Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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