Главная | Обратная связь | Поможем написать вашу работу!
МегаЛекции

Объектно-ориентированное проектирование ЭИС. Метод COMET. Модель требований. Моделирование прецедентов.




COMET (Concurrent Object Modeling and Architectural Design Method) - это метод проектирования

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

Разработка модели требований

Определяются функциональные требования системы.

На этапе моделирования требований выполняются следующие шаги:

1. Разработка модели прецедентов, в том числе:

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

1 Документирование каждого прецедента в словесной форме.

В модели требований система рассматривается как черный ящик. Разрабатывается модель прецедентов:

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

прецедентов и актеров. Описания прецедентов дают картину поведения, характеристика отношений между ними - представление о структуре.

Моделирование прецедентов

Прецеденты

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

Актеры

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

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

Главный актер (primary actor) инициирует прецедент, то есть некоторые действия в системе. Другие актеры, называемые второстепенными (secondary actors), также могут участвовать в прецеденте, получая

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

Актер-человек использует для взаимодействия с системой различные внешние устройства ввода/вывода: стандартные (клавиатуру, дисплей или мышь) либо нестандартные (скажем, различные датчики). В любом случае актером является человек, а не эти устройства

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

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

Актеры, роли и пользователи

Актер - это роль в предметной области, которую обычно играет пользователь. Пользователь - это конкретная личность, тогда как актер - роль, которую играют все пользователи данного типа Например, в системе автоматизации производства есть три актера-человека: Дежурный Оператор, Инженер-Технолог и Начальник Производства Если один и тот же человек в состоянии играть несколько независимых ролей, то в каждой роли он представляется отдельным актером. Например, в разные моменты времени некто способен выступать в роли Начальника Производства или Дежурного Оператора, и для моделирования такой ситуации нужны два актера

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

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

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

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

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

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

Документирование прецедентов в модели прецедентов

Прецеденты документируются в модели следующим образом:

-имя прецедента Каждому прецеденту присваивается имя;

-сводка Краткое описание прецедента, обычно состоящее из одной-двух фраз;

-зависимости. Этот раздел необязателен, в нем указывается, зависит ли прецедент от других прецедентов, и если да, то каков характер зависимости: включение или расширение;

-актеры. В данном разделе именуются актеры, участвующие в прецеденте. Всегда существует главный актер, инициирующий прецедент. Кроме того, могут быть второстепенные актеры. Например, в прецеденте Снять Деньги актером является Клиент Банкомата;

-предусловия. Одно или несколько условий, которые должны быть истинными в начале прецедента В нашем примере банкомат должен быть свободен (в таком случае на его экране отображается сообщение «Добро пожаловать»)!

-описание. Основная часть документации прецедента - это словесное описание главной последовательности. Здесь перечисляются действия актера и реакция системы

на них. Система рассматривается как черный ящик: значение имеют ответы системы на действия актера а не ее внутреннее устройство;

-альтернативы. Словесное описание альтернативных ветвей. От главной последовательности может отходить несколько таких ветвей. Например, если на счете клиента недостаточно средств, то следует принести извинения и вернуть карточку;

-постусловие. Условие, которое должно быть истинным в конце прецедента, если исполнение шло по главной последовательности. Например, клиенту выданы наличные;

- неясные вопросы. Вопросы по поводу прецедента

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

Отношения прецедентов

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

Еще одно отношение между прецедентами, определенное в UML, - это обобщение/специализация. Обобщение прецедента сродни отношению расширения, поскольку оно также предназначено для работы с вариантами.

Отношение расширения

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

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

-чтобы показать условную часть базового прецедента (выполняемую только при соблюдении заданных

условий);

-чтобы промоделировать сложные или альтернативные пути.

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

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

Отношение включения

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

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

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

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

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

Пакеты прецедентов

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

Поделиться:





Воспользуйтесь поиском по сайту:



©2015 - 2024 megalektsii.ru Все авторские права принадлежат авторам лекционных материалов. Обратная связь с нами...