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

Оглавление

Введение. 3

Диаграмма вариантов использования. 5

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

Диаграмма сотрудничества. 12

Диаграмма классов. 15

Диаграмма компонентов и развертывания. 21

Заключение. 25

Список литературы.. 26

Введение

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

Любой язык состоит из словаря и правил комбинирования слов для получения осмысленных конструкций. Так, в частности, устроены языки программирования, таковым является и UML. Отличительной его особенностью является то, что словарь языка образуют графические элементы. Каждому графическому символу соответствует конкретная семантика, поэтому модель, созданная одним разработчиком, может однозначно быть понята другим, а также программным средством, интерпретирующим UML. Отсюда, в частности, следует, что модель ПС, представленная на UML, может автоматически быть переведена на объектно-ориентированный язык программирования (такой, как Java, C++, VisualBasic), то есть, при наличии хорошего инструментального средства визуального моделирования, поддерживающего UML, построив модель, мы получим и заготовку программного кода, соответствующего этой модели.

Следует подчеркнуть, что UML – это именно язык, а не метод. Он объясняет, из каких элементов создавать модели и как их читать, но ничего не говорит о том, какие модели и в каких случаях следует разрабатывать. Чтобы создать метод на базе UML, надо дополнить его описанием процесса разработки программного средства. Примером такого процесса является Rational Rose.

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

По запросу Object Management Group (OMG) – организации, ответственной за принятие стандартов в области объектных технологий и баз данных назревшая проблема унификации и стандартизации была решена авторами трех наиболее популярных объектно-ориентированных методов – Г.Бучем, Д.Рамбо и А.Джекобсоном, которые объединенными усилиями создали версию UML 1.1, утвержденную OMG в 1997 году в качестве стандарта.

Диаграмма вариантов использования

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

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

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

Ø определить общие границы и контекст моделируемой предметной области;

Ø сформулировать общие требования к функциональному поведению проектируемой системы;

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

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

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

,

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

Порядок выполнения работы.

1. Разработать концепцию системы

Ø Описать основные объекты

Ø Сгруппировать объекты в классы

Ø Определить основные связи между классами

Ø Выделить в классах действующих лиц

2 Разработать диаграмму варианты использования (Use Cases)

2.1 Создать диаграммы варианты использования.

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

Ø Нажмите «+» следующий за Use Case View.

Ø Двойной клик на диаграмме Main (в случае создания поддиаграммы – создайте ее из контекстного меню, укажите ее имя, затем откройте ее двойным кликом, если диаграмма создается в рамках пакета создайте пакет, раскройте его «+» в дереве и откройте диаграмму Main).

Ø Установите размер изображения.

2.2 Создать вариант использования.

Вариант использования представляется овалом. Для его создания:

Ø На диаграмме нажать правую кнопку для появления контекстного меню. Выбрать команду New:Use Case. Это создаст неименованный вариант использования. (Также можно нажать значок «овала» в панели инструментов, а затем кликнув на диаграмме создать вариант использования)

Ø Создать имя для варианта использования.

Ø Заполнить спецификацию для варианта использования

2.3 Создать действующее лицо (ДЛ).

Действующее лицо представляется символом «человечка». Для создания ДЛ:

Ø На диаграмме нажать правую кнопку для появления контекстного меню. Выбрать команду New:Actor. Это создаст неименованное действующее лицо. (Также можно нажать значок «человечка» в панели инструментов, а затем кликнув на диаграмме создать вариант использования)

Ø Создать имя для действующего лица.

Ø Заполнить спецификацию для ДЛ

2.4 Создать связи.

На диаграмме могут быть несколько видов связей (обычная ассоциация, генерализация или обобщения, простая связь). Для создания связей на диаграмме:

Ø Нажмите инструмент, соответствующий виду связи (вид стрелки), на панели инструментов.

Ø Соедините указателем соответствующие объекты на диаграмме.

Ø Определите характеристики связи (мощность, направление и т.п.)

2.5 Создать комментарий (пояснение).

На диаграмме могут быть приведены необходимы комментарии. Для создания комментария на диаграмме:

Ø Нажмите комментарий на панели инструментов.

Ø Разместите его на диаграмме.

Ø Соедините комментарий с объектом диаграммы.

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

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

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

Участники диаграммы именуются следующим образом: имя: Класс, где и имя, и класс являются не обязательными, но если используется класс, то присутствие двоеточия обязательно.

Сообщения можно разделить на 2 вида: синхронные (synchronous message) – требующие возврата ответа и асинхронные (asynchronous message) – ответ не тебуется и вызывающий объект может продолжать работу. На диаграмме синхронные вызовы обозначаются закрашенными стрелочками. Асинхронные – незакрашенными или половинными стрелочками.

У первого сообщения, в нашей диаграмме, нет участника, пославшего его, поскольку оно приходит от неизвестного источника. Такое сообщение называется найденным сообщением (found message).

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

Если в сообщении требуется передать параметры, то они указываются в скобках через запятую, с указанием типа параметра messageText(text: string).

Рисунок 2 - диаграмма последовательности

Порядок выполнения работы.

1. Создание диаграммы Последовательности

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

Ø В окне вариантов использования вызвать контекстное меню.

Ø Выбрать команду меню New:Sequence Diagram. Это добавит новую диаграмму последовательности под именем NewDiagram.

Ø Введите имя диаграммы, расположите ее и измените размер (по необходимости).

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

Ø Выберите действующее лицо в окне просмотра.

Ø Переместить действующее лицо на диаграмму.

Для создания сообщение:

Ø Выбрать иконку сообщения на инструментальной панели.

Ø Нажать на объект, представляющий клиента (отправитель сообщения)

Ø Переместить сообщение к объекту, представляющему поставщика (приемник сообщения).

Ø Введите имя сообщения.

Объект может посылать сообщение себе. Это называется возвратным сообщением.

Поиск по сайту: