Detail Design Subsystem Design Background and the Dynamic

Detail Design Subsystem Design Background and the Dynamic Part 1

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 (mentioned in Use Case Design) 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. 2

Subsystem Design in Context in the UP At this time in our Design, we have defined classes, subsystems, their interfaces, and their dependencies. Have looked at components or sub-systems, i. e. , ‘containers’ of complex behavior that we have treated as a black box. Architectural Analysis Describe Architectural Concurrency Design Architect Now we need to flesh out the internal interactions, i. e. , what classes exist in the subsystem and how do they collaborate to support responsibilities documented in the subsystem interfaces. This is what subsystem design is all about. Review the Architecture Reviewer Subsystem Design Use-Case Analysis Designer Describe Distribution Review the Design Use-Case Design Reviewer Class Design 3

Subsystem Design in Context Here in subsystem design: We look at: 1) the detailed responsibilities of the subsystem and define and refine the classes needed to implement responsibilities, while 2) refining subsystem dependencies as needed. Architectural Analysis Describe Architectural Concurrency Design Architect The internal interactions are expressed as collaborations of classes and possibly other components or subsystems. Review the Architecture Reviewer Subsystem Design Use-Case Analysis Designer Describe Distribution Review the Design Use-Case Design Reviewer The focus is on the subsystem. The activity is iterative and recursive, but eventually feeds Class Design 4

Subsystem Design Overview Purpose: to define the behaviors specified in the interface via its contained classes: to document the internal structure of the subsystem, to define realizations between subsystem’s interface(s) and contained classes, & to determine the dependencies upon other subsystems. Design Subsystems and Interfaces (updated) Design Subsystems and Interfaces Use-Case Realization Design Guidelines Subsystem Design Use-Case Realization (updated) Design Classes 5

Review: Subsystems and Interfaces • • Subsystem is 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). Subsystem realizes one or more interfaces which define its behaviors <<interface>> Interface <<subsystem>> Subsystem Name Realization (Canonical form) Interface Subsystem <<subsystem>> Subsystem Name Realization (Elided form) 6

Review: Subsystems and Interfaces • • • 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>> Interface <<subsystem>> Subsystem Name Realization (Canonical form) Subsystem <<subsystem>> Subsystem Name Interface Realization (Elided form) 7

Review: Subsystems and Interfaces • • Interfaces are not classes; provide no default behavior. Realization is a semantic relationship between two classifiers – one serves as contract (the interface ‘class’) ; other, carries it out that is ‘realizes’ the contract. • via its subsystem contents and its dependencies <<interface>> Interface <<subsystem>> Subsystem Name Realization (Canonical form) Subsystem <<subsystem>> Subsystem Name Interface Realization (Elided form) 8

• • Subsystem Guidelines Key is abstraction and encapsulation Goals • Loose coupling; as independent as possible • Insulation from change - minimized • Replaceable elements in the model. Strong Suggestions for Subsystems: • Don’t expose details, only the 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. • <<subsystem>> A <<subsystem>> B <<subsystem>> C Only depend on interfaces of other model elements so that it is not directly dependent on any specific model element outside the subsystem. 9

Subsystem Guidelines Key is abstraction and encapsulation Exception: can share some class definitions done with packages in lower layers to ensure common definition of classes which must pass between subsystems <<subsystem>> A All dependencies on a subsystem should be dependencies on the subsystem interfaces only!! <<subsystem>> B clients not dependent on inside! subsystem can be replaced by different subsystem that realizes same interface. <<subsystem>> C 10

Modeling Convention for Subsystems and Interfaces Represent subsystems as three items in model: 1. <<subsystem>> package; 2. <<subsystem proxy>> class, 3. subsystem interface (class with stereotype <<interface>>). Subsystem package provides a container for the elements in the subsystem. The interaction diagrams describe how the subsystem elements collaborate to implement the operations of the interface the subsystem realizes, Note: <<subsystem proxy>> class actually realizes the interface and will orchestrate the implementation of the subsystem operations. ICourse. Catalog. System <<subsystem>> Course. Catalog. System <<subsystem proxy>> Course. Catalog. System Different (additional) interfaces would have their own proxy! 11

Subsystem Design: Major Steps • Distribute Subsystem behaviors to Subsystem Elements • that is, the design components inside the subsystem. • Next, Document Subsystem Elements (e. g. classes…) • Document internal structural relationships among classes • Then document the interfaces upon which the subsystem itself is dependent. • Then, review the results of your subsystem design. • Now, let’s look at each of these 12

Subsystem Responsibilities • • • Subsystem responsibilities defined by the interface it realizes When a subsystem realizes an interface, it makes a commitment to support 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. <<interface>> ICourse. Catalog. System get. Course. Offerings() subsystem responsibility <<subsystem>> Course. Catalog. System 13

Modeling Convention: Subsystem Interaction Diagrams - General Subsystem Client Subsystem Proxy Design Element 1 Design Element 2 perform. Responsibility( ) Op 1() subsystem responsibility Op 2() Internal subsystem interactions Op 3() Op 4() Subsystem interface not shown 16

Modeling Convention: Subsystem Interaction Diagrams - General Subsystem Client Subsystem Proxy Design Element 1 Design Element 2 perform. Responsibility( ) Op 1() subsystem responsibility Op 2() Internal subsystem interactions Op 3() Op 4() • A message should be drawn from the <<subsystem>> client to the <<subsystem proxy>> • Note: interface does not appear on internal subsystem 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 17 the interface operations.

Example: Course. Catalog. System Subsystem In Context (1 of 2) subsystem interface : Student : Register. For Courses. Form : Registration Controller : ICourse. Catalog System : Schedule : Student 1: // create schedule( ) Student wishes to create a new schedule 2: // get course offerings( ) 3: get. Course. Offerings(Semester) 4: // display course offerings( ) A list of the available course offerings for this semester are displayed subsystem responsibility • This 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 Note: I have ‘cut’ a lot of detail task of creating local interactions out of this sequence diagram and within the subsystem. the next one so that it is ‘easy’ to see thrust of this slide… 18

Example: Course. Catalog. System Subsystem In Context (2 of 2) subsystem interface : Student : Register. For Courses. Form : Registration Controller : ICourse. Catalog System : Schedule : Student 1: // create schedule( ) 2: // get course offerings( ) 3: get. Course. Offerings(Semester) subsystem responsibility Legacy RDBMS Database Access • The ICourse. Catalog. System: : get. Course. Offerings() documentation specifies: “Retrieve the course offerings available for the specified semester. ” • So retrieval of the course offerings from legacy database is responsibility of Course. Catalog system. • Now, must show exactly HOW this is done using the RDBMS persistency mechanism. This will be shown when we actually do the subsystem design (ahead) 19