Detail Design Subsystem Design Static Part - VOPC

1. Detail DesignSubsystem DesignStatic Part - VOPC

2. Subsystem Design Steps - continuing Document Subsystem Elements We have responsibilities allocated to subsystems and now responsibilities are allocated to the subsystemelements. • We havecollaborations 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.

3. 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.).

4. 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 SubsystemProxy SubsystemInterface • 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 (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.) DBCourseOfferring create() : CourseOffering CourseOfferingList read(searchCriteria : string) : CourseOfferingList (from University Artifacts) 1 new() Note where these objects reside!! add() 1 1 0..* Connection <<entity>> (from java.sql) CourseOffering Statement (from University Artifacts) createStatement() (from java.sql) new() executeQuery() ResultSet setData() executeUpdate() (from java.sql) getString()

5. Ex: CourseCatSystem Sub System Elements (2of 2) Inside subsystem; classes only <<Interface>> <<subsystem proxy>> ICourseCatalogSystem CourseCatalogSystem (from External System Interfaces) getCourseOfferings(forSemester : Semester) : CourseOfferingList getCourseOfferings(forSemester : Semester) : CourseOfferingList Subsystem Proxy Subsystem Interface DBCourseOfferring create() : CourseOffering CourseOfferingList read(searchCriteria : string) : CourseOfferingList (from University Artifacts) Note: elements outside of the subsystem are shown, as well, to provide context. These elements – identified by their owningpackage are listed in parentheses below in the class header (e.g University Artifacts) 1 new() add() 1 1 0..* Connection <<entity>> (from java.sql) CourseOffering Statement (from University Artifacts) createStatement() (from java.sql) new() executeQuery() ResultSet setData() 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 conceivably be in a Domain Layer, where other applications needing access to these objects can reuse the DBConnections, …. Notice also the presence of java.sql.(Probably in Middleware Layer) getString()

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

7. <<subsystem>> <<subsystem>> Client Support Server Support Server Describing SubSystem Dependencies - Subsystems Flexible • Subsystem Dependencies on a SubSystem • 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 differentsubsystem, 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!

8. <<subsystem>> Client Support SupportingTypes Describing SubSystem Dependencies - Package Use with care • Subsystem Dependencies on a Package •  If the element the subsystem element is dependent on is within a package, • the dependency should be on the packageitself. (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 ofcommon 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. )

9. <<subsystem>> CourseCatalogSystem (from Business Services) External System Interfaces (from Business Services) University Artifacts (from Business Services) java.sql (from Middleware) Ex: CourseCatalogSystemSubsystem Dependencies I’ve been calling the Business Services layer our Domain Layer… • This models the dependencies that the Course • CatalogSubSystem has with other design elements • 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. • The CourseCatalogSystem is dependent on the: • . 1. java.sql package in order to gain access to the • design elements (objects) that implement • the RDBMS persistency mechanism. • . 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. Course Catalog System… Billing System … Packages… Student; Course Offering… Note: these are dependencies on packages – not subsystems.

10. Ex: BillingSystemSubsystem Dependencies This models the dependencies that the BillingSystem Sub System has with other designelements. 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…) The BillingSystem SS is dependent on the 1. External System Interfaces package in order to gain access to the SS interface itself (IBillingSystem); 2. University Artifacts, … Remember: Oftentimes subsysteminterfaces are not packaged with the subsystems themselves. They may be be packaged in a separate package called ExternalInterfaces, and hence likely found in the domain layer (which makes sense!). The BillingSystem subsystem is dependent on the University Artifacts package in order to gain access to the core abstractions in the Core Registration System. <<subsystem>> BillingSystem (from Business Services) Packages… External System Interfaces (from Business Services) University Artifacts (from Business Services)

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

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

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