Главная » UML » Полные и неполные ограничения классификатора

0

 

В предыдущих выпусках «UML. Основы» было отмечено, что ограничение {complete} (полный) для некоторого обобщения устанавливает, что все экземпляры супертипа должны быть также экземпляром некоторого подтипа в данном разбиении. Вместо этого в языке UML версии 1.1 определено ограничение {complete}, которое указывает лишь на то, что соответствующее разбиение отражает все подтипы. А это совсем не то же самое. Я обнаружил множество несоответствий в интерпретации этого ограничения, поэтому вам следует обратить на это внимание. Если вы хотите показать, что все экземпляры супертипа должны быть экземпляром одного из подтипов, то во избежание недоразумений я советую использовать другое ограничение. В настоящее время я применяю ограничение {mandatory} (обязательный).

 
Композиция

 

Применение композиции в языке UML версии 1.0 означало, что эта связь неизменна (immutable) или заморожена (frozen), по крайней мере, для компонентов с одним значением. Это ограничение больше не является частью определения композиции.

 

Неизменность и замороженность

 

Язык UML определяет ограничение {frozen} (замороженный) для указания неизменяемости ролей ассоциации. Как определено в настоящее время, это ограничение не может быть применено к атрибутам или классам, В своей текущей работе вместо неизменности я употребляю термин frozen, тем самым я могу применять это ограничение к ролям ассоциаций, классам и атрибутам.

 
Возвраты на диаграммах последовательности

 

В UML 1.0 обратное сообщение (или возврат) на диаграмме последовательности вместо сплошной стрелки обозначалось обычной стрелкой (см. предыдущее издание). Это привело к некоторым трудностям, поскольку данное различие трудно заметить, и оно легко приводит к недоразумениям. В UML 1.1 возвраты изображаются пунктирной линией со стрелкой, что мне нравится больше, поскольку делает возвраты намного более очевидными, (Именно поэтому в своей книге «Паттерны анали-

 

за» [16] я использовал пунктирные возвраты, что представляется мне весьма важным.) Для последующего применения возвратов можно назначить им имена вида enoughStock :=check().

 

Использование термина «Role»

 

В языке UML версии 1.0 термин роль (role) в основном указывал направление некоторой ассоциации (см. предыдущее издание). В языке UML версии 1.1 данное определение рассматривается как роль ассоциации (association role). Помимо нее существует роль кооперации (collaboration role), то есть роль, исполняемая некоторым экземпляром класса в кооперации. Версия UML1.1 придает кооперации еще большую выразительность, и похоже, что такое толкование понятия «роль» может стать ведущим.

 

Источник: Фаулер М.UML. Основы, 3-е издание. – Пер. с англ. – СПб: Символ-Плюс, 2006. – 192 с.,ил.

По теме:

  • Комментарии