OKSIMO SW – Minimal Basic Requirements

Integrating Engineering and the Human Factor (info@uffmm.org)
eJournal uffmm.org ISSN 2567-6458, January 8, 2021
Author: Gerd Doeben-Henisch
Email: gerd@doeben-henisch.de

CONTEXT

As described in the uffmm eJournal  the wider context of this software project is an integrated  engineering theory called Distributed Actor-Actor Interaction [DAAI]. This includes Human Machine Intelligence [HMIntelligence]  as part of Human Machine Interaction [HMI]. In  the section Case Studies of the uffmm eJournal there is also a section about Python co-learning – mainly dealing with python programming – and a section about a web-server with Dragon. This document is part of the Case Studies section.

CONTENT

In the long way of making the theory  as well as the software [SW] more concrete we have reached January 5, 2021 a first published version on [www.]oksimo.com.  This version contains a sub-part of the whole concept which I call here the Minimal Basic Version [MBV] of the osimo SW. This minimal basic will be tested until the end of february 2021. Then we will add stepwise all the other intended features.

THE MINIMAL BASIC VERSION

oksimo SW Minimal Basic Version Jan 3, 2021
oksimo SW Minimal Basic Version Jan 3, 2021

If one compares this figure with the figure of the Multi-Group Management from Dec 5, 2020 one can easily detect simplifications for the first modul now called Vision [V] as well as for the last modul called Evaluation [EVAL].

While the basic modules States [S], Change Rules [X] and Simulator [SIM] stayed the same the mentioned first and last module have slightly changed in the sense that they have become simplified.

During the first tests with the oksimo reloaded SW it became clear that for a simulation unified with evaluation  it is sufficient to have at least one vision V to be compared with an actual state S whether parts of the vision V are also part of the state S. This induced the requirement that a vision V has to be understood as a collection of statements where earch statement describes some aspect of a vision as a whole.

Example 1: Thus a global vision of a city to have a ‘Kindergarten’ could be extended with facts like ‘It is free for all children’, ‘I is constructed in an ecological acceptable manner’, …

Example 2: A global vision to have a system interface [SI] for the oksimo reloaded SW could include statements (facts) like: ‘The basic mode is text input in an everyday language’, ‘In an advanced mode you can use speech-recognition tools to enter a text into the system’, ‘The basic mode of the simulation output is text-based’, ‘In an advanced mode you can use text-to-speech SW to allow audio-output of the simulation’, ….

Vision V – Statement S: The citizen which will work with the oksimo reloaded SW has now only to distinguish between the vision V which points into some — as such — unknown future and the given situation S describing some part of the everyday world. The vision with all its possible different partial views (statements, facts) can then be used to a evaluate a given state S whether the vision is already part of it or not. If during a simulation a state S* has been reached and the global vision ‘The city has a Kindergarten’ is part of S*  but not the partial aspects ‘It is free for all children’, ‘I is constructed in an ecological acceptable manner’,  then only one third of the vision has been fulfilled: eval(V,S*)= 33,3 … %. As one can see the amount of vision facts determines the fineness of the evaluation.

Requirements Point of View: In Software Engineering [SWE] and — more general — in Human-Machine Interaction [HMI] as part of System Engineering [SE] the analysis phase is characterized by a list of functional and non-functional requirements [FR, NFR]. Both concepts are in the oksimo SW parts of the vision modul. Everything you think of  to be important for your vision you can write down as some aspect of the vision.  And if you want to structure your vision into several parts you can edit different vision documents which for a simulation can be united to one document again.

Change Rules [X]: In the minimal basic version only three components of a change rule X will be considered: The condition [COND] part which checks whether an actual state S satisfies (fulfills)  the condition; the Eplus part which contains facts which shall be added to the actual state S for the next turn; the Eminus part which contains facts which shall be removed from the actual state S für the next turn. Other components like Probability [PROB] or Model [MODEL] will be added in the future.

KOMEGA REQUIREMENTS No.4, Version 1

ISSN 2567-6458, 26.August 2020
Email: info@uffmm.org
Author: Gerd Doeben-Henisch
Email: gerd@doeben-henisch.de

CONTEXT

As described in the uffmm eJournal  the wider context of this software project is a generative theory of cultural anthropology [GCA] which is an extension of the engineering theory called Distributed Actor-Actor Interaction [DAAI]. In  the section Case Studies of the uffmm eJournal there is also a section about Python co-learning – mainly
dealing with python programming – and a section about a web-server with
Dragon. This document will be part of the Case Studies section.

PDF DOCUMENT

requirements-no4-v1-26Aug2020

The Simulator as a Learning Artificial Actor [LAA]. Version 1

ISSN 2567-6458, 23.August 2020
Email: info@uffmm.org
Author: Gerd Doeben-Henisch
Email: gerd@doeben-henisch.de

CONTEXT

As described in the uffmm eJournal  the wider context of this software project is a generative theory of cultural anthropology [GCA] which is an extension of the engineering theory called Distributed Actor-Actor Interaction [DAAI]. In  the section Case Studies of the uffmm eJournal there is also a section about Python co-learning – mainly
dealing with python programming – and a section about a web-server with
Dragon. This document will be part of the Case Studies section.

Abstract

The analysis of the main application scenario revealed that classical
logical inference concepts are insufficient for the assistance of human ac-
tors during shared planning. It turned out that the simulator has to be
understood as a real learning artificial actor which has to gain the required
knowledge during the process.

PDF DOCUMENT

LearningArtificialActor-v1 (last change: Aug 23, 2020)

KOMEGA REQUIREMENTS No.2. Actor Story Overview

ISSN 2567-6458, 26.July – 12.August 2020
Email: info@uffmm.org
Author: Gerd Doeben-Henisch
Email: gerd@doeben-henisch.de

CONTEXT

As described in the uffmm eJournal  the wider context of this software project is a generative theory of cultural anthropology [GCA] which is an extension of the engineering theory called Distributed Actor-Actor Interaction [DAAI]. In  the section Case Studies of the uffmm eJournal there is also a section about Python co-learning – mainly
dealing with python programming – and a section about a web-server with
Dragon. This document will be part of the Case Studies section.

PDF DOCUMENT

requirements-no2-v1-11Aug2020 (Last change: August 12, 2020)

REVIEWING TARSKI’s SEMANTIC and MODEL CONCEPT. 85 Years Later …

eJournal: uffmm.org, ISSN 2567-6458,
8.August  2020
Email: info@uffmm.org
Author: Gerd Doeben-Henisch
Email: gerd@doeben-henisch.de

85 Years Later

The two papers of Tarski, which I do discuss here, have been published in 1936. Occasionally I have already read these paper many years ago but at that time I could not really work with these papers. Formally they seemed to be ’correct’, but in the light of my ’intuition’ the message appeared to me somehow ’weird’, not really in conformance with my experience of how knowledge and language are working in the real world. But at that time I was not able to explain my intuition to myself sufficiently. Nevertheless, I kept these papers – and some more texts of Tarski – in my bookshelves for an unknown future when my understanding would eventually change…
This happened the last days.

review-tarski-semantics-models-v1-printed

BACK TO REVIEWING SECTION

Here

 

KOMEGA REQUIREMENTS No.1. Basic Application Scenario

KOMEGA REQUIREMENTS No.1. Basic Application Scenario

ISSN 2567-6458, 26.July – 11.August 2020
Email: info@uffmm.org
Author: Gerd Doeben-Henisch
Email: gerd@doeben-henisch.de

CONTEXT

As described in the uffmm eJournal  the wider context of this software project is a generative theory of cultural anthropology [GCA] which is an extension of the engineering theory called Distributed Actor-Actor Interaction [DAAI]. In  the section Case Studies of the uffmm eJournal there is also a section about Python co-learning – mainly
dealing with python programming – and a section about a web-server with
Dragon. This document will be part of the Case Studies section.

PDF TEXT:

requirements-no1-v3-11Aug2020 (published: Aug-11, 2020; this version replaces the version from 7.August 2020)

requirements-no1-v2-2-7Aug2020 (published: Aug-7, 2020; this version replaces the version from 6.August 2020)

requirements-no1-v2-6Aug2020 (published: Aug-6, 2020; this version replaces the version from 25.July 2020)

requirements-no1-25july2020-v1-pub (published: July-26, 2020)