Detail Design:Use-Case Design

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.

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?

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.

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.

Use-Case Design in Context

Architect

Designer

ArchitecturalAnalysis

ArchitectureReviewer

Review theDesign

Review theArchitecture

Use-CaseAnalysis

ArchitecturalDesign

DescribeConcurrency

DescribeDistribution

ClassDesign

Subsystem Design

Use-Case Design

DesignReviewer

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 relationshipsNote ‘designer’ activities are related to architecture - but yet quite different

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.

Use Case Design

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 StepsDescribe Interactions Between Design ObjectsSimplify Interaction Diagrams Using

Subsystems (optional)Focus is on the Use Case and this includes

crossing subsystem boundaries.

Use-Case Design Overview

SupplementarySpecifications

Use-CaseDesign

Use-Case Realization Use-Case Realization

Design Subsystems and Interfaces

Design Classes

Use Case

Use-Case Realization – UML Notation

Class Diagrams

Sequence Diagrams

Use Case

Use-Case Model Design Model

Use Case Use-Case Realization

Collaboration Diagrams

Designer is responsible for the integrity of the Use Case realization. Must coordinate.

Interaction Diagrams:Use CaseRealization:

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

For Each Use-Case Realization 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

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)

BillingSystem

// submit bill()

<<boundary>>

BillingSystem<<subsystem>>

IBillingSystem

CourseCatalogSystem

// get course offerings()

<<boundary>>

CourseCatalogSystem<<subsystem>>

ICourseCatalogSystem

Analysis Classes Design Elements

Ex: Incorporating Subsystem Interfaces

getCourseOfferings(forSemester : Semester) : CourseOfferingList

submitBill(forTuition : Double, forStudent : Student)

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

Ex: Incorporating Subsystem Interfaces (before)

Replace with subsystem interface

: Student : RegisterForCoursesForm : RegistrationController : Schedule : Student : 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( )

1.1.1. // get course offerings(forSemester)

1.3. // display blank schedule( )

2. // select 4 primary and 2 alternate offerings( )

2.1. // create schedule with offerings( )2.1.1. // create with offerings( )

A blank schedule is displayed for the students to select offerings

2.1.2. // 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.

Ex: Incorporating Subsystem Interfaces (after)

: Student

: RegisterForCoursesForm

: RegistrationController

: Schedule : Student : ICourseCatalogSystem

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( )

2.1.2: // add schedule(Schedule)

1.1.1: getCourseOfferings(Semester)

1.3: // display blank schedule( )

At this, point the Submit Schedule subflow is executed.

2: // select 4 primary and 2 alternate offerings( )

2.1: // create schedule with offerings( )2.1.1: // create with offerings( )

A blank schedule is displayed for the students to select offerings

Replaced with subsystem interface

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

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.

Ex: Incorporating Subsystem Interfaces - (VOPC)

ICourseCatalogSystem

getCourseOfferings()initialize()

(from External System Interfaces)

<<Interface>>

RegisterForCoursesForm

// submit schedule()// display course offerings()// display schedule()// save schedule()// create schedule()// select 4 primary and 2 alternate offerings()// display blank schedule()

(from Registration)

<<boundary>>

Student.

- name- address- studentID : int

// addSchedule()// getSchedule()// hasPrerequisites()// passed()

(from University Artifacts)

<<entity>>

RegistrationController

// submit schedule()// save schedule()// create schedule with offerings()// getCourseOfferings()

(from Registration)

<<control>>

0..1

0..1registrant

1 1Schedule

semester

// submit()// save()// any conflicts?()// new()

(from University Artifacts)

<<entity>>

0..*

1

0..1

0..1

currentSchedule

CourseOffering

numberstartTimeendTimedays

// addStudent()// removeStudent()// new()// setData()

(from University Artifacts)

<<entity>>

0..*

0..4primaryCourses

0..*

0..2

alternateCourses

0..*1

Subsystem interface

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.

Static part:

Analysis Class Analysis Mechanism(s)

Student

CourseOffering

Course

RegistrationController

Persistency, Security

Persistency, Legacy Interface

Persistency, Legacy Interface

Distribution

Incorporating Architectural Mechanisms: Security

Analysis-Class-to-Architectural-Mechanism Map from Use-Case Analysis

Schedule Persistency, Security

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.

Analysis Class Analysis Mechanism(s)

Student

CourseOffering

Course

RegistrationController

Persistency, Security

Persistency, Legacy Interface

Persistency, Legacy Interface

Distribution

Analysis-Class-to-Architectural-Mechanism Map from Use-Case Analysis

Schedule Persistency, Security

Details in Appendix

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

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

Raises the level of abstraction

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

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!

<<subsystem>>MySubsystemInterfaceA

op1()Op1()

:InterfaceA

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.

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.

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

Advantages of Encapsulating Subsystem Interactions

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.

Parallel Subsystem Development

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.

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.

Parallel Subsystem Development