Доклад Николая Киреева на Analyst Days-7. 13-14 октября 2017. Минск www.analystdays.com

1. Практикум UML
Моделирование функциональности
бизнеса и ПО на основе модифицированной
структуры уровней требований
Николай Киреев
info@webmax.by
Студия информационных технологий
WebMax.BY

2. Уровни требований К. Вигерса
Уровни требований [К. Вигерс «Разработка требований к ПО», 2004, с.8, рис. 1-1]

3. О чём «молчат» уровни К. Вигерса
• Не поддерживают чёткого разделения Бизнес - Система
• Не предусматривает моделирования функциональности бизнес- субъектов, не
являющихся пользователями программной системы
• Предусматривает моделирование функций программной системы только на
уровне пользовательских требований
• Не вводит иерархии функциональных требований, исключая таким образом их
детализацию.

4. Фреймворк Дж. Захмана
Люди/организации достигают поставленных целей, исполняя возложенные на
них функциональные обязанности, в определённом месте, в определённое
время и оперируя конкретными данными
Почему?
Кто?
Что?
Когда?
Где?
Как?

5. Контекст – Бизнес – Система

6. Модифицированные уровни
функциональных требований
и их моделирование
Что даёт модификация уровней:
1. Чёткое разделение моделей
бизнеса и системы.
2. Делает возможным представлять
субъекты-участники бизнес-
процесса, не являющиеся
пользователями системы.
3. Возможность более детального
представления функций
программной системы.
4. Отделяет функции бизнес-логики
от GUI

7. Представление функционала. Как?
Если говорим о ФУНКЦИЯХ, подразумеваем СУБЪЕКТОВ,
говорим о СУБЪЕТАХ, имеем ввиду их ФУНКЦИИ
Уровень Контекста (Отрасль)
Внешние по отношению к бизнес-системе
субъекты (должностные лица) достигают общие
цели (цели отрасли), исполняя свои
функциональные (должностные) обязанности,
результатом которых станут законы, правила и
ограничения для бизнеса. Их необходимо
учитывать при разработке архитектуры бизнеса.
Уровень Бизнеса (Предприятие)
Участники бизнеса (должностные лица и/или
штатные единицы, в UML это Business Actors)
достигают поставленных целей (Business Goals),
исполняя возложенные на них функциональные
обязанности (в UML-моделях это Business Use
Cases).
Уровень Системы
Пользователи программной системы (Actors)
достигают целей (Software Goals), инициируя
функциональные сервисы системы (User
Requirement, в UML-моделях это базовые Use
Cases).
Законы,
стандарты,
нормы
правила,
ограни-
чения
Бизнес
Система

8. Структура представления Use Case View
(шаблон RUP)
Business Use Case
Model
Use Case Model
Модели Бизнеса Модели Системы

9. Business Use Case Model (уровень Бизнеса)

10. Структура Use Case Model (уровень Системы)
Общая
UC-модель системы
Модели общей
функциональности для
групп пользователей
Детальная модель
функционала
инициируемого
отдельным актёром
Раздельно для
физ.лиц и системБазовые
сервисы,
актёры и
границы
системы
Только для
актёров
физ.лиц

11. Пример. Общая Use Case диаграмма
Диаграмма прецедентов [Д. Арлоу, А. Нейштадт «UML-2 и унифицированный процесс», 2007, с.98, рис. 4.6]

12. Пример. Общая Use Case диаграмма

13. Пример. Общая Use Case диаграмма

14. Пример. Модель общих (для группы) функций

15. Пример. Модель общих (для группы) функций

16. Пример. Детализация функций актёров- физ.лиц

17. Пример. Детализация функций актёров- физ.лиц

18. Принцип MDA или разработка моделированием
Модель MDA [Арлоу Д., Нейштадт И. „UML 2 и Унифицированный процесс. Практический
объектно-ориентированный анализ и проектирование“, 2е издание, 2007, с.28]

19. Заключение. Что дают модифицированные уровни?
ЧТО ДАЮТ МОДИФИЦИРОВАННЫЕ УРОВНИ ТРЕБОВАНИЙ?
• ЧЁТКОЕ РАЗДЕЛЕНИЕ МОДЕЛЕЙ БИЗНЕСА И СИСТЕМЫ
• ПОНЯТНУЮ ИЕРАРХИЮ ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ
• ВОЗМОЖНОСТЬ КАК ОБЩЕГО ПРЕДСТАВЛЕНИЯ
ФУНКЦИНАЛЬНОСТИ СИСТЕМЫ, ТАК ЕЁ ДЕТАЛИЗАЦИИ ДО
УРОВНЯ ФУНКЦИЙ БИЗНЕС-ЛОГИКИ
• ВОЗМОЖНОСТЬ СОЗДАВАТЬ БОЛЕЕ «ЧИТАБЕЛЬНЫЕ»
USE-CASE ДИАГРАММЫ

20. Спасибо за внимание!
Николай Киреев
info@webmax.by
www.webmax.by