Object-oriented design (OOD)

Object-oriented design (OOD) is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. An object contains encapsulated data and procedures grouped together to represent an entity. The 'object interface' defines how the object can be interacted with. An object-oriented program is described by the interaction of these objects. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. The input for object-oriented design is provided by the output of object-oriented analysis. The purpose of object-oriented analysis is to create a model of the system's functional requirements that is independent of implementation constraints. This may include identifying different classes required to implement features required in the application.

Object-oriented concepts are used to design application. The five basic concepts of object-oriented design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

• Object/Class: A tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is created based on a class). Each object serves a separate function. It is defined by its properties, what it is and what it can do. An object can be part of a class, which is a set of objects that are similar.
• Information hiding: The ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.
• Inheritance: The ability for a class to extend or override functionality of another class. The so-called subclass has a whole section that is derived (inherited) from the superclass and then it has its own set of functions and data.
• Interface (object-oriented programming): The ability to defer the implementation of a method. The ability to define the functions or methods signatures without implementing them.
• Polymorphism (specifically, Subtyping): The ability to replace an object with its subobjects. The ability of an object-variable to contain, not only that object, but also all of its subobjects.

Class diagram - A class diagram is a type of diagram that describes the structure of a system by showing the system's classes, its attributes, and the relationships between the classes. 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.

Purpose of Class Diagrams

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.

How to Draw a Class Diagram?

Class diagrams are the most popular UML diagrams used for construction of software applications. It is very important to learn the drawing procedure of class diagram.

Class diagrams have a lot of properties to consider while drawing but here the diagram will be considered from a top level view.

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.

The following diagram is an example of an Order System of an application. It describes a particular aspect of the entire application.

First of all, Order and Customer are identified as the two elements of the system. They have a one-to-many relationship because a customer can have multiple orders.

Order class is an abstract class and it has two concrete classes (inheritance relationship) SpecialOrder and NormalOrder.

The two inherited classes have all the properties as the Order class. In addition, they have additional functions like dispatch () and receive ().

The following class diagram has been drawn considering all the points mentioned above.

Reference: https://www.tutorialspoint.com/uml/uml_class_diagram.htm