Разбиение приложения на задачи на этапе проектирования подсистем

Каждая из этих деятельностей является кандидатом на выделение в самостоятельную задачу. Но более внимательный анализ показывает, что они не могут выполняться параллельно, так как принадлежат различным состояниям объекта Круиз-Контроль: деятельность Разгон выполняется в состоянии Разгон, деятельность Крейсер - в состоянии Крейсерский Режим, а деятельность Возобновление - в состоянии Возобновление. Поэтому все три деятельности являются взаимно исключающими, и помещать их в разные задачи нет смысла. Вместо этого мы сопоставим им всего одну задачу Корректировка Скорости, применив критерий группировки по взаимному исключению (рис.8.13а и 8.136).

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

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

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

Ниже описываются три вида инверсии задач: инверсия нескольких экземпляров задачи, инверсия последовательных задач и темпоральная инверсия.

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

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

В качестве примера рассмотрим систему управления лифтами. Здесь каждый объект Управление Лифтом отображается на отдельную задачу с тем же именем. Если накладные расходы все же оказываются слишком высокими, в системе разрешается оставить только одну задачу Управление Лифтом и завести для каждого лифта свой пассивный сущностный объект Информация о Состоянии Лифта (рис.8.14). В таком случае главной процедурой задачи будет диспетчер, который считывает входную информацию для задачи, решает, для какого лифта она предназначена, и использует соответствующий этому лифту сущностный объект.

Рис.14. Пример инверсии нескольких экземпляров задачи

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

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

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

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

Рассмотрим пример темпоральной инверсии задач. На рис.8.16 показано, как две периодические задачи, уже подвергнутые темпоральной группировке, - Автодатчики и Калибровка - из соображений оптимизации объединяются в инвертированную задачу Периодически. Эта задача время от времени активизируется событием таймера и опрашивает состояние датчиков (педали тормоза и двигателя), а также проверяет калибровку, но с разной частотой. При каждом вызове она решает, что следует сделать: прочитать входную информацию от датчиков, калибровочную информацию или и то, и другое. В первом случае, если состояние изменилось, выводится сообщение запрос Круиз-Контролю. Во втором обновляется объект Калибровочная Константа.

Рис. 15. Пример инверсии последовательных задач:

а - обмен сообщениями между задачами; б - инвертированная задача

Рис.16. Пример темпоральной инверсии задач: а - периодическая задача с темпоральной группировкой; б - инвертированная периодическая задача

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

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

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

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

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

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

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

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

Рассмотрим начальную параллельную диаграмму кооперации (рис.8.18а), на которой изображена задача Интерфейс Ручки Круиз-Контроля, посылающая сообщение задаче Круиз-Контроль. Представим этот интерфейс в виде слабо связанного обмена сообщениями (рис.8.186). Задача Интерфейс Ручки Круиз-Контроля отправляет сообщение и не ждет, пока оно будет принято задачей Круиз-Контроль, что позволяет первой задаче быстро обслуживать все поступающие данные. Слабо связанный обмен предоставляет широкие возможности и задаче Круиз-Контроль, поскольку она в состоянии извлекать из очереди сообщения, поступающие из разных источников.

Пример слабо связанного обмена сообщениями в системе управления лифтами приведен на рис.8.4, где показана задача мониторинга ресурсов Интерфейс Лампочки Этажа. Эта задача принимает запросы на выключение лампочки от разных лифтов. Запросы помещаются в FIFO-очередь. Задача Интерфейс Лампочки Этажа обрабатывает запросы в порядке поступления.

Рис. 17. Архитектура задач: пример начальной диаграммы параллельной кооперации для подсистемы Банкомат

Рис. 18. Пример слабо связанного (асинхронного) обмена сообщениями: а - начальная диаграмма параллельной кооперации с простым сообщением; б - пересмотренная диаграмма параллельной кооперации с асинхронным сообщением

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

Рис. 19. Пример сильно связанного (синхронного) обмена сообщениями с ответом: а - начальная диаграмма параллельной кооперации с простыми сообщениями; б - пересмотренная диаграмма параллельной кооперации (синхронное сообщение с ответом)

В сильно связанном обмене с ответом может участвовать один производитель и один потребитель, в этом случае между ними не образуется очереди. Но вероятны и несколько клиентов, взаимодействующих с одним сервером (рис.8.19). Здесь клиентами являются задачи Банкомат, которые посылают сообщения задаче Банковский Сервер, что изображено на начальной диаграмме кооперации (рис.8.19а). Каждый клиент должен быть сильно связан с сервером, поскольку он ждет ответа на посланное сообщение. Получив сообщение, сервер обрабатывает его, готовит ответ и отправляет клиенту. Нотация сильно связанного обмена сообщениями без ответа на диаграмме параллельной кооперации (рис.8.196) показывает синхронное сообщение от клиента к серверу и простое сообщение, соответствующее ответу сервера.

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

Пример сильно связанного обмена сообщениями без ответа приведен на рис. 20. Интерфейс Дисплея Статистики Датчиков - это пассивная задача вывода. Она принимает сообщение, подлежащее выводу на дисплей, от задачи Алгоритм Статистики Датчиков (рис.8.20а). Затем она показывает статистику, а задача-алгоритм тем временем рассчитывает следующий набор значений. Таким образом, вычисления и вывод совмещаются.

Задача-производитель Алгоритм Статистики Датчиков посылает статистику температуры и давления задаче-потребителю Интерфейс Дисплея Статистики Датчиков, которая выводит эту информацию на монитор. В данном примере нет смысла вычислять статистику, если потребитель не успевает выводить ее. Следовательно, интерфейс между двумя задачами превращается в сильно связанный обмен сообщениями без ответа, что и показано на пересмотренной диаграмме кооперации на рис.8.206. Алгоритм Статистики Датчиков считает статистику, посылает сообщение, ждет, пока задача вывода примет его, после чего продолжает выполнение. Таким образом, первая задача ничего не делает, пока вторая не закончит выводить на дисплей предыдущее сообщение. Как только задача Интерфейс Дисплея Статистики Датчиков примет новое сообщение, Алгоритм Статистики Датчиков прерывает ожидание и переходит в состояние готовности к работе. Таким образом, вычисление статистики (расчетная задача) и ее вывод (задача ввода/вывода) могут быть совмещены во времени без образования ненужной очереди к задаче вывода. Кроме того, сильно связанный обмен сообщениями между двумя задачами способен «притормаживать» задачу-производителя.

Рис. 20. Пример сильно связанного (синхронного) обмена сообщениями без ответа: а - начальная диаграмма параллельной кооперации с простыми сообщениями; б - пересмотренная диаграмма параллельной кооперации (синхронное сообщение без ответа)

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

Типичный пример внешнего события - аппаратное прерывание от устройства ввода - приведен на рис.8.21. На начальной диаграмме кооперации ввод от устройства представлен в виде простого сообщения (рис.8.21а). «Асинхронное устройство ввода» Ручка Круиз-Контроля генерирует прерывание, когда у устройства есть данные. Это прерывание активизирует задачу Интерфейс Ручки Круиз-Контроля, помеченную стереотипом «асинхронный интерфейс устройства ввода», которая читает сообщение ввод от Круиз-Контроля. Такое взаимодействие можно изобразить в виде события ввода от устройства, за которым следует считывание. Однако правильнее было бы представить его в виде асинхронного события, посылаемого устройством, для которого входные данные являются параметрами. Именно так и сделано на пересмотренной диаграмме параллельной кооперации.

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

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

Рис. 21. Пример внешнего события: а - начальная диаграмма параллельной кооперации с простыми сообщениями; б - пересмотренная диаграмма параллельной кооперации с внешними сообщениями

Взаимодействие задач с помощью скрывающего информацию объекта. Задачи могут обмениваться данными также с помощью пассивного скрывающего информацию объекта. Пример доступа к такому объекту приведен на рис.8.24, где задача Алгоритм Статистики Датчиков считывает данные из сущностного объекта Хранилище Показаний Счетчика, а задача Интерфейс Датчика обновляет этот объект. На начальной диаграмме параллельной кооперации задача Алгоритм Статистики Датчиков посылает простое сообщение Читать сущностному объекту и получает в ответ Показания Датчика, тоже изображенные в виде простого сообщения (рис.8.24а). Поскольку задача считывает данные из пассивного объекта, этот интерфейс соответствует вызову операции. Сущностный объект предоставляет операцию читать, которая и вызывается задачей Алгоритм Статистики Датчиков. Ответ показанияДатчика является выходным параметром вызова.

Рис. 22. Пример события таймера: а - начальная диаграмма параллельной кооперации с простыми сообщениями; б - пересмотренная диаграмма параллельной кооперации с событием таймера

Рис. 23. Пример внутренних событий: а - начальная диаграмма параллельной кооперации с простыми сообщениями; б - пересмотренная диаграмма параллельной кооперации с внешними событиями

Рис. 24. Пример задач, вызывающих операции пассивного объекта: а - начальная диаграмма параллельной кооперации с простыми сообщениями; б - пересмотренная диаграмма параллельной кооперации с задачами, вызывающими операции пассивного объекта

Операция читать вызывается в потоке управления такой задачи. На пересмотренной диаграмме параллельной кооперации (рис.8.246) вызов операции читать показан с помощью нотации синхронного сообщения. Ответ показания Датчика представлен в виде параметра этого сообщения. Задача Интерфейс Датчика вызывает операцию писать, предоставляемую сущностным объектом Хранилище Показаний Счетчика, передавая ей показания Датчика в качестве параметра.

В нотации синхронных сообщений важно понимать разницу между двумя параллельными задачами и между задачей и пассивным объектом. В UML они обозначаются одинаково: закрашенной стрелкой, однако семантика совершенно различна. Нотация синхронных сообщений между параллельными задачами описывает сильно связанный обмен сообщениями, как показано на рис.8.19 и 8.20; нотация синхронных сообщений между задачей и пассивным объектом служит для представления операции вызова (рис.8.24).

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

Рис. 25. Архитектура задач: пример пересмотренной диаграммы параллельной кооперации для подсистемы Банкомат

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

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

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

СПЗ определяется следующим образом:

* интерфейс задачи. Сюда должны включаться:

- входные и выходные сообщения. Для каждого сообщения необходимо указать:

- тип интерфейса (слабо связанный, сильно связанный с ответом, сильно связанный без ответа), имя и параметры;

- события (входные и выходные):

- имя события;

- тип события (внешнее, внутреннее, таймера);

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

- используемые пассивные объекты;

* информация о структуре задачи включает:

- критерий, примененный для выделения этой задачи;

- объекты из аналитической модели, отображенные на эту задачу;

* временные характеристики:

- частота активизации. Для периодической задачи - ее период Тi для асинхронной задачи - ожидаемая средняя и максимальная частота активизации асинхронными событиями;

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

* относительный приоритет задачи. Задаче назначается приоритет относительно других исполняемых в системе задач;

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

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

Пример спецификации поведения для задачи «Банковский Сервер». СПЗ для задачи Банковский Сервер (показанной на рис.8.24), выглядит следующим образом.

Задача: Банковский Сервер.