Chapter 2.1

1. Chapter 2.1 Iterative, Evolutionary, and Agile

2. 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.

3. Compare Domain Model Entity with Design class Diagram

4. An Example Design Class Diagram Three section box Navigability Sale Register Date isComplete : Boolean time 1 Captures 1 addLineItem(…) … makeLineItem() 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.

5. ProductSpecification description price itemID 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. • Duplicateattributes from the associated concepts in theDomain Model. • (This is called a disconnected model. No relationships shown, Domain model entities shown) Register Payment ProductCatalog amount quantity Sale Store SalesLineItem date isComplete time address name quantity

6. Next in Design Class Diagram • Add method names by analyzing the usecases 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() makeLineItem(spec, quantity) :Sale :Register

7. Continuing… • Add typeinformationto the attributes and methods. • See integer, String, boolean, and more…. Register ProductCatalog ProductSpecification Payment amount description price itemID … getSpecification() endSale() addLineItem() makeNewSale() makePayment() Sale SalesLineItem date isComplete: Boolean time Quantity: Integer Store becomeComplete() makeLineItem() makePayment() getTotal() getSubtotal() Address: String Name: String addSale()

8. 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 directionof attribute visibility where applicable. • Common situations suggesting a need to define an associationwith 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.

9. 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 Date isComplete : Boolean time Captures 1 1 endSale() addLineItem() makePayment() makeLineItem() Absence of navigability arrow indicates no connection from Sale to Register.

10. Professor University Continuing – Adding Roles (if known) Role Names Employee Employer

11. Adding Navigability and Dependency Relationships Uses Store 1 ProductSpecification address : Address name : Text 1 description : Text price : Money itemID: itemID 1 ProductCatalog addSale() Contains 1 1 1 Looks-in getSpecification() 1 Houses Describes Illustrates non-attribute visibility 1 1 * Register SaleLineItem Sale Captures Contains Date : Date isComplete : Boolean time : Time quantity : Integer 1 1 endSale() enterItem() makePayment() 1 getSubtotal() becomeComplete() makeLineItem() makePayment() getTotal() Payment amount : Money * 1 Logs-completed Paid-by 1

12. 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.

13. 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. 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 codenor 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.

19. Change and the Embracing of Change • The UP and all other iterative approaches (Agile or not) on the other hand try to embracechange: • 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 clarifiestherequirements 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 evolutionaryprocess.

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

25. Time boxing and Feedback (2 of 2) • The UP recommends shortiterationlengths 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