1 detail design subsystem design background and the dynamic part

1

Detail Design Subsystem Design Background and the

Dynamic Part

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 internal structure of the subsystem

Determine the dependencies upon elements external to the subsystem that may be needed to support the responsibilities of the interface.

3

Subsystem Design in Context

Architect

Designer

ArchitecturalAnalysis

ArchitectureReviewer

Review theDesign

Review theArchitecture

Use-CaseAnalysis

ArchitecturalDesign

DescribeConcurrency

DescribeDistribution

ClassDesign

Subsystem Design

Use-Case Design

DesignReviewer

This is a tailored version of the Analysis and Design core workflow of the RUP.(See RUP textbook for more)

We have defined classes, subsystems, their interfaces, and their dependencies.

• Some things so far are components or sub-systems i.e., ‘containers’ of complex behavior that we have treated as a black box.

• Now we need to flesh out the internal interactions, i.e., what classes exist in the subsystem to support, and how do they collaborate to support, the responsibilities documented in the subsystem interfaces. • This is what subsystem design is all about.

4

Subsystem Design in Context

Architect

Designer

ArchitecturalAnalysis

ArchitectureReviewer

Review theDesign

Review theArchitecture

Use-CaseAnalysis

ArchitecturalDesign

DescribeConcurrency

DescribeDistribution

ClassDesign

Subsystem Design

Use-Case Design

DesignReviewer

Here in subsystem design, we look at 1) the responsibilities of the subsystem in detail, defining and refining the classes that are needed to implement those responsibilities, while 2) refining subsystem dependencies as needed.

The internal interactions are expressed as collaborations of classes and possibly other components or subsystems.

The focus is on the subsystem.

The activity is iterative and recursive, but eventually feeds Class Design.

5

Subsystem Design Overview**

SubsystemDesign

Use-Case Realization Use-Case Realization(updated)

Design Subsystems and InterfacesDesign Subsystems and Interfaces

(updated)

Design ClassesDesign

Guidelines

Subsystem Design is performed once per Design Subsystem. Purpose: to define the behaviors specified in the subsystem’s interface in terms of collaborations of contained classes; to document the internal structure of the subsystem, to define realizations between subsystem’s interfaces and contained classes, and to determine the dependencies upon other subsystems.

6

A “cross between” a package and a class Has semantics of a package (i.e., can contain other model

elements) and a class (has behavior). Realizes one or more interfaces which define its behavior

<<subsystem>>Subsystem Name

Interface Subsystem


Interface

Realization (Canonical form)

Realization (Elided form)

<<interface>>Interface

Review: Subsystems and Interfaces

7

An interface is a model element which defines a set of behaviors (set of operations) offered by a classifier model element (e.g., class, subsystem or component).

A classifier may realize one or more interfaces. An interface may be realized by one or more classifiers.


Interface Subsystem


Interface





8

Interfaces are not abstract classes, as abstract classes provide default behaviors. Interfaces provide no default behavior.

Realization is a semantic relationship between two classifiers – one serves as contract (the interface class) ; other, carries it out (subsystem contents and its dependencies).


Interface Subsystem


Interface





9

Key is abstraction and encapsulation

A<<subsystem>>

B<<subsystem>>

C<<subsystem>>

Subsystem Guidelines Goals

Loose coupling; as independent as possible Portability, plug-and-play compatibility

Evolve different parts of systemindependently from other parts.

Insulation from change - minimized Replaceable elements in the model.

Strong Suggestions for Subsystems: Don’t expose details, only interfaces No element contained by a subsystem should have public visibility. No element outside the subsystem should depend on a particular element inside the subsystem. Only depend on interfaces of other model elements so that it is not directly dependent on any specific model element outside the subsystem.

10

Key is abstraction and encapsulation

A<<subsystem>>

B<<subsystem>>

C<<subsystem>>

Subsystem Guidelines

Exception: sharing of some class definitionsin common, should only be done with packagesin lower layers to ensure common definition of classes which must pass between subsystems

All dependencies on a subsystem should be dependencies on the subsystem interfaces.

Clients of a subsystem are dependent on the subsystem interface(s), not on elements withinthe subsystem.

In this way, the subsystem can be replaced by any other subsystem that realizes the same

interfaces.

11

Modeling Convention for Subsystems and Interfaces**

CourseCatalogSystem<<subsystem>>

ICourseCatalogSystem

ICourseCatalogSystem

CourseCatalogSystem<<subsystem proxy>>

CourseCatalogSystem<<subsystem>>

<<subsystem>> package

<<subsystem proxy>> class

Represent subsystems as three items in model: <<subsystem>> package; <<subsystem proxy>> class, & subsystem interface (class with stereotype <<interface>>). The interface names should start with an “I.”

The subsystem package provides a container for the elements that comprise the subsystem.

The interaction diagrams describe how thesubsystem elements collaborate to implement the operations of the interface the subsystem realizes, and other diagrams that clarify the sub system elements.

NB: <<subsystem proxy>> class actually realizes the interface and will orchestrate the implementation of the subsystem operations.

14

CourseCatalogSystem<<subsystem>>ICourseCatalogSystem

getCourseOfferings()

<<interface>>

subsystem responsibility

Subsystem Responsibilities** Subsystem responsibilities defined by the interface it realizes When a subsystem realizes an interface, it makes a

commitment to support each and every operation defined by the interface.

Interface operations may be realized by Internal class operations (which may require collaboration

with other classes or subsystems) An interface realized by a contained subsystem.

17

Modeling Convention: Subsystem Interaction Diagrams

Subsystem Client Subsystem Proxy Design Element 1

performResponsibility( )

Op1()


Op2()

Design Element 2

Op3()

Op4()

Internal subsystem interactions

Subsystem interface not shown

As mentioned, there should be at least one interaction diagram per interface operation to illustrate how the operations offered by the interfaces of the subsystem are performed by model elements contained in the subsystem.

18

Modeling Convention: Subsystem Interaction Diagrams**

Subsystem Client Subsystem Proxy Design Element 1

performResponsibility( )

Op1()

subsystem responsibilityOp2()

Design Element 2

Op3()

Op4()

Internal subsystem interactions

• A message should be drawn from the <<subsystem>> client to the <<subsystem proxy>> class defined for the subsystem. The message should then be mapped to/associated with the interface operation that is being modeled in the interaction diagram. • Remainder of diagram should model how the <<subsystem proxy>> class delegates responsibility for performing the invoked operation to the other subsystem elements.• Recommend you name the interaction diagram <interface name>::<operation name>>.• This convention simplifies future tracing of interface behaviors to the classes implementing the interface operations.

The interface does not appear on the INTERNAL subsystem interaction diagram.

19

Example: CourseCatalogSystem Subsystem In Context

subsystem interface

: Student

: RegisterForCoursesForm

: RegistrationController

: Schedule : Student : ICourseCatalogSystem

A list of the available course offerings for this semester are displayed

Student wishes to create a new schedule

1: // create schedule( )

4: // display course offerings( )

2: // get course offerings( )

9: // add schedule(Schedule)

3: getCourseOfferings(Semester)

5: // display blank schedule( )

At this, point the Submit Schedule subflow is executed.

6: // select 4 primary and 2 alternate offerings( )

7: // create schedule with offerings( )8: // create with offerings( )

A blank schedule is displayed for the students to select offerings


Legacy RDBMS Database AccessThis sequence diagram sets the context of what will be performed in Subsystem Design. - Puts requirements on the subsystem, and is the primary input specification to the task of creating local interactions for the subsystem.

20

Example: CourseCatalogSystem Subsystem In Context

subsystem interface

: Student

: RegisterForCoursesForm

: RegistrationController

: Schedule : Student : ICourseCatalogSystem

A list of the available course offerings for this semester are displayed

Student wishes to create a new schedule

1: // create schedule( )

4: // display course offerings( )

2: // get course offerings( )

9: // add schedule(Schedule)

3: getCourseOfferings(Semester)

5: // display blank schedule( )

At this, point the Submit Schedule subflow is executed.

6: // select 4 primary and 2 alternate offerings( )

7: // create schedule with offerings( )

8: // create with offerings( )

A blank schedule is displayed for the students to select offerings

subsystem responsibility Legacy RDBMS Database Access

• The ICourseCatalogSystem::getCourseOfferings() documentation specifies: “Retrieve the course offerings available for the specified semester.”

• So retrieval of the course offerings from legacy database is responsibility of CourseCatalog system. Now, must show exactly HOW this is done using the RDBMS persistency mechanism.

21

Analysis Class Analysis Mechanism(s)

Student

CourseOffering

Course

RegistrationController

Persistency, Security

Persistency, Legacy Interface

Persistency, Legacy Interface

Distribution

Incorporating the Architectural Mechanisms: Persistency

Schedule Persistency, Security

OODBMS Persistency

RDBMS Persistency

• Given all this, let’s see how the subsystem accommodates its responsibilities. • Since we have been concentrating on course registration, the table only contains classes for the Register for Courses UC Realization that have analysis mechanisms assigned to them.

• We will now incorporate the legacy RDBMS persistency mechanism since access to the legacy system has been encapsulated within a sub system. The legacy interface mechanism distinguished the type of persistency. Remember, legacy data is stored in a RDBMS.

22

(Done:) Provide access to the class libraries needed to implement JDBC; (i.e., Provide java.sql package)

Create the necessary DBClasses and their dependencies on java.sql package; develop detailed interactions. Recall: the java.sql package contains the design elements

that support the RDBMS persistency mechanism. The java.sql package will be depended on by the

CourseCatalogSystem subsystem as that is where the created DBCourseOffering class will be placed (ahead)

Thus a dependency will be added from CourseCatalogSystem to java.sql.

Recall also: One DBClass per persistent class, and the Course Offering persistent class DBCourseOffering.

Review: Incorporating JDBC: Steps of Steps

(continued)

23

Once created, must incorporate DBClasses into the design. Allocate to a package/layer. (probably domain; maybe app)

e.g, The DBCourseOffering class will be placed in the CourseCatalogSystem subsystem.

Once DBClasses have been allocated to packages/layers, the relationships to the DBClasses from all classes requiring

persistence support (that is, the persistency clients) needs to be added. (Persistency clients are the CourseCatalogSystem subsystem clients)

These dependencies have already been established.

The interaction diagrams provide a means to verify that all required database functionality is supported by the design elements.

Review: Incorporating JDBC:Steps (contd)**

24

Review: Incorporating JDBC: Steps (contd.)** Note: the persistency client sends a message to the subsystem proxy class to get course offerings

with argument (Semester)

The proxy class (representing the subsystem) first contacts the DBClass for objects of the persistency class. These DBClasses may be in a single package or elsewhere. But they are ‘depended upon’ by

the subsystem (proxy class).

As we are aware, the DBClass (and perhaps a DBClass package in the domain layer???) will then have a dependency on the java.sql likely in the middleware layer)

Note: that in this sequence diagram, the objects we saw in the class diagram (static view – VOPC) when we were studying Persistency - are playing a clear cut role, and the ‘timing’ of the interactions is quite specific.

Note also that the Course Catalog System is clearly an Actor, which, of course, it should be, AND it is shown as such – in place – in the Sequence Diagram.

So, we are seeing HOW the Course Catalog Subsystem via the proxy class is handling its responsibilities (and associated dependencies!)

25

Ex: Local CourseCatalogSystem Subsystem Interaction

Subsystem Proxy

RDBMSRead

Retrieve all available course offerings for the current semester

CourseCatalogSystem Client

: CourseCatalogSystem

: DBCourseOffering

: CourseOffering

: CourseOfferingList

: ResultSet : Course Catalog

: Statement : Connection

1. getCourseOfferings(Semester)

1.1. read(string)

1.1.1. createStatement( )

1.1.2. executeQuery(String)sql statement is passed in specifying the search criteria -- course offerings in the current semester

1.1.4. new( )

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.

3. setData( )

Create a list to hold all retrieved course offerings

Add the retrieved course offering to the list to be returned

2. getString( )

1.1.3. new( )

4. add(CourseOffering)

1.1.2.1. // executeQuery( )

• Internals of subsystems should yield interaction diagrams that look like this.• We see collaborations to implement the getCourseOfferings operation of the ICourseCatalogSystem interface.• Recall: legacy system stores course offerings in an RDBMS.• Here we show how the RDBMS persistency mechanism identified in Architectural Design is realized in the design.

(Which subsystems/layer do you think these objects are in?)

26


• Client object initiating the interaction is abstracted here…• For design of the subsystem, we don’t care who the client

really is.

• CourseCatalogSystem subsystem proxy class actually realizes the ICourseCatalogSystem interface. It is the class that delegates the implementation of the interface to subsystem elements or to other dependent elements.

27


Subsystem Proxy

RDBMSRead

Retrieve all available course offerings for the current semester

CourseCatalogSystem Client

: CourseCatalogSystem

: DBCourseOffering

: CourseOffering

: CourseOfferingList

: ResultSet : Course Catalog

: Statement : Connection

1. getCourseOfferings(Semester)

1.1. read(string)

1.1.1. createStatement( )

1.1.2. executeQuery(String)sql statement is passed in specifying the search criteria -- course offerings in the current semester

1.1.4. new( )

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.

3. setData( )

Create a list to hold all retrieved course offerings

Add the retrieved course offering to the list to be returned

2. getString( )

1.1.3. new( )

4. add(CourseOffering)

1.1.2.1. // executeQuery( )

• To read the course offerings, the persistency client, the proxy class, asks the DBCourseOffering class to retrieve a course offerings for the specified semester.• DBCourseOffering creates a new statement using Connection class’s createStatement() operation.• The statement is executed; data is returned to ResultSet object. DBCourseOffering then creates a list of CourseOffering instances, CourseOfferingList, populates it with retrieved data, and returns it to the client.

28

Example: Billing System Subsystem In Context

Send student and tuition to the Billing System, which will do the actual billing to the student for the schedule.

: Registrar : CloseRegistrationForm

: CourseOffering

: Schedule : Student. : IBillingSystem

: ICourseCatalogSystem

: CloseRegistrationController

Close registration for each course offering

Retrieve a list of course offerings for the current semester

If the maximum number of selected primary courses have not been committed, select alternate course offerings).

Currently assuming tuition based on number of offerings taken and certain attributes of students. If different offerings get different prices this will change slightly.

Repeat twice this is for simplicity; realistically, an indefinite number of iterations could occur)

Finally commit or cancel the course offering once all leveling has occurred

1. // close registration( )


2.2. // close registration( )

1.1. // is registration open?( )

2.6. submitBill(Student, double)

2.3. // level( )

2.1. getCourseOfferings(Semester)

2.4. // close( )

2.5. getTuition( )

subsystem interface


• Here, will demonstrate design of a subsystem that does not require the incorporation of an architectural mechanism.• This is a portion of the Close Registration use-case realization sequence diagram. The internals of the Billing System subsystem have not been designed yet. That is the purpose of this activity, Subsystem Design

Now, we are really after the next slide…

29

Example: Billing System Subsystem In Context

Send student and tuition to the Billing System, which will do the actual billing to the student for the schedule.

: Registrar : CloseRegistrationForm

: CourseOffering

: Schedule : Student. : IBillingSystem

: ICourseCatalogSystem

: CloseRegistrationController

Close registration for each course offering

Retrieve a list of course offerings for the current semester

If the maximum number of selected primary courses have not been committed, select alternate course offerings).

Currently assuming tuition based on number of offerings taken and certain attributes of students. If different offerings get different prices this will change slightly.

Repeat twice this is for simplicity; realistically, an indefinite number of iterations could occur)

Finally commit or cancel the course offering once all leveling has occurred



2.2. // close registration( )

1.1. // is registration open?( )

2.6. submitBill(Student, double)

2.3. // level( )

2.1. getCourseOfferings(Semester)

2.4. // close( )

2.5. getTuition( )

subsystem interface


• Here we put requirements on the subsystem, and the sequence diagram is the primary input spec to creating local interactions for the subsystem.• We see the operations subsystem must support. Shows the simple way some client (CloseRegistrationController here) deals with the task of submitting bill to the legacy Billing System.

More coming…

30

•The IBillingsystem::submitBill() documentation specifies the following: “Billing information must be converted into a format understood by the external Billing System and then submitted to the external Billing System.

Thus the actual generation and submission of the bill is responsibility of the Billing System subsystem once the bill and proper parameters are passed to it.

But the billing information must be converted into a format that the Billing System can understand. Let’s see how this is done…

31

Example: Local BillingSystem Subsystem Interaction

Billing System Client

: BillingSystem

: StudentBillingTransaction

: BillingSystemInterface

: Billing System : Student.

1. submitBill(Student, double)

1.1. create(Student, double)

1.2. submit(StudentBillingTransaction)

1.1.1. // get contact info( )

Retrieve the information that must be included on the bill

1.2.1. // open connection( )

1.2.2. // process transaction( )

1.2.3. // close connection( )

Subsystem Proxy

• Designing the internals of a subsystem should yield (local) interaction diagrams like this sequence diagram.• This example looks inside and shows collaborations required to implement the submitBill() operation of the IBillingSystem interface.

Logic here must convert thecontract info into a format (StudentBillingTransaction) that the Billingsystem can understand.Given this, the proxy will orchestrate opening, processing, and closing the connection (and submitting the bill).

32



: BillingSystem












Subsystem Proxy

• The client object initiating the interaction is abstracted. Again, we don’t care…• The BillingSystem subsystem proxy class actually realizes the IBillingSystem interface. • It is the class that delegates the implementation of the interface to the subsystem elements.

33



: BillingSystem












Subsystem Proxy

• The BillingSystem proxy class instance creates a StudentBillingTransaction specific to the external Billing System.• This transaction will be in a format that the Billing System can process.• The StudentBillingTransaction knows how to create itself using information from the given Student.

After creating the StudentBillingTransaction, the BillingSystem proxy class instance submits the transaction to the class instance that actually communicates with the Billing System.

Note that only a single message issent to the proxy: submitBill(…)The proxy, then, implements this responsibility by calling create(Student,double) and submit(StudentBillingTransaction).

1 detail design subsystem design background and the dynamic part

Documents