книги / Теоретические основы автоматизированного управления

Рис. 10.4. Связь процесса идентификации (1) с процессами в экспертной системе (2)

Технология идентификации для базовой трехуровневой структу­ ры системы подробно описана в [17], в связи счем ограничимся лишь фиксацией основных ее моментов. Подобные системы часто строятся по схеме «как есть» — «как должно быть». Идентификация позволяет определить состояние «как есть» (рис. 10.4).

Воспользуемся рассмотренными ранее обобщенной моделью и обобщенной технологией (см. гл. 3).

И1. Целью исследования является управление, поэтому следует очертить границы системы управления моделью М(0) в виде «черного ящика» (рис. 10.5, а), характеризующегося векторной зависимостью

где х, у, т — вектор-столбцы входов, выходов и параметров; <р — век­ торная функция. Зависимость степени детализации модели от по­ ставленной цели Ц можно представить в виде формализованной за­ писи: Ц -> М(0).

И2. Принятая цель определяет набор элементов Э, число уровней 0 модели с распределением по ним элементов Э? при известном числе \К/,\ элементов на уровне A, h = 0, 0, где уровень h = 0 соответствует объекту управления. Данные для построения модели М(0) берутся из документов, циркулирующих в системе:

1) выбранных 5 ,8 = 1Д , из множества А (5 с Д) имеющихся доку­ ментов машинных 5М и немашинных (особенно для уровней h = 2,3) 8Р, 5 = SM KJ 8Р;

2) дополнительно сформированных у в процессе исследования моделируемой системы по результатам бесед с ЛПР.

Полная классификация документов приведена в работе [47].

Рис. 10.5. Общая схема (а) многоуровневой системы управления и виды (б, в) топологических связей

ИЗ. Перечисленные документы служат базой для выявления то­ пологии («скалярных» связей между элементами Э/ по принципу «да» — «нет»). Дальнейшее построение модели удобно проводить с уровня h = 0.

Технологические документы целесообразно подразделить на три класса:

•фиксирующие потоки ресурсов в определенной точке (на входе, на выходе элемента Э?) SOT;

•«сопровождающие» потоки ресурсов 80П ;

•отчеты и публикации уО о технологических процессах и техно­ логической линии (ТЛ) выпуска продукции.

При этом полезно использовать и результаты бесед со специали- стами-технологами.

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

Т0У = {акт, К, /е Т Г ^ К

где

Управление технологической линией характеризуется связями ОУ с многоуровневой — в данном случае трехуровневой — управ­ ляющей частью (УЧ) и описывается матрицей смежности Tou = Wkm, К е 1, KQ\ т е 1 ,К ), где а*т определяется выражением вида (10.2).

Базой для формирования матрицы T ou служат документы 5U и yU (положения, инструкции, штатные расписания, типовые структуры, технические отчеты, техническая проектная документация, видеофаммы работы АСУ).

Аналогично строится матрица Tos связи объекта управления со средой.

Документы 5U позволяют сформировать матрицу Тои размерно­ сти (Âj + Кг+ Кг) х (К\ + Кг + Кг) и Tos связей УЧ со средой.

Затем для элементов Э/Аосуществляется переход от скалярных входов-выходов к векторным, выявление связи между векторами и характера внутренних связей элементов, т.е. переход к модели М(1). Для этого скалярным величинам у*, х* ставятся в соответствие (на ос­ нове эксплуатационных документов) вектор-столбцы у* = {Уу*л}, х* =

входных воздействий, которые связаны с у*п операторами <р*„ неиз­ вестной пока структуры и численных значений параметров т*„:

Ы Л = Ч>(х*и['°Ь т*„[/0]).

Сравнивая Укп с планом р*„, получим вектор-столбец отклонений е* = р* — ук- Сопоставление наличного количества ресурсов Ь* с пла­ новыми значениями Ь* дает возможность выявить причину отклоне­ ний Еки наметить координаты управления и*[<], которые уточняются у технологов, и в общем виде записать оператор

Таким образом готовится материал для беседы с ЛПР о процедуре

где ik — вектор-функция переходов; хДг°] = рД/0]; §л — вектор-стол­ бец возмущений; [/°] = [/'] = [Г].

Просматривая операторы (10.4), (10.5) от конца технологической линии к началу, получим оператор всей линии.

Топология УЧ, определяемая в первую очередь топологией ОУ, выявляется в первичной беседе с ЛПР (по схеме «отклонения — при­

с неизвестной структурой операторов М ПА, ФАи параметрами х, т, где RA+l — результаты маркетинговых исследований; ЬА— запас ресур­ сов.

И4. Раскрытие структуры операторов (10.4)—(10.7) осуществляет­ ся на основе эксплуатационных документов 50, 5U, yU-

Для ОУ (см. рис. 10.5, б, в) при этом имеется полная числовая ин­ формация о координатах ук, хк, гк>раскрывающая класс и вид опера­ торов (10.4), (10.5), часто имеющих линейную зависимость:

в которой параметры к, xk(t) трансформируются в элементы матриц Ак, Вк, Ск, ¥к. Документально фиксируются данные об операторах среды, планах РА.

Сложнее обстоит дело с определением структуры операторов (10.7)дляУЧ. Если для операторов (линейное программирование, ка­ лендарное планирование) планирования (10.6) и управления (10.4), (10.5) она, как правило, отражена в документах 5U, то определение структуры операторов (10.7) на основе документальных числовых данных не представляется возможным в силу того, что лишь малая доля решений (управлений) иД/А) фиксируется письменно.

В этих условиях для снижения уровня неопределенности важно выявить логическую последовательность действий ЛПР по выработке решений. Для этого возможно использовать [14,17] «вторичные» бе­ седы с ЛПР с обязательной фиксацией результатов в виде документов

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

Если все решения uk(th) фиксируются, например, с помощью диа­ логовой АСУ, полученная информация может быть использована для обучения (уточнения оператора ФА) системы управления и ЛПР.

Для выявления структуры подобных операторов автор работы [17] предложил специальную оригинальную методику, в которой можно выделить два этапа:

1)определение последовательности операций управления в эле­ менте кп — оператора (10.7);

2)выявление процедур взаимодействия элементов.

Первый этап проводится с ЛПР уровня h — 1, второй — с ЛПР уровней h = 2, 3. При этом ЛПР отвечает на вопрос: «имеется откло­ нение от выполнения плана — какова последовательность Ваших действий по управлению?». Очевидно, что структура полученных операторов имеет в этом случае логическую форму.

И5. Определение числовых значений параметров для модели М(3) специфично.

В документах 5 0 и 5D, характеризующих объект управления и среду, имеются необходимые числовые данные, по которым парамет­ ры определяются методами математической статистики и теории ве­ роятностей. В качестве параметров ОУ могут быть длительности тех­ нологических циклов (запаздывания), нормы расходов ресурсов, нормативные запасы и уровни незавершенного производства, нормы выработки, тарифные ставки, т. е. данные, большинство которых в АСУ именуется как нормативно-справочная информация. Она ис­ пользуется в процедуре планирования (10.6).

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

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

Понятие «адекватность» может быть как содержательным, нефор­ мальным, так и формальным. В литературе освещена преимущест­ венно содержательная адекватность. Ее оценку предлагается осуще­ ствлять:

•доказательством отсутствия неадекватности с участием ЛПР;

•анализом чувствительности модели к параметрам;

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

•рассмотрением устойчивости системы и модели;

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

Относительно формальной оценки адекватности имеются лишь упоминания.

Очевидно, следует выделять адекватность топологическую (структурную), параметрическую, сигнальную.

Если имеет место структурная адекватность, то сигнальная адек­ ватность может быть рассмотрена для отдельных структурных эле­ ментов, системы в целом, среды (сценария). Оценка адекватности в этом случае осуществляется путем сравнения выходных координат УсМ системы (элемента) и ум[/] модели при одинаковых входных сиг­ налах Хс[?] и хм[/]. В качестве критериев сравнения могут быть, как в функциональном анализе, нормы и метрики.

Далее полагаем, что модель в должной мере адекватна исследуе­ мой системе.

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

технологии идентификации и специальной «экспертной» методики снижения неопределенности при получении информации об УЧ для изучения реальной системы приведен в работе [46].

Основными прикладными результатами явились следующие:

•идентификация структуры модели;

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

10.3. CASE-ТЕХНОЛОГИИ

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

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

Объектно-ориентированный подход основан на объектной деком­ позиции с описанием поведения системы в терминах взаимодействия объектов.

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

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

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

• возможностью сборки программной системы из готовых компо­ нентов, которые можно повторно использовать;

• возможностью накопления проектных решений в виде библио­ тек классов на основе механизмов наследования;

•простотой внесения изменений в проекты за счет инкапсуляции данных в объектах;

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

счет использования свойств наследования и полиформизма;

• возможностью организации параллельной работы аналитиков, проектировщиков и программистов.

Концепция объектно-ориентированного подхода и концепция распределенных вычислений стали базой для создания консорциума Object Management Group (OMG), членами которой являются более 500 ведущих компьютерных компаний (Sun, DEC, IBM, HP, Motorola и др.). Основное направление деятельности консорциума — разра­ ботка спецификаций и стандартов для создания распределенных объ-

Объекты

приложений

Object Request Broker

Рис. 10.6. Спецификация ОМА

ектных систем в разнородных средах. Базисом стали спецификации под названием Object Management Architecture (ОМА).

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

10.6):

•архитектура брокера запросов объектов CORBA (Common Object Request BrokerArchitecture) определяет механизмы взаимодей­ ствия объектов в разнородной сети;

•объектные сервисы (Object Services) являются основными сис­ темными сервисами, используемыми разработчиками для создания приложений;

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

•прикладные объекты (Application Object) предназначены для ре­ шения конкретных прикладных задач.

Исходя из основных положений объектно-ориентированного подхода рассмотрим концепцию идеального объектно-ориентиро­ ванного CASE-средства.

Существует несколько объектно-ориентированных методов, ав­ торами наиболее распространенных из которых являются Г. Буч, Д. Рамбо, И. Джекобсон. Б настоящее время наблюдается процесс сближения объектно-ориентированных методов. В частности, ука­ занные авторы создали и выпустили несколько версий унифициро­ ванного метода UML (Unified Modeling Language — унифицирован­ ный язык моделирования).

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

Вреальной практике в большинстве случаев имеется предыстория

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

Современные CASE-средства поддерживают процессы инжини­ ринга и автоматизированного реинжиниринга.

Идеальное объектно-ориентированное CASE-средство (рис. 10.7) должно содержать четыре основных блока: анализ, проектирование, разработку и инфраструктуру [80].

Основные требования к блоку анализа:

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

•согласованность диаграмм при хранении их в репозитарии;

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

•возможность динамического моделирования в терминах собы­

тий;

•поддержка нескольких нотаций (хотя бы трех нотаций —Г. Буча,

И.Джекобсона и ОМТ).

Основные требования к блоку проектирования:

•поддержка всего процесса проектирования приложения;

•возможность работы с библиотеками, средствами поиска и вы­

бора;

•возможность разработки пользовательского интерфейса;

•поддержка стандартов OLE, ActiveX и доступ к библиотекам HTML или Java;

•поддержка разработки распределенных или двух- и трехзвенных клиент-серверных систем (работа с CORBA, DCOM, Интернетом).

Основные требования к блоку реализации:

•генерация кода полностью из диаграмм;

•возможность доработки приложений в клиент-серверных CASE-средствах типа Power Builder;

•реинжиниринг кодов и внесение соответствующих изменений в модель системы;

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

Рис. 10.7. Идеальное объектно-ориентированное CASE-средство

Основные требования к блоку инфраструктуры:

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

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