Содержание
Как показано в /1, гл.17/, язык ДРАКОН с математической точки зрения является формальной системой, относящейся к классу исчислений (автор называет его «исчислением икон»). Элементы алфавита техноязыка являются аксиомами этого исчисления, а каждая дракон-схема – визуальной теоремой; правила визуального синтаксиса и правила вывода теорем сформулированы в шампур-методе. Данная система включает как часть алгебру логики, поэтому возможно графическое представление булевых функций дракон-схемами, что показано в /1, гл.9/.
Формальность ДРАКОНа позволяет однозначно определить порядок трансляции дракон-схем в программы для вычислительных машин (на АЯВУ или в машинных кодах), т.е. фактически реализовать визуальное программирование. При этом устраняются неопределенности, характерные для традиционного структурного программирования на текстовых языках, а первоначальную модель (спецификацию задачи) может составить непрограммист. Такая спецификация может рассматриваться как постановка задачи; далее автор самостоятельно или с помощью специалиста уточняет дракон-схему, переходя к более формальному командному языку и детализируя алгоритм. Так осуществляется автоформализация знаний.
Хотя на первый взгляд ДРАКОН отвергает почти всю сложившуюся практику алгоритмизации и программирования, на самом деле он является продуктом творческого развития идей структурного программирования Э.Дейкстры и особенно теории схем программ А.П. Ершова, что показано в /1, гл.16-17/. Оригинальная составляющая заключена в рассмотренных ключевых идеях языка и средствах их реализации, которые автор языка назвал "шампур-методом". При этом объектом метода является абстрактная дракон-схема (в которой отсутствует текстовая часть), также называемая шампур-схемой. Язык метода (маршрутный, или шампур-язык) с теоретической точки зрения относится к т.н. языкам крупноблочных схем. Шампур-метод фактически определяет визуальный синтаксис этого языка.
На практике ДРАКОН выступает как родоначальник семейства техноязыков; его стандартом задан визуальный синтаксис маршрутного подъязыка. При дополнении шампур-языка текстовым синтаксисом икон получается конкретный язык семейства. В частности, использование синтаксиса того или иного существующего языка программирования приводит к т.н. гибридному языку программирования ДРАКОН-Х (здесь Х-имя использованного языка). Такой прием Паронджанов называет гибридным программированием; визуал с формальным текстом именуется дракон-программой.
Примеры перехода к программам на операторных АЯВУ автор языка привел в /1, гл.12/. Построение визуала на языке ДРАКОН-Х из макроструктурных (структурных, лианных, адресных) блоков фактически эквивалентно структурному программированию на использованном языке Х. При этом иконы "Адрес", употребляемые по правилам построения силуэта, задают безусловные переходы однозначно в отличие от аналогичных операторов в текстовых языках (goto и его заменителей).
Возможно доведение визуального программирования до уровня Ассемблера (т.е. получение машинных кодов непосредственно по дракон-схеме). Все это открывает путь к глубокому и эффективному управлению качеством алгоритмов и программ как компонентов обеспечения оргсистемы (предприятия, учреждения).
Сегодня деятельность оргсистем принято описывать на основе методологий моделирования SADT (Structured Analyses and Design Technique – техника структурного анализа и проектирования) и им подобных, как методология функционального моделирования IDEF0. Мы можем принять IDEF0 в качестве средства обобщённой формализации знаний.
Применением алгоритмов-вставок в ДРАКОНе фактически достигается декомпозиция (иерархическое структурирование) описываемой деятельности, аналогичное методологии IDEF0. В то же время такая методология требует в конце концов перехода к алгоритмическому языку для алгоритмизации задачи и программирования. Тем самым расширяется не только множество языков модели, но и вводится новая форма ее представления; меняется и точка зрения на проблему. Понимание такого описания требует дополнительных интеллектуальных усилий. Поэтому следует вводить прямое соответствие между функциями (процессами) в ФМ-языке и техноязыке. Естественным является соответствие «одна функция – один визуал»; тогда дракон-схема в терминах IDEF0 является спецификацией процесса выполнения функции, получая объекты видов Input и Control явно как формальные параметры, а отдавая объекты вида Output неявно, если только они не определены как компоненты результата визуала-функции. Можно ввести также соответствие «одна функция – одна ветка силуэта»; здесь получение входных объектов также будет неявным, и отображение логики процесса (связей ФМ-блоков на связи веток) требует определённых усилий.
В случае применения ДРАКОНа в процессе формализации просто детализируется (и по необходимости уточняется) исходный визуал с повышением формальности текста икон вплоть до формул и команд. Форма представления проблемы остается неизменной (комплект дракон-схем), что снижает интеллектуальные затраты участников формализации вне зависимости от профессиональной подготовки; достаточно лишь хорошо знать используемую версию ДРАКОНа.
При моделировании процессов, которые оперируют малым числом простых сущностей (данных, предметов и т.д.), объекты можно описывать в самой дракон-схеме или как простейшее приложение к ней; однако если сущностей много и они связаны сложными отношениями, следует моделировать декларативную составляющую отдельно. Для этого нужна методология, которая удовлетворяет критериям когнитивного качества в своей сфере формализации; возможным вариантом является IDEF1X.
В то же время IDEF0 пригодна как высокоуровневая методология для обобщенного моделирования и императивной, и декларативной составляющих. Среди SADT-методологий имеются и другие, подходящие на эту роль; некоторые из них описаны, например, в /5/; в последнее время среди ИТ-специалистов популярен также язык объектного моделирования UML. К сожалению, во всех случаях предлагается при последующей детализации пользоваться набором разных языков, что снижает когнитивное качество. Однако обобщенная модель в исходной форме вполне понятна и может послужить "прародительницей" и модели деятельности по методологии ДРАКОН (комплекта дракон-схем), и модели объектов (например, комплекта диаграмм IDEF1X).
Необходимость в описании оргсистем, простом и достаточно формальном, отчетливо выявилась при внедрении систем менеджмента качества (СМК) оргсистем. Международные стандарты МОС в отношении СМК (серия 900Х) в современной версии (закрепленной в России группой ГОСТ Р ИСО900Х-2001) прямо предписывают описывать процессы деятельности (бизнес-процессы) с целью их понимания персоналом и непрерывного совершенствования, т.е. автоформализовать профессиональные знания. Рассмотрим, какие средства предлагается для этого использовать и насколько они удовлетворяют критериям когнитивного качества.
Для обобщенных моделей МОС рекомендует функциональное моделирование по методологии IDEF0; при этом, как мы отмечали выше, требуются языковые средства для строгого описания содержания IDEF0-блока.
Ещё один класс – символические сценарные языки. Они описывают процесс применения различных устройств человеком детерминированно, как командную модель. Формировались в середине ХХ в. в связи с усложнением техники, повышенными требованиями к работе оператора. Сценарий задаётся как маршрут манипуляций органами управления, выбираемый в зависимости от показаний органов индикации и иных доступных восприятию признаков работы устройства; чаще всего сценарии воспроизводятся непосредственно на пульте управления устройством. Используют специально разработанные алфавиты обозначения маршрутных переходов, состояний органов индикации, выдержек времени между манипуляциями и т.д.
Важно понимать, что сценарии такого рода в пределе не что иное, как алгоритмы для человека («педантические» командные модели). Поэтому они сами по себе в какой бы то ни было совокупности не могут покрывать всё содержание деятельности; практически это выражается в том, что либо в сценарии, либо в охватывающем его описании (обычно — в руководстве оператора устройства) определяется развилка (или ряд на различных маршрутах) вида «в случае неуспеха сценария — действовать по обстановке»; тем самым в сознании оператора «запускается» интеллектуальный процесс поиска «незасценаренного» решения.
Другой класс – языки операторных (функциональных) схем, представляющие деятельность как процесс прохождения значений входных данных (дискретных или аналоговых) через систему трактов переработки в выходные данные. При этом элементы трактов заданы через математические соотношения «вход-выход», т.н. передаточные функции. Так удобно описывать «жёсткую логику» реализации деятельности (чисто аппаратным путём), поэтому такие языки часто используются при описании управляющего оборудования. Однако те или иные функции м.б. реализованы и программно; в этом случае алгоритмы их вычисления, конечно, оптимально записывать на техноязыке.
Разновидностью данного класса являются языки схем действий. Описание на таком ЯПЗ представляет собой, по сути, визуализацию процесса вычисления выражений. Поэтому он удобен при описании вычислительных задач и подзадач. В таких средствах автоматизации, как процессоры динамических (распространяющих, жарг. «машинных») таблиц, командная модель решения задачи представляется сразу в развёрнутом виде; каждый путь получения результата записан в ячейках динатаба от начала до конца. На такую запись адекватно отображается именно схема действий; поэтому на заключительных этапах информоделирования табличных вычислений она удобнее дракон-схемы (если не используется программирование для динатаб-процессора).
Итак, для обобщённого описания системы, решающей произвольную задачу любой мыслимой предметной области, предлагается функциональное моделирование.
Возникает вопрос: а почему бы не применить ДРАКОН уже для обобщённого описания решаемой задачи? Здесь мы рискуем последовать постулату Л.А. Заде: "имеющему в руках молоток везде видится гвоздь" :) иначе говоря, встать в зависимость от средства решения задачи. Конкретно, ДРАКОН является импер-языком и потому не показывает деклар-компоненту задачи. В принципе можно использовать систему из ДРАКОНа и когнитивно-эргономичного деклар-языка, но последний ещё предстоит создать; описание же, созданное такими средствами, всё равно окажется логически разделённым, что нарушает целостность исходной точки зрения на задачу – нужны умственные усилия для воссоединения компонент. В то же время IDEF0-подобный язык обеспечивает эту целостность.
Следует взглянуть и на общее содержание объёма модели; здесь следует привлечь некую философскую концепцию. Если мы стоим на позициях материалистической диалектики, то следует считать, что описание должно раскрывать аспекты пространства, времени и движения предмета изучения на заданном направлении. Такое раскрытие для импер-компоненты частного знания автор по возможности предпринял в п. 1.4.2; специалист в области философии и общей логики, возможно, найдёт в этом описании те или иные неточности.
На системные описания можно взглянуть и в иной плоскости – считать ли при описании более важными сущности («вещи») системы, или связи (логические и физические отношения) между сущностями. Методологии типа «сущность-связь» (англ. «Entity-Relationship», напр. визуальная МФЗ стандарта ERD) как раз совмещают эти точки зрения при обобщённом описании и проясняют структуру логических отношений моделируемой предметной области для конкретного описания её через информатически строгую структуру данных.
Информатическую строгость мы понимаем в смысле иерархии уровней моделирования и формализации, введённой в п. 1.4.2: всё существенное для целей моделирования представлено явным и конечным описанием. Как понимается информатика в данном документе, см. в этом пункте.
Ещё одна плоскость рассмотрения систем – подход к определению семантики (смысла) при формализации. Были выделены три подхода на математической стадии (при специфицировании решений задач для последующего программирования): денотационный, операционный, аксиоматический. Более подробно мы на них останавливаться не будем1; отметим лишь, что подходы по современным представлениям образуют системную триаду, поэтому закономерны взаимосвязи и взаимопереходы между ними.
Обобщённое знание может представляться с т.зр. сущностей-объектов (конструкторское описание любой системы, напр. как изделия по ЕСКД, где функционирование объясняется через принципиальные схемы объекта с указанием параметров процесса в тех или иных точках) и с т. зр. сущностей-процессов ( напр. функциональное по IDEF0, где уже описание сущностей-узлов и их связь раскрыта через преобразования сущностей-ресурсов от входов блоков-процессов к их выходам); примером скорее аксиоматического подхода к описанию искусственных систем можно считать, по-видимому, теорию решения изобретательских задач (ТРИЗ) Г.С. Альтшуллера, где даются исходные структуры и элементы возможных искусственных систем (как т.н. веполи, т.е. комплексы «ВЕщество-ПОЛе») и правила «вывода», т.е. синтеза систем, решающих конкретную задачу2; аксиоматически задана структура системы и некоторые другие объекты.
Конечно, возможности ТРИЗ шире; в принципе её можно рассматривать как первый практически реализованный подход к формализации знаний о механизмах произвольной предметной области (системах-решателях задач). Заданная в ТРИЗ сегодня структурная схема машины, по-видимому, должна относиться и к информашинам.
Базовую процедуру вывода в ТРИЗ Альтшуллер и другие часто называют «алгоритмом изобретения», что являлось предметом критики (см. напр. /4, с.179/). Конечно, эта процедура скорее является «исчислением эффектов», т.е. относится к математической стадии формализации. Для частных случаев, ограниченных условий тем не менее возможно доведение её до информатически строгой, доказательством чему является возникновение т.н. «ТРИЗ-софта» – инфопрогизделий синтеза по правилам ТРИЗ; понятно, что ТРИЗ-софт является средством поддержки интеллектуальной деятельности грамотного специалиста в предметной области синтеза, но также при определённом его построении – и поддержки образования в этой области. При этом программа берёт на себя алгоритмически разрешимые компоненты решения изобретательской задачи, а человек делает всё остальное, применяя программу по неформальной технологии на базе собственного опыта.
Точно так же можно сказать, что определение ДРАКОНа явно тяготеет к аксиоматическому подходу.
Столь популярный ныне объектно-ориентированный поход, который пытаются приложить как «единственно верный» буквально ко всем предметным областям, а не только в информатике, как видим, на деле является лишь одной из возможных точек зрения. Критику его «идолизации» в информатике можно найти, напр., на форуме /8/.
До сих пор мы говорили об уровне обобщённой (предварительной) формализации знаний в целом, предшествующей уровню конкретной (детальной) формализации по частям. В качестве частей мы, следуя Паронджанову, предложили императивное и декларативное знание и соотвественно импер- и деклар-моделирование. Раскроем «секрет полишинеля», который, возможно, уже очевиден для вдумчивого читателя. Конечно же, структура частных знаний, данная в начале цикла, неполна. К импер- и деклар-знаниям следует добавить знания об исполнителях (актив-знания). В результате классификация частных отчуждённых знаний изменится; в ней появится третья подструктура, аналогичная двум введённым ранее.
Полная классификация частного отчуждённого знания
Элементы актив-знания содержатся в различных местах цикла. Более широко, любая дисциплина, имеющая предметом к.-л. средства и системы, относится к актив-знанию. Как и другие рода отчуждённого знания, оно м.б. получено как денотационное, операционное и аксиоматическое. Традиционно первые два подхода совмещаются при описании реальных систем. Так, в описаниях промышленного оборудования всегда содержатся разделы об их устройстве (составе и свойствах составных частей) и принципе действия (но не решения конкретной задачи). Это и можно считать денотационной и операционной составляющими актив-знания.
Отметим, что эти соображения не являются принципиально новыми. В своё время к тому же пришёл, скажем, один из патриархов информатики Н. Вирт, что он и отразил, в частности, в своей Тьюринговской лекции 1989 г.3
Формализация знаний об исполнителях осуществляется в различных отраслях знания. Так, в инженерной психологии в своё время предпринимались попытки описания работы операторов человеко-машинных систем так же детерминированно, как технических средств, напр. через функциональные схемы с передаточными функциями, однако выяснилось, что в большинстве случаев при этом теряется существенная информация о человеческой деятельности. Сегодня используются иные подходы, и в т.ч. процедурное описание человека как исполнителя; при этом часто начинают с весьма общего, глобального уровня, так сказать, «формализации смысла жизни». На техноязыке в частности, этим занимается Ю. Феодоритов, чьи результаты можно найти в /8, тема Дракон-схемы сознания, самосознания и свободы воли/. С системной т.зр., в принципе можно поставить глобальную задачу целенаправленной системы, из которой любая конкретная практическая задача будет следовать как частная; на основе этой постановки можно определить обобщённую архитектуру исполнителя. Интересно, что для человека как естественной интеллектуальной системы-решателя произвольных задач обоснование закономерности формирования его облика также было дано И.А. Ефремовым в ряде его литературных произведений. Та же проблема разрабатывается в рамках общей теории безопасности, одна из западных разновидностей которой известна у нас под названием секьюритологии; здесь можно отметить работы В. Ярочкина, В.А. Герасименко и С.П. Расторгуева. Автору документа довелось в учебных целях разрабатывать постановку глобальной задачи функционирования оргсистем с позиций теории безопасности; при этом также оказалось необходимым выходить на глобальные цели человека как ведущего компонента таких систем. Полученные результаты также оказались весьма общими; можно лишь отметить, что возможно сформулировать назначение системы как обеспечение безопасности в широком смысле – не только как физического выживания («спасения шкуры»), но и поддержки выживания и развития других, т.е. так, как это трактуют общеизвестные морально-этические системы, – а также дать функциональную модель реализации ОБ.
С информатической т. зр. вопросы поведения человека как звена информационных систем разрабатываются в социальной информатике, в основном в целях изучения сферы массовой информации и пропаганды; здесь можно отметить результаты Г.Г. Почепцова и С.А. Муратова. Однако не следует ожидать вывода точных закономерностей совершения человеком действий в рамках оргсистем; разумнее сегодня исходить из позиций Фридланда и Симоновича, которые определяют человека как субъекта, взаимодействующего с искусственными системами определённо по формам (сенсорным и эффекторным каналам), но произвольно по содержанию. Детальную формализацию деятельности нужно проводить применительно к конкретным задачам и человеко-машинным системам.
Если сузить рассмотрение до исполнителей-машин, то следует отметить, кроме упомянутой ТРИЗ, вновь работы по структурированию информашин в рамках инфорбезопасности. Здесь основополагающими можно считать результаты Герасименко (/3, Гл. /) и В.В. Мельникова. Кроме того, целостный подход и к понятию информации, и к средствам её переработки в своё время предлагал В.В. Фурдуев, видный советский электроакустик.
Итак, при конкретной (детальной) формализации знаний нам нужен третий класс частных МФЗ. Посмотрим, что можно предложить для этой цели из имеющегося арсенала моделирования.
Примером реализации полного (в смысле охвата всех указанных классов) набора средств формализации знаний может служить язык UML. Нетрудно видеть, что это на самом деле семейство языков, решающих разные задачи. В частности, есть и средства описания механизмов решения задач, но недостаточно развитые; открыт и вопрос о целостности описания, получаемого с их помощью. В то же время ещё в бывшем СССР предпринимались усилия в этом направлении; в частности, для моделирования и проектирования оригинальных систем автоматизации в отрасли связи был разработан т.н. структурно-топологический метод описания распределённых и иерархических инфорсим и соответствующий ему СТО-язык4. Его можно использовать для визуализации структуры исполнителей, указывая реализуемые в узлах процессы и передаваемые между ними объекты, сопрягая при необходимости с картами местности и/или планами строений, техописаниями оборудования как атрибутами элементов СТО-схем. Однако нужно рассмотреть вопрос об информатической строгости данного языка и других его характеристиках как актив-ЯПЗ.
Концепция описания искусственных систем нормативно задана в семействе стандартов ЕСКД. Здесь мы видим как различные категории средств структурного описания по назначению (структурные, функциональные, принципиальные схемы), так и различные типы схем в зависимости от физического принципа действия структурных элементов (механический, электромагнитный, гидро-пневматический). Говорить о единстве языка описания структуры механизмов, т.о., не приходится.
Формируемый последователями ТРИЗ каталог физических эффектов можно рассматривать как алфавит принципов действия элементов искусственных систем. Возможно, что на его основе можно задать графический язык структурного описания механизмов единообразно и независимо от принципа действия, подобно техноязыку.
Применительно к инфорсимам сегодня также действует отечественная система стандартов КСАС и стандарты Международного электротехнического комитета (МЭК). В частности, среди стандартов МЭК имеются нормирующие принцип структурного описания технических систем; пример их системного использования можно найти в современной работе по автоматизации производства5, где автор на добрых двух десятках страниц опровергает заявления разработчика АИС управления объектами о классификации метаструктурного построения одной из линеек его продукции по стандартам МЭК на отказоустойчивость. С содержательной точки зрения, в рыночном обществе часто продукт представляется потребителям по принципу «коммерческой правды»; однако в данном случае имеет место расхождение заявлений и действительности, которое автор работы определяет как «технический миф». Нас же интересует формальный аспект: какими средствами и способами, инвариантными к данной конкретной ситуации, этот миф развенчивается.
В упомянутом отрывке автором работы фактически строятся информатически строгие определения отказоустойчивых метаструктур на базе стандартов, а также проводится формальный анализ соответствующих заявлений разработчика, для чего сведения о его продукции также приводятся к информатически строгому виду (с восстановлением умолчаний и прояснением неопределённостей). В результате появляется возможность определить истинный класс отказоустойчивости указанных структур не только математически, но и информатически, «на пальцах» показать по шагам алгоритмического процесса, что происходит при тех или иных условиях обстановки с анализируемой структурой и со стандартными структурами заявленного и фактического классов по МЭК; тем самым делается очевидным, для какого класса анализируемая структура служит примером, а для какого – контрпримером.
Для нашего предмета важно, что для представления здесь используется как визуально-структурный язык, так и ограниченный естественный язык, т.к. возможностей первого недостаточно.
В общем и целом, поле формализации актив-ЯПЗ ещё непаханное; к счастью, пока, по-видимому, можно ограничиваться возможностями СТО и других подобных языков.
Вернёмся к деклар-направлению конкретной формализации. Оно разрабатывается для ДРАКОНа в связи с реализацией дракон-сред широкого применения. При этом часто можно видеть, напр. на веб-форуме /8/, уклон в преимущественно текстовую реализацию (напр. реализацию описаний величин как комментариев в дракон-схемах), тогда как здесь действует тот же принцип, что и для импер-моделирования: декларативное описание в своей основе д.б. визуальным. Более точно, необходим комплекс из классиф-подъязыка (визуального) и атриб-подъязыка, используемых «в связке», как маршрутный и командный подъязыки ДРАКОНа.
Комплекс деклар-языков должен позволять:
употреблять типы величин, встроенные в систему "информашина-транслятор", на которой эксплуатируются программные коды алгоритмов, визуализированных в дракон-среде;
задавать (конструировать) визуальные описания производных типов через встроенные и/или иные производные типы в виде граф-схем (т.е. поддерживать визуальный классиф-подъязык, описывающий определение произвольного типа через иные типы аналогично тому, как импер-язык ДРАКОН описывает структуру алгоритма через иконы и/или другие алгоритмы);
атрибутировать каждый тип, т.е. назначать ему конкретные значения параметризованных свойств на некотором атриб-подъязыке (пример неформального задания параметров – язык атрибуции данных из /3, Прил. 2/), причём пользователь должен иметь возможность задавать значения переменных параметров в диалоге реализации подобно тому, как это делается для типов данных в визуальных СУБД;
указывать изменяемые характеристики отображения величин встроенных и производных типов на ресурсы реальной системы (для инфорсим – модель основной памяти, устройств ввода-вывода и иных программно-доступных элементов).
Разумеется, реализация не д.б. узкоспециализированной, для чего за основу берутся прогязыки, поддерживаемые средой в качестве стандартов немаршрутной части гибридного техноязыка (Оберон, 1С и т.д.). Если разработка ведётся на несовместимой системе, необходимы средства определения встроенных типов для целевой системы.
Примером может служить комплекс языков, определённый в Разд.2 Приложения2; однако это языки качественного уровня, не обладающие информатической строгостью. Символику можно использовать как основу алфавита визуального классиф-языка.
Деклар-язык ФЛОКС мог бы служить языком конкретной формализации деклар-знания, но он достаточно узко специализирован и "приближен к машине"; тем не менее ФЛОКС можно расматривать как приближённое определение требований к такому языку, своего рода "печку", от которой можно "танцевать" при выработке стандарта деклар-языка, сопрягаемого с ДРАКОНом. В свою очередь примером машинно-независимого деклар-языка неопределённо широкого применения можно считать язык информационного моделирования методологии формализации деклар-знаний IDEF1X; в тоже время в нём прослеживается приближение к реализации IDEF1X-моделей как СУБД, т.е. некоторая зависимость от средств реализации в широком смысле имеется.
По сути, все эти языки представляются скорее денотационными. Есть и иной вариант, уже всплывавший при обсуждении дракон-сред в /8/: использовать операционно-ориентированный классиф-язык. Текстовым средством подобного рода являются БНФ-языки. По сути, их визуализацией являются языки т.н. синтаксических диаграмм. Если по аналогии с СТО-языком использовать условные вершины для задания определённых условий ветвления и цикла (вместо разветвительных вершин диаграмм), то в принципе получим аппарат визуализации структур объектов (в т.ч. типов величин).
Возможно, для реализации визуального классиф-языка такого рода необходимо математически обосновать условия укладки схем данных на плоскости без пересечений (разрывы устраняются, как и в техноязыке, иерархической декомпозицией через подстановки), подобно тому, как это сделал Паронджанов для схем алгоритмов.
Обоснованием состава частных языков с т. зр. автора документа и служит вышеприведённая полная классификация. Вместе с обобщёнными языками они должны образовывать полное множество (комплекс) средств формализации профессиональных знаний. Представлены также предложения автора документа о свойствах этих языков и их реализаций.
К имеющимся комплексам ЯПЗ и их реализациям следует подходить критически (см., напр., статья об UML в Википедии ). В Справке по Ты-среде также указано следующее: «...UML содержит большое разнообразие по назначению графических диаграмм, графических объектов и элементов отображения их взаимодействия. Соответственно, UML сложно освоить, использовать для документирования и общения с не квалифицированным персоналом. UML не имеет интеграции со средой программирования.» Однако главные недостатки UML, по-видимому, всё-таки в другом, а именно в стихийном формировании этого семейства языков, вследствие чего:
состав UML-языков не обоснован должным образом;
языки не проработаны когнитивно-эргономически сами по себе и как части целого (не всегда есть чёткая взаимосвязь разных описаний);
нет должной формальности ряда языков (поэтому и нет прямого выхода на программирование).
Критикуя, не следует «выплёскивать с водой и ребёнка»: взамен UML нужно предложить именно систему языков представления знаний, только целостную, минимально необходимого состава и имеющую выход на реализацию до уровня командных моделей (программ для информашин и/или формальных, «педантически» строгих инструкций для человека-исполнителя). В этой системе семейство гибридных техноязыков представляется достойным содержанием импер-компоненты, но нужны усилия по адекватному наполнению других компонент. Конечно, это вопросы к дракон-сообществу в целом.
Генеральное структурирование отчуждаемых знаний.
Этот докэлемент находится здесь.
В начало страницы | Оглавление | Главная | Версия для печати
Copyright © Жаринов В.Н.
1Подробнее различие между подходами обсуждается, напр., в работе: Агафонов В.Н. Спецификация программ: понятийные средства и их организация. – Новосибирск: Наука, Сиб. отд., 1990. – С. 39.
2С современной ТРИЗ можно ознакомиться, напр. в работе: Орлов М.А. Основы классической ТРИЗ. – М.: СОЛОН-ПРЕСС, 2006.
3Публикация на русском языке: Вирт Н. От разработки языков программирования к конструированию компьютеров. – Микропроцессорные средства и системы, №4/1989. – С. 42-48.
4См. Кудрявцев Г.Г., Мамзелев И.А. Микропроцессоры и микроЭВМ в системах технического обслуживания средств связи. – М.:Радио и связь, 1989. – П.1.3.
5Фёдоров Ю.П. Справочник по разработке АСУТП. – М.: Инфра-Инженерия, 2008. – С. 34-50.
