designing devs visual interfaces for end-user programmers · 2017-04-12 · designing devs visual...

26
Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1 , Robert Woodbury 1 , Rhys Goldstein 2 , Simon Breslav 2 and Azam Khan 2 Abstract Although the Discrete EVent System specification (DEVS) has over recent decades provided systems en- gineers with a scalable approach to modeling and simulation, the formalism has seen little uptake in many other disciplines where it could be equally useful. Our observations of end-user programmers confronted with DEVS theory or software suggest that learning barriers are largely responsible for this lack of utiliza- tion. To address these barriers, we apply ideas from Human-Computer Interaction to the design of visual interfaces intended to promote their users’ effective knowledge of essential DEVS concepts. The first step is to propose a set of names that make these concepts easier to learn. We then design and provide ratio- nale for visual interfaces for interacting with various elements of DEVS models and simulation runs. Both the names and interface designs are evaluated using the Cognitive Dimensions of Notations framework, which emphasizes trade-offs between fourteen aspects of information artifacts. As a whole, this work illus- trates a generally applicable design process for the development of interactive formalism-based simulation environments that are learnable and usable to those who are not experts in simulation formalisms. Keywords Discrete-event simulation, end-user programming, visual programming, cognitive dimensions 1 Introduction The Discrete EVent System specification (DEVS) provides a general, rigorous formalism for describ- ing discrete event simulations. It is used widely by simulation researchers and systems engineers but has seen less uptake in other disciplines where it could be extremely useful. DEVS is frequently adopted as a basis for software libraries and sim- ulation environments. Most of these tools to date have attempted to closely map their objects to the mathematical constructs of the formalism. This approach has led to features that make DEVS dif- ficult for domain experts (who mostly have lim- ited knowledge of simulation theory) to under- stand. For example, names such as “internal tran- sition function” carry little meaning to those who have not studied DEVS theory, whereas the word “model” may cause confusion by evoking different interpretations for different users. Another source of difficulty is the formalism’s separation of a sim- ulation program into a model-independent simu- lator and various modeling elements. This sepa- ration provides numerous benefits, yet contrasts sharply with the imperative style of programming taught first to many potential DEVS users. Software itself presents new opportunities in learning any formalism. Through careful interface design, support for exploratory coding strategies such as copy-and-modify 1 , freely available exam- ples 2 , and features such as command-line comple- tion, templates, and contextual help, software can assist new users in understanding a system. With the right design, software enables learning by do- 1 School of Interactive Arts and Technology, Simon Fraser 1 University, Canada 2 Autodesk Research, Canada Corresponding author: Robert Woodbury, School of Interactive Arts and Technology, Simon Fraser University, 250-13450 102 Avenue Surrey, BC, CANADA V3T 0A3 Email: [email protected] 1

Upload: others

Post on 04-Jun-2020

15 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

Designing DEVS Visual Interfaces for End-User Programmers

Maryam Maleki1, Robert Woodbury1, Rhys Goldstein2, Simon Breslav2 and Azam Khan2

AbstractAlthough the Discrete EVent System specification (DEVS) has over recent decades provided systems en-gineers with a scalable approach to modeling and simulation, the formalism has seen little uptake in manyother disciplines where it could be equally useful. Our observations of end-user programmers confrontedwith DEVS theory or software suggest that learning barriers are largely responsible for this lack of utiliza-tion. To address these barriers, we apply ideas from Human-Computer Interaction to the design of visualinterfaces intended to promote their users’ effective knowledge of essential DEVS concepts. The first stepis to propose a set of names that make these concepts easier to learn. We then design and provide ratio-nale for visual interfaces for interacting with various elements of DEVS models and simulation runs. Boththe names and interface designs are evaluated using the Cognitive Dimensions of Notations framework,which emphasizes trade-offs between fourteen aspects of information artifacts. As a whole, this work illus-trates a generally applicable design process for the development of interactive formalism-based simulationenvironments that are learnable and usable to those who are not experts in simulation formalisms.

KeywordsDiscrete-event simulation, end-user programming, visual programming, cognitive dimensions

1 Introduction

The Discrete EVent System specification (DEVS)provides a general, rigorous formalism for describ-ing discrete event simulations. It is used widelyby simulation researchers and systems engineersbut has seen less uptake in other disciplines whereit could be extremely useful. DEVS is frequentlyadopted as a basis for software libraries and sim-ulation environments. Most of these tools to datehave attempted to closely map their objects to themathematical constructs of the formalism. Thisapproach has led to features that make DEVS dif-ficult for domain experts (who mostly have lim-ited knowledge of simulation theory) to under-stand. For example, names such as “internal tran-sition function” carry little meaning to those whohave not studied DEVS theory, whereas the word“model” may cause confusion by evoking differentinterpretations for different users. Another sourceof difficulty is the formalism’s separation of a sim-

ulation program into a model-independent simu-lator and various modeling elements. This sepa-ration provides numerous benefits, yet contrastssharply with the imperative style of programmingtaught first to many potential DEVS users.

Software itself presents new opportunities inlearning any formalism. Through careful interfacedesign, support for exploratory coding strategiessuch as copy-and-modify 1, freely available exam-ples2, and features such as command-line comple-tion, templates, and contextual help, software canassist new users in understanding a system. Withthe right design, software enables learning by do-

1School of Interactive Arts and Technology, Simon Fraser1University, Canada2Autodesk Research, Canada

Corresponding author:Robert Woodbury, School of Interactive Arts and Technology,Simon Fraser University, 250-13450 102 Avenue Surrey, BC,CANADA V3T 0A3Email: [email protected]

1

Page 2: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

2 Designing DEVS Visual Interfaces for End-User Programmers

ing. Yet traditionally, systems engineers studyDEVS theory and then learn DEVS tools. A dif-ferent approach is needed for domain experts whoprioritize the objective of their code over its sys-tematic development3. To attract a larger follow-ing, DEVS tools should assume the role of explain-ing the formalism and take advantage of lessonslearned in end-user and visual programming.

A multitude of science, engineering, and designdisciplines now have computational sub-disciplinesthat leverage state-of-the-art computing methodsand technology to address the needs of their area.These computational communities have becomelarge as both system capabilities and demandfor these capabilities have grown. While domainexperts within these communities know little ofsimulation theory, they make use of proceduralscripting, are familiar to some degree with object-oriented concepts, and tend to have considerableexperience with visual programming. In partic-ular, they tend to be comfortable with dataflowvisual programming, in which data flows from oneentity to another and the program is representedby a directed graph4. Dataflow systems are bothwidely used and actively developed in the archi-tectural domain, where among other benefits theparadigm helps designers parameterize buildinggeometry1. In the domain of life sciences, dataflowprogramming aids in the specification and execu-tion of scientific workflows5.

The challenge of expanding DEVS utilizationin the computational communities of various do-mains can be addressed by focusing on three ob-jectives. First, change the way DEVS theory is ex-pressed to make it easier to learn from a user’s per-spective. Second, make software consistent withthe re-expressed DEVS theory. Third, design vi-sual interfaces that emphasize and relate the keyDEVS concepts associated with every element ofthe users’ models and simulation runs. In the veryearly stages of software design, before interfacesexist to facilitate evaluation through user studies,a set of qualitative guidelines is needed to informdesign decisions. We therefore propose the use ofa framework known as Cognitive Dimensions ofNotations6, and apply it to all three objectives.

In this paper we pursue the design process out-lined above by first proposing a set of names tomake DEVS more approachable, and then pre-

senting a set of visual interfaces intended to in-form and remind users of the formalism’s essentialconcepts. These interfaces exhibit novel features,some prominent and others subtle, that we hopewill inspire simulation tool developers. Most im-portantly, the rationale for all decisions is given,which will help DEVS experts re-imagine theirown simulation environments and attract not onlysystems engineers but also end-user programmersfrom a wide range of disciplines. We present theconcepts discussed here through the canonical sim-ulation scenario of a bank.

2 Background and related work

2.1 Human-computer interaction

Researchers in the large and rapidly growingfield of Human-Computer Interaction have ex-plored a number of topics relevant to the software-supported learning of formalisms and program-ming tools. Three topics in particular have in-fluenced our approach to visual interface design.

End-User Programming provides insightinto the motivations of simulation practi-tioners from a range of disciplines. Writingand maintaining software is a professional pro-grammer’s primary job. An end-user program-mer however, has a different primary job: he/shewrites a program only to achieve a goal. This goalis not the program itself, but something relatedto his/her job or hobby. For example, a schoolteacher may program a spreadsheet to calculateclass grades, or an architect may write a simula-tion to analyze the energy performance of a build-ing. Simulation tools have both types of users,and both groups face barriers in authoring simu-lation models. The difference lies in the fact thatend-user programmers are motivated by their do-main and not by the merit of producing code, andtherefore perceive these barriers as distractions7

that require cognitive attention.

In the attention investment model8, the amountof attention a person spends on a task is consid-ered as a currency. So for each programming task,there is a certain amount of attention ‘cost’ thatneeds to be spent in order to receive a ‘payoff’from the program (for example, time saved by au-

Page 3: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

Maleki et al. 3

tomating a task), with the ‘risk’ of receiving nopayoff or incurring additional costs. Users takeinto account the ‘perceived’ costs and risks of aprogramming task and its payoff in their decisionmaking process. For a simulation system to bewidely used, the cost and risk of creating, editing,and using simulations must be low. In addition,the perceived cost of these tasks must be low andin line with the actual cost. In other words, thesystem should not seem more difficult to learn anduse than it actually is.

An increase in the utilization of DEVS-basedsoftware will be accompanied by a shift in userdemographics away from systems engineers andtowards experts in other domains. Both barriersand attention investment are particularly salientfor domain experts; hence the visual interfaces wedesign target end-user programmers. Generally,when we use the term user, we mean “end-userprogrammer”.

Visual programming, where more than onedimension is used to convey semantics9,shows promise in reducing both barriersand perceived cost. Visual programming lan-guages use visual expression as part of their syn-tax. Visual programming environments use tradi-tional textual syntax with visual elements in theenvironment to aid in creating or editing code.There has been several studies on the effects ofusing visual programming techniques on programcomprehension, program creation and programdebugging. The results for program comprehen-sion are generally mixed and depend on the userand the type of task. More significant improve-ments have been reported for program creation,as well as program debugging10. Among end-userprogrammers, visual programming has becomewidely accepted11. The goal of visual program-ming research is not to eliminate textual code,but to improve programming languages and en-vironments and their ease of use, as well as users’accuracy and speed of programming. These goalsare pursued using the following strategies9.

• Concreteness: expressing aspects of the pro-gram using instances.

• Directness: reducing the distance betweenuser’s goal and the actions required to achieve

that goal, giving the user the feeling of di-rectly manipulating the object.

• Explicitness: making some aspect of the se-mantics (such as dataflow or relationships)explicit in the environment.

• Immediate visual feedback: automatically dis-playing the effects of program edits.

Spreadsheets are among the most successful vi-sual programming environments. They allow theuser to work on concrete data in the cells, givethem the impression that they are directly manip-ulating the data, make the relationship betweendata cells explicit, and give immediate feedbackon edits. Another widely used visual program-ming language is Rhino3D’s Grasshopper add-on.Grasshopper, a favourite among architectural de-signers, uses nodes and links to visualize dataflowand parametric relationships between geometricelements, with the result rendered immediately inRhino’s three-dimensional model viewer. An effec-tive visual programming environment for DEVSwould employ all four strategies while amplifyingthe formalism’s support for modular model design.This is analogous to the objective of the ConMansystem12, an early example of visual programminginvolving communication between modular com-ponents.

Cognitive Dimensions of Notations is aframework for evaluating the usability of in-formation artifacts, including both mathe-matical formalisms and software interfaces.The framework, first introduced by Green 6 andlater elaborated by Green et al. 13 , turns theknowledge of psychology of programming into aform that is usable for non-psychologists. It givesnames to concepts that may seem obvious, butsignificantly impact design decisions and trade-offs. The framework comprises fourteen dimen-sions, which we mark in this paper with specialtypography:

• Role-expressiveness(cd): The purpose of an en-tity is readily inferred.

• Hidden dependencies(cd): Important links be-tween entities are not visible.

Page 4: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

4 Designing DEVS Visual Interfaces for End-User Programmers

• Consistency(cd): Similar semantics are ex-pressed in similar syntactic forms.

• Diffuseness(cd): The notation is verbose.

• Closeness of mapping(cd): The notation corre-sponds closely to the problem world.

• Hard mental operations(cd): Use places highdemand on cognitive resources.

• Visibility(cd): Components can be viewed andjuxtaposed easily.

• Abstraction(cd): The notation provides ade-quate levels of abstraction.

• Progressive evaluation(cd): Work-to-date canbe checked at any time.

• Juxtaposibility(cd): Different parts of the in-terface can be viewed and compared side-by-side.

• Error-proneness(cd): The notation invites mis-takes and the system gives little protection.

• Secondary notation(cd): Notation can carry ex-tra information by means of layout, color orother cues.

• Viscosity(cd): Much effort is required to makea change to a program.

• Premature commitment(cd): Decisions must bemade before necessary information is avail-able.

The cognitive dimensions of notations frame-work is used in formative evaluation of softwaresystems during their design process. For exam-ple, Jones et al. 14 use the dimensions as guidesin creating the Forms/3 spreadsheet system. Theframework is also used to evaluate existing sys-tems, such as Green and Petre 15 ’s evaluationof several visual programming languages and en-vironments, including LabView and Prograph.It can also serve as a feedback and evaluationmethod for users of a system, using the cognitivedimensions of notations questionnaire16.

Depending on the type of the system and thetype of task it supports, some dimensions may bemore important than others and trade-offs may

have to be made. A system designer may try toincrease the usability of the notation in one di-mension, keep the usability in a second dimensionconstant, and inevitably reduce the usability in athird dimension. We use the framework to an-alyze existing systems and to design new visualinterfaces, and in doing so, some dimensions cameup more often than others. For example, con-sidering the target users of our system who areend-user programers, it is important for the nota-tion to show the purpose of the entities as clearlyand readily as possible (role-expressiveness(cd)) andto reveal the dependencies between those entities(hidden dependencies(cd)). Another example of adimension that came up frequently in our designdiscussions was diffuseness(cd), not so much as agoal we were after, but a consequence of our de-sign decision to use visual elements to express thenotation. The list of dimensions above is orderedbased on how often they came up: the dimen-sions that we used most frequently, such as role-expressiveness(cd)and hidden dependencies(cd), areat the top of the list.

2.2 Approachability of DEVS

The DEVS formalism allows essentially all simula-tion models to be expressed in a common form. Amodel is either atomic or coupled, and is specifiedby defining each mathematical element in the cor-responding tuple in (1). The role of each elementis described in Theory of Modeling and Simula-tion 17, the latest edition of the book which in-troduced DEVS in 1976. The elements are eval-uated by a model-independent simulation proce-dure, which can be found in the same book or inAlgorithm 1 of this paper’s Appendix.

Atomic Models :〈X,Y, S, δext , δint , λ, ta〉

Coupled Models :〈X,Y,D, {Md},EIC ,EOC , IC ,Select〉

(1)

DEVS has two key properties that facilitate ascalable approach to the design and applicationof simulation models. First, given a set of mod-els implemented in a common form based on thetheory, a single simulator may perform simula-tion runs using any of them. The concept of a

Page 5: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

Maleki et al. 5

reusable simulator is not unique to DEVS, but anatomic model’s relationship with certain time du-rations gives the formalism a high degree of gen-erality which makes the separation of model andsimulator particularly appealing. Second, DEVSmodels of either type can be combined to repre-sent increasingly complex real-world systems. Itis true that object-oriented programming and nu-merous modeling paradigms address complexityusing similar compositional strategies. However,a DEVS coupled model is particularly modular inthat its component models do not reference oneanother.

It is a testament to the generality of DEVS thatmodels of numerous other formalisms can be for-mally mapped onto DEVS models18. This fact,combined with the decades of systems engineeringresearch in the area, should convince simulationusers in other fields that DEVS can accommodatetheir modeling objectives without restricting themto a specific paradigm. Nevertheless, our observa-tions suggest that DEVS remains unused by manycommunities of simulation practitioners in need ofa common yet flexible strategy to facilitate collab-oration. We do not believe this reflects any fun-damental limitation of the theory. Based on ourown early encounters with the approach, we be-lieve DEVS could achieve more widespread adop-tion if it entailed less effort, or rather a lower per-ceived cost in attention, to learn. In other words,we believe that a lack of approachability is the keyfactor impeding the use of DEVS.

The approachability of DEVS relates in part toits history. The formalism was largely inspiredby earlier work in Systems Theory, notably thatdescribed in the book A Mathematical Theory ofSystems Engineering 19. This deeply rooted math-ematical perspective contributes to a number ofpractical benefits for expert users. For example,there is a formula that expresses the “legitimacy”of a model specification. In simplified language,legitimacy indicates that a model will allow a sim-ulator to progress through a simulation run with-out getting stuck. Many systems engineers havelearned DEVS by studying these theories. How-ever, the effort it takes to interpret mathematicaldescriptions of the formalism can become a deter-rent for simulation users in other fields.

One must also acknowledge that DEVS requires

users to develop a mental model of the simulationprocedure that may be at odds with their pastprogramming experience. Many potential DEVSusers will have first learned the imperative styleof programming, which represents computationsin the context of control flow. Given an impera-tive program, a programmer can readily trace thepossible execution paths from one line to the next.Control flow is somewhat hidden with DEVS, asan atomic model defines the functions δext , δint , λ,and ta but does not express the flow of executionbetween them. This separation of the simulationprocedure from the models is what enables thedevelopment of reusable simulators and the rapidintegration of simulation models. It makes DEVSmore useful, but unfortunately less approachable.

Past work has addressed the approachabilityof DEVS through various types of contributions,the most obvious of which is the writing of ac-cessible sections, chapters, and books introducingthe theory. The textbook Wainer 20 is notable inthat its detailed description of a DEVS simula-tor, a seemly fundamental topic, is deferred un-til seven chapters on domain-specific applicationshave been presented.

DEVS can also be made more approachableby re-expressing parts of the theory. Presentingthe DEVS++ library, for example, Hwang 21 re-expresses atomic models by merging the internaltransition function δint with the output functionλ. The resulting function is denoted δy to empha-size its relationship with the output set Y , andsimilarly the external transition function δext isdenoted δx to relate it to the input set X. Gold-stein et al. 22 argue that similar deviations fromthe theory can be found wherever DEVS modelsare mapped from mathematical specifications ontocomputer implementations. The authors proceedto recommend a number of changes to the originalformalism specifically intended for DEVS-basedtools. Some of these changes promote computa-tional efficiency but others might make the theorymore approachable.

Helping programmers approach the formalismoutlined in (1), which is known as Classic DEVS,is only one of the objectives of most introductorymaterial on the subject. Typically there is also anintention to make a vast amount of related sys-tems engineering literature more accessible. This

Page 6: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

6 Designing DEVS Visual Interfaces for End-User Programmers

literature includes numerous extensions to the the-ory, technological contributions, applications, andvariants of the formalism. The best known variantis the Parallel DEVS formalism23, which betterexploits parallel computing technology for isolatedsimulation runs. A notable variant named Easy-DEVS aims to make the theory more approachableby unifying Classic DEVS and Parallel DEVS intoa single formalism24.

When introducing DEVS with the objective ofmaking the entire literature more accessible, itis clearly advantageous to adhere to establishednaming and modeling conventions. All works citedabove use traditional nomenclature to a large ex-tent. Nevertheless, it is interesting to considerwhether simulation users from other communi-ties might find DEVS more approachable if itwere explained using familiar terms and with onlyminimally necessary links to systems engineer-ing. Efforts have been made to exploit establishedconventions within particular areas of expertise.For example, Mooney and Sarjoughian 25 com-bine DEVS with the Unified Modeling Language(UML), which is popular among software engi-neers. The DEVS/UML combination is clearlyuseful, but does not align with our user commu-nities, whose members understand mainly basicimperative languages and visual programming in-terfaces. While interpreting DEVS through UMLmakes DEVS accessible to the software engineer-ing community, our work further expands this tocommunities that practice more basic program-ming skills and techniques.

2.3 Existing visual interfaces for DEVS

To make DEVS more approachable through thedesign of visual interfaces, one may build uponprevious work on domain-independent DEVS-based simulation environments. Several of thesetools feature interfaces that lower the perceivedcost, and in many cases the actual cost, of learn-ing and applying various aspects of DEVS theory.

Visual node editing interfaces provide a meansof viewing and editing coupled models in DEVS-based simulation environments such as Pow-erDEVS26, CD++ Builder27, and GVLE28. Suchinterfaces alleviate the need for textual specifi-cations of coupled model components and the

links between them. They help to distance usersfrom the mathematical elements of the formal-ism, in some cases for atomic models as well ascoupled models. For example, PowerDEVS pro-vides a library of pre-implemented atomic models,and a user new to DEVS can prepare a simula-tion by simply creating instances of these atomicmodels and visually connecting them. Graphicalediting of compositional models is very commonin non-DEVS simulation environments such asSimulink29, Xcos30, Ptolemy II31, and Dymola32,to name a few. The discrete-event simulation en-vironment OMNeT++33 allows both textual andgraphical editing of coupled models, and editingin either interface causes the other to be updatedautomatically.

Visual interfaces that show the transfer of infor-mation between events serve at least two impor-tant roles. First, they reveal to a novice user bothcorrect and false assumptions in their understand-ing of the simulation procedure. Second, they as-sist all users in debugging their models. Exist-ing simulation environments demonstrate multi-ple ways to represent this dynamic information.A timeline interface such as the Sequence Chartin OMNeT++ plots events in order of occurrence,along with arrows representing messages betweenevents. Both OMNeT++ and the MS4 Me simu-lation environment34 feature an alternative styleof interface in which messages are not plotted butrather animated in sequence. By animating datatransfer along the links of the node editing inter-face, a user may more easily relate occurrencesin the simulation run to elements of the coupledmodel. On the other hand, the timeline’s ability tosimultaneously display events and messages over aperiod of simulated time may be useful for observ-ing certain patterns. Our interest is in achievingthe benefits of both styles of interface by designingtimelines exhibiting visual similarities with modelrepresentations.

To simplify programming of the atomic mod-els, DEVS-based simulation environments supporttemplating in various forms. For example, CD++Builder and MS4 Me can generate class defini-tions with all the required member functions, sothat the programmer need only provide the bodyof each function. PowerDEVS separates atomicmodel functions into different tabs in the inter-

Page 7: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

Maleki et al. 7

face, hiding the visual complexity of an object-oriented class. These templating techniques allowusers to focus their concentration on the logic oftheir models rather than tool-specific syntacticalconventions. That said, the user must still have asolid understanding of DEVS at the outset, sinceotherwise he/she will not know when each functionis invoked nor how data is transfered from functionto function. The challenge for future interfaces isto continue to guide the user in authoring a modelwhile also clarifying the simulation procedure andthe role of each function with respect to data.

A number of existing DEVS-based tools allowusers to approach DEVS indirectly by startingwith fully diagrammatic modeling paradigms. Forexample, both MS4 Me and CD++ Builder in-clude State Diagram editors in which nodes rep-resent assignments to state variables and linksdescribe transitions between these assignments.State Diagrams and other fully diagrammaticmodels can be automatically converted into DEVSmodels, so in a sense their authors are usingDEVS. However, our interest lies in visual inter-faces that not only produce DEVS models but alsocommunicate the distinguishing aspects DEVStheory.

3 Re-expressing DEVS theory

The primary objective of this work is to designvisual interfaces that help end-user programmersarrive at some reasonable interpretation of the for-malism, and it is important to acknowledge thata wide range of interpretations are possible. Wemust first develop a clear picture of how we wishusers to interpret the formalism, as only then canthe visual interfaces be designed accordingly.

If our goal were to teach users the mathemat-ics of the formalism, the visual interfaces mightdisplay symbols such as δint , and the associatedfunctions would be labeled with “internal transi-tion function” and other well-established names.We decided to take a different approach and aimto help users bridge from their general and do-main knowledge to a qualitative but effective un-derstanding of how to use DEVS. Because weare tailoring our interfaces not for systems engi-neers but for programmers in other domains, we

take great liberties in proposing our own names tomake DEVS more approachable. We explain eachdeparture from the literature.

We begin with the word “model”, which evokesdifferent interpretations for experts in different do-mains. Consider for example a simulation of heattransfer through a building. To the DEVS expert,the relevant “model” is that of the heat transferprocess, and, if it is an executable model, it willrequire building geometry as initial input data. Toan architect, by contrast, the heat transfer processis part of a solver while the building geometry isthe “model”. Thus this single word may becomean early source of confusion when DEVS is firstintroduced to an architect, and the same can besaid of many other types of simulation users.

To address the inevitable overloading of theword “model”, we advocate the use of more spe-cific terms wherever possible. Consider the fourstatements below:

1. In the proposed model, the withdrawal requestmust be rejected if amount > balance.

2. The bank machine model is defined as〈X,Y, S, δext , δint , λ, ta〉, where X = {(p, v) |p = “Arriving Customer” ∧ ...

3. Open the atomic model by selecting the file“bank machine.java”.

4. When the model receives an “Arriving Cus-tomer” message, it computes the service du-ration.

The first model is likely a conceptual model.The second is a specification that may formal-ize the conceptual model. The third is an exe-cutable description of a bank machine, or ratherof a class of bank machines that can be instan-tiated by suppling parameters. The executabledescription may implement the specification. Thefourth “model” represents an individual bank ma-chine in the context of some scenario; it may bean instance of the executable description. Whenexplaining DEVS to a broad audience, we wouldminimize the use of “model” by favoring “concep-tual model”, “DEVS model specification”, “DEVSclass”, or “DEVS instance” in situations corre-sponding to those above.

Page 8: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

8 Designing DEVS Visual Interfaces for End-User Programmers

We acknowledge that these conventions are a de-parture from the literature. Systems engineers willpoint out that “a DEVS model specification” maysimply be called “a DEVS”, but we expect this ab-breviation to cause confusion for some users. In-stead, the phrase “a specification” may be adoptedwhen “DEVS model” is implied by the surround-ing context. A more significant departure fromthe literature is our use of “class” and “instance”,which suggest a strong relationship to the similarlynamed object-oriented concepts. We believe thisanalogy is appropriate and will be helpful to ex-perts in the computational sub-disciplines of theirdomains. In fact, DEVS models are often im-plemented as object-oriented classes, and in thesecases the relationship is more than just an analogy.We note the word “model” has been identified as asource of confusion in non-DEVS modeling frame-works, and this confusion has even been linked tocostly user errors in managing model libraries35.

We turn our attention to the term “coupledmodel”, which follows from the coupling of sys-tems concept that predates DEVS. This well-establish terminology reflects a bottom-up per-spective on system composition, where pairwiseconnections between interacting subsystems areintroduced one at a time until the desired levelof complexity is achieved. Unfortunately, a “cou-ple” implies two of something, whereas a “cou-pled model” can in fact have any positive num-ber of components. We therefore find “compositemodel”, as used in the DEVS-based CoSMoS envi-ronment36, more approachable. In most cases wewould avoid “model” and explain to users that aDEVS class is either an atomic class or a compos-ite class. Similarly, a DEVS instance is either anatomic instance or a composite instance. Profes-sional programmers will be reminded of the Com-posite Design Pattern 37, which simplifies the rep-resentation of hierarchical structures in a mannerclosely related to the DEVS principle of closureunder coupling.

The word “component” is retained, but we re-mind ourselves that a component is strictly an el-ement of a composite class. A component rep-resents a DEVS instance, but the terms are notinterchangeable. In a simulation involving oneatomic class, there is one atomic instance but nocomponents. In a simulation involving one com-

posite class with four components assigned atomicclasses, there are four atomic instances plus onecomposite instance.

In the context of the theory, it is reasonable torefer to simply “an input” since DEVS models areassociated with only one form of influencing data:a value, affixed with a port name, received at somepoint in time. In practice, a parameter assignedat the beginning of a simulation run might alsobe considered “an input”. Similarly, “an output”could be interpreted as a timed (port name, value)pair as in DEVS theory, but it could also refer toa statistic calculated at the end of a simulationrun. We therefore avoid the use of “input” and“output” as countable nouns describing data, atleast where the names “parameter”, “message”,and “statistic” allow us to be more specific. Notethat a message is the value that is actually trans-ferred between DEVS instances, without any af-fixed port name.

Because parameters, messages, and statistics allpertain to information transferred to or from aDEVS instance, it is reasonable to organize allthree types of data using named ports. Bothatomic and composite classes are permitted tohave any number of any type of port. The fourtypes of ports are listed below along with the as-sociated type of data and the relevant phase of asimulation run:

• Initialization ports represent parameterswhose values are provided to the DEVS in-stance during the initialization phase thatstarts a simulation run.

• Simulation input ports receive messages dur-ing the simulation phase of a simulation run.

• Simulation output ports send messages duringthe simulation phase of a simulation run.

• Finalization ports represent statistics whosevalues are assigned by the DEVS instanceduring the finalization phase that concludesa simulation run.

The qualifiers “initialization”, “simulation”,and “finalization” allow several concepts to beintroduced with a great deal of symmetry. Forexample, there are initialization links, simulationlinks, and finalization links. Each link may only

Page 9: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

Maleki et al. 9

connect to the similarly named type of port. Eachlink directs its associated type of data, either aparameter value or a sequence of messages or astatistic value, during the similarly named phaseof a simulation run. One possible objection tothis scheme is the use of “simulation” to refer toonly one of the three phases. The justification isthat the other two phases, initialization and final-ization, rely only on familiar programming con-cepts. DEVS can therefore be described as build-ing upon a programmer’s preexisting knowledgethrough the incorporation of a simulation phaseand its associated time-related elements: mes-sages, simulation ports, simulation links, and sim-ulation events.

A simulation event represents a self-containedset of computations associated with a particularDEVS instance and a single point in simulatedtime. For an atomic instance, every simulationevent is associated with an invocation of either aninternal or external state transition function. Weobserve that the name “internal transition func-tion” can be regarded as an abbreviation of “in-ternally triggered state transition function”. Al-though the full 12-syllable phrase is prohibitivelylong, the omission of “state” conceals the type ofobject that is transitioning, while the omission of“triggered” leads to ambiguity. If a user assumesthat “internal” and “external” refer to the scopeof a transition’s effects, he/she might incorrectlyassociate internal and external transitions with,respectively, the input and output of messages.

After searching for relatively short names thatunambiguously differentiate the two types of sim-ulation events, we settled on “planned event” and“unplanned event”. A planned event is an inter-nally triggered event that was at one time sched-uled, but at some point actually occurred. Notethat in a discrete time simulation, all events are“planned” in the sense that their timing is knownat the outset; appropriately, such simulations haveonly planned events. A unplanned event is an ex-ternally triggered event that effectively cancels theupcoming planned event due to the “unplanned”arrival of a message.

The functions associated with planned and un-planned events are, respectively, the planned eventhandler and the unplanned event handler. Weuse “handler” in place of “function” to distinguish

these atomic class elements from the more generalfunctions with which all programmers are familiar.Event handlers differ from regular functions pri-marily in their relationship with time. The valueknown as the “elapsed time” is preserved, but werefer to it as the elapsed duration. The word “du-ration” better reflects the fact that this quantityis measured relative to a previous event, as op-posed to the beginning of the simulation. Whatis known as the lifetime of the state, or formallyta(s), can instead be referred to as the plannedduration. The name “planned duration” exhibitsa helpful symmetry with “elapsed duration”, andalso emphasizes the fact that a “planned” eventwill occur should this duration of time elapse.

Having proposed a reasonably comprehensiveset of names to describe DEVS to an end-user pro-grammer, we are now ready to apply these phrasesin the design of visual interfaces. Beforehand, letus briefly reflect on several principles from the cog-nitive dimensions of notations framework that pro-vide a general rationale for the new names.

When choosing a name, closeness of mapping(cd)

suggests that its meaning in a DEVS contextshould map closely to its meaning in a context al-ready familiar to the user. This affirms our restric-tions on the use of “model”, which carries numer-ous domain-specific meanings, as well as our avoid-ance of “coupled” so as not to imply “a pair”. Webelieve that “class”, “instance”, and “composite”avoid misleading associations and map closely toobject-oriented concepts that are growing in pop-ularity even among novice programmers.

When a name is used in a DEVS-related con-text, it should always carry the same meaning.Our names promote this type of consistency(cd) ina preemptive fashion. For example, it is likelythat, at various points in a user’s experience withDEVS, “input” will be applied to some sort of ini-tial value as opposed to a value received at a pointin simulated time. Such inconsistencies are diffi-cult to avoid, unless one actively promotes the useof more specific terms such as “parameter” and“message”.

It is common to encounter trade-offs betweencognitive dimensions. A clear example of thisis the widespread avoidance of “internally trig-gered state transition function” in favor of “inter-nal transition function”. The first phrase clearly

Page 10: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

10 Designing DEVS Visual Interfaces for End-User Programmers

suffers from diffuseness(cd) due to its length, butthe latter gives up role-expressiveness(cd) to somedegree by omitting two words that help describethe element. We consider “planned event han-dler” to be a sufficiently short and reasonably role-expressive alternative. The phrase “lifetime of thestate” and the semantically equivalent expression“ta(s)” exhibit the same trade-off, and for thatreason we prefer “planned duration”.

4 Designing visual interfaces

4.1 Atomic class interface

Unlike their composite counterparts, atomicclasses are structurally similar to one another.They all have the same four event handlers, andeach handler is always linked with a particular oneof the four types of ports. To mirror this struc-tural consistency in interactive consistency(cd), avisual atomic class interface should show all portsand handlers of an atomic class in one place, andallow a user to design a new class by essentially“filling in the blanks”. We acknowledge that thislevel of assistance may not be necessary for a sys-tems engineer already familiar with DEVS theory.For an end-user programmer, however, a compre-hensive, template-like visual interface may act asa valuable learning aid as well as a practical pro-gramming tool.

Figure 1(a) illustrates our proposed atomic classinterface as it might appear when exploring orenhancing a hypothetical “Bank Machine” class.The fact that there are four types of ports conve-niently allows them to be grouped at the cornersof the interface. By scanning the corners in left-to-right, top-to-bottom order, we see quickly thatthe Bank Machine has 3 initialization ports rep-resenting parameters, 2 simulation input ports forreceiving messages, 4 simulation output ports forsending messages, and 2 finalization ports repre-senting statistics.

Arranged in a diamond-shaped configuration,the four event handlers exhibit the following sym-metries:

• Each row of handlers is associated with a par-ticular phase: initialization, simulation, final-ization.

• The upper three handlers compute planneddurations (arrows lead to the clock symbol).

• The lower three handlers observe elapsed du-rations (arrows lead from the clock symbol).

In order to reduce the number of handlers to thefour shown, a number of conventions were adoptedfrom existing DEVS tools. The time advancefunction ta is absorbed into the upper three han-dlers, as is done in DEVSJAVA38 and CD++20.Users of this interface will therefore learn about“planned durations” in place of ta. Also, the out-put function λ is absorbed into the planned eventhandler (i.e. internal transition function). As inDEVS++21, this deviation from the mathemati-cal formalism emphasizes the symmetry betweenunplanned and planned events with respect to sim-ulation input and output ports. As recommendedby Goldstein et al. 22 , a single planned event mayproduce multiple messages. This is convenient inthe case of the Bank Machine class, assuming thedeparture of a “Served Customer” is modeled tocoincide with an “Account Change” message com-municating the result of a withdrawal or deposittransaction. The Appendix provides a mappingbetween this adaptation of DEVS and the classicversion of the formalism, showing that they areessentially equivalent.

Having identified the most prominent elementsof the atomic class interface, we turn our attentionto more specific design decisions and the cognitivedimensions they promote. These decisions addressvarious user needs we consider at high risk of beingneglected in DEVS-based software.

A user needs to understand the simulationprocedure as they develop an atomic class.The separation of model and simulator is an es-sential principle of DEVS, but it is important that“separation” be interpreted as “semantically dis-tinct and independent” as opposed to “visuallyseparated”. It is common in DEVS tools for thesimulation procedure to be hidden from users, orshown only in the documentation. This lack of vis-ibility forces the users to imagine the simulationprocedure in their head, or to switch their atten-tion back and forth between the documentationand the model interface in an effort to determinethe order of events. The timing of events may also

Page 11: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

Maleki et al. 11

(a) The atomic class view (b) The atomic class code view

Figure 1. The visual interface of the atomic class with handlers collapsed (a) and expanded (b).

be unclear to an inexperienced user. He/she maydiscover from the code how the planned durationis calculated, yet fail to understand when the sim-ulator actually applies this duration and advancesthe simulation time.

To increase the visibility(cd) of the simulationprocedure, and to reduce hard mental opera-tions(cd) in determining the order of events, weuse arrows, decision points, and loops to show theflow of program execution. The decision pointsin Figure 1(a) indicate that if the “Planned dura-tion...” has “elapsed”, a planned event occurs; if itis “Interrupted by...” an “incoming message”, anunplanned event occurs; if it is “Interrupted by...”the “end of simulation”, finalization occurs. Ob-serve that the point in the procedure where timeadvances is marked by a clock symbol, promotingcloseness of mapping(cd) between simulation timeand a user’s preexisting knowledge of time.

The interface in Figure 1(a) combines modeland simulator elements from a visual standpoint,yet keeps the model and simulator semanticallyseparate. To maintain this separation, the keyprinciple is that the only elements of the inter-face that may change are those related to themodel: the number of ports, the names of theports, and the code within each handler. Thethick gray arrows, loops, decision points, and clocksymbol are simulator elements that appear thesame for all models and remain unchanged as mod-els are developed. The distinction between ed-itable model elements and non-editable simula-tor elements, which can be further emphasized byhighlighting editable objects when hovered, shouldhelp the user discover that with DEVS he/she hasneither the ability nor the need to alter the simula-tion procedure. In fact this fundamental conceptcan be explicitly stated in a dialog box that would

Page 12: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

12 Designing DEVS Visual Interfaces for End-User Programmers

appear if a user attempts to alter a simulator ele-ment by clicking on it. Users will be familiar withthe locking of cells in an Excel spreadsheet: oneof many examples of editable and non-editable ob-jects juxtaposed in a helpful way.

A user needs to understand the role of eachhandler in observing and computing data.In DEVS theory, the input and output of everyfunction is expressed mathematically with state-ments such as δext : Q × X → S. Systems en-gineers typically learn these statements prior tousing DEVS in a programming environment, butend-user programmers need the software to firstinform and later remind them of the role of eachhandler with respect to data.

To indicate the flow of data into, out of,and among the four event handlers, our atomicclass interface combines the procedural repre-sentations mentioned above with elements fromdataflow programming. This increases the role-expressiveness(cd) of each handler. As shown inFigure 1(a), the visual interface also uses shapes,colors and orientations to distinguish between dif-ferent types of data and their respective ports.Initialization and finalization links are pale goldin color, and flow in a left-to-right direction. Sim-ulation links are blue with a top-down direction,carrying messages from the simulation input portsto the unplanned event handler and from theplanned event handler to the simulation outputports. State links, shown in gray, serve three pur-poses. First, as previously discussed, they play akey role in illustrating the simulation procedure.Second, they clarify the role of the handlers inobserving and modifying the state of an atomicinstance. Third, they draw attention to possi-ble hidden dependencies(cd) between handlers: astate change produced by one handler may influ-ence computations in any downstream handler.

A user needs to relate sections of code toone another and to other atomic class el-ements. When the DEVS formalism is used topresent an atomic model specification, each func-tion is defined by a separate formula identified bya variable: δext , δint , λ, or ta. Similarly, whena visual interface is used to program an atomicclass, each handler may be coded in a separatetext area identified by a label: “Initialization”,

“Unplanned Event”, “Planned Event”, or “Final-ization”. But whereas examples of atomic modelspecifications often fit on a page, we cannot ex-pect all of an atomic class’s code to fit on a com-puter screen. An obvious way to address screensize limitations is to place each handler’s code in ascrollable text area on its own tab. Unfortunately,this design may prevent a user from simultane-ously viewing related sections of code in differenthandlers. Another option is to dedicate a separatefloating window to each hander. Floating windowsmay provide too much flexibility, however, mak-ing it hard to remember which handler was placedwhere. Aside from the issue of displaying multi-ple sections of code, it important for an end-userprogrammer to relate the code to the simulationprocedure and data flow logic.

To help users view sections of code in a helpfulcontext, we envision the use of animated transi-tions to expose handler code in two stages. Inthe first stage, the four handler compartments inFigure 1(a) expand, revolve around their commoncenter by roughly 45◦, and acquire scrollable textareas as shown in Figure 1(b). Juxtaposing thefour event handlers in this fashion reveals hiddendependencies(cd) between them at the level of thecode. Where possible, the ports and links of Fig-ure 1(a) are retained in Figure 1(b) to remindusers of each handler’s relationship with the sim-ulation procedure and various types of data. Portstyles and link colors are maintained, promotingconsistency(cd). In the second stage, a user may fo-cus on a single handler by expanding the selectedcompartment in Figure 1(b) to completely coverthe other three compartments.

A user needs to correct and/or confirmhis/her understanding of the simulationprocedure and atomic class code. Under-standing barriers, according to Ko et al. 39 , emergewhen end-user programmers cannot evaluate thebehaviour of the program relative to their expecta-tions. In other words, even when they think theyunderstand the simulation procedure, the programdoes something they did not expect. Ko et al. 39

also report information barriers occurring whenusers catch an error or unexpected behaviour, butdo not know what causes it and how to go aboutfixing it. Increasing the visibility(cd) of the simula-

Page 13: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

Maleki et al. 13

Figure 2. The atomic class debugging tool, consisting of the code view and the visualization of events with messagesand state variables displayed in the timeline on demand.

tion procedure in the context of specific runs, andmaintaining its connection with the atomic classcode, help in lowering understanding and informa-tion barriers.

Figure 2 shows the visual design of the atomicclass debugging tool, which consists of the atomicclass code view on the left and a timeline interfaceon the right. When a simulation is run, unplannedevents (purple bars near the top of the interface)and planned events (green bars near the bottom)appear on the timeline. There they exhibit thesame colors as their corresponding handlers in theatomic class interface to maintain consistency(cd).Ports and events in the timeline are aligned withthe code view to reduce hard mental operations(cd)

involved in relating the two views. To furtheremphasize related elements, hovering over an ob-ject in one view may produce highlighting in bothviews.

The debugging tool allows the user to watchvariables and messages to aid in finding the sourceof errors and fixing them. The horizontal align-

ment of variables and messages along a time axisis common practice for static diagrams and is alsoseen in the DEVS-Suite simulation tool40. A fea-ture more unique to the proposed interface is thevertical alignment of ports between views, as wellas the alignment of the upper/lower boundariesof unplanned/planned events and their respectivehandlers. This arrangement of elements gives riseto a large region in the center of the timeline wherestate variables can be visualized. Seven variablesare shown in the middle of the timeline in Fig-ure 2. The timeline navigation tool at the topallows the user to go back and forth in time andtrack these variables over time, reducing the needfor breakpoints to stop the process before it crashesand println statements to observe past values ofvariables41. We acknowledge that the elements inthe timeline will have to change dynamically asthe user zooms out to reveal thousands of events.Multiscale widgets such as FacetZoom42 may helpthe debugging tool scale to accommodate complexatomic classes and simulation runs.

Page 14: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

14 Designing DEVS Visual Interfaces for End-User Programmers

Figure 3. The visual interface of the composite class on the left, which is accompanied by the visualization of eventson the right in the composite class debugging tool.

4.2 Composite class interface

As observed in Section 2.3, visual node editing in-terfaces are a common alternative to textual inter-faces for the implementation of composite models.This style of interface is arguably the most promi-nent instance of visual programming applied insimulation environments, and it serves as a start-ing point for our own composite class interface.One unusual feature of our interface is that thecomponents are always placed in a cascading ver-tical arrangement. This layout is shown on theleft of Figure 3 for a “Bank” model consisting ofa lineup for a Bank Machine, the machine itself, alineup for a Bank Teller, and the teller itself. Theuser may reorder the components, in which casethe affected links should be re-positioned automat-ically. Observe that the cascading of the compo-nents reduces the number of necessary link turns,

lowering diffuseness(cd). Also note that our pref-erence for a familiar top-to-bottom, left-to-rightcascade is one of the justifications for placing thesimulation input and output ports on the top-rightand bottom-left corners. We explain how this ver-tical layout and other design decisions address theneeds of end-user programmers.

A user needs to understand the relationshipbetween atomic classes, composite classes,and components. Atomic and composite modelspecifications differ significantly in structure andappearance. It is therefore expected that a typicalDEVS-based tool will provide two very different-looking interfaces: one or more code editors foran atomic class, and a node editor for a compositeclass. Unfortunately, this inconsistency in visualrepresentation means that users may not necessar-ily transfer what they learn from one interface to

Page 15: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

Maleki et al. 15

the other. For example, a user may be slow to rec-ognize that both types of classes feature the sametypes of ports, communicate using same types ofdata during the same phases of a simulation run,and can be assigned to components of a compositeclass.

The similarities between atomic and compositeclasses can be emphasized wherever appropriateby maximizing consistency(cd) between the visualinterfaces of atomic and composite models. First,the outermost compartment that represents an en-tire class is the same shape for the atomic class inFigure 1(a) and the composite class on the left ofFigure 3, with ports placed in the same locationsand drawn with the same styles. Observe that thesame style of compartment is also used for the fourcomponents, suggesting they are associated withclasses of either type. Finally, although they werenot required by DEVS theory, we included linksin the atomic class interface to help users identifythe same types of data in the composite class in-terface. In both interfaces, messages are directedby blue simulation links that connect to ports ina downward direction.

A user needs to relate the elements of acomposite class to events and messages in asimulation run. Like its atomic counterpart, acomposite class consists of static elements repre-senting dynamic behaviour, and a user may havedifficultly understanding this model-simulation re-lationship. In the case of a composite class, it isparticularly difficult to explain how time advanceswithout showing case-specific sequences of events,as well as the transfer of information from oneevent to another. Such visualizations are thereforeessential for helping end-user programmers learnDEVS, and may also serve as a valuable debug-ging aid for all users. The challenge for interfacedesigners is to show the sequence and timing ofevents, the flow of data, and the composite modelitself such that all elements can be related to oneanother.

When a simulation is run, the composite classinterface may be accompanied by a timeline ofevents and messages as illustrated in Figure 3.The vertical layout of components in the class in-terface allows them to be aligned with the time-line events of the corresponding DEVS instances.

This eliminates the need for additional labels onthe timeline, and promotes juxtaposibility(cd) withregard to modeling and simulation elements. Theports are also aligned between the class interfaceand timeline, reducing hard mental operations(cd)

in determining which link is responsible for a giventransfer of data. For the sake of consistency(cd),the colors of planned and unplanned events in thetimeline match those of the corresponding han-dlers in the atomic class interface.

A user needs to be mindful of the order-ing of simultaneous planned events. In the-ory, this is determined by the tie-breaking func-tion Select . In practice, most simulators priori-tize the component closest to the front of a user-defined list, and the manner in which this list isvisually represented can affect the likelihood of afalse assumption about which messages may pre-empt which events. For example, unless the listis an integral part of the interface, the user maysimply forget how the components are ordered. Amore subtle issue is whether a user understandsthat simulation links have slightly different rolesdepending on whether they approach higher- orlower-priority components.

In addition to promoting alignment with thetimeline, the vertical layout of our composite classinterface implies an ordering of components. Thehigher a component is located in the diagram, thehigher its priority. This concept should be eas-ily understood due to its closeness of mapping(cd)

with a user’s mental model of organizational hi-erarchies: higher positions are generally associ-ated with higher priorities. The convention alsoproduces a visual distinction between upward anddownward simulation links. This promotes role-expressiveness(cd) once the user understands thatonly a downward link, which approaches a lowerpriority component, is able to preempt an immi-nent planned event by triggering an unplannedevent instead.

A user needs to manage data dependenciesduring initialization and finalization. TheDEVS formalism does not provide mathematicalelements for initialization and finalization, and wenote that a number of specification properties suchas legitimacy can be formally analyzed withoutthis information. In DEVS-based tools it is com-

Page 16: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

16 Designing DEVS Visual Interfaces for End-User Programmers

Figure 4. The initialization and finalization view of the composite class interface, featuring dataflow programmingelements such as the Accounts and Waiting Customers nodes.

mon practice to include parameters and initializa-tion functions in atomic classes, but not compos-ite classes. The reason is that the user is gener-ally permitted to initialize a composite instance byassigning parameters directly to each component.Unfortunately, this functionality may hide depen-dencies(cd) among component parameters. For ex-ample, suppose that both the Bank Machine andBank Teller atomic classes have an Exchange Rateparameter. When these classes are assigned tocomponents of the Bank composite class, the needto keep the Exchange Rate parameters consistentimposes an uncomfortable burden on the user.

Our composite class interface can be expandedhorizontally to reveal initialization and finaliza-tion elements, as illustrated in Figure 4. This viewis heavily influenced by dataflow visual program-ming, which is suitable for the task of initializ-ing component parameters as it reduces hidden de-pendencies(cd) on the parameters of the compositeclass. These dependencies may take several forms:a 1-1 mapping, as demonstrated by the Machine

Lineup Capacity parameter; a 1-many mapping,as demonstrated by the Exchange Rate parame-ter; and a computation, as demonstrated by theAccounts initialization node that generates an ini-tial set of customer balances for both the Machineand Teller components. As is typical in dataflowprogramming, the initialization and finalizationlinks form a directed acyclic graph. Note that thecolor of these links, their left-to-right orientationat port connections, and the style and placementof the initialization and finalization ports distin-guishes parameter- and statistic-related data frommessage data, promoting consistency(cd) with theatomic class interface.

Our target community is accustomed to usingdataflow programming to both specify and trans-form objects in their domain. In dataflow pro-gramming, a node represents a function that maybe evaluated once values become available on all ofits input ports. We include examples of such user-defined functions in both the initialization and fi-nalization steps to demonstrate that users can en-

Page 17: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

Maleki et al. 17

Figure 5. The overall view of the composite class interface

capsulate these functions in the places where theywill be used. Initialization and finalization func-tions, such as those represented by the Accountsand Waiting Customers nodes, do not contradictDEVS since they are invoked only before and af-ter the simulation process where time advances. Inother words, they are external to the execution ofa DEVS-based simulation. We argue that thesedataflow programming elements will help usersbetter connect simulation to the domain modelsthat are the users’ primary focus.

We believe there is a strong case for incorporat-ing elements of dataflow visual programming atleast for the initialization of component parame-ters. Providing similar elements for finalization,as shown on the right-hand side of Figure 4, com-pletes what we intend to be a very symmetricalmental model of DEVS. Experts may argue thatthe processing of statistics belongs in a separatetransducer class associated with the experimentalframe as opposed to the representation of a real-world system. Without taking a firm stand on thisissue, we suggest that our finalization elements

provide a mechanism for processing statistics inany class. Once this mechanism is understood bythe user, it is possible to recommend a set of bestpractices which may include the consolidation ofstatistics in transducer classes. For the sake ofrole-expressiveness(cd), we would prefer not to usethe term “transducer” but rather “analysis class”.

Figure 5 shows the full view of the compositeclass, where message links and initialization andfinalization elements are overlaid. It is up to theuser to choose among the three composite classviews based on what data is relevant for the taskat hand. We envision an environment that com-plements these views with an interface that allowsthe user to manually rearrange the nodes. Man-ual layouts common to existing simulation toolsremain beneficial for two reasons: to minimize linkoverlap or to use the alternative layout as a formof secondary notation(cd). Ultimately, we want tobe able to combine the system’s automatic layoutand the user’s manual layout in a meaningful way.

Page 18: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

18 Designing DEVS Visual Interfaces for End-User Programmers

5 Discussion and conclusion

We view this paper more as demonstrating an ap-proach making DEVS easier to learn and use fora potentially large community of users who knowmuch about the phenomenon they want to simu-late but little about DEVS, and less as a demon-stration of a new interface for DEVS. To this endwe have presented both design decisions and ra-tionale, the latter using concepts from end-userprogramming and the cognitive dimensions of no-tations.

Any reliable evaluation of our interfaces requiresimplementation and user studies. Even the namesunderlying an interface, such as the names pro-posed in Section 3, lend themselves to system-atic investigation once they are embedded in soft-ware. One methodology for investigating namingconventions involves the recording and collabo-rative examination of programming-related con-versations, as demonstrated by Katzenberg andPiela 35 . In the results of user studies on vocabu-lary and visual interfaces, we can expect both con-firmation of our approach and evidence of trade-offs that must be made. Cognitive dimensions the-ory predicts that improvements in one dimensionmay be linked to problems created for others. Inthe following, we predict several such trade-off ef-fects.

The presented interfaces will increase overall dif-fuseness(cd)when compared with a standard texteditor interface to the simulation code. It is verydifficult to improve on the compactness of text,especially when a programmer takes advantage offunctions for reusable elements and modern pro-gramming language features such as inheritance.On the other hand, these abstraction(cd) mech-anisms tend to increase hidden dependencies(cd),which should be addressed in a visual interface.Still with the issue of functions and inheritance,the absence of devices for these in the interfacewill make it less abstract(cd). However, compos-ite classes are an abstraction(cd)mechanism, whosepurpose is to improve role-expressiveness(cd)andcloseness of mapping(cd), but require devices suchas careful link layout to reduce hard mental oper-ations(cd). Of course, further design informed bycognitive dimensions may improve these trade-offsituations.

As a consequence of increased diffuseness(cd),our visual interfaces and others like them will notscale easily as DEVS classes grow in size. Atomicclasses grow primarily in the internal complexityof their four main user-defined parts: the handlersfor initialization, finalization, planned events andunplanned events. However, these structures canand do become complex, requiring additional user-defined functions. Composite models may presentlarger problems, particularly if they grow by ac-cretion in an iterative process of simulation devel-opment. We should expect to see this problem ad-dressed in several ways: through deepening of themodel hierarchy (extracting subsets of the com-ponents into new composite classes), through se-mantic zoom in which the visualization of a modelchanges with its size (the smallest possible visu-alization being a pixel and the largest one thatfully displays all parts of a model); model com-pilation in which models become black boxes to auser; and by the brute force method of increasingdisplay size (the cost of which is falling dramat-ically, but which is limited by human vision andattention constraints).

Further delving into composite classes revealsboth benefits and trade-offs in other cognitivedimensions. A composite class comprising onlyatomic components could quickly become ex-tremely diffuse(cd). Extracting multiple atomic (orcomposite) components and encapsulating themwithin a new composite class presents a sin-gle concept to a user. This may improve role-expressiveness(cd)in cases where the grouped com-ponents collectively perform a well-defined func-tion in the context of a system, or it may pro-mote closeness of mapping(cd)if the new group re-flects a familiar real-world object. However, whenexpressed as a single node, a composite class in-creases hidden dependencies(cd): what is the re-lation between incoming and outgoing messages?Also, which component addresses a particular as-pect of a simulation? This problem increasessharply when other composite classes occur ascomponents. Fully answering the above questionsmay involve fully expanding the composite class toreveal all atomic classes, which would dramaticallyincrease diffuseness(cd)and may well decrease role-expressiveness(cd)as the sheer complexity of the dis-play may make it difficult to figure out what in-

Page 19: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

Maleki et al. 19

dividual components actually do. The design pre-sented here is not alone in facing this problem:handling such compositions is one of the primaryissues for all visual programming languages. How-ever, the devices of vertical ordering of compo-nents and port alignment present a novel approachto this enduring challenge.

Visual programming interfaces present new op-portunities for debugging, some of which we takeadvantage of in our current design and others weleave for future work. For example, juxtaposing(cd)

the debugging tool with the simulation interfaceand aligning their ports and nodes, liveness ofthe entire interface with highlighting of compo-nents across views43, and the ability to watchthe progress through the code line-by-line andthrough time event-by-event in one interface, allincrease visibility(cd)and role-expressiveness(cd)anddecrease error-proneness(cd)and hard mental oper-ations(cd)of the system and encourage progressiveevaluation(cd). These end-user programming ideasmight be combined with emerging research informalism-based simulation debugging, such asthe recent work by Mierlo et al. 44 .

We argue that the interface designs presentedhere may help DEVS tool designers improve thereception of their work. For example, by criticallyexamining established naming conventions froman end-user perspective, designers may improveboth learnability and ease-of-use once learned. Byusing cognitive dimensions analysis during design,designers may discover not only issues, problemsand trade-offs (for example, the trade-off betweensupporting abstraction(cd)and reducing hidden de-pendencies(cd)that occurs in composite classes),but also motivate and recognize potentially usefulnew design elements (such as the component cas-cade in the composite class interface). By adapt-ing our approach to other modeling formalisms,such as Parallel-DEVS, and other paradigms, suchas agent-directed simulation, designers may notonly improve the user reception of an entire classof tools, but also better reveal commonalitiesamong these diverse approaches. Clearly, we haveonly touched the surface here. It seems entirelysafe to claim that there is plenty of opportunityto make DEVS-based simulation more accessibleto non-DEVS end-user programmers who are ex-perts in the domain being modeled.

Acknowledgments

This work was supported by the Natural Sciencesand Engineering Research Council of Canada un-der an NSERC Engage Grant. We would like tothank Jeremy Mogk for his advice on readabilityof our figures by the colorblind. Of course, anyerrors in the color scheme are ours alone. GabrielWainer provided much useful advice on DEVS, forwhich we are grateful.

References

1. Woodbury R. Elements of Parametric Design.Taylor and Francis, 2010.

2. Reas C and Fry B. Processing: a programminghandbook for visual designers and artists, vol-ume 6812. Mit Press, 2007.

3. Ko AJ, Abraham R, Beckwith L, Blackwell A,Burnett M, Erwig M, Scaffidi C, Lawrance J,Lieberman H, Myers B, Rosson MB, Rother-mel G, Shaw M, and Wiedenbeck S. The stateof the art in end-user software engineering.ACM Comput. Surv., 2011, 43(3):21:1–21:44.

4. Davis AL and Keller RM. Data flow programgraphs. Computer, 1982, 15(2):26–41.

5. Oinn T, Greenwood M, Addis M, AlpdemirMN, Ferris J, Glover K, Goble C, Goderis A,Hull D, Marvin D, Li P, Lord P, Pocock MR,Senger M, Stevens R, Wipat A, and Wroe C.Taverna: lessons in creating a workflow envi-ronment for the life sciences. Concurrency andComputation: Practice & Experience., 2006,18(10):1067–1100.

6. Green TRG. Cognitive dimensions of nota-tions. In People and Computers V. UniversityPress, 1989, pages 443–460.

7. Ko AJ. Barriers to Successful End-UserProgramming. In Burnett MH, Engels G,Myers BA, and Rothermel G, editors, End-User Software Engineering, number 07081in Dagstuhl Seminar Proceedings, Dagstuhl,Germany, 2007.

Page 20: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

20 Designing DEVS Visual Interfaces for End-User Programmers

8. Blackwell AF. First steps in programming: arationale for attention investment models. InProceedings of the IEEE Symposia on HumanCentric Computing Languages and Environ-ments, Arlington, VA, USA, 2002, pages 2–10.

9. Burnett MM. Visual programming. Wiley En-cyclopedia of Electrical and Electronics Engi-neering, 1999.

10. Whitley KN. Visual programming languagesand the empirical evidence for and against.Journal of visual languages & computing,1997, 8(1):109–142.

11. Johnston WM, Hanna JRP, and MillarRJ. Advances in dataflow programming lan-guages. ACM Computing Surveys (CSUR),2004, 36:1–34.

12. Haeberli PE. ConMan: A Visual Program-ming Language for Interactive Graphics. InProceedings of the 15th Annual Conferenceon Computer Graphics and Interactive Tech-niques, SIGGRAPH ’88. ACM, 1988, pages103–111.

13. Green TRG, Blandford AE, Church L, RoastCR, and Clarke S. Cognitive dimensions:Achievements, new directions, and open ques-tions. Journal of Visual Languages & Com-puting, 2006, 17(4):328–365.

14. Jones SP, Blackwell A, and Burnett M. Auser-centred approach to functions in excel. InProceedings of the eighth ACM SIGPLAN in-ternational conference on Functional program-ming, Uppsala, Sweden, 2003, pages 165–176.

15. Green TRG and Petre M. Usability analysis ofvisual programming environments: A ‘Cogni-tive dimensions’ framework. Journal of VisualLanguages & Computing, 1996, 7(2):131–174.

16. Blackwell AF and Green TRG. A cognitive di-mensions questionnaire optimised for users. In12th workshop of the psychology of program-ming interest group, 2000.

17. Zeigler BP, Praehofer H, and Kim TG. Theoryof modeling and simulation: integrating dis-crete event and continuous complex dynamicsystems. Academic Press, San Diego, 2000.

18. Vangheluwe HLM. DEVS as a common de-nominator for multi-formalism hybrid systemsmodelling. In IEEE International Symposiumon Computer-Aided Control System Design,2000. CACSD 2000, 2000, pages 129–134.

19. Wymore AW. Mathematical Theory of Sys-tems Engineering. John Wiley & Sons Ltd,first edition edition edition, 1967.

20. Wainer GA. Discrete-Event Modeling andSimulation: A Practitioner’s Approach. CRCPress, 2008.

21. Hwang MH. DEVS++: C++ open source li-brary of DEVS formalism, 2009.

22. Goldstein R, Breslav S, and Khan A. Infor-mal DEVS conventions motivated by practicalconsiderations (WIP). In Proceedings of theSymposium on Theory of Modeling & Simula-tion, San Diego, CA, USA, 2013, pages 10:1–10:6.

23. Chow AC and Zeigler BP. Parallel DEVS: aparallel, hierarchical, modular modeling for-malism. In Proceedings of the Winter Simula-tion Conference (WSC), 1994, pages 716–722.

24. Traore MK. Easy DEVS. In Proceedings of theSpring Simulation Multiconference - Volume2, SpringSim ’07, San Diego, CA, USA, 2007,pages 214–216.

25. Mooney J and Sarjoughian H. A frame-work for executable UML models. In Proceed-ings of the Spring Simulation Multiconference,SpringSim ’09, San Diego, CA, USA, 2009,pages 160:1–160:8.

26. Bergero F and Kofman E. PowerDEVS: a toolfor hybrid system modeling and real-time sim-ulation. Simulation, 2011, 87(1-2):113–132.

27. Bonaventura M, Wainer GA, and CastroR. Graphical modeling and simulation ofdiscrete-event systems with CD++Builder.SIMULATION, 2013, 89(1):4–27.

28. Quesnel G, Duboz R, and Ramat E. TheVirtual Laboratory Environment – An oper-ational framework for multi-modelling, simu-

Page 21: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

Maleki et al. 21

lation and analysis of complex dynamical sys-tems. Simulation Modelling Practice and The-ory, 2009, 17(4):641–653.

29. MathWorks. Simulink: Dynamic System Sim-ulation for MATLAB. 2000.

30. Scilab Enterprises. Xcos for very beginners,2013.

31. Ptolemaeus C, editor. System Design, Mod-eling, and Simulation using Ptolemy II.Ptolemy.org, 2014.

32. Bruck D, Elmqvist H, Mattsson SE, and Ols-son H. Dymola for Multi-Engineering Model-ing and Simulation. In International ModelicaConference, 2002.

33. Varga A and Hornig R. An overview of theOMNeT++ simulation environment. In Pro-ceedings of the 1st International Conferenceon Simulation Tools and Techniques for Com-munications, Networks and Systems & Work-shops, SIMUTools ’08, ICST, Brussels, Bel-gium, 2008, pages 60:1–60:10.

34. Seo C, Zeigler BP, Coop R, and Kim D. DEVSmodeling and simulation methodology withMS4 Me software tool. In Proceedings of theSymposium on Theory of Modeling & Simula-tion, San Diego, CA, USA, 2013, pages 33:1–33:8.

35. Katzenberg B and Piela P. Work languageanalysis and the naming problem. Commun.ACM, 1993, 36(6):86–92.

36. Sarjoughian HS and Elamvazhuthi V. CoS-MoS: a visual environment for component-based modeling, experimental design, andsimulation. In Proceedings of the Interna-tional Conference on Simulation Tools andTechniques, SIMUTools, ICST, Brussels, Bel-gium, 2009, pages 59:1–59:9.

37. Gamma E, Helm R, Johnson R, and VlissidesJ. Design Patterns: Elements of ReusableObject-Oriented Software. Addison-Wesley,Reading, Mass., 1995.

38. Zeigler BP and Sarjoughian HS. Introduc-tion to DEVS Modeling and Simulation withJAVA: Developing Component-Based Simula-tion Models. Technical Document, Universityof Arizona, 2003.

39. Ko AJ, Myers BA, and Aung HH. Six learningbarriers in end-user programming systems. InProceedings of IEEE symposium on visual lan-guages and human centric computing, 2004,pages 199–206.

40. Zengin A and Sarjoughian H. DEVS-Suitesimulator: A tool teaching network protocols.In Proceedings of the Winter Simulation Con-ference (WSC), 2010, pages 2947–2957.

41. Lewis B. Debugging backwards in time. arXivpreprint cs/0310016, 2003.

42. Dachselt R, Frisch M, and Weiland M. Facet-Zoom: a continuous multi-scale widget fornavigating hierarchical metadata. In Pro-ceedings of the SIGCHI Conference on Hu-man Factors in Computing Systems, CHI ’08.ACM, 2008, pages 1353–1356.

43. Maleki MM, Woodbury RF, and NeustaedterC. Liveness, localization and lookahead: In-teraction elements for parametric design. InProceedings of the Conference on DesigningInteractive Systems, DIS ’14, 2014, pages 805–814.

44. Mierlo SV, Tendeloo YV, Mustafiz S, BarrocaB, and Vangheluwe H. Explicit modelling of aParallel DEVS experimentation environment.In Proceedings of the Symposium on Theoryof Modeling & Simulation, Alexandria, VA,USA, 2015.

Author biographies

Maryam Maleki is a recent Ph.D. graduate inhuman-computer interaction from Simon FraserUniversity. She is a user experience researcher anddesigner and is interested in end-user computingin expert systems, design support tools, and com-putational design.

Page 22: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

22 Designing DEVS Visual Interfaces for End-User Programmers

Robert Woodbury is a University Professor ofInteractive Arts and Technology at Simon FraserUniversity. He was founding Chair of the Gradu-ate Program in the School of Interactive Arts andTechnology at SFU and a Director of two pan-Canadian research networks. His main interest isaugmenting professional work by supporting state-space search in problem spaces. To parametric de-sign he has contributed a book, Elements of Para-metric Design, and numerous articles.

Rhys Goldstein is a Principal Research Scientistat Autodesk Research. His work explores discrete-event simulation and its use in the architectural,building science, and biological domains. He re-ceived the Best Paper award at the 2010 IBPSA-USA Conference for a method to customize simu-lated human behaviour.

Simon Breslav is a Principal Research Scien-tist at Autodesk Research. Simon completed aM.Sc. in computer science (specializing in com-puter graphics) from the University of Toronto.His current research interests include informationvisualization, human-computer interaction, userinterfaces for simulation, and simulation in the en-vironmental and ergonomics contexts.

Azam Khan is the Head of the Environment& Ergonomics Research Group at Autodesk Re-search. He has published over 60 papers insimulation-aided design, human-computer inter-action, and sustainability. He has also foundedseveral inter-organizational initiatives such as theParametric Human Project Consortium, the Sym-posium on Simulation for Architecture and Ur-ban Design (SimAUD), and the CHI Sustainabil-ity Community.

Appendix

With the objective of promoting DEVS utilizationin domains outside of simulation research and sys-tems engineering, the Introduction outlined thefollowing strategy: First, change the way DEVStheory is expressed to make it easier to learn froma user’s perspective. Second, make software con-sistent with the re-expressed DEVS theory. Third,design visual interfaces that emphasize and relatethe key DEVS concepts associated with every el-

ement of the users’ models and simulation runs.Having pursued this strategy throughout the pa-per, we find ourselves with an adapted version ofDEVS. Here we show that this adaptation remainsessentially equivalent to the classic version of theformalism.

We begin by comparing the simulation proce-dures associated with Classic DEVS, the mathe-matical elements of which are listed in Section 2.2,and our adapted version of DEVS, illustrated inFigure 1(a). To simplify the comparison, we omitthe classic sets X, Y , S that contain the permissi-ble values of input messages, output messages, andinstance states. These sets provide both a form ofdocumentation and a degree of reliability. How-ever, their realization in DEVS-based software de-pends on the programming language used, whichis beyond the scope of this paper. We therefore fo-cus on the four classic functions δext , δint , λ, andta, as well as the four proposed event handlersthat take the place of these functions.

The pseudocode listed in Algorithm 1 describesthe basic simulation procedure for Classic DEVS.The model and initial state s0 are known at theoutset. We assume that all input messages are ini-tially available in the form of a time series ts in con-taining time (t), port (port), value (msg) entiresof the form [t, [port ,msg ]]. In contexts involvinginteractivity or real-time control, these messagesbecome available only as the simulation is under-way; nevertheless, the pseudocode provides usefulguidance as to how the messages should influencea simulation. We also assume that a simulatedtime point tend is supplied, and that the simula-tion ends as soon as the current time t reachesthis point. Other terminating mechanisms can beused with minimal change to the overall proce-dure. The result of the algorithm is the time seriesof output messages tsout, the final state s, and thetime elapsed in the final state ∆te. One may mod-ify the algorithm to also record some or all of theintermediate states that occur as the simulationprogresses. It is remarkable that, given suitabledefinitions for the functions δext , δint , λ, and ta,this algorithm can describe essentially any simu-lation run regardless of its domain or the timingpatterns that emerge between its events.

As with most computer programs, certain ma-nipulations can be performed with minimal or

Page 23: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

Maleki et al. 23

Algorithm 1 Classic DEVS Simulation

1: function simulate(model , s0, ts in , tend)2: δext , δint , λ, ta ← model3: s← s0 {current state}4: t← 0 {current time}5: ∆te = 0 {elapsed duration}6: iin ← 0 {input time series index}7: nin ← #ts in {input time series size}8: tsout ← [ ] {output time series}9: done ← ⊥ {termination flag}

10: while ¬done do {simulation loop}11: text , x←∞,∅12: if iin < nin then {more messages?}13: text , x← ts in [iin ]14: end if15: tint ← t+ ta(s)16: tprev ← t17: t← min(text , tint) {time advancement}18: ∆te ← t− tprev

19: if t ≥ tend then {finished?}20: done = >21: else if t = text then {external event?}22: s← δext(s,∆te, x)23: iin ← iin + 124: else if t = tint then {internal event?}25: y, s← λ(s), δint(s)26: if y 6= ∅ then27: tsout ← tsout ‖ [ [t, y] ]28: end if29: end if30: end while31: return tsout, s,∆te32: end function

zero effect on the nature of the algorithm. Anexample of a minimal change is the encapsula-tion of state within the simulation procedure. In-stead of requiring the initial state s0 directly,we require parameter values vals in from whichthe initial state can be computed. It is actuallycommon practice to obtain initial states in thisfashion. The parameter-to-state transformationis performed by the initialization event handler,which we represent using the mathematical func-tion finit . To fully encapsulate state, an analogouschange must be made at the end of the algorithm.Instead of delivering the final state s and corre-sponding elapsed duration ∆te, these values aresupplied to the finalization event handler repre-sented by ffinal . This yields the statistics valuesvalsout , which are delivered along with the output

Algorithm 2 Adapted DEVS Simulation

1: function simulate(model , vals in , ts in , tend)2: finit , fu, fp, ffinal ← model3: s,∆tp ← finit(vals in) {initialization event}4: t← 0 {current time}5: ∆te = 0 {elapsed duration}6: iin ← 0 {input time series index}7: nin ← #ts in {input time series size}8: tsout ← [ ] {output time series}9: done ← ⊥ {termination flag}

10: while ¬done do {simulation loop}11: tu, x←∞,∅12: if iin < nin then {more messages?}13: tu, x← ts in [iin ]14: end if15: tp ← t+ ∆tp16: tprev ← t17: t← min(tu , tp) {time advancement}18: ∆te ← t− tprev

19: if t ≥ tend then {finished?}20: done = >21: else if t = tu then {unplanned event?}22: s,∆tp ← fu(s,∆te, x)23: iin ← iin + 124: else if t = tp then {planned event?}25: s,∆tp, listy ← fp(s,∆te)26: tsout ← tsout ‖ [ [t, listy] ]27: end if28: end while29: valsout ← ffinal(s,∆te) {finalization event}30: return tsout, valsout

31: end function

time series as the simulation results.

An example of a program manipulation with nosemantic effect whatsoever is the relocation of thecomputation ta(s). In Algorithm 1, the compu-tation is found on line 15. Nothing is changedif we instead apply ta immediately after everystate change; in other words, we extract ta(s)from line 15 and insert it after lines 3, 22, and25. Line 3 is where we will invoke the initializa-tion event handler finit , and this function can ab-sorb the ta(s) computation. Line 22 is where theunplanned event handler fu will be invoked, andagain it will absorb ta(s). Finally, line 25 will be-come part of the planned event handler fp, alongwith the ta(s) computation. Note that whereverta(s) is computed, the result can be stored in aplanned duration variable ∆tp so that the valuecan be still be used on line 15.

Page 24: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

24 Designing DEVS Visual Interfaces for End-User Programmers

These largely superficial changes result in Algo-rithm 2, the simulation procedure for the adaptedversion of DEVS involving the four event handlersfinit , fu, fp, and ffinal . For all intents and pur-poses, the algorithms are the same, and accord-ingly the argument model can be interpreted as aDEVS model in both cases. The difference is thatAlgorithm 2 better supports the paper’s visual in-terfaces designed for end-user programmers.

We now explore the question of whether the vi-sual interfaces are appropriate only for end-userprogrammers, or if they also support the needs ofthose who prefer to begin with DEVS model spec-ifications in the conventional form. It turns outthat if one has defined δext , δint , λ, and ta, thereis a simple mapping of these functions onto finit ,fu, fp, and ffinal .

finit(vals in) = s0,∆tpwhere ∆tp = ta(s0)

fu(s,∆te, x) = s′,∆tpwhere s′ = δext(s,∆te, x)

∆tp = ta(s′)

fp(s,∆te) = s′,∆tp, listywhere s′ = δint(s)

∆tp = ta(s′)listy = [λ(s)]

ffinal (s,∆te) = valsout

The mapping is efficient in that, when the abovedefinitions of finit , fu, fp, and ffinal are substi-tuted into Algorithm 2, there are no redundantinvocations of δext , δint , λ, or ta. A DEVS expertcould therefore specify his/her model in the tradi-tional mathematical form, yet implement it usinga simulation tool featuring the proposed visual in-terfaces.

To complete the comparison of the classic andadapted versions of DEVS, there is one remain-ing difference to explore. In Classic DEVS, eachinternal event is associated with exactly zero orone output message (in Algorithm 1, line 25, seey which may be ∅ to indicate no message). Inthe adaptation, where there are “planned events”instead of “internal events”, each planned event isassociated with a list of zero or more output mes-sages (see listy on line 25 of Algorithm 2). This

departure from Classic DEVS is not critical to ourwork; in other words, our visual interface designssupport either one optional message or a list ofmessages. If a message list is to be supported, asmall change must be made in the simulation ofcomposite models.

An elegant way to describe simulations involv-ing composite models is as follows. First, regardany composite model as an atomic model knownas the resultant, which is possible thanks to theconcept known as closure under coupling. Sec-ond, because a composite model is essentially aspecial case of an atomic model, Algorithms 1 and2 can be used to simulate any model. To applythis technique to Classic DEVS, we must definethe resultant functions δext , δint , λ, ta using thecomposite model elements below.

[. . . , [〈δext〉d, 〈δint〉d, λd, tad], . . .] {components}EIC {external input couplings}EOC {external output couplings}IC {internal couplings}Select {tie - breaking function}

Let us focus specifically on the resultantfunctions RESULTANT LAMBDA (λ) and RESUL-

TANT DELTA INT (δint), both associated with in-ternal events. The pseudocode is given in Algo-rithm 3. Both functions select the event-triggeringcomponent using the same procedure, which is en-capsulated in the CALL SELECT function.

The pseudocode for the resultant planned eventhandler is given in Algorithm 4, and the pro-cedure is similar to that of the internal eventsin Algorithm 3. The first step in both cases isto determine the index d∗ of the event-triggeringcomponent. In Algorithm 3 this is done by theCALL SELECT function, whereas in Algorithm 4 thecorresponding code appears on lines 3 through10. The Classic function RESULTANT LAMBDA con-tains a for loop on line 19, which tracks messagesfrom the d∗ component to the output ports ofthe composite model; the same loop appears online 16 of Algorithm 4. The Classic function RE-

SULTANT DELTA INT contains a for loop on line 38,which tracks messages from the d∗ component tothe input ports of other components; the sameloop appears on line 21 of Algorithm 4. The RE-

SULTANT DELTA INT function is also responsible forupdating the state of the d∗ component (line 34)

Page 25: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

Maleki et al. 25

and affected components (line 41); the correspond-ing instructions can be found on lines 11 and 24of Algorithm 4.

Algorithm 3 Resultant Internal Event

1: function call select(s)2: [. . . , [sd, 〈∆te〉d], . . .]← s3: ∆te ← min(. . . , tad(sd)− 〈∆te〉d, . . .)4: imminent ← [ ]5: for d : [0, . . . ,#s− 1] do6: if tad(sd)− 〈∆te〉d = ∆te then7: imminent ← imminent ‖ [d]8: end if9: end for

10: return Select(imminent),∆te11: end function12: function resultant lambda(s)13: [. . . , [sd, 〈∆te〉d], . . .]← s14: d∗,∆te ← CALL SELECT(s)15: y ← ∅16: yd∗ ← λd∗(sd∗)17: if yd∗ 6= ∅ then18: portd∗ ,msg ← yd∗

19: for [d†, portd† ], port : EOC do20: if d† = d∗ ∧ portd† = portd∗ then21: y ← [port ,msg ]22: end if23: end for24: end if25: return y26: end function27: function resultant delta int(s)28: [. . . , [sd, 〈∆te〉d], . . .]← s29: d∗,∆te ← CALL SELECT(s)30: for d : [0, . . . ,#s− 1] do31: 〈∆te〉d ← 〈∆te〉d + ∆te32: end for33: yd∗ ← λd∗(sd∗)34: sd∗ ← 〈δint〉d∗(sd∗)35: 〈∆te〉d∗ ← 036: if yd∗ 6= ∅ then37: portd∗ ,msg ← yd∗

38: for [d†, portd† ], [d, portd] : IC do39: if d† = d∗ ∧ portd† = portd∗ then40: xd ← [portd,msg ]41: sd ← 〈δext〉d(sd, 〈∆te〉d, xd)42: 〈∆te〉d ← 043: end if44: end for45: end if46: return [. . . , [sd, 〈∆te〉d], . . .]47: end function

Algorithm 4 Resultant Planned Event

1: function resultant f p(s,∆te)2: [. . . , [sd, 〈∆te〉d, 〈∆tp〉d], . . .]← s3: d∗ ← ∅4: for d : [0, . . . ,#s− 1] do5: 〈∆te〉d ← 〈∆te〉d + ∆te6: 〈∆tp〉d ← 〈∆tp〉d −∆te7: if d∗ = ∅ ∧ 〈∆tp〉d = 0 then8: d∗ ← d9: end if

10: end for11: sd∗ , 〈∆tp〉d∗ , 〈listy〉d∗ ← 〈fp〉d∗(sd∗ , 〈∆te〉d∗)12: 〈∆te〉d∗ ← 013: listy ← [ ]14: for yd∗ : 〈listy〉d∗ do15: portd∗ ,msg ← yd∗

16: for [d†, portd† ], port : EOC do17: if d† = d∗ ∧ portd† = portd∗ then18: listy ← listy ‖ [ [port ,msg ] ]19: end if20: end for21: for [d†, portd† ], [d, portd] : IC do22: if d† = d∗ ∧ portd† = portd∗ then23: xd ← [portd,msg ]24: sd, 〈∆tp〉d ← 〈fu〉d(sd, 〈∆te〉d, xd)25: 〈∆te〉d ← 026: end if27: end for28: end for29: ∆tp ← min(. . . , 〈∆tp〉d, . . .)30: return [. . . , [sd, 〈∆te〉d, 〈∆tp〉d] . . .],∆tp31: end function

For the version of DEVS adapted for visual in-terfaces, composite models include the followingelements.

[. . . , [〈finit〉d, 〈fu〉d, 〈fp〉d, 〈ffinal 〉d], . . .] {comp ’ s}EIC {external input couplings}EOC {external output couplings}IC {internal couplings}

Though largely similar, there are a few no-table differences between Algorithms 3 and 4. Forthe code at the beginning that selects the event-triggering component, the main semantic differ-ence is that Classic DEVS relies on a Select func-tion whereas the adapted version orders events bycomponent index. Most DEVS-based tools featurethis simplification. Another meaningful differenceis that, whereas the Classic DEVS code handlesone potentially empty output yd∗ , the adaptationcode deals with a list of messages 〈listy〉d∗ . Ac-

Page 26: Designing DEVS Visual Interfaces for End-User Programmers · 2017-04-12 · Designing DEVS Visual Interfaces for End-User Programmers Maryam Maleki 1, Robert Woodbury , Rhys Goldstein2,

26 Designing DEVS Visual Interfaces for End-User Programmers

cordingly, the if statements on lines 17 and 36of Algorithm 3 are replaced with the for loopon line 14 of Algorithm 4. A final differenceis that whereas both versions include componentstates sd and component elapsed durations 〈∆te〉din the state s, Algorithm 4 also includes compo-nent planned durations 〈∆tp〉d. Regardless of howDEVS is adapted, these planned duration shouldbe stored in one form or another to avoid redun-dant invocations of the tad functions. Arguably,the storage of 〈∆tp〉d values makes Algorithm 4easier to implement in an efficient manner.

In summary, the adapted version of DEVS re-mains similar to the original version of the formal-ism. There is a direct mapping from Classic DEVSelements to the newly proposed event handlers,and the corresponding simulation algorithms aresemantically equivalent aside from a few small dif-ferences. Minor departures from the theory canbe found in all DEVS-based tools—a result of thefundamental limitations of computer technology.

Manuscript accepted for publication in Simulation: Transac-tions of the Society for Modeling and Simulation International(sim.sagepub.com).

c© 2015 The Authors

Received: August 6, 2014Revised: April 22, 2015Accepted: June 9, 2015