Мансуров Н. Н., Майлингова О. Л. - Методы формальной спецификации программ - языки MSC и SDL, страница 4

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

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

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

Заметим, что втрадиционном определении отношения наследованиямежду классами(например в C++, Smalltalk, Java и т.д.) наследуются только определенияопераций и атрибутов и не накладывается никаких ограничений ни на ихупорядоченность, ни на способы переопределения.Между тем, в случае отношения использования между сценариямиконкретный сценарий полностью определяет в какой момент и какимобразом использовать абстрактный сценарий. Это означает, что приизменении абстрактного класса необходимо проверять все конкретныеклассы, которые его используют. Таким образом, конкретные классы зависятот абстрактных классов.2.2.2. Отношение расширенияСценарии могут находиться в отношении расширения.

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

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

При этом базовый сценарий незнает о возникновении прерывания. Точка прерывания определяетсярасширением. При добавлении новых расширений базовый сценарий неизменяется. Вместе с тем, поскольку расширения зависят от базовогосценария, при изменении последнего необходимо проверять все расширения.2.3. Сценарная модельОбычно, сценарная модель состоит из следующих трех частей:• список агентов;• список сценариев использования;• набор описаний сценариев использования.Список агентов должен описывать каждого «обнаруженного» агента, егоцели (зачем он использует систему или какие услуги он предоставляетсистеме).

Структура окружения системы представляется графически на такназываемой контекстной диаграмме (см. ниже).Список сценариев использования представляет собой краткое описаниекаждого сценария. Структура сценариев использования и отношения междуними представляются графически на диаграмме сценариев (см. ниже).Для описания сценариев использования на разных фазах разработкииспользуются различные формы представления.2.4. Процедура моделирования1) Выделить всех агентов, взаимодействующих с системой; составить списокагентов, составить текстовое описание каждого агента;2) Выделить все интерфейсы; составить описание каждого интерфейса;построить контекстную диаграмму;3) Для каждого агента выделить различные цели; составить списоксценариев;4) Для каждого сценария составить текстовое описание в соответствии сТабл.

1.175) Провести формальный анализ полученных сценариев, выделить общиечасти, определить абстрактные сценарии; определить отношения расширениямежду сценариями;6) Построить диаграмму сценариев.На фазе системного анализа производится более детальный анализсценариев в соответствии с Табл. 2.2.4.1. Описание сценариев использованияДля описания сценариев использования применяют унифицированныеформы. Форма первичного описания сценария приведена на Табл. 1. Такаяформа удобна на фазе анализа требований.

Детальная форма для описаниясценария использования приведена на Табл. 2. Такая форма удобна на фазеанализа системы. Формализация сценариев использования проводится наязыке диаграмм взаимодействия.Идентификатор: Например, UC_1Название должно отражать суть данного способаНазвание:использования системы с точки зрения пользователяСписок агентов: Внешние агенты, взаимодействующие с системой привыполнении данного сценария (обычно, один изагентов является основным)Зачем нужен данный сценарий; какие событияНазначение:инициируют данный сценарий; основные вариантыразвития сценария; что является результатом сценария.Обзор сценария объемом 3-5 строк текста.Детальное описание основной последовательностиОписание:событий, включая инициирующие события, и результатсценария.Альтернативы:Описание «вариаций» основной последовательности,почему они происходят, что является результатомсценария в каждом случае.Табл.

1. Первичная форма сценария использования18Например, UC_1Название должно отражать суть данного способаиспользования системы с точки зренияпользователяКраткое описание функциональности системы,Описание:определяемой данным сценариемПеречислитьвнешнихагентов(включаяАгенты:пассивных), которые участвуют в выполненииданного сценарияПеречислить условия, которые должны бытьПредусловия:выполнены для того, чтобы данный сценарий могсостояться. Можно ссылаться на другиесценарии, условия на систему или на агентов.Последовательность событий и реакцийКод:Требование: Событие:Реакция:Начинать с КодОписаниеОписание желаемойER_1требования(внешнего)реакции системы наданное событие, пособытия,например, «когда возможностисистема получает единственноесообщение X»действие.ER_2Идентификатор:Название:ER_nАльтернативыAER_x,КодГдеx требованияпринимаетзначение от1 до nЗавершающеедействие,котороедает окончательныйрезультат сценария и«закрывает»сценарийОписаниеРеакция системы насобытия, если оно событиеотличаетсяотсобытия в ER_xилиописаниеусловияТабл.

2. Детальная форма сценария использования19Глава 3. Архитектурные моделиАрхитектурная модель описывает структуру системы, не зависящую отконкретной среды реализации. Целью архитектурного анализа являетсяобнаружение логической структуры системы, такой, что она будетустойчивой и надежной, удобной для сопровождения и последующегорасширения.Архитектурная модель описывает систему с трех точек зрения:информация, поведение и представление. Информационная точка зренияописывает информацию, находящуюся в системе, т.е.

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

Такой подход являетсяхарактерным для функциональной декомпозиции, когда функцииразмещаются вдоль оси поведения, а данные - вдоль оси информации.Однако при таком подходе к проектированию мы получим структуру,неустойчивую к изменениям: изменение информации, в большинствеслучаев, является причиной изменения поведения. Таким образом, было быжелательно, чтобы объекты могли объединять в себе и поведенческие, иинформационные аспекты, а в некоторых случаях и презентационныеаспекты.Большинство объектно-ориентированных методов анализа используютнекоторый единственный универсальный тип объекта, который можетиспользоваться в любой области пространства. Однако и такой подход негарантирует устойчивость системы к изменениям архитектурных моделей.Для достижения большей устойчивости к изменениям, мы будемрассматривать стратегию, использующую объекты трех различных типов.Архитектурная модель описывает систему с помощью объектов трех типов:интерфейсные объекты, информационные объекты и управляющие объекты.Каждый тип объектов охватывает два, или все три измерения, однако,каждый тип объекта моделирует определенную точку зрения.Информационные объекты моделируют данные, время жизни которыхобычно больше времени жизни соответствующего сценария использования.Все поведение, связанное с такого рода данными, должно быть определено в20самих информационных объектах.