Software Design

and
Implementation
Content
▪ Software Design
▪ Design Process
▪ Design Approaches
▪ Functional oriented design
▪ Object-oriented design
▪ Interface design
▪ Database design
Lesson Outcomes
At the end of this lesson you will be able to:
▪ Describe the important of Software Design
▪ Identify the important phases of the Design Process
▪ Discuss different design approaches and their
properties
▪ Design MIS with three layers: application layer,
business logic layer and database layer
 Software Design is the
process of deriving a good
solution which satisfies
software requirements
Stages of Design

🞂 Problem understanding
◦ Look at the problem from different angles to discover the
design requirements.
🞂 Identify one or more solutions
◦ Evaluate possible solutions and choose the most appropriate
depending on the designer's experience and available
resources.
🞂 Describe solution abstractions
◦ Use graphical, formal or other descriptive notations to
describe the components of the design.
🞂 Repeat process for each identified abstraction
until the design is expressed in primitive terms.
The Design Process

🞂 Any design may be modelled as a directed

graph made up of entities with attributes which
participate in relationships.
🞂 The system should be described at several
different levels of abstraction.
🞂 Design takes place in overlapping stages. It is
artificial to separate it into distinct phases but
some separation is usually necessary.
Phases in the Design Process
 Design Phases

• Architectural design: Identify sub-systems.

• Abstract specification: Specify sub-systems.
• Interface design: Describe sub-system interfaces.
• Component design: Decompose sub-systems
into components.
• Data structure design: Design data structures to hold
problem data.
• Algorithm design: Design algorithms for problem
functions.
Design

🞂 Computer systems are not monolithic: they are

usually composed of multiple, interacting
modules.
🞂 Modularity has long been seen as a key to
cheap, high quality software.
🞂 The goal of system design is to decode:
◦ What the modules are;
◦ What the modules should be;
◦ How the modules interact with one-another
Procedural Abstraction

🞂 The most obvious design methods involve

functional decomposition.
🞂 This leads to programs in which procedures
represent distinct logical functions in a
program.
🞂 Examples of such functions:
◦ “Display menu”
◦ “Get user option”
🞂 This is called procedural abstraction
 Programs as Functions
🞂 Another view is programs as functions:
input output
x → f → f (x)
the program is viewed as a function from a set I of
legal inputs to a set O of outputs.
🞂 There are programming languages (ML, Miranda,
LISP) that directly support this view of programming

Well-suited to certain Less well-suited to distributed, non-

application domains terminating systems
- e.g., compilers - e.g., process control systems, operating
systems like WinNT, ATM machines
Object-oriented design

– The system is viewed as a collection of

interacting objects.
– The system state is decentralized and each
object manages its own state.
– Objects may be instances of an object class
and communicate by exchanging methods.
Five Criteria for Design Methods
🞂 We can identify five criteria to help evaluate
modular design methods:
◦ Modular decomposability;
◦ Modular composability;
◦ Modular understandability;
◦ Modular continuity;
◦ Modular protection.
Modular Decomposability

🞂 This criterion is met by a design method if the

method supports the decomposition of a problem
into smaller sub-problems, which can be solved
independently.
🞂 In general method will be repetitive: sub-
problems will be divided still further
🞂 Top-down design methods fulfil this criterion;
stepwise refinement is an example of such
method
Hierarchical Design Structure
Top-down Design

• In principle, top-down design involves starting

at the uppermost components in the hierarchy
and working down the hierarchy level by level.
• In practice, large systems design is never
truly top-down. Some branches are designed
before others. Designers reuse experience (and
sometimes components) during the design
process.
Modular Composability

🞂 A method satisfies this criterion if it leads to the

production of modules that may be freely combined
to produce new systems.
🞂 Composability is directly related to the issue of
reusability
🞂 Note that composability is often at odds with
decomposability; top-down design,
◦ for example, tends to produce modules that may not be
composed in the way desired
🞂 This is because top-down design leads to modules
which fulfil a specific function, rather than a general
one
Examples

🞂 The Numerical Algorithm Group (NAG) libraries

contain a wide range of routines for solving
problems in linear algebra, differential
equations, etc.
🞂 The Unix shell provides a facility called a pipe,
written “−”, whereby
◦ the standard output of one program may be
redirected to the standard input of another; this
convention favours composability.
Modular Understandability

🞂 A design method satisfies this criterion if it

encourages the development of modules which
are easily understandable.

🞂 COUNTER EXAMPLE 1. Take a thousand lines

program, containing no procedures; it’s just a long
list of sequential statements. Divide it into twenty
blocks, each fifty statements long; make each block
a method.
🞂 COUNTER EXAMPLE 2. “Go to” statements.
Understandability

• Related to several component characteristics

– Can the component be understood on its own?
– Are meaningful names used?
– Is the design well-documented?
– Are complex algorithms used?
• Informally, high complexity means many
relationships between different parts of the
design.
Modular Continuity

🞂 A method satisfies this criterion if it leads to the

production of software such that a small change in
the problem specification leads to a change in just
one (or a small number of ) modules.
🞂 EXAMPLE. Some projects enforce the rule that no
numerical or textual literal should be used in
programs: only symbolic constants should be used
🞂 COUNTER EXAMPLE. Static arrays (as opposed to
open arrays) make this criterion harder to satisfy.
Modular Protection
🞂 A method satisfied this criterion if it yields
architectures in which the effect of an abnormal
condition at run-time only effects one (or very
few) modules
🞂 EXAMPLE. Validating input at source prevents
errors from propagating throughout the
program.
🞂 COUNTER EXAMPLE. Using int types where
subrange or short types are appropriate.
Five principles for Good Design
🞂 From the discussion above, we can distil five
principles that should be adhered to:
◦ Linguistic modular units;
◦ Few interfaces;
◦ Small interfaces
◦ Explicit interfaces;
◦ Information hiding.
Linguistic Modular Units
🞂 A programming language (or design language)
should support the principle of linguistic modular
units:
◦ Modules must correspond to linguistic units in the language
used

🞂 EXAMPLE. Java methods and classes

🞂 COUNTER EXAMPLE. Subroutines in BASIC are called
by giving a line number where execution is to
proceed from; there is no way of telling, just by
looking at a section of code, that it is a subroutine.
Few Interfaces
🞂 This principle states that the overall number of
communication channels between modules
should be as small as possible:
◦ Every module should communicate with as few others as
possible.
🞂 So, in the system with n modules, there may be a
minimum of n-1 and a maximum of links;
your system should stay closer to the minimum
Few Interfaces
Small Interfaces (Loose Coupling)
🞂 This principle states:
◦ If any two modules communicate, they should exchange
as little information as possible.

🞂 COUNTER EXAMPLE. Declaring all instance

variables as public!
 Coupling
🞂 A measure of the strength of the inter-connections
between system components.
🞂 Loose coupling means component changes are
unlikely to affect other components.
◦ Shared variables or control information exchange lead to
tight coupling.
◦ Loose coupling can be achieved by state decentralization
(as in objects) and component communication via
parameters or message passing.
Tight Coupling
Loose Coupling
 Coupling and Inheritance

• Object-oriented systems are loosely coupled

because there is no shared state and objects
communicate using message passing.
• However, an object class is coupled to its
super-classes. Changes made to the attributes
or operations in a super-class propagate to all
sub-classes.
Reusability

🞂 A major obstacle to the production of cheap

quality software is the intractability of the
reusability issue.
🞂 Why isn’t writing software more like producing
hardware? Why do we start from scratch every
time, coding similar problems time after time
after time?
🞂 Obstacles:
◦ Economic;
◦ Organizational;
◦ Psychological.
Stepwise Refinement

🞂 The simplest realistic design method, widely

used in practice.
🞂 Not appropriate for large-scale, distributed
systems: mainly applicable to the design of
methods.
🞂 Basic idea is:
◦ Start with a high-level spec of what a method is to
achieve;
◦ Break this down into a small number of problems
(usually no more than 10)
◦ For each of these problems do the same;
◦ Repeat until the sub-problems may be solved
immediately.
Explicit Interfaces

🞂 If two modules must communicate, they must

do it so that we can see it:
◦ If modules A and B communicate, this must be obvious
from the text of A or B or both.
🞂 Why? If we change a module, we need to see
what other modules may be affected by these
changes.
Information Hiding
🞂 This principle states:
◦ All information about a module, (and particularly how
the module does what it does) should be private to
the module unless it is specifically declared otherwise.
🞂 Thus each module should have some interface,
which is how the world sees it anything beyond
that interface should be hidden.
🞂 The default Java rule:
◦ Make everything private
Cohesion
A measure of how well a component “fits
together”.
🞂 A component should implement a single logical
entity or function.
🞂 Cohesion is a desirable design component
attribute as when a change has to be made, it
is localized in a single cohesive component.
🞂 Various levels of cohesion have been identified.
Cohesion Levels
🞂 Coincidental cohesion (weak)
◦ Parts of a component are simply bundled together.
🞂 Logical association (weak)
◦ Components which perform similar functions are
grouped.
🞂 Temporal cohesion (weak)
◦ Components which are activated at the same time are
grouped.
Cohesion Levels
🞂 Communicational cohesion (medium)
◦ All the elements of a component operate on the
same input or produce the same output.
🞂 Sequential cohesion (medium)
◦ The output for one part of a component is the
input to another part.
🞂 Functional cohesion (strong)
◦ Each part of a component is necessary for the
execution of a single function.
🞂 Object cohesion (strong)
◦ Each operation provides functionality which allows
object attributes to be modified or inspected.
Cohesion as a Design Attribute
🞂 Not well-defined. Often difficult to classify
cohesion.
🞂 Inheriting attributes from super-classes
weakens cohesion.
◦ To understand a component, the super-classes
as well as the component class must be
examined.
◦ Object class browsers assist with this process.
Software Implementation
▪ Implementation is the process of transforming
the design into programming language
instructions.
▪ For this purpose programming staff need to:
▪ Select appropriate languages
▪ Agree to standards