Towards domain-specific extensibility of quality-aware software

architecture meta-models

Sebastian Dieter Krachkrach@fzi.de

FZI Forschungszentrum Informatik, Karlsruhe

Abstract

The evermore extending presence of software sys-tems in ubiquitous application domains requires cur-rent software architecture analyses to incorporatedomain-specific concepts. Current model extensionapproaches are too general, do not provide sufficientsupport for multiple roles in the development processor impose high effort on the extension developer. Inthis paper, we present MDSD.tools Characteristics, aframework to enhance existing architecture descrip-tion languages with easy-to-use quality modeling pro-files. It facilitates capturing of domain expert knowl-edge concerning relevant attributes of architecture en-tities into reusable specifications. Furthermore, itcomprises a notion of contextual information with amodel-based specification for information propagationto simplify the integration with existing analyses.

1 Introduction

With increasing capabilities of ubiquitous technology,the size and inherent complexity of the required soft-ware systems grows. Already 2006, Broy estimated50% to 70% of software and hardware developmentcosts to be incurred by software [2]. Hence, alsothe relevance of a suitable up-front architecture de-sign increases. Model-based software quality analy-ses, e. g. the Palladio approach [4], provide meansto quantitatively assess architecture-level alternativesand thereby support cost-and-quality-efficient deci-sions. When designing domain-specific software, do-main knowledge and domain-specific system proper-ties become a significant part of the architecture.

Capturing domain-specific properties in architec-ture models requires to create meta-models for eachdomain and subsequently adapting existing analysistooling to be reused. While this is acceptable fordomain-specific analyses, it becomes a cumbersometask for reusing existing generic ones, e. g. per-formance simulation or reliability analysis. Alter-natively, the software architect needs to know howto translate selected domain-specific properties intogeneric ones to continue using a generic architec-ture model. We envision taking a middle ground:use a generic structural architecture model and sep-arately extend it with the properties of the domain.

The approach is similar to a modularization of whatStrittmatter et al. [6] refer to as Ω and Σ layer.

In this paper we present MDSD.tools Characteris-tics, an approach for domain-experts to extend meta-models with domain-specific properties while beingable to transparently reuse existing analyses.

2 Running Example

Our running example focuses on using Palladio perfor-mance simulation for a simple perception system. Itconsists of two cameras which periodically take a pic-ture and transmit it via messaging to a shared imageprocessing component (see Figure 1).

<<EventGroup>>ImageChannel

message(Image data)

<<Interface>>ICamera

void takePicture()

<<BasicComponent>>CameraComponent

SEFFCompartment

ICamera.takePicture<<Emits>>

<<Provides>>

<<EmitEventAction>>emitPhoto

InputVariableUsageCompartment

data

BYTESIZE = "Resolution.width *Resolution.height"

<<System>>Perception System

<<AssemblyContext>>FrontCamera

<<AssemblyContext>>RearCamera

<<AssemblyContext>>ImageProcessor

frontView

rearView

<<EventChannel>>frontView

<<EventChannel>>rearView

RearCameraTrigger

FrontCameraTrigger

<<Characteristic>>Resolution

height: Pos. Int width: Pos. Int

C

C Resolution

Resolution

Unbound Characteristics

R<<ProvidedInterfaceApplicationRule>>

mandatory = True

.height = 100

.width = 200

Resolution.height = 480.width = 640

M

M

Figure 1: Excerpt of PCM Perception Example

We want to determine the network load and esti-mate the transmission latency for different image res-olution settings. The image resolution determines thesize of each image message and should be configurablefor each camera on its own. Furthermore, the imageresolution affects the probability of successful objectrecognition in subsequent stages.

This trivial example illustrates the use of domain-specific characteristics and does not strive to presenta comprehensive analysis scenario.

3 Domain-specific characterizability

In the following, we discuss the requirements whichneed to be fulfilled by a meta-model extension mecha-

nism. We identified the requirements based on our ex-perience with meta-modeling and model-based analy-ses of applications from different domains, in partic-ular using the Palladio Approach [4]. Thereafter, wepresent the concepts of our framework to meet theidentified requirements.

I. External extensibility The component devel-oper of our CameraComponent should be able to spec-ify the required additional properties for his compo-nent without the need to adapt the PCM meta model.

II. Multi-view refinement support The metamodel extension framework should provide supportfor multi-view-based architecture models, particularlydeferred initializations. In particular, property speci-fication and initialization should be separate. In ourexample, the image resolution property needs to bespecified for the component while concrete image reso-lution values would be specified during system assem-bly for each component instance. For the PCM, Com-ponent Parameters [4, p. 107] provide the requiredfunctionality. They do however lack support for gen-eralization and automated validation.

III. Ahead of analysis-time validation supportThe system architect should be able to validate thecompleteness of extended models. For instance, as-semblies of the camera component which do not spec-ify an image resolution should be identified.

IV. Flexible constraint type system A domainexpert who specified additional properties also wantsto communicate the expected value range. For in-stance, the resolution property has two nested positiveinteger properties width and height. The specificationis essential for editing and validation tool support.

V. Support for stochastic initializations Cer-tain characteristics of a system entity cannot be ex-pressed by a fixed quantity but appear to have arandom component. Consequently, when initializingproperties the modeller should be able to use stochas-tic means to express probabilistic distributions overpotential values.

3.1 The Characteristics Approach

In order to achieve our desired extensibility, we dis-tinguish three model-based view points: Characteris-tics, Manifestations and Value Types (see Figure 2).A Characteristics model captures the specification ofproperties and includes rules on where they can beapplied on an existing meta-model. Manifestationsare concrete values for a particular Characteristic anda model entity. They are stored inside the originalmodel. Third, Value Types define the space of validManifestations. Value Types are defined using a sim-plified modeling language similar to Ecore. Primitivetypes directly map to their Ecore equivalents.

The applicability of a characteristic to a model en-

Manifestation

Characteristic

ValueType

<<captures concrete values

(distribution) for>>

adheres to

<<specifies type andconstraints for

concrete values>>

Figure 2: Overview of the Characteristics view points

tity, that is, the possibility to specify a manifestationon a concrete model element, is determined by Appli-cation Rules. Each rule can be regarded as functionrule : M × C → void, optional,mandatory, withM , set of all model elements, and C, set of all charac-teristics. A void result refers to a rule not making astatement concerning the applicability. We intention-ally refrained from supporting prohibiting rules to pre-vent rule conflicts. In our example, a rule specifies themandatory requirement for the Resolution character-istic to each component which provides the ICamerainterface. Multiple Characteristics and ApplicationRules are bundled to a Characteristic Profile. Similarto EMF Profiles [3], they are applied to a model.

When applying the MDSD.tools Characteristicsframework we differentiate four phases: 1) enhanc-ing the original meta-model with framework support,2) defining profiles of characteristics and their appli-cability, 3) creating enriched models with manifesta-tions according to the applied profiles and 4) usingthe enriched models in model-based quality analyses.The meta-model extension (phase 1) needs to be doneby a developer familiar with the meta-model. Phase 2targets domain experts which require additional prop-erties. Starting with phase three the properties areintegrated transparently into the model view points.

3.2 Hierarchical Manifestation Contexts

A Context Model is the central artifact in enhancingan existing meta model with Characteristics support.It captures which classes of a meta-model are eligiblefor characterization. In particular, it defines whichmodel elements function as Characterization Contextsand their inter-context relationships. A context con-stitutes a name space containing a set of valid identi-fiers. Each identifier either refers to a Manifestation orlinks to a different but related context, e. g. a param-eter name inside a RDSEFF. In our example, each Ba-sicComponent and each AssemblyContext constitutea separate context. On the technical side, the contextserves as storage container for Manifestations.

For each class which acts as Characteristic Context,the Context Model contains model queries, to find theContexts which are included and to which there is arefines relationship. Identifiers in included contextsare resolved, as if they were contained in the includingcontext. Unless specified otherwise, includes relation-ships are assumed along containment references.

Contextual refinements are not included by-

2

default, as their nature is conditional. It lies withinthe responsibility of the evaluating analysis to selectthe set of refining contexts which need to be takeninto account. Manifestations in the selected refiningcontexts then overlay the target context. If the targetcontext already contains a Manifestation, the refiningManifestation has precedence. For example, the In-terpreter of a Palladio Performance simulation, whensimulating a RDSEFF, identifies the currently activeAssembly and includes selects the appropriate Assem-bly Context. Figure 3 visualized relevant contextualrelations in our example.

<<Context>> ExternalCallAction

<<Context>> RDSEFF

<<Context>> BasicComponent

<<Context>> Repository

<<includes>>

<<includes>>

<<includes>> <<Context>> AssemblyContext<<refines>>

<<Context>> Parameter

<<imports>>

<<refines>>

"Resolution": width: 200, height: 100

<<Manifestation>>

<<target>>

"Bytesize": Resolution.width * Resolution.height

<<Manifestation>>

<<Context>> Parameter

<<target>>

Figure 3: Excerpt of exemplary lookup hierarchy

To specify Manifestations, we extend the existingStochastic Expressions (StoEx) approach [4] with sup-port for contextual lookups. Every Enhanced StoEx(eStoEx) expression is evaluated in the context whichcontains it. We reuse the mathematical and stochas-tic capabilities of StoEx but refactor variable referenceaccess. Henceforth, identifiers are resolved using thecontaining context. We continue to use dot separationfor navigation between contexts. When resolving anidentifier, e. g. by analyses, the evaluation starts withthe context containing the expression and follows in-cludes relationships until the identifier is found takinginto account conditional context overlays.

4 Related Work

In the following, we discuss similar extension mecha-nisms. To the best of our knowledge, there is currentlyno approach which fulfills all of our requirements.

With Component parameters [4, p. 107], the Pal-ladio Component Model already provides support formulti view modeling on selected elements. However,they are specific to the PCM and do not support ex-ternal extensibility. Our approach provides a genericmechanism to extend existing meta-models. Compo-nent parameters provide no support for automatedvalidation, which is a main requirement of ours.

CQML+ [1] is a generic quality modeling frame-work for component-based systems. It uses a similarseparation between specifications and initializations ofquality parameters as our framework. While CQMLfocuses on inter-component contracts, it does not pro-vide support for multi-view refinements.

EMF Profiles [3] provide means to attach addi-tional informations to existing meta-models. The el-

ements which should be extensible are selected solelybased on their meta-class. EMF Profiles does not pro-vide support for constraint data types or contextualrefinements. It could, however, serve to store Mani-festations inside of existing model elements.

Architectural Templates [5] fulfill most of our re-quirements. ATs support complex model extensions,including structural adaptations. Their specificationhowever requires the domain expert to create severalcomplex artifacts, including model transformations.ATs are less intrusive to the meta-model to extendbut still need similar extensions to the tooling.

5 Conclusion and Future Work

In this paper we presented foundational conceptsof the MDSD.tools Characteristics framework. Theframework aims to provide domain-specific extensi-bility to existing software architecture meta-models.It enables domain-experts to enhance enabled meta-models with additional properties without changingthe meta-model or the underlying tooling itself. Fur-thermore, it provides a formalized mechanisms to al-low for property refinements throughout the architec-ture design process. To provide this flexibility, meta-model and tooling need to be extended once.

The development of the framework is currently inprogress1. Consequently, as part of future work weplan on conducting elaborate evaluations to deter-mine the degree to which we were able to achieve ourgoals. We will provide more complete documentationon modeling concepts, technical aspects and applica-tion principles in an upcoming technical report.

Acknowledgements. The author acknowledges recurrent re-views and conceptual input of Stephan Seifermann and DominikWerle (both Karlsruhe Institute of Technology). This work waspartially funded by the German Federal Ministry of Educationand Research under grant 16EMO0360 (SmartLoad).

References[1] S. Rottger and S. Zschaler. “CQML+: Enhancements

to CQML”. In: In Proceedings of the 1st InternationalWorkshop on Quality of Service in CBSE. Cepadues-Editions, 2003, pp. 43–56.

[2] M. Broy. “Challenges in Automotive Software Engineer-ing”. In: Proceedings of the 28th International Conferenceon Software Engineering. ICSE ’06. Shanghai, China:ACM, 2006, pp. 33–42.

[3] P. Langer et al. “EMF Profiles: A Lightweight ExtensionApproach for EMF Models”. In: Journal of Object Tech-nology 11.1 (Apr. 2012), 8:1–29.

[4] R. H. Reussner et al. Modeling and Simulating SoftwareArchitectures – The Palladio Approach. Cambridge, MA:MIT Press, Oct. 2016. 408 pp.

[5] S. M. Lehrig. “Efficiently Conducting Quality-of-ServiceAnalyses by Templating Architectural Knowledge”. PhDthesis. Karlsruher Institut fur Technologie (KIT), 2018.

[6] R. Heinrich, M. Strittmatter, and R. H. Reussner. “ALayered Reference Architecture for Metamodels to TailorQuality Modeling and Analysis”. In: IEEE Transactionson Software Engineering (2019).

1https://github.com/MDSD-Tools/

Characteristics-Modeling

3