5.09M

2 Процесс разработки - UML, ТЗ, процесс проектирования, модели разработки (1)

1.

Тема: Проектирование ПО.
UML, разработка требований, процесс проектирования,
модели разработки
Васильев В. С.

2.

План лекции
1. Основы UML.
2. Процесс разработки.
3. Проектирование.
4. Чистая архитектура.
5. Модели разработки ПО.
6. Альтернативы UML и RUP.
2

4.

Задача
мир грузится из файла. Игру можно
сохранить/загрузить.
рисуем диаграмму
классов для игры
4

9.

1.1 Основы UML. Проект без UML.
Entity-Relationship model
9

10.

1.1 Основы UML. Проект без UML.
Entity-Relationship model
10

11.

1.1 Основы UML. Проект без UML.
Entity-Relationship model. Нотация Чена
11

12.

1.1 Основы UML. Проект без UML.
Entity-Relationship model. Нотация Мартина
12

13.

1.1 Основы UML. Проект без UML.
Entity-Relationship model
13

14.

1.1 Основы UML. Проект без UML.
Entity-Relationship model
14

15.

1.1 Основы UML. Проект без UML.
Entity-Relationship model
15

1.2 Основы UML. Основные диаграммы UML
Требования (текстовый
вид)
Динамическая модель
(графический вид)
Статическая модель
(графический вид)
Диаграмма прецедентов
Диаграмма
последовательности
Диаграмма классов
Диаграмма
взаимодействия
Диаграмма объектов
Диаграмма состояний
Диаграмма развертывания
Диаграмма активности
16

17.

1.2 Основы UML. Основные диаграммы UML
17

18.

1.3 Основы UML. Диаграмма прецедентов. Пример
18

19.

1.3 Основы UML. Диаграмма прецедентов. Пример
Прецедент: Купить автомобиль
Действующее лицо: Покупатель
Предусловие: Наличие N рублей и желания купить автомобиль
Главная последовательность:
1. Используя каталог и функцию фильтрации (по цене и характеристикам) —
выбрать подходящий автомобиль;
2. При наличии старого автомобиля — покупатель может сдать его в счет части
цены нового;
3. При нехватке денег покупатель может оформить кредит.
19

20.

1.3 Основы UML. Диаграмма прецедентов.
Алгоритм построения
1.
2.
3.
выделить группы действующих лиц;
идентифицировать как можно больше вариантов использования;
дополнить прецеденты словесным описанием.
20

21.

1.3 Основы UML. Диаграмма прецедентов. Цели
• определение границы и контекста моделируемой предметной области на
ранних этапах проектирования;
• формирование общих требований к поведению проектируемой системы;
• подготовка документации для взаимодействия с заказчиками и пользователями
системы;
• подготовка основы для тестирования.
21

22.

1.4 Основы UML. Диаграмма состояний
22

23.

1.5.1 Основы UML. Интерфейс.
Макеты интерфейса (не UML)
23

24.

1.5.2 Основы UML. Интерфейс.
Макеты интерфейса (не UML)
24

25.

1.5.3 Основы UML. Интерфейс.
Диаграмма потока экранов (не UML)
25

26.

1.5.4 Основы UML. Интерфейс.
Диаграмма состояний. Карта диалоговых окон
Подробнее тут: https://habr.com/ru/post/279373/
26

27.

1.6 Основы UML. Диаграмма последовательностей. Пример
27

28.

1.6 Основы UML. Диаграмма последовательностей.
Алгоритм построения
1.
2.
3.
4.
5.
скопировать текст прецедента на страницу диаграммы;
добавить сущностные объекты с диаграммы пригодности. Каждый из них
является экземпляром класса, изображенного на диаграмме классов (модель
предметной области). В процессе ICONIX при этом предлагается проверить
модель предметной области и добавить в нее пропущенные объекты;
добавить граничные объекты и акторов из диаграммы пригодности (они могут
отсутствовать в модели предметной области);
распределить методы по объектам. Контроллеры могут быть преобразованы
как в сообщения и методы, реализующие нужное поведение, так и в новые
управляющие объекты. Розенберг предлагает вычеркивать контроллеры на
диаграмме пригодности после нанесения на диаграмму последовательности
чтобы ничего не забыть;
обновить и проверить модель предметной области если при построении были
добавлены новые управляющие объекты.
28

29.

1.7 Основы UML. Диаграмма активностей
29

30.

1.7 Основы UML. Диаграмма активностей.
Алгоритм построения
1.
2.
3.
4.
5.
6.
Составление перечня деятельностей в системе;
Принятие решения о необходимости построения диаграммы деятельностей;
Определение зависимостей между деятельностями;
Выделение параллельных потоков деятельностей;
Определение условий переходов;
Уточните сложные деятельности.
30

31.

1.8 Основы UML. Диаграмма взаимодействия
31

32.

1.9 Основы UML. Диаграмма взаимодействия
32

33.

1.9 Основы UML. Диаграмма классов
33

34.

1.9 Основы UML. Диаграмма классов. Цели
словарь системы, концептуальная модель;
средство эскизирования;
нотация для моделирования БД;
часть документации;
результат проектирования.
34

35.

1.10 Основы UML. Диаграмма объектов (object diagram)
35

36.

1.10 Основы UML. Диаграмма объектов. Пример
36

37.

1.11 Основы UML. Литература
1. Буч Градди Объектно-ориентированный анализ и проектирование с примерами
приложений, 3-е изд. / Буч Градди, Максимчук Роберт А., Энгл Майкл У., Янг
Бобби Дж., Коналлен Джим, Хьюстон Келли А.: Пер с англ. — М.: ООО «И.Д.
Вильямс», 2010. — 720 с.
2. Леоненков, А.В. Самоучитель UML 2 / А.В. Леоненков. – СПб.: БХВ —
Петербург, 2007. – 576с.
3. Ларман, К. Применение UML и шаблонов проектирования: Уч. Пос / К. Ларман.
— М.: Издательский дом «Вильямс», 2001. — 496 с.
4. Розенберг Д., Скотт К. Применение объектного моделирования с
использованием UML и анализ прецедентов.: Пер. с англ. М.: ДМК Пресс, 2002
5. Фаулер, М. UML. Основы / М. Фаулер, К. Скотт; пер. с англ. – СПб.: Символ –
Плюс, 2002. – 192 с.
37

38.

1.11 Основы UML. Литература
6. Основы UML — диаграммы использования (use-case). URL:
https://pro-prof.com/archives/2594
7. Процесс ICONIX. Диаграммы пригодности. URL:
https://pro-prof.com/archives/2723
8. Основы UML. Диаграммы последовательности. URL:
https://pro-prof.com/archives/2769
9. Диаграммы классов UML. URL: https://pro-prof.com/archives/3212
10. Нотации модели сущность-связь (ER диаграммы). URL:
https://pro-prof.com/archives/8126
38

39.

* Чего не будет в этом курсе?
Источник: Коваленко, В. В. Проектирование информационных систем : учеб.
пособие / В.В. Коваленко. — Москва : ФОРУМ : ИНФРА-М, 2018. — 320 с. —
(Высшее образование: Бакалавриат). - ISBN 978-5-00091-628-5. - Текст :
электронный. - URL: https://libproxy.bik.sfu-kras.ru:2215/catalog/product/980117
39

40.

2.2 Процесс разработки. Стратегии жизненного цикла
Стратегия жизненного цикла программного обеспечения – порядок
следования и содержания основных этапов процесса разработки.
Основные стратегии жизненного цикла ПО:
однократный проход (водопадная стратегия) – линейная
последовательность этапов конструирования;
инкрементная стратегия – разработка ПО ведется с определения всех
требований к ПО, а оставшаяся часть разработки выполняется в виде
последовательности версий;
эволюционная стратегия – ПО также разрабатывается в виде версий, но
требования формируются и уточняются по ходу разработки от версии к
версии.
40

41.

2.3.1 Процесс разработки.
Каскадная (водопадная) модель
Системный
анализ
Анализ
требований
Проектирование
Реализация
Тестирование
Этап системного анализа:
задается роль каждого элемента в
системе и их взаимодействие друг с
другом;
формируется интерфейс ПО с другими
элементами (аппаратурой, базами
данных, пользователями);
начинается решение задачи
планирования проекта.
Этап анализа требований:
Внедрение
детальное определение
функциональных и
Сопровождение
нефункциональных требований,
предъявляемых к
разрабатываемому ПО;
завершается задача планирования
проекта.
41

42.

2.3.1 Процесс разработки.
Каскадная (водопадная) модель
Этап проектирования:
создание представлений:
архитектуры ПО;
модульной структуры ПО;
алгоритмической структуры ПО;
структуры данных;
графического интерфейса пользователя.
оценка качества будущего программного обеспечения.
Системный
анализ
Анализ
требований
Проектирование
Этап реализации:
преобразование
проектных
спецификаций в
текст на языке
программирования
(кодирование).
Этап внедрения:
выполнение установки разработанного ПО у
заказчика;
Тестирование
обучение персонала;
плавный переход от старого ПО (если оно
Внедрение
есть) к использованию нового.
Реализация
Этап тестирования:
проверка корректности выполнения
программы;
обнаружение и исправление ошибок в
функциях, логике и форме реализации
программного продукта.
Сопровождение
42

43.

2.3.1 Процесс разработки.
Каскадная (водопадная) модель
Критерии применения каскадной модели:
требования к ПО и их реализация максимально четко определены и понятны;
неизменяемое определение продукта и вполне понятные технические методики;
если компания имеет опыт построения подобного рода систем.
Область применения:
сложные системы с большим количеством задач вычислительного характера;
системы управления производственными процессами повышенной опасности и др.
43

44.

2.3.2 Процесс разработки.
V-образная модель
является стандартом для
немецких правительственных
и оборонных проектов, а
также для производителей ПО
в Германии.
Базируется на том, что приёмо-сдаточные испытания основываются, прежде всего, на
требованиях, системное тестирование — на требованиях и архитектуре, комплексное
тестирование — на требованиях, архитектуре и интерфейсах, а компонентное
тестирование — на требованиях, архитектуре, интерфейсах и алгоритмах
44

45.

2.3.3 Процесс разработки.
Макетирование
Макетирование – это процесс создания модели
разрабатываемого программного продукта.
НАЧАЛО
Сбор и уточнение требований
Модель может принимать один из трех видов:
бумажный макет или «электронный» макет,
который представляет человеко-машинный
интерфейс;
работающий макет (выполняет только часть
требуемых функций);
существующая программа (характеристики которой
должны быть улучшены).
Быстрое проектирование
Построение макета
Оценка макета заказчиком
Уточнение макета
Продолжать?
Да
Нет
Конструирование продукта
КОНЕЦ
45

46.

2.3.4 Процесс разработки.
Инкрементная модель
Инкрементная разработка - процесс частичной реализации всей системы и
медленного наращивания функциональных возможностей.
Инкрементная модель действует по принципу каскадной модели с перекрытиями.
Два подхода к набору требований:
полный заранее сформированный набор требований, которые выполняются в виде
последовательных, небольших по размеру проектов,
выполнение проекта может начаться с формулирования общих целей, которые
затем уточняются и реализуются группами разработчиков.
Планирование
Анализ
1-ый инкремент
Проектирование
…
i-ый инкремент
Кодирование
…
Тестирование
n-ый инкремент
Поставка i-го
инкремента
46

47.

2.3.5 Процесс разработки.
Спиральная модель
Спиральная модель
(автор: Барри Боэм, 1988)
является реализацией
эволюционной
стратегии разработки
программного
обеспечения.
Спиральная модель
отображает базовую
концепцию, которая
заключается в том, что
каждый цикл представляет
собой набор операций,
которому соответствует
такое же количество
стадий, как и в модели
каскадного процесса.
47

48.

2.3.6 Процесс разработки.
RAD
RAD предполагает, что разработка ПО осуществляется небольшой командой
разработчиков за срок порядка трёх-четырёх месяцев путём использования
инкрементного прототипирования с применением инструментальных средств
визуального моделирования и разработки. Технология RAD предусматривает активное
привлечение заказчика уже на ранних стадиях.
Пользовательское
проектирование оказывается
длительным интерактивным
процессом, который позволяет
пользователям понять, изменить и
в конечном счёте выбрать
рабочую модель, отвечающую их
требованиям.
Таких процессов предложено
много. Сотни. Запоминать все
это смысла нет. Надо понять
суть.
48

49.

2.3.6.1 Процесс разработки. Выбор модели разработки.
Характеристика требований.
Vобразная
Прототипирование
Спиральная
Да
Да
Нет
Нет
Да
Нет
Да
Да
Нет
Нет
Да
Да
Часто ли будут изменяться
требования в цикле?
Нет
Нет
Да
Да
Нет
Нет
Нужно ли демонстрировать
требования с целью
определения?
Нет
Нет
Да
Да
Да
Нет
Требуются ли для
демонстрации возможностей
проверка концепции?
Нет
Нет
Да
Да
Да
Нет
Будут ли требования
отражать сложность системы?
Нет
Нет
Да
Да
Нет
Да
Обладает ли требование
функциональными
свойствами на раннем этапе?
Нет
Нет
Да
Да
Да
Да
Требования
Являются ли требования
легко определимыми и/или
хорошо известными?
Могут ли требования
заранее определяться в цикле?
Каскадная
RAD
Инкрементная
49

50.

2.3.6.2 Процесс разработки. Выбор модели разработки.
Характеристика команды разработчиков.
Команда разработчиков
проекта
Каскадная
V-образная
Прототипирование
Спиральная
Инкрементная
Да
Да
Нет
Нет
RAD
Являются ли проблемы предметной
области проекта новыми для
большинства разработчиков?
Нет
Является ли технология предметной
области проекта новой для большинства
разработчиков?
Да
Да
Нет
Да
Нет
Да
Являются ли инструменты,
используемые проектом, новыми для
большинства разработчиков?
Да
Да
Нет
Да
Нет
Нет
Изменяются ли роли участников проекта
во время жизненного цикла?
Нет
Нет
Да
Да
Нет
Да
Могут ли разработчики проекта пройти
обучение?
Является ли структура более значимой
для разработчиков, чем гибкость?
Нет
Да
Нет
Нет
Да
Да
Да
Да
Нет
Нет
Нет
Да
Будет ли менеджер проекта строго
отслеживать прогресс команды?
Да
Да
Нет
Да
Нет
Да
Важна ли легкость распределение
ресурсов?
Приемлет ли команда равноправные
обзоры и инспекции,
менеджмент/обзоры заказчика, а
также стадии?
Да
Да
Нет
Нет
Да
Да
Да
Да
Да
Да
Нет
Да
Нет
50

51.

52.

* Чего нет в этом курсе, но могло бы быть
Источник: Трошкин, Н. Р. метод выбора и распределения задач на основе
методологии Scrum с использованием популяционных алгоритмов / Н. Р. Трошкин,
Т. И. Вишневская // Образовательные ресурсы и технологии. – 2025. – № 3(52). –
С. 83-95.
{Что не так с постановкой задачи?}
Таких публикаций про Scrum и все остальное очень много. Читать и смотреть стоит те
из них, которые пишут практики.
52

53.

* Чего нет в этом курсе, но могло бы быть
*Модель непредвиденных обстоятельств Фидлера
53

54.

Разбор задачи о проектировании косынки
54

55.

Разбор задачи о проектировании косынки
https://www.plantuml.com/plantuml/uml/
VL2nRkim3Dpr5Hpp7fm_28eW2TfkBThiXconW119D2GbRM3atqkQ1Uncg9SJZxxZaTjIRQxd64mVR2cmjzd1Q
80_JES8n-k0CEupbOAbWOEtaPBZrpEoZl5zi0xBRLRiAL26yGrT0xjWzFDJCsEA41iVNaPC0cZth6j35AhaebUK4KNyWuoXR3wPzX7CnwmF_ra3BxKZMH-41rZKPrGCD30ijad-gbpT5sWNVJFlQLyaQSnSanbgMIBjXsM3yHapPNFbNuo1GRa5UbXV7EbhzyPrlhNCjgcioar_81EyoDvfTz5hPF
DkAZn-3KMyWdbBhFd9FGM4aY10Tms8PdtnTtk4rs2jc67yDciefnMQz_Z_DcaiTDTSwo1ZvIuavgz5OzwmexaYpnUJECNm3
55

56.

Разбор задачи о проектировании косынки
56

57.

Разбор задачи о проектировании косынки
57

58.

Разбор задачи о проектировании косынки
Описать карту можно с помощью строки.
Например:
- ЗK18 — закрытая красная карта первой масти со значением 8.
- ОК18 открытая красная карта ...
Стопки карт будут массивами
58

59.

Тест Миллера
59

60.

3 Проектирование. Чистая архитектура
Многослойная архитектура является одной из архитектурных парадигм разработки
ПО, при которой функциональные области приложения разделяются на группы.
60

61.

3.1 Проектирование.
Чистая архитектура. Принципы
каждый слой занимается конкретной задачей.
логика разных слоёв не повторяется и не пересекается
способ обращения к нижестоящему слою чётко определён
способ поставки информации вышестоящему слою чётко определён
слои слабо связаны
слои расположены вертикально, хотя есть сквозная функциональность,
которая может пронизывать пирамиду сверху вниз
слои могут размещаться физически на одном компьютере ( в пределах
одного уровня), а могут быть на разных машинах, например, в
распределённых приложениях.
логика разных слоёв инкапсулирована, соответственно, разным слоям
не нужно делать никаких предположений о том, как реализован код
других слоёв приложения.
возможность использования в других сценариях (за счёт слабого
связывания и чётко определённой задачи).
61

62.

3.2 Проектирование.
Чистая архитектура. Примеры
62

63.

3.2 Проектирование.
Чистая архитектура. Примеры
63

64.

3.2 Проектирование.
Чистая архитектура. Примеры
1. MVC
2. MVP
3. MVVM
4. MVI
5. …
Куда
поместить
обработку
ошибок?
64

65.

3.2 Проектирование.
MV
Э. Гамма Приемы объектно-ориентированного
проектирования. Паттерны проектирования / Э.
Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес. –
СПб.: Питер, 2009. – 366 с.
1. MVC
2. MVP
3. MVVM
4. MVI
5. …
Джейсон Мак-Колм Смит Элементарные шаблоны
проектирования : Пер. с англ. — М. : ООО “И.Д.
Вильямс”, 2013. — 304 с.
65

66.

3.3 Проектирование. Процесс ICONIX
Рассматриваем весь процесс на примере...
*Также часто используют SADT (в электронном курсе есть информация)
66

67.

3.4 Проектирование. Литература
1. Буч Градди Объектно-ориентированный анализ и проектирование с примерами
приложений, 3-е изд. / Буч Градди, Максимчук Роберт А., Энгл Майкл У., Янг
Бобби Дж., Коналлен Джим, Хьюстон Келли А.: Пер с англ. — М.: ООО «И.Д.
Вильямс», 2010. — 720 с.
2. Розенберг Д., Скотт К. Применение объектного моделирования с
использованием UML и анализ прецедентов.: Пер. с англ. М.: ДМК Пресс, 2002
3. Процесс ICONIX. Диаграммы пригодности.- URL:
https://pro-prof.com/archives/2723
4. Мартин Р. Чистый код. Создание, анализ и рефакторинг. Библиотека
программиста. — СПб.: Питер, 2014. — 464 с.
5. Фаулер М. Рефакторинг. Улучшение существующего кода/ М. Фаулер. СимволПлюс, 2008. 432 с.
6. Аллен Э. Типичные ошибки проектирования / Э.Аллен: Пер. с англ. – СПб.:
Питер, 2003. – 224 с.
7. Многослойная архитектура. Определение и задачи. URL:
https://pro-prof.com/forums/topic/multilayered-architecture-definition-and-tasks
8. Чистая архитектура. URL: https://habr.com/ru/post/269589/
9. Карта диалоговых окон. URL: https://habr.com/ru/post/279373/
67

68.

3.4 Проектирование. Литература
10. Пример описания API от Яндекс. URL:
https://yandex.ru/dev/speller/doc/dg/reference/error-codes.html
11. Документация API "Руководство для технических писателей". URL:
https://starkovden.github.io/course-overview.html
12. Swagger — Инструмент для документирования API. URL:
https://editor.swagger.io/
13. Д. Цветцих. Чистая архитектура на практике (платный курс). URL:
https://click.linksynergy.com/link?id=dzb6dWyVoSo&offerid=507388.1499548&type=2
&murl=https%3A%2F%2Fwww.udemy.com%2Fcourse%2Fclean-architecture-csharp-ru
%2F
68

69.

4 Альтернативный подход SADT->IDEF/BPMN
Википедия:
{эта часть специально надергана из
википедии, так как почти не применяется}
IDEF0 используется для создания
«функциональной модели», которая
представляет собой структурированное
представление активности или процессов
внутри среды или системы.
IDEF1 используется для создания
«информационной модели», которая
представляет собой структуру или
семантику информации внутри среды или
системы.
IDEF2 используется для создания
«динамической модели».
69

70.

4.1 IDEF0
70

71.

4.1 IDEF0
71

72.

4.1 IDEF1
Википедия .… С сентября 2012 года, IDEF1X является частью международного стандарта
ИСО/МЭК/IEEE 31320-2:2012… который поддерживает реляционные и расширенные
реляционные базы данных, и более нового языка «идентификационного стиля»,
подходящего для объектных баз данных и объектно-ориентированного моделирования.
Фаза первая — определение сущностей
Фаза вторая — определение связей
... Главными результатами второго этапа являются:
Матрица отношений
Диаграммы уровней сущностей
…...
72

73.

4.1 IDEF1 - Матрица отношений
73

74.

4.1 IDEF1 - Диаграмма уровней сущностей
74

75.

4.1 IDEF1 - Фаза третья — определение ключей
Цели этапа определения ключей заключаются в следующем:
Уточнить неопределённые связи из второй фазы
Определить ключевые атрибуты для каждой сущности
75

76.

4.1 IDEF1 - Фаза четвёртая — определение атрибутов
76

77.

4.1 IDEF2
Simulation Model Design — методология динамического моделирования развития систем. В
связи с весьма серьёзными сложностями анализа динамических систем от этого стандарта
практически отказались, и его развитие приостановилось на самом начальном этапе. В
настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие
превращать набор статических диаграмм IDEF0 в динамические модели, построенные на
базе «раскрашенных сетей Петри» (CPN — Color Petri Nets);
77

78.

4.1 IDEF3
IDEF3 широко применяется при разработке информационных систем. При этом
используется инструмент визуального моделирования бизнес-процесc. (Википедия)
78

79.

4.1 IDEF3
Тут надо держать в
голове ось времени
79

80.

4.1 IDEF4
IDEF4 (Object-Oriented Design) – методология описания различных объектов в компании и
действий над ними.
Методология IDEF4 вводит объектно-ориентированный подход в набор стандартов IDEF.
Является основой для построения методики UML, и сейчас практически не
применяется.
Нотация была разработана для обеспечения перехода от предметной области и
требований к объектно-ориентированным моделям, где отражается их структура,
принципы взаимодействия. Объекты проектируются с достаточной детализацией, что дает
возможность анализировать их исходную сущность. IDEF4 обеспечивает связь и дает
возможность перейти от основного анализа объектов к их детальному рассмотрению и
реализации. IDEF4 обеспечивает связь между результатами базового анализа
предметной области и реализацией системы.
80

English Русский Rules