Software & Systems

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

Рассмотрим стратегию проектирования ПО АСОУ, характеризующуюся: а) наличием объектной модели, полностью описывающей всю предметную область, причем прикладная обработка данных реализуется только на базе этой модели; б) полной изоляцией объектной модели от реляционной (в реализации классов исключены все операции работы с БД). Данная стратегия позволяет в полной мере реализовать все достоинства ООП [1,2] (многократное использование кода, распределение разработки, обеспечение эволюционного метода разработки и т.д.), а также обеспечить независимость ПО от используемой БД [3].

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

Рассмотрим основные моменты, связанные с использованием этой библиотеки. Ключевым элементом библиотеки является класс TBaseObject. При построении объектной модели каждая сущность предметной области должна быть описана предметным классом, унаследованным от TBaseObject. Каждый такой класс будет иметь целочисленное свойство Id, служащее для уникальной идентификации всех его объектов. Для представления полного множества объектов какого-либо предметного класса разрабатывается класс-коллекция, наследуемый от TRoleCollection, и соответствующий класс-контейнер, наследуемый от TRoleCollectionItem. Каждый объект класса-контейнера предназначен для хранения одного объекта соответствующего предметного класса и входит в объект класс-коллекция. Например, если TVehicle – это предметный класс для описания транспортных средств, тогда объект класса TVehicles, унаследованного от TRoleCollection, является коллекцией объектов TVehicle, то есть содержит множество контейнеров – объектов класса TVehicleItem, унаследованного от TRoleCollectionItem, в структуру которых входит объект TVehicle.

Унифицированный доступ к множеству всех коллекций объектов обеспечивается глобальным объектом класса TRoleCollectionsManager. Для этого для каждой коллекции TRoleCollection создается объект TRoleCollectionElement, среди прочего обеспечивающий ее автоматическую инициализацию при первом обращении к ней в программе. Важным применением TRoleCollectionsManager является реализация механизма ссылок на объекты предметных классов, реализуемого через разработку потомков TBaseObjectReference. Каждый потомок предназначен для поиска объектов одного из предметных классов по значению их свойств в соответствующей коллекции, доступ к которой обеспечивается через TRoleCollectionsManager.

Таким образом, построенная по этим принципам объектная модель предметной области будет состоять из множества коллекций TRoleCollection, каждая из которых является машинной реализацией либо некоторого сорта, либо функции (предиката) сигнатуры Σ логической модели. Для реализации функций (предикатов) используется следующая техника. Пусть TDrivers – коллекция, описывающая состав водителей транспортных средств, то есть содержащая объекты TDriverItem, каждый из которых имеет объект предметного класса TDriver. Тогда коллекция TDriverVehicles объектов предметного класса TDriverVehicle, содержащих ссылку на объект TDriver и объект TVehicle, реализует функцию f: Drivers®Vehicles, где Drivers – сорт, реализуемый TDrivers, а Vehicles – сорт, реализующий TVehicles. Очевидно, что формулы, которые должны быть истинными в любой структуре, интерпретирующей Σ, обнаруживают себя в реализации предметных классов.

Заметим, что реализация ПО на базе таких объектных моделей сопряжена с падением производительности программ при обработке больших объемов информации, свойственных АСОУ [3]. Действительно, в процессе выполнения программы в памяти формируются коллекции большой мощности, доступ к элементам которых (объектам предметных классов) требуется по различным комбинациям их свойств. В каждом конкретном случае возможно решение этой проблемы в индивидуальном порядке, однако в рассматриваемых условиях востребован унифицированный подход, который обеспечивается механизмом автоматического ведения произвольного числа индексов для коллекций. Данный механизм, в свою очередь, базируется на механизме уведомляющих свойств (notification properties) предметных классов. При каждом изменении такого свойства у некоторого объекта, хранящегося в коллекции, осуществляется информирование соответствующего контейнера этого объекта и далее самой коллекции, встроенные методы которой обеспечивают перестройку индекса, связанного с этим уведомляющим свойством. Каждый предметный класс может содержать произвольное число уведомляющих свойств, на подмножестве которых могут быть организованы индексы. По умолчанию для каждого предметного класса свойство Id является уведомляющим, а каждая коллекция имеет индекс по этому свойству.

Информация о составе уведомляющих свойств (TNotificationProperties) и индексах коллекций (TRcIndices) хранится в дескрипторах классов – объектах TClassDescriptor, множество которых управляется глобальным объектом TClassDescriptorsManager. Как следует из диаграммы, для каждого класса X, унаследованного от TBaseObject, TRoleCollection или TRoleCollectionItem, существует собственный дескриптор, создаваемый автоматически при порождении первого экземпляра класса X, что обеспечивается реализацией TBaseObject, TRoleCollection и TRoleCollectionItem. Последующая инициализация дескриптора для класса X обеспечивается вызовом виртуальных функций классов TBaseObject, TRoleCollection или TRoleCollectionItem, переопределяемых в X.

Упомянутая ранее инициализация коллекций обеспечивается механизмом синхронизации, предусматривающим разработку для каждого предметного класса синхронизатора – потомка TSerializer. Назначение синхронизаторов – загрузка объектов коллекции из БД и их обратная запись, то есть синхронизация объектной и реляционной моделей (таким образом механизм синхронизации обеспечивает требуемую изоляцию объектной модели от реляционной). Информация о синхронизаторе для каждого предметного класса также хранится в соответствующем дескрипторе.

Как уже упоминалось, в каждом предметном классе имеется свойство Id. В логику конструктора TBaseObject заложена автоматическая инициализация свойства Id, реализуемая на основе механизма

поставщиков идентификаторов. Каждый поставщик – это объект класса, унаследованного от TIdProvider и переопределяющего виртуальный метод getId (обеспечивает возврат очередного идентификатора). Логично, что поставщик идентификаторов должен иметь их централизованный источник. Одним из решений является использование глобального счетчика целых чисел, размещаемого в БД. Для борьбы с издержками, связанными с частым обращением за новыми идентификаторами к этому счетчику, целесообразно применять упреждающее резервирование их некоторого диапазона в начале выполнения программ и далее повторять это по мере надобности. Информация о поставщике идентификаторов для каждого предметного класса хранится в соответствующем дескрипторе.

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

Литература

1.   Грехэм И. Объектно-ориентированные методы. Принципы и практика. – М.: Изд-во «Вилльямс», 2004. – 880 с.

2.   Пуха Ю. Объектные технологии построения распределенных информационных систем. // Системы управления базами данных. – 1997. – № 3. – С. 4–20.

3.   Fowler M., Rice D. Patterns Of Enterprise Application Architecture. Addison Wesley, 2003. Р. 560.

4.   Искусственный интеллект. В 3-х кн. – Кн. 2. Модели и методы: Справочник. / Под ред. Д.А. Поспелова. – М.: Радио и связь, 1990. – 304 с.