.Net Software Architects UG Meeting - PowerPoint PPT Presentation

1 / 49
About This Presentation
Title:

.Net Software Architects UG Meeting

Description:

Trace (decomposition) Include (common sub-behavior) Extend (promoted ... step 2 - when the caller uses a mobile phone. Locate the callers current location ... – PowerPoint PPT presentation

Number of Views:59
Avg rating:3.0/5.0
Slides: 50
Provided by: Rotem2
Category:

less

Transcript and Presenter's Notes

Title: .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
Write a Comment
User Comments (0)
About PowerShow.com