Transcript SubSystem Design Part 2

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 internal structure of subsystem elements and
their relationships
Relationships are driven by what is required to support
the collaborations to implement the subsystem interfaces
First, let’s look inside subsystem to collaborations
wholly contained within that realization.
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
Ex: CourseCatalogSystem SubSystem Elements
subsystem; classes only
(1of 2)Note: Inside
Explain the ‘dependencies…’
<<Interface>>
ICourseCatalogSystem
<<subsystem proxy>>
CourseCatalogSystem
(from External System Interfaces)
getCourseOfferings(forSemester : Semester) : CourseOfferingList
getCourseOfferings(forSemester : Semester) : CourseOfferingList
Subsystem Interface
Concentrating on the interface
getCourseOfferings()…
Subsystem Proxy
DBCourseOfferring
CourseOfferingList
(from University Artifacts)
•CourseCatalogSystem works
new()
with DBCourseOffering to
add()
read/write persistent data from
CourseCatalogSystem (RDBMS).
create() : CourseOffering
read(searchCriteria : string) : CourseOfferingList
1
Note where these objects reside!!
1
1
0..*
•DBCourseOffering is responsible <<entity>>
CourseOffering
for accessing the JDBC
(from University Artifacts)
database using the previouslyestablished Connection
new()
setData()
(recall java.sql)
Connection
(from java.sql)
Statement
createStatement()
(from java.sql)
executeQuery()
executeUpdate()
(Recall: Once database connection is opened (DriverManager), DBCourseOffering can then create
SQL statements that will be sent to underlying RDBMS and executed using the Statement class.
(Results of SQL query returned in ResultSet class object.)
ResultSet
(from java.sql)
getString()
4
Ex: CourseCatSystem Sub System Elements
(2of 2)
Inside subsystem; classes only
<<Interface>>
ICourseCatalogSystem
<<subsystem proxy>>
CourseCatalogSystem
(from External System Interfaces)
getCourseOfferings(forSemester : Semester) : CourseOfferingList
getCourseOfferings(forSemester : Semester) : CourseOfferingList
Subsystem Proxy
Subsystem Interface
DBCourseOfferring
CourseOfferingList
(from University Artifacts)
Note: elements outside of the new()
subsystem are shown, as well, add()
to provide context.
These elements – identified by
their owning package are
listed in parentheses below
in the class header
(e.g University Artifacts)
create() : CourseOffering
read(searchCriteria : string) : CourseOfferingList
1
1
1
0..*
<<entity>>
CourseOffering
Connection
(from java.sql)
Statement
(from University Artifacts)
createStatement()
new()
setData()
(from java.sql)
executeQuery()
executeUpdate()
ResultSet
(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 5can
reuse the DBConnections, …. Notice also the presence of java.sql.(Probably in Middleware Layer)
Document External Structure…



Distribute Subsystem behavior to SubsystemElements
Document Subsystem Elements
Describe Subsystem Dependencies


Subsystem elements have been defined to implement the
subsystem responsibilities, and resulting collaborations between
elements have been modeled using interaction diagrams, and the
internal structure of the subsystem (a.k.a. relationships between
subsystem elements) has been modeled using class diagrams.
 Now, must document the elements (elements
external to subsystem) upon which SS depends.


These dependences may have been introduced when
designing the internals of the SS – as described earlier.
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 - Subsystems

Subsystem Dependencies on a SubSystem
<<subsystem>>
Client Support
<<subsystem>>
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
7
Describing SubSystem Dependencies - Package

Subsystem Dependencies on a Package
<<subsystem>>
Client Support
Supporting
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 elements
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)
8
• Disadvantage: SS cannot be reused independent of the depended-on package. )
Ex: CourseCatalogSystem Subsystem Dependencies
•
I’ve been calling
This models the dependencies that the Course
the Business Services
<<subsystem>>
layer our Domain
CatalogSubSystem has with other design elements CourseCatalogSystem
Layer…
(from Business Services)
• These dependencies support the relationships
modeled on earlier subsystem class diagrams.
• These dependencies are on standard packages
that do not have a specific interface.
• Thus the CourseCatalogSystem subsystem cannot
be reused without the packages it depends upon.
Course Catalog System…
Billing System …
External System
Interfaces
(from Business Services)
Packages…
• The CourseCatalogSystem is dependent on the:
. 1. java.sql package in order to gain access to the
design elements (objects) that implement
java.sql
(from Middleware)
the RDBMS persistency mechanism.
University Artifacts
(from Business Services)
Student; Course Offering…
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
Ex: BillingSystem Subsystem Dependencies
This models the dependencies that the BillingSystem
Sub System has with other design elements.
These dependencies are on standard packages
that do not have a specific interface.
Thus the BillingSystem SubSystem cannot be reused
without the packages it depends on. (same words…)
<<subsystem>>
BillingSystem
(from Business Services)
Packages…
The BillingSystem SS is dependent on the
1. External System Interfaces package in
External System
order to gain access to the SS interface
Interfaces
(from Business Services)
itself (IBillingSystem); 2. University Artifacts, …
Remember: Oftentimes subsystem interfaces are not packaged
with the subsystems themselves. They may be be packaged
in a separate package called External Interfaces, and hence
likely found in the domain layer (which makes sense!).
University Artifacts
(from Business Services)
The BillingSystem subsystem is dependent on the
University Artifacts package in order to gain
access to the core abstractions in the Core Registration System.
10
Subsystem Design Steps




Distribute Subsystem behavior to
Subsystem Elements
Document Subsystem Elements
Describe Subsystem Dependencies
 Checkpoints

It is 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?
How many interaction diagrams should be
produced during Subsystem Design?
Why should dependencies on a subsystem
be on the subsystem interface?
Explain how dependencies are modeled on
packages and on subsystems.
13