This repo defines a meta-model allowing to model an embedded software loaded on
a single core microcontroller.
The meta-model is framework and language independent.
It is a set of meta-classes, relations and rules dedicated to the modeling of an
embedded software.
It covers the physical software architecture and the software detailed design. Functionnal architecture is not covered.
The firsts elements defined on this page are abstract meta-classes. They allow to define basic concepts by grouping common properties of elements defined latter which are specializations from these abstract elements.
Note that the rules are inherited. If an element specializes an other element, the rules defined for the based element aplly to the specialized element.
- Software_Element
- Type
- Variable
- Parameter
- Package
- Component_Type
- Interface
- Client_Server_Interface
- Event_Interface
- Ports
- OS_Operation
- Configuration
- Basic_Type
- Enumerated_Type
- Physical_Type
- Array_Type
- Record_Type
Many meta-classes of this meta-model derive from Software_Element.
It is an abstract meta-class that defines the common attributes shared by all
the meta-classes that inherit from it.
| Attributes | Type | Description |
|---|---|---|
| Name | string of charaters | Name of the Software_Element, it shall refer to its role. |
| Description | string of charaters | Description of the Software_Element. |
The Name of any Software_Element shall be fulfilled.
It can be used to create the symbol of the corresponding implementation
element.
The Name of a Software_Element is a string of characters. Allowed
characters are a to z, A to Z, 0 to 9 and underscore. It shall start with a
letter.
To comply with most of programming language allowed symbols.
The Description of a Software_Element shall be fulfilled.
To ensure high level of understanding. Allows to easily maintain or reuse the
elements.
The aggregates of a given Software_Element shall have a different Name.
To ensure model transformation (including implementation).
Some meta-models do not allow that two elements having the same parent have the
same identifier (e.g. : AUTOSAR).
The abstract meta-class Type is specialized into several sub meta-classes.
See following chapters for details.
A Variable shall reference one and only one Type.
By definition.
| Attributes | Type | Description |
|---|---|---|
| Stream | {INPUT, OUTPUT} | Stream of a parameter, either provided to, either result of a subroutine. |
- The stream of a parameter is either INPUT or OUPUT. It does mean that "IN/OUT" parameters can not be modeled. This is because from the (abtract) point of view of the physical software architecture, a data is either necessary to perform a subroutine, either a result of a subroutine. "IN/OUT" concept is programming language specific.
An embedded software is the aggregation of many software elements.
To enable the reuse of these software elements it is suitable to group them in a
consistent set.
A package allows to group software elements.
All the kinds of elements which can be aggregated by a Package are not modeled on this diagram.
Packages aggregated within a project should not be involved in dependency
cycles.
Cyclic dependencies lead to hardly maintainable software.
A Package shall contain at least one Software_Element.
An empty package is useless.
-
A package is the atomic reusable item of a software model.
-
It should gather cohesive software elements.
A software component is a part of a software which implements one or several software functions.
The software architect shall decompose the embedded software in several software components and allocate each software function to one and only one software component.
To fit object oriented design concept, a software component shall be seen as two
linked elements : the software component prototype (the object) and the software
component type (the class).
Thereby, if the same software functions are needed several times within the same
software project, it is possible to instantiate the same component type several
times.
-
A software component shall be as consistent as possible, i.e. the implemented functions shall rely on the same topic.
-
We distinguish 3 kinds of software component types :
- The multi-instanciable software components. These components can be re-used on several projects and a single project can use several instances of the same component (e.g. : push button sensor).
- The configurable singleton software components. These components can be re-used on several projects, but each project has only one instance of them (e.g. : cryptographic server).
- The project specific singleton software components. These components are designed especially for a given project (cannot be reused) and it has only one instance of them (e.g. : system specific function manager).
-
The software functions implemented by a component type should be "high level" functions. It means domain or product specific functions, opposed to "basic" software functions which are implemented by generic classes or libraries (detailed design).
To realize its role (its software functions) a software component may need to
use functions from the other software components of the embedded software.
The communication between the software components shall be done following
predefined patterns. These patterns are the software interfaces.
An interface is a formal description of the communication pattern between
software component types. An interface defines a contract.
The software architect shall define which interface shall be realized and are used by each software component to ensure its role.
A Client_Server_Interface shall provide at least one operation.
An empty communication patern in a nonsense.
The software components hide the implementation of the functionality they
provide and simply expose very well defined connection points, called ports.
Through a "provider" port, a software component realizes one interface.
Through a "requirer" port, a software component uses one interface (realized by
an other software component).
A Port shall have one and only one contract.
By definition.
- The port mechanism allows to finely managed dependencies between components : a component can only depend on a subset of operations provided by an other one and not on all the realized interfaces.
- It also allows to realize, or use, the same interface several times.
The software component types can provide public operations that shall be called by the operating system of the microcontroller.
- An OS_Operation does not have any argument.
The software component type can provide public (read-only) attributes that allow
to configure it.
The value of these attributes shall be set at object creation (component type
instantiation) and cannot be modify later (at run time).
The Type referenced by a Configuration should not be a Record_Type.
Configuration shall be as simple as possible.
The Type referenced by a Configuration shall not be an Array_Type of
Record_Type.
Configuration shall be as simple as possible.
The Type referenced by a Configurationr shall not be an Array_Type
of Array_Type.
Configuration shall be as simple as possible.
The Default_Value of a Configuration shall not be empty.
The Default_Value of a Configuration shall be consistent with its referenced Type.
- Configuration shall be use to create configurable (either mutli-instantiable, either singleton) Component_Types.
An embedded software is implemented on a microcontroller.
A basic type is a type that can be natively handled by a microcontroller.
The meta-model defines some Basic_Types that can be used to model data :
- Basic_Boolean_Type
- boolean : boolean.
- Basic_Integer_Type
- uint8 : unsigned integer on 8 bits.
- uint16 : unsigned integer on 16 bits.
- uint32 : unsigned integer on 32 bits.
- uint64 : unsigned integer on 64 bits.
- sint8 : signed integer on 8 bits.
- sint16 : signed integer on 16 bits.
- sint32 : signed integer on 32 bits.
- sint64 : signed integer on 64 bits.
- Basic_Floating_Point_Type
- float32 : decimal encoded on 32 bits.
- float64 : decimal encoded on 64 bits.
- Basic_Characters_Type
- character : single character.
- characters_string : string of characters.
- Basic_Array_Type
- uint8_array : array of uint8 (unknown size).
An Enumerated_Type shall aggregate at least one Enumeral.
To ensure model implementation, many programming language do not allow an
enumerated data type without enumeral.
An Enumerated_Type should aggregate at least two Enumerals.
An enumerated data type which can take only value one is useless.
The Name of an Enumeral is a string of characters. Allowed characters are
a to z, A to Z, 0 to 9 and underscore. It shall begin with a letter.
To ensure model implementation, to comply with most of programming language
allowed symbols.
The Description of an Enumeral shall be fulfilled.
To ensure high level of understanding. Allows to easily maintain or reuse the
type.
The Resolution of a Physical_Type shall be set to a non-null decimal
value.
The Resolution shall be consistent with a physical value.
A Resolution equal to 0 would mean that the type allows to model a constant
equal to the Offset.
The Unit of a Physical_Type shall be set.
To ensure high level of understanding. Allows to easily maintain or reuse the
type.
The Base_Type_Ref of a Physical_Type shall be a Basic_Integer_Type.
A physical data type shall rely on a native integer data type from the
microcontroller to be able to apply the conversion rule.
The Offset of a Physical_Type shall be set to a decimal value.
The Offset shall be consistent with a physical value.
The Multiplicity of an Array_Type shall be a strictly positive integer
value.
Nonsense.
The Multiplicity of an Array_Type should be greater than 1.
An array of one element is not really an array, just a kind of "typedef" to
redefine an existing type.
The association with a Data_Type (through Base_Type_Ref) is mandatory.
Obvious.
The Base_Type_Ref of an Array_Type shall not be itself.
Nonsense.
A Record_Type shall aggregate at least one Field.
To ensure model implementation, many programming language do not allow a
structured data type without field.
A Record_Type should aggregate at least two Fields.
A structure with only one field is useless.
A Field shall not reference its owner.
To ensure model implementation, some programming language do not allow
auto-reference.