A class is a representation of an object. A class diagram depicts the attributes and operations of each class and the relationship between classes. Class diagrams are used for data modeling.
Within a class diagram, the class is represented by a box containing three parts. The first part shows the class name. The second part lists the attributes of the class and their data type, size, visibility, scope and default value (if any). The third part lists the methods or operations that can be invoked on objects of that class. The method signature indicates the number and type of input arguments / parameters for the method and the resultant object returned by the method (if any).
Example:
Class Name: Employee
Attributes:
- Name: String
- Employee ID: Number
- Salary: Number
- Designation: String
- Date of Joining: Date
- isEligibleForPremiumInsurance: Boolean = True
The description after the “:” indicates the data type of the attribute. The value specified after the “=” sign, is the default value for the attribute when an instance of the class object is created.
Methods:
- getEmployeeName(): String
This method takes no input parameters, but it returns one output parameter of data type String.
- getEmplyeeID() : Number
- getSalary(): Number
- getDesignation(): String
- getDOJ(): Date
- setEmployeeName(String):
- setEmplyeeID(Number)
- setSalary(Number)
- setDesignation(String)
This method takes one input parameter of data type string and does not return any output parameter.
- setDOJ(Date)
Visibility
The visibility of a Class attribute or method is depicted by using the notations “+” for Public, “-” for Private, “#” for Protected and “~” for Package.
+ Public
The attribute/ operation can be accessed by external classes.
Example
“+Name: String” indicates that the attribute “Name” is a public member of the class and it is of data type String.
– Private
The attribute/ operation can be accessed only from within the same class.
# Protected
The attribute/ operation can be accessed from within the class and by all classes derived from that class.
~ Package
The attribute/ operation can be accessed only from within the package that contains the class
Static attributes and operations are underlined to indicate that they are associated with the class itself rather than with an instance and they are shared by all instances of that class object.
Abstract Classes are depicted by showing the class name and abstract method names in italics.
Constraint is used to express a condition or restriction applicable to an attribute or a class. On the class diagram, it is shown in curly braces next to the attribute name or next to the class name as applicable. For example, +accountBalance: String{accountBalance >=0} indicates that the attribute cannot take negative values. To represent a constraint that applies to more than one class, draw a dashed line joining the classes and place the constraint in curly braces as the label of the dashed line. A constraint may also be shown as a note and attached to the element to which it applies.
Standard Stereotypes for Classes
A Stereotype is used to provide additional information regarding a class or a relationship. The stereotype is specified just above the Class Name in the Class Diagram.
<<Focus>> is used to depict classes that form the core controlling business logic of the system.
<<Auxiliary>> is used to depict classes that support Focus classes. They usually describe the secondary business logic or flow of control in the system.
<<Type>> is used to depict classes that describes the domain of objects and their operations, but does not define the implementation of objects.
<<ImplementationClass>> is used to depict an implementation. Every run time instance has a specific implementation.
<<Utility>> is used to depict classes that define the common library functions used across the application. The scope of Utility classes is static and no instances are created.
Multiplicity
The multiplicity of a class on a class diagram shows the number of instances that can be created for that class’ object.
0..1 – No instances or one instance (zero or one)
1 – One and only one instance (exactly one)
0..* or * – No instances or one or many instances (zero or more)
1..* – At least one instance (one or more)
When multiplicity is specified for an attribute, it is shown in square brackets next to the attribute. It is used to depict those attributes that are collections (collection of values such as an array) rather than single values. For example, say we have 2 classes namely “Player” and “CricketTeam”. The attribute in the “CricketTeam” class, +numberOfWicketKeepers: Player [1] means that there can only be one wicket keeper Player in an instance of the “CricketTeam” class.
+numberOfBowlers: Player [4..5] means that there can be 4 to 5 bowler Players in an instance of the “CricketTeam” class.
The multiplicity of an attribute can further be described as {ordered} and / or {unique}. {Ordered} implies that collection of values for that attribute (in an instantiation of the class) is sequentially ordered. {Unique} means that the same value cannot be repeated in the collection of values for that attribute in an instance of the class.
Relationships between Classes
Relationships between classes are represented in UML as links or lines connecting the classes. Relationships between classes may be categorized as generalization and realization. Relationships may be uni-directional or bi-directional. Relationships are depicted as dashed or solid lines connecting the classes with arrow heads pointing to the classes. The type of line and the direction of the arrow head depend upon the type of relationship. The multiplicity (or the number of instances of the object that participate in the relationship) is depicted at the ends of the relationship lines.
Generalization
As an example, consider the relationship between the classes Mammal and Animal. A mammal is an Animal. Animal is the superclass and Mammal is the subclass. The superclass is a Generalization of the subclass. While drawing the class diagram, Generalization is depicted by drawing a solid line from the subclass (child / derived class) to the superclass (parent / base class). At the superclass end of the line, a hollow triangle (arrow head) is drawn.
Realization
It is a relationship between two entities, in which one entity (consumer) implements the behavior specified by the other entity (supplier). A realization is indicated by a dashed line with an unfilled arrowhead at the supplier end of the line. It is used to depict the relationship between a class and the interface that it implements.
Instance Level Relationship Links (Associations)
An association is a special relationship or link between objects of two classes. It can be given a name, and it is depicted by a line joining the associated classes. On the class diagram, at the ends of an association link you may specify the role, ownership, multiplicity and visibility. An association may be uni-directional, bi-directional, aggregation, composition or reflexive.
Uni-directional Association
Two classes are related, but only one class is aware of the relationship.
Example: “Lives at” relationship between “Person” class and “Address” class. The link in the class diagram will show a line from “Person” to “Address” with the arrow head pointing to Address.
Bi-directional Association
Two classes are related and both are aware of each other’s existence and their relationship. It is depicted by a solid line joining the two classes.
Reflexive Association
The association of a class with itself is depicted as a reflexive association. On the class diagram it is shown as a looping line starting and ending at the same class.
Aggregation Association
Basic aggregation is used when one class is a part of another class, but has its own life cycle independent of the other class. For example “Car Wheel” class is a part of “Car” class. But an instance of the “Car Wheel” class may outlive the instance of the “Car” class of which it is a part. To show an aggregation, draw a solid line from the “Car” class to the “Car Wheel” class, and mark an unfilled diamond at the “Car” end of the line and a normal arrow head at the “Car Wheel” end. It is used to depict Class A “has a” Class B.
Composition aggregation is used when one class is a part of another class, and its life cycle is dependent on the instance of the other class. For example, an instance of the “Company” class will have one or more instances of the “Departments” class. When the “Company” instance is destroyed, its corresponding “Department” instances are also destroyed. This relationship is depicted by drawing a solid line connecting the 2 classes, with a filled diamond at the “Company” end of the line and a normal arrow head at the “Department” end. It is used to depict Class A “owns a” Class B.
Interfaces define a set of functions that an implementing class can perform. The link between an interface and its implementing class is shown as a dashed line. A weak relationship between two classes and is depicted by a dotted line joining the two classes.
The class diagram gives a complete description of objects in the system, their attributes, the functions that can be performed on those objects and the relationship between objects.