Определение требований к системе

Сентябрь 2, 2022

Главная
Алгебра
Определение требований к системе

Содержание

2. Виды требований Функциональные требования описывают желаемое поведение системы Нефункциональные требования – любые требования, не являющиеся функциональными,
3. Модель вариантов использования Актант (внесистемный агент, Actor) – внешняя система, взаимодействующая с заданной системой. Актант может
4. Использование модели вариантов испльзования в разработке ПО Модель вариантов использования Разработка программной системы Разработка тестов Тестирование
5. Спецификация варианта использования Спецификация варианта использования – это текстовый документ
6. Спецификация варианта использования Основный поток событий – типовая и, может быть, самая короткая последовательность действий, дающая
7. Графическая нотация
8. Пример: Wylie Course Registration System Glossary
9. Пример: Wylie Course Registration System Close Registration Login Maintain Professor Information Maintain Student Information Register for
10. Отношения между вариантами использования Отношение Include Последовательность событий включаемого варианта использования становится последовательностью включающего варианта использования
11. Отношения между вариантами использования Повторное использование
12. Отношения между вариантами использования Отношение Extend Если выполняется условие расширения, то расширяющий вариант использования становится частью
13. Отношения между вариантами использования
14. Отношения между вариантами использования
15. Отношения между вариантами использования Отношение Обобщения В абстрактном варианте использования обобщаются одинаковые потоки событий других вариантов
16. Отношения между вариантами использования
17. Отношения между вариантами использования
18. Анализ требований Цель: добиться понимания требований в той степени, которая необходима для представления системы в целом,
19. Анализ требований Классы модели анализа – определяют ответственности на высоком уровне абстракции (без детализации методов и
21. Скачать презентацию

Слайд 2

Виды требований
Функциональные требования описывают желаемое поведение системы
Нефункциональные требования – любые требования,

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

Слайд 3

Модель вариантов использования
Актант (внесистемный агент, Actor) – внешняя система, взаимодействующая с

заданной системой. Актант может быть пользователем, либо технической системой.
Вариант использования (Use Case) – это последовательность действий актанта и реакций системы, приводящая к полезному для актанта результату.
Модель вариантов использования – совокупность функциональных требований к системе, описанных в форме вариантов использования. Она содержит описание актантов, спецификации вариантов использования и ассоциаций между ними. Модель вариантов использования является соглашением между заказчиком и разработчиком ПО.
Классификация вариантов использования
По степени использования проектных решений: {идеальный ↔ реальный}
По детализации: {краткий ↔ развернутый}
По уровню абстракции: {абстрактный ↔ конкретный}

Слайд 4

Использование модели вариантов испльзования в разработке ПО
Модель вариантов использования
Разработка программной системы
Разработка тестов
Тестирование

Слайд 5

Спецификация варианта использования
Спецификация варианта использования – это текстовый документ

Слайд 6

Спецификация варианта использования
Основный поток событий – типовая и, может быть, самая

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

Слайд 7

Графическая нотация

Слайд 8

Пример: Wylie Course Registration System
Glossary

Слайд 9

Пример: Wylie Course Registration System
Close Registration
Login
Maintain Professor Information
Maintain

Student Information
Register for Courses
Submit Grades
Select Courses to Teach
View Report Cards

Слайд 10

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

включающего варианта использования (аналогично вызову подпрограмм)

A включает B.
A и B – конкретные варианты использования

Слайд 11

Отношения между вариантами использования
Повторное использование

Слайд 12

Отношения между вариантами использования
Отношение Extend
Если выполняется условие расширения, то расширяющий вариант

использования становится частью расширяемого, добавляя потоки событий

B расширяет A.
B – абстрактный вариант использования, A – как правило, конкретный (абстрактный, если он является расширением другого вариант использования)

Точка расширения

Слайд 13

Отношения между вариантами использования

Слайд 14

Отношения между вариантами использования

Слайд 15

Отношения между вариантами использования
Отношение Обобщения
В абстрактном варианте использования обобщаются одинаковые потоки

событий других вариантов использования

A обобщает варианты использования B и C.
A – как правило, абстрактный вариант использования.

Слайд 16

Отношения между вариантами использования

Слайд 17

Отношения между вариантами использования

Слайд 18

Анализ требований
Цель: добиться понимания требований в той степени, которая необходима для

представления системы в целом, включая архитектуру.
Результат: объектная модель анализа, начальный вариант архитектуры системы

Слайд 19

Анализ требований
Классы модели анализа – определяют ответственности на высоком уровне абстракции

(без детализации методов и конкретных атрибутов). Используются следующие стереотипы классов:
Граничные классы – моделируют взаимодействие между системой и актантом (запросы и получение информации). Запросы актантов – системные операции. Для системных операций составляют диаграммы взаимодействия.
Классы сущностей – моделируют информацию, существующую некоторое время. Как правило классы сущностей получаются из классов предметной области
Управляющие классы – моделируют управление другими объектами (граничных классов и классов сущности). Управляющий класс может соответствовать одному или нескольким вариантам использования.

Определение требований к системе

Содержание

Виды требованийФункциональные требования описывают желаемое поведение системыНефункциональные требования – любые требования,

Модель вариантов использованияАктант (внесистемный агент, Actor) – внешняя система, взаимодействующая с

Использование модели вариантов испльзования в разработке ПОМодель вариантов использованияРазработка программной системыРазработка тестовТестирование

Спецификация варианта использованияСпецификация варианта использования – это текстовый документ

Спецификация варианта использованияОсновный поток событий – типовая и, может быть, самая

Графическая нотация

Пример: Wylie Course Registration SystemGlossary

Пример: Wylie Course Registration SystemClose Registration Login Maintain Professor Information Maintain

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

Отношения между вариантами использованияПовторное использование

Отношения между вариантами использованияОтношение ExtendЕсли выполняется условие расширения, то расширяющий вариант

Отношения между вариантами использования

Отношения между вариантами использования

Отношения между вариантами использованияОтношение ОбобщенияВ абстрактном варианте использования обобщаются одинаковые потоки

Отношения между вариантами использования

Отношения между вариантами использования

Анализ требованийЦель: добиться понимания требований в той степени, которая необходима для

Анализ требованийКлассы модели анализа – определяют ответственности на высоком уровне абстракции

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

Виды требований
Функциональные требования описывают желаемое поведение системы
Нефункциональные требования – любые требования,

Модель вариантов использования
Актант (внесистемный агент, Actor) – внешняя система, взаимодействующая с

Использование модели вариантов испльзования в разработке ПО
Модель вариантов использования
Разработка программной системы
Разработка тестов
Тестирование

Спецификация варианта использования
Спецификация варианта использования – это текстовый документ

Спецификация варианта использования
Основный поток событий – типовая и, может быть, самая

Пример: Wylie Course Registration System
Glossary

Пример: Wylie Course Registration System
Close Registration
Login
Maintain Professor Information
Maintain

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

Отношения между вариантами использования
Повторное использование

Отношения между вариантами использования
Отношение Extend
Если выполняется условие расширения, то расширяющий вариант

Отношения между вариантами использования
Отношение Обобщения
В абстрактном варианте использования обобщаются одинаковые потоки

Анализ требований
Цель: добиться понимания требований в той степени, которая необходима для

Анализ требований
Классы модели анализа – определяют ответственности на высоком уровне абстракции