1 Дисциплина «Технология разработки программного обеспечения» тема 3 «Моделирование средствами UML»

2 Цель занятия - формирование: представлений о принципах создания диаграмм UML, умений моделировать бизнес-процессы с помощью диаграмм UML.

3 Структура дисциплины Раздел 3 Обзор методологий разработки ПП Раздел 2 Средства моделирования бизнес - процессов Раздел 4 Обзор и сравнение основных направлений в стандартизации разработки ПО Раздел 1 Основные положения разработки ПП Тема 5 MSF & MOF Тема 6 XP Тема 7 RAD Тема 8 RUP Тема 9 ICONIX Тема 10 Др. методологии Тема 11 ЕСПД Тема 13 ISO Тема 14 ISO 9000 Тема 15 SPICE Тема 16 CMM Тема 12 ГОСТ Тема 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 является специальным случаем класса, у которого имеются операции, но отсутствуют атрибуты. Для обозначения интерфейса используется специальный графический символ окружность или стандартный способ – прямоугольник класса со стереотипом >. На диаграмме вариантов использования интерфейс изображается в виде маленького круга, рядом с которым записывается его имя.

17 Расширения UML Управляющий класс (control class) класс, отвечающий за координацию действий других классов. На каждой диаграмме классов должен быть хотя бы один управляющий класс. Кроме специального обозначения управляющий класс может быть изображен в форме прямоугольника класса со стереотипом >. Класс-сущность (entity class) пассивный класс, информация о котором должна храниться постоянно и не уничтожаться с выключением системы. Класс-сущность может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом >. Граничный класс (boundary class) класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актерами, но является составной частью системы. Граничный класс может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом >.

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

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

20 Агрегация и композиция Компьютер Окно программы Монитор Заголовок Отличие агрегации от композиции состоит в том, что объект- источник композиции не может существовать отдельно от объекта-клиента композиции

21

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

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

24 Примеры объектов Объект без указания роли Объект с указанной ролью и классом Объект без класса, но с указанной ролью

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

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

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

28 Диаграмма последовательности имя объекта 1: Имя класса 1 имя объекта 3: Имя класса 3 имя объекта 2: Имя класса 2 [a>=0] [a<0]

29 Диаграмма состояний Название состояния Метка-действия/выражение-действия Метки действия: Entry – действие в момент входа в состояние Exit – действие в момент выхода из состояния Do действие выполняется в течение всего времени, пока объект находится в данном состоянии

30 Переходы Простой переход Имя события(список параметров) [сторожевое условие]выражение действия Активизация почтовой программы Загрузка почты с сервера Установить соединение [соединение установлено] Закончить загрузку почты [почтовый ящик пуст]/разорвать соединение

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

32 Диаграмма деятельности Преобразовать уравнение к каноническому виду Вычислить корни Вычислить дискриминант [дискриминант >=0] [дискриминант<0]

33

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

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

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

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

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