arbitrary number of domains can be identified, being business, technical, or related to life cycle activities. In our metamodel-based approach, any domain can be.
Published at APSEC 2008 December 3-5. Beijing, China
Domain Specific Engineering Environments Jacky Estublier, German Vega, Philippe Lalanda, Thomas Leveque Laboratoire Informatique de Grenoble F-38041, Grenoble cedex 9, France {Jacky.Estublier, German.Vega, Philippe.Lalanda, Thomas.Leveque}@imag.fr
Abstract Computer Aided Software Engineering tools represent one the main successes of software engineering in the past decades. They however need to be improved along several dimensions in order to face new challenges due to ever more complex applications, more heterogeneous technologies and more stakeholders involved. In this paper, we present an approach based on the concept of domain. We define a domain as an area in which a number of stakeholders is repeatedly performing similar activities. In a project, an arbitrary number of domains can be identified, being business, technical, or related to life cycle activities. In our metamodel-based approach, any domain can be easily modelled and the corresponding Computer Aided Domain Specific Engineering environment (CADSE) can be generated. Using CADSE composition, complete and wide scope engineering environments can be built as a composition of an arbitrary number of domains. The paper presents the approach, the technology and draws a few lessons of the first years of use in a number of real projects.
1. Introduction Software development tools represent an essential field of software engineering and one of the most successful. Development tools actually provide support to most project actors allowing them to cope with the inherent complexity of software production. They have thus progressively become indispensable at all the development steps, from early analysis up to maintenance stages. Software development tools also constitute a unique vector for the dissemination of scientific advances in industrial contexts. Experience shows that, without appropriate tool support, a technological progress cannot be widely adopted. The need for better, enhanced development tools in the industry is however greater than ever. This is due, according to us, to the diversity of software developments undertaken nowadays. Software systems pervade every aspects of our life and, consequently,
place very different and demanding requirements on development projects. New development paradigms (SOA, AOP, Product lines etc.) have been proposed to face these new demanding conditions and dedicated tools are expected by the industry to support them. It however turns out that the software community is striving to provide the appropriate development tools. One of the main blocking factors is the cost of producing such tools. In order to be really useful, a tool has to be dedicated to the domain it deals with. For instance, Schneider Electric, a world leader in energy management, has repeatedly asked us for tools supporting the development of service-oriented applications in power distribution. Unfortunately, developing a tool in a narrow domain is generally not cost effective and very few companies can afford such an investment. Most companies then rely on generic tools that are getting unfitted to modern software. In this paper, we present a low cost production of domain-centric engineering environments. Our approach is based on the development of meta-models specifying various related domains and on a reusable framework dealing with the common features of every engineering environment like user interaction control, view point support, advanced building, concurrent engineering, versioning etc. The paper is organized as follows. Our proposal is presented in the coming section. Section 3 presents CADSE architecture and generation, section 4 presents in more detail how engineering environment can be modeled, illustrated in section 5. Related work and conclusions are given in sections 6 and 7.
2. Proposal We have recently produced several development tools for our industrial partners, including Schneider Electric and Thales [1][2]. We subsequently believe that in order to reach a high level of support, a development tool has to meet the following requirements: •
Domain centricity. The more familiar the concepts are, the easier for the developers.
•
Abstraction. A tool has to abstract away technological complexity introduced by programming models and tools.
•
Separation of concern. A tool has to separate concerns as much as possible in order for developers to concentrate on a limited number of issues at the given time.
•
Extensibility. A tool has to be adaptable in order to fit in different context, new concepts, etc.
•
Full-fledged. A tool must provide support for persistency, versioning, collaborative work, etc.
•
Standardized and interoperable. A tool has to be based on existing standards to favour interoperability and reuse. Clearly, a major issue is the cost of meeting so demanding requirements. Building an industrial-strength tool cannot be done from scratch any time a domain appears. Some sort of reuse is absolutely necessary in order to extend the number of tools meeting these properties. To do so, we see a development environment as a composition of engineering domains. We define a domain as an area in which a number of stakeholders are repeatedly performing similar activities. A domain can thus be defined every time a set of engineering activities, practices, tools, methods and conventions shared by a group of persons is identified. Given that definition, several domains naturally appear in the context of a software project: the domain of business experts, the domain of software engineers, the domain of development platform, etc. For a given software project, domains are defined by practitioners given their practices and their desire to simplify, enforce, automate their common practices and to separate them from other engineering activities. Domains are not necessarily independent in time and space, they can be active simultaneously, and share some elements. In order to produce development environments, we propose a generative approach based on the concepts of models and metamodels. We use these terms in the sense given by the model driven engineering community [18] . A metamodel is (the definition of) the language in which are expressed models. A metamodel defines the concepts natively recognized, their relationships, and their valid combinations. A metamodel defines the set (possibly infinite) of all valid models in an area of concern. We use metamodels to specify the various domains of the engineering environment under consideration. Each metamodel focuses on a domain that the practitioners want to consider separately. Meta-links can be defined in order to relate concepts of different metamodels. Meta-links express more than semantic
information: they indicate how entities of different domains can be developed and evolved together. From the metamodels, we generate a tailored development environment, called a CADSE (Computer Aided Domain Specific Environment). A CADSE is a complete software engineering environment dedicated to the support of the engineering activities described in the domain. Within a CADSE, practitioners produce the engineering artifacts which are expected in the domain. Having several explicit domains help developers focus on well separated concerns like the logical architectural design, security, data structures, deployment, etc. Metamodels can also be reused from a CADSE to another one, which allows a faster specification of a new development environment.
3. Domains and CADSE 3.1 Domain modeling and composition A domain metamodel is defined in a modeling language close to the Eclipse Modeling Framework language [12], supporting the concepts of class, operation, attribute, association, containment and inheritance. The modeling language is thus simple and limited to the structural aspect of the software to develop. It does not tackle behavior modeling. Recall that our goal is to define an advanced engineering environment not to develop a model of the software. As previously said, we see an engineering environment as a composition of different domains focusing on limited parts of the whole engineering project. This raises the fundamental issue of domain composition. Composing metamodels is done by establishing meta-links between concepts pertaining to two metamodels. These meta-links express the fact that two concepts are related, but more important, they express how the concepts behave with respect to each other. They express relationships like synchronization, generalization/specialization, extension and so on. More precisely, a meta-link defines how actions on a concept are to be interpreted on the concept at the other end of the meta-link. In our system, a domain composition is a domain allowing structuring a complete engineering environment as a network of, possibly nested, more dedicated environments. 3.2 CADSE architecture and generation We have applied our domain composition approach in a number of projects, including to CADSE development itself: a CADSE is defined as the composition of at least three domains (Figure 1):
•
Engineering Model
Application Software Engineer
Interaction
Synchronization
Platform Model Synchronization
IDE Artefacts CADSE
Application Engineering Conforms-to
Predefined
Engineering MM Ecore MMM
Engineering Domain Expert
Platform MM Platform MMM
Software Domain Expert
Environment Models Environment MMs
Environment Domain Expert
that behaves as defined in the environment model, and that generates software artefacts in an IDE as defined in the platform model. A CADSE is generated by a tool called CADSEg which helps in the definition of the engineering metamodel, platform model and the environment model from which it generates the corresponding CADSE. It is interesting to note that CADSEg is itself a domain specific application (targeting CADSE production) and, as such, is also defined and generated by CADSEg itself.
4 CADSE definition An atomic CADSE is defined by the engineering and platform metamodels and the environment model. A composite CADSE is a “main” atomic CADSE in which are imported other CADSEs. In a composite CADSE, we can declare (with CADSEg) (meta)links between the “main” engineering metamodels and the imported ones, expressing how these domains are related. It is also possible to refine the characteristics of the imported CADSEs (engineering concepts, interaction, views, composites). As a special case, the environment model is itself a composition of different domains, as explained below, and therefore can be easily extended without any need to modify those actually defined.
Domain Engineering Generates
Defines
Figure 1 Three domains for a CADSE
We have arbitrarily predefined the environment and platform metamodels, because the environment is always a software engineering environment and the platform is always an IDE (Eclipse in the current version). As for the engineering area, it obviously has to be defined for each CADSE, and it can take the form of several related metamodels. Links between metamodels and models express how concepts of each area of concern relate. For instance, creating a component called mail (in the engineering area) may initiate a dialog asking which kind of mail should be created (in the environment area), and may generate an IMail.java and a mail.xml file in the right place, change the class-path and project dependencies (in the platform area). Conversely, changes in these files are to be interpreted as changes in the associated mail entity; creating files following known patterns are interpreted as engineering item creations and so on. The environment model defines the behaviour of the completed CADSE, and among other things, defines the semantics of the meta-links, user interaction, versioning and so on. The resulting CADSE is therefore an environment that helps in performing the software engineering activities defined in the engineering model,
4.1 Environment modeling In a first step, we have identified the various concerns that have to be supported by every engineering environment; then we have considered that each one of these concerns can be seen as a CADSE domain. Therefore we have developed, for each identified concern, a metamodel containing the concepts of that domain that we have composed with the engineering area metamodel. These metamodels allow experts to describe the intended CADSE behaviour through models. CADSEg
Build Engineering MMs
Composite Interaction & views
Evolution
Mapping
Engineering
Environment Models
Model
Synchronization Platform Model
Application Software Engineer
Platform MMM
Versioning
•
The engineering area. It defines the concepts and activity and products found relevant in the domain of concern, in a platform and environment independent way. The platform. It defines how the artefacts are managed, the results produced and the activities executed are really represented and performed on a given computer, OS and IDE. The environment. It defines, in a platform independent way, how the CADSE should interact with its users, how activities are to be supported, what has to be automated, how concurrent engineering and versioning are supported and so on.
interaction
•
Model Composition Generation
Synchronization Build
Generated Plug-ins
IDE Artifacts
CADSE
Figure 2 Environment Generation
CADSEg takes these environment models in input and generates the code and the plug-ins that will tailor an extensible IDE (Eclipse or NetBeans), to behave as expected. In CADSEg current version, we rely on the following environment concerns: Composites, Build, Interaction, Views, Mapping and Evolution, as depicted in Figure 2. We have hypothesized, at the beginning of the project, that these models would be enough to fully define the environment behaviour. Currently, CADSE developers can refine the default environment behaviour, and add very specific one. We forecast that with more experience we will support others concerns, for a more precise and advanced behaviour in other areas. 4.1.1 Composites and Build The concept of composite is added to the engineering metamodel through the Composition annotation that can be associated with any link type. A composite is defined as an entity which is the origin of links with the composition annotation (called composition links for short), and which components (atomic or composite themselves) are the ends of these composition links. CADSE generalises the concept and mechanisms of building with the concept of composite. Building a composite means performing a computation on its components (e.g. compiling and building a jar file) and associating the result of this computation to the composite. A composite has the property that once built, for some purpose (like executing), the composite can be use on behalf of its components. For that reason, the composite metamodel defines the operations open and close. In a workspace, when a composite is closed, it is rebuilt and its components are removed, but the activities for which the composite has been designed (e.g. executing, testing, documenting etc.) can still be performed in this light weight and simplified workspace. An open composite is a white box aggregate; a closed composite is a black box. The composite concept provides an abstraction and a view mechanism which give high scalability capabilities to domains. See the companion paper in this conference for a more detailed description of CADSE composites [23]. 4.1.2 Evolution and concurrent engineering Software Engineering, as any heavy engineering, requires provision for evolution and concurrent engineering control [15]. Traditionally, evolution control is interpreted as file versioning in Software Engineering and is well supported. Model versioning is much more difficult and remains an open issue, at least if each model element needs to be individually versioned. CADSE includes a model that expresses the evolution and versioning strategy to be used [14].
The evolution metamodel defines a number of annotations that can be associated with any attribute or link type (immutable, immutable destination, final, branch, effective, conflict, reconcile and others). The evolution metamodel also defines the concept of version and repository and operations commit, import, update and so on defined on all items. Based on this information, the systems can perform extensive consistency control computation when importing an (revision of) item in a workspace; and can make suggestions. For example, if you want to import an item in a workspace the system automatically suggests which versions of that item are compatible which those currently present. Sophisticated evolution strategies, including those currently used in Software Engineering, can be defined, and automatically supported, using these evolution annotations [14]. 4.1.3 Interaction manager and Views The first obvious requirement for a Domain Specific Environment is to assist in creating, changing and deleting the items and links defined in the engineering area. Generating an editor from a metamodel is now found in virtually all meta-tools (GMF [6], EMF [12], XMF, Kermeta etc.). CADSE recognizes that each class of stakeholder requires its own view and interaction model. A view, therefore, “filters” away the information which is not relevant (based on the item and link types), and provides, for each class of stakeholder, a different display and interaction of the relevant information. However, we soon realized that composites provide the fundamental mechanism from which complete viewpoints-based environment can be designed and built. Indeed, a composite supersedes its components for a given purpose. For example, an executable is a composite which purpose may be to debug, to be deployed or optimized etc. A composite therefore is a selected point of view over the set of its components. The ability to handle simultaneously different conceptual viewpoints, while keeping consistent a single model, is achieved in our system by defining several composition hierarchies over the same shared basic components and working on the model in isolated workspaces [23].
4.2 Platform modelling and mappings Engineering activities, directly or through a number of tools (compilers, editors, design tools, version manager, etc.) always end up producing a number of software artefacts which are files and directories. Fortunately, modern Integrated Development Environments (IDE) provide advanced features and convenient interfaces for using these tools and providing
access to the underlying file system. For our purpose, an IDE, and its underlying file system, is the target platform. Unfortunately, different IDEs exist (Eclipse, VisualStudio, NetBean, etc.), and their complexity, when it comes to extend them, is rather high. We have defined an abstract IDE interface which presents only the features and functions needed in a CADSE, mostly what is related to resource and builders management (JSR 198 addresses this topic in a more general way). An implementation of this interface must be developed for each of the targeted IDE; currently only Eclipse is available, but NetBean is planned. The platform metamodel defines concepts and operations in terms of the abstract IDE interface. These concepts are meant to support the technical representation of the engineering entities. For example, we can define that the OSGiService concept is represented as a project (in the abstract IDE sense) containing directories main and src, in which are found files manifest and so on. Then it will be possible to define a meta-link between the concept of Service as found in the engineering domain, and the OSGiService concept in the platform model. Clearly, the engineering concept of Service, can be associated with different platform concepts (like OSGiService, WebService, etc.), and each platform concept can be represented differently depending on the actual IDE, platform, tools and company conventions. We believe that this separation in three levels of abstraction: engineering (to define the concepts of concern in an abstract way), platform (to define the technical representations needed by the engineering concepts), and IDE (to define the physical representation on a real IDE and computer) provide high flexibility, but more important, it gives to the stakeholders of a domain, the concepts, tools and operations which make sense for them, which is the very reason why that domain has been defined.
4.3 CADSE Composition Any serious development requires the collaboration of different stakeholders, ideally working with their own CADSE, making CADSE composition a fundamental issue. We have designed a mechanism, for CADSE composition based on metalinks between the engineering metamodels, and links or annotations between models [13]. This mechanism is unique, but has been designed to address different needs. Supporting the “complete” life cycle is, a major challenge, since domains are primarily related with activities performed during a project life cycle. An
environment covering a large fraction of the whole software life cycle typically spans many CADSEs (e.g. design, development, composition and deployment). On the abstraction dimension, different tasks are managing the same software at different levels of abstraction. Natively, CADSE supports 3 levels of abstractions (IDE, platform and engineering), but it is clear that different engineering models, at different abstraction levels do exist. It is the case when an architectural view (e.g. choreography) is composed with a technological view (e.g. service). On the functional dimension, it is common to separate different concerns and to develop them independently, often in parallel. Each one of these functional dimensions can benefit from a CADSE, as exemplified below between the data and choreography domains. Finally, many non-functional dimensions interfere everywhere, as illustrated by the security example below. We believe that we only scratched the surface of multiple domain composition, and that more experience will unveil new issues and new needs.
5. Example To illustrate our approach, consider the tool support needed for the development of Service Oriented applications. Currently there are many specialized tools to support the different activities involved in the whole lifecycle of service oriented applications; the issue is to seemingly integrate these disparate tools. In CADSE, the first step is to define a domain by identifying the practices, tools, methods and conventions shared by a group of persons, and formalizing this shared knowledge in a metamodel. For example, service orchestration is typically a domain: its stakeholders are designers with the same culture and concerns; they know the concepts of service, workflow, ordering of service execution and so on; in most companies, they also have conventions (names, libraries, repositories, configuration files and so on). Therefore we define an Orchestration CADSE in which these designers will perform their activities, i.e. defining a workflow of service irrespective of their implementation; the platform layer of that Orchestration CADSE being in charge of using the right tools, libraries to generate the needed code and to follow the company conventions. Data management, design, administration, storage, and so on is also a domain on its own right in which the stakeholders share a culture, irrespective of the users of the data. For these stakeholders, we have defined a data management CADSE. With separate environments, we achieve an effective separation of concerns between the
different actors. However, these two domains are not at all independent since the Orchestration CADSE engineering metamodel defines the notions of flow of information among activities; this information being the data handled in the data CADSE. This is expressed by a metalink between the concept of product in the orchestration metamodel, and the concept of data in the data management metamodel. Once the metalinks defined, we generate a new CADSE in which an editor will allow establishing links between an orchestration model and the actual data it is referring to. The same is performed for a security CADSE for example (see Figure 3). Secure Orchestration CADSE Data Orchestration CADSE Security CADSE Security MM
Orchestration CADSE Meta link
Orchestration MM
annotation Security Model
Data Management CADSE Meta link
Data MM
link Orchestration Model
Data Model
Figure 3 CADSE composition
This example is meant only to emphasize that the complete environment was generated establishing metalinks between the metamodels of two existing and reusable domains, illustrating the fact that complete and rich environments can be built “simply” by composition.
6 Experience The first CADSE we have developed was operational in 2001 to support Melusine applications and was rather ad-hoc; it was used to develop several hundred thousand line of code, either for customers (Actoll) or in European research programs (ANSO, SODA, SEEMP). Since the system proved to provide great help, we had demands for developing other CADSE. We realized that developing a CADSE is not an easy task, even with explicit models. Therefore we have developed CADSEg, a CADSE for developing other CADSEs. CADSEg was used to generate a number of simple CADSEs, then to rebuild the complete Melusine CADSE (a rather complex one); and recently to generate itself. Once CADSEg available, late 2006, in a matter of a few months, a number of CADSEs have been developed. Among the CADSEs that have been developed we can mention DOCOSOC a complete composition environment for Schneider Electric [1]; FOCAS, an environment for the orchestration of service based applications [2] (used as example is this paper), an iPOJO, a Service Abstract Machine, a Think / Fractal
environment and so on. From the experience in using CADSE and [23].during the last years, we can bring the following lessons. CADSE interface is a tree structure which is clearly not the ideal interface; a graphical one based on EMF/GMF is under way. With CADSEg we can declare the interaction required for each command (asking for parameters, forms, sheets and so on). The flexibility of the interaction was improved and is considered not an issue now. What is really appreciated by users, and our original goal, is the abstraction provided by the native 3 levels of abstraction. In some CADSE, like in DOCOSOC, the domain is narrow enough for the engineering model to fully describe the targeted software; the code is fully generated and never modified by hand. In other cases, like CADSEg, most of the code is generated (about 80% average), only special cases are to be written by hand. In others, like the Think CADSE, the code is fully written by hand, the CADSE “only” automate the housekeeping, building, naming conventions and so on. In all case have been highly appreciated the fact that the view provided matches the user needs. It comes either from drastic reduction in the number of items as compared with the number of corresponding files (often 2 or 3 orders of magnitude), like in most CADSEs (Think, iPOJO, DOCOSOC etc); or simply because the concepts are those relevant to the user, like in CADSEg, where many items are matched towards a few lines in a file, and where there are more items than files. The hierarchy and abstraction provided by composites have been a major design and implementation challenge, maybe because object oriented approaches are good at defining specialization/generalization hierarchies, but not to define composition structures. Closing composites simplifies significantly the management and understanding of large projects, hiding and sheltering the items which are not of concern for a given task. The build mechanism is very appreciated by those developing nested composites. Indeed, Eclipse does not provide support for nested projects, and therefore building software is fully on the developer’s shoulders. A hard issue is related to evolution control. Because items can be related to a large number of files (an Eclipse project for example), an item evolves even if no attribute or link is changed. Therefore we are versioning items individually, which raises many hard issues about consistency and versioning policy. We believe that this feature is required for a production system As far as we know per item versioning is missing in model based system. This part of the system was reworked a number of time to get a good balance between consistency
(allowing only the combination of compatibles items) and flexibility (accepting temporarily some incompatibilities).
7. Related work Generating tools from a metamodel is in no way a novelty; it is the primary purpose of a formal metamodel [19]. Traditionally, in generic approaches (like programming or modeling languages) tools are focusing on compilation and editors generation [12]. CADSE engineering metamodels fall in the area of generic metamodeling approaches since it is a definition of the target engineering domain. It has also similarities with Architecture Description Languages (ADL) because it includes some knowledge of the common architecture of the applications to build. For that reason, editor generation is pretty similar to most approaches, but in our case, it represents only a small fraction of the generated code. Conversely, our approach is not generic in that it focuses “only” on Software Engineering environment generation, which is a specific domain itself for which we have defined specific metamodels; most of the generated code comes from the compilation of the models associated to predefined metamodels. For the environment and platform domains, our approach falls in the Domain Specific Languages (DSL [17]) area, which traditionally targets as much code generation as possible [11]. The idea of defining an engineering environment as interplay of interconnected domains, business or technical, supported by specialized tools can be traced back to Draco [3] in which a model in one domain is refined into a model of a target domain Linking high-level models to code is an old issue [21] which is now critical. Our approach is not based on model transformation using languages like ATL or QVT, but on the real time synchronization of different models (engineering, platform and IDE), in a similar way as [21]. In this respect our approach, following our previous work [13], is very close to metamodel composition [5] and metalinks are similar to the techniques presented in [6]. Domain specific modeling [10] and their composition was addressed in [4], but in CADSE, we specify not only the composite abstract syntax but the complete resulting engineering environment. Metalinks can also be related to model weaving [7][20], we build an application by weaving models from different interrelated domains. Product lines [16], as well as Software Factories [8] are rather close in their focus of providing a complete engineering environment, but our focus is to generate the environment, and to provide advanced capabilities to combine different focused environments in order to
build a larger scope one. Our approach is more general since the concept of domain we have defined allows for the generation of very different kinds of environments dedicated to more specific concerns like technology, (e.g. component models), life cycle phases, specific activities (e.g. configuration management), specific company division (e.g. marketing) and so on.
8. Conclusion We have used CADSEg to generate many domaincentric engineering environments, including CADSEg and Melusine [13] which are our own everyday development environments. We believe that it allowed us to meet the requirements presented in section 2. In particular, the definition of multiple related domains through metamodels allows an effective separation of concerns. It also permitted us to define and reuse domains related to software engineering and development platforms. The CADSE approach thus allows the systematic, rapid, predictable, and rather inexpensive delivery of highly customized environments. We believe that our work contributes in different ways to the domain of Engineering Environments. We have identified different concerns in an Engineering environment domain that are: • Powerful enough to allow for the definition of a large range of Software Engineering practices and policies. • Wide enough to cover most fundamental Software Engineering concerns. • Independent enough to be freely combined to provide a complete Engineering Environment. • Composable to combine different CADSE targeting different concerns. • Almost fully generated based on a few models. In our approach, the environment domain is a composition of different more specialized domains (composites, build, views, interaction, evolution, concurrent engineering); and we expect to add other concerns (domains) in the future. A basic CADSE is the composition of the (composite) environment domain with the engineering and platform domains. A major contribution is the fact that CADSEg allows for the rapid and rather inexpensive development (generation) of very specialized and supportive CADSEs. But we believe that the main contribution and novelty of our approach is the availability of a CADSE composition technology, fully supported by CADSEg, allowing composing different CADSEs. Therefore, CADSEs tailored to the support of different domains, but that are used (sequentially or simultaneously) in the course of a single software project, can be assembled to form new CADSEs, still very specialized and
supportive, but covering in a consistent way a large range of concerns. It is our belief that this new approach and technology will foster the fast and inexpensive development of many very focused but reusable CADSEs, from which will be assembled wide scope and highly supportive engineering environments. We hope the approach will alleviate, to some extent, the burden of Software Engineering practitioners while fostering better collaboration among them; providing more facilities in adapting and evolving their common practices; helping them in identifying, establishing and improving their common know-how, improving in this way the fundamental asset of their company. References [1] P. Lalanda, C. Marin. “A Domain-Configurable
[10] J. Luoma, J. Kelly, J.P. Tolvanen. Defining DomainSpecific Modeling Languages: Collected Experiences, Workshop on Domain-Specific Modeling (DSM’04), Computer Science and Information System Reports, Tech. Rep., TR-33, Univ. of Jyväskylä, Finland. 2004.
[11] K. Czarnecki. Overview of Generative Software Development. In J.-P. Banâtre et al. (Eds.): Unconventional Programming Paradigms (UPP) 2004, Mont Saint-Michel, France, LNCS 3566, pp. 313–328, 2005
[12] F. Budinsky, D. Steingerg, E. Merks, R. Ellersick, T. Grose, “Eclipse Wesley, 2000.
Modeling
Framework”,
Addison
[13] J. Estublier and G. Vega. “Reuse and Variability in Large Software Applications”. Published in Proc ESEC/FSE September 2005, Lisboa, Portugal.
[14] J.
development environment for Service-Oriented Applications”, IEEE Software, pp 31-38, Vol. 24 No. 6 November 2007.
Estublier, G. Vega. Reconciling Software Configuration Management and Product Data Management. ESEC/FSE, Dubrovnick, September 3-7, 2007.
[2] S.Chollet, P. Lalanda, A. Bottaro. “Transparently adding
[15] J. Estublier, S. Garcia. Concurrent Engineering policies
security properties to service orchestration” in Service Oriented Architectures in Converging Networked Environments (SOCNE 08). Okinawa, Japan, 2008.
in Software Engineering. ASE, Tokyo, Japan. September 2006.
[3] Neighbors, J.M., “Draco: A Method for Engineering Reusable Software Systems”, In Software Reusability, Vol. 1, Chap. 12: Concepts and Models, Biggerstaff, T.J, and Perlis, A.J., eds. pp.295-319. Addison-Wesley, 1989.
[4] A. Ledeczi, A. Bakay, M. Maroti, P. Volgyesi, G. Nordstrom, J. Sprinkle, G. Karsai. “Composing DomainSpecific Design Environments”, Computer, pp. 44-51, November, 2001.
[5] Ledeczi, A. Nordstrom, G. Karsai, G. Volgyesi, P. Maroti, M. “On metamodel composition” in Proceedings of the International Conference on Control Applications (CCA '01), Mexico City, Mexico, 2001.
[6] Emerson
M., Sztipanovits J.. "Techniques for Metamodel Composition". OOPSLA – 6th Workshop on Domain Specific Modeling, Portland, USA, October, 2006.
[7] Jossic, A., Del Fabro, M.D., Lerat, J-P., Bezivin, J. Jouault, F. “Model Integration with Model Weaving: a Case Study in System Architecture” in Systems Engineering and Modeling 2007 (ICSEM'07).
[8] Greenfield J., Short K., Cook S., Kent S. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools, Willey, 2004.
[9] I. Crnkovic, U. Asklund, and A. Persson Dahlqvist. Implementing and integrating Product Data Management and Software Configuration Management. Artch House Publishers, 2003.
[16] Clements P., Northrop L. Software Product Lines: Practices and Patterns, Addison-Wesley, 2001.
[17] J. Luoma, J. Kelly, J.P. Tolvanen. « Defining DomainSpecific Modeling Languages: Collected Experiences », Workshop on Domain-Specific Modeling (DSM’04), Computer Science and Information System Reports, Tech. Rep., TR-33, Univ. of Jyväskylä, Finland. 2004.
[18] Bézivin, J., and Gerbé O. Towards a Precise Definition of the OMG/MDA Framework. In Proceedings of 16th Conference on Automated Software Engineering. (ASE 2001) (San Diego, USA, November 26-29 2001).
[19] Favre J.M. Towards a Basic Theory to Model Driven Engineering. WiSME Lisbon, Portugal, October 11-15, 2004.
[20] P.-A. Muller, F. Fleurey, et J.-M. Jézéquel. Weaving executability into object-oriented meta-languages. In Proceedings of the MoDELS/UML 2005 - pp. 264-278, Montego Bay, Jamaica.
[21] Gail C. Murphy, David Notkin, Kevin Sullivan. Software Reflexion Models: Bridging the Gap between Source and High-Level Models. SIGSOFT '95 Washington, D.C., USA.
[22] H. Giese, R. Wager. Incremental Model Synchronization with Triple Graph Grammars. LNCS 4199/2006, Pages 543-557. November 2000.
Volume
[23] J. Estublier, G. Vega, T. Leveque. Management of Composites in Software Engineering Environments. APSEC, December 3-5, 2008 Beijing.
