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

С учётом принятых общего состава и последовательности этапов ТФЗ, применительно к ДРАКОНУ содержание и взаимосвязь этапов можно определить следующим образом.

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

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

Можно вначале описывать задачу в текстовом виде, допустим, так, как мы описываем здесь визуализацию: отдельно модель её сущностей и отношений, содержание этапов решения через укрупнённые операции и наконец, детализацию тех операций, содержание которых неочевидно для сочинителя и/или исполнителя. Т.о. происходит качественная формализация.

Примером эскизной визуализации описания сущностей и отношений предметной области может служить схема выполнения вставки из п/п 4.1.3.2; здесь предметной областью является дракон-модель и её представление и выполнение.

Визуал может быть результатом перевода алгоритма с другого языка. Кроме того, изначально задача м.б. поставлена словесно (скажем, как основная задача УАЗО в п/п 4.1.5.1.

Описания сущностей и икон вместе с дракон-схемой (дракон-эскиз) составляют основу для последующей формализации задачи. При этом ищется математический метод решения.

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

Нестрого-математическое раскрытие неопределённости задачи возможно, в частности, средствами нечёткой логики Л.А. Заде. Для начального знакомства с этими и другими средствами данного рода рекомендуется работа /7, Гл.3/. Конкретизация для информатического моделирования возможна на базе современных методов, о которых подробнее см. п/п 4.2.1.5.

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

Возможны три рода методов алгоритмизации (в т.ч. визуальной):

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

Методы второго рода опираются на стандарт гибридного техноязыка, построенный для языка источника. В /1, Гл.12/ приведены примеры такого построения для распространённых сегодня ТЯП; основываясь на них, можно построить стандарт любого другого гибридного языка. Опыт в этом деле лучше всего приобретать на практике, переводя нужные алгоритмы.

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

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

По мере формирования деклар-стандартов для ДРАКОНа содержание типизации (и вообще деклар-моделирования), очевидно, можно будет уточнить.

Переход к информатической модели мы определили как представление всех действий через присваивание; однако сущность этого перехода не так проста. В самом деле, если матмодель задачи (или часть модели) представлена в виде квадратного уравнения ax²+bx+c=0 с известными коэффициентами, информодель мы вначале должны записать как: x:=решить(a*x²+b*x+c=0; а:=число1, b:=число2, c:=число3) и далее «растехноложить» операцию решить, записав вместо неё последовательность действий по нахождению х (известную из школьного курса математики); т.е. в этом случае ищется (а чаще – подбирается готовый) математический метод решения. Другой случай – матмодель не требует решения, но записана через действия, не входящие в репертуар исполнителя информодели и/или входящие в неё объекты не входят в багаж исполнителя (т.е. не м.б. подведены ни под один тип объекта). Пример – вычисление суммы ряда величин под знаком "∑", когда исполнитель выполняет только сложение пары чисел. Здесь переход несколько проще; нужно представить операции матмодели через доступный репертуар, а её объекты – через имеющийся багаж (обычно – сконструировав производные типы из багажных). Наконец, возможно, что матмодель (её часть) представлена через операции, имеющиеся в репертуаре, но записанные иначе (отличающиеся синтаксисом). Тогда дело совсем просто – достаточно переписать операции в требуемом формате.

В связи с вышесказанным введём опеределение:

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

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

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

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

Кроме иерархической подстановки, возможны три важных частных случая организации дракон-модели:

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

При взаимной рекурсии (парной) в каждом визуале пары есть икона Вставка с именем другого визуала («Иван кивает на Петра, а Пётр – на Ивана»); таких икон м.б. и больше.

При параллельном вызове икона Вставка с именем одного визуала имеется в визуалах, одновременно выполняемых по иконе Параллельный процесс; если модель строится по объектно-ориентированному принципу, то это происходит с визуалом метода, сопоставленного ряду одновременно вызываемых экземпляров класса (разных классов).

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

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

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

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

Рассмотрим состав и условия применения неформальных преобразований.

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

Создатель техноязыка в /1, с.91/ указывает возможный критерий перехода – разветвлённая структура примитива с числом икон 15 и более.

Ветки эргономичного силуэта должны отражать метаструктуру описываемого процесса.

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

В завершение или время от времени проводится формальная эргономизация визуала путём ряда преобразований, сохраняющих эквивалентность итогового алгоритма исходному.

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

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

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

Во-вторых, в эргономичном визуале число вертикалей д. б. минимально возможным. При наличии одинаковых фрагментов в дракон-схеме часто возможно их объединение.

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

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

Возможны и обратные операции (вертикальное или горизонтальное разъединение).

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

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

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

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

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

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

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

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

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

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

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

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

В итоге получаем дракон-спецификацию, используемую далее.

Исходит из того, что как результат ТФЗ должна получиться командная модель решения задачи человеком (возможно – совместно оператором и программно-аппаратным косавтом на базе информашин).

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

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

Здесь же выбирается метод дальнейшей формализации: опытовый («проб и ошибок»), логический или прототипирования.

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

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

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

В любом случае из всех исполнителей сочинителями м.б. только некоторые.

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

Подробнее об этих результатах рассказано здесь.

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

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

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

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

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

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

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

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

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

Свёртку целесообразно проводить с сохранением раскрытого содержания; для этого можно поступить следующим образом: создаётся визуал, именуемый, скажем, <СвёрткаN>, где N – уникальный в рамках задачи индекс; в качестве тела визуала подставляется детальное содержание; на его место в тело укрупняемого визуала вводится икона Вставка с именем <СвёрткаN>. Другая возможность – использование виопов Область, описанных в п/п 4.1.12.2.

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

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

Детализация и подстановка взаимно сочетаемы при условии, что алгоритм-вставка сохраняет эквивалентность.

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

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

Процесс уточнения модели (раскрытия содержания) итеративен в силу следующего:

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

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

Гибридный визуал в окончательной редакции одновременно служит основным документом на процесс (по Паронджанову – т.н. исходным чертежом).

На основании исходного чертежа программы выполняются заключительные этапы ТФЗ: кодирование машинных алгоритмов, проверка и оптимизация, ввод в эксплуатацию. Их содержание зависит от третьей компоненты методологии – реализации техноязыка как части информатической системы. Согласно общей концепции ЖЦ сложных систем, все они относятся к фазе создания системы; далее следуют вторая и третья фазы пожицикла.

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

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

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

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

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

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

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

Каким же путём мы можем идти к формальной верификации? В настоящее время известны три направления:

Сущность двух первых изложена в различных работах³.

Актуальным является третье направление, более известное под английским наименованием model checking. Подробнее оно рассмотрено здесь.

Как соотносится с этими методами ДРАКОН-МФЗ? Прежде всего, очевидно её применение в процессе верификации для визуализации моделей и требований.

Кроме того, ДРАКОН и КогниСтиль позволят удобнее представить сами процессы верификации, включая те же алгоритмы model checking. Тем самым можно рассчитывать на сокращение сложности восприятия, понижение «барьера вхождения» в данную деятельность.

Наконец, внедрение формальной верификации влияет на саму ДРАКОН-МФЗ, конкретизируя работу в фазе создания/совершенствования; очевидно, что эскизно визуализировать нужно сразу с расчётом на верификацию дракон-эскизов.

Чтобы специфицировать поведение и требования для model checking, необходима достаточно высокая математическая культура. Очевидно, по мере распространения метода будет накапливаться опыт спецификации; часть его будет общедоступна (фактически начало этому накоплению положено в упомянутой работе Ю.Г. Карпова).

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

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

В некоторых ModelChecking-системах имеется также возможность тестирования моделей (интерактивного выполнения, примерно как дракон-программ в дракон-диспетчере).

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

Другие элементы полного жизненного цикла решения задачи

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

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

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

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

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

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

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

Сегодня мы имеем огромный и непрерывно пополняемый банк информатических импер-знаний в текстовом представлении, как для конкретных задач и исполнителей, так и для обобщённых задач и абстрактных исполнителей; главными авторами последних, конечно, следует считать Н. Вирта с его "Структурами данных и алгоритмами" и Д. Кнута с его "Искусством программирования".

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

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

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

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

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

2 Показательно, что в системотехнике при структурировании автоматизированных систем по видам обеспечения изначально под «математическим обеспечением» понималось либо изложение методов реализации назначения АС математическим языком, либо... запись алгоритмов решения на языках высокого уровня.