Outline

Ú Object Oriented Concepts

and principals
Ú Object Oriented Analysis
Ú Object Oriented Design
ntroduction
Ú •e live in a world of objects
Ú Object-Oriented view is an abstraction
that models the world in ways that help
us to better understand and navigate it
Ú OO approach was first proposed in the
late 1960s
Ú As time passes, object technologies are
replacing classical software development
approaches. •hy?
Ú Object technologies lead to reuse, OO
software is easier to maintain, to adapt,
and to scale.
OO Paradigm
Ú îor many years, the term OO was used to
denote a software development approach
that used one of a number of OO
programming languages(e.g. Ada 95, C++,
Eiffel, Smalltalk)
Ú Today, the OO paradigm encompasses a
complete view of software engineering
Ú Although any one of process models, could
be adapted for use with OO, the best
choice would be an evolutionary process
model
¦ e OO Process Model

 

 
ë







  ë


  
ë
Æ
 
ë   
Æ 



  
ë ë

ë     ëë




ë
Æ
    
 ëë


 Æ
 



ë 
 

  



OO Concepts
Ú Classes and class hierarchies
P Instances
P Inheritance
P Abstraction and hiding
Ú Objects
P Attributes
P Methods
P Encapsulation
P Polymorphism
Ú Messages
Object

The object encapsulates

both data and the logical
procedures required to method
method
manipulate the data #1 #2
data

method
#6

method method
#5 #4

Achieves ³information hiding´

Polymorp ism
Ú It is a characteristic that greatly reduces
the effort required to extend an existing
OO system.
Ú Polymorphism enables a number of
different operations to have the same
name.
Ú îor example: drawing different type of
graphs( e.g. Line, Pie, Histogram )
Ú It decouples objects from one another
making each more independent.
Ú General class graph and one subclass
for each type.
Messages
sende  ec

 es:

ece e obec

 bues:
ope  ons:

ope  ons:

message:
[sender, return value(s)]

message: [receiver, operation, parameters]

Modeling Dimensions
1. Identification/classification of entities.
2. General-to-specific and whole-to-part entity
relationships
¦he modeling
3. Other entity relationships dimensions 8 and 9
4. Description of attributes of entities are always present
with SA.
5. Large-scale model partitioning
6. States and transitions between states
7. Detailed specification for functions
8. Top-down decomposition
9. End-to-end processing sequences
10. Identification of exclusive services
11. Entity communications (via messages or events)
Conventional vs. OO Approac es
Ú Is OO analysis really different from the
structured analysis approach?
P A radical change over process oriented (SA).
P An incremental change over data oriented
methodologies (IE).
Ú Structured Analysis (SA):
P takes a distinct input-process-output view of
requirements.
P Data are considered separately from the
processes that transform the data.
P System behavior tends to play a secondary
role.
P makes heavy use of functional
decomposition.
¦ e OOA Landscape
Ú Dozens of OOA method during the late 1980s and into
the 1990s are introduced.
Ú Each of them proposed:
P A process for the analysis of the product or system
P A set of diagrams that evolved out of the process.
P A notation that enabled the software engineer to create the
analysis model in a consistent manner.
Ú The most widely use were:
P The Booch method ( an evolutionary approach is
maintained).
P The Rumbaugh method (Object modeling technique
(OMT))
P The Jacobson method (OO Software Engineering (OOSE))
P The Coad and Yourdon method (One of the easiest)
P The •irfs-Brock method (do not make clear distinction
between design and analysis tasks)
OOA & OOP
Ú OOA is based upon OOP: Classes and
members, Objects and attributes and so on
Ú To define them following tasks should be done:
P Basic user requirements should be communicated
between customer and software engineer
P Classes must be identified
P Class hierarchy should be specified
P Object to object relationship should be presented
P Object behavior should be modeled
P These task should be reapplied iteratively until
model is complete
èeneric Steps for OOA
1. Elicit customer requirements for the
system.
2. Identify scenarios for use-cases.
3. Select classes and objects using basic
requirements as a guide.
4. Identify attributes and operations for each
system object.
5. Define structures and hierarchies that
organize classes.
6. Build an object-behavior model.
7. Review the OO analysis model against
use-cases or scenarios.
A Unified Approac to OOA
Ú Grady Booch, James Rumbaugh and Ivar Jacobson
combine the best features into a unified method called:
Unified Modeling Language (UML)
Ú UML allows a software engineer to express and
analysis model using a modeling notation that is
governed by a set of Syntactic, Semantic, and
Pragmatic rules.
P The syntax tells us how the symbols should look
and how they are combined. (•ord in natural
language)
P The semantics tells us what each symbols means
and how it should be interpreted. (Meaning of words
in natural language)
P The pragmatic rules define the intentions of the
symbols through which the perpose of the model is
achieved and become understandable. (The rules
for constructing sentences that are clear and
understandable in natural language)
UML and Analysis Views
Ú User model view. This view represents the system (product)
from the user¶s (called ³actors´ in UML) perspective.
Ú Structural model view. Data and functionality is viewed from
inside the system. That is, static structure (classes, objects,
and relationships) is modeled.
Ú Behavioral model view. This part of the analysis model
represents the dynamic or behavioral aspects of the system.
Ú Implementation model view. The structural and behavioral
aspects of the system are represented as they are to be
built.
Ú Environment model view. The structural and behavioral
aspects of the environment in which the system is to be
implemented are represented.

Ú UML analysis modeling focuses on the first two views of the

system.
Ú UML design modeling addresses the other three views.
Domain Analysis
Ú OO Analysis can occur at many different levels of
abstraction:
P At the business or enterprise level
P At the business area level
P At an application level
Ú OOA at the middle level called Domain Analysis.
Ú Domain Analysis is performed to create a library of
reusable classes applicable to an entire category
of applications.
Ú Using a robust class library produces the system
faster, cheaper and more reliable.
Ú But where did such a library come from? By
applying domain analysis.
Domain Analysis Process
Ú ¦ e oaë:o ndo c eae osecëasses aa eb oadë appë cabëe,
so a ey aybe eused.
Ú Icanbe ewedasanumb eëëaac yo  esowa ep ocess.
Ú ¦ e oëeodoma nanaëys sodes nandbu ëd eusabëe
componens amaybeusedbymanypeopëewo ngons m ëa bu
nonecessa ëy esameappë ca ons.
Ú ey npusandoupuso  edoma nanaëys sp ocess:

class taxonomies
technical literature
S S  reuse standards g
AIN
g
AIN existing applications g
AIN ANALYSIS
KN Lg ANALYSIS functional models
gL
customer surveys
domain languages
expert advice

current/future requirements
Domain Analysis Activities (1)
Ú Define the domain to be investigated.
P Isolate the business area, system type, product category
P Extract both OO and non-OO items.
ż OO-items such as: application and support (GUI, DB) classes,
Commercial off-the-shelf (COTS) component libraries and test
cases.
ż Non-OO items such as: policies, procedures, plans, standards
and guidelines; parts of existing non-OO applications, metrics
and COTS non-OO software.
Ú Categorize the items extracted from the domain.
P Organize items into categories.
P Define the general defining characteristics of the
categories.
P Propose a classification scheme for the categories.
P Define naming conventions for each item.
P Establish classification hierarchy when appropriate.
Domain Analysis Activities (2)
Ú Collect a representative sample of applications in
the domain.
P Ensure that the application has items that fit into
categories.
Ú Analyze each application in the sample.
P Identify candidate reusable objects.
P Indicate the reasons that the object has been identified for
reuse.
P Define adaptions to the object that may also be reusable.
P Estimate the percentage of applications in the domain that
make reuse of the object.
P Identify the object by name and use configuration
management techniques to control them (chapter 9).
Ú Develop an analysis model for the objects.
P As a basis for design and construction of domain objects.
OOA- A èeneric View
Ú define use cases
Ú extract candidate classes
Ú establish basic class relationships
Ú define a class hierarchy
Ú identify attributes for each class
Ú specify methods that service the attributes
Ú indicate how classes/objects are related
Ú build a behavioral model
Ú iterate on the first five steps
¦ e OOA Process
Ú The OOA process begins with an
understanding of the manner in which the
system will be used by:
P People, if the system is human-interactive.
P Machines, if the system is involved in process
control.
P Programs, if the system coordinates and controls
applications
Ú Once the scenario of usage has been defined,
the modeling of the software begins.
Ú A series of techniques may be used to gather
basic customer requirements.
Use Cases
OOD
Ú OOD transforms the analysis model created using
OOA into a design model that serves as a
blueprint for software construction.
Ú OOD results in a design that achieves a number of
different levels of modularity.
Ú Subsystems: Major system components.
Ú Objects: Data and the operations.
Ú îour important software design concepts:
P Abstraction
P Information Hiding
P îunctional Independence
P Modularity
OOD
Ú ¦ esubsysemëaye : ˜
 


Representation of each of the


subsystems that enable the
software to achieve its customer 



defined requirements.



Ú ¦ ecëassandobecëaye : 

  



The class hierarchies,
(generalization) and


 



representation of objects.
Ú ¦ emessageëaye :The design
details of communication of each
object with its collaborators.
(external and internal interfaces)
Ú ¦ e espons b ë  esëaye :Data
Structure and algorithmic design
for all attributes and operations.
OOA to OOD

ttri u tes, operation s,

colla orators resp onsi ilities

e ct- design
CRC relation sh ip
Index C ards od el

 ess ag e
U se cases des ign

C la ss an d o
e ct

ect-B eh avio r
des ign
M od e l

su sys te 
des ign

  
¦  L I ML ¦  IG ML
OOA to OOD

n alysis M ood
nalys d el  e sign M odel
classes o
ects
attri u tes d ata struc tures
eth o d s alg orith s
rela tio n s hips
h ips essag in g
ing
e h a v io r co n tro l
Design ssues
Ú decomposability²the facility with which a design method
helps the designer to decompose a large problem into
subproblems that are easier to solve;
Ú composability²the degree to which a design method
ensures that program components (modules), once designed
and built, can be reused to create other systems;
Ú understandability²the ease with which a program
component can be understood without reference to other
information or other modules;
Ú continuity²the ability to make small changes in a program
and have these changes manifest themselves with
corresponding changes in just one or a very few modules;
Ú protection²a architectural characteristic that will reduce the
propagation of side affects if an error does occur in a given
module.
èeneric Components for OOD
Ú Problem domain component²the subsystems that
are responsible for implementing customer
requirements directly;
Ú Human interaction component ²the subsystems
that implement the user interface (this included
reusable GUI subsystems);
Ú Task Management Component²the subsystems
that are responsible for controlling and
coordinating concurrent tasks that may be
packaged within a subsystem or among different
subsystems;
Ú Data management component²the subsystem
that is responsible for the storage and retrieval of
objects.
Process Flow for OOD
System Design Process
Ú %a   on eanaëys smodeë nosubsysems.
Ú Iden yconcu ency a sd caedby e
p obëem.
Ú Aëëocaesubsysemsop ocesso sandasks.
Ú Deveëopades gno  euse  ne ace.
Ú C ooseabas cs aegyo  mpëemen ngdaa
managemen.
Ú Iden ygëobaë esou cesand econ oë
mec an sms equ edoaccess em.
Ú Des gnanapp op aecon oëmec an smo 
 esysem, ncëud ngaskmanagemen.
Ú Cons de  owbounda ycond  onss ouëdbe
andëed.
Ú Rev ewandcons de  ade
Rev ewandcons de  adeos.
System Design
Subsystem Example
Subsystem Design Criteria
Ú ¦ esubsysems ouëd aveaweëë
de ned ne ace oug w c aëë
commun ca onw   e eso e
sysemoccu s.
Ú W   eexcep onoasmaëënumbe o
commun ca oncëasses,´ ecëasses
w  nasubsysems ouëdcoëëabo ae
onëyw  o e cëassesw  n e
subsysem.
Ú ¦ enumbe osubsysemss ouëdbe
kepsmaëë.
Ú Asubsysemcanbepa   oned
ne naëëyo eëp educecompëex y.
Subsystem Collaboration
¦able
Object Design
Ú A ô


 ô

establishes the
interface of an object by defining each
message that the object can receive and
the related operation that the object
performs
Ú An ô


 ô

shows
implementation details for each operation
implied by a message that is passed to an
object.
P information about the object's private part
P internal details about the data structures that
describe the object¶s attributes
P procedural details that describe operations
Design Patterns
Ú add some example