1. Detail Design: Use-Case Design
OOADv4.2 Instructor Notes
Detail Design: Use-Case Design
Module 11 - Use-Case Design

2. Background on Use Case Design
Have ‘done’ architectural design; need to do three more types of design – each have a specific purpose:
Use case design;
Subsystem design, and
Class design.

3. Use Case Design
Use Case Design is a cross-checking, consistency-imposing activity that is focuses on the ‘use-case thread’ to make sure everything still fits together.
Part of what we do is to continually review interaction diagrams looking for inconsistencies, missing information, opportunities for reuse, etc.
Interaction diagrams: collaboration diagrams; sequence diagrams.
Check to ensure we have operations for the whole path of the flow of events – easy to forget an operation here and there.
Equivalently, are all collaborating objects and their responsibilities ‘in place’ (or add now…) to accommodate the functionality captured in the use case path?

4. Objectives: Use-Case Design
OOADv4.2 Instructor Notes
Objectives: Use-Case Design
Start of ‘Detail Design’ – right above coding.
Verify that there is consistency in the use-case implementation:
1. Verify that all necessary behaviors to support a ‘use case implementation’ have been distributed along the participating classes,
2. Verify that all associations between design elements (classes and subsystems) needed for the use case realizations have been defined,
3. Verify that all of the attributes needed for the use cases have been defined.
Use-Case Design is a cross-checking, consistency-imposing activity, focused on the “use-case thread” to make sure everything still fits together. Part of this activity involves continually reviewing the interaction diagrams, looking for inconsistencies, missing information, opportunities for re-use, etc.
We want to check that we have operations for the whole path of the flow of events. It is not easy to find holes - places where someone have forgotten to create operations -- just by looking at the design model.
Module 11 - Use-Case Design

5. Objectives: Use-Case Design (cont)
4. Refine the use-case realizations from Use-Case Analysis (we did not develop use case realizations during analysis) using defined design model elements (design classes and subsystems that the analysis classes ‘morphed into’).
5. Ensure application architectural mechanisms (persistence, security, etc.) is incorporated into the use case realizations.

6. Use-Case Design in Context
OOADv4.2 Instructor Notes
Use-Case Design in Context
The focus during Use-Case Design, as in Use-Case Analysis, is on a specific use case rather than “the big picture”, which is the focus of the Architect activities.
Use-Case Design is where you refine the use case realizations initially defined in Use Case Analysis. Instead of analysis classes, you will now describe the use case realizations in terms of design subsystems and classes.
The difference between Use-Case Analysis and Use-Case Design is scale. Analysis classes are quite large (this keeps the analysis model small). This means that analysis diagrams are quite easy to read and understand and most of the team will grasp the whole model.
Use-Case Design focuses on the externally visible behaviors of the classes and subsystems; the class and subsystem design activities are concerned with making sure that the “insides” of the class and subsystems correctly implement the publicly visible behaviors.
Architectural
Analysis
Architectural
Describe
Review the
Describe
Architecture
Architecture
Architect
Design
Concurrency
Distribution
Reviewer
Subsystem Design
Use-Case
Analysis
Review the
Use-Case
Design
Design
Designer
Design
Reviewer
Class
Design
Here is our workflow from the Rational Unified Process.
We have defined the architecture (first cut) and defined major elements in our system (subsystems, their interfaces, design classes and some processes and threads and their relationships
Note ‘designer’ activities are related to architecture - but yet quite different
Module 11 - Use-Case Design

7. Use Case Design
Have a cut at an architectural baseline (design). Let’s go into detail design:
Preliminary thoughts:
Use-Case Design is also where the design elements (design classes and subsystems) meet the architectural mechanisms.
In our use case realizations (in particular, the sequence diagrams) we will need to incorporate persistence, security, etc. activities with the other design elements.
Important to note that the detailed design activities (Use Case Design, Subsystem Design, and Class Design) are tightly bound and tend to alternate between one another.

8. Lastly,
Please note that one of the major differences between use case analysis and use case design is scale.
Analysis classes are quite large - this keeps the analysis model small.
This means that analysis diagrams are quite easy to read and understand and most of the team will grasp the whole model.
Use Case Design Steps
Describe Interactions Between Design Objects
Simplify Interaction Diagrams Using Subsystems (optional)
Focus is on the Use Case and this includes crossing subsystem boundaries.

9. Use-Case Design Overview
OOADv4.2 Instructor Notes
Use-Case Design Overview
Supplementary
Specifications
It is important to describe that there are different Designers (or Design teams) on a project, each with different focus. Use-Case Designers are concerned with the design of the use-case realizations for a particular use case, coordinating with the necessary architects, subsystem designers and class designers.
The use-case designer concentrates on the interactions between subsystems and “free” (not contained in subsystem) classes. They can defer responsibility for what happens inside the subsystems to the subsystem designer(s).
That’s the beauty of encapsulation
Be careful with the discussion of project team organization, as you don’t want the discussion to turn into a discussion of OO project management concerns. Refer the students to the OOPM course for more details on team organization.
Design Subsystems and Interfaces
Use-Case
Design
Use-Case Realization
Use-Case Realization
Use Case
Design Classes
Module 11 - Use-Case Design

10. Use-Case Realization – UML Notation
OOADv4.2 Instructor Notes
Use-Case Realization – UML Notation
Use-Case Model
Design Model
For details on how to model use-case realizations in Rose, see the instructor notes for this slide in Use-Case Analysis.
Use Case
Use-Case Realization
Interaction Diagrams:
Use Case
Realization:
Sequence Diagrams
Collaboration Diagrams
Class Diagrams
Use Case
Designer is responsible for the integrity of the
Use Case realization. Must coordinate.
Module 11 - Use-Case Design

11. OOADv4.2 Instructor Notes
Use-Case Design Steps
 Describe Interactions Between Design Objects
This involves replacing analysis classes with the design elements that they were refined into during Architectural Design as well as incorporating any applicable architectural mechanisms.
Replace boundary classes with subsystems; external actors, such as for an external device or database, with its interface; a number of analysis entities may prevail, although perhaps be smaller or adjusted.
Simplify Interaction Diagrams Using Subsystems (optional)
(Lecture 32.) Describe Persistence-Related Behavior
Refine the Flow of Events Description
Unify Classes and Subsystems
Module 11 - Use-Case Design

12. For Each Use-Case Realization
OOADv4.2 Instructor Notes
For Each Use-Case Realization
You are essentially taking the use-case realization diagrams developed in Use-Case Analysis and re-drawing them, using the design elements that the analysis classes were refined into, making sure that the responsibility allocation is still accurate.
Collaboration or sequence diagrams may be used to model these interactions. RUP recommends that sequence diagrams be used during design.
In the early stages of design, some operations may not be defined, so you may have to leave this information out and give the message a temporary name; such messages are said to be "unassigned." Later, when you have found the participating objects' operations, you should update the interaction diagram by ”mapping" the messages to these operations.
In the dynamic part of the Use Case Realization – using collaboration or sequence diagrams:
Identify participating objects needed in the flow of events.
May be instances of design classes and subsystems, or they may be instances of actors that the participating objects interact with.
Allocate responsibilities among objects (should have this done)
Model messages between objects – either operations in design classes or operations in the interface to a subsystem.
This means to construct the message arrow in the sequence diagram.
Describe processing resulting from messages
Attach a script to object describing what it does when it receives a message.
In the static part of the Use Case Realization:
Model associated class relationships that support the collaborations modeled in the interaction diagrams
Module 11 - Use-Case Design

13. Use-Case Realization – Dynamic Modeling (Interaction Diagrams)
OOADv4.2 Instructor Notes
Use-Case Realization – Dynamic Modeling (Interaction Diagrams)
Look at the Interaction Diagrams…Replace applicable classes with the associated subsystem interfaces (but no HOWs)
Incrementally incorporate applicable architectural mechanisms – using patterns of behavior defined for the mechanisms in architectural activities.
This may include the introduction of new design elements and messages.
Update use-case realization – both static and dynamic parts:
Interaction diagrams (sequence / collaboration diagrams)
View of participating classes (VOPC) class diagram(s)
Note: On the presented slide, the items that were added/utilized as part of incorporating the subsystem interface are shown in yellow, but this does not show up in the back-and-white manuals.
Module 11 - Use-Case Design

14. Ex: Incorporating Subsystem Interfaces
OOADv4.2 Instructor Notes
Ex: Incorporating Subsystem Interfaces
BillingSystem
// submit bill()
<<boundary>>
<<subsystem>>
IBillingSystem
CourseCatalogSystem
// get course offerings()
ICourseCatalogSystem
Analysis Classes
Design Elements
Emphasize the rationale for choosing these subsystems -- external system access.
In Rose, you cannot draw a realization relationship from a subsystem (a.k.a. package) to an interface.
See Modeling Design Subsystems slide instructor notes for a description of a workaround.
submitBill(forTuition : Double, forStudent : Student)
getCourseOfferings(forSemester : Semester) : CourseOfferingList
Recall: we determined that interactions to support external system access will be more
complex than can be implemented in a single class. So, we identified subsystems to
encapsulate this access to external systems.
Some analysis classes mapped directly to design classes in the Design Model
Module 11 - Use-Case Design

15. Ex: Incorporating Subsystem Interfaces (before)
OOADv4.2 Instructor Notes
Ex: Incorporating Subsystem Interfaces (before)
Replace with subsystem interface
: Student
: RegisterForCoursesForm
: RegistrationController
: Schedule
: 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( )
2. // select 4 primary and 2 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)
At this point, the Submit Schedule subflow is executed
We know from Architectural Design that a
CourseCatalogSystem subsystem has been
defined to encapsulate access to the
external legacy Course Catalog System.
So, we need to refine interaction diagram
and replace the CourseCatalogSystem
boundary class with the associated
subsystem interface,
ICourseCatalogSystem.
Module 11 - Use-Case Design

16. Ex: Incorporating Subsystem Interfaces (after)
OOADv4.2 Instructor Notes
Ex: Incorporating Subsystem Interfaces (after)
Replaced with subsystem interface
Note: On the presented slide, the items that were added/utilized as part of incorporating the subsystem interface are shown in yellow, but this does not show up in the back-and-white manuals.
: RegisterFor CoursesForm
: Registration Controller
: ICourseCatalog System
: Schedule
: Student
: Student
1: // create schedule( )
1.1: // get course offerings( )
Student wishes to
create a new
1.1.1: getCourseOfferings(Semester)
schedule
1.2: // display course offerings( )
Show here how interactions are modeled
between design elements where one element
is a subsystem.
Original use-case realization was refined and
original boundary class replaced with the
associated subsystem interface,
ICourseCatalogSystem
A list of the available
course offerings for this
semester are displayed
A blank schedule
1.3: // display blank schedule( )
is displayed for the
students to select
offerings
2: // select 4 primary and 2 alternate offerings( )
2.1: // create schedule with offerings( )
2.1.1: // create with offerings( )
2.1.2: // add schedule(Schedule)
At this, point the Submit Schedule subflow is executed.
Module 11 - Use-Case Design

17. More on interaction diagrams – in some cases from analysis
In Use Case Design, we will not flush out the internals of the CourseCatalogSystem subsystem.
This diagram will become the subsystem context diagram in Subsystem Design.
In Subsystem Design we will concentrate on the internals of the subsystem.

18. Ex: Incorporating Subsystem Interfaces - (VOPC)
OOADv4.2 Instructor Notes
Ex: Incorporating Subsystem Interfaces - (VOPC)
Subsystem interface
<<Interface>>
ICourseCatalogSystem
Note: On the presented slide, the items that were added/utilized as part of incorporating the subsystem interface are shown in yellow, but this does not show up in the back-and-white manuals.
<<boundary>>
(from External System Interfaces)
RegisterForCoursesForm
<<control>> 1
(from Registration)
RegistrationController
0..*
getCourseOfferings()
(from Registration)
initialize()
// submit schedule()
// display course offerings()
<<entity>>
// display schedule() 1 1
// submit schedule()
// save schedule()
Schedule
// save schedule()
// create schedule with offerings()
currentSchedule
0..1
(from University Artifacts)
// create schedule()
// getCourseOfferings()
semester
// select 4 primary and 2 alternate offerings()
// display blank schedule()
0..1
0..1
// submit()
registrant
// save()
0..1
0..*
// any conflicts?()
<<entity>>
// new()
Student.
0..*
0..*
(from University Artifacts)
- name
- address 1
alternateCourses
- studentID : int
0..2
primaryCourses
<<entity>>
// addSchedule()
0..4
CourseOffering
// getSchedule()
(from University Artifacts)
// hasPrerequisites()
number
// passed()
startTime
Static part:
endTime
days
The above example is the VOPC after incorporating the design elements.
The original CourseCatalogSystem boundary class has been replaced
with the associated subsystem interface, ICourseCatalogSystem.
// addStudent()
// removeStudent()
// new()
// setData()
Module 11 - Use-Case Design

19. Incorporating Architectural Mechanisms: Security
OOADv4.2 Instructor Notes
Incorporating Architectural Mechanisms: Security
Analysis-Class-to-Architectural-Mechanism Map from Use-Case Analysis
Emphasize to the students that you will not be covering the incorporation of the security mechanism; however, the details can be found in the appendix.
If you choose to present the security mechanism, the slides found in the Additional Information appendix, Security Mechanism section, second part, should be inserted after this slide.
Note: On the presented slide, the italicized text is also yellow, but this does not show up in the back-and-white manuals.
Analysis Class
Analysis Mechanism(s)
Student
Persistency, Security
Schedule
Persistency, Security
CourseOffering
Persistency, Legacy Interface
Course
Persistency, Legacy Interface
RegistrationController
Distribution
In Use Case Analysis, applicable mechanisms for each identified analysis class were
considered (should be documented too). This info, along with the information on what
analysis classes became what design elements allows the applicable mechanisms for a
design element to be identified.
Above only concentrates on the course registration in our examples – these are the only
classes that have analysis mechanisms assigned to them.
Module 11 - Use-Case Design

20. OOADv4.2 Instructor Notes
Analysis-Class-to-Architectural-Mechanism Map from Use-Case Analysis
Emphasize to the students that you will not be covering the incorporation of the RMI mechanism; however, the details can be found in the appendix.
If you choose to present the distribution (RMI) mechanism, the slides found in the Additional Information appendix, RMI Mechanism section, second part, should be inserted after this slide.
Note: On the presented slide, the italicized text is also yellow, but this does not show up in the back-and-white manuals.
Analysis Class
Analysis Mechanism(s)
Student
Persistency, Security
Schedule
Persistency, Security
CourseOffering
Persistency, Legacy Interface
Course
Persistency, Legacy Interface
RegistrationController
Distribution
The details of incorporating the distribution (RMI) mechanism will be provided in the
future. So will the Security Mechanism (for our Course Registration System
application
Details in Appendix
Module 11 - Use-Case Design

21. Use-Case Design Steps - continued
OOADv4.2 Instructor Notes
Use-Case Design Steps - continued
Describe Interactions Between Design Objects
Simplify Interaction Diagrams Using Subsystems (optional)
When a use case is realized, the flow of events is usually described in terms of executing objects; that is, as interactions between design objects.
It may be useful to encapsulate a sub-flow of events within a subsystem.
If done, large subsections of the interaction diagram are replaced with a single message to the subsystem.
Within the subsystem, a separate interaction diagram may illustrate the internal interactions within the subsystem that provides the required behavior. These subsystem interaction diagrams are developed during Subsystem Design.
Describe Persistence-Related Behavior
Refine the Flow of Events Description
Unify Classes and Subsystems
The RUP step is “Simplify Sequence Diagrams Using Subsystems (optional)”. We have used “interaction” instead because we did not want to constrain the designer.
Module 11 - Use-Case Design

22. Encapsulating Subsystem Interactions
OOADv4.2 Instructor Notes
Encapsulating Subsystem Interactions
Interactions can be described at several levels
Lifelines in the middle represent sub-states;
Interactions in circles represent the internal interaction of subsystem members in response to the message.
Subsystem interactions can be described in their own interaction diagrams
Raises the level of abstraction
Module 11 - Use-Case Design

23. When to Encapsulate Sub-Flows in a Subsystem
OOADv4.2 Instructor Notes
When to Encapsulate Sub-Flows in a Subsystem
Sub-flow occurs in multiple use-case realizations
Sub-flow occurs only in one use case realization, but:
Sub-flow has reuse potential
Sub-flow is complex and easily encapsulated
Sub-flow is responsibility of one person/team
Sub-flow produces a well-defined result
Sub-flow is encapsulated within a single Implementation Model component
Make sure what you are abstracting is worth abstracting. There’s no free lunch!
This slide lists those instances when sub-sequences of messages (a.k.a. subflows) within interaction diagrams should be encapsulated within a subsystem.
Sometimes you see repeated patterns of interaction in these early use-case realizations that give birth to new subsystems and some revisions in the use-case realizations. It is important for the Architect to look within and across subsystems for common behavior (i.e., common collaborations) within the subsystems, pulling it out where possible. This is a reuse scavenging activity that falls under the Architectural Design umbrella.
The subflow encapsulated within the subsystem becomes a behavior of the subsystem and should be defined in an interface that the subsystem realizes. Existing dependencies will need to be adjusted to support the new/refined interface. Adjustment/refinement of subsystem interfaces and dependencies is an “Architectural Design” activity and should be performed by the Architect. The modeling of the collaborations within a subsystem is a “Subsystem Design’ activity and should be performed by the Subsystem Designer”
Module 11 - Use-Case Design

24. Guidelines: Encapsulating Subsystem Interactions
OOADv4.2 Instructor Notes
Guidelines: Encapsulating Subsystem Interactions
Subsystems should be represented ONLY by their interfaces on interaction diagrams
Otherwise other diagrams would have to be changed whenever subsystems are substituted
Messages to subsystems are modeled as messages to the subsystem interface
Thus any subsystem that realizes the interface can be substituted for the interface in diagram.
<<subsystem>>
MySubsystem
InterfaceA
op1()
Op1()
:InterfaceA
Module 11 - Use-Case Design

25. Guidelines: Messages Going OUT From Interfaces…
Messages to subsystems correspond to operations of the subsystem interface
Interactions within subsystems will be modeled in Subsystem Design
In many cases, the interface lifeline does not have messages going out from it, since different subsystems realizing the interface may send different messages.
However, if you want to describe what messages should be sent (or are allowed to be sent) from any subsystem realizing the interface, such messages can go out from the interface lifeline.

26. Principle: Design by Contract
With this approach, when describing the interactions, the focus remains focused on the services, NOT on how the services are implemented within the design elements.
This is known as “Design by Contract” and is one of the core tenets of robust software development using abstraction and encapsulation mechanisms.
Describing HOW the services are implemented is the focus of Subsystem Design (for the design subsystems) and Class Design (for the design classes).

27. Advantages of Encapsulating Subsystem Interactions
OOADv4.2 Instructor Notes
Advantages of Encapsulating Subsystem Interactions
Parallel subsystem development is discussed in more detail on the next slide.
Use-case realizations are less cluttered – especially if the internal design of subsystem in complex.
Use-case realizations can be created before the internal designs of subsystems are created (parallel development)
Ensures the use case functionality hasn’t been lost between allocation of use-case responsibility (in Use Case Analysis) and the identification of design elements (subsystems and design classes) in Architectural Design, and before Subsystem Design is performed.
Use-case realizations are more generic and easy to change (subsystems can be substituted)
Again, encapsulating subsystem interactions raises the level of abstraction of the use-case realization flows of events.
Module 11 - Use-Case Design

28. Parallel Subsystem Development
OOADv4.2 Instructor Notes
Parallel Subsystem Development
This is critical information. It really describes parallel software development, which is enabled via the establishment of a well-defined and stable architecture.
Note: This discussion holds true for packages if you substitute “public classes” for “interfaces”. That being said, anytime you find yourself wanting to define packages with some public classes and mostly implementation classes, you may want to consider using a subsystem instead -- more robust modeling technique (no dependencies on anything inside subsystem).
IF we are developing subsystems more or less independently, first find subsystem dependencies by identifying the interfaces between them. How?
Approach:
Concentrate on requirements that affect subsystem interfaces
Outline required interfaces
Show messages that are going to pass over the subsystem borders…
Draw interaction diagrams in terms of subsystem interfaces for each use case
Refine the interfaces needed to provide messages
Develop each subsystem in parallel – using the interfaces as synchronization instruments between development teams.
Module 11 - Use-Case Design

29. Parallel Subsystem Development
May decide to arrange the interaction diagrams in term of subsystems or in terms of their interfaces only.
In some projects, it might even be necessary to implement the classes providing the interfaces before you continue with the rest of the modeling.
The detailed design of the subsystem “internals” is done during Subsystem Design.
The interfaces are what ensure compatibility between the Use-Case Design and the Subsystem Design.