Derivation

Action of producing one thing mechanically from another thing

Introduction to the notion

Derivation plays a key role in the Praxeme method. It provides a powerful accelerator in the transformation chain that covers all the aspects, and a guarantee that the technical system will be aligned with business needs. This approach complies with the MDA (Model Driven Architecture) standard published by the OMG (Object Management Group).

The models maintain relations that have to be clarified. The job of clarification takes place first at the relations-between-modeling-element level. Inside each aspect, the elements are linked to each other by relations depending on their categories and described by the metamodel. Added to which are the relations between packages regarding the reuse of generic or shared elements. Between the aspects, we can distinguish three types of relations: projection, justification and derivation (a downstream element results from the mechanical product from an upstream element). In all cases, the relation between the elements is kept as a traceability link.

An example: derivation channels from the semantic model.

A good example of the power of this mechanism can be seen in the way it is exploited by the semantic model.

The semantic model offers several immediate contributions:

  • the formal expression of business fundamentals (capitalization of knowledge, knowledge management),
  • the abstraction effort (more genericity, and so a more compact model),
  • universality (a pathway to convergence).

The semantic model is also the starting point for several derivation channels, which reuse its modeling elements, either as a design support for other aspects, or to draw up other modeling elements.

Praxeme makes provision for four derivation channels:

The pragmatic and logical aspect guides detail the derivation and design procedures, linked to these channels.

Another example

For those who work in IT, the term “derivation” evokes more the production of the software model, or even the software itself (in this case, we refer to “generation”). In the Praxeme approach, developing software means translating a specific logic into a computer language, through the dictionary provided by the technical architecture. This therefore involves three aspects:

  • logical (the logical model is the organic and formal specification of the software, technical choices aside);
  • technical (the technical architecture, strictly speaking, sets the choice of technology, language and measures… and provides the instructions to translate the logical model);
  • software: firstly as the software model then the code itself, largely generated.

The translation from logical to software is made up of two types of instruction: on the one hand, derivation rules, able in the main to be automated; on the other hand, programming rules that the programmer will have to apply.

Comment

The result of this action is the derived element. Generally, the thing produced belongs to an aspect that depends on the aspect to which the origin of the derivation belongs.

Related terms: synchronization model/code, MDA, aspect.

 

Related - items

Bookmark the permalink.

Comments are closed.