Обычно ваша методология моделирования документации / дизайна определяется планом или процессом разработки программного обеспечения вашей компании. Если у вашей компании его нет, вам, возможно, будет полезно сначала определить процесс разработки документации, независимо от того, что лучше всего подходит для Prism, особенно если у вас есть приложения, которые были разработаны и не зависят от Prism. По моему опыту, Prism сама по себе не всегда подходит лучше или хуже для любого подхода к моделированию.
Кроме этого, и, в частности, в отношении UML, модули Prism обычно можно легко логически разделить на пакеты или варианты использования. Вы на самом деле уже сделали это, когда сначала разбили свое приложение на модули: каждый модуль является слабосвязанной, достаточно независимой частью вашего приложения.
Например, модули, относящиеся к пользовательскому интерфейсу, часто можно сгруппировать как в зависимости от варианта использования, так и в виде отдельных пакетов. Возьмем, к примеру, StockTraderRI : модули «Новости», «Позиция» и «Наблюдение» достаточно легко подразделяются на отдельные варианты использования (просмотр новостей, просмотр позиции, добавление акций к просмотру и т. Д.) легко как отдельные пакеты, в комплекте со статическими диаграммами классов.
В случае модулей бизнес-уровня или уровня данных, таких как инфраструктурные или сервис-ориентированные модули, представление может быть почти исключительно в виде диаграмм пакетов / классов, причем некоторые диаграммы вариантов использования (последовательность и т. Д.) Используются для иллюстрации связи, исходящей от Интерфейс к сервисам. Опять же, с приложением StockTraderRI модуль Market и DLL инфраструктуры, похоже, поддаются более статичному подходу.
Опять же, ваш подход к документированию и моделированию вашего приложения не должен диктоваться Prism, поскольку любой хороший язык моделирования сможет приспособить Prism.