Detail Design:

Use-Case Driven Design

<24> 1
Background on Use Case Design
 Have ‘done’ Architectural Design;
 You know the major (eleven) precepts of good
design.
 Now, we drop down a level to Detail Design
 Now:
Use Case Design;
Subsystem Design, and
Class Design.

Allare very different and satisfy different

purposes.
After class design, you are ready to code.
24 2
Objectives: Use-Case Design (1 of 2)

Start of ‘Detail Design’ – right above coding.

1. Verify that all necessary behaviors cited in the use
case narratives have been distributed along the
participating classes
 See use case narratives and interaction diagrams

2. Verify that all associations between design

elements (classes and subsystems in layers and other
components) needed for the use case realizations
(design solutions) have been defined,
See layer architecture and components therein.

24 3
Objectives: Use-Case Design (2 of 2)
3. Verify that all of the attributes needed for the use cases
have been defined and found in domain models, glossary,
etc.

4. Refine the Use-Case Analysis elements (boundary,

control, entity classes and subsystems interfaces) as
identified in use case analysis into design model elements

5. Ensure application architectural mechanisms

(persistence, security, etc.) are incorporated into the use case
realizations (design)
 Use Case Realizations are captured via software class diagrams and
interaction diagrams for various scenarios.

24 4
 Use-Case Design in Context
Architectural
Analysis

Architectural Describe Review the Architecture

Describe Architecture Reviewer
Architect Design Concurrency Distribution

Subsystem Design
Use-Case
Analysis
Review the
Use-Case Design Design
Designer Design Reviewer

Class
Design

Here is our workflow suggested by the Unified Process. This is merely an FYI.
Note ‘designer’ activities are related to architecture - but quite different from architect

Important to note detailed design activities (Use Case, Subsystem, and Class Design)
are tightly bound and tend to alternate between
24 one another. 5
Lastly, and very importantly:

 Note:one of the major differences between

use case analysis (what we have done - going thru
use case narratives ensuring we have domain objects
and responsibilities) and use case design (what we
are embarking upon - developing software classes) is
scale.
Analysis classes may be quite large
Lots of attributes; no behaviors.
This keeps the analysis model small.

Analysis interaction diagrams are quite easy to read and

understand and most people will grasp the whole model.
Model is rather small and conceptual!
Model does NOT represent an implementation. (design)
24 6
Use Case Design - Guidance
 Use Case Design Steps:
Describe interactions between design objects such as
classes, subsystems...
Simplify interaction diagrams using subsystems &
interfaces
Will ratchet down in Subsystem Design and Class Design

 Let the Use Case ‘drive’ the design process

Ensure interaction diagrams do their job!
Ensure interaction diagrams model the desired behaviors
(via requirements) through responsibilities (in design)

24 7
Use-Case Design Overview

Design Subsystems and Interfaces

Supplementary
Specifications
Use-Case
Design
Use-Case
Realization

Use Case
Design Classes

24 8
 Use-Case Realization – UML Notation
Use-Case Model Design Model

Use Case Use-Case Realization

Interaction Diagrams:
Use Case
Realization:

Sequence Diagrams Communications Diagrams

Use Case

Designer is responsible for the integrity of the

use case realization. Class Diagrams
24 9
Must coordinate with Architect.
 Use-Case Design Steps
 Describe Interactions Between Design Objects.
Involves replacing analysis classes with design elements.

Replace boundary classes (analysis) with subsystems;

 Such as GUI classes for boundary classes for a View

Replace external actors (e.g. external device or a system

that manages a database) with an interface to the class;
 Will show this ahead…

Note: a number of analysis entities may prevail, although

perhaps be fewer in number or adjusted.


24 10
 Ex: Incorporating Subsystem Interfaces
Analysis Classes Design Elements
Using a subsystem
as the interface to
the Billing System.
<<boundary>>
BillingSystem <<subsystem>>
BillingSystem
// submit bill() IBillingSystem
submitBill(forTuition : Double, forStudent :
Student)

<<boundary>>
CourseCatalogSystem <<subsystem>>
CourseCatalogSystem
// get course offerings() ICourseCatalogSystem

getCourseOfferings(forSemester : Semester) :
CourseOfferingList
Note: 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. So this type of boundary class (in analysis) typically morphs into a
subsystem in the Design Model. 24 11
 Ex: Incorporating Subsystem Interfaces (before)

Replace with subsystem interface

: RegisterForCoursesForm : RegistrationController : CourseCatalogSystem : Schedule : Student
: Student

1. // create schedule( )
1.1. // get course offerings( )
Student wishes to
create a new 1.1.1. // get course offerings(forSemester)
schedule
We know from Architectural Design that a
1.2. // display course offerings( ) CourseCatalogSystem Actor has been
A list of the available defined to represent the external legacy
course offerings for this
semester are displayed Course Catalog System.
A blank schedule 1.3. // display blank schedule( )
is displayed for the So, we need to refine interaction diagram
students to select and replace the CourseCatalogSystem
offerings
boundary class (from analysis) with the
. // select 4 primary and 2 alternate associated subsystem interface,
fferings( ) ICourseCatalogSystem, here in design.
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

24 13
Ex: Incorporating Subsystem Interfaces (after)
Replaced with subsystem interface Now a Design element
: RegisterFor : Registration : ICourseCatalog
CoursesForm : Schedule : Student
: Student Controller System

1: // create schedule( )
1.1: // get course offerings( )
Student wishes to
create a new 1.1.1: getCourseOfferings(Semester)
schedule
Show here how interactions are modeled
1.2: // display course offerings( )
A list of the available between design elements where one element
course offerings for this is a subsystem.
semester are displayed
Original use-case realization from Analysis
A blank schedule 1.3: // display blank schedule( ) was refined and original boundary class
is displayed for the replaced with the associated subsystem
students to select
offerings interface, ICourseCatalogSystem
Access to the Catalog system is represented
2: // select 4 primary and 2 alternate
offerings( )
via an interface to that subsystem…
2.1: // create schedule with
2.1.1: // create with offerings( )
offerings( )

2.1.2: // add schedule(Schedule)

At this, point the Submit Schedule subflow is

executed. 24 14
 More on interaction diagrams
In Use Case Design, we do not flush out the internals of
the CourseCatalogSystem subsystem.
How the subsystem accesses the external system that
manages the Catalog is abstracted here and represented
only by an interface to the subsystem.
The subsystem’s job is to connect to the external system.

This part of the Use Case Design sequence diagram will

become the subsystem context diagram in Subsystem
Design coming up
When we take on Subsystem Design we will have to
design the internals of every subsystem we abstract using
only its interface here.

24 15
 Ex: Incorporating Subsystem Interfaces - (VOPC)
<<Interface>>
Subsystem interface ICourseCatalogSystem
<<boundary>> (from External System Interfaces)
RegisterForCoursesForm
(from Registration)
<<control>> 1
RegistrationController 0..* getCourseOfferings()
(from Registration) initialize()
// submit schedule()
// display course offerings() <<entity>>
// display schedule() 1 1 // submit schedule()
// save schedule() Schedule
// save schedule() currentSchedule (from University
// create schedule with 0..1
// create schedule() Artifacts)
// getCourseOfferings()
offerings() semester
// select 4 primary and 2 alternate
// display blank schedule()
offerings() 0..1 0..1
// submit()
registrant // save()
0..1 0..* // any conflicts?()
<<entity>> // new()
Student. 0..*
(from University 0..*
Artifacts)
- name
- address 1 alternateCourses
- studentID : int 0..2
primaryCourses <<entity>>
// addSchedule() 0..4 CourseOffering
// getSchedule() (from University
// hasPrerequisites() Artifacts)
number
// passed() startTime
Static part: endTime
days
The above example is the VOPC after incorporating the design elements.
// addStudent()
The original CourseCatalogSystem boundary class has been replaced // removeStudent()
// new()
24 16
with the associated subsystem interface, ICourseCatalogSystem. // setData()
 Principle: “Design by Contract”
With this approach, when describing the
interactions, the focus remains concentrated on
the services, NOT on how the services are
implemented (realized) within 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).

24 22
 Use-Case Design Steps - continued
 Simplify Interaction Diagrams Using Subsystems
When a use case is realized (that is, ‘design’), the flow of
events is usually described in terms of executing objects;
that is, as interactions between design objects.
Often useful to encapsulate a sub-flow of events within a
subsystem. (below and next slide)

Ifdone, large subsections of the interaction diagram are

replaced with a single message to the subsystem.
This simplifies our first cuts at use-case design and resulting
interaction diagrams.
Subsystem interaction diagrams are later developed during
Subsystem Design and will illustrate the internal interactions
needed to produce each of these desired behaviors.
24 17
Guidelines: Encapsulating Subsystem Interactions
Subsystems should be represented ONLY by
their interfaces on interaction diagrams in use
case design (here)
Messages to subsystems are modeled as
messages to the subsystem interface only.
Thus any subsystem that realizes the interface can be
substituted for the interface in diagram (later).

:InterfaceA
<<subsystem>>
MySubsystem
InterfaceA
Op1()
op1()
24 20
 Guidelines: Messages sent From Interfaces
Messages to subsystems correspond to operations of the
subsystem interface (the signatures)
Interactions within subsystems will be modeled in
Subsystem Design

Very powerful statements here: Discuss real meanings!

24 21
 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 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.
Interfacesare what ensure compatibility between
the Use-Case Design and Subsystem Design.

24 25