понедельник, 15 апреля 2013 г.

Маленькая ремарка про UML

Что хотел сказать пока не забыл - UML без КОДОГЕНЕРАЦИИ - на мой взгляд - фикция. Модель и код - "завтра" же разбегутся и никогда вместе не соберутся. Идея применения UML именно в Model Driven Architecture - когда модель - ПЕРВИЧНА. А скелет кода - постоянно генерируется после изменения модели и наполняется мясом.

Если кодогенерации нет, то мне кажется тогда и UML - действительно не нужен.

Тогда - быстрее и проще рисовать проектные диаграммы на бумажке и складывать в папку. По-моему я уже говорил подобное.

2 комментария:

  1. Проектные диаграммы тоже нуждаются в графической нотации. А иначе всё собьется на рисованные от руки бумажки с подтёками от шариковой ручки. Не всякая уважающая себя папочка не побрезгует хранить в себе мытые листки клетчатой бумаги (я тоже проходил).

    >>Идея применения UML именно в Model Driven Architecture - когда модель - ПЕРВИЧНА.
    А что же всё-таки первично? Иначе Model-Driven вообще будет означать некую идеализированную склонность просто отображать реальный мир на программный код. А должна ли модель исходить из требований? А если так, то модель уже не первична.

    >>Что хотел сказать пока не забыл - UML без КОДОГЕНЕРАЦИИ - на мой взгляд - фикция.
    Позволю себе параллель с реальным миром.

    Есть чертёж. В идеале (model-driven) у нас есть станок с ЧПУ, а чертеж электронный. Два клика - деталь выпиливается электро-лобзиком с паровым приводом.

    Но гигантский класс процессов производства все-таки использует бумажные чертежи без автоматической "детали-генерации". Не есть ли Ваша позиция слишком идеалистичной?

    ОтветитьУдалить
  2. Вы правы. Я конечно же - ИДЕАЛИЗИРУЮ. Сознательно.

    Я сам прекрасно понимаю области применимости. И про это я тоже когда-нибудь напишу.

    Насчёт того "что первично". Как-то так - ПЗ -> ТЗ -> требования -> прецеденты -> детализированные требования (нефункциональные и граничные условия) -> модель -> код и тесты.

    И ещё - я на модели стараюсь рисовать прецеденты (UseCase) и их детализацию (UseCaseRequariments). А от проектных классов ставлю связи РЕАЛИЗАЦИИ (пунктирной стрелочкой) к тем UseCase и их деталям, которые реализует ДАННЫЙ конкретный проектный класс. В итоге я очень быстро перемещаюсь на модели от требований к классам и обратно. И в итоге если я правлю требования, то я вижу какие классы это затрагивает, если я правлю классы, то вижу - на какие требования это может влиять.

    В идеале я планирую из подобных связей автоматически генерировать тесты. Если есть связь класс <-> требование, значит - должен быть тест, который это проверяет.

    До автоматизма я пока не дорос. Но планирую.

    Пока из таких связей я вывожу тесты "руками".

    ОтветитьУдалить