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

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

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

Unified Process (UP) Defined by Rational Corporation Booch, Rumbaugh, Jacobson An iterative development process an iteration yields a working system iterations last anywhere from 2 weeks to 6 months many iterations make a project risk-driven early iterations prove out the major risks or show- stoppers

Unified Process (UP) several activities deliverables are referred to as artifacts - works produced (use cases, code, database designs, …) 4 phases inception, elaboration, construction, transition Inception Use case model is started

Figure 2.4 Illustrates the activities in UP used to develop a system Iterative development is central to the UP

Figure 2.3 illustrates the 4 phases comprising the UP More requirements gatheringMore programming

NextGen POS Record sales Handle payments Retail store Interfaces to service applications Tax calc Inventory control Client – web browser Commercial application – sell to different clients

NextGen POS Layered architecture

NextGen POS Eventually, we’ll end up with a model:

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

Use Cases Introduced by Ivar Jacobson in 1986 literal translation from Swedish ”usage case” - may be of use to you in the future “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”

Use Cases Widely used. Not just an OO technique. Each Use Case will meet one or more user goals Collectively, Use Cases represent the functionality required by a system. Stories of using a system to meet goals

Use Cases Ch 6. Use Case example 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

Use Cases a Use Case is initiated by an Actor Describes functional requirements from the user’s perspective illustrate 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 it does it (black box)

Use Cases numerous textual forms brief, casual, fully dressed single- vs two-column form common format at Risks/dangers when using use cases: too much focus on functionality may lead to non- OO system

Actors An actor is anyone or thing that interacts with the system. These people or things are at the boundaries of the system. Suppose our system interacts with a billing system: Instructor Student Assign duties Assign grades Register for courses Browse enrollments Chair Billing Its common to place non-human roles on the RHS

Use Case Diagram

An Order-Processing System Place order Get Order status Send catalog Cancel order Return product Deliver product Send us product Calculate postage Customer Customer Rep Shipping company Supplier Clerk

Scenarios A scenario refers to a single path through a use case, one that shows a particular combination of conditions within that use case. Consider a Use Case for ordering goods: Several associated scenarios: one in which all goes well one in which there are not enough goods one in which our credit is refused etc

Scenarios A Scenario is an instance of a Use Case. Hence, each Use Case usually has many possible Scenarios For example, two scenarios for Assign grades: Instructor Jim Jones assigns the grade of A+ to student Eddy Match in the course Intro to Warehousing. Instructor Jim Jones tries to assign the grade of B to student Edward Watson in the course Intro to Warehousing, but cannot because there is no record of Edward’s registration in the course.