Как построить диаграмму компонентов. UML-диаграмма. Виды диаграмм UML. Стандартная панель инструментов
Язык UML - это графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых при разработке программных систем.
Существует много хороших книг в которых описано в деталях про UML (местами даже очень подробно), мне хотелось бы собрать в одном месте основные понятия про диаграммы, сущности и связи между ними для быстрого вспоминания, что-то наподобие шпаргалки.
В заметке используется материалы из книжек: Иванов Д. Ю., Новиков Ф. А. Унифицированный язык моделирования UML и Леоненков. Самоучитель по UML .
Для начала определимся с редактором. Под Linux я перепробовал разные UML-редакторы, больше всего мне понравился UMLet , хоть он и написан на Java но шевелится весьма проворно и большинство заготовок сущностей в нем есть. Еще есть ArgoUML кроссплатформенный UML-редактор, написан тоже на Java, функционально-богат но подтормаживает больше.
Я остановился на UMLet , установим его под Arch Linux и Ubuntu :
# под Arch Linux yaourt -S umlet # под Ubuntu sudo apt-get install umlet
В UML все сущности можно разбить на такие типы:
- структурные;
- поведенческие;
- группирующие;
- аннотационные;
В UML используются четыре основных типа отношений:
Зависимость (dependency) - указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность. Графически отношение зависимости изображается в виде пунктирной линии со стрелкой, направленной от зависимой сущности к независимой.
Ассоциация (association) - имеет место, если одна сущность непосредственно связана с другой (или с другими - ассоциация может быть не только бинарной). Графически ассоциация изображается в виде сплошной линии с различными дополнениями, соединяющей связанные сущности.
Обобщение (generalization) - это отношение между двумя сущностями, одна из которых является частным (специализированным) случаем другой. Графически обобщение изображается в виде линии с треугольной не закрашенной стрелкой на конце, направленной от частного (подкласса) к общему (суперклассу).
Реализации - отношение реализации указывает, что одна сущность является реализацией другой. Графически реализация изображается в виде пунктирной линии с треугольной не закрашенной стрелкой на конце, направленной от реализующей сущности к реализуемой.
В UML 2 определено 13 типов диаграмм. По стандартам каждая диаграмма должна иметь рамку с прямоугольником (правый нижний угол скошенный) в левом верхнем углу, в котором указывается идентификатор диаграммы (тег) и название.
Диаграммы для изображения структуры системы :
- Диаграмма компонентов (component diagram, тег component );
- Диаграмма размещения (deployment diagram, тег deployment );
- Диаграмма классов (class diagram, тег class );
- Диаграмма объектов (object diagram, тег object );
- Диаграмма структуры внутренней (composite structure diagram, тег class );
Диаграммы для изображения поведения системы :
- Диаграмма синхронизации (interaction diagram, тег timing );
- Диаграмма деятельности (activity diagram, тег activity );
- Диаграмма последовательности (sequence diagram, тег sd );
- Диаграмма коммуникации (communication diagram, тег comm );
- Диаграмма автомата (state machine diagram, тег state machine );
- Обзорная диаграмма взаимодействия (interaction overview diagram, тег interaction );
Особняком стоят диаграммы:
- Диаграмма использования(use case diagram, тег use case);
- Диаграмма пакетов (package diagram, тег package );
Диаграмма использования
Диаграмма использования (use case diagram) - это наиболее общее представление функционального назначения системы.
Рассматривая диаграмму вариантов использования в качестве модели системы, можно ассоциировать ее с моделью черного ящика. Каждый вариант использования определяет последовательность действий, которые должны быть выполнены проектируемой системой при взаимодействии ее с соответствующим актером.
На диаграмме использования применяются два типа основных сущностей: варианты использования и действующие лица, между которыми устанавливаются следующие основные типы отношений.
Отношение ассоциации - это отношение устанавливает, какую конкретную роль играет актер при взаимодействии с экземпляром варианта использования. Отношение ассоциации обозначается сплошной линией между актером и вариантом использования. Эта линия может иметь дополнительные условные обозначения, такие, например, как имя и кратность.
Отношение расширения - определяет взаимосвязь экземпляров отдельного варианта использования с более общим вариантом, свойства которого определяются на основе способа совместного объединения данных экземпляров. Так, если имеет место отношение расширения от варианта использования А к варианту использования В, то это означает, что свойства экземпляра варианта использования В могут быть дополнены благодаря наличию свойств у расширенного варианта использования А.
Отношение расширения между вариантами использования обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от того варианта использования, который является расширением для исходного варианта использования.
Отношение обобщения служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования В. В этом случае вариант А будет являться специализацией варианта В. При этом В называется предком или родителем по отношению А, а вариант А - потомком по отношению к варианту использования В.
Графически данное отношение обозначается сплошной линией со стрелкой в форме не закрашенного треугольника, которая указывает на родительский вариант использования.
Отношение обобщения между вариантами использования применяется в том случае, когда необходимо отметить, что дочерние варианты использования обладают всеми атрибутами и особенностями поведения родительских вариантов.
Отношение включения между двумя вариантами использования указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования.
Отношение включения, направленное от варианта использования А к варианту использования В, указывает, что каждый экземпляр варианта А включает в себя функциональные свойства, заданные для варианта В.
Графически данное отношение обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от базового варианта использования к включаемому.
Диаграмма классов
Диаграмма классов (class diagram) - основной способ описания статической структуры системы.
На диаграмме классов применяется один основной тип сущностей: классы (включая многочисленные частные случаи классов: интерфейсы, примитивные типы, классы-ассоциации и т.д.), между которыми устанавливаются следующие основные типы отношений: зависимости, ассоциации, обобщения, реализации.
Отношение зависимости в общем случае указывает некоторое семантическое отношение между двумя элементами модели или двумя множествами таких элементов, которое не является отношением ассоциации, обобщения или реализации. Отношение зависимости используется в такой ситуации, когда некоторое изменение одного элемента модели может потребовать изменения другого зависимого от него элемента модели.
Отношение зависимости графически изображается пунктирной линией между соответствующими элементами со стрелкой на одном из ее концов, при этом стрелка направлена от класса-клиента зависимости к независимому классу или классу-источнику.
Над стрелкой могут находится специальные ключевые слова (стереотипы):
- "access" - служит для обозначения доступности открытых атрибутов и операций класса-источника для классов-клиентов;
- "bind" - класс-клиент может использовать некоторый шаблон для своей последующей параметризации;
- "derive" - атрибуты класса-клиента могут быть вычислены по атрибутам класса-источника;
- "import" - открытые атрибуты и операции класса-источника становятся частью класса-клиента, как если бы они были объявлены непосредственно в нем;
- "refine" - указывает, что класс-клиент служит уточнением класса-источника в силу причин исторического характера, когда появляется дополнительная информация в ходе работы над проектом.
Отношение ассоциации соответствует наличию некоторого отношения между классами. Данное отношение обозначается сплошной линией с дополнительными специальными символами, которые характеризуют отдельные свойства конкретной ассоциации. В качестве дополнительных специальных символов могут использоваться имя ассоциации, а также имена и кратность классов-ролей ассоциации. Имя ассоциации является необязательным элементом ее обозначения.
Отношение агрегации имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности. Применяется для представления системных взаимосвязей типа "часть-целое".
Отношение композиции является частным случаем отношения агрегации. Это отношение служит для выделения специальной формы отношения "часть-целое", при которой составляющие части в некотором смысле находятся внутри целого. Специфика взаимосвязи между ними заключается в том, что части не могут выступать в отрыве от целого, т. е. с уничтожением целого уничтожаются и все его составные части.
Отношение обобщения является отношением между более общим элементом (родителем или предком) и более частным или специальным элементом (дочерним или потомком). Применительно к диаграмме классов данное отношение описывает иерархическое строение классов и наследование их свойств и поведения. При этом предполагается, что класс-потомок обладает всеми свойствами и поведением класса-предка, а также имеет свои собственные свойства и поведение, которые отсутствуют у класса-предка.
Диаграмма автомата
Диаграмма автомата (state machine diagram) или диаграмма состояний в UML 1 (state chart diagram) - это один из способов детального описания поведения в UML. В сущности, диаграммы автомата, как это следует из названия, представляют собой граф состояний и переходов конечного автомата нагруженный множеством дополнительных деталей и подробностей.
Диаграмма состояний описывает процесс изменения состояний только одного класса, а точнее - одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне. Именно для описания реакции объекта на подобные внешние воздействия и используются диаграммы состояний.
На диаграмме автомата применяют один основной тип сущностей - состояния, и один тип отношений - переходы, но и для тех и для других определено множество разновидностей, специальных случаев и дополнительных обозначений. Автомат представляет динамические аспекты моделируемой системы в виде ориентированного графа, вершины которого соответствуют состояниям, а дуги - переходам.
Начальное состояние представляет собой частный случай состояния, которое не содержит никаких внутренних действий (псевдосостояния). В этом состоянии находится объект по умолчанию в начальный момент времени. Оно служит для указания на диаграмме состояний графической области, от которой начинается процесс изменения состояний.
Конечное (финальное) состояние представляет собой частный случай состояния, которое также не содержит никаких внутренних действий (псевдосостояния). В этом состоянии будет находиться объект по умолчанию после завершения работы автомата в конечный момент времени.
Диаграмма деятельности
При моделировании поведения проектируемой или анализируемой системы возникает необходимость не только представить процесс изменения ее состояний, но и детализировать особенности алгоритмической и логической реализации выполняемых системой операций.
Диаграмма деятельности (activity diagram) - еще один способ описания поведения, который визуально напоминает старую добрую блок-схему алгоритма. Используется для моделирования процесса выполнения операций.
Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения.
На диаграмме деятельности применяют один основной тип сущностей - действие, и один тип отношений - переходы (передачи управления). Также используются такие конструкции как развилки, слияния, соединения, ветвления. Рекомендуется в качестве имени простого действия использовать глагол с пояснительными словами.
Диаграмма последовательности
Диаграмма последовательности (sequence diagram) - это способ описания поведения системы "на примерах".
Фактически, диаграмма последовательности - это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является пересылка сообщений между взаимодействующими объектами. Именно последовательность посылок сообщений отображается на данной диаграмме, отсюда и название.
На диаграмме последовательности применяют один основной тип сущностей - экземпляры взаимодействующих классификаторов (в основном классов, компонентов и действующих лиц), и один тип отношений - связи, по которым происходит обмен сообщениями.
Возможные виды сообщений (изображение взято у larin.in):
Диаграмма коммуникации
Диаграмма коммуникации (communication diagram) - способ описания поведения, семантически эквивалентный диаграмме последовательности. Фактически, это такое же описание последовательности обмена сообщениями взаимодействующих экземпляров классификаторов, только выраженное другими графическими средствами.
Таким образом, на диаграмме коммуникации также как и на диаграмме последовательности применяют один основной тип сущностей - экземпляры взаимодействующих классификаторов и один тип отношений - связи. Однако здесь акцент делается не на времени, а на структуре связей между конкретными экземплярами.
Диаграмма компонентов
Диаграмма компонентов (component diagram) - показывает взаимосвязи между модулями (логическими или физическими), из которых состоит моделируемая система.
Основной тип сущностей на диаграмме компонентов - это сами компоненты, а также интерфейсы, посредством которых указывается взаимосвязь между компонентами. На диаграмме компонентов применяются следующие отношения:
- реализации между компонентами и интерфейсами (компонент реализует интерфейс);
- зависимости между компонентами и интерфейсами (компонент использует интерфейс);
Диаграмма размещения
Диаграмма размещения (deployment diagram) наряду с отображением состава и связей элементов системы показывает, как они физически размещены на вычислительных ресурсах во время выполнения.
На диаграмме размещения, по сравнению с диаграммой компонентов, добавляется два типа сущностей: артефакт, который является реализацией компонента и узел (может быть как классификатор, описывающий тип узла, так и конкретный экземпляр), а также отношение ассоциации между узлами, показывающее, что узлы физически связаны во время выполнения.
Диаграмма объектов
Диаграмма объектов (object diagram) - является экземпляром диаграммы классов.
На диаграмме объектов применяют один основной тип сущностей: объекты (экземпляры классов), между которыми указываются конкретные связи (чаще всего экземпляры ассоциаций). Диаграммы объектов имеют вспомогательный характер - по сути это примеры (можно сказать, дампы памяти), показывающие, какие имеются объекты и связи между ними в некоторый конкретный момент функционирования системы.
Диаграмма внутренней структуры (composite structure diagram) используется для более подробного представления структурных классификаторов, прежде всего классов и компонентов.
Структурный классификатор изображается в виде прямоугольника, в верхней части которого находится имя классификатора. Внутри находятся части (parts). Частей может быть несколько. Части могут взаимодействовать друг с другом. Это обозначается с помощью соединителей (connectors) различных видов. Место на внешней границе части, к которому присоединяется соединитель, называется портом (port). Порты располагаются также на внешней границе структурного классификатора.
Обзорная диаграмма взаимодействия (interaction overview diagram) является разновидностью диаграммы деятельности с расширенным синтаксисом: в качестве элементов обзорной диаграммы взаимодействия могут выступать ссылки на взаимодействия (interaction use), определяемые диаграммами последовательности.
Диаграмма синхронизации
Диаграмма синхронизации (timing diagram) представляет собой особую форму диаграммы последовательности, на которой особое внимание уделяется изменению состояний различных экземпляров классификаторов и их временной синхронизации.
Диаграмма пакетов
Диаграмма пакетов (package diagram) - единственное средство, позволяющее управлять сложностью самой модели.
Основные элементы нотации - пакеты и зависимости с различными стереотипами.
Модель сущность-связь (ER-модель)
Аналогом диаграммы классов (UML) может быть ER-модель , которая используется при проектировании баз-данных (реляционной модели).
Модель сущность-связь (ER-модель) - модель данных, позволяющая описывать концептуальные схемы предметной области. ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями. wikipedia
Любой фрагмент предметной области может быть представлен как множество сущностей, между которыми существует некоторое множество связей.
Основные понятия:
Сущность (entity) - это объект, который может быть идентифицирован неким способом, отличающим его от других объектов, например, КЛИЕНТ 777 . Сущность фактически представляет из себя множество атрибутов.
Набор сущностей (entity set) - множество сущностей одного типа (обладающих одинаковыми свойствами).
Связь (relationship) - это ассоциация, установленная между несколькими сущностями.
Домен (domain) - множество значений (область определения) атрибута.
Существует три типа бинарных связей:
- один к одному - одиночный экземпляр сущности одного класса связан с одиночным экземпляром сущности другого класса, напимер, НАЧАЛЬНИК - ОТДЕЛ;
- 1 к N или один ко многим - одиночный экземпляр сущности одного класса связан со многими экземплярами сущности другого класса, например, ОТДЕЛ - СОТРУДНИК;
- N к M или многие ко многим - многие экземпляры сущности одного класса связаны со многими экземплярами сущности другого класса, например, СОТРУДНИК - ПРОЕКТ; Словарь основных понятий по UML
- Фаулер М. UML. Основы, 3-е издание
- Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя
Объект (object) - сущность, обладающая уникальностью и инкапсулирующая в себе состояние и поведение.
Класс (class) - описание множества объектов с общими атрибутами, определяющими состояние, и операциями, определяющими поведение.
Интерфейс (interface) - именованное множество операций, определяющее набор услуг, которые могут быть запрошены потребителем и предоставлены поставщиком услуг.
Кооперация (collaboration) - совокупность объектов, которые взаимодействуют для достижения некоторой цели.
Действующее лицо (actor) - сущность, находящаяся вне моделируемой системы и непосредственно взаимодействующая с ней.
Компонент (component) - модульная часть системы с четко определенным набором требуемых и предоставляемых интерфейсов.
Артефакт (artifact) - элемент информации, который используется или порождается в процессе разработки программного обеспечения. Другими словами, артефакт - это физическая единица реализации, получаемая из элемента модели (например, класса или компонента).
Узел (node) - вычислительный ресурс, на котором размещаются и при необходимости выполняются артефакты.
Поведенческие сущности предназначены для описания поведения. Основных поведенческих сущностей всего две: состояние и действие.
Состояние (state) - период в жизненном цикле объекта, находясь в котором объект удовлетворяет некоторому условию и осуществляет собственную деятельность или ожидает наступления некоторого события.
Действие (action) - примитивное атомарное вычисление.
Автомат является пакетом, в котором определено множество понятий, необходимых для представления поведения моделируемой сущности в виде дискретного пространства с конечным числом состояний и переходов.
Классификатор (classifier) - это дескриптор множества однотипных объектов.
Дополнительное чтиво
Язык UML
Унифицированный язык моделирования (UML ) является стандартным инструментом для создания «чертежей» программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать артефакты программных систем.
UML пригоден для моделирования любых систем: от информационных систем масштаба предприятия до распределенных Web -приложений и даже встроенных систем реального времени. UML – это язык для визуализации, специфицирования, конструирования и документирования артефактов программных систем. Язык моделирования, подобный UML, является стандартным средством для составления «чертежей» программного обеспечения.
Для понимания любой нетривиальной системы приходится разрабатывать большое количество взаимосвязанных моделей. В применении к программным системам это означает, что необходим язык, с помощью которого можно с различных точек зрения описать представления архитектуры системы на протяжении цикла ее разработки.
UML – это графический язык специфицирования, что означает построение точных и полных графических моделей, касающиеся анализа, проектирования и реализации, которые должны приниматься в процессе разработки и развертывания системы программного обеспечения.
UML – это язык конструирования, и модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования. Иными словами, UML-модель можно отобразить на такие языки, как Java , C++, Visual Basic , и даже на таблицы реляционной базы данных.
Такое отображение модели на язык программирования позволяет осуществлять прямое проектирование: генерацию кода из модели UML в какой-то конкретный язык. Можно решить и обратную задачу: реконструировать модель по имеющейся реализации.
UML позволяет решить проблему документирования системной архитектуры и всех ее деталей, предлагает язык для формулирования требований к системе и определения тестов и, наконец, предоставляет средства для моделирования работ на этапе планирования проекта и управления версиями.
Использование UML эффективно в:
· информационных системах масштаба предприятия;
· банковских и финансовых услугах;
· телекоммуникациях;
· на транспорте;
· оборонной промышленности, авиации и космонавтике;
· розничной торговле;
· медицинской электронике;
· науке;
· распределенных Web -системах.
Сфера применения UML не ограничивается моделированием ПО. Он позволяет моделировать, скажем, документооборот в юридических системах, структуру и функционирование системы обслуживания пациентов в больницах, осуществлять проектирование аппаратных средств.
1 Структура и компоненты языка UML
1.1 Общие принципы
Конструктивное использование языка UML основывается на понимании общих принципов моделирования сложных систем и особенностей процесса объектно-ориентированного анализа и проектирования (ООАП). Выбор выразительных средств для построения моделей сложных систем основывается на нескольких принципах.
Первым является принцип абстрагирования, который предписывает включать в модель только те аспекты проектируемой системы, которые имеют непосредственное отношение к выполнению системой своих функций или своего целевого предназначения. При этом все второстепенные детали опускаются, чтобы чрезмерно не усложнять процесс анализа и исследования полученной модели.
Вторым принципом построения моделей сложных систем является принцип многомодельности. Это значит, что никакое единственное представление сложной системы не является достаточным для адекватного выражения всех ее особенностей.
Еще одним принципом прикладного системного анализа является принцип иерархического построения моделей сложных систем. Этот принцип предписывает рассматривать процесс построения модели на разных уровнях абстрагирования или детализации в рамках фиксированных представлений.
Таким образом, процесс ООАП можно представить как поуровневый спуск от наиболее общих моделей и представлений концептуального уровня к более частным и детальным представлениям логического и физического уровня. При этом на каждом из этапов ООАП данные модели последовательно дополняются все большим количеством деталей, что позволяет им более адекватно отражать различные аспекты конкретной реализации сложной системы.
Объектно-ориентированный анализ и проектирование системы предусматривает использование словаря языка UML , включающего три вида строительных блоков: сущности, отношения, диаграммы.
1.2 Сущности
Основными объектно-ориентированными блоками являются сущности. В языке UML имеется четыре вида сущностей: структурные, поведенческие, группирующие, аннотационные.
Структурные сущности – это имена существительные в моделях на языке UML. Они представляют собой статические части модели, соответствующие концептуальным или физическим элементам системы. Существует пять разновидностей концептуальных и логических сущностей.
Класс (Class ) – это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой (рис. 3). Класс реализует один или несколько интерфейсов.
Рис. 3 Классы
Интерфейс (Interface ) – это совокупность операций, которые определяют набор услуг, предоставляемый классом или компонентом. Интерфейс описывает видимое извне поведение элемента (рис. 4). Интерфейс редко существует сам по себе – обычно он присоединяется к реализующему его классу или компоненту.
Рис. 4 Интерфейс
Кооперация (Collaboration ) определяет взаимодействие, и представляет совокупность ролей, работающих совместно, производят некоторый кооперативный эффект. Кооперация имеет как структурный, так и поведенческий аспект, – один и тот же класс может принимать участие в нескольких кооперациях (рис. 5).
Рис. 5 Кооперация
Прецедент (Use case ) – это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (Actor ). Прецедент применяется для структурирования поведенческих сущностей модели, и реализуются посредством кооперации (рис. 6).
Рис. 6 Прецедент
Активным классом (Active class ) называется класс, объекты которого вовлечены в один или несколько процессов (Threads ), и могут инициировать управляющее воздействие. Активный класс отличается от обычного класса тем, что деятельность его объектов осуществляется одновременно с деятельностью других элементов. Графически активный класс изображается так же, как простой класс, но ограничивающий прямоугольник рисуется жирной линией и обычно включает имя, атрибуты и операции (рис. 7)
Рис. 7 Активный класс
Компоненты и узлы соответствуют физическим сущностям системы.
Компонент (Component ) – это физическая заменяемая часть системы, соответствующая некоторому набору интерфейсов и обеспечивает его реализацию (рис. 8). Компонент – это физическая упаковка логических элементов, (классов, интерфейсов и кооперации), например компоненты СОМ+ или Java Beans , а также файлы исходного кода.
Рис. 8 Компонент
Узел (Node ) – это элемент, представляющий вычислительный ресурс, обладающий памятью и способностью обработки. Совокупность компонентов может размещаться в узле, а также мигрировать с одного узла на другой (рис. 9).
Рис. 9 Узел
Существуют также разновидности этих семи сущностей: актеры, сигналы, утилиты (виды классов), процессы и нити (виды активных классов), приложения, документы, файлы, библиотеки, страницы и таблицы (виды компонентов).
Поведенческие сущности (Behavioral things ) являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели. Существует всего два типа поведенческих сущностей.
Взаимодействие (Interaction ) – это поведение, суть которого заключается в обмене сообщениями между объектами для достижения определенной цели. С помощью взаимодействия описывается как отдельная операция, так и поведение совокупности объектов. Взаимодействие предполагает ряд других элементов, таких как сообщение (рис. 10), последовательность действий (поведение, инициированное сообщением) и связь (между объектами).
Рис. 10 Сообщение
Автомат (State machine ) – это алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события (рис. 11). С помощью автомата можно описать поведение отдельного класса или кооперации классов. С автоматом связан ряд других элементов: состояния, переходы (из одного состояния в другое), события (сущности, инициирующие переходы) и виды действий (реакция на переход).
Рис. 11 Состояние
Взаимодействия и автоматы семантически связаны с различными структурными элементами, такими как классы, кооперации и объекты.
Группирующие сущности являются организующими частями модели, это блоки, на которые можно разложить модель. Основной группирующей сущностью является пакет.
Пакет (Package ) – это универсальный механизм организации элементов в группы (рис. 12). В пакет можно поместить структурные, поведенческие и даже другие группирующие сущности. В отличие от компонентов, существующих во время работы программы, пакеты носят чисто концептуальный характер, то есть существуют только во время разработки.
Рис. 12 Пакеты
Существуют также вариации пакетов, например каркасы (Frameworks ), модели и подсистемы.
Аннотационные сущности – пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов – примечание.
Примечание (Note ) – это символ для изображения комментариев, присоединенных к элементу или группе элементов (рис. 13).
Рис. 13 Примечание
Примечания используются, чтобы снабдить диаграммы комментариями или ограничениями, которые можно выразить в виде неформального или формального текста. Существуют вариации этого элемента, например требования, где описывают некое желательное поведение с точки зрения внешней по отношению к модели.
1.2 Отношения
В языке UML определены четыре типа отношений : зависимость, ассоциация, обобщение, реализация. Эти отношения являются основными связующими строительными блоками в UML .
Зависимость (Dependency ) – это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой (рис. 14).
Рис . 14 Отношения зависимости
Ассоциация (Association ) – отношение, описывающее совокупность связей между объектами. Разновидностью ассоциации является агрегирование (Aggregation ) – структурное отношение между целым и его частями (рис. 15). Графическое изображение ассоциации может включать кратность и имена ролей (рис. 16).
Рис . 1 5 Агрегирование
Рис . 16 Имена ассоциаций
Обобщение (Generalization ) – это отношение “специализация/обобщение” (рис. 17), при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка). Таким образом, потомок (Child ) наследует структуру и поведение своего родителя (Parent ).
Рис. 17 Обобщение
Наконец, реализация (Realization ) – это отношение между классификаторами, при котором один классификатор определяет “контракт”, а другой гарантирует его выполнение (рис. 18).
Рис. 18 Реализация
Отношения реализации встречаются в двух случаях: во-первых, между интерфейсами и реализующими их классами или компонентами, а во-вторых, между прецедентами и реализующими их кооперациями.
1.2 Диаграммы
Диаграмма в UML – это графическое представление набора элементов, изображаемое в виде связанного графа с вершинами (сущностями) и ребрами (отношениями), используемое для визуализации системы с разных точек зрения. В UML выделяют 8 типов диаграмм (рис. 1 9 ).
Рис. 19 Интегрированная модель сложной системы в нотации UML
На диаграмме классов (C lass diagram) изображаются классы, интерфейсы, объекты и кооперации, а также их отношения. Используется при моделировании объектно-ориентированных систем.
На диаграмме вариантов использования (Use case diagram) представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Они используются при моделировании поведения системы.
Диаграммы последовательностей (Sequence diagram) и кооперации (Collaboration diagram) являются частными случаями диаграмм взаимодействия. На диаграммах взаимодействия представлены связи между объектами (сообщения, которыми объекты могут обмениваться). Диаграммы взаимодействия относятся к динамическому виду системы. При этом диаграммы последовательности отражают временную упорядоченность сообщений, а диаграммы кооперации – структурную организацию обменивающихся сообщениями объектов. Эти диаграммы могут быть преобразованы друг в друга.
На диаграммах состояний (S tatechart diagrams ) представлен автомат, включающий состояния, переходы, события и виды действий. Диаграммы состояний используются при моделировании поведения интерфейса, класса или кооперации, зависящем от последовательности событий.
Диаграмма деятельности (Activity diagram) представляют переходы потока управления между объектами от одной деятельности к другой внутри системы.
Диаграмма компонентов (Component diagram) представляет зависимости между компонентами. Диаграммы компонентов отображаются на один или несколько классов, интерфейсов или коопераций.
На диаграмме развертывания (Deployment diagram) представлена конфигурация обрабатывающих узлов системы и размещенных в них компонентов.
Показать разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами.
В качестве физических компонент могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.
План действий
После ознакомления с разделами («Пример», «Применение») вы можете попробовать свои силы в самостоятельном составлении диаграмм компонентов.
Как применять метод проектирования
Диаграммы компонентов следует применять, когда система разделяется на компоненты и надо показать их взаимоотношения посредством интерфейсов или схему компонентов в низкоуровневой структуре системы.
Пример использования
В объектно-ориентированном сообществе идут дебаты о том, в чем состоит различие между компонентом и обычным классом . Мы не станем обсуждать здесь этот спорный вопрос, но покажем нотацию языка 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 ).
Подписывайтесь на новости сайта, форму подписки вы можете найти в правой колонке сайта.
Если вы хотите научиться работать на фрилансе профессионально, приглашаем на курс « ».
олный проект программной системы представляет собой совокупность моделей логического и физического уровней, которые должны быть согласованы между собой. В языке UML для физического представления моделей систем используются диаграммы реализации (implementation diagrams), которые включают в себя диаграмму компонентов и диаграмму развертывания.
Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Она позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный и исполняемый код. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.
Диаграмма компонентов разрабатывается для следующих целей:
визуализации общей структуры исходного кода программной системы;
спецификации исполняемого варианта программной системы;
обеспечения многократного использования отдельных фрагментов программного кода;
представления концептуальной и физической схем баз данных.
В разработке диаграмм компонентов участвуют как системные аналитики и архитекторы, так и программисты. Диаграмма компонентов обеспечивает согласованный переход от логического представления к конкретной реализации проекта в форме программного кода. Одни компоненты могут существовать только на этапе компиляции программного кода, другие на этапе его исполнения. Диаграмма компонентов отражает общие зависимости между компонентами, рассматривая последние в качестве классификаторов.
Компоненты
Для представления физических сущностей в языке UML применяется специальный термин - компонент (component). Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели. Для графического представления компонента используется специальный символ - прямоугольник со вставленными слева двумя более мелкими прямоугольниками. Внутри большого прямоугольника записывается имя компонента и, при необходимости, некоторая дополнительная информация. Изображение этого символа может незначительно варьироваться в зависимости от характера ассоциируемой с компонентом информации.
Имя компонента подчиняется общим правилам именования элементов модели в языке UML и может состоять из любого числа букв, цифр и некоторых знаков препинания.
Отдельный компонент может быть представлен на уровне типа или на уровне экземпляра. Графическое изображение в обоих случаях одинаковое, но правила записи имени компонента отличаются. Если компонент представляется на уровне типа, то в качестве его имени записывается только имя типа с заглавной буквы. Если же компонент представляется на уровне экземпляра, то в качестве его имени записывается <имя компонента>":"<имя типаХ>. При этом вся строка имени подчеркивается.
В качестве простых имен принято использовать имена исполняемых файлов (с указанием расширения ехе после точки-разделителя), динамических библиотек (расширение dll), Web-страниц (расширение html), текстовых файлов (расширения txt или doc) или файлов справки (hip), файлов баз данных (DB) или файлов с исходными текстами программ (расширения h, cpp для языка C++, расширение java для языка Java), скрипты (pi, asp) и другие.
Поскольку конкретная реализация логического представления модели системы зависит от используемого программного инструментария, то и имена компонентов определяются особенностями синтаксиса соответствующего языка программирования.
В отдельных случаях к простому имени компонента может быть добавлена информация об имени объемлющего пакета и о конкретной версии реализации данного компонента. В этом случае номер версии записывается как помеченное значение в фигурных скобках. В других случаях символ компонента может быть разделен на секции, чтобы явно указать имена реализованных в нем интерфейсов.
Поскольку компонент как элемент физической реализации модели представляет отдельный модуль кода, иногда его комментируют с указанием дополнительных графических символов, иллюстрирующих конкретные особенности его реализации. Эти дополнительные обозначения для примечаний не специфицированы в языке UML, однако их применение упрощает понимание диаграммы компонентов, повышая наглядность физического представления.
В языке UML выделяют три вида компонентов:
развертывания, которые обеспечивают непосредственное выполнение системой своих функций. Такими компонентами могут быть динамически подключаемые библиотеки с расширением dll, Web-страницы на языке разметки гипертекста с расширением html и файлы справки с расширением hlp;
рабочие продукты. Как правило, это файлы с исходными текстами программ, например, с расширениями h или срр для языка C++;
исполнения, представляющие собой исполняемые модули - файлы с расширением ехе.
Эти элементы иногда называют артефактами, подчеркивая при этом их законченное информационное содержание, зависящее от конкретной технологии реализации соответствующих компонентов.
Другим способом спецификации различных видов компонентов является явное указание его стереотипа компонента перед именем. В языке UML для компонентов определены следующие стереотипы:
библиотека (library) - определяет первую разновидность компонента, который представляется в форме динамической или статической библиотеки;
таблица (table) - также определяет первую разновидность компонента, который представляется в форме таблицы базы данных;
файл (file) - определяет вторую разновидность компонента, который представляется в виде файлов с исходными текстами программ;
документ (document) - определяет вторую разновидность компонента, . который представляется в форме документа;
исполнимый (executable) - определяет третий вид компонента, который может исполняться в узле.
Интерфейсы
Следующим элементом диаграммы компонентов являются интерфейсы. В общем случае, интерфейс графически изображается окружностью, которая соединяется с компонентом отрезком линии без стрелок. Имя интерфейса должно начинаться с заглавной буквы "I" и записываться рядом с окружностью. Семантически линия означает реализацию интерфейса, а наличие интерфейсов у компонента означает, что данный компонент реализует соответствующий набор интерфейсов.
Другим способом представления интерфейса на диаграмме компонентов является его изображение в виде прямоугольника класса со стереотипом «интерфейс» и возможными секциями атрибутов и операций. Как правило, этот вариант обозначения используется для представления внутренней структуры интерфейса, которая может быть важна для реализации.
При разработке программных систем интерфейсы обеспечивают не только совместимость различных версий, но и возможность вносить существенные изменения в одни части программы, не изменяя другие ее части. Таким образом, назначение интерфейсов существенно шире, чем спецификация взаимодействия с пользователями системы (актерами).
Зависимости
В общем случае отношение зависимости также было рассмотрено ранее. Напомним, что зависимость не является ассоциацией, а служит для представления только факта наличия такой связи, когда изменение одного элемента модели оказывает влияние или приводит к изменению другого элемента модели. Отношение зависимости на диаграмме компонентов изображается пунктирной линией со стрелкой, направленной от клиента (зависимого элемента) к источнику (независимому элементу).
Зависимости могут отражать связи модулей программы на этапе компиляции и генерации объектного кода. В другом случае зависимость может отражать наличие в независимом компоненте описаний классов, которые используются в зависимом компоненте для создания соответствующих объектов. Применительно к диаграмме компонентов зависимости могут связывать компоненты и импортируемые этим компонентом интерфейсы, а также различные виды компонентов между собой.
В первом случае рисуют стрелку от компонента-клиента к импортируемому интерфейсу. Наличие стрелки означает, что компонент не реализует соответствующий интерфейс, а использует его в процессе своего выполнения. Причем на этой же диаграмме может присутствовать и другой компонент, который реализует этот интерфейс.
Другим случаем отношения зависимости на диаграмме компонентов является отношение между различными видами компонентов. Наличие подобной зависимости означает, что внесение изменений в исходные тексты программ или динамические библиотеки приводит к изменениям самого компонента. При этом характер изменений может быть отмечен дополнительно.
На диаграмме компонентов могут быть также представлены отношения зависимости между компонентами и реализованными в них классами. Эта информация имеет значение для обеспечения согласования логического и физического представлений модели системы. Если требуется подчеркнуть, что некоторый компонент реализует отдельные классы, то для обозначения компонента используется расширенный символ прямоугольника. При этом прямоугольник компонента делится на две секции горизонтальной линией. Верхняя секция служит для записи имени компонента, а нижняя секция - для указания дополнительной информации.
Внутри символа компонента могут изображаться другие элементы графической нотации, такие как классы (компонент уровня типа) или объекты (компонент уровня экземпляра). В этом случае символ компонента изображается таким образом, чтобы вместить эти дополнительные символы.
Объекты, которые находятся в отдельном компоненте-экземпляре, изображаются вложенными в символ данного компонента. Подобная вложенность означает, что выполнение компонента влечет выполнение соответствующих объектов.
Разработка диаграммы компонентов предполагает использование информации как о логическом представлении модели системы, так и об особенностях ее физической реализации. До начала разработки необходимо принять решения о выборе вычислительных платформ и операционных систем, на которых предполагается реализовывать систему, а также о выборе конкретных баз данных и языков программирования.
После этого можно приступать к общей структуризации диаграммы компонентов. В первую очередь, необходимо решить, из каких физических частей (файлов) будет состоять программная система. На этом этапе следует обратить внимание на такую реализацию системы, которая обеспечивала бы не только возможность повторного использования кода за счет рациональной декомпозиции компонентов, но и создание объектов только при их необходимости.
Речь идет о том, что общая производительность программной системы существенно зависит от рационального использования вычислительных ресурсов. Для этой цели необходимо большую часть описаний классов, их операций и методов вынести в динамические библиотеки, оставив в исполняемых компонентах только самые необходимые для инициализации программы фрагменты программного кода.
После общей структуризации физического представления системы необходимо дополнить модель интерфейсами и схемами базы данных. При разработке интерфейсов следует обращать внимание на согласование (стыковку) различных частей программной системы. Включение в модель схемы базы данных предполагает спецификацию отдельных таблиц и установление информационных связей между таблицами.
Завершающий этап построения диаграммы компонентов связан с установлением и нанесением на диаграмму взаимных связей между компонентами, а также отношений реализации. Эти отношения должны иллюстрировать все важнейшие аспекты физической реализации системы, начиная с особенностей компиляции исходных текстов программ и заканчивая исполнением отдельных частей программы на этапе ее выполнения. Для этой цели можно использовать различные виды графического изображения компонентов.
При разработке диаграммы компонентов следует придерживаться общих принципов создания моделей на языке UML. В частности, необходимо использовать уже имеющиеся в языке UML компоненты и стереотипы. Для большинства типовых проектов этого набора элементов может оказаться достаточно для представления компонентов и зависимостей между ними.
Если проект содержит некоторые физические элементы, описание которых отсутствует в языке UML, то следует воспользоваться механизмом расширения и использовать дополнительные стереотипы для отдельных нетиповых компонентов или помеченные значения для уточнения их отдельных характеристик.
Следует обратить внимание, что диаграмма компонентов, как правило, разрабатывается совместно с диаграммой развертывания, на которой представляется информация о физическом размещении компонентов программной системы по ее отдельным узлам.
На схеме компонентов показаны части конструкции программной системы. Схема компонентов помогает визуализировать высокоуровневую структуру системы и поведение служб, предоставляемых и потребляемых этими элементами через интерфейсы. Чтобы создать UML-схему компонентов, в меню Архитектура щелкните Создать схему.
Схему компонентов можно использовать, чтобы описать конструкцию системы, реализуемую на любом языке и в любом стиле. Нужно только определить части конструкции, взаимодействующие с другими частями через ограниченный набор входных и выходных каналов. Можно использовать компоненты любого масштаба, взаимосвязанные любым способом.
В следующей таблице описаны элементы, которые можно использовать на схеме компонентов, и их основные свойства.
Фигура |
Элемент |
Описание и основные свойства |
Компонент |
Допускающий повторное использование функциональный элемент системы. Компонент предоставляет и потребляет поведение через интерфейсы и может использовать другие компоненты. Можно скрывать или отображать внутренние части компонента с помощью элемента управления "развернуть/свернуть" (9). Компонент - это вид класса. Является неявно создаваемым экземпляром. Если значение true (по умолчанию), компонент существует только как артефакт конструкции. Во время выполнения существует только ее часть. |
|
Предоставленный порт интерфейса |
Представляет группу сообщений или вызовов, реализуемых компонентом и доступных для использования другими компонентами или внешними системами. Порт - это свойство компонента, имеющее в качестве типа интерфейс. |
|
Требуемый порт интерфейса |
Представляет группу сообщений или вызовов, отправляемых компонентом другим компонентам или внешним системам. Компонент предназначен для соединения с компонентами, которые предоставляют хотя бы эти операции. Порт имеет в качестве типа интерфейс. |
|
Зависимость |
Может использоваться для указания, что требуемый интерфейс одного компонента может соответствовать предоставленному интерфейсу другого компонента. Зависимости также можно использовать в более общем случае при работе с элементами модели, чтобы показать, что конструкция одного зависит от конструкции другого. |
|
Атрибут компонента, тип которого, как правило, является другим компонентом. Часть используется при внутреннем проектировании ее родительского компонента. Графически части изображаются вложенными в родительский компонент. Чтобы создать часть существующего типа компонента, перетащите компонент из Проводника по моделям UML в компонент-владелец. Чтобы создать часть нового типа, выберите инструмент Компонент и щелкните компонент-владелец. Например, компонент Car имеет части engine:CarEngine, backLeft:Wheel, frontRight:Wheel и т. д. Несколько частей могут иметь один и тот же тип, и разные компоненты могут иметь части одного типа. Тип. Тип части, определяемый в другом месте модели. Как правило, типом является другой компонент. Кратность. По умолчанию используется значение 1. Можно задать значение 0..1, чтобы указать, что часть может иметь значение null, или задать значение *, чтобы указать, что часть является коллекцией экземпляров данного типа. Также в качестве значения можно задать любое выражение, которое можно оценить в числовом диапазоне. |
||
Сборка части |
Соединение между требуемыми портами интерфейса одной части и предоставленными портами интерфейса другой. Реализация сборки части для разных компонентов может различаться. Соединенные части должны иметь один родительский компонент. |
|
Делегирование |
Связывает порт с интерфейсом одной из частей компонента. Указывает, что сообщения, отправленные компоненту, обрабатываются этой частью, или что сообщения, отправленные этой частью, отсылаются из родительского компонента. |
|
(не показана) |
Обобщение |
Указывает, что один компонент наследуется от другого. Части и интерфейсы наследуются. |
Элемент управления "развернуть/свернуть" |
Позволяет скрывать или отображать внутренние части компонента. |
|
(не показана) |
15.2. Назначение и состав диаграммы компонентов
Диаграмма компонентов позволяет определить состав программных компонентов, в роли которых может выступать исходный, бинарный и исполняемый код, а также установить зависимости между ними.
При разработке диаграмм компонентов преследуются цели:
Спецификация общей структуры исходного кода системы;
Спецификация исполнимого варианта системы.
Данная диаграмма обеспечивает согласованный переход от логического к физическому представлению системы в виде программных компонентов. Одни компоненты могут существовать только на этапе компиляции программного кода, другие – на этапе его исполнения. Основными элементами диаграммы являются компоненты, интерфейсы и зависимости между ними . Кроме этого, на ней могут отображаться ключевые классы, входящие в компоненты.
Компонент (англ. component) – это физическая часть системы. Компоненты, представляющие собой файлы с исходным кодом классов, библиотеки, исполняемые модули и т.п., которые должны обладать согласованным набором интерфейсов. Для их графического представления используются следующие графические символы.
Рис. 15.2. Примеры компонентов
Внутри прямоугольника записывается имя компонента и, возможно, некоторая дополнительная информация в виде помеченного значения.
Компоненты могут иметь следующие стандартные стереотипы:
- «file» – любой файл, кроме таблицы:
o «executable» – программа (исполняемый файл);
o «library» – статическая или динамическая библиотека;
o «source» – файл с исходным текстом программы;
o «document» – остальные файлы (например, файл справки);
- «table» – таблица базы данных.
Внутри компонента, как и класса, могут быть выделены дополнительные секции, в которых указываются предоставляемые (provided) или необходимые для работы (required) интерфейсы и классы, методы (operations), наименование файла-компонента (artifacts) и т.п.
Рис. 15.3. Компонент с секциями
Интерфейс (англ. interface) – это внешне видимый, именованный набор операций, который класс, компонент или подсистема может предоставить другому классу, компоненту или подсистеме, для выполнения им своих функций. В некоторых языках программирования, в частности в Java, интерфейс представляет собой отдельный класс, включаемый и реализуемый (конкретизируемый) в части программного кода операций в составе других классов. На диаграмме компонентов интерфейс отображается так же, как и на (слева от компонента необходимые для работы интерфейсы, справа - предоставляемые).
Рис. 15.4. Способы отображения интерфейсов
Отношение ассоциации отображается между компонентами и их интерфейсами. Отношение зависимости означает зависимость реализации одних компонентов от реализации других. Такое возможно в следующих случаях:
В методах классов одного компонента (зависимого) осуществляется вызов методов или обращение к атрибутам классов другого компонента (независимого);
Компонент состоит из других компонентов (например, при сборке исполняемого файла из файлов с исходными кодами);
Компонент осуществляет чтение или запись данных в другой компонент;
Связь между таблицами БД;
Ввиду многоцелевого назначения диаграммы компонентов при ее разработке следует придерживаться следующих правил и рекомендаций .
1. Перед разработкой диаграмм компонентов необходимо решить, из каких физических частей (файлов) будет состоять программная система. При этом должно быть решено две задачи – распределение классов по файлам исходных кодов и по подсистемам. В последнем случае может помочь распределение классов по специализированным (функционально-ориентированным на предметную область) пакетам. На этом этапе следует обратить внимание на такую реализацию системы, которая обеспечивала бы возможность повторного использования кода за счет рациональной декомпозиции системы, т. е. минимизировать количество связей между компонентами.
2. При спецификации общей структуры исходного кода системы необходимо учитывать специфику языка программирования, с помощью которого реализуются компоненты. В частности в Java рекомендуется отдельный класс описывать в отдельном файле, несмотря на то, что язык позволяет описывать несколько классов в одном файле и использовать механизм внутренних классов. Диаграмма компонентов, применяемая для рассматриваемой цели, изображена на следующем рисунке.
Рис. 15.5. Фрагмент диаграммы компонентов, специфицирующей структуру исходного кода
Диаграмма на рис. 15.5 показывает состав классов (файлов), из которых состоит исполняемый компонент iskraPUT.jar, а также зависимости между классами.
3. Для спецификации исполнимого варианта системы необходимо иметь в наличии предварительную топологию системы, т. е. набросок . Для каждого узла в сети может быть построена диаграмма компонентов, определяющая набор файлов, необходимых для работы подсистемы (подсистем) на отдельном рабочем месте.
Рис. 15.6. Пример диаграммы компонентов, специфицирующей состав компонентов на рабочем месте пользователя
4. На диаграмме могут быть представлены отношения зависимости между компонентами и включенными в них классами. Эта информация имеет важное значение для обеспечения согласованности между логическим и физическим представлениями системы. В этом случае зависимость можно показать двумя способами:
Классы показать отдельно от компонента и связать компонент с каждым классом отношением зависимости. Например, на рис. 15.5 вместо компонентов с расширением «java» показать соответствующие им классы;
Классы отобразить внутри символа компонента.
6. Для наглядного отображения специфики компонентов можно вместо стандартного символа компонента со строковым стереотипом внутри использовать графические стереотипы.