Процессы программной инженерии Реализация и изменение процессов (Часть 2)

1.

Процессы программной инженерии
Реализация и изменение
процессов
(Часть 2)

2.

Цели
Представлять:
• Модели этапов унифицированного процесса
(модель вариантов использования,
аналитическая модель, проектная модель)
• Пример банкомата
• Разработка всех трех моделей (модель
вариантов использования, аналитическая
модель, модель проекта) для банкомата
2

3.

Акронимы
• SS –Программная система
• UC – Вариант (ы) использования
• UCM – Модель вариантов использования
• AM – Аналитическая модель
• DM – Проектная модель
• ATM – Банкомат
3

4.

1.1. Инфраструктура процесса
4

5.

1.1.2. Модели этапов
5

6.

Зависимость этапов
унифицированного процесса и
моделей
Этапы\модели
Требования
Анализ
Проектирование
Реализация
Тестирование
Вариантов
использования
Аналитическая
Проектная
Размещения
Реализации
Тестирования
6

7.

1.1.2.1. Модель вариантов
использования
7

8.

Модель вариантов
использования (UCM)
• Цель унифицированного процесса – управлять
разработчиками во время разработки и внедрения
SS
• Трудно определить пользовательские требования,
поэтому разработчики пытаются включить его в
процесс. SS разрабатывается как средство для
пользователя, помогающее выполнять его типовые
задачи.
• Разработка UCM является итеративным процессом
• UC проходит красной нитью через все модели
8

9.

UC и UCM1
• UC – описание того, как SS используется любым
пользователем, решающим его типовую задачу.
UC моделирует удовлетворение конкретного
пользовательского требования.
• Каждый UC представляет последовательность
операций, которые выполняет система, чтобы
достигнуть важного для пользователя
результата.
9

10.

UC и UCM2
• UCM – описание того, как SS используется в целом,
чтобы выполнить все намеченные задачи всех его
пользователей
• Важны законченность, непротиворечивость,
совместимость... Это - проблемные вопросы
• Моделирование UCM помогает только частично
• UML является частью унифицированного процесса
и помогает формализовать и визуализировать
процесс
10

11.

Преимущества UC
1. UC предлагают компромисс между системным и
интуитивным способами фиксировать
функциональные требования пользователя
2. UC ведёт процесс разработки от анализа до
тестирования и реализации
3. UC – взгляд пользователя на SS
4. UC включают пользователя в процесс разработки и
помогают ему договориться с разработчиками
11

12.

Актёры и UC1
• У SS обычно есть различные типы
пользователей
• Каждый отдельный тип пользователя – актёр не
обязательно человек
• Актёр может иметь несколько ролей, или
несколько актёров могут играть ту же самую роль
• актёры общаются с SS при помощи сообщений
12

13.

Актёры и UC2
• UC – конкретная функция, выполняемая SS
• Все актёры и все UC составляют UCM
• Другие модели (аналитическая, проектная...)
описывают, как UC реализуются в системе
13

14.

Специализация и
стандартизация процессов
• Нет единого унифицированного процесса,
подходящего для всех случаев жизни
• Есть много аспектов, которые должны быть
учтены
• Процессы конфигурируются и адаптируются для
разработки определенной SS
• Специализация процессов и компаний
разработчиков
• Стандартизация в пределах одной компании для
разработки подобных продуктов
14

15.

UC и итерации
• Есть много причин итераций. Реализация
каждого UC является также отдельной
итерацией
• Модель процесса и принцип организации
итерации могут дат возможность начать
эксплуатацию SS ещё в период разработки
• UC определяет архитектуру. Важно, чтобы
архитектура не изменялась как можно
дольше
15

16.

Фиксирование
пользовательских требований1
• Фиксирование пользовательских требований решает
задачи:
– Установить правильные пользовательские
требования
– Представить их в удобной форме
• Установить правильные пользовательские
требования означает, что они будут корректны, и
пользователи получат то, что они ожидают
• Представить их в удобной форме означает, что
записанные требования будут легко понятны
16

17.

Фиксирование
пользовательских требований2
• Пользовательские требования устанавливаются
путем анализа отдельных групп пользователей.
Это - основа для формирования модели UC.
• Каждый возможный вариант применения SS
является кандидатом для UC
• Перекрытие, детализация, систематизация
• Процесс заканчивается, когда зафиксированы
все функциональные требования
17

18.

Фиксирование
пользовательских требований3
• В UC можно фиксировать некоторые важные
нефункциональные требования, тем самым
определяя значымые функции SS (характеристики
времени, надежность, безопасность, точность...)
• Совместно с пользователями определяется степень
важности UC.. Функционально близкие UC
объеденяются в группы.
• UCM – это соглашение между разработчиками и
пользователями (клиентами), что должна делать SS,
и включает все UC.
18

19.

Фиксирование
пользовательских требований4
• Опросы пользователей не всегда позволяют установить их
требования. Список может быть внушительным, но не
представлять ценности.
• Определяя UC, пользователей спрашивают, что они ожидают от
SS
• Совокупность пользовательских требований интуитивна. Они
описываются обычним языком. Выяснение пользовательских
требований включает пользователя в процесс разработки
• Ключевые пользователи- с ними уточняются существующие
на предприятие процессы
• Владельцы предметных областей могут менять
существующие на предприятии процессы
• Внедрение программно системы часто позволяет изменить и
оптимизировать процессы на предприятии.
19

20.

Модель UC
1.
Задача и ее анализ, анализ специфических
ситуаций
2.
UC и список актёров
3.
Схема UCM (графическая схема актёров и их
взаимодействия с UC)
4.
Функции актёров (каждый актёр документируется)
5.
Спецификации UC (каждый UC документируется)
20

21.

Спецификация1 UC
• Цель: формулировка цели и ожидаемых результатов
• Актёры: определение актёров, участвующих в
реализации SS
• Соединения с другим UC: описание интерфейсов с
другими UC
• Нефункциональные требования: описание
нефункциональных требований (время, качество,
отклики...)
• Предусловия: описание условий, в соответствии с
которыми выполняется UC
21

22.

Спецификация2 UC
• Условие выполнения: описание события,
непосредственно инициирующего выполнение UC
• Постусловие: описание ситуации (изменения
состояния) после завершения этого UC
• Основной сценарий: описание действий SS,
выполняющих этот UC
• Альтернативные сценарии: сценарии, которые могут
произойти, когда актёр выбирает не основное, а
любое альтернативное или неправильное действие
22

23.

Пример: UCM ATM1
1. Задача: создать SS для обслуживания
клиента банка с помощью ATM
2. Анализ задач:...
3. Список актёров: клиент, система банка
4. Список UC: снятие денег, внесение денег,
перевод денег со счета на счет
23

24.

Пример: UCM ATM2
Снятие
денег
Клиент
Внесение
денег
Банковская
система
Перевод денег
со счета на счет
24

25.

Пример: UCM ATM3
Актёры:
1. Клиент банка:владелец денег. Может внести
деньги в банк, снять в пределах счета,
перевести деньги со счета на счет.
2. Банковская система : SS, обслуживающая
счета и клиентов. Она отвечает за
корректный учет денег и выполнение
операций.
25

26.

Пример: UCM ATM4
(Снятие денег),
• Цель: гарантировать корректную выдачу денег
клиенту
• Актёры: клиент, банковская система
• Связи с другими UC: отсутствуют
• Нефункциональные требования: выдаваемая сумма
не должно превышать баланса
• Предусловия:
1. Пользователь подключен к ATM
2. Пользователь вставил электронную карту идентификации в
ATM и ввел корректный PIN код
26

27.

Пример: ATM UCM5
(Снятие денег),
• Условие выполнения: пользователь выбрал функцию
меню снятия денег
• Постусловие: счет пользователя уменьшился на
сумму снятых денег
• Основной сценарий:
1.
Запрашивается сумма
2.
Проверяется, есть ли запрашиваемая сумма на счету
3.
...
• Альтернативные сценарии: пользователь прерывает
работу, не указав сумму
27

28.

Деньги?
Не советую следовать
этому примеру
вслепую, если придется
реализовать подобную
SS!
28

29.

1.1.2.2. Аналитическая модель
29

30.

Аналитические модели (AM)
• Процесс: UCM AM DM
• AM является промежуточной моделью,
разработанной для увеличения
эффективности реализации SS, и позволяет
разработчикам системы лучше понять
свойства SS
• AM детализирует спецификации UC,
определяет отношение между ними и видом
взаимодействия
30

31.

Разработка AM1
• AM системы разрабатывается поочередно анализируя
UC. Это возрастающий и итеративный процесс.
• Каждый раз стараются выбрать самые важные,
сложные и характерные UC или их группы. Это
позволяет быстрее получит окончательную
архитектуру SS.
• Во время каждой итерации разрабатываются один или
несколько классов, или расширяются существующие,
если им присваиваются новые функции.
31

32.

Разработка AM2
• На каждый класс возлагается ответственность за
реализацию одного или нескольких UC,
определяются атрибуты.
• AM состоит из классов и отношений между ними
• Процесс завершается, когда будут
проанализированы все UC.
• Систематизация и оптимизация классов
• Необходимо сохранить связь с UC, чтобы было
возможно выборочные исправления во время
итераций.
32

33.

Разработка AM3
• AM представляется в диаграммами классов,
трасс и взаимодействия (сотрудничества). У
каждого класса есть собственные "роли" при
реализации одиного или нескольких UC.
Возможен пояснительный текст.
• Диаграмма классов показывает классы и связи
между ними.
• Диаграмма трасс определяет связь с UC
• Диаграмма взаимодействия подобна диаграмме
классов, но показывает порядок взаимодействия
объектов, когда они обмениваются сообщениями
между собой
33

34.

Типы (стереотипы) классов
• Классы границ используются, чтобы смоделировать
взаимодействие между системой и актёрами
• Классы управлений используются, чтобы
скоординировать, определить последовательности
этапов, управлять объектами
• Классы объектов используются, чтобы смоделировать
долговременную или постоянную информацию
Стереотипы классов сокращают описание функций,
помогает идентифицировать повторно используемые части
34

35.

Пример: детализированная
диаграмма трасс снятия денег
UCM
Снятие денег
AM
Трасса
Снятие денег
Класс
управления
Участники
Класс
объекта
Классы
границ
{
Классы
Устройство
выдачи денег
Интерфейс
выдачи денег
Снятие денег
со счета
Счет
35

36.

Пример: диаграмма классов
Диаграмма классов показывает классы и их
взаимосвяз
Клиент
Устройство
выдачи денег
«Снятие денег
со счета»
Интерфейс
выдачи денег
«Перевод»
Устройство
приема денег
«Снятие денег»
Счет
36

37.

Пример: диаграмма взаимодействия
снятия денег
Идентификация
Инициирование
операции «Снятие»
Интерфейс
выдачи денег
Снятие денег
со счета
Подтверждение
и снятие денег
Устройство
выдачи денег
Выдача денег
Счет
Выбор устройство
37

38.

1.1.2.3. Модель проекта
38

39.

Модель проекта (DM)
• AM является исходной для DM, которая
развивает ее дальше. DM является начальной
для этапов развертывания и реализации.
• DM определяет среду реализации SS,
детализирует классы, подсистемы, интерфейсы
и их взаимодействия в реализации UC.
Подбираются инструменты.
• Проектная модель является иерархической и
более ориентированной на окружение, чем АМ,
однако сохраняет ее структуру, и трассу к UC
(Оптимальность DM требует разумного
компромисса).
39

40.

Разработка DM1
• DM выражается диаграммами трасс,
взаимодействия, последовательностей и
подсистем. Также возможен текст, поясняющий
DM.
• Диаграмма трасс определяет связь с UC
• Диаграмма взаимодействия показывает порядок
взаимодействия объектов входе обмена
сообщениями (Подобна AM, но более подробная)
• Диаграмма последовательности определяет
последовательность действий в реализации UC
40

41.

Разработка DM2
• Диаграмма подсистем определяет структуру
SS на уровне классов и подсистем,
устанавливает их суть и функции
• DM может создаваться “сверху вниз” и “снизу
вверх”
• Систематизация и оптимизация классов,
уточнение функций реализации SS
41

42.

Подсистемы DM
• Трудно создавать систему, состоящую из сотен
классов. Они группируются в подсистемы.
• Структура SS создается поочередно
рассматривая классы, по их смыслу, сходству и
функциональности распределяя на подсистемы.
Это возрастающий итеративный процесс.
Процесс заканчивается после просмотра всех
классов.
• Каждый раз выбираются самые важные классы.
Таким образом, структура подсистем
устанавливается быстрее.
42

43.

Пример: детализированная
диаграмма трассы снятия денег
AM
Интерфейс
выдачи денег
Клавиатура
Считыватель
карточки
Снятие денег
со счета
Счет
Клиентменеджер
Сенсор
устройства
выдачи
Дисплей
DM
Устройство
выдачи денег
Линия
выдачи
Счетчик
наличных денег
Устройство
выдачи денег
Менеджер
переводов
Счет
Менеджер
счетов
43

44.

Пример:Диаграмма
взаимодействия снятия денег
Считыватель
карточки
Устройство
выдачи денег
Менеджер
переводов
Дисплей
Клавиатура
Линия
выдачи
Сенсор
устройства
выдачи
Клиентменеджер
Счетчик
наличных
денег
Менеджер
счетов
Счет
44

45.

Пример: Фрагмент диаграммы
последовательности снятия денег
Считыватель
карточки
Вставьте карточку
КлиентДисплей Клавиатура
менеджер
Счетчик
наличных
денег
Менеджер
переводов
Идентификация карточки
Показывает запрос
Запрос PIN кода
Ввод PIN кода
PIN код
Запрос подтверждения PIN кода
Подтверждение PIN кода
Показывает запрос
Вводится сумма
Запрос суммы
Сумма
Возможность
выдачи
Проверка счета
45

46.

Пример:Диаграмма подсистем
Считыватель
карточки
Интерфейс
Человек –
Выдача
система
Менеджер
переводов
Дисплей
Клавиатура
Линия
выдачи
Сенсор
устройства
выдачи
Менеджер
переводов
Клиентменеджер
Счетчик
наличных
денег
Подсистема
сервиса
“Менеджер
выдачи денег”
Снятие
Устройство
выдачи денег денег
Менеджер
счетов
Перевод
Менеджер
счетов
Счет
46

47.

Спасибо за Ваше внимание!