Unified Modelling Language


In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among objects.

Contents

1)    Members
a)    Visibility
b)    Scopes
2)    Relationships
a)    Instance level relationships
i)     Links
ii)    Association
iii)   Aggregation
iv)   Composition
v)    Differences between composition and aggregation
b)    Class level relationships
i)     Generalization
ii)    Realization
c)    General relationship
i)     Dependency
d)    Multiplicity


Class Diagram

The class diagram is the main building block of object oriented modelling.

In the diagram, classes are represented with boxes which contain three parts:
·         The top part contains the name of the class. It is printed in bold and centred, and the first letter is capitalized.
·         The middle part contains the attributes of the class. They are left-aligned and the first letter is lowercase.
·         The bottom part contains the methods the class can execute. They are also left-aligned and the first letter is lowercase.


Members


Visibility

To specify the visibility of a class member (i.e., any attribute or method), these notations must be placed before the member's name.

+
Public
-
Private
#
Protected
/
Derived
~
Package

Scopes

The UML specifies two types of scope for members: instance and classifier.
·         Classifier members are commonly recognized as “static” in many programming languages. The scope is the class itself.
·         Attribute values are equal for all instances
·         Method invocation does not affect the instance’s state
·         Instance members are scoped to a specific instance.
·         Attribute values may vary between instances
·         Method invocation may affect the instance’s state (i.e., change instance’s attributes)

Relationships

1) Instance level relationships


a) Links


A Link is the basic relationship among objects

b) Association


An association represents a family of links. A binary association (with two ends) is normally represented as a line. An association can link any number of classes. An association with three links is called a ternary association. There are four different types of association: bi-directional, uni-directional, Aggregation (includes Composition aggregation) and Reflexive.  Association represents the static relationship shared among the objects of two classes.


Class diagram example of association between two classes

c) Aggregation


Aggregation is a variant of the "has a" association relationship; aggregation is more specific than association. It is an association that represents a part-whole or part-of relationship.
Aggregation can occur when a class is a collection or container of other classes, but the contained classes do not have a strong lifecycle dependency on the container. The contents of the container are not automatically destroyed when the container is.
In UML, it is graphically represented as a hollow diamond shape on the containing class with a single line that connects it to the contained class.


Class diagram showing Aggregation between two classes

d) Composition


Composition is a stronger variant of the "has a" association relationship; composition is more specific than aggregation. Composition usually has a strong lifecycle dependency between instances of the container class and instances of the contained class(es): if the container is destroyed, normally every instance that it contains is destroyed as well. 
The UML graphical representation of a composition relationship is a filled diamond shape on the containing class end of the tree of lines that connect contained class(es) to the containing class.



Class diagram showing Composition between two classes at top and Aggregation between two classes at bottom

 

Differences between composition and aggregation

Composition relationship: When attempting to represent real-world whole-part relationships, e.g., an engine is a part of a car.
Aggregation relationship: When representing a software or database relationship, e.g., car model engine ENG01 is part of a car model CM01, as the engine, ENG01 may be also part of a different car model.

2) Class level relationships

 

a) Generalization


The Generalization relationship ("is a") indicates that one of the two related classes (the subclass) is considered to be a specialized form of the other (the super type) and the superclass is considered a 'Generalization' of the subclass.
The UML graphical representation of a Generalization is a hollow triangle shape on the superclass end of the line (or tree of lines) that connects it to one or more subtypes.
The generalization relationship is also known as the inheritance or "is a" relationship.
The superclass (base class) in the generalization relationship is also known as the "parent", superclass, base class, or base type.
The subtype in the specialization relationship is also known as the "child", subclass, derived class, derived type, inheriting class, or inheriting type.


Class diagram showing generalization between one superclass and two subclasses

b) Realization


In UML modelling, a realization relationship is a relationship between two model elements, in which one model element (the client) realizes (implements or executes) the behaviour that the other model element (the supplier) specifies.



The UML graphical representation of a Realization is a hollow triangle shape on the interface end of the dashed line (or tree of lines) that connects it to one or more implementers.
A realization is a relationship between classes, interfaces, components, and packages that connects a client element with a supplier element. A realization relationship between classes and interfaces and between components and interfaces shows that the class realizes the operations offered by the interface.

3) General relationship

 

a) Dependency


Dependency is a weaker form of bond which indicates that one class depends on another because it uses it at some point in time. One class depends on another if the independent class is a parameter variable or local variable of a method of the dependent class. This is different from an association, where an attribute of the dependent class is an instance of the independent class. Sometimes the relationship between two classes is very weak. They are not implemented with member variables at all. Rather they might be implemented as member function arguments.

Class diagram showing dependency between "Car" class and "Wheel" class (An even clearer example would be "Car depends on Wheel", because Car already aggregates (and not just uses) Wheel)

b) Multiplicity


This association relationship indicates that (at least) one of the two related classes make reference to the other. This relationship is usually described as "A has a B" (a mother cat has kittens, kittens have a mother cat).
The UML representation of an association is a line with an optional arrowhead indicating the role of the object(s) in the relationship, and an optional notation at each end indicating the multiplicity of instances of that entity (the number of objects that participate in the association).

0..1
No instances, or one instance
1
Exactly one instance
0..*
Zero or more instances
1..*
One or more instances


No comments :

Post a Comment

Comment Here