For attaining the vision of a wide-spread use of enterprise modeling in everyday business practices, the underlying modeling methods need to be easily accessible. Therefore, open implementations of these modeling methods are required that can be modi ed and extended as needed. At the same time, such open implementations must provide a su ciently advanced level to be adequate for practical usage. In this paper, we report on experiences gained from the implementation of the SERM modeling approach on the ADOxx meta modeling platform in a student project. We derive guidelines for teachers and students who want to engage in similar projects and discuss implications for future research.
One of the foundations for establishing enterprise modeling as a common practice in organizations is the availability of modeling tools that permit the e ective use of the underlying modeling methods and the exchange of model data between di erent parties and systems [1, 2, 3]. Conceptual enterprise modeling methods are used today for many purposes and domains, ranging from the strategic layer, over the layer of business processes and work ows to the technical and infrastructure layer [4, 5]. An important domain in enterprise modeling is the modeling of data structures and their implementation in database systems [6, 7]. Well-known examples of modeling methods belonging to this domain are the Entity-Relationship-Model by Chen [8] and the Uni ed Modeling Language (UML). However, also several modeling methods have been conceptualized that target speci c ways of modeling and using data structures, e.g. the method for adaptable database design by Roussopoulos and Yeh [9] or the higher order entity-relationship modeling (HERM) language by Thalheim [10].
A further approach that is part of the domain of data modeling is the Structured-Entity-Relationship-Model (SERM) by Sinz [11]. SERM is speci cally directed towards the structuring of large data models, the visualization of existence dependencies, the avoidance of inconsistencies and the easy transition to database schemata. For the details of the SERM method we refer to [11, 12].
In the past, several modeling tools have been developed for SERM. However, these tools were either developed based on some legacy systems that are not operational in modern IT environments any more. Or, some central aspects of SERM such as its particular suitability for generating database schemata had not been realized. Therefore, it was decided to realize a new and openly accessible version of a SERM tool in a student project by reverting to the ADOxx meta modeling platform [2]. In this way, the resulting tool should be shared via the Open Models Initiative to provide a foundation for further developments based on SERM [13].
In this paper we will report on the experiences gained from this project, both from the perspective of the students as well as the teachers in the course. The goal is to provide recommendations for similar projects, thereby contributing to the realization of open enterprise modeling. The remainder of the paper is structured as follows. In Section 2 we will describe the set-up of the student project and the positioning within the curriculum. This will be followed by a description of the project phases in Section 3. Finally, we will report on the experiences in Section 4. The paper will conclude with an outlook on further research in Section 5.
The project was set up in the course of a master seminar for students of Information Systems at the University of Bamberg. Although the students were familiar with various conceptual modeling methods including SERM as well as with the implementation of software applications, none of them had previously implemented a modeling tool. They neither had any knowledge about the ADOxx meta modeling platform nor about the transformation of models into code, e.g. by using XML and XQuery. The goal that was set for the seminar was to implement a SERM modeling tool that should provide as much aid to the users as possible in creating valid SERM models. In addition, the transformation of the models into SQL schemata that are executable on the PostgreSQL database server was de ned as a target.
The project was structured in the following phases: preliminary phase, foundations of modeling methods conceptualizations, formalization using FDMM, and iterative design and implementation using ADOxx and XML processing. These phases will be described in detail in the following sub sections.
In the preliminary phase the seminar participants were introduced to the goals of the project and the main properties of SERM were presented as a re-cap from previous courses. In addition, the current knowledge level of the participants in regard to the implementation of modeling methods in general and the familiarity with ADOxx were assessed. This also included the provision of information regarding the availability of corresponding literature sources, the ADOxx platform, and support tools that are helpful in this context, e.g. the GraphRep generator or the syntax highlighting de nitions for ADOscript in the Notepad++ editor. With these tools, the students were walked through the design of a minimal language. This included a meta model and a visual language consisting of simple modeling elements similar to a "Hello World" program in software development.
The theoretical underpinning of the project is based on a framework proposed by Karagiannis and Kuhn [14]. It serves as a basis to establish a common understanding regarding the components of modeling methods, especially in the context of developing modeling tools with a meta modeling platform such as ADOxx. According to Karagiannis and Kuhn, a modeling method is comprised of modelling technique, including a modeling language and a modeling procedure, as well as mechanisms and algorithms. The modeling language is de ned through its syntax, semantics and notation. For this project, these components were of particular interest for the implementation.
When conceptualizing a tool based modeling method, the implementation of the components de ned by Karagiannis and Kuhn needs to be aligned with three facets. Central to the conceptualization is facet a., the Domain Concept and Grammar of the modeling method to de ne core syntax, semantics and notation of the language. Facet b. is the user's Handling and Interaction of the Domain Concept and Grammar, e.g. through the choice of available notation elements and their graphical representation, optimized for usability. Facet c. concerns the modeling platform's Management and Storage of the Domain Concept and Grammar in data structures and algorithms, optimized for processing inside the platform. Facets b. and c. con ict each other and need to be balanced. For example, in a language with directed and undirected edges, it might be algorithmically easier to process one notational element which has an attribute to di erentiate directed and undirected edges. For a user, however, two separate notational elements available next to each other in a toolbar might be preferable. During implementation, any technical decision has to consider b. as well as c..
The ADOxx meta modeling platform allows designing the abstract syntax of a modeling language through the construction of a meta model as well as an according concrete syntax for the visual notation. The ADOxx meta model [2] complies with the approach of Karagiannis and Kuhn by providing model types with Class and Relation Class elements at its core to allow for instantiating models with model elements and relations. Class and Relation Class may contain multiple instances of Attribute, which may be user de ned or, in case of the notation, pre-de ned as a GraphRep attribute. Through GraphRep, the notation of Class and Relation Class elements is de ned.
At this point in the project the student team had a thorough understanding of the SERM modeling method. The team also had a basic understanding of the necessary technical steps for the conceptualization of a meta model on the ADOxx platform (e.g. de nition of model types, classes, relation classes and their graphical representation). While SERM meta models have been published in the past, e.g. [11], [15, p. 171], they are incomplete (e.g. missing SERM's generalization constructs), have author-speci c notations and are not tailored towards the development of modeling tools. Therefore, the conceptualization of the SERM meta model in the ADOxx platform is not straightforward. However, the conceptualization and formal description is of critical importance for all upcoming development tasks [16].
Instead of proceeding directly with the implementation of the SERM modeling method on the ADOxx platform, it was therefore decided to conduct an additional formalization phase using the FDMM formalism [17]. FDMM allows for a formal, yet concise, technology-independent speci cation of the meta model to be implemented.
As this phase's rst step, a 45 minute introductory lecture on FDMM was given. The lecture, including an exemplary application of FDMM on the 4R modeling language, was based on [17]. It has to be noted that the participating research assistants did have prior experience with the ADOxx platform, but neither the student team, nor the research assistants had any prior experience with FDMM.
Subsequent to the lecture, a discussion about possible design choices
regarding the SERM meta model formalization followed. An emphasis has been
on when to use attributes and when to use modeling classes and relations of
their own for SERM elements (e.g. individual classes for (
Next, the student team presented a rst draft of their SERM formalization using FDMM. The SERM meta model was formally described as follows. As a starting point, single model type M TSERM is de ned:
M TSERM = hOSTERM ; DSTERM ; ASERM i
(
T riangle; DotT oT riangle; T riangleT oER
RecordAttributes; RecordInherited Attributesg
The type DOT (data object type) acts as a super type for ET ype, ERT ype and
RT ype:
(
Relations between data object types were realized using a single type DOT
Relation, while the relation's cardinality was represented by an attribute. The
SERM meta model from [15, p. 171] uses individual relation types for (
Due to space limitations, only an excerpt of the de nition of attributes is described in the following. But before that, the set of data types DSTERM and the set of attributes ASERM needed to be de ned. An excerpt of the set of data types is shown in the following:
DSTERM = fInteger; String; EnumSQLDatatype; : : : g
EnumSQLDatatype = fsmallint; int; bigint; date; : : : g Enum data types, such as EnumSQLDatatype, are used to represent ADOxx Enumeration types with prede ned values. The set of attributes ASERM contains the attributes of all types. Therefore, only an excerpt can be shown here:
ET ype ERT ype
RT ype
DOT DOT
DOT
ASERM = fN ame; Attributes; Key; Cardinality; : : : g
The attributes from ASERM , with the exception of table-valued attributes, were then attached to object types and given a value range. Using FDMM's card function, the number of attribute values per object was constrained. For example, each data object type has exactly one name:
domain(N ame) = fDOT g
range(N ame) = fStringg
card(DOT; N ame) = h1; 1i
(
Finally, ADOxx relation classes were formalized in FDMM using "from" and "to" attributes, e.g.: domain(relatesF rom) = fDOT Relationg
range(relatesF rom) = fDOT g card(DOT Relation; relatesF rom) = h1; 1i domain(relatesT o) = fDOT Relationg
range(relatesT o) = fDOT g card(DOT Relation; relatesT o) = h1; 1i
The abstract and concrete syntax of SERM was implemented in ADOxx over the course of about ten weeks. Included in this time frame are teaching sessions as well as result discussions, which were alternating according to the syllabus. The iterative process covered the implementation of the abstract syntax by extending the ADOxx meta model with the already formalized SERM meta model and the implementation of the concrete syntax by specifying a graphical representation. Beyond syntax and notation, algorithms for the inheritance of primary key attributes among data object types and the generation of SQL code were implemented using ADOxx expression attributes in conjunction with a customization programmed in the ADOscript programming language.
Implementation of Abstract Syntax The elements of the abstract syntax of SERM were implemented as extensions of Class and Relation Class of the ADOxx meta model. Class was extended by the abstract Data Object Type (DOT) which was in turn extended with Entity Type (E-Type), Entity-Relationship Type (ERType), Relationship Type (R-Type), and Triangle for generalizations.
In order to allow relations between instances of Data Objects Types, a
Relation Class DOT-Relation having a From-Class DOT and a To-Class DOT was
speci ed, so that such a relation always connects two DOT instances.
Cardinalities between DOT instances were set as attribute values in the Cardinality
attribute of a DOT-Relation instance as an Enum value out of (
In contrast to relations between DOT instances, a generalization connects one instance of DOT with one or more instances of specialized ER-Type. A <<Class>>
Triangle - isDisjunct : Enum
To-Class <<Relation Class>>
DOTRelation - Key : Enum - Cardinality : Enum <<Relation Class>>
DotToTriangle - Completeness : Enum
To-Class From-Class From-Class To-Class <<Class>>
DOT - Attributes : DOTAttribute [0..*] - Inherited_Attrs : DOTInherited_Attribute [0..*] - sequency_level : Integer <<Record Class>>
DOTAttribute - Datatype : String - Key : Enum - Label : String
<<Record Class>> DOTInherited_Attribute - Datatype : String - Key : Enum - Label : String - From_Cardinality : String - From_DOT : String From-Class <<TRreilaantigolneTColaEsRs>> <<Class>> ERType <<Class>> EType <<Class>> RType single Relation Class is therefore not su cient, but rather two Relation Class DotToTriangle and TriangleToER as well a Class Triangle. Due to notation, completeness of generalized subtypes is stored in an Enum attribute in DotToTriangle, whereas disjunctive generalizations are indicated by an attribute of Triangle.
SERM allows the speci cation of attributes when modeling E-, ER-, and RTypes. For the representation of these instance-level attributes in a model, the E-, ER- and R-Type Class feature an attribute Attributes in conjunction with a Record Class DOTAttribute. The Record Class de nes that such an instancelevel attribute has a label, a datatype from an enumeration of commonly used SQL data types, as well as key to di erentiate between primary key (PK), foreign key (FK), PK and FK, and non-key attributes. In order to allow such attributes to be edited by the modeler, they were added to a user accessible Notebook using the AttrRep attribute of E-, ER-, and R-Type. Inherited instance-level attributes were stored in a similar fashion. Additionally, the Sequency Level attribute was provided to store an ordering property of the quasi-hierarchical graph a SERM constitutes. It is used for ADOscript implementations of algorithms for key inheritance as well as to prepare the generation of SQL code through an XML model.
Implementation of Concrete Syntax The graphical representation of a Class or Relation Class was de ned by their GraphRep attribute containing code according to the GraphRep grammar. SERM depicts E-Types and R-Types in the fashion of ERM. The notation of ER-Types re ects the combination of the E- and R-Type, given a 1:1-relation between them. In addition to the respective shapes, the GraphRep of these Classes contains scaling logic using variable-sized tables to allow resizing. SERM itself does not de ne a notation for attributes; a lineby-line attribute list below each data object type was chosen for size-e ciency. For displaying attributes, the GraphRep implementation contains logic to extend the actual shape, read instance-level attribute values at run-time and write them out line-by-line using token lists.
E-, ER-, and R-Types may be connected using edges for cardinality (
Realizing the graphical notation of generalizations required separate GraphRep logic for DotToTriangle, TriangleToER and Triangle. The completeness property in the DotToTriangle GraphRep displays single or double lines from the supertype to the triangle, indicating given or not given completeness respectively. Disjunct subtypes are indicated in the Triangle GraphRep using the empty set symbol. A limitation of this implementation is the visual depiction of three separate symbols for generalization model elements in the toolbar next to an ADOxx SERM instance. From a usability perspective this might still be practical since all elements ful ll di erent functions and are subsequently needed when modelling a generalization.
Implementation of the Transformation to SQL With the features for creating SERM model being ready, the next step was the development of the SQL code generation feature. The ADOxx platform o ered two alternative ways for implementing a transformation from SERM to SQL code. The rst alternative was to implement the transformation only using ADOxx's scripting facility based on the ADOscript language. The second alternative was to use the ADOxx XML export functionality to export a SERM model as an XML le, which can be further processed using standard XML processing languages and tools. As a pure ADOscript based solution was expected to become hard to debug and maintain quickly, the team decided to use the XML based approach for the transformation. It should be noted, that the student team had no prior in-depth experience in XML processing. Therefore, some introductory learning material on XML { covering topics such as XML basics, XSLT and XQuery { was provided to the students. As the students were familiar with SQL, they chose XQuery for the processing of the exported XML les, as some of the language's elements have more resemblance to SQL when compared to XSLT.
Evaluation Using a Test Model The syntax of SERM required the implementation of three data object type elements, four edge elements and four generalization elements [15, p. 160-166]. To evaluate the implementation, a reference model making use of at least one instance per syntax element was designed as depicted in Figure 2. Table 1 shows the number of instances per element in the model. Due to n > 0 for each element, completeness of the SERM syntax is demonstrated.
E-Type 5 ER-Type 12 R-Type 1
(
Non-Disjunctive and Incomplete 1 Disjunctive and Incomplete 1 Non-Disjunctive and Complete 1 Disjunctive and Complete 1
After the description of the project phases we will now summarize our experiences. This will be discussed both from the perspective of the involved students (Thilo Maximilian Glassner, Florian Heumann, and Luca Ke ler) as well as from the perspective of the teachers (Felix Harer, Andreas Ste an, Hans-Georg Fill).
One of the major advantages from the side of the students was the familiarity with the SERM modeling method from previous courses. This signi cantly lowered the barrier for designing and implementing an according modeling tool. On the other hand, ADOxx was not known to the students. As ADOxx o ers a large number of functions it was rst necessary to become acquainted with the platform. This had to be primarily done by the students themselves as no courses on ADOxx are currently o ered at the University of Bamberg. In addition, neither the processing of XML had been taught in courses before. Therefore, the students also had to become familiar with the corresponding technologies, in particular the XQuery language.
The learning curve in regard to the ADOscript language and the expression language used for programming with ADOxx was rather steep. It could not be accomplished by the students on their own without support from the teachers. Especially, it was unclear which functions in ADOxx have to be used for achieving certain results and what the di erent options and trade-o s are. This was despite the fact that the syntax of the used languages was rather easy to comprehend, although it is not based on object oriented principles which the students were already familiar with.
The scheduling of weekly meetings with the teachers was very helpful for receiving support during the development. One aspect that proved di cult was the distributed cooperation of the three students on the ADOxx library as the ADOxx version used in the course did not permit multi-user distributed development per se. It was therefore decided by the students to resolve this issue by using a virtual machine hosted on Amazon Web Services where all students had simultaneous access. This also permitted to use di erent development platforms on the side of the students, i.e. Mac, Linux, and Windows systems.
From the side of the teachers it was a unique opportunity to have a very small number of students in the course. This permitted a very close interaction with weekly meetings and immediate feedback on the conceptualization, the formalization, and the technical implementation of the modeling method. For larger groups - which had originally been expected - it would not be possible to have the same level of interaction.
Concerning the material required for the course it was possible to re-use material provided by the adoxx.org and the omilab.org websites. Thereby, it proved particularly bene cial that a large number of existing modeling tools together with their openly available libraries in ADOxx could be used for showcasing di erent scenarios and the usage of ADOxx functions. Especially, for elaborating best practices on the speci cation of the visual notation in the GraphRep grammar (e.g. the rather complex ways of correctly specifying scalable graphical objects) or the speci cation of expression attributes in the LEO grammar and ADOscript algorithms it was helpful to revert to existing resources and examples.
Due to the familiarity of the students with the SERM modeling method from previous courses, it was easy to explain to them the goals of the project. In addition, the motivation of the students to implement their own modeling tool including an automated SQL transformation from SERM models seemed very high throughout the project.
In case the modeling method is not known to the students or, if a modeling method does not yet exist and needs to be conceptualized from the beginning, it may be more di cult to convince and motivate the students for such a project. The challenge of the project described here lied mainly in the technical realization and the automated code generation. Designing a modeling method from scratch, including according abstraction could prove more challenging. This is planned to be explored in future student projects.
In summary, we can give the following recommendations for meta modeling projects that take a similar direction. During the de nition of the project's goals it needs to be considered what can be expected of the intended participants of the project. For example, if the focus of the project is to re-implement an already existing modeling method - i.e. one that has either been implemented as a modeling tool before or that is speci ed in such great detail that the meta model can be immediately implemented without further changes - then the participants only need to acquire additional know-how about the implementation environment. If, however, the modeling method has not yet been implemented or not in the way intended for the project and the participants thus have to take decisions on the core parts of the meta model, also a high familiarity with abstraction and design concepts is necessary.
In any case, regular interactions between the project's participants and the teachers / experts in meta modeling should be planned. This ensures continuous and early feedback as practical meta modeling projects tend to be very complex. This primarily stems from the many inter-linkages between the domain representation, the processing and storage aspects, and the user interface / user interaction design. One way to cope with this complexity is to provide examples from other implemented modeling methods to illustrate best practices. For this purpose, repositories such as omilab.org or adoxx.org can be consulted in the case of ADOxx.
Finally, it needs to be ensured that the participants nd a way to e ectively collaborate on the project. For example, if possible, resources for sharing documents, libraries or even virtual machines should be foreseen.
In this paper we have reported on the experiences from a meta modeling project in a master seminar. Besides a detailed description of the phases and results of the project we summarized the experiences gained both from the students and the teachers.
The next steps will be to tackle a more complex project setting and thus enlarge the project focus. We currently plan to redo the meta modeling project for a modeling method that has not been implemented before and where the students thus need to take decisions on the adequate design of the meta model and the visual notation.