Бренд
<<  Требования к бренду Шины расширения  >>
Модели требований—Традиционный и OO
Модели требований—Традиционный и OO
Связи между моделями требований OO
Связи между моделями требований OO
Пример диаграммы вариантов использования
Пример диаграммы вариантов использования
Пример описания прецедента
Пример описания прецедента
Пример диаграммы видов деятельности (Activity Diagram)
Пример диаграммы видов деятельности (Activity Diagram)
Пример диаграммы последовательности системы
Пример диаграммы последовательности системы
Простая UCD
Простая UCD
UCD с границей автоматизации и двумя акторами
UCD с границей автоматизации и двумя акторами
Все прецеденты для одного актора
Все прецеденты для одного актора
UCD для order entry subsystem
UCD для order entry subsystem
Brief Description of Create New Order Use Case (Figure 7-7)
Brief Description of Create New Order Use Case (Figure 7-7)
Полное описание сценария заказа по телефону New Order Use Case
Полное описание сценария заказа по телефону New Order Use Case
Верхняя часть Полного описания прецедента
Верхняя часть Полного описания прецедента
Средняя часть Полного описания прецедента
Средняя часть Полного описания прецедента
Нижняя часть Полного описания прецедента
Нижняя часть Полного описания прецедента
Диаграмма видов деятельности— Сценарий Web заказа
Диаграмма видов деятельности— Сценарий Web заказа
Нотация System Sequence Diagram (SSD)
Нотация System Sequence Diagram (SSD)
Повторяемые сообщения
Повторяемые сообщения
Диаграмма видов деятельности и результирующая SSD для Заказа по
Диаграмма видов деятельности и результирующая SSD для Заказа по
Диаграмма видов деятельности и результирующая SSD для Заказа по
Диаграмма видов деятельности и результирующая SSD для Заказа по
Простая диаграмма State Machine для принтера
Простая диаграмма State Machine для принтера
Диаграмма состояний машины RMO для класса OrderItem проблемной области
Диаграмма состояний машины RMO для класса OrderItem проблемной области
Сложные состояния и параллелизм—Состояния внутри состояния
Сложные состояния и параллелизм—Состояния внутри состояния
Параллельные части для принтера в состоянии On
Параллельные части для принтера в состоянии On
Класс Order—Состояния и выходы
Класс Order—Состояния и выходы
Первоначальная диаграмма состояний машины для Order
Первоначальная диаграмма состояний машины для Order
Улучшенная диаграмма состояний машины для класса Order
Улучшенная диаграмма состояний машины для класса Order
RMO Таблица событий
RMO Таблица событий
Картинки из презентации «Анализ требований» к уроку экономики на тему «Бренд»

Автор: John Satzinger. Чтобы познакомиться с картинкой полного размера, нажмите на её эскиз. Чтобы можно было использовать все картинки для урока экономики, скачайте бесплатно презентацию «Анализ требований.ppt» со всеми картинками в zip-архиве размером 3958 КБ.

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

содержание презентации «Анализ требований.ppt»
Сл Текст Сл Текст
1ОО Анализ требований. 26система добавляет его в заказ Заказчик
2Содержание лекции. Разработка повторяет шаги 5-6 Клиент сигнализирует об
диаграммы прецедентов Описание прецедента окончании формирования заказа; система
и сценарий Разработка диаграмм видов показывает итоги заказа Клиент выполняет
деятельности и диаграмм любые изменения Клиент запрашивает экран
последовательностей Разработка диаграмм оплаты; система показывает экран оплаты.
состояния машины для моделирования Клиент вводит информацию по оплате;
поведения объектов Объяснение каким система показывает суммарную информацию и
образом диаграммы UML используются посылает e-mail подтверждения Система
совместно для определения функциональных завершает заказ Исключительные условия
требований для объектно-ориентированного Если существующий клиент забыл пароль, то
подхода. 2. Клиент может вызвать обработку забытого
3Введение. Целью определения требований пароля Клиент может создать новую учетную
является понимание потребностей запись Если клиент отклонен из-за проверки
пользователя и бизнес-процессов для кредитных обстоятельств, то Клиент может
поддержки последних Понять и определить снять заказ или Заказ задерживается до
требования системы, используя модели ООА и выполнения оплаты. 26.
технологии Граница между ООА и ООD не 27Полное описание сценария заказа по
определена Итеративный пошаговый процесс к телефону New Order Use Case. 27.
разработке Модели строятся на этапе 28Верхняя часть Полного описания
анализа и улучшаются на этапе прецедента. 28.
проектирования. 3. 29Средняя часть Полного описания
4Требования ОО подхода. Нотация ОО прецедента. 29.
моделирования - Unified Modeling Language 30Нижняя часть Полного описания
(UML 2.0) UML принят Object Management прецедента. 30.
Group (OMG) как стандарт технологии 31Компоненты описания прецедента. Имя
моделирования Цели OMG Содействовать прецедента/Имя сценария Акторы/вовлеченные
теории и практике ОО технологии для лица(системы) Связанные прецеденты
разработки распределенных систем Предварительные условия– набор критериев,
Обеспечивать общую архитектурную систему которые должны выполнены перед началом
взглядов для ОО подхода. 4. прецедента Выходные условия– набор
5Требования ОО подхода(продолжение). критериев, которые должны выполнены после
Требования ОО системы определяются и выполнения прецедента Виды деятельности
документируются посредством построения (шаги в одну или две колонки)
моделей Процесс моделирования начинается с Исключительные условия. 31.
идентификации прецедентов и классов 32Диаграммы видов деятельности.
проблемной области (предметов и понятий Документирует последовательность
рабочего окружения пользователей) События выполнения бизнес-операций для каждого
бизнеса запускают элементарные прецедента или сценария Standard UML 2.0
бизнес-процессы (BP), которые новая diagram Может поддерживать любой уровень
система должна рассматривать как варианты описания прецедентов; для дополнительного
использования Варианты использования использования в описании прецедента
определяют функциональные требования. 5. Полезно при разработке диаграмм
6Модели ОО требований. Use case последовательностей системы. 32.
diagrams – идентифицирует акторов и их 33Диаграмма видов деятельности— Сценарий
варианты использования (цели) use case заказов по телефону. 33.
descriptions – включает подробности 34Диаграмма видов деятельности— Сценарий
варианта использования и способа Web заказа. 34.
использования системы актором activity 35Определение входов и выходов—
diagrams – описывает пользователя и виды Диаграмма последовательности системы.
деятельности системы для прецедента Диаграмма последовательности системы -
systems sequence diagrams (ssds) – System sequence diagram (SSD)
определяет входы и выходы и разновидность взаимодействия UML 2.0
последовательность взаимодействия между Обычно моделирует требования сообщений по
пользователем и системой для варианта входу и по выходу для прецедента или
использования state machine diagrams – сценария Показывает акторов,
описывает состояния для каждого объекта. взаимодействующих с системой Показывает
6. последовательность взаимодействий как
7Модели требований—Традиционный и OO. сообщений в процессе выполнения потоков
7. операций Система показывается как один
8Связи между моделями требований OO. 8. объект : черный ящик (“black box”). 35.
9Пример диаграммы вариантов 36Нотация System Sequence Diagram (SSD).
использования. 9. 36.
10Пример описания прецедента. 10. 37Нотация SSD. Актор (Actor)
Systems Analysis and Design in a Changing представляется как фигура из линий–
World, 4th Edition. человек (роль), который взаимодействует с
11Пример диаграммы видов деятельности системой вводя входные данные и получая
(Activity Diagram). 11. выходные данные Объект (Object) –
12Пример диаграммы последовательности прямоугольник с подчеркнутым именем
системы. 12. объекта– показывает индивидуальный объект,
13The System Activities— A Use а не класс похожих ( :System для SSD )
Case/Scenario View. Анализ прецедентов Линия жизни (Lifeline) - вертикальная
идентифицирует и определяет все линия под объектом или актором для
бизнес-процессы, которые система должна представления течения времени для объекта
поддерживать Use case – деятельность Сообщение (Message) помеченная стрелка для
системы, выполняемая, обычно, на запрос показа посланных системе сообщений или
пользователя Actor Роль, исполняемая полученных актором из системы. 37.
пользователем За пределами границ 38Линия жизни SSD. Вертикальная линия
автоматизации. 13. под объектом или актором Показывает
14Технологии, идентифицирующие варианты течение времени Если вертикальная линия
использования. Идентификация целей прерывистая Создание и уничтожение
пользователя Каждая цель- уровень предметов не является важным для сценария
элементарного бизнес-процесса (EBP) Длинные узкие прямоугольники На линии
является вариантом использования EBP – жизни показывает, что объект активный
задача, выполняемая одним пользователем в только во время части сценария. 38.
одном месте и в ответ на событие бизнеса, 39Сообщения SSD. Внутренние события ,
которая добавляет измеряемой ценности идентифицируемые потоком объектов в
бизнесу и покидает систему и данные в сценарии Запросы от одного актора или
согласованном состоянии Технология на объекта другому выполнть некоторые
декомпозиции событий (таблица событий) действия Вызов определенного метода. 39.
Технология CRUD – анализа (create, 40Повторяемые сообщения. 40.
read/report, update, delete) для 41Разработка диаграммы
обеспечения границ. 14. последовательностей системы (System
15Use Case Diagram. Графическая Sequence). Начинается с подробного
диаграмма UML, которая обобщает информацию описания прецедента для полностью
об акторах и прецедентах Простая диаграмма разработанных диаграмм форм и видов
показывает обзор функциональных требований деятельности Идентифицирует входные
Может иметь несколько use case diagrams сообщения Описывает сообщения от внешнего
(UCD) По подсистемам По акторам. 15. актора системе, используя нотацию
16Простая UCD. 16. сообщений Идентифицирует и добавляет любые
17UCD с границей автоматизации и двумя условия на входные сообщения, включая
акторами. 17. итерации и условия true/false
18Все прецеденты для одного актора. 18. Идентифицирует и добавляет выходные
19UCD для order entry subsystem. 19. возвращаемые сообщения. 41.
20Отношение <<Includes>> 42Диаграмма видов деятельности и
Документирует ситуации, в которых один результирующая SSD для Заказа по телефону.
прецедент требует обслуживания общей 42.
программы Другой прецедент разрабатывается 43SSD для Web Заказа сценария прецедента
для этой общей программы Общий прецедент Create New Order. 43.
может использоваться несколькими 44Идентификация поведения объекта—
прецедентами. 20. Диаграмма состояния машины (State Machine
21Пример варианта использования Diagram). State machine diagram –
Order-Entry Subsystem диаграмма UML 2.0 которая моделирует
с<<Includes>> 21. состояния объектов и переходов Должны
22CRUD –анализ для моделироваться классы сложных проблемных
идентификации/подтверждения прецедента. областей Состояние объекта Условие,
CRUD – create, read/report, update, delete которое совершается во время его
Технология Information Engineering (IE) жизненного цикла, когда оно удовлетворяет
для идентификации таблицы событий или некоторым критериям, выполняет некоторые
непосредственной разработки диаграммы действия или ожидает события Каждое
прецедентов Сравнивает идентифицированные состояние имеет уникальное имя и почти
варианты использования с диаграммой неизменное условие или состояние Переход
классов предметной области Каждый класс в Перемещение объекта из одного состояния в
диаграмме классов должен использовать другое состояние. 44.
прецеденты для поддержки создания, чтения, 45Простая диаграмма State Machine для
изменения, удаления и формирования отчетов принтера. 45.
экземпляров объектов Подтверждает 46Терминология Состояния Машины. Псевдо
требования интеграции системы. 22. состояние– начальная точка состояния
23Описание прецедентов. Use case машины, отображается закрашенной точкой
description обеспечивает подробные Исходное состояние– исходное состояние
предварительные условия, постусловия, объекта из которого происходит переход
последовательность действий и Конечное состояние – состояние, в которое
исключительных ситуаций в прецеденте объект перемещается после выполнения
Описывает пошаговое взаимодействие actor с перехода Событие сообщения – инициатор для
компьютерной системой в процессе перехода, которое вызывает объект покинуть
выполнения бизнес-процедур Может иметь начальное состояние Ограждающие условия –
несколько сценариев для прецедента, каждый проверка истинности может ли переход
из которых является экземпляром прецедента осуществиться Выражение действия –
Три уровня детальности: краткое, описания действия, выполняемого как часть
промежуточное и полное разработанное перехода. 46.
описание Многие аналитики предпочитают 47Диаграмма состояний машины RMO для
делать текстовое описание прецедента класса OrderItem проблемной области. 47.
вместо рисования диаграмм видов 48Сложные состояния и
деятельности. 23. параллелизм—Состояния внутри состояния.
24Brief Description of Create New Order Пример сложного состояния для объекта
Use Case (Figure 7-7). Описание прецедента принтер. 48.
Создание нового заказа Когда клиент 49Параллельные части для принтера в
запрашивает заказ, менеджер по работе с состоянии On. 49.
клиентами и система проверяют информацию о 50Правила для разработки диаграммы
клиенте, создают новый заказ, добавляют состояния машины. Обзор диаграмм классов
строки мпецификации заказа, проверяют предметной области и выбрать важные классы
оплату, создают транзакцию заказа и и перечислить все состояния и условия
завершают Заказ. 24. выхода Построение диаграммы состояний
25Промежуточное описание сценария машины начинается с фрагментов для каждого
прецедента для Create New Order Use Case. класса Фрагменты последовательности в
Поток действий для сценария Менеджер правильном порядке рассматриваются на
создает заказ по телефону Главный поток предмет выполнения независимых и
Клиент звонит в фирму и запрашивает заказ параллельных путей Каждый переход
у менеджера Менеджер проверяет информацию расширяется событием, ограждающим условием
о клиенте. Если новый клиент, вызывает и выражением действия Пересмотрите и
прецедент Поддержка учетной информации о проверьте каждую диаграмму состояний
клиенте, чтобы добавить нового клиента машины. 50.
Менеджер начинает создание нового заказа 51Класс Order—Состояния и выходы. 51.
Клиент запрашивает Менеджера о включении 52Первоначальная диаграмма состояний
продукции в заказ Менеджер проверяет машины для Order. 52.
продукцию и добавляет в заказ Шаги 4-5 53Улучшенная диаграмма состояний машины
повторяются до окончания требуемой для класса 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
задерживается до выполнения оплаты. 25. diagrams. 54.
26Промежуточное описание сценария 55Связи между OO моделями требований.
прецедента WEB Создание нового заказа. 55.
Промежуточное описание Поток действий для 56Итоги. ОО подход имеет полный набор
сценария Менеджер создает WEB- заказ диаграмм, которые определяют требования
Главный поток Клиент соединяется с Требования определяются с использованием
WEB-страницей и затем выходит на страницу следующих моделей Диаграмма классов модели
заказов Если клиент новый, клиент предметной области Диаграмма вариантов
переходит на страницу учетных записей и использования Подробные модели
добавляет соответствующую информацию для прецедентов, либо в описательном формате
клиента. Если клиент существует – вход в либо диаграммах видов деятельности
систему Система начинает новый заказ и Диаграммы последовательности системы
показывает структуру каталога Клиент Диаграммы состояния машины. 56.
просматривает каталог Когда клиент находит 57RMO Таблица событий. Многократные
подходящий товар, он включает его в заказ; ответы! 57.
Анализ требований.ppt
http://900igr.net/kartinka/ekonomika/analiz-trebovanij-106405.html
cсылка на страницу

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

другие презентации на тему «Анализ требований»

«Требования к учебным помещениям» - Для озеленения не следует использовать деревья и кустарники с ядовитыми плодами и колючками. Естественная вентиляция осуществляется через фрамуги и форточки. Подвижные и спортивные игры проводят не менее 3 раз в неделю. Фрамуги и форточки должны функционировать круглогодично. Наполняемость начальных классов не должна превышать 20 человек.

«Требования пожарной безопасности» - СП «Склады сжиженных углеводородных газов. СП «Обустройство нефтяных и газовых месторождений. Правила пожарной безопасности, иные нормативные документы. Определение соответствия объекта требуемому уровню пожарной безопасности. СП «Склады нефти и нефтепродуктов. Требования пожарной безопасности». Действующая редакция Предлагаемая новая редакция.

«Требования к обучению» - Проведение нулевых уроков не допускается. Заменять уроки физической культуры другими предметами не допускается. 10.30. Обучение в 3 смены в общеобразовательных учреждениях не допускается. Факультативные занятия следует планировать на дни с наименьшим количеством обязательных уроков. X. Гигиенические требования к режиму образовательного процесса.

«Требования к презентации» - Второй слайд цели и задачи дипломной работы. Список использованных источников. Стиль оформления презентации и порядок представления информации. Задача 1 задача 2 задача 3 … Возможности оформления таблиц. Цель 1 цель 2 цель 3 … Требования к оформлению таблиц в презентации. Требования к графической информации.

«Требования к выпускной работе» - Примеры аннотаций. Цели выпускной работы. Выпускная работа должна представлять собой материал, который будет использоваться в профессиональной деятельности слушателя!!! Надеемся, что унификация требований к выпускным работам позволит поднять качество обучения педагогических работников. Тема: Требования к выпускной работе слушателей.

«Требования к современному учителю» - Учителя - вторые родители … Учитель должен быть вежливым, выдержанным и спокойным. Учитель… Хороший учитель может разобраться в любой ситуации. Какими качествами должен обладать современный учитель? Учитель очень важная и ответственная профессия в мире. Что быть учителем – одна из сложнейших профессий.

Бренд

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

Экономика

125 тем
Картинки