Page | 1

SCHOOL OF ENGINEERING AND TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE AND IT

Name: MAZUBA HAMUCHENJE

SN: 202100240

Course: Software Engineering

Course Code: ICT 382

Course Work Number: 1

Lecturer: Dr Muwanei Sinyinda

Due date: 6th June, 2024

Mazuba Hamuchenje
 Contents
D1: An ERD describing your backend database. .................................................................................................... 2
E-R DIAGRAM ................................................................................................................................................. 2 Page | 2
ERD to Relational Schema Mapping ................................................................................................................. 3
Normalization ................................................................................................................................................... 4
D3: UML Use-case diagrams for the scenario, these should distinguish the various functions and users of the
system. .................................................................................................................................................................... 6
Description of Use Cases ...................................................................................................................................... 8
D4: UML Design Class diagram for the scenario. ................................................................................................ 14

Figure 1. Shows the E-R Diagram ............................................................................................................................................. 3

Figure 2. Car part Retail use case diagram................................................................................................................................. 8
Figure 3. UML class diagram for car part retail ....................................................................................................................... 15

D1: An ERD describing your backend database.

E-R DIAGRAM
1. Entities:
o Garage Outlet: Represents each local retail outlet.
o Part: Represents car parts.
o Customer: Represents customers who purchase parts.
o Order: Represents orders placed by local staff.
o Warehouse: Represents the central warehouse.
o Manager: Represents managers overseeing the system.
2. Attributes:
o Garage Outlet: ID, Name, Location
o Part: Part ID, Description, Stock Level, Price
o Customer: Customer ID, Name, Contact Details
o Order: Order ID, Date, Quantity
o Warehouse: Warehouse ID, Stock Level, Dispatch Schedule
o Manager: Manager ID, Name

Mazuba Hamuchenje
 3. Relationships:
o Garage Outlet has a one-to-many relationship with Part (each outlet sells multiple
parts).
o Garage Outlet has a one-to-many relationship with Customer (each outlet serves
multiple customers). Page | 3
o Garage Outlet has a one-to-many relationship with Order (each outlet places
multiple orders).
o Warehouse has a one-to-many relationship with Part (warehouse maintains stock for
all outlets).
o Manager oversees multiple Garage Outlets and the Warehouse.

Figure 1. Shows the E-R Diagram

ERD to Relational Schema Mapping

7 Steps for translating an ERD into a Relational Schema

1. Identify strong Entities and resolve them:

• Order (OrderID*, date, quantity)

• GarageOutlet (GarageOutletID*, name, location)
• Customer (CustomerID*, name, contact)
• Parts (PartID, description, stock level, price)
• Warehouse (Warehouse ID*, Stock Level, Dispatch Schedule)
• Manager (Manager ID*, name)
2. Identify weak entities and resolve them:

• No weak entities in the E-R diagram

Mazuba Hamuchenje
 3. Identify superclass/subclass hierarchy and resolve them:

• As there are no superclass/subclass hierarchy, in our sample model, we skip Step 3 at

this stage.
4. Identify 1:1 Relationships Types and resolve them:

• As there are no one to one relationship, in our sample model, we skip Step 4 at this Page | 4
stage.

5. Identify 1: N Relationships Types and resolve them:

• Order (OrderID*, date, quantity, GarageOutletID)

• Parts (PartID, description, stock level, price, GarageOutletID)
• Customer (CustomerID*, name, contact, GarageOutletID)
• Parts (PartID, description, stock level, price, GarageOutletID, Warehouse ID)
• Warehouse (Warehouse ID*, Stock Level, Dispatch Schedule, Manager ID)
• GarageOutlet (GarageOutletID*, name, location, Manager ID)
6. Identify M: N Relationships Types and resolve them:

• As there are no many to many relationships, in our sample model, we skip Step 4 at
this stage

7. Identify multivalued attributes and resolve them:

• Customer (CustomerID*, name, GarageOutletID)

• Customer_contact (CustomerID, contact)
• GarageOutlet (GarageOutletID*, name, location, Manager ID)
• GarageOutlet_Loc (GarageOutletID, location)

Final output
1. Manager (Manager ID*, name)
2. Order (OrderID*, date, quantity, GarageOutletID)
3. Parts (PartID*, description, stock level, price, GarageOutletID,
Warehouse ID)
4. Warehouse (Warehouse ID*, Stock Level, Dispatch Schedule,
Manager ID)
5. Customer (CustomerID*, name, GarageOutletID)
6. Customer_contact (CustomerID, contact)
7. GarageOutlet (GarageOutletID*, name, location, Manager ID)
8. GarageOutlet_Loc (GarageOutletID, location)

Normalization
1. Manager:
o Attributes: ManagerID (PK), Name
o No multivalued attributes.
o Already in 1NF.

Mazuba Hamuchenje
 2. Order:
o Attributes: OrderID (PK), Date, Quantity, GarageOutletID (FK)
o No multivalued attributes.
o Already in 1NF.
Page | 5
3. Parts:
o Attributes: PartID (PK), Description, Stock Level, Price, GarageOutletID (FK),
WarehouseID (FK)
o No multivalued attributes.
o Already in 1NF.
4. Warehouse:
o Attributes: WarehouseID (PK), Stock Level, Dispatch Schedule, ManagerID (FK)
o No multivalued attributes.
o Already in 1NF.
5. Customer:
o Attributes: CustomerID (PK), Name, GarageOutletID (FK)
o No multivalued attributes.
o Already in 1NF.
6. Customer_contact:
o Attributes: CustomerID (FK), Contact
o No multivalued attributes.
o Already in 1NF.
7. GarageOutlet:
o Attributes: GarageOutletID (PK), Name, Location, ManagerID (FK)
o No multivalued attributes.
o Already in 1NF.
8. GarageOutlet_Loc:
o Attributes: GarageOutletID (FK), Location
o No multivalued attributes.
o Already in 1NF.
Step 2: Second Normal Form (2NF)
1. Parts:
o Removed the partial dependency by splitting the table into two:
▪ PartDetails: PartID (PK), Description, Price

Mazuba Hamuchenje
 ▪ PartInventory: PartID (FK), Stock Level, GarageOutletID (FK),
WarehouseID (FK)
Step 3: Third Normal Form (3NF)
1. PartDetails:
o No transitive dependencies. Page | 6

o Already in 3NF.
2. PartInventory:
o Removed the transitive dependency by splitting the table into two:
▪ GaragePartInventory: GarageOutletID (FK), PartID (FK), Stock Level
▪ WarehousePartInventory: WarehouseID (FK), PartID (FK), Stock Level
The final normalized schema looks like this:
• Manager: ManagerID (PK), Name
• Order: OrderID (PK), Date, Quantity, GarageOutletID (FK)
• PartDetails: PartID (PK), Description, Price
• GaragePartInventory: GarageOutletID (FK), PartID (FK), Stock Level
• WarehousePartInventory: WarehouseID (FK), PartID (FK), Stock Level
• Warehouse: WarehouseID (PK), Stock Level, Dispatch Schedule, ManagerID (FK)
• Customer: CustomerID (PK), Name, GarageOutletID (FK)
• Customer_contact: CustomerID (FK), Contact
• GarageOutlet: GarageOutletID (PK), Name, Location, ManagerID (FK)
• GarageOutlet_Loc: GarageOutletID (FK), Location

D3: UML Use-case diagrams for the scenario, these should

distinguish the various functions and users of the system.

1. Actors:
o Local Staff: Represents staff working at local garage outlets.
o Warehouse Staff: Represents staff working at the central warehouse.
o Managers: Represents managers overseeing the entire system.
o Emergency Delivery System: Represents the automated emergency delivery system.

Mazuba Hamuchenje
 2. Use Cases:
o Sell Parts: Local staff can sell parts from local stock.
o Order Parts: Local staff can order parts from the warehouse or other garages.
o Record Customer Details: Local staff can record customer details and take
payments. Page | 7

o Automate Re-order Levels: The system automatically manages re-order levels.

o Emergency Query: Local staff can query a local garage for an item of stock
(emergency).
o Maintain Stock at Warehouse: Warehouse staff maintain stock levels.
o Set National Prices and Discounts: Warehouse staff set national prices, discounts,
and offers.
o Dispatch Stock: Warehouse staff dispatch stock to local garage outlets.
o View National Sales Summary: Managers can view a summary of national sales.
o View Local Sales Summary: Managers can view a summary of local sales.
o View National Stock Summary: Managers can view a summary of national stock.
o View Local Stock Summary: Managers can view a summary of local stock.
3. Relationships:
o Local staff interacts with all local use cases.
o Warehouse staff interacts with stock-related use cases.
o Managers interact with summary-related use cases.
o Emergency Delivery System interacts with the emergency query use case.

UML Use case Diagram

Mazuba Hamuchenje
 Page | 8

Figure 2. Car part Retail use case diagram

Description of Use Cases

1. Sell Parts:
o Name: Sell Parts
o Short Description: Local staff sell parts directly from their local stock to
customers.
o Precondition: Local staff have access to the system and are authorized to sell
parts.
o Postcondition: A successful sale transaction occurs, deducting the sold part
from local stock.
o Error Situations: Insufficient stock for the requested part.
o System State on Error: The part remains unsold, and the stock level remains
unchanged.
o Actors: Local staff
o Trigger: Local staff initiates a sale transaction.
o Standard Process:
1. Local staff logs in to the system.

Mazuba Hamuchenje
 2. Local staff selects the part to sell.
3. System confirms part availability.
4. Local staff processes the sale.
o Alternative Processes: Page | 9
▪ If the part is unavailable:
1. System proposes an alternative part.
2. Local staff selects an alternative part and confirms the sale.
2. Order Parts:
o Name: Order Parts
o Short Description: Local staff place orders for parts from the central
warehouse or other garages.
o Precondition: Local staff have access to the system and are authorized to
order parts.
o Postcondition: An order request is submitted to the warehouse or other
garages.
o Error Situations: Unavailable part or insufficient stock at the warehouse.
o System State on Error: The order remains pending.
o Actors: Local staff
o Trigger: Local staff initiates an order request.
o Standard Process:
0. Local staff logs in to the system.
1. Local staff selects the part to order.
2. System confirms part availability.
3. Local staff submits the order request.
o Alternative Processes:
▪ If the part is unavailable:
1. System proposes an alternative part.
2. Local staff selects an alternative part and submits the order.
3. Record Customer Details:
o Name: Record Customer Details
o Short Description: Local staff record customer information (e.g., contact
details, purchase history).

Mazuba Hamuchenje
 o Precondition: Local staff have access to the system.
o Postcondition: Customer details are stored in the system.
o Error Situations: Invalid or incomplete customer information.
o System State on Error: Customer details remain unchanged. Page | 10
o Actors: Local staff
o Trigger: Interaction with a customer.
o Standard Process:
0. Local staff logs in to the system.
1. Local staff enters customer details.
2. System validates and stores the information.
4. Automate Re-order Levels:
o Name: Automate Re-order Levels
o Short Description: The system monitors stock levels and triggers re-orders
when inventory falls below a threshold.
o Precondition: Inventory management system is active.
o Postcondition: Re-order requests are generated for low-stock items.
o Error Situations: None (system-driven process).
o Actors: System
o Trigger: Stock level reaches the re-order threshold.
o Standard Process:
0. System continuously monitors stock levels.
1. When stock falls below the threshold, the system generates a re-order
request.
5. Maintain Stock at Warehouse:
o Name: Maintain Stock at Warehouse
o Short Description: Warehouse staff are responsible for managing stock levels
within the central warehouse.
o Precondition: Warehouse staff have access to the system and are authorized
to manage stock.
o Postcondition: Stock levels are adjusted based on incoming shipments,
outgoing dispatches, and adjustments.
o Error Situations: Incorrect stock adjustments or discrepancies.

Mazuba Hamuchenje
 o System State on Error: Stock levels remain inconsistent.
o Actors: Warehouse staff
o Trigger: Incoming shipments or dispatch requests.
o Standard Process: Page | 11
1. Warehouse staff logs in to the system.
2. Warehouse staff receives incoming stock.
3. Warehouse staff updates stock levels.
4. Warehouse staff processes dispatch requests.
o Alternative Processes:
▪ If stock discrepancies are detected:
1. Warehouse staff investigates and corrects the stock records.
6. Set National Prices and Discounts:
o Name: Set National Prices and Discounts
o Short Description: Warehouse staff define pricing and discount structures for
parts at the national level.
o Precondition: Warehouse staff have access to the system and pricing
authority.
o Postcondition: National prices and discounts are updated.
o Error Situations: Incorrect pricing or discount values.
o System State on Error: Previous pricing remains unchanged.
o Actors: Warehouse staff
o Trigger: Regular pricing review or promotional events.
o Standard Process:
0. Warehouse staff logs in to the system.
1. Warehouse staff selects a part.
2. Warehouse staff sets the national price and applicable discounts.
3. System updates the pricing database.
7. Dispatch Stock:
o Name: Dispatch Stock
o Short Description: Warehouse staff fulfil orders by dispatching requested
parts to local garage outlets.

Mazuba Hamuchenje
 o Precondition: Dispatch requests are received from local garages.
o Postcondition: Parts are dispatched for delivery.
o Error Situations: Incorrect part selection or shipping errors.
o System State on Error: Dispatch remains pending. Page | 12
o Actors: Warehouse staff
o Trigger: Local garage places an order.
o Standard Process:
0. Warehouse staff receives the dispatch request.
1. Warehouse staff selects the requested parts.
2. Warehouse staff prepares the shipment.
3. Warehouse staff notifies the delivery team.
o Alternative Processes:
▪ If a part is unavailable:
1. Warehouse staff proposes an alternative part.
2. Local garage confirms the alternative or requests further
options.
8. View National Sales Summary:
o Name: View National Sales Summary
o Short Description: Managers access a summary of sales across all locations.
o Precondition: Managers have access to the system.
o Postcondition: Managers receive sales insights.
o Error Situations: None (informational use case).
o Actors: Managers
o Trigger: Regular reporting or decision-making.
o Standard Process:
0. Managers log in to the system.
1. Managers select the national sales summary report.
2. System presents aggregated sales data.
9. View Local Sales Summary:
o Name: View Local Sales Summary

Mazuba Hamuchenje
 o Short Description: Managers access sales data specific to individual local
garages.
o Precondition: Managers have access to the system.
o Postcondition: Managers receive localized sales insights.
Page | 13
o Error Situations: None (informational use case).
o Actors: Managers
o Trigger: Regular reporting or performance evaluation.
o Standard Process:
0. Managers log in to the system.
1. Managers select the local sales summary report.
2. System presents sales data for the chosen garage.
10. View National Stock Summary:
o Name: View National Stock Summary
o Short Description: Managers get an overview of stock levels across the entire
network.
o Precondition: Managers have access to the system.
o Postcondition: Managers receive stock insights.
o Error Situations: None (informational use case).
o Actors: Managers
o Trigger: Regular reporting or inventory planning.
o Standard Process:
0. Managers log in to the system.
1. Managers select the national stock summary report.
2. System presents aggregated stock data.

11. View Local Stock Summary:

o Name: View Local Stock Summary
o Short Description: Managers assess stock levels at individual local garages.
o Precondition: Managers have access to the system.
o Postcondition: Managers receive localized stock insights.
o Error Situations: None (informational use case).

Mazuba Hamuchenje
 o Actors: Managers
o Trigger: Regular reporting or inventory management.
o Standard Process:
1. Managers log in to the system. Page | 14
2. Managers select the local stock summary report.
3. System presents stock data specific to the chosen garage.

D4: UML Design Class diagram for the scenario.

1. Actors:
o Local Staff: Represents staff working at local garage outlets.
o Warehouse Staff: Represents staff working at the central warehouse.
o Managers: Represents managers overseeing the entire system.
o Emergency Delivery System: Represents the automated emergency delivery system.
2. Use Cases:
o Sell Parts: Local staff can sell parts from local stock.
o Order Parts: Local staff can order parts from the warehouse or other garages.
o Record Customer Details: Local staff can record customer details and take
payments.
o Automate Re-order Levels: The system automatically manages re-order levels.
o Emergency Query: Local staff can query a local garage for an item of stock
(emergency).
o Maintain Stock at Warehouse: Warehouse staff maintain stock levels.
o Set National Prices and Discounts: Warehouse staff set national prices, discounts,
and offers.
o Dispatch Stock: Warehouse staff dispatch stock to local garage outlets.
o View National Sales Summary: Managers can view a summary of national sales.
o View Local Sales Summary: Managers can view a summary of local sales.
o View National Stock Summary: Managers can view a summary of national stock.
o View Local Stock Summary: Managers can view a summary of local stock.

UML Class diagram

Mazuba Hamuchenje
 Page | 15

Figure 3. UML class diagram for car part retail

Mazuba Hamuchenje