List Screenshot Collection

Last updated on 11-10-19.

The List application is straightforward: (1) a ListDriver instance is created in main; (2) prepopulateList is called on the ListDriver instance; (3) populateList is called by prepopulateList to create four MyItem objects and add each of them to the list encapsulated by ListDriver; (4) printList is called twice on the encapsulated list to print the list contents to the standard output. The source for this application can be found in our reference collection.

Sequence Diagram-- Completed Execution

Sequence Diagram state after executing the List application. Observe that the internal list encapsulated by ListDriver is an instance of LinkedList, therefore, JIVE does not collect information about it at run-time (this is configurable via the Debug configurations). In JIVE terms, this list is out-of-model.

When toString is eventually called on each of the MyItem objects, JIVE determines that the calls come from an out-of-model caller and renders the call and return arrows accordingly. In particular:

  • The first out-of-model call (toString:1 on MyItem:1) is directly connected to printList:1 using a special in/out+/in call arrow, indicates that one or more out-of-model calls exist between the top outstanding in-model method (printList:1) and the newly called method toString:1.
  • The return arrow from toString:1 is a standard UML lost message since the next in-model method to execute is not the top outstanding in-model method (printList:1) but rather toString:2.
  • The call arrow to toString:2 is a standard UML found message since the last in-model method that executed was not the top outstanding in-model method (printList:1) but rather toString:1.
  • The remaining call/return arrows are explained in a similar way. In particular, the return arrow from toString:4 is a special in/out+/in return arrow since this method is called from out-of-model and the next in-model method to execute is the top outstanding in-model method (printList:1).

Sequence Diagram-- Folding

Sequence Diagram state after applying fold before on printList:1. This is achieved by selecting the toString:4 activation on the Sequence Diagram, right clicking it with the mouse, and selecting the fold before option. The "+" symbols on the collapsed diagram regions indicate that some substructure has been omitted. Additional folding operations supported by the Sequence Diagram include: fold after, fold here, and fold children.

Sequence Diagram-- Temporal Navigation

Sequence Diagram state after performing a temporal jump to operation to the point in execution right before toString:4 returns. This is achieved by selecting the toString:4 activation on the Sequence Diagram, right clicking it with the mouse, and selecting the jump to option. The temporal context line (horizontal dashed line) is immediately moved to the corresponding point in the diagram and the Object Diagram is synchronized in order to reflect the new temporal context. The resulting Object Diagram is displayed below.

Synchronized Object Diagram state after the temporal jump. A few remarks should be made:

  • The outstanding call path is indicated by the chained blue arrows, where the color indicates the thread within which the methods execute.
  • A solid arrow indicates a direct connection between the called method (printList:1) and its calling method (main:1).
  • A dashed arrow indicates an indirect connection between the called method (toString:4) and the top outstanding in-model method (printList:1).
  • The special "return point" field in every method environment indicates the target of the arrow. In the case of a dashed arrow, the tooltip text will contain the actual out-of-model caller to which the called method returns, as illustrated in the figure.
  • The special "RESULT" field is present in methods whose return type is not void and will allow users to inspect value returned by a method right before execution is returned to the caller. In the example, toString:4 is about to return the string "This is my secret: 'cows moo'", which is then printed to the standard output.
  • The gray dashed arrow is a structural arrow indicating an association between a local variable (source of the arrow) and an object instance (target of the arrow). In the example, the local variable "driver" in main:1 is associated to the object ListDriver:1.