Metric-centered and technology-independent architectural views for software comprehension

Overview

Even though the projects worked on different technologies, at the end, as we pointed out in Section 3.4 the architectural visualization needs are similar. Thus, we decided to study the possibility of generating metric-centered and technology-independent architectural views. We must emphasize that our aim is creating the most common views observed both in the literature and in our own experiences. Such views serve as a starting point but may require customization to meet all the particular needs. For each new technology we have to develop some assets (referred to as the Domain Engineering process) that are then reused for every application that conforms to such a technology (this is called the Application Engineering process). These terms are originally coined in (Czarnecki and Eisenecker 2000). Figure 1 (which uses a data flow notation) shows the two processes. The application engineering level is for the final users (such as architects, developers, testers, etc. who carry out software comprehension tasks) to generate metric-centered views for a particular application. The final users provides the application data to analyze and automatically, the process generates the views of the application. This process consists of 4 steps (represented as circles): i) data injection to obtain a memory representation of the input software artifacts; ii) queries on the representation of step 1 that allow us to find the architectural elements of the language/technology; iii) computation of metrics related to such elements; and iv) rendering of architectural elements and their associated metrics in an editor.

Process at application/domain engineering level

The domain engineering level is for an MDRE expert who has to provide part of an infrastructure and reuses other part. Light gray squares represent the assets that the MDRE expert has to define per each new technology or programming language of interest. White squares represent assets at the heart of our approach that can be reused regardless of the source technology or language. Dark gray squares represent the assets generated per each source application to be analyzed. The assets consist of parsers, models, metamodels and transformations. Next sections describe these assets in detail. We use the Oracle Forms project as illustrating example.

Step 1: Parsers

For step 1, depending on the technology, the MDRE expert has to produce a model that conforms to the language/technology metamodel from the source data. This task means to develop or reuse one or more parsers depending on the available input data. In our experimentation, in the case of Oracle Forms, we developed a single parser in Java that produces a model conforming to a metamodel of Oracle Forms. For Ruby code, we implemented two Xtext grammars^Footnote13 which in turn generated the parsers and the meta-models for SQL and Rails. For JEE, we used Modisco,^Footnote14 which gives as a result a model with a full abstract syntax tree of the source code. Such a model conforms to the standard metamodel so-called KDM.^Footnote15

Besides the source code, we had dynamic data, i.e., logs that saved a trace of the SQL operations executed. This was useful to complete the model with relationships between the database tables and the microservices. A specific parser was built for that task.

Step 2: architecture metamodel and technology2architecture transformation

The MDRE expert has to design an architecture metamodel and a Technol- ogy2Architecture transformation for this step. The architecture metamodel rep- resents the structural elements that final users want to have in the views. The Technology2Architecture transformation produces an architecture model from the step 1 model.

Fig. 2 shows the architecture metamodel for the Oracle Forms industry case. It provides a way to specify the main concepts needed to represent a typical clien- t/server 4GL application but tries to do so in a more platform independent repre- sentation (in the MDA sense of the word). This would enable in the future to reuse most of the metamodel in the domain engineering process of other similar languages (like Delphi or Visual Basic).

Architecture metamodel for Oracle Forms

Some of the main metamodel concepts are: i) ‘Module’ that contains ‘Form’ and ‘Table’; ii) ‘ModuleRelationship’ that represents the relations between the modules; and iii) A ‘SingleTableRelationship’ that describes a simple relation between a form and a table. It is worth highlighting that some of these concepts have a direct corre- spondence with the concepts of the technology models (i.e., Form and Table). How- ever, others are calculated from the information contained in those models by using clustering algorithms in the Technology2Architecture transformation. A clustering algorithm arranges fine-grained elements in coarse-grained elements by evaluating their attributes and relationships. Previous works in software comprehension have used clustering algorithms, see for example (Anquetil and Laval 2011; Mancoridis et al. 1999).

Clustering algorithms were needed in the three industry cases. However, their use should be assessed on a case-by-case basis because it depends on the final users’ requirements and the software structure. In the next paragraphs, we spell out the requirements and software restrictions that motivated the use of clustering in the industry cases, as well as a brief description of the algorithms.

In the Oracle Forms case, the fact of knowing the module containing the form sub- ject matter of modernization helps developers to delimit the modernization scope. However, it is not always easy to get the modules because legacy software organi- zation is often quite poor. To cope with this, we have implemented two clustering algorithms that arrange the forms, tables and relationships into modules: Menu- based clustering algorithm and Table betweenness clustering algorithm (Garcés et al. 2015). ‘Module’ is the result of these algorithms that group in a module the forms that they have in common, or that are called from a same menu of the graphic interface, or that depend on the same tables. In addition, ‘ModuleRelationship’ comes out the calls between forms that are contained in two different modules (the calls are derived from CALL/OPEN queries embedded in the PL/SQL code).

In the JEE case, developers need suggested options about how to split the legacy applications in microservices. This distribution is not trivial since stakeholders likely face legacy code with the following problems: 1) lack of design and documentation; 2) absent reasoning on the original design and architecture decisions; 3) undermin- ing of the original design decisions as many additions and alterations have been made. To deal with this, we implemented an algorithm that groups together the logic EJBs that access to the same persistence entities. In addition, we developed another algorithm that groups clusters in microservices, taking into account the per- centage of EJBs in common. These algorithms are referred to as EJB Clustering, and Microservice Clustering in previous work (Escobar et al. 2016).

In the Ruby on Rails case, developers need to have a wide vision of the application before taking (re)design decisions. This vision encompasses diagrams for the logic and persistence layers of Ruby on Rails applications. This is challenging because, in applications built on top of dynamically typed languages (like Ruby), it is not possible to have all the information of methods and attributes that will be available in execution; besides that, the types of the attributes are unknown and thus it is impossible to determine which classes have aggregation/composition relationships. To address this, we have implemented a clustering algorithm that groups Rails models in packages based on namespaces and discovered correlation between classes and database tables (García and Garcés 2017).

This helps illustrate that an intermediate representation (i.e., the architecture model) is necessary, where information is synthesized according to interest crite- ria through the clustering algorithms, and that occurs before views specification; otherwise, the implementation of the latter would be very complex.

Step 3: Metrics transformation and annotations

The MDRE expert has to carry out the following three tasks in order to guarantee the success of step 3:

1. 1)Development of a metrics transformation that queries a model conforming to the architecture metamodel and creates measures and measurements in an output model. This output model is conforming to the metrics metamodel.
2. 2)Annotation of the architecture metamodel to indicate which structural ele- ments of the language/technology will be painted, and their appearance. This task has a strong dependency with the previous one because the measures referenced in the annotations are influenced by the measures introduced by the metrics transformation. We have chosen the annotations as the expres- sion mechanism because they are metadata that do not affect the metamodel nor the related models. Our tool validates that the annotations have been correctly applied to the architecture metamodel.
3. 3)Generation of a Technology-independent Views Specification (TIVS) model which is an intermediate representation of the view specification that allows us to be independent from the concrete graphic framework on top of which the view editor is built. This model conforms to the TIVS metamodel (see Section 4.4.2) and is automatically generated from the annotated architecture metamodel by using a transformation (referred to as Annotation2TIVS in Fig. 1).

   The two first tasks are manually carried out by the expert and the latter one is automated through a transformation.

Metrics transformation

The metrics transformation is responsible for: i) creating measures in the metrics model; ii) querying the architecture model to obtain measurements for the estab- lished measures; and iii) associating architecture elements to measurements in order to have a trace indicating where do the measurements come from. The transforma- tion output is a model conforming to the metamodel shown in Fig. 3. To design this metamodel, we took inspiration from the Structured Metrics Metamodel (SMM) which is an OMG specification (OMG n.d.). The main concepts of SMM are: Measure, Mea- surement and Observation. Measure defines a type of software metric that can be applied to one or several architectural elements. Measurement contains the concrete value of a metric for a particular architectural element. Observation saves a trace of which tool is used to compute the measurements, when, and who is the responsible for the observation.

Metrics metamodel

In our Metrics metamodel, we keep the Measure and Measurement concepts and leave aside the Observation concept. The latter adds no value to our approach, instead it impacts the metrics model size and the performance of the views render.

In addition, the SMM includes a set of software measures (that extends the con- cept Measure) but makes no claims about its standardization. Thus, We decided to put aside these subclasses too and prefer to keep our Metrics metamodel as minimal as possible. In fact, it is the MDRE expert the one who adds the measures of her interest at model level.

• MetricSystem: Describes the root concept.
• Measure: Corresponds to the Measure concept from the SMM.
• Measurement: Corresponds to the Measurement concept from the SMM. It is worth noting that the measurement has a reference whose opposite is kind of Object. This allows us to reference any kind of element being present in the architecture model.

  Listing 1 shows an excerpt of the Metrics transformation developed for the Oracle Forms case. This excerpt is devoted to associate the measure ‘Total number of Tables’ to the modules. To this end, the transformation: i) creates the measure (lines 1-2); ii) obtains the collection of modules contained in the application (lines 4-6); and iii) computes the number of tables for each module and assigns this value to the measurement (lines 6-8). It is worth noting that the measurement is linked to the measure (line 9) and the architectural element (line 10) from which the value is computed.

Listing 1 Example of a Software Metrics Transformation for Oracle Forms

1. 1v a r measure = new Measure ( ) ;
2. 2measure . name = ’ Total number o f Tables ’ ; 3

4v a r mai n App l ica t ion = OracleFormsMM ! A p p l i c a t i o n . a l l I n s t a n c e s ( ) . f i r s t ( ) ; 5

1. 6f o r ( module i n mai n App l ica t ion. . modules ){
2. 7v a r measurement = new Measurement () ;
3. 8measurement. v a l u e = module. e l e m e n t s. s e l e c t ( e | eocl Is Type Of (Table ) ). . s i z e () ;
4. 9measurement. Measure = measure;
5. 10measurement. Element = module; 11}

12…

Annotations and Technology-independent Views Specification (TIVS) metamodel

The proposed annotations are aligned with the TIVS metamodel. Therefore, before explaining the annotations, we present such a metamodel. We decided to repre- sent metrics in a metamodel separated from the TIVS metamodel to individualize concerns. Figure 4 shows the TIVS concepts and a basic description follows. The application of these in the projects is introduced in the next chapter.

• System: Describes the root concept.
• Cluster: Represents a set of elements that have been grouped according to a given criteria.
• ClusteredElement: Represents the content elements inside of a cluster.
• Relationship: Describes an association between Clusters or ClusterElements.
• Element: Abstract concept from which Cluster and ClusteredElement extends. It allows that a relation can have as source/target two Clusters or one Cluster and one ClusteredElement. Additionally, it allows that a Cluster can contain others Clusters or ClusteredElements.

Technology-independent Views Specification (TIVS) metamodel

Annotations: In this section, we describe the annotations:

• @Cluster: It is used in a non-abstract metaclass that represents a Cluster.
• @ClusteredElement: It is used in a non-abstract metaclass that represents the ClusteredElement of a metaclass annotated with @Cluster. The annotation cannot be placed on superclasses but directly on the terminal class that represents the actual element to be painted.
• @ClusteredElementCollection: It is used inside a metaclass annotated with
• @Cluster; in particular, it must be placed on composition references of that metaclass whose type is that of classes previously annotated with @Clustere- dElement or @Cluster.
• @Relationship: It is defined on a metaclass that represents in itself a rela- tion between two metaclasses A and B. It is mandatory that both A and B are annotated either with Cluster or with ClusterElement. The annotation
• @Relationship is accompanied by the following two additional annotations: i) @source: It is used on a reference of the annotated metaclass with @Relation- ship that points to the source of a relationship; ii) @target: It is defined on a reference of the metaclass annotated with @Relationship and is an annotation that points to the target of a relationship. In addition, it is possible to specify the line style, where the possible values are: solid, dash, dot or dash-dot. If final user requires a different style, then MDRE expert has to define it in the views specification (in this case, Sirius).
• All annotations with the exception of @ClusteredElementCollection can in- clude three graphical properties: color, size, and label. Developers have to map these properties to measures from the metrics model. That is, the ap- pearance of the displayed architecture elements is changed as a function of the measurements computed in step 3.

  The List 2 shows fragments of the architecture metamodel for Oracle Forms using the notation editor OCLinEcore.^Footnote16 It also shows how the annotations have been applied.

  In the List 2, we have annotated the class ‘Module’ with ‘Cluster’ since it is the only desirable grouper, the classes ‘Table’ and ‘Form’ with ‘ClusteredElement’ since both are contained in the ‘Module’ to visualize, the relationship ‘elements’ between ‘Module’ and ‘Element’ with ‘ClusteredElementCollection’, which allows the access to the tables and forms. In addition, the class ‘SingleTableRelationship’ was anno- tated with ‘Relationship’ to obtain the link between forms and tables. Finally, we include two graphical properties in the ‘Cluster’ annotation and one in the ‘Rela- tionship’ annotation. The first two are size and color; these depend on the measures “Total numbers of Forms” and “Total number of Tables” respectively. The last property is label, and it is mapped to the “Lines Of Code” measure. The name of measures used in the annotations must match the measures defined in the metrics model.

Listing 2 OracleForms Architecture Metamodel Annotated

1. 1c l a s s A p p l i c a t i o n {. . .
2. 2p r o p e r t y modules: Module [∗ | 1] {c o m p o s e s}; 3}
3. 4@ Cluster (s i z e =’ Total numbers o f Forms’, c o l o r =’ Total number o f Tables’)
4. 5c l a s s Module {. . .
5. 6@ C l u s t e r e d E l e m e n t C o l l e c t i o n
6. 7p r o p e r t y e l e m e n t s: Element [∗ | 1] {c o m p o s e s};
7. 8p r o p e r t y e l e m e n t R e l a t i o n s: E l e m e n t R e l a t i o n s h i p [∗ | 1] {c o m p o s e s};

9}

1. 10@ Clustered Element ()
2. 11c l a s s Form e x t e n d s Element {. ..}
3. 12@ Clustered Element ()
4. 13c l a s s Table e x t e n d s Element {. ..}
5. 14a b s t r a c t c l a s s E l e m e n t R e l a t i o n s h i p {. . .
6. 15@ source
7. 16p r o p e r t y s o u r c e: Form [1 ] ;

17}

1. 18@R e l a t i o n s h i p (l a b e l =’ L i n e s Of Code’, s t y l e =’ S o l i d’)
2. 19c l a s s S i n g l e T a b l e R e l a t i o n s h i p e x t e n d s E l e m e n t R e l a t i o n s h i p {. . .
3. 20@ target
4. 21p r o p e r t y s i n g l e T a r g e t: Table 1;
5. 22}

Step 4: Views specification model

In this step, the MDRE expert uses the TIVS2ViewSpecification transformation, which is an asset useful regardless of the source technology. This transformation takes as input the TIVS model and produces as output a views specification model.

A views specification model is used for generating the graphic editor code that will paint the elements in the views. The specification covers three aspects: i) a graphic model that specifies the visual forms that will be used in the editor (e.g., a gray rectangle, a continuous line); ii) a model with correspondences between the visual forms and the metamodel elements (e.g., instances of the class X are represented by the gray rectangle specified in the graphic model); iii) actions that allow the user to interact with the views (e.g., click on a menu to move from one view to another); and iv) conditional style for graphical model that modifies some characteristics such as colors, sizes or labels, according to a specific data (e.g., the color of a rectangle).

In our approach, the views specification model conforms to the Sirius meta- model and is automatically generated from the TIVS model by using the TIVS2ViewSpecification transformation (see Fig. 1). Some of the correspon- dences between these two last models are: an annotated class with @Cluster is mapped to instances of the classes Viewpoint, DiagramDescription, NodeDescrip- tion and ContainerDescription. An annotated class with @Relationship is mapped to EdgeDescription. Please refer to Sirius documentation for more details about the underlying metamodel.

In the application domain phase, the architecture model and the metrics model are taken as input by the view specification model to display, in the graphical editor, the views for the source application. The resulting views depend on the annotated architecture metamodel and can be categorized as follows:

• Clusters views: shows a set of clusters and the relationships between them. Examples of these kinds of relationships are: functional models (Oracle Forms), EJBs clusters and microservices (JEE).
• ClusteredElements for Cluster View: shows in detail the content elements in a selected Cluster. As an example, there exists the Forms and tables view (Oracle Forms).
• ClusteredElements Global View: shows all ClusteredElements of the system, of a same kind, without differentiating to what Cluster they belong. An illus- tration of this is the Forms view (Oracle Forms).
• Cluster and ClusteredElements (or combined) view: shows Cluster and Clus- teredElements together to discriminate what elements belong to what cluster, and determine the relationships among these elements. An example of this view is the (Ruby on Rails) model view.

  As previously mentioned the TIVS model is an intermediate asset that allows us to separate our solution from the graphic framework, e.g., Sirius. Our tool takes this model as input and generates as output the Sirius specification model. Figure. 5 gives a flavor of how the Sirius specification looks like. This excerpt of the specification was generated from the class ‘Module’ that was annotated with ’@Cluster’. A description of the elements follows:

• A Viewpoint element (called ‘Viewpoints for Cluster Module’) that contains a ‘DiagramDescription’ for each kind of view of our approach. ‘Clusters for Module’ is one of them.
• ‘Clusters for Module’ contains a ‘NodeDescription’ (i.e., ‘Cluster-Module’) that defines a representation for the model instances conforming to ‘Module’. In the case of ‘Total number of Tables’, the color of the ‘NodeDescription’ has to change based on the number of tables contained in the ‘Module’. Sirius allows this via a ‘ConditionalStyle’ that consists of a set of ‘PredicateEx- pressions’. In our case, each ‘PredicateExpression’ is a query that obtains a measurement value from the metrics model and assigns a corresponding color. A query example is shown in Listing 3. This query seeks a measurement that meets two conditions: i) refer to the measure ‘Total numbers of Tables’; and ii) point to the current module. If the measurement value is less than or equal to threshold, then a particular color is assigned.

Excerpt of the view specification model generated for the Oracle Forms case

Listing 3 ‘PredicateExpression’ for Oracle Forms case.

1(Metric System. a l l I n s t a n c e s ()− > c o l l e c t (measurements)− > s e l e c t (m|m. measure. name =’ Total numbers o f Tables’ and m. element = s e l f)− > a s Ordered Set ()

− > f i r s t (). v a l u e). f l o o r () < = 1 5;

Scope

In this section, we present an evaluation that focuses on showing the flexibility of our solution. By ‘flexibility’ we mean the ease with which our approach can be modified for use in various source technologies. We chose the technologies of the industrial cases (see Section 3) which are quite different from one another: Oracle Forms is a four-generation programming language, Java and Ruby are Object Oriented Programming languages that range from statically to dynamically typed. We present the results obtained in the three aforementioned industrial cases and finally a discussion is presented.

The size of the generated views specifications ranges from 44 (for Forms) to 134 elements (for JEE ). This difference is due to the fact that for each class annotated with @Cluster, the tool creates by default the four types of view and a series of scaffolding elements required by the technology of graphic editors, i.e., Sirius. The Figure 6a shows the forms and tables views of Oracle Forms when the generated specification is used. In these one, the gray rectangles represent the forms and tables, and the gray lines the relations between them. We included this figure to illustrate the default appearance of the views when the MDRE expert does not use the annotation elements related to size and color.

Views obtained for applications developed under three different technologies: a and b Oracle Forms; c Ruby on Rails; and d JEE

In the case of Oracle Forms, 3 out of 3 expected views were generated. For the Forms and Tables view of Oracle forms, an additional EgdeDescription for ‘Mas- terDetailRelationship’ was included because this one, as opposed to the other ones, has a source and two targets; this is, a form and the master and detail tables. Our approximation is limited to relations with a unique source and target. A workaround would be to annotate a same class from the metamodel with @Relationship several times, indicating for each annotation a different pair source-target.

In the JEE case, 2 of the 4 expected views were produced. The view about depen- dencies among EJBs had to be done by hand, because in the architecture metamodel there is not a class that represents in a synthetic way the relationships between the EJBs; what is described is that the dependency relationships have an invoking method and one invoked. As a consequence, we had to write a query that navigates dependencies between methods to, from there, derive the calls between EJBs. Simi- larly, the specification for the Microservices and Tables view was made by hand since the instances of ‘Table’ are contained within ‘Architecture’ instead of being inside ‘Microservice’. The proposed decomposition views assume that in the architecture model the container and content elements share a direct composition reference.

In the case of Ruby on Rails, the expected view that combines Rails models with their attributes, methods and relations was generated. In this case, there was no need for the annotation elements related to graphical properties. The reason was the simplicity of the view; Sirius’ default configuration was sufficient enough to adjust the size of Rails models to the number of displayed attributes and methods.

Given the generated specifications, we have obtained the views (see Fig. 6) for applications written in the different technologies. In OracleForms, the specification was tested in 4 applications of the insurance and banking sector with sizes between 100 to 200 tables, and 83 to 178 forms. In JEE, in 3 applications of the academic, commerce and government domains, with sizes of up to 624 classes. In Ruby on Rails, in 3 applications designed for professional and educational services with a size of between 45 and 153 Rails models. Fig. 6d demonstrates that the size and color of EJBs clusters (represented as ellipsis) are different among them. In the architecture metamodel for this case, the MDRE expert defined that the size and color of the EJBs clusters depend on the number of EJBs and LOC contained respectively.

Cost of developing a solution

The cost of a solution for a particular technology/language depends on the effort of developing the assets (represented as light gray squares in Fig. 1) required in each step of the views generation process. The assets of steps 1-2 are mandatory regardless of whether our approach is being used or not (Tilley 2009). Instead, the adoption of our approach results in savings in steps 3-4 because the MDRE expert designs the views by annotating the architecture metamodel without caring about the scaf- folding needed in the particular views specification framework (e.g., Sirius). Let us explain the scaffolding needed in a Sirius specification (i.e., .odesign file).

The MDRE expert has to establish correspondences between the architecture metamodel and Sirius concepts: i) The ‘Module’ class contains the forms and tables that one wants to see and therefore the module should be mapped to ContainerDe- scription ii) The ‘Table’ and ‘Form’ classes are fine-grained elements so that they correspond to NodeDescription, and iii) The ‘SingleTableRelationship’ class has to be visualized as a link whose source points to a form and target points to a table; therefore, it corresponds to EdgeDescription.

In addition to establishing the correspondences, it is necessary to delimit the elements that are going to be shown through OCL queries as the ones in the List 4. From lines 1 to 4 there are queries that return a collection of forms and tables, where self represents a previous selected module. In addition, on line 5 there is a query that returns all the ‘SingleTableRelationships’ of the given application and then the technology of the graphic editor (i.e., Sirius) leaves the ones that have as source/target the forms and tables resulting from lines 1-4. Finally, in lines 5 to 11 there is a query that defines the color of a module based on the number of contained tables. For example, if the number of tables is less than or equal to a threshold, then the selected color is blue.

Listing 4 Example of OCL Queries needed in Sirius

1. 1c o n t e x t Module:: t a b l e s: C o l l e c t i o n
2. 2s e l f. e l e m e n t s. s e l e c t (c | c. o c l I s T y p e O f (Table));
3. 3c o n t e x t Module:: forms: C o l l e c t i o n
4. 4s e l f. e l e m e n t s. s e l e c t (c | c. o c l I s T y p e O f (Forms));
5. 5c o n t e x t Module:: module Color: Color
6. 6i f s e l f. elements − > s e l e c t (o c l I s T y p e O f (Table)). s i z e () < = t h r e s h o l d then
7. 7Color#Blue
8. 8e l s e
9. 9. . .
10. 1010 e n d i f.
11. 11;

Instead of developing this scaffolding, the MDRE expert has to establish the cor- respondences between architectural concepts and views specification by annotating the architecture metamodel. The queries from lines 1-4 are automatically generated from the annotations. The query from lines 5-11 is replaced by a snippet in the Metrics transformation (see Listing 1) and a query in the odesign file (Listing 3). Note that the query references to the measure ‘Total number of Tables’ previously calculated by the transformation. The snippet is manually developed by the expert and the query is automatically generated.

Limitations

The main benefit of our approach is the Independence of the technology that allows us to be flexible in terms of the language we can process and the views we can obtain. However, this benefit is, at the same time, a limitation because there is a need for an MDRE expert to build the assets which are non-trivial. However, that task has to be done only once per technology and can be reused as many applications as desired. The cost of the solution is cost-effective if final users are going to reuse the assets many times, either because it is applied in many different applications or in the same application that evolves constantly.

Related work

Our approach was designed based on two main requirements: i) software visualiza- tion; and ii) modeling of software metrics that impact the views. In this section we classify related work whose requirements are similar to ours.

Software visualization

There are several academic approaches on architectural views oriented to soft- ware comprehension tasks, for example: CodeCity (Wettel et al. 2011), eCity+ (Khan et al. 2014), AIVA (Snajberk et al. 2012; najberk et al. 2013), SAABs (Osman et al. 2014), Softwarenaut (Lungu et al. 2014), VizDSL (Morgan et al. 2018), Modigen (Gerhart and Boger 2016), EuGENia,^Footnote17 Moose,^Footnote18 and GRAPH (Bergel et al. 2014).

Several of these approaches (except by VizDSL, Modigen, EuGENia, Moose, and GRAPH) create views for a restricted number of technologies and languages; e.g., Smalltalk, Java, C++ and ADA. In the same way, the views are predefined and it is not possible to easily define new ones. CodeCity and eCity+ generate views whose notation is based on the city metaphor: the neighborhoods represent packages and the buildings represent classes. In the case of SAABs, UML classes diagrams are obtained. In Softwarenaut, module views and their dependencies are obtained. Fi- nally, AIVA produces components and classes views. In contrast, our approximation is open from the technology point of view for several reasons. Firstly, according to the working technology, it allows new parsers to be plugged to the rest of infrastruc- ture. Secondly, it allows the definition of new views with the relevant architectural elements for the developer. Thirdly, it gives freedom to define the used notation instead of using something fixed such as UML (Snajberk et al. 2012) because not all the technologies obey the object oriented programming paradigm.

VizDSL is a visual DSL based on the Interaction Flow Modeling Language (IFML) to design and create interactive visualizations. Modigen is a textual DSL to spec- ify graphical editors DSLs based on node and edge diagrams. These are, together with an EMF metamodel, the input for a generator that produces an Eclipse-based graphical Editor. VizDSL and Modigen are generic workbenches not specially tar- geting metric-centered architectural views for software.

Like EuGENia, our tool generates an editor specification from an annotated meta- model. When using EuGENia developers define the view look-and-feel in a static manner. In contrast, when rendering our views their look-and-feel can dynamically change since Sirius takes as values of graphical properties (i.e., color, size, and labels) the measurements computed prior to visualization.

We found that our approximation resembles Moose in many aspects: it is possible to connect parsers for new technologies, there is an intermediate (meta)model on top of which queries can be made and new views can be specified. Following Moose, the same research group proposes GRAPH: A DSL to specify views that represent software dependencies. Software structural elements and their relationships are re- ferred to as nodes and edges of a graph. The views style (i.e., color, size) is defined in terms of metrics; for example, the number of methods in a class determines the size of nodes. The comparison of our work with Moose and GRAPH is explained in Section 2.

Modeling of software metrics

In (Bagnato et al. 2017), a profile of the Structure Metrics Metamodel (SMM) is contributed. The authors take advantage of Modelio tool^Footnote19 to annotate diagrams with concepts coming from the profile. Diagrams are made from scratch by final users. In contrast, our approach generates diagrams from source applications.

In (Stevanetic et al. 2014), authors define a DSL that serves to express architectural abstractions of software applications. The specification is used to track architectural changes in a given application and check compliance with a reference architecture. Authors present the language constructs to specify understandability metrics so that users can check if the current version of an application is between predefined ranges. Software visualization is out of the scope.

Our approach based on annotations generates specifications of graphic editors that have architectural views that show a decomposed application from a high level to a low level, according to the comprehension necessities based in software metrics. This allows developers to obtain graphic editors in less time, regardless of technology.

Since our experiments have shown that the editor’s performance can decrease with large architecture models, a future direction is to study mechanisms that increase the performance of the queries included in the view specification model (i.e. mainly the queries that navigate the metrics model).

A DSL is a language tailored to a specific application domain. It consists of an abstract syntax, a concrete syntax, and semantics. We have targeted a more DSL- oriented approach for specifying software views. We are reaching the goal incremen- tally. We have moved a step forward by defining the abstract syntax (our TIVS and Metrics metamodels) and semantics (encapsulated in the transformations). For the time being, we are lacking a dedicated concrete syntax and the workaround is the use of annotations. The latter is because we are collecting lessons and experiences from the use of our approach with students and practitioners in order to provide a language expressive enough. However, this shortfall does not prevent the use of the approach since developers are used to employing annotations. We consider that a textual syntax would be a “nice to have” feature and, therefore, the definition of a textual concrete syntax is part of our research agenda.

[“source=jserd.springeropen”]