From the Mist

The article describes the use of a combination of simulation and knowledge system techniques for an ecological simulation application. The purpose of the project was ultimately to provide an environmental monitor that could make statements on pollution events from data gathered from insects, esp. bees, since they are so very sensitive to environmental disturbances.

This article was written as a research paper for this project on the Faculty of Management, University of Groningen, The Netherlands. The original paper was written on a Macintosh IIfx using Aldus Pagemaker, Aldus Paint and possibly some other obsolete software which resulted in some digital archeology in order to restore the article. But is was fun doing so!

Note that there was never a final version of this specific paper. It should be considered a work-in-progress, which explains several sections that are not completely fleshed out or absent.

Copyright © 1991 by Ap Rutges & Rob Vens

Introduction

Introduction to the project

Problem definition

Short definition:

The design and development of a computer simulation and animation of an apiary, which is realistic enough to produce relevant information to deal with three major goals in beekeeping:

1. Swarming prevention.

2. Prevention or treatment of bee diseases, especially the Varroa mite, which imposes a serious threat to beekeeping in the current decade’s.

3. Maximisation of yield, i.e. honey, pollen, royal jelly, wax, propolis.

This definition is perhaps too concise to be useful for non-experts in the area. If you consider yourself such a non-expert reader, please read the section on … first.

Project objectives definition

From the onset of the project it was clear that several objectives could be formulated:

1. Operationalising of expert knowledge in an area of agriculture, in this case beekeeping.
2. Investigating computer simulations as decision support systems, especially in the area of agricultural management.
3. Investigating the use of a combination of computer simulations and knowledge bases for decision support, and developing models to implement this combination.
4. Investigating the power of object-oriented analysis, design, and object-oriented programming languages for these problem-areas, especially regarding change management (adaptability to changes in requirements).
5. Producing a consistent report on the program-development that can be used as:
   1. A general guideline for using these tools in similar problem situations.
   2. A tutorial example of object-oriented (i.e. Smalltalk) programming.
6. Investigating the use of computer simulations as a learning aid in (in this case) beekeeper educational courses (CASE).
7. Investigating the use of computer simulations as a means for the synthesis of scientifically obtained data (statistics etc.).
8. Investigating the use of computer simulation to test and verify scientifically obtained models of the behaviour of complex systems or organisms (in this case populations of bees (“hives”, or diseases like the Varroa mite).

Project development strategy

A global time-planning

The project has started on 25 march 1990.

To obtain a global time-table for the development of this project the following stages are recognised:

1990
25 March – 25 April	Exploring the programming environment
25 April – 25 May	Simulations
25 May – 25 June	Analysis and knowledge acquisition
25 June – 25 July	Building a first prototype
25 July – 25 August	Adding a knowledge base
25 August – 25 September	Delivery of a first product
25 September – 31 December	Version Development
1991

Parts of the program development

The development of this program was, and to a certain extent, should be, an iterative process, in which the different phases constantly returned. Traditionally the following phases are distinguished:

Analysis (Object Oriented Analysis)

In the analysis part of the program development, parallel to knowledge-acquisition in the area of the project, in this case beekeeping, emphasis is on modelling, identifying objects and problem space structuring.

Design (Object Oriented Design)

a. Implementation design

This includes the design of the implementation objects in classes, modelling the interaction of these classes, modelling abstractions of objects modelled in the analysis phase etc.

b. User interface design.

This part is an iterative process of designing windows, images, mouse handling and menu”s, testing these designs on the user (prototyping), and incorporating the suggested add-ons and refinements in the design.

Code-writing (Object Oriented Programming)

This can be differentiated in two parts:

• development implementation code: this is code generated to implement prototypes, for incremental program development, for tutorial examples etc.
• release implementation code: this is code generated to implement a final model of the program, when framework and interface design is considered sophisticated enough for a release implementation.

During the development of this project it was considered necessary to work on these three parts simultaneously, so that the report would satisfy the objectives as formulated. Was the main objective the production of a working simulation, the sequence: modelling-interface design-implementation would probably be more strictly adhered to.

Introduction to this report

Purpose of this report

The purpose of this report is to illustrate the progressive development of a program in an object-oriented programming language like Smalltalk and a strategy for this development that utilises some of the available tools to approach a complex problem with an object-oriented programming language in general.
In object-oriented languages a modular development is more or less automatically generated. When the developer follows the path of careful documenting and step-by-step incorporating his analysis of the problem in the program that he is writing, he can benefit of several characteristics of object-oriented languages:

1. The next step in the program development follows naturally from the previous steps.
2. The steps in the program development are easily retrieved and when necessary corrected in a later phase.
3. The development of the program as a whole is easy to be explained to outsiders.
4. The program is easily modified or changed, also in the implementation phase.

For this project another aspect was important: the educational value. The purpose of this report is also to create an accompanying document that can be used to understand the way the program is planned, developed and written, so that non-Smalltalk programmers can get sufficient insights in these aspects, and in effect the report can be used as a Smalltalk tutorial as well.

This was an aspect equally important for the beekeeper. There is an active beekeeper-association (Bijenvereniging) in the Netherlands, with departments all over the country, mostly amateurs. The program and perhaps the accompanying book should be not only accessible to them but should also be useful in beekeeping courses.

In short, the report is meant as:

• project progress report
• project documentation
• Smalltalk tutorial
• an example of object-oriented analysis

Hardware requirements

The first version of the program was written on an Apple Macintosh IIcx™ computer in Objectworks for Smalltalk-80™ Version 2.5. This machine had 8 MBytes of main memory available. Later versions were developed on a DECStation 3100 (with 16 MBytes of memory), and ported to Release 4 for Objectworks/Smalltalk®. This means that portability to other operating environments is possible (MS-DOS, UNIX) because Objectworks can run on a wide scale of machines. Hardware requirements for the simulation program are a minimum of 8 MByte of RAM. Software requirements are a host window environment (XWindows, SUNViews, MS-Windows etc).

Also a version of the program is planned in Smalltalk/V to run on smaller computers. This involves a MS-DOS version as well as one for the Mac. In this case a minimum of 3.5 MByte RAM will do, and in fact this version will probably be the one that is going to be presented to the Bijenvereniging.

Typographical conventions

This report follows certain typographical conventions:

1. Menu-options and names of methods :12-point bold Helvetica.
2. Smalltalk names, expressions and source-code: 12-point Helvetica.
3. Names and contents of files and extern commands: 12 point Courier.
4. Names of objects and instance variables: 12-point italic Helvetica.
5. Body text is in 12 point Times.

The program is developed incrementally and iteratively, leaving room for the intuitive approach in many cases. This can be seen in the subsequent stages, which are numbered not as a version number, but an increment number. For example Hive1 is the first stage, which contains classes that are the same model objects (i.e. Hive) but this object is further extended in Hive2 etc.

Object-oriented analysis

Object-oriented analysis is primarily concerned with identifying the objects and the mapping of the interactions between those objects. For this it is clearly important to investigate closely the problem domain.

It is clear that in a relatively complex field as beekeeping, the understanding of the problem domain by the analyst cannot be complete. This is a common problem though, and one of the supposed advantages of the object-oriented approach is that this mapping is easier because the semantics of the analyst more closely follows the semantics of the problem domain expert. In other words: the analyst and the expert use the same language.

The first step in the familiarising of the analyst with the problem domain is in reading relevant material. This material is listed at the end of this report in the bibliography under the heading: Object-oriented Analysis and Design.

Also listed is material relevant in the methodology used in the analysis and design. This is done under the heading: The Beehive.

Following guidelines found in [Coad and Yourdon, 1990] the analysis phase was organised in five parts:

1. Identifying objects
2. Identifying structure
3. Identifying subjects
4. Defining attributes
5. Defining services

These phases are more or less iteratively followed.
For a graphical representation of objects, attributes and services (selector names),the following illustration can be examined:

The top part of the card shows the Object’s name (=class), the middle part the object’s attributes or instance variables, and the bottom part the selector service names that are recognised by the object. These are the identifiers of the method bodies (compiled methods) that do the real work. This will be explained further in the next section.

Identifying objects

Object-oriented analysis is the direct mapping of the problem domain to a model

Problem statement

The Beehive Simulation simulates the keeping of one or more hives. We simulate a small apiary with a number of hives. To identify the objects in this apiary we must first list the objects that are concretely present.. Structure is in this phase not important, what matters is the identification of objects. From an early work of Booch⁰ we first try to identify candidate objects by underlining nouns.

A concise description of an Apiary

An apiary consists of hives. Hives consist of supers placed on top of each other, and in the supers a number of frames can be found. In each hive is a population of bees, consisting of one or sometimes more queens, a number of drones (depending on the season), a number of workers in various stages of development from just emerging from the cells to experienced foraging bees, and the frames are filled with brood in different stages of development, and food like honey and pollen.
Also present in the hives are sometimes mites (Varroa), a different population, with male and female mites in different development stages.
The supers in a hive can be separated from each other by an excluder, or a separator.
The apiarist plays a role in the simulation, although he is not a part of the system but operates on the apiary through the user interface. He or she gathers information on the development of the hives, manages swarms, inspects the hives and keeps statistics on the hives, and in general utilises his knowledge to obtain certain goals.
The bees develop as a living entity through the year. Food is gathered by the foraging bees. The quantity of food is dependent upon the weather (temperature, sunshine) and the nectar flow of food plants (which in turn is also dependent upon the weather).

Observations

From the text box above we can summarise as a first list of candidate objects:

• Systems
  • Apiary
  • Hive
  • Super
  • Frame
  • SeparatorExcluder
  • Externals (temperature, rain and sunshine, nectar flow)
• Events remembered
  • Statistics
• Role played
  • Queen
  • Worker
  • Drone
  • Varroa
  • Apiarist

Identifying structure

The first step in acquiring knowledge is identifying structure in a primal, unstructured world.
The next step is leaving structure behind.

After having familiarised oneself with the problem domain, it is necessary to make an attempt in recognising structure. This is (as most phases in object-oriented analysis and design) an iterative process: structure is refined, changed, and further refined as the process of domain mapping continues. According to classification theories there are three main approaches in identifying structure: differentiation of objects and their attributes, classification structure and assembly structure: object-attributes relations, IS-A relations, and PART-OF relations.

Classification structure

The classification structure followed more or less from the factors that have to be taken into account when dealing with a real hive. The subclassing of objects in the simulation was relatively easy in the sense that most objects stood so much apart in their behaviour that ordering them into separate classes seemed appropriate.

In modelling the static components of the Apiary, we encountered several times the need to further extend the class hierarchy, because refinements in abstraction made this necessary (and possible!). For example, the superclass-chain Container-PopulationContainer was added to the structure in a later phase of the design. This abstraction makes future reuse of this hierarchy possible because the general assembly structure is likely to be encountered again. This is an example of investing in the future by creating reusable code. With this in mind, the hierarchy chain was designed as general as possible.

In an even later phase the class ApiaryContainer was inserted into the hierarchy, because we realised the necessity of abstraction for the behaviour of a container in a simulation (with special care that must be taken to insure proper removal of obsolete simulation objects). This class takes care of this aspect, as well as providing generalised methods to count the number of dynamic objects.

The ApiaryBarn is a special object. It functions as a keeper for obsolete simulation objects, that as yet must be kept for possible future use (i.e. revival).

The classification of the dynamic components of the simulation program, i.e. the Simulation objects , was more complex. The main actors in the game are of course the bees. These are easily separated in Drones (the male bees), Workers (the sterile female bees) and Queens (the female fertile bee, of which usually one per hive is present). In the case of the Queen and the Workers specific different life-stages can be defined. The implementation of how to schedule the specific tasks for these different life-stages (which can be very different indeed!) makes an intelligent use of indirect message-passing , which is possible in Smalltalk. The objects remain the same, but they actively determine their present status by sending messages to themselves, and subsequently schedule their tasks. One could say that these objects know how to behave.

So we have a superclass Bees to group the bees in, as a subclass of BeehiveSimulationObject, which was designed to separate a few characteristics of most participants in the simulation, namely the fact that they are contained in a container , that they are distinguished in cohorts , and that they can be said to be conceived at a specific date (i.e. layed by the Queen as an egg, or in the case of the Varroa-mite, layed as an egg by the mother-mite).

There are other objects participating in the simulation as active components. These are mainly for tracing purposes. But some of these classes (=objects …) are to model the dynamic interaction of the simulation actors with their surroundings. They are grouped together under the abstract superclass Externals. Statistical knowledge about external factors such as weather influences is present in these classes, and they can be used to do simulation runs for different simulated environments, for example the tropics.

Assembly structure

An apiary consists of hives, a hive consists of supers, which consist of frames. These composition-objects are represented as instances of their own classes, and appear as instance variables of the objects they are a part of. For example an Apiary consists of Hives and a barn. These appear in the instance variable subContainers (for the Hives) and barn (for the barn). Since this assembly structure can be generalised for most apiary components, it was separately implemented in a superclass: Container. This superclass intends to factorize common behaviour of objects that form an assembly structure – not just the structure as we encounter it in an Apiary, but many more assembly structures like buildings, factories, machines etc.

Identifying subjects

This chapter needs revision. For now I list a few of the subjects under consideration for the project:

• The Apiary system – the static model
• Discrete Event Simulation – the dynamic model
• Statistical analysis – the mathematical model
• Knowledge base – the rule model

Defining attributes

In order to properly define attributes¹ of instances of the defined classes, it is necessary to describe objects as completely as possible by the various attributes that can be assigned to them. We have identified the objects by their names, but of course in reality they are described by their names , their attributes and their behaviour . The attributes of an object are those properties of an object that describe its state as fully as possible.

The questions to ask are: which characteristics can be identified to describe the state of an object, which events must the object remember?

The following tables show the names of the attributes, the class to which the instances belong (i.e. their type), and a short description of the attribute.

The type description follows a more or less rigid syntax. It gives the class to which the values of the instance variables belong, or the classes if there can be more (which is often the case). The character | separates possibilities. It is the equivalent to the OR-statement.

System classes:

(omitted source code listing)

SimulationObject classes

(omitted source code listing)

Defining services

After attributes are assigned, the services to reach the created objects are to be defined. From the description of the objects by assigning attributes a reasonable workable picture of objects is obtained. Now through adding services the behaviour of objects is described. The behaviour of each object must be analysed as thoroughly as possible, so that a complete message dictionary is built. This is the message dictionary that applies to the model, that is those messages that are relevant in the analysis phase and not those methods relating to the computer implementation (such as initialize etc.)

What follows is the complete services definition for all system-classes and simulation-object classes.

(omitted source code listing)

User-interface design

Interface requirements

The different groups of intended users require different specifications of the interface. It is therefore that we differentiated groups of interface components according to the different groups, an approach we have given the name Janus-interface .

Primary requirements

These are user interface requirements on the first level of the interface. This level includes the first sessions with the program for everyone, and the interface required for beekeeping students using the program as a teaching instrument. It provides all basic manipulations with the beehives in the apiary according to various beekeeping methods, and a representation of the apiary that closely resembles what a beekeeper can see in his apiary.

• a view that shows the current state of the apiary: hives and supers as they would look to an observer in a real apiary
• a view that shows the system state in more detail: excluders, frames (i.e. views that zoom in to a detailed part of the apiary).
• a view that informs about the progress of the simulation run (a calendar)
• a view that informs about the external influences such as temperature, nectar flow
• icons and menu-buttons to provide the user with the means to add supers, frames, excluders to the apiary (apiary manipulations)
• menu”s to access the hives on various levels
• views to inform about simple statistical information gathered during the simulation run such as quantities of resources, harvested honey etc.

Secondary requirements

These requirements are for the more sophisticated requirements of expert users. For this group several extra features are listed:

• simulations runs that follow a script (or Log File)
• saving simulation runs in scripts
• fitting statistical input with simulation output
• statistical analysis according to parameters specified by the user
• views to set stochastic parameters: entering fixed seed-numbers for the probability distributions, ability to switch the stochastic parameters off and on, etc.

Prototyping

During the first months of the project several window designs were prototyped in order to get a feel about how the interface should be. The first of these windows where designed using standard drawing software, but the graphical power of Smalltalk was such that interface prototyping was implemented in Smalltalk in an early phase. These windows had no functionality (or almost none) but provided for designing drawing algorithms in Smalltalk, which could be used later in the more extended windows.

Prototyping was not done with (potential) users specifying their wishes. This can be a shortcoming in the future.

Implementation

Implementation of the model was relatively straightforward. The essential framework of the program consisted of initially ”empty” tasks for the various dynamic components (see 3.2.1: Classification structure). Because the emphasis was on the framework structure of an Apiary and the hives in it, no time was lost on implementing complex behaviour-algorithms for the dynamic components of the simulation.

Simulation analysis and design

This is an important phase in the developments because here all presuppositions should be declared and accessible for future change. There are many such presuppositions and probably some of them will always remain unverified because of insufficient information.

For now a few are listed here:

• age of bees: mean and standard deviation, also: influences upon the deviation from external sources such as time of year, average temperature, workload etc.
• mortality rate among bees in the various development stages from brood to flying bee
• food consumption of bees in their different development stages
• food gathering of flying bees: rate of number of bees to nectar flow, influence of health of hive, manipulations done, swarming inclination.
• influences from external factors on the queen”s laying activity
• influences from internal factors on the queen”s laying activity
• effects of apiarist manipulations on the hive

These presuppositions are to be centralised in the source codes in the category task language .

Animation

GUI and animations

Chapter never written.

Animations and diagrams for debugging purposes

Chapter never written.

Knowledge base

Since one of the purposes of the project was the integration of expert-systems with simulations, or the integration of model-based computer programs with rule-based computer programs, we naturally were looking for an implementation of an expert-system written in Smalltalk. Fortunately there was such an application available: HUMBLE.² This application was written for the old implementation of the Smalltalk system, so it had to be ported to the new Release 4³. We exploited the port of the system to adapt it to our purpose: the rule-editor was extended and improved, the graphical interface was rewritten.

HUMBLE is an expert system, written in Smalltalk. The language to define the rules differs from the standard Smalltalk syntax, however. This makes it easier for non-Smalltalk programmers to add rules to the rule-base. These rules are then compiled by the HUMBLE RuleCompiler. When the knowledge base is considered operational (and this can be in a very early stage since only a few rules are enough) an interaction can be started. For this a special window is opened. The user asks the system the answer to a specific question, and after that a series of dialog boxes appear that ask the user all kinds of questions the systems thinks are necessary to arrive at a valid conclusion. It offers everything an expert system should offer: a flexible certainty model, backward and forward chaining, an explanation facility, tracing facilities.

Adding a knowledge base

The first knowledge base that was created was based on the MYCIN model.⁴ We wanted a similar knowledge base to diagnose bee diseases. For the first model we did not interview experts, but extracted symptoms from the literature. This added to a knowledge base with 93 rules and able to diagnose 8 bee diseases. The knowledge base was tested by entomologists from the Agricultural University of Wageningen, and no flaws were found. This encouraged us to extend the system further to an advisor of a beekeeper or apiarist. He or she can than consult the system with questions like: what can I do best in the given circumstances to achieve a maximum honey yield, and so on.

Knowledge bases like this one can be added to approach a few problem areas in the problem space. They are not linked to the simulation model, are relatively easy to implement, and have a restricted functionality. They functioned in the course of the project as finger exercises for the following, more ambitious, goal: interacting the knowledge-base with the simulation.

Interacting the knowledge-base with the simulation

To develop a rule-based expert system on its own is a relatively simple endeavour. To link a rule-based expert system with a model-based simulation is quite another matter. Especially if you, as we intended, want to achieve a synergetic effect, namely the complement of the rule-based and the model-based approach.

Let me list the goals we intend to achieve with the combination of these two modelling techniques.

1. Let the expert-system make use of the knowledge available in the simulation model
2. Let the simulation make use of the knowledge available in the knowledge base (or -bases).
3. Let the structure of the knowledge-base be similar to the structure of the simulation model (which, in turn, is expected to be similar to, or closely mapped to, the structure of the real system)

The points 1. and 2. are of course an over-simplification. This is exactly a statement of the problem: how to link these two systems in such a way that each can make use of the specific power of the other?

Steps in the implementation

First model design

In the following chapters a framework is explained on which to develop an object-oriented program. The first steps are defining very simple objects with their attributes, and gradually refining and deepening the design so that the unfolding of the program can easily be understood.

As a starting point we want to implement a very simple Beehive, namely one that shows itself in a view as a simple drawing of a hive, with one or more Supers on top of each other. The first step is designing the model , without thinking of the interface -side of the problem.

We want the number of Supers to be accessible for the user through a simple pop-up menu that offers the user two options to manipulate the hive:

1. add one Super
2. remove one Super

The choosing of one option must have the desired effect in the model (and later in the implementation of course in the view).

As a first step we define the Hive object as an instance of a class that is a subclass of Model, and as having an attribute supers that in the first definitions is defined as an Integer (i.e. to be of type Integer)⁵. We want to implement this very simple object so that it responds to two messages:

To do this we first generate what is called a protocol description. A protocol description is what is generated first, before the actual implementation. The initial class definition, comment, message categories, and messages with comments for the external interface are contained in this protocol description. It must cover the objectives we defined here (i.e. adding and removing supers).

Hive1

Class hierarchy:

• Object
  • Model
    • Hive1

Comment:

I am an abstract hive that contains a number of supers.

Instance variables:

supers the number of supers in the hive 

Hive1 instance protocol

initialize-release

release

Release dependency relationships among all the supers.

withSupers: anInteger

Set the receiver to manage anInteger number of supers.

accessing

addSuper

Add one to the supers.

removeSuper

Subtract one from the supers.

supers

Answer the value of the instance variable supers.

private

supers: anInteger

Change the value of the instance variable supers and inform dependents that the receiver has changed.

There are two methods where we encounter the word dependency. This is an important concept, the implications of which will be further discussed in the next chapter, where we will see the representation of this elementary model in a view, and we can access this hive through a popup-menu. To implement this we make use of an object-oriented design technique for factoring the specification of the underlying information model from the specification for the presentation of that model on the display screen. This technique in Smalltalk is called MVC-design , shorthand for Model-View-Controller.

A basic outline of the MVC-triad

A first hive prototype

To illustrate the principles of MVC-design for those unfamiliar with the concept, we will make a view that gives a simple representation of the hive that we modelled in the previous chapter, and an access to the hive through a popup menu.

We can distinguish the three legs of this design as the model (representing the interactions and behaviour of “real-life” objects), the view (representing what we see on the display screen) and the controller (functioning as the intermediary between the model and the view through actions undertaken by the user on the display screen, through menu”s and so on). We will implement the Hive object we described in the previous chapter. Here is the protocol description for the View and the Controller:

Hive1View

Class Hierarchy:

• Object
  • View
    • Hive1View

comment:

This view accesses a simple beehive representation through a simple graphic that informs about the state of the hive .

Instance variables: none

Class variables:BottomClosedSuper

Hive1View instance protocol

displaying

displayOn: aGraphicsContext

Provide the view with a graphical representation of a beehive.

controller access

defaultControllerClass

Answer the class whose instance will take care of user-input.

updating

update: hiveContents

The view is a dependent of the model. The model informs the view that a change has occurred. Reflect this change in the text in the view.

Hive1View class protocol

instance creation

openOn: aHive

Create a view on aHive and insert it in a window to be scheduled. Open the window.

class initialization

initialize

Initialize the picture dictionary that contains the pictures to be used for representing the a hive in my views.

Hive1Controller

Class Hierarchy:

• Object
  • Controller
    • ControllerWithMenu
      • Hive1Controller

Hive1Controller instance protocol

initialize-release

initialize

Initialize the menu to access the hive.

menu messages

addSuper

Inform the hive that a super has been added.

removeSuper

Inform the hive that a super has been removed.

control defaults

isControlActive

Answer whether the receiver wants control.

The view that is created is a dependent of the model (the Hive). This dependency relationship is declared during the creation of the view in the HiveView class method openOn: aHive, where the model of the view is set to the Hive. Now if we evaluate the expression

Hive1View openOn: (Hive1 new withSupers: 3)

we see the following view appear:

Through its pop-up menu the hive can be accessed and supers added and removed with the view reflecting the changes. This implementation is almost the simplest of simplest⁶. The major part of the code is the implementation of the pictures (implemented in Smalltalk as OpaqueImage) that compose the Hive picture. It is the responsibility of the model to tell the view that it has changed, after a message telling it so has been received from the controller. The view takes appropriate action by recomputing which picture it should display, corresponding to the new state of its model.

Nested objects

Recognising superclass structure in an early phase of the design is a rewarding activity, because factorising object behaviour greatly simplifies the code that will be generated. In this case of the apiary structure we can pinpoint a candidate for super-classing in the assembly structure of the hive.

Adding complexity to the hive

In the overall picture of this design it is clear that an object can have special characteristics, i.e. a hive is characterised by a number of supers. In reality of course a super is not just an attribute of a hive. It is an object in its own right, and should be treated as such. This is what I call a nested object. This relation between objects is one of four basic ways in which objects are related to each other:

1. Composition relationship
   • nested objects – objects are composed of other objects (Assembly structure)
2. Delegation relationship
   • objects reference other objects
3. Subclass relationship
   • inherited behaviour – objects acquire behaviour from other objects (Classification structure)
4. Dependency relationship
   • objects react to certain changes in other objects of which they are a dependent

A hive consists of supers, which in turn consists of frames. And even the frames consist of cells.

The question is how deep nesting is functional. For the moment let’s stop one level deep: the hive is an object that consists of supers. The supers have an instance variable frames, which for the moment will be defined as an Integer, like we did before with supers.

On the surface it seems that we changed a fundamental aspect of the model, but in our implementation very little has to be changed, thanks to the elasticity of the Smalltalk programming language. To treat supers as objects other than Integers (i.e. instances of the class Hive2Super, a class that has to be added), we need to initialise the Hive’s instance variable supers as an empty Array or an OrderedCollection (we did the last). Also we have to think about how to access these supers: do we state a maximum value of supers? do we explicitly state which super we want to remove or where we want to add a new super? These questions force us to think about the actual implementation of the attribute supers : which class of objects lends itself best for the manipulations we defined?

We decided upon an OrderedCollection, so that we could create a hive with a specified number of supers, and could change this number of supers easily: removing any element from the collection and inserting new ones anywhere in the collection. For this functionality an OrderedCollection is best suited.

Another question that arises is the user interface. In the phase of object-oriented analysis we did not model user-interfaces, but in this phase of prototyping this issue becomes more important. Now that we extend the possibilities to manipulate the hive, the interface has to adapt to these extended possibilities. Apart from the main menu in the view we make use of a prompter to ask which super to access for removing and adding. In a later design this use of prompters will have to be replaced by mouse-events (clicking icons and dragging with the cursor). The view will then have to determine the location of the cursor at the moment a menu is asked for (with the middle button of the mouse), relate this location to a specific super, and subsequently act on this super. This will create the necessity for the view to know selections. We will come to this later.

Also the pictures available had to be extended. In the first prototype we only needed pictures of the hive’s bottom and top (which were the same actually), and of a closed super. For this second example we want to be able to open supers, so we need a picture of an opened super, and we want to be able to see the frames inside, so we need a picture of a frame. The displaying algorithm of the view has to determine the exact location for each of the hive components.

The messages that access this instance variable (i.e. supers) must be changed as well, since we are no longer dealing with a simple Integer, but with a collection that must be accessed with messages like at: anObject and add: newObject after: oldObject. As before, these changes add up to only a few lines of extra code in the model class Hive2, but to more extra lines of code in the interface classes Hive2View and Hive2ViewController. The class Super2 had to be added so that the instance variable supers will from now on consist of an OrderedCollection of instances of Super2.

As a rule we can say that most of the work for an implementation will be in the design and implementation of the interface classes.

After completing the implementation code, the following view appears:

A closer approach to reality

Implementing the model design

We will carry this very simple introduction one step further before we start the discussion on the simulation and its implementation. Our next version of the beehive: Hive3, will incorporate the design that was made in the modelling phase of object-oriented analysis.

All basic manipulations with the hive are now possible, and the menu”s and prompters that process user-input are adapted for these extensive manipulating possibilities.
Also the implementation”s error-handling had to be extended, although in the actual implementation most messages will be sent through the user-interface, which will take care of most possible sources of errors.

In this stage we will show the hive in the view with a simple graphical representation that is sufficient to assure us that the implementation of the model satisfies the specifications that we made, and which will be further elaborated upon in the next chapter.

Starting a simulation

A basic simulation

Definition of objectives in this phase

Interface design of this first simulation

In the first stage of the interface design the following windows were implemented, to experiment with the requirements of monitoring the simulation of an apiary.

1. Beehive Simulator Control Window
   This window was intended to be the main control for the simulation.
2. Simulation Statistics Window
   For representation of measured quantities during simulation runs.
3. Apiary Browser
   To access the various components of the hive and obtain numerical data and status reports for these components. This window was intended to be textual in nature.
4. Population Browser
   To access the dynamical components of the hive: the bee population, and obtain textual data concerning the state of each cohort.

In later phases additional windows were developed, such as Pie Chart Views to graphically represent the contents of each hive component, Bar Chart Views, and specialised views for the setting of parameters.

Closer to reality

Chapter never written.

Further refinements

Chapter never written.

Real-time synchronisation

Chapter never written.

Bibliography

Object-oriented Analysis and Design

[Beck, 1989] – Beck and Cunningham: CRC cards

OOPSLA Proceedings 1989

[Booch, 1983] – Booch: Software engineering with ADA

Benjamin Cummings Pub. 1983

[Booch, 1991] – Booch, Grady: Object Oriented Design

The Benjamin/Cummings Publishing Company 1991,

ISBN-0-8053-0091-0

[Coad and Yourdon, 1990] – Coad, Peter & Edward Yourdon: Object-Oriented Analysis

Prentice Hall, 1990, ISBN-0-13-629122-8

[Coad and Yourdon, 1991] – Coad, Peter & Edward Yourdon: Object-Oriented Design

Prentice Hall, 1991, ISBN 0-13-630146-0

[Cox, 1986] – Cox, Brad: Object-Oriented Programming

Addison-Wesley, 1986

[Goldberg, 1990] – Goldberg, Adele: Information models, Views, and Controllers

Dr.Dobb”s Journal, July 1990

[Johnson, 1988] – Johnson and Foote: Rules for reusability

Journal of Object Oriented Programming, Vol1, No2

[Lieberherr, 1989] – Lieberherr & Holland: Law of Demeter

IEEE Software 9/89

[Meyer, 1988] – Meyer, Bertrand: Object-Oriented Software construction

Prentice Hall, 1988

[ParcPlace, 1990] – Smalltalk-80/Objectworks – Tutorial

Palo Alto, 1990

[Shlaer, 1988] – Shlaer & Mellor: Object oriented system analysis

Yourdon Press 1988

[Wasserman, 1990] – Wasserman, et al: Object-oriented System Design

IEEE Computer, March 1990

The Beehive

[BMCJ] – Carel Jansen: Bedrijfsmethode afgestemd op het verkrijgen en invoeren van jonge
leggende koninginnen.

Bijenteelt VBBN – 4 1990

[BMLK] – L.Kroes: Bedrijfsmethoden Hopf, Alexander, Van den Brink

Bijenteelt VBBN – 5 1988

[BMHG] – H. van Gooi: Bedrijfsmethoden – Het separeren

Bijenteelt VBBN – 10 1988

Notes

⁰ Grady Booch: Object-oriented design using ADA

¹ Attributes or instance variables or fields are synonyms

² Humble© Version 2.1 A from Xerox Special Information Systems, Pasadena

³ This latest Smalltalk implementation runs under a window manager provided by the host machine, and offers full color in addidtion to a vastly improved interface class library

⁴ MYCIN is an early rule-based expert system developed by Dr. Edward H. Shortliffe to identify blood infections and determine the proper antibiotic

⁵ Since Smalltalk is not a typed language, the type is not enforced by the Smalltalk compiler. It is only as a reminder for the programmer that the type is mentioned. This is a design rule.

⁶ For a similar example see the article by Adele Goldberg in the July 1990 issue of Dr. Dobb’s Journal: Information Models, Views, and Controllers. A previous version of her example is published by Glenn E. Krasner & Stephen T. Pope: A Cookbook for Using View-Controller User the Model- Interface Paradigm in Smalltalk-80

Addendum

Some (archeological) remarks.

• This article is not edited and kept as originally published. Most articles on this site are evolving and maintained actively.
• The article, as you may have noticed, is not complete. Some chapters were meant to fill-out later, but that never happened because of time constraints.
• Newer versions were produced, using the colour facilities of the new development environment (as mentioned in the footnotes), but no fundamental changes in the functionality were implemented. Our goal was a greatly enhanced environment, to be used as an “environment monitor”, being fed data from sensors in the environment to be used as input for the knowledge system, and to run the simulation to determine possible causes of empiric data (such as pollutions and diseases). This goal mostly stranded because of political problems between involved parties (international universities and beekeeping associations).

Errata

As mentioned above, this article is published in the last version from 1991, and for historical purposes not edited. This chapter will contain some corrections or such if needed.