Что хотел сказать пока не забыл - UML без КОДОГЕНЕРАЦИИ - на мой взгляд - фикция. Модель и код - "завтра" же разбегутся и никогда вместе не соберутся. Идея применения UML именно в Model Driven Architecture - когда модель - ПЕРВИЧНА. А скелет кода - постоянно генерируется после изменения модели и наполняется мясом.
Если кодогенерации нет, то мне кажется тогда и UML - действительно не нужен.
Тогда - быстрее и проще рисовать проектные диаграммы на бумажке и складывать в папку. По-моему я уже говорил подобное.
Если кодогенерации нет, то мне кажется тогда и UML - действительно не нужен.
Тогда - быстрее и проще рисовать проектные диаграммы на бумажке и складывать в папку. По-моему я уже говорил подобное.
Проектные диаграммы тоже нуждаются в графической нотации. А иначе всё собьется на рисованные от руки бумажки с подтёками от шариковой ручки. Не всякая уважающая себя папочка не побрезгует хранить в себе мытые листки клетчатой бумаги (я тоже проходил).
ОтветитьУдалить>>Идея применения UML именно в Model Driven Architecture - когда модель - ПЕРВИЧНА.
А что же всё-таки первично? Иначе Model-Driven вообще будет означать некую идеализированную склонность просто отображать реальный мир на программный код. А должна ли модель исходить из требований? А если так, то модель уже не первична.
>>Что хотел сказать пока не забыл - UML без КОДОГЕНЕРАЦИИ - на мой взгляд - фикция.
Позволю себе параллель с реальным миром.
Есть чертёж. В идеале (model-driven) у нас есть станок с ЧПУ, а чертеж электронный. Два клика - деталь выпиливается электро-лобзиком с паровым приводом.
Но гигантский класс процессов производства все-таки использует бумажные чертежи без автоматической "детали-генерации". Не есть ли Ваша позиция слишком идеалистичной?
Вы правы. Я конечно же - ИДЕАЛИЗИРУЮ. Сознательно.
ОтветитьУдалитьЯ сам прекрасно понимаю области применимости. И про это я тоже когда-нибудь напишу.
Насчёт того "что первично". Как-то так - ПЗ -> ТЗ -> требования -> прецеденты -> детализированные требования (нефункциональные и граничные условия) -> модель -> код и тесты.
И ещё - я на модели стараюсь рисовать прецеденты (UseCase) и их детализацию (UseCaseRequariments). А от проектных классов ставлю связи РЕАЛИЗАЦИИ (пунктирной стрелочкой) к тем UseCase и их деталям, которые реализует ДАННЫЙ конкретный проектный класс. В итоге я очень быстро перемещаюсь на модели от требований к классам и обратно. И в итоге если я правлю требования, то я вижу какие классы это затрагивает, если я правлю классы, то вижу - на какие требования это может влиять.
В идеале я планирую из подобных связей автоматически генерировать тесты. Если есть связь класс <-> требование, значит - должен быть тест, который это проверяет.
До автоматизма я пока не дорос. Но планирую.
Пока из таких связей я вывожу тесты "руками".