Rational Unified Process (Part 1)

CS3300Fall 2015

The Four P’s

• People (Roles)

• Product (Artifacts)

• Process (Templates / Workflow)

• Project (bundles everything together)

9/9/14

Definition

• Use Case Driven – Successful system must build what users want.

• Architecture Centric – Capture significant static and dynamic aspects of the system.

• Iterative and Incremental – Need to divide larger projects into smaller “mini-projects”

Phases

• Inception – Understand business case, identify use cases, feasibility, cost and planning

• Elaboration – Detailing of use cases for this iteration, refinement of system architecture (the skeleton)

• Construction – build product (put meat on the skeleton)

• Transition – Customer/User tests and interaction

• See paper for more detailed information

Inception Phase Outcomes

• A vision document: a general vision of the core project's requirements, key features, and main constraints.

• A initial use-case model (10% -20%) complete).

• An initial project glossary (may optionally be partially expressed as a domain model).

• An initial business case, which includes business context, success criteria (revenue projection, market recognition, and so on), and financial forecast.

• An initial risk assessment.

• A project plan, showing phases and iterations.

• A business model, if necessary.

• One or several prototypes.

9/9/14

Elaboration Phase Outcomes• A use-case model (at least 80% complete) — all use cases and

actors have been identified, and most usecase descriptions have been developed.

• Supplementary requirements capturing the non functional requirements and any requirements that are not associated with a specific use case.

• A Software Architecture Description.

• An executable architectural prototype.

• A revised risk list and a revised business case.

• A development plan for the overall project, including the coarse-grained project plan, showing iterations and evaluation criteria for each iteration.

• An updated development case specifying the process to be used.

• A preliminary user manual (optional).

9/9/14

Construction Phase Outcomes

• The software product integrated on the adequate platforms.

• The user manuals.

• A description of the current release.9/9/14

Transition Phase Outcomes

• Achieving user self-supportability

• Achieving stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision

• Achieving final product baseline as rapidly and cost effectively as practical

9/9/14

Final Check before next iteration:

Is the user satisfied?

Are the actual resources expenditures versus planned expenditures still acceptable?

Use Case Model

System

Withdraw Money

Deposit Money

Perform Audit

BankCustomer

Bank Manager

Additional Diagram Features

<<includes>> (like a subroutine, always executes)

<<extends>> (like an if statement, may execute)

<<precedes>> (precondition)

(generalization, specialized instance, replaces execution)

WARNING: Use this sparingly, and do not get wrapped around the axle on usage. The most important thing is the text anyway.

9/9/14

Use Case Detailed

UC1: Withdraw Money

Primary Actor: Bank Customer

Stakeholders and Interests:

-- Cashier : Wants accurate disbursement of money

-- Bank Manager : Wants audit trail of transactions

Preconditions: Customer authenticated on Bank system (UC12)

Postcondition: Customer has correct money in their possession and account is debited correct amount. Transaction entered on cashier record and on daily accounting record.

Main Success Scenario:

1. Customer requests transaction.

2. System displays transaction screen.

3. Customer selects withdrawal

4. System requests amount

5. Customer enters amount

6. System checks account for sufficient funds and daily withdraw limit

7. System opens cashier drawer

8. Cashier dispenses amount and closes drawer

9. System prints receipt

Use CaseAlternate Flows:

6A. Insufficient funds: System notifies customer and cashier of account balance and failure of transaction. Reprompts for new amount and resume 6. Customer may also cancel transaction.

6B. Daily Limit exceeded: System notifies….

Special Requirements: Cash Drawer, Customer Screen

Response within 5 seconds

Frequency of Occurrence: Could be continuous

Open Issues: Close drawer by mistake?

Your Turn

• Pick a use case appropriate to your team.

• Draw the diagram, and then detail it with name, precondition, postcondition and main success scenario

• Type the use case text into piazza

Analysis (Robustness) Diagrams

● Tie together the use case and the domain model● Graphically depict interactions between interface

elements and domain model elements● Should be able to walk through your use case

with the diagram● Use to refine use cases and domain model● Often referred to as robustness models because

they check quality of use case/domain model.

Components

● Actor – Stick figure from use cases● Boundary Elements – represent UI screens,

APIs and other interface elements● Control Elements – glue between boundary

and domain elements. Contains business logic. May or may not become classes in the design

● Domain Elements or Entities – things from the domain model that represent data in the system

Icons

● Actors – stick person

From http://iconixprocess.com/iconix-process/analysis-and-preliminary-design/robustness-analysis/

Withdraw

Bank Customer

Transaction Select UI

Withdrawal UI

Transaction Manager

Account

Cash Drawer API Printer API

Log Files

Rules

● Actors can only talk to boundary objects.● Boundary objects can only talk to controllers

and actors.● Entity objects can only talk to controllers.● Controllers can talk to boundary objects and

entity objects, and to other controllers, but not to actors

● Show alternative actions● Don't put design into diagram

Your Turn

• Now draw an analysis model of your use case.

Next Individual Homework

• Complete and Polish the Use Case Detail

• Complete and Polish the Analysis Model