Object Oriented Design

Shruti Jathar
 Chapter -1

• Introduction
– Two views of software Developments: SSAD and
OOAD.
– Why Object – Orientation?
 Structured Programming
• Also called modular programming is a subset of
procedural programming.
• Enforces a logical structure on the program.
• More efficient and easier to understand and modify.
• Importance is given to the procedures that manipulate
the data.
• Follows top-down approach.
• Easy to understand and follows simple hierarchy.
• Basic three structures used are : decisions, sequences,
and loops.
• Eg. Pascal, and dBASE, Ada.
 Object Oriented Programming
• Organized around "objects" rather than data and Logic.
• Importance is given to the objects rather than procedures.
• Anything a program wants to deal with is treated as an object.
• Objects range from human beings (described by name, address
etc) to buildings and floors (whose properties can be described )
down to the little widgets on your computer desktop.
• Objects have their own properties and functionality ( methods ).
• Concepts in Object Oriented Programming
– Class
– Objects
– Encapsulation / Data Hiding
– Polymorphism ( many Forms – Functions / Operators )
– Inheritance ( Reduce Redundancy )
 What is System Analysis and Design?
Definition :
Systems analysis is the interdisciplinary part of science,
dealing with analysis of sets of interacting entities and
systems, often prior to their automation as computer systems,
and the interactions within those systems.
System Analysis is "an explicit formal inquiry carried out to
help someone, referred to as the decision maker, identify a
better course of action and make a better decision than he
might have otherwise made."
Structured System Analysis & Design Object Oriented Analysis & Design
Evolved from Structured programming. Evolved from Object-Oriented Prg.
SSAD is process oriented. OOAD is data oriented;
Processes are of primary focus. data is of primary focus.

System is broken down using DFD. System is broken down using Use Cases.

Components of the system are derived from Components of system are derived from the
the DFD's. class diagrams and (UML).
There are definable steps: planning, analysis, Here there is an iterative approach involving
design, and implementation from start to continuous testing and refinement of the
finish for the systems development life cycle. system from start.

In SSAD there is a separation of the data and In OOAD there is encapsulation of the data
processes. and processes into objects.

Graphical design tools are used to analyze and model the systemrequirements.
For each methodology there is a step by step process for developing the system.

Both techniques emphasize the documentation of the system and its requirements .
Advantages Of SSAD
• SSAD makes tracking bugs easier for project management.
• It is visual and makes understanding easier for the users/programmers.
• Makes good use of it graphical analysis and tools such as DFD's.
• Very well known and established methodology in the industry.
• Consequently a mature technique.
• Finally SSAD is relatively simple and easy to understand.
Limitations Of SSAD
• Since process-oriented, it ignores the non-functional requirements.
• There is less direct management involvement in SSAD.
• Requirement change means restarting the entire process.
• There is some but not enough user/analyst interaction.
• Except for the logical design and the DFD's, SSAD provides no other tools for
communication with users, and therefore it is more difficult for users to measure
progress.
• It is difficult to decide when to stop functional decomposition and to start
building the system.
• Does not always address the user's requirements.
• SSAD is not a good fit for object-oriented programming languages.
 What is Object-Oriented Design ?
• Process of planning a system of interacting objects for the
purpose of solving a software problem. It is one approach to
software design.
• Object Oriented Design refers to the objects that make up a
business.
• An object-oriented system studies the interaction of various
objects used by a system to solve the problem.
Object Oriented Concepts
• Object / Class : An association of data 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 the superclass and then it has its own set of
functions and data.
• Interface : The ability to defer the implementation of a method.
The ability to define the functions or methods signatures
without implementing them.

• Polymorphism : 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.
Object-Oriented Design Concepts
• Input (sources)
1.Use Case : A description of sequences of events that, lead to a
system doing something useful. Each use case provides one or
more scenarios that convey how the system should interact with
the users called actors to achieve a specific business goal or
function. Use case actors may be end users or other systems. In
many circumstances use cases are further elaborated into use case
diagrams. Use case diagrams are used to identify the actor (users
or other systems) and the processes they perform.
2.System Sequence Diagram : System Sequence diagram (SSD)
is a picture that shows, for a particular scenario of a use case, the
events that external actors generate, their order, and possible
inter-system events.
3.User Input : Document that shows and describes the look and feel
of the end product's user interface. Helps to visualize the end-product
and therefore helps the designer.

4.Relational Data Model : (if applicable): A data model is an abstract

model that describes how data is represented and used. If an
object database is not used, the relational data model should usually
be created before the design, since the strategy chosen for
object-relational mapping is an output of the OO design process.
However, it is possible to develop the relational data model and the
object-oriented design artefacts in parallel, and the growth of an
artefact can stimulate the refinement of other artefacts.
Output (deliverables) of object-oriented design
• Sequence Diagrams: Extend the System Sequence Diagram to add
specific objects that handle the system events.
• A sequence diagram shows, as parallel vertical lines, different
processes or objects that live simultaneously, and, as horizontal
arrows, the messages exchanged between them, in the order in which
they occur.
• Class Diagram: A class diagram is a type of static structure UML
diagram that describes the structure of a system by showing the
system's classes, their attributes, and the relationships between the
classes. The messages and classes identified through the
development of the sequence diagrams can serve as input to the
automatic generation of the global class diagram of the system.

--- END ---

 Chapter -2
• The Object Paradigm
- Object and classes
- Abstraction and encapsulation
- Methods and Message
- Interfaces, Inheritance and Polymorphism
- Access Control - The Business case for OO
Developments
Objects
• Objects are the entities of which the world is comprised.
• Objects interact with each other in real world.
• Object can be considered as anything a problem has to deal
with.
• Objects can be as simple as a pen , pencil, person or complex
like a bank account.
• Objects have unique features ( attributes ) and functionality.
• Object is characterized by its behavior.
• Any meaningful object has its own attributes and
functionality.
Classes
• Objects differ from each other only in the value they hold.
• Eg. Blue Crayon --- holds value “blue”
Red Crayon --- holds value “red”
Thus Crayon is a generalized Class and bluecrayon and
redcrayon will be objects Crayon class.
• A class is an abstract description of a set of objects.
• A class contain the descriptions of all the behaviors of the
objects that it represents.
• A class is a template for the creation of a particular type of
object.
• Class can be summarized as a collection of both data
(properties/attributes) and executable code (methods/functions).
Abstraction
• In order to process something from the real world we have to
extract the essential characteristics of that object.

• Data abstraction can be viewed as the process of refining away

the unimportant details of an object, so that only the useful
characteristics that define it remain.
Encapsulation
• Encapsulation is one step beyond abstraction
• Encapsulation links (binds) the data to the operations that can be
performed upon the data.
• Encapsulation enforces integrity (i.e. to make sure data is used in an
appropriate manner) by preventing unauthenticated programmers
from accessing data.
• Thus encapsulation, provides data security.
• Encapsulation is defined as the process of wrapping up the data
members and member functions together into a single unit.
struct Stud
{ private:
int no ;
char name[10];
public :
void fun1() { //code ; }
void fun2() { // code ; }
}
 Polymorphism
• Polymorphism refers to the ability of executing different
operations in response to the same message.
• Polymorphism can also be static or dynamic.
• The mechanism used to link the message with the method in
dynamic polymorphism is known as late or dynamic binding
• Linking done on compile time it is known as early/static binding.
• Polymorphism is implemented using four different mechanisms:
-Overloading: One Operator / Function ( method) name when
used to perform multiple tasks is called Overloading.It uses early
binding.
-Overriding: When a derived class re-defines a method inherited
from the base class it may use late binding and is termed as
overriding.
 Interface
• Objects interact with the outside world through the methods.
• Methods form the object's interface with the outside world;
eg. Buttons of your TV, are the interface between you and the electrical wiring.
• An interface is a group of related methods with empty bodies.
• The area of any shape can be calculated easily if an interface “Shape” is
specified as follows:
Eg .interface Shape {
int calArea();
}
NOTE : This interface could be used as per your Shape-Rect,Circle,triangle
class Rect implements Shape
{ int calArea()
{ // Actual code of the method }
// remainder of this class implemented as before
 }
 Inheritance
• This feature is used to reduce redundancy in the program.
Inheritance allows you to write common code.
• A new class can be created which inherits all of the
functionality and data of some other class.
• The new class can choose to respond to any given message in
a different way than the class it inherits from does and can also
define new methods.
• The new class can modify the data used to implement the class
it inherits from and can add to that data.
Terminology
• These data types are called classes.
• A variable of a given class is an instance of that class.
• Object refers to an instance of a class.
• The operations that a class implements are called methods (not
functions).
• Instead of calling a function to perform some operation on an
object, we send that object a message asking it to perform that
operation on itself.
• A given message may be meaningful to different classes of objects.
(e.g. "size" is meaningful both to a stack and a queue even though
each may calculate its size in a very different way).
Terminology
• A class which inherits from another class is a subclass of the
class it inherits from. A class is a subclass of its superclass.
• When a subclass responds to a message in a different way that
its superclass does, the subclass is said to have overridden its
superclass's method.
• Subclass is often used as a verb: "I subclassed the Vehicle class
to create the Car class."
OOD - Terminology
• Object-oriented programmers use phrases like:
"When the user presses this button, it sends a message to this
object which calculates something and then sends a message to
this other object which updates this and..."
instead of:
• "We wait for the user to press a button and then decide which
one it was, and based on that, we decide what to do, then we
wait for the user to do something else..."
 Chapter – 3

Object Oriented Methodologies

• Diagramming and Notations used in UML

• Generalisation
• Aggregation
• Association
OOD method of Grady Booch
- Also known as OOAD, is a originator to the Unified Modeling (UML).
- Includes six types of diagrams: class, object, state transition, interaction,
module, and process.
- Widely used and covers analysis & design phases of object oriented
system.
- Booch's notation is regarded as the most complete for representing object-
oriented systems.
- Booch methodology considers macro and micro development processes.
- Here one starts with class and object diagrams in the analysis phase and
refine these diagrams through various steps (within the same diagram,
undergoing a refinement process as long as the problem domain gets more
and more understood), following an evolutionary approach. Design
symbols are to be added when ready to generate code, usually
representing very final implementation decisions.
-Macro Development Process
-Technical management of the system.
-Consider goals and develop a prototype.
-Use of class and Object diagrams to analyze and design the system.
-Architecture of system is studied using interaction of classes and
objects.
-Refining the system after carrying out many iterations and producing a
stream of software implementation.
-5.Maintainence : Finally once the system is ready, localised changes
are needed to be made and bugs need to be removed in this stage .

Micro Development Process :

Each macro process has its own micro development process containing following
steps
1.Identify classes and objects.
2.Identify class and object semantics.
3.Identify class and object relationships.
4.Identify class and Object interfaces and implementations.
 OOD method - Rambaugh
• Presents Object Modeling Technique which are useful for analysis, design, and
implementation of the system.
• This is the first approach to identify and model objects making a system.
• Models specifies detailed interaction and state changes of objects in a system
• Four phases in this OMT are
– Analysis
– System Design
– Object Design
– Implementation.
1.State chart diagram:
UML State charts describe state of the object when object
reacts to different . They are needed when an object has a
different reaction dependent on its state. The state design
pattern uses polymorphism to define behaviour. Eg.
2.Class diagram:
• Class is representation of an object.
• It is a template from which objects are created.
• Class is the main building block of object-oriented application. 
• Classes are typically shown as rectangles with three sections: the
top section for the name of the class, the middle section for the
attributes of the class, and the bottom section for the methods of
the class.
• Eg, Course class can be described as ..
3.Use Case diagram
• A use case in SE is description of a system’s behaviour.
• Use case describes "who" can do "what" with the system.
• These describe the interaction between one or more actors and
the system itself, in a sequence of simple steps.
• Actors are one which exists outside the system under study.
• Actors take part in the activities system to achieve some goal.
• Actors may be end users, other systems, or hardware devices.
• Each use case is a complete series of events, described from the
point of view of the actor.
• The two main components of a use case diagram are use cases
and actors.
Sales Order System
4.Activity diagram:
• They are graphical representations of workflows of stepwise
activities and actions.
• In the Unified Modeling Language, activity diagrams can be used
to describe the step-by-step workflows of the components in a
system.
• An activity diagram shows the overall flow of control.
• Activity diagram is a simple and intuitive illustration of what
happens in a workflow, what activities can be done in parallel,
and whether there are alternative paths through the workflow.
• These diagrams are informative and take support for choice,
iteration and concurrency.
5.Sequence diagram:
These represent sequential nature of the logic.
• Boxes across the top represent objects, classes, or actors. Objects
have labels in the standard UML format name: ClassName.
• The dashed lines hanging from the boxes are called object lifelines,
representing the life span of the object during the scenario being
modelled.
• The long, thin boxes on the lifelines are activation boxes, also called
method-invocation boxes, which indicate processing is being performed
by the target object/class to fulfill a message.
Main Purpose
• The main purpose of a sequence diagram is to define event
sequences. The focus is less on messages themselves and
more on the order in which messages occur.
• Most sequence diagrams will communicate what messages are
sent between a system's objects as well as the order in which
they occur. The diagram conveys this information along the
horizontal and vertical dimensions: the vertical dimension
shows, top down, the time sequence of messages/calls as they
occur, and the horizontal dimension shows, left to right, the
object instances that the messages are sent to.
Generalisation
• Generalization relationship is a relationship in which one
element (the child) is based on another element (the parent).
• Classes are composed of three things: a name, attributes, and
operations. 
Association
• This is the most common relationship in a class
diagram. 
• This shows the relationship between instances of
classes.
• Eg. Class Order is associated with class Customer. 
• The multiplicity of the association denotes the
number of objects that can participate in then
relationship.For example, an Order object can be
associated to only one customer, but a customer can
be associated to many orders. 
Chapter – 4
Object-Oriented Systems Development Process
• Rational Unified Process
Four Major phases:-
Inception, Elaboration, Construction, Transition
Requirements Engineering
Problem analysis.
Understanding Stockholders need
Type of requirements.
Use-case Model: Writing Requirements
 Rational Unified Process
• It is a Software Engineering Process which provides
disciplined approach to assigning tasks and responsibilities
within a development organization.
• Its goal is to ensure the production of high-quality software.
• The development team for the Rational Unified Process are
working to ensure that the process is continuously updated
and improved
• The Rational Unified Process is supported by tools, which
automate large parts of the process.
• Rational Unified Process divides one development cycle in
four consecutive phases.
Rational Unified Process phases.
• Inception phase
• Elaboration phase
• Construction phase
• Transition phase

Note : Each phase is concluded with a milestone

- A point where critical decisions must be made.
- Each phase has a specific purpose.
 1.Inception Phase

During inception establish the business case for the system and
delimit the project scope.
-Identify all external entities with which system will interact (actors)
-Define the nature of the interaction at a high-level.
-This involves identifying all use cases and describing a few
significant ones.
-The business case includes success criteria, risk assessment, and
estimate of the resources needed, and a phase plan showing dates
of major milestones.
The outcome of the inception phase is:
• Vision document : General vision of the core project's
requirements, key features, and main constraints.
• A initial use-case model (10% -20%) complete)
• An initial project glossary (may optionally be partially
expressed as a domain model).
• An initial business case, which includes business
context, success criteria (revenue projection, market
recognition, and so on), and financial forecast.
• An initial risk assessment.
• A project plan, showing phases and iterations.
• A business model, if necessary.
• One or several prototypes.
The evaluation criteria for the inception phase are:
• Stakeholder concurrence on scope definition and cost/schedule
estimates.
• Requirements understanding as evidenced by the primary use cases.
• Credibility of the cost/schedule estimates, priorities, risks, and
development process.
• Depth and breadth of any architectural prototype that was developed.
• Actual expenditures versus planned expenditures.
The project may be cancelled or considerably re-thought if it fails to pass
this milestone.
 2.Elaboration Phase
• Purpose is to analyze the problem domain, establish a sound
architectural foundation, develop the project plan, and
eliminate the highest risk elements of the project.
• To accomplish these objectives, you must have the “mile
wide and inch deep” view of the system. Architectural
decisions have to be made with an understanding of the
whole system: scope and major requirements.
• Elaboration phase is the most critical of the four phases.
• Here the hard “engineering” is considered complete and the
project undergoes most important decision : whether or not
to commit the project.
• The elaboration phase activities ensure that the architecture,
requirements and plans are stable enough, and the risks are
sufficiently reduced.
• This predictably determines the cost and schedule for the
completion of the development.
• Executable architecture prototype is built in one or more
iterations, depending on the scope, size, risk, and novelty of
the project.
•
The outcome of the elaboration phase is:
• A use-case model (at least 80% complete) — all use cases and
actors have been identified, and most usecase descriptions have
been developed.
• Supplementary requirements capturing the non functional
requirements and any requirements that are not associated with a
specific use case.
• Software Architecture Description.
• An executable architectural prototype.
• A revised risk list and a revised business case.
• A development plan for the overall project, including the coarse-
grained project plan, showing iterations” and evaluation criteria
for each iteration.
• An updated development case specifying the process to be used.
• A preliminary user manual (optional).
• MileStone -
-The second important project milestone, the Lifecycle Architecture
Milestone.
-Here Examine the detailed system objectives and scope, the choice
of architecture, and the resolution of the major risks.
3.Construction Phase
• Here all features are thoroughly tested.
• Construction phase is, in one sense, a manufacturing process..
• Managing resources and controlling operations to optimize costs, schedules,
and quality.
• In other words, one of the critical qualities of the architecture is its ease of
construction.
• The software product integrated on the adequate platforms.

The outcome of the construction phase is a product ready to put in hands of

its end users. It consists of:
• The user manuals.
• A description of the current release.
• Milestone : Initial Operational Capability
Here you decide if the software, the sites, and the users are ready to go
operational, without exposing the project to high risks
The evaluation criteria for the construction phase
involve answering these questions:
• Is this product release stable and mature enough to be
deployed ?
• Are all stakeholders ready for the transition into the user
community?
• Are the actual resource expenditures versus planned
expenditures still acceptable?
• Transition may have to be postponed by one release if the
project fails to reach this milestone
 4.Transition Phase

The transition phase focuses on the activities required to place the software into
the hands of the users.
Typically, this phase includes several iterations, including beta releases, general
availability releases, as well as bug-fix and enhancement releases.
Considerable effort is expended in developing user-oriented documentation,
training users, supporting users in their initial product use, and reacting to user
feedback.
At this point in the lifecycle, however, user feedback should be confined
primarily to product tuning, configuring, installation, and usability issues.
The primary objectives of the transition phase include:
• Achieving user self-supportability
• Achieving stakeholder concurrence that deployment baselines are complete and
consistent with the evaluation criteria of the vision
• Achieving final product baseline as rapidly and cost effectively as practical
• This phase can range from being very simple to extremely complex, depending
on the type of product.
At the end of the transition phase is the fourth important
project milestone, the Product Release Milestone.
• At this point, you decide if the objectives were met, and if you
should start another development cycle. In some cases, this
milestone may coincide with the end of the inception phase for
the next cycle.
• The primary evaluation criteria for the transition phase involve
the answers to these questions:
• Is the user satisfied?
• Are the actual resources expenditures versus planned
expenditures still acceptable?
• Iterations
Each phase in the Rational Unified Process can be further broken down into
iterations. An iteration is a complete development loop resulting in a release
(internal or external) of an executable product, a subset of the final product under
development, which grows incrementally from iteration to iteration to become the
final system.
Compared to the traditional waterfall process, the iterative process has the
following advantages:
• Risks are mitigated earlier
• Change is more manageable
• Higher level of reuse
• The project team can learn along the way
• Better overall quality
Static Structure of the Process
• A process describes who is doing what, how, and when. The Rational Unified
Process is represented using four primary modeling elements:
• Workers, the ‘who’
• Activities, the ‘how’
• Artifacts, the ‘what’
• Workflows, the ‘when’