Detail Design

Subsystem Design
Static Part - VOPC

1
 Subsystem Design Steps - continuing

Document Subsystem Elements

We have responsibilities allocated to subsystems

and now responsibilities are allocated to the
subsystem elements.
 We have collaborations between subsystem elements
modeled via interaction diagrams.
 So, what’s left to do:
 Model the realization of subsystem interfaces.
 This can be accommodated by design
elements both within and outside the subsystem itself.
 First,let’s look inside subsystem to collaborations
wholly contained within that realization that realize the
interface.
2
 Procedure:
Document Internal SubSystem Structure
Create Class Diagram(s) showing contained
elements and their associations.
 Create State diagram?
 May be appropriate to show different states
subsystem can assume. (interfaces and subsystems
are “stateful”).
 Document any order dependencies
 (i.e., op1 must be executed before op2, etc.).

3
 Inside subsystem; classes only
Explain the ‘dependencies…’
Ex: CourseCatalogSystem SubSystem Elements (1of 2)
Note:
<<Interface>> <<subsystem proxy>>
ICourseCatalogSystem CourseCatalogSystem
(from External System Interfaces)

getCourseOfferings(forSemester : Semester) : CourseOfferingList

getCourseOfferings(forSemester : Semester) : CourseOfferingList

Subsystem Interface Subsystem Proxy

Concentrating on the interface DBCourseOfferring

getCourseOfferings()… create() : CourseOffering

CourseOfferingList
(from University read(searchCriteria : string) : CourseOfferingList
•CourseCatalogSystem works Artifacts)
1
with DBCourseOffering to new()

read/write persistent data from

add() Note where these objects reside!!
CourseCatalogSystem (RDBMS). 1

0..* 1
•DBCourseOffering is responsible <<entity>> Connection
(from java.sql)
for accessing the JDBC CourseOffering
Statement
(from University
database using the previously- Artifacts) createStatement() (from java.sql)
established Connection new()
executeQuery() ResultSet
(recall java.sql) setData()
executeUpdate() (from java.sql)

(Recall: Once database connection is opened (DriverManager), DBCourseOffering can then create getString()
SQL statements that will be sent to underlying RDBMS and executed using the Statement class.
(Results of SQL query returned in ResultSet class object.) 4
 Inside subsystem; classes only
Ex: CourseCatSystem Sub System Elements (2of 2)

<<Interface>> <<subsystem proxy>>

ICourseCatalogSystem CourseCatalogSystem
(from External System Interfaces)

getCourseOfferings(forSemester : Semester) : CourseOfferingList

getCourseOfferings(forSemester : Semester) : CourseOfferingList

Subsystem Proxy
Subsystem Interface DBCourseOfferring

CourseOfferingList create() : CourseOffering

(from University read(searchCriteria : string) : CourseOfferingList
Artifacts)
1
Note: elements outside of the new()
add()
subsystem are shown, as well,
to provide context. 1

0..* 1
These elements – identified by <<entity>>
Connection
(from java.sql)
their owning package are CourseOffering
(from University Statement
listed in parentheses below Artifacts) createStatement() (from java.sql)
in the class header new()
(e.g University Artifacts) setData() executeQuery() ResultSet
executeUpdate() (from java.sql)
Especially note the modeling of the interface and proxy (as well as persistency)
DBCourseOffering can be in Applications Layer (perhaps in CourseCatalogSystem);could getString()
conceivably be in a Domain Layer, where other applications needing access to these objects can
5
reuse the DBConnections, …. Notice also the presence of java.sql.(Probably in Middleware Layer)
 Document External Subsystem Structure…
Now, must document the elements (elements
external to subsystem) upon which SS depends.
Important:subsystems likely do not stand alone;
they may need services of other SubSystems.
 SS designer should feel free to use services of other model
elements.

6
Describing SubSystem Dependencies - on Subsystems
Subsystem Dependencies on a SubSystem

<<subsystem>> <<subsystem>>
Client Support Server Support Flexible
Server
• When a subsystem uses some behavior of an element contained by another
subsystem or package, a dependency on the external element is needed.

• If the element on which subsystem depends is within a different

subsystem, the dependency should be on that SubSystem interface, not on
the element within the SubSystem, since we are denied entry to the subsystem.

• We know the advantages of such a design…

• It also gives the designer total freedom in designing the internal behavior of
the subsystem, as long as it provides the correct external behavior.
• If a model element were to be able to directly reference a model element
inside of another subsystem, the designer is no longer free to remove that
model element or redistribute the behavior of that model element to other
elements. Result is referred to as a brittle architecture! 7
Describing SubSystem Dependencies - on Package
Subsystem Dependencies on a Package
<<subsystem>> Supporting
Client Support Types
Use with care

• If the element the subsystem element is dependent on is within a package,

the dependency should be on the package itself. (e.g. University Artifacts…)
We do not point to an interface (because there isn’t one).
• Ideally, a SubSystem should only depend on the interfaces of other model element
for the reasons stated before.

•(Exception: sometimes subsystems share a set of common class definitions, such

• as java.sql, in which case those subsystems 'import' the contents of the packages
•containing the common classes.
• This should only be done with packages in lower layers in the architecture to
ensure that common class definitions are defined consistently. (java.sql)
• Disadvantage: SS cannot be reused independent of the depended-on package.
8 )
Ex: CourseCatalogSystem Subsystem Dependencies
I’ve been calling
• This models the dependencies that the Course the Business Services
CatalogSubSystem has with other design elements <<subsystem>> layer our Domain
CourseCatalogSystem
• These dependencies support the relationships (from Business Services) Layer…
Course Catalog System…
modeled on earlier subsystem class diagrams. Billing System …

• These dependencies are on standard packages External System

Interfaces
that do not have a specific interface. (from Business Services)
• Thus the CourseCatalogSystem subsystem cannot
be reused without the packages it depends upon. Packages…

• The CourseCatalogSystem is dependent on the: University Artifacts

(from Business Services)
. 1. java.sql package in order to gain access to the
design elements (objects) that implement Student; Course Offering…
java.sql
the RDBMS persistency mechanism. (from Middleware) Note: these are dependencies
on packages – not subsystems.
. 2. External System Interfaces in order to gain access to the SubSystem itself
(ICourseCatalogSystem)

. 3. University Artifacts package in order to gain access to the core objects of the
Course Registration System.
9
 Subsystem Design Steps
Distribute
Subsystem behavior to
Subsystem Elements
Document Subsystem Elements
Describe Subsystem Dependencies
Checkpoints
 Itis now time to look for things when reviewing
the results of your Subsystem Design efforts.

11
Checkpoints: Design Subsystems – Be Careful!!
 Is a realization association defined for each interface
offered by the subsystem?
 Is a dependency association defined for each interface
used by the subsystem?
 Ensure that none of the elements within the subsystem
have public visibility. Why??
 Is each operation on an interface realized by the subsystem
documented in a interaction diagram?
 If not, is operation realized by a single class, so that it is easy to see
there is a simple 1:1 mapping between the class operation and the
interface operation?

12
Review: Subsystem Design – Good exam questions.

What is the purpose of Subsystem Design?

Why should dependencies on a subsystem
be on the subsystem interface?
Explain how dependencies are modeled on
packages and on subsystems.

13