Как я могу определить атрибуты и операции, на которые должен отвечать класс на диаграмме классов проектирования?

Question

Я пытаюсь создать дизайн диаграмму классов, основываясь на прецеденте ниже:

Предусловия: Пользователь регистрируется в

1. Система представляет список расходов претензий, которые были разрешены для оплаты.
2. Пользователь выбирает требование о расходах из списка.
3. Система показывает все предметы, записанные под ней.
4. Пользователь выбирает один из двух вариантов: (a) для подтверждения иска для платежа или (b) для пересмотра .
5. IF вариант (а) выбран ТОГДА

5.1 Система регистрирует подтверждение оплаты и уведомляет счета отдел.

ELSE 5,2 DO ПРОДЛИТЕ Обзор Claim

END IF

Как определить, какой класс (между учетной системой) несет ответственность за какие атрибуты и операции? Принимаю ли я решение на основе моей собственной интерпретации или существует установленный метод?

Это то, что я до сих пор: design class diagram

Answer 1

Разработка диаграммы классов, как правило, то, что открыто для интерпретации человека, делающего его. Не уверен в других способах этого, но именно так я обычно подхожу к этой проблеме:

1. Определить типы объектов (то есть классов), которые существуют в рамках сценария. Это отдельные элементы, которые существуют в вашем сценарии (например, User, ExpenseClaim, ExpenseItem). Хорошей практикой для их идентификации являются элементы, которые обычно имеют кусочки данных (то есть свойства) или выполняют функцию (то есть методы). В общем, вы можете ошибаться на стороне выявления как можно большего количества вещей, поскольку идея состоит в том, что каждый класс должен делать определенную вещь и не более того (вы, вероятно, пересмотрите это при выполнении последующих шагов) , Однако не путайте объекты с актерами - система на самом деле то, что объясняет диаграмма всего класса, поэтому ее никогда не следует рассматривать как класс.
2. Для каждого типа объектов посмотрите на данные, которые они содержат, и переведите их в свойства или отношения к другим типам объектов. На самом деле попытайтесь ограничить объем данных, которые есть у каждого объекта; если у одного объекта много свойств, возможно, он созрел для разделения его на несколько объектов. На примере ExpenseClaim и ExpenseItem ясно, что каждый ExpenseClaim имеет список ExpenseItem, поэтому вы можете связать их со стрелкой состава.
3. Теперь проследите за каждым и подумайте о том, что другие объекты могут попробовать и сделать, чтобы изменить данные, которые есть у объекта - это, вероятно, ваши методы. Для объекта ExpenseClaim он, вероятно, будет иметь метод confirm() для изменения состояния свойства isConfirmed :: boolean. Опять же, действительно попытайтесь ограничить объем функциональности определенной ролью, которую играет объект - если у объекта слишком много функций или функция, которая на самом деле не подходит, это, вероятно, означает, что есть другой (новый) объект, который будет лучше подойдет.