Лекции - Часть 10 - файл n1.doc

Лекции - Часть 10
скачать (3401 kb.)
Доступные файлы (1):

3534kb.

01.09.2004 21:00

n1.doc

1 2 3 4 5

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

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

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

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. Пример темпоральной группировки и объектов интерфейса

1 2 3 4 5