Приложение 3.
Каталог
примеров по формализации знаний
В приложении описана (авто)формализация профессиональных знаний до уровня постановок задач, включающих определение объектов и алгоритмов решения. Включены элементы алгоритмизации и программирования для информашин. Вместе с Приложением 4 оно относится к когнитивному обеспечению информатизации и выделено для удобства использования.
Далее будут показаны конкретные случаи визуализации знаний, представляющие как теоретический, так и практический интерес.
К сему прилагается | Каталог примеров | Комплексная визуализация
Общее РДП Автоматика Датаматика
Здесь приводятся примеры визуализации задач с применением комплекса языков из числа рассмотренных в данном документе.
Содержание
Задачи переработки данных (виртуальных объектов)
Процесс шифрсвязи на базе алгоритма PGP
Задачи переработки данных (виртуальных объектов)
Процесс шифрсвязи на базе алгоритма PGP
Описание данного процесса использовано для иллюстрации некоторых вопросов визуализации; заодно на нём удобно показать и ограничения использования шифрсредств. Ограничимся базовым процессом шифрсвязи в следующем популярном описании:
"В связи с тем, что алгоритм шифрования с открытым ключом значительно медленнее, чем стандартное шифрование с одним ключом, шифрование сообщения лучше выполнять с использованием высококачественного быстрого стандартного алгоритма шифрования с одним ключом. Первоначальное незашифрованное сообщение называется "открытым текстом" (или просто текст). В процессе, невидимом для пользователя, временный произвольный ключ, созданный только для этого одного "сеанса", используется для традиционного шифрования файла открытого текста. Тогда открытый ключ получателя используется только для шифровки этого временного произвольного стандартного ключа. Этот зашифрованный ключ "сеанса" посылается наряду с зашифрованным текстом (называемым "ciphertext" – "зашифрованный" ) получателю. Получатель использует свой собственный секретный ключ, чтобы восстановить этот временный ключ сеанса, и затем применяет его для выполнения быстрого стандартного алгоритма декодирования с одним ключом, чтобы декодировать все зашифрованное сообщение." (Левин М. PGP: кодирование и шифрование информации с открытым ключом. – М.: Майор, 2001. – С. 9...10).
Из этого качественно формализованного описания можно извлечь математизированное при некоторых очевидных допущениях.
Прежде всего нужно рассматривать шифрсвязь как совокупность функций, представляющих обеспечивающие процессы. Также полагаем, что в исходном состоянии ключи асимметричного шифрования (АШ) у сторон уже есть; считаем, что они введены в систему шифрсвязи (служащую исполнителем описания). Наконец, исходные данные вводятся в систему для начала шифрсвязи человеком и выдаются также человеку; люди считаются внешними сущностями задачи (абонентами системы). Тогда представляется очевидным, что имеем систему взаимодействующих процессов в составе:
ввод (In) открытого текста (ОТ) отправителем;
генерация сеансового ключа (СнК) для алгоритма симметричного шифрования (АСШ, SCA);
шифрование ОТ на сеансовом ключе по АСШ;
шифрование СнК на открытом ключе получателя (ОКПл) по алгоритму асимметричного шифрования (ААШ, ACA);
композиция (Concat, от англ. «составление») шифртекста (ШТ), полученного на СК, совместно с ШСнК на передающей стороне в единый массив-шифровку (ШС);
передача (Issue) ШС по уязвимому каналу связи (УКС) от отправителя к получателю;
декомпозиция (DeConc) ШТ и ШСнК на приёмной из массива ШС;
расшифрование ШСнК на секретном ключе получателя (СКПл) по алгоритму асимметричного дешифрования (ААДШ, ADA), восстанавливающее СнК;
расшифрование ШТ на восстановленном СнК по АСШ;
вывод (Out) ОТ получателю.
Некоторые сущности мы именуем также по-английски; это удобно для дальнейшей формализации.
Заметим, что применение алгоритма симметричного шифрования к тому же шифртексту с тем же ключом даёт исходный откртекст – потому оно так и называется. Алгоритм СШ один для шифрования и расшифрования – как и ключ.
Принято, что ключи АСШ хранятся в системе и извлекаются по некоторому правилу для каждого сеанса автоматически на каждой стороне; иначе в состав процессов надо было бы ввести получение открытого и секретного ключей (напр., от абонентов).
Также предположим, что отправитель не обязан передавать шифровку мгновенно после формирования её составных частей; возможна задержка на заданное время (как вариант можно также ввести условие раннего отправления, учитываемое до истечения задержки). В то же время получатель расшифровывает ШС сразу по поступлении.
Тогда процесс можно описать такой системой функций (вертикальная черта означает композицию – как при составлении "конвейера команд" в некоторых ЯУЗ, напр., ОС UNIX; в квадратные скобки берутся моменты времени, которым отвечает готовность аргумента/результата функции):
ОТ[tвв]=In(OT[tнач]) & СнК[tген]=GenKeySns([tзап]) | ШТ[tзшт]=SCA(ОТ[tвв],СК[tген]) & ШСК[tзшк]=ACA(СК[tген],ОКп[tизвотп]) | ШС[tгот]=Concat(ШТ[tзшт],ШСК[tзшк]) | ШС[tотпр]=Delay(ШС[tгот]) | (ШС[tпрм])=Issue(ШС[tотпр]) | (ШТ[tдек],ШСК[tдек])=DeConc(ШС[tпрм]) | СК[tршк]=ADA(ШСК[tпрм],СКПл[tизвпол]) | ОТ[tршт]=SCA(ШТ[tпрм],СК[tршк]) | ОТ[tвв]=Out(OT[tршт]),
причём выполняются следующие неравенства временных параметров:
tотпр-tзшт & tотпр-tзшк >= 0;
Кроме того, предполагается, что каждый элемент композиции (функция, группа функций) вычисляется после завершения вычисления функции (каждой функции группы), предшествующей в композиции (т.е. в терминах теории взаимодействующих процессов элементы связаны отношением «окончание-начало»).
Здесь мы для удобства различения импер- и деклар-частей в "сплошном тексте" взяли для действий англоязычные обозначения, а для объектов оставили русскоязычные.
Очевидны условия выполнения функции: функция начинает вычисляться по готовности всех аргументов; время вычисления функции конечно и больше нуля. Т.е. момент готовности результата функции на оси времени располагается правее момента готовности аргумент<а|ов>, поступивш<его|их> последним[и] (из одной и более одновременно отработавших функций-источников).
Эта система процессов м.б. визуализирована как дракон-модель на расширенном техноязыке Д2М (допустим, на ДО7Pr-диалекте). Для этого нам понадобятся допущения информатизации построенной системы. В основу положим то соображение (относящееся к актив-знанию), что процессы исполняются разными косавтами, которые условно назовём абонентскими пунктами отправителя и получателя (АПОт и АППл) и сетью связи (СтС). Криптоалгоритмы выполняются (санкционированно, т.е. в целях шифрсвязи, а не противодействия ей) только на АП. Косавты связаны в цепочку (через соединения, установленные СтС – выделенные и/или коммутируемые участки маршрута между абонентскими окончаниями УКС); актив-схему приводить не будем.
Модель будет укрупнённой, поэтому внутренняя логика функций нас не интересует. Ввод ОТ сделаем частью одного из процессов на АПОт, а вывод ОТ – одного из процессов на АППл (руководствуясь принципом "разумной достаточности" для состава процессов). Также доопределим, что абонент-отправитель вводит значение момента отправки, которую система осуществляет автоматически.
Результат передаётся процессу-потребителю (множеству потребителей) сообщениями, причём синхронизация достигается тем, что потребитель ждёт сообщения от получателя (которое посылается немедленно по готовности сообщаемых данных). Поэтому используем рандеву-механизм и соответствующие операторы. Каждый процесс проходит до получения результата; формально это обеспечивается помещением оператора Вызов на рандеву в конце визуала. Вызов на рандеву по готовности результата (единственного или выбранного из ряда потребных сочинителем) означает и пуск вызываемого процесса; формально это можно отразить:
поместив оператор Приход на рандеву по этому результату в начале визуала процесса-потребителя;
используя понятие неявной отправки сообщения инициирующим действием, как уже делали это в п. Разработка решения этого примера; здесь действие выдачи данных в сообщении будет обозначать и пуск процесса-адресата.
Выбираем второй вариант. т.к. он понижает громоздкость импер-информодели.
Также зададим идентификаторы каналов, имея в виду актив-знание о системе-исполнителе (при подлинно комплексной визуализации они даются на актив-схеме).
Исключительные ситуации (напр., по тайм-ауту ожидания сообщений, нецелевому завершению процесса или отдельного действия) не рассматриваем.
Дракон-модель показана на рисунке:
Шифрсвязь как система взаимодействующих процессов на ДО7Pr
Видно, что имеется одна секция потенциально параллельного исполнения – шифрование ОТ и СнК можно совместить (конечно, это м.б. и квазипараллелизм – для однопроцессорного многозадачного исполнителя; возможны и особенности исполнения, такие как суперскалярность – но они относятся к «схемокоду» и здесь, на программном уровне, нас не интересуют); это мы визуализировали как вариант 1-А.
Напомним, что в примерах моделируется РДП-документ, и мы по мере необходимости пользуемся возможностями гипотетического РДП-редактора; здесь мы не используем лист-силуэтизацию документа, чтобы сократить объём работ по макетированию.
Подразумевается, что варианты нумеруются автоматически, скажем, по порядку создания в РДП-документе, а сочинитель может перенумеровать их вручную – чтобы отразить, допустим, очерёдность внимания.
Остальные функции вместе с этой секцией дают естественно-последовательное исполнение; поэтому мы организовали их в цепочку, либо связав через сообщения в случае реализации в разных Д2М-алгопроцессах, либо просто расположив реализующие их виопы по шампуру одного алгопроцесса. Тогда возникают варианты распределения отдельных функций по алгопроцессам.
Так, можно было бы ввести функцию ШСК в основной алгопроцесс, "одним махом" избавившись от визуала Зашифровать СК и взаимодействия с ним; но это сделало бы операции шифрования строго последовательными, что противоречит логике спецификации (заданной в системе функций) – порядок исполнения должен определяться только возможностями исполнителя по обеспечению совместного протекания процессов.
Это мы зафиксировали в комментарии к варианту 1-А.
Окна комментариев показаны открытыми на свободных местах диосцены; реально они открываются "всегда впереди" и могут изначально перекрывать какое-то содержание; это устраняется буксировкой. Здесь открыты все окна, предполагаемые заполненными, что загромождает (мягко говоря :)) диосцену; на самом деле, конечно, они открываются выборочно.
Поэтому мы визуализировали этот случай как вариант 1-Б, сделав его неосновным. Однако строго последовательное исполнение можно задать, если заранее известно, что исполнитель не поддерживает [квази]параллелизм.
Здесь мы возложили на алгопроцесс формирования шифровки инициирование других необходимых для этого алгопроцессов, т.е. сделали его ведущим на АПОт; также включили в него функцию композиции шифровки из шифртекста и шифрключа (аналогично декомпозицию включим в процесс расшифрования, исполняемый на АППл).
Реализацию же функции задержки мы вообще передали среде исполнения РВ (как таймерный процесс), также как и рандеву-операторов (как управление алгопроцессами через сообщения).
Возможны и варианты, куда поставить Пуск таймера Отправить. В принципе это можно сделать между любыми двумя операторами на участке от ввода ВрОтпр до выдачи ШТ на отправку. Однако речь идёт об ограничении времени на выполнение этого участка; поэтому мы последовали "армейской логике" – как только все параметры дальнейшего исполнения определены – время пошло (абонентский пункт как бы "говорит про себя" оператору: "– Приказ понял, ноль-ноль." :)). При этом на любом операторе участка может возникнуть исключение по истечению времени, и вот тогда АПОт уже "скажет вслух" абоненту: "– Не успеваю выполнить!" – т.е. выдаст сообщение о тайм-ауте по данной переменной-таймеру; но мы договорились не рассматривать это. Визуализирован же один вариант 2-А.
Чтобы не загромождать схему, мы не стали "городить" все варианты, вытекающие из этих соображений, а описали это опять-таки в тексте комментария.
Возникает и вопрос с описанием передачи шифровки как алгопроцесса, взаимодействующего с алгопроцессом-получателем шифровки. Используем понятие неявной отправки сообщения, как уже делали это выше; инициирующее действие обозначим как присваивание согласно принципу формализации, введённому в п. 4.1.2.
Ключи АСШ, если они не вводятся в сеансе шифрсвязи, должны уже находиться в каком-то хранилище. В программе PGP это специальные закрытые файлы, называемые кольцами (точнее переводить «связками») ключей – один для открытых (будем именовать его PubKeyRing), другой для «секретных» (назовём PrivKeyRing). Поэтому вводим операторы извлечения ключа на каждом АП; понятно, что сохранение ключа – часть процесса распределения, независимого от собственно шифрсвязи.
Здесь название ключей взято в кавычки потому, что, хотя оно принято в популярной русскоязычной литературе по PGP и асимметричному шифрованию вообще, но в России термин «секретный» законодательно придан вполне определённым категориям охраняемых сведений, с охраной которых применение данной программы не обязательно связано.
В операторах извлечения путь к хранилищу-«связке» задан как функция от параметров размещения; подразумевается, что значение этой функции определяется по актив-модели задачи (где заданы элементы пути – адреса косавтов и хранилищ в их составе). Это данные конфигурации косавта. То же справедливо для путей ввода/вывода.
Здесь мы также выбрали способ программной реализации функции Concat – композиция составляется путём заполнения массива – что определяет и реализацию обратной функции DeConc (подразумевается, что нулевой элемент содержит заголовок шифровки, формируемый на АПОт используемый при обработке массива на АППл).
Подразумевается, что типы данных для ШС, ШТ и ШСнК определены адекватно в деклар-модели.
Возможен вопрос: а где же здесь головной процесс, который должен бы называться имеем задачи? В том-то и дело, что в системе процессов структура задачи необязательно определяется импер-моделью; для этого служит модель процессного конструктива, где и «собирается» состав сущностей решения. Для данной задачи ПК-модель приведена ниже:
ПК-схема задачи шифрсвязи
На схеме ветки-модули выделены по косавтам-исполнителям; тем самым модель увязана с актив-знанием о решении задачи. Для упрощения не определены типы величин; также не заданы взаимосвязи модулей в рамках проекта (конечно, реально они автономны, но могут импортировать другие модули, напр., библиотечные).
Модель адекватно отражает логику процессов, но несколько громоздка. Возникает вопрос о других средствах визуализации импер-информодели.
Обычно PGP характеризуют как программу шифрования с открытым ключом (асимметричного), не вдаваясь в детали её работы. Однако из рассмотренного видно, что шифртекст закрыт симметричным алгоритмом; поэтому подобное утверждение неправомерно.
Вообще из изложенного можно заключить, что некорректно говорить об "алгоритме шифрования PGP"; можно говорить о надалгоритме или иначе – о схеме применения криптоалгоритмов двух базовых классов, по которой СШ-алгоритм применяется к содержанию сообщения, а пара АСШ-алгоритмов – к СШ-ключу. Конкретные криптоалгоритмы же в этой схеме м.б. любыми.
Если задать актив-схему, то яснее становится следующее. В процессе Передать по УКС единственное действие, строго говоря, не несёт точного смысла процесса. По сути, всё назначение процесса состоит в передаче сообщения ШС от входного окончания УКС к выходному. Оно вполне отражается рандеву-операторами (если считать СтС механизмом передачи сообщений). В то же время не отражён выбор маршрута между окончаниями – т.е. собственно работа ЦУ-СтС (обозначенного как исполнитель соответствующего модуля) по данной задаче. Можно определить поэтому извлечение указания нужного выходного окончания (напр. из нулевого элемента ШС-массива, раз уж мы договорились, что он содержит заголовок) и установление соединения этого окончания со входным (откуда в СтС поступило ШС). Считаем, что только после этого рандеву-оператор передачи ШС на выход выполним.
В начало страницы | Оглавление | Версия для печати
Copyright © Жаринов В.Н.
