问题
Hi, I have recently started to learn system analysis and design and am having some trouble understanding domain model class diagram (DMCD) association class.
As per image, when drawing the DMCD, I'd like to understand if an association class is allowed to contain attributes of the classes it derives from. The Invoice needs to contain the attributes apptNo and svcName.
Association class inquiry image:
Do I include the attributes as shown in the image? Or do I assume that the Invoice would already have these attributes because it is derived from Appointment and Service and that it is not necessary to include them as they can be referred back to the keys apptNo and svcID?
I am confused about the concept. How should I present the association class? Can someone please provide some guidance?
Thank you.
回答1:
As already pointed out by Geert Bellekens in his comment above, you don't repeat any of the attributes of the classes involved in an association class in the association class. You only include attributes that specifically characterize the links classified by the association class.
In your example, you should only include attributes that are specific for Invoice links, such as invNo, invDate and totalPrice.
This rule holds independently of the kind of class diagram (domain/design/implementation model).
However, your model is only good for invoices refering to one appointment and one service. It does not account for invoices concerning one appointment, no matter how many services it includes. In a model for this business logic, Invoice would no longer be an association class, but an ordinary class associated with Appointment. This would allow it to access each service included in an appointment and turn it into an invoice line.
回答2:
It depends.
A domain model class diagram models the concepts found in the domain, i.e. the part of the real world relevant for your project. In the classes, you only include attributes that are indicated by domain experts or by other sources describing the domain.
I will assume that a domain expert knows what an appointment number and a service name are. If these were just technical data, they should not be attributes of Appointment and Service in the first place. To determine whether these attributes should also be included in Invoice, you need to ask domain experts what they think. Does an invoice always include an appointment number and a service name? Only if the domain expert says "Yes", I would model them as attributes of Invoice.
(To double check, you could ask "Is it also valid to say that the appointment number is not part of the invoice, but that the invoice is somehow associated with an appointment having a particular appointment number?")
Maybe the domain expert says an invoice does not contain the appointment number or the service name, because the corresponding Appointment and Service are always associated to the Invoice as attachments or hyperlinks or otherwise. In that case, the fact that Invoice is an association class on the association between Appointment and Service is enough. You don't have to include attributes of these classes in Invoice. These will probably be added later, when the domain model class diagram is turned into a system model class diagram or database model class diagram.
回答3:
To make it short:
is (sort of; please read the comments below) an alternative notation for
which means that Class3 already has associations to both Class1 and Class2. So there's no point in adding attributes of the latter in the association class. If you're on a DB level you eventually introduce redundancy for performance reason at the cost of violating the principle of single source of truth. But that's another story.
来源：https://stackoverflow.com/questions/58295799/association-class-attributes-in-domain-model-class-diagram