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
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.
2
Die faceValue : int
getFaceValue() : int roll()
DiceGame die1 : Die
die2 : Die play()
DiceGame Die
faceValue Includes 2
1
An Example Design Class Diagram
Captures 1
Sale Date
isComplete : Boolean time
addLineItem(…)
…
Register
1
makeLineItem()
Three section box Navigability
methods; parameters not specified 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
Store
ProductCatalog
SalesLineItem quantity Sale
Payment
address name
date
isComplete time
amount quantity
ProductSpecification description price
itemID
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 date
isComplete time
:Register makeLineItem(spec, quantity) :Sale makeLineItem() If the message makeLineItem is
sent to an instance of class Sale, then class Sale must
define a makeLineItem method.
Continuing…
• Add type information to the attributes and methods.
– See integer, String, boolean, and more….
Register
Store
ProductCatalog ProductSpecification
SalesLineItem Quantity: Integer Sale
Payment
Address: String Name: String
date
isComplete: Boolean time
amount
… description
price itemID endSale()
addLineItem() makeNewSale() makePayment()
getSpecification()
becomeComplete() makeLineItem() makePayment() getTotal()
getSubtotal()
addSale()
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
Captures 1
Sale Date
isComplete : Boolean endSale() time
addLineItem() makePayment()
Register
1
makeLineItem() Register class will probably
have an attribute pointing to a Sale object.
Navigability arrow indicates Register objects are connected uni-directionally to Sale objects.
Absence of navigability arrow
indicates no connection from
Sale to Register.
Continuing – Adding Roles (if known)
Professor University
Employer Employee
Role Names
Adding Navigability and Dependency Relationships
1
Captures 1
endSale() enterItem() makePayment()
Register
ProductSpecification description : Text price : Money itemID: itemID
SaleLineItem quantity : Integer getSubtotal()
Payment amount : Money ProductCatalog
getSpecification()
Sale
becomeComplete() makeLineItem() makePayment() getTotal() Date : Date
isComplete : Boolean time : Time
address : Address name : Text
Store
addSale()
1
1
1
1
1
1
1
1 1 1
1
1
*
* Uses
Houses
Looks-in
Contains
Contains
Describes
Logs-completed Paid-by
Illustrates non-attribute visibility
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).
14
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.
15 Requirements
Design
Implementation &
Test & Integration
& More Design Final Integration
& System Test
Requirements Design
3 weeks (for example)
The system grows incrementally.
Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration N+1.
Iterations are fixed in length, or timeboxed.
Time
Implementation &
Test & Integration
& More Design Final Integration
& System Test
Fig 2.1 Iterative and Evolutionary Development
16
• 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.
17
• There should be no rush to code nor long drawn-out all- detailed 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;
18
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.
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!
21
• 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.
22
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
23
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;
24
