Обсуждение

Поздравляю с днем рождения.....Желаю исполнения желаний... Всегда продолжайте радовать нас своими талантами! Побольше пишите))) И самое главное, будьте счастливы!

Анатолий Игоревич! C Днем Рождения! Желаю Вам здоровья и удачи! К сожалению, об ISO 24744 высказаться пока не в состоянии.

С днем рождения! Пусть все ветры будут попутным и ведут к фронтиру!

Присоединяюсь по всем пунктам. Будь (и дальше) умницей! :)

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

С небольшим опаданием - с Днем рождения!

а инженерный цикл (постановка цели - исследования - анализ - проектирование - исполнение - освоение) не является для метода тем же, чем является ЖЦ для системы?

Является, конечно. И для каждого модуля метода тоже является, ибо модуль метода -- тоже метод...

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

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

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

А задача модуляризации софта включает (может включать) как подзадачу модуляризацию онтологий :). Я уточнил что может потому как такая задача не всегда ставится явно, а зря. Вот Вы недавно писали, что главное - это данные, а код - вокруг данных. Я очень даже согласен с такой позицией. Т.е. грамотный архитектор (проектировщик в большом) смотрит на данные и их потоки (и запасы), а от свойств данных/потоков/запасов уже зависит архитектура системы, причем не только софтовая, но и хардовая, а также административная/операторская часть. Т.е. если при разработке софта (хардово-софтово- и даже human- комплекса) центрироваться на данные, то тут мы уже чудесным образом оказываемся в области онтологии. Потому как схема БД - это уже онтология, правда уровня дизайна (проектирования в малом), а на уровне архитектуры схема БД отражает онтологию. Таким образом при декомпозиции архитектуры (в данном случае софта), нам нужно сделать декомпозицию онтологии, желательно с самого начала. Ибо если у нас онтология не декомпозирована, то и схема БД (уровень дизайна), и код вокруг схемы будет неизбежно сложным и запутанным. Тем не менее, конечно декомпозиция софта сильно сложнее декомпозиции онтологий, в силу того, что размеры софта просто огромны. Однако, на мой взгляд один из важнейших аспектов - это как раз декомпозиция онтологии, явно или неявно лежащей в основе предметной области, обслуживаемой сиим софтом. Ну и тут видно родство с декомпозицией метода. Второй аспект родства состоит, в том, что синтез метода из модулей согласно целям лежит близко к генеративному программированию, можно даже сказать - к декларативному - ибо декларируются цели, а под них ищется композиция модулей. Т.е, если задумываться о программном порождении метода (не факт, что это оправдано на практике, но все же), то тут мы уже вступаем в сферу декларативного программирования и/или тех или иных логик. Хотя учитывая популярность всяких бизнес-рулез и прочих BPM, то "программисткое" рассмотрение порождения методов вполне оправдано, ведь хочется по методу генерить бизнес-рулезы, которые будут поддерживать его исполнение, и проч.

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

Кстати, по поводу функционалка vs. ОО можно отметить, что они друг друга не отменяют, а прекрасно дополняют. Например, Скала, Питон и проч. В Хаскелл тоже есть классы с наследованием, но они конечно хитрее. Тут можно также отметить, что ОО уходит корнями в "онтологию", хотя наверное более точно говорить, что ОО и онтологии растут из одного места :). Типа фреймов и проч.

Идея интересная. Очевидно одно, язык такой модульности должен быть иным, чем язык методов для конкретных задач. Мне видится, что это должен быть язык како-то интерактивной логики, в частности интерактивной логики для ISO 24744. Без интерактивности работающую универсальность получить нельзя.

Про логику (тем более интерактивную) тут пока не понимаю, хотя агент тут появляется дважды (в отличие от "программистского" понимания модульности как удачного разбиения на самые маленькие конструкты, из которых потом может быть собрано огромное целое -- это обычно проблема "достаточно мелкой гранулярности", модульности вниз): 1. агент, который административно владеет модулем (агент-методолог), 2. агент-исполнитель метода (и далее соображения о том, как представлять метод коллективной деятельности). ISO 24744 сам по себе объект-ориентированный стандарт (задан вообще в UML). При размышлениях можно было бы перейти к факт-ориентированным описаниям (и тогда появилась бы логика в первый раз). Но можно было бы пойти еще дальше, и вернуться к pattern languages ("грамматикам деятельности"), но там опять-таки -- связь логики и "лингвистики" на нетекстовых объектах (или текстовых, если брать описания деятельности, а не саму деятельность).