Deliverable D.A1.5.2 Collaborative Modeling Platform 1st Prototype Work Package A1.5

Transcription

1 Programme Integrating and Strengthening the European Research Strategic Objective Networked businesses and governments Integrated Project / Programme Title Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application Acronym ATHENA Project No ATHENA Project Name Enterprise Modeling for Collaborative Enterprises ATHENA - Project No A1 Deliverable D.A1.5.2 Collaborative Modeling Platform 1st Prototype Work Package A1.5 Leading Partner: Troux Technologies AS Contributors: Fraunhofer IPK, ESI, Itrec, DFKI Security Classification: Public July 2005 Version 1.0

2 Document Deliverabile D A1.5.2 Date Contribution History Company Description Date Troux 0.5 version based on WDA IPK Moogo client description DFKI Aris client description ESI UML client description Itrec Grai client description Troux Collected and reformatted all input to v ESI Updated UML client description DFKI Updated ARIS client description IPK Updated Moogo client description Troux Updated consolidated version Troux Updated based on internal review by John Krogstie, SINTEF Troux Updated based on internal review by David Chen, Uni. Bordeaux Troux Updated based on external review by Anthony Kitchin, Troux Troux Updated based on external review by Wasim Sadiq, SAP _ATHENA_DA152_V10 PUBLIC Page ii / 132

3 Document Deliverabile D A1.5.2 Date Table of contents Executive Summary Introduction Objectives Links to Other Activities The Structure of this Document Usage Scenarios and Requirements Usage Scenario: Automotive Testing The Role of MPCE in the Scenario Model Interoperability POP* - Multiple Dimensions Interoperability through Modeling Reflection Multiple Meta-Layers Model Exchange through the EKA EKA Concepts EKA Features and Capabilities Related Approaches Semantics and Usage of the EKA Inheritance Semantics Inherent Reflection Instantiation, Specialization and Classification Operational Semantics Object Creation Promotion of Objects into Reusable Types Aspect Orientation and Mix-In Inheritance in Local Views Dynamic Change Representation of Roles in Complex Relationships Language Definition Metamodeling Tool Specific Views Capturing Mappings between Metamodels Modeling Example - Process Exchanging the Visual Features of Models Scope for Version Coordinate system EKA XML Representation Namespaces Implementation MPCE Web Service Interface Error Handling Administration Services Modeling Support Services Repository Management Services Execution and Integration Services Metis Client Support Modeling Framework Process Modeling Language Implementation of Transformation, Import and Export _ATHENA_DA152_V10 PUBLIC Page iii / 132

4 Document Deliverabile D A1.5.2 Date GRAI Client Support Process Modeling Language Modelling Framework Mapping problems Implementation of Transformation, Import and Export Challenges for further work Rational Software Modeler Client Support Modeling Framework Process Modeling Language Implementation of Transformation, Import and Export Challenges for Further Work Mo2go Client Support Modeling Framework Mapping to POP* Challenges for further work ARIS Client Support Modeling Framework Process Modeling Language Implementation of Transformation, Import and Export Challenges for Further Work How to Integrate Another Tool Conclusions and Further Work References...7 Appendix A...59 Appendix B _ATHENA_DA152_V10 PUBLIC Page iv / 132

5 Document Deliverabile D A1.5.2 Date List of Figures Figure 1. Overview of the use of MPCE to support automotive testing Figure 2. Interoperability problems on different modelling layers Figure 3. Dimensions as multiple, mutually reflective meta-views... 7 Figure 4. Example illustrating the Subclass vs. Instance problem [22)] Figure 5. Example with three meta-levels different from most standard hierarchies... 7 Figure 6. Example with process and metamodeling aspects intertwined Figure 7. Logical model of the EKA framework... 7 Figure 8. Multiple levels of modeling as different views upon self-reflective objects... 7 Figure 9. Different relationship cases with and without explicit roles... 7 Figure 10. POP* process dimension modelled in Metis... 7 Figure 11. Arrangement of model and metamodel views in a typical scenario... 7 Figure 12. The Metis view on the POP* process dimension... 7 Figure 13. Links between tool specific views and the POP* standard... 7 Figure 14. Relationship matrix showing the mapping from Metis constructs to POP* constructs Figure 15. Example process model... 7 Figure 16. Another view of the example process, imported into Metis Figure 17. Core constructs for representing and exchanging visualization properties Figure 18. Concepts for visualization specification... 7 Figure 19. Simplified visualization scheme for version Figure 20. MPCE v.1.0 implementation architecture... 7 Figure 21. The conceptual architecture of the MPCE Figure 22. States in the lifecycle of a model view Figure 23. Example Enterprise Architecture model Figure 24. Example model in the Metis BPM language... 7 Figure 25. Example Process as GRAI Actigram Figure 26. GRAI process dimension modeled in GraiTools... 7 Figure 27. Rational Software Modeler IDE... 7 Figure 28. ESI customized Rational Software Modeler environment... 7 Figure 29. Resource diagram from POP* profile in Rational Software Modeler... 7 Figure 30. Main diagram from POP* profile in Rational Software Modeler... 7 Figure 31. ESI MPCE client screenshot... 7 Figure 32. Main views within MO²GO (Classes and Process Chains)... 7 Figure 33. Elements of MO²GO Process Chains... 7 Figure 34. System Delimitation by Object States and Design of Subprojects... 7 Figure 35. MO²GO meta-meta-model... 7 Figure 36. Example process model in MO²GO IEM... 7 Figure 37. EPC Model example Figure 38. ARIS EPC Metamodel _ATHENA_DA152_V10 PUBLIC Page v / 132

6 Document Deliverabile D A1.5.2 Date Executive Summary The objective of this work package is the development of a modeling platform for collaborative enterprises (MPCE). MPCE is defined as an integrated modeling and execution platform. The platform is to support the implementation of the collaborative enterprise modeling methodology (WP A1.4) and facilitate incremental and reflective definition of the common modeling constructs in POP* (WP A1.3). The primary objective for this deliverable, is the exchange of POP* process models between five enterprise modeling tools. This document does however contain the design of a general modeling framework for concurrent modeling, metamodeling and execution of any kind of enterprise models. The framework, called EKA (Enterprise Knowledge Architecture) enables languages and models defined through multi-dimensional, recursive, and mutually reflective views. The proposed solution consists of these open interface definitions XML schema for the EKA, inspired by the Resource Description Framework (RDF) Model repository web services for storing, retrieving and updating model and metamodel views expressed as EKA files In addition to the open specifications listed above, the deliverable also consists of the following software components, briefly described in this document: EKA services built on top of the Metis Team repository to support the MPCE web services (provided by Troux) Model and metamodel exchange between Metis and the EKA repository (provided by Troux) Model exchange between GRAI and the EKA repository (provided by Adelior Itrec) Model exchange between a POP* profile in the IBM Software Modeler and the EKA repository (provided by ESI) Model exchange between Mo 2 go and the EKA repository (provided by Fraunhofer IPK) Model exchange between ARIS and the EKA repository (provided by DFKI) Because the design choice made for the EKA are unconventional in some aspects, the document also contains brief descriptions of underlying perspectives, rationale, requirements and usage scenarios. More details, including XML examples and in-depth technical discussions, are found in the appendices. Although this report should be readable to anyone with basic knowledge in enterprise modeling, in-depth understanding requires prior knowledge of state-of-the-art in enterprise modeling and metamodeling approaches, as well as some previous A1 deliverables, in particular the definition of POP* languages. Details from these areas will not be repeated here _ATHENA_DA152_V10 PUBLIC Page 1 / 132

7 Document Deliverabile D A1.5.2 Date Introduction This document describes the software deliverable DA1.5.2 from the ATHENA A1 project. It contains the design and underlying rationale for the implementation of model exchange between 5 enterprise modeling tools, and the usage of the modeling platform to achieve business level shared understanding and interoperability among trading partners. 1.1 Objectives The objective of this work package is the development of a modeling platform for collaborative enterprises (MPCE). The primary objective of this document is to establish an Enterprise Knowledge Architecture (EKA) for full enterprise model exchange between Different companies Different disciplines Different functions and roles Different modeling tools Different modeling languages Different modeling paradigms and metamodeling architectures In this first version, the scope is limited to process model exchange, but the design should be easily extensible to cover other dimensions as well as local extensions to models and languages. Version 2, due M24, should extend the interoperability support to other enterprise aspects, in an object repository. 1.2 Links to Other Activities MPCE is defined as an integrated modeling and execution platform. The platform is to support the implementation of the collaborative enterprise modeling methodology (WP A1.4) and facilitate incremental and reflective definition of the common modeling constructs in POP* (WP A1.3). It should fill the gaps uncovered in the state-of-the-art analysis in WP A1.1 concerning model and object repositories, metamodeling and meta-data architectures, and model and knowledge management services: Handle unforeseen exceptions at the instance level, as well as instance evolution, in order to be able to adapt, reclassify and extend single model elements locally to resolve differences between views. Support multiple inheritance and instantiation, capturing multiple dimensions of an element, as well as aspects or facets used to extend the local meaning of a concept through mix-in inheritance, in order to enable interoperability between overlapping views from different business functions or disciplines. Enable reuse and evolution while preserving local autonomy through cancellation inheritance (allowing removal of inherited features). Support decomposition and specialization of properties into attributes, parameter trees and multiple value sets, and management of property structures. Enable relationships seen as more than simple one- or two-way links, by including roles and the underlying tasks and processes that sustain the relationships. The underlying perspective should be aligned with human knowledge, sense-making and communication, rather than software programming languages. Metamodels reflecting human understanding should be organised through mutually reflective views, rather than rigidly separated and ordered meta-levels. These features facilitate the representation and integration of multiple meta-views reflecting different perspectives, which is core to resolving interoperability problems. The MPCE and EKA concepts are therefore based on a perspective where every model is regarded as an incomplete and partial view. Interoperability problems can then be conceptualized as the lack of relationships between heterogeneous views on different meta-levels 1. The consequences for our research are: 1 The approach assumes that there is at least some overlap between what the different views represents. If we have two views describing two different companies, they can co-exists peacefully as _ATHENA_DA152_V10 PUBLIC Page 2 / 132

8 Document Deliverabile D A1.5.2 Date Requirements for a modeling architecture that facilitates mutually reflective views are not yet fully understood by the use case partners, so a scenario-driven joint experimentation process should be carried out. The EKA should be implemented and applied as a model and metamodel interchange format. The EKA should be defined inherently flexible, in order to allow any modeling framework to be expressed, so that interoperability problems may be addressed on the model, language and meta-language (modelling tool) levels. Rules and constraints may be added e.g. to ensure consistency among views, but such restricted interpretations should not be the default. Both the services of the MPCE and the EKA formats should be considered as candidates for standardization. Mapping tables should show how EKA constructs may be translated to MOF, RDF or OWL, and vice versa, in order to interoperate with existing standards. In longer term research, we see the need for addressing several open issues: Whether the EKA also can utilize metametamodels to achieve interoperability, and not just languages and models? What relationship types are needed for resolving heterogeneous views, and what task and decisions patterns that lie behind them? Which view types are needed for different purposes and what services should they include? Replication, reuse and other basic modeling services need to be detailed and implemented in a flexible manner. Inheritance rules should be defined in order relieve the users of having to define change scopes and reuse patterns manually every time they change a reused view [1)]. What negotiation, mapping and resolution services are useful for model driven interoperability establishment on top of the EKA? The scalability of an object repository for EKA structures also needs to be assessed. Integrated with the other projects and activities in ATHENA, this work contributes in the following ways: To the process modeling of A2, it brings language plurality and evolution support, To the semantic reconciliation techniques of A3 it brings a general enterprise ontology (POP*) and modeling language ontology (EKA), which extends RDF with emphasis on relationships, the core elements in enterprise modeling, and mutually reflective views in multiple meta-dimensions (process, organization, product, system etc.), providing a richer set of semantics links. To the elaboration of the Athena Interoperability Framework in A4, the EKA brings an operationalization of business level interoperability concerns, and as such it is an important part of the ATHENA solutions for interoperability. To the execution architectures of A6, the MPCE provides the repository for a concurrent modeling and execution platform, to be applied also in A7 and A8, To the pilots in B5, the MPCE brings modeling support services to be integrated with existing infrastructures services at each use case partner through the work A5 and A The Structure of this Document The document starts with defining the requirements to the MPCE, including motivating examples. Then, section 3 describes the concepts of the EKA, its intended semantics and the XML syntax used for model exchange. Section 4 describes the implementation of model exchange, starting with the web services offered by the MPCE repository. Each modeling tool that uses this repository is also briefly introduced, as well as the work done to integrate it with the repository. Finally, we outline experiences, conclusions and core challenges for further work. There are also five appendices, providing elucidation of key concepts (Appendix A), a survey of related standards (B), a link between the EKA and the Resource Description Format (RDF), practical XML examples (C), and server implementation details, including WSDL definitions (D). long as there is not need for interoperability between the companies, and thus no need for linking and or merging parts of the views _ATHENA_DA152_V10 PUBLIC Page 3 / 132

9 Document Deliverabile D A1.5.2 Date Usage Scenarios and Requirements The main technical objective of this document is to define an XML format for exchange of POP* models. The XML format should implement a modeling framework, called the Enterprise Knowledge Architecture (EKA) with these qualities: Simple, with few core concepts, Intuitive for business users as well as software professionals, Expressive, capable of representing models and metamodels with constructs such as objects, relationships and properties, and all relevant patterns of these constructs. Extensible, enabling exchange of locally defined as well as standardized concepts, and enabling the common POP* language to be kept as a simple core, rather than as yet another complete enterprise ontology. Multiple meta-views of an object, often called aspects or facets, should be composeable, and organized into classification structures and dimensions (e.g. POP*), Multiple perspectives on a model capturing the views of different companies, roles, and disciplines should be able to co-exist and evolve concurrently, Reflection: Any number of meta-layers should be allowed, and there should not be strict separation between layers. This would support that one man s floor is another man s ceiling, i.e. that my model may be your metamodel, in one or the other dimension (defining your process (P), the organizational roles involved in your work (O), the concept of the product you should develop (P), or the modeling types that you should use (System), etc.), Coherence: The same concepts should be applied at all meta-layers, removing the differences between instance data, models, metamodels etc. and facilitating end user modeling at all levels, Reuse of model fragments should be facilitated in a simple, yet powerful way. Any fragment should be reusable through propagation, inheritance, or delegation, while local autonomy should be preserved, in that elements may add, override or remove inherited specifications. The core motivation of this approach is to design enterprise modelling languages suitable for helping humans from different cultures, organisations, disciplines and backgrounds to understand each other. We assume that common understanding among the human actors of enterprises is the foundation for all enterprise and software interoperability. This implies that enterprise models should facilitate the processes through which people establish common understanding and terminologies. These processes are the object of study for the sociology of knowledge. Here we apply the theories of social construction of reality in communities of practice [11),21)] to derive requirements and ideas for the EKA. The core idea is that the semantic of modelling language elements is and should be contextual. Meaning depends on the location of the element in a particular web of knowledge. This perspective, called semantic holism [1)], directs attention to a number of suitable modelling and metamodeling techniques. These techniques have been developed and applied in our research into developing interactive, semi-automatic execution platforms for enterprise models [1)] since 1997, especially in the EXTERNAL project ( The approach leads to a rejection of these common assumptions about modelling: Completely shared understanding of a concept is possible. Models should be formal and precise. Models should be complete. Models should be consistent. A language should be defined as a set of classes. Modelling frameworks should consist of clearly separated meta-layers. A modelling element should be defined in an encapsulated object, independent of the context. Inheritance must be coupled to specialisation. Most of these assumptions describe an ideal end-state of the modeling process, where fully shared understanding is established, and there are no interoperability problems. Rather than designing for such an ideal end state, we should design for facilitating the process of reaching a sufficient shared conceptual understanding. Compared to most work towards the so-called semantic web, we are thus concerned with _ATHENA_DA152_V10 PUBLIC Page 4 / 132

10 Document Deliverabile D A1.5.2 Date pragmatics and real world semantics, establishing common understanding of the relationships between models and the business realities they represent, and operational semantics (how models are manipulated and managed by modeling tools, exemplified by their underlying meta- and metametamodels). Formal semantics, establishing links to mathematical and logical frameworks and algebras, is the domain of A3, and will not be dealt with in this report. 2.1 Usage Scenario: Automotive Testing This scenario (cf. D.B4.3) concerns the Virtual and Physical Testing process during collaborative product design. From a business perspective, the OEM has to define Technical Objectives (engineering specifications), therefore a set of Tests must be performed by the Supplier that by means of own laboratories must provide test results. These Test Results are Technical Objectives that Target Setting must reach. The open issues (problems) in this case are: Not homogeneous and disaggregated user interfaces: different technologies (Web, Client/Server, 3270) and different usability; Business Processes hardcoded in applications: business process changes require high costs and long development times for the ICT alignment; Distributed inconsistent data, Enterprise master data (customers, products, orders ) are spread in many databases, which brings possible inconsistency problems, and the need for periodical data alignments that generate latencies in business process executions. The two relevant aspects emerged were: The difficulty of using a common language, required e.g. by EDI, and demanding both systems to manage this common language. The execution of the collaboration process should, at the systems/applications level, bind the appropriate services while transforming information from the semantic of user A to the semantic of user B. Business processes are often hardcoded in programs. Applications focus on transactions, not on business processes. From these aspects a list of interoperability issues were identified: Data Format Interoperability: ability of a process/application to exchange data with one/more partners by means of a common data format or via a mapping between the proprietary format and an intermediate common format, Process Interoperability: ability of a process or application to make "visible" the requested services/interfaces and the offered services/interfaces, Distributed inconsistent data: ability of a solution to guarantee data consistency and distributed data alignment in a virtual enterprise context; (Several versions of same objects like Product, Customer, etc), Business Processes hardcoded in applications: improvement of application deployment in terms of business internal Time to Market and high programming code reuse level Applications focus on transactions, not on business processes: use of graphical tools to manage process parameterisations and process management in a virtual enterprise context, gaining programming activities reduction/reset (code implementation) The Role of MPCE in the Scenario In applying the MPCE to the automotive testing scenario, we created a situation where the OEM uses one tool to model the test procedures (in Figure 1 Metis), and the test supplier another (in Figure 1 Mo 2 go). The users of the automotive testing scenario can then expect these benefits from the MPCE: Adaptation of the test procedures, so that business processes are no longer hard-coded o Transparently improve common understanding o Rapidly the process can be changed more dynamically Learning from experience with local changes for an individual test, controlled deviation from the normal procedure. Today it takes 6 months to change the entire procedure, because local changes are not tolerated by the system o Easy reuse of procedure definitions for similar tests, because they are available as structured, visual models _ATHENA_DA152_V10 PUBLIC Page 5 / 132

11 Document Deliverabile D A1.5.2 Date Suppliers are able to perform tests for different OEM o Using their own tools, not the different tools demanded by different OEMs Business interoperability can be established through negotiation about the content and procedure of the work, facilitated by the exchange of visual models. Partially overlapping views on data can be exchanged, representing e.g. the perspectives of two trading partners or two functions in an organization. The MPCE will not enforce partners to use a complete common language and nothing else. Internally, shared views can be merged with more comprehensive internal models. Focus on business realities rather than just technology, fostering business interaction. Figure 1. Overview of the use of MPCE to support automotive testing. 2.2 Model Interoperability Figure 2 shows two enterprises that apply modelling tools with some language to define models, which are exchanged using an XML format. Interoperability problems can be found on all levels in the figure: Incompatible data encoding formats (e.g. XML Schemas or character encoding) Different identification and representation schemes in instance models (e.g. scope and granularity), Different modelling languages (e.g. BPMN vs. IDEF), Different modelling tools with incompatible metametamodels and modelling frameworks (e.g. instance-oriented vs. class-based, MOF vs. OWL, Metis vs. ARIS). Even though two companies (or two persons) use the same tools and languages, their modelling focus and style may be different, causing model level interoperability concerns. On the other hand, meta-language interoperability problems need not automatically cause language and model interoperability barriers. For instance, in the instance-oriented modeling tool Metis, UML classes are represented as Metis objects, enabling full interoperability between Metis and UML. Our approach reflects the fact that interoperability problems can exist on all levels, and that they are interrelated across levels. Therefore, we require a modelling framework that enables commonalities and differences between company A and B to be articulated at all levels, in a uniform way. Interoperability resolution will often benefit from investigating multiple meta-levels together. For instance, if we are trying to establish whether object a in view A and object b in view B refer to equivalent or overlapping concepts, we will benefit from assessing what language constructs in the _ATHENA_DA152_V10 PUBLIC Page 6 / 132

12 Document Deliverabile D A1.5.2 Date languages of A and B they are instances of. In order to address multi-level interoperability problems and to be able to construct customized and role-specific views, metamodeling should be an integral part of modeling, not just a specialist activity based on different tools and concepts from modeling. Type definition or selection should be at the control of the user, but controlled according to authorization and modeling phase. In order to fix these problems, many promote a standard format on one level, such as XML, XSD, UML, MOF and OWL. The existence of a standardized or common framework that the companies agree to use will make it easier to achieve interoperability. The standard format can be defined on the XML layer, as a common language (e.g. UML or BPEL), and/or as a meta-language (MOF, RDF, OWL or EKA). However, when a common language has been selected, both companies face the task of relating their views of data and models to the common framework. It is also known that a common language does not guarantee interoperability, e.g. because there are detailed semantics (one metalevel up) that are left implicit. The identity, precision and granularity with which objects are represented in a model view built with the common language, also depends on interpretation and pragmatic decisions by each party, and may thus cause interoperability problems even if a common language has been defined. Consequently, interoperability requires assessment of multiple meta-levels also in the presence of standards. Company A Company B Data of A (eg. XML) M0. Incompatible data formats Data of B (eg. XML) Objects of A Language of A M0. Incompatible representation and identification of elements M1. Incompatible languages Objects of B Language of B Metalanguage of A etc. M2+. Incompatible modeling architectures Metalanguage of B etc. Figure 2. Interoperability problems on different modelling layers. 2.3 POP* - Multiple Dimensions According to the POP* approach (which the MPCE is built to support), enterprises are described in multiple dimensions. In order to illustrate this, let us look at a product component, such as an electronic circuit board. It Has a process lifecycle (design, manufacturing, maintenance, recycling phases) Is handled by organizational roles and responsibilities (in different phases) Which require knowledge and skills And use systems, data, and software services Has product decomposition structure, and variant hierarchy Has timeline (expected lifespan etc.) Has physical and spatial properties (size, weight etc.) Has money parameters (cost, pricing etc.) Has decisions that controls it (e.g. select among alternative designs) _ATHENA_DA152_V10 PUBLIC Page 7 / 132

13 Document Deliverabile D A1.5.2 Date etc. These views are reflective and recursive, in that each view will consist of modeling objects that may themselves be described according to several of the same dimensions as the product component. These facet models are intertwined, so property values and objects will be present (or propagated) across the dimensions. Similarly, structures are often replicated between dimensions. For instance consider the rule that every major project activity should have a budget, which replicates a process structure into a cost structure. Given the large number of potential dimensions of large number of objects, a high degree of reuse is absolutely necessary. We have found that the multidimensional approach helps us to structure model and their metamodels into reusable fragments, combining instance flexibility, reflection, object-orientation, delegation, and aspect-orientation. The figure below shows four views that together comprise an enterprise model. There is however no central model that the views are abstractions of. Instead, the model is a composition of views. Relationships between views connect common elements that represent aspects of the same objects. A similar model could be shown where the views represent those of different ICT systems or different companies. In all these cases, the tasks and decisions involved in creating complex relationships between views is core to solving interoperability problems. Process Organization Complex relationships, tasks, decisions System Product Figure 3. Dimensions as multiple, mutually reflective meta-views. 2.4 Interoperability through Modeling In addition to enabling interoperability between enterprise modeling tools, the MPCE should improve the utilisation of enterprise models for achieving interoperability of business processes, applications, services, and data. Multiple views are also the core of these interoperability problems. Different individuals, groups and companies apply modeling tools with different capabilities, languages and meta-languages, in order to describe partially overlapping aspects of their joint and separate enterprises. These differences create interoperability problems on many levels (as depicted above). In general we cannot assume that different companies, groups or individuals use compatible concepts on any level [12)]. A modeling approach to resolving interoperability problems should thus not assume a single integrated objective model or metamodel. Instead it should facilitate the bringing together of any set of views. The process of establishing relationships between views, in order to achieve interoperability, consists of a set of translation and resolution tasks and decisions (cf. Figure 3). When integrated and related in this way, each view will deepen the interpretation of the other views; they will thus be mutually reflective _ATHENA_DA152_V10 PUBLIC Page 8 / 132

14 Document Deliverabile D A1.5.2 Date Interoperability is thus achieved through interaction [20)], where multiple users and automated tools contribute, as opposed to completely automated reasoning or purely manual transformations [1)]. In order to grasp these processes, we have examined literature on social negotiation of meaning between people and groups from different backgrounds [11),21)]. There we found that ambiguity is a prerequisite for establishing shared meaning, because even before sufficiently shared understanding is established, we need some common terms in order to communicate. Ambiguous terms allow us to speak the same language even though we don t interpret the terms exactly the same way. Formal languages, seeking to remove interoperability problems by providing precise semantics, prohibit the articulation of ambiguous concepts, and thus provide no support for negotiation of meaning. They are thus suitable for reflecting a closed world where no interoperability problems exist. They can document the outcome of interoperability through negotiation, but not support it. For interoperability support, we need an approach that tolerates ambiguity and uncertainty, but which also can express shared understanding precisely when that is achieved. 2.5 Reflection In order to understand some of the challenges of multiple views and reflection, consider the example slide below from an OWL tutorial. The slide illustrates that it is very easy to confuse subclassing and class membership for non-specialist users (and even for experienced meta-modelers who are only used to one framework, e.g. MOF/UML or OWL). The example also shows how different metamodeling choices, each equally correct, can be made, even though we are representing the same enterprise realities and applying the same terms. Figure 4. Example illustrating the Subclass vs. Instance problem [22)]. The author concludes that the proper relationship is instance-of for CabernetSauvignonGrape because he interprets Grape as the set of all Grape types rather than the just as intuitive assessment that Grape represents the set of all grapes. During the task of defining CabernetSauvignonGrape, he faces the problem which does not deal with the scope of this task; rather it involves the precise meaning of the previously defined Grape concept. The question is on what meta-level the Grape concept is defined. If the definition of Grape was precise in this respect, there would be no problem. Does this imply that we should demand more precise definitions of all concepts? Our answer is no. Typically, different people will hold different views on what is the proper representation in situations such as these. This is also an interoperability problem, if one company subscribes to interpretation 1 while another implements interpretation 2. In order to support mediation and communication across these conflicting perspectives, we must allow them to co-exist. We should not _ATHENA_DA152_V10 PUBLIC Page 9 / 132

15 Document Deliverabile D A1.5.2 Date design a modeling framework that only allows one interpretation, because it would make mapping to the local models utilizing the other interpretation difficult. Instead we should have model elements that possess a reflective dualism that can be interpreted as a class by one person and as an instance by another. One area where we encounter this problem, is the case when someone designs or plans the work of someone else, e.g. a software designer shaping the world of the user, the manufacturing engineer defining production processes to be executed repeatedly by the workers, or the quality engineer defining procedures to be followed across the organization. The objects that the designer sees as particular instances, are seen by the performers as classes. In our core model, we therefore should allow both of these interpretations of the Grape concept to co-exist, tolerating ambiguity. We should also allow Views to be defined that favor one interpretation, to serve different roles with what they need, while maintaining an integrated, agnostic model Multiple Meta-Layers The figure below presents a metamodeling framework with three layers (implemented by the MO 2 GO tool). Note that this is different from standard frameworks such as MOF and OWL, by adding another layer (state) to the conventional class-object structure. Class 1..n Inheritance based on rules Inheritance based on rules 0..n Multi inheritance might be possible. Object 1 0..n Inheritance based on rules State Figure 5. Example with three meta-levels different from most standard hierarchies. Figure 6 revisits the Grape example with a model in this framework. Here we see that the state concept adds a process dimension to the metamodel. This is an important case because instance evolution between classes (in this case represented as states) is common, yet poorly handled by most conventional modeling systems. The modeling framework should thus support this and other solutions that need different meta-level arrangements, and be able to resolve differences between the arrangements to achieve interoperability _ATHENA_DA152_V10 PUBLIC Page 10 / 132

16 Document Deliverabile D A1.5.2 Date Class Product Wine CabernetSauvignonGrape Fruit Grape Object Grape: Status: available press CabernetSauvig nongrape: Status: Most making wine CabernetSauvig nongrape: Status: young wine Figure 6. State descriptions Example with process and metamodeling aspects intertwined _ATHENA_DA152_V10 PUBLIC Page 11 / 132

17 Document Deliverabile D A1.5.2 Date Model Exchange through the EKA This section describes the core elements of the EKA, its features and capabilities. A brief comparison with existing modeling frameworks is also offered. Then subsection 3.4 provides guidelines for implementation semantics, e.g. inheritance and object creation, in greater detail. We also show how the EKA is applied to: Define a modeling language (a view representing a meta-model) Define a perspective as a tool-specific metamodel that extends and constrains the general language definition Define a simple process model example. Finally, the XML schema definition of the EKA format is provided. XML examples are found in the appendices. 3.1 EKA Concepts The core concepts of the EKA are shown in the diagram below. Figure 7. Logical model of the EKA framework. The core element of Figure 7 is Object. An Object may have Properties, and Relationships link two Objects through Origin and Target Roles. Relationships, roles and properties are also objects, so they may possess properties and have relationships to other objects. Objects, properties, relationships, and roles, together called elements, are contained within Views that express (partial) models. States make up the lifecycle of an object. As an explicit modeling object, a state represents the object in the situations where the state is active. A state may entail or be derived from a set of property values of the object. The EKA does not separate between meta-classes, classes and instances because this would make it difficult to handle and integrate any meta-layer structure. Instead, a special relationship called Is between two objects (or relationships or properties), denote that the origin is defined by the target, and can thus express both specialization (Student is Person) and instantiation (George is-a Person). The instantiation relationship Is-a shares most of the semantics of Is, but it is used to separate metalevels (for the modeling frameworks where this is required). Other relationship types include general links and associations, and decomposition with (Part) and without (Member) ownership. Relationships and properties have cardinality, and most objects/relationships/-properties should have Name and Description properties. Note that this approach enables classification, decomposition and states of properties, relationships and views just like objects. 3.2 EKA Features and Capabilities The EKA is inherently reflective; it makes no separation between meta-levels. Objects, relationships and property elements can be applied at any level. Inherent reflection also makes the EKA coherent, in that users apply the same modeling constructs and operations on any meta-level. They may perform metamodeling operations such as adding a property in the same way on _ATHENA_DA152_V10 PUBLIC Page 12 / 132

18 Document Deliverabile D A1.5.2 Date instances and classes, or for that matter relationship and property instances and classes. This facilitates instance level exceptions and evolution. Similarly, users may perform modeling operations on objects representing classes, e.g. adding default parts and property values. Multi-dimensional meta-views are captured as multiple Is or Is-a relationships from an element. This approach can also be applied to mix in new aspects locally. For instance, if a group wants to add a cost dimension to a process model, they simply add an Is relationship from Object to CostComponent in their model. All objects within the model will then inherit the properties and behaviour of cost components. Such extensions are local to each view. Multiple inheritance is controlled by Is and Is-a links between the properties of objects. These links articulate which properties are inherited from which super-class. This also opens up for reuse along other structures than classification and specialization, e.g. to have property hierarchies crosscutting the class hierarchy. Through reflection, we may define e.g. that a Part, Member or ordinary relationship is an Is relationship as well, enabling reuse along these dimensions. In previous work, we have discovered a number of scenarios where such inheritance is valuable for and intuitive to business users [1)]. We thus define inheritance as reuse along relationships, extending the conventional definition reuse along classification relationships [19)]. The expressiveness of the EKA satisfies the requirements listed in section 2. Basic elements such as objects, properties and relationships can be described uniformly on any level. Aspects or facets can be represented as objects, and reused through local Is links. Multiple inheritance allows not only aspects, but also interoperability between overlapping classification schemes. Because properties and relationships are first class elements, they may be defined and managed just like objects, specialized and decomposed. Properties can have an extensible set of properties themselves (meta-properties) that define e.g. how they are to be managed (e.g. readonly, derived, priority level ). The tasks and decisions involved in creating/selecting and maintaining a relationship may e.g. be defined as a process meta-view on the relationship. Even though the EKA is this expressive, its core is still quite simple compared to most other frameworks. This, together with coherent modeling constructs and techniques across meta-levels, implies that it should be usable for business people, given some training, and a suitable set of metamodeling services integrated in the modeling user interface. (More work is however needed in order to verify this.) Our previous experiences indicate that users are capable of both modeling and metamodeling, provided customized views are available for such tasks [1)]. The design and derivation of such views for different contexts will be a key challenge in our further work. We need to design general frameworks for typical view types, integrated in suitable methodology processes, in a manner which can be adapted to each customer s organizational maturity and individual skill levels (cf. work package A1.4). 3.3 Related Approaches Modeling frameworks such as MOF [5)] define a modeling language as a set of classes. The elements of a model instantiate these classes. Classes define the expected properties and behavior of the objects, and the relationships it can have with other objects. During several years of research and industrial experience with meta-modeling, we have seen the following problems with this model [1),14)]: It handles unforeseen exceptions at the instance level (such as the addition of a property or a relationship) poorly. It does not support instance evolution, where different classes may reflect different states in the lifecycle of an object [10)]. Multiple inheritance and instantiation is often prohibited, making it difficult to capture multiple dimensions of an element. Aspects or facets [16)] cannot be used to extend the local meaning of a concept through mix-in inheritance. Strict inheritance rules are too rigid for evolving systems, where cancellation inheritance is needed (allowing removal of inherited features) [19)]. Properties are treated as second class elements, existing only as part of an object. There is poor support for decomposing and specializing properties into attributes, parameter trees and multiple value sets, and you cannot classify or describe properties with properties, making it more or less impossible to manage property structures _ATHENA_DA152_V10 PUBLIC Page 13 / 132

19 Document Deliverabile D A1.5.2 Date Relationships are seen as simple one- or two-way links. The tasks and decisions that create and maintain a relationship cannot be captured, making it difficult to grasp the precise meaning and status of each link. Prior to defining this EKA framework we analyzed existing standards such as MOF XMI (Meta Object Facility XML Metadata Interchange) [5)], RDF (Resource Description Framework) [2)] and OWL (Web Ontology Language) [3)]. In MOF, we found the class-based model to be too restrictive, the meta-levels to be rigidly separated, and the support for property and relationship structures limited. MOF is also rather large and complex. MOF is well suited for interoperability between class-oriented modeling tools, but the EKA also needs to support instance, role, and aspect oriented frameworks. OWL and RDF schema better support property modeling, but treats reflection as an exception rather than an inherent feature, and has poor support for object creation. On the other hand, most of these frameworks, with the exception of basic RDF and OWL Full, enable automatic reasoning beyond what our flexible and user-oriented proposal cater for. More details about this analysis can be found in Appendix B. The EKA is inherently flexible, in order to allow any modeling framework to be expressed. Rules and constraints may be added e.g. to ensure consistency among views, but such restricted interpretations should not be the default. In Appendix B, we also provide mapping tables that show how EKA constructs may be translated to OWL and RDF, and vice versa, in order to interoperate with these existing standards. Interoperability between MOF and EKA is partially achieved through the implementation of the POP* profile in Rational Software Modeler as a MPCE client (cf. section 4.4). 3.4 Semantics and Usage of the EKA This section describes the semantics of core elements of the EKA, e.g. inheritance and object creation, in greater detail Inheritance Semantics Currently, Is captures inheritance/generalization/specialization, while the more specialized relationship Is-a is used to represent meta/instantiation structures (the RDF subclassof and type references, respectively). We do however not separate between object individuals and object classes, because we have realized that what one persons sees as a class, often appears as an instance to someone else (in another view). This is often expressed as one man s ceiling is another man s floor. This design is a consequence of our objective to allow multiple meta-levels and to let users mix specifications at different levels, e.g. allowing instance modeling and instance metamodeling. Consequently, object, property and relationship elements may refer to concrete individuals as well as generic types, classes, prototypes, stereotypes, or templates. We do however separate between Is and Is-a in order to facilitate structured model and metamodel management, through relative (relational), and potentially view-local separations between meta-layers using the is-a relationship. The general semantics of the Is and Is-a relationships is however the same. In the description below, we refer to the super as the target of an Is or Is-a relationship, and sub as the origin of the link. 1) Reified 2 children 3 elements (e.g. properties that have an explicit ID 4 of their own) can be referred to from the sub. This implies that their reuse can be managed explicitly by Is and Is-a links from the child of the sub to the corresponding child of the super. We will thus not make any implicit assumption about the inheritance of these elements. This implies e.g. that if the super has a property which no child of the sub refers to by an Is or Is-a relationship, then that property is not currently inherited by the sub. 2) Anonymous children elements of the super cannot be referred to by the sub, so their inheritance cannot be explicitly managed or overridden. This implies that we must decide on a set of standard inheritance rules for these elements. From a pragmatic point of view, we have settled on these rules: a) For properties, the name, datatype and value (inner text) is implicitly inherited from super-property to sub-property, i.e. if the sub does not contain any definition of these elements, the value from the 2 Reified elements are those that have an ID attribute and thus may be referred to from other elements. Elements without an ID attribute are called anonymous, because they cannot be referred to (or related to other elements). 3 Children elements here refers to the XML element hierarchy according to the EKA XSD. 4 An ID attribute uniquely identifies the element within a file. Other elements refer to the element through this attribute. When the ID is combined with the file URL, you get a globally unique URI for the element _ATHENA_DA152_V10 PUBLIC Page 14 / 132

20 Document Deliverabile D A1.5.2 Date super applies to the sub as well (lookup). The rationale is that these elements are mandatory and should have a single value. Lookup here simplifies the definition, e.g. of properties on instance objects in a model, where we would not like to have to include all of these elements for each individual property, but rather reuse from the object type definition. b) For objects (and views, states, properties and relationships), anonymous properties describe the object in itself, and should therefore not be implicitly inherited. For instance, the property Name=Superhero should not be inherited from the Superhero class to its Flying superhero specialization, nor to its Superman instance. Since we cannot attach Is or Is-a links to this anonymous property, the name, type and default value of the Name property should come from a meta-object or reusable property definition which all of these objects have Is-a links to. This general semantics does not make detailed commitments about what is inherited in which ways in different structures. This is intentional, because the EKA must be able to mediate, relate and distinguish between the meta-relationships of diverse modeling tools and frameworks, e.g. handle both MOF, OWL, MO 2 GO, ARIS, GRAI and Metis. While the specification of detailed semantics requires a rule language not yet defined, the core EKA structures must allow e.g. the owl:subclassof and the UML:Generalization to exist side by side, with different, but partially overlapping meaning Inherent Reflection The semantics above implies a reflective dualism of objects (and by extension relationships, properties, roles etc. as well). Any object can be seen both as an instance and as a class, or for that matter meta n class. The instance features are local, and thus captured by anonymous properties and is/is-a relationships. The class features are to be reused by instances (linked to this object by Is-a relationships), and are thus reified. Figure 8 below illustrates how this plays out in a multi-layered meta-hierarchy with specialization. In the language definition view, the language designer performs metamodeling, treating the elements she defines as individual objects. In the class model definition view, the elements of the language are regarded as classes, which are used for instantiating generic model objects. Here each type of process is regarded as an individual element. Finally, in the instance model view, the end user defines models of particular real world instances, regarding the generic elements defined above as classes that can be instantiated to create new objects. The duality of EKA objects support this process by allowing local, anonymous features (above the dotted line) and reusable, reified featured (below the line) to co-exist. In the end, particular instance objects have no reusable parts (per se) and thus nothing below the dotted line Instantiation, Specialization and Classification Note also that Figure 8 represents one, but by no means the only sensible way to organize this model hierarchy. One might instead have regarded the elements of layer two as specializations of process rather than instantiation of an abstract process concept one meta-layer up (substituting the Isa links with Is). The organization of these hierarchies will depend on the usage context, and this a core challenge for the modeling management structures and services to be implemented on top of the EKA structures. This case also illustrates the need for a not too rigorous separation between Is and Is-a relationships, (as defined above, where they have the same semantics). A general Is link also removes the need for making the mapping decision discussed in the Grape example of section 2.5. In an approach that does not separate Is from Is-a (which the EKA also tolerates), the class structure is flattened, so that any class denotes a set of elements, and indeed any element may constitute a class (if other elements point to it with an Is link). Because we cannot assume that there will be only one interpretation, the EKA does not enforce one interpretation. Classification structures will thus be constructed through Is and Is-a links. In the future we may also apply OWL classification mechanisms, as discussed below. When there is a need for separating different kinds of meta-views, we will utilize the fact that Is and Is-a are subclasses of Relationship and thus Object, to add properties to the Is links. We may also decide to utilize inheritance across other relationships, such as part and member. This can be achieved by declaring an Is relationship between the relationship in question and the Is relationship _ATHENA_DA152_V10 PUBLIC Page 15 / 132

21 Document Deliverabile D A1.5.2 Date Object called Process Class called Process Is-a Object called ResearchProcess Is Object called Case Class called Case Is-a Object called LoanApprovalProcess Language definition view Class model definition view Class called ResearchProcess Is-a Object called ATHENA Class called Loan ApprovalProcess Is-a Object called Application A2005/13342 Instance model definition view Figure 8. Multiple levels of modeling as different views upon self-reflective objects. 3.5 Operational Semantics This section provides guidelines for how a modeling tool or repository implementing the EKA structures would deal with typical operational scenarios such as the creation of new objects, the deletion of objects that other objects reuse something from, and how dynamic change of a (super) object influences the already existing instances and specializations. This part of the specification is not mandatory for the implementation by various modeling tools Object Creation Tools can handle creation of new objects in these ways: Copy/Clone object O into a new object N: o All anonymous features (relationships and properties that are sub-elements of the object specification) are copied from O to N. o All reified features are copied from O to N, where they are given a new ID. Instantiation (use object T as type for new object N): o N is given an Is-a link to T o Anonymous features of T do not affect N (they are regarded as relevant for the type level, e.g. for template classification, as illustrated in Figure 8). o For each reified feature of T, N will contain a feature with an Is-a link to the corresponding T feature. The features of N will by default be anonymous Promotion of Objects into Reusable Types As illustrated in Figure 8, objects which are intended to serve as types should have reified properties, while instance objects and templates will mostly have anonymous properties. If you decide to promote an instance to become the basis for a new type, the tool should thus help you with reifying its features Aspect Orientation and Mix-In Inheritance in Local Views The EKA supports role-based delegation and aspects, which are objects that other objects may reuse through Is links, e.g. a BudgetCostComponent aspect with properties and behavior (calculations), or a DocumentLifecycle process-aspect. Often, such aspect links will be reused through other Is links. You may also extend generic objects locally in this way. For instance, adding an Is link from EKA:Object to BudgetCostComponent in a view implies that all objects inside that view by default are BudgetCostComponents _ATHENA_DA152_V10 PUBLIC Page 16 / 132

22 Document Deliverabile D A1.5.2 Date Dynamic Change The dynamic change problem occurs in any system where there are instances and specialized classes whose definition depends on another (super) element. When the super changes, we must decide whether and how to update the dependent objects. In different modeling tools such decisions are made in different ways. If strict inheritance subtyping is implemented, static rules define that the dependent objects should always follow their super. In more flexible systems, however, we may ask the user which of the dependent objects a change should apply to. There may also be change management rules, enforcing different policies in different cases. With respect to the interpretation of EKA data, the various tools should behave in conformance with the following guidelines: 1) Any specification that applies to the target of the Is link (the super), applies by default also to its origin (the sub), e.g. if the property task.state has an is link to process.state, then the datatype of task.state will be the same as that of process.state, unless it is overridden. 2) Any specification inherited according to rule 1) may be overridden or removed in the sub. 3) No reified parts, such as properties and relationships, are implicitly inherited over an Is link between two objects. For instance, in a language where task specializes process, and a user adds the property state to the process type, the type task does not automatically include a state property. Instead, when a new element is added to the super, change management rules, or human decisions, should decide whether a similar change should be made to the dependent objects. 4) Property inheritance from one object to another is achieved by explicit Is/Is-a links from a property of the sub-object to a property of the super-object. Anonymous properties may be copied from the super when a new object is created, but if the super s property is updated later, it will not affect the sub. Reified properties, on the other hand, will be reused as long as the Is link between the properties is active. In the previous example, a change management rule or a decision made by a user may dictate that when state is added for process, it is also added for all of its dependents, including task, and these new state properties should have is links to the process.state property. 5) Removal of an inherited property is done by simply removing the property element from the subobject s specification. Removal of the inheritance relation is done by removing the Is/Is-a link from the property element. Whether removal of an element from a super should cause a similar removal from dependent objects, depends again on change management rules and decisions. Obviously some tools will implement more rigid scheme with less dynamic change flexibility than what is described above. In order to enable interoperability with such tools, future version of the MPCE should support model and metamodel validation services that verify whether a given model follows principles such as subtyping, single inheritance, and no dynamic change allowed on the instance level. 3.6 Representation of Roles in Complex Relationships The POP* process language includes input, control, output and resource roles. The encoding of roles into XML warrants a closer examination. It turns out that for typical relationships, some tools apply roles, while others do not. The objective of the role encoding in the EKA XML format is to simplify the mapping between these two common cases. In the first definition of EKA and POP* (cf. ATHENA Work Document WDA1.5.1), we did not have a uniform way of representing roles: Origin and Target were defined as properties of relationships o They could have properties, cardinality and Is/Is-a links Input, Control, Output, Resource (ICOR) were defined as objects o They were defined as parts of the object they are roles in o Relationships went between objects such as processes and role objects such as ICORs, rather than between the real objects themselves (e.g. a flow between two processes) This heterogeneity makes translation difficult. Tools that do not apply ICOR roles have to derive e.g. process-to-process relationships (such as flows) through the composite pattern process-outputrelationship-input-process. Another problem arises when the POP* core is defined with direct relationships between objects, and a tool wants to add a role to one of its ends. This would require the definition of a new role object type and two relationship types connecting it to the role-playing object and the object on the other end of the relationship. Again, translation would be difficult. Figure 9 below illustrates this problem. Some tools and users will prefer the simple view on the top, where a relationship is shown as a direct link between the two objects O (Origin) and T (Target) _ATHENA_DA152_V10 PUBLIC Page 17 / 132

23 Document Deliverabile D A1.5.2 Date Other views, especially those that aim to assist the users in establishing these relationships, will want explicit roles in both ends. Explicit roles allow e.g. representation of properties and features that are required by the objects filling the role. The old way of representing this in the EKA, is depicted in the middle row of Figure 9, with the relationship connecting the role-objects rather than the real objects. The current solution is depicted in the third row of the figure. Here roles are always implied at relationship ends 5. You need not say anything about the roles other than which objects fill them, corresponding to the top example, but you may also reify the roles as objects, add properties and relationships to them, similar to the 2 nd row view. By treating roles as optional, but always implied, parts of any relationship, users and tools may switch between these views dynamically, and exchange of models between the views is automatically enabled. O T O RT RO T O RT RO T Origin Target role Origin role Target Figure 9. Different relationship cases with and without explicit roles. Role is thus introduced as a core concept in the EKA, like it is in many other frameworks, such as GOPPR (Graph, Object, Property, Role, Relationship) [24)]. This approach also handles roles when you have relationships to relationships (e.g. connecting a State to a Flow), and roles may also be connected to decomposition relationships (Part/Member) and inheritance (Is/Is-a). 3.7 Language Definition Figure 10 below shows a visual representation of the POP* process dimensions as an add-on to the EKA core concepts. (This model was generated by importing the XML definition found in Appendix D.1 into Metis, and manually arranging the visual layout). The notation follows UML, with some exceptions: Relationship types are represented as objects (long rectangles), with arrows to their origin an target object types. Properties are represented as objects within their parent object or relationship. They are not shown in Figure 10 because it would make the figure complex and unreadable. You can however view them by opening up one of the object/relationship boxes, and Is-links are established according to the XML spec. Is-links between objects in the POP* model and the EKA core are not depicted as relationships. Instead, the type/symbol of the POP* objects shown which EKA construct they have Is links to. 5 Notice that we often depict the role on the other end of the relationship, e.g. the resource role is depicted on the process side, not on the person side which it is a role for. This is to enable a complete local view at both ends, i.e. that the process has surrounding role-objects for all its relationships (the ICORs), and that the person on the other end has surrounding role objects representing each of the processes (s)he participates in _ATHENA_DA152_V10 PUBLIC Page 18 / 132

24 Document Deliverabile D A1.5.2 Date Figure 10. POP* process dimension modelled in Metis. Once the model in Figure 10 has been generated by importing the XML specification, it serves as the operational definition of the POP* constructs. Any extensions and adaptation to the metamodel can be made, and immediately be released to all users of the server, through the EKA XML exporting utility of the Metis modeling tool. Below we will see how the same solution can be applied to manage sets of metamodels, such as the POP* dimensions, multiple, partially overlapping metamodel views, e.g. for different modeling tools or different roles in the organization, and mapping relationships between the different views. Then we will illustrate how these features with additional analysis services can be utilized to provide visual management of operational models and metamodel in the MPCE. 3.8 Metamodeling Tool Specific Views In order to manage partially overlapping meta-views handled by different enterprise modeling tools, the MPCE will require that the tools either manage complete model themselves, or articulate in a metamodel which parts of the common language they deal with, as well as which tool specific extensions they require. Tools that support multiple metamodels or templates may define multiple meta-views, one for each metamodel. Figure 11 below illustrates this arrangement. The colors distinguish different tools from each other, while common POP* constructs are pictured in blue. The figure illustrates: A shared model view containing common POP* elements but also tool specific extensions for three tools (small rectangles represent elements) _ATHENA_DA152_V10 PUBLIC Page 19 / 132

25 Document Deliverabile D A1.5.2 Date The POP* core as a partially shared metamodel with different dimensions as sub-views. Three different tool metamodels incorporating POP* elements, but also adding local extensions. Instantiation relationships from the common and tool specific parts of the shared model view to different metamodel views. Elements in the shared metamodel included in tool specific metamodels, denoting that the tools support this element (dotted lines) An element in the metamodel for tool B is also recognized by tool A, so they are able to share this information even though it is not part of the formally recognized common POP* metamodel. In the future, we will explore other kind of relationships between views and meta-views as well. The XML example in Appendix D.2 shows how a tool can articulate which part of the POP* process dimension it supports, and which extensions it makes. The specification of what to include covers all kinds of elements, including properties and is/is-a links. This enables us to distinguish between views on a suitably detailed level. Figure 12 shows the constructs from the POP* process dimension which are supported by Metis, as a visual reflection of the XML definition mentioned above. The model also captures which properties the tool supports, but that is not shown in the figure. Shared model view Specific elements for Tool A Specific elements for Tool B Specific elements for Tool C Metamodel for Tool A Metamodel for Tool B Metamodel for Tool C POP* metamodel Process System Product Decision Org Etc. Figure 11. Arrangement of model and metamodel views in a typical scenario. Figure 12. The Metis view on the POP* process dimension _ATHENA_DA152_V10 PUBLIC Page 20 / 132

26 Document Deliverabile D A1.5.2 Date Capturing Mappings between Metamodels In Figure 13 we see the links between the Metis view and the POP* definition (also generated by the import of the XML file). In addition to direct mappings between types in the two views, we see an example of the locally defined type, Pluggable Action. This type specializes Process Role, hasresource.target and Process.hasPart.Target in POP*. We may in the future also represent relationship roles in the tool specific view, but that is not included in the current specification. The default assumption is that if a tool supports a relationship, it also supported the same origin and target links (with the same cardinality constraints) unless otherwise specified in the tool specific view. Figure 13. Links between tool specific views and the POP* standard. A more convenient representation of this mapping, is the relationship matrix shown in Figure 14. When all the tools metamodels have been articulated in the same manner, we will be able to perform analysis determining what parts of the model two tools are able to exchange, and how an object in one tool is translated into another tool. Note that the mapping covers properties as well as object and relationship types. Once this information is made available as metamodels in an MPCE repository or another place on the web, the EKA services of the MPCE can be utilized to ensure correct server-side view merging. These services are described in section _ATHENA_DA152_V10 PUBLIC Page 21 / 132

27 Document Deliverabile D A1.5.2 Date Figure 14. Relationship matrix showing the mapping from Metis constructs to POP* constructs. 3.9 Modeling Example - Process In Appendix D.3 you will find an example of what a simple model fragment may look like in the XML format. What the model looks like in Mo 2 go, is depicted in Figure 15, while Figure 16 shows how it looks in Metis. We here see clearly the states (circles) as objects that are connected with member relationships to the flow relationships. The input, output and resource roles are represented as yellow interface objects to each process step. (While they are regarded as objects in the Mo 2 go view of Figure 15, they are treated as roles in the XML, cf. section 3.6). The example also illustrates that Metis is incapable of representing relationships that do not have both origin and target roles specified. The initiating and terminating flows are therefore not shown, only the corresponding states are included. Figure 15. Example process model _ATHENA_DA152_V10 PUBLIC Page 22 / 132

28 Document Deliverabile D A1.5.2 Date Figure 16. Another view of the example process, imported into Metis Exchanging the Visual Features of Models The purpose of this section is to introduce concepts that allow us to visually represent the core elements of EKA. The basic concepts are illustrated in the figure below. It shows a that one model view may be shown in multiple visual diagrams. Each model object and relationship may similarly be visualized by different visual objects and relationships in different diagrams. Each model element may also have multiple representations in the same diagram. Diagram (Visual Model) View (Visualization) Visual Object Visual Relationship View (Model) Object Relationship Figure 17. Core constructs for representing and exchanging visualization properties. The core concepts to be used for defining presentation views of any EKA object is described in the class diagram below _ATHENA_DA152_V10 PUBLIC Page 23 / 132

29 Document Deliverabile D A1.5.2 Date Figure 18. Concepts for visualization specification An ObjectView corresponds to one or many Objects. ContainerObjectView is a special kind of ObjectView that contains a collection of other object views. In many modeling tools this will correspond to a diagram. There are many possible visualizations of objects examples are graphical views (as in graphical modeling tools), forms (as in dialogs) and charts (as in diagrams). These different kinds of views are defined as different ObjectViewTypes (OVT). An OVT thus specifies general properties and behavior for one kind of views. Object and relationships view within a view type will inherit these definitions. Currently we will focus on graphical views, and the possibility to exchange these between modeling tools. As the figure shows, the core property types of graphical object views are position (given by coordinates) and size (given by extent). In a graphical view there will be two specializations of graphical view types: the Graphical Object View and the Graphical Relationship View the first with Position (x, y) and Size (width, height) as properties, and the second with Origin, Target and Path (list of coordinate pairs) as properties. Tool specific visualization types and properties may also be defined in the EKA framework, and associated with the object and relationship views. For instance, a specialization of the graphical object view will be the Metis Object View that has at least one additional property: Object Symbol. Corresponding Graphical Object Views can be defined for MOOGO, ARIS and GRAI. All tools should however supply the common types and properties defined above, in order to enable exchange of visual model features between the tools Scope for Version 1.0 In an actual graphical modeling view there will be graphical object views and (eventually) graphical relationship views that are used. In our first version we will represent views of objects only views of relationships will not be considered. This scope was selected when it became evident that the four tools apply different mechanisms for relationship viewing, and not all of them support explicit relationship views. In this situation Figure 18 can be reduced to Figure 19, where the container object view has been specialized to the Graphical Container View object _ATHENA_DA152_V10 PUBLIC Page 24 / 132

30 Document Deliverabile D A1.5.2 Date Figure 19. Simplified visualization scheme for version 1. More complex transformation of visual representations, such as between structured decomposition model diagrams (e.g. IDEF0) and non-structure-decomposition models, is not supported by any MPCE services in this version Coordinate system The graphical container view object defines the coordinate system for its content. As in most graphical systems the origin of the coordinate system is located in the upper left corner of the diagram, with the x-axis pointing to the right and the y-axis pointing downwards. To simplify uniform encoding the coordinates will be stored as integers. This is defined in the graphical view type, where coordinate is defined as an integer number (both positive and negative) and extent is defined as a non-negative integer number. In a modeling view positions and sizes of the objects are important, and they are stored in the graphical object view as x and y (coordinates), and width and height (extents). The x, y is the coordinate of the upper left corner of the object view EKA XML Representation The XML Schema below defines the format that is applied in version 1.0 of the MPCE. In order to simplify the implementation of model exchange, it constrains the number structure of the model files with sequence and structure rules, such as: 1) All Parts, Members and general Relationships must be defined as standalone 6 elements (children of the root View node). 2) All Is and Is-a relationships should be defined as children of their origin element, never standalone with an explicit origin link. 3) All object properties should be defined as children of the object element, never standalone with an explicit object link. The XSD defined for the EKA (below) enforces these rules. XSD also requires that multiple, optional XML elements must be ordered (by the Sequence constructor). This implies that a View s Properties must be defined before all its Objects, then States and Relationships. Inside each Object (or other elements), Is links should occur before Is-a and finally the Properties. We have chosen not to include Name, Description, MinCardinality, and MaxCardinality as XML elements, in order to treat all properties uniformly. 6 We denote the elements that are children of the root node in the XML hierarchy as standalone _ATHENA_DA152_V10 PUBLIC Page 25 / 132

31 Document Deliverabile D A1.5.2 Date Unfortunately, there is no commonly accepted XSD for RDF. We therefore relied on the formal definition of its XML notation [2)]. We also tried to utilize a test XSD for RDF provided by [9)], but found it to be incomplete. In order to enable syntactic verification, we thus decided not to link to RDF explicitly on the syntactic level, and to define the EKA XSD independently of RDF. Instead, RDF attributes and elements such as li, ID, about, resource and datatype are defined as part of the EKA namespace. <?xml version="1.0" encoding="utf-8"?> <xs:schema id="eka" targetnamespace=" elementformdefault="unqualified" attributeformdefault="unqualified" xmlns=" xmlns:xs=" <xs:element name="view" type="ekaview" <xs:complextype name="ekaview"> <xs:complexcontent> <xs:extension base="object"> <!-- Inherit the ability to contain properties and is/is-a relationships --> <xs:sequence> <xs:element name="object" type="object" minoccurs="0" maxoccurs="unbounded" <xs:element name="state" type="object" minoccurs="0" maxoccurs="unbounded" <xs:element name="relationship" type="relationship" minoccurs="0" maxoccurs="unbounded" <xs:element name="member" type="relationship" minoccurs="0" maxoccurs="unbounded" <xs:element name="part" type="relationship" minoccurs="0" maxoccurs="unbounded" <xs:element name="seq" type="collection" minoccurs="0" maxoccurs="unbounded" <xs:element name="alt" type="collection" minoccurs="0" maxoccurs="unbounded" <xs:element name="bag" type="collection" minoccurs="0" maxoccurs="unbounded" <xs:element name="containerview" type="objectview" minoccurs="0" maxoccurs="unbounded" <xs:element name="objectview" type="objectview" minoccurs="0" maxoccurs="unbounded" <xs:element name="viewpart" type="relationship" minoccurs="0" maxoccurs="unbounded" </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="object"> <xs:sequence> <xs:element name="is" type="role" minoccurs="0" maxoccurs="unbounded" <xs:element name="is-a" type="role" minoccurs="0" maxoccurs="unbounded" <xs:element name="property" type="property" minoccurs="0" maxoccurs="unbounded" </xs:sequence> <xs:attribute name="id" type="xs:id" <xs:attribute name="about" type="xs:anyuri" </xs:complextype> <xs:complextype name="role"> <xs:complexcontent> <xs:extension base="object"> <xs:attribute name="resource" type="xs:anyuri" </xs:extension> _ATHENA_DA152_V10 PUBLIC Page 26 / 132

32 Document Deliverabile D A1.5.2 Date </xs:complexcontent> </xs:complextype> <xs:complextype name="relationship"> <xs:complexcontent> <xs:extension base="object"> <xs:sequence> <xs:element name="origin" type="role" minoccurs="0" maxoccurs="1" <xs:element name="target" type="role" minoccurs="0" maxoccurs="1" </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="property" mixed="true"> <xs:complexcontent> <xs:extension base="object"> <xs:sequence> <xs:element name="object" type="role" minoccurs="0" maxoccurs="1" </xs:sequence> <xs:attribute name="datatype" type="xs:anyuri" </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="collection"> <xs:sequence> <xs:element name="li" type="property" minoccurs="0" maxoccurs="unbounded" </xs:sequence> </xs:complextype> <xs:complextype name="objectview"> <xs:complexcontent> <xs:extension base="object" </xs:complexcontent> </xs:complextype> </xs:schema> In greater detail, the EKA XSD defines the following syntax rules: 1) Root node: We will use eka:view as the root element of an EKA XML document. 2) Inclusion of meta-views: We will link in metamodel views through common XML namespace declaration tags as part of the root element. For closed model exchange, all objects that are referred to as targets of Is and Is-a relationships within a view, should be found in these files, or in the local file itself. For open model exchange, this constraint is not enforced. 3) Abbreviated syntax - Tags: The core elements of EKA (View, Object, Property, Relationship, State, Role, Origin, Target, Is, Is-a, Member, Part) may be used directly as XML tags (following the RDF/XML abbreviated syntax notation). Currently, we do however not allow POP* object types such as Process and Person to be used as tags. Instead, use an Object tag with an Is or Is-a element referring to the type. Nor do we allow user-defined types to be used as tag names. We may extend the language with these mechanisms later, if it is found not to cause any problems for the XML parsers that the modeling tools apply. 7 4) Identification: We will use the ID attribute from RDF, which can take any URI value, as the node identification attribute. Core POP* types should have a human-readable local ID (probably equal to its name), so that we may refer e.g. to #Process later. ID values must be unique within a file or base URI. The base URI is represented as the xml:base attribute of the eka:view root 7 Such a notation would not be 100% based on RDF either, because we would allow tag names to be used as replacements for Is and Is-a relationships, while RDF does the same it for its own schema classes and type links _ATHENA_DA152_V10 PUBLIC Page 27 / 132

33 Document Deliverabile D A1.5.2 Date node. If no base is explicitly provided, the URI of the file is used. This creates problems when e.g. downloading a file from the repository to a local machine, so the base attribute should be set. 5) Multiple facets: We will use the about attribute from RDF in the place of ID when we are describing additional features (facets) of elements that are primarily defined in another view. Each object should thus be defined/declared in one view, but any number of other views may contribute to its description. 6) References: We will use the resource attribute from RDF for references to other objects in origin and target roles. 7) Local elements may be anonymous (have no ID), in which case they cannot be referred to from other objects. They may also be reified (have an ID), which implies that they can be referred to (and e.g. reused) by other objects. Relationships may contain an Origin property pointing back to its surrounding object. (The detailed semantics of inheritance was be defined in section 3.4.1). 8) Duplicate forward references, e.g. from an object to its relationships defined standalone somewhere else, will not be included. 9) Values: Text inside a property tag is regarded as the value of that property. The type of the data should be defined by the datatype attribute (from RDF) on the property or one of its supers (inherited through Is/Is-a) Namespaces Since RDF schema and OWL rely on a different type system from ours, we will not use RDFS and OWL elements directly in EKA/POP* specifications. This is why we e.g. have defined our own variants of the cardinality elements from OWL. RDF is however compatible, so we will apply RDF elements like ID and datatype. XML entities will be used as abbreviations for standard, EKA, POP* and tool specific metamodel namespaces (views). For example, when an XML entity xsd defined in the DOCTYPE declaration <!ENTITY xsd " > Then, the URI of an element in the namespace can be referred to as. <Property datatype="&xsd;datetime" Most XML parsers will automatically substitute the value of the entity in the property datatype value above and all other places where it occurs. A header like this should thus be included in EKA XML files: <!DOCTYPE eka:view [ <!ENTITY xsd " > <!ENTITY eka " > <!ENTITY popstar-process " > ]> For model exchange, we standardize on the following namespace names: Namespace Namespace URI Description xsd From XSD we reuse standard data types such as integer, string, date etc. eka The EKA core The standard entities that will be used to denote shared model and metamodel content are defined below: Entity Entity URI Description xsd eka The EKA core 8 We may in the future allow explicit XML schema tags to surround the value, such as <xsd:date> </xsd:date> in order to qualify the data so that it is easy to interpret for other systems _ATHENA_DA152_V10 PUBLIC Page 28 / 132

34 Document Deliverabile D A1.5.2 Date moogo aris grai popstar-uml Entity Entity URI Description popstarprocess The process dimension of POP* popstarorganization popstarproduct popstarsystem metis-bpm The organization dimension of POP* The product dimension of POP* The system dimension of POP* The metamodel of Metis business process modeling, in EKA format The metamodel of Moogo, in EKA format The metamodel of ARIS, in EKA format The metamodel of GRAI, in EKA format The metamodel of the POP* profile in RSM When this standard is followed we need not concern ourselves with the full URLs of the metamodel definitions other than in the XML document heading. This greatly simplifies the XML documents, and makes them more robust to spelling errors and character encoding _ATHENA_DA152_V10 PUBLIC Page 29 / 132

35 Document Deliverabile D A1.5.2 Date Implementation The figure below shows the architecture of the first implementation of the MPCE. At the top, we find five modeling tools all accessing the common modeling repository through its web services. The repository is implemented as a web services layer on top of the commercially available repository Metis Team 3.6, provided by Troux Technologies. On top of this repository we have implemented some EKA services to assist with model view merging. Metis Team also provides a web browser interface that allows users to upload and download files. ATHENA A1 enterprise models and metamodels are stored as files in the EKA XML format. This XML format and the web service interface is open and defined independently of the underlying technology, and hence shown with a white color. (Proprietary technologies provided by the different tool vendors, have different colors.) ARIS MO 2 GO Rational Software Metis GRAI Modeler POP* Profile Web Client EKA XML MPCE Web Services (Standard WSDL/SOAP) EKA Services Metis Team Web Server EKA XML Metis Team 3.6 Repository Figure 20. MPCE v.1.0 implementation architecture This chapter first describes the MPCE web service interface as it is currently implemented. Then each modeling tool is introduced, and the implementation of MPCE support is briefly described. Additional details are found in the appendices to this document. 4.1 MPCE Web Service Interface The deliverable DA1.5.1 specifies the interfaces to the MPCE as in Figure 21 below. The main services it offers are: An enterprise model and metamodel repository with its content stored as EKA structures (as defined in this report). Modeling support services for performing modeling and metamodeling, including transformation of models, changing and working on the models. Administration services, e.g. security and access control. Repository services, e.g. versioning and configuration management. Knowledge management services, for language extensibility, language and model change management. The main components interfacing with the MPCE are: Various modeling tools using the MPCE. Underlying ICT services, e.g. web services or agents. Model generated workplaces. Execution services, such as business process management systems and rule engines _ATHENA_DA152_V10 PUBLIC Page 30 / 132

36 Document Deliverabile D A1.5.2 Date Specialized interfaces are defined for each kind of tool, in addition to generic model and metamodel access services. The architecture should in the future also support replication and synchronization between multiple MPCE repositories. Figure 21. The conceptual architecture of the MPCE. Here we will define the services implemented by version 1.0 of the MPCE in greater details than in DA1.5.1, in order to allow modeling tools, in particular, to interface to the repository. Each of the main service categories above is discussed in a separate section below. Appendix E define envisioned extensions for version 2.0, to be ready by M24, i.e. end of January 2006, in addition to the Web Service Description Language (WSDL) definitions of all the existing services. Below, services are defined with input message content inside parenthesis after the service name and output message content after the arrow symbol Error Handling In general, the services defined in this chapter will always have a string return value. This string may contain composite data as XML. We define this protocol for signaling errors: Situation Result/Indicator The service executed ok, The result is an empty string no return value is expected The service executed ok, a The requested data is returned as a string return value is expected Invalid request parameter The error code 500 for internal server error will be returned, e.g. if you format try to submit anything other than true or false for a boolean field. Invalid request content, A string starting with Error: containing the error message will be failed service returned, e.g. if access is denied Administration Services These services deal with user authentication and access control, user awareness and the definition of content structures such as projects. Access to some of these services is restricted to administrator users. In version 1, these services will only be supported for complete views (model files), but in version 2 access control will also be handled at the object level _ATHENA_DA152_V10 PUBLIC Page 31 / 132

37 Document Deliverabile D A1.5.2 Date User Authentication In order to access the content of the MPCE repository, a SessionKey must be obtained and supplied with every subsequent web service call. The session key is obtained at login, and released by logout, or automatically after 12 hours. For user authentication, these services are applied: Login (string Username, string Password) string SessionKey Logout (string SessionKey) GetUserNameForSession (string SessionKey) string Username Since the password is submitted in un-encrypted text, https should be applied as transport protocol User Definition Users are defined and managed through these services: CreateUser (string SessionKey, string Username, string Password) DeleteUser (string SessionKey, string Username) SetPassword (string SessionKey, string Username, string OldPassword, string NewPassword) GetUserProperty (string SessionKey, string Username, string PropertyName) string Value SetUserProperty (string SessionKey, string Username, string PropertyName, string Value) The list of properties that may be assigned to a user or group, is defined in appendix E Administrator User Definition Administration users are the only ones who are allowed to define new users and user groups, and grant access to objects in general. Ordinary users can just read the user, group and membership lists, and delegate their own access privileges (provided they possess the access right to do so). Administration users are managed by these services: AddAdmin (string SessionKey, string Username) RemoveAdmin (string SessionKey, string Username) IsAdmin (string SessionKey, string Username) boolean GetAdmins (string SessionKey) string AdminUsernames Group Definition User groups may be assigned permissions to objects just like individual users. User groups and membership relationships are defined by these services. CreateUserGroup (string SessionKey, string Groupname) DeleteUserGroup (string SessionKey, string Groupname) AddMember (string SessionKey, string Groupname, string Username) RemoveMember (string SessionKey, string Groupname, string Username) IsMember (string SessionKey, string Groupname, string Username) boolean GetMembers (string SessionKey, string Groupname) string Usernames GetUserGroupProperty (string SessionKey, string Groupname, string PropertyName) string Value SetUserGroupProperty (string SessionKey, string Groupname, string PropertyName, string Value) The properties for user groups are the same as those for users. Groups may also be members of other groups, so you can define a group hierarchy (or graph) Access Control Users are given access to objects in the repository through direct permission assignment or through permission policies that combine at set of atomic permissions. Permissions can be granted on each folder or file to each user or group of users. Permissions are inherited from folders to subfolders or files in the folder, and from groups to the subgroups or users in that group. In addition, you can stop all permission inheritance for a particular folder or file. These basic permissions may be granted: Browse (folders) Read (files) Write (files) Create (folders) Change state (files) _ATHENA_DA152_V10 PUBLIC Page 32 / 132

38 Document Deliverabile D A1.5.2 Date Delete (files and folders) Change inheritance (files and folders) These services are applied for assigning and inspecting basic permissions: CheckPermission (string SessionKey, string ObjectURI, string Username, string Permission, string State, boolean AllowedToDelegate) boolean GrantPermission (string SessionKey, string ObjectURI, string Username, string Permission, string State, boolean StopInherit, boolean AllowedToDelegate) RevokePermission (string SessionKey, string ObjectURI, string Username, string Permission, string State, boolean StopInherit, boolean AllowedToDelegate) Whether an object inherits permissions from its folder is controlled by these services: GetInheritance (string SessionKey, string ObjectURI) boolean AllowInheritance (string SessionKey, string ObjectURI) StopInheritance (string SessionKey, string ObjectURI) In order to provide more user-friendly access control, the basic permissions above may be combined into permission profiles for typical model using roles. These services are used for controlling access through permission profiles: CheckPermissionProfile (string SessionKey, string ObjectURI, string Username, string PermissionProfileName, boolean AllowedToDelegate) boolean GrantPermissionProfile (string SessionKey, string ObjectURI, string Username, string PermissionProfileName, boolean StopInherit, boolean AllowedToDelegate) RevokePermissionProfile (string SessionKey, string ObjectURI, string Username, string PermissionProfileName, boolean StopInherit, boolean AllowedToDelegate) These generic profiles should always be supported by any MPCE server: Permission profile browse read write create change state delete purge change inheritance manager x x x x x x x x designer x x x x x x editor x x x x reviewer x x x x audience x x restricted x Services for defining new permission profiles and updating the permissions they entail, will be offered in version Modeling Support Services Modeling support in the first version deals with file based model upload and download to and from the repository. In version 2, individual objects can be created, updated and deleted separately. The MPCE supports pessimistic locking, so user agents will have to check out the files/objects before they upload a new revision. CheckOut (string SessionKey, string ObjectURI) string XMLContent CheckIn (string SessionKey, string ObjectURI, string Comment) IsCheckedOut (string SessionKey, string ObjectURI) boolean Revert (string SessionKey, string ObjectURI) Get (string SessionKey, string ObjectURI) string XMLContent Put (string SessionKey, string ObjectURI, string XMLContent) Create (string SessionKey, string Path 9, string Type 10, string Name) 9 The path should be complete, i.e. start with /Team/Repository for our current installation. 10 The Type parameter should contain Folder or Directory if you want to create a folder. Otherwise, a versioned file will be created _ATHENA_DA152_V10 PUBLIC Page 33 / 132

39 Document Deliverabile D A1.5.2 Date Copy (string SessionKey, string ObjectURI, string TargetPath, string TargetName) Move (string SessionKey, string ObjectURI, string TargetPath) Delete (string SessionKey, string ObjectURI) In addition to these SOAP web services, http get and put will also be supported for uploading and downloading model files EKA Services In order to support modeling by multiple tools that support partially overlapping metamodels, the MPCE provides services that merges partial models from one tool with complete models (often the previous version) from the repository (cf. section 3.8). If no metamodel is given that informs the server about what parts of the model the tool in question supports, a boolean flag controls whether elements found in the previous version but not in the new master will be included in the result. If a metamodel is specified, elements whose type is part of the metamodel will be deleted if removed in the master, while elements outside of the metamodel will be kept. Merge (string SessionKey, string TargetObjectURI, string MasterObjectURI, string PreviousObjectUri, boolean DeleteMissingObjectsFromPrevious) MergeVersions (string SessionKey, string TargetObjectURI, string MasterObjectURI, string MasterVersion, string PreviousObjectUri, string PreviousVersion, boolean DeleteMissingObjectsFromPrevious) PutAndMerge (string SessionKey, string TargetObjectURI, string XMLContent, boolean DeleteMissingObjectsFromPrevious) MergeWithMetamodel (string SessionKey, string TargetObjectURI, string MasterObjectURI, string PreviousObjectUri, string MetamodelURI) MergeVersionsWithMetamodel (string SessionKey, string TargetObjectURI, string MasterObjectURI, string MasterVersion, string PreviousObjectUri, string PreviousVersion, string MetamodelURI) PutAndMergeWithMetamodel (string SessionKey, string TargetObjectURI, string XMLContent, string MetamodelURI) Repository Management Services In addition to the versioning, configuration, dependency and metadata management services described below, backup services will be controlled on the server side of the MPCE Versioning When check-in is invoked, the current version is automatically stored under a new version number for the object/file. The version numbers thus constitute an ordered list of integers. You may also invoke these services to access previous versions: GetVersionsForObject (string SessionKey, string ObjectURI) string listofversionnumbers GetVersion (string SessionKey, string ObjectURI, string version) string XMLContent DeleteVersion (string SessionKey, string ObjectURI, string version) GetVersionByPolicy (string SessionKey, string ObjectURI, string Policy, string PolicyArgument) integer version The policy-controlled get service supports a wide range of access policies, listed in the table below. These keywords may also be applied as parameters to the version merging services defined in section Policy Policy Name Argument Explanation Unspecified version default If you have not chosen any other policy, the system will use one of the policies below as default. Which one it is can be customized, but usually it is the newest version _ATHENA_DA152_V10 PUBLIC Page 34 / 132

40 Document Deliverabile D A1.5.2 Date Newest version newest Picks the newest version that either is available or has been checked out by you. Corresponds to "My checked-out version" when you have checked out. Corresponds to "Newest available version" when you have not checked out. My version Newest version checked-out available Newest available version with maximum state Newest available version with state equal to... Newest available version with state greater than or equal to... newestopen newestclosed newestclosed WithMaxState newestclosed WithState clientresolve_ newestclosed WithState state state Picks the one version that has been checked out by you. Picks the newest version that is available. Picks the newest available version with a state such that no other available version has a state with a higher maturity level. Picks the newest available version with a state equal to the argument. Picks the newest available version with a state where the maturity level is equal to or greater than the maturity level of the argument. Specific version... count Num-ber Picks the version with the version number specified in the argument. Newest available version at time... checkedinat Time time Picks the newest version that was/is/will be available at the time specified in the argument. The state argument type refers to phases in the lifecycle of a version, and can take one of the following values: Development 1 Review 2 Production 3 Retirement 0 Figure 22. States in the lifecycle of a model view. Additional states may be defined as part of server configuration Dependency Control The modelling support services above provide basic model file and object access and updating functionality with locking. There are however some more complex services that allow tools to create transactions to ensure that interdependent model files are locked and updated together. This is accomplished through changelists, which collect a set of interrelated changes that may be locked and later checked in together. We expect changelists to be even more important in version 2, when model objects are accessed individually. CreateChangeList (string SessionKey, string Comment) string ChangeListId GetChangeLists (string SessionKey, string Owner, datetime Start, datetime End, integer State, string ChangeListId, string ObjectURI, string OrderBy) string ListOfChangeListsWithChangesAsXML SubmitChangeList (string SessionKey, string ChangeListId, string Comment) RevertChangeList (string SessionKey, string ChangeListId) DeleteChangeList (string SessionKey, string ChangeListId) RevertChange (string SessionKey, string ChangeId) MoveChange (string SessionKey, string ChangeId, string ChangeListId) MoveObjectToChangeList (string SessionKey, string ObjectURI, string ChangeListId) _ATHENA_DA152_V10 PUBLIC Page 35 / 132

41 Document Deliverabile D A1.5.2 Date Submit commits all updated objects to the repository. In addition to the services above, an optional ChangeListID parameter may be included in the modeling support services Checkout, Put, Create, Delete, Move and Copy defined in section in order to populate the changelist Metadata Management Metadata about objects (files and folders) may be utilized for controlling how content is to be handled based on policies agreed upon and implemented by the different modeling tools. The MPCE offers these services for managing such metadata: GetObjectProperty (string SessionKey, string ObjectURI, string PropertyName) string SetObjectProperty (string SessionKey, string ObjectURI, string PropertyName, string Value) In addition to setting property values (cf. Appendix E), users may add customised properties for folders and files Execution and Integration Services There are no services for work performance or integration of external technologies such as web services and business process management systems in this version. However, through concurrent work in A2, A6 and C4, the MPCE provides some support in these areas: Through ARIS and Mo 2 go, enterprise-level process models can be converted to executable processes in A2. From Metis you can configure the ATHENA Collaboration Portal (ACP) from C4, which is built on top of the Metis Team repository just like the MPCE: o Model-configured projects portals with content structures, navigation structures, users, roles and access privileges, o Model-generated workplaces for editing and analyzing any kind of relational data (also defined in visual models), such as the DRDS (Dynamic Requirements Definition System) for B4, the Training Content Manager for B6 or the Dissemination Material Manager for C2. o Model-generated workplaces, html-pages and forms can be generated from any of the 5 modeling tools and made available through the portals. The ACP is currently being extended with these and other configuration and integration services as the active model execution platform by A6. As a repository, the MPCE complements the repositories developed and integrated by A6 with a more free and open storage structure compared to the more rigid and low-level MOF and UDDI repositories. As described in Appendix E, These services will be extended for the next version (M24). 4.2 Metis Client Support Metis is a generic enterprise modeling tool with metamodeling capabilities so that customers can adapt the tool to their local need, preferences, and terminology dialects. The tool was originally developed around 1990 to support product design and engineering, but in recent years Enterprise Architecture and IT Governance has been the major application areas. Since the merger between Computas Technology and Troux Technologies, Metis has become the global market leader in these areas. Enterprise Architecture models covers many aspects of the enterprise, connecting from visions and strategy down to the operational level IT infrastructures, business processes and organizational structures such as competence and skill profiles (cd Figure 23). For large enterprises, complete EA models can consist of millions of objects and relationships stored in the Metis Enterprise repository. In order to work with such large models, powerful dynamic queries, multiple views, model and submodel management are critical capabilities _ATHENA_DA152_V10 PUBLIC Page 36 / 132

42 Document Deliverabile D A1.5.2 Date Figure 23. Example Enterprise Architecture model Modeling Framework Most Metis customers utilize the metamodeling capabilities to define their own modeling types. Models consist of objects and relationships, and objects may have interfaces (role objects). Relationships are binary, and go from one object or relationship to another. Relationship type definitions control which type of elements may be connected, and may contain cardinality constraints. Part-of decompositions are supported natively, and may be visualized as tree structures or nested (components inside their parent). Objects and relationships have properties and behavioral features such as methods and criteria (queries) that may be invoked during modeling. Methods may also be used for implementing rules ensuring that one property s value can be derived from other properties on related objects or relationships. Property value types such as enumerations may also be defined. Model elements are typically thought of as instances of their type, but the may represent both concrete individuals as well as generic classes. Users define new types through metamodeling forms. Model elements can be visualized in multiple model views. Each object or relationship may thus have multiple views, even within on model view (diagram). Symbols may be selected individually for each element view, but are typically inherited from the type s viewstyle. Macros are used so that visual elements (such as colors and texts) can be controlled by property values. Macros may also be defined locally for each view Process Modeling Language For Metis, Troux delivers a number of standard modeling languages and architecture frameworks such as UML, BPM (Business process modeling), IT management, Metis Architecture Framework, DoDAF, TOGAF, Capital Asset Planning with Business Cases, etc. This implies that the tool supports many different business process modeling notations, suitable for different user groups and tasks. For the MPCE v.1.0, we have concentrated on the Metis BPM template, which follows the BPMN (Business Process Modeling Notation) standard [23)], with the addition of optional IDEF-inspired constructs for process roles (Input, Output, Control and Mechanism). We do however plan to integrate other process modeling notations as well, in order to achieve interoperability across Metis templates _ATHENA_DA152_V10 PUBLIC Page 37 / 132

43 Document Deliverabile D A1.5.2 Date Figure 24. Example model in the Metis BPM language. The mapping between POP* process constructs and Metis BPM constructs is close to one-one. Still, these differences required some work-arounds: Metis regards roles (interfaces) as part of the object on the other end of the relationship, not as part of the relationship. Metis does not handle relationships without an origin or a target. Metis has a modeling area of infinite depth. Instead of putting decompositions in separate diagrams, multiple levels are found in the same diagram, where a decomposition is shown if you open an object 11. The MPCE scheme for visualization is however diagram-oriented, which caused a need for some special consideration. Metis BPM includes several additional properties on each of the object types compare to POP*, so these had to be captured as tool specific extensions in the EKA files. Metis processes can be connected to many different types of objects in an EA model. These relationships are not handled in the current process-only implementation of the MPCE, and consequently they are stored on the Metis client as part of the proprietary Metis model view file. Metis BPM includes types representing all the concrete POP* process constructs.. The states (called intermediate events) attached to flows, are however used only when there is a special need for highlighting the state in the model. Models commonly, as in Figure 24, do not include such objects. It is difficult to fully recreate this kind of informal modeling conventions in a multitool framework. We chose not to import and visualize states added in the other tools, where they are mandatory in some cases, but to allow users to add intermediate events in Metis Implementation of Transformation, Import and Export For transformation between the internal format of Metis and EKA, we have applied a generic model-driven transformation tool called MMT. It enables customizable XML import and export from Metis models. Different transformation models can be built for different XML formats and Metis languages. For MPCE v.1.0, we have just built a transformation model between the EKA representation of POP* concepts and the Metis BPM template. Extending this to other templates is however straightforward. In addition, XSLT has been used for pre- and post-processing the XML input/output in order to make it more suited for the MMT. 4.3 GRAI Client Support GraiTools proposes a complete environment for BPM and enterprise modeling based on tested techniques and concepts (GRAI methodology). The tools are integrated on one platform, facilitating the implementation of the projects and the maintenance of the enterprise reference frames; 11 In the figure, Evaluate message and Approve or Reject are open and decomposed, while the other objects are closed. The example thus shows three levels of granularity in one diagram _ATHENA_DA152_V10 PUBLIC Page 38 / 132

44 Strat Tact Opér Informations Externes IE IE <<Fonction>> F <<Centre de décision>> F Proc <<Fonction>> F F <<Flux>> d <<Fonction>> F <<Centre de décision>> <<Centre de décision>> F <<Flux>> <<Processus>> Proc <<Flux>> df Informations Internes II II <<Flux>> <<Processus>> Proc Copie de <<Flux>> d <<Processus>> Proc Copie de <<Flux>> df Elément d'info <<Info>> Proc Proc Proc <<Activité d'exécution>> Règles <<Activité de décision>> Objectifs Variables Critères Contraintes IP- Project / Programme ATHENA Project - No Document Deliverabile D A1.5.2 Date The main added value of GraiTools is the capability and facility to capture the structure and the functioning of an enterprise and to communicate with them with the different actors of the enterprise. GraiTools can perform this on different points of view: Functional, Physical, Decisional, Process, Information, Technical, Economical, Social, Human With two different visions: Global (system design): global description showing prominently goals, components and how they interact, features, evolution management and connections with the environment. Local (analytical): detailed description broken down in activities and processes Process Modeling Language GraiTools has been designed to assist enterprises to improve their performance. The GRAI methodology Is based on a reference model, the GRAI model, which allows representing the enterprise in its current, as well as future form, Uses simple and precise graphical conventions to visualize the concepts of the GRAI model and facilitate communication and interpretation, Follows a proactive and precise process in which are defined the different participants and stages, thus providing EFFICIENCY and TIME SAVING The following conventions are used: Convention Functional View Actigram: <<Actigramme>> Act <<Actigramme>> Act Process View Extended Actigram: Decisional System GRAI Grid: Grai net : Physical System Actigram: <<Actigramme>> Act <<Actigramme>> Act Informational System Classes diagram: Copie de entier Copie de entier entier Copie de entier _ATHENA_DA152_V10 PUBLIC Page 39 / 132

45 Document Deliverabile D A1.5.2 Date Extended Actigram is based on the basic constructs of Actigram in which it is added the following constructs: Connector: origin or destination of the flow Logical operator: AND, XOR Trigger: information which triggers the activity. A trigger entity is represented as a bold flow. In GRAI Process, a process is broken down in Activities. An Activity becomes a sub-process when it is also broken down. The word activity is used at the lowest level of decomposition Modelling Framework The GraiTools metamodel cannot be parameterized. A translation has been developed between the POP* model and the GRAI model (see Figure 26 on page 7) so these applications can exchange data with minimal loss of information Mapping problems A GRAI Process always has an origin connector and an extremity (end point) connector. A GRAI Process represents an entity (information of physical item ) by a flow: there is not the construct of "State" which is used in POP*. Each flow indicates a state of the entity implicitly, but there is no explicit state or event object, as in ARIS and Mo 2 go.. In a GRAI Process, the resources are connected on the bottom side of the activity (Actigram construct). The flows which connect the resource to the activity indicate the "competence" supplied by the resource. In our case the resource "Management" supplies the "rules of evaluation". An example of a GRAI Process can be found below.? Received message Evaluate message Approved message Send "Approved" App-send Approved message sent Sent message? Eval-msg Rejected message Send "Rejected" Rej-send Rejected message sent Rules of evaluation Management Figure 25. Example Process as GRAI Actigram. While developing, the whole of the process part has been treated by adding the concepts of resource and control (not shown in our example). POP * POP* Process Decision Point Flow Flow carries Flow state Gateway Gateway.Activated Gateway.ConditionalContinuation Gateway.Description Gateway.inFlowLogic GRAI Process GRAI Process Connector, operators Flow Entity or enterprise object attached to a flow Trigger Operator Activated operator Type of operator Operator description Operator _ATHENA_DA152_V10 PUBLIC Page 40 / 132

46 Document Deliverabile D A1.5.2 Date POP * GRAI Process Input Entity or enterprise object attached to a process(or activity) in order to be transformed LogicalRelation Operator Output Entity or enterprise object attached to a process (or activity) which has been transformed Output.name Name of the entity or enterprise object transformed by the process OutputDescription Description of the output object Play Role Operator Process Entity or enterprise object attached to a process(or activity) in order to be transformed Process.Description Operator Process.Finish-Time Entity or enterprise object attached to a process (or activity) which has been transformed Process.Name - Process.StateTime - Process.State Name of the entity or enterprise object transformed by the process ProcessRole Description of the output object ProcessRole.Activated - ProcessRole.Conditional_Continuation Process ProcessRole.Description Description of the transformation ProcessRole.In-Flow-Logic ProcessRole.Name Process.hasPart - Resource Resource.Activated Resource.ConditionalContinuation Resource.Description Resource.In-flow-logic Resource.Name - Role ( will be added soon) Process name Process activated or not Description of the transformation Process activated Flow indicate the continuation Description of the transformation Name of the transformation Implementation of Transformation, Import and Export All of the developments have been done in Visual Studio C++. An external XML parser has also been integrated. For web services, Visual Studio web interface has been used Challenges for further work The extension to concepts other than processes (decision matrices, organization ) will be a real challenge as concepts used by the different tools are extremely different _ATHENA_DA152_V10 PUBLIC Page 41 / 132

47 Document Deliverabile D A1.5.2 Date EXTENDED ACTIGRAM PROCESSS 0.. RESOURCE MATERIAL RESOURCE DIVERGING AND DIVERGING LOGICAL OPERATOR {Disjoint, Complete} DIVERGING OR {Disjoint, complete} * LOGICAL OPERATOR Output flows correspond to the Totality a part or none (in case Of a XOR) of the corresponding Input flow CONVERGING CONVERGING LOGICAL OPERATOR {Disjoint, complete} {Disjoint, complete} 1 Competency or technical specification : Name 1.. Unitary cost Location CONVERGING OR The output flow Correspond to the Totality or a part of the Corresponding Input flows 2.. input 1 o utput input output Flows between two logical Operators have not the capability of triggering the Beginning of an extended activity * FLOW Type (information or product) Name Trigger is associated with 0.. CONNECTOR Nam 1 {An output flow have not the capability of triggering the beginning of an extended activity * * resource * input 1.. output * control A flow which comes from Connector can only be used By an extended actigram as an input an output or a control {Disjoint, complete} HUMAN RESOURCE 0.. EXTENDED ACTIVITY Minimu cost Maximu cost Mission Functioning rules Expiration date Average cost Minimu delay Average delay Maximu delay Minimum quality Average quality Maximum quality Has authority on {Disjoint, Complete} DIVERGING ASYNCHRON AND DIVERGING SYNCHRON AND INTERNAL CONNECTOR EXTERNAL CONNECTOR PROCESS CONNECTOR CONERGING ASYNCHRON AND CONVERGING SYNCHRON AND Figure 26. GRAI process dimension modeled in GraiTools _ATHENA_DA152_V10 PUBLIC Page 42 / 132

48 Document Deliverabile D A1.5.2 Date Rational Software Modeler Client Support Rational Software Modeler is a customizable, UML 2.0-based visual modeling and design tool developed by IBM (International Business Machines) that enables different types of professionals to document and communicate processes, flows, and designs. Rational Software Modeler is fully integrated with Eclipse IDE and allows plugin based customization and addons. Figure 27. Rational Software Modeler IDE ESI has customized the modeling environment with a Plugin that adds POP* UML2 profile constructors. Rational Software Modeler + ESI POP* plugin allows users to easy develop POP* models and exchange them in XMI or EKA XML format (see Figure 28). Rational Software Modeler uses XMI based XML format for the representation and the interchange of UML models [15)]. XMI is a model driven XML Integration framework for defining, interchanging, manipulating and integrating XML data and objects. XMI-based standards are in use for integrating tools, repositories, applications and data warehouses. XMI provides rules by which a schema can be generated for any valid XMI-transmissible MOF-based metamodel Modeling Framework Rational Software Modeler is based on the UML 2.0 modeling framework. UML (Unified Modeling Language) is a set of objects, relations, diagrams and rules that allow user to convenient represent conceptual designs. UML was originally created to software systems development and design, but thanks to it s profile mechanism it s possible to extend or specialize UML to other areas, such as process modeling and enterprise modeling. UML Profiling mechanism, in which is based all the work that has be done with Rational Software Modeler, consists mainly of a set of stereotypes that extends a set of UML2 common constructors and orients them to a concrete area. This way the end user finds a modeling environment that is adapted to it s specialized requirements. For further reading on UML and UML Profiling mechanism can be visited. MOF was described and analyzed in section _ATHENA_DA152_V10 PUBLIC Page 43 / 132

49 Document Deliverabile D A1.5.2 Date Figure 28. ESI customized Rational Software Modeler environment Process Modeling Language Our POP* modeling approach is based on UML profiling mechanism supported by Rational Software Modeler. Basically, a POP* UML profile has been defined, and the RSM modeling environment has been modified to support this profile s specialization. In order to conveniently represent POP* concepts, our approach consists of two separated diagrams, the resource diagram and main diagram. Figure 29. Resource diagram from POP* profile in Rational Software Modeler _ATHENA_DA152_V10 PUBLIC Page 44 / 132

50 Document Deliverabile D A1.5.2 Date The resource diagram is an UML class diagram which contains information regarding resources and other enterprise objects. These enterprise objects play input or output role in a process flow, and they are logically linked to processes in the other diagram. Figure 30. Main diagram from POP* profile in Rational Software Modeler. The main diagram is an UML activity diagram, which contains information regarding enterprise objects role and process flow. Every datastore object is logically linked with an enterprise object of the resource diagram Implementation of Transformation, Import and Export Rational Software Modeler.emx as well as EKA are xml files, and for xml manipulation and transformation the most obvious option was XSLT. There are two separated XSLT transformation templates, the first one takes as input a.emx file and generates an EKA file, the second does the reverse process. The two xslt templates are enveloped by a very simple JAVA application, that launches a XSLT processor with our templates and source file (RSM or EKA) as a parameter. This application is shown in Figure 31. Figure 31. ESI MPCE client screenshot _ATHENA_DA152_V10 PUBLIC Page 45 / 132

51 Document Deliverabile D A1.5.2 Date Challenges for Further Work Further work in this area will focus on developing more integrated and user friendly modeling and interchange solutions, in order to fully address the need of an all-in-one solution for end users, avoiding actual need of working with different packages. The goal is to integrate all the functionalities as a part of the RSM IDE. There will also be further work on metamodeling, in order to solve issues with the UML2 profile as soon as they appear. 4.5 Mo2go Client Support MO²GO with the IEM method is a easy to use commercial modeling tool. The modeling process is very fast and the IEM method is easy to understand for the different stakeholders of an enterprise (from experiences with new users, they need 5-10 minutes to understand the models and about 4 hours before starting modeling). This is proven in several industrial projects over the last 10 years. Method and tool are used in several small, medium and big companies as well as in the public service and healthcare sector. The application domain includes business process engineering, IT system implementation, certification support (ISO , ISO TS 16949, ISO 14000), etc. With MO²GO different levels of granularity can be described (Process hierarchy, Class hierarchy, Part-Of structures, Attributes and Values, Reference Attributes, Operations (Macros), Program Calls.). The user has the possibility to adapt the tool to his needs by adding classes, attributes, icons and macros. Reference structures and models can be used to start modeling or improve existing models. Models can be easily extended base on the presentation by pre- and post-condition using object state descriptions. Therefore also the interfaces within the collaborative business processes can be modeled easily. In order to utilize its advantages and to provide a comprehensive and expandable enterprise model, the IEM (Integrated Enterprise Modeling) method within MO²GO uses the object-oriented modeling approach, thus allowing the integration of different views on an enterprise in one consistent model as well as the easy adaptation of the model to changes within the enterprise (Figure 32). The generic classes Product, Resource and Order are the basis of the IEM method for developing models from a user s point of view. They can be further specified according to the targets of an individual modeling project e.g. an organization unit as a subclass of the IEM Resource class. IEM Product represents the principal results of the entire enterprise process. IEM Resource represents all means, including organizational units and IT systems, which are necessary to carry out any activity in the enterprise. IEM Order represents planning and control information. Each element of the IEM model can contain attributes defined within the class schemas. Business Process Object Class St ructure ure Information Model Process Chain Process Model Products Orders Resources Inheritance Order (State n) Action Order (State n+1) Product (State n) Action Product (State n+1) (red) (blue) (green) Resource (State n) Action Figure 32. Main views within MO²GO (Classes and Process Chains) Resource (State n+1) Required enterprise data and the enterprise business processes, e.g. the tasks referring to objects, are structured in accordance with the object classes. Furthermore, the relations between objects are determined. The result is a comprehensive description of tasks, business processes, enterprise data, production equipment and information systems of the enterprise at any level of detail _ATHENA_DA152_V10 PUBLIC Page 46 / 132

52 Document Deliverabile D A1.5.2 Date All related aspects within the company, that are part of processes, can be described by activities and their related objects. The execution of any activity requires direct or indirect planning and scheduling. Therefore, it is controlled by orders and executed by resources which posses the required capacities. The Generic Activity Model (Figure 33) represents the processing of objects of the class product, order or resource indicating the interactions of objects while processing. Involved organizational structures can be described by state descriptions of organization resource classes. Actions, functions and activities are combined to represent business processes by using the connection elements ( Split, Join, Decision ). The connection elements can contain further information about their logic (e.g. or, and, synchronized, etc.). The decomposition and aggregation of processes is supported on the action element. A detailed process is represented by a bold border around the action element. Basic Elements Connection Elements Description of object states Product Resource Order Connection between actions and objects or between actions. Process description Action Split: both processes run in parallel. Basic Structure of the Process model Generic Activity Model X = 1 X = 0 Decision: the process sequence depends on the object states following the decision element. control Join: different sequences are joining into one sequence. transformation support X = 0 X = 1 Loop: several iterations of process steps. Figure 33. Elements of MO²GO Process Chains Further modeling aspects related to special modeling purposes can be integrated as additional views on the model. A basic concept of process modeling is a hierarchical structuring of the business processes related to the object states entering the system and leaving the system (inputs and outputs). For a certain field of the company the modeler only studies the essential information about the processes regarding the modeling targets. Detailed studies are described on lower levels through connected sub-processes, global studies are described on superior levels through the whole process. The description of the object states within MO²GO models supports the system delimitation in projects and the extension of these models as well as the formation and linkage of subprojects. Figure 34 illustrates the linkage of subprojects along a fragment of the object life cycle of a product. The object states describe the pre- and post-conditions of the process _ATHENA_DA152_V10 PUBLIC Page 47 / 132

53 Document Deliverabile D A1.5.2 Date Product Idea Considered System Product at customer Product Idea Product Designing Process Product designed Product designed Subsystems Manufacturing Process Product produced The object states define the boundaries of the considered system (Processes) The IEM permits the linking of submodels or projects along the live cycle of the object. Product produced Trading Process Product at customer Figure 34. System Delimitation by Object States and Design of Subprojects The current product release is MO²GO 2.4c, but for research issues, an alpha prototype of MO²GO NG is used Modeling Framework The MO²GO meta-meta-model (Figure 35) consists of classes, objects, states and graphical representations of states. A class tree is the result of multiple deriving of new classes from existing ones, whereas initial inheritance is applied. MO²GO classes can participate in the usual single-parent inheritance relationships. Furthermore, the implementation of the PAR concept makes possible to have inheritance across sub-classes of the different generic classes: Product, Order, Resource (in German abbreviated to PAR). A PAR Object can have, in contrast to the other MO²GO Elements, multiple parent classes, which can be derived from different generic classes. In this way multiple inheritance is achieved. In MO²GO no difference is made between classes and objects. To be more precise classes are considered to be objects at the same time in this way every class can be instantiated to a state. States of one class/object are differentiated by their names and by the values of the attributes they inherit from the parent class/object. States can have multiple graphical representations within one modeling level and across different levels. All graphical representations of a state have the same name as the state. Changing an attribute value of one graphical representation results in changing the state s attribute value, and thus attribute values of all the graphical representations of the state. In contrast to POP*, MO²GO does not regard relationships between objects as objects, thus inheritance and other relations between relationships is not possible. The only relationships used in MO²GO are the connectors between the states and actions. The connectors, together with the logical elements, determine the process-flow in the model _ATHENA_DA152_V10 PUBLIC Page 48 / 132

54 Document Deliverabile D A1.5.2 Date Figure 35. MO²GO meta-meta-model Meta-modeling and Profiles MO²GO supports explicitly saving and loading of class hierarchies along with broad collection of typed class attributes. This feature enables the creation of different profiles. The class editor of MO²GO provides comfortable means to maintain complicated class structures, and in this manner provides meta-modeling facilities Mapping to POP* In many cases an almost one-to-one mapping is possible between MO²GO and POP* constructs. Nevertheless, there are some special cases, which need explanation. For the sake of readability in the following [X Y Z] will denote that each of the MO²GO or POP* elements X, Y, Z can be assumed to be there. Furthermore all MO²GO elements will be abbreviated with their first letter, e.g. [J S D] stays for Join, or Split, or Decision. MO²GO MO²GO Action Product Order Resource Join Split Decision Flow Connectors Control Connectors Element.Documentation Element.Name Control Connectors POP* Process (Property MoogoType = Action) State (Property MoogoType = Product) State (Property MoogoType = Order) State (Property MoogoType = Resource) Gateway (In-Flow-Logic = AND) Gateway (Out-Flow-Logic = AND) Gateway (Out-Flow-Logic = XOR) Flow Relationship hasorder, hasresource [Process State].Description [Process State].Name HasOrder, hasresource _ATHENA_DA152_V10 PUBLIC Page 49 / 132

55 Document Deliverabile D A1.5.2 Date Graphical Information Mapping Table MO²GO Detailed Action Graphical Representation POP* Containerview Objectview Specific Patterns Pattern MO²GO POP* f1 [A J S D] connector [A J S D] f2 [A J S D] - connector [P O R] - connector [A J S D] c1 [R O] ctrl connector Action c2 [R O] - connector - [Join Split Decision] ctrl connector Action [Process Gateway] flow [Process Gateway] 1.[Process Gateway] flow [Process Gateway] Member(flow, state) hasresource(process, State) hascontrol(process, State) hasresource(process, State) hascontrol(process, State) One difference between POP* and MO²GO is the ability of POP* processes to have more than one Input, Output, Control or Resource. In order to map correctly this constructs one to another, the import/export mechanism includes recognition of these patterns and creating of additional Joins on import (omitting unnecessary ones on export). Since Flows can go only between processes (or corresponding Inputs or Outputs, but not States), the typical MO²GO construct of Actions interconnected with connectors over [P O R] (see Table: Pattern f2) is mapped to a single Flow, which has the corresponding to [P O R] State as a Member. The Process hierarchy is given in MO²GO, unlike in POP*, not by explicit relationships, but implicitly, by the sub-layer an Action can contain. That is, the needed information for the Part relationships have to be extracted by traversing the layers hierarchy. The export of the graphical information follows similar structure as the export of the model information. The width of the Containerviews is computed as the difference between the X-coordinates of the most right and the most left elements contained by a sub-layer. Analogically do the height of a Containerview. A major issue of the MO²GO - POP* interface is the preserving of the original Ids on import, so that potential export can assign the same Ids to the imported objects. In MO²GO this is achieved by creating an additional attribute to each object, containing the Id of the imported object. Since in POP* the Relationships are objects also, and since there are still objects, which are being omitted on import, an image of all the Ids is kept in the model. In this way, while exporting the model, all objects can be written back correctly _ATHENA_DA152_V10 PUBLIC Page 50 / 132

56 Document Deliverabile D A1.5.2 Date Figure 36. Example process model in MO²GO IEM Implementation in MO²GO NG Alpha prototype for Research The MO²GO POP* Exchange is realized as a Java client for the MO²GO NG Server. It uses the Java API provided by MO²GO NG, which makes the model manipulating operations accessible from within the Java Programming Language. Thus, the act of export applies to the model, currently opened in the server, while an import from a POP* file loads at the same time the model in the server. The program uses the Document Object Model (DOM), which is well supported in Java. This allows for easy navigation through the XML tree, which is required because of the nonlinear transformation between the MO²GO and POP* models Challenges for further work The most important, incompletely solved issues are related to the graphical representation of the models. Since the tools do not have unified coordinate system and representation strategy the utilization of the graphical information exported by other tools is limited to some extend. In the next development phases some heuristics can be taken advantage of, in order to improve the layout of the imported model, so that it converges to the layout in the tool created it. 4.6 ARIS Client Support ARIS provides a generic and well-documented methodological framework. It uses a graphic modeling system supported by software which models data movement and tasks and is closely associated with SAP to which it can directly export models for incorporation in SAP systems. The ARIS-Tool set provides comprehensive computer support for business process modeling. The four modules of the toolset provide means for a computer-aided analysis, planning and introduction of managerial information systems. The systematic approach covers the entire modeling life cycle. The ARIS-Modeler focuses on system modeling. Based on the meta-structure of the ARIS framework, view-specific modeling methods are provided for computer based modeling. This includes extended entity relationship modeling as well as process chain diagrams, stimulus-response chains, and functional and organizational hierarchy charts. The ARIS-Modeler covers the model construction and storage part of the model management activities mentioned above. In order to transform enterprise models between enterprises it is envisioned to transform the models from different enterprise modeling standards to a common standard: POP*. To achieve this transformation, we provide for a transformation between the EPC models produced by the ARIS- Toolset and the POP* format. In this report we describe the conceptual underpinnings of this transformation. They are the basis for a Java program, which implements this concepts using DOM for XML transformation. The program imports and exports AML (ARIS Markup Language) files, which are used by the ARIS-Toolset to store ARIS models Modeling Framework The ARIS-architecture distinguishes between Organization, Function, Information and Control views. ARIS uses a modeling language known as Event-driven Process Chains (EPC), which is an important aspect of the ARIS-model _ATHENA_DA152_V10 PUBLIC Page 51 / 132

57 Document Deliverabile D A1.5.2 Date Process Modeling Language The method of event-driven process chain (EPC) has been developed within the framework of ARIS and is used by many companies for modeling, analyzing, and redesigning business processes. As such it forms the core technique for modeling in ARIS, and serves to link the different views in the so-called control view of ARIS. EPC is an ordered graph of events and functions. It provides various connectors that allow alternative and parallel execution of processes. Furthermore it is specified by the usages of logical operators, such as OR, AND, and XOR. A major strength of EPC is its simplicity and easy-to-understand notation. This makes EPC a widely acceptable technique to denote business processes. Figure 37. EPC Model example EPC Elements to be transformed Only the basic EPC elements are regarded for transformation. These Elements and their relationship are shown in the following figure. Figure 38. ARIS EPC Metamodel. These elements are extracted from AML Files, produced by the ARIS-Toolset. AML is specified by a DTD _ATHENA_DA152_V10 PUBLIC Page 52 / 132

58 Document Deliverabile D A1.5.2 Date Implementation of Transformation, Import and Export The following table show the EPC source elements and the POP* elements which are target of the transformation. EPC POP * Process Process Function Process AND-Split Gateway; out-flow logic = AND; OR-Split Gateway; out-flow logic = OR; XOR-Split Gateway; out-flow logic = XOR; AND-Join Gateway; in-flow logic = AND; OR-Join Gateway; in-flow logic = OR; XOR-Join Gateway; in-flow logic = XOR; Control Flow (Edge/Link) Relationship.Flow Event State Organizational Role of a function ProcessRole/ Role To generate AML file out of POP* files, the following mappings will be used: POP * EPC POP* Process EPC Process Decision Point Connector Flow Control Flow Flow carries - Flow state Event Gateway Connector Gateway.Activated - Gateway.ConditionalContinuation Function/Connector Gateway.Description - Gateway.inFlowLogic Connector Input Resource attached to function LogicalRelation - Output Only in extended EPC Output.activated - Output.conditionalContinuation - Output.name Only in extended EPC OutputDescription Only in extended EPC Play Role - Process Process Process.Description - Process.Finish-Time - Process.Name - Process.StateTime - Process.State Event ProcessRole _ATHENA_DA152_V10 PUBLIC Page 53 / 132

59 Document Deliverabile D A1.5.2 Date POP * ProcessRole.Activated - ProcessRole.Conditional_Continuation - ProcessRole.Description - ProcessRole.In-Flow-Logic - ProcessRole.Name Process.hasPart Resource Resource.Activated - Resource.ConditionalContinuation - Resource.Description - Resource.In-flow-logic - Resource.Name Role - EPC Organizational Role of a function Subfunction/Hierarchical Function Resource Resource (name) Challenges for Further Work The most not completely solved issues are related to the matching of various POP* and EPC elements. Until now, only the basic, process based elements of both languages are transformed. In the next development phases further dimensions (Organization, IT, etc.) have to be transformed. Further on, correct transformation of more complex sequences of the EPC control flow has to be ensured. 4.7 How to Integrate Another Tool Modeling tool vendors (or users) who wish to make their tools interoperable with our 5 modeling tools and the MPCE repository, should follow this procedure: 1) Define mappings between your modeling language(s) and POP*. 2) Implement some means of exporting models from your own format to the EKA XML format, and for importing EKA XML models into your tool. The current partners have applied techniques such as XML transformation (XSL), programmed interfaces (Java and.net), and model-configured transformations. 3) Test your implementation, e.g. utilizing the example models provided as appendices to this report, then try exchanging model files with existing MPCE tools. 4) Start using the web interface of the MPCE to share EKA XML models across the web. 5) Implement an MPCE client so that users can access MPCE models directly in you tools user interface 6) Define a metamodel of the language of your tool, and start utilizing the EKA view merging services to guarantee a loss-free roundtrip model exchange with other tools. Now you may also be able to establish direct interoperability with some of the specific language elements of one or more of the other tools, outside of the POP* core _ATHENA_DA152_V10 PUBLIC Page 54 / 132

60 Document Deliverabile D A1.5.2 Date Conclusions and Further Work This document has described the design and implementation of a joint platform for collaborative enterprise modeling, consisting of a repository and five different modeling clients. Across this infrastructure organizations are able to exchange and share process models, translating between the proprietary languages of the different tools. The key parts of this infrastructure are Enterprise Knowledge Architecture (EKA), a modeling framework and XML schema for representing any kind of enterprise models and enterprise modeling languages, MPCE web services that tools use to access models in the repository. Although the current ambition is limited to exchanging process models, the framework is defined to support any kind of user-oriented modeling language. For the next version, we will extend the platform to handle also other dimensions of the POP* modeling language core, such as Organizations Products IT Infrastructures Decisions etc. We will also utilize the extensibility of the platform to enable also extra-standard interoperability between some tools where that is beneficial. This first MPCE prototype stores complete models as files, while version 2 should provide an object repository with fine-granular loading, updates and access control. Appendix E lists a number of services that remains to be implemented, in particular in the areas of Knowledge, model and metamodel management and evolution, Integration of available services, applications and automated process fragments, Model execution and other forms of work performance support. View-orientation is another major direction for further research. We will utilize techniques from modeling, model execution and visualization to generate reflective interfaces purposed for the roles of the enterprise and adapted to the individuals that perform the roles. The table below contains the list of MPCE services and the scope for version 1 as defined in DA1.5.1, with the final column assessing what has been implemented. It shows that we are ahead of the schedule, especially in the metamodeling area. The integration of the MPCE with the active model execution platform developed by Troux in A6, also provides some services earlier than planned. Reorientation of other work packages has lead us to down-prioritize the areas of design patterns and dissemination, so there we have not complied with the original schedule. Finally, the decision to store models in the EKA format rather than the proprietary Metis format has made it impossible for us to directly utilize the sub-modeling and dependency tracking capabilities of Metis Team. These features will anyway be handled in a better way when we move to the object repository. Service Category ID Service V.1 Specification Current Status S1 Single sign-on service 100% 100% on server, not all clients S2 Group definition 50% S3 Flexible right definition 100% 100% Administration S4 Concurrent projects services 75% through A6 S5 Notification service S6 Define, modify and delete projects 75% through A6 Supporting enterprise S7 Work Management Services _ATHENA_DA152_V10 PUBLIC Page 55 / 132

61 Document Deliverabile D A1.5.2 Date operational work S8 S9 S10 S11 S12 Work Execution Services Work Monitoring services Simulation and Analytics services Storage of models and sub models Version and variant control 100% 100% for models, submodels not included 25% 100% for models, not for model elements Repository Management S13 S14 Dependency control in order to link or merge models Offline work capabilities 50% for process models S15 Backup and replication 100% backup 100% Merging 75% Model transactions 75% Dependencies across models 0% S16 Filtering service and Access control 100% access to models, 0% access to model elements S17 Search facilities S18 Platform Services Modeling and Management 20%, based on A % Multiple views management Develop EKA S19 S20 Enterprise modeling project definition services Model correctness and granularity control 25% through A6 S21 Developing Application Templates 50% (defined types) 90% Visual metamodeling with the EKA S23 Design pattern services 50% 0% (Not defined in B4 and A4) S22 Meta-model Extension and adaptation 25% 75% through explicit metamodeling of POP* in EKA, with version control S30 Meta-modeling at the class level 50% in the EKA S31 Meta-modeling at the instance level 50% in the EKA Language extension S32 S33 Managing class/type structures Managing property structures 50% in the EKA (inheritance not supported by the server) 50% in the EKA S34 Federated meta-models 50% through the EKA S35 S36 Manage behavior definition structures Flexible, multidimensional inheritance/ propagation 20% EKA contains state, but not task/process or rules Influenced the EKA design, but not implemented Integration S24 Standard API to Modeling Tools 50% (process models) 75% for models, not for model elements S25 Integration services to the standard IT World S26 Dissemination services as defined in _ATHENA_DA152_V10 PUBLIC Page 56 / 132

62 Document Deliverabile D A1.5.2 Date A1.4 S27 S28 S29 Legacy System Integration Data Integration Evaluation service _ATHENA_DA152_V10 PUBLIC Page 57 / 132

63 Document Deliverabile D A1.5.2 Date References 1) Jørgensen, H. D Interactive Process Models. PhD thesis, Norwegian University of Science and Technology, Trondheim, Norway, 2) RDF- Resource Description Framework, 3) OWL Web Ontology Language, 4) Xlink XML Linking Language, 5) MOF Meta-Object Facility, 6) XSD XML Schema Definition languages, 7) RDF XML Syntax Specification, 8) IETF "RFC 2141: URN Syntax", R. Moats, May Available at 9) XML Schema Definition for RDF, unofficial, 10) Augeraud, M. & Freeman-Benson, B. N Dynamic Objects, ACM Conference on Organizational Computing Systems (COOCS), Milpitas, California, USA. 11) Berger, P. L. & Luckmann, T The Social Construction of Reality. A Treatise in the Sociology of Knowledge. Penguin Books, USA, 12) Kangassalo, H Are Global Understanding, Communication and Information Management in Information Systems Possible?, in P. P. Chen, J. Akoka, H. Kangassalo, and B. Thalheim (eds), Conceptual Modeling. Current Issues and Future Directions,. Berlin: Springer LNCS ) Kiczales, G Beyond the Black Box: Open Implementation, IEEE Software, vol. 13, no ) Lillehagen, F The Foundation of the AKM Technology, in Jardim-Gonçalves, Cha & Steiger- Garção (eds), Concurrent Engineering, Enhanced Interoperable Systems: , Rotterdam: Balkema. 15) OMG Meta-Object Facility Specification Version 1.4, 16) Opdahl, A. L. & Sindre, G Facet Modelling: An Approach to Flexible and Integrated Conceptual Modelling, Information Systems, vol. 22, no ) Solheim, H.G., Lillehagen, F., Jørgensen, H.D., Karlsen, D. & Smith-Meyer, H. 2005, Obliterating the border - Concurrent modeling and execution platform, Proceedings of CE 2005, in press. 18) Styhre, A Thinking with AND: Management Concepts and Multiplicities, Organization, vol. 9, no ) Taivalsaari, A On the Notion of Inheritance, ACM Computing Surveys, vol. 28, no ) Wegner, P Why interaction is more powerful than algorithms, Communications of the ACM, vol. 40, no ) Wenger, E Communities of Practice. Learning Meaning and Identity. Cambridge University Press, UK. 22) Bryant, C. OWL The Basic Elements, 23) BPMI, Business Process Modeling Notation BPMN, 24) Metacase, MetaEdit+ product documents, _ATHENA_DA152_V10 PUBLIC Page 58 / 132

64 Programme Integrating and Strengthening the European Research Strategic Objective Networked businesses and governments Integrated Project / Programme Title Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application Acronym ATHENA Project No ATHENA Project Name Enterprise Modeling for Collaborative Enterprises ATHENA - Project No A1 Deliverable D.A1.5.2 Appendices to Collaborative Modeling Platform - 1st Prototype Work Package A1.5 Leading Partner: Troux Technologies AS Contributors: Fraunhofer IPK, ESI, Itrec, DFKI Security Classification: Public July 2005 Version 1.0

65 Table of contents Appendix A Elucidation of Key Concepts...59 Appendix B Related Standards...60 B.1 Meta Object Facility (MOF) and XML Metadata Interchange (XMI)...60 B.2 Resource Description Framework (RDF)...60 B.2.1 Identity of resources...60 B.2.2 Classification...61 B.2.3 Typed resources...61 B.2.4 RDF/XML...61 B.2.5 RDF Reification...61 B.2.6 RDF Schema...61 B.3 Web Ontology Language (OWL)...61 B.3.1 OWL XML Presentation Syntax (OWLX)...62 B.3.2 Semantic Web Rule Language (SWRL)...62 B.4 Mapping OWL and RDF to the EKA Core...62 B.5 Comparison with Standard Frameworks...64 B.5.1 XML Schema Data Types...66 Appendix C Semantic Definition of the EKA...67 Appendix D EKA XML Examples...69 D.1 Definition of the POP* Process Dimension...69 D.2 Tool Specific Metamodel View...73 D.3 Role Example...74 D.4 Process Model Example...75 D.5 Specification of Visual Features...79 Appendix E Server Implementation Details...83 E.1 Properties for Users and Groups...83 E.2 Administration Services for Later Versions...83 E.3 Metadata Management Details...83 E.3.1 Services For Later Versions...84 E.4 Knowledge Management Services for Later Versions...85 E.5 Execution Services for Later Versions...86 E.6 Integration Services for Later Versions...86 E.7 WSDL Specifications...86 E.7.1 Authentication...86 E.7.2 User administration...88 E.7.3 User group administration...95 E.7.4 Access control E.7.5 Model repository E.7.6 EKA services for view merging E.7.7 Version control E.7.8 Dependency control E.7.9 Metadata management _ATHENA_DA152_AP_V10 PUBLIC Page ii / 132

66 List of Figures Figure 1. OWL metamodel Figure 2. XSD datatype hierarchy _ATHENA_DA152_AP_V10 PUBLIC Page iii / 132

67 Appendix A Elucidation of Key Concepts Aspect: A set of inter-dependent model elements that are used together (typically properties, behavior and other features). Elements may for instance have one aspect for each dimension, and aspects can be used as composeable types for objects in order to combine behavior and data structures needed. Aspects and dimensions are also important structures for meta-model and language evolution management. Dimension: A factor in the description of something. Dimensions are applied to organize the POP* common language. In clarifying the meaning of a term, defining its representation in each dimension is a useful approach, taken e.g. in the UEML (Unified Enterprise Modeling Language) in the Interop network. EKA: Enterprise Knowledge Architecture, the metametamodel used by the MPCE, reflected in the XML format used for model exchange. Inheritance: Reuse (of some part or aspect of a description) from one element to another along explicit and derived relationships in a model. Inheritance can be strict and complete, enforcing the subtyping principle, or partial and flexible [19], and it can be implemented by lookup/delegation or propagation of the reused specifications. Meta: A relationship between two views (or model elements) where the meta-element contributes to the interpretation of the element. The meta-element can be viewed as lying behind the element. Each element can have multiple meta-elements from different dimensions. Most modeling frameworks utilize meta-data from the systems dimensions, defining how the data is stored. The EKA allows any number of meta-elements to be combined flexibly, e.g. to add behavior definitions (the meta-process) or roles and responsibilities for using, maintaining and managing the elements (the meta-organization). Model: See view. MPCE: Modeling Platform for Collaborating Enterprises. An open specification of a general enterprise model repository, utilizing the EKA XML format. The term also refers to the currently implemented repository, built on top of Metis Team 3.6. POP*: Process, Organization, Product, etc. The common modeling language core defined by the ATHENA project, organized into dimensions. Reflection: A view is reflective of another if it contributes to the interpretation of it, i.e. if there is a meta-relationship between them. A modeling architecture (or element) is reflective if it combines elements and meta-elements into one, for instance like the EKA elements contain both data (property values) and meta-data (property value types). Semantic atomicism: The doctrine that the meaning of each element should be defined of and by itself, independently of the rest of the model, such as encapsulation in object-oriented systems. Semantic molecularism: The doctrine that the meaning of an element may depend on a small set of explicitly related neighbor elements, such as conventional object-oriented inheritance, Semantic holism: The doctrine that the meaning of an element depends on the meaning of all the other elements in a model (or web of beliefs). View: A representation of some aspects of some parts of reality, as interpreted by some actor(s). This definition is the same as that of a model in [20], but we prefer the term view because model carries connotations of objective, rational and complete representations, whereas views are subjective, partial and incomplete. A view can be a filtered presentation of a larger information base. However, when there are interoperability problems, there is no common information base for the different views. This implies that our views must be able to exist independently, and they can be reflective, including metadata (mate-processes and organizations etc.) as well as data _ATHENA_DA152_AP_V10 PUBLIC Page 59 / 132

68 Appendix B Related Standards This section surveys the existing standards MOF, RDF and OWL, in order to assess how well they support the requirements discussed in section 2. After we have defined our own approach, a more elaborate comparison is presented in section B.5. B.1 Meta Object Facility (MOF) and XML Metadata Interchange (XMI) MOF [5] is the OMG s metamodelling framework for software development. It is based on object oriented programming languages, and thus suitable for describing program structures. Its usefulness for multi-dimensional enterprise models is contested. There are a number of reasons why a MOF/XMIbased model interchange format will not enable the reflective, multi-dimensional definition of POP* models and languages: MOF aims to support design-time modeling of software systems, not runtime operational models of enterprises. These two contexts differ strongly in required user competence, usage focus, repository access patterns (update granularity and frequency) etc. MOF is designed for storage and exchange of meta-data, not data. Although the OMG Common Warehouse Metamodel standard (CWM) has extended XMI with instance data repositories, the solution is far from ideal. MOF handles unforeseen exceptions at the instance level (such as the addition of a property or a relationship) poorly. MOF does not support instance evolution, where different classes may reflect different states in the lifecycle of an object [10]. Strict inheritance rules are too rigid for evolving systems, where cancellation inheritance is needed (allowing removal of inherited features) [19]. Metamodeling is only possible through classes that are instantiated, and not e.g. through templates that are copied (which is easier to grasp for most non-software-engineers). Modeling and metamodeling is done in different ways, using different concepts. This complicates the user experience. The single instantiation class condition of strict metamodeling prohibits multi-dimensional metastructures and aspect-oriented modeling. Aspects or facets [16] cannot be used to extend the local meaning of a concept through mix-in inheritance. When multiple instantiation is prohibited, it becomes difficult to capture multiple dimensions of an element. MOF thus locks you into a rigid, one-dimensional meta-level hierarchy. It handles meta-data-structures, but not e.g. metaprocesses. Properties are treated as second class elements, existing only as part of an object. There is poor support for decomposing and specializing properties into attributes, parameter trees and multiple value sets, and you cannot classify or describe properties with properties, making it more or less impossible to manage property structures. research has demonstrated that property-based languages are much more efficient (simpler, more flexible and more expressive) than classoriented approaches [1]. Relationships are seen as simple one- or two-way links. The tasks and decisions that create and maintain a relationship cannot be captured, making it difficult to grasp the precise meaning and status of each link. Such weaknesses should be removed in an enterprise knowledge architecture. XMI does thus not provide what is needed, and it adds significant overhead and unwanted restrictions which make it impossible for us to apply most MOF concepts directly. B.2 Resource Description Framework (RDF) The resource description framework is a W3C recommendation [2]. It provides a way of describing a resource (subject), its parameters and the values of these parameters. For example one may say that the resource has an owner (a parameter), which is Computas (value, or object). B.2.1 Identity of resources All resources (entities) defined in a document are uniquely identified with the URL of their document and appending # and their rdf:id. To be able to move a document containing resourcedefinitions, we should use the xml:base attribute. Then, that attribute will define the first part of the URI instead of this being defined by the document URL _ATHENA_DA152_AP_V10 PUBLIC Page 60 / 132

69 B.2.2 Classification Classification in RDF is done by the attribute rdf:type. This attribute shall point to a resource (URI) that represents a class. RDF itself cannot describe application specific classes, but this can be done using RDF Schema. An RDF resource can have more than one type. B.2.3 Typed resources RDF may have typed resources, and this may be abbreviated. This means that instead of writing <rdf:description <rdf:type rdf:resource= /thetype> you write <myvocabulary:thetype rdf:id= item234 > rdf:id= item234 > which means the same thing (if myvocabulary refers to the right namespace etc). If we develop a POP* vocabulary, we could write something like this: <rdf:rdf> <popstar:process <popstar:name>myprocess</popstar:name> </popstar:process> </rdf:rdf> rdf:id= 123 > In the above example, the popstar namespace refers to our RDF descriptions of various classes etc. We could also envision using other namespaces like dc referring to Dublin Core, a set of standard RDF properties. B.2.4 RDF/XML The XML produced writing RDF-compliant XML can look like XML that is not RDF-compliant, by using the type abbreviations and namespaces as shown in the last example. B.2.5 RDF Reification This mechanism allows statements to be written that describe the RDF statements themselves, like who entered particular information about a resource. This enables reflection and reuse. Reification is implemented by assigning an rdf:id attribute to the element that one wants to reuse, define relationships to etc. (Elements with no ID are called anonymous.) B.2.6 RDF Schema RDF schema is used for defining RDF vocabularies, mainly as classes and properties, as illustrated in section B.2.3 above. B.3 Web Ontology Language (OWL) OWL [3] is defined as an RDF Schema [2]. It provides a type system on top of RDF. This system is illustrated below. It facilitates definition and classification of property structures as well as class structures, and is in this respect better suited for our purpose than MOF. You may also define restrictions such as cardinality, range and domain on properties, and classes that are derived from property values _ATHENA_DA152_AP_V10 PUBLIC Page 61 / 132

70 Figure 1. OWL metamodel The main purpose of OWL is to describe an ontology, consisting of essential facts about the world. Probably because of this focus on a single consistent (often formal) as-is-model, it does not handle the dynamics of modeling well. There are e.g. no good template or instantiation mechanisms for creating new objects. Potential behavior and properties that members of a class should have can only be defined through absolute restrictions on the class, and you are often required to define conventional features that are instantiated for each object of a class (as in UML). Further problems with OWL include: 1) The property describes its class ( domain ). This means that a property cannot be reused across all classes or on new classes unless they are subproperty of existing ones. 2) The property describes the connection rules and cardinality, which is limiting. B.3.1 OWL XML Presentation Syntax (OWLX) The XML presentation syntax for OWL defines an alternative to the RDF/XML notation for OWL ontology models. The syntax seems more rigid than RDF, and it makes reflective modeling and classinstance duality cumbersome. B.3.2 Semantic Web Rule Language (SWRL) SWRL merges OWL and RuleML, and may thus be relevant for expressing restrictions and other rules. B.4 Mapping OWL and RDF to the EKA Core OWL and RDF contains a number of specific elements that we may directly map to core EKA concepts. The mapping table below thus allows conversion of RDF Schema and OWL fragments into the POP* notation (which extends the capability of the specification). RDF or OWL element EKA element Comment rdfs:class, rdfs:resource owl:class owl:thing, rdf:description Object Object There is no difference between metalevels in POP* rdf:property Property or Relationship Depends on whether the range consist of objects or plain values owl:objectproperty owl:datatypeproperty owl:haspropertyvalue rdfs:subclassof rdfs:subpropertyof rdf:type Relationship Property Property Is Is Is-a There is no difference between metalevels in POP* There is no difference between metalevels in POP* rdf:datatype datatype Is connects two Objects, but not an object to a literal value type. rdf:resource resource RDF constructs is applied for _ATHENA_DA152_AP_V10 PUBLIC Page 62 / 132