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

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

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

3. Структура дисциплины «Технология разработки программного обеспечения» Раздел 1 Основные положения разработки ПП Тема 1 Основы разработки программного продукта Тема 2 Стадии и модели ЖЦ ПО Раздел 2 Средства моделирования бизнес - процессов Тема 3 UML Тема 4 SADT Раздел 3 Обзор методологий разработки ПП Тема 10 Др. методологии Тема 5 MSF & MOF Тема 8 RUP Тема 9 ICONIX Тема 6 XP Тема 7 RAD Раздел 4 Обзор и срав- нение основных направлений в стандартизации разработки ПО Тема 11 ЕСПД Тема 12 ГОСТ 28195 Тема 13 ISO 12207 Тема 14 ISO 9000 Тема 15 SPICE Тема 16 CMM Тема 17 Сравнение направлений в стандартизации

4. UML (Unified Modeling Language)

5. Интегрированная модель сложной системы в нотации UML Концептуальное моделирование Логическое моделирование Use-Case Diagram Диаграмма вариантов использования Class Diagram Диаграмма классов Collaboration Diagram Диаграмма Кооперации Deployment Diagram Диаграмма Развертывания Sequence Diagram Диаграмма Последовательности UML Statechart Diagram Диаграмма Состояний Component Diagram Диаграмма Компонентов ActivityDiagram Диаграмма Деятельности Физическое моделирование

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. Диаграмма классов Является логической моделью разрабатываемой системы. Служит для представления статической структуры системы в терминологии классов объектно-ориентированного программирования. <квантор видимости><имя атрибута>:<тип атрибута>=<значение по умолчанию> + обозначает атрибут с областью видимости общедоступный(public) Имя_класса #обозначает атрибут с областью видимости типа защищенный(protected) +аттрибут_1:integer=0 # /аттрибут_2:Boolean -аттрибут_3:String -Обозначает атрибут с областью видимости типа закрытый(private) операция_1():integer операция_2() операция_3():String

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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