5.5. Углубленное моделирование классов

Дополнительные концепции моделирования включают:

• стереотипы,

• ограничения,

• производную информацию,

• видимость,

• ассоциативные классы,

• параметризованные классы и т.д.

Стереотип расширяет существующий элемент моделирования UML. Он вносит некоторые изменения в семантику существующего элемента. Стереотип не является новым элементом, а позволяет расширить и настроить метод. Существуют различные способы применения стереотипов. Некоторые распространенные стереотипы являются встроенными - они заранее определены в UML. Некоторые CASE-средства включают готовые пиктограммы для встроенных стереотипов. Большинство CASE-средств обеспечивают возможность создания новых пиктограмм по желанию аналитика.

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

Если ограничение является слишком длинным или же оно должно быть выражено с использованием трех или более графических символов, можно воспользоваться таким понятием UML, как примечание. Примечания может содержать текст ограничения, однако, в общем случае, оно может содержать любую информацию. Чтобы показать, что примечание является ограничением, его необходимо дополнительно обозначить как стереотип с помощью ключевого слова «constraint».

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

Видимость и инкапсуляция. В UML в качестве стандартных обозначений видимости приняты следующие знаки: + (для открытой), # (для защищенной ) и – (для закрытой) видимости. Знаки помещаются перед именем свойства. CASE-средства часто заменяют эти обозначения на свои собственные. На рис.5.2. представлен класс, изображенный с помощью CASE-средства Rational Software Architect (RSA). Открытые элементы класса изображены зеленым цветом, защищенные – желтым, закрытые – красным.

Рисунок 5.2. Изображение класса в RSA

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

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

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

Рисунок 5.3. Производный атрибут (/).

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

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

Рисунок 5.4. Производная ассоциация

Производную ассоциацию можно ввести т. к. кратность ассоциации между Order и Invoice равна 1 к 1.

Производная ассоциация не вносит в модель какой-либо новой информации. Всегда можно связать клиента (Customer) с определенным заказом (Order), отыскав один заказ для каждого счета-фактуры (Invoice), а затем одного клиента для каждого заказа.

Ассоциативный класс - ассоциация, которая сама является классом. Ассоциативный класс обычно используется в тех случаях, когда между двумя классами существует ассоциация “многие ко многим” и каждый экземпляр ассоциации (связь) обладает собственными значениями атрибутов. Чтобы обеспечить возможность хранить эти атрибуты, требуется класс - ассоциативный класс (рис.5.5.).

Рисунок 5.5. Ассоциативный класс

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

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

Постановка задачи для примера создает некоторые проблемы. Нам требуется класс для хранения подробной информации о сотруднике (Employee), а также класс для хранения информации об уровнях зарплаты (SalaryLevel). Проблема состоит в моделировании текущих назначений зарплаты работникам, а также хронологии этих назначений. На первый взгляд кажется естественным использовать ассоциативный класс. Но подобное решение неверно, т. к. у одного сотрудника в разные периоды времени может оказаться один уровень зарплаты (т. е. ключи emp_ID+level_id будут одинаковые, а остальные атрибут будут отличаться). Но никакие два объекта ассоциативного класса не могут иметь одинаковых составных ключей (т.е. одинаковых связей с объектами Employee и SalaryLevel). В этом случае лучше использовать материализованный класс (рис. 5.6.).

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

Рисунок 5.6. Материализованный класс