Объектно-ориентированное проектирование архитектуры GUI
Совокупность процесса Rational Unified Process, языка моделирования Unified Modeling Language и CASE-средства Rational Rose позволяет осуществить автоматизированное проектирование GUI для компьютерной обучающей системы на основе объектноориентированных технологий и последующей кодогенсрацисй. Проектирование GUI в рамках Rational Unified Process представляет собой междисциплинарную деятельность… Читать ещё >
Объектно-ориентированное проектирование архитектуры GUI (реферат, курсовая, диплом, контрольная)
Объектно-ориентированные графические системы, такие как Visual Basic и Java Beans, дают возможность быстро создать методом визуального формирования как прототип GUI, так и рабочие версии интерфейса. В то же время, если разработчики ставят своей целью сделать этот интерфейс частью создаваемой компьютерной обучающей системы, то целесообразно использовать инструмент построения, генерирующий поддерживаемый код.
При этом в качестве основы объектной технологии можно использовать универсальный процесс Rational Unified Process. Среда разработки дополняется инструментами моделирования и автоматизированного проектирования.
Проектирование GUI — очень обширная задача. На тему разработки графических интерфейсов написано много книг, акцентирующих внимание на различных аспектах этой деятельности [38. 48. 62].
Проектирование графического пользовательского интерфейса характеризуется двумя основными аспектами: проектированием окон и проектированием элементов ввода-вывода и редактирования информации в окнах. Понятие архитектуры относится к общей структуре интерфейса, а нс к деталям: отдельным кнопкам, выпадающим спискам и экранам.
Целью всего процесса разработки интерфейса пользователя являегся эффективная организация интерфейса. Эффективная организация — это не только вопрос выбора и размещения визуальных компонентов (элементов управления) на экране или внутри диалогового окна. Пользовательский интерфейс должен быть организован таким образом, чтобы он был целостным и понятным пользователю для каждого последующего шага выполнения задания. Эта задача решается построением правильной архитектуры пользовательского интерфейса.
Совокупность процесса Rational Unified Process, языка моделирования Unified Modeling Language и CASE-средства Rational Rose позволяет осуществить автоматизированное проектирование GUI для компьютерной обучающей системы на основе объектноориентированных технологий и последующей кодогенсрацисй. Проектирование GUI в рамках Rational Unified Process представляет собой междисциплинарную деятельность, требующую объединения усислий различных специалистов.
Приведем пример визуального моделирования GUI в этой интегрированной среде разработки.
Разработка пользовательского интерфейса начинается с набросков GUI-окон на этапе анализа требований. Эти наброски используются в процессе сбора требований, а также для создания прототипов и для включения документов описания прецедентов.
В соответствии с требованиями к компьютерной обучающей системе будет полезен предварительный эскиз интерфейса (рис. 4.28).
Рис. 4.28. Эскиз оконного интерфейса.
В нем учтена возможность пользователя работы с меню компьютерной обучающей системы и обращение к наиболее часто используемым функциям меню при помощи панели управления. Отражена возможность навигации по учебному материалу при помощи панели ссылок. Для информирования пользователя о текущем состоянии системы служит панель статуса.
В соответствии с методологией Rational Unified Process на технологическом этапе управления требованиями для проектирования окон графического пользовательского интерфейса выявляются и описываются прецеденты (варианты использования) GUI.
Аналитик, который занимается описанием потока событий для прецедента, обладает некоторым зрительным образом интерфейса для поддержки человеко-машинного взаимодействия. Сложные человеко-машинные взаимодействия нельзя верно передать, пользуясь лишь «языком прозы».
Проектировщик, который участвует в определении кооперативных взаимодействий для реализации прецедентов, должен иметь ясное представление о том, как выглядят экранные отображения, выраженные с помощью GUI. Если до него это уже не сделал аналитик, проектировщик становится первым человеком, который вырабатывает графические представления пользовательского интерфейса.
Эти графические представления, предлагаемые проектировщиком, должны соответствовать технологии, на которой базируется интерфейс — средствам организации окон и элементами управления окнами, Internet-браузерами и т. д.
На основе анализа требований к проекту компьютерной обучающей системы выбирается тип окон и формируется глоссарий (словарь) проекта GUI-интерфейса, в котором классам должны быть присвоены ключевые слова (табл. 4.2).
Таблица 4.2.
Глоссарий проекта GUI-интерфейса
Диалог. | Формализованное посредством интерфейсных методов общение пользователя и программы. |
Первичное окно. | Главное окно приложения, отображаемое непосредственно после его запуска. |
Дочернее окно (класс «SecWindowUn»). | Окно, имеющее «привязку» к началу координат первичного окна. Отображение и перемещение дочернего окна ограничено областью первичного по отношению к нему окна. Перемещение первичного окна вызывает синхронное перемещение дочерних. |
Модальное окно (класс «SecWindowMod»). | «Всплывающее», то есть не дочернее, самостоятельное в своих перемещениях окно, обеспечивающее уровень диалога, подчиненный по отношению к диалогу в окне, из которого оно было вызвано. Окно этого типа блокирует взаимодействие со всеми другими окнами приложения до своего закрытия. |
Внсрсжимнос окно. (класс «SccWindowPar»). | Окно, реализующее параллельные ветви диалога. Пользователь может выбирать активное окно, переключая между первичным и внережимным окнами. При переходе к другому окну, диалог во внережимном окне прерывается, но не завершается окончательно. Введенная информация передастся приложению. |
Меню. (класс «Menu»). | Структурированные по разделам функции приложения. Обычно строка меню находимся в верхней части первичного окна. |
Панель управления (класс «ControlPanel»). | Группирующий наиболее часто используемые в приложении функции интерфейсный объект. Обычно доступ к функциям представлен в виде пиктограмм — графических изображений, связанных по смыслу с назначением функции. |
Рабочая область. (класс. «Workarca»). | Область первичного окна, возможно, представленная дочерним окном, в которой происходит основная работа приложения и пользователя. В компьютерном тренажерном комплексе рабочая область служит для отображения учебного материала. |
Панель ссылок (класс «Link»). | Обычно располагаемая справа интерфейсная панель, содержащая ссылки к опорным точкам в изучаемом материале, облегчающая навигацию. |
Панель статуса (класс «Status»). | Располагающаяся в нижней части экрана интерфейсная панель, служащая для отображения текущего состояния системы и других важных сообщений. |
Выявляются следующие прецеденты для проекта GUI-интерфейса компьютерной обучающей системы, которые отражаются на диаграмме (рис. 4.29):
- • Обращение к меню
- • Обращение к панели управления
- • Обращение по ссылке
Рис. 4.29. Диаграмма прецедентов для графического
пользовательского интерфейса компьютерной обучающей системы Поскольку разработка осуществляется в соответствии с процессом Rational Unified Process в Rational Rose, документирование всех прецедентов целесообразно осуществлять по шаблону RUP. Приведем описание одного из прецедентов GUI в этой форме.
- 1. Название прецедента: Обращение к меню
- 1.1. Краткое описание
Данный вариант использования служит для вызова функций приложения.
1.2. Действующие лица Пользователь программы, производящий запросы к функциональным частям пользовательского интерфейса.
1.3. Триггеры Пользователь обращается к меню программы.
- 2. Поток событий
- 2.1. Основной поток
- 2.1.1. Пользователь обращается к меню программы
- 2.1.2. Система выводит окно, соответствующее пункту меню, инициирует процесс или же выводит подменю, если оно имеется.
- 2.1.3. Подчиненные альтернативные потоки событий
- 2.1.3.1. Условие 1.
Пункт меню ссылается на вторичное дочернее окно.
- 2.1.3.1.1. Выпадающее меню закрывается
- 2.1.3.1.2. Система выводит окно, привязанное к системе координат первичного окна
- 2.1.3.2. Условие 2.
Пункт меню ссылается на всплывающее модальное окно.
- 2.1.3.2.1. Выпадающее меню закрывается
- 2.1.3.2.2. Система выводит окно, блокирующее взаимодействие с другими окнами до своего закрытия.
- 2.1.3.3. Условие 3.
Пункт меню ссылается на всплывающее внережимное окно.
- 2.1.3.3.1. Выпадающее меню закрывается.
- 2.1.3.3.2. Система выводит окно с параллельным ведением диалога относительно первичного окна.
- 2.1.4. Выпадающее меню закрывается.
- 2.1.5. Система инициирует процесс, вызываемый выбранным пунктом меню.
- 2.1.6. Панель статуса обновляется.
- 2.1.7. Вариант использования завершается.
- 2.2. Альтернативные потоки
- 2.2.1. Условие 1.
Если первичное окно неактивно и недоступно, ничего не происходит. Вариант использования завершается.
- 3. Специальные требования
- 3.1. Платформа: Windows
- 4. Предусловия: Первичное окно активно и доступно.
- 5. Постусловия: нет.
- 6. Точки расширения
Точки расширения, связанные с этим прецедентом, отсутствуют.
Следует отметить, что в этом прецеденте не указываются детали, относящиеся к пользовательскому интерфейсу — кнопки, текстовые поля, экраны и страницы. Это сделано намеренно: прецеденты описывают функциональность системы, а не способы реализации.
Выявленные и описанные как прецеденты в шаблоне RUP функциональные требования для GUI являются отправной точкой архитектурного и детализированного проектирования.
Далее по методологии Rational Unified Process осуществляется технологический этап анализа и проектирования, который является связующим между процессами управления требованиями и реализации. При анализе и проектировании прецеденты используются для определения набора объектов, которые последовательно превращаются в классы, подсистемы и пакеты.
В процессе проектирования осуществляется дальнейшая разработка окон GUI для компьютерной обучающей системы в соответствии с особенностями и ограничениями выбранной программной среды.
На этапе анализа и проектирования необходимо распределить функции программы между выявленными объектами. Динамическая часть объектной модели GUI формируется на основе диаграмм последовательности для каждого прецедента и всех потоков событий.
Моделирование последовательности позволяет получить расширенную форму представления, которая выстраивает весь процесс взаимодействия в виде реальной последовательности действий. На рис. 4.30 представлен фрагмент диаграммы последовательности для прецедента «Обращение к меню».
Диаграмма отражает динамику этого прецедента, инициатором которого является пользователь.
Обращение к меню происходит посредством мыши или клавиатуры, что вызывает появление поля для выбора пункта меню, если функция MainWindowStatus () возвращает значение, соответствующее доступности первичного окна. После получения выбора пользователя система открывает окна, принадлежащие одному из классов окон, или инициирует процесс, передавая управления ядру системы. После завершения данных действий поле меню закрывается.
Подобная интерпретация и анализ осуществляется для всех диаграмм последовательности, построенных для основных и подчиненных потоков событий по всем прецедентам интерфейса.
Рис. 4.30. Фрагмент диаграммы последовательности для прецедента «Обращение к меню».
Архитектурное проектирование интерфейса компьютерной обучающей системы отражает многоуровневую организацию классов и пакетов, повторное использование и управление компонентами GUI. Детализированное проектирование, обращенное к моделям кооперации, представляет реализацию функциональных возможностей системы, зафиксированных в прецедентах.
Для распределения процессов между объектами интерфейса и анализа степени равномерности распределенности в Rational Rose генерируются диаграммы кооперации.
Семантически диаграммы последовательности и кооперации идентичны, однако на этапе проектирования диаграммы кооперации дают информацию с необходимой точностью при представлении альтернативных путей сообщений и явно отражают статические отношения между объектами. Диаграмма кооперации для подчиненного потока событий «Вывод внережимного окна интерфейса» представлена на рис. 4.31.
Определение внутреннего состояния системы отражается в модели классов. Диаграмма классов дает обобщенное визуальное представление обо всех элементах модели. После того, как операции в конечном итоге вводятся в классы, модель классов в явном виде определяет поведение системы.
Рис. 4.31. Диаграмма кооперации для подчиненного потока событий «Вывод внсрсжимного окна интерфейса».
На стадии детального проектирования формируются пакеты классов для графического пользовательского интерфейса. Классы системы размещаются по трем пакетам (рис. 4.32):
- • Граница (Boundaries) — интерфейсные объекты системы.
- • Управление (Control) — управляющие объекты системы.
- • Сущность (Entities) — информационные объекты системы.
Рис. 4.32. Диаграмма пакетов классов системы
- • ControlPanel — класс, ответственный за интерфейсный объект, группирующий наиболее часто используемые функции приложения и предоставляющий доступ к ним посредством пиктограмм;
- • Link — класс, реализующий работу интерфейсного объекта, ответственного за навигацию пользователя по документальным ресурсам компьютерного тренажерного комплекса посредством перенесения к опорным точкам и непосредственно к необходимым документам.
- • Menu — класс, ответственный за поведение интерфейсного объекта «Меню»
- • Workarea — класс, отражающий поведение рабочей области первичного окна
- • SecWindowMod — класс, которому наследуют объекты типа «Модальное окно».
- • SecWindowPar — класс, которому наследуют объекты типа «Внережимное окно».
- • SecWindowUn — класс, которому наследуют объекты типа «Дочернее окно».
- • Status — класс, которому наследует объект «Панель статуса». Диаграмма классов пакета «Boundary» представлена на рис. 4.33.
Рис. 4.33. Диаграмма классов пакета «Boundary»
- • FormController — класс, ответственный за корректную работу оконного интерфейса. В ведении данного контроллера — наблюдение за открытием и закрытием окон и соблюдением правил доступа к ним;
- • RunProcess — класс, ответственный за проведение процессов, вызываемых пользователем посредством пользовательского интерфейса. Передает ядру системы запрос на запуск процесса.
- • WorkControlier — класс, ответственный за контроль правильной работы программы в целом.
Диаграмма классов пакета «Control» представлена на рис. 4.34.
Рис. 4.34. Диаграмма классов пакета «Control».
Пакет «Entities» (Информационные объекты системы)
В пакет «Entities» входят следующие классы:
- • LinkBase — класс, ответственный за базу ссылок на опорные места в учебном материале;
- • LecData — класс, отвечающий за учебный материал — тесты, документы и т. д.
Диаграмма классов пакета «Entities» представлена на рис. 4.35. Следует отметить, что при визуальном проектировании окон интерфейса для фиксации возможных путей перемещения целесообразно разработать диаграммы навигации по окнам с использованием в качестве стереотипа диаграммы видов деятельности.
Таким образом, в результате объектно-ориентированного анализа и проектирования графического пользовательского интерфейса компьютерной обучающей системы получено визуальное представление сгруппированных по основному назначению классов с приведением набора неотъемлемых атрибутов и ассоциированных с ними операций.
Рис. 4.35. Диаграмма классов пакета «Entities».
Проект GUI для компьютерной обучающей системы не затрагивает механизм реализации самого приложения и представляет собой модель программного обеспечения, которая подлежит последующей кодогенерации.
Реализация интерфейса на этапе программирования системы должна сопровождаться изменениями, обусловленными средой программирования. В некоторых случаях изменения могут привести к улучшению GUI-интерфейса, в других случаях изменения отрицательно сказываются на проекте из-за ограничений, связанных с программированием и продуктивностью.