The European Space Agency (ESA) has created the Simulation Model Portability 2 ( SMP2 ) standard with the purpose to provide a design solution for the project of Spacecraft Simulators. One element of the SMP2 standard is the metamodel Simulation Model Denition Language (SMDL). The design artefacts of a Spacecraft Simulator consist in descriptions of the business logic shared by a set of SMP2 models. This paper reports results from a study that considers the hypothesis to complement the model-driven design approach of the SMP2 standard with test-driven design techniques. The high-level abstractions of Spacecraft Simulators are used to carry out Model-Driven Development processes, while reusable pieces of software that can to be used by many SMP2 models are designed and developed following Test-Driven-Development . The tool capable to establish the dependencies between the source code produced by the two methodologies and mission specic source code is the GNU Build System.
The design of Spacecraft Simulators is based upon a component model specied
by the the SMDL modeling language which focuses primarily on interface reuse
[
Design prototyping in object orientation is the activity of using objects that represent abstract entities to dene design models. From this premise follows that the planning of the coding activity is done by describing the objects and the business logic they share. Although the design models are written before any programming language specication, we can establish a direct correspondence between the symbology of a modeling language and the symbology of a programming language, thus making the design models a cross-platform specication from which model-driven development departures.
A dierent approach to software design is the specication of code functionalities through test code. Using only test code it is possible to design a piece of software before entering the stage of source code development. Similarly to design models, test code is a design artefact, but it does not follow a pre-dened semantic scheme as per design models. Nonetheless, test-driven development is a restrained process, carried out in closed loop through source code refactoring which makes it appropriated for developing software systems that are continually evolving.
This GNU Build System provides modelling languages to specify
dependencies between source packages [
Our premise is that there are parts of the spacecraft functionality that do not depend on the business logic conguration, because they are generic, context independent and, therefore, reusable. Therefore, the implementation of a Spacecraft Simulator, whether it is accomplished from scratch or as an update to an existing solution, may be decoupled from the design models.
An hybrid system would be possible to recongure by simply adjusting the
variable parts that in it coexist. The articulation of both frameworks, that is, the
integration of the reusable software inside the SMP2 models, is accomplished by
the GNU Build System (see Figure 1). The creation of a SMP2 model is done
indirectly. Template methods of the SMP2 Framework become hook methods
on the specialized classes and the mechanism of object inheritance is used to
plug-in software components into the framework’s hot spots [
To build a functional SMP2 software component it is necessary to link the
code skeletons and the infrastructure libraries with glue code designated by
mission specic , which must reach the reusable behaviour provided by the
infrastructure libraries and make the necessary adaptations to, in its own behalf,
provide to the other SMP2 components the behaviour which is specied in the
SMP2 logic structure. This activity constitutes the tuning of the system and the
GNU Build System guarantees that the system is kept in a consistent state [
Two phases of decoupling are foreseen: the rst decouples interface descriptions from code skeletons, and the second decouples code skeletons from behaviour implementations. The transformation between design models and code skeletons is automated by the model-driven development environment, but the linking to the behaviour implementations is not oered by the SMP2 standard.
The access to the infrastructure functionalities can be automated by adopting
the ‘Adapter’ and ‘Abstract Factory’ GOF [
The hybrid system is developed by an iterative process. In each iteration it
is possible to rene the SMP2 interface signatures or the behaviour provided
by the infrastructure libraries. The granularity of the SMP2 models is decided
upon metrics analysis and the granularity of the Infrastructure Framework is
determined by the number of dierent contexts where a given library can be
reused. If these two operations converge and if relation between the SMP2 models
and the combination of infrastructure libraries is of the type adapter:adaptee,
then the additional coding of mission specic code will increasingly tend to zero
[
With a pure model-driven design approach the initial prototype becomes the
simulator after completing the coding task. This enforces the validation of the
design in the earlier stages of the project life cycle [
A single design approach is hardly a one-size-ts-all solution. An hybrid system is more pluralistic because it provides the software engineers with a large set of building blocks, which are designed to be useful in dierent application contexts and used to build software systems without a fully pre-fabricated structure. In this line of thought, the design of Spacecraft Simulators supported in the two distinct development methodologies of MDD and TDD widens the covering of the software requirements and produces a more complete project specication. The advantage of an hybrid solution is the opportunity to circumscribe the technological push of the SMP2 standard and work exclusively on the design models and evaluate the impact that the modelling breakdown imposes. The GNU Build System is the enabling technology for an hybrid design solution, bringing exibility to the integration of source code derived from the MDD and TDD development lines.