Software Engineering (3150711) Enrollment No:2112401070

PRACTICAL 1

Aim: Study the complete Software Development Life Cycle (SDLC)

and analyze various activities conducted as a part of various phases.
For each SDLC phase, identify the objectives and summaries
outcomes.

 What is Software?
 Software is a collection of instructions that enable the user to interact with a
computer, its hardware, or perform tasks. Without software, most computers
would be useless.

 What is Software Engineering?

 Software engineering is defined as a process of analyzing user requirements
and then designing, building, and testing software application which will
satisfy those requirements.
 IEEE, In Its Standard 610.12-1990, Defines “Software Engineering As The
Application Of A Systematic, Disciplined, Which Is A Computable Approach
For The Development, Operation, And Maintenance Of Software.”
 Fritz Bauer Defined It As “The Establishment And Used Standard Engineering
Principles. It Helps You To Obtain, Economically, Software Which Is Reliable
And Works Efficiently On The Real Machines”.
 Boehm Defines Software Engineering, Which Involves, “The Practical
Application of Scientific Knowledge to The Creative Design and Building of
Computer Programs. It Also Includes Associated Documentation Needed for
Developing, Operating, and Maintaining Them.”

 What is systems development life cycle (SDLC)?

A software life cycle model (also termed process model) is a pictorial and
diagrammatic representation of the software life cycle. A life cycle model
represents all the methods required to make a software product transit through its

SPCE(CE),BAKROL Page | 1
 Software Engineering (3150711) Enrollment No:2112401070

life cycle stages. It also captures the structure in which these methods are to be
undertaken.

In other words, a life cycle model maps the various activities performed on a
software product from its inception to retirement. Different life cycle models may
plan the necessary development activities to phases in different ways. Thus, no
element which life cycle model is followed; the essential activities are contained in
all life cycle models though the action may be carried out in distinct orders in
different life cycle models. During any life cycle stage, more than one activity may
also be carried out.

SDLC Cycle represents the process of developing software. SDLC framework

includes the following steps:

Fig: Software Development Life Cycle

 The stages of SDLC are as follows:

Stage 1: Planning and requirement analysis

Requirement Analysis is the most important and necessary stage in SDLC.

SPCE(CE),BAKROL Page | 2
Software Engineering (3150711) Enrollment No:2112401070

The senior members of the team perform it with inputs from all the stakeholders and
domain experts or SMEs in the industry. Planning for the quality assurance
requirements and identifications of the risks associated with the projects is also done
at this stage.

Business analyst and Project organizer set up a meeting with the client to gather all
the data like what the customer wants to build, who will be the end user, what is the
objective of the product. Before creating a product, a core understanding or
knowledge of the product is very necessary. For Example, A client wants to have an
application which concerns money transactions. In this method, the requirement has
to be precise like what kind of operations will be done, how it will be done, in which
currency it will be done, etc.

Stage 2: Defining Requirements

Once the requirement analysis is done, the next stage is to certainly represent and
document the software requirements and get them accepted from the project
stakeholders. This is accomplished through "SRS"- Software Requirement
Specification document which contains all the product requirements to be constructed
and developed during the project life cycle.

Stage 3: Designing the Software

The next phase is about to bring down all the knowledge of requirements, analysis,
and design of the software project. This phase is the product of the last two, like
inputs from the customer and requirement gathering.

Stage 4: Developing the project

In this phase of SDLC, the actual development begins, and the programming is built.
The implementation of design begins concerning writing code. Developers have to
follow the coding guidelines described by their management and programming tools
like compilers, interpreters, debuggers, etc. are used to develop and implement the
code.

Stage 5: Testing

After the code is generated, it is tested against the requirements to make sure that the
products are solving the needs addressed and gathered during the requirements stage.

SPCE(CE),BAKROL Page | 3
 Software Engineering (3150711) Enrollment No:2112401070

During this stage, unit testing, integration testing, system testing, acceptance testing
are done.

Stage 6: Deployment

Once the software is certified, and no bugs or errors are stated, then it is deployed.
Then based on the assessment, the software may be released as it is or with suggested
enhancement in the object segment.

After the software is deployed, then its maintenance begins.

Stage 7: Maintenance

Once when the client starts using the developed systems, then the real issues come up
and requirements to be solved from time to time.

This procedure where the care is taken for the developed product is known as
maintenance.

 SDLC Models:
A software life cycle model is a descriptive representation of the software
development cycle. SDLC models might have a different approach but the basic
phases and activity remain the same for all the models.

 Software Process and Software Development Life cycle Model:

 The Waterfall Model
 Incremental Process Models
 Evolutionary Process Models
 Prototype Model
 The Spiral Model
 Concurrent Models
 RAD model
 Agile model

 The Waterfall Model:

SPCE(CE),BAKROL Page | 4
 Software Engineering (3150711) Enrollment No:2112401070

The waterfall model is the classic model or oldest model and is known as mother of
all the model. It is widely used in government projects and many vital projects in
company. The waterfall model is also called as 'Linear sequential model' or 'Classic
life cycle model’. In this model, each phase is executed completely before the
beginning of the next phase. Hence the phases do not overlap in waterfall model. This
model is used for small projects. In this model, feedback is taken after each phase to
ensure that the project is on the right path. Testing part starts only after the
development is completed.

Fig: waterfall Model

 The V-model:

V model is known as Verification and Validation model. This model is an extension

of the waterfall model. Instead of moving down in a linear way, the process steps are
bent upwards after the coding phase, to form the typical V shape. The V-Model
demonstrates the relationships between each phase of the development life cycle and
its associated phase of testing. In the life cycle of V-shaped model, processes are
executed sequentially. Every phase completes its execution before the execution of
next phase begins.

Fig : V – Model

SPCE(CE),BAKROL Page | 5
 Software Engineering (3150711) Enrollment No:2112401070

 Incremental Model:

The incremental build model is a method of software development where the model is
designed, implemented and tested incrementally (a little more is added each time)
until the product is finished. The incremental model combines the elements of
waterfall model and they are applied in an iterative fashion. The first increment in this
model is generally a core product. Each increment builds the product and submits it to
the customer for suggesting any modifications. The next increment implements the
customer's suggestions and add additional requirements in the previous increment.
This process is repeated until the product is completed.

Fig : Incremental Model

 Prototyping Model:

The prototype model requires that before carrying out the development of actual
software, a working prototype of the system should be built. A prototype is a toy
implementation of the system. A prototype usually turns out to be a very crude
version of the actual system, possible exhibiting limited functional capabilities, low
reliability, and inefficient performance as compared to actual software. In many
instances, the client only has a general view of what is expected from the software
product. In such a scenario where there is an absence of detailed information
regarding the input to the system, the processing needs, and the output requirement,
the prototyping model may be employed.

SPCE(CE),BAKROL Page | 6
 Software Engineering (3150711) Enrollment No:2112401070

Fig: prototype Model

 The Spiral Model:

The spiral model, initially proposed by Boehm, is an evolutionary software process

model that couples the iterative feature of prototyping with the controlled and
systematic aspects of the linear sequential model. It implements the potential for rapid
development of new versions of the software. Using the spiral model, the software is
developed in a series of incremental releases. During the early iterations, the
additional release may be a paper model or prototype. During later iterations, more
and more complete versions of the engineered system are produced.

Fig: Spiral Model

SPCE(CE),BAKROL Page | 7
 Software Engineering (3150711) Enrollment No:2112401070

 AGILE PROCESS MODELS:

The Agile processes are the light-weight methods are people-based rather than plan
based methods. The Agile process forces the development team to focus on software
itself rather than design and documentation. The Agile process believes in iterative
method. The aim of agile process is to deliver the working model of software quickly
to the customer. There are various process models used as agile process model. But
the most famous agile process model is Extreme Programming.

Fig: Agile Process Model

SPCE(CE),BAKROL Page | 8
Software Engineering (3150711) Enrollment No:2112401070

PRACTICAL 2

Aim: SRS for Multiple Disease Prediction System using Machine

Learning

A software requirements specification (SRS) is a detailed

description of a software system to be developed with its functional and
non-functional requirements. The SRS is developed based the agreement
between customer and contractors. It may include the use cases of how
user is going to interact with software system. The software requirement
specification document consistent of all necessary requirements required
for project development. To develop the software system, we should have
clear understanding of Software system. To achieve this, we need to
continuous communication with customers to gather all requirements.

1. Introduction:
Multiple disease prediction systems are designed to provide individuals
with valuable insights into their health status by analysing a diverse range
of information. This typically includes personal health data, medical
history, lifestyle choices, and, in some cases, genetic information. By
leveraging sophisticated data analysis techniques, machine learning
algorithms, and a vast repository of medical knowledge, these systems
aim to deliver accurate predictions regarding the likelihood of specific
diseases or health issues.
Any problem solving in software consist of these steps:-

 Requirement Analysis:

SPCE(CE),BAKROL Page | 9
Software Engineering (3150711) Enrollment No:2112401070

Requirement analysis for a multiple disease prediction system is as

follows:
 The system must be able to identify users (individuals, healthcare
professionals, administrators) and their roles.
 The system must be able to specify what data users need to provide
(e.g., medical history, lifestyle, symptoms).
 The system must be able to specify how users will interact with the
system (e.g., web app, mobile app).
 The system must be able to specify list of the diseases to be predicted
and include basic information (symptoms, risk factors).

 Software Design:
The multiple disease prediction system will be implemented as a three-
tier architecture:

 Presentation Tier: The user interface where users input data and
view predictions.

 Application Tier: The business logic layer responsible for data

processing, prediction generation, and recommendation generation.

 Data Tier: The database where user data, disease information, and
other relevant data are stored.

 Coding:
Coding for a multiple disease prediction system can be done in various
programming languages, including Python, R, Java, and others,
depending on your team's expertise and project requirements.

 Testing:

SPCE(CE),BAKROL Page | 10
Software Engineering (3150711) Enrollment No:2112401070

 Individual components and functions of the system are tested to

ensure they work as expected.
 The interaction between different system components is tested to
verify that they function together seamlessly.
 Testing the system's ability to handle a growing user base and
increasing data volumes without performance degradation.

1.1 Purpose:
 The purpose of a multiple disease prediction system is to improve
healthcare outcomes and individuals' well-being by leveraging data
and technology to achieve the following objectives:
 Early Disease Detection: Detect diseases at an early stage or assess
an individual's risk of developing specific health conditions, allowing
for timely intervention and treatment.
 Health Education: Educate users about diseases, symptoms, risk
factors, and recommended preventive measures, fostering health
literacy.
 Cost Reduction: By focusing on prevention and early intervention,
these systems aim to reduce the long-term healthcare costs associated
with treating advanced-stage diseases.

1.2 Scope:
 The scope of a multiple disease prediction system includes:
 Predicting the risk of a select set of diseases or health conditions, such
as diabetes, heart disease, and hypertension.
 Utilizing user-provided health data, such as medical history, lifestyle
choices, and symptoms, for risk assessment.

SPCE(CE),BAKROL Page | 11
Software Engineering (3150711) Enrollment No:2112401070

 Targeting individual users seeking personalized health insights and

recommendations.
 Feasibility study: A feasibility study of a face recognition system
would typically consider the following factors:
1. Technical Feasibility: Determine if the necessary technology and
expertise are available to develop the system. Evaluate the feasibility of
implementing machine learning algorithms, data storage, and processing
capabilities.
2. Economic Feasibility: Conduct a cost-benefit analysis to assess
whether the benefits of the system outweigh the development and
operational costs.
3. Operational Feasibility: Evaluate whether users, including
individuals and healthcare professionals, are likely to accept and use the
system effectively.
4. Legal and Regulatory Feasibility: Ensure that the system will comply
with healthcare data privacy regulations (e.g., HIPAA in the U.S., GDPR
in Europe) and other relevant laws and regulations.

1.3 Definition, Acronyms, Abbreviation:

 PYTHON - Object Oriented Language
 SRS - Software Requirement Specification
 HIPPA - Health Insurance Portability and Accountability Act
 GDPR - General Data Protection Regulation
 UI - User Interface
 ML - Machine Learning
 API - Application Programming Interface
 UX - User Experience
 FDA - Food and Drug Administration

SPCE(CE),BAKROL Page | 12
Software Engineering (3150711) Enrollment No:2112401070

1.4 Overview:
A multiple disease prediction system is a sophisticated software
application designed to assess an individual's risk of developing various
diseases or health conditions based on their personal health information,
medical history, lifestyle factors, and sometimes genetic data.
Here's an overview of a multiple disease prediction system:
 Users provide information about their health, including medical
history, family history, current symptoms, lifestyle choices (e.g., diet,
exercise), and sometimes genetic data.
 The system employs advanced data processing techniques to clean,
validate, and normalize the user's health data.
 The system relies on a comprehensive database of diseases, which
includes information about symptoms, risk factors, prevalence rates,
and diagnostic criteria.
 The system calculates the user's risk scores or probabilities for
different diseases based on their data and the disease database.
 Users receive predictions about their likelihood of developing specific
diseases in the future.

2. Overall Description:
2.1 Product Perspective:
The proposed Multiple Disease Prediction System will take care of the
users by detecting various diseases conveniently. It will help user to know
whether he/she should consult a doctor or not.

2.2 Product function:

SPCE(CE),BAKROL Page | 13
Software Engineering (3150711) Enrollment No:2112401070

 The main purpose of this project is to reduce the manual work.

 This software is capable of handling various data’s, detecting various
diseases, saving time and money of the users.

2.3 User characteristics:

Here are common user characteristics for a multiple disease prediction
system:
 Existing Health Conditions: Users may have various pre-existing
medical conditions that could impact disease predictions and
recommendations.
 Data Sharing Preferences: Users' choices regarding how their health
data is shared, used, and stored.
 Genetic Factors: Some users may have known genetic markers or
family histories relevant to disease risk.

2.4 General Constraints:

 Compliance with healthcare data privacy regulations (e.g., HIPAA in
the United States, GDPR in Europe) and ensuring the secure handling
of sensitive health data.
 The system must provide accurate disease predictions and
recommendations to ensure user trust and effectiveness in disease
prevention.

2.5 Assumption and dependencies:

Assumption: Assuming that users will actively engage with the system,
input accurate data, and follow recommendations, as user cooperation is
essential for the system's effectiveness.

SPCE(CE),BAKROL Page | 14
Software Engineering (3150711) Enrollment No:2112401070

Dependency: Dependencies on robust data security measures and

protocols to protect user data from breaches and unauthorized access.

3. Specific Requirement:
3.1 External Interface Requirement:
The user should be simple and easy to understand and use. Also be an
interactive interface. The system should prompt for the user and
administrator to login to the website and for proper input criteria

3.1.1 User Interface:

 The user interface (UI) of a multiple disease prediction system is the
visual and interactive component through which users interact with
the system to input health-related data, receive predictions, and access
recommendations.
 Here are the key elements typically found in the UI of a multiple
disease prediction system:
1. User Registration and Login: Users should be able to create
accounts or log in securely to access the system, ensuring data privacy.
2. Disease Selection: An option to select and prioritize specific diseases
or health conditions for prediction and analysis.
3. Security Measures: Integration of security features to protect user
data and maintain the confidentiality of health information.

3.1.2 Hardware interface:

 Operating system: Windows 7 or higher
 Hard disk: 100 GB ROM or higher
 RAM: 4 GB or higher

SPCE(CE),BAKROL Page | 15
Software Engineering (3150711) Enrollment No:2112401070

 Processor: i3 processor system or higher

3.1.3 Software interface:

 Python
 Sublime Text Editor
 XAMP Server

3.1.4 Communication interface:

Windows

3.2 Functional requirements:

 User registration and authentication: Users should be able to create
accounts with their personal information.
 User Profile Management: Users should be able to update and
manage their profiles, including health history, contact information.
 Disease Database: The system should maintain a database of
diseases, including symptoms, risk factors, etc.

3.3 Performance requirements:

The capability of the computer depends on the performance of the
software. The software can take any number of inputs provided the
database size is larger enough. This would depend on the available
memory space.
1. Response Time: The system should provide predictions and responses
to user queries within a reasonable time frame, typically within seconds
to a few minutes, depending on the complexity of the analysis.

SPCE(CE),BAKROL Page | 16
 Software Engineering (3150711) Enrollment No:2112401070

2. Scalability: The system should be able to handle an increasing

number of users and data inputs without a significant decrease in
performance.
3. Accuracy: Algorithms used for data analysis and prediction should
be optimized for speed and efficiency.

3.4 Other requirements:

There are no other requirements.

Conclusion:
 In conclusion, the development and implementation of a multiple disease
prediction system using machine learning represent a promising frontier
in healthcare technology. Such systems have the potential to revolutionize
patient care, early disease detection, and health management.

PRACTICAL 3

SPCE(CE),BAKROL Page | 17
Software Engineering (3150711) Enrollment No:2112401070

Aim: To perform the user’s view analysis: Use case diagram

 Use Case Diagram :

• A use case diagram is used to represent the dynamic behaviour of a
system. It encapsulates the system's functionality by incorporating use
cases, actors, and their relationships. It models the tasks, services, and
functions required by a system/subsystem of an application. It depicts
the high-level functionality of a system and also tells how the user
handles a system.

 The following topics describe model elements in

use-case diagrams:
 Use cases:

A use case describes a function that a system performs to achieve the

user’s goal. A use case must yield an observable result that is of value
to the user of the system. Each use case describes a particular goal for
the user and how the user interacts with the system to achieve that
goal. The use case describes all possible ways that the system can
achieve, or fail to achieve, the goal of the user.

You can use use cases for the following

Determine the requirements of the
system Describe what the system
should do

Provide a basis for testing to ensure that the system works as

intended As the following figure illustrates, a use case is displayed
as an oval that contains the name of the use case.

SPCE(CE),BAKROL Page | 18
Software Engineering (3150711) Enrollment No:2112401070

You can add the following features to use cases:

Attributes that identify the properties of the objects in a use case

Operations that describe the behaviour of objects in a use

case and how they affect the system

Documentation that details the purpose and flow of events in

a use case

 Actors

• An actor represents a role of a user that interacts with the

system that you are modeling. The user can be a human user,
an organization, a machine, or another external system. You
can represent multiple users with a single actor and a single
user can have the role of multiple actors.
Actors are external to the system. They can initiate the
behaviour described in the use case or be acted upon by the use
case. Actors can also exchange data with the system. Each
actor has a unique name that describes the role of the user
who interacts with the system. As the following figure
illustrates, an actor is displayed as a line drawing of a person.

 Relationships in use-case diagrams

 In UML, relationships are connections between model elements.

 Use cases are also connected to each other in different kinds of
relationships.
 The relationship between two use cases basically models the
dependencies between two use cases.
 By reusing existing use cases using different types of relationships, the
overall effort required to develop the system is reduced.

SPCE(CE),BAKROL Page | 19
Software Engineering (3150711) Enrollment No:2112401070

 UML relationships are grouped into the following categories:



1. Association Relationships
An association is a relationship between two classifiers, such as an actor and use
cases, that describes the cause of the relationship and the rules that govern it. An
association is a relationship between an actor and a business use case. It indicates that
an actor can use the functionality of the business system.

Fig: Association Relationships

2. Generalization Relationships
A generalization relation is a relationship in which one model element (child) is
based on another model element (parent). Generalization relations are used in
class diagrams, component diagrams, deployment diagrams, and use case
diagrams to indicate that the child element accepts all the attributes, operations,
and relationships defined in the parent element.

Fig: Generalization
Relationship

SPCE(CE),BAKROL Page | 20
Software Engineering (3150711) Enrollment No:2112401070

3. Include Relationships
In UML modeling, a Include relationship is a relationship in which one use
case (base use case) contains the functionality of another use case (inclusion
use case). A containment relationship supports the reuse of functionality in the
use case model.

Fig: Include Relationships

4. Extending relationships

In UML modeling, you can use an extend relationship to specify that one use
case (extension) extends the behaviour of another use case (base). This type of
relationship reveals details about the system or application that are usually
hidden in the use case.

SPCE(CE),BAKROL Page | 21
Software Engineering (3150711) Enrollment No:2112401070

SPCE(CE),BAKROL Page | 22
Software Engineering (3150711) Enrollment No:2112401070

PRACTICAL 4

Aim: To draw the structural view diagram: Class diagram,

Object diagram

Class Diagram:

The class diagram depicts a static view of an application. It represents the

types of objects residing in the system and the relationships between them. A
class consists of its objects, and also it may inherit from other classes. A class
diagram is used to visualize, describe, document various different aspects of
the system, and also construct executable software code.

It shows the attributes, classes, functions, and relationships to give an overview

of the software system. It constitutes class names, attributes, and functions in a
separate compartment that helps in software development. Since it is a
collection of classes, interfaces, associations, collaborations, and constraints, it
is termed as a structural diagram.

The main purpose of class diagrams is to build a static view of an application.

It is the only diagram that is widely used for construction, and it can be
mapped with object- oriented languages. It is one of the most popular UML
diagrams. Following are the purpose of class diagrams given below:

 It analyses and designs a static view of an application.

 It describes the major responsibilities of a system.
 It is a base for component and deployment diagrams.
 It incorporates forward and reverse engineering.

Components of a Class Diagram :

A class notation consists of three parts:
Upper Section: The upper section encompasses the name of the class. A class is a
representation of similar objects that shares the same relationships, attributes, operations,

SPCE(CE),BAKROL Page | 23
Software Engineering (3150711) Enrollment No:2112401070

and semantics. Some of the following rules that should be taken into account while
representing a class are given below:

Capitalize the initial letter of the class name.

Place the class name in the center of the upper

section. A class name must be written in bold
format.

The name of the abstract class should be written in italics format.

Middle Section: The middle section constitutes the attributes, which
describe the quality of the class. The attributes have the following
characteristics:

The attributes are written along with its visibility factors, which are
public (+), private (-), protected (#), and package (~).

The accessibility of an attribute class is illustrated by the visibility

factors.
A meaningful name should be assigned to the attribute, which will
explain its usage inside the class.

Lower Section: The lower section contain methods or operations. The

methods are represented in the form of a list, where each method is written in
a single line. It demonstrates how a class interacts with data.

Class Relationships :

SPCE(CE),BAKROL Page | 24
Software Engineering (3150711) Enrollment No:2112401070

A class may be involved in one or more relationships with other classes. A

relationship can be one of the following types

Relationship Type Graphical Representation

Inheritance (or Generalization):

Represents an "is-a" relationship.
An abstract class name is shown in
italics.
SubClass1 and SubClass2 are
specializations of Super Class.
A solid line with a hollow arrowhead
that point from the child to the
parent class

Simple Association:

SPCE(CE),BAKROL Page | 25
Software Engineering (3150711) Enrollment No:2112401070

A structural link between two peer

classes.
There is an association between
Class1 and Class2
A solid line connecting two classes

Aggregation:
A special type of association. It
represents a "part of" relationship.
Class2 is part of Class1.
Many instances (denoted by the *) of
Class2 can be associated with Class1.
Objects of Class1 and Class2 have
separate lifetimes.
A solid line with an unfilled diamond
at the association end connected to
the class of composite

Composition:
A special type of aggregation where
parts are destroyed when the whole is
destroyed.
Objects of Class2 live and die with
Class1.
Class2 cannot stand by itself.
A solid line with a filled diamond at
the association connected to the class
of composite

Dependency:
Exists between two classes if the
changes to the definition of one may
cause changes to the other (but not
the other way around).
Class1 depends on Class2
A dashed line with an open arrow

Usage of Class diagrams

SPCE(CE),BAKROL Page | 26
Software Engineering (3150711) Enrollment No:2112401070

The class diagram is used to represent a static view of the system. It plays an
essential role in the establishment of the component and deployment
diagrams.. Class diagrams can be used for the following purposes:

1. To describe the static view of a system.

2. To show the collaboration among every instance in the static view.
3. To describe the functionalities performed by the system.
To construct the software application using object-oriented languages.

Object Diagram
Object diagrams are dependent on the class diagram as they are derived from
the class diagram. It represents an instance of a class diagram. The objects help
in portraying a static view of an object-oriented system at a specific instant.
Both the object and class diagram are similar to some extent; the only
difference is that the class diagram provides an abstract view of a system. It
helps in visualizing a particular functionality of a system.

Notation of an Object Diagram

Class Diagram for Multiple Disease Prediction System Using

Machine Learning

SPCE(CE),BAKROL Page | 27
Software Engineering (3150711) Enrollment No:2112401070

PRACTICAL 5

SPCE(CE),BAKROL Page | 28
Software Engineering (3150711) Enrollment No:2112401070

Aim: To draw the behavioural view diagram: Sequence

diagram.
UML behavioural diagrams visualize, specify, construct, and document the
dynamic aspects of a system. The behavioural diagrams are categorized as
follows: use case diagrams, interaction diagrams, state–chart diagrams, and
activity diagrams.

Sequence Diagrams :
The sequence diagram represents the flow of messages in the system and is also
termed as an event diagram. It helps in envisioning several dynamic scenarios.
It portrays the communication between any two lifelines as a time-ordered
sequence of events, such that these lifelines took part at the run time. In UML,
the lifeline is represented by a vertical bar, whereas the message flow is
represented by a vertical dotted line that extends across the bottom of the page.
It incorporates the iterations as well as branching.

Notations of a Sequence Diagram :

1. Lifeline : An individual participant in the sequence diagram is represented by a
lifeline. It is positioned at the top of the diagram.

2. Actor: A role played by an entity that interacts with the subject is called as an
actor. It is out of the scope of the system. It represents the role, which
involves human users and external hardware or subjects. An actor may or may
not represent a physical entity, but it purely depicts the role of an entity.

SPCE(CE),BAKROL Page | 29
Software Engineering (3150711) Enrollment No:2112401070

3. Activation : It is represented by a thin rectangle on the lifeline. It describes

that time period in which an operation is performed by an element, such that
the top and the bottom of the rectangle is associated with the initiation and
the completion time, each respectively.
4. Messages : The messages depict the interaction between the objects and are
represented by arrows. They are in the sequential order on the lifeline. The
core of the sequence diagram is formed by messages and lifelines.

Following are types of messages enlisted below:

a. Call Message : It defines a particular communication between the lifelines of
an interaction, which represents that the target lifeline has invoked an
operation.

b. Return Message : It defines a particular communication between the lifelines

of interaction that represent the flow of information from the receiver of the
corresponding caller message.

SPCE(CE),BAKROL Page | 30
Software Engineering (3150711) Enrollment No:2112401070

c. Self Message: It describes a communication, particularly between the lifelines

of an interaction that represents a message of the same lifeline, has been
invoked.

d. Recursive Message : A self message sent for recursive purpose is called a

recursive message. In other words, it can be said that the recursive message is
a special case of the self message as it represents the recursive calls.

e. Create Message: It describes a communication, particularly between

the lifelines of an interaction describing that the target (lifeline) has
been instantiated.

SPCE(CE),BAKROL Page | 31
Software Engineering (3150711) Enrollment No:2112401070

f. Destroy Message : It describes a communication, particularly between the

lifelines of an interaction that depicts a request to destroy the lifecycle of the
target.

g. Duration Message: It describes a communication particularly between the

lifelines of an interaction, which portrays the time passage of the message
while modeling a system.

SPCE(CE),BAKROL Page | 32
Software Engineering (3150711) Enrollment No:2112401070

5. Note : A note is the capability of attaching several remarks to the element. It

basically carries useful information for the modelers.

6. Sequence Fragments :Sequence fragments have been introduced by UML 2.0,

which makes it quite easy for the creation and maintenance of an accurate
sequence diagram. It is represented by a box called a combined fragment,
encloses a part of interaction inside a sequence diagram.

Sequence Diagram for Multiple Disease Prediction using Machine

Learning

SPCE(CE),BAKROL Page | 33
Software Engineering (3150711) Enrollment No:2112401070

PRACTICAL 6

SPCE(CE),BAKROL Page | 34
Software Engineering (3150711) Enrollment No:2112401070

Aim: To draw the behavioral view diagram: State-chart diagram,

Activity diagram.

 State Diagrams
A state diagram is used to represent the condition of the system or part of the
system at finite instances of time. It’s a behavioral diagram and it represents the
behavior using finite state transitions. State diagrams are also referred to as
State machines and State-chart Diagrams. These terms are often used
interchangeably.
Basic components of a state chart diagram –

1. Initial state – We use a black filled circle represent the initial state of a
System or a class.

2. Transition – We use a solid arrow to represent the transition or change of

control from one state to another. The arrow is labelled with the event
which causes the change in state.

3. State – We use a rounded rectangle to represent a state. A state

represents the conditions or circumstances of an object of a class at an
instant of time.

4. Fork – We use a rounded solid rectangular bar to represent a Fork

notation with incoming arrow from the parent state and outgoing arrows
towards the newly created states. We use the fork notation to represent a
state splitting into two or more concurrent states.

SPCE(CE),BAKROL Page | 35
Software Engineering (3150711) Enrollment No:2112401070

5. Join – We use a rounded solid rectangular bar to represent a Join notation

with incoming arrows from the joining states and outgoing arrow towards
the common goal state. We use the join notation when two or more
states concurrently converge into one on the occurrence of an event or
events.

6. Self transition – We use a solid arrow pointing back to the state itself to
represent a self-transition. There might be scenarios when the state of
the object does not change upon the occurrence of an event. We use self
transitions to represent such cases.

7. Composite state – We use a rounded rectangle to represent a composite

state also. We represent a state with internal activities using a composite
state.

SPCE(CE),BAKROL Page | 36
Software Engineering (3150711) Enrollment No:2112401070

8. Final state – We use a filled circle within a circle notation to represent the
final state in a state machine diagram.

 Activity diagram :
The activity diagram is used to demonstrate the flow of control within the
system rather than the implementation. It models the concurrent and sequential
activities.
The activity diagram helps in envisioning the workflow from one activity to
another. It put emphasis on the condition of flow and the order in which it
occurs. The flow can be sequential, branched, or concurrent, and to deal with
such kinds of flows, the activity diagram has come up with a fork, join, etc.
It is also termed as an object-oriented flowchart. It encompasses activities
composed of a set of actions or operations that are applied to model the
behavioral diagram.
Components of an Activity Diagram :

Following are the component of an activity diagram:

1. Activities :

The categorization of behavior into one or more actions is termed as an

activity. In other words, it can be said that an activity is a network of nodes that
are connected by edges. The edges depict the flow of execution. It may contain
action nodes, control nodes, or object nodes.
The control flow of activity is represented by control nodes and object nodes
that illustrates the objects used within an activity. The activities are initiated at
the initial node and are terminated at the final node.

SPCE(CE),BAKROL Page | 37
Software Engineering (3150711) Enrollment No:2112401070

2. Forks
Forks and join nodes generate the concurrent flow inside the activity. A fork node
consists of one inward edge and several outward edges. It is the same as that of
various decision parameters. Whenever a data is received at an inward edge, it gets
copied and split crossways various outward edges. It split a single inward flow into
multiple parallel flows.

3. Join Nodes : Join nodes are the opposite of fork nodes. A Logical AND
operation is performed on all of the inward edges as it synchronizes the
flow of input across one single output (outward) edge.

4. Pins : It is a small rectangle, which is attached to the action rectangle. It

clears out all the messy and complicated thing to manage the execution
flow of activities. It is an object node that precisely represents one input to
or output from the action.

SPCE(CE),BAKROL Page | 38
Software Engineering (3150711) Enrollment No:2112401070

Notation of an Activity diagram :

Activity diagram constitutes following notations:

 Initial State: It depicts the initial stage or beginning of the set of actions.
 Final State: It is the stage where all the control flows and object flows end.
 Decision Box: It makes sure that the control flow or object flow will follow
only one path.
 Action Box: It represents the set of actions that are to be performed.

Activity Diagram for Multiple Disease Prediction System using

Machine Learning

SPCE(CE),BAKROL Page | 39
Software Engineering (3150711) Enrollment No:2112401070

SPCE(CE),BAKROL Page | 40
Software Engineering (3150711) Enrollment No:2112401070

PRACTICAL 7

Aim: To perform the function oriented diagram: DFD and

Structured chart

Function Oriented design is a method to software design where the model is

decomposed into a set of interacting units or modules where each unit or
module has a clearly defined function. Thus, the system is designed from a
functional viewpoint.

Data Flow Diagrams :

A Data Flow Diagram (DFD) is a traditional visual representation of the
information flows within a system. A neat and clear DFD can depict the
right amount of the system requirement graphically. It can be manual,
automated, or a combination of both.
It shows how data enters and leaves the system, what changes the
information, and where data is stored.
The objective of a DFD is to show the scope and boundaries of a system as a
whole. It may be used as a communication tool between a system analyst and
any person who plays a part in the order that acts as a starting point for
redesigning a system. The DFD is also called as a data flow graph or bubble
chart.
Data Flow Diagram Symbols :

DFD can represent Source, destination, storage and flow of data using the
following set of components –

Process: This represents any task that is performed by the system on the
input data. It results in a processed output of data. A process can be related to
the modification, storing, deletion, creation, or any other operation on data. It
is represented by a circle or a round-edged rectangle.

SPCE(CE),BAKROL Page | 41
Software Engineering (3150711) Enrollment No:2112401070

Database: This is where data is stored in a system. It can also be the input
or output of a process as well. It is represented by a rectangle, which can
sometimes have a small section for its ID.

Entities: They are either the source or the termination of the DFD. Ideally,
they represent an external source from where data is taken or processed in
the end. Entities are represented by a closed square/rectangle.

Data Flow: Lastly, we use directional arrows to represent the flow of data
from one entity/database to another. The line would have a directional
arrow in the end to depict the source and the destination units.

Data Flow Diagram Levels:

Data Flow Diagrams are composed of levels and layers, from the basic to the
higher level. The level of the diagram depends upon the scope of the process.
As the level increases, the complexity of the diagram increases. The high-
level Data Flow Diagrams are categorized into low levels with more detailed
process information.
Level 0 DFDs :

The Level 0 data flow diagram gives a general overview of the process. They
are also called context diagrams. The level 0 DFDs depict the single process

SPCE(CE),BAKROL Page | 42
Software Engineering (3150711) Enrollment No:2112401070

node and its links with external entities. It is understood by all the
stakeholders participating in the activity.

Level 1 DFDs :
The Level 1 data flow diagrams are the more detailed breakout of parts of
the Level 0 DFDs. In a level 1 DFD, the single process node is broken down
into sub-processes with additional data flows and data stores to connect
them.

Level 2 DFDs :
The Level 2 data Flow diagrams go into deeper sub-processes to better
illustrate a process and its stages. More symbols, shapes, and text are
required to detail the process depicting the system's functioning.

SPCE(CE),BAKROL Page | 43
Software Engineering (3150711) Enrollment No:2112401070

SPCE(CE),BAKROL Page | 44
Software Engineering (3150711) Enrollment No:2112401070

DFD Diagram for Multiple Disease Prediction System using Machine

Learning

SPCE(CE),BAKROL Page | 45
Software Engineering (3150711) Enrollment No:2112401070

PRACTICAL 8

Aim: To draw the environmental view diagram: Deployment

diagram.

The deployment diagram visualizes the physical hardware on which the

software will be deployed. It portrays the static deployment view of a system. It
involves the nodes and their relationships.

It ascertains how software is deployed on the hardware. It maps the software

architecture created in design to the physical system architecture, where the
software will be executed as a node. Since it involves many nodes, the
relationship is shown by utilizing communication paths.

Purpose of Deployment Diagram :

The main purpose of the deployment diagram is to represent how software is

installed on the hardware component. It depicts in what manner a software
interacts with hardware to perform its execution.

Both the deployment diagram and the component diagram are closely
interrelated to each other as they focus on software and hardware components.
The component diagram represents the components of a system, whereas the
deployment diagram describes how they are actually deployed on the hardware.

The deployment diagram does not focus on the logical components of the
system, but it put its attention on the hardware topology.

Following are the purposes of deployment diagram enlisted below:

1. To envision the hardware topology of the system.

2. To represent the hardware components on which the software
components are installed.
3. To describe the processing of nodes at the runtime.

SPCE(CE),BAKROL Page | 46
Software Engineering (3150711) Enrollment No:2112401070

Symbol and notation of Deployment diagram

The deployment diagram consist of the following notations:
 A component
 An artifact
 An interface
 A node

Example of a Deployment diagram

Example 1 : Following deployment diagram represents the working of
HTML5 video player in the browser:

SPCE(CE),BAKROL Page | 47
Software Engineering (3150711) Enrollment No:2112401070

Example 2 :The following deployment diagram of an order management

system.

SPCE(CE),BAKROL Page | 48
Software Engineering (3150711) Enrollment No:2112401070

Deployment diagrams can be used for the followings:

 To model the network and hardware topology of a system.
 To model the distributed networks and systems.
 Implement forwarding and reverse engineering processes.
 To model the hardware details for a client/server system.
 For modeling the embedded system

SPCE(CE),BAKROL Page | 49
Software Engineering (3150711) Enrollment No:2112401070

PRACTICAL 9

Aim: Study of any two Open source tools in DevOps.

DevOps is a set of practices, tools, and a cultural philosophy that automate

and integrate the processes between software development and IT teams. It
emphasizes team empowerment, cross-team communication and
collaboration, and technology automation.

The DevOps movement began around 2007 when the software development
and IT operations communities raised concerns about the traditional
software development model, where developers who wrote code worked
apart from operations who deployed and supported the code. The term
DevOps, a combination of the words development and operations, reflects
the process of integrating these disciplines into one, continuous process.

DevOps isn’t just a cultural shift — it requires great tools to come to

fruition. Below, we’ve pulled together a list of some of the most well-loved
DevOps tools available today. But, throwing loads of money into fancy SaaS
solutions can quickly gobble up the cloud budget. These DevOps tools all
are open source, and enable everything from container builds and
orchestration to microservices networking, configuration management,
CI/CD automation, full-stack monitoring and more.

Most popular DevOps tools for Infrastructure automation and Monitoring

are given below.

1. Jenkins
2. Puppet
3. Chef
4. Vagrant
5. Docker
6. Saltstack
7. Ansible
8. Juju

SPCE(CE),BAKROL Page | 50
Software Engineering (3150711) Enrollment No:2112401070

9. Sensu
10. Consul
11. New Relic
12. Monit

Jenkins is a Java-based continuous integration tool used for

orchestration for the application provisioning and deployment. It
has to be associated with a version control system (SVN) when you
want a new code to push into the code repository.

The Jenkins server allows you to build and test the new code and
notifies the team about the process, changes and final results.
Jenkins as an orchestration tool used for building pipelines. You
can also configure polls for any comments on SVN and trigger
builds and regression tests on the new code that is added
according

to the latest code commits.

Puppet is a ruby based configuration management tool. It is

written with puppet DSL and is wrapped in modules. Puppet is
developed with special consideration of system administrators.
The design of Puppet felicitates fast deployment, efficiently
manages the infrastructure as code with a task-based approach.
Which improves the overall quality of the software. It runs a
puppet agent running on all servers that need to be configured.
Instead of running any codes on the infrastructure it builds a
graph that represents the code base of the infrastructure. It will
also figure out the best possibilities to achieve the desired state.
Puppet pulls a complied module with the specification desired and
installs the software needed to complete the tasks. You can
find all the puppet

community modules called Puppet forge here.

Chef is one of the most popular agent- based cloud infrastructure

SPCE(CE),BAKROL Page | 51
Software Engineering (3150711) Enrollment No:2112401070

automation tool for configuration management. Ruby-based DSL is

used, you have to code your infrastructure and define the
configuration scenarios.. Chef is helpful to maintain consistent
configuration, this reduces the operating costs, with effective data
centers management. And it also offers customization, flexibility,
and readable configuration policies. The tools provide the support
of simple migration, allows you to integrate with multiple
platforms such as FreeBSD and AIX. Chef provides you with a rich
selection of ready to use templates. You can find everything
you

need on the community cookbook here.

Vagrant is another most popular tool for configuring virtual

machines for your development environment. The tools run on

the top of VM solutions such as Virtualbox HyperV etc. Vagrant
can handle all the configurations with help for Vagrantfile. This
Vagrantfile contains all the configurations required for the Virtual
machines. You can create a configuration, it can be shared with
other developers to imitate the process of the same configuration.
Vagrant also provides plugins for cloud provisioning, infrastructure
automation tools.

Docker will be another most preferred tools for continuous

integration and deployment. Docker is an automation tool build
on the top of Linux containers with the support for
containerization. Docker works on the concept of process-level
virtualization and creates isolated environments for applications
which are known as containers. The containers can be easily
shipped to another server without any changes made to the
application, which further doesn’t have any OS-related
dependencies. Docker is predominantly used by DevOps

SPCE(CE),BAKROL Page | 52
Software Engineering (3150711) Enrollment No:2112401070

professionals in cloud computing and has active

community support on both Windows and Linux.

Saltsack is a Python-based configuration management tool. Unlike

like few other tools which pull the code for configuration from the
server, Saltstack pushes the code to various node simultaneously.
It compiles the code faster than Puppet and Chef and
the

configuration of the code is also pretty quick.

PRACTICAL 10

Aim: Estimating effort using FP Estimation for chosen system

Effort estimation :The managers estimate efforts in terms of personnel

requirement and man-hour required to produce the software. For effort
estimation software size should be known. This can either be derived by

SPCE(CE),BAKROL Page | 53
Software Engineering (3150711) Enrollment No:2112401070

managers’ experience, organization’s historical data or software size can be

converted into efforts by using some standard formulae.

A Function Point (FP) is a unit of measurement to express the amount of

business functionality, an information system (as a product) provides to a user.
FPs measure software size. They are widely accepted as an industry standard
for functional sizing.

It has Five Main Components: Data

Functions Internal Logical Files

External Interface Files Transactional

Functions

External Inputs External Outputs External

Inquiries Internal Logical Files –

The first data function allows users to utilize data they are responsible for
maintaining. For example, a pilot may enter navigational data through a display
in the cockpit prior to departure. The data is stored in a file for use and can be
modified during the mission.

Therefore the pilot is responsible for maintaining the file that contains the
navigational information. Logical groupings of data in a system, maintained by
an end user, are referred to as Internal Logical Files (ILF).

External Interface Files –

The second Data Function a system provides an end user is also related to
logical groupings of data. In this case the user is not responsible for
maintaining the data. The data resides in another system and is maintained by
another user or system. The user of the system being counted requires this data
for reference purposes only. For example, it may be necessary for a pilot to
reference position data from a satellite or ground-based facility during flight.

SPCE(CE),BAKROL Page | 54
Software Engineering (3150711) Enrollment No:2112401070

The pilot does not have the responsibility for updating data at these sites but
must reference it during the flight. Groupings of data from another system that
are used only for reference purposes are defined as External Interface Files
(EIF).

The remaining functions address the user's capability to access the data
contained in ILFs and EIFs. This capability includes maintaining, inquiring and
outputting of data. These are referred to as Transactional Functions.

External Input –

The first Transactional Function allows a user to maintain Internal

Logical Files (ILFs) through the ability to add, change and delete the data. For
example, a pilot can add, change and delete navigational information prior to
and during the mission. In this case the pilot is utilizing a transaction referred to
as an External Input (EI). An External Input gives the user the capability to
maintain the data in ILF's through adding, changing and deleting its contents.

External Output –

The next Transactional Function gives the user the ability to produce outputs.
For example a pilot has the ability to separately display ground speed, true air
speed and calibrated air speed. The results displayed are derived using data that
is maintained and data that is referenced. In function point terminology the
resulting display is called an External Output (EO).

External Inquiries –

The final capability provided to users through a computerized system addresses

the requirement to select and display specific data from files. To accomplish
this user inputs selection information that is used to retrieve data that meets the
specific criteria. In this situation there is no manipulation of the data. It is a
direct retrieval of information contained on the files. For example if a pilot
displays terrain clearance data that was previously set, the resulting output is

SPCE(CE),BAKROL Page | 55
Software Engineering (3150711) Enrollment No:2112401070

the direct retrieval of stored information. These transactions are referred to as

External Inquiries (EQ).

Function Point Analysis :

The basic and primary purpose of the functional point analysis is to measure and
provide the software application functional size to the client, customer, and the
stakeholder on their request. Further, it is used to measure the software project
development along with its maintenance, consistently throughout the project
irrespective of the tools and the technologies.

For Computing Function Points

FP = Count Total * [ 0.65 + 0.01 *

∑(Fi) ]

Count Total is the sum of all FP entries

Fi (i=1 to 14) are complexity value adjustment factors (VAF).

SPCE(CE),BAKROL Page | 56
Software Engineering (3150711) Enrollment No:2112401070

SPCE(CE),BAKROL Page | 57