Transcript OO-analysis

ОО АНАЛИЗ ТРЕБОВАНИЙ
СОДЕРЖАНИЕ ЛЕКЦИИ
Разработка диаграммы прецедентов
 Описание прецедента и сценарий
 Разработка диаграмм видов деятельности и
диаграмм последовательностей
 Разработка диаграмм состояния машины для
моделирования поведения объектов
 Объяснение каким образом диаграммы UML
используются совместно для определения
функциональных требований для объектноориентированного подхода

2
ВВЕДЕНИЕ
Целью определения требований является понимание
потребностей пользователя и бизнес-процессов для
поддержки последних
 Понять и определить требования системы, используя
модели ООА и технологии
 Граница между ООА и ООD не определена



Итеративный пошаговый процесс к разработке
Модели строятся на этапе анализа и улучшаются на этапе
проектирования
3
ТРЕБОВАНИЯ ОО ПОДХОДА



Нотация ОО моделирования - Unified Modeling
Language (UML 2.0)
UML принят Object Management Group (OMG) как
стандарт технологии моделирования
Цели OMG

Содействовать теории и практике ОО технологии для
разработки распределенных систем

Обеспечивать общую архитектурную систему взглядов
для ОО подхода
4
ТРЕБОВАНИЯ ОО ПОДХОДА(ПРОДОЛЖЕНИЕ)




Требования ОО системы определяются и
документируются посредством построения моделей
Процесс моделирования начинается с
идентификации прецедентов и классов проблемной
области (предметов и понятий рабочего окружения
пользователей)
События бизнеса запускают элементарные бизнеспроцессы (BP), которые новая система должна
рассматривать как варианты использования
Варианты использования определяют
функциональные требования
5
МОДЕЛИ ОО ТРЕБОВАНИЙ
Use case diagrams – идентифицирует акторов и их
варианты использования (цели)
 Use case descriptions – включает подробности
варианта использования и способа использования
системы актором
 Activity diagrams – описывает пользователя и виды
деятельности системы для прецедента
 Systems sequence diagrams (SSDs) – определяет
входы и выходы и последовательность
взаимодействия между пользователем и системой
для варианта использования
 State machine diagrams – описывает состояния для
каждого объекта

6
МОДЕЛИ ТРЕБОВАНИЙ—ТРАДИЦИОННЫЙ И OO
7
СВЯЗИ МЕЖДУ МОДЕЛЯМИ ТРЕБОВАНИЙ OO
8
ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ
9
ПРИМЕР ОПИСАНИЯ ПРЕЦЕДЕНТА
Systems Analysis and Design in a Changing
World, 4th Edition
10
ПРИМЕР
ДИАГРАММЫ
ВИДОВ
ДЕЯТЕЛЬНОСТИ
(ACTIVITY
DIAGRAM)
11
ПРИМЕР ДИАГРАММЫ
ПОСЛЕДОВАТЕЛЬНОСТИ
СИСТЕМЫ
12
THE SYSTEM ACTIVITIES—
A USE CASE/SCENARIO VIEW



Анализ прецедентов идентифицирует и определяет
все бизнес-процессы, которые система должна
поддерживать
Use case – деятельность системы, выполняемая,
обычно, на запрос пользователя
Actor

Роль, исполняемая пользователем

За пределами границ автоматизации
13
ТЕХНОЛОГИИ, ИДЕНТИФИЦИРУЮЩИЕ
ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ



Идентификация целей пользователя

Каждая цель- уровень элементарного бизнеспроцесса (EBP) является вариантом
использования

EBP – задача, выполняемая одним
пользователем в одном месте и в ответ на
событие бизнеса, которая добавляет измеряемой
ценности бизнесу и покидает систему и данные в
согласованном состоянии
Технология на декомпозиции событий (таблица
событий)
Технология CRUD – анализа (create, read/report,
update, delete) для обеспечения границ
14
USE CASE DIAGRAM



Графическая диаграмма UML, которая обобщает
информацию об акторах и прецедентах
Простая диаграмма показывает обзор
функциональных требований
Может иметь несколько use case diagrams (UCD)

По подсистемам

По акторам
15
ПРОСТАЯ UCD
16
UCD С ГРАНИЦЕЙ АВТОМАТИЗАЦИИ
И ДВУМЯ АКТОРАМИ
17
ВСЕ ПРЕЦЕДЕНТЫ ДЛЯ ОДНОГО АКТОРА
18
UCD ДЛЯ ORDER ENTRY SUBSYSTEM
19
ОТНОШЕНИЕ <<INCLUDES>>



Документирует ситуации, в которых один прецедент
требует обслуживания общей программы
Другой прецедент разрабатывается для этой общей
программы
Общий прецедент может использоваться
несколькими прецедентами
20
ПРИМЕР ВАРИАНТА ИСПОЛЬЗОВАНИЯ ORDERENTRY SUBSYSTEM С<<INCLUDES>>
21
CRUD –АНАЛИЗ ДЛЯ
ИДЕНТИФИКАЦИИ/ПОДТВЕРЖДЕНИЯ
ПРЕЦЕДЕНТА
CRUD – create, read/report, update, delete
 Технология Information Engineering (IE) для
идентификации таблицы событий или
непосредственной разработки диаграммы
прецедентов
 Сравнивает идентифицированные варианты
использования с диаграммой классов
предметной области
 Каждый класс в диаграмме классов должен
использовать прецеденты для поддержки
создания, чтения, изменения, удаления и
формирования отчетов экземпляров объектов
 Подтверждает требования интеграции системы

22
ОПИСАНИЕ ПРЕЦЕДЕНТОВ





Use case description обеспечивает подробные
предварительные условия, постусловия,
последовательность действий и исключительных
ситуаций в прецеденте
Описывает пошаговое взаимодействие actor с
компьютерной системой в процессе выполнения
бизнес-процедур
Может иметь несколько сценариев для прецедента,
каждый из которых является экземпляром
прецедента
Три уровня детальности: краткое, промежуточное и
полное разработанное описание
Многие аналитики предпочитают делать
текстовое описание прецедента вместо
рисования диаграмм видов деятельности
23
BRIEF DESCRIPTION OF CREATE NEW ORDER
USE CASE (FIGURE 7-7)
Описание прецедента Создание нового заказа
Когда клиент запрашивает заказ, менеджер по
работе с клиентами и система проверяют
информацию о клиенте, создают новый заказ,
добавляют строки мпецификации заказа,
проверяют оплату, создают транзакцию заказа и
завершают Заказ
24
ПРОМЕЖУТОЧНОЕ ОПИСАНИЕ СЦЕНАРИЯ ПРЕЦЕДЕНТА
ДЛЯдействий
CREATE
EW ORDER
USEсоздает
CASEзаказ по телефону
Поток
дляN
сценария
Менеджер
Главный поток
1. Клиент звонит в фирму и запрашивает заказ у менеджера
2. Менеджер проверяет информацию о клиенте. Если новый клиент,
вызывает прецедент Поддержка учетной информации о клиенте, чтобы
добавить нового клиента
3. Менеджер начинает создание нового заказа
4. Клиент запрашивает Менеджера о включении продукции в заказ
5. Менеджер проверяет продукцию и добавляет в заказ
6. Шаги 4-5 повторяются до окончания требуемой продукции
7. Клиент сообщает об окончании заказа; Менеджер вводит окончание
заказа; система вычисляет сумму.
8. Клиент представляет оплату; менеджер вводит сумму; система проверяет
оплату
9. Система закрывает заказ
Исключительные условия
1. Если продукции нет на складе, то клиент может
a. Отказаться от продукции
b. Запросить отложенную поставку
2. Если оплата не выполнена, то
25
a. Заказ отклоняется
b. Заказ задерживается до выполнения оплаты
ПРОМЕЖУТОЧНОЕ ОПИСАНИЕ СЦЕНАРИЯ ПРЕЦЕДЕНТА
WEB СОЗДАНИЕ НОВОГО ЗАКАЗА
Промежуточное описание
Поток действий для сценария Менеджер создает WEB- заказ
Главный поток
1. Клиент соединяется с WEB-страницей и затем выходит на страницу заказов
2. Если клиент новый, клиент переходит на страницу учетных записей и добавляет
соответствующую информацию для клиента.
3. Если клиент существует – вход в систему
4. Система начинает новый заказ и показывает структуру каталога
5. Клиент просматривает каталог
6. Когда клиент находит подходящий товар, он включает его в заказ; система
добавляет его в заказ
7. Заказчик повторяет шаги 5-6
8. Клиент сигнализирует об окончании формирования заказа; система показывает
итоги заказа
9. Клиент выполняет любые изменения
10. Клиент запрашивает экран оплаты; система показывает экран оплаты.
11. Клиент вводит информацию по оплате; система показывает суммарную
информацию и посылает e-mail подтверждения
12. Система завершает заказ
Исключительные условия
1. Если существующий клиент забыл пароль, то
a. Клиент может вызвать обработку забытого пароля
26
b. Клиент может создать новую учетную запись
2. Если клиент отклонен из-за проверки кредитных обстоятельств, то
a. Клиент может снять заказ или
ПОЛНОЕ
ОПИСАНИЕ
СЦЕНАРИЯ
ЗАКАЗА ПО
ТЕЛЕФОНУ
NEW
ORDER USE
CASE
27
ВЕРХНЯЯ ЧАСТЬ ПОЛНОГО ОПИСАНИЯ
ПРЕЦЕДЕНТА
28
СРЕДНЯЯ ЧАСТЬ ПОЛНОГО ОПИСАНИЯ
ПРЕЦЕДЕНТА
29
НИЖНЯЯ ЧАСТЬ ПОЛНОГО ОПИСАНИЯ
ПРЕЦЕДЕНТА
30
КОМПОНЕНТЫ ОПИСАНИЯ ПРЕЦЕДЕНТА
Имя прецедента/Имя сценария
 Акторы/вовлеченные лица(системы)
 Связанные прецеденты
 Предварительные условия– набор критериев,
которые должны выполнены перед началом
прецедента
 Выходные условия– набор критериев, которые
должны выполнены после выполнения
прецедента
 Виды деятельности (шаги в одну или две
колонки)
 Исключительные условия

31
ДИАГРАММЫ ВИДОВ ДЕЯТЕЛЬНОСТИ




Документирует последовательность выполнения
бизнес-операций для каждого прецедента или
сценария
Standard UML 2.0 diagram
Может поддерживать любой уровень описания
прецедентов; для дополнительного использования в
описании прецедента
Полезно при разработке диаграмм
последовательностей системы
32
ДИАГРАММА
ВИДОВ
ДЕЯТЕЛЬНОСТИ
— СЦЕНАРИЙ
ЗАКАЗОВ ПО
ТЕЛЕФОНУ
33
ДИАГРАММА
ВИДОВ
ДЕЯТЕЛЬНОСТИ
—
СЦЕНАРИЙ WEB
ЗАКАЗА
34
ОПРЕДЕЛЕНИЕ ВХОДОВ И ВЫХОДОВ—
ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТИ СИСТЕМЫ
Диаграмма последовательности системы System sequence diagram (SSD) разновидность
взаимодействия UML 2.0
 Обычно моделирует требования сообщений по
входу и по выходу для прецедента или
сценария
 Показывает акторов, взаимодействующих с
системой
 Показывает последовательность
взаимодействий как сообщений в процессе
выполнения потоков операций
 Система показывается как один объект :
черный ящик (“black box”)

35
Нотация System Sequence Diagram
(SSD)
36
НОТАЦИЯ SSD
Актор (Actor) представляется как фигура из
линий– человек (роль), который
взаимодействует с системой вводя входные
данные и получая выходные данные
 Объект (Object) – прямоугольник с
подчеркнутым именем объекта– показывает
индивидуальный объект, а не класс похожих (
:System для SSD )
 Линия жизни (Lifeline) - вертикальная линия
под объектом или актором для представления
течения времени для объекта
 Сообщение (Message) помеченная стрелка для
показа посланных системе сообщений или
полученных актором из системы

37
ЛИНИЯ ЖИЗНИ SSD

Вертикальная линия под объектом или актором


Если вертикальная линия прерывистая


Показывает течение времени
Создание и уничтожение предметов не является
важным для сценария
Длинные узкие прямоугольники

На линии жизни показывает, что объект активный
только во время части сценария
38
СООБЩЕНИЯ SSD



Внутренние события , идентифицируемые потоком
объектов в сценарии
Запросы от одного актора или объекта другому
выполнть некоторые действия
Вызов определенного метода
39
ПОВТОРЯЕМЫЕ
СООБЩЕНИЯ
40
РАЗРАБОТКА ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТЕЙ
СИСТЕМЫ (SYSTEM SEQUENCE)
Начинается с подробного описания прецедента для
полностью разработанных диаграмм форм и видов
деятельности
 Идентифицирует входные сообщения
 Описывает сообщения от внешнего актора системе,
используя нотацию сообщений
 Идентифицирует и добавляет любые условия на
входные сообщения, включая итерации и условия
true/false
 Идентифицирует и добавляет выходные
возвращаемые сообщения

41
ДИАГРАММА ВИДОВ ДЕЯТЕЛЬНОСТИ И
РЕЗУЛЬТИРУЮЩАЯ SSD ДЛЯ ЗАКАЗА ПО ТЕЛЕФОНУ
42
SSD ДЛЯ WEB
ЗАКАЗА
СЦЕНАРИЯ
ПРЕЦЕДЕНТА
CREATE NEW
ORDER
43
ИДЕНТИФИКАЦИЯ ПОВЕДЕНИЯ ОБЪЕКТА—
ДИАГРАММА СОСТОЯНИЯ МАШИНЫ
(STATE MACHINE DIAGRAM)

State machine diagram – диаграмма UML 2.0
которая моделирует состояния объектов и
переходов


Состояние объекта



Должны моделироваться классы сложных
проблемных областей
Условие, которое совершается во время его
жизненного цикла, когда оно удовлетворяет
некоторым критериям, выполняет некоторые
действия или ожидает события
Каждое состояние имеет уникальное имя и почти
неизменное условие или состояние
Переход

Перемещение объекта из одного состояния в другое
состояние
44
ПРОСТАЯ ДИАГРАММА STATE MACHINE ДЛЯ
ПРИНТЕРА
45
ТЕРМИНОЛОГИЯ СОСТОЯНИЯ МАШИНЫ
Псевдо состояние– начальная точка состояния
машины, отображается закрашенной точкой
 Исходное состояние– исходное состояние объекта из
которого происходит переход
 Конечное состояние – состояние, в которое объект
перемещается после выполнения перехода
 Событие сообщения – инициатор для перехода,
которое вызывает объект покинуть начальное
состояние
 Ограждающие условия – проверка истинности может
ли переход осуществиться
 Выражение действия – описания действия,
выполняемого как часть перехода

46
ДИАГРАММА СОСТОЯНИЙ МАШИНЫ RMO ДЛЯ
КЛАССА ORDERITEM ПРОБЛЕМНОЙ ОБЛАСТИ
47
СЛОЖНЫЕ СОСТОЯНИЯ И ПАРАЛЛЕЛИЗМ—
СОСТОЯНИЯ ВНУТРИ СОСТОЯНИЯ
Пример сложного
состояния для объекта
принтер
48
ПАРАЛЛЕЛЬНЫЕ ЧАСТИ ДЛЯ ПРИНТЕРА В
СОСТОЯНИИ ON
49
ПРАВИЛА ДЛЯ РАЗРАБОТКИ ДИАГРАММЫ
СОСТОЯНИЯ МАШИНЫ





Обзор диаграмм классов предметной области и
выбрать важные классы и перечислить все
состояния и условия выхода
Построение диаграммы состояний машины
начинается с фрагментов для каждого класса
Фрагменты последовательности в правильном
порядке рассматриваются на предмет выполнения
независимых и параллельных путей
Каждый переход расширяется событием,
ограждающим условием и выражением действия
Пересмотрите и проверьте каждую диаграмму
состояний машины
50
КЛАСС ORDER—СОСТОЯНИЯ И ВЫХОДЫ
51
ПЕРВОНАЧАЛЬНАЯ ДИАГРАММА
СОСТОЯНИЙ МАШИНЫ ДЛЯ ORDER
52
УЛУЧШЕННАЯ ДИАГРАММА СОСТОЯНИЙ МАШИНЫ
ДЛЯ КЛАССА ORDER
53
ИНТЕГРИРОВАНИЕ ОО МОДЕЛЕЙ
Полная Complete use case diagram is needed to
understand total scope of new system
 Domain model class diagrams should also be as
complete as possible for entire system
 With iterative approach, only construct use case
descriptions, activity diagrams, and system sequence
diagrams for use cases in iteration
 Development of a new diagram often helps refine and
correct previous diagrams

54
СВЯЗИ МЕЖДУ OO МОДЕЛЯМИ ТРЕБОВАНИЙ
55
ИТОГИ
ОО подход имеет полный набор диаграмм,
которые определяют требования
 Требования определяются с использованием
следующих моделей






Диаграмма классов модели предметной области
Диаграмма вариантов использования
Подробные модели прецедентов, либо в
описательном формате либо диаграммах видов
деятельности
Диаграммы последовательности системы
Диаграммы состояния машины
56
RMO ТАБЛИЦА СОБЫТИЙ
Многократные
ответы!
57