0

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: Association class inquiry

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.

Jee Mok
  • 6,157
  • 8
  • 47
  • 80
Jin Yu Chan
  • 19
  • 1
  • 6
  • 2
    No, there's no need to duplicate the id fields in the association class. You are making a UML class diagram, not a database diagram. – Geert Bellekens Oct 09 '19 at 03:37
  • Thank you for the explanation sir. Does this also apply onto any non-key attributes (svcName) from the classes in relation to producing the association class? Should they also not be inside the association class? – Jin Yu Chan Oct 09 '19 at 12:09
  • Maybe you should think about that. Where would you put something like the invoice number? – Geert Bellekens Oct 09 '19 at 12:21
  • Hmmm... I would leave invoice number in the class Invoice as it is but it will no longer be an association class. Instead, I would create an association class called appointmentService from Appointment and Service and link it to Invoice on the assumption that one invoice can have many appointment services but one appointmentService must belong to one invoice. I am not sure if that is how it should be done, please advise. Thanks. – Jin Yu Chan Oct 09 '19 at 12:42
  • I can't comment on the multiplicities, but the current model, with the association class might make sense, if indeed an invoice will always (and only) exists on each link between Service and Appointment. – Geert Bellekens Oct 09 '19 at 12:54
  • Am grateful for the replies. I am trying to create a model where the invoice shows the list of service(s) provided in an appointment aside from the invoice number, date and total amount but I am not sure how to deal with a many to many relationship in a DMCD. Is there an appropriate way in handling this problem? – Jin Yu Chan Oct 09 '19 at 13:11
  • 1
    Seems like you might want to make invoice a normal class, and create an link between invoice and Appointment. From appointment you can then navigate further to Service, so no need to make a direct link. If there is only one invoice per appointment that could be a good model. – Geert Bellekens Oct 09 '19 at 13:19
  • Thanks again for the guidance. I will take notes from this example and reexamine the approach when creating a DMCD. – Jin Yu Chan Oct 09 '19 at 13:26
  • Suppose you have 6 service instances. Suppose the services s1, s2 and s3 have svcName=X and the services s4, s5 and s6 have svcName=Y. Suppose we have an appointment associated with s1, s2 and s6. How many invoices would you need for this appointment? Just one? Or one invoice for X and one invoice for Y? – www.admiraalit.nl Oct 09 '19 at 14:21
  • @www.admiraalit.nl I'd like one invoice for s1, s2 and s6 as it relates to only one appointment. How can I better understand the approach when constructing the DMCD? – Jin Yu Chan Oct 10 '19 at 15:31
  • In that case, the association class is not appropriate, because then, you get three invoices for that appointment in my example. Follow @GeertBellekens' latest advice. – www.admiraalit.nl Oct 10 '19 at 20:12
  • @www.admiraalit.nl Understood, appreciate the guidance. – Jin Yu Chan Oct 11 '19 at 12:53

3 Answers3

2

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.

Gerd Wagner
  • 5,481
  • 1
  • 22
  • 41
  • Thank you for the kind explanation. This also applies to non-key attributes as well? – Jin Yu Chan Oct 09 '19 at 12:11
  • Yes, it is implicit that an instance of an association class is also a "link", or relationship, which means it has references to both objects participating in the link, which in turn means it has access to all of their properties/attributes. Therefore, it does not make sense to repeat them. – Gerd Wagner Oct 09 '19 at 14:19
  • Hi sir, if I were to interpret your explanation, it would mean that even if service name is required to be shown in the class Invoice but because Invoice can access the attribute service name through the class Service, there is no need to include service name as an attribute in Invoice? – Jin Yu Chan Oct 10 '19 at 15:49
  • Yes, in your example, you should only include attributes that are specific for Invoice links, such as invNo, invDate and totalPrice. But I'll add some advice about modeling invoices that concern one appointment and several services. – Gerd Wagner Oct 10 '19 at 20:16
  • Thanks for the advice. I have a much clearer picture now. – Jin Yu Chan Oct 11 '19 at 12:55
1

To make it short:

enter image description here

is (sort of; please read the comments below) an alternative notation for

enter image description here

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.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • Hi, thanks for answering. I understand that in database design non-key attributes related to the original entities are also not added into the associative entity as they can be referred back using the foreign keys which is incidentally the primary of the original entities. In SQL, that would mean a join on FK and then partitioning to the desired view. What I'd like to know is if that rule also applies in DMCD to non-key attributes of the association class which can be found in the original class? – Jin Yu Chan Oct 09 '19 at 12:27
  • Your answer is clear. Just a minor remark: The second diagram is not exactly a shorthand for the first diagram. In the first diagram, every instance of Class3 represents a unique combination of an instance of Class1 and an instance of Class2. In the second diagram, there may be multiple instances of Class3 associated with the same pair of instances of Class1 and Class2. – www.admiraalit.nl Oct 09 '19 at 13:07
  • @qwerty_so: The two patterns of your diagram are NOT equivalent in general, but only in the special case where `Class3` represents a relationship type and where you either (1) add a uniqueness constraint to the combination of links in the lower diagram or (2) add `non-unique` annotations to both association ends in your upper diagram. Remember: meaning matters! – Gerd Wagner Oct 09 '19 at 14:38
  • @www.admiraalit.nl Thanks, I'll update my answer to make it more clear. I made that on the fly (as so often). – qwerty_so Oct 09 '19 at 18:01
  • @GerdWagner Indeed. Where did I hear that before? See my comment above. – qwerty_so Oct 09 '19 at 18:02
  • @JinYuChan see www.admiraal.nl's answer about "it depends". Anyhow, you should make a cut between class and DB design. A DB design is very specific and refers more context (and NFR like those for performance) than a class design. – qwerty_so Oct 09 '19 at 18:03
  • @qwerty_so Thank you for the advice, will keep in mind to treat DB design and DMCD independently. – Jin Yu Chan Oct 10 '19 at 15:35
0

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.

www.admiraalit.nl
  • 5,768
  • 1
  • 17
  • 32
  • Thank you for explaining sir. If it is mandatory to have the attribute svcName in the association class Invoice, does that mean I have to include it in Invoice even though it is a non-key attribute of the class Service? – Jin Yu Chan Oct 09 '19 at 12:34
  • Yes, the difference between keys and non-keys is not important. In my answer, I will replace "service ID" with "service name". – www.admiraalit.nl Oct 09 '19 at 13:02
  • Thank you for the advice sir. I will keep that in mind when I look at requirements in future. – Jin Yu Chan Oct 09 '19 at 13:23