Download
goal directed analysis with use cases n.
Skip this Video
Loading SlideShow in 5 Seconds..
Goal Directed Analysis with Use Cases PowerPoint Presentation
Download Presentation
Goal Directed Analysis with Use Cases

Goal Directed Analysis with Use Cases

105 Vues Download Presentation
Télécharger la présentation

Goal Directed Analysis with Use Cases

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Goal Directed Analysis with Use Cases Journal of Object Technology William N. Robinson and Greg Elofson Presented by Chin-Yi Tsai cyt@pmlab.iecs.fcu.edu.tw http://140.134.26.25/~cyt

  2. Outline • Modeling with Goals • A Goal-Oriented Method • Defining System Goals and Requirements • Deriving Use-Cases • Elevator Requirements • Discussion

  3. Concept • Use cases are touted as means to manage the complexity of object-oriented software specification. • The UML Use Case relationship • It is difficult to determine the scope of a single use case, as well as define its elaborations. However Define a goal-directed modeling approach based upon functional definition for domain property, goal, requirement, and specification. Helps manage specification complexity.

  4. Modeling with Goals • Software specification by use cases has grown with the popularity of object-oriented software engineering. • Four foundational definition to the description of software systems • A goal is a desired property of the environment • A domain property is a property that exists naturally in the environment • A requirement is a special kind of goal that constrains the software behavior • A specification is special kind of requirement that only reference system properties.

  5. Goal-Oriented Modeling • Goals are used in a variety of ways to analyze software systems. • Van Lamsweerde • Goals derive the elaboration of requirements to support them. • Requirement “implement” goals much the same way as programs implement design specification

  6. Goal-Oriented Modeling (cont’d) • Object-oriented analysis • Define use case to satisfy goals • Goal has different abstraction level • Five opportunities for goals • Attach non-functional requirements to goal • Track the project by goals • Get subtle requirements from goal failure • Use goal with responsibility-based design • Match user goals to operational concept • Goal can assist in choosing parameters from the object model • Sometimes goals are called features • A service the system provides to fulfill one or more stakeholder needs System goal User goal subfunction

  7. A Goal-Oriented Method • Define a method for deriving UML specifications from goals. • The method is synthesis of common UML methods • RUP • Goal-oriented requirements analysis method • KAOS

  8. Method Goal-Directed Analysis with Use Cases • Elicit the system context • Define the system goals • Derive requirements • Derive use cases • Derive UML models • Elicitation is common to all system analysis methods • Defining goals and deriving requirement is common to goal-oriented method • Defining use case at varied abstraction levels and deriving their associated models is common to object-oriented methods.

  9. Benefit (adding goals to UML method of analysis) • Abstraction • Goals provide high-level, functional and non-functional, understandable descriptions of what the system shall do, without the complexity of describing how the system works. • Direction • Goals provide analysis with a checklisk of activities to complete • Traceability • Bridge linking stakeholder request to system specification • Analysis • Provide a means to analyze the system prior to its construction

  10. goal Refine Add detail Defining System Goals and Requirements • Analysts define desired properties of the environment, or goal, based on stakeholder need. • Analysts refine goals by adding details, which typically constrain the software • requirements can be derived from goal by refinement

  11. Defining System Goals and Requirements (cont’d) • Analysts structure goals according to how they relate to each other. • Provide a hierarchical structuring of goals • To define a goal hierarchy • One initial goal • Two questions : how? and why?

  12. Refinement Patterns • Basic • Disjunction (or) • Conjunction (and) • Milestone • Case-based

  13. When to stop asking How? • Ideally, requirements are a minimal set of description that constrain the system behavior as a means to bring about desired properties of the environment. • Only necessary

  14. Deriving Use-Cases • In UML, a use case describes a sequence of action a system performs that yield a result of value to a particular actor. • Difference level of abstraction • Three common use case type • Organizational use cases • Task use cases • Low-level use case • Consider use cases based on goal statement as abstract, and use cases based on requirements or specifications are concrete

  15. Deriving Use-Cases (cont’d) • Analysts derive use cases from the goal hierarchy. Consider each node: • If it has sub-goals, then an abstract use case can be defined with the sub-goals as use case steps • If is has sub-requirements, then a concrete use case can be defined with the sub-requirements as use case step • If it is a leaf requirement, then a low-level use case can be defined using specification statements

  16. Elevator Requirements • Three high-level goals • The elevator shall minimize its cost of operation • The elevator shall minimize its movement • The elevator shall move passengers between floors

  17. Discussion • Analysts are quick to grasp the functional definitions • Analysts find it natural to generate goal hierarchies using How and Why questions • Analysts can quickly generate good use case from the goal hierarchy