Objects On Stage. Animating and Visualising Object ... - CiteSeerX

Objects On Stage. Animating and Visualising ObjectOriented Architectures in a CASE Environment. X. Alvarez, G. Dombiak, A. Garrido, M. Prieto and G. Rossi (*) LIFIA. Departamento de Informática. Facultad de Ciencias Exactas. Universidad Nacional de La Plata. Argentina. (*) also CONICET and PUC-Rio (Brazil). E-mail: [xavi, dombiak, garrido, maximo, grossi]@info.unlp.edu.ar Abstract We present in this paper a novel approach for using visualisation and animation facilities in the context of an object-oriented CASE environment. We first analyze the general problem: why CASE tools will succeed or fail; then we present the outstanding features of our environment stressing animation and visualisation tools and an objectoriented framework for enriching CASE documents and application objects with hypertext facilities. Finally, we discuss further work with our animation and visualisation tools.

Introduction The traditional way of developing software means in general following a predefined development process within the context of a certain methodology, as a set of concepts, methods, techniques and notations, and using a CASE tool for representing and documenting the results of the development effort. This approach failed with traditional technology (i.e. Structured Techniques) and we don't see how it can succeed with objectoriented technology. The main philosophy of the object-oriented paradigm, this is seeing the world as a set of collaborating objects, and the intrinsic anthropomorphism of this approach, forces us to find a more intuitive and natural way for developing a complex and volatile piece of software. The final result of a traditional approach is a set of isolated, usually complex and incomplete documents which never provide a full insight of each artefact of a certain application or model. In this way a CASE tool only serves the purpose of documenting a development effort and never acts as a software engineering aiding tool. We must keep in mind that developing software is mainly a thinking process where we observe the world, make meaningful abstractions and elaborate these abstractions towards a full executable model of the problem domain. In our opinion a CASE tool must help in this thinking process and not just in the act of representing its results as a set of documents with a particular notation. Traditional CASE tools don't help to capture the backstage of the development effort, such as the deliberations between domain experts and developers and more technical ones between developers, and the rationales discovered in each deliberation which are the only reason why each artefact must be in a model (redesigned, modified, etc.). Another important problem of these tools is that they don't show the results in an intuitive

way. Let's say that we need to verify, check or trace a given artefact, traditionally one would have to get the many different representations of it in all the places or contexts in which it gets referenced or used (a relatively simple task for any CASE tool). Next you would need to make the abstraction of how all these things interact together to comprehend the artefact. All this turns into a lot of mental overwork just to verify if something was correct or not. A more desirable approach would be to retrieve the artefact and let the user decide how to view the different relationships it has with the rest of the application. Something like having a fish-eye view of the application but focused on the desired artefact, without disconnecting it and having to reconnect it mentally. We present in this paper an extension of the CASE environment proposed in [Alvarez93]. The extension consists in using animation and visualisation of object-oriented architectures and in having the ability to create hypermedia nodes and links between any artefacts belonging to the model being built. The structure of the paper is as follows: We first give an overview of our environment. We then describe the animation and visualisation capabilities with more detail. The third section explains how to add hypermedia facilities in an ad-hoc way. We conclude with some final remarks and future work.

Our environment Our environment handles four models: the Domain-Context Model, the Object Model, the Deliberation Model and the Descriptive Model. The Domain-Context Model represents the more significative relationships among domains and the context for each domain, such as use-cases or scenarios and external interfaces. The Object Model represents the software architecture in two ways, so that we can have a user perspective, made of a set of use-cases or use-scenarios that gathers a collection of collaborating objects to fulfil a certain business transaction, and a developer perspective which models a certain domain without considering a particular application. These two perspectives are necessary to handle the conceptual gap between the user and development realities and necessities from the development effort The Deliberation Model holds all the backstage forces that shape the development effort by capturing the rationales of the development process, in a way similar to that introduced by IBIS, but extending the different types of nodes and links that can be defined, also having un-typed links to keep relationships that need to be defined for later refinement. The Descriptive Model allows to enrich the descriptions of any artefact. These descriptions could range from a simple picture, to full fledged videos, animations and visualisations. We might want to get a set of objects, extracted either from the user or designer model, and animate them with a given script. This allows a better comprehension of how the objects interrelate and provides a much more solid ground not only for understanding but also for discussing the models that are being generated and thus validate and be able to rearrange things with shorter turn-around times.

In our opinion, the best way to achieve these goals is having all the models connected through an underlying hypermedia combining in a consistent way the CASE tool functionality with hypermedia navigation through items of interest of each model. Also, the distinction and separation among the four models require traceability among them so as to be able to retrieve the rationales for the existence of each artefact through links of the underlying hypermedia.

The Tree Within the Forest The development effort is always striving to handle all the complexity without generating more. But the complexity grows along with the evolution and comprehension of the problem. By graphically animating an object in the model a person involved in the development effort can understand it without having much of an overhead due to the mental process of 'seeing' how it interacts with the application. If a new specification is introduced, we can simply animate the object with the new requirements and see how it impacts on the design as a whole or part (with the desired detail). Any animation or visualisation needs an underlying model. Once an object is introduced to the object model together with some kind of behaviour it can be a candidate for the animation. The intervening object is placed in a special 'container' (view, window, etc.) in which a given script will be acted-out by the desired objects. This script (use-case, scenario, etc.) is the normal script generated either during the analysis or design process or even it might be generated by the users, which could also be used as a source of information. The animation will show how they interrelate and through what mechanisms so as to allow the viewer of the animation to discern whether the resulting behaviour is the originally desired and intended one. The internal mechanisms of how this is accomplished is outside the scope of this paper, but meanwhile let's say that through these visualisations the viewer can control and 'see' what objects interact and relate having the ability to filter the problem without being immersed in the intrinsic complexity generated by the solution. As with any visualisation, the objects involved have to satisfy certain prerequisites in order to be animated. Fortunately, most of what is required to animate an object is derived directly from the object models. These models describe the compositions, class relationships, instance relationships, dependencies, etc., together with some behaviour exhibited in this 'contact-points'. All of this information is taken into account at the moment of animating an object. Normally, we don't want to examine all the relationships of an object but a subset and its relationships with some predefined set of objects. Obviously, the animation shouldn't include all the aspects or behaviours exhibited by the object of interest. Much more reasonable it's to let the person doing the animation specify which of all the aspects are of his interest and then animate them. These aspects include some behaviour and the explicit relationships with other objects. Unfortunately the viewer might be a little bit short-sighted and 'forget' some other aspects or objects that are outside of his current scope, but are also involved in the subject of study. The animation is capable of keeping record of some things that are outside the current scope but that can be analysed to detect objects that

are being affected (or that participate in the fringes of the animation) and visually show how precise or complete the current animation is and let the user/director of the animation explore the 'unseen' complexity and determine its relevance to animation. Another useful characteristic of animating the resulting objects is to be able to compare the original specifications generated with the final product. Since the object model is separated between the user and designer, we should be able to reproduce the same behaviour in both models. By having conceptual spaces of animation we can always compare both models and see whether the resulting animation is the same, and if it isn't, then be able not only to see and show where they differ but maybe why they differ and thus try to bring both models closer together. This could be due to some unseen complexity in the user model, which can be verified, or it could also be because the design model drifted away from the requirements. This animation and visualisation are not only restricted within the CASE tool but it extends well into the programming language (Smalltalk in our case). This allows to constantly compare all three object models with the same tool and with the same representations. Keeping this uniform mechanism for the animation and visualisation of the development effort, allow not only the developers with different roles (programmers, designers and analysts) but also the user to constantly monitor any possible divergence with the models. The animation allows the user of the CASE tool to constantly animate any model and make comparisons between them, thus obtaining constant feedback on the differences in the models and be able to react and modify them. Strolling Around the Forest It's been widely recognised the problem of mental overhead that arise when we have to deal with a lot of unstructured information, as usually occurred with the development process of an application, in which each artefact introduced has its own background decisions of the reasons to exist, when it's related to other artefacts by different types of relations, and a change in its definition can affect many parts of the system. To deal with all this unstructured and very connected information a straightway solution is the use of hypermedia. Some CASE tools make use of hypermedia to support the connections of the different documents created for a particular methodology. But this is not enough. What we need developed is a hypermedia framework that allows us to map any kind of component of the CASE tool to a hypermedia node, extracting from that component its data and behaviour, and have the ability of connect that component with different kind of links, with an underlying semantic. We then propose to enhance each of the four models with hypermedia as a front-end tool, and also unified all of them in a global hypermedia that allows the traceability among them. The hypermedia also deals with different kinds of media needed in the descriptive model, but in a complex way in which we can attach an anchor in any part or 'moment' of a text, picture, video, sound or animation, thus allowing a link to depart from or arrive to that anchor. The possibility of making a link arrive at a component of the node

instead of arriving to the whole node facilitates the search of the related component in a possibly large document or resource, simply scrolling the text, playing the animation, video or sound or whatever is applicable. In the object model we can show as nodes any object introduced and/or generated for the application. A link between a given pair of objects, usually classes of the application, may represent a relation of collaboration or an influence of one over the other, or can relate classes of the same underlying pattern. We can also add consistency rules or restrictions to links that can advice or warn us of the whole impact in case of a modification to an object currently being developed, or modified. Furthermore, for any given object we usually need the ability of showing its data with different levels of detail or abstraction for a given stage (analysis, design, implementation, users) or role (software leader, analyst, designer) in software development. This is achieved defining different navigational contexts for each stage, and a set of nodeviews in each node corresponding to every context, so that we can think of that node as having many 'faces' so that each face shows a particular view. And for a given view we can also represent the same data but through different media. An instance of our hypermedia framework can also capture a 'part-of' relation as a composite node. Composites provide means of capturing non-linked based organisation of information, making a structuring beyond pure link networks an explicit part of hypertext functionality [Gronbaek94]. We can also use them to solve the information-overhead problem so common in the hypertext systems. The hypermedia framework also includes different types of browser and access structures, like indexes and guided tours, that aids the user to understand while reducing the search in the whole application space [Isakowitz94]. Another important issue recognised in CASE tools is the ability to query about the hypermedia space. The query results may be easily stored in dynamical virtual nodes so having the ability of making them browesable and linkable in a similar way to that introduced by [Gronbaek94].

Future Work We are now working in the construction of a set of tools for enhancing the animation facilities in our environment. In particular we are defining standard protocols such that a software engineer customising the CASE environment for a particular domain will be able to define new kind of visualisation and animation styles. For example it will be possible to specify the way in which a complex data structure is visualised and animated. In this sense our approach is more powerful than traditional ones like the one in [Stasko94] or [Kleyn88] because it is open-ended: different types of users may visualise the same object in rather different ways and we think this is a key feature in CASE environments.

Conclusions In this position paper we have discussed the main features of a prototypical CASE environment supporting high-level animation and visualisation features. We have discussed these issues in the context of an object-oriented life cycle and argued that these kinds of tools are critical if we want CASE tools succeeding with object technology. We have also analysed the use of hypertext in our environment. Though hypertext has been repeatedly reported as an interesting feature in CASE environments our approach goes further than previous ones because of the dynamic generation of nodes and links, for example in the context of an animation. References [Alvarez93] L. Alvarez, A. Amandi, M. Prieto and G. Rossi. "Combining Hypermedia and Objects in Domain Modelling". Proceedings of TOOLS Europe'93, Versailles, March 1993. [Gronbaek94] K. Gronbaek. "Composites in a Dexter-Based Hypermedia Framework". Proceedings of ECHT '94, Edinburgh, September 1994. [Isakowitz94] T. Isakowitz, E. Stohr and P. Balasubramanian. "Designing Hypermedia Applications". Proceedings of the 27th. Hawaii International Conference on System Sciences, Hawaii, 1994. [Kleyn88] M. Kleyn and P. Gingrich. "GraphTrace -understanding object-oriented systems using concurrently animated views". Proceedings of the ACM OOPSLA '88 Conference (Addison-Wesley, 1988), pp. 191-205. [Shilling94] J.J. Shilling and J.T. Stasko. "Using animation to design object-oriented systems". Object Oriented Systems, vol. 1, n. 1, 1994, pp. 5-19. [Stasko94] J. Stasko. "TANGO: A framework and system for algorithm animation". Computer 23, 1990, pp. 27-39.