Graph-IT Wiki - Benutzerbeiträge [de]

Lxdhost-Server

2019-03-17T08:40:43Z

Hschlabach:

Ziel dieser Anleitung ist eines ausfallsicheren LXDHost. Die Anleitung basiert auf der Anleitung [[Server-Basissystem]]. Das System hat zwei zusätzliche Festplatten auf denen die LXD-Container abgelegt werden. Die Festplatten sind mit LVM zu einer Volume-Group zusammengefasst. In dieser wird ein Logical-Volume vom Typ <code>raid1</code> angelegt. Als Dateisystem wird wieder BTRFS eingesetzt. Das Netzwerk wird so konfiguriert, das die LXD-Container direkten Zugriff auf das Netz haben und von dort per DHCP mit IP-Adressen versorgt werden können. Dazu wird das in der vorhergehenden Anleitung konfigurierte Interface <code>eno1</code> durch die Bridge <code>lxdbr0</code> ersetzt.

==Voraussetzungen==
Funktionsfähiges [[Server-Basissystem]]

Die Dateien lxdh-setup und lxdh-config-example aus den git-Repository [[https://github.com/heiko-schlabach/Server-Basissystem]]

==Installation==
Der Server wird gebootet und der Benutzer <code>root</code> meldet sich am System an. Nun werden die Skripte aus dem Git-Repository abgerufen.
apt install git
git clone https://github.com/heiko-schlabach/Server-Basissystem
cd Server-Basissystem

Zunächst muss eine Konfigurationsdatei für das Skript <code>lxdh-setup</code> angelegt werden:

cp lxdh-config-example lxdh-config
nano lxdh-config

Nun kann das Skript lxdh-setup aufgerufen werden:

./lxdh-setup lxdh-config

Während der Abarbeitung wird der Benutzer nach dem Passwort für den LXD-Deamon gefragt. Anschliessend kann das System neu gestartet werden.

Graphmodul li - LightPi

2019-03-15T09:24:00Z

Hschlabach: Die Seite wurde neu angelegt: „Das Graphmodul li - LightPi bildet alles rund um den LightPi im Graphen ab. Mit dem LightPi können Gebäudeautomatisierungen durchgeführt werden.“

Das Graphmodul li - LightPi bildet alles rund um den LightPi im Graphen ab. Mit dem LightPi können Gebäudeautomatisierungen durchgeführt werden.

Hauptseite

2019-03-15T09:22:22Z

Hschlabach: /* Graphmodule */

==Allgemein==
In diesem Wiki werden Werkzeuge beschrieben, die von Graph-IT zu Verfügung gestellt werden, um eine durchgängige Digitalisierung zu erreichen.

==Graph==

[[Graph | Der Graph]]

[[Graphmodul]]

===Graphmodule===

[[Graphmodul pr - Prozesse | pr - Prozesse]]

[[Graphmodul li - LightPi | li - LightPi]]

==technische Infrastruktur==

[[Server-Basissystem]]

[[Lxdhost-Server]]

Lxdhost-Server

2019-03-14T06:19:24Z

Hschlabach: /* Voraussetzungen */

Server-Basissystem

2019-03-14T06:17:36Z

Hschlabach: /* Voraussetzungen */

==Allgemein==
Das Ziel dieser Anleitung ist ein Ubuntu-Minimal-System mit folgenden Eigenschaften: Das System hat zwei System-Festplatten. Fällt eine der beiden Festplatten aus, so funktioniert das System trotzdem ohne Beeinträchtigung weiter. Dies umfasst auch den Neustart. Ein Hot-Swap der Festplatten ist ebenfalls möglich.

Ich habe keine Möglichkeit gefunden unter Ubuntu zwei EFI-Partionen synchron zu halten. Aus diesem Grund muss das System mit BIOS oder UEFI-Legacy gebootet werden.

Als Partitionstabelle habe ich GPT gewählt. Für die zweite Stufe von GRUB braucht man dann eine zusätzliche kleine Partition vom Typ "BIOS boot". Diese muss auf beiden Festplatten angelegt werden. Es wird eine Größe von 1MB empfohlen. Ein Dateisystem darf in dieser Partition nicht angelegt werden. Die Partion wird unter Ubuntu bei Installation und Update des Bootloaders automatisch aktualisiert und synchron gehalten.

Die zweite Partition umfasst jeweils den Rest der Festplatte. Sie sollte den Typ "Linux LVM" haben. Die beiden großen Partition werden in einer LVM-Volume-Group zusammengefasst. In der Volume-Group wird dann ein Logical-Volume vom Typ raid1 angelegt. Das Logical-Volume muss nicht sehr groß sein, da nur ein Minimal-System installiert werden soll. Sollte der Platz knapp werden, so kann man das Logical-Volume und das enthaltene Dateisystem bis zu der Größe der kleineren Festplatte erweitern

Als Dateisystem für das Logical-Volume wird BTRFS verwendet. Dies gestattet es, vor umfangreicheren Änderungen am Betriebsystem, Snapshots anzulegen.

Das System wird nicht von einem Installationsmedium sondern mit debootstrap installiert. Deshalb kann zur Installation irgendein System verwendet werden, das mit den notwendigen Tools ausgestattet ist. Ich habe den Rechner mit dem Live-System von einem "Ubuntu Desktop 18.04"-Stick gebootet. So kann man einerseits beim Systemstart das Tastaturlayout wählen und andererseite diese Anleitung in einem Browser öffnen.

==Voraussetzungen==

[[Server]] mit 2 Systemfestplatten SSD im Wechselrahmen

USB Stick mit Ubuntu 18.04 Desktop zum Installieren

Netzwerk mit DHCP und Internetverbindung

Die Dateien basy-bootstrap, basy-setup und basy-config.example aus dem GitHub Repository [[https://github.com/heiko-schlabach/Server-Basissystem]]

==Installation==

Graphmodul

2019-03-14T06:02:58Z

Hschlabach: Die Seite wurde neu angelegt: „Ein Graphmodul ist die Sammlung von Knoten, Verknüpfungen, Datenfunktionen und Aktionfunktionen, die logisch zusammen gehören. Graphmodule werden durch den K…“

Ein Graphmodul ist die Sammlung von Knoten, Verknüpfungen, Datenfunktionen und Aktionfunktionen, die logisch zusammen gehören. Graphmodule werden durch den Knoten graphmodul im Graphen definiert.

Ein Graphmodul hat ein Attribut "prefix", welches aus zwei Zeichen besteht. Jeder Knoten, der zu diesem Graphmodul gehört, muss mit diesen zwei Zeichen beginnen.

Ein Graphmodul hat ein Attribut "name", welches den Namen des Graphmoduls in menschenlesbarer Form enthält. Aus dem Namen sollte das Prefix abgeleitet werden, indem die ersten beiden Buchstaben des Namens verwendet werden. Beispiel: Das Graphmodul Finanzwesen hätte das Prefix "fi"

Ist das Prefix schon vergeben, dann wird der erste Buchstabe genommen, im Beispiel für "Finanzwesen" das f und der erste freie Buchstabe des Alphabets, für den gilt, dass das Prefix noch frei ist. Also z.B. fa, ist fa schon belegt, dann wird fb genommen. Ist fz belegt, wird ga benutzt.

Es sind nur die Buchstaben a-z erlaubt, keine Umlaute und nur Kleinbuchstaben.

Graphmodule können lokal sein, das bedeutet, dass sie nur im lokalen Graphen existieren. Diese Graphmodule im Prefix an der zweiten Stelle eine Ziffer, also z.B. f0.

Die Buchstaben x und y sind an der ersten Stelle des Prefix reserviert, damit der Namespace später dort möglicherweise erweitert werden kann.

Hauptseite

2019-03-14T05:53:00Z

Hschlabach: /* Graph */

==Allgemein==
In diesem Wiki werden Werkzeuge beschrieben, die von Graph-IT zu Verfügung gestellt werden, um eine durchgängige Digitalisierung zu erreichen.

==Graph==

[[Graph | Der Graph]]

[[Graphmodul]]

===Graphmodule===

[[Graphmodul pr - Prozesse | pr - Prozesse]]

==technische Infrastruktur==

[[Server-Basissystem]]

[[Lxdhost-Server]]

Server

2019-03-14T05:51:12Z

Hschlabach: Die Seite wurde neu angelegt: „Ein Server ist ein PC-System, auf dem ein Virtualisierungsdienst läuft. ==Anforderungen== Server bilden einen wichtigen Baustein für die gesamte digitale In…“

Ein Server ist ein PC-System, auf dem ein Virtualisierungsdienst läuft.

==Anforderungen==
Server bilden einen wichtigen Baustein für die gesamte digitale Infrastruktur. Server sollen grundsätzlich gewisse Anforderungen erfüllen:

*19" Gehäuse, damit sie in Serverschränke eingebaut werden können
*2.5" Wechselrahmen für alle Festplatten
*ausschließlicher Einsatz von SSDs
*möglichst viele CPU-Kerne
*möglichst viel Hauptspeicher
*Desktop PC oder Gaming PC Hardware für Mainboard ist o.k.
*2x kleine SSD, welche dann im Software Raid1 als Bootmedium benutzt werden, siehe [[Server-Basissystem]]
*mindestens 1 Paar SSD möglichst groß für die Daten/virtuellen Systeme

Server-Basissystem

2019-03-14T05:42:15Z

Hschlabach:

Server-Basissystem

2019-03-14T05:37:55Z

Hschlabach: /* Voraussetzungen */

==Allgemein==
Das Ziel dieser Anleitung ist ein Ubuntu-Minimal-System mit folgenden Eigenschaften: Das System hat zwei System-Festplatten. Fällt eine der beiden Festplatten aus, so funktioniert das System trotzdem ohne Beeinträchtigung weiter. Dies umfasst auch den Neustart. Ein Hot-Swap der Festplatten ist ebenfalls möglich.

Ich habe keine Möglichkeit gefunden unter Ubuntu zwei EFI-Partionen synchron zu halten. Aus diesem Grund muss das System mit BIOS oder UEFI-Legacy gebootet werden.

Als Partitionstabelle habe ich GPT gewählt. Für die zweite Stufe von GRUB braucht man dann eine zusätzliche kleine Partition vom Typ "BIOS boot". Diese muss auf beiden Festplatten angelegt werden. Es wird eine Größe von 1MB empfohlen. Ein Dateisystem darf in dieser Partition nicht angelegt werden. Die Partion wird unter Ubuntu bei Installation und Update des Bootloaders automatisch aktualisiert und synchron gehalten.

Die zweite Partition umfasst jeweils den Rest der Festplatte. Sie sollte den Typ "Linux LVM" haben. Die beiden großen Partition werden in einer LVM-Volume-Group zusammengefasst. In der Volume-Group wird dann ein Logical-Volume vom Typ raid1 angelegt. Das Logical-Volume muss nicht sehr groß sein, da nur ein Minimal-System installiert werden soll. Sollte der Platz knapp werden, so kann man das Logical-Volume und das enthaltene Dateisystem bis zu der Größe der kleineren Festplatte erweitern

Als Dateisystem für das Logical-Volume wird BTRFS verwendet. Dies gestattet es, vor umfangreicheren Änderungen am Betriebsystem, Snapshots anzulegen.

Das System wird nicht von einem Installationsmedium sondern mit debootstrap installiert. Deshalb kann zur Installation irgendein System verwendet werden, das mit den notwendigen Tools ausgestattet ist. Ich habe den Rechner mit dem Live-System von einem "Ubuntu Desktop 18.04"-Stick gebootet. So kann man einerseits beim Systemstart das Tastaturlayout wählen und andererseite diese Anleitung in einem Browser öffnen.

==Voraussetzungen==

Server mit 2 Systemfestplatten SSD im Wechselrahmen

USB Stick mit Ubuntu 18.04 Desktop zum Installieren

Netzwerk mit DHCP und Internetverbindung

==Installation==

Lxdhost-Server

2019-03-13T13:12:09Z

Hschlabach:

Lxdhost-Server

2019-03-13T13:07:25Z

Hschlabach: Leere Seite erstellt

Hauptseite

2019-03-13T13:07:10Z

Hschlabach:

==Allgemein==
In diesem Wiki werden Werkzeuge beschrieben, die von Graph-IT zu Verfügung gestellt werden, um eine durchgängige Digitalisierung zu erreichen.

==Graph==

[[Graph | Der Graph]]

===Graphmodule===

[[Graphmodul pr - Prozesse | pr - Prozesse]]

==technische Infrastruktur==

[[Server-Basissystem]]

[[Lxdhost-Server]]

Server-Basissystem

2019-03-13T10:27:29Z

Hschlabach: Die Seite wurde neu angelegt: „==Allgemein== Das Ziel dieser Anleitung ist ein Ubuntu-Minimal-System mit folgenden Eigenschaften: Das System hat zwei System-Festplatten. Fällt eine der beid…“

==Allgemein==
Das Ziel dieser Anleitung ist ein Ubuntu-Minimal-System mit folgenden Eigenschaften: Das System hat zwei System-Festplatten. Fällt eine der beiden Festplatten aus, so funktioniert das System trotzdem ohne Beeinträchtigung weiter. Dies umfasst auch den Neustart. Ein Hot-Swap der Festplatten ist ebenfalls möglich.

Ich habe keine Möglichkeit gefunden unter Ubuntu zwei EFI-Partionen synchron zu halten. Aus diesem Grund muss das System mit BIOS oder UEFI-Legacy gebootet werden.

Als Partitionstabelle habe ich GPT gewählt. Für die zweite Stufe von GRUB braucht man dann eine zusätzliche kleine Partition vom Typ "BIOS boot". Diese muss auf beiden Festplatten angelegt werden. Es wird eine Größe von 1MB empfohlen. Ein Dateisystem darf in dieser Partition nicht angelegt werden. Die Partion wird unter Ubuntu bei Installation und Update des Bootloaders automatisch aktualisiert und synchron gehalten.

Die zweite Partition umfasst jeweils den Rest der Festplatte. Sie sollte den Typ "Linux LVM" haben. Die beiden großen Partition werden in einer LVM-Volume-Group zusammengefasst. In der Volume-Group wird dann ein Logical-Volume vom Typ raid1 angelegt. Das Logical-Volume muss nicht sehr groß sein, da nur ein Minimal-System installiert werden soll. Sollte der Platz knapp werden, so kann man das Logical-Volume und das enthaltene Dateisystem bis zu der Größe der kleineren Festplatte erweitern

Als Dateisystem für das Logical-Volume wird BTRFS verwendet. Dies gestattet es, vor umfangreicheren Änderungen am Betriebsystem, Snapshots anzulegen.

Das System wird nicht von einem Installationsmedium sondern mit debootstrap installiert. Deshalb kann zur Installation irgendein System verwendet werden, das mit den notwendigen Tools ausgestattet ist. Ich habe den Rechner mit dem Live-System von einem "Ubuntu Desktop 18.04"-Stick gebootet. So kann man einerseits beim Systemstart das Tastaturlayout wählen und andererseite diese Anleitung in einem Browser öffnen.

==Voraussetzungen==

Server mit 2 Systemfestplatten SSD im Wechselrahmen
USB Stick mit Ubuntu 18.04 Desktop zum Installieren
Netzwerk mit DHCP und Internetverbindung

==Installation==

Hauptseite

2019-03-13T09:37:54Z

Hschlabach:

==Allgemein==
In diesem Wiki werden Werkzeuge beschrieben, die von Graph-IT zu Verfügung gestellt werden, um eine durchgängige Digitalisierung zu erreichen.

==Graph==

[[Graph | Der Graph]]

===Graphmodule===

[[Graphmodul pr - Prozesse | pr - Prozesse]]

==technische Infrastruktur==

[[Server-Basissystem]]

Prozessknoten implementieren

2019-03-10T12:57:36Z

Hschlabach: /* Aktionfunktion prvalidieren */

==Allgemein==

Nachdem ein Prozessknoten und sein erstes Formular durch die Aktionfunktionen prtask_aktualisiereknoten und prtask_generiereformular erzeugt wurde, muss er implementiert werden. Dafür sind bestimmte Regeln einzuhalten. Im folgenden wird außerdem der allgemeine Aufbau eines Prozessknotens beschrieben.

==Struktur eines Prozessknotens==
Ein Prozessknoten dokumentiert den Lebenszyklus einer Aufgabe. Mit erfolgreicher Beendigung der Aufgabe wird in der Regel das funktionale Modell aktualisiert. Grundsätzlich gibt es folgende Phasen:

*Aufgabe beginnen
*Aufgabe ausführen
*Aufgabe beenden

Während der Ausführung der Aufgabe kann diese beliebig oft pausiert und angehalten werden. Das wird benutzt, damit die effektive Arbeitszeit für die Bearbeitung einer Aufgabe berechnet werden kann, welche von der Gesamtzeit von Beginn bis Ende der Aufgabe stark abweichen kann.

==Aufgabe beginnen==
Für das Beginnen der Aufgabe müssen nur die richtigen Voraussetzungen vorhanden sein; der Benutzer muss in der Lage sein, die Aufgabe auszuführen. Dies ist der Fall, wenn der Benutzer mit der zugehörigen prTask Instanz verknüpft ist. Die Auto Oberfläche übersetzt automatisch den Autobenutzer zur zugehörigen prPerson Instanz.

Der Task beginnt durch das Ausführen der Aktionfunktion aubeginnen am Prozessknoten.

==Aufgabe ausführen==
Dies ist der Variable Teil des Prozessknotens.

===Beispiel: Ändern von Attributen===
Ein typisches Beispiel wäre das Ändern von Attributen an einem Knoten. Das folgende Beispiel gilt für eine Implementierung vom Prozessknoten ge00001 - "geObjekt Ausdehnung ändern".

Der Knoten geObjekt beschreibt ein 3D-Objekt im Graphmodul ge, welches ein Modell eines Gebäudes darstellt. Jedes Objekt hat die Attribute breite, laenge und hoehe. Mit dem Prozessknoten sollen diese Attribute geändert werden können. Außerdem ist gewünscht, dass die alten Werte im Prozessknoten archiviert werden.

Als erstes wird der Knotenknoten ge00001_geobjekt (1n) angelegt. Danach werden an ge00001 die Attribute breitealt, laengealt, hoehealt sowie breite, laenge und hoehe angelegt. Außerdem wird ein Alias mit dem Namen ge00001_geobjekt auf geobjekt_name angelegt.

Nun wird eine Aktionfunktion ge00001_geobjekt geschrieben, welche durch ge00001_geobjekt und ge00001_prstatus getriggert wird:

$ge00001_prstatus=attribut($node_guid,'ge00001_prstatus');
if($ge00001_prstatus != 'begonnen'){
return 1;
}

$geobjekt_guid=knoten($node_guid,'geobjekt');
$geobjekt=attribute($geobjekt_guid,'geobjekt','breite, laenge, hoehe');
setze($node_guid,'ge00001_breitealt',$geobjekt['breite']);
setze($node_guid,'ge00001_breite',$geobjekt['breite']);
setze($node_guid,'ge00001_laengealt',$geobjekt['laenge']);
setze($node_guid,'ge00001_laenge',$geobjekt['laenge']);
setze($node_guid,'ge00001_hoehealt',$geobjekt['hoehe']);
setze($node_guid,'ge00001_hoehe',$geobjekt['hoehe']);
return 1;

Wie man sehen kann, wird diese Aktionfunktion nur ausgeführt, wenn der Status des Prozessknotens "begonnen" ist. Wenn die Aufgabe noch nicht begonnen oder schon beendet ist, wird die Aktionfunktion nicht ausgeführt. Danach werden die Attribute breite, laenge und hoehe in die 6 Attribute geschrieben.

Nun kann der Benutzer die Werte der Attribute breite, laenge und hoehe ändern. Die anderen drei (breitealt, laengealt und hoehealt) sollen nicht geändert werden, da sie so archiviert werden. Das Formular zu dem Prozessknoten soll so geändert werden, dass nach prPerson die 1-Link Komponente zu geObjekt angezeigt wird, welche schreibgeschützt ist, wenn nicht gilt, dass das Attribut aubeendbar gesetzt ist. Danach kommen 3 Label für breitealt, laengealt und hoehealt. breite, laenge und hoehe werden in einer Komponente "Textfeld" dargestellt werden, welche schreibgeschützt sind, wenn nicht gilt, dass das Attribut aubeendbar gesetzt ist.

Damit ist das Ausführen vollständig implementiert.

==Aufgabe beenden==
Das Beenden der Aufgabe wird durch die Aktionfunktion aubeenden durchgeführt. Diese prüft einige Dinge ab und ruft, wenn die Voraussetzungen erfüllt sind die Aktionfunktion prbeenden auf. Diese wiederum prüft einige Dinge und ruft zuerst die Aktionfunktion validieren auf und danach die Aktionfunktion projizieren.

===Aktionfunktion prvalidieren===
Die Aktionfunktion prvalidieren soll prüfen, ob die gemachten Eingaben gültig sind, z.B. ob Werte regelkonform angegeben wurden. Ist dies nicht der Fall, wird eine Fehlermeldung in das Attribut prfehler geschrieben. Das Validieren darf nur stattfinden, wenn das Attribut prstatus nicht auf "beendet" steht. Das bedeutet, dass zum Beginn folgender Code stehen sollte (am Beispiel ge00001):
$ge00001_prstatus=attribut($node_guid,'ge00001_prstatus');
if($ge00001_prstatus == 'beendet'){
return 1;
}
$fehler = [];

In der Folge wird ein individueller Code erzeugt, der die gemachten Eingaben prüft, z.B. für ge00001:

if(!$ge00001['breite']){
$fehler[]="Breite ist nicht festgelegt";
}
if (!$ge00001['laenge']){
$fehler[]="Länge ist nicht festgelegt";
}
if (!$ge00001['hoehe']){
$fehler[]="Höhe ist nicht festgelegt";
}

Am Ende der Aktionfunktion werden dann möglichen Fehlermeldungen in das Attribut prfehler geschrieben, hier wieder für ge00001:

setze($node_guid,'ge00001_prfehler',implode("\n",$fehler));
return 1;

In der Folge kann die Aktionfunktion prüfen, ob beim validieren Fehler aufgetreten sind.

===Aktionfunktion prprojizieren===
Sind beim Validieren keine Fehler aufgetreten, werden die Änderungen am funktionalen Modell durchgeführt. Wie bei der Aktionfunktion prvalidieren, wird als erstes geprüft, ob die Aktion grundsätzlich ausgeführt werden darf (wieder am Beispiel ge00001):

$ge00001_prstatus=attribut($node_guid,'ge00001_prstatus');
if($ge00001_prstatus != 'beendet'){
return 1;
}

$geobjekt_guid=knoten($node_guid,'geobjekt');
if(!$geobjekt_guid){
return 1;
}

Der erste Teil ist bei jedem Prozessknoten notwendig, der zweite prüft, ob der Zielknoten verknüpft ist, der verändert werden soll.

Sind die Voraussetzungen erfüllt, werden die Änderungen in das funktionale Modell geschrieben und die Aktionfunktion beendet:

$ge00001=attribute($node_guid,'ge00001','breite, laenge, hoehe');
setze($geobjekt_guid,'geobjekt_breite',$ge00001['breite']);
setze($geobjekt_guid,'geobjekt_laenge',$ge00001['laenge']);
setze($geobjekt_guid,'geobjekt_hoehe',$ge00001['hoehe']);

Wurde die Aktionfunktion prprojizieren aufgerufen, ist die Aufgabe abgeschlossen.

Prozessknoten implementieren

2019-03-10T11:34:50Z

Hschlabach:

Prozessknoten implementieren

2019-03-10T11:32:11Z

Hschlabach:

Prozessknoten implementieren

2019-03-10T10:36:31Z

Hschlabach: Die Seite wurde neu angelegt: „Dieser Beitrag ist nicht freigegeben.“

Dieser Beitrag ist nicht freigegeben.

Knoten prtask

2019-03-10T10:35:56Z

Hschlabach:

==Allgemein==
Der Knoten prTask dient dazu Aufgabentypen zu definieren. Ein prTask gehört immer zu einem bestimmten Graphmodul und kann so zwischen Graphen über den Aktualisierungsprozess ausgetauscht werden. Der Name des prTasks wird aus dem Präfix des Graphmoduls und einer pro Graphmodul vorlaufenden Nummer erzeugt. Der prTask hat darüber hinaus eine Menschen lesbare Bezeichnung. Diese ist als kurze Überschrift zu dem Task zu verstehen. Sie wird von den Templates verwendet um Formular und Grid Beschriftungen zu generieren. Ein prTask hat eine oder mehrere prTaskversionen. Der Knoten prTaskversion enthält das Attribut Beschreibung in welchem die einzelnen Arbeitsschritte der Aufgabe in von Menschen lesbarer Form gespeichert werden. Dies ist die eigentliche Definition des Aufgabe. Ein prTask gilt als aktiv, wenn genau eine verknüpfte prTaskversion aktiv ist. Dies bedeutet das neue Aufgaben nach dieser Definition abgearbeitet werden sollen. Die prTaskversionen zu einem prTask sollten sich nicht allzu sehr unterscheiden. Weicht eine gewünschte Aufgabendefinition sehr von der bestehenden ab, so sollte besser eine neue prTask-Instanz angelegt werden.

Nach dem Anlegen einer prTask-Instanz folgt die [[Prozessknoten implementieren | Implementierung]] den durch die Instanz erzeugten Knotens. Der Knoten ist Bestandteil des Prozessteils des Graphen und nicht des funktionalen Modells.

Knoten prtask

2019-03-10T10:29:27Z

Hschlabach: Die Seite wurde neu angelegt: „Dieser Beitrag ist nicht freigegeben“

Dieser Beitrag ist nicht freigegeben

Graphmodul pr - Prozesse

2019-03-10T10:28:54Z

Hschlabach: /* Der Knoten prTask(version) */

==Allgemein==

Das Graphmodul pr - prozesse stellt Knoten zur Verfügung um Aufgabentypen zu definieren und zu versionieren, und den Kreis der Personen festzulegen die Aufgaben dieses Typs ausführen dürfen. Es stellt Templates bereit mit denen zu Aufgabentypen erweiterbare Knoten und Formulare generiert werden können. Es bietet außerdem die Möglichkeit allgemeine Ereignisse die während der Abarbeitung einer Aufgaben auftreten zu protokollieren und aus diesem Protokoll Laufzeiten zu berechnen.

==Die Aufgabe==

Eine Aufgabe ist eine Tätigkeit die von einer Person in einem Zug ohne Unterbrechung durchgeführt wird. Die Aufgabe hat einen bestimmten Typ der von einem bestimmten Personenkreis ausgeführt werden darf. Sie wird zu einem Zeitpunkt A begonnen und zu einem späteren Zeitpunkt B beendet.

==Der Knoten prTask(version)==

Der Knoten [[Knoten prtask | prTask]] dient dazu Aufgabentypen zu definieren. Ein prTask gehört immer zu einem bestimmten Graphmodul und kann so zwischen Graphen über den Aktualisierungsprozess ausgetauscht werden. Der Name des prTasks wird aus dem Präfix des Graphmoduls und einer pro Graphmodul vorlaufenden Nummer erzeugt. Der prTask hat darüber hinaus eine Menschen lesbare Bezeichnung. Diese ist als kurze Überschrift zu dem Task zu verstehen. Sie wird von den Templates verwendet um Formular und Grid Beschriftungen zu generieren. Ein prTask hat eine oder mehrere prTaskversionen. Der Knoten prTaskversion enthält das Attribut Beschreibung in welchem die einzelnen Arbeitsschritte der Aufgabe in von Menschen lesbarer Form gespeichert werden. Dies ist die eigentliche Definition des Aufgabe. Ein prTask gilt als aktiv, wenn genau eine verknüpfte prTaskversion aktiv ist. Dies bedeutet das neue Aufgaben nach dieser Definition abgearbeitet werden sollen. Die prTaskversionen zu einem prTask sollten sich nicht allzu sehr unterscheiden. Weicht eine gewünschte Aufgabendefinition sehr von der bestehenden ab, so sollte besser eine neue prTask-Instanz angelegt werden.

==Der Knoten prPerson==

Im Knoten prPerson werden Personen definiert die Aufgaben eines bestimmten Typs ausführen dürfen. Die prPerson hat nur einen Namen und Verknüpfungen zu den prTask-Instanzen die diese Person durchführen darf. Die prPerson kann darüber hinaus mit einem Autobenutzer verknüpft werden. Diese Verknüpfung wird von den durch Templates generierten Knoten, Formularen und Aktionen dazu verwendet die prPerson-Instanz des Autobenutzer automatisch mit der bearbeiteten Aufgabe-Instanz zu verknüpfen.

==Die Aufgabe-Knoten==

Die Aktionfunktion prtask_aktualisiereknoten aktualisiert zu dem prTask gehörenden Aufgabe-Knoten. Der Name des prTask wird dabei als Knotentyp verwendet. Die Instanzen des generierten Knoten stellen dann Aufgaben des durch die prTask-Instanz definierten Aufgabentyps dar. Die generierten Aufgabe-Knoten haben zunächst folgende Attribute und Aktionen:

Die datetime Attribute ‚angelegtam‘, ‚begonnenam‘, ‚pausiertam‘, ‚fortgesetztam‘ und ‚beendetam‘

Das string Attribut ‚prstatus‘, welches die Werte ‚angelegt‘, ‚begonnen‘, ‚pausiert‘ und ‚beendet‘ annehmen kann

Das string Attribut ‚prperson‘, welches die prPerson-Instanz refenreziert, welche die Aufgabe durchgeführt hat

Das text Attribut ‚prfehler‘, in welchem Fehler ausgegeben werde können

Das string Attribut ‚pruuid‘, in welchem eine eindeutige ID für die Aufgabe abgelegt wird

Das string Attribut ‚name‘ ist ein Alias von ‚prangelegtam‘ solange das Attribut ‚pruuid‘ nicht gesetzt ist. Danach ist es ein Alias von ‚pruuid‘.

Die lifecycle-Aktion ‚pranlegen‘, welche durch das Attribut ‚name‘ getriggert wird. Die Aktion prüft zunächst, ob das Attribut ‚prstatus‘ leer ist. Ist dies nicht der Fall so bricht die Aktion ab. Die Attribute ‚prangelegtam‘ und ‚pruuid‘ werden initialisiert und das Attribut ‚prstatus‘ auf ‚angelegt‘ gesetzt.

Die lifecycle-Aktion ‚prbeginnen‘. Sie bricht ab wenn das Attribut ‚prStatus‘ nicht den Wert ‚angelegt‘ hat. Sie überprüft dann ob die durch das Attribut ‚prperson‘ referenzierte ‚prperson‘-Instanz die Aufgabe ausführen darf. Wenn ja dann wird das Attribut ‚prbegonnenam‘ gesetzt und das Attribut ‚prstatus‘ auf den Wert ‚begonnen‘ aktualisiert.

Die lifecycle-Aktion ‚prpausieren‘ bricht ab wenn das Attribut ‚prstatus‘ nicht den Wert ‚begonnen‘ hat. Sonst wird das Attribut ‚prpausiertam‘ gesetzt und das Attribut ‚prstatus‘ auf den Wert ‚pausiert‘ aktualisiert.

Die lifecycle-Aktion ‚prfortsetzen‘ bricht ab wenn das Attribut ‚prstatus‘ nicht den Wert ‚pausiert‘ hat. Sonst wird das Attribut ‚prfortgesetztam‘ gesetzt und das Attribut ‚prstatus‘ auf den Wert ‚begonnen‘ aktualisiert.

Die lifecycle-Aktion ‚prbeenden‘ bricht ab wenn das Attribut ‚prstatus‘ nicht den Wert ‚begonnen‘ hat. Sonst wird das Attribut ‚prbeendetam‘ gesetzt und das Attribut ‚prstatus‘ auf den Wert ‚beendet‘ aktualisiert.

Die Aktion ‚prvalidieren‘, welche durch die Aktion ‚prbeenden‘ getriggert wird. Ihre Aufgabe ist es zu prüfen ob die Werte in der Instanz gültig sind. Sind sie es nicht so muss sie das Attribut ‚prfehler‘ befüllen. Die Aktion darf nur lesend auf den Graphen zugreifen und darf bis auf das Setzen des Attributes ‚prfehler‘ keine Seiteneffekte haben.

Die Aktion ‚prprojizieren‘, welche durch die Aktion ‚prbeenden‘ getriggert wird. Ihre Aufgabe ist es die Werte in der Instanz auf den restlichen Graphen abzubilden. Sie darf aber keine Werte in der Instanz selbst ändern.

Die Aktion ‚prloeschen‘, welche durch die Aktion ‚loeschen‘ getriggert wird. Ihre Aufgabe ist es abhängige Instanzen der Aufgabe zu löschen.

Die lifecycle-Aktionen und die Aktion ‚loeschen‘ erzeugen darüber hinaus jeweils eine ‚prereignis‘-Instanz, in welcher der Statuswechsel dokumentiert wird. Der Programmierer ergänzt und verwendet den Aufgabe-Knoten. Dies geschieht zunächst in den Aktionen ‚prvalidieren‘, ‚prprojizieren‘ und ‚prloeschen‘. Diese sind zunächst ungültig, da sie keinen Programmcode enthalten. Darüber hinaus können zusätzliche Attribute, Aktionen, Verknüpfungen und Hilfsknoten angelegt werden.

Die zusätzlichen Aktionen an dem Aufgabe-Knoten zerfallen in die zwei Kategorien ‚Vorbereiten‘ und ‚Projizieren‘

Die Aktionen der Kategorie ‚Vorbereiten‘ dürfen nur auf Instanzen arbeiten die nicht im Status ‚beendet‘ sind. Sie dürfen Verknüpfungen zu benachbarten Knoten herstellen und Daten aus dem Rest des Graphen in die Instanz kopieren. Sie dürfen an der Instanz Aktionen der Kategorie ‚Vorbereiten‘ ausführen. Sie dürfen keine anderen Änderungen am Graphen vornehmen. Konzeptionell gehört die Aktion ‚prvalidieren‘ in diese Kategorie.

Die Aktionen der Kategorie ‚Projizieren‘ dürfen nur auf Instanzen arbeiten die im Status ‚beendet‘ sind. Sie dürfen Verknüpfungen zu benachbarten Knoten herstellen, aber keine weiteren Änderungen an der Instanz durchführen. Sie dürfen an der Instanz Aktionen der Kategorie ‚Projizieren‘ ausführen. Die Aktionen der Kategorie ‚Projizieren‘ dürfen nur ein mal pro Instanz aufgerufen werden. Konzeptionell gehört die Aktion ‚prprojizieren‘ in diese Kategorie.

Für zusätzliche Datenfunktionen an dem Aufgabe-Knoten gilt, dass sie von den benachbarten Knoten nur das Primärattribut auslesen dürfen. Werden an dem Aufgabe-Knoten weitere Daten aus den benachbarten Knoten benötigt so müssen diese durch Aktionen aus der Kategorie ‚Vorbereiten‘ kopiert werden.

Aufgabe-Knoten dürfen nur in Aktionen und Datenfunktionen anderer Aufgabe-Knoten referenziert werden. Eine Instanz im Status ‚beendet‘ darf nicht verändert werden.

Hilfsknoten haben eine ‚zu 1‘-Verknüpfung zu ihren Aufgabe-Knoten. Sie sind konzeptionell identisch mit dem Aufgabe-Knoten und unterliegen damit gleichen Einschränkungen. Ihre Typ hat als Präfix den Typ des Aufgabe-Knoten.

==Das Aufgabe-Fomular==

Die Aktionfunktion prtask_generiereformular generiert zu dem prTask ein Formular in der Auto-Oberfläche. Dieses kann als Ausgangspunkt für das Aufgabe-Fomular dienen. Es hat bereits Schaltflächen für die lifecycle-Aktionen ‚beginnen‘, ‚pausieren‘, ‚fortsetzen‘ und ‚beenden‘. Die Schaltfläche ‚beginnen‘ ruft die neue Aktion ‚aubeginnen‘ auf, welche versucht zu dem aktuellen Autobenutzer ein prPerson-Instanz zu ermitteln, deren Name in das Attribut ‚prperson‘ setzt und die Aktion ‚prbeginnen‘ aufruft. Um die Schaltflächen korrekt zu deaktivieren werden auch noch die Attribute ‚aubeginbar‘, ‚aupausierbar‘, ‚aufortsetzbar‘ und ‚aubeendbar‘ angelegt.

==Die Knoten prAufgabe und prEreignis==

Graphmodul pr - Prozesse

2019-03-10T07:38:02Z

Hschlabach: Die Seite wurde neu angelegt: „==Allgemein== Das Graphmodul pr - prozesse stellt Knoten zur Verfügung um Aufgabentypen zu definieren und zu versionieren, und den Kreis der Personen festzul…“

==Allgemein==

Das Graphmodul pr - prozesse stellt Knoten zur Verfügung um Aufgabentypen zu definieren und zu versionieren, und den Kreis der Personen festzulegen die Aufgaben dieses Typs ausführen dürfen. Es stellt Templates bereit mit denen zu Aufgabentypen erweiterbare Knoten und Formulare generiert werden können. Es bietet außerdem die Möglichkeit allgemeine Ereignisse die während der Abarbeitung einer Aufgaben auftreten zu protokollieren und aus diesem Protokoll Laufzeiten zu berechnen.

==Die Aufgabe==

Eine Aufgabe ist eine Tätigkeit die von einer Person in einem Zug ohne Unterbrechung durchgeführt wird. Die Aufgabe hat einen bestimmten Typ der von einem bestimmten Personenkreis ausgeführt werden darf. Sie wird zu einem Zeitpunkt A begonnen und zu einem späteren Zeitpunkt B beendet.

==Der Knoten prTask(version)==

Der Knoten prTask dient dazu Aufgabentypen zu definieren. Ein prTask gehört immer zu einem bestimmten Graphmodul und kann so zwischen Graphen über den Aktualisierungsprozess ausgetauscht werden. Der Name des prTasks wird aus dem Präfix des Graphmoduls und einer pro Graphmodul vorlaufenden Nummer erzeugt. Der prTask hat darüber hinaus eine Menschen lesbare Bezeichnung. Diese ist als kurze Überschrift zu dem Task zu verstehen. Sie wird von den Templates verwendet um Formular und Grid Beschriftungen zu generieren. Ein prTask hat eine oder mehrere prTaskversionen. Der Knoten prTaskversion enthält das Attribut Beschreibung in welchem die einzelnen Arbeitsschritte der Aufgabe in von Menschen lesbarer Form gespeichert werden. Dies ist die eigentliche Definition des Aufgabe. Ein prTask gilt als aktiv, wenn genau eine verknüpfte prTaskversion aktiv ist. Dies bedeutet das neue Aufgaben nach dieser Definition abgearbeitet werden sollen. Die prTaskversionen zu einem prTask sollten sich nicht allzu sehr unterscheiden. Weicht eine gewünschte Aufgabendefinition sehr von der bestehenden ab, so sollte besser eine neue prTask-Instanz angelegt werden.

==Der Knoten prPerson==

Im Knoten prPerson werden Personen definiert die Aufgaben eines bestimmten Typs ausführen dürfen. Die prPerson hat nur einen Namen und Verknüpfungen zu den prTask-Instanzen die diese Person durchführen darf. Die prPerson kann darüber hinaus mit einem Autobenutzer verknüpft werden. Diese Verknüpfung wird von den durch Templates generierten Knoten, Formularen und Aktionen dazu verwendet die prPerson-Instanz des Autobenutzer automatisch mit der bearbeiteten Aufgabe-Instanz zu verknüpfen.

==Die Aufgabe-Knoten==

Die Aktionfunktion prtask_aktualisiereknoten aktualisiert zu dem prTask gehörenden Aufgabe-Knoten. Der Name des prTask wird dabei als Knotentyp verwendet. Die Instanzen des generierten Knoten stellen dann Aufgaben des durch die prTask-Instanz definierten Aufgabentyps dar. Die generierten Aufgabe-Knoten haben zunächst folgende Attribute und Aktionen:

Die datetime Attribute ‚angelegtam‘, ‚begonnenam‘, ‚pausiertam‘, ‚fortgesetztam‘ und ‚beendetam‘

Das string Attribut ‚prstatus‘, welches die Werte ‚angelegt‘, ‚begonnen‘, ‚pausiert‘ und ‚beendet‘ annehmen kann

Das string Attribut ‚prperson‘, welches die prPerson-Instanz refenreziert, welche die Aufgabe durchgeführt hat

Das text Attribut ‚prfehler‘, in welchem Fehler ausgegeben werde können

Das string Attribut ‚pruuid‘, in welchem eine eindeutige ID für die Aufgabe abgelegt wird

Das string Attribut ‚name‘ ist ein Alias von ‚prangelegtam‘ solange das Attribut ‚pruuid‘ nicht gesetzt ist. Danach ist es ein Alias von ‚pruuid‘.

Die lifecycle-Aktion ‚pranlegen‘, welche durch das Attribut ‚name‘ getriggert wird. Die Aktion prüft zunächst, ob das Attribut ‚prstatus‘ leer ist. Ist dies nicht der Fall so bricht die Aktion ab. Die Attribute ‚prangelegtam‘ und ‚pruuid‘ werden initialisiert und das Attribut ‚prstatus‘ auf ‚angelegt‘ gesetzt.

Die lifecycle-Aktion ‚prbeginnen‘. Sie bricht ab wenn das Attribut ‚prStatus‘ nicht den Wert ‚angelegt‘ hat. Sie überprüft dann ob die durch das Attribut ‚prperson‘ referenzierte ‚prperson‘-Instanz die Aufgabe ausführen darf. Wenn ja dann wird das Attribut ‚prbegonnenam‘ gesetzt und das Attribut ‚prstatus‘ auf den Wert ‚begonnen‘ aktualisiert.

Die lifecycle-Aktion ‚prpausieren‘ bricht ab wenn das Attribut ‚prstatus‘ nicht den Wert ‚begonnen‘ hat. Sonst wird das Attribut ‚prpausiertam‘ gesetzt und das Attribut ‚prstatus‘ auf den Wert ‚pausiert‘ aktualisiert.

Die lifecycle-Aktion ‚prfortsetzen‘ bricht ab wenn das Attribut ‚prstatus‘ nicht den Wert ‚pausiert‘ hat. Sonst wird das Attribut ‚prfortgesetztam‘ gesetzt und das Attribut ‚prstatus‘ auf den Wert ‚begonnen‘ aktualisiert.

Die lifecycle-Aktion ‚prbeenden‘ bricht ab wenn das Attribut ‚prstatus‘ nicht den Wert ‚begonnen‘ hat. Sonst wird das Attribut ‚prbeendetam‘ gesetzt und das Attribut ‚prstatus‘ auf den Wert ‚beendet‘ aktualisiert.

Die Aktion ‚prvalidieren‘, welche durch die Aktion ‚prbeenden‘ getriggert wird. Ihre Aufgabe ist es zu prüfen ob die Werte in der Instanz gültig sind. Sind sie es nicht so muss sie das Attribut ‚prfehler‘ befüllen. Die Aktion darf nur lesend auf den Graphen zugreifen und darf bis auf das Setzen des Attributes ‚prfehler‘ keine Seiteneffekte haben.

Die Aktion ‚prprojizieren‘, welche durch die Aktion ‚prbeenden‘ getriggert wird. Ihre Aufgabe ist es die Werte in der Instanz auf den restlichen Graphen abzubilden. Sie darf aber keine Werte in der Instanz selbst ändern.

Die Aktion ‚prloeschen‘, welche durch die Aktion ‚loeschen‘ getriggert wird. Ihre Aufgabe ist es abhängige Instanzen der Aufgabe zu löschen.

Die lifecycle-Aktionen und die Aktion ‚loeschen‘ erzeugen darüber hinaus jeweils eine ‚prereignis‘-Instanz, in welcher der Statuswechsel dokumentiert wird. Der Programmierer ergänzt und verwendet den Aufgabe-Knoten. Dies geschieht zunächst in den Aktionen ‚prvalidieren‘, ‚prprojizieren‘ und ‚prloeschen‘. Diese sind zunächst ungültig, da sie keinen Programmcode enthalten. Darüber hinaus können zusätzliche Attribute, Aktionen, Verknüpfungen und Hilfsknoten angelegt werden.

Die zusätzlichen Aktionen an dem Aufgabe-Knoten zerfallen in die zwei Kategorien ‚Vorbereiten‘ und ‚Projizieren‘

Die Aktionen der Kategorie ‚Vorbereiten‘ dürfen nur auf Instanzen arbeiten die nicht im Status ‚beendet‘ sind. Sie dürfen Verknüpfungen zu benachbarten Knoten herstellen und Daten aus dem Rest des Graphen in die Instanz kopieren. Sie dürfen an der Instanz Aktionen der Kategorie ‚Vorbereiten‘ ausführen. Sie dürfen keine anderen Änderungen am Graphen vornehmen. Konzeptionell gehört die Aktion ‚prvalidieren‘ in diese Kategorie.

Die Aktionen der Kategorie ‚Projizieren‘ dürfen nur auf Instanzen arbeiten die im Status ‚beendet‘ sind. Sie dürfen Verknüpfungen zu benachbarten Knoten herstellen, aber keine weiteren Änderungen an der Instanz durchführen. Sie dürfen an der Instanz Aktionen der Kategorie ‚Projizieren‘ ausführen. Die Aktionen der Kategorie ‚Projizieren‘ dürfen nur ein mal pro Instanz aufgerufen werden. Konzeptionell gehört die Aktion ‚prprojizieren‘ in diese Kategorie.

Für zusätzliche Datenfunktionen an dem Aufgabe-Knoten gilt, dass sie von den benachbarten Knoten nur das Primärattribut auslesen dürfen. Werden an dem Aufgabe-Knoten weitere Daten aus den benachbarten Knoten benötigt so müssen diese durch Aktionen aus der Kategorie ‚Vorbereiten‘ kopiert werden.

Aufgabe-Knoten dürfen nur in Aktionen und Datenfunktionen anderer Aufgabe-Knoten referenziert werden. Eine Instanz im Status ‚beendet‘ darf nicht verändert werden.

Hilfsknoten haben eine ‚zu 1‘-Verknüpfung zu ihren Aufgabe-Knoten. Sie sind konzeptionell identisch mit dem Aufgabe-Knoten und unterliegen damit gleichen Einschränkungen. Ihre Typ hat als Präfix den Typ des Aufgabe-Knoten.

==Das Aufgabe-Fomular==

Die Aktionfunktion prtask_generiereformular generiert zu dem prTask ein Formular in der Auto-Oberfläche. Dieses kann als Ausgangspunkt für das Aufgabe-Fomular dienen. Es hat bereits Schaltflächen für die lifecycle-Aktionen ‚beginnen‘, ‚pausieren‘, ‚fortsetzen‘ und ‚beenden‘. Die Schaltfläche ‚beginnen‘ ruft die neue Aktion ‚aubeginnen‘ auf, welche versucht zu dem aktuellen Autobenutzer ein prPerson-Instanz zu ermitteln, deren Name in das Attribut ‚prperson‘ setzt und die Aktion ‚prbeginnen‘ aufruft. Um die Schaltflächen korrekt zu deaktivieren werden auch noch die Attribute ‚aubeginbar‘, ‚aupausierbar‘, ‚aufortsetzbar‘ und ‚aubeendbar‘ angelegt.

==Die Knoten prAufgabe und prEreignis==

Hauptseite

2019-03-10T07:33:04Z

Hschlabach:

Graph

2019-03-02T16:00:46Z

Hschlabach:

Wenn wir uns ein digitales Unternehmen vorstellen wie einen Menschen, dann stellt der Graph stellt das Gehirn des digitalen Unternehmens dar. Hier werden sowohl Informationen gespeichert als auch Entscheidungen getroffen. Damit der Graph mit der Umwelt kommunizieren kann, muss es eine Schnittstelle geben. Deshalb besteht der Graph aus zwei Teilen. Der erste Teil stellt den Kern des Graphen dar, das funktionale Modell. Der zweite Teil des Graphen bildet die Schnittstelle zur realen Welt, damit eine Interaktion mit dem Modell möglich wird. Dieser Teil ist der Prozessteil des Graphen. In diesem Kapitel wird beschrieben, wie das System generell funktioniert, während später auf die konkrete Implementierung eingegangen wird.

==Idee==

Ein Unternehmen ist ein sehr komplexes System. Es besteht aus vielen verschiedenen einzelnen Komponenten, welche miteinander und mit der Außenwelt kommunizieren. Außerdem ist ein Unternehmen durch innere und äußere Einflüsse einem permanenten Wandel unterzogen. Ein Beispiel hierfür ist ein einfacher Geschäftsvorfall, wie er in der Praxis üblich ist, wie eine Kundenbestellung. Diese Kommunikation mit der Außenwelt mit der Vertriebsabteilung erzeugt zahllose Aktivitäten im Unternehmen, welche eine Kommunikation innerhalb des Unternehmens und nach außen erzeugen. Bei dieser Kommunikation entstehen viele Daten, welche für das Unternehmen relevant sind. So führt die Kundenbestellung möglicherweise dazu, dass die Logistik den Auftrag zur Auslieferung bekommt, eine Bestellung beim Lieferanten ausgelöst wird und am Ende die Finanzabteilung die Zahlung des Kunden verbuchen muss. Außerdem verändert sich ein Unternehmen, es werden neue Produkte und Dienstleistungen angeboten, gesetzliche Rahmenbedingungen ändern sich, welche das Unternehmen betreffen oder eine Restrukturierung des Unternehmens wird durchgeführt, indem eine neue Abteilung mit neuen Aufgaben gegründet wird.

Damit ein ausreichend genaues digitales Abbild des Unternehmens geschaffen werden kann, benötigt man eine passende Datenstruktur. Es gibt nun verschiedene Anforderungen, welche die Datenstruktur erfüllen muss. Die Daten müssen so abgelegt werden, dass man sie wiederfinden kann und die Struktur muss flexibel genug sein, dass man sie entsprechend der Notwendigkeit anpassen kann. Außerdem muss es eine Schnittstelle geben, mit der Informationen mit der Datenstruktur ausgetauscht werden können. Ein weiterer Aspekt ist, dass benötigte Informationen ausreichend schnell aus der Datenstruktur ausgelesen werden können.

Das funktionale Modell des Graphen enthält alle Elemente, damit das digitale Abbild des Unternehmens hinreichend erzeugt werden kann und der Prozessteil des Graphen sorgt dafür, dass die Datenstruktur mit der Umwelt kommunizieren kann.

==Das funktionale Modell==

Funktionale Programmiersprachen bieten die Möglichkeit, sehr komplexe Datenstrukturen zu erschaffen, welche konsistent formuliert werden können. Das Modell ist damit wirkungsfrei. Probleme, welche die Skalierung von Datenstrukturen in herkömmlichen Systemen behindern, treten hier nicht auf. Die Grundidee des funktionalen Modells ist, das wir immer einen diskreten Zustand der Welt betrachten. Soll das Abbild geändert werden, so wird der nächste diskrete Zustand des Abbildes errechnet. Im wesentlichen kann das als Grundprinzip des funktionalen Modells betrachtet werden. Konkret besteht das funktionale Modell aus Knoten, die über Kanten, wir nennen sie Verknüpfungen, verbunden sind. Gibt es zwischen zwei Knoten eine Kante, so besteht diese aus zwei gerichteten Verknüpfungen. Jeder Knoten kann beliebig viele Attribute, wir nennen sie Attributknoten, besitzen. Ein Knoten ist jedoch typisiert, so dass für einen bestimmten Knoten nur bestimmte Attributknoten und bestimmte Verknüpfungen zu anderen Knotentypen erlaubt sind. Die Verknüpfungen besitzen eine Kardinalität von 1 oder n. Eine Kardinalität von 1 bedeutet, dass ein bestimmter Knotentyp nur ein Mal mit einem bestimmten andern Knotentyp verknüpft sein kann. Eine Kardinalität von n bedeutet, dass ein bestimmter Knotentyp mit beliebig vielen anderen Knotentypen verknüpft sein kann. Ein Beispiel hierfür soll das digitale Abbild einer Rechnung sein. Mit dem bisher definierten System können wir folgendes formulieren:

Es gibt Knoten vom Typ „Rechnung“ mit zwei Attributen, „Datum“ und „Rechnungsnummer“

Es gibt einen Knoten vom Typ „Kunde“ mit dem Attribut „Name“

Die Verknüpfung von „Rechnung zu Kunde“ hat die Kardinalität 1, das bedeutet, eine Rechnung kann immer nur einem Kunden zugeordnet werden.

Die Verknüpfung von „Kunde zu Rechnung“ hat die Kardinalität n, das bedeutet, ein Kunde kann mehrere Rechnungen bekommen haben

Damit lässt sich eine beliebige Datenstruktur darstellen. Das Selbe kann man natürlich auch mit einer relationalen Datenbank oder einem objektorientierten Modell erreichen.

So weit haben wir erst einmal die Beschreibung der Datenstruktur und dann die Datenstruktur selbst. Die Beschreibung der Datenstruktur ist im funktionalen Modell selbst enthalten, sie ist also selbstreflektiv. Es gibt einen Knoten vom Typ Knoten, der einen Knoten beschreibt, in unserem Beispiel z.B. die Rechnung.

Nun möchten wir in unserem Beispiel wissen, wie viele Rechnungen ein Kunde bereits bekommen hat. Dafür fügen dem Knoten Kunde einen weiteres Attribut „Anzahl Rechnungen“ hinzu. Dafür definieren wir in unserem funktionalen System eine Datenfunktion. Das Attribut „Anzahl Rechnungen“ wird nun über eine Funktion definiert, nämlich die Anzahl der Verknüpfungen vom Typ „Kunde zu Rechnung“

In Datenfunktionen sind alle herkömmlichen Programmierbefehle erlaubt, die keine Informationen von außen in das System einbringen. Die aktuelle Implementierung des Modells ist in PHP durchgeführt, so dass alle PHP Funktionen, bei welchen sich der Rückgabewert aus den Parametern berechnen lässt, erlaubt sind. Nicht erlaubt sind Funktionen, welche dem Modell Informationen hinzufügen, so z.B. date() oder rand(). Nun können, wenn wir komplexere Datenstrukturen bilden, Datenfunktionen wieder auf andere Datenfunktionen zugreifen, so dass eine Änderung des Systems eine Kaskade von Änderungen hervorrufen kann. Die Datenfunktion selbst (also ihre Beschreibung) ist nun selbstreflektiv im funktionalen Modell enthalten, damit ist sie ebenfalls Teil des funktionalen Systems.

Bei jeder Änderung werden die Informationen über jedes einzelne Attribut, jede Verknüpfung und jeden Knoten gespeichert. Das Speichern der Änderung wiederum ruft möglicherweise die nächste Datenfunktion auf, welche einer weitere aufrufen könnte usw. So muss ein bestimmter Teilbaum des Graphen möglicherweise bei der Änderung neu ausgerechnet werden. In aller Regel ebbt diese Kaskade an Änderungen aber extrem schnell ab. Danach ist der neue Zustand des Modells konsistent gespeichert. Die „Zwischenergebnisse“, also die Werte der Attribute, welche durch eine Funktion definiert sind, werden jedoch abgespeichert, so dass diese zu einem späteren Zeitpunkt sofort verfügbar sind. Somit haben wir im Modell immer ein Abbild der Realität geschaffen, welches zu einem diskreten Zeitpunkt konsistent ist, nämlich nach der letzten Änderung. Primärdaten, welche nicht durch Funktionen berechnet werden, sind somit aus Modellsicht als Konstanten zu betrachten.

Wird nun lesend auf die Struktur zugegriffen, so wird nur auf das gespeicherte Abbild des aktuellen Modells zugegriffen. Damit stellt das funktionale Modell eine rein funktionale Programmiersprache dar, was beträchtliche Auswirkungen auf die Fähigkeiten des Systems hat. Ohne an dieser Stelle weiter darauf einzugehen, somit kann sich das funktionale Modell mit bekannten Methoden der Informatik und Mathematik selbst manipulieren, ohne dass die Integrität der Daten gefährdet wird. Das ist vermutlich der bedeutendste Effekt des gesamten Systems.

Es gibt noch weitere Elemente des funktionalen Modells, welche aber nur Variationen der bisher erläuterten Konzepte sind. Es ist neben der Änderung von Attributen möglich, Knoten zu erzeugen und zu vernichten, sowie Verknüpfungen herzustellen und zu entfernen. Darauf wird in den späteren Kapiteln noch weiter eingegangen.

==Der Prozessteil==
Mit dem funktionalen System ist nun die Möglichkeit geschaffen worden, eine beliebig komplexe Datenstruktur aufzubauen, deren Konsistenz zu jedem (diskreten) Zeitpunkt sichergestellt ist und die jederzeit sehr schnell abgefragt werden kann, unabhängig davon, wie komplex die abgerufene Information entstanden ist.

Es wurde auch herausgestellt, dass durch die Änderung einer Information der nächste diskrete Zustand des funktionalen Systems erzeugt wird.

Es gibt nun neben der Abfrage von Daten aus dem funktionalen System nun noch zwei Wege der Kommunikation, nämlich das schon benannte Ändern der Information und außerdem die Möglichkeit, dass das funktionale System Änderungen an der Welt herbeiführen möchte.

Betrachten wir nun als erstes die Änderung des Modells. Diese Interaktion ist recht einfach; es wird eine beliebige Information geändert, also ein Attribut wird geändert, ein Knoten wird erzeugt oder vernichtet oder eine Verknüpfung wird hergestellt oder entfernt. Aus Sicht des funktionalen Systems sind diese Änderungen alle gleichwertig, sie führen dazu, dass das gesamte System in den nächsten Zustand überführt wird. Konkret gibt es dafür Befehle, welche das Modell manipulieren, so z.B. der Befehl erzeuge(), welcher einen Knoten erzeugt oder setze() welcher ein Attribut ändert. Wird einer dieser manipulierenden Befehle aufgerufen, wird das funktionale Modell neu ausgerechnet.

Möchte das Modell die Realität verändern, so wird geprüft, ob sich ein bestimmtes Attribut geändert hat. Ist dies der Fall wird eine Aktionfunktion ausgeführt, welche die Welt verändern kann. Das kann z.B. das Versenden einer E-Mail sein oder auch das Einschalten einer Beleuchtung.

Damit unser Modell konsistent bleibt, werden die beiden Manipulationen außerhalb des funktionalen Modells durchgeführt. Für diesen Zweck gibt es den Prozessteil des Graphen. Im Prozessteil des Graphen, welcher nicht Teil des funktionalen Modells ist, auch wenn er selbst nur als Teil des funktionalen Modells formuliert ist, können auch von außerhalb Informationen in das System geschleust werden, außerdem gibt es hier die Aktionfunktionen, welche die Welt manipulieren. Er bildet also die Schnittstelle zur realen Welt.

Der Prozessteil besteht aus Knoten, welche als Prozessknoten typisiert sind. Diese sind die einzigen, welche das Modell ändern dürfen und sie sind die einzigen, die von der Welt geändert werden dürfen. Die Änderung, welche die Prozessknoten am Modell durchführen, errechnen aber gleichzeitig auch den neuen Zustand aller Prozessknoten, so dass diese möglicherweise Manipulationen an der Welt durchführen können, welche durch die Veränderung von Informationen aus der Welt ausgelöst wurden.

Da die Struktur des funktionalen Modells im Graphen selbstreflexiv abgebildet ist, kann der Umfang des Abbildes der Realität, also das digitale Modell des Unternehmens, jederzeit beliebig verändert werden. Dieser Vorgang ist aus Sicht des funktionalen Systems eine normale Änderung der Daten wie jede andere auch. Der Prozessteil führt in diesem Fall nur zusätzliche Manipulationen an der Welt aus, welche es ermöglichen, die geänderte Datenstruktur zu erzeugen. Die gespeicherten Daten sind aber nicht Teil des Modells sondern der Welt und somit vom Prozessteil des Graphen zu verwalten. Das mag nicht stimmig klingen, wenn man sich aber z.B. den Menschen ansieht, dann haben wir eine ähnliche Situation; der menschliche Verstand entspringt dem Gehirn, aber das Gehirn, in dem der Verstand entsteht ist nicht Teil des menschlichen Verstandes.

Da sich die Welt kontinuierlich verändert, muss auch das Abbild er Realität, also das funktionale Modell permanent aktualisiert werden. Würde das immer hintereinander gemacht, wäre das System viel zu langsam und außerdem ineffizient, da jede kleine Änderung erst komplett neu errechnet werden müsste, bevor der nächste Zustand erreicht ist. Da wir aber ein rein funktionales System haben, können die Änderungen parallel im System aktualisiert werden. Die Kaskaden der Neuberechnung des Modells sind auch bei paralleler Abarbeitung so, das am Ende ein konsistentes Modell entsteht. Das muss noch genauer erforscht werden, aber in der Praxis treten auch bei massiven, parallel durchgeführten Änderungen im Referenzmodell keine Inkonsistenzen auf.

Das funktionale Modell und der Prozessteil ergeben somit die Möglichkeit, ein sich aktualisierendes Abbild der Realität zu erschaffen, welches auch Informationen an die Welt zurück geben kann. Damit ist die theoretische Voraussetzung geschaffen, ein so komplexes System wie ein Unternehmen in beliebiger und sich ändernder Detaillierung digital abzubilden.

Graph

2019-03-02T15:57:17Z

Hschlabach: Die Seite wurde neu angelegt: „Wenn wir uns ein digitales Unternehmen vorstellen wie einen Menschen, dann stellt der Graph stellt das Gehirn des digitalen Unternehmens dar. Hier werden sowoh…“

Wenn wir uns ein digitales Unternehmen vorstellen wie einen Menschen, dann stellt der Graph stellt das Gehirn des digitalen Unternehmens dar. Hier werden sowohl Informationen gespeichert als auch Entscheidungen getroffen. Damit der Graph mit der Umwelt kommunizieren kann, muss es eine Schnittstelle geben. Deshalb besteht der Graph aus zwei Teilen. Der erste Teil stellt den Kern des Graphen dar, das funktionale Modell. Der zweite Teil des Graphen bildet die Schnittstelle zur realen Welt, damit eine Interaktion mit dem Modell möglich wird. Dieser Teil ist der Prozessteil des Graphen. In diesem Kapitel wird beschrieben, wie das System generell funktioniert, während später auf die konkrete Implementierung eingegangen wird.

==Idee==
Ein Unternehmen ist ein sehr komplexes System. Es besteht aus vielen verschiedenen einzelnen Komponenten, welche miteinander und mit der Außenwelt kommunizieren. Außerdem ist ein Unternehmen durch innere und äußere Einflüsse einem permanenten Wandel unterzogen. Ein Beispiel hierfür ist ein einfacher Geschäftsvorfall, wie er in der Praxis üblich ist, wie eine Kundenbestellung. Diese Kommunikation mit der Außenwelt mit der Vertriebsabteilung erzeugt zahllose Aktivitäten im Unternehmen, welche eine Kommunikation innerhalb des Unternehmens und nach außen erzeugen. Bei dieser Kommunikation entstehen viele Daten, welche für das Unternehmen relevant sind. So führt die Kundenbestellung möglicherweise dazu, dass die Logistik den Auftrag zur Auslieferung bekommt, eine Bestellung beim Lieferanten ausgelöst wird und am Ende die Finanzabteilung die Zahlung des Kunden verbuchen muss. Außerdem verändert sich ein Unternehmen, es werden neue Produkte und Dienstleistungen angeboten, gesetzliche Rahmenbedingungen ändern sich, welche das Unternehmen betreffen oder eine Restrukturierung des Unternehmens wird durchgeführt, indem eine neue Abteilung mit neuen Aufgaben gegründet wird.

Damit ein ausreichend genaues digitales Abbild des Unternehmens geschaffen werden kann, benötigt man eine passende Datenstruktur. Es gibt nun verschiedene Anforderungen, welche die Datenstruktur erfüllen muss. Die Daten müssen so abgelegt werden, dass man sie wiederfinden kann und die Struktur muss flexibel genug sein, dass man sie entsprechend der Notwendigkeit anpassen kann. Außerdem muss es eine Schnittstelle geben, mit der Informationen mit der Datenstruktur ausgetauscht werden können. Ein weiterer Aspekt ist, dass benötigte Informationen ausreichend schnell aus der Datenstruktur ausgelesen werden können.

Das funktionale Modell des Graphen enthält alle Elemente, damit das digitale Abbild des Unternehmens hinreichend erzeugt werden kann und der Prozessteil des Graphen sorgt dafür, dass die Datenstruktur mit der Umwelt kommunizieren kann.

==Das funktionale Modell==

Funktionale Programmiersprachen bieten die Möglichkeit, sehr komplexe Datenstrukturen zu erschaffen, welche konsistent formuliert werden können. Das Modell ist damit wirkungsfrei. Probleme, welche die Skalierung von Datenstrukturen in herkömmlichen Systemen behindern, treten hier nicht auf. Die Grundidee des funktionalen Modells ist, das wir immer einen diskreten Zustand der Welt betrachten. Soll das Abbild geändert werden, so wird der nächste diskrete Zustand des Abbildes errechnet. Im wesentlichen kann das als Grundprinzip des funktionalen Modells betrachtet werden. Konkret besteht das funktionale Modell aus Knoten, die über Kanten, wir nennen sie Verknüpfungen, verbunden sind. Gibt es zwischen zwei Knoten eine Kante, so besteht diese aus zwei gerichteten Verknüpfungen. Jeder Knoten kann beliebig viele Attribute, wir nennen sie Attributknoten, besitzen. Ein Knoten ist jedoch typisiert, so dass für einen bestimmten Knoten nur bestimmte Attributknoten und bestimmte Verknüpfungen zu anderen Knotentypen erlaubt sind. Die Verknüpfungen besitzen eine Kardinalität von 1 oder n. Eine Kardinalität von 1 bedeutet, dass ein bestimmter Knotentyp nur ein Mal mit einem bestimmten andern Knotentyp verknüpft sein kann. Eine Kardinalität von n bedeutet, dass ein bestimmter Knotentyp mit beliebig vielen anderen Knotentypen verknüpft sein kann. Ein Beispiel hierfür soll das digitale Abbild einer Rechnung sein. Mit dem bisher definierten System können wir folgendes formulieren:

Es gibt Knoten vom Typ „Rechnung“ mit zwei Attributen, „Datum“ und „Rechnungsnummer“

Es gibt einen Knoten vom Typ „Kunde“ mit dem Attribut „Name“

Die Verknüpfung von „Rechnung zu Kunde“ hat die Kardinalität 1, das bedeutet, eine Rechnung kann immer nur einem Kunden zugeordnet werden.

Die Verknüpfung von „Kunde zu Rechnung“ hat die Kardinalität n, das bedeutet, ein Kunde kann mehrere Rechnungen bekommen haben

Damit lässt sich eine beliebige Datenstruktur darstellen. Das Selbe kann man natürlich auch mit einer relationalen Datenbank oder einem objektorientierten Modell erreichen.

So weit haben wir erst einmal die Beschreibung der Datenstruktur und dann die Datenstruktur selbst. Die Beschreibung der Datenstruktur ist im funktionalen Modell selbst enthalten, sie ist also selbstreflektiv. Es gibt einen Knoten vom Typ Knoten, der einen Knoten beschreibt, in unserem Beispiel z.B. die Rechnung.

Nun möchten wir in unserem Beispiel wissen, wie viele Rechnungen ein Kunde bereits bekommen hat. Dafür fügen dem Knoten Kunde einen weiteres Attribut „Anzahl Rechnungen“ hinzu. Dafür definieren wir in unserem funktionalen System eine Datenfunktion. Das Attribut „Anzahl Rechnungen“ wird nun über eine Funktion definiert, nämlich die Anzahl der Verknüpfungen vom Typ „Kunde zu Rechnung“

In Datenfunktionen sind alle herkömmlichen Programmierbefehle erlaubt, die keine Informationen von außen in das System einbringen. Die aktuelle Implementierung des Modells ist in PHP durchgeführt, so dass alle PHP Funktionen, bei welchen sich der Rückgabewert aus den Parametern berechnen lässt, erlaubt sind. Nicht erlaubt sind Funktionen, welche dem Modell Informationen hinzufügen, so z.B. date() oder rand(). Nun können, wenn wir komplexere Datenstrukturen bilden, Datenfunktionen wieder auf andere Datenfunktionen zugreifen, so dass eine Änderung des Systems eine Kaskade von Änderungen hervorrufen kann. Die Datenfunktion selbst (also ihre Beschreibung) ist nun selbstreflektiv im funktionalen Modell enthalten, damit ist sie ebenfalls Teil des funktionalen Systems.

Bei jeder Änderung werden die Informationen über jedes einzelne Attribut, jede Verknüpfung und jeden Knoten gespeichert. Das Speichern der Änderung wiederum ruft möglicherweise die nächste Datenfunktion auf, welche einer weitere aufrufen könnte usw. So muss ein bestimmter Teilbaum des Graphen möglicherweise bei der Änderung neu ausgerechnet werden. In aller Regel ebbt diese Kaskade an Änderungen aber extrem schnell ab. Danach ist der neue Zustand des Modells konsistent gespeichert. Die „Zwischenergebnisse“, also die Werte der Attribute, welche durch eine Funktion definiert sind, werden jedoch abgespeichert, so dass diese zu einem späteren Zeitpunkt sofort verfügbar sind. Somit haben wir im Modell immer ein Abbild der Realität geschaffen, welches zu einem diskreten Zeitpunkt konsistent ist, nämlich nach der letzten Änderung. Primärdaten, welche nicht durch Funktionen berechnet werden, sind somit aus Modellsicht als Konstanten zu betrachten.

Wird nun lesend auf die Struktur zugegriffen, so wird nur auf das gespeicherte Abbild des aktuellen Modells zugegriffen. Damit stellt das funktionale Modell eine rein funktionale Programmiersprache dar, was beträchtliche Auswirkungen auf die Fähigkeiten des Systems hat. Ohne an dieser Stelle weiter darauf einzugehen, somit kann sich das funktionale Modell mit bekannten Methoden der Informatik und Mathematik selbst manipulieren, ohne dass die Integrität der Daten gefährdet wird. Das ist vermutlich der bedeutendste Effekt des gesamten Systems.

Es gibt noch weitere Elemente des funktionalen Modells, welche aber nur Variationen der bisher erläuterten Konzepte sind. Es ist neben der Änderung von Attributen möglich, Knoten zu erzeugen und zu vernichten, sowie Verknüpfungen herzustellen und zu entfernen. Darauf wird in den späteren Kapiteln noch weiter eingegangen.

==Der Prozessteil==
Mit dem funktionalen System ist nun die Möglichkeit geschaffen worden, eine beliebig komplexe Datenstruktur aufzubauen, deren Konsistenz zu jedem (diskreten) Zeitpunkt sichergestellt ist und die jederzeit sehr schnell abgefragt werden kann, unabhängig davon, wie komplex die abgerufene Information entstanden ist.

Es wurde auch herausgestellt, dass durch die Änderung einer Information der nächste diskrete Zustand des funktionalen Systems erzeugt wird.

Es gibt nun neben der Abfrage von Daten aus dem funktionalen System nun noch zwei Wege der Kommunikation, nämlich das schon benannte Ändern der Information und außerdem die Möglichkeit, dass das funktionale System Änderungen an der Welt herbeiführen möchte.

Betrachten wir nun als erstes die Änderung des Modells. Diese Interaktion ist recht einfach; es wird eine beliebige Information geändert, also ein Attribut wird geändert, ein Knoten wird erzeugt oder vernichtet oder eine Verknüpfung wird hergestellt oder entfernt. Aus Sicht des funktionalen Systems sind diese Änderungen alle gleichwertig, sie führen dazu, dass das gesamte System in den nächsten Zustand überführt wird. Konkret gibt es dafür Befehle, welche das Modell manipulieren, so z.B. der Befehl erzeuge(), welcher einen Knoten erzeugt oder setze() welcher ein Attribut ändert. Wird einer dieser manipulierenden Befehle aufgerufen, wird das funktionale Modell neu ausgerechnet.

Möchte das Modell die Realität verändern, so wird geprüft, ob sich ein bestimmtes Attribut geändert hat. Ist dies der Fall wird eine Aktionfunktion ausgeführt, welche die Welt verändern kann. Das kann z.B. das Versenden einer E-Mail sein oder auch das Einschalten einer Beleuchtung.

Damit unser Modell konsistent bleibt, werden die beiden Manipulationen außerhalb des funktionalen Modells durchgeführt. Für diesen Zweck gibt es den Prozessteil des Graphen. Im Prozessteil des Graphen, welcher nicht Teil des funktionalen Modells ist, auch wenn er selbst nur als Teil des funktionalen Modells formuliert ist, können auch von außerhalb Informationen in das System geschleust werden, außerdem gibt es hier die Aktionfunktionen, welche die Welt manipulieren. Er bildet also die Schnittstelle zur realen Welt.

Der Prozessteil besteht aus Knoten, welche als Prozessknoten typisiert sind. Diese sind die einzigen, welche das Modell ändern dürfen und sie sind die einzigen, die von der Welt geändert werden dürfen. Die Änderung, welche die Prozessknoten am Modell durchführen, errechnen aber gleichzeitig auch den neuen Zustand aller Prozessknoten, so dass diese möglicherweise Manipulationen an der Welt durchführen können, welche durch die Veränderung von Informationen aus der Welt ausgelöst wurden.

Da die Struktur des funktionalen Modells im Graphen selbstreflexiv abgebildet ist, kann der Umfang des Abbildes der Realität, also das digitale Modell des Unternehmens, jederzeit beliebig verändert werden. Dieser Vorgang ist aus Sicht des funktionalen Systems eine normale Änderung der Daten wie jede andere auch. Der Prozessteil führt in diesem Fall nur zusätzliche Manipulationen an der Welt aus, welche es ermöglichen, die geänderte Datenstruktur zu erzeugen. Die gespeicherten Daten sind aber nicht Teil des Modells sondern der Welt und somit vom Prozessteil des Graphen zu verwalten. Das mag nicht stimmig klingen, wenn man sich aber z.B. den Menschen ansieht, dann haben wir eine ähnliche Situation; der menschliche Verstand entspringt dem Gehirn, aber das Gehirn, in dem der Verstand entsteht ist nicht Teil des menschlichen Verstandes.

Da sich die Welt kontinuierlich verändert, muss auch das Abbild er Realität, also das funktionale Modell permanent aktualisiert werden. Würde das immer hintereinander gemacht, wäre das System viel zu langsam und außerdem ineffizient, da jede kleine Änderung erst komplett neu errechnet werden müsste, bevor der nächste Zustand erreicht ist. Da wir aber ein rein funktionales System haben, können die Änderungen parallel im System aktualisiert werden. Die Kaskaden der Neuberechnung des Modells sind auch bei paralleler Abarbeitung so, das am Ende ein konsistentes Modell entsteht. Das muss noch genauer erforscht werden, aber in der Praxis treten auch bei massiven, parallel durchgeführten Änderungen im Referenzmodell keine Inkonsistenzen auf.

Das funktionale Modell und der Prozessteil ergeben somit die Möglichkeit, ein sich aktualisierendes Abbild der Realität zu erschaffen, welches auch Informationen an die Welt zurück geben kann. Damit ist die theoretische Voraussetzung geschaffen, ein so komplexes System wie ein Unternehmen in beliebiger und sich ändernder Detaillierung digital abzubilden.

Hauptseite

2019-03-02T15:51:57Z

Hschlabach:

==Allgemein==
In diesem Wiki werden Werkzeuge beschrieben, die von Graph-IT zu Verfügung gestellt werden, um eine durchgängige Digitalisierung zu erreichen.

[[Graph | Der Graph]]