Студопедия Главная Случайная страница Обратная связь

Разделы: Автомобили Астрономия Биология География Дом и сад Другие языки Другое Информатика История Культура Литература Логика Математика Медицина Металлургия Механика Образование Охрана труда Педагогика Политика Право Психология Религия Риторика Социология Спорт Строительство Технология Туризм Физика Философия Финансы Химия Черчение Экология Экономика Электроника

Диаграммы 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. И, наконец, создаются интерфейсы для обмена данными между задачами и синхронизации.

 







Дата добавления: 2014-11-12; просмотров: 2089. Нарушение авторских прав


Рекомендуемые страницы:


Studopedia.info - Студопедия - 2014-2019 год . (0.002 сек.) русская версия | украинская версия