UML Inventory Management

40

Implementation UNIT 3 CASE STUDY: INVENTORY

CONTROL SYSTEM

Structure Page Nos.

3.0 Introduction 40

3.1 Objectives 40

3.2 Class Diagram 40

3.3 Object Diagram 41

3.4 Generalization and Association Diagram 42

3.5 Collaboration Diagram 44

3.6 Activity Diagram and Events 44

3.7 Use Case Diagram 48

3.8 Deployment Diagram 49

3.9 Summary 51

3.0 INTRODUCTION

Inventory control systems are used for managing the stocks of companies and big distribution organisations. In this unit we will discuss about OOM for invention control systems. We will cover class diagram design, object diagram different kind of relationships, which include generalization, association and collaboration. We will also discuss use case diagrams activities and events.

3.1 OBJECTIVES

After going through this unit, you should be able to:

• explain class diagram and object diagram of Inventory control System; • describe generalization and Specialization of the system; • describe collaboration diagram of the system; • explain different activities and events of the systems, and • explain deployment Diagram.

3.2 CLASS DIAGRAM

You know that a class is represented in a box like figure. Here we are taking the case study of Inventory Control System.

Let us first set an idea of the Inventory Control System. It is the system in which you can manage the stock of the products that a company sells. Basically, this system is stock oriented where it makes sure that the quantity-in-stock does not reach the danger level (Qty-ordered>Qty-in-stock).

In any system when we reach this level, we place a new order. To avoid this situation, when in our system Qty-in-stock reaches a minimum level called the Reorder-level then a new order is placed. Here, in this case study, you will see various diagrams.

41

Case Study: Inventory Control System

CUSTOMER

Customer-id Cust-name Cust-address Cust-city Cust-state Cust-pincode Cust-contact-no ADD MODIFY DELETE VIEW

SUPPLIER

Supplier-id Supp-name Supp-address Supp-city Supp-state Supp-pincode Supp-status Supp-Contact No1 Supp-phone 2 ADD MODIFY DELETE VIEW

Figure 1: Class diagram represents the static structure of a System

You know that a class is represented in a box like Figure which can have at the most three regions.

• Class Name • List of Attributes • List of Operations/Methods

Class Methods

Attributes/properties

Class Name ORDER Order-id Description No. of items product-id order date NEW () EXISTING ()

SALE Receipt-no Sale-of- sale Qty-sold Detailed Item Sale () Daily Report Sale () Generate () View ()

INVOICE Invoice-no Invoice-date Customer-id Supplier-id Payment-status

Generate () View ()

PRODUCTS Product-id Name-of-product Category-id Description price Qty-in-stock Danger-level Last-modification-date Manufacturing-date

ADD MODIFY DELETE VIEW

Figure 2: Class diagram

3.3 OBJECT DIAGRAM

Object Diagram is an instance of a class. It describes the static structure of a system at a particular time and are used to test the accuracy of classes.

Implementation Generate

Report

Enter

Product Details

Prod. No

PRODUCT INVOICE Bills of

Material SUPPLIER Invoice No.

Order by

ORDER details

Order- no by Cust Code

EXISTING

Old

42

NEW New realise

CUSTOMER Name address

Places an order

Update

Identifies

details

Validation Order Order-no Cost-no Prod-no

Validate

Order

Order received

Updates Files

Update Stock

Qty-Stock

Dispatch Order Order Details

Figure 3: Object Diagram

3.4 GENERALIZATION AND ASSOCIATION DIAGRAM

Generalisation: This is another name for inheritance, or an “is a” relationship. It refers to a relationship between two classes where one class is a specialized version of another.


Sub Type 1

Regular Customer Customer

PRODUCT

New Product Existing Product

CUSTOMER Name: string

Credit ()

Figure 4: Generalisation of customer and product

Sub Type 2

Super Type

Association: This represents static relationship between classes. Roles represent the way the two classes see each other.

name

O DO

AggregaB, and itHollow D

Filled Di

Ternary

Class A

1n

m

n

RDER

ate-of order: date rder-no

n1 role

Figure 5: Association

tion: This denotes a strong ownes part.

iamond Simple Aggrega

amond Strong Aggregat

ORDER ORDER

INVOICE PRODUCT

Figure 6: Aggregati

Association for Customer Sup

PROD

CUSTOMER

Figure 7: Terna

Class B

43

n

m

SUPPLIER Supplier Details

CUSTOMER Customer details

role

of Order and customer

rship between class A, the whole, and class

tion

ion

SUPPLIER

CUSTOMER

on

plier

UCT

SUPPLIER

ry association

44

Implementation 3.5 COLLABORATION DIAGRAM This represents the interactions between objects as a series of sequenced messages. Collaboration diagrams describe both the static structure and the dynamic behaviour of a system.

Representation

Figure 8 a: Collaboration diagram for inventory control system

Object: Class

2.3 [Condition] Message

Actor

Object: Class

1. Message 2. Message 3. Message

1.2: [Condition] Message

Object: Class

Object: Class

SUPPLIER

3.0

Delivery new ()

: SUPPLIER

: STOCK

: PRODUCT

: ORDER

New product 1 [In order] 1.1

[In Stock]

Customer

1 places an order

2.0 [SUPPLIER]Invoice

Figure 8 b: Collaboration diagram for the inventory control system

3.6 ACTIVITY DIAGRAM AND EVENTS STATECHART DIAGRAM

This describes the dynamic behaviour of a system in response to external stimuli

• Basically, states are triggered by specific events.

Representation:

Final state

Initial state

State

event/action

Activity Diagram

This illustrates the dynamic nature of a system by modeling the flow of control from activity to activity, or you can say operation on some class that results in a change in the state of the system.

45

Case Study: Inventory Control System • Basically, this shows the workflow model, or business process and the internal

operation

: Class

Activity

Activity

: Class

Figure 9: Activity flow

Synchronization and Splitting of Control

• A short heavy bar with two transitions entering it represents a synchronization of Control.

• Splitting of Control that creates multiple states.

Splitting of Control Synchronization

Payment Made

Demand Occurred

Regular Delivery Overnight Delivery

Reverse Order

[else] [Rush order]

Place the Order Validate the Order

[Valid demand]

Check QTY-in-stock

Cancel Demand

[Valid]

Demand Occurred

Figure 10: Activity diagram

Events Actions taken in Inventory Control System:

1) Order is placed by the CUSTOMER 2) Order is received by the SUPPLIER 3) Checking of Quantity-in-Stock and Reorder-level 4) Checking of Inventory Status 5) Generating Bills of Material

46

Order

INVOICE

Implementation 6) Generating the INVOICE VOUCHER 7) Updating Inventory Status File

Main screen Do: display Customer/Supplier

Validation Do: Verify the Order

Do: Place the Order Select

Order

Order OK

Order Rejected

Sector the Order

Rejected Order Do: reject the

Min Qty >qty-in-stock Reorder Level

Do: check min. Qty-in-stock

Cancel Do: cancel the Order

Display Do: finish process

Do: Display Bad Message

Generation Do: Generate

Generate Do: Generate Bills of Material (BOM)

Update Do: Update Inventory Status File

Figure 11: State diagram

47

Control System Case Study: Inventory

<<uses>> Place an Order

Generate INVOICE

<<extends>> <<extends>> <<uses>> <<uses>> Invoice of the

item for Supplier

Update Inventory Status File

Invoice of an item for Customer

Generate Receipt

Receipt for Supplier

Receipt of an item for Customer

<<uses>>

Check Qty-in-stock

<<uses>> <<uses>>

Validate the order

Place an Order

Figure 12: Adding details

Data Flow Diagram for System

2.1 Reject the Order

Inventory File 5.0 Update Inventory Status

trans details

Transaction File

Validation Order

4.0

Generate Bills of Material

OK Qty-in-stock

Validated ROL 8.0

Generate Invoice Voucher

2.0

Valid ROL & Qty-in-stock

1.2 Check Reorder level

Order

Invalid

2.0 Display error Msg

Order Master File

Check

Order details

1.0 Validate the order

demand

Places CUSTOMER

1.0 Places an order

Figure 13: Data flow diagram

48

Implementation 3.7 USE CASE DIAGRAM

A “uses” relationship indicates that the use case is needed by another in order to perform a task • An “extends” relationship indicates alternative options under a certain use case. • Use case diagrams model the functionality of a system using actors and use

cases. • Use cases are services or functions provided by the system to its users.

Use Case

Use Case

(Actor)

Use Case

Figure 14: Use Case diagram For Inventory Control System the initial design is:

SUB DIAGRAM

INVENTORY CONTROL SYSTEM

Place an Order

Generate INVOICE


Generate BOM


Generate INVOICE

Generate BOM

<<uses>> <<uses>> <<uses>>

Actor (Customer)

Place an Order

Figure 15: Initial design of the Inventory Control system

49


USER INTERFACE

To View

Set Order Qty

Set Qty-in-stock

60 Sec without input

Setup

Set Program

Set Order Qty

Set Qty-in-stock

Run Program Interactive Display

Run Program

HOLD

Set upon Order

Select

Set supplier & Customer code

Run entries are set

Display Order Screen do: show order details

Display Supplier Screen Do: show supplier

button

enter Display Menu Screen do: show Customer

Operate

Power on Load Standard Program

Generating report mode

Press Report Button

Invoice Card Button

Press

Run Button

Generate Inventory Status Report

Generate Invoice Voucher

Generate Bills of Material entry Report

Figure 16: User interface

3.8 DEPLOYMENT DIAGRAM

Deployment diagram: This shows the hardware for your system, the software that is

installed on that hardware, and the middleware that is used to connect the machines to

one another.

50

Implementation • Deployment diagrams depicts the physical resources in a system including nodes, components and connections, where a node is a physical resource that executes code components.

Node

Component

Figure 17: Deployment

JDBC

<<JDBC>>

{order=order}

<<Device>> DB Server Inventory DB <<databases>>

Web Server INVENTORY CONTROL SYSTEM <<JSPs>>

<<Deployment Space.>> Placing of Order Execution: thread Nested Transaction: True <<EJBs>> Servlets

PRODUCTS

SUPPLIER

CUSTOMER

Inventory Control Series <<Web Services>>

M

<<Device>> :App” Server

Inventory gmt. jar

: EJB Container customes. ear supplier. ear product. ear order..xml <<deployment space>>

<<JDBC>> Inventory DB

<<JDBC>>

Web Server Inventory Control War

Figure 18: Deployment diagram

51

Case Study: Inventory Control System 3.9 SUMMARY

In this unit different diagram are design to represent OOM of inventory control system. These diagrams are:

• Class diagram

• Object diagram

• Generalization and association

• Collaboration diagram

• Activity diagram

• State diagram

• Dataflow diagram

• Use case diagram

• Use Interface and Deployment Diagram.

UML Inventory Management

Documents

Transcript of UML Inventory Management