Copyright 1995-2001 by Bytesmiths. All rights reserved.

Please patronize sponsors of this page!

Bytesmiths no longer is involved in software consulting. Maintenance of this web site is currently subsidised by unrelated business activities. Please pass the word to other interested folks, so I can continue to host this page!

• Bytesmiths Editions -- large, archival, fine-art photography on unusual materials
• Bytesmiths Press -- artists' services: web design/hosting, jury slides, giclee reproductions, opening announcements, brochures, etc.
• Crafted By Carol -- handcrafted jewelry and beadwork
• All in the Memory -- bookkeeping services
• Dymond Graphics -- note cards, pet/people photography
• Village of Willamette Arts Festival -- annual visual/performing arts festival, September 23/24, 2001

Your site could be listed here, for as little as $12 per month! Go to Bytesmiths Press for details.

"The process is more important than the result"

Metalevel programming

CellKeeper, a cellular network manager

S3 Group Report

Before reading on, you might want to find out what the DesignLab is all about.

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:

• Bill Foote
• Torsten Layda (Recorder)
• Robert Pfeiffer
• Shaun Smith
• Ernst Siepmann (Moderator)

In the classic DesignLab terms, this group was

• a full-day group
• an unprepared group
• a Sunday group
• called S3.

The Experience

Positive:

• We made substantial progress, and went further than we expected
• We have been able to use use-cases, class diagrams and patterns to communicate
• We learnt a lot about cellular networks
• In only one day, we uncovered important basic principles

Negative:

• We did not produce enough diagrams and did not capture enough decisions with them
• Time spent defining deliverables in the morning took away from design time
• We wasted time, in particular in the morning, with unproductive disputes over details, e.g. whether or not to introduce another use-case
• Time constraints compromised progress

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:

• 1 => There are many parallel, shallow inheritance trees.
• 2, 4, 5 => There is one Cell class, each instance being of a particular CellType (Meta-Type).
• CellType can become a Factory of cells.
• CellTypes are defined by a list of PropertyDescriptions and a list of Contraints. They are shared among instances of Cells.
• Enquiries on frequency, location etc. are always forwarded to the relevant PropertyDescription. No properties are directly stored on the cell, since although it is obvious that frequency is a property of all cells, for other properties this is hard and errorprone to decide.
• 8 => There is a hierachy of Constraints.
• CellTypes can be defined through a meta language. They change, e.g., with a new software release for the base station controller.
• The type of a PropertyDescription is determined by the instance of PropertyValue associated with it as default value.
• The number N of PropertyValues associated with a particular Cell has to match the number of PropertyDesciptions associated with the relevant CellType.
• 3, 4, 5 => CellImplementors are Proxies for a real piece of hardware. They know about the implementation details like the communication protocol, but, e.g., nothing about neighbours. They know how to optimise() Commands and how to get them to the hardware (C-lib, Command Line Interface). They change if a new base station controller type is deployed.
• With the CellTypes also the CellImplementors are shared among cells. This is possible, since all cell specific information, like the location() and the freq() are stored on the Cell as PropertyValues.
• 7 => Cells communicate with their CellImplementor through Commands.
• Commands are Composites and can be bundled to Plans. Memento can be used to support undoing.
• The interface to the operator is based on the Cells, the PropertyDescriptions and the possible Commands.

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.