THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

Introduction

Visualization helps in understanding a software system. The dynamic views have been extensively used to understand behavior of system from various aspects and at various levels. For example, a flowchart is used to describe logical flow of a system. The orthodox flowcharts are not quite suitable for event driven OO paradigm and event traces with object identification have become popular. They however give no visual hint of decisions involved in system logic, which is one of the things achieved by activity diagram. The activity diagram thus comes as extended flowchart, giving a flow of activity of the system / object with identification of states and visualization of decisions as well as parallel processing. The statecharts depict life of objects (system as a whole may be represented as an object) in terms of states in which they may exist and way they may transform from one to another.

Each of the representation thus has a very specific purpose and it is to this purpose alone that it does justice. There is no alternative then, but to have a band of the dynamic views to serve most aspects of dynamic visualization of a system. We are thus attempting here to achieve a better visualization of a system in a single view, which may cover a multitude of these aspects.

We take example of a simple real-life printing system following the most popular event driven OOAD approach and evaluate what aspects of its visualization are covered by each of the available views. We then objectively list our requirements and check which ones of them can not be met by each of the views. Further, we attempt to bring together features of various dynamic views and add a few of our own to make the visualization more complete.

Case Study: a Printing System

We elaborate a printing system below in the form of a story followed by its conversational pseudocode (do not confuse with pseudo-conversation, which has altogether different meaning).

Story

We have a word-processor W connected to two printers: P1 and P2. The printers can either be busy of available. The environment E makes W to do a printing JOB and W has to respond back to E when it is done.

Given a JOB by W through the request GIVETIME, the printers return the JOBTIME to W. The JOBTIME may be upto 10 (units). The printers can also be busy. When busy, P1 returns a JOBTIME of 10, the largest possible value, whereas P2 returns -1. Thus excluding the case of P2 being busy, the JOBTIME is always positive.

Having thus got response from both P1 and P2, W decides the printer to be used to get PRINT executed in the least time and accordingly calls the appropriate printer. In case of the JOBTIME from both P1 and P2 coming equal or both keeping busy, the job goes to P1.

Conversational Pseudo-code

E: W, DOJOB
W: GIVETIME (JOB)
P1 [/ P2]: JOBTIME1
W: Take JOBTIME1, wait if the other response is yet to arrive
P2 [/ P1]: JOBTIME2

W:
{

     IF, JOBTIME1 = 10 AND JOBTIME2 <> -1
nbsp;    THEN, PRINT (P2, JOB)

     ELSE,

     SWITCH, JOBTIME2

     {

          CASE, -1
          PRINT (P1, JOB)

          CASE, > JOBTIME1
          PRINT (P1, JOB)

          CASE, = JOBTIME1
          PRINT (P1, JOB)

          CASE, < JOBTIME1
          PRINT (P2, JOB)

     }

     P1 / P2: W, JOBOVER

}

W: E, JOBDONE

[In the above pseudo-code, it is assumed that the cases are checked in sequence and the switch ends on executing first favorable case.]

Visualizing the Case

Now we consider the existing views to visualize the case given above.

Flowchart

Flowchart will put forward the logical flow and also visualize Boolean decision, but it will fail to show parallel messaging, parallel event handling by multiple objects (P1 and P2 in our case), logical joins (in case of W waiting for JOBTIME) and switches. It will also fail to give a picture in terms of inter-object conversation.

Activity Diagram (with State Support)

Whereas the activity diagram (often referred to as enhanced flowchart) will eliminate a few of the drawbacks of the conventional flowchart, it too will need to break the switch into multiple Boolean decisions. It will also fail to give feel of inter-object messaging.

Statechart

Statecharts are ideal for describing the behavior of a single object. A bundle of statecharts can give us the possible states through which each of the objects P1, P2 and W (and possibly E) will go. However, this is not describing the system behavior. If we take the system to be one object, we end up without object identity and too may uncanny states for the system. Issue of inter-object communication is simply out of scope here.

Interaction Diagrams: Sequence Diagram

The sequence diagram does solve our long heralded problem of inter-object messaging, but proves inadequate in visualizing system logic. There is no way of knowing how a decision was executed. The visualization of one message caught by multiple objects and handled simultaneously is also clumsy.

Interaction Diagrams: Collaboration Diagram

Apart from object identification and inter-object messaging the collaboration diagram will also show parallel processing, but it will give no clue of the process logic.

Requirements Distilled

From the discussion above, we come up with a minimal set of requirements that a visual representation of system behavior is expected to meet. As done in Event-trace analysis, an event may be identified by message(s) between event initiator and event handler objects. Thus in OO design, the approach is first identifying objects & inter-object messaging, and then showing it visually to put the business logic as clearly as we can.

The designer thus needs a visual representation that can:

• Work in event driven paradigm with a set of event flows rather than a unified flow.
• Identify objects
• Identify inter-object messaging
• Visualize object states
• Show parallel processing
• Show concurrent input requirement
• Visualize Boolean decisions
• Visualize complex switches
• Show system behavior with time dimension

Existing Alternatives

Let's generalize and summarize discussion made above on various visualization practices, intelligent (with CASE support) or otherwise, which are commonly used by visual modelers. In the chart below, we represent their suitability for the requirement criteria identified.

New View

We note from the chart that our requirement is of a diagram like the Interaction diagrams that will show object states, Boolean decisions, switches and temporal progress. If such diagram is not in use, we may design one for ourselves. We need the visual feel of flow as in activity diagram (as also flowchart) and collaboration diagram. In addition, we should have a rule set that will cater to the other requirements. We build below such set of representation rules. Since the representation materializing through this rule set is a new view in its own right, we have the obligation of naming it. In this view, we primarily represent how a trigger event progresses through inter object messaging and control. It may not be inappropriate thus to name this view the Event Progress Diagram (EPD).

Representation Rules

1. The Event Progress Diagrams are drawn after primary object identification. They may give inputs for identifying more objects.
2. The object is defined as rectangle with its name in its top portion (central portion, if attributes other than name are hidden), bold and underlined. We are of course open to use of different icons to represent different objects, thereby making the representation more visual.
3. An EPD is drawn to show consequences of an event. The number of EPDs for a system thus equals the number of trigger events that it handles.
4. EPDs follow the thumb rule generally accepted for flowcharts, of indicating progress of time vertically from top to bottom.
5. Their representation for inter-object messaging is similar to collaboration diagram. The messages may not be numbered however, since definite convention for temporal representation is followed.
6. The states of objects may be depicted in parenthesis below their name, in their representation.
7. Unlike Collaboration Diagrams they show self-delegation by redrawing the same object and passing message, thereby keeping to the temporal norms and facilitating display of states.
8. The fact, that decisions are made by objects, is clearly brought out by placing appropriate decision icon below and touching the decision-maker object.
9. They use same representation as in flowcharts to show Boolean Decisions.
10. They use a switchboard icon to handle switch conditions. A switchboard is a rounded rectangle with a horizontal line dividing it into unequal parts, the upper being the smaller one. The upper part is used to describe the switch statement. The cases are shown in the lower part.
11. If the Event initiator triggers multiple events in sequence (however infinitesimal the difference of time between them may be), the sequence of these "parallel" messages from an object is shown by placing the message receiving objects at vertically different levels.
12. In case where a message (event) is concurrently processed (handled) by multiple objects, a Fork bar is used.
13. In case where an object waits for receiving messages from a number of objects, the Join bar is used.
14. As a thumb rule, multiple messages:
    • Initiating from a Boolean decision or switchboard (these two are of course associated with objects) mean conditional execution
    • Initiating from a fork mean handling of a message by multiple objects
    • Initiating from an object mean parallel handling of different messages from an object

The Printing System Represented

Before we conclude, it will be worth seeing how the above rules fair in bringing out the desired results by drawing the Event Progress Diagram for the printing system case we considered earlier. This we do next.

Conclusion

As concluding remarks, it needs to be reminded that the EPD as it is shown here, is the first of its kind. It is quite likely that Visual analysts will differ on point of its utility. The observations in the chart above are necessarily controversial; since in most visualization efforts, what finally looks is what is looked at and how one looks. In addition, most visual methods have "accessories" which analysts optionally (in fact very rarely) use. Since the representation is usually made at a specific level of understanding and detailing, it suffices its purpose. The EPD has been aimed and has possibly done good to go deep into the system behavior in a single view. This is expected to improve the overall comprehension for its developer / user, and perhaps to make evident a few of the system behavioral problems that will otherwise emerge possibly much later.

It is realized that though based on simple rules and drawing norms, the EPD may not be the easiest representation always. The formal approach however means that it is capable of being tool supported and then perhaps becoming the easiest representation to put forth. It is not meant to summarily replace the present practices of behavioral visualization, since there are scores of analysts doing very well with these. Further, for a specific consideration of system behavior, these practices will be simpler in feel and easier to follow. Enterprising analysts will however check out the utility of the EPD. Tool support may also be obtained to construct EPD through other views and bring out errors / inconsistencies within the group of views.

Someone may point out that we started with Behavioral visualization in general and ended up giving solution (or additional problem perhaps) for a typical event driven OO scenario. What can the EPD do for SSAD (or indeed its unstructured counterpart)? If they meant to be able to use flowcharts here, there's nothing that the EPD can't do. If they mean a well modularized (structured) code, we have the option of replacing objects by respective routines and having nothing as Object State. Further, the diagram that initiated from an external trigger event may initiate from an internal routine (like most of the MAINs) / message or from the good old START block. In case we do not even have modules / subroutines (and this is definitely bad), replace the object block by a logical unit in the system as you may conceive it.

Previously published in the Journal of Conceptual Modeling August 2000 - http://www.inconcept.com/JCM/

© Copyright, 1998-2000 InConcept, Inc. (Information Conceptual Modeling, Inc.)