[Please insert any

relevant photo
around this box] CHAPTER

5
This chapter illustrates the
architectural design and its
role in the software process

Software Architecture
Subtopics:-
5.1 Software architecture and the software life cycle
5.2 Architecture design
5.3 Software architecture assessment
5.4 Reference architectures
5.5 Summary

5.1 Software Architecture and The Software Life Cycle

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.

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. These
enterprise systems are distributed over different computers, which may be owned and
managed by different companies.

36 | P a g e C h a p t e r 5 : S o f t w a r e A r c h i t e c t u r e
The advantages of explicit architecture are:
I. Stakeholder communication
• Architecture may be used as a focus of discussion by system stakeholders.
II. System analysis
• Means that analysis of whether the system can meet its non-functional
requirements is possible.
III. Large-scale reuse
• The architecture may be reusable across a range of systems.
• Product-line architectures may be developed.

Software Life Cycle

Software life cycle models describe phases of the software cycle and the order in which
those phases are executed. Each phase produces deliverables required by the next phase
in the life cycle. Requirements are translated into design. Code is produced according to
the design which is called development phase. After coding and development, the testing
verifies the deliverable of the implementation phase against requirements.

There are six phases in every software development life cycle model:
I. Requirement gathering and analysis- Business requirements are gathered in this
phase. This phase is the main focus of the project managers and stake holders. After
requirement gathering these requirements are analyzed for their validity and the
possibility of incorporating the requirements in the system to be development is also
studied. Finally, a Requirement Specification document is created which serves the
purpose of guideline for the next phase of the model.
II. Design- In this phase, the system and software design is prepared from the
requirement specifications which were studied in the first phase. System Design helps
in specifying hardware and system requirements and also helps in defining overall
system architecture. The system design specifications serve as input for the next
phase of the model.
III. Implementation or coding- On receiving system design documents, the work is
divided in modules/units and actual coding is started. Since, in this phase the code is
produced so it is the main focus for the developer. This is the longest phase of the
software development life cycle.

37 | P a g e C h a p t e r 5 : S o f t w a r e A r c h i t e c t u r e
IV. Testing- After the code is developed it is tested against the requirements to make
sure that the product is actually solving the needs addressed and gathered during
the requirements phase. During this phase all types of functional testing like unit
testing, integration testing, system testing, acceptance testing is done as well as non-
functional testing are also done.
V. Deployment- After successful testing, the product is delivered / deployed to the
customer for their use. As soon as the product is given to the customers they will first
do the beta testing. If any changes are required or if any bugs are caught, then they
will report it to the engineering team. Once those changes are made or the bugs are
fixed then the final deployment will happen.
VI. Maintenance- Once when the customers start using the developed system then the
actual problems come up and needs to be solved from time to time. This process
where the care is taken for the developed product is known as maintenance.

5.2 Architecture Design

Architecture design is an early stage of the system design process. It represents the link
between specification and design processes. It is often carried out in parallel with some
specification activities. It involves identifying major system components and their
communications.

Simple, informal block diagrams showing entities and relationships are the most frequently
used method for documenting software architectures. But these have been criticized
because they lack semantics, do not show the types of relationships between entities nor
the visible properties of entities in the architecture. Depends on the use of architectural
models. The requirements for model semantics depends on how the models are used.

Box and line diagrams are very abstract as they do not show the nature of component
relationships nor the externally visible properties of the sub-systems. However, they are useful
for communication with stakeholders and for project planning.

The uses of architectural models are mainly for the following purposes:
I. As a way of facilitating discussion about the system design
• A high-level architectural view of a system is useful for communication with
system stakeholders and project planning because it is not cluttered with
detail. Stakeholders can relate to it and understand an abstract view of the
38 | P a g e C h a p t e r 5 : S o f t w a r e A r c h i t e c t u r e
 system. They can then discuss the system as a whole without being confused
by detail.
II. As a way of documenting an architecture that has been designed
• The aim here is to produce a complete system model that shows the different
components in a system, their interfaces and their connections.

Layered Architecture

• Used to model the interfacing of sub-systems.

• Organises the system into a set of layers, 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.
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.
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.

Figure 5.1: A generic layered architecture Figure 5.2: Example of layered architecture for LIBSYS system

Repository Architecture

• Sub-systems must exchange data. This may be done in two ways:

o Shared data is held in a central database or repository and may be accessed
by all sub-systems;

39 | P a g e C h a p t e r 5 : S o f t w a r e A r c h i t e c t u r e
 o 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 a this is an efficient data sharing mechanism.
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 The following figure 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.

Figure 5.3: 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. It 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.
Name Client-server
Description In a client–server architecture, the functionality of the system is organized into services,
with each service delivered from a separate server. Clients are users of these services
and access servers to make use of them.
Example The following figure is an example of a film and video/DVD library organized as a client–
server system.

40 | P a g e C h a p t e r 5 : S o f t w a r e A r c h i t e c t u r e
 When used Used when data in a shared database has to be accessed from a range of locations.
Because servers can be replicated, may also be used when the load on a system is
variable.
Advantages The principal advantage of this model is that servers can be distributed across a network.
General functionality (e.g., a printing service) can be available to all clients and does
not need to be implemented by all services.
Disadvantages Each service is a single point of failure so susceptible to denial of service attacks or server
failure. Performance may be unpredictable because it depends on the network as well
as the system. May be management problems if servers are owned by different
organizations.

Figure 5.4: A client–server architecture for a film library

Application Architecture

Application systems are designed to meet an organizational need. As businesses have

much in common, their application systems also tend to have a common architecture that
reflects the application requirements. A generic application architecture is an architecture
for a type of software system that may be configured and adapted to create a system that
meets specific requirements.

The uses of application architectures:

• As a starting point for architectural design.
• As a design checklist.
• As a way of organising the work of the development team.
• As a means of assessing components for reuse.
• As a vocabulary for talking about application types.

Examples of application types:

I. Data processing applications
◦ Data driven applications that process data in batches without explicit user
intervention during the processing.
II. Transaction processing applications
◦ Data-centred applications that process user requests and update information
in a system database.

41 | P a g e C h a p t e r 5 : S o f t w a r e A r c h i t e c t u r e
 III. Event processing systems
◦ Applications where system actions depend on interpreting events from the
system’s environment.
IV. Language processing systems
◦ Applications where the users’ intentions are specified in a formal language that
is processed and interpreted by the system.

In this chapter, we focus on the architecture of transaction processing and language

processing systems.

Transaction Processing Systems

• Process user requests for information from a database or requests to update the
database.
• From a user perspective, a transaction is:
o Any coherent sequence of operations that satisfies a goal;
o For example - find the times of flights from London to Paris.
• Users make asynchronous requests for service which are then processed by a transaction
manager.
• The examples of transaction processing systems are E-Commerce systems and
reservation systems.

Figure 5.5: The structure of transaction processing application

Figure 5.6: The software architecture of an ATM system

Language Processing Systems

Language processing systems accept a natural or artificial language as input and generate
some other representation of that language. They may include an interpreter to act on the
instructions in the language that is being processed.
42 | P a g e C h a p t e r 5 : S o f t w a r e A r c h i t e c t u r e
The examples of language processing systems are compilers and command interpreters.

Figure 5.7: The architecture of a language processing system

The components in a compiler:

I. A lexical analyzer, which takes input language tokens and converts them to an
internal form.
II. 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.
III. A syntax analyzer, which checks the syntax of the language being translated.
IV. A syntax tree, which is an internal structure representing the program being compiled.
V. A semantic analyzer that uses information from the syntax tree and the symbol table
to check the semantic correctness of the input language text.
VI. A code generator that run the syntax tree and generates abstract machine code.

5.3 Software Architecture Assessment

There are two approaches for software architecture assessment:

• after each design iteration
• as a ‘toll-gate’ before starting next phase
The goals for assessment:
• quality attribute satisfaction
• stakeholder satisfaction
• support for software product line
software system acquisition Figure 5.8: The architecture assessment diagram

Assessment techniques for quality attributes:

I. Scenario-based evaluation
• develop a profile
• ‘script’ the scenarios for the architecture
• impact analysis: collect and interpret the results

43 | P a g e C h a p t e r 5 : S o f t w a r e A r c h i t e c t u r e
 • quality attribute prediction: state a conclusion
• state a list of architecture problems (possibilities for improvement)
II. Simulation
• Prototype architecture implementation and abstract components
• implement the profile(s)
• simulate system and initiate scenarios
• collect results and predict quality attributes, for example: correctness,
performance, reliability
• identify functionality mismatches
III. Mathematical Modeling
• select and abstract appropriate mathematical model, for example:
performance modeling
• represent the architecture in terms of the model
• estimate the required input data
• calculate the model output and interpret the results
• quality attribute prediction: state conclusion
• make list of architectural problems
IV. Experience-based reasoning
• reasoning based on logical arguments
• especially for experienced s/w engineers
• basis for other techniques
• architecture assessment teams

Assessment approaches for stakeholder satisfaction:

• ‘toll-gate’ approach, i.e. after architectural design
• assemble all stakeholders for a meeting (end users, customers, operators,
implementers, etc.)
• each stakeholder category defines their primary scenarios
• scenarios are merged (and reduced) in scenario set
• scenarios (max. 20) are discussed and conflicts are resolved
• if conflicts remain, architecture design is rejected, otherwise development
proceeds

Assessment approaches for software product lines:

• assess for reference context

44 | P a g e C h a p t e r 5 : S o f t w a r e A r c h i t e c t u r e
 • assess for each family member
• assess most important systems
• assess low- and high-end systems
• The goal is to determine ability of architecture to support all products in family

Assessment approaches for software system acquisition:

• context: organisation selecting a software system among alternatives
• software architecture indicates several properties about the system that can be
evaluated
• supports selection process against relatively low cost

5.4 Reference Architectures

A reference architecture can be thought of as a resource that documents the learning

experiences gained through past projects. By using a reference architecture, a project
team can potentially save time and avoid mistakes by learning from past experiences. The
specific structure, documentation and management should be flexible, reflecting an
organization's unique structure and needs. To be effective, a reference architecture should
be continually revised to include new insights.

The power of a reference architecture is that it creates a shared mental model for the
architecture and design and it can help you identify the key decisions and key risks early
on. This helps you both shape a skeleton solution as well as identify what you need to
prototype, especially in terms of cross-cutting concerns, or tracer-bullets. From an agile
perspective, the Reference Architecture complements the system metaphor and it helps
you identify potential areas to spike on.

Adopting a reference architecture within an organization accelerates delivery through the

re-use of an effective solution and provides a basis for governance to ensure the
consistency and applicability of technology use within an organization.

In the field of software architecture, many empirical studies have shown the following
common benefits and drawbacks from adopting a software reference architecture within
organizations:
(a) improvement of the interoperability of the software systems by establishing a standard
solution and common mechanisms for information exchange;
45 | P a g e C h a p t e r 5 : S o f t w a r e A r c h i t e c t u r e
(b) reduction of the development costs of software projects through the reuse of common
assets;
(c) improvement of the communication inside the organization because stakeholders share
the same architectural mindset; and,
(d) influencing the learning curve of developers due to the need of learning its features.

Summary

• A software architecture is a description of how a software system is organized.

• Architectural design decisions include decisions on the type of application, the
distribution of the system, the architectural styles to be used.
• Architectures may be documented from several different perspectives or view such
as a conceptual view, a logical view, a process view, and a development view.
• Architectural patterns are a means of reusing knowledge about generic system
architectures. They describe the architecture, explain when it may be used and
describe its advantages and disadvantages.
• Models of application systems architectures help us understand and compare
applications, validate application system designs and assess large-scale
components for reuse.
• Transaction processing systems are interactive systems that allow information in a
database to be remotely accessed and modified by a number of users.
• Language processing systems are used to translate texts from one language into
another and to carry out the instructions specified in the input language. They include
a translator and an abstract machine that executes the generated language.
• Software architecture assessment
o quality attributes
o stakeholders
o software product line
• Software architecture assessment techniques for quality attributes
o scenarios
o simulations
o metrics/mathematical modeling
o experience-based assessment

46 | P a g e C h a p t e r 5 : S o f t w a r e A r c h i t e c t u r e