CW 8591-SOFTWARE ARCHITECTURE

UNIT -1

Envisioning Architecture:
1. Where Do Architectures Come From?
Architecture is the result of a set of business and technical decisions. There are many influences
at work in its design, and the realization of these influences will change depending on the
environment in which the architecture is required to perform.
An architect designing a system for which the real-time deadlines are believed to be tight will
make one set of design choices; the same architect, designing a similar system in which the
deadlines can be easily satisfied, will make different choices.
1. What is Software Architecture?
Software architecture is the set of design decisions which, if made incorrectly, may cause your project
to be cancelled. —
1. Architecture will inhibit or enable a system’s driving quality attributes.
2. The decisions made in an architecture allow you to reason about and manage change as the system
evolves.
3. The analysis of an architecture enables early prediction of a system’s qualities.
4. A documented architecture enhances communication among stakeholders.
5. The architecture is a carrier of the earliest and hence most fundamental, hardest-to-change design
decisions.
6. An architecture defines a set of constraints on subsequent implementation.
7. The architecture dictates the structure of an organization, or vice versa.
8. An architecture can provide the basis for evolutionary prototyping.
9. An architecture is the key artifact that allows the architect and project manager to reason about cost
and schedule.
10. An architecture can be created as a transferable, reusable model that forms the heart of a product
line.
11. Architecture-based development focuses attention on the assembly of components, rather than
simply on their creation.
12. By restricting design alternatives, architecture channels the creativity of developers, reducing
design and system complexity.
13. An architecture can be the foundation for training a new team member.

Definition: Architecture Business Cycle (ABC):

“Software architecture is a result of technical, business, and social influences. Its existence in
turn affects the technical, business, and social environments that subsequently influence future
architectures. We call this cycle of influences, from the environment to the architecture and back to the
environment, the Architecture Business Cycle (ABC).”
Three things required for ABC are as follows:
i. Case studies of successful architectures crafted to satisfy demanding requirements, so as to help set the
technical playing field of the day.
ii. Methods to assess an architecture before any system is built from it, so as to mitigate the risks associated
with launching unprecedented designs.
III.Techniques for incremental architecture-based development, so as to uncover design flaws before it is too
late to correct them

ARCHITECTURES ARE INFLUENCED BY SYSTEM STAKEHOLDERS

Many people and organizations are interested in the construction of a software system. We call
these stakeholders: The customer, the end users, the developers, the project manager, the
maintainers, and even those who market the system are a few examples. Stakeholders have
different concerns that they wish the system to guarantee or optimize, including things as diverse
as providing a certain behavior at runtime, performing well on a particular piece of hardware,
being easy to customize, achieving short time to market or low cost of development, gainfully
employing programmers who have a particular specialty, or providing a broad range of functions.
Figure.1 shows the architect receiving helpful stakeholder "suggestions."

Figure 1.Influence of stakeholders on the architect

ARCHITECTURES ARE INFLUENCED BY THE DEVELOPING ORGANIZATION

In addition to the organizational goals expressed through requirements, architecture is influenced
by the structure or nature of the development organization. For example, if the organization has
an abundance of idle programmers skilled in client-server communications, then client-server
architecture might be the approach supported by management. If not, it may well be rejected.
Staff skills are one additional influence, but so are the development schedule and budget.

There are three classes of influence that come from the developing organization: immediate
business, long-term business, and organizational structure.
ARCHITECTURES ARE INFLUENCED BY THE BACKGROUND AND EXPERIENCE
OF THE ARCHITECTS
If the architects for a system have had good results using a particular architectural approach, such
as distributed objects or implicit invocation, chances are that they will try that same approach on
a new development effort. Conversely, if their prior experience with this approach was
disastrous, the architects may be reluctant to try it again. Architectural choices may also come
from an architect's education and training, exposure to successful architectural patterns, or
exposure to systems that have worked particularly poorly or particularly well. The architects may
also wish to experiment with an architectural pattern or technique learned from a book (such as
this one) or a course.

ARCHITECTURES ARE INFLUENCED BY THE TECHNICAL ENVIRONMENT

A special case of the architect's background and experience is reflected by the technical
environment. Theenvironment that is current when architecture is designed will influence that
architecture. It might include standard industry practices or software engineering techniques
prevalent in the architect's professional community. It is a brave architect who, in today's
environment, does not at least consider a Web-based, object-oriented, middleware-supported
design for an information system.

RAMIFICATIONS OF INFLUENCES ON ARCHITECTURE

Influences on architecture come from a wide variety of sources. Some are only implied, while
others are explicitly in conflict. Almost never are the properties required by the business and
organizational goals consciously understood, let alone fully articulated. Indeed, even customer
requirements are seldom documented completely, which means that the inevitable conflict
among different stakeholders' goals has not been resolved.

A business manages this cycle to handle growth, to expand its enterprise area, and to take
advantage of previous investments in architecture and system building. Figure 2 shows the
feedback loops. Some of thefeedback comes from the architecture itself, and some comes from
the system built from it. The architecture affects the structure of the developing organization. An
architecture prescribes a structure for a system; as we will see, it particularly prescribes the units
of software that must be implemented (or otherwise obtained) and integrated to form the system.
These units are the basis for the development project's structure. Teams are formed for individual
software units; and the development, test, andintegration activities all revolve around the units.
Likewise, schedules and budgets allocate resources in chunks corresponding to the units. If a
company becomes adept at building families of similar systems, it will tend to invest in each
team by nurturing each area of expertise. Teams become embedded in the organization's
structure. This is feedback from the architecture to the developing organization.
 Figure 2. The Architecture Business Cycle

1.1 Software Processes and the Architecture Business Cycle

Software process is the term given to the organization, reutilization, and management of software
development activities. What activities are involved in creating software architecture, using that
architecture to realize a design, and then implementing or managing the evolution of a target
system or application? These activities include the following:

 Creating the business case for the system

 Understanding the requirements
 Creating or selecting the architecture
 Documenting and communicating the architecture
 Analyzing or evaluating the architecture
 Implementing the system based on the architecture
 Ensuring that the implementation conforms to the architecture

ARCHITECTURE ACTIVITIES
As indicated in the structure of the ABC, architecture activities have comprehensive feedback
relationships with each other. We will briefly introduce each activity in the following
subsections. Creating the Business Case for the System

1. Creating a business case: is broader than simply assessing the market need for a system. It is
an important step in creating and constraining any future requirements. How much should the
product cost? What is its targeted market? What is its targeted time to market? These are all
questions that must involvethe system's architects.
2. Understanding the Requirements: There are a variety of techniques for eliciting
requirements from the stakeholders. For example, object-oriented analysis uses scenarios, or "use
cases" to embody requirements. Safety-critical systems use more rigorous approaches, such as
finite-state- machine models for formal specification languages.
3. Communicating the Architecture
For the architecture to be effective as the backbone of the project's design, it must be
communicated clearly and unambiguously to all of the stakeholders. Developers must understand
the work assignments itrequires of them, testers must understand the task structure it imposes on
them, management must understand the scheduling implications it suggests, and so forth. Toward
 this end, the architecture's documentation should be informative, unambiguous, and readable by
many people with varied backgrounds.
3. Communicating the Architecture :

For the architecture to be effective as the backbone of the project's design, it must be communicated
clearly and unambiguously to all of the stakeholders. Developers must understand the work assignments
it requires of them, testers must understand the task structure it imposes on them, management must
understand the scheduling implications it suggests, and so forth. Toward this end, the architecture's
documentation should be informative, unambiguous, and readable by many people with varied
backgrounds.

4. Analyzing or Evaluating the Architecture :

In any design process there will be multiple candidate designs considered. Some will be rejected
immediately. Others will contend for primacy. Choosing among these competing designs in a rational
way is one of the architect's greatest challenges.

Evaluating an architecture for the qualities that it supports is essential to ensuring that the system
constructed from that architecture satisfies its stakeholders' needs. Becoming more widespread are
analysis techniques to evaluate the quality attributes that an architecture imparts to a system. Scenario-
based techniques provide one of the most general and effective approaches for evaluating an architecture.
The most mature methodological approach is found in the Architecture Tradeoff Analysis Method
(ATAM)

5. Implementing Based on the Architecture :

This activity is concerned with keeping the developers faithful to the structures and interaction protocols
constrained by the architecture. Having an explicit and well- communicated architecture is the first step
toward ensuring architectural conformance. Having an environment or infrastructure that actively assists
developers in creating and maintaining the architecture (as opposed to just the code) is better.

6. Ensuring Conformance to an Architecture :

Finally, when an architecture is created and used, it goes into a maintenance phase. Constant vigilance is
required to ensure that the actual architecture and its representation remain faithful to each other during
this phase.

What Makes a 'Good' Architecture?

If it is true that, given the same technical requirements for a system, two different architects in
different organizations will produce different architectures, how can we determine if either one
of them is the right one? We divide our observations into two clusters: process recommendations
and product (or structural) recommendations. Our process recommendations are as follows:
  The architecture should be the product of a single architect or a small group of
architects with an identified leader. The architect (or architecture team) should have the
functional requirements for the system and an articulated, prioritized list of quality
attributes (such as security or modifiability) that the architecture is expected to satisfy.
 The architecture should be well documented, with at least one static view and one
dynamic view, using an agreed-on notation that all stakeholders can understand with a
minimum of effort.
 The architecture should be circulated to the system's stakeholders, who should be
actively involved in its review.
 The architecture should be analyzed for applicable quantitative measures (such as
maximum throughput) and formally evaluated for quality attributes before it is too late
to make changes to it.
 The architecture should lend itself to incremental implementation via the creation of a
"skeletal" system in which the communication paths are exercised but which at first
has minimal functionality.

Architectural patterns, Reference models and Reference architectures

An architectural pattern is a description of element and relation types together with a set of
constraints on how they may be used. A pattern can be thought of as a set of constraints on
architecture? On the element types and their patterns of interaction? And these constraints define
a set or family of architectures that satisfy them. For example, client-server is a common
architectural pattern. Client and server are two element types, and their coordination is described
in terms of the protocol that the server uses to communicate with each of its clients. Use of the
term client-server implies only that multiple clients exist; the clients themselves are not
identified, and there is no discussion of what functionality, other than implementation of the
protocols, has been assigned to any of the clients or to the server.

A reference model is a division of functionality together with data flow between the pieces. A
referencemodel is a standard decomposition of a known problem into parts that cooperatively
solve the problem.

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.
Whereas 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 4.

Figure 4: The relationships of design elements

ROLE OF SOFTWARE ARCHITECT:
1. Contribute to the business case for the system 2. Understand the architecturally significant requirements 3.
Design or select the architecture 4. Document, communicate, and represent the architecture 5. Analyze or
evaluate the architecture 6. Oversee/contribute to system construction based on the architecture 7. Ensure
the implementation conforms to the architecture – validate
 The software architect creates a vision  Keeps up with innovations and technologies 
Understands global requirements and constraints (business and technical)  Creates a vision
(global view) of the system  Communicates the vision effectively  Provides requirements and
inputs to the system architect (if separate role)
 The software architect is the key technical consultant  Organizes the development team around
the architecture design  Manages dependencies  Reviews and negotiates requirements 
Assesses technical capabilities of staff  Motivates the team  Recommends technology, training,
tools  Tracks the quality of the design  Ensures architecture meets its design goals
 The software architect makes decisions  Leads the design team  Makes early design decisions
(key global ones)  Knows when to end discussion and make a decision  Identifies and manages
risk
 The software architect coaches  Establishes dialog with each team member  Teaches the team
the architecture design and gets their buy-in  Listens to feedback  Knows when to yield to
design changes  Knows when to let others take over detailed design
 The software architect coordinates  Coordinates activities of tasks that influence or are influenced
by the architecture  Maintains integrity of the design  Ensures that the architecture is followed.
 The software architect implements  Considers the design implications of introducing a new
technology  May look at low-level details to validate initial concepts  May prototype to explore
and evaluate design decisions  May implement a thin vertical slice to minimize implementation
risk  May implement components as an implementation model for developers
 The software architect advocates  Advocates investment in software architecture  Works to
incorporate software architecture into the software process  Continues to assess and advocate
new software architecture technologies  Advocates architecture reuse
4. Architectural Context on structures:
1. Technical - technical role in the system or systems of which it’s a part

2. Project life cycle - relationship to the other phases of a software development life cycle

3. Business - affect on an organization’s business environment

4. Professional - role of a software architect in an organization or development project

4.1. Technical context:

1.1Architectures Inhibit or Enable the Achievement of Quality Attributes

If you care about a system’s availability, you have to be concerned with how components take over for each
other in the event of a failure, and how the system responds to a fault. ■ If you care about usability, you have
to be concerned about isolating the details of the user interface and those elements responsible for the user
experience from the rest of the system, so that those things can be tailored and improved over time. ■ If you
care about the testability of your system, you have to be concerned about the testability of individual elements,
which means making their state observable and controllable, plus understanding the emergent behavior of the
elements working together. ■ If you care about the safety of your system, you have to be concerned about the
behavioral envelope of the elements and the emergent behavior of the elements working in concert. ■ If you
care about interoperability between your system and another, you have to be concerned about which elements
are responsible for external interactions so that you can control those interactions.
4.2. PROJECT LIFE CYCLE CONTEXT:

These activities include: 1. Making a business case for the system

2. Understanding the architecturally significant requirements
3. Creating or selecting the architecture
4. Documenting and communicating the architecture
5. Analyzing or evaluating the architecture
6. Implementing and testing the system based on the architecture
7. Ensuring that the implementation conforms to the architecture.
4.3. BUSINESS CONTEXT:
Systems are created to satisfy the business goals of one or more organizations. Development organizations
want to make a profit, or capture market, or stay in business, or help their customers do their jobs better, or
keep their staff gainfully employed, or make their stockholders happy, or a little bit of each. Customers have
their own goals for acquiring a system, usually involving some aspect of making their lives easier or more
productive. Other organizations involved in a project’s life cycle, such as subcontractors or government
regulatory agencies, have their own goals dealing with the system. Architects need to understand who the
vested organizations are and what their goals are. Many of these goals will have a profound influence on the
architecture.
Architectures and the Development Organization
The organizational structure can shape the software architecture, and vice versa. Organizations are often
organized around technology and application concepts: a database group, a networking group, a business rules
team, a user-interface group. So the explicit identification of a distinct subsystem in the architecture will
frequently lead to the creation of a group with the name of the subsystem. Furthermore, if the user-interface
team frequently needs to communicate with the business rules team, these teams will need to either be co-
located or they will need some regular means of communicating and coordinating.
4.4 PROFESSIONAL CONTEXT
Architects need to explain to one stakeholder or another the chosen priorities of different properties, and why
particular stakeholders are not having all of their expectations fulfilled. To be an effective architect, then, you
will need diplomatic, negotiation, and communication skills.
Stakeholders
A stakeholder is anyone who has a stake in the success ofthe system: the customer, the end users, the
developers, the project manager, themaintainers, and even those who market the system.
Influence of stakeholders on the architect
5. ARCHITECTURAL STRUCTURES :
Architectural structures can by and large be divided into three groups, depending on the broad
nature of the elements they show.

Module structures: Here the elements are modules, which are units of implementation.
Modules represent a code-based way of considering the system. They are assigned areas of
functional responsibility. There is less emphasis on how the resulting software manifests itself at
runtime.

Component-and-connector structures: Here the elements are runtime components (which

are the principal units of computation) and connectors (which are the communication vehicles
among components). Component-and-connector structures help answer questions such as what
are the major executing components and how do they interact? What are the major shared data
stores?
 Allocation structures: Allocation structures show the relationship between the software
elements and the elements in one or more external environments in which the software is created
and executed. They answer questions such as what processor does each software element execute
on? These three structures correspond to the three broad types of decision that architectural
design involves:

 How is the system to be structured as a set of code units (modules)?

 How is the system to be structured as a set of elements that have
runtime behavior(components) and interactions (connectors)?
 How is the system to relate to non-software structures in its environment (i.e.,
CPUs, filesystems, networks, development teams, etc.)?

SOFTWARE STRUCTURES
Some of the most common and useful software structures are shown in Figure 5. These are
described inthe following sections.
Figure 5: Common software architecture structures

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

Decomposition sub module of
" relation, showing how larger modules are decomposed into
smallerones 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 controlled
Layered in a
particular way, a system of layers emerges, in which
a layer is acoherent set of related functionality.
The module units in this structure are called classes. The
Class relation is"inherits-from" or "is-an-instance-of."
If the system is built as a group of cooperating clients and
Client-server servers, thisis a good component-and-connector structure to
Componen illuminate.
t-and- This component-and-connector structure allows the architect to
Concurrency determine opportunities for parallelism and the locations
Connector where resource contention may occur.
Like all component-and-connector structures, this one is
Process orthogonal tothe module-based structures and deals with the

Prepared by Manjula.P,Asst.Professor, CSBS,PEC

 dynamic aspects of a

running system.
Shared data This structure comprises components and connectors that
create, store, and access persistent data.
Work This structure assigns responsibility for implementing and
assignment integrating the modules to the appropriate development
teams.
Deployment The deployment structure shows how software is assigned to
hardware-processing and communication elements.
This structure shows how software elements (usually
Implementation
modules) are
mapped to the file structure(s) in the system's development,
integration, or configuration control environments.
6. ARCHITECTURAL PATTERNS:
"A pattern for software architecture describes a particular recurring design problem that arises in
specific design contexts and presents a well-proven generic scheme for its solution. The solution scheme
is specified by describing its constituent components, their responsibilities and relationships, and the
ways in which theycollaborate."
An architectural pattern is determined by:

 A set of element types (such as a data repository or a component that computes

a mathematicalfunction).
 A topological layout of the elements indicating their interrelation-ships.
 A set of semantic constraints
 A set of interaction mechanisms

In general, patterns have the following characteristics:

A pattern describes a solution to a recurring problem that arises in specific design

situations. Patterns are not invented; they are distilled from practical experience.
Patterns describe a group of components (e.g., classes or objects), how the components interact,
and the responsibilities of each component. That is, they are higher level abstractions than classes
or objects.
Patterns provide a vocabulary for communication among designers. The choice of a name for a
pattern is veryimportant.
Patterns help document the architectural vision of a design. If the vision is clearly understood, it
will less likely be violated when the system is modified.
Patterns provide a conceptual skeleton for a solution to a design problem and, hence, encourage
the construction of software with well-defined properties

Architectural patterns
"An architectural pattern expresses a fundamental structural organization schema for software
 systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes
rules and guidelines for organizing the relationships between them."
MODULE PATTERN:
1. LayeredPattern: :
As the name suggests, components(code) in this pattern are separated into layers of subtasks and they are
arranged one above another.
• Each layer has unique tasks to do and all the layers are independent of one another. Since each layer
is independent, one can modify the code inside a layer without affecting others.
• 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. Component-and-Connector Patterns

MVC pattern :

Model–View–Controller (MVC) is a software architecture currently considered an architectural pattern

used in software engineering. The pattern isolates "domain logic" (the application logic for the user)
from input and presentation (GUI), permitting independent development, testing and maintenance
ofeach.

The Model-View-Controller pattern (MVC) divides an interactive application into three components.
The model contains the core functionality and data. Views display information to the user. Controllers
handle user input. Views and controllers together comprise the user interface. A change-propagation
mechanism ensures consistency between the user interface and the model.

The model is used to manage information and notify observers when that information changes. The
model is the domain-specific representation of the data upon which the application operates. Domain
logic adds meaning to raw data (for example, calculating whether today is the user's birthday, or the
totals, taxes, and shipping charges for shopping cart items). When a model changes its state, it notifies its
associated views so they can be refreshed.
 The controller receives input and initiates a response by making calls on model objects. A controller
accepts input from the user and instructs the model and viewport to perform actions based on that input.

SERVICE ORIENTED ARCHITECTURE PATTERN

Components:
■■ Service providers, which provide one or more servicesthrough published interfaces. Concerns are often
tied tothe chosen implementation technology, and include performance,authorization constraints, availability,
and cost. Insome cases these properties are specified in a service-levelagreement.
■■ Service consumers, which invoke services directly or throughan intermediary.■■ Service providers may
also be service consumers.
■■ ESB, which is an intermediary element that can route andtransform messages between service providers
and consumers.
■■ Registry of services, which may be used by providers toregister their services and by consumers to
discover services
at runtime.
■■ Orchestration server, which coordinates the interactionsbetween service consumers and providers based
on
languages for business processes and workflows.
PUBLISH-SUBSCRIBE PATTERN:
Components publish and subscribe to events. When an event isannounced by a component, the connector
infrastructure dispatchesthe event to all registered subscribers. The publish-subscribe connector, which will
have announce and listen roles for components that wish to publish and subscribe to events.
The publish-subscribe pattern is used to send events and messages to an unknownset of recipients. Because
the set of event recipients is unknown to theevent producer, the correctness of the producer cannot, in general,
depend onthose recipients. Thus, new recipients can be added without modification to theproducers.

Typical examples of systems that employ the publish-subscribe pattern are the following:
1. Graphical user interfaces, in which a user’s low-level input actions are treated as events that are routed
to appropriate input handlers
2. MVC-based applications, in which view components are notified when the state of a model object
3. Enterprise resource planning (ERP) systems, which integrate many components, each of which is only
interested in a subset of system events
4. Extensible programming environments, in which tools are coordinated through events
5. Mailing lists, where a set of subscribers can register interest in specific topic

SHAREDDATAPATTERN
Shared-data (or repository) pattern. This pattern comprises components and connectors that create, store, and
access persistent data. The repository usually takes the form of a (commercial) database. The connectors are
protocols for managing the data, such as SQL.
Client-server pattern. The components are the clients and the servers, and the connectors are protocols and
messages they share among each other to carry out the system’s work.
PIPE AND FILTER PATTERN: A pipeline consist of a chain of processing elements arranged so that the
output of each element is the input of the next element. Conceptually, it should have a source to provide the
initial data. And then step by step the data will be passed through filters over the pipes. And each filter
supposes to transform the data provided and hand over the transformed data to the next filter through a pipe.
Finally transformed data is handed over the final destination called "Sink".
PEER –PEER PATTERN:
• Peer-to-Peer is a type of decentralized and distributed network architecture in which individual nodes
in the network (called "peers") act as both suppliers and consumers of resources, in contrast to the
centralized client–server model where client nodes request access to resources provided by central
servers.
• Problem Description
• Multiple systems need to share common information and applications along with the resource
demands. A peer-to-peer network is a distributed application architecture that partitions tasks or work
loads between peers. Peers are equally privileged participants in the application.
• Applicable Context
• The nodes in a peer-to-peer network need to operate as both "clients" and "servers"; they both provide
information and services and require information and services from other peers. This arrangement is
very useful for sharing large amounts of information, sharing resources, and sharing services.
• Pattern Constraints
• This pattern is not applicable if the application or the information cannot be distributed on multiple
servers. The scalability of the applications and information access needs to be examined and managed,
since this may be an issue if growth is expected, especially the numbers of peers that communicate
 simultaneously. Also, since the information and application is distributed on servers, IT security
becomes and important aspect of the solution.
• Pattern Solution
• Peers make a portion of their resources, such as processing power, disk storage or network bandwidth,
directly available to other network participants, without the need for central coordination. Peers are
both suppliers and consumers of resources, in contrast to the traditional client-server model in
which the resources are divided.
BROKER PATTERN:

3. ALLOCATION PATTERN

MAP REDUCE PATTERN

MapReduce is a software framework and programming model used for processing huge amounts of
data. MapReduce program work in two phases, namely, Map and Reduce. Map tasks deal with splitting and
mapping of data while Reduce tasks shuffle and reduce the data. The whole process goes through four phases
of execution namely, splitting, mapping, shuffling, and reducing.
MULTI-TIER PATTERN:
Multi-tier pattern, which describes how to distribute and allocate the components of a system in distinct
subsets of hardware and software, connected by some communication medium. This pattern specializes the
generic deployment (software-to-hardware allocation) structure.

ARCHITECTURAL STYLES:

An architectural Style is a specialization of element and relation types, together with a set of constraints on
how they can be used. On the other hand, an architectural Pattern expresses a fundamental structural
organization schema for software systems. It provides a set of predefined subsystems, specifies their
responsibilities, and includes rules and guidelines for organizing the relationships between them.
 The architectural styles that are used while designing the software as follows:

1. Data-centered architecture

 The data store in the file or database is occupying at the center of the architecture.
 Store data is access continuously by the other components like an update, delete, add, modify from the
data store.
 Data-centered architecture helps integrity.
 Pass data between clients using the blackboard mechanism.
 The processes are independently executed by the client components.

2. Data-flow architecture

 This architecture is applied when the input data is converted into a series of manipulative components
into output data.
 A pipe and filter pattern is a set of components called as filters.
 Filters are connected through pipes and transfer data from one component to the next component.
 The flow of data degenerates into a single line of transform then it is known as batch sequential.
3. Call and return architectures

This architecture style allows to achieve a program structure which is easy to modify.

Following are the sub styles exist in this category:

1. Main program or subprogram architecture

 The program is divided into smaller pieces hierarchically.

 The main program invokes many of program components in the hierarchy that program components are
divided into subprogram.
2. Remote procedure call architecture

 The main program or subprogram components are distributed in network of multiple computers.
 The main aim is to increase the performance.


4. Object-oriented architectures

 This architecture is the latest version of call-and-return architecture.

 It consist of the bundling of data and methods.
5. Layered architectures

 The different layers are defined in the architecture. It consists of outer and inner layer.
 The components of outer layer manage the user interface operations.
 Components execute the operating system interfacing at the inner layer.
 The inner layers are application layer, utility layer and the core layer.
 In many cases, It is possible that more than one pattern is suitable and the alternate architectural style can
be designed and evaluated.

6. EVENT-DRIVEN
An event-driven architecture uses events to trigger and communicate between decoupled services and is
common in modern applications built with microservices.
• Event-driven architectures have three key components: event producers, event routers, and event
consumers. A producer publishes an event to the router, which filters and pushes the events to
consumers. Producer services and consumer services are decoupled, which allows them to be
scaled, updated, and deployed independently.

ARCHITECTURAL VIEWS
• A view is a representation of an entire system from the perspective of a related set of concerns.
It is used to describe the system from the viewpoint of different stakeholders such as end-users,
developers, project managers, and testers.
• Architecture views are representations of the overall architecture that are meaningful to one or
more stakeholders in the system.

PROPERTIES OF MODULE VIEWS

• Name. A module’s name is, of course, the primary means to refer to it. A module’s name often
suggests something about its role in the system.
• Responsibilities. The responsibility property for a module is a way to identify its role in the
overall system and establishes an identity for it beyond the name.
• Visibility of interface(s). When a module has submodules, some interfaces of the submodules
are public and some may be private; that is, the interfaces are used only by the submodules within
the enclosing parent module.
• Mapping to source code units. This identifies the files that constitute the implementation of a
module. For example, a module Account, if implemented in Java, might have several files that
constitute its implementation: IAccount.java (an interface), AccountImpl.java (the implementation of
Account functionality), AccountBean.java (a class to hold the state of an account in memory),
• Test information. The module’s test plan, test cases, test scaffolding, and test data are important to
document.
• Management information. A manager may need information about the module’s predicted
schedule and budget.
• Revision history. Knowing the history of a module including authors and particular changes may
help when you perform maintenance activities
COMPONENT AND CONNECTOR VIEWS
• Module views are commonly mapped to component-and-connector views.
• Reliability. This property might be used to help determine overall system availability.
• Performance. This property can be used with others to determine system-wide properties such as
response times, throughput, and buffering needs.
• Resource requirements. This property can be used to determine whether a proposed
hardware configuration will be adequate.
• Functionality. This property can be used to reason about overall computation performed by a
system.
• Security. This property can be used to determine system security vulnerabilities.
QUALITY VIEWS
• A security view can show all of the architectural measures taken to provide security. It would show
the components that have some security role or responsibility, how those components
communicate, any data repositories for security information, and repositories that are of security
interest.
• A communications view might be especially helpful for systems that are globally dispersed and
heterogeneous. This view would show all of the component-to-component channels, the various
network channels, quality-of-service parameter values, and areas of concurrency.
• An exception or error-handling view could help illuminate and draw attention to error reporting and
resolution mechanisms. Such a view would show how components detect, report, and resolve faults
or errors. It would help identify the sources of errors and appropriate corrective actions for each.
Root- cause analysis in those cases could be facilitated by such a view.
• A reliability view would be one in which reliability mechanisms such as replication and
switchover are modeled. It would also depict timing issues and transaction integrity.
• A performance view would include those aspects of the architecture useful for inferring the
system’s performance. Such a view might show network traffic models, maximum latencies for
operations, and so forth.
•
Section 1: The Primary Presentation. The primary presentation shows the elements and relations of the
view. The primary presentation is most often graphical. It might be a diagram drawn in an informal notation
using a simple drawing tool. Occasionally the primary presentation will be textual, such as a table or a list.
If that text is presented according to certain stylistic rules, these rules should be stated or incorporated by
reference, as the analog to the graphical notation key.
Section 3: Context Diagram. The purpose of a context diagram is to depict the scope of a view. Here
“context” means an environment with which the part of the system interacts. Entities in the environment may
be humans, other computer systems, or physical objects, such as sensors or controlled devices.
Section 4: Variability Guide. A variability guide shows how to exercise any variation points that are a part of
the architecture shown in this view.
Section 5: Rationale. The goal of this section is to explain why the design is as it is and to provide a
convincing argument that it is sound. The choice of a pattern in this view should be justified here by
describing the architectural problem that the chosen pattern solves and the rationale for choosing it over
another.
DECENTRALISED ARCHITECTURE

• A decentralised system, on the other hand, is one in which complex behaviour emerges through
the work of lower level components operating on local information, not the instructions of any
commanding influence. This form of control is known as distributed control, or control in which
each component of the system is equally responsible for contributing to the global, complex
behaviour by acting on local information in the appropriate manner.
• The lower level components are implicitly aware of these appropriate responses through
mechanisms that are based on the component's interaction with the environment, including
other components in that environment.
• Decentralized simply means not centralized. The control, as opposed to with a single entity, lies
with the end users. BitTorrent a peer to peer network is an ideal example of this.
• A decentralized network is controlled by a cluster of domain controllers that share the network
load and provide redundancy if one server goes down.
• Decentralized systems just like the distributed architecture have no single points of failure.
Even if several nodes go down, the network as a whole is still up.
• There is no single entity control, so there is zero possibility of the network going down anytime
unless all the nodes go down simultaneously which is a rare possibility when we have systems
connected all over the globe.
• This kind of architecture is almost infinitely scalable, unlike a centralized system in which
scalability depends upon the resources of the organization in charge.

•
 Benefits of decentralization

Provides a trustless environment

In a decentralized blockchain network, no one has to know or trust anyone else. Each member in the network
has a copy of the exact same data in the form of a distributed ledger. If a member’s ledger is altered or
corrupted in any way, it will be rejected by the majority of the members in the network.

Improves data reconciliation

Companies often exchange data with their partners. This data, in turn, is typically transformed and stored in each
party’s data silos, only to resurface when it needs to be passed downstream. Each time the data is transformed, it
opens up opportunities for data loss or incorrect data to enter the workstream. By having a decentralized data store,
every entity has access to a real-time, shared view of the data.

Reduces points of weakness

Decentralization can reduce points of weakness in systems where there may be too much reliance on specific
actors. These weak points could lead to systemic failures, including failure to provide promised services or
inefficient service due to the exhaustion of resources, periodic outages, bottlenecks, lack of sufficient incentives
for good service, or corruption.

Optimizes resource distribution

Decentralization can also help optimize the distribution of resources so that promised services are provided with better
performance and consistency, as well as a reduced likelihood of catastrophic failure.