1 / 65

Teaching Innovation - Entrepreneurial - Global

DTEL (Department for Technology Enhanced Learning). The Centre for Technology enabled Teaching & Learning ,. Teaching Innovation - Entrepreneurial - Global. DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING. V-semester OBJECT ORIENTED ANALYSIS & DESIGN (CS-5005).

marva
Download Presentation

Teaching Innovation - Entrepreneurial - Global

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. DTEL(Department for Technology Enhanced Learning) • The Centre for Technology enabled Teaching & Learning , Teaching Innovation - Entrepreneurial - Global

  2. DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING V-semester OBJECT ORIENTED ANALYSIS & DESIGN (CS-5005)

  3. UNIT 4:-SYSTEM DESIGN Management of data storage, Handling global resources Identifying concurrency, Allocation of subsystems   Making a reuse plan, Breaking into subsystems Handling a boundary conditions Overview, estimating performance. Choosing a software control strategy Common architectural styles 4 1 3 2 5 6 7 . . . . 2 3 4 DTEL 3 Milind S. Deshkar

  4. Understand the system design. UNIT-4 SPECIFIC Objective / course outcome Able to break into subsystems and identify concurrency. Able to define the system boundaries for high level systems. Differentiate between common architecture styles. 1 2 3 4 The student will be able to: DTEL 4 Milind S. Deshkar

  5. LECTURE 1:- Overview of system design System Design • System design is the high-level strategy for solving the problem and building a solution. • It includes decisions about the organization of the system into subsystems, the allocation of subsystems to hardware and software components and major conceptual and policy decisions that form the framework for detailed design. DTEL 5 Milind S. Deshkar

  6. LECTURE 1:- Overview of system design System Design • During analysis, the focus is on what needs to be done, independent of how it is done. During design, decisions are made about how the problem will be solved, first at high level, then at increasingly detailed levels. • It is the first design stage in which the basic approach to solving the problem is selected. • During system design, the overall structure and style are decided. DTEL 6 Milind S. Deshkar

  7. LECTURE 1:- Overview of system design System Design • The architecture provides the context in which more • detailed decisions are made in later design stages. • By making high-level decisions that apply to the entire • system, the system designer partitions the problem into • subsystems. DTEL 7 Milind S. Deshkar

  8. LECTURE 1:- System design System Design • The system designer must make the following decisions: • Making a reuse plan. • Organize the system into subsystems. • Identify concurrency inherent to the problem. • Allocate subsystems to processors and tasks. • Choose an approach for management of data. • Handle access to global resources. • Choose the implementation of control in s/w. • Handle boundary conditions. • Set trade-off priorities. DTEL 8 Milind S. Deshkar

  9. LECTURE 1:- System design 1. Making a reuse plan • There are two aspects of reuse: • i.Using existing things. • ii. Creating reusable new things. • Reusable things include models, libraries, frameworks and patterns. • Models – It is the most practical form of reuse. The logic in a model can apply to multiple problems. DTEL 9 Milind S. Deshkar

  10. LECTURE 1:- System design 1. Making a reuse plan • Libraries– A library is a collection of classes that are useful in many contents. • Qualities of good class libraries are as follows: • a. Coherence. Should be organized about a few, well-focussed themes. • b. Completeness. Should provide complete behavior for the chosen themes. • c. Consistency. Polymorphic operations should have consistent names and signatures across classes. • d. Efficiency. Should provide time and space saving alternative implementations of algorithms. • e. Extensibility. The user should be able to define subclasses for library classes. • f. Genericity. Should use parameterized class definitions where appropriate. DTEL 10 Milind S. Deshkar

  11. LECTURE 1:- System design 1. Making a reuse plan • Frameworks – Is a skeletal structure of a program that must be elaborated to build a complete application. The elaboration consists of specializing abstract classes with behavior specific to an individual application. • Frameworks consists of more than just the classes involved & include a paradigm for flow of control and shared invariants. • Frameworks class libraries are domain specific and not suitable for general use. DTEL 11 Milind S. Deshkar

  12. LECTURE 1:- System design 1. Making a reuse plan • Patterns – Is a proven solution to a general problem. It is a small number of classes & relationships. • Benefits of patterns – • i. Already been tested and used. • ii. Body of literature is available. • iii. Patterns are regarded as extension of a modeling language. DTEL 12 Milind S. Deshkar

  13. LECTURE 1:- THANK YOU DTEL 13 Milind S. Deshkar

  14. LECTURE 2:- System design 2. Breaking a system into subsystems • Fist step in system design is to divide the system into a small number of components. • Each subsystem encompasses aspects of the system that share some common property: similar functionality, the same physical location or execution on the same kind of hardware. DTEL 14 Milind S. Deshkar

  15. LECTURE 2:- System design 2. Breaking a system into subsystems • A subsystem is not an object nor a function but a package of classes, associations, operations, events and constraints that are interrelated and that have a reasonably well-defined and small interface with other subsystems. • A subsystem is usually identified by the service it provides. DTEL 15 Milind S. Deshkar

  16. LECTURE 2:- System design 2. Breaking a system into subsystems • A service is a group of related functions that share some common purpose, such as I/O processing, drawing pictures. • Each subsystem has a well defined interface to the rest of the system. The interface specifies the form of all interactions and the information flow across subsystem boundaries but does not specify how the subsystem is implemented internally. DTEL 16 Milind S. Deshkar

  17. LECTURE 2:- System design 2. Breaking a system into subsystems • Subsystems should be defined in such a manner that it has more cohesion and less coupling. • The relationship between two subsystems can be client-supplier or peer-to-peer. • The decomposition of systems into subsystems may be organized as a sequence of horizontal layers or vertical partitions. DTEL 17 Milind S. Deshkar

  18. LECTURE 2:- System design 2. Breaking a system into subsystems • Layers • A layered system is an ordered set of virtual worlds, each built in terms of the ones below it and providing the basis of implementation for the ones above it. • The objects in each layer can be independent, having some interaction with other layers. • A subsystem knows about the layers below it, but has no knowledge of the layers above it. DTEL 18 Milind S. Deshkar

  19. LECTURE 2:- System design 2. Breaking a system into subsystems • Layers • Layered architecture come in two forms: closed and open. • In an open architecture, a layer can use features of any lower layer to any depth. This reduces the need to redefine operations at each level, which can result in a more efficient and compact code. • Open architecture does not observe the principle of information hiding. Changes to a subsystem can affect any higher subsystem, so an open architecture is less robust than a closed architecture. DTEL 19 Milind S. Deshkar

  20. LECTURE 2:- System design 2. Breaking a system into subsystems • Layers • In closed architecture, each layer is built only in terms of the immediate lower layer. This reduces the dependencies between layers and allows changes to be made most easily because a layer’s interface only affect the next layer. • Partitions • Partitions vertically divide a system into several independent or weakly-coupled subsystems, each providing one kind of service. • The subsystems may have some knowledge of each other, but this knowledge is not deep, so major design dependencies are not created. DTEL 20 Milind S. Deshkar

  21. LECTURE 2:- THANK YOU DTEL 21 Milind S. Deshkar

  22. LECTURE 3:- System design Cashier ATM Consortium Cashier Station User Interface Comm. link Cash Card station code Database Account Comm link Customer User bank code Card Authorization Transaction Transaction Transaction Architecture of ATM System DTEL 22 Milind S. Deshkar

  23. LECTURE 3:- System design 3. Identifying Concurrency • In the analysis model, as in the real world and in hardware, all objects are concurrent. • An important goal of system design is to identify which objects must be active concurrently and which objects have activity that is mutually exclusive. DTEL 23 Milind S. Deshkar

  24. LECTURE 3:- System design 3.1 Identifying Inherent Concurrency • The dynamic model is the guide to identifying concurrency. • Two objects are inherently concurrent if they can receive events at the same time without interacting. • If the events are unsynchronized, the objects cannot be folded onto a single thread of control. • Two subsystems that are inherently concurrent need not necessarily be implemented as separate hardware units. DTEL 24 Milind S. Deshkar

  25. LECTURE 3:- System design 3.2 Defining Concurrent Tasks • Although all objects are conceptually concurrent, in practice many objects in a system are interdependent. • By examining the state diagrams of individual objects and the exchange of events among them, many objects can often be folded together onto a single thread of control. • A thread of control is a path through a set of state diagrams on which only a single object at a time is active. DTEL 25 Milind S. Deshkar

  26. LECTURE 3:- System design 3.3 Defining Concurrent Tasks • A thread remains within a state diagram until an object sends an event to another object and waits for another event. • The thread passes to the receiver of the event until it eventually returns to the original object. • The thread split if the objects sends an event and continues executing. DTEL 26 Milind S. Deshkar

  27. LECTURE 3:- System design • 4. Allocation of Subsystems • Each concurrent subsystem must be allocated to a hardware unit. The system designer must: • Estimate performance needs and the resources needed to satisfy them. • Choose hardware and software implementation for subsystem. • Allocate software subsystems to processors to satisfy performance needs and minimize inter-processor communication. • Determine the connectivity of the physical units that implement the subsystem. DTEL 27 Milind S. Deshkar

  28. LECTURE 3:- THANK YOU DTEL 28 Milind S. Deshkar

  29. LECTURE 4:- System design • 4.1 Estimating Hardware Resource Requirements • The decision to use multiple processors or hardware functional units is based on a need for higher performance than a single CPU can provide. • The system designer must estimate the required CPU processing power by computing the steady state load as the product of the number of transactions per second and the time required to process a transaction. DTEL 29 Milind S. Deshkar

  30. LECTURE 4:- System design • 4.2 Hardware-Software Trade-offs • Hardware can be regarded as a rigid but highly optimized form of software. • The system designer must decide which subsystem will be implemented in hardware and which in software. • Subsystems are implemented in hardware for two main reasons: • Existing hardware provides exactly the functionality required • Higher performance is required than a general purpose CPU can provide, and more efficient hardware is available. DTEL 30 Milind S. Deshkar

  31. LECTURE 4 :- System design • 4.3 Allocating Tasks to Processors • Tasks are assigned to processors because: • Certain tasks are required at specific physical location, to control hardware or to permit independent or concurrent operation. • The response time or information flow rate exceeds the available communication band width between a task and a piece of paper. • Computations rates are too great for a single processor, so tasks must be spread among several processors. DTEL 31 Milind S. Deshkar

  32. LECTURE 4:- System design • 5. Determining Physical Connectivity • The system designer must choose the arrangement and form of connections among the physical units. • The following decisions must be made: • Choose the topology of connecting the physical units. • Choose the topology of repeated units. • Choose the form of the connection channels ad the communication protocols. DTEL 32 Milind S. Deshkar

  33. LECTURE 4:- System design • 6. Management of Data Stores • The following guidelines characterize the kind of data that belongs in a formal database: • Data that requires access at fine levels of detail by multiple users. • Data that can be efficiently managed with DBMS commands. • Data that must port across many hardware and operating system platforms. • Data that must be accessible by more than one application program. DTEL 33 Milind S. Deshkar

  34. LECTURE 4:- System design • 6. Management of Data Stores • The following guidelines characterize the kind of data that belongs in a file and not in a relational database: • Data that is voluminous in quantity but difficult to structure within the confines of DBMS. • Data that is voluminous in quantity and of low information density. • “Raw” data that is summarized in the database. • Volatile data that is kept a short time and then discarded. DTEL 34 Milind S. Deshkar

  35. LECTURE 4:- THANK YOU DTEL 35 Milind S. Deshkar

  36. LECTURE 5:- System design • 6. Management of Data Stores • Data with high volume and low information density( such as historical records). • Modest quantities of data with simple structure. • Data that are accessed sequentially. • Data than can be fully read into memory. • Data suitable for files DTEL 36 Milind S. Deshkar

  37. LECTURE 5:- System design • 6. Management of Data Stores • Data that require updates at fine levels of detail by multiple users. • Data that must be accessed by multiple application programs. • Data that require coordinated updates via transaction. • Large quantities of data that must be handled efficiently. • Data that are long-lived and highly valuable to an organization. • Data that must be secured against unauthorized and malicious access. • Data suitable for databases DTEL 37 Milind S. Deshkar

  38. LECTURE 5:- System design • 7. Handling Global Resources • The system designer must identify global resources and determine mechanisms for controlling access to them. Global resources include: physical units, such as processors, communication satellites; Disk space and databases. • If a resource is a physical object, then it can control itself by establishing a protocol for obtaining access within a concurrent system. • If a resource is a logical entity, such as database, then there is danger of conflicting access in a shared environment. DTEL 38 Milind S. Deshkar

  39. LECTURE 5:- System design • 7. Handling Global Resources • Each global resource must be owned by a “guardian object” that control access to it. • All access to the resource must pass through the guardian object. • In a time critical application, the cost of passing all access to a resource through a guardian object is sometimes too high, and clients must access the resource directly by making use of locks. • A lock is a logical object associated with some defined subset of a resource that gives the lock holder the right to access the resource directly. DTEL 39 Milind S. Deshkar

  40. LECTURE 5:- System design • 8. Choosing Software Control Implementation • There are two kinds of control flows in a software system: external control and internal control. • External control is the flow of externally visible events among the objects in the system. • There are three kinds of control for external events: procedure-driven, event driven sequential and concurrent. DTEL 40 Milind S. Deshkar

  41. LECTURE 5:- System design • 8. Choosing Software Control Implementation • Internal control is the flow of control within a process. It exist only in the implementation and therefore is not inherently concurrent or sequential. • Unlike external events, internal transfers of control, such as procedure calls or inter-task call are under the direction of the program and can be structured for convenience. • Three kinds of control flow are common: procedure call, quasi-concurrent inter-tasks call and concurrent inter-tasks call. DTEL 41 Milind S. Deshkar

  42. LECTURE 5:- System design • 8.1External Control: Procedure-driven Systems • In a procedure-driven sequential system, control resides within the program code. • The major advantage of procedure-driven control is that it is easy to implement with convention languages, the disadvantage is that it requires the concurrency inherent in objects to be mapped into a sequential flow of control. DTEL 42 Milind S. Deshkar

  43. LECTURE 5:- THANK YOU DTEL 43 Milind S. Deshkar

  44. LECTURE 6:- System design • 8.1External Control: Event-driven Systems • In an event-driven sequential system, control resides within a dispatcher or monitor provided by the language, subsystem or operating system. • Event driven systems permit more flexible patterns of control than procedure-driven systems. • The mapping from events to program construct is much simpler and more powerful. DTEL 44 Milind S. Deshkar

  45. LECTURE 6:- System design • 8.1External Control: Concurrent Systems • In a concurrent system, control resides concurrent in several independent objects, each a separate task. Events are implemented directly as one way message between objects. • One task can wait for input, but other tasks continue execution. • The OS usually supplies a queuing mechanism for events so that events are not lost if a task is executing when they arrive. DTEL 45 Milind S. Deshkar

  46. LECTURE 6:- System design • 8.4 Internal control • External interactions inherently involve waiting for events because different objects are independent and cannot force other objects to respond: internal operations are generated by objects as part of the implementation algorithm, so their response patterns are predictable. • Most internal operations can therefore be thought of as procedure calls, in which the caller issues a request and waits for the response. DTEL 46 Milind S. Deshkar

  47. LECTURE 6:- System design • 9. Select an architectural style • There are several prototypical architectural frameworks that are common in existing systems. Each of these is well-suited to a certain kind of system. The kind of system include: • Batch processing. Executed once on an entire input set. • Continuous transformation. Performed continuously as inputs change. • Interactive interface. External interactions. • Dynamic simulation. Simulates evolving real-world objects. • Real-time system. Dominated by strict timing constraints. • Transaction manager. Concerned with storing & updating data, often including concurrent access from different physical locations. DTEL 47 Milind S. Deshkar

  48. LECTURE 6:- System design • 9.1 Batch Transformation • A batch transformation is a sequential input-to-output transformation, in which inputs are supplied at the start and the goal is to compute an answer. • The steps in designing a batch processing transformation are: • Break the overall transformation into stages, each stage performing one part of the transformation. • Define intermediate object classes for the data flows between each pair of successive stages. • Expand each stage in turn until the operations are straightforward to implement. • Restructure the final pipeline for optimization. DTEL 48 Milind S. Deshkar

  49. LECTURE 6:- System design • 9.2 Continuous Transformation • A continuous transformation is a system in which the outputs actively depend on changing inputs and must be periodically updated. • since a complete re-computation is impossible for every input value change, an architecture for a continuous transformation must facilitate incremental computation. The transformation can be implemented as a pipeline of functions. • The effect of each incremental change in an input value must be propagated through pipeline. DTEL 49 Milind S. Deshkar

  50. LECTURE 6:- System design • 9.2 Continuous Transformation • Synchronization of values within the pipeline may be important for high-performance systems. • In such cases, operations are performed at well-defined times and the flow path of operations must be carefully balanced so that values arrive at the right place at the right time. DTEL 50 Milind S. Deshkar

More Related