Use Case Analysis – Part 4

1. Use Case Analysis – Part 4 Analysis Mechanisms

2. Use-Case Analysis Steps – Here’s where we are: • 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

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. Analysis Class Analysis 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. Analysis Class Analysis Mechanism(s) Student Persistency, Security Schedule Persistency, Security CourseOffering Persistency, Legacy Interface Course Persistency, Legacy Interface RegistrationController Distribution 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. 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. 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 • 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

8. <<boundary>> <<control>> <<entity>> <<entity>> 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. Design Model Supplementary Specification Glossary Use-Case Model Analysis Classes Evaluate Your Results

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. 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. 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? (continued)

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. 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 unambiguouslydistributed 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. 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. 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?