Сообщение А.С. Усова:
Вложение:
- для последующего опубликования.
Хотя оно краткое, при обсуждениях подходов автор рассказывал о своих взглядах на реализацию. Так, для программ он полагает целесообразным как вариант (проверенный на практике) структурировать описание на элементы, определяемые независимо. Каждый элемент должен иметь описаание как на языке программирования (высокоуровневом, машинном), так и на языке спецификации (в частности, псевдокоде).
Можно считать, что речь идёт о структурировании программы на области агрегации, имеющие набор языков преедставления. При этом язык должен оперативно переключаться, о чём говорил другой автор здесь (формат мой):
...
1. Оперативная генерация текста - приятная фича. Ибо наглядно.
2. Типов примечаний может быть много. На схеме отрисовали три: КОД (не примечание, вообще-то); ПРИМЕЧАНИЕ (связанный логически с модулем кусок текста) и 2DO - напоминальник внутреннего использования, что надо допилить. Другими не пользуемся.
Все три можно выводить в текст - в комментариях, например.
. Модуль в данном случае - это одна вершина схемы (что и есть частный случай содержания области).
Кроме того, нужно единство представления понятий, чтобы избежать описанного здесь:
...
Цитата:
...
Тезис 5. При написании текста программы алгоритм уже не надо держать в голове, как это делается при обычном программировании.
Строго говоря, это не достоинство языка шампур-"слепышей" - а конкретной реализации на его базе. Следующей принципу разделения аспектов "управленческого", "алгоритмического", программного - по сути, по степени формальности содержания вершины. Что предполагает стандарт разметки вершин "слепыша" записями для каждого аспекта и использования каждого типа записи при редактировании и трансляции.
Естественно, это не критика - сам подход, считаю, плодотворен. Единственное что - принятое выделение аспектов не единственно возможное. Кроме того, в реальном применении оно как бы сочетает в себе и детализацию - а в общем случае это другое измерение содержания предмета описания, чем степень формальности. И в сложных проектах м.б. оправданно дать возможность независимо детализировать и устрожать - но надо думать, как.
Пока же детализация возможна как последовательное усложнение схемы - была одна вершина, стал подграф. Ну и текст где-то разносится (что предполагает активный копипаст), где-то перерабатывается.
Цитата:
...
Тезис 7. В чём теперь заключается программирование? В том, что для каждой иконы нужно написать код, который выполнит то, что написано на этой иконе. Как правило это 1 строчка.
Как раз достижение такого соответствия в общем случае и требует той самой детализации схемы.
Однако при простых и типовых проектах опять же можно дублировать и редактировать схемы, а также копипастить куски...
Только придётся, например, перебивать ручками имена величин, не такие же в новом проекте... с риском ошибиться... и схемная запись этого не упростит... особенно когда часть текста скрыта в примечааниях...
...
- иначе говоря, всё то же самое, что с указателями - нужны поля подстановки имён величин. А в перспективе и "имён действий", связанных с величинами по типам примерно так, как в обычном определении функции как отношения. Кстати, это тоже обсуждалось в связи с подходом Усова...