Куда думать в первом квартале
Поскольку заказчики не мешают работать в эти каникулярные дни, уже нарыто довольно много относительно новых для меня и весьма интересных мыслей -- и что самое интересное, в ранее уже несколько раз просмотренных текстах (просто теперь я читаю эти тексты совсем другими глазами!):
-- программирование, моделирование, онтологизирование -- это просто шкала неимперативности, причем с упором на методы абстракции, а не на исполнение. Ключ тут -- мультипарадигмальность современного моделирования с одной стороны, поддержка качества средств абстрагирования современных онтологий с другой стороны и неутеря исполняемости современного программирования с третьей стороны. Вот пример статьи, в которой явно различаются моделирование и онтологизирование и делаются шаги по их совмещению: http://www.nist.gov/cgi-bin//get_pdf.cgi?pub_id=904119. Таких работ сейчас много, в том числе прямо цепляющих ситуационную инженерию методов (например, http://www.dsmforum.org/events/DSM06/Papers/14-saeki.pdf).
-- разобраться с иерархией выразительности универсального моделирования CYC и сравнить ее с моделерами современных CAD/PLM. Понять, куда этот ветер дует.
-- архитектура "правильного инструмента" (универсальный моделер? универсальный метод композер? универсальный мэппер типа iRing?). Глядючи на iRing, современные САПР (которые я не мыслю без PLM и коллаборации), Protege/TopBraid/NeOn и т.д. в голову приходят разные мысли, и эти мысли все связаны с предыдущим пунктом про тесную связь программирования-моделирования-онтологизирования. Я активно думаю про language workbench, которая надстраивалась бы над универсальной моделью, лежащей в -- и о том, где и в какой форме должна лежать эта модель (по идее, эта модель лежит в десятке разных CAD/PLM разной архитектуры с разными схемами) как раз и нужно думать.
-- системы кодировки (три view IEC 61346, и эти же view в RDS-PP: функциональное, местоположение и продукта -- слайд 13 из http://www.slideshare.net/ailev/rds-pp как раз наследует понимание IEC 61346) + multiple-view architecture. Разобраться с жизненным циклом "tag" (кода), показанным в IEC 61346 и взятым за основу "жизненного цикла изготовления/реализации" в ISO 15926 -- см. http://www.psybertron.org/wp-content/uploads/2010/01/IEC-61346-4-Realiization-Lifecycle.ppt
-- разборка методологической войны функциональной декомпозиции с объект-ориентированной декомпозицией при архитектурном проектировании (см. спецвыпуск INCOSE INSIGHT по MBSE, где про это подробно -- http://www.omgsysml.org/INCOSE-INSIGHT-vol-12-issue-4-Dec_09-MBSE_Theme.pdf). А какие еще декомпозиции бывают, и так ли нужно их все противопоставлять? Наводка тут опять-таки в кодировках...
-- функции как роли (на эту тему разбирался A.v.Renssen and M.West), и вообще про роли. Оказывается, роли -- это состояния! На эту тему нужно подроно читать M.West (http://www.matthew-west.org.uk/Publications.html) и думать про связь "состояний" системы из жизненного цикла (в том числе "жизненного цикла изготовления/реализации" IEC 61346-4, состояний из PSL и т.д.).
-- "поведение" и прочая терминология "хорошо абстрагируемого процесса" (ибо "с семантикой передачи токенов хорошо абстрагировать процессы не получается", как говорит Конрад Бок) из PSL, BPMN 2, OPML (ontological product modeling language) -- это прежде всего работы Conrad Bock c http://www.conradbock.org/. Представление процесса ограничениями (процедурность против логики для репрезентации процесса), трансляция (BPMN 2 почему и зачем транслируется в XPDL). Многоуровневость экземпляризации поведения/процесса/метода.
-- доразобраться в онтологических азах с многоуровневой экземпляризацией: классы против типов, инстансы и клабджекты со степенными типами (powertypes), ISO 15926-2 и прото-шаблоны, OWL, reasoners над всей этой экземпляризацией.
-- к предыдущему: найти, наконец, текст про различные значения слова "meta" (их там было штук шесть). Аж зло разбирает: потерял в собственном компьютере, это была кратенькая главка в какой-то статье, а статей у меня ой-ой сколько. И слово meta и relation в них встречается столько раз, что полностью зашумляют выдачу (про гугль и поиск опять в интернете я вообще молчу).
-- эпистемология: метод онтологической работы. Онтология онтологии, находящаяся в целевой онтологии -- рефлексивность и интерактивность онтологий, моделей, программ. По этому поводу я вчера успел написать англоязычный пост (http://levenchuk.com/2010/01/08/two-times-in-ontologies/): должно быть два времени -- одно из 4D, а второе то самое "вне времени", из которого это 4D рассматривается и строится онтология! Ибо сущности время от времени в реальной жизни переклассифицируются по разным поводам, а в 4D они принадлежат классам вечно, ибо существуют в пространстве-времени. Можно назвать это управлением конфигурацией управления конфигурации (если считать, что именно реализация 4D онтологии в каком-то хранилище реализует управление конфигурацией для инженерной системы!). Типичное "мета".
-- инженерный метод: я сейчас читаю по десятку страниц в день книжку Billy Vaughn Koen "Discussion of the Method" (http://www.oup.com/us/catalog/he/subject/Engineering/GeneralEngineering/IntroductiontoEngineeringProfess/?view=usa&ci=9780195155990). Там задается простой вопрос: почему все знают про "научный метод", и знают "великих ученых", но никто не может ничего внятно сказать про инженерный метод и великих инженеров? А ведь "инженерный метод" есть!
-- программирование, моделирование, онтологизирование -- это просто шкала неимперативности, причем с упором на методы абстракции, а не на исполнение. Ключ тут -- мультипарадигмальность современного моделирования с одной стороны, поддержка качества средств абстрагирования современных онтологий с другой стороны и неутеря исполняемости современного программирования с третьей стороны. Вот пример статьи, в которой явно различаются моделирование и онтологизирование и делаются шаги по их совмещению: http://www.nist.gov/cgi-bin//get_pdf.cgi?pub_id=904119. Таких работ сейчас много, в том числе прямо цепляющих ситуационную инженерию методов (например, http://www.dsmforum.org/events/DSM06/Papers/14-saeki.pdf).
-- разобраться с иерархией выразительности универсального моделирования CYC и сравнить ее с моделерами современных CAD/PLM. Понять, куда этот ветер дует.
-- архитектура "правильного инструмента" (универсальный моделер? универсальный метод композер? универсальный мэппер типа iRing?). Глядючи на iRing, современные САПР (которые я не мыслю без PLM и коллаборации), Protege/TopBraid/NeOn и т.д. в голову приходят разные мысли, и эти мысли все связаны с предыдущим пунктом про тесную связь программирования-моделирования-онтологизирования. Я активно думаю про language workbench, которая надстраивалась бы над универсальной моделью, лежащей в -- и о том, где и в какой форме должна лежать эта модель (по идее, эта модель лежит в десятке разных CAD/PLM разной архитектуры с разными схемами) как раз и нужно думать.
-- системы кодировки (три view IEC 61346, и эти же view в RDS-PP: функциональное, местоположение и продукта -- слайд 13 из http://www.slideshare.net/ailev/rds-pp как раз наследует понимание IEC 61346) + multiple-view architecture. Разобраться с жизненным циклом "tag" (кода), показанным в IEC 61346 и взятым за основу "жизненного цикла изготовления/реализации" в ISO 15926 -- см. http://www.psybertron.org/wp-content/uploads/2010/01/IEC-61346-4-Realiization-Lifecycle.ppt
-- разборка методологической войны функциональной декомпозиции с объект-ориентированной декомпозицией при архитектурном проектировании (см. спецвыпуск INCOSE INSIGHT по MBSE, где про это подробно -- http://www.omgsysml.org/INCOSE-INSIGHT-vol-12-issue-4-Dec_09-MBSE_Theme.pdf). А какие еще декомпозиции бывают, и так ли нужно их все противопоставлять? Наводка тут опять-таки в кодировках...
-- функции как роли (на эту тему разбирался A.v.Renssen and M.West), и вообще про роли. Оказывается, роли -- это состояния! На эту тему нужно подроно читать M.West (http://www.matthew-west.org.uk/Publications.html) и думать про связь "состояний" системы из жизненного цикла (в том числе "жизненного цикла изготовления/реализации" IEC 61346-4, состояний из PSL и т.д.).
-- "поведение" и прочая терминология "хорошо абстрагируемого процесса" (ибо "с семантикой передачи токенов хорошо абстрагировать процессы не получается", как говорит Конрад Бок) из PSL, BPMN 2, OPML (ontological product modeling language) -- это прежде всего работы Conrad Bock c http://www.conradbock.org/. Представление процесса ограничениями (процедурность против логики для репрезентации процесса), трансляция (BPMN 2 почему и зачем транслируется в XPDL). Многоуровневость экземпляризации поведения/процесса/метода.
-- доразобраться в онтологических азах с многоуровневой экземпляризацией: классы против типов, инстансы и клабджекты со степенными типами (powertypes), ISO 15926-2 и прото-шаблоны, OWL, reasoners над всей этой экземпляризацией.
-- к предыдущему: найти, наконец, текст про различные значения слова "meta" (их там было штук шесть). Аж зло разбирает: потерял в собственном компьютере, это была кратенькая главка в какой-то статье, а статей у меня ой-ой сколько. И слово meta и relation в них встречается столько раз, что полностью зашумляют выдачу (про гугль и поиск опять в интернете я вообще молчу).
-- эпистемология: метод онтологической работы. Онтология онтологии, находящаяся в целевой онтологии -- рефлексивность и интерактивность онтологий, моделей, программ. По этому поводу я вчера успел написать англоязычный пост (http://levenchuk.com/2010/01/08/two-times-in-ontologies/): должно быть два времени -- одно из 4D, а второе то самое "вне времени", из которого это 4D рассматривается и строится онтология! Ибо сущности время от времени в реальной жизни переклассифицируются по разным поводам, а в 4D они принадлежат классам вечно, ибо существуют в пространстве-времени. Можно назвать это управлением конфигурацией управления конфигурации (если считать, что именно реализация 4D онтологии в каком-то хранилище реализует управление конфигурацией для инженерной системы!). Типичное "мета".
-- инженерный метод: я сейчас читаю по десятку страниц в день книжку Billy Vaughn Koen "Discussion of the Method" (http://www.oup.com/us/catalog/he/subject/Engineering/GeneralEngineering/IntroductiontoEngineeringProfess/?view=usa&ci=9780195155990). Там задается простой вопрос: почему все знают про "научный метод", и знают "великих ученых", но никто не может ничего внятно сказать про инженерный метод и великих инженеров? А ведь "инженерный метод" есть!