Читальный зал -->  Диаграммы параллельных состояний 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [ 25 ] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

Сравнение диаграмм последовательности и диаграмм кооперации

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

Имя класса

Ответственность Зэказ Кооперация
Проверить наличие товаров	Строка заказа
Определить цену
Проверить факт оплаты	Клиент
Отправить по адресу доставки

Рис. 5.6. Карточка Класс-Ответственность-Кооперация (CRC-card)

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

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

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

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

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

Когда использовать CRC-карточки

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

Использование ответственностей поможет вам сформулировать основные ответственности класса. А они являются полезным средством для приведения в порядок описаний классов.

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

Где найти дополнительную информацию

Сэдли, Каннингхем и Бек никогда не писали книг о CRC, однако можно обратиться к их статье (Бек и Каннингхем, 1989) в Интернете по адресу: http: c2.com/doc/oopsla89/paper.html. Данный метод наилучшим образом описан в книге Вёфс-Брок (Wirfs-Brock), 1990 [46], в которой, по существу, изложена полная нотация использования ответственностей. Это довольно старая книга по объектно-ориентированному подходу, однако она хорошо себя зарекомендовала.

Когда следует использовать диаграммы взаимодействия

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

Если вы хотите описать поведение единственного объекта во многих вариантах использования, то следует применять диаграмму состояний (см. главу 8). Если же возникает необходимость описать поведение, охватывающее несколько вариантов использования или несколько нитей процесса, следует рассматривать диаграмму деятельности (см. главу 9).

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

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

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

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

Стереотипы

Стереотипы являются механизмом расширения ядра языка UML. Если для построения модели необходим некоторый элемент, и он отсутствует в языке UML, но похож на какую-либо конструкцию послед-

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [ 25 ] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

ООО «Мягкий Дом» - это Отечественный производитель мебели. Наша профильная продукция - это диваны еврокнижка. Каждый диван можем изготовить в соответствии с Вашими пожеланияи (размер, ткань и материал). Осуществляем бесплатную доставку и сборку.



Звоните! Ежедневно!
 (926)274-88-54 
Продажа и изготовление мебели.

Копирование контента сайта запрещено.
Авторские права защищаются адвокатской коллегией г. Москвы.