December 10th, 2009

2019

Комменты в ЖЖ: эта старая добрая бумажная почта, которая идет несколько дней

Когда уведомления о комментах стали приходить ко мне на почту через сутки-двое, я нашел способ поправить ситуацию -- http://www.livejournal.com/inbox/, где эти комменты появлялись мнгновенно. Пару суток назад ситуация драматически поменялась: в инбоксе уведомления о комментах появляются теперь тоже через сутки, или даже больше.

Поэтому не удивляйтесь, что я стал отвечать с существенным опозданием. Я просто день, два или три не знаю, что мне написали.

ЖЖ вернул времена почты, которая ходит несколько дней. Как это мило, но как печально...
2019

Моделирование ISO 15288 и ISO 24748-1 в SPEM 2.0

Вчера на 18-м заседании Русского отделения INCOSE vvagr выступил с докладом "Моделирование в метамодели SPEM 2.0 с использованием EPF Composer" -- http://community.livejournal.com/incose_ru/10384.html.

Пройдя по ссылке, вы найдете не только два с половиной часа видео с заседания (довольно бессмысленное, ибо текст на экране нечитаем. Хотя звук вполне осмысленный и разборчивый), но и ссылку на пару плагинов моделей (практики ISO 15288 и иллюстративный жизненный цикл ISO 24748) и комментарий по принятым при их моделировании решениям -- http://www.techinvestlab.ru/files/LCModels/tilselcmodels.rar

Не забывайте саму библиотеку держать в корне диска, ибо при моделировании получились очень длинные имена файлов, и длинный путь к библиотеке где-нибудь внутри My Documents в сочетании с этими длинными именами приводит к ошибкам в файловой системе.
2019

SEMAT -- метод и теория программной инженерии (software engineering method and theory)

Стал подписантом SEMAT -- http://www.semat.org. Там ставится задача найти теоретическое ядро программной инженерии: найти те инварианты описания деятельности программных инженеров, которые верны в любых разработках и которые можно дальше детализировать и уточнять в зависимости от ситуации. Список литературы: http://www.semat.org/bin/view/Main/PubsandRefs

Среди начальных подписашихся -- хорошо знакомые фамилии тех, кто занимается ситуационной инженерией методов, системной инженерией, моделеориентированной разработкой, разворачивал всех в объект-ориентированную сторону, продвигал аспектное программирование и функциональные языки.

Они говорят, что программная инженерия сейчас не представляет собой предмета -- это то ли набор преходящих мод, то ли политика с попытками собрать под эмоциональные лозунги типа agile manifesto побольше сторонников, то ли искусство. Текущие методы -- коктейль практик, а не разворачивание какой-то теоретической идеи. Средние века, одним словом. А хочется сделать красиво и научно -- чем и займутся.

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

А дальше есть варианты написать строчку либо "буду счастлив, если они там что-нибудь сделают", либо "буду счастлив, если мы что-нибудь сделаем". Забавно, что я стал обращать на такие формулировки внимание.
2019

Моделирование деятельности и ISO 15926

Этот пост -- пересказ сделанного по просьбе сообщества ISO 15926 (ага, у меня идет с ними какое-то общение, и они читают мой блог) англоязычного постинга http://levenchuk.com/2009/12/10/activity-modeling-and-iso-15926/.

Для описания деятельности требуется как минимум 4 разных группы описаний (клиентская, инженерная, менеджерская, организационная -- http://ailev.livejournal.com/764492.html (но об этом много раз писалось и раньше, например http://ailev.livejournal.com/695537.html).

Должна существовать какая-то схема (метамодель, онтология) для того, чтобы выразить эти четыре обязательные группы описаний. Многие требования к метамодели описания деятельности (поддержка множества групп описаний одновременно, масштабируемость, возможность нескольких уровней специализации/экземпляризации, возможность порождения выполняемого экземпляра модели) уже обсуждались в рамках ситуационной инженерии методов (http://ailev.livejournal.com/750878.html). Мы добавим еще несколько. Метамодель деятельности должна быть:
-- согласована с/выражена в терминах онтологии более высокого уровня (upper ontology) для того, чтобы описание деятельности потом можно было связать с описаниями продукта и описаниями сервисов (в смысле SOA -- какая-то инфраструктура эти деятельности должна поддерживать).
-- достаточно богата, чтобы позволять отображение (mapping) деятельности в инженерных САПР (на двух уровнях: тамошние workflow/routing проектных решений между рабочими местами самого САПР, и описания инженерного процесса на уровне модели управления жизненным циклом проектируемого объекта)
-- должна поддерживать правильную модель времени (http://www.conradbock.org/)
-- должна поддерживать системный подход, поэтому определять жизненный цикл как онтологическую сущность, которая имеет все эти различные группы описаний

Метамодель деятельности (activity) помянута как часть в ISO 15926-4 но нет никакой теории под относящимися к деятельности понятиями из ISO 15926-2,4 и тем, что уже находится в RDL. Информационные объекты модели (OIM) должны быть добавлены в RDL на трех уровнях:
-- метамодель деятельности (понятия)
-- словари деятельности (для различных отраслевых и национальных языков)
-- нотации деятельности (чтобы выражать данные для этой метамодели в "родной" нейтральной по отношению к вендорам софта нотации, а не только в софте в ходе проектов отображения-mapping) [сейчас нет возможности погружать нотации в RDL. Для этого сначала нужно добавить понятия предметной области нотационной инженерии (notational engineering, http://ailev.livejournal.com/549681.html, http://ailev.livejournal.com/546301.html -- но наверняка это все известно еще под огромным количеством имен. В конце концов, сейчас построением языков занимаются все, кому не лень).

Где мы можем взять ядро такой модели деятельности?
-- метамодель ситуационной инженерии деятельности (по меньшей мере эта метамодель уже сочетает инженерную и менеджерскую группу описаний). Например, мы можем начать с метамодели ISO 24744. Этот способ требует просто закодировать ее в одном из представлений ISO 15926 (например, с использованием протошаблонов). Также мы можем применить предложенную для ISO 24744 нотацию для описания жизненных циклов (http://isotc.iso.org/livelink/livelink/fetch/2000/2122/327993/755080/1054034/2541793/JTC001-N-8628.pdf?nodeid=6558555&vernum=0).
-- современные "схемы" (метамодели) САПР -- это очень интересно, ибо в САПРах уже реализованы связи между моделями деятельности и моделями продуктов.
-- исследовательские обзоры деятельностно-ориентированных метамоделей (например, работы Tyson Browning по архитектурам продуктовых процессов -- http://sbufaculty.tcu.edu/tbrowning/Publications/Browning%20(2009)–SE%20Towards%20a%20PAF.pdf).
-- метамодели деятельности из других онтологий, типа языка спецификации процессов (PSL) или CYC.
-- организационные метамодели DEMO (http://demo.nl)
-- онтологии экономного (lean) производства/строительства (Голдратт, LastPlanner, "фабричная физика" и т.д.)
-- парадигма агентского программирования (для моделирования целей деятельности, назначения мероприятий и т.д.)

Мы не должны сегодня слишком сильно учитывать гибкость (agility) и коллаборативность. Сегодня у нас просто нет достаточного знания по интерактивному моделированию (т.е. изменения метамодели деятельности с удержанием целостности уже разработанной модели в ходе рефлексивного обсуждения того, "что мы будем делать дальше" по ходу жизненного цикла). Это все сейчас про кооперацию (цепочка мероприятий многих акторов), не коллаборацию (одновременно много одновременно планирующих и выполняющих одну и ту же деятельность акторов, как во время джазового музицирования).