Последовательная группировка.

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

 

Группировка по управлению.

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

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

– зависящие от состояния действия, запускаемые управляющим объектом в момент перехода состояний.

– зависящие от состояния деятельности, которые начинаются или заканчи­ваются управляющим объектом в результате перехода состояний.

– зависящие от состояния деятельности, которые запускаются управляющим объектом в результате перехода состояний и исполняются, пока объект на­ходится в данном состоянии.

Группировка по взаимному исключению.

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

Пересмотр проекта путем инверсии задач

Идея инверсии задач впервые была сформулирована в методе структурного программирования Джексона и в системе разработки Джексона. Такая инверсия способствует уменьшению числа задач в системе. В предельном случае параллельное решение можно вообще свести к последовательному.

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

Существует три вида инверсии задач: инверсия нескольких экземпля­ров задачи, инверсия последовательных задач и темпоральная инверсия.

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

Разработка архитектуры задач

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

– задачи интерфейса с устройством. Начните с объектов интерфейса устройств, взаимодействующих с внешним миром.

– управляющие задачи. Рассмотрите все зависящие от состояния управляю­щие объекты. Отобразите их на управляющие задачи.

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

– другие внутренние задачи. Для каждой внутренней задачи, активизируемой внутренним событием, проверьте, нет ли среди соседних с ней задач на диа­грамме параллельной кооперации таких, которые можно объединить на ос­нове различных критериев группировки: последовательной, темпоральной или по взаимному исключению.

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

Коммуникации между задачами и синхронизация

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

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

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

Задачи могут обмениваться данными также с помощью пассивного скрываю­щего информацию объекта.

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

Спецификация поведения задачи

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

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

Проектирование классов

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