Введение. 
Проектирование составных задач

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

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

Проектирование составных задач

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

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

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

Поскольку операции класса проектируются по-разному в зависимости от способа доступа к нему, важно четко определить контекст, в котором может использоваться класс. Эту информацию следует документировать в разделе «Предположения» спецификации класса.

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

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

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

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

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

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

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

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

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

Пример ввода/вывода с опросом приведен на рис. 10.1. На диаграмме кооперации из аналитической модели представлены два объекта интерфейса устройства: Интерфейс Педали Тормоза и Интерфейс Двигателя (рис. 10.la), которые следят за датчиками педали тормоза и двигателя соответственно. Датчики опрашиваются периодически с одной и той же частотой.

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

С точки зрения разбиения на классы создаются два разных класса интерфейса устройства для датчиков педали тормоза и двигателя (рис. 10.1в). Каждый класс поддерживает две операции. Для датчика двигателя это операции читать (out состояниеДвигателя) и инициализировать, а для педали тормоза — читать (out состояниеТормоза) и инициали-зировать.

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

Рассмотрим динамическое поведение, изображенное на рис. 10.1г. Задача Автодатчики периодически активизируется событием таймера. В этот момент объект-координатор Монитор Автодатчиков считывает текущие значения датчиков, вызывая операции ИнтерфейсДвигателя. читать (out состояния Двигателя) и ИнтерфейсПедалиТормоза. читать (out состоянияТормоза). Если состояние какого-либо датчика изменилось, то задаче Круиз-Контроль посылается сообщение (или два сообщения), содержащее новые значения.

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

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

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

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

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

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

С точки зрения разбиения на задачи зависящий от состояния управляющий объект Управление Банкоматом представляет собой управляющую задачу, так как исполняет диаграмму состояний строго последовательно. Такая задача выполняет в своем потоке управления и другие операции (зависящие от состояния действия) в соответствии с критерием группировки по управлению. На рис. 10.26 изображена сгруппированная по управлению задача Контроллер Банкомата.

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

Рис. 4. Пример задачи, сгруппированной по управлению, с пассивными объектами: г — задача, сгруппированная по управлению, с вложенными пассивными объектами

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