ASCoDT Component Specification

From Sccswiki
Jump to navigation Jump to search

For the specification of components, ports and interfaces we use a simplified version of SIDL. The grammar for the simplified language can be downloaded from File:Grammer.doc. The language in our implementation is meant only for prototyping purposes. It supports only a small set of types, which are crucial for scientific applications.

SIDL - Short Introduction

A component in ASCoDT is an autonomous soft- ware entity with a state and an interface. Multiple instances of one component may exist. Hence, a component is similar to an object of a class, and we use class as synonym for component definitions. Our components can be distributed among different computers running in processes or applications, respectively, of their own. The static structure of our applications consists of interfaces and classes, i.e. components interacting due to these interfaces. Both are organised in packages mirroring the namespace concept of C++ and Java. Interfaces prescribe a signature, i.e. comprise methods, and they can extend other interfaces. A class implements interfaces and uses interfaces. Whenever a class implements an interface, the class has a provides port. The port’s type is given by the interface. Whenever a class uses another interface, the class has a uses port. The port’s type is given by the interface. This static structure in our case is written down in a simplified scientific interface definition language (simplified SIDL).

Interfaces and classes

An interface in sidl includes a set of operations. The operations correspond to void function from the c language. Two types of parameters are supported: the input parameters and input/output parameters. The first is parameter with read-only semantics and seconds allows the realisation of return semantics. We support the following atomic types and 1D- arrays from them:

  • int
  • double
  • bool
  • String

The following example shows a simple interface with the name Interface1 located in the package pa.pb. The interface offers one operation: the foo operation with one read-only integer parameter and one read/write array from doubles. The second interface offers the function bar without parameteres.

package pa{

 package pb{
   interface Interface1{
     foo(in int a, inout double b[]);
   interface Interface2{
   @target = java_local
   class Component1 implements-all Interface1 uses Interface2 as entryPoint{
   @target = java_native
   class Component2 implements-all Interface2{


Interfaces can extend already existing interfaces through the extends keyword. Components are represented in sidl as classes. To type of relations exists between components and interfaces : uses-relationship and provides-relationship. In the previous example you can see two component definitions: Component1 and Component2.


Components in ASCoDT can be written in three different languages C++,Fortran and Java. Additionally those components can run locally in the same process space as ASCoDT or remotely. To distinguish between the different cases we introduced the target keyword in our sidl dialect. The following targets are currently implemented in ASCoDT:

  • java_local : for components written in java, which should run in the same process space as ASCoDT.
  • cxx_local : for components written in C++, which should run in the same process space as ASCoDT
  • fortran_local : tbd
  • java_remotef : for components written in java, which should run remotely. Communication is done trough a file protocol.
  • cxx_remotef : for components written in C++, which should run remotely. Communication is done trough a file protocol.
  • fortran_remotef : tbd
  • java_remotes : for components written in java, which should run remotely. Communication is done trough sockets.
  • cxx_remotes : for components written in C++, which should run remotely. Communication is done trough sockets.
  • fortran_remotes : tbd


The uses and provide relationships are realised though a virtual entities called ports. A port is described through an interface. This principal corresponds to the design-by-contract paradigm from software engineering, where the developers need to define formal, verifiable interfaces for the different software entities. Interaction between the components can happen only through the defined interfaces, when curtain pre- and postconditions are fulfilled.

Uses and provides ports

The uses relationship is mapped to association from UML. Lets consider the specification from our example with Component1 and Component2. We can model the uses-relations as directed associations in UML between Componen1 and Component2. In the actual source code we will have a member variable erntryPoints in the Component1 class with type Interface2. In sidl we express this with the keywords uses as <alias>. The provides relationship corresponds to simple interface implementation from a given class. In sidl it is denoted with the implements-all keyword


In the ASCoDT workbench the two components are represented as boxes. There is direct connection between component name class name. Additionally to the class name you can see the the object id of the component. The syntax here resembles the syntax from UML (<alias>:<type>). The uses ports are located on the right side of the component (a box with red border) and the provide ports are on the left side (marked with green border). The user can see the name of the interface of the given port by mouser over.