Применение модельных каркасов для проектирования графического интерфейса

На данном уровне развития средств моделирования программного обеспечения одной из важнейших задач разработки является качественное проведение анализа и проектирования, обеспечивающих создание модели функционирования программной системы. Это позволит заложить твердый фундамент для дальнейшей ее программной реализации.

Качественная архитектура дает возможность выявить общие абстракции и механизмы, которые можно свести воедино, тем самым делая систему проще, меньше и надежнее. Наш опыт разработки компьютерных обучающих систем показывает, что применение принципов объектно-ориентированной декомпозиции для данного класса программного обеспечения приводит к архитектуре, обладающей требуемыми свойствами организованной сложности.

Значительная часть затрат на разработку всей компьютерной обучающей системы в целом приходится на проектирование и реализацию графического пользовательского интерфейса. Как отмечалось ранее, наиболее результативное проектирование архитектуры интерфейса осуществляется по объектно-ориентированной технологии в терминах классов проектирования, с поддержкой объектов и в интегрированной среде разработки, позволяющей осуществить в конечном итоге кодогенерацию [84].

Дизайн пользовательского интерфейса входит в фазу проектирования программного обеспечения, однако его также можно считать и частью фазы требований. Из обработки требований заказчика необходимо понять цель конкретного пользовательского интерфейса в свете общего назначения программы и соответственно определить его важнейшие элементы проектирования.

Центральное место в методологии объектно-ориентированного анализа и проектирования занимает разработка логической модели системы в виде диаграммы классов, графически представляющей структурные взаимосвязи, не зависящие от времени. В соответствии с современными тенденциями программной инженерии повторного использования образцов результативное проектирование архитектуры графического пользовательского интерфейса может быть осуществлено с применением модельных каркасов, представляющих собой расширяемые шаблоны.

Цель применения модельного каркаса в контексте данной задачи — унификация модели интерфейса и упрощение ее архитектуры без потери соответствия реализуемым функциональным требованиям.

Анализ требований к компьютерным обучающим системам позволил выделить следующие основные функциональные требования для подсистемы управления пользовательским интерфейсом:

• • реакция системы на запросы пользователя и реализация его взаимодействия с компьютерной обучающей системой;
• • работа с меню команд;
• • навигация по учебному материалу при помощи панели ссылок в режиме доступа;
• • ограничение доступа к ссылкам при несовместимости режимов использования (например, при тестировании).

Учитывая специфику компьютерных обучающих систем, для которых проектируется унифицированная модель графического пользовательского интерфейса, предлагается создание, кроме главного (первичного) окна программы, следующих типов окон [62]:

• • дочерние — окна, имеющие «привязку» к началу координат первичного окна;
• • модальные — всплывающие, свободные в перемещении, но блокирующие доступ к остальным окнам программы до своего закрытия и реализующие подчиненный уровень диалога;
• • внережимные — окна, свободные в перемещении, но не блокирующие доступ к остальным окнам и реализующие параллельные ветви диалога компьютерной обучающей системы с пользователем.

На основе объектно-ориентированного подхода к проектированию GUI с использованием стандартного языка моделирования Unified Modeling Language (UML) эти интерфейсные окна реализованы в проекте, соответственно, классами SecWindowUn, SecWindowMod и SecWindowPar, которые являются наследующими по отношению к классу WindowClass, определяющему общие свойства всех окон интерфейса (см. раздел 4.5). Каждое новое открываемое окно будет являться экземпляром одного из этих классов.

Основополагающим фактором для описания вариантов использования графического пользовательского интерфейса является то, что интерфейсное окно создается при соответствующей команде пользователя, либо по программному запросу, а его содержание и назначение носят вариативный характер. Необходимо также учитывать, что подсистема поддержки интерфейса отвечает только за создание объекта, принадлежащего к одному из классов интерфейсных окон с определенными свойствами, а также за передачу созданному объекту необходимой информации, соответствующей его назначению.

Для того чтобы не выделять отдельные функции создания окон, класс создаваемого окна может быть представлен в качестве параметризованного ресурса, вид которого зависит от значения параметра (в данном случае — определяющей тип окна переменной). При этом создание окон будет осуществляться с использованием одного и того же набора классов и отношений, в рамках одной единственной функции GUI, что сэкономит время проектировщика и программиста и не допустит последующей путаницы, неизбежной при большом количестве функций.

Современные тенденции программной инженерии предопределяют необходимость в объектно-ориентированном проекте механизмов расширения и модификации системы в соответствии с потенциальными изменениями се функциональности и контекста. Для реализации этих возможностей при разработке архитектуры подсистемы графического пользовательского интерфейса был применен один из видов проектных образцов — модельный каркас (model framework), представляющий собой шаблон как связанную группу пакетов с базовой структурой многократного использования.

Шаблон модельного каркаса содержит механизмы с некоторыми абстрактными сущностями, каждая из которых характеризуется ролью в микроархитсктурс шаблона каркаса. При заполнении абстрактных концепций конкретными сущностями происходит конкретизация шаблона в соответствии с данной предметной областью.

Таким образом, модельный каркас представляет собой пример параметризованного сотрудничества (кооперации), параметры которого именуют элементы, связываемые пользователем с конкретными сущностями, соответствующими решаемой задаче.

Для выявления оптимального набора классов и отношений, задействованных в создании окон графического пользовательского интерфейса, был использован шаблон модельного каркаса ResourseAllocation метода Catalysis, описывающий создание объектов с учетом параметризованного ресурса [25].

Конкретизация данного шаблона модельного каркаса путем замены абстракций понятиями данной предметной области, позволила создать модельный каркас Window Creation, применение которого дает возможность формировать объекты интерфейсных окон любого из трех вышеописанных классов в рамках одной архитектуры (рис. 5.10).

Рис. 5.10. Модельный каркас Window Creation.

В данном каркасе создание продукта (интерфейсного объекта Window) является результатом работы контроллера окон FormController, зависящим от типа окна WindowType. Родительским классом создаваемого объекта является класс, заполняющий поле WindowClass в соответствии с типом окна. Полученный объект-окно будет обладать всеми необходимыми свойствами, характерными для его класса. При этом следует подчеркнуть отличие от классического наследования, поскольку инстанцированный класс наследует все ассоциации с их кратностью.

Применение модельного каркаса Window Creation позволяет выявить классы и их отношения, необходимые для построения модели, описывающей создание нового окна графического пользовательского интерфейса определенного класса, соответствующего значению параметра WindowType. Полученный объект-окно будет обладать всеми необходимыми свойствами, характерными для его класса.

Созданное окно, в зависимости от ситуации, должно отображать некоторую информацию — текст, графику и т. д. Так как передаваемая информация может быть различной, шаблон модельного каркаса может быть также повторно применен и к передаче информации окну с заменой заполнителей другими сущностями, характерными для операции передачи конкретных данных окну (рис. 5.11).

При этой процедуре окну, созданному как экземпляр класса WindowClass в согласовании с контроллером FormController, в соответствии с конкретным назначением окна в системе передается массив данных Content.

Рис. 5.11. Многократное применение шаблона модельного каркаса.

Классы и отношения, выявленные в ходе проектирования с использованием шаблона модельного каркаса, представлены на фрагменте диаграммы классов (рис. 5.12).

Рис. 5.12. Фрагмент диаграммы классов для создания окна интерфейса.

Диаграмма классов подсистемы графического пользовательского интерфейса, отражающая взаимосвязи между отдельными сущностями данной предметной области и описывающая их внутреннюю структуру и типы отношений, может служить дальнейшим развитием концептуальной модели проектируемого интерфейса.

Полная диаграмма классов статической модели подсистемы GUI, представлена на рис. 5.13. На диаграмме также отражены классы, необходимые для работы прочих функций подсистемы GUI — статусной строки, меню и т. д.

Рис. 5.13. Диаграмма классов модели подсистемы поддержки GUI.

Классы SecWindowUn, SecWindowPar и SecWindowMod. представленные на диаграмме классов наследующими классу Window, являются заполнителями ддя приведенного на рис. 5.10 абстрактного класса WindowClass, выбирающимися в соответствии со значением WindowType. Класс Main Window представляет собой родительский класс для объекта главного окна программы. Остальные классы, реализующие окна программы, связаны с классом MainWindow отношениями композиции. На диаграмме присутствует абстрактный класс Process, отражающий совокупность классов, отвечающих за системные процессы, нс входящие в подсистему пользовательского интерфейса, но вызываемые его объектами посредством функции CallProcess контроллера RunProcess.

Следует отметить, что операции и переменные, воспроизведенные в полной статической модели графического пользовательского интерфейса, были выявлены в процессе построения динамической модели системы в виде диаграмм последовательности, представляющих процесс создания нового окна по модельному каркасу Window Creation для всех прецедентов системы. Пример диаграммы последовательности, отражающей процесс создания нового интерфейсного окна по модельному каркасу Window Creation для прецедента «Обращение к меню», представлен на рис. 5.14.

Рис. 5.14. Диаграмма последовательности для прецедента «Обращение к меню».

Логическое представление подсистемы графического пользовательского интерфейса в виде диаграммы классов представляет собой статическую структурную модель, подлежащую программной реализации. Отметим, что подобная диаграмма классов может быть разработана по-разному, что зависит от субъективного взгляда разработчика на отдельные аспекты реализации модели. Особенностью представленной модели является использование в качестве основы модельного каркаса Window Creation, являющегося шаблоном многократного использования.

Применение модельного каркаса ResourseAllocation метода Catalysis позволило объединить однотипные операции по созданию окон различных типов в одну, а также сделать эту операцию компактной. Предложенный подход к разработке графического пользовательского интерфейса на основе идеи модельного каркаса существенно ускоряет процесс проектирования и делает возможным получение унифицированной модели интерфейса.