DRAKON.SU

Ни разу не захотелось назвать икону "Вопрос" по другому.

А вот некоторые другие названия как-то незаметно заместились.
При общении с людьми не подготовленными, в контексте производственного совещания странно звучат слова «дракон-схема», «икона».
Зато неплохо воспринимаются «карта действий», «карточка».

Карта действий описывает какие действия необходимо предпринять исполнителю для достижения заранее определённой цели.

Сравните:

Дракон-схема описывает какие действия необходимо предпринять исполнителю для достижения заранее определённой цели.

или

Дракон-схема содержит алгоритм действий, которые необходимо выполнить исполнителю для достижения заранее определённой цели.

Если упоминается «дракон-схема» - требуются дополнительные пояснения (что это, зачем это), если «карта действий» - то это просто карта действий : )

Под «карту действий» хорошо легло слово «карточка».
Карточка Вопрос, карточка Действие, карточка Выбор и т. д.
Карточка содержит описание действий. Действия вписаны в карточку.

Икона Адрес — карточка Переход.
Икона Имя ветки — карточка Адрес.

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

Карта действий составлена на языке Дракон.

Вы, видимо, тоже пришли к идее "натурализовать" составление схем, используя "кассу вершин с отводками и рёберных элементов" в печатном виде для выкладки на столе? Очень удобно, кстати, в некоторых случаях...

Карта действий - интересно как термин-псевдоним. А вот карточка применительно к вершине схемы - пожалуй, неточно именно потому, что наводит на такое натуральное представление схемы с "разрезанием на карточки поперёк вертикалей". Можно говорить "узел действий"...

Здесь

Где-то с месяц пользуюсь термином «оператор». Получается очень естественно : )

Оператор Начало, оператор Вопрос, оператор Выбор, оператор Вариант, оператор Действие.
Операторы языка Дракон, операторы Дракон-схемы, операторы Карты действий
и т.д.

Выяснилось : ), что оператор это такой человек, который выполняет предписанные ему действия.

Для сравнения:

Оператор должен выполнить действия предписанные оператором Действие.

Оператор должен выполнить действия предписанные иконой Действие.

Оператор должен выполнить действия предписанные карточкой Действие.

Оператор должен выполнить действия предписанные виопом Действие.

Оператор должен выполнить действия предписанные графоэлементом Действие.

Материал из Википедии — свободной энциклопедии

Оператор может означать:

* оператор (математика) — то же, что математическая функция;
* оператор (биология) — последовательность ДНК, принимающая участие в регуляции активности генов;
* оператор (физика) — математические операторы в квантовой физике;
* оператор (программирование) — наименьшая автономная часть языка программирования; команда;
* оператор (поисковая система) — язык запросов к поисковым системам
* оператор связи — предприятие по предоставлению услуг связи;
* оператор (профессия) — группа профессий по управлению работой оборудования (установок) различного вида и назначения; по проведению и обеспечению фото- кино- и видеосъёмки;
* системный оператор (от англ. system operator) — системный оператор многопользовательской копьютерной системы, первоначально - системный оператор мейнфрейма, затем так стали называть операторов BBS и узлов сети Фидонет, однако наибольшую популярность термин получил в соращенном варианте - сисоп (от англ. sysop).

2Ильченко Эдуард:
Находиться в терминологическом контексте ЕСКД и не впадать при этом в программизм можно с помощью подстановки:
Дополнено..

Спасибо.

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

Можно для примера посмотреть схемы оборудования, каковых много публиковалось в "МПСС" - архив имеется здесь.

Матер-схемы обычно имеют более одного выхода - но схемы деятельности тоже, если учитывать исключения. Ну и конечно импер-шампур-схемы не определяют "подключения" выходов - читатель должен определять сам по контексту вызова. Это решено, как и в ЕСКД, введением схем подключения процедур на ДМ-языке.
Можно отразить адресацию выходов в виопах Конец схем Д2М-языка - но читать схемы подключений, где тела процедур свёрнуты, удобнее. Лишний же синтаксис - это усложнение редактора - с каким скрипом более простые представления программируются "избыточно сложным" языком и средой, мы уже видим

Лучше сказать просто "шины" и все, кто имел дело с нормальной документацией, сразу поймут о чём речь. Не возьмусь судить, чем было вызвано введение наблюдаемого терминологического разрыва при создании языка ДРАКОН, но, на мой взгляд, разрыв в значительной степени повлиял на распространение языка после опубликования ДРАКОНа. Причём, не в лучшую сторону.
А приличная масса специалистов, обученных работать с терминологией ГОСТ/ЕСКД в тот период была. На сегодня же такой "закритической массы" нет. Соответственно, сейчас без разницы, с каким синтаксисом и терминологией использовать методологию ДРАКОНа. Экстракт всё равно выделится быстро и не даст особо вольничать со сложностью.