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

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

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

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

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

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

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

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

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

www.pdffactory.com

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

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

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

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

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

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

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

www.pdffactory.com

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

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

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

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

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

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

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

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

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

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

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

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

www.pdffactory.com

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

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

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

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

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

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

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

www.pdffactory.com

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

www.pdffactory.com

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

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

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

www.pdffactory.com

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

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

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

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

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

www.pdffactory.com

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

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

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

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

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

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

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

ми объектами

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

www.pdffactory.com