Основные типы диаграмм в uml. Особенности жизненного цикла с использованием uml.

Диаграммы классов

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

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

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

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

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

Диаграммы использования (use-case) (диаграммы прецедентов)

Диаграммы прецедентов описывают функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования, которая будет видна пользователям системы. Диаграммы прецедентов (use case diagram) отражают прецеденты и актеров (частный случай классов), а также отношения между ними.

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

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

Вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Актер инициирует выполнение прецедента использования и получает от него результаты. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.

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

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

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

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

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

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

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

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

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

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

Диаграмма кооперации

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

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

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

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

Жизненный цикл UML (Rational Objectory Process)

Фирма Rational Software, разработавшая язык UML ( Unified Modeling Language - унифицированный язык моделиро­вания), предло­жила также и свою модель ЖЦ, которая называется Rational Objectory Process (ROP). Означенная технология прямого пере­вода не имеет, так как rational в данном случае употребляется в значении «рациональный» и как название фирмы одновременно, во-вторых, слова objectory в английском языке не существует, его лингвообразование аналогично слову repository (накопитель).

Перечислим основные свойства RОР-технологии.

Rational Objectory Process - итеративный процесс, в течение которого происходит последовательное уточнение результатов; направлен именно на создание моделей, анне на разработку каких-либо других элементов проекта(например, текстовых документов).

Действия Rational Objectory Process определяются в первую очередь блоками использования (Use case).

Rational Objectory Process разбит на циклы, каждый из которых, в свою очередь, состоит из четырех фаз:

· начальная стадия (Inception);

· разработка (Elaboration);

· конструирование (Construction);

· ввод в эксплуатацию (Transition).

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

Каждая стадия завершается в четко определенной контроль­ной точке (milestone). В этот момент времени должны достигать­ся важные результаты и приниматься критически важные реше­ния о дальнейшей разработке.

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

Окончанием начального этапа могут служить следующие ре­зультаты:

· начальный проектный словарь терминов;

· общее описание системы - основные требования к проекту, его характеристики и ограничения;

· начальная модель вариантов использования;

· начальный бизнес-план;

· план проекта, отражающий стадии и итерации;

· один или несколько прототипов.

На стадии разработки выявляются более детальные требова­ния к системе, выполняется высокоуровневый анализ предмет­ной области и проектирование базовой архитектуры системы, создается план конструирования и устраняются наиболее риско­ванные элементы проекта.

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

· модель предметной области, которая служит отправным пунктом для формирования основных абстракций предметной области; .

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

Стадия разработки занимает примерно пятую часть времени создания проекта, результатом которой являются:

· оценка времени реализации каждого варианта использо­вания;

· идентификация всех наиболее серьезных рисков и возмож­ности их ликвидации.

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

При этом необходимо отметить следующее:

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

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

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

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

· бета-тестирование, позволяющее убедиться, что новая сис­тема соответствует ожиданиям пользователей;

· параллельное функционирование с существующей (legacy) системой, которая подлежит постепенной замене;

· оптимизацию производительности;

· обучение пользователей и специалистов службы сопровож­дения.