CS302: Software Engineering

Rules for Drawing a Time-Event Diagram 

A time-event diagram graphically depicts the timing constraints and events that trigger related objects, showing sequences of processing, concurrent processes, and nesting of processes across objects. Time-ordered event diagrams show neither flow of control nor if-then-else logic. These diagrams are showing what can happen in time, including required timing. The time-order event diagram becomes the basis for decisions about concurrent processes and is helpful in identifying service-object needs of the application. 

The diagram is a two-dimensional graphic with objects listed down the left axis and time, broken into segments corresponding to events in the application, along the horizontal axis. For processes that might run concurrently, multiple lists of the objects are shown. Synchronization of concurrent events is shown by the divergent lines returning to one event at some point (see Figure 12-9).

Two formats for time-event diagrams are used. One shows deviations from an otherwise horizontal line with events and critical times demarcated by vertical bars (see Figure 12-10). The other format shows rising steps to mark events and critical time slots within the main object (see Figure 12-11). If one diagram per transaction is created, the rising step method is preferred because it is easy to see the points of change. If one diagram per application is drawn, the information can be presented more compactly with the horizontal line method.

FIGURE 12-9 Potentially Concurrent Processes

TABLE 12-3 Process Subdomain Assignments

Diagram segments are defined as event-driven or clock-driven. For time-constrained segments of the diagram, the allowable maximum time is labeled along the horizontal axis (see Figure 12-12). For event-driven segments, the event is identified on the horizontal axis. Actual drawing requires knowledge of the problem domain requirements for processing. The steps to creating a time-event diagram are:

1. Define all allowable transactions in the application. 

2. Define the processing steps for each transaction. 

3. For each transaction, design a time-event diagram reflecting the dependence or independence of processing steps.

FIGURE 12-10 Horizontal Time-Event Diagram

ABC Video Example of a Time-Order Event Diagram 

For ABC, Table 12-4 shows the transactions allowed in the application. The transactions should have no surprises by this stage of design, and should be closely related to the processes defined for each object. Some objects, such as TempTrans, have processes that relate to more than one transaction, while other objects each have processes that reflect one transaction, such as for Customer.

FIGURE 12-11 Rising Step Time-Event Diagram

FIGURE 12-12 Diagram Segments Identified as Time-Driven or Event-Driven

Of the transactions shown, we will discuss two that are representative of the others: video inventory additions and rental processing. 

First, we describe what happens for a Video Inventory addition. This step requires detailed knowledge of the specific processing to be performed. This knowledge comes from user interviews, study of current procedures, and so on. Subprocess details should be based on the processobject assignment list (Figure 11-20). If there are discrepancies between the use of objects here and the list, the list should be revised to reflect this more detailed level of thought. The steps to adding inventory are:

1. Enter a new VideoId and remaining infonnation for a particular film.

2. When the NumberOfCopies is entered, add the new video infonnation to Videolnventory. Begin prompting for BarCodeld until the number of bar codes is equal to NumberOfCopies. 

3. As each BarCodeId is entered, add the new BarCodeVideo entry to the database. 

4. When the number of BarCodelds entered is equal to NumberOfCopies, signal completion of the transaction to the clerk and end processing.

Figure 12-13 shows the time-event diagram for the processing steps about video inventory creation. Notice that two objects are involved: Videolnventory and BarCodeVideo. Even though Videolnventory is begun first, its processing is completed before BarCodeVideo processing takes place. The processes are related in that the Videold is passed to the BarCodeVideo process, but they are otherwise independent. There is no necessary concurrency within the transaction.

TABLE 12-4 ABC Transaction List

The rental transaction shows that several processes might be concurrent. First the steps to completion of a rental process are: 

1. Get the entry and determine its type (either CustomerPhone or VideoId). 

2. If the entry is CustomerId, get all relevant customer information (e.g., name, address, and so on). 

3. If the entry is VideoId, get the corresponding VideoOnRental and place it in memory. 

The first event, data entry, results in one of two possible processes being invoked. These are shown with dotted lines on the diagram to show that only one is running at a time. If the VideoId is entered, then we have a choice to either nest getting the customer or transfer control. If we transfer control, the video information must have been stored in memory for the first VideoOnRental to avoid passing unnecessary data. If we do not transfer control, and nest retrieval of customer information, then the customer information is unnecessarily passed through the retrieval process for VideoOnRental. The best object-oriented decision would be transfer control to maximize information hiding here, but we can treat these accesses as one if the DBMS supports a user view that links the relevant information. SQL DBMS does provide user views and we select that option. (Make sure you read the appendix for true object-oriented design of this information. It is significantly different.) Once VideoOnRental is accessed, then, the related information from VideoInventory, BarCodeVideo, and Customer are all present automatically (see Figure 12-14).

Eventually, we loop through getting all current outstanding rentals from VideoOnRental. This iteration can be programmed to run until a return code indicating no more videos on rental are present. This return code, then, becomes the event to trigger the next step of the process.

FIGURE 12-13 Time-Event Diagram for Inventory Creation Transaction

Control is passed to compute Late Fees on returned tapes that will require a count of the number of VideoOnRentals in memory to be maintained and passed to control this process. Having processed late fees until this count is reached triggers the next step to compute TotalAmountDue. This is a one-time event at this point, and its completion leads to display of all current customer and rental information on the user screen. 

At this point, if there are new rentals, the BarCodelds are entered. This triggers obtaining BarCodelnventory and Videolnventory information. To simplify memory processing, we have a choice similar to that above for customer and VideoOnRental in step 3. In this case, the decision is between treating BarCodeVideo and Videolnventory as separate and independent or nested or the same. In order to treat them the same, we must be accessing a user view that contains the relevant information. Again, SQL allows user views, and we use the user view that collapses this activity from two to one. As each video's information is displayed, the TotalAmountDue is recomputed and redisplayed. 

Upon receiving the trigger that the rentals, or returns, are complete, payment processing takes place and continues until TotalAmountDue equals zero. At that time, all of the VideoOnRentals, BarCodeVideo locations, and video history counts (for returns) are updated. These are once again assumed to be in the same object as a result of having user view capabilities in SQL.