Architectural Design

Text Book: Chapter 6

Architectural Design
• Architectural design is concerned with understanding how a system
should be organized and designing the overall structure of that system
• It is the critical link between design and requirements engineering
• In agile processes, it is generally accepted that an early stage of the
development process should be concerned with establishing an
overall system architecture
• Incremental development of architectures is not usually successful
Architectural design decisions
• Architectural design is a creative process where you design a system
organization that will satisfy the functional and non-functional
requirements of a system
• The architecture of a software system may be based on a particular
architectural pattern or style
• such as a client–server organization or a layered architecture
• You should be aware of common patterns, where they can be used,
and their strengths and weaknesses when making decisions about the
architecture of a system
Architectural design decisions
• You have to choose the most appropriate structure that will enable
you to meet the system requirements
• To decompose structural system units, you decide on the strategy for
decomposing components into sub-components
• The approaches that you can use allow different types of architecture
to be implemented
• Because of the close relationship between non-functional
requirements and software architecture, the particular architectural
style and structure that you choose for a system should depend on
the non-functional system requirements:
Architecture and Non-Functional Requirements
• Performance
• If performance is a critical requirement, the architecture should be designed to
localize critical operations within a small number of components, with these
components all deployed on the same computer rather than distributed over a
network
• Security
• If security is a critical requirement, a layered architecture should be used
• the most critical assets protected in the innermost
• Safety
• If safety is a critical requirement, the architecture should be designed so that
safety-related operations are all located in either a single component or in a small
number of components
• This reduces the costs and problems of safety validation and makes it possible to
shut down the system in the event of a failure
Architecture and Non-Functional
Requirements
• Availability
• If availability is a critical requirement, the architecture should be designed to
include redundant components so that it is possible to replace and update
components without stopping the system
• Maintainability
• If maintainability is a critical requirement, the system architecture should be
designed using fine-grain, self-contained components
Architecture and Non-Functional
Requirements
• There may be potential conflicts in these architectural choices
• For example, using large components improves performance and using small,
fine-grain components improves maintainability.
• If both performance and maintainability are important system requirements,
then some compromise must be found
• Evaluating an architectural design is difficult because the true test of
an architecture is how well the system meets its functional and non-
functional requirements when it is in use
• However, you can do some evaluation by comparing your design
against reference architectures
Architectural Views
• An architecture may be viewed from different perspectives
• It is impossible to represent all relevant information about a system’s
architecture in a single architectural model
• each model only shows one view or perspective of the system
• An architectural view might show:
• how a system is decomposed into modules
• how the run-time processes interact
• or the different ways in which system components are distributed across a
network
Architectural Views
• Krutchen suggests that there should be four fundamental architectural
views
• The views that he suggests are:
• Logical view
• which shows the key abstractions in the system as objects or object classes
• It should be possible to relate the system requirements to entities in this logical
view
• Process view
• which shows how, at run-time, the system is composed of interacting processes
• It is useful for making judgements about non-functional requirements such as
performance and availability
Architectural Views
• Development view
• which shows how the software is decomposed for development
• it shows the breakdown of the software into components that are implemented by a
single developer or development team
• Physical view
• which shows the system hardware and how software components are distributed
across the processors in the system
• This view is useful for systems engineers planning a system deployment
• Conceptual view
• In practice, conceptual views are almost always developed during the design process
and are used to support architectural decision making
• They are a way of communicating the essence of a system to different stakeholders
Architectural patterns
• The idea of patterns as a way of presenting, sharing, and reusing
knowledge about software systems is now widely used
• You can think of an architectural pattern as a stylized, abstract
description of good practice, which has been tried and tested in
different systems and environments
• So, an architectural pattern should describe a system organization
that has been successful in previous systems
Architectural patterns - Layered
architecture
• The notions of separation and independence are fundamental to
architectural design as they allow changes to be localized
• The layered architecture pattern is another way of achieving
separation and independence
• Here, the system functionality is organized into separate layers, and
each layer only relies on the facilities and services offered by the layer
immediately beneath it
Architectural patterns - Layered
architecture
Architectural patterns - Layered
architecture
Architectural patterns - Layered
architecture
Architectural patterns - Repository
architecture
• The layered architecture and MVC patterns are examples of patterns where
the view presented is the conceptual organization of a system
• Repository pattern describes how a set of interacting components can share
data
• The majority of systems that use large amounts of data are organized around
a shared database or repository
• There is no need to transmit data explicitly from one component to another
• However, components must operate around an agreed repository data
model
• Examples of this type of system include command and control systems,
management information systems, CAD systems, and interactive
development environments for software
Architectural patterns -
Repository architecture
Architectural patterns - Repository architecture
Architectural patterns - Client–
server architecture
• The repository pattern is concerned with the static structure of a system
and does not show its run-time organization
• The Client–server pattern illustrates a very commonly used run-time
organization for distributed systems
• Client–server architectures are usually thought of as distributed systems
architectures but the logical model of independent services running on
separate servers can be implemented on a single computer
• Clients may have to know the names of the available servers and the
services that they provide
• servers do not need to know the identity of clients or how many clients are
accessing their services
Architectural patterns - Client–server
architecture
Architectural patterns - Client–server
architecture
Architectural patterns - Pipe and filter
architecture
• This is a model of the run-time organization of a system where
functional transformations process their inputs and produce outputs
• Each processing step is implemented as a transform
• Input data flows through these transforms until converted to output
• Variants of this pattern have been in use since computers were first
used for automatic data processing
• When transformations are sequential with data processed in batches, this
pipe and filter architectural model becomes a batch sequential model
Architectural patterns - Pipe
and filter architecture
Architectural patterns - Pipe and filter
architecture
Application architectures
• Businesses operating in the same sector use common sector-specific
applications
• Therefore, as well as general business functions, all phone companies need
systems to connect calls, manage their network, issue bills to customers, etc
• Consequently, the application systems used by these businesses also
have much in common
• These commonalities have led to the development of software
architectures that describe the structure and organization of
particular types of software systems
• Application architectures encapsulate the principal characteristics of a
class of systems
Application architectures
• A generic system is configured and adapted to create a specific
business application
• E.g., SAP and Oracle
• As a software designer, you can use models of application
architectures:
• As a starting point for the architectural design process
• As a design checklist
• If you have developed an architectural design for an application system, you can
compare this with the generic application architecture
• As a way of organizing the work of the development team
• As a means of assessing components for reuse
• As a vocabulary for talking about types of applications
Transaction processing
applications
• Transaction processing applications are database-centered
applications that process user requests for information and update
the information in a database
• They are organized in such a way that user actions can’t interfere with
each other and the integrity of the database is maintained
• E.g., banking systems, e-commerce systems, information systems, and
booking systems
Transaction processing
applications
Language processing systems
• Language processing systems are systems in which the user’s
intentions are expressed in a formal language
• The language processing system processes this language into an
internal format and then interprets this internal representation
• E.g. compilers
Transaction processing systems
• They are designed to process user request from a DB or to a DB
• Typically a DB transaction is a sequence of actions, but is treated atomically
• From a user perspective, a transaction is any coherent sequence of operations
that satisfies a goal
• e.g., find the times of flights from London to Paris
• An example of a transaction is a customer request to withdraw money from a
bank account using an ATM. This involves:
• getting details of the customer’s account
• checking the balance
• modifying the balance by the amount withdrawn
• and sending commands to the ATM to deliver the cash
• Until all of these steps have been completed, the
• transaction is incomplete and the customer accounts database is not changed
• Transaction processing systems may be organized as a ‘pipe and filter’
architectures with system components responsible for input,
processing, and output
 Information systems
• All systems that involve interaction with a shared database can be
considered to be transaction-based information systems
• An information system allows controlled access to a large base of
information
• e.g., library catalog, a flight timetable
• Increasingly, information systems are web-based systems that are
accessed through a web browser
Information systems
• The top layer is responsible for implementing the user interface
• The second layer provides the user interface functionality that is
delivered through the web browser
• The third layer implements the functionality or business logic of the
system
• The lowest layer provides transaction management and persistent
data storage