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

2. 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.

3. 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

4. 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.

5. 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…)

6. 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.

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

8. 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)

9. 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

10. 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…

11. 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

12. 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

13. 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

14. 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:

15. 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

16. 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

17. 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.