Dbm (discuter | contributions) m |
Dbm (discuter | contributions) m |
||
Ligne 35 : | Ligne 35 : | ||
:*<b>Conceptual API for system evolution</b> (''API''). The fast evolution of applications systems forces developers to adopt defensive programing techniques to facilitate system adaptation. We have developed a Java API that offers data manipulation at the conceptual level (according to a variant of the Entity-relationship model). The API is automatically generated by the DB-MAIN CASE tool according to rules that minimize the impact of changes on the database, on the data and on the application programs [P10-05]. | :*<b>Conceptual API for system evolution</b> (''API''). The fast evolution of applications systems forces developers to adopt defensive programing techniques to facilitate system adaptation. We have developed a Java API that offers data manipulation at the conceptual level (according to a variant of the Entity-relationship model). The API is automatically generated by the DB-MAIN CASE tool according to rules that minimize the impact of changes on the database, on the data and on the application programs [P10-05]. | ||
− | :*<b>Languages for CASE tools</b>. As any high-end CASE tool, the DB-MAIN environment allows users to develop new functions (checkers, code/report generators, reasoners, etc.) A first language, Voyager 2, was developed in 1995. This complete procedural language provides declarative statements to access the DB-MAIN repository (the database in which DB-MAIN stores the projects, schemas and other products it manages). Later on, ReveR (the spin-off of the LIBD in charge of the maintenance and evolution of the tool) included a JVM (Java virtual machine) into the tool to allow java plug-ins to be developed as well [DB-MAIN]. In parallel, a new research was conducted on generic CASE tool architectures. The proposal comprised three languages, namely a concept definition language, a procedural language and a graphical language (GRASYLA) [P99-03] [P99-06] [PHD00]. The research is ongoing through the development of the | + | :*<b>Languages for CASE tools</b>. As any high-end CASE tool, the DB-MAIN environment allows users to develop new functions (checkers, code/report generators, reasoners, etc.) A first language, Voyager 2, was developed in 1995. This complete procedural language provides declarative statements to access the DB-MAIN repository (the database in which DB-MAIN stores the projects, schemas and other products it manages). Later on, ReveR (the spin-off of the LIBD in charge of the maintenance and evolution of the tool) included a JVM (Java virtual machine) into the tool to allow java plug-ins to be developed as well [DB-MAIN]. In parallel, a new research was conducted on generic CASE tool architectures. The proposal comprised three languages, namely a concept definition language, a procedural language and a graphical language (GRASYLA) [P99-03] [P99-06] [PHD00]. The research is ongoing through the development of the METADONE metaCASE tool. |
:*<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>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]. |
<Back to Themes & Resources page>