1 / 49

.Net Software Architects UG Meeting

.Net Software Architects UG Meeting. Methodology for Use case development Arnon Rotem-Gal-Oz Product Line Architect arnon@rgoarchitects.com. The king’s Ship Wasa - 1628. No Architecture description Changes done on the fly, often under market/customer pressure Testing ignored

sbaumgardner
Download Presentation

.Net Software Architects UG Meeting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. .Net Software Architects UG Meeting Methodology for Use case development Arnon Rotem-Gal-Oz Product Line Architect arnon@rgoarchitects.com

  2. The 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 !

  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 aren’t 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 • Client’s 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 : 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

  32. Step 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

  33. Step 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)?

  34. Step 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?

  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 End…Questions/Full Article?arnonrgo@cool.as

  41. CHAOS Chronicles III - Jan. 2003Success 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 • Generate Emergency Center Statistics Report • Generate Crime Trends Report.

  43. Example : Mis-Use Cases

  44. Example : Use Case

  45. Example : Use Case ../2

  46. Example: Use Case ../3

  47. Why ? How ? Example: Use Case Levels

  48. Example : Refactoring Common Sub-behavior

  49. Use 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

More Related