Model&Metamodel, Metadata and DocumentRepository for Software and Data Integration

Nikola Milanovic, Ralf Kutsche, Timo Baum, Mario Cartsburg, HaticeElmasgunes, Marco Pohl, and Jurgen Widiker

Technische Universitat Berlin{nmilanov,rkutsche,tbaum,mcartsbg,helmas,mpohl,jwidiker}@cs.tu-berlin.de

Abstract. Model-based software engineering (MBSE) projects requireand generate numerous artifacts. While MBSE methodology and designtools have reached certain maturity level, the issue of artifact persistenceand management has been somewhat left in the background. We presentdesign and implementation of the repository that supports storing andmanaging of artifacts such as metamodels, models, constraints, meta-data, specifications, transformation rules, code, templates, configurationor documentation, and their metadata.

1 Introduction

Model-based software engineering (MBSE) projects consume numerous artifacts,such as (meta)models, constraints, metadata, transformation rules, code or doc-umentation. While MBSE methodology and modeling tools have reached a levelof maturity, this is not the case with artifact persistence and management. Theefficient management of the MBSE-artifacts is an important prerequisite for theadoption of the model-based paradigm. We present design and implementationof the repository that supports storing and managing artifacts and metadata inthe model-based software and data integration process.

The repository is part of the BIZYCLE interoperability platform, a joint in-dustry/academy R&D effort to investigate in large-scale the potential of model-based software and data integration methodologies, tool support and practicalapplicability for different industrial domains [1, 2]. The consortium consists ofsix industrial partners and academia and is part of the program of the Ger-man government, the Berlin-Brandenburg Regional Business Initiative BIZY-CLE (www.bizycle.de). The long-term goal is to create a model-based tool gen-eration and interoperability platform, in order to allow for improved and par-tially automated processes in software component and data integration. Theseintegration tasks are performed by experienced software engineers and applica-tion experts, manually programming the connectors i.e. the glue among softwarecomponents or (sub)systems. This requires domain-specific as well as integrationrequirements’ analysis skills. It is a very expensive procedure, estimated between50 and 80 per cent of the overall IT investments (see e.g. [3]). In order to re-duce this cost factor, the BIZYCLE initiative develops a methodology, tools andmetatools for semi-automated integration according to the MDA paradigm.

The BIZYCLE repository supports management and persistence of all com-plex artifacts generated during the BIZYCLE integration process. The mainfeatures of the BIZYCLE repository, that are focus of this paper, are artifactand metadata definition, repository architecture, and artifact management ca-pabilities such as versioning, merging, and consistency control.

2 Related Work

The BIZYCLE repository is based on the Analytical Data on Artifacts andModels (ADAM) project, prototypically implemented at TU Berlin[4]. ADAMsupports integration and development of software components by providing thepossibility of storing artifacts, their metadata and relationships between arti-facts. However, ADAM does not support some essential repository features re-quired in large integration projects e.g., access and version control.

Since the early 90s several repository and SWE coordination approaches havebeen developed in the OOSWE community, their ideas are meanwhile part of allrecent approaches. One of those is Fedora[5] which distinguishes between contentand metadata persistence. Similar are OSCAR [6], enabling hierarchical man-agement and artifact version control, and ADAMS [7], supporting distributedsoftware engineering process by managing artifacts and relationships betweenthem. Another open source repository tool, NetBeans Metadata Repository [8],is an extended implementation of MOF, which provides a JMI [9] based interface.

Repositories are also applied in commercial modeling and enterprise processmanagement tools, such as Adaptive Repository, Aqualogic Enterprise Reposi-tory, ASG/Rochade etc. (detailed list can be found in [10]), but they are mostlyused in runtime for documenting business metadata definitions and businessrules/processes, monitoring and generating key performance indicators throughdata analysis, or performing risk analysis. Management of design-time artifactsis partially supported in modeling tools such as IBM Rational Asset Managerand MagicDraw Teamwork Server.

Repositories should address other aspects of content management like versioncontrol and model merging. In [11], the OMG Group provides an extension forMOF to attach versioning data to model elements. Alanen and Porres propose in[12] an algorithm for metamodel-independent difference calculation, merging of amodel and union of two models. It is based on elementary transformation stepslike creation, deletion or modification of model elements. On the metamodel-independent level merge conflicts cannot be resolved automatically, because thealgorithm does not ensure the conformity of the resulting model to its meta-model. In the approach to the cross-language version management of models[13], Storrle formally defines version management by creating a common con-ceptual domain. Models are transformed into a common meta-metamodel forcapturing differences. Additionally binding metrics are proposed for computingof similarity of two models. However, automatic merge conflict resolution is im-possible. In [14], Hnetynka and Plasil propose distributed versioning model basedon location identification for versioning support in distributed environments.

3 BIZYCLE Repository Information Model

The BIZYCLE repository has two principal roles: 1) to store and manage theartifacts produced in the context of the model-based software engineering projectand 2) to store and manage metadata about the artifacts. In our terminologytherefore, we distinguish between the content and its metadata, both of whichare stored and managed in the repository (see information model in Figure 1).

Artifact is the most general abstraction concept and category whose contentand metadata are managed in the BIZYCLE repository. The following artifacttypes are explicitly supported: metamodel, model, code, internal description andtransformation rule. A model is an artifact representing any kind of modelingabstraction, created and managed by a modeling tool. In this implementation,models are limited to UML and DSL models and persisted in XMI format. In-terfaces to our GMF-based custom modeling tools have been realized, effectivelyenabling these tools to use the BIZYCLE repository as model and metamodelpersistent storage. Each model artifact is an instance of a metamodel artifact,which are also persisted. Transformation rules are artifacts describing how totransform one model into another, and are defined at the metamodel level.Currently we support transformations given in ATL. Code artifacts representthe code generated during the model-based engineering project, not limited tosource code only but including e.g., platform-specific deployment descriptors.Finally, internal description refers to documentation manually or automaticallygenerated during the project (it should not be confused with the external docu-mentation which is provided up front). Each artifact may have its specific dataassociated with it (ArtifactSpecificData), which can be customized as a set of(key, value) pairs. For example, a user can define keys such as ToolName andToolVersion to store the information about the modeling tool used to produce amodel artifact. Artifacts are also annotated with external description, which isdocumentation about the artifact that is provided before the project has started.It can be stored in an external content-management system and just referenced,or physically stored (imported) in the BIZYCLE repository. External descrip-tion covers documentation (e.g., requirements specification, interface list, man-ual), semantics (taxonomy, standards, thesaurus, ontology, glossary), componentmetadata and runtime data (log files, settings, statistics).

Each artifact has associated internal metadata as well as relational metadata.Internal metadata describe artifact name (label), identifier, creation/modificationdate, description, subject/keywords, status, creator and contributors. An artifactis furthermore owned by users, has permissions associated with it and belongsto one or more projects. More about user-, role- and project-management willbe given in Section 5, Artifact Management.

Of more interest are the relational metadata that describe relations betweenthe artifacts, as they build the foundation for the consistency checks. We de-fine the following eight standard meta-relations. IsCopyOf marks an artifactwhich has been duplicated and saved into the BIZYCLE repository as a copy.IsAnotherRepresentationOf denotes the identical artifacts which are persistedusing different formats. An example is an artifact of the type Model which has

-id{readOnly}-creationDate{readOnly}-description [0..1]

...

ArtifactArtifactVersionIdentifier

TransformationRules

ExternalDescription

ArtifactSpecificData

InternalDescription CodeArtifact MetaModel

Permission

Relation

Project

Model

User Role

IsDocumentedBy

IsDocumentedBy

IsDescribeddBy -document0..*

-artefact

0..*

IsInstanceOf

IsInstanceOf 10..*

hasMetaData11..*

isIdentifiedBy

1 1

owns

0..*

1

IsDescribedBy

0..*

0..*

IsTransformationTargetOfIsTransformationTargetOf

-source0..1

-target0..*

IsSpecializationOfIsSpecializationOf-spec0..*

0..1-gen

IsPartOfFlowIsPartOfFlow

IsCopyOfIsCopyOf0..*

0..*

IsPartOfIsPartOf

-part1..*

-compound

1..*

IsOtherRepresentationOfIsOtherRepresentationOf0..*

0..*

belongsTo

Specifiy

-transformation0..*

-rules

0..*

holds

0..*0..*

History

+previousVersion

{ordered}0..*

+nextVersion

0..*

PartOf

-compound1..*

-part 1..*

RelatesTo

0..*

0..*

concerns1

1..*

has0..*

1

Fig. 1. BIZYCLE Repository Information Model (excerpt)

been stored in XMI format, and then converted to another artifact of the sametype and saved in RDF format. IsTransformationTargetOf groups artifacts whichare required to perform model transformation, that is, binds source and targetmetamodels and models with the transformation rules used to perform the trans-formation. IsPartOfFlow is a meta-relation which is specific to the integrationprojects, and it groups artifacts that cooperate in a business process, describedas activity (flow) diagram. IsPartOf marks artifacts that are parts of other arti-facts using the subset semantics. For example, a complex metamodel or a modelmay be divided in parts that are managed separately. This relation plays animportant role in the artifact locking and merging, as explained in Section 5.3.IsSpecializationOf denotes artifacts that are on the different level of abstraction,and orders them using generalization/specialization semantics. IsInstanceOf de-fines relationship between model and metamodel artifacts and is also used by themodel checker to check consistency. Finally, IsDocumentedBy relation describesthat artifact of the type Internal Description documents any other artifact type.Similarly, relation IsDescribedBy performs the analog for the external descrip-tion documents. All meta-relations inherit from the generic Relation, which canbe further extended according to the specific project needs. This is the way tocustomize meta-relations among the artifacts. Artifact version metadata, suchas version number, history and lock status, are stored in the ArtifactVersion-Identifier, which will be detailed in the Section 5.3.

4 Design of the BIZYCLE Repository Architecture

The BIZYCLE repository architecture consists of several sub-components andtwo access layers. Tools that use the BIZYCLE repository access its API viathe Remote Access Layer. External utility tools, such as theorem prover, modelchecker, user management and model merging components, communicate withthe BIZYCLE repository via the Tool Access Layer. In the following section, thedetails of each sub-component or layer are given.

Fig. 2. BIZYCLE Repository Architecture

4.1 External Components and Remote Access Layer

The Configuration Manager is the configuration interface of the BIZYCLErepository. It makes use of the Artifact and Metadata Manager to define artifacttype hierarchy, their metadata, constraints, consistency criteria and rules. It ispossible to define an artifact type hierarchy in order to group metadata whichare used for different artifact types.

The Project Manager is used to create and manage projects. This includesthe management of users and their roles and authorization to access artifacts.It is also possible to import external artifacts that are created using tools that

do not connect to the BIZYCLE repository via the Remote Access Layer (e.g.,existing external descriptive documents).

The Remote Access Layer provides the interfaces to external tools suchas model editors, transforation engines, conflict analyzers or code generators,allowing them to store and retrieve artifacts and their metadata. The BIZYCLErepository API is exposed at this layer. It features methods for transactionalprocessing of the artifacts and allows for executing search and retrieval methods.Interfaces provided in this layer are exposed as J2EE session bean facade to Javaclients and as WSDL endpoints (Web Services) to SOAP clients.

4.2 Core BIZYCLE Repository Components

The core BIZYCLE repository components provide the functionality needed tostore and process artifacts and their metadata. Artifacts may contain metadatawithin their serialized form, e.g., an XMI file which contains extra informationas annotations. They may also be provided together with metadata by externaltools, e.g., use the BIZYCLE repository API to transmit an artifact and an extrapiece of information containing the associated metadata. Some of the metadataare computable and have to be extracted by processing the artifact contents.To track and enable these artifact properties, any artifact type must be regis-tered with the Artifact Manager component together with its consistency andmetadata extraction policies.

The Repository Management component is responsible for the properBIZYCLE repository operation. This includes providing extraction policies, meta-data schemas, consistency rules and transactional processing of artifact andmetadata updates. It makes use of the external User Management compo-nent to manage access to the artifacts based on rights. Sub-components of theRepository Manager are the Consistency Keeper, the Metadata Manager andthe Artifact Manager.

The Artifact Manager is used to register the artifact types which maybe stored in the BIZYCLE repository. For each artifact, there must be definedwhat MIME types are allowed, what metadata exist, how it can be generated,acquired and processed. These we call extraction policies for the metadata. Also,consistency rules are defined for each artifact and its metadata. Those rules areused by the Consistency Keeper. The Artifact Manager uses the RepositoryCore to access the Metadata and Artifact Storage sub-components. Consistencyrules are repository-internal metadata for the artifacts and are stored using theMetadata Storage sub-component.

The Metadata Manager uses the extraction policies to process the meta-data which have been either provided together with the artifact or have been de-rived by computational means. It uses the Metadata Storage via the RepositoryCore to save the extracted or provided metadata. The Consistency Keeper isan inference mechanism used for any repository transaction. It processes the con-sistency rules defined for each artifact type to examine the effect of the changesto the artifact in question. It may invoke external applications to validate theconsistency of the artifact before committing the transaction, e.g., when a new

version of a model is checked in to the BIZYCLE repository, a consistency ruledefined for this artifact type might require checking whether the artifact is con-sistent with another artifact, namely its metamodel. The Consistency Keeperthen calls a model checker via the Tool Access Layer to evaluate the rule andcommunicates the result.

The Repository Core component provides the basic persistence functional-ity which is used to store metadata and artifacts in the backend databases. Thisincludes transactional processing of the database queries, managing referentialintegrity between the artifact and metadata databases and search functionality.

4.3 External Utilities

The Tool Access Layer is used to access external utility programs: theoremprover, model checker, user manager and model merger. Theorem Prover isan external tool used to verify consistency rules. It evaluates logical expres-sions which have been defined and stored using the Artifact Manager. ModelChecker is used to check model artifact consistency by applying the commonmodel checking methods, such as valid metamodel instantiation or integrity con-straints. The User Management component is used for user authentication.It supports user and role management and performs authentication and autho-rization. Data access right within the repository are determined by assigning theroles within the Project Management component.

4.4 Persistence Layer

The persistence layer comprises Metadata Storage and Artifact Storage com-ponents. The Artifact Storage component manages the storage and retrievalof the artifacts. It encapsulates access to the underlying physical storage. Thefollowing storage mechanisms are supported: file system, relational database andXML database. The Metadata Storage component performs the storage andretrieval of metadata in the underlying databases. This includes metadata usedfor the operation of the BIZYCLE repository, e.g., which artifact types are al-lowed, what consistency rules are defined for them, all version information, aswell as metadata about the artifacts that can be queried. The relational databaseis used for both types of metadata. The persistence layer enables transparentaccess as well as migration of the underlying content storage, e.g., a file sys-tem may be easily substituted with the relational database for storing content(model) data.

5 Artifact Management

The repository supports the following management options: project manage-ment, user control, artifact versioning, artifact merging and consistency preser-vation. These mechanisms are investigated in the following sections.

5.1 Project Management

The BIZYCLE repository is an important source of information for the man-agement, development and maintenance of the MBSE artifacts and projects.A project consists of a collection of various artifacts that are related to eachother (Fig. 3). These artifacts are produced by the various development tools(e.g., model editor, code generator). The Configuration Manager component isused to define artifact types and their metadata schemas, so that the BIZYCLErepository is enabled to store the artifacts and their relations. Using the ProjectManager component, projects as well as project-specific constraints and consis-tency criteria are defined. Furthermore, artifacts are selected and assigned to oneor more projects. Roles and the associated access rights are defined accordingto the intended integration workflow. Project Manager also enables tracking ofthe integration workflow progress. It is possible to define project configurationsbased on labeling mechanisms, e.g., one configuration can be a certain projectview or release. The User Management component is then used to create andmodify user information and assign project-specific roles to users.

ExternalDescription

Artifact

-id{readOnly}-creationDate{readOnly}-description [0..1]

...

User

-account : String-password : String-firstName : String-lastName : String-description : String-modifiedOn : date-modifiedBy : User

Project

-name : String-description : String-creationDate : date

Role

-name : String-description : String-modifiedOn : date-modifiedBy : User

Permission

-name : String-read : boolean-write : boolean

...

owns 0..*

1

IsDescribeddBy

-document0..*

-artefact

0..*

belongsToholds0..*0..*

concerns1

1..*

has0..*1

Fig. 3. Project Management and User Control

An artifact can belong to more than one project. An example is a sharedmetamodel or the common model transformation rules, which can be used inmany scenarios, but still have to be kept consistent and centrally managed. Suchshared artifact is created once (by its owner), and then can be imported intoother projects by the creator or other user, depending on the rights. Non-sharedartifacts have their owners, too.

5.2 User Management

Users are project members who are identified by their accounts and names. Usersare assigned one or more roles which determine their access rights (permissions)

in the BIZYCLE repository. Roles furthermore belong to projects and can beredefined on the project level. One user may have multiple roles in one or moreprojects. They define the activities and responsibilities and determine the al-lowed artifact access and manipulation level. For example, a user in a specialrole can make changes to particular artifacts (such as models), but he would haveonly read-only access to most artifacts (such as metamodels or transformations).The level of access for each role is defined by permissions. The management ofusers and artifact types are reserved for the BIZYCLE repository administrator.The project administrator can create projects, select artifact types, and assignroles and permissions. Other user roles (apart from repository and project ad-ministrator) are customizable and can be dynamically added.

5.3 Artifact Versioning

During their life cycle artifacts undergo a series of revisions. To reconstructan old state of an artifact, applying versioning principles is essential. Katz [15]defines version as a semantically meaningful snapshot of a design object at apoint in time and describes a design object as an aggregation of design datatreated as a coherent unit by designers. Our design objects are artifacts likemetamodels, models, transformation rules, generated code or documentation andtherefore each version of an artifact represents one of the artifact’s (historical)states. During the duration of an integration project, creating and maintaininga significant number of different versions of the same artifact is inevitable.

In order to support versioning, an appropriate version model is required. Aversion model defines which items in the BIZYCLE repository are to be ver-sioned, which properties (attributes) are shared by all versions, how versions areto be organized and identified. It must also define operations for creating newversions and retrieving existing versions [16].

The versions are traditionally classified in revisions and variants. Revisionsare versions of the same item which are created to supersede its predecessor andcan be ordered along the time dimension. Variants (branches) are versions ofthe same item which can occur in parallel at a given time. While new revisionssupersede old revisions, variants do not replace each other. The set of all revisionsand variants is called a version group [16, 17]. A trunk contains all revisions whichrepresent the main line from the first version. Branches are used to representthe variants that exist in parallel. Sometimes two users have to concurrentlymake changes to an item. The concept of branch allows users to work in parallelon different versions of an item. A merge combines two versions from differentbranches into a new version in one of the branches.

All versions of an item which are often called a version group can be seen as”incarnations” of the same item. This requires a ”sameness criterion” to decidewhether two versions are versions of the same item [17]. The decision can beperformed by using a unique identifier. All versions of an item must have thesame unique identifier which identifies the versioned item. Within a versioneditem, each version must be uniquely identifiable by a version identifier. With theprospect of having distributed repositories, items must also be globally identified.

All versions of an item must carry item’s identifier and a version identifier whichmust be unique in item’s version history.

ArtifactVersionIdentifier

-changeLogEntry-isLocked-id{readOnly}-label [0..*]{readOnly}

...

+addLabel()+checkIn()+checkOut()+createVersionedArtifact() : ArtifactVersionIdentifier+delete()+lookUpByVersionID() : Artifact+lookUpByLabel() : Artifact+lock()+unlock()+update() : Artifact+removeLabel()

Artifact

-id{readOnly}-creationDate{readOnly}-description [0..1]

+delete()

History

+previousVersion

{ordered}

0..*

+nextVersion

0..*

isIdentifiedBy

1 1

Fig. 4. Version Model

The version model supporting these requirements is illustrated in Figure 4.The number of potential versions of an artifact created during the integrationprocess is clearly large, and the relationships between revisions (iterations) andvariants may be complex. One of the important tasks of versioning is how to or-ganize these versions within the BIZYCLE repository, and how to describe themso they can be properly found and understood by users. In our versioning model,each artifact is identified by a globally unique identifier id. Particular versions ofan artifact are identified by the ArtifactVersionIdentifier which must be uniquein artifact’s version history. The artifact history is expressed by the History as-sociation. The complete history of a versioned artifact, including branches forartifact variants and merges, are described by storing the predecessors and suc-cessors. Labels may be used to mark certain artifacts, e.g., to allow developersto name and restore a particular state of a project.

Another important versioning facility is allowing the user to define versionstates which describe the lifecycles of artifacts. The possible states can be de-scribed in a taxonomy provided by project management and used to label certainversioned artifacts. The method lookUpByLabel allows users to retrieve an ver-sion by a given label.

Versioning is based on the checkout/checkin paradigm adopted in most ofthe current revision control tools. To perform changes to a specific version of anartifact the user must check out (checkOut method) this version to his workspace.He works usually on a local copy of the version. After performing his changes hechecks in (checkIn method) the changed version as a new version of the artifact.A pessimistic approach to manage concurrency is adopted. It enables to lock theartifact by performing a lock operation and prevents conflicts due to editing thesame artifact by different users. By locking an artifact a user indicates an intentto make changes. An artifact can be locked by just one user at a time.

5.4 Artifact Merging

In order to enable the cooperative development within an integration projectteam, the BIZYCLE repository supports branching and merging of artifacts.Whenever an artifact has to be changed by different users, each user must beable to create a new branch to work on the artifact. Each branch can be editedand versioned like the main trunk.

If the user A wants to work on a particular version of an artifact and thisartifact is locked by the user B because he is changing the version, the userA must be able to check out this particular version and work on it. After hisrevisions the user A checks in the changed version, and a new branch from thechecked-out version will be created. The new branch cannot be locked by userB anymore. A user is able to lock only one branch of an artifact.

Merging of the versions from different branches may be done either auto-matically (when possible), or manually. For example, when IsPartOf relationclearly marks parts of a model or a metamodel which have been processed intwo different branches, a clean automatic merge is possible, assuming that theparts are independent. If the parts are dependent, or overlapping, external tools(referenced in the Section 2) may be used to perform syntactic merge. However,the results of such a merge, especially for models and metamodels, are not verygood, since models and metamodels are used to capture semantics and puresyntax/text-based merge of XMI files produces conflicts and not very usable re-sults. Source code artifacts, however, are the example of artifacts that can bemerged using existing tools (such as cvs or svn) successfully.

5.5 Consistency Preservation

A repository that supports model-based software and data integration shouldbe able to manage considerable amount of artifact versions, simple descriptivemetadata and metadata that specify relations between the artifacts. Due to thecomplexity of maintaining relations and dependencies between the evolving arti-facts, it is difficult but very important to guarantee integrity of the metadata. Forthis reason, one fundamental aspect of the repository is to preserve consistency.

The state of a database is consistent, if it does not contain any contradictorydata. In the context of the BIZYCLE repository, many facets of consistency canbe observed. We already introduced versioning methods to support distributeddevelopment, avoid concurrency problems and share artifacts, but there is alsothe need for intelligent handling of artifact and metadata changes during thecontinuous evolution of the artifacts. We consider two types of consistency thatmake up the repository consistency. The inner consistency is accomplished if theartifact is stored completely and its representation, like storage format or schemacompliance, is free of errors (completeness and validity), which is mainly charac-terized by the artifact type. The outer consistency is achieved if its descriptivemetadata is coherent and its relational metadata is non-contradictory.

Consistency Criteria and Inner Consistency The consistency criteria con-sist of logical conditions and information about the evaluation and action pro-cedures which are performed if criteria is triggered. The checking of consistencycriteria conditions may also be performed by external tools, like XML validationengine for schema compliance, or model checker for model consistency. In caseof a detected inconsistency, the preservation mechanism based on consistencypreservation rules triggers detailed notifications of certain users, automated rec-onciliation or derivation of consistent versions of other affected artifacts.

Preservation of inner consistency is not a major point in our examination.We assume that the completeness of the artifacts is enforced by the transac-tion mechanisms of the BIZYCLE repository. Despite the fact that we passthe responsibility of enforcing validity to the tools that concentrate on artifactgeneration or transformation, e.g., modeling tools or code generators, it is alsopossible to check inner consistency within the BIZYCLE repository by takingadvantage of corresponding applications like common schema validator, theoremprover, model checker or other services available at the external tool layer.

Outer Consistency: Criteria and Actions Assuming the BIZYCLE reposi-tory is in a consistent state, changes of the metadata can violate the consistencycriteria and set the repository in an ambiguous state. The consistency preser-vation process consists of activities controlled by the consistency keeper. It is acentral entity of the BIZYCLE repository management, responsible for consis-tency preservation, when artifacts or metadata are created, updated or deleted.For each change request received by the remote access layer, the inner consistencyof the concerned artifact has to be assured, which is the minimal requirementfor artifact storage. This allows for extraction and derivation of its metadata bythe metadata manager. Based on this information and already available meta-data of previous versions, the consistency keeper investigates the applicability ofouter consistency criteria. Consistency evaluation rules that guard the compli-ance of corresponding criteria are scheduled and executed, much like triggers thatare commonly used in the relational databases. Using transactions, only thoseartifact-manipulating actions that are confirmed by the consistency keeper willbe committed to the persistence layer, so results of the consistency evaluationprocess may lead to permission, denial or limitation of the persistent storage.Other processes may be initiated that are necessary to resolve consistency con-flicts, such as asking for user assistance or launching automated conflict solvers.

If an artifact has been changed, the outer consistency with respect to theexisting versions of related artifacts may be affected. Depending on the consis-tency rules the consistency keeper selects appropriate actions (Figure 5). Anautomated consistency preservation is the most desirable option, but in mostsituations missing formalisms lead to ambiguousness. Therefore, often only semi-automated or even manual inconsistency resolution is possible.

The given consistency actions illustrate automatic and manual actions. Forexample, if a transformation source changes (e.g., a model is modified whichis related via IsTransformationTargetOf to another model), its corresponding

Fig. 5. Consistency criteria and actions (excerpt)

transformation is automatically derived using the modified artifact instance asa source and reapplying the same transformation rule. Suppose however, thata metamodel has changed and that an appropriate transformation rule is nolonger applicable – in this case a notification about inconsistency is signaled andmanual intervention required. This holds for other relations, e.g., IsOtherRepre-sentationOf, where automatic consistency preservation is possible if a mappingbetween two representations, such as XMI and RDF, are known in advance.Finally, for some relations external tools perform consistency checks, e,g,. an ex-ternal model checker is used to verify consistency of IsInstanceOf relation wheneither model or metamodel change. The propagation of changes may affect arti-facts that do not directly relate to the artifact that originates the modification.Simply following all relations leads to inefficiencies. To avoid such problems,consistency keeper transforms the scheduled consistency actions into a directed,acyclic graph. If this is not possible, e.g., there are cycles which would causeinfinite loops of consistency checks and repairs, manual intervention is required.

6 BIZYCLE Repository Prototypical Implementation

The BIZYCLE repository has been prototypically implemented using J2EE tech-nology and JBOSS as the application server. The parts that were developed aresketched in the implementation diagram (Figure 6).

A multi-tiered architecture is used, with facade, session, entity and phys-ical persistence layers. The facade exposes BIZYCLE repository API as JavaRMI interface to Java clients and as WSDL interface to SOAP clients. The re-alized clients are Eclipse GMF Model editors and MagicDraw. The session layercaptures the BIZYCLE repository business logic and comprises session beansperforming artifact processing (parsing XML/XMI and ATL content), metadataprocessing (deriving and managing artifact metadata), repository management(consistency, user and project related operations) and providing API to externaltools (interfaces to XML schema validator, model checker and theorem prover).

<<EJBEntityBean>>Project

<<EJBEntityBean>>User

<<component>>Consistency

<<XMLDBMS>>

Berkeley XML DB

<<EJBSessionBean>>Facade

<<EJBSessionBean>>Tool Access

Manager

<<EJBSessionBean>>ArtifactProcessor

<<EJBSessionBean>>Metadata Processor

<<EJBSessionBean>>RepositoryManager

Consistency

<<EJBEntityBean>>Metadata

<<EJBEntityBean>>Artifact

<<FileSystem>>

Flat FileMetadata

Concent

<<RDBMS>>

MySql<<component>>ExternalTool

<<component>>JavaClient JavaRMIClient

<<component>>SOAP Client

SOAPClient Project

<<RDBMS>>

MySQL

User

ToolAccess

API_SOAP

Tool_API

API_RMI

<<use>>

<<use>>

<<use>>

<<use>>

<<use>>

Fig. 6. Prototypical Implementation

Session layer provides interfaces to both Facade and external tools. The en-tity bean layer provides data model abstraction, coarsely divided into Artifacts,Metadata and Project entity beans. Finally, behind the entity layer the per-sistent storage has been implemented, using a file system, relational database(MySQL) and an XML database (Berkeley XML DB) as storage for artifactcontent and the relational database (MySQL) for metadata storage. That way,storage is decoupled from both entity and session layers and can be dynamicallyreconfigured and its content migrated. The minimal configuration requires a filesystem for content storage and a relational database for metadata.

Instead of developing the repository from scratch, experiments have beenmade with integrating existing systems’ functionality, especially in the field ofartifact progression and versioning at the persistence level. Experiments havebeen performed with the common source control management software packagessuch as CVS, SVN and ClearCase. They provide different versioning models andsupport for collaboration, such as locking, variable merging models, transactionalbehavior, enforcement of security aspects and storage of metadata for each arti-fact version. More advanced features of the repository concern project orientedartifact life cycle management, and Apache Maven has been investigated in thiscontext. It standardizes the project structure by setting up conventions usingcertain project archetypes and simplifies the build behavior through unificationof the build process. Furthermore, Maven handles project dependencies, providesfeatures for documentation and reporting.

7 Conclusion and Future Work

For the complex MBSE (meta-)tool platform provided by the BIZYCLE frame,we have presented the information model, the software architecture, severalmethodological considerations and, finally, a prototypical implementation of theBIZYCLE repository. Particularly, the aspects of evolution, i.e. versioning, merg-ing and consistency of the variety of (meta-)models, metadata, documents, and

other artifacts, are challenges in this multi-user environment, and are still subjectto research and development throughout the MDA community.

The flexible and open architecture of the BIZYCLE repository allows forplug-in integration of external tool support, such as consistency checkers, intelli-gent versioning and management support for different kinds of artifacts, as wellas services to be found in the Eclipse framework. As we follow the paradigmof continuous software engineering, we are open to extend the repository withparadigm changes like other MOF metamodel level hierarchy, new modeling lan-guages and their artifacts, new programming languages or middleware services,to be reflected in appropriate metadata sets.

References

1. Kutsche, R., Milanovic, N.: (Meta-)Models, Tools and Infrastructures for BusinessApplication Integration. In: UNISCON 2008, Springer Verlag (2008)

2. Kutsche, R., Milanovic, N., Bauhoff, G., Baum, T., Cartsburg, M., Kumpe, D.,Widiker, J.: BIZYCLE: Model-based Interoperability Platform for Software andData Integration. In: Proceedings of the MDTPI at ECMDA. (2008)

3. Pulier, E., Taylor, H.: Understanding Enterprise SOA. Manning (2006)4. Schmid, F. Erstellung eines Repositories fur die Verwaltung und Transformation

von Komponentenmodellen (November 2004) (in German).5. Fedora Repository http://www.fedora-commons.org/.6. Boldyreff, C., Nutter, D., Rank, S.: Active artefact management for distrib-

uted software engineering. Computer Software and Applications Conference, 2002.COMPSAC 2002. Proceedings. 26th Annual International (2002) 1081–1086

7. Lucia, A.D., Fasano, F., Oliveto, R., Tortora, G.: Adams: Advanced artefact man-agement system. In: Proceedings of the CSMR, Los Alamitos, CA, USA, IEEEComputer Society (2006) 349–350

8. NetBeans Metadata Repository http://mdr.netbeans.org/.9. MOF 2.0 / XMI Mapping Specification, v2.1.1

http://www.omg.org/technology/documents/formal/xmi.htm.10. 2008 metadata solutions report (December 2007) preview at

http://www.gavsys.com/rptfiles/GavResearch-sample-report-pages-Nov2007.pdf.11. Meta Object Facility (MOF) Versioning and Development Lifecycle Specification,

v2.0, formal/07-05-01, OMG Group (May 2007)12. Alanen, M., Porres, I.: Difference and Union of Models. Technical Report 527,

Turku Centre for Computer Science (April 2003)13. Storrle, H.: A formal approach to the cross-language version management of mod-

els. In: Proceedings of the NW-MODE07. (2007)14. Hnetynka, P., Plasil, F.: Distributed Versioning Model for MOF. In: Proceed-

ings of the Winter International Symposium on Information and ComunicationTechnologies (WISICT 2004), Trinity College Dublin (2004) 489–494

15. Katz, R.H.: Toward a unified framework for version modeling in engineering data-bases. ACM Comput. Surv. 22(4) (1990) 375–409

16. Westfechtel, B., Munch, B.P., Conradi, R.: A layered architecture for uniformversion management. IEEE Trans. Softw. Eng. 27(12) (2001) 1111–1133

17. Conradi, R., Westfechtel, B.: Version models for software configuration manage-ment. ACM Comput. Surv. 30(2) (1998) 232–282