Высокоуровневое_проектирование_ПС_

1. Высокоуровневое проектирование программных средств

Метод диаграмм

2. Стили программирования

• Структурное программирование
• Метод потоков данных
• Объектно-ориентированное
программирование
• Функциональное программирование
2

3. Функциональные диаграммы

УПРАВЛЕНИЕ
Желание заключить
договор
В
Х
О
Д
Пожелания
Заказчика
А0
Описания
аналогов
Заключение договора
Техническое
задание
Календарный
план
Ресурсы
фирмы
Договор
Состояние
фирмы
Администрация
Отдел
маркетинга
В
Ы
Х
О
Д
Отдел
программирования
ИСПОЛНИТЕЛИ, ИНСТРУМЕНТЫ
3

4. Детализация базовой диаграммы

Желание
заключить
договор
Пожелания
Заказчика
Анализ
требований
1
2
Интерпретация
требований
Описания
аналогов
4
3
А1
5
Управление
требованиями
Техническое
задание
Решение
о
договоре
Ресурсы
фирмы
Календарный
план
Разработка
ТЗ
Состояние
фирмы
Согласование
договора
А
д
м
и
н
и
с
т
р
а
ц
и
я
О
т
д
е
л
м
а
р
к
е
т
и
н
г
а
П
р
о
г
р
а
м
м
и
с
т
ы
А
д
м
и
н
и
с
т
р
а
ц
и
я
П
р
о
г
р
а
м
м
и
с
т
ы
А
д
м
и
н
и
с
т
р
а
ц
и
я
П
р
о
г
р
а
м
м
и
с
т
ы
Договор
А
д
м
и
н
и
с
т
р
а
ц
и
я
4

5. Передаваемая информация и документы

1
2
3
4
5
Систематизированный набор требований с
указанием важности каждого из них
Реализуемые, по оценке отдела
программирования, наборы требований
Оценка затрат на реализацию различных
наборов требований
Оптимизированный набор пользовательских
требований к программе
Решение заключить договор
5

6. Унифицированный язык моделирования (Unified Modeling Language, UML)‏

Унифицированный язык моделирования
(Unified Modeling Language, UML)
Язык UML предназначен для объектно-ориентированного анализа и
моделирования предметной области программного средства (ПС)
Применение UML позволяет:
• Построить модели предметной области и бизнес-процессов, для
автоматизации которых предназначена наша программа
• Выделить процессы, подлежащие автоматизации (определить
границу проекта)
• Разработать концепцию программного средства
• Сформулировать требования к разрабатываемой программе
• Получить программный код–прототип (заготовку)
разрабатываемой программы
6

7. Средства UML

Язык UML позволяет построить диаграммы следующих типов:
• Диаграммы вариантов использования (Use case diagrams) предназначены для моделирования взаимодействия внешних
пользователей с ПС
• Диаграммы деятельности (блок-схемы бизнес-процессов)
• Диаграммы классов (Class diagrams) (статические диаграммы) предназначены для анализа и моделирования архитектуры ПС
• Диаграммы взаимодействия (Interaction diagrams)- предназначены
для моделирования взаимодействия подсистем ПС
• Диаграммы поведения (Behavior diagrams) - предназначены для
моделирования поведения ПС и ее подсистем
• Диаграммы реализации (Implementation diagrams)
7

8. Структурные диаграммы UML

8

9. UML: Диаграммы поведения

9

10. Диаграммы вариантов использования

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

11. Элементы диаграммы вариантов использования

Пользователь (Actor). Пользователями могут быть: человек,
использующий ПС; внешняя система или время (расписание)
Связь между пользователем и ПС (Communicates )
Вариант использования. Обычно это достаточно крупная
пользовательская задача, а не шаг её решения
Пакет (Package). Область диаграммы, рассматриваемая как
единое целое (внутренняя структура пакета в этой
диаграмме нас не интересует)
{ …}
Ограничения (Constraint). Ограничения и предположения,
которые должны быть выполнены для того, чтобы система была
правильной. Записываются в фигурные скобки.
Интерфейс (Interface).
Граница проекта (Boundary). Позволяет отделить задачи,
включенные в проект от остальных задач
Комментарий (Note)
11

12. Пример построения диаграммы варианта использования

Построим диаграмму использования студентом информационной системы
управления учебным процессом вуза (ИОС)
Студент может обратиться к системе чтобы:
Узнать расписание занятия своей
группы на текущую неделю
Расписание
занятий
Узнать расписание экзаменов и
зачетов
Просмотреть методические
материалы и учебный план по
выбранной дисциплине
Расписание
экзаменов
Студент
Получить дополнительные сведения о:
локации аудитории, контактах преподавателя
и т.д.
Методические
материалы
Дополнительные
сведения
12

13. Структура описания диаграммы использования

Название и назначение. Название должно быть лаконичным и отражать
смысл решаемой задачи. Например: «Расписание занятий для студентов».
Позволяет студенту просмотреть расписание занятий своей группы с любого
компьютера локальной вычислительной сети (ЛВС) или через сайт ВУЗа.
Предусловия. Формулировка условий, необходимых для выполнения варианта
использования. Например: {Компьютер должен быть включен в ЛВС}.
Основной и альтернативные потоки событий. Последовательность
1.
2.
3.
4.
5.
событий, протекающих при выполнении варианта использования. Например:
Студент вызывает программу;
С помощью появившегося диалога студент находит свою специальность,
курс, группу и период времени (четная/нечетная неделя);
Программа высвечивает расписание указанной группы;
При желании, студент может распечатать расписание;
Вариант использования завершается.
Постусловия. Условия, которым должен удовлетворять результат варианта
использования. Например: {Содержание расписания должно соответствовать
последнему утвержденному расписанию}
13

14. Отношение «Использование» (uses, include)

uses
Если какой то элемент поведения системы появляется в
нескольких вариантах использования, его удобно изобразить
отдельным овалом и «подключать» там, где он необходим.
Стрелка показывает, что элемент слева включает поведение
элемента справа. Например, преподаватель, чтобы изменить
личные данные или добавить методические материалы должен
зарегистрироваться.
Изменить личные
данные
Зарегистрироваться
Преподаватель
Добавить методические
материалы
14

15. Отношение «Расширение» (extends)

Один и тот же вариант использования может вести себя по разному,
extends
в зависимости от пользователя, его пожеланий или обстоятельств.
На диаграмме это обстоятельство изображается с помощью
элементов «Расширения» (extends). Элемент, на который
показывает стрелка, может включать поведение элемента из
которого стрелка выходит. Например, просмотреть расписание
можно по группам, по преподавателям или по аудиториям.
Расписание занятий
по группам
Расписание
занятий
extends
Расписание занятий
по преподавателям
Пользователь
Расписание занятий
по аудиториям
15

16. Диаграммы деятельности

• Диаграмма деятельности – блок-схема бизнес-процесса,
для которого разрабатывается ПС.
• Это мощный инструмент интенсивно используется,
прежде всего, на этапах разработки концепции проекта и
сценариев его использования.
• Цель концептуального описания - показать целостную
картину бизнес-процессов предметной области
разрабатываемого проекта и определить место ПС в его
управлении.
• Детализация диаграммы зависит от решаемой задачи.
Таким образом, диаграмма деятельности может применяться как для
описания бизнес-процесса, так и для формирования совокупности
функциональных требований к разрабатываемой системе.
16

17. Диаграммы деятельности

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

18. Компоненты диаграммы деятельности

Для создания диаграммы деятельности используются следующие узлы:
• Начальный узел деятельности (или начальное состояние
деятельности) (activity initial node)
• Узел управления (control node)
• Конечный узел деятельности (или конечное состояние
деятельности) (activity final node)
• Конечный узел потока (или конечное состояние потока) (flow final
node)
• Узел решения
18

19. Узлы диаграммы деятельности

Узел управления (control node) - это абстрактный узел
действия, которое координирует потоки действий
Начальный узел деятельности (или начальное состояние
деятельности) (activity initial node) - является узлом
управления, в котором начинается поток (или потоки) при
вызове данной деятельности извне
• Конечный узел деятельности (или конечное состояние
деятельности) (activity final node) - является узлом
управления, который останавливает (stop) все потоки данной
диаграммы деятельности.
• Конечный узел потока (или конечное состояние потока)
(flow final node) - является узлом управления, который
завершает данный поток.
Узел решения - предназначен
для определения правила
ветвления и различных
вариантов дальнейшего развития
сценария.
19

20.

Узлы диаграммы деятельности
Узел управления (control node) - это абстрактный узел действия,
которое координирует потоки действий
Начальный узел деятельности (или начальное состояние
деятельности) (activity initial node) - является узлом управления, в
котором начинается поток (или потоки) при вызове данной
деятельности извне
Конечный узел деятельности (или конечное состояние
деятельности) (activity final node) - является узлом
управления, который останавливает (stop) все потоки данной
диаграммы деятельности
Конечный узел потока (или конечное состояние потока)
(flow final node) - является узлом управления, который
завершает данный поток
Узел решения предназначен
для определения правила
ветвления
и
различных
вариантов
дальнейшего
развития сценария.
20

21. Объекты диаграммы деятельности

• Объект, над которым выполняются действия.
• Это не обязательный элемент диаграммы, но в
некоторых случаях необходимо показать объект
инициирующий выполнение действий, или
являющийся их промежуточным или конечным
результатом.
21

22. «Плавательные дорожки»

Деятельность (Activity) -это некоторый относительно продолжительный
этап выполнения совокупности атомарных действий. В конечном итоге
деятельность сводится к некоторому результирующему действию нескольких
субъектов.
Чтобы
наглядно
представить
взаимодействие субъектов отведем
для каждого из них «плавательную
дорожку» (swim lanes). В нашем
примере, это вертикальные полосы,
в
которых
изображаются
все
действия субъекта.
Дорожки зачастую символизируют
роль
пользователя
или
организационное
подразделение,
осуществляющее
определенные
действия
в
рамках
данной
деятельности
22

23. Плавательные дорожки

Дорожки могут быть вертикальными или
горизонтальными. Чтобы конкретизировать субъект,
используются вложенные дорожки. Для конкретизации
действий, для которых строится дорожка, в ее названии
указывается действие.
23

24. Пример диаграммы деятельности «Покупка товара»

24

25. Диаграммы классов (статические диаграммы)

При объектном проектировании диаграммы классов являются основным
видом диаграмм. Рассмотрим три этапа проектирования:
1. Разработка концепции ПС
2. Формулировка требований к программе (Техническое задание)
3. Реализация.
В зависимости от этапа меняются назначения и смысл диаграммы
классов, происходит уточнение и конкретизация её параметров.
На первом этапе –классы отображают типы объектов предметной
области, а диаграммы – отношения между объектами этих типов.
На втором этапе подробно описываются интерфейсы классов, а связи
интерпретируются как ответственности классов друг перед другом.
Только на третьем этапе классы модели становятся теми
программными классами, к которым мы привыкли в объектном
программировании.
25

26. Элементы диаграммы классов, используемые на этапе разработки концепции

Название
Список
свойств
Список
методов
Класс. Описывает тип объектов предметной области с их
структурой, свойствами, поведением и отношениями.
Например, класс «Расписание» соответствует расписанию
занятий, включающему названия студенческих групп, даты и
номера пар, аудитории, дисциплины и преподавателей,
проводящих занятие.
Ассоциация. Описывает взаимодействие между классами.
Например: студент X обучается по специальности Y.
Обобщение (Generalization).Отображает иерархию создаваемых
классов, позволяющую использовать механизм наследования.
Например, студент, преподаватель и администратор являются
пользователями информационной системы «Расписание».
{ …}
Ограничения (Constraint). Ограничения и предположения,
которые должны быть выполнены для того, чтобы система была
правильной. Записываются в фигурные скобки.
26

27. Пример построения диаграммы классов на этапе разработки концепции

Пользователь
Просмотр
расписания
Расписание
{Расписание
существует}
Любой пользователь программы
может просмотреть расписание,
если оно существует.
Пользователями программы являются:
Студент
Просмотр
расписания
Преподаватель
Просмотр
расписания
Студент
Преподаватель
Администратор
Подчиним перечисленные классы классу
«Пользователь».
Не смотря на то, что свойства и поведение этих
классов различны, каждый из них наследует
метод «Просмотр расписания».
Администратор
Просмотр
расписания
27

28. Стереотипы классов

Большинство объектов UML имеет стереотипы. Стереотипы – механизм,
позволяющий разделить типовые элементы по категориям, отличающимся
смыслом, свойствами и поведением.
Рассмотрим применение стереотипов на примере классов. Класс может
иметь один из следующих стереотипов:
Мета класс (metaclass)- класс, порождающий остальные классы
Управляющий класс (delegates)- класс, управляющий работой
других классов
Исполняемый класс (implementation class)- класс, …..
Структура (struct)- класс, …..
Запись (type)- класс, …..
Объединение (union)- класс, …..
Утилита (utilite)- класс, …..
28

29. Развитие диаграммы классов на этапе формулировки требований

Класс. Описывает тип объектов предметной области с их структурой,
свойствами, поведением и отношениями.
Название
Список
методов
Интерфейс. Описывает внешние методы класса, компонента,
пакета или другого элемента без описания внутренней структуры
этого элемента.
Ассоциация. Описывает взаимодействие между классами.
Например: студент X обучается по специальности Y.
29

30. Виды связей между классами

*
0…*
Часть
Целое
Ассоциация с навигацией. Концы линии ассоциации – роли. Стрелка
указывает от объекта, вызывающего связь к вызываемому. Символы
под концами ассоциации указывают кратность связываемых объектов.
Например, один преподаватель может вести до 5 разных предметов (1
1..5)
Агрегация – особая разновидность ассоциации, представляющая
структурную связь целого (контейнера) и его части.
Контейнер
Композиция - более строгий вариант агрегации с четко выраженными
отношениями владения и совпадением времени жизни частей и целого.
(время существования экземпляров класса контейнера и экземпляров
содержащихся в нем объектов одинаково).
Родитель
Обобщение – выражает специализацию или наследование, в
Содержимое
котором специализированный элемент (потомок) наследует
свойства и методы родителя. Графически обобщение
представлено в виде сплошной линии с пустой стрелкой,
указывающей на родителя.
Клиент
Поставщик
Реализация (семантическая связь между классами), — отношение
между двумя элементами модели, в котором один элемент (клиент)
реализует поведение, заданное другим элементом (поставщиком)..
30

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

Диаграммы взаимодействия (interaction diagrams) описывают поведение
взаимодействующих групп объектов. Как правило, одна диаграмма
охватывает поведение объектов только одного варианта
использования.
При взаимодействии объекты обмениваются сообщениями следующих
типов:
Информационное (informative) - объект-получатель принимает
некоторую информацию;
Запрос (interrogative)- запрашивается информация об объекте
получателе;
Императив (imperative) – распоряжение объекту получателю выполнить
некое действие
.
Существует два вида диаграмм взаимодействия:
Диаграммы последовательности (sequence diagrams), отражающие
поток событий, упорядоченный во времени;
Кооперативные диаграммы (collaboration diagrams) – отражающие
связи между объектами, возникающие при их взаимодействии.
31

32. Диаграммы последовательности

Диаграммы позволяют проследить взаимодействие программных
объектов во времени.
Взаимодействующие объекты изображаются прямоугольниками в верхней
части диаграммы. Самый левый объект, как правило, пользователь,
инициирующий моделируемое действие.
Ось времени направлена сверху вниз. От каждого объекта вниз рисуется
пунктирная линия, называемая «линией жизни» объекта.
Сообщения изображаются горизонтальными стрелками, соединяющими
линии жизни передающего и получающего объектов. Сообщение,
появившееся позже, изображается ниже предыдущих. Содержание
сообщения записывается над стрелкой. Тип сообщения отображается
формой стрелки.
Активность объекта изображается узким прямоугольником на его линии
жизни. Если сообщение пришло к не активированному объекту, он
активируется (появляется прямоугольник активности). После
последнего переданного сообщения объект деактивируется
(прямоугольник заканчивается).
32

33. Построение диаграммы последовательности

Очередность сообщений
Построение диаграммы последовательности
Пользователь
Объект 1
Объект 2
Сообщение
Сообщение
Ответ
Ответ
В верхней части диаграммы нарисуем прямоугольники –объекты.
От каждого прямоугольника опустим вниз пунктирную линию. Это линия
жизни объекта.
Очередность сообщений будем изображать, рисуя последующее
сообщение ниже предыдущего.
Сообщения изобразим стрелками, идущими от линии жизни объекта –
источника к объекту получателю.
Период активности объекта изобразим узким прямоугольником на его
линии жизни.
33

34. Диаграмма последовательности просмотра расписания

Интерфейс
Пользователь
Расписание
Принтер
Запрос
Список
режимов
Режим
Запрос на
список
параметров
Список параметров
Выбор параметров
Расписание
Печатать?
Да
Принтер готов?
Готов
Печатать
На печать
расписание
Распечатка расписания
34