1. Architectural Analysis These slides are derived from IBM/Rational slides from courses on UML and object-oriented design and analysis. Copyright to the original slides resides with IBM/Rational. They are used here, in this course, under password protection limited to students enrolled in the course, with permission of the owners, but are not to be published or further distributed.

2. What Is Architecture? Software architecture encompasses a set of significant decisions about the organization of a software system. – Selection of the structural elements and their interfaces by which a system is composed – Behavior as specified in collaborations among those elements – Composition of these structural and behavioral elements into larger subsystems – Architectural style that guides this organization Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational (derived from Mary Shaw)

3. Architecture Constrains Design and Implementation Architecture involves a set of strategic design decisions, rules or patterns that constrain design and construction. Architecture decisions are the most fundamental decisions, and changing them will have significant effects. Architecture Design Implementation Code`1 `

4. Software Architecture: The “4+1 View” Model Process ViewDeployment View Logical View Use-Case View Implementation View End-user Functionality Programmers Software management Performance, scalability, throughput System integrators System topology, delivery, installation, communication System engineering Analysts/Designers Structure

5. Analysis and Design Workflow Analysis Design [Early Elaboration Iteration] [Inception Iteration (Optional)] Define a Candidate Architecture Perform Architectural Synthesis Analyze Behavior Refine the Architecture Design Components Design the Database (Optional)

6. Analysis and Design Activity Overview Architect Designer

7. Software Architect’s Responsibilities Architect Software Architecture Document The Software Architect leads and coordinates technical activities and artifacts. Reference Architecture Analysis ModelDesign Model Deployment ModelImplementation Model

8. Designer’s Responsibilities Designer Use-Case Realization Package Class/Subsystems The designer must know use- case modeling techniques, system requirements, and software design techniques.

9. Review: Analysis and Design Is Use-Case Driven Use cases defined for a system are the basis for the entire development process. Benefits of use cases: – Concise, simple, and understandable by a wide range of stakeholders. – Help synchronize the content of different models. Withdraw Money Check Balance Customer

10. What Is a Use-Case Realization? Class Diagrams Use Case Communication Diagrams Use-Case ModelDesign Model Use CaseUse-Case Realization Sequence Diagrams (Traceability)

11. Analysis and Design in an Iterative Process Iteration n Iteration n + 1 Use Case A Scenarios 1 & 2 Use-Case Realization A Start of iteration End of iteration Use Case B Scenario 1 Use-Case Realization A Use Case A Scenario 3 Use-Case Realization B

12. Review What is the purpose of the Analysis and Design Discipline? What are the input and output artifacts? Name and briefly describe the 4+1 Views of Architecture. What is the difference between Analysis and Design? What is architecture?

13. ARCHITECTURAL ANALYSIS

14. KEY CONCEPTS

15. Architectural Analysis in Context [Early Elaboration Iteration] [Inception Iteration (Optional)] Define a Candidate Architecture Perform Architectural Synthesis Analyze Behavior Refine the Architecture Design Components Design the Database (Optional) Architecture Analysis` Architect

16. Architectural Analysis Overview Supplementary Specification Glossary Use-Case Model Architectural Analysis Design Model Reference Architecture Deployment Model Vision Document Software Architecture Doc Project-Specific Guidelines

17. Architectural Analysis Steps Key Concepts Define the High-Level Organization of Subsystems Identify Analysis mechanisms Identify Key Abstractions Create Use-Case Realizations Checkpoints

18. A package is a general-purpose mechanism for organizing elements into groups. It is a model element that can contain other model elements. A package can be used: – To organize the model under development. – As a unit of configuration management. – To cope with complexity. Review: What Is a Package? UniversityArtifacts

19. Packages can be related to one another using a dependency relationship. Dependency Implications – Changes to the Supplier package may affect the Client package. – The Client package cannot be reused independently because it depends on the Supplier package. Package Relationships: Dependency Client PackageSupplier Package Dependency relationship

20. Package Diagram for 5 Layers A package diagram shows packages only

21. C A B Hierarchy should be acyclic A B C A' Circular dependencies make it impossible to reuse one package without the other. Avoiding Circular Dependencies A B

22. Architectural Analysis Steps Key Concepts Define the High-Level Organization of Subsystems Identify Analysis mechanisms Identify Key Abstractions Create Use-Case Realizations Checkpoints

23. Patterns and Frameworks Pattern – Provides a common solution to a common problem in a context Analysis/Design pattern – Provides a solution to a narrowly-scoped technical problem – Provides a fragment of a solution, or a piece of the puzzle Framework – Defines the general approach to solving the problem – Provides a skeletal solution, whose details may be Analysis/Design patterns

24. Structural AspectBehavioral Aspect What Is a Design Pattern? A solution to a common design problem. – Describes a common design problem – Describes the solution to the problem – Discusses the results and trade-offs of applying the pattern Provides the capability to reuse successful designs. Parameterized Collaboration Pattern Name Template Parameters

25. What Is an Architectural Pattern? An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them – Buschman et al, “Pattern-Oriented Software Architecture — A System of Patterns” – Layers – Model-view-controller (M-V-C) – Pipes and filters – Blackboard

26. EVOLVING THE ANALYSIS MODELS INTO DESIGN MODELS

27. Factoring Creating modules that account for similarities and differences between units of interest New classes – Generalization – Aggregation Abstracting Refinement

28. Partitions and Collaborations Creating “subsystems” or larger units Grouping units that collaborate May have collaboration among units or partitions The more messages or contracts between objects, the more likely they are in the same partition

29. Layers Consider system environment information to help evolve the analysis model Model-view-controller (MVC) architecture Separating application logic from user interface logic

30. Typical Layering Approach General functionality Specific functionality Distinct application subsystems that make up an application — contains the value adding software developed by the organization. Business specific — contains a number of reusable subsystems specific to the type of business. Middleware — offers subsystems for utility classes and platform-independent services for distributed object computing in heterogeneous environments and so on. System software — contains the software for the actual infrastructure such as operating systems, interfaces to specific hardware, device drivers, and so on. Application Subsystems Business-Specific Middleware System Software

31. Example: Layers Application PresentationSessionTransportNetworkData LinkPhysical Layer 7 Layer 6 Layer 5 Layer 4 Layer 3 Layer 2 Layer 1 Provides miscellaneous protocols for common activities Structure information and attaches semantics Provides dialog control and synchronization facilities Breaks messages into packets and guarantees delivery Selects a route from send to receiver Detects and corrects errors in bit sequences Transmits bits: velocity, bit-code, connection, etc.

32. Architectural Pattern: Layers Equipment and customer-specificcode Processes and other application code Major abstractions, classes, etc. Mechanisms,services H/W specific code, O/S specific code, general- purpose code (for example, ORB, MQS) 5 4 3 2 1 Application Framework Application Framework Infrastructure

33. Dennis et al. : 5 Layers 1.Foundation 2.Problem Domain 3.Data Management 4.Human-Computer Interaction 5.Physical Architecture Are these in a logical order?

34. Layering Considerations Level of abstraction – Group elements at the same level of abstraction Separation of concerns – Group like things together – Separate disparate things – Application vs. domain model elements Resiliency – Loose coupling – Concentrate on encapsulating change – User interface, business rules, and retained data tend to have a high potential for change

35. Modeling Architectural Layers Architectural layers can be modeled using stereotyped packages. > stereotype Package Name >

36. Class > What Are Stereotypes? Stereotypes define a new model element in terms of another model element. Sometimes you need to introduce new things that speak the language of your domain and look like primitive building blocks. Stereotype

37. Example: High-Level Organization of the Model Application > Business Services >

38. Architectural Analysis Steps Key Concepts Define the High-Level Organization of the model Identify Analysis mechanisms Identify Key Abstractions Create Use-Case Realizations Checkpoints

39. Architect Supplementary Specification Use-Case Model Mechanisms COTS Products Databases IPC Technology, etc. “realized by client classes using” “responsible for” “constrained by” Required Functionality Implementation Environment What Are Architectural Mechanisms ?

40. Architectural Mechanism Categories Analysis mechanisms (conceptual) Design mechanisms (concrete) Implementation mechanisms (actual)

41. Why Use Analysis Mechanisms? Oh no! I found a group of classes that has persistent data. How am I supposed to design these things if I don’t even know what database we are going to be using? That is why we have a persistence analysis mechanism. We don’t know enough yet, so we can bookmark it and come back to it later. Analysis mechanisms are used during analysis to reduce the complexity of analysis and to improve its consistency by providing designers with a shorthand representation for complex behavior.

42. Sample Analysis Mechanisms Persistency Communication (IPC and RPC) Message routing Distribution Transaction management Process control and synchronization (resource contention) Information exchange, format conversion Security Error detection / handling / reporting Redundancy Legacy Interface

43. Examples of Analysis Mechanism Characteristics Persistency mechanism – Granularity – Volume – Duration – Access mechanism – Access frequency (creation/deletion, update, read) – Reliability Inter-process Communication mechanism – Latency – Synchronicity – Message size – Protocol

44. Example: Analysis Mechanism Characteristics (continued) Legacy interface mechanism – Latency – Duration – Access mechanism – Access frequency Security mechanism – Data granularity – User granularity – Security rules – Privilege types Others

45. Collect all analysis mechanisms in a list Draw a map of classes to analysis mechanisms Identify characteristics of analysis mechanisms Model using collaborations Describing Analysis Mechanisms Classes Parsing Authentication Communication Persistency Analysis Mechanisms Flight Aircraft Mission Schedule Route Load

46. Example: Course Registration Analysis Mechanisms SecurityLegacy Interface PersistenceDistribution

47. Architectural Analysis Steps Key Concepts Define the High-Level Organization of the model Identify Analysis mechanisms Identify Key Abstractions Create Use-Case Realizations Checkpoints

48. What Are Key Abstractions? A key abstraction is a concept, normally uncovered in Requirements, that the system must be able to handle Sources for key abstractions  Domain knowledge  Requirements  Glossary  Domain Model, or the Business Model (if one exists)

49. Defining Key Abstractions Define analysis classes Model analysis classes and relationships on class diagrams – Include a brief description of an analysis class Map analysis classes to necessary analysis mechanisms

50. Example: Key Abstractions Student Professor ScheduleCourseCatalogCourseCourseOffering

51. Architectural Analysis Steps  Key Concepts  Define the High-Level Organization of the model  Identify Analysis mechanisms  Identify Key Abstractions  Create Use-Case Realizations  Checkpoints

52. Review: What is a Use-Case Realization? Class Diagrams Use Case Communication Diagrams Use-Case ModelDesign Model Use CaseUse-Case Realization Sequence Diagrams

53. The Value of Use-Case Realizations Provides traceability from Analysis and Design back to Requirements The Architect creates the Use-Case Realization Use Case Analysis & Design (Design Model) Requirements (Use-Case Model) Use-Case realization

54. Architectural Analysis Steps  Key Concepts  Define the High-Level Organization of the model  Identify Analysis mechanisms  Identify Key Abstractions  Create Use-Case Realizations  Checkpoints

55. Checkpoints General – Is the package partitioning and layering done in a logically consistent way? – Have the necessary analysis mechanisms been identified? Packages – Have we provided a comprehensive picture of the services of the packages in upper-level layers?

56. Checkpoints (continued) Classes – Have the key entity classes and their relationships been identified and accurately modeled? – Does the name of each class clearly reflect the role it plays? – Are the key abstractions/classes and their relationships consistent with the Business Model, Domain Model, Requirements, Glossary, etc.?

57. Review: Architectural Analysis What is the purpose of Architectural Analysis? What is a package? What is a layered architecture? Give examples of typical layers. What are analysis mechanisms? Give examples. What key abstractions are identified during Architectural Analysis? Why are they identified here?

58. Building Package Diagrams 1.Set the context 2.Cluster classes together based on shared relationships 3.Model clustered classes as a package 4.Identify dependency relationships among packages 5.Place dependency relationships between packages

59. DESIGN STRATEGIES

60. Custom Development Allows for meeting highly specialized requirements Allows flexibility and creativity in solving problems Easier to change components Builds personnel skills May tax firm’s resources May add significant risk

61. Packaged Software Software already written May be more efficient May be more thoroughly tested and proven May range from components to tools to whole enterprise systems Must accept functionality provided May require change in how the firm does business May require significant “customization” or “workarounds”

62. System Integration The process of combining packages, legacy systems, and new software Key challenge is integrating data Write data in the same format Revise existing data formats Develop “object wrappers”

63. Outsourcing Hire external firm to create system May have more skills May extend existing resources Never outsource what you don’t understand Carefully choose vendor Prepare contract and payment style carefully

64. Selecting a Design Strategy Business need In-house experience Project skills Project management Time frame

65. Selecting a Design Strategy

66. DEVELOPING THE ACTUAL DESIGN

67. The Alternative Matrix Combines several feasibility analyses into one grid Revisits technical, economic, and organizational feasibility

68. Request for Proposals Description of the system you propose to be built Vendors, developers, service providers respond with proposals including how they will address needs as well as stating cost and time requirements.

69. Summary Verifying and Validating the Analysis Models Evolving the Analysis Models into Design Models Packages and Package Diagrams Design Strategies Developing the Actual Design

70. IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 7: Identify Design Elements

71. Objectives: Identify Design Elements Define the purpose of Identify Design Elements and demonstrate where in the lifecycle it is performed Analyze interactions of analysis classes and identify Design Model elements – Design classes – Subsystems – Subsystem interfaces

72. Identify Design Elements in Context [Early Elaborati on Iteration] [Inception Iteration (Optional)] Define a Candidate Architecture Perform Architect ural Synthesis Analyze Behavior Refine the Archite cture Design Compo nents Design the Databa se (Opti onal) Identify Design Elements Architect

73. Supplementary Specifications Identify Design Elements Software Architecture Document Design Model Identify Design Elements Overview Analysis Model Project Specific Guidelines

74. Identify Design Elements Steps Identify classes and subsystems Identify subsystem interfaces Update the organization of the Design Model Checkpoints

75. Identify Design Elements Steps  Identify classes and subsystems  Identify subsystem interfaces  Identify reuse opportunities  Update the organization of the Design Model  Checkpoints Analysis Classes

76. From Analysis Classes to Design Elements Analysis ClassesDesign Elements > Many-to-Many Mapping Subsystem > Subsystem >

77. Identifying Design Classes An analysis class maps directly to a design class if: – It is a simple class – It represents a single logical abstraction More complex analysis classes may – Split into multiple classes – Become a package – Become a subsystem (discussed later) – Any combination …

78. 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 Review: Class and Package Package Name Class Name

79. You can base your packaging criteria on a number of different factors, including: – Configuration units – Allocation of resources among development teams – Reflect the user types – Represent the existing products and services the system uses Package C Group Design Classes in Packages Package BPackage A

80. Packaging Tips: Boundary Classes If it is likely the system interface will undergo considerable changes Boundary classes placed in separate packages If it is unlikely the system interface will undergo considerable changes Boundary classes packaged with functionally related classes

81. Packaging Tips: Functionally Related Classes Criteria for determining if classes are functionally related: – Changes in one class' behavior and/or structure necessitate changes in another class – Removal of one class impacts the other class – Two objects interact with a large number of messages or have a complex intercommunication – A boundary class can be functionally related to a particular entity class if the function of the boundary class is to present the entity class – Two classes interact with, or are affected by changes in the same actor

82. Packaging Tips: Functionally Related Classes (continued)  Criteria for determining if classes are functionally related (continued):  Two classes have relationships between each other  One class creates instances of another class  Criteria for determining when two classes should NOT be placed in the same package:  Two classes that are related to different actors should not be placed in the same package  An optional and a mandatory class should not be placed in the same package

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

84. A B X Package Coupling: Tips Packages should not be cross-coupled Packages in lower layers should not be dependent upon packages in upper layers In general, dependencies should not skip layers AB Upper Layer Lower Layer C X X = Coupling violation X

85. Example: Registration Package MainRegistrarForm 1 11 MainStudentForm 1 RegisterForCoursesForm > 0..1 11 CloseRegistrationForm > 0..1 CloseRegistrationController > RegistrationController > 1

86. FulltimeStudent > ParttimeStudent > PrimaryScheduleOfferingInfo > ScheduleOfferingInfo > Student > Example: University Artifacts Package: Generalization

87. Student > Professor > Schedule > CourseOffering > CourseOfferingList 1 Prerequisites 0..* Course > 0..* 1 instructor 0..1 0..* 0..4 primaryCourses 0..* 0..2 alternateCourses 0..* 1 Example: University Artifacts Package: Associations

88. IBillingSystem > ICourseCatalogSystem > Example: External System Interfaces Package

89. Realizes one or more interfaces that define its behavior Subsystem Review: Subsystems and Interfaces Interface Realization (Canonical form) Realization (Elided form) Interface Name Subsystem Name > Interface Name > Subsystem Name >

90. Subsystems and Interfaces (continued) Subsystems : – Completely encapsulate behavior – Represent an independent capability with clear interfaces (potential for reuse) – Model multiple implementation variants InterfaceK X() W() > SubsystemA > SubsystemB > ClassA1 W() ClassA2 X() ClassB1 W() Y() ClassB2 X() ClassB3 Z()

91. Encapsulation is the key! Packages versus Subsystems Subsystems – Provide behavior – Completely encapsulate their contents – Are easily replaced Subsystem A > Package B ClassB1 ClassB2 Packages  Don’t provide behavior  Don’t completely encapsulate their contents  May not be easily replaced Client Class

92. Subsystems raise the level of abstraction. Subsystem Usage Subsystems can be used to partition the system into parts that 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)

93. 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.

94. 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 Candidate Subsystems Subsystem A > Subsystem B > Subsystem C >

95. Identifying Subsystems > ClassA X() W() X() W() > “Superman Class” InterfaceK SubsystemA > ClassA1 X() ClassA2 W()

96. Identify Design Elements Steps  Identify classes and subsystems  Identify subsystem interfaces  Identify reuse opportunities  Update the organization of the Design Model  Checkpoints

97. Stable, well-defined interfaces are key to a stable, resilient architecture. 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.

98. Interface Guidelines Interface name – Reflects role in system Interface description – Conveys responsibilities Operation definition – Name should reflect operation result – Describes what operation does, all parameters and result Interface documentation – Package supporting info: sequence and state diagrams, test plans, etc.

99. All other analysis classes map directly to design classes. AnalysisDesign Example: Design Subsystems and Interfaces BillingSystem //submit bill() > Billing System > IBillingSystem submitBill(forTuition : Double, forStudent : Student) CourseCatalogSystem //get course offerings() > Course Catalog System > ICourseCatalogSystem getCourseOfferings(forSemester : Semester, forStudent : Student) : CourseOfferingList initialize()

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

101. Interfaces start with an “I” Modeling Convention: Subsystems and Interfaces CourseCatalogSystem > ICourseCatalogSystem + initialize () + getCourseOfferings () CourseCatalogSystem > + initialize () + getCourseOfferings () ICourseCatalogSystem > + getCourseOfferings () + initialize ()

102. Example: Subsystem Context: CourseCatalogSystem Provided interface defined ICourseCatalogSystem > CloseRegistrationController + // is registration open?() + // close registration() > 0..1 +courseCatalog CourseCatalogSystem > + initialize () + getCourseOfferings () + getCourseOfferings ( for Semester: Semester ) + initialize () RegistrationController + getCurrentSchedule() + deleteCurrentSchedule() + submitSchedule() + saveSchedule() + getCourseOfferings() + setSession() + > new() + getStudent() > CourseOfferingList + new() + add() 1 Required interface defined

103. Example: Subsystem Context: Billing System IBillingSystem + submitBill(forStudent : Student, forTuition : double) > 1 0..1 + Biller 1 Student > CloseRegistrationController + // is registration open?() + // close registration() > BillingSystem > + submitBill(forStudent : Student, forTuition : double)

104. Identify Design Elements Steps  Identify classes and subsystems  Identify subsystem interfaces  Identify reuse opportunities  Update the organization of the Design Model  Checkpoints

105. Identification of Reuse Opportunities Purpose – To identify where existing subsystems and/or components can 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

106. Software 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 Software

107. ? Reuse Opportunities Internal to System

108.  Identify classes and subsystems  Identify subsystem interfaces  Identify reuse opportunities  Update the organization of the Design Model  Checkpoints ClassB Y() Z() ClassA Y() Z() Identify Design Elements Steps ClassC Y() Z() ClassD Y() Z() ClassC Y() Z() ClassE Y() Z()

109. Review: Typical Layering Approach General functionality Specific functionality Distinct application subsystems that make up an application — contains the value adding software developed by the organization. Business specific — contains a number of reusable subsystems specific to the type of business. Middleware — offers subsystems for utility classes and platform-independent services for distributed object computing in heterogeneous environments and so on. System software — contains the software for the actual infrastructure such as operating systems, interfaces to specific hardware, device drivers, and so on. Application Business-Specific Middleware System Software

110. Goal is to reduce coupling and to ease maintenance effort. Layering Considerations 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

111. Layer 1 Layer 2 Layer 3 Design Elements and the Architecture

112. Example: Architectural Layers Middleware > Base Reuse global Application > Business Services > Necessary because the Application Layer must have access to the core distribution mechanisms provided with Java RMI.

113. Partitioning Considerations Coupling and cohesion User organization Competency and/or skill areas System distribution Secrecy Variability Try to avoid cyclic dependencies.

114. B A Package A Package B Example: Partitioning

115. Registration > Application Example: Application Layer

116. Security GUI Framework Secure Interfaces Application > Business Services > Application > Business Services Example: Application Layer Context University Artifacts Registration External System Interfaces

117. Example: Business Services Layer CourseCatalogSystem > External System Interfaces University Artifacts ObjectStore Support > Business Services GUI Framework Secure Interfaces Security > Security Manager BillingSystem >

118. Middleware > Business Services > Example: Business Services Layer Context java.sqlcom.odi > Middleware BillingSystem > CourseCatalogSystem > External System Interfaces University Artifacts ObjectStore Support > Business Services GUI Framework Secure Interfaces Security > Security Manager

119. com.odi Database (from com.odi) Session (from com.odi) Transaction (from com.odi) Map (from com.odi) java.sql ResultSet (from com.odi) Connection (from com.odi) Statement (from com.odi) DriverManager (from com.odi) Example: Middleware Layer > Middleware

120. Identify Design Elements Steps  Identify classes and subsystems  Identify subsystem interfaces  Identify reuse opportunities  Update the organization of the Design Model  Checkpoints

121. Checkpoints General – Does it provide a comprehensive picture of the services of different packages? – Can you find similar structural solutions that can be used more widely in the problem domain? Layers – Are there more than seven layers? Subsystems – Is subsystem partitioning done in a logically consistent way across the entire model?

122. Checkpoints (continued) Packages – Are the names of the packages descriptive? – Does the package description match with the responsibilities of contained classes? – Do the package dependencies correspond to the relationships between the contained classes? – Do the classes contained in a package belong there according to the criteria for the package division? – Are there classes or collaborations of classes within a package that can be separated into an independent package? – Is the ratio between the number of packages and the number of classes appropriate?

123. Checkpoints (continued) Classes – Does the name of each class clearly reflect the role it plays? – Is the class cohesive (i.e., are all parts functionally coupled)? – Are all class elements needed by the use-case realizations? – Do the role names of the aggregations and associations accurately describe the relationship? – Are the multiplicities of the relationships correct?

124. Review: Identify Design Elements What is the purpose of Identify Design Elements? What is an interface? What is a subsystem? How does it differ from a package? What is a subsystem used for, and how do you identify them? What are some layering and partitioning considerations?