Как я понимаю, тут два вопроса:
1) Как можно улучшить собственное умение алгоритмизовать?
2) Как лучше представлять результаты алгоритмизации?
С позиций когнитивной эргономики оба вопроса предполагаются связанными - через типы мышления сочинителя (и читателя). Возможно, интерес Даниила обусловлен тем, что он по ходу освоения техноязыка обнаружил, что ему удобнее читать и обрабатывать образно. При этом не факт, что каждому читателю его результатов будет тоже удобна такая форма.
Ну, чтобы долго не рассуждать, скажу практические вещи.
Проблема распадается на ряд взаимосвязанных:
* Чтобы удобно взаимодействовать с программистом-текстовиком, при этих поосылках вроде как нужен гибрид с 1С-прогязыком.
* Для работы с предметниками желателен язык спецификаций задач.
Язык 1С объектный (по крайней мере, как он мне известен - см. эту книгу). Так что для целостной графической нотации потребуются результаты граф-описания классов - хотя бы как у Мейера здесь в общих чертах изложено: viewtopic.php?f=75&t=3555&start=20#p72093. И надо подумать о связи данных и методов... здесь многое к программистам/ИТ-теоретикам...
- Следует учесть замечание Kori здесь (в конце цитаты): viewtopic.php?p=74438#p74438. В том смысле прежде всего, думаю, что ГИО-формы надо описывать - как декларации - а формы для этого ещё не выработаны (я делаю, как здесь: viewtopic.php?p=73245#p73245).
По языку спецификаций. В моей практике для работы с 1С-никами (по той же "Задаче на перспективу", например) использовал форму, которую раньше называли "реферат программы". В принципе она сохранена в описании задачи. При этом в самой организации сверху были предложены как средство приближённого описания техпроцессов блок-схемы с разметкой вершин испоолнителями (вариант в полях) и упрощённая форма реферата. Описателям понравилось (как я понял, обычно они с предметниками такого не использовали)...
По СМК, как уже говорил где-то, стандартом требовали вписывать литерованную БС в таблицу, где и разметка вершин расписывалась (содержание, исполнитель, документ СМК - если он по данной вершине генерился). Смысл, в общем, тот же, но всё это не отражает систему процессов. По сути это типа "варианта использования" для многих рабочих мест, как я понял в сопоставлении с подходом Усова... Т.е. то, что должно получаться при "прогоне" реальной системы алгоритмов... привязанных к рабочим местам исполнителей и срабатывающих по правилам взаимодействия процессов ("бизнес-логике ").- Для зарисовки этого пойдёт такая нотация, как использована в этой задаче. Некоторые объяснения, почему так, можно найти на этой странице.
Там по РМ выделены КОП-модули - но это для программистов (компонентных). Спецификацию же задачи начинаем с описания связности РМ (примерно того, что в типовом положении об организации/подразделении содержится в разделе "Взаимоотношения и связи" - а в юмле представляется "диаграммой коперации" - только тут плюс операция техпроцесса решения данной задачи на данном РМ - это уже как "диаграмма размещения").
Переход от спецификации к автоматизации - это прежде всего выделение на каждом РМ тех функций, что будем поручать машине. И выделение из существующих ручных реализаций машинной части - и пребразование оставшегося в инструкцию пользователю будущей машинной реализации. Тут снова получится взаимодействие алгоритмов... где надо не только форму, но и содержательные умения использовать. Что-то, кроме перехода в уместных случаях от законченных действий к "техпереходам" (т.е. действиям по изменению/удержанию состояний), посоветовать по моему опыту трудно.
)) - ну а имена операторов помещались там, где расшифровка. Можно понять всю "наглядность" такой модели - однако на исходном языке она была гораздо хуже.