1. OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 1 Use Case Analysis – Part 4 Analysis Mechanisms

2. OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 2  Supplement the Use-Case Descriptions  For each use-case realization  Find Classes from Use-Case Behavior  Distribute Use-Case Behavior to Classes  For each resulting analysis class  Describe Responsibilities  Describe Attributes and Associations  Qualify Analysis Mechanisms – ahead… Now we have a pretty good understanding of the analysis classes, their responsibilities, and the collaborations required to support the functionality described in the Use Cases. Now, we look at the analysis classes and see how ‘analysis mechanisms’ are implemented. (ahead)  Unify Analysis Classes  Checkpoints Use-Case Analysis Steps – Here’s where we are:

3. OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 3 Analysis Mechanisms…  The purpose of “Qualify Analysis Mechanisms” is to:  Identify analysis mechanisms (if any) used by an analysis class  Sample analysis mechanisms are persistence, security, distribution, legacy interface, and others.  What we are saying is that some classes must provide additional information about how the class reconciles analysis mechanism (if it has any). During Analysis, this information is speculative and can be refined later. (Don’t want to miss these important points in design…)

4. OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 4 Analysis ClassAnalysis Mechanism(s) Format  The analysis mechanism characteristics should be documented with the class.  Analysis Mechanisms: persistence, security, distribution, legacy interface, etc. A mechanism has characteristics, and a client class uses a mechanism by ‘qualifying these characteristics;’ this is to discriminate across a range of potential designs. These characteristics are part functional, and part size, and performance. Not all classes will have mechanisms associated with them; Also not uncommon for a client class to require the services of several mechanisms.

5. OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 5 Analysis ClassAnalysis Mechanism(s) Student Schedule CourseOffering Course RegistrationController Persistency, Security Persistency, Legacy Interface Distribution Persistency, Security Example: Describing Analysis Mechanisms  Analysis class to analysis mechanism map As analysis classes are identified, it is important to identify the analysis mechanisms that apply to the identified classes. Classes that must be persistent are mapped to the Persistency Mechanism; Classes that are maintained with the Legacy Course Catalog system are mapped to the Legacy Interface mechanism; Classes for which access must be controlled (like who can read and modify instances of the class) are mapped to a Security mechanism., etc. Distributed classes mapped to a Distribution mechanism, etc.) (Often ‘control classes’ are distributed.)

6. OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 6 Example: Describing Analysis Mechanisms (cont.)  Analysis mechanism characteristics  Persistency for Schedule class:  Granularity: 1 to 10 Kbytes per product  Volume: up to 2,000 schedules  Access frequency Create: 500 per day Read: 2,000 access per hour Update: 1,000 per day Delete: 50 per day  Etc. The above is just an example of how the characteristics for an analysis mechanism would be documented for a class. (For scoping reasons, the analysis mechanisms and their characteristics are not provided for all of the analysis classes.)

7. OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 7  Supplement the Use-Case Descriptions  For each use-case realization  Find Classes from Use-Case Behavior  Distribute Use-Case Behavior to Classes  For each resulting analysis class  Describe Responsibilities  Describe Attributes and Associations  Qualify Analysis Mechanisms  Unify Analysis Classes  We have a pretty good understanding of the analysis classes, their responsibilities, the analysis mechanisms they need to implement (persistence, security, legacy, …) and the collaborations required to support the functionality described in the use cases.  Now lets review everything to ensure it is complete and consistent before moving on….  Checkpoints Use-Case Analysis Steps

8. OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 8 > Unify Analysis Classes The purpose of “Unify Analysis Classes” is to ensure that each analysis class represents a single well-defined concept, with non-overlapping responsibilities. Name of analysis class should capture role; Description of class should capture role played by class in the system. Merge classes that define similar behavior or represent the same thing. Merge entity classes that define the same attributes Aggregate behaviors of merged classes. If you do any of these things, make sure you update any supplemental use case descriptions where necessary.

9. OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 9 Supplementary Specification Glossary Use-Case Model Design Model Analysis Classes Evaluate Your Results

10. OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 10 Evaluating and Verifying  Now, verify analysis classes meet functional requirements of the system.  Verify the analysis classes and their relationships are consistent with collaborations that they may support.  Very important that you evaluate your results at the conclusion of Use Case Analysis.  The ‘number’ ‘formality’ and ‘when’ you do this verification is up to the project.

11. OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 11 Use-Case Analysis Steps  Supplement the Use-Case Descriptions  For each use-case realization  Find Classes from Use-Case Behavior  Distribute Use-Case Behavior to Classes  For each resulting analysis class  Describe Responsibilities  Describe Attributes and Associations  Qualify Analysis Mechanisms  Unify Analysis Classes  Checkpoints - Check the ‘quality’ of the model against criteria that the Designer looks for…

12. OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 12 (continued) Checkpoints: Analysis Classes  Are the classes reasonable?  Does the name of each class clearly reflect the role it plays?  Does the class represent a single well- defined abstraction?  Are all attributes and responsibilities functionally coupled?  Does the class offer the required behavior?  Are all specific requirements on the class addressed?

13. OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 13 Checkpoints: Analysis Classes  Note: All checkpoints should be evaluated with regards to the use cases being developed for the current iteration.  The class should represent a single well-defined abstraction. If not, consider splitting it.  The class should not define any attributes and responsibilities that are not functionally coupled to the other attributes or responsibilities defined by that class.  The classes should offer the behavior the use-case realizations and other classes require.  The class should address all specific requirements on the class from the requirement specification.  Remove any attributes and relationships if they are redundant or are not needed by the use-case realizations.

14. OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 14 Checkpoints: Use-Case Realizations  Have all the main and/or sub-flows been handled, including exceptional cases?  Have all the required objects been found?  Has all behavior been unambiguously distributed to the participating objects?  Has behavior been distributed to the right objects?  Where there are several interaction diagrams, are their relationships clear and consistent?

15. OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 15 Checkpoints: Use-Case Realizations  Note: All checkpoints should be evaluated with regards to the use cases being developed for the current iteration.  The objects participating in a use-case realization should be able to perform all of the behavior of the use case.  If there are several interaction diagrams for the use-case realization, it is important that it is easy to understand which interaction diagrams relates to which flow of events.  Make sure that it is clear from the Flow of Events description how the diagrams are related to each other.

16. OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 16 Review: Use-Case Analysis  What is the purpose of Use-Case Analysis?  What is an analysis class? Name and describe the three analysis stereotypes.  What is a use-case realization?  Describe some considerations when allocating responsibilities to analysis classes.  How many interaction diagrams should be produced during Use-Case Analysis?