Static and Dynamic Aspects of Application Domains: An Inductively Defined Modeling Technique That Allows Decomposition

Modeling is one of the most important parts of requirements engineering. Most modeling techniques focus primarily on their pragmatics and pay less attention to their syntax and semantics. Different modeling techniques describe different aspects, for example, Object-Role Modeling (ORM) describes underlying concepts and their relations while System Dynamics (SD) focuses on the dynamic behavior of relevant objects in the underlying application domain. In this paper we provide an inductive definition for a generic modeling technique. Not only do we describe the underlying data structure, we also show how states can be introduced for relevant concepts and how their life cycles can be modeled in terms of System Dynamics. We also show how decomposition can be applied to master complex application domains. As a result we get an integrated modeling technique covering both static and dynamic aspects of application domains. The inductive definition of this integrated modeling technique will facilitate the implementation of supporting tools for practitioners.


Introduction
Requirements can be seen as high-level abstractions of services with precisely stated constraints that are provided by a method under which they function [1], [2]. Vessey asserts that, humans have limited information processors, therefore, decomposing the problem under study into sub-problems is of great importance [2]. He further notes that, the key to successful problem decomposition is to structure the problem into sub-problem solutions which can be integrated to form a complete solution. Wieringa [3] admits that integration of methods is the act of unifying method elements together methodically. Wieringa also notes that the process of integrating methods requires defining relationships between the methods, precise understanding of the relations between the methods and understanding of the underlying ideas of the methods, which then lead to a more principled exposition of the methods. In [4], in the context of System Dynamics (SD), it is noted that integration could make computerization of system modeling and operating of complex systems easier. This paper therefore contributes towards improving SD model conceptualization by introducing an inductive definition and introducing states to a static modeling method called Object-Role Modeling (ORM).
ORM is applicable for conceptualizing and explicitly representing processes in a problem domain. The philosophy behind ORM is that it tries to describe a Universe of Discourse (UoD) by describing the communication between its members. An ORM scheme basically is a grammar describing that communication. This grammar is also referred to as information grammar. The information grammar describes the elementary sentences that are valid in the associated UoD. From these sentences other sentences may be formed. Object Role Calculus (ORC) ( [5]) and ORM2 ( [6]) are examples of such generic systems for constructing sentences. These sentence will be referred to as information descriptors. ORC is the base for formal reasoning about the UoD. A major aspect during the design phase may be a (quantitative) simulation of the model in order to find bottlenecks for the implemented system. Such simulations are quite common in construction technology, for example, to prohibit a bridge from destruction by a too heavy load.
It is stressed here that we do not aim at introducing a completely new modelling technique. Rather, we build a generic bridge between existing techniques, such as techniques for modelling static aspects and techniques for modelling dynamic aspects. Building such a bridge will certainly not result in a decreased expressivity. For an overview on expressivity in conceptual data modeling, see [7]. This work is motivated by the fact that different modelling techniques have different communities of people who are using those techniques. The exchange of theoretical foundations between these communities is now getting more and more attention, but much more work needs to be done.
In order to generate research results which are acceptable and applicable to different communities, we have adopted a very general mechanism for the specification of models: inductive definitions. At this moment no inductive definitions for these modelling techniques are available, despite the inductive description mechanism is very powerful.
Inductive definitions use a (recursive) style in which basic elements are refined or extended in a stepwise manner. When reasoning about models and modelling techniques, the complete line of reasoning can be built using basic elements and more advanced elements. All advanced elements are ultimately defined in terms of basic elements, as in the well-known approaches of natural induction and structural induction.
The rest of this paper proceeds as follows. In Section 2 we present an inductive definition of ORM. In Section 3 we introduce the concept of states, and describe a decomposition mechanism to structure complex state structures. We also show how these states can be related to SD. In Section 4 we draw some conclusions.

Modeling Basics
In this section we will provide an inductive definition of information structures. This definition is compatible with most modern data modeling techniques. The advantage of an inductive definition is that it can follow the step-by-step construction of an information structure and thus can be the basis for building a supporting construction tool. Another advantage is that properties of information structure can be defined and proved inductively.
We start in Subsection 2.1 with some background and history of ORM. Then in Subsection 2.2 the inductive definition is described, followed in Subsection 2.3 with some examples. In Subsection 2.4 we describe and prove some properties, and, finally, in Subsection 2.5 the semantics are formally described by an inductive definition.

Background
ORM evolved from Natural-language Information Analysis Method (NIAM) [8]. It was developed in the early 70's as a fact-oriented approach for modeling information and querying the information content of a business domain at a conceptual level [9]. Originally, ORM was conceived for data modeling purposes and takes a static perspective on the domain in the sense that it aims at capturing the fact types and entity types that play potentially a role in the (dynamic) domain [10]. Fact-orientation means that it includes both, types and instances, in its models; types are called 'fact types', instances 'facts'. It supports n-ary relations, has an expressive and stable graphical notation. Its diagrams can be automatically verbalized into pseudo natural language sentences which makes it resistant to changes that cause attributes to be remodeled as object types or relationships [11]. Its formal specification and semantics are defined in [12], [13], [14]. Here we use ORM [10] and the Predicator Set Model (PSM) [7] to provide a conceptual description of object types and their relations. Objects are instances that behave according to this description. In ORM terminology, an object basically is the set of its properties. So objects with the same set of properties are assumed to be the same. The properties are used to identify the object during the communication with human beings (say). To simplify that identification, in data modeling techniques a fixed combination of properties enforces unique object identification. In the linguistically oriented ORM terminology, this is referred to as the standard name for that object.
In this paper we follow the approach originating in the Natural-language Information Analysis Method (NIAM), in which object types play roles in fact types, see [15], [16] and [17]. A NIAM model was the basis to construct the controlled semi-natural language Reference and IDea Language (RIDL, see [18] and [19]) for communication with the database. In [7] the term predicator (introduced in [20]) was used to describe the Predicator Set Model (PSM) as an extension of NIAM, and Object Role Calculus (ORC [5]) as an extension of RIDL. The ORM modeling technique [10] can be seen as a standardization of the modeling techniques sharing the NIAM ideas. The modeling process and the required competencies of its participants are described in [21].
The first proposal for adding a process-oriented perspective to the fact-based approach was the integration with activity diagrams, see for instance [22]. Many other proposal have been made, see, for example, PSM 2 ([23]) extending PSM with action types. In [24] object-role modeling (ORM) is integrated with System Dynamics (SD). As a central issue we see that states are added to object types. Actions then are seen as state-transformers.
In this paper we want to redefine the basic part of ORM techniques, the definition of the underlying meta-model for the information grammar. We base ourselves on PSM [7] because of its rigourous formal definition. The definition provides a set of structural rules required for valid models. A (concrete) model is an instantiation of these structural rules. Being a concrete model does not imply that the model is constructible in terms of elementary construction steps. In this paper we therefore focus on a constructive domain definition, also referred to as an inductive definition. An inductive definition describes the initial state and the construction operators to obtain other domains. Then in Section 3 we focus on extending object types with states. Conclusions are presented in Section 4.

Definition of ORM
An information structure IS based on an alphabet Σ and a set of domains Doms is introduced as a structure consisting of the following components: IS = Σ, Doms, Labels, Facts, Deriveds, Specs, Gens, Sets, Constraints, isTop, isSpec where Labels are the most simple object types, Facts are the basic construction mechanism for new object types, Deriveds are derived object types to be used to form more complex constructs, Sets are object types that are instantiated by sets of objects, and Constraints are population constraints for the constructed information structures. Furthermore, there are special object types that are obtained either by specialization (Specs) or by generalization (Gens). This induces a hierarchy of object types. Top is the function assigning to each object type its top (also referred to as pater familias), and isSpec is a binary relation over object types describing the specialization relation.
We will refer to the set of all object types defined in information structure IS as Objs(IS) = Labels ∪ Facts ∪ Deriveds ∪ Specs ∪ Gens ∪ Sets. As a consequence of our definition below each object type X will have (i) a unique name, which is referred to as Name(X), and (ii) a verbalizing expression referred to as vRule(X). The verbalization rule is used as the base formulation for this object type in the conceptual modeling language. If N is the name of an object type, then Obj(N) will refer to this object type. Name N is unused in IS if none of the object types has this name: As an abbreviation, we will use the following convention to address the individual components of information structure: Doms(IS) is the set of domains in IS, Labels(IS) is the set of label types, etc.

The Basic Construction Rules
Let Σ be some alphabet and Doms be some set of domains (such as boolean, integer, real and string), then a basic information structure is inductively defined as follows.

Rule 2.
Introducing the label type Let (i) IS be an information structure, (ii) N be an unused name, (iii) D ∈ Doms(IS) be some domain and (iv) let σ = ω 1 D ω 2 with ω 1 , ω 2 ∈ Σ * be a verbalization expression for label instances, then Label (N, D, σ) is a (new) label type named N taking values from domain D and verbalized via σ. The information structure resulting after adding this label type to IS is denoted IS + Label (N, D, σ). See Figure 1 for an example and a graphical representation of this rule. In many cases ω 1 is used to qualify the value from D. For numeric values ω 2 may be used to add a physical dimension, but in many cases ω 2 will be the empty string. It may also happen that both ω 1 and ω 2 are empty strings.
Rule 3. Introducing the fact type Let (i) IS be an information structure, (ii) N be an unused name, (iii) r 1 , . . . , r k (for some k > 0) be so-called role names, (iv) the objects types X 1 , . . . , X k playing these roles be elements from Objs(IS) and (v) let σ = ω 0 r 1 ω 1 . . . r k ω k with ω i ∈ Σ * for 0 ≤ i ≤ k be a verbalization expression for fact instances, then the combination Fact N, r i :X i 1 ≤ i ≤ k , σ is a fact type named N consisting of roles r i , X i 1 ≤ i ≤ k . The information structure resulting after adding this fact type to IS is denoted IS + Fact N, r i :X i 1 ≤ i ≤ k , σ . See Figure 1 for an example and a graphical representation of this rule. We will use Preds(IS) to denote the set of all roles in all fact types in information structure IS. If p ∈ Preds(IS), then Fact(p) indicates the fact type in which the role has been introduced, and Base(p) indicates the name of the object type associated with p.
Roles in different fact types may have the same role name. In such a case, the name of the corresponding fact type is used for disambiguation.
Introduction of basic object types (label types) and being able to make relations between object types is the basis for each data modeling technique. For example, the relational data model can be seen as a modeling technique that is restricted to basic construction rules. Furthermore, the relational model does not introduce (explicitly) verbalization rules. The correspondence is as follows: roles are the attributes, the fact types are the relational schemes.
Entity types are considered to be objectifications of fact types from Facts. This definition is in line, for example, with the approach taken in Fully Communication Oriented Information Modeling (FCO-IM) ( [25]) and with the relational data model ( [26]). Therefore we will not explicitly add entity types to the definition of an information structure. For graphical conventions, see Figure 1.

Introducing the Conceptual Language
The basic naming of information structure elements (object types and roles) is used to introduce a conceptual language (for more advanced verbalization strategies, see [27]). In this paper, we will use the ORC approach, see [5], but other modeling techniques (such as UML) have their own variants to introduce a similar conceptual language. Let C L (IS) be the conceptual language that is derived from information structure IS following [5]. We assume that the conceptual language defines the following syntactic categories: 1. Fact formulation: this syntactic category is used to describe elementary or compound facts, and is used to inform an information system about new information. 2. Information descriptor: this syntactic category is used to describe information subsets. 3. Condition: this syntactic category is used to describe conditions on information descriptors.
We will assume the following special constructions for information descriptors: 1. In this paper we will use the constructor OR OTHERWISE (see [5]) to combine information descriptors by taking the union of their results. We will use the shorthand notation ⊕ for this operator. 2. We furthermore use the constructor AND ALSO as an operator to intersect information descriptor results. We will use ⊗ as a shorthand notation for this operator. 3. We also use the constructor BUT NOT as the set difference operator for information descriptors. We will use as a shorthand notation for this operator. 4. Finally, we assume the check operator EXISTS that takes a fact formulation as its argument and returns true if that fact formulation, interpreted as an information descriptor, returns a non-empty result. We will use ∃ as a shorthand notation for this operator.

Adding Derived Object Types
In some cases it will be convenient to define special sets of instances in order to introduce special relations. Information descriptors from the conceptual language ORC are used to describe such special sets of instances. A derived object type is the objectification of an information descriptor: Rule 4. Introducing the derived type Let IS be an information structure, let N be an unused name, and let σ be an information descriptor taken from the conceptual language C L (IS), then Derived (N, σ) is a derived type, that is instantiated by the instances resulting from evaluating σ. The information structure resulting after adding this derived type to IS is denoted IS + Derived (N, σ).
In the remaining part of this paper we will use derived object types to introduce some special constructs.

Adding Constraints
The next mechanism that we introduce is the constraint, a rule that describes conditions that are required to hold for any instantiation of the information structure.
Rule 5. Introducing the constraint Let IS be an information structure, let N be a unique name and C a condition from the conceptual language C L (IS), then Constr (N,C) is a constraint imposed on IS. The information structure resulting after adding this constraint IS is denoted IS + Constr (N,C).
In Section 2.5 we will consider the semantics of constraints in more detail.

Identity Related Constraints
In various modeling techniques, frequently occurring constraint types have associated an easily usable graphical representation. A powerful system of constraint types helps modelers to more precisely and adequately describe the semantics of the UoD underlying their modeling activity. All modeling techniques have special notations to enforce that roles are required to be played (total role or mandatory role) and that the instance can play the role at most once (unique role). These constraints are essential to handle object identification since they can enforce that each instance of some object type is related to some unique instance from the application domain, and thus serve as a mechanism for identification. We will give a more generic description, and add the extensional uniqueness constraint that is to be used when instances are identified by sets of instances (as is the case for mathematical sets, see also [28]): 1. Total role or mandatory role. Let R be a set of roles with a common base, then the constraint total(R) requires all instances of the common base to play at least one of the roles from R. See Figure 2 for the ORM style to denote this type of constraint. A single-role mandatory constraint is represented by marking the role with a small dot. In case of multi-role mandatory constraint, a small circle (as a representation for a constraint) with a dot embedded is used. 2. Unique role. Let R be a set of roles, then the constraint unique(R) requires instances of the (derived) relation UniQuest(R) to be unique in the combination of roles in R. When all roles in R belong to the same fact type f (or ∀ r∈R [Fact(r) = f ]), then UniQuest(R) = f . When R contains roles from different fact types, then UniQuest(R) is a special derived fact type resulting from joining fact types from roles in R. A detailed description of the derived relation UniQuest(R) can be found in [14]. See Figure 2 for the ORM style to denote this type of constraint. A single-role unique role constraint is represented by marking the role with a small arrow. For a multi-role unique role constraint a small circle with the letter u embedded is used. For the constraint unique( p 1 ) we have, UniQuest( p 1 ) = Fact(p 1 ), while UniQuest( p 1 , q 1 ) = Fact(p 1 ) 1 p 2 =q 2 Fact(q 1 ). 3. Extensional uniqueness. Let R be a set of roles, then the constraint extuniq(R) specifies that R-instances are identified via the derived relation UniQuest(R) in a set-based fashion. See Figure 2 for the ORM style to denote this type of constraint.

Role Participation Constraint
Another special constraint type is the role participation constraint. Let r be a role and ρ ∈ C L (IS) be an information descriptor, then role participation constraint Part(r, ρ) states that only instances that result from evaluating ρ are entitled to play role r. Constraint mPart(r, ρ) makes this role playing mandatory. In Figure 3 we see the two manifestations of the role participation constraint. In both cases the affected role is r, being constrained by information descriptor ρ. For convenience we also show r's associated base Base(r) = A. In the left-hand situation the participation rule ρ restricts the possible candidates for participation in role r to only those instances from A that result from the evaluation of ρ. In the right-hand situation it also makes participation mandatory for all such instances.

Specialization
Specialization allows the modeler to introduce specialized versions of object types. In more advanced situations we may have multiple inheritance. For example, we may specify Supervisors and Non-smokers as two specializations of the object type Employee. Then Senior non-smoking supervisors are a specialization of both Supervisors and Non-smokers. Using specialization, the modeler can specify that some role may only be played by particular, well-defined instances of the supertype(s). As a consequence, specialization can be seen as the intended automatic addition of a participation constraint to subsequent roles. But, rather than adding these participation constraints, the roles are attached to the (derived) object type that is instantiated by the instances that are allowed to participate. Therefore, the specialization constructor may be seen as the objectification of an information descriptor from C L (IS), describing a subset of some given object type.
Rule 6. Introducing the specialization Let IS be an information structure, let N be a unique name, let P be a set of object types from IS, all with the same top element A, and let ρ be an information descriptor from the conceptual language C L (IS), then S = Spec (N, P, σ) introduces an object type named N as the specialization of the object types from P according to the specialization rule ρ, as follows: Furthermore, also S has top element A, or, Top(S) = A, and the specialization relation is extended for the newly introduced object type: Figure 4 for a graphical representation of the specialization. The information structure resulting after adding this specialization to IS is denoted IS + Spec (N, X, ρ).

Generalization
Generalization combines different object types and is used with the purpose of assigning shared properties to each of the specific underlying objects types. The generalization constructor may be seen as the objectification of the special information descriptor that is obtained as a disjoint union of the object types being generalized. We will introduce generalization via 2 constructors. The reason is that this will allow the introduction of recursive information structures.
Rule 7. Introducing the generalization Let (1) IS be an information structure, (2) N a unique name, and let (3) X be an object type, then Gen (N, X) is a generalization type named N, generalizing instances of object type X. The information structure resulting after adding this generalization to IS is denoted IS + Gen (N, X).
Rule 8. Extension generalization Let (1) IS be an information structure, (2) Gen (N, X) be a generalization from the Gens introduced so far in IS, and (3) let Y be an object type, then GenExt (N,Y ) extends the generalization named N with the object type Y . The information structure resulting after adding this generalization extension to IS is denoted IS + GenExt (N,Y ).
The graphical representation of the generalization is shown in Figure 5.

Set Type
It is possible to introduce an object type that is instantiated by sets taken from its underlying base object type.
Rule 9. Introducing the set Let (1) IS be an information structure, (2) N be a unique name, and (3) let X be some object type, then S = Set (N, X) is a set type named N instantiated by sets of base type X. The set type may be graphically represented as a circle encircling its base type (see Figure 6). An alternative is to use a special connection line between the base type and the set type. With this object type the following implicit fact type (see Figure 6, see also Figure 1) Fact S X, sN:S, eX:X , ε where N X, sN and eX are new names, is automatically added to the information structure, and also the extensional uniqueness constraint Constr Nrule, extuniq eX to guarantee S to be identifiable. The resulting information structure is denoted IS + Set (N, X).

Closure
The final step of the inductive definition of information structures is the closure rule: Only what can be formed by these information structure composition rules is an information structure.
The consequence of the inductive definition is that properties of information structures can be proven by structural induction. Let Φ be a property for information structures, then the validity of Φ(IS) for all information structures can be proven by showing that the property holds for the empty information structure ∅ g , and is invariant under each construction operator. This is described by the following scheme of structural induction: If we can prove:

Some Examples
In the following examples, we assume the following set of underlying domains: Doms = Int, String . Let Σ be a standard alphabet.
1. The relational datamodel assumes a set A of attributes. Each attribute A has associated a domain Dom(A) of possible values. Following conventions from relational algebra [26], the term relational scheme is used to refer to a set of attributes. An example is the relational scheme Takes (Student, Course) where the attributes Student and Course both have associated domain String (Figure 7). This scheme is constructed by:  2. The nested relational datamodel is an extension of the relational datamodel, allowing nested tables. In comparison with the relational model, an attribute may have a tabular value. Or, the value of an attribute can be a set of tuples from a table. An example, taken from [29], is the following NF 2 scheme: Cities (zipcode, has comp (name, president, produces (id, color))) This nested table contains for cities (identified by their zip code) the set of companies enclosed. A company is recorded by its name, president and the set of produced products. A product is identified as a combination of product id and color. The reason for storing the information in this nested fashion is to avoid redundancies. In Figure 8 this scheme is graphically displayed. The construction of this scheme is as follows:   Figure 10 models a typical graph database as introduced in [30]. A node in this graph basically is a set of properties, where each property is a key-value pair. However, if a property set contains a property with key 'Label', then the set is an edge. Edges have starting and ending nodes. This resulting scheme is constructed as follows:  The specialization rule is constructed according to the rules from ORC [5]. Figure 11 we see a scheme describing the structure of simple expressions, using a set of variables and a single composition operator F. This example shows how the inductive definition of a recursive datatype is described in terms of a generalization in ORM. In this example, expressions are defined either as a single variable or as the function F applied on a variable and an expression. The generalization is build in two generalization steps, the first corresponding to the base of the inductive definition, the second corresponding to the construction step of the inductive definition.

In
∅ g + Label (VName, String, String) + Fact Variable, with:VName , 'variable' VName + Gen (Expression, Variable) + Fact F, arg1:VName, arg2:Expression , 'F (' Variable ', ' Expression ')' + GenExt (Expression, F) Figure 11. Construction of simple expressions 6. The scheme from Figure 12 introduces a set of (elementary) states. Each elementary state is a state, but also a grouping of states can act as a (compound) state. Then the scheme from Figure 12 is constructed as follows:  Figure 13 we see a simple administration for tracking book inventories. A book is identified by either its title, or, in case of a series, the combination of the title and index number. This scheme is constructed as follows:

Information Structure Properties
Structural induction is a powerful mechanism to prove (structural) properties for all information structures. In this section we will introduce a number of predicates over information structures, and then use structural induction to prove their properties. We start with the predicate that states whether an object (name) is being used in an information structure. This predicate is inductively defined as follows: Proof. Obvious! Except for the extension of a generalization, each construction step introduces a new object type name: Lemma 2. If IS + X is an information structure then Free(Name(X), IS) or X = GenExt (Name(X), G) for some G.
Proof. Structural induction. In each construction step X of an information structure it is required that Name(X) is a fresh name, except when X = GenExt (a, G) in which case Name(X) should be a known name: ¬ Free(Name(X), IS).
Next we will focus on some rules for information structures, and show that their validness is guaranteed when the information structure is introduced stepwise as described by the inductive definition of the information grammar.

Specialization
First we consider relations associated with the specialization hierarchy. The relation isSpec (IS, a, b) states that object type a is a specialization of b in information structure IS. The isSpec-relations is defined inductively as follows: An immediate consequence is: Proof. Structural induction. The induction base is obvious. Next assume isSpec(IS, a, b) ⇒ isSpec(IS +Y, a, b) for information structure IS and each Y such that IS +Y is an information structure. Suppose IS + X is an information structure, and let isSpec(IS + X, a, b) for some object types a and b. We have to show that also isSpec(IS + X + Y, a, b) for each extension Y of IS + X. From isSpec(IS + X, a, b) we conclude that a is an object type from information structure IS + X, and thus a = Y . Applying the definition of isSpec yields the confirmatum.
The function Top(IS) : Objs(IS) → Objs(IS) assigns to each object type a from IS its top element in the specialization hierarchy. The predicate isSpec is the irreflexive transitive closure of the specialization relation that is built by the introduction of specializations in the information structure. In [7] the specialization hierarchy is defined by the following set of axioms: Proof. Structural induction. The base step is obvious since ¬ isSpec(∅ g , a, b). Next assume the statement has been proven for IS, consider information structure IS + X for some X. The predicate isSpec is the same in IS and IS + X unless X = Spec (N, P, ρ) for some N, P and ρ, in which case we have the following possibilities for isSpec(IS + X, a, b): 1. a is introduced by X, or, a = X. Since a is not an object type in IS, the relation isSpec (IS, b, a) does not hold, and also is not introduced by X. 2. b is introduced by X, or, b = X. Then the isSpec-relation is not extended for b by X, and thus is also valid in IS. This is a contradiction since b is not an object type in IS. 3. Neither a nor b are introduced by X. In this case, the relation isSpec (IS, a, b), and thus from the induction hypothesis we conclude ¬ isSpec (IS, b, a). Since in this case the isSpec-relation is not extended by X for either a or b, the confirmatum follows.

Information Structure Semantics
An information structure gets associated history that not only covers its construction process but also the construction of instances. As a consequence, at each moment during its history we can derive the population of each object type. A population of information structure IS traditionally is defined an assignment of a set of instances to each of its object types such that all construction rules and constraints of IS are satisfied. An instance of an object type may also be seen as an elementary fact generated from the verbalization rule of that object type. The set of instances associated with object type A after history H is denoted P (H)(A).
Populations are constructed in the information structure history by (stepwise) adding (elementary or compound) fact formulations, starting from the empty population. The effect of a fact formulation is that it requires, if possible, a minimal modification of the population such that the fact formulation becomes a valid sentence. Note that strictly spoken, this may be an indeterministic operation.
Consequently, we may define the history of an information structure as a sequence of (history) addition operators, where each addition either modifies the underlying information structure, or modifies its population. We will also register the points of time when the history addition operator was proclaimed. We assume some underlying ordered domain of points of time starting at point 0.
Inductively, we define an information history based on alphabet Σ and set of domains Doms and its semantics as follows, where (1) R (H) represents the information structure that results after history H, 1. ∅ h is the empty information history. This information history defines the information structure ∅ g , or, R (∅ h ) = ∅ g and the associated empty population P (∅ h ) = ∅ p . The time of the last addition is set to time 0, or, T (∅ h ) = 0. 2. Let H be an information history, let R (H) + X be a valid information structure, and let t > T (H) be a new point of time, then H + t, X is n information history provided population P (H) satisfies constraint C in case X = Constr (N,C) for some N and C. Furthermore: -the associated information structure is: R (H + t, X ) = R (H) + X; -the population P (H + t, X ) is the extension of P (H) to the newly introduced object type X if X introduces a new object type, and P (H) otherwise; -T (H + t, X ) = t. -T (H + t, Add (φ) ) = t.
From P (H) we can define the populations at any point in time as follows: We extend the definition of populations to also cover all information descriptors from C L (R (H)) (for details, see [5]). The result of the evaluation of information descriptor D thus may be denoted Pop H,t (D). When no confusion is likely to occur, we will simply write Pop t (D) rather than Pop H,t (D).

States
We assume that instances of an object type can be in various states. We are looking for a mechanism to introduce states in a natural way in the modeling technique. We assume that a state of an object type can be described by a specific combination of properties for that object type. We will use ORC as our mechanism to describe (combinations of) properties.

Elementary States
In this section we introduce a conceptual base as a vehicle to describe a complete set of states for an object type. Let D be a set of information descriptors, and let X be a set of object types.
We call D a conceptual base for X , denoted cb(D, X ), if: An information descriptor is structurally empty if at each moment its population is empty. Information descriptors are structurally independent if at no moment they can share an instance in their population. From this definition we conclude that, at each moment, all instances of object types from X are partitioned by the information descriptors in D. Each conceptual basis is maximal in the following sense: Proof. Direct consequence from C-2 and C-3.
A conceptual basis also is maximal in the following sense: Conceptual bases can be reduced into smaller conceptual bases in the following way: 1. In Figure 14 there is a partitioning constraint between roles r and q stating that each instance of A should play exactly either role of r and p. Consequently we have the following conceptual bases for object type A: (a) cb( Name(A) , A ). In this conceptual base there is only one state for each A-instance. (b) cb( r, p , A ). In this conceptual base A-instances can be in any of two roles, depending on whether they play role r or role p.  If D is a conceptual base for object type X, then at each moment t each instance x has associated a unique state.
Proof. Let x ∈ Pop t (X) at some moment t. Because of Pop t (X) = D∈D Pop t (D) we conclude x ∈ Pop t (D) for some D ∈ D. Because of the partitioning behavior of the descriptors in D as expressed in C-2, we conclude D to be unique.
We will alternatively use state t (x) = D in place of x ∈ Pop t (D), suggesting state () to be a partial function Time × Instances → D.

State Decomposition
We call D a set of elementary states for object type X if cb(D, X ). At each moment, each instance of X is in precisely one of the elementary states in D. Besides elementary states, we also introduce compound states. Compound states will enable us to focus on transitions in the information structure at various levels of abstraction (granularity). Basically, a compound state is a grouping of (elementary or compound) states, acting as a higher level state. This leads to a hierarchy of states. In this section we describe the requirements for building a composition hierarchy based on the set D of elementary states. Let S be the set of all (elementary and compound) states. The first requirement states that the composition hierarchy is based on the elementary states: The hierarchy of states is represented by the relation SubState, where SubState(x, y) is representing the fact that x is a substate of y. The hierarchical structure induced by SubState is enforced by the following requirements: States without decomposition are elementary. We will use Elem(x) to denote state x being elementary, abbreviating ¬ ∃ y [SubState(y, x)]. The only elementary states come from D: To express that x is a direct substate of y we use SubState 1 (x, y) which is an abbreviation for SubState(x, y) ∧ ¬ ∃ z [SubState(x, z) ∧ SubState(z, y)]. States can have at most one direct superstate: We will refer to D,S,SubState as an S-hierarchy for D when all requirements S-1 to S-5 are fulfilled. Then, with each state s ∈ S we associate its underlying set of information descriptors as follows: Proof. Obvious! Consequently, the set S of states induces a partitioning subtype hierarchy on the object type X. The subtype rule for state s ∈ S interpreted as a subtype object is D∈δ(s) D and population Pop t (s) = D∈δ(s) (Pop t (D)). Lemma 9. SubState(x, y) ⇒ δ(x) ⊆ δ(y) Proof. Suppose SubState(x, y), then y ∈ D because of S-4. There are 2 possibilities: 1. x ∈ D: From the definition of the δ-function we conclude x ∈ δ(y), and consequently δ(x) = x ⊆ δ(y).
Using the decomposition structure S of descriptors D, we may associate to each instance the following set of states:

State Transitions
First we introduce two helpful predicates as follows. Let Φ be a predicate over points of time, then LE (t, Φ) expresses the fact that in some period before t property Φ holds: The expression RE (t, Φ) states that Φ holds some period after t, or: In this section, let D be a semantic base for object type X, and D,S,SubState be an S-hierarchy. Looking at the history of an information structure we observe the birth of object x at time t in state s as follows: The death of instance x in state s at time t is observed as: Looking at the history of an information system we observe a transition from state s 1 to state s 2 at time t, denoted s 1 s 2 , if (see Figure 16): Transitions are carried over to superstates (see Figure 17): Each object type will have an initial state. The instances of an object type may be persistent, in which case the object type may not have a final state. Within a compound state, an initial state has no predecessor, and a final state has no successor: If a compound state has a successor then this is effectuated by any of its final states. The same holds for the case of a predecessor. This is formalized by the following rules: Finally, transitions are inherited upward in the hierarchy: We call a (compound) state x a start state of compound state y if x is an initial state and also a direct substate of y: StartState(x, y) x ∈ D in ∧ SubState 1 (x, y) We call x a birth state if it is an initial state but not the start state of another state: BirthState(x) x ∈ D in ∧ ¬ ∃ y [SubState 1 (x, y)] If x is a birth state, then we also write: where ω is virtual (source) state. If x is a death state, then we also write: x Ω where Ω also is a virtual (sink) state. Analogously we introduce a final state and a death state: FinalState(x, y) x ∈ D out ∧ SubState 1 (x, y) DeathState(x) x ∈ D out ∧ ¬ ∃ y [SubState 1 (x, y)] We call the structure B(X) = S,SubState 1 , D, , D in , D out a behavioral description of object type X. Note that an object type may have more than one behavioral description, but this will be generally not the case in practice.

Example
We discuss an example taken from [23]. In this example the life of a pop band is described. According to some basic fact types, we may distinguish the elementary states D 1 , . . . , D 6 . After setting up the band (D 1 ) the band gets a name (D 2 ). Then the band repeatedly performs actions like writing a song (D 3 ) followed by recording that song (D 4 ), or producing a recording (D 5 ). Then the band may stop its activities (D 6 ). The resulting extended ORM scheme is shown in Figure 18, focusing at the life model only. We see two compound states, S 1 that comprises the band foundation process, and S 2 covering the active life of the band. Formally, we have: Using the decomposition mechanism, it is possible to see the life of a band at various levels of abstraction. For example, in Figure 19 we have a high level view on the band's life.

Conclusion
Modern information and communication technology is having a big impact on all aspects of daily life. For organizations, a consequence may be that their information systems have to adapt to new situations, leading to rapid changes in the underlying information structure. Besides, the organizational paradigms are intertwined with the structure of the organization's information systems [31]. New developments also necessitate the making of new relationships with data from other companies to address various aspects of data science. Consequently, the question of proper Figure 19. The simplified object life model of a band. Source: [23] data (information) description representing relevant phenomena in real life becomes more and more essential. An important issue is to be able to describe both static and dynamic aspects, preferably within a single formalism. This paper has therefore presented a mechanism to use the information structure for describing information structure states and their relationships in time. In so doing, an integrated modeling technique covering both static and dynamic aspects of application domains is obtained. The inductive definition that we advocated in this paper may be used for more in-depth studies on properties of data models. As a result, we propose an extension of ORM with the behavioral description of object types to allow decomposition to master schema complexity.
Secondly, we have provided a foundation for improving system dynamics conceptualization by introducing the inductive definition for data modeling techniques in general and for ORM in particular. In the context of System Dynamics state decompositions may be used to develop more complex applications. A further point of research is to further explore this foundation both theoretically and pragmatically.