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

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

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

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

По-видимому, нужно уточнить, какие языки оптимальны для обобщённого описания.

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

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

В любом случае ТФЗ-ДРАКОН исходит из непреложных правил, своего рода «альфы и омеги» ДРАКОН-методологии, как они понимаются автором данного документа:

1. С начала применения (на стадии информатического моделирования или раньше) дракон-схемы рассматриваются как единственный источник знания об алгоритме задачи.

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

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

Исходя из этих правил, импер-модель представляется как дракон-схема либо дракон-модель с минимальными текстовыми пояснениями (и необходимыми элементами КогниСтиль).

Понятно, что как маршрутный импер-подъязык мы употребляем ДРАКОН; а как с командным? Он служит для спецификации действий и при качественной формализации представляет их в виде текстов на ограниченном (структурированном) естественном языке.

Предложения по ограничению качественного языка мы оформили как РБНФ-выражения внутри икон алфавита техноязыка в Приложении 1.

Читатель не найдёт определённых ограничений для текста действий; этим мы хотели сказать, что на данной стадии их можно описывать так, как удобнее сочинителю. Желательно сразу придерживаться императивного стиля, т.е. описывать действия на основе глаголов.

Примерами также могут служить тексты дракон-схем из /1, Гл.6...13/.

Далее, на математической стадии командный язык должен представлять действия как некие выражения. Содержание выражений зависит от характера процесса:

Для первого рода процессов выражения содержат привычные математические операции (простейшие – арифметические и/или булево-логические – или построенные из них сложные).

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

Отталкиваясь «от жизни», мы предлагаем вводить для физической операции функцию, как показано в п/п 2.1.3.2 и текстах действий шампур-блоков 1а и 1б (см. п. 2.2.1) ; определением этой функции в символическом представлении будет комплект технологической документации на операцию, а в предметном – пакет программ управления рабочими машинами, участвующими в ней.

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

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

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

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

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

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

Итак, характер формализуемого процесса есть один из ключевых факторов ТФЗ. Более широко в сфере научного изучения деятельности указывалось, что¹: «организационно-техническая система реализует три резко отличных типа процессов:

Первый вид процессов мы вслед за Паронджановым определили как «техпроцессы».

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

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

Наша ТФЗ-ДРАКОН (как и любая ТФЗ вообще) как раз относится к третьему типу. Сам же ДРАКОН в силу универсальности маршрутного подъязыка считаем применимым для формализации процессов любых типов (возможно, с вариациями других подъязыков).

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

Взаимосвязанным существенным фактором является назначение процесса визуализации. Для информационных процессов Фридланд в /4, п. 4.3.1/ выделяет три класса назначений: познание, управление, обучение. Мы создаём технологию, инвариантную к назначению процесса; однако в разных классах, по-видимому, будут свои особенности для отдельных этапов и шагов.

Важно, что ДРАКОН может применяться в качестве и учебного, и практического (в терминологии Ершова – «производственного»), и познавательного языка (для последнего назначения мы фактически доопределили его алфавит обобщёнными блоками и вершинами).

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

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

Таковы наши предложения по командному подъязыку визуалов; разумеется, они развиваются и уточняются применительно к конкретной предметной области сочинителями.

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

Ещё один фактор – степень содержательности визуалов дракон-модели – может меняться в зависимости от стратегии подстановок.

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

Допускаем переменный уровень конкретизации визуалов дракон-модели.

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

ФЛОКС имеет узкопредметную направленность; о других языках судить трудно, ибо они сегодня ещё формируются. В основном эта работа также ведётся силами участников упомянутого форума.

Кроме того, предполагается использование языков обобщённой визуальной формализации (схематизации) в качестве «эрзац-деклар-языков». Так, ГНОМ использован Г. Тышовым в рамках его проекта ИСП-ДРАКОН (авторское название "и.с. ДРАКОН"). Судя по отзывам пользователей-программистов, существенного эффекта это не дало.

Возможно, следует развивать предложения, содержащиеся в п. 2.1.1.4.

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

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

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

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

Мы отдаём предпочтение визуализации «сверху вниз», что будет видно из дальнейшего.

Особенности реализации языка – ещё один ключевой фактор формирования ТФЗ; кроме того, они оказывают обратное влияние на ЯПЗ, в нашем случае – на стандарт семейства техноязыков. Это вкратце обсуждалось в п/п 2.1.2.2.

Подразумевается, что решение этих и других вопросов приведёт к определённым возможностям как языка ДРАКОН, так и созданных дракон-сред, из чего определится и конкретная технология визуализации в этих средах на этом языке. Однако формированию любого техпроцесса присущи и общие закономерности, и универсальные определяющие факторы; вкратце остановимся на этом.

От представления о жизненном цикле формализации

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

Для нашего процесса визуализации сказанное означает, что сначала можно выбрать ИСП-ДРАКОН, затем эскизно формализовать деятельность на техноязыке (обычно из семейства ДРАКОН-1), далее выбрать исполнителя (систему реализации модели) и под него делать рабочую формализацию (детальный визуал либо дракон-модель) уже на техноязыке спецификаций, а далее – на гибридном техноязыке из семейства ДРАКОН-2 для информашин-исполнителей и/или для формального выполнения/анализа деятельности. Точно так же мы формализуем саму ТФЗ вначале нестрого, для реализации только человеком-сочинителем, а затем строго, как максимально поддающуюся автоматизации (реализации формальным исполнителем-информашиной).

Определённую значимость при формировании ТФЗ имеет представление о жизненном цикле создаваемой информодели. Современная системная концепция² подразумевает т.н. полный ЖЦ (пожицикл) из трёх фаз: создание/совершенствование; применение; утилизация. В то же время содержание и/или инструментарий ряда техопераций совпадают для первой и третьей фаз, в связи с чем можно выделить их инвариант.

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

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

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

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

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

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

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

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

При любом методе выполняют также неформальные преобразования структуры дракон-схем (эквивалентные и/или равносильные).

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

Ещё один фактор, управляющий визуализацией – формат диосцены. Формат следует выбирать из стандартных рядов (обычно ряда A<N>), исходя из удобства восприятия. Удобно накладывать на произвольные форматы конструктивную сетку с ячейками заданного формата; по горизонтали (в ряд) укладывается определённое число ширин, а по вертикали (в столбец) – высот ячейки.

Примем, что базовая ячейка соответствует машинописному листу в книжной ориентации (А4), т.е. ширина 210 х высота 297 мм (или в альбомной A4L, т.е. 297 х 210 мм).

Когда необходимо, будем обозначать формат структурной формулой вида:

число-рядов-ячеек х формат-ячейки х число-столбцов.

Для ДРАКОНа стандартны чертёжные форматы до А4х4 и А1, а в необходимых случаях – А0 и А4хN; формат А4 не оптимален, т.к. не учитывает свойств графического языка. В общем случае неудобны и произвольные форматы, вытянутые по вертикали.

На экране устройств отображения лист показывается в масштабе (чаще уменьшенном); однако при регистрации в форме твёрдой копии обычно требуется масштаб 1:1.

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

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

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

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

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

Зададимся рядом значений базовой ширины (в мм): 20 (только для литеральных и абстрактных операторов); 30; 40; 50; 60; 80; 100; ряд можно продолжать, но для большинства случаев этого достаточно.

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

Высоты элементов определяем исключительно по размерам текста (см. п. 2.1.1).

Примем отступы текста от контуров не менее 1 мм.

Введём также критерии рационализации компоновки для ручного построения.

1. Допустим изменения ширины икон от базовой, чтобы убирать строки-«хвосты».

Примем отклонения ширины икон не более ±¼ от базовой для данной дракон-модели.

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

Допустим смещения центра икон относительно вертикали не более ¼ от заданной ширины.

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

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

1 Инженерная психология в военном деле / под ред. Б.Ф. Ломова. - М.: Воениздат, 1983.

2 См. напр.: Спицнадель В.Н. Основы системного анализа. – СПб.: Изд. дом «Бизнес-пресса», 2000. – Гл.3.