"The process is more important than the result"

Metalevel programming

CellKeeper, a cellular network manager

S3 Group Report


The Problem --- The Group --- The Experience --- The Process --- The Design

The Problem

We tackled the Cellular Network --- Metalevel Programming problem. The problem had been kindly prepared by Peter Kriens from aQute.

The Group

The following bunch of people worked on this together:

In the classic DesignLab terms, this group was

The Experience

Positive:

Negative:

The Process

Two thirds of the morning passed by with discussing the deliverables, methodology issues and finding out what the actual problem was. Also, the nomenclature was clarified. The general impression was that this period was not optimally productive and could have been streamlined. On the other hand, we learnt a lot about the problem domain and we all felt very familiar with the issues afterwards. Everybody was comfortable in the discussions.

Intentionally, not all requirements for the CellKeeper where captured in the use-cases. Once we had realised it, this did not present any problem. Wherever necessary, requirements where simply escalated into use-cases on the fly.

Although everybody had some - quite clear - ideas in his head, we were reluctant to pin-point the key elements in diagrams on the flip-chart. Only scarcely, participating patterns were named (Proxy, etc.). In retrospect, this was considered a mistake - we should have moved to concrete diagrams much earlier.

At some point the impression that we just had to start somewhere instead of trying to figure out what the optimal formal approach would be, became dominant. To cope with the overwhelming number of aspects of the problem it was agreed to make some simplifying assumptions first and work from there. This resulted in the following strategy being used:

  1. pin-point the class hierarchy(ies), including highest-level classes only; assume that any new hardware type or software release for a base station controller results in a coding effort, i.e. there is no meta language to re-configure the system
  2. use a meta language to drive the introduction of new classes to model new hardware types or software releases
  3. identify new super-classes to allow for more flexibility, e.g. a super-class of the class modelling the base station controller

After this had been settled, the design phase proper started towards the end of the morning. The discussions became very efficient and deviated rarely from the main path. We all concentrated on what was feasible for the day.

Comparing this unprepared group to the prepared group working on the same problem lead to an amazing result: They had not advanced further than us. While we were exploring the problem domain together and defining our standards, they had spent their time trying to align the various complete design approaches they had brought with them.

The Design

During the design phase, the following key aspects of the problem emerged and were captured in a decision log:

  1. maximum flexibility is necessary; the target is a system to built a system to manage a cellular network
  2. the concept of a cell is stable over time
  3. the base station controller concept may be replaced by a complety different mechanism, which has not even been thought of today
  4. one has to differentiate between the physical representation and implementation of a cell and its logical representation
  5. no new code should be written for new cell types (logical level); it is acceptable to write new code for classes modelling new cell implementations (physical level)
  6. not each property on the cell side has a one-to-one correspondance on the hardware side; implementing a given cell feature might require the use of several hardware features; in particular, properties no longer supported have to be emulated to assure backwards compatability
  7. commands must be
    • bundle-able
    • schedule-able
    • revertable
    • atomic
  8. constraints can refer to
    • one cell
    • one cell and its neighbours
    • more cells
  9. adding new constraints (attached to cell types) should be easy

This gave rise to the design of a (white) framework.

Some highlights:

The human actors in this scenario are the "Operator" (who tunes and splits Cells and changes the CellType) of a particular Cell and the "Cell Type Incorporator" (who adds new CellTypes). A further actor is the cellular network itself.

The Base Station Controller vendors could support the CellKeeper application by providing new software releases in shared libraries, so that new features could just be plugged in.


The Problem --- The Group --- The Experience --- The Process --- The Design