Software Engineering :-

Unit III Software Architecture Learning Objectives

The learning objectives of software architecture in software engineering include:

 Understanding architectural principles like modularity, scalability, and maintainability.

 Familiarizing with architectural patterns such as layered architecture, microservices,
and event-driven models.
 Designing architectures that balance functional and non-functional requirements.
 Evaluating architectures based on quality attributes (performance, security, etc.).
 Documenting architecture using standardized notations like UML.
 Communicating architectural decisions to stakeholders effectively.
 Addressing system evolution by designing flexible and adaptable architectures.
 Identifying risks early and mitigating potential architectural flaws.

The role of software architecture in software engineering includes:

 Providing a blueprint that guides development and system structure.

 Managing complexity by dividing the system into components and defining interactions.
 Ensuring quality attributes, such as performance, scalability, security, and
maintainability.
 Facilitating communication among stakeholders, developers, and other team members.
 Enabling system flexibility and adaptability for future changes or scaling.
 Supporting reuse, allowing components to be reused across projects.
 Mitigating risks early by identifying architectural challenges and addressing them
proactively.
 Driving decision-making, balancing trade-offs between competing requirements

Software architecture plays a vital role in software engineering, serving as the foundation for the
successful design, development, and maintenance of complex software systems. It addresses both
technical and non-technical aspects, shaping the system's structure and guiding its evolution.
Here’s a detailed explanation of its key roles:

1. Blueprint for Development

Software architecture acts as a high-level blueprint that outlines the organization of the system's
components and their interactions. It provides a roadmap for developers, ensuring consistency in
design and implementation, and sets the stage for coding, testing, and maintenance activities.
Without a clear architecture, systems can become chaotic and difficult to manage.

2. Managing Complexity
Large software systems are inherently complex, involving many interacting parts. Software
architecture helps manage this complexity by breaking the system down into manageable
components, modules, or services, each with defined responsibilities. It defines the relationships
between these elements, making it easier to understand, modify, and maintain the system over
time.

3. Ensuring Quality Attributes

Software architecture plays a critical role in addressing non-functional requirements (quality

attributes) such as:

 Performance
 Scalability
 Security
 Maintainability
 Reliability

Decisions made at the architectural level can significantly impact these attributes. For example,
choosing an event-driven architecture can enhance scalability, while a layered architecture may
improve maintainability and separation of concerns.

4. Facilitating Communication

Architecture serves as a common language for various stakeholders (e.g., developers, business
analysts, project managers) to discuss system structure and functionality. It helps bridge the gap
between technical and non-technical perspectives, ensuring that everyone involved has a shared
understanding of the system's design, goals, and constraints.

5. Enabling Flexibility and Evolution

A well-designed architecture provides flexibility, allowing the system to adapt to future

requirements, new technologies, or scaling needs without significant rework. This adaptability is
crucial in modern software development, where systems often evolve over time due to changing
business needs, emerging technologies, or evolving customer expectations.

6. Supporting Reuse

Architecture promotes the reuse of components, modules, and patterns across different parts of the
system or even across different projects. By creating well-defined, modular components with clear
interfaces, developers can reuse existing functionality, speeding up development and ensuring
consistency across systems.

7. Risk Mitigation

By defining key architectural decisions early in the software development lifecycle, architects can
identify and mitigate potential risks such as performance bottlenecks, security vulnerabilities, or
scalability issues. This proactive approach helps avoid costly mistakes later in the development
process.

8. Guiding Decision-Making

Software architecture provides a framework for decision-making throughout the development

process. Architects must balance trade-offs between competing requirements, such as performance
vs. cost, flexibility vs. complexity, or security vs. usability. The architecture acts as a guide,
ensuring that decisions align with both technical goals and business objectives.

9. Aligning with Business Goals

Finally, software architecture aligns technical decisions with business objectives. By addressing
key concerns such as scalability, cost-effectiveness, and time-to-market, architecture ensures that
the software solution not only meets technical requirements but also contributes to the overall
success of the business.

Conclusion

Software architecture is the backbone of successful software engineering. It defines the structure
of the system, ensures that quality attributes are met, and provides a foundation for long-term
maintenance and scalability. Its role extends beyond technical concerns, serving as a
communication tool, a risk management strategy, and a guide for decision-making throughout the
software development process.

Software architecture is a structured framework used to conceptualize software elements,

relationships, and properties. It involves multiple views that help in understanding the structure,
behavior, and interactions of the system. The two commonly used views are:

1. Component-and-Connector (C&C) View

2. Module View

Let's explore each view along with diagrams:

1. Component-and-Connector (C&C) View

The C&C View focuses on the dynamic relationships and runtime interactions of the system. It
shows how components (such as software objects, services, or databases) interact with each other
via connectors (like communication protocols, message passing, or function calls). The focus is on
the behavior of the system.

Components:

 Active Elements: Application logic modules like microservices, databases, or UI components.

 Passive Elements: Data stores or files.

Connectors:

 Types of Connectors: Pipes, HTTP requests, RESTful APIs, remote procedure calls (RPC), message
queues, etc.

Example Diagram of C&C View:

lua
Copy code
+--------------+ +-----------------+
| Web Server | ---- HTTP ----> | Application |
+--------------+ | Server |
+-----------------+
| |
DB Connector Message Queue
| |
+------+ +-----------+
| DB | | Queue |
+------+ +-----------+

In this example:

 Web Server is the component responsible for serving web pages.

 Application Server handles the logic.
 Connectors: HTTP is used to communicate between the Web and Application Server. The
Application Server communicates with the Database (DB Connector) and Message Queue (Queue
Connector).

2. Module View

The Module View describes the static structure of the system. It shows how the system is divided
into modules (logical groups of code), and how these modules are related to each other.

Components in Module View:

 Modules: Represent logical groupings of code such as classes, libraries, packages, etc.
 Dependencies: Show relationships between modules, such as how one module relies on another.

Example Diagram of Module View:

sql
Copy code
+-------------------+
 | User Module |
+-------------------+
|
v
+-------------------+ +-------------------+
| Authentication | ---> | Authorization |
+-------------------+ +-------------------+
| |
v v
+-------------------+ +-------------------+
| Service Layer | ---> | Data Access Layer |
+-------------------+ +-------------------+

In this example:

 User Module handles user-specific tasks.

 Authentication and Authorization are dependent on the User Module.
 Service Layer interacts with the Data Access Layer to manage and retrieve data.

Key Differences:

 C&C View focuses on runtime behavior and interactions between the components.
 Module View focuses on the static organization of the code and its logical structure

Here’s an overview of various software architecture styles and processes, including Pipe-and-
Filter, Shared Data, Client-Server, as well as the concepts of Documenting Architecture
Design and Evaluating Architecture in terms of Software Engineering:

1. Pipe-and-Filter Architecture

The Pipe-and-Filter architecture organizes a system as a sequence of independent components

(filters) that process data incrementally, with the output of one component becoming the input to
the next. The pipes act as connectors that transfer data between filters.

 Filters: Independent modules that perform specific transformations or computations on data.

They don’t share state and work in isolation.
 Pipes: Connections that transmit the output of one filter as the input to the next.

Example:

A system for processing an image might have the following filters:

1. Read Image → 2. Resize Image → 3. Apply Filter → 4. Save Image

Benefits:

 High reusability of filters.

 Easy to maintain and scale (new filters can be added).
 Filters can run in parallel, which enhances performance.

Drawbacks:

 The system may become slow due to data transfer between filters.
 Not suitable for systems requiring a lot of shared state or interaction between filters.

2. Shared Data (Repository) Style

The Shared Data style (also known as the Repository architecture) consists of a central data store
(repository) that is accessed and updated by various components.

 Repository: The central storage where data is maintained.

 Components: Systems or applications that use the data for processing and computation.

Example:

In a database-centric application, all subsystems share and manipulate the data stored in a
common database. For example, multiple services in a banking system (like balance inquiry,
transaction history, loan status) access and update a shared database.

Benefits:

 Centralized management of data ensures consistency.

 Components are loosely coupled since they don’t interact directly with each other but through
the repository.

Drawbacks:

 If the central data repository fails, the entire system may go down.
 Communication overhead increases as components must frequently interact with the repository.

3. Client-Server Architecture

The Client-Server style divides a system into two main components:

 Clients: Users or applications that request services.

 Server: The system that provides services to clients.
Example:

In a web application, the client is the user’s browser, and the server is a web server that processes
requests and serves data.

Benefits:

 Centralized control at the server side.

 Scalability as clients can be added or removed without affecting the server.
 Easy to maintain security and authorization at the server.

Drawbacks:

 The server can become a bottleneck if it receives too many requests.

 If the server fails, all clients are impacted.

4. Documenting Architecture Design

Documenting the architecture of a software system is essential for communication, maintaining

consistency, and guiding future development. Effective documentation includes:

 Architectural Views: Different perspectives (e.g., Module View, Component-and-Connector View)

to show how the system is structured and behaves.
 Context Diagrams: To describe how the system interacts with external entities.
 Data Flow Diagrams (DFD): To show how data flows through the system.
 Sequence Diagrams: To illustrate interactions over time between various components.
 Rationale: Explaining the reasoning behind architectural decisions (e.g., why a specific
architectural pattern was chosen).

Best Practices:

 Keep the documentation up to date with code changes.

 Use visual diagrams for clarity.
 Provide detailed explanations of key components and their interactions.

5. Evaluating Architecture in Terms of Software Engineering

Evaluating software architecture is critical to ensure that the system meets its quality attributes
such as performance, security, and maintainability. Key criteria include:
1. Performance:

 Scalability: How well the system handles increasing loads (e.g., more users, more data).
 Latency: The time delay experienced by users or components while interacting with the system.

2. Maintainability:

 Modularity: Is the system broken into easily maintainable parts?

 Separation of Concerns: Are different functionalities well-separated in the architecture to allow
for independent updates?

3. Security:

 Data Security: How is sensitive data protected (e.g., encryption, authentication)?

 Authorization: Are different users or systems allowed access to only specific parts of the
application?

4. Reliability:

 Fault Tolerance: Can the system continue to operate even if some components fail?
 Redundancy: Are there backup systems or processes in case of failure?

5. Testability:

 How easily can different parts of the system be tested independently?

6. Flexibility & Scalability:

 Can the system be easily modified to meet new requirements or to scale with growing data or
user demands?

Architectural Evaluation Techniques:

 ATAM (Architecture Tradeoff Analysis Method): Used to evaluate architectural decisions by

assessing trade-offs between various quality attributes.
 Scenario-based evaluation: Evaluate the architecture by running it through various real-world
scenarios to check for robustness, scalability, etc.

Planning a Software Project:-

Planning a software project involves defining the objectives, scope, timeline, resources, and risks
to ensure the successful execution of the project. It establishes a roadmap to guide the team toward
delivering a quality product on time and within budget.
Learning Objectives:-

By the end of project planning, participants should be able to:

1. Understand the Importance of Planning: Recognize how a detailed plan impacts project success.
2. Establish Clear Goals: Define measurable project objectives and deliverables.
3. Estimate Effort Accurately: Predict the time and resources needed for project completion.
4. Develop an Execution Strategy: Plan the work breakdown, scheduling, resource allocation, and
risk management.
5. Monitor and Adjust Plans: Use metrics and tools to track progress and update the plan as needed.

Effort Estimation:-

Effort estimation is the process of predicting how much time, effort, and resources will be required
to complete a project or task. Accurate estimates are crucial for:

 Budgeting and resource allocation.

 Scheduling tasks.
 Managing stakeholder expectations.

Key Considerations in Effort Estimation:

 Complexity of tasks.
 Skills and experience of the team.
 Use of tools and technology.
 Historical data from similar projects.

Top-Down Estimation Approach:-

The top-down estimation approach starts by evaluating the project as a whole and then breaking
it down into smaller components.

Characteristics:

1. High-Level Estimation: Begins with an overall estimate based on project size, scope, and historical
data.
 2. Simplistic and Quick: Useful during the early phases of the project when detailed information is
unavailable.
3. Based on Analogies: Often uses experience or comparisons with similar past projects.

Advantages:

 Requires less time and effort initially.

 Provides a rough idea for stakeholders.
 Useful when detailed specifications are not yet available.

Limitations:

 May overlook specific task complexities.

 Less accurate for projects with unique or novel requirements.

Bottom-Up Estimation Approach:-

The bottom-up estimation approach starts by estimating individual tasks and then summing them
up to derive the overall project estimate.

Characteristics:

1. Task-Level Estimation: Breaks the project into smaller components, such as tasks or deliverables.
2. Detailed and Comprehensive: Requires in-depth knowledge of the project and its requirements.
3. Collaborative Process: Often involves input from team members responsible for specific tasks.

Advantages:

 Provides more accurate estimates.

 Accounts for the complexity of individual tasks.
 Helps in detailed scheduling and resource allocation.

Limitations:

 Time-consuming and labor-intensive.

 Requires a well-defined scope and specifications.
Key Aspects of Software Project Management:-
Effective project management in software engineering involves careful planning, monitoring,
and execution of activities. Here's a detailed explanation of the topics mentioned:

1. Project Schedule and Staffing:-

Project Schedule:

The project schedule defines the timeline of activities, milestones, and deliverables to complete
the project.

 Steps to Create a Schedule:

1. Break down the project into smaller tasks (Work Breakdown Structure, or WBS).
2. Define dependencies between tasks (e.g., Task B starts after Task A).
3. Estimate the duration for each task.
4. Allocate resources and set deadlines.
5. Visualize the schedule using tools like Gantt charts or critical path diagrams.
 Output: A roadmap showing when and how tasks will be completed.

Staffing:

Involves allocating team members to tasks based on their skills, experience, and availability.

 Key Considerations:
o Skill Matching: Assign tasks to team members with the necessary expertise.
o Team Size: Balance team size to avoid overcrowding or resource shortages.
o Effort Distribution: Avoid overburdening team members.

2. Quality Planning:-

Quality planning ensures that the project meets defined quality standards.

 Steps:
1. Identify quality standards based on user requirements (e.g., ISO, Agile principles).
 2. Define measurable quality goals (e.g., fewer than X defects per module).
3. Develop quality assurance (QA) and quality control (QC) processes (e.g., code reviews,
testing).
4. Plan for tools and resources needed for quality management.
 Key Outputs:
o Test plans
o Review checklists
o Quality metrics

3. Risk Management Planning:-

Risk management identifies, assesses, and mitigates potential risks that could impact the project.

Risk Management Planning Approach:

1. Risk Identification:
o Use brainstorming, checklists, and historical data to list potential risks.
o Example risks: resource shortages, changing requirements, technical issues.
2. Risk Assessment:
o Likelihood: Determine the probability of each risk.
o Impact: Assess the potential severity of each risk.
o Risk Matrix: Combine likelihood and impact to prioritize risks.
3. Risk Control:
o Mitigation: Develop strategies to reduce the impact or likelihood of risks.
o Contingency: Plan actions to take if the risk materializes.

4. Project Monitoring Plan:-

The project monitoring plan ensures progress aligns with the schedule and objectives.

 Components:
1. Define measurable metrics (e.g., task completion percentage, defect rate).
2. Set regular intervals for status reporting (e.g., weekly updates).
3. Use tools like dashboards, reports, and Kanban boards for tracking.

5. Measurement:-

Measurement involves collecting data to assess project performance.

  Common Metrics:
o Schedule Variance (SV): Measures if the project is ahead or behind schedule.
o Cost Variance (CV): Compares actual spending with the budget.
o Defect Density: Number of defects per unit of code.
o Velocity: Measures the work completed in a sprint (Agile projects).

6. Project Monitoring and Tracking:-

Monitoring and tracking ensure the project stays on course and deviations are addressed
promptly.

 Steps:
1. Compare actual progress with the plan.
2. Identify deviations (e.g., delays, cost overruns).
3. Take corrective actions to address issues.
 Tools:
o Agile boards (e.g., Jira)
o Earned Value Management (EVM)
o Burn-down and burn-up charts

7. Detailed Scheduling

Detailed scheduling involves creating a fine-grained plan for task execution.

 Steps:
1. Break tasks into smaller sub-tasks.
2. Define task dependencies and resource requirements.
3. Assign team members to each task.
4. Create a timeline for each sub-task.
5. Continuously update the schedule based on progress and changes.
 Output: A granular, step-by-step execution plan.