lOMoARcPSD|53378081

Software Architecture [ CS-701 ] - Notes - Unit - IV

computer science (Bansal Institute of Science and Technology)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by SUMAN VERMA (suman.vermacse2022@[Link])
 lOMoARcPSD|53378081

Unit - IV

Software architecture analysis and design involves a systematic approach to

understanding and defining the structure and behavior of a software system. It
encompasses both the requirements for architecture and the lifecycle view of
architecture design and analysis methods. Here’s an overview of these concepts:

Requirements for Architecture

1. Functional Requirements:
o Define what the system should do. These requirements outline the
specific functionalities that the architecture must support, such as
user interactions and system operations.
2. Non-Functional Requirements:
o Include performance, security, scalability, maintainability, and
usability. These requirements specify how the system performs its
functions and are critical for ensuring that the architecture meets
user and business expectations.
3. Quality Attributes:
o Relate to how well the system performs its functions. Common
quality attributes include:
 Performance: Response time and throughput.
 Scalability: Ability to handle increased load.
 Reliability: System’s ability to operate without failure.
 Security: Protection against unauthorized access and data
breaches.
 Maintainability: Ease of making changes and updates.
4. Constraints:
o Limitations that the architecture must consider, such as technology
stacks, regulatory requirements, and budgetary constraints.
5. Stakeholder Concerns:
o Considerations from various stakeholders (users, developers,
business analysts) to ensure the architecture aligns with their needs
and expectations.

Life-Cycle View of Architecture Design and Analysis Methods

1. Architecture Vision:

Downloaded by SUMAN VERMA (suman.vermacse2022@[Link])

 lOMoARcPSD|53378081

o Establish a clear vision of what the system aims to achieve. This

phase involves gathering initial requirements and understanding
stakeholder needs.
2. Architecture Design:
o Involves creating high-level models that define the system’s
components, their interactions, and how they fulfill functional and
non-functional requirements. Common methods include:
 Model-Driven Architecture (MDA): Focuses on creating
models that can be transformed into executable code.
 Architecture Styles: Such as layered architecture,
microservices, event-driven architecture, etc.
3. Architecture Evaluation:
o Assess the proposed architecture against the requirements using
methods like:
 Architecture Tradeoff Analysis Method (ATAM): Evaluates
architectural decisions based on trade-offs between various
quality attributes.
 Scenario-based Evaluation: Uses specific scenarios to validate
how well the architecture meets requirements.
4. Implementation:
o Involves developing the architecture into a working system. It’s
crucial to maintain alignment with the architectural vision
throughout this phase.
5. Validation and Verification:
o Ensures that the system architecture is correctly implemented and
meets the specified requirements. Techniques include testing and
code reviews.
6. Maintenance and Evolution:
o Over time, the architecture may need to evolve due to changes in
requirements, technology, or business needs. Continuous analysis
and design adjustments are necessary to keep the architecture
relevant.
7. Documentation:
o Throughout the lifecycle, maintaining thorough documentation of
architectural decisions, diagrams, and rationale is essential for future
reference and onboarding new team members.

Cost Benefit Analysis Method (CBAM)

Downloaded by SUMAN VERMA (suman.vermacse2022@[Link])

 lOMoARcPSD|53378081

Overview: Cost Benefit Analysis Method (CBAM) is a structured approach used to

evaluate the economic implications of architectural decisions in software
development. It helps stakeholders assess various architectural scenarios by
comparing the anticipated costs against the expected benefits, facilitating
informed decision-making.

Key Components of CBAM

1. Architectural Scenarios:
o Definition: These are different architectural options or designs under
consideration. Each scenario represents a unique approach to
addressing the system’s requirements.
o Examples: Options could include different architectural patterns
(e.g., microservices vs. monolithic), technology stacks, or deployment
strategies.
2. Cost Estimation:
o Identification of Costs: Costs associated with each architectural
scenario can be categorized into several types:
 Development Costs: Expenses related to designing and
building the system.
 Operational Costs: Ongoing expenses for running the system,
including hosting, maintenance, and support.
 Transition Costs: Costs incurred during the migration to a new
architecture (if applicable).
 Training Costs: Expenses for training staff on new technologies
or methodologies.
o Calculation: Estimate the total costs for each scenario over a defined
period.
3. Benefit Identification:
o Types of Benefits: Benefits can include both tangible and intangible
aspects, such as:
 Increased Performance: Faster response times or higher
throughput.
 Scalability: The ability to handle increased loads without
significant rework.
 Reduced Time to Market: Accelerated development cycles
leading to quicker deployment.

Downloaded by SUMAN VERMA (suman.vermacse2022@[Link])

 lOMoARcPSD|53378081

 Improved User Satisfaction: Enhanced features leading to

better user experience.
 Future Flexibility: Easier adaptation to changing business
needs or technology landscapes.
o Quantification: Assign monetary values to these benefits where
possible, or rate them based on importance.
4. Trade-off Analysis:
o Comparison: Compare the estimated costs and benefits for each
architectural scenario. This can be visualized in a matrix or chart
format.
o Net Benefit Calculation: Calculate the net benefit (or cost) for each
scenario by subtracting total costs from total benefits.
5. Decision Making:
o Prioritization: Use the results to prioritize architectural scenarios
based on their net benefits.
o Risk Consideration: Consider any associated risks with each scenario,
as higher benefits may come with increased uncertainties or
challenges.

Benefits of Using CBAM

 Structured Approach: Provides a systematic framework for evaluating

architectural options.
 Informed Decisions: Facilitates better decision-making by quantifying the
economic impact of different architectural choices.
 Stakeholder Engagement: Involves stakeholders in the evaluation process,
aligning architectural decisions with business goals.
 Clarity and Transparency: Offers a clear rationale for choosing one
architectural approach over another, which can be valuable for justifying
decisions to management or stakeholders.

Architecture Tradeoff Analysis Method (ATAM)

Overview: The Architecture Tradeoff Analysis Method (ATAM) is a structured

approach for evaluating software architectures based on the trade-offs between
various quality attributes. It helps stakeholders understand the implications of
architectural decisions, particularly how they affect the system's performance,
maintainability, security, and other critical aspects.

Downloaded by SUMAN VERMA (suman.vermacse2022@[Link])

 lOMoARcPSD|53378081

Key Components of ATAM

1. Stakeholder Identification:
o Engagement: Identify and involve key stakeholders early in the
process. Stakeholders may include architects, developers, product
owners, users, and business analysts.
o Concerns: Gather information about their specific concerns, needs,
and priorities regarding the architecture.
2. Scenario Development:
o Use Scenarios: Create scenarios that illustrate how the system will be
used in real-world situations. These scenarios should cover both
typical and edge cases.
o Quality Attribute Scenarios: Develop specific scenarios that focus on
quality attributes, such as performance, security, usability, and
modifiability.
3. Attribute Refinement:
o Refine Requirements: Work with stakeholders to refine quality
attribute requirements based on the scenarios. This ensures that the
analysis is aligned with real user needs.
o Prioritization: Prioritize the quality attributes according to
stakeholder concerns and system goals.
4. Evaluation:
o Architectural Decisions: Analyze how different architectural
decisions impact the identified quality attributes. Consider various
architectural alternatives and their implications.
o Trade-off Analysis: Evaluate the trade-offs between quality
attributes. For instance, improving performance might negatively
affect maintainability. Document these trade-offs clearly.
5. Risk Identification:
o Identify Risks: Identify potential risks associated with the
architectural decisions, such as:
 Trade-offs that could lead to unforeseen challenges.
 Areas where requirements may not be met adequately.
 Dependencies on specific technologies or components.
o Mitigation Strategies: Propose strategies to mitigate identified risks.
6. Reporting:
o Documentation: Prepare a comprehensive report summarizing the
findings of the ATAM evaluation. This should include:

Downloaded by SUMAN VERMA (suman.vermacse2022@[Link])

 lOMoARcPSD|53378081

 A description of the architectural scenarios analyzed.

 Trade-offs between quality attributes.
 Identified risks and recommendations for addressing them.
o Stakeholder Review: Present the findings to stakeholders for
feedback and validation.

Benefits of ATAM

 Holistic View: Provides a comprehensive understanding of how

architectural decisions affect quality attributes, leading to more informed
choices.
 Stakeholder Involvement: Engages stakeholders throughout the process,
ensuring that their concerns and priorities are addressed.
 Risk Management: Helps identify and mitigate risks associated with
architectural decisions, leading to more robust designs.
 Decision Support: Facilitates better decision-making by making trade-offs
explicit, allowing stakeholders to weigh the implications of different
options.

Active Reviews for Intermediate Design (ARID)

Overview: Active Reviews for Intermediate Design (ARID) is a method used in

software architecture to evaluate architectural designs during the design process
rather than waiting until the architecture is fully implemented. This approach
emphasizes continuous feedback and collaboration, ensuring that the
architecture remains aligned with requirements and stakeholder needs
throughout the development lifecycle.

Key Components of ARID

1. Regular Review Sessions:

o Intermediate Reviews: Conduct scheduled review sessions at key
points in the design process. These reviews allow the architecture to
be assessed incrementally rather than as a final product.
o Frequency: The frequency of reviews can vary based on project size
and complexity, but they should be frequent enough to allow for
timely feedback.
2. Stakeholder Involvement:

Downloaded by SUMAN VERMA (suman.vermacse2022@[Link])

 lOMoARcPSD|53378081

o Engagement: Involve key stakeholders, including developers, project

managers, and end-users, in the review sessions.
o Feedback Loop: Encourage open dialogue during reviews, allowing
stakeholders to voice concerns, provide insights, and suggest
improvements.
3. Focus Areas:
o Quality Attributes: Emphasize the assessment of quality attributes
such as performance, scalability, security, and maintainability during
the reviews.
o Design Decisions: Analyze the rationale behind specific architectural
choices, ensuring they align with stakeholder expectations and
requirements.
4. Documentation:
o Review Findings: Document the outcomes of each review session,
including feedback received, decisions made, and any identified risks
or issues.
o Action Items: Clearly outline any action items or changes to be made
in response to the feedback, assigning responsibilities and deadlines
where appropriate.
5. Iteration and Refinement:
o Continuous Improvement: Use feedback from reviews to iteratively
refine the architecture. This can involve making adjustments to
design decisions or revisiting requirements.
o Prototyping: In some cases, creating prototypes or mock-ups can
help clarify design choices and facilitate discussions during reviews.

Benefits of ARID

 Early Problem Detection: By evaluating the architecture at intermediate

stages, potential issues can be identified and addressed early in the
development process, reducing the cost and effort of making changes later.
 Stakeholder Alignment: Continuous involvement of stakeholders ensures
that their needs and concerns are consistently addressed, leading to
greater alignment with business goals.
 Enhanced Quality: Regular reviews help ensure that the architecture meets
quality attributes and performance expectations, resulting in a more robust
and effective system.

Downloaded by SUMAN VERMA (suman.vermacse2022@[Link])

 lOMoARcPSD|53378081

 Knowledge Sharing: The collaborative nature of ARID fosters knowledge

sharing among team members, improving overall understanding of the
architecture and design decisions.

Attribute Driven Design (ADD)

Overview: Attribute Driven Design (ADD) is a method for designing software

architecture that focuses on fulfilling specific quality attribute requirements. This
approach emphasizes the importance of quality attributes—such as performance,
security, modifiability, and reliability—in shaping the architectural decisions
throughout the design process.

Key Components of ADD

1. Identify Quality Attributes:

o Requirements Gathering: Start by identifying the key quality
attributes that the system must meet based on stakeholder needs
and system requirements.
o Prioritization: Prioritize these attributes according to their
importance to stakeholders and the overall system goals.
2. Create Scenarios:
o Quality Attribute Scenarios: Develop scenarios that describe how
each quality attribute will manifest in the architecture. These
scenarios should be concrete and reflect real-world usage.
o Examples: For instance, a performance scenario might specify how
the system should handle a certain number of concurrent users
within a defined response time.
3. Architectural Drivers:
o Link Attributes to Architecture: Identify how each quality attribute
will influence architectural decisions. This includes determining
design elements, patterns, and strategies that will help achieve the
desired attributes.
o Consider Trade-offs: Analyze potential trade-offs between quality
attributes. For example, optimizing for performance might impact
maintainability.
4. Refine the Architecture:

Downloaded by SUMAN VERMA (suman.vermacse2022@[Link])

 lOMoARcPSD|53378081

oIterative Design: Based on the scenarios and identified architectural

drivers, iteratively refine the architecture. This involves selecting
appropriate architectural patterns, components, and technologies.
o Prototyping: In some cases, creating prototypes or models can help
visualize how the architecture meets the quality attribute
requirements.
5. Documentation and Evaluation:
o Document Decisions: Keep detailed documentation of architectural
decisions, the rationale behind them, and how they relate to the
identified quality attributes.
o Evaluate Against Scenarios: Continuously evaluate the architecture
against the quality attribute scenarios to ensure that the design
aligns with requirements throughout the development process.

Benefits of ADD

 Quality-Centric Design: ADD ensures that quality attributes are at the

forefront of architectural design, leading to systems that meet performance
and reliability expectations.
 Informed Decision-Making: By linking quality attributes directly to
architectural decisions, teams can make more informed choices that
balance trade-offs effectively.
 Stakeholder Alignment: Engaging stakeholders in the identification and
prioritization of quality attributes helps align the architecture with business
goals and user needs.
 Iterative Improvement: The iterative nature of ADD allows for ongoing
refinement, ensuring that the architecture evolves in response to changing
requirements or insights gained during development.

Architecture Reuse

Overview: Architecture reuse involves leveraging existing architectural designs,

patterns, components, or frameworks in new software projects. This practice
aims to enhance productivity, improve quality, and reduce costs by capitalizing on
proven solutions instead of starting from scratch for each new system.

Key Aspects of Architecture Reuse

1. Types of Reusable Artifacts:

Downloaded by SUMAN VERMA (suman.vermacse2022@[Link])

 lOMoARcPSD|53378081

o Architectural Patterns: Established solutions to common

architectural problems (e.g., microservices, layered architecture,
event-driven architecture).
o Design Patterns: Specific solutions to design problems within a
system (e.g., Singleton, Observer, Factory).
o Frameworks: Predefined structures that provide a foundation for
building applications (e.g., Spring for Java, Django for Python).
o Reference Architectures: Blueprint architectures that describe how
to structure applications in specific domains or technologies.
2. Benefits of Architecture Reuse:
o Cost Efficiency: Reduces development time and costs by using
existing solutions, minimizing the need for custom development.
o Consistency: Promotes consistency across projects, leading to better
maintainability and understanding among developers.
o Quality Improvement: Reusing well-tested architectures and
components can lead to fewer bugs and better overall system
reliability.
o Faster Time to Market: Accelerates the development process by
providing ready-made solutions, allowing teams to focus on unique
features rather than reinventing the wheel.
3. Challenges of Architecture Reuse:
o Integration Issues: Reusing components or patterns may lead to
integration challenges with existing systems or technologies.
o Compatibility: Ensuring that reused architectures align with new
project requirements or constraints can be difficult.
o Knowledge Management: Effective reuse requires documentation
and knowledge sharing about existing architectures, which may be
lacking in some organizations.
o Overhead: In some cases, the complexity of integrating reusable
components can outweigh the benefits, leading to increased
overhead.
4. Strategies for Successful Architecture Reuse:
o Establish a Repository: Create a centralized repository for reusable
architectural patterns, designs, and components to facilitate easy
access and sharing.

Downloaded by SUMAN VERMA (suman.vermacse2022@[Link])

 lOMoARcPSD|53378081

oDocument Reusable Artifacts: Ensure that all reusable components

are well-documented, including their intended use cases, limitations,
and integration guidelines.
o Promote Best Practices: Encourage teams to adopt best practices for
reuse, including regular reviews of existing architectures and
patterns.
o Train Teams: Provide training to developers on the available reusable
architectures and how to effectively implement them.
5. Domain-Specific Architecture Reuse:
o Focus on Specific Domains: Develop domain-specific architectures
that capture common patterns and practices for particular
application areas (e.g., healthcare, finance).
o Tailored Solutions: These architectures can be tailored to meet the
unique needs of different projects while still benefiting from the
efficiencies of reuse.

Domain-Specific Software Architecture (DSSA)

Overview: Domain-Specific Software Architecture (DSSA) refers to architectural

designs and patterns that are tailored to the specific needs, challenges, and
requirements of a particular application domain. By focusing on common
problems and solutions within a given domain, DSSA promotes efficiency and
effectiveness in software development.

Key Components of DSSA

1. Domain Definition:
o Identification: A domain is a specific area of expertise or interest
(e.g., healthcare, finance, e-commerce, telecommunications) that has
unique requirements and constraints.
o Characteristics: Each domain has its own terminology, practices,
regulatory considerations, and stakeholder needs that influence the
architecture.
2. Reusable Architectural Patterns:
o Common Solutions: DSSA often includes a set of reusable
architectural patterns and best practices that address recurring
problems within the domain.

Downloaded by SUMAN VERMA (suman.vermacse2022@[Link])

 lOMoARcPSD|53378081

o Examples: In healthcare, for instance, architectures may need to

integrate with electronic health record systems, adhere to privacy
regulations, and support real-time data access.
3. Domain Models:
o Conceptual Frameworks: Domain models provide a structured
representation of the concepts and relationships within the domain,
helping to inform the architecture.
o Business Logic: These models capture essential business logic and
rules that guide the design of the system.
4. Quality Attribute Focus:
o Tailored Quality Attributes: DSSA considers quality attributes that
are particularly relevant to the domain, such as performance in real-
time systems or security in financial applications.
o Scenario-Driven Design: The architecture is often designed around
specific use cases or scenarios that reflect the domain's typical
requirements.
5. Tooling and Frameworks:
o Supportive Tools: Domain-specific architectures may come with
associated tools, frameworks, or libraries that streamline
development processes within that domain.
o Rapid Development: These tools can help developers quickly create
applications that are consistent with domain standards.

Benefits of Domain-Specific Software Architecture

1. Improved Efficiency:
o Accelerated Development: By providing reusable patterns and
components, DSSA can significantly reduce development time and
effort.
o Standardization: Encourages consistency across projects within the
same domain, which can simplify maintenance and onboarding.
2. Enhanced Quality:
o Proven Solutions: Utilizing established patterns reduces the
likelihood of defects, as these solutions are based on successful
implementations.
o Domain Expertise: DSSA incorporates domain knowledge, ensuring
that the architecture aligns well with specific business needs.
3. Better Alignment with Requirements:

Downloaded by SUMAN VERMA (suman.vermacse2022@[Link])

 lOMoARcPSD|53378081

o Focused Design: The architecture is designed with a deep

understanding of domain-specific requirements, making it more
likely to meet stakeholder expectations.
o Regulatory Compliance: Helps ensure that the architecture adheres
to industry regulations and standards that are often specific to
certain domains.
4. Facilitated Communication:
o Common Vocabulary: Provides a shared understanding and
terminology among stakeholders within the domain, improving
collaboration and communication.

Challenges of Domain-Specific Software Architecture

1. Limited Flexibility:
o Domain Constraints: Highly specialized architectures may be less
adaptable to changes outside the defined domain, potentially
limiting reuse in other contexts.
2. Upfront Investment:
o Development Effort: Creating a domain-specific architecture may
require significant upfront investment in terms of time and
resources.
3. Knowledge Management:
o Maintaining Relevance: Keeping domain knowledge and
architectural patterns updated with evolving technologies and
practices can be challenging.

Downloaded by SUMAN VERMA (suman.vermacse2022@[Link])