Transcript Software Engineering COMP 201

Software Design
Deriving a solution which satisfies
software Speficitaion
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
Re quire me nts
spec ifica
tion
De sign acvities
ti
Arc hite ctur
al
design
Abstra ct
spec ifica
tio
n
Interfa ce
design
Component
design
Data
structur
e
design
Algorithm
design
Syste m
a rc hite ctur
e
Softwa re
spec ifica
tion
Interfa ce
spec ifica
tion
Component
spec ifica
tion
Data
structur
e
spec ifica
tion
Algorithm
spec ifica
tion
De sign pr
oducts
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, nonterminating 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: subproblems 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
n( n  1)
system should stay closer to the minimum
2
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
Module A
Module C
Module B
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
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.
Natural Language
 Nouns suggest candidate Classes.
 Not every noun is an Object Class.
– Some are attributes of another Class.
– Some are irrelevant, outside the scope of the application.
 Verb phrases suggest class associations
– some relationships are irrelevant (caution).
 Proper nouns suggest Objects of a Class type. Beware of
singular nouns.
Class Description
 Develop a Class description, either in textual prose or
some other structured form. E.G. using a customer in a
Bank
– Customer: a holder of one or more accounts in a Bank. A
customer can consist of one or more persons or companies.
A customer can: make withdrawals; deposit money; transfer
money between their accounts or to another account; query
their accounts.
Structured Class Description
Class Name: Customer
Description: Personal or company details
Superclass: User
Name: Name
Description: Customer’s name
Type: String (max. 12 chars)
Cardinality: 1
Name: Owns
Description: Details of bank accounts
Type: Account
Cardinality: Many
Structured Class Description (cont..)
Public Methods:
Name: Pay_bill
Parameters: amount, date, destination,
account.
Description: Customer may pay bills
through the Bank.
Structured Class Description (cont..)
Private Methods:
Name: Transfer
Parameters: amount, from_account,
to_account.
Description: Allow transfers from owned
accounts to any others.