5 software design

Software Engineering Software Design Slide 1
Software Engineering
Software Design

Software Design
Deriving a 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
Architectural
design
Abstract
specificatio
n
Interface
design
Component
design
Data
structure
design
Algorithm
design
System
architecture
Software
specification
Interface
specification
Component
specification
Data
structure
specification
Algorithm
specification
Requirements
specification
Design activities
Design products

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

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

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
application domains
- e.g., compilers
Less well-suited to distributed, non-
terminating systems
- 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
System level
Sub-system
level

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
2
)1( −nn

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!

• 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.
Coupling

Tight Coupling
Module A Module B
Module C Module D
Shared data
area

Loose Coupling
Module A
A’s data
Module B
B’s data
Module D
D’s data
Module C
C’s data

• 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.
Coupling and Inheritance

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.

5 software design

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 5 software design

Ähnlich wie 5 software design (20)

Mehr von cherrybear2014

Mehr von cherrybear2014 (12)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

5 software design