Диаграммы UML

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

В UML 2.0 выделяют следующие типы диаграмм, сгруппированные в две категории:

Структурные типы:

· диаграммы классов (Class Diagram);

· диаграммы объектов (Object Diagram, в частности, ‑ диаграммы пригодности, Robustness Diagram);

· диаграммы компонентов (Component Diagram);

· диаграммы развертывания (Deployment Diagram);

· диаграммы пакетов (Package Diagram);

· диаграммы композитных структур (Composite);

· диаграммы профилей (Profile Diagram)

Поведенческие типы:

· диаграммы прецедентов (Use Case Diagram);

· диаграммы активности/деятельности (Activity Diagram);

· диаграммы состояний (Statechart Diagram);

· диаграммы взаимодействия (Interaction Diagram)

· диаграммы последовательностей (Sequential Diagram);

· диаграммы коммуникаций (Communication)[15]

· диаграмма обзора взаимодействий (Interaction Overview Diagram);

· диаграммы таймирования (Timing Diagram)

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

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

Диаграмма композитных структур – это обобщение диаграммы классов, предназначенное для моделирования композитных программных систем с сервис-ориентированной архитектурой (Service-Oriented Architecture, SOA).

На диаграмме объектов представлены объекты и отношения между ними. Частным случаем диаграмм объектов является диаграмма пригодности (Robustness Diagram), используемая для указания объектов предметной области, которые участвуют в реализации требований пользователя.

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

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

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

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

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

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

7.2.3. Использование UML при моделировании систем
реального времени

Встраиваемые системы реального времени, встречающиеся в таких прикладных областях, как телекоммуникации, аэрокосми-ческие и оборонные приложения, обычно имеют тенденцию быть большими и сложными. Решающим для таких систем является то, что они должны быть разработаны в соответствии с разумной архитектурой. Хорошая архитектура не только упрощает создание первоначальной системы, но и, что более важно, обеспечивает адаптивность системы к изменениям, вызываемым постоянным появлением новых требований. Конструкции, полученные из подтвержденных практикой концепций, изначально описанные в языке моделирования RT UML (Real-Time UML), включены в спецификации языка UML, начиная с версии 2.0.

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

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

Хорошим примером объектно-ориентированной методики архитектурного проектирования и моделирования распределенных систем и систем реального времени является метод COMET (Concurrent Object Modeling and Architectural Design Method), базирующийся на языке UML и его расширении для моделирования систем реального времени ‑ Real-Time UML, [16]. В основе COMET лежит унифицированный процесс разработки объектно-ориентированного ПО компании Rational (RUP) и концепция прецедентов (вариантов) использования (Use-Case) языка UML.

Краткое описание методики COMET. На этапе моделирования требований (Requirements Modeling) система рассматривается как черный ящик. Формируется модель прецедентов, где определяются функциональные требования к системе в терминах исполнителей (Actors) и прецедентов (Use-Case).

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

На этапе проектного моделирования (Design Modeling) продумывается архитектура системы:

1. Аналитическая модель, в которой основное внимание уделялось предметной области, соотносится со средой, где будет эксплуатироваться программа, и с проектной моделью, где акцент ставится на область решения.

2. Формулируются критерии разбиения системы на подсистемы.

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

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

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

6. И, наконец, создаются интерфейсы для обмена данными между задачами и синхронизации.