1. Object Oriented Analysis and Design Using the UML
OOADv4.2 Instructor Notes
Object Oriented Analysis and Design Using the UML
Module 7 - Use-Case Analysis

2. Objectives: Use-Case Analysis
OOADv4.2 Instructor Notes
Objectives: Use-Case Analysis
Understand the purpose of Use-Case Analysis and where in the lifecycle it is performed
Identify the classes which perform a use- case flow of events (Analysis Classes)
Distribute the use-case behavior to those classes, identifying responsibilities of the classes
The analysis classes and the initial use-case realizations are the key model elements that we develop in this activity.
Use-Case Analysis is where the “requirements meet OO”.
Module 7 - Use-Case Analysis

3. Use Case Analysis
An instance of Use-Case Analysis is performed for each use case to be developed during an iteration.
The focus during Use-Case Analysis is on a particular use case.
In Use-Case Analysis, we identify the analysis classes and define their responsibilities.
The allocation of responsibility is modeled in use-case realizations that describe how analysis classes collaborate to perform use cases.
(The use-case realizations will be refined in Use-Case Design.)

4. Use-Case Analysis Overview
OOADv4.2 Instructor Notes
Use-Case Analysis Overview
Use Case Analysis is performed
By the Designer – once per
Iteration per use case realization
Software Architecture
Document
Glossary
The Use-Case Model Supplementary Specification, Glossary are described in detail in the Requirements Overview module. The Use-Case Modeling Guidelines define the modeling conventions used in the use-case model. Designers need this information to correctly read and interpret the use-case model.
The Analysis classes represent an early conceptual model for ‘things in the system which have responsibilities and behavior’. Analysis classes are used to capture a ‘first-draft’, rough-cut of the object model of the system.
The Analysis Model describes the realization of use cases, and serves as an abstraction of the Design Model. It contains the analysis classes and their relationships. If your project is maintaining separate analysis and design models, then an Analysis Model is a formal artifact from Use-Case Analysis. Otherwise, the identified analysis classes and their relationships are just placed in the Design Model. These classes will be refined into design elements (e.g., classes, packages and subsystems) during the design activities.
In many cases, the Analysis Model only exists for the brief duration of Use-Case Analysis. Once the analysis classes are transformed into design classes/subsystems, the model generally vanishes.
Use-Case
Modeling Guidelines
Supplementary
Specifications
Analysis Classes
Use-Case Realization
(developed)
Use-Case Realization
(identified)
Use-Case
Analysis
Design Model
Use-Case Model
Analysis Model (optional)
Module 7 - Use-Case Analysis

5. Use Case Analysis - Purpose
To identify the classes which perform a use case’s flow of events
To distribute the use case behavior to those classes
To identify the responsibilities, attributes and associations of the classes
Input Artifacts
Glossary Supplementary Specifications
Use-Case Model Use-Case Flow of Events
Software Architecture Document
Resulting Artifacts
Analysis Classes Analysis Model and/or Design Model
Partially Developed Use-Case Realizations

6. Use-Case Analysis Steps – Major ones
OOADv4.2 Instructor Notes
Use-Case Analysis Steps – Major ones
Supplement the Use-Case Description
Will probably need some enhancements as we pair down our Use Cases and add alternatives and exceptions.
For each use-case realization, do:
Find classes from Use Case behavior - Study each Use Case flow of events to identify analysis classes.
Allocate behaviors (responsibilities) to these classes.
These are the little things the class must do….in some cases, these are merely options afforded to the user like add new customer() or delete customer ()….
Distribute Use-Case Behavior to Classes that you identify
Describe Attributes of each analysis class.
Show associations between the collaborating classes.
Let’s look at each of these in particular….
This is where we preview what we will be doing in Use-Case Analysis
Module 7 - Use-Case Analysis

7. Use-Case Analysis Steps
OOADv4.2 Instructor Notes
Use-Case Analysis Steps
Supplement the Use-Case Description
Capture additional information in order to understand the required internal behaviors.
It is quite customary to make changes (or should be….)
This is why we spend so much time on getting those use cases right – recall, Use Cases drive the whole shooting match!
Update flows of events as needed…..
Module 7 - Use-Case Analysis

8. Supplement the Use-Case Description
OOADv4.2 Instructor Notes
Supplement the Use-Case Description
Sometimes the description of
the use case is not sufficient
for identifying analysis classes and
their objects.
Remember, customer doesn’t
care about the inside of the
system, so many details may
have been left out – leaving the
use case description like a black
box.
To find objects that perform the
use cases, we may need ‘white
box’ descriptions – that is, what does
the system do from an internal
perspective.
One technique for capturing this additional detail if Word is used to document the use cases is to add the detail in the form of comments in the Word document. That way the detail can be “turned on or off”, depending on the audience.
The system retrieves and displays a list of current course offerings from the course catalog legacy database.
The system displays a list of course offerings.
Module 7 - Use-Case Analysis

9. Use-Case Analysis Steps
OOADv4.2 Instructor Notes
Use-Case Analysis Steps
Supplement the Use-Case Description
For each use-case realization
Find Classes from Use-Case Behavior
May be easier now to identify our candidate analysis classes for the system
(candidate means first cut; possible classes)
At this juncture we should have identified a set of candidate analysis classes which will be capable of performing the behaviors described in the use case.
These are now the ‘responsibilities’ of these classes.
Module 7 - Use-Case Analysis

10. OOADv4.2 Instructor Notes
Review: Class
Recall, a class is an abstraction
Describes a group of objects with common:
Properties (attributes)
Behavior (operations)
Relationships
Semantics
A class is an abstraction in that it
Emphasizes relevant characteristics; suppresses others
Consists of the three sections indicated
First section: Class name
Second section: structure (attributes)
Third section: behavior (operations)
For analysis classes, these entries are sufficient!
Professor
name
empID
create( )
save( )
delete( )
change( )
Class Name
Attributes
Operations
Module 7 - Use-Case Analysis

11. Review: Use-Case Realization
OOADv4.2 Instructor Notes
Review: Use-Case Realization
Use-Case Model
Design Model
Use Case
Use-Case Realization
To document use-case realizations in Rose:
Create a separate “Use-Case Realizations” package in the Logical View package.
In the new “Use-Case Realization” package, create a separate package for each use-case realization.
In each use-case realization package, create another use case with exactly the same name to act as the placeholder for the original use case with a stereotype of <<use-case realization>>. Note: A stereotyped collaboration is the correct way to model a use-case realization, but Rose does not yet support stereotyped collaborations.
“Attach” all interaction and class diagrams to the use-case realization. It is recommended that you name the interaction diagrams "<use-case name> - <flow type>". This naming convention simplifies future tracing of objects to the use-case realization that they participate in.
The traceability between use-case realizations and the corresponding use case is done by dragging and dropping the use case and the realization into a class diagram called “Traceabilities”, owned by the “Use-Case Realization” package. Draw a unidirectional association from the realization to the use case and set its stereotype to <<realizes>>. Note: a realization relationship is the correct way to model this, but Rose can’t draw a realization between two use cases.
Sequence Diagrams
Collaboration Diagrams
Class Diagrams
Use Case
Not what we have so far.
These are Design Classes. More later
Module 7 - Use-Case Analysis

12. Comments on previous slide
Remember: a use-case realization describes how a particular use case is realized within the Design Model, in terms of collaborating objects.
A use-case realization is one possible realization of a use case.
A use-case realization in the Design Model can be traced to a use case in the Use-Case Model.
A realization relationship is drawn from the use-case realization to the use case it realizes.
A use-case realization can be represented using a set of diagrams (the number and type may vary)
Different organizations may have their own way of doing these things…(and naming them…)

13. Continuing Comments…
The diagrams that may be used to realize a use case realization may include:
Interaction Diagrams (sequence and/or collaboration diagrams) can be used to describe how the use case is realized in terms of collaborating objects.
These diagrams model the detailed collaborations of the use-case realization.
Class Diagrams can be used to describe the classes that participate in the realization of the use case, as well as their supporting relationships.
These diagrams model the context of the use-case realization.

14. Still more Comments…
In our Use Case Analysis step, the use-case realizations' diagrams are outlined.
Exactly what this entails will be discussed ahead and form part of the fourth deliverable.
In subsequent design activities (Use-Case Design) these class diagrams will be considerably refined and updated according to more formal class interface definitions.

15. A designer: responsible for the integrity of the use-case realization.
Must coordinate with the designers responsible for the classes and relationships employed in the use-case realization.
The use-case realization can be used by class designers to understand the class’s role in the use case and how the class interacts with other classes.
This implies that a team will/may distribute responsibilities for each class to developers.
This information can be used to determine/refine the class responsibilities and interfaces.
Let’s find the classes from different behaviors the classes must provide…

16. Identifying Candidate Classes from Behavior
Will use three perspectives of the system to identify these classes.
The ‘boundary’ between the system and its actors
The information’ the system uses
The ‘control logic’ of the system
Will use stereotypes to represent these perspectives (boundary, control, entity)
These are conveniences used during analysis that will disappear or be transitioned into different design elements during the design process.
Will result in a more robust model because these are the three things that are most likely to change in system and so we isolate them so that we can treat them separately.
That is, the interface/boundary, the control, and the key system entities.….

17. Find Classes From Use-Case Behavior
OOADv4.2 Instructor Notes
Find Classes From Use-Case Behavior
The complete behavior of a use case has to be distributed to analysis classes
We must ‘identify’ these classes – identify, name, and briefly describe in a few sentences.
Do you find classes or objects first? Some people naturally think in abstractions. They find classes first. Others think concretely. They find objects first and then abstract these objects into classes.
Note: RUP ships with a set of special icons to visually represent these different types of classes. We have chosen not to use the RUP stereotypes in this course (they served to be too much of a distraction to the students).
<<boundary>>
<<control>>
<<boundary>>
<<entity>>
<<entity>>
Module 7 - Use-Case Analysis

18. Discovering Classes
Analysis classes represent an early conceptual model for ‘things in the system which have responsibilities and behaviors’.
Analysis classes are used to capture a ‘first-draft’, rough-cut of the object model of the system.
Analysis classes handle primary functional requirements, interface requirements, and some control - and model these objects from the problem domain perspective.

19. Kinds of Analysis Classes
Three things likely to change in a system:
The boundary between the system and its actors (interfaces…)
The information a system uses (data), and
The control logic of the system (who does what)
So, we isolate the different kinds of analysis classes
Each of these has a set of canned duties & responsibilities
Again, the distinction between these classes is used in analysis but goes away in design or becomes less of an issue, as we transition these analysis classes into design artifacts / design entities to accommodate the problem domain representations in a solutions space.

20. What is an Analysis Class?
OOADv4.2 Instructor Notes
What is an Analysis Class?
Can use with the name of the stereotype
In guillemets or as symbols with unique icons.
Finding a candidate set of classes is the first
part of transforming a mere statement of
required behavior to a description of how the
System will work.
Entity classes are derived from the domain of the system. Boundary and control classes are ideal classes that are needed to describe the use cases inside the system.
Introducing the concepts of boundary and control classes in analysis and utilizing their canned responsibilities has provided a little of a “cook book” approach that some designers have been asking for. However, these class stereotypes can be misused. Proper usage of these concepts will be discussed on later slides.
The purpose of the distinction between the different types of analysis classes was to think about the roles objects play, and making sure the behavior is allocated according to the forces which cause objects to change. Once these forces have been considered and there is a good class decomposition, the distinction is no longer really useful.
All analysis classes do not have to have a stereotype. Just use the analysis class stereotypes when they help you. Don't feel that every analysis class you identify must have a stereotype (but make sure you qualify its existence).
<<boundary>>
<<control>>
Use-case behavior coordination
System boundary
System information
<<entity>>
Module 7 - Use-Case Analysis

21. Analysis Classes – an Early Conceptual Model
The analysis classes, taken together, represent an early conceptual model of the system.
This conceptual model evolves quickly and remains fluid for some time as different representations and their implications are explored.
Don’t spend a lot of time maintaining this model, as this ‘model’ is largely expendable.
Analysis classes rarely survive into the design unchanged.
Many of them represent whole collaborations of objects, often encapsulated by a single subsystems or a reverse engineered component.

22. Analysis Classes – Early Conceptual Model
Analysis classes are 'proto-classes', which are essentially "clumps of behavior".
Analysis classes are early conjectures of the composition of the system; they rarely survive intact into implementation.
Many of the analysis classes morph into something else later on (subsystems, components, split classes, combined classes).
They provide us with a way of capturing the required behaviors in a form that we can use to explore the behavior and composition of the system.
Analysis classes allow us to "play" with the distribution of responsibilities, re-allocating, as necessary.

23. Analysis Classes: A First Step Towards Executables
OOADv4.2 Instructor Notes
Analysis Classes: A First Step Towards Executables
Some of the work done in analysis is thrown away. This is not bad, since you need to play with the ideas to see what works and what doesn’t, but you should expect that much of the work done during analysis is a kind of ‘structured doodling’. The biggest mistakes happened when people assign too much value to the early results of analysis.
The need to define analysis classes in UML terms creates a sense that they are more formal than they are. An instructor once referred to analysis classes as “CRC-like
cards, on which you can scribble anything you want in the margins”.
This course concentrates on the development of a Design Model. Maintaining a separate Analysis Model would require some modifications to the presented activities, the discussion of which is out of the scope of this course.
Use Cases
Analysis Classes
Design Elements
Source
Code
Exec
Use-Case Analysis
(…from a structural perspective; static)
Module 7 - Use-Case Analysis

24. What is a Boundary Class?
OOADv4.2 Instructor Notes
What is a Boundary Class?
Insulates the system from changes in the outside
Several Types of Boundary Classes
User interface classes – classes that facilitate communication with human users of the system
Menus, forms, etc. User interface classes….
System interface classes – classes which facilitate communications with other systems.
These boundary classes are responsible for managing the dialogue with the external system, like getting data from an existing database system or flat file…
Provides an interface to that system for this system
Device Interface Classes – provide an interface to devices which detect external events – like a sensor or …
One boundary class per use case/actor pair
<<boundary>>
Analysis class stereotype
Module 7 - Use-Case Analysis

25. The Role of a Boundary Class
OOADv4.2 Instructor Notes
The Role of a Boundary Class
Customer
<<boundary>>
<<control>>
<<entity>>
Actors can only communicate with boundary classes.
Boundary classes identify the system’s boundaries.
External
Database??
. A boundary class is a class used to model interaction between the system’s surroundings
and its inner workings; Involves transforming and translating events and noting changes
in the system presentation (such as the interface).
. Boundary Classes model parts of the system that depend on its surroundings. Entity
and control classes model parts that are independent of the system’s surroundings.
. Examples of boundary classes: Classes that handle GUI or communications protocols.
Module 7 - Use-Case Analysis

26. Boundary Classes - more
Identify boundary classes for things mentioned in the flow of events of the use-case realization.
Consider the source for all external events and make sure there is a way for the system to detect these
events. (user inputs/responses? Connection to existing external data…)
One recommendation: for the initial identification of boundary classes is one boundary class per actor/use-case pair.
This class can be viewed as having responsibility for coordinating the interaction with the actor.
This may be refined as a more detailed analysis is performed.
This is particularly true for window-based GUI applications, where there is typically one boundary class for each window, or one for each dialog.

27. Example: Finding Boundary Classes
OOADv4.2 Instructor Notes
Example: Finding Boundary Classes
One boundary class per actor/use case pair:
Course Catalog System
Register for Courses
Student
<<boundary>>
RegisterForCoursesForm
<<boundary>>
CourseCatalogSystem
The RegisterForCoursesForm contains a Student's "schedule-in-progress".
It displays a list of Course Offerings for the current semester from which the
Student may select to be added to his/her Schedule.
The CourseCatalogSystem interfaces with the legacy system that provides the
unabridged catalog of all courses offered by the university.
Module 7 - Use-Case Analysis

28. Guidelines: Boundary Class – User Interface classes
OOADv4.2 Instructor Notes
Guidelines: Boundary Class – User Interface classes
User Interface Classes
Concentrate on what information is presented to the user
Do NOT concentrate on the UI details
Analysis Classes are meant to be a first cut at the abstraction of the system.
The boundary classes may be used as ‘holding places’ for GUI classes. (Addressed in much more detail later)
Do not do a GUI design in analysis, but isolate all environment-dependent behavior. (Likely you may be able to reverse engineer a GUI component and tailor it.)
The expansion, refinement and replacement of these boundary classes with actual user interface classes is a very important activity of Class Design – later
If prototyping the interface has been done, these screen dumps or sketches may be associated with a boundary class.
Only model the key abstractions of the system – not every button, list, etc. in the GUI.
Module 7 - Use-Case Analysis

29. Guidelines: Boundary Classes – System and Device
System and Device Interface Classes
Concentrate on what protocols must be defined
Note that your application must interface with an existing ‘information source.’
Do NOT concentrate on how the protocols will be implemented
If the interface to an existing system or device is already well-defined, the boundary class responsibilities should be derived directly from the interface definition.
If there is a working communication with the external system or device, make note of it for later reference during design.

30. What is an Entity Class? (recall: boundary, entity, control…)
OOADv4.2 Instructor Notes
What is an Entity Class? (recall: boundary, entity, control…)
Key abstractions of the system
Typical examples of entity classes in a banking system are Account and Customer. In a network-handling system, examples are Node and Link.
Some entity classes may be modeled attributes. The use of attributes vs. separate classes will be discussed later in the module. Keep in mind the key OO concept encapsulation. Entity classes are not just data and structure. They also contain responsibilities.
Tto reduce confusion for those cases where you need to model information about an actor within the system, you may want to define a naming convention for naming the system classes that hold actor information. Some possibilities include (if we had an Employee class that we need to retain information for):
Employee and Employee (I.e. same name)
Employee and EmployeeInfo
EmployeeActor and Employee
EmployeeActor and EmployeeInfo
If you find “EmployeeActor” not very user-friendly, you can also try “EmployeeUser”.
Another option, instead of appending “info” to the class name, try “session” or “profile”.
Using the same name for both does not cause Rose any problems as Rose supports separate namespaces. Thus, we have used the “same name” approach in the OOAD course example and exercise.
Glossary
Analysis class stereotype
<<entity>>
Sources for entity
Classes:
Glossary
Use-Case Flow of
Events
Business domain
model
Business-Domain Model
Entity classes show the
logical data structure,
which will help us
understand what the
system is supposed to
offer to its users.
Use Case
Architectural Analysis Abstractions
Environment Independent
Module 7 - Use-Case Analysis

31. Entity Classes
Entity classes represent stores of information in the system
They are typically used to represent the key concepts the system manages.
Entity objects (instances of entity classes) are used to hold and update information about some phenomenon, such as an event, a person, or some real-life object.
(Chapter advisor, memorabilia, university, student, correspondence_item, International_Secretary, …)
They are usually persistent, having attributes and relationships needed for a long period, sometimes for the life of the system.
The main responsibilities of entity classes are to store and manage information in the system.

32. The Role of an Entity Class
OOADv4.2 Instructor Notes
The Role of an Entity Class
Entity objects can have complicated behavior;
however, unlike other objects, this behavior
is strongly related to the phenomenon the entity
object represents.
Customer
<<boundary>>
<<control>>
<<entity>>
Entity objects are usually
not specific to one use-case
realization; sometime, an
entity object is not even
specific to the system
itself.
The values of its attributes and relationships are often given by an actor.
Entity objects are independent of the environment (actors)
Store and manage information in the system
Module 7 - Use-Case Analysis

33. Example: Finding Entity Classes
OOADv4.2 Instructor Notes
Example: Finding Entity Classes
Use use-case flow of events as input
Key abstractions of the use case
Traditional, filtering nouns approach
Underline noun clauses in the use-case flow of events
Remove redundant candidates
Remove vague candidates
Remove actors (out of scope)
Remove implementation constructs
Remove attributes (save for later)
Remove operations
Module 7 - Use-Case Analysis

34. Example: Candidate Entity Classes
OOADv4.2 Instructor Notes
Example: Candidate Entity Classes
Register for Courses (Create Schedule)
If your students are new at this, you may want to go through an explicit “noun filtering” exercise with them, rather than just showing them the entity classes on this slide (i.e., go through the Register for Courses use case and underline the nouns, filtering out the ones that are not applicable for classes).
Student
CourseOffering
A person enrolled in classes at the university
A specific offering for a course
including days of week and times
Schedule
The courses a student has selected for current semester
Module 7 - Use-Case Analysis

35. Candidate Entity Classes - continued
Sometimes there is a need to model information about an actor within the system. This is not the same as modeling the actor (actors are external. by definition). These classes are sometimes called “surrogates”.
For example, a course registration system maintains information about the student which is independent of the fact that the student also plays a role as an actor of the system.
This information about the student that is stored in a ‘Student’ class is completely independent of the ‘actor’ role the student plays; the Student class (entity) will exist whether or not the student is an actor to the system.

36. Review: Generalization
OOADv4.2 Instructor Notes
Review: Generalization
Account
balance
name
number
Withdraw()
CreateStatement()
Checking
Savings
GetInterest()
Superclass (parent)
Subclasses
Generalization Relationship
One class shares the structure and/or behavior of one or more classes
“Is-a-kind of” relationship
In analysis, use sparingly
Inheritance relationships may be identified – especially in
entity classes.
Generalization used in analysis should be so obvious from the abstraction definitions, that it “hits you in the head with a 2-by-4”.
In analysis, generalization should be
used to model shared behavioral
semantics only (that is, generalization
that passes “is a kind of’ test)
The use of generalization makes the
definition of the abstractions easier to
document and understand.
When generalization found,
create a common super-class
that contains common attributes
associations, aggregations, and
operations
Module 7 - Use-Case Analysis

37. Finding Generalization: Generalization of Classes
OOADv4.2 Instructor Notes
Finding Generalization: Generalization of Classes
Savings
Checking
Stock
Bond
RealEstate
Asset
BankAccount
Security
More general
Base class
subclasses
Subclasses have
Unique semantics
And behavior.
Can generalize when you have a set of classes that share some semantics and behavior
Module 7 - Use-Case Analysis

38. Finding Generalization: Specialization of Classes
OOADv4.2 Instructor Notes
Finding Generalization: Specialization of Classes
Asset
RealEstate
Savings
BankAccount
Checking
Stock
Security
Bond
More specific
More specialized properties are placed in the lower part of the inheritance hierarchy.
Module 7 - Use-Case Analysis

39. Example: Generalization (Shared Semantics)
OOADv4.2 Instructor Notes
Example: Generalization (Shared Semantics)
Part-timeStudent
Full-timeStudent
Without Generalization
name
name
address
address
studentID
studentID
numberCourses
gradDate
Student
name
With Generalization
address
studentID
FulltimeStudent
ParttimeStudent
maxNumCourses
gradDate
Module 7 - Use-Case Analysis