Главная » UML » Диаграммы классов: дополнительные понятия UML

0

Описанные ранее в главе 4 понятия соответствуют основной нотации диаграмм классов. Именно эти понятия нужно постичь и освоить прежде всего, поскольку они на 90% удовлетворят ваши потребности при построении диаграмм классов.

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

Возможно, при чтении этой главы вы столкнетесь с некоторыми трудностями. Порадую вас: эту главу можно без всякого ущерба пропустить при первом чтении книги и вернуться к ней позже.

Ключевые слова

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

Примером может служить интерфейс. Интерфейс (interface) в UMLJ (стр. 96) означает класс, в котором все операции открытые и не имеют тел методов. Это соответствует интерфейсам в Java, COM (Component Object Module) и CORBA. Поскольку это специальный вид класса, то он изображается с помощью пиктограммы с ключевым словом «inter-

 

face». Обычно ключевые слова представляются в виде текста, заключенного во французские кавычки («елочки»). Вместо ключевых слов можно использовать специальные значки, но тем самым вы заставляете всех запоминать их значения.

Некоторые ключевые слова, такие как {abstract}, заключаются в фигурные скобки. В действительности никогда не понятно, что формально должно быть в кавычках, а что в фигурных скобках. К счастью, если вы ошибетесь, то заметят это только настоящие знатоки UML. Но лучше быть внимательными.

Некоторые ключевые слова настолько общеупотребительны, что часто заменяются сокращениями: «interface» часто сокращается до «I», a {abstract} – до {А}. Такие сокращения очень полезны, особенно на белых досках, однако их применение не стандартизовано. Поэтому если вы их употребляете, то не забудьте найти место для расшифровки этих обозначений.

В UML 1 кавычки применялись в основном для стереотипов. В UML версии 2 стереотипы определены очень кратко, и разговор о том, что является стереотипом, а что нет, выходит за рамки этой книги. Однако из-за UML 1 многие разработчики употребляют термин «стереотип» в качестве синонима ключевого слова, хотя теперь это неверно.

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

 

Ответственности

 

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

Статические операции и атрибуты

 

Если в UML ссылаются на операции и атрибуты, принадлежащие классу, а не экземпляру класса, то они называются статическими. Это эквивалентно статическим членам в С-подобных языках. На диаграмме класса статические элементы подчеркиваются (рис. 5.2).

 

 

Агрегация и композиция

К одним из наиболее частых источников недоразумений в UML -можно отнести агрегацию и композицию. В нескольких словах это можно объяснить так; Агрегация (aggregation) – это отношение типа «часть целого». Точно так же можно сказать, что двигатель и колеса представляют собой части автомобиля. Звучит вроде бы просто, однако при рассмотрении разницы между агрегацией и композицией возникают определенные трудности.

До появления языка UML вопрос о различии между агрегацией и композицией у аналитиков просто не возникал. Осознавалась подобная неопределенность или нет, но свои работы в этом вопросе аналитики совсем не согласовывали между собой. В результате многие разработчики считают агрегацию важной, но по совершенно другой причине. Язык UML включает агрегацию (рис. 5.3) но семантика ее очень расплывчата. Как говорит Джим Рамбо (Jim Rumbaugh); «Можно представить себе агрегацию как плацебо для моделирования» [40].

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

 

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

Вы заметите, что на рис 5.4 я не показываю обратные кратности. В большинстве случаев, как и здесь, они равны 0..1. Единственной альтернативой является значение 1, когда класс-компонент разработан таким образом, что у него только один класс-владелец.

Правило «нет совместного владения» является ключевым в композиции. Другое допущение состоит в том, что если удаляется многоугольник (Polygon), то автоматически должны удалиться все точки (Points), которыми он владеет.

Композиция – это хороший способ показать свойства, которыми владеют по значению, свойства объектов-значений (стр. 100) или свойства, которые имеют определенные и до некоторой степени исключительные права владения другими компонентами. Агрегация совершенно не имеет смысла; поэтому я не рекомендовал бы применять ее в диаграммах. Если вы встретите ее в диаграммах других разработчиков, то вам придется покопаться, чтобы понять их значение. Разные авторы и команды разработчиков используют их в совершенно разных целях.

 

Производные свойства

 

Производные свойства (derived properties) могут вычисляться на основе других значений. Говоря об интервале дат (рис. 5.5), мы можем рассуждать о трех свойствах: начальной дате, конечной дате и количестве дней за данный период. Эти значения связаны, поэтому мы можем сказать, что длина является производной двух других значений.

С точки зрения программного обеспечения образование производных можно интерпретировать двумя различными путями. Можно использовать образование производных для обозначения различия между вычисляемым и хранимым значениями. В этом случае, глядя на рис. 5.5,

 

мы скажем, что начальная (start) и конечная (end) даты хранятся, а длина (length) вычисляется. И хотя это наиболее распространенное применение, меня это не очень привлекает, поскольку слишком раскрывает внутреннее устройство класса DateRange (Интервал дат).

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

Образование производных может быть применено к свойствам с помощью ассоциаций. В этом случае вы просто отмечаете имя символом «/»,

 

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

По теме:

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