Алексей Евгеньевич писал(а):
...
Именно по этому, чтобы не оказаться за рамками модели...как мне кажется и существуют критерии достижения результата, которые четко описываются на стадии проектирования...и именно по их описанию можно однозначно говорить о том, что каким бы опытом не обладал человек...он должен на выходе получить именно такой результат, строго формализованный и подробно описанный...
Очень надеюсь на Вашу посильную помощь и поддержку конкретными, четкими предложениями и замечаниями...
Уважаемый Алексей Евгеньевич,
собственно замечаний особых нет. Конкретные предложения же теперь могу сформулировать.
Во-первых, смысл ЕСР можно уточнить, как сделал чуть выше:
viewtopic.php?p=74934#p74934. Ибо есть уже единые системы поддержки управления предприятием, но не связанным с проектным производством. И есть отдельно единые среды разработки ПО - но ограниченные только этим, без интеграции управления. Единственным примером соединения, известным на сегодня, можно считать РТК-Микро, как он только что описан здесь:
viewtopic.php?p=74955#p74955. Но в современных условиях это м.б. лучше делать иначе. Вот дальше расскажу, что думаю насчёт этого.
Во-вторых, отсюда и сказанное здесь по облику ЕСР как продукта:
viewtopic.php?p=74620#p74620. Т.е. делать в концепции КУБа (ну или РТК-Микро) - но со встроенным "семантическим редактором".
Для начала правильно будет ограничиться созданием программной части только на языках высокого уровня - с выходом на внешние трансляторы. И обязательным д.б. создание и оформление руководств для человека - как операторских для заданной техники. Имея в виду, что изначально никакой автоматизации может не быть - стало быть, описываем ручную работу (возможно, механизированную). И уж потом постепенно выделяем из неё автоматизируемые части.
В-третьих, по облику того описания, которое ведётся в ЕСР. Исходя из системного подхода, как я его понимаю. Первичным д.б. описание "производственных мощностей" и заказчика, и разработчика. Понимаемых как участники одного процесса построения/эксплуатации среды поддержки работ заказчика.
Отсюда описание деятельности сторон д.б. увязано с характеристиками этих мощностей. Причём доалгоритмическое является исходным, а алгоритмическое следует из него. Как - теперь описал здесь: viewtopic.php?p=75011#p75011. В уточнение того, что было сказано раньше: viewtopic.php?p=74833#p74833.
Для программ, также как и для материальных предметов разработки, нужны как схемные, так и текстовые описания. Причём общая логика д.б. как в ЕСКД. Как мне думается, разработчики семредактора нашли один из возможных балансов форм записи. И нужны описания с различных позиций моделирования. Всё это недавно постарался отразить в этой полушутливой зарисовке работы с приемлемым редактором:
viewtopic.php?p=74873#p74873. Тут как критерии по форме моделирования, так и по его способу.
Единственное, что пока не раскрыто вполне - это синтаксис многих представлений (прежде всего вспомогательных). Что есть - можно видеть на
этой задаче прежде всего. Уже подумывал описать облик ряда других типов схем - может, как-нибудь соберусь... Кое-что по составу можно видеть в
описании FIELD - но, конечно, это не м.б. в таком виде в эргономичной среде (те граф-схемы, где дуги все "по кратчайшим" сплетаются)...
Когда-то по типовой структуре таких схем было
здесь сказано и
здесь показано - кое-что также можно видеть у
Дмитрия_ВБ - кстати, данный там принцип показа зависимостей удачно, на мой взгляд, найден (в отличие от ФИЛДа и аналогичного решения на Вашей схеме)...
В-четвёртых, как делать. Я бы начинал опять же в РТК-Микро
- но за отсутствием современной его реализации (при наличии которой и ЕСР была бы всего лишь одним из конкурирующих продуктов
) адекватным заменителем будет всё тот же семантический редактор. Даже если к моменту начала реализации ЕСР группа Лаптева его существенно не улучшит по сравнению с нынешним изданием - уже заявленные возможности обещают существенную рационализацию труда (ну а по мере улучшения можно ожидать и роста стоимости лицензии - так что м.б. лучше "маленькие сегодня, но по три"
).
Начинать, думаю, правильно было бы с разработки части, отвечающей за управление. Когда она заработает - начинать в ЕСР поддержку разработки (программируя пока в семредакторе - но ведя проект в ЕСР). Т.е. всё то, что Вы сформулировали как "работу над проектом", поддерживать.
Далее делать редактор-транслятор - среди прогязыков сначала для того, на котором пишем ЕСР. Также надо реализовать "родной" язык и какие-то из спецификационных - очевидно те, которые удобны изначальным разработчикам.
Можно было бы повторить возможности семредактора (принципы реализации "сем-ядра", внутреннюю архитектуру) - но это хорошо при доступе к решениям. Которые в данном случае предполагаются интеллектуальной собственностью изначально. Значит, и договариваться об условиях нужно уже сейчас (что м.б. и лучше, чем в случае, когда проприетарность предполагается когда-то - и об аппетитах туманно намекающих можно только гадать - как и о реальной ценности их наработок)...
Кроме того, свойства архитектуры, заявленные Лаптевым и Грачёвым, важны для любой разработки. Так что всё равно придётся оплачивать либо права - либо труд разработчиков ЕСР над "изобретением велосипеда" в этом смысле... Второе, возможно, и не так плохо - если послушать Усова, скажем - кстати, это мне напомнило, что у него тоже есть свои подходы, так что если и тут м.б. договориться - то возникнет конкуренция правообладателей... Замечу, что теперь есть также открытая "прозрачная архитектура" Дагаева - но есть и её другое обсуждение... которое тоже надо принимать во внимание...
В
результате должна появиться реализация указанных языков (включая ообмен исходными текстами с семредактором). После её минимальной отработки программная часть проекта ЕСР также переносится в рабочую инсталляцию среды. По ходу этого корректируется реализация - что при переносе оказалось делать неудобно, что некорректно. Считаем, что базовое издание ЕСР теперь есть. Развитие проекта продолжается в ней - но какое-то время можно дублировать (за счёт связи по текстам) в инсталляцию семредактора - мало ли что...
Развитие начинается с реализации ближайших целей, намеченных после базового издания. Например, можно расширить круг языков спецификации/программирования, методов управления в среде. Начинаем работать - и одноовременно могут выявляться потребности скорректировать то, что уже сделано, изменить требования к новым возможностям среды. Так оно и будет идти...