Use Case Analysis - Continued: Control Classes Building Analysis Classes

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/18
Control Classes
 A class used to model control behavior specific to one
or more use cases.
 Encapsulate use-case-specific behavior.
 Behavior of a control object is closely related to the
realization of a specific use case.
 Might ‘say’ 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.

What is a Control Class?
 Is a Use-case behavior coordinator;
 sequences; controls; orchestrates use-case.
 One control class per use case (generally)
<<control>>
Analysis class
stereotype
Use Case
Use-case dependent, Environment independent

Control Classes – not always needed
 Provides 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. Think about these activities!!
Control Classes decouple:
  Decouple boundary objects from one another,
making the system more tolerant of changes in the system
boundary.
 Boundary objects may be several; can make cohesive, separate,
easy to change / modify…
  Also decouple from control classes use-case behaviors

to 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 non-functional

requirements (that are addressed in design in considerable
detail), such as maintainability, performance, reusability.
Control Class provided behavior:
 Surroundings-independent (does not change when the
surroundings / environment change)
 Define control logic
 Order/Direct sequence of activities to realize the use-case.
(Consider Registering for Courses use case….
 Changes little if the internal structure or behavior of the entity
classes changes
 Control Classes use or set the contents of entity classes,

and thus need to coordinate behaviors of 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
<<boundary>>
<<control>>
<<boundary>>
Customer
<<boundary>> Database
<<entity>> <<entity>>
Coordinate the use-case behavior

• Several control objects of different control classes can participate in one use case.
This is particularly true if the use case is rather complex and requires much
coordination of access of entity objects, etc.
• As stated, not all use cases require a control object but most do – at least one.
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
1998-1999 this
Rational as more
Copyright  Software, use-case
all rights reserved realizations are
7/18identified and commonality is discovered.
Role of Control Class and Control Objects
 Control classes contribute to understanding the
system.
 Represents the dynamics of the system,
 Handles the main tasks and control flows.
 When the system performs the use case, a control

object is created.
 Control Objects usually die once their corresponding

use case or scenario (story) has been performed.
 (Normally NOT persistent)
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 to
input actor via boundary objects, etc….)
Now, Summarizing Analysis Classes in general:
 Summary of Analysis Classes: View of Participating

Classes (VOPC)
 For each use-case realization (loop) 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…

Example: Summary: Analysis Classes - VOPC
• The diagram 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 Diagram
Analysis Model (classes only listed – no relationships shown here…)

<<boundary>> <<control>> <<boundary>>
RegisterForCoursesForm RegistrationController CourseCatalogSystem
<<entity>> <<entity>> <<entity>>

Student Schedule 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
 Equivalently: Determine the responsibilities of analysis classes.
  For each resulting analysis class, do:

 Describe Responsibilities (behaviors)
 Describe Attributes and Associations (lectures ahead and following…)
 Qualify Analysis Mechanisms (more coming on this last item; quality
metrics; non-functional requirements, such as persistence…)
Distribute Use-Case Behaviors to Classes
 For each use-case flow of events:
 Identify analysis classes (Step thru flow of events)
 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  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 Sequence Diagrams Communications Diagrams

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.
 How to distribute behavior to classes:

Guidelines: Allocating Responsibilities to Classes
 This allocation of responsibilities is crucial!
 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
 Notice, all these allocations are of behaviors.
(continued)
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.”
• Where is the patient data? Patient object. (entity 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.)
 Who coordinates (issues message to patient object) to get this

data? Control class.
 Once the data is ‘obtained,’ who will “display” the data to the
actor? Boundary class. Look 16/18

for data and verbs and nouns!
Copyright  1998-1999 Rational Software, all rights reserved
 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:
• 1. Put the responsibility with one class and add a
relationship to the other (a dependency relationship)
• 2. Create a new class, put the responsibility in the new
class, and add relationships to classes needed to
perform the responsibility
• 3. Put the responsibility in the control class, and add
relationships to classes needed to perform the
responsibility
 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.


Use Case Analysis - Continued: Control Classes Building Analysis Classes

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Use Case Analysis - Continued: Control Classes Building Analysis Classes

Uploaded by

Copyright:

Available Formats

Use Case Analysis – continued

OOAD Using the UML - Use-Case Analysis, v 4.2

OOAD Using the UML - Use-Case Analysis, v 4.2

Use-case dependent, Environment independent

OOAD Using the UML - Use-Case Analysis, v 4.2

 Complex use cases generally require one or more

  Also decouple from control classes use-case behaviors

 Note: we are in the initial stages of ‘design’

 Decoupling may positively affect some of the non-functional

 Control Classes use or set the contents of entity classes,

OOAD Using the UML - Use-Case Analysis, v 4.2

Coordinate the use-case behavior

 When the system performs the use case, a control

 Control Objects usually die once their corresponding

Student Register for Courses Course Catalog System

 Each control class is responsible for orchestrating/controlling the processing that

Here, the RegistrationController <<control>> class has been defined to orchestrate

 Summary of Analysis Classes: View of Participating

 For each use-case realization (loop) there is one or

 Such class diagrams have been called “View of

OOAD Using the UML - Use-Case Analysis, v 4.2

Student Register for Courses Course Catalog System

Analysis Model (classes only listed – no relationships shown here…)

<<entity>> <<entity>> <<entity>>

OOAD Using the UML - Use-Case Analysis, v 4.2

Purpose of Distributing Use Case Behavior to Classes is to:

  For each resulting analysis class, do:

Use Case Sequence Diagrams Communications Diagrams

 How to distribute behavior to classes:

OOAD Using the UML - Use-Case Analysis, v 4.2

 Who has the data needed to perform the responsibility?

 Example: “System displays Patient data on monitor.”

• Where is the patient data? Patient object. (entity object)

• Who can ‘get’ the data? Patient object! (may imply a

 Who coordinates (issues message to patient object) to get this

actor? Boundary class. Look 16/18

  Only when sure that there is not an existing object

OOAD Using the UML - Use-Case Analysis, v 4.2

You might also like