Identifying the Requirements from Problem

Statements
Introduction
In software development, identifying requirements is the initial and critical step. It involves
determining what the software should do (functional requirements) and how it should perform (non-
functional requirements). These requirements form the foundation for a Software Requirements
Specification (SRS) and guide the entire development process.

Functional requirements specify what the software should do. They outline the specific features,
functions, and interactions that the software needs to have to meet the client's needs and
expectations. These requirements focus on the "what" of the system.

Non-functional requirements specify how the software should perform. They define attributes such
as performance, security, usability, and reliability. Non-functional requirements address the quality
and characteristics of the system, rather than its specific functionalities.

Objectives
After completing this experiment you will be able to:

[Link] ambiguities, inconsistencies and incompleteness from a requirements specification

[Link] and state functional requirements

[Link] and state non-functional requirements

Requirements
Requirements, as defined by Sommerville, are specifications that describe what should be
implemented in a software system. They outline how the system should behave without detailing
how it should achieve that behavior. Requirements engineering is the process of understanding and
documenting customer expectations for the system in a clear and understandable format. This
documentation serves as a reference for designing, implementing, and verifying the system.

Having a clear understanding of a software system's requirements is essential before planning,

designing, and implementing it for the client. Without this clarity, serious problems can arise, leading
to customer dissatisfaction. In short, well-defined requirements are crucial to a successful software
project.

Characteristics of Requirements
When gathering requirements for a new system, it is crucial that these requirements possess three
key properties:

Unambiguity: Requirements should be clear and free of any ambiguity. There should be no room for
different interpretations or misunderstandings. For instance, specifying "enough number of people"
without a precise definition can lead to confusion, as it may mean different things to different
stakeholders.

Consistency: Requirements must be consistent with each other and not contradict one another.
Inconsistencies can lead to confusion and conflicts during the development process. For example, in
the case of a nuclear plant automation system, different users should not have conflicting definitions
of critical parameters like radiation levels.

Completeness: Requirements should be comprehensive and cover both what the system should do
and what it should not do. This ensures that all aspects of the system's functionality are addressed.
For example, in an ATM software, it should not only specify what happens when a customer enters a
valid withdrawal amount but also what occurs when an invalid amount is entered, preventing any
unintended actions.

Categorization of Requirements
Requirements in software development can be categorized in various ways based on their audience,
content, and purpose:

1. Based on the Target Audience or Subject Matter:

- User Requirements: These are written in natural language and are intended for customers to
verify that their needs and expectations have been correctly captured. They focus on what the
system should do from a user's perspective.

- System Requirements: These are written using technical terms and specifications and are meant
for development or testing teams. They provide detailed guidance on how the system will be
implemented and tested.

2. Based on What They Describe:

- Functional Requirements (FRs): These describe the specific functionalities of the system, detailing
how it should respond to certain inputs and what outputs should result. They focus on the "what" of
the system's behavior.

- Non-Functional Requirements (NFRs): These are not concerned with specific functionalities but
define how the system should perform under various conditions. NFRs address qualities such as
performance, security, and usability and can be critical for the system's overall success.

3. Types of Non-Functional Requirements:

- Product Requirements: These specify characteristics related to the product itself, such as the
technology stack to be used, like plain HTML in a web application.

- Performance Requirements: These define expectations for the system's performance, like 24x7
availability.

- Organizational Requirements: These pertain to how the development process should be

conducted, such as adhering to specific quality standards like SEI CMM Level 4.

In summary, requirements in software development can be classified based on their audience,

content, and purpose. Understanding these classifications helps in effectively gathering,
documenting, and prioritizing requirements for a successful software project.

Functional Requirements
Identifying Functional Requirements

When identifying functional requirements from a problem statement, focus on the following key
points:

1. High-Level Functional Requirements: Start by identifying the fundamental functions that the
system should perform based on your conceptual understanding of the problem. For instance, in a
Library Management System, it should be able to issue and return books as core functions.

2. User-Centric Functions: Consider how end-users will interact with the system to achieve
meaningful tasks. Look for actions or operations that users perform to accomplish their goals. For
example, in a digital library, the "Search Book" functionality allows users to find books of interest.

3. Inputs and Outputs: Treat the system as a black box and identify the inputs it receives and the
outputs it generates. These inputs and outputs define the system's functionalities. For instance,
when a user searches for a book by providing the title as input, the system should return book details
and location as output.

4. Sub-Requirements: Recognize that high-level requirements may have various sub-requirements or

conditions. For example, the "Issue Book" module may have different behaviors for different user
classes or under specific conditions, like when a user has issued the book multiple times
consecutively.

In short, functional requirements are identified by understanding the core functions of the system,
considering user interactions, defining input-output relationships, and breaking down high-level
requirements into more detailed sub-requirements. This process ensures that the software
accurately captures and implements the desired functionality as specified by the problem statement.

Preparing Software Requirements Specifications

the Software Requirements Specification (SRS) is a vital document that outlines the project's
requirements. It is created by the service provider, verified by the client, and serves as a legal
agreement. The SRS is used as a reference throughout the development process and can be crucial in
resolving scope-related issues or change requests after deployment.

Case studies
Case Study: E-commerce Website Requirement Specification

XYZ Enterprises, a well-established retail company, is embarking on a transformative journey to

revamp its online presence. The current e-commerce platform falls short of modern user
expectations and industry standards. This project aims to develop a cutting-edge e-commerce
website that offers a seamless shopping experience for customers. The website will boast an updated
and responsive design, an expanded feature set including user reviews and wishlists, robust security
measures to safeguard user data, optimized performance, and SEO enhancements to improve search
engine visibility. By addressing these challenges and delivering a fully modernized platform, XYZ
Enterprises seeks to elevate its online sales, engage customers more effectively, and establish a
competitive edge in the digital marketplace.
The final deliverable would a web application (using the recent HTML 5 Although this reduces
security risk of the software to a large extent, care should be taken no confidential information (eg.,
passwords) is stored in plain text.

Functional Requirements:

1. User Registration and Authentication:

- Users must be able to register with their personal details.

- Users can log in using registered email and password.

- Provide an option for social media login (e.g., Facebook, Google).

- Users should be able to reset their passwords if forgotten.

2. Product Catalog:

- Display products categorized by type (e.g., clothing, electronics).

- Each product listing must include high-quality images, detailed descriptions, prices, and
availability.

- Allow users to filter and sort products by category, price, brand, and rating.

3. Shopping Cart and Wishlist:

- Users can add and remove items from their shopping cart.

- Save cart contents for registered users across sessions.

- Implement a wishlist feature for users to save desired items.

4. Checkout and Payment:

- Provide a secure and user-friendly checkout process.

- Collect user shipping and billing information.

- Integrate with payment gateways for credit card and digital wallet payments.

- Validate payment information in real-time.

5. Order Tracking:

- Registered users can view their order history and track order statuses.

- Display estimated delivery dates and shipping carrier information.

- Send email notifications for order updates.

6. User Reviews and Ratings:

- Allow registered users to leave product reviews and ratings.

- Display average ratings and user feedback on product pages.

- Enable users to mark reviews as helpful or report inappropriate content.

Non-Functional Requirements:

1. Performance:

- Ensure fast page load times, especially during peak traffic periods.

- Implement server-side caching and content delivery networks (CDNs) for optimized performance.

- Monitor and optimize website performance regularly.

2. Security:

- Use HTTPS (SSL/TLS) for secure data transmission.

- Store user passwords securely using hashing and salting techniques.

- Keep software up to date to protect against security vulnerabilities.

3. Scalability:

- Design the website for horizontal scalability to accommodate increased traffic and product
listings.

- Implement load balancing and auto-scaling mechanisms for peak demand periods.

4. Cross-Browser Compatibility:

- Ensure compatibility with major web browsers (Chrome, Firefox, Safari, Edge, etc.).

- Validate website functionality on various browser versions.

5. Mobile Responsiveness:

- Optimize the website for mobile devices and provide a seamless mobile user experience.

- Adapt image sizes and layouts for different screen sizes.

6. SEO-Friendly:

- Optimize website structure, meta tags, and content for search engines to improve organic search
rankings and visibility.

- Implement schema markup for product listings to enhance search results.

# Requirement Priority

R1 Patient Registration High

R2 Doctor Appointment Booking High

R3 Medical Record Management High

R4 Prescription Management High

R5 Billing and Invoicing High

R6 Equipment Maintenance Low

These functional and non-functional requirements are essential for the successful development and
deployment of the e-commerce website for XYZ Enterprises, ensuring a secure, user-friendly, and
high-performance online shopping platform.
E-R Modeling from the Problem Statements
Introduc+
tion
In this experiment, we will focus on the conceptual or logical modeling of databases using Entity-
Relationship (ER) diagrams. This process involves identifying the entities within a system, defining
their attributes, and establishing relationships between these entities. This preliminary modeling
step lays the foundation for designing the actual database tables and their relationships in a
systematic manner.

Objectives
After completing this experiment you will be able to:

Identify entity sets, their attributes, and various relationships

Represent the data model through ER diagram

Entity Relationship Model

The Entity-Relationship (ER) model is a fundamental tool for representing the logical design of a
database. It abstracts real-world objects or concepts as entities and defines the potential
associations between them as relationships. For instance, consider the entities "student" and
"school." Students are associated with schools through the "Studies in" relationship. In another
scenario, where a job runs nightly to update a database, "job" and "database" are entities connected
by the "Updates" relationship. The ER model provides a visual and structured way to conceptualize
database structures and their interconnections.

Entity Set and Relationship Set

An entity set is a collection of all similar entities. For example, "Student" is an entity set that
abstracts all students. Ram, John are specific entities belonging to this set. Similarly, a "Relationship"
set is a set of similar relationships.

Attributes of Entity
Attributes in the Entity-Relationship (ER) model are characteristics that describe entities within an
entity set. Entities can be described by zero or more attributes, and these attributes provide
information about the entity's properties or characteristics.

For instance, consider the "Student" entity set. Attributes for this entity set could include "name,"
"age," and "address," which describe specific characteristics of each student. Additionally, attributes
like "roll number" and "grade" could be associated with the entity set to provide more detailed
information.

Keys
- Super Key: This is a combination of one or more attributes that, when taken together, can uniquely
identify an entity within an entity set. For example, in a school database, a combination of "grade"
and "roll number" could form a super key, helping identify a student uniquely within that school.
- Candidate Key: A candidate key is a minimal subset of a super key. It is a set of attributes that can
uniquely identify an entity without any unnecessary attributes. In the example above, "grade" and
"roll number" might form a candidate key.

-Primary Key:A database can have multiple candidate keys, but one of them is chosen as the primary
key for the specific database implementation. It serves as the main identifier for the entity set.

- Prime Attribute: Any attribute that is part of a super key is referred to as a prime attribute. In the
example, "grade" and "roll number" would be prime attributes since they are part of a super key.

Attributes and keys play a crucial role in database design, as they help define the structure and
uniqueness of data within an entity set.

Weak Entity
A weak entity set in the Entity-Relationship (ER) model is an entity set that is dependent on another
entity set for its existence and cannot be uniquely identified solely by its attributes. In other words, it
lacks a super key, which means its uniqueness and existence are tied to another entity set.

For instance, consider a scenario where a company provides travel allowances to employees for their
immediate family members. In this case, we have two entity sets: "employee" and "family,"
connected by the "Can claim for" relationship. The "family" entity set is weak because it doesn't have
a super key of its own; its existence is entirely dependent on the associated "employee." A "family"
entity only makes sense within the context of an "employee."

Weak entities are often used in situations where entities have a hierarchical or containment
relationship. They rely on another entity, known as the "owning" or "parent" entity, to provide the
necessary context for their existence and identification.

Entity Generalization and Specialization

In the Entity-Relationship (ER) model, entity generalization and specialization are used to represent
relationships between generalized and specialized entities. The "ISA" hierarchy is a key concept in ER
modeling for depicting this relationship.

For example, consider a banking system where multiple individuals interact with the system. Most of
these individuals can be categorized as either customers or employees, each with specific attributes
and roles. In this scenario:

- "Person" serves as the generalized entity, representing common characteristics shared by all
individuals.

- "Customer" and "Employee" are specialized entities that inherit attributes from the "Person" entity
but also have their own unique attributes and roles.

The "ISA" hierarchy helps depict how specialized entities are derived from a generalized entity. It
allows for the modeling of commonalities and differences among entities within a system, providing
a structured way to represent entity relationships and attributes.

Mapping Cardinalities
In ER modeling, associating different entity sets is a fundamental task, and it can result in four types
of mappings based on the number of entities in each set that are associated with each other:

1. One to One (1:1): In a one-to-one relationship, each entity in entity set E1 is related to at most one
entity in entity set E2, and vice versa. This type of relationship implies a unique and direct association
between the two entity sets.

2. One to Many (1:N): In a one-to-many relationship, each entity in entity set E1 can be related to
zero or more entities in entity set E2. However, any entity in E2 can be related to at most one entity
in E1. This reflects a parent-child or master-detail relationship.

3. Many to One (N:1):In a many-to-one relationship, zero or more entities in entity set E1 can be
associated with a single entity in entity set E2. Conversely, an entity in E2 can be related to at most
one entity in E1. This is typically used to represent a reverse relationship of the one-to-many type.

4. Many to Many (N:N): In a many-to-many relationship, any number of entities in entity set E1 can
be related to any number of entities in entity set E2, including zero. Likewise, entities in E2 can be
related to any number of entities in E1. This type of relationship represents a complex and flexible
association between the two entity sets, allowing multiple entities to be linked in both directions.

These mappings help define the nature and cardinality of relationships between entities in an ER
model, providing a clear understanding of how different entity sets are connected within a database
system.

ER Diagram
From a given problem statement we identify the possible entity sets, their attributes, and
relationships among different entity sets. Once we have these information, we represent them
pictorially, called an entity-relationship (ER) diagram.

Graphical Notations for ER Diagram

Term Notation Remarks

Name of the set is

Entity set written inside the
rectangle

Name of the attribute is

Attribute
written inside the ellipse

Roll is the primary key;

Entity with
denoted with an
attributes
underline

Weak entity set

Name of the relationship

Relationship set is written inside the
diamond

Related enity
sets

A person can own zero or

Relationship more cars but no two
cardinality persons can own the
same car

Relationship
with weak entity
set

Importance of ER modeling
Entity-Relationship (ER) modeling plays a crucial role in the database design process for several
important reasons:

1. Clarity and Visualization:ER diagrams provide a visual representation of the entities, attributes, and
relationships within a database. This visual clarity helps both database designers and stakeholders
understand the structure and organization of data.

2. Requirement Understanding: ER modeling begins with the identification of entities, attributes, and
relationships based on the problem statement. This process helps in the precise understanding of the
system's requirements and data needs.

3. Data Integrity: By modeling relationships and constraints in ER diagrams, database designers can
enforce data integrity rules, ensuring that data is accurate and consistent throughout the database.

4. Normalization: ER modeling guides the process of database normalization, which eliminates data
redundancy and optimizes data storage. This leads to more efficient database operations and
reduces the risk of data anomalies.

5. Communication: ER diagrams serve as a common language between stakeholders, including

designers, developers, and business analysts. They facilitate communication and collaboration in the
database design process.

In summary, ER modeling is a critical initial step in the database design process, helping to define and
visualize the database's structure, constraints, and relationships. It ensures that data is organized
efficiently, accurately, and in a way that supports the system's functional requirements.

Case Study
Let's consider a scenario for a Hospital Management System (HMS) and develop a simplified ER
(Entity-Relationship) model for it:

Entity Sets and Attributes:

1. Patient

- Attributes: PatientID (PK), Name, Age, Gender, ContactNumber, Address

- Super Key: PatientID

- Primary Key (PK): PatientID

2. Doctor

- Attributes: DoctorID (PK), Name, Specialization, ContactNumber

- Super Key: DoctorID

- Primary Key (PK): DoctorID

3. Appointment

- Attributes: AppointmentID (PK), Date, Time, PatientID (FK), DoctorID (FK)

- Super Key: AppointmentID

- Primary Key (PK): AppointmentID

 - Foreign Key (FK): PatientID (references Patient), DoctorID (references Doctor)

4. MedicalRecord

- Attributes: RecordID (PK), PatientID (FK), DoctorID (FK), Diagnosis, Medication

- Super Key: RecordID

- Primary Key (PK): RecordID

- Foreign Key (FK): PatientID (references Patient), DoctorID (references Doctor)

5. Billing

- Attributes: BillID (PK), PatientID (FK), Amount, PaymentStatus

- Super Key: BillID

- Primary Key (PK): BillID

- Foreign Key (FK): PatientID (references Patient)

Relationships:

1. Patient-Doctor Relationship

- Each patient can have a primary doctor.

- Attributes: None (relationship only).

2. Doctor-Appointment Relationship

- Each doctor can have multiple appointments.

- Each appointment is associated with one doctor.

- Attributes: None (relationship only).

3. Patient-Appointment Relationship

- Each patient can have multiple appointments.

- Each appointment is associated with one patient

4. Patient-MedicalRecord Relationship

- Each patient can have multiple medical records.

- Each medical record is associated with one patient.

- Attributes: None (relationship only).

5. Doctor-MedicalRecord Relationship

- Each doctor can be associated with multiple medical records.

- Each medical record is associated with one doctor.

- Attributes: None (relationship only).

Estimation of Project Metrics
introduction
in the process of initiating a software project, it's essential to follow a systematic approach to
determine the most suitable solution strategy.

1. Requirement Gathering: Collect all project-specific requirements, including goals, features, and
constraints.

2. Expert Analysis: Have experienced business analysts assess the proposed solutions for their
benefits and shortcomings.

3. Estimation: Estimate the project's cost, effort, and duration for each solution option.

4. Resource Evaluation: Check the availability of necessary resources, including skills and tools.

5. Risk Assessment: Identify and evaluate potential risks associated with each solution.

6. Solution Selection: Choose the best-suited approach based on analysis, estimation, resource
availability, and risk assessment.

7. Documentation and Planning: Document the chosen approach and create a project plan.

8. Monitoring: Continuously monitor project progress and adjust as needed to stay on track.

This streamlined process helps in making informed decisions for software project strategies while
managing resources and risks effectively

Objectives
After completing this experiment you will be able to:

•Categorize projects using COCOMO, and estimate effort and development time required for a
project

•Estimate the program complexity and effort required to recreate it using Halstead's metrics

Project Estimation Techniques Project estimation is a critical aspect of software project planning. It
involves quantifying various project parameters to make informed decisions. Here are the key project
estimation techniques and the parameters they address:

1. Size Estimation:

- Lines of Code (LOC): Measure the size of the software by counting the lines of code.

- Function Points: Evaluate the software's functionality to estimate size based on inputs, outputs,
inquiries, files, and external interfaces.

- Story Points: Commonly used in agile methodologies, it assesses the size of user stories or
features.
2. Cost Estimation:

- COCOMO (Constructive Cost Model): Employs mathematical formulas to estimate project cost
based on project size, complexity, and other factors.

- PERT (Program Evaluation and Review Technique): Uses statistical techniques to calculate cost
estimates by considering optimistic, pessimistic, and most likely scenarios.

- Bottom-Up Estimation: Sum the costs of individual project components, such as labor, materials,
and overhead.

3. *Duration Estimation:

- PERT: In addition to cost estimation, PERT can be used to estimate project duration by analyzing
the critical path and considering time estimates for individual tasks.

- Gantt Charts: Create a timeline of project tasks and dependencies to visualize and estimate
project duration.

- Monte Carlo Simulation: A probabilistic method that factors in uncertainties to estimate project
duration.

4. Effort Estimation:

- Expert Judgment: Rely on experienced team members or experts to estimate the effort required
based on their domain knowledge.

- Use Case Points: Estimate effort by analyzing the complexity of use cases and the number of
actors involved.

- Work Breakdown Structure (WBS): Divide the project into smaller tasks and estimate effort for
each task, then sum them up.

Effort estimation is closely related to both project size and duration. Accurate size estimation helps
determine the effort required, while duration estimation considers how the effort is distributed over
time. Cost estimation, on the other hand, helps assess the financial resources needed to complete
the project successfully.

It's important to note that project estimation is an iterative process and should be updated as the
project progresses and more information becomes available. Additionally, historical data and lessons
learned from previous projects can be valuable in improving the accuracy of future project
estimations.

COCOMO
The Constructive Cost Model (COCOMO) proposed by Barry Boehm provides a framework for
estimating software project parameters. COCOMO recognizes three categories of software projects,
each with distinct characteristics, and suggests a three-stage estimation process:

1. Basic COCOMO: This initial stage provides a rough estimate of project parameters based on the
type of project. The three project types are:
 - Organic: This type applies to well-understood applications, small development teams, and
experienced team members. Estimation in this stage is relatively simple and based on project size.

- Semidetached: For projects that have a mix of experienced and inexperienced staff, with some
familiarity with the project type. Estimation considers both size and team capability.

- Embedded: Used for projects closely tied to hardware, typically involving larger teams. Estimation
in this stage accounts for project size, team size, and hardware constraints.

2. Intermediate COCOMO: This stage refines the estimates by considering additional factors like
software reliability, complexity, and documentation. It provides a more detailed estimate of effort,
cost, and duration based on these factors.

3. Complete COCOMO: The final stage of COCOMO incorporates even more factors, such as product
attributes, hardware attributes, personnel attributes, and project attributes. It offers the most
comprehensive and accurate estimation by taking into account a wide range of project-specific
variables.

In summary, COCOMO is a progressive estimation approach that begins with a basic assessment of
the project type and size and gradually incorporates more detailed factors to refine the estimates.
This three-stage process helps project managers and stakeholders make more accurate and informed
decisions about resource allocation, scheduling, and budgeting for software development projects.

Basic COCOMO Model

In the Basic COCOMO model, which provides a rough estimate of project parameters, the effort and
time required for software development are estimated using the following formulas:

1. Effort (in person months - PM):

Effort = a * (KDSI)^b

- KDSI is the estimated size of the software in Kilo Delivered Source Instructions.

- 'a' and 'b' are constants determined by the category of the software project.

2. Development Time (in months):

Tdev = 2.5 * (Effort)^c

- Effort is the total effort required for software development, calculated in person months (PMs).

- 'c' is another constant determined by the category of the software project.

These formulas help in estimating the effort and time required to complete a software development
project based on the estimated size of the software and the project category-specific constants. It
provides a preliminary understanding of the project's resource and time requirements.

Intermediate COCOMO Model

Indeed, the Intermediate COCOMO model enhances the estimation process by considering a broader
set of project parameters, which are represented by 15 cost drivers. These cost drivers account for
various factors that influence software development efforts and costs. Each cost driver is rated on a
six-point scale to assess its impact, and each rating corresponds to an effort multiplier. These effort
multipliers are then used to calculate the Effort Adjustment Factor (EAF), which refines the effort
estimation based on the specific project's characteristics.

The 15 cost drivers include factors such as product attributes, hardware constraints, personnel
experience, and project attributes, among others. By taking these factors into account, the
Intermediate COCOMO model provides a more accurate and detailed estimate of effort and cost
compared to the Basic COCOMO model, which primarily relies on software size.

The EAF is calculated as the product of the effort multipliers for all 15 cost drivers, and it is used to
adjust the effort estimate obtained from the Basic COCOMO model. This adjustment factor accounts
for the project's unique characteristics and complexities, resulting in a more tailored and precise
estimation.

In summary, the Intermediate COCOMO model enhances the estimation process by considering a
wide range of project parameters and their impacts, allowing for more accurate and realistic project
planning and resource allocation.

EAF is used to refine the estimates obtained by basic COCOMO as follows:

Effort|corrected = Effort * EAF

Tdev|corrected = 2.5 * (Effort| corrected) c

Complete COCOMO Model

The Complete COCOMO model recognizes that software projects are often composed of multiple
interconnected components or subsystems, each with its unique characteristics. This model provides
a more accurate estimate of project metrics by accounting for these diverse elements. To illustrate
this, let's consider the example of the Indian Railways ticket booking system, which consists of three
main components: the Database, the Graphical User Interface (GUI), and Networking facilities.

In this scenario:

1. GUI Development (Organic Project Type): The GUI development is considered an organic project
type because it deals with a well-understood application, and it may involve a small development
team with prior experience in similar projects. Estimates for this component are based on organic
project parameters.

2. Database Module (Semidetached Software): The database module is categorized as semidetached

software, as it might involve a mix of experienced and inexperienced team members and has some
familiarity with the project type. Estimates for this component consider semidetached project
parameters.

3. Networking Module (Embedded Software): The networking module is seen as embedded software
because it is strongly related to machine hardware, and it typically requires a larger team.
Estimations for this component take into account embedded project parameters.

To obtain a realistic cost estimate for the entire ticket booking system, you would estimate the costs
for each of these components separately, considering their respective project types. Once you have
the individual estimates, you can add them up to get the overall project cost. This approach allows
for a more accurate assessment of the project's total effort, cost, and duration by acknowledging the
unique characteristics of each subsystem within the larger software project.
Advantages of COCOMO
COCOMO (Constructive Cost Model) offers several advantages for software project estimation and
management:

1. Structured Estimation: COCOMO provides a structured and systematic approach to estimating

software project parameters, including effort, cost, and duration. This structured approach ensures
that estimation is based on well-defined criteria and project-specific factors.

2. Adaptability: COCOMO comes in different variants, such as Basic, Intermediate, and Complete
COCOMO, allowing organizations to choose the level of detail and complexity that best suits their
project's needs. This adaptability makes it applicable to a wide range of projects.

3. Accuracy Improvement: Intermediate and Complete COCOMO models consider a broader set of
project parameters and factors, leading to more accurate estimates. By including cost drivers, effort
multipliers, and other variables, COCOMO can better account for the complexities and nuances of
individual projects.

4. Risk Assessment: COCOMO encourages the identification and assessment of various project risks
through its consideration of factors like personnel experience, hardware constraints, and other
attributes. This helps project managers proactively address potential challenges.

5. Comparative Analysis: COCOMO allows for the comparison of different project alternatives and
strategies. By estimating multiple scenarios, organizations can choose the most cost-effective and
efficient approach.

6. Project Planning: Accurate estimates provided by COCOMO aid in project planning and resource
allocation. Organizations can better determine staffing levels, schedules, and budgets based on these
estimates.

7. Progress Monitoring: COCOMO estimates serve as a baseline for monitoring project progress. By
comparing actual progress to the estimated values, project managers can identify deviations and
take corrective actions.

8. Communication: COCOMO provides a common language for discussing project estimates and
parameters within the organization and with stakeholders. This facilitates effective communication
and decision-making.

9. Historical Data Utilization: Organizations can use historical data from past projects to refine and
improve COCOMO estimates over time. This iterative process can lead to increasingly accurate
estimates.

10. Industry Standard: COCOMO is a well-established and widely recognized model in the software
engineering field. Its use is prevalent, making it easier for organizations to find resources, tools, and
expertise related to COCOMO-based estimation.

In summary, COCOMO offers a structured, adaptable, and comprehensive approach to software

project estimation, contributing to more accurate planning, better risk management, and effective
decision-making in software development projects.

Drawbacks of COCOMO
While COCOMO (Constructive Cost Model) is a valuable tool for estimating software project
parameters, it also has some drawbacks and limitations:

1. Sensitivity to Input Values: COCOMO estimates are highly sensitive to the input values used, such
as project size, complexity ratings, and effort multipliers. Small changes in these inputs can lead to
significant variations in the estimated effort, cost, and duration.

2. Complexity: Intermediate and Complete COCOMO models, which provide more accurate
estimates, can be quite complex and require a substantial amount of data and effort multiplier
ratings. Collecting and maintaining this data can be resource-intensive.

3. Dependency on Historical Data: COCOMO relies on historical data from past projects to calibrate
its parameters and effort multipliers. If an organization lacks relevant historical data, the model may
not be as effective.

4. Assumption of Linearity: COCOMO assumes a linear relationship between project size and effort.
In reality, software development efforts may not scale linearly with size, especially in large and
complex projects.

5. Limited Scope: COCOMO primarily focuses on effort and cost estimation, which are essential but
may not capture all aspects of project success or failure, such as quality, customer satisfaction, or
technical debt.

6. Applicability to Specific Projects: COCOMO may not be well-suited for certain types of projects,
such as highly innovative or research-oriented endeavors, where historical data and standard
practices may not apply.

7. Static Estimation: COCOMO provides estimates at the beginning of a project based on limited
information. As the project progresses and more data becomes available, the initial estimates may
need to be adjusted, and COCOMO does not inherently provide a mechanism for dynamic updating.

8. Not Accounting for Agile Practices: COCOMO was developed before agile methodologies became
widespread. Agile projects with iterative development and changing requirements may not fit well
within the COCOMO framework.

9. Human Error: Estimation is subject to human judgment and bias when input values are
determined, effort multipliers are assigned, or historical data is interpreted. This can introduce
inaccuracies.

10. Limited Industry-Specific Factors: COCOMO does not explicitly consider industry-specific factors
or domain knowledge, which can significantly impact software development efforts in certain fields.

In summary, while COCOMO is a valuable estimation model, it has limitations related to its sensitivity
to input values, complexity, and applicability to specific project types. Organizations should carefully
consider these drawbacks and weigh them against the benefits when using COCOMO for project
estimation.

Halstead's Complexity Metrics

In short, Maurice Halstead's software metrics approach quantifies the complexity and effort required
for a computer program using four key parameters:
1. n1: Number of unique operators used in the program.

2. n2: Number of unique operands (variables or constants) used in the program.

3. N1: Total number of operators used in the program.

4. N2: Total number of operands used in the program.

These parameters are then used to compute various metrics:

- Program Length (N): The total length of the program, calculated as N = N1 + N2.

- Program Vocabulary (n): The total number of unique operators and operands, calculated as n = n1 +
n2.

- Volume (V): A measure of program size, representing the minimum number of bits needed to
encode the program. It's calculated as V = N * log2(n).

- Difficulty (D): Indicates how challenging the program is to write or understand. It's computed as (n1
* N2) / (2 * n2).

- Effort (E): Represents the "mental effort" required to develop the software, or to recreate it in
another programming language. It's calculated as E = D * V.

- Time to Implement (T): The estimated time it would take to implement the program, measured in
seconds. It's calculated as T = E / 18.

This approach provides a quantitative way to assess the complexity and effort involved in software
development, taking into account both the number and uniqueness of operators and operands used
in the program. It can help in project planning, resource allocation, and understanding the challenges
associated with software development.
Modeling UML Use Case Diagrams and Capturing
Use Case Scenarios
Introduction
In brief, a use case diagram is a graphical representation used in software engineering to:

1. Capture Functionality: It helps document the basic functionality of a system, typically by

illustrating the various actions or processes (use cases) that the system can perform.

2. Define Users: It identifies the different types of users or external entities (actors) who interact with
the system to perform these actions or use cases.

3. Visualize Relationships: It provides a visual way to depict how these actors and use cases are
related, showing who interacts with what in the system.

Use case diagrams are valuable tools for communication and understanding within a project team.
They help stakeholders, including end-users, developers, and domain experts, to get a clear and
shared understanding of the system's functionality and its interactions with external entities. This
understanding is crucial for effective system design and development.

Objectives
After completing this experiment you will be able to:

How to identify different actors and use cases from a given problem statement

How to associate use cases with different types of relationships

How to draw a use-case diagram

Use case diagrams

In short, use case diagrams are part of the behavioral diagrams in UML and are used to provide a
graphical overview of the functionality of a system. Here are the key components of use case
diagrams:

1. Actor: Actors are external entities that interact with the system to accomplish certain tasks. They
can be humans, devices, or other systems. There are two main types of actors:

- Primary Actor: These are the principal users of the system who achieve their goals by using the
system's services. For example, a customer using an ATM is a primary actor.

- Supporting Actor: These actors provide services to the system but are not the primary users. An
example could be bank representatives who replenish cash in ATMs. This is not the primary function
of an ATM.

2. Use Case: A use case represents a specific functionality or action that the system can perform. For
instance, in the context of an ATM, "withdraw cash" is a use case, and so is "check balance" or
"change PIN." Use cases can cover both successful and unsuccessful scenarios, like a failed PIN entry
leading to an error message.
3. Subject: The subject is the system under consideration, and use cases apply to it. In the example of
an ATM, the ATM itself is the subject. It contains multiple use cases, and various actors interact with
it. External systems can also interact with the subject, but they are treated as actors.

4. Graphical Representation: In use case diagrams:

- Actors are depicted as stick figures with their names written below.

- Use cases are represented as ellipses with their names inside.

- The subject (system) is shown as a rectangle, and its label can be placed inside it.

- Use cases are placed inside the rectangle, while actors are positioned outside the rectangle.

Use case diagrams are valuable for illustrating how actors interact with a system to achieve specific
tasks or functionalities, making them a useful tool for communication and understanding in software
design and development.

Association between Actors and Use Cases

In short, in a use case diagram:

- A use case is initiated or triggered by an actor.

- Actors and use cases are linked through binary associations, representing communication through
message passing.

- Each actor must be associated with at least one use case.

- Similarly, each use case must be associated with at least one actor.

- Associations among actors are typically not displayed in the diagram, but you can show class
hierarchies among actors if needed.

These associations help illustrate how actors interact with specific use cases within the system,
providing a clear visual representation of the system's functionality and user interactions.
Use Case Relationships
Three types of relationships exist among use cases:

Include relationship

Extend relationship

Use case generalization

Include Relationship
In brief, "include" relationships in use case diagrams are used to represent common behavior shared
by multiple use cases. This relationship is similar to writing functions or reusable code snippets in a
program to avoid repetition. Just as a function can be called from different parts of a program, the
included use case can be invoked by multiple other use cases to ensure that common functionality is
not duplicated throughout the system. This promotes modularity and reduces redundancy in the
system's design.

For instance, consider the scenario of an email application where users can perform various actions
like composing, replying to, or forwarding emails. In each of these use cases, the precondition is that
the user must be logged in. Instead of duplicating the login process within each of these use cases,
the "Login" use case is created separately and then included by the "Compose Mail," "Reply to
Email," and "Forward Email" use cases. This relationship ensures that the login functionality is shared
and executed when necessary, streamlining the design and making it more modular.

The "include" relationship is a powerful concept in use case modeling that enhances the clarity,
reusability, and maintainability of a system's design by encapsulating common behaviors efficiently.

Extend Relationship
In brief, use case extensions, represented by the "extend" relationship in use case diagrams, are used
to depict variations or deviations from an existing use case when certain assumptions made by that
use case become false. Here's an example to illustrate this concept:

Imagine an online bookstore system:

- The main use case is "Place Order," where an authenticated user can buy selected books.

- While placing an order, the system allows the user to specify special shipping instructions, such as
requesting a call before delivery.

- However, this "Shipping Instructions" step is optional and not a fundamental part of the primary
"Place Order" use case.

In this scenario, an "extend" relationship can be used to show that the "Shipping Instructions" use
case extends the "Place Order" use case. It represents an optional deviation from the main process.
This extension mechanism allows for flexibility in capturing variations in behavior while keeping the
main use case focused on its primary objectives.

In summary, "extend" relationships in use case diagrams help document variations or optional
behaviors that occur when specific conditions are met, providing a more comprehensive
understanding of how a system can accommodate different scenarios.

Generalization Relationship
In brief, the "extend" relationship in use case diagrams is used to illustrate variations or optional
behaviors that extend an existing use case when certain conditions are met. It provides a way to
capture and visualize how a system can adapt to different scenarios without cluttering the main use
case with every possible detail or deviation. This helps in maintaining a clear and concise
representation of the system's functionality and behavior.

In brief, consider a graphical application for drawing polygons:

- There's a primary use case called "Draw Polygon," which represents the ability to draw any polygon.

- "Rectangle" is a specific type of polygon with four sides at right angles to each other.

- The "Draw Rectangle" use case inherits the properties of the "Draw Polygon" use case but also
overrides its drawing method to specialize in drawing rectangles.

- Likewise, there's a "Draw Square" use case that inherits properties from "Draw Rectangle."

This scenario demonstrates a "generalization" relationship in use case modeling. It shows how more
specific use cases inherit behaviors and characteristics from more general use cases. In this way, use
cases can be organized hierarchically to represent different levels of abstraction and specialization in
a system.
Identifying Actors
In brief, when identifying actors in a system based on a problem statement, you can ask the following
questions:

1. Who Benefits Most: Determine who primarily benefits from using the system. This identification
leads to the primary actor—the main user who gains the most from the system's functionality.

2. System Maintenance: Identify individuals or entities responsible for keeping the system
operational. This can help create a list of potential secondary actors who interact with the system for
maintenance or support.

3. External Interactions: Consider any external software or hardware components that the system
interacts with. These external elements may be additional actors in the system.

4. System Interfaces: Explore whether there are interfaces or interactions between the system in
question and other external systems. If such interactions exist, the external systems may also be
considered as actors in your use case diagram.

By answering these questions, you can comprehensively identify the actors involved in the system,
providing a clear understanding of who interacts with the system and in what capacity. This
information is crucial for creating accurate and useful use case diagrams.

Identifying Use cases

In brief, to identify use cases for a system, follow these steps:

1. Identify Actors: First, determine the primary and secondary actors who interact with the system.
These are the individuals or entities that have specific goals or functionalities they want to achieve
using the system.

2. Define Goals: For each actor, identify their specific goals or functionalities they aim to accomplish
through interactions with the system. What tasks or actions do they need to perform?

3. Use Case Naming: When naming use cases, it's a good practice to start the name with a verb that
describes the action or functionality the use case represents. For example, "Check Balance," "Place
Order," "Send Message," etc.
By following these steps, you can systematically identify and name use cases based on the goals and
functionalities that actors want to achieve within the system. This helps create a comprehensive list
of use cases that accurately represent the system's intended functionality.

Guidelines for drawing Use Case diagrams

In brief, when drawing a use case diagram, consider the following guidelines:

1. Define the System Boundary: Clearly determine the boundary of the system you are modeling.
This helps establish what's inside the system and what interactions occur with external entities.

2. Clarify Actor Roles: Ensure that each actor in the diagram has a well-defined purpose and role
within the system. Actors should represent distinct individuals, entities, or systems that interact with
the system.

3. Meaningful Use Cases: Identify use cases that represent meaningful and purposeful actions or
functionalities that actors need to perform within the system.

4. Establish Connections: Connect actors to the relevant use cases. There should be a clear
association between actors and use cases, indicating how actors interact with the system through
these use cases.

5. Include Relationships: Use "include" relationships when there is common behavior shared among
use cases. This helps encapsulate and reuse functionality, promoting modularity and reducing
redundancy.

Case Study
Let's consider another scenario for a Project Management System (PMS) and develop a set of use
cases along with their details:

Project Description:

A software development company, TechPro Solutions, is planning to implement a Project

Management System (PMS) to efficiently handle its ongoing projects. The PMS should allow project
managers, developers, and clients to collaborate on project-related activities, monitor progress, and
ensure timely delivery of projects.

Actors:

1. Project Manager: Manages and oversees project activities.

2. Developer: Works on project tasks assigned by the project manager.

3. Client: Monitors project progress and provides feedback.

Use Cases:

1. Create Project

- Description: Allows a project manager to create a new project in the system.

- Assumptions: The project manager is logged in.

- Actors: Project Manager

 - Steps:

1. Project manager clicks on the "Create Project" button.

2. Project manager enters project details (name, description, start date, end date).

3. System validates and creates the project.

2. UC2: Assign Task

- Description: Enables a project manager to assign a task to a developer.

- Assumptions: The project manager is logged in, and the project is already created.

- Actors: Project Manager, Developer

- Steps:

1. Project manager selects a project.

2. Project manager clicks on the "Assign Task" button.

3. Project manager selects a developer and assigns a task.

4. System notifies the developer about the assigned task.

3. Update Task Status

- Description: Allows a developer to update the status of a task.

- Assumptions: The developer is logged in and has been assigned tasks.

- Actors: Developer

- Steps:

1. Developer selects a task.

2. Developer updates the task status (in-progress, completed, etc.).

3. System updates the task status and notifies the project manager.

4. View Project Progress

- Description: Permits a client to view the progress of a specific project.

- Assumptions:The client is logged in and associated with the project.

- Actors: Client

- Steps:

1. Client selects a project.

2. Client views project details, tasks, and their statuses.

Table 7: Use Case Extension for Project Management System

 Use Case Extension
Update Task Status extends. Assign Task

Deals with the condition when a developer has not updated the
task status within the expected timeframe, and the project
Description manager needs to follow up.

2a. IF task status is not updated within the specified time limit
Steps THEN invoke "Update Task Status"
If the developer updates the task status within the expected
Exceptions timeframe, no action is taken.
Actors Project Manager, Developer

Conditions The project manager has set a time limit for task completion.
The system detects that the task status has not been updated
Triggers within the specified time.

The use case diagram above illustrates the interactions between different actors and use cases in the
Project Management System. Each use case is associated with specific actors, and their details
provide a clear understanding of the steps involved in each activity. This modeling helps in visualizing
the functionalities and user interactions within the system
Identifying Domain Classes from the Problem
Statements
Introduction
In brief, in object-oriented programming, classes are used to represent and encapsulate objects with
similar properties and behaviours. Identifying the classes that make up the structural units of a
system is a crucial step in system design. In this experiment, we will focus on how to identify these
classes from a given problem statement. This process involves recognizing objects with common
attributes and behaviors, which can be grouped into classes, forming the foundation for building the
system's structure and logic.

Objectives

After completing this experiment you will be able to:

Understand the concept of domain classes

Identify a list of potential domain classes from a given problem statement

Domain Class
In brief, in the Object-Oriented paradigm, the Domain Object Model is a valuable tool for
understanding and solving complex problems in software design. The core of this model is formed by
Domain Classes, which are abstractions of key entities, concepts, or ideas described in the problem
statement. These classes play a crucial role in representing business activities during the analysis
phase of software development. In essence, Domain Classes help create a conceptual model that
provides a deep understanding of the problem at hand, aiding in the design of effective and well-
structured software systems.

Traditional Techniques for Identification of Classes

In short, the Grammatical Approach Using Nouns is a technique for identifying potential classes in
object-oriented programming. Proposed by Russell J. Abbot and popularized by Grady Booch, this
technique involves the following steps:

1. Obtain the user requirements in the form of a descriptive English text, which essentially represents
the problem statement or use-case diagram.

2. Analyze the text to identify and highlight nouns, pronouns, and noun phrases.

3. Create a list of potential classes based on the category of the identified nouns. For instance:

- Nouns referring to specific persons, places, or entities typically correspond to individual objects.

- Singular proper nouns can also represent individual objects.

- Plural nouns and common nouns often map to classes in the system.

This approach helps systematically identify classes by recognizing and categorizing relevant linguistic
elements in the problem statement, facilitating the initial stages of object-oriented design.

Advantages
This is one of the simplest approaches that could be easily understood and applied by a larger
section of the user base. The problem statement does not necessarily be in English, but in any other
language.

Disadvantages
The problem statement always may not help towards correct identification of a class. At times it
could give us redundant classes. At times the problem statement may use abbreviations for large
systems or concepts, and therefore, the identified class may actually point an aggregate of classes. In
other words, it may not find all the objects.

Case Study
Online Shopping System

An e-commerce company, TechMart, is planning to develop an Online Shopping System (OSS) to

provide a seamless shopping experience for customers. The system will allow users to browse
products, add them to the cart, make purchases, and track their orders. The final deliverable will be a
web application using the latest web technologies.

Identified Nouns and Noun Phrases:

1. Customers

2. Company

3. Online Shopping System

4. Users

5. Products

6. Cart

7. Purchases

8. Orders

9. Web application

10. Technologies

Categorized List:

People:

- Customers

- Users

Organizations:

- Company

Things:

- Products
- Cart

- Purchases

- Orders

Concepts:

- Online Shopping System

- Web application

- Technologies

Relevant Classes:

1. Customer/User:

- Attributes: Name, Unique ID, Email, Address

- Methods: BrowseProducts, AddToCart, MakePurchase, TrackOrder

2. Company:

- Attributes: Name, Location, ContactInfo

- Methods: ManageProducts, ProcessOrders, CustomerSupport

3. Product:

- Attributes: ProductID, Name, Price, StockAvailability

- Methods: DisplayDetails, CheckAvailability

4. Cart:

- Attributes: CartID, Contents, TotalPrice

- Methods: AddItem, RemoveItem, CalculateTotal

5. Purchase:

- Attributes: PurchaseID, CustomerID, Products, TotalAmount

- Methods: GenerateReceipt, ConfirmPurchase

6. Order:

- Attributes: OrderID, CustomerID, Products, Status

- Methods: TrackOrderStatus, UpdateStatus

Use Case Diagram:

The identified classes can be associated with various use cases in the system. For example:

- Browse Products

- Add to Cart
- Make Purchase

- UC4: Track Order

Conclusion:

The above example demonstrates how the process of identifying relevant classes can lead to the
modeling of design and implementation classes in a system. The identified classes serve as the
foundation for further system design and development activities.
Statechart and Activity Modeling
Introduction
In software development, understanding and capturing the dynamic aspects of a system is crucial for
developers to create effective logic and functionality. Two widely used tools for visualizing the
dynamic behavior of an information system in the field of Unified Modeling Language (UML) are
state chart diagrams and activity diagrams.

In this experiment, our focus is to delve into the distinct components of activity diagrams and state
chart diagrams, and to learn how these diagrams can be employed to represent the dynamic nature
of an information system:

1. **Activity Diagrams**: Activity diagrams are graphical representations that illustrate the flow of
activities and actions within a system. They are used to model the dynamic aspects of a system,
showing how various activities are connected and the order in which they are executed. Key
components of an activity diagram include actions, decisions, forks, and joins, which collectively
provide a clear visualization of process flow. Activity diagrams are valuable for understanding the
sequence of tasks and processes in a system.

2. **State Chart Diagrams**: State chart diagrams are employed to depict the various states and
transitions that an object or system undergoes in response to events. These diagrams are particularly
useful for modeling the behavior of objects or entities over time. They consist of states, transitions,
events, and actions. State chart diagrams are essential for illustrating the dynamic lifecycle of an
entity, showcasing how it transitions between different states and responds to external events.

Objectives
• Identify the distinct states a system have
• Identify the events causing transitions from one state to another
• Identify activities representing basic units of work, and represent their flow

Statechart Diagrams
Statechart diagrams are a valuable tool in Object-Oriented Analysis and Design (OOAD) for
abstracting and visualizing the behavior and states of a system. They provide a pictorial
representation of a system's states, along with the various events that trigger transitions between
those states.
To illustrate this concept, let's consider a computer as an example. A computer can exist in different
states such as "running," "shutdown," or "hibernate." Statechart diagrams depict these states and
the transitions between them. For instance, when a user presses the "Power off" switch or clicks the
"Shut down" button provided by the operating system, it triggers a transition from the "running"
state to the "shutdown" state. These user actions are considered external events that drive the
system's state transitions.

Statechart diagrams are typically used to model the behavior of complex systems, where
understanding how the system responds to different events and transitions between states is
essential. In simpler systems, these diagrams may be considered optional. However, for complex
systems, they serve as a powerful tool to provide a clear, visual representation of a system's dynamic
behavior, making it easier to analyze, design, and implement software systems effectively.

Building Blocks of a Statechart Diagram State

In a statechart diagram, the building blocks that represent the various states are essential
components. These states can be categorized into three main types:

1. Initial State: This is the state in which an object or system resides when it is created. It represents
the starting point of the system's lifecycle. In statechart diagrams, an initial state is typically depicted
as a filled black circle.

2. Final State: The final state is a point from which an object or system does not transition to any
other state. It signifies the end of the system's lifecycle. In statechart diagrams, a final state is usually
represented by an unfilled circle with an inner black-filled circle. Note that final states are optional,
and not all statechart diagrams include them.

3. Intermediate State: Intermediate states are the states that fall between the initial and final states.
These states are where the system spends a finite amount of time, and they are subject to transitions
triggered by events. Intermediate states are represented by rectangles with rounded corners.

For intermediate states, two key compartments are often used:

• Name Compartment: This contains a short, descriptive name for the state, providing clarity
about the state's purpose.
• Internal Transitions Compartment: This compartment lists internal activities that occur while
the system is in this state. Internal activities are indicated using a specific syntax, such as
action-label / action-expression. The action labels can include "Entry" (for activities
performed when entering the state), "Exit" (for activities performed when exiting the state),
"Do" (for activities performed while remaining in the state or until an action expression is
completed), and "Include" (for invoking a sub-machine). Other action labels correspond to
events that trigger the associated actions, similar to self-transitions. Internal transitions do
not involve entering or exiting the state.

States can further be categorized as either simple or composite, with composite states containing
other states within them. However, this explanation focuses on simple states. Understanding these
building blocks is essential for effectively representing the dynamic behavior of a system in statechart
diagrams.
Transition
Transitions are fundamental elements in statechart diagrams, representing the movement from one
state to another in response to external stimuli or internal events. A transition is visually depicted as
a solid arrow that connects the current state to the next state, and it is labeled with specific
information:

1. Event: This is a description of what triggers the transition and is typically written in the past tense.
It's a mandatory part of the transition label. For example, "Button Clicked" or "Power Off Request"
could be events that cause a transition.

2. Guard Condition: Guard conditions are preconditions that must be true for the transition to occur.
They act as criteria that determine whether the transition should take place. Guard conditions are
enclosed in square brackets, and if they evaluate to false, the system will remain in the current state.
This part of the label is optional.

3. Action Expression: Action expressions indicate actions or activities that are performed as a result
of the transition. These actions are optional and are enclosed in square brackets as well. They
describe what happens when the transition occurs.

For instance, if a queue is full and an attempt is made to append an item to it, this action may not
result in a state change. Instead, the system continues to stay in its current state until specific
conditions or actions are met, like invoking a delete method to free up space in the queue. Transition
labels help provide a clear understanding of the conditions and actions associated with state changes
in the system, contributing to effective modeling and analysis of the system's dynamic behavior.

Action
Actions in a statechart diagram represent the behavior and activities of the system. When the system
is in the process of executing an action for the current event, it typically doesn't accept or process
new events until the action is completed. The order in which different actions are executed is as
follows:

1. Exit Actions of the Present State: Before leaving the current state, any actions specified as "Exit"
actions for that state are executed. These actions are performed as the system exits the state.

2. Actions Specified for the Transition: Actions associated with the specific transition that led from
the current state to the next state are executed. These actions are performed in response to the
triggering event that caused the transition.

3. Entry Actions of the Next State: Once the system enters the next state, any actions specified as
"Entry" actions for that state are executed. These actions are performed as the system enters the
new state.

This order of execution helps define the sequence of activities and behavior that occurs during state
transitions and is crucial for understanding and modeling the dynamic behavior of a system.

Guidelines for drawing Statechart Diagrams

Creating a statechart diagram involves several steps to effectively represent the dynamic behavior of
a system:
1. Identify Distinct States: Begin by identifying the distinct states that the system passes through
during its operation. These states are the various stages or conditions that the system can exist in.
For example, in a vending machine, states might include "Idle," "Selecting Item," "Dispensing," and
"Change Dispensed."

2. Identify Events and Preconditions for Transitions: Determine the events or triggers that cause
transitions between these states. Events can be external stimuli or internal conditions. Additionally,
consider any preconditions or guard conditions that must be met for a transition to occur. Events
could be actions like "Button Press," "Timer Expiration," or "Inventory Empty."

3. Identify Activities within States: For each state, identify what activities or actions are performed
while the system remains in that state. These activities describe what the system does when it's in a
particular state. Activities can include tasks, processes, or operations specific to that state. For
example, in the "Dispensing" state of a vending machine, activities may involve releasing the product
and updating the inventory.

By following these steps, you can systematically identify states, events, and activities to create a
comprehensive statechart diagram. This diagram provides a visual representation of how the system
behaves as it transitions between states in response to various events, aiding in the understanding,
design, and development of complex systems.

Activity Diagrams

Activity diagrams in UML are high-level diagrams that represent the flow of control in a system. They
are similar to flowcharts but more powerful, as they can handle concurrent activities and their
joining. Activity diagrams are used to confirm complex business logic and help stakeholders
understand a system's behavior. They are not meant for direct code translation and can be avoided in
simpler scenarios.

Components of an Activity Diagram

Activity diagrams in UML consist of several components that visually represent the logical flow of
control within a system. These components help model complex processes and are typically used in
software design and business process modeling. Here's a brief overview of the key components:

1. Activity: An activity represents a specific action or task in the control flow. It can be something like
invoking a mathematical function, altering an object's properties, or any other operation. Activities
are depicted as rounded rectangles with labels inside, identifying the corresponding action.

2. Initial Node: Represented by a filled circle, the initial node indicates the starting point of a flow in
the activity diagram. Multiple initial nodes may exist, initiating multiple flows when invoking the
activity diagram.

3. Final Node: Final nodes are represented by a filled circle with a border. They denote the endpoint
of all activities, and any transition reaching a final node terminates all activities.

4. Flow (Edge/Transition): Flows are directed arrows used to depict the transfer of control from one
activity to another. They can be accompanied by a guard condition, which is a necessary condition for
the transition to occur and is enclosed in square brackets, e.g., [guard condition].
5. Decision Node: A decision node is represented by a diamond shape and is where a single flow
enters, but two or more flows leave. It indicates that the control flow can follow only one of the
outgoing paths, and the outgoing edges may have guard conditions to specify conditions or choices.

6. Merge Node: A merge node is also represented by a diamond shape but with two or more flows
entering and a single flow leaving. It represents the point where at least one control flow should
reach before further processing can continue.

7. Fork: A fork is a point where parallel activities begin. It is depicted with a black bar and typically
has a single flow entering and multiple flows leaving. This shows that multiple activities can occur
simultaneously.

8. Join: A join is also represented by a black bar, but it has multiple input flows and a single output
flow. It represents the synchronization of concurrent activities. All incoming controls must be
completed before any further progress can be made.

9. Note: UML allows attaching notes to different components of a diagram to provide textual
information or comments. For example, you can attach notes to decision points to explain the
branching criteria.

10. Partition: Partitions or swimlanes help logically group components within an activity diagram.
They are represented by vertical or horizontal parallel lines, and they can correspond to different
units of an organization or different actors. Partitions are not mandatory and are used for
organizational clarity.

These components allow you to create detailed and clear activity diagrams to represent complex
processes and control flows within a system. They are valuable for software design and business
process modeling, helping stakeholders understand the flow of activities and decision points.

Example
Order Processing Activity Diagram

In this example:

1. Initial Node: The initial node (dark filled circle) represents the starting point of the process. It
signifies the beginning of the order processing workflow.

2. Activity 1 : This is the first activity (rounded rectangle). It denotes the action of receiving a
customer's order, which is a crucial step in the process.

3. Decision Node : While not shown in this simplified example, a decision node could be used if there
are multiple criteria for processing orders. For instance, it might check if the order is for a product in
stock or for a back-ordered item.

4. Activity 2 (Prepare Items): After the order is received and potentially validated, the next activity is
preparing the items for shipment. This action is represented by a rounded rectangle.

5. Activity 3 (Ship Order): Once the items are prepared, the order is ready to be shipped to the
customer. Shipping the order is another critical step in the process.
6. Final Node: The final node (outer hollow circle with inner filled circle) represents the endpoint of
the process. It indicates the successful completion of the order processing workflow, specifically
when the order has been shipped.

In this example, the activity diagram outlines the typical flow of order processing, starting from order
receipt and ending with the successful shipment of the order. While this is a simplified example,
more complex scenarios can involve additional decision points and conditions to manage various
aspects of the order processing workflow.

Case Studies
Travel Booking System Activity Diagram

In this example:

[Link] Node: The process begins with the "Initial Node," representing the starting point for booking
travel.

2. Activity 1 (Select Destination): The traveler selects their desired destination for the trip. This may
involve browsing available options and choosing one.

3. Activity 2 (Choose Dates): The traveler specifies the travel dates, including the departure and
return dates, for the trip.

4. Decision Node (Diamond): A decision point checks if the chosen dates are available. If the dates
are available, the process proceeds to the next step; otherwise, it follows a path for selecting
alternative dates.

5. Activity 3 (Select Accommodation): The traveler selects the type of accommodation they prefer,
such as a hotel, apartment, or vacation rental.

6. Activity 4 (Select Transportation): The traveler chooses their preferred mode of transportation,
such as flights, trains, or car rentals.

[Link] Node (Diamond): Another decision point checks if the selected transportation options are
available for the chosen dates. If available, the process continues to the next step; otherwise, it
follows a path for selecting alternative transportation.

8. Activity 5 (Confirm Booking): The traveler confirms the travel choices, and the system proceeds to
book the trip. This may involve making payments and issuing tickets.

9. Final Node: The final node represents the endpoint of the travel booking process.
This activity diagram illustrates the workflow for a travel booking system, showing how travelers
select destinations, dates, accommodations, and transportation. Decision points are used to handle
availability checks for dates and transportation options, ensuring that the traveler can make
informed choices. The diagram helps in understanding the process of booking a trip in a travel
booking system.
Modeling UML Class Diagrams and
Sequence diagrams
In this experiment, we will delve into the fundamental concepts of object-oriented system design,
focusing on the representation of class diagrams and sequence diagrams. These diagrams are
essential for understanding the structure and interactions between classes and objects within a
system. Here's a brief overview of what you can expect to learn:

1. Class Diagrams: Class diagrams are used to depict the structure of a system by illustrating the
classes and their relationships. You will learn how to create and interpret class diagrams, including
different types of relationships between classes, such as associations, inheritances, and
dependencies.

2. Sequence Diagrams: Sequence diagrams are a dynamic representation of how objects interact
with one another through message passing, showing the time ordering of these interactions. You will
explore the creation of sequence diagrams and gain an understanding of the various types of
messages exchanged between objects in a system.

Objectives
• Graphically represent a class, and associations among different classes
• Identify the logical sequence of activities undergoing in a system, and represent them
pictorially

Structural and Behavioural aspects

In the context of developing software systems using the object-oriented approach, two key aspects
play a crucial role in understanding and solving problems: structural and behavioral aspects.

[Link] Aspects:

- Structural aspects focus on the static components of a system, emphasizing the "what" of a
system's design.

- These components include classes, objects, relationships between classes, attributes, and
methods.

- Class diagrams and object diagrams are commonly used to represent the structural aspects of a
system.

- They provide a clear picture of the system's architecture, including how classes are related, their
properties, and the organization of data and functionalities.

2. Behavioral Aspects:

- Behavioral aspects, on the other hand, deal with the dynamic aspects of a system, emphasizing
the "how" of a system's operation.

- These aspects focus on the interactions between objects, the sequence of events, and the flow of
control within the system.
 - Sequence diagrams, statechart diagrams, and activity diagrams are commonly used to represent
the behavioral aspects of a system.

- They help in visualizing how objects collaborate, communicate, and respond to events and stimuli,
providing insights into the system's behavior.+

To effectively design a software solution, it is essential to consider both the structural and behavioral
aspects. Understanding the static structure of a system (structural aspects) and how it dynamically
behaves (behavioral aspects) enables developers to create well-organized, efficient, and reliable
software systems. These two aspects complement each other and are fundamental in object-
oriented system design.

Class diagram
It is a graphical representation for describing a system in context of its static construction

Elements in class diagram

In a class diagram, several elements are used to represent the structure and relationships within a
system. Here's a brief explanation of some of the key elements:

1. Class:

- A class represents a blueprint for creating objects. It defines the data members (attributes) and
member functions (operations) that objects of the class will have.

- The class is depicted as a solid outline rectangle with three compartments:

- The top compartment contains the class name, a textual string that uniquely identifies the class
in the system.

- The middle compartment lists the attributes or data members shared by all instances of the
class.

- The bottom compartment lists the operations or member functions that can be performed on
objects of the class.

2. Generalization/Specialization:

- Generalization represents how one class is derived from another class, indicating that the derived
class inherits the properties of its parent class.

- Specialization describes specific classes inheriting properties from a more general class.

- In a class diagram, these relationships are represented by connecting lines with arrows from the
specialized (child) class to the general (parent) class.

For example, in the context of an Educational Organization system, a class "Course" might have
attributes like "courseName" and "courseID," and operations like "addCourse()" and
"removeCourse()." Additionally, you might have a generalization relationship between classes like
"Geometric_Shapes" and specialized classes like "Triangle," "Quadrilateral," and "Pentagon."

These elements in a class diagram help model the structure and relationships within a system,
providing a clear representation of the classes, their attributes, and operations, as well as how they
relate to each other through generalization and specialization.
Relationships
In a class diagram, relationships between classes describe the legitimate connections or interactions
between the classes in a system. Here are some of the common types of relationships and their
characteristics:

1. Association:

- Association is an instance-level relationship that allows objects of classes at both ends of the
association to exchange messages.

- It is represented by a simple straight line connecting two class boxes.

- Association can be named, and role names and multiplicities can be indicated at both ends.

- It may be unidirectional.

For example, in the structure model of an organization system, an "Employee" (instance of the
'Employee' class) is always assigned to a particular "Department" (instance of the 'Department'
class), and this association is shown by a line connecting the respective classes.

2. Aggregation:

- Aggregation is a special form of association that describes a part-whole relationship between a

pair of classes.

- It signifies that one class holds some instances of another related class.

- In UML, it is typically shown using a diamond-shaped line connecting the related classes.

For instance, in a supermarket system, each branch runs some of the departments they have, so
the relationship between the "Branch" and "Department" classes can be designed as an aggregation.

3. Composition:

- Composition is a stronger form of aggregation that indicates that the whole class completely owns
its part.

- The life cycle of the part depends on the whole.

- It is also represented using a diamond-shaped line.

Consider a shopping mall with several branches in different locations in a city. The existence of
branches entirely depends on the shopping mall, and this relationship can be described as
composition.

4. Multiplicity:

- Multiplicity describes the number of instances of one class related to the number of instances of
another class in an association.

- Notation for different types of multiplicities includes:

- "1" for one instance

- "0..*" for zero or more instances

- "1..*" for one or more instances

 For example, one vehicle may have two or more wheels, which can be represented using
multiplicity.

These relationships help in defining how classes are connected and how they interact within a
system, contributing to a comprehensive understanding of the system's structure and behavior.

Sequence diagram
It represents the behavioral aspects of a system. Sequence diagram shows the interactions between
the objects by means of passing messages from one object to another with respect to time in a
system.

In a sequence diagram, various elements are used to represent the interactions and messages passed
between objects in a system. Here's a brief explanation of these key elements:

Elements in sequence diagram

1. Object:

- Objects are depicted at the top portion of the sequence diagram and represent instances of
classes or components in the system.

- An object is shown in a rectangular box, and its name precedes a colon (":") followed by the class
name from which the object is instantiated.

- The whole string is underlined and enclosed in a rectangular box.

- Objects that are created during the execution of a use case and are involved in message passing
are displayed at the point of their creation.

2. Life-Line Bar:

- A downward vertical line extending from the object's box is called the life-line of the object.

- A rectangular bar on the life-line indicates that the object is active at that point in time.

- The life-line visually represents the object's existence and activity during the sequence.

3. Messages:

- Messages are used to represent interactions between objects in a sequence diagram. They show
the flow of control and data between objects.

- Messages are represented as arrows, starting from the life-line of the sender object and ending at
the life-line of the receiver object. They are labeled with the message name.

- The chronological order of messages passing along the life-lines illustrates the sequence in which
they occur.

There are different types of messages, including:

- Synchronous Messages: The receiver starts processing the message after receiving it, and the
sender needs to wait until it's made. They are represented by a straight arrow with a closed and filled
arrowhead from the sender's life-line to the receiver's end.
 - Asynchronous Messages: For asynchronous messages, the sender does not need to wait for the
receiver to process the message. They are represented by a straight arrow with an open arrowhead.

- Return Messages: Used for returning a value to the object that initiated the message. They are
optional and are shown as dashed arrows with open arrowheads.

- Response Messages: Represent interactions within the same object. They are used to show the
object sending a message to itself.

These elements in a sequence diagram help in visualizing the interactions and messages passed
between objects during the execution of a specific use case or scenario. They provide a clear
representation of the sequence of events and the order in which messages are exchanged.

Case Study
Online Shopping System - Class Diagram:

In an online shopping system, you would have various classes that represent different entities and
functionalities. Here's a simplified class diagram for such a system:

1. User:

- Attributes: UserID, Name, Email, Address

- Operations: Register(), Login(), BrowseProducts(), AddToCart(), Checkout()

2. Product:

- Attributes: ProductID, Name, Price, Description

- Operations: ViewDetails()

3. Cart:

- Attributes: CartID, Items

- Operations: AddToCart(), RemoveFromCart(), CalculateTotal()

4. Order:

- Attributes: OrderID, User, Items, TotalAmount

- Operations: PlaceOrder(), ConfirmPayment()

5. Payment:

- Attributes: PaymentID, Order, Amount, Status

- Operations: MakePayment()

6. ProductCatalog:

- Attributes: Products

- Operations: SearchProduct(), ViewProductDetails()

Online Shopping System - Sequence Diagram:

Let's consider a scenario where a user places an order in the online shopping system. Here's a
sequence diagram for the "Place Order" use case:

- The user initiates the "Place Order" action by clicking the "Place Order" button on the website.

- The "User" object sends a "PlaceOrder()" message to the "Order" object, indicating the items they
want to purchase.

- The "Order" object creates an order with the selected items and calculates the total amount by
invoking the "CalculateTotal()" operation on the "Cart" object.

- Once the order is ready, the "Order" object sends a "PlaceOrder()" message to the "Payment"
object to initiate the payment process.

- The "Payment" object processes the payment, deducts the amount from the user's payment
method, and updates the payment status.

- A confirmation message is sent back to the "User" to notify them that the order has been
successfully placed.
This sequence diagram represents the interactions between different objects in the system during
the "Place Order" use case.

This example demonstrates the class diagram and a sequence diagram for a common online
shopping system, showing how users interact with the system to place orders and make payments.
Modeling Data Flow Diagrams
Introduction
In this experiment, we will explore Information Systems (IS) and the importance of identifying
stakeholders and data exchange in the design process. We will also delve into the concept of Data
Flow Diagrams (DFD) and how they are used to visually represent the flow of data within ISs, with a
focus on data sources and destinations.

Objectives
• Identify external entities and functionalities of any system
• Identify the flow of data across the system
• Represent the flow with Data Flow Diagrams

Data Flow Diagram

A Data Flow Diagram (DFD) serves as a powerful tool for understanding and designing a system. It
offers a graphical representation that helps bridge the understanding gap between users and system
analysts, as well as between analysts and system designers. DFD begins by providing an overview of
the system and then delves into a detailed design hierarchy. It illustrates the external entities that
supply data to the system and shows how data flows within the system. Additionally, DFD depicts
how data is transformed by processes and how data stores are utilized for reading or writing data.
This comprehensive visualization aids in the effective analysis and design of complex systems.

Graphical notations for Data Flow Diagram

Term Notation Remarks

External
Name of the external entity is written inside the rectangle
entity

Process Name of the process is written inside the circle

A left-right open rectangle is denoted as data store; name of

Data store
the data store is written inside the shape

Data flow Data flow is represented by a directed arc with its data name
Explanation of Symbols used in DFD
In a Data Flow Diagram (DFD), several symbols are used to represent various components and their
interactions:

1. Process:Processes are depicted as circles, and each circle contains the name of the process. The
name should reflect the functionality of the process. If a process's functionality becomes too detailed
or complex, it can be further broken down into sub-processes in the next level of the DFD. It's
recommended to limit the number of processes to around 7, and if there are more than 7, some
processes can be combined and then decomposed further in the next level.

2. *External Entity:External entities are typically shown in the context diagram, which is the highest-
level DFD. They are represented by rectangles, and the name of the external entity is written within
the shape. These external entities send data to the system for processing and receive processed data
in return.

3. Data Store: Data stores are visualized as left-right open rectangles with the name of the data store
written between two horizontal lines within the open rectangle. Data stores serve as repositories
from which data can be accessed or into which data can be stored. They act as data repositories and
are essential for maintaining data within the system.

4. Data Flow: Data flows are depicted as arrows with a direction indicating the flow of data. They
connect various components in the DFD, including external entities, processes, and data stores. Data
flows illustrate the movement of data from one part of the system to another, whether it's from an
external entity to a process, between two processes, or to/from a data store.

These symbols and their connections help to represent the flow of data within a system, making it
easier to understand the interactions and dependencies between different parts of the system.

Context diagram and leveling DFD

A Data Flow Diagram (DFD) is a hierarchical representation of a system's functionalities and data
flows. Here are some key points to understand about DFDs:

1. Context Diagram: The context diagram, often the highest-level DFD (Level 0), provides an overview
of the entire system. In this diagram, the entire system is depicted as a single process, and external
entities are shown interacting with the system. It offers a bird's-eye view of how the system interacts
with its environment.

2. Splitting Processes: As you move from one DFD level to the next, the single process in the higher-
level DFD is split into multiple processes in the lower-level DFD to represent detailed functionalities.
These processes are numbered to maintain a hierarchical structure. For example, if process 'p' in the
context diagram is split into three processes in the next level, they are labeled as 'p1,' 'p2,' and 'p3.' If
'p3' is further split in the subsequent level, it would be labeled as 'p3.1,' 'p3.2,' and so on.

3. Balancing DFD: Balancing a DFD means ensuring that the data flowing into a process equals the
data flowing out of that process when it's split into the next level. This balancing is essential to
maintain the integrity of data flows in the system and ensure that data is not lost or duplicated
during the process.
4. Number of Processes: It's recommended to keep the number of processes at each DFD level to a
manageable size, typically less than seven. If there are too many processes at a given level, consider
combining related processes and then decomposing them into sub-processes in the next level.

5. Data Flow Rules: Data cannot flow directly between two external entities or between two data
stores. It's also important to note that data cannot flow directly from an external entity to a data
store or vice versa. Data typically flows from external entities to processes, between processes, and
between processes and data stores.

These rules and guidelines help create a clear and well-structured representation of a system's
functionalities and data flows, making it easier to analyze, understand, and design complex
information systems.

Case Study
Online Shopping System:

System Description: The Online Shopping System is a web-based application that allows customers to
browse, select, purchase, and manage products from an online store. It includes features like product
catalog, shopping cart, user accounts, payment processing, and order management.

DFD Components:

1. External Entities:

- Customers: Customers access the online store to browse products, add items to the shopping cart,
make purchases, and manage their accounts.

- Admins: Administrators manage the product catalog, customer accounts, and order processing.

- Payment Gateway: This external entity handles payment processing when customers make
purchases.

- Inventory Database: Represents the database containing product information, availability, and
pricing.

- Order Database: Contains order details and transaction records.

2. Processes:

- Browse Products: Customers can browse the product catalog, view product details, and select
items to add to the shopping cart.

- Add to Cart: Customers can add selected items to their shopping cart for later purchase.

- Update Cart: Customers can modify the contents of the shopping cart by adding or removing
items.

- Checkout: When ready, customers proceed to checkout, providing shipping and payment
information.

- Process Payment: Payment information is sent to the payment gateway for transaction
authorization.

- Confirm Order: The system verifies payment authorization and creates an order record.
 - Update Inventory: After an order is confirmed, the system updates the inventory database to
reflect the purchased items.

- Manage Orders: Admins can manage orders, including order fulfillment, shipping, and
cancellation.

- Manage Products: Admins maintain the product catalog, add new products, update prices, and
descriptions.

3. Data Flows:

- Product Information: Product details flow from the inventory database to customers as they
browse products.

- Shopping Cart Updates: As customers add, update, or remove items in the cart, updates are sent
back to the system.

- Payment Information: Customers provide payment details during the checkout process.

- Payment Authorization: Payment details are sent to the payment gateway for authorization.

- Order Details: After payment authorization, order details, including items and shipping
information, are recorded in the order database.

- Inventory Updates: The system updates the inventory database to reflect product availability after
an order is confirmed.

- Order Management: Admins can view, process, and manage orders using this data flow.

- Catalog Updates: Admins maintain the product catalog by adding or updating product
information.

Levels of DFD:

- Level 0 DFD: The entire system is represented as a single process, illustrating interactions between
external entities (customers, admins, payment gateway) and the system.

- Level 1 DFD: The level-1 DFD decomposes processes further. For example, the "Checkout" process
can be decomposed into sub-processes for payment processing, order creation, and inventory
updates.

- Level 2 DFD: Further decomposition may occur to provide more detailed views of specific
processes, data flows, and data stores.

Data Stores:

- Product Catalog: Stores product information such as names, descriptions, and prices.

- Shopping Cart: Temporarily stores selected items during a customer's shopping session.

- Order History: Maintains records of past customer orders for reference.

- Customer Profiles: Stores customer information and account details.

- Payment Records: Keeps records of payment transactions and authorizations.

- Order Records: Stores order details, including items, shipping information, and order status.
- Inventory Database: Contains product inventory information, such as stock levels and availability.

This example demonstrates how a DFD can visually represent complex interactions in an Online
Shopping System, highlighting data flows between components and external entities. It's a valuable
tool for understanding, designing, and communicating the functionality of such systems.
Estimation of Test Coverage Metrics and
Structural Complexity
In this experiment, we will delve into the concept of a Control Flow Graph (CFG) and its various
components. A CFG is a visual representation of how the control flow or execution flows within a
program. It is a powerful tool for static code analysis and helps developers understand the structure
and complexity of their code.

We'll start by understanding the fundamental building blocks of a CFG, which are basic blocks. Basic
blocks are sequences of code that have a single entry point and a single exit point. We'll learn how to
identify and define basic blocks within a program.

Next, we'll explore how to connect these basic blocks using directed edges to create a complete CFG
for a program. The CFG provides a visual map of the program's execution paths and decision points.

We'll also discuss the concept of paths in the context of a CFG. Paths represent the sequences of
basic blocks that can be traversed during program execution. We'll explore different types of paths
and learn how to identify linearly independent paths within a CFG.

One crucial metric for software complexity that we'll cover is McCabe's cyclomatic complexity. This
metric quantifies the complexity of a program based on the number of linearly independent paths in
the CFG. We'll learn how to calculate McCabe's cyclomatic complexity and understand its significance
in software quality and testing.

Objectives
• Identify basic blocks in a program module, and draw it's control flow graph (CFG)
• Identify the linearly independent paths from a CFG
• Determine Cyclomatic complexity of a module in a program

Control Flow Graph

A Control Flow Graph (CFG) is a graphical representation of a program's control flow. It is a directed
graph where nodes represent different instructions or basic blocks within a program, and edges
define the sequence of execution between these nodes. Here's a breakdown of key concepts related
to CFGs:
1. Basic Block: CFGs can become quite large for real-life applications, so they are often simplified by
grouping sequential statements into basic blocks. A basic block is a maximal sequence of program
instructions such that each instruction is executed immediately before the next one. In the CFG, each
basic block is represented as a single node. The first statement in a basic block is called a leader. This
grouping helps reduce the complexity of the graph.

2. Dominance: In a CFG, one node can dominate another node, denoted as "x dom y," if all possible
execution paths that go through node y must pass through node x. This concept helps in analyzing
the control flow and relationships between different parts of the program. For example, in a loop,
the entry node of the loop block dominates all the nodes within the loop.

3. Entry and Exit Blocks: Every CFG has an entry block and an exit block. The entry block is the
starting point of the control flow, while the exit block marks the end. All paths in the CFG must pass
through the entry block before reaching the exit block.

4. Unreachable Code: If a block or sub-graph in a CFG is not connected to the entry block, it contains
code that is unreachable during program execution. Such unreachable code can be safely removed
from the program, as it will never be executed.

CFGs are valuable tools for understanding and analyzing the structure of a program, identifying
potential execution paths, and detecting unreachable code. They are particularly useful for program
optimization, debugging, and testing, as they provide insights into the program's control flow.

Terminologies
Terminologies related to Control Flow Graphs (CFGs):

Path: A path in a Control Flow Graph (CFG) is a sequence of nodes and edges that begins at the initial
node (or entry block) and concludes at a terminal node. The CFG of a program can have multiple
terminal nodes, as different paths may end at different locations within the program.

Linearly Independent Path: A linearly independent path is a path within the CFG that includes at least
one new edge not present in any other linearly independent path. These paths offer a
comprehensive representation of all possible execution paths within a program. When performing
path-coverage testing, considering only the linearly independent paths is usually sufficient.

For example, in a given CFG, there may be multiple paths, but not all of them are linearly
independent. Four linearly independent paths in a CFG are listed as examples, and they include at
least one unique edge not found in any other linearly independent path. Paths that repeat edges
from previous paths are not considered linearly independent.

Understanding and identifying linearly independent paths in a program's CFG is valuable for testing,
as it helps ensure thorough coverage of potential execution scenarios and the identification of
unique code paths that may require specific attention during testing and debugging.

McCabe's Cyclomatic Complexity

McCabe had applied graph-theoretic analysis to determine the complexity of a program module [vi].
Cyclomatic complexity metric, as proposed by McCabe, provides an upper bound for the number of
linearly independent paths that could exist through a given program module. Complexity of a module
increases as the number of such paths in the module increase. Thus, if Cyclomatic complexity of any
program module is 7, there could be up to seven linearly independent paths in the module. For a
complete testing, each of those possible paths should be tested.

McCabe's Cyclomatic Complexity is a software metric used to measure the complexity of a program
or module by analyzing its control flow. It quantifies the number of linearly independent paths
through a program module, which can serve as an upper bound for the number of test cases
required to test that module effectively. The concept was introduced by Thomas J. McCabe.

Here are some key points related to McCabe's Cyclomatic Complexity:

1. Calculation Methods: There are three methods to calculate the Cyclomatic complexity:

- Method #1: V(G) = E - N + 2, where E is the number of edges and N is the number of nodes in the
control flow graph.

- Method #2: V(G) can be calculated visually by counting the total number of bounded areas
(regions) in the control flow graph and then adding 1.

- Method #3: If LN is the total number of loops and decision statements in a program, then V(G) =
LN + 1. For object-oriented programming, this formula is applied to methods of a class.

2. Optimum Values: It is recommended that the Cyclomatic complexity of any module should not
exceed 10. Modules with complexity greater than 10 may be challenging to understand for humans
and should be considered for redesign.

3. Merits:

- Independent of programming language.

- Helps in risk analysis during development or maintenance phases.

- Provides an estimate of the maximum number of test cases required, thus aiding in testing efforts.

4. Demerits: Cyclomatic complexity does not provide insights into the cohesion and coupling of
modules, which are important aspects of software design and maintainability.

5. Application in Object-Oriented Programming: While McCabe's Cyclomatic Complexity was initially

proposed for procedural languages, it can be adapted for object-oriented languages. Alternatively,
metrics like Chidamber-Kemerer metrics are specifically designed for object-oriented programming.

In summary, McCabe's Cyclomatic Complexity is a useful metric for assessing the complexity of
software modules, which can aid in understanding, testing, and managing the development and
maintenance of software systems. It provides valuable insights into the potential challenges in
understanding and maintaining the code, making it a valuable tool in software engineering.

Case Study
Certainly, here's another example to illustrate how to calculate Cyclomatic complexity for a different
code snippet:
Example: Cyclomatic Complexity for a Conditional Statement

Let's analyze a simple code segment with a conditional statement:

def process_data(data):

result = 0

if data > 10:

result = data * 2

else:

result = data * 3

return result

We will calculate the Cyclomatic complexity for this code snippet.

1. Control Flow Graph (CFG):

- Create a CFG for the code segment with nodes representing statements and edges indicating
control flow.

2. Nodes and Edges:

- Count the number of nodes and edges in the CFG.

- Nodes (N) = 6

- Edges (E) = 7

3. Cyclomatic Complexity Formulas:

- We will apply the three common formulas:

- Using the first formula, V(G) = E - N + 2 = 7 - 6 + 2 = 3.

- Using the second formula (number of regions), there are two regions (one inside the `if` condition
and one inside the `else` condition), so V(G) = 2 + 1 = 3.

- Using the third formula (number of decision points), there are two decision points (the `if` and
`else` conditions), so V(G) = 2 + 1 = 3.

4. Result:

- The Cyclomatic complexity of this code snippet is 3, regardless of which formula is used.

- A Cyclomatic complexity of 3 indicates that there are three linearly independent paths through
the code segment, and you would need at least three different test cases to achieve path coverage
during testing.

This example demonstrates how to calculate Cyclomatic complexity for a code segment with a
conditional statement. It helps in evaluating the complexity of the code and determining the
minimum number of test cases required for path coverage.

Case study
Certainly, here's an example similar to the one you provided, including all the key points related to
Cyclomatic complexity and the control flow graph.

Case Study: An Online Shopping Cart System

Imagine we are developing an Online Shopping Cart System. This system allows users to add and
remove items from their shopping cart and proceed with the checkout process. Let's calculate the
Cyclomatic complexity for the "Checkout" method in this system.

public class ShoppingCart {

public void Checkout(Cart cart, User user) {

if ([Link]) {

if ([Link]) {

DisplayMessage("Your cart is empty. Add items to continue.");

} else {

if ([Link]) {

if ([Link]()) {

ProcessPayment(user, cart);

DisplayMessage("Payment successful. Your order is confirmed.");

} else {

DisplayMessage("Some items in your cart are out of stock. Remove them to continue.");

} else {

DisplayMessage("Please add a payment method before checking out.");

} else {

DisplayMessage("Please log in to proceed with the checkout.");

Control Flow Graph (CFG) for the "Checkout" method:

Here is the Control Flow Graph for the "Checkout" method:

1. Start

2. if ([Link])
 3. True

4. if ([Link])

5. True

6. DisplayMessage

7. False

8. if ([Link])

9. True

10. if ([Link]())

11. True

12. ProcessPayment

13. DisplayMessage

14. False

15. False

16. DisplayMessage

17. False

18. DisplayMessage

19. False

20. DisplayMessage

21. End

The CFG has 12 nodes and 15 edges. So, the Cyclomatic complexity is V(G) = 15 - 12 + 2 = 5.

This case study illustrates how to apply Cyclomatic complexity analysis to a real-world scenario in
software development. It helps in identifying the complexity of the "Checkout" method and
designing test cases to ensure thorough testing of the system.
 Designing Test Suites
In software development, testing is a critical phase to ensure that the software functions correctly
and meets its intended requirements. Testing involves evaluating the software's behavior,
performance, and reliability. There are various types of testing used throughout the software
development lifecycle, each serving a specific purpose. In this experiment, we will provide an
overview of different testing types and focus on unit testing.

Different Types of Testing:

1. Unit Testing: This type of testing focuses on individual components or units of code. Unit tests
verify that each unit behaves as expected in isolation. Developers often write unit tests to validate
the correctness of functions or methods.

2. Integration Testing: Integration testing examines the interactions between different units or
modules. It ensures that these components work correctly when combined. Integration tests can be
used to uncover issues arising from the connections between various software modules.

3. System Testing: System testing evaluates the complete software system as a whole. It verifies that
the entire application, including its user interfaces and databases, functions as intended. This type of
testing often uncovers high-level issues such as compatibility problems or incorrect system behavior.

4. Acceptance Testing: Acceptance testing determines whether the software meets the customer's
requirements and is ready for deployment. It can be performed by both the development team (to
ensure individual features work) and the end-users (to validate the system's overall usability).

5. Regression Testing: Regression testing ensures that new code changes or enhancements do not
negatively impact existing functionality. It involves re-running tests that previously passed to identify
any regressions.

6. Performance Testing: Performance testing assesses the software's behavior under various
conditions, such as high user loads or extreme data volumes. Types of performance testing include
load testing, stress testing, and scalability testing.

7. Security Testing: Security testing identifies vulnerabilities in the software that could lead to
security breaches. It includes penetration testing, code reviews, and assessing the system's
resistance to hacking attempts.

8. Usability Testing: Usability testing evaluates the software's user-friendliness and user experience.
It aims to ensure that the system is intuitive and easy to use for its target audience.

Unit Testing:

Unit testing is a fundamental testing approach that focuses on verifying the correctness of individual
units of code, such as functions or methods. It has several advantages, including:

- Early detection of issues during development.

- Simplification of debugging and troubleshooting.

- Easy identification and isolation of defects in smaller code units.

- Promotion of code maintainability and modularity.

To conduct unit testing, developers write test cases that exercise different aspects of a unit's
behavior, including normal and exceptional scenarios. These tests are typically automated and can be
executed frequently as the code evolves.

Objectives

After completing this experiment you will be able to:

Learn about different techniques of testing a software

Design unit test cases to verify the functionality and locate bugs, if any

Software Testing

Software testing plays a crucial role in the software development life cycle, helping to ensure the
quality, reliability, and correctness of software applications. Here is a brief overview of the key
concepts related to software testing:

1. Definition of Testing: According to the ANSI/IEEE 1059 standard, testing is the process of analyzing
a software item to detect differences between the existing (actual) conditions and the required
conditions. These differences manifest as defects, errors, or bugs, which need to be identified and
addressed. The testing process also involves evaluating the features and functionality of the software
item.

2. Purpose of Testing:

- Verification: Verification is the process of checking whether the software conforms to its specified
requirements. It focuses on ensuring that the software behaves consistently with its design and
requirements. In essence, verification asks, "Are we building the product right?"

- Validation: Validation is the process of confirming that the software meets the user's actual needs
and expectations. It checks if the software delivers the intended functionality and serves its purpose
effectively. Validation seeks to answer, "Are we building the right product?"

3. Defect: A defect is a variance between the expected (desired) result and the actual result when
testing a software application. Defects can be found at any stage of the software development
process, from initial specification through design and coding. They may be introduced due to faults in
the software's specification, design, or coding phases.

Standards for Software Test Documentation

Various standards have been established to provide guidelines and specifications for software test
documentation and related processes. Here are some of the key standards in the field of software
testing and documentation:

1. IEEE 829-1998: This standard, known as the IEEE Standard for Software Test Documentation,
specifies the format and content of a set of documents used in software testing. It outlines the
structure of documents such as test plans, test cases, and test reports.

2. IEEE 1008: This standard focuses on unit testing. It provides guidelines and recommendations for
conducting unit testing, which is the testing of individual components or units of a software system
in isolation.
3. IEEE 1012: The IEEE Standard for Software Verification and Validation (V&V) outlines the processes
for verification and validation of software. It covers a broad range of activities to ensure that
software meets its specified requirements and is free of defects.

4. IEEE 1028: This standard pertains to software inspections, which are a systematic way of
evaluating and reviewing software documents. It provides guidance on how to conduct effective
inspections to identify defects and issues.

5. IEEE 1044 and 1044-1: These standards deal with the classification of software anomalies and
provide guidelines for categorizing and reporting defects and issues identified during the testing
process.

6. IEEE 830: This standard serves as a guide for developing system requirements specifications. While
it primarily focuses on requirements, having well-defined and clear requirements is crucial for
effective testing.

7. IEEE 730: The IEEE Standard for Software Quality Assurance Plans establishes the requirements for
creating a software quality assurance plan. It helps ensure that software quality is maintained
throughout the development and testing processes.

8. IEEE 1061: This standard addresses software quality metrics and methodology. It provides
guidelines for measuring various aspects of software quality and outlines methodologies for quality
assessment.

9. IEEE 12207* The IEEE Standard for Software Life Cycle Processes and Life Cycle Data defines
processes and activities related to the entire software development life cycle. It includes aspects of
testing and quality assurance.

10. BS 7925-1 and BS 7925-2: These British standards are focused on software testing. BS 7925-1
provides a vocabulary of terms used in software testing, helping standardize terminology, while BS
7925-2 is a standard for software component testing.

Testing Frameworks
Following are the different testing frameworks:

jUnit - for Java unit test

Selenium - is a suite of tools for automating web applications for software testing purposes, plugin
for Firefox

HP QC - is the HP Web-based test management tool. It familiarizes with the process of defining
releases, specifying requirements, planning tests, executing tests, tracking defects, alerting on
changes, and analyzing results. It also shows how to customize project

IBM Rational - Rational software has a solution to support business sector for designing,
implementing and testing software

Need for Software Testing

Software testing is a critical phase of the software development life cycle, and it serves several
important purposes and objectives:
1. **Identification of Software Faults:** Software testing is primarily aimed at identifying faults,
defects, and bugs in the software. These faults can be coding errors, logic flaws, or other issues that
may lead to incorrect behavior or system failures. By detecting these issues early in the development
process, software quality can be significantly improved.

2. **Enhancing Reliability:** The removal of software faults through testing contributes to the
reduction of system failures. This, in turn, improves the reliability of the software system. Reliable
software is crucial in various domains, from safety-critical systems in aerospace and healthcare to
everyday applications.

3. **Improving Other System Qualities:** Software testing not only focuses on identifying defects
but also plays a role in enhancing other important system qualities. These qualities include
maintainability (ease of maintenance and updates), usability (user-friendliness), and testability (ease
of testing). Ensuring these qualities leads to a more robust and user-friendly software product.

4. **Meeting Legal and Compliance Requirements:** In many industries and regions, there are legal
and compliance requirements that mandate thorough testing of software products. Meeting these
requirements is essential to avoid legal issues, liabilities, and penalties. For example, healthcare
software must adhere to regulations like HIPAA, and financial software must meet regulations like
SOX (Sarbanes-Oxley Act).

5. **Y2K and Millennium Bug Compliance:** The Y2K or Millennium Bug was a significant concern
leading up to the year 2000. It required software systems to be tested and verified to ensure that
date-related calculations and processing would function correctly as the year rolled over from 1999
to 2000. Software testing was crucial to prevent potential disruptions and issues caused by date-
related problems.

6. **Industry-Specific Standards:** Various industries have their own specific standards and
guidelines for software development and testing. For example, the aerospace industry has strict
standards, such as RTCA DO-178C, for software used in safety-critical aviation systems. The railway
signaling industry has standards like CENELEC EN 50128 for railway applications. Complying with
these standards is essential to ensure the safety and reliability of software in these sectors.

7. **Risk Mitigation:** Software testing is a key part of risk mitigation in software development. It
helps identify and address potential risks and vulnerabilities early in the development process,
reducing the likelihood of costly failures, security breaches, and system downtimes in the future.

Test Cases and Test Suite

A test case describes an input descriptions and an expected output
descriptions. Input are of two types: preconditions (circumstances that hold prior
to test case execution) and the actual inputs that are identified by some testing
methods. The set of test cases is called a test suite. We may have a test suite
of all possible test cases.

Types of Software Testing

Software testing is a crucial phase in the software development life cycle, and there are various types
of software testing to ensure the quality and reliability of software products. Here are some of the
key types of software testing:

1. **Unit Testing:**

- **Objective:** To test the smallest, individual components or units of software.

- **Methods:**

- **Black Box Testing:** Testing based on input and output values.

- **Equivalence Class Partitioning:** Grouping input values into equivalence classes.

- **Boundary Value Analysis:** Testing values at the boundaries of equivalence classes.

- **White Box Testing:** Testing based on examining the code's internal structure.

- **Purpose:** Verify that each unit of code (e.g., functions, methods) behaves correctly.

2. **Integration Testing:**

- **Objective:** To test the interaction and integration of multiple units or components.

- **Approaches:**

- **Top-Down Approach:** Test from the top-level routine and integrate subordinate routines.

- **Bottom-Up Approach:** Test individual subsystems and progressively integrate them.

- **Purpose:** Ensure that different modules work together correctly when combined.

3. **System Testing:**

- **Objective:** To validate the entire system's functionality based on requirements and

specifications.

- **Types:**

- **Alpha Testing:** Performed by developers or client representatives to identify defects.

 - **Beta Testing:** Conducted by a limited number of end users to provide feedback.

- **User Acceptance Testing (UAT):** Ensures system compliance with client requirements.

- **Purpose:** Assess overall system quality, including functional and non-functional attributes.

4. **Regression Testing:**

- **Objective:** To verify that code modifications or bug fixes do not introduce new defects.

- **Purpose:** Ensure that existing functionality remains intact as new changes are made.

- **Process:** Re-testing the software using selected test cases from the original test suite.

The provided example illustrates the concept of unit testing and includes test cases for a simple
program to calculate the square of a number in the range of 1 to 100. It demonstrates how different
input values produce various output results, and test cases are designed to validate the program's
behavior.

Each type of testing serves a specific purpose in the software development process and contributes
to the overall quality and reliability of the software product. By systematically applying these testing
methods, software developers can identify and rectify issues at various stages of development,
resulting in a more robust and dependable software application.

Case study
Certainly! Here's another example for designing test cases for a "Search Functionality" in a web
application. The goal is to test different search scenarios:

**Table 1: A simplified mapping from requirements to test cases**

Requirement # Test Case #

R1 TC1

R2 TC2, TC3

R3 TC4, TC5

**Table 2: A test suite to verify the "Search Functionality" feature**

# TS3

Title Verify "Search Functionality" functionality

Description To test different scenarios during the search process

# Summary Dependency Pre-condition Post-condition Execution Steps Expected
Output

TC1 Verify that a user can successfully search for a product using a valid keyword
Logged-in user with a valid keyword User is presented with search results

Enter a valid search keyword in the search bar

Click the "Search" button

Search results page is displayed with relevant products

TC2 Verify that a user cannot initiate a search without entering a search keyword
Logged-in user with no keyword User remains on the search page

Leave the search bar empty

Click the "Search" button

User receives a validation message: "Please enter a keyword."

TC3 Verify that a user is informed when no search results are found for the entered keyword
Logged-in user with a keyword that yields no results User is shown a message

Enter a unique and non-existent keyword in the search bar

Click the "Search" button

A message appears: "No results found for the keyword."

TC4 Verify that a user can use advanced search filters to narrow down search results
Logged-in user with specific search filters User is presented with refined search results

Enter a valid keyword in the search bar

Apply advanced search filters (e.g., category, price range)

Click the "Search" button

Search results page displays products that match the filters

TC5 Verify that a user can clear search filters Logged-in user with applied search filters
User is shown the default search results

Enter a valid keyword in the search bar

Apply advanced search filters (e.g., category, price range)

Click the "Clear Filters" button

Search results page displays the default search results

This test suite focuses on the "Search Functionality" and tests various aspects of search, including
valid searches, searches with no results, and the use of search filters. It ensures that users can
efficiently search for products on the website.