И если позволить здесь продолжить речь по поводу Р-схем, то не помешает обобщить принципы возможной Р-технологии на сегодня. Ибо сейчас мы можем наблюдать лишь отдельные, в определенных частных аспектах попытки подойти к процессу разработки информационных систем полиморфно.
Опять же, для начала вспомним Седова. Его ключевые тезисы:
- использование формализма, близкого к терминам решаемой прикладной задачи. Роль машинного ЯП общего назначения должна быть максимально приближена или сужена до задач непосредственного управления этой машиной и служить в качестве мостика между прикладным формализмом и "низкоуровневым" стэком данных и алгоритмов. Выражаясь по-современному: основная прикладная разработка - через DSL (domain specific language);
- задействование автоматизма для формирования DSL -> ЯП (имхо, самое главное);
- широкое применение агрегатных моделей в форме модифицированных таблиц решений, для полного, всеохватывающего описания прикладных задач. Подобная сводная форма представления знаний повышает качество визуального системного анализа (к тому же и вынуждает формировать проектную документацию с соответствующими свойствами полноты);
- попытка ликвидировать практику полиинструментальной разработки (одновременное использование различных CASE-средств и т.п., кроме ещё и "ручного" программирования).
В принципе, сегодня тоже не мало разговоров вокруг DSL, но единого системного подхода для его реализации пока не наблюдается (наиболее "продвинутый" в попытках DSL-строения, имхо, проект Nemerle, в основном представленный на RSDN). Если для стартового скачка взять идеологию Р-комплексов, то в современных условиях Р-технология должна иметь:
- язык программирования общего назначения. Можно, конечно, сделать предположение о том, что требуется разработать один универсальный язык (и он желателен, "немногое о многом", но не всегда возможен), но это отдельная тема, и не в этом суть (в любом случае, сегодня без использования чего-то существующего, в том или ином виде, не обойтись). Пока в качестве формальности просто необходимо зафиксировать факт того, что ЯП необходим.
А ЯП на сегодня имеют реальную тенденцию для качественного развития, в т.ч. и в плане прикладного формализма. Даже небольшой шаг в сторону более привычных математических выражений - тоже качественный скачок. Например, ниже записи на языке
Julia, который хоть и позиционирует себя как средство для инженерного программирования, но это вполне ЯП общего назначения (в примере: операции сравнения, функциональная запись (где "2x" => "2*x"), использование комплексных и рациональных чисел, а также пример "встроенного" DSL: r"a+.*b+.*?d$"ism - это регулярное выражение с опциями в соответствии с уже "прикладным" perl-стандартом):
Код:
1 < 2 <= 2 < 3 == 3 > 2 >= 1 == 1 < 3 != 5
map(x -> x^2 + 2x - 1, [1,3,-1])
(1 + 2im)*(2 - 3im)
2//3 == 6//9
match(r"a+.*b+.*?d$"ism, "Goodbye,\nOh, angry,\nBad world\n")
Более лучшая адаптация ЯП к базовому математическому формализму - уже упрощение для выражения прикладных задач. Плюс не будут лишними хорошие помощники в виде развитых механизмов декомпозиции и обобщения (и, кстати, согласно имеющимся источникам у того же Седова были существенные проблемы с реализацией обобщённых или полиморфных таблиц решений или "теорий"), не помешает и развитая система типизации с верификацией (где возможна поддержка, например, и прикладного формализма в виде "единиц измерения" вместе с контролем, предотвращающем возможность смешать слонов с мухами), и т.д.
Ну и не нужно забывать о том, что ЯП сам по себе есть "DSL" для задач реализации универсальных структур данных и обобщённых алгоритмов (не говоря уже о частном).
- далее, базовые принципы Р-комплексов не потеряли свою актуальность, они собраны, например,
здесь. И основная беда на сегодня в том, что современные средства для поддержки контроля версий кода, управления проектами, багтрекеры, wiki, автоматическая компиляция, сборка, тестирование проектов и т.д. не имеют общих стандартов или спецификаций, и в большинстве случаев их интеграция, мягко говоря, костыльна. Лишь временами проскальзывают "просветления", как, например,
Fossil, где понимают, что если система контроля версий кода есть "распределенная", то распределенными и "подверсионными" должны быть и связанные "баги" с документацией (хотя бы то, что реализуется в этой системе).
И, кстати,
"три колонки" в Р-технологии определяются на разных уровнях моделирования и объединяются в соответствующие "контуры", а организация интерактивного рабочего места напоминает современные попытки
"сode bubbles" и подобных семантических редакторов, где по требованию контекстно можно вытащить необходимую часть модели и расположить рядышком. Имхо, так практичнее.
- кроме схем необходимы стандарты или спецификации для всего текстового, более того, всё должно быть "текстовым". На эту роль, например, подходит
Pandoc’s markdown - упрощённо, язык для документации, который позволяет конвертировать результаты в различные форматы, в т.ч. и представлять программный код (или иное) как "литературное программирование". На сегодня, как правило, разброд и шатание даже в базовых составляющих, таких как оформление текста в комментариях для генерации HTML-документации по коду, в системах багтрекера, управления проектами, вики и т.д. Здесь ещё пригодятся наработки эмакса (фактически, ставшие "стандартами") для работы с
таблицами,
задачами, в т.ч. и создание графических диаграмм (
здесь пример), ведь и Р-технология, и Седов предполагают использование DSL-моделей не только в виде Р-схем/таблиц. Также нужны общие спецификации для визуального форматирования, как, например, в проекте
EditorConfig - попытка организовать общие правила для форматирования программного текста для разных редакторов/IDE (которые д.б. расширены, и, кстати, ещё одно "просветление").
В случае тотального текстового представления есть возможность использовать парк мощных средств для формирования текста, поиска, сравнения, анализа, вести контроль версий и т.д. и т.п. Плюс упрощаются рутинные задачи, например, программно формируются дампы данных, пусть в виде дерева, выражаемого через Р-схему, и сразу доступен весь стэк технологий. А редакторы/IDE необязательно должны отображать контекст только через псевдографику, на то они и спецсредства, но какими бы они не были развитыми, всех потребностей они никогда не удовлетворят.
Формализованный текст присутствует везде - в документации и в нестрого формальных моделях, в комментариях в ЯП и схемах, причём схемы и таблицы могут быть частью комментария или документации, из любого места можно перейти или открыть любое связанное, к примеру, из комментария или какой-то ячейки схемы/таблицы сразу перелететь в нужный "тикет" системы багтрекалки, и т.д. Причём, например, если некий режим отображает состояние задач в управлении проектами, всё-равно должна быть возможность получения текстового дампа (фактически, для всех потребностей уже есть текстовые спецификации).
И такой подход позволяет реализовать как и удобный текстовый редактор, так и GUI-режим, включая и вэб, плюс имеется возможность в любой момент сформировать требуемый комплект документации (нужной версии, полный или частичный, со всеми программами, таблицами и схемами) в любом распространённом формате - HTML, pdf и т.д., или в промежуточный docbook, latex и т.п.;
- необходимы сами Р-схемы. Они более-менее представимы в виде текста, причём, повторюсь, схема может быть в любом месте, как модульная модель, так и часть какого-то комментария. Для схем возможны удобные методы построения по мотивам эмаксовых таблиц, ну и нет никаких ограничений для реализации типовой работы через мышь или сенсорный экран;
- Р-нотация должна быть дополнена "схемно-табличной" нотацией, как схематические таблицы, представленные в соседней теме форума. Такие таблицы можно повернуть горизонтально (поменять измерения местами), там, где в примерах таблиц используются соединительные линии, задействовать Р-дуги, выделяя предикаты/результаты сверху, вычисления - снизу дуги. С помощью подобной нотации также можно выражать схемы, подобные
диаграмме последовательности,
активности (имею в виду "плавательные дорожки") и т.п.
И, кстати, можно заметить, если в таблицу, где упорядоченные, равномерные и однородные связи, вписывается "функциональная схема" -- появляются новые, уже неоднородные связи, и сразу чувствуется скачок сложности.
Думаю, что сочетание Р-схем и схематических таблиц не вызывает чувства "полиинструментальности". Они схожи внешне, через сами Р-схемы неплохо отображаются табличные данные, могут иметь схожие методы построения, имеют ряд общих свойств, к примеру, и в таблицах (не только "схематических"), и в Р-схемах есть возможность выражать предикаты через линию/дугу (что, кстати, хороший плюс для возможности представления условий не только в алгоритмах), и т.д. Во всяком случае, нет чувства uml-зоопарка. Р-схемы применимы на разных уровнях проектирования, код на ряде языков действительно нагляднее в виде схем (причём это С/Pascal-подобные или а-ля asm, ФЯП лучше читаются в виде текста, а некоторые языки сами имеют возможность для двумерного представления, как
Epigram). А также и Седов утверждал то, что такая агрегатная модель как таблицы решений служит основой не только для сведения всех данных, но и для вычленения конкретных связей и их анализа. И здесь Р-схемы м.б. помощником для выражения варианта моделирования.
Да и в любом случае, рядом со схемами будут распространены таблицы, в том или ином виде. И набор -- Р-схемы, таблицы, схематические таблицы -- необходимый и достаточный, в качестве универсального, и при этом однородного;
- ну и самое главное, нужен формализм для построения схем и таблиц. Наличие удобной возможности для ручного их формирования является обязательным, но недостаточным для полного автоматизма "DSL -> ЯП", цель которого не только упрощение и ускорение, но и контроль.
В какой-то степени, необходимо дальнейшее развитие идей Nemerle. Приведу пример из этой области (конкретно,
отсюда):
Вложение:
statechart.PNG [ 28.67 КБ | Просмотров: 19223 ]
Здесь в качестве атрибута/аннотации для класса указан прикладной DSL -- код в скобках "<#...#>", что есть "инородная инъекция" для базового ЯП, где в виде прикладного формализма описан некий простой автомат (рядом представлена соответствующая ему UML-диаграмма). Во время компиляции программы будет обработана эта инъекция, выполнятся все проверки, и класс автоматически дополнится недостающими данными и методами, реализующими автомат. Ребята из Nemerle идут дальше, пытаются организовать поддержку DSL и в IDE, также, как и для основного ЯП (подсветка синтаксиса, автодополнение, динамический контроль ошибок и т.д.). И нужен ещё один подобный шаг в сторону поддержки и "визуального". Для этого нужны строгие формализмы. Например, для разбора произвольного текста (в т.ч. и для DSL) имеются наработанные решения, как EBNF/PEG-грамматика, с возможностью разделения на модули/классы с обобщением и повторным использованием. Техники программного формирования кода на самом же ЯП тоже отлажены (лисповое квазицитирование применимо и для языков а-ля мэйнстрим тоже, пример на
Scala). А вот для формирования "визуального" у меня пока нет чёткого понимания.
В частности, Р-схемы и таблицы (в т.ч. и "схемные") имеют много чего генетического общего. Р-схемы вменяемо выражаются в виде табличного представления (в т.ч. и отцы-основатели сами приводили
примеры). Но это не основная сложность. Желателен формализм, который выражает не только то, что необходимо показать, но и отражающий связь между источником (базовый программный код, код DSL, бинарные или другие данные модели, если прикладная модель не в виде текста) и визуальной моделью (схемой, таблицей). Такой формализм должен упрощать и дать возможность наладить, фактически, оперативную двустороннюю связь: код/DSL <-> схемы/таблицы. Как вариант, я сейчас анализирую возможность применения
Datalog (
пример его использования для задач анализа программного кода, здесь
презентация).
Короче говоря, над этим вопросом ещё нужно поработать.
Здесь ещё нужно уточнить. Источником для визуальных моделей может быть что угодно (DSL, в виде текста и нет, код на ЯП). Нужна и обратная связь, из схем и таблиц необходимо формировать целеуказания для формирования кода на ЯП, или другой DSL. Причём, к примеру, те же таблицы м.б. "внешними", подготовленными в каком-нибудь экселе. При этом может существовать эффект обобщённости, например, в теме про схематические таблицы продемонстрировано, что алгоритм можно выразить через Р-схему, алгоритмическую таблицу (или через несколько связанных таблиц), схематическую таблицу, плюс может быть "прикладная" таблица решений, в типовом или в каком-то специальном варианте, а также и Р-дерево решений.
Всё это желательно учитывать в потенциальном формализме для выражения "табло-схем", причём он должен упрощать, как BNF/PEG для разбора сложного текста, и быть применимым на уровне регулярных выражений или SQL-запросов.
И, кстати, если присмотреться к примеру с автоматом выше, то можно заметить, что прикладной текстовый DSL, фактически, есть язык визуальной схемы. Ранее была ссылка и на другие подобные языки для UML-диаграмм (
здесь). Р-схемы/таблицы заменяют, фактически, весь UML-стэк, и требуют одного формального языка - опять же, полиморфная разработка.
А формальный язык схем удобен и для ряда рутинных задач, вот пример:
использование инструмента трассировки событий в Erlang (там формализм скрыт в виде вызова функции, но я имею в виду сам принцип).
Итого:
- важен сам организационный
подход;
- необходимы спецификации для представления:
* формализованного текста (включая ссылки, форматирование и т.д.),
* таблиц,
* Р-схем,
* схематичных таблиц;
- требуется формальный язык для определения схем и таблиц.
Что даёт возможность применить набор уже имеющихся на сегодня технологий для контроля версий кода, формирования документации, управления проектами и т.д. (с потенциалом их улучшенной интеграции, насколько возможно), так и реализовать новые инструменты.
Вход
FAQ
Поиск
и даже не в рамках различных "исчислений графов"... ибо та же ЕСКД сформировалась ещё и до видеоструктур Дейкстры...
). Предварительное замечание: далее рассмотрение именно и только с позиций теории систем, просьба не разводить дискуссий по личным предпочтениям тех или иных из представляемых вариантов объектов, процессов, явлений (полагаю, предел можно считать обозначенным 
