Group Title: investigation of the use of metaphor in the rubeTM paradigm
Title: An investigation of the use of metaphor in the rubeTM paradigm
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE ZOOMABLE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00100790/00001
 Material Information
Title: An investigation of the use of metaphor in the rubeTM paradigm
Alternate Title: Investigation of the use of metaphor in the rube paradigm
Physical Description: Book
Language: English
Creator: Hopkins, John F., 1969-
Publisher: State University System of Florida
Place of Publication: Florida
Florida
Publication Date: 2001
Copyright Date: 2001
 Subjects
Subject: Three-dimensional imaging   ( lcsh )
Computer and Information Science and Engineering thesis, M.S   ( lcsh )
Dissertations, Academic -- Computer and Information Science and Engineering -- UF   ( lcsh )
Genre: government publication (state, provincial, terriorial, dependent)   ( marcgt )
bibliography   ( marcgt )
theses   ( marcgt )
non-fiction   ( marcgt )
 Notes
Summary: ABSTRACT: The rube trademark paradigm proposes a modeling methodology that extends modeling into the third dimension and integrates user-specified metaphors. This thesis examines the motivation for including metaphor in rube trademark modeling processes. The practical feasibility of incorporating customized metaphors in rube trademark models is demonstrated through the step-by-step development of two example models according to the rube trademark modeling steps. These example models are simplified, hypothetical operating system task schedulers. Agent-based, architectural, and other metaphors are integrated in the visualization of the example models to create a work of art. During the development of the example models, several reusable generic model components are created that can be added to a publicly available toolkit. The fully developed example models may also be added to a model repository. Finally, the example models and the process by which they are created are assessed and future directions are suggested.
Summary: KEYWORDS: 3-D programming, rube trademark, metaphor
Thesis: Thesis (M.S.)--University of Florida, 2001.
Bibliography: Includes bibliographical references (p. 75-78).
System Details: System requirements: World Wide Web browser and PDF reader.
System Details: Mode of access: World Wide Web.
Statement of Responsibility: by John F. Hopkins.
General Note: Title from first page of PDF file.
General Note: "TM" in "rubeTM" in title is superscript.
General Note: Document formatted into pages; contains ix, 79 p.; also contains graphics.
General Note: Vita.
 Record Information
Bibliographic ID: UF00100790
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
Resource Identifier: oclc - 47889840
alephbibnum - 002729349
notis - ANK7113

Downloads

This item has the following downloads:

JFHmasters ( PDF )


Full Text











AN INVESTIGATION OF THE USE OF METAPHOR IN THE rubeTM PARADIGM


By

JOHN F. HOPKINS












A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2001




























Copyright 2001

by

John F. Hopkins



























This work is dedicated to my wife, Jennifer.















ACKNOWLEDGMENTS

I owe my development as a scholar of computer science to my research advisor

and mentor, Dr. Paul A. Fishwick, and my second mentor, Dr. Robert M. Cubert. They

have been my guides in both technical and political matters throughout my time here in

the Computer and Information Science Department at the University of Florida. Without

their gentle patience and support, I could not have succeeded in many of my endeavors.

They have been an inspiration to me both professionally and personally.

Thanks also go to Dr. Fishwick's other research assistants whom I have had the

pleasure of working with: Linda Dance and Taewoo Kim. Over time, we became more

than a collection of individuals researching similar problems--we became a team. Our

interactions gave me the creative spark and moral support that I required from day to day.

My wife, Jennifer, has been a constant source of emotional support, comfort, and

practical assistance in all of my affairs. She has been my best friend, confidante, and

constant companion. Of all the blessings and honors that have been bestowed upon me, I

value her love the most.

Finally, thanks also go to the U.S. Department of the Interior and the U.S. Air

Force for their continuing financial support of this and related research.
















TABLE OF CONTENTS

page

A C K N O W L E D G M E N T S ...................... .. ...................................................................... iv

LIST OF FIGURES ........................................ ......................... ..... vii

A B S T R A C T ................................ix.............................

CHAPTERS

1 IN TRODU CTION .................. ............................ .. ...... ................ .. 1

1.1 T rends in P program m ing ..................................................... ............ .............. 1
1.2 Overview of Thesis .................. ............................ .. ...... ... .......... .. 3

2 TH E rubeTM PA R A D IG M ............................................................................. ...... .. 6

2.1 The Object-OrientedPhysical MultimodelingTM System............................ 6
2.2 Heritage of rubeTM and Comparison with OOPMM ................... .............. 7
2.3 rubeTM's Developm ent Environm ent ................................................ ............. 8
2.4 The Steps of the rubeTM Modeling Methodology ............................................ 10
2.5 rubeTM's Perspective on Metaphor .................... ..... ............. 11
2.6 rubeTM's R research Philosophy .......................................................... .... .... ... 15
2.7 rubeTM 's Intended A udience......................................................................... ... 15

3 THE IMPORTANCE OF METAPHOR .............................................. ............ 17

3.1 Brief Survey of M metaphor Theory.............................................. ............. 17
3.1.1 The Literalist/Figuralist Debate .............. ...... ......................... .......... 18
3.1.1.1 Literalist tenets .......................................... .. ........... ...... .... 18
3.1.1.2 Figuralist tenets ........................... ........................... 18
3 .1.2 D iscu ssion .............. ... ................................ 19
3.2 Metaphor and Analogy in Cognition...... ................. .............. 20
3.3 M etaphor in Com puter Science........................................ ............. .............. 21
3.3.1 Empirical Measurement of the Usefulness of Metaphor.............................21
3.3.2 Metaphor in Computer Modeling and Paradigms................ ...............23
3.3.2.1 The data flow m etaphor......... .................................. ..... ............ ...... 23
3.3.2.2 The agent metaphor................. ..................... .............. 24
3.4 Metaphor in 3-D Programming......................................... 25









3 .4 .1 C U B E ................................................... 2 5
3 .4 .2 T o o n T a lkTM .................................. ......... ..................................... .............. 2 6

4 EXAMPLE APPLICATION OF METAPHOR IN THE rubeTM PARADIGM .......... 27

4.1 Step 1: Choose System to be M odeled ................................................... ... 27
4.2 Step 2: Select Structural and Dynamic Behavioral Model Types.........................28
4.3 Step 3: Choose a M etaphor and/or an Aesthetic style........................................ 34
4.4 Step 4: Define Mapping/Develop Analogies ......................... .............. 35
4.5 Step 5: C create M odel ............................... .. ..... ...... ............... .............39
4.6 O operation ........... .. ....... ... ... .. .... ...................... .............. .. ... .. 45
4.7 Steps 3, 4, and 5 Revisited: Example Task Scheduler Based on Logical Time.... 49
4.7.1 Step 3: Choose a Metaphor and/or an Aesthetic Style............................. 49
4.7.2 Step 4: Define Mapping/Develop Analogies ............. .............49
4.7.3 Step 5: Create M odel ........ ........ .. ................. ... ...................... 52
4.7.4 Operation.......................................... ......... 53

5 THE USE OF METAPHOR IN rubeTM: FINDINGS AND PROPOSALS ................. 54

5.1 Proxim al Findings and Proposals ......... ................. ................... ............. ....... 54
5.1.1 The Impact of Metaphor on rubeTM Model Aesthetics ............... ............. 54
5.1.2 Proposals Concerning rubeTM Modeling Step Order.................................. 55
5.2 Distal Findings and Proposals ...... ........... .. .. ........ ............... 60
5.2.1 Findings Related to the Literalist/Figuralist Debate .................................. 60
5.2.2 Findings Related to the Importance of Metaphor and Analogy in Cognition 61
5.2.3 Surfacing the Activity of Model Transitions................. ....................... 61
5.2.4 The Objective Evaluation and Automatic Generation of Analogies ............. 62

6 CON CLU SION S ........... .................. ............ .... ............ .. 65

6.1 R eview of Thesis ................................. ... .. .............. ................... .. 65
6.2 Contributions of the Example M odels ............................................... ................ 70
6.2.1 Reusable Generic Model Components for the rubeTM Toolkit..................... 70
6.2.2 Fully Developed Models for the rubeTM Model Library ............................ 70
6.3 Future D directions ................ ..................... ........ .............. ........ .... 71
6.3.1 Em pirical R research ............ ......... ............ ...... ................ .............. 71
6.3.2 M odeling R esearch........................ .............. .................. .............. 73

LIST O F R EFER EN CE S .................................................... .................................. 75

BIOGRAPHICAL SKETCH.................... ......................................... ......................... 79
















LIST OF FIGURES


Figure Page

2.1 Browser controls of CosmoPlayer 2.1.1. ............. ............................. .............. 8

4.1 Graphical representation of the vertically layered structure of a MINIX-like OS... 28

4.2 A Conceptual Model of the hypothetical OS. ....................................................... 29

4.3 Overhead schematic of task scheduler QNET component layout....................... 30

4 .4 T h e task active ity F SM ............................................................................................. 3 1

4.5 Metaphor mapping between operating system and building................................... 35

4.6 Metaphor mapping between a layer of the OS and a floor of the building ............. 36

4.7 Metaphor mapping between task and synthetic human agent............................. 37

4.8 Metaphor mapping between message passing and courier agent with briefcase..... 37

4.9 Metaphor mapping between an OS device and an agent standing behind a desk
(service facility) .......... .......... ......... ................................ ............. 38

4.10 Metaphor mapping of a waiting line to a device queue. ....................................... 38

4.11 Task activity FSM, traffic light FSM, and state and transition mappings between
the tw o FSM s. .................... ................ ............................... 39

4.12 A task's internal FSM with the In Transit, Waiting, and Running states. ............. 44

4.13 Top view of the task scheduler .............. .. ........................... ... ... ........... 44

4.14 Metaphor mapping between PATH and ROUTE........................................ 45

4.15 Close-up view of task scheduler operation. ............... ................... .................. 48

4.16 Mappings associated with the calendar metaphor.................... ................. 50









4.17 Physical manifestations of the FUTUREEVENTCALENDAR in the OS task
sch ed u ler ............... ...... ......... ............................................ 5 3















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

AN INVESTIGATION OF THE USE OF METAPHOR IN THE rubeTM PARADIGM

By

John F. Hopkins

May 2001


Chairman: Dr. Paul A. Fishwick
Major Department: Computer and Information Science and Engineering

The rubeTM paradigm proposes a modeling methodology that extends modeling

into the third dimension and integrates user-specified metaphors. This thesis examines

the motivation for including metaphor in rubeTM modeling processes. The practical

feasibility of incorporating customized metaphors in rubeTM models is demonstrated

through the step-by-step development of two example models according to the rubeTM

modeling steps. These example models are simplified, hypothetical operating system

task schedulers. Agent-based, architectural, and other metaphors are integrated in the

visualization of the example models to create a work of art. During the development of

the example models, several reusable generic model components are created that can be

added to a publicly available toolkit. The fully developed example models may also be

added to a model repository. Finally, the example models and the process by which they

are created are assessed and future directions are suggested.














CHAPTER 1
INTRODUCTION


1.1 Trends in Programming

The movement from machine language to assembly code was one of the first

steps toward "bringing the computer closer to the user." Assembly code provides

programmers with a unique alphanumeric abbreviation for each machine language

instruction that can be created. These abbreviations serve as mnemonic devices for

programmers since they often resemble natural language. As a result, programmers have

found that assembly code is easier to use and produces more readable programs than its

machine language counterpart. Improved code readability, in turn, has aided debugging

efforts and made code more maintainable. These developments have increased

programmer productivity.

The trend toward reducing the burden of tedious, detail-oriented programming

tasks on the programmer has continued with the development of specialized, higher-level

programming languages like Fortran, C, Lisp, and others. Reduction of syntactical

constraints and improvement of expressive power have been primary objectives in this

process. Furthermore, many languages have been designed with the interests of specific

communities of users in mind. For example, Fortran was designed for scientific

applications, C for systems programming, and Lisp for artificial intelligence

programming. More recently, object-oriented languages like C++ and Java have been a









focus of attention. These languages, in part, have the goal of improving the software

engineering process through the promotion of modular design and code reuse.

The above-mentioned development of computer languages has had a somewhat

corresponding parallel in the development of two-dimensional (2-D) "visual," or "icon-

based," programming environments. Some of these allow programmers to create

diagrams that represent program structure, hierarchy, and functionality in such a way that

the diagrams can be translated directly into an executable program. One goal of visual

languages is to free programmers from the exclusive use of text. In the same way as the

development of programming languages has made programming more of an agreeable

task by more closely matching our everyday communication patterns, visual languages

have attempted to take advantage of the common and intuitive observation that humans

often "think visually." Some have already taken this concept to the next logical step, as

there have been several efforts to develop three-dimensional (3-D) programming

environments and languages.

A programming environment that resembles the holodeck of the Star Trek ( &

TM Paramount Pictures) science fiction series is perhaps an ultimate vision for developers.

One day, a developer could be immersed in a 3-D environment in which he or she could

program by creating, manipulating, and specifying the relationships between customized

and simulated 3-D objects. The use of text programming might be minimized or

eliminated. This is clearly an ambitious undertaking given today's technology and the

social momentum of tradition in the realm of software engineering. However, given the

high rate of technological advancement, the need for better methods of managing and

maintaining increasingly complex software, and the trends outlined above for









accommodating developers, there seems to be good reason to believe that the

development of programming holodeck may simply be a matter of time.


1.2 Overview of Thesis

Fishwick [1, 2] has been developing a 3-D modeling paradigm called rubeTM that

outlines some of the first principles that might guide a user of a programming holodeck.

In order to further the trend toward "bringing the computer closer to the user," rubeTM

incorporates user-specified metaphor in modeling and programming (M&P) processes.

In addition, rubeTM surfaces these metaphors in dynamic 3-D visualization. Thus, rubeTM

consciously promotes the potential for models and programs to become works of art.

The rubeTM paradigm itself is relatively new and is still developing. The overall

goal of this thesis is to contribute to the continuing development of rubeTM by augmenting

support for and exploring rubeTM's use of metaphor in M&P processes and model

visualization. This thesis builds upon work reported in Hopkins and Fishwick [3, 4], and

is part traditional research, part development, and part artwork. The following questions

are addressed:

1. What is rubeTM and how did it develop?

2. What premises provide support for the use of metaphor in M&P processes
and model visualization, and so also in rubeTM?

3. Is metaphor really such an important phenomenon that it deserves our
attention?

4. What other previous work resembles rubeTM, and how does this work
approach metaphor?

5. Is it practically feasible to incorporate user-specified metaphors in M&P
processes and model visualization as currently prescribed by rubeTM?









6. Can rubeTM meet the objective of blending the M&P process with the
creation of a work of art, and does the use of metaphor contribute toward
meeting this objective?

7. What are alternative possibilities for the use of metaphor in rubeTM?

8. What are some suggestions for future research associated with the use of
metaphor in rubeTM?

The answers to Questions 1 and 2 are pursued through a review of the rubeTM paradigm.

Besides detailing rubeTM itself, this review bolsters the support for the use of metaphor in

rubeTM with new and original material. The answers to Questions 3 and 4 are pursued

through a traditional literature review that addresses material from metaphor theory,

psychology, and computer science. The answers to Questions 5 and 6 are pursued

through the synthesis of two example models. The first example model is a hypothetical

synchronous operating system (OS) task scheduler. The second example model is a

modification of the first example model and is a hypothetical hybrid synchronous/

asynchronous OS task scheduler. These example models are among the very first to be

formally developed according to the rubeTM modeling steps and compose the

development and artwork aspects of the thesis. The answer to Question 7 is pursued

through a discussion of the example models and the process by which they are created.

This discussion culminates with proposals for possible modifications to the rubeTM

modeling steps in relation to metaphor. The answer to Question 8 is pursued directly

with proposals for future directions.

One current focus of rubeTM research is the development of a publicly available

toolkit composed of reusable, generic, 3-D model components. Another focus is the

development of a repository of prefabricated, fully developed models. Such a toolkit and

model repository might be of great use to other rubeTM model developers. In this thesis,






5


several reusable, generic, 3-D model components are developed during the creation of the

example OS task scheduler models. These components can be added to the toolkit and

could help other users build their own unique 3-D queuing networks and hybrid

synchronous/asynchronous models. The example OS task scheduler models themselves

can be added to the model repository. It is possible that future users could integrate these

models into a more comprehensive OS model.














CHAPTER 2
THE rubeTM PARADIGM


2.1 The Object-Oriented Physical MultimodelingTM System

In previous research, Cubert et al. [5], Fishwick [6], and Lee and Fishwick [7]

have worked on the development and implementation of an object-oriented simulation

application framework. Object-Oriented Physical Multimodeling (OOPMM) is a system

that is a milestone product of this previous research [5, 7]. OOPvMM extends object-

oriented program design through visualization and a definition of system modeling that

clarifies and strengthens the relationship of model to program [5]. The "physical" aspect

of OOPMM reflects a model design philosophy that recommends that models,

components, and objects should be patterned after the structure and attributes of

corporeal objects.

Within OOPMAM, programs are multimodels [6, 8, 9, 10]. A multimodel is defined

as a hierarchically connected set of dynamic behavioral models, where each model is of a

specific type and the set of models may be homogeneous or heterogeneous [5, 8]. The

basic dynamic behavioral model types are numerous and include Conceptual Model

(CM), Finite State Machine (FSM), Functional Block Model (FBM), System Dynamics

Model (SDM), Equation Constraint Model (ECM), Rule-based Model (RBM), Petri Net

(PNET), Queuing Net (QNET), and others [8]. OOPMM supports the creation and

execution of several of these model types including CM, FSM, FBM, SDM, ECM, and

RBM. The dynamic behavioral model types are freely combined in OOPMTM through the

process of multimodeling, which "glues together" models of same or different type [5].
6









The OOPMM system has some other noteworthy features. One feature is its 2-D

graphical user interface (GUI), which facilitates model design, controls model execution,

and provides output visualization [5]. Another feature is a model repository that

facilitates collaborative and distributed model definitions, and that manages object

persistence [5].


2.2 Heritage of rubeTM and Comparison with OOPMAM

OOPMM research evolved into research in rubeTM, and these two systems are

closely related inasmuch as they have nearly identical goals. They both make use of the

previously listed dynamic behavioral model types within a multimodeling framework.

The characteristics of rubeTM may be viewed as the extension of the characteristics of

OOPMM into the third dimension. One feature of rubeTM is a publicly available World-

Wide-Web (WWW) based toolkit composed of reusable, generic, 3-D model components

based on the basic dynamic behavioral model types. Another feature is a model

repository composed of fully developed models. The current programming language for

rubeTM is Virtual Reality Modeling Language (VRAL). Within rubeTM, models are

created in VRAL via a combination of a 2-D text editor and a 3-D geometry creation tool.

Overall, these characteristics approximate a start toward the programming holodeck

vision mentioned in Chapter 1.

There are some significant differences between rubeTM and OOPMFM. First,

rubeTM is implemented in a hybrid 2-D and 3-D environment, while the OOPMM system

is implemented in a 2-D environment. Second, rubeTM methodology and implementation

technologies are still in their formative stages. There is no full-fledged 3-D programming

GUI for rubeTM yet. Third, the consideration of metaphor will play a much greater role in









the development of rubeTM than it played in the development of OOPMfM. Finally,

rubeTM promotes the integration of modeling with visual and audible elements to

introduce an aesthetic aspect to models, whereas this was not a focus of OOPAM .


2.3 rubeTM's Development Environment

Model development within rubeTM is currently based on VRML. VRML is a

popular, non-proprietary, and portable 3-D language that is based on the concept of a tree

hierarchy of nodes. An approximation of generic and object-oriented programming can

be achieved through the use of a type of VRML node called PROTO (short for prototype)

and the use of a type of structure called ROUTE that can be conceptualized as a pipe that

connects structures to events. Code for behaviors of objects can be written in

ECMAScript, which is an ISO standard for the more commonly known JavaScript. Many

browsers for VRML worlds are freely available, such as CosmoPlayer and Blaxxun

Contact. These browsers allow the user to navigate through the 3-D world and examine

its contents. A prototypical VRML browser dashboard is shown at the bottom of Fig. 2.1.


: ..................... :: :'..'..:' :'',I ... :. ".:' .".: ." :::"::':: ".:'.. ".":: :" ... -'.


View Selector Seek Zoom Rotate Pan

Figure 2.1: Browser controls of CosmoPlayer 2.1.1.









Many 3-D geometry-authoring tools have been developed, such as CosmoWorlds.

These tools are appropriate for creating 3-D environments and objects, and often possess

a 3-D user interface. These tools also allow the user to model relatively simple behaviors

of 3-D environments and objects. Occasionally, these environments and objects are

endowed with the ability to interact with the user. Geometry, sound, light, color,

movement, and user interaction can be combined with these tools. The rubeTM

development environment can make use of such tools to create 3-D geometry and simple

behaviors that will be associated with rubeTM model components, as long as the tools can

export their output into VRML.

The rubeTM development environment currently uses standard 2-D text editors to

write VRML code. Most work performed in the creation of rubeTM models is carried out

within these 2-D text editors. The VRML code exported by the above-mentioned 3-D

geometry tools can be integrated with hand-generated VRML code produced in 2-D text

editors. However, there is currently no 3-D programming editor for building rubeTM

models/programs. The "dragging and dropping" currently performed is on 3-D objects

that have only geometric representation. Within rubeTM, there is no formal metaphor that

informs a 3-D syntax, nor is a set of 3-D representations of primitive data types and

operations available for use. The closest approximation that rubeTM possesses to a set of

primitive data types is the generic model component toolkit that is being developed,

which is based on the basic dynamic behavioral model types.

Ideally, one would like to be able to write a PROTO, place it in the toolkit, and

then later gain drag-and-drop access to that PROTO through a 3-D editing tool. Next, one

would like to connect ROUTEs, envisioned as 3-D pipes, between the different objects

and PROTOs in the 3-D programming editor. No such editor yet exists for rubeTM--it









remains to be developed. The example OS task scheduler models described in Chapter 4

were developed primarily in a 2-D text editor and in part within a VRML geometry

authoring tool. Thus, there is currently no direct translation of "visual thinking" into the

rubeTM development environment. However, this situation is expected to change with

time, and it is speculated that the basic ideas described in this research will be easily and

intrinsically applicable in making use of a 3-D programming editor when one is finally

developed.


2.4 The Steps of the rubeTM Modeling Methodology

The rubeTM modeling methodology proposed by Fishwick [2] consists of the

following five steps:

1. Choose system to be modeled: This could be anything from a system in the
real world (e.g., the Everglades ecosystem), to a typical software system
(e.g., database).

2. Select structural and dynamic behavioral model types: The structural and
dynamic behavioral model types to be used in designing the multimodel
are specified here. These include CM, FSM, FBM, SDM, and others as
previously listed. The dynamics and interactions between the different
models to be used are also specified here.

3. Choose a metaphor and/or an aesthetic style: For example, an
architectural metaphor may be chosen, and within architecture are many
different aesthetic styles to choose from like Romanesque, Baroque, and
Art Deco. As another example, painting metaphor may be chosen, and
there are many aesthetic styles of painting to choose from like Classical,
Cubism, Futurism, Surrealism, and others.

4. Define mappings/Develop analogies: When a metaphor and/or an aesthetic
style are chosen, a careful and complete mapping is created between the
structural and dynamic behavioral model type components and the
metaphorical and stylistic components.

5. Create model: Here, the models and mappings generated in the previous
steps are combined to synthesize the multimodel.

These steps will be demonstrated by example in Chapter 4 so that the process will


become clearer to readers.









2.5 rubeTM's Perspective on Metaphor

One premise that rubeTM is based upon is an extension of an idea developed in the

realm of human-computer interaction (HCI) [1]. This idea is that computer/user

interfaces should incorporate metaphors that are drawn from the real world [11, 12, 13].

Metaphors are often centered on corporeal objects. These corporeal objects are naturally

3-D, and so metaphors based upon them are 3-D metaphors. By extension, rubeTM

suggests that 3-D metaphor may be incorporated in M&P processes and model

visualization with some advantage [1].

To illustrate, a frequent occurrence during the development process is that one or

more abstract data types or functions are created. If a developer finds value in 3-D

visualization and would like to visualize an abstract function such as a sorter, he or she

may arbitrarily decide to visualize it as a green pyramid. Instead, it may be possible to

create a more elaborate visual metaphor for the sorter. For example, the developer might

be able to visualize the sorter as an animated person who is sorting boxes. If the

developer uses the animated sorting person, he or she has made an analogy between the

abstract sorter and the concrete, real-world person. Assuming that the sorter is visualized

in this fashion, there is no need to memorize the previous mapping of the green pyramid

to the sorter. The visualization of the person and the metaphor introduced now provide

this mapping implicitly. In effect, the visualization provides a semantic clue as to the

object's function. This sort of use of metaphor, then, may serve as a form of implicit

documentation. Additionally, the combination of metaphors and visualization may also

suggest potential module boundaries during the model design phase, since the real world

is made up of discrete objects, which the metaphors and visualizations are based upon. It

would be difficult to support the argument that the green pyramid visualization is









preferable to the animated sorting person on grounds other than the additional effort it

would take to produce the animated person. Finally, the extra effort required to produce

a 3-D metaphor visualization should decrease to a minimal level with time and advances

in technology, so that a cost/benefit analysis should eventually become favorable.

Traditional modeling and software development practices tend to subvert

metaphors, 3-D or otherwise. One mode of subversion is through the eventual neglect of

initial conceptual design tools. Such a tool could be a written block sketch of program

modules in which the relationships between modules may be described via metaphor

(e.g., "This outer ring is a gatekeeper that prevents intruders from gaining access to the

inner rings"). The exclusive use of text programming in implementation contributes to

the subversion of metaphor since there is no proper place for metaphor in program code

from a minimalist perspective--metaphor does not contribute to the execution of the code

by the computer. The minimalist urge also suggests that code documentation should not

address metaphor. Finally, programs are often not visualized during development or

execution, which precludes the visualization of metaphor.

Although visual programming environments may be somewhat more conducive to

the integration of metaphor, these typically are not designed with the use of metaphor in

mind, and the implicit nature of many metaphors makes them easy for developers to

ignore. This is an unfortunate situation since metaphor is central to language, cognition,

and diverse aspects of computer science. The rubeTM paradigm seeks, in part, to change

this situation by conceptually and visually integrating metaphors in M&P. Further,

rubeTM encourages developers to devise their own metaphors in accordance with the

observation that one of the main challenges in improving programming language

usability is providing metaphors that are appropriate for the user [14, 15].









The rubeTM paradigm allows a developer total freedom in the choice of metaphors

and sub-metaphors, and these need not necessarily be related to each other. This

freedom may lead to multi-metaphor constructions. The importance of this concept is

that a developer need not devise a single, over-arching metaphor that fits the system to be

modeled in every conceivable way. Neither is it necessary that the metaphors chosen

must be fully elaborated in a literal sense. In addition, rubeTM does not hold that

metaphor should be applied in all situations. It is unlikely that metaphor may be easily

applied to every object or process that can be modeled. It is also doubtful that all

modeling or programming constructs have a metaphor that is a "perfect fit." Finally,

there may often be no appropriate metaphors for the types of atomic operations that

developers traditionally deal with.

The flexibility that the developer has in choosing metaphors within rubeTM results

in a corresponding flexibility in the available modes of representation for models.

Traditionally, a data flow model is represented through the composition of simple

geometric shapes like rectangles, arrows, and circles. Mathematically oriented models

may require the use of special symbolic representations like dx/dt, characters in the Greek

alphabet, and etc. In contrast, rubeTM allows developers to create their own 3-D

representations that are based on the metaphors that they create. Although developers

have this flexibility, they are not required to take advantage of it. For example, if

developers do not generate metaphors and prefer traditional modes of representation for

models and programs, rubeTM allows users to generate appropriate 2-D geometry and text.

The incorporation of user-specified metaphor in rubeTM is based in part on the

idea that personal preference will continue to play a more important role in M&P. This

claim derives from the observation that media are turning away from broadcasting to a









more focused transmission [4]. The idea is cater to individuals without creating generally

palatable media [4]. An example of a similar trend in user interfaces is the current

proliferation of customized skinz in window-based GUIs. Presumably, users of skinz

choose these over GUI default settings because they find that the skinz fit their tastes and

are more aesthetically pleasing than GUI default settings. On a related note, Tractinsky

[16] found a very high correlation between perceived aesthetics of a user interface and a

priori perceived ease of use of the system. The renewed focus on accommodating the

individual in media and user interfaces suggests a corresponding accommodation of

personal preference in M&P. In turn, it is expected that this will lead to the increased

role of aesthetics in M&P.

The use of 3-D metaphor lends models aesthetic and artistic aspects that are

relatively novel in the realm of computer science. As some consider art to be one of the

highest forms of human expression, it would be a notable achievement to blend M&P

processes and model visualization with the creation of a work of art through the vehicle

of 3-D metaphor. An alternative course is to limit a virtual reality modeling/

programming environment to the creation of diagrams composed of abstract geometric

shapes and symbolic text. In essence, these shapes and text are wholly arbitrary forms of

representation. As such, they generally lack intrinsic conceptual content and have little

relation to humans' metaphorical communication and thought patterns. Additionally, the

generic nature of these shapes and text lessens their potential aesthetic impact. These

shortcomings may be ameliorated if a developer is allowed to embellish these generic

entities with customized 3-D metaphors. The rubeTM paradigm would provide developers

with such a framework.









2.6 rubeTM's Research Philosophy

A current focus of rubeTM research is to express the rubeTM modeling

methodology and justify it by demonstrating how it achieves specific goals that are novel

and unique, rather than to immediately justify it through HCI-type research. This is

because its focus is more on modeling research than on human-focused experimental

research. The rubeTM paradigm research philosophy does not diminish the importance of

such research (rather the opposite), but it does attempt to maintain a focus on modeling in

the face of the potentially significant distraction of HCI research. This perspective

ensures that research progresses in the area of model design and methodology. However,

one goal is to monitor and make use of past and future HCI research and thus achieve a

symbiosis.


2.7 rubeTM's Intended Audience

It is the position of this thesis that rubeTM, in its current implementation, is best

suited for use by individual developers in the creation of customized and executable

models. This is a similar but not quite identical audience as that for visual programming

languages (VPLs). Likewise, the general end uses of models developed via rubeTM

somewhat correspond to the general end uses of products generated via VPLs. However,

rubeTM has no accompanying formalized language for high-level design tasks--current

VRML tools do not function in this capacity. Users of rubeTM must, at a minimum, have

some general knowledge of multimodeling with the dynamic behavioral model types

besides a good grasp of VRML. Thus, this thesis further asserts that rubeTM is appropriate

for intermediate to expert developers.









It is important to distinguish the above audience from end users or consumers

(other than creators) ofprefabricated rubeTM models. For example, end users could be

introduced to novel systems via prefabricated rubeTM models. In this capacity, rubeTM

models might serve as instructional aids. Presumably, the effectiveness of rubeTM models

in fostering learning and understanding might be empirically measured and these results

could be compared with the results of other methods and models.

The evaluation of rubeTM models in an instructional capacity is not a focus of this

thesis. The first reason for ignoring this issue is the previously stated rubeTM research

philosophy. The second reason for ignoring this issue is that the individual creators'

customization of models that is an integral part of rubeTM philosophy is at cross-purposes

with consumption of prefabricated rubeTM models by others. Each time a user encounters

a new prefabricated model, it would come along with its own metaphor that the user

would likely need to understand. Furthermore, the model's creator would predetermine

this metaphor. Such a metaphor is not customized to maximize any particular

individual's understanding of the model, besides perhaps the model's creator. This

problem might be relieved by providing documentation of the metaphor with the model,

or through some type of social review process, but the basic need to accommodate the

new user individually would still not be ideally met. Predetermined metaphors may

possibly interfere with others' understanding and formation of proper inferences. At the

opposite end of the spectrum, the complete absence of metaphor in prefabricated models

would leave other users with little or no material for making inferences. Given the

complexity of these issues, this thesis will not address the instructional capacity of rubeTM

models in any significant detail.














CHAPTER 3
THE IMPORTANCE OF METAPHOR


3.1 Brief Survey of Metaphor Theory

According to the dictionary [17], metaphor is a figure of speech in which a word

or phrase literally denoting one kind of object or idea is used in place of another to

suggest an analogy between them. Metaphors are pervasive in everyday language--a few

examples: "swimming in money," "making a mountain out of a molehill," and "time flies

when you're having fun." However, the study of metaphor is not limited to its use in

language, and the simple definition for metaphor provided above belies the complex and

contentious nature of the volumes of active multidisciplinary research that is devoted to it

[18]. The study of metaphor brings together research in linguistics, philosophy, artificial

intelligence, and cognitive science [19].

This thesis will use a modified working definition of metaphor proposed by Veale

[18]. Defined: metaphor is the act or process of denoting one concept (in modeling

terms, the target) with a sign conventionally tied to another (in modeling terms, the

source). Remarkably, the word paradigm derives its etymology from the Greek word

paradeiknynai: to show side by side [17]. Thus, there is some parallel between the two

terms and this thesis sometimes liberally addresses the presence of metaphor within

constructs that are traditionally referred to as paradigms.









3.1.1 The Literalist/Figuralist Debate

According to Veale [18, 19], theories concerning the phenomenon of metaphor

can be roughly classified into Literalist and Figuralist positions relative to debate on the

following question: What is the nature of literal meaning (if it exists at all), and what is

its relation to figurative meaning as a basis of convention in semantics? Answers to this

question commonly raise related questions, like "How involved is metaphor in

cognition?" and "Is metaphor necessary for linguistic expression?" [19].

3.1.1.1 Literalist tenets

Literalists generally hold that metaphor is a rhetorical device grounded in

linguistics and lexical semantics, rather than conceptual representation and knowledge of

the world [18, 19]. The benefits that metaphor provides are not very important, and

metaphor cannot alter the way humans cognitively structure concepts and thereby

structure new knowledge and experience [18, 19]. Metaphor can be decomposed into

literal primitives in both language and cognition, and so metaphor is unnecessary [18,

19].

3.1.1.2 Figuralist tenets

Figuralists generally hold that metaphor is a natural element of both language and

cognition that is compatible and complementary with our ideas of literal meaning [18,

19]. Metaphor plays an important role in the organization of our conceptual system and

memory [18, 19]. It helps shape our experiences and perceptions of the world [18, 19].

Many metaphors are drawn from our sensory experience of external reality, and much of

our knowledge conforms to objects and events in the real world [18, 19]. Metaphors

create a relationship between this sensory knowledge and symbolic information [18, 19].

Metaphor cannot always be decomposed into literal primitives in language or cognition,









and so metaphor provides a necessary and irreplaceable service [18, 19]. It is central in

language and creative thought [18, 19]. Metaphor allows us to understand the causal

mechanics of an unfamiliar or underdeveloped domain in the terms of another domain

that is more familiar or developed [18, 19].

3.1.2 Discussion

Unfortunately, a more detailed address of metaphor theory is beyond the scope of

this thesis. There are significant, ongoing philosophical and logical arguments on both

sides of the Literalist/Figuralist debate. Respected philosophers and researchers can be

found on both sides of the issue. For example, writings on the subject by Aristotle, John

Searle, Andrew Ortony, and Dedre Gentner generally support Literalist views, and

writings by Friedrich Nietzsche, Max Black, and George Lakoff generally support

Figuralist views [19]. However, philosophers and researchers may not adopt certain

views wholeheartedly and may subscribe to one or more sub-positions from the opposing

side, so that neat categorizations of bias are generally impossible [19]. Perhaps

surprisingly, there is little empirical evidence that strongly supports the perspectives of

either position. As a result, there is little consensus on the nature of the metaphor

phenomenon.

The adoption of either a Literalist or Figuralist position has important

implications for rubeTM. Literalist perspectives generally imply that metaphor is

peripheral, reducible, unnecessary, and unimportant in both language and cognition.

Such views are hostile to the idea of incorporating metaphor in M&P processes and

model visualization. On the other hand, Figuralist views are much more "metaphor

friendly," and lend support to the idea of incorporating metaphor in M&P processes and









model visualization. The weight of intuitive arguments seems to favor Figuralist views,

but the value of these intuitive arguments is a matter of "faith." In defense, Veale [18]

makes a forceful philosophical and classical logic-based argument in favor of Figuralist

perspectives.


3.2 Metaphor and Analogy in Cognition

An experimental study by Ottati et al. [20] showed how metaphors influence

communication and attention processes. For example, if people have a general interest in

sports, they pay significantly more attention to information presented in terms of sports

metaphors, regardless of the information content.

Even though metaphor and analogy may be considered to be distinct and separate

entities, an obvious byproduct of metaphor is the suggestion of analogy. The process of

analogy is that of applying previously gathered knowledge in new situations. Analogy is

involved in learning and reasoning [21], and it has been suggested that analogy is a

fundamental cognitive process [22]. For these reasons, analogy has been an area of

interest in cognitive science.

Gentner and Gentner [23] conducted empirical experiments that tested the

hypothesis that analogies are used in generating inferences (i.e., the generative analogy

h1ypohl,,\i), as opposed to the hypothesis that thought processes proceed independent of

analogy and that analogies simply provide a convenient terminology for the results of the

process (i.e., the surface terminology hypothesis). In these experiments, the participants

framed the domain of electricity with "flowing waters" and "teeming crowds" metaphors

and analogies [23]. It was found that people use analogies to help structure unfamiliar

domains and also that the generative analogy hypothesis was supported [23].









Again, the importance of metaphor and analogy in cognition has implications for

rubeTM. The view that metaphor and analogy are central and important to cognition

supports the idea that these may provide some benefit in M&P processes and model

visualization. The brief review of metaphor and analogy in cognition provided here is

intended to provide only general support for speculations that the use of metaphor and

analogy in rubeTM might provide some cognitive benefits. Some more specific support

for the potential cognitive benefits of the use of metaphor in the rubeTM modeling

methodology is detailed elsewhere in this thesis.


3.3 Metaphor in Computer Science

3.3.1 Empirical Measurement of the Usefulness of Metaphor

The empirical measurement of the usefulness of metaphor in user interfaces and

programming (visual or otherwise) is a contentious issue in a wide variety of research

literature [24]. The general lack of consensus on the nature and function of metaphor

contributes to this problem. Since there are several perspectives on the metaphor

phenomenon, the empirical measurement of the effects of metaphor in any domain

becomes a non-trivial task. To further complicate matters, there are several different

ways to define usefulness in computer science. For example, productivity is only one of

many possible measures of usefulness.

Empirical results that demonstrate the usefulness of metaphor in computer science

are mixed. Blackwell and Green [25] investigated the effect of metaphor on visual

language usability and found that metaphor had little effect. Blackwell [24] found that

intuitive, optimistic expectations of the effectiveness of metaphor in diagrams, user

interfaces, and programming are not well supported by empirical studies. Specifically,









Blackwell [24] found that the benefits of using metaphors seem marginal at times, and

positive effects may be attributable to other factors, such as direct manipulation of icons

or the effects of using "plain" diagrams (i.e., those without associated metaphors).

However, Blackwell [24] also found that the use of metaphor in diagrams provides some

mnemonic assistance, which appears to be greatest when the user of the diagram

constructs his or her own metaphor. This finding is easily and naturally extended to

include the integration of user-specified metaphor in 3-D M&P processes and model

visualization, because models very often possess a significant diagrammatic component.

This result has some bearing on the use of metaphor in rubeTM, since users of rubeTM

devise their own metaphors during model development and visualization. Presumably,

developers understand their own metaphors better than other metaphors that are forced

upon them. This leads to the speculation that users of rubeTM will have improved

memory retention of the models and programs that they create. However, this thesis does

not empirically measure this speculated benefit.

Since the "metaphor usefulness issue" is complex and still open, a researcher

might instead pursue the question: "Can it be shown that the use of metaphor doesn't

hurt?" It has been claimed that some commonly used metaphors in computer science do

not fit well, and so these metaphors cause people to draw incorrect analogies [26]. Some

empirical findings suggest that the use of concrete representations can limit the formation

of abstractions in learning how to program [27]. However, there does not seem to be

enough empirical evidence to support the strong claim that the use of metaphor in

diagrams, user interfaces, and programming has significant detrimental effects.

Importantly, this claim is predicated on the assumption that predetermined metaphors are









imposed upon users. The rubeTM paradigm is somewhat immune to such a claim--since

users of rubeTM construct their own metaphors, it seems obvious that the same users

should understand the metaphors that they create and have some idea about the possible

shortcomings of their metaphors. The potential for detriment may arise when these

metaphors are imposed upon others.

3.3.2 Metaphor in Computer Modeling and Paradigms

Several computing paradigms have significant grounding in metaphor. These

metaphors often guide problem representation, design, and implementation efforts within

these paradigms. As such, the metaphors permeate the paradigms. For example, the

artificial neural network [28], evolutionary computing [29], and swarm-based computing

[30] are three computing paradigms that are inspired and permeated by biological

metaphors. The metaphors that permeate data flow and agent-based computing [31],

which are touched upon elsewhere in this thesis in some detail, are described below.

3.3.2.1 The data flow metaphor

Data flow is a fairly common computing paradigm for designing and

diagrammatically representing programs. A data flow diagram is a network

representation of a system that depicts data sources, data sinks, data storage, and

processes performed on data as nodes. In such a diagram, the logical flow of data is

depicted as links between the nodes. Data flow diagrams show all possible data paths

through the system. One metaphor at work in the data flow paradigm might be: "The

network is a system of locations and connecting pipelines." Corollary metaphors might

be: "Data is water" and "A link is pipelinee"









3.3.2.2 The agent metaphor

The term agent is used to describe a broad range of computational entities, and

agent-based computing is a model of computation based on agents. Since there is no

agreed-upon, formal definition for the term agent in a computational context, a functional

definition is provided here through a review of the various characteristics and abilities

that have been used to describe agents in research literature. Some of these

characteristics and abilities include [31, 32]:

the autonomous representation of another entity,


the ability to communicate, interact, and collaborate with other entities,


the ability to perceive, move through, react to, and alter a complex, dynamic

environment,


the ability to reason, learn, and adapt, and


the ability to take initiative in pursuing goals.


Agent-based computing is guided by the agent metaphor: "An entity is an agent."

A cursory comparison of the characteristics of an agent with some of the defining

functional characteristics of a typical human being will reveal that the list could have

been entitled "Some defining functional characteristics of a typical human being," and

readers should not have noticed the difference. A brief survey of agent literature reveals

that the functions of agents are commonly analogous to the functions of human beings in

the real world. Thus, it is a simple matter to metaphorically equate agents with human

beings, and so consider agents to be anthropomorphic entities.









A workshop in Dagstuhl, Germany [33] explored a number of issues regarding the

relationships between agents and M&S (modeling and simulation). A simple use of

metaphor demonstrates a connection--let the agents be human in appearance and in

action. Let this metaphor be called the fl-uthetic human agent metaphor and let such

agents be called nuthetic- human agents [2]. At least one commercial agent development

company, ReyesWorks (http://www.reyes-infografica.com/), has incorporated a yuthetic/

human agent metaphor in its agent development and visualization tools. Another

company, Blaxxun Interactive (http://www.blaxxun.com/), currently operates Cybertown

(http://www.cybertown.com/) in which human users and their autonomous bots possess

avatars that interact with each other within a 3-D virtual world.


3.4 Metaphor in 3-D Programming

Two goals of 3-D programming are to represent program execution with 3-D

graphics [34] and to enable the user to program using executable 3-D graphics. A brief

review of two approaches to this problem, along with their use of metaphor, is given

below.

3.4.1 CUBE

Najork's [35] CUBE is an example of a 3-D visual programming language that

has a 3-D syntax. In CUBE, programs consist of an arrangement of 3-D shapes instead of

a linear stream of text [35]. The language is divided into two fragments [35]. The first

fragment consists of predicate definitions and logic formulas, and the second fragment

consists of type definitions and type expressions [35]. 3-D cubes represent terms and

atomic formulas in the logic fragment [35]. Pipes connect the arguments of predicate

applications (i.e., atomic formulas), forming a data flow diagram [35]. The third









dimension is used to group various 2-D diagrams together [35]. The prototype

implementation of CUBE functions by translating 3-D visual programs into a text format,

and then operates on the text format [35].

CUBE does not make extensive use of metaphor. However, it does make use of

the data flow metaphor on a high level and as a guiding paradigm for the representation

of the language [35]. As described above, this metaphor also extends into the third

dimension. Unlike rubeTM, the user of CUBE has no flexibility to create or visualize his

or her own metaphors within the CUBE environment.

3.4.2 Toon TalkTM

A recent trend in the programming by demonstration (PBD) community has been

to extend into the 3-D programming language arena [36, 37]. Kahn's [36] Toon TalkTM is

a PBD system designed for children in which a programmer is a character in an animated

virtual world in which programming abstractions are replaced by tangible analogues.

Data structures are given 3-D geometry, such as a box with holes, into which different

objects may be placed [36]. Birds and nests perform send and receive operations [36].

Robots are guarded clauses that are trained to perform actions when they receive boxes

[36]. The programmer may generalize robots by using a vacuum cleaner to remove

details from the robots' guard clauses [36]. It can be seen here that Toon TalkTM makes

use of visual metaphor. However, unlike rubeTM, the users of Toon TalkTM do not have

the ability to create or visualize custom metaphors.














CHAPTER 4
EXAMPLE APPLICATION OF METAPHOR IN THE rubeTM PARADIGM

Here, the practical application of metaphor in rubeTM is demonstrated through the

synthesis of example models. It was decided that the example models should be

complex, yet familiar to expected readers of this thesis. Models meeting these criteria

should best demonstrate the application of metaphor in rubeTM. Though there are many

choices that meet the familiar and complex criteria, the focus here is on the OS as a

generic type. The example models are based on a greatly simplified OS task scheduler.

These models are represented with metaphors and 3-D visualization, and are among the

very first to be formally developed according to the rubeTM modeling steps.


4.1 Step 1: Choose System to be Modeled

The first step in the rubeTM modeling methodology is Choose system to be

modeled (see Chapter 2). In accordance with this step, a MINIX-like OS is selected as

the system to be modeled [38]. This OS can be structurally characterized by hierarchical,

vertical layers (top to bottom) [38]:

1. user processes (e.g., word processor),

2. server processes (e.g., file system),

3. I/O tasks (e.g., disk), and

4. process management (e.g., scheduling and communication).









A graphical representation of these layers can be seen in Fig. 4.1. The example model

focuses on the process management layer of the OS, and specifically upon a hypothetical

task scheduler within that layer.




User Processes (e.g., word processor)
Server Processes, (e.g., file system, memory manager)
I/O tasks (e.g., disk, terminal, clock, system, ethernet)
Process Management


Figure 4.1: Graphical representation of the vertically layered structure of a MINIX-like
OS.



The example task scheduler is a non-preemptive, dynamic priority scheduling

system that contains tasks, four priority queues, and the following five types of physical

devices with their associated queues:

1. CPU,

2. DEV (i.e., external device)

3. COM (i.e., communication, such as via the parallel, serial, and USB
ports),

4. MEM (i.e., memory load/store), and

5. I/O (i.e., input/output, such as disk read/write).


4.2 Step 2: Select Structural and Dynamic Behavioral Model Types

The second step in the rubeTM modeling methodology is Select structural and

dynamic behavioral model types (see Chapter 2). In accordance with this step, a formal

CM is created that serves as a high-level structural model:

1. The OS is composed of layers.









2. User processes, server processes, I/O tasks, and process management are
types of layer.

3. The process management layer is composed of the task scheduler.

4. The task scheduler is composed of devices, tasks, and queues.

5. CPU, DEV, COM, MEM, and /O are types of device.


I


Figure 4.2: A Conceptual Model of the hypothetical OS.



The CM is shown graphically in Fig. 4.2, where the lines with a square superimposed

denote the composition relation and lines with a circle superimposed denote the is a









relation. It is also possible to include in this CM the following two relations, which were

left out for the purpose of maintaining clarity:

1. CPU, DEV, COM, MEM, and IO are types of task, and

2. CPU, DEV, COM, MEM, and I/O are types of queue.

This CM obviously does not capture all the different components of the OS, as it is only

meant to model specific aspects of the system for the purpose of the example. Indeed,

many other CMs are possible and this is just one of them.

To this point, an adequate formal structural model has been developed for the OS

layers. Continuing with the second step of the rubeTM modeling methodology, more

detailed dynamic behavioral models for the task scheduler are developed. The task

scheduler is modeled as a complex QNET, with clients, queues, and servers. The

"physical" layout of the task scheduler QNET is given in Fig. 4.3.




Voids area serves as a "stubbed out communication point" between the task






represent paths for tasks. -- '
--










area." This area serves as a "stubbed out communication point" between the task









scheduler and other components of the OS. Conceptually, the Void area is a portal where

tasks that have finished completion leave (or disappear from) the task scheduler, and new

tasks enter the task scheduler. In an actual system, other regions of the OS would

generate tasks, these tasks would be "passed" to the task scheduler, and the work

performed by the task would be "passed" back to the originator of the task. The Void

area is conceptualized as a clearinghouse for this activity.

Next, a model is developed for the state of activity of each task within the

scheduler. These states are running, waiting, and ready, and will be modeled with a

FSM. However, the ready state only applies in a preemptive scheduling system, while

the example system is non-preemptive. An in transit state is substituted for the ready

state, based on the presumption that it will take some finite amount of time for tasks to

travel from devices to queues in the example model implementation. The task activity

FSM is shown in Fig. 4.4. It has the states running/waiting/in transit and the arrows

denote the possible state transitions.


Waiting I Running





In Transit

Figure 4.4: The task activity FSM.



To complete the second step in the rubeTM modeling methodology, the formal

relationships between the models must be specified. The CM primarily provides overall

structure and has little computational value in the current example, so there are few

formal computational relationships to be specified in relation to it. One relationship is









specified between the layers of the OS concerning communication--it is proposed that the

layers will communicate with each other via message passing. This communication

arrangement is not a focus of the current example, and will be addressed in a little more

detail later in the discussion. In general, communication between layers of the OS can be

considered as "stubbed out for future development."

To begin, assume that each task is an individual and maintains its own state

information concerning its task type (i.e., CPU, DEV, COM, MEM, or I/O), CPU run

time left (if this is a CPU task), task priority, and running/waiting/in transit activity

information. Contrast this arrangement with having information like this stored in some

centralized table as in a typical OS implementation. The state information carried around

by each task can be accessed and modified by other components of the task scheduler.

One reason for designing tasks to have individual identities and for letting them carry

around their own state information is that a task is envisioned as an object in the classic

object-oriented sense. A second reason is to maintain the object-oriented physical

modeling philosophy that is the legacy of OOPMTM. In future steps, an analogy will be

made between a task and a person--a person is a physical object. More specifically, an

analogy will be made between a task and a .yn/heii. human agent. However, a careful

reader will note that the metaphor and analogy steps of the rubeTM modeling methodology

have not been executed yet, and so the author of this thesis should be theoretically

"blind" to these future steps at this point. This thesis will have more to say about this

seeming anomaly in step order later.

Now the relationship between the QNET, the tasks and their activity FSMs, and

the devices must be specified. A basic operational sketch produced by following a task









through the scheduler should suffice to specify the relationships among components.

First, a task is "generated" inside the Void area and its task type, CPU run time (if this is

a CPU task), priority information, and state of activity FSM are set. The task type and

run time data are randomly generated according to some distribution, but all tasks start

out with the highest priority. When the task leaves the Void area, the task enters the

scheduler and travels to the first priority queue leading to the CPU. Eventually, this

queue sends the task to the CPU. The CPU then finds out what type of task this is by

reading the task's internally stored task type and CPU run time information. The task

gets service from the CPU if the task is a CPU task. The CPU determines how many

quanta of time to spend serving the task depending on the task's priority. If these quanta

are expended before the remaining service time for the task is expended, the CPU

temporarily stops serving that task. The CPU then assigns the task a successively lower

priority, updates the remaining service time field inside that task, and sends the task to

the appropriate priority queue. If the remaining service time for the task is expended

during the CPU service quanta, the task is sent from the CPU to back to the Void area. If

a task arrives at the CPU and it is not a CPU task, the CPU immediately sends the task to

the appropriate peripheral device queue (i.e., DEV, COM, MEM, or I/O queues). When a

non-CPU task arrives at its device (i.e., DEV, COM, MEM, or I/O devices), the device

randomly decides on a total service time for that task according to some distribution.

When the task's total service time is expended, the task is sent back to the Void area.

Next, the relationship between a task activity FSM and the task scheduler

components needs to be specified. The following explains the operation of a task's

activity FSM:









1. When a task enters a queue of any sort, that queue sets the task's activity
FSM to the waiting state.

2. When a task leaves a queue of any sort, that queue sets the task's activity
FSM to the running state

3. When a task leaves a device of any sort, that device sets the task's activity
FSM to the in transit state.

The unidirectional state changes shown in Fig. 4.4 are enforced by the fact that tasks

always follow a repeating pattern of travel along a path enter a queue get service from

a device travel along a path enter a queue, etc.


4.3 Step 3: Choose a Metaphor and/or an Aesthetic style

The third step of the rubeTM modeling methodology is Choose a metaphor and/or

an aesthetic style (see Chapter 2). This is a step in which freedom and subjectivism can

play a great role, and the metaphors chosen below are not the only possible metaphors

that can be chosen. The architectural metaphor, %yinheric human agent metaphor (see

Chapter 3), business workflow metaphor, and traffic light metaphor are chosen for this

example. The best place for discussing these metaphors is in the following step.

Readers may be troubled by the seemingly arbitrary selection of the metaphors

listed above. According to the current rubeTM modeling steps, an arbitrary selection of

metaphors is permitted. However, the metaphors in this example are not arbitrarily

chosen. The metaphors are chosen with a view toward the development of mappings and

analogies in the next step. Again, there is a seeming anomaly in step order that will be

addressed in more detail later.









4.4 Step 4: Define Mapping/Develop Analogies

The fourth step of the rubeTM modeling methodology is Define mapping/Develop

analogies (see Chapter 2). Here, a complete mapping is created between the structural

and dynamic behavioral model type components and the metaphors that have been

chosen. First, the architectural metaphor is explored. Next, the .y)nhetic human agent

metaphor and business workflow metaphor are explored. Finally, the traffic light

metaphor and other minor metaphors involved in the example are discussed.

The sort of vertically layered structure of a MINIX-like OS lends itself naturally

to an architectural metaphor, where the OS itself may be visualized as a building with an

Art Deco aesthetic applied, as shown in Fig. 4.5. Here, the architectural metaphor

figuratively serves as a structural model for the vertically layered hierarchy. The layers

of the OS then correspond to the different floors of the building, as shown in Fig. 4.6.








Operating
System Building


Figure 4.5: Metaphor mapping between operating system and building.


























One layer One floor of
of the OS the building


Figure 4.6: Metaphor mapping between a layer of the OS and a floor of the building.


In the present example, synthetic human agents are created that act as

representatives of OS tasks inside the simplified task scheduler. These entities may be

considered to be agents inasmuch as they:

1. serve as semi-autonomous representatives of another entity (i.e., they are
subtasks of a higher-level task that does not exert direct control over
them),

2. communicate and interact with the queues and devices in the task
scheduler, and

3. move through, react to, and alter the task scheduler environment (which is
somewhat complex and dynamic).

However, it is stressed that that the agents in the OS task scheduler example are not

perceptive, intelligent, or adaptive. Neither do these agents take initiative in pursuing

goals. The mapping between task and synthetic human agent is shown in Fig. 4.7.


mmmi















Synthetic
Task Human
Agent







Figure 4.7: Metaphor mapping between task and synthetic human agent.



As previously stated, the primary mode of communication between the layers of

the example OS is message passing. Continuing with the .yIntheiik human agent

metaphor, a mapping is developed between the mechanism of message passing and a

courier agent transporting a briefcase that contains a message, as shown in Fig. 4.8.

Since this aspect of the example OS was not actually developed, there is no picture in the

figure.


Courier
Message Agent
Passing Transporting
Briefcase


Figure 4.8: Metaphor mapping between message passing and courier agent with
briefcase. Picture of mapping not shown because this aspect of the example OS has not
been implemented.



The business workflow metaphor is an extension of the %yInthetic human agent

metaphor. In the business workflow metaphor, agents operate in a dynamic micro-world

common to agents that is envisioned as a business workplace. This metaphor can be









mapped to any model, process, or procedure whose elements involve queued entities,

resources, and paths [2]. The business workflow metaphor provides the foundation for

the mappings between queues, resources, and paths, and the translation of these into a

physical, 3-D space according to the layout in Fig. 4.3. In accordance with the synthetic

human agent metaphor and business workflow metaphor, a mapping is created between

an OS device and an agent standing behind a desk, called a service facility, as shown in

Fig. 4.9. Next, a mapping is created between the OS device queues and waiting lines, as

shown in Fig. 4.10. Lastly, paths between the devices and queues are directly mapped

into the 3-D space. Agents will travel over paths between the devices and queues.



OS device



Agent standing
behind a desk
(service facility)



Figure 4.9: Metaphor mapping between an OS device and an agent standing behind a
desk (service facility).


Figure 4.10: Metaphor mapping of a waiting line to a device queue.









The final mapping to be created is between the running/waiting/in transit task

activity FSM and the traffic light metaphor. In this mapping, the states and transitions of

the task activity FSM are mapped with the states and transitions of a traffic light FSM.

The mapping is shown in Fig. 4.11.

Task activity FSM Traffic light FSM

WTR RTG
Waiting WR Running Red light G Green light


TTW\ /RTT YTR\ /GTY

In Transit Yellow light


"I -I I- I :ii ,: :l i 1 1 1''1..

Task t" T: '-. Task i' : :::'
'1 i i. J [ ; l h.-1\/i '""1 .' ]


-,r -I T'.7 I- .



Figure 4.11: Task activity FSM, traffic light FSM, and state and transition mappings
between the two FSMs.




4.5 Step 5: Create Model

The fifth step in the rubeTM modeling methodology is Create model (see Chapter

2). Here, the models, metaphors, and mappings generated in the previous steps are

combined to implement the example OS task scheduler in a 3-D environment. In the

context of VRAML, PROTOs are created for each of the items in the task scheduler that will

be used again and again. A VRML convention for naming PROTOs is to fully capitalize

the PROTO name, e.g. MYPROTO. The author of this thesis created the following









PROTOs for use in the example OS task scheduler model, except for MFACTORY and

PATH, which the author significantly modified:

1. PERSON,

2. CPUFACILITY,

3. FACILITY,

4. QUEUEMANAGER,

5. RANDOMIZER,

6. FACTORY, and

7. PATH.

PERSON is a synthetic human agent and is the manifestation of a task (see Fig. 4.7).

CPUFACILITY and FACILITY are manifestations of service facility (see Fig. 4.9). The

CPU has special management functions, so it is given its own CPUFACILITY PROTO.

All devices besides the CPU are instances of the generic FACILITY. When a PERSON

reaches a FACILITY, it is held there for some random amount of time to simulate

service and then it is released. QUEUEMANAGER is the manifestation of a waiting line

(see Fig. 4.10). Instances of QUEUEMANAGER will manage each of the priority queues

and the queues leading to each of the service facilities. RANDOMIZER randomly sets the

fields of the persons to specific task types and assigns them a CPU run time if necessary.

MFACTORY generates people (tasks) dynamically. Instances of PATH connect the

devices together physically and manage the movement of persons throughout the world.

Each of the PROTOs mentioned above, except RANDOMIZER and MFACTORY,

has a physical geometry node included inside that will give it an identifiable and

appropriate physical presence in the 3-D environment. Some of these physical geometry









nodes are modeled in a 3-D authoring tool prior to their inclusion in the PROTOs. For

example, instances of PERSON look like a stylized version of an actual person, the

geometry of which is modeled in CosmoWorlds. These appearances are according to the

metaphors that are being used. RANDOMIZER's and MFACTORY's logical and functional

location in the 3-D OS task scheduler is inside the Void area where tasks are created and

their attribute fields are set. However, these two PROTOs have little to do with the

metaphors that have been chosen and merely serve as hooks for the future addition of

other components. As such, it is not necessary for them to have a physical presence in

the world, and therefore they have no geometry associated with them. If desired,

geometry could be added to them later.

Some items of note within the PROTOs are the attribute fields they include in their

declarations. For example, the PERSON PROTO has the fields

task type (one of CPU, DEV, COM, MEM, or I/O),


CPU run time left (only relevant if this is a CPU task), and


task priority (from 1 through 4, where 1 is highest).


The implication here is that each instance of PERSON is an object in the task scheduler

and carries its own state information, which can be accessed and modified by other

components of the scheduler. Other instances of PROTOs have similar ways of utilizing

attributes. A partial listing of PROTO declarations developed for this thesis and used in

the creation the OS task scheduler model is given below:

PROTO PERSON
[
exposedField SFString task type
exposedField SFInt32 task cpu run time












exposedField
eventIn
eventIn
eventIn


SFInt32
SFBool
SFBool
SFBool


task priority
running
transit
waiting


PROTO CPUFACILITY


cpu facility
cpu_facility
servicetime
servicetime
servicetime
servicetime
task arrival
input queue _
input queue ;
input queue 3
input queue 4
input queue 1
input queue ;
input queue
input queue 4
output queue
output queue
output queue
output queue
get task fron
get task fron
get task fron
get task fron


field
field
field
field
field
field
eventIn
eventIn
eventIn
eventIn
eventIn
eventIn
eventIn
eventIn
eventIn
eventIn
eventIn
eventIn
eventIn
eventOut
eventOut
eventOut
eventOut
eventOut
eventOut
eventOut
eventOut
eventOut
eventOut
eventOut
eventOut
]


SFString
SFNode
SFInt32
SFInt32
SFInt32
SFInt32
SFNode
SFBool
SFBool
SFBool
SFBool
SFBool
SFBool
SFBool
SFBool
SFBool
SFBool
SFBool
SFBool
SFBool
SFBool
SFBool
SFBool
SFNode
SFNode
SFNode
SFNode
SFNode
SFNode
SFNode
SFNode


name "NoName"
geometry NULL
quantumpl 10
quantump2 20
quantump3 30
quantum p4 40


-_empty
_empty
empty
empty
-full
full
!full
full
1 full
2 full
3 full
4 full
iinput
iinput
iinput
iinput
input_
input(
input_
output
output
output
output
output


queue
queue
queue
queue
queue_
queue_.
queue_
queue
queue
queue
queue
queue


PROTO FACILITY


SFString
SFNode
SFInt32
SFInt32
SFNode
SFBool
SFBool
SFBool
SFNode


facilityname "NoName"
facility_geometry NULL
min random service time
max random service time
task arrival
input queue 1 empty
output queue 1 full
get task from input queue 1
send task to output queue 1


]

PROTO QUEUEMANAGER

field SFString queuemanagername "NoName"


send
send
send
send
send
send
send
send


task
task
task
task
task
task
task
task


field
field
field
field
eventIn
eventIn
eventIn
eventOut
eventOut







43


field SFNode queuemanagergeometry NULL
field SFInt32 capacity 10
eventIn SFBool send task
eventIn SFNode task arrival
eventOut SFBool is empty
eventOut SFBool is full
eventOut SFNode taskdeparture
]

PROTO RANDOMIZER
[
field SFString randomizer name "NoName"
field SFNode randomizer geometry NULL
field SFInt32 cpuminruntime 120
field SFInt32 cpu max run time 9
eventIn SFNode task arrival
eventOut SFNode task departure
]

PROTO FACTORY
[
field SFBool initiallyrunning TRUE
eventIn SFBool start
field MFString name "mover factory"
field SFVec3f position 0 0 0
field SFInt32 howMany 1
eventIn SFTime setMoverPace
eventOut SFNode aMover
eventOut SFBool stop
]

PROTO PATH
[
field SFString name "NoName"
field SFVec3f origin 0 0 0
field SFVec3f destination 0 0 0
field SFColor rug 0.2 0.5 0.8
field SFFloat visibility 0.0
eventIn SFNode arrive
eventOut SFNode depart
]


A task activity FSM is placed inside each person that reflects the associated task's

current state: waiting, running, or in transit. In the VRML implementation, the user of

the simulation is able to zoom in on any particular person and see through that person's

transparent skin into the person's chest, where the task activity FSM is shown

progressing through its various states, as shown in Fig. 4.12. In addition to the task

activity FSM changes that can be viewed, the color of a person's skin changes to the










color assigned to each state using the traffic light metaphor: (1) waiting--red, (2) running-

-green, and (3) in transit--yellow.











i:,







Figure 4.12: A task's internal FSM with the In Transit, Waiting, and Running states. The
task shown is being serviced at the CPU.



Next, the components of the OS task scheduler are physically arranged in the

VRML 3-D world. An overhead schematic of the task scheduler physical layout is given

in Fig. 4.3 and is shown in its VRML implementation in Fig. 4.13.



















Figure 4.13: Top view of the task scheduler. The CPU facility is shown at top center,
with its priority queues just below and to the left of it. DEV, COM, MEM, and I/O
service facilities are on shown on the right, top to bottom respectively, with queues to the
left of each.
ami {:
M:: 7

MM,'.r..









When the objects of the task scheduler have been physically arranged in the

environment, a static representation of the example task scheduler has been developed.

The next job is to make the task scheduler function dynamically and in an animated

fashion. This is accomplished in VRML through the occurrence and utilization of events.

Events are generated and sent through ROUTEs to their destinations.

Recall that instances of PATH connect the devices together physically and manage

the movement of persons throughout the world. Note that PATH is a metaphor in the

following respect: it has a parallel function as that of a ROUTE. PATH physically

transports movers through the world in a like manner as ROUTE transports events through

the world. Fig. 4.14 shows an example mapping of a ROUTE structure to a use of PATH

for transporting a task from a queue to a service facility. PATHs are given physical

geometry that can be turned on or off by the user.

PATH
Queue.send-task Facility.task arrival



ROUTE Nd2vet
Nodel.eventOut Node2.eventIn

Figure 4.14: Metaphor mapping between PATH and ROUTE.




4.6 Operation

When the program is initialized, MFACTORY generates 10 tasks inside the Void

area. Person/tasks have internal accounting abilities--they are individuals, and maintain

their own task type, remaining run time, and priority information, which are utilized

especially by the RANDOMIZER and CPUFACILITY. The 10 tasks move along a path to









the RANDOMIZER, where the tasks' fields are set. The RANDOMIZER begins with a

50/50 probability of assigning a task as a CPU task vs. another device task. Later, the

user that views the model can alter these probabilities using a heads-up display (HUD).

The initial task probability weightings are (1) CPU = 20, (2) DEV = 5, (3) COM = 5, (4)

MEM = 5, and (5) I/O = 5. No control over CPU weight is given to the user from the

HUD since changing the weights of the devices uniformly is equivalent to changing the

weight of CPU task probability. If a task is a CPU task, the RANDOMIZER also

randomly assigns the task a CPU service time that the CPU will need to dispatch that

task. Fields in the RANDOMIZER declaration determine the randomization of CPU task

service time, so the simulation user has no control over it from the HUD. If a task is

something other than a CPU task, it is assigned a service time of zero (i.e., the CPU will

send it on its way to the appropriate device immediately upon arrival at the CPU).

All tasks start out with a priority of (1 = highest) upon leaving the RANDOMIZER

in the Void area. When a task leaves the Void area, it enters the first priority queue

leading to the CPU. All queues, including the CPU priority queues, are managed by

instances of the QUEUEMANAGER PROTO, which send out waiting tasks upon requests

from the CPU and devices.

When a task reaches the CPU, if the task is a CPU task, it gets service from the

CPU. A backbeat soundtrack plays as the CPU is serving a task. The CPU determines

how much time to spend servicing the task as follows: Priority 1 tasks are given 10

seconds, which is the priority 1 time quantum. If this quantum is expended before the

total service time for the task is complete, the CPU assigns the task a priority of 2,

updates the remaining total service time field inside that task, and sends it to the second









priority queue. The other priority queues work the same way, except their CPU time

quanta are 20, 30, and 40 for priorities 2, 3, and 4 respectively. Time quanta for each

priority are determined by the CPUFACILITY declaration. If a task reaches priority 4,

goes to the CPU, expends the 40 second time quantum, and is still not finished executing,

the CPU leaves the task at priority 4 and sends it back to the fourth priority queue. When

a CPU task's total service time is expended, it is sent back to the Void area. The CPU

determines which queue to draw tasks from based on the following rule: Draw a task

from the highest priority queue that has a waiting task (by waiting, the task is meant to be

at the head of the queue, and not traveling/in transit from the end of the queue to the head

of the queue). Lower priority queues may starve, but this is a danger of any priority

queuing system that is not implemented in a round-robin fashion. A round-robin system

would be simple to implement here, if so desired.

When a task reaches the CPU, if the task is not a CPU task, it is sent along to the

appropriate peripheral device queue. There is no priority queuing at the peripheral

devices--these queues operate on a first-in-first-out basis. When a non-CPU task arrives

at its device, the device decides on a random service time for that task according to some

distribution. Fields in the FACILITY declarations determine the randomization of

service time at peripheral devices. While a peripheral device is serving a task, a specific

sound can be heard (these have no relationship to the metaphors being used):

1. DEV--church bell,

2. COM--blowing wind,

3. MEM--running water, and

4. /O--rain and thunder.

When the task's service time is expended, the task is sent back to the Void area.









In summary, proceeding in a top-down fashion, the model viewer first encounters

the shell of the building of the OS as shown in Fig. 4.5. Soon, the shell disappears and

the viewer sees a series of floors stacked one on the other as shown in Fig. 4.6. On one

of these floors the viewer sees the task scheduler operating as shown in Fig. 4.6. Inside

the task scheduler, the viewer sees persons moving along paths and through queues

toward service facilities, where they spend some random amount of time receiving

service as shown in Fig. 4.15. As persons go through the waiting/running/in transit

states, their skin color and internal FSM changes state as shown in Fig. 4.12. Service

itself is associated with a unique type of sound that continues as long as that type of

service is being provided. When their service at some facility is complete, persons leave

the service facilities, enter the Void area, and have their attributes reset to start the

process again. This "recycling" of persons avoids destroying and regenerating them in

order to continue the simulation. Lastly, a HUD is provided, which allows the viewer of

the model to turn the geometric representations of the paths on and off and alter the

random probabilities of task type assignment, all while the simulation is operating.






.. . .... ...X-: ,



...... .....


Figure 4.15: Close-up view of task scheduler operation.









The actual implementation of the above-described 3-D world/program is located

at the following URL at time of writing:

http://www.cise.ufl.edu/-fishwick/rube/worlds/os.html



4.7 Steps 3, 4, and 5 Revisited: Example Task Scheduler Based on Logical Time

The model created previously during the fifth step of the rubeTM modeling

methodology is a simulation model based on the passage of wall-clock time. It is

possible to create a simulation of the same hypothetical OS task scheduler (proposed in

Step 1) based on logical (or virtual) time, using the same formally defined conceptual

and dynamic behavioral models that were developed in Step 2. Steps 3, 4, and 5 change

somewhat for the new model. These changes are described below.

4.7.1 Step 3: Choose a Metaphor and/or an Aesthetic Style

Here, the calendar metaphor is added to the previously chosen metaphors (i.e.,

architectural metaphor, synthetic human agent metaphor, business workflow metaphor,

and traffic light metaphor). Again, the choice of the calendar metaphor here is not

arbitrary, and so there seems to be an anomaly in the rubeTM modeling step order. This

anomaly will be addressed in more detail later.

4.7.2 Step 4: Define Mapping/Develop Analogies

It is envisioned that the virtual time OS task scheduler will have some sort of

global virtual time clock and also a global list of events that will take place in the future

with respect to the current global virtual time. The calendar metaphor is used to

represent the global virtual clock and event list: "The current global virtual clock time is

today (or now)," and "The list of events is a calendar."









An easy way to understand virtual time is to view it via the calendar metaphor.

Many people maintain calendars on which they note the planned dates and times of

important events, along with a short description of the event (e.g., November 16th: See

dentist at 10:00 AM). Often, as the days pass, the owner of the calendar will 'X' the days

out. There may be several days or weeks in between events in which there are no events

scheduled. Sometimes the user of the calendar may wish that, by 'X'-ing the "empty"

days out, he or she could skip over them entirely and travel into the future to the next

important event on the calendar. In the current context, virtual time allows the user to

'X'-out time in which no events are scheduled and instead immediately advance to the

next future event. Using the calendar metaphor, the latest 'X' marks the current day and

a mapping can be created between the current global virtual time in the OS example and

"today." The calendar itself contains the list of events, and so a mapping can be created

between the list of events and a calendar in the OS task scheduler. These mappings are

shown in Fig. 4.16.

Current global 4 Today List of events Calendar
logical time


Figure 4.16: Mappings associated with the calendar metaphor.



The calendar metaphor guides a manner of thinking about how a virtual time OS

task scheduler might operate. The calendar would maintain a global list of all pending

events. This event list is simply envisioned as a conglomeration of times when task

scheduler devices are due to "release" the particular task they are serving. To illustrate,

suppose a task arrives at device 'A' at global virtual time 58. Device 'A' determines that

this task will require 20 units of virtual time to dispatch. Device 'A' adds 20 units of









virtual time to the current virtual time (58), which yields 78. This time reflects the global

virtual time at which Device 'A' will release the task it is currently serving. Device 'A'

posts this future event in the global calendar and continues to service the task, since the

global virtual time has not yet advanced to 78 and the task cannot be released until that

time. Since there are many other devices in the task scheduler system, the calendar is

also maintaining task release times for these other devices. Suppose that there are five

devices in the system (including Device 'A'), the current global virtual time is 58, and the

calendar contains the following event list:

1. release task from Device 'D' at time 60,

2. release task from Device 'B' at time 65,

3. release task from Device 'E' at time 69,

4. release task from Device 'C' at time 73, and

5. release task from Device 'A' at time 78.

The calendar directly advances current global virtual time from 58 to 60, tells Device 'D'

to release its task, directly advances global virtual time from 60 to 65, tells Device 'B' to

release its task, and so on. Eventually, virtual time advances to 78, and the calendar tells

Device 'A' to release its task. Each time the calendar updates the global virtual time, it

informs each of the devices in the scheduler, so that as new tasks arrive at each device,

the devices can correctly predict and post future task release events to the calendar.

In this instance, the calendar metaphor aids in thinking about and solving some

model design and implementation problems. However, this use of the calendar metaphor

is in a capacity that lies outside of the rubeTM modeling steps. That is, rubeTM does not

describe an algorithm for using metaphors in M&P processes that will help users to think










about and solve problems associated with model design and implementation. This issue

will be addressed in more detail later.

4.7.3 Step 5: Create Model

All the PROTOs created previously in Step 5 are carried over in this step. A new

PROTO is developed: FUTUREEVENTCALENDAR. This PROTO is the manifestation of a

calendar as guided by the calendar metaphor. It maintains global virtual time and allows

devices to post task release event times in the global event calendar. A partial PROTO

declaration for FUTUREEVENTCALENDAR is given below:

PROTO FUTUREEVENTCALENDAR
[
field SFString calendar name "NoName"
field SFInt32 time steps btwn release signals 13
eventIn SFTime timestep
eventIn SFInt32 device 1 future event time
eventIn SFInt32 device 2 future event time
eventIn SFInt32 device 3 future event time
eventIn SFInt32 device 4 future event time
eventIn SFInt32 device 5 future event time
eventOut SFInt32 global time
eventOut SFBool release mover from device 1
eventOut SFBool release mover from device 2
eventOut SFBool release mover from device 3
eventOut SFBool release mover from device 4
eventOut SFBool release mover from device 5
]

The previous service facility PROTOs are modified to post task release events to

FUTUREEVENTCALENDAR and also to "obey" the task release signals that will issue

from FUTUREEVENTCALENDAR. The physical manifestations of the

FUTUREEVENTCALENDAR in the 3-D OS task scheduler are: (1) A global virtual time

"clock" that shows the current virtual time and resides just above the CPU facility in the

world, and (2) future task release times that are displayed above each device. These

physical manifestations are shown in Fig. 4.17.

























Figure 4.17: Physical manifestations of the FUTUREEVENTCALENDAR in the OS task
scheduler.



4.7.4 Operation

The operation of this second version of the OS task scheduler is nearly identical to

the operation of the first version. The only differences between the two versions concern

the virtual time implementation. Time quanta are measured in virtual time units vs. wall-

clock seconds. Since it takes some finite amount of wall clock time for tasks to travel

along paths and through queues to get to devices in the 3-D world,

FUTUREEVENTCALENDAR spaces successive task release signals by about 13 wall

clock seconds (determined by trial and error). This delay allows all devices in the task

scheduler a reasonable amount of time to schedule a task release event before the next

release signal is sent by FUTUREEVENTCALENDAR. The simulation is "optimistic" by

design in the sense that, once global virtual time is advanced to some new value, it is

impossible for some event to be assigned a time that is less than (i.e., before) the current

global virtual time. This eliminates the need to "roll back" the simulation and the virtual

clock to the point where the anomaly occurred so that the event chain can be repaired.














CHAPTER 5
THE USE OF METAPHOR IN rubeTM: FINDINGS AND PROPOSALS


5.1 Proximal Findings and Proposals

5.1.1 The Impact of Metaphor on rubeTM Model Aesthetics

The rubeTM paradigm brings out the issue of aesthetics in programming in a novel

way. At the moment, programmers may discuss the aesthetics of programs that exist as

text code. These discussions may include the subjects of code commenting, brace

indexing, overall design efficiency, and etc. Sometimes, aesthetics may not be

considered at all. With the introduction of 3-D metaphor, aesthetics play a larger role,

and the potential develops for programs to evolve into a type of visual art.

In the example OS task scheduler models presented in this thesis, some effort was

made to have the models interact with and entertain the user. This was done with the

incorporation of 3-D metaphor visualization, view changes, animation, and sound. These

aspects of the example models should be novel and attractive to users, even if users do

not quite understand the models or their operation. For developers that would rather not

consider the issue of aesthetics, it may be ignored, or it may prove to be a hindrance to

using rubeTM altogether. Others may view it as an opportunity to explore and pioneer a

new art form.

The example OS task scheduler models created for this thesis may rightfully be

considered works of art. A movie presented at the 2000 Winter Simulation Conference

(Orlando, FL) showed a virtual tour of the synchronous OS task scheduler model along









with other rubeTM models. This was a public exhibition of the aesthetic properties of the

models. The example OS task scheduler models have been informally exhibited to

several viewers at least partially on the premise that the models are works of art. The

significance of using metaphor to promote aesthetics in M&P and model visualization

was noted by Roger Malina, the Executive Editor of Leonardo magazine: (paraphrased)

"The artistic community would be interested in this sort of use of metaphor" [personal

communication, March 2001].

Perhaps a more convincing argument that the use of metaphor in M&P in rubeTM

leads to the creation of art can be derived from the effects of the absence of metaphor.

Without metaphor, there can be no metaphor visualization, and visualizations are reduced

to abstract geometric shapes and text. Although it is certainly possible to create a work

of art with abstract shapes and text, metaphor adds flexibility and freedom to explore

different modes of model representation. Thus, metaphor contributes to the aesthetic

qualities of the example OS task scheduler models presented in this thesis and so also can

contribute to the aesthetic qualities of other rubeTM models.

5.1.2 Proposals Concerning rubeTM Modeling Step Order

The mapping definition of Step 4 of the rubeTM modeling methodology may be

easy or difficult to perform based on the metaphor and aesthetic chosen. For this reason,

this thesis proposes that Steps 3 and 4 may be performed in parallel, such that any

generally apparent requirements of mapping may help guide a choice of metaphor and

aesthetic. Unfortunately, this thesis is unable to comment on how the human mind

seemingly generates metaphor and analogy spontaneously. For example, the vertically

layered OS hierarchy naturally suggests an architectural metaphor where the layers of









the OS correspond to the floors of a building. The architectural metaphor was chosen

when some of the possible mappings between it and the OS layers were immediately

apparent. While a Dadaist painting metaphor might be arbitrarily chosen to represent the

structure of the same vertically layered OS hierarchy, some may find it "unaesthetic,"

difficult, or impossible to generate a mapping between the two. Further, the physically

based design philosophy that is the legacy of OOPMM may have the tendency to involve

metaphor early in modeling processes. The author of this thesis found that the eventual

integration of 3-D metaphor in the example OS task scheduler models made it necessary

to think in a "physical" object-oriented fashion from the start of the rubeTM modeling

steps. This is because the author had little choice but to consider that the model, its

operation, and its 3-D metaphors would ultimately be represented in three dimensions

with concrete and familiar objects. Overall, this thesis proposes that rubeTM modeling

steps related to the use of metaphor should not necessarily be conformed to in a rigidly

sequential fashion. This thesis has demonstrated that the metaphor processes are

somewhat dialectical in practice.

This thesis is unable to assess how the incorporation of metaphor affects decision-

making in model design processes as prescribed by rubeTM. This situation arises as

byproduct of the step order of the rubeTM modeling methodology; metaphor does not

come into play in the rubeTM modeling methodology until Steps 3 and 4. For example, in

the OS scheduler example, the task of designing a hypothetical OS task scheduler--minus

the metaphors--had already been largely completed prior to the beginning of the project

by virtue of the fact that MINIX had been chosen as a rough model. The system that was

being modeled was relatively well understood and was chosen in Step 1 and specified in









detail in Step 2 of the rubeTM modeling methodology. Also, the calendar metaphor,

which helped the author of this thesis think about how to structure a hybrid

synchronous/asynchronous model, cannot "appear" in the current rubeTM modeling steps

until Step 3 at the earliest. Overall, the example models showed that it is possible to

represent an OS task scheduler using metaphor in the rubeTM modeling methodology. It

is reasonable to assume that, during the model representation process, some of the ideas

or tools necessary to be able to generate an OS task scheduler design via metaphor were

created. However, the design, specification, and generation of a novel system via

metaphor would better demonstrate the utility of metaphor in these tasks.

Accordingly, this thesis proposes that if metaphor is to be incorporated as a

system design aid in rubeTM, metaphor should be considered much earlier than it currently

is in the current rubeTM modeling steps (i.e., before Steps 3 and 4). Further, the generic

scenarios most likely to benefit from a metaphor modelingprocess (MMP) are ones in

which the developer is approaching an unfamiliar problem or there is a moderate to high

level of ambiguity in the specification of the target system. An outline of a MMP that

one might use to model the target system in such a case might be:

1. Develop a partial list of the most important and desired characteristics and
relationships between objects in the target system.

2. Develop a good analogy or analogies between the target system and some
other well-known domain(s) (i.e., sourcess), based on partially matching
the list from the previous step with a list of the characteristics and
relationships in the well-known domain(s).

3. Using the unmatched characteristics and relationships from the well-
known domain(s) as a guide, develop the specifications of the target
system in greater detail.

4. Repeat steps as often as necessary to specify the target system to a
satisfactory level.









5. Return to the current rubeTM modeling steps.

This method "suffers" from the fact that analogy, rather than metaphor, is the

primary drive mechanism. However, the method also shows how metaphor and analogy

are related, and how metaphor may be the more important phenomenon--the well-known

domain serves as a metaphor that suggests subsequently generated analogies with the ill-

defined target system (see Step 3, above). Thus, metaphor has broader scope and

implication than simple analogy.

To demonstrate the general action of the MMP proposed above, consider the

following. A common problem area in agent research is that of security, especially in the

context of mobile agents [39, 40]. The ynt.he/ti human agent metaphor could help a

developer unfamiliar with mobile agent security to draw an analogy between the nodes of

a network and buildings in the real world. Mobile agents travel amongst the nodes of a

network just as humans travel amongst buildings. Humans gain access to buildings by

passing through doors, and if a building is secure, the doors are locked. However, if a

human has a key to the door's lock, then he or she can get into the building. This

suggests that locks should be placed on the nodes of the network at their communication

access points (software or hardware), and specific agents should be granted access to

these nodes with keys. This might be enough to satisfy a novice developer, but

admittedly it is not nearly enough to satisfy a more advanced developer or provide an

adequate architecture for airtight security. Still, the analogies can be expanded, and

public key techniques might be incorporated to develop a better solution. Solving the

problem of security in a network that contains mobile agents is not the focus here.

Rather, the focus is on suggesting a mode of thinking about modeling and design

problems that is inspired by metaphor, and that remains familiar and clear because it









accords with everyone's everyday experience. The inspirational metaphor in this case is

the 'll-he/icL human agent metaphor.

If the target system is fairly well understood, the MMP proposed above may serve

to give users a different perspective of it. This novel perspective may or may not have

some practical value. For example, during the application of the 'Inhelick- human agent

metaphor to the example OS task scheduler models, the author of this thesis developed a

"new" (to the author) perspective on non-distributed OS design. To elaborate, consider

an agent-based, non-distributed OS in which several semi-autonomous synthetic human

agents may be used to represent the same high-level task within disparate portions of the

OS (e.g., file system manager), and within a computer's hardware (e.g., memory). In this

environment, a single high-level task may possess several agents throughout the system.

The agents' common owner--the high-level task--would link these. The idea that tasks

could be designed as agents involves an implicit shift away from the idea that tasks are

simply manipulated by a non-distributed OS. Rather, tasks and their agents within the

system could play a more active role as seekers of services. Traditionally, tasks have no

perception of a non-distributed OS, but rather a non-distributed OS perceives and

manages tasks. For the tasks and their agents to become more active in these respects, a

possible course of action is to endow them with perceptive abilities and varying degrees

of autonomy. Without doubt, this can be considered as a radical departure from

traditional views of non-distributed OS functionality and architecture. Less controversial

is the notion that agents may inhabit a physically distributed system (OS or other), in

which they autonomously travel about between different hosts in their quest to perform

tasks (i.e., mobile agents [31]). To reduce the contrast between these domains, one might









assert that there is little difference between the distributed system and the non-distributed

system from an abstract point of view--after all, they both contain tasks and physically

distributed hardware devices. To raise the contrast, one might raise pragmatic issues

such as the network delays, bandwidth, and security issues that distributed systems must

be concerned with. So, this thesis suggests that the out-of-hand dismissal of unusual

abstract thinking incited by the use of metaphor may preclude the development

potentially useful and interesting insights like those above.


5.2 Distal Findings and Proposals

5.2.1 Findings Related to the Literalist/Figuralist Debate

It was previously stated that Literalists generally hold that metaphor is a rhetorical

device grounded in linguistics and lexical semantics, rather than conceptual

representation and knowledge of the world [18, 19]. This thesis finds that the 'yiuhelic-

human agent metaphor alone provides enough material to dispute this claim. For

example, simple dictionary definitions of synthetic, human, and agent, taken together,

could not have adequately expressed the concept of a %yulhliic human agent. Knowledge

of the real world was necessary to describe the synthetic human agent. It was also stated

that Literalists hold that the benefits that metaphor provides are not very important, and

metaphor cannot alter the way humans cognitively structure concepts and thereby

structure new knowledge and experience [18, 19]. This thesis finds that metaphor can

have a significant impact on artistic expression. Additionally, metaphor can alter the way

humans cognitively structure concepts--this was shown by Gentner and Gentner [23]

through the process of analogy and also in this thesis through the proposal of a MMP that

would guide modeling and design of unfamiliar or ambiguous systems. This thesis also









showed how metaphor altered the author's perspective on non-distributed OS architecture

and operation. Finally, it was stated that Literalists hold that metaphor can be

decomposed into literal primitives in both language and cognition, and so metaphor is

unnecessary. This thesis contains no findings that directly undermine this claim.

The findings in this thesis support the Figuralist view that metaphors help shape

our conceptual system and perceptions of the world--the author's view of a non-

distributed OS was altered. This thesis speculates that metaphor is central to creative

thought on the basis of the potential of the MMP. This thesis did not find direct support

for other Figuralist claims, except as these are opposed to the Literalist claims identified

above.

5.2.2 Findings Related to the Importance of Metaphor and Analogy in Cognition

Since this thesis contains no human-based empirical research, it makes no strong

claims concerning the empirically measurable effects of metaphor on cognition. Weak

claims may be made by this thesis that metaphors help shape our conceptual system and

perceptions of the world, and that metaphor is central to creative thought (as previously

stated in findings related to the Literalist/Figuralist debate, above).

5.2.3 Surfacing the Activity of Model Transitions

Many of the dynamic behavioral model types, such as QNET, FSM, PNET, and

SDM, incorporate transitions, arcs, links and etc. that are usually visualized as 2-D

arrows that lead from one component of the model to another. In traditional 2-D

representations of these models, these arrows are static--that is, their appearance never

changes according to the dynamic operation of the model. For example, in a PNET,

tokens move from component to component over paths directed by arrows, but these

tokens are seldom shown physically moving over the length of the arrows. So, if an









observer is to watch and understand such a model during its operation, he or she must

often infer the "movement" of objects along the paths directed by the arrows as indicated

by the state change of the model from time step to time step.

A rubeTM visualization that incorporates the PATH PROTO presented in this thesis

has the ability to show the movement of data over transitions. This gives such models

more of a real-world aspect and removes the need for an observer to perform inferences

concerning the transfer of data. Overall, this aids in understanding visualizations since

objects in the real world do not "disappear" from one point and "reappear" at another

distant point without physically traveling between the points.

5.2.4 The Objective Evaluation and Automatic Generation of Analogies

The objective evaluation of analogies suggested by metaphors may be of some

utility in rubeTM modeling methodology. According to Gentner's [41] Structure-Mapping

Theory (SMT), a good analogy is one where relations between entities match well,

without regard to what they are relating. The deeper the structure of the relation, the

more promising the analogy [41]. For example, an electron revolving around a nucleus

of an atom is a good analogy for a planet orbiting around a sun even though the nucleus is

not equivalent to the sun [41]. However, the electron and the planet share a revolves-

around(x,y) relation [41]. Within SMT, an analogy is a mapping between domains in

which few attributes match, but many relations map (e.g., our solar system is like an

atom) [41].

Falkenhainer et al. [22] have described a Structure-Mapping Engine (SME) that is

based on the SMT of analogy. The SME works out many computational details of SMT

[22]. Structure-mapping has three stages [22]:









1. Access: Retrieve a similar analogue.

2. Mapping: Find the correspondences between the subject and its analogue
and produce a set of candidate inferences.

3. Evaluation and Use: Determine the quality of the match.

SME models the Mapping stage--SME constructs all possible mappings, each with a score

for finding the best mapping each with candidate inferences [22].

The rubeTM paradigm does not yet incorporate systems like SMT or SME for the

purpose of generating or evaluating mappings between domains. While it is possible that

these or similar systems may be included in rubeTM in the future, these seem non-

essential, and it is likely that developers will prefer to use such systems at their

discretion. It is expected that developers should be quite familiar and comfortable with

their own spontaneously generated metaphors and analogies, and when they are not, ad-

hoc manual procedures may suffice.

The automatic generation of metaphors and analogies is another matter. Perhaps

one day, a rubeTM model developer may be able to ask the system to automatically

generate candidate metaphors and analogies that the developer may pick from. The

developer may only know the domain to be modeled and may have no idea about other

domains that may provide possible metaphors and analogies. Swanson and Smalheiser

[42] describe a system called ARROWSMITH that performs automated scientific

discovery that may be adapted to automatically generate metaphors and analogies in the

above scenario. A possible outline of the automatic metaphor/analogy generation process

follows:

1. Start with the domain to be modeled: A.

2. Find a set of keywords/domains { B } associated with A: A- > { B}.









3. Find a set of keywords/domains { C } associated with { B : { B ) > { C .

4. Formalize and evaluate the links between domains A- > { C } for quality
(perhaps with SME).

The process of "finding" may take place via traditional WWW or database search, for

example. An example of a simple process for lessening the impact of the combinatorial

explosion over the path A- > B } > C might be:

1. Cluster members of { B } that occur together most frequently (e.g., key],
key2, and key3 appear together most frequently in individual research
papers). Continue the search from B } > C } using the clusters derived
from set { B}.

2. Perform the same clustering for the set { C } to narrow the results.

3. Identify the domains associated with the clusters derived from set { C}.














CHAPTER 6
CONCLUSIONS


6.1 Review of Thesis

The goal of this thesis is to contribute to the continuing development of rubeTM by

augmenting support for and exploring rubeTM's use of metaphor in M&P processes and

model visualization. The thesis develops answers to several questions. These questions

and their answers are outlined in the paragraphs below.

What is rubeTM and how did it develop? Answer (Chapter 2): rubeTM is a

modeling paradigm that outlines some of the first principles that might guide a user of a

programming holodeck. The rubeTM paradigm proposes a modeling methodology that

extends modeling into the third dimension through the use of a hybrid 2-D/3-D VRAL

development platform. The rubeTM paradigm integrates user-specified metaphors in

M&P processes and model visualization, and promotes the addition of visual and audible

elements to models. Thus, rubeTM consciously promotes the potential for models and

programs to become works of art. Research in rubeTM evolved from research in

OOPMM, and both of these systems make use of the dynamic behavioral model types

within a multimodeling framework. The characteristics of rubeTM may be viewed as the

extension of the characteristics of OOPIFM into the third dimension.

What premises provide support for the use of metaphor in M&P processes and

model visualization, and so also in rubeTM? Answer (Chapter 2): The rubeTM paradigm

suggests that 3-D metaphor may be incorporated in M&P processes and visualization









with some advantage [1]. For example, metaphor may serve as a form of implicit

documentation, and the combination of metaphors and visualization may suggest

potential module boundaries during the model design phase. Traditional modeling and

software development practices tend to subvert metaphors, 3-D or otherwise. Although

visual programming environments may be somewhat more conducive to the integration

of metaphor, these typically are not designed with the use of metaphor in mind. This is

an unfortunate situation since metaphor is central to language, cognition, and diverse

aspects of computer science. The rubeTM paradigm seeks, in part, to change this situation

by conceptually and visually integrating metaphors in M&P processes and model

visualization. Further, rubeTM encourages developers to devise their own metaphors. The

increased use of metaphor in rubeTM is based in part on the idea that aesthetics will

continue to play a more important role in M&P. The use of 3-D metaphor in model

visualization lends models aesthetic and artistic aspects that are relatively novel in the

realm of computer science.

Is metaphor really such an important phenomenon that it deserves our attention?

Answer (Chapter 3): In short, "yes." Metaphors influence communication and attention

processes. Metaphors suggest analogies, and analogy is a fundamental cognitive process

[22] that is involved in learning and reasoning [21]. Volumes of active multidisciplinary

research are devoted to metaphor [18]. According to Veale [18, 19], theories concerning

the phenomenon of metaphor can be roughly classified into Literalist and Figuralist

positions. Figuralist views are "metaphor friendly," and lend support to the idea of

incorporating metaphor in M&P processes and model visualization. Veale [18] makes a

forceful philosophical and classical logic-based argument in favor of Figuralist









perspectives. The empirical measurement of the usefulness of metaphor in user

interfaces and programming (visual or otherwise) is a contentious issue [24]. Empirical

results that demonstrate the usefulness of metaphor in computer science are mixed.

However, there does not seem to be enough empirical evidence to support the strong

claim that the use of metaphor in diagrams, user interfaces, and programming has

significant detrimental effects. Finally, several computing paradigms have significant

grounding in metaphor.

What other previous work resembles rubeTM, and how does this work approach

metaphor? Answer (Chapter 3): Najork's [35] CUBE is an example of a 3-D visual

programming language. CUBE does not make extensive use of metaphor. However, it

does make use of the data flow metaphor on a high level and as a guiding paradigm for

the representation of the language [35]. Unlike rubeTM, the user of CUBE has no

flexibility to create or visualize his or her own metaphors within the CUBE environment.

Kahn's [36] Toon TalkTM is a PBD system designed for children in which a programmer

is a character in an animated virtual world in which programming abstractions are

replaced by tangible analogues. Toon TalkTM makes use of visual metaphor. However,

unlike rubeTM, the users of Toon TalkTM do not have the ability to create or visualize

custom metaphors.

Is it practically feasible to incorporate user-specified metaphors in M&P

processes and model visualization as currently prescribed by rubeTM? Answer (Chapter

4): In short, "yes." Two example OS task scheduler models are developed step-by-step

according to the rubeTM modeling methodology, which integrates metaphor in M&P

processes and model visualization. The example models integrate user-specified









architectural, synthetic human agent, business workflow, and other metaphors. These

example models are among the very first to be formally developed according to the

rubeTM modeling steps and compose the development and artwork aspects of this thesis.

Can rubeTM meet the objective of blending the M&P process with the creation of a

work of art, and does the use of metaphor contribute toward meeting this objective?

Answer (Chapters 4 and 5): In short, "yes." The example OS task scheduler models

developed according to the rubeTM modeling methodology may be considered works of

art. Metaphor contributes to the aesthetic qualities of the example OS task scheduler

models by providing flexibility and freedom to explore different modes of model

representation. By extension, metaphor provides the same advantages to other models

developed within rubeTM.

What are alternative possibilities for the use of metaphor in rubeTM? Answer

(Chapter 5): This thesis proposes that Steps 3 and 4 of the rubeTM modeling methodology

may be performed in parallel, such that any generally apparent requirements of mapping

may help guide a choice of metaphor and aesthetic. The rubeTM modeling steps related to

the use of metaphor should not necessarily be conformed to in a rigidly sequential fashion

because it is demonstrated that the metaphor processes are somewhat dialectical in

practice. This thesis is unable to assess how the incorporation of metaphor affects

decision-making in model design processes because of restrictions arising from the

current step order of the rubeTM modeling methodology. Metaphor does not come into

play in the rubeTM modeling methodology until Steps 3 and 4. This thesis proposes that if

metaphor is to be incorporated as a system design tool in rubeTM, metaphor should be

considered much earlier than it currently is in the current rubeTM modeling steps. Toward









this end, the thesis provides a general outline of a MMP that places the use of metaphor

earlier in M&P processes. The potential of a MMP to aid in modeling of both unfamiliar

and familiar systems is demonstrated. This thesis also proposes possibilities for the

objective evaluation and automatic generation of analogies within rubeTM.

What are some suggestions for future research associated with the use of

metaphor in rubeTM? Answer: See "future directions" in this chapter.

This thesis concludes that rubeTM presents an interesting and novel approach to

modeling that shows promise in both humanistic and pragmatic senses. As rubeTM is a

"work in progress" and many of its ideas are not yet fully developed and formalized,

more research is indicated. At present, the primary value of incorporating metaphor in

the rubeTM modeling methodology seems to be the development of aesthetic properties.

This situation is not necessarily permanent, but it is not yet clear how metaphor might

guide and inform the M&P process. Other assertions concerning the pragmatic effects of

the incorporation of metaphor in the rubeTM methodology are well supported by

philosophical and intuitive arguments, and are somewhat less well supported by related

empirical findings; these assertions remain speculative at present. Such seeming

deficiencies will not prevent the further development of the rubeTM modeling

methodology, and rubeTM possesses the flexibility to adapt to important empirical

findings as they may arise.









6.2 Contributions of the Example Models

6.2.1 Reusable Generic Model Components for the rubeTM Toolkit

During the creation of the example OS task scheduler models in this thesis,

several reusable generic model components were created in the form of VRML PROTOs,

namely:

1. FACILITY (created),

2. QUEUEMANAGER (created),

3. FUTUREEVENTCALENDAR (created),

4. MFACTORY (modified), and

5. PATH (modified).

These PROTOs will be added to the rubeTM generic model component toolkit so that other

rubeTM model developers can use them to construct their own QNETs. FACILITY maps

to any device in a QNET, QUEUEMANAGER maps to any queue in a QNET, MFACTORY

generates tokens that physically move around in a QNET, and PATH connects QNET

devices and queues together and manages the movement of tokens through the QNET.

FUTUREEVENTCALENDAR could help other rubeTM model developers create their own

hybrid synchronous/asynchronous models, QNET or otherwise. Other PROTOs are

developed for the models in this thesis, but these are more specialized to the particular

OS task scheduler models.

6.2.2 Fully Developed Models for the rubeTM Model Library

This thesis contributes a fully developed synchronous OS task scheduler model

and a fully developed hybrid synchronous/asynchronous OS task scheduler model to the

rubeTM model library. These models can be considered works of art. Additionally, these









models can be built upon by future rubeTM model developers, perhaps to create a fully

elaborated OS model


6.3 Future Directions

6.3.1 Empirical Research

Although it has been stated that rubeTM research currently concentrates on

developing and justifying the rubeTM modeling methodology rather on HCI-type research,

this may cease to be the case at some point in the future. As previously stated, human-

based empirical research has some importance to the continuing development of rubeTM.

Accordingly, some types of empirical research that might be of significance to rubeTM are

outlined below.

Ultimately, the practical utility of integrating metaphor in M&P processes and

model visualization will need to be judged from the results of empirical research. Such

research might concern itself with both tangible and psychological factors associated with

the use of metaphor. These may include such things as gains or losses in efficiency and

correctness compared with traditional M&P methods, length of design/implementation/

debug cycles, programmer memory retention of program structures and design after

varying periods of time, and ease and enjoyability of use. One obvious candidate for

additional investigation in the context of rubeTM is Blackwell's [24] finding that the use

of metaphor in diagrams provides some mnemonic assistance, which appears to be

greatest when the user of the diagram constructs his or her own metaphor.

Historically, empirical programming research has been hindered by the use of

tools characterized by poor usability; poor usability interferes with the evaluation of more

important aspects of the research. Hopefully, better tools are on the horizon. Ideally, a









fully developed and usable 3-D programming editor for rubeTM model creation would

serve as the core for empirical research within the paradigm, but this tool has not been

developed yet. This sort of editor seems essential to all manner of research within

rubeTM, including the use of metaphor.

The performance of "psychology of programming" studies is a non-trivial task.

Individual differences between people in their problem solving strategies often confound

empirical results. Current studies of the psychology of programming may be criticized

on the grounds that they do not address the concerns of typical developers who deal with

ambiguous problems. Often, developers are faced with the challenge of collaborating

with end-users and co-workers over long periods of time. It would be interesting to

empirically study the utility of metaphor in helping developers to design architectures for

unfamiliar or ambiguously specified systems. Another interesting subject for empirical

study might concern the utility of metaphor in facilitating collaboration. The rubeTM

paradigm offers some potential for facilitating communication amongst end-users and

developers in a shared (e.g., via the WWW) development environment and so rubeTM

may be promoted in this fashion. It is speculated that communication between the two

groups will be facilitated through the use of shared metaphors for the system being

developed. Such metaphors may be a particularly useful tool for end-users who have

limited knowledge of common development and implementation issues. Research

concerning the use of metaphor in the communication patterns of developers who must

work in groups and with end-users seems to be rare if not non-existent. Considering the

central role that communication plays in facilitating teamwork, this is an unfortunate

omission.









6.3.2 Modeling Research

Earlier, it was mentioned that several metaphors could be applied to the data flow

paradigm: "Data is water" and "A link is pipelinee" The SDM is a type of data flow

model in which these metaphors can also be applied. Besides data and links, SDMs have

rates and levels. Rates control and modify data that flow along the links, and levels

collect/sum the data. Within this framework, at least two more metaphors may be

developed: "A rate is a valve" and "A level is a [water] tank." In this way, the SDM is

thought of as a system of water tanks connected by pipelines that are controlled by

valves. To control flow between the tanks, the states of the valves are varied. SDMs

have found some use in modeling population variations of creatures in nature. Currently,

the rubeTM research group is considering creating an apple snail SDM that incorporates

the metaphors just mentioned. Instead of water flowing along the pipelines, snails may

"inch" along the pipelines.

A general aim of the rubeTM research group is to continue to explore the

extensions and applications of metaphor in modeling methodology through the

development of the model toolkit. When a model is added to the toolkit, its metaphors

come along with it. The SDM proposed above and its associated metaphors would

become part of the toolkit, just as the example OS task scheduler models and their

metaphors will become part of the toolkit. In this way, the toolkit may also become a

metaphor toolkit, rather than just a model toolkit.

Finally, the proposals outlined in Chapter 5 might be investigated. Of these, the

proposals concerning rubeTM's modeling step order and the incorporation of metaphor






74


early in M&P processes currently seem most important. Other proposals concerning the

objective evaluation and automatic generation of analogy currently seem less important.
















LIST OF REFERENCES


[1] P.A. Fishwick, rubeTM. http://www.cise.ufl.edu/-fishwick/rube/intro/index.html,
February 2001.

[2] P. A. Fishwick, "Aesthetic Programming," in Leonardo, submitted for review
September 2000.

[3] J. F. Hopkins and P. A. Fishwick, "On the Use of 3D Metaphor in Programming,"
in Proc. of Enabling Technologyfor Sim. Sci., SPIE AeroSense 2000 Conf., April
2000.

[4] J. F. Hopkins and P. A. Fishwick, "A Three-Dimensional Human Agent Metaphor
for Modeling and Simulation," in IEEE Trans. on Syst., Man and Cybern., in
press.

[5] R. M. Cubert, T. Goktekin and P. A. Fishwick, "MOOSE: Architecture of an
Object Oriented Multimodeling Simulation System," in Proc. Enabling
Technology for Sim. Sci., SPIE AeroSense 1997 Conf., April 1997.

[6] P. A. Fishwick, "SIMPACK: Getting Started with Simulation Programming in C
and C++," in 1992 Winter Sim. Conf. Proc., 1992.

[7] K. Lee and P. A. Fishwick, "OOPM/RT: A Multimodeling Methodology for Real-
Time Simulation," in ACM Trans. on Modeling and Comp. Sim., vol. 9, no. 2, pp.
141-170, April 1999.

[8] P. A. Fishwick, Simulation Model Design and Execution. Englewood Cliffs, NJ:
Prentice-Hall, 1995.

[9] P. A. Fishwick, N. H. Narayanan, J. Sticklen and A. Bonarini, "A Multi-Model
Approach to Reasoning and Simulation," in IEEE Trans. on Syst., Man and
Cybern., vol. 24, no. 10, pp. 1433-1449, 1992.

[10] P. A. Fishwick and B. P. Zeigler, "A Multimodel Methodology for Qualitative
Model Engineering," in ACM Trans. on Modeling and Comp. Sim., vol. 2, no. 1,
pp. 52-81, 1992.

[11] Macintosh Human Interface Guidelines, Apple Computer Inc. Staff. New York,
NY: Addison-Wesley, 1993.









[12] The Windows Interface Guidelinesfor Software Design (An Application Design
Guide), Microsoft Corp. Redmond, WA: Microsoft Press, 1995.

[13] D. C. Smith, PYGMALION. A Creative Programming Environment. Ph.D.
dissertation, Stanford Univ., 1975.

[14] J. M. Carroll and J. R. Olson, "Mental Models in Human-Computer Interaction,"
in M. Helander, Ed., Handbook of Human-Computer Interaction. New York, NY:
Elsevier, 1988.

[15] J. F. Pane and B. A. Myers, "Usability Issues in the Design of Novice
Programming Systems," Technical Report CMU-CS-96-132, School of Computer
Science, Carnegie Mellon Univ., 1996.

[16] N. Tractinsky, "Aesthetics and Apparent Usability: Empirically Assessing
Cultural and Methodological Issues," in Proc. 1997 Conf on Human Factors and
Computing Sys. (CHI '97), March 1997.

[17] Merriam-Webster's Collegiate Dictionary, 10th ed. 1998.

[18] T. Veale, Metaphor, Memory and Meaning: Symbolic and Connectionist Issues in
Metaphor Interpretation. Ph.D. dissertation, School of Computer Applications,
Dublin City Univ., Dublin, Ireland, 1995.

[19] T. Veale, A Survey of the Metaphor Field.
http://www.compapp.dcu.ie/-tonyv/trinity/survey.html, February 2001.

[20] V. Ottati, S. Rhoads and A.C. Graesser, "The Effect of Metaphor on Processing
Style in a Persuasion Task: A Motivational Resonance Model," in Journal of
Personality and Social Psychology, vol. 77, no. 4, pp. 688-697, 1999.

[21] P.H. Winston, "Learning and Reasoning by Analogy," in Comm. of the ACM, vol.
23, no. 12, December 1980.

[22] B. Falkenhainer, K. D. Forbus and D. Gentner, "The Structure Mapping Engine:
Algorithm and Examples," in Artificial Intelligence, vol. 41, pp. 1-63, 1990.

[23] D. Gentner and D. R. Gentner, "Flowing Waters or Teeming Crowds: Mental
Models of Electricity," in D. Gentner and A. L. Stevens, Eds., Mental Models.
Hillsdale, NJ: Lawrence Erlbaum, 1983.

[24] A. F. Blackwell, Metaphor in Diagrams. Ph.D. dissertation, Darwin College,
Univ. of Cambridge, Cambridge, UK, 1998.

[25] A. F. Blackwell and T. R. G. Green, "Does Metaphor Increase Visual Language
Usability?" in Proc. 1999 IEEE Symp. on Visual Languages, 1999.










[26] T. H. Nelson, "The Right Way to Think about Software Design," in B. Laurel, Ed.
The Art ofHuman-Computer Interface Design. Reading, MA: Addison-Wesley,
1991.

[27] A. A. di Sessa, "Notes on the Future of Programming: Breaking the Utility
Barrier," in D. A. Norman and S. W. Draper, Eds., User Centered System Design:
New Perspectives on Human-Computer Interaction. Hillsdale, NJ: Lawrence
Erlbaum, 1986.

[28] R. J. Schalkoff, Artificial Neural Networks. New York, NY: McGraw-Hill, 1997.

[29] L. Davis and M. Steenstrup, "Genetic Algorithms and Simulated Annealing," in
L. Davis, Ed., Genetic Algt i/thin and Simulated Annealing. Los Alamitos, CA:
Morgan Kaufmann, 1988.

[30] R. Burkhart, "The Swarm Multi-Agent Simulation System," in (OOPSLA) '94
Workshop on "The Object Engine," September 1994.

[31] N. R. Jennings and M. J. Wooldridge, Eds., Agent Technology: Foundations,
Applications, andMarkets. Berlin: Springer-Verlag, 1998.

[32] S. Franklin and A. Graesser, "Is it an Agent, or Just a Program?: A Taxonomy for
Autonomous Agents," in Proc. of the Third nt. Workshop on Agent Theories,
Architectures, and Languages, 1996.

[33] P. A. Fishwick, A. Urmacher and B. Zeigler, Eds., "Agent Oriented Approaches
in Distributed Modeling and Simulation: Challenges and Methodologies," in
Dagstuhl Seminar Report, July 1999.

[34] H. Lieberman, "A Three-Dimensional Representation for Program Execution," in
Proc. of the 1989 Workshop on Visual Languages, October 1989.

[35] M. Najork, Programming in Three Dimensions. Ph.D. dissertation, Univ. of
Illinois at Urbana-Champaign, 1994.

[36] K. Kahn, "Generalizing by Removing Detail," in Comm. of the ACM, vol. 43, no.
3, pp. 104-106, March 2000.

[37] R. St. Amant, H. Lieberman, R. Potter and L. Zettlemoyer, "Visual Generalization
in Programming by Example," in Comm. of the ACM, vol. 43, no. 3, pp. 107-114,
March 2000.

[38] A. S. Tanenbaum, Operating systems: design and implementation. Englewood
Cliffs, NJ: Prentice-Hall, 1987.






78


[39] W. Jansen and T. Karygiannis, "NIST Special Publication 800-19 Mobile Agent
Security," Gaithersburg, MD: National Institute of Standards and Technology,
August 1999.

[40] K. Schelderup and J. Olnes, "Mobile Agent Security Issues and Directions,"
Lecture Notes in Comp. Sci., vol. 1597, pp. 155-167, 1999.

[41] D. Gentner, "Structure-Mapping: A Theoretical Framework for Analogy,"
Cognitive Science, vol. 7, no. 2, pp. 155-170, 1983.

[42] D. R. Swanson and N. R. Smalheiser, "An Interactive System for Finding
Complementary Literatures: A Stimulus to Scientific Discovery," Artificial
Intelligence, vol. 91, pp. 183-203, 1997.















BIOGRAPHICAL SKETCH

John F. Hopkins was born in Elizabeth, NJ, on November 20, 1969. He was an

enlisted member of the U.S. Navy during the period 1987-1993, and performed the duties

of electronics technician and nuclear reactor operator on board a Los Angeles class

submarine. John graduated summa cum laude and as co-valedictorian of the College of

Liberal Arts and Sciences at the University of Florida with a Bachelor of Science degree

in psychology in 1998. He married his wife, Jennifer, in 1999. Currently, John is

pursuing the Master of Science degree in computer and information science at the

University of Florida and expects to graduate in May 2001. In August 2001, he expects

to begin a career as a research engineer with Lockheed Martin Corp., Missiles and Fire

Control Division, located in Orlando, FL.




University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs