Конструирование веб-приложений на основе графического интерфейса
Проектирование архитектуры инструментальных средств конструирования веб-приложений. Выбор цветовой схемы графического интерфейса. Проектирование и создание макета интерфейса редактора. Реализация редактора графического интерфейса веб-приложения.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 01.07.2017 |
| Размер файла | 2,4 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
- Оглавление
- Введение
- 1. Модельно-ориентированная разработка и CASE инструменты
- 1.1 Модельно-ориентированная разработка
- 1.2 Трансформация моделей
- 1.3 Пользовательский интерфейс
- 1.4 Понятие CASE-инструментов
- 1.5 Анализ CASE-инструментов
- 1.5.1 PragmaDev Studio
- 1.5.2 Flexberry
- 1.5.3 Rational Software Architect
- 2. Проектирование архитектуры инструментальных средств конструирования веб-приложений
- 2.1 Требования к программному обеспечению
- 2.1.1 Функциональные требования
- 2.1.2 Нефункциональные требования
- 2.2 Общая архитектура приложения
- 2.3 Схема базы данных
- 2.4 Структура классов приложения
- 2.5 Диаграмма сотрудничества
- 3. Создание редактора графического интерфейса
- 3.1 Выбор цветовой схемы для редактора
- 3.2 Проектирование и создание макета интерфейса редактора
- 3.2.1 Visual Studio
- 3.2.2 IntelliJ Idea
- 3.2.3 Создание макета интерфейса редактора
- 3.3 Реализация редактора графического интерфейса
- Заключение
- Библиографический список
- Приложение A Архитектура приложения
- Приложение B Схема работы RabbitMQ
- Приложение C Схема базы данных
- Приложение D Диаграммы классов
- Приложение E Диаграммы сотрудничества
- Приложение F Техническое задание
- Приложение G Цветовые схемы редактора
- Приложение H Листинг функции для перестроения дерева
Введение
веб приложение интерфейс редактор
В наше время, когда информационные технологии развиваются с большой скоростью, появляется множество инструментов для работы на компьютере. Они стали для нас неотъемлемой частью в обыденной жизни. Компьютер выполняет самые разные задачи, а для выполнения задач требуется различное программное обеспечение. В последние годы программное обеспечение все больше и больше «переходит» в интернет, растет количество веб-приложений [7].
Веб-приложения имеют ряд положительных аспектов:
- Для полноценной работы веб-приложения нужен только браузер и доступ в интернет.
- Для работы веб-приложений требуется аппаратная платформа, не обладающая большими вычислительными мощностями.
- Для конечного пользователя обновление веб-приложений происходит автоматически, не занимая времени и сил пользователя.
- Веб-приложения обеспечивают высокую мобильность [31].
Разработка веб-приложения, реализующего сложный функционал, является не простой задачей. Пользователи приложений даже не подозревают, что, когда они заходят на сайт и выполняют какие-либо действия, где-то на сервере происходит сложные вычислительные процессы, которые, возможно, их персональный компьютер не смог бы обработать [17].
Для создания веб-приложений привлекаются разработчики, которые «с нуля» пишут код, используют готовые библиотеки кода, фреймворки и другие необходимые инструменты. Однако есть альтернативные решения. Например, генерация приложений, основанная на построении визуальных моделей с использованием языков моделирования, таких как UML. Человек строит необходимые диаграммы по определенным заранее заданным правилам, а на следующем шаге он запускает генерацию исходного кода приложения на основе созданных диаграмм [16, 22]. Примерами, такого типа программного обеспечения являются Flexberry и инструменты компании PragmaDev, RISE Editor, Timing-Architects Tool Suite.
Такие программные продукты позволяют сократить время на разработку, при этом не требуются программисты, которые пишут именно код. Для использования таких инструментов требуется человек, знающий правила построения диаграмм для конкретного продукта, который может «разработать» приложения.
Данные продукты являются хорошей альтернативой разработке приложений «с нуля», тем не менее, они обладают рядом недостатков:
- программные продукты запускаются на определенной операционной системе,
- продукты используют языки моделирования, что является с одной стороны наглядным, но с другой стороны, для некоторых людей, не совсем ясным и понятным,
- требуются определенные знания в проектировании и моделировании, а также в использовании языков моделирования и построении диаграмм.
Данные недостатки приводят к тому, что продукты не находят широкого применения, а используются в узких кругах.
Для устранения недостатков вышеописанных программных продуктов было решено разработать веб-приложение, которое будет строить модель приложений на основе пользовательского интерфейса, т.е. пользователь на сайте инструмента создает визуальный вид приложения, дополняя его небольшим количеством метаданных, и на основе созданной пользователем модели веб-странички строится модель приложения.
Объектом данного исследования является процесс разработки веб-приложений на основе графического интерфейса. Предметом исследования является инструментальное средство конструирования веб-приложений.
Целью работы является реализация редактора графического интерфейса инструментального средства конструирования веб_приложений.
Для достижения цели были поставлены следующие задачи:
1. Проанализировать системы, использующие языки моделирования для построения веб-приложений.
2. Составить техническое задание.
3. Описать архитектуру с помощью диаграммы развертывания и компонентов.
4. Выполнить проектирование базы данных.
5. Описать статическую структуру приложения с помощью диаграмм классов и сотрудничества.
6. Выбрать цветовую схему для редактора графического интерфейса инструментального средства конструирования веб_приложений.
7. Создать прототип, макет интерфейса и сверстать каркас редактора графического интерфейса.
8. Реализовать функции и провести альфа_тестирование редактора графического интерфейса. Под функциями понимается реализация возможности создания веб_страниц при помощи добавления элементов на рабочую область, изменение стилей элементов, сохранение, загрузка и удаление проектов на локальном компьютере.
1. Модельно-ориентированная разработка и CASE_инструменты
В данной главе будет описано что такое модельно_ориентированная разработка, ее достоинства и недостатки по сравнению с код-ориентированным подходом разработки. Далее будет рассмотрено понятие трансформации, какие бывают виды трансформаций. После чего будет описано что такое CASE_инструмент, и проведен анализ нескольких CASE_систем.
1.1 Модельно-ориентированная разработка
Модельно-ориентированная разработка - это парадигма создания программного обеспечения, в которой основным артефактом в процессе разработки являются модели. Сторонники (Martнnez, Lуpez, Gustavsson, Heijstek и Chaudron) данного подхода разработки утверждают, что подход имеет следующие преимущества над традиционным подходом к разработке программного обеспечения (код_ориентированный подход) [16, 11]:
- Прирост производительности в долгосрочном и краткосрочном периоде.
- Улучшение коммуникации проекта.
- Улучшение качества готового программного обеспечения.
- Существенная экономия ресурсов при реализации приложения для нескольких программных платформ одновременно.
- Архитектура позволяет до известной степени автоматизировать процесс программирования. Наличие подробной модели обеспечивает автоматическое создание типовых частей приложения, разработка которых поддается автоматизации. Например, создание пользовательского интерфейса, программирование типовых операций, создание базы данных и организация доступа к данным.
- Независимость модели от средств разработки обеспечивает возможность реализации на любой программной платформе.
Причиной вышесказанных утверждений является то, что на сегодняшний день подход модельно-ориентированной разработки предлагает высокий уровень абстракции, который «захватывает» основные характеристики современных приложений. Абстракции позволят ускорить создание моделей, которые могут использоваться в различных средах выполнения [16].
Данная парадигма появилась и могла быть реализована благодаря наличию ряда стандартов и технологий, на практике доказавших свою полезность. Концептуальной основой появления парадигмы стали спецификации OMA, ORB, CORBA. Перевести замысел в практическую плоскость позволили технологии объектно-ориентированного программирования (ООП), стандарт CWM, языки UML, XML, MOF. Работами по созданию новой архитектуры программирования занялся консорциум Object Management Group (OMG) [22].
По мнению создателей данного направления, оно является новым витком эволюции технологий программирования, т.к. описывает процесс разработки целиком. Новизна заключается в том, что описание процесса разработки в данном направлении выполнено с использованием современных средств представления, например, диаграммы на языке UML. Также MDE позволяет автоматизировать создание приложений [8, 21].
Модельно-ориентированная разработка способствует активному использованию моделей на протяжении всего процесса разработки программного обеспечения, что приводит к автоматической генерации конечного приложения. Под моделью в данном случае понимают описание или спецификацию системы и ее окружения, созданную для определенных целей. Часто модель является комбинацией текстовой и графической информации. Текст может быть описан специализированным или естественным языком. Обычно модель определяется с помощью языков моделирования общего назначения таких, как UML, XML, но также часто встречается использование предметно-ориентированных языков моделирования, которые позволяют учесть специфику предметной области и задач проекта [10].
Результатом процесса разработки при использовании модельно-ориентированного подхода является готовое приложение, включая его интерфейс. Пользовательский интерфейс приложения зачастую является одним из основных факторов, определяющих успех приложения. Технология разработки пользовательского интерфейса, основанная на моделях, стремится обеспечить программистов средой, в которой они могут проектировать и реализовывать пользовательские интерфейсы намного проще, чем при использовании традиционных инструментов разработки пользовательского интерфейса. Однако, стоит обратить внимание на то, что в пользовательском интерфейсе могут присутствовать сложные элементы управления интерфейсом, такие как таблицы, графики, деревья, которые меняют свое содержание в зависимости от заданного контекста. Сложные элементы управления и компоненты пользовательского интерфейса расширяют функциональные возможности интерфейса, но являются трудоемкими для практической реализации [15].
Исходя из вышесказанного, можно утверждать, что модельно-ориентированная разработка пользовательского интерфейса имеет определенные преимущества, такие как автоматизация создания интерфейса, описание процесса разработки более абстрактно, наглядное отображение пользовательского интерфейса, например, в диаграммах. Однако есть и недостатки, например, отсутствие определенного единства в обозначениях, каждый инструмент требует определенных правил составлениях схем, диаграмм и связей между ними. Также инструменты в основном генерируют определенно заданные элементы пользовательского интерфейса, что ведет к единообразию получившихся приложений. Изменение интерфейса может быть трудоемким для пользователей данных инструментов. А пользовательский интерфейс должен быть уникальным, чтобы привлечь пользователей, но помимо привлекательности интерфейс должен быть удобным, чтобы пользователю было приятно с ним работать. Например, элементы одного типа, такие как кнопки «ОК» и «Отмена», должны находиться в одном месте для определенного типа окон, иначе пользователя это будет дезориентировать. Исходя из примера, стоит полагать, что инструменты должны позволять настраивать пользовательский интерфейс «вручную», т.к. мнение об удобстве привычных элементов визуального отображения меняется, стандарты для интерфейсов создаются разными компаниями, например, Google, Apple и др. Но их стандарты могут также меняться со временем, и, следовательно, нужно вносить изменения в механизм генерации пользовательского интерфейса.
1.2 Трансформация моделей
В модельно-ориентированном подходе модель является главным артефактом разработки, из которого генерируется исполняемый код. В данном случае, модель - это абстрактное описание программного продукта, которое упрощенно описывает аспекты программного обеспечения. Основная идея модельно-ориентированной разработки состоит в том, что для разработки приложения потребуется построить подробную и формально точную модель. Из этой модели в дальнейшем будет генерироваться код программного обеспечения. Модель создается не на языке программирования, а при помощи языка моделирования, например, Unified Modeling Language (UML). Модель, построенная при помощи языков моделирования, является независимой от используемой платформы (Platform Independent Model), в данном случае платформа - это набор технологий, который включает в себя функциональные возможности, предоставляемые через интерфейсы и модели использования. Данная модель привязана к требованиям и предметной области, и не зависит от деталей, таких как язык программирования, платформа на которой будет исполняться приложение, тип базы данных и др. После построения платформенно-независимой модели, задаются детали реализации, такие как язык программирования, платформа, архитектура, и на основе деталей, платформенно-независимая модель трансформируется в платформенно-зависимую (Platform-Specific Model) [20]. Далее на основе платформенно-зависимой и -независимой моделей с помощью инструментальных средств генерируется исполняемый код приложения. Если создано несколько платформенно-зависимых моделей, то процедура генерации кода может производиться несколько раз - под каждую используемую платформу, в соответствии с выбранными настройками. Поэтому трансформация моделей является неотъемлемой частью модельно-ориентированного подхода.
Как было описано в работе [3], “Вертикальная трансформация - это преобразование, при котором исходная и целевая модель принадлежат различным уровням абстракций, например, при отображении объектов метамодели на объекты модели предметной области” или иными словами, это уточняющая трансформация, которая отображает высокоуровневые модели на модели низкого уровня. И “Горизонтальная трансформация - это преобразование, при котором исходная и целевая модели принадлежат одному уровню абстракций”. Также автор Чарнецки [9] разделял горизонтальные трансформации на реструктуризующие и делокализующие.
- Реструктуризующие трансформации реорганизуют спецификацию для совершенствования ее дизайна без изменения содержания. Данная трансформация может быть применена к языкам на основе графов и древовидным языкам.
- Делокализующие трансформации используются для оптимизации или для комбинации частей одной и той же реализации.
Помимо этого, автор выделяет наклонный тип трансформации - комбинация горизонтальной и вертикальной трансформации. Примером наклонной трансформации является компилятор общего назначения, он генерирует двоичный код из исходного кода (вертикальная трансформация) и оптимизирует генерируемый двоичный код (горизонтальная трансформация) [9].
1.3 Пользовательский интерфейс
“Пользовательский интерфейс (user interface) - все компоненты интерактивной системы (программное обеспечение или аппаратное обеспечение), которые предоставляют пользователю информацию и являются инструментами управления для выполнения определенных задач” [1]. Представляет собой совокупность методов и средств, с помощью которых пользователь взаимодействует с устройством.
Средства взаимодействия включают в себя:
- Средство вывода информации от устройства к пользователю - это воздействие на организм человека (на зрение, слух, тактильное взаимодействие и т.д.).
- Средство ввода информации - это устройства для контроля состояния человека - кнопки, датчики положения и движения, жесты лицом и руками и другие способы считывания данных человека.
Методы - это набор правил, заложенный разработчиком, благодаря которым пользовательские действия приводят к необходимой реакции устройства и выполнению требуемой задачи. Данные правила должны быть легки для запоминания и просты для понимания, разработка правил входит в область пригодности использования. “Пригодность использования (usability) - свойство системы, продукции или услуги, при наличии которого установленный пользователь может применить продукцию в определенных условиях использования для достижения установленных целей с необходимой результативностью, эффективностью и удовлетворенностью” [1].
Существует несколько видов пользовательского интерфейса:
1. Визуальный интерфейс.
1.1. Текстовый интерфейс пользователя - разновидность интерфейса пользователя, использующая при вводе-выводе и представлении информации исключительно набор буквенно-цифровых символов и символов псевдографики.
1.2. Графический интерфейс - разновидность пользовательского интерфейса, в котором элементы интерфейса (меню, кнопки, значки, списки и т.п.), представленные пользователю на дисплее, исполнены в виде графических изображений.
1.2.1. Оконный интерфейс - способ организации полноэкранного интерфейса программы (разновидность графического интерфейса), в котором каждая интегральная часть располагается в окне - собственном субэкранном пространстве, находящемся в произвольном месте «над» основным экраном. Несколько окон, одновременно располагающихся на экране, могут перекрываться, виртуально находясь «выше» или «ниже» друг относительно друга.
1.2.2. Веб интерфейсы - это совокупность средств, при помощи которых пользователь взаимодействует с веб-сайтом или любым другим приложением через браузер.
1.2.3. Масштабируемый интерфейс - графический интерфейс пользователя, где рабочее пространство представляет собой большую или неограниченную плоскость, на которой расположены основные элементы, свойства и содержимое которых становятся доступны по мере их «приближения» путём увеличения.
2. Жестовый интерфейс - подмножество системы ввода для графического пользовательского интерфейса для устройств, оснащённых специальными либо устройствами ввода (отличными от клавиатуры), либо сенсорными экранами и позволяющая эмулировать клавиатурные команды (либо сочетания клавиш) при помощи жестов.
3. Голосовой интерфейс - при помощи голосовой/речевой платформы делает возможным взаимодействие человека и компьютера для запуска автоматизированного сервиса или процесса.
4. Осязательный интерфейс - это разновидность интерфейса пользователя, в котором взаимодействие человека с электронными устройствами происходит при помощи материальных предметов и конструкций.
Помимо пользовательского интерфейса часто можно встретить статьи об опыте пользователя, опыте взаимодействия с компьютером. Опыт пользователя (user experience) - восприятие и ответные действия пользователя, возникающие в результате использования и/или предстоящего использования продукции, системы или услуги [2]. О разработке интерфейса пользователя, основанном на опыте взаимодействия, материалы часто меняются, каждый автор видит «идеальный» интерфейс по-своему. По данной тематике проходит множество конференций, делают много докладов, она актуальна, т.к. устройства ввода/вывода информации меняются. Раньше компьютер был лишь настольным, то есть имел только клавиатуру и мышь как средство ввода информации и средство вывода - экран. Но на сегодняшний день это изменилось - у пользователя широкий выбор средств ввода и вывода. Ввод информации может происходит за счет сенсорного экрана, датчиков движения, считывания жестов и мимики лица с помощью камеры и других способов ввода. Это все сильно изменило представление о пользовательском интерфейсе. Большое количество средств ввода и вывода информации приводит к тому, что приложения должны соответствовать каждому типу устройства и иметь свой, уникальный и особенный дизайн.
Модельно-ориентированный подход вводит много жесткости, строгости в определение модели. В данном подходе разработка ведется на уровне абстракции, а значит разработчик не сможет изменить каждую мелочь. Это также относится и к интерфейсу пользователя. Обычно инструменты модельно-ориентированной разработки являются гибкими лишь настолько, насколько это заложено в них на этапе проектирования и разработки. Также инструменты ограничены предметно-ориентированным языком. Часто бывает так, что данные инструменты генерируют интерфейс похожий друг на друга, и он является не настраиваемым и негибким [13, 19].
Это приводит к тому, что инструменты со временем будут устаревать, т.к. устройства модернизируются, появляются новые тренды в разработке дизайна приложений. Поэтому хорошим решением было бы сделать гибкую настройку дизайна интерфейса пользователя на этапе разработки программного продукта.
1.4 Понятие CASE-инструментов
“CASE (Computer-Aided Software Engineering) - набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов” [15]. Средства автоматизации разработки программ (CASE-средства) - инструменты автоматизации процессов проектирования и разработки программного обеспечения для проектировщиков, разработчиков программных продуктов и системных аналитиков. Изначально CASE-средства упрощали только трудоемкие процессы анализа и проектирования, но после появления стандарта ISO/IEC 14102 CASE-средства стали применять для поддержки программного продукта на всех этапах жизненного цикла [18].
Предпосылкой для появления CASE-средств была информационная система проектирования и оптимизации систем (Information System Design and Optimization System, ISDOS), которая начала разрабатываться в 1968 году в университете Мичигана. Данная система привлекла большой интерес во всей сфере использования компьютерных технологий. Однако термин CASE был впервые придуман в 1982 году в Мичигане компанией Nastec Corporation of Southfield для их текстового редактора GraphiText с оригинально встроенной графикой. Это была первая система на базе микрокомпьютера, которая использовала гиперссылки для перекрестных ссылок между текстовыми строками в документах - аналог сегодняшних ссылок на веб-странице. Преемником GraphiText стал DesignAid - первый инструмент для логической и семантической оценки программного обеспечения, проектирования диаграмм системы и создания словаря данных [14].
A. Fuggetta классифицировал CASE-средства на три категории [12]:
1. Вспомогательные программы (Tool) - поддержка конкретной задачи жизненного цикла программного обеспечения.
2. Инструментальное средство (Workbenches) - объединение двух или более вспомогательных программ, ориентированных на поддержку определенной части жизненного цикла программного обеспечения.
3. Рабочие среды разработчика - объединение двух или более инструментов или инструментальных средств для поддержки полного или почти полного жизненного цикла программного обеспечения.
Сейчас данную классификацию можно назвать классификацией по категориям CASE-средств. Далее рассмотрим классификацию по признакам [12]:
- Поддерживаемые методологии проектирования: объектно-ориентированные, функционально-ориентированные, структурно-ориентированные и комплексно-ориентированные.
- Поддерживаемые графические нотации построения диаграмм.
- Степень интегрированности: toolkit - не интегрированные средства, которые охватывают большинство этапов разработки информационных систем, tools - отдельные локальные средства и workbench - интегрированные средства.
- Тип и архитектура вычислительной техники.
- Режим коллективной разработки проекта.
- Тип операционной системы.
Также CASE-средства классифицируются по типам [12]:
- Средства проектирования и анализа - предназначены для анализа и построения моделей системы, например, System Architect, Power Designer, Paradigm Plus, Rational Rose, Oracle Designer, Silverrun, BPwin.
- Средства проектирования базы данных - обеспечивают моделирование данных и генерацию схем баз данных, к ним относятся: Power Designer, Paradigm Plus, Oracle Designer.
- Средства тестирования - предназначены для автоматического тестирования.
- Средства управления конфигурацией программного обеспечения, например, ClearCase, PVCS.
- Средства документирования - предназначены для автоматического документирования.
- Средства управления проектами - предназначены для автоматизации управления проектами, к ним относятся такие системы как Microsoft Project, Open Plan Professional.
- Средства реверсного инжиниринга - предназначены для анализа существующих баз данных и программного кода, формирования на их основе различных моделей и в дальнейшем перенос существующей системы на новую среду.
Как и все программные продукты, CASE-средства имеют недостатки, далее представлены наиболее значимые факторы риска для организаций, которые применяют технологию CASE:
- Недостаточная стандартизация. Как правило, организации должны подбирать и адаптировать под себя методологии и инструменты для конкретных задач. Однако это может потребовать значительных усилий по интеграции несогласованных технологий или методов.
- Нереалистичные ожидания. Поставщики дорогих CASE-средств часто завышают ожидания, обещая, что их CASE-средство будет решением всех проблем. В действительности такого инструмента не существует.
- Недостаточная подготовка. Как и любая новая технология, CASE-средства требуют времени на обучение персонала.
- Неадекватное управление технологическим процессом. CASE обеспечивает использование новых возможностей, что может привести к новым проблемам без надлежащего управления и контроля за новыми возможностями.
1.5 Анализ CASE-инструментов
В данной части будут рассмотрены CASE-инструменты, которые в своем функционале имеют возможность создания моделей и генерации кода на основе моделей. Для рассмотрения будут взяты следующие CASE-инструменты: PragmaDev Studio, FLexberry и Rational Software Architect.
1.5.1 PragmaDev Studio
PragmaDev Studio - это инструмент для проектирования, моделирования и генерации кода, который был впервые представленный в 2002 году под названием Real Time Developer Studio. Главная цель программного продукта заключалась в поддержке языка с формальной семантикой (Specification and Description Language, SDL) в реальном времени. В октябре 2015 года была выпущена пятая версия продукта и было изменено название на PragmaDev Studio. Программный продукт разделен на четыре модуля: Specifier, Developer, Tester and Tracer [30].
PragmaDev Specifier направлена на оказание помощи системным инженерам, архитекторам для выражения своих требований в графической и исполняемой модели.
PragmaDev Developer помогает разработчикам программного обеспечения в определении архитектуры. Данный модуль позволяет:
- Сосредоточить внимание на функциональных проблемах.
- Создать понятную и четкую архитектуру.
- Написать портативный дизайн.
- Облегчить техническое обслуживание.
- Автоматически сгенерировать документацию.
Графические символы (рисунок 1.1 [30]) используются для описания архитектуры и поведения на высоком уровне различных агентов. Низкоуровневое поведение описывается на C или C++ в графической модели, поэтому код и модель всегда согласованы.
После того как модель будет проверена на локальном компьютере, код может быть сгенерирован для выполнения на целевом сервере. Компания утверждает, что сгенерированный код будет читабельным и понятным. Также данный модуль дает возможность соединяться с отладчиком и кросс-отладчиком, что позволяет отлаживать модель на локальном и удаленном серверах.
Отслеживаемый код может включать в себя:
- Информацию для подключения к PragmaDev Tracer.
- Информацию для анализа последних событий.
- Информацию о покрытии тестами.
Отладчик моделей предоставляет пути выполнения, а также три уровня пошагового перехода по модели:
- Переход от одного события к другому.
- Графический пошаговый переход на диаграммах.
- Пошаговый переход в сгенерированном C-коде.
Отладчик данного программного продукта позволяет сделать шаг в отладчике на диаграмме и переключиться на другое представление, что позволяет отлаживать модель более гибко. Также для визуального контроля тестируемой системы может быть создан путь реального выполнения, пример которого представлен на рисунке 1.2 [30].
Рисунок 1.1 PragmaDev Developer
Рисунок 1.2 Путь реального выполнения
PragmaDev Tester модуль тестирования, который поддерживает стандарт тестирования TTCN-3 (нотация тестирования и управления тестами версии 3) - это строго типизированный скриптовый язык, который применяется в различных областях. С 2000 года был использован в области стандартизации, промышленности, научных исследованиях, международных проектах и в научных кругах. Данный язык поддерживается компанией European Telecommunication Standards Institute (ETSI) [28].
Данная система имеет следующие функции:
- Моделирование: PragmaDev Specifier включает в себя симулятор SDL, который ведет себя как отладчик модели. В нем возможно установить точки останова в графическом виде для просмотра переменных, а также установить ожидающие таймеры. Во время выполнения формируется путь на основании диаграммы последовательности сообщений.
- Анализ производительности: система предоставляет инструмент анализа производительности, чтобы найти наилучшую архитектуру.
- Тестирование: в системе есть модуль тестирования, который имитирует тестовые случаи созданной модели или генерирует код тестов для запуска в системе для тестов.
- Проверка модели: система позволяет экспортировать модель в такие форматы, как IF, FIACRE или XLIA, чтобы проверить модель в сторонних инструментах, например, IFx, TINA или Diversity.
- Генерация кода: PragmaDev Developer может сгенерировать код на языках C или C++ на основе SDL модели.
На рисунке 1.3 представлен пример написанного тест-кейса в нотации TTCN-3, который может быть создан в PragmaDev Studio. Кроме текстового представления, для тестирования используются диаграммы, которые представляют собой путь выполнения тест-кейса. Пример такой диаграммы представлен на рисунке 1.4. На диаграмме можно увидеть, как обозначаются функции, а также в конце показано окончание тест-кейса (белый прямоугольник с обозначением setVerdict). В самом конце показан результат выполнения тест-кейса. При разработке крупных проектов порой становится сложно тестировать приложение, необходимо писать много тест-кейсов, много кода, а при отладке кода тестов иногда сложно обнаружить ошибку. Диаграмма позволяет упростить процесс отладки тестового кода и ускорить процесс локализации проблемы.
Рисунок 1.3 Пример тест-кейса в нотации TTCN-3
Рисунок 1.4 Диаграмма выполнения тест-кейса
1.5.2 Flexberry
“Flexberry - это технологическая программная платформа для профессиональной разработки программного обеспечения. Позволяет ИТ-подразделениям предприятий и компаниям-разработчикам оптимизировать процесс проектирования, создания и поддержки информационных систем” [27]. Данная система применима в следующих областях:
- Комплексные учетные системы.
- Автоматизация бизнес-процессов и документооборота.
- Веб-приложения.
- Мобильные приложения.
- Интеграция информационных систем.
- Аналитические системы.
- Геоинформационные системы.
Также на сайте системы приводятся следующие преимущества использования платформы:
- Быстрое создание прототипов программного решения.
- Снижение трудоёмкости процесса разработки информационных систем.
- Возможность применения готовых программных компонент.
- Повышение эффективности взаимодействия с заказчиками за счёт применения визуальных моделей систем и процессов.
- Использование сервисно-ориентированного подхода для развития информационного пространства предприятия.
- Уменьшение затрат на сопровождение информационных систем.
В состав платформы входят следующие компоненты:
- Flexberry Designer - CASE-инструмент, который реализует нотацию UML. Данный инструмент может использоваться в бизнес моделировании, а также в объектно-ориентированном проектировании программного обеспечения и баз данных.
- Flexberry ORM (Object-Relational Mapping) - программный продукт, реализующий объектно-реляционное отображение на базе Microsoft.NET Framework.
- Flexberry ASP.NET - Flexberry ASP.NET представляет собой полноценный фреймворк ASP.NET Web Forms-приложений и генераторы кода для Flexberry Designer. Включает в себя все возможности Flexberry ORM.
Есть другие компоненты данной платформы, но они не относятся к теме исследования.
Ключевыми особенностями Flexberry ORM являются [26]:
- Концепция представлений (проекций).
- Поддержка различных СУБД «из коробки».
- Полная настройка названий таблиц, полей и т.п. в БД.
- Первичные ключи произвольного типа.
- Отображение в БД полей произвольных типов.
- Перехват момента сохранения в БД и выполнение дополнительных действий.
- Широкие возможности по кастомизации, включая возможность управления запросами.
- Поддержка Mono (отсутствие неуправляемого кода).
Ключевыми особенностями Flexberry ASP.NET являются [25]:
- Готовые веб-компоненты, предназначенные для работы с Flexberry ORM.
- Возможность сгенерировать готовое веб-приложение.
При помощи данной платформы можно создать веб-приложение, которое будет сгенерировано по UML диаграммам. От разработчика требуется создать диаграмму классов, далее можно сгенерировать скрипты для базы данных на основе данной диаграммы, сгенерировать приложение ASP.NET и др. В данном случае реализован принцип Model-first - разработчик производит все изменения в CASE-системе, а изменения в коде происходят во время генерации. На момент использования в системе была реализована генерация ASP.NET приложения. На момент написания данной работы Flexberry предлагает генерировать приложения используя концепцию MVC для back-end приложения, и фреймворк Ember для front-end приложения. На рисунке 1.5 представлено окно компонента платформы Flexberry Designer. На рисунке 1.5 можно видеть слева дерево проектов. В показанном дереве имеется уже несколько диаграмм с названиями Stage и Stage Ember.
Рисунок 1.5 Внешний вид окна Flexberry Designer
На рисунке 1.6 представлено окно проектирования диаграммы классов компонента Designer, на основании которой будет сгенерирован код. На диаграмме можно видеть основные элементы стандартной нотации UML. Отношения обобщения, ассоциации и агрегации корректно отражаются в коде. В диаграмме некоторые названия полей и методов начинаются с плюса, некоторые нет. Плюс в данном случае обозначает, что поле или метод будет иметь модификатор прав доступа public в коде, а по умолчанию выставляется private.
Рисунок 1.6 Flexberry Designer. Окно проектирования диаграммы классов
Помимо диаграммы классов, в данном инструменте можно строить диаграммы состояний (рисунок 1.7) и диаграммы использований (рисунок 1.8), а также сотрудничества и последовательностей.
Рисунок 1.7 Flexberry Designer. Диаграмма состояний
Рисунок 1.8 Flexberry Designer. Диаграмма использований
Недостатками данной платформы являются: жесткая привязка к UML диаграммам и его нотации. Также данная диаграмма классов расширяется дополнительным набором параметров, которые нужно определить и не всегда очевидно, что получится после генерации. Пользовательский интерфейс генерируется однотипный и статичный. Также настройки некоторых полей, например, выпадающие списки редактируются в коде, а не в редакторе. Данные настройки находятся не всегда в очевидном месте, что приводит к обращению за помощью в службу поддержки, что замедляет разработку. Несмотря на все это, данная платформа является средством разработки, основанной на диаграмме классов и может использоваться для создания крупных проектов.
1.5.3 Rational Software Architect
“Rational Software Architect - инструмент, обеспечивающий возможности моделирования на основе UML, функций трансформации модели и генерации кода. Это интегрированное средство проектирования и разработки, которое использует преимущества UML-разработки на основе моделей, позволяя создавать приложения и сервисы с практичной архитектурой” [4]. Данный инструмент поддерживает стандарт UML 2.0. В инструменте есть окно Model Explorer (рис. 1.9) [4], которое показывает проекты моделирования, содержащее любое количество моделей. Сама модель содержит различные элементы, такие как классы, пакеты, параметры и др.
Рисунок 1.9 Rational Software Architect. Model Explorer
В инструменте есть окно “Навигатор диаграмм”, которое показывает проекты моделирования и их UML_диаграммы в другом представлении. Они отображаются в виде дерева (рис. 1.10) [4].
Рисунок 1.10 Rational Software Architect. Diagram Navigator
В инструменте можно строить 13 видов диаграмм:
- Диаграмма вариантов использования (use case).
- Диаграмма хронометрирования.
- Диаграмма состояний (State machine).
- Диаграмма последовательностей.
- Диаграмма пакетов.
- Диаграмма объектов.
- Диаграмма обзора взаимодействия (interaction overview).
- Диаграмма размещения.
- Диаграмма с составной структурой (Composite structure).
- Диаграмма компонентов.
- Диаграмма коммуникации.
- Диаграмма классов.
- Диаграмма активностей (Activity diagram).
На рисунке 1.11 [4] представлен редактор диаграмм инструмента Rational Software Architect. В нем можно открыть UML_диаграмму. В редакторе есть возможность добавления новых элементов диаграммы или загрузки из существующей модели, перемещая элемент из Model Explorer.
Рисунок 1.11 Rational Software Architect. Редактор диаграмм
Инструмент Rational Software Architect поставляется с 5 трансформациями. Они применяются к разным уровням элементов UML, а также к модели, пакету, классу и интерфейсу. Доступны следующие трансформации:
- UML в C++.
- UML в Java.
- UML в EJB.
- UML в CORBA.
- UML в XSD.
Они позволяют сгенерировать соответствующие проекты Eclipse и родственные артефакты из UML_модели. Например, инструмент может сгенерировать Enterprise Java® beans (EJB) проект из UML для трансформации компонентов EJB, а трансформация UML в Java может создать проект Java Application.
2. Проектирование архитектуры инструментальных средств конструирования веб-приложений
В данной главе будут описаны шаги проектирования архитектуры приложения. Графически архитектура будет описана с помощью языка моделирования UML. Для описания функциональных требований будет использована диаграмма вариантов использования (use case diagram), для представления архитектуры будет использоваться диаграмма. Для детального анализа будут использованы диаграммы классов и состояний. Диаграмма классов служит для представления статической структуры модели системы в терминологии классов объектно_ориентированного программирования, а диаграмма состояний поможет описать возможные последовательности состояний и переходов, которые характеризуют поведение элемента модели в течение жизненного цикла программного обеспечения.
Разрабатываемое программное обеспечение будет представлять из себя веб_приложение, которое состоит из серверного приложения, которое работает на сервере или нескольких серверах, клиентского приложения для взаимодействия с пользователем и базой данных. Разрабатываемый программный продукт должен будет генерировать основу для развертывания веб_приложения. Под основой понимается: код серверного приложения, код клиентского приложения и скрипты для создания базы данных.
2.1 Требования к программному обеспечению
Далее будут описаны функциональные и нефункциональные требования к разработке инструментальных средств конструирования веб_приложений. Функциональные требования будут поделены на необходимые функции серверной и клиентской частей.
2.1.1 Функциональные требования
Серверное приложение должно включать в себя обработку данных, работу с базой данных, выполнение функций, требующих большого количество ресурсов. К функциональным требованиям серверной части относятся функции:
- Работа с базой данных.
- Обработка данных полученных из базы и приведение данных к нужному виду для отображения в пользовательском интерфейсе.
- Трансформация исходной HTML страницы в пригодную для чтения и хранения модель на каком_либо языке, например, XML.
- Генерация скриптов для создания базы данных, исходного кода приложений как для серверной части, так и для пользовательской.
- Функция проверки HTML страниц, созданных с помощью редактора.
Клиентское приложение в разрабатываемом инструменте будет обладать не только функциями вывода информации, а также включать в себя редактор HTML страниц. Исходя из вышесказанного, клиентская часть будет обладать следующим функционалом:
- Вывод необходимой информации.
- Создание и редактирование HTML страниц, которые в дальнейшем будут использоваться для трансформации.
- Возможность проверки созданных страниц на пригодность к трансформации.
- Возможность предпросмотра создаваемой страницы веб_приложения.
Функциональные требования описаны на языке UML с помощью диаграммы вариантов использования, которая представлена на рисунке 2.1. На диаграмме показаны основные функции, которые доступны пользователю, в зависимости от его прав доступа. Например, пользователь с правами «Гость» не сможет войти в редактор, у него будет доступ только для просмотра основной информации о программном продукте, сайте и другой общей информации. Также ему будет доступна авторизация если у него есть аккаунт или же возможность регистрации. Для авторизированного пользователя доступен другой набор функций: вход в редактор и создание HTML страниц, просмотр страниц не в режиме разработки, а как эти страницы примерно будут выглядеть в итоге - предпросмотр, загрузка созданных проектов из базы данных, а также сохранение в базу, помимо этого у пользователя должна быть функция генерации готового приложения - генерация итогового кода веб_приложения. Также пользователь может просматривать основную информацию или выйти из аккаунта.
Рисунок 2.1 Диаграмма вариантов использования
2.1.2 Нефункциональные требования
К нефункциональным требованиям можно отнести:
- Безопасность - регистрация и авторизация пользователя по логину и паролю. Для повышения безопасности возможно подключить Google Authenticator, который позволяет реализовать двухфакторную аутентификацию. Использование протокола HTTPS для шифрования передаваемых данных.
- Разграничение прав доступа - предоставление доступа к функционалу в зависимости от выданных пользователю прав.
- Доступность - приложение должно быть доступно круглосуточно, кроме штатных работ.
- Масштабируемость - приложение должно иметь возможность подключения нескольких серверных приложений, которые будут работать независимо друг от друга. Также масштабируемость предполагает подключение множества пользователей к сервису.
- Удобство - клиентская часть должна быть спроектирована в соответствии с правилами User Experience Design. Серверная часть должна быть спроектирована и разработана в соответствии с общепринятыми шаблонами проектирования (pattern), если это необходимо и возможно в конкретной ситуации.
- Возможность настройки приложения - функция, позволяющая изменять конфигурации приложения. Переход к странице изменения настроек должен быть доступен с любой страницы приложения.
- Приложение должно корректно работать в браузере Chrome версии 56 и выше.
- Совместимость между версиями приложений должна поддерживаться с разницей в одну версию - при переходе приложения с версии 1.0.0 на версию 2.0.0 модель должна трансформироваться из HTML страниц, разработанных в версии 1.0.0.
- Приложение должно быть локализовано как минимум на два языка: русский и английский, причем английский язык в приоритете и стандартно выбран. Изменение языка интерфейса, должно происходить в пользовательских настройках приложения.
- Редактор графического интерфейса (клиентское приложение для создания HTML страниц) может иметь исключения в разделе нефункциональных требований.
2.2 Общая архитектура приложения
Первым шагом в разработке программного продукта является анализ и проектирование архитектуры будущего приложения. Одним из способов является графическое описание архитектуры, например, с помощью диаграммы. Она представлена на рисунке А.1. На ней можно видеть из каких частей будет состоять программный продукт. Разрабатываемое приложение будет состоять из:
- Серверной части веб_приложения, для взаимодействия с пользователем.
- Клиентской части веб_приложения.
- Очереди сообщений.
- Сервера баз данных.
- Нескольких вычислительных узлов, выполняющих сложные функции.
Клиентская часть будет состоять из нескольких модулей, которые доступны неавторизированному и авторизированному пользователям. Для неавторизированного пользователя должен быть доступ к информации сайта, информации о приложении, контактным данным. Для авторизированного пользователя должен быть доступ ко всей информации, которую видит неавторизированный пользователь, а также в личный кабинет, к истории созданных проектов (в данном случае проект - это создание веб_страниц для одного приложения). Кроме того, авторизированный пользователь может перейти к редактору веб_страниц, создать новый проект, открыть ранее созданный, начать редактировать проект. Проектирование интерфейса будет описано далее в работе.
Серверная часть будет состоять из нескольких модулей:
- Обработчик запросов.
- Обработчик сообщений в исходящей (input) очереди.
- Обработчик сообщений во входящей (output) очереди.
- Модуль для работы с базой данных.
Обработчик запросов будет содержать в себе логику обработки всех запросов, приходящих от пользователей. Например, это может быть запрос на получение данных, авторизация, генерация кода. В зависимости от типа запроса, обработчик будет вызывать функции того или иного модуля. В случае с получением данных из базы, обработчик запросов будет запрашивать данные из модуля для работы с базой данных, а если пользователь захочет сгенерировать код приложения, основанного на модели, то запрос будет передан в обработчик исходящих очередей, чтобы добавить сообщение в очередь на обработку запроса.
Обработчик сообщений в исходящей очереди будет выполнять формирование сообщения для очереди, добавление метаданных к нему и отправку в очередь сообщений. К метаданным будет относится информация о том, какую функцию требуется выполнить, какой идентификатор был присвоен операции и другие данные по мере необходимости. Это позволит в дальнейшем серверу определить в какую очередь сообщений необходимо перенаправлять сообщение.
Обработчик сообщений во входящей очереди будет выполнять функцию просмотра и поиска в определенной очереди результата выполнения действий вычислительного узла. Примером функции вычислительного узла может являться функция генерации исходного кода. Данная функция является затратной по ресурсам, может выполняться долгое время, поэтому есть смысл вынести такую функцию на отдельный сервер, который будет выполнять подобного рода задачи.
Модуль для работы с базой данных будет инкапсулировать в себе функции для работы с базой данных. Это повысит читабельность кода, т.к. разработчик будет знать, что все функции для работы с базой будут находиться именно в этом модуле, а не разбросаны запросы на языке SQL по всему коду приложения, что понизит читабельность.
Для работы с очередями сообщений была выбрана платформа RabbitMQ, основанная на стандарте Advanced Message Queuing Protocol (AMQP). В протоколе AMQP используются такие понятия, как:
- Exchange - место, куда пишутся сообщения.
- Queue - место, откуда читаются сообщения.
- Route - связывает Exchange и Queue.
На рисунке B.1 [24] показана схема работы RabbitMQ с одной очередью. Видно, что слева находится Publisher - субъект, который отправляет сообщение в Exchange, после этого Route перенаправляет сообщения с помощью метаданных сообщения в соответствующую очередь - Queue. Такая схема позволяет добиться большой гибкости, т.к. приложение может публиковать сообщения в N Exchange и читать из M очередей (рис. B.2 [24]). При этом из одной очереди могут читать несколько клиентов, в этом случае сообщения раздаются по алгоритму round_robin, что наделяет RabbitMQ функцией балансировщика. Помимо этого, RabbitMQ, отдав сообщение, требует подтверждения его обработки сервером, или отправки отказа в обработке, что приводит к возврату отправленного сообщения обратно в очередь, и сообщение снова отправляется подписанным на очередь серверам по алгоритму round_robin. В пользу выбора RabbitMQ можно отметить следующие функции: отправка сообщений в очереди, балансировка между серверами, а также повышение отказоустойчивости, за счет подтверждения обработки сообщения.
...Подобные документы
Особенности создания ряда игровых приложений, логической игры. Программное обеспечение простейшего калькулятора, генератора функций. Разработка элементов интерфейса простейшего графического редактора, электронной записной книжки, текстового редактора.
методичка [788,7 K], добавлен 24.10.2012Изучение особенностей растровых и векторных графических редакторов. Создание графического редактора: выбор языка программирования, разработка структуры программы и алгоритма работы. Описание интерфейса программы. Руководство программиста и пользователя.
курсовая работа [1,3 M], добавлен 28.07.2013Изучение основных алгоритмов генерации различных видов фракталов. Выбор языка и среды программирования. Характеристика структурных элементов растрового графического редактора фракталов. Описание интерфейса приложения, порядок редактирования изображений.
курсовая работа [1,2 M], добавлен 04.04.2014Создание Интернет-сайта для упрощения связи учителей-логопедов и родителей учащихся. Проектирование макета графического интерфейса. Выбор средств разработки программного продукта. Требования к функционалу ученика. Возможности интерфейса администратора.
дипломная работа [2,8 M], добавлен 01.04.2013Принципы создания приложений с GUI. Панель инструментов для добавления элементов интерфейса. Расположение кнопки и осей в окне приложения. Управление свойствами объектов. Установка свойств при редактировании. Программное изменение свойств. Флаги и рамки.
методичка [1,1 M], добавлен 06.07.2009Обзор мобильной ОС Android. Выбор инструментов и технологий. Проектирование прототипа графического интерфейса. Характеристика и описание пользовательского интерфейса. Проектирование и разработка базы данных. Определение списка необходимых разрешений.
курсовая работа [376,6 K], добавлен 13.09.2017Дизайн интерфейса приложения как связь человека и персонального компьютера. Adobe Photoshop и его возможности, анализ функциональности и содержание главных операций. Используемые инструменты для разработки дизайна интерфейса текстового редактора.
контрольная работа [407,5 K], добавлен 12.10.2015Создание консольных приложений с использованием графического интерфейса пользователя. Содержание палитры компонентов программы С++ Builder. Использование возможностей объектно-ориентированного программирования, особенности редактора кода и форм в С++.
лекция [27,0 K], добавлен 22.12.2010Структура организации графического интерфейса, объявление и создание слушателей событий с помощью анонимных классов. Представление данных для таблицы – класс AbstractTableModel. Визуализация ячеек таблицы. Два основных типа потоков ввода-вывода в Java.
лекция [685,3 K], добавлен 01.05.2014Разработка графического интерфейса для ввода начальных значений, отображения результатов и тестирования методов собственного класса на языке программирования С++. Подсветка цветом выбранных операндов в процессе их инициализации и вывода на дисплей.
курсовая работа [234,6 K], добавлен 27.12.2014Алгоритмическое представление и описание правил игры "Эволюция". Построение диаграммы прецедентов. Разработка графического интерфейса пользователя. Реализация интерфейса в среде Unity. Структура файла сохранения игры. Проектирование поведения компьютера.
дипломная работа [3,3 M], добавлен 18.02.2017Роль распределенных вычислительных систем в решении современных задач. Инструментальная система DVM для разработки параллельных программ. Средства построения формальной модели графического интерфейса. Требования к графическому интерфейсу DVM-системы.
курсовая работа [2,7 M], добавлен 15.10.2010Разработка базы данных и сайта с портфолио преподавателей политехнического института. Формирование таблиц со сведениями о преподавателях. Создание графического интерфейса пользователя клиентских приложений. Обоснование выбора языка программирования.
контрольная работа [1,1 M], добавлен 14.05.2013Разработка графического редактора для рисования двухмерной и трехмерной графики, используя язык программирования Java и интерфейсы прикладного программирования Java 2D и Java 3D. Создание графического редактора 3D Paint. Основные методы класса Graphics.
курсовая работа [197,5 K], добавлен 19.11.2009Диаграмма консольного приложения табулирования функции. Отличие консольного приложения и приложения и GUI. Диаграмма классов для JFrameи JPanel. Создание простейшего фрейма в Java. Компоновка элементов интерфейса внутри фрейма. Цикл обработки событий.
лекция [693,8 K], добавлен 01.05.2014Критерии и порядок выбора интерфейса веб-сайта. Характеристики, которые определяют успешность пользовательского интерфейса. Структура навигационной системы. Графический дизайн и выбор цветовой схемы. Техническая реализация интерфейса сайта на сегодня.
реферат [164,8 K], добавлен 24.02.2011Принципы написания оконных приложений, представляющих данные в табличном виде и осуществляющих взаимодействие с символьными и байтовыми потоками ввода-вывода в среде Eclipse. Особенности построения приложений с расширенным графическим интерфейсом.
методичка [1,0 M], добавлен 01.05.2014Элементы интерфейса графического редактора Macromedia Flash. Создание изображений, преобразование формы и заливки. Использование слоев и библиотечных образцов. Разработка анимации в среде Flash. Реализация мультипликации, ее звуковое сопровождение.
курсовая работа [1,3 M], добавлен 15.11.2013Разработка инфологической модели базы данных "Рабочее место кассира", требования к ее функциональным характеристикам. Создание программы в Delphi. Описание компонентов для реализации графического интерфейса и интерфейса ввода справочника кассиров.
курсовая работа [2,2 M], добавлен 17.04.2014Общая характеристика и описание математической модели. Выбор и обоснование среды программирования, анализ входных и выходных данных. Структурное проектирование приложений и интерфейса пользователя. Реализация и оценка защитного программирования.
курсовая работа [564,9 K], добавлен 26.09.2014
