Experiment No – 1

1. Introduction to software architecture & common software architecture framework.

Objective:
To understand the concept of software architecture and explore common frameworks used in
software architecture.

Theory:

1. Software Architecture: Software architecture is the high-level structure of a software system,

defining the set of structures needed to reason about the system. It provides an abstraction to
understand the elements of the system, their interactions, and the guiding principles of the
design. Software architecture serves as a blueprint for the system and is critical for meeting
functional and non-functional requirements.

Key elements of software architecture include:

 Components: Independent units of a system, such as modules, classes, and functions.

 Connectors: Means of communication between components (e.g., function calls,
messages).
 Configurations: The organization and relationships between components and
connectors.

2. Common Software Architecture Frameworks:

 1. Layered (N-Tier) Architecture:

Organizes the system into layers, each with a specific responsibility, such as presentation,
business logic, and data access. It’s useful for modular, maintainable systems and is
common in enterprise applications.
 2. Client-Server Architecture:
Separates clients and servers, where the server provides resources, and the client accesses
them. This model is used in applications where multiple clients need to interact with a
centralized server.
 3. Microservices Architecture:
Breaks down a system into small, independent services that can be developed, deployed,
and scaled independently. Ideal for complex, scalable systems with loosely coupled
services.
 4. Event-Driven Architecture:
Based on the production, detection, consumption, and reaction to events, allowing
services to react to changes or triggers asynchronously. Common in real-time
applications.
 5. Service-Oriented Architecture (SOA):
A style that supports service interoperability and reusability, where services provide
 business functionality via interfaces and interact over a network. Suitable for enterprise-
level applications that require complex integration.

Conclusion: Software architecture is essential for designing scalable, maintainable systems.

Different architectural frameworks serve specific requirements, and selecting an appropriate
framework depends on factors like scalability, maintainability, and the complexity of the
system.
 Experiment No. 2
2. Pipes and filters architecture.

Objective:
To understand the Pipes and Filters architecture and its application in software systems.

Theory:

1. Pipes and Filters Architecture: The Pipes and Filters architecture is a design pattern
commonly used for data processing systems, where data flows through a sequence of processing
elements known as "filters," connected by "pipes." Each filter performs a specific operation on
the data and then passes the modified data to the next filter through a pipe.

This architecture is ideal for systems that require data to be processed in multiple steps and can
be represented as a chain of discrete processing elements.

Key Components:

 Filters: Independent modules that perform a single transformation or computation on the

data. Each filter is responsible for a specific operation, like data cleaning, transformation,
or aggregation.
 Pipes: Connectors between filters that pass data from one filter to the next in a
unidirectional flow. Pipes facilitate the sequential flow of data through the filters.

Characteristics of Pipes and Filters Architecture:

 Modularity: Each filter is a separate, independent component, making it easy to modify

or replace filters without affecting the entire system.
 Reusability: Filters can be reused across different pipelines as they perform a specific,
well-defined task.
 Flexibility: Filters can be added, removed, or rearranged in the pipeline to change or
extend the functionality of the system.

Applications:

 Data Processing Pipelines: Used in data analytics and ETL (Extract, Transform, Load)
processes where data goes through multiple transformations.
 Compiler Design: Common in compilers, where code goes through stages like lexical
analysis, syntax analysis, and code generation.
 Audio/Video Processing: Used in applications where multimedia data needs to be
filtered, compressed, or transformed.
Diagram: Pipes and Filters Architecture

Figure Description:
Draw a series of boxes connected by arrows in a sequential flow. Each box represents a filter,
with arrows (pipes) connecting them to indicate data flow. Label each filter with a hypothetical
operation, such as "Filter 1: Data Cleaning," "Filter 2: Data Transformation," and "Filter 3: Data
Aggregation." Show the data moving through each filter from left to right.

Conclusion: The Pipes and Filters architecture provides an efficient, modular approach to
handling sequential data processing tasks. It allows for flexibility and reusability, making it
suitable for systems requiring complex data transformations through a series of distinct
processing steps.
 Experiment No. 3
3. Architecture Tradeoff Analysis Method (ATAM).

Objective:
To understand the Architecture Tradeoff Analysis Method (ATAM) and how it evaluates and
improves software architecture by analyzing trade-offs among various quality attributes.

Theory:

1. Architecture Tradeoff Analysis Method (ATAM): The Architecture Tradeoff Analysis

Method (ATAM) is a structured process developed by the Software Engineering Institute (SEI)
to assess the consequences of architectural decisions in terms of quality attributes. ATAM helps
identify trade-offs and risks associated with architecture choices, allowing stakeholders to make
informed decisions to optimize the software architecture for desired quality attributes.

Key Steps in ATAM:

1. Establish Objectives: Define the goals and objectives of the architecture, focusing on
critical quality attributes such as performance, security, scalability, and modifiability.
2. Present Architecture: The architecture team presents the initial architecture to the
stakeholders, outlining major components, design decisions, and architectural patterns
used.
3. Identify Architectural Approaches: Discuss different architectural approaches used in
the system and how they influence quality attributes.
4. Identify Attribute-Specific Scenarios: Stakeholders create scenarios that reflect real-
world conditions or potential future use cases, such as "Handling 10,000 users
concurrently" for performance or "Updating a module with minimal downtime" for
modifiability.
5. Analyze Attribute Trade-offs: Evaluate each scenario in terms of how it affects the
quality attributes. This involves analyzing trade-offs; for example, enhancing security
may impact performance.
6. Identify Sensitivity Points, Trade-off Points, and Risks:
o Sensitivity Points: Architectural decisions that significantly affect one or more
quality attributes.
o Trade-off Points: Decisions that impact multiple quality attributes, requiring a
balance (e.g., performance vs. security).
o Risks: Potential weaknesses or architectural decisions that may not meet specific
quality attribute requirements.
7. Summarize and Document Results: Document the findings, including identified trade-
offs, risks, sensitivity points, and potential improvements. This helps guide future
development and informs stakeholders about critical decisions.

Advantages of ATAM:
  Helps identify strengths and weaknesses in architecture early in the development process.
 Promotes informed decision-making by highlighting trade-offs and risks.
 Engages stakeholders in architecture evaluation, ensuring alignment with business goals.

Applications: ATAM is widely used in enterprise software development, large-scale systems,

and projects where quality attributes (e.g., scalability, security) are critical and require careful
consideration.

Diagram: ATAM Process Flow

Figure Description:
Draw a flowchart with the following labeled steps in sequence: "Establish Objectives," "Present
Architecture," "Identify Architectural Approaches," "Identify Attribute-Specific Scenarios,"
"Analyze Attribute Trade-offs," "Identify Sensitivity and Trade-off Points," and "Summarize and
Document Results." Connect each step with arrows to indicate the process flow.

Conclusion: The Architecture Tradeoff Analysis Method (ATAM) provides a systematic way to
evaluate software architecture, identify risks, and make trade-offs among quality attributes. By
engaging stakeholders and analyzing scenarios, ATAM helps to ensure that architectural
decisions align with the project's quality goals, thereby improving the system's robustness and
performance.
 Experiment No. 4
4. Software Architecture Description Languages (ADLs).

Objective:
To understand Software Architecture Description Languages (ADLs) and their role in defining
and modeling software architectures.

Theory:

1. Software Architecture Description Languages (ADLs): Software Architecture Description

Languages (ADLs) are specialized languages used to formally describe the architecture of a
software system. ADLs provide a structured way to represent architectural components, their
interactions, configurations, and constraints. They help architects and developers visualize,
analyze, and document the architecture to ensure it aligns with system requirements.

Key Components of ADLs:

 Components: Represent individual elements or modules of the architecture (e.g.,

services, classes, functions).
 Connectors: Define the communication mechanisms or protocols that connect
components, such as messages, shared data, or events.
 Configurations: Specify the arrangement or structure of components and connectors
within the system.

Examples of ADLs:

1. ACME: A general-purpose ADL used for representing and analyzing architectures,

supporting various types of components and connectors.
2. Wright: Focuses on specifying the behavior of components and connectors using formal
specifications, ideal for complex systems requiring precise interaction definitions.
3. AADL (Architecture Analysis & Design Language): Commonly used in embedded
systems and real-time applications, emphasizing performance and safety-critical
requirements.
4. xADL: An XML-based ADL used for flexibility and interoperability, suitable for
dynamic and web-based systems.

Characteristics of ADLs:

 Formal Syntax and Semantics: ADLs use well-defined syntax and semantics to ensure
consistency and precision in architecture specifications.
 Analysis Support: Many ADLs include tools or frameworks that allow for architectural
analysis, such as performance, reliability, or scalability assessments.
  Documentation and Communication: ADLs provide a standardized format for
documenting architecture, making it easier for stakeholders to understand and
collaborate.

Applications of ADLs:

 Architecture Modeling: Used to represent the high-level structure and behavior of the
system, making it easier to understand and reason about.
 Consistency Checks: ADLs allow for validating architectural consistency, ensuring that
components and connectors are configured correctly.
 System Evolution and Maintenance: ADLs aid in managing changes to the architecture,
providing a blueprint for implementing updates without disrupting existing functionality.

Diagram: Example ADL Structure

Figure Description:
Draw a simple architecture diagram with labeled boxes representing components (e.g.,
"Component A," "Component B") connected by lines or arrows representing connectors (e.g.,
"Message Passing," "Event Trigger"). Below each component, add a brief description of its role.
This demonstrates how ADLs define relationships between components and connectors.

Conclusion: Software Architecture Description Languages (ADLs) are essential tools for
formally representing and analyzing software architectures. By offering precise notations and
support for architectural analysis, ADLs facilitate the design of complex systems and help ensure
that architectural decisions meet the system's functional and non-functional requirements.
 Experiment No. 5
5. Explain RMI and CORBA.

Objective:

1. RMI (Remote Method Invocation): To understand how RMI facilitates communication

between Java applications running on different machines or processes, allowing remote
method invocations as if they were local.
2. CORBA (Common Object Request Broker Architecture): To understand how
CORBA enables communication between distributed objects across different
programming languages and platforms.

Theory:

Remote Method Invocation (RMI):

Introduction: RMI is a Java-based mechanism that allows one Java program to invoke methods
on an object located in another Java virtual machine (JVM), either on the same machine or
across a network. It provides an object-oriented interface for distributed systems.

Key Concepts:

 Client-Server Architecture: In RMI, the client invokes methods on a server-side object

(remote object) through a proxy (stub).
 Serialization: Objects passed between client and server must implement the
Serializable interface to allow their data to be transmitted over the network.
 RMI Registry: The server registers the remote objects with the RMI registry, which
allows clients to look up the remote objects by name.
 Stub and Skeleton: The stub on the client side acts as a proxy to the remote object, and
the skeleton on the server side processes the request from the client.

Advantages of RMI:

 Simplifies the development of distributed applications.

 Automatically handles network communication and data marshaling.
 Provides easy integration with Java-based systems.

Common Object Request Broker Architecture (CORBA):

Introduction: CORBA is a platform-independent, language-independent architecture that

enables communication between software objects in distributed systems, regardless of the
programming languages used to create them. It uses an Object Request Broker (ORB) to handle
communication between clients and servers.

Key Concepts:

 Object Request Broker (ORB): The ORB is responsible for facilitating communication
between client and server applications by forwarding requests to the appropriate remote
objects.
 Interface Definition Language (IDL): CORBA uses IDL to define the interface for
objects, ensuring that different systems (written in different languages) can communicate
with each other.
 Interoperability: CORBA allows distributed objects written in various programming
languages (such as Java, C++, and Python) to interact across different platforms.
 Services: CORBA offers several services like naming, transaction, and security
management, which can be used by distributed applications.

Advantages of CORBA:

 Supports distributed systems in a heterogeneous environment.

 Platform and language-independent.
 Provides built-in support for various services to aid in the development of complex
applications.

Comparison Between RMI and CORBA:

Aspect RMI CORBA

Java-specific (only works in the
Platform Platform-independent (cross-platform)
JVM)
Languages Java only Multiple languages (Java, C++, Python, etc.)
Client-server communication Supports client-server communication across
Communication
within Java languages and platforms
Easier to implement in Java-
Ease of Use More complex, requires IDL and ORB setup
based systems
Faster for Java-to-Java May incur additional overhead due to
Performance
communication language mapping
Typically used in Java-based Used in heterogeneous distributed systems
Use Case
distributed applications across multiple platforms and languages
Conclusion:

 RMI is suitable for Java-based applications that require remote method invocation across
a network, leveraging Java's object-oriented capabilities and providing simplicity for Java
developers.
 CORBA, on the other hand, is a more complex, but powerful, framework for creating
distributed systems that require communication between objects in different
programming languages and across multiple platforms. CORBA provides greater
flexibility but demands more effort to implement and manage.
 Experiment No. 6
6. Cost Benefit Analysis Method (CBAM).

Objective:

To understand the Cost Benefit Analysis Method (CBAM) and its application in software
architecture to evaluate the trade-offs between costs and benefits when choosing architectural
decisions.

Theory:

Introduction to CBAM:

The Cost Benefit Analysis Method (CBAM) is a decision-making technique used to evaluate
and compare the costs and benefits associated with different architectural decisions. CBAM
helps in selecting the most appropriate architecture for a system by quantifying the trade-offs and
aligning architectural decisions with the business goals. It focuses on tangible and intangible
factors, such as costs, benefits, risks, and uncertainties.

Key Concepts:

1. Cost: This includes the direct and indirect costs involved in implementing and
maintaining a particular architectural decision. Costs could involve development, testing,
integration, and operational expenses.
2. Benefit: Benefits are the improvements or value gained by implementing the architecture.
These could include performance gains, scalability, maintainability, and customer
satisfaction.
3. Risks: Risks refer to the uncertainties in implementing a certain architecture that could
affect costs or benefits. This could involve technical challenges, resource limitations, or
external factors like market conditions.
4. Uncertainty: In CBAM, uncertainty refers to the unknown factors or variables that might
impact the cost-benefit outcome, such as emerging technologies or evolving market
demands.
5. Time Horizon: The analysis considers both short-term and long-term costs and benefits.
Some benefits may take time to realize, and some costs may be incurred over an extended
period.
Process of Cost Benefit Analysis Method (CBAM):

1. Identify Architectural Scenarios:

The first step is to define multiple architectural scenarios or options. These scenarios
represent different ways of designing the system to meet the specified requirements.
2. Quantify Costs and Benefits:
For each scenario, identify and quantify the costs and benefits. This might involve:
o Estimating development costs (e.g., resources, time, tools).
o Estimating benefits in terms of system performance, scalability, and user
satisfaction.
3. Risk Assessment:
Assess the risks associated with each scenario, considering technical, operational, and
business uncertainties. This helps in understanding how each scenario might perform
under different conditions.
4. Estimate the Time Horizon:
CBAM typically uses a time horizon, considering both short-term and long-term costs
and benefits. A long-term evaluation allows understanding of how the system will evolve
and scale over time.
5. Prioritize Decisions:
CBAM helps prioritize architectural decisions based on the balance between costs,
benefits, and risks. Decision-makers can then focus on the most beneficial architecture
with the least risk and cost.
6. Select the Best Architecture:
After comparing the different scenarios, the architecture with the best overall balance of
cost, benefit, and risk is selected.

Steps in Applying CBAM:

1. Identify Key Scenarios: Define a set of architectural options or scenarios to be

evaluated.
2. Estimate Costs and Benefits: For each scenario, estimate the costs and benefits in
quantitative terms (e.g., cost in dollars, time, or effort, and benefits in terms of
performance, scalability, or ease of maintenance).
3. Risk and Uncertainty Analysis: Evaluate the risks and uncertainties associated with
each architectural decision and its impact on the overall system.
4. Assessment and Decision Making: Based on the costs, benefits, and risks, make an
informed decision regarding the best architectural choice.
Advantages of CBAM:

1. Quantitative Decision Making: CBAM allows for a more objective decision-making

process by quantifying both costs and benefits.
2. Risk Management: By considering risks and uncertainties, CBAM helps in making
informed decisions that account for potential challenges and unforeseen outcomes.
3. Long-Term View: CBAM encourages long-term thinking, ensuring that architectural
decisions consider both immediate and future needs.
4. Better Resource Allocation: Helps allocate resources effectively by identifying the most
cost-effective architecture with the greatest potential benefit.

Limitations of CBAM:

1. Complexity: It can be time-consuming and complex to accurately estimate the costs,

benefits, and risks for each architectural scenario.
2. Subjectivity: While CBAM aims to be objective, some elements (e.g., benefits related to
user experience or innovation) may still be subjective.
3. Requires Accurate Data: To perform an effective CBAM, accurate data regarding costs,
benefits, and risks is essential, which might not always be available.

Conclusion:

Cost Benefit Analysis Method (CBAM) is a crucial technique for evaluating and selecting
software architectures by comparing the costs and benefits associated with different architectural
decisions. By integrating risk assessment and long-term planning, CBAM ensures that the chosen
architecture aligns with both technical and business goals. While it provides a structured
approach for decision-making, it requires careful data estimation and risk analysis to be
effective.
 Experiment No. 7
7. Role of UML in software architecture.

Objective:

To understand the role of Unified Modeling Language (UML) in software architecture and how
it aids in the visualization, specification, and documentation of software architecture.

Theory:

Introduction to UML:

Unified Modeling Language (UML) is a standardized modeling language used to represent the
design of a system. It provides a set of graphical notations and diagrams that help in visualizing,
specifying, constructing, and documenting the structure and behavior of software systems.

In the context of software architecture, UML plays a vital role by providing a means to
represent the high-level structure of the system, its components, and their interactions. UML
helps architects and developers understand complex systems, communicate architectural
decisions, and document the system's design for future reference.

Key Concepts of UML in Software Architecture:

1. Structure Diagrams:
These diagrams represent the static aspects of the system, focusing on the components
and their relationships.
o Class Diagram: Shows the system’s classes, their attributes, methods, and the
relationships between them (e.g., inheritance, association).
o Component Diagram: Depicts the high-level components or modules of the
system and their interactions.
o Deployment Diagram: Represents the physical deployment of the system,
including hardware nodes and the relationships between them.
2. Behavior Diagrams:
These diagrams represent the dynamic aspects of the system, illustrating how the system
behaves over time.
o Use Case Diagram: Describes the system’s functional requirements by showing
the interactions between users (actors) and the system’s use cases.
o Sequence Diagram: Shows how objects interact in a particular scenario,
including the messages passed between them.
o Activity Diagram: Represents workflows or the flow of control within the
system.
 3. Interaction Diagrams:
UML interaction diagrams, such as Sequence Diagrams and Communication
Diagrams, help in understanding the sequence of messages or interactions between
system components.
4. State Diagrams:
Depict the states of a system or component and the transitions between them, providing
insights into the system’s behavior under different conditions.

Role of UML in Software Architecture:

1. Visualization:
UML provides a graphical representation of the architecture, allowing architects to
visualize the system’s structure and behavior. This makes it easier to understand the
system’s components and their relationships, especially in complex architectures.
2. Specification:
UML helps in specifying the system's components, their interactions, and how they fit
together to achieve the desired functionality. It provides a clear, detailed blueprint for
developers, stakeholders, and designers.
3. Documentation:
UML diagrams serve as documentation for the software architecture, helping to
communicate the design to various stakeholders. This documentation can be used for
future reference, maintenance, and knowledge transfer.
4. Communication:
UML enables clear and standardized communication among team members, including
software architects, developers, testers, and clients. It provides a common language for
discussing system design and making architectural decisions.
5. Analysis and Design:
UML aids in both the analysis and design phases of software development. During
analysis, UML diagrams like use case diagrams help define functional requirements. In
the design phase, class, component, and deployment diagrams are used to design the
system architecture.
6. Traceability and Consistency:
UML ensures that the architecture design is traceable, with clear links between different
design elements. This helps ensure consistency in the system’s architecture as
development progresses.
7. Evolution of the System:
UML allows architects to model potential future states of the system, making it easier to
modify or extend the system architecture as new requirements emerge. This is especially
important in agile and iterative development processes.

Benefits of Using UML in Software Architecture:

 1. Standardization: UML provides a standardized approach to system modeling, ensuring
consistency across different projects and teams.
2. Clear Understanding: Diagrams help stakeholders understand the system at various
levels of abstraction (from high-level architecture to detailed component interactions).
3. Documentation for Maintenance: UML diagrams act as essential documentation for
maintaining the system in the long term, especially when new team members join the
project.
4. Easy Integration: UML diagrams facilitate the integration of various subsystems or
components by clearly defining their interfaces and interactions.
5. Early Detection of Issues: By visualizing the architecture before implementation, UML
helps identify potential design flaws early in the development process.

Conclusion:

UML plays a critical role in software architecture by providing a standardized way to represent,
communicate, and document the structure and behavior of complex systems. It helps in
visualizing system components, defining their relationships, and specifying system behavior,
which leads to better understanding, decision-making, and maintenance of software systems.
UML fosters clear communication among stakeholders, reduces the risk of misunderstandings,
and provides a strong foundation for both design and development processes.