Dbm (discuter | contributions) m |
Dbm (discuter | contributions) m |
||
Ligne 37 : | Ligne 37 : | ||
:*<b>Languages for CASE tools</b>. [DB-MAIN] [P99-03] [P99-06] [PHD00] | :*<b>Languages for CASE tools</b>. [DB-MAIN] [P99-03] [P99-06] [PHD00] | ||
− | :*<b>Co-transformation</b> (''language processing''). [P04-03][P06-04] [P06-06] | + | :*<b>Co-transformation</b> (''language processing''). Current studies on software intensive system evolution emphasize the concept of co-transformation. When two artefacts A and B interact (e.g., program B working on database A), modifying A may imply modifying B accordingly. If changes to A can be modeled by transformations, the adaptation of B can, under specific conditions, be carried out automatically. The coordinated modification of A and B is called ''co-transformation''. The idea was first suggested in [B86] to automatically transform ADL algorithms defined on a conceptual schema into algorithms compliant with a logical model such as SQL, standard file structure or CODASYL. More recently, co-transformations were studied in the context of data intensive system evolution. The problem addressed is the following. We consider, as a case study, a legacy database that is to migrate to a modern platform. The best approach consists in reverse engineering the legacy database in order to get its conceptual schema, then to generate a new database according to the new data model. Then the legacy data are transformed and moved to the new database and, finally, the application programs are adapted to the new schema and the new API. The whole process can be described as a co-transformation of schema, data and programs, driven by schema transformation. In this process, program transformation is particularly challenging. The problem is described in [P04-03], [P06-04] and [P06-06], an application in [P08-05] and the full solution, including the use of ASF/SDF for program transformation, in [PHD09]. |
:*<b>Program understanding</b> (''language processing''). Database reverse engineering requires the elicitation of implicit (i.e., not explicitly declared in the DDL code) data structures and constraints. This process relies on various techniques such as data analysis, schema analysis and program source code analysis. Code analysis is a complex matter but it provides essential information on the data structures. For instance, implicit foreign keys can be detected through the examination of the data validation sections that precede the insert statements in application programs. Identification of programming ''clichés'', dependency graph and program slicing are some techniques that have been studied and implemented in DB-MAIN [P96-01] [P98-01] [P98-02] [PHD03]. Recently, we applied dynamic program analysis techniques to the detection of dynamic SQL statements, which are increasingly used in web applications (through JDBC for instance). [P08-02] [PHD09] | :*<b>Program understanding</b> (''language processing''). Database reverse engineering requires the elicitation of implicit (i.e., not explicitly declared in the DDL code) data structures and constraints. This process relies on various techniques such as data analysis, schema analysis and program source code analysis. Code analysis is a complex matter but it provides essential information on the data structures. For instance, implicit foreign keys can be detected through the examination of the data validation sections that precede the insert statements in application programs. Identification of programming ''clichés'', dependency graph and program slicing are some techniques that have been studied and implemented in DB-MAIN [P96-01] [P98-01] [P98-02] [PHD03]. Recently, we applied dynamic program analysis techniques to the detection of dynamic SQL statements, which are increasingly used in web applications (through JDBC for instance). [P08-02] [PHD09] |
<Back to Themes & Resources page>