A Component-Oriented Architecture for the CASE

A Component-Oriented Architecture for the CASE-Tool AUTO F OCUS Klaus Bergner, Andreas Rausch, Marc Sihling bergner rausch sihling @in.tum.de Institut f¨ur Informatik, Technische Universit¨at M¨unchen D-80290 M¨unchen

Abstract In this paper we explore how the componentware paradigm can be used for realizing a distributed multi-user CASE tool. The case study concentrates on the repository subsystem, as this is the most critical component with respect to the overall design and has strong implications on the possible working modes available to the developers. The proposed architecture will be integrated into the existing CASE tool AUTO F OCUS which was designed originally using an object-oriented architecture. Keywords: Componentware, Design, Java, CASE, Repository, Framework

1

AUTO F OCUS – A Distributed Multi-User CASE Tool

AUTO F OCUS is a prototype implementation of a multi-user software engineering tool for the specification and simulation of distributed systems based on the formal development method F OCUS [1]. Within this framework, AUTO F OCUS currently provides graphical description formalisms covering different aspects of distributed systems. For each of these formalisms, AUTO F OCUS provides its own graphical editor (see Figure 1). The conceptual basics of AUTO F OCUS and its description techniques are described in detail [2]. Once the desired system is specified with these description techniques, code for a prototype of the system can be generated and animated to validate the correctness of the specification [3]. AUTO F OCUS is implemented as a client/server system. It consists of a central server that manages the repository with the development documents and provides mechanisms for client access control and version management. The development documents in the repository are organized according to the projects. The AUTO F OCUS client contains a project browser used to navigate through the development projects and documents in the repository, and the graphical editors necessary to edit the different kinds of diagrams. This paper originated in the ForSoft project A1 on “Component-Based Software Engineering”, supported by Siemens ZT.

Figure 1: Project Browser, STD Editor, and EET Editor of AUTO F OCUS

In its current form, AUTO F OCUS has many drawbacks with respect to its extensibility and to the possibilities it offers. Mainly, because its repository is based on simple data files corresponding to the different development documents. If a developer wants to edit or view a development document, the corresponding file is loaded by the repository server and sent over the network to the respective client. Although this simple architecture is sufficient for simple editing tasks on the level of whole documents, it is too rigid and breaks down for tasks that require other levels of granularity or that involve more than one developer. Another drawback of the current approach is that the meta-model is more or less hard-coded into various parts of the tool (a meta-model is an explicit model of a description or modeling technique supported by a CASE tool, cf. [4]). To provide adequate support for all sorts of tasks and for arbitrary meta-models, a new approach for the repository architecture is needed. In the following, we first list and explain the requirements for a generic repository for distributed multi-user CASE tools. After that, Section 3 presents an overview over a new, component-oriented repository architecture which is at the one hand powerful enough to support different working modes and at the other hand flexible and extensible enough to be enhanced with new mechanisms and services. The following Sections 4.1 until 4.4 cover some of the basic mechanisms and services, namely, persistence and archiv-

ing, locking and checkin/checkout, versioning, and transactions. Finally, the hardware/software mapping and the proposed distribution architecture are presented in Section 5. A short conclusion ends the paper.

Checkin/Checkout At each time, only one user has the right to edit a single model element, and no other user can see his or her modifications. Elements that are checked out by a user must be accordingly marked to indicate that they can neither be edited nor seen by other users.

2 Requirements and State of the Art The main goal of the redesign is to make AUTO F OCUS a flexible toolkit for experimentation with adaptable metamodels, working modes, and new CASE tool concepts in general. Therefore, extensibility and flexibility with respect to the following issues is required: Extensible Meta-Model and Services: Meta-modelers and methodologists are offered a rich and comfortable framework with base mechanisms and services for all kinds of meta-models. New meta-models and description techniques can be easily integrated. Once they are integrated, they take automatically part in the basic mechanisms and services already provided by the framework. Additionally, new mechanisms and functionality can be integrated into the framework. Multi-User Support: The development of a new software system is a very demanding task. This is partly due to the fact that experts of different knowledge areas, for example, system analysts, system designers, and programmers are working collaboratively to carry out a project. A CASE tool should, therefore, provide extensive support for computer-supported collaborative work (CSCW) and for data sharing (cf. [5]). This pertains especially to different working modes suitable for various organizational configurations. The main variants with respect to multi-user support are: Shared Whiteboard Some users may simultaneously have the right to edit a single model element (such as a state of a state transition diagram, the label on a transition, or the whole diagram), and they see all modifications in real-time. If conflicts arise, they are resolved according to some strategy. If, for example, two users attempt to drag a graphically represented element to different locations on the screen at the same time, only the action started first may succeed. Exclusive Whiteboard At each time, only one user has the right to modify a certain model element, but all users see the modifications in real-time. Elements owned by a user must be accordingly marked to indicate that they can not be modified by other users willing to edit them.

Although most of today’s CASE tools offer support for a broad range of modeling techniques, most are very restricted with respect to their services and working modes. Only a small fraction of the current tools, like Software Through Pictures [6] or objectIF [7], offer support for generic scripting or for consistency checks [8], for example. Commercial tools without a generic, meta-model-based repository, like Rational Rose [9] or TogetherJ [10], usually consist only of more or less sophisticated graphical editors and some functionality for code generation and reengineering of existing software. The situation with meta-CASE tools is similar. Most of them concentrate on mechanisms and formalisms for meta-modeling, support for different methodologies [11, 12, 13] and the rapid generation of specialized graphical editors [14, 15]. It is, therefore, an interesting point to design a CASEtool repository that integrates aspects from meta-CASE tools with support for different working modes and multiple users. The requirement of adaptability to various meta-models, description techniques, and different working modes suggests the use of a flexible architecture and requires a well-structured software development approach. Note that a flexible, extensible architecture has also positive impacts on the interoperability with other tools and on tool integration [16]. However, this aspect is not in the focus of our approach, as it concerns not only the architecture of the repository, but of the whole CASE tool, and because there exist already some standards in this area, like the ECMA reference model [17].

3 Overall Architecture The design of a repository for a generic distributed multiuser CASE tool is a very demanding task because the repository mechanisms—among them support for persistence, locking, versioning, and short and long transactions—must be carefully coordinated and harmonized. In the following, we present a component-oriented architecture that is structured according to three dimensions, which are explained in more detail in Section 3.1: The meta-model is built as a framework of interfaces derived from some abstract, generic modeling concepts.

Meta-model elements are separated into a model part and the corresponding view parts, to support different representations of a single modeling entity. The components providing the standard mechanisms and services of the system are kept separate from the meta-model entities in order to be able to exchange and adapt them without changing the meta-model. The additional requirement of support for multiple users requires a further level of structure, explained in Section 3.2. Here, the connection of the user clients to the repository and the architecture of these clients is presented.

3.1 Extensible Meta-Model Framework and System Mechanisms As already mentioned, the first main goal of the redesign is to make AUTO F OCUS a flexible toolkit with adaptable meta-models and description techniques. Furthermore, the mechanisms working on top of the meta-models shall also be extensible and flexible. To achieve these goals, we distinguish between two main kinds of components with respect to the dynamic instantiation and connection structure of component instances: Herd Components can be created, deleted, and connected under the control of the system. Herd components model the application’s changing meta-model data, but may also represent volatile and dynamic technical entities like the dialogs of the system’s GUI. Manager Components form the static architecture of a system and fulfill the task of organizing the herd components. An example is the system’s dialog manager keeping track of all actual dialogs. Manager components are often singletons. Figure 2 illustrates parts of the herd and manager components in the context of the AUTO F OCUS repository. The herd components on the left side represent the description techniques of various modeling languages. They are derived from abstract interfaces, like, for example, Entity, Relation, Lockable, or Versionable. At runtime, each modeling construct, for example, a graphically represented state or transition, is a herd component managed by the system’s manager components visualized on the right side. The herd components are split up into two kinds of components: All MetaModelElements components are observed by a number of MetaModelViews components. The latter realize the meta-model interface of the repository. Hence, if clients need access to an instance of a meta-model for editing or viewing, they have to use the interfaces provided by

the MetaModelViews components. These views observe their corresponding model elements according to the socalled Observer pattern (cf. [18]). Therewith we can provide several representations for one meta-model concept. A MetaModelElements component representing a state automaton may, for example, be represented as in form of an UML state diagram (UMLStateDiagram) [19] as well as in form of an AUTO F OCUS state transition diagram (AFStateTransitionDiagram). We also can change the meta-model or add new meta-model variants to the framework without changing the interface of the repository. The new meta-model components just have to support the corresponding interfaces, like, for example Entity, Relation, or Observable. By doing so, they automatically take part in the functionality and basic mechanism provided by the manager components. The mechanism part consists of various manager components (shown on the right side of Figure 2) providing the more advanced functionality of the system that cannot be assigned naturally to single herd components. Managers are typically singleton components—there is only one manager of a kind in a system. An example for a manager is the DocumentManager organizing the Document components or the TransactionManager responsible for creating, managing, and deleting transactions. The functionality implemented by the manager components is offered to clients via corresponding service interfaces, e.g. DocumentService or TransactionService. New managers can be added easily if they are orthogonal to existing mechanisms. Otherwise, the resulting interactions and overall mechanisms must of course be carefully designed. An example for a non-trivial dependence between two mechanisms can be found between versioning and locking. One can not create a new version branch from a document locked exclusively by someone else, so versioning depends on locking and we need to coordinate their managers following a global strategy. To sum up, the presented framework for the meta-model and mechanisms of AUTO F OCUS has the following three benefits: 1. One can easily extend the meta-model by introducing new components. The new parts of the meta-model are automatically accessed by the manager components because they support the abstract interfaces. 2. One can easily add new manager components to extend the system’s functionality. Via the abstract interfaces, these new Manager components can handle all kinds of meta-model elements. 3. One can easily add new description techniques on top of the meta-model elements. These components are

Figure 2: Repository Architecture of the Meta-Model and the Services connected via the Observer pattern to the MetaModelElement components. Of course, standard implementations for some interfaces can be provided, like for Entity or Relation. Hence, if one wants to extend the meta-model elements or their corresponding views, the new elements do not have to be implemented from scratch.

3.2 Multi-User Support The second main goal of the redesign of AUTO F OCUS is to support multi-user access by providing a GUI component for each user of the CASE tool. To connect the GUI components, we extend our architecture, as Figure 3 shows: We connect the ViewElements components of the GUI components with the herd view components of the repository. Again, this is done according to the Observer pattern, so that the herd view components must provide the Observable interface and use the Observer interfaces of the GUI components’s ViewElements. Hence, if one user edits a meta-model element, all other users get notified about the changes. As a result, all users have access to the actual meta-model data. Technical mechanisms like LockService or VersionService are used by the Viewers and Editors of the GUI component to provide different working modes for the user.

Examples for concrete ViewElements are graphical representations of document-level model elements as well as basic graphical elements like lines or ellipses that correspond to model elements like transitions or states. The Viewers and Editors components use the Draw interface of the ViewElements to let them draw themselves. Additionally, user events like mouse clicks may also be directed to the ViewElements over HandleEvent interfaces. The Viewers and Editors components have to support the different working modes to the user. To do this, they use the different services of the Manager components to provide three different access modes for each MetaModelViews component, which can be choosen by the user according to the overall work strategy: Read Access indicates that a user reads a certain model element (‘reading’ means in this context that the user has opened an editor with a representation of the model element). Multiple simultaneous users with read access to a single element are possible. Write Access corresponds to the exclusive whiteboard working mode. A user with write access has the exclusive right to modify a model element. Although only one simultaneous user with write access to a single element is possible, there may additionally exist many users with read access. Exclusive Access corresponds to the checkin/checkout working mode. A user with exclusive access has the right to modify and read a model element. As the name indicates, there must not be other users with access to

Figure 3: Connection of GUI Components to the Repository a model element that is accessed by a user with exclusive access. Access modes are not a purely technical concept because they must be visualized to the user in some form. A possible, straightforward implementation will use the technical concept of locking, as described in Section 4.2.

4 Design of the System Mechanisms In following sections we will discuss the design of the basic technical mechanisms, like versioning, archiving, and locking.

4.1 Persistence and Archiving Our archiving concept comprises two separate areas, namely, the archive with old, immutable versions of model elements, and the shared workspace with the actual, “live” model elements that are worked on by one or more users. MetaModelViews components are also stored persistently because one has to keep, for example, the geometry information pertaining to each view. New versions of model elements are created only on user demand, not on every user edit action. Once a relationship between model entities has been archived (which implies that the related entities are

archived, too), it cannot be modified or removed anymore. However, relationships involving entities from the workspace can be altered. The conditions under which new relationships can be introduced depend on the meta-model; we have, therefore, decided not to provide additional support for them in our framework architecture. We have not introduced a delta mechanism for storage space efficiency into our design because we think that would be a premature optimization at this time—all versions of model elements are considered to be full-blown persistent components. Persistence is handled transparently by a persistent object system like PJama [20], the CORBA persistence service [21, 22], or an ORB/OODBMS combination. We are currently working on combining the Versant OODBMS [23] with Iona’s Orbix CORBA ORB [24], as this approach offers transparent persistence and standardized remote access. Concerning the repository architecture, we have included a specialized manager component responsible for managing all archived model and view elements. Components and interfaces:

ArchiveManager: This manager maintains model elements in the workspace as well as those already archived. Additionally, it answers global queries like, for instance, “Return all actual model element versions as of February, 1st.” in cooperation with the version manager (see Section 4.3).

4.2 Locking and Checkin/Checkout As explained in Section 3.2, on of the main goals of the AUTO F OCUS redesign is to support different working modes. These working modes are based on different access modes: read access, write access, and exclusive access. In the following, we present a simple concept for lock management, where read, write, and exclusive access modes are realized by read, write, and exclusive locks, respectively. The final implementation may not necessarily be based on this locking concept, but may resort to a built-in locking mechanism of the used persistence platform (see above). As with versioning (cf. next section), not all model elements must be necessarily lockable. However, all nonlockable low-level elements must be encapsulated in and handled by lockable document-level model elements, and there should be no relationships to them from model entities outside of this encapsulating document-level element. The lock granularity must be defined by the meta-modeler. Apart from the implicit propagation to encapsulated lowlevel elements of a document-level element, the metamodeler can choose to propagate the lock to other model elements. An example arises in the context of AUTO F OCUS hierarchical state diagrams. Here, the meta-modeler could implement a locking strategy where a lock set on a single state locks also all subordinated sub-states and their transitions recursively. Locks cannot be set on single attributes of model elements—if a meta-modeler wants to have very fine-grained locking control, he or she has to choose adequately fine-grained meta-modeling concepts. As with versioning, view elements are not locked themselves. Their locks follow the locks of their viewed model element. Locks can be used to implement the separation between archive and workspace elements by allowing the ArchiveManager to achieve write locks to the archived model element versions that it never returns. Components and interfaces: Lockable: Interface for herd model elements, must be implemented by all lockable model elements. Contains functionality for setting and accessing information about each of the locks of a single model element. Lock: Interface for the three kinds of locks. Allows access to information about the kind of the lock (read/write/exclusive), the user who owns the lock, and the time at which the lock was created. Lockmanager: Manager component, responsible for complex queries concerning locks (e.g. “Which state

transition documents has user ‘Paul Quargl’ open for reading?”), and for locking whole hierarchies or transitive closures of model elements with the help of navigation managers.

4.3 Versioning of Model Elements We have not yet included a versioning concept into our design because we think that the actual concept should be tailored to the versioning concept of the persistency mechanism used. We want to stress that, usually, not all model elements are versioned. However, all non-versioned element must be encapsulated in and handled by versioned model elements, and there may be no relationships to them from entities outside of this encapsulating model element. Additionally, relationships between versioned model elements are usually also versioned, especially if they carry application information. As with locking, this leads to a two-leveled structure with document-level model elements that can be versioned by users, and low-level model elements contained in the document-level elements. View elements are, like low-level elements, not versioned themselves; their version follows the version of their viewed model element. Possible components and interfaces: Versionable Interface for herd model elements, must be implemented by all versioned model elements. Contains functionality for storing and accessing version information of a single model element, and for navigation to the predecessors and successors in the version history. VersionManager Manager component, responsible for implementing a version numbering scheme, for realizing complex queries on the version history (e.g. “Return a certain version of a certain model element.”), and for performing complex changes on the version structure (e.g. creating a snapshot of the most recent versions of all elements).

4.4 Transactions and Undo/Redo Users can control a CASE tool in various ways. There will usually be interaction via menus, dialogs, mouse actions in graphical editors, or even via automation facilities like scripting languages (cf. next section). All of these interactions can be captured using the concept of commands as introduced in [18]. Apart from providing a single, powerful abstraction for all kinds of user interaction, commands offer support for undoable and redoable actions.

In the context of a multi-user tool, where many users access a set of shared resources, we also need a facility for coordinating the user commands. This can be done most easily by encapsulating each critical command sequence in a transaction. The choice of transaction granularity and generally the implementation of the single command transactions is not part of our architecture; it must be designed according to the intended working mode by meta-modelers and methodologists extending the framework. The shared whiteboard working mode would, for example, lead to very fine-grained transactions on the level of single mouse actions. We do not intend to program support for transactions by ourselves because components for this purpose are already available: The persistence mechanism PJama [20] or CORBA’s transaction service [21, 22] are possible alternatives here. We have not yet decided which alternative to choose, as this requires extensive evaluation. Components and interfaces: Command: Interface for all kinds of actions that can be performed by the users. Contains functionality for execution, undo and redo. Transaction: Derived from Interface for commands accessing shared resources. Contains functionality for commit and rollback, as required by the underlying transaction mechanism.

5 Distribution Design Distribution design is concerned with the partitioning of the data and functionality of a system on a network of physically or logically distributed computation nodes. Our intended, typical target architecture is a powerful central server with some Java-capable clients. For this configuration, we chose to centralize as much data and functionality as possible on the server, leaving only the graphical user interface data and functionality on the distributed clients. The reasons for this decision were: Specification model information can not easily be assigned to a single client. Especially in the shared whiteboard working mode, many users must access the same elements. Centralizing all information on the server keeps the communication patterns simple. It also avoids the necessity for object migration of model elements from one node to another. The single elements of the specification model are strongly interconnected. If some of them would live

on the clients, this would result in many remote references and in complicated reference structures between the clients. If all data is held on the server, all references between model elements can be implemented by server-local Java references. Queries and global operations that need the whole specification model can be executed efficiently on a central server. Data security and access control is easy with a central server. The main disadvantage of the proposed distribution architecture is that the load on the network connections between the clients and the server is high. Each user interaction usually requires some calls to server components. However, we think that a first implementation should not contain premature optimizations that would complicate the overall architecture. If they turn out to be necessary in certain areas, such optimizations can be added later on. A possible extension would be to add other servers for special tasks to this architecture. This makes sense, for example, for functionality like automated proof support via model checkers or theorem provers. These tools are usually large, not very portable legacy components that need fast computing servers to perform adequately. Wrapping their functionality in a remote interface would allow to connect them to AUTO F OCUS or other tools. The technical realization of the distributed communication can be done via a distributed programming mechanism. We have evaluated RMI [25] for that purpose [26] extensively and will evaluate also CORBA for Java [27]. Both approaches in principle seem suitable for inclusion as communication infrastructure into our system.

6 Conclusion Currently, only parts of the system architecture proposed in the previous sections are realized. Although the current version of AUTO F OCUS provides a working environment that is sufficient for small projects, most of the work for the redesign remains yet to do. This pertains not only to the actual coding, but also to the elaboration of the proposed design. Existing base techniques and components— especially for transaction management, persistence, and distributed communication—are currently evaluated, interface signatures must be defined, and a prototype will be built to show the viability of the approach.

References [1] M. Broy, F. Dederich, C. Dendorfer, M. Fuchs, T. Gritzner, and R. Weber, “The design of distributed systems - an introduction to FOCUS,” Tech. Rep. TUM-I9202, Technische Universit¨at M¨unchen, 1992. [2] F. Huber, B. Sch¨atz, A. Schmidt, and K. Spies, “Autofocus - a tool for distributed systems specification,” in Proceedings FTRTFT’96 - Formal Techniques in Real-Time and Fault-Tolerant Systems (B. Jonsson and J. Parrow, eds.), pp. 467–470, LNCS 1135, Springer Verlag, 1996. [3] F. Huber, S. Molterer, A. Rausch, B. Sch¨atz, M. Sihling, and O. Slotosch, “Tool supported specification and simulation of distributed systems,” in Proceedings International Symposium on Software Engineering for Parallel and Distributed Systems (B. Kr¨amer, N. Uchihira, P. Croll, and S. Russo, eds.), pp. 155– 164, IEEE Computer Society, Los Alamitos, California, 1998. [4] Metamodel.com, “Metamodel.com homepage http: //www.metamodel.com/,” 1998. [5] U. Borghoff and J. Schlichter, Rechnergest¨utzte Gruppenarbeit. Springer-Verlag, 1995. [6] Integrated Development Environments, Software Through Pictures, http://www.ide.com, 1998. [7] microTOOL GmbH, objectiF, microtool.de, 1998.

http://www.

[8] F. Huber, B. Sch¨atz, and G. Einert, “Consistent graphical specification of distributed systems,” in FME’97: 4th International Symposium of Formal Methods Europe (J. Fitzgerald, C. Jones, and P. Lucas, eds.), no. 1313 in Lecture Notes in Computer Science, Springer, 1997. [9] Rational Rose, Rational Rose, http://www. rational.com, 1998. [10] Object International Software, TogetherJ, http: //www.oisoft.com, 1998. [11] D. Mehandjiska-Stavreva, D. Page, and M. D. Choi, “Meta-modelling and methodology support in objectoriented case tools,” in Proceedings of OOIS’96, Springer-Verlag, 1997. [12] M. Jarke, “ConceptBase home page, http:// www-i5.informatik.rwth-aachen.de/ cbdoc/cbflyer.html,” 1998.

[13] M. Consulting, “MetaEdit home page, http:// www.jsp.fi/metacase/metaedit.html,” 1998. [14] L. Software, “What is MetaCASE?, http://www. ipsys.com/mc-wp.htm,” 1998. [15] J. Brant, “HotDraw home page, http://st-www. cs.uiuc.edu/users/brant/HotDraw/Hot Draw.html,” 1998. [16] J. Grundy, J. Hosking, and R. Mugridge, “Experiences in using java on a software tool integration project,” in Proceedings of SE:E&P’98, IEEE Press, 1998. [17] T. E. C. M. Association, “Reference model for frameworks of software engineering environments,” 1993. [18] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [19] U. Group, “Unified Modeling Language,” Version 1.1, Rational Software Corporation, Santa Clara, CA95051, USA, July 1997. [20] S. M. Laboratories, “PJama Release 0.3.4 (for JDK 1.1.4), http://www.sunlabs.com/ research/forest/opj.main.html.” [21] O. M. G. CORBA, “OMG website, http://www. omg.org.” [22] R. Orfali, D. Harkey, and J. Edwards, Instant CORBA. John Wiley & Sons, 1997. [23] Versant Object Technology, Versant Home Page, http://www.versant.com, 1998. [24] Iona Technologies, Iona Home Page, http://www. iona.com, 1998. [25] SUN Microsystems, RMI – Remote Method Invocation, http://java.sun.com/products/jdk /1.1/docs/guide/rmi, 1997. [26] K. Bergner, A. Rausch, and M. Sihling, “Casting an abstract design into the framework of Java RMI,” in Proceedings of SE:E&P’98, IEEE Press, 1998. [27] R. Orfali and D. Harkey, Client/Server Programming with Java and CORBA. John Wiley & Sons, 1997.