pith. sign in

arxiv: 1907.11893 · v1 · pith:75PE3CI7new · submitted 2019-07-27 · 💻 cs.SE

Five Generic Processes for Behavior Description in Software Engineering

Pith reviewed 2026-05-24 14:59 UTC · model grok-4.3

classification 💻 cs.SE
keywords behavior modelingsoftware engineeringthinging machineprocess modelingsystem behaviorsoftware architectureunified modeling
0
0 comments X

The pith

Five elementary processes form a thinging machine that models system behavior uniformly.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper proposes five generic elementary processes—creating, processing, releasing, receiving, and transferring—to combine into a higher-order thinging machine for describing behavior. Existing behavior models rely on varied approaches such as state transitions, natural language, or flowcharts, which complicate direct comparisons for consistency. The thinging machine adds memory and triggering relations to serve as a common template that supports platform-independent, decomposable, and reusable models. A sympathetic reader would care because such a unification could simplify integrated modeling of behavior and architecture while enabling formal analysis.

Core claim

The paper claims that behavior in systems can be analyzed and modeled using a thinging machine built from the five elementary processes of creating, processing, releasing, receiving, and transferring, augmented by memory and triggering relations among process stages, and that this template applies productively to examples drawn from the literature.

What carries the argument

The thinging machine (TM), a unifying higher-order process formed from the five elementary processes of creating, processing, releasing, receiving, and transferring together with memory and triggering relations.

If this is right

  • Behavior descriptions from different sources become directly comparable for consistency.
  • Integrated behavior and architecture models can be decomposed for separate expert development.
  • Models gain platform independence, reusability, and eligibility for formal analysis.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The thinging machine could map onto and reconcile existing techniques such as state transitions and flowcharts.
  • Widespread use might expose which current behavior models omit necessary process elements.
  • The approach could extend to standardize behavior specification within software architecture practices.

Load-bearing premise

The five processes plus memory and triggering relations suffice to capture every essential aspect of behavior in any system.

What would settle it

A documented system behavior that cannot be expressed using only creating, processing, releasing, receiving, transferring, memory, and triggering without introducing extra primitives.

Figures

Figures reproduced from arXiv: 1907.11893 by Sabah Al-Fedaghi.

Figure 1
Figure 1. Figure 1: Illustration of the level of the behavior description of interest in this paper (partially adapted from [15]). Use Input_account_ data>>receive account Application Other application s Error Request_EOF>> send_EOF Check_data_ consistency … User [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 3
Figure 3. Figure 3: Thinging machine. Create Receive Transfer Release Process Accept Arrive Output Input [PITH_FULL_IMAGE:figures/full_fig_p002_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Another form of description of a TM. Receive Create Release Process Arrive Accept Transfer Input Output [PITH_FULL_IMAGE:figures/full_fig_p002_4.png] view at source ↗
Figure 6
Figure 6. Figure 6: Illustration of the dynamic description of the mousetrap. [PITH_FULL_IMAGE:figures/full_fig_p003_6.png] view at source ↗
Figure 15
Figure 15. Figure 15: Different chronologies of events related to John and sleeping. [PITH_FULL_IMAGE:figures/full_fig_p005_15.png] view at source ↗
Figure 19
Figure 19. Figure 19: The event Sum is retrieved. Stream Landscape Banks Bridge Create Process Receiv e Transfe r Release [PITH_FULL_IMAGE:figures/full_fig_p006_19.png] view at source ↗
Figure 21
Figure 21. Figure 21: The behavior of the formula. Change color Paint Dry [PITH_FULL_IMAGE:figures/full_fig_p007_21.png] view at source ↗
Figure 25
Figure 25. Figure 25: Multiple behaviors (adapted from [60]) Change color Paint Dry Allowed Not allowed Time One-lane street Transfer Transfer Release Receive Receive Release [PITH_FULL_IMAGE:figures/full_fig_p007_25.png] view at source ↗
Figure 28
Figure 28. Figure 28: Multiple behaviors (adapted from [60]) Time [PITH_FULL_IMAGE:figures/full_fig_p008_28.png] view at source ↗
Figure 29
Figure 29. Figure 29: The TM static description of the multiple behaviors. [PITH_FULL_IMAGE:figures/full_fig_p008_29.png] view at source ↗
Figure 30
Figure 30. Figure 30: The events of the multiple behaviors. Drying Coloring Paint Brush Release Transfer Process Transfer Receive Process Release Transfer Release Transfer Release Release Transfer Transfer Transfer Receive Receive Process Process Release Transfer Cleaning Object Transfer [PITH_FULL_IMAGE:figures/full_fig_p008_30.png] view at source ↗
read the original abstract

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.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 1 minor

Summary. The paper proposes five generic elementary processes (creating, processing, releasing, receiving, and transferring) that combine with memory and triggering relations to define a higher-order thinging machine (TM) template. This template is applied to examples drawn from the literature on behavior modeling in software engineering, with the conclusion that the TM constitutes a valuable unifying tool for analyzing and modeling system behavior.

Significance. If the completeness and non-lossy character of the TM could be established, the framework would offer a platform-independent basis for integrating behavior descriptions with software architecture models, potentially aiding consistency checks, decomposition, and reuse across heterogeneous systems.

major comments (3)
  1. [Abstract] Abstract: the assertion that 'the results show that a TM is a valuable tool for analyzing and modeling behavior in a system' is unsupported by quantitative metrics, error analysis, formal verification, or falsification criteria; the claim rests solely on qualitative mappings to selected literature examples.
  2. [Abstract] Abstract: the sufficiency of the five listed processes plus memory and triggering relations to capture all essential behavior aspects across systems without loss or need for additional primitives is asserted via examples but not demonstrated; no argument rules out the possibility that some behaviors require further relations or that the encoding is informationally incomplete relative to state machines or Petri nets.
  3. [Abstract] Abstract: the TM is defined directly in terms of the five processes it introduces, with no external benchmarks or independent grounding cited, rendering the value judgment circular and dependent on the model's own descriptive vocabulary.
minor comments (1)
  1. [Abstract] The abstract refers to application to 'many examples from the literature' without indicating selection criteria, total count, or how representative the chosen cases are.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the comments, which highlight important aspects of how the claims in the abstract are presented. The manuscript is a conceptual proposal introducing a unifying template rather than an empirical or formal verification study. We respond to each major comment below.

read point-by-point responses
  1. Referee: [Abstract] Abstract: the assertion that 'the results show that a TM is a valuable tool for analyzing and modeling behavior in a system' is unsupported by quantitative metrics, error analysis, formal verification, or falsification criteria; the claim rests solely on qualitative mappings to selected literature examples.

    Authors: We agree the wording is too assertive for the nature of the work. The paper relies on qualitative application to examples drawn from the literature to illustrate the template's unifying potential. We will revise the abstract to replace 'show that' with phrasing such as 'indicate that' or 'suggest the potential of' a TM as a tool, to align the claim with the exploratory character of the contribution. revision: yes

  2. Referee: [Abstract] Abstract: the sufficiency of the five listed processes plus memory and triggering relations to capture all essential behavior aspects across systems without loss or need for additional primitives is asserted via examples but not demonstrated; no argument rules out the possibility that some behaviors require further relations or that the encoding is informationally incomplete relative to state machines or Petri nets.

    Authors: The manuscript does not provide a formal demonstration of completeness or non-lossiness; such a demonstration would require a separate theoretical analysis comparing expressive power with established formalisms. The five processes are proposed as elementary on the basis of recurring patterns identified across behavior descriptions in the software engineering literature, with the examples serving to show coverage in practice. We will add an explicit limitations paragraph acknowledging that additional relations or primitives might be needed for certain behaviors and that future work could investigate equivalence or embedding with state machines and Petri nets. revision: partial

  3. Referee: [Abstract] Abstract: the TM is defined directly in terms of the five processes it introduces, with no external benchmarks or independent grounding cited, rendering the value judgment circular and dependent on the model's own descriptive vocabulary.

    Authors: The processes themselves are identified from an analysis of existing behavior-modeling approaches in the literature, and the value of the resulting template is assessed by its ability to produce uniform representations of models that were originally expressed in heterogeneous notations. The mappings therefore constitute external grounding. We do not view the judgment as circular and see no need to alter the abstract on this point. revision: no

Circularity Check

0 steps flagged

No significant circularity in the TM proposal or its application to examples

full rationale

The paper defines five elementary processes, composes them into the TM template (with memory and triggering), applies the template to selected literature examples, and states that the results show TM is valuable. This is a standard conceptual proposal followed by illustrative demonstration rather than a derivation in which any claimed result reduces to its own inputs by construction. No equations, parameter fitting, self-citations, or uniqueness theorems appear in the provided text. The sufficiency of the five processes is asserted via examples but does not constitute a self-referential loop or fitted prediction.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The model rests on the domain assumption that behavior decomposes exhaustively into the five named processes; no free parameters or independently evidenced invented entities are introduced beyond the TM itself.

axioms (1)
  • domain assumption Behavior in systems can be fully described using the five elementary processes of creating, processing, releasing, receiving, and transferring together with memory and triggering relations.
    This premise is invoked to justify the TM as a unifying template.
invented entities (1)
  • Thinging machine (TM) no independent evidence
    purpose: Higher-order unifying template for behavior modeling
    New conceptual construct introduced to organize the five processes; no falsifiable handle outside the paper is supplied in the abstract.

pith-pipeline@v0.9.0 · 5767 in / 1222 out tokens · 20966 ms · 2026-05-24T14:59:04.646354+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

63 extracted references · 63 canonical work pages

  1. [1]

    The Second Workshop on Behavioural Modelling - Foundations and Application, Introduction, Call for papers, 15 June 2010, University of Pierre & Marie Curie, Paris, France

  2. [2]

    From software architecture structure and behavior modeling to implementations of cyber-physical systems ,

    J. O. Ringert, B. Rumpe, and A. Wortmann, “From software architecture structure and behavior modeling to implementations of cyber-physical systems ,” in Software Engin eering, A Editor and B. Editor, Eds. Bonn: 2013, p. 155 –170. Workshopband, LNI P -215. GI, Köllen Druck+Verlag GmbH, Bonn, 2013

  3. [3]

    On defining behavior: Some notes,

    F. Lazzeri, “On defining behavior: Some notes, ” Behavior and Philosophy, vol. 42, pp. 65–82, 2014

  4. [4]

    Tinbergen, The Study of Instinct, Oxford, UK: Oxford University Press, 1951

    N. Tinbergen, The Study of Instinct, Oxford, UK: Oxford University Press, 1951

  5. [5]

    Ontology.Encyclopedia of Database Systems, 2009

    S. T. Watson and D. Brown, “Behavior,” in Encyclopedia of Child Behavior and Development, vol. 1, A -D, S. Goldstein and J. A. Naglieri, Eds. New York, NY: Springer , 2011. doi:10.1007/978-0-387- 79061-9_304

  6. [6]

    Dretske, Explaining behavior: Reasons in a World of Causes

    F. Dretske, Explaining behavior: Reasons in a World of Causes. Cambridge, MA: MIT Press, 1988

  7. [7]

    J. O. de La Mettrie, Man a Machine and Man a Plant. Indianapolis, IN: Hackett Publishing Company, 1994

  8. [8]

    Salustri, The Purpose –Function–Behaviour–Structure Framework, DesignWIKI, 19 Jan

    F. Salustri, The Purpose –Function–Behaviour–Structure Framework, DesignWIKI, 19 Jan. 2019. https://deseng.ryerson.ca/dokuwiki/design:pfbs

  9. [9]

    R. J. Wieringa, Requirements Engineering Frameworks for Understanding. John Wiley Sons Ltd, 1996

  10. [10]

    Identifying emergent behaviors of complex systems,

    K. Mok, “Identifying emergent behaviors of complex systems,” Nature and Computers, The New Stack Newsletter, 4 Apr . 2017. https://thenewstack.io/identifying-emergent-behaviors-complex- systems-nature-computers/

  11. [11]

    Specifying software behavior for requirements and design,

    J. Kirby Jr ., “Specifying software behavior for requirements and design,” Systemics, Cybernetics and Informatics, vol. 11, no. 8, 2013

  12. [12]

    Archive for the ‘UML’ category,

    J. Brush, “Archive for the ‘UML’ category,” Philosophical Musings on Software Architecture and Design, 19 July, 2010. http://blogs.ethz.ch/sadmusings/category/uml/

  13. [13]

    The function –behaviour– structure ontology of design,

    J. S. Gero and U. Kannengiesser. 2013. “The function –behaviour– structure ontology of design,” in An Anthology of Theories and Models of Design, Chakrabarti and Blessing, Eds . London : Springer -Verlag, 2013, pp. 263–283

  14. [14]

    Conceptual modeling of structure and behavior with UML - The Top Level Object -Oriented Framework (TLOOF) approach,

    I. Reinhartz-Berger, “Conceptual modeling of structure and behavior with UML - The Top Level Object -Oriented Framework (TLOOF) approach,” ER, 2005 [24th International Conference on Conceptual Modeling, Klagenfurt, Austria, October 24-28, 2005]

  15. [15]

    Behavioral modeling of software intensive system architectures ,

    M. Farah-Stapleton and M. Auguston, “ Behavioral modeling of software intensive system architectures ,” Procedia Computer Science , vol. 20, pp. 270–276, 2013

  16. [16]

    Toward maximum grip process modeling in software engineering,

    S. Al-Fedaghi, “Toward maximum grip process modeling in software engineering,” International Journal of Computer Science and Information Security (IJCSIS), vol. 17, no. 6, July 2019

  17. [17]

    Toward a conceptual foundation for physical security : Case study of an IT department,

    S. S. Al-Fedaghi and O. Alsumait, “Toward a conceptual foundation for physical security : Case study of an IT department,” International Journal of Safety and Security Engineering, vol. 9, no. 2, pp. 137–156, 2019

  18. [18]

    Existential ontology and thinging modeling in software engineering,

    S. Al-Fedaghi, “Existential ontology and thinging modeling in software engineering,” International Journal of C omputer Science and Information Security, vol. 17, no. 3, pp. 70–80, Mar. 2019

  19. [19]

    Tracking systems as thinging machine: A case study of a service compan y,

    S. Al-Fedaghi and Y. Atiyah, “Tracking systems as thinging machine: A case study of a service compan y,” International Journal of Advanced Computer Science and Applications, vol. 9, no. 10, pp. 110–119, 2018

  20. [20]

    Enterprise asset management as a flow machine ,

    S. Al-Fedaghi and N. Al-Huwais, “Enterprise asset management as a flow machine ,” International Journal of Modeling and Optimization, vol. 8, no. 5, pp. 290–300, Oct. 2018

  21. [21]

    Thinging vs . objectfying in software engineering,

    S. Al-Fedaghi, “Thinging vs . objectfying in software engineering,” International Journal of Computer Science and Information Security, vol. 16, no. 10, pp. 87–94, July 2018

  22. [22]

    Thinging machine applied to information leakage ,

    S. Al-Fedaghi and M. BehBehani, “Thinging machine applied to information leakage ,” International Journal of Advanced Computer Science and Applications, vol. 9, no. 9, pp. 101–110, 2018

  23. [23]

    Modeling and control of engineering plant processes ,

    S. Al-Fedaghi and A. AlQallaf, “Modeling and control of engineering plant processes ,” International Journal of Applied Systemic Studies, vol. 8, no. 3, pp. 255–277, 2018

  24. [24]

    Conceptual modeling of inventory management processes as a thinging machin e,

    S. Al-Fedaghi and N. Al-Huwais, “Conceptual modeling of inventory management processes as a thinging machin e,” International Journal of Advanced Computer Science and Applications, vol. 9, no. 11, November 2018

  25. [25]

    Thinging for software engineers,

    S. Al-Fedaghi, “Thinging for software engineers,” International Journal of Computer Science and Information Security, vol. 16, no. 7, pp. 21– 29, July 2018

  26. [26]

    Conceptual modeling of a procurement process: Case study of RFP for public key infrastructure,

    S. Al-Fedaghi and M. Al-Otaibi, “Conceptual modeling of a procurement process: Case study of RFP for public key infrastructure,” International Journal of Advanced Computer Scienc e and Applications, vol. 9, no. 1, Jan. 2018

  27. [27]

    Privacy things: Systematic approach to privacy and personal identifiable information ,

    S. Al-Fedaghi, “Privacy things: Systematic approach to privacy and personal identifiable information ,” International Journal of Computer Science and Information Security, vol. 16, no. 2, Feb. 2018

  28. [28]

    Modeling an unmanned aerial vehicle as a thinging machine ,

    S. Al-Fedaghi and J. Al-Fadhli, “Modeling an unmanned aerial vehicle as a thinging machine ,” The 5th International Conference on Control, Automation and Robotics (ICCAR 2019), Beijing, China , Apr. 19–22, 2019

  29. [29]

    Conceptual modeling of an IP phone communication system : A case study ,

    S. Al-Fedaghi and G. Aldamkhi, “Conceptual modeling of an IP phone communication system : A case study ,” 18th Annual Wireless Telecommunications Symposium (WTS 2019), New York City, New York, USA, Apr. 9–12, 2019

  30. [30]

    Programming is diagramming is programming,

    S. Al-Fedaghi and E. Haidar, “Programming is diagramming is programming,” 3rd International Conferenc e on Computer, Software and Modeling, Barcelona, Spain, July 14–16, 2019

  31. [31]

    Service-oriented systems as a thinging machine: A case study of customer relationship management ,

    S. Al-Fedaghi and M. Al-Otaibi, “Service-oriented systems as a thinging machine: A case study of customer relationship management ,” IEEE International Conference on Information and C omputer Technologies (ICICT), University of Hawaii, Maui College, Kahului, Hawaii, USA, Mar. 14–17, 2019

  32. [32]

    Modeling with thinging for intelligent monitoring system ,

    S. Al-Fedaghi and Y. Atiyah, “Modeling with thinging for intelligent monitoring system ,” IEEE 89th Vehicular Technol ogy Conference: VTC2019-Spring Kuala Lumpur, Malaysia, Apr. 28–May 1, 2019

  33. [33]

    Modeling the engineering process as a thinging machine : A case study of chip manufacturing ,

    S. Al-Fedaghi and A. Hassouneh, “Modeling the engineering process as a thinging machine : A case study of chip manufacturing ,” The 8th Computer Science On line Conference (CSOC 2019). Springer Advances in Intelligent Systems and Computing, in press

  34. [34]

    Network architecture as a thinging machine,

    S. Al-Fedaghi and H. Alnasser, “Network architecture as a thinging machine,” Symposium on Mobile Computing, Wireless N etworks, & Security (CSCI-ISMC), Las Vegas, Nevada, USA, Dec. 13–15, 2018

  35. [35]

    Privacy thinging applied to the processing cycle of bank cheques ,

    S. Al-Fedaghi and M. Alsulaimi, “Privacy thinging applied to the processing cycle of bank cheques ,” 3rd International Conference on System Reliability and Safety (ICSRS 2018), Barcelona, Spain, Nov. 24–26, 2018

  36. [36]

    Diagramming language for process documentation,

    S. Al-Fedaghi and H. Almutairi, “Diagramming language for process documentation,” 15th International Conference on Applied Computing (AC 2018), Budapest, Hungary, Oct. 21–23, 2018

  37. [37]

    A small company as a thinging machine,

    S. Al-Fedaghi and H. Aljenfawi, “A small company as a thinging machine,” 10th International Conference on Information Management and Engineering (ICIME 2018), University of Salford, Manchester, UK, September 22–24, 2018

  38. [38]

    Security processes as machines : A case study,

    S. Al-Fedaghi and M. Alsharah, “Security processes as machines : A case study,” Eighth international conference on Innovative Computing Technology (INTECH 2018), August 15–17, 2018, London, UK

  39. [39]

    Control of waste water treatment as a flow machine: A case study,

    S. Al-Fedaghi and R. Al-Azmi, “Control of waste water treatment as a flow machine: A case study,” The 24th IEEE International Conference on Automation and Computing (ICAC ’18), Newcastle University, Newcastle upon Tyne, UK, 6–7 September 2018

  40. [40]

    Computer attacks as machines of things that flow ,

    S. Al-Fedaghi and M. Allah Bayoumi, “Computer attacks as machines of things that flow ,” International Conference on Security and Management (SAM’18), Las Vegas, USA, July 30–August 2, 2018

  41. [41]

    Toward modeling information in asset management : Case study using Maximo,

    S. Al-Fedaghi and N. Al-Huwais, “Toward modeling information in asset management : Case study using Maximo, ” 4th International Conference on Information Management (ICIM2018), Oxford, UK , May 25–27, 2018

  42. [42]

    Provenance as a machine,

    S. Al-Fedaghi and N. Warsame, “Provenance as a machine,” International Conference on Information Society (i -Society), Du blin, Ireland, July 15–18, 2018. (IJCSIS) International Journal of Computer Science and Information Security, Vol. 17, No. 7, July 2019

  43. [43]

    Modeling IT processes: A case study using Microsoft Orchestrator,

    S. Al-Fedaghi and M. Alsharah, “Modeling IT processes: A case study using Microsoft Orchestrator, ” 4th IEEE International Conference on Advances in Computing and Communication Engineering, Paris, France, June 22–23, 2018

  44. [44]

    User interface as a machine of things that flow ,

    S. Al-Fedaghi, “User interface as a machine of things that flow ,” The 2nd SERSC International Conference on Multimedia Technology and Human-Computer, Interaction 2018 (MTHCI 2018), Bangkok, Thailand, May 4–5, 2018

  45. [45]

    Re-conceptualization of IT services in banking industry architecture network ,

    S. Al-Fedaghi and M. Alsulaimi, “Re-conceptualization of IT services in banking industry architecture network ,” 7th IEEE International Conference on Industrial Technology and Management (ICITM 2018), Oxford University, Oxford, United Kingdom, March 7–9, 2018

  46. [46]

    Modeling banking processes ,

    S. Al-Fedaghi and M. BehBehani, “Modeling banking processes ,” International Conference on Information and Computer Technologies (ICICT 2018), DeKalb, IL, USA, March 23-25, 2018

  47. [47]

    Modeling digital circuits as machines of things that flow,

    S. Al-Fedaghi and A. Esmaeel, “Modeling digital circuits as machines of things that flow,” International Conference on Mechatronics Systems and Control Engineering (ICMSCE 2018), Amsterdam, Netherlands, Amsterdam, Netherlands Feb. 21–23, 2018

  48. [48]

    Integrated modeling methodologies and language s,

    S. Al-Fedaghi and H. Alahmad, “Integrated modeling methodologies and language s,” ACM 12th International Conference on Ubiquitous Information Management and Communication, Langkawi, Malaysia, Jan. 5–7, 2018

  49. [49]

    Re-conceptualization of IT services in banking industry architecture network ,

    S. Al-Fedaghi and M. Alsulaimi, “Re-conceptualization of IT services in banking industry architecture network ,” 7th IEEE International Conference on Industrial Technology and Ma nagement (ICITM 2018), Oxford University, Oxford, United Kingdom, March 7–9, 2018

  50. [50]

    Petri nets and machines of things that flow,

    S. Al-Fedaghi and D. Shbeeb, “Petri nets and machines of things that flow,” Intelligent Systems Conference (IntelliSys) 2018, Sept. 6 –7, 2018 in London, UK

  51. [51]

    Verbs in English grammar

    TESOL Direct, “Verbs in English grammar ” [Online] Available: https://www.tesol-direct.com/tesol-resources/english-grammar- guide/verbs/

  52. [52]

    An orientation of the theoretical aspects of verbs in English,

    M. Hedayatnia, “An orientation of the theoretical aspects of verbs in English,” Master’s Thesis, University of Richmond, 1973

  53. [53]

    What is the noun -verb methodology of process mapping?

    M. Cousins, “What is the noun -verb methodology of process mapping?” Feb. 23, 2016 [Online]. Available: http://blog.triaster.co.uk/blog/what-is-the-noun-verb-methodology-of- process-mapping

  54. [54]

    Thering, About FluentU Blog, 2019

    R. Thering, About FluentU Blog, 2019. https://www.fluentu.com/blog/english/basic-english-phrases/

  55. [55]

    Sheninger, The Process of Change, A Principal’s Reflections, July 10, 2016

    E. Sheninger, The Process of Change, A Principal’s Reflections, July 10, 2016. http://esheninger.blogspot.com/2016/07/the-process-of- change.html

  56. [56]

    Wildon Carr, The Philosophy of Change, London: MacMillan and Co., 1914

    H. Wildon Carr, The Philosophy of Change, London: MacMillan and Co., 1914. https://ia800301.us.archive.org/9/items/cu31924029119075/cu31924029 119075.pdf

  57. [57]

    Sjöstedt-H, A

    P. Sjöstedt-H, A. N. Whitehead ’s Process Philosophy, Introductory Notes for Class, 2019. http://www.philosopher.eu/texts/1248-2/

  58. [58]

    Why nouns are learned before verbs: Linguistic relativity versus natural partitioning ,

    D. Gentner, “Why nouns are learned before verbs: Linguistic relativity versus natural partitioning ,” in Language Development, vol. 2, Language, Thought and Culture, S. Kuczaj II , Ed. Eribaum, pp. 301 – 334, 1982

  59. [59]

    The thing ,

    M. Heidegger, “The thing ,” in Poetry, Language, Thought, A. Hofstadter, Trans. New York: Harper & Row, pp. 161–184, 1975

  60. [60]

    Ontological behavior modeling ,

    C. Bock and J. Odell , “Ontological behavior modeling ,” Journal of Object Technology, vol. 10, 2011, pp. 31–36. doi:10.5381/jot.2011.10.1.a3

  61. [61]

    Modelling ‘State’, Lecture 13 ,

    S. Easterbrook, “Modelling ‘State’, Lecture 13 ,” Department of Computer Science, University of Toronto, 2004/5. http://www.cs.toronto.edu/~sme/CSC340F/slides/13-state.pdf

  62. [62]

    Computation and State Machines ,

    L. Lamport, “Computation and State Machines ,” Semantic Scholar,

  63. [63]

    https://pdfs.semanticscholar.org /b901/b71fcbd2282f0fa8fc83b758a3d528df902e.pdf