- classes
- interfaces
- data types (structs, enums, etc.)
- components
Class diagram manifests the static aspect of a system, or a domain conceptually.
Notation of an element
A Class is represented by:
- name
- attributes (optional)
- operations (optional)
the format of defining an attribute is:
visibility attributeName:type=defaultValue{isNullable}
the format of defining an operation is:
visibility operationName(parameterList):returnType
Each parameter is defined as:
direction parameterType
where direction = {in|out}
visibility = {+|-|#|~}
respectively indicates public, private, protected, package.
static attributes and operations are indicated with an underline.
An abstract class is indicated by italicizedclass name
An interface is indicated with <
The Relationship
The relationhsip demonstrated in a class diagram aims to discover and express the structural aspect of collabrations, as opposed to behaviourial aspect.
some relationships are stated differently in different books. generally the relationships can be categorized into three kinds:
- Generalization
- Association
- Others
Generalization includes extention and implementation(some books called realization). The former refers to that a class extends from another class (including abstract class), the latter refers to a class implements an interface.
figure 2: implementation and extention
Association Relationship
Association relationship represents that two or more elements conceptually associate with each other. for example, a person owns a car, a car has an engine, a student registers in courses and so forth. [3] discriminates association relationships into five types:
- uni-directional
- bi-directional
- reflexive
- aggregation
- composition
In a class diagram, uni-directional association is represented by a solid line with an arrow head indicating the direction, bi-directional association uses a solid line. based on [3], reflexive association uses a solid line. I would like add anarrow head so that it is easier to read the association with role information.
aggregation uses a solid line with an unfilled diamond, while composition uses a solid line with filled diamond.
figure x shows the notations of above five associations
Obviously, multiplicity gives the possible number of instances that could be associated, while roles clarifies the association in terms of real world.
Worth to notice, to determine which type of association to use is totally based on conceptual context of the domain, not relies on code implementation. For example, both aggregation and composition can be implemented with an collection attribute in the whole class, the only difference is that the elements in the collection of a composition whole has no other classes reference to them, while for aggregation, it is not guaranteed.
Others category includes dependency. If a class uses another class in its implementation or as a parameter, this sort of relationship neither belongs to generalization nor belongs to association, it is called dependency relationship. The notation for it is a dash-line and an arrow head indicating the direction.
figure 3:
References:
[1] Information System Analysis and Design, University of Toronto, lecture of CSC340
[2] UML basics: The class diagram, IBM website.
