Pawan111

3.Object Oriented Systems Development
Life Cycle
 s/w development process -> three transformations, building
high quality s/w -> correspondence, correctness, validation,
verification.
 Object Oriented system development (OOSD) -> OOA, OOD,
prototyping, Implementation –> Component Based
Development & Rapid Application Development(CBD &
RAD), Incremental Testing, Reusability.
• Main goal of this is giving idea of building the s/w by placing
emphasis on the Analysis and Design aspects of the s/w life
cycle.
• Emphasis means intend to promote the building of high
quality s/w.
• s/w industry has suffered a lot on the early stages of the life
cycle.

Life Cycle Software Development Process:
• System development can be viewed as a process.
• With in the process, it is possible to replace one subprocess with a
new one.
• But the new subprocess has the same interface as the old one.
• Each Process can be divided into small, interacting phases into
subprocesses which consists of
• Description of the work to be done.
• Specification of input required for the process.
• Specification of output to be produced.
• Software development process also can be divided into smaller,
interacting subprocesses.
• s/w development process can be viewed as a series of
transformations.
• Here o/p of one transformation becomes the i/p of the subsequent
transformation.

Life Cycle
• Transformation 1:(analysis)
• It translates the users needs into system requirements and
responsibilities.
• In this the system can provide insight into the users
requirements.
• Transformation 2:(design)
• It begins with a problem statement and ends with detailed
design.
• It can be transformed into an operational system.
• In this transformation it includes the bulk of the s/w
development activity.
• That means it includes the definition of how to build the s/w, it’s
development, testing, and design descriptions.
• Also includes the program & the testing materials.

Life Cycle
• Transformation 3:(implementation)
• It refines the detailed design into the system deployment.
• It will satisfy the users needs.
• It includes the equipment, procedures, people.
• It represents embedding the s/w product within it’s operational
environment.
User needs
Problem,
statements,
analysis
Design,
Implementation,
Details
System, software,
product
Transformation 1
Transformation 2
Transformation 3
SEQUENCE OF TRANSFORMATIONS

3.Object Oriented Systems Development Life
Cycle
• s/w development process mainly based on Water fall approach.
a. Decide what is the problem?
b. Decide how to accomplish the requirement’s determined.
c. Do it.
d. Test the result.(if user’s requirement are satisfied)
e. Finally Use what we’ve done.
What
How
Do It
Test
Use

Life Cycle

3.Object Oriented Systems Development Life Cycle
1. Correspondence measures how well the delivered system
matches the needs of the problem.
2. Validation is the task of predicting correspondence.
3. Correctness measures the consistency of the product
Needs Requirements Design Software
Validation
Verification
Correctness
Correspondence

Life Cycle
• Correctness is always objective & Validation is always subjective.
• Boehm observes the difference b/w the Verification & Validation
as:
• Verification : Am I building the product right?
• Validation : Am I building the right product?
• Validation begins as soon as the project starts.
• But Verification can begin only after a specification has been
accepted.
• These’re independent of each other.

Cycle
 OO Analysis – Use Case Driven:
• Mainly concerned with determining the system requirements &
identifying classes and their relationship to other classes in the
problem domain.
• To determine sys. Requirements, we need to identify the user’s
or the actor’s.
• For that , Ivar Jacobson had brought the concept of Use Case.
• A Use Case is a typical interaction between a user and a system.
• It captures user’s goals & needs.
• The intersection among objects, roles to achieve a given goal is
known as Collaboration.
• Focusing on high level processes and interactions with
customers in a scenario & analyzing is referred to as Use Case
modeling.

Cycle
• Once our Use Case model is well understood and
developed, we should start to identify classes and
create their relationship’s.
• Interaction between objects in a particular context is
given in collaboration diagram.
• Msg. exchanged among objects with in the
collaboration to achieve the desired outcome.
• Sequence is indicated by numbering the msg.
• Documentation is another important activity.
• It does not end with Object Oriented Analysis, but it
should be carried out throughout the system
development.

Life Cycle
• Make the Documentation as short as possible.
• For that we’re applying 80 – 20 rule for
documentation.
• That is 80 percent of the work can be done with 20
percent of the documentation.
• Documentation & Modeling are not separate
activities.
• So good modeling can make up good
documentation.

Cycle
 Object Oriented Design:
• Main goal of OOD is to design the classes identified
during the analysis phase and the user interface.
• During this phase, we identify and define additional
objects and classes that support implementation of
the requirements.
• Some activities are:
• Design & refine classes.
• Design & refine attributes
• Design & refine methods.
• Design & refine structures.
• Design & refine associations.

3.Object Oriented Systems
Development Life Cycle
• Few guidelines to use in our object oriented
design:
• Reuse, rather than build a new class. Know
the existing classes.
• Design a large number of simple classes ,
rather than a small number of complex
classes.
• Design methods.

Cycle
 Prototyping:
• A prototype is a version of a s/w product developed in
the early stages of the product’s life cycle for specific,
experimental purposes.
• A prototype enables us to fully understand how easy
or difficult it will be to implement some of the
features of the system.
• Also given a chance to the user to comment on the
usability & usefulness of User Interface Design (UID).
• Prototyping provides the developer a means to test
and refine the user interface and increase the
usability of the system.

Cycle
• Prototyps can be categorized into many ways:
1. Horizontal prototype
2. Vertical prototype
3. Analysis prototype
4. Domain prototype
• Horizontal prototype:
• It is a simulation of the user interface. (i.e) it has the entire
user interface that’ll be in the full featured system.
• But it contains no functionality.
• Adv: very easy to implement good overall feel of the sys.
• Allowing the user to evaluate UI based on the expectation
or needs.

Cycle
• Vertical prototype:
• It is a subset of the system features with complete
functionality.
• Adv: few implemented functions can be tested in
great depth.
• Analysis prototype:
• It is an aid for exploring the problem domain.
• Adv: This is used to inform the user and
demonstrate the proof of a concept.

Life Cycle
• Domain prototype:
• It is an aid for the incremental development of the
ultimate sw solution.
• Adv: used as a tool for the staged delivery of
subsystems to the user’s or other members of the
development team.
• Overall prototyping is a useful one at almost
any stage of the development.

Life Cycle
• Object Oriented Implementation:
• Computer Aided Software Engineering (CASE) tools
is only the skeleton of an application.
• New generation of CASE tools support component
based development (CBD).
• Implementation:
a.CBD-Component based development
b.RAD-Rapid application development

Cycle
• CBD:
• This’s an industrial approach to the s/w.
• In this, application development moves from custom
development to assembly development.(i.e.)
prebuilt, pretested & reusable s/w components.
• Two basic ideas:
1.Application development can be improved
significantly if applications can be assembled quickly
from pre s/w components.
2.Large collection of interpretable s/w components
can be easily available to the developer’s in both
general & specialist catalogs.

Cycle
• CBD developer can assemble components to construct a
complete s/w system.
• s/w are assembled from components from the variety of
constructed components written in several diff. languages &
run on several diff. platform advantages.
• Simplicity:
• Replacing components to produced stepwise improvement.
• Integration:
• Inserting additional components to create new tasks & next
transformation.
• Disassembling: The components based on the sys.needs

Cycle
• RAD:
• It’s a quick & dirty prototype used to build an
application faster than other traditional methods.
• To achieve RAD, developer sacrifices the quality of the
product for a quicker delivery.
• RAD does not replace the system development life
cycle but complement’s it.
• Main objective of RAD is to build a version of an
application rapidly to see whether they actually have
understood the problem.(i.e.) Analysis.
• Further it determines whether the system does what
it’s supposed to do.(i.e.) Design.

Life Cycle
• RAD involves a number of iterations.
• Through each iteration we can understand the
problem a little better and make an improvement.
• RAD encourages the incremental development
approach.
• Prototyping & RAD do not replace the object
oriented software development model.
• Instead , in a RAD application, we go through stages
in a rapid (incomplete) fashion, completing more in
the next iteration of the prototype.

Life Cycle
• Incremental testing:
• Testing is a process with a intent of finding error’s.
• If we wait until after development to test an
application, we'd be wasting a lot of time & money.
• The problem was that developers would turn over
applications to a quality assurance (QA) group for
testing only after development was completed.
• Since the QA group wasn’t included in the initial plan,
it had no clear picture of the system characteristics
until it came time to test.
• Do the test case, it provides reliability, reduced time &
cost and improve consistency.

Cycle
 Reusability
– A major benefit of object-oriented systems
development is reusability, and this is the most
difficult promise to deliver on.
 Reuse strategy
– Information hiding (encapsulation).
– Conformance to naming standards.
– Creation and administration of an object repository.
– Encouragement by strategic management of reuse as
opposed to constant redevelopment.

Life Cycle
– Establishing targets for a percentage of the objects in
the project to be reused (i.e.,50 percent reuse of
objects).
 The essence of the software process is the
transformation of users‘ needs into a software
solution.
 The O-O SDLC is an iterative process and is
divided into analysis, design , prototyping /
implementation, and testing.

4.Object Oriented Methodologies
 Rumbaugh Object Modeling Technique:
• Object model
• OMT Dynamic model
• OMT Functional model
 Booch Methodology:
• Macro development process
• Micro development process
 Jacobson methodologies:
• Use Cases
• Object Oriented S/w engineering
• Object Oriented Business Engineering

 Patterns:
• Generative & Non generative patterns
• Patterns template
• Antipatterns
• Capturing patterns
 Frameworks
 Unified approach
• OOA
• OOD
• Iterative development & continuous testing
• Modeling based on UML
• UA protocol repository
• Layered approach:
Business layer
User interface layer
Access layer

• For system development many methodologies are
available.
• Each object oriented methodology is based on modeling
the business problem & implementing the application
only in an object oriented fashion.
• Small variant or differences only in documentation ,
modeling & notations.
• Rumbaugh, Booch & Jacobson have developed some
methodologies & their modeling notations.
• These are the origin of Unified Modeling Language
(UML).

• Rumbaugh method describes object model or
static structure of system.
• Booch method describes detailed object
oriented design models.
• Jacobson method describes user driven
analysis models.

 Rumbaugh Object Modeling Technique:
• This Object Modeling Technique describes a method
for Analysis, Design & Implementation of a sys. Using
an object oriented technique.
• OMT is fast & intuitive approach for identifying &
modeling objects that making up a system.
• Class attributes, methods, inheritance & association
can be expressed easily using object model.
• Dynamic behavior of objects with in a system can be
described using OMT Dynamic model.
• Process description & consumer – producer
relationships can be expressed using OMT Functional
model.

 Rambaugh methodologies:
• Phases of OMT:
• Analysis
• System Design
• Object Design
• Implementation
• OMT consists of four phases, which can be performed iteratively,
– Analysis: The results are objects and dynamic and functional models.
– System design: The result is a structure of the basic architecture
of the system.
– Object design: This phase produces a design document, consisting
of detailed objects and dynamic and functional models.
– Implementation: This activity produces reusable, extendible and
robust code.

• OMT consists of three parts:
 object model– consists of Object model and Data
dictionary.
Dynamic model– consists of State diagrams and
Event flow diagrams.
Functional model– consists of Data flow and
Constraints.

 Object model:
• This describes the structure of objects in the system.
• That is Identity, Relationships to other objects,
Attributes & Operations.
• OMT object model diagram contains classes
interconnected by association lines.
• Each class represents a set of individual objects.
• Association lines establish relationships among the
classes & represent set of links from objects of one
class to objects of another class.

 OMT object model bank system
Client
First name
Last name
Pin code
Client
Account
Account
Transaction
Account
Number balance
Deposit
Withdraw
Create transaction
Transaction
Trans. Date
Trans. Time
Trans. Type
Amount
Post balance
Checking Account
Withdraw
Checking Savings
Account
Savings Account
Boxes represent classes,
*filled triangle represents specialization,
*association b/w account & transaction
is one to many
• filled circle represents many
• *client & account classes is
one to one relationships.

 OMT Dynamic model:
1. States
2. Transitions
3. Events
4. Actions

• State transition diagram of bank application:
Many
Nothing is selected Account has
been selected
Selected checking
Or savings account
Select checking
account
Select transaction type
(withdraw, deposit, transfer)
Enter the amount
confirmation
Transitions States
Round boxes states, Arrows transitions
Each state receives
one or more events,
at which time it makes
the transition to next
state.
Next state depends on
the current state
as well as the events.

 OMT functional model:
 OMT data flow diagram (DFD) shows the flow of
data b/w different processes in a business.
 DFD how data is processed by a sys. In terms of
i/p’s & o/p’s.
 OMT DFD provides simple & intuitive method.
 It describes business processes without focusing
on details of computer systems.

 DFD consists of four symbols:
1. Process : any function being performed. For example
verify Password or PIN in ATM system.
2. Data flow: direction of data element movement. E.g.:
PIN code.
3. Data store: location where data are stored. E.g.:
account is a data store in ATM.
4. External entity: source or destination of a data
element. E.g.: ATM card reader.

 Rambaugh OMT methodology provides
strongest tool sets for analysis and design of
object oriented systems.

 Booch Methodology
– The Booch methodology covers the analysis and design
phases of systems development.
– Booch sometimes is criticized for his large set of
symbols.
– The Booch method consists of the following diagrams:
• Class diagrams
• Object diagrams
• State transition diagrams
• Module diagrams
• Process diagrams
• Interaction diagrams

Car
Color
Manufacturer
cost
Escort
Ford
Mustang Taurus
inherits
inherits
superclass
Object modeling diagram using
Booch notation.
Arrows represent specialization.
e.g. the class Escort is subclass of the class
Ford.

 Booch’s object oriented design is also known as Object
Oriented Analysis and Design (OOAD).
 This’s one of the precursor of Unified Modeling
Language (UML).
 Booch dynamic diagrams corresponds to in UML.
 State transition diagram corresponds to State chart diagram
in UML.
 Interaction diagram corresponds to Sequence diagram in
UML.
 Module diagram corresponds to Component diagram in UML.
 Process diagram corresponds to deployment diagram in UML.
 Module diagram & Process diagram illustrate the physical
design of our application.

 State chart diagram in UML (State transition
diagram)

State
Event or Action
Initial State
Final State

synchronization
(2 transitions
entering into it)
Splitting of control
(2 transitions
leaving it &
Creates multiple
States)

 Sequence diagram in UML (Interaction diagram):
 It describes interactions among classes in terms of an
exchange of messages over time.
 Class roles:
 Messages :
 Messages are arrows, represent communication b/w objects.
 Use half arrowed lines, represent Asynchronous messages.
 i.e. Asynchronous messages are sent from an object & that’ll
not wait for a response from receiver before continuing it’s
tasks.
object: class

 Symbols for Message type:

Simple
Synchronous
Asynchronous

 Component diagram (Module diagram):
 It describes the organization of physical
components in a system.
 Symbols:
 Component  physical building block of the system.
 Interface describes group of operations used.
component Rectangular with tabs

 Dependencies :
component
component
component
----
----
dependency

 Deployment diagram (Process diagram):
 Depict the physical resources in a system including
nodes, components & connections.
 Symbols:
 Node: physical resources that executes code
components.
Node name

 Association:
 Physical connection b/w nodes. E.g. Ethernet.
Node Node

 Components & Nodes:
 Place components inside the node that deploys them.
component
component
Server

 The Booch methodology prescribes
– A macro development process
– A micro development process.
 Macro development process:
 It serves as a controlling framework for micro process.
 For the period of more than a week & months.
 Primary concern of macro process is technical
management of the system.
 But this technical management is less interested in
object oriented design.

 Rather it’ll concentrate more on how the project
corresponds to requirements & whether it’ll be
produced on time.
 In macro process traditional phases of analysis &
design are preserved to a large extent.
 Macro development process consists of five steps:
1.Conceptualization
2.Analysis and development of the model
3.Design or create the system architecture
4.Evolution and implementation
5.Maintenance

 Conceptualization:
 During Conceptualization we’ve to establish the core
requirements of the system.
 We’ve to establish a set of goals & develop some prototype to
prove the concept.
 Analysis and development of the model:
 In this stage, we use the class diagram.
 Class diagram used to describe the roles and responsibilities of
the objects that are carry out to perform the behavior of the
system.(or)
 Object diagram used to describe the behavior of system in
terms of scenarios.(or)
 Interaction diagram used to describe the same as object
diagram.

 Design or create the system architecture:
 At design stage, we use the class diagram.
 Here Class diagram used to describe what classes exists & how
they relate to each other.
 Next we use object diagram, used to describe what
mechanisms are used to regulate the collaboration of objects.
 Next we use Module diagram, used to map out where each
class & object should be declared.
 Finally we use process diagram, used to determine which
processor to allocate a process.
 Process diagram is also used to determine the schedules for
multiple processes on each relevant processor.

 Evolution and implementation:
 In this phase, we’re successively refine the system
through many iterations.
 Each refinement of prior one by producing a stream of
s/w implementation.
 Maintenance:
 Some localized changes are made to the system to add
new requirements & eliminate bugs.

 The Micro Development Process:
 Each macro development process has it’s own
micro development processes.
 Micro process having the description of day to day
activities by a single or small group of s/w
developers.
 Since analysis and design phases are not clearly
defined.

 The micro development process consists of
the following steps:
 Identify classes and objects.
 Identify class and object semantics.
 Identify class and object relationships.
 Identify class and object interfaces and
implementation.

 Jacobson Methodologies:
 The Jacobson et al. methodologies (e.g., OOBE, OOSE,
and Objectory ) cover the entire lifecycle and stress
traceability between the different phases.
 Here traceability means reuse of analysis & design
work.
 It’ll reduce the development time than reuse of code.
 Heart of this methodology is use case concept.

 Use Case concept:
 Use cases are scenarios for understanding sys.
requirements.
 Use case describes the interaction b’w users &
system.
 Use case model captures the goal of the user &
the responsibility of system to it’s users.

 In requirement analysis, use cases are described
as any one of the following:
• Non formal text, with no clear flow of events.
• Text, easy to read with clear flow of events.
• Formal style, using pseudo code.
 Use case description must contain:
a.How & when the use case begins & ends.
b.When the interaction occurs and what is going to be
exchanged b/w the use case and it’s actors should be
included.
c.How and when the use case will need data store in the
sys.
d.Exceptions to the flow of events.
e.How and when the concepts of the problem domain

 Every single use case should describe one main
flow of events.
 Exceptional or additional flow of events could be
added.
 Extends relationship is used when we have one
use case that is similar to another use case.
 It extends the functionality of original use case
that is it does a bit more (like subclass).

 Abstract use case  use cases could be viewed as
abstract use case.
 It’s not complete & has no actors that initiate it.
 It’s used by another use case.
 This inheritance used in different levels.
 Abstract use case have uses or extends
relationship.

 Object-Oriented Software Engineering: Objectory
– Object-oriented software engineering (OOSE), also
called Objectory, is a method of object-oriented
development with the specific aim to fit the
development of large, real-time systems.
– OOSE also known as object factory for system
development.
– It follows the concept of modern UML.
– i.e. Modeling language & methodology.
– Development process called use case driven
development includes Analysis, Design, Validation &
Testing.

 Objectory is built around several different
models:
– Use case model.
– Domain object model.
– Analysis object model.
– Implementation model.
– Test model

Use case
diagram
Analysis
diagram
State
transition
diagram
Interaction
diagram
Program
diagram

 In this we can use RUP – Relational Unified
Process.
 OOSE tools have been replaced by UML & RUP
tools.
 Objectory is built around several different models:
 Use case model:
 Use case model defines the outside & inside of
system’s behavior.
 Domain object model:
 Provides the logical view of a system used to
specify the use cases for use case diagram.

 Problem domain object model diagram:
 Interaction b/w users.
obj obj
obj obj

 E.g.. For use case  quiz system.
Quiz system
Requestration
Viewing the question
Answering the
question
Validation
Final score
Quiz system
viewer

 Analysis model:
 Defines the three object in a system.
 Entity object information about the object.
 Control object illustrate the functionality of object.
 Interface object interact directly with an
environment.
 Design model:
 State transition diagram
 Interaction diagram

 State transition diagram:
 Similar to UML state chart diagram.
 It shows the flow of events with in the system.
 Jacobson’s method also user Unix symbols.
 Interaction diagram:
 Similar to UML sequence diagram.
 Shows the step by step happenings to accomplish
a particular functionality.

 Jacobson’s symbols:
Send msg
Receive a msg
Return a msg
Send a signal
Receive a signal
Process
Decision
Label

 Implementation model:
 Represents the implementation of a system,
finally test model represent test cases,
specification & report.

 Object-Oriented Business Engineering (OOBE):
• Object-oriented business engineering (OOBE)
is object modeling at the enterprise level.
• Use cases again are the central vehicle for
modeling.
• It provides traceability throughout the
software engineering processes.

 OOBE consists of
– Analysis phase
– Design Implementation phases
– Testing phase.
 Analysis phase:
 Analysis phase defines the system in terms of problem
domain object model, requirement model & analysis
model.
 This reduces the complexity & promotes maintainability
over the life of the system.
 Analysis process is iterative.
 But requirements & analysis model should be stable
before moving on to subsequent models.

 Design Implementation phases:
 Implementation environment must be identified for
design model.
 It includes Database Management System, distribution of
process, available component libraries & graphical user
interface tools.
 Testing phase:
 Several testing levels & techniques are described by
Jacobson.
 This phase includes unit testing, integration testing &
system testing.

 Patterns:
 A pattern is an instructive information that captures
the essential structure and insight of a successful
family of proven solutions to a recurring problem that
arises within a certain context and system of forces.
 The main idea behind using patterns is to provide
documentation to help categorize and communicate
about solutions to recurring problems.
 The pattern has a name to facilitate discussion and the
information it represents.

 A good pattern will do the following:
 It solves a problem
 Patterns capture solutions, not just abstract
principles or strategies.
 It is a proven concept
 Patterns capture solutions with a track record, not
theories or speculation.
 The solution is not obvious
 The best patterns generate a solution to a problem
indirectly- a necessary approach for the most difficult
problems of design

 It describes a relationship
 Patterns do not just describe modules, but
describe deeper system structures and
mechanisms.
 The pattern has a significant human
component .
 All software serves human comfort or quality of
life; the best patterns explicitly appeal to
aesthetics and utility.

 More recent patterns encompass all aspects of
software engineering, s/w development process,
project planning, requirements engineering & s/w
configuration management.
a. Generative & Non generative patterns
b. Pattern template
c. Antipatterns

 Generative patterns:
 It not only a recurring problem, it can tell us how to generate
something & can be observed in the resulting system
architecture.
 Non generative patterns:
 Static & passive.
 It’ll describe recurring phenomena without necessarily saying
how to reproduce them.
 Patterns template:
 Every pattern must be expressed in the form of a rule which
establishes a relationship b/w a context.
 It allows to resolve themselves in that context.
 Here template  nothing but a rule.

 Different patterns template are:
1. Name
2. Context
3. Forces
4. Solution
5. Problem
6. Examples
7. Related patterns

 Antipatterns:
 Patterns represents a best practice.
 Antipatterns represents a worst practice.
 Antipatterns come in two ways:
1.Those describing a bad solution to a problem that
resulted in bad situation.
2.Those describing how to get out of a bad situation &
how to proceed from there to a good solution.
 Antipatterns are valuable one, because often it’s
used to see & understand the bad solution & also
see & understand the good ones.

 Capturing patterns:
 Patterns should provide not only facts, but it also tell
a story that captures the experience they are trying to
convey.
 A pattern should help it’s users,
 comprehend existing systems
 Customize systems to fit user needs
 Construct new systems
 The process of looking for patterns to document is
known as pattern mining.

 Some guidelines:
 Focus on practicability:
 Patterns should describe proven solutions to recurring
problems rather than the latest scientific results.
 Aggressive disregard of originality:
 Pattern writers do not need to be the original inventor or
discoverer of the solutions that they document.
 Non anonymous review:
 Pattern submissions are shepherded rather than reviewed.
(a person who guides, or watches).
 The shepherd contacts the patterns author and discusses
with him or how the patterns might be clarified or
improved on.

 Writer’s workshops instead of presentations:
 Rather than being presented by the individual authors,
the pattern authors and discusses in writers
workshops,
 open forums where all attending seek to improve the
patterns presented by discussing what they like about
them and the areas in which they are lacking.
 Careful editing:
 The pattern authors should have the opportunity to
incorporate all the comments and insights during the
shepherding and writers workshops before presenting
the patterns in their finished form.

 Frameworks:
 A framework is a way of presenting a generic solution
to a problem that can be applied to all levels in a
development.
 A single framework typically encompasses several
design patterns and can be viewed as the
implementation of a system of design patterns.
 It is important to recognize that framework & design
patterns are two distinctly separate beasts.

 Framework is executable software & design
patterns represent the knowledge and experience
about software.
 Frameworks are the physical realization of one or
more software pattern solutions.
 Patterns are the instructions for how to
implement those solutions.

 Differences Between Design Patterns and
Frameworks:
 Design patterns are more abstract than
frameworks.
 Design patterns are smaller architectural
elements than frameworks.
 Design patterns are less specialized than
frameworks.

 The Unified Approach
 The idea behind the UA is not to introduce yet
another methodology.
 The main motivation here is to combine the best
practices, processes, methodologies, and
Guidelines along with UML notations and
diagrams.
 UA establishes a unifying & unitary framework
around their works by utilizing the Unified
Modeling Language (UML).
 It’ll be better understanding object oriented
concepts & system development.

 Motivation of UA:
 Here Booch, Rambaugh & Jacobson methods has it’s
strength & weakness.
Rambaugh Objectmodel Cannot fully
express the
requirements
Jacobson User driven
requirement &
OO analysis
model
Not for design
Booch Detailed OO
Design
Not for analysis

So motivation of UA is to combine all the
three methodologies strength along with UML
notation for better understanding OO
concepts & system development.

 The Unified Approach (UA)
 The unified approach to software development
revolves around (but is not limited to)the
following processes and components.
 The UA processes are:
– Use-case driven development.
– Object-oriented analysis.
– Object-oriented design.
– Incremental development and prototyping.
– Continuous testing

 UA Methods and Technology
 Unified modeling language (UML) used for
modeling.
 Layered approach.
 Repository for object-oriented system
development patterns and frameworks.
 Promoting Component-based development.

Processes & Components of Unified Approach

 UA Object-Oriented Analysis: Use-Case
Driven:
 The use-case model captures the user
requirements.
 The objects found during analysis lead us to model
the classes.
 The interaction between objects provide a map
for the design phase to model the relationships
and designing classes.

• UA Object-Oriented Design:
 Booch provides the most comprehensive object-
oriented design method.
 However, Booch methods can be somewhat
imposing to learn and especially tricky to figure
out where to start.
 UA realizes this by combining Jacobson et al.'s
analysis with Booch's design concept to create a
comprehensive design process.

 Iterative Development and Continuous
Testing:
 The UA encourages the integration of testing
plans from day 1 of the project.
 Usage scenarios or Use Cases can become test
scenarios; therefore, use cases will drive the
usability testing

 Modeling Based on the Unified Modeling
Language:
 The UA uses the unified modeling language (UML)
to describe and model the analysis and design
phases of system development.

 The UA Proposed Repository:
 The requirement, analysis, design, and
implementation documents should be stored in
the repository, so reports can be run on them for
traceability.
 This allows us to produce designs that are
traceable across requirements, analysis, design,
implementation, and testing.

 The Layered Approach to Software
Development:
 Most systems developed with today's CASE tools
or client-server application development
environments tend to lean toward what is known
as two-layered architecture: interface and data
workstation Data

 Two-Layer Architecture:
 In a two-layer system, user interface screens are
tied directly to the data through routines that sit
directly behind the screens.
 Problem with the Two-Layer Architecture:
 This approach results in objects that are very
specialized and cannot be reused easily in other
projects.

 Three-Layer Architecture:
 Using three layered architecture , we’re able to
create objects that represents tangible elements
of our business,
 Yet are completely independent of how:
 they are represented to the user (through an
interface) or
 how they are physically stored(in a database).

 Three layered approach consists of
 View or User interface layer
 Business layer
 Access layer
 User Interface layer:
 This layer consists of objects with which the user
interacts as well as the objects needed to manage
or control the interface.
 Also known as view layer.

Access Layer
Business
Layer
View Layer
Three-Layered Architecture

 This layer is typically responsible for two major
aspects of the applications:
 Responding to user interaction
 Displaying business objects.
 Responding to user interaction:
 The user interface layer objects must be designed to
translate actions by the user, such as clicking on a
button or selecting from a menu, into an appropriate
response.
 Displaying business objects:
 This layer must paint the best possible picture of the business
objects for the user. e.g. list boxes & graph.

 Use cases can provide a very useful tool for understanding user
interface requirements.
 User interface layer’s objects are identified during the object
oriented design phase.
 Business layer:
 Layer contains all the objects that represent the business (both
data & behavior).
 Responsibilities of the business layer are very straight forward:
 Model the objects of the business and how they interact to
accomplish the business processes.
 When creating the business layer, there’re two important
things to note:
• Displaying details
• Data access details

 Displaying details:
 Business objects should have no special knowledge of
how they are being displayed and by whom.
 They are designed to be independent of any particular
interface, so the details of how to display an object is
exists in the interface layer of the object displaying it.
 Data access details:
 Business objects also should have no special knowledge
of where they come from.
 It does not matter whether data are stored and
retrieved via SQL or file I/O.
 Business objects need to know only to whom to talk
about being stored or retrieved.

 Business model captures of static and dynamic
relationships among a collection of business
objects.
 Static relationships includes object associations
and aggregations.
 Dynamic relationships show how the objects
interact to perform tasks.
 Use cases can provide a tool to capture business
objects.
 Business objects are identified during object
oriented analysis phase.

 Access layer:
 Layer contains objects that know how to communicate with the
place where the data actually reside.
 Whether it be a relational database, mainframe, internet or
file.
 Access layer has two major responsibilities:
• Translate request
• Translate results
 Translate request:
 The access layer must be able to translate any data
related requests from the business layer into the
appropriate protocol for data access.
 For example, if customer number 102356 needs to be
retrieved, access layer must be able to create the

 Translate results:
 The access layer also must be able to translate the data
retrieved back into the appropriate business objects and pass
those objects back up into the business layer.
 Access objects are identified during object oriented
design phase.

5.Unified Modeling Language
 A model is an abstract representation of a system, constructed to
understand the system prior to building or modifying it.
 Most of the modeling techniques involve graphical languages.
 Static or Dynamic Models:
Static Dynamic Model
A static model can be
viewed as “snapshot" of a
system's parameters at
rest or at a specific point
in time.
Is a collection of
procedures or behaviors
that, taken together,
reflect the behavior of a
system over time.
The classes‘ structure and
their relationships to each
other frozen in time are
examples of static models.
For example, an order
interacts with inventory to
determine product
availability.

 Why Modeling?
 Models make it easier to express complex ideas.
 For example, an architect builds a model
to communicate ideas more easily to clients.
 Advantages of Modeling:
 Models reduce complexity by separating those
aspects that are unimportant from those that are
important.
 Models enhance learning.
 The cost of the modeling analysis is much lower than
the cost of similar experimentation conducted with a
real system

 Manipulation of the model (changing variables) is
much easier than manipulating areal system.
 Modeling Key Ideas:
 A model is rarely correct on the first try.
 Always seek the advice and criticism of others.
 Avoid excess model revisions, as they can distort
the essence of your model. Let simplicity and
elegance guide us through the process.

 What Is the UML?
 The Unified Modeling Language (UML) is a
language for
 Specifying
 Visualizing
 Constructing
 Documenting the software system and its
components

 What UML is/isn’t?
 Is NOT
 A process
 A formalism
 Is
 A way to describe your software
more precise than English
less detailed than code

 What is UML Used For?
Trace external interactions with the software.
Plan the internal behavior of the application.
Study the software structure.
View the system architecture.
Trace behavior down to physical components.

 UML Diagrams
 The UML defines nine graphical diagrams:
1. Class diagram (static)
2. Use-case diagram
3. Behavior diagrams (dynamic)
 3.1. Interaction diagram
• 3.1.1. Sequence diagram
• 3.1.2. Collaboration diagram
 3.2. State chart diagram
 3.3. Activity diagram
4. Implementation diagram
 4.1. Component diagram
 4.2. Deployment diagram

 Use Case Diagram:
 Use case diagrams are created to visualize the
relationships between actors and use cases.
 An actor is someoneor some thing that must
interact with the system under development.
 A use case is a pattern of behavior the system
exhibits.
 Use cases are written from an actor point of view.
 Details what the system must provide to the actor
when the use cases is executed.

 Class Diagram
 A class diagram describes the types of objects in the
system and the various kinds of static relationships
that exist among them.
 A graphical representation of a static view on
declarative static elements.
 A central modeling technique that runs through nearly
all object-oriented methods.
 The richest notation in UML.
 A class diagram shows the existence of classes and
their relationships in the logical view of a system.

 Essential Elements of a UML Class Diagram
 Class
 Attributes
 Operations
 Relationships
• Associations
• Generalization
 Dependency
 Realization

Pawan111

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (16)

Similar to Pawan111

Similar to Pawan111 (20)

More from ranjeetdon

More from ranjeetdon (7)

Pawan111