first meta- – ISA\\Metamodel

Parent

LL

Data
Metamodel
Aliases None.
Information This establish the metamodel thru Metaclasses. This means all the elements of the languages. These metaclasses derives of Concept .
Explanation
The sizing limits are often specified as an effective integer value in . This could appear strange when compared to the usual freedom the designers and especially developers have with other languages. So this could be seen as not very “Ideal”. However there are strong arguments to do that this way. Bellow are some references (there are so much) to consolidate the accuracy of this approach. These references are followed by decision diagrams justifying the limits values.
So yes, in an ideal architecture, the modules built by humans should not be in-considerably big. To ensure it, having fixed limits is necessary, because they force to improve the design of the systems.
At the end of this explanation, some statistics consolidate this approach.
References :
The maximum number of components in an
Metamodel Assembly

The maximum number of dependencies in an

Metamodel Assembly
The maximum number of Feature in an Module
Metamodel Assembly
The maximum number of settings in an
Metamodel Assembly
In order to illustrate the accuracy of the size limitation policy, it is also worst noting that on a real IT system with more that 10 years of production experience, the statistics revels the following facts:
  • More that 93% of the classes have less than 30 fields.
  • The average is measured at 11,5 data features per class.
  • When analyzing the 13 classes that have more than 30 fields, each of them can be better designed or worse have severe flaws.

Metamodel Assembly

 
data
Edition
Version 1
Country None.
Language  None.
Number  1
Dependencies None.
Inhibit all invariants False.
Scope Ideas.
Diagram

 

 

Classes
Abstract data type
Information An Abstract data type is a Type with its set of Features supporting the  functions, axioms and preconditions.
Fields
Shared members This members are shared by all instances of the Abstract data type on a Node.  This means that there is at most one shared per run-time Node.

For example, members of a  are instantiated at the Class level.
Unshared members This members are specific to each instances of the Abstract data type on a Node. This means that there is one set of members for every instances on a run-time Node.

For example, members of the that are instantiated at the Object level.
Abstract data type
Assembly
Information An Assembly is the delivery unit of software.
Fields
 Dependencies The list of Assemblies the Assembly depends on.
Attribute
Settings
 The list of named changeable parameters roots for this Assembly.

The modification on this attribute should typically not require administrative access right. A modification never imply a reload of the Assembly.
Configurations
 The list of named fixed parameters roots for this Assembly.

The modification on this attribute typically require administrative access right. The modification could imply a reload of the Assembly.
Inhibit all invariants
 Allows to disable all the invariants, preconditions and post-conditions in order to improve efficiency. This attribute is typically set to True when delivering the Assembly to a client.
Property
Children The names of the Assembly Components for the named ones.
Scope
 The process step of this Assembly.
Relationship
assemblage
components
The set of components the Assembly contains in a given Edition.
contextualization
situation
The set of contextual elements giving information on the components the assembly contains in order for it to be consistent.
Invariants
Name
Scope is immutable.
Information The process step of a Assembly cannot be changed because artifacts are specific to a step.
Name  All components and dependencies of the Assembly share its process step.
Information This rule prevent artifact step mismatch.
Name
The Zone Id of the Assembly is mandatory.
Information The Assembly is the delivery unit. It is not acceptable to deliver without having a registered zone. 
Name  Assembly name is unique within a Zone for a given Edition.
Information The couple Zone, Edition defines a namespace for the assemblies.   This check can only be done if the invariant above is passed.

This does not means that for an Edition hierarchy, an Assembly can not have the same name. At contrary in fact it is recommended to always use the same name, because it is fundamentally the same artifact but in several variants, and to only rely on the Edition properties to distinguish these variants.
Name
The Edition of components must be compatible with the Edition of the Assembly.
Information This rule checks several consistency  like having a Class specific for France while the Assembly is dedicated to China.
Name
The Edition version of of a given Category is unique within the Assembly
Information All of a same Category must have the same version in order to avoid delivery of Class of several version which make no sense since the version N is supposed to replace a version N-1. However, for a given edition version, several variant can be delivered together for different countries for .
Notes
Kind Explanation
Text Assembly also derives from Module, contrary to what B. Meyer recommends, because it is also a engineering major .

The Information Systems Artifact: A Conceptualization Based on General Systems Theory
Assembly
Category
Information A Category tells the meaning of a filiation, the semantic they share whatever their Editions.
In LL, a Category is the equivalent of a Class in other languages that do not support versioning like Java or C#. The Class in LL is in fact a variant of a Category. The variation axis being the Edition version, language, country and the number.
Category
Context
Information A Context give a general a global information on other elements, therefore they are not necessarily linked to an Edition.
However, to make a Assembly consistent, Context instances need to be incorporated in deliverable. Even if they are of different versions, they are not supposed be be different in essence.
Context
Classifier
Information A Classifier represents a classification of objects according to a subset of their features.
It is both a Type and a Module.
Fields
Abstract Specify if the Classifier can be directly instantiated or if every  of the abstract Classifier shall be an of one of its specializations.
Hook
 Specify if the Classifier require the hook mechanism. Typical classes requiring a hook are those relying on runtime events or aspect injection.
Category
 The classification, beyond editions, that the Classifier manifests.
Invariants
The semantic id cannot differ from the Category one
The constraint guarantee that all Classifier of a given filiation share the same meaning
Two Classifiers of the same Category cannot have equals Editions
Ensure that only one given Edition of a Classifier filiation can exist, this constraint avoid edition collision
Note
Kind Explanation
Text The hook mechanism is the LL way to support both dynamicity  and performance for runtime event processing and aspect injection.

Problematic

To be dynamic, it is needed to be able to add event observation on any Object both at design and runtime. The static way is quite easy and implemented in many usual languages like C# or Java. Adding it at runtime by dynamic inheritance can be very costly because of extra code that could impact all Objects even those not requiring this feature, i.e the very large majority of them.

The question of adding dynamically a transversal feature as in Aspect face the same problem.

Solution

The solution is to have a single hook mecanism on object in all cases a dynamic behaviour has to be added or removed to an Object.

When a not-hooked Object have the addition of a class (or Aspect injection) that has the property Hook set to True, all the Classification Classes the Object belongs to are recompiled in adding the hook parts (if not already done on the Node). The class regular compiled code is enriched of a hook holder at each sensitive place (method entry, method exit, etc.) and of a hook associative table. This class has new compiled variante with its proper Sbyte Id. The Object is reclassifier to belong to that variante.

If the Object hooking is no more required, the reverse mechanism is applied.

This solution allows to have the better possible performance on regular classes (optimization like inlining are possible) and to pay for the hooking feature only on Objects that require it.
Classifier
Edition
Information
An Edition represents a variant in an engineering artifact like Classifier or Assembly.
The Editions are in hierarchy for a given Version from the more general to the more particular. This allows to retrieve a more general artifact edition, up to the version root edition.
Note
Kind Explanation
Text The edition is linked to a deliverable artifact thru its usage by the Module metaclass. Its Version property gives the version of that deliverable artifact. It is public and managed by engineers.
It acts a version number in the common sense.All Object, and a metaclass is an Object, also as an Object version thru its Identifier. This version is updated each time the metaclass is updated and persisted. It is not directly visible and managed by the system.
It acts as a build number in the common sense.
Properties
Version
The version of the artifact thru an ordered integer.
Country
ISO 3166-1 alphabetic 2 characters code.
Language
ISO 639-3 alphabetic code.
Number
Number following a class provider own convention. Could be use for to limit the Class capacity by software option number.
Edition
Metaclass
Information This class is the root of any LL metamodel class.
A Metaclass is an element of a .
As using Metaclasses is like using molecules in chemistry, Elements are the elementary elements as atoms are to physic.
Fields
Name The name of the Metaclass.
Aliases The alternative names usable for this Metaclass.
Information The general documentation of the Metaclass.
It describes what is the element.
Typical usage: Software developer public documentation.
Semantic id Global semantic id attributed by some central authority like Wikipedia.
This id allows to multilingualy make inference on objects.
The authorities or others can have a semantic graph of terms ids to increase the meaning capabilities.
For example, with this kind of ids, translation can be done automatically in a very accurate manner.
Invariant
Name
Name cannot contain LL punctuation or special characters.
Information The name of a Metaclass is used in the LL language and must not be confused with language punctuation characters. This is also applicable for conventional special characters like $.
Metaclass
Module
Information A Module is basic unit for building a system.
Modules are identified, specified, implemented and joined by engineers to compose a complete system version.
Note
Kind Explanation
Text Distinct Modules having the same path typically are the same, but in different Editions. However they do  not necessarily share the same semantic. It is the Category that tell the meaning of a Classifier, the one they share whatever their Editions, so the Path that can changes  after a software refactoring.
Property
Path The full qualified path of the Module . This path defines a namespace. The Edition of the current Module is the final part of the Path.
Examples:
  • An Assembly : \e-Companion Software\HRM\4\BE\fra\
  • A Class : \e-Companion Software\HRM\4\BE\fra\Employee\2\
Edition   The Edition of the Module.
Invariant
Name
Define a namespace for the named items
Information
Define a namespace to avoid unauthorized name collision. For a given path several Features could not have the same name, except in some cases where name overloading is authorized.
Module
Nomenclature
Information A Nominal that is also a Module in the metamodel allowing it to be a major modeling artefact.
Nomenclature
Nominal
Information Transposition of the Nominal concept in the Metamodel.

Remark: Direct instances of this class are part of the LL model, since instances of Nomenclature and of Sequence are part of the user model.
Invariants
Name
The Shared members must contains a `Names: Literal [2..30]`
Information  The Nominal must specify a list of Literal forming the name value domain.
Explanation The maximum number of name a nominal can have is limited to 30 because it is the conclusion of study : The maximum number of Feature in an Module. If a named artifact needs have a wider extend a dedicated type have to be defined by the designer.
Name
Each Name is unique among Names
Information The list of Names must have duplicate.
Nominal
Note
Information
A text associated to a model element.
Fields
Metaclasses The Metaclasses the Note is linked to.
Kind
 The kind of the Note.
Text
 The text of the Note.
Note
Numeral
Information Transposition of the Numeral concept in the Metamodel.
Numeral
Ordinal
Information Transposition of the Ordinal concept in the Metamodel.
Ordinal
Primitive
Information A Primitive is the metaclass for Elements (built-in Types).
Primitive
Sequence
Information A Nominal that is also a Module  in the metamodel together with a relationship of order (Ordinal) allowing it to be a major modeling artefact.
Sequence
Type
Information
A Type realize the concept defining a collection of objects characterized by functions, axioms and preconditions.
  • Functions are the operations applicable to a particular type.
    Example: On the Natural type, you can add or multiply with another Natural.
  • Axioms are the constraints, the invariants that always applies to the Type thru its functions giving their preconditions. In other words, the axioms state the minimal set of properties of the Type values.
    Example: For the Natural Type these axioms are those of Peano.
  • Preconditions defines the applicability scope of a Type function.
    Example: Suppose a divide function of the Natural Type , a precondition on that function should be that the denominator value must not be 0.
Type
Valuable
Information Instances of a Valuable are identified only by their value.
All instances of a Valuable with the same value are considered to be equal instances. So they are neither Object nor Classifier, even if they also categorize real world objects.
Valuable
Wellformed metaclass
Information A wellformed metaclass  has a significant name and is regularly documented.
Invariants
Name
Name is mandatory and must be valued significantly
Information To be well formed, a Metaclass must have a name . This invariant is needed because some Metaclasses are anonymous (multiplicity 0..1).

The name should have at least 3 not blank characters. It must begin by a letter.
Name
Information is mandatory and must be valued significantly
Information To be well formed, a Metaclass must have be documented. This invariant is needed because some Metaclasses do not need a documentation because their name is self descriptive (multiplicity 0..1).

The information should have at least 1 sentence of at least 2 words and 5 not blank characters.
Wellformed metaclass
Assemblies

 

 

Version and status

Version Date Description Status
V1R1 29-Dec-17 Initial. Candidate

Related posts:

  1. Elements Assembly
  2. Relationships Assembly
  3. Containment Assembly
  4. Identity Assembly
  5. Textuals Assembly
Tags: Assembly, Class, Classifier, Component, Instance, LL, Model, Object, Paradigm, Process, sbyte, Scope, State, Universe, Versioning

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.