Rational Unified Process (Part 1) CS3300 Fall 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 Bank Customer Bank Manager

Additional Diagram Features > (like a subroutine, always executes) > (like an if statement, may execute) > (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 Case Alternate 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

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