Thinging vs Objectfying in Software Engineering

In this paper, we propose the use of a modeling methodology based on the notion of thing, with a focus on the current stage of research being on the analysis phase of software system modeling. The object-oriented approach, which takes the object as a central concept, provides the opportunity to explore applying thinging to the reconceptualization of objects. Several object-oriented examples are recast in terms of thing-oriented modeling. The results indicate a positive development that leads to several possible options: (1) supplementing the object orientation (OO) paradigm with additional notations, and (2) promoting a further understanding of some aspect of the OO paradigm. The possibility of developing a new approach in modeling based on thinging also exists.Comment: 8 pages, 18 figure

Existential Ontology and Thinging Modeling in Software Engineering

This study is a sequel to a previous study entitled Thinging for Software Engineers, which showed that the notion of thing, in contrast to objectification, has some beneficial orientations in modeling. The incorporation of thinging in conceptual modeling is required to explain the roots of Heidegger s conception of things. This requires an understanding of Heidegger s existential ontology to identify any relationship to thinging. This paper is an exploration of existential ontology in search of further clarification of the concept of thinging. We start by reviewing the thinging machine (TM) introduced in Thinging for Software Engineers and provide a full example of its utilization in modeling an ordering system. We follow this with a discussion of the being (existence) of things in the word and Heidegger s interpretation of time as a possible horizon for any understanding whatsoever of being. We emphasize that the TM is not related directly to the Heideggerian notion of existence and its elaborate analysis of Dasein. However, there may be some benefit to studying non-Dasein things to provide a philosophical foundation to thinging, as utilized in TM modeling. Interestingly, the TM can be utilized to model existential ontology, thus increasing the level of understanding about them.Comment: 11 pages,17 figure

Three Levels of Modeling: Static (Structure/Trajectories of Flow), Dynamic (Events) and Behavioral (Chronology of Events)

Constructing a conceptual model as an abstract representation of a portion of the real world involves capturing the (1) static (things/objects and trajectories of flow), (2) the dynamic (event identification), and (3) the behavior (e.g., acceptable chronology of events) of the modeled system. This paper focuses on examining the behavior notion in modeling and current works in the behavior space to illustrate that the problem of behavior and its related concepts in modeling lacks a clear-cut systematic basis. The purpose is to advance the understanding of system behavior to avoid ambiguity-related problems in system specification. It is proposed to base the notion of behavior on a new conceptual model, called the thinging machine, which is a tool for modeling that establishes three levels of representation: (1) a static structural description that is constructed upon the flow of things in five generic operations (activities; i.e., create, process, release, transfer and receive); (2) a dynamic representation that identifies hierarchies of events based on five generic events; and (3) a chronology of events. This is shown through examples that support the thinging machine as a new methodology suitable for all three levels of specification.Comment: 10 pages, 16 figure

Modeling Physical/Digital Systems: Formal Event-B vs. Diagrammatic Thinging Machine

Models are centrally important in many scientific fields. A model is a representation of a selected part of the world, which is the model s target system. Here, a system consists of a software portion as a component among many others. Event-B is a modeling method for formalizing and developing systems whose components can be modeled based on set theory and first-order logic. The thinging machine (TM) is a diagram-based model establishes three levels of representation: (1) a static structural description, which is constructed upon the flow of things in five generic operations (activities; i.e., create, process, release, transfer, and receive); (2) a dynamic representation, which identifies hierarchies of events based on five generic events; and (3) a behavioral representation according to the chronology of events. This paper is an exercise in contrasting the formal Event-B to the diagrammatic TM. The purpose is to further understand modeling in computer science. This is motivated by the claim that computer scientists should not invent specific languages to do the modeling. Important notions such as events and behavior are contrasted, and a case study system of traffic on a bridge is modeled in Event-B and TM. The results seem to indicate the need for both modeling approaches.Comment: 13 pages, 18 figure

Toward Maximum Grip Process Modeling in Software Engineering

Process modeling (PM) in software engineering involves a specific way of understanding the world. In this context, philosophical work is not merely intrinsically important; it can also stand up to some of the more established software engineering research metrics. The object-oriented methodology takes an object as the central concept of modeling. This paper follows from a series of papers that focus on the notion of thinging in the context of the analysis phase of software system modeling. We use an abstract machine named the Thinging Machine (TM) as the mechanism by which things reveal themselves. We introduce a more in-depth investigation of a grand TM that Signifies the totality of entities in the modeled system. We also present new notions, such as maximum grip, which refers to the level of granularity of the significance where optimum visibility of the model s meaning is given. The outcomes of this research indicate a positive improvement in the field of PM that may lead to enhance understanding of the object-oriented approach. TM also presents the possibility of developing a new method in PM.Comment: 13 pages, 18 figure

Five Generic Processes for Behavior Description in Software Engineering

Behavior modeling and software architecture specification are attracting more attention in software engineering. Describing both of them in integrated models yields numerous advantages for coping with complexity since the models are platform independent. They can be decomposed to be developed independently by experts of the respective fields, and they are highly reusable and may be subjected to formal analysis. Typically, behavior is defined as the occurrence of an action, a pattern over time, or any change in or movement of an object. In systems studies, there are many different approaches to modeling behavior, such as grounding behavior simultaneously on state transitions, natural language, and flowcharts. These different descriptions make it difficult to compare objects with each other for consistency. This paper attempts to propose some conceptual preliminaries to a definition of behavior in software engineering. The main objective is to clarify the research area concerned with system behavior aspects and to create a common platform for future research. Five generic elementary processes (creating, processing, releasing, receiving, and transferring) are used to form a unifying higher-order process called a thinging machine (TM) that is utilized as a template in modeling behavior of systems. Additionally, a TM includes memory and triggering relations among stages of processes (machines). A TM is applied to many examples from the literature to examine their behavioristic aspects. The results show that a TM is a valuable tool for analyzing and modeling behavior in a system.Comment: 12 pages, 35 figure

Modeling the Realization and Execution of Functions and Functional Requirements

Requirements engineering plays a critical role in developing software systems. One of the most difficult tasks in this process is identifying functional requirements. A critical problem in many projects is missing requirements until late in the development cycle. In this paper, our core interest is function modeling, which refers to building models of systems based on their functionalities and on the functionalities of their subcomponents. We present a framework as the basis for specifying functional requirements via a modeling language that produces a high-level diagrammatic representation. The aim is to deliver an overall system description, facilitate communication and understanding, construct a holistic view of the system above the domains of different expertise, and lay the foundation for the design phase. We analyze the notion of function and its elementary types and apply examples of natural language description and scenarios. The results reveal a new method that lays a foundation for works on functionality and viable methodology for capturing its requirements.Comment: 12 pages, 31 figure

Modeling Events and Events of Events in Software Engineering

A model is a simplified representation of portion of reality that hides a system s nonessential characteristics. It provides a means for reducing complexity as well as visualization and communication and a basis for building it. Most models involve graphic languages during many of the software lifecycle phases. A new model, called thinging machine (TM), has recently been developed as an extension of the input-process-output framework. The paper focuses on events in a TM, offering a new perspective that captures a system s dynamic behaviors and a means of diagrammatically modeling events. The event notion is an important factor in giving semantics to specifications and providing a natural way to specify the interfaces and observable behavior of system components. Specifically, five generic TM event processes are analyzed: create, process, receive, release, and transfer. All events can be mapped (or reduced) to the events of these five event processesComment: 12 pages, 15 figure

Causality in Static Models as an Initial Constraint on the Chronology of Events in System Behavior

This paper analyzes the notion of causality in a conceptual model, mainly as applied in software engineering. Conceptual system modeling can be considered a three-level process that begins with building a static structural description to develop a dynamic model that will identify events used to specify the chronology of events. In this context, the model involves a representation of a portion of reality, based on ontology of different kinds of things and their basic relations to each other. Relations are defined in terms of their participating entities. This paper concerns relations between events, specifically causal relations among events in modeling. We examine causality in many fields of study to understand its role in modeling. The problem is that, according to many researchers, causation is so inextricably bound up in misleading associations that it is hard to define and is shrouded in mystery, controversy, and caution. We study and clarify the notion of causality through several examples, utilizing an event definition as a time thing/machine in a new conceptual modeling methodology. In conclusion, we claim that the purpose of causal relations in a system s static description is to constrain the system s behavior and thus exclude some possible chronologies of events.Comment: 12 pages, 25 figure