DRAKON.SU

Здесь я не понял о чем речь. Для спецструктуры же остается в силе логика переходов в "начальную" и "конечную" вершины структуры (*, #) - я об этом писал.

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

а как мы попадем в конечную вершину, если проходимых прямых дуг нет?
Чем дальше в лес ... непонятки только увеличиваются.
Базовая структура в РТК имеет следующую обобщенную форму
...

Если мы и буду использовать Р-технологию, то или сами будем писать компиляторы или проспонсируем разработку.

Собственно, у меня были размышления над тем, как можно организовать циклы. Для меня неясно, будут ли переходы на спецдугу (*, #) срабатывать как continue и break. А также я пытался заложить возможность для операции "redo", пример отсюда....

Можно пойти другим путём. Скажем, если реализовывать семантику циклов вида питоновских "while-else" и "for-else", то для указания переходов можем ввести ещё один символ, к примеру "!", что означает "нестрогий" переход. Т.е.:

- "!*..." - "нестрого" перейти на начало: continue без for-инициализаций - "redo"
- "!#...." - "нестрого" перейти на конец: break, но выполнить часть "else"

В принципе, ведь в тех же циклах, как "while", как-то попадают в конечную вершину, даже если не было выполнения прямых дуг...

Кстати, в смысле развития сегодня - один из вопросов - это как раз о варианте с инверсной нагрузкой графа (действие-вершина)...

Идея использовать предикат цикла не над обычной дугой, а сразу над специальной дугой, как в предоставленном мне компиляторе, так и в примерах с сайта Фонда Глушкова, в принципе, тоже интересная, но тогда такой подход должен использоваться везде, иначе каша получится, причем невкусная.

То есть Вы хотите изменить семантику переходов в спецструктуре, заменив переходы на начало и конец графа на переходы на начало и конец данной спецструктуры, имитируя continue и break в некоторых языках, плюс ввести дополнительный вид структуризатора для перехода на именованную дугу структуры. Но ввести дополнительный вид не получится, потому что именовать дуги нельзя, именовать можно только вершину структуры. Если мы введем подобное, то, во-первых, полностью нарушим логику р-схем, и, во-вторых (связанное с первым) нарушим соответствие ГОСТу.

А в общих циклах обратные и работают как exit, а переход в начальную вершину(без всяких структуризаторов) и есть continue.

Смысл примера с луа/питоном я не совсем понял, в чем логика редо? Если смысл в том, чтобы повторить итерацию, при этом не изменяя итератор, то это бессмысленно, потому что таким образом мы нарушаем логику работы цикла FOR, это уже и не FOR вовсе.
...
И на эту дугу с предикатом можно навесить вложенную структуру с именованной вершиной, и прыгать, и на неё и от радости, не трогая итератор, но как по мне, такой изврат лучше с помощью базовых структуры делать. А то вмешательство в FOR может стать источником трудноуловимых ошибок.

Ещё одна статья Вельбицкого...

R-technology: A structured-design software engineering methodology developed in the early 1970s.

R-technology has been used by software developers in the USSR’s strategic missiles industries.

The Soviets claim that R-technology enables software professionals to electronically “draw” on a computer screen the algorithmic design of the software, which is then automatically mapped to a compiler that generates executable object code.

Как раз речь, в основном, об РТК-микро, где, кстати, сказано, что нет параллельного соединения структур (именно в микро)

Короче говоря, в голове одна Р-каша пока...

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

Параллельные соединения в РТК-микро есть

...
Собственно, к чему я веду. Во-первых, понять, есть ли потребность у общества в таком Р-конструировании, есть ли конкретные идеи и пожелания.
А во-вторых, хотелось бы понять, очередной ли это велосипед? Здесь на форуме есть обсуждения каких-то структурных и семантических редакторов и др., м.б. кто-то укажет, что всё уже изобретено ?

По велосипедам - вот если будет профессиональный ответ на это: viewtopic.php?p=74873#p74873 - так делать или не так (хотя бы от разработчиков семредактора) - то будет ясно, что уже изобретено (ими), что изобретается, а что ещё предстоит (и какие здесь м.б. проблемы)...
...
А вот взять себе на заметку интеграцию и поддержку работы оргсистемы в целом (как было, судя по всему, в РТК-Микро) - обязательно.
...

Технологический модуль. В Р-технологии это понятие является развитием известных понятий (структура, модуль, абстрактный тип данных, базы знаний) в направлении стандартизации понятия "интерфейс". Технологический модуль в Р-технологии (РТМ) - это элемент абстракции процесса программирования. Он состоит из трех частей:

Интерфейсная часть РТМ - это то, что всегда видит специалист на экране дисплея или распечатке при обращении к РТМ.

Операционная часть РТМ определяет все допустимые действия специалиста в интерфейсной видимой части модуля, а также связь ее с информационной частью и другими модулями.

Имя чертежа - произвольная последовательность символов, имеющая в некоторых случаях краткий эквивалент или шифр.

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

Рабочая часть - функциональная часть чертежа, задающая в строгой алгоритмической форме (например в Р-схемах) соответствующий фрагмент проектируемой структуры - алгоритма, программы, СУБД и т.д.

В поле абстракций определяются любые неформальные обозначения, используемые в рабочем поле или поле спецификаций чертежа и соответствующие математическим текстам после слова "где...".

Чертежи (точнее - содержательная их часть) могут быть связаны друг с другом иерархически через механизм раскрытия любого обозначения или понятия на чертеже. Раскрыть понятие можно в поле абстракций данного чертежа, а также с помощью чертежа следующего уровня или того же уровня иерархии - вариантное определение (рис. . Раскрываемые понятия на чертеже выделяются тем или иным способом (цветом, тоном и др.). Иерархия чертежей может быть многоуровневой и многомерной.

Помимо иерархии, чертежи можно объединить в контуры, связь между которыми не является жесткой, алгоритмической, а скорее информационной, например: "об этом в другом контуре сказано в таком-то месте" или "требования к этому алгоритму сформулированы в контуре технического задания там-то" и т.д. Контуры проекта могут быть самыми разнообразными, например: информационный контур заказчика (техническое задание), моделирующий, алгоритмический, рабочий, оптимизирующий время работы, эксплуатационной документации и т.д. Связь между понятиями в разных контурах может быть разветвленной и поименованной (средствами меню), например:

Такая система разветвленной связи между различными понятиями чертежей (при электронной, безбумажной схеме ее реализации) позволяет оперативно сформировать гибкий интерфейс всестороннего и быстрого проекта.

Технологический процесс. В Р-технологии он формируется на этапе технологической подготовки работ та РТМ, соответствующим образом запрограммированных. Этим достигается особая гибкость процесса конструкторской разработки в Р-технологии, обеспечивающая эффективную ее настройку на конкретные условия коллектива, планируемое повышение качества программных средств и производительности труда программистов.

При формировании конкретной технологической линии в Р-технологии используется понятие универсального технологического цикла, которое означает, что любая разработка (и/или производство, использование) программной системы должна иметь следующий универсальный технологический цикл выполнения:

где СА - системный анализ, МП - модельное проектирование, Р - собственно работа, Д - документирование работы, АНАЛИЗ - итерационный процесс улучшения выполненной работы.

Указанные имена условны и на разных стадиях и этапах технологического процесса могут иметь другие названия, сходные по сути: предпроектные исследования, эскизный, технический и рабочие проекты, создание прототипа, экспертиза проекта, отладка, тестирование, отчего выполнении работы, контроль исполнения, производство, сопровождение и т.д.

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

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

Этап документирования в традиционном его понимании отсутствует в Р-технологии, ибо комплект чертежей программного проекта по ГОСТ 19.005-85 (ISO 8631Н) полностью заменяет документ "Описание программы" по БСПД. Эксплуатационная же документация проекта (инструкция для пользователя, оператора и др.) получается не изготовлением заново, как обычно, а редактированием и автоматизированной генерацией из поля спецификаций соответствующего комплекта чертежей. Объем ее меньше традиционного, так как содержит только основные, самые необходимые для эксплуатации системы сведения, а за остальными пользователя отсылают к соответствующему комплекту чертежей проектной документации. Проектная и эксплуатационная документация создается по унифицированным технологическим операциям, содержащим соответствующие шаблоны и трафареты, что облегчает ее понимаемость и усваиваемость.

В комплект поставки программных средств, изготовленных по Р-технологии, входят отредактированное дерево проекта (комплект чертежей), инструкция по генерации системы, программа испытаний с генератором контрольных тестов и комплект эксплуатационной документации.

Производство программ по Р-технологии-это Не только тиражирование программного проекта, но и большой комплекс работ по его привязке к условиям эксплуатации. В процессе производства исходный программный проект рассматривается лишь как прототип или опытный образец и фактически заново переконструируется на макроуровне таким образом, чтобы обеспечить удобную и эффективную эксплуатацию соответствующей программной системы в конкретных условиях эксплуатации. К производству относится также большой комплекс мероприятий по маркетингу, сбору статистики при использовании проекта, анализу рекламаций, модификации проекта в результате накопленного опыта эксплуатации и т.д. Все эти работы проводятся независимо от разработчиков проекта теми же инструментальными средствами, что и разработка по технологическим маршрутам и РТМ, запрограммированным для задач производства.

Использование программ по Р-технологии осуществляется независимо - от тех, кто их разрабатывал, и от тех, кто их производил. Пользователь программной системы, разработанной по Р-технологии, Может по комплекту документации поставки разобраться как угодно глубоко в принципах работы системы и по опыту ее использования самостоятельно ее модифицировать или дать задание на проведение таких модификаций службой сопровождения или производства.

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

В Р-технологии каждая работа также имеет паспорт, в котором указаны ее название, регистрационный номер (шифр), организационные и технические данные. К организационным данным относятся сведения о том, кем сформулирована работа, когда и кому поручена, в какие сроки и чем должна заканчиваться, кому и в каком виде предъявляется и т.д. Эти данные передаются системе при определении неформального обозначения в поле абстракции соответствующего чертежа проекта. По этим данным в системе формируется сетевой график выполнения работ и проводится автоматический контроль за его соблюдением. В технической части паспорта сообщаются сведения о технологическом маршруте для данной работы, т.е. последовательности технологических операций с соответствующими организационными данными для каждой из них. Большинство данных в организационной и технической частях паспорта на работу формируются автоматически.

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

В моём понимании повторять Р-среды буквально (с точностью до единой нотации) может, и не стоит...

...
Вообще, моя идея такая: проект должен содержать метаданные, включающие в себя описание решаемой задачи и структур данных, которые будут использоваться. С последовательной декомпозицией на подзадачи. У всех проектов, с которыми я работал логика настолько проста, что там не нужен ДРАКОН. Работа кода понятна после прочтения задачи и последовательности преобразования структур данных.

А генерацию кода из ДРАКОН схемы, где программный код вписан в блоки я считаю ложной ветвью развития, т.к. на такой схеме все равно не видно преобразования структур данных. Они будут понятны с первого взгляда только для очень простых программ. А так их ценность ненамного выше псевдокода.
...

Кстати, обратите внимание, что у меня уже не говорится о чертежах как основе всего. Это не дань "структурным скобкам" - а понимание того же, что сказано здесь:

- что и Прохоренко и Лаптев подтверждают...

Третья мысль Ивана Кузьмицкого

Отчего бы формальным схемам не выливаться в исходный текст на Обероне, а оберон-программам не отображаться в формальную схему? Автоматически.

Ответ Паронджанова на третью мысль Кузьмицкого

Ваша мысль заслуживает одобрения и всяческой поддержки. В нашей системе сделано только прямое преобразование. Обратного нет.

В отличие от нас, Вы предлагаете реализовать не только прямое, но и обратное преобразование. Это высший шик (хотя кое-кто может посчитать это «архитектурным излишеством. Но я так не думаю). Я хорошо помню, что мне рассказывал Ковалев, сотрудник Игоря Вельбицкого — автора Р-технологии. Ковалев сказал, что когда они сделали и прямое, и обратное преобразование, это произвело на сторонних программистов ошеломляющее впечатление. (Прошу не рассматривать мои слова как высказывание в поддержку Р-технологии).

Думаю, если Вы, уважаемый Иван, сумеете реализовать «туда-сюда» преобразование, это будет просто здорово! Восхищаюсь Вашим дерзким предложением!

Конец ответов Паронджанова на предложения Кузьмицкого

...
Это частный случай. А как представлять проект, где, скажем, одни полиморфные функции над абстрактными данными?
...

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

Собственно, у меня были размышления над тем, как можно организовать циклы. Для меня неясно, будут ли переходы на спецдугу (*, #) срабатывать как continue и break. А также я пытался заложить возможность для операции "redo", пример отсюда:

...
Я с трудом нашёл лишь один случай свидетельств тех лет, а оказывается, что здесь, на месте, не отходя от кассы, имеется "человек-легенда"
...