1. 1 Detail Design Subsystem Design Static Part - VOPC

2. 2 Subsystem Design Steps - continuing Distribute Subsystem behavior to Subsystem Elements – covered this last lecture…. Document Subsystem Elements Have responsibilities allocated to subsystems now allocated to subsystem elements. Have collaborations between subsystem elements modeled via interaction diagrams.  To do: Model internal structure of subsystem  Model subsystem element relationships Relationships are driven by what is required to support the collaborations to implement the subsystem interfaces Describe Subsystem Dependencies

3. 3 Procedure: Document internal SS Structure  Create class diagram(s) showing contained elements and their associations. IF lots of complexity, may need two class diagrams. Create State diagram? May be appropriate to show different states subsystem can assume. (interfaces and subsystems are “stateful”). Document any order dependencies (e.g., op1 must be executed before op2, etc.).

4. 4 Ex: CourseCatalogSystem SS Elements (1of 2) Subsystem Proxy Subsystem Interface DBCourseOfferring create() : CourseOffering read(searchCriteria : string) : CourseOfferingList CourseCatalogSystem getCourseOfferings(forSemester : Semester) : CourseOfferingList > ICourseCatalogSystem getCourseOfferings(forSemester : Semester) : CourseOfferingList (from External System Interfaces) > Statement executeQuery() executeUpdate() (from java.sql) Connection createStatement() (from java.sql) 1 1 CourseOfferingList new() add() (from University Artifacts) CourseOffering new() setData() (from University Artifacts) > 1 0..* ResultSet getString() (from java.sql) Concentrating on the interface getCourseOfferings()… CourseCatalogSystem works with DBCourseOffering to read/write persistent data from CourseCatalogSystem (RDBMS). DBCourseOffering is responsible for accessing the JDBC database using the previously- established Connection (recall java.sql) (Recall: Once database connection is opened, 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.) Note:

5. 5 Ex: CourseCatSystem Sub Sys Elements (2of 2) Subsystem Proxy Subsystem Interface DBCourseOfferring create() : CourseOffering read(searchCriteria : string) : CourseOfferingList CourseCatalogSystem getCourseOfferings(forSemester : Semester) : CourseOfferingList > ICourseCatalogSystem getCourseOfferings(forSemester : Semester) : CourseOfferingList (from External System Interfaces) > Statement executeQuery() executeUpdate() (from java.sql) Connection createStatement() (from java.sql) 1 1 CourseOfferingList new() add() (from University Artifacts) CourseOffering new() setData() (from University Artifacts) > 1 0..* ResultSet getString() (from java.sql) Note: elements outside of the subsystem are shown, as well, to provide context. These elements – identified as their owning package is listed in parentheses below (e.g University Artifacts) Especially note the modeling of the interface and proxy (as well as persistency) Again, the DBCourseOffering can be in the applications layer (perhaps in a package; could conceivably be in a Domain Layer, where other apps needing access to these objects can reuse the DBConnections, …. Notice also the presence of java.sql. Probably in Middleware)

6. 6 Example: Billing System Subsystem Elements StudentBillingTransaction create(forStudent : Student, forAmount : double) Student. // get contact info() (from University Artifacts) > BillingSystem submitBill(forStudent : Student, forTuition : double) > BillingSystemInterface submit(theTransaction : StudentBillingTransaction) 0..1 1 1 IBillingSystem submitBill() (from External System Interfaces) > Subsystem Proxy Subsystem Interface Remember, the actual generation and submission of the bill is responsibility of the Billing System subsystem. (So, the proxy uses StudentBillingTransaction and the Student entity stored in the UniversityArtifacts package. Presumably the submitBill method needs these objects.) So, we really don’t care how the Billing System (the file access itself) does its thing. This models the SS elements and their relationships. These relationships support the required collaborations between the design elements to support the behavior of the SS (as documented in the SS interfaces). Again, elements outside SS are shown to provide context. Especially note the modeling of the interface and proxy. If nested subsystems are defined (like here) the class diagrams should only show the relationship to the subsystem interfaces. Internals can be defined for ‘that’ subsystem design. Note the dependencies, realizations, and communications…

7. 7 Subsystem Design Steps 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 external elements (elements external to the subsystem) upon which the SS depends. These dependences may have been introduced when designing the internals of the SS – as described earlier. Important to note: subsystems may not be able to stand alone; they may need services of other SSs. SS designer should feel free to use services of other SS.

8. 8 Flexible Describing Sub Sys Dependencies - Subsystem Subsystem dependency on a SubSystem Server Client Support > Server Support > When a subsystem uses some behavior of an element contained by another Sub System or package, a dependency on the external element is needed. If the element on which the Sub System is dependent is within a Sub System, the dependency should be on the SS interface, not on the element within the SS. e.g. Dependencies on java.sql 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 directly references a model element inside of another Sub- System, the designer is no longer free to remove that model element or redistribute the behavior of that model element to other elements. Result, a brittle architecture!

9. 9 Describing Sub Sys Dependencies - Package Subsystem dependency on a Package  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…) Ideally, a SS should only depend on the interfaces of other model elements for the reasons stated before. The exception: number of Sub Systems share a set of common class definitions, in which case those Sub Systems '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. Use with care Client Support > Supporting Types

10. 10 Ex: CourseCatalogSystem Sub System Dependencies java.sql (from Middleware) CourseCatalogSystem (from Business Services) > External System Interfaces (from Business Services) University Artifacts (from Business Services) This models the dependencies that the Course CatalogSystem has with other design elements These dependencies support the relationships modeled on earlier Sub System 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. The CourseCatalogSystem is dependent on the: java.sql package in order to gain access to the design elements that implement the RDBMS persistency mechanism. External System Interfaces in order to gain access to the SS itself (ICourseCatalogSystem). Remember, the Sub System Interfaces were not packaged with the SS themselves University Artifacts package in order to gain access to the core types of the Course Registration System. Course Catalog System… Billing System … Student; Course Offering… Note: these are dependencies on packages – not subsystems. I’ve been calling the Business Services layer our Domain Layer… Packages…

11. 11 Ex: BillingSystem Subsystem Dependencies BillingSystem (from Business Services) > External System Interfaces (from Business Services) University Artifacts (from Business Services) 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 SS cannot be reused without the packages it depends on. The BillingSystem SS is dependent on the External System Interfaces package in order to gain access to the SS interface itself (IBillingSystem). Remember: the Sub System interfaces were not packaged with the Sub Systems themselves. The BillingSystem subsystem is dependent on the University Artifacts package in order to gain access to the core types of the Core Registration System.

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

13. 13 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. Is each operation on an interface realized by the subsystem documented in a interaction diagram? If not, is the operation realized by a single class, so that it is easy to see that there is a simple 1:1 mapping between the class operation and the interface operation?

14. 14 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?