I'm having quite a difficulty with what i think would suit a Patient class and a Record class in UML

Basically the Record class stores the patient's information such as name, vitals, gender, age and etc.

However, when linking these two classes together, I'm very much confused as to which relationship would be suitable for these.

Currently, I'm creating a composite relationship between the two,

enter image description here

Based on the way i interpret it, a patient record wouldn't exist without it's patient. However, in most examples i researched online, composition relationship is represented in an example as such:

enter image description here

I'm starting to wonder, would my interpretation of Patient and Record having a composite relationship is acceptable?

  • need more info. can you give examples of patient and record?
    – Ewan
    Mar 25, 2019 at 13:31
  • What would you like to express? Patient appears in/has Records. Records are related to only one Person? What does your domain language say about the relationship?
    – Laiv
    Mar 25, 2019 at 14:29
  • 1
    It seems to me that you have here a huge misunderstanding. Why do you want to have Record class if the information it is supposed to hold are apparently attributes of Patient. Why don't you want to store that information simply in Patient?
    – Ister
    Mar 25, 2019 at 20:27
  • Refer the following site.May this help you:creately.com/blog/diagrams/class-diagram-relationships & creately.com/blog/diagrams/…
    – AjayGohil
    Dec 21, 2020 at 4:13

2 Answers 2


Making a clear distinction between composition and aggregation is not terribly relevant in most contexts. I haven't used composition notation since I passed my software engineering class.

UML diagrams are just models: simplified views of a design. If noting the composition is irrelevant for a specific viewpoint, it should be left out. You can just use some generic association instead, i.e. a normal line.

Composition does become relevant when …

  • your model needs to discuss ownership or lifetime of objects, for example if you want to model the ownership relationships in a C++ system where clear ownership is necessary to avoid memory leaks.
  • you are using UML notation for an Entity-Relationship diagram, where you might use composition notation to denote a weak entity.

In the ER diagram sense, a record presumably can't exist without a patient. It could then be fine to notate composition here.

However, your actual software might handle records independently from patients. In particular, the object lifetimes might not be linked. Using composition to denote lifetime/ownership might be overspecified in this case.

  • 1
    I find that it's often useful to distinguish between composition and aggregation when reverse-engineering or debugging. This includes reverse-engineering my own code. The UML notation comes handy sometimes. Well after the hype about UML had deflated, Martin Fowler wrote short practical application notes UmlAsSketch, UmlAsNotes, UnwantedModelingLanguage. Mar 25, 2019 at 14:57

Having a composite associations between 1 or more classes means that they live together and die together. The fact that most composition diagrams you have found have more than 1 class is because in real life it is common to have a thing built from" several "parts" and not only one. However, it is valid to separate classes and enforce composition when you want to build other associations specific to each class. For example, in your case, you may want the patient record to be associated with a class such as TestResult. It is not very good to associate it to a Person class. Also separation of components allows easier handling of security and has an effect on designing responsibilities associated with each class.

The life cycle may be an issue in composition in some cases. Suppose the institution would destroy patient records after 10 years. In this case, composition usage is wrong.

The problem of using composition is that it is not always evident in the early days of design that classes are tightly coupled.

In short what you have is correct under certain assumptions: 1-The properties are set properly for each class 2-Lifetime of both classes is exactly the same (creation and death).

  • 1
    in the description, it says that a record would consist of name, vitals, lab data, gender, age and etc. However, since its a conceptual diagram for an application, the vitals and lab data of the patient will be shown to the patient through the app. In this case, would it still be feasible to create a class such as Vitals/Lab Results and link to Patient Record instead?
    – Maxxx
    Mar 25, 2019 at 13:51
  • @Maxxx, thanks for pointing out that the vitals are stored in the patient record, which is probably not correct. It would be correct only if the physician only cares about the "current" values which is almost never the case except maybe in an ambulance case. I don't think that in areal world application vitals should be stored this way because they are collected in a patient-medical_person encounter (visit). The visit is almost always of interest.
    – NoChance
    Mar 25, 2019 at 14:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.