0% found this document useful (0 votes)
108 views38 pages

CMP 102 Introduction To CP Module 4 Software Design

The document discusses key concepts in software design including: 1) Software design aims to derive solutions that satisfy software requirements. 2) The design process involves understanding the problem, identifying solutions, describing abstract solutions, and repeating until a design is expressed in basic terms. 3) Modular design methods aim to decompose problems into independently solvable subproblems arranged in a hierarchical structure to improve understandability, reusability, and ability to change designs with minimal impact.

Uploaded by

Miracle
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
108 views38 pages

CMP 102 Introduction To CP Module 4 Software Design

The document discusses key concepts in software design including: 1) Software design aims to derive solutions that satisfy software requirements. 2) The design process involves understanding the problem, identifying solutions, describing abstract solutions, and repeating until a design is expressed in basic terms. 3) Modular design methods aim to decompose problems into independently solvable subproblems arranged in a hierarchical structure to improve understandability, reusability, and ability to change designs with minimal impact.

Uploaded by

Miracle
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 38

Software Design

CMP 102 Introduction to Computer Programming


Dr. S. A. Arekete (adapted)

Software Engineering Software Design Slide 1


Software Design

Deriving a solution which


satisfies software requirements

Software Engineering Software Design Slide 2


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.
Software Engineering Software Design Slide 3
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.

Software Engineering Software Design Slide 4


Phases in the Design Process
Requirements
specifica
tion

Design acti
vities

Architectur
al Abstract Interface Component Data Algorithm
design specifica
tio design design structur
e design
n design

Software Data
System Interface Component Algorithm
specifica
t ion structure
architectur
e specifica
tion specifica
t ion specifica
tion
specificat ion

Design pr
oducts

Software Engineering Software Design Slide 5


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.
Software Engineering Software Design Slide 6
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

Software Engineering Software Design Slide 7


Modular programming

• In the early days, modular programming was


taken to mean constructing programs out of
small pieces: “subroutines”
• But modularity cannot bring benefits unless
the modules are
– autonomous,
– coherent and
– robust

Software Engineering Software Design Slide 8


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
Software Engineering Software Design Slide 9
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.,
- e.g., compilers process control systems, operating systems
like WinNT, ATM machines
Software Engineering Software Design Slide 10
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.

Software Engineering Software Design Slide 11


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.

Software Engineering Software Design Slide 12


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

Software Engineering Software Design Slide 13


Hierarchical Design Structure
System level

Sub-system
level

Software Engineering Software Design Slide 14


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.
Software Engineering Software Design Slide 15
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

Software Engineering Software Design Slide 16


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.

Software Engineering Software Design Slide 17


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.

Software Engineering Software Design Slide 18


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.

Software Engineering Software Design Slide 19


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.

Software Engineering Software Design Slide 20


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.

Software Engineering Software Design Slide 21


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.

Software Engineering Software Design Slide 22


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.

Software Engineering Software Design Slide 23


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
n(n  1)
a minimum of n-1 and a maximum of 2
links; your system should stay closer to the
minimum
Software Engineering Software Design Slide 24
Few Interfaces

Software Engineering Software Design Slide 25


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!

Software Engineering Software Design Slide 26


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.

Software Engineering Software Design Slide 27


Tight Coupling

Module A Module B

Module C Module D

Shared data
area

Software Engineering Software Design Slide 28


Loose Coupling
Module A

A’s data

Module B Module C
B’s data C’s data

Module D
D’s data

Software Engineering Software Design Slide 29


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.

Software Engineering Software Design Slide 30


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.

Software Engineering Software Design Slide 31


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.

Software Engineering Software Design Slide 32


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.

Software Engineering Software Design Slide 33


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

Software Engineering Software Design Slide 34


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.
Software Engineering Software Design Slide 35
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.

Software Engineering Software Design Slide 36


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.
Software Engineering Software Design Slide 37
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 Engineering Software Design Slide 38

You might also like