Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
310313 SOFTWARE ENGINEERING SYSTEM DESIGN 310313 SYSTEM DESIGN 1 LEARNING OBJECTIVES 1. Understand the role and importance of system design in the software development process. 2. Understand that system analysis and system design are intertwined activities. 3. Know some major architectural styles and design patterns for realizing system design goals. 4. Know the major activities that take place during system design 310313 SYSTEM DESIGN 2 SIGN OUTLINE SYSTEM The Unified Process and System Design — Overview – System Design — Life Cycle Role – Moving from System Analysis to System Design – The Importance of System Design – Some Design Considerrations The Unified Process — System Design Activities – Use-case Design – Class Design – Subsystem Design – Architectural Design 310313 SYSTEM DESIGN 3 LIFE CYCLE ROLE Core Workflows Phases Inception Elaboration Construction Transition Requirements Iteration Analysis Design Implementation Testing iter. #1 iter. #2 — — — — — iter. #n-1 iter. #n Increments 310313 SYSTEM DESIGN 4 ARTIFACTS & WORKERS Design Model 310313 Architect Use-Case Engineer Component Engineer responsible for responsible for responsible for Deployment Architecture Model Description Use-Case Realization —Design Design Class Interfaces Design Subsystem SYSTEM DESIGN 5 SYSTEM DESIGN : WORKERS The architect is responsible for the integrity and the architecture of the design and deployment models The use-case engineer is responsible for one or more usecase realizations—design. He makes all textual descriptions and diagrams describing the use-case realization readable and suited for their purpose The component engineer is defines and maintains the operations, methods, attributes, relationships and implementation of one or more design classes may also maintain the integrity of one or more subsystems 310313 SYSTEM DESIGN 6 SYSTEM DESIGN : ARTIFACTS The design model is describes the physical realization of a use case; focuses on how functional and nonfunctional requirements, together with implementation environment constraints, impact the system The deployment model is describes the physical distribution of the system in terms of how functionality is distributed among computational nodes The architecture description is contains the architecturally significant artifacts of the design model and all of the deployment model In the design model there are two views of architecture : the deployment model specifies the system architecture (physical). the design model specifies the software architecture (logical). 310313 SYSTEM DESIGN 7 SYSTEM DESIGN : ARTIFACTS A use-case realization—design - describes how a specific use case is realized and performed in terms of design classes and their objects A design class is an abstraction of a class or similar construct in the system’s implementation We use programming language to specify a design class A design subsystem - organizes artifacts of the design model into more manageable pieces An interface - specifies the operations provided by design classes and subsystems An interface separates operations from their implementation 310313 SYSTEM DESIGN 8 6 THE PURPOSE OF SYSTEM DESIGN To adapts the logical structure of the Analysis Model to the implementation environment and prepares for implementation When to transition from system analysis to system design? The system is gradually structured into basic “parts” with welldefined relationships among them in two stages: 1. building the skeleton is the process by which the parts come together to produce a stable basis. The skeleton is provided by the software architecture. 2. growing the system is the process by which the parts aggregate around the skeleton to produce a finer system structure. The growing is accomplished by the analysis and design workflows. 310313 SYSTEM DESIGN 9 FROM SYSTEM ANALYSIS TO SYSTEM DESIGN Analysis and design activities may be combined in various ways. 310313 SYSTEM DESIGN 10 THE IMPORTANCE OF DESIGN Why not go straight to implementation? We need to consider issues preveiously ignored, such as : – the nonfunctional requirements – the implementation environment. the system must be adapted to the implementation environment Since the analysis model is not sufficiently formal so we need to: – refine analysis classes – determine operations – determine how classes should communicate we also want to validate the analysis results 310313 How well do the Analysis Model and the Requirements Model describe the system? What is not yet clear? SYSTEM DESIGN 11 ANALYSIS MODEL Conceptual model Generic –> many designs possible DESIGN MODEL Physical model Specific –> for one implementation Less formal More formal Less expensive to develop More expensive to develop Package have few layers Subsystem have many layers Focus is on interactions Focus is on sequence Outline of design Implementation of design Created by developer meetings Created by software engineering environments May not be maintained Should be maintained 310313 SYSTEM DESIGN 12 6.2 REALIZING DESIGN GOALS We need to decide how system design goals wiill be realized. Design goals come mainly from nonfunctional requirements(i.e., system qualities we try to optimize) Design goals guide the decisions made by developers, especially when implementation trade-offs are needed usually only a small subset of the nonfunctional requirements can be considered simultaneously THEREFORE we need to prioritize design goals and possibly develop trade-offs against each other as well as against managerial goals (e.g., schudule, budget) Examples: space vs. speed; delivery time vs. functionality, etc. 310313 SYSTEM DESIGN 13 6.4.2 DESIGN GOALS — SOME DESIRABLE QUALITIES Performance response time throughput memory Dependability robustness reliability availability fault tolerance security safety End user Maintenance extensibility modifiability adaptability portability readability Cost development deployment upgrade maintenance administration traceability utility usability 310313 SYSTEM DESIGN 14 6.4.4 REALIZING DESIGN GOALS : IMPLEMENTATION ENVIRONMENT Need to consider the technical and managerial constraints under which the system should be built What hardware/software will the system run on? – hardware (limitations) – distribution What programming language will be used? – OO, non-OO – memory management What existing software do we need to use? – DBMS – UIMS – system software – network facilities – legacy systems What development people/organizations will be involved? – distributed location 310313 – team competencies SYSTEM DESIGN 15 REALIZING DESIGN GOALS : IMPLEMENTATION ENVIRONMENT (cont’d) General design strategy: localize and encapsulate implementation environment To accomplish this, we create “bridge” classes that represent occurrences of components in the implementation environment application system classes that require file access ? FileManager can use the Bridge design pattern FileManager WinXP Unix Mac-OS We often need to define many additional classes to deal with the implementation environment 310313 SYSTEM DESIGN 16 6.4.5 6.4.6 6.4.7 6.4.8 REALIZING DESIGN GOALS : SYSTEM-WIDE DESIGN ISSUES We need to develop consistent approaches to handle issues that have system-wide implications. data management — How is persistent data handled? files? relational DBMS? object-oriented DBMS? access control — How is access control specified and realized? global access table? access control list? capability? control flow — How is processing initiated and controlled? procedure-driven? event-driven? threaded? boundary conditions — How are system start-up, shutdown, failure and exceptions handled? administration use cases for start-up, shutdown, recovery exceptional handling mechanism for errors 310313 SYSTEM DESIGN 17 7.4.6 GENERIC DESIGN MECHANISMS A generic design mechanism is a well-tried solution to a common occing design requirements. architectural style/design pattern – a named, well-understood solution to a common problem in context What described in literary form – Help novices to learn by example to behave more like experts – Pattern catalog documents particular designs that are useful in a certain context framework – a reusable “chunk” of architecture – Describes how a collection of objects work together to implement How the structural part of, usually, several design patterns – Usually define generic classes that describe the collaborations between the objects and which will be sub-classed (specialized) when the framework is applied to a problem 310313 SYSTEM DESIGN 18 GENERIC DESIGN MECHANISMS : ARCHITECTURAL STYLES/DESIGN PATTERNS Architectural styles/design patterns represent solutions to problems that arise when developing software within a particular context. architectural styles/design patterns ≡ problem/solution pairs in a context Architectural styles/design patterns capture the static and dynamic structure and collaboration among key participants in software architectures and designs. They are particularly useful for describing how and why to resolve nonfunctional requirements. Architectural styles/design patterns facilitate reuse of successfulsoftware architectures and designs. 310313 SYSTEM DESIGN 19 GENERIC DESIGN MECHANISMS : ARCHITECURAL STYLES An architecture style specifies how to organize and connect a set of software modules. It is a pattern of system organization that defines the software architecture of a system. It includes the specification of: – system decomposition – global control flow – error handling – inter module communication protocols 310313 SYSTEM DESIGN 20 ARCHITECTURAL STYLES: MULTI-LAYER Goal: To build the software in layers so that each layer communicates only with the layers below it. Top layer: user interface Middle layers: application functions Bottom layers: common services (e.g., data storage, communication, etc.) Each layer has a welldefined API defining the services it provides. 310313 Often combined with other styles. SYSTEM DESIGN 21 ARCHITECTURAL STYLES: REPOSITORY Goal: To centralize the management of data. Control flow can be dictated by: – repository via triggers on the data. – subsystems using locks to synchronize. Possible drawbacks: – repository can be a bottleneck. A typical style for applications requiring data management. – high coupling between repository and subsystems. 310313 SYSTEM DESIGN 22 ARCHITECTURAL STYLES: CLIENT-SERVER Goal: To separate and distribute the system’s functionality. three-tier The server communicates with both a client (usually via the Internet) and with a database server (usually via an intranet). peer-to-peer Each subsystem can be both a server and a client and can set up a communication channel to exchange information as required 310313 SYSTEM DESIGN 23 ARCHITECTURAL STYLES: BROKER Goal: To distribute aspects of the system transparently to different nodes. The Proxy design pattern can be used to achieve this goal. Examples: CORBA - Common Object Request Broker Architecture Microsoft’s COM - Common Object Mode 310313 SYSTEM DESIGN 24 ARCHITECTURAL STYLES: TRANSACTION PROCESSING Goal: To direct input to specialized subsystems (handlers). A transaction dispatcher decides what to do with each input transaction, dispatching a procedure call or message to a handler that will handle the transaction. Example: – A database engine. 310313 SYSTEM DESIGN 25 ARCHITECTURAL STYLES: PIPE-AND-FILTER Goal: To provide flexibility, modifiability and reuseability of subsystem . A stream of data is passed through a series of subsystems, called a pipeline, each of which transforms it in some way. Examples: – UNIX shell 310313 SYSTEM DESIGN 26 ARCHITECTURAL STYLES: MODE-VIEW-CONTROLLER (MVC) Goal: To separate the user interface layer from other parts of the system. The model contains the classes (data) to be viewed and manipulated. The view contains objects used to render the data from the model and also the various controls with which the user can interact. The controller contains the objects that control and handle the users interaction with the view and the model. 310313 The Observer design pattern is normally used to separate the model from the view. SYSTEM DESIGN 27 DESIGN PATTERNS Design patterns are described using the following main parts: 1. Name and intent. 2. Problem and context. 3. Concern(s) addressed. 4. Abstract description of structure and collaborations in solution. 5. Positive and negative consequence(s) of use. 6. Implementation guidelines and sample code. 7. Known uses and related patterns. Design pattern makes extensive use of inheritance and delegation. Design patterns descriptions are usually independent of programming language or implementation details. 310313 SYSTEM DESIGN 28 DESIGN PATTERN: BRIDGE — MOTIVATION Problem: When an abstraction can have several possible implementations, inheritance is usually used to handle this. However, this binds an implementation to an abstraction permanently making it difficult to modify, extend and reuse abstractions and implementations independently. e.g., implementation of a portable Window abstraction in a user interface toolkit Window MSWindow MacWindow Window MSWindow Problem:We are mixing design and implementation inheritance hierarchies. 310313 MacWindow IconWindow MSWindow MacWindow SYSTEM DESIGN 29 DESIGN PATTERN: BRIDGE — MOTIVATION Solution: Separate the Window abstraction and implementation class hierarchies and connect them using a bridge bridge Window imp WindowImp drawText() drawRect() devDrawText() devDrawRect() impdevDrawLine() impdevDrawLine() impdevDrawLine() impdevDrawLine() IconWindow drawBorder() drawRect(); drawText() 310313 ApplicationWindow drawCloseBox() drawRect(); MSWindowImp devDrawText() devDrawLine() msDrawLine(); MacWindowImp devDrawText() devDrawLine() msDrawString(); SYSTEM DESIGN 30 DESIGN PATTERN: BRIDGE Intent Decouple an abstraction from its implementation so that the two can vary independently. Solution 1. Create an Implementor class that defines a public interface. 2. Create subclasses of the Implementor class to implement each operation as needed. 3. Create an Abstraction class that maintains an association to the Implementor class and provides a set of methods to invoke those operations. 4. For each RefinedAbstraction class that needs to use an Implementor subclass, subclass the RefinedAbstraction from the Abstraction. Consequences Avoids permanent bindings between an abstraction and its implementation. Both abstractions and implementations are extendable via subclassing. Changes to the implementation have little or not impact on clients. Hides implementation of an abstraction from clients. Allows sharing an implementation among multiple objects and hiding that fact from clients. 310313 SYSTEM DESIGN 31 DESIGN PATTERN: BRIDGE Client Abstraction imp Implementor operation() realOperation() imprealOperation() RefinedAbstraction ConcreteImplementorA realOperation() ConcreteImplementorB realOperation() Abstraction – defines the Abstraction’s interface; maintains a reference to an object of type Implementor. RefinedAbstraction – extends the interface defined by Abstraction. Implementor – defines the interface for implementation classes. This interface does not have to correspond exactly to Abstraction’s interface. Typically, Implementor provides only primitive operations; Abstraction defines higher-level operations based on these primitives. ConcreteImplementor – implements the Implementor interface and defines its concrete implementation. 310313 SYSTEM DESIGN 32 DESIGN PATTERN: FAÇADE – MOTIVATION Problem: Structuring a system into subsystems helps reduce complexity. A common design goal is to minimize the communication and dependencies between subsystems. How best to achieve this? Solution: Introduce a Façade class that provides a single, simplified interface to the more general facilities of a subsystem. 310313 SYSTEM DESIGN 33 DESIGN PATTERNS: FAÇADE — DESCRIPTION Intent Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use. Solution 1. Clients communicate with subsystem objects by calling operations in Façade. 2. Clients never (or as seldom as possible) directly access objects in subsystem—any such access weakens the encapsulation. 3. Subsystem objects usually retain no knowledge of Client. 4. Subsystem objects do not normally maintain any reference to Façade. Consequences Eliminates hard to control tangled networks of object associations. Reduces the number of objects with which Clients need to interface. Promotes weak coupling, which enhances overall flexibility. 310313 SYSTEM DESIGN 34 DESIGN PATTERNS: FAÇADE — DESCRIPTION Façade – knows which subsystem classes are responsible for a request and delegates client requests to appropriate subsystem objects. Subsystem classes – implement subsystem functionality; handle work assigned by the Façade object; have no knowledge of Façade. 310313 SYSTEM DESIGN 35 DESIGN PATTERN: PROXY — MOTIVATION Problem: Sometimes we want to defer the full cost of creating and initializing an object until we actually need to use it – e.g., in a document editor that can embed graphical objects in a document, objects like large raster images can be expensive to create – but, opening a document should be fast avoid creating expensive objects at once when the document is opened (also, usually not all objects are visible at the same time anyway) expensive objects should be created on demand Solution: Use another object, an image proxy, that acts as a stand-in for the real image – the proxy acts just like the image, instantiates it when needed and forwards request to it after creating it aTextDocument anImageProxy image fileName in memory 310313 anImage data on disk SYSTEM DESIGN 36 DESIGN PATTERN: PROXY-DESCRIPTION Intent Provide a surrogate or placeholder for another object to control access to it. Solution 1. 2. 3. Create an abstract Subject class that defines the complete public interface of a class, but does not implement it. Derive a RealSubject class from Subject and implement the public interface as needed to perform all required behaviour. Derive a Proxy that creates the RealSubject and passes all requests to it. Consequences Proxy is extremely good for patching inflexible OO designs in a well-controlled manner, often adding flexibility to the design. Proxys can be used to – distribute objects to different object spaces or across networks (remote proxy) – perform optimizations (virtual proxy) – allow additional housekeeping tasks to be done when an object is accessed (smart reference). Proxy can enhance RealSubject’s behaviour—particularly important when used to encapsulate third party libraries. 310313 SYSTEM DESIGN 38 DESIGN PATTERN: PROXY-DESCRIPTION Client Subject request() .. . RealSubject request() .. . realSubject Proxy request() .. . realSubjectrequest(); Proxy – maintains a reference that lets Proxy access RealSubject. Proxy may refer to Subject if the RealSubject and Subject interfaces are the same. – provides an interface identical to Subject’s so that Proxy can be substituted for RealSubject. – controls access to RealSubject and may be responsible for creating and deleting it. Subject – defines the common interface for RealSubject and Proxy so that Proxy can be used anywhere RealSubject is expected. RealSubject – defines the real object that Proxy represents. 310313 SYSTEM DESIGN 39 GENERIC DESIGN MECHANISM : MAKING DATA PERSISTENT USING AN RDBMS Volatile memory-object structure Our goal is to encapsulate database access to hide its implementation details! Persistent memory-table structure issues to consider for mapping classes/objects to a RDBMS: – class /object structure table structure – OIDS -how to create and assign them (if required by the OO PL) – inheritance ( if not supported in a relational DBMS) – data type mismatches (programming language DBMS) 310313 SYSTEM DESIGN 40 GENERIC DESIGN MECHANISM : MAKING DATA PERSISTENT USING AN RDBMS 1. Brute Force – Embed SQL in application classes (e.g. JDBC class libraries, ODBC API) Application classes Not a database encapsulation strategy! SQL database Pros – Can write code very quickly – O.K. for small applications and prototypes One approach : Customer Cons – Couples application classes directly with database schema making schema changes require reworking the code 310313 Database build select statement select statement result set set data values SYSTEM DESIGN 41 GENERIC DESIGN MECHANISM : MAKING DATA PERSISTENT USING AN RDBMS 2. Using Data Access Objects – Encapsulate SQL statements in one or more “data classes”(e.g. Java Data Object,Activex Data Object) Data classes Application classes SQL database Pros – Encapsulates the source code that handles hardcoded transactions in one place Cons – Needs recompilation of data classes when changes are made to the database One approach : Customer Database : CustData read(customer) get key values key value(s) build select statement select statement result set set data values 310313 SYSTEM DESIGN 42 EXAMPLE DATA ACCESS OBJECTS 310313 SYSTEM DESIGN 43 APPROACHES TO MAKING RDBMS DATA PERSISTENT 3. Using a Persistence Framework Application classes – A persistence layer maps objects to the database so that simple changes to the database schema do not affect the object code Pros – Application classes do not know anything about the database schema (they do not even know that a database is being used!) 310313 database One approach : Customer : Persistence Framework : Mapping Classes Database read(customer) get key values get maps build select statement Cons – Impacts performance SQL Persistence Layer select statement set data values SYSTEM DESIGN 44 EXAMPLE Make an objects persistent PERSISTENT DATA FRAMEWORK 1..* 0..1 PersistentObject -isProxy : Boolean -isPersistent : Boolean -timestamp : DateTime created from ClassMap 1 -name : String +getInsertSqlFor() +getDeleteSqlFor() +getUpdateSqlFor() +getSelectSqlFor() 1 1 PersistentTransaction * -tasks : Collection +processTransaction() +retry() +addTransaction() +addSaveObject() +addRetrieveObject() +addDeleteObject() +addCriteria() -attempt() -rollback() -commit() Provides Query and Transaction Processing Cursor -size : Integer +nextObjects() +nextProxies() +nextRows() +previousObjects() +previousProxies() +previousRows() -defaultSize() 310313 -statementComponents : Collection +buildForObjects() +buildForCriteria() +asString() maps +save() +retrieve() +delete() * * creates 1 Maps Objects to Tables SqlStatement processed by 1 processed by * PersistentCrteria -areSubclassesIncluded : Boolean -forClass : Class +addSelectXXX() +addOrCriteria() +perform() 1 processed by PersistenceBroker * uses -singleInstance : Object -connections : Collection +saveObject() +retrieveObject() +deleteObject() +processCriteria() connects to +processTransaction() 1 +processSql() -connectTo() -disconnectFrom() -retrieveClassMaps() * Interact with Persistence Mechanism Encapsulate Persistence Mechanism PersistenceMechanism -connection : Connection -name : String +open() +open() +close() +isOpen() SYSTEM DESIGN 45 UP — SYSTEM DESIGN ACTIVITIES Architect Architectural Design Design Use Cases Use-Case Engineer Component Engineer 310313 Design Classes Design Subsystems SYSTEM DESIGN 46 UP — SYSTEM DESIGN PROCESS Design use cases – identify design classes and/or subsystems for a use case – distribute use case behaviour to design classes and/or subsystems – specify requirements on operations of design classes and/or subsystems and their interfaces – capture nonfunctional implementation requirements Design classes – create design classes that fulfill all their functional and nonfunctional requirements by specifying completely their: attributes, relationships, operations, interfaces, dependencies on generic design mechanisms, etc. Design subsystems – define dependencies among subsystems – define interfaces that subsystems provide 310313 SYSTEM DESIGN 47 UP — SYSTEM DESIGN ACTIVITIES Architect Architectural Design Design Use Cases Use-Case Engineer Component Engineer 310313 Design Classes Design Subsystems SYSTEM DESIGN 48 USE-CASE DESIGN Identify the participating design classes – analysis classes that participate in the use case – additional classes to handle any special requirements of analysis use case (e.g., design goals) – any other classes needed to implement the use case (e.g., to accommodate the implementation environment) preserve traceability: use-case realization–design use-case realization–analysis use case Specify: – class diagrams show participating classes identify active classes a thread or process shown with a thicker border – implementation requirements collect the nonfunctional requirements that will be handled during implementation 310313 SYSTEM DESIGN 49 UP — SYSTEM DESIGN ACTIVITIES Architect Architectural Design Design Use Cases Use-Case Engineer Component Engineer 310313 Design Classes Design Subsystems SYSTEM DESIGN 50 7.4 CLASS DESIGN A Design class is class whose specifications has been completed to such a degree that it can be implemented. design classes come from two places: 1. the problem domain refine analysis classes by adding implementation details may require analysis classes to be divided into two or more detailed design classes 2. the solution domain utility class libraries, reusable components, component frameworks (DCOM, CORBA, Enterprise JavaBeans, etc.) provides the technical tools to implement a system 310313 SYSTEM DESIGN 51 CLASS DESIGN — SOLUTION DOMAIN For boundary classes we need to consider – specific user interface technologies used in Visual Basic need design classes: (1) stereotyped as «form» (2) representing “controls” For entity classes we need to consider – specific data management technologies used design classes that encapsulate a relational database For control classes we need to consider – distribution issues –> do we need a separate design class at each node? – performance issues –> do we merge with boundary/entity class? – transaction issues –> do we need to incorporate transaction management technology? 310313 SYSTEM DESIGN 52 7.4 CLASS DESIGN — ACTIVITIES complete the specification by identifying/specifying: – missing attributes, associations and operations not all messages become operations (e.g., actors, boundary classes) not all operations appear in interaction diagrams – type signatures and visibility of attributes and operations – constraints on operations –> invariants; preconditions; postconditions – exceptions –> values that operations should not accept select reusable components by identifying and adapting: – class libraries –> conversion/“glue” classes and operations may be needed – generic design mechanisms for handling nonfunctional requirements persistence; object distribution; security; transaction management; error handling, etc. 310313 SYSTEM DESIGN 53 CLASS DESIGN — ACTIVITIES (cont’d) restructure the design model – realize associations –> often realized as variables that provide references among objects refine multiplicities, role names, association classes, qualified roles, navigability of associations; consider programming language support – increase reuse by use of inheritance/delegation optimize the design model – revise access paths to speed up access –> add new associations – collapse classes –> classes with few attributes and little behavior – cache expensive computations –> use derived attributes – delay expensive computations –> e.g., image display Describe using the syntax of the programming language. 310313 SYSTEM DESIGN 54 CLASS DESIGN: ACTIVE CLASSES An active class has its own thread of control. It is usually boundary or control classes and is shown with a thicker border in class diagram Active classes can be identified by considering: The performance, throughput and availability requirements of different actors as they interact with the system e.g., a need for fast response time might be managed by a dedicated active object for taking input and providing output The system’s distribution onto nodes — active objects needed to support distribution onto several nodes e.g., one active object per node and separate active objects to handle node intercommunication Other requirements e.g., system startup and termination, liveness, deadlock avoidance, starvation avoidance, reconfiguration of nodes, capacity of connections, etc. 310313 SYSTEM DESIGN 55 CLASS DESIGN GOAL: WELL-FORMED CLASSES 1. High cohesion A class should model a single abstract concept and should have operations that support the intent of the class 2. Low coupling A class should be associated with just enough other classes to allow it to realize its responsibilities 3. Completeness and sufficiency A class should do what users of the class expect – no more and no less 4. Primitiveness A class should always make available the simplest and smallest possible set of operations 310313 SYSTEM DESIGN 56 UP — SYSTEM DESIGN ACTIVITIES Architect Architectural Design Design Use Cases Use-Case Engineer Component Engineer 310313 Design Classes Design Subsystems SYSTEM DESIGN 60 6.3.1 SUBSYSTEM DESIGN m subsystem name A subsystem is used to organize artifacts of the design model into more manageable pieces A subsystem can contain: – design classes – other subsystems – use-case realizations – interfaces A use case can be designed as a collaboration of subsystems rather than classes Can be represented as a class diagram of subsystems Subsystems can be used on interaction diagrams This allows hierarchical decomposition Subsystem can be refinements of packages or be directly identified in the design workflow (if there is no analysis model) 310313 SYSTEM DESIGN 61 SUBSYSTEM DESIGN — COHESION & COUPLING Goal: independent and loosely coupled but highly cohesive cohesion - a measure of the number of functionally different things a package has to do a package is most cohesive when it does only one thing coupling - a measure of the number and types of interconnections (dependencies) a package has with other packages a package has the lowest coupling when it has minimal dependencies with other packages There is a trade-off between cohesion and coupling (7 ± 2 heuristic) 310313 SYSTEM DESIGN 62 SUBSYSTEM DESIGN — COHESION coincidental logical Low worst “scatter-brained” temporal communicational procedural cohesion spectrum functional sequential High “single-minded” coincidental - The subsystem does not achieve any definable function. logical - The subsystem contains several similar, but slightly different functions. temporal - The subsystem contains various functions that happen to be executed at the same time. procedural - The subsystem functions must be executed in a pre-specified order. communicational - All subsystem functions operate on the same data stream or data structure. sequential - The output from one part of the subsystem is input to the next part. functional - The subsystem has one and only one identifiable function. best 310313 SYSTEM DESIGN 63 SUBSYSTEM DESIGN — COUPLING no direct stamp data Low external control coupling spectrum content common High no direct - The subsystems are not related. data - The subsystems pass only simple data (e.g., a parameter list). BEST! stamp - The subsystems pass a portion of a data structure as an argument. control - The subsystems pass control information (e.g., via a flag or switch). external - The subsystems are tied to an environment external to the system. common - Several subsystems reference a global common data area. content - One subsystem makes use of data or control information maintained within another subsystem. AVOID! 310313 SYSTEM DESIGN 64 6.3.4 SUBSYSTEM DESIGN — LAYERS AND PARTITIONS Recursively dividing subsystems into smaller and simpler subsystems leads to a hierarchy of subsystems/layers Each layer (subsystem) provides higher-level services and uses services of lower-level layers (subsystems) Subsystem layer architecture: 1. closed layered architecture: each layer can only depend on the layer immediately below it lower coupling (more overhead) 2. open layered architecture: each layer can depend on any layer below it higher coupling (less overhead) subsystem partitions: – divide services in one layer into different subsystems – results in peer to peer services within a layer Usually there are 3 to 5 subsystem layers in practice. 310313 SYSTEM DESIGN 65 SUBSYSTEM DESIGN — LAYERS AND PARTITIONS Application-specific layer Application-general layer Middleware layer (Provides middleware services) System-software layer (Provides OS services) 310313 SYSTEM DESIGN 66 SUBSYSTEM DESIGN — LAYERS AND PARTITIONS Application subsystems – come mainly from decomposing the analysis packages – application-specific: the part of the system that is not shared by other subsystems – application-general: the part of the system that is reusable within a business or application domain Middleware subsystems – reusable building blocks for utility frameworks and services that are platform-independent – generic design mechanisms, object request brokers, GUI toolkits System-software subsystems – software for computing and network infrastructure that is platform dependent – O.S., DBMS, hardware interfaces, communication software encapsulate middleware and system-software subsystems 310313 SYSTEM DESIGN 67 RECALL ASU PACKAGES : DESIGN 4 Interfaces People Maintenance Application-specific layer Course Registration Course Maintenance Application-general layer People Data 310313 Course Data SYSTEM DESIGN 69 ASU SUBSYSTEMS AND DEPENDENCIES m Interfaces m System Security m Application-specific layer m People Maintenance m Course Registration Course Maintenance m Report Generation Application-general layer m People Data 310313 m Course Data SYSTEM DESIGN 70 6.3.2 SUBSYSTEM DESIGN : INTERFACES m An interface is the set of operations that are accessible from “outside” the subsystem to other subsystems. Interface name also called the application programmer interface (API) interface specification includes: – operation names – parameters and their type – return values (if any) the interface implementation is provided by classes or other subsystems within the subsystem if a subsystem has a dependency directed toward it, it is likely that it needs to provide an interface any client using an interface is independent of the implementation of the subsystem 310313 SYSTEM DESIGN 71 ASU Course Registration System CourseRegistration Subsystem Interfaces 310313 SYSTEM DESIGN 72 ASU INTERFACES — COURSEREGISTRATION SUBSYSTEM CourseRegistration Student RegistrationMgr Request EnrollmentMgr IEnrollment IRegistration PrepareBilling InfoMgr IBilling 310313 SelectCourse ToTeachMgr ICourses SYSTEM DESIGN 73 ASU INTERFACES — COURSEREGISTRATION SUBSYSTEM Façade class CourseRegistration Student RegistrationMgr Course RegistrationMgr ICourseRegistration Student RegistrationMgr PrepareBilling InfoMgr SelectCourses ToTeachMgr Use the Façade design pattern to minimize coupling. 310313 SYSTEM DESIGN 74 ASU INTERFACES: ICOURSEREGISTRATION An interface consists of a list of all the operations that a subsystem makes visible to the outside world. For the CourseRegistration subsystem these can be obtained by examining the sequence diagrams— design containing the control classes inside the subsystem and extracting the operations to which these control classes respond. 310313 SYSTEM DESIGN 75 UP — SYSTEM DESIGN ACTIVITIES Architect Architectural Design Design Use Cases Use-Case Engineer Component Engineer 310313 Design Classes Design Subsystems SYSTEM DESIGN 76 UP SYSTEM DESIGN ACTIVITIES: ARCHITECTURAL DESIGN Architectural design outlines the deployment model by – specifying the (physical) system architecture in terms of physical computing nodes and their network configuration. – mapping subsystems onto the computing nodes. 310313 SYSTEM DESIGN 77 6.3.6 ARCHITECTURAL DESIGN :DEPLOYMENT MODEL node name A deployment model describes how the functionality of the system is physically distributed to processing nodes A deployment diagram shows: – nodes: computational resources (e.g., processors) – relationships: means of communication among nodes (e.g., network) common distributed configurations use a three-tier architecture – clients (to handle user interactions) boundary classes – database functionality (to store persistent data) entity classes – business/application logic control classes Client/server Architecture (special case of three-tier architecture where business/ application logic is relocated to one of the other two tiers) 310313 SYSTEM DESIGN 78 DEPLOYMENT MODEL — DESIGN ISSUES Which nodes are involved, and what are their capacities in terms of processing power and memory size? What types of connections are between the nodes, and what communication protocols will be used? What are the characteristics of the connections and communication protocols ( e.g., bandwidth, availability, quality, etc.)? Is there any need for redundant processing capacity, fail-over nodes, process migration, keeping backup data, etc.? 310313 SYSTEM DESIGN 79 ASU Course Registration System Architectural Design Deployment Model 310313 SYSTEM DESIGN 80 ASU DEPLOYMENT MODEL Registrar «intranet» Dorm 310313 Web server «intranet» «intranet» Main Building «intranet» Database server «intranet» Library SYSTEM DESIGN 81 ASU Course Registration System Architectural Design Subsystem Deployment 310313 SYSTEM DESIGN 82 ASU DEPLOYMENT MODEL — WEB SERVER NODE Web Server m System Security 310313 m People Maintenance m Course Registration m Course Maintenance m Report Generation SYSTEM DESIGN 83 ASU DEPLOYMENT MODEL — REGISTRAR NODE Registrar System Security Interfaces People Maintenance Course Registration People Data 310313 Course Maintenance Report Generation Course Data SYSTEM DESIGN 84 ASU DEPLOYMENT MODEL — DORM NODE Dorm m Interfaces 310313 SYSTEM DESIGN 85 ASU DEPLOYMENT MODEL — DORM NODE Dorm System Security Interfaces Course Registration People Data 310313 Course Data SYSTEM DESIGN 86 SYSTEM DESIGN ACTIVITIES — RETROSPECTIVE Use-case design – Identifies active classes and additional classes needed to meet design goals and handle the implementation environment Class design – Completes the specification of each class (attributes, operations); – Identifies reusable components; – Restructures and optimizes the design model Subsystem design subsystem, interfaces – Organize classes into cohesive, loosely coupled units; Architectural deployment model – Outlines the deployment of the system onto processing nodes. – Specifies the physical distribution of subsystem onto nodes. 310313 SYSTEM DESIGN 87 SUMMARY — SYSTEM DESIGN Design Model contains: Use-case realizations—design used to construct “builds” during implementation Design classes, their operations, attributes, relationships and implementation requirements implemented by files containing source code Subsystems, their dependencies and their interfaces implemented by implementation subsystems containing source code, scripts, binaries, executables, etc. Deployment Model These are all documented in the System Design Specification (SDS) 310313 SYSTEM DESIGN 88