.Net Software Architects UG Meeting

1
.Net Software Architects UG Meeting

• Methodology for Use case development
• Arnon Rotem-Gal-Oz
• Senior Software Architect
• arnonrgo_at_cool.as

2
The kings Ship Wasa - 1628

• No Architecture description
• Changes done on the fly, often under
  market/customer pressure
• Testing ignored
• Didnt know how to tell the clients No
• The system last longer than was ever imagined
• Maintenance costs far exceed ordinary development
• No Specification !

3
Agenda

• Vocabulary
• Why Use Cases?
• Why should we care?
• The challenges of UC modeling in large projects
• The Methodology
• Summary

4
Vocabulary

• Actor Role(s) external parties that interact
  with the system
• Use Case A sequence of actions that the system
  performs that yields an observable result of
  value to an actor. Booch 1999
• Use Case Model - Bag that contains
• Actors list, packages, diagrams, use cases, views

5
Use Cases benefits

• Promote customer involvement
• Help manage complexity
• Layers
• Focus on real user needs
• Groundwork for user manual, test cases
• Help us work in iterations

6
Use cases arent everything

• Non-behavioral requirements
• Performance
• Design constrains
• Etc.
• Sometimes an overkill

7
Use cases Architects ?!

• Requirements drive the design !!!
• Help force designers focus on concrete issues
• Help identifying technical and business risks
• Can be used to help validate the architecture

8
Use cases Architects ?! (cont.)

• Architects should be involved in (if not
  responsible for) - UC prioritization !
• Architectural design workflow (Kruchten 2003)
• Select scenarios criticality and risk
• Identify main classes/components and their
  responsibility
• Distribute behavior
• Structure into subsystems, layers and define
  interfaces
• Define distribution and concurrency
• Implement architectural prototype
• Derive tests from use cases
• Evaluate architecture

9
Overview

• Use case modeling for large projects is
  problematic
• Most literature is lacking
• (too simplistic /
• not practical)
• A practical
• reasonable
• process is needed!

Vision
Diagram
PDOM
UC
priorities
Verify
Validate
Refactor
Team
10
Naïve approach

• Find Actors
• Find Use Cases
• Describe Use Cases

11
Challenges

• Model
• Duplicates
• Explosion
• Making sure the requirements are good
• Team
• Efficiency
• Fragmentation
• Process
• Details too early
• Quitting Time
• Waterfall

12
The Methodology

• To resolve the challenges we need a process that
  is
• Ordered
• Controlled
• Not too complicated
• Not too demanding
• Flexible

13
Methodology Initialization Steps

• Define System Boundary
• Organize the Team
• Build a Problem Domain Object Model

14
Methodology - Process

• Find Actors
• Find Use Cases
• Organize the Model
• Prioritize Use Cases
• Describe Use Cases
• Refactor the Model

15
Methodology Supporting Steps

• Verify and Validate
• Add Future Requierments

16
Methodology End Game

• Knowing when to stop !

17
Step 1 Define System Boundary

• Vision and Scope
• What problems are solved
• Who are the stakeholders
• Clients Organization main goals
• System main goals
• Boundaries of the solution
• Future Directions

18
Step 2 Organize the Team

• Small teams
• Heterogeneous
• Multi-tier reviews
• Requirements manager

19
Step 3 Build a PDOM

• Terms
• and relations
• Iterative
• development

20
Step 4 Find Actors

• Identify
• Ask the End-Users
• Documentation
• Issues
• Roles Vs. Job Titles
• The Clock

21
Actor Hierarchy
22
Step 5 Find Use Cases

• Scenario Driven
• Find measurable value
• Business events
• Services actor needs / supplies
• Information needed
• Recurring
• Actor/Responsibility
• Unstructured aggregation
• Mission decomposition
• Misuse cases

23
Step 5 Find Use Cases ../2

• Initial Description
• Unique ID
• Scope
• Pre conditions
• Success Guarantee
• Trigger

24
Example Initial description
25
Step 6 Organize the Model

• Ever Unfolding story
• Category sets
• Status, scope, stakeholders, sub-systems
• Subject Category hierarchy
• Views
• Architectural view (i.e. SAD - Use Case View)

26
Step 7 Prioritize Use Cases

• Risk Classes
• Business Risks
• Architectural Risks
• Logistical Risks
• Iterative development
• Small vs. Large projects

27
Step 8 Describe Use Cases

• Template
• Main success Scenario
• Variations
• Exception
• Assumptions
• Status
• Priority
• Stakeholders and concerns
• Issues
• Non-behavioral reqs.
• Extension points.

28
Step 8 Describe Use Cases ../2

• Focus
• Technology neutral
• Activity diagrams

29
Step 9 Refactor the Model

• Relations
• Trace (decomposition)
• Include (common sub-behavior)
• Extend (promoted alternatives)
• Generalize
• Merge droplets

30
Step 10 Verify Validate

• Verification Making sure we build the product
  right
• Validation Making sure we build the right
  product
• Traceability
• Inspection
• Reviews
• Walkthroughs
• Prototypes

31
Step 10 VV ../2

• Actors
• Are all the actors abstractions of specific
  roles?
• Are all the actors clearly described, and do you
  agree with the descriptions?
• Is it clear which actors are involved in which
  use cases, and can this be clearly seen from the
  use case diagram and textual descriptions

32
Step 10 VV ../3

• Use Cases
• Does the use case make sense?
• For each iteration Are all the use cases
  described at the same level of detail?
• Are there any superfluous use cases, that is, use
  cases that are outside the boundary of the
  system, do not lead to the fulfillment of a goal
  for an actor or duplicate functionality described
  in other use cases?
• Do all the use cases lead to the fulfillment of
  exactly one goal for an actor, and is it clear
  from the use case name what is the goal

33
Step 10 VV ../4

• The Scenarios
• Are there any variants to the normal flow of
  events that have not been identified in the use
  cases, that is, are there any missing variations?
  (happy days scenarios, exceptions, variation,
  soup-opera scenarios)
• Are the triggers, starting conditions, for each
  use case described at the correct level of
  detail?
• Does the behavior of a use case conflict with the
  behavior of other use cases?
• Is the number of steps in the complex scenarios
  excessive (12 to 15 is getting borderline)?

34
Step 10 VV ../5

• Organization Prioritization
• Are all the use cases organized in an appropriate
  manner (e.g. by functional area, by dependency,
  by actor etc)?
• Are all the use cases within a package consistent
  with the theme of the package?
• Is the priority mechanism documented?
• Are the use cases prioritized correctly?

35
Step 11 Add Future Requirements

• Capture Change cases
• Preparing for change
• Impact analysis

36
Example Future Requierments
37
Step 12 Knowing When to Stop

• Project Level
• Complete list of actors and goals
• Customer approval
• Design ready
• Iteration Level
• Covered all currently prioritized use cases
• Level of detail

38
Summary

• What we have seen
• Additional Issues
• Project Management
• Requirements Management
• Configuration Management

39
Further Reading

• Writing Effective Use Cases (Cockburn)
• Patterns for Effective Use Cases (Adolph
  Bramble)
• Advanced Use Case Modeling (Armour Miller)

40
The EndQuestions/Full Article?arnonrgo_at_cool
.as
41
CHAOS Chronicles III - Jan. 2003 Success Factors

• Executive-management support
• User involvement
• Clear business objectives
• Minimizing scope
• Time is the enemy of all projects
• Scope equals time
• Firm basic requirements
• Balance between "Paralysis through Analysis" and
  what happens if requirements are not specified

CHAOS research is dedicated to solving the
mystery of project success and failure
http//standishgroup.com
42
Example Finding Use Cases

• What measurable value is needed by the actor?
• Plan Special Op.
• Monitor Special Op.
• Analyze Crime Patterns.
• What business event might this actor initiate
  (based on her role)?
• Handle Emergency Call
• Call Car for Service
• What services does the actor need from the
  system?
• Find Navigation Route
• Get Unit Status
• Map Incidents
• What services does the actor provide?
• Dispatch Units
• Issue Tickets
• What information does the actor need from the
  system?
• Get Car Registration History
• List Duties
• What are the activities that are recurring and
  triggered by time?
• Get Updated Situation Awareness Map

43
Example Mis-Use Cases
44
Example Use Case

45
Example Use Case ../2

46
Example Use Case ../3

47
Example Use Case Levels

48
Example Refactoring Common Sub-behavior

49
Use Case View

• Concerns
• Whats the conceptual framework in which the
  system operates
• What are the key processes and events that must
  be presented in the system
• Why the architecture is the way it is
• Stakeholders
• Users
• Designers Developers
• Integrate the other views