UNIT -5

SYSTEM DESIGN
 SYSTEM DESIGN
• High level strategy – the system architecture is designed
for solving the problem and building a solution.
• Here decisions are made about the organization of the
system into subsystem, allocation of subsystems to
hardware and software and major policy decisions that
form the basis for class design.
 Overview of system design
• Analysis- what needs to be done & Design- How it is done.
• First stage-overall structure and style decided by the
developers.
• System architecture determine the organization of system into
subsystems.
• Following decisions are to be made.
– Estimate system performance
– Make a reuse plan
– Organize the system into subsystems
– Identify concurrency inherit in the problem
– Allocate subsystems to hardware
– Manage data stores
– Handle global resources
– Choose a software control strategy
– Handle boundary conditions
– Set trade off priorities
– Select an architectural style
 ESTIMATING PERFORMANCE
• Engineers call this as “Back of envelope” calculation. The
purpose is not to achieve high accuracy, but merely to determine
if the system is feasible
– ie. Making a rough performance estimate.(just to see if
feasible)-calculation must be fast and involve common sense-
assumptions must be simplifying-just approximate, estimate
and guess if necessary.
• Atm ex:
– Atm n/w for a bank with 40 branches.
assuming 1 transaction/sec This does not need a very fast
computer. This is not the case of online sellers.
– Data storage- number of customers*estimated data for each
• not huge but for satellite based ground imaging system
bandwidth required and data storage huge.
 MAKE A REUSE PLAN
• Reuse doesn’t happen automatically.
There are two different aspects: using existing
things and creating reusable new things.
(difficult)
• Reusable things include
– Models
– Library
– frameworks and
– patterns.
• Reuse of models is often the most practical form
of reuse. The logic in the model can apply to

Library
• Collection of classes –to be organized carefully – must have
accurate and thorough descriptions to help users determine
their relevance.
• The qualities of good class libraries
• Coherence -Few well focuses themes
• Completeness-Complete behaviour of selected themes
• Consistency-Polymorphic operations have consistent names
and operations.
• Efficiency-Alternate implementations of algorithms that works
on time and space(depending on requirement)
• Extensibility-User should be able to create subclasses
• Genericity-Should use parameter class definitions
• Problem may be encountered when integrating
class libraries from multiple sources.
– Classes may adopt policies that are individually
sensible but fundamentally incomplete with those of
other class libraries. If such inconsistencies are seen,
the source code must be reworked.
• limits our ability to reuse code from class libraries.
• Argument validation
• An application may validate arguments
individually(responsive user interfaces) or as a
collection(command interfaces).
• Error handling
• Use different error handling techniques. Some methods
may return error codes or some may handle them
directly.
• Control paradigms
– Applications may adopt event-driven or procedure-driven.
With ED, the UI calls application methods. With PD, the
application call UI methods. Combining both in one
application is difficult.
• Group operations
– Are often inefficient and incomplete. A single object
deletion is complex –locks to be taken care etc. Deleting a
group is complex.
• Garbage collection
– Different strategy used for managing memory
allocation(returning a pointer to a string, copy of a string,
returning a pointer with read-only access), avoiding
memory leaks(mark, sweep, reference counting etc)
• Name collisions
– Class names, public attributes and methods –global
namespace. Prefix added to avoid collisions
 FRAMEWORKS
• A framework is a skeletal structure of a program elaborated to
build a complete application.
• Elaboration consists of specialized abstract classes with
behaviour specific to an individual application.
• A class library may accompany frameworks to reuse
subclasses.
• Framework also contains a paradigm for flow of ctrl and
shared invariants.
• Frameworks tend to be specific to a category of applications.
• Framework class libraries typically application specific and
not for general use
 PATTERNS
• A pattern is a proven solution to a general problem.
• Patterns target different phases of s/w lifecycle (analysis,
architecture, design & implementation).
• Can achieve reuse by using existing pattern rather than
reinventing from scratch.
• A pattern comes with guidelines on when to use it, as well as
trade-offs on its use.
• Adv. More likely to be correct as they are tested. Normally
designed in known languages
• Patterns are extension of modeling language and prototypical
model fragments that distills the some of the knowledge of
experts.
 Patterns
• A pattern is different from framework that is broader in scope
and covers entire subsystem. pattern contains small number of
classes and relationships.
• ATM Ex: The notion of a transaction offers some possibility of
reuse-transactions are a frequent occurrence in computer
systems, and there is a commercial software to support them.
 Breaking a system into subsystems
• First step in system design is to divide system into pieces.
• Each major piece is a subsystem based on similar functionality
such as physical location, execution on same h/w.
• For Ex: a spaceship computer might include subsystems for life
support, navigation, engine control, and running scientific
experiments.
• A subsystem is not an object nor a function but a group of
classes, associations, operations, events and interrelated
constraints.
• A subsystem is usually identified by the services it provides.
• Service- group of related functions that share common purpose
such as processing I/O, performing arithmetic.
 Breaking a system into subsystems
• Each subsystem has a well defined interface to the rest of the
system which specifies the form of all interactions and the info
flows across subsystem boundary but nothing about implement.
• Interactions must be made only within the subsystem as much
as possible rather than across subsystem boundary .
Dependency is reduced.
• Each subsystem may in turn be decomposed into deeper
subsystems.
• Relation b/w subsystems may be client-server(client needs to
know server’s interface as clients initiate all interactions) or
peer-peer(all must know about others interfaces). Client server
is easier to build and hence preferred.
• Decomposition can be organized into sequence of horizontal
 Layers
• A layered system is an ordered set of virtual worlds(a set of tiers)
each built in terms of the ones below it and providing the
implementation basis for the ones above it..
• The objects in each layer can be independent(correspondance
allowed b/w objects)
• Subsystem knows about the layers below it, not the ones above.
Layer 2 is made of its own classes and operations and also of objects
of layer 1.
• Client –server relationship exists b/w upper layer and lower layers.
• Layered architecture comes in two forms:
• Closed architecture -(each layer is built only in terms of the
immediate lower layer-reduces dependencies b/w layers ) .
• This reduces the dependencies between layers and allows changes to
be made easily because it affects only the next layer.
• 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.
• Changes to a subsystem affects many systems above. Therefore,
this is less robust then a closed architecture.
• Problem Statement specifies only the top and bottom layers.
– Top-desired system
– bottom-available resources(h/w,os,…)
• If the disparity between the two is more, introduce intermediate
layers.
• By rewriting layers, we can port a system constructed in layers
between hardware /software platforms.
• It is a good practice to introduce one layer of abstraction
between the application and any sevices provided by the
operating system or hardware.
 Partitions
• Partitions vertically divide a system into several independent
or weakly coupled subsystems, each provide one kind of
service.
• For Ex: a computer operating system includes a file system,
virtual memory management, and device control.
• Ex. Each subsystem may have some knowledge of each
other but this knowledge is not deep.
• Diff from layers:
1. Layers vary in their level of abstraction. Partitions divide a
system into pieces –similar level of abstraction.
2. Layers ultimately depend on each other. Partitions are peers
that are independent or mutually dependent.(peer-to-peer
relationship).
 Combining layers and partition
• Decompose a system into subsystems by combining layers and
partitions. Layers can be partitioned and partitions can be
layered.
• Figure below shows a block diagram of a typical application.
Most large systems require a mixture of layers and partitions .
• Information flow of top level subsystems are to be shown. Ex.
Many computations have the form a pipeline; a compiler is an
example.
• Other systems are arranged in a star, in which a master
subsystem controls all Interactions with other subsystems.
 ATM Ex: Fig below shows the architecture of the ATM system.
There are three subsystems; the ATM stations, the consortium
computer, and the bank computers.
 The topology is a simple star; the consortium computer
communicates with all the ATM stations and with all the bank
computers.
 The architecture uses the station code and the bank code to
distinguish the phone lines to the consortium computer.
 Choosing a software control strategy
• It is better to choose the same kind of control system for the
whole system. There are 2 kinds of control flow:
• External control (concerns externally visible events among
objects) and
• Internal control (flow of control within a process)
• Three kinds of external control:
• Procedure-driven sequential
• Event-driven sequential
• Concurrent
• Internal control exists only in the implementation and therefore
is neither concurrent nor sequential.
 Unlike external events, internal transfers of control, such as
procedure calls or intertask calls.
 Three kinds of control flow are common: procedure calls, quasi-
concurrent calls and concurrent intertask calls.
 Procedure-driven Control

 In a procedure-driven sequential system, control resides within

the program code. Procedures request external input and then
wait for it; when input arrives, control resumes within the
procedure that made the call.
 The location of the program counter and the stack of procedure
calls and local variables define the system state.
 The major advantage of procedure-driven is that it is easy to
implement with conventional languages.
 The disadvantage is that it requires the concurrency inherent in
objects to be mapped into a sequence flow of control.
 The designer must convert events into operations between
objects. A typical operation correspond to a pair of events: an
output event that performs output and requests input and an
input event that delivers the new values.
 The procedure-driven paradigm is suitable only if the state
model shows a regular alternation of input and output events.
 Flexible user interfaces and control systems are hard to build
with this style.
 Event-driven Control
 In an event-driven sequential system control resides within a
dispatcher or monitor that the language, subsystem, or os
provides.
 Developers attach application procedures to events, and the
dispatcher send output or enable input but do not wait for it in
line.
 All procedures return control to the dispatcher, rather than
retaining control until it arrives. The program counter and stack
cannot preserve state.
 Procedures must use global variables to maintain state, or the
dispatcher must maintain local state for them. Event-driven
control is more difficult to implement with standard languages
than procedure-driven control.
 Event-driven systems permit more flexible control than
procedure-driven systems. Event-driven systems simulate
cooperating processes within a single multithreaded task; an
errant procedure can block the entire application.
 Event-driven system for external control in preference to a
procedure-driven system, because the mapping from events to
program constructs is simpler and more powerful.
 Concurrent Control
 In a concurrent system, control resides concurrently in several
independent objects, each a separate task.
 Such a system implements events directly as one-way messages
between objects.
 A task can wait for input, but other tasks continue execution.
The OS resolves scheduling conflicts among tasks and usually
supplies a queuing mechanism, so that events are not lost if a
task is executing when they arrive.
 If there are multiple CPUs, then different tasks can actually
execute concurrently.
 Internal Control
 Internal object interactions are similar to external object
interactions, because we can use the same implementation
mechanisms.
 There is important difference- external interactions inherently
involve waiting for events, because objects are independent and
cannot force other objects to respond;
 Objects generate internal operations as part of the
implementation algorithm, so their form of response is
predictable.
 Common Architectural styles
• Batch transformation: a data transformation executed once on
an entire input set.
• Continuous transformation: a data transformation performed
continuously as inputs change.
• Interactive interface: a system dominated by external
interactions.
• Dynamic simulation: a system that simulates evolving real-
world objects.
• Real-time system: a system concerned by strict timing
constraints
• Transaction manager: a system concerned with storing and
updating data, including concurrent access from different
physical locations.
 Batch Transformation
• A batch transformation performs sequential computations.
The application receives the inputs, and the goal is to compute
an answer, there is no ongoing interaction with the outside
world.
• Examples include standard computational problems such as
compilers, payroll processing, VLSI automatic layout etc.,
• The most important inspect of a batch transformation is to
define a clean series of steps.
• Figure below shows the sequence of steps for a compiler. It has
five class models- one for the input, one for the output, and
three for intermediate representations.
• The steps in designing a batch transformation are as follows:
• break the overall transformation into stages , with each stage
performing one part of the transformation
• Prepare class models for the input, output and between pair of
successive stages. Each stage knows only about the models on
either side of it
• Expand each stage in turn until the operations are
straightforward to implement
• Restructure the final pipeline for optimization.
• Continuous Transformation
• A Continuous transformation is a system in which the outputs
actively depend on changing inputs.
• A batch transformation computes the outputs only once, a
continuous transformation updates outputs frequently.
• Applications include signal processing, windowing systems
etc., One way to implement a continuous transformation is with
a pipeline of functions.
• Fig below shows the example of a graphics application.
• The steps in designing a pipeline for a continuous
transformation are as follows.
• Break the overall transformation into stages, with each stage
performing one part of the transformation
• Define input, output and intermediate models between each pair
of successive stages as for the batch transformation.
• Differentiate each operation to obtain incremental changes to
each stage. That is, propagate the incremental effects of each
change to an input through the pipeline as a series of
incremental updates.
• Add additional intermediate objects for optimization.
 Interactive Interface
 An interactive interface is a system that is dominated by
interactions between the system and external agents, such as
humans or devices.
 The external agents are independent of the system, so the system
cannot control the agents, although it may solicit responses from
them.
 Examples include a forms-based query interface, workstation
windowing system etc.,
 The steps in designing an interactive interface are as follows
 Isolate interface classes from the application classes
 Use predefined classes to interact with external agents, if
possible. For example, windowing systems have extensive
collections of predefined windows, menus, buttons , forms and
other kinds of classes ready to be updated to applications.
 Use the state model as the structure of the program. Interactive
interfaces are best implemented using concurrent control
(multitasking) or event-driven control (interrupts or call-backs).
Procedure-driven control (writing output and then waiting for
input in-line) is awkward for anything but rigid control
sequences.
 Isolate physical events from logical events. Often a logical event
corresponds to multiple physical events. For example, a
graphical interface can take input from a form, from a pop-up
menu, from a function button on the keyboard, from a typed in-
command sequence or from an indirect command file.
 Fully specify the application functions that are invoked by the
interface. Make sure that the information to implement them is
present.
• Dynamic Simulation
• A dynamic simulation models or tracks real-world objects.
Examples include molecular motion modeling, spacecraft
trajectory computation etc.,
• The objects and operations come directly from the application.
There are two ways of implementing control;
• An explicit controller external to the application objects can
simulate a state machine.
• The objects that exchange messages among themselves.
• The steps in designing a dynamic simulation are as
following:
 Identify active real-world objects from the class model. These
objects have attributes that are periodically updated.
 Identify discrete events. Discrete events correspond to discrete
interactions with the object, such as turning power on or
applying the brakes. Discrete events can be implemented as
operations on the object.
 Identify continuous dependencies. Real-world attributes may be
dependent on other real-world attributes or vary continuously
with time, altitude, velocity or steering wheel position for
example. These attributes must be updated at periodic intervals
using numerical approximation techniques to minimize
quantization error.
 Generally a simulation is driven by a timing loop at finite time
scale. Discrete events between objects can often be exchanged
as a part of the timing loop.
• Real-time System
• A real-time system is an interactive system with tight time
constraint on actions.
 Hard real time s/w involves critical application that requires a
guaranteed response within the time constraints.
 Software real time s/w must be also be highly reliable but can
occasionally violate time constraints.
• Real time applications include process control, data acquisition,
communication devices etc.,
• Real time design is complex and involves issues like interrupt
handling, prioritization of tasks etc.,
• Transaction Manager
• A transaction manager is a system whose main function is to
store and retrieve data.
• Most transaction managers deal with multiple users who read
and write data at the same time. Transaction managers are built
on database management system.
• The steps in designing an information system are as follows:
 Map the class model to database structures.
 Determine the units of concurrency-- that is the resources that
inherently or by specification cannot be shared. Introduce new
classes as needed.
 Determine the unit of transaction-- that is the set of resources
that must be accessed together during a transaction. A
transaction succeeds or fails in its entirety.
 Design concurrency control for transactions. Most database
management systems provide this. The system may need to
retry failed transactions several times before giving up.
 Architecture of the ATM System

 Study the explanation from text book.