OberonCore

Кое-что в связи с составлением графит-модели техпроцесса из этого сообщения. По времени в основном сделана в 4 подхода длительностью до половины рабочего дня. Не менее четверти времени затрачивалось на компоновку. По субъективной оценке, работа эта трудная. И это при том, что велась по офисной технологии. Что подтверждает замечание С. Прохоренко отсюда: "схемы требуют недюжинных способностей по компоновке".
Но. Во-первых, процесс сочинения/оформления двуединый. Недаром Дмитрий_ВБ в своё время назвал его "разработка И документирование". И компоновочные работы помогают содержательному редактированию.
Во-вторых, в данном случае это было не самым трудным. Труднее проводить информатизацию задачи. И здесь явное отделение структуры от содержания элементов (которое обеспечивает формально-схемная запись), по опять же субъективной оценке, важно. Другое дело - что такого отделения можно достичь не обязательно на базе графов. Структурный текст (только с заменой маршрутных слов на нетекстовые элементы) тоже м.б. полезен.
Ну и третье - модель не сводится к одному роду описаний. И когда нужно представить разнородные компоненты симультанно - всё равно нужно их скомпоновать на диосцене. Уже говорил об этом здесь: viewtopic.php?p=73050#p73050.
Явное выделение уровней формальности также помогает делу. Ибо всё сразу информатизовать не получится (а для исполнителя-человека и не обязательно). Указанная модель включает все три уровня - что отражено в употреблении величин и формулировке действий. А такие вещи, как "конкретное определение типа" (здесь - иллюстративная часть типа Мягкий переплёт) - это в любом случае изображения. Кстати, тут понадобилось некоторое 3D-моделирование . Информатически строгие величины даны в зелёной гамме; они неизменяемы (т.к. машинный исполнитель ЕЯ-правил не придерживается); определения их абстрактно-типизированы. Математически определённые (хотя бы и предварительно) сущности даны в синей гамме (имея в виду, что оопределение отсылает к какому-то месту описания, т.е. может пониматься как гиперссылка); сами определения "конкретно-типизированы" путём указания соотношений и/или элементов форм. Качественно определённые сущности не выделены цветом (только форматом шрифта, принятым для имён величин); определений в модели могут не иметь (неявно обращаясь к предметному опыту и здравому смыслу читателя). Также и формулировки операций различны - структурированные русские предложения, математические формулы, программные операторы/выражения.

Заметим и основную особенность моделей материальных техпроцесов в сравнении с датаматическими (как говорил создатель техноязыка, "техпроцессов" с "алгоритмами"). В первых, кроме действий над данными пявляются и действия над материальными объектами ("веполями", как говорят в ТРИЗ). А среди действий над данными обязательно есть предназначенные для управления процессами - определения условий обстановки (данных обратной связи), принятия решений и исполнения (выдачи данных прямой связи).

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

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

А. С очевиднымми (хотя и не обязательно сразу) ответами:
А1. По структуре деятельности (удобство получения ответов на которые подчёркивается создателем техноязыка):

* как называется задача?
* из скольких частей она состоит?
* как называется каждая часть?
* ну и также - каковы взаимосвязи между частями?

При ответе следует определиться, откуда получать данные.
А2. Как определяются условия протекания процессов?
А3. Зачем вершины некоторых действий на импер-схемах расположены встык?
А4. Имеются ли в модели датаматические действия (по переработке данных)?

Б. С неочевидными, но имеющими единственно верный вариант ответами:
Б1. В актив- схеме для человека-переплётчика определены ряд величин задачи. А как он определяет значения этих величин?
Б2. Все ли параметры циклов в импер-схемах достаточно информатизованы?
Б3. В процедурах прошивки вначале задаются рабочие количества отверстий. А можно ли перенести соответствующие присваивания в вызывающую их процедуру Укрепить книгу и что это даст? А если передавать при вызове как параметры?
Б4. Можно ли информатизовать тип Мягкий переплёт?
Б5. Есть ли ошибки в модели?

В. С возможностью различных ответов (где нет "двух мнений - моего и неправильного" ). Каждый вариант м.б. в чём-то лучше:
В1. Можно ли записать схемы модели без графики вершин и линий? Какие средства для этого удобнее? Что это может дать?
В2. Процедуры прошивки весьма схожи по структуре и содержанию операторов. Можно ли заменить их единой процедурой, охватывающей оба случая?
В3. При алгоритмизации процессов прошивки проверка выполнения вспомогательной техоперации в одном случае включена в процедуру, в другом - вынесена в вызывающий процесс. В чём разница и какой вариант лучше?
В4. В импер-схеме головного процесса главный маршрут проходит по шапке. Можно ли направить его вертикально и что это даст?
В4. В импер-схеме головного процесса главный маршрут проходит по шапке. Можно ли направить его вертикально и что это даст?

А1. Кто по привычке к техноязыку стал извлекать данные сначала из импер-схем - пошёл эргономически неоптимальным путём . Общий состав процесса отражён на АТ-схеме, как и подчинённость его процедур. Но подчинённость эта по объявлениям.
Связи процедур при исполнении (по вызовам) нужно показывать на схеме подключения процедур - ДМ-типа. Для удобства прослеживания взаимосвязей можно использовать "придание глубины" по Дмитрию_ВБ (т.е. наложение схемы зависимостей, выделенных цветами - как на рисунках в этом посте).
Уже затем переходим к импер-схемам. И тут используется структурирование процесса как дейкстрала (головного). Дейкстрал-"шапка" показывает читателю не только логические части процесса - но и логические условия выбора каждой из частей.
А2. Из операторов утверждений - предусловий, постусловий, текущих условий.
А3. Так выделены атомарные последовательности действий (при испоолнении совершаемых непрерывно). Для эскиза это возможная замена операторам атомизации (определённым здесь) - не вводятся дополнительные типы и экземпляры вершин, что удобнее для читателя-"предметника".
А4. Да. Прежде всего это проверки всех условий. А также изменения параметров циклов.

Б1. Ответ содержится в определении смысла по Фридланду (см. статью здесь). Он определяет полуформальный смысл как существующий в сознании образ результата решения, с которым и сравнивается текущее состояние предметной области. Определённые в модели множества флагов выполнения и требования техопераций получают свои значения как результат таких сравнений (мысленных). C этим связано и дублирование флагов в актив-модели - вне человека они отражают состояние предметки, у человека - результат оценки этого состояния.
Б2. Нет, не все. Значения некоторых параметров можно понимать как перечисления, но такой тип в гарантоспособных инфор-языках типа Оберона не определён. Более того, по контексту употребления можно видеть, что эти параметры трактуются как логические. Для корректной информатизации следует понимать перечисляемые значения как предметно-обусловленные ("знаковые", как говорит создатель техноязыка) псевдонимы значений числового индекса (Вирт говорит "именованные значения"). А их логический смысл отражать как сравнения числового параметра с заданными уставками. Вообще здесь проявляется тот факт, что циклы с параметром многое скрывают в логике процесса - особенно когда параметр имеет также нечисловые смыслы, как в данных случаях. И следует изначально писать цикл по схеме поиска/прохода - как сделано в задаче оформления дракон-схем (допустим, при обходе КС-ячеек здесь).
Б3. В вызывающий процесс перенести можно. Это должно сделать логику исполнения более прослеживаемой. Поскольку эта величина используется и там - для определения длины нити, вдеваемой в иглу на вспомогательной техоперации ВспОп3. В силу того же эту величину некорректно будет передавать как параметр, не сохраняя в вызывающей процедуре - тогда она будет локальной, и для вычисления длины нити её значение будет недоступно.
Б4. Если имеем в виду формального исполнителя - нужно. Подход к этому уже намечен в иллюстративной части определения типа. Там введена система координат для книги. Для полной математизации следует описать все существенные для задачи подобъекты как геометрические сущности (точки, линии, поверхности, объёмы). Тогда для информатизации можно определить их как подтипы и использовать определяющие величины в процессах.
Б5. Да, есть. И много - так что если кто действительно вчитывался, но не обнаружил - может смело поставить себе "неуд". Итак, перечислим:

* В ОснОп1 процесса Укрепить книгу в первом цикле с параметром неверно расположены первые два действия. Нужно поместить их на главный маршрут.
* Параметр этого же цикла неверно наращивается - следует добавлять ещё единицу, чтобы действительно выйти за пределы обработанного выпадения - листа/пачки.
* Также неверно показано расширение типа Мягкий переплёт - указание д.б. в расширяемой записи.
* Включение величины Название в определение типа Мягкий переплёт логически некорректно - в самом деле, какое значение для переплёта имеет название конкретной оформленной по такому типу книги?
* Некорректно определено число итераций цикла в процедуре Прошить постоянно. Правильное выражение: ОтвДляПрш=2*(Кол-воОтв-1). Первый сомножитель учитывает, что прошивка обходит обе стороны КБ, второй - что шаг цикла соединяет пару соседних отверстий (т.е., связь здесь такая же, что и между числом точек и числом интервалов между этими точками). Кстати, эту величину можно прямо подставить и при вычислении длины нити, вдеваемой в иглу (первый сомножитель при этом не нужен).
* Критерий выбора текущей позиции в том же цикле некорректен во второй своей части - условие направления прохождения будет выполняться только при чётном числе прошиваемых отверстий. Условие, не зависящее от чётности отверстий, будет иметь вид:"... не исходное И не соединённое данной нитью с соседним отверстием по этой же стороне КБ". Первое условие нужно, чтобы не "зациклиться" уже на втором шаге на исходном отверстии, повторяя витки между ним и соседним. Оно же м.б. использовано для "непараметрического" выхода из цикла - т.к. его невыполнение свидетельствует, что прошивка вернулась к исходному отверстию.

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

Также можно говорить о некоторых недочётах в описании:

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

Также модель можно было бы развить в некоторых аспектах:

* Можно описать случай неоднократной прошивки КБ. На практике - двукратная с выбором исходных отверстий с противоположных краёв КБ (на одной - оборотной - стороне). Тогда обычно нить протягивается каждый раз одинарная (в иглу вдевается только на длину одного хвоста). Независимые прошивки могут и приходить в негодность независимо - обрыв нити в одной не обязательно влечёт за собой обрыв и в другой - это повышает надёжность укрепления.
* В модели можно описать также случай неремонтопригодного укрепления переплёта. Оно отличается тем, что форзац-скрепа накладывается только на КБ и склеивается (после прошивки) также и с обложкой.

В1. В принципе можно. Однако чистый текст не будет столь наглядным. Эргономичнее будет использовать структурные скобки. Но структуру маршрутов с выделением ветвей (как в дейкстрале) показывать одномерными скобками также недостаточно наглядно.
В2. Вообще-то можно, но маршрутная логика м.б. чересчур сложна для восприятия, если иметь в виду "предметника".
В3. Логически разницы нет - структура деятельности будет эквивалентной (можно проверить, составив "варианты использования"). А вот для формального исполнителя разница будет - в виде накладных расходов на вызов процедуры только для того, чтобы затем из неё выйти ... То же проявляется и эргономически - ситуацию, исключающую исполнение процедуры целиком, удобнее описать вне этой процедуры. Иначе читателю приходится переключаться на другую схему - лишь затем, чтобы от неё вернуться к исходной.
В4. Можно - рокировав развилки "шапки". Тогда дейкстрал будет иметь т.н. "примитивидную" организацию. Нетрудно видеть, что её пропорции будут неоптимальны - схема окажется вытянута по вертикали. Отчасти может изменить пропорции структурное представление циклов с параметром, как сказано в ответе Б2. Важнее другое - принятая организация следует интерпретации координат на плоскости, предложенной Ермаковым и Жигуненко - когда состояния процесса располагаются по своей оси ортогонально цепочкам действий.

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

Вот что ещё можно сказать по этой теме.

1. На примере прояснения смысла циклов с параметром (прежде всего цикла прошивки) можно видеть подтверждение тезиса Дрейпера (обсуждавшегося у Мичи и Джонстона, с. 98-99): "Поручите физическому миру проделать за вас все расчёты". В данном случае, чем считать число итераций, чтобы подставить его как значение параметра, можно было вникнуть в физику процесса. И тогда определить состояние предметки, при котором цикл завершается. Что и намечено в части ответа Б5, касающейся условия выбора текущей позиции. В общем, базовые паттерны циклов рулят и в таком понимании - если сочинитель стремится формализовать циклический процесс как поиск/проход - он начинает представлять себе физику предметки математически формально...
Помимо прочего, такое представление оказывается инвариантным к фактору числа элементов структуры предметки (при сохранении вида структуры). Так, в данном случае "физическое" условие выхода из цикла не зависит от количества прошиваемых отверстий. Сколько бы их не было - менять в алгоритме ничего не надо - выходим, когда оказываемся рядом с исходным. Тогда как в "длятском" цикле каждый раз надо править верхнюю границу... В данном случае она связана с числом засверливаемых отверстий - но в каких-то задачах может оказаться, что "настраивать" итератор придётся независимо. А таких операций всегда лучше избегать...

2. Повышение степени формализованности описания возможно различными путями. Наряду с раздельным, который обычно подразумевался в этой теме, можно и "вытеснять" менее формализованное содержание тех или иных элементов более формализованным. Такой путь лучше реализуется в машинном редакторе. А прояснение частей описания связано, в частности, со сказанным выше.

Сказанное выше в ответе В4 имеет под собоой некоторые представления о структурировании деятельности как предмета инженерии. А именно - упорядочивая в схемном представлении состояния алгопроцесса, мы должны, думаю, учитывать, что множество этих состояний само может иметь какую-то структуру. И её надо тогда отражать...