Skip to content
Snippets Groups Projects
Commit c3cda0df authored by Reiner Jung's avatar Reiner Jung
Browse files

Improved meta-model comparison, added parameter issue solutions, and discussed... 

Improved meta-model comparison, added parameter issue solutions, and discussed SMM meta-model errors.
parent 1a51aaf6
No related branches found
No related tags found
No related merge requests found
Expand all Show whitespace changes
Inline Side-by-side
Showing
with 721 additions and 276 deletions
doc/smm-mamba-comparision/comparision-of-smm-documentation-and-the-meta-models-from-mamba-and-the-omg.tex
+ 3
− 3
View file @ c3cda0df
......@@ -24,7 +24,7 @@
% see http://merkel.zoneo.net/Latex/natbib.php
\usepackage{natbib}
%\usepackage{natbib}
% bibpunct: set up for the reference appearance
% 1. the opening bracket symbol, default = (
% 2. the closing bracket symbol, default = )
......@@ -35,7 +35,7 @@
% 6. the punctuation that comes between years or numbers when common
% author lists are suppressed (default = ,);
%\bibpunct{[}{]}{,}{n}{}{,}
\bibpunct{[}{]}{,}{}{}{,}
%\bibpunct{[}{]}{,}{a}{}{;}
\usepackage{ae,aecompl}
\usepackage[pdfborder={0 0 0}]{hyperref}
......@@ -71,7 +71,7 @@
\include{content}
% einkommentieren, wenn eine Bibliographie existiert
\bibliographystyle{natdin}
\bibliographystyle{alphaurl}
\bibliography{references}
% einkommentieren, wenn ein Index gewünscht ist
......
doc/smm-mamba-comparision/content.tex
+ 97
− 28
View file @ c3cda0df
......@@ -2,18 +2,10 @@
%%
%% add content here
\newcommand{\modisco}{\textsf{MoDisco}}
\newcommand{\spec}{\ac{smm} specification}
\newcommand{\type}[1]{\textsf{#1}}
\newcommand{\attr}[1]{\textsf{#1}}
\newcommand{\code}[1]{\texttt{#1}}
\newcommand{\val}[1]{\textsf{#1}}
%%
\section{Introduction}
The \ac{omg} published a meta-model specification targeting measuring and measurements called \ac{smm} \citep{OMG:SMM:2012}. The \ac{omg} provides a slightly outdated meta-model in \ac{emof} for their \spec. The \ac{mamba} project developed its own \ac{smm} meta-model based on the published specification. And \modisco{}\footnote{Website \url{http://www.eclipse.org/MoDisco/}} comes also with a meta-model for \ac{smm}. All three meta-models and the specification deviate from each other. Furthermore, the semantics of some constructs and attributes are not explicitly defined, which results in some space for interpretation how certain properties, e.g., setting parameters for observed measures, can be defined.
The \ac{omg} published a meta-model specification targeting measuring and measurements called \ac{smm} \cite{OMG:SMM:2012}. The \ac{omg} provides a slightly outdated meta-model in \ac{emof} for their \spec. The \ac{mamba} project developed its own \ac{smm} meta-model based on the published specification. And \modisco{}\footnote{Website \url{http://www.eclipse.org/MoDisco/}} comes also with a meta-model for \ac{smm}. All three meta-models and the specification deviate from each other. Furthermore, the semantics of some constructs and attributes are not explicitly defined, which results in some space for interpretation how certain properties, e.g., setting parameters for observed measures, can be defined.
The goal of this paper is to collect the differences of the three meta-models and the specification, and formulate solutions for semantic and implementation problems.
......@@ -65,7 +57,7 @@ The \ac{smm} meta-model in the delivered state cannot be used for code generatio
%
\subsection{Class \type{AbstractMeasureElement}}
The \modisco{} meta-model extends the declaration by a \attr{inCategory} association of type \type{CategoryRelationship}. The \spec{} has no separate section for the \type{AbstractMeasureElement} class. However, it is noted in Section 10.1 of \citep{OMG:SMM:2012} and has no additional attributes, associations or operations.
The \modisco{} meta-model extends the declaration by a \attr{inCategory} association of type \type{CategoryRelationship}. The \spec{} has no separate section for the \type{AbstractMeasureElement} class. However, it is noted in Section 10.1 of \cite{OMG:SMM:2012} and has no additional attributes, associations or operations.
%
\subsection{Enumeration \type{Accumulator}}
......@@ -75,7 +67,7 @@ The \modisco{} meta-model extends the declaration by a \attr{inCategory} associa
%
\subsection{Class \type{AggregatedMeasurement}}
The class \type{AggregatedMeasurement} is not defined in the \spec{} or in the \ac{smm} or \ac{mamba} meta-model. However, the \modisco{} meta-model provides such class. It might be a leftover from previous versions. The \spec{} mentions a class \type{AggregatedMeasure} in an example (see \citep[p. 91]{OMG:SMM:2012}).
The class \type{AggregatedMeasurement} is not defined in the \spec{} or in the \ac{smm} or \ac{mamba} meta-model. However, the \modisco{} meta-model provides such class. It might be a leftover from previous versions. The \spec{} mentions a class \type{AggregatedMeasure} in an example (see \cite[p. 91]{OMG:SMM:2012}).
%
\subsection{Class \type{Argument}}
......@@ -324,18 +316,21 @@ this section provides information on the three different realizations of relatio
\subsection{Class \type{MeasureRelationship}}
Class \type{MeasureRelationship} is derived from the class \type{SmmRelationship}. The \ac{mamba} meta-model uses the class \type{AbstractMeasureRelationship} as parent class. A detailed relationship is illustrated in \autoref{fig:smm-relationship}. Furthermore, the declaration of attributes and associations is different between \ac{mamba} and \ac{smm}. However, the result for the \type{MeasureRelationship} class are the same. The \modisco{} meta-model class for \type{MeasureRelationship} extends the \ac{smm} meta-model and the \spec{} by two operations \code{getTo} and \code{getFrom}, which overloads the corresponding methods from \type{SmmElement}.
W
We should consider to remove \type{AbstractMeasureRelationship} from the \ac{mamba} meta-model and use the implementation from \ac{smm} meta-model.
%
\subsection{Class \type{EquivalentMeasureRelationship}}
The properties of the \type{EquivalentMeasureRelationship} class are identical in all realizations. However, in \modisco and \ac{smm} meta-models, the properties \attr{from} and \attr{to} are declared in the \type{EquivalentMeasureRelationship} class while the \ac{mamba} equivalent inherits these two properties from its parent class \type{MeasureRelationship} (see also \autoref{tbl:equivalent-measure-relationship}).
\begin{table}[h!tb]
\caption{Class \type{EquivalentMeasureRelationship}}
\label{tbl:equivalent-measure-relationship}
\centering
\begin{tabular}{l|ll}
\multicolumn{1}{c|}{\bf Attribute} &
\multicolumn{1}{c|}{\bf \ac{smm}} &
\multicolumn{1}{c}{\bf \ac{smm}} &
\multicolumn{1}{c}{\bf \ac{mamba}} \\
\hline
\attr{mapping} & \type{Operation} & \type{Operation} \\
......@@ -345,51 +340,124 @@ We should consider to remove \type{AbstractMeasureRelationship} from the \ac{mam
\end{table}
%
\subsection{Class \type{Scope}}
The \type{Scope} class differs in one parameter between the different realizations. In the \spec{} and the \ac{smm} meta-model the \attr{class} attribute is modelled as a \type{String}, while the \ac{mamba} meta-model uses \type{EClass}. Cause of that difference, is the ability to reference only classes modelled in Ecore. While the \type{EClass} allows fast run-time lookup, the \type{String} variant allows to specify scopes for non-Ecore models.
\subsection{Class \type{Scope}}\label{ss:class-scope}
The \modisco{} meta-model implements the \type{Scope} class differently. \autoref{tbl:modisco-smm-scope} relates both classes to each other.
The \type{Scope} class differs in its realization in the three meta-models, where the \ac{smm} meta-model conforms to the specification. The other two meta-model deviate from that. \autoref{tbl:modisco-smm-scope} shows the three meta-model realizations.
\begin{table}[h!tb]
\caption{\modisco{} and \ac{smm} meta-model realizations of class \type{Scope}}
\caption{\modisco{}, \ac{mamba} and \ac{smm} meta-model realizations of class \type{Scope}}
\label{tbl:modisco-smm-scope}
\centering
\begin{tabular}{ll|ll}
\begin{tabular}{ll|ll|ll}
\multicolumn{2}{c|}{\bf \ac{smm}} &
\multicolumn{2}{c|}{\bf \modisco} &
\multicolumn{2}{c}{\bf \ac{smm}} \\
\multicolumn{2}{c}{\bf \ac{mamba}} \\
\hline
\attr{class} & \type{String} &
\attr{class} & \type{EString} \\
\attr{class} & \type{EString} &
\attr{class} & \type{EClass} \\
\attr{recognizer} & \type{Operation} &
\attr{recognizerQuery} & \type{Operation} \\
\attr{recognizerQuery} & \type{Operation} &
\attr{recognizer} & \type{Operation} \\
& &
\attr{elements} & \type{EObjects} \\
\attr{elements} & \type{EObjects} &
& \\
\attr{breakCondition} & \type{Operation} &
\attr{breakCondition} & \type{Operation} &
\attr{breakCondition} & \type{Operation} \\
\end{tabular}
\end{table}
%
\subsection{Class \type{SmmElement}}
The class \type{SmmElement} is implemented equally. However, the \ac{mamba} and the \modisco{} meta-model class declaration have an attribute \attr{attribute} which is called \attr{attributes} in the \ac{smm} meta-model and the \spec{}. The \modisco{} realization calls the attribute \attr{annotations} only \attr{annotation}. It adds also the association \attr{requestedObservations} of type \type{Observation}.
%%
\section{\ac{mdl} and \ac{mql}}
%%
\section{The Parameter Issue}
A central element of \ac{mdl} and especially \ac{mql} is the use of parameters to configure scope selection. Therefore, the generation of these parameters and the application of arguments to these parameters in \ac{smm} is required. In this section we sketch a solution for this problem by discussing the semantics of the involved classes and attributes, the \ac{smm} model generation, and the functionality required by the \ac{mee}.
A central element of \ac{mdl} and especially \ac{mql} is the use of parameters to configure measures for the observation. One important parameter is the scope selection. Therefore, the generation of these parameters and the application of arguments to these parameters in \ac{smm} is required. In this section we sketch a solution for this problem by discussing the semantics of the involved classes and attributes, the \ac{smm} model generation, and the functionality required by the \ac{mee}.
%
\subsection{Possible \spec{} Semantics}
In \ac{smm}, a \type{Measure} must have a \type{Scope} comprising three properties. First, a \type{String} property defining the class of objects where the \type{Measure} can be used. Second, a recognizer can be specified which selects only a sub-set of objects belonging to the class specified in the \attr{class} attribute. The other properties are of no concern to the parameter issue. The class \type{Scope} has different realizations documented in \autoref{ss:class-scope}, but they all have the two mentioned properties.
While the \spec{} defines a \code{getArguments()} operation for \type{Measure}, the documentation is unclear if the parameter declared in operations in \type{Scope} belong the set of parameters to be returned by the \code{getArguments()} operation. If the specification is interpreted literally, \code{getArguments()} returns only the arguments of the operations of the \type{Measure} (see \cite[p. 22]{OMG:SMM:2012}). As \type{Scope} is a separate class, the operations in \type{Scope} might not be included in the result of \code{getArguments()}. It is doubtful that this literal interpretation is the right interpretation, as all the known sub-classes of \type{Measure} have only operation properties for
In \ac{smm} a measure can have one or more \type{Operations}, which can have parameters. The parameters are returned by an operation \code{getParamStrings} (from the \type{Operation} class) conforming to a simple string format \citep[p. 24]{OMG:SMM:2012}. As the \type{Operation} class does not have any attribute to store this parameter information, it has to be extracted from the \attr{body} attribute of the \type{Operation} class. As the language of the operation can be XQuery or OCL, the \code{getParamStrings} method must provide two implementations for that parameter extraction.
\begin{description}
\item[\type{Measure}.\attr{defaultQuery}] representing the default measurement result for a measure (compare \cite[p. 22]{OMG:SMM:2012}),
\item[\type{CollectiveMeasure}.\attr{operation}] representing an optional collection operation (compare \cite[p. 34]{OMG:SMM:2012}), and
\item[\type{DirectMeasure}.\attr{operation}] representing on optional direct measuring operation (compare \cite[p. 34]{OMG:SMM:2012}).
\end{description}
\noindent It would be preferable to have \type{Scope} included in the result of the \code{getArguments()} result.
For the correct application of \type{Measures} to model elements, a selection operation must be used. In the following subsections, we will discuss different solutions to this problem. One idea is to use the recognizer operation of a \type{Measure} to implement a model node selector. Another idea is, using the \type{ObservationScope} as a selector for nodes.
\begin{figure}[h!tb]
\includegraphics[width=\textwidth]{images/observation}
\caption{The application of a \type{Measure} in an \type{Observation}}
\label{fig:observation}
\end{figure}
A portion of the \ac{smm} meta-model is presented in \autoref{fig:observation} showing the relationships between \type{Observations}, \type{Measures}, and \type{Scopes}.
%
\subsection{\type{Scope}.\attr{recognizer} as Node Selector}
The \spec{} states for the \type{Operation} referenced by the \attr{recognizer} attribute:
\begin{quote}
If given [the operation], provides a boolean operation applicable to instances of the class [defined in the \attr{class} attribute] that returns true, if, and only if, the instance is an element of the set.
{\hfill \cite[p. 20]{OMG:SMM:2012}}
\end{quote}
\noindent This specification fragment for \type{Scope} implies that the \type{Operation} can be used to select nodes from the observed model. The selection is further limited by the node type specified in the \attr{class} attribute. If a \type{Measure} is used in an \type{Observation} (expressed through an \type{ObservedMeasure}), the \attr{recognizer} \type{Operation} can be used to determine which model nodes are measured by the the \type{Measure}.
A \attr{recognizer} \type{Operation} can have parameters, which can be used to parametrize the \type{Operation}. The operation \code{getParamStrings()} in \type{Operation} returns a list of parameters derived from the code defined in the \type{Operation}.\attr{body} attribute. The \code{getArguments()} operation presents those parameters as \type{Arguments} to the system.
\paragraph{Example} A \type{Measure} shall be applied to the method declarations of \code{getBook(int id)} and \code{getCategory(int id)}. The \type{MeasureLibrary} defines a \type{Measure} with a scope targeting \type{MethodDeclaration} instances of a model and has a \attr{recognizer} defined to check method signatures.
To write such \attr{recognizer} is not complicated, but is it unclear how to apply values for the \attr{recognizer}. One option would be to specify the \type{Scope} without such parameters. However, such specialized \type{Measures} cannot be used across projects making the idea of a \type{MeasureLibrary} pointless.
A logical solution to this issue are the \attr{scopeUris} provided by \type{ObservationScopes} (see \autoref{fig:observation}). This would require the definition of a new \ac{uri} scheme, as the schemes defined in the \spec{} do not allow parameter assignments (see \cite[p. 55]{OMG:SMM:2012}. Futhermore, they define a \ac{uri} scheme, which allows to construct complex queries over the model under observation, which can be used as node selectors just like the \attr{recognizer} \type{Operation}.
Another forms of parameter passing are \type{Arguments} as shown in \autoref{fig:observation}, but this option is only present in the illustration and is not backed by the specification text. Furthermore, the this only allows one set of \type{Arguments} for all parameters declared in all \type{Measures} used by the \type{Observation}. As \type{Argument}.\attr{name} attributes are plain identifiers and do not provide some dotted notation, all parameter names of all \type{Measures} must be different.
%
\subsection{\type{ObservationScope} as Node Selector}
The second node selection concept uses \type{ObservationScopes}. An \type{ObservationScope} has a \attr{scopeUri} attribute of type \type{String} to represent an \ac{uri}. The \ac{uri} can have any semantic we define as long as it follows RFC 2396 \cite{RFC:2396}. However, such self-defined semantics will not be compatible with any other application.
The \spec{} itself defines a semantic for it \cite[p. 54f]{OMG:SMM:2012}. That \ac{uri} scheme comprises a reference to the model under observation and optional a query over the model. The query can select model nodes based on their attributes and their context. Allowed languages are OCL and XQuery. Such \ac{uri} allows it to select single nodes from the model based on their attributes, which is similar to the functionality provided by the recognizer operations combined with arguments, rendering the solution from the previous subsection obsolete. It might be possible, but not stated in the specification, that a recognizer operation of a measure can be called in the query string. However, the way how such \type{Operation} can be triggered is unclear.
A more stringent approach for the whole scenario is the use of the \attr{scopeUri} as only source for selecting model nodes. Each model node has a type and all \type{Measures} have a \type{Scope} with an attribute \attr{class} providing a pre-selection of \type{Measures} for nodes. The node type must correspond with the type specified in the \type{Scope}. Required structural relationships of nodes can still be modelled in the recognizer for the \type{Measure}, but the \attr{scopeUri} solely defines which instances are selected.
This approach does not make any use of the ability to query for arguments with \code{getArguments()} operation. It is in this context unclear what purpose they serve. The language \ac{mdl} is able to define parameters for \type{Measures}, which can be used in the \ac{mql} to assign values to \type{Measures}. This information can then be used to generate the \type{ObservationScope}.\attr{scopeUris}. However, the generation of an \ac{smm} model from an \ac{mql} model will not contain the necessary parameter information.
%
\subsection{Summary}
Both approaches have their advantages and there weak spots, lacking proper specification or resulting in ugly \ac{smm} models. However, the second approach provides a consistent way to express \ac{mdl} and \ac{mql} parameters in \ac{smm}. Therefore, we should use the second approach to implement a solution.
%%
\section{Conclusion}
The \ac{smm} meta-model is a comprehensive meta-model on the subject on measuring. The meta-model provides a separation between \type{Measures}, \type{Observations}, and \type/Measurements}, which represent the three aspects of the measuring domain. It comes with a clever type system, which uses scalar values together with \attr{units}.
On the down side, the \ac{smm} meta-model has a set of shortcomings and uses awkward meta-model structures, which are unnecessary. It uses relationship classes where bidirectional relationships are not necessary and the bidirectionality could be modelled differently. Many relationships and aggregates over relationships are never used, but declared, which looks like, that they are defined to provide model navigation capabilities. However, that aspect should be left out of the specification, as it can be provided automatically by \ac{emof} and code generators around \ac{ecore}.
The meta-model provides the capability to define measure libraries, but it is uncertain about how the measures can be parametrized. It would have been a better idea to provide a well defined way to model parameters for measures and provide a mechanism for parametrization which would be attached to observed or requested measure instances.
The selection of nodes of the model under observation is realized by an \ac{uri} including a reference to a model and a query over that model. This is one how node selection could be implemented, but it results in a lot of redundancy. Other approaches define the queries independent of the model and use the queries on all models.
\appendix
......@@ -404,6 +472,7 @@ In \ac{smm} a measure can have one or more \type{Operations}, which can have par
\acro{omg}[OMG]{Object Management Group}
\acro{emof}[EMOF]{Essential MOF}
\acro{mee}[MEE]{MAMBA Execution Engine}
\acro{uri}[URI]{Universal Resource Indicator}
\end{acronym}
doc/smm-mamba-comparision/images/observation.pdf 0 → 100644
+ 0
− 0
View file @ c3cda0df
File added
doc/smm-mamba-comparision/images/observation.svg 0 → 100644
+ 599
− 0
View file @ c3cda0df
This diff is collapsed.
doc/smm-mamba-comparision/macros.tex
+ 6
− 245
View file @ c3cda0df
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% macors.tex
%
% author: Reiner Jung
%
%% setzt pfad fr bilder
%
% Parameter:
% Neuer Pfad fr Bilder
%
% initialisierung
\newcommand{\img}{images}
%
\newcommand{\setimage}[1]{\renewcommand{\img}{#1/images}}
%% setzt pfad fr subdokumente
%
% Parameter:
% Neuer Pfad fr Bilder
%
% initialisierung
\newcommand{\docdir}{.}
%
\newcommand{\setdocdir}[1]{\renewcommand{\docdir}{#1}}
%% input mit docdir usage
%
% Parameter:
% Datei die eingebunden werden soll
\newcommand{\use}[1]{\input{\docdir/#1}}
%% \includepicture
% Erlaubt es ein Bild in ein Dokument einzufgen
%
% Parameter:
% 1. Werte fr \includegraphics z.B. die Breite width=11.7cm
% 2. Dateiname der eps-Datei im Unterverzeichnis graphics
% 3. Bildunterschrift
% 4. Label/Referenzname
\newcommand{\incpic}[4]{
\begin{figure}[ht]
\begin{center}
\fbox{
\includegraphics[#1]{\img/#2}}
\caption{#3} \label{#4}
\end{center}
\end{figure}}
%% \includepicture
% Erlaubt es ein Bildschirmabbild in ein Dokument einzufgen
% Erzeugt keinen Rahmen
%
% Parameter:
% 1. Werte fr \includegraphics z.B. die Breite width=11.7cm
% 2. Dateiname der eps-Datei im Unterverzeichnis graphics
% 3. Bildunterschrift
% 4. Label/Referenzname
\newcommand{\incscreen}[4]{
\begin{figure}[hpt]
\begin{center}
\includegraphics[#1]{\img/#2}
\caption{#3} \label{#4}
\end{center}
\end{figure}}
%% \figref
% reference a figure
\newcommand{\figref}[1]{(see fig. \ref{#1})}
%% \secref
% reference a section
\newcommand{\secref}[1]{(see section \ref{#1})}
%% \note
% Erzeugt eine Notiz im Text, welche spter noch entfernt werden muss.
% (von Michael um Autor erweitert, da das auch ganz interessant sein knnte...)
%
% Parameter:
% 1. Autor der Notiz
% 2. Die Notiz
\newcommand{\note}[1]{\paragraph{Note:} \textit{#1} \vskip 2em}
%% action
\newcommand{\actionpre}{}
\newcommand{\actionpost}{}
\newcommand{\actionrole}{}
\newcounter{actioncount}
\setcounter{actioncount}{1}
\newenvironment{action}[1]{
\renewcommand{\actionpre}{}
\renewcommand{\actionpost}{}
\renewcommand{\actionrole}{}
\vspace{3mm}
\noindent
\vline\hspace{2mm}
\begin{minipage}{0.95\textwidth}
\paragraph{Action \arabic{actioncount}: #1}
}{
\begin{description}
\ifthenelse{\equal{\actionrole}{}}{}{\item[Roles:] \actionrole}
\ifthenelse{\equal{\actionpre}{}}{}{\item[Precondition:] \actionpre}
\ifthenelse{\equal{\actionpost}{}}{}{\item[Postcondition:] \actionpost}
\end{description}\end{minipage}\\
\vspace{3mm}\stepcounter{actioncount}}
%% \pre
\newcommand{\pre}[1]{\renewcommand{\actionpre}{#1}}
%% \post
\newcommand{\post}[1]{\renewcommand{\actionpost}{#1}}
%% \role
\newcommand{\role}[1]{\renewcommand{\actionrole}{#1}}
%%
\newcounter{reqcount}
\setcounter{reqcount}{1}
\newcommand{\req}[2]{\paragraph{Requirement \arabic{reqcount}: #1} #2\stepcounter{reqcount}}
\definecolor{keywordA}{RGB}{127,24,156}
\definecolor{keywordB}{rgb}{1,0.30,0.20}
\definecolor{datatypes}{rgb}{0,0,0}
\definecolor{background}{RGB}{255,255,255}
\definecolor{comment}{rgb}{0.6,0.6,0.6}
\definecolor{string}{rgb}{0.4,0.4,0.4}
\lstset{tabsize=4,
basicstyle=\sffamily\scriptsize,
inputencoding=latin1,
numbers=none,
numberstyle=\tiny,
emphstyle=\bfseries,
stringstyle=\color{string}\sl,
keywordstyle=\bfseries,
keywordstyle=[1]\color{keywordA},
keywordstyle=[2]\color{keywordB},
keywordstyle=[3]\color{datatypes}\bfseries,
commentstyle=\color{comment},
columns=[r]fullflexible,
backgroundcolor=\color{background},
breaklines=true,
showtabs=false,
showspaces=false,
showstringspaces=false,
frame=tb,
captionpos=b}
\lstdefinelanguage{logic}{
alsoletter={},
keywords=[1]{process,condition,conditional,action,case,cases,references,start,default,send,continue,receive,subprocess,state,machine,from,to, stepwise,transition,if,then,change,with},
keywords=[2]{-, ->,this,null,true,false},
keywords=[3]{Integer,List,Collection},
string=[b]{\"},
morecomment=[l]{//},
morecomment=[s]{/*}{*/}
}
\lstdefinelanguage{types}{
alsoletter={},
keywords=[1]{communication,description,:,properties,messages,rules,interlocking,element,enumeration,state,set,
roles,statevars},
keywords=[2]{->,this,null,true,false},
keywords=[3]{Integer,List,Collection},
string=[b]{\"},
morecomment=[l]{//},
morecomment=[s]{/*}{*/}
}
\lstdefinelanguage{devices}{
keywords=[1]{device, slaves, inputs, named, fetched, from, outputs, forwarded, to, deployment, bit, inverse},
keywords=[2]{ -, ->, \{, \}, \[, \], \<, \>},
string=[b]{\"},
morecomment=[l]{//},
morecomment=[s]{/*}{*/}
}
\lstdefinelanguage{blocks}{
keywords=[1]{interlocking, unit, devices, deployment, connections, tasks},
keywords=[2]{ -, ->, \{, \}, \[, \], \<, \>},
string=[b]{\"},
morecomment=[l]{//},
morecomment=[s]{/*}{*/}
}
\lstdefinelanguage{topo}{
keywords=[1]{einbruchsknoten,weichenknoten,stumpfgleisknoten,connect,with,abzweigend,edge,from,
freimeldeabschnitt,bounded,by,achszaehlpunkt,group,hauptsignal,zugstrasse,lage,einfahrt,fahrweg,to},
keywords=[2]{end,diversion,main,head,left,right},
}
\lstdefinelanguage{mdl}{
alsoletter={[,],:,+,-,/,*},
keywords=[1]{library,meta,model,enum,interval,measure,with},
keywords=[2]{named,-,+,:,*,/,[,],in},
keywords=[3]{ID,String,String[]},
string=[b]{\"},
}
\lstdefinelanguage{mql}{
alsoletter={},
keywords=[1]{SELECT,FROM,WHERE,AS,MEMBER,OF,GROUP,BY,ORDER,OUTPUT,EVERY,AGGREGATE,OVER,MODEL,METRIC},
keywords=[2]{max,min,average}
string=[b]{\"},
morecomment=[l]{//},
morecomment=[s]{/*}{*/}
}
%% contact
\newenvironment{contact}{\singlespacing\section*{Kontakt}}
{\vbox{
\hbox{MENGES-Projektpartner\hfill}
\vskip2mm
\hbox{\textbf{\Xperson}\hfill}
\vskip1mm
\hbox{\vbox{\Xpartner}\hfill}
\vskip4mm
\hbox{\vbox{\noindent\Xaddress}\hfill}
\vskip2mm
\hbox{Tel.: \Xphone\hfill}
\hbox{Fax: \Xfax\hfill}
\vskip2mm
\hbox{E-Mail: \href{mailto:\Xmail}{\texttt{\Xmail}}\hfill}
\hbox{Web: \url{menges.informatik.uni-kiel.de}\hfill}
}
}
\newcommand{\person}[1]{\def\Xperson{#1}}
\newcommand{\partner}[1]{\def\Xpartner{#1}}
\newcommand{\address}[1]{\def\Xaddress{#1}}
\newcommand{\phone}[1]{\def\Xphone{#1}}
\newcommand{\fax}[1]{\def\Xfax{#1}}
\newcommand{\mail}[1]{\def\Xmail{#1}}
\newcommand{\inline}[2]{\lstinline[language=#1]{#2}}
\newcommand{\modisco}{\textsf{MoDisco}}
\newcommand{\spec}{\ac{smm} specification}
\newcommand{\type}[1]{\textsf{#1}}
\newcommand{\attr}[1]{\textsf{#1}}
\newcommand{\code}[1]{\texttt{#1}}
\newcommand{\val}[1]{\textsf{#1}}
doc/smm-mamba-comparision/references.bib
+ 16
− 0
View file @ c3cda0df
% This file was created with JabRef 2.7b.
% Encoding: UTF8
@techreport{RFC:2396,
added-at = {2006-12-04T13:55:41.000+0100},
author = {Berners-Lee, T.},
biburl = {http://www.bibsonomy.org/bibtex/208517a68e5da5b5e3059c7f3bd6ddb70/wikier},
description = {SWAML PFC BibTeX},
institution = {MIT},
interhash = {a6436cfe8523ac8850c4b67b687b1760},
intrahash = {08517a68e5da5b5e3059c7f3bd6ddb70},
keywords = {swaml rfc},
owner = {wikier},
timestamp = {2006-12-04T13:55:41.000+0100},
title = {{RFC} 2396: {U}niform {R}esource {I}dentifiers ({URI})},
url = {http://www.rfc-archive.org/getrfc.php?rfc=2396},
year = 1998
}
@INPROCEEDINGS{Benevides:2009,
author = {Alessander Botti Benevides and Giancarlo Guizzardi},
title = {A Model-Based Tool for Conceptual Modeling and Domain Ontology Engineering
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment