Introduction

The Architectural Design decIsion Support framEwork – ADvISE is one of the contributions of the Software Architecture Group, Faculty of Computer Science, University of Vienna to the EU FP7 INDENICA project.

INDENICA introduces the notion of Virtual Service Platforms (VSPs) as a novel domain-specific approach to create service-based applications based on heterogeneous platforms, by resolving the quality, interface, and technology fragmentation that can be observed in today’s service platforms. To assist decision making for reusable architectural decisions, such as the ones needed in service-based platform integration, ADvISE is proposed for modeling reusable architectural decisions and architectural decisions under uncertainty (using Fuzzy Logic, see FuzzDS for more details) at different levels of abstraction, i.e., high-level as well as technology and domain specific levels. This approach enables us to semi-automate the decision making process for recurring architectural decisions and document the design rationale at low cost. This way, we support software architects in recurring design making processes, so that they can have more time left to spend on the challenging architectural problems that require creative thinking.

Apart from that, in order to keep architectural decisions and designs consistent and traceable to each other, we introduce formal links between the reusable architectural decisions and architectural designs. We achieve that by integrating ADvISE with View-based Modeling Framework – VbMF – a tool for implementing model-driven architectural view models. Thus, we provide maintenance support for evolving architectural decisions and designs. In particular, using the Architectural Knowledge (AK) Transformations Toolkit, a bridge between architectural decisions modeled in ADvISE and the architectural designs modeled with VbMF, we are able to automatically generate architectural designs from actual decisions and check for inconsistencies between them.

This documentation presents step by step how to model reusable architectural decisions and decisions under uncertainty and how to use these models to support software architects in architectural decision making. It also explains how to integrate architectural decisions in ADvISE with architectural designs (component-and-connector views) using the AK Transformation Language. ADvISE, as well as the rest of the tools integrated with it, can be adapted and modified according to the developers’ needs, as they are all available as open-source Eclipse plug-ins.

Toolsuite for Architectural Decision & Design Support

Eclipse Plug-ins

ADvISE tool as well as the tools that have been integrated to ADvISE are developed as Eclipse plug-ins organized in features. On the hard disk, an Eclipse based product is structured as a collection of plug-ins and each plug-in contains the code that provides some of the product’s functionality. Product’s plug-ins are grouped together into features, i.e., units of separately downloadable and installable functionality.

The Eclipse platform itself is structured as subsystems which are implemented in one or more plug-ins. The subsystems are built on top of a small runtime engine. The plug-ins that make up a subsystem define extension points for adding behavior to the platform. The Platform Runtime defines the extension point and plug-in model. In particular, it dynamically discovers plug-ins and maintains information about the plug-ins in a platform registry using the OSGi framework. Other subsystems implement the user cockpit for navigating the platform (Workbench UI), define the API for creating and managing resources (Workspace), provide a team programming model for managing and versioning resources (Team), etc. The Eclipse SDK includes the basic platform plus two major tools that are useful for plug-in development. The Java development tools (JDT) implement a full featured Java development environment. The Plug-in Developer Environment (PDE) adds specialized tools that streamline the development of plug-ins and extensions. Thus, new tools can be added to the platform by building plug-ins that extend the system.

The following figure illustrates the available features (ADvISE, FuzzDS and AK Transformation Language) and the plug-ins they include ^[1].

Plugins

In the following, a short overview of the plug-ins functionality is given.

ADvISE

ADD Models: It contains the definition of meta-models for modeling of reusable architectural decisions based on Questions, Options and Criteria (QOC) ^[2] and questionnaires for decision support. Also, the code for creating, modifying and persisting the architectural decision models.
ADD Wizards: It provides Eclipse wizards for creating ADvISE projects and models.
ADD Documentation: The documentation of architectural decisions and their rationale can be generated automatically from the answered questionnaires.
ADD Editors: Two kinds of editors are provided. One for editing the architectural decision models and one for editing the questionnaires generated from these models. Also, the questionnaires for assisting architectural decision making are generated automatically from the decision models.
ADD Views: It provides two customized Eclipse views, one for the management of resources and one for visualizing the decided and open decision points during architectural decision making. This plug-in contains also code for manipulating all related artifacts (create, delete, rename, etc.).

FuzzDS

FuzzDS Editor: It provides a textual Editor for editing reusable fuzzy models (based on Fuzzy Logic and fuzzy rules) to be used for architectural decision making under uncertainty (see FuzzDS for more details).
Fuzzy Inference Engine: The Fuzzy Inference Engine infers the best-fitting solutions in a specific context (based on the fuzzy models) given specific requirements by leveraging the fuzzy models that have been edited with the FuzzDS Editor.

AK Transformation Language

AK Transformation Language Editor: The transformation from actual decisions to design views is achieved by executing transformation actions that apply on these views. These transformation actions (simple or compound) can be edited using the AK Transformation Language Editor. Not only transformation actions but also templates of transformation actions can be edited using this editor. The .action files can be, thus, also edited using a template language editor (Velocity).
ADDs-to-Views Binder: Transformation actions that are edited in template form need to be bound to actual values when actual decisions are made. The bound actions are executable and can afterwards transform the design views.
AK Transformation Engine: The transformation actions enact on the design views using the AK Transformation Engine. Also, consistency checking rules (constraints) for checking the conformance of the architectural decisions to the corresponding designs are generated as soon as the transformation actions modify the design views.
Consistency Checker: It validates the constraints for consistency checking between architectural decisions and designs and highlights detected inconsistencies.

Plug-in Dependencies and Technologies

The following figure shows the dependencies between the various plug-ins introduced before, as well as the technologies and frameworks they are based on. ADvISE (with its integrated tools) is an Eclipse RCP application ^[3]. FuzzDS can be used either stand-alone or through the ADvISE user interface. The AK Transformation Language requires both ADvISE and the VbMF Framework plug-ins as it works as a bridge between these tools.

Plugins-dependencies

The grammars for the AK Transformation Language (DSL) as well as the FuzzDS DSL were created with Xtext framework ^[4]. Xtext is also used to generate Eclipse-based textual editors that can support several useful features such as syntax highlighting, content assist and auto-completion, validation and quick fixes, automated external cross-references resolutions, and so on. The Eclipse Modeling Framework (EMF) ^[5] project was used to create all required models (e.g., architectural decision models) and the code for editing these models. Where model-to-model or model-to-text generation is required (e.g., AK Transformation Engine) Xtend2 ^[6] was used. The template binding of transformation actions and constraints in template form was done with the Velocity Template Engine ^[7]. Finally, the fuzzy inference system of the open-source jFuzzyLogic package ^[8] was adapted for the needs of FuzzDS.

Architectural Decision Meta-model

An architectural decision model, as depicted below contains architectural decisions – decision points, and for each decision point a set of questions along with potential options or answers are introduced. The selection of an option can lead either to a solution (often pattern-based) or trigger follow-on decisions and questions. A question that requires a free-text answer can also be followed by a next decision or question. Also, an option can constraint other options (e.g., force or be incompatible with).

Metamodel

C&C View Model

ADvISE has been integrated with component-and-connector view models of VbMF using the AK Transformation Language. Of course it can be integrated well with other architectural views with the corresponding development effort. Here, we describe the component models that have been used in this tooling. Component models are often used as an essential view for describing software architectures. Without loss of generality, we propose the use of a generic, abstract component model built upon the essential concepts such as components, ports, and connectors to specify the underlying system and software architectures.

For the sake of integrating different models, we define a Core model that provides essential concepts such as NamedElement and AnnotatedElement. A View and its Element are abstractions of a design model and its model elements, respectively. A component model reflects a view of software architectures that comprises various Components wired by several Connectors via the component’s Ports. A component may have several sub-components. Property and Stereotype elements enrichComponents, Connectors and Ports with additional information.

Core

Component

Installation

The Eclipse plug-ins have been developed and currently work stably in Eclipse 3.7.2 (Indigo). To install ADvISE go to Help → Install New Software… and add the ADvISE Update Site – http://indenica.swa.univie.ac.at/public/advise to download the latest version of the tool.

Update-site

Installation

At this point you can select the features you want to install. Note that ADvISE requires FuzzDS and that AK Transformation Language requires ADvISE and VbMF. To save time you can download the Eclipse version with the Eclipse Modeling Tools fromhttp://www.eclipse.org/downloads/packages/eclipse-modeling-tools/indigosr2 and afterwards download the last versions of Xtext and Xtend2 from the corresponding Update Site. In order to install and use ADvISE you have to install the Eclipse Modeling Framework (EMF), Xtend2 and Xtext.

ADvISE Requirements

To use the AK Transformation Language you will also need to install VbMF and its dependencies.

AK Transformation Language Requirements

FuzzDS Requirements

Xtext/Xtend2

User’s Guide

In this guide, the functionality of the ADvISE tooling is presented step-by-step.

ADvISE

ADvISE Perspective

The ADvISE perspective contains all views and editors (parts) that are used when working with ADvISE and the tools integrated with it. To activate the perspective go to Window → Open Perspective → Other… → ADvISE.

Perspective

ADvISE Views

ADvISE offers two types of views: the ADvISE View for the management of models and questionnaires and the Questionnaire View which gets synchronized when questionnaires for architectural decision making are filled in, and shows unassigned, assigned and made decisions at real-time.

AdviseView

Available actions provided in ADvISE View:

Create new architectural decision model
Create new group for organizing architectural decision models
Rename group/architectural decision model/questionnaire
Delete group/architectural decision model/questionnaire
Refresh all projects
Validate architectural decision model
Generate Questionnaire (from architectural decision model)

QuestionnaireView

Questionnaire View:

Decisions group contains all made decisions
Unassigned questions have not been answered yet
Assigned questions have been already answered
Questions indicated with (M) are mandatory
Questions indicated with (O) are optional
Questions in green color are activated
Questions in gray color are deactivated

Activate Views

To activate the views separately go to Window → Show View → Other… Under the group ADvISE activate the views ADvISE View and Questionnaire View.

Views

ADvISE Wizards

New ADvISE Project

To create a new ADvISE project go to File → New → Other… → ADvISE wizards and select ADvISE Project. A new project with the following structure is created:

project_name
- Decision Groups (root folder for architectural decision models)
  - ADModel (empty architectural decision model)
- Questions (root folder for questionnaires)

New ADvISE Decision Model

To create a new ADvISE model go to File → New → Other… → ADvISE wizards and select Architectural Decision Model. An empty decision model (with extension .admodel) is created in the selected folder. The decision model editor contains 3 tabs: Architectural Decisions, Design Solutions and Design Patterns for editing the architectural decisions and the solutions and patterns related to them. Every time you edit your model (and the workspace resources are refreshed) the “Save” and “Save all” buttons get activated. Press “Save All” to save all the changes you have done so far or the “Undo” button to undo the changes (one by one) after the last save. You can switch between horizontal and vertical view of your editor by using the buttons and respectively.

Wizard

Activate Refresh for Changed Resources: In order to keep the ADvISE Decisions View and the workspace resources synchronized to each other you need to allow the Eclipse workspace refresh automatically. Go to Window → Preferences → General → Workspace and check “Refresh on access”.

Edit Design Patterns

Go to the Tab Design Patterns and press “Add”. A pattern with the name NewPattern will be created. You can give the Name and Description of the pattern and change your selection to see the changes in the list of patterns on the left. You can delete one or more patterns by selecting the pattern(s) and pressing “Delete”.

DesignPatterns

Edit Design Solutions

Go to the Tab Design Solutions and press “Add”. A solution with the name NewSolution will be created. You can give the Name and Description of the solution and relate the solution to one or more Design Patterns. To add/remove related Patterns press the buttons and under the Patterns table respectively. After you change your selection you can see the changes in the list of solutions on the left. You can delete one or more solutions by selecting the solution(s) and pressing “Delete”.

DesignSolutions

RelatedPatterns

Edit Architectural Decisions

Go to the Tab Architectural Decisions and press “Add”. A decision with the name NewAD will be created. You can give the following information of the decision:

Name: name of decision
Level: design level for decision
Scope: description of decision
Status: status of decision (In Progress, Finished, Not Reviewed)
IsFirst: indicates if it is the first decision to make before making follow-on decisions (i.e., it indicates the first decisions to be made in the generated questionnaire)
Order: indicates the order of the decision as it will appear in the generated questionnaire

Each decision contains a list of questions. To add/remove a question press the buttons and under the table of questions respectively. You can edit a question by double-clicking it. To set a question as first question (i.e., first question(s) to be answered for the corresponding decision in the generated questionnaire) select the checkbox “First”. You can delete one or more decisions by selecting the decision(s) and pressing “Delete”.

ArchitecturalDecisions

Edit Questions

You can add either a Question with Answer or a Question with Options.

TypeOfQuestion

QuestionWithOptions

QuestionWithAnswer

A question expecting alternative options contains the following information:

Name: symbolic name of the question
Question: actual question
mandatory/optional: check if question is mandatory or optional
Options: press the buttons and to add/delete options respectively

When an option is selected the following get activated:

Solution: select the solution that corresponds to the selected option (if exists)
next Decisions: add/delete follow-on decisions
next Questions: add/delete follow-on questions
forces Options: add/delete options that are forced by the selection of this option
incompatible Options: add/delete options that are incompatible with the selection of this option

The Fuzzy Decision Support field can be used to add fuzzy logic decision support (see for more details) between alternative options. Only .fuzzypattern files can be selected. You can read more about editing these files in the documentation of FuzzDS.

A question expecting a free-text answer contains the following information:

Name: symbolic name of the question
Question: actual question
mandatory/optional: check if question is mandatory or optional
next Decisions: add/delete follow-on decisions
next Questions: add/delete follow-on questions

Architectural Decision Questionnaires

ADvISE framework uses model-to-model transformation to generate Questionnaires from the architectural decision models. To generate a questionnaire from an architectural decision model right-click on the model in the ADvISE View and click “Generate Questionnaire”. Choose the name and location of the generated questionnaire. This questionnaire will be used to make a decision for a specific problem at hand and is based on the reusable architectural decision model.

Generate-questionnaire

Double-click on the generated questionnaire to edit the questionnaire with the corresponding editor. Answering the questionnaire contains clicking on the available options to the questions and filling-in the required information. Whenever an option is selected you are guided to the next questions you have to consider for making your decision, as well as to the follow-on decisions. Decisions and questions that are grayed-out can not be answered at this stage. The Questionnaire View shows which options have been decided and which are left open for decision and is synchronized with the questionnaire. Questions indicated as (M) or (O) are mandatory or optional respectively. Changing a previous option may lead to invalidated follow-on questions and options which are recalculated real-time from the constraints introduced in the respective architectural decision model (incompatible with, etc.). Questions that get invalidated by decision changes have to be answered again.

Questionnaire

Save/Reset a Questionnaire

To save a questionnaire press on button “Save”, so you can re-open and re-edit your questionnaire. Press “Reset” to discard all answers and re-start with the questionnaire.

Fuzzy Logic Support

If a question has been configured to use fuzzy decision support a button Fuzzy Decision Support will appear next to the question. Press the button to use the wizard that will guide you through the decision making (see for more details).

Generate Documentation

Press the “Export” button to generate documentation (in HTML format) of the made decisions. The exported documentation is based on the answers that have been given to the questionnaires and the solutions that are implied by the selected options and can be also edited manually.

FuzzDS and Integration with ADvISE

FuzzDS (Fuzzy Decision Support) is a fuzzy logic based tool for providing semi-automatic support for (pattern-based) architectural decision making under uncertainty. It provides the following facilities:

Domain-Specific Language (DSL) Editor for editing pattern-based decision models.
Reference and extension of pattern-based decision models.
Fuzzy Inference System for inferring best-fitting solutions using fuzzy logic.
Architectural Decision Making Wizard for guiding the software architect in decision making process (based on the fuzzy models).
Automatic architectural decision documentation.

Overview

FuzzDS aims to provide semi-automated support for specific recurring ADDs and resolve their inherent uncertainty. Rather than creating a new design from scratch, it automates the decision making for design problems that emerge repetitively in a specific context. Our purpose is to cover the whole design space for a design situation at hand consisting of generic, as well as technology-specific decisions. To address uncertainty we use Fuzzy Logic , which allows the numerical encoding of the vague linguistic values software engineers use to describe requirements, as well as forces and consequences of reusable ADDs. Key concepts of Fuzzy Logic are fuzzy sets and their membership functions, which express degrees of membership spanned in the interval [0,1] for the elements of the fuzzy sets. The linguistic values can be interpreted using fuzzy sets which get mapped to overlapping membership functions (e.g., gaussian, trapetzoidal, etc.). For example, the property performance could be described as high, medium or low and these linguistic values can be mapped to overlapping membership functions, as shown in the figure below.

Membership

The following figure presents an overview of our approach, namely the participating tools and roles. We distinguish between two stakeholder roles: software architect (expert) and software architect (user). That is, different levels of experience are expected for architects who create the fuzzy logic models and users of our approach. The software architects (experts) use the Fuzzy Decisions Models Editor (a textual DSL editor) to capture architectural knowledge. A decision model contains alternative design solutions along with their properties and quality attributes and a set of expert IF–THEN fuzzy rules that guide the design decisions. From these decision models we derive specialized fuzzy decision models in which domain and technology specific knowledge can be included. Both kinds of decision models get stored in a Fuzzy Decision Model Repository for reuse by a Fuzzy Inference System. The software architects (users) use the Requirements Editor to give the desired requirements in crisp values using a grading system (e.g., 1–10) for fuzzy input variables like performance and reliability and binary values (i.e., 0, 1) for variables that accommodate only two values (e.g., Yes, No) like supports acknowledgment.

The Fuzzy Inference System returns the appropriate design alternatives and their ranking for the given requirements by combining and evaluating the fuzzy rules already defined in the fuzzy models. The list of the best-fitting design solutions is supposed to be used as a decision aid for the software architect who makes the final decision. After that, the input requirements and the inferred design solutions can be synthesized to produce ADD Documentations.

Fuzzy

FuzzDS Editor

The DSL editor is based on the Xtext framework. It offers highlighting, auto-completion and an outline view. In the following examples we will see how to use this DSL.

Language Specification

The main elements defined in a fuzzy decision model expressed in our DSL are the alternative Patterns that can be used as solutions for a design problem, as well as their forces and rules. A list of alternative patterns can belong to a group and can import other fuzzy decision models expressed in our DSL, thus inheriting their forces, membership functions and rules. This way, we can create technology-specific fuzzy models which are based on generic fuzzy models and their Patterns are pattern implementations or pattern variants (ofType) of the Patterns included in the general model. The membership functions of the fuzzy sets can be defined using some standard function types, i.e., gaussian, trapetzoidal, triangular, piece-wise linear and singleton (gauss, trape, etc.) independently (schemas) and reused by multiple pattern forces. The fuzzy inference system (e.g., the fuzzy inference method) can also be configured by the user. The rules have the following syntax: if condition then Patternwhere the condition can contain conjunctions and disjunctions or combinations of them of the form force_name is force_value or force_name not force_value. Also, weights can be assigned to the rules using the keyword with weight. The formal specification of the DSL given below is defined as an Xtext language grammar.

grammar at.ac.univie.swa.advise.fuzzds.FuzzyPatternModel with org.eclipse.xtext.common.Terminals
 
generate fuzzypatternmodel "http://cs.univie.ac.at/swa/fuzzypatternmodel"
import "http://www.eclipse.org/emf/2002/Ecore" as ecore
 
Model:
   ("group" name=ID (":" description=STRING)?)
   (model=Patterns);
Patterns:
   (imports+=GenericGroup)?
   (patterns+=Pattern)+
   (forces=ForceList)
   (schemas=SchemaList)?
   (rules=RuleList)
   (config=Configurations)?;
ForceList:
   "forces"
      (forceList+=Force)+
   "end";
RuleList:
   "rules"
      (ruleList+=Rule)+
   "end";
SchemaList:
   "schemas"
      (schemaList+=Schema)+
   "end";
GenericGroup:
   "import" importedNamespace = FqnWildcard;
FQN returns ecore::EString:
   ID ('.'ID)*;
FqnWildcard:
   FQN ('.*')?;
Pattern:
   "Pattern" name=ID ("ofType" parentPattern=[Pattern|FQN])? (":" description=STRING)?;
Force: 
   name=ID (schema=[Schema|FQN])? "{"
      (values+=ForceValue)*
   "}";
ForceValue:
   name=ID (":" membership=MembershipFunction)?;
enum MembershipType:
   gauss1 | gauss2 | pi | trian | trape | singleton;
MembershipFunction:
   membership=MembershipType "["(values+=Number)*"]";
Schema:
   name=ID "{"
      functions+=MembershipFunction*
   "}";
Rule:
   name=ID "-->" "if" (parOpen+=OpenParenthesis)* (firstPredicate=Predicate) (next+=NextPredicate)* "then" action=[Pattern] ("with" weight=Number)?;
NextPredicate:
   connector=Connector (parOpen+=OpenParenthesis)* predicate=Predicate (parClose+=CloseParenthesis)*;
Predicate:
   variable=[Force|FQN] (positive="is" | negative="not") property=ID;
Connector:
   "and" | "or";
OpenParenthesis:
   "(";
CloseParenthesis:
   ")";
Number:
   INT | "-"INT | "-"INT"."INT | INT"."INT;
Configurations:
   {Configurations}
   "config" "{"
   ("activation=" activation=("MIN" | "PROD"))?
   ("operatorAND=" operatorAND=("MIN" | "PROD" | "BDIF"))?
   ("accumulation=" accumulation=("MAX" | "BSUM" | "NSUM"))?
   "}";

Fuzzy Application-Generic Decision Models: An Example

Here, we explain how to define fuzzy pattern-based decision models. Patterns that refer to a specific domain, problem, or technology can be organized in groups. In the following example, we list the alternative design patterns for asynchronous invocations ^[9] and related solutions that allow client applications to resume their work while waiting for response from a remote invocation:

group async
 
Pattern fire_and_forget
Pattern sync_with_server
Pattern poll_object
Pattern result_callback
Pattern messaging
Pattern sync_void
Pattern sync_result

Before writing the rules for the pattern selection we need to define the patterns’ forces and consequences and their possible values – the fuzzy sets. Along with the fuzzy sets, we need to select their membership functions. For the quality attributes (e.g., reliability) we may define triangular, gaussian, etc. membership functions (e.g., gauss[mean stdev]). For properties that do not contain fuzziness (e.g., supports acknowledgment can be either yes or no) we use singleton membership functions. The patterns and pattern variants are the values of the fuzzy output variable pattern with a singleton membership function, as they do not contain any fuzziness as well. We define quality attributes with their linguistic values along with their membership functions as following:

forces
    reliability gauss {low medium high}
    performance gauss {low medium high}
    acknowledgement yesno {no yes}
    log_application_error yesno {no yes}
end
schemas
    gauss {gauss[1 2] gauss[5 2] gauss[10 2]}
    yesno {singleton[0] singleton[1]}
end

The precise shape of the membership curves is not so important, as their approximate placement on the universe of discourse, the number of curves used, and their overlapping character are the most important ideas. The overlapping of the curves helps us express the ambiguous and vague borders between the linguistic attribute values. Finally, the experts’ experience gets translated into fuzzy rules as in the following example:

rules
    rule1 --> if performance is high and reliability is low and acknowledgement is no and log_application_error is no then fire_and_forget
    rule2 --> if performance is medium and reliability is medium and acknowledgement is yes and log_application_error is no then sync_with_server
    rule3 --> if performance is high and reliability is medium and acknowledgement is yes and log_application_error is yes then poll_object
    rule4 --> if performance is high and reliability is medium and acknowledgement is yes and log_application_error is yes then result_callback
    rule5 --> if performance is low and reliability is medium and acknowledgement is yes and log_application_error is no then sync_void
    rule6 --> if performance is low and reliability is medium and acknowledgement is yes and log_application_error is yes then sync_result
    rule7 --> if performance is high and reliability is high and acknowledgement is yes and log_application_error is yes then messaging
end

Fuzzy Application-Specific Decision Models: An Example

In order to include technology and system-specific knowledge, pattern implementations extend the generic patterns and thus inherit their membership functions and rules. In the following example, we derive the Apache CXF technology variant for the aforementioned asynchronous invocation patterns. We import the general fuzzy model (async) and define the pattern implementations as subtypes (ofType) of the design patterns that are defined in the following code snippet. For instance, oneway is the CXF implementation of the fire and forget pattern. Apart from pattern implementations we can also define pattern variants using the same notation.

Fuzzy Inference System

For the fuzzy inference the open source Fuzzy Logic library jFuzzyLogic has been used. jFuzzyLogic implements the Fuzzy Control Language (FCL) for specifying fuzzy models and the fuzzy inference system.

Use as Standalone

After defining the design space (i.e., general and technology-specific fuzzy pattern-based models and pattern inter-dependencies graphs) using the FuzzDS Editor, a wizard guides the user through architectural design decision making. To open the wizard right-click on a .fuzzypattern file and click on Fuzzy Decision Support.

Integration with ADvISE

FuzzDS can also be used integrated with ADvISE for selecting between alternative options that contain uncertainty. In this case, when creating the architectural decision model a fuzzy model must be related to the specific question. Afterwards, when questionnaires are generated from this architectural decision model a button “Fuzzy Support” will appear next to the corresponding question.

Requirements Editor

The requirements editor is automatically generated from the fuzzy pattern model. Give your desired requirements and press Next. The fuzzy inference system will calculate the best-fitting solutions for the given requirements.

Requirements-editor

Make Final Decision

Select one of the possible alternatives that were calculated at the previous step. The best-fitting solution (see also generated fuzzy outputs) is pre-selected.

Alternatives

Architectural Decision Documentation

This last page contains a preview of the architectural decision documentation. Press Finish to save the decision, so that you are able to edit/change its fields in the future. You can navigate back and forth, change the requirements, recalculate the best-fitting solutions and change the final decision.

Final-decision

AK Transformation Language and Integration with ADvISE

The AK Transformation Language works as a bridge between ADvISE for modeling architectural decisions and supporting architectural decision making and VbMF for modeling architectural views.

AK Transformation Language Editor

Language Specification

Essentially, the goal of the AK transformation language is to express the actions that create or update the underlying architectural models (e.g., C&C models) according to the intentions of the software architects reflected by the design decisions. Unlike general model transformation languages (as ATL) our domain-specific language (DSL) is intended to provide simple and comprehensible architecture-specific transformation actions, as well as the structures for grouping, extending and inheriting these actions. We present a formal definition of the AK transformation language in terms of a EBNF like syntax developed using the Xtext DSL framework ^[10]. Please note that the square brackets in Xtext enable cross-references to other models, in our case, to the elements of the VbMF C&C view. We also use Xtext to generate an Eclipse-based textual editor that can support several useful features such as syntax highlighting, content assist and auto-completion, validation and quick fixes, automated external cross-references resolutions, and so on.

The core of the language consists of basic actions that can be used to create or alter individual elements of the architectural models, for instance, creating a new component, deleting an existing connector, or updating a port. In addition, we introduce special structures, such as Group, Loop, and Compound to support the compositions and extensions of the predefined actions. A Group indicates the grouping of a finite set of components that are sub-components of a particular component. For efficiently handling the iteration and application of similar actions to a finite set of elements of the design model, a Loop can be used. A Compound represents a structure that embraces multiple actions and even other Compounds. Through an extension, a Compound can inherit the definition of existing Compounds and extend the inherited behavior with additional actions. The semantics of a Compound is an atomic (i.e., all-or-nothing) sequential execution of its inherited compounds and constituting actions.

The core actions of the AK transformation language mainly aim at expressing particular changes to individual elements of the corresponding VbMF C&C view. We can also associate the options and answers of a certain ADD model with one or many transformation actions in template form, in order to enable the automation of creating and/or updating of the architectural C&C models. In this case, once the generated questionnaires from the ADD model are answered resulting in concrete decisions, the related actions will be bound to concrete elements of the underlying architectural models.

Action:
  Add | Delete | Update | Group | Loop;
Add:
  AddComponent | AddConnector | AddPort | AddProperty | AddStereotype | AddPrimitive;
AddComponent:
  "add component" name=STRING;
AddConnector:
  "add connector" name=STRING "from" source=[component::Port|FQN] "to" target=[component::Port|FQN];
AddPort:
  "add port" name=STRING "kind=" kind=PortKind "to" component=[component::Component|FQN];
AddStereotype:
  "add stereotype" "<<" text=STRING ">>" "to" target=[core::Element|FQN];
AddProperty:
  "add property" name=STRING "type=" type=STRING "value=" value=STRING "to" target=[core::Element|FQN];	
AddPrimitive:
  "add compound" primitive=[Compound|FQN] name=STRING "("(args+=ID|LIST)+")";
Delete:
  DeleteComponent | DeleteConnector | DeletePort | DeleteProperty | DeleteStereotype;
DeleteComponent:
  "delete component" component=[component::Component|FQN];
DeleteConnector:
  "delete connector" conn=[component::Connector|FQN];
DeletePort:
  "delete port" port=[component::Port|FQN];
DeleteProperty:
  "delete property" property=[component::Property|FQN];
DeleteStereotype:
  "delete stereotype" stereotype=[component::Stereotype|FQN];
Update:
  UpdateComponent | UpdateConnector | UpdatePort | UpdateProperty | UpdateStereotype;
UpdateComponent:
  "update component" component=[component::Component|FQN] "name=" newName=STRING;
UpdateConnector:
  "update connector" conn=[component::Connector|FQN] "name=" newName=STRING;
UpdatePort:
  "update port" port=[component::Port|FQN] ("name=" newName=STRING)? ("kind=" newKind=PortKind)?;
UpdateProperty:
  "update property" prop=[component::Property|FQN] ("name=" newName=STRING)?  ("type=" newType=STRING  "value=" newValue=STRING)?;
UpdateStereotype:
  "update stereotype" stereotype=[component::Stereotype|FQN] "text=" newText=STRING;
Group:
  "group" component=[component::Component|FQN] "container" container=[component::Component|FQN];
Loop:
  "for" "(" element=ID ":" (params+=FQN)+")" (actions+=Action)+ "end";
Compound:
  "compound" name=ID ("extends" (parent+=[Compound|FQN])*)? spec=Spec;
Spec: "("(args+=ID)+")" "{" (actions+=Action)* "}";
Import: "import" importedNamespace=FqnWildcard;
 
enum PortKind:	provided="PROVIDED"|required="REQUIRED";
FQN returns ecore::EString: ID ("." ID)*;
FqnWildcard: FQN ".*"?;
LIST: ID","ID(","ID)*;

Simple Transformation Actions

A simple transformation action may lead to addition, modification or deletion of a single component, connector, property, etc. For instance, a selection of an option in an ADD model will lead to the introduction of a new stereotype for the component. In the following listing a new stereotype with the value of the template variability TypeOfComponent will be created and attached to the component denoted by the template variability A. We use variable access in the form ${p-name} to refer to the parameter p-name.

add stereotype <<"${TypeOfComponent}">> to ${A}

The binding of the template variables during decision making will result in an executable transformation action, such as the one in the following example.

add stereotype <<"Remote Proxy">> to example.ServiceProxy

Compound Transformation Actions

Simple transformation actions may be useful in simple cases where a component or connector has to be added or modified, but usually an architectural decision entails more than one transformation actions that will enact on the corresponding architectural view. In the course of decision making, software architects often leverage several recurring architectural elements and structures such as proxies, adapters, gateways, layers, etc. The idea of proposing primitives as fundamental elements for describing such recurring design patterns and architectural styles has been investigated by various studies. For example, Zdun and Avgeriou described architectural patterns through a number of recurring architectural primitives in the component-and-connector view using UML profiles ^[11]. Mehta and Medvidovic developed a framework for defining abstract primitives shared by all architectural styles for composing their elements ^[12]. In this section, we will describe how to define recurring architectural primitives for modeling certain patterns or styles as action sets, as an example of how to realize reusable AK transformations with our language.

In the following code lines, we present the indirection compound. Indirection happens when one or more related “proxy” components receive a message on behalf of one or more “target” components, forward the message to these “targets” and receive results from these “targets” also through the “proxy” components . Proxies and adapters are examples of indirection. The parameters cv, A, and B refer to the target component view, the target component, and the client respectively. The variable n will be bound to the name of the compound “instance” (e.g., Proxy, Adapter, etc.).

compound indirection (cv A B) {
  add component "${A}${n}"
  add port "${A}${n}_I1" kind=PROVIDED to ${cv}.${A}${n}
  add port "${A}${n}_I2" kind=REQUIRED to ${cv}.${A}${n}
  add port "${A}_I" kind=REQUIRED to ${cv}.${A}
  add port "${B}_I" kind=PROVIDED to ${cv}.${B}
  add connector "${A}_I_${A}${n}_I1" from ${cv}.${A}.${A}_I to ${cv}.${A}${n}.${A}${n}_I1
  add connector "${A}${n}_I2_${B}_I" from ${cv}.${A}${n}.${A}${n}_I2 to ${cv}.${B}.${B}_I
  add stereotype <<"${n}">> to ${cv}.${A}${n}
}

An example of using the indirection compound is presented here:

add compound indirection "Proxy" (example Facade Service)

This compound action will create a proxy for invoking the component “Service” from the component “Facade”. This will happen by replacing the variables n, cv, A and B with “Proxy”, the C&C view name “example” and the components “Service” and “Facade”, respectively. The transformation of the C&C view includes the creation of a component, two connectors, the corresponding ports and a stereotype. The execution of the compound transformation action triggers the execution of its containing actions. In our example, the enactment of the previous compound transformation action will trigger the execution of the following primitive actions.

add component "ServiceProxy"
add port "ServiceProxy_I1" kind=PROVIDED to example.ServiceProxy
add port "ServiceProxy_I2" kind=REQUIRED to example.ServiceProxy
...

Consistency Checking Rules

Consistency checking is an important mechanism to ensure the integrity of the design models under consideration. For each transformation action that is executed a corresponding OCL-like constraint for consistency checking is automatically generated. The following example checks that a component that has been added by a transformation action exists in the C&C model.

context component::ComponentView ERROR "ADD ${ADD}: Component ${A} does not exist":
    element.typeSelect(component::Component).exists(c|c.name == "${A}");

We have designed and developed respective constraint templates for each AK transformation language element and each architectural primitive defined above. The combination of transformation actions with automatically generated constraints that check that the transformation’s semantics are not violated in the C&C diagram, enables us to allow developers and architects to manually change the C&C model. If a manual change violates an architectural decision that has triggered transformation actions, the corresponding constraint checking will signal an error.

Mapping between Architectural Decisions and C&C Views

The ADvISE tooling provides launchers for binding transformation actions in template form according to actual architectural decisions and also for executing these transformation actions.

Running the Bind Action Execution Launcher requires the following arguments:

Mapping File: a property file that includes information for binding not included in the questionnaire (e.g. the name of the component model, names of components, etc.)
Questionnaire: the questionnaire name which will provide the information for the binding of the transformation actions
Action Template: file containing the transformation actions in template form
Implementation Class: a class that implements the mapping between the questionnaire options and the transformation actions that have to be bound

Bind-launcher

Running the Transformation Action Execution Launcher requires the following arguments:

Action File: contains executable transformation actions
Input Component View: the component view that will be transformed by the transformation actions
Output Component View: the output component view, result of the transformation
Constraints: file containing the generated constraints for consistency checking between the architectural decisions and the component view

Execute-launcher

Developer’s Guide

ADvISE is open-sourced under a mixed MIT+BSD license to enable the utmost freedom in acquiring, modifying, using, and distributing the implementation.

Download the complete source of ADvISE.

The development environment of ADvISE requires the following:

Examples

The source code of ADvISE contains an example project (Indenica-CaseStudy) based on the INDENICA case study. In particular, it contains the following:

An architectural decision model (/IndenicaDecisions/InterfaceDesign.admodel) about Interface Design and two questionnaires (/IndenicaDecisions/OperatorInterface.questionnaire and /IndenicaDecisions/YMSNotificationInterface.questionnaire).
A fuzzy model (/fuzzymodels/async.fuzzypattern) to be used by FuzzDS.
Transformation actions (/transformation-actions/actions/InterfaceDesign.action) in template form that correspond to the architectural decision model and shall be bound using the information from the questionnaires, the corresponding mapping files (*.properties) and the implementation of mapping from decisions to designs (test.bind.BindInterfaceDesign).
A component diagram (/cncmodels/Indenica.component) to be transformed by the generated executable transformation actions.

Known Issues

The ADvISE View is populated from the workspace resources. If a menu action (e.g., rename, delete, etc.) causes any errors, refresh first your project view and afterwards the ADvISE View.
Note that ADvISE is a research prototype and may contain bugs 🙂

Future Versions

Repair Plans for Detected Inconsistencies

In the future version of the tool, the handling of inconsistencies between the architectural decisions and the design views will be included. In the current version, the inconsistencies are detected by the validation of constraints; ADvISE tooling will provide support for resolving these inconsistencies.

Integration with Requirements Engineering

Architectural decisions are regarded as trade-offs between competing requirements. Thus, every architectural decision implies various requirements. In the future version of ADvISE the links between the requirements and the architectural decisions will be made explicit, so that the requirements can be traced to the actual decisions and down to the component views.

People

Ioanna Lytra – ioanna.lytra@univie.ac.at
Huy Tran – huy.tran@univie.ac.at
Uwe Zdun – uwe.zdun@univie.ac.at

↑ Please note that the plug-ins here are described in terms of their functionality and not in terms of physical Eclipse projects.
↑ Allan MacLean, Richard M. Young, Victoria M. E. Bellotti, and Thomas P. Moran. 1991. Questions, options, and criteria: elements of design space analysis. Hum.-Comput. Interact. 6, 3 (September 1991), 201-250
↑ http://www.eclipse.org/home/categories/rcp.php
↑ http://www.eclipse.org/Xtext/
↑ http://www.eclipse.org/modeling/emf/
↑ http://www.eclipse.org/xtend/
↑ http://velocity.apache.org/
↑ http://jfuzzylogic.sourceforge.net/
↑ M Voelter, M Kircher, and U Zdun. Remoting Patterns. John Wiley & Sons, 2004.
↑ http://www.eclipse.org/Xtext/
↑ Uwe Zdun and P. Avgeriou. Modeling Architectural Patterns Using Architectural Primitives. In 20th ACM Conf. on Object-Oriented Programming, Systems, Languages & Applications (OOPSLA), pages 133–146. ACM Press, 2005
↑ Nikunj R. Mehta and Nenad Medvidovic. Composing architectural styles from architectural primitives. In 9th European Software Engineering Conf. held jointly with 11th ACM SIGSOFT Int’l Symposium on Foundations of Software Engineering (ESEC/FSE-11), Helsinki, Finland, pages 347–350. ACM, 2003