М. Фаулер, К. Скотт - UML. Основы - 2002 (1158629), страница 26
Текст из файла (страница 26)
1гг Глава 7. Пакеты и кооперации Что означает зависимость, изображенная по направлению к пакету, который в свою очередь содержит другие пакеты7 В общем случае это означает, что такая зависимость обобщает зависимость более низкого уровня. Другими словами, если существует некоторая зависимость от некоторого элемента, содержащегося внутри пакета более высокого уровня, то для представления подобных деталей необходима более подробная диаграмма.
Кроме того, точные правила изменяются для каждого отдельного множества зависимостей. На рис. 7.2 изображен пакет Общий, помеченный как «глобальный». Это означает, что все пакеты в системе зависят от данного пакета. Очевидно, такую конструкцию следует применять весьма осторожно, однако некоторые общие классы, такие как Деньги, используются всеми элементами системы. К пакетам можно применять отношение обобщения. Это означает, что более частный пакет должен быть согласован с интерфейсом общего пакета. Именно такое определение сопоставимо с точкой зрения спецификации на механизм подклассов в диаграммах классов (см.
главу 4). Следовательно, в соответствии с рис. 7.2 Брокер Базы Данных может использовать либо Интерфейс Огас1е, либо Интерфейс БуЬазе. Если обобщение применяется подобным образом, то общий пакет можно пометить как (абстрактный). Это говорит о том, что общий пакет всего лишь определяет интерфейс, реализуемый более частным пакетом. Обобщение означает наличие зависимости от подтипа к супертипу. (Нет необходимости дополнительно показывать подобную зависимость; для этого достаточно самого обобщения.) Размещение абстрактных классов внутри пакета-супертипа является хорошим способом избежать появления циклов в структуре зависимостей. В нашем случае пакеты интерфейса базы данных отвечают за загрузку и сохранение объектов предметной области в базе данных.
Следовательно„они должны располагать информацией относительно объектов предметной области. Однако инициировать загрузку и сохранение должны сами объекты предметной области. Обобщение позволяет поместить необходимый интерфейс триггера (различные операции загрузки и сохранения) в пакет интерфейса базы данных.
После чего эти операции могут быть реализованы классами в рамках пакетов-подтипов. Таким образом, нет никакой необходимости указывать зависимость между пакетом интерфейса базы данных н пакетом интерфейса Огас1е, поскольку во время выполнения объекты предметной области сами будут вызывать соответствующий пакетподтип. Но сами объекты предметной области будут думать, что имеют дело только с исходным пакетом интерфейса базы данных.
Полиморфизм столь же полезен для пакетов, как и для классов. Как и любая эвристика, удаление циклов из структуры зависимостей является достаточно хорошей идеей. Я не уверен, что можно избавиться от всех циклов, однако следует стремиться минимизировать их ко- 1гЗ Кооперации личество. Если у вас имеются подобные циклы, попытайтееь поместить их в более крупный пакет-контейнер. В моей практике встречались случаи, когда я был не способен избавиться от циклов между пакетами предметной области, однако старался исключить их из взаимодействий между интерфейсами предметной области и внешними интерфейсами. Основным средством для исключения циклов является механизм обобщения для пакетов.
В существующей системе зависимости могут быть выведены на основании анализа классов. Эта задача является крайне полезной для реализации с помощью любого инструментального средства. Я всегда пользуюсь такими средствами, когда занимаюсь улучшением структуры существующей системы. Было бы неплохо в качестве самого первого шага сгруппировать классы в пакеты и проанализировать зависимости между пакетами. После чего я прибегаю к реорганизации, чтобы уменьшить количество зависимостей. Кооперации Так же как классы-контейнеры, пакет может содержать кооперации. Кооперация представляет собой имя, которое присваивается взаимодействию двух и более классов. Обычно подобное взаимодействие изображается на диаграмме взаимодействия. Так, например, диаграмма последовательности на рис.
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 изображена диаграмма состояний в обозначениях языка УМЬ, описывающая поведение заказа в системе обработки заказов, которая была рассмотрена ранее в данной книге. На диаграмме представлены различные состояния, в которых может находиться заказ.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
