1 Object Oriented Analysis and Design with UML UNIT 1.

1

Object OrientedAnalysis and Design

with UML

UNIT 1

2

Coordinates

Office

Building F, 10th Floor

Campus Etterbeek

Surface Mail Vrije Universiteit Brussel Faculty of Sciences [WE]

Department of Computer Science [DINF]

Programming Technology Lab [PROG]

Pleinlaan 2

B-1040 Brussels

Telephone +32 2 629 34 91

Telefax +32 2 629 35 25

Email [email protected]

Homepage http://prog.vub.ac.be/

3

Course Contents : Overview

Object Oriented Paradigm (OO) Analysis and Design (A&D) Unified Modelling Language (UML)

OO Programming Complete Coverage Rational Rose Tool

What you not will learn

What you will learn

4

Unit 1

Course : Timing...

– Introduction to Object Orientation– Introduction to Analysis & Design

5

Unit 2

– The history of UML– General overview of UML– Use cases and scenarios– Class diagrams

Course : Timing...

6

Unit 3

Course : Timing...

– Advanced Class diagrams– Object Interaction diagrams– A notion of Design Patterns – Antipatterns

7

Unit 4

– Sequence diagrams– Collaboration diagrams– Activity diagram

Course : Timing...

8

Unit 5

– Component diagrams– Deployment diagrams– A Process for UML : RUP

Course : Timing.

9

Book

UML ToolkitHans-Erik Eriksson & Magnus Penker

Wiley Computer Publishing

© 1998, ISBN 0-471-19161-2

10

TheObject Oriented

Paradigm

UNIT 1

11

Questions to be answered

Why is Object Orientation (OO) Popular? Why is switching to OO not trivial An Object Oriented Paradigm? Overview of OO Concepts Overview of OO Techniques

12

Why could OO be so Popular...

A few possible reasons : Hope that it will quickly and easily lead to

increased productivity and improved reliability End of the software crisis!

Hope for easy transition from existing languages Similarity to techniques of thinking

about problems in other domains

Everybody talks about it, our customers ask it, ...

NAÏVEAPPROACH

=TROUBLE !

13

Why should OO be so Popular.

OO is an evolutionary step, following naturally on the heels of earlier programming abstractions

OO ‘solves’ many problems encountered in the traditional approaches.

OOP is a revolutionary idea, totallyunlike anything thathas come before.

OO promotes reuse…

LET’s EVALUATEIT FIRST

=BEST WAY TO GO !

14



15

Sapir - Whorf Hypothesis...

In Linguistics :– The language in which an idea is thought or

expressed, colours or directs the nature of thought

• Eskimo languages and snow• French vs Dutch : neveu,cousin vs neef

– neveu = children of a brother/sister– cousin = children of an uncle/aunt

What is true of natural languagesis true for artificial languages

Especially for OO

16

Example for Computer Science...

A student working in DNA research had the task of finding

repeated sequences of M values in a long sequence of values :

Wrote a simple FORTRAN program with 2 nested loops :

Took a depressing long time !

DO 10 I=1, N-M DO 20 J=I+1, N-M FOUND = .TRUE20 IF X[I+K-1].NE.X[J+K-1] THEN FOUND = .FALSE. IF FOUND THEN …10 CONTINUE

ACTCGGATCTTGCATTCGGCAATTGGACCCTGA ...

17

A friend working in APL found another solution by rearranging the data and sorting :

A Better Solution...

ACTCGGATCTTGCATTCGGCAATTGGACCCTGA ...

ACTCG positions 1 to MCTCGG positions 2 to M+1TCGGA positions 3 to M+2CGGAT positions 4 to M+3GGATC positions 5 to M+4GATCT positions 6 to M+5... ...

SORT

Amazingly fast !

18

What Lead to the Discovery?

Why did the APL programmer find a faster solution?

– FORTRAN programmer was blinded by a culture that valued loops

• If M=length of pattern and N=size of string O(M*N2)

– Sorting is a built-in operation in APL (high performance), good programmers try novel uses of sorting

• If M=length of pattern and N=size of string O(M*N log N)

19

General Conclusion.

Thoughts/solutions are often guided by the language in which they are expressed

Anything can be done in any language– but it may be easier or more difficult.

To become a good OO Programmer/Analyst, you must think in terms of OO !– Otherwise you get traditional programs

with an OO coating

20



21

A New Paradigm...

What is a paradigm ?– a set of theories, standards, and methods that

together represent a way of organising knowledge that is, a way of viewing the world.

In software development there are numerous ways of viewing the world...

22

What are the major paradigms?

Paradigms...

Object oriented paradigm (Smalltalk, Java, C++,...)

Functional paradigm (Scheme, Lisp, ...)

Logic paradigm (Prolog, ...)

New?

Imperative paradigm (Cobol, C, Lisp, Pascal, Fortran,...)

Small languages and tools (Perl, Python, Tcl/Tk, ...)

23

Imperative Programming...

Imperative Programming is the ‘traditional’ model of computation– Variables

– Procedures

– Functions

– Assignments, …

A set of procedures/functions acts upon memory– The processing unit is separated from this memory

24

Visualisation...

(1)

(2)

(3)

STATE

BEHAVIOUR

proc_B causes a crashof proc_A

(without knowing it)

proc_B proc_A

25

Visualisation.

(1)

(2)

(3)

STATE

BEHAVIOUR

Worked ‘fine’ for many years, but…

… systems become larger, so there was a

need for something new

26



27

Object Orientation

Based on the principle of recursive design :– Everything is an object

This includes basic datatypes : aString, anInteger, aFloat,...

Objects perform computation by making requests to each other : messages

An object has its own memory, which consists of other objects : state

28

Object Orientation

Every object is an instance of a class. A class groups similar objects (see later...)

The reaction upon a message is described in a method

Information hiding is a very powerfulaspect of OO

Classes can be organized into tree structures, called inheritance hierarchies (see later...)

29

aRectangleaRectangle

ulc: (10,20) side1: 50 side2: 20

ulc: (10,20) side1: 50 side2: 20

circumference( ) area( )

moveTo(aPoint)


moveTo(aPoint)

OO Concepts : Objects...

Everything is an object All actions in OO are performed by agents

called instances or objects

Identity

StateBehaviour, Messages

Object = identity + state + behaviour

30

Examples of Objects

aButton

aTrafficLight

aSportman

aCdRomaFloppy

anExplorer

aLibrary aPrinter

31

OO Concepts : Messages...

Objects perform computation by making requests from each other by sending messages

Actions are produced in response to messages

An object may accept a message– It will perform an action– The result of this action

is returned (an object)

aRectangle.c

ircumference

()

aRectangle.a

rea()

aRectangle.m

oveTo(myPoin

t)

aRectangle.g

etShoeSize()

“Message no

t understood

”

32

Examples of Messages...

offline?()

setBackColor(aColor)

click()

setFocus()

getAge()

displayTrophyList()

getAverageScore()

print(aDocument)

getBook(anISBN)

getAllBooks()

sortByAuthor(order)

33

Examples of Messages...

deleteFile(aFilename)

format()

getLabel()

getContents()

responding?()

selectDrive(aDrive)

refresh()

windowSize(aSize)

switchColor(aColor)

startWorking()

!polymorphism

34

OO Concepts : Messages Summary

Always sent to a receiver object A message may include parameters (objects)

necessary for performing the action Message-send always returns a result (an object) Only way to communicate with an object and

have it perform actions

aRectangle.circumference() aRectangle.area() aRectangle.moveTo(myPoint) aPrinter.print(myFile) anEmployee.setName(aName)

Receiver Objects Messages

35

OO Concepts : Methods...

Defines how to respond to a message Selected via method lookup technique Has name that is the same as message name Is implemented as a sequence of executable

statements Returns an object as its result of execution

Integer area() { return side1 * side2 } Integer circumference() { return (2*side1)+(2*side2)}...

aRectangleaRectangle

ulc: (10,20) side1: 50 side2: 20

ulc: (10,20) side1: 50 side2: 20


moveTo(aPoint)


moveTo(aPoint)

Return Type

Method body

Messagename

36

What: Messages– Specify what behaviour objects are to perform

– Details of how are left up to the receiver

– State information only accessible through messages

How: Methods– Specify how operation is to be performed

– Must have access to the objects’ internal state

– Need detailed knowledge of internal state

– Can manipulate internal state directly

Messages vs Methods : What vs How.

37

OO Concepts : Classes...

“Factory” object for creating new objects of a certain type– These objects are referred to as instances of a class– (cfr. Cookie-cutter)

Every object must be an instance of a class In “true” OO languages there exists a root class

the class named Object Rectangle aRectangle aRectangle = Rectangle.new() Point myPoint myPoint = Point.new(10,50) aRectangle.moveTo(myPoint)

Classname Instancename

38

OO Concepts : Class Instances.

Instance = a particular occurrence of an object defined by a class

Each instance has its own value for each instance variable

All instances of a class share the same methods

StockStockcompanyName

numberofSharescurrentPrice

companyNamenumberofShares

currentPrice

calculateValue( )calculateGainorLoss( )calculateTaxLiability( )

calculateValue( )calculateGainorLoss( )calculateTaxLiability( )

IBM Inc.3000

$ 78.00

myIBMStockmyIBMStock

AppleInc.1000

$ 42.00

yourAppleStockyourAppleStock

Instances

39

OO Concepts : Object Encapsulation

Objects encapsulate state as a collection of instance variables

Objects encapsulate behaviour via methods invoked by messages

External perspective vs. Internal perspectiveWhat vs. HowMessage vs. Method

40

OO Concepts : Information Hiding

A user of a service provided by an object, only needs to know the set of messages that this object will accept.

The user doesn’t need to have any idea how the actions performed in responseto his request will be carried out.

Having accepted a message, an object is responsible for carrying it out.

Interfaces

Delegation

Encapsulation

41

Object Encapsulation Technique for

– Hiding implementation details

– Protecting the state information of objects

– Communicating/accessing via a uniform interface

Puts objects in control Facilitates modularity, code reuse and maintenance

RectangleRectangle

ulc: Point brc: Pointulc: Point brc: Point

circumference area

moveTo: aPoint

circumference area

moveTo: aPoint

RectangleRectangleulc: Point

side1: Integer side2: Integer

ulc: Point side1: Integer side2: Integercircumference

area moveTo: aPoint

circumference area

moveTo: aPoint

Different Representation

Same Interface !

42

Behaviour and Interpretation

Although different objects may accept the same message, the actions (behaviour) they perform will likely be different.

The determination of what behaviour to perform may be made at run-time, a form of late binding

43

Intermezzo...

Messages differ from traditional function calls in two very important aspects :– In a message there is a designated receiver that

accepts the message.– The interpretation of the message may be

different, depending upon the receiver– The object is in control of its own state...

44

Intermezzo.

(1)

(2)

(3)

STATEBEHAVIOUR

Encapsulation is a mechanismthat solves this problem !

45



46

Class Hierarchies

Some classes are related to each other– Specialization principle– Generalization principle

Allows to :– Extend ...– Refine ...

an existing class with your own version

47

Class Hierarchies : ExampleStorageMediumStorageMedium

label: String capacity: IntegerContents: FilePool

label: String capacity: IntegerContents: FilePool

write(aFile) read(aFile)

getContents( )

write(aFile) read(aFile)

getContents( )

FloppyDiskFloppyDisk

capacity: 1440Writeprotect: Boolean

capacity: 1440Writeprotect: Boolean

format( )delete( )format( )delete( )

CdRomCdRom

capacity: 66500jolietClosed: Boolean

capacity: 66500jolietClosed: Boolean

FilePoolFilePool

......

ExplorerExplorer

......

48

Inheritance Hierarchical definitions

– Classes as units of sharing

– Object’s state and behavioural description is broken into pieces

– Promotes modularity and reusability

Inheritance– Child shares state/behaviour with parent

– Child can add new state information

– Child can selectively add and/or redefine behaviour

Living Thingage

Animalhabitat

Mammalpregnancy

Human Beingname

49

Overriding Behaviour

Subclasses can alter or override information inherited from parent classes :– All mammals give birth to live young– A platypus is an egg-laying mammal

50

Superclass/subclass Relationship

Superclass is the parent and subclass is a child Subclasses specialise their superclass

Living Thing

Plant Animal

Reptile Mammal Fish Tree Flower

51

Example of a Hierarchy

Living Thing

PlantAnimal

Reptile Mammal

Human Being Cat Dog Platypus

Dentist Florist Secretary

Rock

52

Concrete vs. Abstract Classes Abstract Class

– Holds on to common characteristics shared by other classes

– Not expected to have instances Concrete Class

– Contains complete characterisation of actual objects

– Expected to have instances

Animal

Mammal Reptile

Living Thing

53

Polymorphism...

Same message may be sent to different objects

speak()

WOEF !

MEUH !

Different receiver objects may respond differently to the same message.

54

Polymorphism & Dynamic Binding

Mapping of messages to methods deferred until run-time

Allows for rapid incremental development without the need to recompile (in Smalltalk)

Most traditional languages do this at compile time (static binding)

Efficiency of dynamic binding very high.

aRectangle aSquare

aCircle

Area aGraphic

55

Example:The Investment Manager Many activities for each investment, e.g.,

– Calculate current worth

– Calculate tax liability

Nature of activity depends on:– Kind of investment (stock, bond, rental)

– How long investment has been held

– What’s happened during a particular period

56

Procedural Language Solution…

For each investment, define– Data Structures

State

type: bondissue_name: char*int_rate: floatcur_price: floatpur_price: floatpur_date: date

type: rentallocation: char*rent_rate: floatpur_price floatpur_date: dateloan_bal: float

type: stockcomp_name: char*cur_price: floatpur_price: floatpur_date: date

57


For each investment, define– Uniquely named Procedures

Behaviour

float calc_stock_tax(stock){ result: float; result = (stock.pur_price - stock.cur_price) * 0.21; return(result);}

float calc_bond_tax(bond){ result: float; result = bond.pur_price * bond.int_rate) * 0.21 return(result)}

float calc_rental_tax(rental){ result: float; result = (rental.rent_rate * 12) * 0.21; return(result)}

58


For each activity, define:– Control (e.g., case statements) to select proper set of

procedures for handling each type of investment.

calculate_taxes(investment_list):for each item in investment_list do begin

index := item.type;case index of

stock: calc_stock_tax(item);bond: calc_bond_tax(item);rental: calc_rental_tax(item);...

end case end

Code to generate

a tax report

might look like:

59

A Simple OO Solution…

Have a unique class description for each kind of investment

Each investment object will have its own instance variables

Each investment has a calculateTaxLiability method

StockStockcompanyName

numberofSharescurrentPrice

companyNamenumberofShares

currentPrice

calculateValuecalculateGainorLosscalculateTaxLiability


BondBondissuerNameinterestRate

purchasePrice

issuerNameinterestRate

purchasePrice



RentalPropertyRentalPropertylocation

rentalRatepurchasePrice

locationrentalRate

purchasePrice



60

A Simple OO Solution.

Assume a list of current investments has already been generated.

Code to generate a tax report might look like:

(message) investmentList calculateAllTaxes

(method) investmentList do: [:eachInvestment | eachInvestment calculateTaxLiability]

61

Extending the Financial Investments Example

StocksStocks

Rental Property

Rental PropertyBondsBonds

Before

AfterStocksStocks

Rental Property

Rental PropertyBondsBonds

Home Home

Mutual FundsMutual Funds CommercialLand

CommercialLand

62

Revised Traditional Solution…

For each new kind of investment, define– New data structure(s)

type: landlocation: char*int_rate: floatpur_price floatpur_date: dateloan_bal: float

type: fundcomp_name: char*share_value: floatcur_price: floatpur_price: floatpur_date: date

State

63

Revised Traditional Solution…

For each new kind of investment, define– New uniquely named procedures

float calc_fund_tax(fund){ result: float; result = ((fund.pur_price - fund.cur_price) * fund.share_value ) * 0.21; return(result)}

float calc_land_tax(land){ result: float; result = (land.pur_price - land.loan_bal) * 0.21; return(result)}

Behaviour

64

Revised Traditional Solution.

For each case, add a test for each new kind of investment

Ensure that every case can handle the new types

calculate_taxes(investment_list):for each item in investment_list do begin

index := item.type;case index of

stock: calc_stock_tax(item);bond: calc_bond_tax(item);rental: calc_rental_tax(item);fund: calc_fund_tax(item);land: calc_land_tax(item);...

end case end

Code to generate

a tax report

might look like:

65

Revised OO Solution…

» Create a new class description for each new kind of investment

» Each new investment object will have its own instance variables

» Each investment has a calculateTaxLiability method

MutualFundMutualFundcompanyName

shareValuecurrentPrice

companyNameshareValuecurrentPrice



CommercialLandCommercialLandlocation

interestRatepurchasePrice

locationinterestRate

purchasePrice



66

Revised OO Solution.

Because the individual objects know what to do, no changes are required

Code to generate a tax report still looks like:

(message) investmentList calculateAllTaxes

(method) investmentList do: [:eachInvestment | eachInvestment calculateTaxLiability]

67

Possible Hierarchy for Investments

Investment

Real Estate Investment

SecuritiesInvestment

Stock Bond MutualFund

CommercialProperty

Raw Land

Object

68

The Investment Manager Revisited

InvestmentcurrentValuepurchasePricedatePurchased

calculateGainOrLosscalculateTaxLiabilitycalculateAnnualIncome

SecuritiesInvestmentissuerName

calculatePriceEarnings

SecuritiesInvestmentlocationinterestRate

calculateValue(calculateTaxLiability)Stock

sharesOutstandingcalculateVolatility(calculateTaxLiability)

BondmaturityDate

updateRating(calculateTaxLiability)

HomeloanBalance

(calculateValue)

RentalPropertyrentalRate

(calculateValue)(calculateTaxLiability)calculateDepreciation

69

Summary...

Object-Oriented Approach– Emphasises behavioural modeling– Is structured in terms of

• Objects

• Messages

• Methods

– Supports sharing through• Classes and instances

• Class hierarchies

70

Summary...

Object-Oriented Techniques» Are based on

– Encapsulating data and procedures

– Inheritance

– Polymorphism

– Dynamic binding

» Facilitate– Modularity

– Reusability and sharing

– Extensibility and change (maintainability)

71

Analysis&

Design

UNIT 1

72

Main Development Phases

Analysis

Design

Implementation Testing

ExploitationMaintenance

Problem

73


Analysis

Design



Problem

74

ANALYSIS

Requirements Engineering (RE) Creation, verification, validation of a

conceptual specification :– problems, domain, future system

As complete as possible Focus on real-world problems

– What is the system supposed to do ?

75

Requirements Engineering

Input consists of many fuzzy informal statements of requirements– Statements come from the future users of the system

An agreement must be reached– With all the stakeholders

Four fundamental RE Processes :– Requirements elicitation, specification, verification,

validation

76

Fundamental RE Processes

Requirements elicitation– Gain relevant knowledge about the problem

and its context– Could/should be an ongoing process running

parallel with other RE processes– Results in an informal requirements document

• informally specified in natural language

77

…

FormAnalysis

TaskAnalysis

How to Elicit Knowledge ...

Objectiveand

Goal Analysis

Scenario basedAnalysis

Reuse

FromUsers

78


From users– interviews, questionnaires, brainstorming sessions, …– Problems experienced :

• Users that do not have a clear idea of what they want• Users that do not agree on what they want• Users that are not able to describe what they want• Users use domain oriented terminology, analysts use

computer oriented language• Users that simply refuse to cooperate or participate

79


Objective and Goal Analysis– Ask and question the reasons why a system

needs to be built

Task Analysis– How do the users do their job?

• Activities they perform and the structure in which they perform them

• What kind of knowledge is required to perform the activity

80

How to Elicit Knowledge.

Scenario-based Analysis– Make use of active ‘story telling’ sessions

Form Analysis– Listings, official documents, …

• Less ambiguous, less inconsistent and structured

Reuse– Do not reinvent the wheel over and over again

81

Fundamental RE Processes

Requirements Specification– Analyze, assimilate, synthesize, organize

knowledge from the requirements document– Describe the problem formally by creating

models– Different views of the problem may exist

• Try to reach an agreement

– Results in a requirements specification

82

What Aspects must be Modeled

3 main requirements should be modeled :– Enterprise requirements

• Allows to delimit the scope of investigation

• Provides a context and justification for the system to be built

• Considers organizational structures, activities, processes, products, agents and work roles

– Functional requirements• What is the system intended to do

83

What Aspects must be Modeled

– Non functional requirements• Issues like performance, external interfaces, design

constraints, standards, quality attributes, security, ...

84

Requirements Specification Properties Requirements Verification

– Check wether the models have certain properties

• Communicability– Dual nature !

• Implementation Independency

• Completeness– To a certain degree

85

Requirements Specification Properties

• Feasibility– benefits vs costs

• Consistency– All conflicts must be resolved

• Verifiability– Properties of the system should be specified in a

measurable way

• Maintainability– Changes should be easily incorporatable

86

Requirements Specification Properties

• Validity– External consistency

» Reach an agreement between what is stated in the model and what is true in the problem domain

– Non-ambiguity

» A req. cannot be interpreted in more than one way

– Minimality

» No over-specification

– Completeness

» No omission of essential elements

87

Importance of RE

Wrong decisions, misunderstandings made in this phase have a major impact !

RE process provides a foundation by :– Enforcing users to consider req. carefully– Aims at an as correct and complete as possible

specification of the problem and domain– Bringing users and developers in agreement– Acting as a contractual agreement– Basis for managerial activities : cost, time, ...

88


Analysis

Design



Problem

89

DESIGN

Detailed specifications that describe the intended form of implementation– For all SW components– For all relationships between these components

• How do they fit together?

Specification of SW architecture Focus on computerized solutions

– A blue-print of how to construct the system

90

Features of Good Design

Completeness and correctness– Fitness for purpose

Robustness– Stable against changes

Maintainability Reusability Modularity Simplicity ...

91

Main Contributions ...

Further refinement of aspects identified in analysis phase– move seamlessly to actual implementation

Adaptation of system to actual implementation environment– Contrast to ideal world of analysis

• How to incorporate existing legacy systems, available HW and SW, performance, people, ...

92

Main Contributions.

Additional validations of analysis results– Maybe we were too idealistic– Maybe the problem is not implementable as is?

Result = A design model

93

A Possible SystemArchitecture Reference Model 6 subsystems (Components) :

– Problem Domain, Human Interaction, External Interface, Data Management, Task Management, Utility Services

94


Analysis

Design



Problem

95

IMPLEMENTATION

Last creative phase of SW development Creation of all :

– HW and SW components– Documentation of the system– User documentation– Organizational structures– …

‘Results’ into an executable system...

96

Main Implementation Issues...

Programming languages– Often not free to choose– Each have their own weaknesses and strengths

Increased complexity– Often leads to patchwork

• e.g. unsupported features• Or undocumented features

Increased quality requirements

97

Main Implementation Issues.

Reduction of development time Evolving nature of systems

– Written today, outdated tomorrow.

98

How to Facilitate this Phase

Two main approaches– Reuse of programming code

• The reapplication of a variety of kinds of knowledge about one system to another similar system in order to reduce the effort of development and maintenance of that other system.

– In majority of projects it remains hype, however OO...

– Code generation• Many CASE tools offer this feature

– Results remain dubious.

99


Analysis

Design



Problem

100

TESTING

Make sure a system contains as few as possible errors (0), before deliverance.

Focus on :– Validation

• Develop the right product

– Verification• Develop the product right

– Qualification• Develop right

101

Several Kinds of Tests...

Unit test– Test individual SW components seperately– Focus on small pieces of code

• e.g. classes in OO

Integration test– Test the method, procedure, function interfaces

of SW components• Can they communicate with each other ?• Is the protocol respected ?

102

Several Kinds of Tests.

System test– Compare the SW system to original goals and

objectives– Test the capability of the system to satisfy

performance, security, usability, and stability

Acceptation test– Let the user test the system

• Does the system perform as expected

• Is the user documentation understood

103

Phases vs. Tests

Analysis

RequirementsElicitation

Design

Implementation

AcceptationTest

IntegrationTest

SystemTest

UnitTest

104


Analysis

Design



Problem

105

EXPLOITATION and MAINTENANCE The system is built, the real work starts 3 main categories

– Corrective– Adaptive– Perfective

Sometimes 50 % of total system cost ! Sometimes better to restart building a

system...

106

Summary

Analysis

Design



Problem

107

Development Strategies...

Different ways to execute development phases Linkage of phases in a Life cycle

• Define the actions of each phase

• Define the deliverables of each phase

• Define the transition from one phase into another

In early days of computing there was no need for a strategy– Simply encode the problem and test

CRISIS

108

Development Strategies.

Two main directions– Linear vs. Iterative development– Incremental development

Well-known strategies– Waterfall model– Prototyping approach– Spiral model

109

Linear vs. Iterative development

Linear direction– Phase based– Each phase carried out once

• After a phase is concluded you never enter it again

– No iteration, so no mistakes ???

Iterative direction– Allows (parts of) a phase to be carried out more than

once– Commonly accepted

110

Incremental Development...

Partial implementation (PI) instead of total system at one go

When PI turns out fine– Add more functionality– Add increased performance, …

But how many units of incremental delivery are needed?– Reach agreement before starting !

111

Incremental Development.

Main decisions to be made :– What is subject to incrementation

• The product as a whole or parts of it?

– What is subject to iteration• Phases as a whole or steps from phases?

112

The Waterfall Model...

113


Interaction between subsequent phases Includes iteration and feedback

– Feedback loops allow modification

Each phase is completed by documenting the achievements

114


Main benefits of introduction– Systems are specified before construction– System components are designed before encoded– Tends to ease project management

• Well-defined milestones

– Facilitates maintenance• Required documentation per phase

115

The Waterfall Model.

Main criticism :– Too strict seperation of phases

• Often very artificial

– An executable SW version appears at the end of the project !

• Too late for major changes

• Could be solved by the notion of prototyping

116

Unit Testing

Coding

Program Design

System Design

SoftwareRequirementsSpecification

Derivative : Fountain ModelFurther

DevelopmentMaintenance

UserRequirementsSpecification

ProgramUse

RequirementsAnalysis

117

Prototyping Approach...

What is a prototype ?– An executable model of (parts of) a SW system,

which emphasizes specific aspects.

High degree of user participation Concrete representation of user requirements Very useful whenever requirements are

unstable or uncertain

118

Prototyping Approach...

Throwaway Prototyping– Makes use of prototypes early in development

to clarify poorly understood parts

Iterative/Evolutionary Prototyping– The initial prototype provides an overall

framework for the total system

119

Prototyping Approach.

Main benefits :– Faster development time

– Resulting system is easier to use and to learn

But be careful :– Working out specific details too early

• Most of the time on user demand

– There is a danger that the final system will still be a prototype

Smalltalk is well suited for making prototypes

120

State of the Art

Object Modeling Technique (OMT) Booch Method (OOD) Object-Oriented Software Engineering (OOSE) Kirsten Iteration, Selection and Sequence Method

(KISS) Method for Conceptual Modeling (MCM) Object Behaviour Analysis (OBA) Shlaer/Mellor Method Yourdon Method

121

State of the Art

Object Modeling Technique (OMT) Booch Method (OOD) Object-Oriented Software Engineering (OOSE) Kirsten Iteration, Selection and Sequence Method

(KISS) Method for Conceptual Modeling (MCM) Object Behaviour Analysis (OBA) Shlaer/Mellor Method Yourdon Method

Combination of the best of these

=UML

1 Object Oriented Analysis and Design with UML UNIT 1.

Documents

Transcript of 1 Object Oriented Analysis and Design with UML UNIT 1.