Unit 2 - Class Diagrams
Unit 2 - Class Diagrams
Unit 2 - Class Diagrams
software engineering to visualize the structure and relationships within a software system.
Purpose:
● It analyses and designs a static view of an application.
● It describes the major responsibilities of a system.
● It is a base for component and deployment diagrams.
● It incorporates forward and reverse engineering.
● Upper Section:
The upper section encompasses the name of the class. A class is a representation of
similar objects that shares the same relationships, attributes, operations, and semantics.
Some of the following rules that should be taken into account while representing a class
are given below:
○ Capitalize the initial letter of the class name.
○ Place the class name in the center of the upper section.
○ A class name must be written in bold format.
○ The name of the abstract class should be written in italics format.
● Middle Section:
The middle section constitutes the attributes, which describe the quality of the class. The
attributes have the following characteristics:
○ The attributes are written along with its visibility factors, which are public (+),
private (-), protected (#), and package (~).
○ The accessibility of an attribute class is illustrated by the visibility factors.
○ A meaningful name should be assigned to the attribute, which will explain its
usage inside the class.
● Lower Section:
The lower section contain methods or operations. The methods are represented in the
form of a list, where each method is written in a single line. It demonstrates how a class
interacts with data.
Relationships
1. Dependency:
A dependency is a semantic relationship between two or more classes where a change
in one class cause changes in another class. It forms a weaker relationship.
2. Generalization:
A generalization is a relationship between a parent class (superclass) and a child class
(subclass). In this, the child class is inherited from the parent class.
3. Association:
It describes a static or physical connection between two or more objects. It depicts how
many objects are there in the relationship. For example, a department is associated with
the college.
Class diagrams primarily depict two main types of static relationships among classes:
They can be created from different perspectives to serve specific purposes during the software
development lifecycle:
1. Conceptual Perspective:
○ In the conceptual perspective, class diagrams focus on capturing high-level
domain concepts and relationships.
○ This perspective is used to create a conceptual model of the system, which is
often independent of the specific programming language or implementation
details.
○ It helps stakeholders understand the core ideas behind the software.
2. Specification Perspective:
● The specification perspective emphasizes the interface and contract of software
components without delving into their actual implementation.
● It defines how classes interact with one another and the services they offer.
● This perspective is valuable for defining APIs and designing the overall system
structure.
3. Implementation Perspective:
● The implementation perspective provides a detailed view of the actual classes and their
relationships within the software.
● It includes the specific attributes, methods, and implementation details of each class.
● This perspective is used by developers to design and implement the software.