Detail Design

Subsystem Design
Background and the
Dynamic Part

1
Objectives: Subsystem Design
 Understand the purpose of Subsystem Design and
where in the lifecycle it is performed
  Define the behaviors specified in the
subsystem's interfaces in terms of
collaborations of contained classes (mentioned in
Use Case Design)
  Document internal structure of the subsystem
  Determine the dependencies upon elements
external to the subsystem that may be needed to
support the responsibilities of the interface.

2
 Subsystem Design in Context in the UP
At this time in our Design,
we have defined classes,
subsystems, their interfaces,
and their dependencies. Architectural
Analysis

Have looked at components Review the Architecture

Architectural Describe Describe
or sub-systems, i.e., Architect Design Concurrency Distribution
Architecture Reviewer

‘containers’ of complex
behavior that we have
treated as a black box.

Now we need to flesh out

Subsystem Design
the internal interactions, i.e., Use-Case
Analysis
what classes exist in the Review the
Use-Case Design
subsystem and how do they Designer Design
Design
Reviewer
collaborate to support
responsibilities documented Class
Design
in the subsystem interfaces.

3
This is what subsystem design is all about.
 Subsystem Design in Context
Here in subsystem design: We look at:

1) the detailed responsibilities

of the subsystem and define
and refine the classes needed
to implement responsibilities, Architectural
Analysis
while
Architectural Describe Review the Architecture
Describe Architecture Reviewer
2) refining subsystem Architect Design Concurrency Distribution

dependencies as needed.

The internal interactions are

expressed as collaborations
Subsystem Design
of classes and possibly other Use-Case
Analysis
components or subsystems. Use-Case
Review the
Design Design
Designer Design Reviewer
The focus is on the subsystem.
Class
Design
The activity is iterative and
recursive, but eventually 4
feeds Class Design.
 Subsystem Design Overview
Subsystem Design is performed once per Design Subsystem.

Purpose: to define the behaviors specified in the interface via its contained classes:
to document the internal structure of the subsystem,
to define realizations between subsystem’s interface(s) and contained classes, &
to determine the dependencies upon other subsystems.

Design Subsystems and Interfaces Design Subsystems and Interfaces

(updated)

Subsystem
Design
Use-Case Realization Use-Case Realization
(updated)

Design 5
Guidelines Design Classes
 Review: Subsystems and Interfaces
 Subsystem is a “cross between” a package and a class
 Has semantics of a package
 (i.e., can contain other model elements)

 and a class (has behavior).

 Subsystem realizes one or more interfaces which define its
behaviors
<<interface>>
Interface <<subsystem>>
Subsystem
Name
Interface Realization (Canonical form) Subsystem

<<subsystem>>
Subsystem Name
Interface 6
Realization (Elided form)
 Review: Subsystems and Interfaces
 An interface is a model element which defines a set of
behaviors (set of operations) offered by a classifier model
element (e.g., class, subsystem or component).
  A classifier may realize one or more interfaces.
  An interface may be realized by one or more classifiers.
<<interface>>
Interface <<subsystem>>
Subsystem Name

Interface Realization (Canonical form) Subsystem

<<subsystem>>
Subsystem Name
Interface
7
Realization (Elided form)
 Review: Subsystems and Interfaces
 Interfaces are not classes; provide no default behavior.
 Realization is a semantic relationship between two classifiers
– one serves as contract (the interface ‘class’) ; other, carries it
out that is ‘realizes’ the contract.
 via its subsystem contents and its dependencies

<<interface>>
Interface <<subsystem>>
Subsystem Name

Interface Realization (Canonical form) Subsystem

<<subsystem>>
Subsystem Name
Interface 8
Realization (Elided form)
 Key is abstraction
Subsystem Guidelines and encapsulation

 Goals
 Loose coupling; as independent as possible <<subsystem>>
 Insulation from change - minimized A
 Replaceable elements in the model.

 Strong Suggestions for Subsystems:

 Don’t expose details, only the interfaces <<subsystem>>
B
 No element contained by a subsystem should
have public visibility.
 No element outside the subsystem should depend <<subsystem>>
on a particular element inside the subsystem. C

 Only depend on interfaces of other model

elements so that it is not directly dependent on
any specific model element outside the subsystem. 9
 Key is abstraction
Subsystem Guidelines and encapsulation

<<subsystem>>
Exception: can share some class definitions A

done with packages in lower layers to ensure

common definition of classes which must pass
between subsystems
<<subsystem>>
B
All dependencies on a subsystem should be
dependencies on the subsystem interfaces only!!
 clients not dependent on inside! <<subsystem>>
C
 subsystem can be replaced by different
subsystem that realizes same interface.
10
Modeling Convention for Subsystems and Interfaces

Represent subsystems as three items in model:

1. <<subsystem>> package;
2. <<subsystem proxy>> class,
3. subsystem interface (class with stereotype <<interface>>).

Subsystem package provides a container for the elements in the subsystem.

The interaction diagrams describe how the

subsystem elements collaborate to
implement the operations of the <<subsystem>>
interface the subsystem realizes, CourseCatalogSystem

Note: <<subsystem proxy>>

class actually realizes the <<subsystem proxy>>
interface and will orchestrate CourseCatalogSystem
the implementation of the
subsystem operations. ICourseCatalogSystem
11
Different (additional) interfaces would have their own proxy!
 Subsystem Design: Major Steps
 Distribute Subsystem behaviors to Subsystem
Elements
 that is, the design components inside the subsystem.

 Next, Document Subsystem Elements (e.g. classes…)

 Document internal structural relationships among
classes
 Then document the interfaces upon which the
subsystem itself is dependent.
 Then, review the results of your subsystem design.

 Now, let’s look at each of these

12
 Subsystem Responsibilities
 Subsystem responsibilities defined by the interface it realizes
  When a subsystem realizes an interface, it makes a
commitment to support every operation defined by the interface.
  Interface operations may be realized by
 Internal class operations (which may require collaboration
with other classes or subsystems)
 An interface realized by a contained subsystem.

<<interface>>
ICourseCatalogSystem <<subsystem>>
getCourseOfferings() CourseCatalogSystem

13
subsystem responsibility
 Modeling Convention:
Subsystem Interaction Diagrams - General

Subsystem Client Subsystem Proxy Design Element 1 Design Element 2

performResponsibility( )
Op1()

subsystem
responsibility Op2() Internal subsystem
interactions
Op3()

Op4()

Subsystem interface not shown

16
 Modeling Convention:
Subsystem Interaction Diagrams - General
Subsystem Client Subsystem Proxy Design Element 1 Design Element 2

performResponsibility( )
Op1()

subsystem responsibility Op2()

Internal subsystem
interactions
Op3()

Op4()

• A message should be drawn from the <<subsystem>> client to the <<subsystem proxy>>
• Note: interface does not appear on internal subsystem interaction diagram.
• Remainder of diagram should model how the <<subsystem proxy>> class delegates
responsibility for performing the invoked operation to the other subsystem elements.

•  Recommend you name the interaction diagram <interface name>::<operation name>>.

• This convention simplifies future tracing of interface behaviors to the classes implementing the17
interface operations.
Example: CourseCatalogSystem Subsystem In Context
(1 of 2)
subsystem interface
: RegisterFor : Registration : ICourseCatalog : Schedule : Student
: Student CoursesForm Controller System

1: // create schedule( )
2: // get course offerings( )
Student wishes to
create a new 3: getCourseOfferings(Semester)
schedule

4: // display course offerings( )

subsystem responsibility
A list of the available
course offerings for this •This sequence diagram sets the context of what
semester are displayed
will be performed in Subsystem Design.

• Puts requirements on the subsystem, and

Note: I have ‘cut’ a lot of detail • Is the primary input specification to the
out of this sequence diagram and task of creating local interactions
within the subsystem.
the next one so that it is ‘easy’ to
see the thrust of this slide…

18
Example: CourseCatalogSystem Subsystem In Context (2 of 2)

subsystem interface
: RegisterFor : Registration : ICourseCatalog : Schedule : Student
: Student CoursesForm Controller System

1: // create schedule( )
2: // get course offerings( )
3: getCourseOfferings(Semester)

subsystem responsibility Legacy RDBMS

Database Access

• The ICourseCatalogSystem::getCourseOfferings()
documentation specifies: “Retrieve the course
offerings available for the specified semester.”

• So retrieval of the course offerings from legacy

database is responsibility of CourseCatalog system.

• Now, must show exactly HOW this is done using the

RDBMS persistency mechanism. This will be shown
when we actually do the subsystem design (ahead)
19
 Review: Incorporating JDBC: Steps of Steps
 (Done:) Provide access to the class libraries needed to implement
JDBC; (i.e., Provide java.sql package)
 (Done. Seen in Persistency:) Create the necessary DBClasses and
their dependencies (for objects requiring persistency)
 Remember, the proxy class is the class that manages the responsibilities
of the subsystem as found in its interface.
 You may think of it as a ‘control class’ for a particular interface.

 Review slide 14 (and others) in lecture 29. DBClass and

PersistentClassList and PersistentClass (and others) were stereotyped
<<role>>, which implied their specific implementation is built by the
designer when applying a mechanism such as persistency, legacy
database access, etc.
 Recall DBClass had methods like read(), update(), delete() create()…
 In the next couple of slides, we are doing exactly that with the
DBCourseOffering class in attempting the access the legacy RDBMS
(continued)
to read data, execute a query, and more.
 We have a DBCourseOffering along with CourseOfferingList and a20
CourseOffering to get results from executeQuery() (ahead)
more
 Note also that the Course Catalog System is clearly an
Actor, which, of course, it should be, AND it is shown as
such – in place – in the Sequence Diagram.
 Note that the proxy class, DBCourseOffering, and the
objects within java.sql are all involved in constituting the
interface with the legacy RDBMS system.
 So, we are seeing HOW the Course Catalog Subsystem
via the proxy class and its dependencies are handling
responsibilities.
 Note that the next couple of slides do NOT have the
caveat ‘Context.’
 They do not show the context for the subsystem or its interface;
rather, this is the design implementation of the interface!
 This is the subsystem design.
21
 Ex: Local CourseCatalogSystem Subsystem Interaction
CourseCatalog : : : Connection : Statement : : : ResultSet
: Course Catalog CourseOfferingList CourseOffering
System Client CourseCatalogSystem DBCourseOffering

1. getCourseOfferings(Semester) Retrieve all available course• Internals of subsystems should yield interaction diagrams
offerings for the current that look like this.
Subsystem Proxy semester
• We see collaborations to implement the getCourseOfferings
(represents Subsystem) 1.1. read(string) operation of the ICourseCatalogSystem interface.
• Recall: legacy system stores course offerings in an RDBMS.
1.1.1. createStatement( )
• Here we show how the RDBMS persistency mechanism
sql statement is passed in
specifying the search criteria -- identified in Architectural Design is realized in the design.
1.1.2. executeQuery(String)
course offerings in the current
semester 1.1.2.1. // executeQuery( Create
) a list to hold all
retrieved course offerings
Repeat these operations for each 1.1.3. new( )
element returned from the
executeQuery() command.
RDBMS
The CourseOfferingList is loaded
1.1.4. new( ) Read
with the data retrieved from the 2. getString( )
database.
The getData and setData 3. setData( )
operations are called for each
attribute in the each retrieved 4. add(CourseOffering)
class instance.

Add the retrieved course offering

to the list to be returned

CourseCatalogSystem (proxy) is in subsystem. DBCourseOffering object is created by designer

(think DBClass in past lectures) as needed persistency and legacy interfacing.
There is a dependency between the DBCourseOfferings and objects in java.sql starting with
Connection and the actual access to the RDBMS via actor CourseCatalog.
22
Note the design objects: CourseOfferingList and CourseOffering (no longer <<role>>
Ex: Local CourseCatalogSystem Subsystem Interaction
CourseCatalog : : : Connection : Statement : : : ResultSet
: Course Catalog CourseOfferingList CourseOffering
System Client CourseCatalogSystem DBCourseOffering
• To read the course offerings, the persistency client requests
1. getCourseOfferings(Semester) Retrieve all available course a service from the subsystem interface, represented by the
offerings for the current proxy class, who asks the DBCourseOffering class to retrieve a
semester course offerings for the specified semester.
Subsystem Proxy • DBCourseOffering creates a new statement using Connection
1.1. read(string) class’s createStatement() operation.
• The statement is executed; data is returned to ResultSet object.
1.1.1. createStatement( ) DBCourseOffering then creates a list of CourseOffering
sql statement is passed in instances, CourseOfferingList, populates it with retrieved
specifying the search criteria -- 1.1.2. executeQuery(String)
data, and returns it to the client.
course offerings in the current
semester 1.1.2.1. // executeQuery( Create
) a list to hold all
retrieved course offerings
1.1.3. new( )
RDBMS
Repeat these operations for each
element returned from the Read
executeQuery() command.
1.1.4. new( )
The CourseOfferingList is loaded
with the data retrieved from the
2. getString( )
database.

The getData and setData 3. setData( )

operations are called for each
attribute in the each retrieved 4. add(CourseOffering)
class instance.

Add the retrieved course offering

to the list to be returned

23
 If we have time, we’ll go through the Billing System. But
the ideas are the same…

 Idea behind the Billing System is almost the same, but the
Billing System does not require a persistency mechanism.

 Start with the Billing subsystem interface object in the next

slide at the end…
 Really showing how the submitBill(Student, double) is
implemented in the subsystem. But first:
 Billing System in Context – then Local

24
 Example: Billing System Subsystem In Context
subsystem interface
: : : : : Schedule : Student. :
: Registrar CloseRegistrationForm CloseRegistrationController ICourseCatalogSystem CourseOffering IBillingSystem
• Here, will demonstrate design of a subsystem that does
1. // close registration( ) not require a persistency mechanism.
1.1. // is registration open?( ) Retrieve a list of course • This is at portion of the Close Registration use-case
offerings for the current realization sequence diagram.
2. // close registration( ) semester The internals of the Billing System Subsystem
Close have not been designed yet. That is
2.1. getCourseOfferings(Semester) registration for the purpose of this activity, Subsystem Design
each course
Repeat twice this is If the maximum number of
offering
for simplicity; selected primary courses have
realistically, an 2.2. // close registration( )
not been committed, select
indefinite number of alternate course offerings).
iterations could
occur)
2.3. // level( )

Finally commit or
2.4. // close( ) Currently assuming tuition based on
cancel the course
offering once all number of offerings taken and certain
leveling has occurred attributes of students. If different offerings
get different prices this will change slightly.
2.5. getTuition( )
Send student and tuition to
the Billing System, which will
do the actual billing to the 2.6. submitBill(Student, double)
student for the schedule.

subsystem responsibility
25
Now, we are really after the next slide…
 Example: Billing System Subsystem In Context
subsystem interface
: : : : : Schedule : Student. :
: Registrar CloseRegistrationForm CloseRegistrationController ICourseCatalogSystem CourseOffering IBillingSystem
• Here we put requirements on the subsystem, and
1. // close registration( ) the sequence diagram is the primary input spec to
1.1. // is registration open?( ) creating local interactions for the subsystem.
Retrieve a list of course
offerings for the current • We see the operations subsystem must support. Shows
semester the simple way some client (CloseRegistrationController
2. // close registration( )
Close here) deals with the task of submitting bill to
2.1. getCourseOfferings(Semester) registration for the legacy Billing System.
each course
Repeat twice this is If the maximum number of
offering
for simplicity; selected primary courses have
realistically, an 2.2. // close registration( )
not been committed, select
indefinite number of alternate course offerings).
iterations could
occur)
2.3. // level( )

Finally commit or
2.4. // close( ) Currently assuming tuition based on
cancel the course
offering once all number of offerings taken and certain
leveling has occurred attributes of students. If different offerings
get different prices this will change slightly.
2.5. getTuition( )
Send student and tuition to
the Billing System, which will
do the actual billing to the 2.6. submitBill(Student, double)
student for the schedule.

subsystem responsibility
26
More coming…
 Explanation for next slides

•The IBillingsystem::submitBill() documentation specifies

the following: “Billing information must be converted
into a format understood by the external Billing System
and then submitted to the external Billing System.

Thus the actual generation and submission of the bill is

responsibility of the Billing System subsystem once the bill and
proper parameters are passed to it.

But the billing information must be converted into a format that the
Billing System can understand.

Let’s see how all this is done…

27
Example: Local BillingSystem Subsystem Interaction
Subsystem Proxy
Billing System : : : Student. :
: Billing System
Client BillingSystem StudentBillingTransaction BillingSystemInterface

1. submitBill(Student, double)
Retrieve the
information that must
1.1. create(Student, double) be included on the bill

1.1.1. // get contact info( )

1.2. submit(StudentBillingTransaction)

Logic here must convert the contract info 1.2.1. // open connection( )
into a format (StudentBillingTransaction)
that the Billingsystem can understand. 1.2.2. // process transaction( )

Given this, the proxy will orchestrate 1.2.3. // close connection( )

opening, processing, and closing the
connection (and submitting the bill).

No DBCourseOffering is needed here

But StudentBillingTransaction is designed to convert
data into a form the Billing System can understand
from Student information and the ‘double.’ 28
We simply see HOW the subsystem interface is realized.
Example: Local BillingSystem Subsystem Interaction
Subsystem Proxy
Billing System : : : Student. :
: Billing System
Client BillingSystem StudentBillingTransaction BillingSystemInterface

1. submitBill(Student, double)
Retrieve the
information that must
1.1. create(Student, double) be included on the bill

1.1.1. // get contact info( )

1.2. submit(StudentBillingTransaction)

1.2.1. // open connection( )

• The client object initiating the interaction
is abstracted. Again, we don’t care… 1.2.2. // process transaction( )
• The BillingSystem subsystem proxy
class actually realizes the 1.2.3. // close connection( )
IBillingSystem interface and drives this
realization by delegating the
implementation of the interface to the
subsystem elements.

29
Example: Local BillingSystem Subsystem Interaction
Subsystem Proxy
Billing System : : : Student. :
: Billing System
Client BillingSystem StudentBillingTransaction BillingSystemInterface

1. submitBill(Student, double)
Retrieve the • The BillingSystem proxy class instance
information that must creates a StudentBillingTransaction
1.1. create(Student, double) be included on the bill specific to the external Billing System.
• This transaction will be in a format that
1.1.1. // get contact info( ) the Billing System can process.
• The StudentBillingTransaction knows
how to create itself using information
1.2. submit(StudentBillingTransaction) from the given Student.

Note that only a single message is 1.2.1. // open connection( )

sent to the proxy: submitBill(…)
The proxy, then, implements this 1.2.2. // process transaction( )
responsibility by calling
create(Student,double) and 1.2.3. // close connection( )
submit(StudentBillingTransaction).

After creating the StudentBillingTransaction, the BillingSystem

proxy class instance submits the transaction to the class
instance that actually communicates with the Billing System.

30