Отечественному специалисту в информатизации Ф.В. Ткачёву принадлежит высказывание:

«Алгоритмика — это программирование, очищенное от мешающих случайностей» (см. Тезисы доклада).

Следуя Фридланду, мы говорим об информатическом моделировании, случаем которого выступает программирование как «планирование поведения исполнителя-машины», говоря словами Кауфмана (см. /15, с. 22/).

Существенную роль в таком очищении могут играть нотации для программ (инфор-моделей), адекватные сферам употребления. Для этого и сами нотации не должны нести избыточной сложности, а форма записи — отвечать условиям применения. Важным условием можно считать тип составляющей знания, отчуждаемого в инфор-модели («абстракции» по Кауфману, см. /15, Гл.3/).

Материал раздела служит основой для освоения основного материала, содержащегося в этом разделе Приложения 3.

Алгоритм мы будем понимать как информатическую модель деятельности для абстрактного императивного исполнителя. Слово «абстрактный» здесь значит «любой». «Императивный» имеет смысл «требующий описать для него, КАК делать» - в отличие от декларативного, которому достаточно описать, ЧТО делать. Можно считать, что это же различие Фридланд в /1, Гл. 5/ определяет между «информатическим» и «интеллектуальным». Разницу также определил в своё время Кауфман:

«Людей как исполнителей характеризует прежде всего наличие у них модели реального мира, в достаточной мере согласованной с моделью мира у создателя плана <т.е. описания поведения исполнителя>. Поэтому в плане для людей можно указывать цели, а не элементарные действия.» (/15, с. 31/).

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

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

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

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

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

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

Другой типичный случай – автоматизация путем разработки программы для СУБД (или включения новых функций в уже существующую) – отличается главным образом тем, что в качестве формального декларативного языка вместо выбранного стандарта используется стандарт графического моделирования данных вида «сущность-связь», например по методологии IDEF1X. При этом текстовый процессор обычно заменяется на редактор моделей данных, а в качестве языка Х выступает язык описания запросов к БД (например, SQL).

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

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

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

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

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

Методика алгоритмизации процессов переработки данных

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

Методика основана на положениях технологии формализации знаний с помощью техноязыка ДРАКОН, а также на методической разработке процесса алгоритмизации В. Ляховичем (см. статью /16/).

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

Тем не менее методика Ляховича требует корректировки по следующим причинам:

Результат корректировки оформлен как частный методический комплекс (см. в Приложении 8). При этом сами методики включены как основной материал, а примеры Ляховича (с авторскими комментариями) — как опорный материал.

В результате анализа этих методик также выявилось следующее.

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

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

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

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

В первом приближении можно считать, что результаты Потопахина наполняют конкретным содержанием шаги 2..4 методик Ляховича. На деле имеет место взаимозависимость — также и методики Ляховича на шагах 5..6 м.б. использованы для уточнения результатов Потопахина до методики доказательного синтеза программных процедур — правда, в частных случаях. В общем остаются справедливы исходные полоожения Потопахина и предлагаемые им эвристики решения сложных задач.

Кроме того, п. 1 методик Ляховича, особенно для сложных задач, подчиняется общим принципам информатизации в условиях ограниченной алгоритмической разрешимости. Характеристику их дал, в частности, Фридланд:

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

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

Также методика Ляховича д.б. включена в более общую методику информатизации как часть (необходимая) по следующим причинам:

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

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

В целом рассмотренный комплекс охватывает этапы 1 и 3 ТФЗ-ДРАКОН.

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

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

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

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

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

При отсутствии автоматического конвертора исходных чертежей с языка ДРАКОН-Х код (исходный текст) на языке Х можно получить только вручную.

1 Переменные части текста даются как поля в '< >', заменяемые на описание; общая часть (корень) поля пишется как есть, а изменяемые части как '*'. Файлы МО с однокоренным именем относятся к одному элементу структуры.

2 Федеральный закон № 230-ФЗ от 18 декабря 2006 г.

3 Если цитата состоит полностью из сведений, цитирующих иной источник – сохраняя ссылку на первоисточник.

4 По терминологии автора техноязыка.