Содержание к диссертации
Введение
Глава 1. Определение и виды информационных систем 12
1.1 ВидыИС 14
1.2 Функциональность информационных систем, ориентированных на данные 15
Глава 2. Технология REAL-IT 18
2.1 Моделирование схемы данных 20
2.2 Описание ограничений целостности 21
2.3 Описание экземпляров 21
2.4 Создание представлений 22
2.4.1 Расширение UML для моделирования представлений 22
2.5 Создание экранов 25
2.6 Генерация 26
2.6.1 База данных 27
2.6.2 Программный интерфейс базы данных 27
2.6.3 Экранные формы 28
2.7 Заключение 28
Глава 3. Язык описания расширенных ограничений ссылочной целостности 29
3.1 Пример диаграммы классов с ограничениями 30
3.2 Альтернативные подходы 32
3.2.1 Visual OCL 33
3.2.2 Constraint Diagrams 34
3.3 Контекстные ограничения 36
3.4 Нотация 39
3.5 Семантика 40
3.5.1 Базовая модель 40
3.5.2 Модель с отрицаниями 43
3.5.3 Модель с ограничениями на отдельные объекты 44
3.5.4 Дизъюнктная модель 45
3.5.5 Пример 46
3.6 Заключение 50
Глава 4. Разработка пользовательского интерфейса 51
4.1 Модельно-ориентированные подходы к разработке пользовательскогоинтерфейса 51
4.1.1 Визуальное моделирование при разработке WEB-приложений 54
4.2 Моделирование интерфейса в REAL-IT 60
4.2.1 Порядок использования модели интерфейса 61
4.2.2 Диаграммы классов UML 62
4.2.3 Шаблоны экранных форм 63
4.3 Разработка отдельных типов экранных форм 65
4.3.1 Список 66
4.3.2 Использование ограничений на данные 71
4.3.3 Карточка 72
4.3.4 Форма - отношение 74
4.4 Заключение 77
Глава 5. Поддержка итеративной разработки 79
5.1 Альтернативные подходы 81
5.2 Поддержка «ручных» изменений кода 86
5.2.1 Возможные решения 87
5.2.2 Анализ возможных решений 88
5.2.3 Предлагаемое решение 89
5.3 Сохранение содержимого базы данных при обновлении ее схемы 93
5.4 Заключение 95
Глава 6. Реализация 97
6.1 База данных 98
6.1.1 Поддержка итеративного процесса 99
6.2 REAL-IT/VB 100
6.2.1 Архитектура приложения 100
6.2.2 Оптимизация выборки данных 105
6.2.3 Генераторы 109
6.2.4 Поддержка итеративного процесса 110
6.3 REAL-IT/Java 111
6.4 REAL-ITAVEB 112
6.5 Заключение 114
Глава 7. Направления дальнейших исследований 116
7.1 Моделирование расширенных ограничений ссьшочнои целостности... 116
7.2 Моделирование пользовательского интерфейса 117
7.3 Распределение прав доступа в терминах модели системы 117
7.4 Разработка семейств информационных систем 118
7.5 Использование модели бизнес-процессов для реализации системы 119
Заключение 120
Литература... 121
- Функциональность информационных систем, ориентированных на данные
- Описание ограничений целостности
- Модель с ограничениями на отдельные объекты
- Порядок использования модели интерфейса
Введение к работе
Несмотря на то, что первые работы по использованию диаграмм для спецификации программ появились еще в начале 60х годов прошлого века, вопрос о роли и месте визуальных спецификаций и их соотнесении с кодом до сих пор остается открытым и вызывает полемику.
Мартин Фаулер (Martin Fowler) и, независимо от него, Стив Меллор (Steve Mellor) определяют следующие способы использования языка визуального моделирования UML [90], которые, однако, можно отнести и к визуальному моделированию в целом [56]:
Набросок. Использование диаграмм в процессе обсуждения или изложения проблем и концепций. Такие наброски носят неформальный характер, простота и выразительность для них важнее, чем полнота описания. При этом следование определенным нотациям может быть полезно для повышения скорости восприятия, если предполагается, что все, для кого предназначена диаграмма, хорошо знакомы с нотацией. Но следование правилам определенного языка не является обязательным требованием и часто нарушается. Чаще всего такие наброски делаются от руки на бумаге или на доске непосредственно во время обсуждения, если же требуется электронный вариант, то обычно используются средства рисования произвольных схем, например, Microsoft Visio.
Чертеж. При этом подходе набор диаграмм представляет собой полное (с определенной точки зрения) формальное описание системы, на основе которого создается программный код. Хотя для получения первой версии кода часто используются генераторы, диаграммное описание является проектом, а не собственно программой, т.е. не включает в себя все детали функционирования системы.
Язык программирования. В этом случае семантика программы полностью выражается средствами языка моделирования, и CASE-пакет представляет собой законченную среду разработки. Обычно, однако, подобный язык содержит не только диаграммную составляющую, но текстовую, которая не может быть выражена средствами диаграмм
(например, система типов или элементарные операции над данными). Примером такого языка может служить SDL [1,97], ведущиеся в настоящее время работы консорциума OMG по подготовке стандарта UML 2.0 во многом направлены на возможность использования UML в этом качестве.
Подход «Чертеж» подразумевает использование диаграмм по аналогии с чертежами в промышленности — т.е. в качестве формальных и полных спецификаций продукта. Долгое время именно этот подход считался основным, и на него ориентировались разработчики CASE-пакетов 70х-90х годов XX века,
1 *?
таких как IEF1, ADW и т.д. Эти пакеты предназначались для разработки произвольных информационных систем, в этом смысле их можно назвать универсальными. Их создатели пытались представить процесс разработки системы как последовательное построение взаимосвязанных моделей, на основе которых осуществляется генерация программного кода. Характерными чертами данного подхода являются необходимость детального моделирования системы с разных точек зрения, внутренняя согласованность и взаимосвязь моделей, а также однозначно определенная семантика каждого элемента модели. Практика показала, что такой подход требует очень больших накладных расходов, а отсутствие поддержки итеративного процесса (что характерно для большинства его реализаций) разработки делает его плохо применимым в большинстве реальных проектов. Несмотря на то неоднократные попытки воплотить этот подход в жизнь не увенчались успехом, он до сих пор представляется идеалом для многих исследователей.
Подход «Набросок» в настоящее время пропагандируется сторонниками «гибких методологий» как альтернатива подходу «Чертеж». Этот подход ограничивает использование диаграмм исключительно коммуникативными функциями, их место оказывается среди пояснительных документов, описывающих мысли проектировщиков системы по поводу отдельных аспектов
Information Engineering Facility, продукт компании Texas Instruments Application Development Workbench, продукт компании Knowledge Ware.
разрабатываемой системы, но не саму эту систему. Естественно, никакой генерации кода при этом не предполагается.
В рамках подхода «Язык программирования» создано несколько специализированных пакетов [99], интегрирующих в себе возможности CASE-средств и среды разработки. Каждый такой пакет предназначен для достаточно узкого класса систем, главным образом, в сфере телекоммуникаций и управления оборудованием. В области создания информационных систем такой подход не нашел широкого применения.
Предлагаемый в данной работе подход относится к направлению «Чертеж» и предусматривает генерацию кода по диаграммам, однако, в отличие от классических подходов [77], здесь не предполагается полное и всеобъемлющее описание системы с помощью диаграмм, а использование последних для описания отдельных подсистем, хорошо поддающихся такому декларативному описанию. Особое внимание при этом уделено интеграции сгенерированного кода и кода, написанного вручную, а также поддержке итеративного процесса разработки.
При выборе подсистем, описываемых с помощью диаграмм, мы исходили из следующих предпосылок:
То, какой из способов представления информации - текстовый или графический, является наиболее удобным, зависит от структуры этой информации.
При описании статической структуры системы диаграммы позволяют наглядно представить взаимосвязи между ее элементами.
Для описания алгоритмов текстовые языки обычно оказываются более удобными, чем графические.
Исходя из представленных принципов (в особенности, последнего), невозможно создать универсальное решение, пригодное для разработки любых видов ПО, в котором основная часть кода генерировалась бы по диаграммам.
Выход здесь мы видим в отказе от универсальности и ориентации на отдельные классы программных систем (или отдельных подсистем), в которых статическая структура информации превалирует над алгоритмами. В качестве такого класса
в данной работе рассматриваются информационные системы, ориентированные на данные. Отметим основные свойства таких систем:
Основными компонентами системы являются база данных и интерфейс пользователя. VT*
Наиболее важным архитектурным элементом является модель данных и ее реализация - схема БД.
При разработке баз данных общепринятым подходом является использование визуального моделирования - диаграмм сущность-связь [25] и их разновидностей - IDEFlx [28], диаграмм классов и т.д. Однако, не вся существенная информация о данных может быть выражена на этих диаграммах. Различного рода зависимости между данными и вытекающие из этих зависимостей ограничения приходится описывать в текстовом виде - в лучшем случае, они указываются в модели в виде формализованных или неформальных комментариев, чаще же всего появляются уже непосредственно в коде. Таким образом, актуальным является вопрос наглядного моделирования функциональных зависимостей, невыразимых средствами модели сущность-связь.
Вторая существенная компонента рассматриваемого класса систем - интерфейс пользователя, во многом определяется моделью данных, что создает предпосылки для создания модели интерфейса на основе модели данных и последующей генерации кода по этой модели. Сциллой и Харибдой являются, с одной стороны, слишком сложная и богатая модель, в пределе позволяющая описывать произвольный интерфейс - при этом затраты на разработку модели окажутся сопоставимыми с непосредственным созданием интерфейса в WYDIWYS3 среде разработки (но без наглядности последней), а с другой -чрезмерное ее упрощение (пределом чего является генерация интерфейса непосредственно по схеме БД), приводящее к необходимости существенной доводки полученного результата (а то и полного его переписывания) для повышения его эргономичности.
3 What You Do Is What You See
Решение этих задач - моделирования ограничений и интерфейса пользователя, а также поддержка итеративной разработки при использовании генераторов кода, представляются нам ключевыми моментами в создании эффективной технологии разработки рассматриваемого класса систем, основанной на генерации кода по диаграммам.
В данной работе представлена оригинальная технология разработки этого класса ИС, основанная на использовании универсального объектно-ориентированного CASE-пакета REAL [22] и включающая в себя набор генераторов программного кода и дисциплину их использования. Основу предлагаемого подхода составляет набор методик, каждая из которых накрывает тот или иной вид деятельности или предназначена для решения определенного класса проблем, возникающих при разработке ИС. Некоторые из методик заимствованы из других подходов (например, использование модели «сущность-связь»), другие являются оригинальными разработками (их описание и составляет основную часть работы). Все эти методики, взятые вместе, составляют единый процесс разработки, для поддержки которого разработаны соответствующие инструментальные средства. Весь набор предлагаемых методик и инструментальных средств мы называем технологией REAL-IT.
Традиционно в процессе создания программных систем выделяют фазы анализа, проектирования и реализации [19]. Использование визуального моделирования при анализе требований и проектировании программных систем является в настоящее время широко распространенной практикой, существует большое количество методологий создания визуальных спецификаций [2,31], в частности, методология REAL [23]. В фокусе внимания технологии REAL-IT находятся этапы детального проектирования и реализации ИС, при этом использование объектно-ориентированного CASE-пакета как среды моделирования и диаграмм UML в качестве основы для генерации исполняемого кода позволяет уменьшить разрыв между этапами проектирования и реализации, поскольку именно UML является, в настоящее время, наиболее часто используемым языком для описания результатов проектирования.
В настоящее время реализовано несколько версий REAL-IT для различных технологических платформ:
REAL-IT/VB - для создания приложений на языке Visual Basic, работающих под управлением ОС семейства Microsoft Windows, как на одном компьютере, так и в архитектуре клиент-сервер. Это вариант предназначен, главным образом, для создания приложений для автоматизации офисной деятельности.
REAL-IT/Java - для создания переносимых приложений в трехзвенной архитектуре на платформе J2SE.
REAL-IT /WEB — для создания интерн ет/интранет приложений. Эта версия технологии еще только разрабатывается.
Предлагаемая технология была успешно применена при реализации целого ряда проектов для отечественных и зарубежных заказчиков, и продолжает использоваться как в новых проектах, так и при сопровождении ранее выпущенных систем.
Основные инструментальные средства REAL-IT создавали:
А.Иванов - основные идеи и общее руководство проектом, генераторы кода, библиотеки поддержки REAL-IT/VB и REAL-IT/Java;
С.Стригун - библиотеки поддержки REAL-IT/VB;
Н.Васильева - библиотека UniWord (REAL-IT/VB), система разграничения прав доступа;
Т.Хаиров - библиотека UniMigrator (REAL-IT/VB);
Ю.Худякова - система разграничения прав доступа;
Т.Сорокина - мастер создания приложения (REAL-IT/VB);
А.Болотова - библиотеки поддержки и генераторы кода REAL-IT/Java для форм типов список и отношение;
Е.Чулкова - библиотеки поддержки и генераторы кода REAL-IT/Java для форм типа карточка, библиотеки поддержки для REAL-IT/WEB;
Т. Васильева - библиотеки поддержки и генераторы кода REAL-IT/Java для форм типа отношение.
Автор выражает признательность всем участникам этого проекта, а также благодарит Д.Кознова и И.Соболева за обсуждение и конструктивную критику диссертационной работы.
Функциональность информационных систем, ориентированных на данные
Все случаи использования ИС можно разделить на две группы: работа пользователей с основными функциями системы и ее администрирование, изображенные на рис. 1.2.
Как правило, базовой подсистемой информационной системы является картотека (людей, документов, продуктов, деталей и т.п.), основной задачей которой является предоставление удобного интерфейса для добавления, удаления и редактирования справочных и рабочих данных. О важности картотеки говорит, в частности, тот факт, что историческое название для всего класса рассматриваемых систем - системы обработки данных.
Кроме того, информационная система призвана автоматизировать некоторый процесс (например, учебный или производственный), в ходе которого над данными картотеки выполняются некоторые операции, причем, обычно эти операции фиксируются в документах определенных типов (приказы для контингента сотрудников или студентов, проводки для счетов, накладные для материальных ценностей и т.д.). Этот процесс определяет основную бизнес-логику системы.
Сбор статистической информации необходим для предоставления различных отчетов, автоматическое создание которых на основе имеющихся данных, как правило, подразумевается.
Информационная система также может содержать ряд специфичных функций, предназначенных для автоматизации сложных бизнес-процессов, например, подготовку и печать выпускных документов для студентов.
Основные задачи администрирования приведены на рис. 1.4. К ним относятся распределение прав доступа к ресурсам системы между группами пользователей, ведение некоторых справочников, которые существенно влияют на логику работы системы и, поэтому, не предоставляются для изменения обычным пользователям, а также настройка и оптимизация системных программных и аппаратных компонент.
В настоящий момент в рамках работ по REAL-IT разрабатывается методика и набор инструментальных средств для организации системы разделения прав на основе высокоуровневых визуальных моделей, полученные на данный момент результаты представлены в работах [3,8].
Редактирование системных справочников полностью аналогично работе с картотекой данных, поэтому для реализации этой функциональности используются те же средства. Вопросы, связанные с настройкой и оптимизацией системных компонент ИС, выходят за рамки данной работы.
Как уже говорилось выше, подход, рассматриваемый в данной работе, содержит набор методик, связанных в единый процесс разработки. Для обозначения всей совокупности этих методик, а также поддерживающих эти методики программных средств, мы используем термин «Технология REAL-IT». Ядром средств технологической поддержки REAL-IT является объектно-ориентированный CASE-пакет REAL [22], разработанный на кафедре системного программирования математико-механического факультета СПбГУ.
С самого начала работа над REAL-IT велась в рамках реальных производственных проектов [20], поэтому особое внимание уделялось интеграции предлагаемых подходов в производственный процесс и тому, чтобы эффект от их использования существенно превышал затраты на их внедрение и поддержку. В частности, именно поэтому одним из наиболее важных элементов REAL-IT является методика поддержки итерационного процесса - отсутствие подобной методики, с нашей точки зрения, является одной из основных причин, не позволяющих использовать кодогенерационные методы в промышленности.
В данную работу не вошли те методики, которые пока не доведены до промышленного применения - такие как высокоуровневый механизм распределения доступа, поддержка разработки семейств программных продуктов, поддержка работы с темпоральными данными и некоторые другие.
Схема, представленная на рис.2.1, отражает основные этапы процесса реализации информационной системы в рамках технологии REAL-IT.
Описание ограничений целостности
При разработке системы могут возникать ситуации, когда уже на стадии построения модели можно выделить отдельные элементы данных (экземпляры классов), существование которых необходимо для правильного функционирования системы. Мы будем называть такие элементы данных предопределенными объектами. К предопределенным объектам можно отнести также элементы некоторых элементы справочников, общие для всех экземпляров системы.
Предопределенные объекты описываются на диаграммах кооперации UML, при этом для их выделения у экземпляров классов на диаграммах кооперации вводится специальный стереотип — «Описание экземпляра». Кроме того, естественным необходимым условием для предопределенного объекта, является его привязка к долгоживущему классу, не являющемуся абстрактным. При описании предопределенных объектов на диаграмме можно указывать их связи друг с другом и значения их атрибутов.
При создании пользовательского интерфейса используются представления. Представление в REAL — это выборка объектов и их атрибутов, которая может содержать, в том числе, вычислимые атрибуты с учетом связей между объектами (SQL-запрос). Представления реализуют шаблон «фасад» [5] для данных, позволяя разработчику конструировать дополнительные логические срезы, или интерфейсы, элементов предметной области. Использование представлений позволяет задавать набор данных, отображаемых в элементе интерфейса, и формат этих данных. Например, разработчик может указать представление для определения набора столбцов в списке, при этом среди них могут быть указаны атрибуты различных классов.
В UML нет специальных средств для описания представлений. В профиле UML, описывающем правила моделирования схемы реляционной базы данных [17], включающей в себя представления, предлагается использовать для моделирования представлений классы со специальным стереотипом «View». При этом с помощью отношений зависимости между классами можно указать, какие классы входят в то или иное представление, однако нет возможности сделать то же самое для ассоциаций, или связать атрибут представления с атрибутом класса, которое оно представляет. Подобные связи можно получить только из текста представления. Однако отсутствие поддержки этих связей может привести к разрушению модели, например, если атрибут класса, использующийся в одном или нескольких представлениях, будет переименован. Чтобы избавиться от этих проблем, в REAL-IT для моделирования представлений было использован не профиль («легкое» (light) расширение метамодели по классификации MOF), а «тяжелое» (heavy) расширение метамодели, т.е. введение в нее дополнительных элементов — классов, атрибутов и ассоциаций для моделирования представлений. Фрагмент метамодели CASE-пакета REAL, описывающий это расширение, представлен на рис. 2.2. Опишем это расширение поподробнее:
Для описания представлений в метамодель добавляется специальный класс «Представление» («View»). Этот класс является наследником класса «Classifier», что позволяет в любых контекстах использовать представления вместо классов.
Для определения набора классов, использующихся в представлении, в метамодель добавлен класс «Элемент представления» («ViewElement»). Фактически, он реализует отношение «многие ко многим» между классами и представлениями, однако при этом он является самостоятельной сущностью метамодели — это нужно для того, чтобы была возможность задать его имя (синоним класса в представлении), и, кроме того, позволяет производить дальнейшее расширение модели, определяя для него стереотипы и пользовательские свойства.
Для определения ассоциаций между классами, входящими в представление (т.е. использующимися для его построения), в метамодель добавлен класс «Связь в представлении» («ViewConnector»). Однако, вместо того, чтобы связывать представления и ассоциации, он связывает элементы представления и роли ассоциации («AssociationEnd»). Такая связь необходима, поскольку один и тот же класс может иметь много вхождений в представление, и если указать только факт использования ассоциации в представлении, то может возникнуть неоднозначность в определении того, какие именно элементы представления она связывает. Кроме того, ассоциация может входить в представление не полностью, а частично, т.е. представление может содержать только некоторые из концов ассоциации, в таком случае мы получаем «индуцированную» ассоциацию между представлением и классами исходной модели. Какие именно ассоциации входят в представление и каким именно образом (полностью или частично) можно определить по цепочке классов «ViewElement» -«ViewConnector» - «AssociationEnd», никаких дополнительных классов и ассоциаций для этого не требуется.
Являясь классом, представление может содержать все те же члены («Feature»), что и любой другой класс (что требуется, например, для описания вычислимых полей представлений в реляционной схеме). Однако, помимо них, представление может содержать и члены специального вида, являющиеся «ссылками» на члены классов, входящих в представление. Для их описания в метамодель добавлен класс «Член представления» («ViewFeature»). Множество членов представления, как и множество членов любого класса является упорядоченной последовательностью, в которой как «обычные» (описанные в UML) члены, так и вводимые нами члены представления могут идти в произвольном порядке.
Модель с ограничениями на отдельные объекты
Для описания семантики сначала определяется семантика отдельной диаграммы кооперации, описывающей ограничение, на которой отсутствуют отрицательные ассоциации. Мы будем называть это базовой моделью ограничений.
Затем будет определена семантика некоторых расширений предложенной модели, позволяющих использовать в ограничениях логические операции, а также интегрировать их с ограничениями других видов.
В модели с отрицаниями нотация диаграмм ограничений расширяется дополнительным элементом, позволяющим описывать отрицания. Для этого нотация расширяется связями с новым стереотипом - «Absent».
В рамках модели с ограничениями на отдельные объекты предлагается способ интеграции в контекстные ограничения, изображаемые на диаграммах, дополнительных ограничений на объекты, выполненных, например, на языке OCL или любым другим способом.
Наконец, в дизъюнктной модели будет определена семантика набора диаграмм кооперации, описывающих ограничения над одним набором классов. При этом нотация самих диаграмм не изменяется.
Ограничение с отрицаниями — это обычное ограничение, к которому добавлены еще некоторые объекты и связи, которые мы будем называть отрицательными. Т.е. на диаграмме объектов у нас будут присутствовать два вида дуг — обычные (элементы L ) и отрицательные (элементы L). Ограничение с отрицаниями выполняется, если выполняется обычное ограничение, и невозможно каждому объекту сопоставить запись таблицы, так, чтобы все дуги (как положительные, так и отрицательные) соответствовали связям между записями. Примерами диаграмм с отрицаниями являются диаграммы на рис.3.8 и рис.3.11. Прагматика
Ограничения позволяют определять допустимость связи между двумя записями в базе данных не только в зависимости от наличия других связей, но и, например, в зависимости от значений атрибутов этих записей (или связанных с ними). Эти дополнительные ограничения могут быть специфицированы с помощью OCL или любым другим способом.
Если имеется набор ограничений на один объект (в нашем случае это ER-база данных), то обычно принято считать, что объект удовлетворяет этому набору в том и только том случае, если он удовлетворяет каждому из ограничений. В случае дизъюнктной системы это не так — весь набор ограничений, составляющий систему, разбивается на группы (дизъюнкты), в каждую из которых входят все ограничения на одну и ту же ассоциацию. При этом считается, что база данных удовлетворяет системе в целом, если она удовлетворяет каждому из дизъюнктов. Однако чтобы база данных удовлетворяла отдельному дизъюнкту, достаточно, чтобы она удовлетворяла хотя бы одному из ограничений, входящих в дизъюнкт. Такая трактовка набора ограничений связана с тем, что довольно часто ограничение на ассоциацию формулируется в виде: «если верно условие 1, то ассоциация должна удовлетворять ограничению 1, а иначе — ограничению 2». Ясно, что такого рода ограничения можно записать в виде дизъюнктов, в том случае, если условие 1 и его отрицание можно добавить на диаграммы, соответствующие ограничениюі и ограничению2 соответственно, в виде дополнительного контекста. В рассмотренном нами примере такой вид имеет ограничение 2. Кроме того, как было сказано выше, пара ограничений 4 и 5 совместно описывает ограничение такого же вида. Ограничения на разные ассоциации, как правило, не связаны между собой, поэтому связь между отдельными дизъюнктами конъюнктивная.
Предлагаемая нотация позволяет в наглядной форме изображать ограничения на модель классов UML.
Новизна предлагаемого подхода заключается в использовании для записи ограничений стандартного синтаксиса диаграмм кооперации OCL. При этом создающиеся диаграммы обычно оказываются «визуально похожими» на диаграммы классов, на которые накладываются ограничения, что облегчает их восприятие. Это достигается за счет того, что граф ограничения гомоморфен графу классов (объекты соответствуют классам, связи — ассоциациям). Кроме того, использование стандартного синтаксиса позволяет уложить предлагаемый язык в рамки профиля UML и использовать для создания диаграмм практически любой CASE-пакет, поддерживающий язык UML.
Можно выделить два способа использования спецификаций ограничений на данные при создании информационных систем: 1. Для недопущения некорректного изменения данных (обычно это делается в триггерах базы данных). 2. Для создания приложений, логика работы которых строится таким образом, чтобы все модификации данных априори удовлетворяли ограничениям. В REAL-IT основным является второй способ — генераторы пользовательского интерфейса используют спецификации ограничений для того, чтобы ограничить возможности пользователя при вводе данных только корректными вариантами.
Порядок использования модели интерфейса
Бурное развитие сети Internet, наблюдающееся в последнее десятилетие, привело к активному использованию средств и протоколов, использующихся в этой сети, в качестве базовой инфраструктуры при создании современных информационных систем. В первую очередь, речь идет об использовании WEB-интерфейса для взаимодействия системы с пользователем (хотя в последнее время большой интерес проявляется также к построению систем на основе WEB-служб).
Моделирование WEB-приложений естественно было бы рассматривать как частный случай модельно-ориентированной разработки пользовательского интерфейса, рассмотренного в предыдущем разделе. Однако, большинство работ, посвященных этой тематике [57], не содержат ссылок на работы по МВиГО и, соответственно, не используют аппарат MBUDD для описания предлагаемых моделей. По-видимому, это связано с тем, что исторически данная область выросла из работ по созданию гипермедиа приложений — энциклопедий, виртуальных музеев и т.д. [48,59,67]. Стоит отметить, что исследования в этой области активно ведутся в последние 3-4 года, в то время как пик интереса к «классическому» MBUE) подходу пришелся на 90е года XX века. Это заставляет рассматривать отдельно исследования в области моделирования WEB-приложений (при этом естественный интерес вызывает сравнение предлагаемых подходов с работами в области МВЦШ).
Отсутствие общего формального аппарата вынуждает нас более подробно описать отдельные подходы (большинство из них представлено одной-двумя статьями и не имеет собственного названия, поэтому мы будем идентифицировать их фамилиями авторов работ).
Подход Коналена (Conallen) [47] предлагает расширение UML для описания Web-приложений. Он вводит стереотипы для классов, методов, атрибутов и ассоциаций для того, чтобы отличать серверную компоненту от клиентской части, server pages от client pages и т.д. Данный подход позволяет описывать взаимодействие между страницами (logical behaviors of Web pages), а также описывать детали peaiiH3auiiH(implementation aspects). Недостатком данного подхода является то, что для описания структуры и поведенческой модели используется только статическая диаграмма классов.
Подход Хенникера (Hennicker) [62] предлагает методологию дизайна, основанную на расширении UML для hypermedia, позволяющего моделировать Web-приложения, фокусируясь на навигации и пользовательском интерфейсе. Предлагаются следующие фазы: концептуальное моделирование, навигационное моделирование и моделирование представления. Концептуальная модель (Conceptual model) строится, основываясь на функциональных требованиях, описываемых с помощью диаграммы случаев использования (use case diagram). Концептуальная модель состоит из диаграммы классов, представляя объекты предметной области и связи между ними. Модель навигационного пространства (Navigation Space model), описывающая какие объекты можно посетить в hypermedia приложении, описывается с помощью диаграммы классов, где определяются навигационные узлы (Navigation Class) и их связи (Direct Navigability). Как конкретно может быть осуществлена навигация (indexes, guided tours, menus) описывает модель навигационной структуры (Navigational structure model), также описываемая с помощью диаграммы классов. Индексы, меню и т.д. описываются с помощью стереотипов. Для визуализации навигационной структуры используются framesets. Хотя в данном подходе так же, как и в предыдущем тоже используется только диаграммы классов для описания поведения и структуры, но данная поведенческая модель более наглядна за счет введения новых элементов моделирования - индексов, очередей и т.д.
Шатковский и Ломен (Schattkowsky, Lorn en) [91] предлагают использовать подмножество UML, адаптированное к предметной области с помощью стереотипов, а также стратегию для генерации шаблонов приложения по построенной модели. Данная методология предназначена для проектирования сайтов малых и средних размеров. Введено различие между клиентскими и серверными элементами страниц. Представлена возможная архитектура Web-приложения (концептуальная модель), описываемая с помощью диаграммы классов. Для описания требований к системе используется диаграмма случаев использования UML. Диаграмма случаев использования уточняется с помощью диаграммы активностей. Данная диаграмма описывает взаимодействие между клиентом и сервером, а так же возможное взаимодействие пользователя с клиентской частью. Для описания структуры данных обрабатываемых клиентской приложением используется диаграмма классов. Отличительной особенностью данного подхода является то, что при генерации кода будущей системы используется и диаграмма случаев использования (для генерации модуля для каждого актера-роли).
Подход Горшковой и Новикова [7,60] также содержит специализацию UML для построения моделей Web-приложения. При этом рассматриваются две модели — навигационная, описывающая взаимодействие пользователя с системой на уровне смены страниц, и композиционная, описывающая структуру и наполнение отдельных страниц. Для описания навигационной модели сайта предлагается использовать диаграммы состояний, элементы которых должны иметь специальные стереотипы, а для создания композиционной модели — диаграммы классов. В отличие от большинства подходов, в навигационной модели предусмотрена возможность работы пользователя с несколькими открытыми окнами одновременно, кроме того, вводится специальный стереотип для описания ошибочных состояний.
