The University of Warwick Department of Computer Science MSc Computer Science and Applications 2007‐2008 CS907 Dissertation Project Basic Grid
A generic Empirical Modelling Package
and Its Applications
Dissertation Report Supervised by Dr Meurig Beynon Bo Gao 0755311 September 2008 Abstract
This paper is the result of a four month MSc Project which aims to build a generic Empirical Modelling EM Package with the existing tools that is available from the Empirical Modelling Research Group at the University of Warwick. The name given for the product of this project is “Basic Grid” for its generic nature and simple grid presentation. The package of Basic Grid is itself an Empirical Modelling Model and it serves as a standard development toolkit which can be applied to various modelling scenarios. This paper starts with an Introduction of Empirical Modelling together with its principles and tools in Chapter 1, and then explains the necessity of building a standard toolkit model and set out a list of objectives for the project in Chapter 2. Due to the experimental characteristic of Empirical Modelling activities, design and implementation issues are iterated through the process of the project which made it difficult to make a clear cut between design and implementation issues. In Chapter 3 and 4, issues that have been raised for Design and Implementation purposes are discussed. Chapter 5 demonstrates some of the applications that have already been made with different prototypes of the toolkit throughout the project. Conclusions are made in Chapter 6 to answer “to what extend does the project of Basic Grid succeeded in achieving its goals?” and various outcomes of the project. Suggestions of Future Development Directions of the project are made at last in Chapter 7. N.B. due to the experimental style of an EM development, design issues are not strictly included into Chapter 3, but discussed throughout the report. Keywords
If you are thinking of “Empirical Modelling (EM), Grid, tkeden, Definitive Programming, Generic Modelling Toolkit”, then reading this paper should be a useful experience. i Acknowledgements
First and foremost, I would like to express my deepest gratitude to my project supervisor Dr Meurig Beynon for his helpful guidance throughout the course of this project. Without your helps, this project would not have been realised. Thank you also to Dr Steve Russ who has given me so much valuable suggestions on writing up this report. ii Declarations
This thesis is presented in accordance with regulations for the degree of Master of Science in Computer Science and Application at the University of Warwick. It has been composed by the author solely and has not been submitted in any previous application for any degree. All work in this thesis has been undertaken by the author unless otherwise stated. iii Contents
Abstract ....................................................................................................................... i Keywords ..................................................................................................................... i Acknowledgements .................................................................................................... ii Declarations ............................................................................................................... iii Contents .................................................................................................................... iv Table of Figures ......................................................................................................... vi Chapter 1 Introduction 1.1 Empirical Modelling Principles .................................................................................... 1 1.2 Project Background and Initiation ............................................................................... 2 1.3 Empirical Modelling Tools ........................................................................................... 3 Chapter 2 Research 2.1 Modelling approaches under Other Topics ................................................................. 5 2.2 Programming Paradigms ............................................................................................. 7 2.3 Project Objectives ........................................................................................................ 8 Chapter 3 Design 3.1 The Grid ..................................................................................................................... 11 3.2 Package Structure ...................................................................................................... 17 3.3 Prototype I ................................................................................................................. 20 3.4 Prototype II ................................................................................................................ 22 Chapter 4 Implementation 4.1 Naming Convention and Commenting Style ............................................................. 23 4.1 The Grid Core File ...................................................................................................... 25 4.2 Focus Component ...................................................................................................... 26 iv 4.3 Selector Component .................................................................................................. 27 4.4 Controller Component (SCOUT and GEL) .................................................................. 28 4.5 Info Component ......................................................................................................... 29 4.6 Updater Component .................................................................................................. 30 4.7 Clock Component ...................................................................................................... 31 Chapter 5 Demo Applications 5.1 Organic Farm ............................................................................................................. 32 5.2 Crazy Spot .................................................................................................................. 33 5.3 Cherries Drawing ....................................................................................................... 34 5.4 Rush Hour .................................................................................................................. 34 5.5 Basic Grid on Web EDEN ........................................................................................... 34 Chapter 6 Conclusions 6.1 Package Structure ...................................................................................................... 37 6.2 Efficiency.................................................................................................................... 37 6.3 Extensibility ............................................................................................................... 38 6.4 Comparison with Spreadsheet .................................................................................. 39 Chapter 7 Future Extensions 7.1 Suitable Applications ................................................................................................. 40 7.2 Component Developments ....................................................................................... 40 7.3 GEL on Web EDEN ..................................................................................................... 41 Appendix A: .............................................................................................................. 42 Appendix B: .............................................................................................................. 43 Bibliography.............................................................................................................. 44 v Table of Figures
Figure 1 Example of an automaton ........................................................................................... 5 Figure 2 Screen Mesh Effect .................................................................................................... 11 Figure 3 Model of a bicycle from WEB‐EM‐1 .......................................................................... 12 Figure 4 the Room Viewer Model ........................................................................................... 12 Figure 5 multiplied display of the Traffic Light Model ............................................................ 13 Figure 6 the Heapsort Model .................................................................................................. 14 Figure 7 a class of advanced computer models are to be presented by EM models .............. 15 Figure 8 the Sudoku Model's data layers ................................................................................ 15 Figure 9 a Cell on the Grid with its Data underneath it ........................................................... 16 Figure 10 Basic Grid's Package Structure ................................................................................ 17 Figure 11 Screen Layout of Prototype I ................................................................................... 21 Figure 12 Illustration of Prototype II ....................................................................................... 22 Figure 13 A 10*10 grid displayed ............................................................................................ 26 Figure 14 Screenshot of a Focus set on a grid ......................................................................... 27 Figure 15 Screenshot of three cells selected on a grid ............................................................ 27 Figure 16 Controller Component ............................................................................................. 28 Figure 17 Controller Component in GEL .................................................................................. 28 Figure 18 Info Component ....................................................................................................... 29 Figure 19 Updater Component ................................................................................................ 30 Figure 20 Clock Component .................................................................................................... 31 Figure 21 Organic Farm Application ........................................................................................ 32 Figure 22 Cherries Painter Application .................................................................................... 34 Figure 23 Rush Hour Application ............................................................................................. 34 Figure 24 Room model and its meanings ................................................................................ 36 Figure 25 Structure of Basic Grid after Implementation ......................................................... 36 Figure 26 From Grid to Chart ................................................................................................... 38 Figure 27 Chart in the Planimeter Model ................................................................................ 41 Figure 28 Palette Component in the Ants Model .................................................................... 41 vi Chapter 1
Introduction
Empirical Modelling is the name of a research programme at the University of Warwick’s department of Computer Science. The name given to this research was originally set as “Agent‐Oriented Modelling” Beynon, 2006 . When the term “agent‐orientation” became mainstream during 1987‐92, the name “Empirical Modelling” was adopted to this research. “EM has been developed as a new conceptual framework for computing. This conceptual framework is motivated by a shift in emphasis in computer use that has taken place over the fifty years since the first high‐level programming languages were developed.” Beynon, 2007 . “The principles and tools for EM enable model construction and manipulation with a unique emphasis on the role of experience. Model‐building is seen as intimately connected with sense‐making, and models have a high degree of openness encouraging exploration and embellishment.” Harfield, 2007 . 1.1 Empirical Modelling Principles
“Perhaps the most fundamental concept in EM is that of state‐as‐experienced.” King, 2006 “Following traditional interpretations of computational artefacts, states are typically characterised in relation to the behaviour of a computer program, or more generally to a space of potential states. In contrast, in Empirical Modelling the primary semantic relation is the result of personal subjective experience and relates to the association between a computer‐based artefact and that which it is currently about for the modeller.” King, 2006 “Practical experience of model building has suggested that state‐as‐experienced can be usefully construed as comprising the following elements:” King, 2006 observables – entities whose identity is established through experience, whose current state can be reliably captured by experiment; 1 agent – is an observable a family of co‐existing observables that is constructed to be responsible for changes to status of observables; dependency – is a relationship between observables which in the view of a state‐changing agent, expresses how changes to observables are indivisibly linked in change. Beynon, 2006 “The primary activity in the modelling process is the faithful representation of real‐world states in terms of relationships between observations that can be determined by experiment. It is only when we have finally modelled the context for agent action that we introduce agents into the model. Even at this stage, as in a real experimental situation, there is scope to adapt system behaviour through introducing additional factors.” Meurig Beynon, 1994 1.2 Project Background and Initiation
Motivation to this project was found after the author’s experience of making an EM model for the coursework of an introductive taught module of Empirical Modelling at the University of Warwick. The model for the coursework was designed to simulate the various activities on a country farm. At that time, because the author was not so experienced in using the definitive notations, the construction of the model was very time‐consuming and the result model did not satisfy the requirements of EM principles. The same issue was also affecting the work of other students. “EM has been used by over 100 students and many researchers for model‐
building activities,” Harfield, 2007 and some of the resulting models are featured in the EM Project Archive Beynon, 2006 , which contains over 170 models at the time when this report is written. An experimental approach towards the development of models and the reuse of existing model is encouraged by the EM principles. However looking at the list of projects from the archive list, there is a very clear pattern that reuse of a model is normally carried out by the author of the original model. 2 So the idea of building a generic model package as a toolkit for developing new EM models was initiated, the general aim of this toolkit is to make the modelling process easier and more compatible with the EM principles. 1.3 Empirical Modelling Tools
“Tkeden has been the principal Empirical Modelling Tool for a number of years. Its development dates back to 1987 when Edward Yong developed the first version of EDEN, the Evaluator of Definitive Notations. The advent of EDEN enabled the development of a number of definitive notations, the earliest of which communicated with EDEN through UNIX pipelines.” King, 2006 DONALD – a Definitive Notation for 2D Line Drawings. “While the DONALD notation is effective in supporting the development of line drawing models, it does not provide support for interactive interface;” King, 2006 SCOUT – a definitive notation for SCreen layOUT. The notation supports the creation of text, textbox, picture and DONALD windows; GEL – a definitive notation for Graphical Environment Language for EDEN; GEL or SCOUT: Although both SCOUT and GEL Harfield, 2006 are notations for GUI Graphical User Interface construction purposes, their working style are very different. SCOUT emphasises on the precise location of each window it draws and the presentation of each window is adjustable by changing the attributes of the window. Components in GEL provide a much more advanced user interface than SCOUT. Whilst SCOUT windows are limited to a box presentation, GEL has checkbox, radio button, scroll bar and even a scale. The only disappointment from GEL is that the user is not able to precisely adjust the location of each component. Web EDEN – a most recent development which enables the use of EDEN interpreter on the Web. Detailed description can be found in section 5.5. 3 Chapter 2
Research
Started from around 1983 Beynon, 2003 , the Empirical Modelling research programme has been growing up for more than 25 years. It now holds a rich asset consisting of numerous paper, report, talks and models as well as some tailor‐made scripting tools that has been built for its practical experiments. Due to the author’s limited experience of Empirical Modelling, it is hard to make a precise judgement on what has been achieved in the last two or more decades by the research group and what should and should not be the future direction of the research. However, the author argues that the impression EM makes to those who are not experts of this field will largely determines the popularity of this ongoing research, and to a certain extend will have influence over the successfulness of EM. There are two sides to the story of EM, Philosophical Discussions and Practical Experiments. This project emphasises on improving the practical experiences one can have whilst carrying out modelling experiments with EM. In this chapter, we will firstly look at some modelling activities that are being practiced under other topics of computer science, and compare them with what EM does in terms of modelling in section 2.1. We will also raise the issue of EM being a different software paradigm in section 2.2. In section 2.3, we will summarise the issues that have been discussed in the first two sections and then have a discussion over what can be done to make the EM modelling activities more efficient and also to comply better to the EM principles better. Finally, also in section 2.3, we will come back to the purpose of this project and a list of objectives is given as assessment criterion for this project. 4 2.1 Modelling approaches under Other Topics
The Cambridge English Dictionary gives the explanation of “model” to be: “a representation of something, either as a physical object which is usually smaller than the real object, or as a simple description of the object which might be used in calculations”, in computer science, modelling normally means the involvement of building a computer programme which have a set of pre‐set equations to simulate what happens in the real object that it is set to model. Of course we cannot list out all modelling approaches that are currently being used for research under various topics of computer science. However we will have a brief look at some of the modelling approaches and see if there if any similarities or differences to the approach of EM. 2.1.1 Automata Theory In Theoretical Computer Science, the research focus is set on the abstract, logical and mathematical aspects of computing E.Hopcroft, 2007 Linz, 2006 . The most typical modelling activity involved in automata theory is the study of using an automaton to model a machine which takes a finite/infinite list of characters as input and then Figure 1 Example of an automaton according to the next character came into the machine and the built in logic of this automaton decides which state the machine is in. Each node of the abstract machine represents a state that the machine could be in. Take the example from Figure 1 for an instance, the machine has two possible states which are represented by node 1 and node 2. The input goes into the automaton abstract machine from the left of node 1, when the input character is “a” or “c” the state of the machine stays at node 1. A “b” would change the machine’s state to node 2. At node 2, an input of “a” or “c” would take the machine back to node 1, a continuous input of “b” keeps the machine at node 2. So if the input of the machine is “caccabbb” then the output value of this automaton is the state of node 2. 5 2.1.2 Formal Computing Methods One class of computer models is used in the study of Formal Method Butler, 2007 to evaluate the correctness of the operation and output of a written program script e.g. C, Java, etc. . Similarly to EM’s approach, it also uses a set of notations, the Abstract Machine Notation AMN to write these models. The most widely used implementations are the B Method Schneider, 2001 and Z Method. We will use a piece of script with the B Method as an example: MACHINE
Stats(studentMax)
CONSTRAINTS
studentMax : NAT1
SETS
MARK
PROPERTIES
MARK = 0.. 10
VARIABLES
stats
INVARIANT
stats : MARK --> (0.. studentMax)
INITIALISATION
stats := MARK *{0}
OPERATIONS
oo <-- querytot =
oo := SIGMA(nn).(nn:MARK|stat(nn));
tested(nn:MARK) =
PRE stats(nn) < studentMax
THEN stats(nn) := stats(nn) + 1
END;
……
END
In the B notation script above, all fully capitalised identifiers are reserved namespaces for the interpreter of the script. The programmer/modeller’s job is to specify the details on the right of each of those identifiers. Before the “OPERATIONS” keyword is the header information of the model, and preconditions and post‐conditions of operations are described in the main body after the “OPERATION” keyword. 2.1.3 High Performance Computing The research of High Performance Computing HPC aims at shortening the running time of a computer program by parallel the program’s sequential code 6 Laurence T. Yang, 2006 . Models are built to estimate the running time of a paralleled program without running it, thus tell the performance of the algorithm used to parallel the program. Models can be in a form of an executable program, but the simplest performance model can be written in an Excel spreadsheet file. For example, it can be an equation like: Running Time 2* Number of Processor * Communication Time Number of Processor * Calculation Time 2.1.4 Similarities and Differences It is clear to see that although all these topics build models to achieve its research goals including EM which uses models to demonstrate its philosophy principles , EM’s modelling tools are built to accommodate a much broader range of problems. All three of the above model examples can be modelled using the tools provided by EM. In contrast, models from the other three topics are built for use under those topics only. Like the examples shown in section 1.4, models within the EM context normally emphasis on the on‐going observation experience as the outcome of the model, whereas the other topics emphasis on the outcome value solely. The comparison that has been addressed here considers only a few topic with modelling features, however there is much more topics within the scope of Computer Science. The purpose of this comparison is not to put EM above all the other topics, but to give a good impression of the distinctive features of EM. 2.2 Programming Paradigms
“Paradigm is commonly used to refer to a category of entities that share a common characteristic. Numerous authors have examined the concept of a paradigm. Perhaps the foremost user of the word has been Thomas Kuhn, who wrote the seminal book The Structure of Scientific Revolutions.” H.Kaisler, 7 2005 . In his paper Paradigms for Programming Beynon, 1986 Dr Beynon discussed the same issue and “outlined an alternative framework for general purpose programming systems, based upon the author Dr Beynon ’s work on ‘definitive notations’ ” Beynon, 1986 . A programming paradigm defines a style of computer programming. “Procedural” and “Object‐Oriented” are the most commonly known paradigms. EM’s definitive programming style is to be differed from those two, thus holds a distinctive programming paradigm Modelling with Definitive Scripts, MWDS . This distinctiveness of EM programming languages is due to the principles of EM. However, the definitive language and its notations still provides what a common programming language offers, so for an un‐experienced modeller to use EM’s tools, the EM principles are quite easy to be forgotten, so that the outcome model does not fit the EM requirements. The modeller should be encouraged to both follow the instructions of Definitive Programming and not be prohibited from borrowing ideas from other paradigms at the same time. 2.3 Project Objectives
•
To build a model package to work as a toolkit for enabling a faster model developments; •
Structure of the model package much follow closely to the EM principles, and give a clear demonstration of the principles; •
Some demo applications using the model package should be developed to show the benefits of using the toolkit; •
As well as following the rules of Definitive Programming, the package should not be prevented from borrowing useful structures from other programming paradigms; •
The model package should have well documented support and the code should be well commented to read. 8 Chapter 3
Design
When I was asked “What do you think was the most challenging task during the process of your project?” at my presentation, I undoubtedly answered “The design work”. Indeed, Analysis and Design is commonly recognised as the decisive phase of the software engineering lifecycle where you could tell whether the project will be a success or not. Like an infection into the root of a plant, even the tiniest fault from the design blue print will almost certainly have a knock‐on effect to the subsequent stages of the project and eventually devaluate the outcome of the project hugely. A mistake at the implementation stage can normally be corrected, whereas a correction from the earlier design normally means some hard work that’s already been done would be wasted, or sometimes means that the whole project must be restarted from scratch. Being a generic model which is expected to be extended along various directions in the future, by this nature which it holds, Basic Grid puts itself at the start of the lifecycle of all those future model developments. So, to get the design right is not only a crucial task to the development of Basic Grid itself, but also to the extensive developments that’s to follow in the future. Before any design was carried out, a set of objectives was identified as guidance for the design of all aspects of Basic Grid: Ease to understand: The target user group of Basic Grid is not the professionals of EM who knows every single bit of the EM assets like the back of their hand, but those who has only just had a hint of what EM is like, who still think that imaging of a piano keyboard whilst looking at three water jugs is all what an EM people would do, who never used EDEN and presume that DONALD is a notation for modelling a fancy restaurant. To achieve the objective of enabling faster development lifecycles of EM models for those who don’t know much about EM, the know‐what‐it‐is process of Basic Grid should not occupy too much of the 9 developer’s time. Over‐complication is to be avoided; otherwise the use of Basic Grid will be avoided by the developers at the start of their model design. Ease to use: There are currently a number of PhD students doing research within the EM research group at the University of Warwick’s Department of Computer Science, together with the leaders of the group, Dr Beynon and Dr Russ, they forms the expert team of EM which is not of a great size. Even with contact to this source of EM brainpower, I could still feel a lack of technical support during the process of my project. Unlike the commercial programming languages, the documentation and teaching resource of EM’s definitive language and the various notations are very limited. It is of Basic Grid’s primary task to make everything easier for the modeller, not harder. The APIs function/procedure calls, observable names provided by Basic Grid should be straight forward to use, not adding any extra load on top of the existing learning curve of the EM tools. Wide extensibility: Modelling from an EM’s point of view is to do with all kinds of activities one can possibly image, and that is one of the primary principles within the EM philosophy. The architecture of computer limits the possibilities of modelling the various activities in the world, and it is EM’s intension to scale down that limitation by introducing the new programming paradigm that’s based on giving definitions to observables and building dependencies. A grid can represent a wide range of activities, however not everything can be explained with a grid. It is the first thing to bear in mind that the grid must be adjustable in many ways e.g. colour, size, layout, zoom, etc. to accommodate as many scenarios as possible, secondly, when it comes to modelling a problem that’s not the best for a grid to accommodate e.g. line drawings, shape drawings, 3Ds, etc. the grid tools must be able to give way to those who is the best for the job, DONALD for instance, and can be added as an compatible tool to where it is needed. 10 To put the above requirements into practical terms, the model scripts must be compact in length, use easy to remember identifiers, provide useful information for debugging, well‐commented and self‐explanatory, the structure of the Basic Grid package should be open for modification, and has appropriate modularity structure. 3.1 The Grid
Like any creative competitions, the object/topic given to the contenders would have few distinguishable features, a blank paper, a white cube, an unpainted wall, the number 1, the word “love” or even a bottle of pure water to elaborate one’s creativity from. The principle is that if you want a group of people to think of different things from the same object, you should choose an object that has as few pre‐set attributes as possible. Being the core script which all other components of the Basic Grid package and all the future models are going to be built on, we don’t want any distinguishable characteristics to be attached to the grid at its root form. The definition of “grid” from the Cambridge Dictionary says that a grid is “a pattern or structure made from horizontal and vertical lines crossing each other to form squares.” The word “square” might sounds like a big restriction of what you can do with it, what if I want a set of triangles? What about circles? 3.1.1 Issue 1: Graphics Display There are two ways to break this restriction in the design of our grid. First, by zooming in and out on a grid can show different visual patterns. Just like the way a computer screen works. A screen itself is a grid/mesh of points which can be assigned with different colour values. We can model a computer screen by first define a grid with high values for both columns and rows, and then redefine the Figure 2 Screen Mesh Effect
11 width and height of all cells to a small number so that the whole grid represents a screen which is capable of displaying all real life objects. To implement this method, the grid script must provide accessible functionalities which would allow the redefinition of the geometry properties of the grid itself. According to the principles of EM’s philosophy and tools, this is best to be achieved by re‐definable observables or otherwise by providing parameterised procedures to the user. The other way to display various shapes on the grid is by enabling DONALD on the cells which would be defined as SCOUT windows. Almost all of the existing EM models use DONALD when it comes to the need of giving visual presentation of the real life objects. Although a DONALD drawing can hardly be classified as elegant, it does provide enough functionality for data visualisation. Since a SCOUT window can be defined as a display for DONALD drawings, this should not be difficult to implement, the user should be given the choice on the SCOUT window’s “type” attribute. Figure 3 Model of a bicycle from WEB‐EM‐1
3.1.2 Issue 2: When DONALD is the answer An interesting thought would be raised here about the necessity of a SCOUT grid when DONALD drawing alone is capable of representing the complete model. Take the classic “Room Model” Yung, 1989 as an example. The original model was aimed at demonstrating the various dependencies that’s behind a room environment. At that stage, there seemed no need for any SCOUT involvement at all. However at the later extension of the room model, the “Room Viewer Model” Yung, 1991 , a second window is added alongside the original room representation which shows a zoomed‐in view of 12 Figure 4 the Room Viewer Model
the same room. Both of the two windows are defined with SCOUT, together with all the control buttons on the bottom. The comparison between the two views in the second model undoubtedly made the model much more interesting to the users, and also much more information can be extracted from this model. The layout of the room viewer model can be classified as the use of two sets of grid objects, one for the two displays and one for the control buttons. A single DONALD presentation is normally adequate to give the user the impression of what the model is about. However, valuable information is often discovered by comparison of the different states of the same model. Take the “Traffic Flow” model Mendis, 1997 for an instance, the model intends to simulate a traffic management system and has the intension to observe the possible outcomes of different light plans. However with only one simulator of one traffic junction, it is very difficult to tell the difference between different light plans in real time. It is an obvious advantage for the user of the model, if additional SCOUT windows are used to display the same juction with different light plan as parameters. In that way, it is easier to see how and where things start to get different and how the difference develops through time with the multiplied display of the same model. Figure 5 multiplied display of the Traffic Light Model Another example to elaborate this idea of a Grid display of DONALD drawings can be applied to the “Heapsort” model Beynon, 1998 . The model illustrates 13 the complete process of a Heapsort Algorithm by drawing a Heap Tree on the screen. Having a duplication of the same sorting tree can be of litter help for the understanding of the algorithm. However, an inclusion of the illustration of a different sorting algorithm on the same screen, e.g. the Bubblesort model Beynon, 1998 , is certainly a good idea that is worth implementing. Start with the same list to be sorted, one step at a time for both algorithms, see which Figure 6 the Heapsort Model
algorithm get the list sorted first, how the list look like at different stages of the sorting process. Under this approach the user can have a much better understanding of the differences between the various sorting methods and thus understand the advantages and disadvantages of each. So, for line drawing activities, the Grid is no replacement to the DONALD notation, but if the use of Grid is properly applied to the original model, it can largely enhance the experience for the observer of the model, thus add values to the model itself. A challenge is set here if DONALD drawings within adjacent cells are to be coordinated to assemble a bigger picture on the whole grid. A grid of coordinated DONALD cells can be used to model a problem like the airflow on a car’s surface in a wind tunnel. 3.1.2 Issue 3: Possibilities of Coordinated DONALD drawings Follow up with the previous issue about the coordination between SCOUT and DONALD, and look at the existing models from EM’s project archive, it is often the case that separate DONALD drawings are normally not well related, in other words, not much coordination is reflected between the drawings. That in a way limits the scope of EM models. One particular class of advanced computer models e.g., the Computational Fluid Dynamics CFD has been excluded from the EM family. I suggest that with the support of Basic Grid, EM modeller should be able to step into this class of problem using a Grid of Coordinated DONALD drawing. 14 Figure 7 a class of advanced computer models are to be presented by EM models This class of computer model typically involves the observation of the status of a grid of points, and each point on the grid, being influenced by the surrounding environment e.g. flows of air, water , gives a value of direction as the result of the influence concurrently. The Grid should be designed to accommodate this class of problem. That requires not only the ability to define DONALD windows within the grid, but also to store distinguishable data for each cell of the grid. That brings up the next issue. 3.1.2 Issue 4: Store Data for Individual Cells Like the models that have been suggested in the previous section, just the visual presentation is normally not enough to represent a proper model. Take the Sudoku Game Model King, 2006 as an example, visually each cell only contains a digit from 1 to 9, however, there is much more logic than that behind the scene when you build a computer model for it. Which column, row and square does it belong, what digit is in this cell, what is the possible answers to this cell, has this cell been filled, which cell is the user’s focus on, the answers to Figure 8 the Sudoku Model's data layers 15 all this questions are to be stored somewhere in this model, and be related to each particular cell. Before dependencies can be constructed, we must have the data ready. Logics like the position of the cell can be put into the identifier of the cell, a list of possible entries can be calculated with function calls, but attributes like “if the cell has been filled by the user” must be stored somewhere and has an identifier that’s related to its cell. Such problem can be found in many models especially when the grid is used for representing a world. For instance, in the Ant’s Navigation Model Keer, 2005 , each position on the Ant’s world map is assigned with different values which defines the type of object that’s on that location, its colour and amount if it is some food or water. So the design of the Grid should make it flexible for the user to define the data structure behind each cell, at the design stage I would like to illustrate the conceptual organisation of each cell and its data as below: Figure 9 a Cell on the Grid with its Data underneath it
16 3.2 Package Structure
After the discussions over the various issues that’s influential over the design of the Grid’s core file, let’s come back to the first principle that’s been mentioned at the start of section 3.1 which is to make it simple and as pure and generic as it can be. According to that principle, we expect not a lot of colourful functionalities would be provided by the core file. A well structured grid with layers of data storage behind it, a set of observables to define the geometry and visual information of the grid, functions to query and update data to the grid. Any redundancy at this core would be inherited by the subsequent models which will cause either delay in running time or restriction on flexibility for those models. So only the essential of the most essentials would be kept in the core file. As addressed within the dissertation title, Basic Grid is not just about the one core file, but a package of different components that provides various functionalities which can be applied to the grid. With the core file being so purely defined, it requires the use of various components that’s been built around it to full fill the requirements for various functionalities. Figure 10 Basic Grid's Package Structure
17 Like shown in Figure 10, there is a very clear pattern within Basic Grid’s package structure. All of the additional components are built around the core file, with different levels of functionality and complication. The first circle of components is regarded as the administrators’ ring, components from which take control of other components that are to be attached to the core file. The main tasks involve jobs like showing the list of installed components; provide an interface to switch on/off the components that have been attached to the core file; and clear what changes the components have made to the core object. Components in the second circle should provide functionalities to enable the most basic operations that can be applied to the core Grid. Operations like setting the user’s focus on the grid; trace the movement of the mouse; select a group of cells from the grid should be implemented in the scripts of components at this level. It is also to be noted that components at this level should keep itself simple as the core file does, because it is very likely that the later more sophisticated components will need to integrate this low level components into its development. There is no need to start develop a highly sophisticated set of functionalities at this level, because some of the sophistications would just be made redundant when only the simple operation is needed by a higher level component. If a more sophisticated version of it is requested, then the same component can be further developed and put on some higher level for use. On the third ring around the core are the components whose tasks are to query and update the data stored behind every cell like it has been illustrated in Figure 9. This set of components is particularly useful when it comes to debugging a model that’s been build with Basic Grid. Being underneath the cell’s presentation, the data behind the grid presentation are not visible to the user. To check if the model is doing the correct operations on the data, and to find where the data has lost its consistency 18 whilst debugging, these components are the best tools. Components on this ring should allow a concurrent insight into what is going on behind the grid. In terms of operation needs, there is some overlapping between this level and the previous. For example, to raise a query of the data behind one cell, you have to interact with the model so that it knows which cell column index and row index your intension is at. Instead of setting a new set of procedures to realise this operation again, it is much easier to use what the components on the previous level, like the Focus component, already provides. And of course, if the activation of the lower level component is necessary for the operation of this component, this dependency should be informed to the Administrator components on the first ring. On the very outside of Figure 10, I put two classes of components on the same ring which means that component classes that have been built on this level can be independent from each other. There is no particular difference on the level of importance between the component classes at this circle of development. Classes of components can be developed in a direction which is suitable for solving a certain class of problems. The functionalities of the components within the “Run‐time Controller” class are discussed in the Implementation Chapter, and the “Data Visualisation” class is detailed within the Future Direction Chapter. There is certainly more than just two classes of components to be developed on this level, new classes are to be invented when various functionalities are needed for building the model in the future. The key principle discipline of this structure is that the developers should always think of building new components in its simplest form, position the simplest working version of the component in the inside circles, and then gradually add more functionality and features to this simplest form and place the advanced versions towards the outside circles. Under this discipline, all components that have been built around the core are sorted in an order of its level of complication from the centre. Components with similar functionalities 19 are concentrated on a certain angle of radiation coming out of the centre point. This structure naturally organises the components of the package and its future development into a well indexed library of components. It is not only a benefit to the ease of future development but also a good practice of the iterative experimental Russ, 2007 King, 2006 approach of EM. Also to be noted is that the names of the components shown in Figure 10 are provisional regarding the future implementation. 3.3 Prototype I
Due to the experimental natures of an EM development process, this project of building the Basic Grid’s lifecycle is iterative between implementation and design. So it is very difficult to make a clear cut between design and implementation in the description of this project. Two versions of prototype design have been practiced in the development. Both have been used to guide the development works at different stage. The package structure addressed in the previous section holds in both prototypes, the difference between the prototypes is mainly within the organisation of the presentation of individual components. Derived from the idea of building a game model of the organic farm located in Virginia U.S. named Polyface Pollan, 2008 Pollan, 2006 Gumpert, 2007 which I put into practice for the coursework of Empirical Modelling, the user interface of Prototype I is set to be very much alike the classic strategic games e.g. Red Alert, Starcraft, Command and Conquer, etc. , so that the user can buy units of farm animal / crop and locate them onto a grid which represent the map of a farm e.g. river, grass, forest, etc. . This prototype uses one big screen to display all the components that are relevant to the model. The advantage of this prototype is that the user of the model has a shorter learning curve of the interface. The organisation of the screen is set to be very similar to what the user would get in any grid‐manipulating /map‐with‐control application e.g. Excel Spreadsheet, Google map, Board Games, etc. . For the 20 developer of the model, it is easy to preset the organisation of various components to make it suit the particular need of the model so that the user sees exactly what the modeller want him to see. Figure 11 Screen Layout of Prototype I
The biggest disadvantage of this prototype is the limitation it puts on the model’s possible applications. Because the design of this prototype is guided by the Map‐
Manipulation styled scenarios, the design pattern is very much shifted towards this certain type of scenarios. This prototype also suffers from the low flexibility when more components are to be added. It is very easy to get the screen fully loaded with different control units. Also for a developer who is learning to use the Basic Grid package, the circular structure of the package is not very clearly demonstrated by this prototype. The impression one get from the screen is more of a set of independent components instead of the dependent gradual development style recommended by Basic Grid. In brief, this prototype is good for building models which is based on a Map‐
Manipulation background, but limited in the number of future extensions. 21 3.4 Prototype II
This prototype is designed after considering all the disadvantages of the first prototype. A major modification made to the first prototype is the separation of display for individual components. After definition, every component provides a unique identifier for display itself, and then it is up to the runner file to decide whether to display this new component alongside a previously defined component or to open a new screen of display to accommodate the new component. Another major improvement of this prototype comes from the use of the execution function provided by eden. This improvement allows the developer to have control of more parameters at the definition of a new grid, which means the developer can ask for a grid of certain size of column and rows with specific colouring scheme, and manipulate the size and content of individual cell at the run‐time of the model. Details of these functionalities are addressed in the Implementation Chapter. Figure 12 Illustration of Prototype II
22 Chapter 4
Implementation
The definitive language eden and its notations are not difficult to learn, however to write a script which complies with all the EM principles is a huge challenge. My previous knowledge of the other programming languages like C, C
and Java does not help in this matter, and sometimes even makes negative effect during the course of my implementation. Eden and the notations are classified as a group of “Definitive Languages” for its huge difference to other programming languages in principle. Maintaining dependencies with other languages normally involves the use of constantly triggered actions, in eden an “is” is enough. The type of variables is maintained after it is declared in most of the other languages, but in eden the programmer has to take care of that issue themselves. To my experience, eden is a language that you must have faith in it in order to use it. You are most certainly to get some error messages at the first time you execute a new script, and in most cases the error messages don’t provide much information that you need. You just have to keep faith in it, believe that you can fix it, and try to look for bugs from the places that you won’t normally look at if dealing with a piece of Java code. Eden is a language which only the faithful can see its beauty. 4.1 Naming Convention and Commenting Style
Looking at the existing models that have been produced for Empirical Modelling, it seems like a tradition that most scripts are not commented well, and when you try to run a model that interests you, you would normally have to choose a script randomly from the bunch of files that is provided within the model’s package and hope it would work. The modellers of EM seem to have misapplied the freedom hinted by EM’s experimentation style into a careless programming style and 23 forgot the basic disciplines of traditional programming. Same experience was mentioned in Keer’s project report Keer, 2005 . Being a generic toolkit for future developments, scripts in Basic Grid has to demonstrate a strong programming discipline. The presentation of the three key concepts of EM, observable, dependency and agent within a script is very much relied on the names of the variable, procedure and functions. So to have a common naming convention for eden and the notations can be very helpful in terms of locating the various observables and dependencies. Inside the following sections which contain details of the implementation of various components, example will be given to explain how the identifiers are organised. Commenting is also very important to the future extension of the model. Within the package of Basic Script, each component has its own script file and at the start of each script, comment is given for the use of this component: /***********************************
* Basic Grid - Controller component
*
* To attach a controller to a grid:
*
BG_defineController(name, steps);
*
name - string, name of the grid. e.g. "cells"
*
steps - integer, number of time steps to be counted
*
* Outcome as new identifiers defined ($1 - name of grid):
*
integer
$1_currentClockStep, [eden]
$1_totalClockStep, [eden]
*
integer
$1_clock_display, [scout]
*
display
display
$1_clockControl_display, [scout]
*
*
* Bo Gao Sep.08
*
*
version [1.0]
*/
In line of the script, steps of operation is commented: ####
## Contruct a clock control panel with a grid (BG_name_clockControl)
##
BG_CLOCK_CONTROLLIST=["start", "pause", "restart", ……];
execute("BG_defineGrid(\""//BG_name//"_clockControl\", "//……”);
24 4.1 The Grid Core File
File Name: bgrid.main The purpose of this file is simply to define a grid, request the data storages spaces, and some functions to raise query / update the grid’s data. A SCOUT display $1_display $1‐name of grid is defined to display the grid onto a screen. Main Definition Procedure: BG_defineGrid BG_name, ‐ name of the new grid string BG_columns, ‐ number of columns of the grid integer BG_rows, ‐ number of rows of the grid integer BG_winType, ‐ SCOUT window type for the cells TEXT, TEXTBOX, etc. BG_winRelief, ‐ relief property of the SCOUT windows raised, flat, etc. BG_name_DATA_NAME, ‐ list of name for the data fields list of strings BG_name_DATA_TYPE, ‐ list of data type for the data fields los BG_name_DATA_DFVALUE – list of default values for the data fields los ; Some of the new identifier defined not all are listed due to the length of report : After a grid called “cells” is defined with a data list of “data01”, “data02” : cells_c1r5_data01 –data field “data01” at the cell located at column 1, row 5; cells_c4r8_BGCOLOUR –background colour of the cell at column 4, row 8; cells_c4r8_FONT – font property of the cell at column 4, row 8; cells_c4r8_STRING –background colour of the cell at column 4, row 8; cells_c4r8_FGCOLOUR –foreground colour of the cell at column 4, row 8; cells_c5r2_W –width of the cell at column 5, row 2; eden cells_c5r2_X – X value of the NW point of the cell at column 5, row 2; eden cells_c5r2_Y – Y value of the NW point of the cell at column 5, row 2; eden cells_cellWidth – default width of the cells; eden cells_cellMargin – default margin between the cells; eden cells_startX – X value of the NW point of the grid; eden etc. 25 Some of the new functions defined not all are listed due to the length of report : After a grid called “cells” is defined: cells_getDataWithName (c, r, dataname) – return the value of data at column c, row r, under the name of dataname; cells_getDataWithIndex (c, r, dataindex) – return the value of data with index of dataindex, at column c, row r; cells_getDataTypeWithIndex (c, r, dataindex) – returen the type of the data at column c, row r; cells_setDataWithIndex (c, r, dataindex) – update the data of index dataindex, at column c, row r, Figure 13 A 10*10 grid displayed 4.2 Focus Component
File Name: bgrid.focus The Focus component allows the user to set focus on one of the cells on the grid with a click within the cell. Colour of the cell’s background is changed after the 26 focus is set. Main observables defined after the definition of the Focus component is the $1_focusX and $1_focusY $1 – name of the grid this focus is attached to which represents the location of the focus. A function $1_focusSet( rowIndex, columnIndex ) is defined to aid the update of the focus’s location. $1_enableFocus is defined as a request of the Controller Component, so that the Focus can be switched off by setting its value to 0. $1_clearFocus is also defined to work with the Controller, each time its value is redefined, the Focus information on the grid it attaches to will be cleared for once. Figure 14 Screenshot of a Focus set on a grid 4.3 Selector Component
File Name: bgrid.selector The Selector component provides similar functionalities to that of the Focus component. The difference is that this component adds a data field named “selected” to each cell of the grid using which allows multiply‐
selection of cells on the grid. By querying the _selected Figure 15 Screenshot of three cells selected on a grid
data field on a particular cell can help to tell if this cell is within selection. Other two observables are defined, $1_totalSelected, $1_maxSelected to identify the total number of cells selected by the user and the maximum number of cell can be selected by the user using this particular Selector instance. The value of maximum selection is set through parameter that is given at the definition of the Selector instance. The Selector component also has two identifiers to coordinate with the Controller, $1_enableSelector and $1_clearSelector. 27 4.4 Controller Component (SCOUT and GEL)
File Name: bgrid.controller The Controller Component uses the core grid file to define a grid with 2 rows and the number of column is due to the number of components it is to control. The grid defined by this Controller is to be distinguished with the grid that this controller is attached to. The name of this Controller’s grid is $1_controller, and to display the Controller, the run file need to put $1_controller_display onto a screen. Figure 16 Controller Component
Only two parameters are needed for defining a controller instance, the name of the grid to attach the controller and a list of component names of those components that are to be controlled. Button on the first row allows the user to switch on and off the various components. Like in Figure 16, the only component that is switch on is the Info component. A click on the second row will clear the existing modification that the component has made to the grid. File Name: bgrid.controller.gel The same Controller component is also developed with the GEL Harfield, 2006 notation. The “checkbox” component of GEL is quite suitable to represent the on/off status of the components. However at the point of this report being written, I have not figured out how to set the box to be ticked by default, so to use this GEL interpretation, all components have to 28 Figure 17 Controller Component in GEL
be switched off initially. There is no need to call the display of this GEL window, since a GEL window pops onto the screen at definition. Looking at both versions of the Controller Component, the SCOUT version is clearly more organised and was easier to implement since it is based on a Grid that is provided by the core file, a lot of definition work was saved and it cooperates well with the other SCOUT based components, for a Controller, that is essential. The only advantage of the GEL version is that it provides an interface that is friendlier to the user. So for this instance, SCOUT is the winner. 4.5 Info Component
File Name: bgrid.info The Info component serves the grid as a query raiser of the data behind the cells. Like the Focus and Selector components, this component is also controllable by the Controller, so it also has a pair of observables $1_enableInfo and $1_clearInfo. Figure 18 Info Component
The main body of this component is also defined with the Grid’s core file. The first column gives a list of names of data fields that is layered behind the grid. The second column displays the data of the cell which the user has set focus on. The third column follows the location of the user’s mouse instead of the focused cell. The Info Component uses a copy of what the Focus Component has achieved, but still stays independent from the existence of the Focus Component. 29 4.6 Updater Component
File Name: bgrid.updater Improving what the Info Component has for offer, the Updater provides functionalities not only for querying the data layer behind the cells but also to update the value of them. Figure 19 Updater Component
Notable difference to the Info Component is that the data type is added to the back of the data names to aid the input of data. This component is also related to the Focus Component since it needs the coordinates of the cell which the user wants to update. Unlike the Info Component, there is no inclusion of the Focus Component’s code within the Updater script which means it gets the coordinates straight from $1_focusX and $1_focusY. So the operation of this component is totally dependent on the existence of the Focus Component. Due to this nature, there is an additional procedure defined together with the Updater instance which monitors the status of the activation of the Updater instance it belongs to and maintains the dependency between the activation of Updater and Focus. Since the Updater Component is built with two instances of Grid one for each column , the display of this component is a combination of two displays: $1_updatorTrigger_diplay and $1_updator_display. 30 4.7 Clock Component
File Name: bgrid.clock Using the edenclock which is demonstrated in the Revised Jugs Model Beynon, 2008 , this component is built for those models that need to be observed through the course of time. There are two parameters needed to be specified at the Clock’s definition. The first one is for the name of the grid to attach to, second being the number of time steps that’s required for the clock. Figure 20 Clock Component The Clock Component is defined with two instance of the Grid Core. One for illustrating the time steps, the other for the control buttons on the bottom. The control menu allows the user to start, pause and reset the clock, increase and decrease the speed of the clock. The window between the speed controls is used for illustrating the current speed, the colour goes light in green when the speed increases, and goes dark for decrease of speed. There are two observables to use after definition of the Clock Component, $1_currentClockStep and $1_totalClockStep. The first is used to monitor the current progress of the clock and the other is to get the attribute of the total number of steps that is available in this Clock. In Figure 10 the Clock Component sits on the circle on the very outside of the package. That is because its functionalities are not so commonly helpful to all possible model scenarios. Itself and the History Component which is classified to the same class represents a certain class of real‐life problems that is distinguishable to the other classes of components. 31 Chapter 5
Demo Applications
As listed in the Project Objectives, some applications of the Basic Grid model package have been made with different prototypes of the model. The “Farm” and “Crazy Spot” model application were made with the first prototype, the others with Prototype II. Demonstration of 5.1 Organic Farm
The idea of this application is to simulate the management activities of an organic farm. The story comes from the U.S., that a family farm is generating times more of organic farm products than any other industrialised farms Pollan, 2008 . They do it by organising different types of animals and crops in a way that benefits the growth of the other. For instance, they let chickens onto the grass land first to fertilise the soil before crops are planted to increase the production of crops and at the same time got the chicken fed. A “dance” of farm spices is what Pollan call it all in his book Pollan, 2008 . Figure 21 Organic Farm Application
32 In this model, a map of farm is loaded to the main grid. Background colours are changed according to the property of the cell being grass land, river or forest . A list of farm products is shown on the right with prices behind the item icons. The boxes behind the buy/sell price show the total number of the corresponding item on the farm land. A clock component is added to the model to enable the simulation of days passed on the farm. The purpose of this application is to demonstrate the possibility of constructing a world‐management styled model. 5.2 Crazy Spot
The original idea of this application is to build a “Crazy Snake” game model. The model was prepared for the presentation and the time was not enough to enable the full functionalities of a snake, but a spot was used instead. The “start” button enables the game. A green spot appears on the grid moving with speed. List on the right provides the ability to control the movement of the spot. Purpose of this application is to demonstrate some run‐time control ability the model can have visually on the grid. 33 5.3 Cherries Drawing
The purpose of this model is to demonstrate the image display ability of Prototype II. It simply loads a map of image information and displays it on the grid. Because Prototype II uses a more flexible grid definition function, so it is more suitable for displaying purposes. Figure 22 Cherries Painter Application
5.4 Rush Hour
This application is designed to simulate the puzzle game of “Rush Hour”. Rule of the game is to get the red car out through the only exit by moving the other cars on the board only forward or backwards. The model is built for the demonstration of the puzzle game building ability which is one set of Figure 23 Rush Hour Application
models Basic Grid is particularly good at presenting. 5.5 Basic Grid on Web EDEN
Web EDEN is the most recent advancement on the development of EM’s programming tools. Developed with Flex Chafic Kazoun, 2007 , it enables the use of tkeden on the web. No publication has been made at this point regarding the specifications of Web EDEN since the project of Web EDEN has only just finished some of its testing one month before this report is compiled. However with help of Dr Beynon and instructions given by the developer of Web EDEN through email, the author was able to get Basic Grid up and running on Web EDEN. A screen shot of Basic Grid running on Web EDEN is added to Appendix A. 34 Based on the desktop version of EDEN, it is easy to think Web EDEN as just a fancy way to access EDEN. However, much more benefits can be identified from Web EDEN. First of all, the ability to share a session of the same running model on the web enables the interaction between users on the same model. Two users can connect to the same chess model to play against each other; an instance of the Heapsort Beynon, 1998 model can be shared between the instructor and the student to allow distance teaching, the possibilities are endless. Secondly, the EDEN interpreter from Web EDEN is provided from the same server to all users, and that ensures the consistency over the version of EDEN that’s been used by the various users and reduce the chance of a model being unable to execute on a different machine. Web EDEN also broadens the range of applications EM model can be developed for. For instance an application of internet photo album can be developed using the image windows from SCOUT. The author’s experience of using Web EDEN has encountered some minor issues: •
Forwarded domain names within the config.xml file and index.html files and within the “onlineinclude ” function have to be replaced by the actual address of the target/included file; •
The relief property of SCOUT windows does not show any effect under the Web EDEN environment; •
Geometry settings of SCOUT windows under the Web EDEN environment are different to that of the desktop version; •
Notation GEL does not work on Web EDEN. This version of Basic Grid is accessible on: http://weden.iamgaobo.com/model04 35 Chapter 6
Conclusions
On one of the lectures of Introduction of Empirical Modelling, to explain the actual meanings of an EM model, Dr Beynon used an illustration to explain the actual meaning behind the classic Room model Yung, 1989 . The same graph was used many times during the course of the module lectures. It really is a classic illustration of EM’s principles when it comes to modelling activities. Figure 24 Room model and its meanings In addition to Figure 10, after the implementation, the package structure of Basic Grid has become clearer: Figure 25 Structure of Basic Grid after Implementation 36 6.1 Package Structure
There is no intension by the author to copy Dr Beynon’s classic illustration into the illustration of Basic Grid’s structure. However, it was one of the author’s objectives to build the package closely to the principles of Empirical Modelling. As shown in Figure 25, the core script bgrid.main together with the components which provide the most basic functionalities form the core of Basic Grid. Various classes of components with more specific functionalities extend the package towards different directions. The current structure of the Basic Grid Package not only makes the package comply with the EM principles, but more importantly it helps to shape the designs originated from the developers who intend to build models on top of this package. This structure is a good starting point for any related future development. Concepts are introduced from the Object‐Oriented programming paradigm into the definitive programming style. The division between the components and the use of procedure to define an instance of a component are borrowed straight from the object‐oriented programming principles to the construction of this model package. This borrowing was inevitable in order to use the “execute ” function for definition of observables, and because the code generated by this method is still eden codes, it does not compromise the user’s experience whilst experimenting with the model, redefinition of observables and dependencies is still done in the definitive programming manner. In fact, principles like the reuse of model are already being shared between the definitive programming culture and the Object‐Oriented paradigm. 6.2 Efficiency
This package is extremely useful for shortening the development time of grid based models. Modelling of Board Games for example benefits the most from this package. Evidence of improved efficiency can be found in the contrast of 37 Prototype I and Prototype II of the package. Prototype I adopted the same method used in the Sudoku Model King, 2006 to make definition of the grid, the main file stretches to a length of 2149 lines. In contrast, Prototype II adopted the use of “execute ” function for definition of the grid and reduced the number of lines to 352. By calling the definition procedure provided by the core file, definition of the Sudoku game board can now be done in one single line, whereas the original Sudoku model had 6008 lines for the same. It is not just a saving on the number of code lines that has been achieved by Basic Grid, it is also the improved experience of Data Manipulation, and also the organisation of display windows. Before the existence of Basic Grid, every time the developer wants to have a set of data that’s needed to be displayed on the screen, definitions of SCOUT windows has to be made first, variable have to be declared and dependencies between the display and data have to be set manually. With help of Basic Grid, it is now just one procedure call. Evidence of this is the repetitive use of instances of grid defined using the core file within the scripts of added functionalities. The Controller Component, Info Component, Updater Component and the Clock Component all contains an instance of grid defined using the core file. 6.3 Extensibility
Because of the grid nature of this package, it is easy to think that the extensibility of the model is very much limited to scenarios which are also based on a grid presentation. It is true. However, because the second prototype defines a highly adjustable grid, this limitation has been reduced. Like the example shown in Figure 26, a grid with only one row can be turned into a bar‐chart with Figure 26 From Grid to Chart
adjustments on the height of each cell. Limitations can be big when certain class of scenario is to be modelled. Like the issues the author discussed in Chapter 3, the Basic Grid package can only be a 38 supporting tool to an application that’s solely relied on curved line drawing activities which is excelled by the DONALD notation. 6.4 Comparison with Spreadsheet
One class of application is closely related to EM activities, that is the Spreadsheet applications. A typical spreadsheet application deals with observables and dependencies on a grid presentation. That is exactly what Basic Grid does too. However, the Basic Grid applications can have as many layers of data as possible behind the grid presentation. Dependencies can be set between the layers of data to accommodate problems of complex structures. Another advantage of Basic Grid over Spreadsheet is the visual effect it can generate on the presentation of cells. Thanks to SCOUT, there is a lot of displaying attributes can be used from a SCOUT window to send visual messages to the user. Although you can also give background colours, add borders to a spreadsheet cell, but it is not a straight forward task to relate those features to the data layers behind. Also, input method is more machine friendly in EM’s models than in a spreadsheet. You can write a script to draw a pixel picture on the Basic Grid instances, but not on a spreadsheet. You can add components to the Basic Grid like the Clock, but not when you are using a spreadsheet. In summary, the package structure of Basic Grid and the script within the package has been very carefully built closely to the EM principles. The package is a good demonstration of EM principles. Like shown in Figure 25 the package encourages the user to extend and it also provides an good platform to be extended on also improvements on the script’s efficiency is also achieved. 39 Chapter 7
Future Extensions
Due to the nature of this project, its successfulness is largely dependent on its future extensions. 7.1 Suitable Applications
Purpose of this generic model package is to enable a better experience for the developers of EM models so that more inspiring models can be developed in the future. Any creative thought are welcomed. Due to its grid layout, the toolkit is best for building board game type models, and spreadsheet type models, e.g.timetabling Keen, 2000 . Also as demonstrated by the Organic Farm model, the package can be extended to a class of real‐time management models e.g. restaurant table management, traffic management, airport control, bus route planning, etc. . Like demonstrated in Figure 26 the visual presentation of a grid is flexible and can be used to reflect the trend of data over time or the difference between different items. There is really no need to list out all the possible applications of Basic Grid. As for a generic model development can be in any direction of interest. 7.2 Component Developments
To extend the breadth of Basic Grid’s application range, more components are needed for the package. Two components have been proposed for the “Data Visualisation” class: “Zoom Component” and the “Chart Component”, both of which are aimed at improving the presentation of data. Inspired by the Room Viewer model Yung, 1991 and part of the Ant model Keer, 2005 , the Zoom model is aimed at providing a 40 similar zooming window functionality that’s been demonstrated in those two models. Having access to adjust the geometry settings of the grids is the key to the construction of this component e.g. width / height of cells, font size of the SCOUT windows’ displaying string which should be considered whilst designing the core file. The Chart component set its goal on supporting the data plotting functionality that has been practised within both the Figure 27 Chart in the Planimeter Model Planimeter model Care, 2005 and also by the Spreadsheet Demo model Maad, 1996 in a simpler fashion. Also suggested is a Palette Component which provides the same functionality as the Palette in the Ant Navigation Model Keer, 2005 .
Figure 28 Palette Component in the Ants Model 7.3 GEL on Web EDEN
At last, I would like to suggest the development of a new notation on Web EDEN which can provide similar functionalities which GEL provides on the desktop version of EDEN. That is because of the relatively poor presentation of SCOUT windows on Web EDEN No relief properties are displayed , especially when interactions from the model user are needed, the flat SCOUT window is not very inviting. The development requires both knowledge of the understanding of Adobe’s FLEX platform. 41 Appendix A:
Screenshot of Basic Grid Prototype II running on Web EDEN. 42 Appendix B:
Code of the Basic Grid Package’s core file, bgrid.main:
43 Bibliography
Beynon, Meurig. 2006. A Glossary for Empirical Modelling. The Warwick Empirical Modelling Homepage. [Online] November 2006. http://www2.warwick.ac.uk/fac/sci/dcs/research/em/. —. 1998. Bubblesort ‐ an EM Model. s.l. : Project Archive, 1998. —. 2006. Empirical Modelling Project Archive. Empirical Modelling Homesite. [Online] November 2006. http://www2.warwick.ac.uk/fac/sci/dcs/research/em/projects/. —. 1998. Heapsort ‐ an EM Model. s.l. : EM Project Archive, 1998. —. 1986. Paradigms for Programming. s.l. : University of Stirling Workshop on Functional and Logic Programming, 1986. —. 2003. Radical empiricism, empirical modelling and the nature of knowing. s.l. : Knowledge Management and Philosophy: Proceedings of the WM 2003 Workshop on Knowledge Management and Philosophy, 2003. —. 2008. Revised Jugs Model ‐ an EM Model. s.l. : EM Project Archive, 2008. —. 2007. Visualisation using Empirical Modelling principles and tools. s.l. : AHRC ICT Methods Network Expert Workshop, 2007. Butler, Michael. 2007. Formal Methods and Software Engineering. s.l. : Springer‐Verlag Berlin Heidelberg, 2007. Care, Charles. 2005. Planimeter ‐ an EM Model. s.l. : EM Project Archive, 2005. Chafic Kazoun, Joey Lott. 2007. Programming Flex 2. s.l. : O'Reilly, 2007. E.Hopcroft, John. 2007. Introduction to automata theory, languages, and computation. s.l. : Addison‐Wesley, 2007. Gumpert, David E. 2007. A New Push to Make Farming Profitable. BusinessWeek.com. [Online] 10 August 2007. http://www.businessweek.com/smallbiz/content/aug2007/sb2007088_984272.htm. H.Kaisler, Stephen. 2005. Software Paradigms. s.l. : Wiley Interscience, 2005. Harfield, Antoney James. 2007. Empirical Modelling as a new paradigm for eductional technology. s.l. : PhD Thesis, 2007. Harfield, Antony. 2006. GEL: A definition‐based graphical environment language for EDEN. s.l. : Empirical Modelling Research Group, 2006. Keen, Chris. 2000. Oral Timetabling ‐ an EM Model. s.l. : EM Project Archive, 2000. 44 Keer, Daniel. 2005. Modelling Navigation and Landmarking in Ants. s.l. : 3rd Year Report, DCS, University of Warwick., 2005. —. 2005. Navigation and Landmarking in Ants. s.l. : EM Model Archive, 2005. King, Karl George. 2006. Uncovering Empirical Modelling. s.l. : MSc by Research Thesis, DCS, University of Warwick, 2006. King, Karl. 2006. Sudoku ‐ an EM Model. s.l. : EM Project Archive, 2006. Laurence T. Yang, Minyi Guo. 2006. High Performance Computing : paradigm and infrastructure. s.l. : J.Wiley, 2006. Linz, Peter. 2006. An introduction to formal languages and automata. s.l. : Jones and Bartlett, 2006. Maad, Soha. 1996. Simple Spreadsheet ‐ an EM Model. s.l. : EM Project Archive, 1996. Mendis, Chandika. 1997. Traffic Light ‐ an EM Model. s.l. : EM Project Archive, 1997. Meurig Beynon, M S Joy. 1994. Computer Programming for Noughts‐and‐Crosses: New Frontiers. s.l. : Proc. PPIG'94, Open University, 1994. Meurig Beynon, R C Boyatt, S B Russ. 2006. Rethinking Programming. Las Vegas : In Proceedings of IEEE Third International Conference on Information Technology, 2006. Meurig Beynon, Russell Boyatt, Zhan En Chan. 2008. Intuition in Software Development Revisited. 2008. O'Regan, Gerard. 2008. A Brief History of Computing. London : Springer, 2008. Pollan, Michael. 2006. No Barcode. s.l. : Mother Jones, 2006. —. 2008. The Omnivore's Next Dilemma. TED. [Online] Feburary 2008. http://www.ted.com/index.php/talks/view/id/214. Russ, Steve. 2007. Computing with Experience. Tilburg : Models and Simulations 2, October, 2007. Schneider, Steve. 2001. The B‐Method: an introduction. Basingstoke : Palgrave, 2001. Ward, Ashley Thomas. 2004. Interaction with Meaningful State: Implementing Dependency on Digital computers. s.l. : Phd Thesis from the EM Group, 2004. Yung, Edward. 1989. Room ‐ an EM Model. s.l. : EM Project Archive, 1989. Yung, Simon. 1991. Room Viewer ‐ an EM Model. s.l. : EM Project Atchive, 1991. 45