Jan 8, Ron McFadyen1 Waterfall Spiral UP Case study UML Use Cases

Jan 8, Ron McFadyen2 design analysis implementation testing maintenance Waterfall Development Process Linear one phase is completed before the next begins in practice, must revise earlier decisions based on experience in project - I.e. there is feedback Page 25, 593-4

Jan 8, Ron McFadyen3 design analysis implementation testing maintenance Waterfall Development Process Not iterative errors in earlier phases are really expensive to fix doesn’t allow for prototyping which is a strong aid for confirming requirements

Jan 8, Ron McFadyen4 A Generic Spiral Process for Development Evaluate Analyze risks / plan Engineer (design, implement, test) Analyze requirements for this iteration 4 phases comprise one iteration arbitrary number of iterations user involvement early feedback Studies show more successes with an iterative approach

Jan 8, Ron McFadyen5 Unified Process (UP) Defined by Rational Corporation An iterative development process an iteration yields a working system iterations last anywhere from 2 weeks to 6 months many iterations make a project early visible progress, feedback Risk-driven early iterations prove out the major risks or show-stoppers Pages 13-22

Jan 8, Ron McFadyen6 Unified Process (UP) Each iteration involves choosing a small subset of the requirements, and designing, implementing, testing. Deliverables are referred to as artifacts - (use cases, models, code, database designs, …) iterations are organized into 4 phases inception, elaboration, construction, transition

Jan 8, Ron McFadyen7 Figure 2.3 illustrates the 4 phases comprising the UP More requirements gatheringMore programming

Jan 8, Ron McFadyen8 Unified Process (UP) Inception Feasibility is considered Use case model is started Chapters 4-8 for the text’s case study Elaboration 1 Chapters 9-20 Elaboration 2 Chapters Elaboration 3 Chapters note that Ch 3 gives you an introduction to the case study

Jan 8, Ron McFadyen9 Figure 2.4 Illustrates the activities in UP used to develop a system Iterative development is central to the UP Use cases Domain modeling

Jan 8, Ron McFadyen10 NextGen POS (Ch 3) Retail store Record sales Handle payments Hardware computer bar code scanner software Interfaces to service applications Tax calc Inventory control Client-side – web browser, Java Swing gui,... Commercial application – sell to different clients - needs to be flexible for customization

Jan 8, Ron McFadyen11 NextGen POS Typical systems are designed in terms of a layered architecture Figure 3.1

Jan 8, Ron McFadyen12 NextGen POS Eventually, we’ll end up with a model:

Jan 8, Ron McFadyen13 Unified Modeling Language (UML) Booch, Rumbaugh, Jacobson (the 3 Amigos) joined forces (all work for Rational) to create a unified development method/process, from which came the Unified Modeling Language (UML) Not a methodology Methodologies can use UML examples: Rational’s Unified Process; Catalysis Value of UML is in the common language IT professionals have for expressing the nature of a system

Jan 8, Ron McFadyen14 Use Cases Introduced by Ivar Jacobson in 1986 literal translation from Swedish ”usage case”. “blackbox” style is recommended - specify what the system must do, and not how it must do it. A project may begin with the definition of many “brief” or “casual” use case definitions. Later on, these can be become “fully dressed”. The Use Case Model is the set of all use cases; it is a model of the system’s functionality and environment.

Jan 8, Ron McFadyen15 Use Cases Widely used. Not just an OO technique. Each Use Case will meet one or more user goals Stories of using a system to meet goals 2 Forms: diagrams, textual – simplicity is important, both used Various styles used for textual forms brief casual fully dressed

Jan 8, Ron McFadyen16 brief Cancel Order Use Case When the customer rep receives a request to cancel an order, the customer rep finds the order in the system and marks it canceled. Then a request is sent to the accounting system to credit the customer’s account Use Cases

Jan 8, Ron McFadyen17 More formally, not quite fully dressed Cancel Order Use Case 1. The use case begins when the customer rep receives a request to cancel an order 2. The customer rep enters an order ID 3. The customer rep presses Find 4. The system will display that order 5. The system marks the order canceled 6. The accounting system is notified to credit the customer’s account and the use case ends Use Cases

Jan 8, Ron McFadyen18 Use Cases Ch 6. Use Case example on page is very lengthy and fairly complete must read: pages 45-61, and sections 6.12, 6.13, 6.15 Jump ahead to Ch 25 to see more ways of managing Use Cases. Ch 25. Use Case has been broken down into multiple Use Cases that are related via > and > must read: sections 25.1, 25.2, 25.3, 25.5

Jan 8, Ron McFadyen19 Use Case is initiated by an Actor Describes functional requirements from the user’s perspective Illustrates actors & tasks Forms: pictorial (defined in UML) textual not defined in UML recommended to leave UI details out and focus on the purpose of the use case focus on what the system does, not how (black box) Use Cases

Jan 8, Ron McFadyen20 numerous textual forms brief, casual, fully dressed single- vs two-column form common format at Use Cases

Jan 8, Ron McFadyen21 2-column format Main success scenario: Alternate scenarios:

Jan 8, Ron McFadyen22 An actor is anyone or thing that interacts with the system. These people or things are at the boundaries of the system. Use cases are represented with ovals. Instructor Student Assign duties Assign grades Register for courses Browse enrollments Chair Billing Its common to place non-human roles on the RHS Use Cases Diagrams

Jan 8, Ron McFadyen23 An Order- Processing System Place order Send catalog Cancel order Return product Deliver product Customer Customer Rep Shipping company Clerk Get Order status Calculate postage Use Cases Diagrams