1

Дисциплина

«Технология разработки программного обеспечения»

тема 3 «Моделирование средствами UML»

2

Цель занятия -

формирование: представлений о принципах создания

диаграмм UML, умений моделировать бизнес-процессы с

помощью диаграмм UML.

3

Структура дисциплины

Раздел 3Обзорметодологийразработки ПП

Раздел 2Средства моделированиябизнес - процессов

Раздел 4Обзор и срав-нение основныхнаправленийв стандартизацииразработки ПО

Раздел 1Основные положенияразработки ПП

Тема 5

MSF & MOF

Тема 6

XPТема 7

RADТема 8

RUPТема 9

ICONIX

Тема 10

Др. методологии

Тема 11ЕСПД

Тема 13ISO 12207

Тема 14ISO 9000

Тема 15SPICE

Тема 16CMM

Тема 12ГОСТ 28195

Тема 17Сравнение

направлений в стандартизации

Тема 3

UMLТема 4

SADT

Тема 1

Основы разработкипрограммного продукта

Тема 2

Стадии и моделиЖЦ ПО

«Технология разработки программного «Технология разработки программного обеспечения»обеспечения»

4

UML (Unified Modeling Language)

5

Интегрированная модель сложной системы в нотации UML

UML

Use-Case DiagramДиаграмма вариантов

использования

Class DiagramДиаграмма классов

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

Activity DiagramДиаграмма

Деятельности

Sequence DiagramДиаграмма

Последовательности

Collaboration DiagramДиаграмма Кооперации

Component DiagramДиаграмма

Компонентов

Deployment DiagramДиаграмма

Развертывания

КонцептуальноеКонцептуальное

моделированиемоделирование

ЛогическоеЛогическое

моделированиемоделирование

ФизическоеФизическое

моделированиемоделирование

6

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

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

Разработка диаграммы данного вида преследует следующие цели:

Определить общие границы предметной области Сформулировать общие требования к

функциональному поведению системы Разработать исходную концептуальную модель для

дальнейшего детализирования Подготовить исходную документацию для

взаимодействия разработчиков системы с ее заказчиками и пользователями

7

Актеры

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

Графическое изображение актера

Зарегистрироваться на курс

Графическое изображениеВарианта использования

8

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

Зарегистрироватьсяна курс1 *

Актер Вариант использования

Ассоциация

9

Отношения на диаграммевариантов использования Отношение ассоциации Отношение расширения Отношение обобщения Отношение включения

“extend”

“include”

10

Отношение ассоциации

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

Эта линия может иметь дополнительные обозначения, например имя и кратность.

Зарегистрироватьсяна курс1 *

11

Отношение расширения

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

Зарегистрироватьсяна курс

Запросить каталогвсех курсов

“extend”

12

Отношение обобщения

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

Зарегистрироватьсяна курс

Зарегистрироватьсяна курс по ХР

13

Отношение включения

Отношение включения указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования

Аутентификация Редактироватьличные данные

“include”

14

Дополнительные обозначения языка UML для бизнес-моделирования Бизнес-актер (business actor) – индивидуум, группа, организация,

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

Бизнес-Сотрудник (business worker) – индивидуум, который действует внутри моделируемой бизнес-системы, взаимодействует с другими сотрудниками и является участником бизнес-процесса моделируемой системы.

Бизнес-вариант использования (business use case) — вариант использования, определяющий последовательность действий моделируемой системы, направленных на выполнение отдельного бизнес-процесса.

Бизнес-актер Бизнес-сотрудник Бизнес-вариант использования

15

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

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

Имя_класса

+ аттрибут_1:integer=0# /аттрибут_2:Boolean- аттрибут_3:String

операция_1():integerоперация_2()операция_3():String

+ обозначает атрибут с областью видимости общедоступный(public)

# обозначает атрибут с областью видимости типа защищенный(protected)

- Обозначает атрибут с областью видимости типа закрытый(private)

<квантор видимости><имя атрибута>:<тип атрибута>=<значение по умолчанию>

16

Интерфейсы

Интерфейс (interface) — именованное множество операций, которые характеризуют поведение отдельного элемента модели.

Интерфейс в контексте языка UML является специальным случаем класса, у которого имеются операции, но отсутствуют атрибуты. Для обозначения интерфейса используется специальный графический символ окружность или стандартный способ – прямоугольник класса со стереотипом <<interface>>.

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

Датчик Камера

17

Расширения UML Управляющий класс (control class) — класс, отвечающий за координацию

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

Класс-сущность (entity class) — пассивный класс, информация о котором должна храниться постоянно и не уничтожаться с выключением системы. Класс-сущность может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом <<entity>>.

Граничный класс (boundary class) — класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актерами, но является составной частью системы. Граничный класс может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом <<boundary>>.

Управляющий класс Класс-сущность Граничный класс

18

Отношения классов

Отношение зависимости Отношение агрегации Отношение композиции Отношение обобщения

19

Пример отношений

Класс BКласс C

Класс D

Класс A

20

Агрегация и композиция

Компьютер

Окно программы

Монитор

Заголовок

Отличие агрегации от композиции состоит в том, что объект-источник композиции не может существовать отдельно от объекта-клиента композиции

21

Условие

Участник

Свойство

Использует

0..n

0..n

0..n

0..n Пьесса

Роль в пьессе

Акт

1..n1..n

1..n1..n

Обучаемый

Преподаватель

Учебный объект

Сервис

Среда

РезультатУведомление <Вызывает

Активность обучения

Поддерживающая активность

Активность

0..n1..n 0..n1..n

Использую>

Структура активностей

0..n

1..n

0..n

1..n

ПререквизитыМетод

1..n1..n

0..n0..n

Цель обучения

0..n0..n

Разработан с учетом>

Роль

0..n0..n 0..n0..n

Осуществляет>

0..n

0..n

0..n

0..n

22

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

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

Кооперация определяет структуру поведения системы в терминах взаимодействия участников этой кооперации

Кооперация(collaboration) — спецификация множества объектов отдельных классов, совместно взаимодействующих с целью реализации отдельных вариантов использования в общем контексте моделируемой системы.

23

Объекты

Имя объекта в общем случае представляется строкой: <собственное имя объекта >'/‘<Имя роли класса>:<Имя класса >

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

24

Примеры объектов

с/обработчик запросов:сервер

Клиент/инициатор запроса

Объект без указания роли

о:Окружность

Объект с указанной рольюи классом

Объект без класса, но с указанной ролью

25

Сообщения Сплошная линия с треугольной стрелкой

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

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

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

26

Пример диаграммы кооперации в Rational Rose

: Учащийся :Форма подписки на курсы

:Контроллер регистрации

4: Показать доступные операции

Учащийся выбирает действие 5,6 или 7 1: Подписка на курс

5: Создать расписание6: Редактировать расписание

7: Удалить расписание

2: Окончен ли набор

3:

27

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

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

28

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

имя объекта1:Имя класса1

имя объекта3:Имя класса3

имя объекта2:Имя класса2

[a>=0]

[a<0]

29

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

Название состояния

Метка-действия/выражение-действия

Метки действия:

•Entry – действие в момент входа в состояние

•Exit – действие в момент выхода из состояния

•Do действие выполняется в течение всего времени, пока объект находится в данном состоянии

30

Переходы

Простой переход

Имя события(список параметров)[сторожевое условие]выражение действия

Активизация почтовой

программы

Загрузка почты ссервера

Установить соединение[соединение установлено]

Закончить загрузку почты[почтовый ящик пуст]/разорвать соединение

31

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

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

Графически деятельность обозначается так:

Преобразовать уравнениек каноническому виду

32

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

Преобразовать уравнениек каноническому виду

Вычислить корни

Вычислить дискриминант

[дискриминант >=0]

[дискриминант<0]

33

Оценка

Подготовка

Практика по дисциплине "Advising"

Тестирование по дисциплине "Adviding"

Практика по дисциплине "Anticipating"

Тестирование по дисциплине "Anticipating"

Экзамен(запрос на оценку)

Выбор

Обеспечивает обратную связь

Аттестация и оценка

Обеспечивает обратную связь

Аттестация и оценка

[ Студент имеет оценки по тестам ]

ПреподавательСтудентЭкзаменатор

34

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

Диаграмма компонентов является физическим представлением модели системы

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

35

Компоненты

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

BaseLib<<DLL>>

StudyLib<<DLL>>

MainProgram<<EXE>>

36

Диаграмма развертывания

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

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

38

Пример диаграммы развертывания

Учащийся

Преподаватель

Модемное соединение

Сервер

Сеть, 10 Мбит