CASE-СРЕДСТВО СИНТЕЗА ТЕХНОЛОГИЧЕСКИХ ПРОЦЕССОВ
И МОДЕЛИРОВАНИЯ В СТАНДАРТЕ IDEF0

А.Е. Никитин,
аспирант,
В.П. Румянцев,
к.т.н., доцент,
А.В. Трусов,

ст. преп.,
МИФИ, каф.28, Москва

1. Предпосылки создания системы. Цели и средства.

Постоянный рост сложности создаваемых и изучаемых систем требует преодоления все новых барьеров. Первоочередная проблема – формализация представления знаний о системе. Новые методологии описания систем и развитие компьютерных технологий привели к появлению CASE-средств (Computer-Aided Software Engineering). Один из классов CASE-систем (upper-CASE) ориентирован на содействие в процессе анализа и проектирования. Среди методологий, получивших широкое распространение, лишь немногие приняты в качестве промышленных, а тем более, государственных стандартов. К их числу относится стандарт IDEF0 [1], последняя версия которого выпущена в 1993 г. Являющийся развитием методологии SADT [2], стандарт включил в себя опыт функционального моделирования, накопленный более чем за два десятилетия, что позволяет ему оставаться востребованным и широко используемым, несмотря на появление новых методологий.

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

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

На основе вышеизложенного, подведем итог: при разработке программного комплекса было поставлено целью реализовать разумно полезный набор возможностей, сделав продукт легким в освоении и использовании и доступным по цене для отечественных потребителей, а не обойти существующие коммерческие программные продукты по функциональности в части надстроек над стандартом IDEF0. Система призвана объединить в себе как средство ручного создания моделей (такого как AllFusion Process Modeler, MS Visio, ConceptDraw, iGrafx IDEF0), так и алгоритмы автоматизированного синтеза технологических цепочек, избавляющие аналитика от многократного повторения тривиальных операций. Выбор IDEF0 в качестве используемой нотации, во многом определяется именно задачей синтеза [3], поскольку она является одной из наиболее формальных и неизбыточных.

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

Клиентское приложение программного комплекса построено в рамках объектно-ориентированной методологии. В контексте работы с БД комплекс организован по трехзвенной архитектуре, где промежуточный уровень представлен в виде хранимых процедур на стороне сервера. Для реализации комплекса выбраны Delphi 7.0, в качестве среды разработки клиентского приложения и MSSQL Server 2000 в качестве СУБД и носителя промежуточного уровня (в том числе алгоритмов синтеза).

2. Постановка задачи синтеза технологических процессов

Функциональным описанием предметной области назовем пару , где:

– конечное множество объектов, принадлежащих некоторой рассматриваемой предметной области. Будем называть их ресурсами предметной области.

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

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

Полезные графовые интерпретации :

1. Двудольный орграф ( – множество вершин – множество дуг), где

, а , будем называть графом предметной области.

2. Орграф , где

, а , будем называть графом последовательностей предметной области.

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

Введем обозначения:

– выходы (результаты, продукты) ТП;

– входы ТП;

– чистые выходы ТП;

– чистые входы (исходные данные, ресурсы) ТП;

– промежуточные результаты ТП.

Основной рассматриваемой задачей является задача синтеза возможных вариантов ТП, на которые наложены некоторые ограничения. В качестве основных видов (возможны и другие) выделим следующие:

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

2. Ограничение на выходы. В качестве ограничения задано некоторое множество . Ограничению удовлетворяют такие , что . То есть, в рамках ТП должны быть произведены все ресурсы из множества . Направления ужесточения этого требования:

2.1. Направление «полезности». По возможности функции ТП должны производить продукты, которые полезны с точки зрения получения ресурсов из ограничивающего множества .

2.1.1. Полезность уровня 1. В ТП должны присутствовать только функции, хотя бы один продукт которых потребляется в ТП или является искомым результатом ТП. Ограничению удовлетворяют такие , что .

2.1.2. Полезность уровня 2. Все продукты, производимые в ТП должны потребляться в нем или быть искомыми результатами ТП. Ограничению удовлетворяют такие , что .

2.2. Направление «непотребляемости». Ресурсы, которые должны быть произведены в рамках ТП (то есть принадлежащие ), в самом ТП не потребляются. Ограничению удовлетворяют такие , что .

3. Ограничения на входы

В качестве ограничения задано некоторое множество . Ограничению удовлетворяют такие , что . То есть, входными для ТП ресурсами могут быть только ресурсы из . Ужесточение этого требования:

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

4. Ограничения на внутреннюю структуру ТП.

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

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

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

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

5. Ограничение на участие функций в ТП. В качестве ограничения задано некоторое множество . Возможны следующие трактовки ограничения:

5.1. Включение. Ограничению удовлетворяют такие , что .

5.2. Исключение. Ограничению удовлетворяют такие , что .

6. Количественные ограничения.

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

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

.

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

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

3. Связь модели функционального описания и IDEF0.
Недостатки модели.

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

1. Отсутствие иерархичности. Модели IDEF0 строятся по иерархическому принципу (принципу декомпозиции) применяемому как к функциональным блокам, так и к ресурсным дугам. Приведенная модель же не подразумевает наличия декомпозиции. Но это не означает, что она отрицает ее возможность. Что касается функциональных блоков, то, во-первых, функциональное описание предметной области может одновременно содержать функции различного уровня декомпозиции, а не только листовые, каждой функции можно приписать уровень декомпозиции, на котором она находится. После этого можно сформулировать дополнительные правила порядка перебора функций во время работы алгоритмов и правила их сочетаемости в ТП в соответствии с уровнем декомпозиции. Во-вторых, полученные в результате синтеза ТП можно обрабатывать специальными алгоритмами, которые будут предлагать возможные варианты организации иерархии на множестве функций ТП, в том числе, в соответствии с требованиями, предъявляемыми к моделям IDEF0. В отношении ресурсов ситуация более неоднозначная. С одной стороны, дополнить описание предметной области данными о декомпозиции ресурсов не сложно. С другой – модели IDEF0 не всегда содержат достаточно данных для восстановления этой информации. Кроме того, в реализации такого описания и модифицированных в соответствии с ним алгоритмах необходимо найти обоснованный компромисс между быстродействием обработки и объемом избыточных данных.

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

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

4. Описание прототипа. Перспективы

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

В перспективах развития также включение в CASE-средство поддержки других методологий, часто сочетаемых на практике с IDEF0 в рамках одной структурно-функциональной модели – DFD и IDEF3.

Литература

1. INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0). Draft Federal Information Processing Standards Publication 183, 1993, Dec. 2

2. Марка Дэвид А., МакГоуэн Клемент Л. SADT: Методология структурного анализа и проектирования. : Пер с англ. – М.: Мета Технология, 1993

3. Титов Д.Г. Автоматизация проектирования интегрированных информационных систем – Диссертация - М:МИФИ, 1979