net software architects ug meeting methodology for use case development arnon rotem-gal-oz product...
TRANSCRIPT
.Net Software Architects .Net Software Architects UG MeetingUG Meeting
Methodology for Use case development
Arnon Rotem-Gal-OzProduct Line [email protected]
The king’s Ship Wasa - 1628The king’s Ship Wasa - 1628
No Architecture description Changes done on the fly,
often under market/customer pressure
Testing ignored Didn’t know how to tell the
clients No The system last longer than
was ever imagined Maintenance costs far exceed
ordinary development No Specification !
AgendaAgenda
VocabularyWhy Use Cases?Why should we care?The challenges of UC modeling in large
projectsThe Methodology Summary
VocabularyVocabulary
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
Use Cases benefitsUse 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
Use cases aren’t everythingUse cases aren’t everything
Non-behavioral requirements– Performance– Design constrains– Etc.
Sometimes – an overkill
Use cases & Architects ?!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
Use cases & Architects ?! (cont.)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
Overview Overview
Use case modeling for large projects is problematic
Most literature is lacking (too simplistic / not practical)A practical reasonable process is needed!
priorities
Team
Validate
UC Verify
Refactor
PDOM
VisionDiagram
Naïve approachNaïve approach
Find Actors
Find Use Cases
Describe Use Cases
ChallengesChallenges Model
– Duplicates– Explosion– Making sure the requirements are good
Team – Efficiency– Fragmentation
Process– Details too early– Quitting Time– Waterfall
The MethodologyThe Methodology
To resolve the challenges we need a process that is: – Ordered– Controlled– Not too complicated– Not too demanding– Flexible
Methodology – Initialization StepsMethodology – Initialization Steps
Define System BoundaryOrganize the TeamBuild a Problem Domain Object Model
Methodology - ProcessMethodology - Process
Find ActorsFind Use CasesOrganize the ModelPrioritize Use CasesDescribe Use CasesRefactor the Model
Methodology – Supporting StepsMethodology – Supporting Steps
Verify and ValidateAdd Future Requierments
Methodology – End GameMethodology – End Game
Knowing when to stop !
Step 1: Define System BoundaryStep 1: Define System Boundary
Vision and Scope– What problems are solved– Who are the stakeholders– Client’s Organization main goals– System main goals– Boundaries of the solution– Future Directions
Step 2: Organize the TeamStep 2: Organize the Team
Small teamsHeterogeneous Multi-tier reviewsRequirements manager
Step 3: Build a PDOMStep 3: Build a PDOM
Terms and relationsIterative development
Police Car
Watch
Policeman
Work in
Beat
Beat Car
Is aAllocated to
Beat Team
AreAllocated to
Drive
Police HQ
Watch Commander
Is a
Commands
Emergency CenterDistrict
Commands
Commands Has an
Rapid Response Car
Is a
Sector
Is made of
Is made of
Allocated to
Step 4: Find ActorsStep 4: Find Actors
Identify– Ask the End-Users– Documentation
Issues– Roles Vs. Job Titles– The Clock
Actor HierarchyActor Hierarchy
Emergency Center Supervisor
User
Watch Commander
Emergency Center Operator
HQ Watch Commander
Cop
User
(from Actors)
Log in
Step 5: Find Use CasesStep 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
Step 5: Find Use Cases ../2Step 5: Find Use Cases ../2
Initial Description– Unique ID– Scope– Pre conditions– Success Guarantee– Trigger
Example : Initial descriptionExample : Initial descriptionUse Case: Run Special Op.
ID: UC4
Scope: The Watch Commander chooses a Special operation to manage.The task team chosen for the operation is briefedThe watch commander then monitors the operation as it unfolds (sending out orders as needed)The task team is debriefed for the results and a final report is made.
Primary Actor: Watch Commander
Preconditions: A Special Op. Plan is saved in the system.
Success Guarantees: The Special Op. recordings (Forces movement, Voice recordings etc.) are saved in the system. The operation's statistics are saved in the system. Operation Final Report is saved and printed.
Trigger: The Watch Commander chooses a Special Op.
Step 6: Organize the ModelStep 6: Organize the Model
Ever Unfolding storyCategory sets
– Status, scope, stakeholders, sub-systemsSubject Category hierarchyViews
– Architectural view (i.e. SAD - Use Case View)
Step 7: Prioritize Use CasesStep 7: Prioritize Use Cases
Risk Classes– Business Risks– Architectural Risks– Logistical Risks
Iterative development– Small vs. Large projects
Step 8: Describe Use CasesStep 8: Describe Use Cases Template
– Main success Scenario– Variations– Exception– Assumptions– Status– Priority– Stakeholders and concerns– Issues– Non-behavioral reqs.– Extension points.
Step 8 : Describe Use Cases ../2Step 8 : Describe Use Cases ../2
Focus
Technology neutral
Activity diagrams
Step 9: Refactor the ModelStep 9: Refactor the Model
Relations– Trace (decomposition)– Include (common sub-behavior)– Extend (promoted alternatives)– Generalize
Merge droplets
Step 10: Verify & ValidateStep 10: Verify & Validate
Verification – Making sure we build the product right
Validation – Making sure we build the right product
Traceability Inspection Reviews Walkthroughs Prototypes
Step 10 : V&V ../2Step 10 : V&V ../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
Step 10: V&V ../3Step 10: V&V ../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
Step 10: V&V ../4Step 10: V&V ../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)?
Step 10: V&V ../5Step 10: V&V ../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?
Step 11: Add Future RequirementsStep 11: Add Future Requirements
Capture Change cases– Preparing for change– Impact analysis
Example: Future RequiermentsExample: Future Requierments
Step 12: Knowing When to StopStep 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
SummarySummary
What we have seen…
Additional Issues– Project Management– Requirements Management– Configuration Management
Further Reading…Further Reading…
Writing Effective Use Cases (Cockburn)Patterns for Effective Use Cases (Adolph
& Bramble)Advanced Use Case Modeling (Armour &
Miller)
The End…The End…
Questions/Full Article?Questions/Full [email protected]@cool.as
CHAOS Chronicles III - Jan. 2003CHAOS Chronicles III - Jan. 2003 Success FactorsSuccess Factors
Executive-management supportUser involvement Clear business objectivesMinimizing 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 isdedicated to solving the mystery of project success and failure”
http://standishgroup.comhttp://standishgroup.com
Example: Finding Use CasesExample: 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– Generate Emergency Center Statistics Report– Generate Crime Trends Report.
Example : Mis-Use CasesExample : Mis-Use Cases
User
(from Actors)
Log in
Tap Communications
Hacker
(from Mis-Actors)
Obtain Password
<<include>>
<<include>>
User
(from Actors)
Log in
Tap Communications
Hacker
(from Mis-Actors)
Obtain Password
<<include>>
Enforce Password Regime
Sys Admin
(from Actors)Monitor System
<<detect>>
<<detect>>
<<mitigate>>
<<include>>
Example : Use CaseExample : Use Case
Use Case: Handle Emergency Call
ID: UC24
Scope: The Operator accepts an incoming call, enters the incident information and dispatch a unit to the location of the incident
Stakeholders and Concerns: Victim - wants the police to arrive as soon as possible Beat Team – don't want to be dispatched to handle false incidents.
Primary Actor: Emergency Center Operator
Preconditions: Operator logged in.
Success Guarantees: The Call has been recorded A unit has been dispatch to investigate the incident The incident details are saved in the system
Trigger: A Citizen's incoming call has been directed by the Call Center system to an Operator.
Example : Use Case ../2Example : Use Case ../2Main Success Scenario:1.The system begins recording the call.2.The system traces the caller address.3.The Operator takes the incidents location4.The system calculates available police units.5.The Operator takes the incidents detail6.The system presents a list of available teams and their distance from the incidents estimated location.7.The Operator chooses a unit to handle the incident8.The system dispatches the incident details to the chosen team.9.The Operator takes the caller details10.The system saves the incidents details including call statistics11.The system ends recording.
Variations:1.step 2 - when the caller uses a mobile phone
a. Locate the callers current location2.step 2 - when the caller is on the black list (known to call for no reason)
a.The Operator is presented with additional questions to ask the callerb.The system marks the incident as low-priority on count of possible false alarm.
3.step 7 - when the incident does not require police intervention.a.The Operator closes the incidentb.The system saves the termination reasons and continues from step 10
4.step 7 - if the incident requires a fire truck/ambulancea. The Operator chooses which authority to notify (fire / ambulance etc)b.The system dispatches the incident details to the appropriate authority's system
Example: Use Case ../3Example: Use Case ../3Main Success Scenario:1. The system begins recording the call.2. The system traces the caller address.3. The Operator takes the incidents location4. The system calculates available police units.5. The Operator takes the incidents detail6. The system presents a list of available teams and their distance from the incidents estimated location.7. The Operator chooses a unit to handle the incident8. The system dispatches the incident details to the chosen team.9. The Operator takes the caller details10. The system saves the incidents details including call statistics11. The system ends recording.
Exceptions: 1.step 2 - when the call cannot be traced
a.The system suggests lowering the priority of the call on the count of an unknown callerb.The operator decides what priority to allocate for the incident.
2.step 6 – when there is no available free forcea.The system presents the operator with low-priority incidents (along with the reason for low-priority
3.step 8 – communication problem with the unit dispatcheda.The system performs step 6 and 7 again.
4.step 8 – communication problem with all the units.a.The system presents the operator the incidents details to allow dispatching by radio/mobile phone.
Non Behavioral Requirements: The system should present as few screen as possible to the operator Locating a free unit should take less than 30secondsCommunications to and from the unit should be secure (encrypted) to prevent eavesdropping by offenders/media
Example: Use Case LevelsExample: Use Case Levels
Service Cars
(from Service/Maintenance management)
Fix Car After Accident
(from Service/Maintenance management)
Maintain Police Cars
(from Service/Maintenance management)
Track Police Cars Usage
(from Service/Maintenance management)
<<trace>>
<<trace>>
<<trace>> Why ?How ?
Example : Refactoring Example : Refactoring Common Sub-behavior Common Sub-behavior
Find Navigation Route
(from Navigation)
Respond to Incident
(from Incidents Response)
Beat Cop
(from Actors)
Perform Assignment
(from Special Ops support)
<<include>>
<<include>>
Use Case ViewUse Case View
Concerns– What’s 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