АКТУАЛЬНОСТЬ И ПРЕСПЕКТИВЫ ИСПОЛЬЗОВАНИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА ПРИ ПРОЕКТИРОВАНИИ СЛОЖНЫХ ГИБКИХ СИСТЕМ УПРАВЛЕНИЯ.
Ямов С.И., Кабак И.С
(Москва, МГТУ "СТАНКИН")

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

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

        Все вышеизложенное требует новых подходов к проектированию. На данный момент наиболее перспективным можно считать объектно-ориентированный подход проектирования.
        К существенным отличиям объектно-ориентированного подхода от традиционного проектирования относят возможность использования итеративно-поступательного цикла создания программного обеспечения и перенос акцента проектирования с разработки алгоритмов функционирования системы на построения системы абстракций и их взаимодействия.
        При создании программных систем для реализации, полученной с помощью объектно-ориентированного подхода проектирования модели необходим такой язык программирования, который бы поддерживал объектно-ориентированную идеологию. Страуструп определил это так: “если термин “объектно-ориентированный язык” что-то означает, то он должен означать язык, имеющий все необходимые средства для обеспечения объектно-ориентированного стиля программирования... Обеспечение такого стиля в свою очередь означает наличие соглашений по реализации стиля программирования. Если написание программ в стиле объектно-ориентированного программирования требует специальных усилий или оно невозможно совсем, то этот язык не отвечает требованиям объектно-ориентированного программирования”. С++, SmallTalk, CLOS, Eiffel, Object Pascal, J++ являются представителями объектно-ориентированных языков программирования.
        Объектно-ориентированный подход рассматривает проектирование как процесс создания ряда последовательность опирающихся друг на друга абстракций.
        Предлагаются следующие возможные этапы абстрагирования при создании программной модели управляющей системы. На первом этапе имеем физическую модель компонентов системы и их взаимодействия, а также совокупность формализованных алгоритмов управления. Далее целесообразно разделить алгоритмы управления, реализуемые на прикладном уровне и аппаратно. На данном этапе появляется интерфейс между аппаратными средствами и прикладной частью системы. Появление этого уровня обусловлено наличием специальных аппаратных средств по сопряжению "внешних" устройств.
        Следующим шагом может быть описание свойств внешних объектов на прикладном уровне. Имеется несколько альтернатив моделирования. В простом случае, когда внешние устройства легко представляемы как один неделимый объект управления, алгоритмы управления могут напрямую учитывать поведенческие характеристики внешнего объекта управления. Только относительно простые системы могут быть описаны вышеуказанным методом. Часто систему можно представить как совокупность взаимодействующих самостоятельных подсистем. Они могут состоять из одного или нескольких управляемых устройств, датчиков (в том числе и обратной связи), но с точки зрения решаемых задач управления - это логически неделимые объекты. Можно учитывать все необходимые для управления свойства выделенных подсистем, создав между нижним уровнем (программно-аппаратным интерфейсом) и прикладным уровнем прослойку из объектов, отражающих свойства реальных подсистем. В сложной системе объекты могут образовывать иерархию, где с повышением уровня иерархии повышается и уровень обобщенности отображения системы. Соответственно, объекты более высокого уровня отвечают за реализацию более обобщенных алгоритмов управления и за отражение более обобщенных характеристик системы.
        Такой подход дает возможность использования всех возможностей объектно-ориентированного анализа и проектирования системы. Сама система становится более гибкой. Описав и закрепив семантику интерфейса каждого объекта можно с наименьшими потерями отражать изменения в организации внешних подсистем. Преимуществом такого подхода является также расширяемость системы в целом. Объект, являющийся верхом некоторой иерархии может быть перенесен со всей иерархией в подуровень более обобщенной системы, став ее частью. Заметим, что для разработчика объект, отражающий некоторую часть иерархии системы, может иметь сложную внутреннюю структуру, быть составным и содержать вложенные объекты, но с точки зрения верхних уровней он является компонентом. Его внутренняя структура скрыта от них.

art12_1.gif (6286 bytes)

        Проектирование рассматривается как последовательное отражение уровней абстракции создаваемой системы управления на программную модель. Каждый уровень представляет собой совокупность объектов. Эти объекты образуют иерархии при повышении уровня общности.
        При создании модели сложной системы можно выделить три укрупненных уровня: во-первых уровень программно-аппаратной поддержки; во-вторых уровень управления подсистемами; в-третьих, информационный уровень. Назначение уровня программно-аппаратной поддержки интуитивно понятно; уровень управления подсистемами - совокупность подуровней, содержащих объекты, отображающие некоторые внешние подсистемы; информационный уровень - уровень объектов, предназначенный для управления потоками информации между верхними объектами иерархий на уровне управления подсистемами и/или системами сбора и обработки информации.
        Границы этих уровней весьма размыты, однако уровень управления подсистемами отличается повышенной оперативностью и, как правило, предъявляет особые требования к надежности в отличие от информационного уровня. В различных системах тот или иной уровень может отсутствовать или быть вырожденным. Дпя системы управления станка с ЧПУ модель, не рассчитанной на последующее подключение в локальную сеть информационный уровень отсутствует также как для тривиальной системы управления финансами программно-аппаратный уровень. Важно, что из-за отличий в требованиях, предъявляемых к программному обеспечению, отражающих разные уровни, может отличаться и подход, и средства разработки.
        Простым и привычным подходом к созданию управляющей системы является описание всех объектов и их окружения в одной управляющей программе. Однако предлагаемая методология проектирования системы с трудом укладывается в этот подход. Упаковка всей управляющей иерархии в одну программу становится серьезным барьером на пути к достижению высокого уровня гибкости системы и ее распределенности. А именно эти требования необходимы для многих типов систем; интеллектуальных и распределенных систем управления, крупных информационных систем.
        Стремление сконцентрировать управление в одной управляющей программе может сильно усложнить разработку, а иногда и делает ее невозможной. Целесообразно, оговорив интерфейсы взаимодействия, создавать независимые и интерпортабельные программные единицы, являющиеся компонентами программной системы, причем эти же компоненты могут быть распределенными. На данный момент существует две технологии, отвечающих данным принципам.
        С апреля 1989 года функционирует группа OMG (Object Management Group), в состав которой входит на данный момент более 400 организаций. Цель OMG состояла в создании распределенной объектной системы которая позволила бы совместно использовать объекты, реализованные на разных объектно-ориентированных языках программирования, и которая работала бы при этом на любой неоднородной сети компьютеров под управлением различных операционных систем. Результатом ее деятельности явилось создание обзора по архитектуре управления объектами ОМА (Object Management Architecture). ОМА представляет собой полный набор рекомендаций по разработке распределенных объектных систем, среди которых основной является архитектура СОRВА. СОRВА решает базовые вопросы взаимодействия объектов, операционных систем, сетевых протоколов и т.п. СОRВА содержит описание своей собственной объектной модели. Согласно этой объектной модели объекты могут посылать и принимать сообщения от других объектов и при этом изменять свое внутреннее состояние. Интерфейс объекта полностью отделен от его реализации, причем объектная модель имеет дело только с интерфейсами объектов. Такое решение позволило полностью абстрагироваться от конкретного языка реализации объектов. Интерфейсы объектов определяются на языке описания интерфейсов IDL (Interface Definition Landuage), в котором реализуются основные понятия объектно-ориентированного подхода: инкапсуляция, наследование и полиморфизм.
        Технология ОLЕ является реализацией модели "клиент-сервер". Появление ОLЕ явилось следствием развития объектно-ориентированного программирования и связано с тем, что возникла необходимость во взаимодействии приложений на уровне объектов. ОLЕ является основанием, на котором строятся объекты. Эта аббревиатура означала первоначально связывание и внедрение объектов (Object Linking and Embedding), однако с выпуском версии ОLЕ 2 представление об ОLЕ изменилось. Сейчас ОLЕ представляет собой целый набор технологий, среди которых:

  • унифицированную передачу данных;
  • структурированное хранилище информации;
  • автоматизацию (набор интерфейсов, позволяющий использовать приложение в качестве ОLЕ-объекта);
  • динамические запросы о структуре объектов, позволяющие определять наличие методов и атрибутов объекта на стадии выполнения.
  • 0LE 2 построено на протоколе Lightweight Remote Procedure Calls (LRPC), т.е. облегченный удаленный вызов процедур. LRPС подобен своему аналогу из UNIX - RPC (Remote Procedure Calls, удаленный вызов процедур), так как и тот и другой протокол позволяют передавать информацию между приложениями. LRРС, по сравнению с RРС, является "облегченным" (Lightweight), поскольку он ограничен пересылкой информации внутри одной машины. Распределенное ОLЕ (Distributed OLE) – другая версия ОLЕ, использующая RРС, а не LRРС, что позволяет объектам пересекать границы между машинами.

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

ЛИТЕРАТУРА:

  1. Гради Буч, Объектно-ориентированное проектирование с примерами применения, // Киев: Диалектика, Москва, И.В.К. 1992г.
  2. Страуструп Б. Язык программирования С++, "ДиаСофт”, Киев 1993г.
  3. Кабак И.С., Интерактивный объектно-ориентированный подход к построению систем управления. Тезисы докладов Международной конференции "Информационные средства и технологии", М., 1996г.
  4. Гейсарян С.С., Объектно-ориентированный подход к разработке корпоративных информационных систем, М., 1996г.