UML Class Diagram – How to Include Reference Data Type

class-diagramuml

For the following UML Class diagram, I have a reference data type Nurse, and I am using it in Hospital Class, is it needed all the time to describe the reference data types in UML Class diagram? Is this diagram created correctly? Also, is it needed for the methods that don't return anything to mention: void?

Best Answer

Assuming you mean 'reference data type' rather than an association to a data type which is realised in the implementation language as a reference, then

is it needed all the time to describe the reference data types in UML Class diagram?

The vast majority of software isn't described using UML, so no. If you find it is useful to describe something in UML or you believe whoever is reading your diagram will find it useful, include it.

Most UML classifiers are assumed to represent reference types, a stereotype is usually used if they are not.

Is this diagram created correctly?

Syntactically, yes. It shows a number of operations and properties of two types, and a composition association between Hospital (whole end) and Nurse (part end). Whether this matches the semantics of your problem domain is not something anyone can answer.

Also, is it needed for the methods that don't return anything to mention: void?

Partly this is a convention of the implementation language, and partly of your processes. If the return type is not specified, then your process might be to mark that as a missing detail in the model, and it might be that your team has the convention that it is treated as void. It depends how detailed you want your model to be whether this matters.

Related Solutions

UML Class Diagram – Resolving Common Confusions

An association links one class to another to indicate a relation between them. For example, you have an association between Customer and Order which (with no further information) indicates that:

A customer can have an order or maybe several orders,
An order can belong to a customer or maybe shared by several customers.

The diagram in your question gives an additional info: there is one and only one customer by order, and zero or more orders by customer, so the rules become:

A customer have zero or more orders,
An order belongs to one and one only customer.

While aggregation is used in the association between Order and OrderDetail, it's not used in the association between Customer and Order. This is done to indicate the life cycle dependency. If an instance of the Order is destroyed, all instances of OrderDetail inside it would be destroyed too; on the other hand, the instances of Order are independent of the life cycle of the Customer instance, thus no aggregation here.

This doesn't mean that an order can exist without a customer: the 1 ↔ 0..* association explicitly forbids the orders which have no customers. The difference between a 1 ↔ 0..* association and the aggregation really happens on life cycle level.

UML Class Diagram – Illustrating Attributes/Annotations

You could represent the annotation as a stereotype, and then apply the stereotype to the class.

    +----------------------+
    |   <<SuperSpecial>>   |
    |       MyClass        |
    +----------------------+

If your annotation has attributes, you can represent them as tagged values on the class. Tagged attributes have different syntax in UML 1.x and UML 2.x

In UML 1.x you put tagged values between {}, like this:

    +----------------------+
    |   <<SuperSpecial>>   |
    | {AllowMultiple=true} |
    |       MyClass        |
    +----------------------+

In UML 2.x you can use a section for the stereotype attributes:

    +----------------------+
    |   <<SuperSpecial>>   |
    |       MyClass        |
    +----------------------+
    | <<SuperSpecial>>     |
    | AllowMultiple=true   |
    +----------------------+

Best Answer

Related Solutions

UML Class Diagram – Resolving Common Confusions

UML Class Diagram – Illustrating Attributes/Annotations

Related Topic