Professional Documents
Culture Documents
tm
ionP A
r
c
o
n
tm
o
l
e
r G r
icon
p
e
r
t
o
l
a
cselyk g
ietm
n
o
©Ian Sommerville 2000
P a
csyk iten
mC g o
n
v
e
y
o
ctrlr
Software Engineering, 6th edition. Chapter 10 Slide 14
The repository model
● Sub-systems must exchange data. This may be
done in two ways:
• Shared data is held in a central database or repository and may
be accessed by all sub-systems
• Each sub-system maintains its own database and passes data
explicitly to other sub-systems
● When large amounts of data are to be shared, the
repository model of sharing is most commonly
used
D e
stranliagtn P
r
oj
e
c
tC
o
g
e
nd
e
r
a
t
r P
r
o
g
a
m
oraD
enslyigne
ps
i
r
yR
ep
o
r
t
ergna e
d
i
t
r
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10 Slide 16
Repository model characteristics
● Advantages
• Efficient way to share large amounts of data
• Sub-systems need not be concerned with how data is produced
Centralised management e.g. backup, security, etc.
• Sharing model is published as the repository schema
● Disadvantages
• Sub-systems must agree on a repository data model. Inevitably
a compromise
• Data evolution is difficult and expensive
• No scope for specific management policies
• Difficult to distribute efficiently
R
o
u
ti
n R
o
u
t
ii
n
m
n
e
2R o
u
t
in
e
3
R
ou
tin
e1.Rou
tin
e1.2Rou
tin
e3.1R
ou
tin
e3.2
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10 Slide 25
pSens
o
r
rocecS
Real-time system control
y s
t e m A
c
t
u
a
o
r
p
r
o
e
s
C
om
p u o
n
trcesaionin
U ro l
r
stfearc h
F
au
ln
td
er
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10 Slide 26
Event-driven systems
● Driven by externally generated events where the
timing of the event is outwith the control of the
sub-systems which process the event
● Two principal event-driven models
• Broadcast models. An event is broadcast to all sub-systems.
Any sub-system which can handle the event may do so
• Interrupt-driven models. Used in real-time systems where
interrupts are detected by an interrupt handler and passed to
some other component for processing
● Other event driven models include spreadsheets
and production systems
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10 Slide 27
Broadcast model
● Effective in integrating sub-systems on different
computers in a network
● Sub-systems register an interest in specific events.
When these occur, control is transferred to the sub-
system which can handle the event
● Control policy is not embedded in the event and
message handler. Sub-systems decide on events of
interest to them
● However, sub-systems don’t know if or when an
event will be handled
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10 Slide 28
S
u
b
-s1ytemS
u
b
-s2
y
tE e
m S
ub
-
s
3y
Selective broadcasting
ven
tan
d
m
esageh
an
d t
e
m
ler S
u
b
-
s
y
t
e
m
4
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10 Slide 29
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
H
an
lP1d e
r
ro1cesPH
an2dle
rH
ro2cesPan3d l
e
r
ro3cesPH
an4dle
r
ro4ces
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10 Slide 31
Modular decomposition
● Another structural level where sub-systems are
decomposed into modules
● 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 which transform inputs to outputs. Also
known as the pipeline model
● If possible, decisions about concurrency should be
delayed until modules are implemented
I
n
v
o
i
cn
v
o
i
c
e
#e R
i
n
v
o
i
d
a
t
m
u
c
s
oe
c
i
#
n
t
m
e
r
#p
t
id
n
v
icm oP
atseoua
c y m
# ent a
t
m
u
c
s
o
i
u
s
e
n
d
R
a
c
pn
t
m
e
r
(
)
e
m
i
t
P
a
yn
d
e
r
(
)
t
n
tm er# cp
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10 Slide 34
Data-flow models
● Functional transformations process their inputs to
produce outputs
● May be referred to as a pipe and filter model (as in
UNIX shell)
● Variants of this approach are very common. When
transformations are sequential, this is a batch
sequential model which is extensively used in data
processing systems
● Not really suitable for interactive systems
R
eia
d
iIn
sn
vo cuedI
d
p
a
ye
mn
t
i
fy
s r
e
c
i
p
t
s
F
i
n
d
p
a
y
m
e
t
s I
s
u
e
p
a
y
m
nt R
e
m
i
n
d
e
rs
voicesP
aym
en
ts u r
e
i
dr
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10 Slide 36
Domain-specific architectures
● Architectural models which are specific to some
application domain
● Two types of domain-specific model
• Generic models which are abstractions from a number of real
systems and which encapsulate the principal characteristics of
these systems
• Reference models which are more abstract, idealised model.
Provide a means of information about that class of system and
of comparing different architectures
● Generic models are usually bottom-up models;
Reference models are top-down models
L xliycsalS
ean y n Sy
m
b
o
l
t
a
e
talacsi S
ean
m
a n
tlysicgen
C
ord
eation
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10 Slide 39
L
e x
ianlycsaelraS
Language processing system
yn
tla
sx
erS
e
m
a
na
n
t
i
c
l
y
s
e
r
P
rp
e
tE
-d
in y
r
itor S A
b
s
s
y
n
y
mt
x r
a
c
b
ot
e
ltaeR G
r
a
m
d
e
f
i
n
t
O
u
t
p
d
e
f
i
na
r
o
n
o
n O
p
t
i
m
z
e
C
o
d
e
g
e
n
r
a
tr
r
©Ian Sommerville 2000
ep
ositry
Software Engineering, 6th edition. Chapter 10 Slide 40
Reference architectures
● Reference models are derived from a study of the
application domain rather than from existing
systems
● May be used as a basis for system implementation
or to compare different systems. It acts as a
standard against which systems can be evaluated
● OSI model is a layered model for communication
systems
Tra p a
t
o
n
i
r
t A
p
P
r
e
S
T
r
al
i
c
a
t
s
n
i
i
o
n
s
p
r
to
n
321N
eD
tPw o k N
e
t
wo
rk N
e
tw
o
k
Application
ah
lyscianC D
a
P
h
y
s
om
u
nl
i
n
c
a
ition
sm
edD
a
P
h
y
iu
ml
i
n
s
c
a
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10 Slide 42
Key points
● The software architect is responsible for deriving a
structural system model, a control model and a
sub-system decomposition model
● Large systems rarely conform to a single
architectural model
● System decomposition models include repository
models, client-server models and abstract machine
models
● Control models include centralised control and
event-driven models
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10 Slide 43
Key points
● Modular decomposition models include data-flow
and object models
● Domain specific architectural models are
abstractions over an application domain. They may
be constructed by abstracting from existing
systems or may be idealised reference models