Subsystem Design. FROM Dr. Giuseppe Calavaro, Ratiolal TO Students in the DISP, University of Roma Tor Vergata 2003

Transcription

1 Subsystem Design FROM Dr. Giuseppe Calavaro, Ratiolal TO Students in the DISP, University of Roma Tor Vergata 2003 Copyright Rational Software, all rights reserved 1

2 Objectives: Subsystem Design Understand the purpose of Subsystem Design and where in the lifecycle it is performed Define the behaviors specified in the subsystem's interfaces in terms of collaborations of contained classes Document the internal structure of the subsystem Determine the dependencies upon elements external to the subsystem Copyright Rational Software, all rights reserved 2

3 Subsystem Design in Context Architectural Analysis Architect Architectural Design Describe Concurrency Describe Distribution Review the Architecture Architecture Reviewer Designer Use-Case Analysis Use-Case Design Subsystem Design Review the Design Design Reviewer Class Design Copyright Rational Software, all rights reserved 3

4 Subsystem Design Overview Design Subsystems and Interfaces Design Subsystems and Interfaces (updated) Use-Case Realization Subsystem Design Use-Case Realization (updated) Design Guidelines Design Classes Copyright Rational Software, all rights reserved 4

5 Review: Subsystems and Interfaces A cross between a package and a class Realizes one or more interfaces which define its behavior <<interface>> Interface <<subsystem>> Subsystem Name Interface Realization (Canonical form) Subsystem Interface Copyright Rational Software, all rights reserved 5 Realization (Elided form) <<subsystem>> Subsystem Name

6 Subsystem Guidelines Goals Loose coupling Portability, plug-and-play compatibility Insulation from change Independent evolution Strong Suggestions Don t expose details, only interfaces Only depend on other interfaces Key is abstraction and encapsulation <<subsystem>> A <<subsystem>> B <<subsystem>> C Copyright Rational Software, all rights reserved 6

7 Review: Modeling Convention for Subsystems and Interfaces The <<subsystem>> package provides a container for the elements <<subsystem>> that comprise the subsystem, the interaction diagrams that describe CourseCatalogSystem how the subsystem ICourseCatalogSystem elements collaborate to implement the operations of the interfaces the subsystem realizes, and other diagrams that clarify the subsystem elements. The <<subsystem proxy>> class actually realizes the interface and will <<subsystem>> orchestrate package the implementation of the subsystem interface operations. <<subsystem proxy>> class Interfaces start with an I <<subsystem>> CourseCatalogSystem <<subsystem proxy>> CourseCatalogSystem ICourseCatalogSystem Copyright Rational Software, all rights reserved 7

8 Subsystem Design Steps Distribute Subsystem behavior to Subsystem Elements Document Subsystem Elements Describe Subsystem Dependencies Checkpoints Copyright Rational Software, all rights reserved 8

9 Subsystem Design Steps Distribute Subsystem behavior to Subsystem Elements Document Subsystem Elements Describe Subsystem Dependencies Checkpoints Copyright Rational Software, all rights reserved 9

10 Subsystem Responsibilities Subsystem responsibilities defined by interface operations Interface operations may be realized by Internal class operations Internal subsystem operations <<interface>> ICourseCatalogSystem getcourseofferings() <<subsystem>> CourseCatalogSystem subsystem responsibility Copyright Rational Software, all rights reserved 10

11 Distributing Subsystem Responsibilities Identify new, or reuse existing, design elements (e.g., classes and/or subsystems) Be careful to avoid having effectively the same class in two different Allocate subsystems. subsystem responsibilities to design elements Incorporate Existence of such applicable a class implies mechanisms that the subsystem (e.g., boundaries persistence, may not be well-drawn. distribution, etc.) Document design element collaborations in interface realizations Diagram One are or owned more by the interaction subsystem, and diagrams are used to design per the interface internal behavior operation of the subsystem. The diagrams are essential for subsystems with complex internal designs. It also enables the subsystem behavior to be easily understood, Class hopefully diagram(s) rendering containing it reusable across the contexts. required design element relationships These internal interaction diagrams should incorporate any Revisit Architectural Design applicable mechanisms initially identified in Architectural Design (e.g., Adjust persistence, subsystem distribution, boundaries etc.) and/or dependencies, as needed Copyright Rational Software, all rights reserved 11

12 Modeling Convention: Subsystem Interaction Diagrams Subsystem Client Subsystem Proxy Design Element 1 Design Element 2 performresponsibility( ) Op1() subsystem responsibility Op2() Op3() Internal subsystem interactions Op4() Subsystem interface not shown Copyright Rational Software, all rights reserved 12

13 Example: CourseCatalogSystem Subsystem In Context subsystem interface : Student : RegisterFor CoursesForm : Registration Controller : ICourseCatalog System : Schedule : Student 1: // create schedule( ) Student wishes to create a new schedule 2: // get course offerings( ) 3: getcourseofferings(semester) 4: // display course offerings( ) A list of the available course offerings for this semester are displayed A blank schedule is displayed for the students to select offerings 5: // display blank schedule( ) subsystem responsibility Legacy RDBMS Database Access 6: // select 4 primary and 2 alternate offerings( ) 7: // create schedule with offerings( ) 8: // create with offerings( ) 9: // add schedule(schedule) At this, point the Submit Schedule subflow is executed. Copyright Rational Software, all rights reserved 13

14 Incorporating the Architectural Mechanisms: Persistency Analysis-Class-to-Architectural-Mechanism Map from Use-Case Analysis Analysis Class Student Schedule CourseOffering Course RegistrationController Analysis Mechanism(s) Persistency, Security Persistency, Security Persistency, Legacy Interface Persistency, Legacy Interface Distribution OODBMS Persistency RDBMS Persistency OODBMS Persistency was discussed in Use-Case Design Copyright Rational Software, all rights reserved 14

15 Review: Incorporating JDBC: Steps Provide access to the class libraries needed to implement JDBC Provide java.sql package Create the necessary DBClasses One DBClass per persistent class Course Offering persistent class => DBCourseOffering (continued) Copyright Rational Software, all rights reserved 15

16 Review: Incorporating JDBC: Steps (contd.) Incorporate DBClasses into the design Allocate to package/layer DBCourseOffering placed in CourseCatalogSystem subsystem Add relationships from persistency clients Persistency clients are the CourseCatalogSystem subsystem clients Create/Update interaction diagrams that describe: Database initialization Persistent class access: Create, Read, Update, Delete Copyright Rational Software, all rights reserved 16

17 Example: Local CourseCatalogSystem Subsystem Interaction CourseCatalog System Client : : : Connection CourseCatalogSystemDBCourseOfferring : Statement : : : Course Catalog CourseOfferingList CourseOffering : ResultSet 1. getcourseofferings(semester) Retrieve all available course offerings for the current semester Subsystem Proxy 1.1. read(string) createstatement( ) sql statement is passed in specifying the search criteria executequery(string) course offerings in the current semester // executequery( Create ) a list to hold all retrieved course offerings Repeat these operations for each element returned from the executequery() command. The CourseOfferingList is loaded with the data retrieved from the database. The getdata and setdata operations are called for each attribute in the each retrieved class instance new( ) new( ) 3. setdata( ) 4. add(courseoffering) 2. getstring( ) Add the retrieved course offering to the list to be returned RDBMS Read Copyright Rational Software, all rights reserved 17

18 Example: Billing System Subsystem In Context subsystem interface : Registrar : : : : CloseRegistrationFormCloseRegistrationController ICourseCatalogSystemCourseOffering : Schedule : Student. : IBillingSystem 1. // close registration( ) 1.1. // is registration open?( ) 2. // close registration( ) Repeat twice this is for simplicity; realistically, an indefinite number of iterations could occur) Retrieve a list of course offerings for the current semester 2.1. getcourseofferings(semester) 2.2. // close registration( ) 2.3. // level( ) Close registration for each course offering If the maximum number of selected primary courses have not been committed, select alternate course offerings). Finally commit or cancel the course offering once all leveling has occurred Send student and tuition to the Billing System, which will do the actual billing to the student for the schedule // close( ) 2.5. gettuition( ) 2.6. submitbill(student, double) Currently assuming tuition based on number of offerings taken and certain attributes of students. If different offerings get different prices this will change slightly. Copyright Rational Software, all rights reserved 18 subsystem responsibility

19 Example: Local BillingSystem Subsystem Interaction Subsystem Proxy Billing System Client : BillingSystem : StudentBillingTransaction : Student. : BillingSystemInterface : Billing System 1. submitbill(student, double) 1.1. create(student, double) Retrieve the information that must be included on the bill // get contact info( ) 1.2. submit(studentbillingtransaction) // open connection( ) // process transaction( ) // close connection( ) Copyright Rational Software, all rights reserved 19

20 Subsystem Design Steps Distribute Subsystem behavior to Subsystem Elements Document Subsystem Elements Describe Subsystem Dependencies Checkpoints Copyright Rational Software, all rights reserved 20

21 Example: CourseCatalogSystem Subsystem Elements <<Interface>> ICourseCatalogSystem (from External System Interfaces) getcourseofferings(forsemester : Semester) : CourseOfferingList <<subsystem proxy>> CourseCatalogSystem getcourseofferings(forsemester : Semester) : CourseOfferingList Subsystem Interface Subsystem Proxy CourseOfferingList (from University Artifacts) new() add() 1 DBCourseOfferring create() : CourseOffering read(searchcriteria : string) : CourseOfferingList 1 <<entity>> CourseOffering new() setdata() 0..* (from University Artifacts) 1 Connection (from java.sql) createstatement() Statement (from java.sql) executequery() executeupdate() ResultSet (from java.sql) getstring() Copyright Rational Software, all rights reserved 21

22 Example: Billing System Subsystem Elements <<Interface>> IBillingSystem (from External System Interfaces) submitbill(forstudent : Student, fortuition : double) StudentBillingTransaction Subsystem Interface create(forstudent : Student, foramount : double) <<subsystem proxy>> BillingSystem submitbill(forstudent : Student, fortuition : double) 1 <<entity>> Student. (from University Artifacts) // get contact info() Subsystem Proxy 0..1 BillingSystemInterface submit(thetransaction : StudentBillingTransaction) Copyright Rational Software, all rights reserved 22

23 Subsystem Design Steps Distribute Subsystem behavior to Subsystem Elements Document Subsystem Elements Describe Subsystem Dependencies Checkpoints Copyright Rational Software, all rights reserved 23

24 Describing Subsystem Dependencies Subsystem dependency on a subsystem <<subsystem>> Client Support <<subsystem>> Server Support Flexible Server Subsystem dependency on a package <<subsystem>> Client Support Supporting Types Use with care Copyright Rational Software, all rights reserved 24

25 Example: CourseCatalogSystem Subsystem Dependencies <<subsystem>> CourseCatalogSystem (from Business Services) External System Interfaces (from Business Services) MEMO A subsystem cannot be reused without the packages it depends on Access to the subsystem interface itself (ICourseCatalogSystem). University Artifacts (from Business Services) Access the core types of the Course Registration System java.sql (from Middleware) Access the DBMS Copyright Rational Software, all rights reserved 25

26 Example: BillingSystem Subsystem Dependencies <<subsystem>> BillingSystem (from Business Services) External System Interfaces (from Business Services) University Artifacts (from Business Services) Copyright Rational Software, all rights reserved 26

27 Subsystem Design Steps Distribute Subsystem behavior to Subsystem Elements Document Subsystem Elements Describe Subsystem Dependencies Checkpoints Copyright Rational Software, all rights reserved 27

28 Checkpoints: Design Subsystems 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? Copyright Rational Software, all rights reserved 28

29 Review: Subsystem Design 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? Copyright Rational Software, all rights reserved 29

30 Exercise: Subsystem Design Given the following: The defined subsystems, their interfaces and their relationships with other design elements (the subsystem context diagrams) Patterns of use for the architectural mechanisms (continued) Copyright Rational Software, all rights reserved 30

31 Exercise: Subsystem Design (cont.) Identify the following for a particular subsystem(s): The design elements contained within the subsystem and their relationships The applicable architectural mechanisms The interactions needed to implement the subsystem interface operations (continued) Copyright Rational Software, all rights reserved 31

32 Exercise: Subsystem Design (cont.) Produce the following diagrams for a particular subsystem(s): Interface realizations Interaction diagram for each interface operation Class diagram containing the subsystem design elements that realize the interface responsibilities and their relationships Class diagram that shows the subsystem and any dependencies on external packag(es) and/or subsystem(s) (subsystem dependencies class diagram) Copyright Rational Software, all rights reserved 32