BCA213-4

PRINCIPLES OF SOFTWARE DEVELOPMENT – 2

UNIT 1 - Software Engineering

1
Overview

Chapter 16 -Software reuse Page 425

Chapter 17 -Component-based software engineering -Page
452
Chapter 18- Distributed software engineering -Page 479
Chapter 19 -Service-oriented architecture -Page 508
Chapter 20- Embedded software -Page 537
Chapter 21 -Aspect-oriented software engineering

2
Software reuse

✧ In most engineering disciplines, systems are designed

by composing existing components that have been used
in other systems.
✧ Software engineering has been more focused on original
development but it is now recognised that to achieve
better software, more quickly and at lower cost, we need
a design process that is based on systematic software
reuse.
✧ There has been a major switch to reuse-based
development over the past 10 years.

3
Reuse-based software engineering

✧ System reuse
▪ Complete systems, which may include several application
programs may be reused.
✧ Application reuse
▪ An application may be reused either by incorporating it without
change into other or by developing application families.
✧ Component reuse
▪ Components of an application from sub-systems to single objects
may be reused.
✧ Object and function reuse
▪ Small-scale software components that implement a single well-
defined object or function may be reused.

17/11/2014 Chapter 15 Software reuse 4

Benefits of software reuse

Benefit Explanation
Accelerated development Bringing a system to market as early as possible is
often more important than overall development costs.
Reusing software can speed up system production
because both development and validation time may be
reduced.
Effective use of specialists Instead of doing the same work over and over again,
application specialists can develop reusable software
that encapsulates their knowledge.
Increased dependability Reused software, which has been tried and tested in
working systems, should be more dependable than
new software. Its design and implementation faults
should have been found and fixed.

17/11/2014 Chapter 15 Software reuse 5

Benefits of software reuse

Benefit Explanation
Lower development costs Development costs are proportional to the size of the
software being developed. Reusing software means that
fewer lines of code have to be written.
Reduced process risk The cost of existing software is already known, whereas
the costs of development are always a matter of
judgment. This is an important factor for project
management because it reduces the margin of error in
project cost estimation. This is particularly true when
relatively large software components such as
subsystems are reused.
Standards compliance Some standards, such as user interface standards, can
be implemented as a set of reusable components. For
example, if menus in a user interface are implemented
using reusable components, all applications present the
same menu formats to users. The use of standard user
interfaces improves dependability because users make
17/11/2014 fewer Chapter
mistakes whenreuse
15 Software presented with a familiar interface. 6
Problems with reuse

Problem Explanation
Creating, maintaining, Populating a reusable component library and ensuring the
and using a component software developers can use this library can be expensive.
library Development processes have to be adapted to ensure that
the library is used.
Finding, understanding, Software components have to be discovered in a library,
and adapting reusable understood and, sometimes, adapted to work in a new
components environment. Engineers must be reasonably confident of
finding a component in the library before they include a
component search as part of their normal development
process.
Increased maintenance If the source code of a reused software system or
costs component is not available then maintenance costs may be
higher because the reused elements of the system may
become increasingly incompatible with system changes.

17/11/2014 Chapter 15 Software reuse 7

Problems with reuse

Problem Explanation
Lack of tool support Some software tools do not support development with
reuse. It may be difficult or impossible to integrate these
tools with a component library system. The software
process assumed by these tools may not take reuse into
account. This is particularly true for tools that support
embedded systems engineering, less so for object-
oriented development tools.
Not-invented-here Some software engineers prefer to rewrite components
syndrome because they believe they can improve on them. This is
partly to do with trust and partly to do with the fact that
writing original software is seen as more challenging than
reusing other people’s software.

17/11/2014 Chapter 15 Software reuse 8

Reuse planning factors

✧ The development schedule for the software.

✧ The expected software lifetime.
✧ The background, skills and experience of the
development team.
✧ The criticality of the software and its non-functional
requirements.
✧ The application domain.
✧ The execution platform for the software.

17/11/2014 Chapter 15 Software reuse 9

Base systems for a software product line

17/11/2014 Chapter 15 Software reuse 10

Base applications

✧ Core components that provide infrastructure support.

These are not usually modified when developing a new
instance of the product line.
✧ Configurable components that may be modified and
configured to specialize them to a new application.
Sometimes, it is possible to reconfigure these
components without changing their code by using a built-
in component configuration language.
✧ Specialized, domain-specific components some or all of
which may be replaced when a new instance of a
product line is created.

17/11/2014 Chapter 15 Software reuse 11

ERP systems

✧ An Enterprise Resource Planning (ERP) system is a

generic system that supports common business
processes such as ordering and invoicing,
manufacturing, etc.
✧ These are very widely used in large companies - they
represent probably the most common form of software
reuse.
✧ The generic core is adapted by including modules and
by incorporating knowledge of business processes and
rules.

17/11/2014 Chapter 15 Software reuse 12

The architecture of an ERP system

17/11/2014 Chapter 15 Software reuse 13

ERP architecture

✧ A number of modules to support different business

functions.
✧ A defined set of business processes, associated with
each module, which relate to activities in that module.
✧ A common database that maintains information about all
related business functions.
✧ A set of business rules that apply to all data in the
database.

17/11/2014 Chapter 15 Software reuse 14

ERP configuration

✧ Selecting the required functionality from the system.

✧ Establishing a data model that defines how the organization’s
data will be structured in the system database.
✧ Defining business rules that apply to that data.
✧ Defining the expected interactions with external systems.
✧ Designing the input forms and the output reports generated by
the system.
✧ Designing new business processes that conform to the
underlying process model supported by the system.
✧ Setting parameters that define how the system is deployed on
its underlying platform.
17/11/2014 Chapter 15 Software reuse 15
Integrated application systems

✧ Integrated application systems are applications that

include two or more application system products and/or
legacy application systems.
✧ You may use this approach when there is no single
application system that meets all of your needs or when
you wish to integrate a new application system with
systems that you already use.

17/11/2014 Chapter 15 Software reuse 16

Design choices

✧ Which individual application systems offer the most

appropriate functionality?
▪ Typically, there will be several application system products
available, which can be combined in different ways.
✧ How will data be exchanged?
▪ Different products normally use unique data structures and
formats. You have to write adaptors that convert from one
representation to another.
✧ What features of a product will actually be used?
▪ Individual application systems may include more functionality
than you need and functionality may be duplicated across
different products.

17/11/2014 Chapter 15 Software reuse 17

 Component-based software engineering
Contents

1.Components and component models

2.CBSE processes
3.Component composition

18
CBSE

19
Continued…

20
Continued…

21
 CBSE Essentials

CBSE Essentials refers to the foundational principles, practices, and

components that underpin the CBSE approach. CBSE is a methodology that
emphasizes building software systems by integrating pre-existing, reusable
components rather than developing everything from scratch.

1.Independent components that are completely specified by their interfaces.

There should be a clear separation between the component interface and its
implementation. This means that one implementation of a component can be
replaced by another, without changing other parts of the system.
2. Component standards that facilitate the integration of components. These
standards are embodied in a component model. They define, at the very
minimum, how component interfaces should be specified and how components
communicate. Some models go much further and define interfaces that should
be implemented by all conformant components. If components conform to
standards, then their operation is independent of their programming language.
22
Components written in different languages can be integrated into the same
CBSE Essentials

3. Middleware that provides software support for component integration.

To make independent, distributed components work together, you need
middleware support that handles component communications. Middleware
for component support handles low-level issues efficiently and allows you
to focus on application-related problems. In addition, middleware for
component support may provide support for resource allocation,
transaction management, security, and concurrency.

4. A development process that is geared to component-based software

engineering. You need a development process that allows requirements to
evolve, depending on the functionality of available components.

23
 CBSE are sound design principles that support the
construction of understandable and maintainable
software:

1.Components are independent so they do not interfere with each other’s

operation. Implementation details are hidden. The component’s
implementation can be changed without affecting the rest of the system.
2. Components communicate through well-defined interfaces. If these
interfaces are maintained, one component can be replaced by another,
which provides additional or enhanced functionality.
3.Component infrastructures offer a range of standard services that can be
used in application systems. This reduces the amount of new code that has to
be developed.

24
Several different protocols and standards have been developed to
support this view of a component, such as Sun’s Enterprise Java Beans
(EJB), Microsoft’s COM and .NET, and CORBA’s CCM.

Components that are developed for different platforms, such as .NET

or J2EE, cannot interoperate.

25
Components and component models

There is general agreement in the CBSE community that a component is

an independent software unit that can be composed with other
components to create a software system. Beyond that, however, people
have proposed varying definitions of a software component.
“A software element that conforms to a standard component model
and can be independently deployed and composed without
modification according to a composition standard.”
“A software component is a unit of composition with contractually-
specified interfaces and explicit context dependencies only. A software
component can be deployed independently and is subject to
composition by third parties.”
Both of these definitions are based on the notion of a component as an
element that is included in a system, rather than a service that is
26
referenced by the system.
Component Characteristics

27
 A useful way of thinking about a component is as a
provider of one or more services. When a system needs a
service, it calls on a component to provide that service
without caring about where that component is executing or
the programming language used to develop the
component.
For example, a component in a library system might
provide a search service that allows users to search
different library catalogs.
A component that converts from one graphical format to
another (e.g., TIFF to JPEG) provides a data conversion
service, etc.
28
Component interfaces

Components have two related interfaces.

These interfaces reflect the services that the component provides and
the services that the component requires to operate correctly:

The ‘provides’ interface defines the services provided by the

component. This interface, essentially, is the component API. It defines
the methods that can be called by a user of the component. In a UML
component diagram, the ‘provides’ interface for a component is
indicated by a circle at the end of a line from the component icon.

29
The ‘requires’ interface specifies what services must be provided by
other components in the system if a component is to operate correctly.
If these are not available, then the component will not work.
This does not compromise the independence or deployability of a
component because the ‘requires’ interface does not define how these
services should be provided.
In the UML, the symbol for a ‘requires’ interface is a semicircle at the
end of a line from the component icon.

30
Component interface

31
A model of a data collector component

32
Explanation

A model of a component that has been designed to collect and

collate information from an array of sensors. It runs autonomously to
collect data over a period of time and, on request, provides collated
data to a calling component.
The ‘provides’ interface includes methods to add, remove, start,
stop, and test sensors. The report method returns the sensor data
that has been collected, and the listAll method provides information
about the attached sensors. Although I have not shown this here,
these methods have associated parameters specifying the sensor
identifiers, locations, and so on.
The ‘requires’ interface is used to connect the component to the
sensors. It assumes that sensors have a data interface, accessed
through sensorData, and a management interface, accessed
through sensor Management. This interface has been designed to
connect to different types of sensor so it does not include specific33
CBSE processes

CBSE processes are software processes that support

component-based software engineering. They take into
account the possibilities of reuse and the different process
activities involved in developing and using reusable
components.

34
Diagram

35
 Explanation

1.Component acquisition is the process of acquiring

components for reuse or development into a reusable
component. It may involve accessing locally developed
components or services or finding these components from an
external source.
2. Component management is concerned with managing a
company’s reusable components, ensuring that they are
properly cataloged, stored, and made available for reuse

36
3. Component certification is the process of checking a
component and certifying that it meets its specification.
4. Components maintained by an organization may be stored
in a component repository that includes both the
components and information about their use.

37
Two types of CBSE processes:

The two processes, Development for Reuse and

Development with Reuse, are central to component-
based software engineering (CBSE) and emphasize
different aspects of software reuse.
1. Development for reuse This process is concerned with
developing components or services that will be reused in
other applications. It usually involves generalizing existing
components.
2. Development with reuse This is the process of
developing new applications using existing components
and services

38
 Development for Reuse

Objective: Create components or services that can be reused in multiple

applications or projects.
Approach: Focuses on generalizing components to make them
adaptable to various contexts.
Key Activities:
○ Requirement Generalization: Design components with broad
functionality to support various applications. For example,
instead of a "Login Module" tailored to one app, create a
configurable "User Authentication System."
○ Abstraction and Modularity: Ensure components are modular,
loosely coupled, and have well-defined interfaces to maximize
reusability.
39
continued..

○ Documentation: Provide clear documentation,

including usage instructions, dependencies, and
constraints.
○ Testing for Versatility: Components are rigorously
tested across different environments to ensure
reliability in varied use cases.
○ Storage and Sharing: Store reusable components in
libraries or repositories for easy access.

40
Advantages

○ Reduces future development effort.

○ Promotes consistency across applications.
○ High return on investment when components are
reused multiple times.

41
Development with Reuse

● Objective: Build new applications by leveraging existing components

or services, saving time and effort.
● Approach: Focuses on identifying, integrating, and customizing
existing reusable components.
● Key Activities:
○ Component Discovery: Search for suitable components in
repositories or libraries.
○ Evaluation: Assess components for compatibility, performance,
and quality with the target system.
○ Integration: Combine and adapt components to work seamlessly
within the new application.
○ Glue Code Development: Write code to connect or customize
components for the specific application.
○ Testing and Validation: Ensure integrated components function 42
as expected and meet requirements.
Examples:
○ Developing an e-commerce application using pre-built
components like payment gateways, inventory management
modules, and user authentication.
○ Building a website using CMS platforms like WordPress, which
rely heavily on plugins and themes.
Advantages:
○ Accelerates development timelines.
○ Leverages proven, tested components for better reliability.
○ Reduces redundant effort.

43
 CBSE for reuse

CBSE for reuse is the process of developing reusable components

and making them available for reuse through a component
management system.

44
CBSE for reuse

A company with a reuse program may carry out some form of

component certification before the component is made available
for reuse.
Certification means that someone apart from the developer
checks the quality of the component. They test the component
and certify that it has reached an acceptable quality standard,
before it is made available for reuse.
However, this can be an expensive process and many
companies simply leave testing and quality checking to the
component developers.

45
 CBSE with reuse

The successful reuse of components requires a development

process tailored to CBSE. The CBSE with reuse process has
to include activities that find and integrate reusable
components.

The component identification process

46
Explanation

An activity that is unique to the CBSE process is identifying

candidate components or services for reuse. This involves a
number of sub activities, as shown in the above figure.
Initially, your focus should be on search and selection. You need to
convince yourself that there are components available to meet your
requirements.
Obviously, you should do some initial checking that the component
is suitable but detailed testing may not be required. In the later
stage, after the system architecture has been designed, you should
spend more time on component validation. You need to be
confident that the identified components are really suited to your
application; if not, then you have to repeat the search and selection
47
processes.
 continue…

Component validation involves developing a set of test cases

for a component.
The major problem with component validation is that the
component specification may not be sufficiently detailed to
allow you to develop a complete set of component tests.

48
 Component composition

Component composition is the process of combining multiple

software components to create a larger, functioning application
or system. It involves integrating components, managing their
dependencies, and ensuring seamless interaction through their
interfaces.
(or)
Component composition is the process of integrating
components with each other, and with specially written ‘glue
code’ to create a system or another component. There are
several different ways in which you can compose components,

49
Glue code

Glue code refers to code written to integrate or connect

different software components, systems, or libraries that may
not natively interact seamlessly. It acts as an intermediary,
enabling these components to work together without
modifying their internal logic or implementation.

50
Examples of Glue code

Middleware: Code that translates between APIs or wraps third-party libraries to integrate
them into a system.
● Example: A Python script that converts data from a REST API into a format usable
by a database system.
Adapters: Code that conforms one interface to another.
● Example: In Java, an adapter class wrapping a legacy service so it can be used in a
new microservices application.
Wrappers: Encapsulation of libraries or APIs to make them compatible with the host
system.
● Example: A wrapper function in JavaScript to make a third-party library fit with the
application's asynchronous workflow.
Event Handling: Code that listens for events from one component and triggers
appropriate actions in another.
● Example: Glue code in an event-driven architecture, where a message from Kafka is
consumed and forwarded to a processing component.
51
Types of Component Composition

1. Sequential Composition
○ In this method, components are composed in a sequence, where the
output of one component is the input to the next.
○ Common in workflows or data processing pipelines.
○ Example: A data processing system where a data validation
component feeds into a data transformation component, which then
passes data to a reporting component.

52
2. Hierarchical Composition

● Involves organizing components in a hierarchical structure, where one

component acts as a controller or aggregator for subcomponents.
● Useful for modular systems with clear parent-child relationships.
● Example: A user interface component where a window contains
buttons, text fields, and menus as its subcomponents.

53
3. Additive Composition
● Combines components by adding their functionalities together to
extend system capabilities.
● Often used in systems requiring feature aggregation.
● Example: Adding authentication and logging components to a core
application to enhance its functionality.

54
 Distributed software engineering

In software engineering, a distributed system refers to a collection of

independent computers or nodes that work together to achieve a common goal.
These systems are characterized by their ability to operate as a cohesive unit
despite being geographically dispersed or physically separate.

Define: a distributed system to be: “. . .a collection of independent

computers that appears to the user as a single coherent system.

55
 Key Features of Distributed Systems

1. Decentralization:
○ The system does not rely on a single central server. Instead, tasks are distributed across
multiple nodes.
2. Concurrency:
○ Multiple processes run concurrently on different nodes, collaborating to achieve the
desired functionality.
3. Transparency:
○ The system hides the complexity from the user, making it appear as a single system.
○ Types of transparency include location, access, replication, concurrency, and failure
transparency.
4. Scalability:
○ These systems can handle growth by adding more nodes without significant changes to
the system architecture.
5. Fault Tolerance:
○ Distributed systems can continue functioning even if some nodes fail, making them
reliable.
6. Communication:
○ Nodes communicate through a network using standard protocols like TCP/IP or 56
Examples of Distributed System & Advantages

1. Cloud Computing Platforms: Amazon Web Services (AWS), Microsoft

Azure, Google Cloud.
2. Distributed Databases: Apache Cassandra, MongoDB, Google Spanner.
3. Peer-to-Peer Networks: Torrent systems, Bitcoin blockchain.
4. Microservices Architecture: Applications like Netflix and Uber.

Advantages

● Improved Performance: Tasks are divided across nodes for faster

processing.
● High Availability: Even if one node fails, others can take over.
● Scalability: Resources can be added easily to meet growing demands.
● Cost Efficiency: Uses commodity hardware instead of expensive single
servers.
57
Advantages of using a distributed approach to systems
development

1. Resource sharing A distributed system allows the sharing of hardware and

software resources—such as disks, printers, files, and compilers—that are
associated with computers on a network.

2. Openness Distributed systems are normally open systems, which means

that they are designed around standard protocols that allow equipment and
software from different vendors to be combined.

3. Concurrency In a distributed system, several processes may operate at the

same time on separate computers on the network. These processes may (but
need not) communicate with each other during their normal operation.

58
Advantages of using a distributed approach to systems
development(Continued…)

4. Scalability In principle at least, distributed systems are scalable in that the

capabilities of the system can be increased by adding new resources to cope
with new demands on the system. In practice, the network linking the individual
computers in the system may limit the system scalability.

5. Fault tolerance The availability of several computers and the potential for
replicating information means that distributed systems can be tolerant of some
hardware and software failures (see Chapter 13). In most distributed systems,
a degraded service can be provided when failures occur; complete loss of
service only occurs when there is a network failure

59
Challenges & Common application

Challenges:

● Complexity: Designing, implementing, and maintaining distributed systems can be

difficult.
● Security Risks: Communication over networks can expose the system to cyber
threats.
● Synchronization: Ensuring consistency across nodes requires sophisticated
algorithms.
● Fault Handling: Identifying and recovering from failures in nodes or communication
can be challenging.

Common Applications:

● Social media platforms (e.g., Facebook, Instagram)

● Online retail systems (e.g., Amazon)
● Real-time collaboration tools (e.g., Google Docs)
● Content delivery networks (e.g., Akamai, Cloudflare)

A distributed system is a cornerstone in modern computing, enabling systems to scale 60

 Distributed systems issues

Some of the most important design issues that have to be considered in

distributed systems engineering are:

1. Transparency To what extent should the distributed system appear to

the user as a single system? When it is useful for users to understand that
the system is distributed?

2. Openness Should a system be designed using standard protocols that

support interoperability or should more specialized protocols be used that
restrict the freedom of the designer?

3. Scalability How can the system be constructed so that it is scalable?

That is, how can the overall system be designed so that its capacity can be
increased in response to increasing demands made on the system?

61
The types of attacks that a distributed system must defend
itself against are the following:

1. Interception, where communications between parts of the system are

intercepted by an attacker so that there is a loss of confidentiality.

2. Interruption, where system services are attacked and cannot be

delivered as expected. Denial of service attacks involve bombarding a
node with illegitimate service requests so that it cannot deal with valid
requests.

3. Modification, where data or services in the system are changed by an

attacker.

4. Fabrication, where an attacker generates information that should not

exist and then uses this to gain some privileges. For example, an attacker
may generate a false password entry and use this to gain access to a
system
62
 continued…

4. Security How can usable security policies be defined and implemented

that apply across a set of independently managed systems?

5. Quality of service How should the quality of service that is delivered to

system users be specified and how should the system be implemented to
deliver an acceptable quality of service to all users? 6. Failure
management How can system failures be detected, contained (so that they
have minimal effects on other components in the system), and repaired?

63
Models of Interaction

Models of Interaction refer to the ways in which components or

systems communicate and exchange information with each other in a
distributed or networked environment. These models define the rules,
patterns, and mechanisms through which systems or processes
interact to achieve specific goals.
Purpose:
○ Facilitate communication between different entities (e.g.,
computers, software components, or users).
○ Ensure that information exchange is efficient and reliable.

64
Models of Interaction

Types of Interaction Models:

○ Procedural Interaction:
One system requests a service from another, waits for a response, and
proceeds step-by-step.
■ Example: A client making a request to a server and waiting for the result.
○ Message-Based Interaction:
One system sends a message to another with all necessary details, and the
receiver processes it independently.
■ Example: Sending an email or a queued task in a distributed system.

Context:
Models of interaction are critical in distributed computing, software design, and human-
computer interaction (HCI). They shape how systems are designed to handle
communication and processing.

65
Example in Real Life: Restaurant Order

● Procedural Interaction:
○ A diner interacts with a waiter to place an order.
○ The conversation proceeds step-by-step: the waiter asks questions,
and the diner responds (e.g., "What would you like to eat?").
● Message-Based Interaction:
○ After taking the orders from all diners, the waiter sends the entire
order to the kitchen at once.

66
Models of Interaction

1. Procedural Interaction
○ Definition: One computer calls a known service from another
computer and typically waits for the result (synchronous interaction).
○ Example:
■ Scenario: Ordering food from a waiter.
■ Interaction:
■ Diner: What would you like?
■ Customer: Tomato soup, please.
■ Waiter: Acknowledged.
■ Customer: Fillet steak cooked rare with salad.
■ Waiter: Noted.
■ Analogy in Computing:
■ A software component calls a method in another component,
waits for the response, and proceeds step by step.
67
Example : Procedural interaction between a diner
and a waiter

It shows the synchronous ordering process as a series of calls

68
Message-Based Interaction

● Definition: A computer sends a message defining the required

information, which another computer processes independently
(asynchronous interaction).
● Example:
○ Scenario: The waiter communicates with the kitchen.
○ Interaction:
■ The waiter consolidates the order (e.g., soup, fillet steak, salad)
from multiple diners and sends it as a single message to the
kitchen staff for preparation.
○ Analogy in Computing:
■ A system sends a message with all necessary details to another
system, which processes the message without direct back-and-
forth communication.
69
Example:Message-based interaction between a
waiter and the kitchen staff

70
Explanation

It shows a hypothetical XML message that defines an order

made by the table of three people. The difference between
these forms of information exchange is clear. The waiter
takes the order as a series of interactions, with each
interaction defining part of the order. However,

71
Middleware

The components in a distributed system may be

implemented in different programming languages and may
execute on completely different types of processor. Models
of data, information representation, and protocols for
communication may all be different. A distributed system
therefore requires software that can manage these diverse
parts, and ensure that they can communicate and
exchange data.
The term ‘middleware’ is used to refer to this
software—it sits in the middle between the distributed
components of the system.

72
Middleware in a distributed system(Diagram)

73
which shows that middleware is a layer between the
operating system and application programs. Middleware is
normally implemented as a set of libraries, which are
installed on each distributed computer, plus a run-time
system to manage communications.

74
In a distributed system, middleware normally
provides two distinct types of support:

1. Interaction support, where the middleware coordinates

interactions between different components in the system.
The middleware provides location transparency in that it
isn’t necessary for components to know the physical
locations of other components. It may also support
parameter conversion if different programming languages
are used to implement components, event detection, and
communication, etc.
2. The provision of common services, where the
middleware provides reusable implementations of services
that may be required by several components in the
distributed system. By using these common services,
components can easily interoperate and provide user 75
services in a consistent way
Client–server computing: Introduction

● Distributed systems that are accessed over the Internet

are normally organized as client–server systems.
● In a client–server system, the user interacts with a
program running on their local computer (e.g., a web
browser or phone-based application).
● This interacts with another program running on a remote
computer (e.g., a web server). The remote computer
provides services, such as access to web pages, which
are available to external clients.
● In a client–server architecture, an application is modeled
as a set of services that are provided by servers.
● Clients may access these services and present results to
end users
76
Client–server Interaction(Diagram)

77
Explanation

This illustrates a situation in which there are four servers

(s1–s4), that deliver different services. Each service has a
set of associated clients that access these services.

It shows client and server processes rather than

processors. It is normal for several client processes to run
on a single processor.

For example, on your PC, you may run a mail client that
downloads mail from a remote mail server. You may also
run a web browser that interacts with a remote web server
and a print client that sends documents to a remote printer.
78
Mapping of clients and servers to networked
computers(Diagram)

79
Explanation

The situation where the 12 logical clients.

Several different server processes may run on the same
processor but, often, servers are implemented as
multiprocessor systems in which a separate instance of
the server process runs on each machine.
Load-balancing software distributes requests for service
from clients to different servers so that each server does
the same amount of work. This allows a higher volume of
transactions with clients to be handled, without degrading
the response to individual clients.

80
Layered architectural model for client–server
application

The architecture of distributed client–server systems are

structured into several logical layers, with clear
interfaces between these layers. This allows each layer
to be distributed to a different computer.

81
Explanation

● A presentation layer that is concerned with presenting

information to the user and managing all user
interaction
● A data management layer that manages the data that
is passed to and from the client. This layer may
implement checks on the data, generate web pages,
etc.
● An application processing layer that is concerned
with implementing the logic of the application and so
providing the required functionality to end users
● A database layer that stores the data and provides
transaction management services, etc
82
Architectural patterns for distributed systems(
five architectural styles)

1. Master-slave architecture, which is used in real-time

systems in which guaranteed interaction response times are
required.
2. Two-tier client–server architecture, which is used for
simple client–server systems, and in situations where it is
important to centralize the system for security reasons. In
such cases, communication between the client and server is
normally encrypted.
3. Multitier client–server architecture, which is used when
there is a high volume of transactions to be processed by the
server.

83
4. Distributed component architecture, which is used when
resources from differ ent systems and databases need to be
combined, or as an implementation model for multi-tier client–
server systems.
5. Peer-to-peer architecture, which is used when clients
exchange locally stored information and the role of the server
is to introduce clients to each other. It may also be used when
a large number of independent computations may have to be
made.

84
 A traffic management system with a master-slave
architecture(Example)

The ‘master’ process is usually responsible for computation, coordination, and

communications and it controls the ‘slave’ processes.
The ‘Slave’ processes are dedicated to specific actions, such as the
acquisition of data from an array of sensors.

85
Explanation

Model Description: Represents a traffic control system with three

logical processes running on separate processors.
Master Process:
● Located in the control room.
● Communicates with slave processes.
● Displays traffic status, computes traffic light sequences, and
processes operator commands.
● Organized as a client-server system, with client processes on
operator consoles.
Slave Processes:
● Collect traffic data from sensors.
● Manage the operation of traffic lights.
Sensor Control Process:
● Periodically polls distributed sensors for traffic flow information. 86
● Collates traffic data for further processing.
Master-Slave Interaction:
● The sensor control process is polled periodically by the master
process.
● The master process sends commands to the traffic light control
process, which converts these into signals for hardware.
Application Context:
● Suitable for situations with predictable distributed processing
needs.
● Effective when processing can be localized to slave processors.
● Common in real-time systems requiring strict processing
deadlines.
● Slave processors handle computationally intensive tasks like signal
processing and equipment management. 87
Two-tier client–server architectures

A two-tier client-server architecture is the simplest client-

server model.
Server: The system includes a single logical server.
Clients: An indefinite number of clients can interact with
the server.
Structure: The architecture has two layers:
● Client Tier: Handles user interfaces and application
logic.
● Server Tier: Manages data storage, processing, and
services.
Key Characteristic: Direct communication occurs between88
Thin- and fat-client architectural models

89
Explanation

Thin-Client Model:
● The presentation layer is implemented on the client device.
● All other layers (data management, application processing,
and database) are implemented on the server.
● Client Software:
○ May be a custom-written program.
○ Commonly, a web browser is used for data presentation.
Fat-Client Model:
● Some or all application processing occurs on the client
device.
● Data management and database functions are handled by
the server.
90
Thin-Client Model Advantages & Disadvantages

Advantages:
● Ease of Management: Simple to manage clients, even with a large
number of them.
● No Software Installation: No need to install software if a web
browser is used as the client.
Disadvantages:
● Server Load: Places a heavy processing load on the server.
● Network Traffic: Generates significant network traffic between the
client and server.
● Infrastructure Costs: May require additional investment in network
and server capacity.
● Limited Local Processing: Although browsers can execute scripts
(e.g., JavaScript), they still rely heavily on the server for
91
computations.
Fat-Client Model Advantages & Disadvantages

Fat-Client Model
● Advantages:
○ Efficient Use of Client Resources: Utilizes the processing
power of client computers.
○ Distributed Processing: Distributes application processing
and presentation to the client.
○ Simplified Server Role: Server functions mainly as a
transaction server managing database transactions.
○ Straightforward Data Management: No need to manage
interactions between the client and application processing
system.
● Disadvantages:
○ System Management Complexity: Requires additional effort
92
to deploy and maintain software on client computers.
A fat-client architecture for an ATM system

93
Situation Where Fat-Client Architecture is
Used:Bank ATM System

Bank ATM System

● Client & Server Components:

○ The ATM is the client computer.
○ The server is typically a mainframe running the customer account database.
● Role of Mainframe:
○ A powerful machine designed for transaction processing.
○ Handles large transaction volumes generated by ATMs, teller systems, and onlin
banking.
● Processing in ATMs:
○ The ATM software handles a significant portion of the customer-related transa
processing.
● Teleprocessing Monitor:
○ Acts as middleware to manage communication between ATMs and the database
○ Serializes client transactions, ensuring they remain independent and do not interf
with each other.
94
○ Enables fault recovery without corrupting system data.
 Advantages & Disadvantages of Fat-Client Model in This
Context

Advantages of Fat-Client Model in This Context:

● Distributed Processing:
○ ATM machines carry out much of the transaction-related processing.
● Reduced Server Load:
○ The mainframe processes only essential database transactions rather
than handling all computation.
Disadvantages of Fat-Client Model:
● Complex System Management:
○ Application software needs updates on every ATM client, which can be
costly and time-consuming.
● Remote Software Upgrades:
○ May require designing the system to support remote software upgrades.
● Downtime for Updates:
○ May necessitate shutting down all services during updates, leading to
temporary service interruptions. 95
Multi-tier client–server architectures

Definition:
● A multi-tier client-server architecture divides different layers of the
system into separate processes.
● These layers may execute on different processors.
Key Layers in Multi-Tier Architecture:
1. Presentation Layer: Managed by the client (e.g., user's Internet
browser).
2. Data Management Layer: Managed by web servers for data
handling and web page generation.
3. Application Processing Layer: Handles logic like transferring
cash, generating statements, paying bills, etc.
4. Database Layer: Managed by a database server (often hosted on
a mainframe). 96
Example:Three-tier architecture for an Internet
banking system

Three-tier architecture for an Internet banking system

97
Example: Internet Banking System

Three-Tier Model:
○ Customer Database: Hosted on a mainframe to store
customer account information.
○ Web Server: Manages data management and application
services like generating web pages and executing customer
actions.
○ Client (User's Internet Browser): Acts as the front end for
users to interact with the system.

98
Advantages of the Three-Tier Model:

○ Scalability: Additional servers can be added as the number

of customers increases (scale-out).
○ Optimized Communication: Information transfer between
web servers and database servers uses fast, low-level
protocols.
○ Efficient Middleware: Supports database queries in SQL
(Structured Query Language) for faster information retrieval.

99
Extensions to Multi-Tier Architecture

Multi-Tier Variants:
○ Additional servers can be added to separate data
management, application processing, and database
functions further.
○ Integration Servers: Used to combine data from multiple
distributed databases into a unified view for application
servers.
■ Ensures seamless data access across systems by
aggregating data and presenting it as a single database.
● Distributed Component Architectures:
○ Implement multi-tier systems with distributed services.

100
Key Considerations for Designers:

When designing client-server architectures, designers must evaluat

factors such as:
1. Application processing volatility(Scalability requirements (handlin
growing customer loads).
2. Fault tolerance-
3. Middleware efficiency and protocol selection.
4. Communication optimization across distributed layers

101
Use of client–server architectural patterns

102
Service -oriented Architecture

Service-Oriented Architecture (SOA)

Definition:
Service-Oriented Architecture (SOA) is a design pattern used to create distributed systems that provide services to applications or
other services through standard protocols. It is an architectural approach, not tied to any specific programming language or
platform.

103
Key features of SOA

1. Loosely Coupled:
○ Services interact with minimal dependencies, making them flexible and reusable.
2. Message-Based Communication:
○ Communication between services is typically done using standard message formats like XML or JSON over
protocols like HTTP, SOAP, or REST.
3. Interoperability:
○ Services can interact regardless of the underlying technology stack, enabling cross-platform integration.
4. Reusability:
○ Services are designed to be reusable across different applications.
5. Abstraction:
○ Service details are hidden from the consumer, who only interacts through a defined interface.
6. Scalability:
○ SOA systems can scale horizontally by adding more service instances.
7. Discoverability:
○ Services are registered in a directory and can be discovered by consumers dynamically.

104
What is Service?

What is a Service?

A service in SOA is a well-defined, self-contained functionality that:

● Represents a specific task or business process.

● Can exchange information with other services.
● Operates independently of the state or context of other services.
● Can be reused across multiple applications.

Example Services:

● Authentication Service
● Payment Processing Service
● Weather Forecasting Service

105
Service connection

The figure given below illustrates the service-oriented architecture. Service consumer sends a service request
to the service provider, and the service provider sends the service response to the service consumer. The
service connection is understandable to both the service consumer and service provider.

106
Service oriented Terminologies

Service-Oriented Terminologies

107
Explanation

○ Services - The services are the logical entities defined by one or more published interfaces.
○ Service provider - It is a software entity that implements a service specification.
○ Service consumer - It can be called as a requestor or client that calls a service provider. A service
consumer can be another service or an end-user application.
○ Service locator - It is a service provider that acts as a registry. It is responsible for examining service
provider interfaces and service locations.
○ Service broker - It is a service provider that pass service requests to one or more additional service
providers.

108
Components of SOA

The service-oriented architecture stack can be categorized into two parts - functional aspects and quality of
service aspects.

109
Explanation

he functional aspect contains:

○ Transport - It transports the service requests from the service consumer to the service provider
and service responses from the service provider to the service consumer.
○ Service Communication Protocol - It allows the service provider and the service consumer to
communicate with each other.
○ Service Description - It describes the service and data required to invoke it.
○ Service - It is an actual service.
○ Business Process - It represents the group of services called in a particular sequence associated
with the particular rules to meet the business requirements.
○ Service Registry - It contains the description of data which is used by service providers to publish
their services.

110
Quality of Service Aspects

○ Policy - It represents the set of protocols according to which a service provider make and provide
the services to consumers.
○ Security - It represents the set of protocols required for identification and authorization.
○ Transaction - It provides the surety of consistent result. This means, if we use the group of services
to complete a business function, either all must complete or none of the complete.
○ Management - It defines the set of attributes used to manage the services.

111