Loading...
 

Getting started

Getting started

This page provides a step-by-step introduction to the central concepts and tools of the ClassiX system. The focus is on the standardised enterprise model, which uses abstracted business objects to create a flexible yet stable basis for operational applications. The clear system architecture with the CyberEnterprise as the foundation and the object-orientated database enable direct access to related data structures without complex table links.

In order to ensure the comprehensibility and clarity of code - both for yourself and for third parties - the great importance of adhering to the ClassiX programming guidelines is emphasised at this point. All ClassiX applications follow these guidelines. Among other things, this results in the uniformly designed user interfaces of all applications. The guidelines are continuously referred to during the tutorials.

Important note: This introduction provides you with an initial overview. In order to fully understand the system and use it efficiently, we recommend that you read the following pages carefully:

  • Deepening your understanding of the system gives you a deeper understanding of the basic architecture and concepts.
  • The programming guidelines are essential for consistent and maintainable development in the ClassiX environment.
  • In the tutorials, you will be guided through typical use cases in a practical way and learn how to use the system step by step.

Foreword

ClassiX is introduced as an object-orientated system for the development of business applications, which differs from classic systems through dynamic business objects and a central data stack. It is supplemented by the AppsWarehouse, a collection of ready-made applications. The underlying enterprise model, the CyberEnterprise, maps operational structures in an abstract and expandable way.

Classix

A fully object-orientated system for creating business applications. It differs from conventional systems in several fundamental ways: Instead of classic, hard-wired logic, ClassiX is based on a dynamic interplay of business objects, immediately executable application code and a stack-based programming model.

ClassiX therefore initially presents itself as a technical solution, a construction kit for application development, so to speak. However, it should be emphasised from the outset that ClassiX does not see itself as a pure development system, but with the AppsWarehouse, the "Application Warehouse", already has an extensive library of finished, business applications.

ClassiX therefore also sees itself as a complete solution for companies in any industry in which the completely new development of applications should actually be the exception.

However, this tutorial begins - to promote overall understanding - with the development of a sample application from scratch.

The ClassiX tutorials teach the application developer the basics necessary for working with ClassiX. Because ClassiX differs significantly from classic software systems in its structure and behaviour - among other things through direct interaction with a central data stack, modular app components and dynamically changeable processes - this introduction should first provide an overall picture and explain the special features. If further literature is available on individual topics, this will be noted accordingly below, with a direct link where appropriate.

We start with a brief insight into the system architecture of ClassiX, followed by a short presentation of the underlying business model. InstantView is then introduced by highlighting the most important features of this application scripting language. Finally, there is an overview of the individual tutorials.

The introductory texts and digressions on the ClassiX system and InstantView are intended as a supplement, they are not a prerequisite for the following parts of the tutorials. There, an example application is set up step by step. At each level, the only prerequisite for understanding is knowledge of the previous levels.

Company model

The CyberEnterprise has already been presented in advance as a cybernetic representation of a company and thus as the company model on which the ClassiX system is based.

The CyberEnterprise contains all the classes required to describe the business world. This class tree is modelled at C++ level. The structure of the classes is kept as abstract and simple as possible. As a result, ClassiX manages with around 300 classes. The first tutorials deliberately start with very simple programme examples (mapping of persons and family relationships), which do not necessarily originate from the business world, but are part of the real world.

All classes are derived from CX_CLASS . They can be divided into three main categories:

1) Basic objects (primitive and intelligent data types)
These are the basic objects such as:

2) Information objects (Information Objects)
These are descriptive objects such as

All information objects are derived from CX_EXPANDABLE - i.e. they can be extended.

3) Business objects (Business Objects)
These are also derived from CX_EXPANDABLE (via CX_STRUCTURED). Business objects are in turn subdivided into real objects (business partners CX_PARTNER and things CX_ITEM (tangible objects)) and concepts (intangible objects).

By "terms" we mean, for example, the roles of an object: a business partner can have the roles of customer, supplier, manufacturer, etc. in both single and multiple forms. Cost centres, company codes and work groups, for example, are also designations for abstract terms.

4) Documents (Transaction Objects)
Transaction objects are classically referred to as master data, while transaction data are, for example, orders, invoices or goods receipt documents. This transaction data is modelled in ClassiX as objects of the CX_TRANSACTION class and its derived classes.

5) Accounts (monitor objects)
Accounts - together with the set of rules for transaction descriptions - are the central evaluation tool for documents(CX_TRANSACTION). Whether accounting, inventory or time management, any statistics, transactions or business processes, everywhere you have to deal with an "account assignment" of documents or transaction data.

We established at the beginning in the premises that all companies are basically the same in the company model. Of course, this only applies to a basic structure in abstraction. Companies can certainly name business objects differently or use different characteristics of their business objects.

Classes derived from CX_EXPANDABLE can therefore be extended by so-called dynamic data fields, and new classes (so-called "pseudo-classes") can be derived, i.e. the classification scheme of the business objects can be extended as required.

Introduction to the system

This brief introduction to the architecture of ClassiX must be preceded by three premises for better understanding:

  1. All (business) organisations have the same basic structure. This presupposes - for the digital transformation of each individual company - a high degree of abstraction of the company and its business processes. ClassiX has developed these abstract business objects, which have been in use for decades and have proven their worth.
  2. All business objects together form a standardised, digital company model, which is the basis of all applications in ClassiX.
  3. The individual differences between the companies are quickly implemented through simple dialogue adaptations, rule-based business process characteristics and flexible data structures. This is guaranteed by the ClassiX platform, as it was designed for constant change and thus for the continuous improvement of a company's processes (CIP).

The focus of development with ClassiX is therefore on the individual adaptation of dialogues and processes with the predefined business objects and standard apps from the AppsWarehouse.

Architecture

The levels of the ClassiX architecture are clearly separated from each other. The lowest level is the enterprise model. This is the cybernetic representation (CyberEnterprise) of a company.

ClassiX provides the application developer with the InstantView scripting language as a tool for visualising and networking the data. InstantView is also used to write cross-entity procedures(providers) and to control which objects are to receive which dynamic data fields.

The following tutorials will therefore mainly deal with the use of this scripting language to develop the user interface and extend the data model.

After an elementary introduction to how a ClassiX application can be developed with InstantView - from scratch - the entire existing application library, the AppsWarehouse, is presented. With the "Application Warehouse", ClassiX already has an extensive collection of ready-made dialogues (-> Applications). These can then be used to compile complete customised application solutions.

MorhpIT provides browser-based application solutions written with InstantView in an ergonomically optimised way.

The documentation for the architecture, the CyberEnterprise, the InstantView scripting language, the AppsWarehouse and MorhpIT provide a detailed insight into the individual layers of the Classix architecture.

ClassiXArchitektur De

Database

At ClassiX we work with an object-oriented database, which differs fundamentally from the usual use of relational databases. While in relational databases information is stored in various tables organised according to the principle of normalisation, the object-oriented model in ClassiX combines related data into so-called objects. With this approach, all relevant information is directly accessible without having to navigate through multiple tables using foreign keys.

Instead of distributing data across different tables, ClassiX's object-orientated database allows you to work with a single "entry point". A hit gives direct access to all linked data, as each object "knows" which other data or objects belong to it through back-relationships.

In contrast to relational databases, in which complex data structures are created through many links between tables, all components of a unit are immediately available in an object-orientated database. This makes it possible to handle significantly more complex data sets efficiently without the database being slowed down by extensive links.

InstantView

InstantView plays a central role in working with the ClassiX system and is therefore the focus of the entire tutorial.
The previous section gave an idea of how the CyberEnterprise presents itself as a set of business classes with a high degree of abstraction.

The digital mapping of a company begins with the business objects , but no applications are created yet. So we have the individual parts, but we need a tool that can be used to create finished applications.

InstantView is an application scripting language that is used to bring the business objects within application modules (apps) to life. The library of existing application modules, the AppsWarehouse , appears as a comprehensive collection of ready-made assemblies that only need to be put together to form a complete application. InstantView is also responsible for this.
InstantView - a tool used to "assemble" prefabricated components into an application. What is being assembled?

It is
- the business objects of the CyberEnterprise are connected to the user interface.
- the relationships between the business objects are determined.
- The sub-applications that exist as InstantView code (the modules of the AppsWarehouse) are assembled into an application.

The "Instant" in the name refers to quick modifications, changes and additions to the programme code "on the fly". Applications should be able to be adapted to changing conditions at any time and without risk. InstantView allows programme code to be replaced during operation. And small modifications can be made directly and immediately by a "superuser" "on site" by the user of a ClassiX application.

This objective explains the characteristics, special features and also the limits of the InstantView scripting language:

  • InstantView is an interpreter.
  • On the one hand, InstantView programme code is a description of the user interface of an application. On the other hand, InstantView has elements of a simple procedural as well as functional programming language with which algorithmic processes are described.
  • InstantView is object-oriented, i.e. the programme modules structuring the InstantView code have object properties. An inheritance concept is one of the foundations for the flexibility mentioned above.
  • InstantView is used to create and manipulate objects. These objects are instances of C++ classes.
  • The objects of certain classes can be extended by additional data fields. From InstantView's point of view, there is no difference between these "dynamic data fields" and the other "normal" data fields provided a priori in the C++ class layout.
  • It is not possible (and also not necessary) to define something like a class with the means of InstantView. Provider modules represent the counter-concept to your own free class creation.
  • InstantView recognises constants and variables. Results of an executable InstantView instruction are passed on to the following instruction via a stack . The stack plays a central role here: it acts as a link between the instructions and controls the data flow within the programme. Functions take their arguments from the stack and store results there again. This principle enables compact and modular structuring of code, but at the same time requires a precise understanding of which values are available at which point in time.

Click here for more information about the system.