Session summary : Session on Component engineering
Tapio Tallgren, Nokia Research Center
The final session in the workshop was on component engineering. Component engineering allows a company to produce different products by modifying and combining pre-existing components. However, components have not yet become widely used, partly because reusable components are always more difficult and expensive to develop than stand-alone parts. Using existing components in products can also be difficult. Components must be as powerful as possible while assuming about their environment as little as possible.
The first talk was by Neno Medvidovic (University of California, Irvine). He described the experiences he has had with building a video game using the C2 architectural style. The C2 architectural style consists of a network of concurrent components linked by connectors that route messages between the components. Two components can only be connected via a connector while two connectors can be directly connected. Two components connected by a connector are always in an asymmetric relationship with each other, with one higher than the other. The relation ‘higher’ is also acyclic. Components pass requests to other components above them and receive requests from components below them. Similarly, they send notifications downwards and receive notifications from above. All communication is message-based and the system takes care of delivering the messages. There may be extraneous messages that no component receives.
The system is substrate independent: components are only aware of the components above them. The highermost level is application code, and the lowest is the physical level and eventually the user. Thus the application is not aware of the physical details.
KLAX is a falling-tile game not unlike Tetris. The player has a hard real-time requirement to arrange dropped tiles or risk losing a life. The whole implementation is approximately 13000 lines of commented C++ code. The architecture has 16 communicating components. A keystroke generates generally between 10 and 30 messages, and a clock tick from 3 to 20.
This style allowed to replace a component in the original architecture by one which uses an off-the-shelf constraint solver. The main result was that this was possible without too much effort. After this, it was possible to experiment with different combinations of what components to select. The variant components differed in implementation and in the notifications they handled.
In conclusion, the C2 architecture was flexible enough so that using an external component was possible. The style made few assumptions about the architecture of its components.
In the second talk, Johannes Weidl (Technical University of Vienna) advocated implementing state machines at as high a level of abstraction as possible. He considered as alternatives Alexander Ran’s state classes and a table-based approach. State classes represent the different states of an object by different classes. The state is an instance of a suitable object that implements events by different methods. State classes can also inherit from other state classes.
When using state classes, state transitions are hard-coded in implementation. A table-based approach would decouple the states, events and transitions. The actions and transitions corresponding to an event in a certain state are stored in a table. Thus a table-based approach is in some sense more generic that state classes. It is also more flexible, as data is easier to change than code.
Finally, Stephen Crane (Imperial College) presented an abstract framework for distributed interaction. Such a framework must first of all support both first-party and third-party. In first-party binding, the client finds the location of the service provider. This is the usual way. In third-party binding, some third party sets up the binding. There must also be support for varying quality of service, such as reliable delivery and best effort. Lastly, the framework must allow for different selection criteria: checking for new messages can be either blocking or non-blocking, and the client can either wait for a single response, a responses from any of multiple sources, or responses from all of a number of sources.
Distributed programming environments have commonly restricted programmers to a single way of expressing interactions between program components. The framework was general enough to model both client/server and remote procedure calls.