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

Jan 8, 2003 91.3913 Ron McFadyen 1

•Waterfall

•Spiral

•UP

•Case study

•UML

•Use Cases


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

5, 593-4


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

•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



•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


Figure 2.3 illustrates the 4 phases comprising the UP

More requirements gathering More programming



•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 21-23

•Elaboration 3

•Chapters 24-34

note that Ch 3 gives you an introduction to the case study


Figure 2.4 Illustrates the activities in UP used to develop a system

•Iterative development is central to the UP

Use cases

Domain modeling


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


NextGen POS

Typical systems are designed in terms of a layered architecture

Figure 3.1


NextGen POSEventually, 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”.

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


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


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


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


Use Cases

Ch 6. Use Case example on page 50-53 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 <<extend>> and <<include>>

must read: sections 25.1, 25.2, 25.3, 25.5


•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


•numerous textual forms

•brief, casual, fully dressed

•single- vs two-column form

•common format at www.usecases.org

Use Cases

http://www.usecases.org/




Use CaseUse Case: Rent Items

Typical Course of Events

Actor Intentions System Responsibility

1. Customer arrives at a checkout with videos (and/or less often, video games) to rent.

2. The Customer presents their membership identification to the Clerk, who enters it into the system.

3. Presents membership information, and status of loans (usually nothing on loan, and no outstanding fines).

4. For each video or game, the Clerk records the item identification into the system.

5. Presents accumulating list of rental item titles, due dates, total rental fee, and any late charges.

6. Clerk informs Customer of total charge, and asks for payment.

7. Customer pays Clerk by cash or credit.

8. Clerk records payment into system. 9. If a credit payment, authorizes it.

10. Generates receipt and loan report.

11. Clerk gives receipt and loan report to Customer, who then leaves with the rental items.

Alternative Courses

Step 7. Customer has insufficient cash. Request a credit payment, cancel the transaction, or deduct rental items until transaction can be paid for.

Step 7: Customer has unpaid late charges and will not pay them. Customer must pay them before renting more items, so either collect full payment, or cancel the transaction.

Step 9. Failure to authorize credit payment, either because of insufficient credit or inactive authorization service. Request cash payment instead.

2-column format

Main success scenario:

Alternate scenarios:


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


An Order-Processing

SystemPlace order

Send catalog

Cancel order

Return product

Deliver product

Customer

Customer Rep

Shipping company

Clerk

Get Order status

Calculate postage

Use Cases Diagrams

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

Documents

Transcript of Jan 8, 200391.3913 Ron McFadyen1 Waterfall Spiral UP Case study UML Use Cases.