1. Detail Design Subsystem Design Background and the Dynamic Part
OOADv4.2 Instructor Notes
Detail Design Subsystem Design Background and the Dynamic Part
Module 12 - Subsystem Design

2. Objectives: Subsystem Design
OOADv4.2 Instructor Notes
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
 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.
Module 12 - Subsystem Design

3. Subsystem Design in Context
OOADv4.2 Instructor Notes
Subsystem Design in Context
This is a tailored version
of the Analysis and Design
core workflow of the RUP.
(See RUP textbook for more)
We have defined classes,
subsystems, their interfaces,
and their dependencies.
Some things so far are
components or sub-systems
i.e., ‘containers’ of complex
behavior that we have
treated as a black box.
Now we need to flesh out
the internal interactions, i.e.,
what classes exist in the
subsystem to support, and
how do they collaborate to
support, the responsibilities
documented in the subsystem
interfaces.
This is what subsystem design is all about.
Subsystem Design is where you design the inside of the black box that was identified during Architectural Design.
Just like the saying “everything I’ve ever known I learned in kindergarten” says, everything you need to know in Subsystem Design, you learned in Use-Case Analysis and Use-Case Design -- identifying abstractions and allocating responsibilities to those abstractions, incorporating any necessary mechanisms.
You may want to note that Subsystem Design can be applied to packages, as well. In that case, you would concentrate on flushing out the details of the public class operations. As was mentioned earlier, in essence, the public classes are a package’s interface.
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
Module 12 - Subsystem Design

4. Subsystem Design in Context
OOADv4.2 Instructor Notes
Subsystem Design in Context
Subsystem Design is where you design the inside of the black box that was identified during Architectural Design.
Just like the saying “everything I’ve ever known I learned in kindergarten” says, everything you need to know in Subsystem Design, you learned in Use-Case Analysis and Use-Case Design -- identifying abstractions and allocating responsibilities to those abstractions, incorporating any necessary mechanisms.
You may want to note that Subsystem Design can be applied to packages, as well. In that case, you would concentrate on flushing out the details of the public class operations. As was mentioned earlier, in essence, the public classes are a package’s interface.
Here in subsystem design,
we look at 1) the responsibilities
of the subsystem in detail,
defining and refining the
classes that are needed to
implement those
responsibilities, while 2)
refining subsystem
dependencies as needed.
The internal interactions are
expressed as collaborations
of classes and possibly other
components or subsystems.
The focus is on the subsystem.
The activity is iterative and
recursive, but eventually
feeds Class Design.
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
Module 12 - Subsystem Design

5. Subsystem Design Overview**
OOADv4.2 Instructor Notes
Subsystem Design Overview**
Subsystem Design is performed once per Design Subsystem.
Purpose: to define the behaviors specified in the subsystem’s interface
in terms of collaborations of contained classes; to document the internal
structure of the subsystem, to define realizations between subsystem’s interfaces
and contained classes, and to determine the dependencies upon other subsystems.
In Subsystem Design, the concentration is on developing the “interface realizations”.
In RUP v5.5, Design Guidelines are not listed as input to the Subsystem Design activity. This will be fixed in a future release of RUP.
Design Subsystems and Interfaces
Design Subsystems and Interfaces
(updated)
Subsystem
Design
Use-Case Realization
(updated)
Use-Case Realization
Design Guidelines
Design Classes
Module 12 - Subsystem Design

6. Review: Subsystems and Interfaces
OOADv4.2 Instructor Notes
Review: Subsystems and Interfaces
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).
 Realizes one or more interfaces which define its behavior
Subsystems and interfaces were first introduced in the Introduction to Object Orientation module. They were identified and modeled in Architectural Design. The concepts are repeated here for review purposes.
In the UML, any classifier (e.g., class, subsystem, component) can have interface(s); however, to keep things simple, in this course we will concentrate on interfaces for subsystems.
Emphasize the following:
Canonical vs. elided notation
Multiple interfaces possible per subsystem
Interface can be realized by multiple subsystems
Interface is not a part of the subsystem, it is external
Remember that interfaces and abstract classes/generalization are not the same concept. An interface is a full-fledged citizen that may be “realized” (excuse the overloaded term) using abstract classes. Though the realization of an interface is not the same as inheriting from an abstract base class.
Rose does not fully support subsystems yet (you can’t include subsystems in interaction diagrams, and you can’t draw a realizes relationship from a subsystem to an interface). See the “Review: Modeling Convention for Subsystems and Interfaces” slide instructor notes for a description of a workaround.
The use of Rose in support of RUP is described in the tool mentors that are shipped with RUP.
<<subsystem>>
Subsystem Name
Interface
Subsystem
Realization (Canonical form)
Realization (Elided form)
<<interface>>
Module 12 - Subsystem Design

7. Review: Subsystems and Interfaces
OOADv4.2 Instructor Notes
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.
Subsystems and interfaces were first introduced in the Introduction to Object Orientation module. They were identified and modeled in Architectural Design. The concepts are repeated here for review purposes.
In the UML, any classifier (e.g., class, subsystem, component) can have interface(s); however, to keep things simple, in this course we will concentrate on interfaces for subsystems.
Emphasize the following:
Canonical vs. elided notation
Multiple interfaces possible per subsystem
Interface can be realized by multiple subsystems
Interface is not a part of the subsystem, it is external
Remember that interfaces and abstract classes/generalization are not the same concept. An interface is a full-fledged citizen that may be “realized” (excuse the overloaded term) using abstract classes. Though the realization of an interface is not the same as inheriting from an abstract base class.
Rose does not fully support subsystems yet (you can’t include subsystems in interaction diagrams, and you can’t draw a realizes relationship from a subsystem to an interface). See the “Review: Modeling Convention for Subsystems and Interfaces” slide instructor notes for a description of a workaround.
The use of Rose in support of RUP is described in the tool mentors that are shipped with RUP.
<<subsystem>>
Subsystem Name
Interface
Subsystem
Realization (Canonical form)
Realization (Elided form)
<<interface>>
Module 12 - Subsystem Design

8. Review: Subsystems and Interfaces
OOADv4.2 Instructor Notes
Review: Subsystems and Interfaces
Interfaces are not abstract classes, as abstract classes provide default behaviors.
Interfaces provide no default behavior.
Realization is a semantic relationship between two classifiers – one serves as contract (the interface class) ; other, carries it out (subsystem contents and its dependencies).
Subsystems and interfaces were first introduced in the Introduction to Object Orientation module. They were identified and modeled in Architectural Design. The concepts are repeated here for review purposes.
In the UML, any classifier (e.g., class, subsystem, component) can have interface(s); however, to keep things simple, in this course we will concentrate on interfaces for subsystems.
Emphasize the following:
Canonical vs. elided notation
Multiple interfaces possible per subsystem
Interface can be realized by multiple subsystems
Interface is not a part of the subsystem, it is external
Remember that interfaces and abstract classes/generalization are not the same concept. An interface is a full-fledged citizen that may be “realized” (excuse the overloaded term) using abstract classes. Though the realization of an interface is not the same as inheriting from an abstract base class.
Rose does not fully support subsystems yet (you can’t include subsystems in interaction diagrams, and you can’t draw a realizes relationship from a subsystem to an interface). See the “Review: Modeling Convention for Subsystems and Interfaces” slide instructor notes for a description of a workaround.
The use of Rose in support of RUP is described in the tool mentors that are shipped with RUP.
<<subsystem>>
Subsystem Name
Interface
Subsystem
Realization (Canonical form)
Realization (Elided form)
<<interface>>
Module 12 - Subsystem Design

9. OOADv4.2 Instructor Notes
Key is abstraction and encapsulation
Subsystem Guidelines A
<<subsystem>> B C
Goals
Loose coupling; as independent as possible
Portability, plug-and-play compatibility
Evolve different parts of system
independently from other parts.
Insulation from change - minimized
Replaceable elements in the model.
Strong Suggestions for Subsystems:
Don’t expose details, only interfaces
No element contained by a subsystem should
have public visibility.
No element outside the subsystem should depend
on a particular element inside the subsystem.
Only depend on interfaces of other model
elements so that it is not directly dependent on
any specific model element outside the subsystem.
Discuss some of the benefits of doing this well: portability, reuse, insulation from change, etc.
There should not be any public classes within a subsystem; the only thing a subsystem should expose to the outside world is its interfaces.
These guidelines will be applied throughout this module as we describe how to perform the detailed design of a subsystem. This slide is meant to provide the student with an “overall vision” for the subsystem design.
Module 12 - Subsystem Design

10. OOADv4.2 Instructor Notes
Key is abstraction and encapsulation
Subsystem Guidelines A
<<subsystem>> B C
Exception: sharing of some class definitions
in common, should only be done with packages
in lower layers to ensure common definition
of classes which must pass between subsystems
All dependencies on a subsystem should be
dependencies on the subsystem interfaces.
 Clients of a subsystem are dependent on the
subsystem interface(s), not on elements within
the subsystem.
In this way, the subsystem can be replaced by any other subsystem that realizes the same
interfaces.
Discuss some of the benefits of doing this well: portability, reuse, insulation from change, etc.
There should not be any public classes within a subsystem; the only thing a subsystem should expose to the outside world is its interfaces.
These guidelines will be applied throughout this module as we describe how to perform the detailed design of a subsystem. This slide is meant to provide the student with an “overall vision” for the subsystem design.
Module 12 - Subsystem Design

11. Modeling Convention for Subsystems and Interfaces**
OOADv4.2 Instructor Notes
Modeling Convention for Subsystems and Interfaces**
Represent subsystems as three items in model:
<<subsystem>> package; <<subsystem proxy>> class,
& subsystem interface (class with
stereotype <<interface>>).
The interface names should start with an “I.”
The subsystem package provides a container for the
elements that comprise the subsystem.
The interaction diagrams describe how the
subsystem elements collaborate to
implement the operations of the
interface the subsystem realizes, and
other diagrams that clarify the sub
system elements.
This modeling convention was presented in Architectural Design. It is repeated here for review purposes.
There may be some concern over the use of “proxy”. However, using <<subsystem proxy>> should remove any ambiguous confusion with the "proxy" design pattern (although it is, in a loose way, an instance of the design pattern, at least at design time).
This convention is useful when using Rose since Rose does not fully support subsystems yet (you can’t include subsystems in interaction diagrams, and you can’t draw a realizes relationship from a subsystem to an interface). The subsystem proxy class may act in place of the subsystem in sequence diagrams, collaboration diagrams and class diagrams in which a subsystem cannot (today) appear in Rose. Use a subsystem proxy when you want to indicate usage of a specific subsystem. The subsystem proxy realizes the interfaces realized by the subsystem.
Some students may complain that we use this convention because Rose does not directly support subsystems. While this may be true, it is not the only reason we use this convention. See the “OOAD and Rose Gaps” section of the OOAD IBP for more information on positioning the lack of subsystem support (and other concepts) in Rose.
<<subsystem>>
CourseCatalogSystem
ICourseCatalogSystem
<<subsystem>> package
<<subsystem proxy>> class
CourseCatalogSystem
<<subsystem>>
NB: <<subsystem proxy>>
class actually realizes the
interface and will orchestrate
the implementation of the
subsystem operations.
ICourseCatalogSystem
CourseCatalogSystem
<<subsystem proxy>>
Module 12 - Subsystem Design

12. Subsystem Design Major Steps
OOADv4.2 Instructor Notes
Subsystem Design Major Steps
The process is similar to that defined in Use-Case Analysis, but instead of use cases we are working with interface operations. In Subsystem Design, we concentrate on developing “interface realizations” rather than “use-case realizations”.
Ask the students where the subsystem responsibilities are documented. Answer: In the interfaces that the subsystem realizes.
Distribute Subsystem behavior to Subsystem Elements
Next, Document those Subsystem Elements (e.g. classes…)
Then the internal structure of the subsystems (that is, subsystem element relationships) needs to be documented.
Once we know how the subsystem will implement it’s responsibilities, we need to document the interfaces upon which the subsystem is dependent.
Then, review the results of your subsystem design.
Module 12 - Subsystem Design

13. Subsystem Design Steps
OOADv4.2 Instructor Notes
Subsystem Design Steps
In Subsystem Design, you define subsystem elements to implement subsystem responsibilities.
Note: The design mechanisms were mapped to the design elements in the Architectural Design module..
Distribute Subsystem behavior to Subsystem Elements
So, we must first take the responsibilities allocated to the subsystems and further allocate those responsibilities to the subsystem elements.
We must specify the internal behaviors
Identify new classes / subsystems that may be needed to satisfy behavioral requirements.
To this point, we have created interaction diagrams in terms of design elements (design classes and/or subsystem interfaces.
 Now we will describe the ‘local’ interactions within a subsystem to clarify internal design.
Document Subsystem Elements
Describe Subsystem Dependencies
Module 12 - Subsystem Design

14. Subsystem Responsibilities**
OOADv4.2 Instructor Notes
Subsystem Responsibilities**
Subsystem responsibilities defined by the interface it realizes
 When a subsystem realizes an interface, it makes a commitment to support each and 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.
In Rose, interface realizations can be documented using a variant of the use-case realization idea. Essentially, a <<interface realization>> stereotyped use case is created inside the <<subsystem>> package with the same name as the interface it models. Thus, there is one <<interface realization>> use case (e.g., UML collaboration) for each interface the subsystem realizes. The interface realization contains the static and dynamic models that describe how the subsystem realizes the interfaces (e.g., a class diagram and interaction diagrams – at least one interaction diagram per interface operation). As with use-case realizations, the interface realization does not contain any classes (they “live” in the <<subsystem>> package or in other design element packages).
This fits well with the large-scale ‘systems-of-systems’ development idea where you would have subsystem use cases and their corresponding realizations, and also keeps the diagrams neat.
This convention is not part of the tool mentors yet, bit it was used in the sample models provided with the OOADcourse materials.
CourseCatalogSystem
<<subsystem>>
ICourseCatalogSystem
getCourseOfferings()
<<interface>>
subsystem responsibility
Module 12 - Subsystem Design

15. Distributing Subsystem Responsibilities (1 of 2)
OOADv4.2 Instructor Notes
Distributing Subsystem Responsibilities (1 of 2)
For each interface operation, identify new, or reuse existing, design elements (e.g., classes and/or contained subsystems, if required behavior is complex)
Create new classes/subsystems where existing classes/subsystems cannot provide the required behavior
Try to reuse first.
Be careful and avoid having effectively the same classes in two different subsystems.
Incorporate applicable mechanisms (e.g., persistence, distribution, etc.)
You may find additional classes and/or subsystems during this activity. If so, the added classes and relationships must be consistent with the established architecture.
Sometimes you see repeated patterns of interaction in these early interface realizations that give birth to new subsystems and some revisions in the interface 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.
It is important to describe the collaborations to support the design and implementation mechanisms defined in Architectural Design.
Module 12 - Subsystem Design

16. Distributing Subsystem Responsibility** (2 of 2)
OOADv4.2 Instructor Notes
Distributing Subsystem Responsibility** (2 of 2)
 Document design element collaborations in “interface realizations” to show how the behaviors are realized via interaction diagrams.
One or more interaction diagrams per interface operation
These ‘internal’ interaction diagrams show exactly what classes provide the interface, what needs to happen internally to provide the subsystem’s functionality, and which classes send messages out from the subsystem.
These diagrams are ‘owned’ by the subsystem and can be used to design the internal behavior of the subsystem.
Essential for subsystems w/ complex internal designs
Enables behavior to be understood; hopefully rendering it reusable across contexts.
You may find additional classes and/or subsystems during this activity. If so, the added classes and relationships must be consistent with the established architecture.
Sometimes you see repeated patterns of interaction in these early interface realizations that give birth to new subsystems and some revisions in the interface 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.
It is important to describe the collaborations to support the design and implementation mechanisms defined in Architectural Design.
Module 12 - Subsystem Design

17. Modeling Convention: Subsystem Interaction Diagrams
OOADv4.2 Instructor Notes
Modeling Convention: Subsystem Interaction Diagrams
Subsystem Client
Subsystem Proxy
Design Element 1
Design Element 2
Note: In RUP, the recommendation is to start the interaction diagram with the <<subsystem proxy>> class. We have chosen to enhance that recommendation and include the subsystem client on the diagram for clarity reasons (it makes it obvious what interface operation is being modeled).
The subsystem client speaks directly with the <<subsystem proxy>> class, as opposed to the subsystem interface, as the interaction diagram is meant to show the subsystem implementation, and in the implementation, there is no interface (it has been “compiled away”).
performResponsibility( )
Op1()
subsystem responsibility
Op2()
Internal subsystem interactions
Op3()
Op4()
Subsystem interface not shown
As mentioned, there should be at least one interaction diagram per interface operation
to illustrate how the operations offered by the interfaces of the subsystem are performed
by model elements contained in the subsystem.
Module 12 - Subsystem Design

18. Modeling Convention: Subsystem Interaction Diagrams**
OOADv4.2 Instructor Notes
Modeling Convention: Subsystem Interaction Diagrams**
Subsystem Client
Subsystem Proxy
Design Element 1
Design Element 2
The interface does
not appear on the
INTERNAL
subsystem interaction
diagram.
Note: In RUP, the recommendation is to start the interaction diagram with the <<subsystem proxy>> class. We have chosen to enhance that recommendation and include the subsystem client on the diagram for clarity reasons (it makes it obvious what interface operation is being modeled).
The subsystem client speaks directly with the <<subsystem proxy>> class, as opposed to the subsystem interface, as the interaction diagram is meant to show the subsystem implementation, and in the implementation, there is no interface (it has been “compiled away”).
performResponsibility( )
Op1()
subsystem responsibility
Op2()
Internal subsystem interactions
Op3()
Op4()
A message should be drawn from the <<subsystem>> client to the <<subsystem proxy>>
class defined for the subsystem. The message should then be mapped to/associated with the
interface operation that is being modeled in the 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 the
interface operations.
Module 12 - Subsystem Design

19. Example: CourseCatalogSystem Subsystem In Context
OOADv4.2 Instructor Notes
Example: CourseCatalogSystem Subsystem In Context
subsystem interface
This is the same diagram that appeared in the Use-Case Design module.
Emphasize that we will be incorporating legacy RDBMS persistency, specifically, retrieving the course offerings for a particular semester from the legacy Course Catalog System.
On the presented slide, the subsystem interface is shown in yellow, but this does not show up in the back-and-white manuals.
The requirements documents for the Course Registration System do not really include any specific requirements for the Course Catalog System, beyond the fact that it is a read-only legacy system with an RDBMS database. Thus, for the rest of the Subsystem Design module, we will concentrate on the application of the RDBMS persistency mechanism, and not on any of the other subsystem design details.
: RegisterFor CoursesForm
: Registration Controller
: ICourseCatalog System
: Schedule
: Student
: Student
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
Legacy RDBMS Database Access
semester are displayed
This sequence diagram sets the context
of what will be performed in Subsystem
Design. - Puts requirements on the
subsystem, and is the primary input
specification to the task of creating
local interactions for the subsystem.
A blank schedule
5: // display blank schedule( )
is displayed for the
students to select
offerings
6: // select 4 primary and 2 alternate offerings( )
7: // create schedule with offerings( )
8: // create with offerings( )
9: // add schedule(Schedule)
At this, point the Submit Schedule subflow is executed.
Module 12 - Subsystem Design

20. Example: CourseCatalogSystem Subsystem In Context
OOADv4.2 Instructor Notes
Example: CourseCatalogSystem Subsystem In Context
subsystem interface
This is the same diagram that appeared in the Use-Case Design module.
Emphasize that we will be incorporating legacy RDBMS persistency, specifically, retrieving the course offerings for a particular semester from the legacy Course Catalog System.
On the presented slide, the subsystem interface is shown in yellow, but this does not show up in the back-and-white manuals.
The requirements documents for the Course Registration System do not really include any specific requirements for the Course Catalog System, beyond the fact that it is a read-only legacy system with an RDBMS database. Thus, for the rest of the Subsystem Design module, we will concentrate on the application of the RDBMS persistency mechanism, and not on any of the other subsystem design details.
: RegisterFor CoursesForm
: Registration Controller
: ICourseCatalog System
: Schedule
: Student
: Student
1: // create schedule( )
2: // get course offerings( )
Student wishes to
create a new
3: getCourseOfferings(Semester)
schedule
4: // display course offerings( )
subsystem responsibility Legacy RDBMS Database Access
A list of the available
course offerings for this
semester are displayed
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.
A blank schedule
5: // display blank schedule( )
is displayed for the
students to select
offerings
6: // select 4 primary and 2 alternate offerings( )
7: // create schedule with offerings( )
8: // create with offerings( )
9: // add schedule(Schedule)
At this, point the Submit Schedule subflow is executed.
Module 12 - Subsystem Design

21. Incorporating the Architectural Mechanisms: Persistency
OOADv4.2 Instructor Notes
Incorporating the Architectural Mechanisms: Persistency
If you do not want to cover all of the persistency interaction diagrams, you can use the rationale that the key scenarios we are focussing on for this iteration do not require all database CRUD behaviors.
If you are teaching to an introductory audience, or If you skipped the introduction of the RDBMS mechanism in the Architectural Design module, then you should skip these next few slides on incorporating the RDBMS persistency mechanism.
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
OODBMS Persistency
Schedule
Persistency, Security
CourseOffering
Persistency, Legacy Interface
RDBMS Persistency
Course
Persistency, Legacy Interface
RegistrationController
Distribution
Given all this, let’s see how the subsystem accommodates its responsibilities.
Since we have been concentrating on course registration, the table only contains classes for the
Register for Courses UC Realization that have analysis mechanisms assigned to them.
We will now incorporate the legacy RDBMS persistency mechanism since access to the legacy
system has been encapsulated within a sub system. The legacy interface mechanism
distinguished the type of persistency. Remember, legacy data is stored in a RDBMS.
Module 12 - Subsystem Design

22. Review: Incorporating JDBC: Steps of Steps
OOADv4.2 Instructor Notes
Review: Incorporating JDBC: Steps of Steps
(Done:) Provide access to the class libraries needed to implement JDBC; (i.e., Provide java.sql package)
Create the necessary DBClasses and their dependencies on java.sql package; develop detailed interactions.
Recall: the java.sql package contains the design elements that support the RDBMS persistency mechanism.
 The java.sql package will be depended on by the CourseCatalogSystem subsystem as that is where the created DBCourseOffering class will be placed (ahead)
Thus a dependency will be added from CourseCatalogSystem to java.sql.
Recall also: One DBClass per persistent class, and the Course Offering persistent class  DBCourseOffering.
The italicized text reflects the RDBMS incorporation design decisions made for the current design.
Note: On the presented slide, the italicized text is also yellow, but this does not show up in the back-and-white manuals.
The check mark indicates what steps have already been completed (in Architectural Design).
(continued)
Module 12 - Subsystem Design

23. Review: Incorporating JDBC:Steps (contd)**
OOADv4.2 Instructor Notes
Review: Incorporating JDBC:Steps (contd)**
Once created, must incorporate DBClasses into the design.
Allocate to a package/layer. (probably domain; maybe app) e.g, The DBCourseOffering class will be placed in the
CourseCatalogSystem subsystem.
 Once DBClasses have been allocated to packages/layers, the relationships to the DBClasses from all classes requiring
persistence support (that is, the persistency clients) needs to
be added. (Persistency clients are the CourseCatalogSystem
subsystem clients)
These dependencies have already been established.
The interaction diagrams provide a means to verify that all
required database functionality is supported by the design
elements.
The italicized text reflects the RDBMS incorporation design decisions made for the current design.
Note: On the presented slide, the italicized text is also yellow, but this does not show up in the back-and-white manuals.
Module 12 - Subsystem Design

24. Review: Incorporating JDBC: Steps (contd.)**
Note: the persistency client sends a message to the subsystem proxy class to get course offerings with argument (Semester)
The proxy class (representing the subsystem) first contacts the DBClass for objects of the persistency class.
These DBClasses may be in a single package or elsewhere. But they are ‘depended upon’ by the subsystem (proxy class).
As we are aware, the DBClass (and perhaps a DBClass package in the domain layer???) will then have a dependency on the java.sql likely in the middleware layer)
Note: that in this sequence diagram, the objects we saw in the class diagram (static view – VOPC) when we were studying Persistency - are playing a clear cut role, and the ‘timing’ of the interactions is quite specific.
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.
So, we are seeing HOW the Course Catalog Subsystem via the proxy class is handling its responsibilities (and associated dependencies!)

25. Ex: Local CourseCatalogSystem Subsystem Interaction
OOADv4.2 Instructor Notes
Retrieve all available course
offerings for the current
semester
CourseCatalog
System Client :
CourseCatalogSystem
DBCourseOffering
CourseOffering
CourseOfferingList
: ResultSet
: Course Catalog
: Statement
: Connection
1. getCourseOfferings(Semester)
1.1. read(string)
createStatement( )
executeQuery(String)
sql statement is passed in
specifying the search criteria --
course offerings in the current
new( )
Repeat these operations for each
element returned from the
executeQuery() command.
The CourseOfferingList is loaded
with the data retrieved from the
database.
The getData and setData
operations are called for each
attribute in the each retrieved
class instance.
3. setData( )
Create a list to hold all
retrieved course offerings
Add the retrieved course offering
to the list to be returned
2. getString( )
new( )
4. add(CourseOffering)
// executeQuery( )
(Which subsystems/layer do you think these objects are in?)
Internals of subsystems should yield interaction diagrams
that look like this.
We see collaborations to implement the getCourseOfferings
operation of the ICourseCatalogSystem interface.
Recall: legacy system stores course offerings in an RDBMS.
Here we show how the RDBMS persistency mechanism
identified in Architectural Design is realized in the design.
Point out the use of the subsystem interaction diagram modeling conventions (described on the “Review: Modeling Convention for Subsystems and Interfaces” slide): the use of the subsystem client and the subsystem proxy instances.
Also describe to the students how the RDBMS persistency mechanism has been applied: the use of the DBCourseOffering, Connection, Statement, and ResultSet instances.
Subsystem Proxy
RDBMS Read
Module 12 - Subsystem Design

26. Ex: Local CourseCatalogSystem Subsystem Interaction
OOADv4.2 Instructor Notes
Ex: Local CourseCatalogSystem Subsystem Interaction
Client object initiating the interaction is abstracted here…
For design of the subsystem, we don’t care who the client
really is.
CourseCatalogSystem subsystem proxy class actually
realizes the ICourseCatalogSystem interface. It is the
class that delegates the implementation of the interface to
subsystem elements or to other dependent elements.
Point out the use of the subsystem interaction diagram modeling conventions (described on the “Review: Modeling Convention for Subsystems and Interfaces” slide): the use of the subsystem client and the subsystem proxy instances.
Also describe to the students how the RDBMS persistency mechanism has been applied: the use of the DBCourseOffering, Connection, Statement, and ResultSet instances.
Module 12 - Subsystem Design

27. Ex: Local CourseCatalogSystem Subsystem Interaction
OOADv4.2 Instructor Notes
Retrieve all available course
offerings for the current
semester
CourseCatalog
System Client :
CourseCatalogSystem
DBCourseOffering
CourseOffering
CourseOfferingList
: ResultSet
: Course Catalog
: Statement
: Connection
1. getCourseOfferings(Semester)
1.1. read(string)
createStatement( )
executeQuery(String)
sql statement is passed in
specifying the search criteria --
course offerings in the current
new( )
Repeat these operations for each
element returned from the
executeQuery() command.
The CourseOfferingList is loaded
with the data retrieved from the
database.
The getData and setData
operations are called for each
attribute in the each retrieved
class instance.
3. setData( )
Create a list to hold all
retrieved course offerings
Add the retrieved course offering
to the list to be returned
2. getString( )
new( )
4. add(CourseOffering)
// executeQuery( )
To read the course offerings, the persistency client, the
proxy class, asks the DBCourseOffering class to retrieve a
course offerings for the specified semester.
DBCourseOffering creates a new statement using Connection
class’s createStatement() operation.
The statement is executed; data is returned to ResultSet object.
DBCourseOffering then creates a list of CourseOffering
instances, CourseOfferingList, populates it with retrieved
data, and returns it to the client.
Point out the use of the subsystem interaction diagram modeling conventions (described on the “Review: Modeling Convention for Subsystems and Interfaces” slide): the use of the subsystem client and the subsystem proxy instances.
Also describe to the students how the RDBMS persistency mechanism has been applied: the use of the DBCourseOffering, Connection, Statement, and ResultSet instances.
Subsystem Proxy
RDBMS Read
Module 12 - Subsystem Design

28. Example: Billing System Subsystem In Context
OOADv4.2 Instructor Notes
Example: Billing System Subsystem In Context
subsystem interface : : : :
: Schedule
: Student. :
: Registrar
Note: On the presented slide, the subsystem interface is shown in yellow, but this does not show up in the back-and-white manuals.
The requirements do not include any specific requirements for the Billing System. Thus, for the purposes of the Subsystem Design module, we will concentrate on the basics of building a transaction to the Billing System and communicating with the Billing System via a specific boundary class.
CloseRegistrationForm
CloseRegistrationController
ICourseCatalogSystem
CourseOffering
IBillingSystem
Here, will demonstrate design of a subsystem that does not
require the incorporation of an architectural mechanism.
This is a portion of the Close Registration use-case
realization sequence diagram.
The internals of the Billing System subsystem
have not been designed yet. That is the
purpose of this activity, Subsystem Design
1. // close registration( )
1.1. // is registration open?( )
Retrieve a list of course
offerings for the current
semester
2. // close registration( )
Close
2.1. getCourseOfferings(Semester)
registration for
each course
Repeat twice this is
offering
If the maximum number of
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( )
cancel the course
Currently assuming tuition based on
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
Now, we are really after the next slide…
Module 12 - Subsystem Design

29. Example: Billing System Subsystem In Context
OOADv4.2 Instructor Notes
Example: Billing System Subsystem In Context
subsystem interface : : : :
: Schedule
: Student. :
: Registrar
Note: On the presented slide, the subsystem interface is shown in yellow, but this does not show up in the back-and-white manuals.
The requirements do not include any specific requirements for the Billing System. Thus, for the purposes of the Subsystem Design module, we will concentrate on the basics of building a transaction to the Billing System and communicating with the Billing System via a specific boundary class.
CloseRegistrationForm
CloseRegistrationController
ICourseCatalogSystem
CourseOffering
IBillingSystem
Here we put requirements on the subsystem, and the
sequence diagram is the primary input spec to creating
local interactions for the subsystem.
We see the operations subsystem must support. Shows
the simple way some client (CloseRegistrationController
here) deals with the task of submitting bill to
the legacy Billing System.
1. // close registration( )
1.1. // is registration open?( )
Retrieve a list of course
offerings for the current
semester
2. // close registration( )
Close
2.1. getCourseOfferings(Semester)
registration for
each course
Repeat twice this is
offering
If the maximum number of
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( )
cancel the course
Currently assuming tuition based on
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
More coming…
Module 12 - Subsystem Design

30. OOADv4.2 Instructor Notes
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 this is done…
Note: On the presented slide, the subsystem interface is shown in yellow, but this does not show up in the back-and-white manuals.
The requirements do not include any specific requirements for the Billing System. Thus, for the purposes of the Subsystem Design module, we will concentrate on the basics of building a transaction to the Billing System and communicating with the Billing System via a specific boundary class.
Module 12 - Subsystem Design

31. Example: Local BillingSystem Subsystem Interaction
OOADv4.2 Instructor Notes
Example: Local BillingSystem Subsystem Interaction
Subsystem Proxy
Billing System : :
: Student. :
: Billing System
Client
BillingSystem
StudentBillingTransaction
BillingSystemInterface
Designing the internals of a subsystem
should yield (local) interaction diagrams
like this sequence diagram.
This example looks inside and shows
collaborations required to implement
the submitBill() operation of the
IBillingSystem interface.
1. submitBill(Student, double)
Retrieve the
information that must
1.1. create(Student, double)
be included on the bill
// get contact info( )
1.2. submit(StudentBillingTransaction)
// open connection( )
Logic here must convert the
contract info into a format
(StudentBillingTransaction)
that the Billingsystem can
understand.
Given this, the proxy will
orchestrate opening,
processing, and closing
the connection (and submitting
the bill).
// process transaction( )
// close connection( )
Module 12 - Subsystem Design

32. Example: Local BillingSystem Subsystem Interaction
OOADv4.2 Instructor Notes
Example: Local BillingSystem Subsystem Interaction
Subsystem Proxy
Billing System : :
: Student. :
: Billing System
Client
BillingSystem
StudentBillingTransaction
BillingSystemInterface
The client object initiating the interaction
is abstracted. Again, we don’t care…
The BillingSystem subsystem proxy
class actually realizes the
IBillingSystem interface.
It is the class that delegates the
implementation of the interface to the
subsystem elements.
1. submitBill(Student, double)
Retrieve the
information that must
1.1. create(Student, double)
be included on the bill
// get contact info( )
1.2. submit(StudentBillingTransaction)
// open connection( )
// process transaction( )
// close connection( )
Module 12 - Subsystem Design

33. Example: Local BillingSystem Subsystem Interaction
OOADv4.2 Instructor Notes
Example: Local BillingSystem Subsystem Interaction
Subsystem Proxy
Billing System : :
: Student. :
: Billing System
Client
BillingSystem
StudentBillingTransaction
BillingSystemInterface
The BillingSystem proxy class instance
creates a StudentBillingTransaction
specific to the external Billing System.
This transaction will be in a format that
the Billing System can process.
The StudentBillingTransaction knows
how to create itself using information
from the given Student.
1. submitBill(Student, double)
Retrieve the
information that must
1.1. create(Student, double)
be included on the bill
// get contact info( )
1.2. submit(StudentBillingTransaction)
Note that only a single message is
sent to the proxy: submitBill(…)
The proxy, then, implements this
responsibility by calling
create(Student,double) and
submit(StudentBillingTransaction).
// open connection( )
// process transaction( )
// close connection( )
After creating the StudentBillingTransaction, the BillingSystem
proxy class instance submits the transaction to the class
instance that actually communicates with the Billing System.
Module 12 - Subsystem Design