Judith Michael, Victoria Torres (eds.): ER Forum, Demo and Posters 2020 115 A Missing Concept? A Short Postulation About the Need for Human Understanding and an Often Only Implicitly Given, Fundamental Aspect of Modeling Efforts Matthes Elstermann1 1 Karlsruhe Institute of Technology, 76133 Karlsruhe, Germany matthes.elstermann@kit.edu Abstract. In almost all fundamental modeling or description approaches, espe- cially those meant for the domain of (business) process, there is one description aspect often missing that is core to human understanding of the world: the as- pect of active entity or the concept of the subject and its strict differentiation from passive entities (objects). This work postulates that this simple idea is of great importance when approaching any description/modeling, be it made by humans as input/instruction for information systems or AI engines, or be it gen- erated by such a system to explain its inner workings to humans to enable better understanding and therefore acceptance. Therefore, it is proposed that any for- mal or informal modeling approach should consider these aspects in order to better facilitate human understanding of models and avoid humans working around the lack of expressiveness or try to erroneous interpret non-given infor- mation. Keywords: Process Modeling · Fundamental Modeling Concept · Subject- Orientation 1 Introduction Any kind of modeling or description is, in essence, always an act of communica- tion. It is usually done to first structure thoughts and concepts and then convey them to other human beings or as input for human-made machines as operating instructions. However, any act of communication is potentially error-prone and may cause misun- derstandings. Therefore having models that, while being as correct as possible, also are as easily conceivable as possible, is a goal to be strived for. Considering the fundamental way in which humans communicate about the world and orienting modeling efforts accordingly (if possible) may give an indication of how to improve. When humans convey information from and to one another, the simplest complete structure in all natural languages (spoken or written) is the simple active sentence. Shorter means of communication are possible in a context where with agreed-on or Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). 116 M. Elstermann “common” knowledge that makes it possible to abbreviate the information exchange. Otherwise, full information exchange requires to state an active entity, the Subject (S), an activity, verb, or predicate (P) and an object (O) upon which an activity is acted upon (See Fig. 1). The order of S, P, O, may differ. More than half of the world’s languages have a subject-object-Predicate (SOP) structure. Among them Turkish or Japanese or Latin. Roughly 30% have the subject-verb-object (SVO) structure, e.g. the English or Ger- man languages [1] with very few of the rest not starting with the subject or active entity at the beginning of a sentence. This leads to two conclusions or premises for this work: firstly, the existence and differentiation between active entities, activities and passive objects is a fundamental aspect of human perception of the world and secondly the subject is of especial im- portance and the first information expected to be given by human beings. Only if the context is clear1 or in a passive setting2, can it be omitted. Fig. 1. The principle of conveying information using human (English) language compared to description paradigms typical found in programming (from [2]) 1.1 Consequential Demand If accepted, the consequence of this consideration is that when approaching any kind of modeling, there should always (!) be a fundamental, explicit, and strict differ- entiate between active entities (subjects), passive entities (objects - including con- cepts, terms) and activities/instructions (verbs/predicates) before all other concerns or aspects. This is especially true and of importance when considering terminology or 1 E.g. in a barber shop where subject (the barber) and object (hair and scissors a.o.) are clear, the activities can be described (modeled) by only using verbs (e.g. wash, cut, style) 2 E.g. if the subject is a non-descriptive, generic “somebody” that A Missing Concept? 117 naming in any type of model – ambiguous terminology leaving interpretation of sub- ject, object, or activity should be avoided. Alternatively and more simply put, a modeler should, even if it is not his main goal, always be aware of and be able to answer the questions about his model (and ideally make that obvious by naming): Is this “concept” something to that does some- thing on its own or in cooperation with other “concepts”? Is this a “concept” describ- ing something that can be used by some entity for some purpose3 or, is this the “con- cept” an action or activity that is to be executed? This may not necessarily be the focus of modeling, but it should always be clearly stated. If this fundamental paradigm is adhered to, it should make legibility of models, be they human-created or be they output of technology (e.g., AI-based) systems describ- ing their inner workings. 2 Differentiation It is very likely that people always differ between subject, object, and activity/verb, since it is so ingrained into human communication and information exchange. The question is how well they can assign concepts and terms in models of any kind to the aforementioned terms. The problem arises if concepts are assigned erroneous or am- biguous and, e.g., properties are assigned to an activity that are more befitting to an active entity (subject vs. verb). The hypothesis here is, that if a clear differentiation is missing or at least not very obvious or ambiguous, model-perceivers will make (pos- sibly wrong) implicit assumptions about what is an active entity, what an action, and what an object to be acted upon. And if these (erroneous made) assumptions do not fit together or, based on a perceiver’s current level of understanding, are impossible to make at all, this may lead to a downright rejection of a description or model as stupid or simply wrong. Equally, it can be assumed that if they are missing or not easily discernable in a modeling formalism or modeling concept, it becomes harder for humans to cope with the description mechanism and use them. The second hypothesis here is that most modeling formalisms contain assumptions about subject, object, and verb, so to speak. However, in many cases they contain them so implicitly or are optional that consequential in the domain of a given model- ing formalism, only for insiders it is obvious what is what and what fits together how. The following section discusses these hypotheses with examples from different modeling formalisms. 2.1 Programming (General) Programming is the “art” of describing activities to solve computational problems. While not modeling per-se, a program source code, especially in a high-level pro- gramming language, can be considered the model of an algorithmic workflow. Also, 3 With „purpose“ being the properties of an active entity. 118 M. Elstermann the activity of programming is taught in almost all science, technology, engineering, and mathematic domains, so in contrast to more domain-specific approaches, this modeling approach is widely used, and many people are theoretically familiar with its description concepts. Therefore it is considered here. Furthermore, in time of increasing usage of computer systems or AI solutions, it can be argued that the border between programming and describing aspect to be con- sidered by the machines (modeling) is somewhat blurred, especially when most kinds of models are created on computers and are many are evaluated by them. 2.2 Procedural Programming Procedural programming is the main paradigm of programming languages such as C, PASCAL, or (partly) BASIC (see among others [3]). These languages are already Turing complete [4], implying that it is theoretically possible to describe any compu- tation process with them! This, in turn, implies two things: first, that modeling it is a description mechanism for computational problems or mathematical models, and secondly, that no other description mechanism is necessary in theory. The whole concept centers on describing procedures/functions/methods, which contain instructions to modify some data or to call other procedures. All methods are basically instructions of activities (therefor verbs) that can be chained or use the sub- procedure call that at the same time is the only available abstraction mechanism in this paradigm. Since this description formalism is a programming paradigm, obviously, the sub- ject conduct the activities is the computer or processor of the machine the instruction model is to be executed on. The object is also implicitly given in form of the “data” to be acted upon, which in original incantation was only the raw numerical or alpha- numerical data. That data may implicitly be used to model complex circumstances or concept; however, no formal or conceptual modeling mechanism exists to express the according concepts. However, the need to express/model descriptions for more and more complex cir- cumstances and in larger teams of human beings led to the rise of another program- ming or rather modeling paradigm that nowadays predominant is the most widely used: Object-Orientation [5]. 2.3 Object Orientation – The passive Tense As stated before, object-orientation (OO) as a description paradigm allows to mod- el individual (data) objects. It was praised as a better way to conceive computational models that fit the problems of the real world since everything can be described “as an object.” This simple statement may lead to somewhat of a misconception or misalignment in modeling. Namely, it may lead to the concept that in object-oriented programming, you can state that something is, e.g., a “car” and it can “drive.” However, this is not what can be denoted exactly. A Missing Concept? 119 As a programming paradigm, in essence, OO is a means to describe instruction for an implicitly assumed subject: again, the processor of a computer. The objects are only data concepts that may represent concepts from the real world. Still, the meth- ods/behavior (the verbs) described for an object are not its behavior but rather the behavior of the computer and how it is allowed to act upon the object. If tasked to state a natural language equivalent to object-orientation, it would be that of the passive tense, as it can conceptually be modeled what is to be done to a (data) object but now how it acts. While possibly elegant and useful, the passive tense is never the first nor the easiest description means to learn a new (natural) language to describe the world with4. When using the passive tense for describing the real-world as well as for pro- gramming, there are some conceptual problems. First, there are people not understanding the fundamentals of what can be modeled and for what purpose. People not versed well in OO but with access to UML-OO- class-diagraming tools creating conceptual non-sound models that are impossible to work with, in the programming domain because the model subject and objects mixed into each other. This, supposedly, could be the general cause for problems with OO as a modeling means. A second problem is the conceptual impossibility to describe what is to be done with two objects to create a third (see Fig. 2). If strictly staying in the passive tense, the process of combining two objects into a third is neither really part of the first two nor the resulting object but rather somewhere in between. Workarounds for this situa- tion exist; however, it can be speculated that this is one of the reasons why there for business processes modeling (see later section) there is no equivalent of object- oriented process modeling. action 1 action 2 last action to be done to be done to be done action to be done upon object 3 action 1 last action to be done to be done ? Fig. 2. Object-oriented process modeling concept (sketch). Processes are described in the pas- sive tense for different objects individually. The context of transitions, termination, and object transformations is unspecific (from [6]) The third modeling or description problem is that of the modeling/programming threads. In essence, the problem arises when parallel activities need to be described for two or more processors or subjects. Most OO programming languages (e.g., 4 Microsoft Word, the software used to create this paper even has a default setting that discour- ages a user from using the passive tense and instead go for active sentence description as they easier, more precise and therefor better to understand. 120 M. Elstermann JAVA) have the means to describe so-called thread objects that are to be executed independently from each other. However, in OO description languages, “everything is an object.” Therefore no differentiation is done between active elements (subjects) and passive entities (objects) and no language has explicit means to differentiate the two. However, the need to express the concept of subject as something different from and object is there even though they are not named that way but rather, e.g., “active objects”[7] possibly to not have to deviate from the “object” concept5. The same can be seen in the programming directive that states that threads should not hold their own data, but need to be treated differently from classical passive data objects [8]. 2.4 Functional Programming Functional programming is a very powerful description means different from the previous two programming paradigms. Its possible pros or cons cannot be discussed here. It can be stated that (admittedly based on anecdotal evidence only) opinions are divided about it either as being a superior modeling concept for computational pro- cesses or alternatively as non-maintainable nightmare only mentally accessible to its creators, which necessarily need to be well versed in this mathematical modeling method. However, it shall briefly be analyzed what is implicitly assumed in this paradigm about subject, object, and verb: Namely within this modeling concept, everything is considered a mathematical function that is necessary to be evaluated by a computer, the implicitly necessary subject. As instructions, all functions are computational activ- ities with data inputs and outputs (the objects). However, describing aspects from the real world and/or mapping them to functional models is not necessarily easy or intui- tive. 2.5 Business Process Modeling In contrast to the domain of programming, the modeling of (business) processes is not in its origination geared towards describing instructions for implicitly assumed processors. Rather by its definition, it is about describing complex networks, interac- tions, and activities of several active entities of various types, sizes, and scopes. The need to express all three aspects of subject, object, and verb is obvious if not limited to the simplest of cases. However, as Fig 3 shows, almost none of the existing modeling languages explicit- ly used for business processes (as well as data) allow to formally express all three aspects. 5 The argument here is that an „active object“ basically is the description of a “subject” but since it is programmed using classes which get instantiated into “objects” may be mental willingness to identify them as such possible. A Missing Concept? 121 Considered Modeling Development Consideration of Language Paradigm Subject Predicate/Verb Object Natural Languages n.a. Function- Flow Charts oriented Event-driven Process Function- Chains (EPC) oriented Function- Extended EPCs oriented Entity-Relationship Data- Model (ERM) Oriented Unified Modeling Lan- Object- guage (UML) oriented Calculus of Communi- Subject- cating Systems (CSS) oriented Business Process Mod- Function- ell and Notation (BPMN) oriented Parallel Activity Speci- Subject- fication Schema (PASS) oriented Fig 3: Explicit consideration of the language elements of subject, object, and predicates in various modeling concepts (translated from [9]) Naturally, the notion of (different) actors is important for business process and many of these diagramming languages have the means to attach additional infor- mation about the active entities, however most often only as an informal and optional side note without formal implications. They mostly are task/verb in their based de- scriptions. An example for additional information about active entities in business process models is the well-known swimlane concept that allows to group tasks according to their execution by the same entity. However, swimlanes are usually only graphical structuring means for human beings. While carrying the need to express the subject concept with them, rarely they have an impact on the conceptual modeling itself. They can be left off and the model would still be formally complete and consistent. The only exception for business processes according to [9] is the Parallel Activity Specification Shema (PASS), an explicitly subject-oriented business process model- ing language as introduced. 122 M. Elstermann 2.6 Fundamental Modeling Concepts The final example discussed here are the Fundamental Modelling Concepts (FMC) [10, 11], a semi-formal modeling framework to describe software-intensive systems with a supposedly easily be understood graphical notation. Fig. 4. Software Architecture Model using the Block Diagram Fundamental Modelling con- cepts [12] with active entities (squares) and passive entities (round border blocks) – the only activities expressed here are reading and writing as arrows and generalized “communication” between active entities. While being semi-formal, similar to natural languages and the PASS process mod- eling language, it emphasizes the differentiation between active and passive elements, especially in its block diagrams (Fehler! Verweisquelle konnte nicht gefunden werden.). 2.7 Other Modeling or Description Means The list of discussed approaches is far from holistic. Left out are, for example, very general and, therefore, very open modeling concepts like the Resource Description Framework (RDF) or the possibilities that, e.g., the related Web Ontology Language (OWL) offer. In both cases, it can be stated that the core element is always a name (or resource), and it is completely up to the freedom of the modeler how to use it and its interactions there. If they care for the differentiation, they can explicitly differ be- tween subject, object, and verb, but they are not required to do so conceptually. A Missing Concept? 123 Beyond that, it is expected that modeling methods exist that also differ between the concepts. However, none is known that does so explicitly and consider it an important and essential modeling aspect. 3 A missing Concept? As shown, implicitly, the concept or idea of subject, object, and verb exist in many modeling approaches, hypothetically in all. However, rarely explicitly nor even rarer as a must-be-used requirement. While descriptions of activities (or computations) essentially exist in every modeling method and due to object-orientation, the concept of object as modeling focus is not exactly unknown; it is the explicit and mandatory consideration of the subject that is missing from many. That does not mean that it is not there, but that it is not considered an elemental part or as the type of information necessary to be described explicitly at the “beginning” of a model, similarly to how an easy-to-understand active sentence is grammatically required to start with a subject. The according paradigm that calls for exactly that is called Subject-Orientation: A modeling or description paradigm for originally intended for processes that requires the explicit and continuous consideration of active entities within the bounds of a process as the conceptual center of description. Active entities (subjects) and passive elements (objects) must always be distinguished and activities or tasks can only be described in the context of a subject. The interaction between subjects is of particular importance and must explicitly be described as the exchange of information [6] [13]. Next to the initially given hypotheses6, a third one would that differentiating ex- plicitly between all three may help avoid confusion in any kind of model, especially when it comes to summaries or abstractions. E.g., abstraction relationships in models typically are something like "is-a" (inheritance), "contains/is collection of", or "uses". However, not all fit together with all modeled concepts: An activity may consist of other (sub) activities, but a subject executes activities; it does not consist of activities. Equally, an activity can be neither an active entity nor an object. However, a subject may consist of sub-entities or abstraction wise be of a type. Similar logical restrictions go with concepts of objects. E.g., a subject uses an object, but it does not consist of it7. Without a strict separation, small logical gaps are likely to occur in understanding, either because of erroneous modeling or because of incorrect interpretation when it is not clear what concept is meant. E.g., is a box in a graphical model labeled as “Busi- ness Planning” referring to the activity or to an organizational unit? One is executed at a certain point in time with a given amount of input data, while the other is a con- 6 As in their nature those hypotheses cannot be proven but rather would needed to be disprov- en. The given examples, in their briefness and incompleteness tried to argue about their ori- gins and indicate their relevance. 7 Modelling wise, it could be argued here that, e.g., a computer as an active entity consist of many passive objects like memory, hard drives or processors. However, this refers to the non-animated object of the physical computer where the computer or computer system as an active entity in a model description is an abstract idea that makes uses of physical object. 124 M. Elstermann tinuously operating entity or system that is to be handled and described quite differ- ently. With expert support, errors or misunderstandings may quickly be resolved and, therefore, not even considered that harmful. However, if the conceptual differentiation of subject, object, and verbs is what is being done anyway when describing or model- ing due to the way human beings perceive and especially describe and model the world, why not embrace it? Why not embrace subject-orientation as fundamental modeling concept in each and every modeling domain? References 1. M. S. Dryer, “Chapter Order of Subject, Object and Verb,” 2017. [Online]. Available: http://wals.info/chapter/81. [Accessed 06 02 2017]. 2. H. Buchwald, The Power of ‘As-Is’ Processes, Karlsruhe: Springer, 2009, pp. 13- 23. 3. H. Buchwald and M. Elstermann, Propädeutikum Java : Ein Buch zum Selbststudium, Karlsruhe: KIT Scientific Publishing, 2012. 4. R. Herken, The Universal Turing Machine: A Half-Century Survey., Wien: Springer, 1995. 5. M. Parbel, "Programmiersprachen 2017: Vielfalt ist gefragt," 13 10 2017. [Online]. Available: https://www.heise.de/developer/meldung/ Programmiersprachen-2017-Vielfalt-ist-gefragt-3861018.html. 6. M. Elstermann, Executing Strategic Product Planning, Karlsruhe: KIT Scientific Publishing, 2020. 7. G. Oprean and J. Pedersen, “Asynchronos Active Objects in Java,” in Communciation Process Architectures 2008 - CPA conference, New York , 2008. 8. D. Ratz, j. Scheffle, D. Sees and J. Wiesenberger, Grundkurs Programmieren in Java - 8. Auflage, Hanser , 2014. 9. W. Schmidt, A. Fleischmann and O. Gilbert, "Subjektorientiertes Geschäftsprozessmanagement," HMD Praxis der Wirtschaftsinformatik, pp. 52- 62, 2009. 10. FMC-modeling.org, "Fundamental Modeling Concepts," [Online]. Available: http://www.fmc-modeling.org/. [Accessed 01 06 2020]. 11. A. Knoepfel, B. Groene and P. Tabeling, Fundamental Modeling Concepts - Effective Communication of IT Systems, Wiley, 2006. 12. Ihpiv, "Wikipedia: Fundamental Modeling Concepts," [Online]. Available: https://upload.wikimedia.org/wikipedia/commons/4/44/FMCBlockDiagram.png. [Accessed 01 06 2020].