Прежде всего должен отличаться прагматически - иную цель реализует (как-то спасти исполнение образом, пред-усмотренным построителем системы, который следует сказанному Лаптевым
). Отсюда - и семантически (иной смысл - как "альтернативного конца" по обнаружению одной из пред-усмотренных ситуаций, исключающих "обычный конец", т.е. нормальное достижение цели системы в данном процессе). И далее - конечно, синтаксически (как допвыход из процесса, где локализована пред-усмотренная реакция на исключение, в процесс, где решается, как действовать дальше с учётом последствий). Как-то так...
При этом всего в модели деятельности пред-усмотреть, конечно, нельзя... отсюда жёсткое требование - если модель для человека, то решающий процесс должен обязательно направлять исполнителя на "действовать по обстановке, если ситуация до/после реакции на исключение не подходит ни подо что из пред-усмотренных"... А если для машины - то в архитектуре системы д.б. человек, чтобы действовать по обстановке...
Далее. В структурном редакторе прежде всего д.б. структурировано мнжество элементов деятельности...
Действия типизируются укрупнённо на преобразования и перемещения. Далее
преобразования - на:
* целевые (включая вызовы процедур и прерывания/исключения);
* проверочные (включая анализ состояний для подготовки ветвлений в соответствии со сказанным в начале этого пункта). Т.е. "для ответа на вопрос "Заболел?"" в терминах Дагаева: viewtopic.php?p=76979#p76979.
Дмитрий Викторович ведь удачно напомнил о сказанном насчёт "режимов исполнения маршрутной схемы как сценария" ещё здесь:
viewtopic.php?p=49567#p49567. И ежели мы не хотим, чтобы человек каждый раз вводил ответ на воопрос развилки (сиречь управлял флагами для условного джампа) - значит, надо пред-усмотреть получение этого ответа перед вопросом путём вычислений отношений от величин состояния процесса/исполнителя...
Перемещения же - на типы:
* "внутри исполнительских ядер" (в терминах Бабаяна, в общем "информационном пространстве" существования системы процессов - реализуемом как система основных ЗУ) - т.е. отправки/приёма сообщений по каналам;
* "ядро-хранилище исполнителя" - т.е. сохранения/извлечения данных, с временным изъятием из инфопространства во внешние ЗУ;
* "исполнитель-окружение" - т.е. ввода/вывода (обычно без изъятия из инфопространства, когда просто дублируем область ЗУ через порт, но, видимо, м.б. и с удалением).
Элементарные внутренние перемещения - это пересылки по адресам. В небезопасных архитектурах исполнителей - тупые интеловские и прочие мувы. Отсюда широкие возможности для "боёв в памяти":
viewtopic.php?p=66718#p66718. В безопасных - например, по принципу "Эльбруса", представленному в "
Люди и дела . Бабаян".
Само собой, за каждым типом может стоять в виде результата построения как команда (фрагмент кода), так и библиотечная функция (процедура). Пример - пересылки сообщения м.б. как у Вирта:
viewtopic.php?p=57526#p57526, а м.б. на асме...
Ну,
условия можно типизировать на целевые опять же и на, как Дагаев предлагает
здесь, функциональные (говоря "системотехнически") - т.е. осуществимости очередного шага процесса. При этом по нормальной модели процесса (системы процессов) вторые, очевидно, должны генериться автоматически - из структуры связей шагов.
И вот такой структуризации примерно учить...