Сергей Прохоренко писал(а):
Сергей Прохоренко писал(а):
Если Вы о том, что программная документация должна стать составной частью каждого программного проекта (с возможностью по гиперссылкам переходить к конкретным местам программы), то я с Вами совершенно согласен.
Именно!
...
Хорошая мысль.
И мне нравится
Проиллюстрирую её уж окончательно. Проект должен иметь форму РДП-документа, где содержится всё перечисленное. Как это всё организовано для человека - зависит от формы - текстобазированной или граф-базированной ("графитной", на основе лист-силуэтов - т.е. в принципе информатизованных синт-диаграмм, которые мы с Вами обсуждали
здесь). Моя мысль - что вторая является основной (в ней РДП-документ редактируется) - а первая образуется как "отчёт по запросу" (символ-сборка).
Как выглядит графит-форма - см. в этом примере, а текстобазированная - см. исходные материалы для этой задачи (указаны в Дано; смотреть образы через позицию "Для просмотра"). Конечно, задачи разные, но суть схватить, наверное, несложно. Тем более в титул графит-документа специально включил типовые докэлементы, которые есть и в текстовом.
То, что в графит-форме нумерованные заголовки (номера в угловых скобках) - в другой форме заголовки к содержанию. По смыслу (над структурой лист-силуэта) разные элементы содержания, оформленные как графит-схемы, связаны ссылками по именам в текстах вершин (ведутся по правилам графит-языков); содержание, оформленное как текст жёстких полей, связывается как в обычном гипердоке, через наводимые сочинителем ссылки на номера заголовков/поставленные закладки.
Как я вижу предметную форму документа - качественно в общих чертах описал
на этом листе в жёстком поле Титул.2.2 Введение в предмет. Специалист, возможно, сформирует иную структуру.
Механизм формирования символ-сборки - см. в общих чертах
в ОЯ-правиле СВ из этого пункта - видно что м.б. настроено много конфигураций сборки. Что в какое жёсткое поле включать - решает сочинитель - а также и в какие конфигурации сборки оно войдёт. Тем самым в проекте фиксируются все сведения о "предметке" (или описываемой задаче) - а выбираться могут только некоторые. В принципе как паспорт задачи должно получаться то, что описано
в этом разделе. А как видно из описания Задачи 1.1.1, материал можно и сократить. Можно и как-то иначе описание строить.
Алгоритм сборки выкладывает содержимое жёстких полей в порядке возрастания нумерации и вставляет управляющие конструкции лист-силуэтов в текстобазированный документ как элементы "текста как интерфейса" (ссылки, командеры и пр.), а также заголовки к тексту, таблицам и изображениям. Ну также выкладывает на лист сборки графику некоторым образом (очевидный вариант - основываясь на порядке следования в жёстких полях) - сочинитель потом может редактировать собранный документ независимо.
Предполагается, что формат символ-сборки - ББ-документ, соответственно используется ББ-редактор. Вероятно и вся РДП-среда пишется на КП - возможно, как РДП-подсистема ББ.
Для трансляции в исхтекст используются как раз языковые связи между графит-схемами. Естественно, транслироваться могут только схемы на определённых языках - для них д.б. доступно значение атрибута <exec> (нетранслируемые м.б. только <draft>). По связям через имена выбирается совокупность схем, топология и текст которых формируют исхтекст (программу с инвариантами и исключениями, *TL-требования в обычной или never-записи, систему Promela-процессов и т.д. - зависит от системы графит-языков).
Предполагается, что сочинитель выбирает схему - а РДП-редактор по определению может выбрать все остальные схемы на всех языках, представляющие тот же исхтекст. Но для контроля должен задаваться вопрос типа "Вы хотите оттранслировать всё или только выбранную схему?"
Файл исхтекста грузится в ББ, или Spin, или ещё куда, там обрабатывается - и м.б. снова загружен в РДП-документ как входной, обновляя собой все представляющие схемы (опять же по именным связям).
Вот так примерно.