Many modeling languages, especially graphical ones, concentrate on the ease of expression in specifying certain aspects of a system that need to be developed. However, this often leads to a reduced ability to express complex relations between particular elements in the model. This is certainly obvious when using UML’s class diagrams, but also occurs in specificationoriented versions of state machines, activity diagrams, business process models, and variants of architectural description languages. The restricted ability to describe additional constraints usually leads to the demand for an expressive logic that is used on top of the underlying modeling language. The Object Constraint Language (OCL), as part of the UML, is such an example. In the context of class diagrams, it allows the description of invariants in the form of relations between attributes, as well as structural restrictions between objects during runtime.
A logic formula is either true or false. In terms of logic, there is no other possibility. The Law of the Excluded Middle (i.e., either a formula is true, or its negation is true—there is no third possible value) is a core axiom in logic and has been accepted by logicians throughout the deep history of development of mathematics and philosophy. The truth values are of such importance that many programming languages have a builtin type that represents these two values; for example, a “Boolean” (going back to George Boole, 1815–1864) type that has values “true” and “false”.
Computers, like humans, have restrictions in their abilities to deduce truth. In particular, the theory of computability allows us to understand when a logic formula is true, but the computer does not recognize this when “executing” the formula. Hence, logicians have tried to describe this behavior of computers by introducing denotational semantics as a form of mapping each syntactic construct to the result obtained when the computer executes the formula. In the case of a logic formula, there are three potential values in the notation and semantics: True, false and “undef”. This third value, called “undef”, is a virtual construct of humans that defines a denotational semantics for languages. “Undef” occurs when the computer does not terminate, when emulating the formula, or terminates in an extraordinary state (e.g., an exception). Therefore, “undef” in its purest sense is not part of the syntax of the language itself.
“Undef” is an interesting construct when reasoning about the behavior of programs. Many verification tools have explicitly added “undef” as an element of any type, because the execution of any expression may fail. Thus, the Boolean type suddenly becomes threevalued. This leads to interesting challenges at the logic level. For example, the traditional logic laws (e.g., commutativity, associativity, and idempotence of “and” and “or”) should be retained. The number of cases to be handled in a proof, as well as when intellectually designing a system, should be small; handling of “undef” should not introduce too many exceptions and extra cases to handle. Please note that “and” has four cases in 2valued logics, but nine cases in 3valued logics, which is more than twice the potential values in a 2valued logic.
Different solutions have been proposed (e.g., extending logics to three values, like in Kleene logic, or strictly separating the Boolean type to 3 elements and the Truth values to 2 elements). All of the solutions have individual advantages and disadvantages, sometimes very much dependent on the purpose and use of the formula, such as: when a formula is used mainly for programming, when a formula is for specifying in an abstract way and then, for example, deriving tests from a specification, or for verifying certain properties in critical parts of a system.
“Undef” is also an interesting construct when modeling the desired behavior from a safety or security point of view. For example, robustness to some extent explicitly refers to the definedness of functionalities. This led to a need to add “undef” as an explicit value to a modeling language, but also to certain programming languages. The very famous “null” in many programming languages is such a construction. The logic of OCL also provides explicit mechanisms to describe the absence of a truth value by “null” and invalidity of a formula by “invalid”. This allows the convenient expression of certain effects, for example when retrieving data from a database, where “null” describes missing data. Thus, it can be seen as a valid mechanism to extend forms of types to these values. However, from the denotational semantics point of view, these are just ordinary real values and again the virtual value “undef” is necessary to describe nonterminating execution. The OCL Boolean type with all of these options has roughly five values (“true”, “false”, “invalid”, “null” and of course the virtual “undef”).
It is necessary to clearly separate a Boolean type, which is part of the underlying programming language and thus of the system under development, from the Truth values. The Truth values are not part of the system under development and need not be used to type attributes or variables, but describe the logical outcome of the meaning of a formula. Tertium non datur.
When we use a logic formula during the execution of a test, then we are confronted again with the restricted ability to deduce truth computationally (especially in nonterminating evaluations). However, we believe that in a modern language, such as Java, where many potential sources for nontermination are eliminated, this is not a practical problem anymore. For example, infinite loops are easy to detect by humans and infinite recursion may terminate eventually with a StackOverflow exception. If the execution of a logic formula terminates with an exception, the formula is simply false.The truth shall not be compromised by alternate truth and false values.
Thus, we think it is necessary for models, but first of all for designers of modeling languages including logics, to explicitly separate the truth values from the Boolean type. It also does not make sense to try to inject everything into computational types, because it complicates the logic formulas to be defined beyond the intrinsic necessity.
Content of this issue
This issue contains the theme section of Business Process Modeling, Development, and Support (BPMDS’2014): “The Human Perspective in Business Processes”, with Selmin Nurcan and Rainer Schmidt as Guest Editors. The included papers are described in the Guest Editorial.

“A case study about the improvement of business process models driven by indicators” by Felix Garcia, Laura SanchezGonzalez, Francisco Ruiz, and Mario Piattini.

“Refinementbased Validation of EventB Specifications” by Atif Mashkoor, Faqing Yang, and JeanPierre Jacquot.

“Design notations for secure software: a systematic literature review” by Alexander van den Berghe, Riccardo Scandariato, Koen Yskout, and Wouter Joosen.

“A graphtheoretic method for the inductive development of reference process models” by Jana Rehse, Peter Fettke, and Peter Loos.

“An integrated semantics for reasoning about SysML design models using refinement” by Lucas Lima, Alvaro Miyazawa, Ana Cavalcanti, Márcio Cornélio, Juliano Iyoda, Augusto Sampaio, Ralph Hains, Adrian Larkham, and Vaughan Lewis.

“Supporting aspect orientation in business process management—From process modelling to process enactment” by Amin Jalali, Amin, Chun Ouyang, Petia Wohed, and Paul Johannesson.