Jump to: navigation, search


< MoDisco
Revision as of 16:22, 28 November 2008 by Fmadiot.mia-software.com (Talk | contribs) (New page: = Architecture of MoDisco = MoDisco aims at providing a platform supporting various legacy modernization use-cases for various kinds of existing technologies. To facilitate reuse of comp...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Architecture of MoDisco

MoDisco aims at providing a platform supporting various legacy modernization use-cases for various kinds of existing technologies. To facilitate reuse of components between several use-cases, MoDisco is organized in three layers:

  • the Use-Cases layer containing components providing a solution for a specific modernization use-case.
  • the Technologies layer containing components dedicated to one legacy technology but independent from the modernization use case.
  • the Infrastructure layer containing generic components independent from any legacy technology.



This layer contains components supporting legacy modernization use-cases. The kind of use-cases MoDisco could support is quite infinite. Nevertheless, the main ones are well identified:

  • Comparison : comparing two versions of the same application at a structural level
  • Quality Analysis: detection of anti-patterns in existing code and computation of metrics.
  • Cartography: detection of the main components of a system and their dependencies.
  • Understanding: extraction of features presented independently from the implementation (structure, behaviour, persistence, data-flow …).
  • Reverse-Modeling: creation of models out of existing systems to populate modeling tools (supporting UML or Domain-Specific Languages).
  • Refactoring: improvement of the source code to integrate better coding norms or design patterns.
  • Migration: transformation of the source code to change the framework, the language, or the architecture of existing applications.


Other more specific use-cases may be supported as, for example, extraction of business rules from programs to populate a business-rules engine, modification of an existing system to better integrate with another system, etc…


The technology layer contains components dedicated to one legacy technology.

These components can be reused between several use-cases components involving the same legacy technology. For example, a use-case computing metrics on Java source code and another providing refactoring for Java applications could reuse the same component.

Use-cases generally involve only one legacy technology (the one used to implement the existing system).

Some use-cases can involve several legacy technologies. It is the case when the existing system is heterogeneous, built with several languages. For example, when a system, implemented with Java, stores data into a relational database using JDBC, the use-case may need MoDisco components able to analyse Java and SQL source code.


Each technology component is composed of, at least, a metamodel of the dedicated technology. This metamodel describes the elements required to support modernization use-cases for the corresponding technology. Depending on the kind of use-case the metamodel can be complete (for refactoring or migration) or partial (for cartography or some quality analysis scenarii).

Ideally, the metamodel is completed by a discoverer, a component which aims at building models conforming to the metamodel from artefacts of an existing system.

Artifacts analysed by discoverers are not necessarily source code files. There exist multiple other ways a discoverer can find the information needed to create a model of an existing system :

  • analysing parameter files
  • analysing execution logs
  • unzipping an archive to access to its contents
  • querying a database
  • using APIs to access a tool with which the system has been designed
  • translating data provided by a reverse-engineering tool into model
  • transforming models provided by another discoverer

A MoDisco Technology component can come with utilities dedicated to its metamodel:

  • Browsers to navigate the models more easily
  • Viewers to represent the models graphically
  • Computation of standard metrics
  • Transformation to standard metamodels (ASTM, KDM, UML …)
  • Generator to regenerate the initial artefact from its model


<to be completed>