 Architectural design is concerned with understanding how a

software system should be organized and designing the

overall structure of that system
 The output of the architectural design process is an
architectural model that describes how the system is
organized as a set of communicating Components
 Refactoring components in response to changes is usually
relatively easy. However, refactoring the system architecture
is expensive because you may need to modify most system
components to adapt them to the architectural changes.
 You can design software architectures at two levels
of abstraction, which I call
 architecture in the small and architecture in the
large:
 Architecture in the small is concerned with the
architecture of individual programs .At this level, we
are concerned with the way that an individual
program is decomposed into components
 Architecture in the large is concerned with the
architecture of complex enterprise systems that
include other systems, programs, and program
components.
Figure 6.1 The architecture of a packing robot
control system
 Figure 6.1. This diagram shows an abstract model of the
architecture for a packing robot system. This robotic
system can pack different kinds of objects. It uses a
vision component to pick out objects on a conveyor,
identify the type of object, and select the right kind of
packaging.
 The system then moves objects from the delivery
conveyor to be packaged.
 It places packaged objects on another conveyor. The
architectural model shows these components and the
links between them.
 Architectural design
 Architectural design is a creative process in which
you design a system organization that will satisfy the
functional and non-functional requirements of a
system.
 There is no formulaic architectural design process. It
depends on the type of system being developed, the
background and experience of the system architect,
and the specific requirements for the system.
 Consequently, I think it is best to consider
architectural design as a series of decisions to be
made rather than a sequence of activities.
 [Link] communication The architecture is a high-
level presentation of the system that may be used as a
focus for discussion by a range of different stakeholders.

 2. System analysis Making the system architecture

explicit at an early stage in the system development
requires some analysis.

 Large-scale reuse An architectural model is a compact,

manageable description of how a system is organized
and how the components interoperate.
Figure 6.2 Architectural design decisions
 To develop a general model of the control relationships
between the various parts of the system and make decisions
about how the execution of components is controlled.
Because of the close relationship between non-functional
system characteristics and software architecture, the choice
of architectural style and structure should depend on the
non-functional requirements of the system
 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 deployed on the same computer rather than
distributed across the network.
[Link] If security is a critical requirement, a
layered structure for the architecture should be
used, with the most critical assets protected in
the innermost layers and a high level of security
validation applied to these layers.
3. Safety If safety is a critical requirement, the
architecture should be designed so that safety-
related operations are co-located in a single
component or in a small number of components.
[Link] 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
that may readily be changed. Producers of data should
be separated from consumers, and shared data
structures should be avoided.
Architectural views
 that architectural models of a software system can be used
to focus discussion about the software requirements or
design.
 Alternatively, they may be used to document a design so that
it can be used as a basis for more detailed design and
implementation of the system
two issues that are relevant to both of these:
1. What views or perspectives are useful when designing and
documenting a system’s architecture?
2. What notations should be used for describing architectural
models?
There should be four fundamental architectural views, which
can be linked through common use cases or scenarios (Figure
6.3). He suggests the following views:
1. A 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.
2. A process view, which shows how, at runtime, the system is
composed of interacting processes. This view is useful for
making judgments about non-functional system characteristics
such as performance and availability.

3. A development view, which shows how the software is

decomposed for development; that is, it shows the breakdown
of the software into components that are implemented by a
single developer or development team. This view is useful for
software managers and programmers.

4. A 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.
 Architectural Pattern
 The idea of patterns as a way of presenting,
sharing, and reusing knowledge about
software systems has been adopted in a
number of areas of software engineering
 The model view controller is an architectural pattern
that separates an application into three main logical
components: The model, the view and the controller.
 Each of these components are built to handle specific
development aspects of an application.
 MVC is one of the most frequently used industry
standard web development framework to create
scalable and extensible projects
Figure 6.4 The Model-View-Controller
(MVC) pattern
 Figure 6.4 describes the well-known Model-View-
Controller pattern. This pattern is the basis of
interaction management in many web-based
systems and is supported by most language
frameworks. The stylized pattern description
includes the pattern name, a brief description, a
graphical model, and an example of the type of
system where the pattern is used.
Figure 6.5 The organization of the Model-View-
Controller

Graphical models of the architecture associated with the MVC

pattern are shown in Figures 6.5 and 6.6. These present the
architecture from different views: Figure 6.5 is a conceptual view,
and Figure 6.6 shows a runtime system architecture when this
pattern is used for interaction management in a web-based
system.
Figure 6.6 Web Database application architecture using
the MVC pattern
 Layered architecture
 The Layered Architecture pattern is another way of
achieving separation and independence
 This pattern is shown in Figure 6.7. 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.
Figure 6.7 The Layered Architecture pattern
 This layered approach supports the incremental
development of systems. As a layer is developed, some of the
services provided by that layer may be made available to
users.
 The architecture is also changeable and portable. If its
interface is unchanged, a new layer with extended
functionality can replace an existing layer without changing
other parts of the system.
 Furthermore, when layer interfaces change or new facilities
are added to a layer, only the adjacent layer is affected.
 As layered systems localize machine dependencies, this
makes it easier to provide multi-platform implementations of
an application system. Only the machine dependent layers
need be reimplemented to take account of the facilities of a
different operating system or database.
 Figure 6.8 is an example of a layered architecture with
four layers. The lowest layer includes system support
software—typically, database and operating system
support. The next layer is the application layer, which
includes the components concerned with the
application functionality and utility components used
by other application components.
 Figure 6.8 A generic layered architecture
Figure 6.9 The architecture of the iLearn
system

Figure 6.9 shows that the iLearn digital learning system,

introduced in Chapter 1, has a four-layer architecture that
follows this pattern
 Repository architecture
 The layered architecture and MVC patterns are
examples of patterns where the view presented is the
conceptual organization of a system.
 Figure 6.10 The Repository pattern
 the Repository pattern (Figure 6.10), describes how a set of
interacting components can share data.
Figure 6.11 A repository architecture for an IDE
 The majority of systems that use large amounts of data are
organized around a shared database or repository. This
model is therefore suited to applications in which data is
generated by one component and used by another.
 Figure 6.11 illustrates a situation in which a repository might
be used.
 This diagram shows an IDE that includes different tools to
support model-driven development.
 The repository in this case might be a version-controlled
environment
 Organizing tools around a repository is an efficient way of sharing
large amounts of data. There is no need to transmit data explicitly
from one component to another. However, components must
operate around an agreed repository data model.

 In the repository architecture shown in Figure 6.11, the repository

is passive and control is the responsibility of the components using
the repository. An alternative approach, which has been derived
for artificial intelligence (AI) systems, uses a “blackboard” model
that triggers components when particular data become available.

 This is appropriate when the data in the repository is unstructured.

Decisions about which tool is to be activated can only be made
when the data has been analyzed.
advantages
 Efficient way to share large amounts of data.
 Sub-systems need not be concerned with how data is
produced centralised management [Link],security
 Sharing model is published as the repository schema
 Disadvantages
 Data evolution is difficult and expensive
 Difficult to distribute efficiently.
Client–server architecture
The Client–Server pattern (Figure 6.12), illustrates a commonly used runtime
organization for distributed systems. A system that follows the Client–Server
pattern is organized as a set of services and associated servers, and clients
that access and use the services.
The major components of this model are:
 1. A set of servers that offer services to other components.
Examples of servers include print servers that offer printing
services, file servers that offer file management services, and a
compile server that offers programming language compilation
services. Servers are software components, and several servers
may run on the same computer.
 2. A set of clients that call on the services offered by servers. There
will normally be several instances of a client program executing
concurrently on different computers.
 3. A network that allows the clients to access these services.
Client–server systems are usually implemented as distributed
systems, connected using Internet protocols.
 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
Figure 6.13 A client– server architecture for
a film library
 the model by identifying the components that support
user communications and information retrieval and
access:
[Link] top layer is a browser-based user interface.
2. The second layer provides the user interface functionality that is delivered
through the web browser. It includes components to allow users to log in to
the system and checking components that ensure that the operations they
use are allowed by their role.
[Link] third layer implements the functionality of the system and
provides components that implement system security, patient
information creation and updating, import and export of patient
data from other databases, and report generators that create
management reports.
4. Finally, the lowest layer, which is built using a commercial
database management system, provides transaction management
and persistent data storage.
 Figure 6.13 is an example of a system that is based on
the client–server model. This is a multiuser, web-based
system for providing a film and photograph library. In
this system, several servers manage and display the
different types of media.
 Video frames need to be transmitted quickly and in
synchrony but at relatively low resolution.
 They may be compressed in a store, so the video server
can handle video compression and decompression in
different formats.
 Still pictures, however, must be maintained at a high
resolution, so it is appropriate to maintain them on a
separate server.
Figure 6.20 The architecture of a language
processing system
 The catalog must be able to deal with a variety of queries
and provide links into the web information system that
include data about the film and video clips, and an e-
commerce system that supports the sale of photographs,
film, and video clips.
 The client program is simply an integrated user interface,
constructed using a web browser, to access these services.
 The most important advantage of the client–server model is
that it is a distributed architecture
Pipe and filter architecture
 This is a model of the runtime organization of a system
where functional transformations process their inputs and
produce outputs. Data flows from one to another and is
transformed as it moves through the sequence.
 Each processing step is implemented as a transform. Input
data flows through these transforms until converted to
output. The transformations may execute sequentially or in
parallel.
Figure 6.14 The Pipe and Filter pattern

The name “pipe and filter” comes from the original Unix system where it
was possible to link processes using “pipes.” These passed a text stream
from one process to another
 An example of this type of system architecture, used in a
batch processing application, is shown in Figure 6.15. An
organization has issued invoices to customers. Once a week,
payments that have been made are reconciled with the
invoices
 for those invoices that have been paid, a receipt is issued. For those
invoices that have not been paid within the allowed payment time, a
reminder is issued.
Pipe and filter systems are best suited to batch processing systems
and embedded systems where there is limited user interaction.
Interactive systems are difficult to write using the pipe and filter
model because of the need for a stream of data to be processed.
As a starting point for the architectural design process
As a design checklist
Transaction processing systems
 Transaction processing systems are designed to
process user requests for information from a database,
or requests to update a database

Figure 6.17 The software architecture of an ATM system

 Transaction processing systems may be organized as a “pipe
and filter” architecture, with system components responsible
for input, processing, and output.
 For I/O processing Application logic Transaction manager
Database Figure 6.16 The structure of transaction processing
applications .
 example, consider a banking system that allows customers
to query their accounts and withdraw cash from an ATM. The
system is composed of two cooperating software
components—the ATM software and the account processing
software in the bank’s database server.
 The input and output components are implemented as
software in the ATM, and the processing component is part
of the bank’s database server.
 Figure 6.17 shows the architecture of this system, illustrating
the functions of the input, process, and output components.
 Figure 6.18 presents a very general model of an
information system. The system is modeled using a
layered approach (discussed in Section 6.3) where the
top layer
 Figure 6.18 Layered information system architecture

supports the user interface and the bottom layer is the system database. The user
communications layer handles all input and output from the user interface, and the
information retrieval layer includes application-specific logic for accessing and
updating the database. The layers in this model can map directly onto servers in a
distributed Internet-based system
 The organization of servers in these systems usually reflects
the four-layer generic model presented in Figure 6.18. These
systems are often implemented as distributed systems with a
multitier client server/architecture
1. The web server is responsible for all user communications,
with the user interface implemented using a web browser;
2. The application server is responsible for implementing
application-specific logic as well as information storage and
retrieval requests;
3. The database server moves information to and from the
database and handles transaction management.
Figure 6.19 The architecture of the Mentcare system

, Figure 6.19 shows the architecture of the Mentcare system

Language processing systems
Language processing systems translate one language into an
alternative representation of that language and, for
programming languages, may also execute the resulting
code. Compilers translate a programming language into
machine code
 Programming language compilers that are part of a more general
programming environment have a generic architecture (Figure
6.21) that includes the following components:
1 A lexical analyzer, which takes input language tokens and converts
them into an internal form.
2. A symbol table, which holds information about the names of
entities (variables, class names, object names, etc.) used in the
text that is being translated.
3. A syntax analyzer, which checks the syntax of the language being
translated. It uses a defined grammar of the language and builds a
syntax tree.
4. A syntax tree, which is an internal structure representing the
program being compiled.
5. A semantic analyzer, which uses information from the syntax tree
and the symbol table to check the semantic correctness of the
input language text.
6. A code generator, which “walks” the syntax tree and generates
abstract machine code.
 Design and Implementation
 Software design and implementation is the stage in the
software engineering process at which an executable
software system is developed.
 Software design and implementation activities are
invariably interleaved.
 Software design is a creative activity in which you
identify software components and their relationships,
based on a customer’s requirements.
 Implementation is the process of realizing the design as
a program
 Build or Buy
 For many types of application, it is now possible to buy off-the-
shelf application systems that can be adapted and tailored to the
users’ requirements.
 For example, if you want to implement a medical records system,
you can buy a package that is already used in hospitals. It is
usually cheaper and faster to use this approach rather than
developing a new system in a conventional programming
language.
Object –Oriented design process
 Structured object oriented design processes involve developing
a number of different system model.
 They require a lot of effort for development & maintainence of
these models and for small systems, this may not be cost
effective.
 However for large systems developed by different groups
design models are an important communication mechanism.
 Process stages
There are a variety of different object-oriented design
processes that depend on the organization using the process
Common activities in these processes include:
Define the context and modes of use of the system
1. Understand and define the context and the external
2. Design the system architecture.
3. Identify the principal objects in the system
4. Develop design models.
5. Specify interfaces
Process illustrated here using a design for a wilderness weather
station
 System context and interactions
 Understanding the relationships between the software
that is being designed and its external environment is
essential for deciding how to provide the required
system functionality and how to structure to
communicate wit its environment.
 Understanding of the context also lets you establish the
boundaries of the system. setting the system boundaries
helps you decide what features are implemented in the
system being designed and what features are in other
associated systems
UML(Unified Modeling Language) Diagram Types
❖ Activity diagrams, which show the activities involved in a
process or in data processing.
❖ Use case diagrams, which show the interactions between
a system and its environment.
❖ Sequence diagrams, which show interactions between
actors and the system and between system components.
❖ Class diagrams, which show the object classes in the
system and the associations between these classes.
❖ State diagrams, which show how the system reacts to
internal and external events.
 Process stages
 To develop a system design from concept to
detailed, object-oriented design, you need to:
1. Understand and define the context and the
external interactions with the system.
2. Design the system architecture.
3. Identify the principal objects in the system.
4. Develop design models.
5. Specify interfaces.
 System context and interactions
 understanding the relationships between the software
that is being designed and its external environment. This
is essential for deciding how to provide the required
system functionality and how to structure the system to
communicate with its environment.
 understanding the context also lets you establish the
boundaries of the system. Setting the system
boundaries helps you decide what features are
implemented in the system being designed and what
features are in other associated systems
 System context models and interaction
models present complementary views of the
relationships between a system and its
environment:
 1. A system context model is a structural
model that demonstrates the other systems in
the environment of the system being
developed.
 2. An interaction model is a dynamic model
that shows how the system interacts with its
environment as it is used
System context for the weather
station
 The use case model for the weather station is shown
in Figure 7.2. This shows that the weather station
interacts with the weather information system to
report weather data and the status of the weather
station hardware.
 Other interactions are with a control system that
can issue specific weather station control
commands.
 The stick figure is used in the UML to represent
other systems as well as human users.
Figure 7.2 Weather station use cases
Figure 7.3 Use case description—Report weather
 Architectural design
 Once the interactions between the software system
and the system’s environment have been defined, you
use this information as a basis for designing the system
architecture.
 You identify the major components that make up the
system and their interactions. You may then design the
system organization using an architectural pattern
such as a layered or client–server model.
 The weather station is composed of independent
subsystems that communicate by broadcasting
messages on a common infrastructure
Figure 7.4 High-level architecture of
weather station
 Figure 7.5 Architecture of data collection system
 Object class identification
 Identifying object classes is often a difficult part of
object oriented design
 There is no ‘magic formula’ for object identification. it
relies on the skill,experienceand domain knowledge of
system designers
 Object identification is an iterative process you are
unlikely to get it right first time
Approaches to identification
 Use a grammatical analysis of a natural language
description of the system
 Base the identification on tangible things in the
application domain.
 Use a behavioural approach and identify objects based on
what participates in what behaviour.
 Use a scenario-based analysis. The objects, attributes and
methods in each scenario are identified.
Weather station object classes
 Object class identification in the weather system
may be based on the tangible hardware and data
in the system.
--- Ground thermometer,anemometer,barometer
Application domain objects that are ‘hardware’
objects related to the instruments in the system
----- Weather station
The basic interface of the weather station to its
environment. It therefore reflects the
interactions identified in the use case model
----Weather data
Encapsulates the summarized data from the
instruments
Figure 7.6 Weather station objects