Chapter 2.1
Iterative, Evolutionary, and Agile
Introduction
• We will look at Agile Modeling, UML, and iterative and
evolutionary development.
• We will also look at the RUP (Unified Process) as a popular
iterative method.
• Be certain to review section 1.6 on UML Modeling and know
how UML is used conceptually in modeling the problem
domain (Conceptual; analysis) as opposed to the solutions
domain (Specification; design UML) and Implementation.
There are examples.
Compare Domain Model Entity with Design class Diagram
DiceGame
1
Includes
2
Die
faceValue
DiceGame
die1 : Die
die2 : Die
play()
Die
2
faceValue : int
getFaceValue() : int
roll()
Conceptual Perspective
(domain model)
Raw UML class diagram
notation used to visualize
real-world concepts.
Specification or
Implementation
Perspective
(design class diagram)
Raw UML class diagram
notation used to visualize
software elements.
An Example Design Class Diagram
Three section box
Navigability
Sale
Register
1
Captures
addLineItem(…)
…
methods; parameters not specified
Date
isComplete : Boolean
1 time
makeLineItem()
Type information
Still high level. Not much detail. Only names a couple of methods
No parameters, return types – these come later after iterating a bit.
Procedure in Creating Design Class Diagrams
•
Identify all the classes participating in the software solution from Domain Model.
–
•
•
•
•
•
Remember, all entities in domain model may not be candidate classes in design model for a given application.
Domain Entities shown below.
Create Design Model by analyzing use cases and interaction diagrams. (coming later) Look at
the nouns as possible classes.
Draw Design classes in a class diagram.
Duplicate attributes from the associated concepts in the Domain Model.
(This is called a disconnected model. No relationships shown, Domain model entities shown)
Register
ProductCatalog
quantity
Store
address
name
Sale
date
isComplete
time
ProductSpecification
description
price
itemID
SalesLineItem
quantity
Payment
amount
Next in Design Class Diagram
•
Add method names by analyzing the use cases and interaction diagrams. (coming)
– The methods for each class can be identified by analyzing the interaction diagrams.
– Look at the verbs in the use cases
– Dog-eared figure is a UML Note.
Sale
If the message makeLineItem is
sent to an instance of class
Sale, then class Sale must
define a makeLineItem method.
date
isComplete
time
makeLineItem()
:Register
makeLineItem(spec, quantity)
:Sale
Continuing…
•
Add type information to the attributes and methods.
– See integer, String, boolean, and more….
Register
ProductCatalog
…
endSale()
addLineItem()
makeNewSale()
makePayment()
Store
Address: String
Name: String
addSale()
getSpecification()
ProductSpecification
Payment
description
price
itemID
amount
Sale
date
isComplete: Boolean
time
becomeComplete()
makeLineItem()
makePayment()
getTotal()
SalesLineItem
Quantity: Integer
getSubtotal()
Associations, Navigability, and Dependency Relationships
•
Add the associations necessary to support the required attribute visibility.
– Can have roles at the end of an association.
•
Navigability is a property of the role implying visibility of the source to target
class.
– Attribute visibility is implied.
– Add navigability arrows to the associations to indicate the direction of attribute
visibility where applicable.
– Common situations suggesting a need to define an association with
navigability from A to B:
• A sends a message to B.
• A creates an instance of B.
• A needs to maintain a connection to B
•
Add dependency relationship lines to indicate non-attribute visibility.
Continuing: Adding Notes
Register class will probably
have an attribute pointing to a
Sale object.
Navigability arrow indicates
Register objects are connected
uni-directionally to Sale objects.
Sale
Register
1
Captures
endSale()
addLineItem()
makePayment()
1
Date
isComplete : Boolean
time
makeLineItem()
Absence of navigability arrow
indicates no connection from
Sale to Register.
Continuing – Adding Roles (if known)
Role Names
University
Professor
Employee
Employer
Adding Navigability and Dependency Relationships
Uses
1
Store
1
address : Address
name : Text
ProductSpecification
1
description : Text
price : Money
itemID: itemID
ProductCatalog
addSale()
Contains
1
Looks-in
1
getSpecification()
1
1
Houses
1
Describes
Illustrates non-attribute visibility
1
*
Register
endSale()
enterItem()
makePayment()
1
1
Contains
Date : Date
isComplete : Boolean
time : Time
becomeComplete()
makeLineItem()
makePayment()
getTotal()
*
Logs-completed
SaleLineItem
Sale
Captures
quantity : Integer
1
getSubtotal()
Payment
amount : Money
1
Paid-by
1
Iterative and Evolutionary Development
• Often compared with a sequential or waterfall approach that deals with early
programming and testing of partial systems in repeated cycles.
• Iterations are started before all requirements are totally defined.
• Feedback on each iteration is used to lock in subsequent iterations.
• This approach is in stark contrast to waterfall approach that worked on
defining requirements up front, then design, then programming.
• Many project failures are attributed to this big bang approach.
2.1 What is the UP?
• The Unified Process is a very popular iterative software
development process.
• It is very popular for producing OOA/OOD systems
• The UP subscribes to best practices and is thus widely accepted in
practice and widely understood.
• Interesting to note that other iterative procedures such as Extreme
Programming and Scrum fit nicely within the UP.
• So why is the UP so important? (right from book)
– 1. The UP is an iterative process.
– 2. UP practices provide an example structure for how to do (and how to
explain) OOA/OOD.
– 3. The UP is flexible and can be applied to lightweight and agile approaches
that include practices from other agile methods (again, such as XP, Scrum,
and others).
2.2 What is Iterative and Evolutionary Development?
• An iteration is a time-boxed (say 3 weeks) mini-project during which an
increment of the software is developed.
– The increment is integrated into the current project.
– Each iteration has its own requirements, design, implementation, testing, etc.
• Each iteration therefore is made up of the following sequential activities:
requirements analysis, design, implementation and testing.
• The software is enlarged by increments and refined (and thus it evolves) as
we go along via feedbacks: Iterative and Evolutionary Development.
• Application grows incrementally, iteration by iteration.
• Approach is known as iterative and incremental development.
• Also known as iterative and evolutionary development.
• Be careful! : an increment is not a prototype that sometimes work and
sometimes doesn’t; it should represent a properly analysed, designed, coded
and tested chunk of the future software (otherwise?)
• Consider the next slide.
14
Requirements
Requirements
Design
Implementation &
Test & Integration
& More Design
Final Integration
& System Test
Time
Design
Implementation &
Test & Integration
& More Design
Feedback from
iteration N leads to
refinement and
adaptation of the
requirements and
design in iteration
N+1.
Final Integration
& System Test
3 weeks (for example)
Iterations are fixed in
length, or timeboxed.
The system grows
incrementally.
Fig 2.1 Iterative and Evolutionary Development
15
• Example of three-week agile iteration (may not always be suitable):
– The last iteration is debriefed and suggestion for process improvement are noted;
– Feedback from previous demonstrations and subsequent requests for change are
integrated in this iteration;
– All artifacts (use cases, UML diagrams, code …) from the previous iteration are
updated and synchronized with each other;
– Meeting clarifying the goals of the next iteration;
– Use cases may need to be refined;
– OOA is performed by the team (working by pairs via the UML using whiteboard
and capturing outcomes using a digital camera;)
– OOD is performed by the team again (probably by pairs of staff members.)
– Previous UML artifacts are updated;
– Most of the remaining days are spent on implementation and testing (with may
be re-design if necessary);
– The last day should be spent tidying up and documenting;
– (Other project management activities such as demonstration, quality evaluation,
personal issues etc. have not been detailed here)
– Measuring the success of the iteration against established criteria and assessment
must take place at the end of the iteration.
16
• There should be no rush to code nor long drawn-out alldetailed design phase : it is a project and team-dependent
compromise.
• The result of each iteration is an executable (why is this
important?) but incomplete system:
– Whatever done within an increment is part of the final system
– Increment should be high quality, suitable for release, production-grade
code and documentation;
• You will not always get it right:
– Changing a previous iteration’s code or design is inevitable and will
happen all the time (the nature of the changes are important.
– Unrealistic to believe that the code of an iteration will never change
during an entire project;
– That’s about handling change during development;
17
Change and the Embracing of Change
• Change will be needed during a project because:
–
–
–
–
What was done previously is never perfect (this is very common);
Requirements are often misunderstood (this is very common);
Requirements change (this is very common);
New requirements are discovered…
• Change will occur and is common.
• The waterfall-way of dealing with this problem is to spend
enough time during analysis to ensure that the requirements are
perfect: this is generally impossible.
18
Change and the Embracing of Change
• The UP and all other iterative approaches (Agile or not) on the
other hand try to embrace change:
– Each iteration looks at only one aspect of the project
– But done quickly and results in an executable and feedback.
• Entire detailed requirements do not need to be frozen:
– Each iteration and subsequent evaluation-feedback clarifies the
requirements that were looked at in previous iterations and also sheds
light on the requirements of the future iterations.
– The requirements are clarified as we go along: a problem solving process.
– Hence, we term this an evolutionary process.
Change and the Embracing of Change
• Stakeholders usually have changing requirements.
• Each iteration involves choosing a small subset of the
requirements and quickly design, implement and testing them.
• This leads to rapid feedback, and an opportunity to modify or
adapt understanding of the requirements or design.
• Also provides for developing increments of business value!
• But changes must not be major all the time:
– We mustn’t make major blunders in our design;
– Or completely misunderstand a requirement;
– Or accept requirement changes (new feature please!) from external sources
(client, marketing department etc.) that require a re-design.
• Changes get more difficult to accommodate as project progresses
• We want properly managed iterations during which release-grade
artifacts are produced
• Fig 2.2 tries to illustrate the evolutionary nature of an iterative
process.
21
Early iterations are farther from the "true
path" of the system. Via feedback and
adaptation, the system converges towards
the most appropriate requirements and
design.
In late iterations, a significant change in
requirements is rare, but can occur. Such
late changes may give an organization a
competitive business advantage.
one iteration of design,
implement, integrate, and test
Fig 2.2 Iterative feedback leads to an evolving system closer to the
‘real’ requirements
22
Benefits of Iterative Development (last)
– Early progress that can be evaluated;
– Early feedback, user engagement early clarifications of requirements
that will bring us closer to the ‘real’ requirements;
– Complexity containment: we proceed by chuck;
– Early tackling of risks (technical, requirements, objectives, usability etc.)
– Late total project failure less likely;
– Better productivity (especially when agile);
– Fewer defects;
23
Time Boxing and Feedback (1 of 2)
• Each iteration should be time-boxed between 2 to 6 weeks:
– If Longer: rapid feedback and adaptation is lost, complexity of task is
probably too great, falls into waterfall;
– If Shorter: quality and documentation will suffer;
– Need a rhythm! Essential
– What if we run out of time??
• If the manager feels that a deadline will not be met a recommended response
is to de-scope : remove tasks or requirements from the iteration and schedule
them to a future iteration, rather than slip the completion date (what do you
think?)
24
Time boxing and Feedback (2 of 2)
• The UP recommends short iteration lengths to allow for rapid
feedback and adaptation.
• Long iterations increase project risk.
• Iterations are fixed in length (time boxed).
• UP recommends iterations between two and six weeks
• Time boxing is in contrast to Scope Boxing