The construction of models and by their means processing particular information is nowadays a common procedure. Depending on the domain, the purpose and the underlying meta-model, the resulting instance models are "by definition" more or less complex. We use the classification of model hierarchies and language levels according to Kühn [11,p 32]. As we speak of instance models we think of graphical models and refer to the distinction of different types of models [9,10,8]. The end user of the metamodel, let"s call him/her modeller, will use the modelling method at hand ideally in terms of the method engineer. In addition s/he will shape and refine the information to be conveyed with the instance model in the best possible way. This task is in general at least twofold.. Firstly, there is the design of the model and secondly, there is nearly at all times the need to consider further concinnities, like additional model descriptions in natural language, time-related data, necessary skills during processing, or applicable forms or regulations of the model. In fact the effort spent for the latter varies depending on the purpose and the target group the instance model is designed for. This demands flexibility from the underlying meta-modelling platform, in concrete for the case study ADOxx ® . Although there are already a number of solutions available providing an implementation of this method [2], the crucial distinction feature in this study case is that the design and realization of the i* method [6,16,19] is based on a meta-modelling approach, as described in Section 2. Section 3 is devoted to lessons learned. Section 4 concludes the paper and gives an outlook on further research questions to be addressed.
In this case study the i* method on one hand and the ADOxx ® meta-modelling platform on the other hand have been used. The former provides a specification for the syntax, the semantic and the notation. The method concepts: actor, role, agent and position are subsumed under the term "intentional actor". Furthermore there are the elements goal, softgoal, task, resource and belief. These elements form the group "intentional elements". Connections comprise the constructs of a dependency link, association link, means-end link, decomposition link and contribution/correlation link [6,19]. On the other side the ADOxx ® supports the process of method customization and allows themostly graphical -creation, persistence, maintenance and usage of models. Further it offers functionality to freely define and configure arbitrary meta-models of modelling languages including the definition or adaptation of the corresponding procedures and mechanisms applicable to models. By means of these tools the method engineer elaborates the translation of the i* method into a conceptual model. The result of this development is a semi-formalised structure of the available modelling concepts and their dependencies. For the construction of graphical models the i* method also provides integrated mechanisms, especially to perform goal satisfaction evaluations, based on these models. For these mechanisms further requirements related in particular to the notation of the modelling concepts can be specified during the developing phase by the method engineer. In the following the focus lays on the elaboration of the i* conceptual model, in the translation part and the customization concepts, in the instantiation part [1].
The starting point for the translation is the ADOxx ® metameta-model which exhibits the structure for the matching of i* concepts. In the following selected concepts of this metameta-model are used to exemplarily demonstrate mappings between the method and the platform. The method engineer has to know these concepts in order to fulfil the intellectual process: to design a holistic view of the i* conceptual model (see Fig. 1.).
The first applicable concept is library. The library is a container to which all formalisms and constructs of an instance of a modelling language are assigned to. Yet, the meta-model possesses also a particular structure so that the assigned elements are not loosely arranged abreast on an equal level. The next step is to allocate the constructs of the modelling language to model types. The i* method comprises two different types of models, the strategic dependency model and the strategic rationale model. The model type is a modularisation element for the available modelling concepts of a method. Hence, a model type strategic dependency model groups for example all modelling concepts necessary to map strategic dependencies for a particular scenario. The modelling concepts are described with classes which are assigned to a particular model type. In ADOxx ® modelling classes, which are in the i* method, actor, agent, role etc. and for the relation classes, which are dependency link, association link etc. are distinguished.The different classes have particular properties. In this point the i* method gives the method engineer an opportunity of a precise formal description about the syntax of the classes by means of attributes. The only mandatory requirement of the platform is that each class, modelling class or relation class, has a name attribute, because technically speaking, it becomes a global identifier. We distinguish between class attributes and instance attributes. The differene between these two lay in the values the attribute can adopt. Class attributes are context neutral and not to be filled by the end user or modeller using the method after implementation. Instance attributes are context dependent and will be used by the modeller to capture data and convey certain information [11, p. 100]. The attribute type is determined by the value the attribute can adopt when using the method, i.e. which data should be captured. Beside commonly known datatpyes ADOxx ® additionally provides support for inter model references, expressions, tables, or programm calls to name some of them. This list can be extended for applying the algorithms and mechanisms on the instance models.
The instantiation should lead to a mapping between the ADOxx ® meta-classes with the i* modelling and relation classes. After this step the customizing effort can be determined. The customizing is conducted on the level of the modelling languageconsidering the notation, the syntax and the semantic -on the method procedure level as well as from the processing point of view within mechanisms and algorithms. For demonstrating the work which is involved is shown in an example concerning the customizing of the notation.
The i* method gives guidelines how the different classes look. It specifies the shape. Furthermore that for the modelling classes the value of the name attribute is displayed in the centre of the shape. The intentional actors can furthermore possess a boundary. The intentional actors are represented with a boundary, to express that all intentional elements within this boundary are explicitly desired by that intentional actor. For the relation classes association link and contribution/correlation link several type of links, for example if the association link is a "covers", "plays" etc. association, are specified. They are visualised with a respective label. This requirement can be fulfilled with the Graphrep formalisms which are provided by ADOxx ® . Fig. 2. gives an example of the actor specification and the realization in the ADOxx ® Graphrep. In analogy, the customization effort for syntactical and semantical requirements is fulfilled through ADOxx ® functionality. The version of the i* method which has been translated and customized on the ADOxx ® platform as described in the case study at hand is available on the open models platform.
The i* method provides a high degree of maturity in terms of method specification. Nevertheless, the mapping on the meta-modelling platform ADOxx ® showed that the offered platform functionality gives new input to further conceivable extensions. Suggestions for extensions rely on the analysis of instance models provided in different papers and can be structured by extensibility for syntax and notation as well as by interpretability [16,17].
Extensibility. The syntax is related to the notation as some attributes are only necessary for the "orchestration" of a certain graphical representation, for example that the actor is represented with a boundary. The actor boundary belongs to a very specific actor and if a boundary is required to express the delineated semantic, it should be possible that the modeller can activate and deactivate the boundary on the drawing area as needed. In ADOxx ® this can be done by defining an attribute, e.g. boundary and two possible predetermined values "with" or "without". Another extension concerns the colour as it is an important distinction element, to keep the available shapes and as a consequence their meaning apart, there is the suggestion to use coloured elements. The reason for this is that if the instance models are of a certain size they tend to become hard to overlook and to read. From the experience of working with end users and addressees of instance models we know that the rectilinear an instance model is mapped, the easier the reader picks up the content and the better s/he understands the scenario captured with it.
Interpretability. During the analysis phase of instance models it became obvious, that the two previously identified model types -strategic dependency model and strategic rational model -are candidates for applying the ADOxx ® view concept. As both types use most of the available classes of the i* method mutually. The latter refines the former entirely or only in parts by using the same instance objects. Hence, what in the i* method is expressed by two different types of models is considered as a view or mode in the meta-model of the ADOxx ® platform. Despite of using the mode concept at least one model type needs to be defined. The suggestion for a name of the newly specified model type is Intentional actors and elements model. As the name should be specific for the i* method and should convey as precisely as possible the context that should be documented with a strategic dependency model and a strategic rational model. The new model type has two modes, once the strategic dependency mode and twice the strategic rational mode whereas the former is defined as the default mode.
The explained lessons learned are concerning the conceptualization of a particular method. The deployment of the instantiated method is beyond the focus of the case study, although there are related technical questions the method engineer needs to answer in order to provide a "ready-to-use" tool. The ADOxx ® platform offers respective support for this task.
Instance models and with them the modelling method they have been created with are commodity, this is also valid for the i* method. There will always be the need for new methods or extended functionality of existing ones in order to convey information in the intended way. Once modelling methods are to be used by a broader group of people and drift off the initial inventing team it becomes advantageous if the method is supported by a tool. The more the modelling method avoids ambiguity in expressing certain information the more difficult it is to "translate" this modelling method and support it by a platform. From our experience one reason for that is that today"s meta-modelling platforms lack in providing the full range of required functionality. Further research on the side of meta-modelling platforms and furthermore on the end user side is essential. This even more if this is seen in context of the integration of different modelling methods. For the later this is a claim in form of a non-functional requirement with regards to the utilisation of the modelling method by the end user resulting in userfriendly handling and as a consequence user acceptance [5,18].
Acknowledgments. The authors thank all the colleagues from the University of Vienna and the Open Models Community for helpful discussions and comments during the realization of this case study.