Logiciels, Systèmes, Réseaux - IMAG-OneTree Technologies SA
|Lieu||Luxembourg ( et Grenoble )|
Modern software engineering methodologies have raised awareness of modeling activities in software construction. Currently, models are identified as valuable asset in the software development lifecycle. Popular approaches like Model-Driven Architecture (MDA) are a clear attempt to raise abstraction from code to more concise and easier to understand models. Although these approaches are increasingly gaining popularity in industry, a general discomfort about the overall approach is felt by software modeling experts and perceivable in conferences, workshops and industrial experience reports. In one hand research work has proliferated UML ?flavors ? and ?Architecture description languages ? that are not transferred to the industry. On the other hand, discussions in the academia about poor software engineering practices do not really reach the industry. This situation is to be contrasted with the need for controllable, traceable, and easy to validate software development process.
The MDE community is making an important step in this direction by promoting model transformation as the ?breadcrumb trail ? from early stages of development down to detailed design model transformation in order to produce code. Although MDE is slowly becoming an acknowledged branch of the software engineering, especially in the academia, a large set of issues still remain open for investigation :
? Current software engineering methodologies are poor in addressing the rationale of models. This often leads to ambiguities as for the role of the various models (existing or to be created). For instance, a relational database schema can be used by OO developers as persistent store for object-oriented code, while PL/SQL developers would rather use the same schema to write stored procedures that directly manipulate the data outside OO code. Failure to clarify the rationale of models, especially in large projects, lead to design inconsistencies or even to architecture misconceptions that could lead complete projects to failure. The problem is even more complex when dealing with more abstract models like high-level specification UML diagrams or other conceptual diagrams produced at early stages of a software project.
? Current software methodologies are poor in capturing and capitalizing domain (functional) knowledge. The software industry is clearly driven by waves of technical/technological solutions. Today ?s Integrated Development Environments come with support for a plethora of libraries and provide a large number of plug-ins for assisting generation of various kinds of patterns. In that context it is rare to find software analysts that still keep their focus in understanding the vocabulary of experts, capture the essential abstractions of the domain, then transform this business knowledge to models that can in turn be understood by software developers. Although the essence of the software process is supposed to be creation of a system that maps seamlessly to the problem domain, most of today ?s software experts are spending most of their time in coding patterns and technical abstractions that might be unnecessary or even useless.
? Current software methodologies are poor in capturing the separation between problem analysis and solution specification. For example, MDA-based development largely focuses in the definition of PIM or PSM models and their transformation to code. But how one can be sure that a given PIM or PSM covers the needs addressed in the requirements ? Software engineering methodologies are fragile when dealing with modification or requirements and it is rare to find methodologies that point the need for problem analysis as a stand-alone task of the software process. In particular, a clean separation between the following type of models in nearly absent from current software methodologies : models capturing the functional problem domain, models capturing the technical problem domain (e.g. availability, scalability, reliability), models showing explicitly how functional and non functional aspects are tackled at a software architecture level, models expressing functional capabilities of existing (legacy) systems, models expressing technical capabilities of existing (legacy) systems (e.g. ACID Transactions, Clustering, Remote deployment).
Following the MDE philosophy, models represent any kind of information related to the software process. Each model should be expressed in a well defined language (UML, but also other less or more formal notations, depending on the context and the intent/purpose of the model). These languages should be explicitly described by means of metamodels to ensure that tools can deal with models.
The objective of the work is to provide a development approach where modeling decisions are captured and can be traced throughout the software life-cycle. Mappings between models should also be formalized and described through mapping metamodels. Currently an important area of research aims at defining transformation languages to automate these mappings. For instance, typical applications of such languages consist in providing software engineers means to define their own rules for code generation or database schema generation from UML class diagrams. In such cases models of transformations can be interpreted by a model transformer and are directly executable.
The degree of automation that can be achieved in late stages is quite high. This is not the case for early stages such as analysis. Obviously, it is expected that model transformations and mappings should expressed in a rather descriptive/heuristic guidance. The idea is to supply software engineers with a framework in which they can build mappings on their own, and then to provide them support to evaluate these mappings a posteriori. Once again, this will be possible only if all mappings are described explicitly by models written in well-defined languages.
In practice, validation is achieved through tests. Tests and associated models should also be mapped to the models described above. For instance, models of scenario or test plans could be mapped to the business and technical models they intent to validate.
The candidate will be hosted for 50% of the time of the thesis at IMAG ?s LSR Laboratory in Grenoble and 50% at OneTree Technologies offices in Luxembourg.
Cette offre vous a été transmise via La Navette CIFRE de placeOjeunes. Nous vous remercions de mentionner la référence ’placeOjeunes’ lors de votre candidature.