Title: A visual business modelling and simulation environment

Full text


Title: A visual business modelling and simulation environment

Authors: See Wong†, John Hosking†† and Peter Mazany†

Contact Author:

Associate Professor John Hosking Department of Computer Science University of Auckland

Private Bag 92019 Auckland, New Zealand john@cs.auckland.ac.nz


We describe Builder, a language and environment for interactive specification and simulation of business-oriented models. The Builder language uses an object-oriented declarative approach, combining a visual specification of the model structure (the business entities) with a declarative specification of model behaviour. The Builder environment supports exploratory development of models, with a tight integration between modelling environment and execution environment. This provides a system with a high degree of liveness, which supports either a concrete or abstract approach to model development. Models can be simulated using two different types of constraint solver, with other types of solver under development. A graphical user interface editor allows a GUI layer to be added to a model for entry of model data and display of results, while a notation editor permits customisation of the model notation.


A visual business modelling and simulation environment

See Wong†, John Hosking†† and Peter Mazany†

Active Learning Online Ltd PO Box 87-265


Auckland 1130, New Zealand {swong,pmazany}@visionplus.co.nz


Department of Computer Science University of Auckland

Private Bag 92019 Auckland, New Zealand john@cs.auckland.ac.nz


We describe Builder, a language and environment for interactive specification and simulation of business-oriented models. The Builder language uses an object-oriented declarative approach, combining a visual specification of the model structure (the business entities) with a declarative specification of model behaviour. The Builder environment supports exploratory development of models, with a tight integration between modelling environment and execution environment. This provides a system with a high degree of liveness, which supports either a concrete or abstract approach to model development. Models can be simulated using two different types of constraint solver, with other types of solver under development. A graphical user interface editor allows a GUI layer to be added to a model for entry of model data and display of results, while a notation editor permits customisation of the model notation.

1. Introduction

While computer modelling and simulation has been used for many decades, the process of modelling a system and simulating it has largely remained in the realms of experts and professionals with in depth knowledge of their domains. The technology of modelling and simulation has matured to a point where entire plants or systems have been modelled and simulated. Software packages and programming languages exist to aid the process of modelling and simulation and many are sophisticated in terms of the models that can be specified and simulated. However, there is still a need for a modelling tool that is targeted at users that have little experience with modelling, to make modelling more accessible to those wishing to learn and explore their field of interest without in depth knowledge of programming skills and numerical solution techniques.

The motivation for the work presented here comes from a business simulation game called Mike's Bikes [1,2] that simulates business scenarios with competing firms controlled by real players. This game provides a sophisticated business simulation environment, but lacks a modelling tool to allow different business organisations to be investigated. In the next section we describe Mike's Bikes and its underlying business model. This leads on to a discussion of requirements for a tool capable of supporting business modelling for Mike's Bikes-style simulations. In Section 4 we examine existing modelling and simulation approaches, before introducing our new modelling language and environment in Section 5. Following this we discuss the process of


model instantiation and provision of graphical user interfaces. A discussion and summary complete the paper.

2. Mike's Bikes

The Mike's Bikes business game models companies competing in the bicycle industry [1,2]. The simulation is discrete time based; the set of decisions for each company during the current period are inputs to a simulation engine which processes them and outputs the results for the next period. The process continues in this fashion for a set number of periods. Fig. 1 shows a screen dump of Mike's Bikes executing. Teams of people control the companies and playing the game helps them learn business concepts and formulate strategies. The decisions that companies need to make are numerous. Examples include: the amount of advertising to spend; when and where to position their products on the market; and changes to the company's manufacturing process and financial situation. Numerous reports are available to players to inform their decision-making. The numbers of companies and market segments are determined when the model is formed and are fixed through out the simulation. However, the number of products can change because firms can launch new products and abandon old ones.

Figure 1 Mike's Bikes screen dump

Mike's Bikes is an extremely successful approach to teaching basic business principles. However, as mentioned in the introduction, the business model it uses is effectively hard coded into the application. The model was initially developed, using pencil and paper, as a set of mathematical equations. Then a simplified version was prototyped using a spreadsheet before the model was finally coded in C++ in its


entirety. Because of this it is impossible for end users to explore and modify the model, and extremely difficult even for the game developers to make modifications. For example, the current model only has a manufacturing component. Adding a service industry component is a non-trivial programming exercise.

To assist in developing a set of requirements for a tool that could be used to create and implement the Mike's Bikes business model, it is useful to explore part of the existing model. Here we focus on a simplified demand model, modelling how the demand for products varies depending on factors such as how well they suit the market segments they are targeted at, and how much money is spent on advertising them. The business entities in this submodel are market segments and products. Companies own products, but we ignore companies for the purpose of this formulation. We also consider only three of many factors that could influence demand for a given product:

• Perceptual distance: this provides a numerical measure of how close a product matches the ideal characteristics for a given segment. The closer the match, the higher the demand for the product.

• Price: within a minimum and maximum expected price range for a segment, demand will decrease as price increases.

• Awareness: Consumers' awareness of a product decays exponentially with time due to forgetfulness. Spending money on advertising counteracts this decay. Let us consider the perceptual distance in more detail. Market research determines what factors the consumers consider important when deciding what product to buy. For bikes this might be, aesthetic style (design and appearance of the bike) and technical features (such as materials used and strength). Each of the attributes is ranked with a number. The possible combinations of these two attributes can then be visualised as a two dimensional plane called a perceptual map. A point in the perceptual map represents the ideal requirements for some market segment. For example the adventurers segment could represent the group of people that buys bikes for outdoor adventures. They demand high technical and style features. Leisure riders demand lower technical features, but style is important to them. The perceptual distance for a product p in a segment s is defined to be how far away from the segment's ideal point, p is:

PerceptualDistancep,s = || AttributePointp – AttributePoints ||

The influence on the demand is highest when the perceptual distance is zero and falls away as the product is further from the ideal point. Once it exceeds the influence

radius, demand falls to zero. This is captured by the distance index, which varies in

value from 0 to 1:

DistanceIndexp,s = (InfluenceRadiuss – PerceptualDistancep,s )/ InfluenceRadiuss if PerceptualDistancep,s < InfluenceRadiuss

= 0 otherwise

Similarly, equations can be derived for the price index and awareness index for a product p targeting sector s. The awareness index varies with time and consists of two


parts: a contribution from the previous time period, plus the impact of advertising in the current time period (modelled using an S curve):

AwarenessIndex(time)p,s = AwarenessIndex(time-1)p * AwarenessDecays + SCurve(Advertisingp)

The three indices can now be combined using a power law equation to produce the ‘ValueForMoney’ for product p targeting segment s (DP, AP and PP are segment parameters determining sensitivity of the segment to the particular factor):

ValueForMoneyp = DistanceIndexp^DPs * AwarenessIndexp^APs * PriceIndexp^PPs

The segment share for a product is determined by how its value for money compares with that of other products targeting the segment (i ranges over all products that target the segment):

= i i p s p ney ValueForMo ney ValueForMo re SegmentSha ,

Continuing in this way, equations can be defined for the total segment demand, the demand for each product targeting a segment and the total demand for a product over all segments. In playing Mike's Bikes, players need to make decisions at each time period about the price, advertising, and market placement of their products, which feed through, using an implementation of these equations, into an updated product demand, and hence profit, for the company.

This simplified demand model already exhibits some interesting non-linear dynamics, especially if many products and segments are created. The complete Mike's Bikes model which models an entire business scenario becomes very complicated with many model entities related to one another.

Having explored the domain in which we are constructing models and some of the terminology and methodology used to specify them manually, we are now at a stage where we can begin to design a language suitable for this type of modelling task. There are several observations that can be made about the simplified demand model which are pertinent to the design of such a language. First is that the model lends itself to an object oriented approach. The two entity types (segment and product) in the model have associated variables that describe their state and behaviour, and multiple instantiations of each type of entity occur in a typical scenario. One benefit of recasting the model in object oriented terms is that the indexing scheme on variables, which is confusing and complicated when the relationship between model entities become complicated, becomes less necessary. Each object describes its own state and behaviour.

Secondly, a relationship can be identified between the two entity types. The ‘targets’ relationship represents the fact that a given product targets a given segment.


The ‘targets’ relationship is many to many between products and segments. Such relationships identify an important type of abstraction that can be exploited in the model building process.

Thirdly, the behaviour of the model entities is entirely described by the equations and functions that relate the variables. That is, the model is declarative; all state changes are described by these equations. Business modellers are comfortable with an equational approach to modelling, whereas, by and large, they are much less comfortable with imperative programming approaches. Retaining a declarative equational approach in designing the modelling language is an important goal.

3. Prototype language and modeling environment

The design of our modelling language, Builder, aims to separates the specification of the model from the solution process and subsequent simulation and analysis of the model. Because the specification of the model is more stable than the technology used to solve it, decoupling the specification from the solution process has many benefits. The specification of the model is aimed to be as natural to the users as possible and yet flexible enough to encompass a broad class of models.


Builder is object oriented. Classes and relationships define the structure of the model. Declarative equations and functions define the behaviour of the model. A visual notation, based on class and instance diagrams, is used to specify classes, relationships, and instances. Equations and functions are defined textually.

Classes are the basic building blocks. They encapsulate typed attributes, equations, and functions. Variable attributes represent the state of objects that are instances of the class. Relationships associate classes together. They are themselves classes, and so can encapsulate state and behaviour specification. They differ from ordinary classes by containing role variables. For example, Fig. 2 shows the structural specification of the simplified Mike’s Bike demand model. This consists of three classes, World, Segment, and Product, related by the Targets relationship. Classes and relationships are visualised as rectangles, with class name and attribute definitions inside. Attributes may be of simple type, or may be arrays, such as the Point attribute of a Segment, which is modelled as an array of reals (one real per attribute contributing to the point in the perceptual map). Relationships have role variables with associated cardinality constraints. Each role is associated with a class that takes part in the relationship and this connection is shown visually by a line connecting the role variable with the class. For the Targets relationship, the roles are Segment, Product, and World (connecting to classes of the same name). The first two of these have many cardinality, indicating the relationship between Segments and Products is many to many. By contrast there is only one World associated with a Targets object (in fact a single World object is used to maintain the simulation time). When instantiated, each triple of World, Segment and Product objects that are related has a corresponding Targets relationship object connecting them.

Role variables provide a way of navigating from a relationship object to the objects connected by a relationship. By default, however, classes connected to by a relationship object are unable to navigate in the reverse direction to that relationship object. Mapping variables indicate that this navigation is possible, and provide a name to reference the relationship objects by. For example, class Segment has a TargetBy mapping variable, which permits access to the collection of Targets objects related to a Segment, and, through them, the corresponding Product objects. Similarly the Targets mapping variable in class Product allows navigation from a Product to the Segments that target it. There is no mapping variable in the World class, indicating that objects of class World do not need to access objects of class Segment or Product.

Equations and functions specify the principal dynamic behaviour of models. The Builder environment currently supports equation definition via free format text editor windows, one per class, such as the one shown in Fig. 3. The equation formalism borrows much from modern functional languages, such as Haskell [3], and builds on our earlier work with the Kea language [4]. Equations relate attribute values together in a declarative fashion. Functions are essentially parameterised equations. For example, Fig. 3 shows the two equations specifying the demand and total value for money calculations for the Segment.

Within an equation, variables local to a class, such as Demand and TotalValue, can be referenced directly, as is normal in an object oriented approach. Variables in objects


referenced by objects of the class are accessed using the common "." notation ("ObjectRef.Variable"). Variables local to an equation, such as AveragePrice, can be specified (within a let clause) to help modularise calculations.

A variety of collection manipulation functions are provided, such as the sum function, which iterates over a collection summing an expression defined on each element in the collection. In the equations shown, the collection iterated over is that specified by the TargetBy role variable, i.e. each of the Targets relationship objects that has this Segment as its Segment role. Thus the calculation for AveragePrice sums the product of the MarketShare and PriceIndex for each Targets object associated with the Segment. The equations defined in class Targets specify how their MarketShare and PriceIndex attributes are calculated (using values from the Segment and Product objects they relate). Other collection functions include those for product and cardinality of a single collection and union, difference, and intersection, of two collections.

Figure 3: Equations for Segment class

Objects are typically created directly by the user through the interactive environment, as described in the next section, however automatic creation and deletion of objects is also possible using explicit creation and deletion operators. These are mostly used to create instances of relationship objects automatically when objects that should be related are created. For example if a new Product is created, a new Targets


relationship should be created for each Segment the Product targets. Fig. 4 shows code that would cause this to happen:

let {

s in Segment, p in Product } in {

when (s.Distance(s.Point,p.Point) < s.Radius) { new Targets(Segment = s, Product = p)

} }

Figure 4: Automatic relationship creation

This example makes use of the when construct, which supports discrete event modelling. Local variables s and p range respectively over all instances of the Segment and Product classes. The when construct has two parts: a condition and an action to perform if the condition is true. Thus, whenever the perceptual distance between a product and segment is less than the influence radius, the action is triggered, creating a new Targets relationship between them. As new segments or products are added, the corresponding when conditions are checked and Targets objects created as appropriate. Another when clause can be used to delete Targets relationships if the perceptual distance changes to be larger than the influence radius.

4. Model instantiation and simulation

The instance editor allows the instantiation of classes and relationships, providing a workspace in which model instances can be placed and simulated. Direct editing of variable values and connection of relationships by mouse drag are supported. Fig. 5 shows instantiation of the simplified demand model with one segment and two products, both of which target the segment. Note that the top product (object 0) has a larger market share than the lower one because it is cheaper, has a higher advertising budget, and it's perceptual distance from the segment point is less than that of the other product.

Models may be instantiated at any time. This allows simulation even though a model schema is not fully complete, encouraging exploratory development of the model. The underlying solver will solve the model as much as possible given the inputs. The instance editor provides visual feed back by evaluating equations and functions as soon as enough information is available to it.

As changes are subsequently made to classes, any instances of those classes are updated to reflect the changes, maintaining consistency between the model and instance views. For example, if a user adds an attribute to a class, all instances of that class also have an extra attribute added. If equations and functions of a class are modified then the solver re-solves the instantiated model so that everything is consistent.


Figure 5: Demand model instantiation

Changes to instances also propagate back to classes. For example, if an attribute is added to an instance, the system infers that the attribute should also be added to the class that the instance belongs to, and the change then propagates to all other instances of that class. This provides a prototype-based approach to model formulation without losing the class concept, as modellers can immediately work on the instances themselves with the system deducing the classes and relationships. Similar techniques are used in Self [5] (as clone maps) and other advanced prototype languages such as Forms/3 [6], which deduces commonality between instances implicitly.

As mentioned in the introduction to Section 3, the Builder environment attempts to decouple the model from the choice of solution process. Thus, for any particular model, a choice of constraint solvers is available to simulate an instantiation of the model. The solver used in Fig. 5 for the demand model is a one-way constraint solver, similar to that used in spreadsheets. This provides exact (within the precision of reals) values, but is limited in the types of model it can simulate. For example, this solver does not support solution of simultaneous equations.

An interval constraint solver for Builder has been implemented as a proof of concept for reliable computation and error control, which the simple one way equation solver does not support. Although it is somewhat slower, it has the advantages of interval arithmetic, and gives a multi-way constraint system implementation capable of handling simultaneous non-linear equations and inequality constraints. Fig. 6 shows the interval solver in use simulating the solution of a modelling mapping between objects representing cartesian (CPoint) and polar (PPoint) co-ordinates. The values shown now take on intervals of numbers rather than a single number. Solutions are


given as floating point intervals; the goodness of solutions can be measured by the intervals’ widths, in which the true solutions are guaranteed to lie. In the example shown in Fig. 6, an exact solution has been obtained as all the interval widths are zero.

Figure 6: Interval solver mapping cartesian and polar co-ordinates

5. Graphical user interface specification

Once a model is developed to a useful point, the next step is to customise it for use by the intended users (who may or may not be the business modellers developing the models) by adding a user interface. There are several reasons for having a separate layer that visualises the model instance rather than directly coupling visual elements on to the instances themselves. One is that the modeller may wish to present different views of the model to different kinds of users. Another is that the user interface or part of it could later be reused for completely different kinds of models.

The user interface customisation has two aspects. The first is the addition of a graphical user interface to allow model attributes to be manipulated and visualised in a simple and straightforward manner, rather than via the instance editor. The second is to customise the visual representation of the model itself, to make it more understandable by a particular end user community. This second aspect is only required if end-users need to be able to browse and/or manipulate the model or its instance representation.

To support the first aspect, a graphical user interface builder is provided as part of the Builder environment. This allows modellers to present a view of the model instantiation to the end user in a way familiar and useful to them. The end user graphical interface can then be used to obtain input and present results to the users of the model. In the Mike's Bikes simulation game, the decisions that a user makes are presented as dialogs and the simulation results of each period presented as reports and graphs.

The user interface builder permits the construction of forms, reports and graphs. The modeller can place a variety of graphical interface elements such as edit boxes, combo boxes and radio buttons, on to a form to receive user input or display results. These elements are linked to the attributes, which they affect the value of, or the value of which affects them. Fig. 7(a) shows a form used to enter and display information


about a Product object. Users can modify the product's price and advertising expenditure, by typing in the form fields, or move its market placement by dragging its point around on the perceptual map. As these changes are made, the Demand field is updated to show the new demand for the product. Figure 7(b) shows a form containing a graph depicting the results of executing another model (a rocket simulation taken from [7]). The user interface builder is, as yet, somewhat unsophisticated, lacking a few useful components, such as sliders, but is sufficiently powerful to demonstrate proof of concept.

Figure 7: Graphical user interface examples

Customisation of the model representation is supported via a notation editor. This allows modellers to make the visual appearance of model classes and objects relate to the domain they are targeted for. For example, in electrical models, it is useful to be able to associate the common iconic symbols for electrical elements such as capacitors and resistors to the classes and objects representing them.

Figure 8: Simplified demand model represented using EER and ORM notation.

The notation editor provides a palette of primitive geometrical symbols that can be mapped to language constructs. These include ellipses, rectangles, rounded rectangles, diamonds and polygonal shapes. Various connecting primitives, lines and line


segments, are provided. Attributes can be attached to the primitives: text labels for all primitives and arrow attributes for connecting primitives. Hot spots can be attached to a shape to form one end of a connecting primitive. Bitmaps can be attached to shape primitives for user defined images. Fig. 8 shows a simplified version of the demand model represented using EER and ORM notation. The current implementation does not, however, support the change of an instance’s appearance during simulation. Such a feature could be valuable in supporting animation.

6. Comparison with other work

There are a number of existing business modelling languages and environments that attempt to serve a similar problem domain to that of our Builder language.

Extend is an iconic environment for modelling and simulating discrete event, continuous, and combined discrete event/continuous processes and systems [8]. Like Builder it uses a combination of visual and textual specification. However, the visual paradigm used is quite different. In Builder, the visual representation models objects and their relationships. The textual language is used to specify attribute interactions in a declarative manner. Extend is far more process oriented, with the visual models consisting of process objects, called blocks, connected together via dataflow links. The textual language used to define blocks is an imperative style language similar to C, rather than the declarative approach taken in Builder. We argue that Builder’s approach provides a closer mapping to the equational style of modelling that forms the basis of Mike’s Bikes style models.

Arena [9] is a dataflow, flowchart based modelling tool. It is a graphical front end for the discrete event language SIMAN. Models are built by dragging module components into a model window and connecting the modules together with lines. Arena supports the analysis of simulation results by providing user with reports and animating the simulation. Like Extend, the emphasis is on process modelling rather than reflecting structural properties of a model, as does Builder.

IThink, developed by High Performance Systems Inc [10], is based on systems dynamics introduced by Forrester [11]. Systems dynamics focuses on system structure as a whole rather than the behaviour of individual components in the system. Inherent in that system structure are the causal loops or feedback loops that are used to describe the pattern of behaviour of the system. A feedback loop is a closed sequence of causes and effects. Systems dynamics describes non-linear dynamical systems with a visual notation called the stock-flow diagram containing two different types of icon, namely stocks and flows. Stock variables represent accumulations and flow variables represents rate of accumulation. From a continuous time modelling view, stock variables can be thought of as a dependent variable y, and flow variables represents the rate of change of that variable dy/dt. IThink is a dataflow visual language, with icons representing the primitives of the system dynamics notation. Various modelling elements are provided that can be connected together to form a model. IThink provides a good environment for modelling using a Systems Dynamics approach, but is limited to that paradigm. To use it for Mike’s Bikes models would necessitate a translation of the mathematical model into Systems Dynamics’ stock and flow representations.


Modelica is a declarative, object-oriented language intended for use in modelling physical systems [12]. The Modelica language specification was introduced by a working group within Eurosim stemming from the work by the ESPIRIT project “Simulation in Europe Basic Research Working Group” (SiEWG). It attempts to specify a common language to describe physical systems regardless of the different formalism and solution techniques used to solve the model. The design goal of Modelca language was to expand on a common mathematical framework of modelling dynamical physical systems, namely DAE (Differential-algebraic equations), then introduce additional formalism in future specifications.

A Modelica class encapsulates a modelling component. Classes are defined by declaring a set of state variables and a set of equations that relates the variables. To connect model classes together, a special operator ‘connect’ is provided to connect two different connector classes. Connector classes are special classes that define what kinds of variables are involved in the connection. Modelica distinguishes between two types of variables in a connector classes, namely across and through variables. Across variables always sum to zero at a connection and through variables are made equal at a connection. This is a generalisation of the Kirchoff law. The default variable type in a connector class is an across variable, the ‘flow’ modifier keyword can be added to a variable declaration to specify that the variable is to be made a flow variable. The ‘connect’ operator generates these additional equations taking into account what kind of variables is involved in the connectors.

The Modelica language is quite similar to our Builder language, using an object oriented plus declarative style, together with connector classes that are similar to our relationship classes. The semantics are somewhat different, but similar in power. However, Modelica lacks the visual modelling environment that Builder provides, and, in particular, lacks Builder’s tight integration between modelling and instantiation environments.

Our work in developing Builder has been strongly influenced by the Visual Languages community, most notably Burnett’s work on Forms/3 [6]. The equational style of Builder is quite similar to the spreadsheet formula basis of Forms/3. Both strive to offer a high degree of liveness to end users (aiming at level 4 in Tanimoto’s categorisation [13]), although the time steering facilities of Forms/3 provide a level of sophistication that is currently missing from Builder. There are, however, some significant differences in style between the two approaches, mainly due to the different domains each system is aimed at. Forms/3 aims for a highly concrete representation, whereas Builder provides more abstract (and hence less concrete) modelling via its class-based representation. These distinctions are blurred somewhat, however as Builder allows instance-based programming (with changes propagated to classes) and Forms/3 provides a “concrete” approach to ADT specification. Builder’s equation specification lacks the sophistication of the cell-based formula construction method of Forms/3, while Forms/3 lacks the high level visual modelling capability of Builder. In terms of execution behaviour, Forms/3 is limited to a one-way constraint solver, while Builder aims to support a variety of execution semantics.


7. Conclusions and future work

We have described a tool for formulating mathematical models oriented towards models used in business simulation. It includes a language for specifying models and an environment that is both visual and interactive supporting model specification using that language. Two constraint solvers have been presented as a proof of concept that the language semantics is independent of the technology used to solve the models.

The design of the language takes an object oriented declarative approach to modelling. The modeller specifies equations, functions and structural integrity constraints within an object oriented framework. The system is left with the task of satisfying the equations and maintaining the structural integrity constraints. Relationships between classes are supported as first class entities through relationship classes.

The visual environment provides the modeller with a visual notation for specifying the classes and relationships. A class editor is provided for specifying classes, relationships and variables. A textual editor is also provided for entering equations, functions and constraints. An instance diagram editor is provided for instantiating model instances. The system gives live feedback as the user is modifying the model. The system is able to simulate partial models that are not fully specified. Modifications to model parameters and states are reflected to the environment immediately. Consistency is kept between the class and instance diagram editors so that any modification to the model through either the class or instance diagram editor reflects to the other views. In particular, modifications to classes are reflected to their instances and modifications to an instance are reflected to the class it belongs to. The appearance of instances can be specified through a notation editor, where the appearances of instances can be changed from the default shape to user defined shapes. A graphical interface editor provides the modeller with the ability to build end-user graphical interfaces such as input forms, reports and graphs.

The implementation of the prototype of Builder only supports a limited subset of the full design of Builder. For example, the complete design includes multiple inheritance capabilities, and a variety of other solver methods. The equation specification editor could make use of the formula construction approach of spreadsheet based languages such as Forms/3. In current and future work we aim to implement such language and environment extensions. We also plan to develop an application construction tool, to allow “completed” models to be generated as stand-alone tools capable of running in a multi-player network environment, similar to that of the existing Mike’s Bikes application.

The work presented here was motivated by a need to develop a simple to use yet powerful modelling tool aimed at several different kind of users, but particularly aimed at business modellers. Users who are familiar with the process of modelling and simulation can quickly define their models through the visual environment, while others can make use of the models developed to learn modelling and simulation skills. The system provides live feedback that supports those users wishing to explore and test ideas without having to fully define their models.



[1] Mazany, P., and Sharpe, A., Mike’s Bikes, VisionPlus Developments, 1997. [2] Mikes Bikes web site, http://www.netmike.com/

[3] Peterson, J. and Hammond, K. Report on the Programming Language Haskell 1.4, A Non-strict Purely Functional Language. Technical report. Yale University. Department of Computer Science. 1997.

[4] Hosking, J. Hamer, J., and Mugridge, R., Kea 1.0 Tutorial Manual, Department of Computer Science, University of Auckland. 1991.

[5] Urs Hölzle, Bay-Wei Chang, Craig Chambers, Ole Agesen, and David Ungar. The Self Manual, Version 1.1. Unpublished manual, February, 1991.

[6] Yang, S. and M. Burnett, From Concrete Forms to Generalized Abstractions through Perspective-Oriented Analysis of Logical Relationships, 1994 IEEE

Symposium on Visual Languages, St. Louis, MO, October 1994

[7] T. Green, M. Petre. Usability analysis of visual programming environments: a 'cognitive dimensions' framework. Journal of Visual Languages and Computing. 131-174, 1996.

[8] Extend users manual. Demo version, ImagineThat Inc, 1995.


[9] Arena business edition version 3.6 Help. Windows NT demo. http://www.sm.com/ [10] http://www.hps-inc.com/

[11] Jay W, Forrester. Industrial Dynamics, Productivity Press. 1961

[12] H. Elmqvist, F. Boudaud, J. Broenink, D. Brück1, T. Ernst, P. Fritzson, A. Jeandel, K. Juslin, M. Klose, S. E. Mattsson, M. Otter, P. Sahlin, H. Tummescheit, H. Vangheluwe. Modelica(tm) - A Unified Object-Oriented Language for Physical Systems Modeling. Version 1, September 1997. http://www.modelica.org

[13] Tanimoto, S.L. VIVA: A visual language for image processing. JVLC 1, 2, 127-140. 1990.





Related subjects : Business modelling