4. Модели и методики построения типовых систем обработки информации как информационных систем с метауправлением функциональностью, и примеры их применения

   1. Модель и методика построения средств формализации и агрегации экспертных знаний по спецификациям доменов

Обязательным компонентом как процесса создания, так и преобразова­ния (реинжиниринга) любой автоматизированной системы (и не только) явля­ется формализация экспертных знаний как сведений о существующей и (или) создаваемой системе, предъявляемых к ней требованиях, условиях ее функ­ционирования и т. д. (/7, 118, 243,244/ и др.). В практике создания автомати­зированных систем и их специального программного обеспечения принято рассматривать подобные сведения как совокупность спецификаций (/37, 212, 245, 246/ и др.), которые способствуют пониманию требований, предъявляе­мых к конечному продукту, и служат основой для проектирования, реализа­ции, тестирования, сертификации, сопровождения и дальнейшего развития создаваемой системы.

В настоящий момент не существует формального определения понятия "спецификация" или '’специфицирование". В /246/ приведено определение спецификаций как формального отображения замысла в символьную конст­рукцию, исключающую ее неоднозначное толкование, которое наиболее со­ответствует общему предназначению процесса специфицирования. Специфи­кации представляют собой описание высокого уровня в терминах, характер­ных для описываемой системы (процесса), и должны отвечать требованиям точности, понятности и полноты /245/, а по степени формальности различают вербальные, формализованные и формальные спецификации /9/.

Совокупность структурированных спецификаций, обладающую свойст­вами целостности и непротиворечивости, можно рассматривать как информа­ционную

модель (ИнМ), которая несет в себе всю совокупность сведений, ха­рактеризующих существенные свойства объекта моделирования (требование целостности) и согласованных по семантической и прагматической нагрузке использованного понятийного аппарата (требование непротиворечивости).

Такое определение, наиболее близкое к приведенным в /247, 248/, по­зволяет охватить общим термином "информационная модель" достаточно обширный класс информационных семантических систем: например, инфор­мационными моделями можно считать технологическую карту процесса, спе­цификатор работ, бизнес-план выпуска продукции (производства услуг), схе­му организационно-штатной структуры предприятия и т. д. (/110, 249, 250/ и др.), разного рода концептуальные модели (/7, 98,99/ и др.), а также опреде­ления информационных моделей, используемых в различных методологиях (в том числе и создания баз данных) (/152,183,251 - 254/ и др.).

Хотя любая абстрактная модель является гомоморфным отображением оригинала с сохранением его существенных свойств и несет в себе некоторую информацию о моделируемом объекте /255/, информационная модель имеет характер первичного семантического документа модельного типа (по класси­фикации, приведенной в /256/). Структурированность спецификаций, состав­ляющих ИнМ, обусловлена переходом от многомерного плана содержания специфицируемых свойств объекта моделирования к линейному плану его отображения в виде последовательности знаковых элементов модели /256/.

На основе результатов анализа /7, 110, 118, 167, 191, 257, 258/, процесс построения ИнМ можно описать следующим образом:

производится декомпозиция системы на подсистемы (домены), каждый из которых в свою очередь также может быть разбит на подсистемы (домены) меньшего объема (разбиение производится до того уровня, когда можно осу­ществить линейное специфицирование полученной подсистемы);

осуществляется специфицирование подсистем* результатом которого являются спецификации;

полученные спецификации формализуются с использованием той или иной схемы формализации (см. п. 2.3);

формализованные спецификации агрегируются п ИнМ с проверкой се корректности.

Следует отметить, что понятия подсистемы и домена не совпадают: в соответствии с методологией объектно-ориентированного анализа /183/ до­мен представляет собой некий функциональный "срез" системы, более близ­кий к определению бизнес-процесса в методологии реиижинирига бизнес- процессов (BPR - Business Process Reengineering) /110/.

Создание ИнМ, представляет собой достаточно весьма ответственный и трудоемкий процесс, осложняемый необходимостью коллективного взаимо­действия разработчиков ИнМ (аналитиков, или инженеров по знаниям - /257/) и специалистов предметной области, владеющих знаниями о специфицируе­мом объекте (экспертов), со всеми вытекающими из этого отрицательными последствиями (см., например» /1,7,110» 123,172,259,2601).

Сложность и размерность объектов информационного моделирования, особенности организации процесса его проведения (последовательно- параллельная коллективная работа аналитиков и экспертов) и жесткие требо­вания по срокам создания ИнМ привели к необходимости создания и внедре­ния средств автоматизации информационного моделирования для повышения производительности труда разработчиков ИнМ и качества создаваемых моде­лей/7. 110,118» 212» 245/.

Наиболее развитыми средствами автоматизированного специфицирова­ния и информационного моделирования являются CASE-средства этапа сис­темного анализа, подробный обзор и сравнительный анализ которых приве­ден в /7, 118/. Несмотря на несомненные достоинства CASE-средств, их при­менение

для информационного моделирования осложняется следующими об­стоятельствами:

1. Каждое CASE-средство ориентировано на использование одной или нескольких схем формализации» и основная проблема выбора CASE-средства состоит в оценивании применимости той или иной схемы формализации для описания моделируемого объекта с учетом назначения модели и целей моде­лирования (причем не всегда CASE-средства могут обеспечить применение требуемой схемы формализации, особенно на начальных этапах проектирова­ния системы, когда формализации подлежат предметные сведения специфи­ческой направленности - как, например, медицинское обеспечение систем скринирующей диагностики /261/).

2. CASE-средства ориентиропанм на аналитика, оперирующего понятия­ми схемы формализации и хорошо представляющего последнюю, а не экспер­та предметной области.

Указанные недостатки заставляют искать иные подходы к созданию средств автоматизации информационного моделирования и организации их использования. Одним из наиболее перспективных направлений исследова­ний в данной области являегся создание условий, позволяющих привлечь предметных экспертов непосредственно к формированию спецификаций по задаваемой схеме формализации, устранив "передаточное звено" в виде ана­литика. Такой результат может быть получен с помощью применения мета­управления, и сознания средств автоматизированного информационного мо­делирования как информационных систем с метауправлением.

Анализ содержания манипулирования знаниями в процессе информаци­онного моделирования /191,219,220, 257, 262/ показывает, что процесс спе­цифицирования естественным путем разбивается на два уровня определений, первый из которых является для второго управляющим (рис. 4.1):

Рис. 4.1. Уровни работы со знаниями ы процессе информационного моделирования

на первом уровне задаются определенные понятия, семантические огра­ничения и определения, подлежащие использованию при формировании ИнМ, и создается план формализации - совокупность схем содержательной и организационной декомпозиции объекта моделирования, а также одной или нескольких схем формализации с привязкой последних к схемам декомпози­ции;

на втором уровне производится задание или модификация самих спе­цификаций, выраженных ранее определенными понятиями и записанных на ранее определенном дескриптивном языке, элементы которого с использова­нием ссылок на определенные понятия могут быть представлены в естествен­ной и удобной для эксперта форме в терминах предметной области.

Таким образом, применение метауправления при формировании специ­фикаций основано на дескриптивной природе самих спецификаций /245/, что обеспечивает

задание формализмов языковых определений на метауровне для выражения понятий, служащих для описания моделируемых систем, простым и понятным способом, удобным для эксперта.

Приведенное разделение уровней определений позволяет формально разграничить области действия аналитика и эксперта н рамках парадигмы ме- тауправлеиия:

на первом уровне специфицирования аналитик преобразует свои знания в универсальные понятия некоего концептуального мира, описывающего оп­ределенную ПрО, и правила их композиции в подлежащей созданию ИнМ, то есть задает синтаксис знаковой модели (в виде метаспецификаций), которую далее будет формировать эксперт;

на втором уровне определений эксперт, манипулируя понятиями сфор­мированного аналитиком концептуального мира, создает предметные специ­фикации конкретного домена.

Применение метауправления. приводит к существенному изменению схемы организации работ по проведению информационного моделирования (рис. 4.2):

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

в процессе специфицирования эксперт описывает знания о домене но схеме формализации, ранее ^нвложенной" аналитиками в средства моделиро­вания в виде спецификатора домена - результатом специфицирования будут формализованные спецификации домена;

аналитиками осуществляется агрегация спецификаций и последующая верификация получаемой ИнМ.

На рис. 4.2 также показаны возможные "возвраты", отражающие внесе­ние изменений в метаспецификации или предметные спецификации и обу­словленные стремлением к получению корректной ИнМ.

Рис. 4.2. Схема работ по созданию ИнМ с применением метауправления

Очевидно, что при создании средств автоматизированного информаци­онною моделирования (САИНМ) как ИСМУ номенклаторы понятий и спе­цификаторы доменов (далее - номенклаторы и спецификаторы соответствен­но) представляют собой компоненты метаинформации, первый из которых есть онтология (понятийная модель), а второй - такая компоновка элементов

онтологии, перевод которой в детерминированную форму позволяет получать предметные спецификации, структурированные в соответствии с используе­мой схемой формализации. Таким образом, термины "номенклатор" и "спе­цификатор" здесь и далее используются для обозначения именно формы представления онтологии и схемы формализации, "спроецированной” на он­тологию, как компонентов метаинформации.

С учетом концептуальных и методологических основ построения ИСМУ, изложенных в главах 2 и 3, САИНМ может быть построена как ин­формационная система с метауправлением, в которой использование метаин­формации осуществляется по вычислительной схеме с характеристическим вектором <1, 2, 1, 1, 1> (см. п. 2.2). Специфика САИНМ с точки зрения ис­пользуемых вычислительной схемы и логической структуры определяется со­держанием автоматизируемых процессов информационного моделирования и заключается в следующем:

по отношению к САИНМ пользователями выступают как аналитики, формирующие и изменяющие КМИ, так и эксперты, для которых имеющиеся КМИ статичны;

процесс формирования предметных спецификаций по спецификатору домена есть процесс перевода спецификатора (в рамках разработанной БМПМИ - процесс конкретизации, то есть конкретизованный спецификатор и представляет собой предметные спецификации домена);

интерпретация конкретизованных спецификаторов (которые уже не яв­ляются КМИ) заключается в агрегации их содержимого в единую информа­ционную модель.

Указанные особенности приводят к тому, что логическая структура САИНМ приобретает вид, показанный на рис. 4.3.

Рис. 4.3. Логическая структура САИНМ

Формальная модель САИНМ, соответствующая ее логической структу­ре и являющаяся частным случаем модели (2.3), может быть определена как формальная система вила

IS* = (Ц* U* R„ о», Lp,, S, Rs) (4.1)

где L_m>- язык представления метаспецификаций;

Множество КМИ U_c

Множество спе­цификаторов и„

Спецификатор домена а-,е U_c

	-
		J

Множество номенклаторов U_<P

множество КМИ, образованное множеством номенкла­торов U_cp и множеством спецификаторов Ucs((Vu)(u eU_c) (u eL_ms));

ис­пользование номенклаторов при формировании спецификаторов: R_u(uc_P) = u<*,

если Ucp € U_cp, u« e Ucs и номенклатор u_cp использован для создания специфи­катора u_n;

(о ^в (Du и ®d - правила обработки метаспецификаций и предметных спецификаций (правила перевода £0и и правила интерпретации ©о)> описан­ные ниже;

Lm - язык представления предметных спецификаций;

S = S₅p и S, - множество предметных спецификаций, образованное множеством спецификаций доменов S_v и множеством результатов агрегации

S_a;

Rs- отношение на множестве S, описанное ниже.

Аналогично модели (2.3), функционирование САИНМ в рамках модели (4.1) может быть описано как совокупность действий по формированию, пе­реводу и интерпретации.

Формирование КМИ представляет собой процесс создания номенклато- ров и спецификаторов, образующих U_c, причем один номенклатор может быть использован при создании двух и более спецификаторов, но каждому спецификатор создается с использованием только одного номенклатора ((Vu) (u ell_a) (|R„"'(u)| - I)).

В данной работе предполагается, что для представления номенклаторов и спецификаторов используется БМПМИ (см. п. 3.1), а в качестве - один из языков, описанных в п. 3.2. При необходимости БМПМИ может быть рас­ширена: например, в /58/ описано введение в модель и язык представления метаинформации типа понятий (сущности, отношения, атрибуты, значения), отображаемых информационными элементами и секциями ИСФ.

Номенклатор создается как результат идентификации и формулировки множества понятий, адекватных (концептуально) специфицируемому домену. По своему содержанию он представляет собой совокупность двух множеств - базовых понятий Р и множества базовых отношений R, в основу правил фор­мирования которых положен

подход, изложенный в /227, 228, 263. - 265/ и до­полненный с учетом 19/.

Каждое базовое понятие Pj задается в виде совокупности Р; = (nj, Aj, q, ,Sj) (4.2), где n* - имя i-го понятия, А; - множество атрибутов i-ro понятия, q, - семантическое значение i-ro понятия, Si - супертип (суперпонятие) для i-ro понятия.

Элементы множества Aj являются парами вида (a^:j, z j), где a j - имя j-ro атрибута i-ro понятия (j > 0), - множество возможных значений этого атри­бута (|Zj| £ 0).

Введение супертипа позволяет реализовать иерархическое отношение ^нтип-подтип" ("IS-A") (/220, 221, 262/ и др.): если в описании понятия Sj* 0, то новое понятие определяется как подтип (наследник, потомок) супертипа, наследующий все его атрибуты (возможно, также приобретенные).

Семантическое значение понятия qj представляет собой вербальное описание смысловой нагрузки данного понятию.

По аналогии с /263/, множество базовых отношений R = {Г|, ъ, г„} является множеством бинарных отношений, которые могут существовать ме­жду парами экземпляров базовых понятий в данной ПрО.

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

Методика формирования номенклаторов и спецификаторов, а также возможность поддержки их формирования посредством множества шаблонов подробно описаны в /58/.

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

Перевод КМИ при использовании БМПМИ достаточно очевиден - это конкретизация базы спецификатора, правила выполнения которой (то есть «и) полностью определяются моделью СДУ-перевода, приведенной в п. 3.3. Су­щественно» что БМПМИ в виде ИСФ позволят представить в рамках этой мо­дели и предметные спецификации, то есть обеспечить L_ps = L™, что сущест­венно упрощает реализацию САИНМ.

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

Интерпрегаиия для САИНМ весьма специфична - ее составляют про­цессы агрегации предметных спецификаций и получение собственно инфор­мационной модели, выполняемые по правилам g>da и о>оо соответственно (соо

= ©од yJ ©do)-

Итоговой ИнМ должна соответствовать одна (единая, общая) понятий­ная модель, а разработка номенклаторов (и соответствующих им специфика­торов)

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

Агрегация предметных спецификаций и является процессом объедине­ния предметных спецификаций, полученных по тем или иным спецификато­рам, в единую ИнМ, однако она не сводима ни к элементарному объединению множеств предметных спецификаций, ни к агрегированию /266/, так как тре­бует учета семантики элементов объединяемых множеств /17/ и не предпола­гает замену множеств объектов (сущностей, величин и т. д.) одним агрегиро­ванным (или интегральным) объектом. Выполняемая при этом верификация есть проверка непротиворечивости спецификаций как корректности междо- менных связей.

Агрегация и сопутствующей ей процесс формальной верификации предметных спецификаций может быть обеспечен двумя операциями: агрега­ция спецификаций, полученных по одиому и тому же спецификатору, и агре­гация спецификаций, полученных по различным спецификаторам. Полное описание методики агрегации и содержания указанных операций приведено в приложении 6.

Результаты выполнения операций агрегации помещаются в $_а. Посколь­ку агрегации могут быть подвергнуты как спецификации доменов (элементы 5>,Д так и результаты выполнения операций агрегации (элементы S_e), отно­шение R, характеризует использование элементов S₉ и S, в получении S_a: R,(uO - u„ где u, € S, и» € $,, если спецификации u_a получены как результат агрегации в том числе спецификаций и$.

Итоговая модель 1м также есть результат выполнения операции агрега­ции Um, если (Vu_s)( u_s е SjpX Rs⁺(u_s) = u_m), к которому применимы правила отображения со do: с)ро(^ип) 1м- Под отображением в данном случае понима­ется визуализация содержимого u_m с использованием того или иного способа определения вычислительной семантики ИСФ - как правило, композиции со­держимого атрибутов и слотов фреймов (см. п. 3.4).

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

Описанные выше модель и методика построения средств формализации и агрегации экспертных знаний как ИСМУ были использованы при создании нескольких вариантов САИНМ. Опыт их применения в интересах информа­ционного моделирования реабилитационных центров для детей-инвалидов /23/, бизнес-процессов промышленных предприятий /11,63/ и АСУ специаль­ного назначения /12, 50/ показал, что только временные затраты на формиро­вание информационных моделей при использовании таких средств сокраща­ются в два и более раза. Эффективность применения подобных средств нели­нейно увеличивается с ростом количества специфицируемых доменов, уменьшением ресурса аналитиков и уменьшением количества спецификато­ров (уменьшением количества используемых схем формализации), а также пространственной распределенностью экспертов. Причина, по которой разра­ботанная методика более эффективна по отношению к традиционному подхо­ду, достаточно очевидна — это привлечение экспертов непосредственно к формированию спецификаций, и высокая степень функциональной адапти­руемости САИНМ, создаваемых с применением метауправления.

2. Модель и методика построения средств порождения имитацион­ных моделей по схеме метауправления на основе агрегативного подхода

Имитационное моделирование, являющееся важнейшим инструментом решения задач анализа, синтеза и оптимизации сложных систем в условиях существования явления "вычислительной неприводимости" /267/, в настоящее время имеет широчайшую теоретическую и методологическую базу (/184, 268

-272/и др.).

По мере накопления опыта применения и совершенствования средств имитационного моделирования все больший интерес стали вызывать иссле­дования, направленные на автоматизацию имитационного моделирования. Наибольший пик этих работ пришелся на конец 80-х - начало 90-х годов, и основными направлениями исследований явились создание специализиро­ванных языков моделирования, генераторов моделей, проблемно- ориентированных пакетов и систем моделирования - /213, 273 - 282/ и др. Анализ результатов этих работ позволяет выделить семь групп работ, состав­ляющих содержание применения имитационного моделирования и потенци­ально подлежащих автоматизации:

исполнение ("прогон”) модели на ЭВМ;

задание значений параметров модели для проведения имитационного эксперимента;

обратная интерпретация результатов, под которой понимается сопос­тавление результирующих значений переменных программной модели и со­ставляющих моделируемой системы;

построение программной модели;

вторичная обработка (постобработка) результатов моделирования мето­дами статического анализа и т. д.;

планирование экспериментов, анализ их результатов и определение мо­мента завершения исследований;

построение формально-математической модели.

Описываемая ниже методика охватывает работы первых четырех групп, для автоматизации которых наиболее широко используются (/273, 275, 283 - 288/и др.):

реализация макросредств записи текста модели;

создание метаязыков описания моделей и соответствующих предпро- цессоров;

использование библиотек типовых, часто используемых фрагментов (сегментов, агрегатов) моделей;

разработка программ, позволяющих задать в диалоговом режиме зна­чения параметров модели (исходные данные экспериментов) и компоновать тексты моделей.

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

содержимое модели систематизируется, после чего формируются пра­вила компоновки текста модели при известных значения входных парамет­ров;

далее разрабатывается программа, которая запрашивает у пользовате­ля значения параметром модели, генерирует (формирует) текст модели на входном языке системы имитационного моделирования.

Как показывает опыт этих работ (/223, 224, 279, 289, 290/ и др.), про­грамма-генератор позволяет существенно сократить затраты ресурсов, необ­ходимых на модификацию модели при варьировании параметров экспери­мента, и, реализуя диалоговый режим работы с широким набором сервис­ных функций, становится удобной и доступной в использовании даже для пользователей, не знакомых с языком имитационного моделирования и со­держанием алгоритмов модели. Однако подобная программа является уни­кальной

для каждой модели (или множества моделей, объединенных целе­вым предназначением).

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

Тогда автоматизированное построение текстов моделей и их использо­вание может осуществляться следующим образом:

эксперт создает типовую модель (библиотеку моделей) и программу- генератор конкретных вариантов моделей, посредством которой аналитик формирует нужные ему модели и проводит на них эксперименты;

эксперт создает и пополняет базу типовых фрагментов (агрегатов), из которых аналитик выбирает и "настраивает" (адаптирует путем параметриче­ской настройки) агрегаты* соответствующие своей задаче* формирует по ним модель с использованием программы-генератора, задает значения параметров эксперимента и осуществляет "прогон" модели.

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

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

Применение метауправления для автоматизированного построения тек­стов имитационных моделей и их последующего использования предполага­ет, что основу структуры вычислительного формализма системы автоматизи­рованного построения текстов моделей (САИМ) образует базовая система имитационного моделирования (со своим входным языком), дополняемая средствами реализации трех процессов (рис. 4.4):

синтеза конструкций, воспроизводящих поведение моделируемой сис­темы (то есть текста имитационной модели);

задания входных значений параметров модели и инициации выполне­ния модели;

формирования правил обратной интерпретации результатов.

В свою очередь, содержание этих процессов должно определяться сово­купностью сведений, описывающих: структуру моделируемого объекта;

алгоритмы функционирования элементов объекта моделирования; параметры, характеризующие объект моделирования и его компоненты; правила генерации текста модели, позволяющие осуществить по­строение текста модели;

параметры базовой системы моделирования, определяющие режимы ее функционирования и условия проведения процесса имитации.

Рис. 4.4. Вычислительный формализм САИМ

Указанная совокупность сведений может быть разделена на две части - процедурную (агрегаты модели и программа обратной интерпретации резуль­татов на входном языке базовой системы моделирования), и декларативную, которая представляет собой некое формализованное описание (ФО), являю­щееся метаописанием для синтеза программных средств, реализующих ука­

занные выше вычислительные процессы вычислительного формализма САИМ.

Исходя из вышеизложенного, вычислительная схема использования ме­таинформации в САИМ, создаваемой как разновидность ИСМУ, будет иметь характеристический вектор < 1, 2, 2, I, 2 > (см. и. 2.2), а ее логическая струк­тура будет расширением варианта структуры, показанного на рис. 2.8. Следу­ет отметить, что в зависимости от базовой системы моделирования порож­даемый текст имитационной модели (ИМ) может либо интерпретироваться (как это имеет место, например, в системе моделирования GPSS /291/), либо компилироваться в совокупность машинных кодов, пригодных к дальнейше­му выполнению в качестве самостоятельной программы (например, СИМПАС /47/). На рис. 4.5 приведена логическая структура САИМ для второго вариан­та. Процесс функционировании САИМ с такой логической структурой может быть описан как совокупность трех стадий работ.

На первой стадии производятся:

разработка математической модели на основе постановки задачи на имитационное моделирование;

формирование макета программы имитационной модели; разработка агрегатов на языке моделирования, описывающих поведе­ние элементов моделируемой системы;

формирование перечня входных и выходных параметров модели; разработка формальных правил построения текста модели на базе имеющихся афегатов и значений параметров элементов моделируемой сис­темы;

разработка программы (процедуры) обратной интерпретации результа­тов, являющихся значениями объектов имитационной модели и среды моде­лирования.

Разработанные агрегаты снабжаются паспортами для обеспечения их параметрической настройки с целью обеспечения возможности их использо­вания в составе различных моделей, и помешаются в библиотеку агрегатов.

Рис. 4.5. Логическая структура САИМ

После этого эксперт осуществляет копирование всех агрегатов, необхо­димых для построения моделей в данном исследовании, из библиотеки агре­гатов (являющейся общим ресурсом) в библиотеку задачи, и их параметриче­скую настройку для применения в рамках решаемой задачи исследований.

Совокупность декларативных сведений, сформированных на первой стадии, составляет формализованное описание, структура которого определя­ется используемой схемой формализации (см. п. 2.2).

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

На второй стадии осуществляются:

формирование одного конкретного варианта ФО, однозначно опреде­ляющего строящуюся модель и возможности экспериментов с ней, то есть получение УФО, которое можно считать результатом конкретизации исход­ного ФО, но с некоторыми отличиями, описанными ниже;

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

На третьей стадии с помощью построенных на предыдущей стадии средств осуществляются:

задание значений параметров модели; генерация текста модели; компиляция полученног о текста модели;

выполнение полученной программы, осуществляющей проведение ста­тистических испытаний;

анализ результатов моделирования.

Естественно, что описанный выше процесс имеет итерационный харак­тер, соответствующий плану исследований моделируемой системы.

Предложенная схема имеет ряд преимуществ перед различными мето­дами автоматизации моделирования, основными из которых являются сле­дующие:

проводит ь эксперименты с достаточно сложной имитационной моде­лью, подготовленной экспертом, может аналитик, не знакомый с языками моделирования, причем формализованные описания, средства генерации средств построения моделей и проведения экспериментов отчуждаются от эксперта, и конструктивно представляют собой самостоятельный инструмент исследований;

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

В основе представления ФО как совокупности метазнаний декларатив­ного характера лежит применение схемы формализации, которая, в свою оче­редь, формируется при создании САИМ и далее является неизменной. По су­ти схема формализации в данном случае играет роль языка представления ме­таинформации ИСМУ (см. п. 2.1), а ее содержание определяется канониче­ским составом модели, фиксирующим липовую компоновку текста модели в используемой базовой системе моделирования. В частности, такие "канониче­ские модели" были построены для систем моделирования GPSS, СИМПАС, CSS и COMNET. Роль канонического состава состоит в том, что он позволяет зафиксировать общий вид результатов формирования текста модели и соот­ветствующим образом сформировать требования к составу ФО в виде сово­купности сведений трех групп:

подсистемы и элементы моделируемой системы, их взаимосвязи и па­раметры, характеризующие их свойства (в виде скалярных величин, векторов, матриц и вычисляемых функций), а также возможные альтернативные типы (см. выше);

имена используемых агрегатов, отождествляемых с элементами систе­мы. и схему сопряжения агрегатов;

разного рода служебные параметры, позволяющие осуществлять управ­ление функционированием базовой системы моделирования и процессом имитации (условия завершения моделирования, трассировка событий и т. д.);

правила генерации текста модели путем компоновки указанных агрега­тов, обеспечения схемы их сопряжения, установления соответствия парамет­ров модели и объектов среды моделирования и т. д.

Важнейшей особенностью процесса формирования ФО, содержащего указанные выше сведения, является сильная зависимость задаваемых значе­ний друг от друга: например, в схеме сопряжения а!регатов могут быть указа­ны имена агрегатов только из заданного ранее множества имен, функции мо­гут быть записаны как выражения над уже описанными параметрами и т. д., что также вносит свою специфику в выбор средств представления ФО.

Для представления ФО в принципе могут быть использованы модель и языки, описанные в пп. 3.1 и 3.2, однако в данном случае из-за необходимо­сти выполнения уточнения ФО более целесообразно использовать логиче­скую модель представления, определив состав конструктов для представления метаинформации и поставив им в соответствие логические предикаты, при­годные для фиксации факюв и отношений, составляющих ФО (применение математической логики к использование предикатов для представления зна­ний различного характера описано, например, в /206,225,292/).

Пример возможном схемы формализации и соответствующего ей соста­ва конструктов ФО приведен в приложении 7.

Как неоднократно отмечалось выше, уточнение ФО представляет собой своеобразный процесс конкретизации, механизм которого существенно отме­чается от рассмотренного в п. 3.3 и обеспечивается следующими средствами представления ФО:

конструктом "тип_объекта" могут быть заданы альтернативные типы объекта моделирования, а также его любых подсистем и элементов;

практически во все конструкты входит аргумент, которым является спи­сок типов объектов, при котором действует данный конструкт (то есть значе­

ние этого аргумента задает область истинной интерпретации данного преди­ката.

В зависимости наличия значений аргумента "тип объекта" все конст­рукты, имеющиеся в произвольном ФО, можно разделить на два типа: содер­жащие только константы (высказывания, к которым относятся конструкты "типобъекта" и все конструкты, не содержащие аргумента "тип объекта"), и содержащие как константы, так и переменные, то есть предикаты, к которым относятся все конструкты, в которых имеется непустой аргумент "тип объек­та"):

Р с F: F = (А|, А₂,..., А_к}. F" г: F: F" = {В,, В₂,B_L}, где F - множество конструктов формализованного описания, состоящее из непересекающихся множеств F¹ высказываний Al, А2, ..., АК и F" преди­катов В I, В2,BL.

Аргумент "тип объекта’’ представляет собой список типов объектов S, имеющий вид:

S = ( d„ d₂,d_N), N>0, d_s - (u, (Wj|, w_i2,w_iNi), (Vi) (N > i >1) HX), где d, - элемент списка типов объектов,

и - имя переменной, являющейся значением первого аргумента хотя бы одного конструкта "типобъекта";

Wji, Wjj, ..., Wj\-j - список значений переменной и, для которых элемент d; считается истинным.

Весь список S истинен, если истинен хотя бы один его элемент.

Во время формирования ФО эксперт с помощью конструктов "тип об7>скта'' (которые являются высказываниями) задает полный список типов объектов Т„ то есть для каждого объекта перечень всех возможных его типов (если это необходимо):

^Ts~ Л

No( и.

Vtir ^,=1^ г-1 j

где No - количество объектов (подсистем и элементов), для которых заданы списки значений их типов.

Этот список удобно представить в виде дерева возможных интерпре­таций /218,293/, так как, с одной стороны, каждый i-й "срез" дерева содержит все возможные типы i-ro объекта, а, с другой стороны, любой путь из корня дерева к конечному листу задает одну возможную интерпретацию на множе­стве типов.

Представленное в таком виде ФО дает возможность аналитику в про­цессе уточнения ФО конкретизировать описание моделируемой системы пу­тем задания для каждого объекта одного конкретного типа из множества воз­можных, то есть определение интерпретации I как списка значений, в кото­ром каждая переменная имеет одно и только одно значение:

I = {ij I (Vj) (1 < j <No) (3 k) (1 < k < mj): tjk € Tj a -i (3 v) (1 < v <m,)(v * k A tj, € Tj) A ij = tjk).

На этом действия аналитика по уточнению ФО заканчиваются, после чего соответствующее программное средство осуществляет:

проверку выполнения условия истинности всех предикатов, входящих в ФО, на этой интерпретации по правилу (Vj) (1 < j < L) [ (3 k) (1 < k < |Sj|) (d| (I) true) ^ (B_k = true) ];

элиминацию ложных предикатов из ФО.

Таким образом, по одному ФО может сформировано множество уточ­ненных описаний, каждое из которых может самостоятельно использоваться как исходные данные для построения текста модели, а процесс уточнения выполняется по отношению ко всем предикатам ФО "сразу", а не путем по­следовательности запросов к аналитику и обработки его ответов, как это име­ет место в модели, описанной в п. 3.3.

Пример построения текста модели, демонстрирующий применение описанной выше методики, приведен в приложении 8.

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

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

построение булевой матрицы отношения "зависит от" для всех вход­ных параметров модели:

1 - если параметр j зависим от параметра i,

Мсти (i j) ^—

О-в противном случае; сжатие Мо™, необходимое для уменьшения ее размерности и упроще­ния дальнейшей обработки (склейка строк для векторов);

упорядочивание строк по типам переменных — скалярные величи­ны, векторы, матрицы, таблицы, выражения;

построение матрицы транзитивного замыкания отношения Мао,*; ранжирование элементов матрицы Мотн* по итерационному алгорит­му, в соответствии с которым все независимые параметры получают ранг "1", а далее при каждой итерации номер итерации присваивается в качестве ранга всем параметрам, зависящим только от тех параметров, которые уже имеют ранг/41/.

Наличие вычисленных рангов позволяет организовать действия пользо­вателя при задании и корректировке исходных данных для моделирования через механизм статуса параметров. В полном списке параметров для каждо­го из них указывается один из следующих статусов:

"определен" - значение параметра уже задано пользователем;

"может быть определен" - значение параметра еще не задано, но может быть задано;

"не определен" - значение параметра не может быть задано, так как оно зависит от значений хотя бы одного параметра, имеющего в данный мо­мент статус "не определен" или "может быть определен".

Изначально статус "может быть определен” присваивается только па­раметрам первого ранга. В дальнейшем при задании пользователем какого- либо параметра его статус изменяется на "определен", и, если это был по­следний не заданный параметр i-ro ранга, осуществляется приписывание параметрам (i* I )-го ранга статуса "может быть определен".

Если же пользователь изменяет значение некоторого ранее определен­ного параметра i-ro ранга, от значения которого зависят какие-либо уже за­данные параметры старшего ранга, то параметры (i+l)-ro ранга получают статус "может быть определен", а параметры (i+2)-ro, (i+3)-ro и т. д. рангов получают статус "не определен".

Этот способ позволяет пользователю вводить и корректировать зави­симые параметры, не заботясь о выявлении их взаимосвязей. Следует отме-

тить, что

данный способ может быть применен в любой диалоговой системе, предполагающей задание взаимосвязанных параметров.

Отдельной особенностью САИМ на принципах МУ является возмож­ность формирования полиязыковых моделей, так как в ФО в качестве агрега­тов могут быть указаны имена процедур на языке, не являющемся входным языком базовой системы моделирования, но поддерживаемой ею для разного рода программ выхода. В целом полиязыковость означает возможность как интеграции фрагментов модели, описанных (представленных) на различных по своему классу языках, в единую модель, так и возможность комплексиро- вания модели (моделирующей среды) с программными средствами» не вхо­дящими в состав системы моделирования. В ходе работ по созданию различ­ных версий САИМ были использованы три подхода, позволяющие реализо­вать свойство полиязыковости при создании новых и модификации сущест­вующих систем моделирования:

расширение возможностей интерпретирующей системы путем создания программных средств поддержки межъязыкового интерфейса;

формирование средств поддержки моделирования в рамках универсаль­ного языка программирования;

интеграция полиязыковых средств в интерпретирующую среду.

Опыт создания полиязыковых моделей показал высокую эффективность такого подхода с точки зрения вычислительной эффективности получаемых моделей /38,46, 55/.

Описанная выше методика построения средств порождения имитацион­ных моделей по схеме метауправления на основе агрегативного подхода раз­рабатывалась и апробировалась более 10 лет - /223, 289, 294/. Будучи изна­чально ориентированным на параметрическую настройку моделей /289, 294/, в дальнейшем под влиянием /9/ используемый подход существенно перерабо­тан на предмет использования метауправления и осуществления гибкой ком­поновки текстов моделей.

В ходе апробации методики были созданы три вер­сии системы автоматизированного построения имитационных моделей, отли­чающиеся базовой системой моделирования (GPSS, СИМ П Л С), средой функ­ционирования (СВМ, MS-DOS) и функциональными возможностями. Все они прошли многолетнюю апробацию в различных проектах в ряде организаций: наиболее сложные модели сетей связи и систем автоматизации были разрабо­таны в НПП "Полет" (г. Н-Новогород), ИНТЕЛ ТЕХ (г. С-Петербург), СПВВИУС (г. С-Петербург). Проведенная апробация показала состоятель­ность использованного подхода и подтвердила высокое качество выполнен­ной программной реализации. Ее результаты нашли частичное отражение в /10, 36, 48, 52, 53, 69, 76, 77, 85, 224/, а программная реализация полностью представлена в /86,87/.

3. Методика построения системы интеграции отчетно­аналитической информации в иерархически организованной системе управле­ния с использованием унифицированных спецификаторов документов

В любой сисгеме управления (СУ), в которой имеется контур обратной связи с объектом управления, осуществляется сбор информации состояния /102,106, 107,295,296/. Описываемая методика разработана применительно к иерархически организованным СУ в составе организационно- технологических систем, для которых характерны (/100,102,106,297 - 299/):

наличие организационно-технологических процессов, направленных на получение определенного результата с заданным расходованием ресурсов в различных областях деятельности (например, образование, медицинское и социальное обслуживание, управление деятельностью муниципальных обра­зований и т. д.);

наличие коммуникационных процессов, направленных на обеспечение достаточного информационного взаимодействия территориально распреде­ленных элементов СУ;

отсутствие жестких требований по оперативности реализуемых процес­сов сбора и обработки информации;

управление осуществляется не как реакция на единичные события, а как оценивание ситуации "в целом" и выработка управляющих воздействий по изменению или поддержанию сложившейся ситуации;

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

К числу подобных систем относится абсолютное большинство админи­стративных и информационно-административных служб различных мини­стерств, ведомств, и управленческих структур субъектов федерации - напри­мер, разного рода популяционные регистры (раковый, врожденных пороков развития, заболеваний диабетом и им подобные - /300 - 303/ и др.), санитар­но-эпидемиологическая. ветеринарная, экологическая и иные службы и т. д.

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

Суть выполняемого преобразования поступающих документов в про­цессе формирования сводных (обобщенных) документов заключается в раз­биении получаемых сведений на два множества, над первым из которых вы­полняется операция объединения (композиции), а над вторым — обобщения, состоящая в получении интегральных оценок путем ^Рсвертки^п вектора значе­ний в скалярную величину по тем или иным правилам (суммирование, выбор максимального значения и т. д.).

Рис. 4.6 Основные компоненты процесса интеграции ОАД

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

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

Если СИАОИ создается на базе синтаксически неизменной ИС, то при ее эксплуатации возникает ряд проблем, прежде всего обусловленных фикси- рооанностью форм ОАД и правил их формирования, а также реализованных возможностей отбора сведений из информационной базы для формирования ОАД.

Кроме того, на практике подобные ИС нередко создаются в рамках ге­терогенных динамичных компонентов (возможно, даже различной ведомст­венной и административной принадлежности), и поэтому при создании по­добных СИАОИ необходимо учитывать следующие факторы:

сложившуюся организацию СУ;

установившиеся процедуры и периодичность сбора отчетно- аналитических документов, их объем и периодичность формирования;

имеющее место сочетание традиционных и автоматизированных спосо­бов формирования, передачи и обработки отчетно-аналитических докумен­тов;

разнородность используемых средств вычислительной техники, общего и специального программного обеспечения, несовместимость абсолютного большинства используемых средств по кодировкам, форматам представления

и алгоритмам обработки данных, а довольно часто - и по применяемым тер­минам и понятиям;

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

Перечисленные факторы, а также специфика целевого назначения СИАОИ (относительно низкая интенсивность формирования документов, не­оперативный характер функционирования вне реального масштаба времени по отношению к организационно-технологическим процессам, не относящих­ся к числу критических /161, 165/) приводят к тому, что применение "класси­ческой¹¹ методологии создания корпоративных информационных систем /7, 118, 171, 304/ в данном случае будет кране малоэффективным в силу низкой рентабельности подобных проектов. На практике административные службы (ФЕ верхних уровней иерархии) доводят до нижестоящих ФЕ требования к формам и периодичности формирования ОАД, но крайне редко обеспечивают средствами автоматизации формирования этих ОАД или финансами на их приобретение, оставляя решение этого вопроса за руководителями организа­ций и предприятий (см., например, /304 - 307/ и многие другие приказы и рас­поряжения), откуда и возникает разнородность состава средств, осуществ­ляющих формирование ОАД в СИАОИ.

Таким образом, при создании и эксплуатации СИАОИ в иерархически организонанных СУ решению подлежат следующие основные проблемы:

обеспечение высокой адаптивности средств автоматизированного фор­мирования ОАД в составе ФЕ к изменению форм документов и правил их формирования;

обеспечение взаимодействия разнородных средств ФЕ.

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

С учетом вышеизложенного несомненный интерес представляет по­строение СИАОИ с использованием метауправления, целесообразность при­менения которого обусловлена следующим /18/:

если невозможно или нецелесообразно стандартизовать и унифициро­вать используемые программные средства, то можно поступить таким обра­зом по отношению к информации, являющейся определяющей (или управ­ляющей) для формируемых и обрабатываемых документов;

введение новых форм и правил формирования документов и изменение существующих при использовании МУ будет сводиться к созданию и коррек­тировке метаинформации - без изменений или с минимальными изменениями в программных средствах, и может осуществляться централизованно;

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

СИАОИ может либо изначально создаваться как ИСМУ, либо путем создания ИСМУ для ФЕ, образующих некоторое ядро СИАОИ, интегрируе­мое с существующими средствами, не поддерживающими применение мета­управления, посредством специальных программных "шлюзов” - рис. 4.7. Привлекательность второй стратегии обусловлена тем, что она не требует единовременных затрат

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

Рис. 4.7. Основные компоненты комбинированной СИАОИ

Разработанная методика построения системы интеграции отчетно­аналитической информации в иерархически организованной системе управ­ления с использованием унифицированных спецификаторов документов предполагает:

создание информационных систем ФЕ как ИСМУ с использованием вычислительной схемы с характеристическим вектором <1,2, 1, 1, 1> (см. п. 2.2);

применение КМИ трех типов: номенклаторов доменов, фильтров дан­ных и спецификаторов документов, а собственно документы рассматриваются совокупность метасведений и определенным образом структурированных предметных сведений;

применение специально разработанного XML-приложения, являющего­ся расширением XML-приложения для базовой модели представления мета* информации, описанного в п. 3.2.2, п качестве лингвистического средства представления КМИ и документов.

Из-за большого объема описание разработанного XML-приложения приведено в приложении 9. где также показана возможность настройки XML- редактора, описанного в п. 3.S, для формирования номенклаторов доменов, спецификаторов документов и фильтров данных. Несмотря на большое коли­чество добавленных тегов, правила конкретизации КМИ для данного XML- приложения идентичны рассмотренным в п. 3.3 с учетом указанной в прило­жении 9 принадлежности правила конкретизации каждого добавленного тега к одному из числа базовых - "И", "ИЛИ", "МИЛИ", "повтор” и "необязатель­но".

Структура, правила формирования и интерпретации номенклаторов до­менов. фильтров данных, спецификаторов документов и самих документов имеют ряд специфических особенностей, подробно описанных в приложении

10,

а ниже приведены только ключевые моменты рассматриваемой методики, связанные с использованием КМИ в общем процессе интеграции ОАД.

Обобщенная схема применения КМИ в интересах интеграции ОАД изо­бражена на рис. 4.8. Все КМИ, а также документы имеют паспорта подлежат хранению в репозитарии информационной базы ИС ФО, а процесс помещения КМИ в репозитарий представляет собой опубликование КМИ, сопровождае­мое назначением ему глобального уникального идентификатора (ГУИ) (см. структуру паспорта, а также ГУИ и алгоритм его вычисления в приложении 2).

Номенклатор понятий (далее - номенклатор) фиксирует онтологию до­мена ПрО, доступную при последующем описании форм ОАД и правил их формирования, с единым толкованием семантики элементов понятийной мо­дели (в этом плане номенклатор домена и номенклатор, описанный в п. 4.1, совпадают). Каждый номенклатор Н из множества опубликованных номенк­латоров Н в общем случае содержит четыре раздела:

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

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

Н_зг - "интегрированные сведения", к которым относятся сведения, вы­числяемые на основании множества кортежей данных, "видимых" на момент вычисления этих сведений (например, моменты случайной величины и т. д.);

Рис. 4.8. Обшая схсма формирования и использования КМИ

H41 — "правила фильтрации", задаваемые как множество возможных элементарных критериев отбора (выборки) сведений.

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

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

В силу специфики СИАОИ прерогатива разработки номенклаторов принадлежит старшим в иерархическом отношении ФЕ, а нижестоящие ФЕ потенциально могут расширять номенклатор в своих интересах (например, номенклатор иммунологической службы Министерства здравоохранения мо­жет быть дополнен на региональном уровне понятиями, специфичными для иммунологической службы этого региона). Изменение номенклатора тожде­ственно изменению синтаксиса ИС СИОАИ и требует адекватных изменений в ассоциированных процедурах. В идеале версии номенклатора должны рас­сылаться нижестоящим ФЕ вместе с библиотекой ассоциированных проце­дур, обеспечивающих его применение.

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

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

Спецификатор документа (далее - спецификатор) является описанием формы документа и параметров его отображения, а учитывая установленную процедуру конкретизации и интерпретации спецификатора, он, по сути, зада­ет и правила формирования документа.

Синтаксис спецификатора достаточно сложен (см. приложения 9 и 10), так как выбранный подход к определению структуры спецификатора предпо­лагает фактическое объединение трех уровней описания документа: концеп­туального, логического и представления (компоновки), которые обычно рас­сматриваются отдельно (например, в /186,309/).

В первом приближении можно считать, что спецификатор есть объеди­нение описаний фильтров данных и одного или нескольких компонентов до­кумента. Описания фильтров данных задаются в том же виде, как и для фильтров данных как отдельных КМИ, н дают возможность статического за­дания правил отбора сведений для формирования документа (например, если формируется список сделанных прививок от полиомиелита, то в специфика­торе явно указывается отбор сведений по типу прививки). В случае необхо­димости усечения получаемой выборки непосредственно во время формиро­вания документа при интерпретации спецификатора могут быть указаны фильтры данных, условия которых также будут учтены (например, фильтр "пациенты 10-го участка" в приведенном выше случае даст возможность ди­намически ограничить получаемый список прививками только но 10-му уча­стку).

Каждый компонент документа может быть одним из типовых компо­нентов документа (ТКД): надписью, список или таблицей, причем ТКД до­пускают определенную возможность композиции - элементом списка может быть таблица, а содержимым ячейки таблицы - список или надпись и т. д. Различие между списком и таблицей заключается в том, что в список поме­щаются строки, каждая из которых формируется по одной строке выборки, а в таблице при формировании содержимого ячеек доступна только вся выборка, и оперировать можно с ее характеристиками — сумма значений поля, объем выборки и т. д., в том числе путем использования этих характеристик как ар­гументов функции пли операндов арифметического выражения.

Описание каждого ТКД в общем случае включает в себя три группы сведений:

дополнительные условия выборки, формируемые по содержимому чет­вертых разделов номенклаторов и дополняющих действующие правила по­строения выборки на период формирования данного ТКД (для таблиц такие условия могут быть заданы и для отдельных строк и столбцов);

сведения, определяющие содержание надписей, элементов списков и ячеек таблиц через элементы содержимого первого, второго и третьего разде­лов номенклаторов (в зависимости от вида ТКД);

сведения, определяющие правила композиции, представления и ото­бражения содержимого ТКД (заголовки, сортировки, нумерация, стили и форматы и т. д.).

Использование спецификатора обеспечивается как ассоциативными процедурами элементов номенклаторов, которые внедрены в спецификатор,

так и процедурами, обеспечивающими интерпретацию вершин ИСФ специ­фикатора ’’надпись", "список" и "таблица".

Фильтр данных и спецификатор являются КМИ, которые могут быть выполнены, то есть подвергнуты конкретизации (по правилам, описанным в п. 3.3) и интерпретации, причем выполнение фильтра всегда осуществляется в контексте выполнения спецификатора.

Процесс интерпретации спецификатора может быть описан следующим образом:

по конъюнкции статических правил отбора сведений, содержащихся в спецификаторе, и содержимого указанных пользователем фильтров данных определяется выборка, на которой будет формироваться документ;

осуществляется последовательное формирование компонентов доку­мента (с учетом возможности “вложенности" ТКД процесс формирования компонента "верхнего" может иметь рекурсивный характер).

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

Результатом выполнения спецификатора является документ - совокуп­ность сигнатуры и структурированных сведений. Сигнатура представляет со­бой сведения о том, как именно был конкретизован спецификатор, по кото­рому впоследствии был сформирован именно данный документ. Установле­ние соответствия между структурными элементами документа, описанными в его спецификаторе, и сведениями, содержащимися в самом документе, осу­ществляется в два этапа: автоматическая конкретизация спецификатора по сигнатуре и сопоставление вершин "надпись”, "список" и "таблица” ИСФ конкретизованного спецификатора со списками данных в документе. Этот процесс имеет место при визуализации документа (представлении его в виде

текста) и при использовании содержимого документа в интересах формиро­вания других документов (см. ниже). Таким образом, передаче документа ме­жду ФЕ фактически передаются только сигнатура и предметные сведения, входящие в документ. Наличие у ФЕ-получателя спецификатора полученного документа последующие визуализация документа и использование содержа­щихся в нем сведений затруднений не вызывают, чем и обеспечивается в том числе независимость процессов пересылки и обработки документов от вы­числительной платформы и используемых программных средств.

Возможность формирования документов по содержимому ранее сфор­мированных документов представляет собой мощное средство агрегации и интеграции отчетно-аналитической информации. По сути, используемые при этом теги задают правила извлечения сведений из имеющихся документов, их компоновки и (или) использования при вычислении элементов компонента формируемого документа. Например, из списка можно "вырезать" один или несколько столбцов, из таблицы ячейку или множество ячеек и т. д., и исполь­зовать строки, столбцы, ячейки в том числе в формулах для вычисления, на­пример, значений ячеек формируемой таблицы (например, получив таблицы по заболеваемости от множества учреждений, можно построить не только сводную таблицу, но и таблицу, характеризующую распределение нозологии и частоты заболеваний по району, городу и т. д.). Будучи один раз указанны­ми в спецификаторе, данные правила могут быть применены к различным ра­нее сформированным документам, выступающим носителями конкретных аг­регируемых и интегрируемых сведений. Процессы агрегации и интеграции MOiyi носить многоступенчатый характер, позволяя получать необходимый сводный документ путем агрегации и интеграции сведений из сводных доку­ментов более "низкого" уровня интеграции - рис. 4.9.

Рнс.4.9. Пример последовательности формирования документов

Описанная выше организация процессов создания и обработки доку­ментов в наиболее полной мере отвечает потребностям процесса интеграции отчетно-аналитической информации в многоуровневой системе управления благодаря возможностью адаптации процессов интеграции информации и единству построения информационно-лингвистического обеспечения.

Адаптация к изменениям содержимого информационных потоков дос­тигается:

возможностью модификации (наращивания) содержания номенклатора понятий;

возможностью описания новых форм документов с пересылкой их спе­цификаторов всем заинтересованным пользователям системы и отказа от использования спецификаторов документов, применение которых прекраще­но.

Единство построения информационно-лингвистического обеспечения реализуется:

использованием единого номенклатора (группы номенклаторов);

возможностью обмена между пользователями системы номенклатора- ми, спецификаторами и содержанием документов в единой форме представ­ления, определяемой выбранным языком представления;

централизованным выполнением действий по ведению номенклаторов и разработке спецификаторов документов, используемых в СИОЛИ.

Данная методика построения СИАОИ использована при создании се­мейства ряда программных комплексов лечебно-профилактических учрежде­ний ("Автоматизированная система профилактических осмотров детского на­селения АСПОН-Дт" /310/» "Управление иммунизацией" /311/)» а также при создании региональной системы мониторинга врожденных пороков развития, охватывающей множество разнородных лечебно-профилактических учрежде­ний и Городской консультативно-диагностический медико-генетический центр г. С-Петербурга /303/. Кроме того, рассматриваемая методика пред­ставляет собой достаточно перспективный подход к построению подсистем сбора результатов разного рода мониторинга, интерес к которым возрастает в последнее время /30,33/.

4. Концептуальная модель синтаксически вариантной аналитической информационной системы и методика ее предметной адаптации

Создание и внедрение аналитических информационных систем (АИС), основанных на применении технологий хранилищ и интеллектуального ана­лиза данных, в настоящее время рассматривается как один из наиболее пер­спективных подходов к созданию высокоэффективных систем поддержки принятия решений на основе применения современных информационных технологий» математического аппарата и средств вычислительной техники /312-315/.

Главной предпосылкой появления в начале 90-х годов концепции АИС как отдельного класса ИС явилось осознание возможности принципиально нового подхода к осуществлению сбора и анализа информации в системах стратегического и оперативного планирования и управления» основанного на:

использовании разнородных источников данных в едином кибернети­зированном информационном пространстве (или инфосфере);

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

Базовыми компонентами АИС по /68,316 - 325/ являются: аналитическая оболочка (АО), реализующая технологию интеллекту­ального анализа данных (ИАД) (Data Mining) и основанная на совокупности методов количественных и качественных исследований сверхбольших масси­вов разнородных ретроспективных данных;

информационная подсистема, основанная на технологиях хранилищ данных (ХД) (Data Warehouse), витрин данных (ВД) (Data Mart) и оперативно­го анализа данных (On-Line Analytical Processing, OLAP);

соответствующим образом организованные вычислительная среда и средства сбора информации, реализация которых базируется на известные, апробированные технологии и средства.

Авторами работ /68, 312, 314, 316 - 318/ и др. утверждается, что ком­плексное использование перечисленных технологий позволяет реализовать следующие возможности:

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

обнаружение и исследование скрытых закономерностей, факторов, тен­денций и взаимосвязей;

агрегация и интеграция информации, необходимой для обоснования и принятия решений;

формирование альтернативных решений и поддержка выбора "опти­мального" в соответствии с заданным критерием и результатами анализа сце­нариев развития ситуаций;

моделирование процесса эволюции состояния объеюа в нестационар­ной неоднородной среде и т. д.

Следует отметить, что:

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

направление исследований, связанное с созданием аналитических ин­формационных систем еще находится в начальной стадии своего развития, оно определилось и бурно развивается с середины 90-х годов, поэтому в на­стоящее время имеются только лишь отдельные образцы соответствующих инструментальных средств и некоторый опыт их создания и применения;

практически отсутствует отечественный опыт разработок в данной об­ласти.

В то же время интерес к АИС в настоящее время чрезвычайно высок, и прежде леею - со стороны органов государственного управления, силовых структур, крупных холдингов и банковских структур (достаточно посмотреть на перечень материалов на открытом в 2000г. сайте www.olap.ru). Однако имеющиеся коммерческие образцы систем НАД (изделия Microsoft, Oracle, SAS Institute и др.) при своей достаточно высокой стоимости имеют весьма существенный недостаток - сочетание фиксированного набора средств мате-

магического инструментария с частными программно реализованными мето­диками решения задач анализа (/174, 326, 327/ и др.). Это приводит как к су­щественному ограничению областей применения указанных систем и решае­мых задач управления, так и к высокому риску неверного выбора потенци­альными пользователями инструментария, адекватною решаемым ими зада­чам. Общая ситуация с применением АИС осложняется еще и слабой насы­щенности рынка, отсутствием развитых мехашпмов анализа опыта примене­ния систем ИАД и уникальности прагматических аспектов их использования (более того, в современных условиях сам факт, а также методики и результа­ты применения систем ИАД зачастую приобретают статус "ноу хау" /328/).

Таким образом, при создании АИС основной проблемой становится обеспечение корпоративной деятельности множества экспертов с динамиче­ской адаптацией множества средств хранения данных и инструментов ИАД к классам решаемых задач и предметным областям. При этом каких-либо огра­ничений на используемые частные методики ИАД, состав математического инструментария, а также задачи и области применения АИС на момент ее разработки принципиально не накладывается, так как функциональные тре­бования к АИС в части объектов анализа, классов решаемых задач, методов и схем их решения на момент создания АИС зачастую могут быть определены только предположительно, а области их применения могут характеризоваться большой степенью неопределенности и высокой динамикой (что, например, имеет место при применении АИС в интересах информационной борьбы и особенно - защиты информации /329 - 331/). Вышеизложенное порождает потенциальную неоднозначность в проектировании АИС, неразрешимую в рамках традиционных архитектур и технологий создания корпоративных ин­формационных систем.

По результатам анализа подходов к созданию адаптивных программных систем и опыта применения метода метауправления были сформулированы

два базовых принципа системной интеграции, обеспечивающих .формирова­ние АИС нового поколения /25,27,32,61/:

многоуровневый подход к синтезу архитектуры и профилей АИС и формализации процессов ее функционирования;

создание АИС как синтаксически вариантной информационной систе­мы, вариантность которой реализуется на основе метауправления в виде со­вокупности процессов формирования и обработки компонентов метаинфор­мации.

Результатами применения многоуровневого подхода к синтезу архитек­туры и профилей АИС и формализации процессов ее функционирования яв­ляются (рис. 4.9):

декомпозиция процессов функционирования АИС; потенциальный состав пользователей АИС и распределение их возмож­ностей и обязанностей с позиций участия в функционировании АИС;

двухступенчатый характер хранения и обработки предметный сведений; функциональная, организационная и техническая структуры, архитек­тура и профили АИС и соответствующие отношения отображения (структуры

• на профили, а профилей - на архитектурные компоненты).

Процессы функционирования АИС, являющиеся основой для синтеза ее функциональной структуры, определяются путем выделения управляющего, основного (содержательного) и обеспечивающего процессов, и формализуют­ся как три взаимосвязанных уровня управления функционированием АИС (рис. 4.10):

стратегический (управляющий) — уровень управления охватываемой предметной областью и классом потенциально решаемых задач в рамках ди­намически формулируемых конкретных проблем анализа и прогностики, представляющий собой процесс управления структурой и содержанием хра-

нммых предметных сведений, а также множеством программно реализо­ванных математических методов, обеспечивающих решение задач ИАД

Рис. 4.9. Объекты и результаты применения многоуровневого подхода

оперативный (основной) - уровень отдельных задач в рамках общей решаемой проблемы, на котором по отношению к каждой задаче выполняют­ся этапы се постановки, анализа и решения;

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

Потенциальный состав пользователей ЛИС, являющийся основой для синтеза организационной структуры, определяется как совокупность еле-

дующих должностных лиц, контура информационного взаимодействия кото­рых показаны на рис. 4.11:

лицо, принимающее решения (ЛПР) - руководитель, осуществляющий постановку проблем и задач и являющийся для АИС конечным потребителем получаемых результатов;

предметный эксперт (ПЭ) - специалист предметной области, несущий основную нагрузку по определению состава и содержательному анализу предметных сведений, а также результатов их обработки;

эксперт-аналитик (ЭА) - специалист, осуществляющий выбор методик решения задач и выполняющий их решение на основе формальных методов обработки;

администратор данных (АД) - лицо, выполняющее действия по сбору необходимых предметных сведений и помещению их в хранилище данных;

системный интегратор (СИ) - лицо, осуществляющее управление служ­бами АИС, ее конфигурированием и содержательным наполнением.

Двухступенчатый характер хранения и обработки предметный следует из специфики функционирования АИС и предполагает разделение информа­ционного хранилища на две части - хранилище данных и витрины данных (см. рис. 4.11). В первом приближении хранилище данных предназначено для хранения всех предметных сведений, собранных АД и совместно используе­мых другими пользователями путем выбора необходимых сведений и копи­рования их в витрины данных. Последние представляют собой локальные информационные хранилища, цикл жизни которых ограничен рамками про­цесса решения одной задачи. В витринах данных размещаются как исходные предметные сведения, необходимые для решения задачи, так и все результа­ты, получаемые в процессе ее решения. Совокупность ХД и БД, а также ин­формационных связей (потоков данных) является основой для синтеза ин­формационной структуры АИС. Детальное описание разработанных вариантов

функциональной, организационной, информационной и технической структуры АИС, ее профилей и архитектуры приведено в /59/.

Рис. 4.11. Состав и взаимосвязи рабочих мест пользователей АИС

Второй принцип построения АИС - создание ее как СВИС - является приложением концептуальных и методологических основ построения ИСМУ, изложенных в главах 2 и 3, к построению АИС с учетом следующих особен­ностей ее архитектуры и организации функционирования:

два уровня хранения данных - наличие хранилища данных и витрин данных, заполняемых по содержимому ХД в интересах решения отдельных задач;

наличие в составе пользователей АИС системного интегратора, который может осуществлять разработку и модификацию библиотек ассоциированных процедур и математического инструментария как часть действий стратегиче­ского уровня управления функционированием АИС (см. рис. 4.10).

В целом применение метауправления при построении АИС во многом аналогично его применению в СИОАИ (см. п. 4.3 и приложение 10), основные отличия заключаются в следующем:

номенклаторы доменов соответствуют структуре ХД, имеют только два раздела ("единичные сведения" и "правила отбора сведений") и используется для формирования запросов к ХД, результатом выполнения которых является изменение содержимого БД;

запросы к ХД по своей структуре аналогичны фильтрам данных, опи­санным в п. 4.3. дополненным перечнем атрибутов, значения которых должны быть помещены в формируемую выборку;

поскольку логическая структура ВД принципиально динамична, для ее описания используется отдельный вид КМИ - спецификации таблиц ВД, соз­даваемые и изменяемые при помещении выборок в ВД;

выполнение модуля АО рассматривается как процесс формирования до­кумента, исходными данными для которого являются содержимое ВД, и ре­зультат которого (документ и его спецификации) также помещается в ВД, благодаря чему содержание процесса аналитической обработки данных зада­

ется с помощью запросов на выполнение этапов решения задачи, а формиро­вание этих запросов поддерживается номенклатором модулей и операций АО;

неконкретизованные запросы к ХД и на выполнение этапа решения рас­сматриваются как соответствующие шаблоны, представляющие собой КМИ отдельного типа.

В целом синтаксически вариантная АИС представляет собой ИСМУ с характеристическим вектором <1,2,1,1,1> и логической структурой, показан­ной на рис. 4.12. Существенно, что логическая структура синтаксически вари­антной АИС имеет некоторую симметрию по используемым КМИ и про­граммным средствам их выполнения, значительно упрощающую реализацию подлежащих созданию программных средств.

Описанные выше особенности построения АИС и применения в ее кон­струкции метауправления приводят к тому, что в ней могут быть выделены процессы метауправления трех типов, которые с использованием обозначе­ний, приведенных на рис. 4.12, можно определить следующим образом:

управление структурой ХД и составом модулей АО (то есть собственно управление синтаксисом АИС)

({< Бнхл»^нхд^>}» Rju) ^ (<$хд, Охд>, Pr), ({a,X(a),Y(a)}) -^(Sao) управление заполнением таблиц БД по содержимому ХД, и, как следст­вие - составом и содержанием спецификаций таблиц ВД

Ою(О_п(Кзхд), рхдЛвд» Ктвд) (Т'вд, Ктвд) управление содержанием выполняемого этапа решения как композиции вызовов модулей АО с указанием исходных данных для работы каждого мо­дуля, и, как следствие - составом и содержанием документов и их специфи­каций в ВД

О_м(Оо(Кзр), Твд, КтвД| Дод, Кдвд) (Т вд»К твд» Двд Д^двд) • Представление метаинформации в синтаксически вариантной АИС мо­жет быть обеспечено XML-приложением, являющимся расширением XML-

приложения для базовой модели представления метаинформации - по анало­гии, как это сделано в рамках методики, описанной в п. 4.3 (см. приложения 9 и 10), а все многообразие программных средств, обеспечивающих формирова­ние и обработку КМИ, сводится к соответствующем образом настроенному XML-редактору, а также программам конкретизации и интерпретации с использованием механизма ассоциированных процедур (см. пп. 3.3 - 3.5).

Рис. 4.12. Логическая структура синтаксически вариантной АИС

Указанные выше программные средства составляют ядро информаци­онной подсистемы АИС, фрагмент

структуры которой (в части средств, обес­печивающих использование метауправления) приведен на рис. 4.13.

Рис. 4.13. Фрагмент структуры информационной подсистемы АИС

Предметная адаптация синтаксически вариантной АИС фастически яв­ляется процедурой изменения ее синтаксиса и сводится к настройке ее ин­формационной подсистемы, предполагающей выполнение системным инте­гратором АИС ряда действий, описанных далее.

Разработка номенклатора домена предметной области осуществляется ПЭ с помощью средства создания и редактирования номенклаторов. Разрабо­танный номенклатор помещается в репозитарий номенклаторов.

Разработка логической и Физической моделей данных, соответствую­щих номенклатуру домена, выполняется либо с использованием специальных инструментальных средств, либо "вручную'¹. Результатом является описание разработанных логической и физической моделей, используемое в дальней­шем для модификации структуры таблиц БД хранилища данных.

Модификация структуры хранилища данных заключается в реализации разработанной физической модели данных путем внесения соответствующих изменений в системный каталог ХД.

Разработка ассоциированных процедур, поддерживающих использова­ние номенклатора, выполняется с использованием принятых в АИС средств программирования.

Разработка приложений для ведения основного Фонда хранилища дан­ных выполняется с использованием средств программирования, принятых в АИС. Разработанные средства, обеспечивающие ввод и модификацию подле­жащих хранению в ХД данных, передаются на АРМ администратора данных.

В целом описанный выше подход к созданию АМС как СВИС приводит к тому, что все изменения в синтаксисе системы, продиктованные необходи­мостью ес адаптации, локализуются в номеиклаторах, каталогах ХД библио­теке ассоциированных процедур и библиотеке модулей аналитической обо­лочки. Такой способ построения АИС позволяет осуществлять ее модифика­цию и модернизацию непосредственно в процессе ее эксплуатации, обеспечи- пая высокую

адаптируемость системы, и позволяет преодолеть трудности, связанные с потенциальной неопределенностью в аналитическом инструмен­тарии решения задач, имеющиеся на момент создания системы.

Кроме того, ввод в эксплуатацию АИС, созданных как синтаксически вариантные, приводит к ситуации, когда их свойства становятся динамичны­ми и уникальными для каждого экземпляра эксплуатируемой системы. Это повышает устойчивость и скрытность АИС, подлежащих использованию в потенциально агрессивных средах, а также как элемента систем управления оборонного характера /296, 332, 333/. В этом случае сама парадигма серий­ных средств воздействия и средств противодействия с фиксированными так- тико-техническими характеристиками становится неприемлема при планиро­вании, например, информационных операций /4, 334, 335/ и иных боевых действий, если в составе системы управления, являющейся объектом предпо­лагаемого воздействия или его частью, имеется синтаксически вариантная АИС. Данное положение позволяет рассматривать создание синтаксически вариантных АИС как одно из эффективных направлений перспективного раз­вития вооружения и военной техники, соответствующее общей стратегии в этой области на ближайшее десятилетие /4/.

Полное описание методики построения синтаксически вариантной АИС приведено п монографии /59/, а ее апробация осуществляется в настоящее время в Военном университете связи в рамках создания макетной версии мно­гоцелевой АИС, концепция которой описана в /68/. Опыт выполненных к на­стоящему времени работ, в частности, показал, что применение метауправле­ния позволяет существенно упростить создание информационной подсистемы АИС аа счет унификации средств формирования и обработки КМИ, а также достоинств XML как средства представления КМИ, и сосредоточить основ­ные усилия на методах ИАД и их реализации в виде модулей АО /71/.

Выводы по четвертой главе

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

2. Применение двухуровневого построения текста имитационной мо­дели, являющегося вариантом применения метауправления в построении САИМ, позволяет получить качественно более высокий уровень автоматиза­ции работ, связанных с применением имитационного моделирования, чем это обеспечивают разного рода системы и пакеты имитационного моделирования, сократить затраты на проведение имитационного моделирования.

3. Применение метауправления для описание содержания, правил фор­мирования и формы представления отчетно-аналитических документов по содержимому базы данных и других, ранее сформированных документов, в терминах номенклаторов понятий прикладной области в интересах интегра­ции и агрегации отчетно-аналитической информации может быть реализовано в рамках разработанных методологических основ построения ИСМУ и даст эффективную возможность осуществления автоматизации сбора отчетно- аналитической информации в разнородных иерархически организованных системах управления организационно-технологическими системами некрити­ческого характера.

4. Создание аналитических информационных систем как синтаксически вариантных может рассматриваться как один из основных принципов их по­строения

необходимость которого продиктована спецификой применения АИС для решения задач идентификации и прогностики в динамичных средах.

5. Все приведенные в данной главе модели и методики соответствуют частным конкретным вариантам создания отдельных классов ИС как ИСМУ, а их реализация во многом облегчается унифицированностью средств форми­рования, конкретизации и интерпретации компонентов метаинформации бла­годаря общности разработанной модели представления метаинформации и моделям процессов формирования и конкретизации метаинформации, а также общей стратегией создания XML-Приложений как лингвистического средства представления метаинформации, а при необходимости - и предметных сведе­ний.

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