Determining How to Build:

Object Oriented Design

(OOD)
1
* Object-oriented analysis and design (OOAD) is a software engineering
approach that models a system as a group of interacting objects. Each
object represents some entity of interest in the system being modeled, and is
characterized by its class, its state (data elements), and its behavior. Various
models can be created to show the static structure, dynamic behavior, and
run-time deployment of these collaborating objects. There are a number of
different notations for representing these models, such as the Unified
Modeling Language (UML).
Definition of OOD
* Object Oriented Design (OOD) is concerned with developing object-oriented
models of a software/system to implement the requirements identified
during OOA. [SEI]
* System Design is the transformation of analysis models of the problem
space into design models (based on the solution space).
* It involves selecting strategies for building the system e.g. software/hardware
platform on which the system will run and the persistent data strategy.
2
* Object-oriented design (OOD) elaborates the analysis models to produce
implementation specifications.
* OOA focuses on what the system does, OOD on how the system does it.
* Design emphasizes on conceptual solution that fulfills the requirements,
rather than its implementation. For example, a description of a database
schema and software objects. Ultimately, designs the system.
* During the design phase, we elevate the model into logical entities, some of
which might relate more to the computer domain (such as user interface, or
the access layer) than the real world or the physical domain (such as people
or employees). Start thinking how to actually implement the problem in a
program.
* The goal is to design the classes that we need to implement the system.
* Design is about producing a solution that meets the requirements that have
been specified during analysis.
* Design focuses on understanding the solution, Operations & attributes,
performance, close to real code, object lifecycles, non-functional
3
requirements.
* During object-oriented design, there is an emphasis on defining software
objects and how they collaborate to fulfill the requirements. For example, in
the Library System, a Book software object may have a Title, ISBN, etc
attributes.
* An object-oriented system is composed of objects. The behavior of the
system results from the collaboration of those objects. Collaboration between
objects involves them sending messages to each other. Sending a message
differs from calling a function in that when a target object receives a
message, it decides on its own what function to carry out to service that
message. The same message may be implemented by many different
functions, the one selected depending on the state of the target object.
* The implementation of "message sending" varies depending on the
architecture of the system being modeled, and the location of the objects
being communicated with.
* Finally, during implementation or object-oriented programming, design
objects are implemented, such as a Book class in Java.

4
* Design results in:
a) a list of design goals – qualities of the system
b) software architecture describing:
i) the subsystem responsibilities,
ii) dependencies among subsystems,
iii) subsystem mapping to hardware,
iii) major policy decision such as control flow, access control, and data
storage

5
* The class type Architecture indicates that users application interact directly with the
user interface layer application. The following Class Type Architecture represents high
level strategy for software application. The various layers are represented by the
rectangles and collaboration between layers by the arrows. The primary name of layer
indicated first, and other common names in parenthesis. Those architecture layers are
listed below and they will be discussed in below table one by one.

6
Class Type Architecture

Fig. 5.1 Class Type Architecture

State Chart Modeling
* The state chart diagram shows the change of an object through time based
upon events that occur and it shows how the object changes from start to
finish.
* States are represented as a rounded rectangle with the name of the state
show in the system.
* A state diagram shows a sequence of states an object can assume during its
lifetime, together with the stimuli that cause changes of state.
* A state diagram describes a hypothetical machine (finite automaton) which at
any given time is found in a set of finite states.
* Connecting state together are transitions. These represent the events that
cause the object to change from one state to another. The guard clause of
the label is again mutually exclusive and must resolve itself to be either true
or false. Actions represent tasks that run causing the transitions. Like activity
diagrams, state diagrams have one start and end from at which the state
transition start and end respectively. State diagrams show the change of an
object over time and are useful when an object exhibits interesting or unusual
behavior-such as that of a user interface component. The figure below shows
security state chart for a system. 8
.

Start

You have valid

User Name and
Password

Enter User Name and Password

Is User Display User

No Yes
Name &
Return Password Environment
Correct?

Choose if you want to get

User closes the Order to close

Finish Users get proper
environment after
finishing service

Fig. 5.2 State Chart Diagram for Security System

 State Chart Diagram describes dynamic behavior of a system in response to
actions triggered (external stimuli).

Finish
4
1
Close Main Menu
Click Add New
Book Button

Start Application Main

Menu Cancel Add New Book
Form 2
2
Fill & Click Save

Close Add New

Book Form
3
Save to DB

Fig. 5.3 State Chart Diagram for Add New Book

10
* A collaboration models the objects and links that are meaningful within an
interaction.
* The objects and links are meaningful only in the context provided by the
interaction. A classifier role describes an object and an association role describes a
link within a collaboration. A collaboration diagram shows the roles in the
interaction as a geometric arrangement
* One use of a collaboration diagram is to show the implementation of an
operation.
* The collaboration shows the parameters and local variables of the operation,
* The collaboration diagram is an interaction diagram emphasized the structural
organization of the object that participates in an interaction.
* It consists of collection of objects that work together to preform a task. In the
class diagram modeling the static nature of the system is shown. Where as the
collaboration diagram shows the message flow between objects in an oriented are
developed in the following manner.
• The rectangle represents the various objects involved that make up the
application.
• The line between the classes represent the relationship(association, aggregation ,
composition dependency between them )
• The text along the line is for invoking message on the collaboration diagram.
* The collaboration diagrams are drawing completely based on the sequence
diagrams in the analysis artifact. 11
* Collaboration Diagram represents interactions (communications) between
objects as series of sequenced messages.
* It describes both static structure and dynamic behavior of a system.
* Compared to Sequence Diagram, Collaboration Diagram is more focused on
showing the collaboration of objects rather than the time sequence.

1 :Add New Book Button

2

4 3
:Add New Book Control

Clerk 7
:Add New Book Form
6
5
:Book

Fig. 5.5 Collaboration Diagram for

12 Add New Book Information
 Component diagrams allow the designer to model physical relationships
among the physical modules of code. The diagram when combined with the
deployment diagram can be used to portray the physical distribution of the
software modules over a network.
* A component is a physical unit of implementation with well-defined
interfaces that is intended to be used as a replaceable part of a system. Each
component embodies the implementation of certain classes from the system
design. Well designed components do not depend directly on other
components but on interfaces that components support. In that case, a
component in a system can be replaced by another component that supports
the proper interfaces.
* Components have interfaces they support and interfaces they require from
other components. An interface is a list of operations supported by a piece of
software or hardware.
* Component diagrams describes organizations of physical software
components, including source code, run time(binary code), and executable.
* A Component is a physical building block of a system.
13
Continued…
* The main purpose of the component diagram is to know the structural
relationship between the components of the system. In UML a component
diagram represent implementation items.
* Generally components are considered autonomous, encapsulated units with
in a system or subsystem things that will typically be implemented using
replaceable models.
* In component based development, component diagrams after architects a
natural format to begin modeling a solution. Component diagram allow an
architect to verify that a system’s required functionality is being implemented
by components thus ensuring that the eventual systems will be acceptable.
* Developers find the component diagram useful because it provides them with
a high level architectural view of the system that they will be building, which
helps developers being formalizing a roadmap for the implementation and
make decision about task assignments and needed skill enhancement.

14
Continued…

15

Fig. 5.6 Component Diagram for Revenue Collecting System

Shows the configuration of run-time processing elements and the software
processes living on them. The deployment diagram visualizes the distribution
of components across the enterprise.
A node is an object which physically present at runtime and has computing
power or memory, such as computers (processors), devices, and the like.
Deployment diagrams show which components and objects run on which
node (processes, computers) – how they are configured and which
communication relations exist between them.
Deployment diagrams are used to represent the relationships between the
hardware components used in the physical infrastructure of an information
system.
In the deployment phase, we’re concerned with getting the hardware and
software to the end users, along with manuals and training materials. This may
be a complex process, involving a gradual, planned transition from the old way
of working to the new. The sort of task we carry out during the deployment
phase is ‘Run the program setup.exe on each server machine and follow the
instructions that appear’.
16
.

Fig. 5.7 Deployment Diagram for ATM

17
* Deployment diagram shows how the software components, processes, and
objects deployed into the physical architecture of the system. It shows the
configuration of the hardware units (e.g. computers, communication devices,
etc) and how the software components are distributed across the units.

18

Fig. 5.8 Deployment Diagram for Revenue Collecting System

Persistence Modeling
* Persistence model- A model that describes the persistent data aspects of a
software system.
* Persistence modeling is used to communicate the design of a database to
both users and to other developers. This model basically is the entity
relationship diagram in database application.
* Your Subsystem Components may be windows or web based subsystems that
run only over a LAN or Stand alone PC, and you may want to store the
persistent data of these subsystems in SQL Server database or in any
database according to the requirement of the system.

19
 20

Fig. 5.9 Persistent Modeling for Student Placement & Retrieval System
*UI Design Rules
• UI Design Rule 1: Making the interface simple.
• UI Design Rule 2: Making the interface transparent and natural.
• UI Design Rule 3: Allowing users to be in control of the software.
*Windows in User Interface are used for
• Forms and data entry windows:
 Data entry windows provide access to data that users can retrieve,
display and change in the application.
• Dialog boxes:
Dialog boxes display status information or ask users to supply
information or make a decision before continuing with a task.
• Application windows:
* An application window is a container of application objects or icons. It
contains an entire application with which
21 users can interact
Three general steps in creating a user interface object?
• Creating a user interface generally consists of three steps.
1.Create the user interface objects (such as buttons, data entry fields).
2.Link or assign the appropriate behaviors or actions to these user interface
objects and their events.
3.Test, debug, then add more by going back to step 1.
1.Create user interface controls
2.Associate actions to the user interface controls and their events
3.Test/debug

22
 23

Fig. 5.10 System Login UI

 24

Fig. 5.11 The Main Menu Form UI

 25

Fig. 5.12 Registration Form UI

 7

26

Fig. 5.13 Update Information Form UI

* Object-oriented analysis and design (OOAD) is a software engineering
approach that models a system as a group of interacting objects. Each
object represents some entity of interest in the system being modeled, and
is characterized by its class, its state (data elements), and its behavior.
* Object Oriented Design (OOD) is concerned with developing object-
oriented models of a software/system to implement the requirements
identified during OOA. [SEI]
* System Design is the transformation of analysis models of the problem
space into design models (based on the solution space).
* OOA focuses on what the system does, OOD on how the system does it.
* Design emphasizes on conceptual solution that fulfills the
requirements, rather than its implementation.
* Design is about producing a solution that meets the requirements that have
been specified during analysis.

27
* The Class Type Architecture indicates that users application interact directly
with the user interface layer application.
* The State Chart Diagram describes dynamic behavior of a system in response
to actions triggered (external stimuli). It models the dynamic flow of control
from state to state with in a system.
* Collaboration Diagram is same as Sequence Diagram but, more focused on
showing the collaboration of objects rather than the time sequence.
* Component Diagram describes organization of physical software
components, UI, Database, Persistence(DBMS) which help know structural
relationship between the components of the system. Component is physical
building block of a system.
* Deployment Diagram depicts a static view of the run-time configuration of
hardware nodes and the software components that run on those nodes. It
show the hardware for your system, the software that is installed on that
hardware, and the middleware used to connect the disparate machines to one
another. Node is physical resource that executes code components.
* Persistence modeling is used to communicate the design of a database to
both users and to other developers. How28 attributes of a an object are saved

persistently/consistently to database.