 |
Порядковая нумерация сообщений
|
|
|
|
Сообщениям на диаграмме кооперации присваиваются порядковые номера
На диаграмме кооперации, соответствующей некоторому прецеденту, описывается последовательность участия объектов в этом прецеденте, что графически выражается с помощью порядковых номеров сообщений. Номер сообщения имеет вид:
[первая необязательная строка букв] [строка цифр] [вторая необязательная строка букв].
Пример: А1, где буква «А» обозначает прецедент, а цифра - порядковый номер сообщения на диаграмме кооперации, соответствующей данному прецеденту. Объект А1, посылающий первое сообщение, является инициатором кооперации. Для конкретного прецедента в роли инициатора должен выступать актер, хотя абстрактно это может быть произвольный объект.
1) [первая необязательная строка букв] - это необязательный идентификатор, обозначающий конкретный
или абстрактный прецедент. Первая буква строки должна быть
заглавной. За ней могут идти одна или несколько заглавных и строчных букв, если прецеденту желательно дать более содержательное имя;
2) [строка цифр]. Первый порядковый номер соответствует событию, которое инициирует
последовательность сообщений, изображенных на диаграмме кооперации. Типичные последовательности таковы: 1,2,3,...; Al, A2, A3,...; Usel, Use2, Use3
3) В интерактивной системе, где актер многократно вводит различные данные, полезно нумеровать внешние события целыми числами, отделяя от них точкой номера по
следующих внутренних событий. Например, событиям, инициированным актером, присваиваются номера А1,
А2, A3, а полная последовательность сообщений на диаграмме кооперации будет иметь вид Al, AI.I, А1.2, А1.3 А2, А2.1, А22.......................................................................................................... A3, А3.1, А3.2 и т.д.
|
|
|
Альтернативные последовательности сообщений изображаются с помощью условия, записанного после сообщения. Для именования альтернативных ветвей используются заглавные буквы. Например, главная ветвь помечена 1.4[Нормально], а другая, менее важная, -1.4А[Ошибка]. Порядковые номера сообщений на главной ветви обозначаются как 1.4[Нормально], 1.5,1.6 и т.д.; на альтернативной ветви - как 1.4А[Ошибка], 1.4А.1,1.4А.1 и т.д.
2.2 Описание последовательности сообщений
Описание последовательности сообщений разрабатывается как часть аналитической модели. В нем говорится, каким образом объекты аналитической модели участвуют в прецедентах. Это текст на естественном языке, повествующий о том, что происходит, когда сообщение приходит объекту-получателю на диаграмме кооперации или последовательности. В описании последовательности сообщений имеются ссылки на номера сообщений, присутствующие на диаграмме кооперации. В нем прослеживается порядок сообщений, посланных от отправителя получателю, и рассказывается о действиях получателя после прихода сообщения. Обычно такое описание дает дополнительную информацию, которой нет на диаграмме кооперации объектов. Например, для каждого доступа к сущностному объекту здесь могут предлагаться сведения о том, какие атрибуты объекта запрашиваются.
ЗДинамический анализ
Аналитик разрабатывает прецедент, выявляя последовательность взаимодействий (внешних событий) между актером и системой. В динамической модели этот прецедент уточняется путем рассмотрения участвующих в нем объектов и очередности внутренних событий, возникающих в результате прихода внешнего события.
Динамический анализ (его также называют анализом поведения) - это стратегия, позволяющая разобраться в том, как объекты, представленные в аналитической модели, взаимодействуют между собой в различных прецедентах. Динамический анализ выполняется для каждого прецедента. Он начинается с рассмотрения внешнего события, поступающего интерфейсному объекту, после чего прослеживается вся цепочка внутренних событий вплоть до конечного отклика системы. При возникновении внутренних событий происходит обмен сообщениями между объектами-участниками прецедента. В прецеденте может быть описана последовательность внешних событий, например несколько взаимодействий с актером. В таком случае следует определить цепочки внутренних событий, вызванных каждым внешним. События в последовательности нумеруются и представляются на диаграмме кооперации. Сообщение состоит из события и ассоциированных с ним данных.
|
|
|
Методика, основанная на динамическом анализе, итеративная. На первой итерации выявляют объекты, участвующие в прецеденте, применяя критерии разбиения на объекты. Затем определяют, как эти объекты кооперируются друг с другом для выполнения прецедента В ходе анализа иногда приходится задавать дополнительные объекты или взаимодействия.
Динамический анализ может быть зависящим или не зависящим от состояния - это определяется тем,
есть ли зависимость от состояния 8 самом прецеденте.
4Динамический анализ, не зависящий от состояния На основе прецедента делается первая попытка выявить участвующие в нем объекты. Должен быть по меньшей мере один объект интерфейса, который получает входные данные от актера. Как правило, присутствует несколько сущностных объектов, где содержится информация, срок хранения которой больше, чем время исполнения данного прецедента. Несложные прецеденты могут этим и ограничиваться. Например, в простой системе клиент-сервер прецедент состоит из клиента, реализующего интерфейс пользователя, который взаимодействует с сервером -сущностным объектом. В более сложных прецедентах, где есть несколько объектов, обычно возникает потребность еще и в управленцем объекте, который координирует взаимодействие остальных объектов. Например, управляющий объект способен координировать выборку информации из нескольких сущностных объектов и ее обработку до предъявления актеру с помощью объекта пользовательского интерфейса
|
|
|
Не зависящий от состояния управляющий объект, например координатор или объект таймера, необходим в тех случаях, когда нужно то или иное согласование действий или принятие решений. Сущностный объект применяется для хранения и выборки информации.
В случае периодических видов деятельности, в частности для генерации отчетов, требуется вводить в рассмотрение объекты таймеров, которые активизируются событиями таймера, в результате чего система генерирует определенную выходную информацию. При этом некоторый объект должен подготовить данные (например, отчет) и послать его интерфейсному объекту для вывода во внешнюю среду.
Стратегия выполнения не зависящего от состояния динамического анализа состоит в том, чтобы начать с прецедента и рассмотреть по отдельности каждое взаимодействие между главным актером и системой. Актер начинает взаимодействие с помощью некоторого внешнего события. Последовательность генерируемых актером внешних событий описана в прецеденте. В простых прецедентах может быть всего одно взаимодействие (внешнее событие), в более сложных -несколько.
Если речь идет о периодической деятельности, то время от времени активизируется объект таймера. Он заставляет сущностный объект или объект-алгоритм выполнить необходимую деятельность. В периодическом прецеденте внешний таймер является актером, а объект таймера - управляющим объектом. 6 Динамический анализ, зависящий от состояния
В данном случае речь идет о взаимодействиях между объектами, которые участвуют в прецеденте, зависящем от состояния: выходные данные, получаемые актером, зависят не только от входных данных, но и от того, что происходило в системе раньше. В прецеденте, зависящем от состояния, имеется зависящий от состояния управляющий объект, который исполняет свою диаграмму состояний, управляя тем самым последовательностью событий. В сложных прецедентах таких объектов обычно несколько, и у каждого есть своя диаграмма состояний.
6.1 Определение объектов и взаимодействий
Цель динамического анализа, зависящего от состояния, - определить взаимодействия между
|
|
|
следующими объектами:
-зависящий от состояния управляющий объект, который исполняет диаграмму состояний;
-объекты (обычно интерфейсные), которые посылают сообщения управляющему объекту, вызывая тем
самым переходы состояний;
-объекты, представляющие действия и деятельности, которые запускаются управляющим объектом в
результате переходов состояний;
-прочие объекты, принимающие участие в прецеденте.
Взаимодействия между всеми этими объектами изображаются на диаграмме кооперации или последовательности. По результатам анализа в ранее разработанные диаграммы состояний вносятся изменения.
Сообщение состоит из события и ассоциированных с ним данных. Рассмотрим отношение между сообщениями и событиями в случае зависящего от состояния управляющего объекта, который исполняет некоторую диаграмму состояний. Когда такой объект получает сообщение, событие, которое является его частью, вызывает переход состояний. Выполняемое в результате действие соответствует выходному событию, изображенному на диаграмме кооперации. В общем случае, говоря о сообщениях, мы имеем в виду диаграммы взаимодействия (кооперации или последовательности), а говоря о событиях - диаграммы состояний. Однако при описании динамического сценария с зависимостью от состояния мы будем употреблять термин «событие». Объект-отправитель посылает событие управляющему объекту, зависящему от состояния. Поступление входного события вызывает переход состояний. В результате этого перехода генерируется одно или несколько выходных событий, каждое из которых управляющий объект посылает тому или иному объекту-получателю. Выходное событие на диаграмме состояний изображается в виде действия (при переходе состояния, при входе или при выходе) либо начальной или завершающей деятельности.
Основные шаги динамического анализа, зависящего от состояния, таковы:
1.Определите интерфейсные объекты. Для этого выясните, какие объекты получают входные данные от
актера
2.Укажите зависящий от состояния управляющий объект. Существует хотя бы один управляющий объект, который исполняет некоторую диаграмму состояний, но могут потребоваться и дополнительные.
3.Задайте прочие внутренние объекты. Речь идет о внутренних объектах, которые взаимодействуют с
управляющими или интерфейсными объектами.
критерии разбиения на подсистемы. Разработка для каждой подсистемы диаграмм кооперации, а также высокоуровневой диаграммы кооперации для системы в целом.
3.3. Проектирование архитектуры программы, основанной на распределенных компонентах. Для распределенных приложений разбиение на распределенные подсистемах происходит на основе критериев распределенности. Требуется также определить интерфейс между компонентами системы на основе обмена сообщениями. Такой шаг необходим только при проектировании распределенных приложений.
|
|
|
3.4. Проектирование архитектуры параллельных задач для каждой подсистемы, Этот шаг включает:
3.4.1.Разбиение подсистемы на параллельные задачи путем применения соответствующих критериев декомпозиции.
3.4.2.Определение задач и их интерфейсов.
3.4.3.Разработка для каждой подсистемы диаграмм параллельных коопераций, на которых изображаются
задачи и их интерфейсы.
3.4.4. Документирование проекта каждой задачи в виде спецификации поведения задачи.
3.5. Анализ производительности проекта. Применение метода планирования в реальном времени для определения того, отвечает ли проект требованиям, предъявляемым к производительности. При необходимости можно несколько раз повторить шаги 3.3 и 3.4. Подобный шаг нужен только при проектировании приложений реального времени.
З.б.Проектирование классов в каждой подсистеме. Разработка интерфейсов классов, в том числе и всех их операций, а также иерархий наследования. Для приложений,
нуждающихся в базе данных, необходимо создать структуру базы данных и классы-обертки (эти вопросы затрагиваются в настоящей книге очень кратко). Для каждого класса требуется спецификация интерфейса
3.7.Разработка детального проекта каждой подсистемы, в том числе:
3.7.1.Создание внутренней структуры составных задач, которые содержат вложенные пассивные объекты.
3.7.2.Уточнение деталей механизмов синхронизации для объектов, к которым возможен доступ со стороны
нескольких задач.
3.7.3.Выделение классов-разъемов, инкапсулирующих детали межзадачной коммуникации.
3.7.4.Выявление и документирование внутренней для каждой задачи логики возникновения и обработки
событий.
3.8. Более детальный анализ производительности каждой подсистемы приложения реального
времени. Если необходимо, можно повторить шаги 3.4-3.7. Этот шаг нужен только при проектировании приложений реального времени.
|
|
|
