Порождающие модели: как им учить?
Между разными моделями бывают разные отношения. Так, людям трудно свободно ориентироваться в стеке из ряда мета-моделей и "порождаемых ими моделей". Только вчера на одном из семинаров с клиентами нами было потрачено не менее получаса для объяснения того, как мета-модель электронного документооборота может "породить" любую модель документооборота организации. Ошибкой всех участников было то, что ежели в "языке" есть слово "Бармалей", то присутствие этого "Бармалея" в любых предложениях этого "языка" неминуемо. А уж задание языка (грамматики) схемой вообще стало камнем преткновения: схема рассматривалась не как язык (грамматика), а как высказывание на языке -- после чего торжествующие представители клиента убеждали нас, что жизнь не соответствует представленному о ней высказыванию! До самих высказываний, порожденных моделью, дело не доходило.
Клиенты не готовы обсуждать мета-модели (например, концептуальные модели электронного документооборота), но радостно обсуждают полученные из них конечные модели (например, тексты нормативных документов для конкретного варианта системы электронного документооборота) -- без малейшего представления, как затем эти модели менять, почему они получились именно такими, какие принципы легли в их построение...
А ведь использование "порождающих моделей" -- это и есть моделецентрическая системная инженерия (http://ailev.livejournal.com/721298.html). Термин "порождающая модель" используется тут в том самом смысле, что "порождающая грамматика", введенный Хомским (и его не нужно путать с "порождающей моделью" из математической статистики, http://en.wikipedia.org/wiki/Generative_model). Термин "порождающий" был использован Хомксий как технический термин в особом смысле. Когда говорят, что грамматика "порождает" предложение, смысл этого в том, что грамматика дает структурное описание предложению (Chomsky, Noam, 1965. "Aspects of the Theory of Syntax". MIT Press). Модели в моделецентрической системной инженерии порождают описания систем в том самом смысле, что порождающие грамматики порождают предложения -- они дают структурированные описания систем. В сущности своей, моделецентрическая системная инженерия -- это про использование языковых слоев (слоев описаний описаний, слоев пар мета-моделей и моделей) для описания систем.
Все это хорошо и перспективно, но как объяснить это людям? Я хорошо помню, как сам путался на заре своего программистского детства в том, что "один язык может описывать другой язык, а тот -- сам служить описанием третьего языка". Неподготовленному человеку разобраться в типовом стеке моделей MDA невозможно: туда входит минимально четыре таких уровня -- MOF или мета-мета-мета-метамодель, UML 2 или мета-мета-мета модель, стереотипы UML или мета-модель, и "целевая модель" или просто "модель". Более того, в современной версии ограничение на число этих уровней снято, и этих уровней легко может быть более четырех.
Я думаю, что тут нужно использовать "образование будущего" (http://ailev.livejournal.com/722451.html):
1. отмоделировать (тут это слово используется как в НЛП, в смысле поиска "возникающих внутри головы и тела профессионала визуальных, аудиальных, кинестетических образов, позволяющих ему великолепно выполнять свою работу") то, как опытные программисты и системные архитекторы пользуются этими мета-модельными представлениями (тут слово "модель" используется как в MDA -- беда с этими "моделями", каждый раз приходится уточнять, что за "модель" имеется ввиду).
2. придумать методику по научению пользоваться этими образами (какие должны быть объясняющие создание требуемых образов метафоры, какие должны быть закрепляющие "ментальные алгоритмы" тренировочные упражнения, и т.д.). Сама эта методика должна быть "замаскирована", чтобы не вызывать ощущения ситуации явного "тренинга" -- клиенты ведь очень любят беседовать, но терпеть не могут "тренинга" кроме очень особых и редких специально оговариваемых случаев.
Клиенты не готовы обсуждать мета-модели (например, концептуальные модели электронного документооборота), но радостно обсуждают полученные из них конечные модели (например, тексты нормативных документов для конкретного варианта системы электронного документооборота) -- без малейшего представления, как затем эти модели менять, почему они получились именно такими, какие принципы легли в их построение...
А ведь использование "порождающих моделей" -- это и есть моделецентрическая системная инженерия (http://ailev.livejournal.com/721298.html). Термин "порождающая модель" используется тут в том самом смысле, что "порождающая грамматика", введенный Хомским (и его не нужно путать с "порождающей моделью" из математической статистики, http://en.wikipedia.org/wiki/Generative_model). Термин "порождающий" был использован Хомксий как технический термин в особом смысле. Когда говорят, что грамматика "порождает" предложение, смысл этого в том, что грамматика дает структурное описание предложению (Chomsky, Noam, 1965. "Aspects of the Theory of Syntax". MIT Press). Модели в моделецентрической системной инженерии порождают описания систем в том самом смысле, что порождающие грамматики порождают предложения -- они дают структурированные описания систем. В сущности своей, моделецентрическая системная инженерия -- это про использование языковых слоев (слоев описаний описаний, слоев пар мета-моделей и моделей) для описания систем.
Все это хорошо и перспективно, но как объяснить это людям? Я хорошо помню, как сам путался на заре своего программистского детства в том, что "один язык может описывать другой язык, а тот -- сам служить описанием третьего языка". Неподготовленному человеку разобраться в типовом стеке моделей MDA невозможно: туда входит минимально четыре таких уровня -- MOF или мета-мета-мета-метамодель, UML 2 или мета-мета-мета модель, стереотипы UML или мета-модель, и "целевая модель" или просто "модель". Более того, в современной версии ограничение на число этих уровней снято, и этих уровней легко может быть более четырех.
Я думаю, что тут нужно использовать "образование будущего" (http://ailev.livejournal.com/722451.html):
1. отмоделировать (тут это слово используется как в НЛП, в смысле поиска "возникающих внутри головы и тела профессионала визуальных, аудиальных, кинестетических образов, позволяющих ему великолепно выполнять свою работу") то, как опытные программисты и системные архитекторы пользуются этими мета-модельными представлениями (тут слово "модель" используется как в MDA -- беда с этими "моделями", каждый раз приходится уточнять, что за "модель" имеется ввиду).
2. придумать методику по научению пользоваться этими образами (какие должны быть объясняющие создание требуемых образов метафоры, какие должны быть закрепляющие "ментальные алгоритмы" тренировочные упражнения, и т.д.). Сама эта методика должна быть "замаскирована", чтобы не вызывать ощущения ситуации явного "тренинга" -- клиенты ведь очень любят беседовать, но терпеть не могут "тренинга" кроме очень особых и редких специально оговариваемых случаев.