Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Все лекции по системам реального времени.pdf
Скачиваний:
189
Добавлен:
02.05.2014
Размер:
8.11 Mб
Скачать

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

231

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

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

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

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

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

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

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

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

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

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

232

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

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

10.1.2. Разделение обязанностей между задачами и классами.

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

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

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

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

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

233

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

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

Составная задача инкапсулирует вложенные в нее объекты. Та-

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

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

10.1.3. Темпоральная группировка и объекты интерфейса уст-

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

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

Пример ввода/вывода с опросом приведен на рис.10.1. На диа- грамме кооперации из аналитической модели представлены два объ-

екта интерфейса устройства: Интерфейс Педали Тормоза и Интер-

фейс Двигателя (рис.10.la), которые следят за датчиками педали тор- моза и двигателя соответственно. Датчики опрашиваются периодиче- ски с одной и той же частотой.

С точки зрения разбиения на задачи объекты Интерфейс Педали Тормоза и Интерфейс Двигателя объединяются в задачу Автодатчи-

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

234

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

С точки зрения разбиения на классы создаются два разных клас-

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

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

Рассмотрим динамическое поведение, изображенное на рис. 10.1г. Задача Автодатчики периодически активизируется событием таймера. В этот момент объект-координатор Монитор Автодатчиков считывает текущие значения датчиков, вызывая операции Интер-

фейсДвигателя.читать (out состояния Двигателя) и ИнтерфейсПе- далиТормоза.читать (out состоянияТормоза). Если состояние како-

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

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

235

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

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

236

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

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

периодическими задачами ввода или темпорально сгруппированными периодическими задачами ввода/вывода. Кроме того, в этот класс до-

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

237

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

10.1.4. Группировка по управлению и объекты, скрывающие ин-

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

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

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

www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

238

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

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

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

фейс Устройства Печати Чеков и Интерфейс Устройства Выдачи Наличных. Объект Управление Банко-матом предоставляет операцию

обработать Событие, которая вызывается для обработки нового со- бытия и возвращает действие, подлежащее выполнению. Объект Ин-

терфейс Устройства Печати Чеков предоставляет операцию напе- чатать Чек, а объект Интерфейс Устройства Выдачи Наличных операцию выдать Наличные.

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

ми объектами

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

www.pdffactory.com

Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.

Оставленные комментарии видны всем.