Category Archives: oksimo reloaded software

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.