21. Понятие прецедента в процессе моделирования требований к информационной системе, модель прецедентов.

Прецеденты – рассказы об использовании системы в процессе решения поставленных перед ней

задач. Под прецедентами мы будем понимать не диаграммы, а текстовое описание. Основной

сложности в описании прецедентов является выбор нужного уровня детализации.

Тогда, прецедент (use case) — это набор взаимосвязанных успешных и неудачных сценариев,

описывающий использование системы исполнителем для решения одной из задач. Например,

рассмотрим свободный формат прецедента, включающего некоторые альтернативные сценарии.

Модель прецедентов.

Как артефакт унифицированного процесса модель прецедентов состоит из диаграмм прецедентов,

текстов описаний прецедентов, системных диаграмм последовательностей и описание операций.

Сами по себе прецеденты не имеют отношения к объектно-ориентированной разработке и

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

объектно-ориентированного анализа и проектирования (ООА/П)

Более того: прецеденты упрощают этап формулировки требований для всех заинтересованных лиц.

Описания прецедентов должны быть ориентированы на цели и задачи пользователя и в

зависимости от реальных потребностей позволяют варьировать уровень сложности и

формальности.

22. Понятие исполнителя в процессе формализации требований к информационной системе

Исполнитель (actor) – сущность, обладающая поведением, компьютерная система или

организация.

К числу исполнителей может относится сама система, если она вызывает службы других систем.

Также существуют специальные исполнители – время, который вводится в том случае, если какие-либо действия должны осуществится по расписанию или через заданный промежуток времени. Во всех остальных ситуациях существует различают три типа внешних по отношению к

разрабатываемой системе исполнителя:

1. Основной исполнитель (primary) – его задача выполняется с использованием системы. Этот

тип используется для определения целей пользователя, на основе которых формулируются

прецеденты.

2. Вспомогательный исполнитель (supporting) – обслуживает систему, например

предоставляет информацию. Используется для определения внешних интерфейсов и

протоколов.

3. Закулисный исполнитель (offstage) – заинтересован в реализации прецедента, но не

является основным или вспомогательным исполнителем.

23. Артефакты унифицированного процесса, используемые для описания нефункциональных требований к информационной системе

По определению гибкий унифицированный процесс (в дальнейшем просто унифицированный

процесс) детерминированный набор необязательных видов деятельности и артефактов. Однако на практике унифицированный процесс является скорее адаптивным и гибким.

Так как все артефакты унифицированного процесса являются не обязательными

– следует избегать их создание, если нельзя получить лучшее качество.

Артефакт – любой результат работы, например код, текстовые документы, диаграммы, модели…

Требование – возможности или условия, которым должны соответствовать система или проект.

Требования можно разделить (классификацировать) на функциональные и не функциональные. Функциональные требования относятся к поведению системы, нефункциональные это все остальные.

В унифицированном процессе предусмотрены несколько артефактов, связанных с требованиями:

1. Модель прецедентов.

2. Дополнительная спецификация.

3. Словарь терминов.

4. Видение.

5. Бизнес правила.

технические артефакты – модели системы, исходные коды программ, готовый программный продукт, документация к нему и т. д.

артефакты управления – календарный план, техническое задание, инструкции и т. д.

Возможно что-то из них лишнее.