Agile Software Developmentwith the UML

Bernhard RumpeSoftware & Systems Engineering

Fakultät für InformatikTechnische Universität München

21.10.2002

2Dr. Bernhard Rumpe

Contents

• Goals of the proposed approach

• Running example: online auction system

• Agile use of UML

• Technique: modelling of test cases

• Technique: refactoring

• Testing components through interfaces

• Conclusion and outlook

3Dr. Bernhard Rumpe

Proposed approach

• Method for – small and medium sized projects for a– more efficient and flexible development of systems in– rapidly changing business domains such that– a high quality product satisfies the customer early

• Approach through integration of – agile method techniques with UML

• Contributions in this talk– modelling tests with the UML– refactoring of UML diagrams

4Dr. Bernhard Rumpe

Running example: online auction system• Several suppliers bid for a single contract

• Real-time auctions ~2h duration, extensions allow to react on competitor bids,

• Example: electrical power for a bank for 12 month supply: 46% cost reduction

applet running within a browser

• Requirements: – availability, security

– easy to use,

– high quality implementation,

– flexible extensions

• Limited personal resources available

5Dr. Bernhard Rumpe

Trends in software development

• Size and complexity of systems continually increase:– Isolated solutions company-wide integration E-Commerce

• New technologies:– EJB, XML, .Net, ...

• Diversification of application domains:– Embedded systems, business systems, telecommunication, mobiles

• Growing methodological experience how to deal with these challenges– Agile Methods, e.g, address

unstable requirements, time-to-market pressure, lean and effective development for small projects

Diversification of software development processes

6Dr. Bernhard Rumpe

Our approach: UML as central notation

UML

static analysis

rapid prototyping

code generationautomated tests

refactoring

documentation

• An adapted version of the UML serves as central notation for the project• UML is programming, test and modelling language at the same time

7Dr. Bernhard Rumpe

codegeneration

system

• Two kinds of models are used: the system

test code

test codegeneration

• Two kinds of models are used: the system and executable tests

UML models check mutual conformance

How UML is used

statechartsclass diagrams sequence diagrams

object diagrams

__:

__:

__:

OCL

Java

8Dr. Bernhard Rumpe

Benefits of this approach

• UML + code blocks are a full programming language– compact– diagrams allow a good structuring– less redundant information

• Parameterised code generator – generates e.g. access methods– adaptable to target platform, frameworks, GUI … – separation of application logic and platform dependent code

• UML as single language for (analysis,) design, implementation and test documents

• Consistency checks used for critical parts– type check, tests, consistency of models

efficiency & reuse

no conceptualbreak

quality

efficiency

9Dr. Bernhard Rumpe

How the approach supports agile development

Core characteristics of agility: Improvement through use of UML:

Reactivity: flexibility to deal with changes

+ incremental development in yet smaller cycles

Efficiency of the developers

+ increased through advanced notation & tools

Rely on individuals + less tedious work

? skilled people are necessary

Simplicity + refactoring increases extensibility

Customer focus + even more rapid feedback

Quality is an emerging property

+ automated tests

+ common ownership & pairwise development of models

+ better review-able designs

10Dr. Bernhard Rumpe

Typical infrastructure of an automated test

object undertest

o1

o3 o4

o2 o1

o3 o4

o2

o5

• Principle: use– relatively complete object diagram (OD) for test data– partial OD und OCL as oracle– sequence diagram (SD) or Java as test driver

OD OD

OCL

SD or Java

+

test data test driver

expected result and/orOCL-contract as test oracle

11Dr. Bernhard Rumpe

Test invariants with object diagrams and OCL• OCL and object diagrams can be mutually integrated• E.g. object diagrams used as predicates within OCL statements

…

0

a:Auction…

OD.Welcome OD.Open

:TimingPolicy

/int status = OPEN

…

a:Auction…

inv WelcomeMSG: forall Auction a: OD.Open implies exists TextMessage w: OD.Welcome

describes type of diagram and gives it a name

content == “Welcome.“

w:TextMessage

12Dr. Bernhard Rumpe

Sequence diagram: test driver and interaction description

• linear structure of an exemplaric system run• + OCL for property description

OCL constraints describe properties duringthe test run

copper912:Auction

bidPol:BiddingPolicy

timePol:TimingPolicy

test driver

validateBid(bid)

return OK

return t

newCurrentClosingTime(copper912, bid)

t.time == bid.time + extensionTime

«trigger» handleBid(bid)

SD

13Dr. Bernhard Rumpe

Refactoring

• Refactoring is a technique to – improve internal structure / architecture of a system, while – preserving observable behaviour

• Refactoring rules:– series of systematically applicable, goal directed steps

• Powerful through– simplicity of piecewise application and– flexibility of combination of systematic steps

• Examples: – expand method, move attribute, – add method parameter, split classes

• Roots: – Opdyke/Johnson 1992 had 23 refactorings on C++– Fowler’1999 has 72 refactoring rules shown in Java

14Dr. Bernhard Rumpe

Principle of refactoring

• Refactoring is orthogonal to adding functionality• An idealised diagram:

quality of design

functionality

programming

refactoring

target: 100% of the functionality, acceptable design

100%

100%

15Dr. Bernhard Rumpe

Refactoring example 1

• Pull Up Attribute “ident” into superclass: structural generalization • Factor Method “checkPasswd()” and adapt it

PersonCD

Guest

checkPasswd()

Bidder

long ident

checkPasswd()

Bidder

Person

checkPasswd()

long ident

Guest

CD

Refactoring

• Preservation of observable behaviour?– depends on viewpoint: class, component, system

16Dr. Bernhard Rumpe

Refactoring example 2: changing data structures

A series of steps to apply:

1. Identify old data structure: here: long to be replaced by Money

long currentBidInCent

Auction …

2. Add new datastructure + queries + compile

Money bestBidlong currentBidInCent

Auction …

currentBidInCent = ...bestBid.setValue...assert M

4. Add code for new data structure & invariants wherever old data structure is changed + compile & run tests

context Auction inv M: currentBidInCent == bestBid.valueInCent()

3. Identify invariants to relate both

5. Modify places where old data structure was used + compile & run tests

= ... currentBidInCent ... = ... bestBid.valueInCent() ...

6. Simplify + compile & run tests

7. Remove old data structure + compile & run tests

Money bestBid

Auction …

17Dr. Bernhard Rumpe

Test as observation for refactoring • Both structure and behaviour are observed by tests

test = driver and “observer”

setup &call

compare with expected result

time axis

snapshotsof the test run

observecreation

checkproperty

observeinteraction

18Dr. Bernhard Rumpe

Validation of refactorings • Observation remains invariant under refactoring

• But: structure is likely to change through refactorings• So: use proper abstractions and published interfaces for acceptance tests

Refactoring

Observation

test = driver and “observer”

System run Modified system run

19Dr. Bernhard Rumpe

Tests as abstract observation

• Unit tests check methods, single classes and small collaborations: – they need not be abstract – but may become obsolete or need to be changed as well when tested element is refactored

• Acceptance tests capture user input/observation– Tests should be as abstract as possible– Query-methods instead of direct attribute access

• more stable when data structure is changed– OCL property definitions instead of exact description of result

• descriptive properties allow a range of results– Ignoring uninteresting objects and attribute values– Observations of interesting interactions only

• sequence diagram need not show all interactions of the test– Published interfaces

20Dr. Bernhard Rumpe

Outlook and conclusion

• Integration of two major trends– UML and agile techniques

• Intelligent use of UML allows to successfully improve development

• Methodical knowledge allows more efficient processes– tests over documentation and reviews

– refactoring over big-upfront-design phase

– agile development with UML instead of plan-driven method

• Practical experience has driven this approach and will again be needed to trigger further research