1 / 319

Chapter 14 System Design

Chapter 14 System Design. Overview of system design Estimating performance Making a Reuse plan Breaking system into sub-system Identifying Concurrency Allocation of Sub Systems Management of Data Storage Handling Global Resources Choosing a Software Control strategy

kelton
Télécharger la présentation

Chapter 14 System Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 14 System Design

  2. Overview of system design Estimating performance Making a Reuse plan Breaking system into sub-system Identifying Concurrency Allocation of Sub Systems Management of Data Storage Handling Global Resources Choosing a Software Control strategy Handling Boundary Conditions Setting Trade-off Priorities Common Architectural Style Topic Covered

  3. Till now, focus was on WHAT needs to be done, independent of HOW it is done. During System design, decide how the problem will be solved. Need to apply high level strategy – System Architecture – for solving the problem and building a solutions. During System design, developer decide the overall structure and style. System architecture provides the organization of the system into subsystem. System Design

  4. System Design • To construct system architecture, following decision must make: • Estimating performance • Making a Reuse plan • Breaking system into sub-system • Identifying Concurrency • Allocation of Sub Systems • Management of Data Storage • Handling Global Resources • Choosing a Software Control strategy • Handling Boundary Conditions • Setting Trade-off Priorities • Common Architectural Style

  5. System Design Estimating Performance • You should prepare rough performance estimate. • Purpose of this task to determine if the system is feasible. • You will have to make simplifying assumptions.(i.e. assume factors) • Don’t worry about detail – just approximate, estimate and guess.

  6. System Design • For ATM exa. Consider following case • Bank has 40 branches and no. of terminals. • On a busy day half the terminal are busy at once. • Suppose each customer takes one min to perform a session and most transaction involve a single transaction. i.e. 40 transaction a time. • You can perform similar estimate for data storage. • Count the no. of customer, estimate amount of data for each one and multiply. i.e. 40 *20 =800.

  7. System Design Making a Reuse plan • Two different aspect of reuse • Using existing thing • Creating reusable new things. • Much easier to reuse existing things than to design new things. • Most developer reuse existing thing and only a small fraction of developers create new things. • Creating reusable new things is not easy task. It require good experience.

  8. System Design • Reusable thing includes mainly • Libraries • Frameworks • Patterns • Libraries: it is a collection of classes that are useful in many contexts. • Classes must be organized, so users can find them. Online searching can help more. • Classes must have accurate and thorough description to help users determine their relevance.

  9. System Design • Several qualities of good class libraries: • Coherence: organized well focus • Completeness: complete behavior • Consistency: consistent names and signature. • Efficiency: provide alternative to implement • Extensibility: able to define subclasses • Genericity: should be parameterized class where appropriate.

  10. System Design • Framework: it is skeletal structure of a program that must be elaborated to build complete application. • Framework consists of more than just the classes. It is more specific to individual application. • Framework class libraries are typically application specific and not suitable for general use.

  11. System Design • Patterns: A pattern is proven solution to a general problem. • There are patterns for analysis, architecture, design and implementation. • A pattern comes with guideline on when to use it, as well as exchange on its use. • There are many benefits. One advantage, carefully created and applied on past problems. • A pattern is different from a framework.

  12. System Design • A pattern is typically a small number of classes and relationship. • A Framework is much broader in scope and covers an entire application.

  13. System Design Breaking a system into SubSystems • First steps in system design is to divide the system into pieces. • Each major pieces of a system is called Sub System. • Each subsystem is based on common functionality, common physical location and common hardware. • A subsystem is not an object nor a function. But a group of classes, association operations, events and constraints that are interrelated.

  14. System Design • A Sub system always identified by its Service it provides. • A Service is group of related functions that share common purpose. • For. File system within an operating system is a subsystem. • Each subsystem interface specifies the form of all interactions and information flow between them. • Relationship between two subsystems can be client-server or peer-to-peer.

  15. System Design • Client-Server Relationship: • Client calls on the server, which performs some services and replies with a result. • Client must know server interface, but server did not know its client’s interface. • Because client initiates all interactions. • Peer-to-Peer Relationship: • A communication from one subsystem to another is not necessarily followed by an immediate response.

  16. System Design • Each subsystem must know each other’s interfaces. • Therefore, these interactions are more complicated. • So Decomposition of system into subsystem may be organized as a sequence of horizontal layers or vertical partitions.

  17. System Design Layers: • A layered system is ordered set of tiers. • Each built in terms of the ones below it and providing the implementation basis for the ones above it. • Information is one way only – subsystem knows about the layers below it but has no information of layers above it. • Client-Server relationship exists between upper layers(users of services) and lower layers (providers of services)

  18. System Design • In interactive graphics system, windows are made from screen operation, which implemented using pixel operation, which execute device I/O operation. • Each layer is implemented in terms of classes and operation of lower layers. • Layers architecture are in two forms: • Open Architecture • Close Architecture.

  19. System Design • Closed Architecture: • Each layer built only in terms of immediate lower layer. • Reduces dependencies between layered • Allows changes easily. • Open Architecture: • A layer can use features of any lower layer to any depth. • It reduces the need to redefine operation at each level. • Changes to sub system can affect at higher level • So, it is Less robust compare to close architecture

  20. System Design • Usually Problem statement specifies only the top and bottom layers: • Top layers is desired system • Bottom layers is available resources (Hardware, Operating system)

  21. System Design Partitions: • Vertically divide a system into several independent or weakly coupled subsystem. • For ex. Computer operating system includes a file system, process control, virtual memory management and device control. • Sub system may have some information of each other but not deep.

  22. System Design • Diff. between layers and partitions • Layers vary in their level. While partitions only divide a system into pieces.( all have same level) • Layers depend on each others(client Server relationship). While partitions are independent (peer to peer relationship)

  23. System Design Combining layers and partitions • Layers can be partitioned, and partitions can be layered. • Most large system require a mixture of layers and partitions. (Refer fig 1) • Once you have identified the top-level subsystems, you can show their informational flow. • Many computations have the form of pipeline;

  24. System Design Figure 1

  25. System Design • For ATM example: there are 3 major sub systems. ATM stations, Consortium Computer and Bank computes. • Consortium computer communicate with all ATM and bank computers ( comm. Links) • Architecture uses station code and bank code to differentiate phone lines and consortium computer.

  26. System Design

  27. System Design Identifying Concurrency: • Identify the objects that must be active concurrently and objects that have mutually exclusive activity. • You can fold the latter objects into a single thread of control or task. • Two steps: • Identifying inherent concurrency • Defining Concurrent Tasks.

  28. System Design Identifying inherent concurrency • State model guide to identifying concurrency. • If two objects receive events at the same time without interacting then its called inherently concurrent. • If event are unsynchronized, you can’t fold the objects into a single thread of control. • Often problem statement specifies that distinct hardware units can implement the objects.

  29. System Design • For Example ATM: it was stated (in chapter 11) each machine should continue to operate locally in event of central system failure, then would have no choice but to include a CPU in each ATM machine with full control program.

  30. System Design Defining concurrent Tasks • By studying state diagram of individual objects and exchange of events among them. • You can fold many objects onto a single thread of control.. • A thread of control is path through a set of state diagram on which only a single object at a time is active.

  31. System Design • A thread remains within a state diagram until an object sends an event and passes to the receiver of event. • A thread splits if the object sends an event and continues executing. • Only single object at a time is active. • ATM Ex. : if a central computer directly controls the ATM, we can combine ATM object with Bank transaction object as a single task.

  32. System Design Allocation of Subsystem • Must allocate each concurrent subsystem to hardware unit. • Either general purpose or specialized functional unit. • Criteria would be • Estimate hardware resource requirement • Making hardware-software trade-off • Allocating Tasks to processors • Determining Physical connectivity.

  33. System Design Estimating hardware resource requirement • System designer must estimate the required CPU processing power by computing steady-state load. • I.e. Product of number of transaction per second and time required to process a transaction. • You should increase estimate to allow for transient effects(i.e. failure cases) • Steady-state and peak load are important.

  34. System Design • For. Ex. ATM machine just proive user interface and some local processing. So single CPU would work for each ATM. • Consortium computer is essential – as it receives ATM request and sending them to appropriate bank computer. So it involves multiple CPUs. • While Bank computers perform data processing and database application. • Appropriate depend upon needed throughout.

  35. System Design Making Hardware-Software Trade-offs • You must decide which subsystem will be implemented in hardware and which in software. • Two main reason: • Cost – it is easier buy floating point chip than to implement floating point in software. • Performance – more efficient hardware is available.

  36. System Design Allocating Tasks to processors • Several reasons for assigning task to processors • Logistics : Some tasks are required at specific physical locations or to permit independent operations. • For ex. At ATM, might communication network is down on that case ATM must have its own CPU and programming logic.

  37. System Design • Communication Limits • Sometime available comm. bandwidth between task & piece of Hardware is not sufficient then response is not getting on time or its taking more time to complete. • Computation Limits • Assign separates processors for computation process.

  38. System Design Determining Physical Connectivity • Connection topology: • Choose the topology for connecting physical units. • As Association in the class model indicating physical connection. • For ATM communicate with Consortium. • Also client-server relationship also correspond to physical connections.

  39. System Design • Repeated units • Topology has a regular pattern such as • Linear Sequence , A martix, A tree, A Star • If you have boosted performance for particular kinds of units or group of units, then you must specify their topology. • Communications: • Choose the form of connection channel & comm protocol.

  40. System Design • System designer may specify the exact interfaces among units for interaction mechanisms. • For Ex. Interactions may be Asynchronous, Synchronous or blocking. • Based on estimate bandwidth & latency of the comm channels and choose the correct kinds of comm channels.

  41. System Design Management of data storage • There are several alternatives for data storage. • You can use separately or in combinations. • Data structure • Files • Database • Based on cost, access time and reliability different kinds of data storage. • For Ex. PC application may use memory data structure or files. • An accounting system may use a database,

  42. System Design • Data storage – Files • Files are cheap, simple and permanent. • Files implementation vary for different computer systems. • For ex. Implementation for sequential files are mostly standard, but commands and storage formats for random-access files and indexed files vary

  43. System Design • Kinds of data that belongs in files • Data with high volume and low information density (historical records) • Quantities of data with simple structure. • Data that are accessed sequentially. • Data that can be fully read into memory

  44. Data storage – Database • Various type of DBMS available • Relational DB • OO DB. • DBMS cache frequently accessed data in memory. • DB makes application easier to port different hardware and OS. • Disadvantage – complex interface

  45. System Design • Kinds of data that belongs in DB • Data that requires updates from multiple users. • Data that must accessed by multiple application programs. • Data that require updates via transaction. • Data that are long-lived and highly valuable. • Data that must be secure.

  46. System Design Note: • Most application need a database, you should use relational DBMS. • RDBMS features are sufficient for most application.

  47. System Design Handling Global Resources • System designer must identify • Global resources • Mechanism for controlling the access. • There are several kinds of global resources. • Physical units : Processors, tape drives and communication satellites. • Space: Disk space, workstation screen and buttons on a mouse

  48. System Design • Logical names: Object IDs, Filenames and class names. • Access to shared data: Database • Resource can be • Physical object : It can control itself by specifying protocol • Logical object: Conflicting access in a shared environment. • To solve conflicting access, you should introduce “Guardian object”.

  49. System Design • Guardian object - own each global logical resource and have control access to it. • All access must be pass through Guardian object only • In ATM example, Bank code and Account numbers are global resources. • Bank codes must be unique within consortium. • Account number must be unique within the Bank.

  50. System Design Choose the Software control strategy • Two kinds of control system in Software system: • External control • Internal control • External control concerns the flow on externally visible events among objects. • Three kinds of control external event: • Procedure-driven sequential • Event-driven sequential • Concurrent

More Related