50 %
50 %
Information about UCMethodology

Published on April 18, 2008

Author: Vincenza

Source: authorstream.com

.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:  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 ! Agenda:  Agenda Vocabulary Why Use Cases? Why should we care? The challenges of UC modeling in large projects The Methodology Summary Vocabulary:  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 Use Cases benefits:  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 Use cases aren’t everything:  Use 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 Vision Diagram Naïve approach:  Naïve approach Find Actors Find Use Cases Describe Use Cases Challenges:  Challenges Model Duplicates Explosion Making sure the requirements are good Team Efficiency Fragmentation Process Details too early Quitting Time Waterfall The Methodology:  The Methodology To resolve the challenges we need a process that is: Ordered Controlled Not too complicated Not too demanding Flexible Methodology – Initialization Steps:  Methodology – Initialization Steps Define System Boundary Organize the Team Build a Problem Domain Object Model Methodology - Process:  Methodology - Process Find Actors Find Use Cases Organize the Model Prioritize Use Cases Describe Use Cases Refactor the Model Methodology – Supporting Steps:  Methodology – Supporting Steps Verify and Validate Add Future Requierments Methodology – End Game:  Methodology – End Game Knowing when to stop ! Step 1: Define System Boundary:  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 Step 2: Organize the Team:  Step 2: Organize the Team Small teams Heterogeneous Multi-tier reviews Requirements manager Step 3: Build a PDOM:  Step 3: Build a PDOM Terms and relations Iterative development Step 4: Find Actors:  Step 4: Find Actors Identify Ask the End-Users Documentation Issues Roles Vs. Job Titles The Clock Actor Hierarchy:  Actor Hierarchy Step 5: Find Use Cases:  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 Step 5: Find Use Cases ../2:  Step 5: Find Use Cases ../2 Initial Description Unique ID Scope Pre conditions Success Guarantee Trigger Example : Initial description:  Example : Initial description Step 6: Organize the Model:  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) Step 7: Prioritize Use Cases:  Step 7: Prioritize Use Cases Risk Classes Business Risks Architectural Risks Logistical Risks Iterative development Small vs. Large projects Step 8: Describe Use Cases:  Step 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 ../2:  Step 8 : Describe Use Cases ../2 Focus Technology neutral Activity diagrams Step 9: Refactor the Model:  Step 9: Refactor the Model Relations Trace (decomposition) Include (common sub-behavior) Extend (promoted alternatives) Generalize Merge droplets Step 10: Verify & Validate:  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 Step 10 : V&V ../2:  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 Step 10: V&V ../3:  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 Step 10: V&V ../4:  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)? Step 10: V&V ../5:  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? Step 11: Add Future Requirements:  Step 11: Add Future Requirements Capture Change cases Preparing for change Impact analysis Example: Future Requierments:  Example: Future Requierments Step 12: Knowing When to Stop:  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 Summary:  Summary 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… Questions/Full Article? arnonrgo@cool.as :  The End… Questions/Full Article? arnonrgo@cool.as CHAOS Chronicles III - Jan. 2003 Success Factors:  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 Example: Finding Use Cases:  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. Example : Mis-Use Cases:  Example : Mis-Use Cases Example : Use Case:  Example : Use Case Example : Use Case ../2:  Example : Use Case ../2 Example: Use Case ../3:  Example: Use Case ../3 Example: Use Case Levels:  Example: Use Case Levels Example : Refactoring Common Sub-behavior :  Example : Refactoring Common Sub-behavior Use Case View:  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

Add a comment

Related presentations

Related pages

Earth Science - UC Santa Barbara

Yann Ricard, Graduate Program Coordinator Department of Earth Science 1006 Webb Hall Santa Barbara, CA 93106-9630 ...
Read more

Ipswich Local Development Framework

Urban Capacity Study Ipswich Local Development Framework January 2008 Planning Transport & Regeneration, Ipswich Borough Council, Grafton House,
Read more

Unified Content Software Methodology

Introduce a new species of software development methodology, called Unified Content, not heavyweight, not lightweight, but rightweight methodology.
Read more

Research - LANGHORST and COLLEAGUES, - Positive Health Online

Research: LANGHORST and COLLEAGUES, Listed in Issue 213. Abstract. LANGHORST and COLLEAGUES, ... (UC). Methodology. The authors performed a randomized, ...
Read more


PRODUCTION RECONCILIATION FOR MINERAL RESOURCE ... UC Methodology In the univariate case, the change of support is based on the three assumptions (DGM):
Read more

The UC approach: an application view - eprint.iacr.org

1 The UC approach: an application view István Vajda February 15, 2013 Abstract: What kind of guidelines can the UC approach provide for traditional
Read more

Practice Parameters for the Surgical Treatment of ...

ment for the patient with uC. METHODOLOGY ... Practice Parameters for the Surgical Treatment of Ulcerative Colitis Howard Ross, M.D. • Scott R. Steele, ...
Read more

Survey Analysis: Organizations' Unified Communications ...

Survey Analysis: Organizations' Unified Communications ... Which Communication Platforms Will Continue to Be Utilized as Organizations Move to UC? Methodology
Read more

Earth Science - Education | Earth Science - UC Santa Barbara

Earth Science - Education . Graduate Program. The goal of the Graduate program is to equip budding scientists for their future roles as independent ...
Read more

Methodology - public history (starting a house museum) B ...

Methodology - public history (starting a house museum) B. Evidence - documentary, built from HIST 367 at UNC
Read more