Диаграмма компонентов обозначение элементов для построения. Проектирование программного обеспечения

Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Диагра́мма компоне́нтов, Component diagram - статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами.

Таким образом иллюстрируются отношения клиент-источник между двумя компонентами. После ознакомления с разделами («Пример», «Применение») вы можете попробовать свои силы в самостоятельном составлении диаграмм компонентов. В объектно-ориентированном сообществе идут дебаты о том, в чем состоит различие между компонентом и обычным классом. В UML 1 был отдельный символ для компонента (рис. 14.1). В UML 2 этого значка нет, но можно обозначить прямоугольник класса похожим значком.

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

В этом примере компонент Till (Касса) может взаимодействовать с компонентом Sales Server (Сервер продаж) с помощью интерфейса sales message (Сообщение о продажах). Вопрос о сущности компонента является предметом бесконечных споров. Компоненты – это не технология. Компоненты – это скорее стиль отношения клиентов к программному обеспечению. Они хотят, чтобы новые компоненты работали так же, как и прежние, и обновлять их согласно своим планам, а не по указанию производителей.

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

В ходе проектирования архитектором или опытным программистом создается проектная документация, включающая текстовые описания, диаграммы, модели будущей программы. UML - является графическим языком для визуализации, описания параметров, конструирования и документирования различных систем (программ в частности).

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

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

Эта диаграмма, по сути, завершает процесс ООАП для конкретной программной системы и ее разработка, как правило, является последним этапом спецификации модели. И способствуют этому несколько специальных техник (Scrum of scrums, компонентные команды, участие архитектора в роли Product owner’а). Это и есть развитие реальной системы.

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

3.4.3. Применение диаграмм компонентов и размещения

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

Диаграмма компонентов и особенности ее построения

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

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

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

Показать разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами.

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

План действий

После ознакомления с разделами («Пример», «Применение») вы можете попробовать свои силы в самостоятельном составлении диаграмм компонентов.

Как применять метод проектирования

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

Пример использования

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

В UML 1 был отдельный символ для компонента (рис. 14.1). В UML 2 этого значка нет, но можно обозначить прямоугольник класса похожим значком. Или можно воспользоваться ключевым словом «component » (компонент ).

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

На рис. 14.2 показан пример простой диаграммы компонентов. В этом примере компонент Till (Касса) может взаимодействовать с компонентом Sales Server (Сервер продаж) с помощью интерфейса sales message (Сообщение о продажах). Поскольку сеть ненадежна, то компонент Message Queue (Очередь сообщений) установлен так, чтобы касса могла общаться с сервером, когда сеть работает, и разговаривать с очередью сообщений, когда сеть отключена. Тогда очередь сообщений сможет поговорить с сервером, когда сеть снова станет доступной. В результате очередь сообщений предоставляет интерфейс для разговора с кассой, и требует такой же интерфейс для разговора с сервером. Сервер разделен на два основных компонента: Transaction Processor (Процессор транзакций) реализует интерфейс сообщений, а Accounting Driver (Драйвер счетов) общается с Accounting System (Система ведения счетов) .

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

Компоненты – это не технология. Технические специалисты считают их трудными для понимания. Компоненты – это скорее стиль отношения клиентов к программному обеспечению. Они хотят иметь возможность покупать необходимое им программное обеспечение частями, а также иметь возможность обновлять его, как они обновляют свою стереосистему. Они хотят, чтобы новые компоненты работали так же, как и прежние, и обновлять их согласно своим планам, а не по указанию производителей. Они хотят, чтобы системы различных производителей могли работать вместе и были взаимозаменяемыми. Это очень разумные требования. Одна загвоздка: их трудно выполнить.
Ральф Джонсон (Ralph Johnson), http://www.c2.com/cgi/wiki?DoComponentsExist

Важно то, что компоненты представляют элементы, которые можно независимо друг от друга купить и обновить. В результате разделение системы на компоненты является в большей мере маркетинговым решением, чем техническим. Прекрасное руководство по данному вопросу представляет книга Хохмана . Она также напоминает о том, что следует остерегаться разделения системы на слишком мелкие компоненты, поскольку очень большим количеством компонентов трудно управлять, особенно когда производство версий поднимает свою уродливую голову; отсюда пошло выражение «ад DLL» или «dll hell» . В ранних версиях языка UML компоненты применялись для представления физических структур, таких как DLL. Теперь это не актуально; в настоящее время эта задача решается при помощи артефактов (artifacts ).

Подписывайтесь на новости сайта, форму подписки вы можете найти в правой колонке сайта.

Если вы хотите научиться работать на фрилансе профессионально, приглашаем на курс « ».

        Унифицированный язык моделирования (Unified Modeling Language - UML) это язык для специфицирования, визуализации, конструирования и документирования программных систем, а так же бизнес моделей и прочих не программных систем. UML представляет собой объединение инженерных приемов, которые ранее успешно использовались при моделировании больших и сложных систем

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

        UML предоставляет выразительные средства для создания визуальных моделей, которые:

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

        Унифицированный Язык Моделирования (UML):

• не зависит от объектно-ориентированных (ОО) языков программирования;
• не зависит от используемой методологии разработки проекта;
• может поддерживать любой ОО язык программирования.

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

Диаграммы UML

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

• Use case diagram (диаграммы прецедентов);
• Deployment diagram (диаграммы топологии);
• Statechart diagram (диаграммы состояний);
• Interaction diagram (диаграммы взаимодействия); Activity diagram (диаграммы активности);
• Sequence diagram (диаграммы последовательностей действий);
• Collaboration diagram (диаграммы сотрудничества);
• Class diagram (диаграммы классов);
• Component diagram (диаграммы компонент);
• Behavior diagrams (диаграммы поведения);
• Activity diagram (диаграмма деятельности);
• Implementation diagrams(диаграммы реализации);

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

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

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

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

        При графическом изображении диаграмм рекомендуется придерживаться следующих правил:

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

Сущности в UML

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

       Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют статические части модели, соответствующие концептуальным или физическим элементам системы. Примерами структурных сущностей являются "класс", "интерфейс", "кооперация", "прецедент", "компонент", "узел", "актер".

        Поведенческие сущности являются динамическими составляющими модели UML. Это глаголы, которые описывают поведение модели во времени и в пространстве. Существует два основных типа поведенческих сущностей:

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

        Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Такая первичная сущность имеется в единственном экземпляре - это пакет.

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

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

Отношения в UML

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

        Зависимость (dependency) - это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой.

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

        Обобщение (generalization) - это отношение, при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (предка). При этом, в соответствии с принципами объектно-ориентированного программирования, потомок (child) наследует структуру и поведение своего предка (parent).

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

• между интерфейсами и реализующими их классами или компонентами;
• между прецедентами и реализующими их кооперациями.

Общие механизмы UML

        Для точного описания системы в UML используются, так называемые, общие механизмы:

• спецификации (specifications);
• дополнения (adornments);
• деления (common divisions);
• расширения (extensibility mechanisms).

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

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

        При моделировании объектно-ориентированных систем существует определенное деление представляемых сущностей.

        Во-первых, существует деление на классы и объекты. Класс - это абстракция, а объект - конкретное воплощение этой абстракции. В связи с этим, практически все конструкции языка характеризуются двойственностью "класс/объект". Так, имеются прецеденты и экземпляры прецедентов, компоненты и экземпляры компонентов, узлы и экземпляры узлов. В графическом представлении для объекта принято использовать тот же символ, что и для класса, а название подчеркивать.

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

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

        Механизмы расширения UML включают:

• стереотипы (stereotype) - расширяют словарь UML, позволяя на основе существующих элементов языка создавать новые, ориентированные для решения конкретной проблемы;
• помеченные значения (tagged value) - расширяют свойства основных конструкций UML, позволяя включать дополнительную информацию в спецификацию элемента;
• ограничения (constraints) - расширяют семантику конструкций UML, позволяя создавать новые и отменять существующие правила.

        Совместно эти три механизма расширения языка позволяют модифицировать его в соответствии с потребностями проекта или особенностями технологии разработки.

Диаграмма вариантов использования (use case diagram)

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

Рисунок - 1. Диаграмма вариантов использования

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

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

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

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

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

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

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

Диаграмма классов (class diagram)

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

Рисунок - 2. Диаграмма классов

        Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на котором отображаются объекты системы. Rational Rose позволяет создавать классы при помощи данного типа диаграмм в различных нотациях. похожего на облако. Таким образом класс - это лишь шаблон, по которому в дальнейшем будет создан конкретный объект.

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

        Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами других классов. Графически класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции. В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (методы).

Диаграмма состояний (statechart diagram)

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

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

Рисунок - 2. Диаграмма состояний

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

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

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

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

        Для автомата должны выполняться следующие обязательные условия:

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

состояния (state) является фундаментальным не только в метамодели языка UML, но и в прикладном системном анализе. Вся концепция динамической системы основывается на понятии состояния. Семантика же состояния в языке UML имеет ряд специфических особенностей.

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

Диаграмма деятельности (activity diagram)

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

        Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение Activity diagram в том, чтобы отражать бизнес-процессы объекта. Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов.

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

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

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

        В контексте языка UML деятельность (activity) представляет собой совокупность отдельных вычислений, выполняемых автоматом, приводящих к некоторому результату или действию (action). На диаграмме деятельности отображается логика и последовательность переходов от одной деятельности к другой, а внимание аналитика фокусируется на результатах. Результат деятельности может привести к изменению состояния системы или возвращению некоторого значения.

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

Диаграмма последовательности (sequence diagram)

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

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

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

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

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

Диаграмма кооперации (collaboration diagram)

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

Рисунок - 3. Диаграмма кооперации

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

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

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

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

        Кооперация может быть представлена на двух уровнях:

• уровне спецификации - показывает роли классификаторов и роли ассоциаций в рассматриваемом взаимодействии;
• уровне примеров - указывает экземпляры и связи, образующие отдельные роли в кооперации.

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

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

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

Диаграмма компонентов (component diagram)

        Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей.

Рисунок - 4. Диаграмма компонентов

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

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

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

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

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

        Для представления физических сущностей в языке UML применяется специальный термин - компонент (component) . Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели. Для графического представления компонента используется специальный символ - прямоугольник со вставленными слева двумя более мелкими прямоугольниками. Внутри большого прямоугольника записывается имя компонента и, при необходимости, некоторая дополнительная информация. Изображение этого символа может незначительно варьироваться в зависимости от характера ассоциируемой с компонентом информации.

Диаграмма развертывания (deployment diagram)

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

Рисунок - 5. Диаграмма развертывания

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

        Для представления общей конфигурации и топологии распределенной программной системы в UML предназначены диаграммы развертывания.

        Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполняемыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов. На диаграмме развертывания они не указываются.

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

        При разработке диаграммы развертывания преследуют следующие цели:

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

        Диаграммы развертывания разрабатываются совместно системными аналитиками, сетевыми инженерами и системотехниками.

Особенности рабочего интерфейса Rational Rose

        В CASE-средстве Rational Rose реализованы общепринятые стандарты на рабочий интерфейс программы, подобно известным средам визуального программирования. После установки Rational Rose на компьютер пользователя, что практически не вызывает трудностей даже у начинающих, запуск этой программы в среде MS Windows 95/98 приводит к появлению на экране рабочего интерфейса (рис. 6).

Рисунок - 6. Общий вид рабочего интерфейса программы Rational Rose

        Рабочий интерфейс Rational Rose состоит из различных элементов, основными из которых являются:

• Главное меню программы
• Окно диаграммы
• Окно документации
• Окно браузера
• Окно журнала

Рассмотрим кратко назначение и основные функции каждого из этих элементов.

Главное меню программы

Главное меню программы выполнено в общепринятом стандарте и имеет следующий вид (рис. 7).

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

Рисунок - 7. Внешний вид главного меню программы

Стандартная панель инструментов

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

Рисунок - 8. Внешний вид стандартной панели инструментов

Пользователь может настроить внешний вид этой панели по своему усмотрению. Для этого необходимо выбрать пункт меню Tools -> Options (Инструменты -> Параметры) и открыть вкладку Toolbars (Панели инструментов). Этим способом можно показать или скрыть различные кнопки инструментов, а также изменить их размер.

Окно браузера

Окно браузера по умолчанию располагается в левой части рабочего интерфейса под стандартной панелью инструментов (рис. 9).

Браузер организует представления модели в виде иерархической структуры, которая упрощает навигацию и позволяет отыскать любой элемент модели в проекте. При этом любой элемент, который разработчик добавляет в модель, сразу отображается в окне браузера. Соответственно, выбрав элемент в окне браузера, мы можем его визуализировать в окне диаграммы или изменить его спецификацию. Браузер позволяет также организовывать элементы модели в пакеты и перемещать элементы между различными представлениями модели. При желании окно браузера можно расположить в другом месте рабочего интерфейса либо скрыть вовсе, используя для этого пункт меню View (Вид). Можно также изменить размеры браузера, переместив мышью границу его внешней рамки.

Рисунок - 9. Внешний вид браузера

Специальная панель инструментов

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

Рисунок - 10. Внешний вид специальной панели инструментов для диаграммы классов

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

Окно диаграммы

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

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

Рисунок - 11. Внешний вид окна диаграмм с различными видами представлений модели

Окно документации

Окно документации по умолчанию может не присутствовать на экране. В этом случае оно может быть активизировано через пункт меню View -> Documentation (Вид->Документация), после чего появится ниже браузера (рис. 12).

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

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

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

Рисунок - 12. Внешний вид окна документации

Окно журнала

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

Окно журнала всегда присутствует на рабочем интерфейсе в области окна диаграммы (рис. 13). Однако оно может быть закрыто другими окнами с диаграммами или быть свернутым. Активизировать окно журнала можно через меню Window->Log (Окно->Журнал). В этом случае оно изображается поверх других окон в правой области рабочего интерфейса. Полностью удалить это окно нельзя, его можно только минимизировать.

Рисунок - 13. Внешний вид окна журнала

Заключение

        Со временем язык UML станет тем "эсперанто", на котором смогут общаться математики, системные аналитики, физики, программисты, менеджеры, экономисты и специалисты других профессий, представляя свои профессиональные знания в унифицированном виде. Ведь, по существу, каждый из специалистов оперирует модельными представлениями в своей области знаний. И именно этот модельный аспект может быть специфицирован средствами языка UML.

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

В этой статье рассказывается о новой эпохе разработки ПО, о ее влиянии на новые требования, выдвигаемые к языку UML, и об оптимальных методах их выполнения.
  7. "Моделирование данных в Rational Rose" Сергей Трофимов Описывается моделирование физического представления данных с использованием Rational Rose
  8. Язык UML . Общее представление о языке UML: структуры, графические элементы и диаграммы языка.
  9. Практический UML . Этот документ является переводом документа "Practical UML. A Hands-On Introduction for Developers". Практическое введение для разработчиков
  10. "Стандартный язык объектно-ориентированного моделирования UML" Вендров Александр Михайлович . История создания UML
  11. UML – унифицированный язык моделирования . Данный материал содержит начальные сведения о методах описания программных систем и нотациях, используемых в UML
  12. Язык UML. Руководство пользователя. Авторы: Грейди Буч, Джеймс Рамбо, Айвар Джекобсон
  13. "UML диаграммы в Rational Rose" Сергей Трофимов
  14. "Анализ и проектирование. Визуальное моделирование (UML) Rational Rose" Константин Домолего
  15. Библиотека Геннадия Верникова. Полные описания стандартов проектирования и моделирования.
  16. "Пример описания предметной области с использованием UML при разработке программных систем" Е.Б. Золотухина, Р.В. Алфимов. В статье на конкретном примере демонстрируется возможный подход к моделированию предметной области, основанный на применении Унифицированного Языка Моделирования (Unified Modeling Language) (UML)

       

Цель работы:

• изучение диаграмм пакетов, диаграммы компонентов и диаграммы размещения,
• изучение их применения в процессе проектирования.

Диаграммы пакетов (package diagrams)

Один из важнейших вопросов методологии создания программного обеспечения - как разбить большую систему на небольшие подсистемы? Именно с этой точки зрения изменения, связанные с переходом от структурного подхода к объектно-ориентированному, являются наиболее заметными. Одна из идей заключается в группировке классов в компоненты более высокого уровня. В UML такой механизм группировки носит название пакетов (package).

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

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

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

На рис. 14.1 мы имеем дело с классами предметной области, моделирующими деятельность организации и сгруппированными в два пакета: «Клиенты» и «Заказы».

Рис. 14.1. Классы предметной области, моделирующие деятельность организации

«Приложение сбора заказов» имеет зависимости с обоими пакетами предметной области. «Пользовательский интерфейс сбора заказов» имеет зависимости с «Приложением сбора заказов» и «Библиотекой GUI».

Зависимость между двумя пакетами существует в том случае, если имеется какая-либо зависимость между любыми двумя классами в пакетах. Например, если любой класс в пакете «Список рассылки» зависит от какого-либо класса в пакете «Клиенты», то между соответствующими пакетами существует зависимость.

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

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

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

Диаграммы компонентов (component diagrams)

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

Рис. 14.2.

Зависимости между компонентами должны совпадать с зависимостями между пакетами. Эти зависимости показывают, каким образом одни компоненты взаимодействуют с другими. Направление данной зависимости показывает уровень осведомленности о коммуникации. Если на панелях инструментов диаграмм размещения отсутствуют некоторые значки, то их можно настроить вызвав диалоговое окно View/Toolbar/Configure/Toolbars/Component Diagrams

Таблица 14.1. Описание кнопок панели инструментов диаграмм компонентов Rational Rose

Кнопка	Описание	Название
	Выбор элемента модели	Select tool
	Ввод текста	Text Box
	Комментарий	Note
	Связь комментария с элементом	Anchor Note to Item
	Компонент	Component
	Пакет	Package
	Зависимость	Dependency
	Тело задания	Task Body
	Спецификация задания	Task Specification
	Тело пакета	Package Body
	Спецификация пакета	Package Specification
	Главная программа	Main Program
	Спецификация подпрограммы	Subprogram Specification
	Тело попдпрограммы	Subprogram Body

Диаграммы размещения (deployment diagrams)

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

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

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

Рис. 14.3.

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

Таблица 14.2. Описание кнопок панели инструментов диаграмм размещения Rational Rosee

Примеры

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

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

На рис. 14.4 изображена диаграмма пакетов подсистемы «Служба занятости в рамках вуза» системы «Дистанционное обучение». Численная оценка для нее равна:

Рис. 14.4. Диаграмма пакетов

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

Рис. 14.5 . Диаграмма компонентов

На рис. 14.5 изображена диаграмма компонентов, построенная на основе диаграммы пакетов, изображенной на рис. 14.4. На рис. 14.6 изображена диаграмма размещения подсистемы «Служба занятости в рамках вуза». Оценка для данной диаграммы компонентов равна:

Оценка для диаграммы размещения равна:

Рис. 14.6. Диаграмма размещения

Упражнения

Упражнение 1. Создание диаграммы размещения системы регистрации

Распределенная конфигурация системы моделируется с помощью диаграммы размещения. Ее основные элементы:

• узел (node) - вычислительный ресурс (процессор или другое устройство (дисковая память, контроллеры различных устройств и т.д.). Для узла можно задать выполняющиеся на нем процессы;
• соединение (connection) - канал взаимодействия узлов (сеть).

Пример: сетевая конфигурация системы регистрации (без процессов) (рис. 14.7).

Ри с. 14.7. Сетевая конфигурация системы регистрации

Распределение процессов по узлам сети производится с учетом следующих факторов:

• используемые образцы распределения (трехзвенная клиент - серверная конфигурация, «толстый» клиент, «тонкий» клиент, равноправные узлы (peer-to-peer) и т.д.);
• время отклика;
• минимизация сетевого трафика;
• мощность узла;
• надежность оборудования и коммуникаций. Пример: распределение процессов по узлам (рис. 14.8).

Рис.

14.8. Сетевая конфигурация системы регистрации с распределением

Для того чтобы открыть диаграмму размещения, надо дважды щелкнуть мышью по представлению Deployment View (пред­ставлению размещения) в браузере.
Для того чтобы поместить на диаграмму процессор:

1. На панели инструментов диаграммы нажмите кнопку Processor.
2. Щелкните по диаграмме размещения в том месте, куда хотите поместить процессор.
3. Введите имя процессора.

В спецификациях процессора можно ввести информацию о его стереотипе, характеристиках и планировании. Стереотипы применяются для классификации процессоров (например, ком­пьютеров под управлением UNIX или ПК). Характеристики процессора - это его физическое описание. Оно может, в частности, включать скорость процессора и объем памяти.

Поле планирования (scheduling) процессора содержит описание того, как осуществляется планирование его процессов

• Preemptive (с приоритетом). Высокоприоритетные процессы имеют преимущество перед низкоприоритетными.
• Non preemptive (без приоритета). У процессов не имеется приоритета. Текущий процесс выполняется до его завершения, после чего начинается следующий.
• Cyclic (циклический). Управление передается между процессами по кругу. Каждому процессу дается определенное время на его выполнение, затем управление переходит к следующему процессу.
• Executive (исполнительный). Существует некоторый вычислительный алгоритм, который и управляет планированием процессов.
• Manual (вручную). Процессы планируются пользователем.

Для того чтобы назначить процессору стереотип.

1. Перейдите на вкладку General.
2. Введите стереотип в поле Stereotype.

Для введения характеристик и планирования процессора

1. Откройте окно спецификации процессора.
2. Перейдите на вкладку Detail.
3. Введите характеристики в поле характеристик.
4. Укажите один из типов планирования.

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

1. Выберите пункт Show Scheduling в открывшемся меню.

Для того чтобы добавить связь на диаграмму:

1. На панели инструментов нажмите кнопку Connection.
2. Щелкните по узлу диаграммы.
3. Проведите линию связи к другому узлу.

Для того чтобы назначить связи стереотипа:

1. Откройте окно спецификации связи.
2. Перейдите на вкладку General.
3. Введите стереотип в поле Stereotype (Стереотип).

Для того чтобы добавить процесс:

1. Щелкните правой кнопкой мыши по процессору в браузере.
2. Выберите пункт New > Process в открывшемся меню.
3. Введите имя нового процесса.

Для того чтобы показать процессы на диаграмме:

1. Щелкните правой кнопкой мыши по процессору.
2. Выберите пункт Show Processes в открывшемся меню.

Контрольные вопросы

1. Какую проблему проектирования призваны решить диаграммы пакетов?
2. В чем отличие диаграмм пакетов от диаграмм классов?
3. В чем смысл зависимости между элементами диаграммы пакетов?
4. Что такое интерфейс класса?
5. По каким признакам классы группируются в пакеты?
6. Какие виды элементов модели представлены на диаграмме компонентов?
7. Как связаны между собой диаграммы пакетов и диаграммы компонентов?
8. Что показывает диаграмма размещения?
9. Какие сущности.отображаются на диаграммах-размещения?
10. 10. В каких случаях необходимо применение диаграмм размещения?