The instrumental tool for designing of object-oriented models of complex systems.pdf Объектно-ориентированные представления, в частностиунифицированный язык моделирования UML (Unified ModelingLanguage) [1], широко используются для построения мо-делей сложных систем - как правило, на этапах концептуаль-ного и логического проектирования информационных системдля структурированного описания автоматизируемой пред-метной области. Чаще всего модели предназначены для ви-зуализации и документирования существующего состояниясистемы (модель «As-is») или желаемого состояния (модель«To-be») как предварительного шага в процессе разработкипрограммного обеспечения. Однако возможности объектныхязыков моделирования не исчерпываются только описатель-ными средствами. Механизм включения в объектное описа-ние процедур (так называемых методов), способных изменятьсостояния объектов, позволяет осуществлять поиск решенийна модели. Множество атрибутов, описывающих класс неко-торой компоненты системы, при этом рассматривается какпространство поиска экземпляра класса, соответствующегооптимальному варианту реализации компоненты.В данной статье рассматривается инструментальный ком-плекс, предназначенный для построения объектно-ориенти-рованных моделей сложных систем и выработки оптималь-ных проектных решений на моделях. Данный комплекс явля-ется автоматизированным средством поддержки информаци-онной технологии проектирования социально-экономическихсистем для разрешения сложных многофакторных проблем-ных ситуаций [2−5]. В основе данной технологии лежит объ-ектно-ориентированная методология моделирования, главнойособенностью которой является возможность объединять раз-личные методики системного анализа и инженерии знаний набазе декларативной модели, формируемой с использованиемэкспертных знаний, описывающих типовые свойства, струк-туры и закономерности отдельных классов систем. Объектно-ориентированный язык моделирования предоставляет следу-ющие важные преимущества: возможность комплексированиядекларативногосистема, элемент, комплексное свойство. Будем пола-гать, что описание компоненты вариативно, т.е. можетотражать различные состояния или варианты реализа-ции компоненты, однако структура описания (шаблон)инвариантна. Структура, определяющая состав атрибу-тов и методов, задается с помощью класса, сопостав-ляемого компоненте. На основе класса формируютсяэкземпляры (объекты), содержащие конкретные значе-ния атрибутов.Модель классов включает множество классов C = { ci },на котором определено отношение наследования (inheritance)Rin C C. Класс представляет собой кортеж( ) ( ) { } ( ) ( ) , | j , i , i ,inci = n ci n c j ciR c A c P cгде ( ) n ci - имя класса; { n( ci ) } - множество имен клас-сов, от которых наследуется данный класс; ( ) { } A ci = am -множество атрибутов класса, включающее подмноже-ства наследуемых и новых атрибутов; ( ) P ci - множе-ство методов класса, включающее подмножества на-следуемых, перекрытых и новых методов.Каждый из атрибутов задается тройкой( ) ( ) ( ), , , m m m m a D a t a n a =где ( ) n am - имя атрибута; ( ) t am - тип атрибута(, , , , …);( ) { } D am = dk - множество значений (домен) атрибута.Домен задается в зависимости от типа атрибута. На-пример, для атрибута типа или - в видеинтервала, для атрибута типа - в виде спискастрок, для атрибута типа - в виде имени объек-та. Посредством атрибутов типа в описаниеобъекта может включаться описание другого объекта.Например, атрибуты подсистемы могут содержать ссыл-ки на объекты, описывающие элементы данной подсис-темы или некоторые комплексные свойства, которыесами описываются множеством собственных атрибутов.Множество методов класса содержит обязательное под-множество методов доступа к значениям атрибутов, ко-торые могут быть двух типов: get - метод получениязначения и set - метод задания значения.Для работы с классами модель классов должна со-держать собственные методы (присоединенные проце-дуры), которые можно разделить на две основныхгруппы: методы наследования, позволяющие создаватьновые классы на базе имеющихся классов; методыобобщения, позволяющие автоматически или в диало-говом режиме формировать иерархию наследованияклассов.Основу модели вариантов реализации компонентсоставляет дерево компонент сложной системы. Обо-значим множество компонент через K = { kn} . Из мно-жества компонент выделим подмножество подсистемS  K , на котором определено отношение агрегации (aggregation)Rag  S  S . Это отношение типа «часть−целое»(«Part-of»). Множество подсистем, связанных отноше-ниями агрегации, представляет собой дерево подсис-тем. Дерево, как правило, формируется путем последо-вательной декомпозиции подсистем.Среди множества компонент будем выделять такжеподмножество элементов E  K . При этом под эле-ментом будем понимать активные и пассивные сущно-сти, участвующие в деятельности подсистемы (напри-мер, конечные продукты, предметы деятельности,средства деятельности, исполнители) или комплексныесвойства, описываемые набором характеристик (на-пример, технологические параметры, экономическиерезультаты, технические условия и т.д.). Элемент мо-жет «присоединяться» к подсистеме или к другомуэлементу посредством указания ссылки на объект, со-поставленный присоединяемому элементу, в качествезначения одного из атрибутов объекта присоединяю-щей компоненты. Таким образом, объектное описаниеприсоединяемой компоненты дополняет описание при-соединяющей компоненты, т.е. является его частью.Обозначим отношение присоединения (connection) че-рез Rcn K  K . На рис. 2 представлено дерево компо-нент сложной системы.Рис. 2. Дерево компонент сложной системыКаждой компоненте сопоставляется класс, на базекоторого формируется один или несколько экземпля-ров класса (объектов), содержащих конкретные значе-ния атрибутов, дополненные факторами уверенности:ok = n( ok ) , c( ok) , { dk( am) / cf( dk( am) ) } ,где ( ) n ok - имя объекта; ( ) c ok - указатель на класс,на базе которого реализован объект; ( ) ( ) dk am  D am −значение атрибута; ( ( ) )[0; 1] cf dk am - фактор уве-ренности в значении атрибута, принимающий значениев интервале от 0 (полная недостоверность) до 1 (абсо-лютная достоверность). Если фактор уверенности неуказан, по умолчанию он считается равным единице.Для отражения множества вариантов или состоянийкомпоненты (например, в различные моменты времени,в различных точках пространства, в различных услови-ях) используется мультиобъект - набор экземпляров,выделенных в соответствии с некоторым признаком p:( i ) { k k ( ) , ( k ) i } ( i ) .Op c = o o = o p c o = c  O cВ качестве признака выступает заданный ключевойатрибут или комбинация нескольких ключевых атрибу-тов. Каждому значению признака соответствует свойэкземпляр. Различают три основных типа базовых при-знаков - время, пространство и группа (population). Отних могут наследоваться конкретные признаки.Поскольку объект однозначно идентифицируетсязначениями ключевых атрибутов, обращение к нему осу-ществляется указанием после имени, общего для всехобъектов, в скобках этих значений. Отдельный объектможно рассматривать как вырожденный мультиобъект,мощность множества которого равна единице. На рис.3 представлен пример мультиобъекта.Рис. 3. Пример мультиобъектаВ состав множества методов модели вариантов реа-лизации компонент могут быть включены следующиегруппы методов: методы создания и редактированиядерева подсистем и присоединенных элементов; мето-ды создания и редактирования мультиобъектов; пере-борные методы генерации мультиобъектов (в частно-сти метод морфологического анализа); методы поискаобъектов по заданному шаблону поиска; методы выво-да закономерностей на множестве объектов и т.д.Модель зависимостей атрибутов включает множе-ство отношений функциональной зависимости (functionaldependence) между атрибутами, описывающимикомпоненты системы: : ( ) . ... ⎟⎠⎞⎜⎝⎛ =    UiiR fd A A A A c Каж-дое такое отношение связывает некоторый атрибут-функцию a0 с множеством атрибутов-аргументов a1, …,:( 1,..., ) 0. a a a R fdan n Закономерность, показывающая, какименно значение атрибута-функции определяется зна-чениями атрибутов-аргументов, представляется сово-купностью правил-продукций Rlk вида:Rlk :( d ( a1) Dk( a1) )&...&( d ( an) Dk( an) )( d ( a0)= fk( a1,..., an) ) / cf ( Rlk ) ,где ( ) d am - текущее значение атрибута am; ( )  Dk am( )  D am - допустимая область атрибута am; ( ) fk a1,..., an -функция, представленная либо в виде конкретного зна-чения, либо в виде формулы, либо в виде некоторойпроцедуры-функции; ( )[0, 1] cf Rlk - фактор уверен-ности правила. Правило имеет смысл: «ЕСЛИ атрибутa1 принимает значение из области ( ) Dk a1 … И атрибутan принимает значение из области Dk( an) , ТО атрибутa0 принимает значение функции ( )fk a1,..., an с уверен-ностью ( ) cf RLk ».Допустимые области значений в условной частиправил для атрибутов с текстовыми значениями зада-ются перечислением значений, для количественныхпараметров - в виде интервалов. Если на значение ат-рибута не накладывается никаких ограничений (атри-бут может принимать любое значение), то вместо до-пустимой области указывается пробел. Формула в за-ключении правила задается только для количественныхатрибутов (типа Integer, Real) и может включать теку-щие значения атрибутов-аргументов, константы, знакиарифметических операций и математических функцийи т.д. Процедура-функция может задаваться для атри-бутов любого типа. Она может иметь в составе вход-ных параметров текущие значения атрибутов-аргумен-тов и должна возвращать значение определяемого ат-рибута.Графически совокупность функциональных отно-шений можно представить в виде направленной сетибез циклов, вершинами которой являются атрибуты, адугами - функциональные зависимости между атрибу-тами (рис.4). В истоках сети располагаются независи-мые атрибуты, значения которых разработчик можетнепосредственно задавать, в стоках - целевые атрибу-ты, к которым относятся показатели эффективности икачества моделируемой компоненты системы.Рис. 4. Сеть отношений функциональной зависимостиВ модели зависимостей атрибутов отношениефункциональной зависимости задается в виде объектастандартного класса «FuncDependence», содержащегоимя атрибута-функции, список имен атрибутов-аргу-ментов, а ссылку на мультиобъект − с правилами-про-дукциями, описывающими закономерность.Множество методов модели зависимостей атрибутоввключает две основные группы: методы формированиясети зависимостей и задания закономерностей; методыпоиска решений, в том числе методы прямого и обратноговывода на модели функциональных отношений [7].СТРУКТУРА ИНСТРУМЕНТАЛЬНОГОСРЕДСТВА ENGINE 2.0Основными принципами реализации комплекса Engine2.0. являются: языковая независимость реализацииотдельных компонент; открытая архитектура, позво-ляющая интегрировать различные приложения, удоб-ство пользовательского интерфейса.Программный комплекс включает в себя три базо-вых модуля (рис. 5): «Project (Проект)», «Register (Ме-неджер регистрации)» и «Work space manager (Менед-жер рабочей области)».Модуль «Project» является основным, отражающиммодель (совокупность моделей) предметной области, соз-даваемую пользователем. Он состоит из множества, такназываемых узлов (Project node), соответствующим от-дельным видам моделей. Стандартными узлами проектаявляются: узел классов (classes), узел деревьев мульти-объектов подсистем (subsystems objects), узел зависимо-стей атрибутов (attributes net). Кроме того, пользовательможет определить собственные виды узлов проекта.ApplicationInitalize ()Uninitalize ()OpenProject ()SaveProject ()NameApplicationProjectNodesProjectInitalize ()Uninitalize ()LoadFromStorage ()SaveToStorage ()MenuRegisterToolbarsRegisterToolformsRegister…RegisterInitalize ()Uninitalize ()Work space manager1NameDescriptionProjectProject nodeInitalize ()Uninitalize ()LoadFromStorage ()SaveToStorage ()10..*Classes managerInitalizeClassesNode ()Uninitalize ()LoadFromStorage ()SaveToStorage ()111111Storage InfoFileNameXMLNodeMenu register11Toolbars register1ClassManagerAttributesMethodsEngine classInitalize ()Uninitalize ()LoadFromStorage ()SaveToStorage ()Рис. 5. Диаграмма классов Engine 2.0Узел проекта включает множество элементов фор-мируемой с его помощью модели и менеджер узла, по-зволяющий создавать соответствующую модель, запи-сывать ее в хранилище, загружать сохраненную ранеемодель из хранилища и т.д. Так, узел классов содержитмножество элементов типа «Engine class», описываю-щих классы компонент моделируемой сложной систе-мы. С помощью менеджера классов пользователь мо-жет создавать новые классы, редактировать сущест-вующие и т.д. Менеджеры узлов обеспечивают воз-можность визуального представления проектируемойсистемы в виде различных диаграмм (иерархии классов,дерева подсистем и элементов, сети зависимостей атрибу-тов). Все стандартные узлы имеют однотипный пользова-тельский интерфейс, что значительно упрощает и ускоря-ет процесс обучения пользователя работе с системой.Результаты проектирования системы могут бытьсохранены в хранилище в виде файлов формата XML.Каждый из узлов для обмена информацией с хранили-щем использует модуль «Storage Info», содержащиймножество узлов «XML Node» для записи (чтения) ин-формации об отдельных элементах модели.Любой узел реализуется в виде COM-библиотеки,содержащей некоторый набор обязательных объектов сопределенными интерфейсами (меню, панелью инст-рументов, компонентами, формами и т.д.). Пользовате-лю предоставляется возможность замены любого узлана альтернативный, а также возможность добавленияновых программ. Для того чтобы интегрировать новуюбиблиотеку с Engine 2.0, ее необходимо зарегистриро-вать. Для регистрации используется менеджер регист-рации «Register». В его состав входят модули, осуще-ствляющие регистрацию отдельных элементов интер-фейса, таких, как меню, панели инструментов и т.д.Модуль «Work space manager» обеспечивает взаи-модействие всех модулей системы.ЗАКЛЮЧЕНИЕИнструментальный комплекс Engine 2.0. предостав-ляет непрограммирующему пользователю удобныесредства для создания моделей проектируемых слож-ных систем и поиска решений на моделях. Для генери-рования вариантов компонент системы, их оценки ивыбора могут быть использованы традиционные мето-ды системного анализа и теории принятия решений,такие, как морфологический анализ, методы одно- имногокритериального выбора и др., адаптированные кобъектно-ориентированному описанию системы, атакже методы инженерии знаний, в частности методынечеткого логического вывода на множестве правил-продукций.Разработчик модели может использовать типовыеклассы для описания свойств и характеристик системы,а также экспертные знания о зависимостях между ха-рактеристиками. В то же время он легко может попол-нять, корректировать состав атрибутов, изменять пра-вила определения их значений. Декларативное заданиезависимостей позволяет легко изменять вид зависимо-стей, не меняя методы, их обрабатывающие.Комплекс был использован для формирования ре-гиональной программы повышения энергетическойэффективности на территории Томской области, а так-же для создания системы выбора инвестиционных про-ектов разработки нефтегазовых месторождений.

Скачать электронную версию публикации