ОО А НАЛИЗ ТРЕБОВАНИЙ

С ОДЕРЖАНИЕ ЛЕКЦИИ Разработка диаграммы прецедентов Описание прецедента и сценарий Разработка диаграмм видов деятельности и диаграмм последовательностей Разработка диаграмм состояния машины для моделирования поведения объектов Объяснение каким образом диаграммы 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

П РИМЕР ДИАГРАММЫ ВИДОВ ДЕЯТЕЛЬНОСТИ (A CTIVITY D IAGRAM ) 11

П РИМЕР ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ СИСТЕМЫ 12

T HE S YSTEM A CTIVITIES A U SE C ASE /S CENARIO V IEW Анализ прецедентов идентифицирует и определяет все бизнес-процессы, которые система должна поддерживать Use case – деятельность системы, выполняемая, обычно, на запрос пользователя Actor Роль, исполняемая пользователем За пределами границ автоматизации 13

Т ЕХНОЛОГИИ, ИДЕНТИФИЦИРУЮЩИЕ ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ Идентификация целей пользователя Каждая цель- уровень элементарного бизнес- процесса (EBP) является вариантом использования EBP – задача, выполняемая одним пользователем в одном месте и в ответ на событие бизнеса, которая добавляет измеряемой ценности бизнесу и покидает систему и данные в согласованном состоянии Технология на декомпозиции событий (таблица событий) Технология CRUD – анализа (create, read/report, update, delete) для обеспечения границ 14

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

П РОСТАЯ UCD 16

UCD С ГРАНИЦЕЙ АВТОМАТИЗАЦИИ И ДВУМЯ АКТОРАМИ 17

В СЕ ПРЕЦЕДЕНТЫ ДЛЯ ОДНОГО АКТОРА 18

UCD ДЛЯ O RDER E NTRY S UBSYSTEM 19

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

П РИМЕР ВАРИАНТА ИСПОЛЬЗОВАНИЯ O RDER - E NTRY S UBSYSTEM С > 21

CRUD – АНАЛИЗ ДЛЯ ИДЕНТИФИКАЦИИ / ПОДТВЕРЖДЕНИЯ ПРЕЦЕДЕНТА CRUD – create, read/report, update, delete Технология Information Engineering (IE) для идентификации таблицы событий или непосредственной разработки диаграммы прецедентов Сравнивает идентифицированные варианты использования с диаграммой классов предметной области Каждый класс в диаграмме классов должен использовать прецеденты для поддержки создания, чтения, изменения, удаления и формирования отчетов экземпляров объектов Подтверждает требования интеграции системы 22

О ПИСАНИЕ ПРЕЦЕДЕНТОВ Use case description обеспечивает подробные предварительные условия, постусловия, последовательность действий и исключительных ситуаций в прецеденте Описывает пошаговое взаимодействие actor с компьютерной системой в процессе выполнения бизнес-процедур Может иметь несколько сценариев для прецедента, каждый из которых является экземпляром прецедента Три уровня детальности: краткое, промежуточное и полное разработанное описание Многие аналитики предпочитают делать текстовое описание прецедента вместо рисования диаграмм видов деятельности 23

B RIEF D ESCRIPTION OF C REATE N EW O RDER U SE C ASE (F IGURE 7-7) 24 Описание прецедента Создание нового заказа Когда клиент запрашивает заказ, менеджер по работе с клиентами и система проверяют информацию о клиенте, создают новый заказ, добавляют строки мпецификации заказа, проверяют оплату, создают транзакцию заказа и завершают Заказ

П РОМЕЖУТОЧНОЕ ОПИСАНИЕ СЦЕНАРИЯ ПРЕЦЕДЕНТА ДЛЯ C REATE N EW O RDER U SE C ASE 25 Поток действий для сценария Менеджер создает заказ по телефону Главный поток 1.Клиент звонит в фирму и запрашивает заказ у менеджера 2.Менеджер проверяет информацию о клиенте. Если новый клиент, вызывает прецедент Поддержка учетной информации о клиенте, чтобы добавить нового клиента 3.Менеджер начинает создание нового заказа 4.Клиент запрашивает Менеджера о включении продукции в заказ 5.Менеджер проверяет продукцию и добавляет в заказ 6.Шаги 4-5 повторяются до окончания требуемой продукции 7.Клиент сообщает об окончании заказа; Менеджер вводит окончание заказа; система вычисляет сумму. 8.Клиент представляет оплату; менеджер вводит сумму; система проверяет оплату 9.Система закрывает заказ Исключительные условия 1.Если продукции нет на складе, то клиент может a.Отказаться от продукции b.Запросить отложенную поставку 2.Если оплата не выполнена, то a.Заказ отклоняется b.Заказ задерживается до выполнения оплаты

П РОМЕЖУТОЧНОЕ ОПИСАНИЕ СЦЕНАРИЯ ПРЕЦЕДЕНТА WEB С ОЗДАНИЕ НОВОГО ЗАКАЗА 26 Промежуточное описание Поток действий для сценария Менеджер создает WEB- заказ Главный поток 1.Клиент соединяется с WEB-страницей и затем выходит на страницу заказов 2.Если клиент новый, клиент переходит на страницу учетных записей и добавляет соответствующую информацию для клиента. 3.Если клиент существует – вход в систему 4.Система начинает новый заказ и показывает структуру каталога 5.Клиент просматривает каталог 6.Когда клиент находит подходящий товар, он включает его в заказ; система добавляет его в заказ 7.Заказчик повторяет шаги Клиент сигнализирует об окончании формирования заказа; система показывает итоги заказа 9.Клиент выполняет любые изменения 10.Клиент запрашивает экран оплаты; система показывает экран оплаты. 11.Клиент вводит информацию по оплате; система показывает суммарную информацию и посылает подтверждения 12.Система завершает заказ Исключительные условия 1.Если существующий клиент забыл пароль, то a.Клиент может вызвать обработку забытого пароля b.Клиент может создать новую учетную запись 2.Если клиент отклонен из-за проверки кредитных обстоятельств, то a.Клиент может снять заказ или b.Заказ задерживается до выполнения оплаты

П ОЛНОЕ ОПИСАНИЕ СЦЕНАРИЯ ЗАКАЗА ПО ТЕЛЕФОНУ N EW O RDER U SE C ASE 27

В ЕРХНЯЯ ЧАСТЬ П ОЛНОГО ОПИСАНИЯ ПРЕЦЕДЕНТА 28

С РЕДНЯЯ ЧАСТЬ П ОЛНОГО ОПИСАНИЯ ПРЕЦЕДЕНТА 29

Н ИЖНЯЯ ЧАСТЬ П ОЛНОГО ОПИСАНИЯ ПРЕЦЕДЕНТА 30

К ОМПОНЕНТЫ ОПИСАНИЯ ПРЕЦЕДЕНТА Имя прецедента/Имя сценария Акторы/вовлеченные лица(системы) Связанные прецеденты Предварительные условия– набор критериев, которые должны выполнены перед началом прецедента Выходные условия– набор критериев, которые должны выполнены после выполнения прецедента Виды деятельности (шаги в одну или две колонки) Исключительные условия 31

Д ИАГРАММЫ ВИДОВ ДЕЯТЕЛЬНОСТИ Документирует последовательность выполнения бизнес-операций для каждого прецедента или сценария Standard UML 2.0 diagram Может поддерживать любой уровень описания прецедентов; для дополнительного использования в описании прецедента Полезно при разработке диаграмм последовательностей системы 32

Д ИАГРАММА ВИДОВ ДЕЯТЕЛЬНОСТИ С ЦЕНАРИЙ ЗАКАЗОВ ПО ТЕЛЕФОНУ 33

Д ИАГРАММА ВИДОВ ДЕЯТЕЛЬНОСТИ С ЦЕНАРИЙ W EB ЗАКАЗА 34

О ПРЕДЕЛЕНИЕ ВХОДОВ И ВЫХОДОВ Д ИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТИ СИСТЕМЫ Диаграмма последовательности системы - System sequence diagram (SSD) разновидность взаимодействия UML 2.0 Обычно моделирует требования сообщений по входу и по выходу для прецедента или сценария Показывает акторов, взаимодействующих с системой Показывает последовательность взаимодействий как сообщений в процессе выполнения потоков операций Система показывается как один объект : черный ящик (black box) 35

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

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

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

С ООБЩЕНИЯ SSD Внутренние события, идентифицируемые потоком объектов в сценарии Запросы от одного актора или объекта другому выполнть некоторые действия Вызов определенного метода 39

П ОВТОРЯЕМЫЕ СООБЩЕНИЯ 40

Р АЗРАБОТКА ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТЕЙ СИСТЕМЫ (S YSTEM S EQUENCE ) Начинается с подробного описания прецедента для полностью разработанных диаграмм форм и видов деятельности Идентифицирует входные сообщения Описывает сообщения от внешнего актора системе, используя нотацию сообщений Идентифицирует и добавляет любые условия на входные сообщения, включая итерации и условия true/false Идентифицирует и добавляет выходные возвращаемые сообщения 41

Д ИАГРАММА ВИДОВ ДЕЯТЕЛЬНОСТИ И РЕЗУЛЬТИРУЮЩАЯ SSD ДЛЯ З АКАЗА ПО ТЕЛЕФОНУ 42

SSD ДЛЯ W EB З АКАЗА СЦЕНАРИЯ ПРЕЦЕДЕНТА C REATE N EW O RDER 43

И ДЕНТИФИКАЦИЯ ПОВЕДЕНИЯ ОБЪЕКТА Д ИАГРАММА СОСТОЯНИЯ МАШИНЫ (S TATE M ACHINE D IAGRAM ) State machine diagram – диаграмма UML 2.0 которая моделирует состояния объектов и переходов Должны моделироваться классы сложных проблемных областей Состояние объекта Условие, которое совершается во время его жизненного цикла, когда оно удовлетворяет некоторым критериям, выполняет некоторые действия или ожидает события Каждое состояние имеет уникальное имя и почти неизменное условие или состояние Переход Перемещение объекта из одного состояния в другое состояние 44

П РОСТАЯ ДИАГРАММА S TATE M ACHINE ДЛЯ ПРИНТЕРА 45

Т ЕРМИНОЛОГИЯ С ОСТОЯНИЯ М АШИНЫ Псевдо состояние– начальная точка состояния машины, отображается закрашенной точкой Исходное состояние– исходное состояние объекта из которого происходит переход Конечное состояние – состояние, в которое объект перемещается после выполнения перехода Событие сообщения – инициатор для перехода, которое вызывает объект покинуть начальное состояние Ограждающие условия – проверка истинности может ли переход осуществиться Выражение действия – описания действия, выполняемого как часть перехода 46

Д ИАГРАММА СОСТОЯНИЙ МАШИНЫ RMO ДЛЯ КЛАССА O RDER I TEM ПРОБЛЕМНОЙ ОБЛАСТИ 47

С ЛОЖНЫЕ СОСТОЯНИЯ И ПАРАЛЛЕЛИЗМ С ОСТОЯНИЯ ВНУТРИ СОСТОЯНИЯ 48 Пример сложного состояния для объекта принтер

П АРАЛЛЕЛЬНЫЕ ЧАСТИ ДЛЯ ПРИНТЕРА В СОСТОЯНИИ O N 49

П РАВИЛА ДЛЯ РАЗРАБОТКИ ДИАГРАММЫ СОСТОЯНИЯ МАШИНЫ Обзор диаграмм классов предметной области и выбрать важные классы и перечислить все состояния и условия выхода Построение диаграммы состояний машины начинается с фрагментов для каждого класса Фрагменты последовательности в правильном порядке рассматриваются на предмет выполнения независимых и параллельных путей Каждый переход расширяется событием, ограждающим условием и выражением действия Пересмотрите и проверьте каждую диаграмму состояний машины 50

К ЛАСС O RDERС ОСТОЯНИЯ И ВЫХОДЫ 51

П ЕРВОНАЧАЛЬНАЯ ДИАГРАММА СОСТОЯНИЙ МАШИНЫ ДЛЯ O RDER 52

У ЛУЧШЕННАЯ ДИАГРАММА СОСТОЯНИЙ МАШИНЫ ДЛЯ КЛАССА O RDER 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 Многократные ответы!