UML. Принцип создания проектов

Содержание

Слайд 2

Принцип создания проектов Принцип ООП: абстракция - реализация

Принцип создания проектов

Принцип ООП: абстракция - реализация

Слайд 3

UML(Unified Modeling Language) Цель UML – проектирование, документирование, визуальное описание основных

UML(Unified Modeling Language)

Цель UML – проектирование, документирование, визуальное описание основных компонентов

проекта
Диаграмма – визуальное описание процесса, классов, взаимодействия
На каждый процесс – своя диаграмма
Хранение важной информации в эл. виде
Не язык программирования (но можно генерировать код)
Дополняет ТЗ
Видение процесса «сверху»
Слайд 4

Основные источники uml-diagrams.org Creately.com

Основные источники
uml-diagrams.org
Creately.com

Слайд 5

Кто может использовать UML Заказчик – общие задачи и цели проекта

Кто может использовать UML

Заказчик – общие задачи и цели проекта
Аналитик –

подходы, правильность работы системы и её частей, «слои» приложения
Разработчик/Архитектор – дизайн кода, архитектура классов, объектов и взаимодействий
Тестировщик – проверка функционала на всех уровнях
Менеджер проекта – общая картина по проекту
ООП!
Слайд 6

Плюсы Универсальность – единая технология Автоматическая генерация кода на основе UML-диаграмм

Плюсы

Универсальность – единая технология
Автоматическая генерация кода на основе UML-диаграмм
Широкое применение –

ИТ, бизнес и др.
Поддержка ООП
Большое количество типов диаграмм
Удобные инструменты, плагины для многих IDE
Разбор основных моментов проекта без изучения кода
Миграция диаграмм инструментальными средствами
Слайд 7

Минусы Изучение UML Для начинающих – путаница в количестве диаграмм Знание

Минусы

Изучение UML
Для начинающих – путаница в количестве диаграмм
Знание ООП
Детализация/поверхностное описание
Учебные материалы

сложны и запутаны
Слайд 8

Типы диаграмм Structure diagrams Общая картина взаимодействия Как устроено, кто с

Типы диаграмм

Structure diagrams
Общая картина взаимодействия
Как устроено, кто с кем связан

Behavior diagrams
Динамическое

поведение, изменение состояния во времени
Как работает, последовательность процессов

Структурные

Поведенческие

Слайд 9

Типы диаграмм

Типы диаграмм

Слайд 10

Class diagram Описание классов, интерфейсов, связей, методов Структура в стиле ООП

Class diagram

Описание классов, интерфейсов, связей, методов
Структура в стиле ООП
Позволяет понять работу

кода без изучения самого кода
Автогенерация кода на основе диаграмм
Слайд 11

Object diagram Состояние экземпляров классов с конкретными значениями полей в определенный

Object diagram

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

времени
Похож на диаграмму классов, но в режиме runtime (во время работы программы)
Слайд 12

Package diagram Показывает вложенность и связи между пакетами Более высокий уровень, чем классы

Package diagram

Показывает вложенность и связи между пакетами
Более высокий уровень, чем классы

Слайд 13

Model diagram Описание «слоев» проекта Используется для многоуровневых приложений Часто используется

Model diagram

Описание «слоев» проекта
Используется для многоуровневых приложений
Часто используется в ТЗ

для общего описания частей проекта
Слайд 14

UseCase Diagram Диаграмма прецедентов/вариантов использования Описание возможных сценариев работы с системой

UseCase Diagram

Диаграмма прецедентов/вариантов использования
Описание возможных сценариев работы с системой с точки

зрения пользователя
Возможные пути использования системы
Описание всех участников системы (актеры)
Слайд 15

Activity Diagram Описание возможных бизнес-процессов приложения Взаимодействие «потоков», пошаговое представление действия

Activity Diagram
Описание возможных бизнес-процессов приложения
Взаимодействие «потоков», пошаговое представление действия
Более низкий уровень,

чем UseCase
Может быть конкретным описанием блоков UseCase диаграмм
Слайд 16

Sequence diagram Последовательность взаимодействия объектов для определенного бизнес-процесса Как объекты друг

Sequence diagram

Последовательность взаимодействия объектов для определенного бизнес-процесса
Как объекты друг друга вызывают

и какие данные передают
Показывают объекты в действии
Показывают время жизни объектов (создание, удаление)
Слайд 17

Deployment diagram Описание архитектуры, топологии системы (ОС, БД, сервера и пр.) Информация для администраторов

Deployment diagram

Описание архитектуры, топологии системы (ОС, БД, сервера и пр.)
Информация для

администраторов
Слайд 18

Диаграмма вариантов использования (use case diagram) диаграмма, на которой изображаются варианты

Диаграмма вариантов использования (use case diagram)

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

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

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

Назначение диаграммы вариантов использования

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

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

Проектируемая система и ее окружение Субъект (subject) – любой элемент модели, который обладает функциональным поведением

Проектируемая система и ее окружение

Субъект (subject) – любой элемент модели, который

обладает функциональным поведением
Слайд 21

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

Прецеденты

UseCase(случай использования, прецедент) – набор сценариев, путей, которые нужно выполнить

для достижения целей приложения ( с точки зрения пользователей)
Описывает участников (actor), возможные сценарии (успешные и неудачные), которые выполняются для решения задач приложения
Может описывать основные сценарии, которые составляют «ядро» приложения (дополнительные сценарии могут добавляться по ходу разработки)
Ориентация - на пользователей
Слайд 22

Основные обозначения на диаграмме вариантов использования

Основные обозначения на диаграмме вариантов использования

Слайд 23

Вариант использования (use case) представляет собой общую спецификацию совокупности выполняемых системой

Вариант использования (use case)

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

целью предоставления некоторого наблюдаемого результата, который имеет значение для одного или нескольких актеров
Отвечает на вопрос «Что должна выполнять система?», не отвечая на вопрос «Как она должна выполнять это?»
Имена – отглагольное существительное или глагол в неопределенной форме
Слайд 24

Актер (actor) любая внешняя по отношению к проектируемой системе сущность, которая

Актер (actor)

любая внешняя по отношению к проектируемой системе сущность, которая взаимодействует

с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач
Примеры актеров: кассир, клиент банка, банковский служащий, президент, продавец магазина, менеджер отдела продаж, пассажир авиарейса, водитель автомобиля, администратор гостиницы, сотовый телефон
Слайд 25

Вопросы для идентификации актеров в системе Какие организации или лица будут

Вопросы для идентификации актеров в системе

Какие организации или лица будут использовать

систему
Кто будет получать пользу от использования системы
Кто будет использовать информацию от системы
Будет ли использовать система внешние ресурсы
Может ли один пользователь играть несколько ролей при взаимодействии с системой
Могут ли различные пользователи играть одну роль при взаимодействии с системой
Будет ли система взаимодействовать с законодательными, исполнительными, налоговыми или другими органами
Слайд 26

Отношения на диаграмме вариантов использования

Отношения на диаграмме вариантов использования

Слайд 27

Отношение ассоциации Ассоциация (association) является одним из фундаментальных понятий в языке

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

Ассоциация (association) является одним из фундаментальных понятий в языке

UML 2.х и может использоваться на различных канонических диаграммах при построении визуальных моделей
Применительно к диаграммам вариантов использования отношение ассоциации может служить только для обозначения взаимодействия актера с вариантом использования.
Слайд 28

Отношение включения Отношение зависимости (dependency) определяется как форма взаимосвязи между двумя

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

Отношение зависимости (dependency) определяется как форма взаимосвязи между двумя

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

Отношение расширения Отношение расширения (extend) определяет взаимосвязь одного варианта использования с

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

Отношение расширения (extend) определяет взаимосвязь одного варианта использования с

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

Изображение отношения расширения с условием выполнения

Изображение отношения расширения с условием выполнения

Слайд 31

Отношение обобщения Отношение обобщения (generalization relationship) предназначено для спецификации того факта,

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

Отношение обобщения (generalization relationship) предназначено для спецификации того факта,

что один элемент модели является специальным или частным случаем другого элемента модели
Слайд 32

Пример диаграммы ВИ для системы продажи товаров в Интернет-магазине

Пример диаграммы ВИ для системы продажи товаров в Интернет-магазине

Слайд 33

Формализация функциональных требований с помощью диаграммы ВИ Требование (requirement) – желательное

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

Требование (requirement) – желательное свойство,

характеристика или условие, которым должна удовлетворять система в процессе своей эксплуатации
Требование к ПО – некоторое свойство ПО, которым должна обладать система или ее компонент, чтобы удовлетворять условиям контракта, положениям стандартов, формальной спецификации или технической документации
Управление требованиями – это систематический подход к выявлению, организации и документированию требований к системе, а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и разработчиком по поводу меняющихся требований к системе
Слайд 34

Описание прецеденты Понятное имя Краткость – главное понять смысл без технических

Описание прецеденты

Понятное имя
Краткость – главное понять смысл без технических деталей

(«что», а не «как»)
Правильное разделение действующих лиц на главные (инициатор) и второстепенные роли
Заполнять только самые важные пункты (свободная форма или по формату alistair.cockburn)
Слайд 35

Последовательность Описать основные возможности программы (мозговой штурм) Составить список Разделить по

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

Описать основные возможности программы (мозговой штурм)
Составить список
Разделить по смыслу на группы
Выделить

сценарии
Описать UseCase
Слайд 36

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

Адресная книга (мозговой штурм)

Не слишком сложное, попроще, чтобы познакомиться с технологиями
Хранение

пользователей
Редактирование
Поиск
Удаление
Добавление
Сортировка
Удобное отображение
Резиновый дизайн
Видна основная информация
Локальное или распределенное приложение
Десктоп или веб?
Юзабилити
Всплывающие подсказки
Красивый интерфейс
Индикаторы загрузки
Проверка введенных данных
Маски для ввода
Переключение языков