Объектно-ориентированное проектирование на основе эталонных моделей

Внедрение компьютерных технологий в разнообразные сферы человеческой деятельности привело к необходимости создания больших и сложных программных систем. В ходе их разработки выявился ряд крупных недостатков, присущих традиционным методологиям проектирования программного обеспечения. Осмысление этих недостатков и путей их преодоления привело к созданию в начале 80-х гг. парадигмы объектно-ориентированного программирования (ООП), которая сегодня занимает лидирующее положение в информатике. Вместе с тем, эффективность применения ООП на практике все еще продолжает оставаться крайне низкой [1]. На мой взгляд, это происходит из-за недостатка практических методик проектирования, предусматривающих "прямое" использование приемов ООП в реализуемых проектах. Известно, что практическое применение какой-либо методологии требует ее конкретизации относительно области приложения. В частности, ООП может с успехом использоваться в автоматизированном управлении.

Суть предлагаемого подхода к проектированию заключается в использовании в качестве концептуального каркаса проекта структурообразующей модели - базовой структуры, которая состоит из набора программных объектов и объединяющих их бинарных базовых отношений [2]. Данный подход позволяет унифицировать проектные решения в рамках систем определенного класса, установить рациональный порядок их принятия и начинать проектирование не с "нуля", а с некоторого исходного "каркаса" проекта. Для этого необходима концептуальная модель проекта, которая выстраивается путем формализации характерных для систем определенного класса содержательных понятий и связывания их набором отношений в единое целое. Такая формализация базируется на результатах анализа ряда программных систем, в ходе которого "вынесятся за скобки" их характерные общие свойства и понятия. С этой точки зрения базовая структура - это средство компактного представления знаний об особенностях построения программного обеспечения систем определенного класса. В теории открытых систем такие модели называются эталонными [3]. Таким образом, предлагаемый подход представляет собой реализацию методологии открытых систем в конкретной области.

Использование базовой структуры позволяет существенно облегчить решение основной задачи объектно-ориентированного проектирования [4]: помогает определить состав программных объектов и правила их взаимодействия. Очевидно, что для сложной системы эта задача должна решаться поэтапно. Сначала нужно определить состав и взаимодействие небольшого набора объектов, охватывающих основные понятия рассматриваемой предметной области. Рассмотрим пример использования подхода к проектированию ПО автоматизированной системы управления реального времени (АСУ РВ) [5], ее структура и описание особенностей функционирования приведены на рис. 1.

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

Для определения элементов базовой структуры рассмотрим обобщенный алгоритм работы КСА ПУ и определим основных его "исполнителей", которые в дальнейшем будут представлены как базовые объекты. Выделим на структурной схеме типовое звено: комплекс средств автоматизации пункта управления (КСА ПУ), и его непосредственное окружение - взаимодействующие КСА ПУ, сопряженные источники информации (ИИ) и объекты управления (ОУ). Несмотря на различия реализации и характеристик в рамках каждой конкретной АСУ "поведение" программного обеспечения КСА ПУ можно представить следующим образом.

Информация о состоянии окружающей среды (в первую очередь о состоянии ОО и ОУ), поступающая от различных ИИ через каналы связи и АПД, принимается в вычислительном комплексе (ВК). Затем она приводится к единообразной внутренней форме (унификации), передается компонентам содержательной обработки. Главным результатом обработки поступающей информации является модель состояния среды, характеризующая ситуацию управления в каждый момент времени и обновляемая динамически по мере прихода новых данных. На основе этой модели формируется поток сообщений, включающий в себя управляющие воздействия для ОУ и информацию о текущем состоянии среды управления, которые передаются по каналам связи на соответствующие объекты АСУ. Кроме того, модель состояния в удобной для восприятия форме отображается на видеомониторах АРМ операторов ПУ, которые осуществляют визуальный контроль ситуации и при необходимости могут активно вмешаться в процесс управления путем ввода соответствующих директив. Возможная базовая структура программного обеспечения КСА, позволяющая решить эти задачи управления путем взаимодействия входящих в нее объектов, представлена на рис. 2 (линиями обозначены двусторонние отношения между объектами, типа "поставщик - получатель").

Объекты "АПД и системные устройства" / DCE (Data Communication Equipment) представляют в ПО аппаратуру передачи данных (АПД), через которую осуществляется взаимодействие (прием и передача сообщений) с сопрягаемыми изделиями. Кроме того, в семейство DCE входят объекты - программные драйверы другой, несколько отличной от АПД, аппаратуры, выполняющей логически сходные функции - прием и передача данных от некоторых источников. Такой аппаратурой могут быть различные контроллеры и подключенные к ним устройства. Основной функцией объектов DCE является прием сообщений, поступающих от аппаратуры, и передача их соответствующим программным объектам, восприятие сообщений от программных объектов для передачи и пересылка их в аппаратуру, а также управление работой аппаратуры.

Каждый программный объект "сопрягаемые объекты"/Unit представляет собой программную модель удаленного реального объекта - элемента АСУ (ОУ, ИИ, ОО, ПУ), а также некоторых устройств КСА. Основной функцией Unit является интерпретация принятых от "своего" объекта сообщений, формирование на их основе некоторых внутренних данных и их последующая передача соответствующим программным объектам (DP, Terminal и т.д.), восприятие от этих объектов результатов их работы, относящихся к представляемому элементу АСУ и формирование на основе этих результатов соответствующих сообщений для передачи. Для сложных объектов характерно также наличие некоторого внутреннего состояния объекта, влияющего на его поведение. Объект "Обработка данных"/ DP ( Data Processing) предназначен для выполнения различного вида обработки поступающей информации: первичной, вторичной и любой другой, определяемой спецификой ПУ и АСУ в целом. Кроме того, в состав объекта в виде набора внутренних объектов входит упомянутая модель состояния среды управления.

Объекты класса "АРМ"/Terminal обеспечивают интерфейс с оператором АРМ ПУ. В их функции входит отображение информации, поступающей от других программных объектов на экране видеомонитора, а также восприятие управляющих воздействий оператора и передача их соответствующим объектам.

Уместно привести некоторые постулаты, определившие общий подход к выбору базовых объектов:

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

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

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

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

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

Поведение объектов во времени определяется через взаимодействие процессов, "вложенных" в каждый базовый объект и отражающих специфику функционирования ПО в реальном времени. Таким образом, по терминологии Гради Буча [4] базовые объекты относятся к разряду активных объектов.

Предлагаемый подход был применен при проектировании программно-аппаратного комплекса обработки радиолокационной информации (РЛИ), предназначенного для использования в составе автоматизированной системы управления воздушным движением гражданской авиации. Комплекс имеет открытую архитектуру и построен на базе промышленных компьютеров на платформе Intel, объединенных в локальную вычислительную сеть Ethernet. В состав каждого компьютера кроме стандартных устройств включены электронные модули адаптеров АПД, обеспечивающие связь с соответствующей аппаратурой. Взаимодействие модулей адаптеров и центрального процессора осуществляется через шину VMEbus.

Комплекс функционирует под управлением операционной системы реального времени QNX 4.23. В качестве инструментального средства разработки программ на языках C/C++ используется среда программирования Watcom 10.6. Интерфейс пользователя комплекса реализован с помощью графических сред QNX Windows и Photon 1.12.

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

Класс DP не может похвалиться наличием большого количества потомков, однако он сильно разросся внутрь, инкапсулировав в себе всю сложность алгоритмов вторичной и третичной обработки РЛИ и структур обрабатываемых данных (модель воздушной обстановки, состоящую из отметок и трасс летательных аппаратов и т.п.).

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

Использование базовой структуры на практике дает ряд преимуществ. Несомненно, проектирование по определенным образцам существенно снижает трудоемкость. Говоря об образцах предложенной базовой структуры, следует отметить, что благодаря высокому уровню абстракции ее ключевых понятий она может с успехом использоваться при создании достаточно широкого класса АСУ. При этом механизм наследования классов допускает во многих ситуациях прямое повторное использование отлаженного программного кода, что сокращает сроки реализации новых проектов. Лишь в отдельных случаях, когда речь идет о создании не имеющих аналогов АСУ РВ, появляется необходимость в базовой структуре "нового типа". Последовательное применение подхода при проектировании программного обеспечения позволяет добиться "открытости" прикладной части ПО, непосредственно реализующей задачи предметной области АСУ и составляющую по объему и сложности "львиную долю" проекта. Это существенно упрощает проблему их модернизации.

Известно, что "жизненный цикл" АСУ РВ намного превышает продолжительность жизни коммерческих систем и исчисляется десятками лет. С другой стороны, прогресс в сфере развития средств вычислительной техники и средств связи, а также необходимость в расширении функциональных возможностей АСУ в целом и их отдельных компонентов неизбежно приводят к необходимости модернизации "на ходу", без приостановки серийного производства и эксплуатации систем. В этих условиях крайне важно иметь возможность дополнить систему новыми функциями по обработке информации, усовершенствовать реализованные ранее алгоритмы, обеспечить сопряжение со вновь разработанными компонентами, осуществить перенос программ на более современную вычислительную платформу, наконец, устранить выявленные в ходе эксплуатации ошибки с минимальными затратами сил и средств. Высокая самодостаточность объектов базовой структуры позволяет довольно легко распараллелить процессы их разработки во времени, разделив работу по их созданию между несколькими исполнителями.

В развитие данного подхода к проектированию представляется целесообразным использование базовой структуры как основы для построения профиля [6] АСУ РВ в части стандартизации структуры прикладной составляющей программного обеспечения. Несомненно, это требует дополнительных усилий по совершенствованию базовой структуры, в первую очередь, в направлении более глубокой формализации ее понятий. Однако есть основания полагать, что эти усилия с лихвой окупятся на практике.

Литература