1. Use Case Analysis – continued
Control Classes
Interaction Diagrams

2. Separate the Control Class treatment from the Interaction Diagrams… 4/17/04
Building Analysis Classes – next lecture – is mal-placed… See notes on first slide.

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

4. OOADv4.2 Instructor Notes
What is a Control Class?
Use-case behavior coordinator
One control class per use case
May be a number of methods for a 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

5. Control Classes – not always needed
Control classes provide coordinating behavior in the system.
The system can sometimes 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 use case.
 Examples of control classes include transaction managers, resource coordinators and error handlers.

6. Control Classes decouple other classes:
Control classes effectively decouple boundary and entity objects from one another, making the system more tolerant of changes in the system boundary. This is very important!
They also decouple the use-case specific behavior from the entity objects, making them more reusable across use cases and systems.
What does this sentence (above) mean to you?
Reverse engineer existing GUI components??

7. 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.
Control classes change little if the internal structure or behavior of the entity classes changes
Control classes use or set the contents of several entity classes, and therefore need to coordinate the behavior of these entity classes
Control classes are not performed in the same way every time they are activated (flow of events features several states)
One recommendation for the initial identification of control classes is one control class per use case.

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

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

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

11. 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…
We have called this an Analysis Diagram, and this terminology is also sometimes used. VOPC is also used to model classes used to ‘realize’ a Use Case.

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

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

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

15. Distributing Use Case behavior to Analysis Classes
Interactions BETWEEN actors should NOT be modeled. (Can show inheritance, 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:

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

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

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

19. Interaction Diagrams

20. The Anatomy of Sequence Diagrams
OOADv4.2 Instructor Notes
The Anatomy of Sequence Diagrams
A Sequence Diagram describes a pattern of interaction among objects, arranged in a
chronological order; it shows the objects participating in the interaction and the
messages they send.
A message from one object to another, indicates that the responsibility modeled by the message has been allocated to the receiving object’s class. A message can be unassigned, meaning that its name is a temporary string that describes the overall meaning of the message and is not the name of an operation of the receiving object. You can later assign the message by specifying the operation of the message's destination object. The specified operation will then replace the name of the message. Class operations are not formally defined until Class Design.
Note: To reduce information overload, we intentionally did not include all of the possible UML detail that can be use on sequence diagrams.
In Rose, focus of control and hierarchical messaging can be turned on and off. If you are EVER going to use these features, turn them on right away as Rose is not very forgiving if you turn them on later and need to adjust things. Also, a script can be attached to a particular message, so the script moves with the message.
Client Object
Supplier Object
Sample Script
:Client
:Supplier
An object is shown as a vertical dashed line called a lifeline.
Lifeline represents the existence of object at a particular time.
An object symbol is drawn at the head of the life line.
Name of object & its class are separated by a colon & underlined.
Object Lifeline
Reflexive Message
1: PerformResponsibility
1.1: PerformAnother Responsibility
Message
Hierarchical Message
Numbering
Focus of Control
Module 7 - Use-Case Analysis

21. The Anatomy of Sequence Diagrams – the Message
A message is a communication between objects that conveys information with the expectation that activity will ensue.
A message is shown as a horizontal solid arrow from the lifeline of one object to the lifeline of another object.
For a reflexive message, the arrow starts and finishes on the same lifeline.
The arrow is labeled with the name of the message, and its parameters.
The arrow may also be labeled with a sequence number.

22. Anatomy of Sequence Diagrams – Focus of Control
Focus of control represents the relative time that the flow of control is focused in an object, thereby representing the time an object is directing messages.
Focus of control is shown as narrow rectangles on object lifelines.
Hierarchical numbering bases all messages on a dependent message.
The dependent message is the message whose focus of control the other messages originate in.
For example, message 1.1 depends on message 1.
Scripts describe the flow of events textually.

23. Anatomy of Sequence Diagram – new one…
The next example shows the object interactions to support the Register for Courses use case, Create a Schedule subflow. Some responsibility allocation rationale is as follows:
The RegisterForCoursesForm knows what data it needs to display and how to display it. It does not know where to go to get it. That’s one of the RegistrationController’s responsibilities.
Only RegisterForCoursesForm interacts with Student actor.
The RegistrationController understands how Students and Schedules are related.
Only the CourseCatalogSystem class interacts with the external legacy Course Catalog System.
Note inclusion of the actors. This is important as it explicitly models what elements communicate with the “outside world”.

24. Example: Sequence Diagram – a “richer’ example…
OOADv4.2 Instructor Notes
Example: Sequence Diagram – a “richer’ example…
Sequence Diagram to Create a New Schedule…(from a Use Case)
: Student :
RegisterForCoursesForm
RegistrationController
: Schedule
: Course Catalog
CourseCatalogSystem
A list of the available
course offerings for this
semester are displayed
Student wishes to
create a new
schedule
1. // create schedule( )
1.2. // display course offerings( )
1.1. // get course offerings( )
// get course offerings(forSemester)
1.3. // display blank schedule( )
At this, point the Submit Schedule subflow is executed. Note requests for service from Actor!
2. // select four primary and two alternate offerings( )
2.1. // create schedule with offerings( )
// create with offerings( )
A blank schedule
is displayed for the
students to select
offerings
// add schedule(Schedule)
// get course offerings( )
Be sure to walk through this interaction diagram, emphasizing the responsibility allocation. Emphasize the application of the guidelines provided earlier.
Another option is to NOT show this slide immediately and to build the interaction diagram interactively with the students on the white board, demonstrating proper allocation of responsibility. When finished, you can compare the results with this slide.
Note: The use of “//” as the first two characters of the message name. This naming convention indicates that the operation is being used to describe the responsibilities of the analysis class and that these “analysis” operations WILL PROBABLY change/evolve in design).
What kinds of classes are these?????
Know this.
Module 7 - Use-Case Analysis

25. Continuing…(two slides forward…)
Next is the interaction diagram for the Submit Schedule subflow.
It describes what occurs when a Student requests that an entered schedule be actually submitted.
When a Schedule is submitted, an attempt is made to register the student for all selected primary courses one at a time, as you will see in the sequence diagram ahead...
Note the allocation of responsibility.
The Schedule has been given the responsibility for performing all of the processing associated with submitting a Schedule. (shown ahead in Sequence Diagram)
It orchestrates a series of checks (Student has pre-requisites, the course offering is still open, and the Student does not have any schedule conflicts), prior to enrolling the Student in the Course Offering.
. These methods (responsibilities) must be available in all Schedule object

26. Continuing – adding a new class…(next slide)
Note the addition of the new class, PrimaryScheduleOfferingInfo.
This class was needed to maintain the status of each particular Course Offering on a Schedule (as well as the associated grade – grade was added later).
This will be discussed in more detail later.

27. Example: Sequence Diagram (cont.)
OOADv4.2 Instructor Notes
Example: Sequence Diagram (cont.)
:CourseOffering
: Student
: RegisterForCoursesForm
: RegistrationController
: Schedule :
PrimaryScheduleOfferingInfo
Repeat for all primary
course offerings.
An attempt is made
to register the
student for all
selected course
Offerings one at a
time!!! (See loop)
1. // submit schedule( )
1.1. // submit schedule( )
// submit( )
// still open?( )
// add student(Schedule)
// has pre-requisites(CourseOffering)
// any conflicts?( )
// is selected?( )
// mark as enrolled in( )
// save( )
[ has pre-requisites, course offering open,
and no schedule conflicts ]
[ is selected ]
Be sure to walk through this interaction diagram, emphasizing the responsibility allocation. Emphasize the application of the guidelines provided earlier.
Now actor wishes to submit the schedule…
This sequence diagram is for Submit Schedule
Note the loop in the
Sequence Diagram…
Module 7 - Use-Case Analysis

28. The Anatomy of Collaboration Diagrams
OOADv4.2 Instructor Notes
The Anatomy of Collaboration Diagrams
Client Object
A collaboration diagram
describes a pattern of
interaction among objects.
It shows objects participating
in the interaction by their
links to each other and the
messages that they send to
each other.
An object is represented in three ways:
Objectname:Classname, Objectname,
and :Classname
A message from one object to another, indicates that the responsibility modeled by the message has been allocated to the receiving object’s class.
Note: Class operations are not formally defined until Class Design.
A comparison of Collaboration Diagrams and Sequence Diagrams is provided on a later slide.
In Rose, sequence diagrams can automatically be generated from collaboration diagrams and visa versa.
Link
Supplier Object
:Client
:Supplier
1: PerformResponsibility
Message
A link is a relationship among objects across which messages can be sent.
In a collaboration diagram, a link is shown as a solid line between two objects.
A link can be an instance of an association, or it can be anonymous – meaning that its
association is unspecified.
Module 7 - Use-Case Analysis

29. The Anatomy of Collaboration Diagrams - more
A message is a communication between objects that conveys information with the expectation that activity will ensue. (back one to slide)
In collaboration diagrams, a message is shown as a labeled arrow placed near a link.
This means that the link is used to transport, or otherwise implement the delivery of the message to the target object.
The arrow points along the link in the direction of the target object (the one that receives the message).
The arrow is labeled with the name of the message, and its parameters.

30. The Anatomy of Collaboration Diagrams - more
The arrow may also be labeled with a sequence number to show the sequence of the message in the overall interaction.
Sequence numbers are often used in collaboration diagrams, because they are the only way of describing the relative sequencing of messages.
(A message can be unassigned, meaning that its name is a temporary string that describes the overall meaning of the message. You can later assign the message by specifying the operation of the message's destination object.
The specified operation will then replace the name of the message. )

31. Example: Collaboration Diagram (one subflow…)
OOADv4.2 Instructor Notes
Example: Collaboration Diagram (one subflow…)
This example shows the collaboration of objects to support the Register for Courses
use case: Create a Schedule subflow. It is the “collaboration diagram equivalent”
of the sequence diagram shown earlier. (Refer to slide 23 for corresponding Sequence Diagram)
Point out how the collaboration diagram makes it easy to see the patterns of collaboration amongst participating objects. For example, boundary class instances are “on the edge”, control class instances are “in the middle”, and entity class instances are “towards the bottom”. This reflects the roles of these class instances, as described earlier.
: Student
: RegisterForCoursesForm
: RegistrationController :
Schedule
:Student
: CourseCatalogSystem
1.2. // display course offerings( )
1.3. // display blank schedule( )
: Course Catalog
1. // create schedule( )
2. // select 4 primary and 2 alternate offerings( )
1.1. // get course offerings( )
2.1. // create schedule with offerings( )
// create with offerings( )
// get course offerings(forSemester)
// add schedule(Schedule)
// get course offerings( )
Module 7 - Use-Case Analysis

32. Example: Collaboration Diagram (second subflow)
OOADv4.2 Instructor Notes
Example: Collaboration Diagram (second subflow)
The example below shows the collaboration of objects to support the
Register for Courses use case, Submit Schedule subflow.
It is the “collaboration diagram equivalent” of the sequence diagram shown earlier. :
CourseOffering
: Student
RegistrationController
Schedule
PrimaryScheduleOfferingInfo
// any conflicts?( )
: RegisterForCoursesForm
1. // submit schedule( )
1.1. // submit schedule( )
// submit( )
// save( )
// still open?( )
// add student(Schedule)
// is selected?( )
// mark as enrolled in( )
// has pre-requisites(CourseOffering)
Note all the responsibilities of Schedule objects…
Module 7 - Use-Case Analysis

33. One Interaction Diagram Not Good Enough
You should model most of the flows of events to make sure that all requirements on the operations of the participating classes are identified.
Start with describing the basic flow, which is the most common or most important flow of events.
Then describe variants such as exceptional flows.
You do not have to describe all the flows of events, as long as you employ and exemplify all operations of the participating objects.
Very trivial flows can be omitted, such as those that concern only one object.

34. Exception Flows Examples of exceptional flows include the following.
Error handling. What should the system do if an error is encountered?
Time-out handling. If the user does not reply within a certain period, the use case should take some special measures
Handling of erroneous input to the objects that participate in the use case (e.g., incorrect user input)
Examples of optional flows include the following:
The actor decides-from a number of options-what the system is to do next
The subsequent flow of events depends on the value of stored attributes or relationships
The subsequent flow of events depends on the type of data to be processed
Can use either collaboration and sequence diagrams.

35. One Interaction Diagram Not Good Enough
OOADv4.2 Instructor Notes
One Interaction Diagram Not Good Enough
Basic Flow
If you want an optional flow, or any flow that you consider important, to be especially noticeable, you can use a separate interaction diagram, but you should refer to this view in the sequence of the basic flow of events.
The diagramming of use-case flows of events vs. individual scenarios ensures better coverage of the requirements. If I have an interaction diagram per flow then there is a better chance that I have identified all classes participating in the use-case flow. Whereas, if I had diagrammed some subset of the scenarios (no one diagrams them all – like total path coverage in testing), I may be missing some (unless the rule is that I must cover all flows of a use case in my scenarios).
Such an approach means that your interaction diagrams may very well have conditional statements and looping.
Alternate Flow 1
Alternate Flow 2
Alternate Flow 3
AF3
AF1
AF2
Alternate Flow 4
Alternate Flow 5
Alternate Flow n
Can all be shown visually with an Activity Diagram for that Use Case
Module 7 - Use-Case Analysis

36. OOADv4.2 Instructor Notes
Collaboration Diagrams Vs Sequence Diagrams Same information expressed in different ways…
The choice of sequence or collaboration diagrams is a personal choice. This course does not recommend one over the other, but describes the advantages of each.
For brainstorming, some find the collaboration diagram easier – a closer visual representation of CRC cards.
The students should use whichever diagram they like best, however, you may want to recommend that they ultimately create the collaboration diagram in support of finding relationships between the associated classes. Rose’s automatic generation of one diagram from the other makes this easy, no matter what diagram you start with.
Note: RUP recommends that collaboration diagrams be used in analysis and that sequence diagrams be used in design. Collaboration diagrams get pretty unwieldy in design.
Collaboration Diagrams
Show relationships in addition to interactions
Better for visualizing patterns of collaboration
Better for visualizing all of the effects on a given object
Easier to use for brainstorming sessions
Sequence Diagrams
Show the explicit sequence of messages
Better for visualizing overall flow
Better for real-time specifications and for complex scenarios
Module 7 - Use-Case Analysis

37. More on Collaboration Diagrams
emphasize the structural collaboration of a society of objects and
provide a clearer picture of the patterns of relationships and control that exist amongst the objects participating in a use case.
Collaboration diagrams show more structural information (i.e., the relationships among objects).
better for understanding all the effects on a given object and for procedural design. (your logic is there!!)

38. More on Sequence Diagrams
show the explicit sequence of messages and
are better for real-time specifications and for complex scenarios.
A sequence diagram includes chronological sequences, but does not include object relationships.
Sequence numbers are often omitted in sequence diagrams, in which the physical location of the arrow shows the relative sequence.
On sequence diagrams, the time dimension is easier to read, the operations and parameters are easier to present, and the larger number of objects are easier to manage than in collaboration diagrams.