Кажется, понял... перечитывая Новикова... ну и с учётом некоторых других других источников отсюда:
viewtopic.php?p=73665#p73665. При этом то, что формализовано, в данном случае плюс - помогает построить "систему языков". Как обычно, идём от
моделирования/формализации по Леонтьеву-Грековой-Фридланду.
Короче. Озадачился построитель-"
сочинитель" достижением некоей цели - сам или извне, неважно. Или даже просто взялся за некую предметку и смотрит - а чего бы в ней можно достичь? Подумал... и появился некий образ... "нетекстовый, многомерный какой-то..." ((С)
И. Ермаков ). В таком смысле, что: "Хачу! Чтобы из этого получилось такое при сяких условиях!". Всё, уже можно браться за редактор. Берёт он планшет... или смартфон (да-да, граждане разработчики, там тоже среда должна работать... и не просто, а бегать... не требуя гигов оперативки, как некоторые интегрированные решения
).
Так вот, значит. Открыл редактор и создал структуру. Под именем, которое дал своей модели (задачи, предметки). Будет, само собой, интегрированный документ типа "проект" (в смысле сказанного здесь:
http://forum.easyelectronics.ru/viewtop ... 47#p204947).
Выбрал язык "родной", организацию "линейная" - открылась трёхколонная вьюшка. Уже обсуждалась - кому надо, может найти подробно - а что важно, далее напомню.
В правой колонке (напомню, она у нас "качественная" в терминах Грековой - т.е. комменты для человека, "неявно поощрённого к незнанию математики" ((С) borix)) пишет при начале структуры своё Дано, при конце - своё Надо. Это структурно как пред- и постусловия - только в свободной форме. Между ними - в общем как коммент в целом к структуре - излагает идею решения. Стараясь придерживаться ограничений структурированного ЕЯ.
В левой колонке (она у нас математическая) пишет то же самое, но логически обоснованно. Т.е., формулирует Дано и Надо как соотношения между матемобъектами, а между ними - доказательство решения в целом. Как у Новикова для алгоритмов. Если сам из "неявно поощрённых" - то идёт за этим к коллеге-аналитику, владеющему математикой.
В средней колонке (она "информатическая" в терминах уже Фридланда) на "родном" языке формализации предполагается псевдокод. В структурных скобках, само собой... и на национальном языке. Сам построитель пишет там что-то - например, как результат пошаговой детализации.
В результате псевдокод может получиться в такой форме, как у Новикова - но разумнее предположить, что как у Вирта или Потопахина в "Решении сложных задач" - т.е. на "родном" ТЯС. Щаз объясню, почему.
Штука в том, что границы между стадиями, на которые я разделил процесс по Фридланду, условные (как и между уровнями Фридланда). Что и было показано выше - у нас фактически получилась не чисто "качественная", предметная формализация - а с переходом к логико-математической. А дальше будем так же плавно (или не очень
) переходить от математики к информатике. На самом деле, конечно, в любом случае будут качественные изменения - хотя бы те, которые Фридланд описал.
Качественный переход здесь прежде всего будет связан с выбором системы абстракций задачи (предметки). В общем, парадигмы информоделирования (программирования машины, инструктирования человека). Бодаются по этому поводу много (на КЫВТ.рф, например
) - а практический смысл в том, что часто надо с т.зр. более чем одной парадигмы на предмет посмотреть...
И как же дать такую возможность нашему построителю?
Так вот. Теперь сочинитель посмотрел на это, подумал... и снова появился образ. Типа: "А вот как это можно описать в виде абстрактной программы!". Т.е. как раз в форме, принятой у Новикова (только не забывая про абстрактные типы данных - он не всегда их приводит, часто в силу тривиальности, иной раз - очевидно, ради сокращения изложения).
И тут он снова берётся за девайс (гаджет) с редактором, открывает тот же документ-проект. И создаёт там новую структуру. Под именем той же модели - но на "математическом" языке. Причём как вариант (среда это допускает). Почему, опять же дальше будет ясно.
Снова выбирает линейную организацию. Только теперь уже начинает, скорее всего, со средней колонки. Допустим, он придумал формализацию точно по Новикову - т.е. программу на математизированном импер-прогязыке. Вот её и записывает (только придётся при жёсткой структурности без явных БП и множественных выходов). Ну, к каждой строчке - связанный коммент в правой колонке - если надо. Левую оставил пустой (раз он у нас "неявно поощрённый"
)...
Причём здесь уже м.б. широко применена декомпозиция и иерархическая (на процедуры) и диспозитивная (на сопрограммы и пр.). Так что структура реально м.б. из многих других структур скомпонована... включая единицы каталога среды. Тогда в правой колонке для каждой структуры в целом он написал, на основании каких мнений считает возможным использовать (и из каких источников). Типа, "управленческое приложение Г-Ф" по смыслу выходит, короче...
Также, где надо, даются вычислительные процедуры - непрерывные и/или дискретные. Для чего составляется математическое описание предметки. Выбирается и логика управления решением - автоматная или ещё какая. В зависимости от идентифицированного рода поведения условной системы-решателя задачи - простое или зависимое от состояний. Общее описание или включается в модельную структуру, или помещается в охватывающий проектный документ.
Так получился вариант спецификации. Который можно показать
руководителю работ. Если проект для "критической" предметки - то шеф посмотрит и скажет: "А чем докажешь? Вон разрабы не проверили как следует - видел,
чего получилось?!". Если решение у Новикова (Вирта, Гриса, Дейкстры...) целиком списано - то можно и доказательства оттуда представить.
Но обычно так не получается - используются наработки, которые по опыту/публикациям вроде как должны работать.
Так что наш "сочинитель" (на полноценного построителя системы в смысле Усова он пока что не тянет) отвечает: "Так вот (показывает на своей структуре) - этот элемент по отзыву X в похожих условиях работает N1 месяцев нормально... а этот контора Y применяет N2 лет уже везде... а вот такое сочетание Z рассматривал в посте N3 на конференции R... вот все ссылки, можно посмотреть". На что шеф закономерно вопрошает: "Вы вообще-то понимаете, что это за проект?!... трам-тарарам?!! Идите и обоснуйте всё решение в совокупности! Не знаете как - вон Лаврова почитайте!".
И с этими словами вошёл в проект сочинителя в роли шефа (со своими правами доступа, стало быть), выбрал сетевой график проекта. Посмотрел нужный техмаршрут, уточнил отдельные техоперации в смысле сказанного (и/или новые добавил), сроки проверил. И активировал расширенное уведомление о ходе проекта - себе и сочинителю... чтоб жизнь мёдом не казалась...
Ну, пошёл сочинитель... в библиотеку/сеть... нашёл, почитал, как-то заполнил левую колонку для отдельных мест структур...
Принёс показать
аналитику опытному - всё ли правильно и как дальше. Тот посмотрел и говорит: "Ну, тут нормально, здесь лажа... это обосновывается так... а это вообще только при таких допущениях...".
Также просмотрел предлагаемую модель предметки, вычислительные методы и управляющие алгоритмы. Проверил Математику-2. Заодно и исходную модель уточнил.
Заполнил он всю математику, добавил кой-чего в комменты. А затем сказал: "Вот так примерно... но всё я доказать не могу... а кое-что вообще доказать проблематично." С тем и распрощались.
Решил сочинитель пойти ещё к
другому аналитику. Тот почитал то, что уже написано. Потом задумался и говорит: "Слушай, а вообще-то зачем именно так проверять? Вон у меня стоит модел-чекер... сейчас составим модель, сформулируем требования... тебе чего проверить-то надо?..".
Читатель уже, возможно, догадался, что будет дальше. Правильно - открывает аналитик проект в инсталляции среды на своём АРМе из репоза конторы (или прямо на девайсе коллеги его локальную копию)... и создаёт там новую модель.
Как другой вариант на своём "математическом" языке.
В данном случае выбирается язык не "произвольного" рода - как все предыдущие - а "регулярного". Ибо это входной язык связанного со средой приложения, имеющий стандартное определение. Правда, как мы знаем (хотя бы из обсуждения грамматики Оберонов здесь и на Спейсе), оно м.б. не очень строгим...
Ну, пусть чекер - это Спин, так что язык модели - Промела+логика требований.
И пишет аналитик своё видение каждого элемента модели, скомпонованной сочинителем, включая понимание связей между этими элементами. В средние колонки - Промела-исхтекст, в левые - формулы требований, в правые - свои объяснения. Прежде всего - по интерпретации качественного понимания задачи (оно у нас осталось в первой модели проекта, помните?). Т.е. почему "Мы придём к победе коммунистического труда!" записывается как "
F Коммунистический_труд_победил!"...
И, если его что-то не устраивает в качественном понимании - тоже пишет в комментах.
При этом широко использует возможности среды по построению схем зависимостей элементов модели.
Написал - проверил - скомандовал трансляцию. Средний столбец превратился во входной Промела-файл (секцию единого - как там в чекере принято), левый - в *ТЛ-файл (секцию). Синтаксис реализован корректно - так что просто взяли файл[ы] и загрузили в чекер. Поработали с ними, нашли несоответствия, исправили кое-что в процессах/требованиях/комментах чекера. Загрузили обратно, указав среде обновить модель по входу. Она обновила - логировав, само собой. Возможно, сохранили прежнюю версию (или диффы - смотря какой принцип управления изменениями реализован).
Однако наш сочинитель решил подстраховаться. И пошёл к
ещё одному аналитику. Тот посмотрел - и сказал: "Подождите-подождите... зачем здесь так? Я ясно вижу, как это можно реализовать композицией функций без побочных эффектов!". Что дальше? Правильно - создаётся ещё одна модель... теперь уже на функционально-математическом языке...
Т.к. я по своей математической культуре недалеко от нашего главного героя ушёл
- то не могу сказать абсолютно точно, как этот аналитик будет обосновывать её корректность - но понятно, что при принятой общей организации моделей результаты появятся в крайних колонках - а в средней будет сообственно функциональщина в нотации, принятой в среде. Чего там за синтаксис (и точная семантика за ним) будет - я тоже не знаю - вы, авторы редактора, решайте...
я вот прагматику вам набросал...
Теперь у нашего героя голова совсем пошла кругом...
И решил он... правильно... а
очередной аналитик... правильно, сказал: "Эврика! Так мы же можем задать здесь предметную область через факты и отношения для исчисления предикатов первого порядка!".
И дальше... правильно... новая модель... теперь уже на логико-математическом языке... например, на Прологе...
Заодно проанализировал логику предметки и составил схему отношений (если редактор не позволяет из логпрограммы вытащить).
Т.к. опять же есть где исполнить (во внешнем приложении) - то туда и загружаем.
А вообще-то выходит, что некий программный продукт уже написан... причём дважды (если для нашей функциональщины тоже есть прикладная среда).
Ну а
ещё один аналитик и объяснять ничего не стал - взял да составил структуру классов типа Эйффелевской... только вместо инвариантов составил
N-мерную VMT, сказав при этом: "- Знаем мы эти инварианты классов...".
Только без всякого юмля... примерно в той форме, как у Мейера и сделано...
Ну и в качестве бонуса - выяснил у сочинителя, в какой оргструктуре эксплуатироваться будет, составил схему рабочих мест, выделил типы АРМов да набросал техпроцессы развёртывания и применения...
Но. Т.к. мы ещё не все возможности редактора рассмотрели - то волшебник Дед Секрет не хочет отдать нам предмет... в смысле, готовый продукт....
А говорит ехидно (устами шефа): "А откуда наши клиенты возьмут платформы для вашего кода?! Идите и пишите экзешники!" Снова вошёл в проект, набросал состав команды в части реализации, установил сроки. График-то работ уже задан как типовой - если что, шеф корректирует... при необходимости с командой советуясь...
И пошли теперь уже чисто
прогеры работать... Но т.к. они не тупые кодеры - то тем, что уже было написано, не пренебрегают...
Взяли, открыли каждый на своём АРМе проект в среде... посмотрели на всё уже написанное... подумали... разобрали специфицированные элементы модели по своим профилям в среде... и выбрали каждый свой прогязык. Всё равно же они в среде с общим семантическим ядром... так что как ни программируй, в пределе ЛИСП получится...
Написали... причём кто-то извратился мультипарадигменно (спецификации же разные есть
), кто-то "экстремистски-объектно"... кто-то функциональщину закодировал императивно с динамическими структурами данных на одном из встроенных ЯВУ... кто-то переписал под внешний транслятор (используя механизм определения "произвольных" транслируемых языков)... ну и т.д...
Сделали также руководства, сценарии развёртывания/обслуживания, где можно, автоматизировали.
И все снова пишут код, обоснования и комменты... правя при необходимости предметную и математические модели. А также - заимствуя готовое из каталога среды.
И вот тут что важно? В каталог включаются элементы не на основании чьего-то мнения в статье или в посте. А имеющие достоверные теоретические обоснования и подтверждённую практику применения. Т.е. по такому же принципу, что и конструкции деталей "их машин" ((С) Б. Мейер) и сооружений.
И понятно, что показанная здесь форма должна облегчать документирование конструкций. А способы ведения документов в среде (прежде всего управления совместной работой и изменениями) - также и разработку конструкций.
Здесь важно понимать, что один элемент может иметь две и более разных реализаций. И на встроенных ЯВУ, и как произвольный текст (скажем, на внешних языках - хоть в кодах реальной/виртуальной машины). И в каждой он д.б. проверен - как и материальная деталь/сборочная единица. А язык/архитектура исполнителя кода - это вроде как материал детали. Их свойства обусловливают, что и как проверяем.
Причём речь не только о коде. Но и о спецификациях, кладущихся в его основу. И об архитектурных решениях - с т.зр. классификации, скажем, такой:
...
1) Инструменты программирования — языки программирования, окружения разработки и выполнения, библиотеки и программные каркасы (frameworks);
2) Внутрипрограммные конструктивные схемы;
3) Несущее программное обеспечение (middleware), которое обеспечивает выполнение, взаимодействие и управление в распределённых системах;
4) Межпрограммные конструктивные схемы, применяемые в распределённых системах;
5) Средства проектирования архитектуры, системного анализа, спецификации требований).
...
- т.е. двигаемся к принципам ЕСКД - не только виды схем по наполнению связей (электрика/гидравлика и пр. материальные, а в ИТ - данные) - но и типы схем по назначению.
Потому и каждый пользователь (предметник, аналитик, программист) длжен иметь возможность оперативно получать и основные схемы моделей. и вспомогательные схемы, производные от содержания модельных единиц в их взаимосвязи. Скомандовал - появилась схема вызовов процедурами друг друга. Ещё - и схема обмена рандеву-сообщениями. Ещё - и схема порождения/снятия процессов (м.б. как частный случай конструкции/деструкции экземпляров представляющих классов). Ещё - и схема вводов/выводов. Ещё - и сохранений/извлечений.
Раз - и АСД для средних столбцов превратились в АТ-схему типов... где мы и области видимости, и передачи параметров, и указательные связи видим нагляднее... ну а комменты/математика пошла как примечания к АТ-вершинам...
И всё на отдельных вкладках, допустим...
И здесь поле применения исчисления графов. Не сводимого к маршрутным схемам само собой... Общая организация многих типов вспомогательных схем м.б. сходной и даже унифицированной. Конкретные же синтаксисы ещё надо определять.
И ещё. Модель на инфор-языке (программирования ВУ) можно рассматривать как реализацию какой-то из спецификаций на одном из математических языков. Но. В общем случае возможны заметные отличия. Может не совпадать и архитектура. Т.е. невозможно прямо сопоставить каждому специф-элементу один элемент реализации - или несколько, ведущих себя в модельной связке как один. И/или если и можно соспоставить - то принципы связи будут не эквивалентны. Т.е. реализация должна иметь своё обоснование (что и показано выше). Единственно что будет со всем структурно совпадать - это исходная постановочная модель на "родном" языке... она же без структурирования решения...
Это весьма наглядно для случая проверки моделей - обычно такая модель весьма упрощает суть решения.
Ну и права доступа нужны, как мы видим. Можно предположить, что по умолчанию каждый должен видеть все спецификации и иметь возможность писать в их комменты. Далее всё настраивается.