PSIT-Pranveer Singh Institute of Technology

Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

PRANVEER SINGH INSTITUTE OF TECHNOLOGY,

KANPUR

DEPARTMENT OF DATA SCIENCE

Even Semester 2025-26

B. Tech.- Third Year

Semester - VI

Lab File
Software Engineering
(BCS 651)

Submitted To: Submitted By:

Faculty Name :_________________ Name :_________________
Designation :_________________ Roll No. :_________________
Section :_________________

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

Table of Contents
 Vision and Mission Statements of the Institute

 Vision and Mission Statements of the Department

 PEOs, POs, PSOs of the Department

 Course Objective and Outcomes

 List of Experiments

 Index

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

Department Vision Statement

To be recognized, the Department of Computer Science & Engineering produces versatile
computer engineers, capable of adapting to the changing needs of computer and related industry.

Department Mission Statements

The mission of the Department of Computer Science and Engineering is:

i. To provide broad-based education with knowledge and attitude to succeed in Computer

Science & Engineering careers.

ii. To prepare students for emerging trends in computer and related industry.

iii. To develop competence in students by providing them with skills and aptitude to foster
culture of continuous and lifelong learning.

iv. To develop practicing engineers who investigate research, design, and find workable
solutions to complex engineering problems with awareness & concern for society as well as the
environment.

Program Educational Objectives (PEOs)

i. The graduates will be efficient leading professionals with knowledge of computer science &
engineering discipline that enables them to pursue higher education and/or successful careers in
various domains.

ii. Graduates will possess the capability of designing successful innovative solutions to real life
problems that are technically sound, economically viable and socially acceptable.

iii. Graduates will be competent team leaders, effective communicators and capable of working
in multidisciplinary teams following ethical values.

iv. The graduates will be capable of adapting to new technologies/tools and constantly upgrading
their knowledge and skills with an attitude for lifelong learning

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

Department Program Outcomes (POs)

The students of the Computer Science and Engineering Department will be able:

1. Engineering knowledge: Apply the knowledge of mathematics, science, Computer

Science & Engineering fundamentals, and an engineering specialization to the solution
of complex engineering problems.

2. Problem analysis: Identify, formulate, review research literature, and analyze complex
engineering problems reaching substantiated conclusions using first principles of
mathematics, natural sciences, and Computer Science & Engineering sciences.

3. Design/development of solutions: Design solutions for complex Computer Science &

Engineering problems and design system components or processes that meet the
specified needs with appropriate consideration for public health and safety, and the
cultural, societal, and environmental considerations.

4. Investigation: Use research-based knowledge and research methods including design of

experiments, analysis and interpretation of data, and synthesis of the information to
provide valid conclusions.

5. Modern tool usage: Create, select, and apply appropriate techniques, resources, and
modern engineering and IT tools including prediction and modelling to complex
Computer Science & Engineering activities with an understanding of the limitations.

6. Engineering and Society: Apply reasoning informed by contextual knowledge to

assess societal, health, safety, legal and cultural issues and the consequent
responsibilities relevant to the professional engineering practice in the field of Computer
Science and Engineering.

7. Environment and sustainability: Understand the impact of the professional Computer

Science & Engineering solutions in societal and environmental contexts, and
demonstrate the knowledge of, and need for sustainable development.

8. Ethics: Apply ethical principles and commit to professional ethics and responsibilities
and norms of the Computer Science & Engineering practice.

9. Individual and team work: Function effectively as an individual, and as a member or

leader in diverse teams, and in multidisciplinary settings.

10. Communication: Communicate effectively on complex Computer Science &

Engineering activities with the engineering community and with society at large, such as

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

being able to comprehend and write effective reports and design documentation, making
effective presentations, and giving and receiving clear instructions.

11. Project management and finance: Demonstrate knowledge and understanding of the
Computer Science & Engineering and management principles and apply these to one’s
own work, as a member and leader in a team, to manage projects and in
multidisciplinary environments.

12. Life-long learning: Recognize the need for and have the preparation and ability to
engage in independent and life-long learning in the broadest context of technological
change.

Department Program Specific Outcomes (PSOs)

The students will be able to:

1. Use algorithms, data structures/management, software design, concepts of programming

languages and computer organization and architecture.

2. Understand the processes that support the delivery and management of information
systems within a specific application environment.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

Course Outcomes
*Level of Bloom’s
*Level of Bloom’s Taxonomy Level to be met Level to be met
Taxonomy
L1: Remember 1 L2: Understand 2
L3: Apply 3 L4: Analyze 4
L5: Evaluate 5 L6: Create 6

CO Number Course Outcomes

BCS-651.1 Define [1. Knowledge] the specification standard of IEEE for writing SRS.
BCS-651.2 Discuss [2. Comprehension] the scope of Software Engineering to students where
they can infer small, real-life problems.
Apply [3. Application] the development & design concepts in DFDs, UML
BCS-651.3
Diagrams, others to develop, implement, and demonstrate the learning through a
project that meet stated specifications.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

List of Experiments

Lab No. Lab Experiment Corresponding CO

Prepare a SRS document in line with the IEEE
1 recommended standards. CO1
Draw the case diagram and specify the role of each of the
2 actors. Also state the precondition, post condition and CO1
function of each use case.
3 Draw the activity diagram. CO1
Identify the classes. Classify them as weak and strong
4 classes and draw the class diagram. CO3

5 Draw the sequence diagram for any two scenarios. CO1

6 Draw the collaboration diagram. CO2

7 Draw the state chart diagram. CO3

8 Draw the component diagram. CO2

Perform forward engineering in java. (Model to code
9 conversion) CO3
Perform reverse engineering in java. (Code to Model
10 conversion) CO3

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

INDEX
Date of Date of Faculty
S No Lab Experiment Marks
Experiment Submission Signature
To Prepare a SRS document in line
1 with the IEEE recommended
Standards
Draw the Use Case diagram and
specify the role of each of the actors.
2 Also state the precondition, post
condition and function of each use
case.
To draw a activity diagram for a real
3
project or system.
Identify the classes. Classify them as
4 weak and strong classes and draw the
class diagram.
Draw the sequence diagram for any
5
two scenarios.
Draw the collaboration diagram using
6
Star UML.
To prepare State Chart diagram for
7
project.
Draw the Component Diagram using
8
Star UML
Draw the Deployment Diagram using
9
Star UML.
To draw a sample E-R diagram of
10
project.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

EXPERIMENT 1

Aim: To Prepare a SRS document in line with the IEEE recommended Standards

Requirements:

Software Requirements:

Star UML, Windows XP,

Theory:

An SRS is basically an organization's understanding (in writing) of a customer or

potential client's system requirements and dependencies at a particular point in time
(usually) prior to any actual design or development work. It's a two-way insurance policy
that assures that both the client and the organization understand the other's requirements
from that perspective at a given point in time.
SRSs are typically developed during the first stages of "Requirements Development,"
which is the initial product development phase in which information is gathered about
what requirements are needed--and not. This information-gathering stage can include
onsite visits, questionnaires, surveys, interviews, and perhaps a return-on-investment
(ROI) analysis or needs analysis of the customer or client's current business environment.
The actual specification, then, is written after the requirements have been gathered and
analyzed.

SRS should address the following

The basic issues that the SRS shall address are the following:
a) Functionality. What is the software supposed to do?

b) External interfaces. How does the software interact with people, the system’s hardware,
other hardware, and other software?

c) Performance. What is the speed, availability, response time, recovery time of various
software functions, etc.?

d) Attributes. What are the portability, correctness, maintainability, security, etc.

considerations?

e) Design constraints imposed on implementation. Are there any required standards in

effect, language implementation, policies for database integrity, resource limits, operating
environment(s) etc.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

1. Introduction
1.1 Purpose
The purpose of this document is to specify the requirements for the AI Integrated Resume
Builder and Analyzer system. This SRS defines the functional and non-functional requirements
for the web-based application that utilizes Google Gemini AI to help users build, analyze, and
optimize professional resumes.
1.2 Scope
The AI Resume Builder and Analyzer is a web application that allows users to: (a) Create
structured professional resumes with personal information, experience, education, skills,
projects, and certifications; (b) Receive an AI-generated professional summary; (c) Analyze
existing resume text against job descriptions; (d) Get AI-powered career insights and job
recommendations; (e) Chat with a virtual AI career mentor.
1.3 Intended Audience
• Final-year and undergraduate students seeking internships/jobs
• Working professionals who want to update their resumes
• Career counselors and HR professionals
• Developers maintaining/extending the system
•
1.4 Definitions and Acronyms
Term Definition

ATS Applicant Tracking System – software used by recruiters to

scan resumes

API Application Programming Interface

Gemini AI Google's large language model used for AI content generation

SRS Software Requirements Specification

2. Overall Description

2.1 Product Perspective

The AI Integrated Resume Builder and Analyzer is a standalone web application. It connects to
Google Gemini AI via REST API calls from the [Link] backend. Users interact via a
browser-based frontend. Resumes are stored as HTML files on the server file system, and session
data (chat history, resume data) is maintained in server memory.
2.2 Product Functions
• Resume Builder: Accepts user input for all resume sections and generates a
formatted HTML resume
• AI Summary Generator: Generates a professional 2–3 sentence summary using
Gemini
• Resume Analyzer: Scores and provides feedback on resume text against a job
description
• Career Mentor Chat: Chat interface with an AI career mentor powered by Gemini
• Career Insights: AI-generated career level, recommended roles, skill gaps, and
next steps
• Job Recommendations: AI-generated personalized job suggestions with match

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

scores
• Skill Alignment Analyzer: Compares user skills against a target role
• Dashboard Overview: Shows profile completeness and recent activity

2.3 User Classes

• Job Seeker: Creates and downloads resumes, uses chat mentor
• Admin/Developer: Maintains API keys, manages server and file storage
2.4 Operating Environment
• Server: [Link] v18+ on Windows/Linux/macOS
• Client: Modern web browser (Chrome, Firefox, Edge)
• Network: Internet connection required for Gemini AI API calls
2.5 Design and Implementation Constraints
• Google Gemini API key (GEMINI_API_KEY) must be configured in the .env file
• In-memory storage means data is lost on server restart
• Maximum request payload: 10MB (configured via [Link] limit)

3. External Interface Requirements

3.1 User Interfaces

The application provides two main HTML pages: [Link] (Resume Builder) and
[Link] (Career Dashboard). The UI is responsive, browser-based, and requires no
installation on the client side.
3.2 Software Interfaces
• Google Generative AI SDK (@google/genai v1.38.0) — Gemini 2.5 Flash model
• [Link] (v4.18.2) — HTTP server and routing
• dotenv (v16.3.1) — Environment variable management
• cors (v2.8.5) — Cross-origin resource sharing middleware
4. System Features
Feature ID Feature Name Priority API Endpoint

F-01 Resume Builder High POST /api/resume/build

F-02 Resume Analyzer High POST /api/resume/analyze

F-03 AI Mentor Chat High POST /api/mentor/chat

F-04 Career Insights Medium GET /api/career/insights

F-05 Job Recommendations Medium POST

/api/career/jobrecommendations

F-06 Skill Alignment Medium GET /api/alignment/skills

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

F-07 Dashboard Overview Low GET

/api/dashboard/overview

5. Non-Functional Requirements
5.1 Performance
• API response time for resume build: < 5 seconds
• Gemini AI response time: < 8 seconds under normal network conditions
• Supports at least 20 concurrent users on the server
5.2 Security
• GEMINI_API_KEY is stored securely in .env file and never exposed to the client
• CORS middleware restricts unauthorized cross-origin requests
• Input payload limited to 10MB to prevent denial-of-service attacks
5.3 Reliability
• System gracefully handles Gemini API failures by returning fallback messages
• Server uptime target: 99% during active usage hours
5.4 Maintainability
• Modular route structure with clear section comments in [Link]
• ES Module (import/export) syntax for clean dependency management

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

EXPERIMENT 2

Aim: Draw the use case diagram and specify the role of each of the actors. Also state the
precondition, post condition and function of each use case.

Software Requirements:

Star UML, Windows XP,

Theory:

According to the UML specification a use case diagram is “a diagram that shows the
relationships among actors and use cases within a system.” Use case diagrams are often
used to:

 Provide an overview of all or part of the usage requirements for a system or

organization in the form of an essential model or a business model
 Communicate the scope of a development project
 Model your analysis of your usage requirements in the form of a system use case
model

Use case models should be developed from the point of view of your project stakeholders
and not from the (often technical) point of view of developers. There are guidelines for:

Use Cases

Actors

Relationships

System Boundary Boxes

1. Use Cases

A use case describes a sequence of actions that provide a measurable value to an actor. A
use case is drawn as a horizontal ellipse on a UML use case diagram.

1. Use Case Names Begin with a Strong Verb

2. Name Use Cases Using Domain Terminology
3. Place Your Primary Use Cases in the Top-Left Corner of The Diagram
4. Imply Timing Considerations by Stacking Use Cases.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

2. Actors

An actor is a person, organization, or external system that plays a role in one or more
interactions with your system (actors are typically drawn as stick figures on UML Use
Case diagrams).

1. Place Your Primary Actor(S) In the Top-Left Corner of the Diagram

2. Draw Actors to the Outside of a Use Case Diagram
3. Name Actors with Singular, Business-Relevant Nouns
4. Associate Each Actor with One Or More Use Cases
5. Actors Model Roles, Not Positions
6. Use <<system>> to Indicate System Actors
7. Actors Don’t Interact With One Another
8. Introduce an Actor Called “Time” to Initiate Scheduled Events

3. Relationships

There are several types of relationships that may appear on a use case diagram:

 An association between an actor and a use case

 An association between two use cases
 A generalization between two actors
 A generalization between two use cases

Associations are depicted as lines connecting two modeling elements with an optional
open-headed arrowhead on one end of the line indicating the direction of the initial
invocation of the relationship. Generalizations are depicted as a close-headed arrow with
the arrow pointing towards the more general modeling element.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

1. Indicate An Association Between an Actor and a Use Case If the Actor Appears
within the Use Case Logic
2. Avoid Arrowheads on Actor-Use Case Relationships
3. Apply <<include>> When You Know Exactly When to Invoke the Use Case
4. Apply <<extend>> When A Use Case May Be Invoked Across Several Use Case
Steps
5. Introduce <<extend>> associations sparingly
6. Generalize Use Cases When a Single Condition Results in Significantly New
Business Logic
7. Do Not Apply <<uses>>, <<includes>>, or <<extends>>
8. Avoid More Than Two Levels of Use Case Associations
9. Place An Included Use Case to the Right of the Invoking Use Case
10. Place An Extending Use Case Below the Parent Use Case
11. Apply the “Is Like” Rule to Use Case Generalization
12. Place an Inheriting Use Case Below the Base Use Case
13. Apply the “Is Like” Rule to Actor Inheritance
14. Place an Inheriting Actor Below the Parent Actor

4. System Boundary Boxes

The rectangle around the use cases is called the system boundary box and as the name
suggests it indicates the scope of your system – the use cases inside the rectangle
represent the functionality that you intend to implement.

1. Indicate Release Scope with a System Boundary Box.

2. Avoid Meaningless System Boundary Boxes.

Creating Use Case Diagrams

We start by identifying as many actors as possible. You should ask how the actors
interact with the system to identify an initial set of use cases. Then, on the diagram, you
connect the actors with the use cases with which they are involved. If actor supplies
information, initiates the use case, or receives any information as a result of the use case,
then there should be an association between them.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

EXPERIMENT 3

AIM :- To draw a activity diagram for a real project or system.

To draw a activity diagram for a real project or system.

Software Requirements: Star UML, Windows XP,

THEORY

UML 2 activity diagrams are typically used for business process modeling, for modeling
the logic captured by a single use case or usage scenario, or for modeling the detailed
logic of a business rule. Although UML activity diagrams could potentially model the
internal logic of a complex operation it would be far better to simply rewrite the
operation so that it is simple enough that you don’t require an activity diagram. In many
ways UML activity diagrams are the object-oriented equivalent of flow charts and data
flow diagrams (DFDs) from structured development.

Basic notation:

 Initial node. The filled in circle is the starting point of the diagram. An initial
node isn’t required although it does make it significantly easier to read the
diagram.
 Activity final node. The filled circle with a border is the ending point. An activity
diagram can have zero or more activity final nodes.
 Activity. The rounded rectangles represent activities that occur. An activity may
be physical, such as Inspect Forms, or electronic, such as Display Create Student
Screen.
 Flow/edge. The arrows on the diagram. Although there is a subtle difference
between flows and edges never a practical purpose for the difference.
 Fork. A black bar with one flow going into it and several leaving it. This denotes
the beginning of parallel activity.
 Join. A black bar with several flows entering it and one leaving it. All flows
going into the join must reach it before processing may continue. This denotes the
end of parallel processing.
 Condition. Text such as[Incorrect Form] on a flow, defining a guard which must
evaluate to true to traverse the node.
 Decision. A diamond with one flow entering and several leaving. The flows
leaving include conditions although some modelers will not indicate the
conditions if it is obvious.
 Merge. A diamond with several flows entering and one leaving. The implication
is that one or more incoming flows must reach this point until processing
continues, based on any guards on the outgoing flow.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

 Partition. If figures are organized into three partitions, it is also called swimlanes,
indicating who/what is performing the activities (either the Applicant, Registrar,
or System).
 Sub-activity indicator. The rake in the bottom corner of an activity, such as in
the Apply to University activity, indicates that the activity is described by a more
finely detailed activity diagram.
 Flow final. The circle with the X through it. This indicates that the process
stopsat this point.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

GUIDELINES ASSOCIATED FOR DRAWING AN ACTIVITY DIAGRAM

[Link] Guidelines

[Link]

[Link] Points

[Link]

[Link] Activities

[Link] Guidelines

[Link]-Object Guidelines

Conclusion: The activity diagram was made successfully by following the steps
described above.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

EXPERIMENT 4

AIM: Identify the classes. Classify them as weak and strong classes and draw the class
diagram.

REQUIREMENTS:

Software Interfaces

 Any window-based operating system (Windows98/2000/XP/NT)

 IBM Star UML Software

THEORY:
A class diagram is a type of static structure diagram that describes the structure of a system by
showing the system's classes, their attributes, and the relationships between the classes.

Class diagrams show the classes n of operations and attributes of the classes. all at once, to:
 Explore domain concepts in the form of a domain model
 Analyze requirements in the form of a conceptual/analysis model
 Depict the detailed design of object-oriented or object-based software

A class model is comprised of one or more class diagrams and the supporting specifications
that describe model elements including classes, relationships between classes, and interfaces.
There are guidelines:

1. General issues
Because class diagrams are used for a variety of purposes – from understanding
requirements to describing your detailed design – it is needed to apply a different
style in each circumstance. This section describes style guidelines pertaining to
different types of class diagrams.

2. Classes
A class in the software system is represented by a box with the name of the class written
inside it. A compartment below the class name can show the class's attributes (i.e. its
properties). Each attribute is shown with at least its name, and optionally with its type,
initial value, and other properties

3. Interfaces
An interface is a collection of operation signature and/or attributes definitions that
ideally define a cohesive set of behaviors. Interface a class or component must
implement the operations and attributes defined by the interface. Any given class or
component may implement zero or more interfaces, and one or more classes or

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

components can implement the same interface.

4. Relationships
A relationship is a general term covering the specific types of logical connections
found in a class and object diagram.
Class diagrams also display relationships such as containment, inheritance,
associations and others.
The association relationship is the most common relationship in a class diagram.
The association shows the relationship between instances of classes.

Another common relationship in class diagrams is generalization. A generalization

is used when two classes are similar but have some differences.

5. Aggregation and Composition

Aggregation is a variant of the "has a" or association relationship; composition is

more specific than aggregation. Aggregation occurs when a class is a collection or
container of other classes, but where the contained classes do not have a strong
life cycle dependency on the container-- essentially, if the container is destroyed,
its contents are not.

TO DRAW CLASS DIAGRAM

When designing classes the attributes and operations it will have are observed. Then
determining how instances of the classes will interact with each other. These are the very
first steps of many in developing a class diagram. However, using just these basic
techniques one can develop a complete view of the software system. There are various
steps in the analysis and design of an object oriented system.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

EXPERIMENT 5
Aim: Draw the sequence diagram for any two scenarios.
Software Requirements:
Star UML, Windows XP

Theory:
UML sequence diagrams model the flow of logic within the system in a visual manner,
enabling the user both to document and validate the logic, and are commonly used for
both analysis and design purposes. Sequence diagrams are the most popular UML artifact
for dynamic modeling, which focuses on identifying the behavior within your system.
Sequence diagrams, along with class diagrams and physical data models are the most
important design-level models for modern application development.

Sequence diagrams are typically used to model:

1. Usage scenarios. A usage scenario is a description of a potential way the systemis

used. The logic of a usage scenario may be part of a use case, perhaps an alternate
course. It may also be one entire pass through a use case, such as the logic
described by the basic course of action or a portion of the basic course of action,
plus one or more alternate scenarios. The logic of a usage scenario may also be a
pass through the logic contained in several use cases. For example, a student
enrolls in university, and then immediately enrolls in three seminars.
2. The logic of methods. Sequence diagrams can be used to explore the logic of a
complex operation, function, or procedure. One way to think of sequence
diagrams, particularly highly detailed diagrams, is as visual object code.
3. The logic of services. A service is effectively a high-level method, often one that
can be invoked by a wide variety of clients. This includes web-services as well as
business transactions implemented by a variety of technologies such as
CICS/COBOL or CORBA-compliant object request brokers (ORBs).

To Draw Sequence Diagrams

Sequence diagramming really is visual coding, even when you are modeling a usage
scenario via a system-level sequence diagram.

While creating a sequence diagram, start by identifying the scope of what you are trying
to model. You should typically tackle small usage scenarios at the system level or a
single method/service at the detailed object level.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

You should then work through the logic with at least one more person, laying out
classifiers across the top as you need them. The heart of the diagram is in the messages,
which you add to the diagram one at a time as you work through the logic. You should
rarely indicate return values, instead you should give messages intelligent names which
often make it clear what is being returned.

It is interesting to note that as you sequence diagram you will identify new
responsibilities for classes and objects, and, sometimes, even new classes. The
implication is that you may want to update your class model appropriately, agile
modelers will follow the practice Create Several Models in Parallel, something that
CASE tools will do automatically. Remember, each message sent to a class invokes a
static method/operation on that class each message sent to an object invokes an operation
on that object.

Regarding style issues for sequence diagramming, prefer drawing messages going from
left-to-right and return values from right-to-left, although that doesn’t always work with
complex objects/classes. Justify the label on messages and return values, so they are
closest to the arrowhead. Also prefer to layer the sequence diagrams: from left-to-right.
indicate the actors, then the controller class(es), and then the user interface class(es), and,
finally, the business class(es). During design, you probably need to add system and
persistence classes, which you should usually put on the right-most side of sequence
diagrams. Laying your sequence diagrams in this manner often makes it easier to read
and also makes it easier to find layering logic problems, such as user interface classes
directly accessing persistence.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

EXPERIMENT 6

Aim:- Draw the collaboration diagram using Star UML.

Hardware Requirements:

Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard and mouse, colored
monitor.

Software Requirements:
Star UML, Windows XP

THEORY

Collaboration diagrams are also relatively easy to draw. They show the relationship
between objects and the order of messages passed between them. The objects are listed as
icons and arrows indicate the messages being passed between them. The numbers next to
the messages are called sequence numbers. As the name suggests, they show the
sequence of the messages as they are passed between the objects. There are many
acceptable sequence numbering schemes in UML. A simple 1, 2, 3... format can be used,
as the example below shows, or for more detailed and complex diagrams a 1, 1.1 ,1.2,
1.2.1... scheme can be used.

The example below shows a simple collaboration diagram for placing an order use case.
This time the names of the objects appear after the colon, such as :Order Entry Window
following the objectName:className naming convention. This time the class name is
shown to demonstrate that all of objects of that class will behave the same way.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

EXPERIMENT 7

AIM: To prepare state chart diagram for project.

REQUIREMENTS:

Software Interfaces
 Any window-based operating system (Windows98/2000/XP/NT)
 IBM Star UML Software

THEORY:
State Chart Diagrams provide a way to model the various states in which an object can exist.
There are two special states: the start state and the stop state.
The Start state is represented by a block dot.
The Stop state is represented by a bull’s eye.
A condition enclosed in square brackets is called a guard condition and controls when
transition can or cannot occur.
Process that occur while an object is in a certain state are called actions.
STEPS TO DRAW STATE CHART DIAGRAM IN STAR UML SOFTWARE
 To insert new state diagram secondary click on Logical View.
 Select---New----State chart Diagram.
 A new diagram will be created, type in a name for the new diagram.

 Now double click on the new diagram to open it on the stage. To begin the diagram click on

the “START STATE” button.

Place a start state icon on the diagram by clicking the mouse once.
Now add states to the diagram, these make up the content of the diagram.
Click on the state button. Place the instances for each state into the diagram and
type in names for them.
 Now arrange the states to fill the diagram better. Drag the states to new positions to make
the easiest layout to work with.
 Add an end state to the diagram by clicking the “END STATE” button. Place an instance
into the diagram. Now add relationships to the diagram.
 Click on the “STATE TRANSITION” button and drag arrows between the appropriate
states.
 To edit the specification secondary click on the relation lines and select
“OPENSPECIFICATION” button. Add a name for the event in the specification.
Then click on “apply” and then on “OK” button.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

 Add details to the specifications of the other relationships in the same way.
 There may be instances on the diagram where a state can join more than one state. In this
case add a relationship in the same way. Then enter the specification for the new state.

Conclusion: The state chart diagram was made successfully by following the steps
described above.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

EXPERIMENT 8

Aim:
Steps to draw the Component Diagram using Star UML.

Software Requirements:
Star UML, Windows XP

THEORY

A component is something required to execute a stereotype function. Examples of

stereotypes in components include executables, documents, database tables, files, and library
files. Components are wired together by using an assembly connector to connect the required
interface of one component with the provided interface of another component. This illustrates
the service consumer - service provider relationship between the two components. An
assembly connector is a "connector between two components that defines that one
component provides the services that another component requires. An assembly connector is
a connector that is defined from a required interface or port to a provided interface or port."
When using a component diagram to show the internal structure of a component, the
provided and required interfaces of the encompassing component can delegate to the
corresponding interfaces of the contained components.
Component is represented by a rectangle with either the keyword "component" or a
stereotype in the top right corner: a small rectangle with two even smaller rectangles jutting
out on the left.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

EXPERIMENT 9
Aim:
Steps to draw the Deployment Diagram using Star UML.

Software Requirements:
Star UML, Windows XP

THEORY

Deployment diagram visualizes the topological view of an entire system. It represents the
deployment of a system.A deployment diagram consists of nodes which describe the physical
devices used inside the system. On these nodes, artifacts are deployed. We can also have
node instances on which artifact instances are going to be implemented.

Node and artifacts of a system participate in the final execution of a system. A deployment
diagram plays a critical role during the administrative process, and it must satisfy the
following parameters:

 High performance
 Maintainability
 Scalability
 Portability
 Easily understandable

Nodes and artifacts are the essential elements of deployment. Before actually drawing the
deployment diagram, all nodes and the relationship between every node of the system must
be identified.

You must know the architecture of a system, whether an application is a web application,
cloud application, desktop application, or a mobile application. All these things are critical
and plays a vital role during the development of a deployment diagram.

If all the nodes, relations, and artifacts are known, then it becomes easy to
develop a deployment diagram.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

EXPERIMENT 10
AIM :- To draw a sample E-R diagram of project .

Software Requirements:
Star UML, Windows XP,

THEORY
Entity Relationship Diagrams are a major data modelling tool and will help organize the
data in your project into entities and define the relationships between the entities. This
process has proved to enable the analyst to produce a good database structure so that the
data can be stored and retrieved in a most efficient manner.

Entity
A data entity is anything real or abstract about which we want to store data. Entity types
fall into five classes: roles, events, locations, tangible things or concepts. E.g. employee,
payment, campus, book. Specific examples of an entity are called instances. E.g. the
employee John Jones, Mary Smith's payment, etc.

Relationship
A data relationship is a natural association that exists between one or more entities. E.g.
Employees process payments. Cardinality defines the number of occurrences of one
entity for a single occurrence of the related entity. E.g. an employee may process many
payments but might not process any payments depending on the nature of her job.

Attribute
A data attribute is a characteristic common to all or most instances of a particular entity.
Synonyms include property, data element, field. E.g. Name, address, Employee Number,
pay rate are all attributes of the entity employee. An attribute or combination of attributes
that uniquely identifies one and only one instance of an entity is called a primary key or
identifier. E.g. Employee Number is a primary key for Employee.

AN ENTITY RELATIONSHIP DIAGRAM METHODOLOGY:

Identify the roles, events, locations, tangible things or

1. Identify Entities concepts about which the end-users want to store data.
Find the natural associations between pairs of entities using
2. Find Relationships a relationship matrix.
Put entities in rectangles and relationships on line segments
3. Draw Rough ERD connecting the entities.
Determine the number of occurrences of one entity for a
4. Fill in Cardinality single occurrence of the related entity.

DEPARTMENT OF DATA SCIENCE BCS-651

PSIT-Pranveer Singh Institute of Technology
Kanpur-Delhi National Highway (NH-2), Bhauti, Kanpur-209305(U.P.), India

Identify the data attribute(s) that uniquely identify one and

5. Define Primary Keys only one occurrence of each entity.
Eliminate Many-to-Many relationships and include primary
6. Draw Key-Based ERD and foreign keys in each entity.
Name the information details (fields) which are essential to
7. Identify Attributes the system under development.
For each attribute, match it with exactly one entity that it
8. Map Attributes describes.
Draw fully attributed Adjust the ERD from step 6 to account for entities or
9. ERD relationships discovered in step 8.
Does the final Entity Relationship Diagram accurately
10. Check Results depict the system data?

Conclusion: The entity relationship diagram was made successfully by following the
steps described above.

DEPARTMENT OF DATA SCIENCE BCS-651