Module4

Software Engineering
Software Engineering: The Software Engineering Discipline, The Software Life Cycle, Software
Engineering Methodologies, Modularity, Tools of the Trade.

Q) Explain Software Engineering and The Software Engineering Discipline

Software Engineering is the systematic and disciplined approach used for the development,
operation, maintenance, and management of software systems.
Software Engineering is a disciplined approach to developing and maintaining software systems.
The Software Engineering Discipline includes methods, tools, and processes that help create
reliable, efficient, and high-quality software. It plays a major role in modern technology and
supports the development of software used in business, education, healthcare, communication,
and many other fields.
It applies engineering principles to software development in order to produce:
 Reliable software
 Efficient software
 High-quality software
 Cost-effective software

Definition of Software Engineering

Software Engineering is defined as:
―The application of engineering principles, methods, and tools to the development and
maintenance of software.‖
As software systems became large and complex, traditional programming methods were not
sufficient.
Software engineering helps to:
 Reduce software errors
 Improve quality
 Complete projects on time
 Reduce development cost
 Maintain large software systems efficiently
 Develop high-quality software
 Meet user requirements
 Ensure reliability and security
 Improve maintainability
 Deliver software within budget and schedule

Software Engineering Discipline

The Software Engineering Discipline refers to the organized field of study and professional
practices involved in software development.
It includes:
 Methods
 Tools
 Techniques
  Processes
 Standards
used throughout the software life cycle.

Activities in Software Engineering Discipline

1. Requirement Analysis
Understanding user needs and system requirements.
Example
Identifying features needed in a banking application.

2. Software Design
Planning the structure and architecture of the software.
Includes
 Database design
 Interface design
 System architecture

3. Coding (Implementation)
Writing program code using programming languages.
Examples
 C
 Java
 Python

4. Testing
Checking software for errors and bugs.
Types
 Unit testing
 Integration testing
 System testing

5. Deployment
Installing software for users.

6. Maintenance
Updating and improving software after deployment.
Includes
 Bug fixing
 Performance improvement
 Security updates
Describe the Software Development Life Cycle (SDLC)
Software engineering follows a structured process called SDLC.
Phases of SDLC
1. Requirement Analysis
2. System Design
3. Coding
4. Testing
5. Deployment
6. Maintenance

Importance of Software Engineering Discipline

 Produces reliable software
 Reduces development risks
 Improves software quality
 Supports teamwork
 Makes maintenance easier
 Helps manage complex projects

Applications of Software Engineering

Software engineering is used in:
 Banking systems
 Mobile applications
 Web development
 Healthcare systems
 Embedded systems
 E-commerce platforms

Examples of Software Products

  Microsoft Windows
 Android
 Google Chrome
 Microsoft Office

Advantages of Software Engineering

 Better software quality
 Reduced cost and time
 Easier maintenance
 Improved customer satisfaction
 Efficient project management

Q) Why would the number of lines in a program not be a good measure of the
complexity of the program?

The number of lines in a program is not a reliable measure of program complexity because
complexity depends on the logic, structure, and difficulty of the operations performed. A short
program can be highly complex, while a long program may be simple and easy to understand.
Therefore, software complexity should be evaluated using logical and structural factors rather
than line count alone.
The number of lines in a program is not always a good indicator of its complexity because
complexity depends on the logic, structure, and functionality of the program, not just its length.

1. Short Programs Can Be Very Complex

A program with fewer lines may contain:
 Complex algorithms
 Nested loops
 Difficult logic
 Advanced mathematical calculations
Example
A short encryption program may be harder to understand than a long simple program.

2. Long Programs May Be Simple

A program with many lines may only contain:
 Repeated statements
 Simple input/output operations
 Basic calculations
Such programs may be easy to understand despite having many lines.

3. Programming Style Differs

Different programmers write code differently.
Example
One programmer may write:
if(a>b): print(a)
Another may write the same logic in multiple lines:
if(a>b):
print(a)
Both perform the same task but have different line counts.

4. Use of Functions and Libraries

Modern programming languages use:
 Built-in functions
 Libraries
 Modules
A powerful function can perform large operations in a single line.
Example
sorted(list)
One line may internally execute complex operations.

5. Complexity Depends on Logic

Program complexity is better measured by:
 Decision making
 Loops
 Conditions
 Interactions between modules
 Algorithm difficulty
Not by physical size alone.

6. Maintainability Matters More

A small but poorly written program may be:
 Hard to debug
 Difficult to maintain
 Confusing to understand
Whereas a longer well-structured program may be easier to manage.

Q) Suggest a metric for measuring software quality. What weaknesses do your metric
have?

A useful metric for measuring software quality is Defect Density.

Defect Density
It measures the number of defects (bugs) found in a software product relative to its size.
Software size is usually measured in:
 Lines of Code (LOC)
 Function Points
 Helps identify software reliability
 Useful for comparing software quality
 Indicates testing effectiveness

 Does not measure user satisfaction

  Depends on accurate defect reporting
 Large programs may naturally contain more defects
 Ignores code readability and maintainability
 Different programming languages affect LOC measurements; Therefore, defect density
gives only a partial measure of software quality.

Q) What technique can be used to determine how many errors are in a unit of software?

A common technique used to determine how many errors are in a unit of software is Software
Testing, especially Unit Testing.
In unit testing, individual modules or units of a program are tested separately to identify errors or
bugs.
Another technique is Error Seeding, where known artificial errors are intentionally inserted into
the software. By checking how many seeded errors are found during testing, developers can
estimate the total number of remaining errors in the software
Identify two contexts in which the field of software engineering has been
or currently is progressing toward improvements.
Two contexts in which software engineering has progressed toward improvements are:
1. Software Development Methods
Modern methodologies such as Agile and DevOps have improved software development
by increasing speed, flexibility, collaboration, and software quality.
2. Software Quality and Testing
Advanced testing techniques, automation tools, and quality assurance practices have
improved software reliability, security, and error detection.

Q) How does the development stage of the software life cycle affect the
maintenance stage?

The development stage of the Software Life Cycle greatly affects the maintenance stage because
well-designed and properly documented software is easier to maintain.
 Good coding practices and proper testing reduce future errors.
 Clear documentation helps developers understand and modify the software easily.
 Poor development leads to more bugs, higher maintenance cost, and difficulty in updating
the software.
Thus, better development results in easier and more efficient maintenance.

Summarize each of the four stages (requirements analysis, design, implementation,

and testing) within the development phase of the software life
cycle.

Q) explain the Four Stages of the Development Phase in Software Life Cycle

1. Requirements Analysis
In this stage, the needs and expectations of users are identified and analyzed. The system
requirements are clearly defined.

2. Design
The overall structure and architecture of the software are planned. This includes database design,
user interface design, and system flow.

3. Implementation
The actual coding of the software is done using programming languages. The designed system is
converted into a working program.

4. Testing
The software is tested to identify and remove errors or bugs. This ensures the software works
correctly and meets user requirements.
What is the role of a software requirements specification?
A Software Requirements Specification (SRS) is a document that clearly describes the
functional and non-functional requirements of a software system.

Role of SRS
 Defines user needs and system requirements
 Acts as a guide for developers, designers, and testers
 Helps in planning and designing the software
 Reduces misunderstandings between users and developers
 Serves as a reference during testing and maintenance
  Ensures the software meets customer expectations

Thus, the SRS acts as the foundation for successful software development.

Q) Summarize the distinction between the traditional waterfall model of software

development and the newer incremental and iterative paradigms.

The Waterfall Model is a traditional software development approach in which development

proceeds step-by-step through fixed phases such as requirements, design, implementation, and
testing. Each phase must be completed before moving to the next phase.
In contrast, Incremental and Iterative Models develop software in smaller parts and repeated
cycles. Features are added gradually, and feedback is used to improve the software continuously.
Main Difference
 Waterfall Model: Linear and rigid approach.
 Incremental/Iterative Models: Flexible and continuous improvement approach.
Incremental and iterative paradigms are better suited for changing requirements and faster
software delivery.
Difference Between Waterfall Model, Incremental Model, and Iterative Model
Feature Waterfall Model Incremental Model Iterative Model
Step-by-step
Approach Sequential Repeated improvement cycles
development
Development One phase after Software developed in
Software refined repeatedly
Process another small parts
Flexibility Low Moderate High
Requirement
Difficult Easier Easily accommodated
Changes
Delivered once at Improved versions delivered
Software Delivery Delivered in increments
the end repeatedly
Customer
Mostly at the end After each increment During every iteration
Feedback
Done after
Testing Done for each increment Continuous testing
development
Risk Higher Lower Lower
Small, fixed
Suitable For Medium-sized projects Large and changing projects
projects

1. Waterfall Model
 Traditional linear model
 Each phase must finish before the next starts
 Simple but rigid
Advantage
Easy to understand and manage
Disadvantage
Difficult to make changes later

2. Incremental Model
 Software is developed in smaller functional parts
 Each increment adds new features
Advantage
Early delivery of working software
Disadvantage
Integration may become complex

3. Iterative Model
 Software is developed through repeated cycles
 Each version improves the previous one
Advantage
Continuous improvement
What is the distinction between traditional evolutionary prototyping and
open-source development?
Traditional evolutionary prototyping and open-source development differ mainly in their
development approach and participation.
 Evolutionary Prototyping:
A prototype is developed, tested, and continuously refined based on user feedback until
the final software is produced. Development is usually controlled by a specific
organization or development team.
 Open-Source Development:
Software source code is publicly available, and developers from different locations
collaboratively improve and modify the software. Contributions
What potential problems do you suspect could arise in terms of ownership rights of software
developed via the open-source methodology?
Potential problems related to ownership rights in open-source software development include:
 Unclear ownership: Many developers contribute, making it difficult to determine who
owns the final software.
 Licensing conflicts: Different open-source licenses may create legal issues regarding
modification and distribution.
 Unauthorized use of code: Contributors may include copyrighted code without
permission.
 Patent issues: Some software features may violate patents owned by others.
 Commercial usage disputes: Companies may use open-source software commercially
without clearly sharing profits or contributions.
These issues can create legal and management challenges in open-source development.
Identify three development paradigms that represent the move away from strict adherence to the
waterfall model.
Three development paradigms that moved away from strict adherence to the Waterfall
Model are:
1. Incremental Development Model
Software is developed and delivered in smaller functional parts called increments.
 2. Iterative Development Model
Software is improved repeatedly through multiple development cycles or iterations.
3. Evolutionary Prototyping Model
A prototype is continuously refined based on user feedback until the final system is
developed.

Q) Explain Modularity and modular implementation

Modularity and Modular Implementation
Modularity is the concept of dividing software into smaller manageable modules, while modular
implementation is the practical development of those modules independently and integrating
them into a complete system. Both concepts reduce software complexity and improve
maintainability, reliability, and efficiency in software engineering.

Modularity is the process of dividing a large software system into smaller, independent parts
called modules.
Each module performs a specific function and can be developed, tested, and maintained
separately.
 Divides complex systems into manageable parts
 Each module has a specific task
 Modules interact through well-defined interfaces
 Improves readability and organization

Advantages of Modularity
 Easier program development
 Simplifies debugging and testing
 Improves maintenance
 Encourages code reuse
 Reduces complexity
 Supports teamwork

Modular Implementation
Modular implementation is the process of developing software by implementing each module
separately and then integrating them into a complete system.

Steps in Modular Implementation

1. Divide the software into modules
2. Develop each module independently
3. Test individual modules
4. Integrate modules together
5. Perform system testing

Characteristics of Modular Implementation

 Independent module development
 Easier error detection
 Better maintainability
  Parallel development by teams

For an online shopping system:

Module Function
Login Module User authentication
Product Module Display products
Cart Module Manage shopping cart
Payment Module Process payments
Each module is implemented separately and later connected.

Advantages of Modular Implementation

 Faster software development
 Easier updates and modifications
 Better reliability
 Simplifies testing
 Improves software quality

the structure chart shown in Figure 7.3, in which functions are represented by rectangles and
function dependencies (implemented by function calls) are represented by arrows. In particular,
the chart indicates that the entire game is overseen by a function named ControlGame, and to
perform its task, ControlGame calls on the services of the functions Serve, Return, ComputePath,
and UpdateScore.
the chart indicates that the entire game is overseen by a function named ControlGame, and to
perform its task,
ControlGame calls on the services of the functions Serve, Return, ComputePath,
and UpdateScore.
Let us now reconsider the program’s design—this time in the context of the
object-oriented paradigm. Our first thought might be that there are two players
that we should represent by two objects: PlayerA and PlayerB. These objects
will have the same functionality but different characteristics. (Both should be
able to serve and return volleys but may do so with different skill and strength.)
Thus, these objects will be instances of the same class. (Recall that in Chapter 6
we introduced the concept of a class: a template that defines the functions (called
methods) and attributes (called instance variables) that are to be associated with
each object.) This class, which we will call PlayerClass, will contain the methods
serve and return that simulate the corresponding actions of the player. It
will also contain attributes (such as skill and endurance) whose values reflect
the player’s characteristics. Our design so far is represented by the diagram in
Figure 7.4. There we see that PlayerA and PlayerB are instances of the class
PlayerClass and that this class contains the attributes skill and endurance as
well as the methods serve and returnVolley. (Note that in Figure 7.4 we have
underlined the names of objects to distinguish them from names of classes.)
Next we need an object to play the role of the official who determines whether
the actions performed by the players are legal. For example, did the serve clear
the net and land in the appropriate area of the court? For this purpose we might
establish an object called Judge that contains the methods evaluateServe and
evaluateReturn. If the Judge object determines a serve or return to be acceptable,
play continues. Otherwise, the Judge sends a message to another object
named Score to record the results accordingly.

Q) Explain coupling, data coupling, control coupling with flow diagram.

Coupling refers to the degree of dependency between two modules in a software system.
It indicates how closely connected different modules are.
 Low coupling → Better software design
 High coupling → Poor software design
Low coupling is preferred because changes in one module will have minimal effect
what is data coupling control coupling
Data Coupling
Data Coupling occurs when two modules interact by passing only the necessary data as
parameters.
It is considered a good type of coupling because modules remain mostly independent.

Advantages
 Easy maintenance
 Better module independence
 Reduced side effects
Control Coupling
Control Coupling occurs when one module controls the behavior of another module by passing
control information or flags.
Example
A module sends a flag value to decide what operation another module should perform.
ProcessData(data, flag)
If:
 flag = 1 → Print data
 flag = 2 → Save data
Here, one module controls another module’s actions.

Disadvantages
 Increases dependency between modules
 Makes maintenance difficult
 Reduces modularity

Difference Between Data Coupling and Control Coupling

Feature Data Coupling Control Coupling
Communication Through data only Through control information
Dependency Low Higher
Modularity Better Poorer
Complexity Less More
Preferred Yes No
Q) Explain Information Hiding and its advantages.
Information Hiding is a software design principle in which the internal details of a module are
hidden from other modules. Only the necessary information is exposed. Information Hiding is an
important software engineering concept that protects the internal details of modules and allows
interaction only through well-defined interfaces. It improves security, maintainability, and
modularity in software systems.

It helps protect data and reduces dependency between modules.

A module should:
 Hide its internal working
 Expose only required operations or interfaces
Other modules should not directly access internal data.
Information Hiding in Programming
It is commonly implemented using:
 Private variables
 Access modifiers
 Functions and methods

Advantages of Information Hiding

 Improves security
 Reduces complexity
 Easier maintenance
 Increases modularity
 Prevents unauthorized access
 Makes software easier to modify

Information hiding supports modularity because each module works independently without
exposing internal details.
Q) Explain Cohesion, Types of Cohesions, Difference between Logical and Functional
Cohesion and discuss their advantages and disadvantages.

Cohesion measures how strongly related the functions inside a module are. High cohesion
improves software quality, maintainability, and reliability, making it an important concept in
software engineering.

Cohesion refers to the degree to which the elements within a module work together to perform a
single task.
It measures the strength of relationship among components inside a module.
 High Cohesion → Good software design
 Low Cohesion → Poor software design

A module that performs only student record management has high cohesion because all functions
are related to one task.

Advantages of High Cohesion

 Easier maintenance
 Better readability
 Improved reliability
 Easier testing and debugging
 Better modularity

Types of Cohesion
1. Coincidental Cohesion
Unrelated tasks are grouped together.

2. Logical Cohesion
Related tasks are grouped logically.
Input/output functions in one module.

3. Temporal Cohesion
Tasks executed at the same time are grouped together.

4. Procedural Cohesion
Elements are grouped because they follow a sequence of steps.

5. Communicational Cohesion
Elements operate on the same data.

6. Sequential Cohesion
Output of one part becomes input to another part.

7. Functional Cohesion
All elements work together to perform one specific function.
Cohesion vs Coupling
Cohesion Coupling
Relationship within a module Relationship between modules
High cohesion is desirable Low coupling is desirable

Logical Cohesion Within an Object

Logical cohesion occurs when functions that are logically related are grouped together in a
single object or module, even though they perform different activities.
The operations are selected using a control flag or condition.
All are related to printing, so they are logically grouped.

Disadvantage
 Functions may not be strongly related
 Maintenance becomes difficult

Functional Cohesion Within an Object

Functional cohesion occurs when all elements of an object work together to perform one
specific task.
It is the highest and best form of cohesion.
Example
A Student Record object that only:
 Stores student data
 Updates student details
 Displays student information
All functions are focused on one purpose.
Advantages
 Easy maintenance
 Better readability
 High reliability
  Improved modularity

Difference Between Logical and Functional Cohesion

Feature Logical Cohesion Functional Cohesion
Purpose Logically related tasks Single specific task
Relationship Weak Strong
Complexity Higher Lower
Software Quality Moderate Best
Preferred Less preferred Highly preferred

The goal of maximizing cohesion compatible with minimizing coupling. That is, as cohesion
increases, does coupling naturally tend to decrease?

Yes, the goal of maximizing cohesion is generally compatible with minimizing coupling.
 High cohesion means a module focuses on a single well-defined task.
 Low coupling means modules have fewer dependencies on each other.
As cohesion increases, modules become more independent and self-contained, which naturally
tends to reduce coupling between modules.
Therefore:
 Good software design aims for high cohesion and low coupling.
 These two concepts usually support each other and improve maintainability, reliability,
and modularity of software systems.
 Define coupling, cohesion, and information hiding

Coupling
 Coupling is the degree of dependency between two modules in a software system. Low
coupling is preferred because modules become more independent.

Cohesion
 Cohesion is the degree to which the elements within a module work together to perform a
single task. High cohesion is considered good software design.

Information Hiding
 Information hiding is the practice of hiding the internal details of a module and exposing
only the necessary information through interfaces. It improves security and modularity.

Q) Explain Component architecture, A traditional programmer and A component

assembler and differentiate
Research in the development and use of components has led to the emerging
field known as component architecture (also known as component-based
software engineering) in which the traditional role of a programmer is replaced
by a component assembler who constructs software systems from prefabricated
components that, in many development environments, are displayed as icons in
a graphical interface. Rather than be involved with the internal programming of
 the components, the methodology of a component assembler is to select pertinent
components from collections of predefined components and then connect
them, with minimal customization, to obtain the desired functionality. Indeed, a
property of a well-designed component is that it can be extended to encompass
features of a particular application without internal modifications.

A traditional programmer develops software by writing most of the program code from
scratch using programming languages.

A component assembler builds software by selecting, combining, and integrating prebuilt

software components or modules instead of creating everything from the beginning.

 Difference
Traditional Programmer Component Assembler
Writes code manually Reuses existing components
Develops entire programs Integrates ready-made modules
More coding effort Less coding effort
Time-consuming Faster development
 Component assembly improves software reuse and reduces development time.

Tools of the Trade

Q) Explain dataflow diagram
A dataflow diagram is a means of representing the information
gained from such dataflow studies. In a dataflow diagram, arrows represent data
paths, ovals represent points at which data manipulation occurs, and rectangles
represent data sources and stores. As an example, Figure 7.8 displays an elementary
dataflow diagram representing a hospital’s patient billing system. Note that
the diagram shows that Payments (flowing from patients) and Patient Records
(flowing from the hospital’s files) merge at the oval Process Payments from which
UpdatedRecords flow back to the hospital’s files.

Q) Explain Unified Modeling Language (UML) for a simple use case diagram.
Dataflow diagrams and data dictionaries were tools in the software engineering
arsenal well before the emergence of the object-oriented paradigm and have
continued to find useful roles even though the imperative paradigm, for which
they were originally developed, has faded in popularity. We turn now to the more
modern collection of tools known as Unified Modeling Language (UML) that
has been developed with the object-oriented paradigm in mind. The first tool that
we consider within this collection, however, is useful regardless of the underlying
paradigm because it attempts merely to capture the image of the proposed system
from the user’s point of view. This tool is the use case diagram—an example of
which appears in Figure 7.9.
A simple use case diagram

Q) Explain one –to –one, one to many and many to many relation between the entitie of
types X & Y with diagram
Figure 7.10 indicates that each patient can occupy one room and each room can host zero or one
patient. (We are assuming that each room is a private room.) An asterisk is used to indicate an
arbitrary nonnegative number. Thus, the asterisk in Figure
7.10 indicates that each physician may care for many patients, whereas the
1 at the physician end of the association means that each patient is cared for by
only one physician.
A one-to-one
relationship is exemplified by the association between patients and occupied
private rooms in that each patient is associated with only one room and each
room is associated with only one patient. A one-to-many relationship is exemplified
by the association between physicians and patients in that one physician is
associated with many patients and each patient is associated with one (primary)
physician. A many-to-many relationship would occur if we included consulting
physicians in the physician–patient relationship. Then each physician could be
associated with many patients and each patient could be associated with many
physicians.
One-to-one, one-to-many, and many-to-many relationships between entities of
types X and Y

In an object-oriented design it is often the case that one class represents

a more specific version of another. In those situations we say that the latter
class is a generalization of the former. UML provides a special notation for representing
generalizations. An example is given in Figure 7.12, which depicts
the generalizations among the classes MedicalRecord, SurgicalRecord, and
OfficeVisitRecord.
There the associations between the classes are represented
by arrows with hollow arrowheads, which is the UML notation for associations
that are generalizations. Note that each class is represented by a rectangle containing
Q) Explain the UML’s way of representing the internal characteristics of
a class in a class diagram
the name, attributes, and methods of the class in the format introduced
in Figure 7.4. This is UML’s way of representing the internal characteristics of
a class in a class diagram. The information portrayed in Figure 7.12 is that the
class MedicalRecord is a generalization of the class SurgicalRecord as well as a
generalization of OfficeVisitRecord.
That is, the classes SurgicalRecord and
OfficeVisitRecord
contain all the features of the class MedicalRecord plus
those features explicitly listed inside their appropriate rectangles. Thus, both the
SurgicalRecord and the OfficeVisitRecord
classes contain patient, doctor,
and date of record, but the SurgicalRecord class also contains surgical procedure,
hospital, discharge date, and the ability to discharge a patient, whereas
the OfficeVisitRecord class contains symptoms and diagnosis.
classes have the ability to print the medical record. The printRecord method in
SurgicalRecord
and OfficeVisitRecord are specializations of the printRecord
method in MedicalRecord, each of which will print the information specific to
its class.

A class diagram depicting generalizations

Q) Explain A sequence diagram depicting a generic volley
Figure 7.13 demonstrates that an entire sequence diagram is
enclosed in a rectangle (called a frame). In the upper left-hand corner of the
frame is a pentagon containing the characters sd (meaning ―sequence diagram‖) followed by an
identifier. This identifier may be a name identifying the overall
sequence or, as in Figure 7.13, the name of the method that is called to initiate
the sequence. Note that in contrast to Figure 7.5, the rectangles representing the
players in Figure 7.13 do not refer to specific players but merely indicate that
they represent objects of the ―type‖ PlayerClass. One of these is designated
self, meaning that it is the one whose serve method is activated to initiate the
sequence. The
―loop‖ interaction fragment indicates that the events within its boundaries are to
be repeated as long as the Judge object determines that the value of validPlay
is true. The ―alt‖ interaction fragment indicates that one of its alternatives is to
be performed depending on whether the value of fromServer is true or false.

1. Draw a dataflow diagram representing the flow of data that occurs when
a patron checks a book out of a library.
2. Draw a use case diagram of a library records system.
3. Draw a class diagram representing the relationship between travelers and
the hotels in which they stay.
4. Draw a class diagram representing the fact that a person is a generalization
of an employee. Include some attributes that might belong to each.
5. Convert Figure 7.5 into a complete sequence diagram.
6. What role in the software engineering process do design patterns play?