Языки программирования / Книги / ob''ektno-orientirovannyj_analiz_i_proektirovanie

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

Далее, определим класс Keypad следующим образом:

class Keypad { public:

Keypad();

~Keypad();

int inputPending() const; Key lastKeyPress() const;

protected:

...

};

Протокол для данного класса уже был в основном определен в процессе анализа. Мы добавили лишь операцию inputPending; это сделано для того, чтобы клиент мог узнать, есть ли новая, еще не обработанная команда пользователя.

Класс InputManager имеет во многом аналогичный интерфейс:

class InputManager { public:

InputManager(Keypad&);

~InputManager();

void processKeyPress();

protected: Keypad& repKeypad; };

Как мы увидим, поведение этого класса почти исчерпывающе описывается конечным автоматом.

Рис. 8-13 иллюстрирует взаимодействие классов Sampler, InputManager и Keypad по обработке пользовательских команд. Чтобы интегрировать их, надо несколько видоизменить интерфейс класса Sampler, включив в его описание новый объект repInputManager:

class Sampler { public:

Sampler(Sensor&, DisplayManager&, inputManager&);

...

protected:

Sensors& repSensors; DisplayManager& repDisplayManager; InputManager& replnputManager;

};

Теперь связь между экземплярами классов Sensors, DisplayManager и InputManager устанавливается в момент создания объекта класса Sampler. Использование ссылок гарантирует, что каждый экземпляр Sampler получит соответствующий набор датчиков, менеджера экрана и менеджера ввода. Другая схема, в которой вместо ссылок

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

Ключевую функцию Sampler::sample надо модифицировать следующим образом:

void Sampler::sample(Tick t)

{

repInputManager.processKeyPress();

for (SensorName name = Direction; name <= Pressure; name++) for (unsigned int id = 0; id < repSensors.numberOfSensors(name); id++)

if (!(t % samplingRate(name))) repDisplayManager.display(repSensors.sensor (name, id));

}

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

Для конечных автоматов с относительно небольшим числом состояний, к числу которых принадлежит и класс InputManager, достаточно использовать второй подход. Сначала определим имена объемлющих состояний класса:

enum InputState {Running, Selecting, Calibrating, Mode);

Затем определим некоторые защищенные функции класса:

class InputManager { public:

...

protected:

Keypads repKeypad; InputState repState; void enterSelecting(); void enterCalibrating(); void enterMode();

};

И, наконец, начнем реализовывать переходы между состояниями (см. рис. 8-11):

void InputManager::process Keypress() {

if (repKeypad.inputPending()) {

Key key = repKeypad.lastKeyPress(); switch (repState) {

case Running:

if (key == kSelect) enterSelecting();

else if (key == kCalibrate) enterCalibrating();

else if (key == kMode) enterMode();

break;

case Selecting: break; case Mode: break;

}

}

}

Таким образом, реализация данной функции отражает содержание диаграммы переходов межу состояниями на рис. 8-11.

8.4. Сопровождение

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

Видно, что система позволяет измерять многие погодные параметры, однако не все. Может оказаться, что пользователи захотят измерять также количество осадков. Какие изменения при этом необходимо будет внести в программу?

К счастью, нам не придется радикально менять нашу архитектуру, надо будет лишь дополнить ее. Используя в качестве основы архитектурный макет, представленный на рис. 8-13, можно выделить следующие необходимые изменения:

•Создание нового класса-датчика RainFallSensor (датчика осадков); выявление его оптимального положения в иерархии датчиков (RainFallSensor есть разновидность

HistoricalSensor).

•Обновление перечисления SensorName.

•Модификация класса DisplayManager, обеспечивающая вывод на экран параметров, снимаемых с датчика нового типа.

•Модификация класса InputManager, обеспечивающая обработку нажатия новой клавиши RainFall.

•Правильное включение экземпляров класса RainFallSensor в коллекцию Sensors.

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

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

•Создание нового класса SerialPort, ответственного за управление последовательным портом RS232.

•Разработка нового класса ReportManager, ответственного за подготовку информации к записи в определенном формате. Этот класс в основном использует ресурсы класса-коллекции Sensors и ассоциированных с ним конкретных датчиков.

•Изменение реализации функции Sampler::sample, дополнительно обеспечивающее периодическое обслуживание последовательного порта.

Признак хорошо продуманной объектно-ориентированной архитектуры - изменения не разрушают ее, а расширяют, сохраняя существующие механизмы.

Дополнительная литература

Проблемы синхронизации процессов, тупиков, конфликтов и т. п. подробно обсуждаются в работах Хансена (Hansen) [H 1977], Бен-Ари (Ben-Ari) [H 1982] и Холта и др. (Holt et al.) [H 1978]. Мелличамп (Mellichamp) [H 1983], Гласе (Glass) [H 1983] и Фостер (Foster) [H 1981] являются традиционными ссылками по вопросам разработки приложении реального времени. Параллельность с точки зрения взаимодействия аппаратуры и программы обсуждает Лорин (Lorin) [H 1972].

Глава 9

Среда разработки: библиотека базовых классов

Основным преимуществом объектно-ориентированных языков программирования, таких, как C++ и Smalltalk, является высокая степень повторного использования в хорошо спроектированных системах. Это означает, что для разработки каждого следующего приложения требуется гораздо меньше нового кода; следовательно, меньшее количество кода требуется сопровождать и поддерживать.

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

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

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

9.1. Анализ

Определение границ проблемной области

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