CompArch Modeling Language
The CompArch (short for Component Architecture) modeling language is defined by the metamodel depicted in the following figure. It is used to model the architectures of individual or multi-tenant software systems.
An example for a multi-tenant system is mRUBiS, which is a marketplace that hosts multiple shops where each shop belongs to a tenant and has its own architecture. In such an example, all shops share the same component types but each shop has its own components (i.e., instances of component types) that can be individually configured, that is, each shop has its own architecture isolated from the architectures of the other shops (cf. multi-tenancy). Nevertheless, the CompArch metamodel allows describing software systems where a tenant may run components of different types than other tenants as well as just a single individual software system that we consider as a multi-tenant system with one tenant.
The metamodel contains the following elements that are structured into five groups:
- General Elements
- Type Level
- Deployment Level
- Runtime Level
- Annotations
There are two general elements that are colored gray in the figure of the metamodel.
Abstract super class for all model elements that describe an architecture. The uid is a unique identifier of the element. Each architectural element can be assigned a criticality that defines the how critical is the element for the operation of the architecture.
Subclass of ArchitecturalElement.
The architecture of the overall platform with an arbitrary name. It is the root element of the model and contains all ComponentTypes and InterfaceTypes as well as the Tenant architectural description.
This level describes artifacts resulting from the development phase (such as .class and .jar files), for example, a component type (a .jar file) can be instantiated and deployed multiple times. The type level elements are colored blue in the figure of the metamodel.
Subclass of ArchitecturalElement.
A component type with a name and an optional reliability defining the reliability of this component type. The instantiate() operation instantiates a ComponentType to a Component.
Subclass of ArchitecturalElement.
A type of configuration parameter for a ComponentType. Each parameter type has a name, a type, and a defaultValue. The type defines the data type of the defaultValue.
An example for a parameter type is the value-added tax (VAT) where the name is "VAT", the type is "java.lang.Integer", and the defaultValue is "0.19".
Subclass of ArchitecturalElement.
An interface type that can be provided or required by a ComponentType. The fqName refers to the fully qualified name of the interface type (e.g., the fully qualified name of a Java interface).
Subclass of ArchitecturalElement.
Specification of individual methods as part of an InterfaceType. The signature refers to the signature of the method.
This level describes a specific architecture of a tenant's software system, that is, components that are configured and deployed. Configuration of a component includes setting values for its parameters and connecting its required interfaces to provided interfaces of other components. The deployment level elements are colored green in the figure of the metamodel.
Subclass of ArchitecturalElement.
A Tenant describes the architecture of a software system running on the platform. Each tenant has an arbitrary name and it contains the Components that constitute this software architecture.
In other words, each tenant groups the components that comprise the tenant's sub-system in a multi-tenant system (platform). If the modeled system is only an individual system, we consider it as a multi-tenant system with one tenant.
Subclass of ArchitecturalElement.
A component (to be) deployed on the platform. It is an instance of a ComponentType. It has an optional name that can be different from the name of its ComponentType. The state describes the current life cycle state of the component. The life cycle states are defined by the enumeration ComponentState that considers four different states:
-
UNDEPLOYED: the component exists but is not deployed. -
DEPLOYED: the component is deployed and stopped. -
STARTED: the component is deployed and started, thus running. -
UNKNOWN: the component is in any other states, for instance, crashed.
The following changes of the component state are valid (thus, all others are invalid):
| Source State | Target State | Corresponding life cycle operation |
|---|---|---|
UNDEPLOYED |
DEPLOYED |
Deploy the component |
DEPLOYED |
UNDEPLOYED |
Undeploy the component |
DEPLOYED |
STARTED |
Start the component |
STARTED |
DEPLOYED |
Stop the component |
UNKNOWN |
UNDEPLOYED |
Undeploy the component |
UNKNOWN |
DEPLOYED |
Stop the component |
Subclass of ArchitecturalElement.
Configuration parameter of a Component as an instance of a ParameterType. The value describes the current value of the parameter (e.g., "0.19" or "0.20" for the value-added tax parameter), that is, the defaultValue of the corresponding ParameterType can be overwritten. The type of the value (as well as of the defaultValue) is defined by the attribute type of the corresponding ParameterType.
Subclass of ArchitecturalElement.
Abstract super class for a RequiredInterface and ProvidedInterface. It is an instance of an InterfaceType.
Subclass of Interface.
An interface required by a Component.
Subclass of Interface.
An interface provided by a Component. Each Component must provided at least one interface.
Subclass of ArchitecturalElement.
A connector wires a RequiredInterface to a ProvidedInterface. For each wired RequiredInterface, there exists a connector. Multiple connectors can be wired to the same ProvidedInterface. A RequiredInterface and a ProvidedInterface that are wired by a connector must have the same InterfaceType. A connector has an optional name.
This level describes runtime concepts that are not modeled before the run time but that are observed in the running system by monitoring and then reflected in the model via sensors.
Subclass of ArchitecturalElement.
A runtime exception thrown by the associated ProvidedInterface and thus, by the corresponding Component. The type describes the type of the exception (e.g., the fully qualified name of the exception), the message the exception message, and the stackTrace the stack trace of the exception. The method reference points to the MethodSpecification that specifies the method of the ProvidedInterface that has thrown the exception. Thus, the referred MethodSpecification must belong to the InterfaceType that is the type of the ProvidedInterface,
Subclass of ArchitecturalElement.
Performance statistics of using the associated ProvidedInterface and thus, the corresponding Component. In particular, the statistic refer to the usage of the referenced method defined by a MethodSpecification of the ProvidedInterface.
The minTime refers to the minimum time in milliseconds of executing the method, maxTime to the maximum time in milliseconds of executing the method, totalTime to the sum of all execution times in milliseconds of the method, and invocationCount to the number of invocations of the method. Thus, the average response time in milliseconds of a method of the provided interface can be calculated by totalTime / invocationCount.
Subclass of ArchitecturalElement.
Generic class to describe an application-specific property of any ArchitecturalElement, which is monitored in the running system. Such
a property has a name, a description, a type defining the data type of the property value, a unit defining the measurement unit of the property value, and the actually measured value of the property.
A monitored property can optionally refer to further architectural elements (see relationship relatedArchitecturalElements) besides its main element (see relationship architecturalElement).
The component state primarily belongs to the runtime level since changes of the life cycle states of components can be monitored and reflected in the model. If the life cycle state of a Component changes, the value of the attribute state of the affected Component is updated.
Annotation elements are intended to be used by adaptation engines and feedback loops to perform self-adaptation. The usage of these elements is optional. Essentially, these elements capture knowledge created by an adaptation engine or feedback loop (e.g., analysis results or adaptation plans) as annotations to elements of the architecture. Annotation elements are colored yellow in the figure of the metamodel.
Single root element with a unique identified (uid) to store all Annotation elements to the Architecture.
Abstract super class for each annotation to the architecture. It defines the name, type, uid (unique identifier), and description of the annotation.
Subclass of Annotation.
An annotation to capture metric working data of an adaptation engine or feedback loop. Besides the attributes inherited from Annotation, it allows to store a value and a unit for the value. A working data annotation points to an arbitrary number of ArchitecturalElements via ConcernedElements.
Subclass of Annotation.
A ConcernedElement connects a WorkingData annotation to an ArchitecturalElement. The semantics of this connection can be specified through the attributes of the ConcernedElement inherited from the abstract Annotation class.
Subclass of Annotation.
An annotation to capture that there is an issue in the architecture, which should be handled by self-adaptation. Typically, an issue is identified by the analysis step of a feedback loop. Generally, an issue negatively affects the proper operation of an architecture. The semantics of an Issue can be specified through the attributes of the Issue element inherited from the abstract Annotation class. Additionally, the negative effect of the issue can be captured as a drop in the utility of the architecture (see attribute utilityDrop).
An Issue element points to at least one ArchitecturalElement via Impact elements.
Subclass of Annotation.
An Impact element connects an Issue element to an ArchitecturalElement, that is, the issue impacts the connected architectural element. The semantics of this connection can be specified through the attributes of the Impact inherited from the abstract Annotation class.
Subclass of Annotation.
An annotation to describe a planned adaptation to handle an issue. Thus, an AdaptationStrategy annotation is typically created by the planning step of a feedback loop. The semantics of an AdaptationStrategy annotation can be specified through the attributes inherited from the abstract Annotation class. Additionally, the expected utilityIncrease and the costs of the adaptation strategy can be captured. An AdaptationStrategy annotations refers to at least one Issue the strategy is going to handle and to an arbitrary number of ArchitecturalElements that serve as InputParameters to the strategy. For instance, a strategy to restart a Component will have this Component as an input.
Subclass of Annotation.
An InputParameter element connects an AdaptationStrategy element to an ArchitecturalElement, that is, the strategy has the connected architectural element as an input parameter. The semantics of this connection can be specified through the attributes of the InputParameter inherited from the abstract Annotation class.