3.6 Заключение

Предлагаемая нотация позволяет в наглядной форме изображать ограничения на модель классов UML.

Новизна предлагаемого подхода заключается в использовании для записи ограничений стандартного синтаксиса диаграмм кооперации ОСЬ. При этом создающиеся диаграммы обычно оказываются «визуально похожими» на диаграммы классов, на которые накладываются ограничения, «по облегчает их восприятие. Эго достигается за счет того, «по граф ограничения гомоморфен графу классов (объекты соответствуют классам, связи - ассоциациям). Кроме того, использование стандартного синтаксиса позволяет уложить предлагаемый язык в рамки профиля UML и использовать для создания диаграмм практически любой CASE-пакет, поддерживающий язык UMJL.

Можно выделить два способа использования спецификаций ограничений на данные при создании информационных сметем:

1. Для недопущения некорректною изменения данных (обычно это делается в триггерах базы данных).

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

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

Глава 4. Разработка пользовательского интерфейса

Существенную часть современной информационной системы сосгавляег пользовательский интерфейс. По данным [80] разработка пользовательского интерфейса обычно занимает около 50% времени от всех затрат на раработку системы.

В ланной главе описывается подход к созданию пользовательского интерфейса, реализованный в RF.AL-1T. Этот подход характеризуется следующими чертами:

• Пользовательский интерфейс разрабатывается в рамках модельно- ориентированного подхода.

• Модель интерфейса строится на основе модели данных.

• Пользовательский интерфейс строится из набора элементов (экранных форм) различных типов. Каждое окно приложения формируется из одной или нескольких экранных форм.

• По модели интерфейса генерируется работающий код, а не только прототип экранной формы.

• Используется инкрементальный подход к созданию интерфейса.

1. Модельно-ориентированные подходы к разработке пользовательского интерфейса

В настоящее время существуют различные подходы к созданию графического пользовательского интерфейса (GUI) 180], например, широко используются среды разработки, которые позволяют визуально конструировать интерфейс из уже готовых графических элементов. Примерами таких сред являются Visual Basic, Delphi, Power Builder и т.д.

Одним из подходов является моделыю-ориентированная разработка пользовательского интерфейса (MBUID — Model Based User Interface Development) [26,50,92], характсризирующаяся использованием высокоуровневых декларативных моделей для проектирования интерфейса, а также автоматическим связыванием моделей и программного кода системы (например, путем генерации кода по моделям). При создании интерфейса в рамках MBUID обычно рассматриваются следующие виды моделей:

• Модель предметной области (Domain Model). Описывает множество сущностей, представленных в разрабатываемой ИС, вместе с их атрибутами, отношениями и возможными операциями нм этими сущностями. Чаще всего в качестве модели предметной области используется модель классов.

• Модель задач (Task Model). Описывает алгоритмы взаимодействия пользователя с системой в виде набора задач, для каждой из которых обычно определяется цель, непустое множество действий или подзадач, необходимых для достижения этой пели, план достижения цели и множество артефактов, изменяемых или используемых для достижения цели.

• Модель пользователей (User Model). Описывает характеристики отдельных пользователей и их ipytin, взаимодействующих с системой. Основная цель использования эгой модели - возможность персонализации интерфейса, т.е. предоставления каждому пользователю системы такого интерфейса, который в наибольшей степени удовлетворяет именно его требованиям и предпочтениям.

• Модель диалога (Dialogue Model). Описывает последовательность взаимодействия пользователя и системы на уровне смены диалогов.

• Абстрактная модель представления (Abstract Presentation Model). Описыкзег каждый диалог в терминах абстрактных объектов интерфейса (АЮ - Abstract Interface Object).

• Конкретная модель представления (Concrete Presentation Model). Уточняет абстрактную модель для конкретной платформы реализации, сопоставляя каждому ЛЮ свой CIO (Concrete Interface Object).

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

Большинство MBUID систем поддерживает какое-то подмножество моделей, в некоторых системах тс или иные модели сливаются (например, модель диалога может составлять единое целое с моделью задач или с абстрактной моделью представления).

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

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

К решениям, основывающимся на динамическом аспекте, можно отнести системы MASTERMIND [42,81], TEALLACH [34,61], ADEPT [76] а также подходы, изложенные в [32,51,94].

К решениям, основывающимся на модели данных, относятся системы JANUS [33], GENIUS [69], Мссапо [85]. К этому же направлению можно отнести генераторы |}м>рм, встроенные в ряд сред разработки приложений (например, MS Accrss, Delphi) и CASE-пакеты (например, ERwin).

Решения первой группы позволяют описать схему бизнес-логики системы, не предоставляя средств для легальной спецификации алгоритмов. Такой подход позволяет генерировать только каркас кода системы. Кроме того, в этих подходах требуется формально описывать интерфейс системы, что, как правило, занимает существенно больше времени, чем создание аналогичного интерфейса в редакторах экранных форм широко распространенных средств разработки ИС (например, в Visual Basic, Delphi, Cylix и т.д.).

В решениях второй группы основной моделью, используемой для создания системы, является статическая модель предметной области (схема базы данных в MS Access и ERwin, диаграммы классов в JANUS). При этом данные средства полразумсвают предопределенную логику работы интерфейса. За счет .этого генерируется не только внешнее представление пользовательского интерфейса, но и программный код, обеспечивающий его работоспособность. Однако интерфейс, создаваемый в рамках этих подходов, однозначно соответствует структуре базы данных, что зачастую оказывается недостаточно удобным для выполнения задач, стоящих перед пользователем.

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