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 COMPUTER SCIENCE & ENGINEERING

Even Semester 2024-25

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 COMPUTER SCIENCE AND ENGINEERING 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 COMPUTER SCIENCE AND ENGINEERING 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 COMPUTER SCIENCE AND ENGINEERING 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 COMPUTER SCIENCE AND ENGINEERING 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 COMPUTER SCIENCE AND ENGINEERING 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 Level to be met
Taxonomy
to
b
e
m
et
L1: Remember 1 L2: Understand 2
L3: Apply 3 L4: Analyze 4
L5: Evaluate 5 L6: Create 6

CO Course Outcomes

B Define [1. Knowledge] the specification standard of IEEE for writing SRS.

B 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 Diagrams,
B
others to develop, implement, and demonstrate the learning through a project that
meet stated specifications.

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING 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

9 Draw the Deployment Diagram using Star UML CO3

10 To draw a sample E-R diagram of project CO3

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING 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 COMPUTER SCIENCE AND ENGINEERING 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 COMPUTER SCIENCE AND ENGINEERING BCS-651

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

A sample of basic SRS Outline

1. Introduction
1.1 Purpose
1.2 Document conventions
1.3 Intended audience
1.4 Additional information
1.5 Contact information/SRS team members
1.6 References

2. Overall Description
3. 2.1 Product perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Operating environment
2.5 User environment
2.6 Design/implementation constraints
2.7 Assumptions and dependencies

3. External Interface Requirements

3.1 User interfaces
3.2 Hardware interfaces
3.3 Software interfaces
3.4 Communication protocols and interfaces

4. System Features
5. 4.1 System feature
4.1.1 Description and priority
4.1.2 Action/result
4.1.3 Functional requirements
4.2 System feature B

5. Other Non-Functional Requirements

5.1 Performance requirements
5.2 Safety requirements
5.3 Security requirements
5.4 Software quality attributes
5.5 Project documentation
5.6 User documentation

6. Other Requirements
7. Appendix A: Terminology/Glossary/Definitions
list Appendix B: To be determined
Conclusion: The SRS was made successfully by following the steps described.

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING BCS-651

Contents
 1 .Introduction
1.1Purpose
This Software Requirements Specification (SRS) document outlines the requirements for the
development of a system for Automatic Craters and Boulder Detection Using AI/ML Techniques
(ACABD). The system aims to automatically detect and classify craters and boulders on planetary
surfaces using satellite or rover imagery, leveraging artificial intelligence and machine learning
technique.

1.2Scope
The ACABD system will process high-resolution planetary surface images to identify and classify
craters and boulders. It will utilize AI/ML models, specifically convolutional neural networks
(CNNs), to achieve high accuracy in detection. The system will provide:
• Automated detection of craters and boulders from input images.

• A user-friendly interface for uploading images and viewing results.

The system will not perform physical analysis of detected features (e.g., composition or age) or
control any hardware (e.g., rovers).

1.3Definitions, Acronyms, and Abbreviations

• ACABD: Automatic Craters and Boulder Detection.

• AI/ML: Artificial Intelligence/Machine Learning.

• CNN: Convolutional Neural Network.

• UI: User Interface.

• SRS: Software Requirements Specification.

• IEEE: Institute of Electrical and Electronics Engineers.

1.4References
• IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications.

• Planetary surface image datasets (e.g., NASAs Lunar Reconnaissance Orbiter).

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING BCS-651

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

1.5 Overview
This document is structured according to IEEE standards. Section 2 provides an overall description, Section 3
details specific requirements, and Section 4 includes appendices and supporting information.

[Link] Description
2.1 Product Perspective
The ACABD system is a standalone software application that integrates with existing planetary image databases
or user-uploaded images. It employs AI/ML models trained on labeled datasets of craters and boulders. The
system operates independently but can interface with visualization tools or mission control software via APIs.

2.2 Product Functions

• Image Input: Accept high-resolution images in formats such as TIFF, PNG, or JPEG.

• Preprocessing: Enhance images (e.g., noise reduction, contrast adjustment) for better detection.

• Detection: Identify craters and boulders using trained CNN models.

• Classification: Categorize detected features (e.g., crater diameter, boulder shape).

• Visualization: Display results with bounding boxes, labels, and confidence scores.

• Output: Generate reports summarizing detected features and export results in CSV or JSON format.

2.3 User Classes and Characteristics

• Planetary Scientists: Require accurate detection and detailed reports for geological analysis.

• Mission Planners: Use outputs to plan rover paths or landing sites.

• Developers: Maintain and update the system, requiring access to model training pipelines.

2.4 Operating Environment

The system will operate on:
• Desktop or server environments with Linux, Windows, or macOS.

• Minimum hardware: 16 GB RAM, 4-core CPU, GPU (optional for faster processing).

• Software dependencies: Python 3.8+, TensorFlow/PyTorch, OpenCV, Flask (for UI).

2.5 Design and Implementation Constraints

• The system must process images within 5 minutes on standard hardware.

• Models must achieve at least 90% accuracy on validation datasets.

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING BCS-651

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

• The system must comply with open-source licensing for dependencies.

2.6 Assumptions and Dependencies

• Availability of labeled datasets for training.

• Users have access to high-resolution planetary images.

• Stable internet for downloading dependencies during setup.

[Link] Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
• Web-based UI using Flask or Django.

• Features: Image upload, result visualization, report download.

• Responsive design for desktop and tablet displays.

3.1.2Hardware Interfaces
• No direct hardware control.

• Optional GPU support for accelerated model inference.

3.1.3Software Interfaces
• Image Processing: OpenCV for preprocessing.

• AI/ML Frameworks: TensorFlow or PyTorch for model training and inference.

• Output Formats: CSV, JSON for reports; PNG for visualized images.

• APIs: RESTful API for integration with external tools.

3.1.4Communications Interfaces
• HTTP/HTTPS for web-based UI and API communication.

• No real-time communication required.

3.2 Functional Requirements

3.2.1 Image Input
• The system shall accept images in TIFF, PNG, or JPEG formats.

• Maximum image size: 100 MB.

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING BCS-651

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

• Resolution: Minimum 1024x1024 pixels.

3.2.2 Preprocessing
• The system shall apply noise reduction and contrast enhancement.

• Processing time shall not exceed 30 seconds per image.

3.2.3Detection and Classification

• The system shall detect craters and boulders with 90% accuracy.

• Classification shall include crater diameter (small: ¡100m, medium: 100-500m, large: ¿500m) and boulder
type (angular, rounded).

• Detection time shall not exceed 4 minutes per image.

3.2.4 Visualization
• The system shall display bounding boxes around detected features.

• Labels shall include feature type and confidence score (0-1).

• Users shall be able to zoom and pan visualized images.

3.2.5 Output
• The system shall generate reports in CSV or JSON format.

• Reports shall include feature type, location (x, y coordinates), size, and confidence score.

• Visualized images shall be exportable as PNG.

3.3 Performance Requirements

• Total processing time per image shall not exceed 5 minutes.

• System uptime shall be 99.9% during operation.

• The system shall handle up to 10 concurrent users without performance degradation.

3.4 Design Constraints

• The system shall use open-source libraries for image processing and AI/ML.

• The UI shall comply with WCAG 2.1 accessibility standards.

3.5 Software System Attributes

3.5.1 Reliability
• The system shall achieve 90% detection accuracy on standard datasets.

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING BCS-651

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

• Mean time between failures: 1000 hours.

3.5.2 Availability

• The system shall be available 99.9% of the time during operational hours.

3.5.3 Security
• User-uploaded images shall be stored temporarily and deleted after processing.

• API endpoints shall use HTTPS and require authentication.

3.5.4 Maintainability
• The system shall allow model retraining with new datasets.

• Codebase shall follow PEP 8 standards for Python.

3.5.5 Portability
• The system shall run on Linux, Windows, and macOS.

• Dependencies shall be managed via [Link] or similar.

3.6 Other Requirements

• The system shall include documentation for installation, usage, and model training.

• Training datasets shall be cited in the documentation.

4.1 Glossary
• Crater: A circular depression on a planetary surface caused by impact.

• Boulder: A large rock fragment on a planetary surface.

4.2 Assumptions
• Users are familiar with basic image processing concepts.

• Input images are free from significant artifacts (e.g., sensor noise).

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING BCS-651

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

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING 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 COMPUTER SCIENCE AND ENGINEERING 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.

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
[Link] An Extending Use Case Below the Parent Use Case

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING BCS-651

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

[Link] the “Is Like” Rule to Use Case Generalization

[Link] an Inheriting Use Case Below the Base Use Case
[Link] the “Is Like” Rule to Actor Inheritance
[Link] 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 COMPUTER SCIENCE AND ENGINEERING BCS-651

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

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING 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 COMPUTER SCIENCE AND ENGINEERING 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 COMPUTER SCIENCE AND ENGINEERING 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

1. General Guidelines

2. Activities

3. Decision Points

4. Guards

5. Parallel Activities

6. Swimlane Guidelines

7. Action-Object Guidelines

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

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING BCS-651

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

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING BCS-651

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

Crater

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING 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 COMPUTER SCIENCE AND ENGINEERING 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 COMPUTER SCIENCE AND ENGINEERING BCS-651

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

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING 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 COMPUTER SCIENCE AND ENGINEERING 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 COMPUTER SCIENCE AND ENGINEERING BCS-651

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

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING 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 COMPUTER SCIENCE AND ENGINEERING BCS-651

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

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING BCS-651

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

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING 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 COMPUTER SCIENCE AND ENGINEERING 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 COMPUTER SCIENCE AND ENGINEERING BCS-651

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

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING 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.

Example

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING BCS-651

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

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING BCS-651

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

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING 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.

Example of a Deployment diagram

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

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING BCS-651

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

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING 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 COMPUTER SCIENCE AND ENGINEERING 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?

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING BCS-651

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

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

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING BCS-651