Giáo trình Kỹ nghệ phần mềm - Bài 6: Thiết kế kiến trúc

 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.
Client-server model
• Distributed system model which shows how data 
and processing is distributed across a range of 
components
• Set of stand-alone servers which provide specific 
services such as printing, data management, etc.
• Set of clients which call on these services
• Network which allows clients to access servers
Film and picture library
Internet
Client 1 Client 2 Client 3
Web 
server
Film and 
photo 
info.
Video 
server 
Film clip 
files
Picture 
server 
Digitalized 
photos
Catalog 
server 
Library 
catalog
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 sub-systems use different data 
organisation. 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.
Abstract machine (layered) model
• Used to model the interfacing of sub-systems.
• Organises 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 artificial to structure systems in this way.
Version management system
Version Management layer
Object management system layer
Database system layer
Operating System layer
Modular decomposition styles
• Styles of decomposing sub-systems into modules.
• No rigid distinction between system organisation 
and modular decomposition.
Sub-systems and modules
Sub-system
• A system in its own right 
• Operation is independent of 
the services provided by 
other sub-systems
Module
• A system component 
• Provides services to other 
components 
• Not normally be considered 
as a separate system.
Modular decomposition
• Another structural level where sub-systems are 
decomposed into modules
• Two modular decomposition models covered
– An object model 
• System is decomposed into interacting objects
– A pipeline or data-flow model 
• System is decomposed into functional modules which 
transform inputs to outputs
• If possible, decisions about concurrency should 
be delayed until modules are implemented
Object models
• Structure the system into a set of loosely coupled 
objects with well-defined interfaces
• Decomposition is identifying object classes, their 
attributes and operations
• When implemented, objects are created from 
these classes and some control model used to 
coordinate object operations
Invoice processing system
Object model (dis)advantages
• Advantages
– Loosely coupled so objects implementation can be 
modified without affecting other objects
– Close to real-world entities
– OO implementation languages are widely used
• Disadvanages
– Object interface changes may cause problems 
– Complex, abstract entities may be hard to represent 
as objects
Function-oriented pipelining
• 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
Invoice processing system
Pipeline model (dis)advantages
• Advantages
– Supports transformation reuse
– Intuitive organisation for stakeholder communication
– Easy to add new transformations
– Relatively simple to implement as either a concurrent 
or sequential system
• Disadvantages 
– Requires a common format for data transfer 
– Difficult to support event-based interaction
Control styles
• Are concerned with the control flow between 
sub-systems
• Distinct from the system decomposition model
• Centralised control
– One sub-system has overall responsibility for control 
and starts and stops other sub-systems
• Event-based control
– Each sub-system can respond to externally generated 
events from other sub-systems or the system’s 
environment
Centralised control
• A control sub-system takes responsibility for managing 
the execution of other sub-systems.
• Call-return model
– Top-down subroutine model where control starts at the top of 
a subroutine hierarchy and moves downwards. Applicable to 
sequential systems.
• Manager model
– Applicable to concurrent systems. One system component 
controls the stopping, starting and coordination of other 
system processes. Can be implemented in sequential systems 
as a case statement.
Call-return model
Main
program
Routine 3Routine 2Routine 1
Routine 1.1 Routine 2.1 Routine 3.1
Real-time system control
System
Sensor
processes
Actuator
processes
controller
user
interface
Computation 
processes
Fault
handler
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.
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.
Selective broadcasting
Sub-system 1 Sub-system 2 Sub-system 3
Event and message handler
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.
Interrupt-driven control
Interrupt
vector
Handler
1
Process
1
Handler 
2
Process
2
Handler
3
Process
3
Reference architectures
• Architectural models may be specific to some 
application domain
• Two types of domain-specific model
– Generic models 
• Abstractions from a number of real systems 
• Encapsulate the principal characteristics of these systems
• Usually bottom-up models
– Reference models 
• More abstract, idealised model 
• Provide a means of information about that class of system and of 
comparing different architectures
• Usually top-down models
Reference models
• Derived from a study of the application domain 
rather than from existing systems
• May be used as a basis for implementation or to 
compare different systems 
• Act as a standard for evaluation
• Example
– OSI model: a layered model for communication 
systems
OSI reference model
Application
Presentation
Session
Application
Presentation
Session
Application A Application B
Transport
Network
Data Link
Physical
Transport
Network
Data Link
Physical
Network
Data Link
Physical
Network
Data Link
Physical
Communication Network
CASE tools reference model
• Data repository services
– Storage and management of data items
• Data integration services
– Managing groups of entities
• Task management services
– Definition and enaction of process models
• Messaging services
– Tool-tool and tool-environment communication
• User interface services
– User interface development
The ECMA reference model
Key points
• The software architecture is the fundamental framework 
for structuring the system
• Architectural design decisions include decisions on the 
application architecture, the distribution and the 
architectural styles to be used
• Different architectural models such as a structural 
model, a control model and a decomposition model may 
be developed
• System organisational models include repository 
models, client-server models and abstract machine 
models
Key points
• Modular decomposition models include object
models and pipelining models
• Control models include centralised control and 
event-driven models
• Reference architectures may be used to 
communicate domain-specific architectures and 
to assess and compare architectural designs
Architectural models
• Different architectural models may be produced 
during the design process
• Each model presents different perspectives on 
the architecture
Architecture attributes
• Performance
– Localise operations to minimise sub-system communication
• Security
– Use a layered architecture with critical assets in inner layers
• Safety
– Isolate safety-critical components
• Availability
– Include redundant components in the architecture
• Maintainability
– Use fine-grain, self-contained components
Bài tập về nhà
• Trả lời câu hỏi: 11.1, 11.2, 11.3, 11.6, trang 264-
265, sách Software Engineering, Ian Summerville
• Xây dựng, xác định kiến trúc của bài tập nhóm
thuộc mô hình nào?