Domain Modeling and Domain Engineering: Key Tasks in Requirements Engineering

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

  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.

  This is a preview of subscription content, log in via an institution to check access.

  Access this chapter

  Subscribe and save

  Springer+ Basic €32.70 /Month
  • Get 10 units per month
  • Download Article/Chapter or eBook
  • 1 Unit = 1 Article or 1 Chapter
  • Cancel anytime

  Buy Now

  Price includes VAT (France)

  eBook EUR 85.59 Price includes VAT (France)

  Softcover Book EUR 105.49 Price includes VAT (France)

  Hardcover Book EUR 105.49 Price includes VAT (France)

  Tax calculation will be finalised at checkout

  Purchases are for personal use only

  Similar content being viewed by others

  

  An Essence of Domain Engineering

  Chapter © 2022

  

  Domain Modelling: A Foundation for Software Development

  Chapter © 2023

  

  Domain Modeling Based on Requirements Specification and Ontology

  Chapter © 2017

  References

  1. Batory, D., McAllester, D., Coglianese, L., Tracz, W.: Domain modeling in engineering of computer-based systems. In: 1995 International Symposium and Workshop on Systems Engineering of Computer Based Systems, Tucson (1995) Google Scholar
  2. Gunter, C.A., Gunter, E.L., Jackson, M., Zave, P.: A reference model for requirements and specifications. IEEE Softw. 17(3), 37–43 (2000) ArticleGoogle Scholar
  3. Jackson, M.: Problem Frames: Analyzing and Structuring Software Development Problems. Addison-Wesley, Boston (2001) Google Scholar
  4. Kofler, Th., Ratiu, D.: Towards a reusable unified basis for representing business domain knowledge and development artifacts in systems engineering. In: DE@ER2010, Workshop on Domain Engineering (2010) Google Scholar
  5. Broy, M.: Towards a theory of architectural contracts:—schemes and patterns of assumption/promise based system specification. In: Broy, M., Leuxner, Ch., Hoare, T. (eds.) Software and Systems Safety—Specification and Verification. NATO Science for Peace and Security Series—D: Information and Communication Security, vol. 30, pp. 33–87. IOS Press, Fairfax Google Scholar
  6. Ratiu, D.: Intentional meaning of programs. Dissertation, Technische Universität München, Fakultät für Informatik (2009) Google Scholar
  7. Broy, M.: The logic of requirements – formalizing tracing, In: Schnieder, E., Tarnai, G. (eds.) Forms/Format 2012, Technische Universität Braunschweig, Beyrich Digital Service GmbH & Co. KG, pp. 2–4 Google Scholar
  8. Scholz, G., Scholz, G.: IT-Systeme für Verkehrsunternehmen. In: Informationstechnik im öffentlichen Personenverkehr. dpunkt.verlag, Heidelberg (2012) Google Scholar
  9. Broy, M.: Functional safety based on a system reference model. In: Cant, T. (ed.) Australian System Safety Conference (ASSC 2012). Conferences in Research and Practice in Information Technology (CRPIT), vol. 145. Brisbane, 23–25 May 2012 Google Scholar
  10. Basili, V.R., Rombach, H.D.: Support for comprehensive reuse. Softw. Eng. J. 6(5), 303–316 (1991) ArticleGoogle Scholar
  11. Wing, J.M.: Computational thinking. Comm. ACM 49(3), 33–35 (2006) ArticleMathSciNetGoogle Scholar
  12. Broy, M.: Software and system modeling: structured multi-view modeling, specification, design and implementation. In: Hinchey, M., Coyle, L. (eds.) Conquering Complexity, pp. 309–372. Springer (2012) Google Scholar
  13. Broy, M., Stølen, K.: Specification and Development of Interactive Systems: Focus on Streams, Interfaces, and Refinement. Springer, New York (2001) BookGoogle Scholar

  Author information

  Authors and Affiliations

  1. Institut für Informatik, Technische Universität München, 80290, Munich, Germany Manfred Broy
  1. Manfred Broy
  You can also search for this author in PubMed Google Scholar

  Corresponding author

  Editor information

  Editors and Affiliations

  1. , Dept. of Computer Science, University of Helsinki, Gustav Hällströmin katu 2b, Helsinki, 00014, Finland Jürgen Münch
  2. Institut für Informatik, Universität Hildesheim, Samelsonplatz 1, Hildesheim, 31141, Germany Klaus Schmid

  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.

  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’₁, ….

  Definition.

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

  $$ \mathrm:\mathrm\backslash \\to <<\mathrm>^> $$

  In a timed stream s, a sequence s(t) of messages is given for each time interval t ∈ IN\. 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.

  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:\mathrm\to \left( <\mathrm\backslash \\to \mathrm<<\mathrm>^>> \right) $$

  such that x(c) is a timed stream of messages of the type of channel \( \mathrm\in \mathrm.\,\,\vec<\mathbf> \) 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> \) onto output histories in \( \vec<\mathrm> \) . This way we get a functional model of a system interface behavior.

  Definition.

  A causal mapping \( \mathrm: \vec<\mathrm> \to \wp (\vec<\mathrm> ) \) 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\to <<\mathrm>^>))\to \wp (\Sigma \times (\mathrm\to <<\mathrm>^>)) $$

  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).

  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 ∩ have consistent channel types in and . □

  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.

  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 = \ denotes the set of input channels of the architecture,
  • D_A = denotes the set of generated channels of the architecture,
  • O_A = D_A\ denotes the set of output channels of the architecture,
  • D_A\O_A denotes the set of internal channels of the architecture
  • C_A = ∪ 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.

  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):

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

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

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

  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.

  Rights and permissions

  Copyright information

  © 2013 Springer-Verlag Berlin Heidelberg

  About this chapter

  Cite this chapter

  Broy, M. (2013). Domain Modeling and Domain Engineering: Key Tasks in Requirements Engineering. In: Münch, J., Schmid, K. (eds) Perspectives on the Future of Software Engineering. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-37395-4_2

  Download citation

  • .RIS
  • .ENW
  • .BIB
  • DOI : https://doi.org/10.1007/978-3-642-37395-4_2
  • Published : 22 April 2013
  • Publisher Name : Springer, Berlin, Heidelberg
  • Print ISBN : 978-3-642-37394-7
  • Online ISBN : 978-3-642-37395-4
  • eBook Packages : Computer ScienceComputer Science (R0)

  Share this chapter

  Anyone you share the following link with will be able to read this content:

  Get shareable link

  Sorry, a shareable link is not currently available for this article.

  Copy to clipboard

  Provided by the Springer Nature SharedIt content-sharing initiative