CC BY
15
Посилання на статтю_
Данич В.Н. Синтез объектных моделей информационно-управленческих архитектур/В.Н. Данич,М.К. Дёмин// Управлшня проектами та розвиток виробництва: Зб.наук.пр. - Луганськ: вид-во СНУ iм. В.Даля, 2007 - №4(24). С. 114-121._
УДК 004.65:330.47
В.Н. Данич, М.К. Дёмин
СИНТЕЗ ОБЪЕКТНЫХ МОДЕЛЕЙ ИНФОРМАЦИОННО-УПРАВЛЕНЧЕСКИХ АРХИТЕКТУР
Детализированы модели информационно-управленческих архитектур со статическим определением типов, выполнено сравнение моделей со статическим и с динамическим определением типов, выявлены их преимущества и недостатки. Рис. 6, ист. 9.
В.М. Дашч, М.К. Дьомш
СИНТЕЗ ОБ'еКТНИХ МОДЕЛЕЙ 1НФОРМАЦ1ЙНО-УПРАВЛ1НСЬКИХ АРХ1ТЕКТУР
Деталiзованi моделi Ыформацмно-управлЫських архтектур 3i статичним визначенням титв, виконано порiвняння моделей 3i статичним i динамiчним визначенням типiв, виявленi ix переваги i недолiки. Рис. 6, ист. 9.
V.N. Danich, M.K. Dyomin
SYNTHESIS OF INFORMATION-ADMINISTRATIVE ARCHITECTURE OBJECT MODELS
Information-Administrative Architecture models with static definition types are detailed. The comparison of models with static and dynamic definition types are performed, determining their advantages and disadvantages.
Постановка проблемы. Концепция информационно-управленческих архитектур (ИУА), сформулированная в [1-3], дает возможность подойти к выбору эффективной архитектуры предприятия путем мониторинга реальных ИУА, создания соответствующей базы данных, последующего выделения типовых и предпочтительных архитектур для предприятий определенного класса.
Информационно-управленческой архитектурой предприятия в [1 -3] названа совокупность управленческой и информационной структуры, рассматриваемая в единстве и взаимодействии. Она представляет собой каркас системы управления. По своему строению она многослойна и каждый слой отображает сущности и связи определенной природы: подразделения, должности, элементы информационной системы (аппаратные, программные и др.). Создание баз данных ИУА предполагает наличие адекватных информационных моделей.
В [1-3] и [4] описаны различные подходы к построению моделей информационно-управленческих архитектур (ИУА). Подходы [1 -3] проработаны на уровне концепций. В них непосредственно моделируются сущности
"Управлшня проектами та розвиток виробництва", 2007, № 4(24)
1
предметной области в виде классов. В [4] описана модель, которая решает проблему представления многослойности ИУА и может применяться для широкого круга предприятий. Но она построена на других принципах, чем те, что описаны в [1-3], в ней в виде системы классов моделируются средства описания сущностей, а не сами сущности, задается общий вид моделей ИУА. Возможности решения проблем многослойности и расширяемости в рамках подхода [1-3] ранее не рассматривались. Для проведения анализа этих возможностей необходимо детализовать метод построения моделей, представленный в [1-3]. Кроме того, необходимо более четко определить условия, при которых следует применять тот или иной вид моделей.
Анализ публикаций. В [1,2] обоснована необходимость создания базы данных информационно-управленческих архитектур, а также поставлена задача построения объектно-ориентированных моделей и баз данных ИУА. В [3] предложена концепция построения таких моделей.
Подход к построению моделей используется следующий: на базе анализа предметной области (предприятий, законодательства и т. д.) в реальном мире выделяются некоторые сущности, между ними устанавливаются связи типа общее-частное. Эти сущности непосредственно отображаются в модели в виде классов, связи типа общее-частное - в виде наследования, а связи включения -агрегированием. Данный подход освещен в специализированной литературе [8], и возможность его использования считается одним из основных достоинств объектно-ориентированного моделирования. Такие модели мы называем моделями со статическим определением типов.
При анализе предметной области были выделены следующие сущности: организация, юридическое лицо, предприятие, конкретное предприятие. Кроме того, было выяснено, что понятия «Организация» и «Подразделение» отличаются друг от друга только смысловой нагрузкой некоторых полей. Предложен набор классов, описывающих некоторые реальные подразделения. В компании, работающей на рынке нефтепродуктов, это могут быть классы «АЗС», «Бухгалтерия». При таком построении модели получается иерархия классов (рис. 1,2), полностью представляющих оргструктуры предприятия [3].
Рис 1. Классы, представляющие оргструктуру конкретного предприятия, работающего на рынке нефтепродуктов
2
"Управлшня проектами та розвиток виробництва", 2007, № 4(24)
Рис 2. Композиция объектов, представляющих оргструктуру конкретного предприятия, работающего на рынке нефтепродуктов
Поскольку в модели присутствует отдельный класс для каждого предприятия, то допустимым является представление вхождения подразделения в предприятие в качестве поля соответствующего типа.
В [4] предложена модель, позволяющая без модификации представлять информацию об ИУА широкого круга предприятий. Назовем ее моделью с динамическим определением типов.
Целью статьи является детализация методов построения моделей со статическим определением типов, анализ моделей со статическим и с динамическим определением типов, оценка их преимуществ и недостатков, определение условий применимости указанных моделей.
Изложение основного материала. Рассмотрим возможность применения подхода, приводящего к построению моделей со статическим определением типов. Речь пойдет о создании на основе таких моделей программного комплекса мониторинга ИУА. Достоинством этого подхода является естественность (простота) построения объектно-ориентированной модели. Такие определения объектов реального мира как «предприятие - это юридическое лицо», «Донецкие ресурсы - это предприятие», «бухгалтерия - это подразделение» с легкостью отображаются в модели при помощи наследования. Но модель получается довольно громоздкой. Необходимость создания отдельного класса для каждого предприятия требует, чтобы количество рассматриваемых предприятий было заранее ограничено.
Следует оценить количество классов в модели. Предположим, рассматривается 40 предприятий одной отрасли, каждое из которых состоит в среднем из 20 подразделений. Исследования показали, что в различных предприятиях очень редко бывают полностью идентичные подразделения. Например, цех одного предприятия состоит из трех участков, а другого - из пяти. В этом случае нам понадобится два отдельных класса для представления двух разных цехов. Рассматриваемая модель при указанных предположениях может включать до 800 классов. Это в худшем случае, но модель из 200-300 классов тоже представляется слишком громоздкой. Ситуация усложняется тем, что кроме написания самих классов необходимо написать программный код для работы с новыми классами. Получается, что при добавлении нового класса приходится изменять почти всю программу. Учитывая сказанное, можно сделать вывод, что такой подход пригоден для построения моделей ИУА предприятий мелкого либо среднего размера в случаях, когда количество предприятий
"Управлшня проектами та розвиток виробництва", 2007, № 4(24)
3
варьируется от 1 до 10. Если предприятий больше (или если рассматривать одно очень крупное предприятие, например, Новокраматорский машиностроительный завод), то значительно возрастает сложность модификации программы, построенной на основе такой модели. Громоздкость таких моделей препятствует их практическому применению в случаях, если круг рассматриваемых предприятий должен быть достаточно широк.
Кроме того, ИУА постоянно изменяются. Например, компания «Восточные ресурсы» за 2002 год открыла 4 новые АЗС, а за 2004 - 2. Модель ИУА предприятия «Восточные ресурсы» в течение 2002 года пришлось бы модифицировать четыре раза, а в 2004 году - два. Это еще один недостаток таких моделей.
На практике классы создаются таким образом, что подразумевается возможность существования нескольких объектов определенного класса. Возможно получение модифицированной модели, в которой объекты класса «Предприятие» будут представлять информацию о различных предприятиях. В этом случае предприятие «Донецкие ресурсы» представляется, как указано на рис. 3 и 4.
Рис. 3. Классы модифицированной модели, представляющие организационную структуру предприятия, работающего на рынке нефтепродуктов
Имя: Донецкие ресурсы
Тип: Предприятие
-^ ^ Имя: Дирекция / 1 - *- Имя: Бухгалтерия
Тип: Дирекция Имя: АЗС1 Имя: АЗС2 Тип: Бухгалтерия
Тип: АЗС Тип: АЗС
Имя: АЗС3
Тип: АЗС
Имя: Магазин при АЗС Имя: СТО при АЗС
Тип: Магазин Тип: СТО
Рис. 4. Композиция объектов модифицированной модели, представляющие организационную структуру предприятия, работающего на рынке нефтепродуктов
Иерархия классов не претерпела существенных изменений. Основные изменения состоят в следующем. В класс «Организация» включен список дочерних подразделений. Следовательно, любое предприятие и подразделение может содержать такой список. А состав списка определяется во время работы программы, а не на этапе проектирования. Нужно отметить, что в тип «Предприятие» можно включить и дополнительные списки объектов, и тем 4 "Управлшня проектами та розвиток виробництва", 2007, № 4(24)
самым реализовать представление многослойности ИУА. Классы «АЗС», «Дирекция», «Бухгалтерия» должны представлять информацию о соответствующих подразделениях различных предприятий. Рассмотрим пример. В состав одной АЗС входит магазин и небольшая СТО, а у другой АЗС таких подразделений нет. Поскольку класс «АЗС» является наследником класса «Организация», то он может содержать список подразделений, каждое из которых должно быть объектом класса, производного от класса «Организация». Если в модели есть классы «СТО» и «Магазин», то мы можем представить информацию о двух разных АЗС в данной модели. Для этого нам не придется модифицировать класс АЗС. В этом случае список подразделений объекта, представляющего первую АЗС, будет содержать два элемента, а список подразделений объекта, представляющего вторую АЗС, будет пустым.
Полученную модель следует использовать при таких условиях:
- все предприятия содержат ограниченный круг различных подразделений;
- рассматриваемые предприятия сходны по своей структуре;
- ИУА предприятий с течением времени изменяются лишь незначительно.
Построение модели состоит из следующих этапов. Во-первых, выбирается
соответствующий круг предприятий. Во-вторых, производится анализ ИУА с целью выделения сущностей (подразделений, должностей), которые образуют ИУА этих предприятий. Для каждой такой сущности создается свой класс. Далее на этапе выполнения создаются объекты этих классов, из которых и строятся представления ИУА предприятий.
Рассмотрим проблемы, которые могут возникнуть при использовании данного подхода. Список дочерних подразделений должен быть организован как список указателей на экземпляры класса «Организация» (то же, что и «Подразделение»), базового класса, для всех классов, представляющих конкретные подразделения. В этом списке могут находиться экземпляры классов, производных от класса «Организация». Но в момент создания такого объекта необходимо обязательно указывать, экземпляр какого конкретно класса создается. Следовательно, необходим механизм создания объектов по имени класса либо по некоторой другой информации, идентифицирующей класс, которая определяется во время выполнения. Такой механизм напрямую не поддерживается ни одним из распространенных (и доступных) объектно-ориентированных языков программирования (C++, Object Pascal, Java).
Реализовать механизм создания объектов по имени в C++ возможно, адаптировав для этого паттерн проектирования «Абстрактная фабрика» [5]. Возможность реализации такого механизма упомянута в [8]. Для этого потребуется создать класс AbstractFactory, определяющий интерфейс для создания объектов класса «Организация» либо производных классов. От этого класса наследуется шаблонный класс Factory. Он должен уметь создавать экземпляры классов, которые являются параметром шаблона. В качестве такого параметра и будут использоваться производные классы. Далее нужно организовать словарь, ключом которого является имя класса, а значением указатель на AbstractFactory, который может (и должен) указывать на экземпляр класса Factory. Конструктор класса Factory удобно сделать таким, чтобы автоматически добавлял ссылку на экземпляр создаваемого класса в словарь. (Рассматривается именно С++ прежде всего из соображений эффективности и доступности ОО СУБД, ориентированных на использование этого языка).
Следующий вопрос, требующий рассмотрения: как организовать работу с данными производных классов, которых нет в базовом. С каждым новым классом (производным от класса «Организация») необходимо ассоциировать набор интерфейсных элементов. Сделать это можно, создавая для каждого
"Управлшня проектами та розвиток виробництва", 2007, № 4(24)
5
класса новый диалог с необходимыми элементами управления, работающими с данными объектов этого класса. Связать диалог с классом можно, добавив в соответствующий класс метод, создающий новый диалог. Такой подход не является гибким, но достаточно просто реализуем.
Если модифицировать класс, представляющий информацию о подразделении, то приходится модифицировать и соответствующий набор интерфейсных элементов и код программы, работающий с ними. Но в любом случае в рамках предложенной модели избежать этого не удастся.
Для реализации некоторых аспектов предложенной модели приходится применять нетривиальные методы. Минусом данного подхода является достаточно большое число классов в модели, а также ее значительная статичность.
Рассмотрим ИУА ВНУ имени В.Даля в 2004 (рис. 5) и 2007 (рис. 6) году. Произошло не только переформирование подразделений, но и появились новые подразделения, не существовавшие ранее, а другие подразделения были ликвидированы.
Если предприятие производит реорганизацию, в результате которой в его составе образуется новое подразделение, для представления которого в модели нет соответствующего класса, то модель уже не может быть адекватной. В таких случаях требуется корректировка модели, которая заключается в следующем: добавление нового класса (и диалога) в модель и перекомпиляция приложения.
Желательно иметь возможность производить такие модификации без перекомпиляции. Для данной модели это значит, что необходим механизм динамического создания типа во время выполнения. Известно, что на этапе выполнения уже не существует типа в общепринятом смысле (как на этапе проектирования). На этапе выполнения используется некоторая информация о структуре типа, но не более. Но даже если бы имелась возможность создать такую новую структуру на этапе выполнения, этого еще недостаточно. Необходимо «научить» всю программу работать с новым типом. Именно поэтому сделать добавление нового типа без перекомпиляции не представляется возможным. Разве что следует рассмотреть возможность организации объектов, так как это сделано в технологии СОМ (стандартизация на двоичном уровне [6]). В случае использования такой возможности процесс разработки каждого класса значительно усложнится. Кроме того, возможно значительное снижение эффективности. Поскольку классов в модели должно быть достаточно большое количество, такое усложнение разработки классов является неприемлемым.
6
"Управлшня проектами та розвиток виробництва", 2007, № 4(24)
Рис. 5. Фрагмент ИУА ВНУ им. В. Даля (2004 г.)
В [4] рассмотрена модель, названная моделью с динамическим определением типов. В ней существует набор классов, позволяющий описывать сущности предметной области в виде набора атрибутов. Эти описания могут добавляться во время работы приложения. Достигается это за счет унификации механизмов хранения данных. При использовании такого подхода пользователь может самостоятельно создавать описания сущностей предметной области. Эти описания являются логическими типами данных. Следует отметить, что расширяемое множество логических типов реализовано с помощью фиксированного набора классов модели. Можно провести аналогию с реляционными СУБД. Они позволяют в работающую БД добавлять новые таблицы, что аналогично добавлению новых типов. Новый тип возникает только с точки зрения пользователя СУБД.
Модель с динамическим определением типов обеспечивает большие возможности, чем просто унификацию хранения данных. Благодаря отражению специфики реальных ИУА, модель позволяет строить единое согласованное описание ИУА в целом, а не только хранить информацию о ее разнородных элементах. Механизм хранения значений атрибутов позволяет в полной мере использовать средства, предоставляемые СУБД, для анализа информации об ИУА предприятий. При использовании этой модели имеется возможность реализовать специализированный язык запросов к БД ИУА. Важно, что единая реализация языка запросов сможет оперировать расширяемым набором логических типов.
"Управлшня проектами та розвиток виробництва", 2007, № 4(24)
7
Рис. 6. Фрагмент ИУА ВНУ им. В. Даля (2007 г.)
В то же время и модели с динамическим определением типов имеют ряд недостатков. Это менее эффективное хранение данных, чем при использовании специализированной модели для конкретного круга предприятий. При неправильном использовании таких моделей можно получить запутанную систему. Но перечисленные недостатки не являются принципиальными. Во-первых, снижение эффективности хранения данных не является критичным, а построение специализированных моделей для каждого круга предприятий не в полной мере согласуется с общей концепцией мониторинга, который является наименее затратным способом построения эффективных ИУА. Во-вторых, использование при сборе данных о предприятии инструментов и механизмов мониторинга, описанных в [9], приводит к однозначному представлению ИУА в рамках модели с динамическим определением типов.
В случаях, когда рассматриваемые ИУА разнообразны и динамично изменяются, применение таких моделей является предпочтительным.
Выводы. В статье детализована модель ИУА со статическим определением типов, произведено сравнение моделей со статическим и с динамическим определением типов, выявлены их преимущества и недостатки. Модель со статическим определением типов может использоваться в случаях, если круг рассматриваемых предприятий ограничен, их ИУА однотипны и мало подвержены изменениям. Для организации мониторинга ИУА в современных условиях предпочтительнее использовать модели с динамическим определением типов.
Направления дальнейших исследований - изучение особенностей реализации моделей с динамическим определением типов, создание на их основе баз данных ИУА с использованием современных объектно-ориентированных и реляционных СУБД.
8
"Управлшня проектами та розвиток виробництва", 2007, № 4(24)
ЛИТЕРАТУРА
1. Данич В. Н. Синергизм управленческих и информационных структур в социальных системах // Вестник Восточноукраинского государственного университета, Луганськ. -2000. - №3 (25). - С. 20-27.
2. Данич В. Н. Объектно-ориентированные модели социально-экономических систем в задачах выбора предпочтительных информационно-управленческих архитектур // Модели управления в рыночной экономике: сб. науч. тр. / Под ред. д.э.н. , проф. Ю.Г. Лысенко. - Донецк: Изд-во ДонГУ, 2000. - Вып. 3 - С. 245-254.
3. Данич В.Н. Базовые структуры данных в объектно-ориентированных моделях социальных систем // Экономическая кибернетика, Донецк. - 2001. - № 5-6. - С. 91-98.
4. Данич В.Н., Демин М.К., Чернышев Г.Е. Система классов в задаче моделирования информационно-управленческих архитектур // Прац Луганського вщдтення мiжнародноí академи шформатизаци: науковий журнал / За ред. д.т.н В.О. Ульшина. -Луганськ: СНУ iм. В. Даля, 2005. - С. 39-46.
5. Гамма Э. Приемы объектно-ориентированного проектирования. Паттерны проектирования / Э.Гамма, Р.Хелм, Р.Джонсон, Дж.Влиссидес. - СПб.: Питер, 2001. -368 с.
6. Бокс Д. Сущность технологии COM. - СПб: Питер, 2001. - 400 с.
7. Элджер Дж. С++: библиотека программиста. - СПб: Питер, 2000. - 320 с.
8. Буч Гр. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. - 2-е изд. - М.: Бином, 1999. - 560 с.
9. Данич В.Н., Дёмин М.К., Танченко С.М. Инструменты и механизмы мониторинга информационно-управленческих архитектур предприятий // Вестник ВНУ. - Луганськ. - 2007. - №5. - С. 160-165.
Отаття надмшла до редакцп 13.11.2007 р.
"Управлшня проектами та розвиток виробництва", 2007, № 4(24)
9
