Атрибуты класса ассоциации в диаграмме классов модели домена

Question

Привет, я недавно начал изучать системный анализ и проектирование, и у меня возникли проблемы с пониманием класса ассоциации диаграммы классов модели домена (DMCD).

Что касается изображения, то при рисовании DMCD я хотел бы понять, разрешено ли ассоциативному классу содержать атрибуты классов, из которых он получен. Счет должен содержать атрибуты apptNo и svcName.

Изображение запроса класса ассоциации:

Включены ли атрибуты, как показано на рисунке? Или я предполагаю, что Счет-фактура уже будет иметь эти атрибуты, потому что он получен из Назначения и Службы и что нет необходимости включать их, поскольку они могут быть отосланы обратно к ключам apptNo и svcID?

Я являюсьзапутался в концепции. Как мне представить ассоциативный класс? Может ли кто-нибудь дать какое-нибудь руководство?

Спасибо.

Answer 1

Как уже указывал Герт Беллекенс в своем комментарии выше, вы не повторяете никаких атрибутов классов, включенных в класс ассоциации в классе ассоциации. Вы включаете только атрибуты, которые конкретно характеризуют ссылки, классифицированные классом ассоциации.

В вашем примере вы должны включать только атрибуты, характерные для ссылок на счета-фактуры, такие как invNo, invDate и totalPrice.

Это правило действует независимо от видаДиаграмма классов (модель домена / дизайна / реализации).

Однако ваша модель подходит только для счетов, относящихся к одному собранию и одной услуге. Он не учитывает счета за одно посещение, независимо от того, сколько услуг он включает. В модели для этой бизнес-логики Invoice больше не будет классом ассоциации, а обычным классом, связанным с Appointment. Это позволит ему получить доступ к каждой услуге, включенной в встречу, и превратить ее в строку счета.

Answer 2

Для краткости:

является (вроде; читайте комментарии ниже) альтернативной нотацией для

, что означает, что Class3 уже имеет ассоциации с Class1 и Class2. Так что нет смысла добавлять атрибуты последнего в ассоциативный класс. Если вы работаете на уровне БД, вы в конечном итоге вводите избыточность по соображениям производительности за счет нарушения принципа единого источника правды. Но это другая история.

Answer 3

Это зависит.

A модель предметной области диаграмма классов моделирует понятия, найденные в домене, то есть часть реального мира, имеющую отношение к вашему проекту. В классы вы включаете только те атрибуты, которые указаны экспертами домена или другими источниками, описывающими домен.

Я предполагаю, что специалист по домену знает, что такое номер встречи и название услуги. Если это были просто технические данные, они не должны быть атрибутами Назначения и Обслуживания в первую очередь. Чтобы определить, должны ли эти атрибуты также быть включены в Счет-фактуру, вам нужно спросить экспертов домена, что они думают. Всегда ли счет-фактура содержит номер встречи и название услуги? Только если эксперт по домену скажет «Да», я бы смоделировал их как атрибуты счета-фактуры.

(Для двойной проверки вы могли бы спросить: «Можно ли также сказать, что номер встречи не является частью счета-фактуры»? , но что счет-фактура каким-то образом связан с назначением, имеющим определенный номер назначения? ")

Может быть, эксперт в области говорит, что счет-фактура не содержит номер назначения или название услуги, поскольку соответствующие назначение и обслуживаниевсегда ассоциируется с инвойсом в виде вложений, гиперссылок или иным образом. В этом случае достаточно того факта, что Счет-фактура является классом ассоциации для связи между Назначением и Услугой. Вам не нужно включать атрибуты этих классов в Invoice. Вероятно, они будут добавлены позже, когда диаграмма классов модели домена будет преобразована в диаграмму классов модели системы или диаграмму класса модели базы данных.