1

Introduction to StarUML:

1. Unified Modelling Language (UML):

 UML is a standardized modelling language used to visualize, specify, construct, and
document software system artifacts.
 It provides a common platform for developers to communicate system design effectively.

2. Purpose of StarUML:
 To simplify complex system design through diagrams.
 To provide platform-independent models for software development.
 To support multiple UML diagram types such as:
o Structural diagrams: Class Diagram, Object Diagram, Component Diagram,
Deployment Diagram.
o Behavioural diagrams: Use Case Diagram, Sequence Diagram, Activity
Diagram, State chart Diagram, Communication Diagram.

3. Features of StarUML:
 Open-source and lightweight.
 Supports model-driven architecture (MDA).
 Allows easy diagram creation and editing.
 Provides export/import facilities for diagrams in different formats (e.g., PNG, PDF,
HTML).
 Supports plugins and extensions for enhanced functionality.

4. Advantages of Using StarUML:

 Improves understanding of system requirements.
 Encourages visual thinking in system design.
 Reduces errors in the development phase by clarifying system relationships.
 Provides reusability of design models for future projects.

5. Applications of StarUML in Practical Work:

 Drawing Use Case Diagrams to represent system functionalities and interactions with
users.
 Creating Class Diagrams for object-oriented analysis.
 Modelling Activity and Sequence Diagrams to show workflows and communication
between system objects.
 Designing Component and Deployment Diagrams for system implementation details.

MANAV SHARMA IT-1 03515003123

 2

Installation Guide for StarUML:

System Requirements:

 Operating System: Windows 7 or later, macOS 10.11+, or Linux (Ubuntu/Debian-

based).
 RAM: Minimum 2 GB (4 GB recommended).
 Disk Space: At least 200 MB of free space.
 Processor: Intel/AMD 1 GHz or faster.

Steps to Install StarUML:

1. Download the Installer

o Visit the official website: [Link]
o Choose the installer for your operating system (Windows, Linux, or macOS).
2. Run the Installer
o For Windows: Double-click the .exe file and follow the setup wizard.
o For macOS: Open the .dmg file and drag StarUML to Applications.
o For Linux: Use the .deb package and install using sudo dpkg -i [Link].
3. Accept License Agreement
o Read and accept the End User License Agreement (EULA) to continue
installation.
4. Select Installation Location
o Choose a folder where you want to install the software (default is recommended).
5. Complete Installation
o Click Install and wait for the setup to finish.
o Launch StarUML after installation.

Verification:

 After opening, you will see the StarUML workspace with options to create new projects
and diagrams.
 Free version is available with basic features, while advanced features require activation.

MANAV SHARMA IT-1 03515003123

 3

Steps to Create Diagrams in StarUML:

1. Starting a New Project

 Open StarUML.
 Go to File → New Project.
 Select Empty Project or a template.

2. Choosing a Diagram
 Right-click on the Model Explorer Panel (left side).
 Select Add Diagram.
 Choose the type of diagram (Use Case, Class, Sequence, Activity, etc.).

3. Using the Toolbox

 The Toolbox Panel contains elements for each diagram type.
o Example:
 Use Case Diagram → Actor, Use Case, System Boundary.
 Class Diagram → Class, Interface, Association, Inheritance.
 Sequence Diagram → Lifeline, Messages.
 Drag and drop required elements into the diagram workspace.

4. Connecting Elements
 Use relationship tools (association, generalization, dependency, etc.).
 Example: Connect an Actor to a Use Case using an association line.

5. Saving and Exporting

 Save project: File → Save (stored as .mdj file).
 Export diagram: File → Export Diagram → PNG/JPEG/PDF.

Example Workflow:
 Create a Use Case Diagram for a Library Management System.
o Add an Actor: “Student.”
o Add Use Cases: “Borrow Book,” “Return Book.”
o Connect Actor to Use Cases using associations.

MANAV SHARMA IT-1 03515003123

 4

EXPERIMENT-1
Aim: Write down the problem statement for a suggested system of relevance.

PROBLEM STATEMENT

Online food ordering system

Introduction:

Traditional food ordering methods rely heavily on phone calls or physical visits to restaurants.
These approaches are often slow, error-prone, and inconvenient for both customers and
restaurant staff. Managing menus, coordinating deliveries, and ensuring accurate billing also
become challenging when handled manually. To address these inefficiencies, an Online Food
Ordering System is proposed. This system aims to offer customers a secure and convenient way
to browse menus and place orders while enabling restaurants to manage orders, menus, and
deliveries with greater efficiency. Administrators will have oversight of the entire platform to
maintain smooth operations.

Existing Situation (Current System):

Most restaurants still depend on manual processes for taking and managing orders. This creates
several challenges:
• Time-consuming ordering through calls or in-person visits.
• Higher chances of order mistakes due to manual entry.
• Difficulty updating menus or communicating availability in real time.
• Inefficient delivery coordination and billing management.
While some digital tools exist, they may lack automation, multi-role access, or complete
integration of ordering, payments, and delivery updates.

Proposed System:

The proposed Online Food Ordering System addresses the limitations of the current process by
introducing a centralized and automated platform. The system will:
• Provide customers with online access to menus and a smooth ordering and payment process.
• Automate order processing, billing, and delivery coordination.
• Allow restaurant staff to manage menus, track and update order statuses, and handle deliveries.
• Enable administrators to oversee system operations and ensure accuracy across all modules.
This solution will reduce errors, save time, and deliver a more seamless experience for all users.

MANAV SHARMA IT-1 03515003123

 5

Mode of Operation:

1. Customer/User logs into the platform and browses available menus.

2. Customer places an order and completes payment through the system.
3. Restaurant staff receives the order in real time and begins processing.
4. Order status is updated by staff and visible to the customer.
5. Delivery personnel handle order dispatch and completion.
6. The system maintains records for admin monitoring, menu updates, and financial
tracking.

Advantages of the Proposed System:

• Faster and more convenient ordering for customers.

• Automated processing reduces manual errors.
• Real-time updates improve communication between customers and restaurants.
• Centralized management of menus, orders, and deliveries.
• Improved financial accuracy through automated billing.
• Scalable design suitable for multiple restaurants in the future.
• Enhanced operational efficiency for restaurants and administrators.

Conclusion:

The Online Food Ordering System offers an efficient solution to improve how restaurants
manage orders and how customers place them. With features like automated processing, real-
time updates, and secure online access, the system minimizes manual inefficiencies and boosts
reliability. This platform supports better restaurant operations, smoother customer experiences,
and long-term scalability for growing businesses.

MANAV SHARMA IT-1 03515003123

 6

EXPERIMENT-2
AIM: Do requirement analysis and develop Software Requirement Specification (SRS) Sheet
for the suggested system.

PURPOSE:

The purpose of this SRS is to define the requirements for an Online Food Ordering System. The
system will allow customers to browse menus, place orders, make payments, and track
deliveries. Restaurant staff will manage menu items, process orders, and monitor transactions.
The document describes functional and non-functional requirements clearly to ensure proper
understanding of the system’s workflow.

SCOPE:

The Subscription Analytics Dashboard is a web-based platform with the following features:

 For Customers:
• Create account and log in.
• Browse menu items and place orders.
• Apply promo codes and make secure payments.
• Track live order status and estimated delivery time.

 For Restaurant staff:

• Add, edit, or delete menu items.
• Confirm or reject orders based on item availability.
• View all transactions made in the system.

This system focuses on core food ordering operations and does not include advanced AI
recommendations, third-party delivery integrations, or subscription meal plans in its initial
version.

PRODUCT PERSPECTIVE:

• Independent online ordering platform for restaurants.

• Main interfaces:
• Customer Panel – for account creation, menu browsing, ordering, and tracking.
• Restaurant Staff Panel – for menu management, order processing, and updating statuses.
• Connects to database server that stores user information, orders, menus, payments, and delivery
data.

MANAV SHARMA IT-1 03515003123

 7

PRODUCT FEATURES:
• User account creation and login.
• Menu browsing with real-time availability.
• Order placement.
• Live tracking of delivery and order status.
• Restaurant staff functionalities for menu and order management.

FUNCTIONAL REQUIREMENTS:

Restaurant Staff Features

1. Menu Management
• Input: Item details.
• Output: Menu items added, edited, or deleted.
2. Order Approval
• Input: Incoming user order.
• Output: Accepted or rejected status based on availability.
3. View Transactions
• Input: None.
• Output: List of all transactions in the system.

Customer Features

1. User Account Creation

•Input: Customer details.
•Output: Account registered successfully.
2. Browse and Order
• Input: Selected menu items.
• Output: Order placed and payment processed.
3. Track Order
• Input: None.
• Output: Live order status and estimated delivery time.

NON-FUNCTIONAL REQUIREMENTS:
1. Usability
• Simple and intuitive interface for all users.
2. Security
• Encrypted transactions and secure login.
3. Performance
• Capable of handling multiple simultaneous orders without delay.
4. Scalability
• Ability to support multiple restaurants, users, and delivery agents.
5. Portability
• Works on both web and mobile platforms.

MANAV SHARMA IT-1 03515003123

 8

OTHER REQUIREMENTS:

 Backup & Recovery: Daily backup of menu, orders, and payment data.
 Audit Logging: Record staff actions and customer order activities.

ASSUMPTIONS AND DEPENDENCIES

 Users and staff have stable internet connectivity.

 The database is consistent, secure, and updated regularly.

MANAV SHARMA IT-1 03515003123

 9

EXPERIMENT-3
Aim: Create use case diagram for suggested problem statement.

AIM: To perform the user's view analysis for the suggested system: Use case diagram.

What is a Use Case Diagram?

A Use Case Diagram is a behavioral UML diagram that represents the interaction between
users (actors) and the system.
It visually describes what the system does (its functional requirements) without specifying how it
is done.

It helps in identifying:

 The external users (actors) of the system.

 The major functions or services (use cases) the system provides.
 The relationships between actors and those use cases.

Purpose of the Diagram:

The purpose of this Use Case Diagram is to model the functional behavior of the Online Food
Ordering System from both Customer and Staff perspectives. It helps in:

• Understanding the system’s functional scope.

• Showing how customers and staff interact with order-related and menu-related features.
• Providing a clear structure for future test cases and system feature design.

Actor:
Actor Description

The end-user who browses menu items, places orders, tracks order arrival, and views billing
Customer
status.

Restaurant personnel who manage orders, update order status, view transactions, and maintain
Staff
menu items and pricing

MANAV SHARMA IT-1 03515003123

 10

Use Cases:
No. Use Case Name Description

Allows customers and staff to register or securely log into the

1 Login or Signup
system.

2 Order Items Enables customers to browse menu items and place food orders.

3 Track Order Arrival Allows customers to track the delivery status of their placed orders.

Lets customers check the final bill amount, taxes, and payment
4 View Billing Status
status.

5 View Transactions Staff can view all orders and transaction details made in the system.

Confirm or Reject Customer

6 Staff can accept or decline customer orders based on availability.
Order

Staff updates the status of orders (e.g., preparing, out for delivery,
7 Update Order Status
delivered).

Staff can modify, add, or remove menu items and update their
8 Update Menu Items and Prices
pricing.

USE CASE DIAGRAM:

MANAV SHARMA IT-1 03515003123

 11

EXPERIMENT-4

AIM
To perform the behavioral view diagram for the suggested system: Sequence diagram,
Collaboration diagram.

SCENARIOS

Case 1: Customer places an order successfully

Login
 The customer enters login credentials into the frontend.
 The frontend sends these credentials to the Server for authentication.
 The Server validates the credentials by querying the Database.
 Once confirmed, the Server informs the frontend, and the customer sees a “Login
Successful” message.
Browse Menu
 The customer requests to browse the menu.
 The frontend forwards the request to the Server.
 The Server retrieves menu items from the Database.
 Menu items are sent back and displayed on the frontend for the customer.
Select Item & Place Order
 The customer selects one or more items and chooses to place an order.
 The frontend forwards this request to the Server.
 The Server creates a new order entry and saves it into the Database.
 After successful saving, the Server notifies the Restaurant about the new order.
Payment
 If the customer chooses Online Payment, payment details are sent from the frontend to
the Server.
 The Server communicates with the Payment Gateway to process the payment.
 Once payment succeeds, confirmation is made by the restaurant.
Order Confirmation
 The frontend confirms back to the customer that the order is successfully placed, showing
the unique Order ID.

MANAV SHARMA IT-1 03515003123

 12

Sequence Diagram: Case 1

Collaboration Diagram: Case 1

MANAV SHARMA IT-1 03515003123

 13

Case 2: Restaurant updates order status

Login
 The restaurant staff enters their login credentials into the Admin frontend.
 The frontend sends credentials to the server.
 The server verifies them via the Database.
 On success, the staff is logged in to the system.

View Orders
 The restaurant staff requests to view pending or active orders.
 The frontend forwards this request to the server.
 The server retrieves order details from the Database.
 The list of orders is displayed on the Admin frontend.

Update Order Status

 The restaurant staff selects an order and updates its status (e.g., Confirmed → Preparing
→ Out for Delivery → Delivered).
 The frontend sends the update request to the server.
 The server updates the order record in the Database.
 Once updated, confirmation is sent back to the Admin frontend.

Notify Customer
 The server also triggers a notification to the customer’s frontend.
 The customer sees real-time updates about the order progress (e.g., “Your food is out for
delivery”).

MANAV SHARMA IT-1 03515003123

 14

Sequence Diagram: Case 2

Collaboration Diagram: Case 2

MANAV SHARMA IT-1 03515003123

 15

EXPERIMENT – 5
AIM: To perform the function oriented diagram: Data Flow Diagram (DFD).

Theory:

A Data Flow Diagram (DFD) is a graphical representation used to visualize how data flows
through a system. It shows the processes that transform data, the data stores, and the external
entities that interact with the system. DFDs help in understanding the logical flow of
information, which is crucial during system analysis and design.

Key Components of a DFD:

1. Processes (Rounded rectangles):

o Represent operations that transform data.
o Labelled with verbs like "Retrieve menu", "Track order status", etc.
2. Data Stores (Open-ended rectangles):
o Represent places where data is stored (e.g., databases).
3. External Entities (Squares/rectangles):
o Represent actors or systems outside the system boundary (e.g., Customer).
4. Data Flows (Arrows):
o Represent the movement of data between processes, stores, and entities.

DFD 1 (High-Level Overview):

Description:

This is a Level 0 DFD (Context Diagram), giving a high-level view of the system.

Components:

 Customer (External Entity):

o Sends food order requests to the system.
o Receives order confirmations and status updates.
o Interacts with the system to browse menu and place orders.
 Food Ordering System (Process):
o Central process that handles all interactions between customers and restaurant
staff.
o Receives customer orders, validates them, and forwards them to staff.
o Sends order confirmations and delivery updates back to customers.
o Updates order status when staff makes changes.
 Restaurant Staff (External entity):
o Receives customer orders from the system.
o Updates order status (accepted, rejected, prepared, delivered).
o Sends status updates back to the system for customer tracking.

MANAV SHARMA IT-1 03515003123

 16

Flow Summary:

1. Customer places order (food items selected, order request sent).

2. Food Ordering System receives order and validates it.
3. System sends the order to Restaurant Staff for processing.
4. Restaurant Staff updates the order status (accepted, prepared, out for delivery, etc.).
5. System sends updated order status to Customer as confirmation or progress updates.

DFD 1 (High-Level Overview)

DFD 1 (Detailed Flow):

This is a Level 1 DFD, breaking the system into multiple detailed processes.

Major Components:

 Login:
o Validates credentials using D1: User Data (for customers) and D4: Staff Data (for
staff).
o Determines whether the user gains access to the ordering system or staff
management interface
 Retrieve Menu:
o Displays available menu items to the customer.
o Fetches item data from D2: Menu Items.

MANAV SHARMA IT-1 03515003123

 17

o Sends menu information back to the customer for browsing.

 Process order:
o Receives order details from the customer.
o Validates the order and stores it in D3: Order Data.
o Passes order information to “Handle Pending Orders” for staff processing.
 Handle pending orders:
o Retrieves unprocessed orders from D3: Order Data.
o Sends pending order information to Restaurant Staff.
o Receives updated order decisions (accepted/rejected/prepared).
 Manage menu items(staff):
o Staff can add, update, or remove menu items.
o Updates D2: Menu Items accordingly.
o Ensures menu changes reflect in the “Retrieve Menu” process.
 Track Order Status:
o Allows customers to check live order status.
o Retrieves updated status from D3: Order Data.
o Displays real-time order progress to customers.
 Restaurant staff:
o Logs in using D4: Staff Data.
o Views pending orders, updates their status, and manages menu items.
o Sends updated order statuses back to the system.

Data Stores:

 D1: User data – Stores customer credentials and basic profile information for login
validation.
 D2: Menu items – Stores menu items, prices, categories, and availability.
Updated by “Manage Menu Items,” and read by “Retrieve Menu.”
 D3: Order Data – Stores customer orders, order items, timestamps, and order status.
Used by “Process Order,” “Handle Pending Orders,” and “Track Order Status.”
 D3: Staff Data – Stores staff login credentials and role information.
Used by the Staff Login process.

Flow Summary:

1. Customer or Staff logs in → Credentials validated using D1 or D4.

2. Customer browses menu → Retrieve Menu fetches menu items from D2.
3. Customer places an order → Process Order stores order details in D3.
4. Pending orders are checked → Handle Pending Orders pulls data from D3.
5. Restaurant Staff updates order status → Changes reflected in D3.
6. Customer tracks order → Track Order Status fetches updates from D3.
7. Staff manages menu items → Manage Menu Items updates D2 (new, edited, or removed
items).

MANAV SHARMA IT-1 03515003123

 18

DFD 1 (Detailed Flow)

MANAV SHARMA IT-1 03515003123

 19

EXPERIMENT – 6
AIM: Draw the entity relationship diagram for the suggested system.

Theory:

1. Definition:

An Entity–Relationship Diagram (ERD) is a conceptual data model that visually represents the
entities, their attributes, and the relationships among them within a system.
It helps database designers structure data logically before creating the actual database tables.

2. Purpose:

The ER diagram is used to:

 Identify and organize system data requirements.

 Show how entities (like staff or menu items) are related.
 Serve as a blueprint for database design.
 Eliminate data redundancy and maintain integrity.

3. Components of an ER Diagram:

Component Description Example

Staff, Customer, Menu

Entity A real-world object or concept represented as a rectangle.
items

Characteristics or properties of entities (shown as ovals or in

Attributes email, password
a table list).

Primary Key
A unique attribute identifying each record in an entity. order_id, user_id
(PK)

Foreign Key
An attribute that links one entity to another. order_id in Order Items
(FK)

Association between two entities (shown as diamonds or

Relationship Staff manages menu
connecting lines).

1-to-many, many-to-
Cardinality Defines how many instances of one entity relate to another.
many

MANAV SHARMA IT-1 03515003123

 20

4. Types of Relationships:

 One-to-One (1:1): Each record in Entity A relates to one record in Entity B.

 One-to-Many (1:N): One record in Entity A can be linked to many in Entity B.
 Many-to-Many (M:N): Many records in A can relate to many in B (usually resolved via
a bridge table).

Description of ER Diagram – Food ordering system

It’s consists of five main entities:

Customer:

 Primary Key: customer_id

 Attributes: name, email, password, address, age
 Role: Represents users who browse menus, place food orders, and track delivery.
 Relationships:
o One Customer → Many Orders (places)

Staff:

 Primary Key: staff_id

 Attributes: name, email, password
 Role: Manages menu items and approves or rejects orders based on availability.
Relationships:
o Many Staff members → Many Menu items (manages)

Menu:

 Primary Key: order_id

 Foreign Key: customer_id
 Attributes: total_amount, order_status, order_date
 Role: Stores details of each food order placed by a customer..
 Relationships:
o One Order → Many OrderItems (contains)
o Many Orders ← One Customer (places)

OrderItem:

 Primary Key: order_item_id

 Foreign Key: order_id, item_id
 Attributes: quantity
 Role: Acts as a bridge table that stores which menu items belong to which order.
 Relationships:

MANAV SHARMA IT-1 03515003123

 21

o Many OrderItems belong to One Order

o Many OrderItems reference One Menu item

Order:

 Primary Key: order_id

 Foreign Key: customer_id
 Attributes: total_amount, status, order_address
 Role: Stores details of each food order placed by a customer.
 Relationship:
o One Order → Many OrderItems (contains)
o Many Orders ← One Customer (places)

Relationship Summary Table

Relationship Type Description

Customer – Order 1 : N One customer can place many orders

Staff – Menu M : N Many staff members manages many menu items

Order – OrderItem 1 : N One order contains many order items

Menu – OrderItem 1 : N One menu item can appear in many order items

Entity-Relationship Diagram

MANAV SHARMA IT-1 03515003123

 22

EXPERIMENT – 7
AIM: To draw the structural view diagram for the system: Class diagram, object diagram.

UML Class Diagram

What is a Class Diagram?

A Class Diagram is a structural diagram in UML (Unified Modeling Language) that provides a
static view of a software system. It acts as a blueprint, representing the types of objects in the
system and the various kinds of static relationships that exist between them. The Class Diagram
is fundamental to object-oriented analysis and design, showing the system's inherent structure
before it runs.

Components of Class Diagram

Class Diagram for the Food Ordering System is built from the following core components:

1. Classes

These are the fundamental building blocks (entities) of your system. Each class is represented by
a rectangle divided into three compartments: Name, Attributes, and Operations (Methods).

1. Customer: The external user who interacts with the food ordering platform to browse
items, place orders, and track their order status.
Attributes: customerID (PK), name, email, password, address.
Operations: login(),browseMenu(), placeOrder(), trackOrder().

2. Staff: Represents restaurant personnel who manage system operations such as reviewing
orders, updating order status, and maintaining menu items.
Attributes: staffID (PK), name, email, role, password.
Operations: login(), viewTransactions(), confirmOrder(), rejectOrder(),
updateOrderStatus(), updateMenuItems().

3. MenuItem: Stores information about food items available on the platform. It defines the
menu content customers can browse.
Attributes: itemID (PK), name, price.
Operations: addItem(), updateItem(), deleteItem().

4. Order: Contains details about each order placed by a customer, including the total
amount, order date, and current status.
Attributes: orderID (PK), customerID (FK), totalAmount, orderStatus.
Operations: calculateTotal(), updateStatus(), getOrderDetails().

MANAV SHARMA IT-1 03515003123

 23

5. OrderItem: Represents the individual menu items included in an order. It connects

MenuItem and Order as a bridge entity.
Attributes: orderItemID (PK), orderID (FK), itemID (FK), quantity, subTotal.
Operations: calculateSubTotal().

Class Diagram

2. Relationships (Associations and Multiplicity)

Relationships define how instances of the classes are logically connected.

Source Class Target Class

Relationship Association Type
(Multiplicity) (Multiplicity)

Customer–Order Customer (1) places Order (N) One-to-Many (1:N)

Order–OrderItem Order (1) contains OrderItem (N) One-to-Many (1:N)

OrderItem–
OrderItem (N) appears in MenuItem (1) Many-to-One (N:1)
MenuItem

Many-to-Many
Staff–MenuItem Staff (N) manages MenuItem (N)
(M:N)

Staff–Order Staff (1) updates Order (N) One-to-Many (1:N)

MANAV SHARMA IT-1 03515003123

 24

UML Object Diagram

What is an Object Diagram?

An Object Diagram is also a structural diagram that shows a snapshot of the system at a
specific point in time. Unlike the abstract Class Diagram, the Object Diagram displays real,
instantiated objects (instances of classes) with their current attribute values (state) and the links
(instances of associations) between them. It is used to model data structure examples and verify
the correctness of the class model.

Components of Object Diagram

Object Diagram for the Online Food Ordering System illustrates a scenario where one Customer
places one Order that contains one Menu Item through one OrderItem entry, while one Staff
member manages the menu items and updates the status of that same Order.

1. Objects (Instantiated Classes)

Objects are named instances of a class, with their name and class underlined
Object Notation Class Key State (Attribute Values)

customer id = 101, name = userA, email= userA@[Link],

c1: Customer Customer
address=XYZstreet, password=*****

s1: Staff Staff staff id = 201, name = staffA, email = s1@[Link],password=*****

Item1: menuItem menuItem item id = 67, name = Pizza, price =200

order id = 301, customer id = 101, total amound = 200, order

Order1: order order
status=preparing

orderItem1: Order item id = 9001, order id = 301, item id = 67, quantity = 1,

orderItem
orderItem subTotal = 200

MANAV SHARMA IT-1 03515003123

 25

Object Diagram

2. Links Between Objects (Instance Relationships)

 c1 → order1
(1 places order1)
 order1 → orderItem1
(order1 contains order item1)
 orderItem1 → item1
(orderItem1 refers to Pizza)
 s → item1
(staff1 manages menu item)
 s1 → order1
(s1 updates order1 status)

MANAV SHARMA IT-1 03515003123