Multi-User Groups for Conceptual Understanding and Prototyping (MUG)

Yuri Shapirstein, Cheryl V. Foster, Chris Cera, Lisa Rocci
http://edge.mcs.drexel.edu/MUG/reqdoc/reqdoc.html
Drexel University
May 29, 2001
Version 2.0

 

 

 

 

Contents

  1. Preface
  2. Introduction
  3. Glossary
  4. User Requirements Definition
    1. User Functional Requirements
    2. User Non-Functional Requirements
      1. User Product Requirements
        1. User Usability Requirements
        2. User Reliability Requirements
        3. User Portability Requirements
        4. User Efficiency Requirements
          1. User Performance Requirements
          2. User Space Requirements
          3. User Speed Requirements
        1. User Delivery Requirements
        2. User Implementation Requirements
        3. User Standards Requirements
      2. User External Requirements
      3. User Legislative Requirements
        1. User Privacy Requirements
  5. System Architecture
  6. System Requirements
    1. System Functional Requirements
      Section 1. Adding objects
      Section 2. Linking and Groups
      Section 3. User Modes
      Section 4. Views
      Section 5. File Operations
      Section 6. Annotations
      Section 7. Object Transformations
      Section 8. Free-Form Objects
      Section 9. Color Chooser
    2. System Non-Functional Requirements
      1. System Product Requirements
        1. System Usability Requirements
        2. System Reliability Requirements
        3. System Portability Requirements
        4. System Efficiency Requirements
          1. System Performance Requirements
          2. System Space Requirements
          3. System Speed Requirements
      2. System Organizational Requirements
        1. System Delivery Requirements
        2. System Implementation Requirements
        3. System Standards Requirements
      3. System External Requirements
      4. System Legislative Requirements
        1. System Privacy Requirements
  7. Domain Requirements
  8. System Models
  9. System Evolution
  10. Appendix A: Internet Resources
  11. Appendix B: NURBS
  12. Appendix C: Markup Language Discussion

  1. Preface

    2.

    This document is intended to describe in detail the requirements and functionality of the MUG, a collaborative, conceptual design application for the users and system developers of the application. This is the first published version of this document.

  2. Introduction

    3.

    The goal of the the MUG project is to implement a stand-alone system that supports the conceptual design phase of building mechatronic artifacts within a collaborative environment. For this phase of the project we are focusing on integrating the features of the last version of MUG with the major features of CUP version 2 along with making general system improvements and adding new features.

    Application History

    MUG 2.0 is the 4th version of a conceptual design application developed by GICL called Conceptual Understanding and Prototyping (CUP). CUPs purpose was to allow a designer to perform a conceptual or "back of the envelope" sketch of an electro-mechanical design. The original version was developed by Santiago Lombeyda in 1998 using Java 1.6, Netscape's VRML plug-in and CosmoPlayer v2.1 as their platforms. To increase usability and functionality, version 2 was developed by Lisa P. Anthony and Jon E. John in 1999, and implemented using Java and Java3D. Version 2 incorporated xml file format, vrml importation, and an annotation tool based on the NIST S-B-F model of a mechatronic assembly with the original capabilities of the application. In 2000, the evolution of CUP continued with version 1 of MUG, which added multi-user capabilities, free-form objects, a new GUI and underlying core architecture, but left out some key functionality that was present in the last version of CUP.

    Conceptual Design

    Conceptual design is the initial stage of the design and development of most mechanical objects. In this stage, the designer traditionally sketches out the basic definitions of an object without going into details, leaving them for the later stages. The designer does this by analysing the requirements, generating ideas and solutions and then sketching them out. Our goal is to provide a system which will support this work in a collaborative environment, allowing multiple designers working on a particular design to work together over a network or the Internet.

    Project Goals

    System Improvements. To incorporate the new features and improvements to the system, changes will be made to the core architecture of MUG and a new GUI will be designed and implemented. Object rotation will be improved, along with the creation and manipulation of free-form objects.

    New Features. In the development of MUG, the developers focused primarily on designing the core architecture, the new gui, and the multi-user functionality that was to be the main difference between MUG and CUP. All other functionality was put aside as features that could be "plugged-in" later. Features that existed in CUP,such as the S-B-F annotation tool and xml file exportation, are going to be reimplemented as parts of the new version of the application. Also new to MUG will be the ability to see multiple views of a design at the same time.

  3. Glossary

    4.
    API
    Application Programmers Interface: a set of routines, protocols, and tools for building software applications. A good API makes it easier to develop a program by providing all the building blocks. A programmer puts the blocks together.
    basis function
    The elements of the functions that form linear spaces.
    CAD
    Computer Aided Design: CAD systems allow an engineer to view a design from any angle with the push of a button and to zoom in or out for close-ups and long-distance views. In addition, the computer keeps track of design dependencies so that when the engineer changes one value, all other values that depend on it are automatically changed accordingly.
    Canvas3D
    Java3D object used for on-screen or off-screen rendering of 3D objects.
    CSCW
    Computer Supported Collaborative Work
    control point
    A point in three-space which is part of the definition of a NURBS object. Associated with a weight, changing a control point position or weight modifies the shape of the NURBS object.
    CUP
    Conceptual Understanding and Prototyping: an application developed by GICL. MUG is the fourth version of this application. Go to the CUP web page at CUP/cup.html">http://edge.mcs.drexel.edu/CUP/cup.html
    flow
    These correspond to the inputs and outputs to functions. The main categories of flows are material, energy, and signal flows. In reality, a flow can neither appear from nothing, nor vanish into nothing either. (ex. direct current, translational motion, rotational motion, etc.).
    function
    an action that is characterized by its operations on its input(s), and the corresponding output(s) from that operation. It is a relation between the input and output of energy, material, and other information. Most functions are composite, and consist of multiple subfunctions, rather than atomic. (ex. convert)
    GICL
    GICL is the Geometric and Intelligent Computing Laboratory at Drexel University. http://gicl.mcs.drexel.edu
    granularity
    The number of points defined in each direction of a given free-form object.
    GUI
    Graphical User Interface: a program interface that takes advantage of the computer's graphics capabilities to make the program easier to use. Well-designed graphical user interfaces can free the user from learning complex command languages.
    host
    the physical machine on which the MUG software will be run.
    Java
    a programming language written for the JVM.
    Java3D
    an API which focuses primarily on transformations involving three-dimensional objects.
    JavaDoc
    an automatic source code documentation system that generates HTML pages which display the content of the source code.
    JavaSpace
    simple unified mechanism for dynamic communication, coordination, and sharing of objects between Java technology based network resources like clients and servers.
    JINI
    a distributed architecture for JVM.
    JRE
    The Java Runtime Environment is the platform which is created on the host platform. This is the main component of the virtual machine.
    JVM
    an abstract computing machine, or virtual machine, JVM is a platform-independent programming language that converts Java bytecode into machine language and executes it. Most programming languages compile source code directly into machine code that is designed to run on a specific microprocessor architecture or operating system, such as Windows or UNIX. A JVM -- a machine within a machine -- mimics a real Java processor, enabling Java bytecode to be executed as actions or operating system calls on any processor regardless of the operating system. For example, establishing a socket connection from a workstation to a remote machine involves an operating system call. Since different operating systems handle sockets in different ways, the JVM translates the programming code so that the two machines that may be on different platforms are able to connect.
    knot
    The points that define the partion of the over which a NURBS curve is defined.
    KQML
    Knowledge Query and Manipulation Language: a language and protocol for exchanging information and knowledge.
    mechatronic
    electro-mechanical systems - some examples are automatic cameras, miniature disk drives, missle seekers, and consumer products like CD players, camcorders, and VCRs.
    metadata
    Data about data. Metadata describes how and when and by whom a particular set of data was collected, and how the data is formatted. Metadata is essential for understanding information stored in data warehouses.
    MUG
    Multi-User Groups for Conceptual Understanding and Prototyping
    NURBS
    Non-Uniform Rational B-Splines: a mathematical representation of a three-dimensional object which can be used to represent analytic shapes, such as cones, as well as free-form shapes, such as car bodies.
    PDM
    Product Data Management
    Plug-in
    a hardware or software module that adds a specific feature or service to a larger system.
    RAM
    Random Access Memory: a type of computer memory that can be accessed randomly; that is, any byte of memory can be accessed without touching the preceding bytes. RAM is the most common type of memory found in computers and other devices, such as printers.
    real-time
    Refers to events simulated by a computer at the same speed that they would occur in real life. In graphics animation, for example, a real-time program would display objects moving across the screen at the same speed that they would actually move
    S-B-F
    Structure Behavior Function: most important information in a conceptual plan for an assembly which describes the relationships among the parts and how they work together.
    SGML
    Standard Generalized Markup Language, an international standard for the definition of device-independent, system-independent methods of representing texts in electronic form.
    VRML
    Virtual Reality Markup Language: a specification for displaying three-dimensional objects on the World Wide Web. You can think of it as the 3-D equivalent of HTML. Files written in VRML have a.wrl extension (short for world). To view these files, you need a VRML browser or a VRML plug-in to a Web browser.
    W3C
    World Wide Web Consortium: an international consortium of companies involved with the Internet and the Web. The W3C was founded in 1994 by Tim Berners-Lee, the original architect of the World Wide Web. The organization's purpose is to develop open standards so that the Web evolves in a single direction rather than being splintered among competing factions. The W3C is the chief standards body for HTTP and HTML.
    XML
    eXtensible Markup Language: specification developed by the W3C. XML is a pared-down version of SGML, designed especially for Web documents. It allows designers to create their own customized tags, enabling the definition, transmission, validation, and interpretation of data between applications and between organizations.

  4. User Requirements

    5.

    1. User Functional Requirements

      2.
      1. To add objects to a design, select the Add option from the menu. The user may select from a default set of objects or a set of plug-in curves and surfaces.
      2. To create a link between two or more objects in a design, select the objects using the mouse and select the link option from the menu.
      3. The user may elect to operate in single-user mode (in which only one user may view and make changes to the design) or in multi-user mode (which allows for design collaboration).
      4. The user may choose to view the design from two or more different view points. There is a menu option for this choice.
      5. The user may open existing designs by selecting Open from the File menu.
      6. The user may save his/her design by selecting Save As or Save from the File menu. Saving a design allows the user to also save annotations and a history tree associated with the design.
      7. The user may elect to annotate his/her design. Annotation includes definitions of the function of an object in a design, the function of a link between objects, the flow of a link between objects, and a description of an object or a link.
      8. To move an object, click and drag with the mouse.
      9. To rotate an object, change the rotation tabs in the right hand side panel.
      10. To change the size of an object, change the scale tabs in the right hand side panel.
      11. To group objects and/or links together, select the objects and choose Group from the menu.
      12. Each user will have access to menus, short-cut keys and seperate panels for use in design modification.
      13. The user can add and modify free-form objects to the design. These objects can be modified in a variety of ways using control points. The granularity of the object may also be altered.
      14. The user can change the color of objects by selecting a color from the default color set or from the color wheel.

    2. User Non-Functional Requirements

      3.

      1. User Product Requirements

        2.

        1. User Usability Requirements

          2.
          • MUG utilizes a graphical user interface similar to that of many popular CAD/CAM software packages. Prior knowledge of CAD/CAM software is recommended and will ease the learning curve involved in using MUG.
          • MUG supports many of the same basic operations and queries that are commonly found in other CAD/CAM software packages. MUG should look and feel similar to other CAD/CAM packages.
          • No more than four hours should be required to learn MUG. Previous experience of at least one year with another CAD package will make it easier to learn MUG.
          • Plug-in authors and power users will have access to MUG's API via the JavaDoc documentation system.
          • A "Help" button is available on the MUG toolbar.

        2. User Reliability Requirements

          3.
          • MUG is fault-tolerant and will maintain data integrity throughout operation.
          • Should MUG involuntarily halt, this will not result in loss of currently active models.
          • Importing and exporting in MUG will not corrupt or degrade models during use.

        3. User Portability Requirements

          4.
          • MUG shall be able to function regardless of the quality of hardware on the host machine.
          • MUG shall be able to function regardless of the operating systems software that may be running on the host machine.
          • MUG shall be able to function regardless of other external software running on the host machine.

        4. User Efficiency Requirements

          5.
          Hardware/Software Minimum Recommended
          CPU Requirements Intel Pentium II 350MHZ Intel Pentium III 450MHZ
          RAM Requirements 128MB 256MB
          Disk Requirements 4.5MB 8MB (with documentation)
          Video Card OpenGL support video, w/32MB of video RAM OpenGL support video w/3D acceleration, w/64MB of video RAM

          1. User Performance Requirements

            2.
            • The following host-dependent system requirements must be met:
              • Any combination of computer hardware capable of running a JVM, and other external Java packages upon which MUG is dependent.
              • Any operating system capable of running the JVM, and other external Java packages upon which MUG is dependent.
            • MUG is desgined such that software muti-tasking may take place, allowing for optimal use of a designer or engineer's time. MUG will not consume the entirety of the host computer's resources.

          2. User Space Requirements

            3.

            See the table above.

      2. User External Requirements

        3.

        Mug is backward compatible. Designs created in one version of MUG can be opened and altered in earlier versions.

      3. User Legislative Requirements

        4. The user must give proper acknowledgements to all direct or indirect contributors, including corporations, individuals, etc., who are responsible for software upon which MUG is built.

        When dealing with proprietary models it must be guaranteed, by law in some cases, that the intellectual property of those models can not be compromised. A strong, well-defined encryption algorithm may be required in order to host these models.

        1. User Privacy Requirements

          2.
          • The user must provide a username and password to access the network area on which MUG is located.
          • Encryption of data is recommended for network use of MUG, in both single-user and multi-user modes.
          • The user shall be able to confidently perform transactions without the threat of a malicious user trying to intercept his/her data.

  5. System Architecture

    6.

    MUG can be broken down into the following distinct system components:

    1. Mug Core Architecture

      MUG Core consists of the following parts:
      Mouse Controller, Reprogrammable Keyboard Controller, Undo/Redo Manager, Scene Manager, Behavior Manager, Object Hierarchy, Transform Hierarchy.

      Mouse Controller works closely with the swing event model. It grabs mouse events that are applied to the Canvas3D, and extends them to describe the information related to the 3D scene.

      Keyboard Controller (aka KeyChooser) traps all of the keyboard actions related to the MUG application and searches the shortcut tree to figure out whether any action is related to a particular sequence of key strokes.

      Undo/Redo Manager is one of the most important parts of the application. It stores all of the states that current design went through (i.e. the designer can go back as many steps as needed and walk down a different branch if desired).

      Scene Manager is responsible for keeping track of all of the objects located in the scene, whether those are related to the design, user-defined cameras, lights, or any other helper object that may find its way into MUG.

      Behavior Manager keeps track of which objects are being changed in real time (i.e. with the mouse), and records the changes with Undo/Redo Manager once they are complete.

      Object Hierarchy is designed to simplify extention of MUG and creation of plugins.

      Transforms Hierarchy is a set of objects that describe changes to the scene.

    2. Distributed Architecture:

      Consists of three Modules:

      1. MUG-Server: is a central tower which maintains all user logins/outs. It is also responsible for starting and stoping MUG-Agents when a valid request is made.
      2. MUG-Agent: Currently located in the same JRE as the MUG-Server and is responsible for an ongoing design session. It keeps track of all of the changes done to the design.
      3. MUG-Client (aka MUG): User interface to the MUG-Agent and MUG-Server; also works in a single-user mode.

      Uses KQML-like message architecture to relay information between all three parts of the distributed system.

    3. Plugin Architecture

      Provides a set of methods for creating plugins for MUG. Currently, only two types of plugins are available: import plugins and object plugins. These are facilitated by the Interface construct that Java provides to ensure that all plugin's adhere to the appropriate constraints, and assignments.

      The purpose of the import plugin is so that a MUG can handle new input formats for representing models. These formats can be easily added and removed depending upon the implementation, host operating system, license restrictions on usage, etc. The currently implemented plugins are for VRML, and XML.

      The purpose of the object plugin is so that MUG can use different geometric objects. All of the objects currently supported have been implemented via this plugin architecture. This makes adding and removing geometrical objects very simple, and less hard-coding of these structures makes for a better design.

  6. System Requirements

    7.

    1. System Functional Requirements

      2.

      Section 1. Adding objects

      1.1 Provide default object to be added

      1.2 Accept new object types in the form of a "plug-in"

      1.3 Additional objects to be provided

      Section 2. Linking and Groups

      2.1 Enable the user to establish links between objects

      2.2 Enable the user to establish links between groups of objects

      2.3 Enable the user to define a group of objects (including links)

      Section 3. User Modes

      3.1 Two modes of use will be provided, single-user and multi-user

      3.2 A user will be able to participate in only one design session at a given time in either mode

      Section 4. Views

      4.1 Four different views of the current design session will be provided concurrently in separate windows.

      Section 5. File Operations

      5.1 User will have the ability to create a new design

      5.2 User will have the ability to open existing design files

      5.3 User will have the ability to save designs.

      Section 6. Annotations

      Based on the NIST S-B-F model, the user will be able to define a semantic description of the design. The intended purpose is to represent function and flow of a conceptual model, and be able to import and export these properties using a metadata described in a markup language. A thorough description of metadata and markup languages used in MUG is given in Appendix C. Function, and its corresponding flows for every instance of a model, are used to describe the behavior of a design in terms of input and output of energy, material, and other information.

      6.1 Function of a link or object within a design

      6.2 Flow of a link between objects

      6.3 Give a description of a link or object

      Section 7. Object Transformations

      7.1 Translation - objects will be able to change position in all directions within a scene.

      7.2 Rotation - objects will be able change the orientation of an object in the world.

      7.3 Scaling - the scale of the objects will be able to change.

      7.4 The user will be able to limit the in which planes the transformations will take place.

      7.5 Modification will be done through the a combination of keystrokes, mouse movement, and menu selection.

      Section 8. Free-Form Objects

      8.1 Curves

      8.2 Surfaces

      8.3 Control Points

      8.3 User will be able to adjust the rendering granularity of a free-form object, adjusting the recomputation and drawing time when the user modifies an object.

      Section 9. Color Chooser

      The color chooser will allow the user to alter the default color of a object within a design.

      9.1 Color Selection

    2. System Non-Functional Requirements

      3.

      1. System Product Requirements

        2.

        1. System Usability Requirements

          2.
          • The system shall provide a simple graphical interface that is commonly found in many competing products of this nature. Prior knowledge of existing CAD/CAM software will greatly reduce this learning curve.
          • The system shall support many of the same basic operations and queries that are commonly found in other CAD/CAM software packages. This will give the system a familiar look and feel and increase its usability.
          • The mean training time for the typical designer with at least one year of prior experience with another CAD package should take no more than four hours to attain complete competance with the system.
          • The JavaDoc documentation system shall be utilized so plug-in authors, and any power users, will have ready access to the MUG core API,
          • A "Help" button shall exist on the toolbar of the GUI, readily accessible to those who need it.

        2. System Reliability Requirements

          3.
          • The system shall be fault tolerant and maintain data integrity throughout operation.
          • The system shall not involuntarily halt, and result in loss of currently active models.
          • The system's input/output drivers for various file formats should not corrupt or degrade models through an importing or exporting operation.
          • The JavaSpaces server shall not involuntarily halt, and disconnect all parties participating in a collaborative design session.

        3. System Portability Requirements

          4.
          • The system shall be able to function regardless of the quality of hardware on the host machine.
          • The system shall be able to function regardless of the operating systems software that may be running on the host machine.
          • The system shall be able to function regardless of other external software running on the host machine.

          The main issue of portability is whether or not the host machine is capable of running a JVM. A few issues do exist, however, with certain Java packages which are not considered part of the core API. These are typically more dependent upon the host operating system than the hardware running on the host. MUG uses two additional packages, JavaSpaces and Java3D.

        4. A "Help" button shall exist on the toolbar of the GUI, so then this feature is readily accessible to those who need it. The Help feature will cover all menu options, and offer a brief description of functionality to the user.

          Portability with the Java3D: a few issues exist with the Java3D API. Since this relies heavily upon the host machine's graphical capabilities, it requires that the Java3D API is developed specifically for that platform in addition to the JVM.

        5. System Efficiency Requirements

          6. Hardware/Software Minimum Recommended
          CPU Requirements Intel Pentium II 350MHZ Intel Pentium III 450MHZ
          RAM Requirements 128MB 256MB
          Disk Requirements 4.5MB 8MB (with documentation)
          Video Card OpenGL support video, w/32MB of video RAM OpenGL support video w/3D acceleration, w/64MB of video RAM

          1. System Performance Requirements

            2.
            • The following host-dependent system requirements must be met:
              • Any combination of computer hardware capable of running a JVM, and other external Java packages upon which MUG is dependent.
              • Any operating system capable of running the JVM, and other external Java packages upon which MUG is dependent.
            • The system shall not consume all of the host's resources such that it can not operate other programs typically necessary for a designer or engineer to work effectively.

          2. System Space Requirements

            3.

            See the table above

          3. System Speed Requirements

            4.
            • The system shall perform at a rate such that collaborative meetings can be executed in real-time.
            • Typical design transactions shall be executed with little or no delay as long as the host meets the minimum system requirements for operating hardware.
            • The processing chip required to undergo a real-time collaborative design session should be at least an Intel Pentium III 800 Megahertz.

      2. System Organizational Requirements

        3.

        1. System Delivery Requirements

          2.

          The timetable that outlines the MUG development cycle and the evolutionary development process is shown below. It lists the individual tasks that need to be completed as well as which candidate specifically will be working on a task.

        2. System Implementation Requirements

          3.

        3. System Standards Requirements

          4.
          • The VRML importing and exporting capabilities shall adhere to all standards of the industry, and shall further resist any temptation from corporate powers to use non-standard features.
          • The XML importing and exporting capabilities shall adhere to all standards of the industry, and shall further resist any temptation from corporate powers to use non-standard features.

          Although some of the packages used by MUG have not been standardized amongst all platforms, they are still considered standard within the Java community and plans are in action to bring those packages to all platforms which are capable of running a JVM.

      3. System External Requirements

        4.

        MUG has been developed with the intentions that it will be extensible by others. This means that backward-compatibility with older versions of the API must be enforced to ensure the future usability of the system, since programs may already be in place that are dependent upon legacy API's that MUG once directly supported.

      4. System Legislative Requirements

        5. Proper acknowledgements shall be given to all direct or indirect contributors including corporations, individuals, etc. who are responsible for software upon which MUG is built.

        When dealing with proprietary models it must be guaranteed, by law in some cases, that the intellectual property of those models can not be compromised. A strong, well-defined encryption algorithm may be required in order to host these models.

        1. System Privacy Requirements

          2.
          • The system should provide a way to accept or deny access to any user trying to connect to network space.
          • The system should avoid sending data unencrypted over network channels.
          • The user shall be able to confidently perform transactions without the threat of a malicious user trying to intercept his/her data.

  7. Domain Requirements

    8.
    these are requirements that come from the application domain of the system and that reflect characteristics of that domain. They may be functional or non-functional requirements.

  8. System Models

    9.


    This is how an agent interacts with the system.

     


    This is an abstract overview of the entire system.

     


    This is a model of the client/server architecture.

     


    This is a model of the threads architecture.

     

  9. System Evolution

    10.

    As part of an on going development project, MUG is just another step in the projects evolution from a VRML-web based application to a stand-alone, multi-user java application. The system is based on the understanding of how conceptual design is currently achieved, people working together with pencil and paper, sketching out their solutions to a particular problem. We assume that being able to achieve this type of collaboration through a light-weight CAD system, will greatly improve productivity and reduce the costs of producing designs.

    As software tools such as Java, Java3D, and JINI improve, the system will evolve to utilize their new features, thus creating better performance.

  10. Appendix A: Internet Resources

    11.
    CUP
    http://edge.mcs.drexel.edu/CUP/
    DAML
    http://www.daml.org
    GICL
    http://gicl.mcs.drexel.edu
    HTML
    http://www.w3.org/MarkUp/
    Java
    http://java.sun.com/
    Java3D
    http://java.sun.com/products/java-media/3D/index.html
    JavaSpace
    http://java.sun.com/products/javaspaces/index.html
    National Design Repository
    http://www.designrepository.org
    MUG
    http://edge.mcs.drexel.edu/MUG/
    RDF
    http://www.w3.org/RDF/
    SGML
    http://www.w3.org/MarkUp/SGML/
    VRML
    http://www.w3.org/MarkUp/VRML/
    XML
    http://www.w3.org/XML/

  11. Appendix B: NURBS

    12. In MUG, free-form curves and surfaces are implemented using NURBS (Non-Uniform Rational B-Splines), the standard representation of shapes in most commercial CAD packages. Their popularity is attributed to several factors:

    Curves are defined as a piecewise rational polynomial function of the following form:

    <a href=NURBS curve formula" align="center">

    definition of w_i, P_i

    The basis functions are recursively defined as:

    basis

    Ui

    There are several different types of NURBS surfaces that can be defined, such as ruled, extruded, or surfaces of revolution, which are based on either one or two curves. In general they are defined as:

    surface formula variable defs

    In general there are two ways to modify the shape of a NURBS objects by direct manipulation or by modifying the degrees of freedom. Although that ambiguity arises, our approach in MUG has been a degree of freedom approach, which allows manipulation to occur by altering the position of a control points, by changing the weight of a control points, by modifying the knot vector(s), along with the degree in the case of the curve. In MUG, only the two of these methods are implemented. By restricting the user to only modifying the control points and the degree of the object, we reduce some of the ambiguity and difficulty that arises when allowing this type manipulation while limiting the number of possible shape.

    For more information on NURBS see the following webpages:

  12. Appendix C: Markup Language Discussion

    13.

    In order to give a thorough discussion of markup languages, we'll attempt to wal k you through a brief history of the topic. The Standard Generalized Markup Lan guage (SGML) is defined in International Standard ISO 8879:1 986, and it is a language for formally describing the structure and contents of documents. SGML is an important move in the direction of se parating information from its presentation, (ie. making different presentations possible for the same information). All the markup languages we will discuss, a re descendents from this language.

    While HTML allows us to visualize the information on the web, it doesn't provide much capability to describe the information in ways that facilitate the use of software programs to find or interpret it. HTML is not well defined as a standa rd, and does not have any constructs for representing semantic data. Missing is a part of the Web which contains information about information (ie. labeling, c ataloging and descriptive information), structured in such a way that allows Web pages to be properly searched and processed in particular by computer. This in formation about information is what we call metadata .

    XML was developed to encapsulate much of the functionality of SGML, but with the intentions that it would be easier to use. The designers of XML simply took the best parts of SGML, guided by the experience with HTML, and produced something that is no less powerful than SGML, b ut vastly more regular and simpler to use. It must be said that while SGML is mostly used for technical documentation and much less for oth er kinds of data, with XML it is exactly the opposite.

    Despite the glorious capabilities for exchanging general purpose metadata in XML, it does have its limitations. Some people believe that XML tends to fall apart on the scalabili ty design goal for several reasons. When you represent general X ML documents in computer memory, you get weird data structures that mix tree s, graphs, and character strings. In general, these are hard to handle in even m oderate amounts, let alone by the billion. Another reason is b/c the order in w hich elements appear in the source of the XML document is sig nificant and meaningful. This should not be a requirement for representing metadata. XML also has a limited capabil ity to describe the relationships (schemas or ontologies) with respect to object s.

    XML is unequalled as an exchange format on the web. It is a perfect solution to the interchange design goal of the Resource Description Fram ework (RDF). RDF is a framework for describing and interchanging metadata built with tuples consisting of a resource, prop erty, and value. There are also statements allow the lis ting of other facts in the domain. A resource includes any web pages, as well a s individual elements of another XML document. The RDF is ve ry extensible in that properties are resources, values can be resources, and sta tements can be resources. Statements can also have properties of their own whic h allows a class hiearchy to possibly emerge.

    The DARPA Agent Markup Language (DAML) is being developed as an extension to XML and the Resource Description Framework (RDF), to solve this problem. DAML is now coupled with the Ontology Inference Layer (OIL), a joint s tandard for integrating ontologies with exisiting and arising web standards. OIL is a Web-based representation and inference layer for ontologies, which combine s the widely used modelling primitives from frame-based languages with the forma l semantics and reasoning services provided by description logics. DAML+OIL is a semantic markup language for Web resources. It builds on earlier W3C standards such as RDF and RDF Schema, and extends these languages with richer modelling primitives. DAML+OIL provides modelling primitives commonly f ound in frame-based languages. The language has a clean and well defined semanti cs based on description logics.

    Most references to XML in this paper, would more accurately b e described as DAML instead of XML. Since DAML uses XML as an exchange format, the use of terminology is somewhat interch angable, which is reflected by the usage in this paper.

    Our purposes for using the DAML ontology are for the semantic representation of function and flow of the models MUG is going to represent. Comprehensive representation schema's need to be implemented in order for the conceptual models to be useful. This w ill facilitate indexing, querying, and other automated tasks that may need to be accomplished using the models.