Domain Modeling and Domain Engineering: Key Tasks in Requirements Engineering

Abstract

Requirements engineering is an essential part of software and systems development. Besides the elicitation, analysis, and specification of the intrinsic system requirements as a basis for these activities, it also involves the elicitation, analysis, and specification of the information about the application domain (also called problem domain or domain for short: includes terminology, concepts, and rules). The result of this activity is an elaborated domain model, which is a model of the relevant parts of the application domain.

Roughly speaking, a domain model for a system or software development task comprises the following parts:

• The domain ontology rules, laws, terminology, and notions describing the relevant terms giving an ontology/taxonomy of the domain and specific rules and principles

  • Concepts, data types, and functions

  • Rules and laws

• The context model, which describes the general properties of the system’s environment. This includes the operational context such as software systems, physical systems, and actors, encompassing users in the environment, properties of the physical environment in case of cyber-physical systems, as well as the wider business and technological context.

These aspects can be captured by adequate data models.

The domain model collects all the information about the problem domain that must be known and understood to allow capturing requirements for the system, specifying them, implementing and verifying the system. The detailed system requirements, however, are not part of the domain model, but they are based upon it.

Ultimately, the domain model is a collection of knowledge about the application domain at an adequate level of abstraction—including the use of modeling techniques where useful.

Appendices

A.1 Appendix: The System Model

We use a specific notion of discrete systems in this paper following [12] with the following characteristics and principles.

• A discrete system has a well-defined boundary that determines its interface.

• Everything outside the system boundary is called the system’s environment. Those parts of the environment that are relevant for the system are called the system’s context. Actors in the context that interact with the system, such as users, neighbored systems, or sensor and actors connected to the physical context are called the operational context.

• A system’s interface indicates the steps through which the system interacts with its operational context. The syntactic interface defines the set of actions that can be performed in interaction with a system across its boundary. In our case, syntactic interfaces are defined by the set of input and output channels together with their types. The input channels define the input actions for a system, while the output channels define the output actions for a system.

• We distinguish between the syntactic interface, also called static interface, which describes the set of input and output actions that can take place across the system boundary, and the interface behavior (also called dynamic interface), which describes the system’s functionality; the interface behavior is captured by the causal relationship between streams of actions captured in the input and output histories. This way we define a logical behavior as well as a probabilistic behavior for systems.

• The logical interface behavior of a system is described by means of logical expressions, called interface assertions or by state machines, or it can be further decomposed into architectures.

• A system has an internal structure and behavior (“glass box view”). This structure is described by its state space with state transitions and/or by its decomposition into sub-systems forming its architecture in case the system is decomposed into a number of subsystems that interact and also provide the interaction with the system’s context. The state machine and the architecture associated with a system is called its state view and its structural or architectural view, respectively.

• In a complementary way, the behavior of a system can be described by sets of traces, which are sets of scenarios of the input and output behavior of a system. We distinguish between finite and infinite scenarios.

• Moreover, systems operate in time. In our case, we use discrete time, which seems particularly adequate for discrete systems. Sub-systems operate concurrently within the architecture.

This gives a highly abstract and at the same time quite comprehensive model of a system. This model is formalized in the following by one specific modeling theory.

A.2 Data Models: Data Types

Data models define a set of data types and some basic functions for them. A (data) type T is a name for a data set for which a family of operations is usually available. Let TYPE be the set of all data types.

A.3 Interface Behavior

Systems have syntactic interfaces that are described by their sets of input and output channels attributed by the type of messages that are communicated over them. Channels are used to connect systems to allow transmitting messages between them. Formally, a channel is an identifier for a uni-directional communication link. A set of typed channels is a set of channels with types given for each of its channels.

Definition.

Syntactic interface

Let I be the set of typed input channels and O be the set of typed output channels. The pair (I, O) characterizes the syntactic interface of a system. The syntactic interface is denoted by (I▸O). □

Figure 3 shows the syntactic interface of a system F in a graphical representation as a data flow node with its syntactic interface consisting of the input channels x₁, … of types T₁, … and the output channels y₁, … of types T’₁, ….

Fig. 3

Graphical representation of a system F as a data flow node

Definition.

Timed Streams

Given a message set M of data elements of type T, we represent a timed stream s of type T by a mapping

$$ \mathrm{s}:\mathrm{IN}\backslash \{0\}\to {{\mathrm{M}}^{*}} $$

In a timed stream s, a sequence s(t) of messages is given for each time interval t ∈ IN\{0}. In each time interval, an arbitrary, but finite number of messages may be communicated. By (M^*)∞ we denote the set of timed streams. □

A (timed) channel history for a set of typed channels C assigns to each channel c ∈ C a timed stream of messages communicated over that channel.

Definition.

Channel history

Let C be a set of typed channels; a (total) channel history x is a mapping (let IM be the universe of all messages)

$$ \mathrm{x}:\mathrm{C}\to \left( {\mathrm{IN}\backslash \{0\}\to \mathrm{I}{{\mathrm{M}}^{*}}} \right) $$

such that x(c) is a timed stream of messages of the type of channel $\mathrm{c}\in \mathrm{C}.\,\,\vec{\mathbf{C}}$ denotes the set of all total channel histories for the channel set C. □

The behavior of a system with a syntactic interface (I▸O) is defined by a mapping that maps the input histories in $\vec{\mathrm{I}}$ onto output histories in $\vec{\mathrm{O}}$. This way we get a functional model of a system interface behavior.

Definition.

I/O-Behavior (see [13])

A causal mapping $\mathrm{F}: \vec{\mathrm{I}} \to \wp (\vec{\mathrm{O}} )$ is called an I/O-behavior. By IF[I▸O] we denote the set of all (total and partial) I/O-behaviors with a syntactic interface (I▸O) and by IF the set of all I/O-behaviors. □

Interface behaviors model system functionality. For systems we assume that their interface behavior is total. F behaviors may be deterministic (in this case, the set F(x) of output histories has at most one element for each input history x) or nondeterministic.

A.4 State Machines by State Transition Functions

State machines with input and output describe system implementations in terms of states and state transitions. A state machine is defined by a state space and a state transition.

Definition.

State Machine with Syntactic Interface (I▸O)

Given a state space Σ, a state machine (Δ, Λ) with input and output according to the syntactic interface (I▸O) consists of a set Λ ⊆ Σ of initial states as well as of a nondeterministic state transition function □

$$ \Delta :\ (\Sigma \times (\mathrm{I}\to {{\mathrm{M}}^{*}}))\to \wp (\Sigma \times (\mathrm{O}\to {{\mathrm{M}}^{*}})) $$

Fig. 4

A simple state machine—described by a state transition graph

For each state σ ∈ Σ and each valuation a: I → M^* of the input channels in I by sequences of input messages, every pair (σ′, b) ∈ Δ(σ, a) defines a successor state σ′ and a valuation b: O → M^* of the output channels consisting of the sequences produced by the state transition (Fig. 5).

Fig. 5

A simple architecture—described by a data flow graph

A.5 Architecture

In the following, we assume that each system used in an architecture as a component has a unique identifier k. Let K be the set of identifiers for the components of an architecture.

Definition.

Set of Composable Interfaces

A set of component names K with a finite set of interfaces (Ik▸Ok) for each identifier k ∈ K is called composable if the following propositions hold:

• The sets of input channels Ik, k ∈ K, are pairwise disjoint,

• The sets of output channels Ok, k ∈ K, are pairwise disjoint,

• The channels in {c ∈ Ik: k ∈ K } ∩ {c ∈ Ok: k ∈ K } have consistent channel types in {c ∈ Ik: k ∈ K } and {c ∈ Ok: k ∈ K }. □

If channel names and types are not consistent for a set of systems to be used as components, we can simply rename the channels to make them consistent.

Definition.

Syntactic Architecture

A syntactic architecture A = (K, ξ) with the interface (I_A▸O_A) is given by a set K of component names with composable syntactic interfaces ξ(k) = (Ik▸Ok) for k ∈ K.

• I_A = {c ∈ Ik: k ∈ K }\{c ∈ Ok: k ∈ K } denotes the set of input channels of the architecture,

• D_A = {c ∈ Ok: k ∈ K } denotes the set of generated channels of the architecture,

• O_A = D_A\{c ∈ Ik: k ∈ K } denotes the set of output channels of the architecture,

• D_A\O_A denotes the set of internal channels of the architecture

• C_A = {c ∈ Ik: k ∈ K } ∪ {c ∈ Ok: k ∈ K } denotes the set of all channels

By (I_A▸D_A) we denote the syntactic internal interface and by (I_A▸O_A) we denote the syntactic external interface of the architecture. □

A syntactic architecture forms a directed graph with its components as its nodes and its channels as directed arcs. The input channels in I_A are ingoing arcs and the output channels in O_A are outgoing arcs for that graph.

Definition.

Interpreted Architecture

An interpreted architecture (K, ψ) for a syntactic architecture (K, ξ) associates an interface behavior ψ(k) ∈ IF[Ik▸Ok] , where ξ(k) = (Ik▸Ok), with every component k ∈ K. □

An architecture can be specified by a syntactic architecture given by its set of sub-systems and their communication channels and an interface specification for each of its components.

For an interpreted architecture A with syntactic internal interface (I_A▸D_A), we define the glass box interface behavior [×] A ∈ IF[I_A▸D_A] by the equation (let ψ(k) = Fk):

$$ \begin{gathered} ([\times ]\,\,\mathrm{A})(\mathrm{x})=\left\{ {\mathrm{y}\in {{{\vec{\mathbf{D}}}}_{\mathrm{A}}}:\exists\,\,\mathrm{z}\in {{{\vec{\mathbf{C}}}}_{\mathrm{A}}}:\mathrm{x}=\mathrm{z}|{{\mathrm{I}}_{\mathrm{A}}}\wedge \mathrm{y} = \mathrm{z}|{{\mathrm{D}}_{\mathrm{A}}}\wedge \forall\,\,\mathrm{k}\,\in \mathrm{K}:\,\,\mathrm{z}|{{\mathrm{O}}_{\mathrm{k}}}\in } \right. \hfill \\ \left. {{{\mathrm{F}}_{\mathrm{k}}}(\mathrm{z}|{{\mathrm{I}}_{\mathrm{k}}})} \right\} \hfill \\ \end{gathered} $$

[×] A describes the behavior of the architecture A. For [×] {F₁, F₂} we also write F₁ [×] F₂.

In a black box view ⊗ A ∈ IF[I_A▸O_A] onto the architecture we hide internal channels

$$ \begin{gathered} ( \otimes \mathrm{A})(\mathrm{x})=\left\{ {\mathrm{y}\in {{{\vec{\mathbf{O}}}}_{\mathrm{A}}}:\,\,\,\exists\,\,\,\mathrm{z}\,\,\in } \right.\,\,{{{\vec{\mathbf{C}}}}_{\mathrm{A}}}:\,\,\,\mathrm{x}=\mathrm{z}|{{\mathrm{I}}_{\mathrm{A}}} \wedge \mathrm{y} = \mathrm{z}|{{\mathrm{O}}_{\mathrm{A}}}\wedge \forall\,\,\mathrm{k}\in\,\,\mathrm{K}:\,\,\mathrm{z}|{{\mathrm{O}}_{\mathrm{k}}}\,\,\in \hfill \\ \left. {{{\mathrm{F}}_{\mathrm{k}}}(\mathrm{z}|{{\mathrm{I}}_{\mathrm{k}}})} \right\} \hfill \\ \end{gathered} $$

⊗ A describes the interface behavior of the architecture A. For ⊗ {F₁, F₂} we also write F₁ ⊗ F₂ (Fig. 6).

Fig. 6

Abstraction functions between modeling concepts

A.6 Relating the Modeling Concepts

The three basic modeling concepts can be related as shown in Fig. 4. Through interface abstractions we can relate state machines and architectures to interfaces.