Слайд 1
UML
Султанбекова Улбала Ракимкуловна
Слайд 2Содержание
Что такое моделирование?
UML – универсальный язык моделирования
Основные UML диаграммы
Преимущества использования UML
диаграмм
Слайд 3Что такое моделирование?
Модель = абстракция + прототип
Средство общения с заказчиком и
между разработчиками
Документация для разработчиков
Примеры методологий моделирования
Блок-схемы
CRC-карты
Слайд 4Блок-схемы
Позволяют описать последовательность действий, алгоритм
Не позволяют описать параллельные процессы
Не позволяют
описать взаимоотношения между объектами
Не позволяют описать событийную модель
Слайд 5Полноценный язык моделирования:
Элементы модели
Отношения между элементами
Нотация – визуальное представление элементов
моделирования
Принципы использования – правила применения элементов
Слайд 6UML – универсальный язык моделирования
Используется при объектной декомпозиции
Не зависит от используемой
методологии разработки
Может поддерживать любой объектно-ориентированный язык
Слайд 7Словарь UML
Словарь UML образует три разновидности строительных блоков:
Предметы.
Отношения.
Диаграммы.
Слайд 8Предметы – абстракции, которые являются основными элементами в модели
В UML
имеются четыре разновидности предметов:
Структурные предметы.
Предметы поведения.
Группирующие предметы.
Поясняющие предметы.
Слайд 9Структурные предметы
Класс – описание множества объектов, которые разделяют одинаковые свойства
операции, отношения и семантику (смысл).
Интерфейс – набор операций, которые определяют услуги класса или компонента.
Кооперация (сотрудничество) определяет взаимодействие
Актер – набор согласованных ролей, которые могут играть пользователи при взаимодействии с системой (ее элементами Use Case)
Элемент Use Case (прецедент) – описание последовательности действий, выполняемых системой в интересах отдельного актера и производящих видимый для актера результат.
Компонент – физически и заменяемая часть системы, которая соответствует набору интерфейсов и обеспечивает реализацию этого набора интерфейсов.
Узел – физический элемент, который существует в период работы системы и представляет ресурс, обычно имеющий память и возможности обработки
Слайд 10Предметы поведения
Взаимодействие – поведение, заключающее в себе набор сообщений, которыми
обмениваются набор объектов в конкретном контексте для достижения определенной цели.
Конечный автомат – поведение, которое определяет последовательность состояний объекта или взаимодействия, выполняемые в ходе его существования в ответ на события.
Слайд 11Отношения
В UML имеются четыре разновидности отношений:
Зависимость.
Ассоциация.
Обобщение.
Реализация.
Зависимость – семантическое отношение между двумя
предметами, в котором изменение в одном предмете (независимом) может влиять на семантику другого предмета (зависимого).
Ассоциация – структурное отношение, которое описывает набор связей, являющихся соединением между объектами.
Обобщение – отношение, в котором объекты специализированного элемента (потомка) могут заменять объекты обобщенного элемента (предка). Потомок разделяет структуру и поведение родителя.
Реализация – семантическое отношение между классификаторами, где один классификатор определяет контракт, который другой классификатор обязуется выполнять (к классификаторам относят классы, интерфейсы, компоненты, элементы Use Case, кооперации). Реализации применяют в двух случаях: между интерфейсами и классами (или компонентами), реализующими их; и между элементами Use Case и кооперациями, которые реализуют их.
Слайд 12Диаграммы
Диаграмма – графическое представление множества элементов, наиболее часто изображается как связный
граф из вершин (предметов) и дуг (отношений). Диаграммы рисуются для визуализации системы с разных точек зрения, затем они отображаются в систему.
Отображают
сущности
отношения между сущностями
Обобщения (Generalization)
Ассоциации (Association)
Включения (Composition)
Зависимости (Dependency)
Слайд 13Основные UML диаграммы
Прецеденты (Use case)
Диаграммы взаимодействия (interaction diagrams)
Диаграммы последовательности (sequence diagrams)
Диаграммы
кооперации (collaboration diagrams)
Диаграммы классов (class diagrams)
Диаграммы состояний (Statechart diagrams)
Диаграммы деятельности (Activity diagrams)
Диаграммы размещения (deployment diagrams)
Слайд 14Диаграмма Use Case
(Вариантов использования)
Слайд 15Прецеденты
Взаимодействие пользователя и системы
Каждый прецедент описывает:
функцию взаимодействия
Все взаимодействие или небольшую часть
Включает
одного или несколько действующих лиц
Участвуют, пользуются результатами
Перечисляют задачи в рамках данного взаимодействия
Слайд 16Актеры
Не являются частью системы - любая внешняя по отношению к моделируемой
системе сущность, которая
взаимодействует с системой
и использует ее функциональные возможности для достижения определенных целей или решения частных задач.
Примеры актеров:
клиент банка, банковский служащий,
продавец магазина, менеджер отдела продаж, пассажир авиарейса, водитель автомобиля, администратор гостиницы,
сотовый телефон
Слайд 17Как определить актеров?
Кто заинтересован в данных требованиях?
Где будет применятся данная система?
Кто
выигрывает от использования системы?
Кто обеспечивает систему информацией, применяет и удаляет её?
Кто занимается поддержкой системы?
Использует ли система внешние ресурсы?
Выполняет ли один человек несколько ролей?
Взаимодействует ли система с другими системами?
Слайд 18Как определить прецеденты?
Какую задачу выполняет каждый из актеров?
Будет ли кто-то из
актеров создавать, сохранять, изменять, удалять информацию из системы?
Где будет создаваться, сохраняться, изменяться, удаляться информация?
Потребуется ли актеру уведомлять систему о внешних изменениях?
Необходимо ли оповещать актеров о наступлении каких-либо событий в системе?
Слайд 19Отношения на диаграмме ВИ
Отношение ассоциации (association relationship)
Отношение расширения (extend
relationship)
Отношение обобщения (generalization relationship)
Отношение включения (include relationship)
Слайд 20Отношение ассоциации
служит для обозначения специфической роли актера в отдельном варианте
использования
устанавливает, какую конкретную роль играет актер при взаимодействии с экземпляром варианта использования.
Слайд 21Отношение расширения
определяет взаимосвязь экземпляров отдельного варианта использования с более общим
вариантом:
если имеет место отношение расширения от варианта использования А к варианту использования В, то это означает, что свойства экземпляра варианта использования В могут быть дополнены благодаря наличию свойств у расширенного варианта использования А.
Слайд 22Отношение обобщения
Отношение обобщения между прецедентами и актерами аналогично отношениям обобщения (наследования)
между классами:
Потомок (В) наследует все свойства и поведение своего родителя (А), а также может быть дополнен новыми свойствами и особенностями поведения
Слайд 23Отношение включения
указывает, что некоторое заданное поведение для одного варианта использования
включается в качестве составного компонента в последовательность поведения другого варианта использования.
Слайд 26Спецификация ВИ с помощью текстовых сценариев
Сценарий (scenario) – специально написанный текст,
который описывает поведение моделируемой системы в форме последовательности выполняемых действий актеров и самой системы
Пример.
На основе заданных сценариев разработать диаграмму вариантов использования для банкомата
Слайд 27Сценарий №1 выполнения ВИ "Снятие наличных по кредитной карточке»
Главный раздел
Вариант использования: Снятие
наличных по кредитной карточке
Актеры: Клиент Банкомата, Банк
Цель: Получение требуемой суммы наличными
Краткое описание: Клиент использует свою карточку для снятия наличных. Клиент запрашивает требуемую сумму. Банкомат обеспечивает доступ к счету клиента. Банкомат выдает клиенту наличные.
Тип: Базовый
Ссылки на другие варианты использования: Включает в себя ВИ:
Проверка ПИН-кода кредитной карточки
Слайд 28Раздел Типичный ход событий
1. Клиент вставляет кредитную карточку в устройство чтения
банкомата
2. Банкомат передает информацию о кредитной карточке в Банк
3. Банк проверяет информацию о кредитной карточке
Исключение №1: Кредитная карточка недействительна (утрачена)
Исключение №2: Кредитная карточка просрочена
4. Банкомат предлагает ввести ПИН-код
5. Клиент вводит PIN-код
6. Банкомат проверяет ПИН-код
Исключение №3: Введенный ПИН-код неверный
Исключение №4: Клиент ввел неверный ПИН-код 3 раза
7. Банкомат отображает опции меню
8. Клиент выбирает снятие наличных со своего счета
9. Банкомат предлагает ввести требуемую сумму
Слайд 29Раздел Типичный ход событий
10. Клиент вводит требуемую сумму
11. Банкомат делает соответствующий
запрос в Банк
12. Банк проверяет введенную сумму
Исключение №5: Требуемая сумма превышает сумму на счете клиента
13. Банк изменяет состояние счета клиента
15. Клиент получает свою кредитную карточку
Исключение №6: Клиент выбрал печать чека
14. Банкомат предлагает клиенту забрать его кредитную карточку
16. Банкомат выдает наличные и предлагает забрать их клиенту
17. Клиент получает наличные
18. Банкомат отображает сообщение о готовности к дальнейшей работе
Слайд 30Раздел исключений
Исключение №1. Кредитная карточка недействительна (утрачена)
4. Банкомат блокирует кредитную карточку
18.
Банкомат отображает сообщение о готовности к дальнейшей работе
Исключение №2: Кредитная карточка просрочена
4. Банкомат предлагает клиенту забрать его кредитную карточку
15. Клиент получает свою кредитную карточку
18. Банкомат отображает сообщение о готовности к дальнейшей работе
Исключение №3. Введенный ПИН-код неверный
4. Банкомат предлагает ввести ПИН-код
5. Клиент вводит ПИН-код
Слайд 31Раздел исключений
Исключение №4: Клиент вводит неверный ПИН-код 3 раза
4. Банкомат блокирует
кредитную карточку
18. Банкомат отображает сообщение о готовности к дальнейшей работе
Исключение №5. Требуемая сумма превышает сумму на счете клиента
9. Банкомат предлагает ввести новую сумму
10. Клиент вводит новую требуемую сумму
Исключение №6: Клиент выбрал печать чека
16. Банкомат предлагает клиенту забрать чек
Примечание. Клиент может отказаться от выполнения транзакции "Снятие наличных по кредитной карточке" при введении ПИН-кода, при выборе типа транзакции и при вводе суммы.
Слайд 32Сценарий №2 "Получение справки о состоянии счета"
Главный раздел
Вариант использования: Получение справки о
состоянии счета
Актеры: Клиент Банкомата, Банк
Цель: Получение информации о балансе
Краткое описание: Клиент использует свою карточку для получения справки о состоянии счета. Банкомат обеспечивает доступ к счету клиента. Банкомат выдает клиенту справку в форме чека.
Тип: Базовый
Ссылки на другие варианты использования: Включает в себя ВИ:
Проверка ПИН-кода кредитной карточки
Слайд 33Типичный ход событий
1. Клиент вставляет кредитную карточку в устройство чтения банкомата
2.
Банкомат передает информацию о кредитной карточке в Банк
3. Банк проверяет информацию о кредитной карточке
Исключение №1: Кредитная карточка недействительна (утрачена)
Исключение №2: Кредитная карточка просрочена
4. Банкомат предлагает ввести ПИН-код
5. Клиент вводит PIN-код
6. Банкомат проверяет ПИН-код
Исключение №3: Введенный ПИН-код неверный
Исключение №4: Клиент ввел неверный ПИН-код 3 раза
Слайд 34Типичный ход событий
7. Банкомат отображает опции меню
8. Клиент выбирает получение справки
о состоянии счета
9. Банкомат делает соответствующий запрос в Банк
10. Банкомат предлагает клиенту забрать его кредитную карточку
11. Клиент получает свою кредитную карточку
12. Банкомат выдает справку о состоянии счета и предлагает забрать ее клиенту
13. Клиент получает справку о состоянии своего счета
14. Банкомат отображает сообщение о готовности к дальнейшей работе
Слайд 35Последовательность разработки вариантов использования
Определить главных (первичных) актеров и определить их цели
по отношению к системе
Специфицировать все базовые (основные) ВИ
Выделить цели базовых ВИ, интересы актеров в контексте этих ВИ, предусловия и постусловия ВИ
Написать успешный сценарий выполнения базовых ВИ
Определить исключения (неуспех) в сценариях ВИ и написать сценарии для всех исключений
Выделить ВИ исключений и изобразить их со стереотипом «extend»
Выделить общие фрагменты функциональности ВИ и изобразить их отдельными ВИ со стереотипом «include»
Слайд 36Показатели качества модели вариантов использования
Все ли функциональные требования описываются ВИ?
Не содержит
ли модель ненужное поведение, которое отсутствует в требованиях?
Действительно ли в модели необходимы все выявленные связи включения, расширения и обобщения?
Можно ли на основе модели вариантов использования составить четкое представление о функционировании системы в контексте ее пользователей?
Слайд 37Типичные ошибки при разработке диаграмм вариантов использования
Превращение диаграммы вариантов использования в
диаграмму деятельности за счет желания отразить все функциональные действия
Инициатором действий является разрабатываемая система
Спецификация атрибутов и операций классов до того, как сформулированы все варианты использования
Задание слишком кратких имен вариантам использования
Описание вариантов использования в терминологии, непонятной пользователям системы или заказчику
Отсутствие описаний альтернативных последовательностей действий
Слайд 39Диаграммы взаимодействия
Диаграмма взаимодействий (Interaction diagram) описывает взаимодействия, состоящие из множества объектов
и отношений между ними, включая сообщения, которыми они обмениваются.
Диаграммы последовательности (sequence diagrams)
Диаграммы кооперации (collaboration diagrams)
диаграмма последовательностей акцентирует внимание на временной упорядоченности сообщений
диаграмма кооперации - на структурной организации посылающих и принимающих сообщения объектов
Описывают поведение взаимодействующих объектов
Можно составлять для каждого прецедента
На диаграммах отображаются
Объекты
Сообщения которыми они обмениваются
Временная шкала
Слайд 40Диаграмма последовательности
Изображаются объекты, которые участвуют во взаимодействии и не показываются возможные
статические ассоциации с другими объектами.
динамика взаимодействия объектов во времени.
вертикальные линии - линии жизни отдельного объекта, участвующего во взаимодействии.
каждый объект изображается прямоугольником и располагается в верхней части своей линии жизни
Слайд 41Линия жизни - для обозначения периода времени, в течение которого объект
существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях.
Фокус управления – для явного выделения активности объектов, непосредственно выполняющих определенные действия.
Слайд 44Диаграммы классов
Диаграмма классов (class diagram) — диаграмма, предназначенная для представления модели
статической структуры программной системы в терминологии классов объектно-ориентированного программирования
Объекты
Статические связи между объектами
Показывают в каких отношениях находятся объекты
Ассоциации, Обобщения, Включения, Зависимости
Ограничения
Атрибуты
Слайд 47Ассоциация
Ассоциация (association) – произвольное отношение или взаимосвязь между классами
Имя стороны ассоциации
специфицирует роль (role), которую играет класс, расположенный на соответствующей стороне рассматриваемой ассоциации
Видимость стороны ассоциации специфицирует возможность доступа к соответствующей стороне ассоциации с других ее сторон
Кратность ассоциации специфицирует возможное количество экземпляров соответствующего класса, которое может соотноситься с одним экземпляром класса на другой стороне этой ассоциации
Символ наличия навигации (navigable) изображается с помощью простой стрелки
Слайд 48Исключающая ассоциация между тремя классами
Слайд 49Обобщение (generalization)
отношение между более общим классификатором (родителем или предком) и более
специальным классификатором (дочерним или потомком)
Слайд 50Агрегация (aggregation)
направленное отношение между двумя классами, предназначенное для представления ситуации, когда
один из классов представляет собой некоторую сущность, которая включает в себя в качестве составных частей другие сущности
Слайд 52Композиция (composition)
композитная агрегация предназначена для спецификации более сильной формы отношения "часть-целое",
при которой с уничтожением объекта класса-контейнера уничтожаются и все объекты, являющимися его составными частями.
Слайд 56Диаграмма состояний
Назначение – описать возможные последовательности состояний и переходов, которые в
совокупности характеризуют поведение элемента модели в течение его жизненного цикла
Динамика поведения системы
Все возможные состояния объекта
События влияющие на объект
Условия перехода в новое состояние
Не годится для описания нескольких взаимодействующих объектов
Слайд 57Диаграмма состояний – граф специального вида, который представляет некоторый автомат.
Автомат не
запоминает историю перемещения из состояния в состояние.
В каждый момент времени автомат может находиться в одном и только в одном из своих состояний.
Хотя процесс изменения состояний автомата происходит во времени, явно концепция времени не входит в формализм автомата.
Количество состояний автомата должно быть обязательно конечным (конечный автомат)
Граф автомата не должен содержать изолированных состояний и переходов
Автомат не должен содержать конфликтующих переходов
Слайд 59Состояния
Состояние - это ситуация в жизни объекта, на протяжении которой он
удовлетворяет некоторому условию, выполняет определенную деятельность или ожидает какого-то события.
Объект остается в некотором состоянии в течение конечного отрезка времени.
В этом случае под действием понимают некоторую атомарную операцию, выполнение которой приводит к изменению состояния или возврату некоторого значения (например, "истина" или "ложь").
Слайд 60Переход
Переход - это отношение между двумя состояниями, показывающее, что объект, находящийся
в первом состоянии, должен выполнить определенные действия и перейти во второе состояние, как только произойдет указанное событие и будут удовлетворены указанные условия (триггерный переход).
при таком изменении состояния переход срабатывает.
пока переход не сработал, объект находится в исходном состоянии; после срабатывания он находится в целевом состоянии.
Слайд 61Составное состояние
Составное состояние (composite state) - такое сложное состояние, которое состоит
из других вложенных в него состояний (подсостояния).
Слайд 62Сложные переходы
Переходы между параллельными состояниями
Синхронизирующие состояния
Слайд 64Диаграмма деятельности
Описание параллельных процессов
Основное отличие от блок-схем
Не важна последовательность выполнения
Деятельности
Задачи, которые
надо выполнить
Последовательности деятельностей
Линейки синхронизации
Для каждой подзадачи
Два вида
Используются только нетриггерные переходы, которые срабатывают сразу после завершения деятельности или выполнения соответствующего действия.
Слайд 65Элементы диаграммы
Изображение разделения и слияния параллельных потоков управления
Дорожки – для бизнес-процессов
выполнение каждого действия лучше ассоциировать с конкретным подразделением компании.
Слайд 67Преимущества использования
Облегчение общения между
заказчиками и разработчиками
Прецеденты, диаграммы последовательности
Участниками команды разработчиков
На стадии
разработки
Передача данных следующему поколению
Эффект «критической массы»
Диаграммы классов, диаграммы состояния, диаграммы размещения
Пользователями и разработчиками
Прецеденты
Слайд 68Использование UML в различных методологиях разработки
Водопадные модели – UML от начала
до конца
Как только переходим к итеративной модели объём UML уменьшается
Проблема рассинхронизации модели и кода
XP – итеративная от начала до конца
Слайд 69Средства проектирования
Rational Rose - считается профессиональным средством, адаптирован под методику разработки
RUP.
Borland Together –хорошо интегрируется в Visual Studio.
Microsoft Visio - система для визуального описания моделей. UML диаграммы не интегрируются в среду разработки.
Rational XDE DeveloperPlus .NET - сочетает возможности Rational Rose и тесную интеграцию с Visual Studio .NET.
PowerDesigner12 - позволяет в одном месте (workspace) сосредоточить все диаграммы
IBM Raional Software Architect - адаптирован под методику разработки RUP