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() : introll()

DiceGame

die1 : Diedie2 : Die

play()

DiceGame Die

faceValue

Includes 21

An Example Design Class Diagram

1Captures

Sale

DateisComplete : Booleantime

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 methodsNo 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

addressname

dateisCompletetime

amountquantity

ProductSpecificationdescriptionpriceitemID

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

dateisCompletetime

:Register :SalemakeLineItem(spec, quantity)

makeLineItem()

If the message makeLineItem issent to an instance of classSale, then class Sale mustdefine 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: StringName: String

dateisComplete: Booleantime

amount… descriptionpriceitemIDendSale()

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

1Captures

Sale

DateisComplete : Booleantime

endSale()addLineItem()makePayment()

Register

1

makeLineItem()

Register class will probablyhave an attribute pointing to aSale object.

Navigability arrow indicatesRegister objects are connecteduni-directionally to Sale objects.

Absence of navigability arrow indicates no connection fromSale to Register.

Continuing – Adding Roles (if known)

Professor University

EmployerEmployee

Role Names

Adding Navigability and Dependency Relationships

1

Captures

1

endSale()enterItem()makePayment()

Register

ProductSpecification

description : Textprice : MoneyitemID: itemID

SaleLineItem

quantity : Integer

getSubtotal()

Payment

amount : Money

ProductCatalog

getSpecification()

Sale

becomeComplete()makeLineItem()makePayment()getTotal()

Date : DateisComplete : Booleantime : Time

address : Addressname : 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

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?)

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