Unit I

1. Quality attributes of the design product and techniques 4 attributes

2. Design strategies explain
3. Incremental
4. Component based steps, design process.
5. Design in the software development process - prototyping and its advantages

Unit II
6. Data centered architecture, benefits/advantages and limitations
7. Hierarchical architecture, different approaches
8. Distributed architecture
9. Product line architecture, features
10. Models of architecture – project life cycle
11. behavioral models in uml
Unit III
12. Quality attributes of software
13. Architecture in agile projects
14. Documenting software architecture, features, template, importance and how it used
15. Architecture reconstruction
Unit V
16. Centralized version control explain with example
17. Distributed version control and comparison of distributed and centralized
18. Features of version control tools, 4 tools, importance and functions
Give above questions ans as per reference to software design David budgen, version control example by
eric sink, software architecture and design illuminated, configuration management best practices
UNIT I
 What is quality attributes? Explain any four quality attributes of software
Each architecture style has its advantages, disadvantages, and potential risks. Choosing the right style to
satisfy required functions and quality attributes is very important. Quality attributes are identified in the
requirement analysis process. Quality attributes can be categorized into the following three groups:
1. Implementation attributes (not observable at runtime)
• Interoperability: universal accessibility and the ability to exchange data among internal components
and with the outside world.
Interoperability requires loose dependency of infrastructure.
• Maintainability and extensibility: the ability to modify the system and conveniently extend it.
• Testability: the degree to which the system facilitates the establishment of test cases. Testability
usually requires a complete
set of documentation accompanied by system design and implementation.
• Portability: the system's level of independence on software and hardware platforms. Systems
developed using high-level
programming languages usually have good portability. One typical example is Java—most Java
programs need only be
compiled once and can run everywhere.
• Scalability: a system's ability to adapt to an increase in user requests. Scalability disfavors bottlenecks
in system design.
 • Flexibility: the ease of system modification to cater to different environments or problems for which
the system was not originally designed. Systems developed using component-based architecture or
service-oriented architecture usually possess this attribute.
2. Runtime attributes (observable at runtime)
• Availability: a system's capability to be available 24/7. Availability can be achieved via replication and
careful design to cope
with failures of hardware, software, or the network.
• Security: a system's ability to cope with malicious attacks from outside or inside the system. Security
can be improved by
installing firewalls, establishing authentication and authorization processes, and using encryption.
• Performance: increasing a system's efficiency with regard to response time, throughput, and resource
utilization, attributes
which usually conflict with each other.
• Usability: the level of human satisfaction from using the system. Usability includes matters of
completeness, correctness,
compatibility, as well as a friendly user interface, complete documentation, and technical support.
• Reliability: the failure frequency, the accuracy of output results, the Mean-Time-to-Failure (MTTF),
the ability to recover from
failure, and the failure predictability.
• Maintainability (extensibility, adaptability, serviceability, testability, compatibility, and
configurability): the ease of software system change.
3. Business attributes
• Time to market: the time it takes from requirements analysis to the date a product is released.
• Cost: the expense of building, maintaining, and operating the system.
• Lifetime: the period of time that the product is “alive” before retirement.

 Explain design strategies used in software development

 decompositional methods, which generally take a ‘top-down’ view of the design process,
developing the design model through a process of sub-division;
 compositional methods, whereby the basic design model is built up from the identification of
‘entities’ of some form;
 organizational methods, for which the structure of the design process is strongly influenced by the
requirement that it should conform to non-technical requirements that are based on the form of the
organization;
 template-based methods, where a specific problem domain provides a class of problems that can be
tackled using a fairly standard strategy.
1. Decompositional Methods
 Definition: A top-down approach where the system design begins with a high-level model and is
progressively refined into smaller, manageable components or sub-systems.
 Advantages:
o Promotes clarity by focusing on the system’s overall structure first.
o Encourages modularity, making testing and maintenance easier.
 Example: Designing an e-commerce platform by dividing it into major modules like user
management, product catalog, and payments, and then refining these into submodules like login,
search, and checkout.

2. Compositional Methods
 Definition: A bottom-up approach where the system is designed by building smaller, reusable
components or entities and integrating them to form the complete system.
 Advantages:
 o Encourages code reuse and reduces redundancy.
o Ensures the quality and functionality of individual components before integration.
 Example: Building a media player by developing reusable components for playback, volume
control, and playlist management, then combining them into a functional system.

3. Organizational Methods
 Definition: The design process is influenced by non-technical requirements, such as aligning with
organizational structures, workflows, or policies.
 Advantages:
o Ensures the software fits seamlessly within the organization’s processes.
o Encourages collaboration between technical and business teams.
 Example: Designing a project management tool tailored to a company’s specific hierarchy and
workflow.

4. Template-Based Methods
 Definition: A method where solutions are derived using predefined templates or patterns specific
to a recurring problem domain.
 Advantages:
o Reduces design time and effort for common problems.
o Provides proven and reliable solutions.
 Example: Applying the Model-View-Controller (MVC) design pattern to develop a web application.

 Explain incremental design in software development process with diagram.

Definition:
Incremental design is a systematic approach where a software system is developed in small,
functional increments. Each increment provides a subset of the final system's functionality, allowing
for iterative testing, evaluation, and refinement. This approach is particularly effective in managing
complexity, reducing risks, and adapting to evolving requirements.
Process of Incremental Design
The process, as referenced from David Budgen's "Software Design", consists of the following key
stages:
1. Agree on Basic Requirements:
o The initial step involves identifying core requirements for the system. These are
typically high-priority features or functionalities that form the foundation of the
software.
o Example: In an e-commerce system, basic requirements might include user login and
product browsing.
 2. Develop Architectural Design:
o A high-level system architecture is designed to ensure that the system can
accommodate future increments. This includes defining the overall structure and the
relationships between components.
o Example: Establishing a layered architecture to separate user interface, business logic,
and data storage.
3. Undertake Partial Detailed Design:
o Detailed design is carried out for the specific increment being developed. This focuses
on achieving a well-defined and functional module.
o Example: Designing the database schema and logic for the shopping cart
functionality.
4. Develop Prototype, Test, and Evaluate:
o A working prototype of the increment is implemented. It undergoes rigorous testing to
ensure correctness and reliability. Feedback is gathered to improve the increment.
o Example: Testing the shopping cart feature with various scenarios like adding and
removing items.
5. Implement and Test Final System:
o The tested increment is integrated with previously completed increments. The
integrated system undergoes additional testing to ensure all components work
seamlessly.
o Example: Verifying that the shopping cart works in conjunction with the payment
gateway.
6. Repeat the Process:
o The cycle is repeated for subsequent increments until the entire system is developed
and delivered. Each iteration builds upon the previous one, gradually evolving into the
final product.
Advantages
1. Risk Reduction:
Errors are easier to identify and address in smaller increments, minimizing the chances of
major failures.
2. Early Delivery:
Users receive functional parts of the system early, allowing them to begin using it while
development continues.
3. Flexibility:
Evolving requirements can be incorporated into future increments without disrupting the
entire system.
4. Improved Quality:
Continuous testing and feedback ensure higher reliability and alignment with user needs.
5. Cost-Effectiveness:
Smaller increments allow for better resource allocation and reduce wastage caused by
unanticipated changes.
 What is prototyping? Explain the advantages of prototyping in software.
Definition:
Prototyping in software development refers to the creation of a preliminary version (prototype) of a
system that can be tested and evaluated. This prototype is used to visualize system functionality, gather
feedback, and refine the system iteratively based on user input.
Floyd’s Classification of Prototyping Roles
1. Evolutionary Prototyping:
o This is similar to incremental development, where a basic system is built and evolved
through continuous changes based on feedback. The prototype gradually evolves into the
final product.
2. Experimental Prototyping:
o The prototype is used for evaluating potential solutions, such as assessing performance or
testing algorithms. It is often discarded after serving its purpose for testing.
3. Exploratory Prototyping:
o This role focuses on clarifying user requirements and understanding how the system
impacts broader organizational processes. It is used to explore unclear or ambiguous user
needs.
Advantages of Prototyping in Software Development
1. Improved User Involvement:
Prototypes allow users to interact with the system early in the process, providing direct feedback
and ensuring the system meets user expectations.
2. Better Requirement Clarification:
Prototypes help in refining and clarifying ambiguous requirements by giving users a tangible
version of the system to evaluate and provide input on.
3. Reduced Risk of Failure:
Early feedback and iterative testing help identify flaws and issues early, reducing the risk of
failure in the final product.
4. Faster Development:
By building prototypes incrementally, developers can deliver working versions of the system
faster, allowing for ongoing feedback and improvements.
5. Cost-Effective:
Prototypes help save costs by identifying necessary features early, preventing the development of
unnecessary functionalities, and allowing for more focused resources.
6. Facilitates Communication:
Prototypes act as a visual tool for communication between users and developers, helping to align
expectations and clarify design decisions.
7. Flexibility and Adaptability:
Prototyping offers flexibility by allowing changes based on feedback at each iteration, making it
easier to adapt to evolving requirements.
UNIT II
 Explain Behavioural model in UML.
 1. The Unified Modeling Language (UML) is a graphical language for visualizing, specifying,
constructing, and documenting the artifactsof a software-intensive system.
2. UML is widely used as a guideline for software requirement analysis and design documents
3. UML provides several modeling diagrams that can be grouped into two major categories:
structural (static) and behavioral (dynamic).

 data cantered architecture

 Data-centered software architecture is characterized by a centralized data store that is shared by
all surrounding software components.
 The software system is decomposed into two major partitions: data store and independent
software component or agents. The connections between the data module and the software
components are implemented either by explicit method invocation or by implicit method
invocation
 There are two categories of data-centered architecture: repository and blackboard.

 These are differentiated by the flow control strategy.

  Data Repository: A data repository is a centralized storage system that houses the shared
data. It acts as a passive component, storing data and providing access to it when requested.
Components interact with the repository by reading from it or writing to it. The repository
itself does not initiate any actions or trigger any processes.

1. Blackboard: A blackboard is a more dynamic and active version of a data repository. It not only
stores data but also actively monitors it for changes. When changes occur, the blackboard notifies
interested components, triggering them to take action. This proactive nature of the blackboard
allows for a more event-driven and reactive architecture.
2. Centralized Data Management
o Facilitates a single source of truth, ensuring that all team members access consistent and
up-to-date data.
o Simplifies tracking and merging of changes, reducing conflicts.
3. Improved Collaboration
o Centralized repositories like GitHub or GitLab support team collaboration by providing
structured data handling.
o Teams can work on the same project without overwriting each other's changes.
4. Data Integrity and Consistency
o Centralized architectures often include mechanisms to ensure data integrity, such as
version tracking and conflict resolution tools.
o Helps maintain consistent versions across the development environment.
5. Efficient Backup and Recovery
o Easier to create backups of centralized data. If issues occur, recovery is streamlined.
o Provides historical data access to revert to previous states of the software or codebase.
6. Scalability
o Suitable for large-scale projects where multiple versions and branches of the software
need to be managed.
o Supports branching, merging, and maintaining multiple versions with ease.
7. Traceability
o Changes to the codebase are tracked systematically, enabling developers to identify and
resolve issues efficiently.
o Enhances accountability with a clear audit trail of who made changes and why.

Limitations of Data-Centered Architecture in Software Development Version Control

1. Single Point of Failure
o A centralized system may face downtime or data loss if the central repository or server
fails, affecting all users.
o Requires robust backup and redundancy mechanisms.
2. Performance Bottlenecks
o Heavy usage or large teams accessing the central data simultaneously can lead to slower
performance.
o Network latency may affect operations like pulling or pushing updates.
3. Complexity in Large Systems
o Managing vast amounts of data and multiple branches in a centralized architecture can
become complex.
o Merging conflicting changes in large projects may require significant manual
intervention.
4. Security Concerns
o Centralized systems are attractive targets for attacks, as compromising the central
repository can jeopardize the entire project.
o Requires robust security measures like access control and encryption.
 5. Dependency on Infrastructure
o Relies on high availability and reliability of the central server. If infrastructure is weak, it
could lead to disruptions.
o Offline work can be challenging, as developers often need a connection to sync with the
central repository.
6. Version Overhead
o In highly iterative environments, the frequent creation of versions can lead to repository
bloating, consuming storage and complicating navigation.
 Hierarchical architecture:

 The hierarchical software architecture is characterized by viewing the entire system as a

hierarchy structure.
 The software system is decomposed into logical modules (subsystems) at different levels in the
hierarchy.
 Modules at different levels are connected by explicit or implicit method invocations.
 In other words, a lower-level module provides services to its adjacent upper-level modules,
which invokes the methods or procedures in the lower level.
 System software is typically designed using the hierarchical architecture style; examples include
Microsoft .NET, Unix operating system, TCP/IP, etc.
 This architecture category is characterized by the hierarchical structure and explicit method
invocation (call-and-return) connection styles.
 It is also used in the organization of class libraries such as Java API in package hierarchy
or .NET class library in name space hierarchy.
 A variety of design types—procedure-oriented, object-oriented, component- oriented, domain-
specific—can all implement the hierarchical software architecture.

Benefits of Hierarchical Architectures

1. Organized Structure
o Each layer has a specific role, making it easier to understand and work on.
2. Easy Maintenance
o You can update or fix one layer without affecting the others.
3. Scalable
o New features or changes can be added to a specific layer without much hassle.
4. Reusability
o Parts of the system, like utility functions, can be reused in different projects.
5. Better Testing and Debugging
o Layers can be tested one at a time, making it easier to find and fix bugs.
6. Team Collaboration
o Different teams can work on different layers simultaneously without conflicts.
7. Flexible Technology Choices
o Each layer can use the best tools or technologies for its tasks.
Limitations of Hierarchical Architecture

1. Slower Performance
o Data has to go through multiple layers, which can slow things down.
2. Too Complex for Small Projects
o Using layers can make simple projects unnecessarily complicated.
3. Dependency Problems
o If layers are too dependent on each other, making changes becomes hard.
4. Rigid Structure
o Adding features that affect multiple layers might require a lot of redesigning.
5. Duplication of Work
o Some tasks, like data validation, might be repeated in multiple layers.
6. Hard to Maintain if Poorly Designed
o If the system isn’t well planned, managing the layers becomes a headache.
7. Communication Delays
o Passing information between layers can take extra time and effort.

 Distributed architecture.
 Distributed architecture is a system design where components are spread across different networked
locations but work together to achieve a common goal. Each component, or "node," can perform
tasks independently or collaborate with others.
 A distributed system is a collection of computational and storage devices connected through a
communications network.
 In this type of system, data, software, and users are distributed. The subsystems or components
within distributed system communicate with each other using a number of methods including
message passing, remote procedure calls, and remote method invocation.
 Two important elements of designing a distributed system are: network topology, the way in which
entities are organized to form a connected network; and communications mode, the method by
which components communicate with each other.
 Many systems in the real world are naturally distributed.
 These systems are widely used in large enterprise environments such as a database system that
enables data to be accessed remotely, a B2B system with its distributed suppliers and clients, or an
SAP system to manage distributed resources. Distributed systems are everywhere.
 A distributed system can be modeled by the client-server architecture, and this forms the basis for
multi-tier architectures.
 Alternatives are the broker architecture such as CORBA, and the service-oriented architecture
(SOA) such as web services and grid services.
 Key features of a distributed architecture are its service location transparency and its services
reliability and availability.
 Additionally, there are several technology frameworks to support distributed architectures,
including .NET, J2EE, CORBA, .NET web services, AXIS Java web services, and GloBus grid
services.
 The client-server model is the most commonly distributed system architecture.
 Advantages:
• Separation of responsibilities such as user interface presentation and business logic processing
• Reusability of server components
Disadvantages:
• Lack of heterogeneous infrastructure to deal with the requirement changes
• Security complications
• Server availability and reliability
• Testability and scalability
• Fat clients with presentation and business logic together

 Product line architecture:

Product Line Architecture refers to a strategic approach in software development where a shared
architecture is created to serve as the foundation for developing a series of related software products. It
emphasizes reuse and scalability, catering to a family of products within a specific domain, enabling
organizations to efficiently create customized solutions.

Key Concepts of PLA

1. Core Architecture
o A single, shared architecture forms the foundation of all products in the product line.
o Encapsulates common functionalities, ensuring uniformity and reducing duplication.
2. Variability Management
o PLA incorporates mechanisms to handle variations across products in the family.
o Features are designed to be configurable or extensible to meet diverse requirements.
3. Domain Engineering
o Focuses on identifying and designing reusable components within a specific domain.
o Core assets such as libraries, frameworks, and tools are developed during this phase.
4. Application Engineering
o Involves customizing and integrating core assets to develop individual products.
o Leverages the reusable architecture to reduce time-to-market.

Advantages of Product Line Architecture

1. Reusability
o Promotes reuse of core components, leading to reduced development time and costs.
2. Consistency Across Products
o Ensures uniform design and quality across the product family.
3. Faster Time-to-Market
o Speeds up the development process for new products by utilizing existing assets.
4. Reduced Maintenance Effort
o Shared components minimize redundancy, making updates and fixes easier.
5. Scalability and Extensibility
o Facilitates the addition of new features or products without reworking the core architecture.
Challenges of Product Line Architecture
1. High Initial Investment
o Requires significant effort and resources to develop the initial core architecture.
2. Complexity in Managing Variability
o Balancing commonality and variability can be challenging, especially as the product family
grows.
3. Dependency Management
o Shared components increase inter-product dependencies, which may complicate updates or
bug fixes.
4. Skill Requirements
o Demands skilled architects to design a robust, reusable core.

PLA Design Example

Consider a company creating a suite of e-commerce platforms (e.g., websites for retail, wholesale,
and subscriptions).
 Core Components: User authentication, payment gateway, and product catalog.
 Variability:
o Retail: Single-item purchases.
o Wholesale: Bulk discounts and inventory management.
o Subscription: Recurring payment support.

UNIT III
19. Quality attributes of software
 Quality attributes are an essential part of the nonfunctional requirements of a system. It is
the responsibility of system analysts to put together a complete list of quality attributes
before the detailed design process can begin.
 For most computer systems, quality attributes often include:
1. Efficiency
Time Efficiency:
 Refers to how quickly the system performs tasks. Optimized architectural patterns reduce
execution time, ensuring timely responses to user requests.
 Example: Using caching mechanisms or load balancing to reduce response times in web
applications.
Resource Economy:
 Efficient use of hardware and software resources, such as memory, CPU, and network
bandwidth.
 Example: Lightweight frameworks reduce resource overhead in embedded systems.
2. Functionality
Completeness:
 The architecture should ensure that the software fulfills all specified functional requirements
without omissions.
 Example: E-commerce software should support user authentication, payment processing, and
order tracking.
Security:
 Incorporates mechanisms to protect against unauthorized access, data breaches, and
cyberattacks.
 Example: Secure architectural components like firewalls, encryption, and authentication
protocols.
Interoperability:
 Ensures that the system can interact seamlessly with other systems or components, even from
different vendors.
 Example: APIs and microservices enable communication between diverse systems.
3. Maintainability
Expandability:
  The ability to add new features or functionality with minimal impact on the existing
architecture.
 Example: Plug-in architectures in software like browsers support easy integration of new
features.
Modifiability:
 Simplifies modifications, whether for updates, fixes, or changes in requirements.
 Example: Layered architectures isolate changes to specific modules.
Testability:
 Ensures that individual components can be tested independently and comprehensively.
 Example: Modular architectures facilitate unit testing of individual components.
4. Portability
Hardware Independence:
 The architecture should enable the software to run on different hardware platforms without
modification.
 Example: Virtual machines allow software to run on various devices regardless of underlying
hardware.
Software Independence:
 The ability to operate across diverse operating systems or middleware.
 Example: Cross-platform frameworks like Java or .NET Core.
Installability:
 Simplicity and reliability of the installation process, ensuring that the software can be
deployed efficiently on different systems.
 Example: Containerized deployments using Docker.
Reusability:
 Architectural components should be reusable across different projects or systems.
 Example: Shared libraries or frameworks.
5. Reliability
Error Tolerance:
 The system’s ability to continue functioning in the presence of faults or errors.
 Example: Fault-tolerant architectures with redundancy or backup mechanisms.
Availability:
 Ensures the system remains operational and accessible to users with minimal downtime.
 Example: High-availability architectures with failover support.
6. Usability
Understandability of Code:
 Ensures that the code structure is clear and easy for developers to comprehend and maintain.
 Example: Well-documented and modular codebases.
User Interface:
 Focuses on creating an intuitive and user-friendly front-end experience.
 Example: Consistent design patterns and responsive interfaces.
Learnability:
 The ease with which users can learn to interact with the software effectively.
 Example: Architectures supporting comprehensive onboarding or help systems.

20. Architecture in agile projects

 Traditional software architecture designs, fundamentally based on a waterfall model (a linear
process without integrating feedbacks), do not emphasize the iterative refinement nature and
do not use element and connector attributes to capture the key architecture requirements of a
software project.
 As a result, there is big gap between a project's requirement specification and a concrete
software architecture for its detailed design and implementation.
 Another weak point of traditional architecture design is that if the deployment environment
changes, which is happening more often with the economy's globalization, the architecture
design must start from scratch.
 Agile Software Development is a software development methodology that values flexibility,
collaboration, and customer satisfaction. It is based on the Agile Manifesto, a set of principles
for software development that prioritize individuals and interactions, working software,
customer collaboration, and responding to change.
 Agile Software Development is an iterative and incremental approach to software
development that emphasizes the importance of delivering a working product quickly and
frequently. It involves close collaboration between the development team and the customer to
ensure that the product meets their needs and expectations.
 Requirements Gathering: The customer’s requirements for the software are gathered and
prioritized.
 Planning: The development team creates a plan for delivering the software, including the
features that will be delivered in each iteration.
 Development: The development team works to build the software, using frequent and rapid
iterations.
 Testing: The software is thoroughly tested to ensure that it meets the customer’s
requirements and is of high quality.
 Deployment: The software is deployed and put into use.
 Maintenance: The software is maintained to ensure that it continues to meet the customer’s
needs and expectations.