Architecture Comprehension Tools for a PBX System - IEEE Computer ...

Download PDF
1 downloads 0 Views 179KB Size Report
Comment
cesses and their communication links inside the switch). Given a ... Also, the link between ..... [6] B. Steffen, T. Margaria, A. Classen, V. Braun, M. Reit- enspiess.
Architecture Comprehension Tools for a PBX System - Experience Report R.L. Krikhaar R.P. de Jong J.P. Medema Philips Research Laboratories Prof. Holstlaan 4 (WL01) 5656 AA Eindhoven The Netherlands [email protected]

Abstract The comprehension of the dynamic and static structure of a system is of main importance for purposes of adding features, bug solving, and for redesign activities. This holds particularly for systems where the features tend to be strongly intertwined. In telephony systems, there is feature interaction both at specification and implementation level. In the present paper we report on a dedicated environment called URSA: Understanding and Recovery of the Sopho Architecture. A special role is played by an extended MSC language called CMSC. Keywords: software architecture extraction, program visualisation, dynamic analysis, program comprehension, Message Sequence Charts, Web technology

1 Introduction Philips is an electronics company which operates worldwide and develops professional systems such as business communication systems, medical systems as well as consumer systems, e.g. audio, television. The architecture of software based systems plays an important role to develop new products within acceptable time to market schedules. New developers should learn the architecture rapidly to become cost effective as fast as possible. They need to understand and comprehend the system’s architecture to be able to extend and/or maintain the system. But also experienced users ask for tool support to browse, analyze and comprehend the system, due to the system’s size and complexity.

L.M.G. Feijs

Philips Research Laboratories Eindhoven University of Technology The Netherlands [email protected]

The last few years a number of publications have appeared that address the subject software architecture. Software architecture concerns computational components and interactions among those components [1]. Soni et al. [2] distinguish five different views on architecture:  conceptual architecture: describing a system in terms of its major design elements and relationships among them,  module architecture: functional decomposition and layers, which are orthogonal structures,  execution architecture: describing the dynamic structure of the system,  code architecture: describing how the source code, binaries, and libraries are organized in the development environment,  hardware architecture: describing the hardware components and their relations as far as they are relevant for making software design decisions. The module architecture (or static structure) of a software based system can be made explicit by identifying the dependencies between the various components at various abstraction levels (files, modules, components, subsystems). This process of reverse architecting the module architecture is already described in [3] and [4]. The problem of feature interaction in telephony systems is a well-known problem [5]. Typical features are various kinds of follow-me, automatic ring-back and conference calls. In public telephony, the topic of feature interaction has been addressed by the introduction of the IN (intelligent network) concepts, splitting functionalities over specialized units like Service Switching Points and Service Control Points and also introducing dedicated service cre-

plementation issues are presented. We finish the paper with a discussion of related work and a conclusion (Sections 8 and 9).

ation environments, see e.g. [6]. It is typical for public telephony that the billing systems are very complex, and this is one of the reasons why the concept of Service Independent Building block (SIB) turned out fruitful: for example access to billing databases is encapsulated in SIBs. For private switches (sometimes called PBXs), like the members of Philips’ Sopho family of switches, the nature of the feature interaction problems is different. Whereas for public telephony, the IN concept can be introduced by redistributing functionalities over a national network, a private switch works more locally and it has to deal with the feature interaction internally. Moreover, there is less focus on billing but instead there is a wealth of variations with respect to the call-topologies (a topology comprises the telephone parties involved in a call, as well as the software processes and their communication links inside the switch). Given a system with N features, there are potentially N 2 feature interactions possible between two features. The system grows in the direction of adding more features, resulting in more complications with feature interaction. Furthermore, different customers ask for different sets of features. These features must be switched on and off in a effective way. These variations of the product enlarge its complexity. Here it is also important to mention the graphical language MSC [7], which has been designed with (amongst others) the goal of analyzing feature interaction in mind. A closely related language is called Interworkings [8]. The latter language is much simpler because it is concerned with synchronous communication only. The dedicated toolset URSA has been built to suit the specific needs of the Sopho environment. In this paper we focus on reverse engineering the dynamic structure of a system (URSA covers also module architecture). Also, the link between execution behaviour and static structures is emphasized in our tools. The main results of our work are:  we have developed a model to present a dynamic structure of a system with a dedicated execution model;  we have established a logical connection between dynamic structure and static structure;  we have exploited readily available internet technology, adding dedicated techniques when needed. Software analysis generally consists of three stages:  extraction of information from system artifacts (source code, documents) and system experts,  abstraction to a requested level of detail,  presentation of the abstracted information. The paper is structured as follows: first the baseline of our project is discussed (Section 2) and secondly the three stages of software analysis are addressed (extraction, abstraction and presentation) in Sections 3, 4 and 5 respectively. In Section 6 Clickable Message Sequence Charts are presented and related to MSCs. In Section 7 some of the im-

2 Baseline In this section we discuss the baseline, by which we mean the relevant aspects of the Sopho switch and its tooling as existing before, which served as the starting point for our own developments. The Sopho system consists of about a million lines of C++ code, divided over ten subsystems, tens of components and thousands of files. The oldest parts of the system have been built more than ten years ago. Furthermore, the system contains its own local operating system (LOS). The details are proprietary, but some explanation of the execution model of the system is given below. Initially, the system starts a number of service processes and a generic call process. The latter process is responsible for creating a new process for each telephone call. A call process consists of a number of tightly coupled sub-processes working cooperatively together. For the A-side (calling extension) and B-side (called extension) a proxy, resided in such a sub-process, hides the specifics of an extension. The subprocesses are grouped together as indicated in Figure 1. The grouping concepts are closely related to the call topology.

Control A

A

Proxy A

Control B Proxy B

B

Figure 1. Basic Call structure At the start of our project there already existed a way to visualize the dynamic behaviour. The visualization tools were based on the ITS toolset, described in [9], using Interworkings [8]. Especially the Postscript drawing tool of [9] was heavily used, both for feature analysis and for internal educational purposes. Three major restrictions of this approach, which were overcome by the language and tools described in the present paper are:  an interworking is a synchronous sequence chart; it is hard to express that there is a delay between sending and receiving a message. This is important since messages have priorities and the order of receipt need not match the order of transmission;  an interworking can only express binary communication, and it can not express, for example, the simultaneous creation of two sub-processes of a call (a workaround is shown in Figure 2); 2



interacting features. We are interested in the dynamic behaviour when applying a Telecase on the target. We foresee the possibility of building a database of TeleCases, containing both the TeleCase itself and the CMSCs resulting from executing them. In principle, all options with respect to traffic generation hardware and capture-replay tools, which are available already, can still be used. For debugging a single run, no database is needed, but for certain cross-referencing purposes (e.g. find out which modules are not used in certain type of “follow-me”) it is needed to have a representative set of TeleCases. We experimented with a database-like front-end for querying a file-based collection of TeleCases, but no real design has been made. Next to the step of CMSC construction, other abstraction tools could be inserted as well. They should work on CMSCs (we consider this better than already abstracting during at logging level), and we envisage functions like collapsing groups of (sub-)processes. No such abstractors are implemented at present, however.

an interworking is made available as a postscript document (hard-copy oriented). It can be printed on paper or viewed on-line using a postscript viewer, e.g. Ghostview. The diagrams are not “scrollable”, although the issue of cutting the diagram at page boundaries is nicely solved (see Figure 2). The main disadvantage is that there is no interaction possible, in other words, interworkings do not contain hyperlinks. Please note that the first and second limitations are language limitations whereas the third limitation is a tool limitation. A relevant investigation is reported in [10], where it is shown that replacement of printout by sophisticated interactive viewing yields siginificant reduction in comprehension time, next to improvements in “answer” quality. i_cc

c_pfh

c_pc

START_OF_CANCEL_FOLLOW_ME_PAGE_1 launch_partition Proxy_A launch_partition

3 Extraction

Control_A split_process

The first step is to extract information from the system. For static analysis, one can analyze the system artifacts (source code etc., which is directly accessible). For dynamic analysis one is restricted to monitor the target system, using dedicated tools as usually packaged in a standard operating system. Another way is to instrument the source code to be able to log information about the execution. In our case we instrumented the code by adding statements within the LOS. During execution, the following activities are logged, in a so called AFF (Action Flow Format) file:  messages: send and receive of a message are handled separately;  timers: start, expire and stop;  LOS actions: launch, split, and kill; a process can split the set of sub-processes into two sets each having its own address space. In case one of these activities occurs, the instrumented code takes care of logging information (i.e. time, process id, and message/timer/action) in a file. Besides this information also the call stack is logged. This information is logged in hexadecimal code. We must note that monitoring heavily affects the performance of the system, but in our setting this is not our point of attention. For URSA, we have extended the logging facilities of the system for ReceiveMessage (previously only SendMessage was logged) and the call stack. The used C++ compiler takes care of generating a number of symbol tables. These tables are necessary to transform hexadecimal code into symbolic names. The following tables are produced during compilation:

Figure 2. Launch and split in interworking To give already an indication of one of the improvements, we show Figure 3, where the artificial sequentialization of the creation action has been replaced by a more natural representation in CMSC (our new language). Initiator

launch

Proxy A

Control A

split

Figure 3. Launch and split in CMSC The executaion of use cases, which we have called TeleCases in this context, on a target system results in many activities in the system. Some of these activities, e.g. sending of messages and launching of new sub-processes, are of interest in an architecture context. We focus on the issues that are of importance for architectural decisions. As explained, feature interaction is a main issue in this type of systems. We introduce TeleCases, where a TeleCase is defined as a use-case related to a single feature or two 3



message names; for example #AF0F0124 maps to OFF HOOK;  message contents; this is context sensitive information. For different messages the contents must be transformed differently, but also values of certain fields decide on how to interpret the other fields (think of a union-like construct with a separate tag field); a separate tool, which already exists previous to URSA, takes care of this kind of transformations,  process identification; the process-ids of fixed processes are defined, in a table, in the source code. The dynamically created processes are harder to identify, but the types (Proxy or Control) can be reconstructed from the first digits of the process-id;  statement addresses; instructions relate to statements in the source code. A map table includes relations between addresses and source file locations. In fact, this is similar to information a traditional debugger requires to show the appropriate line of the source code. To reduce the amount of log information a special contamination concept is used by the instrumented code (this was already in the baseline). The idea is that initially a few (e.g. one) processes are chosen as being ‘interesting’. LOS keeps track of this fact by a single bit for each process. As soon as another process receives a message from a process which has this bit set (such a process is said to be ‘contaminated’), the receiving process sets this bit set as well. Only actions related to contaminated processes are logged. Analogously, messages can be marked as ‘interesting’, with the effect that processes who send or receive these messages are ‘contaminated’.

these mappings available. Now we have to apply the appropriate inverse mapping to the logged hexadecimal codes. In this way messages and processes get labeled with the right strings in the graphical representation. Moreover, the begin and end nodes of messages get labels which are URLs, containing statement addresses (source code file name plus line number). These URLs allow the diagram of Figure 4 to be closed when the user clicks. In other words, the user can browse through the CMSC and the corresponding source code, while staying at the symbolic level. Possible clickactions in Figure 4 are indicated by the bear’s claw (URSA means bear in Latin :).

4 Abstraction

There is a third transformation which is done before the CMSC is transferred to the presentation tool Jolly Jumper: transitive reduction of the partial event-order (using the terminology of Section 6 below it is an ordering on so-called ‘occurrences’). The idea behind this is as follows: the semantics of a CMSC is a partial order relation on events, such that e.g. the begin node of a message precedes the end node of that same message, the begin node of an actor segment precedes its end node, etc. In general this is not a linear order, since there may be events on remote actors, not directly or transitively ordered in this way. This is the traditional interpretation of ITU (International Telecommunication Union) MSC, which are designed for specification purposes, not just for logging. We had some discussions whether a linear ordering is more appropriate for logging, but we decided to adopt a partial order semantics too, especially since this gives additional freedom to the layout algorithms of Jolly Jumper. The freedom could be used to compress the diagram in vertical direction, drawing unrelated activities next to each other instead of below each other. For each pair of nodes (= events) it must be possible to find

module structure use URL

run Tele Case

source code

map

symbolic names

CMSC

compiler and linker

inverse mapping mapping table

translate

inverse mapping inverse mapping

binary code

load

run in SOPHO

low-level logging

Figure 4. Clicking as closing the diagram

In order to construct a CMSC after the low-level logging data, AFF, have been extracted and transferred to the host, a number of transformation and translation steps have to be done. First of all, the linear list of events must be transformed into an CMSC object, containing sets of actors, actor segments, messages, etc. which refer to a (shared) set of nodes (such as the begin and end nodes of messages). The main effort is to find matching pairs of send and receive statements. Secondly, the actors and messages must be labeled with strings, corresponding to process identities and symbolic messages with symbolic parameters. Initially these labels are given as hexadecimal codes, but then these are translated into symbolic expressions wherever possible. This translation is done on the basis of the symbol tables generated by the compiler (and linker), as mentioned already in Section 3. It is the task of the compiler to assign codes to message names, codes to process names, etc. and to make 4

out if one precedes the other. But note that if n1 < n2 and n2 < n3 , also n1 < n3. Should the abstractor store all such implied facts too in its data structure? We had to make a decision here affecting the interface between the abstractor and Jolly Jumper: we decided that only the directly ordered pairs are stored in a kind of minimal representation. Formally, this means that the abstractor calculates the transitive reduction of its partial order. Transitive reduction is the opposite of transitive closure; for a relation R it can be found as R, (RR+ ) where , is asymetric set difference,  is relation composition and R+ is transitive closure. We avoided the explicit calculation of transitive closures and used a simple algorithm to perform the reduction in-situ as a graph-traversal on the internal representation of the CMSC (Java objects pointing to each other).

The dynamics of the system are viewed in a CMSC diagram created by the tool Jolly Jumper, see Figure 5. This shows the message communications, but also activities like launching new processes. Both sub-processes and processes are treated as a “pillar” in the viewer. The circles and other symbols represent special actions of the system. The diagram contains many clickable points for “jumping” to the presentation of the pertinent Sopho source code. The source code of Sopho is presented in a separate window of the Web browser (including the related call stack), see Figure 7. Furthermore, the user is able to “click” to the world of module architecture as described in [3] and [4].

6 Clickable MSC This section is devoted to the graphical language we designed and which is supported by the Jolly Jumper tool. CMSC is a graphical language in the tradition of Interworkings [8] and MSC [7]. We show an example in Figure 6, which contains creation nodes, synchronization lines (the dotted lines), a found and a normal message, a remote set state, a condition (here called ‘state’), two creation and two termination nodes, and a local action (number analysis()).

5 Presentation The previous two sections describe in fact preparations for the presentation of the dynamic structure. We have chosen to employ Web technology for our URSA system. It facilitates hyperlinking, and it has the advantage that the whole software community is familiar with it. We assume that the user of URSA is the Sopho developer who wants to understand (a part of) the system. The container of the presentation tool is a Web browser. The entrance of URSA is a Web page with the various available areas of attention. The developer can search for information by clicking around, e.g. to select a scenario with a particular feature or to view the actual relations between components.

i_cc

off_hook c_pfh

c_pc

) call(2

_

s_soc

state=idle number_analysis()

Figure 6. Graphical elements of CMSC The most distinguishing feature of CMSC is that nodes, edges, and messages have an URL (Universal Resource Locator) associated with them, which can be used for clicking and jumping to the source code and other relevant information (hyperlinking). Moreover, CMSC has a number of additional features which are closely related to the intended application: Sopho program understanding. The idea is that as much logging information is made available as possible, for example time-stamps and specific kinds of synchronous communication next to messages and timers.

Figure 5. Jolly Jumper 5

for stable, running, blocked, etc., and then the receiving node of one actor must be synchronized (equal vertical level + dashed line) with the node of the stable-blocked transition of the other. The last ‘group’ of features concerns one feature which has been discussed, but which is neither in CMSC, nor in MSC-96. We add a few remarks on the way we designed and described the language. We described the CMSC language at an abstract level, independent from the concrete representation as Java objects, and independent of the specific graphical elements chosen during the design of Jolly Jumper. CMSC has no textual syntax, and hence no Backus-Naur grammar. It is described as a collection of object classes. We did not write a fully formal syntax for the graphical language; instead, we decoupled the (object) model and the view, treating the former as the essential language definition, and the latter as a matter of choice freedom for the presentation tool. The main CMSC object types are:  URLs.  strings,  actors,  nodes (of various subtypes),  time-stamps (natural numbers),  messages (of various subtypes),  edges (of two subtypes, viz. actor edges and macro edges),  occurrences (nodes sharing an occurrence are simultaneous; more general, all information with respect to the ordering is cast into attributes of the occurrence objects), Next to the definition of these objects and their attributes, we formulated a number of well-formedness rules. To give an impression, we show a few of them:  a creation node may only appear as an actor’s first node;  an end node may only appear as an actor’s last node;  nodes shall not be shared amongst actors or macro edges;  occurrences shall not be shared, except if the nodes involved are: a normal node and a creation node, or a normal node and a remote action node, or two normal nodes. Semantically, a CMSC denotes two relations: first, an equivalence relation e on the set of nodes, and second, a relation < on the equivalence classes of e.

In the table below, we list a number of features, and compare them with the corresponding features of MSC-96. The first group contains those features which appear both in CMSC and MSC-96, although for CMSC we have a terminology which differs in some cases. The second group of features is unavailable in CMSC, although present in MSC-96. They are unavailable because they were not in IW (interworkings), they are not urgently needed, and probably they would present complications in the design of Jolly Jumper. For example, high-level MSCs are a kind of graphs (road-maps), which show how to walk through a collection of normal MSCs. This is present in MSC-96, but since Sopho logs do not present branches and alternatives in a natural way, these things are excluded from CMSC.

messages timers actions entities MSC references conditions partial order semantics process creation connectors environments and gates high-level MSCs inline operator expressions hyperlinks synchronization special string labels time-stamps actor segment coloring global total timeline

CMSC + + + + (‘actors’) + (‘macros’) + (‘states’) + + + + + + + -

MSC-96 + + + + + + + + + + + + -

The third group of features is available for CMSC, because they are considered essential for Sopho programunderstanding and because they are essential for the basic idea of Jolly Jumper. These are not in MSC-96. Synchronization is considered necessary for three reasons. First, for representing remote assignments (“Set State”). Secondly, for avoiding misleading drawings of actor creations: e.g. two actors are created in one step, and then they must start at the same vertical position. Thirdly, because Sopho actors have hidden communication, which must be visualized. The key example is the execution-state of an actor (stable, running, blocked, etc.). Two actors of one process are connected in the sense that if one of them becomes “running”, the other may turn into “blocked”. Future versions of the Jolly Jumper may support separate colors (drawing styles)

7 Implementation This section starts with a discussion on design principles. After that we present some of the design decisions for three specific tool components, viz. the AFF translator, the CGI scripts, and the Jolly Jumper. 6

At the start of our project we have defined the following general design principles:  use models, tools and techniques that already exist. Develop new modules or functionality in those parts that are unique for the application domain;  relax requirements where possible to adhere to this principle, but don’t be to generous in this;  adopt an open tool architecture with e.g. possibilities to easily extend with new (visualization) tools; separate abstraction functionality from viewing to elaborate the advantages of such a Model-View-Control pattern);  use non proprietary standards and tools of the World Wide Web. AFF translator: When the target system operates in a special mode, a stream of information is passed to a connected PC. This binary format is translated to a readable format which we have called AFF (Action Flow Format). Currently, the AFF file is processed by a number of awk scripts to map hexadecimal code into symbolic names. A Java program translates the AFF format into serialized CMSC objects. The AFF translator also calculates the proper URLs for each CMSC object. An example of such an URL is:

Figure 7. Source Code Viewer

overview, zoom view and a dictionary view. The overview shows processes and message communication. The user is able to hide processes in which he/she is not interested. Various colors are used to distinguish states, actions and events. Furthermore, the process columns have a width proportional to the number of messages sent or received. It is possible to zoom in on a part of the MSC, resulting in a separate windows. Furthermore, the contents of a message can be displayed in a so-called dictionary view. In [11], Jerding et al. describe two prototypes of tools for identifying interaction patterns in program event traces. There are two main techniques, the first of which amounts to creating a global overview of a message trace containing hundreds of thousands of messages (creating a miniature representation of it). Such an overview is called a Mural. The second technique is based on pattern recognition, patterns being represented as special types of compact call trees. The options provided by the tools include a source code view in which arrows between functions, classes etc. are shown for a selected set of messages. It is also possible to display diagrams of recognized patterns, applying the mural technique again to get a compressed view. Visputer [12] is a tool to graphically design and edit message-passing programs. The tool generates machine language code, Occam, for transputers. Because the tool generates the code, it is also able to instrument this code. During a run events are logged in a file. The animator retrieves event information from this file and replays execution by animating communication activity. The visualization of communication patterns is shown in an event-time diagram. As the name indicates, the elapsed time is one of the axes of this diagram. The Software Bookshelf [13] is a prototype environment which captures, organizes, manages, and delivers compre-

http://www/URSA/cgi/source.pl?sendHookOff.stack

The file sendHookOff.stack contains the call stack in a post-processed form, namely addresses and source code locations. A Perl script source.pl generates from this information the above described frames. CGI scripts: The URL refers to a CGI script that generates a view as displayed in Figure 7. The source code viewer consists of several frames. The frame on the left shows the call stack belonging to the latest clicked CMSC object. The right part shows a frame with the source code, in which the statements that correspond to the CMSC object are highlighted. The title, name of source file, on top of this frame is a hyperlink to module architecture-related information of this file. Jolly Jumper: this is the CMSC visualizer. It has been implemented in Java (version 1.1) using the AWT package. The fact that we have used the newest Java version has resulted in some practical problems. The Web browser at hand did not support Java 1.1, so we have constructed Jolly Jumper as an application. From a Web browser perspective this program viewer is a “helper” application for opening CMSC files. In a later version of URSA, Jolly Jumper can be easily transformed into an applet running in a (Java 1.1 compliant) Web browser.

8 Related Work SeeSeq [10] is a visualization tool for Message Sequence Charts. Most MSC (drawing) tools use text- and typographic-based methods. SeeSeq uses several views: 7

conference call etc.), exploitation of such a scenario database, for example, by adding a search engine on top of the scenario database; it could also be combined with advanced cross-reference tools to find out which code modules play a role in the interaction of two or more features. Although many of the ingredients of the URSA approach (clickable documents, message sequence charts, etc.) are not new as such, the project as a whole was still an interesting challenge because it required a lot of design decisions, language-design and fine-tuning of interface details to convert the initial ideas into a useful environment. We feel that other tool constructors may benefit from the approach, the experiences and the technical solutions reported in this paper. Acknowledgments: We thank Thijs Winter and Reinder Bril of Philips Business Communications in Hilversum, the Netherlands for their efforts and contribution to URSA. Without their cooperation and enthusiasm URSA would not have reached the current stage. We also thank Ron Koymans for his contribution in discussions. Furthermore, a number of people of Philips Business Communications have supported us in our work.

hensive information about software, and provides an integrated suite of code analysis and visualization capabilities intended for software re-engineering. Various roles are defined to build the bookshelf (builder), to maintain its contents (librarian), and to browse the bookshelf repository (patron). The bookshelf is based on an open architecture, which allows a variety of tools to be integrated. The bookshelf architecture uses Web technologies extensively, e.g. CGI and Java to build the glue code for integration. URLs are used to have unified access to information resources. Also [14] and [15] describe related work. Next, let us compare [10, 11, 12, 13] with URSA. SeeSeq uses nice techniques to focus the user’s attention, like coloring schemes, marking points and information hiding (but no hyperlinks to source code). Most of these techniques are complementary to Jolly Jumper. Compared to the tools of Jerding et al., URSA allows for more specific details in the event traces (distinct types of arrows, actions, stateinformation, etc.), but is weaker with respect to its abstraction mechanisms. Visputer generates very specific machine language. Furthermore, it uses a communication model which is different from MSCs, which are effectively used for telecommunication systems. The Software Bookshelf and URSA use very similar open architectures. Both systems are based on Web technology. The open architecture enables to easily extend the system with new information visualizers. The three identified roles, builder, librarian and patron, can also be recognized in URSA.



References [1] Mary Shaw, David Garlan, Software Architecture: Perspectives on an emerging discipline, Prentice Hall, 1996. [2] D. Soni, R. Nord, C. Hofmeister Software Architecture in Industrial Applications, Proceedings 17th International Conference on Software Engineering, April 1995. [3] R.L. Krikhaar, Reverse Architecting Approach for Complex Systems, Proceedings International Conference on Software Maintenance 1997, pp. 4-11, 1997. [4] L. Feijs, R. Krikhaar, R. van Ommering, A Relational Approach to Support Software Architecture Analysis. Software Practice and Experience, Vol. 28(4), pp 371400, April 1998. [5] C.A. Middelburg. A simple language for expressing properties of telecommunication services and features, PTT Research report 94-PU-356, (1994). [6] B. Steffen, T. Margaria, A. Classen, V. Braun, M. Reitenspiess. An Environment for the Creation of Intelligent Network Services, in: Intelligent Networks: IN/AIN Technologies, Operations, Services, and Applications - A Comprehensive Report, pp. 287–300, IEC - International Engineering Consortium (1996). [7] E. Rudolph, J. Grabowski, P. Graubmann. Tutorial on Message Sequence Charts (MSC ’96), in: Tutorials of the First joint International Conference on Formal

9 Conclusions The construction of the first version of the tools is being completed now and the first version of URSA has been installed. The reactions and the feedback from the intended developers/users are very positive and encouraging. At the same time it is clear that there will be requests for various extensions in-the-small (other colors for certain buttons, etc.). However, also extensions with more impact are already coming up. We mention the following options for nontrivial extensions:  coupling of error traces from “the field” to URSA, which means that the traces should be extended for this purpose (relating them to core dumps etc.),  more tight integration of the URSA environment into the Sopho software development environment (taking the build-process into account),  construction of abstraction tools which operate on CMSCs to deal more easily with larger chunks of information and, hence, enhancing comprehension,  creation of a large database with scenarios which provide a systematic covering of the TeleCases of certain important features (follow-me, automatic ring-back, 8

Description Techniques for Distributed Systems and Communication Pro tocols, and Protocol Specification, Testing, and Verification (FORTE/PSTV’96), Kaiserslautern, Germany, October 1996. FORTE’96. [8] S. Mauw, M. van Wijk, T. Winter. A formal semantics of synchronous Interworkings. In O. Færgemand, A. Sarma (Eds.), SDL’93 Using Objects, Proceedings of the Sixth SDL Forum, Elsevier Science Publishers, 1993. [9] S. Mauw, T. Winter. A prototype toolset for Interworkings. Philips Telecommunication Review, 51(3):41-45, 1993. [10] Stephen G. Eick, Amy Ward, An Interactive Visualization for Message Sequence Charts 4th Workshop on Program Comprehension, Berlin 1996 [11] Dean F. Jerding, John T. Stasko, Thomas Ball, Visualizing Interactions in Program Executions, Proceedings 19th International Conference on Software Engineering, 1997. [12] Gaurav Marwahe, Kang Zhang, Parallel Program Visualisation for a Message-Passing System, Proceedings 13th annual IEEE International Phoenix Conference on Computers and Communication, April 1994. [13] P.J. Finnigan et al., The Software Bookshelf, IBM Systems Journal, Vol 36, No. 4, 1997. [14] Gregory Abowd et al., MORALE Mission Oriented Architectural Legacy Evolution Proceedings International Conference on Software Maintenance 1997, pp. 4–11, 1997. [15] W. De Pauw, R. Helm, J. Vlissides, Modelling objectoriented systems, Proceedings of the European Conference on Object-Oriented Programming, 1994.

9