The modelling approach for the framework and for applications instantiated from it is dictated by the framework development process. The following types of models are directly provided by the OBS Framework:

Additionally, the OBS Framework supports the creation of application models as instances of the OBS Framework model. The general modelling approach is that pioneered in the feature-based framework modelling project.

Feature Models

The OBS Framework uses feature models as a means to describe the variability and commonality within its target domain. In general, a feature is a characteristic of a concept and a feature model is a description of the relevant features of some entity of interest. In the case of the OBS Framework, the feature model describes the features that are mandatory for all applications to be instantiated from the framework, and the features that are optional and that applications instantiated from the framework may choose to include or to leave out. In some cases, the framework model can specify that a feature can only be present in one of a possible range of allowed options. Features can have a cardinality that represents the number of times they can be present in an application.

Feature modelling for the OBS Framework is used at three levels of abstraction as illustrated in the figure:

The framework meta-level contains items that are framework-independent. Two such items are provided:

The Framework Meta-Model: this is an XSD Schema that defines the features that are allowed when modelling a framework and their mutual relationships
The Application XSD Generator: this is an XSL program that can automatically generate the Application XSD Schema from a framework model. The application XSD schema is the application meta-model that constrains the constructions of models of applications instantiated from a certain framework.

The framework model is obtained as an instance of the framework meta-model and it is expressed as an XML document. Formally, the fact that the framework model is an instance of the framework meta-model is expressed by constraining the XML representation of the framework model to be validated by the Framework XSD Schema that represents the framework meta-model. The application model describes the features that are present in a specific applications. An application model represents a formal specification of an application to be instantiated from the framework. The application model can be seen as an instance of the framework model. The relationship of instantiation is formally expressed by stating that the application model must be validated by the XSD schema generated by the Application XSD Generator.

Following the feature-based framework modelling approach, framework models in the OBS Framework are represented as tree-like structures where each node represents a feature and each feature can be split into sub-features that are represented by child nodes. Features are refined in sub-features up to the point where the sub-features can be directly mapped to framework constructs. Graphical notations can be used to distinguish between mandatory and optional features. An application model could be represented using a similar notation. The graphical representation of the feature models is at present not supported for the OBS Framework but tools to support it are being developed and will be included in future releases of the framework.

Framework Meta-Model

The meta-model for the OBS Framework is the same meta-model proposed in the feature-based framework modelling project. The framework meta-model provided by this project may evolve in the future. For reference, the framework meta-model elements that were used to construct the framework model are included in the OBS Framework web site:

Framework Model

The framework model is expressed in XML and must comply with the Framework XSD Schema defined by the framework meta-model. It consists of a set of XML documents with each document describing one major feature of the OBS Framework. A feature is described in terms of sub-features and all the features can be arranged as a single tree-like structure with a top-level root feature. This root feature is called ObsApplication and is described in the FeatureObsApplication.xml document. The framework model can be found in the OBS Framework delivery in directory: ObsFramework/model/xml. This directory contains contains all the XML documents representing the framework features. The processing of the framework models is controlled by the build.xml Ant build file.

As indicated in the figure above, the application XSD generator (part of the framework meta-model) can be run on the framework feature model to automatically generate the Application XSD Schema. This XSD Schema defines the structure of the feature models of applications instantiated from the framework. The Application XSD Schema can be found in the OBS Framework delivery in directory: ObsFramework/model/xsd.

Application Model

The model of an application instantiated from the OBS Framework can be derived by instantiating the framework feature model. The application model is an instance of the framework feature model in the sense that it specifies which of the optional framework features must be present in the application. The application model contains all the information required to instantiate the framework and can be regarded as a formal specification of the part of the target application that can be directly generated from the framework. In principle, the application model can be used as an input for a fully automated framework instantiation process. The generator meta-components and the transformer meta-components provided by the OBS Framework implement part of this automated instantiation process.

The delivery of the OBS Framework contains a number of classes that have been automatically generated by framework meta-components by processing a sample application model instantiated from the OBS Framework model. This model can be seen as a single XML file or as collection of XML documents that contain the models of subsets of the sample application. The latter XML documents can be found in directory: ObsFramework/src/xml. The sample application model does not model a complete OBS application. It is only provided for demonstration purposes. It covers the following high-level items:

Three Finite State Machines (FSMs) of which the first one associated lower level FSMs to each of its states (this mimics the modelling of a set of operational modes to each of which a number of submodes are associated). In most cases, only dummy actions are associated to the FSM states.
A sample data pool
A sample parameter database
A dummy OBS Clock
An event repository
Four control action components to each of which a dummy control block is associated
A manoeuvre manager
A telecommand manager
A telemetry manager

Class Model

The framework class model describes the framework in terms of its concrete components and abstract interfaces. Two UML models are provided. The first one makes the framework abstract interfaces explicit. The choice of C++ as an implementation language and the decision to use only single class inheritance led to the mapping of the abstract interfaces to abstract base classes. Thus, a second class model is offered that reflects the class-based implementation of the framework rather than its interface-based design. Both class models are made available as XMI files (XMI 1.1 for UML 1.4). They can be found in the project directory ObsFramework/models/xmi.

Source Code Model

The framework concrete components and abstract interfaces are implemented in C++. The possibility exists that future versions of the OBS Framework will be implemented using Java as a target language. It is therefore desirable to make the implementation as language-independent as possible. Total language independent is impossible to achieve at present. Language-dependence can however be lessened by exploiting recently developed techniques for XML-based modelling of source code.

These techniques exist in many variants but the basic idea is that the source code is parsed and its abstract syntax tree is expressed as an XML document where each XML element describes one syntactical element in the source code (the level of granularity at which the code is described varies across tools). The XML document conforms to an XML Schema that therefore defines a sort of modelling language for the source code. The XML-based models of the source code are not language-independent but, in the case of languages like Java and C++ that are syntactically and semantically very close, they open the prospect to automatic or semi-automatic translation across the two languages. The possibility of automating the translation from one language to the other is even greater in the case of the OBS Framework where the use of C++ is basically restricted to the Java-like subset of the language and all constructs that do not have direct counterparts in Java are avoided (see discussion of the C++ code quality).

The XML model of the framework source code was constructed using the public domain srcML tool (version and can be found in project directory ObsFramework/models/srcML.

OBS Framework