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 1 Captures Sale Date isComplete : Boolean time addLineItem(…) … Register 1 makeLineItem() Three section boxNavigability 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. 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

6. 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 :Sale makeLineItem(spec, quantity) makeLineItem() If the message makeLineItem is sent to an instance of class Sale, then class Sale must define a makeLineItem method.

7. Continuing… Add type information to the attributes and methods. –See integer, String, boolean, and more…. Register Store ProductCatalogProductSpecification 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()

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

9. Continuing: Adding Notes 1 Captures Sale Date isComplete : Boolean time endSale() 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.

10. Continuing – Adding Roles (if known) ProfessorUniversity EmployerEmployee Role Names

11. 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 11 1 1 1 * * Uses Houses Looks-in Contains Describes Logs-completed Paid-by Illustrates non-attribute visibility

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. 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. 15 Fig 2.1 Iterative and Evolutionary Development

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

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. 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. 22 Fig 2.2 Iterative feedback leads to an evolving system closer to the ‘real’ requirements

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