Project-Team-Triskell:Object Oriented Technologies for Distributed Software Engineering

Project-Team : triskell

Section: Scientific Foundations

Keywords: Objects, design patterns, frameworks, software components, contracts, UML.

Object Oriented Technologies for Distributed Software Engineering

Object-Oriented Software Engineering

The object-oriented approach is now widespread for the analysis, the design, and the implementation of software systems. Rooted in the idea of modeling (through its origin in Simula), object-oriented analysis, design and implementation takes into account the incremental, iterative and evolutive nature of software development [47], [44]: large software system are seldom developed from scratch, and maintenance activities represent a large share of the overall development effort.

In the object-oriented standard approach, objects are instances of classes. A class encapsulates a single abstraction in a modular way. A class is both closed, in the sense that it can be readily instanciated and used by clients objects, and open, that is subject to extensions through inheritance [50].

Design Pattern

Since by definition objects are simple to design and understand, complexity in an object-oriented system is well known to be in the collaboration between objects, and large systems cannot be understood at the level of classes and objects. Still these complex collaborations are made of recurring patterns, called design patterns. The idea of systematically identifying and documenting design patterns as autonomous entities was born in the late 80's. It was brought into the mainstream by such people as Beck, Ward, Coplien, Booch, Kerth, Johnson, etc. (known as the Hillside Group). However the main event in this emerging field was the publication, in 1995, of the book Design Patterns: Elements of Reusable Object Oriented Software by the so-called Gang of Four (GoF), that is Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides [46]. Today, design patterns are widely accepted as useful tools for guiding and documenting the design of object-oriented software systems. Design patterns play many roles in the development process. They provide a common vocabulary for design, they reduce system complexity by naming and defining abstractions, they constitute a base of experience for building reusable software, and they act as building blocks from which more complex designs can be built. Design patterns can be considered reusable micro-architectures that contribute to an overall system architecture. Ideally, they capture the intent behind a design by identifying the component objects, their collaborations, and the distribution of responsibilities. One of the challenges addressed in the Triskell project is to develop concepts and tools to allow their formal description and their automatic application.

Framework

Frameworks are also closely related to design patterns. An object-oriented software framework is made up of a set of related classes which can be specialized or instantiated to implement an application. It is a reusable software architecture that provides the generic structure and behavior for a family of software applications, along with a context which specifies their collaboration and use within a given domain [42]. A framework differs from a complete application in that it lacks the necessary application-specific functionality. It can be considered as a prefabricated structure, or template, of a working application, where a number of pieces in specific places, called plug-points or hot spots, are either not implemented or given overridable implementations. To obtain a complete application from a framework, one has to provide the missing pieces, usually by implementing a number of call-back functions (that is, functions that are invoked by the framework) to fill the plug-points. In an object-oriented context, this feature is achieved by the dynamic binding: an operation can be defined in a library class but implemented in a subclass in the application specific code. A developer can thus customize the framework to a particular application by subclassing and composing instances of framework classes [46]. A framework is thus different from a classical class library in that the flow of control is usually often bi-directional between the application and the framework. The framework is in charge of managing the bulk of the application, and the application programmer just provides various bits and pieces. This is similar to programming some event driven applications, when the application programmer usually has no control over the main control logic of the code.

Design patterns can be used to document the collaborations between classes in a framework. Conversely, a framework may use several design patterns, some of them general purpose, some of them domain-specific. Design patterns and frameworks are thus closely related, but they do not operate at the same level of abstraction: a framework is made of software, whereas design patterns represent knowledge, information and experience about software. In this respect, frameworks are of a physical nature, while patterns are of a logical nature: frameworks are the physical realization of one or more software pattern solutions; patterns are the instructions for how to implement those solutions.

Component

The object concept also provides the bases needed to develop software components, for which Szyperski's definition [52] is now generally accepted, at least in the industry:

A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party.

Component based software relies on assemblies of components. Such assemblies rely in turn on fundamental mechanisms such as precise definitions of the mutual responsability of partner components, interaction means between components and their non-component environment and runtime support (e.g. .Net, ejb, Corba Component Model).

Components help reducing costs by allowing reuse of application frameworks and components instead of redeveloping applications from scratch (product line approach). But more important, components offer the possibility to radically change the behaviors and services offered by an application by substitution or addition of new components, even a long time after deployment. This has a major impact of software lifecycle, which should now handle activities such as:

design of component frameworks,
design of reusable components as deployment units,
validation of component compositions coming from various origins,
component life-cycle management.

Empirical methods without real component composition models have appeared during the emergence of a real component industry (at least in the Windows world). These methods are now clearly the cause of untractable validation and of integration problems that can not be transposed to more critical systems (see for example the accidental destruction of Ariane 501 [48]).

Providing solutions for formal component composition models and for verifiable quality (notion of trusted components) are especially relevant challenges. Also the methodological impact of component-based development (for example within the maturity model defined by the sei (cmm model)) is also worth attention.

Contracts

Central to this trusted component notion is the idea of contract. A software contract captures mutual requirements and benefits among stake-holder components, for example between the client of a service and its suppliers (including subcomponents). Contracts strengthen and deepen interface specifications. Along the lines of abstract data type theory, a common way of specifying software contracts is to use boolean assertions called pre- and post-conditions for each service offered, as well as class invariants for defining general consistency properties. Then the contract reads as follows: the client should only ask a supplier for a service in a state where the class invariant and the precondition of the service are respected. In return, the supplier promises that the work specified in the postcondition will be done, and the class invariant is still respected. In this way rights and obligations of both client and supplier are clearly delineated, along with their responsibilities. This idea was first implemented in the Eiffel language [51] under the name Design by Contract, and is now available with a range of expressive power into several other programming languages (such as Java) and even in the Unified Modeling Language (UML) with the Object Constraint Language (OCL) [53]. However, the classical predicate based contracts are not enough to describe the requirements of modern applications. Those applications are distributed, interactive and they rely on resources with random quality of service. We have shown that classical contracts can be extended to take care of synchronization and extrafunctional properties of services (such as throughput, delays, etc) [43].

Modeling with the UML

As in other sciences, we are increasingly resorting to modelling to master the complexity of modern software development. According to Jeff Rothenberg,

Modeling, in the broadest sense, is the cost-effective use of something in place of something else for some cognitive purpose. It allows us to use something that is simpler, safer or cheaper than reality instead of reality for some purpose. A model represents reality for the given purpose; the model is an abstraction of reality in the sense that it cannot represent all aspects of reality. This allows us to deal with the world in a simplified manner, avoiding the complexity, danger and irreversibility of reality.

The massive adoption of Unified Modeling Language (UML) in many industrial domains open new perspectives to make the underlying ideas on modeling evolve, scale up, and hence become profitable. Unlike its predecessors, (omt, Booch, etc.), that only proposed a graphical syntax, UML is partially formalized by a meta-model (expressed itself as a UML model) and contains a very sophisticated constraint language called OCL (Object Constraint Language), that can be used indifferently at the model level and at the meta-model level. All this makes it possible to consider formal manipulations of models that capture many aspects of software, both from the technical side, (with the four UML main dimensions: data, functional, dynamic, and deployment) and on the process side, ranging from the expression of requirements and the analysis to design (framework models and design patterns) and test implementation.

Model Driven Engineering

Usually in science, a model has a different nature that the thing it models ("do not take the map for the reality" as Sun Tse put it many centuries ago). Only in software and in linguistics a model has the same nature as the thing it models. In software at least, this opens the possibility to automatically derive software from its model. This property is well known from any compiler writer (and others), but it was recently be made quite popular with an OMG initiative called the Model Driven Architecture (MDA).

The OMG has built a meta-data management framework to support the MDA. It is mainly based on a unique M3 ``meta-meta-model'' called the Meta-Object Facility (MOF) and a library of M2 meta-models, such as the UML (or SPEM for software process engineering), in which the user can base his M1 model.

The MDA core idea is that it should be possible to capitalize on platform-independent models (PIM), and more or less automatically derive platform-specific models (PSM) –and ultimately code– from PIM through model transformations. But in some business areas involving fault-tolerant, distributed real-time computations, there is a growing concern that the added value of a company not only lies in its know-how of the business domain (the PIM) but also in the design know-how needed to make these systems work in the field (the transformation to go from PIM to PSM). Reasons making it complex to go from a simple and stable business model to a complex implementation include:

Various modeling languages used beyond UML,
As many points of views as stakeholders,
Deliver software for (many) variants of a platform,
Heterogeneity is the rule,
Reuse technical solutions across large product lines (e.g. fault tolerance, security, etc.),
Customize generic transformations,
Compose reusable transformations,
Evolve and maintain transformations for 15+ years.

This wider context is now known as Model Driven Engineering.