agile software development with the uml bernhard rumpe software & systems engineering fakultät...
Post on 21-Dec-2015
215 views
TRANSCRIPT
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