|
|
The intermediate language is an architecture description language with a modular meta model. The meta model comprises a relatively small core and several modules that extend the core and other modules. Modules can be active or inactive for a model. The core and the active modules together build the meta model of a model. Inactive modules are not part of the meta model of a model.
|
|
|
|
|
|
Activating modules can exclude other modules from activation, or require to activate other modules. This relationship is expressed in the [module dependency model](https://s3gitlab.paluno.uni-due.de/ADVERT/core/tree/master/Intermediate%20Language/il.modules) (to open with [Remidemmi](https://sse.uni-due.de/remidemmi/)). The [modules](Intermediate_Language/IL_Modules) are described on a separate page.
|
|
|
Activating modules can exclude other modules from activation, or require to activate other modules. This relationship is expressed in the [module dependency model](https://s3gitlab.paluno.uni-due.de/ADVERT/core/tree/master/Intermediate%20Language/il.modules) (to open with [Remidemmi](https://sse.uni-due.de/remidemmi/)).
|
|
|
|
|
|
The following figure shows the dependencies between the modules using the OVM notation.
|
|
|
## Core
|
|
|
The intermediate language comprises a core and modules. The core comprises meta elements that are central for architecture specifications with this language. The following figure shows the core's meta elements:
|
|
|
![Unbenannt](/uploads/0e55599a7077c9315dd342f704f328f8/Unbenannt.png)
|
|
|
|
|
|
## Modules
|
|
|
For different architectural features and styles, modules exist for the intermediate language. The following figure shows the dependencies between the modules using the OVM notation.
|
|
|
![il](/uploads/411da6ae619388105e0405e2f6a46d24/il.png)
|
|
|
|
|
|
In the following sections, the modules are briefly explained.
|
|
|
|
|
|
### Component Hierarchy
|
|
|
These modules consider the hierarchy of components.
|
|
|
|
|
|
#### Flat Hierarchy
|
|
|
Component types and their instances are all located in the same namespace. There is no hierarchy. An example is Enterprise JavaBeans (EJB).
|
|
|
|
|
|
#### Shared Hierarchy
|
|
|
Component types are all declared in the same namespace. Component Instances are defined in a hierarchy. An example is the Palladio Component Model (PCM), where all component types are declared in the repository on the same level. Component instances in PCM are declared hierarchically in the system model and the composite structure model.
|
|
|
|
|
|
#### Scoped Hierarchy
|
|
|
Component types and instances are built hierarchically. Each component type declares its own namespace, in which component instances and other component types can be defined.
|
|
|
|
|
|
### Instantiation
|
|
|
These modules consider different types of instantiation of components.
|
|
|
|
|
|
#### Fixed
|
|
|
The amount of instances of a component type is declared statically in the model, and cannot change at run time.
|
|
|
|
|
|
#### Per-Session
|
|
|
For each user session a new component instance is created.
|
|
|
|
|
|
#### Pooled
|
|
|
A set of instances can be constructed at run time. When an instance is requested, an algorithm decides which instance to return.
|
|
|
|
|
|
### Statefulness
|
|
|
These modules consider whether a component type is stateful or stateless.
|
|
|
|
|
|
#### Stateful
|
|
|
A stateful component can declare attributes, which can change over time. Typically such component types are used to hold application wide or session wide information.
|
|
|
|
|
|
#### Stateless
|
|
|
A stateless component is considered to be shared throughout the application by different users or clients.
|
|
|
|
|
|
### Connectors
|
|
|
Connectors connect provisions with requirements. The "Connector" profile declares the existence of a connector type and multiple connector instances. The connector type and instances are abstract in the context of this profile and need to be refined using subsequent profiles (e.g. 1on1 synchronous procedure call).
|
|
|
|
|
|
Connector types will be used to connect component types with each other. Connector instances will be used to connect component instances with each other, following the constraints given by their types.
|
|
|
|
|
|
#### 1on1 Synchronous Procedure Call
|
|
|
A 1on1 synchronous procedure call connector connects 1 requirement with 1 provision via proceduce calls, operation calls or method calls.
|
|
|
|
|
|
#### 1ton Events
|
|
|
An event dispatcher connects an arbitrary number of message issuers with an arbitrary number of message receivers.
|
|
|
|
|
|
### Datatypes
|
|
|
Data types are named elements that can be used to type e.g. operation parameters. Data types are can have sub- and super types. They can own operations with parameters.
|
|
|
|
|
|
### Deployment
|
|
|
Deployment fragments are named elements that represent a deployable unit of an application, such as an executable, a library, a JAR file or something similar.
|
|
|
|
|
|
### Interface Hierarchy
|
|
|
These modules consider the hierarchy of interfaces.
|
|
|
|
|
|
#### Shared
|
|
|
In shared interface hierarchies, all interfaces are declared within the same, global name space.
|
|
|
#### Scoped
|
|
|
In scoped interface hierarchies, interfaces are declared within the scoped of component types.
|
|
|
|
|
|
### Interface Types
|
|
|
These modules consider the type of interfaces.
|
|
|
|
|
|
#### Events
|
|
|
Event based interfaces declare events that they can issue, when they are declared provided with the 1ton Events profile, or that they can react on, when they are declared required with the that profile.
|
|
|
|
|
|
### Operations
|
|
|
Operation based interfaces are known e.g. by most object oriented programming languages. They declare operations that can be called by users. Operations can have parameters and return types.
|
|
|
|
|
|
### Namespaces
|
|
|
Namespaces are hierarchically organized, named elements. Interfaces and component types can be organized in namespaces to collect semantically coupled elements.
|
|
|
|
|
|
### Quality
|
|
|
These modules consider quality concerns of the architecture. They are in an early version and should not be considered usable at the moment.
|
|
|
|
|
|
#### Core
|
|
|
The quality core defines that an operation has a general resource demand.
|
|
|
|
|
|
#### Security Levels
|
|
|
The security levels module defines the information necessary to implement the "secure information flow" concept. Component types and name spaces can define security levels in partially ordered sets (POSET).
|
|
|
Interfaces and operations within that name spaces can require a minimal security level by the user for being allowed to execute.
|
|
|
|
|
|
#### Timing
|
|
|
The timing module describes a time based resource demand for operations. |
|
|
\ No newline at end of file |