Lecture No 11 To 12
Lecture No 11 To 12
ARCHITECTURE
Software architecture
• The software architecture of a program or
computing system is the structure or
structures of the system, which comprise
software components, the externally visible
properties of those components, and the
relationships among them.
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.
• In agile processes, an early stage of the development
process should be concerned with establishing an
overall system architecture
• 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 representations
• System architectures are often modeled using
simple block diagrams
• Each box in the diagram represents a component
• Boxes within boxes indicate that the component
has been decomposed to sub-components
• Arrows mean that data are passed from component
to component in the direction of the arrows
• Block diagrams present a high-level picture of the
system structure
Box-and-line diagram
Box-and-line diagrams are often used to
describe the business concepts and processes
during the analysis phase of the software
development lifecycle.
These diagrams come with descriptions of
components and connectors, as well as other
descriptions that provide common inherent
interpretations.
Example
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 activities within the process depend on the
type of system being developed, the background
and experience of the system architect, and the
specific requirements for the system
– Therefore architecture design is more making series
of decisions to be made rather activities
Architectural design decisions
• Is there a generic application architecture that
can be used?
• How will the system be distributed?
• What architectural styles are appropriate?
• How will the system be decomposed into
modules?
• How will the architectural design be evaluated?
• How should the architecture be documented?
Architecture and system characteristics
• Performance
– Localize critical operations and minimize communications. Use
large rather than fine-grain components.
• Security
– Use a layered architecture with critical assets in the inner layers.
• Safety
– Localize safety-critical features in a small number of sub-systems.
• Availability
– Include redundant components and mechanisms for fault
tolerance.
• Maintainability
– Use fine-grain, replaceable components.
Architectural views
• What views or perspectives are useful when designing and
documenting a system’s architecture?
• What notations should be used for describing architectural
models?
• It is impossible to represent all relevant information about a
system’s architecture in a single architectural model
• Each architectural model only shows one view or perspective
of the system.
– It 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.
– For both design and documentation, you usually need to present
multiple views of the software architecture.
4 + 1 view model of software architecture
• A logical view, which shows the key abstractions in the system as
objects or object classes.
– Contents: Class diagrams, Sequence diagrams
• A process view, which shows how, at run-time, the system is
composed of interacting processes.
– Contents: Activity diagrams
• A development view, which shows how the software is decomposed
for development.
– Contents: Component diagram, Package diagrams.
• A physical view, which shows the system hardware and how software
components are distributed across the processors in the system.
– Contents: Deployment diagrams.
• Scenario (+1), Use cases for illustrating and validating the
architecture.
– Contents: Use case diagrams.
Architectural patterns
• Patterns are a means of representing, sharing and
reusing knowledge.
• An architectural pattern is a stylized description of
good design practice, which has been tried and
tested in different environments.
• Patterns should include information about when
they are and when they are not useful.
• Patterns may be represented using tabular and
graphical descriptions.
The Model-View-Controller (MVC) pattern
Name MVC (Model-View-Controller)
Description Separates presentation and interaction from the system data. The
system is structured into three logical components that interact with
each other. The Model component manages the system data and
associated operations on that data. The View component defines
and manages how the data is presented to the user. The Controller
component manages user interaction (e.g., key presses, mouse
clicks, etc.) and passes these interactions to the View and the
Model.
Example Figure (next slide) shows the architecture of a web-based
application system organized using the MVC pattern.
When used Used when there are multiple ways to view and interact with data.
Also used when the future requirements for interaction and
presentation of data are unknown.
Advantages Allows the data to change independently of its representation and
vice versa. Supports presentation of the same data in different
ways with changes made in one representation shown in all of
them.
Disadvantages Can involve additional code and code complexity when the data
model and interactions are simple.
The organization of the Model-View-
Controller
Web application architecture using the
MVC pattern
Layered architecture
• System functionality is organized into separate
layers
– Each layer only relies on the facilities and services
offered by the layer immediately beneath it
• Supports the incremental development of sub-
systems in different layers.
– When a layer interface changes, only the adjacent
layer is affected.
• The architecture is also changeable and portable
The Layered architecture pattern
Name! Layered architecture
Description Organizes the system into layers with related functionality
associated with each layer. A layer provides services to the layer
above it so the lowest-level layers represent core services that are
likely to be used throughout the system.
Example A layered model of a system for sharing copyright documents held
in different libraries, as shown in Figure 6.7.
When used Used when building new facilities on top of existing systems;
when the development is spread across several teams with each
team responsibility for a layer of functionality; when there is a
requirement for multi-level security.
Advantages Allows replacement of entire layers so long as the interface is
maintained. Redundant facilities (e.g., authentication) can be
provided in each layer to increase the dependability of the system.
Disadvantages In practice, providing a clean separation between layers is often
difficult and a high-level layer may have to interact directly with
lower-level layers rather than through the layer immediately below
it. Performance can be a problem because of multiple levels of
interpretation of a service request as it is processed at each layer.
A generic layered architecture
The architecture of the LIBSYS system
Repository architecture
• 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
• Examples
– CAD System, MIS, IDE for software
The Repository pattern
Name Repository
Description All data in a system is managed in a central repository that is
accessible to all system components. Components do not interact
directly, only through the repository.
Example Figure 6.9 is an example of an IDE where the components use a
repository of system design information. Each software tool
generates information which is then available for use by other
tools.
When used You should use this pattern when you have a system in which large
volumes of information are generated that has to be stored for a
long time. You may also use it in data-driven systems where the
inclusion of data in the repository triggers an action or tool.
Advantages Components can be independent—they do not need to know of the
existence of other components. Changes made by one component
can be propagated to all components. All data can be managed
consistently (e.g., backups done at the same time) as it is all in one
place.
Disadvantages The repository is a single point of failure so problems in the
repository affect the whole system. May be inefficiencies in
organizing all communication through the repository. Distributing
the repository across several computers may be difficult.
A repository architecture for an IDE
Client-server architecture
• Distributed system model which shows how
data and processing is distributed across a
range of components.
– Can be implemented on a single computer.
• 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.
The Client–server pattern
Name Client-server