Анализ возможностей организации 7 страница

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

Для кооперативных диаграмм можно использовать один из нескольких вариантов нумерации. В UML применяется десятичная схема нумерации (рис. 3.13), поскольку в этом случае понятно, какая операция вызывает какую операцию, хотя может быть труднее разглядеть их общую последовательность.

Рис. 3.13.Кооперативная диаграмма с десятичной нумерацией

 

Независимо от используемой схемы нумерации на диаграмме можно разместить такого же рода управляющую информацию, как и на диаграмме последовательности.

На рис. 3.13 можно увидеть различные формы схемы именования объектов, принятые в UML. Общая форма имеет вид <Имя Объекта: ИмяКласса>, где либо имя объекта, либо имя класса может отсутствовать. При отсутствии имени объекта остается двоеточие, чтобы было понятно, что это имя класса, а не объекта.

 

3.5.3.

СРАВНЕНИЕ ДИАГРАММ ПОСЛЕДОВАТЕЛЬНОСТИ

И КООПЕРАТИВНЫХ ДИАГРАММ

У разных разработчиков имеются различные предпочтения вида диаграммы взаимодействия. В диаграмме последовательности делается акцент именно на последовательность сообщений: легче наблюдать порядок, в котором происходят различные события. На кооперативной диаграмме можно использовать пространственное расположение объектов для того, чтобы показать их статическое взаимодействие.

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

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

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

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

 

3.6. ДИАГРАММЫ СОСТОЯНИЙ

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

Рис. 3.14.Диаграмма состояний

 

Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой. Наиболее популярная форма, используемая в объектно-ориентированных методах, впервые применялась в методе OMT и впоследствии была адаптирована Гради Бучем.

На рис. 3.14 показана диаграмма состояний UML, отражающая поведение заказа в системе обработки заказов, которая была описана в предыдущих разделах. На диаграмме изображены различные состояния, в которых может находиться заказ.

Процесс начинается с начальной точки, затем следует самый первый переход в состояние Проверка позиции заказа. Метка этого перехода - "/получить первую позицию заказа". Синтаксически метка перехода состоит из трех частей, каждая из которых является необязательной: <Событие> [<Условие>]/<Действие>. В данном случае метка включает только действие "получить первую позицию заказа". После выполнения этого действия мы попадаем в состояние Проверка позиции заказа. С этим состоянием связана деятельность, которая обозначается меткой со следующим синтаксисом: выполнить/деятельность. В данном случае деятельность называется "проверить позицию".

Следует отметить, что термин "действие" (action) используется для перехода, а термин "деятельность" (activity) - для состояния. Хотя и то, и другое — это процессы, реализуемые, как правило, некоторым методом класса Заказ, они трактуются различным образом. Действия связаны с переходами и рассматриваются как мгновенные и непрерываемые процессы. Деятельности связаны с состояниями и могут длиться достаточно долго. Деятельность может быть прервана в результате наступления некоторого события.

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

Если метка перехода не содержит никакого события, это означает, что переход происходит, как только завершается любая деятельность, связанная с данным состоянием. В данном случае - как только завершится Проверка позиций заказа. Из состояния Проверка позиции заказа возможны три перехода. Метка каждого из них включает только условие. Условие — это логическое условие, которое может принимать два значения: "истина" или "ложь". Условный переход выполняется только в том случае, если условие принимает значение "истина".

Из конкретного состояния в данный момент времени может быть осуществлен только один переход. Таким образом, условия являются взаимно исключающими для любого события. На рис. 3.14 мы имеем дело с тремя условиями:

1) если проверены не все позиции, входящие в заказ, то получаем следующую позицию и возвращаемся в состояние Проверка позиции заказа;

2) если проверены все позиции и все они имеются на складе, то переходим в состояние Выдача заказа на поставку;

3) если проверены все позиции, но не все из них имеются на складе, то переходим в состояние Ожидание.

Рассмотрим сначала состояние Ожидание. Для этого состояния не существует деятельностей, поэтому данный заказ находится в состоянии ожидания, пока не наступит некоторое событие. Оба перехода из состояния ожидания помечены событием Позиция Получена. Это означает, что заказ ожидает до тех пор, пока он не обнаружит наступление данного события. При этом оцениваются условия переходов и выполняется тот переход, для которого условие "истинно" (либо в состояние Выдача заказа на поставку, либо обратно в состояние Ожидание).

В состоянии Выдача заказа на поставку имеется деятельность, которая инициирует поставку. Из этого состояния имеется единственный безусловный переход, управляемый событием Поставлен. Это означает, что данный переход обязательно произойдет, если произойдет данное событие. При этом переход никак не связан с завершением деятельности; наоборот, когда деятельность "инициировать поставку" завершится, то данный заказ останется в состоянии Выдача заказа на поставку, пока не наступит событие Поставлен.

Последнее, что нужно рассмотреть, — это переход под названием "отмена". Необходимо располагать возможностью отменить любой заказ в любой момент до завершения его выполнения. Это можно сделать, изобразив отдельные переходы из каждого состояния: Проверка позиции заказа, Ожидание и Выдача заказа на поставку. Альтернативный вариант - определение суперсостояния для трех перечисленных состояний и соответственно единственного перехода из него. Подсостояния просто наследуют любые переходы суперсостояния (рис. 3.15).

На этих диаграммах деятельность изображается внутри состояния в виде текста "выполнить/ деятельность". Внутри состояния можно также разместить и другую информацию.

Если состояние реагирует на событие, связанное с действием, которое не влечет за собой никакого перехода, этот факт можно изобразить, поместив в прямоугольник состояния текст вида "ИмяСобытия/ИмяДействия ".

Рис. 3.15.Диаграмма состояний с суперсостояниями

 

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

Помимо состояний заказа, связанных с получением информации о наличии предметов и их поставкой, существуют также состояния, связанные с проверкой платежей. Эти состояния отражает диаграмма на рис. 3.16.

В данном случае все начинается с выполнения проверки. Деятельность "проверить платеж" завершается сообщением информации о состоянии платежа. Если платеж прошел, то данный заказ ожидает в состоянии Проверен до тех пор, пока не наступит событие "поставка". В противном случае заказ переходит в состояние Отвергнут.

Таким образом, поведение объекта Заказ определяется одновременно диаграммами на рис. 3.14 и 3.16. Их можно объединить в одну диаграмму параллельных состояний (рис. 3.17); детали внутренних состояний здесь опущены.

Смысл параллельных разделов диаграммы состояний заключается в том, что в любой их точке данный заказ находится одновременно в двух различных" состояниях, по одному из каждой исходной диаграммы. Когда заказ покидает параллельные состояния, он оказывается в одном-единственном состоянии. Из диаграммы видно, что в начальный момент заказ оказывается одновременно в двух состояниях: Проверка позиции заказа и Проверка прохождения платежа. Если первым успешно завершится процесс Проверка прохождения платежа, то заказ окажется в двух состояниях: Проверка позиции заказа и Проверен. Если же наступит событие "отмена", то заказ окажется только в состоянии Отмена.

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

Рис. 3.16.Проверка платежа

Рис. 3.17. Диаграмма параллельных состояний

 

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

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

 

3.7. ДИАГРАММЫ ДЕЯТЕЛЬНОСТЕЙ

В отличие от большинства других средств UML диаграммы деятельностей основаны на нескольких различных методах, в частности методе моделирования состояний SDL и сетях Петри. Эти диаграммы особенно полезны в описании поведения, включающего большое количество параллельных процессов.

На рис. 3.18, который заимствован из документации UML, основным элементом является деятельность. Интерпретация этого термина зависит от той точки зрения, с которой строится данная диаграмма. На концептуальной диаграмме деятельность — это некоторая задача, которую необходимо выполнить вручную или автоматизированным способом. На диаграмме, построенной в аспекте спецификации или реализации, деятельность представляет собой некоторый метод над классом.

За каждой деятельностью может следовать другая деятельность. Такое следование образует простую последовательность. Например, за деятельностью Положить Кофе в Фильтр следует деятельность Вставить Фильтр в Автомат. Деятельность Поискать Напиток активизирует на выходе два действия. Каждое действие содержит условие — логическое выражение, которое может принимать одно из двух значений: "истина" или "ложь", так же как и на диаграмме состояний. В ситуации (см. рис. 3.18) Личность осуществляет деятельность Поискать Напиток, выбирая между кофе и колой.

Предположим, что мы отыскали кофе и идем вниз по "кофейному маршруту". Этот путь ведет к линейке синхронизации, с которой связана активизация трех деятельностей: Положить Кофе в Фильтр, Добавить Воду в Емкость и Достать Чашки.

 

Рис. 3.18.Диаграмма деятельностей

 

Диаграмма указывает на то, что эти три деятельности могут выполняться параллельно. По существу, это означает, что порядок их выполнения не играет роли. Можно сначала положить кофе в фильтр, затем добавить воды в емкость, потом достать чашки, а можно сначала достать чашки, а затем добавить кофе в фильтр.

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

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

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

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

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

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

Теперь переместимся к другому маршруту.

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

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

Деятельность Выпить Напиток имеет два входа, что означает ее выполнение в любом случае. Данную ситуацию можно рассматривать как условие "ИЛИ" (выполняется, если выполняется хотя бы одна из двух деятельностей), а линейку синхронизации можно рассматривать как условие "И" (выполняется, если выполняются обе деятельности).

Рис. 3.18 представляет собой описание метода над типом Личность. Диаграммы деятельностей полезны для описания сложных методов. Их можно также применять где угодно — например, для описания вариантов использования.

Рассмотрим вариант использования, связанный с обработкой заказа.

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

Данный вариант использования представлен на рис. 3.19. В диаграмму деятельностей введена новая конструкция: вход деятельности Проверить Позицию Заказа помечен символом "*". Это маркер множественности (такой же маркер использовался в диаграммах классов), он показывает, что при получении заказа необходимо выполнить деятельность Проверить Позицию Заказа для каждой строки заказа. Это означает, что за деятельностью Получить Заказ следует один вызов деятельности Проверить Платеж и много вызовов деятельности Проверить Позицию Заказа. Все эти вызовы выполняются параллельно.

Рис. 3.19.Получение заказа

 

Этот случай подчеркивает второй источник параллелизма на диаграмме деятельностей. Параллельные деятельности могут быть связаны не только с линейкой синхронизации, но также с множественной активизацией. Для любой множественной активизации нужно обязательно показать на диаграмме ее основу, как, например, в данном случае - "для каждой строки заказа". Такое обозначение не является частью официального UML, однако можно считать его весьма важным для понимания диаграмм.

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

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

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

Рис. 3.19 содержит также тупик: деятельность Повторно заказать Позицию. После выполнения этой деятельности больше ничего не происходит. Тупики вполне нормально выглядят на такой не имеющей завершения диаграмме деятельностей, как данная. Иногда они выглядят очевидными, как деятельность Повторно заказать Позицию. В других случаях они не столь очевидны. Посмотрим на деятельность Проверить Позицию Заказа. У нее только один выход, который содержит условие. Что произойдет, если данной позиции не окажется на складе? Ничего - такая ветвь отсутствует.

В данном примере невозможно выполнить заказ, пока не пополнится запас на складе с помощью комплектующей поставки. Этой деятельности может соответствовать отдельный вариант использования.

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

Этот вариант использования отражает диаграмма деятельностей, представленная на рис. 3.20. Здесь показан процесс ожидания заказа до получения очередной комплектующей поставки.

Рис. 3.20.Получение комплектующей поставки

 

Когда каждый из двух вариантов использования отражает свою часть общей картины, обычно они объединяются в одну диаграмму (рис. 3.21). Здесь отдельные диаграммы деятельностей для обоих вариантов использования наложены друг на друга. Таким образом, можно наблюдать, как действия в одном варианте использования вызывают соответствующие действия в другом. Такого рода диаграмма содержит множество начальных точек, что является вполне допустимым, поскольку диаграмма деятельностей отражает реакцию системы на множество внешних событий.

 

Рис. 3.21.Получение заказа и комплектующей поставки

 

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

Любая деятельность может быть подвергнута дальнейшей декомпозиции. Описание декомпозированной деятельности может быть представлено в виде текста, кода или другой диаграммы деятельностей (рис. 3.22).

Когда строится диаграмма деятельностей, представляющая собой декомпозицию деятельности более высокого уровня, на ней должна присутствовать только одна начальная точка. С другой стороны, конечных точек может быть столько, сколько выходов у деятельности более высокого уровня. Таким образом, декомпозированная диаграмма возвращает значение, определяемое последним выходом. Например, на рис. 3.22 присутствует деятельность Проверить Кредитную Карту, которая возвращает либо "ОК", либо "проверка не прошла".

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

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

Рис. 3.22. Декомпозированная диаграмма деятельностей

 

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

· анализ варианта использования. На этой стадии нас не интересует связь между действиями и объектами, а нужно только понять какие действия должны иметь место и каковы зависимости в поведении системы. Связывание методов и объектов выполняется позднее с помощью диаграмм взаимодействия;

· анализ потоков работ (workflow) в различных вариантах использования. Когда варианты использования взаимодействуют друг с другом, диаграммы деятельностей являются мощным средством представления и анализа их поведения.

Не рекомендуется использовать диаграммы деятельностей в следующих ситуациях:

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

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

 

3.8

ДИАГРАММЫ КОМПОНЕНТОВ

Диаграммы компонентов показывают, как выглядит модель системы на физическом уровне. На диаграмме изображены компоненты программного обеспечения и связи между ними. При этом выделяют два типа компонентов: исполняемые компоненты и библиотеки кода.

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

На рис. 3.23 изображена одна из диаграмм компонентов для некоторой системы обслуживания банкоматов архитектуры клиент-сервер.

На этой диаграмме показаны компоненты клиента системы. В данном случае система строится с помощью языка C++. У каждого класса имеется свой собственный заголовочный файл и файл с расширением .СРР, так что каждый класс преобразуется в свои собственные компоненты на диаграмме. Например, некоторый класс Screen преобразуется в два компонента, представляющие тело и заголовок класса Screen. Выделенный темным компонент называется спецификацией пакета (package specification) и соответствует

Рис. 3.23. Диаграмма компонентов для клиента

 

файлу тела класса Screen на языке C++ (файл с расширением .СРР). Невыделенный компонент также называется спецификацией пакета, но соответствует заголовочному файлу класса языка C++ (файл с расширением .Н). Компонент Client.exe является исполняемой программой.

Компоненты соединены штриховой линией, что соответствует зависимостям между ними. Например, класс CardReader зависит от класса Screen. Это означает, что, для того чтобы класс CardReader мог быть скомпилирован, класс Screen должен уже существовать. После компиляции всех классов может быть создан исполняемый файл Client.exe.

В данном примере система включает два исполняемых файла. Один из них — это клиент Client.exe, он содержит компоненты CashDispenser, CardReader и Screen. Второй файл — это сервер, включающий в себя компонент Account. Диаграмма компонентов для сервера показана на рис. 3.24.

Рис. 3.24. Диаграмма компонентов для сервера

 

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

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

 

3.9

ДИАГРАММЫ РАЗМЕЩЕНИЯ

Диаграмма размещения (deployment diagram) отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она является хорошим средством для того, чтобы показать маршруты перемещения объектов и компонентов в распределенной системе.

Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства, в большинстве случаев — часть аппаратуры. Эта аппаратура может быть простым устройством или датчиком, а может быть и мэйнфреймом.

На рис. 3.25 изображен персональный компьютер (ПК), связанный с UNIX-сервером посредством протокола TCP/IP (Transmission Control Protocol / Internet Protocol - протокол управления передачей — протокол Интернет). Связи между узлами показывают коммуникационные каналы, с помощью которых осуществляются системные

взаимодействия.

Компоненты на диаграмме размещения представляют собой физические модули программного кода. Как правило, они в точности соответствуют компонентам на диаграмме компонентов. Таким образом, диаграмма размещения отражает выполнение каждого компонента в системе.

На данной диаграмме Пользовательский Интерфейс Отделения Заболеваний Печени зависит от Клиентской Части Отделения Заболеваний Печени, поскольку он обращается к конкретным методам клиентской части. Хотя коммуникация является двунаправленной в том смысле, что Клиентская Часть возвращает данные, Клиентская Часть не знает, кто ее вызывает, и поэтому не зависит от Пользовательского Интерфейса. Что касается коммуникаций между двумя компонентами Медицинской Помощи, каждый из них знает, что передается другому компоненту, поэтому коммуникационная зависимость является двунаправленной.