Не существует общепринятой практики документирования, указывающей, что должно быть на диаграмме, а что нет. Более того
вы не ограничены одной диаграммой, которая показывает все это.
Для начала вам необходимо объяснить цель вашего приложения. Нарисуйте диаграмму прецедентов, чтобы сделать сводку целей пользователей, которые решаются.
Диаграмма классов предметной области всегда очень полезна. Он показывает сущности и то, как они связаны, а также доменные службы, которые не принадлежат ни к одному классу. Это позволяет читателю понять, о чем идет речь.
Дизайн вашего приложения со всеми контроллерами, службами приложений и объектами пользовательского интерфейса может оказаться излишним. Лучший подход — взять один пример, чтобы показать, как контроллеры, сервисы и один или два объекта связаны на диаграмме классов. Затем некоторый сценарий взаимодействия в виде диаграммы последовательности помогает понять динамику.
Наконец, вы можете использовать диаграмму компонентов, чтобы показать общую картину вашей системы. Чтобы показать общую архитектуру, не теряясь во многих деталях базовых классов.
Однако лучше всего запросить подтверждение у вашего клиента/учителя.
Лучше всего спросить у учителя, чего он ожидает. Это то, на что незнакомцы в Интернете действительно не смогут вам ответить.
сначала, может быть, лучше знать, какую UML-диаграмму вы хотели нарисовать? (структура или тип поведения?). Угадай
class diagram
, так что просто посмотри, каковы требования к тому или иному типу. Диаграммы UML стандартизированы, но также лучше уточнить у инструктора, какие детали должны быть заполнены (в основном должны присутствовать все классы, но необходимо добавить все методы? и т.д.)Короче говоря: то, что вы считаете полезным для передачи дизайна. Но, см. комментарии выше.