Моделирование требований к системе 29 icon

Моделирование требований к системе 29


2 чел. помогло.

Смотрите также:
Моделирование бизнес-процессов спецификация требований на основе структурного подхода...
Лекция: Этапы проектирования ис с применением uml: Основные типы uml-диаграмм...
Реферат отчёта по нир на тему: «Разработка требований к системе отраслевых показателей...
Формулирование и анализ требований 1 Определение требований к системе 2 Пользовательские...
Формулирование и анализ требований 1 Определение требований к системе 2 Пользовательские...
Уточнение требований к системе 6 Архитектура системы 8...
Программа вступительного экзамена в магистратуру по направлению...
Руководство по системе pc4020...
“Компьютерное моделирование работы схемы усилителя”...
К минимуму содержания и уровню требований к специалистам для присвоения дополнительной...
Учебная программа. Наименование тем, их содержание...
К минимуму содержания и уровню требований к специалистам для присвоения дополнительной...



страницы: 1   2   3   4   5   6   7   8   9   ...   13
вернуться в начало
скачать
^

ЛЕКЦИЯ 5. Модель анализа прецедентов




Предварительные замечания



Системы не существуют в изоляции. Как правило, они взаимодействуют с актерами, людьми или программами, которые используют систему в своих целях, причем каждый актер ожидает, что она будет вести себя определенным, вполне предсказуемым образом. Прецедент (use case) специфицирует поведение системы или ее части и представляет собой описание множества последовательностей действий (включая варианты), выполняемых системой для того, чтобы актер мог получить определенный результат.

С помощью прецедентов можно описать поведение разрабатываемой системы, не определяя ее реализацию. Таким образом, они позволяют достичь взаимопонимания между разработчиками, системными аналитиками, экспертами и конечными пользователями продукта. Кроме того, прецеденты помогают проверить архитектуру системы в процессе ее разработки. Реализуются они кооперациями.

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

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

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

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

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

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


^

Поток событий, сценарий, кооперация



Итак, прецедентом называется описание множества последовательностей действий, включая варианты, выполняемых системой для того, чтобы актер мог получить определенный результат. Графически прецедент изображается в виде эллипса. Нотация прецедента похожа на нотацию кооперации. Другой термин, который достаточно часто используется, процесс. Процесс (process) от начала и до конца описывает последовательность событий, действий и транзакций, требуемых для достижения какого-либо результата.

Любой прецедент должен иметь имя, отличающее его от других прецедентов. Оно должно быть уникально внутри объемлющего пакета. Имя прецедента представляет собой текстовую строку. Взятое само по себе оно называется простым именем. К составному имени спереди добавляется имя пакета, в котором находится прецедент. Обычно, при изображении прецедента указывают только его имя.

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

Актеров можно связывать с прецедентами только отношениями ассоциации. Ассоциация между актером и прецедентом показывает, что они общаются друг с другом, возможно, посылая или принимая сообщения. Можно использовать механизмы расширения UML для приписывания актеру стереотипа, чтобы создать другую пиктограмму, адекватную поставленным целям. Также можно определить общие типы актеров, а потом специализировать их, создавая разновидности, с помощью отношения специализации.

Прецедент описывает, что делает система (подсистема, класс или интерфейс), но не определяет, каким образом она это делает. В процессе моделирования всегда важно разделять внешнее и внутреннее представления.

Можно специфицировать поведение прецедента путем описания потока событий в текстовой форме - в виде, понятном для постороннего читателя. В описание необходимо включить указание на то, как и когда прецедент начинается и заканчивается, когда он взаимодействует с актерами и какими объектами они обмениваются. Важно обозначить также основной и альтернативный потоки поведения системы.

Для полноты картины дадим полный список определений различных видов прецедентов, которые создаются на различных этапах планирования и анализа.

Прецеденты высокого уровня (high-level use case) - это очень краткие описания процессов, обычно состоящие из 2-3 предложений. Язык UML не определяет какой-либо жесткий формат для представления прецедентов, одна из возможных структур описания приведена ниже, хотя в зависимости от требований к документации можно выбрать и другую, что может значительно облегчить дальнейшую работу. Прецеденты высокого уровня описывают процессы очень сжато, обычно в двух или трех предложениях. Такой тип описания очень удобно использовать на начальном этапе формулирования требований к системе для быстрого осознания степени сложности и функций системы. Прецеденты высокого уровня - это лишь краткое описание, имеющее слабое отношение к конкретным проектным решениям.

Прецедент Название прецедента (русское и английское).

Исполнители Исполнители, работающие с прецедентом.

Тип Какой тип (типы прецедентов будут рассмотрены ниже).

Описание Словесное описание прецедента, состоящее из двух - трех предложений.


Рис. Описание прецедента высокого уровня


Развернутые прецеденты (expanded use case) представляют собой более подробное описание, чем прецеденты высокого уровня. Они оказываются полезными для углубленного понимания происходящих процессов и требований. Очень часто развернутые прецеденты имеют форму диалога между исполнителем и системой. Развернутый прецедент описывает процесс более детально, чем прецедент высокого уровня. Основной особенностью этого прецедента является наличие раздела "Типичный ход событий", в котором описывается последовательность событий. На этапе формулирования требований в развернутом формате целесообразно представлять лишь наиболее важные и значительные прецеденты, а более подробное описание остальных прецедентов отложить до того цикла разработки, в котором они должны быть реализованы. Жесткого формата на представление развернутых прецедентов тоже нет. Один из вариантов их описания приведен ниже. В верхней части развернутой формы содержится обобщенная информация, большая часть которой берется из соответствующего прецедента высокого уровня.

Прецедент Имя прецедента

Исполнители Перечень исполнителей (внешних агентов), а также те из них, кто инициирует данный прецедент

Цель Цель прецедента

Краткое описание Копия содержимого прецедента высокого уровня или некоторая аналогичная обобщенная информация

Тип 1. Главный, второстепенный или дополнительный

2. Идеальный или реальный

Ссылки Связанные прецеденты и (или) функции системы.


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

^ ТИПИЧНЫЙ ХОД СОБЫТИЙ

Действия исполнителя Отклик системы

Пронумерованные действия исполнителей Пронумерованные описания откликов системы


Завершающий раздел, "Альтернативный ход событий", должен содержать важные альтернативы или исключения, которые могут возникать в ходе типичной последовательности. Если эти исключения слишком сложны, они могут быть развернуты в собственные прецеденты.

Альтернатива Описание

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


По мере уточнения требований к системе потоки событий прецедента будет удобнее записать в графической нотации, используя диаграммы взаимодействий. Обычно для главного потока (типичного хода событий) используют диаграмму последовательностей, а для дополнительных (альтернатив) ее варианты. Обратите внимание, что типичный ход событий отделяется от альтернатив. Поскольку прецедент описывает не одну, а множество последовательностей, то выразить все детали интересующего вас прецедента с помощью одной последовательности просто невозможно. Один прецедент, обычно, описывает несколько последовательностей, или сценариев, каждый из которых представляет одну из возможных вариаций данного потока событий. Таким образом, сценарий (scenario) - это некоторая последовательность действий, иллюстрирующая поведение системы. Сценарии находятся в таком же отношении к прецедентами, как экземпляры (объекты) к классам, то есть сценарий - это экземпляр прецедента.

Относительно сложная система содержит несколько десятков прецедентов, каждый из которых может разворачиваться в несколько десятков сценариев. Для любого прецедента можно выделить основные сценарии, описывающие важнейшие последовательности, и вспомогательные, описывающие альтернативы.

Как уже не раз оговаривалось, прецедент описывает желательное поведение системы (подсистемы, класса или интерфейса), но не определяет их реализацию. Это важнейшая особенность, так как анализ системы, по результатам которого специфицируется ее поведение, по возможности не должен учитывать проблемы реализации, иными словами, как это поведение должно быть материализовано. В конце концов, однако, прецеденты придется реализовывать. Для этого необходимо будет создать сообщество классов и других элементов, в результате совместного поведения которых будет достигнуто желаемое поведение. Такое сообщество. Включая его динамическую и статическую структуру, называется в UML коопераций.

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

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





Скачать 0,92 Mb.
оставить комментарий
страница6/13
Дата30.09.2011
Размер0,92 Mb.
ТипЛекция, Образовательные материалы
Добавить документ в свой блог или на сайт

страницы: 1   2   3   4   5   6   7   8   9   ...   13
отлично
  3
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

Загрузка...
База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Документы

наверх