SOFTWARE ENGINEERING LAB

PRACTICAL FILE
(BCS 651)

GL BAJAJ INSTITUTE OF TECHNOLOGY AND

MANAGEMENT, GREATER NOIDA

BACHELOR OF TECHNOLOGY
In
COMPUTER SCIENCE AND ENGINEERING

Session: 2024-2025

SUBMITTED BY: SUBMITTED TO:

Name: Saanvi Gupta Mr. Panchanan Pyare Singh

Section: E (Assistant Professor)
Semester: 6th
Roll No.: 2201920100250
Group: G1
 INDEX
S.
No. Name of Practicals Page Date of Date of Grades / Faculty
No. Practicals Submission Remarks Signature
1. Prepare an SRS document in
line with the IEEE
recommended standards.
2. 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.
3. Draw the activity diagram.

4. Identify the classes. Classify

them as weak and strong
classes and draw the class
diagram.
5. Draw the sequence diagram
for any two scenarios.
6. Draw the collaboration
diagram.
7. Draw the state chart
diagram.
8. Draw the component
diagram
9. Perform forward engineering
in java. (Model to code
conversion)
10. Perform reverse engineering
in java. (Code to Model
conversion)
11. Draw the deployment
diagram.
12. Draw the ER diagram.
 EXPERIMENT 1

AIM:
To develop a structured Software Requirements Specification (SRS) that defines the
functional and non-functional aspects of a software system, ensuring comprehensive
documentation for all stakeholders.

THEORY:
A Software Requirements Specification (SRS) document is a formal description of a software
system that outlines its objectives, functionalities, constraints, and expected performance. It
is a crucial part of software engineering, serving as a contract between stakeholders,
developers, and testers.
The purpose of an SRS is to provide a structured and clear understanding of what needs to be
developed, reducing ambiguity and ensuring that the final product aligns with business goals.
A well-documented SRS helps in risk mitigation, improves development efficiency, and acts
as a reference for future maintenance and updates.

A well-structured SRS enhances software quality by covering:

(i) Technical aspects (system architecture, design constraints)
(ii) Functional requirements (features, user interactions)
(iii) Business-related aspects (stakeholder needs, project goals)

Software Requirements Specification (SRS)

1. Introduction
This section provides an overview of the document, setting the foundation for understanding the
software requirements.

1.1 Purpose of the Document – Defines the objective of the SRS, detailing the need
for the software, expected functionalities, and how it aligns with business goals.

1.2 Formatting Guidelines – Specifies the structure, formatting styles, and

conventions used for consistency, making the document readable and standardized.

1.3 Intended Readers and Suggested Reading Approach – Identifies the target
audience (developers, testers, managers) and recommends how they should interpret
different sections.

1.4 Project Scope and Objectives – Summarizes the software’s purpose, key
functionalities, and how it benefits users, along with the problem it aims to solve.
 1.5 Reference Documents – Lists relevant standards, existing reports, regulatory
guidelines, and other documents that provide background information.

2. Overall Description
This section describes the broader context, end users, system constraints, and dependencies.
2.1 System Background and Perspective – Explains the motivation behind the
software, its historical background, and how it fits within the existing ecosystem.
2.2 Key Functionalities – Highlights the core features of the system, providing an
overview of what the software is designed to accomplish.
2.3 Characteristics of End Users – Defines the target users, their technical
proficiency, and how they will interact with the system.
2.4 System Limitations and Constraints – Specifies the boundaries of the system,
including hardware/software limitations, regulatory constraints, and operational
restrictions.
2.5 Assumptions and Dependencies – Lists external factors (third-party services,
frameworks, APIs) the system relies on and any preconditions assumed during
development.

3. Specific Requirements
This section provides detailed technical and functional specifications of the system.
3.1 Functional Needs – Defines specific software functionalities and how they behave
under different conditions.

3.1.1 Feature Name – Each feature is detailed with:

3.1.2 Description – A brief explanation of what the feature does.
3.1.3 Inputs – Data or actions required to activate the feature.
3.1.4 Outputs – Expected results from the feature execution.
3.1.5 Pre-conditions – Conditions that must be met before the feature is used.
3.1.6 Post-conditions – Expected state of the system after the feature has been
executed.

3.2 External Interface Requirements – Describes how the system interacts with
users , hardware, and other software
3.2.1 User Interfaces – Specifies UI design aspects such as layout, user
experience considerations, and accessibility features.
3.2.2 Hardware Interfaces – Details interactions with hardware components
like sensors, printers, or external devices.
3.2.3 Software Interfaces – Lists dependencies on other software, including
APIs, databases, and operating systems.

3.3 Performance Expectations – Defines response times, system throughput, load

capacity, and other performance metrics.
 3.4 Design Constraints – Covers limitations in technology choices, compliance with
specific architectures, and industry regulations.

3.5 Security Requirements – Specifies data protection mechanisms, authentication

protocols, encryption standards, and access control policies.

3.6 Additional Requirements – Captures any other essential requirements not

covered in the previous sections.

4. Appendices
Includes supplementary materials such as diagrams, tables, and supporting documentation
for additional clarification.

5. Glossary
Defines key terms, acronyms, and technical jargon to ensure clarity and consistency in
understanding.

6. Revision History
Maintains a record of document modifications for tracking changes and improvements over
time.
6.1 Version Details – Assigns version numbers to track different iterations of the
document.
6.2 Date of Change – Specifies when a particular version or modification was
introduced.
6.3 Author Information – Documents the names of contributors or teams responsible
for changes.
6.4 Modifications Summary – Provides a brief overview of what was updated in each
version.
 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.

THEORY:
A Use Case Diagram is a visual representation of the interactions between users (actors) and
a system. It is used in software engineering to capture functional requirements and show
how users interact with a system.
A Use Case Diagram primarily consists of three main components:

1. Actors: Represent external users or systems that interact with the system (e.g., Customers,
Admins).
2. Use Cases: Represent specific actions or functions the system performs (e.g., "Login",
"Make Payment").
3. Relationships:
i Association (solid line) shows interaction between actors and use cases. ii Include
(dashed arrow with <<include>>) means a use case is always called by another use case.
iii Extend (dashed arrow with <<extend>>) means a use case may optionally extend
another.
Description of the Use Case Diagram for website:-

1. System: E-Commerce System

a) The system boundary is represented by the rectangular box labelled "E-Commerce
System".
b) All actions (use cases) occur within this system.

2. Actors (Users interacting with the system)

a) Customer (Left-side actor)
I. Represents a user who wants to buy products.
II. Has access to multiple system functionalities.
b) Operator (Right-side actor)
I. Represents an administrative user who manages system operations. II.
Has limited interaction with specific use cases.

3. Use Cases (Functionalities of the system)

a) Browse Catalog
I. Actor Involved: Customer
II. Description: The customer can view the product catalog available on the
ecommerce platform.
III. Purpose: Helps customers explore available products before making a
purchase.
IV. Precondition: The customer must have access to the e-commerce platform
(either as a guest or logged-in user).
V. Postcondition: The customer views the available products and may decide
to proceed with purchasing.
VI. Function: Allows customers to explore the product catalog, including
product details, prices, and availability.

b) Register Customer
I. Actor Involved: Customer
II. Description: A customer can register to create an account in the system.
III. Purpose: Necessary for placing orders and tracking purchases.
IV. Precondition: The customer must have access to the e-commerce platform
(either as a guest or logged-in user).
V. Postcondition: The customer views the available products and may decide
to proceed with purchasing.
VI. Function: Allows customers to explore the product catalog, including
product details, prices, and availability.
 c) Order Goods
I. Actors Involved: Customer, Operator
II. Description: Customers can place an order for selected goods, and
operators may process these orders.
III. Purpose: Enables customers to buy products and operators to assist in
processing transactions.
IV. Precondition: The customer must be registered and logged in. Selected
products must be available in stock. Payment and delivery details must be
provided.
V. Postcondition: The order is successfully placed, and the system generates
an order confirmation. The operator (if involved) can process the order for
fulfilment.
VI. Function: Enables customers to purchase goods from the e-commerce
platform and allows operators to manage and process orders.

d) Change Password
I. Actors Involved: Customer, Operator
II. Description: Both customers and operators can change their passwords for
security purposes.
III. Purpose: Ensures account security by allowing users to update credentials
when needed.
IV. Precondition: The customer or operator must be logged into the system.
The current password must be provided or an account recovery process
must be initiated.
V. Postcondition: The password is updated, and the user must use the new
password for future logins.
VI. Function: Enhances account security by allowing users to reset or change
their passwords when necessary.

4. Relationships (Connections Between Actors & Use Cases)

a) Solid Lines indicate direct interaction between actors and use cases.
b) The Customer interacts with all four use cases.
c) The Operator interacts with Order Goods and Change Password only.
 EXPERIMENT 3

AIM:
Draw the activity diagram.

THEORY:
An activity diagram is a type of UML diagram that represents the flow of activities or processes
within a system. It visually describes the sequence of actions, decisions, and parallel operations
involved in a process. The diagram consists of several elements, including start and end nodes,
actions, decision points, and transitions that define the movement from one activity to another. It
can also include swim lanes to assign responsibilities to different actors. Activity diagrams are
useful for modelling business workflows, system functionalities, and step-by-step operations. They
help in understanding complex processes by breaking them down into manageable steps. Common
applications include e-commerce order processing, user authentication, and transaction workflows.

Key Elements of Activity Diagram:

1. Initial State: Represents the starting point of the activity diagram. It is depicted as a filled
black circle.
2. Activity/Action: Represents a specific task or step in the process. It is usually shown as a
rounded rectangle.
3. Control Flow (Arrows): Indicates the sequence of execution between activities,
represented by arrows.
4. Decision Node: Depicts a point where a decision is made, leading to different paths based
on conditions. It is shown as a diamond shape.
5. Merge Node: Combines multiple alternative flows into a single flow, also represented as a
diamond.
6. Fork Node: Splits a single flow into multiple parallel flows (concurrent execution),
represented as a thick horizontal or vertical bar.
7. Join Node: Merges multiple concurrent flows back into a single flow, also represented as
a thick bar.
8. Swimlanes: Used to group activities based on the responsible actor or system component,
dividing the diagram into sections.
9. Final State: Represents the end of the process.

Steps to Create an Activity Diagram:

1. Identify Initial and Final States – Define where the process begins and ends.
2. Identify Intermediate Activities – List key steps needed to complete the process.
3. Identify Conditions or Constraints – Determine factors influencing transitions.
4. Draw the Diagram with appropriate notations– Use appropriate symbols to visually
represent states, activities, and flow.
Example of Activity Diagram:

Online E Commerce Website web application project provides activity diagrams while in
development stage, this article explain about user and admin work flow features with diagrams.
The below attached User of the shopping cart system activity diagram explains about how login
activity of user and admin works, Here user enters user name and password in the login web form
and system validates the user details with the database, if the user details are equal to the database
details then it can accept the user login form and proceeding to the next level or else it can reject
the user login.
Process Flow:
1. Start – The process begins when the user enters their registration details.
2. Get the Details – The system retrieves the entered information.
3. Submit – The user submits the registration details for processing.
4. Validate Details – The system checks if the provided details are correct and complete.
5. Decision Point – The system determines if the validation is successful:
6. Accepted – The user is successfully registered.
a) If No → The registration is rejected, and the process ends.
b) If Yes → The registration is accepted and moves forward.
7. End – The process is completed.

Key Takeaways:
1. The diagram visually represents the registration workflow in a system.
2. It highlights decision-making points, showing both acceptance and rejection paths.
3. Ensures error handling, allowing users to correct incorrect details.
4. Clearly defines the sequence of actions, making it easy to understand.
5. Helps in system design and validation, ensuring smooth user registration.
 EXPERIMENT 4

AIM:

To identify the classes in the given system, classify them as weak and strong classes, and
draw the class diagram accordingly.

REQUIREMENTS:

1. Software Requirement: draw.io (for designing the class diagram)

2. Hardware Requirement: Operating System(MacOs Monetorey) with internet access

THEORY:

Object-Oriented Modelling is a fundamental aspect of software design, where real-world

entities are represented using classes and objects. A class diagram is a type of UML
(Unified Modelling Language) diagram that represents the static structure of a system,
showing the system’s classes, their attributes, methods, and relationships.
Classification of Classes:
Classes in a system can be classified as:

1. Strong Classes: These are the core functional classes that contain business logic and play a
significant role in the system. They have attributes and behaviours essential to the system’s
functionality. In the given class diagram, the strong classes are:

1.1 Person – A superclass with core attributes and methods.

1.2 Student – A subclass of Person, containing attributes and methods relevant to students.
1.3 Professor – Another subclass of Person, representing faculty members with specific
attributes and behaviours.

2. Weak Classes: These are support or utility classes that assist strong classes but do not have a
major role in implementing the business logic. In the given class diagram, the weak class is:

2.1 Address – A supporting class that holds address details.

Elements of a Class Diagram:

1. Classes: Represented as rectangles containing the class name, attributes, and methods.
2. Relationships:

2.1 Association: Shows a relationship between two classes.

2.2 Inheritance (Generalization): Denotes a parent-child relationship.
2.3 Aggregation & Composition: Defines whole-part relationships between classes.

3. Multiplicity: Specifies how many instances of a class relate to another.

Relationships in the Given Class Diagram:

1. Person and Address: A one-to-zero-or-one (0..1) association exists, meaning a person may
or may not have an address.
2. Person, Student, and Professor: The Person class is a generalization (parent class) of both
Student and Professor, meaning both inherit attributes and methods from Person.
3. Professor and Student: A professor supervises students, with a one-to-many (1..5 to 0..*)
relationship, meaning a professor can supervise between one to five students, while a student
can have multiple professors.
 EXPERIMENT 5

AIM:

To draw the sequence diagram for any two scenarios and explain the interactions between
objects in the system.

REQUIREMENTS:

1. Software Requirement: draw.io (for designing the class diagram)

2. Hardware Requirement: Operating System(MacOs Monetorey) with internet access

THEORY:

A sequence diagram is a type of UML (Unified Modelling Language) diagram that

represents the interaction between objects in a system over time. It shows the sequence of
messages exchanged among various objects to accomplish a specific task. Sequence
diagrams are particularly useful for understanding system behaviour and designing
interactions in objectoriented modelling.
 The given sequence diagram illustrates the process of searching for items in a system. The
two scenarios captured in the diagram are:

Scenario 1: Valid Search Request

1. The Customer initiates an itemSearch(itemName) request via the SearchForm.

2. The SearchForm validates the request by calling validSearch().
3. If the search term is valid:

3.1 The SearchForm proceeds to SearchItems(itemName).

3.2 The ItemDatabase retrieves the results through listResults().
3.3 The retrieved results are displayed to the customer via displayResults().

Scenario 2: Invalid Search Request

1. The Customer initiates an itemSearch(itemName) request.

2. The SearchForm validates the search (validSearch()).
3. If the search term is invalid, an error message is displayed using displayError().

Relationships in the Sequence Diagram:

1. Actor-Object Interaction: The Customer interacts with the SearchForm to initiate a search
request.
2. Object-Object Communication: The SearchForm communicates with SearchResults and
ItemDatabase to retrieve and display search results.
3. Control Flow with "alt": The alt (alternative) fragment divides the diagram into two paths:

3.1 A valid search path leading to item retrieval and display.

3.2 An invalid search path leading to an error message.

CONCLUSION:
In this experiment, a sequence diagram was created for two scenarios: a valid and an
invalid item search. The diagram effectively models the interactions between the system
components and captures the conditional logic within the system. The use of alternative
(alt) conditions ensures a clear representation of different execution paths.
 EXPERIMENT 6

AIM:

Draw the collaboration diagram.

REQUIREMENTS:

1. Software Requirement: draw.io (for designing the class diagram)

2. Hardware Requirement: Operating System(MacOs Monetorey) with internet access

THEORY:

A Collaboration Diagram (also known as a Communication Diagram in UML) is a structural

diagram that shows the interactions between objects or components in a system. These
diagrams emphasize the relationships and messages passed between objects, focusing on the
sequence of interactions and how they collaborate to achieve a specific task. Collaboration
diagrams are often used in object-oriented design to represent the dynamic behavior of a
system.

Key Concepts of a Collaboration Diagram:

1. Objects or Components:

These are instances of classes that interact with each other in the system. Each object is
represented by a rectangle with the object's name (or class name).

2. Links:

A link represents the relationship between two objects. It is typically shown as a line
connecting two objects.

3. Messages:

These are the interactions or communications that happen between the objects. The messages
are represented as arrows labeled with the action or method being called. They are numbered
to represent the order in which messages are sent.

4. Message Sequence:

The message sequence in a collaboration diagram is important because it defines the order in
which messages are passed. This sequence is represented by the numbering system of the
arrows (e.g., 1, 2, 3), which helps in understanding the flow of communication.
 5. Object IDs:

In a collaboration diagram, objects can be assigned unique identifiers to distinguish them,

which is especially important when there are multiple instances of the same class involved in
the interactions.

Steps to Create a Collaboration Diagram:

1. Identify the Scenario: Determine the specific use case or interaction.

2. Identify the Objects Involve: List objects that participate in the scenario.
3. Define Object Relationship: Establish how objects are connected or related.
4. List the Messages Exchanged: Define the interactions or method calls.
5. Number the Messages in Order: Sequence messages to show their execution flow.
6. Draw the Diagram Structure: Represent objects, links, and messages visually.
7. Refine and Finalize the Diagram: Ensure clarity, accuracy, and completeness in the diagram.

Example of Collaboration Diagram:

CONCLUSION:

A collaboration diagram involves identifying the scenario, defining the objects and their
relationships, listing and numbering the messages exchanged, and visually representing the
interactions. This process helps in understanding how objects collaborate in a system, making it a
useful tool for system analysis and design.
 EXPERIMENT 7

AIM:

Draw the state chart diagram.

REQUIREMENTS:

1. Software Requirement: draw.io (for designing the class diagram)

2. Hardware Requirement: Operating System(MacOs Monetorey) with internet access

THEORY:

UML primarily uses diagrams to represent systems. These diagrams can be broken down
into two types: behavioural UML diagrams, and structural UML diagrams.
UML is an extremely versatile and widely-recognised language. It is the standard language
used by many developers, as well as an increasing number of business professionals. Its
flexibility means that it can be applied to a number of IT or business-related situations, so
that you can make it applicable to the system or technology you are using.

Key Concepts of State Chart Diagram:

1. States: Represent conditions or situations of objects.

2. Transitions: Arrows showing movement between states.
3. Events: Actions that trigger state transitions.
4. Actions: Operations executed during states or transitions.
5. Initial State: Starting point of the state machine.
6. Final State: Represents the end of the process.
7. State Transitions: Movement between states triggered by events.
8. Entry/Exit Actions: Actions performed when entering/exiting states.
9. Nested States (Substates): States within other states for hierarchy.
10. Guard Conditions: Conditions that control state transitions.

Steps to create a State Chart Diagram:

1. Identify Key States and Events: Determine states and events for transitions.
2. Define Transitions Between States: Establish the flow between different states.
3. Specify Actions for Each State: Define actions performed during states or transitions.
4. Add Initial and Final States: Mark the starting and ending points.
5. Incorporate Guard Conditions (If Necessary): Define conditions controlling state
transitions.
Example of State Chart Diagram:

Conclusion:

State chart diagrams model an object's lifecycle, showing its states, events, transitions, and
actions. They help visualize how objects respond to different events and conditions, providing
a clear understanding of dynamic behaviors in a system.
 EXPERIMENT 8

AIM:

Draw the component diagram.

REQUIREMENTS:

1. Software Requirement: draw.io (for designing the class diagram)

2. Hardware Requirement: Operating System(MacOs Monetorey) with internet access

THEORY:

A Component Diagram in UML (Unified Modeling Language) is used to model the physical
components in a system and their interactions. It focuses on the high-level structure of a system,
representing the software components, the relationships between them, and their dependencies.
Component diagrams are useful for understanding how large systems are divided into smaller,
modular parts and how they interact.

Key Concepts of Component Diagram:

1. Components:

Components are modular, replaceable parts of a system, often representing physical or logical
entities (like software modules, libraries, or subsystems). They are typically represented as
rectangles with the component name and an optional provided/required interface.

2. Interfaces:

Interfaces define the points of interaction between components. A component exposes provided
interfaces (services it offers) and required interfaces (services it needs). These are shown as circles
(lollipops) for provided interfaces and semi-circles (sockets) for required interfaces.

3. Ports:

Ports are interaction points between components and external systems or other components. They
represent entry/exit points for communication.

4. Dependencies:

Dependencies between components show how one component relies on another. These are
represented by dashed arrows, indicating that one component needs the services or functionality
provided by another.
 5. Connector:

A connector is used to show communication between components or between a component and

its environment. These are usually depicted by lines connecting components or interfaces.

6. Reusability:

Components are designed to be reusable, meaning they can be swapped out or used in different
contexts without significant changes. Component diagrams help show how components can be
integrated into different systems.

Example of Component Diagram:

CONCLUSION:

Component diagrams are powerful tools for illustrating how different parts of a system interact,
focusing on the architecture and dependencies between components. They are essential for
understanding complex systems, promoting modularity, and ensuring efficient communication
between system parts.
 EXPERIMENT 9

AIM:
Perform forward engineering in java.

REQUIREMENTS:

Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard

keyboard n mouse, colored monitor.
Software Requirements: Java, Windows XP

THEORY:

Forward engineering involves translating a higher-level model or design into actual code. In
the context of Java, this typically means going from a design or model (such as a UML
class diagram) to Java code. I'll provide a simple example where we'll create a Java class
based on a hypothetical model.

Let's say we have a class diagram with a class named Person having attributes name and
age. Here's how you might forward engineer this into Java code:

1. Model (UML Class Diagram):

2.Forward Engineering to Java Code:

// Person.java

public

class

Person {

//

Attributes

private

String

name;

private int

age;

//

Constructor

s public

Person() {

// Default constructor
}

public Person(String

name, int age) {

this.name = name;

this.age = age;

// Getters and

Setters public
String getName()

{ return

name;

public void setName(String name)

{ this.name = name;

public int

getAge() {

return age;

public void setAge(int

age) { this.age = age;

// Other methods if needed

@Override

public String

toString() {

return

"Person{" +

"name='" + name + '\'' +

", age=" + age +
'}';
}
}
CONCLUSION:

This Java class corresponds to the Person class in our model. It has private attributes (name
and age), constructors, getters, setters, and a toString method for better representation.

This is a basic example, and in real-world scenarios, you might have more complex
relationships, methods, or other elements in your model that need to be translated to Java
code. The key is to understand the structure and behavior of your model and represent that
in Java classes and methods.
 EXPERIMENT 10
AIM:
Perform reverse engineering in java.

REQUIREMENTS:

Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard

keyboard n mouse, colored monitor.
Software Requirements: Java, Windows XP

THEORY:

Reverse engineering involves analyzing existing code to create a higher-level model or

design representation. In the context of Java, this typically means going from Java code to a
model, such as a UML class diagram. Here, I'll provide a simple example of reverse
engineering a Java class into a UML class diagram.

Let's say we have the following Java class:

//

Person.jav

a public

class

Person {

//

Attributes

private

String

name;

private int

age; //
Constructor

public

Person() {

// Default constructor

public Person(String name, int age)

{ this.name = name;

this.age = age;

// Getters and

Setters public

String getName()

{ return

name;

public void setName(String name)

{ this.name = name;

public int

getAge() {

return age;
 }

public void setAge(int

age) { this.age = age;

// Other methods

public void

celebrateBirthday() {

age++;

System.out.println("Ha

ppy Birthday, " + name

+ "! You are now " +

age + " years old.");

@Override

public String

toString() {

return

"Person{" +

"name='" + name + '\'' +

 ", age=" + age +

'}';

Now, let's represent this Java class in a simplified UML class diagram:

+---------------------+

| Person |

+---------------------+

| - name: String |

| - age: int |

+---------------------+

| + Person() |

| + Person(name: String, age: int) |

| + getName(): String |

| + setName(name: String): void |

| + getAge(): int |

| + setAge(age: int): void |

| + celebrateBirthday(): void |

| + toString(): String|

+---------------------+
CONCLUSION:

In this UML class diagram:

● Attributes are represented as fields within the class.

● Constructors are listed with their parameter names and types.
● Methods are listed with their names, return types (if applicable), and parameter names
and types.

Note that this is a simplified example. In a real-world scenario, you might have more
complex relationships, associations, and other UML elements. Reverse engineering tools
and techniques can assist in automatically generating UML diagrams from existing
codebases, providing a visual representation of the software architecture.
 EXPERIMENT 11
AIM:
Draw the deployment diagram.

REQUIREMENTS:
Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard
keyboard n mouse, colored monitor.
Software Requirements: Java, Windows XP

THEORY:

UML Deployment Diagram describes the software system's specifications and the physical
hardware system required to run the software. The Deployment Diagram also determines
the installation of the software on the hardware. UML Deployment Diagram maps software
segments of a method to the device that is going to implement it.

Deployment Diagram Symbols

Example of Deployment Diagram:

CONCLUSION:

A Deployment Diagram provides a high-level view of the physical architecture of a system,

focusing on how software components are deployed across hardware nodes. It helps visualize the
distribution of components, servers, and devices, clarifying how system elements interact in a real-
world environment. Deployment diagrams are essential for understanding system performance,
scalability, and network configuration, making them a valuable tool for system administrators and
architects when planning and optimizing system deployment.
 EXPERIMENT 12
AIM:

Draw the Er -modelling diagram.

REQUIREMENTS:

Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard

keyboard n mouse, colored monitor.
Software Requirements: Java,windows xp

THEORY

ERD stands for Entity Relationship Diagram. It is a type of visual model that describes
different elements in a specific domain. ER diagrams are widely used in software
engineering and database management. People use them to study the links between separate
entities to create an organized and robust database. ER diagrams look like flow charts to
some extent. To draw an ER diagram, you need to identify all the entities, know the
relationships between all the entities, and add attributes for each entity.
There are many to create an ER diagram online using different diagrammatic tools. One
such tool to create an ER diagram online is Drawio Online. Drawio is an online graphic
creator that can be used to create different types of charts, graphs, and diagrams in just a
few simple steps. To learn how to make an Entity Relationship diagram in the process of a
few steps, please check out our ER diagram tutorial below.

OUTPUT: