Software Engineering: A Practitioner's Approach

candlewhynotΔιαχείριση Δεδομένων

31 Ιαν 2013 (πριν από 4 χρόνια και 2 μήνες)

183 εμφανίσεις

Lecture 7










Slide
1

Lecture 7: Software Design

Spring 2010

Lecture 7










Slide
2

Software
design


Software design specifies
how
the system is to be
implemented
.


Produce a model of a system that will later be built


Input: SRS and
the analysis model
diagrams


Several design elements:


Architectural design


Interface design


Component or module design


Data structure design


Procedural or algorithm design

Lecture 7










Slide
3

Architectural Design


It is the process of establishing the overall
structure of a software system


It represents an early stage of software design


It involves identifying:


the
subsystems or components
making up a system, and


the communications between these
components


The output of this design process is a description
of the

software architecture


Normally
expressed as a block diagram presenting an overview
of the system
structure


It could be used for stakeholder communication

Lecture 7










Slide
4

Architectural Design


It includes choosing an adequate


Structural model


Control model


Module decomposition


Architectural design is a creative activity


Architects must select a right model for their application


They must describe a system in terms of components


A component can be:

»
A program module or procedure (small grain component)

»
An object
-
oriented class

»
A subsystem (large grain component)

»
A middleware that “glue” together other components (e.g., CORBA)

Lecture 7










Slide
5

Example of a structural model:
Packing robot control system

V
i
s
i
o
n
s
y
s
t
e
m
O
b
j
e
c
t
i
d
e
n
t
i
f
i
c
a
t
i
o
n
s
y
s
t
e
m
A
r
m
c
o
n
t
r
o
l
l
e
r
G
r
i
p
p
e
r
c
o
n
t
r
o
l
l
e
r
P
a
c
k
a
g
i
n
g
s
e
l
e
c
t
i
o
n
s
y
s
t
e
m
P
a
c
k
i
n
g
s
y
s
t
e
m
C
o
n
v
e
y
o
r
c
o
n
t
r
o
l
l
e
r
Architecture expressed
as block diagrams

subsystems

Subsystem

interface

Lecture 7










Slide
6

Critical requirements on architecture


Improve Performance


by minimizing
subsystem
communication


Provide Security


to the critical components of the system


Be fault tolerant


to increase availability


Increase maintainability


by designing self
-
contained components that are easy to replace.


These requirements may conflict with each other


Improving performance may reduce maintainability


Introducing redundancy improve availability but reduces security

Lecture 7










Slide
7

Generic structural
models


The repository (shared database) model


Subsystems exchange data


The client
-
server model


Also known as distributed model


Clients request services to servers


A client is responsible for generating user events


The layered model


System organized into a set of layers


These models show how a system is structured
and decomposed into subsystems

Lecture 7










Slide
8

Repository Model


Subsystems exchange data either by


Sharing data held in a centralized database


Advantages:


Efficient way of sharing large amounts of data


Centralized data control, recovery, security, backup


Disadvantages:


Subsystems must use the same database system


Difficult to distribute the database and operations


Lecture 7










Slide
9

Repository Model

P
r
o
j
e
c
t
r
e
p
o
s
i
t
o
r
y
D
e
s
i
g
n
t
r
a
n
s
l
a
t
o
r
P
r
o
g
r
a
m
e
d
i
t
o
r
D
e
s
i
g
n
e
d
i
t
o
r
C
o
d
e
g
e
n
e
r
a
t
o
r
D
e
s
i
g
n
a
n
a
l
y
s
e
r
R
e
p
o
r
t
g
e
n
e
r
a
t
o
r

Integrated case toolset architecture

Lecture 7










Slide
10

Client
-
server:
Film &
picture library

C
a
t
a
l
o
g
u
e
s
e
r
v
e
r
C
a
t
a
l
o
g
u
e
V
i
d
e
o
s
e
r
v
e
r
F
i
l
m

c
l
i
p
f
i
l
e
s
P
i
c
t
u
r
e
s
e
r
v
e
r
D
i
g
i
t
i
z
e
d
p
h
o
t
o
g
r
a
p
h
s
H
y
p
e
r
t
e
x
t
s
e
r
v
e
r
H
y
p
e
r
t
e
x
t
w
e
b
C
l
i
e
n
t

1
C
l
i
e
n
t

2
C
l
i
e
n
t

3
C
l
i
e
n
t

4
W
i
d
e
-
b
a
n
d
w
i
d
t
h

n
e
t
w
o
r
k
Data and processing are distributed Clients call on services

Servers provide specific services

Network allows clients to access servers

Lecture 7










Slide
11

Client
-
server characteristics


Advantages


Distribution of data is straightforward


Makes effective use of networked systems. May require cheaper
hardware


Easy to add new servers or upgrade existing servers


Disadvantages


No shared data model so data interchange may be inefficient


Redundant management in each server


No central register of names and services
-

it may be hard to
find out what servers and services are available

Lecture 7










Slide
12

The layered model


Used to model the interfacing of subsystems


Organizes the system into a set of layers (or abstract
machines) each of which provide a set of services


Supports the incremental development of sub
-
systems in different layers. When a layer interface
changes, only the adjacent layer is affected


However, often difficult to structure systems in this
way


hard to request service from an inner layer

Lecture 7










Slide
13

Drupal

(Content management system)


It is used to build websites


It consists of a stack of layers



Language



Database


Web Server


OS




PHP



MySQL

/
PostGreSQL

/ ...

Database
Abstraction Layer


Apache / IIS / …


Linux / BSD / Windows / Solaris / …

Lecture 7










Slide
14

Control styles


Concerned with control flows between subsystems


Distinct from the system decomposition models


Subsystems
must be controlled so that their services are delivered
to the right place at the right time


Centralized control


One
sub
-
system
has overall responsibility for control and starts
and stops
other
subsystems


Call
-
return model or Manager model


Event
-
based control


Each subsystem can respond to externally generated events from
other subsystems or the system’s environment


Broadcast model or Interrupt
-
driven model

Lecture 7










Slide
15

Call
-
return model: centralized control

R
o
u
t
i
n
e

1
.
2
R
o
u
t
i
n
e

1
.
1
R
o
u
t
i
n
e

3
.
2
R
o
u
t
i
n
e

3
.
1
R
o
u
t
i
n
e

2
R
o
u
t
i
n
e

3
R
o
u
t
i
n
e

1
M
a
i
n
p
r
o
g
r
a
m
Top
-
down control:
control starts at the top
and moves downwards

Applicable only to
sequential systems

Lecture 7










Slide
16

Manager model: Real
-
time controller

S
y
s
t
e
m
c
o
n
t
r
o
l
l
e
r
U
s
e
r
i
n
t
e
r
f
a
c
e
F
a
u
l
t
h
a
n
d
l
e
r
C
o
m
p
u
t
a
t
i
o
n
p
r
o
c
e
s
s
e
s
A
c
t
u
a
t
o
r
p
r
o
c
e
s
s
e
s
S
e
n
s
o
r
p
r
o
c
e
s
s
e
s
Centralized System
controller decides when
other processes should be
started or stopped

Lecture 7










Slide
17

Event
-
driven systems


Driven by externally generated events where the
timing of the event is outside the control of the
process or subsystem that handles the event.


Three
principal event
-
driven models


Broadcast
model.
An event is broadcast to all subsystems. Any
subsystem which can handle the event can respond to it
.


“Pure” event
-
driven model. Externally generated events are
sent to specific systems. Subsystem must respond to the event
as planned.


Interrupt
-
driven
model.
Used in real
-
time systems where
external interrupts are detected by an interrupt handler and
passed to some other component for processing
.

Lecture 7










Slide
18

Broadcast model

S
u
b
-
s
y
s
t
e
m
1
E
v
e
n
t

a
n
d

m
e
s
s
a
g
e

h
a
n
d
l
e
r
S
u
b
-
s
y
s
t
e
m
2
S
u
b
-
s
y
s
t
e
m
3
S
u
b
-
s
y
s
t
e
m
4


Effective
in integrating subsystems on different computers in a network.



Control
policy is not embedded in the event and message handler.



Subsystems
decide on events of interest to them.



However
, subsystems don’t know if or when an event will be handled

The object request broker (ORB) follows a similar model. It handles communication between objects

Lecture 7










Slide
19

“Pure” event
-
driven model


Any object
-
oriented implementation is an event
-
driven system


Started by the component interacting with the user


Example: Online computer shopping (Component diagram)


VendorsPage


ProductInfo


MakeConfiguration


Purchase


OrderTracking

Lecture 7










Slide
20

Online Shopping


package diagram


Identify boundary, control and entity packages


Entity: real
-
world objects identified during analysis


Boundary: GUI classes


Control: classes that service system events

B: Configuration GUI


B: Order GUI


C: Configure Computers

C: Place Orders

E: Customers

E: Computers


E: Orders


E: Database Interface

Lecture 7










Slide
21

Interrupt
-
driven systems


Used in real
-
time systems where fast response to
an event is essential


There are known interrupt types with a handler
defined for each type


Each type is associated with a memory location
and a hardware switch causes transfer to its
handler


Allows fast response but complex to program and
difficult to validate

Lecture 7










Slide
22

Interrupt
-
driven control

H
a
n
d
l
e
r
1
H
a
n
d
l
e
r
2
H
a
n
d
l
e
r
3
H
a
n
d
l
e
r
4
P
r
o
c
e
s
s
1
P
r
o
c
e
s
s
2
P
r
o
c
e
s
s
3
P
r
o
c
e
s
s
4
I
n
t
e
r
r
u
p
t
s
I
n
t
e
r
r
u
p
t
v
e
c
t
o
r
Lecture 7










Slide
23

Modular decomposition


S
ubsystems
are decomposed into
modules


A module is a system component that provides
services to other components but would not normally
be considered as a separate system


Two modular decomposition models covered


An object model where the system is decomposed
into interacting
objects


A
data flow
model where the system is decomposed
into functional modules



If possible, decisions about concurrency should be
delayed until modules are implemented

Lecture 7










Slide
24

Invoice processing system:object
-
oriented

i
s
s
u
e

(
)
s
e
n
d
R
e
m
i
n
d
e
r

(
)
a
c
c
e
p
t
P
a
y
m
e
n
t

(
)
s
e
n
d
R
e
c
e
i
p
t

(
)
i
n
v
o
i
c
e
#
d
a
t
e
a
m
o
u
n
t
c
u
s
t
o
m
e
r
I
n
v
o
i
c
e
i
n
v
o
i
c
e
#
d
a
t
e
a
m
o
u
n
t
c
u
s
t
o
m
e
r
#
R
e
c
e
i
p
t
i
n
v
o
i
c
e
#
d
a
t
e
a
m
o
u
n
t
c
u
s
t
o
m
e
r
#
P
a
y
m
e
n
t
c
u
s
t
o
m
e
r
#
n
a
m
e
a
d
d
r
e
s
s
c
r
e
d
i
t

p
e
r
i
o
d
C
u
s
t
o
m
e
r
objects are created
from these classes and
some control model
used to coordinate
object operations

Structure the system into a set of loosely coupled objects with well
-
defined
interfaces.

Lecture 7










Slide
25

Invoice processing system:
data flow

R
e
a
d

i
s
s
u
e
d
i
n
v
o
i
c
e
s
I
d
e
n
t
i
f
y
p
a
y
m
e
n
t
s
I
s
s
u
e
r
e
c
e
i
p
t
s
F
i
n
d
p
a
y
m
e
n
t
s
d
u
e
R
e
c
e
i
p
t
s
I
s
s
u
e
p
a
y
m
e
n
t
r
e
m
i
n
d
e
r
R
e
m
i
n
d
e
r
s
I
n
v
o
i
c
e
s
P
a
y
m
e
n
t
s


Functional transformations process their inputs to produce outputs.



May be referred to as a pipe and filter model (as in UNIX shell).



Not really suitable for interactive systems.

Lecture 7










Slide
26

Module types based upon:


Activation mechanism:


By reference (invoked by reference)


By interrupt (invoked by interrupt)


Pattern of control:


Single entry and exit


Reentrant


Within a program structure:


Sequential (no interruption)


Incremental (can be interrupted)


Parallel (running concurrently with other modules)

Lecture 7










Slide
27

Data flow decomposition: two
flow types


Transform flow


A DFD that has clear boundaries of incoming flow,
transform flow and outgoing flow


Map into a module structure that adds 4 top level
modules that perform decision making:

»
Main, input, processing, and output controllers


Low level modules map to DFD processes

Lecture 7










Slide
28

Data flow decomposition (cont.)


Transaction flow


A DFD with a single data item that triggers a number
of info flows


Map into a module structure that adds three top level
modules for decision making


Lecture 7










Slide
29

Example: Transform mapping

data flow model
"Transform" mapping
a
b
c
d
e
f
g
h
i
j
x1
x2
x3
x4
b
c
a
d
e
f
g
i
h
j
Lecture 7










Slide
30

Example: Transaction mapping

data flow model
a
b
t
d
e
f
g
h
i
j
k
l
m
n
Mapping
b
a
x1
t
x2
d
e
f
x3
g
h
x3.1
i
j
k
x4
l
m
n
Lecture 7










Slide
31

Module design evaluation criteria


Cohesion


Measure of the strength of a component, module, or class
to encapsulate attribute or operations that are closely
related to one another and to the class, module or
component


HIGH cohesion is desired and occurs when

»
When module executes one thing ,or

»
Class operations access the same data



Coupling


Measure of the degree to which classes, modules, or
components are connected


Low coupling (less interconnection) is desired

»
Avoid global variables or modifying data internal to others

Lecture 7










Slide
32

References


Roger Pressman


Software Engineering: A
Practitioner’s Approach
, McGraw Hill, 6
th

ed.


Ian
Sommerville



Sofware

Engineering
, Addison
Wesley, 8
th

ed.