М. Фаулер, К. Скотт - UML Основы (1114905), страница 29
Текст из файла (страница 29)
Мие приходилось встречать разработчиков, которые выполняли такое иазиачеиие немедленно и весьма эмоционально высказывались в адрес тех, кто откладывал это иа потом; ати разработчики обвиняли своих коллег в том, что оии заиимаются построением обычных диаграмм потоков данных, а вовсе ие объектно-ориентированным проектированием. Должен признаться, что я сам иногда изображаю диаграмму деятельности без назначения поведения конкретным объектам, откладывая это в долгий ящик. Я считаю, что для пользы дела лучше в тот или иной момент времени заниматься решением только одной проблемы.
Это особенно справедливо при моделировании бизнес-процессов, тем самым эксперту предметной области предоставляется возможность обрести новый взгляд иа вещи. Этот способ работает иа меня. Другие предпочитают сразу же назначать поведение объектам. Вы же поступайте так, как считаете удобным для себя. Важно помнить, что деятельности нужно назначить классам до окончания моделирования. Что касается меня, то я предпочитаю для этой цели использовать диаграммы взаимодействия ~см.
главу 5). Когда использовать диаграммы деятельности Подобно большинству других методов моделирования диаграммы деятельиости обладают определенными достоинствами и иедостатками, поэтому их лучше всего использовать в сочетании с другими методами. Самым большим достоинством диаграмм деятельности является возможиость представления и описания параллельного поведения. Именио благодаря этому оии являются мощным средством моделирования потоков работ и, по существу, программирования многопоточности. Самый большой недостаток этих диаграмм заключается в том, что оии ие позволяют представить связи между действиями и объектами достаточио наглядно.
144 Гпава 9. Диаграммы деятельности Связь с некоторым объектом можно определить, помечая ту или иную деятельность именем соответствующего объекта или используя дорожки, которые разделяют диаграмму деятельности на зоны ответственности, но этот способ не обладает наглядностью диаграмм взаимодействия (см. главу б). По этой причине некоторые разработчики считают, что использование диаграмм деятельности не отвечает объектноориентированному подходу и поэтому их вовсе не стоит строить.
Я же считаю этот метод весьма полезным и не собираюсь от него отказываться. Я предпочитаю использовать диаграммы деятельности в следующих ситуациях: ° Анализ варианта использования. На этом этапе меня не интересует связь между действиями и объектами; мне только нужно понять, какие действия должны иметь место и каковы зависимости в поведении системы. Я выполняю связывание методов с объектами позже и показываю эти связи с помощью диаграмм взаимодействия.
° Понимание потока работ. Прежде чем приступить к рассмотрению содержания вариантов использования, целесообразно привлечь диаграммы деятельности для лучшего понимания соответствующего бизнес-процесса. Эти диаграммы лучше разрабатывать совместно с бизнес-аналитиками, поскольку при этом можно понять особенности бизнес-процесса и возможности его изменения.
° Описание сложного последовательного алгоритма. В этом случае диаграмма деятельности не позволяет представить ничего сверх того, что может быть изображено на согласованной с обозначениями языка УМ1 схеме алгоритма. При этом можно использовать принятые на схемах алгоритмов специальные обозначения. ° Работа с многопоточными приложениями. Я сам еще не использовал диаграммы деятельности для этой цели, однако слышал положительные отзывы о подобном применении. Диаграммы деятельности не следует использовать в следующих ситуа- циях: ° Пытаться представить кооперацию объектов.
Диаграммы взаимодействия являются более простыми и обеспечивают более наглядное представление кооперации. ° Пытаться представить поведение объектов в течение их жизненного цикла. Для этой цели лучше использовать диаграмму состояний (см. главу 8). ° Представление сложных логически~ условий. Для этой цели лучше использовать таблицу истинности.
В ходе работы над версией 1.3 языка ПМ1. диаграммы деятельности были значительно уточнены и существенно дополнены. Однако все это вызывает смешанные чувства. Проблема состоит в том, что если ис- 145 Где найти дополнительную информацию пользовать эти диаграммы для концептуального моделирования, многие из уточнений теряют смысл. Б подобных ситуациях не следует стремиться к исчерпывающей точности — нужно лишь представить общую картину того, как все работает. Даже если такие уточнения очевидны, все равно едва ли стоит что-либо исправлять, пока вы не будете способны проверить и протестировать диаграмму. Следует помнить фразу Бертрана Мейера: «Пеной не напьешься». С другой стороны, наличие некоторого стандарта для представления диаграмм состояний и диаграмм деятельности дает более стабильную основу для разработки инструментальных средств, применение которых позволило бы реализовывать эти диаграммы.
Именно такие средства позволят вам разрабатывать данные диаграммы и тестировать их. Где найти дополнительную информацию По диаграммам деятельности имеется довольно мало информации. В «Справочнике пользователя» (Рамбо, Джекобсон и Буч, 1999 «37)) рассматривается много деталей, но совсем не объясняется, как они работают. «Руководство пользователя» (Буч, Джекобсон и Рамбо, 1999 (6)) вовсе не содержит подробные ответы на типичные вопросы, возникающие при попытке использовать эти диаграммы. Было бы неплохо, если бы кто-нибудь заполнил этот пробел в ближайшее время.
Физические диаграммы В языке 11М1. имеется два вида физических диаграмм: диаграммы раз- вертывания и диаграммы компонентов. Диаграммы развертывания Диаграмма развертывания (дер1оутпеп1 Й1аягат) отражает физические взаимосвязи между программными и аппаратными компонентами разрабатываемой системы. Эта диаграмма является хорошим средством для представления маршрутов перемещения объектов и компонентов в распределенной системе. Каждый узел на диаграмме развертывания представляет собой некоторый тип вычислительного устройства — в большинстве случаев самостоятельную часть аппаратуры.
Эта аппаратура может быть как простым устройством нли датчиком, так и мейнфреймом. На рис. 10.1 изображен персональный компьютер, соединенный с 1)п1хсервером посредством протокола ТСР(1Р. Соединения между узлами показывают физические каналы связи, с помощью которых осуществляются взаимодействия в системе. Диаграммы компонентов Диаграмма компонентов (сотпропеп1 й1аягат) показывает различные компоненты системы и зависимости между ними. 149 Объединение диаграмм компонентов и развертывания Компонент представляет собой физический модуль программного кода. Компонент часто считают синонимом пакета, но эти понятия могут отличаться, поскольку компоненты представляют собой физическое объединение программного кода.
Хотя отдельный класс может быть представлен в целой совокупности компонентов, этот класс должен быть определен только в одном пакете. Например, класс Слзрока в языке дача является частью пакета затга.!апя, но он может быть обнаружен в ряде компонентов. Зависимости между компонентами показывают, как изменения одного компонента могут повлиять на изменения других компонентов. Существует довольно ограниченное количество видов зависимостей, которые можно использовать, включая зависимости типа связь и компиляция. Я часто применяю эти виды зависимостей для представления связей компонентов между собой.
Объединение диаграмм компонентов и развертывания Хотя диаграммы развертывания и диаграммы компонентов можно изображать отдельно, также допускается помещать диаграмму компонентов на диаграмму развертывания, как показано на рис. 10.1. Это целесообразно делать, чтобы показать какие компоненты выполняются и на каких узлах. Так, например, на данной диаграмме компоненты Пользовательский Интерфейс Отделения Заболеваний Печени и Фасад Клиента Отделения Заболеваний Печени исполняются на ПК под управлением ОС 1йГ1пботзгэ. Компонент Пользовательский Интерфейс Отделения Заболеваний Печени зависит от компонента Фасад Клиента Отделения Заболеваний Печени, поскольку он обращается к конкретным методам этого Фасада. Хотя связь является двунаправленной в том смысле, что Фасад возвращает данные, компонент Фасад не знает, кто его вызывает, и поэтому не зависит от компонента Пользовательский Интерфейс. С другой стороны, связь между двумя компонентами Предметная Область Медицинской Помощи является двунаправленной, поскольку каждый из них знает, какому компоненту он передает данные.
Однако эти компоненты выполняются на отдельных узлах. Компонент может иметь более одного интерфейса, при этом в каждом случае видно„какие компоненты взаимодействуют с тем или иным интерфейсом. На рис. 10.1 серверная часть приложения имеет два интерфейса. Один интерфейс используется фасадом приложения во время его исполнения на ПК, другой интерфейс используется компонентом конфигурирования во время его исполнения на сервере. Факт использования нескольких компонентов Предметная Область Медицинской Помощи скрыт от своих клиентов. Каждый компонент 1бо Глава 10. Физические диаграммы Предметная Область Медицинской Помощи имеет свою локальную базу данных.
Разработчики часто изображают на физических диаграммах специальные символы, которые по своему внешнему виду напоминают различные элементы. Например, применяются специальные пиктограммы для серверов, ПК и баз данных. В рамках языка ПМ1 это вполне допускается: каждую из пиктограмм можно рассматривать как стереотип соответствующего элемента диаграммы. Обычно такие пиктограммы способствуют лучшему пониманию диаграммы, хотя и усложняют ее, если одновременно изображаются узлы и компоненты, как на рис.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
