Г Р А Ф И Т — б а з и с

Концепция | Методологическая структура формализации

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

Сколько базовых элементов брать при структуризации? Вроде бы это должно проистекать исключительно из знаний о рассматриваемой системе. Однако имеется и иной подход, заявленный, напр., в /3/, при котором предлагается образовывать структуру системы из триад элементов. В целом на сегодня можно говорить о тринитарном мышлении, при котором исходят из тернарных представлений об объектах познания. Вкратце изложим его основы¹.

Базовой структурой объекта является триада, т.е. комплекс из трёх элементов, так или иначе связанных между собой. Сложившиеся ранее бинарные структуры (диады) достаточны для анализа, но не для синтеза. По виду связи различают триады трёх типов: линейные, переходные, системные. Первые одномерны в семантике (упорядочены на одной смысловой оси); третий элемент может представлять промежуточное значение между двумя другими либо иметь смысл центра, «золотой середины» между крайностями (как в китайском видении мира), однако критерий оптимального центра в единственном измерении не находим. Во вторых триадах один элемент поднят на более высокий уровень, где должно быть разрешено противоречие, в котором находятся два других элемента; однако механизм снятия противоречий в этой структуре не раскрывается. Наконец, триады третьего вида образуются равноправными элементами, находящимися на одном уровне общности. По смыслу это может трактоваться как треугольник «рацио-эмоцио-интуицио» (в категориях мышления – «понятие-образ-символ»). Любые два элемента триады находятся в противоречии; каждый элемент может участвовать в разрешении противоречий между двумя другими как фактор их сосуществования в системе. Особо важной считается не полнота описания, а его целостность.

Какими будут элементы методологии формализации знаний? Предлагается выделять в ней язык представления знаний (ЯПЗ), технологию формализации (ТФЗ) и реализацию. Для наглядности определим сущность этих элементов на вполне вещественном инструменте человеческой деятельности – топоре. Большинство читателей, пожалуй, удивятся этому, но вспомним, что топор – по сути, древнейшее орудие труда, в пользовании которым начинали создаваться более совершенные, а также и добываться те самые профессиональные знания, которые мы формализуем. Кроме того, хороший топор в умелых руках – инструмент многофункциональный – квалифицированный плотник мог с его помощью не только, скажем, заготовить дрова и соорудить загон для скота (а то и ловушку для крупного зверя), но и построить дом, и лодку-долблёнку, и даже вытесать посуду, столовые приборы, вырезать простейшие украшения и игрушки; по сути, один инструмент удовлетворял все базовые потребности человека. Не правда ли, хорошая методология формализации знаний должна быть столь же совершенной?

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

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

Языков формализации техзнаний существует множество; по сути, любой алгоязык есть более или менее специализированный императивный ЯПЗ. Структура самих формализуемых знаний м.б. определена по-разному. Исходя из подходов Кауфмана или Вирта, минимально полный инфор-ЯПЗ должен распадаться на четыре подъязыка; однако, т.к. инфор-модель всегда составляется для некоего исполнителя — абстрактного или конкретного — целостный ЯПЗ должен включать модель исполнителя или явно адресоваться к такой модели, заданной вне его.

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

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

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

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

Для обобщённого описания рекомендуется методология т.н. функционального моделирования IDEF0; её стандарт опубликован на русском языке (см. /5/, а также пособия для СА, напр. /6/).

В Приложении 2 описан набор деклар-языков, пригодных для визуализации бизнес-процессов.

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

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

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

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

Математически любое графическое описание структур лежит среди конструктивных объектов особого рода – графов (граф-схем)²; при этом графическое представление маршрутов относят к классу граф-схем алгоритмов (ГСА). Процесс составления ГСА в графит-методе именуется схематизацией деятельности (импер-знаний), а ГСА в графит-языках – импер-[графит-][алго]схемами.

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

Реализация МФЗ – это информационная система поддержки употребляемого в ней языка. Вообще-то она человеко-машинная, но специально разрабатывается только машинная часть. Эту часть следует называть информатической системой поддержки (ИСП), следуя уточняемой в настоящее время терминологии информатики (подробнее см. /4, Гл.6/). Крайними случаями реализации считаем ручную – формализация полностью силами человека; автоматическую – полностью силами машины (от человека требуется только подготовить описание задачи). Практически возможна лишь в той или иной степени автоматизированная формализация знаний, когда ИСП выступает партнером человека; в первую очередь это вытекает из математического запрета на алгоритмизацию процесса построения алгоритма в общем случае.

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

Идея реализации графит-метода – охватить любые случаи максимально удобно для неспециалиста в ИТ. Поэтому как реализация рассматривается система «человек-инфортехника», где техника варьируется от простейших чертежно-письменных принадлежностей до авторамов САПР типа I-CASE, и учитывается опыт конструирования физических систем (по ЕСКД) и их производства (по ЕСТПП).

Наконец, технология. Понятно, что это процесс применения выбранного орудия. «Для топора» это последовательность элементарных операций, причём из множества, заданного в «топорном языке»; варьируются только количественные характеристики действия (скажем, твёрдый материал надо рубить или строгать с большим усилием). Понятно, что разными топорами одно и то же действие придётся совершать по-своему и с различной эффективностью.

Технология формализации импер-знаний – это процесс описания деятельности на основе данного ЯПЗ средствами конкретной ИСП. Если язык и/или реализация неадекватны сфере деятельности, то этот процесс может напоминать «варку супа из топора»:–). ТФЗ зависит и от возможностей реализации как информатической системы визуализации, например:

• «в карандаше», когда все моделирование ведёт человек (в крайнем случае рисуя на экране);

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

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

В целом ТФЗ – вещь неформальная, она должна согласовать формализм языка и ограничения реализации для достижения цели применения МФЗ – создания требуемого описания.

Итак, формальный язык представления знаний (допустим, техноязык ДРАКОН) применяется для представления содержания деятельности по определённой (но неформальной, неалгоритмической) технологии; эта технология, в свою очередь, зависит от возможностей реализации как информатической системы. Таковы основные взаимосвязи в системной триаде методологии формализации знаний.

В процессе моделирования/формализации ранее выделялись три стадии. С учётом перехода между стадиями можно выделить два уровня формальности ЯПЗ. Они меняются в зависимости именно от немаршрутных подъязыков (командного и атрибутивного), употребляемых при визуализации, образуя:

• неформальный язык – для профессионалов своего дела (носителей знаний предметной области), можно называть его «родной»;

• формальный язык – для профессионалов информатизации того или иного дела (ИТ-специалистов, таких как программисты, системные аналитики), это инфор-язык программирования (инструктирования).

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

В результате имеем базис представлений (пространство выбора) 2х2. Его измерения: степень формальности {предметно-неформальный; информатически формальный}; специализация {материальная; датаматическая}.

С т. зр. специализаций целостный ЯПЗ, образно говоря, имеет два «гардероба»:

• «родной» (предметный) – содержит «костюмы» (наборы немаршрутных подъязыков), которые «пошиты» на носителей, т.е. формулируют текст икон в терминах рода их занятий (напр., педагогики, биологии, нефтехимии, механообработки);

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

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

Сегодня чаще всего под формализацией явно или неявно понимается лишь употребление информатического гардероба, когда командное и декларативное описания подгоняются под шаблон языков программирования. Кроме того, традиционно абсолютизируется текст как единственная форма представления данных (включая отчуждённые знания), что неэргономично (об этом подробнее в /1, Гл.5,17/). Однако из целостного определения формализации, данного в /4/ и обсуждённого нами в п. 1.4.1, следует, что изначально описание деятельности «облачается из предметного гардероба». Именно здесь проявляется достоинство унифицированного и строгого визуального синтаксиса ДРАКОНа: по мере уточнения представления о деятельности правила описания её структуры не меняются, меняется лишь правила описания содержания элементов структуры.

Управляющие знания логически есть одна часть из двух (структурной и атрибутивной) в одной составляющей из четырёх (императивной, декларативной, активностной и обобщающей). Это следует из известного тезиса Н. Вирта (программа = алгоритм + структура данных + систематическое представление об исполнителе; см. в этой статье), а также из факта существования т.н. парадигмы программирования как способа увязки частей описания программы (по Вирту) в единое целое. Однако синтаксический объём этих частей в разных языках не обязательно одинаков. Существует и подход В.Ш. Кауфмана — язык программирования определяет т.н. базис трёх абстракций - данные, операции и их связывание.

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

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

В нашей стране основным языком спецификаций, пожалуй, следует считать т.н. алгоритмическую нотацию (русский псевдокод, или «школьный» алгоритмический язык), разработанную в СССР под руководством А.П. Ершова; именно на основе её немаршрутных подъязыков можно построить русский специфтехноязык (что продемонстрировано в /1, Рис.92...95/).

Язык спецификаций можно задать как самостоятельный логико-математический «гардероб», тем самым вернувшись к принципу «каждой стадии моделирования/формализации — свой языковой базис». Но можно понимать его и как часть «гардеробов» разной формальности - «родного» и информатического. Тем самым мы фактически принимаем традиционную логику построения систем, включающую эскизный проект (представляемый в «родном» базисе языков) и рабочий проект (в информатическом базисе).

За понятиями «эскизного» и «рабочего» проектов традиционно видится что-то большое и сложное. Но это не обязательно так — описание задачи или предметной области м.б. простым и кратким. Важно представить его в отптимальной совокупности форм.

Если носитель знаний знает формальный язык и главное – понимает, как интерпретировать на нём свой исходный язык, то он может автоформализовать ту или иную деятельность достаточно строго и без ИТ-специалиста, вплоть до разработки программы автоматизации «для себя» (утилитарной). Другой вопрос, всегда ли нужно обходиться своими силами?..

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

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

В начало страницы | Оглавление | Версия для печати

Copyright © Жаринов В.Н.