Бренд
<<  Требования к бренду Шины расширения  >>
ОО Анализ требований
ОО Анализ требований
Содержание лекции
Содержание лекции
Введение
Введение
Требования ОО подхода
Требования ОО подхода
Требования ОО подхода(продолжение)
Требования ОО подхода(продолжение)
Модели ОО требований
Модели ОО требований
Модели требований—Традиционный и OO
Модели требований—Традиционный и OO
Связи между моделями требований OO
Связи между моделями требований OO
Пример диаграммы вариантов использования
Пример диаграммы вариантов использования
Пример описания прецедента
Пример описания прецедента
Пример диаграммы видов деятельности (Activity Diagram)
Пример диаграммы видов деятельности (Activity Diagram)
Пример диаграммы последовательности системы
Пример диаграммы последовательности системы
The System Activities— A Use Case/Scenario View
The System Activities— A Use Case/Scenario View
Технологии, идентифицирующие варианты использования
Технологии, идентифицирующие варианты использования
Use Case Diagram
Use Case Diagram
Простая UCD
Простая UCD
UCD с границей автоматизации и двумя акторами
UCD с границей автоматизации и двумя акторами
Все прецеденты для одного актора
Все прецеденты для одного актора
UCD для order entry subsystem
UCD для order entry subsystem
Отношение <<Includes>>
Отношение <<Includes>>
Пример варианта использования Order-Entry Subsystem с<<Includes>>
Пример варианта использования Order-Entry Subsystem с<<Includes>>
CRUD –анализ для идентификации/подтверждения прецедента
CRUD –анализ для идентификации/подтверждения прецедента
Описание прецедентов
Описание прецедентов
Brief Description of Create New Order Use Case (Figure 7-7)
Brief Description of Create New Order Use Case (Figure 7-7)
Промежуточное описание сценария прецедента для Create New Order Use
Промежуточное описание сценария прецедента для Create New Order Use
Промежуточное описание сценария прецедента WEB Создание нового заказа
Промежуточное описание сценария прецедента WEB Создание нового заказа
Полное описание сценария заказа по телефону New Order Use Case
Полное описание сценария заказа по телефону New Order Use Case
Верхняя часть Полного описания прецедента
Верхняя часть Полного описания прецедента
Средняя часть Полного описания прецедента
Средняя часть Полного описания прецедента
Нижняя часть Полного описания прецедента
Нижняя часть Полного описания прецедента
Компоненты описания прецедента
Компоненты описания прецедента
Диаграммы видов деятельности
Диаграммы видов деятельности
Диаграмма видов деятельности— Сценарий заказов по телефону
Диаграмма видов деятельности— Сценарий заказов по телефону
Диаграмма видов деятельности— Сценарий Web заказа
Диаграмма видов деятельности— Сценарий Web заказа
Определение входов и выходов— Диаграмма последовательности системы
Определение входов и выходов— Диаграмма последовательности системы
Нотация System Sequence Diagram (SSD)
Нотация System Sequence Diagram (SSD)
Нотация SSD
Нотация SSD
Линия жизни SSD
Линия жизни SSD
Сообщения SSD
Сообщения SSD
Повторяемые сообщения
Повторяемые сообщения
Разработка диаграммы последовательностей системы (System Sequence)
Разработка диаграммы последовательностей системы (System Sequence)
Диаграмма видов деятельности и результирующая SSD для Заказа по
Диаграмма видов деятельности и результирующая SSD для Заказа по
SSD для Web Заказа сценария прецедента Create New Order
SSD для Web Заказа сценария прецедента Create New Order
Идентификация поведения объекта— Диаграмма состояния машины (State
Идентификация поведения объекта— Диаграмма состояния машины (State
Простая диаграмма State Machine для принтера
Простая диаграмма State Machine для принтера
Терминология Состояния Машины
Терминология Состояния Машины
Диаграмма состояний машины RMO для класса OrderItem проблемной области
Диаграмма состояний машины RMO для класса OrderItem проблемной области
Сложные состояния и параллелизм—Состояния внутри состояния
Сложные состояния и параллелизм—Состояния внутри состояния
Параллельные части для принтера в состоянии On
Параллельные части для принтера в состоянии On
Правила для разработки диаграммы состояния машины
Правила для разработки диаграммы состояния машины
Класс Order—Состояния и выходы
Класс Order—Состояния и выходы
Первоначальная диаграмма состояний машины для Order
Первоначальная диаграмма состояний машины для Order
Улучшенная диаграмма состояний машины для класса Order
Улучшенная диаграмма состояний машины для класса Order
Интегрирование ОО моделей
Интегрирование ОО моделей
Связи между OO моделями требований
Связи между OO моделями требований
Итоги
Итоги
RMO Таблица событий
RMO Таблица событий

Презентация на тему: «Анализ требований». Автор: John Satzinger. Файл: «Анализ требований.ppt». Размер zip-архива: 3958 КБ.

Анализ требований

содержание презентации «Анализ требований.ppt»
СлайдТекст
1 ОО Анализ требований

ОО Анализ требований

2 Содержание лекции

Содержание лекции

Разработка диаграммы прецедентов Описание прецедента и сценарий Разработка диаграмм видов деятельности и диаграмм последовательностей Разработка диаграмм состояния машины для моделирования поведения объектов Объяснение каким образом диаграммы UML используются совместно для определения функциональных требований для объектно-ориентированного подхода

2

3 Введение

Введение

Целью определения требований является понимание потребностей пользователя и бизнес-процессов для поддержки последних Понять и определить требования системы, используя модели ООА и технологии Граница между ООА и ООD не определена Итеративный пошаговый процесс к разработке Модели строятся на этапе анализа и улучшаются на этапе проектирования

3

4 Требования ОО подхода

Требования ОО подхода

Нотация ОО моделирования - Unified Modeling Language (UML 2.0) UML принят Object Management Group (OMG) как стандарт технологии моделирования Цели OMG Содействовать теории и практике ОО технологии для разработки распределенных систем Обеспечивать общую архитектурную систему взглядов для ОО подхода

4

5 Требования ОО подхода(продолжение)

Требования ОО подхода(продолжение)

Требования ОО системы определяются и документируются посредством построения моделей Процесс моделирования начинается с идентификации прецедентов и классов проблемной области (предметов и понятий рабочего окружения пользователей) События бизнеса запускают элементарные бизнес-процессы (BP), которые новая система должна рассматривать как варианты использования Варианты использования определяют функциональные требования

5

6 Модели ОО требований

Модели ОО требований

Use case diagrams – идентифицирует акторов и их варианты использования (цели) use case descriptions – включает подробности варианта использования и способа использования системы актором activity diagrams – описывает пользователя и виды деятельности системы для прецедента systems sequence diagrams (ssds) – определяет входы и выходы и последовательность взаимодействия между пользователем и системой для варианта использования state machine diagrams – описывает состояния для каждого объекта

6

7 Модели требований—Традиционный и OO

Модели требований—Традиционный и OO

7

8 Связи между моделями требований OO

Связи между моделями требований OO

8

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

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

9

10 Пример описания прецедента

Пример описания прецедента

10

Systems Analysis and Design in a Changing World, 4th Edition

11 Пример диаграммы видов деятельности (Activity Diagram)

Пример диаграммы видов деятельности (Activity Diagram)

11

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

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

12

13 The System Activities— A Use Case/Scenario View

The System Activities— A Use Case/Scenario View

Анализ прецедентов идентифицирует и определяет все бизнес-процессы, которые система должна поддерживать Use case – деятельность системы, выполняемая, обычно, на запрос пользователя Actor Роль, исполняемая пользователем За пределами границ автоматизации

13

14 Технологии, идентифицирующие варианты использования

Технологии, идентифицирующие варианты использования

Идентификация целей пользователя Каждая цель- уровень элементарного бизнес-процесса (EBP) является вариантом использования EBP – задача, выполняемая одним пользователем в одном месте и в ответ на событие бизнеса, которая добавляет измеряемой ценности бизнесу и покидает систему и данные в согласованном состоянии Технология на декомпозиции событий (таблица событий) Технология CRUD – анализа (create, read/report, update, delete) для обеспечения границ

14

15 Use Case Diagram

Use Case Diagram

Графическая диаграмма UML, которая обобщает информацию об акторах и прецедентах Простая диаграмма показывает обзор функциональных требований Может иметь несколько use case diagrams (UCD) По подсистемам По акторам

15

16 Простая UCD

Простая UCD

16

17 UCD с границей автоматизации и двумя акторами

UCD с границей автоматизации и двумя акторами

17

18 Все прецеденты для одного актора

Все прецеденты для одного актора

18

19 UCD для order entry subsystem

UCD для order entry subsystem

19

20 Отношение <<Includes>>

Отношение <<Includes>>

Документирует ситуации, в которых один прецедент требует обслуживания общей программы Другой прецедент разрабатывается для этой общей программы Общий прецедент может использоваться несколькими прецедентами

20

21 Пример варианта использования Order-Entry Subsystem с<<Includes>>

Пример варианта использования Order-Entry Subsystem с<<Includes>>

21

22 CRUD –анализ для идентификации/подтверждения прецедента

CRUD –анализ для идентификации/подтверждения прецедента

CRUD – create, read/report, update, delete Технология Information Engineering (IE) для идентификации таблицы событий или непосредственной разработки диаграммы прецедентов Сравнивает идентифицированные варианты использования с диаграммой классов предметной области Каждый класс в диаграмме классов должен использовать прецеденты для поддержки создания, чтения, изменения, удаления и формирования отчетов экземпляров объектов Подтверждает требования интеграции системы

22

23 Описание прецедентов

Описание прецедентов

Use case description обеспечивает подробные предварительные условия, постусловия, последовательность действий и исключительных ситуаций в прецеденте Описывает пошаговое взаимодействие actor с компьютерной системой в процессе выполнения бизнес-процедур Может иметь несколько сценариев для прецедента, каждый из которых является экземпляром прецедента Три уровня детальности: краткое, промежуточное и полное разработанное описание Многие аналитики предпочитают делать текстовое описание прецедента вместо рисования диаграмм видов деятельности

23

24 Brief Description of Create New Order Use Case (Figure 7-7)

Brief Description of Create New Order Use Case (Figure 7-7)

Описание прецедента Создание нового заказа Когда клиент запрашивает заказ, менеджер по работе с клиентами и система проверяют информацию о клиенте, создают новый заказ, добавляют строки мпецификации заказа, проверяют оплату, создают транзакцию заказа и завершают Заказ

24

25 Промежуточное описание сценария прецедента для Create New Order Use

Промежуточное описание сценария прецедента для Create New Order Use

Case

Поток действий для сценария Менеджер создает заказ по телефону Главный поток Клиент звонит в фирму и запрашивает заказ у менеджера Менеджер проверяет информацию о клиенте. Если новый клиент, вызывает прецедент Поддержка учетной информации о клиенте, чтобы добавить нового клиента Менеджер начинает создание нового заказа Клиент запрашивает Менеджера о включении продукции в заказ Менеджер проверяет продукцию и добавляет в заказ Шаги 4-5 повторяются до окончания требуемой продукции Клиент сообщает об окончании заказа; Менеджер вводит окончание заказа; система вычисляет сумму. Клиент представляет оплату; менеджер вводит сумму; система проверяет оплату Система закрывает заказ Исключительные условия Если продукции нет на складе, то клиент может Отказаться от продукции Запросить отложенную поставку Если оплата не выполнена, то Заказ отклоняется Заказ задерживается до выполнения оплаты

25

26 Промежуточное описание сценария прецедента WEB Создание нового заказа

Промежуточное описание сценария прецедента WEB Создание нового заказа

Промежуточное описание Поток действий для сценария Менеджер создает WEB- заказ Главный поток Клиент соединяется с WEB-страницей и затем выходит на страницу заказов Если клиент новый, клиент переходит на страницу учетных записей и добавляет соответствующую информацию для клиента. Если клиент существует – вход в систему Система начинает новый заказ и показывает структуру каталога Клиент просматривает каталог Когда клиент находит подходящий товар, он включает его в заказ; система добавляет его в заказ Заказчик повторяет шаги 5-6 Клиент сигнализирует об окончании формирования заказа; система показывает итоги заказа Клиент выполняет любые изменения Клиент запрашивает экран оплаты; система показывает экран оплаты. Клиент вводит информацию по оплате; система показывает суммарную информацию и посылает e-mail подтверждения Система завершает заказ Исключительные условия Если существующий клиент забыл пароль, то Клиент может вызвать обработку забытого пароля Клиент может создать новую учетную запись Если клиент отклонен из-за проверки кредитных обстоятельств, то Клиент может снять заказ или Заказ задерживается до выполнения оплаты

26

27 Полное описание сценария заказа по телефону New Order Use Case

Полное описание сценария заказа по телефону New Order Use Case

27

28 Верхняя часть Полного описания прецедента

Верхняя часть Полного описания прецедента

28

29 Средняя часть Полного описания прецедента

Средняя часть Полного описания прецедента

29

30 Нижняя часть Полного описания прецедента

Нижняя часть Полного описания прецедента

30

31 Компоненты описания прецедента

Компоненты описания прецедента

Имя прецедента/Имя сценария Акторы/вовлеченные лица(системы) Связанные прецеденты Предварительные условия– набор критериев, которые должны выполнены перед началом прецедента Выходные условия– набор критериев, которые должны выполнены после выполнения прецедента Виды деятельности (шаги в одну или две колонки) Исключительные условия

31

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

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

Документирует последовательность выполнения бизнес-операций для каждого прецедента или сценария Standard UML 2.0 diagram Может поддерживать любой уровень описания прецедентов; для дополнительного использования в описании прецедента Полезно при разработке диаграмм последовательностей системы

32

33 Диаграмма видов деятельности— Сценарий заказов по телефону

Диаграмма видов деятельности— Сценарий заказов по телефону

33

34 Диаграмма видов деятельности— Сценарий Web заказа

Диаграмма видов деятельности— Сценарий Web заказа

34

35 Определение входов и выходов— Диаграмма последовательности системы

Определение входов и выходов— Диаграмма последовательности системы

Диаграмма последовательности системы - System sequence diagram (SSD) разновидность взаимодействия UML 2.0 Обычно моделирует требования сообщений по входу и по выходу для прецедента или сценария Показывает акторов, взаимодействующих с системой Показывает последовательность взаимодействий как сообщений в процессе выполнения потоков операций Система показывается как один объект : черный ящик (“black box”)

35

36 Нотация System Sequence Diagram (SSD)

Нотация System Sequence Diagram (SSD)

36

37 Нотация SSD

Нотация SSD

Актор (Actor) представляется как фигура из линий– человек (роль), который взаимодействует с системой вводя входные данные и получая выходные данные Объект (Object) – прямоугольник с подчеркнутым именем объекта– показывает индивидуальный объект, а не класс похожих ( :System для SSD ) Линия жизни (Lifeline) - вертикальная линия под объектом или актором для представления течения времени для объекта Сообщение (Message) помеченная стрелка для показа посланных системе сообщений или полученных актором из системы

37

38 Линия жизни SSD

Линия жизни SSD

Вертикальная линия под объектом или актором Показывает течение времени Если вертикальная линия прерывистая Создание и уничтожение предметов не является важным для сценария Длинные узкие прямоугольники На линии жизни показывает, что объект активный только во время части сценария

38

39 Сообщения SSD

Сообщения SSD

Внутренние события , идентифицируемые потоком объектов в сценарии Запросы от одного актора или объекта другому выполнть некоторые действия Вызов определенного метода

39

40 Повторяемые сообщения

Повторяемые сообщения

40

41 Разработка диаграммы последовательностей системы (System Sequence)

Разработка диаграммы последовательностей системы (System Sequence)

Начинается с подробного описания прецедента для полностью разработанных диаграмм форм и видов деятельности Идентифицирует входные сообщения Описывает сообщения от внешнего актора системе, используя нотацию сообщений Идентифицирует и добавляет любые условия на входные сообщения, включая итерации и условия true/false Идентифицирует и добавляет выходные возвращаемые сообщения

41

42 Диаграмма видов деятельности и результирующая SSD для Заказа по

Диаграмма видов деятельности и результирующая SSD для Заказа по

телефону

42

43 SSD для Web Заказа сценария прецедента Create New Order

SSD для Web Заказа сценария прецедента Create New Order

43

44 Идентификация поведения объекта— Диаграмма состояния машины (State

Идентификация поведения объекта— Диаграмма состояния машины (State

Machine Diagram)

State machine diagram – диаграмма UML 2.0 которая моделирует состояния объектов и переходов Должны моделироваться классы сложных проблемных областей Состояние объекта Условие, которое совершается во время его жизненного цикла, когда оно удовлетворяет некоторым критериям, выполняет некоторые действия или ожидает события Каждое состояние имеет уникальное имя и почти неизменное условие или состояние Переход Перемещение объекта из одного состояния в другое состояние

44

45 Простая диаграмма State Machine для принтера

Простая диаграмма State Machine для принтера

45

46 Терминология Состояния Машины

Терминология Состояния Машины

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

46

47 Диаграмма состояний машины RMO для класса OrderItem проблемной области

Диаграмма состояний машины RMO для класса OrderItem проблемной области

47

48 Сложные состояния и параллелизм—Состояния внутри состояния

Сложные состояния и параллелизм—Состояния внутри состояния

Пример сложного состояния для объекта принтер

48

49 Параллельные части для принтера в состоянии On

Параллельные части для принтера в состоянии On

49

50 Правила для разработки диаграммы состояния машины

Правила для разработки диаграммы состояния машины

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

50

51 Класс Order—Состояния и выходы

Класс Order—Состояния и выходы

51

52 Первоначальная диаграмма состояний машины для Order

Первоначальная диаграмма состояний машины для Order

52

53 Улучшенная диаграмма состояний машины для класса Order

Улучшенная диаграмма состояний машины для класса Order

53

54 Интегрирование ОО моделей

Интегрирование ОО моделей

Полная 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

55 Связи между OO моделями требований

Связи между OO моделями требований

55

56 Итоги

Итоги

ОО подход имеет полный набор диаграмм, которые определяют требования Требования определяются с использованием следующих моделей Диаграмма классов модели предметной области Диаграмма вариантов использования Подробные модели прецедентов, либо в описательном формате либо диаграммах видов деятельности Диаграммы последовательности системы Диаграммы состояния машины

56

57 RMO Таблица событий

RMO Таблица событий

Многократные ответы!

57

«Анализ требований»
http://900igr.net/prezentacija/ekonomika/analiz-trebovanij-106405.html
cсылка на страницу

Бренд

8 презентаций о бренде
Урок

Экономика

125 тем
Слайды