Formality vs. flexibility. Ultimately, the purpose of constructing models is to support analysis that yields predictions about real-world behavior. A formal process model, such as one created in Marvel, provides a basis for detailed analysis and improvement. However, formal models are usually difficult to develop and maintain. In Improvise we attempted to achieve a reasonable balance by encouraging users to create an initial, high-level process model, and incrementally refine it in a multilayered approach. A composite node in one layer of a model can be expanded into a process diagram that represents lower layers of the model. Further, users can annotate graphs with formal values, such as estimates of costs and delays, and informal descriptions (audio and video recordings). Improvise implements a mathematical algorithm based on extended Markov chains that uses the formal values to compute estimates of time, cost, and reliability of a process. Thus, Improvise supports high-level process analysis that, although less powerful than what can be obtained from Marvel, is nevertheless quite useful to technical organizations.
Manual graph editing vs. automatic diagramming. There is an intrinsic tension between user-defined object placement and automatic layout. Users seem to be very aware of node placement in forming a mental map of a diagram [Eades94], but may mix placement and routing methods in the same layout. Layout algorithms, on the other hand, generally assume a certain layout style (hierarchical, orthogonal grid, force-directed placement, etc.) and apply objective functions to try to optimize a global property such as number of crossings, bends, or total edge length. These objectives do not usually lead to stable, incrementally-generated layouts. Also, most automatic layout systems do not conveniently support differing layout styles and user hints within the same diagram.
The previous version of Improvise used an automatic layout service that did not accommodate user-defined placement at all. Early early users of Improvise reported that it was absolutely essential for their applications that manual node placement be respected by automatic layout services; if this requirement is not met, they will not use the system. We are working on satisfying this requirement by exploring effective incremental layout techniques. When updating a diagram, incremental techniques treat the previous placement of its objects as weak topological and geometric constraints on their subsequent placement in the new layout. These techniques can also accommodate certain user-defined hints on node and edge placement.
We have three prototype incremental layout systems:
Object database vs. ad-hoc representations. A system built on a transactional object database has the advantage of providing concurrency control for multiuser access to process and information models. It also offers unified management of multimedia objects and enforce consistency. Object database systems, however, can be quite expensive and complicated; it is thus very difficult to convince an organization to commit to using such a system up front, especially for experimental modeling.
We followed a two-phase approach to resolve this tradeoff. Improvise itself relies on the native file formats of its tools (e.g. annotated graphs in Dot, MPEG files). There is no concurrency control below the file level, and users are responsible for maintaining object collections in directories. This is sufficient for creating process and information models. When users want to invoke these models for process automation and more sophisticated analysis, they can use the Marvel system, to which Improvise is connected and which is built on an transactional object system. A diagram representing a process or information model in Improvise can be translated to a Marvel specification, and instances of this model are then stored as objects in Marvel's database. Marvel provides database management functions, including concurrency control to support multiuser access.
Open computing environment (Unix) vs. integrated environment (PCs) A typical research computing environment is composed mostly of workstations running some version of the UNIX operating system. Tools developed for such an environment are usually open in the sense of interoperating with other tools at the file or message passing level, without requiring tight integration. In contrast, the computing environment of many industrial organizations is composed of personal computers (PCs) running some version of Microsoft Windows, and perhaps some Apple Macintosh or UNIX workstations. System administrators usually integrate a set of programs to generate a uniform environment for users; interoperability with foreign tools is limited, or even inadvertently discouraged.
One of our users' requirements is that Improvise must be portable across Unix and Microsoft Windows, and thus we were particularly aware of the tension between creating systems under Unix and being able to integrate Improvise with Microsoft Windows programs. In fact, although the initial version of Improvise ran under MS-Windows, it was insufficient for many of our users because it was not integrated with other PC tools, such as word processors, nor did have the expected Windows ``look and feel.'' To meet this need, the interim version of Improvise is being moved to the TCL/tk version of Dot (that permits fine-tuning of graphical objects, and has been ported to MS-Windows). Meanwhile, we are building a new graph visualizing system in native MS-Windows with OLE (an Object Linking and Embedding protocol).