7.3 Architecture And Analysis Framework
7.3.1 Framework Architecture
Based on the conceptual view on the framework, a prototypical implementation of the A3F is realized. To meet different application purposes and technological contexts and to reflect the extensibility and flexibility of the concept, the following architecture is chosen (figure 7.27).
GPML artifacts represent the point of interaction with the framework regarding data.
Therefore, all information that is modeled inEnterprise Architect®, a CASE tool that was chosen during the prototypical implementation, is stored in a connected model reposi- tory. Furthermore, this repository is the source of information for the A3F developer. In the following, individual components of this toolchain and in particular, the internals of the technical realization of A3F is described in detail.
Model Repository
First, theModel Repositoryis realized by a database. For instance, it could be a relational Postgres database, not necessarily running on the same hardware as the framework or the modeling tool. The applied schema of the relational database must be able to map and manage models according to any GPML including extension mechanisms. A solu- tion satisfying these requirements is given by Enterprise Architect®. Therefore, in the context of our prototype, the predefined database schema from Enterprise Architect®is
Architecture And Analysis Framework (A3F)
Meta-Models
Enterprise Architect
A3F Plugin Model Repository
Analyses ea-meta-model
egpp-meta-model
data-transformation-module
EAORM
MAF
REST
Server 3rd Party
Tooling utp2-meta-model
...
maf-analysis-module
egpp-testgen-module
...
GUI Framework Core
Figure 7.27: Internal architecture of the A3F
applied, which makes the interaction between the repository and the CASE tool work out of the box.
In contrast, A3F must provide a way to work with the information in theModel Repos- itory. A special Object Relational Mapper (ORM) has been developed for this purpose (see section 7.3.1). All in all, the architecture decision regarding a single and fully- fledged model repository provides a solid basis for flexible, distributed, and scalable work with the A3F.
Enterprise Architect®
As already mentioned, a special CASE tool for creating the GPMLs models was cho- sen in the course of the prototypical implementation, namely Enterprise Architect®. Enterprise Architect®is one of many modeling tools that are widely used in industry.
Especially the high distribution among industry partners in the context of the research projects mentioned at the beginning of this thesis has led to the choice of this tool. How- ever, Enterprise Architect® has several technological unique selling points that have additionally supported the choice.
On the one hand, the extension possibilities regarding the modeling support of DSLs are to be emphasized. This makes the use of the MDSD tool for modeling the DSLs explained in the concept more user-friendly, which has been implemented for some modeling languages in this thesis. On the other hand, Enterprise Architect® offers the possibility to extend the standard range of functions with plugins or to adapt it to your needs. This mechanism is used within the scope of the prototypical implementation.
In addition to the wide distribution and the mentioned extension possibilities, there are some technological aspects to mention, which are beneficial to the technical implemen- tation of our prototype.
• Integrated baseline mechanism: a snapshot of model elements and a possibility to restore a baseline
• Transparent data model: Extensive documentation on the repository data model available
• Scalable data management: support of various database systems/technologies All in all, the Enterprise Architect® thus provides a solid basis within the course of our prototypical implementation. However, the framework architecture enables the adoption of company-specific tooling, replacing Enterprise Architect® with any other CASE tool.
The Framework
On the left side of figure 7.27, the functional parts of the framework are shown. Here, a further distinction is made between the metamodel definitions, the analysis definitions, and the framework core.
A3F Metamodels At this point a multitude of metamodels including the correspond- ing transformation rules are defined. These can be classified according to the three-part division is shown in figure 7.26. In the first category GPMLs, theea-meta-modelis to be mentioned as a representative, whose components are explained in part VI (Sup- plementary Material). It is an Ecore representation of the Enterprise Architect® data model, which is the A3F counterpart of theModel Repository. In particular, theEAORM uses data from the Model Repository to create instances of this metamodel, which are then suitably processed. Work may either be carried out directly on the created models or a specified M2MT is applied to obtain a domain-specific representation.
In the category of DSLs, there is a variety of representatives, indicated by the dots in the figure. In contrast to the metamodels described above, instances of theu2tp-meta- model(see section 7.1.2), for example, are always derived from GPML instances. The combination of such metamodels together with the Integration Model represents the Omni Model approach in the context of the A3F.
The last remaining category is described by metamodels, which can be assigned to the presented PSD. Theegpp-meta-model(section 7.2.1) should be mentioned here as a representativeAnalysis-specific Metamodel. In principle, its instances can be derived from both of the presented metamodel categories by M2MTs, but usually, a domain- specific metamodel is used as the source due to the more concrete semantics.
A3F Analyses At this point, the processing modules of the framework are integrated, which ultimately specify the scope of functions. Here, a module can specify any num- ber of so-calledanalyses, which represent the smallest processing units. For example, the loading (ea_db_loader) and saving (ea_db_persister) of models from theModel Repositoryare implemented by separateanalyses. In addition to the specification of pro- cessing logic, which in turn requires certain metamodels from the previous section, other frameworks can be integrated. Specifically, the modulemaf-analysis-moduleinte- grates the Model Analysis Framework (MAF), which was developed at the professor- ship. The following list shows a selection of the current A3F analyses:
• history_loader: Load specific analysis results from previous executions
• data_transformer: Runs a model-to-model transformation script
• fta_cutsets: Computes cutsets for a fault tree
• documentation_generator: Generates a set of hypertext documentation for a set of model artifacts
Since a certain amount of configuration is necessary for addition to the pure implemen- tation of the functional logic, the following DSL was developed (see listing 7.5), which allows the specification of these configuration parameters and allows for a combination of analyses.
1 configuration:
2 (analyses+=analysis)* ;
3
4 analysis:
5 ’analysis’ classID=ID ’(’identifier=ID’)’
6 ((’{’ (parameters+=parameter)* ’}’) | ’;’) ;
7
8 parameter:
9 id=ID ’=’ value=STRING ’;’ ;
10
11 ID : LETTER (LETTER|DIGIT)* ;
12
13 fragment LETTER : [a-zA-Z\u0080-\u00FF_] ;
14 fragment DIGIT : [0-9] ;
15
16 STRING: ’"’ (~(’"’ | ’\\’ | ’\r’ | ’\n’) | ’\\’ (’"’ | ’\\’))* ’"’ ;
17
18 BLOCK_COMMENT: ’/*’ .*? ’*/’ -> channel(HIDDEN) ;
19
20 LINE_COMMENT: ’//’ ~[\r\n]* -> channel(HIDDEN) ;
21
22 WS : [ \t\r\n]+ -> skip ; // skip spaces, tabs, newlines
Listing 7.5: ANTLR grammar for A3F configuration language
As the ANTLR grammar shows, a so-called configuration consists of any number of analyses. Each analysis is specified by a uniqueclassIDand an instanceidentifier. This makes it possible to use several instances of the same analysis in one configuration.
Besides, a set of parameters can be specified for each analysis in the form of key-value pairs.
Dependencies between individual analyses can be created in different ways. There are data dependencies that result from interdependent parameters as well as there are implementation-related dependencies that result from splitting processing steps across several analyses.
A3F Core This part of the architecture forms the framework around the components already explained. In particular, Core implements the execution of an analysis con- figuration. For this purpose, the transferred configuration is first checked for certain properties that determine its validity:
• Syntactic conformance to the defined configuration grammar
• Absence of circular dependencies between included analyses
• Proper specification of mandatory analysis parameters
• Presence of dependencies (data and implementation) across individual analyses If the configuration was classified as valid, an execution sequence is determined from the underlying dependency graph. This sequence is chosen as optimally as possible by running independent analyses in parallel. In addition to the pure determination of the execution sequence, the administration of the processing results of the individual analyses and their exchange is managed. This means the framework manages all results of analyses in so-called ResultContainers. This applies to each execution round of a configuration, as well as across successive rounds. The presented components already allow functional variants of the A3F, with the possibility for customizing functional scope.
Framework Extensions
The extensions improve the interaction with the framework. To extend the scope of functions and interaction with other tools, additional components are planned, ex- plained at the end of this section.
Developer GUI - This A3F interface allows users to elegantly create and edit config- urations, checking their well-formedness at all times. Furthermore, the execution can be controlled, and especially the results of an analysis run can be examined in different views, e.g. for detailed examination of model transformation results as well as for vi- sual preparation of model artifacts. In addition to the presentation of analysis results, the user is provided with detailed log information on the execution of a configuration.
The main view of the GUI is shown in figure 7.28.
Server - To scale the framework better and to create a versatile interface, a server component was developed. This encapsulates the already presented framework and
provides all interaction points in form of a REST-API. All model data can be retrieved via this interface and thus be processed in other tools. Furthermore, the server compo- nent marks the basis for other extensions, which are explained in the following.
Enterprise Architect® Plugin - As already mentioned, the Enterprise Architect® used in the prototypical implementation offers the possibility to extend its function- ality with plug-ins. In this way, a further type of interaction with A3F was imple- mented. The plugin enables analysis configurations to be executed directly from Enter- prise Architect®and allows the calculated results to be visualized directly. The REST- API mentioned before is used here, which guarantees the decoupling of the CASE tool and the framework.
Future Extensions - In principle, further useful extensions are conceivable, but these were not realized in the course of the prototypical implementation. First of all, the realization of a frontend should be mentioned here, which is based on the REST-API and thus represents a more practicable implementation compared to theDeveloper GUI.
In particular, this allows for better scaling and cooperative work with the framework.
Besides the user interface, the data interface offers great potential for extensions. At this point, a connection of the framework to other model data sinks is useful and necessary to be able to leave the context of the MDSD tool. Conceivable is the connection to the so-calledModelBus, which is a technology that connects different tools in the context of MDSD and enables data exchange [35]. A technology that is used in theModelBusand thus represents a product-independent extension of A3F’s functional scope would be a connection according to theOpen Services for Life Cycle Collaboration (OSLC)[132]. This enables the connection to other tools that implement an OSLC interface.