ПР / ПР1 / РазрабСтанд2021_ЛР1

Введение

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

Одним из факторов, от которых зависит успех проекта, является наличие строгого стандартного языка моделирования. Таким языком является унифицированный язык моделирования UML (Unified Modeling Language). Построение моделей и диаграмм UML выполняется с помощью различных программных систем автоматизации проектирования, так называемых CASE –средств (Computer Aided Software Engineering). В качестве такого средства все часто используется IBM Rational Rose.

2

Средства UML

Универсальный язык моделирования UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. Стандарт UML версии 1.1, принятый OMG в 1997 году, предлагает следующий набор диаграмм для моделирования:

диаграммы вариантов использования или диаграммы прецедентов (use case diagrams), используемые для моделирования бизнес-процессов организации и требований к создаваемой системе;

диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними;

диаграммы поведения системы (behavior diagrams): o диаграммы взаимодействия (interaction diagrams);

-диаграммы последовательности (sequence diagrams);

-кооперативные диаграммы (collaboration diagrams) – для

моделирования процесса обмена сообщениями между объектами;

oдиаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое;

oдиаграммы деятельности (activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельности;

диаграммы реализации (implementation diagrams);

oдиаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы;

oдиаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.

3

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

Прецедент (вариант использования) – это последовательность действий,

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

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

-пользователи системы;

-другие системы, взаимодействующие с данной;

-время, если от него зависит запуск каких-либо событий в системе.

На рисунке 1.1 приведена диаграмма прецедентов для банковской системы с банкоматами. В этой системе определены два актера:

-клиент

-кредитная система

ишесть прецедентов, изображенных овалами, которые определяют основные действия, выполняемые системой:

-перевести деньги;

-сделать вклад;

-снять деньги со счета;

-просмотреть баланс;

-изменить PIN-код;

-сделать платеж.

4

Рисунок 1.1. Диаграмма прецедентов для банковской системы

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

5

Создание диаграммы прецедентов в среде Rational Rose

Запуск Rational Rose (Rational Rose Enterprise Edition

Откроется диалоговое окно для создания новой модели с тремя вкладками:

-New –новая модель;

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

-Recent – последние используемые модели с последующим выбором из списка нужной модели.

Если Вы создаете новую модель, то нажмите клавишу Cancel. Откроется окно экрана интерфейса Rational Rose со следующими элементами:

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

-окно документации (documentation window) – располагается под браузером, используется для работы с текстовым описанием элементов модели;

-панели инструментов (toolbars) и строка меню – в верхней части экрана;

-окно диаграммы (diagram window) с панелью элементов, которые можно наносить на диаграмму – для просмотра и редактирования одной или нескольких диаграмм UML.

Браузер – это иерархическая структура, позволяющая осуществлять навигацию по модели. С помощью браузера можно:

-добавлять к модели элементы;

-просматривать существующие элементы модели;

-просматривать существующие связи между элементами модели;

-перемещать элементы модели;

-переименовывать элементы модели;

-добавлять элементы модели на диаграмму;

-связывать элемент с файлом или адресом Интернета;

-группировать элементы в пакеты;

-работать с детализированной спецификацией элемента;

6

-открывать диаграмму.

Браузер поддерживает четыре представления (view):

-вариантов использования – прецедентов (папка, или пакет Use Case View);

-компонентов (папка, или пакет Component View);

-размещения (папка, или пакет Deployment View);

-логическое представление (папка, или пакет Logical View).

Представление вариантов использования содержит всех актеров, все прецеденты и диаграммы для конкретной системы.

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

-Классы;

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

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

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

-Пакеты, являющиеся группами взаимосвязанных классов.

Представление компонентов содержит:

-Компоненты, являющиеся физическими модулями системы;

-Диаграммы компонентов;

-Пакеты, являющиеся группами связанных компонентов. Представление размещения соответствует физическому размещению системы,

которое может отличаться от ее логической архитектуры. Представление размещения может содержать:

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

7

-Процессоры, включающие любые компьютеры, способные обрабатывать данные. Любой процесс выполняется на одном или нескольких процессорах.

-Устройства, т.е. любая аппаратура, не способная обрабатывать данные (терминалы ввода-вывода, принтеры и пр.).

-Диаграмма размещения.

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

В языке UML для прецедентов и актеров поддерживается несколько типов связей. Это - связи коммуникации (communication), включения (include), расширения (extend) и

обобщения (generalization).

Связь коммуникации (communication) –однонаправленная обычная связь. Направление стрелки указывает, кто инициирует коммуникацию.

Связь включения (include) – применяется тогда, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном прецеденте. В примере банковской системы прецеденты Снять деньги со счета и Сделать вклад должны опознать (аутентифицировать клиента), т.е. использовать прецедент аутентифицировать клиента. Направление связи в этом случае указывается от базового прецедента к используемому.

Связь расширения (extend) – применяется при описании

-изменений в нормальном поведении системы;

-дополнительных режимах;

-режимов, которые запускаются только при определенных условиях, например, сигнал тревоги;

-альтернативных потоков, которые запускаются по выбору актера. Связь обобщения (generalization) – показывает, что у нескольких актеров

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

8

служащий

служащий с почасовой оплатой временный

служащий

служащий на окладе

Рисунок 1.2. Связь обобщение для служащего

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

1)Создать актера в браузере. Для этого нужно из контекстно-зависимого (в дальнейшем будем обозначать сокращенно к.з.) меню, открытого (1с правой кнопкой мыши) на папке Use Case View браузера выполнить команду: New/Actor и дать актеру имя клиент. Таким же образом следует создать еще одного актера по имени кредитная система.

2)Создать прецеденты (сделать вклад, перевести деньги, изменить PIN-код, просмотреть баланс, снять деньги со счета, сделать платеж, аутентифицировать клиента, выполнить ускоренное снятие денег). Прецеденты создаются аналогично актерам, но по команде New/Use Case из к.з. меню на папке Use Case View браузера.

3)Создать диаграмму прецедентов (вариантов использования). Для этого из к.з. меню на папке Use Case View браузера выполнить команду New/Use Case Diagram и дать ей имя, например, диаграмма прецедентов банкомата.

4)Открыть диаграмму прецедентов (2с по имени диаграммы в браузере).

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

9

выделив актера (1с по актеру мышью), нужно из к.з. меню на актере выполнить команду Options/Stereotype Display/Icon .

6)Связать актеров с прецедентами. Для этого нужно воспользоваться кнопкой Unidirectional Association (однонаправленная ассоциация) на панели элементов диаграммы, которая располагается слева от диаграммы между диаграммой и браузером. При этом нужно протаскивать связь мышью по направлению от источника связи к потребителю (см. рисунок 1.1).

7)Отобразить связь включения между прецедентами Снять деньги со счета и Аутентифицировать клиента. Связь можно отобразить пунктирной линией, как это сделано на рисунке 1.1, а можно – сплошной. Для этого типа связи необходимо указать стереотип (include). Для этого нужно на линии связи открыть окно спецификации связи ( 2с на линии связи) и выбрать из списка Stereotype соответствующий стереотип (include).

8)Отобразить связь расширения между прецедентами Снять деньги со счета и Выполнить ускоренное снятие денег, и на линии связи указать стереотип extend.

Для того, чтобы фактически разработать систему, одной диаграммы прецедентов недостаточно, поскольку требуется описать более конкретные детали. Эти детали обычно описываются в документе, который называется «поток событий». А затем этот документ связывается с диаграммой. Целью такого документа является описание процесса обработки данных, реализуемого в рамках каждого прецедента (варианта использования). Этот документ подробно описывает, что будут делать пользователи системы и что – сама система, но не как это будет делаться. Обычно поток событий включает:

-краткое описание;

-предусловия (pre-conditions);

-основной поток событий;

-альтернативный поток событий;

-постусловия (post-condition).

Пример такого документа для прецедента Перевести деньги приведен в Приложении А.

Чтобы связать этот документ с прецедентом Перевести деньги, нужно:

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

10