Get started
Employees" Qualifications:
-
For solving > 90% of the practical problems that arise while adapting an enterprise’s cybernetic model in dia$par.Matrix, junior level employee with the following skills are needed:
- C# 6.0 (object oriented programming, LINQ, asynchronous programming);
- SQL
-
In cases of extreme use (overloading combined with the uniquely complex business-logic of dia$par.Matrix), developers may need additional resources for database development from Oracle Database EE (or a very similar Enterprise DB).
-
Customizing a client’s application is no different than developing any other application on a given platform (Windows, Android, iOS, specialized operating systems).
-
If developing desktop dia$par applications for clients on Windows, experience using Windows Forms will be useful.
When using browser interfaces, a web stack (HTML, CSS, JS, React/Bootstrap) is needed.
The approach of the cybernetic model
The cybernetic model consists of five distinct classes:
- Value chains (mchains)
- Coherent pack of changes to the model (mpacks)
- Projections of the model’s data (mfaces)
- dia$par’s reactions to different external and internal events
- classic dictionaries.
Consequently, a model engineer interfering with the model’s logic will produce changes in the objects of these classes.
The engineer introduces applicable changes into the compositional blocks in dia$par’s software system.
If one looks a little deeper into the details, then writing the model also uses:
-
tableparts
-
linktables
-
State of the mpack in the value chain (mstep)
-
constants
-
localization structures
-
and about 40 more types of objects with technical purposes
The structure and description of these objects forms the metadata for dia$par.Matrix's concrete configuration.
Dictionaries
... are used for storing different types of statical data.
As a rule, of real-world objects.
In the simplest example, a dictionary in the database represents one table. For example, "Stores."
Mpacks
Compact block-containers of logically connected objects (possibly empty) move along the steps (msteps) of the value chain (mchain), changing their properties until they become objects of a different type.
A fairly complex class with a rich internal structure. Their capacity is a result of strict, practical demands and the heterogeneity of the data stored.
The worst case is any accounting document.
Mfaces
In the simplest sense, a parallel can be drawn between an inventory sheet and the mface (the idea of accounts).
Parallel between OLAP and mface — the idea of the cube.
mfaces use measurable markers from the model for storage and inventory. For example, the remaining goods in storage and the debts of other parties.
Equants
The history of mfaces is the set of changes, made by quants in the evolution of mutual mapping — equants.
The extreme case of an equant would be an accounting entry.
In OLAP terminology, the sum of equants is a table of facts.
Mflexes
To all events, occurring in the perimeter of the meta-system, dia$par reacts.
The scripted reactions to events are called mflex (reference to reflexes, the biological analog of mflexes).
All dia$par events fall into 21 types.
Accordingly, dia$par's mmizer has 21 types of mflexes, each of which has its own unique features.
So, for example, quants of dia$par's evolution and exclusively generated by one type of mflexes — traflexes (reflexes, developed during mstep-changes of a concrete mpack container, with properties as a copy of an mpack, and the properties of objects which it contains).
The frequently used dia$par events which occur during business-logic (in brackets the shown names of the respective mflexes):
-
servicing web-requests according to SOAP/REST protocols (oflex)
-
generating equants (traflex)
-
handler for mpack evolution events (mpack mflex)
-
event handler for the evolution of directories (dictionary mflex)
-
mflexes, caused by the user for a given mpack, mchain or dictionary (deflex)
-
compleX face (xface mflex)
-
mlex for calculating the analytical side of mface (fprocessor)
-
the quanta validator (fvalidator)
-
Execution according to scheduled events (sheflex)
-
scripted logic for client interfaces (rflex)
The type of event or mflex (in this case, they are equivalent) determines the method of that initiates the answering reflex (the event reaction), and binding the scenario to data, metadata and other compositional blocks of dia$par.
Abstractly formed business-logic for managing enterprises is practically transcribed in the mflex, developed in accordance to events or scheduling.
Actually, the applied development
In general, the activity of the applied analyst-developer in dia$par is a cycle:
-
to project the logic on Changes to metadata in the cybernetic model (directories, mchains, mfaces, etc), to formulate and implement deltas
-
to program changes in business-logic and decompose them by changes to the specific mflexes
-
to implement the logic of effectors — special forms to display or enter data and oflexes
-
to check (including with regressive tests)
-
to pass for testing (in the case of errors, correct and retest)
-
uploading changes into the working configuration of the model
When implementing a project, the prepeartory stage of moving to dia$par, changes are the result of bringing a base version of dia$par.Matrix from distribution to a concrete enterprise.
Mflex code is written inline in C#, the editor supports AutoComplete (analogous to IntelliSense).
The proprietary control system allows simultaneously having any amount of parallel configurations of a single enterprise in dia$par.Matrix.
An independent team of developers can work on separate configurations without affecting the work of other teams.
It is important that all the configurations of dia$par.Matrix work with the same set of real data.
That, when combined with development of traditional ABC systems, brings an additional contribution to the effectiveness of dia$par developers, in this case, at the testing stage.
To commit changes in the model's working version, press a single button in the developer's interface.
Another advantage of a built-in system is that it is extremely easy to understand which changes have been made (tools for viewing structured diff on model objects, etc).
The screen logic of the base desktop-client is implemented in the form of a WinForms application.
Design can be done however desired; for example, in VisualStudio.
