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

Август 19, 2022

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

Содержание

2. Цели Представлять: Модели этапов унифицированного процесса (модель вариантов использования, аналитическая модель, проектная модель) Пример банкомата Разработка
3. Акронимы SS –Программная система UC – Вариант (ы) использования UCM – Модель вариантов использования AM –
4. 1.1. Инфраструктура процесса
5. 1.1.2. Модели этапов
6. Требования Анализ Проектирование Реализация Тестирование Вариантов использования Аналитическая Проектная Размещения Реализации Тестирования Зависимость этапов унифицированного процесса
7. 1.1.2.1. Модель вариантов использования
8. Модель вариантов использования (UCM) Цель унифицированного процесса – управлять разработчиками во время разработки и внедрения SS
9. UC и UCM1 UC – описание того, как SS используется любым пользователем, решающим его типовую задачу.
10. UC и UCM2 UCM – описание того, как SS используется в целом, чтобы выполнить все намеченные
11. Преимущества UC UC предлагают компромисс между системным и интуитивным способами фиксировать функциональные требования пользователя UC ведёт
12. Актёры и UC1 У SS обычно есть различные типы пользователей Каждый отдельный тип пользователя – актёр
13. Актёры и UC2 UC – конкретная функция, выполняемая SS Все актёры и все UC составляют UCM
14. Специализация и стандартизация процессов Нет единого унифицированного процесса, подходящего для всех случаев жизни Есть много аспектов,
15. UC и итерации Есть много причин итераций. Реализация каждого UC является также отдельной итерацией Модель процесса
16. Фиксирование пользовательских требований1 Фиксирование пользовательских требований решает задачи: Установить правильные пользовательские требования Представить их в удобной
17. Пользовательские требования устанавливаются путем анализа отдельных групп пользователей. Это - основа для формирования модели UC. Каждый
18. Фиксирование пользовательских требований3 В UC можно фиксировать некоторые важные нефункциональные требования, тем самым определяя значымые функции
19. Фиксирование пользовательских требований4 Опросы пользователей не всегда позволяют установить их требования. Список может быть внушительным, но
20. Модель UC Задача и ее анализ, анализ специфических ситуаций UC и список актёров Схема UCM (графическая
21. Спецификация1 UC Цель: формулировка цели и ожидаемых результатов Актёры: определение актёров, участвующих в реализации SS Соединения
22. Спецификация2 UC Условие выполнения: описание события, непосредственно инициирующего выполнение UC Постусловие: описание ситуации (изменения состояния) после
23. Пример: UCM ATM1 Задача: создать SS для обслуживания клиента банка с помощью ATM Анализ задач:... Список
24. Пример: UCM ATM2 Снятие денег Внесение денег Перевод денег со счета на счет Клиент Банковская система
25. Пример: UCM ATM3 Актёры: Клиент банка:владелец денег. Может внести деньги в банк, снять в пределах счета,
26. Пример: UCM ATM4 (Снятие денег), Цель: гарантировать корректную выдачу денег клиенту Актёры: клиент, банковская система Связи
27. Пример: ATM UCM5 (Снятие денег), Условие выполнения: пользователь выбрал функцию меню снятия денег Постусловие: счет пользователя
28. Деньги? Не советую следовать этому примеру вслепую, если придется реализовать подобную SS!
29. 1.1.2.2. Аналитическая модель
30. Аналитические модели (AM) Процесс: UCM ? AM ? DM AM является промежуточной моделью, разработанной для увеличения
31. Разработка AM1 AM системы разрабатывается поочередно анализируя UC. Это возрастающий и итеративный процесс. Каждый раз стараются
32. Разработка AM2 На каждый класс возлагается ответственность за реализацию одного или нескольких UC, определяются атрибуты. AM
33. Разработка AM3 AM представляется в диаграммами классов, трасс и взаимодействия (сотрудничества). У каждого класса есть собственные
34. Типы (стереотипы) классов Классы границ используются, чтобы смоделировать взаимодействие между системой и актёрами Классы управлений используются,
35. Пример: детализированная диаграмма трасс снятия денег Устройство выдачи денег Интерфейс выдачи денег Снятие денег со счета
36. Диаграмма классов показывает классы и их взаимосвяз Клиент Устройство выдачи денег Интерфейс выдачи денег Устройство приема
37. Пример: диаграмма взаимодействия снятия денег Выдача денег Интерфейс выдачи денег Устройство выдачи денег Снятие денег со
38. 1.1.2.3. Модель проекта
39. Модель проекта (DM) AM является исходной для DM, которая развивает ее дальше. DM является начальной для
40. Разработка DM1 DM выражается диаграммами трасс, взаимодействия, последовательностей и подсистем. Также возможен текст, поясняющий DM. Диаграмма
41. Разработка DM2 Диаграмма подсистем определяет структуру SS на уровне классов и подсистем, устанавливает их суть и
42. Подсистемы DM Трудно создавать систему, состоящую из сотен классов. Они группируются в подсистемы. Структура SS создается
43. Пример: детализированная диаграмма трассы снятия денег Интерфейс выдачи денег Устройство выдачи денег Снятие денег со счета
44. Пример:Диаграмма взаимодействия снятия денег Считыватель карточки Дисплей Клавиатура Линия выдачи Сенсор устройства выдачи Клиент- менеджер Счетчик
45. Пример: Фрагмент диаграммы последовательности снятия денег Считыватель карточки Дисплей Клавиатура Клиент- менеджер Счетчик наличных денег Менеджер
46. Пример:Диаграмма подсистем Подсистема сервиса “Менеджер выдачи денег” Дисплей Клавиатура Линия выдачи Сенсор устройства выдачи Клиент- менеджер
48. Скачать презентацию

Слайд 2

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

банкомата
Разработка всех трех моделей (модель вариантов использования, аналитическая модель, модель проекта) для банкомата

Слайд 3

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

– Аналитическая модель
DM – Проектная модель
ATM – Банкомат

Слайд 4

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

Слайд 5

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

Слайд 6

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

Слайд 7

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

Слайд 8

Модель вариантов использования (UCM)
Цель унифицированного процесса – управлять разработчиками во время

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

Слайд 9

UC и UCM1
UC – описание того, как SS используется любым пользователем,

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

Слайд 10

UC и UCM2
UCM – описание того, как SS используется в

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

Слайд 11

Преимущества UC
UC предлагают компромисс между системным и интуитивным способами фиксировать функциональные

требования пользователя
UC ведёт процесс разработки от анализа до тестирования и реализации
UC – взгляд пользователя на SS
UC включают пользователя в процесс разработки и помогают ему договориться с разработчиками

Слайд 12

Актёры и UC1
У SS обычно есть различные типы пользователей
Каждый отдельный

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

Слайд 13

Актёры и UC2
UC – конкретная функция, выполняемая SS
Все актёры и

все UC составляют UCM
Другие модели (аналитическая, проектная...) описывают, как UC реализуются в системе

Слайд 14

Специализация и стандартизация процессов
Нет единого унифицированного процесса, подходящего для всех случаев

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

Слайд 15

UC и итерации
Есть много причин итераций. Реализация каждого UC является также

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

Слайд 16

Фиксирование пользовательских требований1
Фиксирование пользовательских требований решает задачи:
Установить правильные пользовательские требования
Представить

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

Слайд 17

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

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

Фиксирование пользовательских требований2

Слайд 18

Фиксирование пользовательских требований3
В UC можно фиксировать некоторые важные нефункциональные требования,

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

Слайд 19

Фиксирование пользовательских требований4
Опросы пользователей не всегда позволяют установить их требования. Список

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

Слайд 20

Модель UC
Задача и ее анализ, анализ специфических ситуаций
UC и список актёров
Схема

UCM (графическая схема актёров и их взаимодействия с UC)
Функции актёров (каждый актёр документируется)
Спецификации UC (каждый UC документируется)

Слайд 21

Спецификация1 UC
Цель: формулировка цели и ожидаемых результатов
Актёры: определение актёров, участвующих в

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

Слайд 22

Спецификация2 UC
Условие выполнения: описание события, непосредственно инициирующего выполнение UC
Постусловие: описание ситуации

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

Слайд 23

Пример: UCM ATM1
Задача: создать SS для обслуживания клиента банка с

помощью ATM
Анализ задач:...
Список актёров: клиент, система банка
Список UC: снятие денег, внесение денег, перевод денег со счета на счет

Слайд 24

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

Слайд 25

Пример: UCM ATM3
Актёры:
Клиент банка:владелец денег. Может внести деньги в банк,

снять в пределах счета, перевести деньги со счета на счет.
Банковская система : SS, обслуживающая счета и клиентов. Она отвечает за корректный учет денег и выполнение операций.

Слайд 26

Пример: UCM ATM4 (Снятие денег),
Цель: гарантировать корректную выдачу денег клиенту
Актёры:

клиент, банковская система
Связи с другими UC: отсутствуют
Нефункциональные требования: выдаваемая сумма не должно превышать баланса
Предусловия:
Пользователь подключен к ATM
Пользователь вставил электронную карту идентификации в ATM и ввел корректный PIN код

Слайд 27

Пример: ATM UCM5 (Снятие денег),
Условие выполнения: пользователь выбрал функцию меню снятия

денег
Постусловие: счет пользователя уменьшился на сумму снятых денег
Основной сценарий:
Запрашивается сумма
Проверяется, есть ли запрашиваемая сумма на счету
...
Альтернативные сценарии: пользователь прерывает работу, не указав сумму

Слайд 28

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

Слайд 29

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

Слайд 30

Аналитические модели (AM)
Процесс: UCM ? AM ? DM
AM является промежуточной моделью,

разработанной для увеличения эффективности реализации SS, и позволяет разработчикам системы лучше понять свойства SS
AM детализирует спецификации UC, определяет отношение между ними и видом взаимодействия

Слайд 31

Разработка AM1
AM системы разрабатывается поочередно анализируя UC. Это возрастающий и

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

Слайд 32

Разработка AM2
На каждый класс возлагается ответственность за реализацию одного или

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

Слайд 33

Разработка AM3
AM представляется в диаграммами классов, трасс и взаимодействия (сотрудничества).

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

Слайд 34

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

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

Слайд 35

Пример: детализированная диаграмма трасс снятия денег
Устройство
выдачи денег
Интерфейс
выдачи денег
Снятие денег
со

счета

Счет

Снятие денег

UCM

Трасса

Участники

Классы

{

Классы
границ

Класс
управления

Класс объекта

Слайд 36

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

денег

«Снятие денег
со счета»

«Перевод»

«Снятие денег»

Счет

Пример: диаграмма классов

Слайд 37

Пример: диаграмма взаимодействия снятия денег
Выдача денег
Интерфейс
выдачи денег
Устройство
выдачи денег
Снятие денег
со

счета

Счет

Подтверждение и снятие денег

Выбор устройство

Инициирование операции «Снятие»

Идентификация

Слайд 38

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

Слайд 39

Модель проекта (DM)
AM является исходной для DM, которая развивает ее дальше.

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

Слайд 40

Разработка DM1
DM выражается диаграммами трасс, взаимодействия, последовательностей и подсистем. Также

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

Слайд 41

Разработка DM2
Диаграмма подсистем определяет структуру SS на уровне классов и

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

Слайд 42

Подсистемы DM
Трудно создавать систему, состоящую из сотен классов. Они группируются в

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

Слайд 43

Пример: детализированная диаграмма трассы снятия денег
Интерфейс
выдачи денег
Устройство
выдачи денег
Снятие денег

со счета

Счет

Дисплей

Клавиатура

Считыватель
карточки

Сенсор
устройства
выдачи

Линия
выдачи

Счетчик
наличных денег

Клиент-
менеджер

Устройство
выдачи денег

Менеджер
переводов

Счет

Менеджер
счетов

Слайд 44

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

выдачи денег

Слайд 45

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

карточки

Запрос PIN кода

Показывает запрос

Ввод PIN кода

PIN код

Запрос подтверждения PIN кода

Подтверждение PIN кода

Запрос суммы

Показывает запрос

Вводится сумма

Сумма

Возможность
выдачи

Проверка счета

Слайд 46

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

карточки

Менеджер
переводов

Менеджер
счетов

Счет

Менеджер
счетов

Снятие
денег

Устройство
выдачи денег

Выдача

Перевод

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

Содержание

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

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

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

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

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

Модель вариантов использования (UCM)Цель унифицированного процесса – управлять разработчиками во время

UC и UCM1UC – описание того, как SS используется любым пользователем,

UC и UCM2 UCM – описание того, как SS используется в

Преимущества UCUC предлагают компромисс между системным и интуитивным способами фиксировать функциональные

Актёры и UC1 У SS обычно есть различные типы пользователейКаждый отдельный

Актёры и UC2 UC – конкретная функция, выполняемая SSВсе актёры и

Специализация и стандартизация процессовНет единого унифицированного процесса, подходящего для всех случаев

UC и итерацииЕсть много причин итераций. Реализация каждого UC является также

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

Фиксирование пользовательских требований3 В UC можно фиксировать некоторые важные нефункциональные требования,

Фиксирование пользовательских требований4Опросы пользователей не всегда позволяют установить их требования. Список

Модель UCЗадача и ее анализ, анализ специфических ситуацийUC и список актёровСхема

Спецификация1 UCЦель: формулировка цели и ожидаемых результатовАктёры: определение актёров, участвующих в

Спецификация2 UCУсловие выполнения: описание события, непосредственно инициирующего выполнение UCПостусловие: описание ситуации

Пример: UCM ATM1 Задача: создать SS для обслуживания клиента банка с

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

Пример: UCM ATM3 Актёры:Клиент банка:владелец денег. Может внести деньги в банк,

Пример: UCM ATM4 (Снятие денег), Цель: гарантировать корректную выдачу денег клиентуАктёры:

Пример: ATM UCM5 (Снятие денег),Условие выполнения: пользователь выбрал функцию меню снятия

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

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

Аналитические модели (AM)Процесс: UCM ? AM ? DMAM является промежуточной моделью,

Разработка AM1 AM системы разрабатывается поочередно анализируя UC. Это возрастающий и

Разработка AM2 На каждый класс возлагается ответственность за реализацию одного или

Разработка AM3 AM представляется в диаграммами классов, трасс и взаимодействия (сотрудничества).

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

Пример: детализированная диаграмма трасс снятия денегУстройство выдачи денегИнтерфейсвыдачи денегСнятие денег со

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

Пример: диаграмма взаимодействия снятия денегВыдача денегИнтерфейсвыдачи денегУстройство выдачи денегСнятие денег со

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

Модель проекта (DM)AM является исходной для DM, которая развивает ее дальше.

Разработка DM1 DM выражается диаграммами трасс, взаимодействия, последовательностей и подсистем. Также

Разработка DM2 Диаграмма подсистем определяет структуру SS на уровне классов и

Подсистемы DMТрудно создавать систему, состоящую из сотен классов. Они группируются в

Пример: детализированная диаграмма трассы снятия денегИнтерфейс выдачи денегУстройство выдачи денегСнятие денег

Похожие презентации

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

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

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

Модель вариантов использования (UCM)
Цель унифицированного процесса – управлять разработчиками во время

UC и UCM1
UC – описание того, как SS используется любым пользователем,

UC и UCM2
UCM – описание того, как SS используется в

Преимущества UC
UC предлагают компромисс между системным и интуитивным способами фиксировать функциональные

Актёры и UC1
У SS обычно есть различные типы пользователей
Каждый отдельный

Актёры и UC2
UC – конкретная функция, выполняемая SS
Все актёры и

Специализация и стандартизация процессов
Нет единого унифицированного процесса, подходящего для всех случаев

UC и итерации
Есть много причин итераций. Реализация каждого UC является также

Фиксирование пользовательских требований3
В UC можно фиксировать некоторые важные нефункциональные требования,

Фиксирование пользовательских требований4
Опросы пользователей не всегда позволяют установить их требования. Список

Модель UC
Задача и ее анализ, анализ специфических ситуаций
UC и список актёров
Схема

Спецификация1 UC
Цель: формулировка цели и ожидаемых результатов
Актёры: определение актёров, участвующих в

Спецификация2 UC
Условие выполнения: описание события, непосредственно инициирующего выполнение UC
Постусловие: описание ситуации

Пример: UCM ATM1
Задача: создать SS для обслуживания клиента банка с

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

Пример: UCM ATM3
Актёры:
Клиент банка:владелец денег. Может внести деньги в банк,

Пример: UCM ATM4 (Снятие денег),
Цель: гарантировать корректную выдачу денег клиенту
Актёры:

Пример: ATM UCM5 (Снятие денег),
Условие выполнения: пользователь выбрал функцию меню снятия

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

Аналитические модели (AM)
Процесс: UCM ? AM ? DM
AM является промежуточной моделью,

Разработка AM1
AM системы разрабатывается поочередно анализируя UC. Это возрастающий и

Разработка AM2
На каждый класс возлагается ответственность за реализацию одного или

Разработка AM3
AM представляется в диаграммами классов, трасс и взаимодействия (сотрудничества).

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

Пример: детализированная диаграмма трасс снятия денег
Устройство
выдачи денег
Интерфейс
выдачи денег
Снятие денег
со

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

Пример: диаграмма взаимодействия снятия денег
Выдача денег
Интерфейс
выдачи денег
Устройство
выдачи денег
Снятие денег
со

Модель проекта (DM)
AM является исходной для DM, которая развивает ее дальше.

Разработка DM1
DM выражается диаграммами трасс, взаимодействия, последовательностей и подсистем. Также

Разработка DM2
Диаграмма подсистем определяет структуру SS на уровне классов и

Подсистемы DM
Трудно создавать систему, состоящую из сотен классов. Они группируются в

Пример: детализированная диаграмма трассы снятия денег
Интерфейс
выдачи денег
Устройство
выдачи денег
Снятие денег