Proposition of an Analysis Framework

In order to classify modeling methods according to their degree of formalization an analysis framework is established in the following, comprising a set of criteria based on the generic components of modeling methods summarized in Figure 8. For each of the central components (i.e., modeling language, modeling procedure, mechanisms & algorithms), different possibili- ties for their specification in various degrees formalization are identified.

unambiguous specification that is inter-subjectively understandable and processable by differ- ent computer systems. This definition can be aligned to the one of Harel and Rumpe, stating “’formal’ is a label for any language endowed with precise and unambiguously defined syntax and semantics“(HAREL AND RUMPE, 2004, p. 70).

Components of the Analysis Framework

Modeling languages, referring to Figure 8, are composed of syntax, semantics, and notation. The syntax of a modeling language is usually described in a formal way using a meta model, therefore utilizing a meta modeling approach, or a mathematical notation like FDMM (FILL ET AL., 2012) or Z (ABRIAL, 1980). A formal specification must identify the elements of the modeling language and a precise specification of the valid relationships between those elements by means of constraints and cardinalities. An informal specification of a languages’ syntax is e.g., the definition of elements using natural language, e.g., “the organizational model con- sists of business units and relations between business units“. Semi-formal specifications result from the combination of formal and informal specifications, i.e., some elements are specified formally using a meta model whereas the relations between the elements are only described generally using natural language. Many modeling languages emphasize on a formal specifica- tion of the syntax by means of a meta model, however, they lack at formally constraining the valid relationships.

Semantics and notation of a modeling language have to be investigated in more detail as they relate to both, structural and behavioral aspects of process models. Generally, a formal notation specification defines precisely the “representation of the elements of the language“ (K ¨UHN, 2004), whereas a formal semantics specification assigns an unambiguous meaning, i.e., an inter- subjective understanding, to each element of the language’s syntax (H ¨OFFERER, 2007). In the domain of enterprise modeling, Lankhorst states that “most languages have a weak formal basis and lack a clearly defined semantics“(LANKHORST, 2009, p. 43).

Figure 21 illustrates the analysis framework. Each analysis criteria (positioned on the right border of Figure 21) is related to the corresponding component in the hierarchical structure of modeling method components defined by KARAGIANNIS AND K ¨UHN(2002) (cf. Figure 8). Subsequently, each criteria is introduced briefly by discussing its specifics and pointing to tech- niques allowing their informal, semi-formal, and formal specification.

Notation Notation is analyzed twofold: First, static notation investigates a fixed notation for

modeling language elements that is not changing. Second, dynamic notation is concerned with the question, whether a modeling language provides dynamic changes to the notation depending on the current state of the model or the current attribute value of an element. Most common modeling languages provide a static notation.

M ode ling Te chn ique Inherent Semantics Type Semantics Dynamic Notation Static Notation N ot ati on Se m an tic s M ode ling L ang ua ge M ode ling M et hod Behavioral Semantics St ruc tur al Semantic Schema Semantic Mapping Syntax Modeling Procedure Mechanisms & Algorithms

Figure 21: Analysis framework (BORK AND FILL, 2014)

The range of specifications for static and dynamic notation spans from informal by us- ing natural language, e.g., “the element is represented by a blue car“; over semi-formal by reverting to mathematical shapes, e.g., rectangle, triangle, circle; up to formal by us- ing a programming language or a precise mathematical description, e.g., “the element is represented by a square with an edge length of 2cm“.

Considering the dynamic notation, a specification of the different states or attribute values has to be given together with a mapping function to the corresponding notation in that state. The formalization of the states and the mapping influences the formalization of the dynamic notation specification. Only if both are specified in a formal manner, a formal dynamic notation can be attested.

Semantics For semantics, the following categories have been distinguished: First, semantics

are divided into Structural Semantics, Behavioral Semantics, Semantic Domain, and Se- mantic Mapping. In a second step, structural semantics has been further divided into type semanticsand inherent semantics. The decomposition is motivated by the goal to derive the most adequate and precise analysis criteria. Behavioral semantics, type semantics, and inherent semantics are therefore investigated individually.

Structural Semantics The structural semantics of a modeling language are further decom-

posed into i) Type Semantics, usually defined with the meta model by specifying the semantics of each element (i.e., type) on the meta level; and ii) Inherent Semantics as introduced by H ¨OFFERER (2007), defining the semantics of instances of the meta model types. Figure 22 illustrates the difference between type and inherent semantics.

For the formal specification of type and inherent semantics, ontologies can play an impor- tant role. “An ontology defines the common words and concepts (meanings) used to de- scribe and represent an area of knowledge. [..] Ontologies include computer-usable def- initions of basic concepts in the domain and relationships among them“ (OBRST, 2003, p. 366). Informal specifications can be natural language descriptions of the modeling method’s domain. A semi-formal specification can be realized by linking some concepts to concepts defined in an ontology, whereas others are only specified in natural language. Often, the modeling classes are specified more formally, whereas the semantics specifi- cation for the relation classes stays on an informal level.

>

Control flow object

event AND activity

… …

meta model level type semantics business process model level ontology level inherent semantics to refuse to reject to accept suggestion proposal … … … … … … refuse

proposal proposalrefused …

…

…

provision of

type semantics provision ofinherent semantics

reject suggestion

… …

Model A: Company X Model B: Company Y

Figure 22: Type and inherent semantics (cf. (H ¨OFFERER, 2007, p. 1628))

Figure 22 exemplifies the relationships between type and inherent semantics. It shows excerpts of the different models and model levels together with their type and inherent semantics derivation by reverting to an event-driven process chain and a business pro-

cess model. On the meta model level and on the ontology level, both models share the same concepts, e.g., the meta concept activity is instantiated to reject suggestion and refuse proposal. Moreover, the attribute values, in this case the name of activities and events, are mapped to concepts on the ontology level. This integration not only improves inter-subjective understanding but also model processing by means of semantic queries or comparison of multiple process models, created according to multiple modeling lan- guages.

Behavioral Semantics This criteria describes the degree of formalization according to the

execution of the process model. A formal specification of behavioral semantics can be defined by e.g., relating the specific execution semantics to the Petri net execution se- mantics PETRI(1962, 1966), or by providing some algebraic specification. An informal specification can use natural language without an machine-processable, precise formula. A semi-formal specification can result in an incomplete mapping of the language’s ele- ments to the behavioral semantics specification (i.e., not all process model elements are mapped to their respective behavioral semantics).

Semantic Schema The semantic schema defines the semantic domain of the modeling lan-

guage by specifying “the very concepts that exist in the universe of discourse. As such, it serves as an abstraction of reality, capturing decisions about the kinds of things the lan- guage should express“ (HAREL ANDRUMPE, 2004, p. 67). The spectrum of formalized specifications is the same as that for type semantics.

Semantic Mapping The semantic mapping defines the mapping between elements of the

language’s syntax and the concepts defined in the semantic schema. A formal semantic mapping relies on a formal semantic schema. Semi-formal specifications can be derived, if not all elements are associated with one exact concept of the semantic schema, whereas an informal specification of the mapping can be defined using natural language and an informal semantic schema.

As the number of investigated criteria suggests, the formalized specification of the se- mantics plays an important role. Ontologies provide an intuitive and efficient way to define the very concepts of a domain as well as the relationships between those concepts. However, ontologies itself comprise “a range of models of varying degree of semantic richness and complexity“(OBRST, 2003, p. 366). Figure 23 illustrates this range of mod- els by ordering them in increasing semantic richness from the lower left to the upper right side (cf. (SMITH ANDWELTY, 2001; DACONTA ET AL., 2003)). The spectrum ranges from weak semantics on the lower left side (e.g., Taxonomies), over conceptual models, up to strong semantics (e.g., using first order logic or modal logic).

weak semantics

strong semantics

Relational Model

Taxonomy Is Sub-Classification of

Has Narrower Meaning Than Is Subclass of Is Disjoint Subclass of with transitivity property Schema ER Thesaurus Extended ERXTM RDF/S Conceptual Model UML DAML + OIL, OWL

Description Logic Logical TheoryFirst Order Logic

Modal Logic

Figure 23: Ontology spectrum (OBRST, 2003, p. 367)

Modeling Procedure The modeling procedure is composed of steps and delivers results (cf.

Figure 8). These two criteria describe how the user actually creates valid models, i.e., the sequence of actions performed by the modeler. A formal specification of the model- ing procedure can be provided e.g., by using rule-based systems (TSALGATIDOU AND LOUCOPOULOS, 1991), Triple-Graph Grammar (TGG) (EHRIG ET AL., 2007), or con- straint definition languages like Object Constraint Language (OCL) (OBJECTMANAGE- MENT GROUP (OMG), 2010). TGGs “are a rule-based technique with a formal back- ground for specifying bidirectional model transformation[s]“ (LAUDER ET AL., 2012, p. 287).

Informal specifications can be in natural language or e.g., by a tabular specification of the different steps to be performed. A semi-formal specification can result of the combination of formal specification techniques for some modeling steps with informal specifications for some others. Another semi-formal specification can be defined by describing formally the sequence of actions that are allowed to be performed by the modeler, but staying on an informal level for the specification of the single steps itself. Therefore, a tool developer could automatically derive the valid sequence of actions to support the modeler, on the other hand it is impossible to guarantee the correct execution of the modeling actions itself.

Mechanisms & Algorithms Formal specifications for mechanisms and algorithms of arbi-

trary modeling methods have not been regarded in depth up to now. Whereas lot of effort has been put into providing formal approaches for the specification of syntax, semantics, and lately also notation (cf. SEIDEWITZ(2013)), the development of formal specification approaches for modeling method mechanisms and algorithms is still an open research area. Mechanisms and algorithms are e.g., simulation algorithms that can be performed on models, or model transformation algorithms, transforming a source model into a target model.

In the beginnings of enterprise modeling, the focus was on capturing the relevant aspects of an enterprise in conceptually models and linking them to each other. Recently, the focus has emerged, now including the generated models also as knowledge bases for further processing. Hence. mechanisms & algorithms are of increasing interest, too. A formal specification in this field can be stated, if meta models are given and the model transformation is defined by specifying a meta model mapping from the source meta model to the target meta model (FILL ANDKARAGIANNIS, 2013). For simulation algo- rithms, concrete implementations using a programming language can hold as a formalized specification. An informal specification can be achieved using natural language or use case models, whereas pseudo code notation (i.e., some programming language constructs together with natural language) can be classified as semi-formal.

Table 3 summarizes the spectrum of techniques that can be used for each analyzed criteria to produce informal, semi-formal, or formal specifications. The table provides a selection of the discussed techniques. The value C/P is used as an abbreviation for Combination or Partial. Combination means, that a semi-formal specification for a criteria can be produced by com- bining formal techniques with informal ones. Partial on the other hand indicates that a formal technique has been adopted, but not consequently for all parts of a criteria.

Generally, in case of the semi-formal instances, it can be often referred to one of the three cases: (1) a combination of some formal and informal specification elements (C), (2) a partly usage of a formal specification (P) (e.g., a meta model for the syntax specification but without defining the cardinalities of the relations), or (3) a dedicated semi-formal technique (e.g., pseudo code for mechanisms & algorithms).

The criteria semantic mapping cannot be described using the classes informal, semi-formal, and formal. The specification of the semantic mapping depends on the specification of the syntax on the one hand, and on the specification of the semantic schema on the other. Only if syntax and semantic schema are formally specified, a formal semantic mapping can be given. If at least one of the two aspects is on a semi-formal level (e.g., the syntax definition for TOVE), the semantic mapping remains on a semi-formal level, too.

Table 3: Formalized specification of modeling methods

Analysis criteria Modeling Method Specification Informal Semi-Formal Formal

Syntax Text C/P Meta Model, FDMM, Z

Type Semantics Text Taxonomy Ontology, Modal Logic Inherent Semantics Text Taxonomy Ontology, Modal Logic Behavioral Semantics Text C/P Petri nets

Semantic Schema Text Taxonomy Ontology

Semantic Mapping depends on syntax and semantic schema definition Static Notation Text Sketches Mathematical, Program-

ming Language

Dynamic Notation Text Sketches Mathematical, Program- ming Language

Modeling Procedure Text C/P TGG, OCL, BNF notation Mechanisms & Algorithms Text pseudo code Programming Language

Legend: C= combination of formal and informal specifications, P_b = partly formalized specification_b