Engineering environments

It is widely accepted that, in software engineering, the major improvements in productivity, predictability and quality are due to the availability of CASE tools and SE environments. But the support an environment can provide is proportional to the knowledge it has of the task to perform (methods, tools, conventions, libraries, architectures etc.). This knowledge does not necessarily cover a complete business area but any domain defined as an engineering area in which a class of stakeholders is performing the same activity again and again; "the same" meaning that there are significant similarities among these activities. Therefore the concept of domain is very large; it covers partial or complete business activities, but also any engineering activity in which can be identified a set of practices, tools and conventions shared by a group of persons. Domains can refer either to a subset of the business, to some technology, to a phase of the life cycle (design, develop, deploy etc.), or any mixture of the above. They are all Computer Aided Domain Specific Environments (CADSEs).

For that reason, many tools and environment today, like IDE, SCM systems, design systems, administration systems and so on can be seen through the unifying concept of CADSE, allowing envisioning a systematic Software Engineering approach for their design, development, composition and evolution which is the overall topic of our work. Indeed, despite their differences, all CADSEs rely on two fundamental aspects:

1. the knowledge of the targeted domain, which is embedded in the environment, and
2. a mechanism for using this domain specific knowledge for the tasks at hand.

The more specialized, the more automated an environment can be; but being very narrow the environment cannot automate and guide the user when performing related activities. Therefore, the broader the coverage, the more supportive in term of method and guidance an environment can be. The logical consequence is that a real development should be supported by a number of different CADSEs, each one tailored for a given kind of stakeholder, in a given phase of the life cycle, performing a given task in a given company. This (hypothetic) proliferation of CADSEs would raise a number of additional questions like: what are the relationships between CADSEs? How to compose and reuse CADSEs? How to support concurrent engineering which involves different CADSEs? and so on. Instead of proposing a unique and heavy large scope environment, like in product line or software suites, we propose an approach in which each CADSE is a composition unit which exposes its functionality (as a set of models), and which targets a well defined scope of functionalities. A large scope CADSE is a composition of more specialized CADSEs, independently designed, developed and maintained. Provided each CADSE is built based on a set of models which are conform to the same set of metamodels with well known semantics, it is possible to define the concepts, techniques and methods, based on metamodel and model composition, needed for composing different CADSEs in different cases. The approach should solve a number of issues:

• Supply chains can be built assembling the CADSEs supporting the business performed in the different suppliers contributing to a complex product.
• Large scope business CADSEs (like Product lines) can be built assembling a number of CADSEs addressing each one a different sub-set of the business.
• Large scope CADSEs in all domains can be built assembling a number of CADSEs addressing each one a different phase of the software life cycle.
• Technical CADSEs can be reused in all domains which rely on that technique (IDE, component model, middleware etc.).
• CADSE evolution (fixes, extensions, adaptations) can be handled versioning each CADSE individually and making evolve the configuration.

Major results Oct. 2006-Oct. 2009:

The first CADSE we have developed was operational in 2001. 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; FOCAS, an environment for the orchestration of service-based applications, an iPOJO, a Service Abstract Machine, a Think/Fractal environment and so on.

Perspectives:

The approach consists, fundamentally, in reusing (sic) the principles and approaches (abstraction, encapsulation, separation of concern, composition and reuse) which made the success of Software Engineering in general, replacing the nature of the parts (from code to models), changing the granularity and abstraction level (from component to CADSE) and changing the composition technology (from procedure call to model and metamodel composition). More generally, we believe that the approach could be extended from CADSE construction to any software construction and most Software Engineering activities, contributing to the more general field of Model Driven Engineering.