Design Principles, Design Concepts, Data

Design, Architectural Design-

Architectural Styles, Procedural Design
Design Principles

• Software design is both a process and a model.

• Creative skill, past experience, a sense of what makes "good" software and an
overall commitment to quality are critical success factors for a competent
design. 
• Basic design principles enables the software engineer to navigate the design
process.
• Davis suggests a set of principles for software design, which have been adapted
and extended in the following list:
 The design should
The design process should The design should be "minimize the intellectual
The design should not
not suffer from tunnel traceable to the analysis distance" between the
reinvent the wheel.
"vision". model. software and the problem as
it exists in the real world.

The design should be

The design should be structured to degrade gently,
The design should exhibit Design is not coding,
structured to accomodate even when aberant data,
uniformity and integration.  coding is not design. 
change. events or operating
conditions are encountered.

The design should be The design should be

assessed for quality as it reviewed to minimize
being created, not after the conceptual (semantic)
fact.  errors.
Design Concepts

• Software Design -- An iterative process transforming requirements into a

“blueprint” for constructing the software. 
•  Software design is the process of implementing software solutions to one or
more sets of problems.
• Design concept provides the software designer with a foundation from which
more sophisticated design methods can be applied. 
 What criteria can be used to partition
software into individual components ?
Each helps the
software engineer How is function or data structure detail
to answer the separated from a conceptual
following representation of the software ?
questions :
What uniform criteria define the
technical quality of a software design ?
 M.A. Jackson once said,
"The beginning of wisdom for a software engineer
is to recognize the difference between getting a
program to work, and getting it right."
 Abstraction
Refinement 
The following Modularity
are the basic Software Architecture
concepts for the
software Control Hierarchy
design: Structural Partitioning
Data Structure
Software Procedure
Information Hiding
 Abstraction allows designers to focus on
solving a problem without being concerned
about irrelevant lower level details.

Abstraction
There are three types of abstraction
available : 
Procedural Data Control
abstraction  abstraction abstraction
Procedural abstraction – a sequence of instructions that have a specific and limited
function. Eg: Word OPEN for a door. 

Data abstraction – a named collection of data that describes a data object. Data
abstraction for door would be a set of attributes that describes the door (e.g. door
type, swing direction, weight, dimension). 

Control abstraction – a program control mechanism without specifying internal

detail. It is used to coordinate all activities in operating system.
Refinement

• Stepwise refinement is a top-down design strategy Refinement

• Refinement is actually a process of elaboration.
• It begin with a statement of function (or description of information) that is
defined at a high level of abstraction and reach at the lower level of abstraction.
• Abstraction and refinement are complementary concepts
 Single attribute of software that allows a program to be
intellectually manageable

Software is divided into separately named and addressable

components, often called modules, that are integrated to satisfy
problem requirements.
Modularity This leads to a "divide and conquer" conclusion—it's easier to
solve a complex problem when you break it into manageable
pieces. 

Modularity enhances design clarity, which in turn eases

implementation, debugging, testing, documenting, and
maintenance of the software product. 
Architecture

• The overall structure of the software and the ways in which the structure provides
conceptual integrity for a system.
• Shaw and Garlan (1996) suggest that software architecture is the first step in
producing a software design. 
• They distinguish among three design levels:
1. Architecture design
2. Code design
3. Executable design
Architecture design : It associates the system capabilities
identified in the requirements specification with the system
components that will implement them. Components are usually
modules, and the architecture al describes the interconnections
among them.

Code design involves algorithms and data structures, and the

components are programming language primitives such as
numbers characters, pointers, and control threads.

Executable design addresses the code design at a lower level of

detail still. It discusses memory allocation, data formats, bit
patterns, and so on.
Control Hierarchy

• Control Hierarchy also called program structure, represents the organization of

program components and implies a hierarchy of control.
• The set of components to which arrows are drawn is called scope of control of
the components.
• The components invoked by the given component are collectively referred to as
the scope of effect.
Structural Partitioning

• If the architectural style of a system is hierarchical, the program structure can be

partitioned both horizontally and vertically.
• Horizontal partitioning defines separate branches of the modular hierarchy for each
major program function.
• Control modules, represented in a darker shade are used to coordinate communication
between and execution of the functions.
•  The simplest approach to horizontal partitioning defines three partitions-
input, data transformation (often called processing) and output.
• Vertical Partitioning – Also called as factoring, suggests that
control and work should be distributed top-down in the
program structure.
• Top – level modules should perform control functions and
do little actual processing work. 
• Whereas the modules that reside low in the structure should
be the workers, performing all input, computation and
output task
Data Structure

• Data structure is a representation of the logical relationship among individual elements

of data.
• Because the structure of information will invariably effect the final procedural design,
data structure is an important as program structure to the representation of software
architecture.
• Data structure dictates the organization, methods of access, degree of associativity, and
processing alternatives for information.
• The organization and complexity of a data structure are limited only by the ingenuity of
the designer.
Software Procedure

• Program structure defines control hierarchy without regard to the sequence of

processing and decisions. 
• Software procedure focuses on the processing details of each module
individually.
• Procedure must provide a precise specification of processing, including
sequence of events, exact decision points, repetitive operations, and even data
organization and structure.
Information Hiding

• Information hiding is a fundamental design concept for software.

• The principle of information hiding was formulated by Parnas.
• When a software system designed using the information hiding approach, each module in
the system hides the internal details of its processing activities and modules communicate
only through well-defined interfaces.
• According to Parnas, design should begin with a list of difficult design and decisions and
design decisions that are likely to change. Each module is designed to hide such a decision
from the other modules. Because these design decisions transcend execution time, design
modules may not correspond to processing steps in the implementation of the system.
Data Design
• Data design is the first design activity, which results in less
complex, modular and efficient program structure. 
• The data objects, attributes, and relationships depicted in entity
relationship diagrams and the information stored in data
dictionary provide a base for data design activity.
• During the data design process, data types are specified along with
the integrity rules required for the data.
• For specifying and designing efficient data structures, some
principles should be followed.
These principles are listed below :-

The data structures needed for implementing the software as well-as the operations that can be applied on them should be
identified.

A data dictionary should be developed to depict how different data objects interact with each other and what constraints are to be
imposed on the elements of data structure.

Stepwise refinement should be used in data design process and detailed design decisions should be made later in the process.

Only those modules that need to access data stored in a data structure directly should be aware of the representation of the data
structure.

A library containing the set of useful data structures along with the operations that can be performed on them should be
maintained.

Language used for developing the system should support abstract data types.
 Component Level

• At the program component level, the design of data

structures and the algorithms required to manipulate them
The structure of is necessary, if high-quality software is desired.

data can be viewed

at three levels, Application Level

namely, program c • At the application level, it is crucial to convert the data

model into a database so that the specific business
omponent level, objectives of a system could be achieved.

application level, Business Level

and business level. • At the business level, the collection of information stored in
different databases should be reorganized into data
warehouse, which enables data mining that has an
influential impact on the business.
Architectural Design
• The overall structure of the software and the ways in which
the structure provides conceptual integrity for a system.
• They distinguish among three design levels:
   1. Architecture design
   2. Code design
   3. Executable design
• Just as buildings reflect a particular architectural style, so, too, can
we characterize software architectural styles.
• A style involves its components.
 Pipes and filter
Object-oriented design
Shaw and
Implicit invocation
Garlan note that
there are seven Layering
commonly used Repositories
styles :
Interpreters
Process control
Pipes and Filter

• A component is a pipe-and-filter
system, illustrated in figure 9.1, has
streams of data called pipes, for input
and output.
• Often, the transformation of the data
from input to output is begun before
the component, called a filter, finishes
reading the input stream.
• In this type of system, the filter are independent and each is not aware of the existence or
functions of the system's other filters.
• In addition, the correctness of the systems output does not depend on the order in which
the filters are applied.
 1. The designers can understand the entire system's
effects on input and output as the composition of
There are the filters.
2. Since any two filters can be linked together, the
several filters can be reused easily on other systems.
important 3. System evolution is simple, because new filters can

properties of 4.
be added and old filters removed with relative ease.
Because of filter independence, designers can
pipe and filter simulate system behaviour and analyze properties

systems: such as throughput.

5. They allow concurrent execution of filters.
Object-oriented Design

• The system requirements can be organized by objects and their abstract types. 
• The design can also build its components around abstract data types. 
• An object based design must have two important characteristics: 
• The object must preserve the integrity of the data representation, and the data
representation must be hidden from other objects. 
• One object must know the identity of the other objects in order for them to
interact.
Implicit invocation

• The design model for implicit invocation is event-driven, based on the notion of broad-casting. 
• Instead of invoking a procedure directly, a component announces that one or more events have taken place.
• Then other components can associate a procedure with those events (called registering the procedure), and
the system invokes all such registered procedures. 
• Data exchange in this type of system must be done through shared data in a repository. This type of design is
often used in packet-switched networks.
• This style of design is especially useful for reusing design components from other systems. Because any
component can register for an event, a reused component can be added to the system and can register itself,
independent of the other components like-wise, as the system evolves and requires upgrades, old components
can be removed and new ones added easily.
Layering

• Layered systems are organized as shown in example of

figure 9.2. 
• The layers are hierarchical; each layer provides services to
the one outside it and acts as a client to the layer inside it. 
• In some systems, every layer has access to some or all of the
other layers.
• Layered architecture take great advantage of the notion of
abstraction. Each layer can be considered to be an
increasing level of abstraction.
 Finally, the fourth layer
The inner layer, The third layer is key provides authentication.
cryptography, includes, management; it allows a This layer manages a
The second layer, the file
functions to encrypt and component to "sign" for a password file that is stored
level interface, encrypts and
decrypt a key that is used in file, verifies the signature, in encrypted form, and it
decrypts a file. 
the basic encryption scheme and computes a hash code to requests users to provide
for the system.  gain access to the file.  identification (such as the
users name) and a password.
Repositories

• There are two types of components in a repository

(a) a central data store
(b) a collection of components that operate on it to store, retrieve, and update information.
• Part of the challenge of designing à repository is deciding how the two types of
component will interact.
(a) In a traditional database, the transactions, in the form of input stream, trigger process
execution.
(b) In a blackboard, the central store controls the triggering of processes.
 A blackboard has three aspects :

01 02 03

The blackboard itself : The Knowledge sources : The The control : The control is
blackboard contains a hierarchy of knowledge sources are separate determined by the state of the
problem-solving state data that are pieces of data, also application- blackboard. As the blackboard
dependent on the application being dependent, that interact only by changes state, the knowledge
designed. using the blackboard. sources respond, much as we noted
in the implicit invocation style.
Blackboard designs have appeared in
many systems, notably signal
processing and pattern recognition.
Interpreters

• An interpreter takes a string of characters called pseudocode, and converts it

into actual code that is then executed.
• Thus, the interpreters can be used not only to convert programming language to
machine code, but also to convert any kind of encoding to a more explicit or
usable form.
• To this end, the interpreter is composed of four parts as shown in figure.
1. A memory to contain the
pseudocode to be interpreted.
2. An interpretation engine to
convert the pseudocode and
simulate the program it
represents.
3. The current state of the
interpretation engine.
4. The current state of the program
being simulated.
Process Control

• Shaw and Garlan (1996) point out that process control systems are very different from function -
or object-based designs, which are characterized by the kinds of components that appear in the
design.
• Process control systems are characterized not only by the type of component, but also by the
relationships that hold among them.
• The purpose of a process control system is to maintain specified properties of process outputs at or
near specified reference values called set points.
• For example, your home heating and cooling system uses a thermostat to monitor air temperature
and then controls the furnace and air condition to keep the air temperature within an acceptable
range.
Procedural design
• Procedural design, also called component level design, occurs after data, architectural, and
interface designs have been established.
• The intent is to translate the design model into operational software.
• But the level of abstraction of the existing design model is relatively high, and the abstraction level
of the operational program is low.
• The translation can be challenging, opening the door to the introduction of subtle errors that are
difficult to find and correct in later stages of the software process. 
• The translation can be challenging, opening the door to the introduction of subtle errors that are
difficult to find and correct in later stages of the software process.
• It is possible to represent the component-level design using a programming language.
• In essence, the program is created using the design model as a guide.
• An alternative approach is to represent the procedure design using some intermediate (e.g.,
graphical, tabular, or text-based representation that can be translated easily into source code.
Thank You