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

Размещено на http://www.allbest.ru/

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

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

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

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

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

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

2. Категории критериев разбиения на задачи

Критерии разбиения на задачи можно отнести к нескольким категориям по признаку участия в процессе структурирования:

- критерии выделения задач ввода/вывода. Касаются отображения объектов интерфейса устройств на задачи ввода/вывода и вопроса о моменте активизации таких задач;

- критерии выделения внутренних задач. Связаны с тем, как внутренние объекты отображаются на внутренние задачи и как эти задачи активизируются;

- критерии назначения приоритетов задачам. Позволяют определить относительную важность каждой задачи;

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

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

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

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

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

3. Критерии выделения задач ввода/вывода

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

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

- характеристики устройств ввода/вывода. Важно понять, является устройство асинхронным (активным) или пассивным. Вот три основных класса устройств ввода/вывода:

* асинхронные устройства ввода/вывода (иногда их называют также активными), работающие по прерываниям. Когда асинхронное устройство ввода получает данные для обработки, оно генерирует прерывание. Асинхронное же устройство вывода генерирует прерывание, когда заканчивает операцию вывода и готово к приему новых данных;

* пассивные устройства ввода/вывода. Пассивное устройство не генерирует прерываний при завершении операции. Чтобы узнать, есть ли информация у пассивного устройства ввода, его надо периодически опрашивать. Соответственно перед отправкой данных пассивному устройству вывода надо убедиться, что оно готово принять их;

* канал связи. Некоторые управляемые микропроцессорами устройства ввода/вывода и внешние системы подключаются с помощью канала связи. Порядок обмена данными между системами определяется коммуникационным протоколом (например, TCP/IP). На прикладном уровне задачи, принадлежащие разным системам, обмениваются сообщениями.

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

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

- частота опроса. Если пассивное устройство ввода/вывода приходится периодически опрашивать, необходимо определить частоту опроса. Она зависит от того, насколько критичны входные данные и как интенсивно они могут изменяться.

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

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

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

Асинхронная задача интерфейса с устройством ввода/вывода - это задача драйвера устройства. Как правило, она активизируется низкоуровневым обработчиком прерывания, а иногда непосредственно устройством.

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

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

Периодические задачи интерфейса с устройством ввода/вывода. Если асинхронная задача интерфейса с устройством ввода/вывода работает с асинхронным устройством, то периодическая задача имеет дело с пассивным устройством, которое необходимо время от времени опрашивать. В этой ситуации задача активизируется периодически, но ее функции связаны с вводом/выводом.

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

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

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

Периодические задачи интерфейса с датчиками

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

В качестве примера рассмотрим объект Интерфейс Двигателя, показанный на рис.8.2а. На диаграмме кооперации из аналитической модели объект Интерфейс Двигателя, являющийся «интерфейсом устройства ввода», принимает данные от объекта Двигатель, изображенного со стереотипом «внешнее устройство ввода». Поскольку двигатель - это пассивное устройство, то на диаграмме параллельной кооперации он имеет стереотип «пассивное устройство ввода» (рис.8.26). Двигатель не генерирует прерываний, так что использовать асинхронную, задачу для интерфейса с ним нельзя. Поэтому применяется периодическая задача интерфейса с устройством ввода, которая регулярно (по событию таймера) опрашивает датчик двигателя. Следовательно, объект Интерфейс Двигателя отображен на задачу Интерфейс Двигателя, имеющую стереотип «периодический интерфейс устройства ввода». Для активизации этой задачи необходимо добавить объект Тактовый Генератор со стереотипом «внешний таймер» (рис.8.26). При активизации задача Интерфейс Двигателя опрашивает датчик двигателя и, если его состояние изменилось, выводит сообщение двигатель Включен или двигатель Выключен задаче-потребителю, после чего ожидает следующего события таймера.

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

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

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

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

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

Пример монитора ресурсов приведен на рис.8.4. Интерфейс Лампочки Этажа - это объект интерфейса устройства вывода, который получает запросы от нескольких экземпляров объекта Управление Лифтом с указанием погасить лампочку на данном этаже (рис.8.4а). Лампочка - это пассивное устройство вывода. Поскольку оно получает запросы из разных источников, то объект Интерфейс Лампочки Этажа устроен как задача-монитор ресурса, которая координирует все поступающие запросы (рис.8.46). Описанная задача изображена на диаграмме параллельной кооперации со стереотипом «монитор ресурса».

4. Критерии выделения внутренних задач

Если критерии выделения задач ввода/вывода применяются для определения задач ввода/вывода, то критерии выделения внутренних задач помогут выявить внутренние задачи, не связанные с вводом/выводом.

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

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

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

В качестве примера рассмотрим объект Таймер Пути, показанный на рис.5а. Он активизируется событием таймера и просит объект Путь вычислить пройденное машиной расстояние. Объект Путь сначала считывает показания счетчика оборотов вала и значения калибровочной константы, а затем вычисляет полный пройденный путь. Объект Таймер Пути отображается на периодическую задачу (рис.8.56), которая при каждой активизации запрашивает у объекта Путь пройденное машиной расстояние. Задача Таймер Пути изображена на диаграмме параллельной кооперации со стереотипом «периодическая». Объекты Путь, Счетчик Оборотов Вала и Калибровочная Константа являются пассивными.

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

Пример управляющей задачи приведен на рис.8.7. Зависящий от состояния управляющий объект Круиз-Контроль (рис.8.7а), который исполняет диаграмму состояний Круиз-Контроль, оформлен в виде отдельной одноименной задачи (рис.8.76), так как исполнение диаграммы строго последовательное. Эта задача изображена на параллельной диаграмме состояний со стереотипом «управление».

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

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

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

Рис. 8. Пример нескольких однотипных управляющих задач:

а - аналитическая модель (управляющий объект, несколько экземпляров); б - проектная модель (однотипные управляющие задачи)

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

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

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

В многооконной графической среде дежурный оператор может одновременно наблюдать за состоянием производства (это окно поддерживается одной задачей) и подтверждать прием тревожных сигналов (за такое окно отвечает другая задача) - рис.8.9в. Здесь присутствуют две задачи интерфейса пользователя: Окно Состояния Производства и Окно Тревожных Сигналов. Задача Окно Состояния Производства взаимодействует с пассивным объектом Хранилище Состояний Производства, а задача Окно Тревожных Сигналов - с пассивным объектом Хранилище Тревожных Сигналов.

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

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

Пример нескольких однотипных управляющих задач можно найти в системе управления лифтами (см. рис.8.8). Аспекты работы лифта, связанные с управлением, моделируются с помощью управляющего объекта Управление Лифтом и изображаются на последовательной диаграмме состояний. На этапе разбиения на задачи объект Управление Лифтом отображается на задачу Контроллер Лифта. В системе с несколькими лифтами имеется по одной такой задаче для каждого объекта Управление Лифтом. Эти задачи идентичны, и каждая исполняет экземпляр одной и той же диаграммы состояний. Однако, скорее всего, все лифты будут в любой момент времени находиться в разных состояниях.

5. Критерии назначения приоритетов задачам

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

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

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

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

Другие разновидности критических по времени задач - управляющие задачи и асинхронные задачи интерфейса с устройствами ввода/вывода. Управляющая задача исполняет некоторую диаграмму состояний и обязана работать с высоким приоритетом, поскольку переходы состояний должны производиться быстро. Асинхронной задаче ввода/вывода следует иметь высокий приоритет, чтобы успевать обслуживать прерывания, иначе есть риск пропустить одно из них. Примером высокоприоритетной асинхронной задачи интерфейса с устройством ввода служит задача Интерфейс Ручки Круиз-Контроля на рис.8.1.

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

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

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

6. Критерии группировки задач

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

Критерии группировки задач, или критерии слияния задач (task cohesion criteria), помогают установить, какие из задач, выявленных на первой стадии процесса разбиения на задачи, удобно объединить для уменьшения общего числа задач.

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

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

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

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

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

Пример темпоральной группировки

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

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

Теперь предположим, что оба датчика опрашиваются с одной и той же частотой, скажем каждые 100 мс. Тогда задачи Интерфейс Двигателя и Интерфейс Педали Тормоза можно сгруппировать в одну задачу Автодатчики, применив критерий темпоральной группировки (рис.8.106). Задача Автодатчики изображена на диаграмме параллельной кооперации со стереотипом «темпоральная группировка».

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

Рис. 10. Пример темпоральной группировки: а - периодические задачи ввода/вывода

- при включении в темпоральную группу предпочтение нужно отдавать тем задачам, которые функционально взаимосвязаны и одинаково важны с точки зрения планирования;

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

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

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

Если довести идею темпоральной группировки до абсурда, то получится задача, объединяющая все периодические операции. Такой подход напоминает метод циклического исполнителя, при этом получившуюся программу очень трудно сопровождать. Данный метод предполагает объединение всех периодических видов деятельности в одну задачу, так что различные периодические события активизируют разные операции. Для реализации требуется процедура-супервизор с периодом, равным наибольшему общему делителю периодов всех видов деятельности. При каждой активизации задачи супервизор должен решить, какую деятельность (или деятельности) выполнять. Например, если есть три операции с периодами 15, 20 и 25 мс, то объединенная задача должна иметь период 5 мс, что приводит к более высоким накладным расходам, чем для отдельных задач. Недостаток подобного подхода в том, что супервизор дублирует функции многозадачного ядра. Его применение приводит к увеличению сложности системы, а значит, и к росту затрат на сопровождение.

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

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

В качестве примера рассмотрим две задачи-кандидата, показанные на рис. 11a. Задача Генератор Отчетов активизируется периодически. Она считывает информацию из различных сущностных объектов, готовит отчет и посылает его задаче Интерфейс Дисплея для вывода. Задача Интерфейс Дисплея - это пассивная задача интерфейса с устройством вывода, предназначенным для вывода отчета. Если отчет генерируется редко, скажем раз в минуту, то нет смысла совмещать его генерацию и вывод.

В такой ситуации задачи Генератор Отчетов и Интерфейс Дисплея можно объединить в последовательную группу (рис. 8.116). Задача Генерация и Вывод Отчета изображена на диаграмме параллельной кооперации со стереотипом «последовательная группировка».

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

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

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

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

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

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

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

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

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

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

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

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

Пример группировки по управлению

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

На диаграмме состояний банкомата (рис.8.126) видно, что после отправки сообщения Выдать Наличные (событие 2 на рис.8.12а и 8.126) объект Управление Банкоматом переходит в состояние Выдача и ожидает ответа Наличные Выданы. Выйти из состояния Выдача можно только одним способом: получив ответ Наличные Выданы (событие 4) от объекта Интерфейс Устройства Выдачи Наличных. Поступление сообщения Выдать Наличные активизирует объект Интерфейс Устройства Выдачи Наличных, который выдает наличные (событие 3), посылает ответ Наличные Выданы (событие 4) и ждет следующего сообщения Выдать Наличные. Как видно из этого примера, объекты Управление Банкоматом и Интерфейс Устройства Выдачи Наличных не могут исполняться параллельно. Поэтому их допустимо сгруппировать по управлению в задачу Контроллер Банкомата. По той же причине объект Интерфейс Устройства Печати Чеков удобно сгруппировать с задачей Контроллер Банкомата.

Таким образом, зависящий от состояния управляющий объект Управление Банкоматом и объекты интерфейсов Устройство Выдачи Наличных и Устройство Печати Чеков группируются по управлению в одну задачу Контроллер Банкомата, которая помечена стереотипом «группировка по управлению» на диаграмме параллельной кооперации (рис.8.12в).

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

а - аналитическая модель (диаграмма кооперации)

б - проектная модель (диаграмма параллельной кооперации)

Рис. 13. Пример группировки по взаимному исключению