
- •Программная инженерия
- •Use Case Diagrams (1)
- •Use Case Diagrams (2)
- •Use Case Diagrams (3)
- •Use Case Diagrams (4)
- •Activity Diagrams (1)
- •Activity Diagrams (2)
- •Activity Diagrams (3)
- •Activity Diagrams (4)
- •Sequence Diagrams (1)
- •Sequence Diagrams (2)
- •Sequence Diagrams (3)
- •Sequence Diagrams (4)
- •Identifying Business Objectives (1)
- •Identifying Business Objectives (2)
- •Business Objective for a Hospital Management System Project
- •Dividing a Project into Smaller, Manageable Parts
- •Dividing a Project into Smaller, Manageable Parts (2)
- •Prioritization of Requirements (1)
- •Prioritization of Requirements (4)
- •Prioritization of Requirements (5)
- •Prioritization of Requirements (6)
- •Modeling of the Problem Space (1)
- •Actors (1)
- •Actors (2)
- •Actors (3)
- •Actors (4)
- •How to Find Actors? (1)
- •How to Find Actors? (2)
- •How to Find Actors? (3)
- •How to Find Actors? (4)
- •How to Find Actors? (5)
- •Abstract versus Concrete Actors (1)
- •Abstract versus Concrete Actors (2)
- •Abstract versus Concrete Actors (3)
- •Abstract versus Concrete Actors (4)
- •Clarifying Actor-Class Confusion (1)
- •Clarifying Actor-Class Confusion (2)
- •Clarifying Actor-Class Confusion (3)
- •Use Cases (1)
- •Use Cases (2)
- •Use Cases (3)
- •Finding Use Cases (1)
- •Finding Use Cases (2)
- •Strengths of Use Cases (1)
- •Strengths of Use Cases (2)
- •Strengths of Use Cases (3)
- •Strengths of Use Cases (4)
- •Strengths of Use Cases (5)
- •Weaknesses of Use Cases (1)
- •Weaknesses of Use Cases (2)
- •Use Case Diagrams (1)
- •Use Case Diagrams (2)
- •Use Case Diagrams (3)
- •Use Case Diagrams (4)
- •Требования: пользователя и системы
- •Требования системы: функциональные и нефункциональные
- •Требования к функциональным требованиям (1)
- •Вариант использования (сценарий) «Войти в систему» (1)
- •Вариант использования (сценарий) «Войти в систему» (2)

Prioritization of Requirements (5)
-Моделирование бизнес-целей нижнего уровня как пакетов UML
-Итерационное продолжение процесса приоритизации (повторение предшествующих шагов)
-Включение пакетов с высоким приоритетом в первую итерацию проекта
-Цели нижнего уровня являются кандидатами для построения диаграмм сценариев (в больших системах эти цели представляются пакетами с
соответствующими приоритетами)
Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Prioritization of Requirements (6)
-Требования пользователей в каждом пакете моделируются с использованием
диаграмм сценариев и диаграмм деятельности
-При проектировании используют диаграммы классов, последовательностей и
диаграммы состояний
-Итерационное повторение всех предшествующих шагов в зависимости от
процесса разработки
Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Modeling of the Problem Space (1)
Моделирование в пространстве проблем предназначено для того, чтобы уяснить
ЧТО из себя представляют бизнес-проблемы пользователя.
Пространство проблем, таким образом, отображает модели требований бизнеса, решение которых еще только предстоит найти.
Основные виды деятельности при этом включают в себя детальное
исследование бизнес-проблем, осознание требований, их документирование и анализ, возможно, создание концептуального прототипа, а также понимание
потоков бизнес-процессов.
Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Actors (1)
Моделирование сценариев (вариантов, прецедентов) начинается с
идентификации и документации пользователей или акторов.
Главная цель разработки программного решения состоит в обеспечении
потребностей этих пользователей.
Актор также указывает на то, как система будет использоваться (will be used), отсюда и термин use case – вариант использования.
Акторы обеспечивают основную отправную точку для всего оставшегося моделирования, проектирования и разработки программных проектов.
Актор – это роль, играемая человеком или вещью, которая является внешней
по отношению к программной системе.
Актор (пользователь системы) взаимодействует с системой для достижения
бизнес целей.
Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Actors (2)
Актор – это:
-Роль, играемая обычным пользователем системы (заметим: актор это роль, а не
человек, который играет эту роль)
-Роль, которая инициирует взаимодействие с системой (пациент, который может и не обязательно взаимодействует, но чье присутствие вызывает действия и реакции)
-Время считается актором, т.к. события, запускаемые в определенные моменты времени инициируют взаимодействие или процесс в системе.
-Роль, которая извлекает выгоды (достигает цели) из работы системы
-Внешняя система, с которой будет взаимодействовать разрабатываемая система (общедоступная база данных или сервис)
Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Actors (3)
Актор – это:
-Внешнее устройство, с которым будет взаимодействовать разрабатываемая система (принтер или мобильный телефон)
-Все, что посылает сообщения системе (некие внешние объекты)
-Все, что получает сообщения от системы (другие системы)
-По сути, все, что находится за пределами системы
Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Actors (4)
Кроме того, говоря об акторе, стоит отметить следующее:
Актор может участвовать в нескольких сценариях, т.к. каждый актор способен инициировать несколько процессов в системе и может иметь несколько целей, которых хочет достичь с помощью системы.
Выявление актора может служить отправной точкой для моделирования интерфейса, т.к. актор представляет собой интерфейс системы.
И наконец, актор может служить основой для надлежащего формирования классов (однако, актор, как и пользователь, не является классом).
Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

How to Find Actors? (1)
Правильное определение акторов является первой и наиболее важной
задачей анализа в проблемной области.
Отсутствие должного внимания к процессам идентификации, обсуждения и документирования акторов может привести к неприятию пользователем
принятых решений.
Недостаточное понимание сущности актора часто своим следствием имеет доработки решения и задержки в его поставке, а также общую неудовлетворенность пользователей процессом разработки.
В противоположность этому, вовлечение пользователей в моделирование
требований на его ранних стадиях гарантирует их участие в процессе разработки вплоть до приемочного тестирования.
Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

How to Find Actors? (2)
Список акторов создается в самом начале моделирования сценариев.
Не считайте этот список закрытым.
Идентификация и документация сценариев, создание диаграмм деятельности и последующая идентификация классов неизбежно приведут к
уточнению этого списка.
Такое итерационное пополнение списка или модификация некоторых акторов находится в соответствии с итерационным и постепенных процессом
разработки (Agile).
Идентификация потенциальных акторов и сценариев происходит в рамках рабочих семинаров.
Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

How to Find Actors? (3)
Некоторые вопросы, уместные для создания предварительного списка акторов (которые могут быть заданы в ходе семинара по моделированию сценариев):
-Кто будет главными и второстепенными пользователями системы?
-Кто будет основными выгодоприобретателями при взаимодействии с системой?
-Кто будет основными инициаторами взаимодействия с системой?
-С какими внешними системами и устройствами понадобится интерфейс для разрабатываемой системы?
-Присутствуют ли в системе процессы, для которых время является
существенным параметром?
Bhuvan Unhelkar Software Engineering with UML CRC Press 2018