Д Р А К О Н О Г Р А Ф И К А

Перспективы | Техноязык и информоделирование | Структуры алгопроцессов

Содержание

Диоформы в структурировании визуальных алгоритмов

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

«Шапка» силуэта – структура переходов

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

Из схемы вполне очевидно, как получается «зацикленный» силуэт — выходной БП с возвратом заменяется на ещё один обычный БП по адресу Цикл. При этом конечная ветка превращается в полную (что мы отразили выбором графит-индекса Z или N).

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

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

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

Визуал формы силуэта – шинная структура для произвольного вида

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

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

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

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

Метке БП на входе (относится к вызванному процессу) соответствуют действия по смене контекста алгопроцесса с вызывающего на текущий, называемые прологом; команде БП на выходе (относится также к вызванному процессу) соответствуют действия по подготовке смены контекста алгопроцесса с текущего на вызывающий, называемые эпилогом.

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

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

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

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

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

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

Каковы иные возможные логические основания применения силуэта?

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

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

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

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

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

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

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

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

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

В начало страницы | Оглавление | Главная | Версия для печати