Use Case Analysis – continued Control Classes Building Analysis Classes Modified considerably by your Instructor

Control Classes A Control Class is a class used to model control behavior specific to one or more use cases. Control classes encapsulate use-case-specific behavior. The behavior of a control object is closely related to the realization of a specific use case. In many scenarios, you might even say that the control objects "run" the use-case realizations. Some control objects can participate in more than one use-case realization if the use-case tasks are strongly related.

OOADv4.2 Instructor Notes What is a Control Class? Use-case behavior coordinator One control class per use case One recommendation for the initial identification of control classes is one control class per use-case. This may be refined as a more detailed analysis is performed. Control classes are to be used to isolate use-case-specific responsibilities/behavior, not to be “do-all, be-all” classes. Control classes contain behavior that doesn’t belong in entity and boundary classes. Stress that the control classes know how to “orchestrate and delegate”. They don’t do everything, but they know the order in which things should be done. In many cases, these control classes are “designed away” in Class Design (e.g., may become methods in UI classes). In analysis, however, they allow the analyst to allocate that use-case-specific behavior and move on. <<control>> Analysis class stereotype Use Case Use-case dependent, Environment independent Module 7 - Use-Case Analysis

Control Classes – not always needed Control classes provide coordinating behavior in the system. The system sometimes can perform some use cases without control classes (just using entity and boundary classes) – particularly use cases that involve only the simple manipulation of stored information. Complex use cases generally require one or more control classes to coordinate the behavior of other objects in the system. Examples of control classes include transaction managers, resource coordinators and error handlers.

Control Classes decouple: Control classes effectively decouple boundary and entity objects from one another, making the system more tolerant of changes in the system boundary. They also decouple the use-case specific behavior from the entity objects, making them more reusable across use cases and systems. Reverse engineer existing GUI components?? Note: we are in the initial stages of ‘design’ Decoupling affects some of the non-functional requirements (that are addressed in design in considerable detail), such as maintainability, performance, reusability. Discuss: (contradictory in places…)

Control Class provided behavior: Is surroundings-independent (does not change when the surroundings change) Defines control logic (order between events) and transactions within a use case. Changes little if the internal structure or behavior of the entity classes changes Uses or sets the contents of several entity classes, and therefore needs to coordinate the behavior of these entity classes Is not performed in the same way every time it is activated (flow of events features several states) One recommendation for the initial identification of control classes is one control class per use case.

The Role of a Control Class OOADv4.2 Instructor Notes The Role of a Control Class Coordinate the use-case behavior Customer <<boundary>> <<control>> <<entity>> Several control objects of different control classes can participate in one use case. As stated, not all use cases require a control object. Example: if the flow of events in a use case is related to one entity object, a boundary object may realize the use case in cooperation with the entity object. You can start by identifying one control class per use case realization, and then refine this as more use-case realizations are identified and commonality is discovered. Module 7 - Use-Case Analysis

Role of Control Class Control classes can contribute to understanding the system because they represent the dynamics of the system, handling the main tasks and control flows. When the system performs the use case, a control object is created. Control objects usually die when their corresponding use case has been performed. (Normally NOT persistent)

Example: Finding Control Classes OOADv4.2 Instructor Notes Example: Finding Control Classes Recommend: Identify one control class per use case Course Catalog System Register for Courses Student <<control>> RegistrationController Each control class is responsible for orchestrating/controlling the processing that implements the functionality described in the associated use case. Here, the RegistrationController <<control>> class has been defined to orchestrate the Register for Courses processing within the system. Module 7 - Use-Case Analysis

Summary of Analysis Classes: View of Participating Classes (VOPC) For each use-case realization there is one or more class diagrams depicting its participating classes, along with their relationships. These diagrams show consistency in the use-case implementation across subsystem boundaries. Such class diagrams have been called “View of Participating Classes” diagrams (VOPC, for short) – next overhead…

Example: Summary: Analysis Classes OOADv4.2 Instructor Notes Example: Summary: Analysis Classes The diagram here shows the classes participating in the Register for Courses use case The part-time student and full-time student classes have been omitted for brevity (they both inherit from Student. Class relationships will be discussed later. Note: This slide is a summary of all of the other example slides for this step. The Part-Time Student and Full-Time Student classes have been omitted from the diagram for clarity. Student Register for Courses Course Catalog System Use-Case Model Design Model (classes only listed – no relationships shown here…) <<boundary>> RegisterForCoursesForm <<control>> RegistrationController <<boundary>> CourseCatalogSystem <<entity>> Student <<entity>> Schedule <<entity>> CourseOffering Module 7 - Use-Case Analysis

Use-Case Analysis Steps – Next Major Step… OOADv4.2 Instructor Notes Use-Case Analysis Steps – Next Major Step… Supplement the Use-Case Descriptions For each use-case realization Find Classes from Use-Case Behavior - DONE! But nothing in them! Distribute Use-Case Behavior to Classes Now we need to allocate responsibilities of the use cases to the analysis classes and model this allocation by describing the way the class instances collaborate to perform the use case in use-case realizations. Purpose of this task (Distributing Use Case Behavior to Classes) is to: Express the use-case behavior in terms of collaborating classes, and Determine the responsibilities of analysis classes. For each resulting analysis class, do: Describe Responsibilities Describe Attributes and Associations (lectures ahead and following…) Qualify Analysis Mechanisms Module 7 - Use-Case Analysis

Distribute Use-Case Behavior to Classes OOADv4.2 Instructor Notes Distribute Use-Case Behavior to Classes For each use-case flow of events: Identify analysis classes (Step thru flow of events) We have identified classes. Now, see where they are applied in the use case flow of events. Allocate use-case responsibilities to analysis classes Model analysis class interactions in interaction diagrams = we need to show interactions of the system with its actors. Interactions all begin with an actor, who invokes the use case This is where the initial use-case realizations are developed. When identifying analysis classes and allocating use-case responsibilities, keep in mind the recommendations: One control class per use case, one boundary class per actor/use-case pair. You can create an interaction diagram for each variant of a use case's flow of events. The Rational Unified Process recommends the use of Collaboration Diagrams in Analysis. This is discussed in more detail on a later slide. Business Modeling is addressed in the Rational Unified Process in the “Business Modeling” workflow. You are done with Use-Case Analysis when you have allocated all the use-case responsibilities to something (e.g., analysis classes). Sequence Diagrams Collaboration Diagrams Use Case Use-Case Realization Module 7 - Use-Case Analysis

Distributing Use Case behavior to Analysis Classes Interactions BETWEEN actors should NOT be modeled. (Can show inheritance, surrogates, etc. but no ‘interactions.’) By definition, actors are external, and are out of scope of the system being developed. Thus, you do not include interactions between actors in your system model. Let’s look at how to distribute behavior to classes:

Guidelines: Allocating Responsibilities to Classes OOADv4.2 Instructor Notes Guidelines: Allocating Responsibilities to Classes This allocation of responsibilities is crucial! Stereotypes assist in that they provide a set of canned responsibilities that we can use. Use analysis class stereotypes as a guide Boundary Classes (the Interface) Behavior that involves communication with an actor Entity Classes (Persistent Data) Behavior that involves the data encapsulated within the abstraction Control Classes (the Use Case flow of events) Behavior specific to a use case or part of a very important flow of events (continued) Module 7 - Use-Case Analysis

Guidelines: Allocating Responsibilities to Classes (cont.) OOADv4.2 Instructor Notes Guidelines: Allocating Responsibilities to Classes (cont.) A driving influence on where a responsibility should go is the location of the data needed to perform the operation. Who has the data needed to perform the responsibility? Design options: One class has the data, put the responsibility with the data – best case!!! Multiple classes have the data: Put the responsibility with one class and add a relationship to the other (a dependency relationship) Create a new class, put the responsibility in the new class, and add relationships to classes needed to perform the responsibility Put the responsibility in the control class, and add relationships to classes needed to perform the responsibility Module 7 - Use-Case Analysis

Guidelines: Allocating Responsibilities to Classes (cont.) Be careful when adding relationships -- all relationships should be consistent with the abstractions they connect. Don’t just add relationships to support the implementation without considering the overall affect on the model. When a new behavior is identified, check to see if there is an existing class that has similar responsibilities, reusing classes where possible. Only when sure that there is not an existing object that can perform the behavior should you create new classes.