Хорошей новостью является то, что 1) вы можете использовать UML для разных целей и 2) UML всегда является UML:
Анализ имеет целью понять проблему и требования . Модель анализа делает акцент на бизнес-сфере без ущерба тому, как могут выглядеть внутренние компоненты решения. Так что если вы думаете о MVC, эта модель будет ориентирована только на М.
Дизайн имеет целью придумать решение , подходящее для решения проблемы и выполнения требований. Красота MVC появится в проектной модели, поскольку MVC является частью решения, а не (функциональных) требований.
Где заканчивается модель анализа и начинается модель проектирования, зависит от методологической основы:
- Очень часто в анализе вы найдете только доменные объекты , Проект обогатил бы модель анализа дополнительными классами о внутренностях.
- В книге " Унифицированный процесс разработки программного обеспечения " отцы UML объясняют, как они думают, что его можно использовать в итеративном подходе, основанном на сценариях использования. Затем в модели анализа есть несколько классов, которые представляют варианты использования (с Entity-Contol-Boundary )
- Скотт Амблер Agile UP переименовал модель анализа в модель требований. Для него модель проекта должна быть эскизом общего решения с достаточным количеством деталей, чтобы понять, как оно работает, но не слишком, потому что дизайн может развиваться. Я полностью поддерживаю эту точку зрения.
Наконец, стоит упомянуть, что некоторые рассматривают модель анализа как временную модель, которая будет обогащена, чтобы стать моделью проекта. Другие видят их как две разные модели. Поддерживать его или нет - это еще один методологический вопрос, который необходимо прояснить в проекте.