ТЕОРИЯ СИСТЕМ и СИСТЕМНЫЙ АНАЛИЗ

4.3. Объектно-ориентированная технология системного анализа

4.3.1. Принципы разработки технологии

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

Требования к регламенту:

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

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

Требования к методологии моделирования:

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

использование при построении моделей опыта экспертов.

Требования к инструментальным средствам:

открытость и интегрируемость;

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

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

1. Принцип декларативности: регламент должен предписывать вид декларативной модели, формируемой на каждой стадии, и совокупность методов, используемых для ее построения и принятия решений на модели.

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

171

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

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

На рис. 4.4 приведены три схемы автоматизированной разработки проблеморазрешающей системы. Алгоритмическая схема (рис. 4.4, а) предполагает, что последовательность преобразований исходной информации I в конечное описание R воплощена в некоторый единый универсальный алгоритм F, выполняемый информационной системой. Разработчику необходимо реализовать лишь процедуру сбора информации D и реализации готового проекта W. Данная схема идеальна с точки зрения снижения трудоемкости процесса разработки, однако в случае сложных многофакторных проблемных ситуаций она практически нереализуема.

Модельная схема (рис. 4.4, б) предполагает формирование декларативной модели M проектируемой системы с помощью инструментального средства. Инструментарий содержит процедуры построения модели FM, используемые разработчиком в интерактивном режиме для формирования модели системы «как есть» (As is) или «как должно быть» (To be). Непосредственно же принятие решений (с помощью соответствующих процедур FP) осуществляется самим разработчиком.

172

в

Рис. 4.4. Схемы автоматизированной разработки проекта:

а – алгоритмическая; б – модельная; в – гибридная

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

Компромиссом между стремлением максимально автоматизировать процедуру разработки и сложностью ее алгоритмизации является использование гибридной схемы (рис. 4.4, в). Инструментальная система, построенная по принципу систем поддержки, вместо единой процедуры содержит библиотеку процедур, которые наряду с неавтоматизированными процедурами принятия решений из общей совокупности процедур FP могут использоваться на различных этапах разработки проблеморазрешающей системы. Декларативная модель М служит интегрирующим звеном для множества процедур. Подсистема моделирования FM инструментального средства позволяет разработчику формировать модель, используя при этом библиотеку типовых моделей Mt и библиотеку процедур FP.

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

173

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

Принцип иерархичности предполагает рассмотрение системы и любой ее подсистемы, с одной стороны, как некого целостного объекта, описываемого набором свойств, характеристик и выполняемых им действий, а с другой стороны, как совокупности более мелких компонент (подсистем, элементов), взаимодействующих между собой. Таким образом, мы можем говорить о двух модельных представлениях системы (подсистемы): в виде объектной (атрибутивной) модели, представляющей собой описание эмерджентных свойств и поведения, и в виде компонентной модели, отражающей состав более мелких компонент и отношений между ними. Первое представление соответствует модели «черного ящика», второе – модели структуры. Таким образом, модель системы должна представлять собой множество иерархически связанных объектных моделей отдельных компонент.

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

иинформационной, а в реинжиниринге бизнес-процессов – прецедентной

иобъектной.

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

174

ся методы теории выбора, различные сценарные методы, а также методы инженерии знаний.

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

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

Рис. 4.5. Выбор маршрута на картах различного масштаба

175

3. Принцип итеративности: схема применения этапов системного анализа должна быть итеративной.

Данный принцип выдвигается исходя из требования гибкости регламента. Общий регламент, безусловно, должен соответствовать системной последовательности принятия решений, включающей в себя этапы анализа, постановки целей, выработки решений, реализации и оценки. При этом для отдельных классов систем могут быть предложены адаптированные к конкретной предметной области и более подробные последовательности этапов. Однако схема применения этапов, определяющая порядок их следования, не может быть жесткой, она должна быть итеративной – по типу спиральной схемы или макетной (схемы быстрого прототипирования). Необходимость итеративного регламента, допускающего возможность возврата на предыдущие этапы и корректировки ранее принятых решений, обусловлена сложностью и многоаспектностью работ, выполняемых в процессе разработки проблеморазрешающей системы. На рис. 4.6 представлена итеративная схема выполнения системного анализа.

План работ

Подготовка

Проблемы

Анализ

Цели

Постановка целей

Решения

Поиск решения

Результат

Организация выполнения

Оценивание

Рис. 4.6. Схема взаимосвязей этапов системного анализа

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

176

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

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

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

Как уже указывалось, разработчик некоторой конкретной системы должен иметь возможность использовать разнообразные процедуры системного анализа и принятия решений. Мало того, он должен иметь возможность воспользоваться не только универсальными методами из заранее сформированного набора. В процессе решения некоторой сложной проблемы ему могут понадобиться вспомогательные средства и знания из любых предметных наук. «Системный аналитик готов привлечь к решению проблемы любые необходимые для этого знания и методы» [2]. Возникает проблема сочетаемости различных методов и процедур, их интегрируемости в единый процесс. Единственным объединяющим элементом может выступить декларативная модель предметной области. Единую модель или семейство согласованных моделей, основанных на одной парадигме и использующих общий язык представления знаний, можно рассматривать, как «каркас», интегрирующую «надстройку» над множеством различных процедур, как своего рода «метазнание».

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

178

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

Решение дилеммы, заключающейся, с одной стороны, в необходимости частого обновления отдельных компонент ИС и добавления, по мере необходимости, новых, а с другой стороны, сохранения целостности системы, видится в «скелетной» архитектуре. Этот подход предполагает наличие единого каркаса – интегрирующей компоненты, допускающей присоединение различных приложений, отвечающих определенным требованиям (по интерфейсу, по форме входных и результирующих данных и т. д.). Вот что пишет по этому поводу Зиндер Е.З. в [63]: «Единственным достаточно стабильным интегрирующим элементом современной ИС может являться … только понятийная модель предметной области». И там же: «В настоящее время слияние средств представления знаний с технологией обобщенных объектов и стандартизацией в области объектноориентированных представлений реально ведет на следующий, качественно новый уровень в технологии системного проектирования».

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

179