Object Oriented Analysis and Design Using the UML Version 4.2

1. Object Oriented Analysis and Design Using the UMLVersion 4.2 Module 8: Architectural Design

2. Objectives: Architectural Design • Understand the purpose of Architectural Design and where in the lifecycle it is performed • Explain what Design and Implementation Mechanisms are and how they map from Analysis Mechanisms • Understand what subsystems and interfaces are and what role they play in the architecture • Describe the process for identifying interfaces and subsystems • Understand the rationale and considerations that support the architectural decisions

3. Architectural Design in Context Architectural Analysis Review the Architecture Describe Architectural Describe Architecture Reviewer Architect Concurrency Design Distribution Subsystem Design Use-Case Analysis Review the Use-Case Design Design Design Designer Reviewer Class Design

4. Software Architecture Document Analysis Classes Design Model Design Model Supplementary Specifications DesignGuidelines DesignGuidelines Glossary Architectural Design Overview ArchitecturalDesign

5. Architectural Design Topics • Key Concepts • Design and Implementation Mechanisms • Design Classes and Subsystems • Reuse Opportunities • Design Model Organization • Checkpoints

6. Architectural Design Topics • Key Concepts • Design and Implementation Mechanisms • Design Classes and Subsystems • Reuse Opportunities • Design Model Organization • Checkpoints

7. End-user Functionality LogicalView Implementation View Programmers Software management Analysts/Designers Structure Use-Case View Process View Deployment View System engineering System integrators System topology Delivery, installation communication Performance Scalability Throughput The “4+1 View” Architecture Model The Logical View is an “architecturally significant” slice of the Design Model

8. Class Name Package Name Review: Class and Package • What is a class? • A description of a set of objects that share the same responsibilities, relationships, operations, attributes, and semantics. • What is a package? • A general purpose mechanism for organizing elements into groups • A model element which can contain other model elements

9. Foundation Classes global Global Packages • Certain packages are used by all other packages • These packages are marked global

10. Architectural Design Topics • Key Concepts • Design and Implementation Mechanisms • Design Classes and Subsystems • Reuse Opportunities • Design Model Organization • Checkpoints

11. Analysis Mechanism (Conceptual) Design Mechanism (Concrete) Implementation Mechanism (Actual) Legacy Data Persistency RDBMS JDBC New Data ObjectStore OODBMS Persistency Remote Method Invocation (RMI) Distribution Java 1.2 from Sun Analysis Design Implementation Design and Implementation Mechanisms

12. Pattern Name TemplateParameters Documenting Architectural Mechanisms • Architectural Mechanisms can be treated as patterns (i.e., stereotyped parameterized collaboration) Behavioral Aspect Structural Aspect Documented in Design Guidelines

13. Statement (from java.sql) executeQuery(sql : String) : ResultSet executeUpdate(sql : String) : int Example: Persistency: RDBMS: JDBC Roles to be filled by the designer applying the mechanism <<role>> <<role>> PersistencyClient PersistentClassList (from SamplePersistency Client) (from SamplePersistentClass) new() add(c: PersistentClass) <<role>> DBClass 1 1 0..* 0..* create() : PersistentClass <<role>> read(searchCriteria : string) : PersistentClassList PersistentClass update(c : PersistentClass) (from SamplePersistentClass) delete(c : PersistentClass) getData() 1 setData() command() new() DriverManager (from java.sql) 1 getConnection(url, user, pass) : Connection Connection ResultSet (from java.sql) (from java.sql) createStatement() : Statement getString() : string

14. Example: Persistency: RDBMS: JDBC: Initialize : DBClass : DriverManager 1. getConnection(url, user, pass)

15. 1.4. executeUpdate(String) Example: Persistency: RDBMS: JDBC: Create : : DBClass : : Connection : Statement PersistencyClient PersistentClass 1. create( ) 1.1. New() 1.2. getData( ) 1.3. createStatement( )

16. The SQL statement built by the DBClass using the given criteria is passed to The criteria used to executeQuery() access data for the persistent class Example: Persistency: RDBMS: JDBC: Read : : DBClass : Connection : Statement : ResultSet : : PersistencyClient PersistentClassList PersistentClass returns a 1. read(string) Statement 1.1. createStatement( ) 1.2. executeQuery(string) Create a list to hold all 1.3. new( ) retrieved data 1.4. new() Repeat these operations for each element returned from 1.5. getString( ) the executeQuery() called for each command. attribute in the 1.6. setData( ) class The PersistentClassList is loaded with the data retrieved 1.7. add(PersistentClass) from the database. Add the retrieved course offering to the list to be returned

17. execute SQL statement 1.3. executeUpdate(string) Example: Persistency: RDBMS: JDBC: Update : : DBClass : : Connection : Statement PersistencyClient PersistentClass 1. update(PersistentClass) 1.1. getData( ) 1.2. createStatement( )

18. Example: Persistency: RDBMS: JDBC: Delete : : DBClass : Connection : Statement PersistencyClient 1. delete(PersistentClass) 1.1. createStatement( ) execute SQL statement 1.2. executeUpdate(string)

19. 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 • Incorporate DBClasses into the design • Allocate to package/layer • Add relationships from persistency clients • Create/Update interaction diagrams that describe: • Database initialization • Persistent class access: Create, Read, Update, Delete Deferred

20. Sample Persistency Client Package DriverManager (from java.sql) Example: Incorporating JDBC java.sql Connection (from java.sql) Statement ResultSet (from java.sql) (from java.sql)

21. Architectural Design Topics • Key Concepts • Design and Implementation Mechanisms • Design Classes and Subsystems • Reuse Opportunities • Design Model Organization • Checkpoints

22. <<boundary>> <<control>> <<entity>> <<boundary>> From Analysis Classes to Design Elements Analysis Classes Design Elements Many-to-Many Mapping

23. Identifying Design Classes • Analysis class maps directly to a design class if: • Simple • Represents a single logical abstraction • More complex analysis classes may • Split into multiple classes • Become a package • Become a subsystem (discussed later) • Any combination … • Simple analysis classes may become one design class

24. PackageA +Class B1 Class A1 Class A3 -Class B2 Class A2 Package Dependencies: Package Element Visibility A Only public classes can be referenced outside of the owning package PackageB B Public visibility Private visibility OO Principle: Encapsulation

25. <<subsystem>> Subsystem Name <<interface>> Interface <<subsystem>> Subsystem Name Review: Subsystems and Interfaces • A “cross between” a package (can contain other model elements) and a class (has behavior) • Realizes one or more interfaces which define its behavior Realization (Canonical form) Interface Subsystem Interface Realization (Elided form)

26. Class B2 Class B3 Class B1 Class A2 Class A1 W() Y() X() Z() W() X() <<Interface>> InterfaceK X() W() Subsystems and Interfaces (cont.) • Subsystems : • Completely encapsulate behavior • Represent an independent capability with clear interfaces (potential for reuse) • Model multiple implementation variants <<subsystem>> SubsystemA <<subsystem>> SubsystemB

27. Client Class Class B1 Class B2 Packages Vs. Subsystems • Subsystems provide behavior, packages do not • Subsystems completely encapsulate their contents, packages do not • Subsystems are easily replaceable PackageB <<subsystem>> A Encapsulation is the key!

28. Subsystem Usage • Subsystems can be used to partition the system into parts which can be independently: • ordered, configured, or delivered • developed, as long as the interfaces remain unchanged • deployed across a set of distributed computational nodes • changed without breaking other parts of the systems • Subsystems can also be used to: • partition the system into units which can provide restricted security over key resources • represent existing products or external systems in the design (e.g. components) Subsystems raise the level of abstraction

29. Identifying Subsystems Hints • Look at object collaborations • Look for optionality • Look to the user interface of the system • Look to the Actors • Look for coupling and cohesion between classes • Look at substitution • Look at distribution • Look at volatility

30. Candidate Subsystems • Analysis classes which may evolve into subsystems • Classes providing complex services and/or utilities • Boundary classes (user interfaces and external system interfaces) • Existing products or external systems in the design (e.g. components) • Communication software • Database access support • Types and data structures • Common utilities • Application-specific products

31. ClassA Y() Z() Identifying Subsystems “Superman Class” <<Interface>> InterfaceA <<subsystem>> SubsystemK Y() Z() ?

32. Identifying Interfaces • Purpose • To identify the interfaces of the subsystems based on their responsibilities • Steps • Identify a set of candidate interfaces for all subsystems • Look for similarities between interfaces • Define interface dependencies • Map the interfaces to subsystems • Define the behavior specified by the interfaces • Package the interfaces Stable, well-defined interfaces are key to a stable, resilient architecture

33. Interface Guidelines • Interface name • Reflect role in system • Interface description • Convey responsibilities • Operation definition • Name should reflect operation result • Describe what operation does, all parameters and result • Interface documentation • Package supporting info: sequence and state diagrams, test plans, etc.

34. <<boundary>> <<subsystem>> <<subsystem>> BillingSystem CourseCatalogSystem BillingSystem // submit bill() <<boundary>> CourseCatalogSystem // get course offerings() ICourseCatalogSystem Example: Design Subsystems Analysis Design IBillingSystem submitBill(forTuition : Double, forStudent : Student) getCourseOfferings(forSemester : Semester) : CourseOfferingList All other analysis classes map directly to design classes

35. Example: Analysis-Class-To-Design-Element Map Analysis Class Design Element CourseCatalogSystem CourseCatalogSystem Subsystem BillingSystem Subsystem BillingSystem All other analysis classes map directly to design classes

36. <<subsystem>> CourseCatalogSystem <<subsystem proxy>> CourseCatalogSystem ICourseCatalogSystem Modeling Convention: Subsystems and Interfaces <<subsystem>> CourseCatalogSystem ICourseCatalogSystem <<subsystem>> package <<subsystem proxy>> class Interfaces start with an “I”

37. CourseOfferingList Example: Subsystem Context: CourseCatalogSystem <<control>> RegistrationController <<control>> CloseRegistrationController // get course offerings() // get current schedule() // delete current schedule() // is registration open?() // submit schedule() // close registration() // is registration open?() // save schedule() 0..1 // create schedule with offerings() // update schedule with new selections() 0..* Interface defined courseCatalog courseCatalog 1 1 <<Interface>> ICourseCatalogSystem getCourseOfferings(forSemester : Semester) : CourseOfferingList <<subsystem proxy>> CourseCatalogSystem getCourseOfferings(forSemester : Semester) : CourseOfferingList

38. <<control>> CloseRegistrationController // is registration open?() // close registration() Example: Subsystem Context: Billing System 0..1 +Biller 1 <<Interface>> <<entity>> IBillingSystem Student submitBill(forTuition : Double, forStudent : Student) <<subsystem proxy>> BillingSystem submitBill(forStudent : Student, forTuition : double)

39. Exercise: Architectural Design, Part 1 • Given the following: • The analysis classes and their relationships

40. Exercise: Architectural Design, Part 1 (cont.) • Identify the following • Subsystems, their interfaces and their relationships with other design elements • The mapping from the analysis classes to the design elements (continued)

41. Exercise: Architectural Design, Part 1 (cont.) • Produce the following diagrams: • For each subsystem, a subsystem context class diagram • Table mapping analysis classes to design elements

42. Architectural Design Topics • Key Concepts • Design and Implementation Mechanisms • Design Classes and Subsystems • Reuse Opportunities • Design Model Organization • Checkpoints

43. Identification of Reuse Opportunities • Purpose • To identify where existing subsystems and/or components may be reused based on their interfaces. • Steps • Look for similar interfaces • Modify new interfaces to improve the fit • Replace candidate interfaces with existing interfaces • Map the candidate subsystem to existing components

44. Possible Reuse Opportunities • Internal to the system being developed • Recognized commonality across packages and subsystems • External to the system being developed • Commercially available components • Components from a previously developed application • Reverse engineered components

45. Reuse Opportunities Internal to System ?

46. Architectural Design Topics • Key Concepts • Design and Implementation Mechanisms • Design Classes and Subsystems • Reuse Opportunities • Design Model Organization • Checkpoints

47. Typical Layering Approach Specific functionality General functionality

48. Layering Guidelines • Visibility • Dependencies only within current layer and below • Volatility • Upper layers affected by requirements changes • Lower layers affected by environment changes • Generality • More abstract model elements in lower layers • Number of layers • Small system: 3-4 layers • Complex system: 5-7 layers Goal is to reduce coupling and to ease maintenance effort

49. <<boundary>> <<boundary>> <<boundary>> <<control>> <<control>> <<control>> <<control>> <<entity>> <<entity>> <<entity>> <<entity>> <<entity>> Design Elements and the Architecture Layer 1 Layer 2 Layer 3

50. <<layer>> Application <<layer>> Business Services Example: Architectural Layers <<layer>> Middleware Base Reuse global