1. Teaching Innovation - Entrepreneurial - Global
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 1 Overview, estimating performance. 2 2
Making a reuse plan, Breaking into subsystems 2 2
Identifying concurrency, Allocation of subsystems   3 3 4
Management of data storage, Handling global resources 4 .
Choosing a software control strategy 5 .
Handling a boundary conditions 6 .
Common architectural styles 7
DTEL
Milind S. Deshkar 3

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

5. System Design Overview of system design
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
Milind S. Deshkar 5

6. System Design Overview of system design
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
Milind S. Deshkar 6

7. System Design Overview of system design
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
Milind S. Deshkar 7

8. System Design System design
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
Milind S. Deshkar 8

9. 1. Making a reuse plan System design There are two aspects of reuse:
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
Milind S. Deshkar 9

10. 1. Making a reuse plan System design
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
Milind S. Deshkar 10

11. 1. Making a reuse plan System design
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
Milind S. Deshkar 11

12. 1. Making a reuse plan System design
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
Milind S. Deshkar 12

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

14. 2. Breaking a system into subsystems
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
Milind S. Deshkar 14

15. 2. Breaking a system into subsystems
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
Milind S. Deshkar 15

16. 2. Breaking a system into subsystems
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
Milind S. Deshkar 16

17. 2. Breaking a system into subsystems
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
Milind S. Deshkar 17

18. 2. Breaking a system into subsystems
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
Milind S. Deshkar 18

19. 2. Breaking a system into subsystems
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
Milind S. Deshkar 19

20. 2. Breaking a system into subsystems
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
Milind S. Deshkar 20

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

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

23. 3. Identifying Concurrency
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
Milind S. Deshkar 23

24. 3.1 Identifying Inherent Concurrency
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
Milind S. Deshkar 24

25. 3.2 Defining Concurrent Tasks
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
Milind S. Deshkar 25

26. 3.3 Defining Concurrent Tasks
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
Milind S. Deshkar 26

27. 4. Allocation of Subsystems
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
Milind S. Deshkar 27

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

29. 4.1 Estimating Hardware Resource Requirements
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
Milind S. Deshkar 29

30. 4.2 Hardware-Software Trade-offs
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
Milind S. Deshkar 30

31. 4.3 Allocating Tasks to Processors
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
Milind S. Deshkar 31

32. 5. Determining Physical Connectivity
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
Milind S. Deshkar 32

33. 6. Management of Data Stores
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
Milind S. Deshkar 33

34. 6. Management of Data Stores
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
Milind S. Deshkar 34

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

36. Data suitable for files
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
Milind S. Deshkar 36

37. Data suitable for databases
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
Milind S. Deshkar 37

38. 7. Handling Global Resources
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
Milind S. Deshkar 38

39. 7. Handling Global Resources
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
Milind S. Deshkar 39

40. 8. Choosing Software Control Implementation
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
Milind S. Deshkar 40

41. 8. Choosing Software Control Implementation
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
Milind S. Deshkar 41

42. 8.1External Control: Procedure-driven Systems
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
Milind S. Deshkar 42

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

44. 8.1External Control: Event-driven Systems
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
Milind S. Deshkar 44

45. 8.1External Control: Concurrent Systems
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
Milind S. Deshkar 45

46. 8.4 Internal control System design
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
Milind S. Deshkar 46

47. 9. Select an architectural style
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
Milind S. Deshkar 47

48. 9.1 Batch Transformation System design
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
Milind S. Deshkar 48

49. 9.2 Continuous Transformation
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
Milind S. Deshkar 49

50. 9.2 Continuous Transformation
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
Milind S. Deshkar 50

51. 9.2 Continuous Transformation
LECTURE 6:-
System design
9.2 Continuous Transformation
The steps in designing a pipeline for a continuous transformation are:
Draw a data flow diagram for the system
Define intermediate objects between each pair of successive stages, as in the batch transformation.
Differentiate each operation to obtain incremental changes to each stage.
Add additional intermediate objects for optimization.
DTEL
Milind S. Deshkar 51

52. LECTURE 6:-
THANK YOU
DTEL
Milind S. Deshkar 52

53. 9.3 Interactive Interface
LECTURE 7 :-
System design
9.3 Interactive Interface
An interactive interface is a system that is dominated by interactions between the system and external agents, such as humans, devices or other programs.
It usually includes part of an entire application which can often be handled independently from the computational part of the application.
The major concerns of an interactive interface are the communications protocol between the system and the external agents, the syntax of possible interactions, the presentation of output.
DTEL
Milind S. Deshkar 53

54. 9.3 Interactive Interface
LECTURE 7 :-
System design
9.3 Interactive Interface
Interactive interfaces are dominated by the dynamic model. The steps in designing an interactive interface are:
Isolate the objects that form the interface from the objects that define the semantics of the application.
Use predefined objects to interact with external agents.
Use the dynamic model as the structure of the program. Interactive interfaces are best implemented using concurrent control or event-driven control.
Isolate physical events from logical events.
Fully specify the application functions that are invoked by the interface. Make sure that the information to implement them is present.
DTEL
Milind S. Deshkar 54

55. 9.4 Dynamic Simulation System design
LECTURE 7 :-
System design
9.4 Dynamic Simulation
A dynamic simulation models or tracks objects in the real world.
Traditional methodologies built on data flow diagrams are poor at representing these problems because simulations involve many distinct objects that constantly update themselves, rather than a single large transformation.
DTEL
Milind S. Deshkar 55

56. 9.4 Dynamic Simulation System design
LECTURE 7 :-
System design
9.4 Dynamic Simulation
The steps in designing a dynamic simulation are:
Identify actors, active real-world objects, from the object model
Identify discrete events.
Identify continuous dependencies.
Generally a simulation is driven by a timing loop at a fine time scale.
The hardest problem with simulation is usually providing adequate performance.
DTEL
Milind S. Deshkar 56

57. 9.5 Real time System System design
LECTURE 7 :-
System design
9.5 Real time System
A real time system is an interactive system for which time constraints on actions are particularly tight or in which the slightest timing failure cannot be tolerated.
For critical actions, the system must be guaranteed to respond within an absolute interval of time.
Typical application include process control, data acquisition, communication devices etc.
DTEL
Milind S. Deshkar 57

58. 9.5 Transaction Manager System design
LECTURE 7 :-
System design
9.5 Transaction Manager
A transaction manager is a database system whose main function is to store and access information. The information comes from the application domain.
The steps in designing a transaction manager are
Map the object model directly into a database.
Determine the units of concurrency.
Determine the unit of transaction.
Design concurrency control for transactions.
DTEL
Milind S. Deshkar 58

59. LECTURE 7 :-
THANK YOU
DTEL
Milind S. Deshkar 59

60. Chapter 4 Question Bank
What decisions a system designer must take before creating a system design ?
Discuss the qualities of a good class library.
Draw and explain architecture of ATM system.
What is the need of global resources ? How can it be handled ?
Explain the usefulness of data store.
How many types of architectural frameworks are there that are common in existing systems ? Discuss any two.

61. Summary
1. System design is the high-level strategy for solving the problem and building a solution that 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.
Decisions made by a system designer are as follows :
- 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
3. There are two aspects of reuse:
i. Using existing things.
ii. Creating reusable new things.

62. Summary
4. 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.
5. 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.
6. 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.
In closed architecture, each layer is built only in terms of the immediate lower layer.
7. Partitions : Partitions vertically divide a system into several independent or weakly-coupled subsystems, each providing one kind of service.

63. Guideline for a formal database
Summary
8. Management of data store:
Sr. No.
Guideline for a formal database
Guidelines for a file 1
Data that requires access at fine levels of detail by multiple users.
Data that is voluminous in quantity but difficult to structure within the confines of DBMS. 2
Data that can be efficiently managed with DBMS commands.
Data that is voluminous in quantity and of low information density. 3
Data that must port across many hardware and operating system platforms.
“Raw” data that is summarized in the database. 4
Data that must be accessible by more than one application program.
Volatile data that is kept a short time and then discarded.

64. Summary 9. There are three kinds of control for external events:
- Procedure-driven
- Event driven
- Sequential and concurrent.
10. There are several prototypical architectural frameworks that are common in existing systems 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.

65. THANK YOU
DTEL
Milind S. Deshkar 65