Object Oriented System Design

MODULE:IIIMODULE:III
Object-Oriented Systems DevelopmentObject-Oriented Systems Development
Life CycleLife Cycle
Namita PandaNamita Panda
School of Computer EngineeringSchool of Computer Engineering
KIIT Deemed to be UniversityKIIT Deemed to be University
01/25/1901/25/19 11MODULE-III OOSD Life CycleMODULE-III OOSD Life Cycle

INTRODUCTIONINTRODUCTION
 The essence of theThe essence of the software developmentsoftware development
processprocess that consists of :that consists of :
 AnalysisAnalysis
 DesignDesign
 ImplementationImplementation
 TestingTesting
 RefinementRefinement
is to transform users’ needs into a softwareis to transform users’ needs into a software
solution that satisfies those needs.solution that satisfies those needs.
01/25/1901/25/19 MODULE-III OOSD Life CycleMODULE-III OOSD Life Cycle 22

INTRODUCTION…INTRODUCTION…
 We need not see code until afterWe need not see code until after 25 to 30 %25 to 30 % of theof the
development time.development time. Because ?Because ?
 We need to spend more time in:We need to spend more time in:
 GatheringGathering REQUREMENTSREQUREMENTS,,
 Developing aDeveloping a requirement modelrequirement model
 Developing anDeveloping an analysis model (analysis model (It consists ofIt consists of class diagrams andclass diagrams and
sequence diagramssequence diagrams that describe the logical implementation of thethat describe the logical implementation of the
functional requirements.)functional requirements.)
 Developing aDeveloping a design model(design model(In the design model, packages contain theIn the design model, packages contain the
design elements of the system, such asdesign elements of the system, such as design classesdesign classes,, interfacesinterfaces, and, and
design subsystemsdesign subsystems, that evolve from the analysis classes.), that evolve from the analysis classes.)
 FinallyFinally codecode can be developed quickly.can be developed quickly.
 Emphasize is on building high quality software.Emphasize is on building high quality software.
i.e (Meeting specifications & being adaptable for change.)i.e (Meeting specifications & being adaptable for change.)

THE SOFTWARETHE SOFTWARE
DEVELOPMENT PROCESSDEVELOPMENT PROCESS
 Goals for OOSD:Goals for OOSD:
 The software development processThe software development process
 BuildingBuilding high-qualityhigh-quality softwaresoftware
 Object-orientedObject-oriented systems developmentsystems development
 Use-case drivenUse-case driven systems developmentsystems development
 PrototypingPrototyping
 The system development can be viewed as aThe system development can be viewed as a
process.process.

DEVELOPMENT PROCESS…DEVELOPMENT PROCESS…
 The essence of theThe essence of the software processsoftware process is theis the
transformationtransformation of Users’ needs to the applicationof Users’ needs to the application
domain into a software solution.domain into a software solution.
 The development itself is a process of :The development itself is a process of :
 ChangeChange
 RefinementRefinement
 TransformationTransformation oror
 Addition to existing systemAddition to existing system
 Within the process we can replace oneWithin the process we can replace one subsystemsubsystem
with a new one as long as it has same interfacewith a new one as long as it has same interface..

DEVELOPMENT PROCESS…DEVELOPMENT PROCESS… The process can be divided into small, interactingThe process can be divided into small, interacting
phases –phases – sub processes.sub processes.
 EachEach sub processsub process must have the following:must have the following:
 A description in termsA description in terms how it workshow it works
 Specification of theSpecification of the inputinput required for the processrequired for the process
 Specification of theSpecification of the outputoutput to be producedto be produced
 Software development process can be viewed as aSoftware development process can be viewed as a
series of transformationseries of transformation where:where:
 The output of one transformation becomes the inputThe output of one transformation becomes the input
of the subsequent transformation.of the subsequent transformation.

The Software Development ProcessThe Software Development Process
Need
Problem
Statements
Analysis
Design
Implementation
Detail
System
Software
Product
Transformation 1
Transformation 2
Transformation 3
What are the uses
of the system.?
Needs

The Software Development Process…The Software Development Process…
 Transformation 1 (Analysis):Transformation 1 (Analysis): Translates the users’Translates the users’
need into systems requirements & responsibilities.need into systems requirements & responsibilities.
 Transformation 2 (Design):Transformation 2 (Design): Begins with a problemBegins with a problem
statement and ends with astatement and ends with a detail designdetail design that can bethat can be
transformed into an operational system. (includestransformed into an operational system. (includes
definition ofdefinition of how to build the softwarehow to build the software,, itsits
developmentdevelopment andand its testingits testing.).)
 Transformation 3 (Implementation):Transformation 3 (Implementation): Refines theRefines the
detail design into thedetail design into the system deploymentsystem deployment that willthat will
satisfy the users’ needs.(satisfy the users’ needs.(embedding the softwareembedding the software
product within its operational environmentproduct within its operational environment))

The Software Development Process…The Software Development Process…
What
How
Do It
Test
Use
Traditional
Water Fall
Model

BUILDING HIGH-QUALITY SOFTWAREBUILDING HIGH-QUALITY SOFTWARE
 To achieve high quality in software we need toTo achieve high quality in software we need to
be able to answer the following questions:be able to answer the following questions:
 How do we determine the system isHow do we determine the system is ready forready for
delivery ?delivery ?
 Is it now an operational system thatIs it now an operational system that satisfiessatisfies
users’ need ?users’ need ?
 Is itIs it correctcorrect and operating as we thought itand operating as we thought it
should ?should ?
 Does it pass anDoes it pass an evaluation processevaluation process ??

BUILDING HIGH-QUALITY SOFTWARE…BUILDING HIGH-QUALITY SOFTWARE…
 Two basic approaches for system testing:Two basic approaches for system testing:
 We can test a system according toWe can test a system according to how it has beenhow it has been
builtbuilt oror alternativelyalternatively
 What itWhat it should doshould do ??
 Blum’s four quality measures for systemsBlum’s four quality measures for systems
evaluation:evaluation:
 CorrespondenceCorrespondence
 CorrectnessCorrectness
 VerificationVerification
 ValidationValidation

BUILDING HIGHQUALITY SOFTWAREBUILDING HIGHQUALITY SOFTWARE
 Correspondence :Correspondence : Measures how well the deliveredMeasures how well the delivered systemsystem
matches the needs of the operational environmentmatches the needs of the operational environment, as, as
described in the original requirements statement.described in the original requirements statement.
 Validation :Validation : It is the task of predicting correspondence.It is the task of predicting correspondence.
 Correctness :Correctness : Measures the consistency of the productMeasures the consistency of the product
requirements w.r.t the design specification.requirements w.r.t the design specification.
 Verification :Verification :It is the exercise of determining correctness.It is the exercise of determining correctness.

BUILDING HIGHQUALITY SBUILDING HIGHQUALITY SOFTWAREOFTWARE
 Validation :Validation : Am I building theAm I building the rightright productproduct ??
 Verification :Verification : Am I building theAm I building the productproduct rightright ??
 Validation begins as soon as the project starts.Validation begins as soon as the project starts.
 Verification can begin only after specification hasVerification can begin only after specification has
been accepted.been accepted.
 Both are independent of each other.Both are independent of each other.

Needs Requirement Design Software
Validatio
n
Verification
Correctness
Correspondence
(Four Quality Measures)

VerificationVerification
 It ensures the product is designed to deliver allIt ensures the product is designed to deliver all
the functionality to the customer.the functionality to the customer.
 It involves:It involves:
 Review meetings to evaluate the documentsReview meetings to evaluate the documents
 Planning (Scheduling/staffing etc.)Planning (Scheduling/staffing etc.)
 Code WalkthroughsCode Walkthroughs
 SRS (Review)SRS (Review)
 Inspection meeting (Progress)Inspection meeting (Progress)
 Prepare check list/issue list/potential risk listPrepare check list/issue list/potential risk list

ValidationValidation
 It ensures that functionality, as defined inIt ensures that functionality, as defined in
requirements, is the intended behavior of therequirements, is the intended behavior of the
product.product.
 It involvesIt involves actual testingactual testing and takes place afterand takes place after
verification.verification.

O-O SYSTEMS DEVELOPMENT: AO-O SYSTEMS DEVELOPMENT: A
USE CASE DRIVEN APPROACHUSE CASE DRIVEN APPROACH
 The O-O software development life cycleThe O-O software development life cycle
(SDLC) consists of three macro processes:(SDLC) consists of three macro processes:
 Object-Oriented AnalysisObject-Oriented Analysis (focuses on(focuses on whatwhat thethe
system does)system does)
 Object-Oriented Design(Object-Oriented Design(OOD onOOD on howhow the systemthe system
does it)does it)
 Object-Oriented ImplementationObject-Oriented Implementation
 The use case model can be employedThe use case model can be employed
throughout most activities.throughout most activities.

Object-Oriented AnalysisObject-Oriented Analysis
 Analyze the taskAnalyze the task to develop a conceptual modelto develop a conceptual model
 Identify the software requiredIdentify the software required to satisfy a customer-definedto satisfy a customer-defined
requirement.requirement.
 Requirements areRequirements are gatheredgathered
 Divide in toDivide in to subprogramssubprograms
 Business logicBusiness logic andand technologytechnology are identified for eachare identified for each
subprogramsubprogram
 The artifacts of OOA are:The artifacts of OOA are:
set of use cases, one or more UML class diagram, numberset of use cases, one or more UML class diagram, number
of interaction diagrams, UIof interaction diagrams, UI

Object-Oriented DesignObject-Oriented Design
 implementationimplementation
constraintsconstraints(technical/environmental) are added to(technical/environmental) are added to
the conceptual modelthe conceptual model
-- architectural constraints, response time, run-time-- architectural constraints, response time, run-time
platform, development environment, or thoseplatform, development environment, or those
inherent in the programming language.inherent in the programming language.
 Concepts in the analysis model areConcepts in the analysis model are mapped ontomapped onto
implementation classes and interfacesimplementation classes and interfaces
 a detailed description ofa detailed description of howhow the system is to bethe system is to be
built.built.01/25/1901/25/19 MODULE-III OOSD Life CycleMODULE-III OOSD Life Cycle 1919

Object-Oriented DesignObject-Oriented Design
 Goal : toGoal : to design classesdesign classes identified during analysisidentified during analysis
phase & user interfacephase & user interface
 Identify additional objects & classes that supportIdentify additional objects & classes that support
implementation of requirementsimplementation of requirements
 Eg. add objects for user interface to system (data entryEg. add objects for user interface to system (data entry
windows, browse windows)windows, browse windows)
 Can beCan be intertwinedintertwined with analysis phasewith analysis phase
 Highly incrementalHighly incremental, eg. can start with object-oriented, eg. can start with object-oriented
analysis, model it, create object-oriented design, then doanalysis, model it, create object-oriented design, then do
some more of each again & again, gradually refining &some more of each again & again, gradually refining &
completing models of systemcompleting models of system
 Activities & focus of oo analysis & oo design areActivities & focus of oo analysis & oo design are
intertwinedintertwined

Trasformation 1
Trasformation 2Trasformation 3

Let’s SummarizeLet’s Summarize
 Object-oriented software developmentObject-oriented software development

ActivitiesActivities
 Object-oriented analysis - use case drivenObject-oriented analysis - use case driven
 Object-oriented designObject-oriented design
 PrototypingPrototyping
 Component-based developmentComponent-based development
 Incremental testingIncremental testing
 EncouragesEncourages
 viewing of system as a system of cooperative objectsviewing of system as a system of cooperative objects
 incremental developmentincremental development

Object-oriented analysis -Object-oriented analysis -
use-case drivenuse-case driven
 Use CaseUse Case, is a name for a, is a name for a scenarioscenario to describe theto describe the
user–computeruser–computer system interaction.system interaction.
 DetermineDetermine system requirementssystem requirements,, identify classesidentify classes &&
their relationshiptheir relationship to other classes in domainto other classes in domain
 To understand system requirementsTo understand system requirements
 need to identify theneed to identify the usersusers oror actorsactors
 who are the actors ? How do they use system ?who are the actors ? How do they use system ?
 Scenarios can help (in traditional development, it is treatedScenarios can help (in traditional development, it is treated
informally, not fully documented)informally, not fully documented)
 Jacobson introduces concept ofJacobson introduces concept of use case - scenario to describeuse case - scenario to describe
user-computer system interactionuser-computer system interaction

Use caseUse case
 Typical interaction between user & system that captures users’Typical interaction between user & system that captures users’
goal & needsgoal & needs
 In simple usage,In simple usage, capture use case by talking to typical users, discussingcapture use case by talking to typical users, discussing
various things they might want to do with systemvarious things they might want to do with system
 can be used to examine who does what in interactions among objects,can be used to examine who does what in interactions among objects,
what role they play, intersection among objects’ role to achieve givenwhat role they play, intersection among objects’ role to achieve given
goal is called collaborationgoal is called collaboration
 several scenariosseveral scenarios (usual & unusual behaviour, exceptions) needed to(usual & unusual behaviour, exceptions) needed to
understand all aspects of collaboration & all potential actionsunderstand all aspects of collaboration & all potential actions
 use cased modelinguse cased modeling
 expressingexpressing high level processeshigh level processes && interactions withinteractions with
customerscustomers in a scenario & analyzing itin a scenario & analyzing it
 gives system uses, system responsibilitiesgives system uses, system responsibilities
 developingdeveloping use case is iterativeuse case is iterative
 when use case model better understood & developed, start identifyingwhen use case model better understood & developed, start identifying
classes & create their relationshipclasses & create their relationship

Identifying objectsIdentifying objects
 What are physical objects in system ?What are physical objects in system ?
 Individuals, organizations, machines, units of information,Individuals, organizations, machines, units of information,
pictures, whatever makes up application/ make sense inpictures, whatever makes up application/ make sense in
context of real worldcontext of real world
 objects help establish workable systemobjects help establish workable system
 work iteratively between use-case & object modelswork iteratively between use-case & object models
 incentive payroll - employee, supervisor, office administrator,incentive payroll - employee, supervisor, office administrator,
paycheck, product made, process used to make productpaycheck, product made, process used to make product
 Intangible objects ?Intangible objects ?
 Data entry screens, data structuresData entry screens, data structures
 DocumentationDocumentation
 80-20 rule80-20 rule
 80% work can be done with 20% documentation80% work can be done with 20% documentation
 20% easily accessible, 80% available to few who needs to know20% easily accessible, 80% available to few who needs to know
 modeling & documentation inseparatablemodeling & documentation inseparatable
 good modeling implies good documentationgood modeling implies good documentation

Life Cycle Model of JacobsonLife Cycle Model of Jacobson
and Ericssonand Ericsson
Use case
models/
documnet
Dynamic model
OOA: Use case
Model
Object
interaction
diagram, etc.
OOA: Courses of
action
Testing: Usage
Scenarios
OOA: Identify
Actors
OOA: Object
Model
OOD: Dynamic
model
Design
classes
UI

Life Cycle Model of JacobsonLife Cycle Model of Jacobson
and Ericssonand Ericsson
 Advantages of OOSD-By use case are:Advantages of OOSD-By use case are:
 All design decisions can be traced back directly toAll design decisions can be traced back directly to
user requirements.user requirements.
 Usage scenariosUsage scenarios can becomecan become test scenarios.test scenarios.
 Views problem as aViews problem as a system of cooperating objects.system of cooperating objects.
 AdvocatesAdvocates incrementalincremental development.development.
 Helps inHelps in identifying objectsidentifying objects..

Object-oriented DesignObject-oriented Design
 First,First, build object modelbuild object model based on objects &based on objects &
relationshiprelationship
 ThenThen iterate & refineiterate & refine modelmodel
 Design & refine classesDesign & refine classes
 Design & refine attributesDesign & refine attributes
 Design & refine methodsDesign & refine methods
 Design & refine structuresDesign & refine structures
 Design & refine associationsDesign & refine associations

Guidelines in Object-orientedGuidelines in Object-oriented
DesignDesign
 ReuseReuse rather than build new classesrather than build new classes
 Know existing classesKnow existing classes
 Design large number of simple classes ratherDesign large number of simple classes rather
than small number of complex classesthan small number of complex classes
 Design methodsDesign methods
 Critique what has been proposedCritique what has been proposed
 Go back & refine classesGo back & refine classes

PrototypePrototype
 PrototypePrototype – version of software product developed in early– version of software product developed in early
stages of product’s life cycle for specific,stages of product’s life cycle for specific, experimentalexperimental
purposespurposes
 Enables us toEnables us to fully understand how easy/difficultfully understand how easy/difficult it will be toit will be to
implementimplement some features of systemsome features of system
 Gives users chance toGives users chance to commentcomment onon usabilityusability && usefulnessusefulness of userof user
interface designinterface design
 Can further define use cases, makes use case modeling easierCan further define use cases, makes use case modeling easier
 prototype that satisfies user + documentationprototype that satisfies user + documentation ->-> define basicdefine basic
courses of action for use cases covered by prototypecourses of action for use cases covered by prototype
 Important to construct prototype of key system componentsImportant to construct prototype of key system components
shortly after products are selectedshortly after products are selected
 Pictures worth a thousand wordsPictures worth a thousand words
 Build prototype with use-case modeling to design systems that usersBuild prototype with use-case modeling to design systems that users
like & needlike & need

Prototyping: old & newPrototyping: old & new
 Before: prototype thrown away when industrial strengthBefore: prototype thrown away when industrial strength
version developedversion developed
 New trend: (eg. rapid application development)New trend: (eg. rapid application development)
prototype refined into final productprototype refined into final product
 Prototype used as means toPrototype used as means to test & refine user interfacetest & refine user interface &&
increase usability of systemincrease usability of system
 As underlying prototype design becomes more consistent withAs underlying prototype design becomes more consistent with
application requirements, more detail can be added toapplication requirements, more detail can be added to
applicationapplication
 Test, evaluate & build further, till all components workTest, evaluate & build further, till all components work
properlyproperly

Categories of PrototypesCategories of Prototypes
 Horizontal prototypeHorizontal prototype
 Simulation of interfaceSimulation of interface (entire interface in full-featured system)(entire interface in full-featured system)
 ContainContain no functionalityno functionality
 Quick to implement, provide good overall feel of systemQuick to implement, provide good overall feel of system
 Vertical prototypeVertical prototype
 Subset of systemSubset of system features withfeatures with complete functionalitycomplete functionality
 Few implemented functions can be tested in great depthFew implemented functions can be tested in great depth
 Hybrid prototypesHybrid prototypes
 Major portions of interface established, features havingMajor portions of interface established, features having high degree of riskhigh degree of risk are prototypedare prototyped
withwith more functionalitymore functionality
 Analysis prototypeAnalysis prototype
 Aid in exploring problem domain, used to inform user & demonstrate proof of conceptAid in exploring problem domain, used to inform user & demonstrate proof of concept
 Not used as basis of development,Not used as basis of development, discardeddiscarded when it has serve purposewhen it has serve purpose
 Final product use prototype concepts, code is not used in implementation.Final product use prototype concepts, code is not used in implementation.
 Domain prototypeDomain prototype
 AidAid for incremental developmentfor incremental development of the ultimate software solutionof the ultimate software solution
 Often used as tool for staged delivery of subsystems to users/other members of developmentOften used as tool for staged delivery of subsystems to users/other members of development
teamteam
 Demonstrate the feasibility of implementationDemonstrate the feasibility of implementation
 Eventually evolve into deliverable productEventually evolve into deliverable product

Developing prototypesDeveloping prototypes
 Typical time from few days to few weeksTypical time from few days to few weeks
 Should be doneShould be done parallel with preparation of functionalparallel with preparation of functional
specificationspecification
 Can result in modification of specification (some problems/features onlyCan result in modification of specification (some problems/features only
obvious after prototype built)obvious after prototype built)
 Should involve representation from all user groups that will beShould involve representation from all user groups that will be
affected by projectaffected by project
 To ascertain all that the general structure of the prototype meetsTo ascertain all that the general structure of the prototype meets
requirements established for overall designrequirements established for overall design
 Purpose of reviewPurpose of review
 Demo that prototype has beenDemo that prototype has been developed according to specificationdeveloped according to specification & that& that
final specification is appropriatefinal specification is appropriate
 Collect infoCollect info about errors & problems in systems,about errors & problems in systems, eg user interfaceeg user interface
problemsproblems
 GiveGive management & everyonemanagement & everyone connected withconnected with project glimpseproject glimpse of whatof what
technology can providetechnology can provide

Implementation: Component-Implementation: Component-
based developmentbased development
 No more custom development, nowNo more custom development, now
assemble from prefabricated componentsassemble from prefabricated components
 No more cars, computers, etc customNo more cars, computers, etc custom
designed & built for each customerdesigned & built for each customer
 Can produceCan produce large marketslarge markets,, low cost, highlow cost, high
quality productsquality products
 Cost & time reducedCost & time reduced by building from pre-by building from pre-
built, ready-tested componentsbuilt, ready-tested components

Component-based developmentComponent-based development
 Industrialised approach to system development, move formIndustrialised approach to system development, move form
custom development to assembly ofcustom development to assembly of pre-built, pre-tested,pre-built, pre-tested,
reusable software componentsreusable software components that operate with each otherthat operate with each other
 Application development improvedApplication development improved significantly if applicationssignificantly if applications
assembled quickly from prefabricated software componentsassembled quickly from prefabricated software components
 Increasingly large collection of interpretable software componentsIncreasingly large collection of interpretable software components
could be made available to developers in both general & specialistcould be made available to developers in both general & specialist
catalogscatalogs
 Components themselves can be constructed from otherComponents themselves can be constructed from other
components, down to prebuiltcomponents, down to prebuilt
 Visual tools/actual codeVisual tools/actual code can be used tocan be used to glue togetherglue together
componentscomponents
 Visual glue – Digitalk’s Smalltalk PARTS, IBM VisualAgeVisual glue – Digitalk’s Smalltalk PARTS, IBM VisualAge
 Less development effortLess development effort,, fasterfaster,, increase flexibilityincrease flexibility

Application WrappingApplication Wrapping
 Application/component wrapperApplication/component wrapper
 surrounds complete system, both code & datasurrounds complete system, both code & data
 Provides interface to interact with both new & legacy software systemsProvides interface to interact with both new & legacy software systems
 Off the shelf not widely available, mostly home-grown within organizationOff the shelf not widely available, mostly home-grown within organization
 Software componentSoftware component
 Functional units of prgs, building block offering collection of reusable servicesFunctional units of prgs, building block offering collection of reusable services
 Can request service form another component or deliver its own services onCan request service form another component or deliver its own services on
requestrequest
 Delivery of services independent, component work together to accomplish taskDelivery of services independent, component work together to accomplish task
 Components can depend on one another without interfering one anotherComponents can depend on one another without interfering one another
 Each component unaware of context/inner workings of other componentsEach component unaware of context/inner workings of other components
 Aspects of software developmentAspects of software development
 OO concept – analysis, design, programmingOO concept – analysis, design, programming
 Component-based – implementation, system integrationComponent-based – implementation, system integration

Rapid Application DevelopmentRapid Application Development
 Set ofSet of tools & techniquestools & techniques to build application fasterto build application faster
than typically possible with traditional methodsthan typically possible with traditional methods
 Often used with software prototypingOften used with software prototyping
 Iterative developmentIterative development
 Implement design & user requirements incrementally withImplement design & user requirements incrementally with
tools like Delphi, VisualAge, Visual Basic, ortools like Delphi, VisualAge, Visual Basic, or
PowerBuilderPowerBuilder
 Begins when design completedBegins when design completed
 Do we actually understood problem (analysis) ?Do we actually understood problem (analysis) ?
 Does the system do what it is supposed to do (design) ?Does the system do what it is supposed to do (design) ?
 Make improvement in each iterationMake improvement in each iteration

Incremental testingIncremental testing
 Software development and all of its activitiesSoftware development and all of its activities
including testing are an iterative process.including testing are an iterative process.
 Waiting until after development waste moneyWaiting until after development waste money
& time& time
 Turning over applications to quality assuranceTurning over applications to quality assurance
group not helping since they are not includedgroup not helping since they are not included
in initial planin initial plan

Incremental Testing…Incremental Testing…
 Two important types of testingTwo important types of testing
 Usability TestingUsability Testing
 More on the Interfaces of the systemMore on the Interfaces of the system
 Eg - Questionnaires to targeted usersEg - Questionnaires to targeted users
 Feedback from targeted usersFeedback from targeted users
 Functionality TestingFunctionality Testing
 More on the features of the systemMore on the features of the system
 Eg – Test Plan (includes test cases)Eg – Test Plan (includes test cases)
 Testing on Expected and Actual Outcome of the systemTesting on Expected and Actual Outcome of the system

ReusabilityReusability
 Major benefit of Object-oriented approachMajor benefit of Object-oriented approach
 For objects to be reusable, much effort must beFor objects to be reusable, much effort must be
spent on designing itspent on designing it
 Design reusabilityDesign reusability
 Effectively evaluate existing softwareEffectively evaluate existing software
componentscomponents
 Has my problem been solved ?Has my problem been solved ?
 Has my problem been partially solved ?Has my problem been partially solved ?
 What has been done before to solve problemWhat has been done before to solve problem
similar to this one ?similar to this one ?

Reuse StrategyReuse Strategy
 Information hidingInformation hiding
 Conformance to naming standardsConformance to naming standards
 Creation & administration of an object repositoryCreation & administration of an object repository
 Encouragement by strategic management of reuse asEncouragement by strategic management of reuse as
opposed to constant redevelopmentopposed to constant redevelopment
 Establish target for % of object in project to be reuseEstablish target for % of object in project to be reuse

Object Oriented System Design

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Object Oriented System Design

Similar to Object Oriented System Design (20)

Recently uploaded

Recently uploaded (20)

Object Oriented System Design