Диаграмма классов UML

Для чего используется техника креативности

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

План действий

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

После ознакомления с другими разделами («Пример», «Применение») вы можете попробовать свои силы в самостоятельном составлении диаграмм последовательности.

Замечания (описание)

Здесь представлен основной набор символов диаграммы последовательности, необходимый для того, чтобы суметь прочитать диаграмму. После ознакомления с другими разделами («Пример», «Применение») вы сможете составлять диаграммы последовательности самостоятельно!

Термин	Изображение	Описание
Функциональность		Функциональность применяется в качестве основного термина, описывающего и свойства, и операции класса.
Свойства (атрибуты и ассоциации)		Свойства представляют структурную функциональность класса. В первом приближении можно рассматривать свойства как поля класса. Как мы увидим позднее, в действительности это не так просто, но вполне приемлемо для начала. Свойства представляют единое понятие, воплощающееся в двух совершенно различных сущностях: в атрибутах и в ассоциациях. Хотя на диаграмме они выглядят совершенно по разному, в действительности это одно и то же.
Кратность		Кратность свойства обозначает количество объектов, которые могут заполнять данное свойство. Чаще всего встречаются следующие кратности: • 1 (Заказ может представить только один клиент.) • 0..1 (Корпоративный клиент может иметь, а может и не иметь единственного торгового представителя.) • * (Клиент не обязан размещать заказ, и количество заказов не ограничено. Он может разместить ноль или более заказов.)
Операции		Операции (operations) представляют собой действия, реализуемые некоторым классом. Существует очевидное соответствие между операциями и методами класса.
Обобщение		Типичный пример обобщения (generalization) включает индивидуального и корпоративного клиентов некоторой бизнес системы. Несмотря на определенные различия, у них много общего. Одинаковые свойства можно поместить в базовый класс Customer (Клиент, супертип), при этом класс Personal Customer (Индивидуальный клиент) и класс Corporate Customer (Корпоративный клиент) будут выступать как подтипы.
Примечания и комментарии		Примечания – это комментарии на диаграммах. Примечания могут существовать сами по себе или быть связаны пунктирной линией с элементами, которые они комментируют. Они могут присутствовать на диаграммах любого типа.
Зависимость		Считается, что между двумя элементами существует зависимость (dependency), если изменения в определении одного элемента (сервера) могут вызвать изменения в другом элементе (клиенте). В случае классов, зависимости появляются по разным причинам: один класс посылает сообщение другому классу; один класс владеет другим классом как частью своих данных; один класс использует другой класс в качестве параметра операции. Если класс изменяет свой интерфейс, то сообщения, посылаемые этому классу, могут стать недействительными.
Правила ограничений		Язык UML разрешает использовать для описания ограничений все что угодно. При этом необходимо лишь придерживаться правила: ограничения следует помещать в фигурные скобки ({}).

Как применять технику креативности

Диаграммы классов составляют фундамент UML, и поэтому их постоянное применение является условием достижения успеха.

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

Приведем несколько полезных советов.

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

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

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

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

Как научиться

Здесь мы попытались предоставить как можно более простой способ изучения диаграммы классов языка UML.

Как и многие другие языки он использует для описания набор знаков. Смысл этих знаков вы найдете в таблице в разделе «Замечания (описание)». Каждый знак имеет свое наименование (термин) и написание. Также каждый термин снабжен кратким пояснением, чтобы быстро уяснить его основную суть.

Далее мы бы рекомендовали перейти в раздел «Пример», чтобы попробовать свои силы в чтении разных диаграмм. Затем стоит изучить раздел «Применение», так как, хотя и количество типов диаграмм в UML невелико, максимум преимуществ от их использования вы сможете получить только если будете применять соответствующие диаграммы по назначению.

Пример использования

Диаграмма классов UML (ЮМЛ) описывает типы объектов системы и различного рода статические отношения, которые существуют между ними. На диаграммах классов отображаются также свойства классов, операции классов и ограничения, которые накладываются на связи между объектами. В UML термин функциональность (feature) применяется в качестве основного термина, описывающего и свойства, и операции класса.

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

Свойства

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

Рис. 3.1. Простая диаграмма класса

Атрибуты

Атрибут описывает свойство в виде строки текста внутри прямоугольника класса. Полная форма атрибута:
видимость имя: тип кратность = значение по умолчанию {строка свойств}
Например: имя: String [1] = «Без имени» {readOnly}
Обязательно только имя.

Ассоциации

Другая ипостась свойства – это ассоциация. Значительная часть информации, которую можно указать в атрибуте, появляется в ассоциации.

Ассоциация – это непрерывная линия между двумя классами, направленная от исходного класса к целевому классу. Имя свойства (вместе с кратностью) располагается на целевом конце ассоциации. Целевой конец ассоциации указывает на класс, который является типом свойства. Большая часть информации в обоих представлениях одинакова, но некоторые элементы отличаются друг от друга. В частности, ассоциация может показывать кратность на обоих концах линии.

Естественно, возникает вопрос: «Когда следует выбирать то или иное представление?». Как правило, при помощи атрибутов обозначают небольшие элементы, такие как даты или логические значения, – главным образом, типы значений, – а ассоциации для более значимых классов, таких как клиенты или заказы.

Кратность

Кратность свойства обозначает количество объектов, которые могут заполнять данное свойство. Чаще всего встречаются следующие кратности:
• 1 (Заказ может представить только один клиент.)
• 0..1 (Корпоративный клиент может иметь, а может и не иметь единственного торгового представителя.)
• * (Клиент не обязан размещать заказ, и количество заказов не ограничено. Он может разместить ноль или более заказов.)

В большинстве случаев кратности определяются своими нижней и верхней границами, например 2..4 для игроков в канасту. Нижняя граница может быть нулем или положительным числом, верхняя граница представляет собой положительное число или * (без ограничений). Если нижняя и верхняя границы совпадают, то можно указать одно число; поэтому 1 эквивалентно 1..1. Поскольку это общий случай, * является сокращением 0..*.

При рассмотрении атрибутов вам могут встретиться термины, имеющие отношение к кратности.
• Optional (необязательный) предполагает нулевую нижнюю границу.
• Mandatory (обязательный) подразумевает, что нижняя граница равна или больше 1.
• Single- valued (однозначный) – для такого атрибута верхняя граница равна 1.
• Multivalued (многозначный) имеет в виду, что верхняя граница больше 1; обычно *.

Если свойство может иметь несколько значений, я предпочитаю употреблять множественную форму его имени. По умолчанию элементы с множественной кратностью образуют множество, поэтому если вы просите клиента разместить заказы, то они приходят не в произвольном порядке. Если порядок заказов в ассоциации имеет значение, то в конце ассоциации необходимо добавить {ordered}. Если вы хотите разрешить повторы, то добавьте {non-unique}. (Если желательно явным образом показать значение по умолчанию, то можно использовать {unordered} и {unique}.) Встречаются также имена для unordered, non-unique, ориентированные на коллекции, такие как {bag}.

Кратность атрибута по умолчанию равна [1]. Хотя это и верно для метамодели, нельзя предполагать, что если значение кратности для атрибута на диаграмме опущено, то оно равно [1], поскольку информация о кратности на диаграмме может отсутствовать. Поэтому рекомендуется указывать кратность явным образом, если эта информация важна.

Двунаправленные ассоциации

До сих пор мы говорили об однонаправленных ассоциациях. К другому распространенному типу ассоциаций относится двунаправленная ассоциация, например, показанная на рис. 3.4.

Двунаправленная ассоциация – это пара свойств, связанных в противоположных направлениях. Класс Car (Автомобиль) имеет свойство owner:Person[1], а класс Person личность) имеет свойство cars:Car[*].
(Обратите внимание, что мы использовали множественную форму имени свойства cars, а это соглашение общепринятое, но ненормативное.)

Обратная связь между ними подразумевает, что если вы следуете обоим свойствам, то должны вернуться обратно к множеству, содержащему вашу исходную точку. Например, если я начинаю с конкретной модели MG Midget, нахожу ее владельца, а затем смотрю на множество принадлежащих ему машин, то оно должно включать модель Midget, с которой мы начали.

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

Большинство разработчиков объектов предпочитают использовать имя свойства, так как оно больше соответствует функциональным назначениям и операциям.
Некоторые разработчики тем или иным способом именуют каждую ассоциацию. Мы предпочитаем давать имя ассоциации, только если это улучшает понимание. Слишком часто встречаются такие имена, как «has» (имеет) или «is related to» (связан с).

На рис. 3.4 двунаправленная природа ассоциации подчеркивается стрелками на обоих концах ассоциации. На рис. 3.5 стрелок нет; в языке UML эта форма применяется либо для обозначения двунаправленной ассоциации, либо когда направление отношения не показывается.

Операции

Операции (operations) представляют собой действия, реализуемые некоторым классом. Существует очевидное соответствие между операциями и методами класса. Обычно можно не показывать такие операции, которые просто манипулируют свойствами, поскольку они и так подразумеваются.
Полный синтаксис операций в языке UML выглядит следующим образом:

видимость имя (список параметров) : возвращаемый тип {строка свойств}

• Метка видимости обозначает, относится ли операция к открытым (+) (public) или к закрытым ( ) (private);
• Имя – это строка.
• Список параметров – список параметров операции.
• Возвращаемый тип – тип возвращаемого значения, если таковое есть.
• Строка свойств – значения свойств, которые применяются к данной операции.

Параметры в списке параметров обозначаются таким же образом, что и для атрибутов. Они имеют вид:

направление имя: тип = значение по умолчанию

• Имя, тип и значение по умолчанию те же самые, что и для атрибутов.
• Направление обозначает, является ли параметр входным (in), выходным (out) или тем и другим (inout). Если направление не указано, то предполагается in.
Например, в счете операция может выглядеть так:

+ balanceOn (date: Date) : Money

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

Обобщение

Типичный пример обобщения (generalization) включает индивидуального и корпоративного клиентов некоторой бизнес системы. Несмотря на определенные различия, у них много общего. Одинаковые свойства можно поместить в базовый класс Customer (Клиент, супертип), при этом класс Personal Customer (Индивидуальный клиент) и класс Corpo rate Customer (Корпоративный клиент) будут выступать как подтипы.

Этот факт служит объектом разнообразных интерпретаций в моделях различных уровней. На концептуальном уровне мы можем утверждать, что Корпоративный клиент представляет собой подтип Клиента, если все экземпляры класса Корпоративный клиент по определению являются также экземплярами класса Клиент. Таким образом, класс Корпоративный клиент представляет собой частную разновидность класса Клиент. Основная идея заключается в следующем: все, что нам известно о классе Клиент (ассоциации, атрибуты, операции), справедливо также и для класса Корпоративный клиент.

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

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

Примечания и комментарии

Примечания – это комментарии на диаграммах. Примечания могут существовать сами по себе или быть связаны пунктирной линией с элементами, которые они комментируют (рис. 3.6). Они могут присутствовать на диаграммах любого типа.

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

Зависимость

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

По мере роста систем необходимо все более и более беспокоиться об управлении зависимостями. Если зависимости выходят из под контроля, то каждое изменение в системе оказывает действие, нарастающее волнообразно по мере увеличения количества изменений. Чем больше волна, тем труднее что нибудь изменить.

UML позволяет изобразить зависимости между элементами всех типов. Зависимости можно использовать всякий раз, когда надо показать, как изменения в одном элементе могут повлиять на другие элементы.

На рис. 3.7 показаны зависимости, которые можно обнаружить в многоуровневом приложении. Класс Benefits Window (Окно льгот) – это пользовательский интерфейс, или класс представления, зависящий от класса Employee (Сотрудник). Класс Employee – это объект предметной области, который представляет основное поведение системы, в данном случае бизнес- правила. Это означает, что если класс Employee изменяет свой интерфейс, то, возможно, и класс Benefits Window также должен измениться.

Здесь важно то, что зависимость имеет только одно направление и идет от класса представления к классу предметной области. Таким образом, мы знаем, что имеем возможность свободно изменять класс Benefits Window, не оказывая влияния на объект Employee или другие объекты предметной области. Я понял, что строгое разделение логики представления и логики предметной области, когда представление зависит от предметной области, но не наоборот, – это ценное правило, которому стоит следовать.

Второй существенный момент этой диаграммы: здесь нет прямой зависимости двух классов Data Gateway (Шлюз данных) от Benefits Window. Если эти классы изменяются, то, возможно, должен измениться и класс Employee. Но если изменяется только реализация класса Employee, а не его интерфейс, то на этом изменения и заканчиваются.
UML включает множество видов зависимостей, каждая с определенной семантикой и ключевыми словами. Базовая зависимость, которую я здесь обрисовал, с моей точки зрения, наиболее полезна, и обычно мы используем ее без ключевых слов. Чтобы сделать ее более детальной, вы можете добавить соответствующее ключевое слово (табл. 3.1).

Базовая зависимость не является транзитивным отношением. Примером транзитивного отношения может служить отношение «эта борода больше». Если у Джима борода больше, чем у Гради, а борода Гради больше бороды Айвара, то мы можем сделать вывод, что у Джима борода больше, чем у Айвара. Некоторые типы зависимостей, такие как замещение, являются транзитивными, но в большинстве случаев существует значительное расхождение между прямыми и обратными зависимостями, как показано на рис. 3.7.

Многие отношения UML предполагают зависимость. Направленная ассоциация от Order к Customer означает, что Order зависит от Customer. Подкласс зависит от своего суперкласса, но не наоборот.
Вашим основным правилом должна стать минимизация зависимостей, особенно когда они затрагивают значительную часть системы. В частности, будьте осторожны с циклами, поскольку они могут привести к циклическим изменениям. Мы не слишком строго придерживаемся этого правила. Мы не имеем в виду взаимные зависимости между тесно связанными классами, но стараемся избегать циклов на более высоких уровнях, особенно между пакетами.

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

В самом общем случае мы используем зависимости с классами для иллюстрации транзитивного отношения, такого, когда один объект передается другому в качестве параметра. Иногда их применяют с ключевыми словами «parameter» (параметр), «local» (локальный) и «global» (глобальный). Эти ключевые слова можно увидеть на ассоциациях в моделях UML 1, и в этом случае они обозначают транзитные связи, а не свойства. Эти ключевые слова не входят в UML 2.

Зависимости можно обнаружить, просматривая программу, вот почему эти инструменты идеальны для анализа зависимостей. Применение инструментария для обращения схем зависимостей – наиболее полезный способ применения этого раздела UML.

Правила ограничений

При построении диаграмм классов большая часть времени уходит на представление различных ограничений. На рис. 3.1 показано, что Заказ (Order) может быть сделан только одним единственным Клиентом (Customer). Из этой диаграммы классов также следует, что каждая Line Item (Позиция заказа) рассматривается отдельно: вы можете заказать 40 коричневых, 40 голубых и 40 красных штучек, но не 120 штук вообще. Далее диаграмма утверждает, что Корпоративные клиенты располагают кредитами, а Индивидуальные клиенты – нет.

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

Язык UML разрешает использовать для описания ограничений все что угодно. При этом необходимо лишь придерживаться правила: ограничения следует помещать в фигурные скобки ({}). Можно употреблять разговорный язык, язык программирования или формальный объектный язык ограничений UML (Object Constraint Language, OCL), базирующийся на исчислении предикатов. Формальное написание позволяет избежать риска неоднозначного толкования конструкций разговорного языка. Однако это приводит к возможности недоразумений из-за непрофессионального владения OCL пишущими и читающими.

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

Подписывайтесь на новости сайта, форму подписки вы можете найти в правой колонке сайта.

Если вы хотите научиться работать на фрилансе профессионально, приглашаем на курс «Как зарабатывать на фрилансе».