Diagrams

In this blog I will be explaining the UML diagrams created with changes made and why.

Use case diagram

This is the first attempt of the use case diagram that I have created. The login ellipse was missing from this diagram. Keeping the diagram the way shows the system has no security measures in place to protect data being edited or delete.

The other part that was missing was the use case description, goal and the step to make a successful order. Without this the user is unable to understand this diagram.

First attempt by myself

Final attempt

This is now the final attempt of the use case including all the parts. It includes the goal, use case description, steps and the use case diagram.

Entity Relationship diagram First attempt

This diagram was missing the fan trap from suppliers to orders.

Entity relationship diagram (Group Attempt)

Final Attempt

usecase

I decided to amend the diagram; I added a relationship between supplier and order. This is because there is a fan trap between them two entities. The fan trap occurs when one to many join links a table which in turn is linked by another one to many join. To solve the fan trap we have added a foreign key from the supplier table to the orders table. The reason this was created is because when calculating multiple orders, it would output duplicate data. If this fan trap wasn’t created it would output the incorrect result because we will be performing an aggregate function on the tables.

Table Schema first attempt

This is the first attempt at the table schema. The expected and delivery date was missing from the order. These two fields will enable the group to output late and on time orders. Without these two fields we wouldn’t know when an order has arrived. On the other hand the order items had way too many fields so these were split up and added to other tables. Also some tables was missing because they wasn’t created.

Final attempt

This the the final version of the table schema. It now has all the tables not like before with just two tables.

Activity Diagram

This is the activity diagram that was created for ordering low stock. However the title is missing from this and also the final state was missing.

Final Attempt

A suitable title and final states have been added. Without the final state it shows the diagram will never end. Without the title the user won’t understand what the diagram is for.

Checking Reports

usecase

This is the activity diagram for checking report for William. This is a very simple diagram because Williams’s requirement in this diagram is to view reports of late orders. It has a decision symbol, this checks if the delivery has been made on time or late.

Receiving orders for Warehouse Operative

This diagram shows the process for the warehouse operative updating the system once and order has arrived. It has a decision symbol if there are any deliveries being received or not. If there is there is another decision symbol to see if the delivery has arrived on time or late. Once that has been done the system is updated on the database.

Authorising orders

usecase