UNIT-IV

DESIGN

CHAPTER OBJECTIVE:
You should able to design the
• Application using UML diagrams.
• Architecture of the overall system.
• Subsystems of application which is modularized.

Overview of System Design

System design is the high-level strategy for solving the problem and building a
solution.
The steps involved in system design are:
1. Estimating system performance
Prepare a rough performance estimate. The purpose is not to achieve high
accuracy, but merely to determine if the system is feasible.
2. Making a reuse plan
There are 2 different aspects of reuse – using existing things and creating
reusable new things. It is much easier to reuse existing things than to design new
things. Reusable things include models, libraries, patterns, frameworks etc.

Breaking a system into subsystems

First step of system design is to divide the system in a small number of
subsystems. Each subsystem encompasses aspects of the system that share some common
property such as similar functionality, same physical location, execution on same kind of
hardware.
A subsystem is a package of classes, associations, operations, events and
constraints interrelated and have a well defined small interface with other subsystems.
Subsystems are identified by the services provided. Determining subsystems allow a
division of labor so each can be designed by a separate team.
 Most interactions should be within subsystems rather than across boundaries and
it reduces dependencies among subsystems. Relationship between two subsystems can
be client-supplier or peer-to-peer. In a client-supplier relationship, the client calls on the
supplier for service. Client must know the interface of the supplier but not vice versa. In a
peer-to-peer relationship, each can call on the other and therefore they must know each
others interfaces. One way communication (client-supplier) is much easier to build,
understand and change than two way (Peer-to-Peer).

The decomposition of systems into subsystems may be organized as a sequence of

layers or partitions. Layered system is an ordered set of virtual worlds, a layer knows
about the layer below but not above. A client supplier relationship exists between lower
layers and upper layers. Partitions divide into several independent SS, each providing a
type of service. A system can be a hybrid of layered and partitioned.

Choosing the system topology

System Topology defines the flow of information among subsystems. The flow
may be a pipeline (compiler) or star which has a master that controls all other
interactions. Try to use simple topologies when possible to reduce the number of
interactions between subsystems.

In analysis as in the real world and in hardware all objects are concurrent. In
implementation not all software objects are concurrent because one processor may
support many objects. An important goal of system design is to identify which object
must be active concurrently and which objects have activity that is mutually exclusive
(not active at the same time). The latter objects can be folded into a single thread of
control or task (runs on a single processor).
Identifying Concurrency
• Dynamic Modeling is the guide to concurrency - Two objects are said to be inherently
concurrent if they can receive events at the same time without interacting. If the
events are unsynchronized, the objects cannot be folded into a single thread of
control. (engine and wing control on an airplane must operate concurrently)

• Two subsystems that are inherently concurrent need not necessarily be implemented
as separate hardware units. The purpose of interrupts, Operating System and tasking
mechanism is to simulate logical concurrency in a uniprocessor - so if there are no
timing constraints on the response then a multitasking Operating System can handle
the computation.

• All objects are conceptually concurrent, but many objects are interdependent. By
examining the state diagram of individual objects and the exchange of events between
them, many objects can be folded into 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 - thread remains in a state diagram until an object sends an event to another
object and waits for another event.

• On each thread of control only a single object is active at a time. Threads of control
are implemented as tasks in computer systems.

Defining concurrent task:

Although all objects are conceptually concurrent, in practice many objects in a
system are inter-dependent. By examining the state diagrams of individual objects & the
exchange of events among them, many objects can often be folded together on to a single
thread of control. A thread of control is a path through a set of state diagrams on which
only a single objects at a time is active. 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. Tdshe thread
splits if the object sends an event & continues executing.
 On each thread of control, only a single objects at a time is active. Threads of
control are implemented as tasks in computer system. For example, while the bank is
verifying an account or processing a bank transaction, the ATM machine is idle. If the
ATM is controlled directly by a central computer, then the ATM object can be folded
together with the bank transaction object as a single task.

ALLOCATING SUBSYTEMS TO PROCESSORS & TASKS:

Each concurrent subsystems must be allocated to a hardware unit,either a general purpose

processor or a specialized functional unit. The system designer must:

1) Estimate performance needs & the resources needed to satisfy them.

2) Choose hardware or software implementation for subsystems.
3) Allocate software subsystems to processors to satisfy performance needs &
minimize inter-processor communication.
4) Determine the connectivity of the physical units that implement the subsystem.

Estimating Hardware Resource Requirements

• The decision to use multiple processors or hardware functional units is based on
the need for higher performance than a single CPU can provide (or fault tolerant
requests). Numbers of processors determine the volume of computations and
speed of the machine.

• The system designer must estimate the required CPU 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. Experimentation is often useful to assist in
estimating.
Hardware/Software Tradeoffs
Hardware can be viewed as a rigid but highly optimized form of software. The
system designer must decide which subsystems will be implemented in hardware and
which in software.

Subsystems are in hardware for 2 reasons:

• Existing hardware provides exactly the functionality required – e.g. floating point
processor
• Higher performance is required than a general purpose CPU can provide.

Compatibility, cost, performance, flexibility are considerations whether to use

hardware or software. Software in many cases may be more costly than hardware because
the cost of people is very high. Hardware of course is much more difficult to change than
software.

Allocating Tasks To Processors

Tasks are assigned to processors because:
• Certain tasks are required at specific physical locations
• Response time or information flow rate exceeds the available communication
bandwidth between a task and a piece of hardware.
• Computation rates are too great for single processor, so tasks must be spread
among several processors

Determining Physical connectivity:

After determining the kinds & relative numbers of physical units, the system
designer must choose the arrangement & form of the connections among the physical
units. The following decisions must be made:
1) choose the topology of connecting the physical units. Association in the object
model, client-supplier relationship in the functional model corresponds to the
physical connections. Some connections may be indirect, but the designer must
attempt to minimize the connection cost of important relationships.
 2) Choose the topology of repeated units. If several copies of a particular kind of
unit or group of units are include for performance reasons, their topology must be
specified. The object model & functional model are not useful guides. The
topology of repeated units usually has a regular pattern, such as a linear sequence,
a matrix, a tree or a star. The designer must consider the expected arrival patterns
of data and the proposed parallel algorithm for processing it.
3) Choose the form of the connection channels and the communication protocols.
The system design phase may be too soon to specify the exact interfaces among
units, but the general interaction mechanisms & protocols must usually be chosen.
Interactions may be asynchronous, synchronous or blocking . The bandwidth of
the communication channels must be estimated and the correct kind of connection
channels chosen.

Management Of Data Stores

• The internal and external data stores in a system provide clean separation points
between subsystems with well defined interfaces. Data stores may combine data
structures, files, and database implemented in memory or on secondary storage
devices. The different data stores provide trade-offs between cost, access time,
capacity and reliability.
• Files are cheap, simple and permanent form of data store. File operations are low
level and applications must include additional code to provide a suitable level of
abstraction. File implementations vary from machine to machine so portability is
more difficult.
• Databases are powerful and make applications easier to port. They do have a
complex interface and may work awkwardly with programming languages.

The kind of data that belongs in a Database:

• Data that requires access at fine levels of detail by multiple users
• Data that can be efficiently managed by DBMS commands
• Data that must be ported across many hardware and operating system platforms
• Data that must be accessible by more than one application program.
The kind of data that belongs in a file:
• Data that is voluminous but difficult to structure within the confines of a Database
(graphics bit map)
• Data that is voluminous and of low information density (debugging data,
historical files)
• Raw data that is summarized in the Database
Advantages of Using A Database

• Handles crash recovery, concurrency, integrity

• Common interface for all applications
• Provides a standard access language - SQL

Disadvantages Of Using A Database

• Performance overhead
• Insufficient functionality for advanced applications - most databases are
structured for business applications.
• Awkward interface with programming languages.

Handling Global Resources

• The system designer must identify the global resources and determine
mechanisms for controlling access to them - processors, tape drives, etc
• If the resource is a physical object, it can control itself by establishing a protocol
for obtaining access within a concurrent system. If the resource is logical entity
(object ID for example) there is a danger of conflicting access. Independent tasks
could simultaneously use the same object ID. Each global resource must be
owned by a guardian object that controls access to it.

Choosing Software Control Implementation

There are two kinds of control flows in a software system: external control and
internal control. Internal control is the flow of control within a process. It exists only in
the implementation and therefore is not inherently concurrent or sequential. External
control is the flow of externally visible events among the objects in the system.
There are three kinds of external control:
 • Procedure driven systems: control resides within program code; it is easy to
implement but requires that concurrency inherent in objects be mapped into a
sequential flow of control.
• Event driven systems - control resides within a dispatcher or monitor provided by
the language, subsystem or operating system. Application procedures are attached
to events and are called by the dispatcher when the corresponding events occur.
• Concurrent systems: control resides concurrently in several independent objects,
each a separate task.

Handling Boundary Conditions

We must be able to handle boundary conditions such as initialization, termination
and failure.
1. Initialization: The system must be brought from a quiescent initial state to a
sustainable steady state condition. Things to be initialized include constant data,
parameters, global variables, tasks, guardian objects and possibly the class hierarchy
itself.

2. Termination: It is usually simpler than initialization because many internal objects

can simply be abandoned. The task must release any external resources that it had
reserved. In a concurrent system, one task must notify other tasks of its termination.

3. Failure: It is the unplanned termination of a system. Failure can arise from user errors,
from the exhaustion of system resources, or from an external breakdown.

Setting Trade-Off Priorities

Cost, maintainability, portability, understandability, speed, may be traded off during
various parts of system design.
Common Architectural Frameworks
There are several prototypical architectural frameworks that are common in
existing systems. Each of these is well-suited to a certain kind of system. If we have an
application with similar characteristics, we can save effort by using the corresponding
architecture, or at least use it as a starting point for our design. The kinds of systems
include:

1. Batch transformation: It is a data transformation executed once on an entire input set.

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. There is no ongoing
interaction with the outside world. The most important aspect of the batch transformation
is the functional model which specifies how input values are transformed into output
values. The steps in designing a batch transformation are:

1) Break the overall transformation into stages, each stage performing one part of
the transformation. The system diagram is a data flow diagram. This can usually be taken
from the functional model.

2) Define intermediate object classes for the data flows between each pair of
successive stages.

3) Expand each stage in turn until the operations are straightforward to

implement.

4) Restructure the final pipeline for optimization.

2. Continuous Transformation: It is a system in which the outputs actively depend on

changing inputs and must be periodically updated. Because of severe time constraints, the
entire set of outputs cannot usually be recomputed each time an input changes. Instead,
the new output values must be computed incrementally.
The transformation can be implemented as a pipeline of functions. The effect of each
incremental change in an input value must be propagated through the pipeline. The steps
in designing a pipeline for continuous transformation are

1. Draw a DFD for the system. The input and output actors correspond to data
structures whose value change continuously. Data stores within the pipeline show
parameters that affect the input-to-output mapping.

2. Define intermediate objects between each pair of successive stages.

3. Differentiate each operation to obtain incremental changes to each stage.

4. Add additional intermediate objects for optimization.

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. The external agents are independent of the system, so their inputs cannot be
controlled. Interactive interfaces are dominated by the dynamic model. The steps in
designing an interactive interface are:

1. Isolate the objects that form the interface from the objects that define the
semantics of the application.

2. Use predefined objects to interact with external agents, if possible.

3. Use the dynamic model as the structure of the program.

4. Isolate physical events from logical events.

5. Fully specify the application functions that are invoked by the interface. Make
sure that the information to implement them is present.
4. Dynamic Simulation: A dynamic simulation models or tracks objects in the real
world. The steps in designing a dynamic simulation are:

1. Identify actors, real-world objects from the object model. The actors have
attributes that are periodically updated. The actors have attributes that are periodically
updated.

2. Identify discrete events. Discrete events correspond to discrete interactions with

the object. Discrete events can be implemented as operations on the object.

3. Identify continuous dependencies.

4. Generally a simulation is driven by a timing loop at a fine time scale. Discrete

events between objects can often be exchanged as part of the timing loop.

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. Most transaction managers must deal with multiple users and concurrency. The
steps in designing a transaction management system are:

1. Map the object model directly into a database.

2. Determine the units of concurrency. Introduce new classes as needed.

3. Determine the unit of transaction.

4. Design concurrency control for transactions.

CLASS DESIGN:
The analysis phase determines what the implementation must do, and the system
design phase determines the plan of attack. The purpose of class design is to complete the
definitions of the classes and associations and choose algorithm for operations.

Overview of Class Design:

Class Design involves the following steps,

• Bridge the gap from high-level requirements to low-level services.

• Realizes use cases with operations.

• Formulate an algorithm for each operations.

• Recurse downwards to design operations that support higher-level operations.

• Refactor the model for a cleaner design.

• Optimize access paths to data.

• Reify behavior that must be manipulated.

• Adjust class structure to increase inheritance.

• Organize classes and associations.

Bridging the Gap:

There is a set of features that you want your system to acheive. You have a set of
available resources. Think of the distance between them as a gap. Your job is to build a
bridge across the gap. There are several sources of high-level needs: Use cases,
application commands, and system operations, and services. Resources includes the
operating system infrastructure, class libraries, and previous applications.

Available Resources

Furthermore, if the gap is large you will need to organize the intermediate
elements into multiple levels. The intermediate elements may be operations, classes, or
other UML, constructs. Inventing good intemediate elements is the essence of successful
design. Often the intermediate elements sre not obvious. There can be many ways to
decompose a high-level operation. If the intermediate elements have already been built,
you can just use them,but the principle of bridging the gap is the same. You still have to
find the elements in a framework or a class library, select them, and fit them together.
Realizing Use Cases:

Usecases define the required behaviour, but they do not define its realization. That
is purpose of design- to choose among the options and prepare for implementation. Each
choice has advantages and disadvantages. It is not sufficient merely to deliver the
behaviour, although that is a primary goal. You must also consider the consequences of
each chooice on performance, reliability, ease of future enhancement, and many other
"ilities". Design is the process of realizing functionality while balancing conflicting
needs.

To start, list the responsibility of a use case or operation. A responsibility is something

that an object knows or something it must do. Finally, assign the new lower-level
operations to classes. If there are no good class to hold an operation, you may need to
invent a new lower-level class.

ATM example:One of the use cases is process transaction. A ttransaction is a set of

Updates and that the logic varies according to withdrawal, deposit,and transfer.

• Withdraw

• Deposit

• Transfer

Designing Algorithm:

Now formulate an algorithm for each operation. The analysis specification tells
what the operation does for its clients, but the algorithm shows how it is done. Perform
the following steps to design algorithm;

• Choose algorithms that minimize the cost of implementing operations.

• Select data structure apprpriate to the algorithms.

• define new internal classes and operations as necessary.

• Assign operations to appropriate classes.

1. Choosing Algorithm:

Many operations are straight forward because they simply traverse the class
model to retrive or change attributes or links. The OCL provides a convinient notation for
expressing such traversals. Pseudocode helps to thing about the algorithm while defering
programming details.

• Computational Complexity

• Ease of implementation and understandability

• Flexibility

2. Choosing Data Structure:

Algorithm require data structure on which to work. During analysis, we focused

on logical structure of system information but during design we must device data
structures that will permit efficient algorithms. The data structures do not add information
to the analysis model but they organize it in a form convinient for algorithms. Many of
these data structures are instances of container classes. Such data structures includes
arrays, list, stack, queue, set, bags, trees, such as priority queues and binary trees.

3. Defining Internal classes and operations:

We may need to invent new, low-level operations during the decompositions of

high-level operations. The expansion of algorithms may lead to create new classes of
objects to hold intermediate results.

4. Assigning operations to classes:

When a class is meaningfull in the real world, the operation on it are usually clear.
During design, we introduce internal classes that do not correspond to real world classes.
The following questions must be asked ourselfs,

• Receiver of action.

• Query versus Update.

• Focal Class

• Analogy to real world.

Recursing Downward:
Downward recursion proceeds in two main ways: by functionality, and by
mechanism.

1.Functionality Layers:

Functionality recursion means that, we take the required high-level functionality

and break it into lesser operations. Trouble occurs in the case of decompositions and
exact statement of top level functionality. To guard against this we must attach operations
to classes and braoden them for reuse.

2. Mechanism Layers:

Mechanism recursion means that, we build a system out of layers of needed

support mechanisms. In providing functionality, we need various mechanism to store
information, sequence control, co-ordinate object, transmit information, perform
computation, and providing other kinds of computing infrastructure.

Refactoring:
The intial design of the set of operations will contain inconsistencies,
redundancies, and inefficiencies. This is natural, because it is impossible to get a large
design correct in one pass. Martin fowler defines refactoring as changes to the internal
strcuture of software to improve its design without altering its external functionality. It
means that we step back, look accross many different classes and operations and
reorganize them to support further development better.

Refactoring may seem like a waste of time, but it is a essential part of any good
engineering process.

Design Optimization:
A good way to design system is to first get the logic correct and then optimize it.
The design model builds on the analysis model. The analysis model captures the logic of
the system while the design model adds development details. We can optimize the
inefficient but semantically correct analysis model to improve performance, but an
optimized system is more obscure and less likely to be reusable. Design optimizable
involves the following tasks:

• Rearrange the computation for greater efficiency.

• Save intermediate results to avoid recomputation.

1. Adding Redundant Associations for Efficient access:

Redundant associations are undesirable during analysis because they do not add
informations. Design has different motivations and focusses on the viability of a model
for implementation. The association from analysis may not form the most efficient
network., When you consider access patterns and relative frequencies. Start by examining
each operation and see what associations it must traverse to obtain its information. Next,
for each operation, note the following,

• Frequency of Access

• Fan-out

• Selectivity

2. Reaaranging Execution Order for Efficiency:

After adjusting the structure of the classs model to optimize frequent traversals,
the next thing to optimize is the algorithm itself. One kay to algorithm optimization is to
eliminate dead paths as early as possible.

3. Saving Derived Values to Avoid Reccomputaion:

Sometimes it is helpful to define the new classes to cache derived attributes and
avoid recomputation. You must update the cache if any of the object on which it depends
are changed. There are three ways to handle updates.

• Explicit Updates

• Periodic recomputation

• Active values
REIFICATION OF BEHAVIOR:
Behavior written in code is rigid. You can execute it, but cannot manipulate it at
run time. Reification is the promotion of something that is not an object into an object.
Behavior usually meets this description. It isn't usually something that you would
normally manipulate. If you reify behavior, you can store it, pass it to other operations,
and transform it. Reification addds complexity but can dramatically exapnd the
flexibility of a system.

You reify bahavior by encoding it into an object and decoding it when it is run.
The resulting run-time cost may or may not be significant. If the encoding invokes high-
level procedures, the cost is only a few indirections. If the entire behavior is encoded ina
different language, however, it must be interpreted, which can be an order of magnitude
slower than direct execution of code.

ADJUSTMENT OF INHERITANCE:

As class design progresses, you can often adjust the definitions of classes and
operations to increase inheritance by performing the following steps;

• Rearrange classes and operations to increase inheritance.

• Abstract common behavior out of groups of classes

• Use delegation to share behavior when inheritance is semantically invalid.

1. Rearrange Classes and Operations:

Sometimes several classes define the same operation and can easily inherit it from
a common ancestor, but more often operations in different classes are similar but not
identical. By adjusting the definitions of the operations, you may be able to cover them
with a single inherited operation.

Before using inheritance, the operations must match. All operations must have the
same signature- that is, the same number and types of arguments and results. In addition,
the operations must have the same semantics. You can use the following kinds of
adjustments to increase the chance of inheritance.

• Operations with optional arguments.

• Operations that are special cases.

• Inconsistent names.

• Irrelevant operations.
2. Abstracting Out Common Behavior:

You will not recognize all opportunities for inheritance during analysis, so it is
worthwhile to reexamine the class model looking for commonality. In addition, you willl
be adding new classes and operations during design. If two classes seem to repeat several
operations and attributes, it is possible that the two classes are really specializatins of the
same thing, when viewed at a higher level of abstraction. When there is common
behavior, you can create a common superclass for the shared features, leaving only the
specialized features in the subclasses. This transformation of the class model is called
Abstracting out a common superclass or common behavior.

3. Using Delegation to share Behavior:

Inheritance is a mechanism for implementation generalization, in which the

behavior of a superclass is shared by all its subclasses. Sharing of behavior is justifiable
only when a true generalization relationship occurs- that is, only when it can be said that
the subclass is a form of the superclass. Operations of the subclass that override the
corresponding operation of the superclass must provide the same services as the
superclass. When class B inherits the A because it behaves the same.

The programmer is then tempted to inherit from the existing class to achieve part
of the implementation of the new class. This can lead to problems if other inherited
operations provide unwanted behavior. We discourage this inheritance of implementation
because it can lead to incorrect behavior.

Delegates consists of catching an operation on one object and sending it to

related object. You delegate only meaningful operations so there is no danger of
inheriting meaningless operations be accident.
ORGANIZING A CLASS DESIGN:
Programs consists of discrete physical units that can be edited, compiled,
imported, or otherwise manipulated. In some languages, such as C and Fortran, the units
are some files. In Ada, Java, the package is an explicit language construct. You can
improve the organization of a class design with the following steps:

• Hide internal information from outside view.

• Maintain coherance of entities.

• Fine-tune defintion of packages.

1. Information Hiding:

During analysis we did not consider information visibility- rather our focus was
on understanding the application. The goals of design are different. During design we
adjust the analysis model so that it is practical to implement and maintain. One way to
improve the visibility of a design is by carefully seperating external specification from
internal implementation. This is called information hiding. Then you can change the
implementation of a class without requiring that clients of the class modify code.

There are several ways to hide information.

• Limit the scope of class-model traversals

• Do not direcctly access foreign attributes

• Define interfaces at a high level of abstraction

• High external objects

• Avoid cascading methods calls

2. Coherence of Entities:

Coherence is another important design principle. An entity, such as a class, an

operation, or a package, is coherent if it is organized on a consistent plan and all its parts
fit together toward a common goal. An entity shoud have a single major theme; it should
not be a collection of unrelated parts. A method should do one thing well. A single
method should not contain both policy and implementation.
Policy is the making of context-dependent decisions. Implementation is the execution of
fully-specified algorithm. Separating policy and implementation greatly increase the
possibility of reuse. The implementation methods do not contain any context
dependencies, so they are likely to be reusable.

3. Fine- Tuning Packages:

During analysis you partitioned the class model into packages. This initial
organization may not be suitable or optimal for implementation. You should define
packages so that their interfaces are minimal and well defined. Te interface between two
packages consists of the associations that relate classes in one package to classes in the
other and operations that access classes across package boundaries.
SUMMARY
• System design is the high-level strategy for solving the problem and building a
solution.
• First step of system design is to divide the system in a small number of
subsystems.
• Each subsystem encompasses aspects of the system that share some common
property such as similar functionality, same physical location, execution on
same kind of hardware.
• System Topology defines the flow of information among subsystems. Each
concurrent subsystems must be allocated to a hardware unit,either a general
purpose processor or a specialized functional unit.
• We must be able to handle boundary conditions such as initialization,
termination and failure.
• Cost, maintainability, portability, understandability, speed, may be traded off
during various parts of system design.
• There are several prototypical architectural frameworks that are common in
existing systems.
• System design is the high-level strategy for solving the problem and building a
solution.
• First step of system design is to divide the system in a small number of
subsystems.
• Each subsystem encompasses aspects of the system that share some common
property such as similar functionality, same physical location, execution on
same kind of hardware.
• System Topology defines the flow of information among subsystems.
• Each concurrent subsystems must be allocated to a hardware unit,either a
general purpose processor or a specialized functional unit.
• We must be able to handle boundary conditions such as initialization,
termination and failure.
 • Cost, maintainability, portability, understandability, speed, may be traded off
during various parts of system design.
• There are several prototypical architectural frameworks that are common in
existing systems.
• During analysis we did not consider information visibility- rather our focus on
understood the application.

KEY TERMS:
• System topology
• Explicit updates

• Periodic recomputation

• Active values

• System design
• Initialization
• Termination
• Failure.
• Subsystem