UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Cnj : subtitle a visual programming environment for constraint nets Song, Fengguang 2002

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata


831-ubc_2002-0564.pdf [ 9.79MB ]
JSON: 831-1.0051712.json
JSON-LD: 831-1.0051712-ld.json
RDF/XML (Pretty): 831-1.0051712-rdf.xml
RDF/JSON: 831-1.0051712-rdf.json
Turtle: 831-1.0051712-turtle.txt
N-Triples: 831-1.0051712-rdf-ntriples.txt
Original Record: 831-1.0051712-source.json
Full Text

Full Text

CNJ: A Visual Programming Environment For Constraint Nets by Fengguang Song B.Eng., Zhengzhou University, 1996 M.Eng., Nanjing University of Aeronautics and Astronautics, 1999  A THESIS SUBMITTED IN P A R T I A L F U L F I L L M E N T OF THE REQUIREMENTS FOR THE D E G R E E OF Master of Science in THE F A C U L T Y OF G R A D U A T E STUDIES (Department of Computer Science)  we accept this thesis as conforming to the required standard  THE UNIVERSITY OF BRITISH COLUMBIA October 2002 © Fengguang Song, 2002  In presenting this thesis/essay in partial fulfillment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying for this thesis for scholarly purposes may be granted by the Head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission.  Oct. 1>2°°l Date  Department of Computer Science The University of British Columbia 2366 Main mall Vancouver, BC Canada V 6 T 1 Z 4  ABSTRACT  The Constraint Nets model (CN) proves to be useful for a wide variety of purposes, ranging from intelligent agent systems, and real-time embedded systems, to integrated hybrid systems with various time structures: discrete, continuous, and time-based. This thesis describes a new visual programming environment called C N J (Constraint Nets in Java) which utilizes component-based technology. C N J uses JavaBeans, Bean Introspection, drag-and-drop, and Java Swing M D I (Multiple Document Interface) technologies, as well as XML-based C N M L as its standard interchange format. The environment supports constraint net modeling, simulation, and animation for hybrid systems. Furthermore, it provides support for a topdown design, middle-out design, and bottom-up design where the module bean can be reused anywhere in any other C N model, saving designers time and effort. As an experiment, a hybrid dynamic elevator system is developed successfully, and test results confirm the effectiveness of the tool for hybrid system modeling and real-time simulation.  ii  ABSTRACT  »  CONTENTS  U  LIST OF T A B L E S  V I  I  LIST OF FIGURES  vii  ACKNOWLEDGEMENTS  «x  DEDICATION  x  C H A P T E R 1 INTRODUCTION  1  1.1 Thesis Statement  1  1.2 Motivation  2  1.3 Related Work  3  1.4 C N J Overview  5  1.5 Thesis Outline  7  1.6 Contributions  7  C H A P T E R 2 BACKGROUND  9  2.1 Component-Based Software Engineering  9  2.2 JavaBeans Component Architecture  10  2.3 Graphical User Interface Design  12  2.3.1 UI Design Guidelines  12  2.3.2 Java Look and Feel Style  13  2.4 Visual Programming Languages  14  2.4.1 Classification and Concepts  14  2.4.2 Automated Control Engine  16  2.5 Summary  16  CHAPTER 3 CONSTRAINT NETS  18  3.1 Constraint Net Model  18  3.1.1 Constraint-Based Intelligent System iii  18  3.1.2 Constraint Net Syntax and Semantics  20  3.2 Requirement Specification with Timed V-Automata  21  3.3 Behavior Verification  23  3.4 Summary  23  C H A P T E R 4 CONCEPTS AND ARCHITECTURE OF C N J  25  4.1 Main Idea  25  4.2 Requirement Analysis  27  4.2.1 System Requirements  27  4.2.2 User Groups  29  4.3 System Architecture  30  4.4 Summary  34  C H A P T E R 5 GRAPHICAL USER INTERFACE DESIGN  5.1 User Interface Architecture  35  35  5.1.1 GUI Introduction  35  5.1.2 GUI Composition  37  5.2 Multi-threaded Panels  38  5.3 Important UI Classes  39  5.3.1 DrawPane Class  39  5.3.2 PropertySheetPanel Class  41  5.4 Constraint Net Nodes  44  5.4.1 Transduction Bean  44  5.4.2 Location Bean  46  5.4.3 Clock Bean  46  5.4.4 Module Bean  46  5.4.5 Connection  47  5.5 Summary  47  C H A P T E R 6 C N J SIMULATION  49  6.1 Java Event Mechanism  49  6.2 The Compilation Step of CNJ  53  6.3 Dataflow Issue  54  6.3.1  Data-driven and Demand-driven Models  iv  55  6.3.2 Dataflow in C N J  55  6.3.3 Transduction Scheduling Algorithm  56  6.4 Discussion of "Real-time"  60  6.5 Summary  62  C H A P T E R 7 CONSTRAINT N E T M A R K U P L A N G U A G E  63  7.1 X M L  63  7.2 C N M L  65  7.3 Summary  67  C H A P T E R 8 A REALISTIC C N M O D E L  68  8.1 The Elevator System  68  8.1.1 Top-level Hybrid Model  69  8.1.2 The Continuous E L E V A T O R Module  71  8.1.3 The Discrete CONTROL1 Module  73  8.2 Elevator System Modeled in C N J  73  8.3 Elevator System Simulation and Animation in C N J  74  8.4 Summary  76  C H A P T E R 9 EXPERIMENTAL RESULTS  78  9.1 Methodology  78  9.2 Results  79  9.3 Summary  82  C H A P T E R 10  CONCLUSIONS AND FUTURE W O R K  83  10.1 Conclusions  83  10.2 Future Work  84  BIBLIOGRAPHY  86  APPENDIX A  C N M L F I L E FOR T H E C A R DYNAMICS M O D E L  89  APPENDIX B  T H E E L E V A T O R SYSTEM M O D E L E D IN C N J  V  100  LIST OF TABLES  Table 5.1  DrawPane class  41  Table 6.1  Simulation output of a simple constraint net  53  Table 9.1  Simulation results for Example 1, 2, 3  80  Table 9.2  Simulation results for the Elevator system (Example 4)  81  vi  Figure 1.1  The Graphical User Interface of CNJ  Figure 3.1  The structure of a constraint-based agent  19  Figure 3.2  An integration system in constraint net  20  Figure 3.3  V-automata  22  Figure 3.4  Timed V-automata  22  Figure 4.1  Putting together a system from bean objects  27  Figure 4.2  Architecture of CNJ  30  Figure 4.3  Class architecture graph  32  Figure 5.1  CNFrame composition  36  Figure 5.2  Containment hierarchy of CNJ GUI  38  Figure 5.3  Method of setTarget() in BeanPropertySheet  43  Figure 5.4  C N bean classes  44  Figure 5.5  PropertyEdit of Transduction  45  Figure 5.6  Transduction definition for "minus"  45  Figure 6.1  Three types of PropertyChangeEvents in C N J Simulation  51  Figure 6.2  A constraint net to represent x(t) = x(t-1) + step  52  Figure 6.3  A transduction scheduling example  58  Figure 6.4  Transduction scheduling algorithm  60  Figure 7.1  X M L document life cycle  64  Figure 7.2  C N M L Elements  67  Figure 8.1  3-floor elevator system  69  Figure 8.2  A hybrid model of the Elevator system  70  Figure 8.3  The continuous E L E V A T O R module  71  Figure 8.4  The discrete CONTROL1 module  73  Figure 8.5  The Elevator system modeled in C N J  75  Figure 8.6  The Elevator animation window  77  Figure 9.1  Example 1 (a simple adder)  79 vii  5  Figure 9.2  Example 2 (a two-level adder)  79  Figure 9.3  Example 3 (the Car Dynamics)  80  Figure B - l  B U T T O N Module  100  Figure B-2  FlipFlop Module  100  Figure B-3  ResetSignal Module  101  Figure B-4  E V E N T Module  101  Figure B-5  CONTROL1 Module  102  Figure B-6  UpRequest Module  102  Figure B-7  DownRequest Module  103  Figure B-8  StopRequest Module  103  Figure B-9  ServingState Module  104  Figure B-10 Command Module  104  Figure B - l 1 E L E V A T O R Module  105  Figure B-12 CONTROL0 Module  105  Figure B-13 B O D Y Module  106  Figure B-14 H O M E Module  106  Figure B-15 FLOOR Module  106  viii  ACKNOWLEDGEMENTS'  I would like to gratefully acknowledge my supervisor, Dr. Alan Mackworth. Numerous motivational and instructional discussions with him ensured the success of this project. His wealth of knowledge in computational intelligence and constraint-based systems assisted me in identifying the critical and interesting issues of this research. His attitude towards research and professionalism also inspired me to continuously challenge myself to reach new levels. This work would not have been possible without his enthusiastic supervision, invaluable guidance, and generous financial support. I also wish to thank Dr. Jim Little for taking the time to be my second reader, and for providing me with many insightful comments. I would like to thank Y u Zhang (IBM) and Ying Zhang (Xerox Pare). They gave me lots of valuable suggestions and long hours of discussion over various issues related to this project. M y experience here in the L C I lab is full of opportunities to learn, not only from faculty and students who are experts in the field, but also from industrial fellows and sponsoring companies. I owe my gratitude to those people who are particularly instrumental in contributing to my experience in the LCI lab at U B C . They are Dr. Jim Little, Dr. Anne Condon, Valerie McRae, Robert St-Aubin, and Xiaoming Zhou. I really appreciate Lisa Beckett's great help with my technical writing. I am deeply grateful to my parents Linbin Song, and Suzhen Ji, for their never ceasing love and support for my whole life. Their confidence in me and encouragement of me are the impetus of this hard work. I am also grateful to my wife Lan Lin who can always lift up my spirits even in the worst of times. I also thank my brother Xuguang Song and my sister Min Song for their constant inspiration and comfort. This work was supported by IRIS and NSERC.  ix  To my parents and family, for their support, love, and enthusiasm.  CHAPTER 1  INTRODUCTION  The complexity of software development is rapidly increasing during this decade and it often exceeds human intellectual capability. Component-based technology, an exciting new research area, promises to deliver scalable and reusable software because of its decomposition, abstraction, and hierarchy properties. The Constraint Nets model (CN) was developed by Zhang and Mackworth to represent hybrid dynamic systems. It is a family of visual programming languages (VPLs) with inherent graphical icons and hierarchies. In this thesis, a visual programming environment called C N J (Constraint Nets in Java), is established to support constraint net modeling and simulation. C N J uses component-based technology (JavaBeans), Bean Introspection and Java Swing, as well as X M L as the standard interchange format.  1.1 Thesis Statement C N is a unified and integrated approach for modeling, specifying and verifying discrete, continuous, and event-based hybrid dynamic systems. C N J aims to provide a practical, feasible environment for constraint net modeling and simulation. Although one of its purposes is to provide such a realistic environment, other more important research objectives include the following:  •  Investigation of component-based technology in hybrid system modeling and simulation.  •  Proof that visual programming environments and visual programming languages (VPL) are helpful for users.  •  Demonstration that Java is useful for virtual real-time programming.  1  •  Feasibility of the efficient and useful implementation of the concept of Constraint Nets.  •  Demonstration of an open, portable, executable representation of hybrid dynamic systems.  1.2 Motivation In the past decade, hybrid systems have become a focus of interest for a wide community for two reasons.  One is that analog computation is gaining more attention because of  recent technological advances, such as faster computers, and cheaper, more reliable sensors. The other is that the integration of computers that control continuous dynamic systems shows increasing importance [7]. Constraint Nets are developed as a unified formal foundation for hybrid dynamic systems, consisting of modeling, and the specification and verification of languages. C N is a generalization of dataflow with multiple data and events, in which a dynamic control system can be described as several block diagrams. A constraint net represents a set of equations, with locations as variables, and transductions as functions. It is able to support various time structures: discrete, continuous and event-based. Since it has a graphical representation, and is composed of a set of basic graphical elements, C N is an ideal model for visual programming. Java is an object-oriented programming language where a Java class is reusable. The JavaBeans technology has  the  important properties  of reusability, bean  introspection, and platform-independence. Using the technology of JavaBeans, Java classes are able to be reused, and can run anywhere. It facilitates greater reusage and allows for rapid development through assembling software components rather than writing codes. The goal of this thesis is to design and implement a visual programming environment for hybrid system modeling and simulation in the constraint net language. The environment uses JavaBeans as atomic blocks to build hierarchical, modular and large-scale system models [35]. In C N J , several kinds of Java bean classes are implemented and provided as elementary blocks. The tool uses Java's event handling  2  mechanism (registration of event listeners) to connect Java beans, and make them communicate with each other. The Java event mechanism successfully handles the support for various time structures. This JavaBeans-based  visual programming  environment has the advantages of the reusability of modules, reduction of coding time, and simplification of model development. Since CNJ is a visual programming tool, users only need to drag and drop the provided Java beans, and assemble them together. To store constraint net models, we also define XML-based C N M L (Constraint Net Markup Language) as the standard interchange file format. C N M L conforms to the specification of X M L (extensible Markup Language) 1.0.  1.3 Related Work It has been eight years since C N was first introduced and developed. It works as a formal analysis and modeling framework for the development of hybrid systems. C N proves to be useful for a variety of purposes, ranging from intelligent systems, and real-time embedded systems, to integrated hybrid systems [7]. However, there is no appropriate programming environment available for it. C N J is the first customized visual programming environment for C N , based on component-based technology. Nevertheless, research in hybrid system modeling and simulation is not completely new. Many papers are published in this area and several systems are developed in industry. However, most of them focus on some specific time structures, instead of a variety of them, such as discrete, continuous, and event-based. Maflab/Simulink [3] is a visual programming and simulation environment for continuous and discrete control systems. It enables users to build graphical block diagrams, simulate dynamic systems, evaluate system performance, and refine their designs. It is currently the most popular tool for control system modeling and simulation. However, it is not suited for hybrid system modeling in constraint nets. There are three reasons for this:  •  First, Simulink is unable to support an event-based time structure, which is an important characteristic of hybrid systems.  3  •  Second, although it supports bottom-up modeling well (by grouping), it does not support top-down and middle-out modeling methods, which are helpful for some users [3].  •  Third, in Simulink, all the system models are stored in M D L format (Model Description Language). In addition, since C N has a different graphical representation from Simulink's models, the M D L file format is not able to store constraint net models.  There is also some component-based simulation work done. [33] [28] and [17] use Sun's B D K (Bean Development Kit) tool directly to model and simulate control systems. B D K is a simple tool for testing Java beans, and for visually manipulating their properties and events. It is convenient to use the B D K to assemble some beans to build a system model or module, through drag-and-drop. However, since B D K is not aimed at system modeling, it actually imposes some limits on the use of those systems. The graphical user interface of B D K is weak because it is implemented in Java A W T (Abstract Window Toolkit), not Java Swing (which is much more powerful). For instance, in B D K , there are only a small number of visual components which display bean properties because of its limited internal support. The wires that connect between beans are invisible. Also, there are only Java-level events in the modeled systems, with no concept of a continuous time structure, which is, however, essential for complex hybrid systems. Furthermore, it is challenging work to build a complex model based on customized JavaBeans. Users might be required to implement a very complicated Java bean as an atomic block. A l l the limits above make those BDK-based modeling environments difficult to use practically. In addition, it is even harder to apply it to constraint net modeling. Visual programming languages (VPL) have been researched for dozens of years, and numerous visual programming systems have been developed to address specific application areas, physical simulation, and more general programming tasks. VPLs offer many advantages over traditional textual programming languages, such as fewer programming concepts, concreteness, explicit relation depiction, and visual feedback [8]. Some popular visual programming languages include Alternate Reality Kit (ARK),  4  Visual Imperative PRogramming (VIPR), Cube, and so forth [13]. With the increase in computer speed and graphical display capabilities, it is highly probable that visual programming languages will be widely used.  1.4 CNJ Overview Our environment is called CNJ (Constraint Nets in Java). It is a specific environment for hybrid system modeling and simulation with constraint nets. C N is a family of visual  Figure 1.1. The Graphical User Interface of CNJ  5  programming languages, which consist of timed V-automata as a requirement specification language, a dynamical system modeling language, and a verification method. CNJ's system design includes support for the requirement specification language, the dynamical modeling language and the verification method. The present version provides visual programming in the dynamical modeling language, as well as real-time simulation. A constraint net is composed of Locations, Transductions, and Connections. CNJ provides several basic Java beans, accordingly. When designing a constraint net model, users need to draw and define transductions, locations, modules, and clocks (a kind of transduction), and then wire these by connections. Because it is a visual programming environment, CNJ is easy to use and learn. CNJ is implemented in pure Java, and can run on different platforms. Its graphical user interface consists of two main windows, shown in Figure 1.1. The big window is the CNFrame, used for designing or drawing a constraint net model. The small one is the PropertyEdit window, which is able to edit a selected object's properties in the left window. When users select a different object, the PropertyEdit window changes accordingly. The panel at the center of the CNFrame adopts the style of an M D I (Multiple Document Interface) with child windows. Each child window has a DrawPane for displaying a constraint net module. CNJ supports various modeling and development methods: top-down, bottom-up, and middle-out. With these modeling methods, user can group system models into hierarchies to create a simplified view of subsystems or modules. To design a constraint net model, the simple drag-and-drop method is used. In constraint nets, the function of a transduction might be arbitrary. C N J provides predefined basic operators for building complicated functions. If an unsupported function is needed, CNJ developers can easily add it. This tool also provides a compilation step to detect some syntax errors in user designed constraint nets. After passing the compilation step, users might run a simulation to see the output data. Users can also run an animation window to see a more straightforward running result. A constraint net model, or module, is stored in a Constraint Net Markup Language (CNML). When users need a module for further reuse, they can save it in a  6  separate file. The C N M L is based on the specification of X M L 1.0, and brings X M L ' s advantages: being content-oriented, giving easy access and reusage, providing validation support, and so forth. Presently C N J can export a constraint net model to a postscript file.  1.5 Thesis Outline This chapter provides an introduction to the thesis, including the thesis statement, motivation, contributions and overview of CNJ. Chapter 2 introduces some background knowledge related to our research. In it, Component-Based Software Engineering (JavaBeans), HCI, and V P L are briefly mentioned. Chapter 3 introduces the principles of constraint nets. In Chapter 4, we present our main idea for designing CNJ and its system architecture. Chapter 5 describes the implementation of CNJ's graphical user interface and the C N nodes in Java bean. Chapter 6 illustrates several mechanisms for supporting real-time simulation in C N J . In Chapter 7, Constraint Net Markup Language is introduced. In Chapter 8, a hybrid Elevator control system is modeled in constraint nets, and developed in CNJ. Chapter 9 presents some experimental results of the environment. Finally, conclusions and future work are described in Chapter 10. Appendix A gives a complete C N M L file for the Car Dynamics C N model. Appendix B contains the set of graphical C N modules for the 3-floor Elevator system designed in CNJ.  1.6 Contributions A hybrid system in general, is a continuous, discrete, and event-based dynamic system. In the past decades, models for hybrid systems developed and matured. Some design environments for these were also created [5]. Matlab/Simulink was developed for continuous and discrete models [3]. DevsJava was developed for Discrete Event System Specification (DEVS) [16]. P N K was developed for Petri Nets [34]. The Automated Control Engine (ACE) was developed for event-based control systems [9]. C N is an ideal model for hybrid systems, and it is unitary, modular, and powerful. It is successfully applied to robotic system modeling. A robotic system is a typical hybrid 7  system. Its controller is modeled in discrete dynamics, its body and environment are modeled in continuous dynamics. With the support of various time structures, C N J is able to model such hybrid systems in constraint nets. Component-based technology is used to realize the visual programming environment. The simulation part is almost in real-time, even though it is written in Java. This thesis presents our work of C N J for modeling and simulating real-time hybrid systems with constraint nets. The primary contributions of our work are as follows:  •  It proves that component-based technology works well for control system modeling and simulation.  •  It shows visual programming is helpful for users.  •  It demonstrates that Java is useful for real-time programming.  •  It proves that Constraint Nets are a practical, feasible language for modeling hybrid systems.  •  It is helpful for different user groups to use CNJ to study Constraint Nets.  •  C N M L is defined as the first standard XML-based interchange file format for constraint nets.  8  CHAPTER 2  BACKGROUND!  CNJ is designed and implemented using component-based technology. It works as a visual programming environment. This chapter illustrates the concepts of componentbased technology, JavaBeans, user interface design, and visual programming languages (VPL).  2.1 Component-Based Software Engineering The idea of software components has been developed in software engineering for some time. A software component is defined as "a unit of composition with contractually specified interfaces and explicit context dependencies only" [20]. In this definition, components are independent of each other, and communicate with each other through predefined interfaces. A software component is an independent object that has its own functionality. Through interfaces, a large-scale and complicated system can be built on the available components. Component-Based  Software  Engineering (CBSE)  is based  on  software  components. It is a process of building systems by combining and assembling predefined objects or components. C B S E is able to guarantee the development of software or systems in less time, with higher quality and reliability. The characteristics of component-based development are as follows [15]:  •  Black-box reusage  •  Reactive-control and the component's granularity  •  Using R A D (rapid application development) tools  •  Contractually specified interfaces  •  Introspection mechanism provided by the builder systems  •  Software component market  9  In addition, component-based development is closely related to object-oriented programming. It is natural and straightforward to implement software components in an object-oriented language. The traditional techniques in object-oriented  software  engineering are important for component-based development, such as design pattern, architecture pattern, and meta-pattern. However, component-based development is different from object-oriented development. A software component is not a part of the application or program, but is an autonomous entity. Programmers cannot see its code, except for the interface specification [18]. Typically, it is in the form of an object instance instead of source code. Furthermore, component-based development does not need to use the class hierarchy that is very important in object-oriented programming. Currently, software components can be developed with ActiveX, C O R B A , JavaBeans and EJB (Enterprise JavaBeans). We chose JavaBeans to develop C N J because it has the advantages of platform-independence, object-orientation, simple strategy for multi-threading, automatic garbage collection, safe memory usage, and easy programming. Although a Java program's speed is not as fast as that of a C++ program, after the utilization of Just-In-Time (JIT) and native code compilers, this problem of speed decreases.  2.2 JavaBeans Component Architecture Java bean is defined as "a reusable software component that can be manipulated visually in a builder tool" [14]. The JavaBeans component architecture is a platform-neutral architecture for the Java application environment. It is used to develop fully portable network-aware applications within Intranets, or across the Internet. Actually, when using Java, JavaBeans component architecture is the only choice to consider in componentbased development. A Java bean class is able to run on various operating systems, and also within many application environments. As [37] stated, " A JavaBeans developer secures a future in the emerging network software market without losing customers that use proprietary platforms, because JavaBeans components interoperate with ActiveX". Through  10  JavaBeans Architecture Bridges, JavaBeans can be connected together with other component models, such as ActiveX. Therefore, software components that use JavaBeans APIs are portable to containers such as Internet Explorer, Visual Basic, Microsoft Word, and Lotus Notes. A Java bean is a Java class. When obeying a few non-critical naming conventions, or using a Beanlnfo class, a general Java class becomes a Java bean. A bean's interface includes its properties, methods, and events. A Java bean has the following typical features [14]:  •  Support for "properties", both for customization and for programming use. Properties are the named attributes of a bean. They can be accessed (read and write) by some appropriate methods which obey some rules. The method has to be named as get<Property> or set<Property>. There are four kinds of bean property: Simple Property, Bound Property, Constrained Property, and Indexed Property [30]. The Bound Property has the capability that, when the value of the property changes, it notifies the other objects that added a PropertyChangeListener for that property. A Constrained Property handles how a proposed property change can be permitted or vetoed by other objects. An Indexed Property describes a multiple-value property.  •  Support for "events" as a simple communication method that can be used to connect up beans. With an event, a bean can notify other beans that something interesting has happened. Also, other beans can do something to respond to the events. For that purpose, event listeners are registered to event sources. The event source provides two methods to support event listener registration: add<Event>Listener and remove<Event>Listener, where <Event> is the name of the event.  •  Support for "Introspection" so that a builder tool can analyze how a bean works. The builder tool can detect information of a bean, such as properties, methods, and events if the bean class conforms to naming conventions of JavaBeans.  •  Support for "Persistence". A bean can be customized in an application builder, and then have its customized state saved away and reloaded later.  •  Support for "Customization". When using an application builder, a user can. customize the appearance and behavior of a bean. Sometimes the modification of  11  simple properties is not sufficient for complex components. Additional editors or customizers may be provided for the ease of customization.  2.3 Graphical User Interface Design User interface is a bridge between users and computers by allowing for information exchange between them. There are a vast variety of ways to bridge humans and computers, for instance, display areas, digital cameras, full-duplex audio, actuators and sensors, and more recently, even scent through aroma generating machines and artificial noses. With increased user interface sophistication, this, in turn, makes the programming task more difficult. Generally, user interface design and programming occupies a large proportion of software development. From the survey [2], the average time spent on the user interface portion is 45% during the design phase, 50% during the implementation phase, and 37% during the maintenance phase. The most common difficulties that UI programmers confront include getting the user's requirements, writing help text, achieving consistency, getting acceptable performance, and communicating among various parts of the program. In order to decrease the UI programming task, some interface builders and UTMSs (User Interface Management System) are developed.  2.3.1 UI Design Guidelines  A good user interface should be easy to use, and suitable for a specific operating system. However, this is not easy for software developers to realize. In addition, good UI designs do not happen naturally. These require software developers to learn and apply a few basic guidelines. The following items are provided as basic guidelines for designing a user interface [12]:  1.  Maintain Consistency in Look and Feel. It requires consistent visual appearance and consistent response to user input throughout the user interface design.  2.  Provide Shortcuts and Flexibility. Some experienced users need the means of going directly to specific locations in UI.  12  3.  Present Informative Feedback. Feedback gives users confidence. It tells the user what the program is doing.  4.  Design for Recovery from Error. If possible, the undo function and meaningful error messages are provided to users.  5.  Reduce Memory Demands. Too many facts and decisions might overload a person's short-term memory.  6.  Design for Task Relevance. UI should present information that pertains to the user's task. Any arrangement of items on the screen is task-related.  7.  Aid Orientation and Navigation.  8.  Maintain a User-Centered Perspective. Every element of the design should be traceable to the user requirements.  The guidelines above are at a relatively high level. However, a project does not need to include all of them. It can just select the guidelines that are meaningful in the context of its own user interface design.  2.3.2 Java Look and Feel Style  As the Java platform matured, developers recognized the need for consistent, compatible, and easy-to-use Java applications. The Java look and feel provides a platform-independent appearance and standard behavior to meet this need. It can reduce design and development time, and lower training and documentation costs. The Java look and feel is the default interface for applications built with the Java Foundation Classes (JFC). It has the following characteristics [29]:  •  Consistency in the appearance and behavior of common design elements.  •  Compatibility with industry-standard components and interaction styles.  •  Aesthetic appeal that does not distract from application content  Developers have the choice to choose a look and feel style. They can determine a platform-dependent look and feel, or a cross-platform look and feel. If they specify a  13  cross-platform look and feel, applications appear and perform the same everywhere, simplifying the application's development and documentation. If choosing a particular look and feel, developers can specify an OS-dependent look and feel style. The look and feel styles available in Java 2 SDK as follows:  •  Java look and feel. (Called "Metal" in the code) It is designed for use on any platform that supports the JFC.  •  Microsoft Windows look and feel. (Called "Windows" in the code) It can be used only on Microsoft Windows platforms. It follows the behavior of the components in applications that ship with Windows NT 4.0.  •  CDE look and feel. (Called "CDE/Motif" in the code) It is designed for use on U N I X platforms. It emulates OSF/Motif 1.2.5.  •  Macintosh look and feel. Developers can download the Macintosh style (called "Mac OS" in the code) separately.  2.4 Visual Programming Languages Visual Programming Languages (VPLs) are a combination of computer graphics, programming languages, and human computer interaction. With the increase in computer speed and graphical display capability, a great deal of research and experiments are now possible in the field of visual programming languages. A variety of different methodologies originate from this research field, and numerous software systems are developed for both specific application tasks and more general tasks. 2.4.1 Classification and Concepts  In [13], visual programming languages are classified as:  •  Purely visual language  •  Hybrid text and visual system  •  Programming-by-example system 14  •  Constraint-oriented system  •  Form-based system  These categories are not exclusive and a programming language might belong to more than one category. The category of purely visual language is characterized by its reliance on visual techniques throughout the programming process. The programmer manipulates icons or other graphical representations to create a program, and then debugs and executes it in the same visual environment. The program is compiled directly from its visual representation, and is never translated into an interim text-based language [13]. This category can be further subdivided into sections like iconic and non-iconic languages, object-oriented, functional, and imperative languages. Hybrid text and visual language involves both visual and textual elements. The hybrid systems include programs that are created visually and then translated into a textual language, as well as those utilizing graphical elements in a textual language. Programming-by-example systems provide users with a way to create and design graphical objects to "teach" the system how to perform a particular task. A popular approach for simulation design is the constraint-oriented system. Physical objects can be modeled in the visual environment, subject to a set of constraints, to simulate natural behaviors. These systems have also found applications in the development of graphical user interfaces. The form-based VPLs refer to those borrowing their visualization and programming metaphors from spreadsheets [13]. Some important basic concepts in VPLs are defined by [1], as follows:  Icon: An object with the dual representation of a logical part (meaning) and a physical part (image).  Icon sentence: A spatial arrangement of icons from an iconic system.  Visual language: A set of iconic sentences constructed with given syntax and semantics.  15  Syntactic analysis: An analysis of an iconic sentence to determine the underlying structure.  Semantic analysis: A n analysis of an iconic sentence to determine the underlying meaning.  2.4.2 Automated Control Engine  The Automated Control Engine (ACE) is a software package from International Submarine Engineering Ltd., B.C., Canada. It is designed to help design event-driven, and dataflow, control systems. The A C E is also an implementation of an object-oriented Events and Actions programming paradigm using the C++ language [9]. Events and Actions is an object-oriented event-driven programming paradigm. It is based upon two object types: event and action. Event represents some significant occurrence or occurrence with some related data, such as timer interruption, or message from other components. Action is an appropriate response to a particular event. Typically, an action consists of a procedure for execution, a priority level for the procedure, and a reference to any data belonging to the event. The action may signal events after the completion of its task. Component is another key element in A C E . It is a set of connections to input events and output events with a well-defined transformation between them. A C E programming is therefore, a collection of events and actions, and the connections between them. This type of programming provides a high level of design, which does not require any C++ knowledge. It is a natural approach to real-time or highly interactive systems [9].  2.5 Summary  To develop a visual programming environment for constraint nets, many issues in this chapter must be considered. It is helpful to provide this research's context. For instance, what are visual programming languages, how to design a good user interface for such an 16  environment, which software engineering method is most suited for this application, how to use JavaBeans to develop a component-based software, what is JavaBeans, as well as event-driven programming, and so forth.  17  CHAPTER 3  CONSTRAINT NETS  Over the last twenty-five years, the Constraint Satisfaction Problem (CSP) model developed and matured. Constraint Programming (CP) also evolved several powerful frameworks. The algorithms developed for the Constraint Satisfaction Problem are made more useful and available when they are incorporated into the Constraint Programming (CP) paradigm [23]. This is successful, and as a result, some constraint-satisfying devices are developed. Generally, these devices are offline. A challenge for CP researchers is to develop a theoretical and practical tool for the constraint-based embedded intelligent system. The Constraint Nets model (CN) is developed by Ying Zhang and Alan Mackworth as an abstraction and a unitary framework for developing a hybrid dynamic system, analyzing its behavior, and understanding its underlying physics. This chapter first describes the definition of constraint nets. Then the requirement specification language of timed V-automata, and the behavior verification method are described.  3.1 Constraint Net Model  Intelligent systems embedded as controllers in real systems, or virtual systems, are designed in an online model based on various time structures: discrete, continuous, and event-based. It is a typical hybrid dynamic system. However, the CSP paradigm and CP paradigm are inadequate for this kind of task since they are primarily off-line. Generally, C N is a semantic model for those hybrid dynamic systems. A constraint net model is built as an online dataflow-like distributed programming language with formal algebraic denotational semantics, a requirement specification language, and real-time temporal logic [25].  3.1.1 Constraint-Based Intelligent System  18  An intelligent agent system is normally a hybrid system that runs on the domains of discrete, continuous and event-driven structures. It is modeled as the symmetrical coupling of an agent with its environment. A n agent situated in an environment has three machines: the agent controller, the agent body, and the environment, as shown in Figure 3.1 [23].  AGENT CONTROLLER  Reports  Constraints  BODY J  >  Reactions  Actions >i  \ *  1  ENVIRONMENT ^  J  Figure 3.1. The structure of a constraint-based agent The controller, body and environment are modeled as separate dynamic systems. Both the controller and the body consist of discrete, continuous or event-driven components operating over a discrete or continuous domain. The controller has the perceptual subsystem that can (partially) observe the state of the body, and through the body, partially observe the state of environment. The agent's body is the interface to the environment. The body executes actions in the environment, senses the change of the environment, and reports the environment's state to the controller. Whenever the controller gets the report about the environment's state from the body, it calculates the constraints and sends them to the body. Then, the body performs the actions obeying the constraints.  19  3.1.2 Constraint Net Syntax and Semantics  A constraint net model is a dataflow and equation based model with formal syntax and semantics. It consists of a finite set of locations, a finite set of transductions, and a finite set of connections. Locations can be regarded as communication channels, memory cells, variables, or wires. Transductions are causal mappings from input traces to output traces, operating on a global reference time, or activated by external events [7]. Connections represent interaction structures of the modeled system by relating locations with ports of transduction. Formally, a constraint net is a triple C N = <Lc, Td, Cn>, where Lc is a finite set of locations, Td is a set of transductions, each with an output port and a set of input ports, and Cn is a set of connections between locations and ports [6, 10, 25]. A Connection has to follow some restrictions: one, there is at most one output port connected to each location; two, each port of a transduction connects to a unique location; and three, no location is isolated. A location is an output of the constraint net if it is connected to the output of some transductions; otherwise, it is an input. A constraint net is open if there is an input location; otherwise, it is closed. A constraint net represents a set of equations, with locations as variables and transductions as functions. The semantics of the constraint net, with each location denoting a trace, is the least solution of the set of equations [4]. The semantics is defined on abstract data types and abstract reference time, which can be discrete or continuous. Graphically, a constraint net is depicted by a bipartite graph where locations are depicted by circles, transductions by rectangle blocks, and connections by arcs. For instance, integration is the basic transduction on a continuous time structure. In Figure 3.2, a differential equation ds/dt = f(s) = s' is represented by a constraint net, where so is an initial state. f  Figure 3.2. An integration system in constraint net  20  3.2 Requirement Specification with Timed V-Automata C N graphical modeling language focuses on the underlying structure of a system, such as the organization and coordination of components or subsystems. However, the overall behavior of the modeled system is not explicitly expressed. For many cases, it is important to specify some global properties, and guarantee that these properties hold in the proposed design. Zhang and Mackworth advocate timed V-automata for specifying requirement properties. A discrete V-automaton is a non-deterministic finite state automaton over infinite sequences [6]. It was originally proposed as a formalism for the specification and verification of temporal properties of concurrent programs. Then, discrete V-automata were augmented to timed V-automata by generalizing time from discrete to continuous, and by specifying time constraints on automaton-states. Therefore, timed V-automata can be used to specify languages composed of traces on continuous, as well as discrete, time. A V-automaton A is a quintuple {Q, R, S, e, c}, where Q is a finite set of automaton-states, R c S is a set of recurrent states, and S c Q is a set of stable states. Let r be a run of A over a trace v. r is accepting if every state that appears infinitely many times is a stable state, or if some state that appears infinitely many times is a recurrent state [6]. With each q G Q, an assertion e(q) is associated, which characterizes the entry condition under which the automaton may start its activity in q. With each pair q, q' 6 Q, an assertion c(q, q') is associated, which characterizes the transition condition under which the automaton may move from q to q'. R and S are the generalization of accepting states to the case of infinite inputs. B = Q - (R u S) is the set of non-accepting (bad) states. A V-automaton can be depicted by a labeled directed graph where automatonstates are depicted by nodes, and transition relations by arcs. Furthermore, some automaton-states are marked by a small arrow, an entry arc, pointing to it. Each recurrent state is depicted by a diamond inscribed within a circle. Each stable state is depicted by a  21  square inscribed within a circle. Nodes and arcs are labeled by assertions.  A node or an  arc that is left unlabeled is considered to be labeled with true. The labels define the entry conditions and the transition conditions of the associated automaton. Some examples of V-automaton are shown in Figure 3.3 [6]: (a) states that the system should finally satisfy G; (b) states that the system should never satisfy B and (c) states that whenever the system satisfies R, it satisfies S in some bounded time.  (a)  (b)  (c)  Figure 3.3. V-automata: (a) reachability (b) safety (c) bounded response Timed V-automata are V-automata augmented with timed automaton-states and time bounds. Let R  +  be the set of non-negative real numbers. A timed V-automaton TA  is a triple {A, T, x }, where A = {Q, R, S, e, c} is a V-automaton, T c Q is a set of timed automaton-states, and T : T U {bad} -> R u {<*>} is a time function. A V-automaton is a +  special timed V-automaton with T = 0 and x (bad) = °o. Graphically, a T-state is denoted by a nonnegative real number indicating its time bound. Figure 3.4 shows an example of timed V-automata. This system should satisfy S within 3 time units, whenever it satisfies R.  Figure 3.4. Timed V-automata: real-time response 22  3.3 Behavior Verification In constraint nets, timed V-automata in Section 3.2 work as a requirement specification language. It can specify the required properties for the designed models. To decide whether the model is well-designed or ill-designed, a model checking method is developed to verify the relationship between the behavior of a dynamic system and its requirement specification. Given a constraint net model of a system and a timed V automaton specification of a behavior, the behavior of the system satisfies the requirement specification if and only if the (behavior) traces of the system are accepting for the timed V-automaton. The model checking method developed by Zhang and Mackworth uses the induction principle, and generalizes both Liapunov stability analysis for dynamic systems and monotonicity of well-foundedness in discrete-event systems [21]. A representation between constraint nets and timed V-automata is a state-based transition system, such as Kripke structure. The verification rules are applied to the Kripke structure. A useful and important type of behavior is state-based and time-invariant. A state-based and time-invariant behavior is a behavior whose traces, after any time, are totally dependent on the current snapshot. State-based and time-invariant behaviors can be defined using the generalized Kripke structure. The formal method for behavior verification consists of a set of model-checking rules, which is a generalization of the model-checking rules developed for concurrent programs. There are three types of rules: invariant rules (I), stability or eventuality rules (L) and timelines rules (T) [21].  3.4 Summary  23  In Constraint Nets, timed V-automata are simple to use for requirement specifications. However, they are not powerful enough to represent all possible behaviors. The verification method provides a set of formal model checking rules, which can be used to guide a formal proof procedure. However, the invariants, Liapunov, and timing functions are not automatically created, and the verification of the rules is not automatic, in general. Nevertheless, the C N approach can be used to solve many problems in hybrid system modeling, designing, specification, and verification. This chapter does not attempt a comprehensive illustration of constraint nets. It endeavors to provide basic C N principles for CNJ, and make the thesis self-contained. While the system design of C N J includes the modeling language, the requirement specification language as well as the verification method, until now, C N J has only provided the support for the modeling language. We propose in future work, adding the specification and verification languages to the C N J tool based on the existing CNJ's architecture since our design allows for it.  24  CHAPTER 4  CONCEPTS AND,ARCHITECTURE OF C N J  In C N J , there are predefined icons provided for users to choose, drag and drop, and connect together. C N J supports modularity and hierarchy in C N programming. After completing the model design, users can compile it, simulate it, and see the animation effect. This chapter describes the design idea, requirement analysis and implementation mechanism of CNJ, as well as the class architecture implemented in CNJ.  4.1 Main Idea  C N is a family of visual programming languages. A constraint net consists of locations, transductions, and connections, where locations are depicted by circles, transductions are depicted by rectangles, and connections are depicted by arcs. When users write programs in constraint net language, intuitively, the simplest method is to allow them to drag and drop the predefined nodes, then customize their functions, size, and appearance. Finally, the designed or drawn program is able to run. In CNJ's framework, the realization of such a visual programming environment is based on a few ideas. There are three specific types of nodes for composing a constraint net graph. From the viewpoint of component-based software engineering, each type of node may be implemented as a software component, which is easier for users and program developers. In Java, JavaBeans is the only candidate to support software components. We plan to provide a set of elementary, yet powerful building blocks for constraint net modeling and simulation. The building blocks are implemented with JavaBeans. Each constraint net node is a Java bean, and is added to the C N J environment, then customized. To allow for adding a Java bean, the C N J environment is required to support the Bean Introspection mechanism. There should be a library of utilities and support objects provided to identify the properties, events, and methods that a Java bean supports. With  25  it, the environment can customize the constraint net beans in their functionality in order to meet programming requirements. The communication between Java beans uses Java's event mechanism. Locations and ports of transductions are wired by connections. The Java event mechanism allows Java beans to act as event sources for event notifications that can be caught and processed by some other listeners. The designed constraint net is like a dataflow graph where data are relayed and processed from input locations to output locations. Constraint net modules are coupled by interface locations. If a module's interface location has the same name as one of this module's outside connected locations, the two locations are actually connected together transparently, and communicate with each other (see Figure 4.1). There are several different methods for modeling a hybrid dynamic system, such as bottom-up, top-down, and middle-out. In C N , these modeling methods are generally realized by hierarchical composition and the coupling of modules through input and output interface locations. In fact, a transduction can probably be specified as an arbitrary function. It is certainly impossible to provide all of the arbitrary functions. A few basic functions are provided in CNJ, such as +, -, *, /, or, <, >, sine, if...then...else..., delay, ... Based on these, complicated functions  for particular complex systems  are  able to be  compositionally represented. After users complete designing a constraint net, the constraint net is stored away. Unlike JavaBean's serialization, where a bean is converted into data stream and written into storage, an XML-based file format is used to save a constraint net. We defined Constraint Net Markup Language (CNML) as CNJ's standard interchange file format. C N M L provides CNJ with a lot of advantages that X M L inherently owns. Figure 4.1 illustrates how to put together a system model by bean objects. Using this method, a system model can be built with much less effort by simply picking, zooming, customizing, and coupling components from libraries. The locations labeled with "loc" are modules' interface locations, with which the two modules are connected with each other.  26  Figure 4.1. Putting together a system from bean objects  4.2 Requirement Analysis To work as a visual programming environment, CNJ should be able to support users to 'draw' a program in constraint nets. When programming visually, users choose locations, transductions, connections, and modules to put together a constraint net. To mimic the realistic manual C N design, a component-based modeling and programming framework is the most convenient and beneficial method for building CNJ.  4.2.1 System Requirements  There are several requirements for this kind of modeling and simulation environment:  •  First, it should enable developers to interactively pick components, and place them onto a work area. These components are transductions, connections, and modules. 27  CN's atomic nodes:  locations,  •  Second, connecting has to be accomplished in a way where events and data can be exchanged correctly among the components.  •  Third, the convenient interactive customization of bean properties should be supported by the environment.  •  Fourth, there has to be a method to check each C N node's dynamic values. For instance, users might wish to see a location's changing values while a simulation is running.  •  Finally, such a modeling and simulation environment has to be simple to use and execute. Also the designed model should be reusable as a new component in any other hybrid system. In this case, a very complicated system can be built by assembling some less complicated components.  During our system design period, we hoped to make CNJ run on the Internet as a Java applet, for it is very helpful and important for people to learn and study constraint nets. However, Java applets have a few limits to running on the Internet for several reasons. For instance, an applet runs very slowly under severe network restrictions, it cannot read or write to the local disk, and it has less rich G U I components than a Java application. Therefore, we chose to implement CNJ as a Java application first. Moreover, the implementation of CNJ in Java brings some advantages, such as platform portability, simple implementation, robustness, reliability, and so forth. In such a visual programming environment, users 'draw' constraint net programs, instead of writing code for them. The look and feel is intended to resemble the style of some popular drawing tools such as Adobe Illustrator, M S Painter, and Unix xfig to support constraint net designing. In addition, to make the GUI respond as quickly as possible, we adopt multi-threaded programming to minimize the response time to users' action. In Constraint Nets, a model possibly consists of dozens of modules that are hierarchically located in different levels. To support as many modules as possible, C N J uses Multiple Document Interface (MDI) to display each module in a child window. Thus, every module component corresponds to a child window in the MDI desktop.  28  4.2.2 User Groups  C N J is supposed to be used by three different types of users in three different ways. They are the CNJ Users, CNJ Experts and CNJ Programmers. A CNJ user uses a set of predefined, ready-to-use Java beans (locations, transductions, modules, and clocks) to model a hybrid dynamic system. After picking the beans, he or she can customize them by setting their properties in a dynamic interactive window (PropertyEdit Window), then connect them together, and run simulations with them. He or she needs to know nothing about Java language except for constraint nets. There should be a simple installation and easy-to-use configuration for a CNJ user in different platforms.  In most cases, this type  of user only needs to know how to design a constraint net. We consider CNJ users as the main client. Also, they profit most from the component-based modeling and simulation environment. It should be less effort for them to model an application-specific control system. Although C N J provides all the necessary building blocks for constraint nets, they are still not sufficient to build an arbitrary hybrid system because a transduction bean is not powerful enough to support an arbitrarily complex function. There is a set of basic function options for transduction beans. In most cases, a complex function can be built by those basic transductions. However, occasionally, when building a complex function, a user might find that there is an indispensable basic function not yet provided by CNJ. In this situation, another type of user, CNJ experts, is needed. Besides the capabilities a CNJ user has, a CNJ expert also knows how to write programs in Java in order to implement new functions without which a necessary function cannot be built. A C N J expert heavily relies on Java development tools to implement new functions. However, writing Java code to add new functions is not too troublesome. Based on explicit guidelines, he or she can realize this by modifying a few codes in several specific places. Although the task of a CNJ expert is challenging, it is still not the same as that of a CNJ programmer. A CNJ programmer's task is the most demanding. He or she needs a good understanding of CNJ's source code, detailed structure, modeling and simulation concepts, Java Beans, C N M L , as well as the maximization of components' reusability.  29  4.3 System Architecture CNJ is a hybrid system modeling and simulation environment. With this tool, users can model or render a control system visually in constraint nets (CNRender). Also C N J is able to run or execute the designed models that are driven by Clocks (CNRun). When there is an animation package connected to that control system, the system's running result can be shown explicitly, and also, users can set or change input locations' values interactively through the animation window. The architecture of CNJ is shown in Figure 4.2. Users i  i  CNJ  r  Animation Packages  CNRun  CNRender  Designed Models in Constraint Nets^,  Figure 4.2. Architecture of CNJ  The graphical user interface is an important part, and has the same style that an interactive drawing tool has. It has two main windows: CNFrame and PropertyEdit, as shown in Figure 1.1 in Chapter 1. The CNFrame window is the bigger one. It consists of MenuBar, ToolBar, ToolPane, and DrawPane. A l l the necessary C N nodes are contained 30  in the ToolPane panel (the left column) where there are the Connection bean, Location bean, Transduction bean, Clock bean, and Module bean.  DrawPane is the center area  for drawing constraint nets and has a M D I (Multiple Document Interface) for designing different hierarchies of modules. PropertyEdit window is the smaller one lying to the right, close to the CNFrame, and displays corresponding properties for the focused C N node in the left DrawPane area. To design a constraint net model, users need to choose a graphical C N node from the ToolPane, then drag-and-drop it to the DrawPane. After that, they customize the node's properties in the PropertyEdit window. They can also use connections to wire two C N nodes from the source's output port to the destination's input port. In order to support bottom-up modeling, we implement the "grouping" function to allow designers to generate a higher level of new module component which accommodates those grouped nodes. To support top-down modeling and middle-out modeling, we provide child windows to display modules' content. By double-clicking a module component, its child window pops up accordingly. To make the user interface respond as quickly as possible, CNJ  uses multiple-threaded  programming with  an appropriate  synchronization  mechanism. In CNJ, there are seven packages. For different purposes, Java classes are placed under the packages separately (See Figure 4.3).  •  GUI package There is plenty of development work related to user interface implementation.  There are several windows and a few panels for designing constraint nets interactively. CNFrame.java  corresponds  to  the  left  main window. PropertySheet.java  and  PropertySheetPanel.java correspond to the right main window. Connection .Java implements the connection class in C N . ToolPane.java is for the left column panel in the CNFrame window, in which constraint nets' graphical elementary nodes are located. BeanWrapper.java seems like a "wrapper" for a Java bean. Every instantiated bean is actually contained and packed in a BeanWrapper object when it is shown in C N J . EditedAdapter.java works as an adapter which can listen to the PropertyChangeEvent, and transfer the event to a proper object to handle it. In the center of the CNFrame  31  window, it is a Multi-Document desktop with a set of child windows within it. The child window is realized in DrawFrame.java. PrintUtilities.java enables the printing of a constraint net, and the export of a constraint net to a postscript file. DrawPane.java is a big file which has approximately 2,000 lines of code. It works as a drawing area embedded in the DrawFrame child window. Lots of constraint net drawing and designing mechanisms are implemented in the class of DrawPane.  (  J  J a v a class  Figure 4.3. Class architecture graph  •  PropertySupport package By the means of JavaBeans Introspection, CNJ is able to detect a bean's properties. A  property might have either a string, integer, float, or Color type. For each type, there is a PropertyEditor to allow for displaying and editing this type of data. PropertyColor.java supports the PropertyEditor for the Color property; PropertyText.java supports the  32  PropertyEditor for the String property; PropertySelector.java supports the PropertyEditor for the Items (multiple options) property.  •  xml package After constraint nets are finished or partly completed, they are stored in an X M L -  based file format of C N M L (Constraint Net Markup Language). To read and write a C N M L file, the class of CNMLIO.java is implemented and put in the xml package.  •  CNAdv package At the top right of the CNFrame window, there is an animation panel for advertising  CNJ tool. Its classes are placed under this directory.  •  CNBeans package A l l of the C N beans are placed in this package. It includes Java bean classes for  transduction, location, clock, and module. These are inherited from one parent class named CNNode. Also, there are four subdirectories under the CNBeans: Clock, Transduction, Location, and Module. Since Transduction is realized as a Java bean, its bean supporting files are placed under its subdirectory, including:  •  Transduction.java  •  TransductionBeanlnfo.java  •  CNFunction.java  • CNFunctionDlg.java •  PropertyCNFunction.java  •  FunctionCustomEdi tor .java  Similarly, the Location package has Location.java and LocationBeanlnfo.java. The Clock package has Clock.java and ClockBeanlnfo.java. Also, there are Module.java and ModuleBeanlnfo.java in the package of Module.  33  4.4 Summary This chapter gives the design idea, system requirements, and system design of CNJ. The requirement analysis determines that C N J has the interactive drawing look-and-feel, while supporting visual modeling as well as real-time simulation. The utilization of component-based technology (JavaBeans) gives rise to the extensibility of C N J and reusability of module components. Moreover, the class architecture and package composition of CNJ are also presented.  34  ^CHAPTER 5  GRAPHICAL USER INTERFACE DESIGN  This chapter illustrates the GUI design of CNJ. The tool is a component-based modeling and simulation environment where each C N node is a bean, and C N J itself, is a JavaBeans introspecting environment. The design methodology is based on assembling or drawing a constraint net from a set of graphical building blocks (CN nodes), and then running or simulating that program. C N J aims to provide users with numerous convenient features, such as drag-and-drop, zoom in, zoom out, move, automatic connection wiring, and so on. To avoid the slow response of GUI written in Java, it uses multi-threaded programming among most UI panels. The following sections describe the user interface architecture, UI threads, important supporting classes, and C N nodes as beans.  5.1 User Interface Architecture In CNJ's user interface, there are dozens of panels with different purposes. To support human-computer interactive functions, CNJ's windows have several layers of Java components. First, we introduce the concepts and functions of those panels. Then we describe how the GUI is composed.  5.1.1 GUI Introduction  As described in Section 4.3, there are two main windows in C N J : CNFrame and PropertyEdit. CNFrame is the left bigger window for supporting constraint net designing and simulation. PropertyEdit is the right one, supporting the dynamic customization of the focused object's properties. Figure 5.1 presents the composition graph of CNFrame.  35  Menu Bar  Tool Bar  Advertisement Pane  Grouping TransductionLocation Connection Clock _ ModuleModule Border-  Tool Pane-  MDI Desktop  Status Pane  Draw Pane  Draw Internal Frame  Figure 5.1. CNFrame composition  On the Tool Pane, there are seven icons. The five icons of Transduction, Location, Connection, Clock, and Module are C N nodes, which serve as building blocks for designing a constraint net. Whenever a node is needed, users click its corresponding icon and drag-and-drop it to the central Draw Panes. The "grouping" icon is used in the method of bottom-up modeling. That is, when a user wants to convert several components into a module, he or she uses the "grouping" function to circle those components, and then a new module is created from them at a higher level. "Module Border" is used for drawing a dashed-line round-corner rectangle. In a constraint net  36  module, a border is required to separate input and output interface locations from other components. In the center of the CNFrame is the M D I desktop. The M D I desktop is used as a container to create a multiple-document interface, or a virtual desktop. It manages potentially overlapping Draw InternalFrames, as there are probably dozens of Draw InternalFrames within it. A Draw InternalFrame extends JInternalFrame and can be added to the M D I desktop. A Draw InternalFrame displays a set of constraint net components. It is either a C N module or the highest level of a model. The Draw InternalFrame usually corresponds to a specific module at a higher level. When users double click a module component, its Draw InternalFrame window pops up accordingly. Each Draw InternalFrame contains a Draw Pane. Draw Pane is the actual area for painting visual components and allowing them to be visually manipulated. Before being added to a Draw InternalFrame, Draw Pane is placed into a JScrollPane, which provides a scrollable view of Draw Pane. When users layout a constraint net larger than CNJ's window size, the drawing area is extended automatically. In CNJ, most of the work of constraint net modeling is done in the Draw Pane windows. Status Pane provides users with interactive information, such as prompts, running results, and online help. Advertisement Pane is an animation window used to show lines of fancy words about C N J with animated effects, such as contributions, authors, copyrights, and acknowledgements.  5.1.2 GUI Composition  The graphical user interface of CNJ is created using Java Swing components. It has a predefined containment hierarchy, which is hard to understand unless reading the source code. We introduce those Swing components, and show how they fit together into a multi-leveled containment hierarchy. The root of the containment hierarchy is a top-level container, which provides a place for its descendent Swing components to paint themselves.  37  CNFrame contains  Menu Bar I  Tool Bar I JButton  MDI Desktop I  Tool Pane I  Draw InternalFrame  Status Pane I  JButton  AdvPane  JLabel  JScrollPane  Draw Pane  Bean Wrapper 1  CN Bean  j  Figure 5.2. Containment hierarchy of CNJ GUI Figure 5.2 is a diagram of the containment hierarchy for the CNFrame window. It shows each container created or used by CNJ, along with the components it contains. CNFrame is the top-level container, which extends the class of JFrame. It contains components of Menu Bar, Tool Bar, M D I Desktop, Tool Pane, Status Pane, and Adv Pane. It is also composed of seven levels in its containment hierarchy. In Figure 5.2, an upper parent component is the container of its child components.  5.2 Multi-threaded Panels Programs implemented in Java often involve slower speeds because of the Java virtual machine (JVM) that often interprets the bytecode at the runtime. To avoid this in CNJ, we implement multiple threads in programs to make the user interface respond as quickly as possible. 38  In the Draw Pane, users can choose one specific component, and focus on it with shaded hash bars around it. A thread called focusThread is created in CNFrame.java to handle the focus change. Whenever the focus has changed, the thread detects it immediately, and draws hash bars around the new focused object. When designing a constraint net, users pick an icon from the Tool Pane, then put it into a Draw Pane. To respond to this picking action, CNJ creates an internal thread of insertThread in ToolPane .Java. The thread detects that the user has clicked an icon and that it instantiates a bean object for the icon. The eventThread is implemented in DrawPane.java. It is blocked by, and waiting for, a mouse click event. The thread distinguishes two kinds of mouse click events. One mouse click event is used for inserting a Java bean. The other one is used for drawing a C N connection. Two different processes are notified and executed for the two mouse click events. Finally, the thread of animationThread is created in the animation package. It runs separately from the C N J simulation. Depending on its internal clock, it runs in a variety of speeds. In addition, the animation thread is capable of setting a user's input to input locations of a constraint net, and at the same time, displaying the simulation result in an animation window.  5.3 Important UI Classes In the GUI package, there are a dozen of classes. Among them, DrawPane is the most important  one.  Other  classes  such  as  BeanWrapper,  CNFrame,  and  BeanPropertySheetPanel are also important. In this section, we introduce the classes of DrawPane (shown in Table 5.1) and PropertySheetPanel. The simpler methods in the DrawPane class are omitted from Table 5.1.  5.3.1 DrawPane Class  39  public c l a s s D r a w P a n e  Public  DrawPane(CNFrame mainFrame) C o n s t r u c t s a n e w D r a w P a n e . T h e a r g u m e n t of m a i n F r a m e is the left C N F r a m e w i n d o w w h i c h is u n i q u e for e a c h C N J r u n n i n g .  public CNFrame  public void  getCNFrame() R e t u r n s the h a n d l e of the left C N F r a m e w i n d o w . . i n s e r t B e a n ( O b j e c t b e a n , String b e a n N a m e ) A d d s a J a v a b e a n to the D r a w P a n e .  public v o i d  s t a r t M o v e ( B e a n W r a p p e r w, i n t x , i n t y ) Initializes a m o v e o p e r a t i o n after u s e r s h a v e c l i c k e d the m o u s e button on the w r a p p e r w h i l e m o v e - c u r s o r a p p e a r s .  public v o i d  s t a r t R e s i z e ( B e a n W r a p p e r w, i n t x , i n t y , C u r s o r c u r s o r ) Initializes a resize o p e r a t i o n after u s e r s h a v e c l i c k e d the m o u s e button on the w r a p p e r w h i l e r e s i z e - c u r s o r a p p e a r s .  public void  M o u s e P r e s s e d ( M o u s e E v e n t event) Starts t h e " g r o u p i n g " o p e r a t i o n if s o m e c o n d i t i o n is satisfied.  public v o i d  M o u s e R e l e a s e d ( M o u s e E v e n t event) H a n d l e s the m o u s e r e l e a s e event.  public void  mouseClicked(MouseEvent event) H a n d l e s the m o u s e click event.  public v o i d  m o u s e M o v e d ( M o u s e E v e n t event) D r a w s a c o n n e c t i o n s e g m e n t like a r u b b e r b a n d .  public v o i d  MouseDragged(MouseEvent event) H a n d l e s the m o u s e d r a g event.  public void  S e t D r a g g e d H a n d l e ( i n t index) R e c o r d s the index of the h a n d l e w h i c h is c h o s e n by a user f r o m a connection.  Continued 40  private  G e t G r o u p i n g B o x ( i n t deltaX, int deltaY)  rectangle  Figures  out t h e o n - s c r e e n  b o x to be d r a w n  to r e p r e s e n t  the  p r o p o s e d n e w location of a g r o u p i n g box. private void  D r a w M o d u l e B o x ( G r a p h i c s g, R e c t a n g l e box) D r a w s a d a s h e d line r o u n d - c o r n e r r e c t a n g l e a s a m o d u l e border.  public void  run(  ) A t h r e a d ' s running b o d y to h a n d l e users' m o u s e c l i c k i n g e v e n t s .  public void  DoEventHookup() Starts to d r a w a c o n s t r a i n t net c o n n e c t i o n b e t w e e n t w o b e a n s , a n d c r e a t e t h e first s e g m e n t of that c o n n e c t i o n .  public v o i d  scrollLayout(Rectangle area, BeanWrapper wrapper) C h e c k s w h e t h e r a b e a n is o u t of t h e a r e a of t h e original w i n d o w . If it is, C N J will a d j u s t t h e size of t h e d r a w i n g a r e a to fit it.  private v o i d  G r o u p T o M o d u l e ( i n t x 1 , int y 1 , i n t x 2 , int y 2 ) G r o u p s t h e c o m p o n e n t s inside t h e r e c t a n g l e of (x1,y1) a n d (x2,y2) into a n e w m o d u l e , w h i c h is c r e a t e d at a h i g h e r level.  Table 5.1. DrawPane class There are a few other methods for supporting the creation of new C N beans based  on  the  data  read  from  a  CNML  file.  These  methods  includes:  createTransductionFromElementQ, createLocationFromElementi), createModuleFromE lementQ, createConnectionFromElementQ, and createClockFromElementQ. Other methods provide support connection  for drawing connections,  while keeping  segments horizontal or vertical, selecting a component,  deleting a  component, dragging a rubber line, scrolling a view, building the communication between two beans, compiling a designed constraint net, as well as running simulations, and so forth.  5.3.2 PropertySheetPanel Class  41  CNJ realizes the Bean Introspection mechanism which enables the identification of a bean's properties and methods. Using this method, we do not need to customize a different PropertyEdit window for each kind of bean, and C N J can add appropriate components into the PropertyEdit to form a new edit window for the bean. This step is executed automatically by programs. The PropertySheetPanel class mainly supports Bean Introspection. Whenever users click an object in the left CNFrame window, the setTarget( ) method in the PropertySheetPanel is called. The method first identifies the new focused object's properties, then creates and adds their corresponding visual components in the PropertyEdit window. Its code is shown in Figure 5.3. * * * * *  setTarget() provides support for Bean Introspection. The Argument w is current focused bean in the left CNFrame window. When the focus is changed, this method will be called. The visual components for that focused bean are then added into PropertyEdit.  public v o i d s e t T a r g e t ( B e a n W r a p p e r w ) { propertyFrame.getContentPane().removeAII(); removeAII(); wrapper = w; bean = w.getBean(); try { B e a n l n f o bi = l n t r o s p e c t o r . g e t B e a n l n f o ( b e a n . g e t C l a s s ( ) ) ; pds = bi.getPropertyDescriptors(); } catch (IntrospectionException ex) { S y s t e m . e r r . p r i n t l n f P r o p e r t y E d i t W i n d o w c o u l d n ' t introspect"); return;  } int len = p d s . l e n g t h ; editors = n e w P r o p e r t y E d i t o r [ l e n ] ; v a l u e s = n e w Objectfjen]; views = new JComponentfJen]; names = new JLabel[len]; // c r e a t e e v e n t a d a p t o r EditedAdaptor adaptor = new EditedAdaptor(propertyFrame); for (int i = 0; i < len; i++) { String n a m e = p d s [ i ] . g e t D i s p l a y N a m e ( ) ; Class type = pds[i].getPropertyType(); M e t h o d getter = p d s [ i ] . g e t R e a d M e t h o d ( ) ; M e t h o d setter = p d s [ i ] . g e t W r i t e M e t h o d ( ) ;  Continued 42  if (getter == null || setter == null) c o n t i n u e ; J C o m p o n e n t v i e w = null; try { O b j e c t argsD = {}; values[i] = g e t t e r . i n v o k e ( b e a n , args); Class pec = pds[i].getPropertyEditorClass(); P r o p e r t y E d i t o r editor = null; if ( p e c != null) { editor = ( P r o p e r t y E d i t o r ) p e c . n e w l n s t a n c e ( ) ;  } if (editor == n u l l ) { editor = P r o p e r t y E d i t o r M a n a g e r . f i n d E d i t o r ( t y p e ) ;  } if (editor == null) { S y s t e m . o u t . p r i n t l n f C a n ' t find t h e P r o p e r t y E d i t o r f o r : " + n a m e ) continue;  } editors[i] = editor; editors[i].setValue(values[i]); editors[i].addPropertyChangeListener(adaptor); if ( e d i t o r . g e t V a l u e ( ) i n s t a n c e o f C o l o r ) { view = (JComponent) new PropertyColor(propertyFrame,editor); views[i] = v i e w ;  } if (editor.getValue() i n s t a n c e o f String) { view = (JComponent) new PropertyText(editor); views[i] = v i e w ;  } if ( n a m e . e q u a l s f f u n c t i o n " ) ) { view = (JComponent) new FunctionCustomEditor(propertyFrame,editor); views[i] = v i e w ;  } if ( n a m e . e q u a l s f t y p e " ) ) { view = (JComponent) new PropertySelector(editor); views[i] = v i e w ;  } } catch (InvocationTargetException ex) { S y s t e m . e r r . p r i n t l n f C a n ' t i n v o k e a getter m e t h o d " ) ; ex.printStackTrace(); continue; } catch (Exception ex) { S y s t e m . e r r . p r i n t l n f C a n ' t h a n d l e t h e property: " + n a m e ) ; System.err.println(ex); continue;  } names[i] = new JLabel(name); add(names[i]); add(views[ij);  } propertyFrame.getContentPane().add(this, BorderLayout.CENTER); propertyFrame.show();  }  Figure 5.3. Method of setTarget() in BeanPropertySheet 43  5.4  Constraint Net Nodes  The building blocks for constraint net modeling consist of transductions, locations, modules, clocks, and connections. Each of these is implemented as a Java bean, except for connection, which is implemented as a geometric polyline. Their classes are put separately into different packages. To implement the C N nodes as Java beans, some programming rules and Java classes are required. The C N nodes of transduction, location, module, and clock have some common attributes and methods. We place these common attributes and methods into one parent class named CNNode. The CNNode is thus inherited by all the constraint net node classes shown in Figure 5.4. Transduction  Location  CNNode  Module  Figure 5.4: CN bean classes  5.4.1 Transduction Bean The class of Transduction is a child class of the CNNode. Its related classes are put under the directory of Transduction (in one package). They are classes of Transduction, TransductionBeanlnfo, CNFunction, PropertyCNFunction, FunctionCustomEditor, and CNFunction.  44  The Transduction class contains an important attribute of the CN function, which is to define its supported function. It implements a variety of methods for computing different functions, such as +, -, delay, sine, cosine, and so forth. The CNFunction class represents a constraint net function, and has the attributes of function name, input number, input data type, output data type, and input buffer. TransductionBeanlnfo class provides explicit information about a transduction bean's properties, methods, and events. Without the Beanlnfo class, all of its implicit properties, methods, and events from Java foundation classes are shown in CNJ.  ~W Properties - Transduction  - •  X  backgroundColor color foregroundColor function  +  label  _  N/A  +  Figure 5.5. PropertyEdit of Transduction  X~W Function Definition for -  \M\x\  d a t a t y p e at port 1:  integer  "w  data type at port 2:  integer  •  Ok  Cancel i  Figure 5.6. Transduction definition for "minus"  45  The class of PropertyCNFunction inherits from PropertyEditorSupport the ability to allow for editing a CNFunction object. After finding the CNFunction type, C N J displays a specific visual view for it. The visual view is provided in the class of FunctionCustomEditor which supports both the showing and choosing of a function name in a ComboBox (see Figure 5.5). After users choose a function name, a new dialog pops up to let them customize that function (see Figure 5.6). The implementation of function customization is in the class of CNFunctionDlg.  5.4.2 Location Bean The Location class also inherits from CNNode. A location is used to store a trace of a constraint net. Its attributes include location type, trace clock, and trace value. A location type can be either integer, real, boolean, event, or vector. Its bean-related classes are put under the directory of Location. The class of LocationBeanlnfo provides explicit information about Location bean's properties, methods, and events. Based on the LocationBeanlnfo, the properties of Background Color, Foreground Color, Color, Label, Type, Trace Clock, and Trace Value are shown in the PropertyEdit window. Extended from PropertyEditorSupport, the LocationTypeEditor class allows C N J to access a location's type value. 5.4.3 Clock Bean The Clock contains classes similar to what Transduction and Location have: Clock and ClockBeanlnfo. A clock bean has an important property of "cycle", which defines how many milliseconds it takes for a clock to tick. If its cycle is set to 10 milliseconds, the clock's frequency is 1000/10 = 100 Hz. To support the Clock's timing, C N J uses Java Swing's Timer class. A Timer object is able to fire action events (clock triggering events) to each of its connected transductions in a specified frequency.  5.4.4 Module Bean  46  Module classes are put under the directory of Module. Similar to the other beans, the Module bean has related classes of Module and ModuleBeanlnfo. The module itself does not have many properties, and it only has Background Color, Foreground Color, Color, and Label. Each module bean corresponds to a constraint net module, and has a child window to show its contents. Modules are generally used for the methods of top-down, bottom-up, and middleout modeling. They are hierarchically located in different levels. To provide support for the communication between modules in CNJ, some special methods are developed. A module bean's input location is relayed inward to the module's input interface location, and a module's output interface location is relayed outward to the module bean's output location. When the module is driven by a clock, its transductions must be triggered in a correct order because the transductions have a dependency relationship among them. CNJ uses the transduction scheduling algorithm and a heuristic method to find their dependency, and then lets the clock drive them in that order.  5.4.5 Connection A connection is one of the building blocks for constraint net modeling, but it is not implemented as a Java bean. A connection is drawn as a red directed polyline to connect locations and ports of transductions. When a connection is created between one location and one transduction, there is an event transfer from the source to the destination. The Connection class is put under the directory of GUI. Methods in Connection.java deal with drawing a polyline, editing and moving handles of the polyline, as well as checking the compatibility of data types for the connected location and transduction.  5.5 Summary This chapter concentrates on an overview of CNJ's graphical user interface. It introduces the composition and architecture of the user interface. To provide an easy-to-use, extensible and convenient user interface, C N J creates multiple threads in program and utilizes the JavaBeans Introspection mechanism. Furthermore, it describes some  47  important UI classes and the detailed implementation of C N nodes as Java beans transductions, locations, clocks, modules, and connections.  48  CHAPTER 6  C N J SIMULATION  After modeling a hybrid system in constraint nets, designers can run a simulation to verify the model. This chapter introduces how to support the real-time simulation in CNJ, which implements the object-oriented Java Event mechanism. Before running the simulation, a compilation step is used to detect the syntax errors. Since C N is a generalization of dataflow with multiple data and events, and contains a set of dependency relationships, C N J has to find a correct order for the data flow using the Transduction Scheduling algorithm. Another issue on the real-time simulation of CNJ is also discussed in this chapter.  6.1 Java Event Mechanism In the past, a program which tried to figure out what the user was doing, had to actively ask for such information itself. This method often implies an infinite loop which repeatedly checks a user's status, and then takes the appropriate action. This technique is known as polling. Polling is workable, but it tends to be unwieldy when used in modernday applications because of its C P U waste and large code in one location. In Java, these problems are solved by event driven programming, which is also popular in Window systems. An event describes a specific kind of user action. Rather than the program collecting events, J V M notifies the program when an interesting event occurs. Programs that handle user interaction in this way are called event driven [19]. To receive an event, a Java object has to implement the appropriate interface, and be registered as an event listener on the appropriate event source. After hearing an event, the object performs some actions to handle the received event. Each event-handling code executes in the single thread of event-dispatching thread. This ensures that each event handler finishes executing before the next one executes. In C N J , a connection's target node registers to listen to the events from the source node of the connection. After setting up a connection between a location and a  49  port of transduction, the data flows from the location to the transduction, or from the transduction to the location, depending on the connection's direction. Different from event types used in the GUI implementation, C N J utilizes the PropertyChangeEvent to support the CNJ simulation. In CNJ, the PropertyChangeEvent is applied in three cases: (a) Transduction works as the event source and Location as the event listener, (b) Location works as the event source and transduction as the event listener, (c) Clock works as the event source and transduction as the event listener. These three cases each carry different data objects. These are shown in Figure 6.1.  Transduction Event Source  (a) Transduction as event source, Location as event listener  Transduction Location value  Event Source  Event Listener  Transduction ft Event Listener  Transduction  Event Listener  (b) Location as event source, Transduction as event listener  50  Event Listener  Event Listener  Event Listener  (c) Clock as event source, Transduction as event listener  Figure 6.1. Three types of PropertyChangeEvents in CNJ Simulation  To realize such a mechanism for supporting PropertyChangeEvent propagation between constraint net nodes, three bits of code are required:  1) In the event listener class, write the code to specify that the class implements the PropertyChangeListener interface. public  class  CNBean implements  PropertyChangeListener {  2) In the event source class, write the code that registers an instance of the event listener class. public  PropertyChangeSupport pceListeners = new PropertyChangeSupport(this); pceListeners.addPropertyChangeListener(instanceOfCNBean);  3) In the event listener class, write the code that executes the event handler in the listener interface. For instance, a transduction bean calculates a new value after getting its inputs, and then fires an event to its connected output location. public  void p r o p e r t y C h a n g e ( P r o p e r t y C h a n g e E v e n t evt) { ... // c o d e that h a n d l e s t h o s e heard e v e n t s . // T r a n s f e r its n e w v a l u e to its registered e v e n t listeners. pceListeners.firePropertyChangefEvent Name", newvalue, oldvalue);  }  51  After a constraint net is designed, the relationship between event sources and event listeners is built up. Whenever there is a data change, the event of data changing is propagated from the source to the connected listening nodes, which continues to propagate after some processing. During the process of propagation, C N clocks are indispensable. Clock is a special kind of transduction with no input locations. It has a specifiable frequency. A clock drives all of its connected transductions in each cycle to trigger them to compute their functions. Without clocks, data is not able to flow further, since transductions' function calculation and data propagation happen only if they get a clock event. The following constraint net example in Figure 6.2 represents an equation of x(t) = x(t-l) + step. We assume x = 100, step = 2, at t = 0, and the time unit is equal to the clock's cycle (in milliseconds).  Figure 6.2. A constraint net to represent x(t) = x(t-l) + step  Users are able to run the simulation where transductions of "+" and "delay(l)" are driven by a clock. The simulation output is shown in Table 6.1.  52  t=0  t+1  t+2  t+3  t+4  t+5  t+6  t+7  X  100  102  104  106  108  110  112  114  step  2  2  2  2  2  2  2  2  Table 6.1. Simulation output of a simple constraint net  6.2 The Compilation Step of CNJ In the design of constraint nets, users might make some errors which are either syntactic or semantic. In C N , there is a set of syntax rules for designing a well-formed constraint net. Formally, a constraint net is a triple C N = <Locations, Transductions, Connections>. To design a connection, users have to follow restrictions:  (1) there is at most one output port connected to each location; (2) each port of a transduction connects to a unique location; and (3) no location is isolated.  The above restrictions also affect the design of transductions and locations. First, a transduction/location cannot be directly connected with another transduction/location, which means a transduction is always connected to a location. Second, each location can have only one output port. Third, a location's input should be dependent on a unique transduction's output. Fourth, a location's data type should be compatible with the data type of its connected transduction port. Not obeying the rules results in syntax errors. In C N J , we implement a compilation module to detect syntax errors. After a user completes designing a constraint net, he or she clicks the menu to start a simulation. However, the simulation cannot run unless it passes the compilation. The compilation module works as follows.  •  First, it checks the data type compatibility for the connected locations and transduction ports. There are 5 kinds of data types in CNJ: integer, float, boolean, event, and vector. When finding such a kind of error, it displays the prompt 53  "Error: data type incompatibility from Location-^ Transduction typel, type?' if data flows from a location to a transduction. •  Second, it checks to make sure that there is no case where two transductions are connected together directly.  •  Third, it checks whether all the transduction's functions are defined completely and correctly. If not, a prompt "Error: undefined Transduction name" pops up.  •  Fourth, it checks to ensure a location's input depends on a unique transduction.  •  Finally, it checks whether each of the input locations in the top-level module has an initial value. If there is one input location not set, C N J displays an error prompt "Should not start simulation since not all the input locations are set."  Whenever a syntax error is found, the simulation stops immediately. Users have to redesign their constraint nets to correct the syntax errors. CNJ's compilation step greatly reduces users' design errors. However, because it is still a prototype, it does not guarantee that it constrains users to make absolutely syntax-correct constraint nets. Besides those syntax errors, there are semantic errors. A semantic error might occur while the simulation is running. When a Java exception is thrown out, a semantic error occurs. In our experiments, a semantic error might occur when a constraint net is very complex and has a lot of cycles (feedback) in its graph. This problem is related to the transduction scheduling algorithm, which sorts out transductions and then drives them one by one. Such an error can be avoided if users know how to break the cycles through defining some special locations in non-white color ("heuristic tips"). The transduction scheduling algorithm is introduced, in detail, in Section 6.3.2.  6.3 Dataflow Issue C N is a dataflow with multiple data and events. Data and events produced and consumed by C N nodes are carried by Java objects, which flow along the connections from tails of connections to their heads. The dataflow computing model is based on the flow of data, not on the flow of control. Unlike the control-flow computing model, it assumes that a program is a data dependency graph whose nodes denote operations, and whose edges 54  denote dependencies between operations. A dataflow computing model executes any operation denoted by a node as soon as its incoming edges have the necessary operands [11]. There are two kinds of dataflow models: data-driven dataflow model and demanddriven dataflow model.  6.3.1 Data-Driven and Demand-Driven Models  The dataflow model described above can be more accurately characterized as a datadriven dataflow model. It often implies the qualification of "data-driven". The datadriven dataflow model was invented as an architectural abstraction, based on which dataflow computers are built up. A n Operand set is used as the basis for the firing rules in data-driven systems. The firing rules may be strict or non-strict [11]. A strict firing rule requires a complete operand set to exist before a node can fire; a non-strict firing rule triggers execution as soon as a specific proper subset of the operand set is formed. The latter rule gives rise to more parallelism. Another important branch of the dataflow model is demand-driven dataflow. It was invented as a computing model to efficiently evaluate programs in non-strict dataflow languages. The basic idea behind demand-driven dataflow execution is that "an operation of a node will be performed only if there are tokens on all the input edges and there is a demand for the result of applying the operation" [11]. Its main motivation is to deal efficiently with non-strictness, something that data-driven cannot deal with efficiently.  6.3.2 Dataflow in CNJ  The language of constraint nets is a graphical programming model whose programs can be given mathematical semantics under a particular data algebra. Constraint nets appear similar to dataflow graphs, but they do not make any assumptions about how they are evaluated. It is possible to be either data-driven or demand-driven. It also often denotes a semantic model, which is a composition of other modules corresponding to subnets. To execute a constraint net program, CNJ regards it as a specific computation given a set of  55  sequences of input values and a sequence of demands for output values of the constraint net. At the initial step, only the values of the input locations are defined. At each subsequent step, some of the undefined locations are computed and eventually, the constraint net outputs are computed. In CNJ, a C N module component is often both connected with and driven by a clock. To evaluate the module correctly, the transductions contained in the module have to be triggered in proper sequence. C N J uses the transduction scheduling algorithm to figure out a right dependency relationship within the transductions. Then the clock triggers those transductions one by 'one in that order. This approach allows the 6  computation of constraint net modules to work as demand-driven dataflow, and it works well.  6.3.3 Transduction Scheduling Algorithm  In general, a module component is triggered by one outside clock. It consists of a set of connections, locations and transductions. The clock's driving events are transferred to the module's inside transductions, but the problem is how to drive the transductions and in what order. To find out a correct order to drive the transductions, we implement a scheduling algorithm based on the topological sorting algorithm. Topological sorting is a natural problem in many algorithms on directed acyclic graphs (DAG). Topological sorting orders the vertices and edges of a D A G in a simple and consistent way. It can be used to schedule tasks under dependency constraints. The problem of topological sorting is described as follows:  Input: A directed, acyclic graph G=(V, E) (also known as a partial order). Problem: Find a linear ordering of the vertices of V such that for each edge (rj) in E , vertex i is to the left of vertex j.  56  a) A constraint net module  G>  (7)a Vy  Sine  +  Level 1 Level 2  Level 3  Level 4  Level 5 b) The hierarchical tree after sorting  57  c) The sorted order to drive the nodes  Figure 6.3. A transduction scheduling example  The topological sorting problem is also applicable to constraint net graphs. Suppose we have a set of transductions to be driven in a C N module, and certain transductions must be computed before other transductions. These dependency constraints thus form a constraint net (also a directed graph). The transduction scheduling algorithm searches for an order to execute the transductions, such that each is performed  only after  all of its previous transductions  are executed. In the  implementation, it utilizes the breadth-first algorithm to transverse the constraint net graph, but in a backward way (from output interface locations to input interface locations). The algorithm picks vertices in hierarchical levels with the output interface locations as roots. That is, if a vertex has an out-degree-count 0 it can be next in the topological order. Then, the algorithm removes this vertex and looks for another vertex with an out-degree-count 0 in the resulting D A G . It repeats this until all vertices are added to the topological order. Figure 6.3 represents a constraint net example to illustrate the algorithm. Graph a) shows a constraint net module. After applying the breadth-first algorithm to transverse the graph from the end to the beginning, together with an outdegree-count in each node, a linear order is reached in Graph b), where the numbers denote the order of the node in the breadth-first transverse. However, the order in Graph b) is not the final result yet, since the sequence number is calculated with the roots of the output locations instead of the input locations. Therefore in Graph c), a correct order is 58  finally acquired after reversing the order in Graph b). Based on the final order, the execution of the module works correctly. Although the ordered sequence includes both transductions and locations, the clock only needs to trigger the transductions. The transduction scheduling algorithm, however, does not work without the condition that the constraint net has to be a directed acyclic graph (DAG). Sometimes constraint nets have feedback connections resulting in a few cycles in the graph. In the complex case of a directed cyclic graph, those cycles have to be broken up, and then it becomes an acyclic graph. In C N modules, a cycle forms when there is a backward connection for creating a feedback. To run the simulation, the particular location in that feedback cycle has to be assigned an initial value (or else, the involved transduction can never get inputs to compute). Such a special kind of location is regarded as a "heuristic tip" for breaking up cycles. When designing a constraint net and confronting a feedback cycle, designers are required to paint the special location in a non-white background color. It also reminds designers to assign an initial value to that location before starting the simulation. The Java method for the algorithm is listed in Figure 6.4.  public v o i d . d r i v e T r a n s d u c t i o n s l n O r d e r ( l o n g t i m e s t a m p ) { DrawPane drawP = drawFrame.getDrawPane(); V e c t o r vector; Transduction transduction; BeanWrapper wrapper; Vector orderVector = new Vector(); int n u m b e r = d r a w P . g e t C o m p o n e n t C o u n t ( ) ; HashMap visitedMap = new HashMap(); HashMap dependentCountMap = new HashMapO; O b j e c t Q u e u e q u e u e = n e w O b j e c t Q u e u e ( n u m b e r ) ; // a F I F O q u e u e c l a s s . // First, a d d t h e o u t p u t interface l o c a t i o n s to Q u e u e , vector = drawP.getOutputlnterfaceLocationWrappers(); for (int i = 0; i < v e c t o r . s i z e ( ) ; i++) { queue.addToQueue(vector.elementAt(i)); visitedMap.put(vector.elementAt(i),new Boolean(true));  } while (!queue.isEmpty()) { Object current = queue.getFirst(); / W r a p p e r orderVector.addElement(current); v e c t o r = queue.getConnectedNodes((BeanWrapper) c u r r e n t ) ;  Continued 59  for (int i = 0; i < v e c t o r . s i z e ( ) ; i++) { wrapper = (BeanWrapper) vector.elementAt(i); if ( ! v i s i t e d M a p . c o n t a i n s K e y ( w r a p p e r ) ) { /* i s L e g a l T o P u s h ( ) d e c i d e s w h e t h e r a n o d e s h o u l d be a d d e d * to t h e tail of t h e Q u e u e , a l s o b r e a k s up c y c l e s . */ if ( i s L e g a l T o P u s h ( w r a p p e r , d e p e n d e n t C o u n t M a p ) ) { queue.addToQueue(wrapper); visitedMap.put(wrapper,new Boolean(true));  }  }  }  queue.removeFirstFromQueue();  } BeanWrapper element; Object bean; // r e v e r s e t h e o r d e r to drive in t h e o r d e r V e c t o r . for (int i = o r d e r V e c t o r . s i z e ( ) - 1 ; i > = 0; i~) { element = (BeanWrapper) orderVector.elementAt(i); // trigger t r a n s d u c t i o n s to c o m p u t e , bean = element.getBean(); if ( b e a n i n s t a n c e o f T r a n s d u c t i o n ) { transduction = (Transduction) bean; transduction.computeResult(timestamp);  } // trigger m o d u l e s to e x e c u t e , if ( b e a n i n s t a n c e o f M o d u l e ) { Module m = (Module) bean; m.driveTransductionslnOrder(timestamp);  }  }  }  Figure 6.4. Transduction scheduling algorithm  6.4 Discussion of "Real-time" Users might run CNJ's real-time simulation to see the system's result and verify their designed models. A constraint net has one (global) or more (local) clocks with different frequencies (Hz). The clocks are distributed in different areas or modules. By setting a clock to an infinitely high frequency, the continuous time structure can be virtually realized. It also depends on the simulation speed that the system requires. In general, CNJ's real-time system is composed of a number of Java threads which execute concurrently, and compete or cooperate to fulfill the requirements placed  60  on the system. Because it runs on digital computers, it cannot be of absolutely real-time and have no time delay. If those threads' timing (completed before their deadlines) is correct, we can say that the real-time simulation is correct. There are four types of realtime systems [26]:  •  A hard real-time system where a missed deadline causes the failure of the system.  •  A firm real-time system where there is no associated value if finishing after the deadline, but the system can continue to run.  •  A soft real-time system where missed deadlines are not ideal, but can be tolerated.  •  An interactive system where there is just the "adequate response times".  We develop the transduction scheduling algorithm to schedule the transductions for execution. Since the algorithm produces the correct order that obeys the transductions' dependency relationship, the calculation result should be correct. In our environment where we have a Linux Redhat 7.3 box with a PHI 1G C P U and 256M R A M , the CNJ's simulation can run correctly in the fastest speed of 50 Hz if the C N model is not too big. Its performance heavily depends on the hardware speed and its specific operating system. Moreover, the correctness of the real-time system depends not only on the logical result of its computation, but also on the time at which the results are produced. CNJ simulation runs on Linux boxes. Unix supports a time-slicing (preemptive) multi-threaded system and it ensures that multiple threads of the same priority share C P U time. When running CNJ in Linux, there are a group of processes created for the threads to run. Also, the Linux scheduler latency affects any process's speed. If the scheduler latency is big, it is impossible for a real-time process to respond faster than the latency. Most Real Time Operating Systems (RTOS) have kernel code that is written to be preemptive. However, the Linux kernel is not a preemptive kernel where all interrupts are created equal [38]. This means that once the kernel has been entered from a system call, the current process cannot be unexpectedly changed.  61  Linux is not designed to be a RTOS. If users need a hard real-time system in the 10's of microseconds, a modified kernel such as RTLinux, or a dedicated RTOS, is probably more suitable than Linux as a solution.  6.5 Summary C N J simulation is realized by the means of Java event mechanism. C N clocks drive the transductions to compute results, and drive the data flow along the graph. To make sure a designed constraint net is well-formed, C N J calls the compilation module before starting the simulation. Also, the transduction scheduling algorithm is introduced to compute a proper order to drive transductions correctly. On the discussion of CNJ's realtime issue, the real-time simulation depends not only on the model's logical computation, but also on its running environment, which changes with time.  62  7=  :—  CHAPTER 7  --  •'•.,'  —r-r-—rr  ••  —  CONSTRAINT N E T M A R K U P L A N G U A G E  The Constraint Net Markup Language (CNML) serves as an interchange format for CNJ to store C N models. It is a preliminary proposal of an XML-based interchange format for constraint nets. This chapter presents, in the first version, the concepts and terminology of the C N M L , as well as its syntax, which is based on X M L . In the current version, constraint nets' general features are included in the C N M L . It also provides a starting point for the development of a standard format for Constraint Nets.  7.1 X M L X M L stands for Extensible Markup Language, which is a set of rules for defining semantic tags that break a document into parts and identify the different parts of the documents [27]. Different from H T M L or Tex, it is a meta-markup language, in which developers make up the tags they need as they go along. It means they do not have to wait for browser vendors to catch up with what they want to do. They can invent the tags when they need to. X M L describes a document's structure and meaning. It does not describe the formatting of the elements on the page. The document itself only contains tags that say what is in the document, not what the document looks like. Formatting can be added to a document with a style sheet. X M L documents are most commonly created with an editor. This may be a basic text editor that does not understand X M L at all, such as vi, emacs, or Notepad. Moreover, an X M L document does not absolutely have to be a file on some hard disk. It can be a record or a field in a database, or it may be a stream of bytes received from the network [27]. A n X M L parser reads the document and verifies whether it is well formed. If the document passes the tests, the parser converts the document into a tree of elements. Finally, the parser passes the tree to the end application. If this application is a web browser such as Mozilla, the browser formats the data and shows it to the user.  63  However, other programs may also receive the data. For instance, C N J might view the X M L as a constraint net that is composed of transductions, locations, and connections, then display it in front of users. X M L is extremely flexible, and can be used for many different purposes. Figure 7.1 shows its whole process.  T  XX  Editor  writes  file.xmJ ' " " "  Xerces  Document  is read by  Parser  sends data to  Browser  displays to  User  Figure 7.1. X M L document life cycle  Using X M L involves several related technologies and standards. These include the following:  •  H T M L for backward compatibility with popular browsers. It takes about two years from the initial release before most users have upgraded to a new browser version [27].  •  The CSS (Cascading Style Sheets) and X S L (Extensible Stylesheet Language) languages to define the appearance of X M L documents.  •  URLs (Uniform Resource Locators) and URIs (Uniform Resource Identifiers) to specify the locations of documents.  •  Xlinks to connect X M L documents to each other.  •  The Unicode character set to encode the text of X M L documents.  X M L brings a lot of advantages to program developers. It enables the design of field- specific markup languages. Individual professionals can develop their own markup languages. It is a self-describing and simple data format. It can be written in 100 percent pure ASCII text. In other formats (compressed data or serialized objects), the loss of a single byte can result in the entire file being unreadable. X M L is designed to be easy for  64  both human and programs to read and write. Moreover, since it is structured and integrated, X M L is ideal for large and complex documents.  7.2 CNML C N M L supports all constraint net models. Each C N node has a corresponding Element defined in C N M L . A file that satisfies the requirements of the interchange file format of C N M L is called a constraint net file. Each constraint net consists of locations, transductions, connections, and modules. It represents the graph structure of the constraint net. Conforming to X M L , in C N M L , a model and its constraint net nodes are represented by X M L elements [22] [27][35]. For convenience, the tags of C N M L elements are named after the constraint net terminology (e.g., <model>, <module>, <transduction>, <location>, <connection>, and <clock>). When a constraint net model is saved to a file, each node in the file is assigned a unique ID, which can be used to refer to the object. To give further meaning to a C N node, each node has a label. Typically, a label represents the name of an object, or the marking of a place. For instance, transductions, locations, and modules have labels. Each C N node includes some graphical information. For a transduction, location, connection, or module, its position information must be recorded. In addition, its specific geometry shape, size, background color, and foreground color are indispensable information. For a connection, the graphical information is the polyline's coordinates and its connected nodes' IDs. To represent the graphical information of a constraint net, C N M L uses the S V G (Scalable Graphics Vector) 1.0 specification [31]. S V G is a standard language developed by W3C for describing two-dimensional graphics in XML1.0. Moreover, in order to specify  a transduction's  function, C N M L  uses MathML (Mathematics Markup  Language) 2.0 specification [32]. C N M L leverages and integrates with other W3C specification and standards. By conforming to other specifications, C N M L becomes more powerful and makes it easier for users to transfer to other applications.  65  CNJ uses J D O M beta 7 [24] to deal with the C N M L files, to parse, to read or write, as well as export to or import from another file format, that is, H T M L , X H T M L and Simulink's M D L . In CNJ, the C N M L I O class is implemented to support the handling of C N M L files. The following a), b), and c) in Figure 7.2 are Elements of transduction, location, and connection, described by C N M L . Also, a complete constraint net for the Car Dynamics model in C N M L is presented in Appendix A . t r a n s d u c t i o n id = "0"> <graphics> <rect x = " " y = " " w i d t h = " " height = " fill = "color" s t r o k e = "color" /> </graphics> <label color = " b l u e " > +  "  </label> <function> <input n u m b e r = "2" /> <math> <apply> < p l u s /> <ci t y p e = " i n t e g e r " > input </ci> <ci t y p e = "integer"> input </ci> </apply> </math> </function> </transduction>  a) C N M L element for the "plus" transduction  l o c a t i o n id = "1"> <graphics> <ellipse cx = " " cy = " " rx = " " r y = " " fill'= "color" stroke = "color" /> " </graphics> <label color = "blue"> input x </label> <ci t y p e = "integer" /> </location>  b) C N M L element for a location 66  c o n n e c t i o n id = " 2 " > < p o l y l i n e points = " x1 ,y1 x 2 , y 2 x 3 , y 3 ..." /> < s o u r c e > id < / s o u r c e > <target> id </target> </connection>  c) C N M L element for a connection Figure 7.2. CNML Elements  7.3 Summary Constraint Net Markup Language (CNML) is defined for Constraint Nets for the first time. It works as an XML-based interchange format to support the storing of constraint nets and the representation of them. Its X M L compliant definition brings a lot of advantages to store constraint nets, and facilitates the development and sharing of constraint net models.  67  CHAPTER 8  A REALISTIC C N M O D E L  To test and demonstrate the performance of CNJ, we modeled a complete elevator system in Constraint Nets, and simulated its running behavior. The elevator system is a typical hybrid system that works as a  good example to demonstrate the power of  constraint nets. In this chapter, Section 8.1 introduces the elevator system and its designed model in a constraint net. Section 8.2 presents the constraint net model generated by CNJ for the elevator system. Section 8.3 briefly introduces the simulation and animation result of the modeled elevator system.  8.1 The Elevator System  Elevator systems are used in various communities as examples of methodologies for software engineering and real-time systems. A n elevator system is a typical hybrid dynamic system with continuous motion following Newtonian dynamics and discrete event control responding to users' request. In Zhang and Mackworth's paper [21], one nfloor elevator system is modeled using constraint nets, including the specification and verification for that C N model. Based on their model, a 3-floor elevator system is designed and simulated successfully in CNJ. The 3-floor elevator system is used in a three-floor building. Inside the elevator there is a board of buttons to indicate floor numbers ( i , 2, and 3 ). Outside the elevator s  there are two direction buttons (up, down) on each floor, except for the first and the third floor, where only one button is needed (see Figure 8.1). Any button can be pushed at any time. After being pushed, a floor button is on until the elevator reaches that floor, and a direction button is on until the elevator reaches that floor and is moving in the same direction. The elevator system is modeled in two levels using constraint nets. At the lower lever, the continuous dynamics is modeled. At the higher level, the abstraction of the  68  desired discrete system is modeled. Therefore, the model has a continuous elevator body and a discrete controller. Direction Buttons (outside elevator)  Floor Buttons (inside elevator)  Floor 3  Floor 2  Floor 1  Figure 8.1.  3-floor elevator system  The rest of this section describes the constraint net modules for the elevator system. The system was first introduced by Zhang and Mackworth in [21].  8.1.1 Top-level Hybrid Model The 3-floor elevator system is modeled as a hybrid constraint net model with its body running in a continuous time domain, and its controller running in a discrete time domain. The top-level model is shown in Figure 8.2 [21]. The E V E N T module implements the event logic that produces the events for triggering the discrete C O N T R O L 1 module. It realizes the or function of the following three events: 1) (s = idle ) A [J  ]s  (Ub (k) v Db (k) v Fb s(k)) . A user pushes a button at s  s  the elevator's idle state. 2) | d | <= £. The elevator comes to a home position. s  69  3)  (Com = 0) A —{Fbs(f) v (Ubs(f) A S = up) v (Dbs(f) AS = down)). A user request  has been served for a certain time. If it takes x seconds to serve a user, a delay of x will be waited for.  bi  BUTTON  ELEVATOR  Figure 8.2. A hybrid model of the Elevator system  E L E V A T O R is a continuous module where the elevator body is modeled by a second order differential equation following Newton's Second Law. It is depicted in Section 8.1.2. From Figure 8.2, we can see that the continuous part of E L E V A T O R is linked seamlessly together with the discrete part of CONTROL1 by the event-driven module of E V E N T . CONTROL1 is a discrete control module with the current floor number/and the current button states b (includes Ub , Db , Fb for Up buttons, Down buttons, and Floor s  s  s  s  number buttons) as inputs. The command Com, and serving state s, are its outputs. Its module composition is described in Section 8.1.3.  70  The B U T T O N module is discrete, consisting of an array of flip-flops to simulate pushing buttons. Interested readers might refer to [21] for more detail.  8.1.2 The Continuous E L E V A T O R Module  The continuous E L E V A T O R module is depicted in Figure 8.3 [21]. Com is a command from a higher level (CONTROL1), which can be 1,-1,0 representing up, down, and stop respectively. / is the current floor number. When the elevator body is within a small range of a floor, e/, is set to true, or else false.  CONTROL0  FLOOR  HOME  ELEVATOR  BODY  Figure 8.3. The continuous E L E V A T O R module  In the FLOOR module, given the separation of floors H , and the current elevator height h, the current floor number f can be obtained by the following: f=[h/H] + l  (1),  where [x] denotes the closest integer to x. In the H O M E module, the distance to the nearest floor is as follows: d = h-(f-l)H  (2),  s  and the home position eh is as follows:  71  e  h = (|dsl< )  (3)-  = £  Unlike the discrete controller of CONTROL1, CONTROLO is an analog controller that generates force to drive the elevator body. In our model, it is a linear proportional and derivative (PD) controller. The driving force F is computed by the following: F =i  Fo  if Com =1  (41  -Fo  if Com =-1  (5)  if Com = 0  (6)  Kpds - KAs  where d is the distance to the nearest floor, Fois a positive constant, K i s a proportional s  p  gain, and K is a derivative gain. The Fo, K , and K should satisfy the following v  p  v  conditions [21]: •  Continuous Stability. The continuous control is stable.  •  Hybrid Consistency. The interface to the discrete control is consistent.  To satisfy the conditions, Fo, K , and K have to be chosen based on the following p  v  equations: K + K >0, v  K >0 p  ( 7 ) >  Fo < min(K^4ed/3,a)  (8),  Kv'= Fo/(Ke)  (9),  K = K '-K  (10), and  K =K  (11),  v  p  v  2 v  /4  where F is the motor driving force, K is the fiction coefficient, a is the maximum 0  acceleration of the motor, and d is the maximum deceleration of the motor. For detailed deduction and calculation, readers may refer to the paper [21]. In the model of the elevator system, we set K = 1.0, a = d = 0.5, and e = 0.15, F  0  = 0.33, K = 1.2, andKp = 1.21 to satisfy the above equations. v  The elevator B O D Y module is modeled by a second order differential equation following Newton's Second Law, as follows: F-Kh  =h  (12)  Here we assume the mass of the body is 1, since it can be scaled by F and K. We also ignore gravity since it can be added to F to compensate for its effect.  72  8.1.3 The Discrete C O N T R O L l Module  CONTROL1 is a discrete controller. It receives buttons' state of Ubs, Dbs, Fbs, the current floor number / , and the current serving state s, and then determines the next motion Com, and the serving state s of the elevator. It is described in Figure 8.4 [21].  c-^ c '  . UpRequest  DownRequest  1,,  ,  StopRequest  1  -WSr  ServingState S(idle)  Command  CONTROLl  Figure 8.4. The discrete C O N T R O L l module We assume there are three kinds of serving states: up, down, and idle. In addition, we assume that the elevator is always parked (idle) at the first floor. The elevator moves persistently in one direction until there is no request in that direction. The complete logic functions of UpRequest, DownRequest, StopRequest, ServingState, and Command can be found in the paper [21].  8.2 Elevator System Modeled in CNJ  73  The 3-floor hybrid elevator system is also practically modeled and simulated in C N J . However, it is different from the one described in Section 8.1. The model in Section 8.1 is developed at a higher level than this one modeled in CNJ. As described in Chapter 4, C N J provides users with a set of elementary transductions for designing a constraint net, such as plus, minus, times, division, and so forth. Before starting to design the elevator system, we already modeled a few simple control systems for which those elementary transductions are sufficient. However, to model the much more complicated hybrid elevator system, the basic transduction set is not enough. Therefore, while modeling the elevator system, we wrote code to add new transductions and new supports to allow for elevator system modeling. In addition, some complex transductions have to be developed as modules, based on basic transductions. In other words, the implementation of C N J is driven by models' new requirements. For instance, to support the elevator system, we added the vector data type and modified some transductions to make them accept vector data input, added the ElementAt transduction to access a specific element from vectors, and added the isChanged transduction, as well as the wait transduction. The elevator system modeled in C N J is composed of three levels. There are in total, 17 modules, 169 transductions, 2 clocks, and hundreds of locations. The top-level model in CNJ is shown in Figure 8.5. The other module graphs are given in Appendix B, since they have similar designs to those depicted in Section 8.1.  8.3 Elevator System Simulation and Animation in CNJ The simulation of the modeled elevator system is able to run in two ways. First, users input data directly into locations Ubi, Dbi, and Fbi. They are boolean vectors of three elements with the initial value {false,false,false}. To simulate a button's pushing action (down-up), C N J requires users to restore the button's value to false after setting it to true. For instance, if the Down button on the third floor is pushed once, the Dbi[3] element should be first set to true, then set to false right away. This value change is considered as button pushing by CNJ. After the C N J simulation starts, the elevator's height value is continually displayed at the bottom StatusPane.  74  Figure 8.5. The Elevator system modeled in CNJ  Another way for the simulation is to utilize a two-dimensional animation window to display the simulation result. For the Elevator animation, we implemented a dedicated software package. It also works as a human-computer interface for interacting with the C N J simulation. From the animation window in Figure 8.6, we can see that the left three buttons are the floor buttons inside the Elevator; each floor has two direction buttons (Up and Down). The floor buttons and the direction buttons can be pushed by clicking the mouse on them. The animation window is running in a separate thread. Whenever a button is pushed, it is lighted as on, until the request is served. The states of buttons are transferred to the C N J simulation. Then the C N J simulation computes new results for every location while data is flowing along connections. For each clock tick, there is a newly computed value for the height of the elevator body. Meanwhile, the height of the elevator body is obtained by the animation thread in a specified frequency. Depending  75  on the animation thread's frame speed, the elevator body is shown and refreshed frequently (generally, 5Hz).  8.4 Summary The n-floor hybrid elevator system is modeled in constraint nets and works as a good example to demonstrate the performance of CNJ. It is a typical hybrid system with the elevator body as the continuous part and a discrete controller. The model designed by C N J is based on the one depicted in Section 8.1, but is at a lower level. During the process of modeling, the elevator system, new functions and features are added into the environment. Furthermore, C N J provides an animation package as a human computer interface to execute the simulation. It has successfully realized the modeling and simulation of the complex 3-floor hybrid elevator system, and works correctly.  76  —w  • X  Animation  Figure 8.6 The Elevator animation window  77  CHAPTER „  ,  i i ' , r  9  I^XPERIMENTAE R K S I I . I S firiiiiii.ii.ii.il  ...  r.,,.. ,,  r  ti i III  in'n^^^^^^^iSi^i^^^^^^^S^  9.1 Methodology Several experiments are carried out^on the CNJ environment to analyze its performance. There are four examples developed.' The first example is the simplest one, which has only one transduction (see Figure 9.1). The second one has two levels, and the lower level module is very simple (see Figure 9.2). The third one has dozens of nodes at one level (see Figure 9.3) [35]. It represents the dynamics of a car which is used as a radiocontrolled mobile base for a robot soccer player. The last one is the most complicated model (Hybrid Elevator Control System illustrated in Chapter 8), which has 17 modules distributed in three levels, with 169 transductions and 2 global clocks (see Figure 8.5 in Chapter 8). We generated different shapes and sizes of models in order to find CNJ's scalability. The shape and size of models can be defined by the parameters depth and width. Depth determines how many levels there are in the model. Width determines the number of nodes in each level. The above four examples have different shapes and sizes for conducting the experiments. The experiments run under the environment of Linux Redhat 7.1 with PHI 1 G Hz CPU, 256M S D R A M , and Java Hotspot™ Client V M (1.4.0, mixed mode). The code is programmed and compiled using J2SDK1.4.0. The performance of the CNJ simulation depends on the size of the model, clock frequency, and number of clocks in the model. Also it is dependent on its operating system's scheduling algorithm. These are called factors. C N J is able to run simulations in speed from an arbitrarily low frequency (e.g., 0.1 Hz), up to what your computer is capable of (e.g., 50 Hz in our environment).  78  9.2 Results  output  Qtep^  Figure 9.1. Example 1 (a simple adder)  79  Figure 9.3. Example 3 (the Car Dynamics)  Since there is only one global C N Clock in the models of Example 1, Example 2, and Example 3, we put them in one table (Table 9.1) for comparison. Depending on the Clock's specified frequency, the output values are computed, and flow out in different speeds. Average time cost per output (millisecond) Clock frequency (Hz) Example 1  Example 2  Example 3 (Car)  1  1010  1010  1010  10  110  110  110  20  60  60  60  50  20  20  20  100  20  20  20  1000  20  20  20  Table 9.1. Simulation results for Example 1, 2, 3  80  Chapter 8 described the hybrid 3-floor Elevator system modeled in CNJ.  The  Elevator model is used as Example 4, which has two abstract levels. One is the higherlevel discrete controlling part. The other is the lower-level elevator body, running in a continuous domain. To let the elevator body virtually run in a continuous time structure, we used a faster Clock to drive the E L E V A T O R and E V E N T modules, and a slower one to drive the discrete B U T T O N module. Assuming the slower clock is Clock 1, and the faster one Clock 2. Unlike other modules, the C O N T R O L l module is event-based. Whenever there is a state change outside, it is triggered to run once. In Table 9.2, we assigned to the two clocks a variety of frequencies to test how more than one clock affects the CNJ's performance. This time the output specifically refers to the elevator's height from its body to the ground. B O D Y is a continuous module driven by  Clock frequency (Hz)  Clock 2.  Average time cost per output of Height (millisecond)  Clock 1  Clock 2  Example 4 (The Elevator Control System)  1  10  110  1  20  60  1  50  20  10  10  110  10  20  60  10  50  25  20  20  60  20  50  30  50  50  40  Table 9.2. Simulation results for the Elevator system (Example 4)  From Table 9.1, we can see that the maximum speed that the simulation can run in our environment is 50 Hz. When the clock is set to 50, Hz, it fires clock events to its transductions to make them execute once per 20 ms (1000 / 50). However, when the  81  clock's frequency is greater than 50 Hz, the output cannot be computed in a time slot less than 20 ms. The reason is that the operating system's scheduler has its own predefined latency for scheduling the running processes. In Table 9.2, we find that if Clock 1 is not fast, the output speed is still dependent on Clock 2's frequency. However, when Clock l's frequency is high enough, it greatly slows down the output speed. For instance, compared with Table 9.1 (Clock = 50 Hz, output speed = 20 ms), when Clock 2 = 50 Hz and Clock 1 = 10 Hz, the output speed becomes 25 ms (slower than 20 ms). Another example is that when Clock 2 = 50 Hz, Clock 1 = 50 Hz, the speed = 40 ms, which is much slower than 20 ms, as in Table 9.1. Therefore, we can draw the conclusion that the number of clocks affects the simulation speed more than the size of a C N model. The larger scalability results from the Clock class using the Java Swing Timer class. In Java, the Swing Timer object automatically shares a thread to avoid spawning too many threads. It utilizes the same thread used to make cursors blink, tool tips appear, and so on. This method might lead to an event queue which may be too long for the C P U to process. To solve this problem, we need to implement a new Timer class which has its own dedicated thread. Through this means, different timers' clock events will be distributed in different threads, instead of one thread. Although it involves much more threads when running a CNJ simulation, a faster computer can easily solve this problem.  9.3 Summary In our environment, CNJ is able to run at the speed of 50 Hz, close to real-time. From the experiments, the number of clocks gives a larger scalability than the model's size. The calculation of transductions is also executed after the correct dependency order is obtained by the transduction scheduling algorithm. Although CNJ's GUI is implemented in Java Swing, the UI response lag is small enough that it cannot be detected by users. Also, the performance of C N J can be greatly improved if real-time operating systems and high-performance computers are adopted.  82  CHAPTER 10  CONCLUSIONS AND FUTURE W O R K  10.1 Conclusions C N J is a visual programming environment for hybrid dynamic system modeling and simulation with constraint nets. Component-based technology (JavaBeans) is deployed to design and implement such an environment. Using a visual programming tool, users can easily model control systems by assembling a number of C N nodes together without knowing any programming languages, such as C/C++ and Java. In addition, C N J is capable of developing programs with features of modularity, hierarchy, and reusability, saving designers a great deal of time and effort. It is useful for users to adopt the visual programming technique to model and simulate control systems. The environment is written in pure Java, and the user interface is implemented by Java Swing. However, it runs fast, and its response lag is too low to be detected by users. Based on Java's Event mechanism, C N J real-time simulation is built up successfully. Discrete, continuous, and event-based hybrid time structures are provided in CNJ. Also, the Transduction Scheduling Algorithm ensures that data flow satisfies the transductions' dependency relationship. Experimental results indicate that for clocks running at 50 Hz, the designed models can run close to real-time. This work demonstrates that Java language is useful for virtual real-time programming. Constraint Net Markup Language (CNML) is developed for the first time as an XML-based interchange format for storing constraint nets. It makes translation to and from other file formats feasible and convenient. C N J is the first practical specific environment to support constraint net modeling and simulation. We have modeled a variety of control systems successfully using CNJ. It works as proof of the feasibility of the efficient and useful implementation of the concept of Constraint Nets. The current version of C N J is definitely a prototype. In many ways, it is an experiment which uses component-based technology to build a visual programming environment. It is implemented in Java, and able to execute real-time simulations for 83  hybrid models. The tool can also work as a useful practical programming environment for constraint net users and learners.  10.2 Future Work The prototype of C N J could be improved in many aspects, and there might be opportunities for future work. Besides the constraint net modeling language, C N includes timed V-automata as the requirement specification language, and a verification method to verify whether a constraint net satisfies the requirements. Future work, therefore, includes the extension of the support for graphical requirement specification and verification tools. Until now, C N J provides a limited set of basic functions to define transductions. Sometimes, a complex model may require new functions that are not provided by the function set. In addition, developers have to read code and modify some methods in a few classes. We propose to provide a functionality which allows users to add new functions automatically. During our future work of designing more hybrid systems, new useful functions and reusable modules would then be incorporated. To improve real-time performance, much work needs to be done. This includes research on Real Time Specification Java (RTSJ 1.0 currently), adoption of real-time operating systems, real-time Java Virtual Machines [36], and better transduction scheduling algorithms. Regarding the detailed implementation of C N J , we hope to improve the compilation step to restrict users to design constraint nets with no syntax errors, and to generate better and clearer runtime error reports. The graphical drawing of connections and transductions needs to be refined. In particular, transduction components need explicit ports with them. We would like better ways to draw C N connections more efficiently and easily. Some operations would be helpful for future users, such as copy, paste, undo, redo, and export to I import from other file formats (HTML, Adobe Illustrator, Matlab M D L , ...). Also we hope to add additional support for storing each location's history traces in C N J simulations.  84  For Constraint Net Markup Language (CNML), a DTD (Data Type Definition) or X S D ( X M L Schema Definition) can be added to define the legal building blocks of C N M L files. We can also use X S L (extensible Stylesheet Language) to express C N M L files in different styles in web browsers. In this way CNJ could provide wider coverage and be more robust. Finally, there is an opportunity to design and simulate more challenging hybrid dynamic systems in constraint nets with CNJ.  85  BIBLIOGRAPHY  [I]  S. Chang, Principles of Visual Programming Systems. New York: Prentice Hall, 1990.  [2]  Brad A. Myers and Mary Beth Rosson, "Survey on User Interface Programming," presented at SIGCHJ'92: Human Factors in Computing Systems, 1992.  [3]  B . Sharhian and M . Hassul, Control System Design Using Matlab: Prentice-Hall Inc., 1993.  [4]  Y . Zhang and A. K . Mackworth, "Constraint Programming in Constraint Nets," presented at First Workshop on Principles and Practice of Constraint Programming, 1993.  [5]  John Lygeros, Datta N . Godbole, and Shankar S. Sastry, "Simulation as a Tool for Hybrid System Design," presented at Fifth IEEE conference on A l , Simulation and Planning in High-Autonomy Systems, 1994.  [6]  Y . Zhang and A. K . Mackworth, "Specification and Verification of ConstraintBased Dynamic Systems," in Principles and Practice of Constraint Programming, No. 874 in Lecture Notes in Computer Science, A. Borning, Ed.: Springer-Verlag, 1994, pp. 229-242.  [7]  Ying Zhang, "A Foundation for the Design and Analysis of Robotic Systems and Behaviors, Ph.D. thesis," in Department of Computer Science. Vancouver: University of British Columbia, 1994.  [8]  Margaret Burnett, "Scaling Up Visual Programming Languages," presented at IEEE Computer, 1995.  [9]  E. Jackson, ACE For Windows NT Prototype Design Document: International Submarine Engineering Ltd, 1995.  [10]  Y. Zhang and A. K . Mackworth, "Synthesis of Hybrid Constraint-Based Controllers," in Hybrid Systems II, Lecture Notes in Computer Science 999, W. K. P. Antaklis, A . Nerode, S. Sastry, Ed.: Springer Verlag, 1995, pp. 552-567.  [II]  R. Jagannathan, "Dataflow Models," in Parallel and Distributed Computer Handbook, A. Y. Zomaya, Ed.: McGraw-Hill, Inc., 1996.  86  [12]  Goddard Space Flight Center of N A S A , "User-Interface Guidelines," 1996.  [13]  Marat Boshernitsan and Michael Downes, "Visual Programming Languages: A Survey," University of California, Berkeley 1997.  [14]  Sun Microsystems, JavaBeans specification version 1.01, 1997.  [15]  Y.Fukazawa, "Cooperation Between Methodology and its Support Tools in Component-based Software Development," Waseda University Journal of Science and Engineering, vol. 1, 1997.  [16]  Hessam S. Sarjoughian and Bernard P. Zeigler, "DEVSJava: Basis for a D E V S based Collaborative M & S Environment," presented at INTERNATIONAL C O N F E R E N C E O N W E B - B A S E D M O D E L I N G & SIMULATION, 1998.  [17]  John A . Miller, Y . Ge, and J. Tao, "Component-Based Simulation Environments: JSFM As a Case Study Using Java Beans," presented at Winter Simulation Conference, 1998.  [18]  W i m Groenendaal, "Component Technology," in Xootic Magazine, 1999.  [19]  H . Praehofer, J. Sametinger, and A . Stritzinger, "Discrete Event Simulation using the JavaBeans Component Model," presented at International Conference On Web-Based Modelling & Simulation 1999, 1999.  [20]  M . Pidd, N . Oses, and R. J. Brooks, "Component-Based Simulation On The Web," presented at 1999 Winter Simulation Conference, 1999.  [21]  Y . Zhang and A . K . Mackworth, "Modeling and Analysis of Hybrid Systems: An Elevator Study," in Logical Foundation for Cognitive Agents, F. P. H . Levesque, Ed. Berlin: Springer, 1999, pp. 370-396.  [22]  M . Jungel, E. Kindeler, and M . Weber, "The Petri Net Markup Language," presented at Workshop Algorithm for Petri Net, 2000.  [23]  A . K . Mackworth, "Constraint-Based Agents: The ABC's of CBA's," presented at 6th Int. Conf. On Principles and Practice of Constraint Programming - CP2000, Singapore, 2000.  [24]  "JDOMBeta7,"2001.  [25]  A . K . Mackworth and Y . Zhang, "Constraint-Based Agents: A Formal Model for Agent Design," in UBC Computer Science Technical Report TR 2001-09, 2001.  [26]  Guillem Bernat and Alan Burns, "Weakly Hard Real-Time Systems," IEEE Transactions on Computers, vol. 50, 2001.  87  [27]  E.R. Harold, XML Bible 2nd edition: JDB Books, 2001.  [28]  K . Verschaeve, B. Wydaeghe, and F. Westerhuis, "Visual Composition with S D L Beans," presented at ECBS 2001, Washington, U S A , 2001.  [29]  Sun Microsystems, "Java Look and Feel Design Guidelines (2nd edition)," 2001.  [30]  Andy Quinn, "Trail: JavaBeans (TM)," 2001.  [31]  W3C, Scalable Vector Graphics (SVG) 1.0 Specification, 2001.  [32]  W3C, Mathematical Markup Language (MathML) Version 2.0, 2001.  [33]  Y. Wang and S. Ho., "Implementation of a DEVS-JavaBean Simulation Environment," presented at Advanced Simulation Technologies Conference, 2001.  [34]  "Petri Net Kernel," Research Group Petri Net Technology, 2002.  [35]  Fengguang Song and Alan K. Mackworth, "CNJ: A Visual Programming Environment for Constraint Nets," presented at A l , Simulation and Planning in High Autonomy Systems, Lisbon, Portugal, 2002.  [36]  M . Pfeffer, S. Uhrig, Th. Ungerer, and U . Brinkschulte, "A Real-Time Java System on a Multithreaded Java Microcontroller," presented at Fifth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing, 2002.  [37]  Sun Microsystems, "The Only Component Architecture for Java Technology," 2002.  [38]  Clark Williams, "Linux Scheduler Latency," Red Hat Inc., 2002.  88  APPENDIX A  C N M L F I L E FOR THE  C A R DYNAMICS M O D E L  <?xml v e r s i o n = " l . 0 " encoding="UTF-8"?> <cn_model id="cn"> <name>Car Dynamics</name> t r a n s d u c t i o n id="0"> <graphics> <rect x="150" y="326" width="90" height="40" f i l l = " - l " 16777216" /> </graphics> < l a b e l color="-1677 6961">tan</label> <function> <input number="l" /> <math> <apply> <tan /> <ci type="1">input</ci> </apply> </math> </function> </transduction> < t r a n s d u c t i o n id="l"> <graphics> <rect x="383" y="347" width="19" height="86" f i l l = " - l " 16777216" /> </graphics> < l a b e l color="-1677 6961">/</label> <function> <input number="2" /> <math> <apply> < d i v i d e /> <ci type="1">input</ci> <ci type="1">input</ci> </apply> </math> </function> </transduction> < t r a n s d u c t i o n id="2"> <graphics> <rect x="537" y="300" width="19" height="98" f i l l = " - l " 16777216" /> </graphics> < l a b e l color="-16776961">*</label> <function> <input number="2" /> <math> <apply> <times /> <ci type="l">input</ci> <ci type="l">input</ci> </apply> </math>  89  stroke="-  stroke="-  stroke="-  </function> </transduction < t r a n s d u c t i o n id="3"> <graphics> <rect x="739" y="373" width="22" height="78" f i l l = " - l " s t r o k e 16777216" /> </graphics> < l a b e l color="-1677 6961">+</label> <function> <input number="2" /> <math> <apply> <plus /> <ci type="1">input</ci> <ci type="1">input</ci> </apply> </math> </function> </transduction t r a n s d u c t i o n id="4"> <graphics> <rect x="152" y="185" width="90" height="40" f i l l = " - l " s t r o k e 16777216" /> </graphics> < l a b e l color="-16776961">sine</label> <function> <input number="l" /> <math> <apply> <sine /> <ci type="1">input</ci> </apply> </math> </function> </transduction t r a n s d u c t i o n id="5"> <graphics> <rect x="153" y="128" width="90" height="40" f i l l = " - l " s t r o k e 16777216" /> </graphics> < l a b e l color="-16776961">cosine</label> <function> <input number="l" /> <math> <apply> <cosine /> <ci type="l">input</ci> </apply> </math> </function> </transduction> t r a n s d u c t i o n id="6"> <graphics> <rect x="373" y="82" width="19" height="63" f i l l = " - l " stroke= 16777216" /> </graphics> < l a b e l color="-16776961">*</label> 90  <function> <input number="2" /> <math> <apply> <times /> <ci type="1">input</ci> <ci type="1">input</ci> </apply> </math> </function> </transduction> < t r a n s d u c t i o n id="7"> <graphics> <rect x="377" y="171" width="21" height="66" f i l l = " - l " s t r o k e 16777216" /> </graphics> < l a b e l color="-1677 6961">*</label> <function> <input number="2" /> <math> <apply> <times /> <ci type="l">input</ci> <ci type="l">input</ci> </apply> </math> </function> </transduction> < t r a n s d u c t i o n id="8"> <graphics> <rect x="667" y="15" width="15" height="63" f i l l = " - l " stroke= 16777216" /> </graphics> < l a b e l color="-16776961">+</label> <function> <input number="2" /> <math> <apply> <plus /> <ci type="l">input</ci> <ci type="l">input</ci> </apply> </math> </function> </transduction> < t r a n s d u c t i o n id="9"> <graphics> <rect x="674" y="134" width="13" height="66" 16777216" /> </graphics> < l a b e l color="-1677 6961">+</label> <function> <input number="2" /> <math> <apply> <plus /> <ci type="l">input</ci> 91  fill="-l"  stroke  <ci type="l">input</ci> </apply> </math> </function> </transduction t r a n s d u c t i o n id="10"> <graphics> <rect x="561"'y="84" width="20" height="56" f i l l = " - l " stroke= 16777216" /> </graphics> < l a b e l color="-16776961">*</label> <function> <input number="2" /> <math> <apply> <times /> <ci type="l">input</ci> .<ci type="l">input</ci> </apply> </math> </function> </transduction> <transduction id="ll"> <graphics> <rect x="561" y="174" width="20" height="55" f i l l = " - l " s t r o k e 16777216" /> </graphics> < l a b e l color="-1677 6961">*</label> <function> <input number="2" /> <math> <apply> t i m e s /> <ci type="1">input</ci> <ci type="1">input</ci> </apply> </math> </function> </transduction t r a n s d u c t i o n id="12"> <graphics> <rect x="690" y="327" width="21" height="48" 16777216" /> </graphics> < l a b e l color="-16776961">*</label> <function> < i n p u t number="2" /> <math> <apply> t i m e s /> <ci type="1">input</ci> <ci type="l">input</ci> </apply> </math> </function> </transduction < l o c a t i o n id="13">  92  fill="-l"  stroke  <graphics> < e l l i p s e cx="91" cy="343" rx="25" ry="25" f i l l = " - 3 3 5 5 3 9 3 " stroke="-16777216" /> </graphics> < l a b e l color="-1677 6961">alpha</label> <ci type="l" /> </location> < l o c a t i o n id="14"> <graphics> < e l l i p s e cx="311" cy="347" rx="25" ry="25" f i l l = " - l " s t r o k e 16777216" /> </graphics> < l a b e l color="-167 7 6961">loc</label> <ci type="l" /> </location> < l o c a t i o n id="15"> <graphics> < e l l i p s e cx="243" cy="431" rx="25" ry="25" f i l l = " - 6 6 8 4 9 2 8 " stroke="-16777216" /> </graphics> < l a b e l color="-16776961">length</label> <ci type="l" /> </location> < l o c a t i o n id="16"> <graphics> < e l l i p s e cx="476" cy="389" rx="25" ry="25" f i l l = " - l " s t r o k e 16777216" /> </graphics> < l a b e l color="-16776961">loc</label> <ci type="l" /> </location> < l o c a t i o n id="17"> <graphics> < e l l i p s e cx="90" cy="272" rx="25" ry="25" f i l l = " - 3 3 5 5 3 9 3 " stroke="-16777216" /> </graphics> < l a b e l color="-16776961">V</label> <ci type="l" /> </location> < l o c a t i o n id="18"> <graphics> < e l l i p s e cx="631" cy="350" rx="33" ry="23" f i l l = " - l " s t r o k e 16777216" /> </graphics> < l a b e l color="-1677 6961">delta-theta</label> <ci t y p e = " l " /> </location> < l o c a t i o n id="19"> <graphics> < e l l i p s e cx="851" cy="407" rx="23" ry="20" f i l l = " - 2 6 3 6 8 " stroke="-16777216" /> </graphics> < l a b e l color="-16776961">theta</label> <ci type="l" /> </location> < l o c a t i o n id="2 0"> <graphics> 93  < e l l i p s e cx="314" cy="205" rx="25" ry="25" f i l l = " - l " stroke="16777216" /> </graphics> < l a b e l color="-1677 6961">loc</label> <ci type="l" /> </location> < l o c a t i o n id="21"> <graphics> < e l l i p s e cx="315" cy="149" rx="25" ry="25" f i l l = " - l " stroke="16777216" /> </graphics> < l a b e l color="-1677 6961">loc</label> <ci type="l" /> </location> < l o c a t i o n id="22"> <graphics> < e l l i p s e cx="501" cy="113" rx="25" ry="25" f i l l = " - l " stroke="16777216" /> </graphics> < l a b e l color="-16776961">delta-x</label> <ci type="l" /> </location> < l o c a t i o n id="23"> <graphics> < e l l i p s e cx="503" cy="204" rx="25" ry="25" f i l l = " - l " s t r o k e = " 16777216" /> </graphics> < l a b e l color="-16776961">delta-y</label> <ci type="l" /> </location> < l o c a t i o n id="24"> <graphics> < e l l i p s e cx="753 " cy="50" rx="25" ry="25" f i l l = " - 2 6 3 6 8 " s t r o k e 16777216" /> </graphics> <label color="-16776961">output</label> <ci t y p e = " l " /> </location> < l o c a t i o n id="25"> <graphics> < e l l i p s e cx="759" cy="168" rx="21" ry="22" f i l l = " - 2 6 3 6 8 " stroke="-16777216" /> </graphics> < l a b e l color="-1677 6961">y</label> <ci type="l" /> </location> < l o c a t i o n id="26"> <graphics> < e l l i p s e cx="481" cy="470" rx="35" ry="17" f i l l = " - 1 0 0 2 7 2 1 3 " stroke="-16777216" /> </graphics> < l a b e l color="-16776961">clock c y c l e < / l a b e l > <ci type="l" /> </location> < l o c a t i o n id="27"> <graphics>  94  < e l l i p s e cx="624" cy="93" rx="13" ry="12" f i l l = " - l " stroke=" 16777216" /> </graphics> < l a b e l color="-16776961">loc</label> <ci t y p e = " l " /> </location> < l o c a t i o n id="28"> <graphics> < e l l i p s e cx="625" cy="201" rx="13" r y = " l l " f i l l = " - l " stroke= 16777216" /> </graphics> < l a b e l color="-167769 61">loc</label> <ci type="l" /> </location> < l o c a t i o n id="29"> <graphics> < e l l i p s e cx="684" cy="397" rx="15" ry="12" f i l l = " - l " stroke= 16777216" /> </graphics> < l a b e l color="-1677 6961">loc</label> <ci type="l" /> </location> <clock id="30"> <graphics> <rect x="178" y="489" width="32" height="32" f i l l = " - 1 6 7 1 1 9 3 6 stroke="-65536" /> </graphics> <delay>1000</delay> </clock> <connection id="31"> < p o l y l i n e points="91,343 195,346" /> <source>13</source> <target>0</target> </connection> <connection id="32"> < p o l y l i n e points="195,346 311,347" /> <source>0</source> <target>14</target> </connection> <connection id="33"> < p o l y l i n e points="311,347 353,347 353,381 392,390" /> <source>14</source> <target>l</target> </connection> <connection id="34"> < p o l y l i n e points="243,431 352,430 352,397 392,390" /> <source>15</source> <target>l</target> </connection> <connection id="35"> < p o l y l i n e points="392 , 390 476,389" /> <source>l</source> <target>16</target> </connection> <connection id="36"> < p o l y l i n e points="90,272 494,272 494,335 546,349" /> <source>17</source> 95  <target>2</target> </connection> <connection id="37"> < p o l y l i n e points="476,389 <source>16</source> <target>2</target> </connection> <connection id="38"> < p o l y l i n e points="546,349 <source>2</source> <target>18</target> </connection <connection id="39"> < p o l y l i n e points="194,505 <source>3 0</source> <target>0</target> </connection> <connection id="40"> < p o l y l i n e points="194,505 <source>3 0</source> <target>l</target> </connection> <connection id="41"> < p o l y l i n e points="194,505 <source>3 0</source> <target>2</target> </connection> <connection id="42"> < p o l y l i n e points="750,412 <source>3</source> <target>19</target> </connection> <connection id="43"> < p o l y l i n e points="194,505 <source>3 0</source> <target>3</target> < /connection <connection id="44"> < p o l y l i n e points="851,407  516,389  516,356  631,350"  />  195,346"  />  546,349"  392,505 392,390"  />  546,505  />  851,407"  546,349"  />  />  194,538 750,538 750,412"  />  849,265 849,245 109,245 109,146  198,148"  />  <source>19</source> <target>5</target> </connection> <connection id="45"> < p o l y l i n e points="851,407 849,235 130,235 <source>19</source> <target>4</target> </connect i o n <connection id="46"> < p o l y l i n e points="198,148 315,149" /> <source>5</source> <target>21</target> </connection> <connection id="47"> < p o l y l i n e points="197,205 314,205" /> < source>4</source> <target>2 0</target> 96  130,204 197,205"  />  </connection> <connection id="48"> •cpolyline points="90,272 90,86 358,86 358,101 382,113" /> <source>17</source> <target>6</target> </connection> <connection id="49"> < p o l y l i n e points="315,149 315,113 382,113" /> <source>21</source> •<target>6</target> </connection> <connection id="50"> < p o l y l i n e points="90,272 90,103 342,103 342,179 358,179 358,190 387,204" /> <source>17</source> <target>7</target> </connection> <connection id="51"> < p o l y l i n e points="314,205 387,204" /> <source>20</source> <target>7</target> </connection> <connection id="52"> < p o l y l i n e points="382,113 501,113" /> <source>6</source> <target>22</target> </connection> <connection id="53"> < p o l y l i n e points="387,204 503,204" /> <source>7</source> <target>23</target> </connection> <connection id="54"> < p o l y l i n e points="194,505 120,505 120,183 204,183 198,148" /> <source>30</.source> <target>5</target> </cohnection> <connection id="55"> < p o l y l i n e points="194,505 138,505 138,295 193,295 197,205" /> <source>3 0</source> <target>4</target> </connection> <connection id="56"> < p o l y l i n e points="194,505 425,505 425,157 381,157 382,113" /> <source>3 0</source> <target>6</target> </connection> <connection id="57"> < p o l y l i n e points="194,505 413,505 413,299 387,299 387,204" /> <source>3 0</source> <target>7</target> </connection> <connection id="58"> < p o l y l i n e points="674,46 753,50" /> <source>8</source> <target>24</target> </connection> 97  <connection id="59"> < p o l y l i n e points="194,505 210,511 734,511 734,97 670,97 674,46" /> <source>30</source> <target>8</target> </connection <connection id="60"> < p o l y l i n e points="194,505 721,505 721,220 677,220 680,167" /> <source>30</source> <target>9</target> </connection> <connection id="61"> < p o l y l i n e points="753,50 801,47 801,7 608,7 608,46 674,46" /> <source>24</source> <target>8</target> </connection> <connection id="62"> < p o l y l i n e points="759,168 808,173 808,120 609,120 609,166 680,167" <source>2 5</source> <target>9</target> </connection> <connection id="63"> < p o l y l i n e points="680,167 <source>9</source> <target>25</target> </connection> <connection id="64"> < p o l y l i n e points="851,407 <source>19</source> <target>3</target> </connection> <connection id="65"> < p o l y l i n e points="501,113 <source>22</source> <target>10</target> </connection> <connection id="66"> < p o l y l i n e points="503,204 <source>2 3</source> <target>ll</target> </connection> <connection id="67"> < p o l y l i n e points="631,350 <source>18</source> <target>12</target> </connection> <connection id="68"> < p o l y l i n e points="481,470  759,168"  849,466  />  631,466  571,112"  />  571,201"  />  700,351"  />  631,411 750,412"  />  601,470 601,385  671,385  671,356  <source>2 6</source> <target>12</target> </connection> <connection id="69"> < p o l y l i n e points="481,470 575,470 575,255  539,255  539,122 571,112"  <source>2 6</source> <target>10</target> 98  700,351"  </connection> <connection id="70"> < p o l y l i n e points="481,470 565,470 565,280 546,280 546,213 571,201 />  <source>2 6</source> <target>ll</target> </connection> <connection id="71"> < p o l y l i n e points="571,112 592,112 592,92 624,93" /> <source>10</source> <target>27</target> </connection> <connection id="72"> < p o l y l i n e points="624,93 642,93 642,51 674,46" /> <source>27</source> <target>8</target> </connection> <connection id="73"> < p o l y l i n e points="571,201 625,201" /> <source>ll</source> <target>28</target> </connection> <connection id="74"> < p o l y l i n e points="625,201 648,201 648,174 680,167" /> <source>2 8</source> <target>9</target> </connection> <connection id="75"> < p o l y l i n e points="700,351 724,351 724,378 611,378 611,396 684,397 />  <source>12</source> <target>2 9</target> </connection> <connection id="76"> < p o l y l i n e points="684,397 <source>29</source> <target>3</target> </connection> <connection id="77"> < p o l y l i n e points="194,505 <source>3 0</source> <target>10</target> </connection> <connection id="78"> < p o l y l i n e points="194,505 <source>3 0</source> <target>ll</target> </connection> <connection id="79"> < p o l y l i n e points="194,505 <source>3 0</source> <target>12</target> </connection> </cn_model>  724,397 750,412" />  589,505 589,154 571,154 571,112" />  588,505 588,250 571,250 571,201" />  704,505 704,402 703,390 700,351" />  99  APPENDIX B  T H E E L E V A T O R S Y S T E M M O D E L E D IN C N J  This appendix contains the complete graphical modules for the 3-floor Elevator control system modeled by CNJ. The top level is shown in Figure 8.5.  r FllpFlop  Figure B-L BUTTON Module  Figure B-2.  FlipFlop Module  100  Fugure B-3. ResetSignal Module  Figure B-4. EVENT Module 101  Figure B-6. UpRequest Module 102  Figure B-7. DownRequest Module  -Q-  elementAt r * ^ | g elemenlAt h»-» IhCTV  •j IT... then... else. . . | — - M j o c > -  Lj-j elernentAl |-»-<Jbg>- * j elemernAi~K^bQ> - H elemeni^~|-*-^£gi-H  elemeniA~K-^b(j>[j-| 1 elernentAl  41... then. ..else  if...then... else...  •~*Hloy  H elernentAl h — f b g ) — r  - 0  Figure B-8. StopRequest Module  103  Figure B-10. Command Module 104  Figure B - l l . E L E V A T O R Module  Figure B-12. C O N T R O L O Module 105  106  


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items