М. Фаулер, К. Скотт - UML Основы (1114905), страница 26
Текст из файла (страница 26)
Кооперация представляет собой имя, которое присваивается взаимодействию двух и более классов. Обычно подобное взаимодействие изображается на диаграмме взаимодействия. Так, например, диаграмма последовательности на рис. 7.3 представляет кооперацию Организация Продажи. в Рие. 7.3. Диаграмма последовательности длл организации ародажи 124 Глава 7. Пакеты и кооперации Эта кооперация может показывать выполнение операции или реализацию варианта использования. Кооперации можно моделировать до решения о том, какие операции они будут в себя включать. Кооперация может быть описана более чем одной диаграммой взаимодействия, на каждой из которых показывается отдельная линия поведения.
Можно также добавить диаграмму классов, чтобы показать классы, участвующие в заданной кооперации (рис. 7.4). Рис. 7.4. Диаграмма классов для кооперации организации ородазии В дополнение к использованию коопераций в пакете кооперации можно применять для представления общего поведения совокупности пакетов. Если задать вопрос о взаимодействии базы данных, то можно в качестве ответа изобразить несколько пакетов и классов с взаимосвязями между ними. Такое представление поможет понять, как все это работает, хотя взаимодействие базы данных может оказаться лишь одним из аспектов этих пакетов и классов.
Можно усовершенствовать это представление посредством определения кооперации взаимодействия базы данных. В рамках этой кооперации можно изобразить только релевантные аспекты классов, а диаграммы взаимодействия покажут, как они работают. Часто можно столкнуться с ситуацией, при которой одна и та же кооперация используется различными классами в системе. При этом в каждый момент времени основные особенности поведения этих классов идентичны, но классы и операции имеют различные имена, и могут существовать лишь небольшие различия в их реализации.
Данную ситуацию можно представить посредством параметризованной кооперации. Сначала рисуется диаграмма, подобная рис. 7.5, где показаны разные роли, которые исполняют различные объекты в данной кооперации. (Заметим, что классы на этой диаграмме не являются реальными классами системы; в действительности они являются ролями этой кооперации.) Затем следует добавить диаграммы взаимодействия, чтобы показать особенности взаимодействия этих ролей. 125 Кооперации г — — — — — — — — ч ! покупатель, продмзц, партия, зввз ~ ь Продажа l 1 Покупатель Заказ / 1 1 продавец Про1юаец Парка l 1 l г Рис.
7.$. Параметризоеанная кооперация Продажа Далее можно показать, как множество классов участвует в этой кооперации, нарисовав диаграмму, подобную рис. 7.6. пскупзтзпь, продзпец пцппя~. 1 К Продажа т Рис. 7.6. Использование кооперации Продажа В языке Т)МЬ используется также термин образец (раззегп) как синоним параметризованной кооперации. Довольно спорно называть образцом подобную ситуацию, поскольку здесь присутствуют по сути бо- 126 Глава 7. Пакеты и кооперации лее одного образца.
Но, без сомнения, эта нотация может быть применена для изображения ситуации, когда в конкретной системе используются общие образцы. Этот вид нотации может быть использован также в процессе моделирования на основе ролей, в рамках которого вначале моделируются кооперации и роли, а затем разрабатываются классы, которые реализуют эти роли. Дополнительную информацию об этом стиле проектирования можно найти в книге Ринскауга (Веепв)тапи), 1996 [36].
Когда использовать диаграммы пакетов и кооперации Пакеты являются чрезвычайно важным средством для больших проектов. Пакеты следует использовать всякий раз, когда диаграмма классов для системы в целом, размещенная на единственном листе бумаги формата А4, становится трудно читаемой. Пакеты особенно полезны для тестирования. Хотя я и писал некоторые тесты„основываясь исключительно на классах, все же предпочитаю формировать тестовые блоки на основе пакетов. При этом каждый пакет может содержать один или несколько тестовых классов, с помощью которых проверяется поведение этого пакета. По моему опыту кооперации полезны всякий раз, когда необходимо сослаться на конкретное взаимодействие.
Параметризованные кооперации полезны, если в вашей системе имеется несколько похожих коопераций. Где найти дополнительную информацию Пакеты подробно рассмотрены в работе Роберта Мартина (ВоЬегФ Маг$1п), 1996 [30], которая, по моему мнению, является лучшей из книг по данной тематике на сегодняшний день. В этой книге приведен ряд примеров использования метода Буча в сочетании с языком С++, при этом большое внимание уделено минимизации зависимостей. Полезную информацию можно найти также в книге Вире-Брока (та71г(вВгос)т), 1990 [46], в которой автор впервые говорит о пакетах как с подсистемах. Кооперации являются сравнительно новой темой, поэтому дополнительную информацию можно найти только в более обстоятельных книгах по языку ПМ?..
Диаграммы состояний Диаграммы состояний являются хорошо известным методом описания поведения систем. Они изображают все возможные состояния, в которых может находиться конкретный объект, а также изменения состояния объекта, которые происходят в результате влияния некоторых событий на этот объект. В большинстве объектно-ориентированных методов диаграммы состояний строятся для единственного класса, чтобы показать динамику поведения единственного объекта. Существует несколько разновидностей представления диаграмм состояний, незначительно отличающихся друг от друга семантикой. Стиль, принятый в языке ПМБ, основан на схемах состояний Дэвида Харела (Пач1с1 Наге1), 1987 122). На рис.
8.1 изображена диаграмма состояний в обозначениях языка УМЬ, описывающая поведение заказа в системе обработки заказов, которая была рассмотрена ранее в данной книге. На диаграмме представлены различные состояния, в которых может находиться заказ. Из начальной точки процесс переходит в состояние Проверка. Этот переход имеет метку «/получить первую позицию заказаэ. Синтаксис метки перехода состоит из трех частей, каждая из которых является необязательной: Событие 1Сторожееое условие1 /Действие.
В данном случае метка состоит только из действия вполучить первую позицию заказа». После выполнения этого действия мы попадаем в состояние Проверка. С этим состоянием ассоциируется некоторая деятельность, которая обозначается меткой со следующим синтаксисом: 128 Глава 8. Диаграммы состояний вьтолнить/деятельность. В данном случае деятельность называется «проверить позицию заказа». [Не зсе яозици /псяЗчить Повиси [ивкОтор отсЪтств Рис. В.1.
Диаграмма состояний Следует отметить, что я пользуюсь терминами «действие» [асФ[оп) для перехода и «деятельность» (асФ[тг[1у) для состояния. Хотя оба термина обозначают процессы, обычно реализуемые некоторым методом класса Заказ, они трактуются различным образом. Действия ассоциируются с переходами и рассматриваются как мгновенные и непрерываемые.
Деятельности ассоциируются с состояниями и могут продолжаться достаточно долго. Деятельность может быть прервана некоторым событием. Обратите внимание, что смысл определения «мгновенный» зависит от типа разрабатываемой системы. Для компьютерных систем реального времени зто может соответствовать нескольким машинным командам; для обычной информационной системы «мгновение» может означать менее нескольких секунд. Если метка перехода не содержит никакого события, зто означает, что переход произойдет, как только завершится какая-либо деятельность, ассоциированная с данным состоянием; в данном случае — как только будет выполнена Проверка.
Из состояния Проверка выходят три перехода. Метка каждого из них включает только Сторожевое условие. Сторожевое условие — зто логическое условие, которое может принимать одно из двух значений: «истина» или «ложь». Переход со сторо- Диаграммы состояний жевым условием выполняется только в том случае, если данное сторо- жевое условие принимает значение «истина». Из конкретного состояния в данный момент времени может быть осуществлен только один переход, таким образом, сторожевые условия должны быть взаимно исключающими для любого события. На рис. 8.
1 мы имеем дело с тремя условиями: 1. Если проверены не все позиции, входящие в заказ, мы получаем следующую позицию и возвращаемся в состояние Проверка. 2. Если проверены все позиции и все они имеются на складе, то мы переходим в состояние Отправка. 3. Если проверены все позиции, но не все из них имеются на складе, то мы переходим в состояние Ожидание.
Сначала рассмотрим состояние Ожидание. В этом состоянии не существует деятельностей, поэтому данный заказ находится в состоянии ожидания, пока не наступит некоторое событие. Оба перехода из состояния Ожидание помечены событием «Позиция получена». Это означает, что соответствующий заказ находится в состоянии Ожидание до тех пор, пока он не обнаружит наступление данного события. В этот момент оцениваются сторожевые условия данных переходов, и выполняется соответствующий переход либо в состояние Отправка, либо обратно в состояние Ожидание. В состоянии Отправка имеется деятельность, которая инициирует доставку. Из этого состояния имеется единственный безусловный переход, который происходит в результате наступления события «Отправлен».
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
