Defining and Validating Use Cases with UML …...Proving Use Cases Correct: Defining and Validating...

Proving Use Cases Correct:Defining and Validating Use Cases with UML

Presented by Alan Cline, PMPMay 16, 2011

[email protected]

www.carolla.com

Agenda

• Motivation: Current state of the art• Source of use cases: requirements’ lifeline• A proper use case• Validating use cases with UML• A note about agile and iterative

development

5/16/20114

Agenda• Motivation: Current state of the art• Source of use cases: requirements’ lifeline• A proper use case• Validating use cases with UML• A note about agile and iterative

development

Requirements’ Lifeline(In order of progressively-elaborated scope)

What must come before:1. Collect project sponsor’s mission statement -- defines

overall scope (and financial boundaries)2. Collect stakeholders’ expectations (and objectives) --

defines success criteria when used w/ mission statement3. Draw solution context diagram with stakeholders

• Defines what is in and out of scope; boundary is arbitrary business decision, defines limits of project responsibility

• Defines high-level data into / from the system• Each arrow indicates workflow and 1: M use cases

ATM Context Diagram

ATM System

Customer

Admin

Bank Data Systems

Cash, Identification, Cashbox Init

Amount

Cashbox Balance, Deposit Envelopes,

Reconcilement Report

Identification, Transactions, Cash,

Checks, Money Orders

Cash, Receipt, Account Balance

Customer Profiles, Accounts

Account Updates, Session Log

8

Requirements’ Lifeline(in order of progressively-elaborated scope)

What must be done once:4. Elicit business workflow

• Tie workflow I/O into arrows of context diagram• Workflow defines superset of all use cases (UML state diagram

or activity diagrams)5. Define Use Case catalog

• Listing of all use case descriptions and objectives• Fragment workflow into use case descriptions • Entire workflow must be decomposed for use case completeness• In agile, same as user story master list

ATM Activity DiagramATM UML Activity Diagram Activity

10

Requirements’ Lifeline(Iteration package)

What must be repeated:o Select use cases to include in packageo Define object model for problem domain (UML class

diagrams)o Elicit detailed use cases in package with stakeholderso Use orthogonality to validate use cases

--Use cases use functional decomposition--Object modeling uses scope-of-control decomposition--Tracing a use case through the object model exercises the

orthogonality mathematics: consistency means correctness-- UML is used for validation and use case correctness


development

IEEE Requirements for a Proper Use Case

• Clear, concise, and unambiguous• Complete, with references and exhaustive lists of inputs and outputs

• Consistent in units, terminology, format, with logical progression and agreement between sections

• Testable, providing adequate information to derive test cases (NEBS method)

• Buildable, facilitating design and coding (UML extensions)

• Modifiable, designed for change, modular

• Documentable, usable for creating user manuals

• Operational, usable after the product is in production

Sample Use Case:

ATM Withdraw


development

Rules for Correct Analysis• Rule Development

– Ivar Jacobsen: UML as visual proof language– Chris Kemerer: dynamic metrics – Arthur Riel: summarized rules in “Object

Oriented Design Heuristics”• Rules cover inheritance, components, aggregation,

operations, attributes, state, relational and object integrity

• Analysis is not design--during design, expedience outweighs rigor

• Skilled BA may prove requirements correct!

Procedure for UML Validation

• Cross-check use cases (functional) through requirements model (scope-of-control)

• Simulate use case with sequence diagram to execute class operations

• Client-server model: Caller object must pass data required by the operation of the called object

• One sequence diagram per use case path• Optimum: simulate PDC objects; defer other

components to design

21

• OOA is performed on the problem domain• HIC, DMC, and SIC are more design centered• OOD performed on all components after OOA• Components communicate through messaging

ATM UML Class Diagram for PDC

Requirements Validation Approach

Scope Workflow

Functional Decomp

Scope-of-Control Decomp

Functional Validation

Sponsor’s Mission Statement

Solution Context Diagram

Stakeholder Expectations

To-be-Process Maps

(UML Activity dgms or state charts)

Use Cases

UML analysis class dgms

UML analysis class specs

UML analysis sequence diagrams

Verified Consistency

Orthogonality Example: Simple Spreadsheet

ATM Withdraw Use Case (UML Sequence Diagram)

Results of UML Validation• Verifies existence of required support data• Reveals missing classes, operations, data• Reveals missing use case logic and data• Reveals missing classes, operations, and data• Foundation for transforming use cases into test cases

(NEBS method)• Foundation for extending analysis model into design

model• Change use cases, class diagram, or sequence diagrams

until all consistent to prove correctness.


development

Why would anyone want to do agile?

How much time, effort, or money do youwant to spend on Quality?

King Xerxes’ Warship Canal

“…the best man, in my belief, is he who lays his plans warily, with an eye for every disaster which might occur, and then, when the time comes, act boldly.”

-- General Artabanus, advisor to King Xerxes, c 480 BC.

King Xerxes’ Warship Canal

“Certainty, surety, is beyond human grasp. But however that may be, the usual thing is that profit comes to those who are willing to act, not to the overcautious and hesitant.”

-- King Xerxes, in reply to General Artabanus, c 480 BC.

Results of QSM Study• 2006 study included 565 recent projects from 31 corp., 16

industries, 16 countries; project database of 7000 projects over last 30 years.

• 30 person teams do not finish significantly faster than 3 person teams for same size project!

• 30 person teams develop 6 times more defects than 3 person teams for same size project!

-- “Software: Hard Data,” Phillip Armour, Communications of the ACM, Sept 2006

• Implicated: Brook’s Law (communications, training, and mgmt overhead, perhaps explaining why agile doesn’t scale well

Risk vs. Rigor by Project Method

Risk

Rigor

Features User Stories

Use Cases + Requirements Modeling

IUT + Use Cases

TDD + User Stories

TDD = Test-Driven Development

IUT = Integrated Unit Testing

Effort vs Planning by Project MethodE

ffor

t

Planning

Waterfall Extreme Programming

PDC modeling with TDD coding

All-component modeling

Ran

dom

Act

s of

Con

stru

ctio

n

Various Agile Techniques

Planning Overhead

Refactoring Overhead

References• Armour, Phillip, “Software: Hard Data,” Communications of the ACM,

Sept 2006• Beck, Kent, “Extreme Programming Explained”, Addison-Wesley,

2000• Boehm, Barry, “Software Engineering Economics”, Prentice-Hall,

1981• Booch, Grady, Jim Rumbaugh, and Ivar Jacobson, “Unified Modeling

Language User Guide”, Addison-Wesley, 1999 • Gibbs, W, Wayt, “Software’s Chronic Crisis”, Scientific American,

September, 1994 • Fowler, Martin, et al, “Refactoring”, Addison-Wesley, 2000• Fowler, Martin, “UML Distilled” 3/e, Addison-Wesley, 2004

References• IEEE Std. 830-1998, “IEEE Recommended Practice for Software

Requirements Specifications, IEEE, 1998• Kemerer, Chris, and Shyam Chidamber, “A Metrics Suite for Object-

Oriented Design”, MIT, 1993• Meyer, Bertrand, “Object-Oriented Software Construction”, Prentice-

Hall, 1998• Riel, Arthur, “Object-Oriented Design Heuristics”, Addison-Wesley,

1996• Satzinger, John W, Robert Jackson, and Stephen Burd, “Systems

Analysis and Design in a Changing World”, 3/e, Course Technology, 2004

• Welsh, Nancy and Alan Cline, “The ATM Project in Java”, Carolla Development, 2005

Questions?If you have questions for Alan, please submit them in the Q&A function at the bottom right hand side of your screen.

If we do not get to your question, they will be answered by Alan and posted to the ASPE-SDLC blog. You will receive a link to that blog post in the next few days, along with a copy of today’s slides and a link to the recording of today’s seminar.

How to Claim Your PDU

• Go to ccrs.pmi.org/• Search for ASPE as a Registered Education

Provider. Our number is 2161• At the bottom of our details page, select “See

Provider’s Activities”• Find the activity code stated by the moderator

during the presentation: WS051611• The seminars are Category A for one PDU

Defining and Validating Use Cases with UML …...Proving Use Cases Correct: Defining and Validating...

Documents

Transcript of Defining and Validating Use Cases with UML …...Proving Use Cases Correct: Defining and Validating...