Class Diagrams In UML

Class diagram describes the attributes and operations of a class and also the constraints imposed on the system. The class diagrams are widely used in the modeling of object-oriented systems because they are the only UML diagrams, which can be mapped directly with object oriented languages. 

Class diagram is a static diagram. It represents the static view of an application. Class diagram is not only used for visualizing, describing, and documenting different aspects of a system but also for constructing executable code of the software application.

Class diagram shows a collection of classes, interfaces, associations, collaborations, and constraints. It is also known as a structural diagram.

The purpose of class diagram is to model the static view of an application. Class diagrams are the only diagrams which can be directly mapped with object-oriented languages and thus widely used at the time of construction.

The purpose of the class diagram can be summarized as −

·        Analysis and design of the static view of an application.

·        Describe responsibilities of a system.

·        Base for component and deployment diagrams.

·        Forward and reverse engineering.

Example: Class diagram for an ATM system

ATMs are deceptively simple: although customers only need to press a few buttons to receive cash, there are many layers of security that a safe and effective ATM must pass through to prevent fraud and provide value for banking customers. The various human and inanimate parts of an ATM system are illustrated by this easy-to-read diagram—every class has its title, and the attributes are listed beneath. 

How to Draw a Class Diagram?

Class diagram is basically a graphical representation of the static view of the system and represents different aspects of the application. A collection of class diagrams represent the whole system.

The following points should be remembered while drawing a class diagram −

·        The name of the class diagram should be meaningful to describe the aspect of the system.

·        Each element and their relationships should be identified in advance.

·        Responsibility (attributes and methods) of each class should be clearly identified

·        For each class, minimum number of properties should be specified, as unnecessary properties will make the diagram complicated.

·        Use notes whenever required to describe some aspect of the diagram. At the end of the drawing it should be understandable to the developer/coder.

·        Finally, before making the final version, the diagram should be drawn on plain paper and reworked as many times as possible to make it correct.