Getting started

Diese Seite führt schrittweise in zentrale Konzepte und Werkzeuge des ClassiX-Systems ein. Im Mittelpunkt steht das standardisierte Unternehmensmodell, das durch abstrahierte Geschäftsobjekte eine flexible und zugleich stabile Basis für betriebliche Anwendungen schafft. Die klare Systemarchitektur mit dem CyberEnterprise als Fundament sowie die objektorientierte Datenbank ermöglichen einen direkten Zugriff auf zusammenhängende Datenstrukturen ohne komplexe Tabellenverknüpfungen.

Um die Verständlichkeit und Übersichtlichkeit von Code – sowohl für Sie selbst als auch für Dritte – zu gewährleisten, wird an dieser Stelle auf die große Bedeutung der Einhaltung der ClassiX-Programmierrichtlinien hingewiesen. Alle ClassiX-Anwendungen folgen diesen Richtlinien. Dadurch entstehen unter anderem die einheitlich gestalteten Benutzeroberflächen sämtlicher Applikationen. Während der Tutorials wird kontinuierlich auf die Richtlinien Bezug genommen.

Wichtiger Hinweis: Diese Einführung bietet Ihnen einen ersten Überblick. Um das System umfassend zu verstehen und effizient nutzen zu können, empfiehlt es sich, die weiterführenden Seiten sorgfältig zu lesen:

• Vertiefung in das System vermittelt Ihnen ein tieferes Verständnis der grundlegenden Architektur und Konzepte.
• Die Programmierrichtlinien sind essenziell für eine konsistente und wartbare Entwicklung im ClassiX-Umfeld.
• In den Tutorials werden Sie praxisnah durch typische Anwendungsfälle geführt und lernen Schritt für Schritt den Umgang mit dem System.

• Vorwort

  • Classix

  • Unternehmensmodell

• Einführung in das System

• Architektur

• Datenbank

• InstantView

Vorwort

ClassiX wird als objektorientiertes System zur Entwicklung betriebswirtschaftlicher Anwendungen eingeführt, das sich durch dynamische Geschäftsobjekte und einen zentralen Daten-Stack von klassischen Systemen unterscheidet. Ergänzt wird es durch das AppsWarehouse, eine Sammlung vorgefertigter Anwendungen. Das zugrunde liegende Unternehmensmodell, das CyberEnterprise, bildet betriebliche Strukturen abstrakt und erweiterbar ab.

Classix

Ein durchgehend objektorientiertes System zur Erstellung betriebswirtschaftlicher Anwendungen. Dabei unterscheidet es sich in mehreren grundlegenden Punkten von herkömmlichen Systemen: Statt klassischer, fest verdrahteter Logik basiert ClassiX auf einem dynamischen Zusammenspiel von Geschäftsobjekten, sofort ausführbarem Anwendungscode und einem stackbasierten Programmiermodell.

Damit stellt sich ClassiX erst einmal als technische Lösung, sozusagen als Baukasten für die Anwendungsentwicklung dar. Es soll jedoch gleich vorweg genommen werden, dass ClassiX sich nicht als reines Entwicklungssystem versteht, sondern mit dem AppsWarehouse, dem „Application Warehouse“ bereits über eine umfangreiche Bibliothek fertiger, betriebswirtschaftlicher Anwendungen verfügt.

ClassiX sieht sich deshalb auch als Komplettlösung für Unternehmen jeglicher Branche, in der die völlige Neuentwicklung von Anwendungen eigentlich die Ausnahme bilden sollte.

Dieses Tutorial beginnt jedoch – zur Förderung des Gesamtverständnisses – mit der Entwicklung einer Beispiels-Anwendung von Anfang an.

Die ClassiX Tutorials vermitteln dem Anwendungsentwickler die für den Umgang mit ClassiX notwendigen Grundlagen. Weil ClassiX sich in Aufbau und Verhalten deutlich von klassischen Softwaresystemen unterscheidet – unter anderem durch die unmittelbare Interaktion mit einem zentralen Daten-Stack, modulare App-Komponenten und dynamisch veränderbare Prozesse – soll diese Einleitung zunächst ein Gesamtbild vermitteln und dabei die Besonderheiten erläutern. Sofern weitergehende Literatur zu einzelnen Themen vorhanden ist, wird dies im Weiteren entsprechend vermerkt, gegebenenfalls mit einem direkten Link.

Wir beginnen mit einem kurzen Einblick in die System-Architektur von ClassiX, dann folgt eine kurze Darstellung des zugrunde liegenden Unternehmensmodells. Anschließend wird InstantView vorgestellt, indem die wichtigsten Eigenschaften dieser Applikations-Skriptsprache beleuchtet werden. Den Schluss bildet eine Übersicht über die einzelnen Tutorials.

Die Einführungstexte und Exkurse zum ClassiX-System und zu InstantView sind als Ergänzung gedacht, sie sind keine Voraussetzung für die folgenden Teile der Tutorials. Dort wird eine Beispielsanwendung Schritt für Schritt aufgebaut. Auf jeder Stufe ist die einzige Voraussetzung für das Verständnis die Kenntnis der vorhergehenden Stufen. 

Unternehmensmodell

Vorab wurde das CyberEnterprise bereits als kybernetische Abbildung eines Unternehmens und damit als das dem ClassiX-System zugrunde liegende Unternehmensmodell vorgestellt.

Das CyberEnterprise enthält alle für die Beschreibung der betriebswirtschaftlichen Welt notwendigen Klassen. Dieser Klassenbaum ist auf C++ Ebene modelliert. Die Klassen sind in ihrer Struktur so abstrakt und einfach wie nur möglich gehalten. Dadurch kommt ClassiX mit etwa 300 Klassen aus. Die ersten Tutorials starten bewusst mit sehr einfachen Programmbeispielen (Abbildung von Personen und familiären Beziehungen), die nicht unbedingt aus der betriebswirtschaftlichen Welt stammen, aber Teil der realen Welt sind.

Alle Klassen sind von CX_CLASS abgeleitet. Sie lassen sich in drei Hauptkategorien gliedern:

1) Basis Objekte (Primitive and Intelligent Data Types)
Das sind die grundlegenden Objekte wie:

2) Informationsobjekte (Information Objects)
Das sind beschreibende Objekte wie:

Alle Informationsobjekte sind abgeleitet von CX_EXPANDABLE - sind also erweiterbar.

3) Geschäftsobjekte (Business Objects)
Diese sind auch von CX_EXPANDABLE abgeleitet (über CX_STRUCTURED). Geschäftsobjekte werden wiederum in reale Objekte (Geschäftspartner CX_PARTNER und Sachen CX_ITEM (tangible objects)) und in Begriffe (intangible objects) untergliedert.

Unter „Begriffen“ verstehen wir zum Beispiel die Rollen eines Objektes: Ein Geschäftspartner kann die Rollen Kunde, Lieferant, Hersteller, etc. in einfacher, wie auch in mehrfacher Ausprägung haben. Auch sind z.B. Kostenstellen, Buchungskreise, Arbeitsgruppen Bezeichnungen für abstrakte Begriffe.

4) Belege (Transaction Objects)
Geschäftsobjekte werden klassischerweise als Stammdaten bezeichnet, als Bewegungsdaten werden z.B. Aufträge, Rechnungen oder Wareneingangsbelege bezeichnet. Diese Bewegungsdaten werden im ClassiX als Objekte der Klasse CX_TRANSACTION und seiner abgeleiteten Klassen modelliert.

5) Konten (Monitor Objects)
Konten sind - gemeinsam mit dem Regelwerk der Transaktionsbeschreibungen - das zentrale Auswertungswerkzeug für Belege (CX_TRANSACTION). Ob Buchhaltung, Lager- oder Zeitwirtschaft , jegliche Statistiken, Vorgänge oder Geschäftsprozesse, überall hat man es mit einer "Kontierung" von Belegen oder Bewegungsdaten zu tun.

Wir haben eingangs in den Prämissen festgestellt, dass alle Unternehmen im Unternehmensmodell prinzipiell gleich sind. Das trifft natürlich nur in der Abstraktion auf eine Grundstruktur zu. Unternehmen können durchaus Geschäftsobjekte unterschiedlich benennen oder auch unterschiedliche Ausprägungen ihrer Geschäftsobjekte einsetzen.

Von CX_EXPANDABLE abgeleitete Klassen, können deshalb um sogenannte Dynamische Datenfelder erweitert werden, zum anderen können neue Klassen (sogenannte „Pseudoklassen“) abgeleitet werden, d. h. das Klassifizierungs-Schema der Geschäftsobjekte ist beliebig erweiterbar.

• Zahl    CX_NUMERIC
• Datum    CX_DATE
• Formel    CX_FORMULA
• Zeitraum    CX_SPAN_DATE
• Zeit    CX_TIME
• Attribute    CX_ATTRIBUTES
• Verbindungen    CX_ACCESS
• Zu/Abschläge    CX_CHARGE
• Kalendarien    CX_CALENDAR

Einführung in das System

Dieser kurzen Einführung in die Architektur von ClassiX müssen zum besseren Verständnis drei Prämissen vorangestellt werden:

1. Alle (betriebswirtschaftlichen) Unternehmen sind in ihrer Grundstruktur gleich. Das setzt - für die digitale Transformation jedes einzelnen Unternehmens - eine hohe Abstraktion des Unternehmes und seiner Geschäftsprozesse voraus. ClassiX hat diese abstrakten Geschäftsobjekte entwickelt, diese sind seit Jahrzehnten im Einsatz und haben sich bewährt.
2. Alle Geschäftsobjekte zusammen bilden ein standardisiertes, digitales Unternehmensmodell, das die Basis aller Anwendungen in ClassiX ist.
3. Die individuellen Unterschiede zwischen den Unternehmen werden durch einfache Dialoganpassungen, Regel behaftete Geschäftsprozess Ausprägungen und flexible Datenstrukturen schnell realisiert. Das garantiert die ClassiX Plattform, da sie für einen stetigen Wandel und somit für die kontinuierliche Verbesserung der Prozesse (KVP) eines Unternehmens konzipiert wurde.

Damit liegt der Schwerpunkt einer Entwicklung mit ClassiX auf der individuellen Anpassung von Dialogen und Prozessen mit den vordefinierten Geschäftsobjekten und Standard Apps aus dem AppsWarehouse.

Architektur

Die Ebenen der ClassiX Architektur sind klar voneinander getrennt. In der untersten Ebene befindet sich das Unternehmensmodell. Darunter verstehen wir die kybernetische Abbildung (CyberEnterprise) eines Unternehmens. Als Werkzeug für die Visualisierung und Vernetzung der Daten stellt ClassiX dem Anwendungsentwickler die Skriptsprache InstantView zur Verfügung. In InstantView werden auch Entitäten übergreifende Prozeduren (provider) geschrieben und darüber hinaus gesteuert, welche Objekte welche dynamischen Datenfelder erhalten sollen. Die folgenden Tutorials werden sich deshalb im Wesentlichen mit Gebrauch dieser Skriptsprache zum Entwickeln der Benutzeroberfläche und der Erweiterung des Datenmodells befassen. Nach einer elementaren Einführung wie eine ClassiX Anwendung mit InstantView - von Grund auf neu - entwickelt werden kann, wird die gesamte vorhandene Anwendungsbibliothek, das AppsWarehouse, vorgestellt. Mit dem „Application Warehouse“ verfügt ClassiX bereits über eine umfangreiche Sammlung vorgefertigter Dialoge (-> Anwendungen). Aus diesen lassen sich dann komplette individuelle Anwendungslösungen zusammenstellen. MorhpIT stellt, Browser-basierend, die mit InstantView geschriebenen Anwendungslösungen in einer ergonomisch optimalen Weise zur Verfügung. Einen ausführlichen Einblick in die einzelnen Schichten der Classix-Architektur geben die Dokumentationen für die Architektur, das CyberEnterprise, die InstantView-Scriptsprache , das AppsWarehouse und das MorhpIT.

Datenbank

Bei ClassiX arbeiten wir mit einer objektorientierten Datenbank, die sich grundlegend von der üblichen Nutzung relationaler Datenbanken unterscheidet. Während in relationalen Datenbanken Informationen in verschiedenen, nach dem Prinzip der Normalisierung organisierten Tabellen gespeichert werden, fasst das objektorientierte Modell bei ClassiX zusammengehörige Daten zu sogenannten Objekten zusammen. Mit diesem Ansatz sind alle relevanten Informationen direkt zugänglich, ohne dass man sich mithilfe von Fremdschlüsseln durch mehrere Tabellen navigieren muss.

Statt Daten auf verschiedene Tabellen zu verteilen, kann man bei der objektorientierten Datenbank von ClassiX mit einem einzigen "Eintrittspunkt" arbeiten. Ein Treffer gibt direkten Zugriff auf alle verbundenen Daten, da durch Rückrelationen jedes Objekt "weiß", welche weiteren Daten oder Objekte zu ihm gehören.

Im Gegensatz zu relationalen Datenbanken, bei denen komplexe Datenstrukturen durch viele Verknüpfungen zwischen Tabellen erstellt werden, sind bei einer objektorientierten Datenbank alle Bestandteile einer Einheit sofort verfügbar. Dies ermöglicht es, deutlich komplexere Datensätze effizient zu handhaben, ohne dass die Datenbank durch umfangreiche Verknüpfungen ausgebremst wird.

InstantView

InstantView spielt bei der Arbeit mit dem ClassiX-System eine zentrale Rolle und steht deshalb im Mittelpunkt des gesamten Tutorials.
Im vorhergehenden Abschnitt wurde eine Idee davon vermittelt, wie sich das CyberEnterprise als eine Gesamtheit von Geschäftsklassen mit hohem Abstraktionsgrad darstellt.

Mit den Geschäftsobjekten beginnt die digitale Abbildung eines Unternehmens, aber es entstehen noch keine Anwendungen. Wir haben also die Einzelteile, benötigen aber ein Werkzeug, mit dem fertige Anwendungen erstellt werden können.

InstantView ist eine Applikations-Skriptsprache, mit deren Hilfe die Geschäftsobjekte innerhalb von Anwendungsmodulen (Apps) zum Leben erweckt werden. Die Bibliothek bereits existierender Anwendungsmodule, das AppsWarehouse erscheint als reichhaltige Sammlung vorgefertigte Baugruppen, die nur noch zu einer Komplettanwendung zusammengestellt werden müssen. Auch dafür ist InstantView zuständig.
InstantView – ein Werkzeug, mit dem man vorgefertigte Komponenten zu einer Anwendung „assembliert“. Was wird da zusammengefügt? 

Es werden 
•    die Geschäftsobjekte des CyberEnterprise mit der Benutzeroberfläche verbunden.
•    die Beziehungen der Geschäftsobjekte untereinander bestimmt.
•    die Teilanwendungen, die als InstantView-Code existieren (die Module des AppsWarehouse), zu einer Anwendung zusammengestellt.

Das „Instant“ im Namen verweist auf schnelle Modifikationen, Veränderungen und Zusätze im Programmcode „on the fly“. Anwendungen sollen jederzeit und ohne Risiko an veränderte Bedingungen angepasst werden können. InstantView erlaubt den Austausch von Programmcode im laufenden Betrieb. Und kleine Modifikationen können beim Nutzer einer ClassiX-Anwendung „vor Ort“ durch einen „Superuser“ direkt und sofort vorgenommen werden.

Diese Zielstellung begründet Eigenschaften, Besonderheiten und auch die Grenzen der Skriptsprache InstantView:

• InstantView ist ein Interpreter.
• InstantView-Programmcode ist einerseits eine Beschreibung der Benutzeroberfläche einer Anwendung. Andererseits besitzt InstantView Elemente einer einfachen prozeduralen, wie auch funktionalen Programmiersprache, mit denen algorithmische Abläufe beschrieben werden.
• InstantView ist objektorientiert, d. h. die den InstantView-Code strukturierenden Programm-Module besitzen Objekteigenschaften. Ein Vererbungskonzept ist eine der Grundlagen für die oben erwähnte Flexibilität.
• Mit InstantView werden Objekte erzeugt und manipuliert. Diese Objekte sind Instanzen von C++-Klassen. 
• Die Objekte bestimmter Klassen können um zusätzliche Datenfelder erweitert werden. Aus der Sicht von InstantView gibt es keinen Unterschied zwischen diesen „dynamischen Datenfeldern“ und den anderen, im C++-Klassenlayout a priori vorgesehenen „normalen“ Datenfeldern.
• Es ist nicht möglich (und auch nicht notwendig), so etwas wie eine Klasse mit den Mitteln von InstantView zu definieren. Provider Module stellen das Gegenkonzept zur eigenen, freien Klassenbildung dar.
• InstantView kennt Konstanten und Variablen. Ergebnisse einer ausführbaren InstantView-Anweisung werden an die folgende Anweisung über einen Stack weitergereicht. Der Stack übernimmt dabei eine zentrale Rolle: Er fungiert als Bindeglied zwischen den Anweisungen und steuert den Datenfluss innerhalb des Programms. Funktionen entnehmen ihre Argumente vom Stack und legen Ergebnisse dort wieder ab. Dieses Prinzip ermöglicht eine kompakte und modulare Strukturierung von Code, erfordert aber zugleich ein genaues Verständnis darüber, welche Werte zu welchem Zeitpunkt verfügbar sind.

Hier geht es zu weiteren Informationen über das System.