310313 SOFTWARE ENGINEERING SYSTEM DESIGN.

SOFTWARE ENGINEERING SYSTEM DESIGN

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

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

LIFE CYCLE ROLE Phases Core Workflows Iteration Increments Inception
Elaboration Construction Transition Requirements Analysis Design Iteration Implementation Testing iter. #1 iter. #2 iter. #n-1 iter. #n — — — — — Increments

ARTIFACTS & WORKERS Architect Use-Case Engineer Component Engineer
responsible for responsible for responsible for Design Model Deployment Model Architecture Description Use-Case Realization —Design Design Class Design Subsystem Interfaces

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 use- case 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

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

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

THE PURPOSE OF SYSTEM DESIGN
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.

FROM SYSTEM ANALYSIS TO SYSTEM DESIGN
Analysis and design activities may be combined in various ways.

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 How well do the Analysis Model and the Requirements Model describe the system? What is not yet clear?

ANALYSIS MODEL DESIGN MODEL Conceptual model
Generic –> many designs possible Less formal Less expensive to develop Package have few layers Focus is on interactions Outline of design Created by developer meetings May not be maintained Physical model Specific –> for one implementation More formal More expensive to develop Subsystem have many layers Focus is on sequence Implementation of design Created by software engineering environments Should be maintained

REALIZING DESIGN GOALS
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., schedule, budget) Examples: space vs. speed; delivery time vs. functionality, etc.

DESIGN GOALS — SOME DESIRABLE QUALITIES
6.4.2 DESIGN GOALS — SOME DESIRABLE QUALITIES Performance response time throughput memory Dependability robustness reliability availability fault tolerance security safety End user utility usability Maintenance extensibility modifiability adaptability portability readability Cost development deployment upgrade maintenance administration traceability

REALIZING DESIGN GOALS : IMPLEMENTATION ENVIRONMENT
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) – system software distribution What programming language will be used? OO, non-OO – memory management What existing software do we need to use? DBMS – network facilities UIMS – legacy systems What development people/organizations will be involved? distributed location – team competencies

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

REALIZING DESIGN GOALS : SYSTEM-WIDE DESIGN ISSUES
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

GENERIC DESIGN MECHANISMS
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 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 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 What How

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.

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

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. Often combined with other styles.

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. high coupling between repository and subsystems. A typical style for applications requiring data management.

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

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

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.

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

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 user􀀁s interaction with the view and the model. The Observer design pattern is normally used to separate the model from the view.

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.

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 MacWindow IconWindow MSWindow MacWindow Problem:We are mixing design and implementation inheritance hierarchies.

DESIGN PATTERN: BRIDGE — MOTIVATION
Solution: Separate the Window abstraction and implementation class hierarchies and connect them using a bridge imp Window drawText() drawRect() drawRect(); MSWindowImp devDrawText() devDrawLine() MacWindowImp IconWindow drawBorder() ApplicationWindow drawCloseBox() imp®devDrawLine() msDrawLine(); msDrawString(); bridge WindowImp devDrawRect()

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.

DESIGN PATTERN: BRIDGE
RefinedAbstraction imp®realOperation() Implementor realOperation() Abstraction operation() ConcreteImplementorA ConcreteImplementorB Client imp 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.

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.

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.

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.

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 image anImageProxy fileName anImage data in memory on disk

DESIGN PATTERN: PROXY-DESCRIPTION
Intent Provide a surrogate or placeholder for another object to control access to it. Solution 1. Create an abstract Subject class that defines the complete public interface of a class, but does not implement it. 2. Derive a RealSubject class from Subject and implement the public interface as needed to perform all required behaviour. 3. 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.

DESIGN PATTERN: PROXY-DESCRIPTION
realSubject®request(); Subject request() . RealSubject Proxy Client realSubject 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.

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)

1. Brute Force Embed SQL in application classes (e.g. JDBC class libraries, ODBC API) Pros Can write code very quickly O.K. for small applications and prototypes Cons Couples application classes directly with database schema making schema changes require reworking the code Application classes Not a database encapsulation strategy! SQL database One approach : Customer Database build select statement set data values select statement result set

2. Using Data Access Objects Encapsulate SQL statements in one or more “data classes”(e.g. Java Data Object,Activex Data Object) Pros Encapsulates the source code that handles hard- coded transactions in one place Cons Needs recompilation of data classes when changes are made to the database Application classes Data classes SQL database One approach : CustData Database set data values build select statement select statement result set : Customer read(customer) get key values key value(s)

EXAMPLE DATA ACCESS OBJECTS

APPROACHES TO MAKING RDBMS DATA PERSISTENT
3. Using a Persistence Framework 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!) Cons Impacts performance Application classes SQL Persistence Layer database One approach : Persistence Framework Database set data values build select statement select statement : Customer read(customer) get key values : Mapping Classes get maps

PersistentTransaction PersistenceMechanism
EXAMPLE PERSISTENT DATA FRAMEWORK Make an objects persistent Maps Objects to Tables creates maps PersistentObject -isProxy : Boolean -isPersistent : Boolean -timestamp : DateTime +save() +retrieve() +delete() PersistentTransaction -tasks : Collection +processTransaction() +retry() +addTransaction() +addSaveObject() +addRetrieveObject() +addDeleteObject() +addCriteria() -attempt() -rollback() -commit() PersistentCrteria -areSubclassesIncluded : Boolean -forClass : Class +addSelectXXX() +addOrCriteria() +perform() SqlStatement -statementComponents : Collection +buildForObjects() +buildForCriteria() +asString() ClassMap -name : String +getInsertSqlFor() +getDeleteSqlFor() +getUpdateSqlFor() +getSelectSqlFor() PersistenceBroker -singleInstance : Object -connections : Collection +saveObject() +retrieveObject() +deleteObject() +processCriteria() +processSql() -connectTo() -disconnectFrom() -retrieveClassMaps() PersistenceMechanism -connection : Connection +open() +close() +isOpen() * 1 0..1 1..* Cursor -size : Integer +nextObjects() +nextProxies() +nextRows() +previousObjects() +previousProxies() +previousRows() -defaultSize() created from uses connects to processed by Provides Query and Transaction Processing Interact with Persistence Mechanism Encapsulate Persistence Mechanism

UP — SYSTEM DESIGN ACTIVITIES
Architectural Design Architect Use-Case Engineer Design Use Cases Design Subsystems Design Classes Component Engineer

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

USE-CASE DESIGN Identify the participating design classes Specify:
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

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

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?

CLASS DESIGN — ACTIVITIES
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.

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.

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 inter- communication Other requirements e.g., system startup and termination, liveness, deadlock avoidance, starvation avoidance, reconfiguration of nodes, capacity of connections, etc.

CLASS DESIGN GOAL: WELL-FORMED CLASSES
High cohesion A class should model a single abstract concept and should have operations that support the intent of the class Low coupling A class should be associated with just enough other classes to allow it to realize its responsibilities Completeness and sufficiency A class should do what users of the class expect – no more and no less Primitiveness A class should always make available the simplest and smallest possible set of operations

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 – use-case realizations other subsystems – 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)

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)

SUBSYSTEM DESIGN — COHESION
coincidental logical temporal procedural communicational sequential functional “scatter-brained” “single-minded” High Low cohesion spectrum worst 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

SUBSYSTEM DESIGN — COUPLING
no direct data stamp control external common content High Low coupling spectrum 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!

SUBSYSTEM DESIGN — LAYERS AND PARTITIONS
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: closed layered architecture: each layer can only depend on the layer immediately below it ® lower coupling (more overhead) 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.

Application-specific layer Application-general layer Middleware layer (Provides middleware services) System-software layer (Provides OS services)

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

RECALL ASU PACKAGES : DESIGN 4
Interfaces Application-specific layer People Maintenance Course Registration Course Maintenance Application-general layer People Data Course Data

ASU SUBSYSTEMS AND DEPENDENCIES
Interfaces Application-specific layer m System Security m People Maintenance Course Registration m Course Maintenance m Report Generation m Application-general layer m m People Data Course Data

SUBSYSTEM DESIGN : INTERFACES
6.3.2 SUBSYSTEM DESIGN : INTERFACES An interface is the set of operations that are accessible from “outside” the subsystem to other subsystems. m Interface name also called the application programmer interface (API) interface specification includes: operation names – return values (if any) parameters and their type 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

ASU Course Registration System CourseRegistration Subsystem Interfaces

ASU INTERFACES — COURSEREGISTRATION SUBSYSTEM
Student RegistrationMgr Request EnrollmentMgr IRegistration IEnrollment PrepareBilling InfoMgr SelectCourse ToTeachMgr ICourses IBilling

ASU INTERFACES — COURSEREGISTRATION SUBSYSTEM
Façade class CourseRegistration Student RegistrationMgr SelectCourses ToTeachMgr PrepareBilling InfoMgr Course RegistrationMgr ICourseRegistration Student RegistrationMgr Use the Façade design pattern to minimize coupling.

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.

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.

ARCHITECTURAL DESIGN :DEPLOYMENT MODEL
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)

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

ASU Course Registration System
Architectural Design Deployment Model

ASU DEPLOYMENT MODEL Registrar Web server Database server Dorm Main
«intranet» «intranet» «intranet» «intranet» «intranet» Dorm Main Building Library

ASU Course Registration System
Architectural Design Subsystem Deployment

ASU DEPLOYMENT MODEL — WEB SERVER NODE
System Security m m m People Maintenance Course Registration m Course Maintenance m Report Generation

ASU DEPLOYMENT MODEL — REGISTRAR NODE
People Maintenance Course Data Report Generation Interfaces Registration System Security

ASU DEPLOYMENT MODEL — DORM NODE
Interfaces m

ASU DEPLOYMENT MODEL — DORM NODE
People Data Course Interfaces Registration System Security

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.

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 SOFTWARE ENGINEERING SYSTEM DESIGN.

Similar presentations

Presentation on theme: "310313 SOFTWARE ENGINEERING SYSTEM DESIGN."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

310313 SOFTWARE ENGINEERING SYSTEM DESIGN.

Similar presentations

Presentation on theme: "310313 SOFTWARE ENGINEERING SYSTEM DESIGN."— Presentation transcript:

Similar presentations

About project

Feedback