DesignRole of DesignDesign Model HierarchyDifference Between Analysis and Design ModelsExampleDesign as Use Case RealizationDesign SubsystemsArchitectural View of Design ModelDeployment ModelArchitectural DesignI/O of Architectural DesignIdentifying Nodes and Network ConfigurationsSlide 13Identifying Subsystems and InterfacesMiddleware LayerIdentifying Subsystem InterfacesIdentifying Active ClassesIdentifying Generic Design MechanismsExample: Generic Collaboration Used in Several Use Case RealizationsMapping to Invoice Buyer Use CaseDesign Use CaseIdentifying Participating Design ClassesPay Invoice Use Case RealizationDescribe Object InteractionsSlide 25Identifying Participating Subsystems and InterfacesDesign a ClassSlide 281Design2Role of DesignDevelop blueprints for implementationQ: What does this mean?3Design Model Hierarchy4Difference Between Analysis and Design Models5Example6Design as Use Case Realization•Collaboration within design model describes how a use case is realized•Should maintain traceability to use case realization in analysis model•Provides physical realization of the use case and handles non-functional requirements7Design Subsystems•Subsystems organizes system into manageable pieces•Subsystems can be very large and hierarchical•But, a subsystem should be cohesive, and they should be loosely coupled•Top level subsystems normally have direct trace to analysis packages•Can represent reused software products or legacy systems by wrapping them - means of integration8Architectural View of Design Model•Decomposition of design model into subsystems, their interfaces, and dependency between them - subsystems and their interfaces make up fundamental structure of software system•Key design classes - those trace to architecturally significant analysis classes, those general and central (e.g. abstract classes), those having many relationships•Designs that realize key use cases9Deployment Model•Object model describing physical distribution of system in terms of how functionality distributed among computational nodes–Each node a computational resource, e.g. processor –Nodes have relationship representing means of communication•Has major impact on design and implementation–Q. Why?10Architectural Design•Purpose is to outline the design and deployment models and their architecture by identifying:–Nodes and their network configurations–Subsystems and their interfaces–Architecturally significant classes–Generic design mechanisms handling common requirements, e.g. performance, persistency, distribution•Many possibilities to consider, need to weight what’s more important11I/O of Architectural Design12Identifying Nodes and Network Configurations•Network configuration often have major impact on system architecture, including active classes required and distribution of functionality among network nodes–Which nodes involved and what’s their processing power and memory size?–What types of connections between the nodes, and what protocols–Bandwidth, availability, quality?–Need for redundant capacity, fault tolerance, process migration, backup, etc.?13Example14Identifying Subsystems and Interfaces15Middleware Layer16Identifying Subsystem Interfaces•From subsystem dependencies•Inherit from analysis packages–analysis class interfaces that are referenced from another package17Identifying Active Classes•Performance, throughput, availability factors•System distribution onto nodes•System startup and termination, liveness, deadlock avoidance, starvation avoidance, reconfiguration of nodes, and capacity of connections•Q: what kind of objects most likely to be active objects?18Identifying Generic Design Mechanisms•Persistency•Transparent object distribution•Security features•Error detection and recovery•Transaction management•Concurrency control, etc.19Example: Generic Collaboration Used in Several Use Case Realizations20Mapping to Invoice Buyer Use Case21Design Use Case•Purpose:–Identify design classes and/or subsystems whose instances are needed to perform the use case flow of events–Distributed the behavior of the use case to interacting design objects and/or subsystems–Define requirements on the operations of design classes and/or subsystems and their interfaces–Capture implementation requirements for the use case22Identifying Participating Design Classes•Identify design classes that trace to those participating classes in the analysis model•Identify design classes that implement non-functional requirements–From analysis model–Discovered in the design process•Identify missing classes23Pay Invoice Use Case Realization24Describe Object Interactions•When use sequence diagrams–If there are multiple flows, use one sequence diagram for each flow–Should be based on object interaction defined in analysis model (traceability)–Each design class identified in the realization of the use case should have at least one object in the sequence diagram–Focus on sequence of interaction or message exchange–Should handle all relationships of the use case25Example26Identifying Participating Subsystems and Interfaces27Design a Class•Its operations•Attributes•Relationship it participates in•Methods (that realize the operations)•Its imposed states•Its dependency to any generic design mechanisms•Requirements relevant to its implementation•Correct realization of any interface it is required to