A UML Profile for the Specification of System Architecture VariantsSupporting Design Space Exploration and Optimization

Alexander Wichmann, Ralph Maschotta, Francesco Bedini, Sven Jager, and Armin ZimmermannSystems and Software Engineering Group

Computer Science and Automation DepartmentTechnische Universitat Ilmenau

Ilmenau, GermanyContact: alexander.wichmann@tu-ilmenau.de; see http://www.tu-ilmenau.de/sse

Keywords: System modeling, architecture variant description, UML profile, design space

Abstract: The optimization of complex systems as well as other design methods require a description of the systemparameters, or the design space. Explicit encoding of all possible variants is practically impossible, thus animplicit method is needed. While this is easy for purely numerical parameters and a fixed number of them asusually assumed in direct or indirect optimization, it is quite hard for systems in which the architecture and thusthe structure of the parameters themselves can be varied. This paper introduces an approach to specify systemarchitecture variants in a concise way and proposes a UML profile for this task. Standard UML meta modelelements are used for the description of variant-specific stereotypes. An example of a variant specification fora communication network model is presented.

1 Introduction

Model-based systems engineering is helpful in al-lowing early validation of complex system designsand reduction of costly failure corrections in late de-velopment states. The underlying models have to cap-ture all significant information, which often containsboth (static) structural as well as (dynamic) behav-ioral aspects. Numerous design decisions must bemade to obtain a hopefully close-to-optimal system.These decisions could be supported or automatedby a closed-loop indirect optimization approach (vanLeeuwen et al., 2014), in cases where the descrip-tional power of linear programming is insufficient.The set of valid system variants (or design alterna-tives), also called the design space (Taghavi and Pi-mentel, 2010), has to be specified as an input to theoptimization heuristic. Such a specification (not itsderivation or exploration, though) is comparably sim-ple as long as all parameters are just numerically val-ued with a given interval. In fact, it is usually de-scribed by a vector of n real values for a system withn design parameters, and we may imagine the designspace as an n-dimensional geometrical space then.However, this paper addresses the problem of archi-tectural optimization, in which the structure of vari-ants and design parameters is typically much morecomplex, and in which already the number of parame-

ters n is not obvious as it depends on other design pa-rameter value choices: Components may be optionaland include a variable attribute. If such an optionalcomponent is not used inside a system variant, thentheir properties as well as the corresponding parame-ters are also not existing. Thus, the well-understoodresearch area of linear systems with numerical param-eters cannot be applied here.

What should be described for the design spaceabout a variable architecture? First of all, the gen-eral structure must be defined including system com-ponents as well as their properties and relations toother components. Furthermore, variants of the sys-tem model have to be specified in order to solve thefollowing questions: How many instances of com-ponents are existing? How many instances belongto or comprise another one? What are the limits ofthe numbers of instances? Which values can be as-signed to component properties? Which interface re-alization should be used? Should an optional featurebe used? Where is each component placed? Whatare fixed components and attributes? How should anattribute be specified, which depends on another at-tribute? What kind of connections should be used be-tween components? How can attributes be capturedthat are only necessary for certain structural selectionsor options?

Apparently the design space includes numerical

parameters, structural, non-numerical parameters andparameters, which are only existing in specific cases.How can the design space be described? A possibil-ity is to list all architecture variants explicitly. Thisdescription is practically impossible for complex sys-tems because of the sheer number of variants, whichusually scales exponentially (with the size of the crossproduct of all individual parameters). An implicit de-scription is thus the only viable way to specify a de-sign space, in which decisions and their alternativesare described.

In the existing literature on this subject, systemarchitectures can be specified by using the familyof architecture description languages (ADL). Thereare a variety of languages like xADL (XML-basedADL, (Dashofy et al., 2001)), Acme (Garlan et al.,2010) or µ-ADL (Oquendo, 2004). A survey of suchlanguages is presented in (Clements, 1996). All ofthese languages can be used to specify a single sys-tem architecture, but they do not support techniquesto specify variations or the possible design space.

Feature models (Schobbens et al., 2006; Zakalet al., 2011; Acher et al., 2014; Gronninger et al.,2014) are a description language, which is used inproduct lines engineering. It allows the description toa variety of products, which are based on an identicalbasis, while differing in features and design details.Feature models provides elements to describe featuresof a system, including possibilities to choose or ig-nore alternative features or define XOR-relations offeatures, where exactly one feature has to be chosen.However, feature models lack support for dynamicvariability: All alternatives have to be described ex-plicitly. For instance, a component can be existingbetween 0 and 10 times. Furthermore, each compo-nent includes a property, which can be varied. Thiscan be done with XOR-relations, in which each com-ponent count is explicitly listed. For each componentalternative, the identical attribute variants have to bedescribed separately and thus redundantly. For smallsystems, this may be usable, but the model will loseclarity and expressiveness in variant specifications ofcomplex systems. Moreover, the possibility to definephysical connections between features such as twocomponents communicating or a component includ-ing a variable count of another component are com-pletely missing.

Another architecture description language isEAST-ADL (Association, 2013), which is a domain-specific language for the description of automotivesystems. EAST-ADL includes a package which pro-vides description elements for variability manage-ment. This language is based on the AUTOSAR (AU-TOSAR, 2015) meta model, which is developed

for use in automotive domain. Here, a domain-independent language is required in order to modelvariants of system of different domains. A broaderview on architectural models in the automotive do-main is given in (Broy et al., 2009).

The goal and contribution of this paper are (meta)models for the description of system architecture vari-ants that can later be used for design space analy-sis, including automatic indirect optimization meth-ods (Wichmann et al., 2015). We propose standardUML class diagrams for this goal and combine themin a UML profile (OMG, 2015) for this task. Profilesinclude stereotype definitions, which extend standardUML elements and are used to define domain-specificinformation. In this case, a profile named variantprofile is specified, which defines several stereotypesfor our task in the subsequent Section 2. Techni-cally, the Eclipse modeling project and the Siriusproject are used which enable a more effective real-ization of domain-specific languages than other ap-proaches (Eclipse, 2014; El Kouhen et al., 2012).

This profile is used for the description of systemarchitecture variants for an example in Section 3. Thearchitecture of a sample communication network ismodeled with the proposed profile, in which systemcomponents, their properties and connections to othercomponents are described. Stereotypes of the profileare available inside system models and can be appliedto UML elements in order to specify variants of thesystem, which results in a system architecture variantsmodel as design space description.

Furthermore, this approach allows an easy integra-tion with the concept of executable system optimiza-tion specification, in which the behavior of systemoptimization is modeled with UML activity diagramsand transformed into executable code using model-to-text generators (Wichmann et al., 2016). The genera-tors are also applicable to system architecture variantmodels and create executable code, which can be usedby optimization processes using an fUML executionengine (Bedini et al., 2017).

2 A UML profile for systemarchitecture variant specification

This section describes the UML profile and its ap-plication for the implicit specification of architecturaldesign spaces. A UML profile is an element of theUML and defined inside the UML meta model (OMG,2015). Profiles are used to extend classes of the UMLmeta model with additional stereotypes, which allowsa more detailed (usually domain- or appplication-specific) specification of system.

A model of a system can be structured as a classrepresenting the system. This system class has as-sociations to component classes, which have proper-ties and may have associations to other componentclasses. For that, two types of structural element areidentifiable: class properties and class associations.

The following three UML meta classes are ex-tended with variant-specific stereotypes: Property,Dependency and Model. The following subsectionsdescribe the additional stereotypes for these metaclasses in the profile.

2.1 Model Variants

The UML meta class Model serves as the root elementof a system model and includes all elements, whichdescribe structure and behavior of the system archi-tecture. The profile extends Model with stereotypevariant, which implies that the system model includesvariants.

Figure 1: Profile diagram for Model stereotype

Variant owns the optional property rootClass,which provides a reference to the model class, inwhich the creation of a system architecture variantshould start. If this property is not specified, rootclasses can be determined automatically by searchingfor classes which are not referenced by another classand thus are independent. For each found class, thevariant creation is executed afterwards.

2.2 Value Variants

The second extended UML meta class is Property,which is used to specify properties of classes. Fig-ure 2 presents all stereotypes, which are extendingProperty.

Regarding variant specification, properties can beclassified into value-based and instance-based prop-erties. Value-based properties are specified by prim-itive data types (comparable to simple linear or nu-merical design parameters) or enumerations and areassigned one or more fixed values. Their propertiescannot be modified for variant specification. Thus,

Figure 2: Profile diagram for value variants

the set of stereotypes for Property is called valueVari-ant. In contrast to this, instance-based properties arespecified by associations and allow hierarchical vari-ant specification of the associated class.

Property is classified into several categories: nu-merical attributes, optional attributes, fixed attributesor derived attributes. For each category, a separatestereotype is defined, which owns different propertiesto specify the variants of corresponding Property ele-ment.

First of all, a system architecture may have com-ponent properties, which are important for simulationand evaluation of this architecture, but should not bevaried in the design space description. Such proper-ties can apply the stereotype fixedValueVariant explic-itly, but this is not mandatory. Properties without vari-ant stereotype do not increase the design space andthus are automatically interpreted as fixed. StereotypefixedValueVariant is thus defined as default. FixedVal-ueVariant includes property value of type ValueSpeci-fication, which allows static configuration of Propertyvalues for system architecture variant models. Valueis an optional stereotype property allowing to set avalue to be assigned to this property.

Defining a set of valid values is another possibil-ity to specify value variants of a Property element.Each value of this set can be assigned to a class prop-erty. We propose the stereotype typeValueVariant forthis case, which allows the definition of a value list,whose items confirm to the type of its Property. Forthat, the stereotype typeValueVariant owns two prop-erties: type specifies the class, whose value are set to

Figure 3: Example for typeValueVariant

Figure 4: Example for intervalValueVariant

the list and thus defines the type of the list, while listrepresents a set of actual values (like an enumeration).

Figure 3 presents a simple example us of typeVal-ueVariant. The class A has a property b with enumer-ation class enum as type. The enumeration includesthree literals option1, option2 and option3. Propertyb is specified with stereotype typeValueVariant. Thus,stereotype properties type and list should be set. Thevalue of type must match with type of b. This canbe an instance of property type or an instance of aderived class. Here, the enumeration enum is used.Property list includes all value variants, which can beassigned to b. Here, these value variants must be a lit-eral of enum. However, list does not have to containall existing literals, but only literals which are relevantfor the current variant specification. Thus, list is filledwith enumeration literals option1 and option2.

Variants of numerical properties may be speci-fied by interval definitions with minimal and maxi-mal value as well as a step definition to specify allintermediate values. For that, stereotype IntervalVal-ueVariant is introduced to describe the range of nu-merical values of Property. The range is restricted bya minimal value (min) and maximal value (max). Thevalues between these limits are calculated using theproperty step.

An example for application of stereotype interval-ValueVariant is presented in Figure 4. A class A ownsa real number b, which should be varied. For that, thestereotype intervalValueVariant is applied to b and itsproperties have to be set. The property b should beable to take values from 0 to 2.5 with accuracy ofone decimal digit. Thus, the property min is set to0.0 and max to 2.5. The accuracy is specified withproperty step, which is set to 0.1. Thus, the values0.0, 0.1, ..., 2.4, 2.5 can be assigned to property b.

The length of list properties can be assumed as sspecial case of numerical attributes. Instead of as-signing a value to a Property, a value can representthe number of elements inside the Property. How-

ever, the changed interpretation of variant specifica-tion requires the additional stereotype listValueVari-ant, which is derived from intervalValueVariant andinherits its properties. This stereotype only specifiesthe count of values inside a Property element, butdoes not have information about the value specifica-tions. This has to be done by another stereotype.

Furthermore, a system component may have op-tional features, which are represented by Boolean val-ues specified in Property and thus can assume eitherthe value true or false. Exactly such a variant specifi-cation is realized with stereotype optionalValueVari-ant. Properties for optionalValueVariant are not spec-ified, because further information for this stereotypeis not necessary.

System components may have properties, whichdepend on other properties and can be calculated ex-plicitly based on the value of such properties. Suchvariants are specified with the stereotype derivedVal-ueVariant (to simplify their later calculation, whichotherwise could be done with constraints in a muchless efficient generate-and-test algorithm). Its prop-erty formula describes the calculation function. For-mula is a Behavior, which is the basic meta classfor all behavioral (executable) elements of the UML.Thus, the formula can be described by using UML di-agrams like Activity Diagram or Sequence Diagram.Furthermore, OpaqueBehavior or FunctionalBehav-ior can be used to specify the behavior with codefragments of programming languages or expressionsof OMG’s Meta Object Facility Model to Text Trans-formation Language (MOFM2T (OMG, 2008)). Thespecified behavior can be executed and the result is as-signed to the corresponding Property afterwards. Theactual behavior for formula has to be specified duringthe variants modeling.

Figure 5: Example for derivedValueVariant

Figure 5 shows an example class A with propertyb and c. The value of b should be calculated basedon the value of c. For that, the stereotype derived-ValueVariant is applied to b. Its calculation formulais specified inside the stereotype property formula,which can be described using MOFM2T expressionsfor instance. All instances and values of the currentsystem architecture variant can be used for the calcu-

lation. Here, MOFM2T expression is specified insidea FunctionBehavior and calculates the modulo valueof c. The result of MOFM2T expression processingis assigned to b.

These stereotypes suffice to describe all possibili-ties for specifying variants of properties that we haveencountered so far in our analysis. The more complexdescription of instance variants is covered next.

2.3 Instance Variants

The UML meta class Dependency is extended withvariant stereotypes in order to vary instance-basedproperties, which are specified by associations toother classes. A Dependency relation defines that aclass depends on a single supplier class or set of sup-plier classes (OMG, 2015). Figure 6 shows the in-troduced stereotypes, which extend the Dependencyclass. These stereotypes define, how many instancesof the supplier class should be created and how theirproperties have to be set.

Figure 6: Profile diagram for instance variants

In general, variant specification of instance-basedproperties defines, that instances of a supplier classshould be assigned to a property of the dependingclass. How many instances should be created andhow these instances are configured, should be definedthrough specializations.

The meta class Dependency is extended by thestereotype instanceVariant, which implies, that a de-pendent class includes instances of the supplier class.These instances are assigned to the property of the de-pendent class, with is configured in stereotype prop-

erty target. The second Property of instanceVariant iscalled uniqueInstances and implies that the instancesare unique w.r.t. their values.

Further stereotypes are derived from this basestereotype and specify the number of instances andtheir property settings. The properties of instance-Variant are inherited and thus configurable by derivedstereotypes.

The number of instances can be fixed or variablefor variant specification. In the fixed case, a prede-fined number of supplier class instances has to be as-signed to a property of the depending class. Further-more, these fixed instances have attributes, which maybe fixed or variable. For that, the derived stereotypecountFixedInstanceVariant is introduced. It impliesthat a fixed number of instances of the supplier classshould be created and assigned to the inherited Prop-erty target. The count of instances is specified withProperty instanceCount. A created instance has prop-erties, to which a value has to be assigned. Thesevalues can be determined by a fixed or variable speci-fication. In order to cover all combinations of variantspecifications, three possibilities including value set-ting behavior are defined, and priorities assigned tothem as follows.

The preferred (high priority) option is the con-figuration of fixed instance specifications inside thestereotype countFixedInstanceVariant. For that, theoptional Property instanceList is defined, which is aset of InstanceSpecification elements, which includesslots for values specifications of class properties. Itmay be that an InstanceSpecification is incomplete,because at least one value of an attribute is not pre-configured. In this case, the second option is checked,in which the value should be determined based onstereotype specifications. If the property does not ap-ply a stereotype, specified default values of the prop-erty should be used. If none of the options is applica-ble, the property value stays undefined.

Figure 7: Example for countFixedInstanceVariant

An example is shown in Figure 7: Two classes Aand B are connected through a composite association,in which class A includes instances of class B. Addi-tionally, class B has a numeric property c. The variant

profile should be used to specify that A owns two in-stances of B, in which one instance has a fixed value 5for c. The second instance’s attribute can be variedbetween 0 and 10, but has to be different from the firstinstance’s value. To specify that, a Dependency con-nection is created between target class A and supplierclass B, which applies the stereotype countFixedIn-stanceVariant. The stereotype property target speci-fies the property of the target class, to which the cre-ated instances should be assigned. Here, the instancesare assigned to the property b of class A. UniqueIn-stances is set to true, because the instances inside bshould be different. Class A should own two instancesof B, thus instanesCount is set to 2. The fixed instanceis specified with InstanceSpecification s, which assignthe value 5 to property c. This InstanceSpecificationis assigned to stereotype property list. The stereotypeintervalValueVariant is applied to property c in orderto specify the variants of class B.

According to the specified value-setting behavior,an instance of class A is created and its properties areconfigured based on the applied stereotypes. Two in-stances of class B are created afterwards. The precon-figured instance specifications of class B are used first.The second instance is not specified by instanceList.Thus, the remaining instances are created based onvariant specification of class B, in which the value ofproperty c may be set to 9, for instance.

In contrast to countFixedInstanceVariant, thestereotype countVariableInstanceVariant is used forvariable quantities of class instances. Variants of in-stance quantities are restricted by the stereotype prop-erties minimalCount and maximalCount. The valuesbetween these limits are calculated based on steps.The Property values of each class instance are calcu-lated in the same way as for countFixedInstanceVari-ant.

Figure 8: Example for countVaribleInstanceVariant

Figure 8 presents an example for the application ofstereotype countVaribleInstanceVariant to the samesystem as in Figure 7. Class A should include one tofive instances of class B. Instances of class B are not

predefined, but the property of B is fixed to 1. Thus,a Dependency connection with stereotype countVari-ableInstanceVariant is created between classes A andB. The stereotype target is set again to A::b. Class Bshould not be varied; thus all instances have the samevalue for c and the property uniqueInstances must beset to false. At least one instance of B has to exist, butnot more than five of them together. For this, mini-malCount is set to 1, maximalCount to 5, and step to1. The list of preconfigured instances remains empty,because instance specifications are not used here.

Creation of class instances may depend on alreadyexisting instances of other classes. This can be thecreation of a communication connection between twocomponent classes, for instance. If a communicationlink can be created, it may depend on properties of theconnected components (modeled as class instances),which cannot be evaluated during variant specifica-tion. This has to be done at run time of the later vari-ant creation. The required behavior to create an in-stance of the supplier class has to be defined insidethe system architecture variants model.

For that, the stereotype derivedInstanceVarianthas to be applied. DerivedInstanceVariant impliesthat the supplier class is created based on informationfrom the depending class. How the supplier instancesshould be created, is specified in stereotype propertycreationBehavior, which is a Behavior. CreationBe-havior can be specified by any UML behavioral ele-ment like Activity Diagram or FunctionBehavior. Thespecified behavior is executed for each unique com-bination of instance specifications of the dependentclass.

For the special case of bidirectional associationsbetween classes, the optional Property oppositeTar-get is introduced, which specifies a property of thesupplier class. It expresses that the bidirectional as-sociation should be created, in which instances of adepending class should be assigned to the propertyoppositeTarget and the created supplier class instanceshould be assigned to the target class property target.Furthermore, oppositeTarget allows the restriction ofinstance combinations as input for the behavior. Forinstance, a Dependency is linked to a class with anopposite target-property, which required exactly twoinstances of the class. Thus, only combinations withtwo different class instances have to be investigated.

A derivedInstanceVariant-applied Dependency ispresented in Figure 9. Class A and B are associatedbidirectionally, in which class B depends on class A.Class A owns several instances of B, but class B in-cludes only one instance of A. Thus, the Dependencyis created from A to B. The stereotype derivedIn-stanceVariant is applied. The property target is set

Figure 9: Example for derivedInstanceVariant

to A::b and oppositeTarget to B::a in order to real-ize the bidirectional association. The creationBehav-ior is specified by Activity createB, which creates aninstance of B. The property variantClass defines pos-sible classes, which could be created during the opti-mization process. Here, only instances of class B canbe created and thus, B is assigned to variantClass.

These stereotypes form the variant profile and al-low the design space specification of system architec-tures.

3 An Application Example

The presented profile for modeling system archi-tecture variants from Section 2 is applied to a commu-nication network, where nodes shall send and receivedata using certain communication protocols.

The class diagram of the system design is pre-sented in Figure 10. The communication networkis represented by the class Network. Network nodesare modeled as interfaces to provide basic properties,which are necessary for all nodes. A network nodehas a name and a position in three-dimensional spaceas well as nonrecurring and ongoing costs. Commu-nication with other nodes is realized over a connec-tion interface, which is implemented by an Ethernetor WLAN connection and can transfer data accordingto its Property dataRate. Network nodes may pro-vide Ethernet slots or WLAN technique to be able tocommunicate. The connection realization WLANCon-nection has additional properties to specify the max-imal communication range and stores the actual dis-tance between two network nodes. Each connectiondescribes communication between two NetworkNodeobjects.

Network nodes can have more than one connec-tion to different nodes depending on their Ethernetslots and WLAN features. Connections between twonodes are limited to one. The NetworkNode inter-face is realized by classes EndNode and AccessPoint.

Figure 10: Design of communication network

Figure 11: Fixed instance specifications of communi-cation network model

EndNodes represent machines like server, personalcomputer or smart phones. They produce data witha Gaussian distributed data rate and send this to con-nected nodes, while also receiving data. AccessPointsserve as transmission nodes and transfer received datato target nodes or another AccessPoint.

The design space of this system should be de-scribed in order to be used by a system architectureoptimization process. The presented variants profileis assigned to the communication network model inorder to define which elements of this model can bevaried.

Figure 12 presents the resulting architecture vari-ant model of the communication network. First of all,the model CommunicationNetwork applies stereotypevariant. Its property rootClass is set to Class Commu-nicationNetwork, because creation of an architecturevariant should start with this class.

Dependency connections are defined and specifiedwith stereotypes afterwards. EndNodes should not bevaried. The example considers one personal computerand one smart phone. The personal computer has oneEthernet port but no WLAN option, while the smartphone provides WLAN connections, but has no Eth-ernet ports. Both are placed in different positions.For that, a Dependency is created from Network toEndNode and stereotype countFixedInstanceVariantis assigned to this connection. The specification ofthis two EndNode instances is presented in Figure 11.

Figure 12: Architecture variants model of communication network

InstanceSpecifications are used to define proper-ties of existing nodes. They are assigned to stereo-type property instanceList. Furthermore, objectCountis set to value 2, all instances should be unique. Net-work::networkNodes is specified as target.

AccessPoints are variable in quantity and propertyconfiguration. They are used to implement communi-cation between computer and smart phone. For that,Network and AccessPoint are connected by a Depen-dency with applied stereotype countVariableInstance-Variant. Network includes at least zero and not morethan three AccessPoints objects. A instanceList is notset. Thus, values of instances are set based on valuevariant specification or default value of properties.

A Dependency with applied stereotype includ-eDerivedObjects is created between interfaces Net-workNode and Connection. References of this con-nection are stored inside NetworkNode::connectionsand references of nodes should be deposited in Con-nection::networkNode. A connection can be real-ized by classes WLANConnection and LANConnec-

tion. The property variantClass is specified with bothclasses. Thus, an optimization process can decidewhich should be created, if both are possible.

Furthermore, stereotype includeDerivedObjectsrequires a specification of a Behavior element, whichshould be processed to create an instance of Con-nection class. For that, the Activity CreateConnec-tion is specified. Figure 13 presents the correspond-ing Activity Diagram. It has three ingoing and oneoutgoing Activity Parameters. The two ingoings areused for NetworkNode instances, because the inter-face Connection owns Property networkNode, whichshould exactly include two NetworkNode instances.The third parameter is called Class and allows to in-fluence this activity by a calling optimization process.

The activity CreateConnection checks which con-nections are possible between two ingoing NetworkN-ode instances. A LANConnection can be created, ifboth NetworkNode instances have free Ethernet ports.A prerequisite for WLANConnections is the support ofthe WLAN feature by both NetworkNode instances.

Figure 13: Activity diagram for connection creation behavior

If exactly one check passes, then an instance of thecorresponding class is created. The class specifiedby Activity Parameter Class is instantiated, if bothchecks are successful. Otherwise, no connection in-stance is created. The activity ends with an Instance-Specification of a Connection or without a result, ifno connection is creatable. This behavior is executedfor all combinations with two different NetworkNodeinstances.

Value variant stereotypes are applied to propertiesof interface NetworkNode as well as of classes Ac-cessPoint and WLANConnection. InitialCosts, com-municationCostPerDay and totalCostsPerDay of in-terface NetworkNode are derived properties and ap-ply stereotype derived. For each Property, a formulais specified with MOF Model to Text TransformationLanguage expressions. The formula for initialCostsdepends on the quantity of Ethernet ports and enabledWLAN features. Daily communication costs are cal-culated based on the enabled WLAN feature. Fur-thermore, the sum of fixed daily execution costs anddaily communication costs results in total daily costs.Another derived Property exists in WLANConnection.Distance calculates the distance between two Networ-kNode instances, which are set in networkNodes.

The class AccessPoint inherits all properties ofthe interface NetworkNode. The following propertiesare overwritten and stereotypes are applied to them:Property countLANPorts applies the stereotype inter-

valValueVariant. An AccessPoint can have no Ether-net port up to four Ethernet ports. Accordingly, thestereotype properties are set. The optionalValueVari-ant stereotype is applied to isWLANExisting indicat-ing if an AccessPoint can provide WLAN connectionsor not. The position attributes of AccessPoint appliesthe intervalValueVariant stereotype and the valid co-ordinates are specified.

Finally, all value-based properties without variantstereotypes are assigned a default value. This com-pletes the system architecture variants model, and anoptimization process could use this model of the de-sign space to find an optimal system architecture.

4 Conclusion

This paper presented an approach for the model-based specification of system architecture variants,thus allowing the concise specification of the com-plex design space of a system with architectural vari-ations. A UML profile is introduced for this task,which extends standard UML meta model elementswith variant-specific stereotypes. This allows variantspecifications of system architectures, which are nec-essary to execute system architecture optimizationsautomatically or to apply other methods which requirean implicit design space description.

Future steps include the specification and imple-

mentation of a generator, which creates architecturesbased on the architecture variants model affected bydecisions made during an optimization heuristic exe-cution.

Acknowledgment

The work has been supported by the Federal Min-istry of Economic Affairs and Energy of Germany un-der grant number 20K1306D.

REFERENCES

Acher, M., Cleve, A., Collet, P., Merle, P., Duchien,L., and Lahire, P. (2014). Extraction and evolu-tion of architectural variability models in plugin-based systems. Software & Systems Modeling,13(4):1367–1394.

Association, E.-A. (2013). EAST-ADL domainmodel specification version V2.1.12. Technicalreport, EAST-ADL Association.

AUTOSAR (2015). AUTOSAR specification. Online.Release 4.2.

Bedini, F., Maschotta, R., Wichmann, A., Jager, S.,and Zimmermann, A. (2017). A model-drivenC++-fUML execution engine. submitted.

Broy, M., Gleirscher, M., Merenda, S., Wild, D.,Kluge, P., and Krenzer, W. (2009). Toward aHolistic and Standardized Automotive Architec-ture Description. COMPUTER, 42(12):98–101.

Clements, P. C. (1996). A Survey of Architecture De-scription Languages. In Proceedings of the 8thInternational Workshop on Software Specifica-tion and Design, IWSSD ’96, pages 16–, Wash-ington, DC, USA. IEEE Computer Society.

Dashofy, E., van der Hoek, A., and Taylor, R.(2001). A highly-extensible, XML-based archi-tecture description language. In Software Archi-tecture, 2001. Proceedings. Working IEEE/IFIPConference on, pages 103–112.

Eclipse (2014). Sirius. http://www.eclipse.org/sirius/.

El Kouhen, A., Dumoulin, C., Gerard, S., andBoulet, P. (2012). Evaluation of modelingtools adaptation. Available: https://hal.archives-ouvertes.fr/hal-00706701.

Garlan, D., Monroe, R., and Wile, D. (2010).Acme: An architecture description interchange

language. In CASCON First Decade High Im-pact Papers, CASCON ’10, pages 159–173,Riverton, NJ, USA. IBM Corp.

Gronninger, H., Krahn, H., Pinkernell, C., andRumpe, B. (2014). Modeling variants ofautomotive systems using views. In Tagungs-band Modellierungs-Workshop MBEFF:Modellbasierte Entwicklung von eingebettetenFahrzeugfunktionen.

OMG (2008). MOF model to text transformation lan-guage 1.0. Technical report, Object ManagementGroup.

OMG (2015). Unified modeling language (OMGUML), version 2.5. Technical report, ObjectManagement Group.

Oquendo, F. (2004). µADL: An architecture descrip-tion language based on the higher-order typed π-calculus for specifying dynamic and mobile soft-ware architectures. SIGSOFT Softw. Eng. Notes,29(3):1–14.

Schobbens, P.-Y., Heymans, P., and Trigaux, J.-C.(2006). Feature diagrams: A survey and a formalsemantics. In 14th IEEE International Require-ments Engineering Conference (RE’06), pages139–148. IEEE.

Taghavi, T. and Pimentel, A. (2010). Visualizationof multi-objective design space exploration forembedded systems. In Digital System Design:Architectures, Methods and Tools (DSD), 201013th Euromicro Conference on, pages 11–20.

van Leeuwen, C., de Gier, J., de Filho, J. O., and Papp,Z. (2014). Model-based architecture optimiza-tion for self-adaptive networked signal process-ing systems. In SASO 2014 - 8th IEEE Inter-national Conference on Self-Adaptive and Self-Organizing Systems.

Wichmann, A., Jager, S., Jungebloud, T., Maschotta,R., and Zimmermann, A. (2015). System ar-chitecture optimization with runtime reconfigu-ration of simulation models. In IEEE Interna-tional Systems Conference (SYSCON15).

Wichmann, A., Jager, S., Jungebloud, T., Maschotta,R., and Zimmermann, A. (2016). Specificationand execution of system otimization processeswith UML activity diagrams. In IEEE Interna-tional Systems Conference (SYSCON16).

Zakal, D., Lengyel, L., and Charaf, H. (2011). Soft-ware Product Lines-based development. InApplied Machine Intelligence and Informatics(SAMI), 2011 IEEE 9th International Sympo-sium on, pages 79–81.