Что именно должно быть представлено на диаграмме классов

Question

Я пишу свой проект Bsc IT конца года и смущен тем, что именно должно быть представлено на диаграмме классов и что на самом деле не нужно.

В моем случае я использую spring with MVC+hibernate. Я представлял только свои классы сущностей с их отношениями между собой. Теперь я хотел бы создать диаграмму активности, и я понял, что могут быть задействованы классы MVC controller, которые я не включил в свой class diagram.

Второго вопрос: Между activity, sequence и data flowdiagrams который один лучше, чтобы document a flow of process (не данные, необходимым). Предположим, что я хотел бы документировать, как authentication работы (в доливают signup, verification и login)

Спасибо очень

Answer 1

UML является инструментом коммуникации. Ваша цель - сделать ваши намерения понятными для других разработчиков. Сколько деталей требуется, чтобы все понять, зависит от того, что вы хотите общаться.

Если вы рассматриваете UML как инженерные чертежи, вам может понадобиться каждый класс, каждая подпись метода, каждый вызов. Вы можете взять такое, бросьте его на стол разработчика и попросите их составить свое видение. Я бы сказал, что это редко бывает. Это такая же работа, как и запись кода, но это невозможно проверить.

Я думаю, что более реалистично включать классы и их взаимодействия на достаточно простом уровне, чтобы показать намерение высокого уровня. Пусть разработчики заполняют остальные детали.

Answer 2

Диаграммы классов показывают взаимосвязь между классами, а для каждого класса - важные переменные-члены и функции. Таким образом, они показывают роли и обязанности, позволяя дизайнерам определять, какие программные модули должны содержать какую функциональность. При использовании наследования они очень полезны для отображения иерархии, которая занимает гораздо больше времени, чтобы различаться при просмотре кода. Для атрибутов и методов укажите количество деталей, необходимых для вашей аудитории.

Мне нравятся диаграммы последовательности, когда есть несколько взаимодействующих классов/компонентов, которые достигают цели. Каждая последовательность показывает один и только один сценарий и поэтому имеет предварительное условие, одну последовательность потока (например, не представляет решений) и пост-условие. Диаграммы операций лучше для отображения последовательных алгоритмов с решениями, обработкой ошибок и т. Д. Я также использую несколько действий на одной диаграмме, если есть точки сотрудничества и синхронизации.