System Behavior

The purpose of this section is to provide a clearer picture of how the tracking system is to behave, and how its

components and sub-systems can be fit together to form an integrated, fully functional inventory tracking system.

To elaborate on the textual use cases presented in the Use Case Modeling Section, activity diagrams and statecharts

are presented in this section, as well as a class diagram. The activity diagrams and statecharts are used to model

system behavior. They show the various pathways, or flows of events, that can be traced through the system

behavior to satisfy both normal and alternate use case scenarios. Statechart diagrams are used to illustrate behavior

for more complex sequences of events that would otherwise be difficult to show in an activity diagram alone. The

class diagram gives an overall picture of the system components, or classes of components, and the interactions that

occur between them.

Activity Diagram – Track Movement Use Case

An analysis of the Track Movement activity diagram reveals the following:

The tracking system is heavily sequence dependent, which is not surprising. Just as UML is a meta-model,

or a model of a model, the material tracking system uses a sequence of events to track a sequence of events

(i.e., shipping, receiving, and storage activity). To move beyond the initial modeling stages, the activity

diagrams that are presented here would have to be decomposed into subsystem diagrams and possibly

statecharts to model more complex sequential behavior.

Although the system is automated, initial tag programming, and checking-in of materials shipments are

human activities that are prone to error. Future iterations of activities should include more scenarios that

trace through the effects of human interaction with the system. See Figure 3.

Figure 3: Activity Diagram for Track Movement Use Case

The functionality and behavior of the tag subsystem is critical. Many of the other system components can

potentially be off the shelf devices, such as the LogProc, GUI, RF Trans-ceiver, etc., but the tag will be a

custom design. The tags ability to retain and communi-cate data in all anticipated scenarios must be fully

understood in order to properly specify the tag’s performance characteristics. The tags behavior is best

described by a statechart diagram, which is presented below in Figure 4.

Figure 4: Statechart Diagram for Tag Behavior

Database Update is normally a synchronous activity (i.e., software timer initiates the tag status request

sequence at regular intervals). Although, a modified tag will send out its own request asynchronously to

alert the LogProc that its data has changed. Database Query is purely asynchronous because its activities

are initiated by the LogOfcr and can happen at any time, without a set interval. At the communications

level, the sequence of these synchronous and asynchronous events is being executed in millisecond and

micro-second intervals. Because one of the requirements placed on the system is to track materials in “near

real-time,” system activity at this level will have to be analyzed to insure that near real-time performance is

achievable. See Figure 5.

Message passing between a LogOfcr using the LogSoft and the WrhsOpr using the local GUI is an

important part of system functionality. However, in this project communication between networked

computers is considered to be an ancillary system function. Only computer functions that relate directly to

the use and manipulation of tag data are considered. Figure 6 illustrates this activity.

Figure 5: Activity Diagram for Update Database Use Case

Figure 6: Activity Diagram for Database Query Use Case

The class diagram illustrates the tracking system behavior at a very high level of abstraction. All the major

subsystems, or classes of objects, are included with the interface connections and primary interactions between

each class shown explicitly in Figure 7.

Figure 7: Class Diagram for Tracking System Behavior