XIS-Reverse: A Model-Driven Reverse Engineering Approach forLegacy Information Systems

André Reis and Alberto Rodrigues da SilvaINESC-ID, Instituto Superior Técnico, Universidade de Lisboa, Lisbon, Portugal

{andre.filipe.reis, alberto.silva}@tecnico.ulisboa.pt

Keywords: Model-Driven Engineering, Model-Driven Reverse Engineering, Model-Driven Reengineering, Database,Legacy System

Abstract: Due to the development of new technologies companies face high costs managing and maintaining their legacyapplications, thus upgrading those systems became a complex challenge. This paper describes a model-drivenreverse engineering approach that aims to support the mentioned challenge. This approach takes as input thelegacy relational database schema, but also user preferences to better guide the reverse engineering process.From these artefacts it is possible to extract models of the legacy application through model-to-model transfor-mations based on a set of well defined rules and heuristics. The main contributions of this proposal (comparedwith the state of the art) are the semi-automatic identification of generalizations and aggregations and thepossibility to automatically extract default values to enrich the produced models. The paper also includes anevaluation and a discussion of the proposal based on a simple case study and a real-world application.

1 INTRODUCTION

Enterprises have to manage legacy software applica-tions which were built in the past and are still beingused since then. In the long term the maintenance ofsuch applications become rather complex, mainly dueto outdated or poor documentation and reduced flexi-bility of the original software technologies (De Luciaet al., 2008). To overcome these problems softwarereengineering approaches can be used (Arnold, 1993).Reengineering supports evolutionary maintenance oflegacy applications by analysing and modifying suchapplications rebuilding them in a new form (Chikof-sky and Cross, 1990).

A model-driven engineering (MDE) approach canbe seen as a chain of model transformations that pro-duces the target software artefacts from more abstractmodels (Ruiz et al., 2016). Using this kind of ap-proach, the most common model transformations are:Model-to-Model (M2M) and Model-to-Text (M2T)(da Silva, 2015). M2M transformations generate a tar-get model from a source model. M2T transformationsproduce a textual representation from a source model.

Model-driven reengineering is the application ofMDE principles and techniques to reengineer an ap-plication. As illustrated in Figure 1, a completemodel-driven reengineering process is composed ofthree main stages (Chikofsky and Cross, 1990): (i) re-

verse engineering, (ii) restructuring and (iii) forwardengineering. First, the reverse engineering stage aimsto extract knowledge defined in low abstraction rep-resentations through introspection and analysis of theinitial source artefacts (initial models); this processcollects valuable information that makes it easier todefine current legacy application requirements. Sec-ond, the system restructuring stage involves establish-ing a mapping between the source and the target sys-tems. Third, the forward engineering stage producesthe artefacts to the new target system. Each of thesestages is a transformational process that can be im-plemented by means of a model transformation chainwhose initial set of models is injected. This modelinjection is performed with a T2M transformation ap-plied to textual software artefacts, such as SQL datadefinition language (DDL) scripts (Ruiz et al., 2016).

Model-Driven Reverse Engineering (MDRE) usesMDE principles and techniques to reverse engineer-ing, producing relevant (model-based) views fromlegacy systems, thus facilitating their understand-ing and subsequent manipulation (Bruneliere et al.,2014). A MDRE process is a part of the model-drivenreengineering process merely focused in the reverseengineering stage.

This paper proposes a MDRE approach to producehigh-level specifications of legacy information sys-tems in a human-controlled way. These specifications

Figure 1: Model-driven reengineering process.

are defined according to domain specific languages,and produced from the injection and the reverse engi-neering stages.

The remainder of the paper is organized as fol-lows. Section 2 gives a brief introduction of the con-text of this research. Section 3 describes the proposedMDRE approach and associated tool. Section 4 dis-cuss the main results using a simple case study andalso a real-world application. Section 5 analyses andcompares this proposal with the related work. Finallysection 6 presents the conclusion and future work.

2 BACKGROUND

This research has been developed at the Instituto Su-perior Técnico, Universidade de Lisboa, in the area ofMDE, namely within the MDDLingo 1 initiative.

MDDLingo is an umbrella researching initiativethat aggregates several projects around MDE topics,namely involving the definition of a family of lan-guages, also known as XIS*. This set of modellinglanguages derives from XIS-UML profile (da Silva,2003), involving namely XIS-Mobile (Ribeiro andda Silva, 2014b; Ribeiro and da Silva, 2014a), XIS-CMS (Filipe et al., 2016) or XIS-Web (Seixas, 2016).XIS-UML is a set of coherent constructs defined asa UML profile that allows a high-level and visualmodeling way to design business information sys-tems. In general these languages include the fol-lowing views: Entities (which includes Domain andBusiness Entities views), UseCases (containing Ac-tors and Use Cases views), Architectural and User-Interfaces (composed by Interaction Space and Nav-igation Space views). Figure 2 illustrates the afore-mentioned set of views

1https://github.com/MDDLingo

Figure 2: The multi-view organization of XIS*.

Figure 3 illustrates a very simple XIS* Domainview which aggregates domain classes (XisEntity),their attributes (XisEntityAttribute) and relationships(XisEntityAssociation/XisEntityInheritance).

Figure 3: XIS* Domain view.

In addition, Figure 4 shows the BusinessEntitiesview which allows to define higher-level entities (Xis-BusinessEntity), that aggregate XisEntities and that inthe context of a given use case are easily manipulated.

Figure 4: XIS* BusinessEntities view.

Finally, Figure 5 shows the UseCases View. Thisdetails the operations an actor can perform when in-teracting with the application in the context of a busi-ness entity (Ribeiro and da Silva, 2014b).

Figure 5: XIS* UseCases view.

XIS* languages are very alike in terms of theEntities view, however there are some discrepancieson their Use Cases, Architectural and User-Interfacesviews due to each platform target application. Forexample, XIS-CMS does not have an Architecturalview.

It is to point out that all of them are able to gen-erate their User-Interfaces, using a smart approachbased on M2M transformations given the set of Do-main, Business Entities, (Architectural,) Actors andUse Cases views.

3 XIS-REVERSE APPROACH

The MDRE approach proposed in this paper is named“XIS-Reverse”. This approach focus only in the

first two stages of the reengineering process (Fig-ure 1), namely Injection and Reverse Engineeringstages. XIS-Reverse is generically represented in Fig-ure 6. It starts by extracting the application databaseschema from an existent data source (through injec-tion). Thereafter the Application data model is gener-ated. Secondly, the user is able to define his own pref-erences by tweaking some heuristic’s parameters, pro-ducing the XIS-Reverse configuration. The reverseengineering stage takes as input these two artefacts,and generates XIS* models. Then, the designer cananalyse the produced artefacts and introduce some re-finements, such as changing automatically identifiedrelationships into different ones in the Entities view,enhancing the Use-Cases views, etc.

3.1 Tools Support

Since Sparx Systems Enterprise Architect (EA)2 isthe tool used to design business information systemsin the other XIS* projects, in order to reduce depen-dencies for future work and learning curve for theuser, we decided to also implement XIS-Reverse ontop of this tool. Moreover, from this tool we used aset of provided technologies, namely the AutomationInterface and the Model Driven Generation3.

Both reverse engineering configuration and exe-cution steps (Figure 6) are supported by the XIS-Reverse tool. Moreover, in terms of the applica-tion database access and the profiler log file injec-tion, for now this tool only supports SQL Serverconnections and profiler log files generated fromthe Microsoft SQL Server Management Studio Pro-filer Tool. Regarding the produced specifications,this tool is able to produce XIS* models but alsoRSLingo’s RSL4 (de Almeida Ferreira and da Silva,2012; de Almeida Ferreira and da Silva, 2013) spec-ifications. However, due to space constraints, onlyXIS*/XIS-Web models are considered. Furthermore,this tool can be extended to support different repre-sentations.

3.2 Running Example

For better understanding and simplicity of the expla-nation, we introduce a simple but practical example:the Social Security legacy application (SS-App).

The SS-App consists in an application that man-ages beneficiaries, their dependents (and tutors), as-sociated documents and user accounts.

2http://www.sparxsystems.com/products/ea3http://www.sparxsystems.com/resources/mdg_

tech4https://github.com/RSLingo/RSL

Figure 6: Overview of the XIS-Reverse approach.

This domain is modelled as 8 tables: Beneficiaryand Dependent which primary keys are foreign keysto a Person table. Dependents table represents therelationship between a Beneficiary and a Dependent(through its foreign keys linked to each of those ta-bles). A Dependent may have a Tutor, which arelinked by a foreign key. Each Beneficiary has a setof documents (since a Document has a foreign key toa Beneficiary table) and a unique UserAccount (dueto the unique constraint that the UserAccount tablehas over its BenIdNumber foreign key). Furthermore,several documents not linked to any Beneficiary mayexist as an UnknownDocument.

Each of those tables, columns, constraints andnumber of rows in the database are represented in Fig-ure 7.

3.3 Data Schema Extraction

Following the aforementioned process of Figure 6,during the Data Schema Extraction step, in order toextract the application data model our approach de-pends on the EA native capability 5 to reverse engi-neer a database model through an ODBC connection.Moreover, EA supports several ODBC data sources6.

5http://www.sparxsystems.com/enterprise_architect_user_guide/13.0/model_domains/importdatabaseschemafromod.html

6http://www.sparxsystems.com/enterprise_architect_user_guide/13.0/model_domains/supported_databases.html

Figure 7: Case Study SS-App data model.

3.4 Reverse Engineering Configuration

A snapshot of the tool is illustrated in Figure 8, whichis used to explain the main configuration features.The configuration panel of the tool has four main ar-eas: input, output, transformation rules guidance andappearance.

Figure 8: Configuration panel of the tool.

The Input area allows to specify the root node towhere the application data model was extracted, to in-troduce the database name and to choose how to en-hance the output specifications.

In the Output area the user can select addi-tional output representations, namely XIS-Web orRSLingo’s RSL representations.

The Transformation Rules Guidance area allowsthe user to contribute with his knowledge to enhancethe Reverse Engineering process. This configurationcan be split into three areas: (i) Simple Principal Ta-bles (ii) Default Values Extraction and (iii) General-ization discovery. The user can select which tablesare Simple Principal Tables (which we consider as ta-bles without many relationships, such as configura-tion tables or “kind of” tables). Moreover, the usercan enhance the produced specifications by extractingdefaults values from a selected column of a certain ta-ble. Furthermore, in both cases the user can also filterthe list of tables by specifying the maximum numberof rows per table, which allows the user to find moreeasily “kind of” tables, since usually they have fewnumber of instances (rows). Finally, the user can acti-vate generalization discovery and add some knowl-edge, such as a list of XisEntityAttribute names toignore, the minimum number of shared XisEntityAt-

tributes (e.g. 5 or 10), and to choose how to aggregatethose entities (e.g. by the higher number of sharedattributes or by the higher number of aggregated enti-ties).

The Appearance configuration area allows to im-prove readability of the produced specifications, byarranging models into smaller views and changing thename of the tables to a clearer one.

3.5 Reverse Engineering Execution

Taking as input (i) the application data model, (ii) theXIS-Reverse configuration and (iii) the profiler logfile or the database connection, the reverse engineer-ing process is composed by a set of transformationtasks, that will be applied. Those include a chain ofM2M transformations which are used to specify theapplication as a set of XIS* views.

3.5.1 Initialization

Before M2M transformations take place, the profilerlog file or the database connection, if provided, areused to extract more detailed information about thelegacy application, that may enhance the producedspecifications.

From the profiler log file it is possible to extractSQL statements (INSERT, SELECT, UPDATE andDELETE), and from those statements the set of usedtables. Moreover, from that we generate 4 differentlists, one for each type of statement, where each oneof them holds for each table the number of occur-rences for the corresponding kind of statement.

A database connection can be used to collect foreach table in the initial application model, the currentnumber of rows in the actual application database.

3.5.2 XIS Model-to-Model transformations

The following transformations are broken down intothe different set of produced elements.

XisEntities transformation rulesFor each table of the source data model, the followingXisEntities (E i) rules are applied:

(E 1) If a table has only 2 foreign keys, each oneto a distinct table, and does not contain more at-tributes (excluding its primary keys), this tablewill be translated into a XisEntityAssociation be-tween the two referenced tables, using a many-to-many cardinality, ie. *:* cardinality (e.g. Depen-dents in the running example).

(E 2) Otherwise the table will map a XisEntity (e.g.Beneficiary in the running example).

XisEntityAttribues transformation rulesRegarding table columns, the following XisEntityAt-tribues (EA j ) rules are applied:

Let A, B be two tables related by a foreign keyconstraint from B (referencing table) to A (referencedtable):

(EA 1) For the complete Primary Key:

a) If all the foreign key columns in B are also itscomplete primary key, in other words B andA have a 1:1 relationship since B primary keyreferences A primary key. Then B foreignkeys will be translated into a XisEntityInheri-tance relationship, where the class equivalentto A will be the superclass and the equivalentclass to B will be the subclass (e.g. Person(A) and Beneficiary (B) in the running exam-ple).

b) Otherwise, the complete Primary Key willnot be represented (e.g. UnknownDocumentin the running example). Due to XIS* Do-main View similarity to a Class Diagram,each XisEntity can be seen as a Class, whichcan have objects, and each object is different

by definition, so there is no need for a uniqueidentifier for each XisEntity.

(EA 2) For the remaining columns with Foreign Keyconstraints:

a) If the foreign key in B constitute a unique in-dex the XisEntityAssociation will have a 1:1cardinality, preserving the relationship direc-tion (e.g. BenIdNumber of UserAccount inthe running example).

b) If A was not selected as Simple Principal Ta-ble by the user (configuration stage), and oneof the following options is also true: 1) theprofiler log file was provided, both A andB tables were referenced in that file, and ta-ble B had the same or higher amount of IN-SERT operations as A did, or 2) the databaseconnection was provided and table B had thesame or higher amount of rows as A did (ifB foreign key column allows NULL values,only rows with NOT NULL values on thatcolumn will be taken into account). Then weassume that there is an aggregation relation-ship between entity A and B (A aggregatesB), that is translated into a XisEntityAsso-ciation, preserving the foreign key cardinal-ity and represented with a bidirectional arrow(e.g. Beneficiary with 500 rows (A) and Doc-ument with 1000 rows (B) in the running ex-ample).This reasoning made sense for us since that,assuming that A and B are respectively strongand weak entities, A is the one which aggre-gates B, it is fair to assume that if that foreignkey was made for that purpose, then theremust be at least the same amount of B in-stances created compared with A.

c) Otherwise, the XisEntityAssociation willhave a 1:* cardinality between table B andA, preserving the relationship direction (e.g.Dependent (A) and Tutor (B) in the runningexample).

(EA 3) Otherwise the column will be translated into aXisEntityAttribute with a corresponding XIS* at-tribute type following a predefined mapping (e.g.Name from table Person in the running exam-ple). Moreover, if previously configured, the usercan explicitly select if default values from a cer-tain XisEntityAttribute from a particular XisEn-tity should be extracted and written as an annota-tion, which will be linked to the XisEntity. Thisfeature is a significant contribution since the pro-duced specifications are enhanced with those val-

ues, allowing a better understanding of the XisEn-tities captured from the legacy domain.

Note: in both b) and c) cases, from (EA 2), whenthe Not Null option is not set for that column (in otherwords, that column can be NULL), the XisEntityAs-sociation target’s cardinality is the concatenation of0.. with the original target cardinality. (e.g. 1 wasthe original target cardinality and the column allowedNULL values, then it becomes 0..1)

Further XisEntityInheritance transformation ruleFor each XisEntity, after the previously mentionedXisEntities and XisEntityAttributes rules are applied:

This XisEntityInheritance identification is per-formed comparing every XisEntity and their XisEn-tityAttributes with each other. We assume that twoXisEntityAttributes are the same if they share thesame name and type. During this comparison, ifpreviously defined, some XisEntityAttributes can beexcluded by their name. Moreover, we cluster 2or more XisEntities if they share at least the sameor more predefined number of shared XisEntityAt-tributes. Furthermore during this comparison onlyXisEntities without inheritance relationship will betaken into account.

After this clustering procedure, there are two waysof finding inheritance, depending on the configura-tion, the list can be ordered by the descending num-ber of entities or ordered by the descending numberof shared XisEntityAttributes in each cluster. Whilethis list has clusters of XisEntities a Superclass is cre-ated for each cluster. This Superclass will have theidentified XisEntityAttributes, each of the XisEntitiesin that cluster will be linked to the superclass using aXisEntityInheritance and will not own the XisEntity-Attributes that their Superclass has (e.g. Unknown-Document and Document share 3 identical columns(Path, Description and Notes) in the running exam-ple).

In order to implement the first phase of thisalgorithm, given the complexity that is comparingevery XisEntity with each other taking into accountall their XisEntityAttributes, in domains that caneasily be compound by hundreds or thousands ofelements, we based our approach in the MapReduce(Dean and Ghemawat, 2008) programming modelwhich allows to handle large data sets.

XisBusinessEntities transformation rulesFor each XisEntity, the following XisBusinessEntity(BE k ) rules are applied:

(BE 1) If the current XisEntity aggregates otherXisEntities or is not aggregated by another XisEn-tity (i.e. we do not consider weak entities as

Business Entities), then a corresponding XisBusi-nessEntity will be created, followed by the cre-ation of a XisBE-EntityMasterAssociation thatwill link that XisBusinessEntity with its XisEntityfrom the Domain view, and for each XisEntityAs-sociation:

a) If the XisEntityAssociation is an aggre-gation then it will be translated into aXisBE-EntityDetailAssociation between thatXisBusinessEntity and the target XisEn-tity of the XisEntityAssociation. More-over, if the corresponding target XisBusi-nessEntity exists, there will be a XisBE-EntityReferenceAssociation between the tar-get XisBusinessEntity and the source XisEn-tity.

b) Otherwise it will be translated into aXisBE-EntityReferenceAssociation betweenthat XisBusinessEntity and the target XisEn-tity of the XisEntityAssociation.

(BE 2) Otherwise there is no mapping.

XisEntityUseCases transformation rulesFor each XisBusinessEntity there will be a corre-sponding elementary XisEntityUseCase that is named"Manage" followed by the XisBusinessEntity masterXisEntity name, associated to the XisBusinessEntityby a XisModule-BEManageAssociation. And a de-fault XisActor will be linked to the XisEntityUseCaseusing a XisRole-ModuleAssociation.

4 EVALUATION

In this section a real-world Social Security legacy ap-plication (SS-App) will be used as the case study.Firstly, due to the extension of this paper a simplifiedversion of the SS-App (described in the Subsection3.2) will be used to show the produced specificationswith our tool. Secondly, the results of using our toolwith the whole version of this application will be fur-ther shown and analysed.

4.1 A Simple Example

Taking as input the specified running example SS-App data model, selecting database access to en-hance the output specifications, selecting Status col-umn from UnknownDocument to extract its defaultvalues and activating generalization discovery by thehigher number of shared attributes with the minimumof 3 attributes, Figure 9 shows the produced XIS* Do-main view. For this image only the main contributionsof this paper were taken into account.

From the aforementioned configurations it waspossible to detect an aggregation between Beneficiaryand Document through (EA 2) b). Moreover, a super-class with the shared attributes was created for Doc-ument and UnknownDocument entities, through thefurther XisEntityInheritance transformation rule. Andfinally, a note was created and linked to the Unknown-Document entity displaying the default values that theStatus column had in the database, through (EA 3).

Figure 9: Case Study SS-App XIS* Domain view.

4.2 A Real-World Example

During our research we had the chance to apply thisapproach to a real-world legacy application, in orderto evaluate how much knowledge we could extractfrom it.

This legacy database was from a Social Securityapplication and had 187 tables.

To reverse engineer this database we tried differ-ent configurations, from which we are going to stresstwo. Both used database access to enhance outputspecifications and generalization discovery activatedby the higher number of shared attributes, with a mini-mum of 5 shared attributes. Moreover, after analysingthe database we identified 5 often used attributes, eachone of them with same name and type in almost every

table. Thus, those 5 attributes were included in thelist of attribute names to ignore, in order to decreasethe generalization discovery time and try to producemore interesting results, instead of a superclass thatwould generalize almost every entity. The differ-ence between the two configurations were in terms ofSimple Principal Tables selection. Although, in theExperiment-A we did not select Simple Principal Ta-bles, in Experiment-B we did.

Table 1, shows the main results of those two con-figurations (Experiment-A and Experiment-B) withthe following metrics: number of XisEntities (in-cluding explicit and implicit superclasses); numberof XisAssociations (also including Aggregations andMany-to-many associations); the number of Aggre-gations; number of Many-to-many associations; num-ber of explicit superclasses; number of implicit super-classes (through Generalization discovery) and num-ber of XisBusinessEntities.

Table 1: Main results from reverse engineering process witha real-world Social Security application.

Experiment-A Experiment-BEntities 174 174

Associations 205 205Aggregations 126 43

Many-to-many 19 19Exp superclasses 0 0Imp superclasses 4 4BusinessEntities 140 156

After the Experiment-A reverse engineering, wewere mainly surprised with the amount of Aggrega-tions detected (more than 60% of all Associations).Then we explored more the database and concludedthat almost every foreign key from a main entity (e.g.Beneficiary) to a configuration entity, was mistakenlytransformed into an aggregation from the configura-tion entity to the main entity.

Thus, in order to discard such aggregations, inthe Experiment-B configuration we selected every en-tity with at most 20 rows per table in the databaseas a Simple Principal Table. Then the number ofaggregations reduced to around 20% of all Associa-tions, and after analysing such aggregations againstthe database, most of them made sense to be classifiedas aggregations (e.g. Beneficiary aggregates ActivityLogs).

We did not further explored different general-ization discovery configurations, since the minimumnumber of shared attributes was already too low. Thuswe assumed that 4 implicit superclasses was alreadya good result.

5 RELATED WORK

Reverse engineering of software applications havebeen extensively studied in the last decades, and theirmain contributions have been crucial to produce bet-ter results in this complex activity, and furthermoreto stimulate the development of reverse engineeringtools. More recently, MDE started to be applied toreverse engineering (MDRE), promoting a more sys-tematic and flexible process. Moreover, MDRE ap-proaches have been extended in order to completelyreengineer a source application into a new target ap-plication through model-driven reengineering tech-niques.

This section overviews the most relevant researchstudies, covering data schema extraction and reverseengineering of databases. Moreover, those contribu-tions are also compared with our approach.

5.1 Data Schema Extraction

The main properties of the research works analysedin this subsection are shown in Table 2. This tablespecifies for each approach, its input, the existence ofdata schema extractors, if it extracts all table proper-ties and its output. The last row categorises our ap-proach.

Gra2MoL (Izquierdo et al., 2008) Text-to-Model(T2M) language and MoDisco (Bruneliere et al.,2014) framework have been specially tailored for dataschema extraction (model injection). Gra2MoL is aDomain Specific Language (DSL) to write transfor-mations between any textual artefact which conformsto a grammar (e.g. source code) and a model whichconforms to a target metamodel. On the other hand,MoDisco is a Java framework intended to facilitatethe implementation of MDRE approaches. Regard-ing to data schema extraction, MoDisco facilitates theimplementation of discoverers (model injectors), andit currently provides discoverers for Java, JSP andXML. A drawback for both approaches is that theywould require the definition of such transformationsand discoverers, respectively, to extract the databaseschema.

Schemol (Díaz et al., 2013) is another tool forinjecting models. However, this tool allows inject-ing data stored into database by specifying transfor-mations that express the correspondence between thesource database schema and the target metamodel.

Furthermore, in terms of database model injec-tion (to ease this T2M transformation) it is possi-ble to transform a database schema into a graphi-cal representation using a variety of commercial andacademic tools. DB-MAIN (Hainaut et al., 1994)

and SQL2XMI (Alalfi et al., 2008) are two exam-ples of such academic tools. Firstly, DB-MAIN isa toolbox that supports database reverse engineer-ing, and includes legacy database schemas extractors,through several sources such as ODBC drivers or SQLfiles. Secondly, SQL2XMI is entitled as a lightweighttransformation of data models from SQL Schemas toUML-ER expressed in XMI. To our knowledge, thistool is still limited compared with DB-MAIN sinceit does not infer entity types or cardinalities, and fornow it is only compatible with the MySQL implemen-tation of the SQL DDL.

To sum up, given that a set of existing tools al-ready support data schema extraction from severalsources, without additional specification of transfor-mations, we took advantage of such tools, more pre-cisely we used EA.

5.2 Reverse Engineering

A reverse engineering approach can be classified inseveral ways. Table 3 gives a properties summary ofthe thereafter analysed research works. These proper-ties include: kind of analysis, output, the existence oftools for automating the approach, automation level ofthose tools in regards to the reverse engineering stage,if the tool allows extension and main contributions (A- Aggregations Extraction, G - Implicit Generaliza-tion Extraction and V - Default Values Extraction).

Regarding reverse engineering techniques, sev-eral approaches have been proposed, which are usu-ally distinguished by the particular application arte-fact used as main information source. The most rel-evant research works, following such distinction, aredescribed below.

Schema analysis (Premerlani and Blaha, 1993)is mainly focused on spotting similarities in names,value domains and representative patterns. This tech-nique may help identify missing constructs (e.g. for-eign keys). Moreover, (Premerlani and Blaha, 1993)specification of a manual process was adapted inour approach to semi-automatically and automaticallyidentify generalizations and many-to-many associa-tions, respectively.

Data analysis (Chiang et al., 1994; Pannurat et al.,2010) uses content mined from a database. Firstly itcan be used to analyse the database normalisation andsecondly to verify hypothetical constructs suggestedby other techniques. Given the combinatorial explo-sion that can affect the first approach, data analysistechnique is mainly used with the purpose of the sec-ond approach. In addition, our approach uses thistechnique in a similar way, however it is applied toclassify associations.

Table 2: Classification of some related works on data schema extraction.

Approach Input Schema Extractors Properties OutputGra2Mol (Izquierdo et al., 2008) any textual artefact no n.a. any modelMoDisco (Bruneliere et al., 2014) several sources no n.a. any modelSchemol (Díaz et al., 2013) data stored into DB no n.a. any modelDB-MAIN (Hainaut et al., 1994) several sources yes (e.g. ODBC) yes GERSQL2XMI (Alalfi et al., 2008) SQL DDL schema yes (only MySQL) no UML in XMIEA (our approach) several sources yes (e.g. ODBC) yes UML

Screen analysis (Ramdoyal et al., 2010) state thatuser interfaces can also be sources of useful informa-tion. These user-oriented views over a database maydisplay spatial structures, meaningful names and, atrun time data population and errors combined withdata-flow analysis may provide information aboutdata structures and schema properties. Moreover, ourapproach did not consider this kind of analysis.

Static (Petit et al., 1994; Di Lucca et al., 2000)and Dynamic (Cleve et al., 2011a; Cleve et al., 2011b)program analysis can easily give valuable informationabout field structure and meaningful names, or iden-tifying complex constraint checking and foreign keysafter a complex analysis. A main challenge of dy-namic program analysis is the extraction of highly dy-namic interactions between a program and a database.Moreover, the analysis of SQL statements is one ofthe most powerful variant of source code analysis.Furthermore, our approach uses static program anal-ysis in the profiler log file, aiming to classify associa-tions.

Additionally, a set of approaches, concerning theapplication of MDE, are also taken into account. Ouranalysis focused on their injection and reverse engi-neering stages.

As previously introduced, MoDisco MDREframework (Bruneliere et al., 2014) has a huge poten-tial in order to support reverse engineering activities,due to its generic and extensible properties. Besidesits legacy application discoverers (model injectors),MoDisco also allows the definition of transformationsand generators, responsible for restructuring and for-ward engineering tasks over the system models, re-spectively. Our approach could be implemented ex-tending this framework, however that would requirethe definition from scratch of all the three stages (dis-coverers, transformations and generators) needed toproduce the desired artefacts.

Polo et al. propose a method and a tool, calledRelational Web (Polo et al., 2007) specially designedfor database reengineering. The starting point is a re-lational database, whose physical schema is reverseengineered into a class diagram representing its con-ceptual schema. In the restructuring stage, the class

diagram is manipulated by the user and then passedas input to the forward engineering step. Moreover,this tool supports the definition of new database man-agers to be used as input and the implementation ofnew code generators. Furthermore, on the one handthis approach only uses as input the physical schema,and user knowledge, and its tool does not take advan-tage of the existing MDE techniques nor technologies.However, this approach defined foreign key’s seman-tic extraction techniques, to identify inheritance rela-tionships and associations, that were adapted and ex-tended by our approach, in order to identify aggrega-tions.

As previously stated, DB-MAIN (Hainaut et al.,1994) is a toolbox that offers a complete function-ality with which to apply database reverse engineer-ing. Regarding to reverse engineering DB-MAIN in-cludes features such as extractors of legacy databaseschemas, transformations between schemas, data andcode analysis tools, among others. This tool is oneof the most mature ones, in regard to database re-verse engineering, meaning that it includes severalfeatures that have been the result of a great number ofresearch contributions from Namur University. DB-MAIN supports a lot of common transformations andextraction tools thus, a user with such tools can han-dle almost any needed transformation to create a goodconceptual schema. However, this tool will requirethe user to apply all the needed transformations, thusthe degree of automation achieved in our approach ishigher. Furthermore, DB-MAIN supports generaliza-tion representation, but once again it must be identi-fied by the user.

Regarding to the main contributions of this paper,we do not find any other approach that specializes as-sociations (e.g. distinguishing between associationsand aggregations), nor any approach that allows to ex-tract default values and their representation into thetarget conceptual schema.

Table 3: Classification of some works on reverse engineering.

Approach Analysis Output Tools Auto. Extension Contributions(Premerlani andBlaha, 1993)

schema OMT classdiagram

no n.a n.a. n.a.

(Chiang et al.,1994)

data Extended ER no n.a n.a. n.a.

NoWARs (Pannuratet al., 2010)

data Conceptualschema

yes Semi n.a. n.a.

RAINBOW(Ramdoyal et al.,2010)

screen ER model yes n.a. n.a. n.a.

(Petit et al., 1994) program (static) Extended ER no n.a n.a. n.a.(Di Lucca et al.,2000)

program (static) Object-Orientedclass diagram

no n.a n.a. n.a.

(Cleve et al.,2011a)

program(dynamic)

n.a. yes n.a. n.a. n.a.

(Cleve et al.,2011b)

program(dynamic)

n.a. yes n.a. n.a. n.a.

Modisco(Bruneliere et al.,2014)

schema andprogram (static)

KDM or UML yes Auto. yes n.a.

Relational Web(Polo et al., 2007)

schema UML yes Auto. yes n.a.

DB-MAIN(Hainaut et al.,1994)

schema andprogram (static)

GER yes Semi yes G

XIS-Reverse (ourapproach)

schema, data andprogram

XIS* andRSLingo’s RSL

yes Semi yes A;G;V

6 CONCLUSION AND FUTUREWORK

This paper presented a model-driven reverse engi-neering approach, named XIS-Reverse, applied tolegacy information systems. This approach providesthe opportunity to maintain and extend a given appli-cation, even in cases that the related documentation isoutdated or missing. Moreover, XIS-Reverse is ableto specify an application both as XIS* models andas RSLingo’s RSL specifications. The main contri-butions of this paper in terms of reverse engineering,are focused in the implementation of semi-automaticheuristics that can identify certain relationships be-tween entities, namely aggregations and generaliza-tions, and also the possibility to extract default valuesfrom the source databases to enrich the target modelsor specifications. This identification enables require-ments enhancement, with less effort for the user byusing a tool that supports Reverse Engineering Exe-cutions.

Regarding future work, in terms of extensibilityof the process we would like to evaluate the interop-erability of the produced models with the XIS-Web

framework, for example, and analysing the similarityof a forward engineered application from those mod-els, allied with the smart approach of XIS* technolo-gies, with the original legacy application. Addition-ally, a divide-and-conquer approach could be used tomanage the complexity of identifying implicit gener-alizations, splitting sets of entities by their schema,for example.

ACKNOWLEDGEMENTS

This work was partially supported by national fundsunder FCT project UID/CEC/50021/2013 and theproject TT-MDD-Mindbury/2015.

REFERENCES

Alalfi, M. H., Cordy, J. R., and Dean, T. R. (2008).SQL2XMI: Reverse engineering of uml-er diagramsfrom relational database schemas. In 15th WorkingConference on Reverse Engineering, pages 187–191.IEEE.

Arnold, R. S. (1993). Software reengineering. IEEE Com-puter Society Press.

Bruneliere, H., Cabot, J., Dupé, G., and Madiot, F.(2014). Modisco: A model driven reverse engineer-ing framework. Information and Software Technology,56(8):1012–1032.

Chiang, R. H., Barron, T. M., and Storey, V. C. (1994). Re-verse engineering of relational databases: Extractionof an eer model from a relational database. Data &Knowledge Engineering, 12(2):107–142.

Chikofsky, E. J. and Cross, J. H. (1990). Reverse engineer-ing and design recovery: A taxonomy. IEEE software,7(1):13–17.

Cleve, A., Meurisse, J.-R., and Hainaut, J.-L. (2011a).Database semantics recovery through analysis of dy-namic sql statements. In Journal on data semanticsXV, pages 130–157. Springer.

Cleve, A., Noughi, N., and Hainaut, J.-L. (2011b). Dy-namic program analysis for database reverse engineer-ing. In International Summer School on Generativeand Transformational Techniques in Software Engi-neering, pages 297–321. Springer.

da Silva, A. R. (2003). The XIS approach and principles. In29th Euromicro Conference, pages 33–40. IEEE.

da Silva, A. R. (2015). Model-driven engineering: A surveysupported by the unified conceptual model. ComputerLanguages, Systems & Structures, 43:139–155.

de Almeida Ferreira, D. and da Silva, A. R. (2012).RSLingo: An information extraction approachtoward formal requirements specifications. InModel-Driven Requirements Engineering Workshop(MoDRE), pages 39–48. IEEE.

de Almeida Ferreira, D. and da Silva, A. R. (2013). RSL-IL: An interlingua for formally documenting require-ments. In Model-Driven Requirements Engineering(MoDRE), pages 40–49. IEEE.

De Lucia, A., Francese, R., Scanniello, G., and Tortora, G.(2008). Developing legacy system migration methodsand tools for technology transfer. Software: practice& experience, 38(13):1333.

Dean, J. and Ghemawat, S. (2008). Mapreduce: simplifieddata processing on large clusters. Communications ofthe ACM, 51(1):107–113.

Di Lucca, G. A., Fasolino, A. R., and De Carlini, U. (2000).Recovering class diagrams from data-intensive legacysystems. In Software Maintenance, 2000. Pro-ceedings. International Conference on, pages 52–63.IEEE.

Díaz, O., Puente, G., Izquierdo, J. L. C., and Molina, J. G.(2013). Harvesting models from web 2.0 databases.Software & Systems Modeling, 12(1):15–34.

Filipe, P., Ribeiro, A., and da Silva, A. R. (2016). XIS-CMS: Towards a model-driven approach for develop-ing platform-independent cms-specific modules. InMODELSWARD’2016. SCITEPRESS.

Hainaut, J.-L., Englebert, V., Henrard, J., Hick, J.-M., andRoland, D. (1994). Database evolution: the DB-MAIN approach. In International Conference on Con-ceptual Modeling, pages 112–131. Springer.

Izquierdo, J. L. C., Cuadrado, J. S., and Molina, J. G.(2008). Gra2mol: A domain specific transformationlanguage for bridging grammarware to modelwarein software modernization. In Workshop on Model-Driven Software Evolution.

Pannurat, N., Kerdprasop, N., and Kerdprasop, K. (2010).Database reverse engineering based on associationrule mining. arXiv preprint arXiv:1004.3272.

Petit, J.-M., Kouloumdjian, J., Boulicaut, J.-F., andToumani, F. (1994). Using queries to improvedatabase reverse engineering. In International Con-ference on Conceptual Modeling, pages 369–386.Springer.

Polo, M., García-Rodríguez, I., and Piattini, M. (2007).An mda-based approach for database re-engineering.Journal of Software Maintenance and Evolution: Re-search and Practice, 19(6):383–417.

Premerlani, W. J. and Blaha, M. R. (1993). An approach forreverse engineering of relational databases. In ReverseEngineering, 1993., Proceedings of Working Confer-ence on, pages 151–160. IEEE.

Ramdoyal, R., Cleve, A., and Hainaut, J.-L. (2010). Reverseengineering user interfaces for interactive databaseconceptual analysis. In International Conference onAdvanced Information Systems Engineering, pages332–347. Springer.

Ribeiro, A. and da Silva, A. R. (2014a). Evaluation of XIS-Mobile, a domain specific language for mobile appli-cation development. Journal of Software Engineeringand Applications, 7(11):906.

Ribeiro, A. and da Silva, A. R. (2014b). XIS-Mobile: a dslfor mobile applications. In 29th Annual ACM Sympo-sium on Applied Computing, pages 1316–1323. ACM.

Ruiz, F. et al. (2016). An approach for model-driven datareengineering. PhD dissertation, University of Mur-cia.

Seixas, J. (2016). The XIS-Web Technology: A Model-Driven Development Approach for Responsive WebApplications. MSc dissertation, Instituto SuperiorTécnico, University of Lisbon.