Входные параметры. идДатчика, значениеДатчика.

Выходные параметры. Нет.

Вызываемые операции. Нет.

4.читатьПривод (in идПривода,out значение Привода)

Функция. Читает новое значение привода для вывода во внешнюю среду.

Предусловие. Значение привода ранее было обновлено.

Инвариант. Значение привода не изменяется.

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

Входные параметры. идПривода.

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

Вызываемые операции. Нет.

10. Детальное проектирование по

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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