Key Points on Software Engineering

1. Definition
o Software engineering is the discipline that deals with all aspects of software production,
from initial system specification to post-deployment maintenance.
2. Engineering Discipline
o Engineers apply established theories, methods, and tools where applicable.
o They explore innovative solutions when existing methods do not fit the problem.
o Work is done within real-world constraints like budget, time, and organizational policies.
3. Scope of Software Production
o Covers technical processes like coding, testing, and debugging.
o Includes non-technical aspects like project management, requirement analysis, and quality
assurance.
o Involves developing tools, frameworks, and methodologies to improve software
development.
4. Systematic and Organized Approach
o Ensures efficiency, reliability, and maintainability of software.
o Structured methodologies like Agile, Waterfall, and DevOps guide development.
o Software engineers choose the best approach based on project needs.
5. Flexibility in Development
o Not all projects require a rigid, structured process.
o Creative and adaptive methods are useful for specific types of applications.
o Web-based systems require a mix of software and graphical design skills.

Detailed Comparison Between Software Engineering and Computer Science

Aspect Software Engineering Computer Science

The discipline of designing, developing,
The study of algorithms, data structures,
1. Definition testing, and maintaining software
and computational theory.
systems.
Solving practical problems related to
Understanding the fundamental principles
2. Focus software development and project
of computation and software design.
management.
Applies engineering principles to build
Uses mathematical and theoretical models
3. Approach efficient, scalable, and maintainable
to analyze and optimize computations.
software.
Software development, system
Algorithms, complexity theory, artificial
4. Key Areas architecture, testing, deployment, and
intelligence, and distributed computing.
maintenance.
Formal methods, automata theory,
5. Methodologies Agile, Waterfall, DevOps, Scrum for
computational models for problem-
Used managing projects and development.
solving.
Theoretical computing models,
6. Tools & Programming languages (Java, Python,
programming language design,
Technologies C++), IDEs, frameworks, databases.
cryptographic algorithms.
What is Software?
Software includes not just computer programs but also documentation, configuration data, and
materials needed to make programs work properly. It consists of:
• Programs: The actual software that runs.
• Documentation: System and user guides.
• Configuration Data: Settings to operate the software.
• Websites: For updates and product info.
Types of Software Products:
1. Generic Products: Stand-alone software sold to any customer (e.g., word processors, databases).
2. Customized Products: Tailored software developed for specific customers (e.g., control
systems, business-specific tools).

Difference Between Software Engineering and System Engineering:

• System Engineering: Focuses on designing and managing entire complex systems, including
hardware, processes, and software. System engineers integrate all parts to create the final system.
• Software Engineering: Focuses on developing and maintaining software. It involves designing,
coding, testing, and ensuring software works correctly within a system.
• System engineering is broader and older, while software engineering is more specific to software
development.
Example:
For building a smartphone:
• System Engineering: Oversees the design of the entire phone, including hardware (screen,
battery, etc.) and software (apps, operating system). They ensure everything works together.
• Software Engineering: Focuses on writing the code for the phone’s software, like the operating
system and apps, ensuring they function properly.

What is a software process?

A software process refers to the structured sequence of activities and results required to create a
software product. The process includes four fundamental activities that are common across all software
development projects:

1. Software Specification: This is the initial phase where the customer and engineers work together
to define the software's requirements, as well as any operational constraints. The goal is to
understand what the software should do and under what conditions.
2. Software Development: In this phase, the actual software is designed, developed, and coded. It
involves creating the architecture and programming the system to meet the specifications defined
earlier.
3. Software Validation: Once the software has been developed, it needs to be validated. This
means checking and testing the software to ensure it meets the specified requirements and
performs as expected.
4. Software Evolution: Software often needs to be updated or modified after initial release to
accommodate new requirements, fix bugs, or improve performance. The evolution process
ensures the software remains useful and relevant over time as customer needs or market
conditions change.
Example using an online shopping platform:

1. Software Specification: The customer defines the need for an online shopping site with features
like product search, user accounts, and secure payment.
2. Software Development: Engineers design and build the website, coding the front end, back end,
and integrating payment systems.
3. Software Validation: The platform is tested to ensure it works as required—checking features
like checkout, security, and user experience.
4. Software Evolution: After launch, the platform is updated based on user feedback and changing
market needs, such as adding new payment options or improving search functionality.

What is a software process model?

A software process model is a simplified view of a software process, depicting the activities, software
products, and roles involved in software engineering. It helps to visualize how the process works. Some
common types of software process models include:
1. Workflow Model: Shows the sequence of activities and their inputs, outputs, and dependencies,
often representing human actions.
2. Dataflow or Activity Model: Represents the process as a series of activities that transform data,
showing how inputs (e.g., specifications) are turned into outputs (e.g., design).
3. Role/Action Model: Focuses on the roles of people involved and the activities they are
responsible for.
There are three primary paradigms of software development:
1. Waterfall Model: Activities like requirements specification, design, and testing are handled in
distinct, sequential phases, with each phase signed off before moving to the next.
2. Iterative Development: Involves rapidly developing an initial version from abstract
specifications, then refining it based on customer feedback until a satisfactory system is created.
3. Component-Based Software Engineering (CBSE): Focuses on integrating pre-existing
software components rather than building everything from scratch.
These models provide structured approaches to managing software development.

What are the attributes of good software?

Good software is characterized by a set of attributes that reflect its quality and behavior during
execution, as well as the structure of its code and documentation. These attributes are often referred to
as non-functional attributes and include:

1. Maintainability: The software should be easy to modify and update to meet changing customer
needs or fix issues, as software change is inevitable.
2. Dependability: This encompasses reliability, security, and safety. Dependable software should
not cause harm, whether physical or economic, during system failures.
3. Efficiency: Software should make optimal use of system resources (memory, processing time),
ensuring that it operates swiftly and with minimal resource consumption.
4. Usability: The software should be user-friendly, with an intuitive interface and adequate
documentation, enabling users to interact with it easily and effectively.

Additional attributes depend on the specific application, such as security for banking systems,
responsiveness for interactive games, and reliability for telephone switching systems. These attributes
ensure that the software functions well in its environment and serves its intended purpose efficiently.
Software engineering faces three key challenges :
1. Heterogeneity Challenge: Modern systems are often distributed across various networks and
different types of computers. Additionally, they need to integrate with legacy systems that may
use different programming languages. The challenge is to create dependable software that is
flexible enough to handle this complexity and support diverse systems.
2. Delivery Challenge: Traditional software engineering methods are time-consuming, which can
hinder rapid software delivery. However, businesses today need to be agile and responsive. The
challenge is to shorten the delivery time for large, complex systems without compromising on
quality.
3. Trust Challenge: As software becomes increasingly embedded in all aspects of life, it must be
trustworthy, particularly for remote systems accessed via the web. The challenge is to develop
techniques to ensure software can be trusted by its users, especially in critical areas like security
and reliability.
These challenges often overlap, such as the need to rapidly modify legacy systems to accommodate
new functionalities like web service interfaces. Addressing these requires new tools, techniques, and
innovative ways to combine existing methods.

Professional and Ethical Responsibility in Software Engineering:

Software engineers must uphold not only technical standards but also ethical and professional
responsibilities. This includes respecting confidentiality, ensuring competence, protecting intellectual
property, and avoiding misuse of technology. Their roles go beyond just applying technical skills, and
they must act in ways that contribute to the public good and maintain the integrity of the profession.
Some key ethical considerations include:
1. Confidentiality: Software engineers must respect the confidentiality of clients and employers,
even if no formal agreement exists.
2. Competence: Engineers should not misrepresent their expertise and should avoid accepting tasks
beyond their capabilities.
3. Intellectual Property Rights: Engineers must adhere to laws regarding patents and copyrights
and protect the intellectual property of their employers or clients.
4. Computer Misuse: Engineers should avoid using their skills for unethical purposes, from trivial
matters like gaming on work systems to serious offenses like distributing viruses.

The Software Engineering Code of Ethics and Professional Practice, developed by the ACM/IEEE-
CS Joint Task Force, lays out guidelines for software engineers to follow in order to maintain ethical
standards in their profession. Here’s a breakdown of the Eight Principles:
1. PUBLIC – Software engineers must act in a manner that prioritizes the public interest, ensuring
that their work does not harm the public and contributes positively to society.
2. CLIENT AND EMPLOYER – Engineers must act in the best interests of their clients and
employers, as long as those actions are consistent with the public interest.
3. PRODUCT – The software produced must meet the highest possible professional standards. This
includes ensuring quality, safety, and effectiveness in their work.
4. JUDGMENT – Engineers should maintain integrity and independence in their professional
decisions, free from bias or influence that could compromise their judgment.
5. MANAGEMENT – Managers in software engineering must promote ethical practices and adopt a
responsible approach to software development and maintenance.
6. PROFESSION – Engineers should contribute to advancing the integrity and reputation of the
software engineering profession, fostering respect and trust within and outside the field.
 7. COLLEAGUES – Engineers must be fair to their colleagues, supporting them and contributing to
a positive, collaborative work environment.
8. SELF – Engineers should commit to continuous learning and self-improvement in their profession
and promote ethical behavior in all their professional endeavors.
These principles are designed to guide software engineers in making decisions that align with the
broader social good, uphold the integrity of the profession, and contribute to a positive and productive
working environment. The code encourages engineers to act ethically and responsibly in all their
professional activities.

CASE stands for Computer-Aided Software Engineering. It refers to a set of software tools designed
to assist software engineers in various activities throughout the software development process. These
tools help automate and streamline tasks, making the development process more efficient and
consistent.
Some key features of CASE tools include:
• Editors for Method Notations: These tools help software engineers create and edit models and
diagrams that follow specific notations used in software engineering methods (e.g., Unified
Modeling Language, UML).
• Analysis Modules: CASE tools often come with modules that check system models for correctness
and consistency, ensuring that the model adheres to the rules and guidelines of the chosen method.
• Report Generators: These tools help generate system documentation automatically, which is an
essential part of maintaining and understanding software projects.
• Code Generators: Some CASE tools can generate source code directly from the system models,
saving time in the coding phase and reducing errors.
• Process Guidance: CASE tools may offer guidance and best practices for software engineers,
helping them follow established workflows and methodologies.
In essence, CASE tools aim to enhance the productivity and effectiveness of software engineers by
automating routine tasks, ensuring consistency, and supporting various stages of the software
development lifecycle.

System

A system is a collection of interconnected components that function together to achieve a specific

objective. It can consist of hardware, software, people, processes, and rules depending on its type and
complexity.

Two Categories of Systems

1. Technical (Computer-based) Systems
These systems are composed of hardware and software and operate without involving people or
processes.
o Examples:
▪ Televisions: Work using hardware (screen, circuits) and software (image processing
algorithms).
▪ Mobile phones: Combine hardware (camera, screen) and software (apps, operating system)
for communication.
▪ ATMs: Include hardware (keypad, cash dispenser) and software (banking applications) for
financial transactions.
2. Socio-technical Systems
These systems combine hardware, software, people, processes, and rules to achieve broader goals.
They are typically more complex and adaptive.
o Example: E-commerce platform
▪ Technical Components: Websites, apps, databases, payment systems.
▪ People: Customers, sellers, support staff, delivery personnel.
▪ Processes: Steps for browsing, ordering, paying, shipping, and returning items.
▪ Rules: Policies such as consumer protection laws, refund guidelines, and privacy regulations.

Main Characteristics of Socio-technical Systems

Emergent Properties
Emergent properties are characteristics or behaviors that arise only when all parts of the system work
together as an integrated whole. These properties cannot be attributed to any individual component.
• Example: A fully operational car results from the combined functionality of its engine, wheels,
electronics, and safety systems.
Types of Emergent Properties:
1. Functional Properties:
o These properties describe the system’s ability to perform its intended tasks.
o Example: An air conditioning system’s ability to regulate room temperature by combining
sensors, a compressor, and airflow mechanisms.
2. Non-functional Properties:
o These describe the system's performance and usability in real-world conditions.
o Examples:
▪ Reliability: The ability to consistently deliver expected results.
▪ Performance: Speed, responsiveness, and efficiency of the system.
▪ Safety: The system’s ability to prevent harm to users or the environment.
▪ Security: Measures to protect data and functionality from unauthorized access or
damage.

Key System Properties

1. Volume
o The sound output of speakers can vary based on their placement and room acoustics,
highlighting the impact of the environment on system performance.
2. Reliability
o The system must function correctly under specified conditions. Failures in component
interactions (e.g., an overheated engine affecting air conditioning in a car) can undermine
reliability.
Three Types Of Reliability:
Hardware Reliability:
• Measured as the probability of hardware failing and the time required to repair it.
Software Reliability:
• Software reliability is about how dependable a software is. It means the software can do its job
correctly without breaking or failing, even when used over time.
Eg: Weather Forecasting
Operator Reliability:
• Operator reliability refers to how consistently and accurately a human or automated operator can
perform their tasks in a system without errors.
 3. Repairability
o Systems should be designed to make fixing problems straightforward, minimizing downtime.
4. Usability
o A system should be intuitive and easy to use, minimizing the learning curve for users.
5. Security
o Security encompasses all components working together to protect the system.
o Example: Smartphones use passwords, fingerprint recognition, encryption, and firewalls to
ensure data safety.

Challenges in Designing Socio-technical Systems

1. Integration
o Ensuring smooth interaction between technical and human components.
2. Complexity
o Managing multiple interdependent processes and rules.
3. Scalability
o Adapting the system to handle growth in users, data, or processes.
4. Ethics and Privacy
o Balancing functionality with user privacy and ethical considerations.

The systems engineering process

Systems engineering is the activity of specifying, designing, implementing, validating, deploying and
maintaining socio-technical systems

Requirements Definition:
System Requirements Definition is the process of identifying and specifying what a system should do
(its functions) and its essential and desirable properties.
1. Abstract Functional Requirements: Defines basic system functions at a high level. Example: A
flight-plan database in air traffic control systems.
2. System Properties: Specifies non-functional aspects like performance, safety, and availability.
3. Characteristics the System Should Not Exhibit: Defines what the system must avoid. Example:
The system should not overload the user with excessive information.
4. Objective Setting: States the goals of the system, such as ensuring minimal disruption in case of
fire or intrusion, beyond just its functionality.
5. Stakeholder Consultation: System requirements are created by consulting with customers, users,
and engineers from various disciplines.
System Design:

System Design focuses on how to implement the system's functionality through its components. The
key activities are:
1. Partition Requirements: Analyze and organize requirements into related groups, considering
multiple partitioning options.
2. Identify Sub-systems: Identify sub-systems that can fulfill the grouped requirements. This may
also be influenced by organizational or environmental factors.
3. Assign Requirements to Sub-systems: Allocate requirements to the identified sub-systems,
although real-world constraints may require adjustments.
4. Specify Sub-system Functionality: Define the specific functions that each sub-system will
perform in the system design.
5. Define Sub-system Interfaces: Specify the interfaces that each sub-system provides and requires.
Once the interfaces are agreed upon, it allows for parallel development of the sub-systems.

System Modelling:
System Architecture Model:
During the system requirements and design activity, systems are modeled as a set of components and
the relationships between them. These are typically illustrated in a system architecture model, which
gives an overview of the system’s organization.
This model is usually presented as a block diagram, where:
• Each sub-system is represented as a rectangle.
• Relationships between sub-systems are shown using arrows. These relationships can include:
o Data flow: Indicates the movement of data between sub-systems.
o 'Uses'/'Used by' relationship: Shows how sub-systems depend on each other.
o Other types of dependency relationships can also be shown.
The system architecture model helps to visualize how the different sub-systems interact with each
other and provides a clear representation of the overall system organization. This graphical
representation simplifies the understanding of the system's structure and the dependencies between its
components.

Sub-system development
In the sub-system development phase, the sub-systems designed earlier are built. This may involve
developing custom components or using commercial off-the-shelf (COTS) products, which are
usually cheaper but may require design adjustments.
Key points:
1. COTS products may not fully meet requirements, leading to redesigns.
2. Sub-systems are developed in parallel, but issues may arise between them.
3. Changes after manufacturing are costly, so work-arounds (often software fixes) are used.
4. Designing software for flexibility helps manage changes without high costs.
Systems Integration :
It involves combining independently developed sub-systems to form a complete system.
Key points:
1. Incremental integration is preferred over the "big bang" approach because:
• It’s difficult to finish all sub-systems at once.
• It makes error detection easier since issues can be traced to the newly integrated sub-system.
2. Once integrated, a system testing phase ensures all components work together, focusing on
interfaces and overall system behavior.
3. Integration issues often arise due to faulty assumptions about how sub-systems interact, leading to
disputes between contractors responsible for different sub-systems.
4. As more systems use COTS components, integration becomes more critical, sometimes blending
with the implementation phase.
In simpler terms, integration is about bringing all sub-systems together and testing them to ensure the
complete system works smoothly.

System Evolution refers to the ongoing changes made to a system throughout its lifetime to fix errors,
add new features, or adapt to external changes.
Key points:
1. Reasons for Evolution:
• Correcting errors: Changes may be required to fix issues in the original system.
• New requirements: As time passes, new needs may arise.
• Technological upgrades: Systems may need updates to support newer hardware or software.
• Organizational or environmental changes: Changes in the way an organization works or
external factors may require system updates.
2. Challenges of System Evolution:
• Changes need to be carefully analyzed for both business and technical alignment.
• Changes to one sub-system can impact others, requiring further modifications.
• The reasons for initial design choices might not be documented, complicating the evolution
process.
• As systems age, their structure may deteriorate, increasing the difficulty and cost of changes.
3. Legacy Systems:
• Evolved systems that rely on outdated technology but are still critical to an organization are
called legacy systems. Replacing them can be risky but may eventually be necessary.

System Decommissioning :
It refers to the process of taking a system out of service once it has reached the end of its useful
operational life.
Key points:
1. For hardware systems:
• Involves disassembling the system and recycling materials or safely disposing of any toxic
substances.
2. For software:
• No physical decommissioning, but it may help with monitoring hardware components during the
decommissioning.
• Some software may assist in identifying reusable components for other systems.
3. Handling data:
• If data from the old system is still valuable, it may need to be converted to be used by a new
system.
• This requires analyzing the data structure, understanding how it is organized, and writing programs
to reorganize it for the new system.

Legal System:
Legacy Systems are older, complex systems that continue to be used because they are critical to
business operations. They often include outdated hardware, software, and business processes that
are difficult to change.

Key characteristics:
1. Long lifespan: Legacy systems often have a long operational life (e.g., military or air traffic
control systems), and replacing them is expensive and risky.
2. Business-critical: These systems are vital for business operations, such as banking systems that
track customer accounts.
3. Components of Legacy Systems:
o System hardware: Older hardware that may no longer be available or compatible with
current technologies.
o Support software: Outdated software tools (e.g., operating systems or compilers) that are no
longer supported.
o Application software: The specific programs that carry out business operations, often
developed over time and composed of separate parts.
o Application data: Large volumes of data accumulated over time, often inconsistent or
duplicated.
o Business processes: Processes in the business world that depend on the legacy system's
functionality (e.g., issuing insurance policies).
o Business policies and rules: The organizational rules and policies that often rely on the legacy
system.

Legacy systems are often seen as layers of interdependent components, where each layer depends on
the one below it. This interdependence makes changes or upgrades challenging without affecting the
system as a whole.

System Dependability
System dependability is the ability of a system to deliver its intended function reliably and safely
while maintaining security. It ensures that users can trust the system to operate as expected under
different conditions.
Dependability encompasses several key attributes:
• Availability
• Reliability
• Safety
• Security
Key Aspects of Dependability
• Fault Tolerance: The system continues to function despite minor failures.
• Error Handling: It detects and corrects errors before they cause failures.
• Maintainability: The system should be easy to update and repair.
Example
An air traffic control system must be dependable to prevent accidents. If one component fails, the
system should automatically switch to a backup.

2. Availability
Availability is the probability that a system is operational and accessible when needed. It is usually
expressed as a percentage, such as 99.99% uptime (meaning the system is down for only a few
minutes per year).
Factors Affecting Availability
• System Downtime: The amount of time the system is non-functional.
• Redundancy: Having backup components to ensure continuous operation.
• Recovery Time: How quickly the system restores after failure.
Example
A cloud storage service (e.g., Google Drive, Dropbox) ensures high availability by using multiple
servers worldwide. Even if one server fails, another takes over.

3. Reliability (5 Marks)
Reliability refers to the likelihood that a system will function without failure for a specific time period.
A reliable system has fewer breakdowns and requires less frequent repairs.
How to Improve Reliability
• Testing and Debugging: Finding and fixing issues before release.
• Robust Software Design: Using well-tested algorithms and structures.
• Predictive Maintenance: Monitoring for potential failures before they happen.
Example
A medical ventilator used in hospitals must work continuously without failure, as even a short
malfunction can endanger lives.

4. Safety (5 Marks)
Safety ensures that a system does not cause harm to people, the environment, or assets. It is crucial
in critical systems where failure could lead to serious consequences.
Factors Affecting Safety
• Risk Assessment: Identifying possible dangers.
• Fail-Safe Mechanisms: Ensuring the system stops working in a safe way during failure.
• Regulatory Compliance: Following industry safety standards.
Example
A nuclear power plant control system must ensure that even in the event of a failure, radiation leaks
do not occur.

5. Security (5 Marks)
Security protects a system from unauthorized access, data breaches, and cyber threats. It ensures
confidentiality, integrity, and availability of data.
Key Aspects of Security
• Authentication: Ensuring only authorized users can access the system.
• Encryption: Protecting data by converting it into unreadable code.
• Firewall & Intrusion Detection: Preventing hackers from entering the system.
Example
An online banking system uses multi-factor authentication (MFA) and encryption to prevent fraud and
unauthorized transactions.

Software Process Models

Software process models provide a structured approach to developing software by defining the steps,
phases, and methodologies used throughout the development lifecycle. Different models suit
different types of projects based on their complexity, requirements, and risks.

1. Waterfall Model
The Waterfall Model is a sequential software development approach where each phase must be fully
completed before moving to the next.
Phases:
1. Requirements Analysis – Understanding customer needs.
2. System Design – Creating software architecture.
3. Implementation – Writing the actual code.
4. Testing – Identifying and fixing defects.
5. Deployment & Maintenance – Installing the software and updating it when needed.
Advantages:
• Simple and easy to manage.
• Best for well-defined projects.
Disadvantages:
• Not flexible; difficult to accommodate changes later.
 • No working software is available until late in the process.
2. Incremental Model
Software is developed and delivered in multiple small parts (increments) rather than as a whole
system at once.

Phases:
1. Develop a basic version with core functionality.
2. Add features in small incremental releases.
3. Incorporate user feedback at each stage.
Advantages:
• Early delivery of working software.
• Easier to handle changing requirements.
Disadvantages:
• Requires good planning and design.
• Might lead to inconsistent system architecture.
3. Spiral Model
The Spiral Model combines risk management with iterative development. Each cycle of the spiral
represents a new version of the software, improving with each iteration.

Phases:
1. Planning & Risk Analysis – Identify potential risks.
2. Prototype Development – Build a small version for testing.
3. Evaluation & Feedback – Gather user input.
4. Final Development – Implement full features.
Advantages:
• Best for high-risk projects requiring careful risk management.
• Allows continuous user feedback and refinement.
Disadvantages:
• Expensive and time-consuming.
• Requires expert risk assessment.
4. Agile Model
Definition:
The Agile Model focuses on rapid and flexible software development through continuous iterations
and customer collaboration.

Principles:
1. Iterative Development: Software is delivered in small cycles (sprints).
2. Customer Collaboration: Regular feedback is gathered and implemented.
3. Adaptability: Changes can be made at any stage.
Advantages:
• Faster delivery of working software.
• Better customer satisfaction due to regular updates.
Disadvantages:
• Requires high user involvement.
• Hard to predict costs and timelines.
5. Scrum Model (Agile Framework)
Scrum is an Agile framework that organizes development into short sprints (2-4 weeks), with a focus
on team collaboration and adaptability.

Phases:
1. Sprint Planning: The team selects tasks to complete in the sprint.
2. Daily Standup Meetings: Quick updates on progress and obstacles.
3. Sprint Review: Demonstrating the completed work to stakeholders.
4. Sprint Retrospective: Analyzing what went well and what needs improvement.
Advantages:
• Encourages teamwork and transparency.
• Delivers working software frequently.
Disadvantages:
• Requires experienced teams for effective execution.
• Can be difficult to manage large teams

Process Iteration
Process iteration refers to the repetition of development activities to improve a software system.
Instead of following a strict sequence, iteration allows revisiting and refining earlier phases based on
feedback, changing requirements, or detected issues.
Importance of Process Iteration
Accommodates Requirement Changes: Software requirements evolve due to market trends or user
feedback. Iteration ensures that changes can be incorporated without restarting the entire project.
• Enhances Software Quality: Continuous testing and improvements result in a more stable and
bug-free system.
• Reduces Project Risks: Early detection of design flaws or technical issues prevents costly fixes
later.
• Encourages User Involvement: Regular feedback from users helps ensure the software meets
their needs.

Types of Process Iteration (4 Marks)

A. Incremental Development
• The system is built and delivered in small increments, rather than as a single product.
• Each iteration adds new functionality, allowing users to provide feedback.
• Example: Developing an e-commerce website, starting with basic product listings, then adding
cart functionality, and later integrating payment gateways.

B. Evolutionary Development
• A working prototype is built quickly and improved through multiple iterations.
• Helps when requirements are unclear or constantly changing.
• Example: Mobile app development, where frequent updates introduce new features based on
user reviews.
C. Spiral Model
• Combines iterative development with risk analysis.
• Each iteration includes planning, risk assessment, prototype development, and testing.
• Example: Developing AI-driven systems, where continuous learning and refinements are
needed.
Challenges of Process Iteration
Increased Complexity: Managing frequent iterations requires strong version control and effective
team coordination.
• Higher Costs: Multiple cycles of development and testing may increase project expenses.
• Risk of Scope Creep: Continuous iterations without proper control can lead to never-ending
development.
Process Activities
Process activities refer to the key steps involved in software development. These activities help
ensure that software is developed systematically, efficiently, and meets user needs.

Four Fundamental Process Activities

A. Software Specification (Requirements Engineering)

Defines what the system should do and the constraints under which it must operate.
• Includes:
o Requirement gathering (meeting with clients, surveys, and research).
o Requirement documentation (functional & non-functional specifications).
o Requirement validation (ensuring clarity, completeness, and feasibility).
• Example: A company developing an e-commerce website specifies that it must allow users to
browse products, add them to a cart, and process payments securely.
B. Software Design and Implementation

• Focuses on translating requirements into an actual working system.

• Includes:
o System architecture design (defining software structure and components).
o UI/UX design (creating user interfaces for better interaction).
o Coding & development (writing, debugging, and integrating code).
• Example: Designing a database structure for an online banking system and implementing the
transaction processing functionality.
C. Software Validation
• Ensures that the software meets the requirements and functions correctly.
• Includes:
o Unit testing (testing individual components).
 o Integration testing (ensuring components work together).
o System testing (validating the entire system’s functionality).
• Example: A mobile app company tests its app for bugs, crashes, and user experience issues
before launching it.
D. Software Evolution
Software must be updated, maintained, and improved over time.

• Includes:
o Bug fixing (resolving reported issues).
o Feature updates (adding new functionalities).
o Performance optimization (improving speed and efficiency).
• Example: WhatsApp frequently releases updates to fix security vulnerabilities and introduce
new features like disappearing messages.

Project Management
Project management ensures efficient planning, execution, and control of software development
projects. Each of the following aspects plays a crucial role in delivering successful software within
scope, budget, and timeline.

1. Management Activities
Management activities refer to the key tasks that help plan, monitor, and control software projects.
These activities ensure projects are completed on time, within budget, and with the required quality.
Key Management Activities:
1. Proposal Writing – Creating detailed project proposals, cost estimates, and schedules.
2. Project Planning – Defining project goals, resources, and timelines.
3. Project Scheduling – Assigning tasks, estimating timelines, and tracking progress.
4. Risk Management – Identifying potential risks and preparing mitigation strategies.
5. Progress Monitoring – Regularly checking project status and making adjustments as needed.
Example:
A software development company working on an e-commerce website tracks the project timeline
weekly to ensure it meets deadlines.

2. Project Planning
Project planning involves defining project scope, estimating resources, and identifying milestones to
ensure smooth execution.
Steps in Project Planning:
1. Defining Objectives: Setting clear project goals and expected outcomes.
2. Work Breakdown Structure (WBS): Dividing the project into smaller, manageable tasks.
3. Resource Allocation: Assigning personnel, budget, and tools for development.
4. Identifying Constraints: Understanding limitations such as time, budget, and team size.
5. Developing a Risk Plan: Listing potential issues and how to handle them.
Example:
A mobile banking app project defines key deliverables: user authentication, transaction processing,
and security testing.

3. Project Scheduling
Project scheduling is the process of organizing tasks, setting deadlines, and assigning responsibilities
to ensure timely project completion.
Techniques Used for Scheduling:
1. Gantt Charts: A visual timeline showing task dependencies.
2. Critical Path Method (CPM): Identifies the longest sequence of dependent tasks.
3. PERT (Program Evaluation and Review Technique): Estimates task duration using probability
analysis.
4. Milestone Tracking: Setting key checkpoints to measure progress.
5. Resource Scheduling: Assigning the right number of developers, testers, and designers.
Example:
A software company developing a healthcare management system sets task deadlines for UI/UX
design, backend development, and testing to ensure delivery within 6 months.

4. Risk Management
Risk management is the process of identifying, analyzing, and mitigating potential risks that could
impact project success.
Steps in Risk Management:
1. Risk Identification: Listing potential risks (e.g., budget overruns, staff turnover).
2. Risk Assessment: Analyzing the probability and impact of each risk.
3. Risk Mitigation Planning: Developing strategies to reduce risks.
4. Risk Monitoring: Regularly tracking risks throughout the project lifecycle.
5. Contingency Planning: Preparing backup plans in case of failure.
Example:
A startup developing an AI chatbot anticipates delays in data collection and prepares alternative data
sources as a risk mitigation strategy.

Software Requirements
Software requirements define what a software system must do to meet user needs. They are
documented in a Software Requirements Specification (SRS), which serves as an official guide for
developers.
Software Requirements
Software requirements are the functional and non-functional characteristics a system must fulfill.
Types of Software Requirements:
1. Functional Requirements – Define specific actions a system must perform.
o Example: An ATM must allow users to withdraw cash.
2. Non-Functional Requirements – Define system properties like performance, security, and
usability.
o Example: The ATM must process transactions within 3 seconds.
3. User Requirements – High-level system requirements written for end users.
4. System Requirements – Detailed specifications for developers on how the system should work.
Importance of Software Requirements:
✔ Ensure that developers build the right product.
✔ Help in estimating cost, time, and resources.
✔ Reduce misunderstandings between stakeholders and developers.

Software Requirements Specification (SRS)

An SRS document defines the functional and non-functional requirements of a software system. It
serves as a contract between stakeholders, developers, and testers to ensure project clarity.
Structure of an SRS Document
A well-written SRS document follows a standardized structure to ensure clarity and completeness.
1. Introduction
• Purpose – Describes why the software is being developed.
• Scope – Defines what the software will cover and its limitations.
• Definitions & Acronyms – Provides explanations of technical terms.
• References – Lists related documents, standards, and resources.
Example:
For a Library Management System, the introduction might specify that the system will track book
inventory, manage user memberships, and handle book loans and returns.

2. Overall Description
• Product Perspective – Explains how the new system fits into existing infrastructure.
• User Characteristics – Defines who will use the system (e.g., librarians, students, etc.).
• System Constraints – Identifies hardware, network, or regulatory limitations.
Example:
For an E-commerce Website, the system must be compatible with Windows, Mac, and mobile devices
while ensuring high-speed performance.

3. Functional Requirements
• Specifies features and functionalities the system must support.
• Each function is clearly defined with input, output, and behavior.
Example:
For an Online Banking System, functional requirements may include:
1. Login System: "The system shall authenticate users using a username and password."
2. Fund Transfer: "Users should be able to transfer money between accounts securely."
4. Non-Functional Requirements
• Defines the quality attributes of the system, such as:
o Performance: Response time, system speed.
o Security: Data encryption, authentication methods.
o Usability: Ease of use, accessibility.
o Reliability: System uptime percentage.
Example:
For a Hospital Management System, a non-functional requirement could be:
• "The system should process patient records within 2 seconds of retrieval."

5. External Interface Requirements

• Describes how the system will interact with hardware, software, databases, and external APIs.
Example:
For a Chat Application, it may specify integration with SMS gateways to send notifications.

6. Assumptions & Dependencies

• Lists any external factors that could affect system performance, such as:
o Dependence on third-party software or APIs.
o Hardware constraints (e.g., only works on Android OS).
3. Importance & Benefits of SRS
✔ Prevents Miscommunication: Reduces misunderstandings between developers and clients.
✔ Ensures Software Quality: Sets clear expectations, leading to better software design.
✔ Improves Maintenance & Scalability: Serves as a reference for future upgrades and debugging.
✔ Aids in Testing & Validation: Helps testers verify that all requirements are met before deployment.

4. Example of an SRS Document

Here is a sample SRS outline for an Online Ticket Booking System:
1. Introduction
• Purpose: To provide users a way to book tickets online.
• Scope: The system will allow users to search for events, book tickets, and process payments.
2. Overall Description
• Users: General customers, event organizers, and administrators.
• Constraints: The system should be available 24/7 and handle high traffic during peak times.
3. Functional Requirements
• Users must be able to search for events based on date and location.
• The system shall allow secure online payments via credit/debit cards.
4. Non-Functional Requirements
• The system should support 1,000 concurrent users without slowing down.
• The payment system should comply with PCI-DSS security standards.

Requirements Engineering Process

The Requirements Engineering Process is a structured approach for gathering, analyzing,
documenting, validating, and managing software requirements. It ensures that the software system
aligns with user expectations and business goals【Standard Software Engineering Principles】.
1. Requirements Elicitation
Requirements elicitation is the process of gathering requirements from stakeholders such as users,
clients, and developers. It ensures that the software meets actual user needs.
Techniques Used:
1. Interviews – Conducting discussions with users to understand their expectations.
2. Surveys & Questionnaires – Collecting structured responses from a large group.
3. Observation – Studying how users interact with the current system.
4. Prototyping – Creating an early version of the software to refine requirements.
5. Brainstorming – Holding group discussions to generate ideas.
6. Use Case Analysis – Defining user interactions with the system.
Challenges:
✔ Stakeholders may struggle to express their requirements.
✔ Conflicting needs from different stakeholders.
✔ Changing requirements during development.
Example:
For a Hospital Management System, requirements are gathered from:
• Doctors (need electronic prescriptions).
• Nurses (require real-time patient updates).
• Administrators (want billing automation).

2. Requirements Analysis
Requirements analysis involves understanding, refining, and resolving conflicts in the gathered
requirements. It helps in categorizing and prioritizing system needs.
Key Steps:
1. Conflict Resolution: Resolving contradictory requirements from different stakeholders.
2. Feasibility Analysis: Checking if requirements are practical within given constraints (time, cost,
technology).
3. Prioritization: Ranking requirements based on importance.
4. Classification:
o Functional Requirements – Define specific features (e.g., "User should be able to reset the
password").
o Non-Functional Requirements – Define system properties (e.g., "System must process
requests within 2 seconds").
Challenges:
✔ Conflicting requirements from different stakeholders.
✔ Difficulty in balancing user needs vs. technical feasibility.
Example:
For an E-commerce Website:
• Functional Requirement: "Users should be able to track orders in real time."
• Non-Functional Requirement: "The system should support 100,000 concurrent users."
3. Requirements Specification
Requirements Specification is the process of documenting the requirements in a structured format
(SRS - Software Requirements Specification).
Structure of an SRS Document:
1. Introduction: Purpose, scope, and objectives.
2. Overall Description: User needs, system overview, and constraints.
3. Functional Requirements: Features and behaviors of the system.
4. Non-Functional Requirements: Performance, security, usability.
5. External Interface Requirements: Interaction with external systems (e.g., databases, third-party
APIs).
6. Assumptions & Dependencies: Any limitations or external conditions affecting the project.
Importance:
✔ Serves as a contract between stakeholders and developers.
✔ Helps in project planning and resource allocation.
✔ Acts as a reference document for future maintenance.
Example:
For an Online Banking System:
• Functional Requirement: "Users must be able to transfer money securely."
• Non-Functional Requirement: "Transaction processing must take less than 5 seconds."

4. Requirements Validation
Requirements validation ensures that requirements are correct, complete, and meet user needs
before development starts.
Key Techniques:
1. Prototyping: Building a mock-up to get user feedback.
2. Stakeholder Reviews: Holding meetings with clients and users to validate requirements.
3. Test Case Generation: Ensuring requirements are testable.
4. Formal Inspections: Conducting detailed document reviews.
Challenges:
✔ Difficult to get full agreement from all stakeholders.
✔ Errors in validation can lead to major rework costs later.
Example:
For a University Course Registration System, validation includes:
• Testing a prototype to check ease of course selection.
• Getting feedback from students and faculty to confirm requirements.
5. Requirements Management (10 Marks)
Requirements management is the process of tracking, modifying, and controlling requirement
changes throughout the project lifecycle.
Key Aspects:
1. Version Control: Keeping track of different versions of requirements.
2. Change Control: Handling modifications systematically.
3. Impact Analysis: Evaluating how changes affect the project timeline and budget.
4. Traceability Matrix: Mapping requirements to system components and test cases.
Challenges:
✔ Changing business needs may lead to frequent requirement modifications.
✔ Poor management can cause scope creep (uncontrolled project expansion).
Example:
For a Social Media App, after initial requirements, the client requests:
• A dark mode feature due to user demand.
• A new security feature for multi-factor authentication.
Effective requirements management ensures these changes are tracked, evaluated, and implemented
smoothly.

System Models and CASE Workbenches

System models and CASE (Computer-Aided Software Engineering) workbenches are essential
components in software engineering. System models provide abstract representations of a system to
help understand and design its structure, while CASE workbenches are tools that automate software
development tasks to improve efficiency and accuracy.

1. System Models
A system model is an abstract representation of a software system that helps developers, analysts,
and stakeholders visualize its structure, behavior, and data flow.
Purpose of System Models:
✔ Helps in understanding system architecture before implementation.
✔ Identifies functional and non-functional requirements clearly.
✔ Improves communication among developers, designers, and stakeholders.
✔ Reduces errors and inconsistencies in software development.

Types of System Models:

1. Context Models
• Show how a system interacts with external entities like users, devices, and databases.
• Used in high-level requirement analysis to define system boundaries.
• Example: A Library Management System context model may show interactions with librarians,
students, and book databases.

2. Behavioral Models
• Represent how the system behaves in response to events and inputs.
• State Machine Diagrams and Use Case Diagrams are common examples.
• Example: In an Online Banking System, a state diagram could show states like "Logged In,"
"Performing Transaction," and "Logged Out."

3. Data Models
• Define how data is structured, stored, and related in a system.
• Entity-Relationship (ER) Diagrams and Data Flow Diagrams (DFD) are commonly used.
• Example: A University Student Database model may include entities like Students, Courses,
and Instructors, along with their relationships.
4. Object Models
• Represent the system using object-oriented concepts like classes, attributes, and relationships.
• UML Class Diagrams are commonly used in object modeling.
• Example: In an E-commerce Application, objects like User, Order, and Payment interact with
each other.

5. Architectural Models
• Define the overall system structure and how different components interact.
• Common architectures:
o Layered Architecture (e.g., Presentation, Business, Data layers).
o Client-Server Architecture (e.g., Web applications).
• Example: A 3-tier Web Application model separates the system into User Interface, Business
Logic, and Database layers.

2. CASE Workbenches
CASE (Computer-Aided Software Engineering) workbenches are software tools that support different
phases of software development. They automate tasks like design, coding, testing, and maintenance,
improving productivity and reducing errors.
Types of CASE Tools:
1. Upper CASE Tools
• Support early development stages such as requirement analysis and design.
• Examples:
o Rational Rose – Helps in UML modeling and system design.
o Enterprise Architect – Used for software architecture and requirement analysis.
2. Lower CASE Tools
• Assist in coding, testing, and debugging phases.
• Examples:
o Eclipse IDE – Provides code editing, debugging, and testing tools.
o JUnit – Automated testing for Java applications.
3. Integrated CASE (I-CASE) Tools
• Cover the entire software development lifecycle (SDLC).
• Provide end-to-end automation from planning to maintenance.
• Example: IBM Rational Suite integrates design, coding, testing, and documentation tools.
4. Features of CASE Workbenches
✔ Diagramming Tools: Helps in modeling system architecture.
✔ Code Generation: Transforms UML models into executable code.
✔ Version Control: Tracks changes and maintains different versions of software.
✔ Testing & Debugging: Automates unit and integration testing.
5. Benefits of CASE Workbenches
✔ Reduces Development Time: Automates repetitive tasks like coding and testing.
✔ Improves Software Quality: Ensures consistency and minimizes human errors.
✔ Enhances Team Collaboration: Developers, testers, and designers can work together efficiently.
✔ Reduces Maintenance Costs: Makes software easier to update and modify.
Architectural Design and System Structuring
Architectural design is a crucial phase in software engineering where the overall structure of the
system is defined. This process includes organizing the system into subsystems, defining their
interactions, and selecting design patterns that ensure maintainability, scalability, and efficiency.

1. Architectural Design
Architectural design is the process of defining a structured solution that meets the system’s functional
and non-functional requirements. It serves as a blueprint for both software development and
maintenance.
Goals of Architectural Design:
✔ Improve modularity for easier development and debugging.
✔ Ensure scalability and performance efficiency.
✔ Enhance security and fault tolerance.
✔ Define clear communication paths between system components.
Key Components of Architectural Design:
1. System Structuring: Organizing components into subsystems.
2. Modular Decomposition: Breaking the system into functional modules.
3. Control Styles: Managing interactions between modules.
4. Reference Architectures: Standardized architectures for specific domains.

2. System Structuring
System structuring is the process of breaking down a software system into subsystems and defining
how they interact.
Common System Structuring Models:
1. Layered Architecture
• The system is organized into layers, where each layer provides services to the one above it.
• Example: The OSI Model in networking consists of 7 layers (Physical, Data Link, Network, etc.).
✔ Advantages:
✔ Easy to modify and scale.
✔ Helps in separating concerns between functionalities.
✖ Disadvantages:
✖ Performance overhead due to data passing through multiple layers.

2. Client-Server Architecture
• The system is divided into two main parts:
o Clients that request services.
o Servers that process and return responses.
• Example: A web application where browsers (clients) request data from a web server.
✔ Advantages:
✔ Supports multiple users simultaneously.
✔ Centralized control for better security and data management.
✖ Disadvantages:
✖ Single point of failure—if the server crashes, all clients lose service.
3. Repository Model
• All system components interact through a central data repository.
• Example: Version Control Systems like Git, where all project files are stored in a shared
repository.
✔ Advantages:
✔ Ensures data consistency across components.
✔ Reduces redundancy in data storage.
✖ Disadvantages:
✖ If the repository fails, the whole system may stop working.

4. Pipe-and-Filter Architecture
• The system is structured as a sequence of processing steps (filters), where output from one
module is input for the next.
• Example: Compiler Design, where data flows through Lexical Analysis → Syntax Analysis → Code
Generation.
✔ Advantages:
✔ Supports parallel execution, improving performance.
✔ Allows modular development, where filters can be modified separately.
✖ Disadvantages:
✖ High overhead due to data transformation at each step.

5. Event-Driven Architecture
• Components communicate through events or messages, allowing a loosely coupled system.
• Example: IoT (Internet of Things) systems, where sensors send events to cloud platforms.
✔ Advantages:
✔ Highly scalable and flexible.
✔ Works well for real-time applications.
✖ Disadvantages:
✖ Difficult to debug and test due to asynchronous communication.

3. Modular Decomposition Styles

Modular decomposition helps in breaking the system into functional units (modules) to improve
maintainability and reusability.
1. Object-Oriented Decomposition
• The system is divided into objects that interact through well-defined interfaces.
• Example: In Java, a banking system may have classes like Account, Customer, and Transaction.
✔ Advantages:
✔ Promotes code reuse and encapsulation.
✔ Enhances scalability and flexibility.
✖ Disadvantages:
✖ Can increase complexity due to multiple object interactions.
2. Function-Oriented Decomposition
• The system is divided into functional modules, each responsible for a specific task.
• Example: In a payroll system, modules may include Salary Calculation, Tax Deduction, and
Report Generation.
✔ Advantages:
✔ Well-suited for procedural programming (C, Pascal).
✔ Easier to implement for smaller systems.
✖ Disadvantages:
✖ Difficult to modify since changes in one function may affect others.

4. Control Styles
Control styles define how different modules interact and coordinate within a system.
1. Centralized Control
• A single entity (controller) manages the execution of system components.
• Example: A traffic control system where a central server manages all signals.
✔ Advantages:
✔ Predictable behavior and easier debugging.
✖ Disadvantages:
✖ Single point of failure—if the controller fails, the entire system crashes.

2. Event-Based Control
• Components trigger events dynamically rather than relying on a central controller.
• Example: A notification system where events (emails, messages) are triggered by user actions.
✔ Advantages:
✔ Highly scalable and flexible.
✖ Disadvantages:
✖ Debugging can be challenging due to complex event flows.

5. Reference Architectures
Reference architectures provide standardized templates for designing systems in specific domains.
1. The OSI Model
• A 7-layer architecture used in networking.
• Example: The Internet follows the OSI model for data transmission.
✔ Advantages:
✔ Provides clear separation of concerns.
✖ Disadvantages:
✖ Can be overly complex for small-scale systems.

2. ECMA CASE Reference Model

• Defines services for Computer-Aided Software Engineering (CASE) environments.
• Example: Software design tools like Rational Rose use CASE models for automation.
✔ Advantages:
✔ Standardizes software development processes.
✖ Disadvantages:
✖ May not be suitable for every project due to strict guidelines.

Control Models
Control models define how different subsystems coordinate and execute operations within a software
system. These models supplement structural models to ensure that services are delivered to the right
place at the right time.

Types of Control Models

1. Centralized Control Model
• A single subsystem (controller) is responsible for managing the execution of all other
subsystems.
• The controller initiates, stops, and monitors subsystems as needed.
• Centralized control models can be sequential or concurrent.

Types of Centralized Control Models:

a) Call-Return Model
• Uses a hierarchical subroutine structure.
• Control starts at the top and flows downward through function calls.
• Example: A compiler system where different phases (lexical analysis, parsing, code generation)
call each other in sequence.
b) Manager Model
• Used in concurrent systems where multiple processes run simultaneously.
• A system manager process controls the starting, stopping, and coordination of these processes.
• Example: Operating Systems that manage multiple applications running concurrently.

2. Event-Driven Control Model

• Instead of having a central controller, subsystems respond to externally generated events.
• These events may come from user actions, sensors, or messages from other components.

Types of Event-Driven Control Models:

a) Broadcast Model
• Events are broadcasted to all subsystems, and only those interested in the event respond.
• Example: A stock market system, where all trading terminals receive price updates, but only
those interested in a specific stock react.
b) Interrupt-Driven Model
• Used in real-time systems, where external signals trigger an immediate response.
• Example: An airbag system in a car, which instantly deploys airbags upon detecting a crash.

Modular Decomposition
Modular decomposition is the process of breaking down a system into smaller, manageable
modules, making it easier to develop, maintain, and scale. The approach used for decomposition
impacts system flexibility, complexity, and efficiency.
• A subsystem is an independent system that provides services without depending on others.
• A module is a smaller system component that depends on services from other modules and
provides services to others.
After defining subsystems, software engineers decide how to decompose them into modules using
different architectural styles.

2. Modular Decomposition Approaches

There are two major strategies for modular decomposition:
1. Object-Oriented Decomposition (OOD)
• The system is decomposed into interacting objects, each with private states and well-defined
interfaces.
• Objects communicate via method calls instead of sharing data directly.
✔ Advantages:
✔ Objects represent real-world entities, making the system easier to understand.
✔ Promotes code reuse, since objects can be used across multiple applications.
✔ Objects are loosely coupled, making it easy to modify without affecting others.
✖ Disadvantages:
✖ Objects must explicitly reference other objects’ interfaces, which can complicate dependencies.
✖ Some complex entities may not fit naturally into an object-based structure.
Example:
• A Banking System may include objects like Customer, Account, and Transaction, each handling
different operations.

2. Function-Oriented Pipelining
• The system is decomposed into functional transformations that process input data and
produce outputs.
• Data flows through different processing steps, each executed sequentially or in parallel.
✔ Advantages:
✔ Supports code reuse—transformations can be reused across different systems.
✔ Easy to extend by adding new processing steps.
✔ Can be implemented as batch or real-time systems.
✖ Disadvantages:
✖ Requires a common data format that all processing stages must understand.
✖ Not suitable for interactive systems, as it processes data in streams rather than responding to user
inputs dynamically.
Example:
• In a Billing System, function-oriented decomposition may include the following
transformations:
1. Read issued invoices
2. Identify received payments
3. Issue receipts
4. Generate reminders for unpaid invoices
This model can be implemented using batch processing or real-time stream processing.
Domain-Specific Architectures
Domain-specific architectures (DSA) refer to architectural models designed for specific application
domains. These architectures reuse common patterns found in similar systems to improve efficiency,
maintainability, and scalability.

A domain-specific architecture is a predefined system structure designed to address the needs of a

particular application domain (e.g., banking, healthcare, telecommunications).
✔ Helps software developers reuse common architectural structures.
✔ Reduces development time by providing tested and optimized designs.
✔ Improves system consistency and reliability across similar applications.

Types of Domain-Specific Architectures

1. Generic Models
• Generic models abstract common features of real-world systems in a domain.
• They capture key functionalities and constraints of applications like data processing or
monitoring systems.
✔ Example: Real-time systems often use generic models for data collection and monitoring
applications (e.g., flight control systems, weather monitoring).

2. Reference Models
• Higher-level abstractions derived from studying multiple applications in a domain.
• Provide a standardized framework for designing systems within that domain.
✔ Example: The OSI Model (Open Systems Interconnection) is a reference model used in networking
systems. It defines how data should be transferred across a network.

Examples of Domain-Specific Architectures

Domain Example Architecture Use Case
Business Enterprise Resource Planning Manages business functions like payroll, HR,
Systems (ERP) finance
Handles secure transactions and account
Banking Transaction-Processing Systems
management
Healthcare Electronic Health Records (EHR) Manages patient data and hospital records

Benefits of Domain-Specific Architectures

✔ Reduces Development Time – Predefined models accelerate system design.
✔ Improves Reliability – Reuses tested designs, reducing system failures.
✔ Ensures Compliance – Helps meet industry standards (e.g., healthcare regulations, banking security
protocols).
✔ Enhances Maintainability – Standardized architectures simplify updates and modifications.
Objects and Object Classes, Object-Oriented Design Process, and Design Evolution
Object-oriented design (OOD) is a software development methodology where a system is structured
using objects, which are instances of classes that encapsulate data and behavior. The OOD process
involves identifying objects, defining their interactions, and refining the design over time through
design evolution.

1. Objects and Object Classes

An object is an entity that has attributes (data/state) and behavior (operations/methods). It
represents a real-world entity in the software system.
An object class is a blueprint that defines the structure and behavior of objects.
Characteristics of Objects:
✔ Encapsulation – Data is stored within the object and cannot be accessed directly.
✔ Inheritance – Objects can inherit attributes and behaviors from parent classes.
✔ Polymorphism – Different objects can implement the same method differently.
Example: A Banking System
In an online banking system, the following classes and objects exist:
Class: Account
+-----------------+
| Account |
+-----------------+
| - accountNo |
| - balance |
+-----------------+
| + deposit() |
| + withdraw() |
+-----------------+
• An object of this class can be:
o acc1 = Account(101, 5000)
o acc2 = Account(102, 10000)
Relationship Between Objects and Classes:
• A class is a template that defines the properties of objects.
• Objects are instances of a class with specific values for attributes.

2. Object-Oriented Design Process

OOD is a structured approach for developing software using objects and their interactions.

Steps in the Object-Oriented Design Process:

1. Define System Context and Use Cases
• Identify how the system interacts with users, external systems, or devices.
• Use Use Case Diagrams to map out functionalities.
✔ Example: In a Library Management System, actors like Librarian, Member, and System interact with
use cases like Issue Book, Return Book, and Add New Books.
2. Identify Key Objects and Classes
• Analyze the system requirements to determine main objects.
• Define object classes that encapsulate related attributes and methods.
✔ Example: In a Hospital Management System, the following objects can be identified:
• Doctor: name, specialization, schedule().
• Patient: id, disease, admit().
• Appointment: date, time, confirm().

3. Define Object Relationships and Hierarchies

• Identify associations between objects.
• Use UML Class Diagrams to define relationships.
✔ Example: In an E-commerce System, relationships may include:
• Customer places Order.
• Order contains Products.
• Product belongs to a Category.

4. Develop Design Models

OOD uses UML models to define interactions:
✔ Class Diagrams – Define object attributes and methods.
✔ Sequence Diagrams – Show message passing between objects.
✔ State Machine Models – Define object states and transitions.
✔ Example: A Sequence Diagram for Online Shopping may show:
• Customer → Search Product → Select Product → Make Payment → Receive Confirmation.

5. Define Object Interfaces

• Objects communicate through defined interfaces.
• Each object should expose only necessary methods to maintain encapsulation.
✔ Example: A Payment Gateway Interface in an E-commerce System may include:
• processPayment(), refund(), validateCard().

3. Design Evolution
Design evolution is the continuous process of modifying a system’s design over time to:
✔ Accommodate new requirements.
✔ Fix design flaws or inefficiencies.
✔ Improve scalability and performance.

1. Why Design Evolution is Necessary?

✔ Changing User Needs: Business requirements may change over time.
✔ Performance Optimization: Existing code may need improvements.
✔ Scalability: System expansion may require architectural changes.
✔ Security Enhancements: Software must adapt to evolving threats.
✔ Example:
• A Weather Station System originally only recorded temperature.
• Later, humidity and air quality monitoring were added.
• New objects (HumiditySensor, AirQualitySensor) were introduced.

2. Strategies for Managing Design Evolution

• Refactoring: Improving code structure without changing its behavior.
• Design Pattern Adoption: Using reusable solutions for common problems.
• Encapsulation & Loose Coupling: Ensuring changes in one module don’t break others.
✔ Example:
• In a Banking System, initially, only local transactions were supported.
• Later, international transactions were introduced, requiring new currency conversion logic.
• Instead of modifying the entire Transaction class, a separate CurrencyConverter class was
added.

3. Challenges in Design Evolution

✔ Maintaining Backward Compatibility – Ensuring older system components still work.
✔ Avoiding Increased Complexity – Preventing unnecessary dependencies.
✔ Testing and Validation – Ensuring changes do not introduce new errors.
✔ Example:
• A Mobile Payment App added QR code scanning to improve usability.
• This required testing old and new payment methods to avoid failures.

4. Example: Evolution of a Vehicle Control System

• Stage 1: Basic car control with start(), stop(), accelerate().
• Stage 2: Introduced cruiseControl() for automatic speed management.
• Stage 3: Added selfDrivingMode(), requiring integration with GPS and AI.