Описание экземпляров
При разработке системы могут возникать ситуации, когда уже на стадии построения модели можно выделить отдельные элементы данных (экземпляры классои), существование которых необходимо для правильного функционирования системы. Мы будем называть такие элементы данных предопределенными объектами. К предопределенным объектам можно отнести также элементы некоторых элементы справочников, общие для всех экземпляров системы.
Предопределенные объекты описываются на диаграммах кооперации UML, при этом для их выделения у экземпляров классов на диаграммах кооперации вводится специальный стереотип — «Описание экземпляра». Кроме того, естественным необходимым условием для предопределенного объекта, является его привязка к долгоживущему классу, не являющемуся абстрактным. При описании предопределенных объектов на диаграмме можно указывать их связи друг с другом и значения их атрибутов.
Создание представлений
При создании пользовательского интерфейса используются представления. Представление в REAL — это выборка объектов и их атрибутов, которая может содержать, в том числе, вычислимые атрибуты с учетом связей между объектами (SQL-запрос). Представления реализуют шаблон «фасад» [5] для данных, позволяя разработчику конструировать дополнительные логические срезы, или интерфейсы, элементов предметной области. Использование представлений позволяет задавать набор данных, отображаемых в элементе интерфейса, и формат этих данных. Например, разработчик может указать представление для определения набора сюлбцов в списке, при этом среди них могут быть указаны атрибуты различных классов.
Расширение uml для моделирования представлений
В UML нет специальных средств для описания представлений. В профиле UML, описывающем правила моделирования схемы реляционной базы данных [17], включающей в себя представления, предлагается использовать для моделирования представлений классы со специальным стереотипом «View». При этом с помощью отношений зависимости между классами можно указать, какие классы входят в то или иное представление, однако нет возможности сделать то же самое для ассоциаций, или связать атрибут представления с атрибутом класса, которое оно представляет. Подобные связи можно получить только из текста представления. Однако отсутствие поддержки этих связей может привести к разрушению модели, например, если атрибут класса,
использующийся в одном или нескольких представлениях, будет переименован. Чтобы избавиться от этих проблем, в REAL-IT для моделирования представлений было использован не профиль («легкое» (light) расширение метамодели по классификации MOF), а «тяжелое» (heavy) расширение метамодсли, т.с. введение в нее дополнительных элементов - классов, атрибутов и ассоциаций для моделирования представлений. Фрагмент метамодсли CASE-пакета REAL, описывающий это расширение, представлен на рис. 2.2.
Опишем это расширение поподробнее:
Для описания представлений в метамодель добавляется специальный класс «Представление» («View»). Этот класс является наследником класса «Classifier», что позволяет в любых контекстах использовать представления вместо классов.
Для определения набора классов, использующихся в представлении, в метемодель добавлен класс «Элемент представления» («ViewElement»). Фактически, он реализует отношение «многие ко многим» между классами и представлениями, однако при этом он является самостоятельной сущностью метамодели - это нужно для того, чтобы была возможность задать его имя (синоним класса в представлении), н, кроме того, позволяет производить
дальнейшее расширение модели, определяя для него стереотипы и пользовательские свойства.
Для определения ассоциаций между классами, входящими в представление (т.с. использующимися для его построения), в мстамодсль добавлен класс «Связь в представлении» («VicwConncctor»). Однако, вместо того, «лгобы связывать представления и ассоциации, он связывает элементы представления и ро~и ассоциации («AssociationEnd»). Такая связь необходима, поскольку один и тот
же класс может иметь много вхождений в представление, и если указать только факт использования ассоциации в представлении, то может возникнуть неоднозначность в определении того, какие именно элемент представления она связывает. Кроме того, ассоциация может входить в представление не полностью, а частично, т.с. представление может содержать только некоторые из концов ассоциации, в таком случае мы получаем «индуцированную» ассоциацию между представлением и классами исходной модели. Какие именно ассоциации входят в представление и каким именно образом (полностью или частично) можно определить по цепочке классов «ViewElcment» - «VicwConncctor» - «AssociationEnd», никаких дополнительных классов и ассоциаций для этого не требуется.
Являясь классом, представление может содержать все те же члены («Feature»), что и любой другой класс (что требуется, например, для описания вычислимых полей представлений в реляционной схеме). Однако, помимо них, представление может содержать и члены специального вида, являющиеся «ссылками» на члены классов, входящих в представление. Для их описания в мстамодсль добавлен класс «Член представления» («ViewFeature»). Множество членов представления, как и множество членов любого класса является упорядоченной последовательностью, в которой как «обычные» (описанные в UML) члены, так и вводимые нами члены представления MOiyr идти в произвольном порядке.
Описанные выше свойства предлагаемого расширения означают наличие ограничений на использование добавляемых в мстамодсль элементов. На языке ОСЬ эти ограничения можно описать следующим образом5:
context ViewConncctor inv:
VicwCanncctor.participant.rcffcrcncc.parcnts()-> includes (ViewConnector.AssociationEnd.participant)
context ViewFeaiuie inv:
ViewFeature.owner.ViewElement.parcnts()->
mcludes(ViewFcaturc.reffercncc.owner)
В приведенных 01раничеиия нспользуегся операция рагсШьО. применяемая к элементам типа Classifier. Мы будем определять эту операцию, как выдающую для класса множество классов, включающее сим класс и всех его наследников.