• Introduction
• SDLC
• Static and Dynamic Models
• Verifying Card and PIN at ATM
• Sequence Diagram
• Use Case
• Activity Diagram
• Class Diagram
• Separation of Concern
• GRASP
• GoF Design Patterns
• Factory and Observer
• Domain Model
• Unified Modeling Language
• Q and A
• SingleTon and Adapter Examples
• Adapter_new
• Observer Design Pattern Code_New
• Singleton Design Pattern Code New
• Factory Design Pattern Code_New
• Sequence Diagram to Code
• QandA_2023
• QandA_2023_II

OOAD - Object Oriented Analysis and Design

GRASP

General Responsibility Assignment Software Principle (Pattern): GRASP

OOAD – Object Oriented Analysis and Design

• Identify requirements
• Create domain model
• Create Use cases, create sequence diagram showing interactions between the objects
• Add methods to the classes
• Create Design Model using Domain model and the use cases

Objects have state and behavior; state of object is shown by the member variables of the object; behavior of objects is shown by the methods, the methods access, manipulate the member variables of the objects. Methods of the objects are called at the time of interaction. Deciding which method goes to which object and how the interaction between objects takes place is a complicated process. Mastering OOAD requires understanding of large set of principles; knowledge about design Patterns, lots of practices, examples are of great help.

UML is a standard visual modeling language only; it does not teach how to think like objects.

Object design

• What has to be done?
• How do things or objects related?
• How much design modeling has to be done and how to do it?
• What are the expected outputs?

What are Inputs to Object Design?

• Artifacts: use case text, Programming experiences, sequence diagrams, operation contracts

Activities of Object Design

• Start coding with test-first development
• Start some UML modeling: (Draw interaction diagram and class diagram) or use CRC cards.
• Apply OO design principles, such as GRASP and the Gang-of-Four (GoF) design patterns

Overall focus in OO design modeling is based on responsibility-driven design (RDD), thinking about assigning responsibilities to the collaborating objects.

Outputs

• UML interaction, class and package diagrams
• User Interface (UI) sketches and prototypes
• Database Models

Responsibilities and Responsibility-Driven Design

Software design is done based on the responsibilities, roles and collaborations of the software objects. Responsibility is a contract or obligation of a class. Responsibilities are assigned to object during object design. Responsibilities are of two types: doing and knowing.

Doing Responsibility

• Creating object or performing calculation.
• Initiating action in other objects.
• Controlling and coordinating activities among the objects

Knowing responsibility

• Knowing about data
• Knowing about related objects
• Knowing about objects that can derive or calculate some values

Patterns

Object-Oriented programming has been more than four decades old. Several programmers developed software using OOP languages like Smalltalk, C++,Lisp and gained lots of experience about programming with objects. Some of those experienced OO developers developed a repertoire of problems and solutions that were faced quite frequently in almost all software development process. That repertoire of problems and solutions is Design Patterns. The design patterns have name, problem statement and the solution statement.

In 1994, massive-selling and hugely influential book: Design Patterns written by Gamma, Helm, Johnson and Vlissides (Gang of Four (GoF)) was published. This book considered 23 design patterns for Object-Oriented software design. Those 23 design patterns are also known as the Gang of Four (GoF) design patterns.

GRASP Principles/Patterns

The GRASP patterns are not new patterns; they are just simplification of existing patterns/principles. GRASP defines nine basic OO design principles. GRASP is about figuring out the responsibilities and assigning responsibilities to the objects. GoF is for more advanced design ideas. Design patterns can be used during modeling and coding.

GRASP design Principles

• Creator
• Information Expert
• Low Coupling
• Controller
• High Cohesion
• Pure Fabrication
• Indirection
• Polymorphism
• Protected Variation

Name:	Creator
Problem:	Who creates an object of class A?
Solution:	Class B will create object of class A if any one of the following is true: B contains or compositely aggregates A B records A B closely uses A B has the all the required parameters to initialize object of class A
Name:	Information Expert
Problem:	How to know which object has what responsibility or on the basis of what responsibilities are assigned to objects?
Solution:	Assign responsibility to that object which has all the information required to fulfill that responsibility.
Name:	Low Coupling
Problem:	How to reduce the impact of change in one object on other objects?
Solution:	Assign responsibilities to objects in such a way that reduces coupling (dependencies) between the objects. That is, to perform responsibility by an object, it should be able to perform without minimum help from other objects.
Name:	Controller
Problem:	Which first object beyond the UI layer will receive and control a system operation? How to make UI focused on its job of taking/showing data to the users only?
Solution:	Consider object representing any one of the following options: Object representing overall "system", a "root object" (the entry point), a device on which the software is running. Object that represents a use case scenario within which the system operation executes.
Name:	High Cohesion
Problem:	How to create focused, understandable and manageable objects that support Low Coupling?
Solution:	Assign only those responsibilities to the objects which are of their concern and they should do, don't assign unnecessary responsibilities to the object which they can't do independently.
Name:	Polymorphism
Problem:	How to handle alternatives situations based on type?
Solution:	Assign responsibilities for behavior using polymorphic operations.
Name:	Pure Fabrication
Problem:	Which object should be assigned the responsibility, when low coupling and high cohesion principles are not to be violated?
Solution:	Create an artificial class, not part of the domain concept, with highly cohesive set of responsibilities. Fabricate an object.
Name:	Indirection
Problem:	How to avoid direct coupling (dependency) between two or more objects?
Solution:	Assign responsibility to an intermediate object to mediate between other objects or services to create low coupling between those objects.
Name:	Protected Variation
Problem:	How design objects so that the variations or changes in these objects do not have an unwanted impact on other objects?
Solution:	Create stable interface around the varying features or functions of the objects.