Use Case Analysis – continued
Control Classes
Building Analysis Classes
(Modified considerably by your Instructor)
OOAD Using the UML - Use-Case Analysis, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
1
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.
 Similarly, some use cases may require more than one
control class; but in general, there is a one-to-one
correspondence – as a heuristic.
OOAD Using the UML - Use-Case Analysis, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
2
What is a Control Class?
 Use-case behavior coordinator
 One control class per use case
<<control>>
Use Case
Analysis class
stereotype
Use-case dependent, Environment independent
OOAD Using the UML - Use-Case Analysis, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
3
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 case only involves 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.
OOAD Using the UML - Use-Case Analysis, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
4
Control Classes decouple:
 Control classes effectively decouple boundary
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 (the entity
objects) more reusable across use cases and
systems.
 Note: we are in the initial stages of ‘design’
 Decoupling may positively affect some of the nonfunctional requirements (that are addressed in design in
considerable detail), such as maintainability,
performance, reusability.
 Discuss: (A number of non-functional requirements are
quite contradictory in places…)
OOAD Using the UML - Use-Case Analysis, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
5
Control Class provided behavior:
 Is surroundings-independent (does not change
when the surroundings / environment change)
 Defines control logic
 Order the sequence of activities to realize the use-case.
(Consider registering for courses….
 Changes little if the internal structure or behavior of the
entity classes changes
 Use or set the contents of several entity classes,
and therefore needs to coordinate the behavior of
these entity classes (gets and sets and
sequencing…)
 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.
OOAD Using the UML - Use-Case Analysis, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
6
The Role of a Control Class
<<boundary>>
<<control>>
<<boundary>>
Customer
Database
<<boundary>>
<<entity>>
<<entity>>
Coordinate the use-case behavior
• 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.
OOAD Using the UML - Use-Case Analysis, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
7
Role of Control Class
 Control classes contribute to understanding
the system.
 Represent the dynamics of the system,
 Hande 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)
OOAD Using the UML - Use-Case Analysis, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
8
Example: Finding Control Classes
 Recommend: Identify one control class per
use case (again)
Student
Register for Courses Course Catalog System
<<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 (sequencing of activities) within the system.
 (Controller accepts inputs, ‘knows’ where required data and functionality reside,
sends key messages to entities, sequences all actions to satisfy use case, sends
data
back
input
actor,
etc….)
OOAD
Using
the UML - to
Use-Case
Analysis,
v 4.2
9
Copyright  1998-1999 Rational Software, all rights reserved
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.
 Such class diagrams have been called “View of
Participating Classes” diagrams (VOPC, for short)
– next overhead…
OOAD Using the UML - Use-Case Analysis, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
10
Example: Summary: Analysis Classes - VOPC
• 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.
Student
Register for Courses
Course Catalog System
Use-Case Model
Design Model (classes only listed – no relationships shown here…)
<<boundary>>
RegisterForCoursesForm
<<entity>>
Student
OOAD Using the UML - Use-Case Analysis, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
<<control>>
RegistrationController
<<entity>>
Schedule
11
<<boundary>>
CourseCatalogSystem
<<entity>>
CourseOffering
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 Behaviors to these 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 Distributing Use Case Behavior to Classes is to:
 Express the use-case behavior in terms of collaborating
objects, and thus
 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 (more coming on this last item)
OOAD Using the UML - Use-Case Analysis, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
12
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.
 Static: Allocate use-case responsibilities to analysis
classes (look for the verbs and actions in use case flow…)
 Dynamic: Model analysis class interactions in
interaction diagrams  we need to show interactions of
system with its actors.
  Interactions all begin with an actor, who invokes the use
case (Use cases don’t start themselves!)
Use Case
OOAD Using the UML - Use-Case Analysis, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
Sequence Diagrams
Collaboration Diagrams
13
Use-Case Realization
Interactions among Actors? No.
 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:
OOAD Using the UML - Use-Case Analysis, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
14
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)
• Behaviors that involves communication with an actor
 Entity Classes (Persistent Data)
• Behaviors that involves the data encapsulated within
the abstractions. (All data manipulation, retrieval…)
 Control Classes (the Use Case flow of events)
• Behaviors specific to a use case or part of a very
important flow of events
(continued)
OOAD Using the UML - Use-Case Analysis, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
15
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?
 Example: “System displays Patient data on monitor.”
 OK. Where is the patient data? – patient object.
 Who can ‘get’ the data? Patient object! (may imply a
retrieval from a database, but ultimately the patient
object has the data and the responsibility to get it.)
OOAD Using the UML - Use-Case Analysis, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
16
Guidelines: Allocating Responsibilities to Classes (cont.)
 Design options:
 For a class that has the data, put the
responsibility for access, for manipulation, for
modification, etc. with the data – best case!!!
 If 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
OOAD Using the UML - Use-Case Analysis, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
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.
OOAD Using the UML - Use-Case Analysis, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
18