UNIT-I:

EnvisioningArchitecture:TheArchitectureBusinessCycle,WhatisSoftwareArchitecture,Architectu
ralpatterns,referencemodels,reference architectures,architectural structures and views

1. What is Software Architecture?

Software Architecture:
Soft ware Architecture is the high level structure of the Software system. Like blue print in building
architecture.
Soft ware Architecture consist of following :
i. Software components
ii.details
iii.relationship among components
iv.dataflow ,controlflow,dependencies

Elements of Software Architecture:

a.components
b.connectors
c.configuration topologies
d.system models

2. The Architecture Business Cycle(ABC)

A Software Architecture is the result of Technical ,Business and Social influences .the following
diagram illustrate the ABC

The ArchitectureBusiness Cycle

1.Stakeholders:
The persons or organizations who are going to use after development of this product.
Simply we can remember Stakeholders are Users
Stakeholdres:
 a)The customer
b)The end users
c)The developers
d)The project manager
e)The maintainers
2.Devoloping organization:
The organization who is going to develop this particular product or services is consider as developing
organization

1. In addition to the organizational goals expressed through requirements, an architecture is influenced by

the structure or nature of the development organization.
2. For example, if the organization has an abundance of idle programmers skilled in client-server
communications, then a client-server architecture might be the approach supported by management.
3.If not, it may well be rejected. Staff skills are one additional influence, but so are the development
schedule and budget.
3.Techincal environment:
What technology we have used to develop this product
1.A special case of the architect's background and experience is reflected by the technical environment.
2. The environment that is current when an architecture is designed will influence that architecture.
3. It might include standard industry practices or software engineering techniques prevalent in the
architect's professional community.
4.Architect’s Experience:
1.The architects may also wish to experiment with an architectural pattern or technique learned from a
book (or) a course.
2.the architects for a system have had good results using a particular architectural approach
5 Quality requirements:
1.modifiability
2.performance
3.avilability.
4.network usage
5.better memory
3.Architectural patterns, Reference models and Reference architectures
Architectural patterns:
Architecture patterns:
Architecture patterns are reusable designs which consists of structure and organization of software
systems
There are many ways to organize these parts, called software architecture patterns.
These patterns have been tested and proven to solve different problems by arranging components in
specific ways
Types of Software Architecture Patterns
1. Layered Architecture Pattern:
i)As the name suggests, components(code) in this pattern are separated into layers of subtasks
and they are arranged one above another.
ii)Each layer has unique tasks to do and all the layers are independent of one another.
iii)Since each layer is independent, one can modify the code inside a layer without affecting
others.
iv)It is the most commonly used pattern for designing the majority of software. This layer is
also known as ‘N-tier architecture.

Basically, this pattern has 4 layers.

1. Presentation layer: The user interface layer where we see and enter data into an application.)
2. Business layer: This layer is responsible for executing business logic as per the request.)
3. Application layer: This layer acts as a medium for communication between the ‘presentation layer’
and ‘data layer’.
4. Data layer: This layer has a database for managing data.

2.Client-Server Architecture Pattern :

The client-server pattern has two major entities.

They are a server and multiple clients.
Here the server has resources(data, files or services) and a client requests the server for a particular
resource.
Then the server processes the request and responds back accordingly.
3.Event-Driven Architecture Pattern
Event-Driven Architecture is an agile approach in which services (operations) of the software are
triggered by events.
When a user takes action in the application built using the EDA approach, a state change happens and a
reaction is generated that is called an event.
Example:
A new user fills the signup form and clicks the signup button on Facebook and then a FB account is
created for him, which is an event.

4.Microkernel Architecture Pattern:

Microkernel pattern has two major components. They are a core system and plug-in modules.
• The core system handles the fundamental and minimal operations of the application.
• The plug-in modules handle the extended functionalities (like extra features) and customized
processing.
you have successfully built a chat application
The basic functionality of the app is that you can text with people across the world without an internet
connection.
After some time, you would like to add a voice messaging feature to the application, then you are
adding the feature successfully
You can add that feature to the already developed application because the microkernel pattern
facilitates you to add features as plug-ins.
5. Microservices Architecture Pattern:
The collection of small services that are combined to form the actual application is the concept of
microservices pattern.
Instead of building a bigger application, small programs are built for every service (function) of an
application independently.
Those small programs are bundled together to be a full-fledged application. So adding new features
and modifying existing microservices without affecting other microservices are no longer a challenge
when an application is built in a microservices pattern.
6. Space-Based Architecture Pattern:
Space-Based Architecture Pattern is also known as Cloud-Based or Grid-Based Architecture Pattern.
It is designed to address the scalability issues associated with large-scale and high-traffic applications
This pattern is built around the concept of shared memory space that is accessed by multiple nodes.
7. Master-Slave Architecture Pattern:
The Master-Slave Architecture Pattern is also known as Primary-Secondary Architecture.
It involves a single master component and that controls multiple slave components.
The master components assign tasks to slave components and the slave components report the results
of task execution back to the master.
8. Pipe-Filter Architecture Pattern:
Pipe-Filter Architecture Pattern structures a system around a series of processing elements called filters
that are connected by pipes.
Each filter processes data and passes it to the next filter via pipe.
9. Broker Architecture Pattern:
The Broker architecture pattern is designed to manage and facilitate communication between
decoupled components in a distributed system. It involves a broker that acts as a intermediary to route
the requests to the appropriate server.
10. Peer-to-Peer Architecture Pattern:
The Peer-to-Peer (P2P) architecture pattern is a decentralized network model where each node, known
as a peer, acts as both a client and a server.
There is no central authority or single point of control in P2P architecture pattern. Peers can share
resources, data, and services directly with each other.

Reference model:
A reference model is a division of functionality together with data flow between the pieces.
A reference model is a standard decomposition of a known problem into parts that cooperatively
solve the problem.
Reference Architecture:
Reference architecture is a reference model mapped onto software elements (that cooperatively
implement the functionality defined in the reference model) and the data flows between them.
Where as a Reference model divides the functionality, reference architecture is the mapping of
that functionality onto system decomposition.
The relationship among these design elements is shown in Figure
3.Architectural structures and views

Structure: A Structure is set of elements itself, as they exist in Software or Hardware

View: A view is coherent set of architectural elements, as written by and read by system stakeholders

This view shows the relationship in the system.

Architectural structures broadly classified as
1.moduler structures
2.component and connector structures
3.allocation structures

1.moduler structures:

i)these are units of implementation i.e. code based

ii)they are the areas of functional responsibilities
iii)it allows us to answer the questions of primary responsibilities of each module
iv)is the module generalized or specialized

2.component and connector structures:

i) these elements are runtime components i.e. principal components

ii)connectors are the communicator components
iii)c&c helps in identifying and executing the major components to execute in applications
iv)c&c helps in data store i.e what and how the data store
v)it helps in how data progress in the systems

3.Allocation structures:

i)it is a collection of software elements is one or more stores in environment

ii)software elements are mapped on to file storage structures

.
 Figure5:Common software architecture structures

The units are modules related to each other by the "is a

Decomposition submodule of
" relation, showing how larger modules are decomposed into
smaller ones recursively until they are small enough to be
easily understood
Module
The units of this important but overlooked structure are also
Uses modules,
Or procedures or resources on the interfaces of modules.
When the uses relations in this structure are carefully
Layered controlled in a particular way, a system of layers emerges, in
which alayerisa
Coherent set of related functionality.
The module units in this structure are called classes.The relation
Class is "inherits-from"or"is-an-instance-of."

If the system is built as a group of cooperating clients and servers,

Client-server this is a good component-and-connector structure to illuminate.
Componen This component-and-connector structure allows the
t-and- Concurrency architect to determine opportunities for parallel is mand
Connector the locations where resource contention may occur.
Like all component-and-connector structures, this one is
Process orthogonal to the module-based structures and deals with the
dynamic aspects of a running system.

This structure comprises components and connectors that create,

Shared data store, and access persistent data.
 Work This structure assigns responsibility for implementing and
assignmen integrating the modules to the appropriate development teams.
Allocation t
The deployment structures how show software is assigned to
Deployment hardware-processing and communication elements.
This structures how show software elements (usually modules)
Implementation are mapped to the file structure(s)in the system's development,
integration, or configuration control environments.

Views:
View is a coherent set of architectural elements, are write and read by corresponding stakeholders
Views are divided into following types:
1.Moduler view
2.Component and Connector view
3.Allocation view
Moduler view:
A module is an implementation unit that provides a coherent set of responsibilities.
Module views are decomposition, uses, and layers. Every module has a collection of properties assigned
to it.
Module views contains the following properties.
Name:
A module’s name is , of course, the primary means to refer to it.name is used to identify module
Responsibilities:
Each and every module have their responsibilities depend on the module
Visibility of interface: when a module has sub modules some interfaces are public, some may be private
and some may be protected
Implementation information:
modules are units of implementation
mapping to source code units:
this identifies the files that constitute the implementation of a module
test information:
the modules test plan, test cases and test data
implementation constraints:
in many cases the architect will have an implementation strategy in mind for a module
Revision history:
Knowing the history of a module including authors and particular changes may help to perform
maintenance activities
Component and connector views:
component and connector views shows elements that have some run time presence such as processes,
objects, clients, servers and data stores
c &c views contains the following properties
Reliability:
This property might be used to help determine overall system availability
Performance:
This property is used with others to determine system wide properties such as response times
Resource requirements:
This property is used to determine if proposed hardware configuration will be required
Functionality:
This property can be used to reason about overall computation performed by a system.
Security:
This property can be used to be determined system security vulnerabilities.
Concurrency:
This property can help to analyse the performance of concurrent components and identify possible
deadlocks.
Modifiability:
This property can be defined to extend the functionality of a component.
Tier:
This property can define the build and deployment procedures, as well as platform requirements for each
tier.
Allocation views:
Allocations views describe the mapping of a software units to elements of an environment in which the
software is developed. Allocation views consist of software elements and environmental elements.
5.Software Architecture Quality attributes
Quality Attribute:
i)Achieving quality attributes must be considered throughout design, implementation, and deployment.
ii)No quality attribute is entirely dependent on design, nor is it entirely dependent on implementation or
deployment.
iii)Satisfactory results are a matter of getting the big picture (architecture) as well as the details
(implementation) correct.
Quality attributes:
1)maintainability
2)Usability
3)performance
4)security
5)testability
6)availability
1.Maintainability:
This quality attribute defines the degree of efficiency to which a software solution can be modified for its
improvement or adaptation to the evolving requirements or changes in the environment.
Take a look at the following sub-characteristics of this quality attribute:
i)Reusability defines the degree to which a system component or an asset can be utilized on
several systems or in building other components or assets.
ii)Modifiability means the degree to which a software system can be effectively modified without
causing defects or bugs or decreasing the quality of the existing system.
iii)Testability shows the degree to which test criteria can be used for the software system, and
tests can be performed to determine whether these criteria have been satisfied.
2.Usability
This software quality attribute helps define the ease with which users can perform a specific task
on the system (registering an account or adding an item to the shopping cart). What issues can be
seen as usability problems? These may include inconsistency, too complicated signup process,
poor error handling, or unclear navigation, to name a few.
This software characteristic consists of the following sub-characteristics:
Operability denotes the degree to which a software system or a digital product has qualities that
simplify its operation and control.
User error protection is the degree to which a software system or its components protect users
from committing errors.
User interface aesthetics means the degree to which users get pleasing and satisfying interaction
with a software solution or digital product.
3.Performance efficiency
This software quality attribute shows a software product’s performance relative to the number of
resources applied under predefined conditions.
When checking the performance efficiency, consider the following sub-characteristics:
Time behavior means the degree to which an operating software solution’s response and
processing time meet the predefined requirements.
Capacity is the degree to which the maximum limit of a software product or parameters satisfies
the established requirements.
Resource utilization defines the degree to which the amount of resources utilized by a working
 software system satisfies the main requirements.
4.Security
This attribute of product quality refers to the degree to which a software system safeguards the
information or data so that users or other systems have the degree of access to these data based on
the authorization level.
The main sub-characteristics of this software quality attribute are as follows:
Confidentiality is the degree to which a software system guarantees that only authorized users
can access the data.
Integrity is the degree to which a software system prevents unauthorized access to a program or
data.
Authenticity is the degree to which the identity of the user or resource can be verified when
required.
Accountability means the degree to which the actions of a particular entity can be monitored and
tracked uniquely to this entity.
5.Testability
In simple terms, testability determines how easy a software solution is to test to find bugs or
ensure that it meets all predefined criteria.
Testability can result from efficient collaboration between the development, product, and testing
teams. The development team should consider the testing ability when implementing a new
feature. Thus, the input of testers is required to ensure efficient testing.

6.avilability:

Availability is part of reliability and is expressed as the ratio of the available system time to the

total working time. Important indicators for this attribute are: Availability, Planned downtime,

The time needed to update the software, and so on.

Achieving qualities:
The achievement of these qualities relies on fundamental design decisions. We will examine these
design decisions, which we call tactics. A tactic is a design decision that influences the control of
a quality attribute response. A system design consists of a collection of decisions. Some of these
decisions help control the quality attribute responses; others ensure achievement of system
functionality.

Figure 9: Tactics are intended to control responses to stimuli

We organize the tactics for each system quality attribute as a hierarchy, but it is important to
understand that each hierarchy is intended only to demonstrate some of the tactics, and that any
list of tactics is necessarily incomplete.
1.1 Availability Tactics: A failure occurs when the system no longer delivers a service that is
consistent with its specification; this failure is observable by the system's users. A fault (or
combination of faults) has the potential to cause a failure. Recall also that recovery or repair is an
important aspect of availability. We first consider fault detection. We then consider fault recovery
and finally, briefly, fault prevention.

Figure 10: Goal of availability tactics

Figure 11: Summary of availability tactics

1.2 Modifiability Tactics: We organize the tactics for modifiability in sets according to their goals.
One set has as its goal reducing the number of modules that are directly affected by a change. We
call this set "localize modifications." A second set has as its goal limiting modifications to the
localized modules. We use this set of tactics to "prevent the ripple effect." Implicit in this
distinction is that there are modules directly affected (those whose responsibilities are adjusted to
accomplish the change) and modules indirectly affected by a change (those whose responsibilities
remain unchanged but whose implementation must be changed to accommodate the directly
affected modules). A third set of tactics has as its goal controlling deployment time and cost. We
call this set "defer binding time."

Figure 12: Goal of modifiability tactics

Figure 13: Summary of modifiability tactics

1.3 Performance Tactics: The event can be single or a stream and is the trigger for a request to
perform computation. It can be the arrival of a message, the expiration of a time interval, the
detection of a significant change of state in the system's environment, and so forth. The system
processes the events and generates a response. Performance tactics control the time within which a
response is generated.

Figure 14: Goal of performance tactics

Figure 15: Summary of performance tactics

1.4 Security Tactics: Tactics for achieving security can be divided into those concerned with
resisting attacks, those concerned with detecting attacks, and those concerned with recovering
from attacks. All three categories are important. Using a familiar analogy, putting a lock on your
door is a form of resisting an attack, having a motion sensor inside of your house is a form of
detecting an attack, and having insurance is a form of recovering from an attack.

Figure 16: Goal of security tactics

Figure 17: Summary of tactics for security

1.5 Testability Tactics: The goal of tactics for testability is to allow for easier testing when an
increment of software development is completed.

Figure 18: Goal of testability tactics

Figure 19: Summary of testability tactics

1.6 Usability Tactics: Two types of tactics support usability, each intended for two categories of
"users." The first category, runtime, includes those that support the user during system execution.
The second category is based on the iterative nature of user interface design and supports the
interface developer at design time. It is strongly related to the modifiability tactics already
presented.

Figure 20: Goal of runtime usability tactics

Figure 21: Summary of runtime usability tactics

 2. Architectural styles and patterns:

An architectural style is a set of principles and patterns that guide the organization of a software
system.
It dictates how components and modules within the system interact and communicate.
In essence, it comprises a set of principles and patterns that dictates how component within the
system communicate.

1. Client Server

The client-server architecture is a model in which the client, a user or an application, sends a

request to the server, which in turn responds with the requested data or service. The client and

server can be on the same machine or on different machines connected through a network.

The client is responsible for initiating communication with the server and sending a request. The

server, on the other hand, listens for incoming requests from clients, processes them, and

returns a response.

Advantages of Client-Server Architecture

Scalability: Client-server architecture is highly scalable, as it allows multiple clients to connect to the
same server and share resources.

Security: Client-server architecture provides better security than other network models, as the server
can control access to resources and data.

Reliability: Client-server architecture is highly reliable, as the server can provide backup and recovery
services in case of failures.

2. Layering
It’s a common way to design complex software systems, and it involves breaking down the system into

layers, where each layer is responsible for a specific set of functions. This approach helps to organize

code and makes it easier to maintain and modify the system over time.

A typical layering architecture consists of three main layers: presentation,

business logic, and data access.

Presentation Layer: The presentation layer is responsible for displaying information to the user and

gathering input. This layer includes the user interface and any other components that interact directly

with the user. The user interface is what the user sees and interacts with, such as buttons, text boxes, and

menus. The presentation layer also includes any logic related to the user interface, such as event handlers

and validation.

Business Logic Layer: The business logic layer is responsible for implementing the business rules

of the application. This layer contains the code that processes and manipulates data, as well as any other

application logic. The business logic layer is where the magic happens, so to speak. It’s where the

software performs calculations, makes decisions, and carries out tasks. This layer is where the software

really earns its keep.

Data Access Layer: The data access layer is responsible for interacting with the database or other

external data sources. This layer contains the code that reads and writes data to and from the database.

The data access layer is where the software retrieves data from the database, makes changes to the data,

and saves the changes back to the database. This layer is critical to the functioning of the software, as it

enables the software to store and retrieve data.

3. Pipe and Filter

Pipe and Filter Architecture is a design pattern that allows software systems to process data by separating
the processing tasks into multiple independent components. This architecture is particularly useful for
systems that need to handle large amounts of data, as it can help to improve performance, scalability, and
maintainability.

The Pipe and Filter Architecture is based on the idea of a pipeline, where data flows through a series of
processing steps, each of which performs a specific task. Each processing step is implemented as a
separate component, or filter, that accepts data as input, performs some operation on the data, and
produces output data. The output data is then passed on to the next filter in the pipeline.

The filters in the pipeline are independent of each other, which means that they can be developed, tested,
and deployed separately. This makes it easy to add new filters to the pipeline or modify existing ones
without affecting the rest of the system.

Benefits

Scalability: The architecture can be scaled horizontally by adding more filters to the pipeline, which
allows the system to handle larger amounts of data.

Performance: The architecture can be optimized for performance by parallelizing the processing of
data across multiple filters.

Maintainability: The architecture promotes modularity and separation of concerns, which makes it
easier to maintain and update the system over time.

3. Pipe and Filter

Pipe and Filter Architecture is a design pattern that allows software systems to process data by

separating the processing tasks into multiple independent components. This architecture is

particularly useful for systems that need to handle large amounts of data, as it can help to

improve performance, scalability, and maintainability.

The Pipe and Filter Architecture is based on the idea of a pipeline, where data flows through a

series of processing steps, each of which performs a specific task. Each processing step is

implemented as a separate component, or filter, that accepts data as input, performs some

operation on the data, and produces output data. The output data is then passed on to the next

filter in the pipeline.

The filters in the pipeline are independent of each other, which means that they can be

developed, tested, and deployed separately. This makes it easy to add new filters to the pipeline

or modify existing ones without affecting the rest of the system.

Benefits

Scalability: The architecture can be scaled horizontally by adding more filters to the pipeline,

which allows the system to handle larger amounts of data.

Performance: The architecture can be optimized for performance by parallelizing the

processing of data across multiple filters.

Maintainability: The architecture promotes modularity and separation of concerns, which

makes it easier to maintain and update the system over time.

4. Master-Slave

Master-Slave architecture is a design pattern used in distributed systems, where one node (the

master) controls one or more nodes (the slaves) to perform specific tasks. The master node is

responsible for distributing the workload across the slaves and for coordinating their activities.

The slave nodes do not have the same level of control as the master node and only perform tasks

that are assigned to them by the master.

Benefits

One of the most significant advantages is that it allows for the efficient distribution of workload

across multiple nodes. This helps to reduce the load on any one node and ensures that the

system can handle large amounts of data and traffic.

Another advantage of using a master-slave architecture is that it provides fault tolerance. If one

of the slave nodes fails, the master node can redistribute its workload to the other slave nodes.

This ensures that the system can continue to function even if one or more nodes fail.

5. MicroKernel

MicroKernel architecture is a software design pattern that allows developers to build more

modular and flexible systems. It separates the core system functionality from additional features,

which are implemented in separate modules. The core functionality of the system is

implemented in the MicroKernel, a minimalistic core system that provides only the most

essential services required to run the system. It is plug and play concept.

Example:

Let’s consider the example of an e-commerce website. The MicroKernel would provide essential

services such as handling user authentication, managing user sessions, and processing

payments. Additional features, such as product recommendations, user reviews, and social

media integration, would be implemented in separate modules.

If the website wants to add a new feature, such as a loyalty program, it can be developed and

added as a separate module without affecting the core functionality of the system. This
modularity makes it easier to add new features or remove existing ones without affecting the

core system functionality.

Furthermore, if the website wants to customize its system to meet the specific needs of different

users, it can choose the modules it needs for each user. For example, a user who frequently buys

electronics can be provided with a module that recommends electronic products. On the other

hand, a user who frequently buys cosmetics can be provided with a module that recommends

cosmetic products.

Finally, if the website wants to scale its system to handle more users or changes in hardware, it

can easily add or remove modules as needed. This scalability makes it easier to adapt the system

to changes in user requirements or changes in the underlying hardware.

6. DDD (Domain Driven Design)

At its core, DDD is a way of thinking about software architecture that emphasizes the domain or

problem space of a project. This means that developers focus on the business logic of the

software, rather than just the technical implementation.

In practice, this means that developers start by understanding the domain they are working in

and break it down into smaller, more manageable parts. They then use this understanding to

create a domain model, which is a representation of the different entities within the domain and

how they interact with one another.

Once the domain model is created, developers can use it to guide the rest of the architecture of

the software. This includes creating bounded contexts, which are areas of the software that are

defined by a specific language and context, and aggregates, which are collections of related

entities that are treated as a single unit.

7. Component Based

In software engineering, component-based architecture (CBA) is an approach to software design

and development that emphasizes the use of reusable software components. The idea behind

CBA is that software development can be made more efficient and effective by breaking down

complex systems into smaller, more manageable components.

What is a component?

A software component is a modular, self-contained unit of software that can be reused across

different systems. A component typically has a well-defined interface, which specifies how other

components can interact with it. This interface includes information about the component’s

inputs, outputs, and behavior.

Components can be classified into different types based on their functionality, such as user

interface components, data access components, and business logic components. Each type of

component has a specific role in the software system and can interact with other components

through their interfaces.

8. SOA

SOA is an architectural style that aims to create modular, reusable services that can be easily

integrated with other services to create a larger system. In this approach, services expose their

functionality through interfaces, which can be accessed by other services or applications.

At its core, SOA is about building software by breaking it down into smaller pieces, or modules,

that can be reused across different applications. This modular approach allows developers to

focus on building specific pieces of functionality and then integrating them with other pieces to

create a larger system.

Core Components of SOA

Service Provider: The service provider is responsible for creating and exposing services to the

outside world. These services can be used by other services, applications, or end-users. For

example, a payment processing service provider might create and expose a service that allows

other applications to process payments.

Service Registry: The service registry is a directory of available services that can be accessed by

other services or applications. The service registry provides information about the service, such

as its name, location, and interface. For example, if an application needs to process payments, it

can use the service registry to find the payment processing service and access its interface.

Service Requestor: The service requestor is responsible for consuming the services exposed by

the service provider. This can be done by using the service registry to find the appropriate service

and then invoking its interface. For example, an application might use the service registry to find

the payment processing service and then use its interface to process payments.

9. Monolithic

Monolithic architecture is a software design pattern that has been around for decades. It’s a way

of structuring an application as a single, cohesive unit, rather than splitting it up into individual,

smaller components.

In a monolithic architecture, the entire application is built as a single, self-contained unit. All of

the code and dependencies are packaged together, so the application can be deployed and run on

a single server.
This makes it easy to develop and deploy the application, since everything is in one place. It also

makes it easier to scale the application horizontally, by adding more servers.

Advantages of Monolithic Architecture

One of the biggest advantages of monolithic architecture is its simplicity. Since everything is

contained in a single unit, there are fewer moving parts to worry about. This makes it easier to

develop, test, and deploy the application.

Another advantage is that it’s easier to maintain and debug a monolithic application. Since

everything is in one place, it’s easier to track down issues and fix them.

Disadvantages of Monolithic Architecture

One of the biggest disadvantages of monolithic architecture is that it can be difficult to scale the

application vertically. Since everything is running on a single server, there’s a limit to how much

traffic the application can handle.

Another disadvantage is that it can be difficult to adopt new technologies and languages in a

monolithic application. Since everything is packaged together, it can be hard to update

individual components without breaking the entire application.

10. Microservice

Microservice architecture is a style of software architecture that structures an application as a

collection of small, independent services that communicate with each other over a network. Each

service is focused on a specific business capability and can be developed, deployed, and scaled

independently of other services in the system.

The main idea behind microservice architecture is to break down a large, monolithic application

into smaller, more manageable services. This approach brings several benefits, such as improved

scalability, increased flexibility, and quicker time-to-market for new features. With a

microservice architecture, each service can be scaled independently, making it easier to handle

traffic spikes or changes in demand. Developers can also modify or add new services without

affecting other parts of the system, which speeds up the development process.

Challenges of Microservice Architecture

Despite the benefits of microservice architecture, it also introduces additional complexity. One of

the biggest challenges is managing inter-service communication. Services need to be able to

discover each other and communicate effectively, which can be difficult to do at scale. Load

balancing and fault tolerance are also more complex in a microservice architecture.

Another challenge is ensuring that each service has its own data store. In a monolithic

application, all data is typically stored in a single database. With microservices, each service

should have its own data store to ensure that changes to one service do not affect other services

in the system. This can lead to increased complexity in data management and synchronization.

11. Event Driven

Event Driven Architecture (EDA) is an approach to designing software systems that enables

rapid and efficient communication between different components or services. In this paradigm,

different software components communicate with each other using events, rather than through

direct requests or responses.

In EDA, events are generated by different components of a software system, such as a user

interface or a backend service. These events are then broadcast to other components of the

system, which can subscribe to them and act on them as needed.

12. Stream Based

As software development becomes more complex and demands greater scalability, traditional

architectures are becoming less and less effective. Stream-based architecture is emerging as a

promising alternative that enables developers to build systems that can handle massive amounts

of data in real-time.

At its core, stream-based architecture is based on the principles of event-driven programming.

Instead of processing data in batches, stream-based systems process data as it is generated in

real-time. This allows developers to build systems that can respond to changes in data with

minimal latency

7.Designing the Architecture:

Architecture in the Life Cycle:

• Any organization that embraces architecture as a foundation for its software development
processes needs to understand its place in the life cycle.
• Several life-cycle models exist in the literature, but one that puts architecture squarely in
the middle of things is the Evolutionary Delivery Life Cycle model shown in Figure.
• The intent of this model is to get user and customer feedback and iterate through several
releases before the final release.
• The model also allows the adding of functionality with each iteration and the delivery of a
limited version once a sufficient set of features has been developed.
 Evolutionary Delivery Life Cycle

Designing the Architecture:

• In this section we describe a method for designing architecture to satisfy both quality
requirements and functional requirements.
• We call this method Attribute-Driven Design (ADD). ADD takes as input a set of quality
attribute scenarios and employs knowledge about the relation between qualities attribute
achievement and architecture in order to design the architecture.
• The ADD method can be viewed as an extension to most other development methods, such
as the Rational Unified Process.
• The Rational Unified Process has several steps that result in the high-level design of an
architecture but then proceeds to detailed design and implementation.
• Incorporating ADD into it involves modifying the steps dealing with the high-level design
of the architecture and then following the process as described by Rational.
• ADD is an approach to defining a software architecture that bases the decomposition
process on the quality attributes the software has to fulfill. It is a recursive decomposition
process where, at each stage, tactics and architectural patterns are chosen to satisfy a set of
quality scenarios and the functionality is allocated to instantiate the module types provided
by the pattern.
• ADD is positioned in the life cycle after requirements analysis and, as we have said, can
begin when the architectural drivers are known with some confidence.
• The output of ADD is the first several levels of a module decomposition view of
architecture and other views as appropriate
• Not all details of the views result from an application of ADD; the system is described as a
set of containers for functionality and the interactions among them.
 • This is the first articulation of architecture during the design process and is therefore
necessarily coarse grained.
• Nevertheless, it is critical for achieving the desired qualities, and it provides a framework
for achieving the functionality.
• The difference between an architecture resulting from ADD and one ready for
implementation rests in the more detailed design decisions that need to be made.
• These could be, for example, the decision to use specific object-oriented design patterns or
a specific piece of middleware that brings with it many architectural constraints. The
architecture designed by ADD may have intentionally deferred this decision to be more
flexible.

1. Documenting software architectures: Documenting the architecture is the crowning step to

crafting it. Even a perfect architecture is useless if no one understands it or (perhaps worse) if key
stakeholders misunderstand it. If you go to the trouble of creating a strong architecture, you must
describe it in sufficient detail, without ambiguity, and organized in such a way that others can
quickly find needed information. Otherwise, your effort will have been wasted because the
architecture will be unusable.

This principle is useful because it breaks the problem of architecture documentation into more
tractable parts, which provide the structure for the remainder of this chapter:
• Choosing the relevant views
• Documenting a view
• Documenting information that applies to more than one view
Software architecture views are divided views into these three groups: module, component-and-
connector (C&C), and allocation. This three-way categorization reflects the fact that architects
need to think about their software in at least three ways at once:
• How it is structured as a set of implementation units
• How it is structured as a set of elements that have runtime behavior and interactions
• How it relates to non-software structures in its environment
There is no industry-standard template for documenting a view, but the seven-part standard
organization that we suggest in this section has worked well in practice.
1. Primary presentation
2. Element catalog
3. Context diagram
4. Variability guide
5. Architecture background
6. Glossary of terms
7. Other information
Reconstructing Software Architecture:
Architecture reconstruction has been used in a variety of projects ranging from MRI scanners to
public telephone switches and from helicopter guidance systems to classified NASA systems. It has
been used
• To redocument architectures for physics simulation systems.
• To understand architectural dependencies in embedded control software for mining
machinery.
• To evaluate the conformance of a satellite ground system's implementation to its reference
architecture.
• To understand different systems in the automotive industry.
Reconstruction Activities
Software architecture reconstruction comprises the following activities, carried out iteratively:
• Information extraction. The purpose of this activity is to extract information from various
sources.
• Database construction. Database construction involves converting this information into a
standard form such as the Rigi Standard Form (a tuple-based data format in the form of
relationship
<entity1><entity2>) and an SQL-based database format from which the database is created.
• View fusion. View fusion combines information in the database to produce a coherent view of
the architecture.
• Reconstruction. The reconstruction activity is where the main work of building abstractions
and various representations of the data to generate an architecture representation takes place.

Architecture reconstruction activities.