Use Case Modeling

The primary function of the system is to track materials and provide materials data that can be used to

improve efficiency, reduce costs, and reduce errors in the process of shipping and storing materials. The primary

actors or end users of this system are the warehouse operator (WrhsOpr) and the logistics officer (LogOfcr). A

secondary actor would be the physical environment such as ambient conditions inside and outside a warehouse, or

obstructions that block the transmission of RF waves.

Goals and Scenarios

To generate use cases that accurately reflect the needs of the actors, a set of goals are identified that describe

the needs placed on the system by the actors. Within each goal there are different scenarios that are intended to

capture the various aspects of system structure and behavior that are needed to achieve that goal. As stated above,

the system must be capable of tracking materials and providing useful materials data in order to be effective. The

needs of the system are described in the following goals and scenarios:

Goal #1

The system should track materials by storing and passing data between devices in a predictable and

repeatable manner.

Scenarios

1.1 Tags should be programmable with a hand held, wireless device. At shipment, the tag is programmed

by a WrhsOpr with the necessary data.

1.2 Tags should be capable of receiving data requests and transmitting data to RF transceivers within a

warehouse environment where materials may be stored for long periods of time.

1.3 The LogProc should communicate with tags and store local tag data for materials stored in a particular

warehouse.

1.4 The LogProc should also be capable of input/output network communications with the LogDB, GUI,

and LogSoft.

Goal #2

The system should store useful data

Scenarios

2.1 The LogDB should contain logged departure and expected arrival date/time info for comparison with

actual checked-in date/time.

2.2 The system should account for lost and damaged shipments.

2.3 The LogDB should be updated at regular intervals. The LogProc should request tag data using a

synchronous time interval for scanning tags located within a particular warehouse.

2.4 Tag data that has been modified using an MtagPro should be sent asynchronously to the local

LogProc, and on to the LogDB.

2.5 The LogDB should differentiate between historical and current tag data to increase search efficiency.

Goal #3

The system should provide access to stored and real-time data

Scenarios

3.1 Using the LogSoft, a LogOfcr should be able to extract data from the LogDB for n tags in m

warehouses.

3.2 The LogSoft should have access to data of like kinds such as all tag shipped/received times and

dates, or all materials damaged in shipment, etc.

3.3 A database query of current tag data should generate an asynchronous data request to n LogProc

devices to update current tag data in the LogDB.

3.4 System should allow a WrhsOpr to use a GUI to interface with a LogProc for access to local tag

data and messaging that may be sent by a LogOfcr using the LogSoft.

System Boundaries

The material tracking system is composed of several elements or subsystems, some of which are physically

connected and others that are wireless. Additionally, the actors can interface with the system at several levels. For

instance, the LogOfcr uses the LogSoft to obtain data from the LogDB at a global level, whereas the WrhsOpr

interfaces with the system at two levels, through the LogProc/GUI at the local level, and through communication

with a Tag via the MtagPro at the remote level. Taking these points into consideration, the system boundaries are

laid out as follows:

1. System/User – The boundaries between the user and system are at the user interface objects, such as the

MtagPro and GUI.

2. System/Environment – At the preliminary stage the environmental boundaries are not apparent. Because

the system is partially wireless the environment acts as a boundary between the Tags and RF

Transceivers, making the system appear discontinuous. However, in the abstract sense the RF signal

between the Tag and RF Transceiver can be considered continuous, as if the two subsystems were

connected by an invisible cable.

3. System Controls – A primary function of the system is data manipulation, which suggests that the data

content should be controllable. This is the case, where everything from data in an individual tag, to

large blocks of data stored in the LogDB can be manipulated. However, the data values within the tags

and LogDB must be protected from being overwritten or incorrectly logged. Attributes that will be

fixed, once the system is designed, are the communications protocol, the file format, and to a large

extent the firmware that will run in the microcontroller devices such as the tags, MtagPro and RF

Transceivers.

Initial Textual Use Cases

The purpose of textual use cases is to convert the informal requirements contained in the goals and

scenarios into functional statements that describe the system’s behavior and possibly its structure. In this

project, the textual use cases are converted into activity diagrams which serve as initial graphic models of the

system behavior. Future iterations of the activity diagrams are used to show alternate flows of events, and to

identify the need for more detailed models such as Statechart Diagrams.

Three use cases are used below, to elicit the three goals listed above. The scenarios listed under each goal

can represent alternative flows of events within a respective use case. Alternatively, more than one scenario

may be described within a particular sequence of use case events.

UC1. Track Movement:

Actors: WrhsOpr, Physical Environment

Precondition: A fully functional tag is attached to shipment, and is ready to be programmed. Also,

desired “ship to” locations and shipment quantities are known prior to programming tags.

Alternate Behavior:

a. Material/tag shipped to wrong warehouse

b. Material/tag moved into receiving warehouse without being checked in

c. Partial shipment removed from tagged inventory, need to update tag data

UC1.1 WrhsOpr programs shipment of n tags using the MtagPro to enter material characterization data.

UC1.2 WrhsOpr downloads “to be shipped” tag data from MtagPro to LogProc at shipping warehouse.

LogProc compares desired tag data with “to be shipped” tag data. If data is correct shipment is sent

to destination.

UC1.3 At receiving warehouse, WrhsOpr checks in materials with an MtagPro.

UC1.4 WrhsOpr downloads “as received” tag data from MtagPro to LogProc at receiving warehouse.

UC1.5 Materials are moved into warehouse and stored.

UC1.6 Material inside warehouse is monitored by LogProc through RF transceivers that communicate with

Tags.

UC1.7 LogProc sends out tag status requests at regular time intervals.

UC1.8 Tags respond to status request by sending current tag data back to LogProc through RF Transceiver.

UC1.9 Tag status data is stored in LogProc local memory.

UC1.10 LogProc uses “as received,” historical, and current tag data at a particular warehouse location to

provide tracking and error detection information to the WrhsOpr.

UC2. Update Database:

Actors: Software Timer, Tag Signal

Precondition: Tag data has changed state.

Alternate Behavior:

a. Tag has low battery, unable to transmit data

b. Tag contents are being modified when tag data request is sent

UC2.1 Software timer inside LogProc times out, triggering a tag data request.

UC2.2 LogProc sends out tag data request through RF Transceivers into warehouse.

UC2.3 All tags in warehouse respond by sending current tag data back to LogProc.

UC2.4 LogProc compares current tag data with previous data to detect changes. If any tag data has changed,

it is sent to the LogDB for updating.

UC3. Database Query:

Actors: LogOfcr

Precondition: LogOfcr wants current data for n tags in m warehouses that is stored in the LogDB.

Alternate Behavior:

a. WrhsOpr wants to display local tag data on the GUI

b. LogOfcr wants historical and current data to create a trending log.

c. A LogProc goes offline

UC3.1 LogOfcr uses LogSoft to request current data from LogDB.

UC3.2 LogSoft checks to see when last database update was performed. If updated recently the current data

is obtained directly from the LogDB.

UC3.3 If LogDB has not been updated recently, an update request is sent out from the LogDB to m

LogProc’s to retrieve current tag data.

UC3.4 LogProc’s respond by updating the LogDB with current tag data.

Initial Use Case Diagram

Analysis of the above use cases shows that Track Movement is a concrete use case because a primary actor,

WrhsOpr, participates directly in its implementation. However, the Database Update and Query use cases appear to

be more abstract. Even though the LogOfcr interfaces with the system to generate a database query, he participates

very little in the actual querying process. The LogOfcr is involved at the beginning to initiate the query, and at the

end to use the data results generated by the query. Similarly, and to an even greater extent, the Database Update use

case can be initiated and carried out without any primary actor participation. The real interface with the Query and

Update use cases comes when the LogOfcr or WrhsOpr access the actual data that is produced. Therefore, the use

case diagram contains two concrete use cases Track Movement and Access Data. Database Update and Query are

abstract parts of the Access Data use case. Figure 2 illustrates the initial use case diagram.

Figure 2: Initial Use Case Diagram for Material Tracking System