Разработка требования к системе

Основу составляет диаграмма прецедентов или диаграмма usecase’ов. Этот вид диаграмм позволяет создать список операций или функций, которые выполняет система. По сути, в этой диаграмме у нас расписывается всё, что относится конкретно к нашему ПО. На этой диаграмме изображаются действующие лица и прецеденты.

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

Прецедент, или usecase, или вариант использования – это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-либо действующего лица.

Вопросы, которые помогают создавать систему для выявления пользователей:

1. Для каждого пользователя выясняют, как он будет пользоваться системой

2. Будет ли он работать с информацией

3. Будет ли он информировать систему о внешних событиях

4. Должна ли система уведомлять его о каких-либо изменениях или событиях

Для выявления прецедентов:

1. Существует ли для любого функционального требования хотя бы один прецедент

2. Какую информацию предоставляет системе каждый пользователь, какую информацию получит от Системы каждый пользователь

3. Выявлены ли все действующие лица

4. Обслуживающие систему учтены ли все внешние системы, с которыми взаимодействует разрабатываемая система

5. какую информацию наша система будет получать от внешних систем, и какую будет отправлять им

Элементы диаграммы связываются между собой отношениями.

Между действующими лицами возможны отношения обобщения и генерализации (наследование). Если у нас есть действующее лицо “пользователь”, который может только просматривать информацию, то его функции может наследовать действующее лицо “зарегистрированный пользователь” – в его функции также включается просмотр информации, но добавляются свои функции. Такие отношения обозначаются сплошной стрелкой с наконечником, проведённой от класса-наследника к классу-потомку.

Между действующим лицом и usecase’ом возможны отношения ассоциации, изображаемые обычной стрелкой или обычной линией.

Отношения между прецедентами:

1. Отношения обобщения (наследования), когда деятельность одного прецедента наследуется другим прецедентом с добавлением своих свойств. Эта операция используется редко.

2. Включающие отношения. Изображаются в виде стрелки с надписью “Include”, которая следует от главного прецедента к дополнительному. Позволяет одному прецеденту предоставлять свои функции другому прецеденту. Например, оформление заказа предоставляет функцию выбора способа доставки. Этот вид отношения выполняется всегда, т. е. при оформлении заказа всегда требуется выяснить, каким способом товар будет доставлен.

3. Расширяющие отношения. Позволяют одному прецеденту дополнить свою функциональность за счёт другого. Выполняются в каких-либо исключительных ситуациях, т. е. не всегда. Изображаются в виде пунктирной стрелки с надписью “Extend”, которая следует от дополнительного к главному. Например, при просмотре заказов покупатель может отменить какой-то из сделанных заказов, а может не отменить. Когда пользователь просматривает каталог, покупатель может оформить заказ, а незарегистрированный пользователь – не может.

Задание: построить usecase-модель создаваемой системы.

В Visual Paradigm создаём привычную Use Case Diagram, но теперь не заботимся об установке флажков “Business Diagram”. Все элементы отныне рисуем без косых черт.