3.10 Real-time extensions

Applets running in browsers and many real-time applications bring issues of concurrency to the fore. This kind of program can (or can appear to) do several things at once. A thread represents a concurrent sequence of steps and there may be many of these that can start, stop and signal to each other. A simple and familiar example is a GIF image being downloaded to a browser while the user continues to be able to click on hyperlinks. Threads are a key part of the Java object model. Buhr and Casselman (1996) describe Ray Buhr's important and powerful technique of time threads. Time threads (re-badged - we think rather opportunistically - in the cited book as 'use case maps') enable designers to visualize the way a system transfers control amongst its components. In this sense a thread is rather like the internalization of a use case. However, these authors routinely confuse use cases with scenarios and most examples that they give deal with using time threads to model scenarios rather than, more generically, use cases. A time thread map shows the components of a system (which could be machines or people) and one or more wiggly lines that pass through the components and which are annotated with (possibly shared) responsibilities. Components can be objects or pure processes. Time threads can branch and join. They can be synchronized according to a number of protocols. In fact, one can make an exhaustive list of the different patterns of inter-process coupling that can occur. Threads can access 'pools' of information and populate object 'slots' dynamically.

Figure 37 Time threads.

A number of commonly recurring design patterns can be presented using time thread diagrams. These vary from abstract and general patterns like producer/consumer, through those specific to GUI design such as MVC to quite specific real-time ones such as dynamic buffering. The notation is fairly complex and we can't help feeling that we wouldn't use it on a system that didn't involve complex inter-process coupling of some sort. However, were one to take up network design or really low level tool-smithing, then learning the technique would pay dividends. For the run-of-the-mill MIS system though it is just too complex. Figure 37 shows how concurrent threads might look on a thread diagram.

The technique is a high level design technique that finds its apotheosis mid-way between use case analysis and object modelling. In fact, the time thread technique could be usefully added to most methods, especially where there is a need to model concurrency or real-time behaviour. Time threads could be usefully added to task scripting techniques. The root task script associated with a message in the business process model gives rise to a time thread map that is less committed than the associated sequence or activity diagrams, because it enables the designer to defer commitment as to which classes own or share the necessary responsibilities.

The ROOM method for real-time object-oriented design (Selic et al., 1994) introduced ports and the idea of representing their protocols as classes. It was the basis for the real-time UML notation. We will have more to say about these issues when we discuss component design, and look at the idea of capsules.