М. Фаулер, К. Скотт - UML Основы (1114905), страница 19
Текст из файла (страница 19)
На рис. 5.4 и 5.5 можно увидеть различные формы схем именования объектов в языке БМЬ. Общая форма имеет вид <ИмяОбъекта с ИмяКласса>, где либо имя объекта, либо имя класса могут отсутствовать. При отсутствии имени объекта необходимо оставить двоеточие, чтобы было понятно, что это имя класса, а не объекта. Таким образом, имя «строка Макаллана: Строка Заказа» означает, что экземпляр класса Строка Заказа называется строка Макаллана (именно такой порядок записи имен мне особенно нравится). Я стараюсь именовать объекты в стиле языка Зша11$а1)г, который я использовал в диаграммах последовательности.
(Такая схема находится в соответствии с нотацией языка ПМЬ, поскольку «некоторыйОбъект» вполне подходит для имени некоторого объекта.) 88 Глава 5. Диаграммы взаимодействия Сравнение диаграмм последовательности и диаграмм кооперации Разные разработчики имеют различные мнения по поводу выбора вида диаграммы взаимодействия. Я предпочитаю диаграмму последовательности, поскольку в ней сделан акцент именно на последовательности сообщений: легче наблюдать порядок, в котором происходят различные события. Другие предпочитают диаграммы кооперации, поскольку можно использовать схему пространственного расположения объектов для показа их статических взаимосвязей.
Одним из главных свойств любой формы диаграммы взаимодействия является их простота. Взглянув на диаграмму, сразу можно увидеть все сообщения. Однако если вы попытаетесь изобразить нечто более сложное, чем единственный последовательный процесс без множества условных переходов или циклов выполнения, то такая попытка закончится неудачей. Одной нз проблем при построении диаграмм взаимодействия являются возможные неудобства, связанные с представлением альтернативных ветвей процесса. Попытка изобразить альтернативы приводит к усложнению диаграмм и их многократной переработке. Поэтому для представления поведения я считаю очень полезными СВС-карточки.
СВС-карточки В конце 80-х годов одним из крупнейших центров объектной технологии были исследовательские лаборатории фирмы ТеИгоп1х в Портленде, штат Орегон. В этих лабораториях была сосредоточена некоторая часть основных пользователей языка Вша11- Фа1)с, и многие из главных идей объектной технологии родились именно там. Здесь же работали два таких известных программиста и специалиста по языку Вта1ВаЖ„как Уорд Каннингхем и Кент Бек. Они и сейчас занимаются методами обучения объектному языку Вта1ВаПс.
Результатом этой работы явился достаточно простой метод под названием «СВС-карточки» (Класс- Ответственность-Кооперация). В то время как большинство аналитиков использовали для разработки моделей диаграммы, Уорд представлял описание классов на небольших карточках размером 4 х 6. Причем вместо атрибутов и методов класса он записывал на этих карточках ответственности (геэропэ(Ъ11Шез). Итак, что же такое ответственностьг По существу, это высокоуровневое описание целевого назначения класса.
Идея заключается в том, чтобы абстрагироваться от описания конкретных элементов данных и процессов и вместо этого несколькими предло- Сравнение диаграмм последовательности и диаграмм кооперации женнямн сформулировать целевое назначение класса. Небольшой размер карточки был выбран намеренно, чтобы описание было предельно кратким (рнс. 5.6). Рис. о.в. Карточка Класс-Ответственность-Кооперация (СКС-сага) Вторая буква «С» соответствует кооперации классов.
Для каждой ответственности вы показываете, с какими другими классамн необходимо кооперироваться для ее реализации. Это дает вам некоторое представление о связях между классами, хотя н на достаточно высоком уровне, Одно нз главных достоинств СВС-карточек заключается в том, что онн способствуют более оживленному обсуждению модели разработчиками. Прн работе над неким вариантом нспользовання рассмотренные в атой главе диаграммы взаимодействия могут только замедлить процесс разработки, если нужно показать особенности реализации классов.
Обычно вам необходимо рассмотреть альтернативы, а указанные диаграммы не позволяют наглядно нх представить. С помощью СКС-карточек моделирование взаимодействия осуществляется посредством сортировки карточек по пачкам, а также нх удаления. Это позволяет разработчнкам быстро рассмотреть различные альтернативы.
По мере того как формируются представления относительно ответственностн классов, нх записывают на карточках. Концентрация внимания на ответственностях весьма важна, поскольку позволяет избавиться от рассмотрения классов как тупых храннтелей данных н помогает команде разработчиков понять особенностн высокоуровневого поведения каждого класса. Ответственность может соответствовать операции, атрибуту нлн (что более вероятно) неопределенному набору атрибутов и операций. Наиболее распространенная ошибка разработчиков, с которой мне приходятся сталкиваться, заключается в формировании слишком длинных списков низкоуровневых ответственносФей. 90 Глава 5.
Диаграммы взаимодействия Такая работа лишена смысла. Все ответственности должны легко помещаться на карточке. С моей точки зрения карточка, содержащая более трех ответственностей, вызывает дополнительные вопросы. В этом случае следует либо разделить класс на части, либо рассматривать ответственности на более высоком уровне. Когда использовать Сйс-карточки Использование СВС-карточек помогает моделировать взаимодействие между классами, в частности, показать особенности выполнения некоторого сценария.
Выяснив для себя детали взаимодействия, можно приступить к его документированию в форме диаграмм взаимодействия. Использование ответственностей поможет вам сформулировать основные ответственности класса. А они являются полезным средством для приведения в порядок описаний классов. Многие аналитики рекомендуют пользоваться методикой проигрывания ролей, когда каждый разработчик в команде играет роль одного или нескольких классов.
Я никогда не видел, чтобы Уорд и Кент делали это, но сама идея этой методики мне нравится. Где найти дополнительную информацию Сэдли, Каннингхем и Бек никогда не писали книг о СВС, однако можно обратиться к их статье (Бек и Каннингхем, 1989) в Интернете по адресу: И~рт//с2.сот/г(ос/оорз(а89/рарет.Итпй Данный метод наилучшим образом описан в книге Вефс-Брок (МГ1г1в-Вгос)т), 1990 (46), в которой, по существу, изложена полная нотация использования ответственностей. Это довольно старая книга по объектно-ориентированному подходу, однако она хорошо себя зарекомендовала.
Когда следует использовать диаграммы взаимодействия Диаграммами взаимодействия следует пользоваться в том случае, когда вы хотите описать поведение нескольких объектов в рамках одного варианта использования. Диаграммы взаимодействия удобны для изображения кооперации объектов и вовсе не так хороши для точного представления их поведения.
Если вы хотите описать поведение единственного объекта во многих вариантах использования, то следует применять диаграмму состояний (см. главу 8). Если же возникает необходимость описать поведение, охватывающее несколько вариантов использования или несколько нитей процесса, следует рассматривать диаграмму деятельности (см. главу 9). Диаграммы классов: дополнительные понятия Описанные ранее в главе 4 понятия соответствуют основной нотации диаграмм классов.
Именно зти понятия нужно постичь и освоить прежде всего, поскольку они на 90% удовлетворят ваши потребности при построении диаграмм классов. Однако диаграммы классов могут содержать множество нотаций для представления различных дополнительных понятий. Я сам использую их не слишком часто, но в отдельных случаях они оказываются весьма удобными. Рассмотрим последовательно эти дополнительные понятия, обращая внимание на особенности их применения. Однако при этом следует помнить, что их использование не является обязательным, и многим разработчикам удается вложить достаточно много смысла в диаграммы классов и без этих дополнительных понятий. Возможно, при чтении этой главы вы столкнетесь с некоторыми трудностями.
Могу вас обрадовать: вы можете без всякого ущерба пропустить зту главу при первом чтении книги и верйуться к ней позже. Стереотипы Стереотипы являются механизмом расширения ядра языка \ПП.. Если для построения модели необходим некоторый элемент, и он отсутствует в языке ОМЕ, но похож на какую-либо конструкцию послед- 92 Глава 6. Диаграммы классов: дополнительные понятия него, можно попытаться рассмотреть данный элемент в качестве стереотипа известной конструкции ЬтМЬ.
Примером подобной ситуации является интерфейс. В языке ПМЬ интерфейс представляет собой класс, который имеет только общедоступные операции без тел методов или атрибутов. Это соответствует интерфейсам в языках дача, СОМ и СОВВА. Поскольку интерфейс является частным случаем класса, он определяется как стереотип класса. (Подробнее об этом см. в разделе «Интерфейсы и абстрактные классы» далее в этой главе.) Стереотипы обычно записываются с помощью текста, заключенного в кавычки (например, »интерфейс»), однако они могут также изображаться с помощью пиктограммы стереотипа. Многие расширения ядра языка 1)МЬ можно описать в виде совокупности стереотипов. В рамках диаграмм классов могут существовать стереотипы классов, ассоциаций или обобщений. Вы можете понимать стереотипы как подтипы следующих типов метамодели: Класса„Ассоциации и Обобщения.
При использовании языка 1)МЬ аналитикам иногда бывает трудно разобраться в разнице между ограничениями и стереотипами. Если вы помечаете класс как абстрактный, то что это — ограничение или стереотип"г В существующих официальных документах это называется ограничением, но нужно сознавать, что различие между ним и стереотипом весьма размыто. Именно поэтому нет ничего удивительного в том, что подтипы зачастую являются более ограниченными, чем супертипы. Работа ОМО в этом направлении сосредоточена на создании так называемых профилей ()МЬ. Профиль представляет собой часть языка 1)МЬ и расширяет его с помощью стереотипов, предназначенных для специальных целей.
Начало этой работы ОМО положено разработкой профиля реального времени и профиля языка определения интерфейсов (1РЬ) СОВВА. Очевидно, что работа в зтом направлении будет продолжена. Диаграмма объектов Диаграмма объектов представляет собой мгновенный снимок объектов системы с точки зрения времени. Поскольку на ней изображаются экземпляры классов, но не сами классы, диаграмма объектов часто называется диаграммой экземпляров. Для представления варианта конфигурации объектов может быть использована некоторая диаграмма экземпляров. (На рис. 6.1 изображено некоторое множество классов, а на рис. 6.2 — соответствующее множество объектов.) Это может оказаться весьма полезным в случае сложных связей между объектами.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
