chapter 2.1 iterative, evolutionary, and agile. introduction we will look at agile modeling, uml,...
TRANSCRIPT
![Page 1: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/1.jpg)
Chapter 2.1
Iterative, Evolutionary, and Agile
![Page 2: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/2.jpg)
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.
![Page 3: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/3.jpg)
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
![Page 4: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/4.jpg)
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.
![Page 5: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/5.jpg)
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
![Page 6: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/6.jpg)
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.
![Page 7: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/7.jpg)
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()
![Page 8: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/8.jpg)
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.
![Page 9: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/9.jpg)
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.
![Page 10: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/10.jpg)
Continuing – Adding Roles (if known)
Professor University
EmployerEmployee
Role Names
![Page 11: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/11.jpg)
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
![Page 12: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/12.jpg)
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.
![Page 13: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/13.jpg)
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).
![Page 14: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/14.jpg)
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.
![Page 15: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/15.jpg)
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
![Page 16: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/16.jpg)
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.
![Page 17: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/17.jpg)
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;
![Page 18: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/18.jpg)
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.
![Page 19: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/19.jpg)
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.
![Page 20: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/20.jpg)
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!
![Page 21: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/21.jpg)
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.
![Page 22: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/22.jpg)
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
![Page 23: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/23.jpg)
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;
![Page 24: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/24.jpg)
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?)
![Page 25: Chapter 2.1 Iterative, Evolutionary, and Agile. Introduction We will look at Agile Modeling, UML, and iterative and evolutionary development. We will](https://reader035.vdocuments.site/reader035/viewer/2022062314/56649dd05503460f94ac5e83/html5/thumbnails/25.jpg)
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