DIAGRAM DEFINITION FACILITIES IN A GENERIC MODELING TOOL Lelde Lace, Edgars Celms, Audris Kalnins {Lelde.Lace, Edgars.Celms, Audris.Kalnins}@mii.lu.lv The foundation of a generic modeling tool is its flexible diagramming facility. The paper proposes a new method for declarative specification of such facility. The proposed method permits to build up several diagrammatic presentations from one domain. The main principles of the proposed method such as mapping, presentation metamodel and some other details of the method are explained. 1 Introduction Today there are a lot of modeling tools on the market. Modeling tools are designed to provide all what is necessary to support major areas of modeling, including business process modeling, object-oriented and component modeling with UML [1], relational data modeling, and structured analysis and design, etc. Why it is not sufficient to use “hard-coded” modeling tools? Let us consider for example the situation in business modeling. On the one hand there exist several well-known business-modeling languages (IDEF3 [2], ARIS [3] etc), each with a set of tools supporting it. But there are also Activity diagrams in UML, whose main role now is to serve business modeling. There is also GRADE BM [4] – a specialized language for business modeling and simulation. Thus for the area of business modeling there is no one best or most used language or tool, each of them emphasizes its own aspects. The problem with flexible modeling environment is even more urgent for domain-specific modeling, where countless special notations are used for separate domains. There are probably several ways to solve such problem. You can develop a modeling tool specially for any specific modeling method but this way can be very time and cost consuming. You can make a tool, as universal as possible to support all needs but in practice such a universal tool is difficult for use in simple cases. An alternative way is a completely metamodel-based generic modeling tool (previously called metaCASE). Such a tool has no built-in modeling methodology. It has to be filled up with a specific metamodel and additional information to start modeling something. Such approaches (metamodel-based) are proposed by ISIS GME [5], DOME [6] and Moses [7] projects. Several commercial modeling tools (STP by Aonix, ARIS by IDS prof. Scheer etc) use a similar approach internally, for easy customization of their products, but their tool definition languages have never been made explicit. Perhaps the richest diagram definition possibilities of them are in GME. According to the GME method the configuration is accomplished through metamodels specifying the modeling paradigm (modeling language) of the target domain. The modeling paradigm contains all the syntactic (defined by UML class diagram), semantic (defined by MCL – a subset of OCL, with some specific extensions), and presentation information regarding the domain. The presentation information is specified by assigning to the domain classes and relationships some special predefined kinds of stereotypes (e.g. <<model>>, <<atom>>, <<connection>>, etc.). In that way the domain classes are mapped to GME modeling objects. This means that the domain metamodel is modified during the specification process and there is no possibility to define various presentation notations for the same domain (for example, UML Sequence and Collaboration diagrams). Perhaps this method is sufficient for creating environments for domain-specific modeling in the engineering world but it is not good enough for the generic diagrammatical modeling environment. The approach explained in this paper is in a sense a further development of the above-mentioned approaches. In our approach at first the domain metamodel of the modeling area is built independently of the diagram definition elements, which are built later and mapped to it. It should be emphasized that the domain metamodel itself is never modified during this process and remains a separate fragment, with only new associations attached. 2 Use of metamodels for editor definition What does it mean to define an editor for a new diagram type? The result should have the same functionality as a “hard-coded” editor that would be made for this type of diagram. The result also has to conform to the modeling paradigm of this diagram. The paradigm consists of syntactic, semantic, presentation and interpretation specifications. The main goal of our approach is to solve the following problem – to enable building of several diagrammatic presentations from one domain (for instance, UML Sequence and Collaboration diagrams). Our approach has the following basic principles. First, Graphical Diagramming Engine is built as a separate component. Second, the domain metamodel is extended with other parts. Third, a new concept of Mapping (from one part of metamodel to another) is introduced, with its own syntax and semantics. Our approach is described in detail in following chapters.