Architectural Design

Objectives
• To introduce architectural design and to
discuss its importance
• To explain the architectural design decisions
that have to be made
• To introduce three complementary
architectural styles covering organisation,
decomposition and control
• To discuss reference architectures are used to
communicate and compare architectures
 Topics covered
• Architectural design decisions
• System organisation
• Decomposition styles
• Control styles
• Reference architectures
 Software architecture
• The design process for identifying the sub-
systems making up a system and the
framework for sub-system control and
communication is architectural design.
• The output of this design process is a
description of the software architecture.
 Architectural design
• An early stage of the system design process.
• Represents the link between specification and
design processes.
• Often carried out in parallel with some
specification activities.
• It involves identifying major system
components and their communications.
 Advantages of explicit architecture

• Stakeholder communication
– Architecture may be used as a focus of discussion
by system stakeholders.
• System analysis
– Means that analysis of whether the system can
meet its non-functional requirements is possible.
• Large-scale reuse
– The architecture may be reusable across a range
of systems.
 Architectural design
• Hofmeister ,el al.,2000 suggest that the
software architecture
– can serve as a design plan that is used to
negotiate system requirements &
– As a means structuring discussions with client,
developers & managers.
– It is an essential tool for complexity management;
it hides details & allows the designer to focus on
the key system abstractions
 Architectural design
• System affects the performance,
robustness(strength), distributability &
maintainability of the system.
• The particular style & structure of system
architecture depends on the non functional
requirements.
 Architecture and system characteristics
• Performance
– Localize critical operations and minimize communications. Use large rather
than fine-grain components to reduce component communications.
• Security
– Use a layered architecture with critical assets in the inner layers & with a high
level of security validation applied to these layers.
• Safety
– Localize safety-related operations in either a single subsystem or a small
number of sub-systems.
– This reduces costs & problems of safety validation &
– Makes it possible to provide a protected system
• Availability
– Architecture should be designed to include redundant components so that it is
possible to replace & update components without stopping the system
– These are the features used for fault tolerance systems.
• Maintainability
– Since it is a critical requirement, architecture should be designed using fine-
grain, replaceable components.
 System structuring
• Concerned with decomposing the system into
interacting sub-systems.
• The architectural design is normally expressed
as a block diagram presenting an overview of
the system structure.
• More specific models showing how sub-
systems share data, are distributed and
interface with each other may also be
developed.
Example- Packing robot control system
Example- Packing robot control system

• Fig above is the abstract model of the

architecture for packaging robot system that
shows the sub systems that have to be
developed.
• This robotic system can pack different kinds of
object.
• It uses vision subsystem to pick out objects on
a conveyer
Example- Packing robot control system

• Identify the type of object &

• Select the right kind of packaging
• The system then moves the objects from the
delivery to be packaged
• It places the packaged objects on another
conveyer.
 Box and line diagrams
• Very abstract - they do not show the nature of
component relationships nor the externally
visible properties of the sub-systems.
• However, useful for communication with
stakeholders and for project planning.
• General problem – To decide how to
decompose system into sub-system is difficult
one.
– Where system requirement are the major factor
– Thus, if the requirement change, this change is
likely to be localized rather than distributed across
several sub- system.
 Architectural design decisions
• It is a creative process where one tries to establish a
system organization that will satisfy the functional &
non functional system requirements
• Activities within the process differs radically depending
on the
– type of system being developed
– The background & experience of the system architect &
– The specific requirement of the system
• Thus, consider architectural design process from
decision perspective rather than from activity
perspective.
 3.1 Architectural design decisions
• During architectural design process, system
architects have to make many fundamental
decisions
• based on their knowledge & experience, have
to answer the following fundamental
questions:
 Architectural design decisions
• Is there a generic application architecture that can be used?
• How will the system be distributed?
• What architectural styles are appropriate?
• What approach will be used to structure the system?
• How will the system be decomposed into modules?
• What control strategy should be used?
• How will the architectural design be evaluated?
• How should the architecture be documented?
 Architecture reuse
• Systems in the same domain often have
similar architectures that reflect domain
concepts.
• Application product lines are built around a
core architecture with variants that satisfy
particular customer requirements.
 Architectural styles
• The architectural model of a system may conform
to a generic architectural model or style such as
client-server or layered architecture.
• An awareness of these styles, their applications,
their strength/weaknesses can simplify the
problem of defining system architectures.
• However, most large systems are heterogeneous
and do not follow a single architectural style.
 Architectural design
• The product of the architectural design process –
is the architectural design document
• It includes number of graphical representations
of the system along with associated descriptive
text.
• Should describe how the system is structured into
sub- systems, an approach is adapted & how each
subsystem is structured into modules
• Graphical model of the system present different
perspectives on the architecture. Architectural
models that may be developed may include
 Architectural models
• Interface model that defines sub-system
interfaces.
• Relationships model such as a data-flow model
that shows sub-system relationships.
• Distribution model that shows how sub-systems
are distributed across computers.
• A number of researchers proposed the use of
architectural description language(ADL) to
describe system architecture –
– however, it is difficult to understand & use
– Thus, difficult to analyse from practical perspective
 3.2 System organization
• Reflects the basic strategy that is used to
structure a system.
• Three organizational styles are widely used:
– A shared data repository style;
– A shared services and servers style;
– An abstract machine or layered style.
 The repository model
• Sub-systems making up a system must exchange
information so that they work together
effectively.
• 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.
• Suited for applications where data is generated
by one sub-system and used by another.
Example-CASE toolset architecture
 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.
 Client-server model
• A system model where the system is organized as a set
of services and associated servers and clients that
access & use the services.
• i.e. Distributed system model which shows how data
and processing is distributed across a range of
components.
• The major components of this model are:
1. A set of servers that offer services to other
subsystems such as printing, data management, etc.
2. A set of clients that call on services offered by the
servers.
3. A network that allows clients to access these services.
 Client-server model
• Clients may have to know the names of the
available servers & the services they provide
• However, servers need not know either the
identity of clients and their number.
• Clients accesses the service from remote
procedural call using request reply protocol
such as http.
Example-Film and picture library
 Example-Film and picture library
• It is multi-user, web based system
• Several servers manage & display the different
types of media
• Video frames need to be transmitted quickly and
in synchrony but with low resolution
• Video servers may handle video compression/
decompression into different formats to be
stored in a store
• Still pictures must be maintained at a high
resolution so must be maintained in a separate
server.
 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.
• Each layer can be thought of as an abstract machine whose
machine language is defined by the services provided by the
layer beneath it.
• This language used is to implement the next level of abstract
machine.
• 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.
 Example-Version management system(Ada
Programming support environment structure)

Configuration ma nagement system layer

Object management system layer

Database system layer

Operating system layer

 The Layered model
• Shows how configuration management system might be
integrated using this abstract machine model
• Config management system manages
– versions of objects & provides general config management
facilities
• To support these config management facilities, it uses object
management system that provides
– information storage and management services for
configuration items or objects.
• The system is built on the top of the database system to
provide basic data storage and services such as transaction
management
• The database management uses the underlying operating
system facilities and file store in its implementation
 The layered model
• Disadvantages-
– Structuring system in this way can be difficult.
– Inner layer may provide basic facilities, such as file mgmt.
that are required at all levels
– Service required by the user of the top level may have to
‘punch through’ adjacent layers
• to get access to services that are provided several layers
beneath it.
– This subverts the model, as the outer layer in the system
does not just depend on its immediate predecessor.
– Performance can be a problem because of multiple levels of
command interpretation that are sometimes required.
3.3 Modular decomposition styles
• After overall system organization is complete,
the subsystems are further needs to be
decomposed into modules.
• Styles of decomposing sub-systems into
modules-called modular decomposition.
• No rigid distinction between system
organization and modular decomposition.
• However, components in modules are usually
smaller than subsystems, which allows
alternate decomposition styles to be used.
Differences- Subsystem & Modules
• A sub-system is a system in its own right
whose operation is independent of the
services provided by other sub-systems.
• A module is a system component that
provides services to other components but
would not normally be considered as a
separate system.
• To produce its output it requires other’s input
 Modular Decomposition
• There are two main strategies that one can use while
decomposing subsystem into modules.
– An Object oriented model where the system is decomposed into
interacting object;
– A Function oriented pipelining (or data-flow model) where the system
is decomposed into functional modules which transform inputs to
outputs.
• If possible, decisions about concurrency should be delayed
until modules are implemented.
 Object oriented decomposition
• Structure the system into a set of loosely
coupled objects with well-defined interfaces.
• Object-oriented decomposition is concerned
with identifying object classes, their attributes
and operations.
• When implemented, objects are created from
these classes and some control model used to
coordinate object operations.
Example-Invoice processing system(OO arch
model)
 Object Oriented Decomposing
• This system can issue invoices to
– customers, receive payments &
– issue receipts for these payments
– Reminders for unpaid invoices
– Object classes have names and a set of associated
attributes
– Operations, if any are defined in the lower part of
the rectangle representing the object.
– Dashed arrows indicate that an object uses the
attributes or services provided by another object.
 Object oriented Decomposition-
Advantages
• Objects are loosely coupled so their
implementation can be modified without
affecting other objects.
• The objects may reflect real-world entities
because of which objects can be reused.
• OO implementation languages are widely
used.
• However, object interface changes may cause
problems and complex entities(abstract) 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.
Example-Invoice processing system
 Invoice processing system
• (in fig.) An Invoice processing system has issued
invoices to customers
• Once a week, payments that have been made
reconciled with the invoices
• For invoices that have been paid, a receipt is issued.
• For invoices that have not been paid within the
allowed payment time, reminder is issued.
• This model is only the part of invoice processing
system; alternative transformations would be used
for the issue of invoices
 Pipeline model advantages
• Supports transformation reuse.
• Intuitive organization for stakeholder
communication.
• Easy to add new transformations.
• Relatively simple to implement as either a
concurrent or sequential system.
• However, requires a common format for data
transfer along the pipeline and difficult to
support event-based interaction.
 3.4 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
• Here, one subsystem is designated as the system controller &
has responsibility for managing the execution of other sub
systems.
• Centralized control models fall into two classes, depending on
weather the controlled sub-system execute sequentially or in
parallel
• 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.
Example-Call-return model
 Example-Call-return model
• In fig. the main program call routines 1,2 &3; Routine
1 can call Routine 1.1 & 1.2;Routine 3 can call
Routines 3.1 & 3.2; & so on.
• Here, control passes from a higher-level routine in
the hierarchy to the lower level
• Then it returns to a point where the routine was
called
• The currently executing subroutine has responsibility
to control & can either call other routines or return
control to its parents.
• It is poor programming style to return to some other
point in the program.
 Call-return model
• This model may be used at the module level
to control functions and objects.
• Strength-It is relatively simple to analyze
control flows & work out how the system will
respond to particular inputs.
• Weakness- exceptions to normal operation are
awkward to handle.
Real-time system control
 Real-time system control
• In fig., shows the centralized management model of
control for a concurrent system.
• This model is often used in “soft” real-time systems
which do not have very tight time constraints.
• The central controller manages the execution of set
of processes associated with sensors and actuators
• The system controller decides when processes
should be started or stop depending on system state
variables.
• It checks whether other processes have produced
information to be processed or pass the information
to them for processing.
 Event-driven systems
• Event driven control models are driven by externally
generated events where the timing of the event is outside the
control of the process that handles that 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.
• Here, sub-systems register an interest in specific events.
When these occur, control is transferred to the sub-system
which can handle the event.
• Difference of this with centralized model is that the control
policy is not embedded in the event and message handler.
Sub-systems decide on events of interest to them.
• Subsystem decide which event they require, & the event of
interest to them.
• However, disadvantage of this model is that sub-systems don’t
know if or when an event will be handled.
Selective broadcasting
 Selective broadcasting
• Here, sub-system register an interest in
specific events.
• When these occur, control is transferred to the
subsystem that can handle the event
 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 systems
 Interrupt-driven systems
• In fig., there are known number of interrupt
types with the handler defined for each type.
• Each interrupt is associated with a memory
location where its handler’s address is stored.
• When an interrupt of a particular type is
received, h/w switch causes control to be
transferred immediately to its handler.
• This interrupt handler may then start or stop
other processes in response to the event
signalled by the interrupt.
 3.5 Reference architectures
• Architectural models may be 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.
 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.
 OSI reference model

7 Applica tion Applica tion

6 Presenta tion Presenta tion

5 Session Session

4 Transpor t Transpor t

3 Network Networ k Networ k

2 Data link Data link Data link

1 Physical Physical Physical

Comm unica tions medium

 Case reference model
• Data repository services
– Storage and management of data items.
• Data integration services
– Managing groups of entities.
• Task management services
– Definition and enactment of process models.
• Messaging services
– Tool-tool and tool-environment communication.
• User interface services
– User interface development.
The ECMA reference model