Design is

the creative process of transforming a

problem into a solution (verb)
the description of the solution (noun)

Design
Design starts from the requirements and
transforms them into a working system.
Required to satisfy two groups when design
is produced
Customers need to understand what the system
is to do.
System builders must understand how the system
is to work

For this reason we produce a conceptual

design and a technical design

System
Designers

Conceptual
Design

Technical
Design

See Textbook (SWE

TnP Shari Lawrence
PfLeeger)
pg. 225 for this figure

Conceptual Design
A conceptual design focuses on the systems
functions.
It describes:

system boundary, (what is within and what is not)

entities, (element involved in activity)
attributes, (characteristics of entity)
relationships (among entities and activities)

Also, it answers the following questions:

Where will the data come from?

What will happen to the data in the system?
What will the system look like to users?
What is the timing of events?
What will the reports and screens look like?

Conceptual
A good conceptual design should have the
following characteristics:
written in the customer's language
contains no technical jargon
describes the functions of the system
independent of implementation
linked to the requirements documents

Design

The conceptual design enables the customer to

understand what the system will do by explaining
the observable external characteristics of the
system.

Technical Design
Technical design describes

hardware configuration,
software needs,
communications interfaces,
input and output of the system,
network architecture
anything else that translates the requirements into
a solution to the customer's problem.

It usually includes at least the following:

a description of the major hardware components
and their functions
the hierarchy and function of the software
components
the data structures and the data flow

Decomposition and Modularity

Wasserman suggests that designs
are created in one of five ways:
Modular decomposition
Data-oriented decomposition
Event-oriented decomposition
Outside-in design
Object-oriented design

Modular Decomposition
This construction is based upon assigning
functions to components.
The designer begins with a high-level
description of the functions that are to be
implemented
and builds lower-level explanations of how
each component will be organized and
related to the other components

Data-oriented Decomposition
This design is based on external data
structures.
The high-level description depicts
general data structures,
and lower-level descriptions provide
detail on what data elements will be
involved and how they are related.

Event-oriented Decomposition
This design is based on events that the
system must handle and uses
information about how events change
the system's state.
The high-level description catalogues
the various states
and the lower-level descriptions
describe how state transformations take
place.

Outside-in Decomposition
This black box approach is based on
user inputs to the system.
That is, the high-level description lists
all possible inputs a user can make,
then the lower-level descriptions
address what the system does with
each input (including what outputs are
produced).

Object-oriented Decomposition
This design identifies classes of objects
and their interrelationships.
At the highest level, each object type is
described.
At lower levels, the object attributes and
actions are discussed
the design explains how objects are
related to one another.

Decomposition and Modularity

Thus a design can be derived by
working from system data descriptions,
events, user inputs, high-level functional
descriptions, or a combination,
and creating a hierarchy of information
with increasing detail.

Decomposition and Modularity

Architecture Styles and Strategies

Shaw and Garlan, suggest that software
architecture is also the first step in
producing a software design. They
distinguish between three design levels:
Architecture
Code design
Executable design

Architecture
Architecture associates the system
capabilities identified in the requirements
specification with the system components that
will implement them.
Components are usually modules and the
architecture also describes the
interconnections among them.
In addition, the architecture defines operators
that create systems from subsystems.

Code Design
Code design involves
algorithms
data structures such as numbers, characters,
pointers and control thread.

In turn, there are primitive operators,

including
the language's arithmetic and data manipulation
primitives, and
composition mechanisms such as arrays, files and
procedures.

Executable Design
Executable design addresses the code
design at a lower level of detail still.
It discusses memory allocation, data
formats, bit patterns etc.

Strategies
It is useful to work from the top down,
designing
an architecture,
then the code design and
finally the executable design.

In reality, designers move back and forth from

one level to another, as they understand
more about the solution and its implications.
These iterations mean that the designers
must work on each level in small chunks as
their understanding and creativity permit.

Characteristics of Good Design

High quality designs should have the following
characteristics that lead to quality products:

Ease of understanding
Ease of implementation
Ease of testing
Ease of modification
Correct translation from requirements specification

Modifiability is especially important since changes

to requirements or changes for fault correction,
sometimes result in a design change

Software Design Document (SDD)

Independence of Components
Reasons for independence of components:
easier to understand how a component works if
it is not intricately tied to others
easier to modify a independent component
helps to isolate and fix cause of a system failure
which is traced back through the code to the
design

Good Design Coupling / Cohesion

To recognise and measure the
degree of component independence
in a design we use two concepts:
coupling
cohesion

Coupling
Highly coupled
there is a great deal of dependence
between them.

Loosely coupled
There is some dependence, but the
interconnections among components are
weak

Uncoupled
components have no interconnections at
all
they are completely independent

Coupling

Types of Coupling
Content
occurs when on component modifies another
modified component is completely dependent
on modifying one
May occur when one component modifies
internal data item in another component
OR when one component branches into the
middles of another component

Example of Content Coupling

Example of Common Coupling

Types of Coupling

Types of Coupling

Cohesion
Cohesion refers to the internal glue(intradependence) with which a component is
constructed.
The more cohesive a component, the more
related are the internal parts of the
component to each other and to its overall
purpose.
In other words, a component is cohesive if all
elements of the component are directed toward
and are essential for performing the same task.

Types of cohesion

Coincidental
Worst degree of cohesion
Parts of component are
unrelated to one another
These parts placed for
reasons of convenience

Logical
Next higher level of
cohesion, though still not
desirable
Several logically related
function or data elements
are placed in the same
component
e.g. one component may
read all kinds of input
regardless of where input
is coming from or how it
will be used

Temporal
Component performs
several functions in
sequence, but
functions are related
only by time
e.g. component used
to initialise a system
or set of variables

Procedural
Functions must be
performed in a certain
order
e.g. data must be
entered before they
can be checked and
manipulated

Communicational
Associate functions
because they operate on or
produce the same data set
e.g. unrelated data fetched
together because the fetch
can be done with only one
disk or tape access
Destroys modularity and
functional independence
of design

Sequential
The output from one
part of a component is
input to next part of
component
Possible that
component will not
contain all of
processing related to a
function

Functional
Every processing
element is essential to
performance of a
single function, and all
elements contained in
one component
Performs only that
function for which it is
designed

Control Issues
We have to decide how many
components are under the control of a
particular component.
fan-in is the number of components
controlling a particular component
fan-out is the number of components
controlled by a component.

Control example

Faults and Failures

Fault occurs when a human makes a
mistake, called an error, in performing some
software activity
Inside view of the system seen by developer

Failure is a departure from the systems

required behaviour
Outside view of problem user sees

Exception Handling
We design systems defensively, i.e. we take
an active role in anticipating failures before
they occur.
Exceptions are situations that are counter to
what we really want the system to do.
Typical exceptions:
failure to provide a service
providing the wrong service or data
corrupting data

Exception Handling
For each exception we identify, we can
handle it in one of three ways:
Retrying: We restore the system to its previous
state and try again to perform the service using
perhaps, a different strategy
Correct: We restore the system to its previous
state, correct some aspect of the system, and try
to perform the service using the same strategy
Report: We restore the system to its previous
state, report the problem and do not provide the
service

Technical Design

Architectures and
Some Examples

Architecture styles

Pipes and filters

Object-oriented design
Implicit invocation
Layering
Repositories

Pipes and filters

Two components:
Pipe streams of data for input and output
Filter transforms data from input to output

Filters are independent

Not aware of the existence or functions of the
systems other filters

Pipes and filters

Pipes and filters

Advantages
Designers can understand the entire systems effects on
inputs and output as the composition of filters
Since any two filters can be linked together, the filters
can be reused easily on other systems
System evolution is simple, because new filters can be
added and old filters removed with relative ease
Because of filter independence, designers can simulate
system behaviour and analyse system properties (such
as throughput)
Allow concurrent execution of filters

Pipes and filters

Disadvantages
Encourage batch processing, which is not good
for handling interactive applications
When two data streams are related, the system
must maintain a correspondence between them
Independence of filters means that some filters
may duplicate preparatory functions that are
performed by filters, thereby affecting
performance and making code quite complex

Object-Oriented Design
This design builds components around
abstract data types
It has two important characteristics:
Object must preserve the integrity of the data
representation
Data representation must be hidden from other
objects (encapsulation)

Object-Oriented Design
Advantages
Encapsulation makes it easy to change the
implementation without greatly disturbing the rest of
the system
Combining object access routines with the data
manipulated by them, encourages designers to
decompose the underlying problem into a collection of
interacting agents

Disadvantages
One object must know the identity of the other objects
in order for them to interact

Implicit Invocation
This design is event-driven and based on the
notion of broadcasting
Instead of invoking a procedure directly, a component
announces that one or more events have taken place
Other components can associate a procedure with those
events registering a procedure
System invokes all such registered procedures

Data exchanged must be done through a shared

data in a repository
In general, when a component or system
announces an event, it does not know which
components will be affected by the event
For this reason there is usually some explicit invocation
as well

Implicit Invocation
Advantage
Especially useful for reusing design component
from the other systems

Disadvantage
Lack of assurance that a component will
respond to an event
The dependence on the context and sequence of
events makes it very difficult to test the system and
check for correctness

Layering
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, each layer has to access some or all of
the other layers
In other systems, a given layer has access only to
adjacent layers

Design includes the protocols that explain how

each pair of layers will interact

Layering

Layering
Advantages
Each layer can be considered to be an increasing level
of abstraction, and the designers can use the layers to
decompose a problem into a sequence of more abstract
steps
Because there are restrictions on which layers interact
with other layers, it is relatively easy to add or modify a
layer as the need arises.
Usually such changes affect only the two adjacent layers

Layering
Disadvantages
Not easy to structure a system in layers, as
multiple layers of abstraction are not always
evident when we examine a set of requirements
Even when a layered design is created, the
system performance may suffer from the extra
coordination among the layers

Repositories
Has two types of components
A central data store
A collection of components that operate on it to store,
retrieve, and update information

The challenge in this design, lies in deciding how

the two types of components will interact
Traditional databasethe transactions, in the form
of an input stream, trigger process execution
Blackboardthe central store controls the
triggering of the process

Repositories

Repositories
Advantage
Its openness as data representation is often
made available to several vendors so that they
can build tolls to access the repository

Disadvantage
Shared data must be in a form acceptable to all
knowledge sources, even if the knowledge
sources themselves are radically different

End of Lesson 5 :: Design

Thank you