OBJECT ORIENTED ANALYSIS

The intent of object oriented analysis is to define all classes that are relevant to the
problem to be solved. To accomplish this ,a number of tasks must occur.

1.Basic user requirements must be communicated between the customer and the
software engineer
2.Classes must be identified
3. A class hierarchy is defined

4.Object-to –object relationships should be represented.

5.Object behavior must be modeled.
6.Tasks 1 through 5 are reapplied iteratively until the model is complete.

Structured Analysis

One view of analysis modeling called structured analysis considers data and the
processes that transform the data as separate entities.Data objects are modeled in a
way that defines their attributes and relationships. processes that manipulate data
are modeled in a manner that shows how they transform data as data objects flow
through the system
.Class based modeling.
.Classes and objects.
• They are the main building blocks on an OOD. During analysis we view an
object as an entity in the problem domain that have clearly defined boundaries
and behavior. Objects represent runtime entities in an OO system. They occupy
space in memory that keeps its state and is operated on by the defined
operations on the object.
A class defines possible set of objects.

A class can be considered a template that specifies the properties for objects of the
class
1.an interface that defines which parts of an object of a class can be accessed from
outside and how.
2.A class body that implements the operations in the interface
3.Instance variables that contain the state of an object of that class.

• A class represents a set of objects that share a common structure and a

common behavior ,whereas an object is an instance of a class.
• Dynamic modeling
• The dynamic model of a system aims to specify how the state of various
objects changes when events occur. An event is an occurrence of
something .It is an initiator and a responder. A scenario is a sequence of
 events that occur in particular execution of the system. From then scenarios
the different events can be identified .
• The different scenarios together can characterize the behavior of the system.
If the design is such that it can support all scenarios , we can be sure that the
desired dynamic behavior of the system can be supported by the design.
• It is best to start by modeling the scenarios.
• First the main scenarios are modeled and t5hgen the exception scenarios get
modeled.
• In a system for restaurant the main success scenario for placing an order
could be

• Customer reads menu

• Customer places order
• Order is sent to the kitchen for preparation
• Ordered items are served
• Customer requests for a bill for the order
• Bill is prepared for this order
• Customer is given the bill
• Customer pays the bill

• The exception scenario could be

• If the ordered item was not available or if the customer cancels his order.
• A possible sequence diagram of the preceding scenario is given .
 kitchen
customr
order
Place
order prepare

serve dishes
read

Menu Get bill Bill

prepare
Bill

Bill

Pay bill

• The main reason for performing dynamic analysis is that scenarios and
sequence diagrams extend the initial design.

Challenges of object oriented analysis

• It is easy to cross the boundary line between specifications (what) and design
how).
• The transition from object oriented analysis to object oriented design is more
smoother than the transition in the classical paradigm from analysis phase
to design phase.
• In classical paradigm the initial task of the design phase is to decompose the
product into modules. In contrast the classes , the modules of object oriented
design workflow are extracted during the object oriented analysis workflow
ready for refinement ,during the object oriented design workflow.

• Class Diagrams.

• The purpose of a class diagram is to depict the classes within a model. In an

object oriented application,
• classes have attributes (member variables), operations (member functions)
• and relation-ships with other classes. The UML class diagram can depict all
these things quite easily. The fundamental element of the class diagram is an
icon the represents a class. This icon is shown in figure

• A class icon is simply a rectangle divided into three compartments. The

topmost compartment contains the name of the class.
• The middle compartment contains a list of attributes (member variables),
• and the bottom compartment contains a list of operations (member
functions)
• . In many diagrams, the bottom two compartments are omitted.
• Even when they are present, they typically do not show every attribute and
operations.
• The goal is to show only those attributes and operations that are useful for
the particular diagram.
 Button Class

Illuminated ::
Boolean

Elevator Button Class Floor button class

Communicates
with Communicates with
Elevator class
 Detailed design

• Detailed design is concerned with specifying algorithmic details ,concrete

data representations ,interconnections among functions and data structures
and packaging of the software product.
• The starting point for detailed design is an architectural structure for which
algorithmic details and concrete data representations are to be provided.
• Implementation: addresses issues of programming language syntax coding
style ,internal documentation and insertion of testing and debugging probes.
• Detailed design separates the activity of low level design from
implementation
• The notations used for detailed design include HIPO diagrams, structured
English, pseudo code, Structure charts, structured flow charts
• Product packaging is an important aspect of detailed design .packaging is
concerned with the manner in which global data items are selectively shared
among program units, specification of static data areas ,packaging of
program units as functions and subroutines, specification of parameter
passing mechanisms , file structures , file access techniques, structure of
compilation modules and load modules.

• Transaction analysis

• In the case of systems where there are many different sets of possible
actions and the actions to be performed depend on the input command
specified .The module splitting the input is called transaction center. one of
the standard ways to convert a data flow diagram into a structure chart is to
have an input module that gets the analyzed transaction and a dispatch
module that invokes the modules for the different transactions.
•

b
T

Transactio
c
n Center

Transaction
Analysis

Get Transaction Dispatch

Do type1 Do type 2 Do typen

 Design classes

• Design classes are intended to describe some element of problem domain,

focusing on the aspects of the problem that are user or customer visible.
• As the design model evolves the software team must define a set of classes
that
• 1.Refine the analysis classes by providing design detail that will enable the
classes to be implemented
• 2.to create a set of design classes that implement a software infrastructure
to support the business solution.
• Five different types of design classes each representing a different layer of
design architecture are suggested

• User interface classes :define all abstractions that are necessary for human
computer interaction (HCI)
• Business domain classes: They are often refinements of the analysis classes
defined earlier .The classes identify the attributes and services that are
required to implement some element of the business domain
• Process classes implement lower level business abstractions required to fully
manage the business domain classes
• Persistent classes represent data stores that will persist beyond the execution
of the software.
• System classes implement software management and control functions that
enable the system to operate and communicate with the outside world.

• The four characteristics of a well formed design class

• Complete and sufficient :A design class should be complete encapsulation of

all attributes and methods that reasonably be expected to exist for a class
.Sufficiency ensures that the design class contains those methods that are
sufficient to achieve the intent of the class .
• Primitiveness: Methods associated with design class should be focused on
accomplishing one service for the class
• High cohesion :A cohesive design class has a small focused set of
responsibilities and it applies attributes and methods to implement those
responsibilities.
• Low coupling: with in a design model it is necessary for design classes to
collaborate with one another .How ever the collaboration should be kept at a
low minimum.

The open closed principle

• The basic goal here is to promote building of systems that are easily
modifiable as modification and change happen frequently and
• a design that cannot easily accommodate change will result in systems that
will die fast and will not be able to easily adapt to the changing world.

Software entities should be open for

extension , but closed for
modification.
Example 0..n 0..n
client Printer

• In the above design the client directly calls the methods on printer object for
printing something. Now if the system has to be enhanced to allow another
printer to be used by the client .under this design to implement this change a
new class printer2 will have to be created and the code of the client class will
have to be changed to allow using object of type printer2 as well.
 Design that supports open closed
principle

0..n 0..n
client printer

Printer 1 Printer 2

In the above design using open closed principle we create an abstract class
printer that defines the interface of a printer and specifies all methods a printer
object should support.printer1 is implemented as a specialization of this class.
When printer 2 is added it is added as a subclass of type printer.

Some design guidelines

• 1.The public interface of a class should only contain the operations defined
on the class. That is the data definitions should not be a part of the public
interface.
• Only the operations that form the interface for a class that is the ones needed
by the users of the class should be the public members of the class
• 3.an instance of a class should not send messages directly to components of
another class.That is if there is a class C defined inside a class B , then objects
of a class A should not directly perform operations on objects of class C
• 4.Each operation defined on a class should be such that it either modifies or
accesses some data defined in the class
• 5.A class should be dependent on as few classes as possible.
• 6.The interaction between two classes should be explicit
• 7.Each subclass should be defined as a specialization of the super class
• 8.The number of arguments and size of methods should be kept small
 Coupling in OO Systems

• In OO systems, basic modules are classes, which are richer than fns
• OO Systems have three types of coupling
– Interaction coupling
– Component coupling
– Inheritance coupling

Coupling in OO - Interaction
• Interaction coupling occurs due to methods of a class invoking methods of
other classes
– Like calling of functions
– Worst form if methods directly access internal parts of other methods
– Still bad if methods directly manipulate variables of other classes
– Passing info through tmp vars is also bad
Coupling in OO …
• Least interaction coupling if methods communicate directly with parameters
– With least number of parameters
– With least amount of info being passed
– With only data being passed
• I.e. methods should pass the least amount of data, with least no of parms

Coupling in OO - Component
• Component coupling – when a class A has variables of another class C
– A has instance vars of C
– A has some parms of type C
– A has a method with a local var of type C
• When A is coupled with C, it is coupled with all subclasses of C as well
• Component coupling will generally imply the presence of interaction
coupling also
Coupling in OO - Inheritance
• Inheritance coupling – two classes are coupled if one is a subclass of other
• Worst form – when subclass modifies a signature of a method or deletes a
method
• Coupling is bad even when same signature but a changed implementation
• Least, when subclass only adds instance variables and methods but does not
modify any
Cohesion in OO Systems
• In OO, different types of cohesion is possible as classes are the modules
– Method cohesion
– Class cohesion
– Inheritance cohesion
• Method cohesion – why diff code elts are together in a method
– Like cohesion in functional modules; highest form is if each method
implements a clearly defined function with all elts contributing to
implementing this function
Cohesion in OO…
• Class cohesion – why diff attributes and methods are together in a class
– A class should represent a single concept with all elts contributing
towards it
– Whenever multiple concepts encapsulated, cohesion is not as high
– A symptom of multiple concepts – diff gps of methods accessing diff
subsets of attributes
Cohesion in OO…
• Inheritance cohesion – focuses on why classes are together in a hierarchy
– Two reasons for subclassing – generalization-specialization and reuse
– Cohesion is higher if the hierarchy is for providing generalization-
specialization