MXPA99007846A - Visualization of dynamic objects and code generation - Google Patents

Abstract

An apparatus operated by computer is presented to generate a visual information system. A virtual world associated with an application is made using building blocks such as scenarios, data sources, global parameters and resources. A scenario is a visual display of information much like a presentation slide, with the exception that the information can be linked to data stored in a database or other data storage systems. Within a scenario, the resulting values of the data source are graphically represented as data elements defined by the user. Data sources are constructed with a block schematic tool that generates one or more questions in the database. The questions can be SQL questions. The scenarios are created with a plan editor that transparently commits the data sources with the graphic elements of the scenarios. When the virtual world is completed, an execution image of the virtual world can be represented as an octet code. The octet code that represents the virtual world can be executed by means of a runtime control to provide the desired information to the users.

Description

VISUALIZATION OF DIN MICOS OBJECTS AND GENERATION OF CODES BACKGROUND The present invention relates to commercial intelligence tools for creating applications in a database management system (DBMS). The advent of powerful, yet affordable, computers made possible by advances in processor, memory, and data storage devices has made computers an integral part of modern companies. An important class of application for these computers includes a DBMS where information is collected and organized according to a data model and searched using questions. DBMS allows users to perform operations such as locating, adding, deleting and updating records stored on the computer without any detailed knowledge of how the information that makes up the records is actually stored on the computer. Another powerful type of DBMS is known as a Relational DBMS where the stored information appears to the user as a set of boxes, each of which is called a relationship. In each relation, the information appears to be arranged in rows and columns, with columns of data being related to each other by one or more predetermined functions. To access particular information in the relational DBMS, a question compiler converts a user request, usually expressed in a question language as a structured question language (SQL), into a set of operations that will be performed on one or more input relationships to produce a solution sensitive to the user's request. Using the question language provided by the DBMS, the user can develop application programs which facilitates the recovery of DBMS data, the processing of data and the organization of data in reports. A topic in the development of commercial intelligence tools is the type of reports that the tool will generate. Normally, the tool generates certain preformatted reports using the question language. Although the question language is easier to use than conventional programming languages such as Basic or C, the generation of each new report still requires some programming experience and can often take a substantial amount of time. Compendium The invention provides a user access to data through information spaces called scenarios that allow the user to understand, visualize and navigate data. In one aspect, a method for execution and application expressed as a scenario graph is presented. The scenario graph is a hierarchical representation of one or more objects, each object capable of generating a code associated with the object. The application is executed crossing the hierarchy of the scenario graph; and for each object stored in the scenario graph, the instruction of each object for its self-execution. The implementation of the invention includes the following. The method generates an execution image for each scenario of the scenario graph by: retrieving the octet code associated with each node of the object; the storage of the octet code as part of the scenario and the generation of the execution image of the octet code for the scenario. In addition, the node is characterized as one of several types. If the node type is a form type, the method generates a form creation declaration; generates a start property declaration; for each property, it generates a declaration to program each property associated with the object, and generates a declaration to bind each property. If the node type is a type of data source, the method generates a question from the database; determines the names of the columns for the identifiers with reference; generates a statement to create the question; for each parameter, create a declaration to program a value of the parameter of the question; and generates a statement to execute the question. The image of the octet code is then provided to an execution engine. Then an execution context is created for the octet code. When the declaration is executed in the octet code, the method determines whether the declaration is a declaration of creating form, and if so: the form is created and the form is stored in a copying table context using a form name symbolized If the declaration is a declaration of starting property, the method looks for the form in a copying table context; and performs a startup method associated with the form. If the declaration is a declaration of schedule property, the method looks for the form in a copy table context, evaluates a property expression associated with the form, and assigns a value to the property. If the declaration is a declaration of ending property, the method looks for the form in a copying table context, performs the method of ending properties associated with the form to commit the properties, initializes the form and adds the form to a list display. The method also renews a picture associated with the form. Each property of the object is programmed and the object is notified before and after the programming of the property of the object. In another aspect, an editor is presented to visually edit the data representation. The data has a matrix graph and one or more graphical data elements nested recurrently in the matrix graph. The editor has a window to edit a matrix graph and one or more specialized search windows to edit each or more graphical data elements nested in the matrix graph, where each of the elements of the graphical data contains a nested graph. Publisher implementations include one or more of the following. An attribute window is associated with each of the graphic data elements. The attributes window is used to edit the properties associated with an object implemented by the computer that has an object state and one or more interfaces that provide access to the state of the object through a plurality of attributes, each of the defined attributes as a functional and referenced expression at runtime as the value of the data. The functional expression includes one or more of the following: a function, an operator, a column name of the database, a variable and a constant. The attribute can be a value of static data. The functional expression can be analyzed to generate a function that is stored as a value of the execution time. The function can be cloned and stored as a design time value if the function is a constant. In addition, an error message may appear on the screen if the expression is not valid. The advantages of the invention include 1 or more of the following. The invention is a visual commercial intelligence tool to create applications that go beyond the limitations inherent in conventional applications based on forms or based on reports. Specialized programmers are removed from the application development process and users are moved closer to the data so that application development time is reduced. User interfaces can be quickly and easily created for information-rich databases and for applications such as data storage and decision support. The hyperlink of the invention provides text and "advance registration" information to the applications. This capability supports several powerful advantages in the creation of data driven applications. First, users can see through portals to other views of their data without losing the context of where they are. The navigation path taken by a user browsing the application can affect the application itself, thus providing dynamic customization of the application. In addition, context portals simplify the consolidation of various data sources in a single application. In the case of questions that are parameterized with parameters that are adjusted by the portal, it actually provides unions of universal questions on the client side, allowing data from different databases to be combined in a meaningful way. As a result, context portals allow users to achieve a greater level of understanding of their data and thus make better business decisions. The dynamic properties of the object simplify the development of data driven applications, allowing experts in the domain, without programming experience other than the use of analysis sheets, to use the tool to easily create powerful applications. The dynamic properties of the object have several advantages over the static properties of the object which are encoded with protection to the application when they are collected. The first is that the properties are linked in a perfect and automatic way to the data. In addition, links are applied to a complete class of objects (all objects represented by the data element node) instead of simply to a single object (that is, the calculated value for each object depends on the row represented by the object). object). Another advantage is that it eliminates the specialized coding that would otherwise be required to perform these simple tasks in order to make the object color depend on the value of a column or set of columns of a data source. In addition, more than one property of an object can join a column in a row (or even a calculation made in all rows). In contrast to conventional development tools where each object is limited to a single link. The invention allows each column or row associated with an object to be linked to a separate property. Generating the code of a scenario graphic eliminates the need for manual scheduling, thus allowing developers to concentrate on mastering the problem instead of the tool itself. As a result, a domain expert with no programming experience can quickly create powerful applications. In addition, the representation of the stage graph provides a powerful way to browse the content of an application and make changes and organization to an application as easy as reorder the summary of a document in a word processor. In addition, the invention allows the representation of individual data points to be avoided in a general manner as the upper level scenario itself. This capability allows the creation of powerful applications which support specialized search and exploration navigation. This navigation allows users to achieve a greater level of understanding of their data and thus make better business decisions. Other features and advantages will be apparent from the following description and claims. Description of the drawings Figure 1 is an interface of multiple documents to edit 1 or more worlds. Figure 2 is a diagram illustrating an object inspector. Figure 3 is a diagram illustrating an object property model of an abstract base class VcPropertyBag. Figure 4 is a diagram illustrating two classes of execution in octet code VCStmtCreateShape and VcSmtSetProperty.

Figure 5 is a diagram illustrating an analyzed property sample function. Figure 6 is a diagram illustrating an object model of a scenario code generation process. Figure 7 is a flow chart illustrating a property sheet entry process. Figure 8 is a flow diagram illustrating a process for visually manipulating an object. Figure 9 is a flow chart illustrating a process for generating byte codes. Figure 10 is a flow chart illustrating a process for obtaining execution declarations and byte codes for a node. Figure 11 is a flow diagram illustrating a process for executing the octet code. Figure 12 is a diagram illustrating a graphics editing system. Figure 13 is a diagram illustrating a needle. Figure 14 is a diagram of an object model of a hole. Figure 15 and 16 are diagrams illustrating exemplary uses of the hole.

Description Now we will describe a visual commercial intelligence system to create applications. In this system, a developer interactively creates a virtual world, whose building blocks include scenarios, data sources, global parameters and resources. A scenario is a visual representation of information very similar to a presentation slide, except that information may be linked to data stored in a database. Within a scenario, the resulting values of a data source are represented graphically as data elements defined by the user. The data sources are built with a block schematization tool which generates one or more database questions. The questions can be SQL. The scenarios are created with a drawing editor which transparently links the data sources to the graphic elements of the scenarios. When the virtual world is finished, an execution image of the virtual world can be represented as an octet code or a high-level code which can be interpreted subsequently. The octet code representing the virtual world can be executed by a runtime control as an ActiveX control.

The runtime control can be incorporated into a Web page or are applications that support the ActiveX control such as Visual Basic, C or C ++. A scenario can have 1 or more objects. Objects in a scenario are described by a set of properties and actions can be assigned which are triggered by events such as clicking, proximity of the user to the scene and location of the mouse. A point of view is a three-dimensional location to see a scenario. The location s describes in terms of the current X and Y compensation of the user's cursor from the center of the stage and the current approach level of the user (often referred to as the amplification level). At a point of view a unique name can be assigned and saved to facilitate navigation within the world. Named views can be used for manual navigation by the user or can be used as the target for an event-based jumping action. A data element is the graphic representation of a row resulting from a question. It is always associated with a sketch and data source and is constructed in a very similar way to a scenario. It may contain some combination of objects, including sketches and holes to other scenarios. Properties for objects that make up a data element can not only refer to scenario parameters, but can also reference column names in the associated data source. Scenarios and data elements can be represented differently as a function of the user's approach level. Each representation is called a level of detail (LOD) and visually is mutually exclusive of other LODs. For example, an object that begins to be represented by a single point can change to an icon when the user comes closer and then to a table when the user gets even closer. The transition points between the levels of detail are defined manually by the user in terms of approach factors. A scenario or data element can N-l transition points for N levels of detail. Visibility can also be controlled on a "per objects" basis by setting a "visibility" property to a conditional expression such as Yes (UserZoom >); 2, true, false) In this way, regions of transition can be created where alternate representations cover certain ranges of approach levels instead of being mutually exclusive. Coating can be particularly important in creating layered maps containing multiple data elements. In addition, more complicated expressions can be used to control visibility in order to achieve other effects. Data sources can be named SQL questions that can be parameterized by 1 or more identifiers that are adjusted at runtime. When the data sources are defined, they are named and added to a world and not shown in the World Manager data source category. Then they are available for execution. The results can be browsed on a data sheet or used in a sketch. When used in a sketch, each row resulting from the question is transformed into a graphical representation represented by a data element. Columns in the resulting data source can be linked to attributes and objects contained in the data element. The parameters present in the data source query can be associated with a global program variable, with a local scenario parameter, or with a column in a higher data source in the hierarchy of the world tree. Figure 1 shows an interface of multiple documents to avoid 1 or more worlds at the same time.

The main portions of the user interface are a World Manager 10 window, project workspace window and editor 20 and 22, an object inspector 30, a control bar 40 and an output window 24. The workspace of the world is a background area that contains publisher sales. Four types of editor windows are provided. A graphic drawing editor called a scenario editor is provided to compose a higher level scenario. A graphic drawing editor called a data element editor is provided to define the representation of each data point in a sketch. A tool called a question editor is provided to define SQL questions, either by constructing a graphic block diagram of the question or by directly entering the SQL manually. The question editor also provides a fact sheet to see the results of a question. In addition, a world editor is provided which shows two clues of a complete virtual world: the first is the view of the structure of the world showing the world hierarchy along with parameter links and the second is a read-only pseudo-code view providing documentation and search skills for everyone. The World Manager 10 window is the main interface for editing and managing the world or open worlds of a user. It has a control bar that can be coupled with tabs 12, 14 and 16 and corresponding information panels. When the user clicks on a tab, the tab is moved to the top and an underlying panel is displayed. Each panel in turn presents a set of buttons, to show categories and information. Clicking a button shows the category of information associated with the button. The Graphics tab 16 presents a categorized palette of all graphic objects that can be added to a scenario or data element. The World Manager 10 can be attached either to the right or to the left of the workspace 20. In its coupled state, it can be stretched horizontally to lengthen or reduce the dimensions of the panels. In its floating state, it can stretch both horizontally and vertically. In the example of Figure 1, a tab called a Mundos 12 tab shows three separate views of the structure and hierarchy of the currently open worlds. Each open world is shown below the main workspace point in a tree control 18. A context menu is available for each point shown in a tree control and provides a list of common menu commands for the selected point when it is selected. click with the right mouse button. In this example, a category of scenarios shows global parameters and scenarios contained within each open world. The global parameters are identifiers which can be mentioned anywhere within the hierarchy of some scenario both in object properties, and in event actions. Below each scenario is a list of its local parameters (if any) and views, along with the detail levels for the scenario and a hierarchical list of the objects that comprise each level of detail. Each level of detail is mutually exclusive of the others when viewed. In other words, only one level of detail is visible at a time. The order of the objects in the tree below a level of detail determines its order of * drawing. Objects displayed below other objects are called child objects and their owners are called parent or compound objects, some points in the tree can refer to other points in the tree as a hole (discussed later) which refers to another scenario , or a data element which refers to a data source in the tree for the category of data sources. The category of data sources demonstrates a list of questions contained by each open world. Each data source in turn contains a list of question parameters, names or aliases of columns and a diagram if the question diagram editor was used to construct the question. When present, the question diagrams contain the list of blocks and connections used in their construction. The resource category shows a list of execution resources that can be used in the calculation of property values for scenarios and their graphical content (nodes). Basic types of resources can include color maps, color sequences, stock images, and user classes. Data sheet 14 contains two categories of information: Question Design, which provides a palette of elements that will be used in the construction of a question diagram; and Database Content, which allows the content of an active database schema to be browsed. The content of the question design category can be presented as a palette. The database content category can be presented as a tree where the column names below each table and view can show the name of the column and its type, separated by two double points (for example,? Employee_name:: varchar =). The database content tree can be used to browse the active schema. Each open world can contain zero or more open editor windows. Each of the four types of editors can display a single icon, followed by text describing the type of editor and the content of the editor. The format of the text can be in an abbreviated format or an extended format as follows: EditorType: Contents EditorType: WorldName [. ExtendedContents], where EditorType is the type of editor (? Scenario =, ? Datóse element,? Question =, or? World =), WorldName is the name of the world containing the content and Contents is the short name for the object that is edited (for example,? DataElementl =), and ExtendedContents is the name long for the object that is edited that includes the symbolized names of all parent objects, separated by periods (for example, Scenel ScatterChartl = more than one editor window can be opened for a particular part of a world. For example, the same scenario can be edited in an editor at 100% amplification to see the whole scenario, while another editor can be approached to a smaller portion of the stage. A change to the scenario in any editor can be reflected in both windows. The scenario editor window is used to graphically edit and debug the content of a top-level scenario. The editor has two modes: a design mode and a runtime mode. In the design mode view, the objects are added from the graphics palette and displayed without the execution of questions. Objects that are linked to data sources through one or more property values are represented by site support objects. In addition, no object events are generated, therefore all actions associated with objects are not executed. The scenarios can be edited at any approach level, which can be adjusted from the navigation toolbar. The design mode view provides two optional docking toolbars: a selection bar and a parameter bar. The scenarios can be represented differently at different approach levels, where each representation or drawing defines an LOD. The selection bar provides control over which the LOD is currently being edited. The parameter bar shows a button for each parameter in the scenario. If a scenario has no parameters, the bar is not displayed unless it has been manually activated from the View menu. The parameters displayed in the palette can be used in the Object Inspector to adjust the value of the properties of an object. The parameter bar can be updated automatically when the parameters are created, deleted, or edited. When the run-time mode is selected, the content of the scenario is collected in octet code and then displayed, as discussed below. All the associated questions are executed, the object events are generated and the associated actions are carried out. The runtime mode supports the full navigation capability, therefore the holes or jump links to other scenarios are accessible. If a jump is made to another scenario, the design view is also changed to the new scenario. The run-time mode can be seen simultaneously during the editing operations in the design view by opening a second window. Multiple runtime views that show in the same scenario operate independently and can not be enslaved to each other. Each view has its own copy of global parameters which can be reflected in the world's scenario tree for the active run-time view. The data element editor window is used to graphically edit the representation of a data point resulting from a question. The data element editor window is shown in the design mode in Figure 12. Both the bending bar and the data source bar are visible. Similar to the scenario editor window, the data element editor has two modes: design mode and run time mode. In the design mode view, objects are added from the graphics palette and displayed without the execution of questions. Objects that are linked to data sources through one or more property values are represented by site support objects. further, no object events are generated, therefore all the actions associated with the objects are not executed. Data elements can be edited at any approach level, which can be adjusted from the navigation toolbar. Data elements can be represented differently at different levels of approach, where each representation or drawing defines an LOD. In addition, different objects can be associated in the data element with different axes. For example, a stock chart with trading volume bars can have two Y axes. The data item for each trading day can have a high / low / close bar associated with the price axis and a volume bar associated with it. the volume axis. The selection bar provides control over which the LOD and axis set can be edited. The parameter bar shows a button for each parameter in the scenario. The parameters displayed in the palette can be used in the object inspector to adjust the value of the properties of an object. The parameter bar is updated automatically when the parameters are created, deleted, or edited. The data source bar shows a strip of buttons for data source within the scope of the data element. Each button corresponds to a column name that can be used in the object inspector. For a simple sketch, only one data source is displayed. For nested sketches, a row can be displayed for each question. A question is considered in the scope if the associated object of the data element exists as an ancestor to the data element in the tree of the world scenario. The data source bar can be updated automatically when columns of data sources are created, deleted, or edited. The question editor offers three views of a question: the data sheet that shows the results of a correctly formed question; the question diagram view which provides a block diagram of the question structure; and the SQL view, which shows the actual SQL text. The user can switch between the views by clicking on one of the corresponding mode buttons in the lower part of the window to the left of the scroll bar. The data sheet view is a read-only view, which shows the tabular results of the question. If the question is parameterized, the data sheet can only be available when an implicit value is available for each parameter contained in the question. The data sheet can be viewed simultaneously during the editing operations in the question or text text view of SQL by opening a second window. Changes to the question may cause the data sheet to be updated interactively. When the data sheet mode is not selected, it can not be updated with changes to the other views. The rows are loaded into the data sheet when they come into view.

The user adds blocks to a question diagram by selecting them from the World Manager data sheet or from the Insert menu. The blocks are connected by clicking on the output port of the source block and the input port of the target block. Alternatively, the blocks can be connected by dragging the mouse from one of the ports to the other with a resulting elastic band connection line shown until the user releases the mouse button. In any case, the cursor can be changed between the port selection actions to denote the connection operation. The SQL view allows the creation and editing of SELEC arbitrary questions. It also allows the editing of the expression generated by the diagram editor. However, if the SQL is edited, the diagram may no longer be available. In this case, a confirmation dialog can be displayed to warn the user. The world editor provides two views to interact with the virtual world: a structure view and a pseudo-code view. The structure window of the world shows a hierarchical view of the organization for a complete world. Each box below the world root box corresponds to a scenario. The boxes below the scenarios correspond to data elements or other scenarios connected by holes. Double-clicking on any of these boxes can open the corresponding scenario or data element editor. The links between boxes represent the hierarchy in the tree of the world scenario. A table can have a child table for each data source and hole included in its graphic content. Depending on the structure of a world, the depth of the tree can be infinite. For example, if a scenario contains a hole to another scenario which in turn contains a hole back to the first, the tree can contain an infinite vertical sequence of the first and second scenarios. As a result, the tree can only expand one level when it is explicitly expanded by the user. Each link and the box or boxes below it can be shown or hidden by clicking on the button at the top of the link. When initially displayed, the world box can be expanded to show all the scenarios contained by the world. When the frames are expanded, the tree structure can be adapted to make room for newly exposed paintings.

The parametrization of a world is also shown in the structure diagram. The global parameters, the scenario parameters and the question parameters are shown as text boxes which extend to the left of the box denoting their role as entries, while the question columns are displayed as text boxes which are They extend to the right of the box that denotes their role as outputs. When parameters and column names are added, deleted or modified in other editor windows, the tables are updated to reflect the change. When you adjust a scenario or question parameters to a parameter or column higher in the hierarchy, the text box of the parameter is shown? Wired = to the source value. These connections can be avoided in the structure diagram. When establishing a new connection and adjusting the value of a parameter, click with the mouse on the input connection point for the parameter and on the output connection point for the source or column parameter (in any order). Alternatively, the connection points can be connected by dragging the mouse from one point to another with a resulting elastic band connection line shown until the user releases the mouse button.

In any case, the cursor can be changed between the selection actions to denote the connection operation. Note that the source must be higher in the tree hierarchy for a valid connection to be established. To remove the link, the user selects the link and then presses the delete key. The pseudo-code view provides a read-only view of the entire contents of a world in text format. The pseudocode can display an initial heading consisting of the world name and the initial scenario, followed by the following sections: Global parameters User classes Color maps Color sequences Stock images Database connections Data sources Scenarios In an implementation , the sections are surrounded by a pair of dashed lines as follows: SectionName In addition, data sources and scenarios are separated by a single separation line: The following sections show the format for each pseudocode element. Note that brackets X ['and]') denote optional text and vertical separators (* | ') denote alternatives. Global parameter format DataType ParamName [(Incorporated)] Description: Description Implicit value: (None) | Access Value: [Private I Public] Format of user classes ClassName Parent classes: (None) I ParentClassl [ParentClassN] Format color maps (discrete colors) ColormapName Discrete Colors: ColormapName (below BL) valueL [(ColorName)] ColormapName (Bi-Bi + 1) = valuei [(ColorName)] ColormapName (above BU) valueU [(ColorName)] Color map format (mixed colors) Continuous colors (mixed): ColormapName (below BL) valueL [ (ColorNameL)] ColormapName (Bi) = valuei [(ColorNamei)] ColormapName (above BU) valueU [(ColorNameU)] Format of color sequences: ColorseqName ColorseqName [O] = valueo [(ColorNameo)] ColorseqName [N-l] = valueN-1 [(ColorNameN-1)] Stock image format: ImageName Format: [Bitmap | Windows Metafile | JPEG] Format of database connections: ConnectionName Server: Server Database: Database User: User Implicit scheme: Format of data sources: DataSourceName [(DataType paraml,)] Connection: ConnectionName SQL: SQL Scenario format : SceneName [(DataType parmal, ...) Local parameters: Parameter name ParaName Description: Description Implicit value: [Value] Points of view: Point of view name: ViewpointName [(Incorporated)] Description: Description Location: (X, Y) Approach factor:% approach Obj ects: ExtendedObj ectName Properties: DataType PropertyName = PropertyValue Events: EventName (DataType EventParaml, ...) [Param = Expression] [Action (Optionl,.] The pseudocode can display a chromocoded syntax. For example, section headers can be displayed in green, data types can be displayed in blue, and all other text can be displayed in black. The pseudocode can be updated every time a change is made that any part of the world. The output window is a dockable control bar which displays and collects execution information when a world is developing and viewing. It also shows warnings and error messages. The exit window can be readjusted vertically when it is coupled and both vertically and horizontally when it is floating. In the run-time mode, a dialog box of views can be provided to navigate a world. Scenarios that allow direct access in the scenario combination box can be displayed. The views for the selected scenario can be displayed in the views list box. Selecting a point of view updates the values of the location editing controls. The values in these controls can be changed to a custom designation specifying a location and approach factor. A sketching expert can be provided to guide the user through the steps in creating a new sketch. The first two common steps for all the sketches are to select the sketch and then the data source. Each sketch can then have the additional steps specific to the sketch that are necessary to create the sketch. Sketches are spatial arrays of data elements resulting from a data source with backup context information such as a set of axes. The sketches can be included in the following set of 5 categories: Tables B Used to present a series of information. B maps used to design multiple curves or series of information within a single data source. Hierarchies B used to show object dependencies. Patterns B used to design independent objects in an ordered pattern.

Forms B used to display a single record in a data source (if the data source results in more than one row, subsequent rows are ignored.) Sketches can be placed anywhere in a scenario or data elements drawing. Some types of sketch such as maps and scatter charts support more than one data element, thus allowing the "stratification of information." In this case, each item of data can be assigned a visibility that depends on the current level of approach, thus allowing more information is presented at larger zoom levels.The axis nodes are attached to the sketches that require them.For some types of tables such as bar tables and columns which have an axis that is based on text labels instead of numerical values, one or more of these axes may require a data source and thus may be linked to the data.Axis that can be supported includes Linear, logarithmic and date / time axes. These axes can also support label increments and auto-adjustment counter-marks so that the approach can provide more information about the precise values of axes.

Certain sketch types can use locators instead of axes to place the data elements. These locators can not be displayed visually at design time, but their properties can be displayed in the object inspector along with the properties of the other objects in a sketch. Composite sketches, where a piece of data within a sketch can contain a sketch itself, can also be used. Normally, the data source associated with the second sketch can be parameterized, with one or more parameters linked to a column of the data source of the parent sketch. The identifiers are names for elements within a virtual world such as objects, data sources, scenarios, parameters, user classes, color maps, color sequences and points of view. The identifiers are not case-sensitive and may be of some length greater than or equal to one character. Object properties consist of named attributes that define the appearance of an object in terms of a functional expression. Access to these properties is provided through the object inspector. Their values are adjusted in the execution time based on the calculated result of the expressions. An expression can include the names of one or more columns of data sources which are automatically linked to a row of results at runtime. Object object expressions result in one of the following base data types: Boolean, numeric, string, point, PoinList, and image. Derived numeric types include color, DateTime, Enum, Integer, and Percentage. Derived string types include FilePath (or URL) and FontName. Referring now to Figure 2, the object inspector 30 is shown in more detail. The object inspector 30 provides two columns, a column of attribute names 100 and a property column 110. The object that is inspected in Figure 2 has properties 112, 114, 116, 118, 120, 122, 124, and 126 Particularly the properties 114, 116, 118, 120, 124 and 126 are constant and static. However, properties 112 and 122 are dynamic and are evaluated at runtime. Due to the dynamic properties 112 and 122, to create a time-driven application, the user only needs to enter the dynamic properties and the code can be generated automatically. In this way, the data link of the dynamic properties 112 and 122 is seamlessly integrated into the property sheet 30. The object inspector window 30 is a dockable control bar that displays the properties and events of an object. The object inspector can be readjusted horizontally when it is attached and in both vertical form, as horizontal when it is floating. The window can be attached to the left or right of the world's workspace when its location overlaps the docking site when it is dragged. The object inspector 30 is displayed when a scenario editor window or data element editor is active in design mode and displays a downward combination box containing a list of all objects within the scope of the editor. The annotation? Dot = is used to denote compound objects. For example,? ScatterChart1. DataElementl = denotes that DataElementl is an object owned by ScatterChartl. Below the object selection combination box is a sheet provided with tabs showing either properties or events for an object. When the property tab is selected, an input form of two columns is displayed, to adjust the values of the properties of the selected object. The column on the left is a read-only column that shows the name of the property, while the column on the right is a read / write column that shows the value of the property. The values entered in the right column can be constant or they can be calculated values that contain parameter functions or column names of a data source. When a property value is of the enumerated type (a value that can only be programmed in a limited number of values), a reduction combo box may appear on the screen listing the legal values for the property. The types listed include but are not limited to the following: Name of the font (for example,? Arial =,? Courier =) Color (for example, Red, Blue) Alignment of the text (for example, Left, Right) text anchor (for example, Lower Left, Upper Right) Boolean values (for example, True or False) Line style (for example, Solid, Dashes) Fill pattern (for example, Solid, Horizontal) When a property is a date or a time, the calendar control can be displayed below the property value when the field is active.

The objects of the data element and form provide control over the values of the query parameters through the QueryParameters object listed in the Object Inspector. The QueryParameters object is a child object of the data element or form and contains a property for each question parameter. If the question is not parameterized, the QueryParameters object does not appear on the screen in the Object Inspector. The values contained by the object are used to program the properties of the question at run time before asking the question. Figure 3 shows a model of the property object of an abstract base class VcPropertyBag 200. The VcPropertyBag 200 acts as a container for a set of properties that are specific to one or more derived classes. The VcPropertyBag 200 provides an interface to access and manipulate properties and their values. It also provides a pure virtual method to obtain type information about the set of properties of the derived object. Derived from VcPropertyBag 200 there is an abstract base class VcScene 202 and an abstract base class VcDrawingNode 204. VcScene 202 is the class for a scenario and inherits properties from VcPropertyBag 200. VcDrawingNode 204 is an abstract base class for all objects graphics displayed in a scenario and also inherits the properties of the VcPropertyBag 200. VcDrawingNode 204 provides a set of pure virtual methods for manipulating properties in motion support, graduation and other standard editing operations. The derived classes are responsible for mapping the editing operations for the appropriate properties. VcPropertyBag 200 also has a set of m_properties properties of the VcProperty 210 class, which contains all the information about a property of a specific object, including the name and the type information listed, m_expectedType. M_expectedType describes the data type of the resulting property value (for example, boolean, numeric, string, etc.), stores the path to access the m_path object, and handles a design time value m_designValué and a value of runtime m_runtimeValue for the property. The design time is always evaluated according to a constant in such a way that the object of the container can be viewed in isolation (without links to data or parameters). When the value of the execution time is also constant, the two values are programmed in the same value. VcProperty 210 has an m_name property that belongs to Cstring 212, a standard string class to provide storage for the property name.

The VcProperty 210 object also has an m_path property of a class named VcPropertyPath 214, which stores an identifier for a property that is unique within the VcPropertyBag property set, and that provides an indicator, m_next, to a linked list of VcPropertyPath to support to the aggregate property exchanges. VcProperty 210 also has a m_design property value that belongs to a class called VcPropertyValue 216. VcPropertyValue 216 stores a function that represents the value of the design time for the property (VcFunction 220) and stores the expression accessed by the user in such a way that the sensitivity of cases, the spacing and other particular details to the user can be visualized as it is accessed (Cstring 218). VcFunction 220 is an abstract base class for a parsed expression element and the function is the root element for an expression tree that can be evaluated by supplying a context object. Cstring 218 is a standard string class that provides storage for the expression accessed by the user. By last, the VcProperty 210 object also has a property of m_runtime value that belongs to an abstract base class VcPropertyValue 222. VcPropertyValue 222 stores a function that represents the value of the runtime for the property and stores the expression accessed by the user in such a way that the sensitivity of cases, spacing and other particular details towards the user can be visualized as they are accessed. Turning now to Figure 4, a diagram illustrating the execution of an example octet code is shown. In this example, the user has specified a function in the form of an expression. The expression is subsequently analyzed to generate the octet code, which is a high level set of instructions that represent the desired operations and that are carried out at runtime. * The execution of the octet code is schematized in the Figure 4. Figure 4 shows the execution of a sample VcStmtCreateShape octet code 302. The octet code 302 creates a case of an object in particular form at the time of its execution and records a name symbolized for the object for a display of copying table. An example implementation pseudocode for the construction of the shape of the object that will be generated through the octet code 302 is shown as the block 310. In the implementation pseudocode block 310 for constructing the shape of the object, when a VcStmtCreateShape method 's Perform () is requested, the CreateShape () method of the factory object is required to create a new shape object and then an indicator is stored for the object on a copying table owned by a context object for later viewing when programming the properties. Finally, the method releases the reference for the form established during its creation. The octet code 302 has a property m_objectId that is a member of the standard class Cstring 300 to provide storage for the symbolized name of the form. The octet code 302 has a m_factory property that is a member of the abstract base class VcShapeFactory 304 that is responsible for the creation of a form within a scenario. Classes derived from VcShapeFactory 304 should bypass the pure virtual method CreateShape () in order to create a particular class of form and add it to a list of frames display. VcShapeFactory 304 creates a case of an object so that it is derived from the abstract base class VcShape 306. VcShape 306 is an abstract base class for all shape objects. It provides a polymorphic interface, oriented to the operations, to program the properties of the form. The classes derived from VcShape are responsible for implementing the provision and support of shock detection. Figure 4 also shows an abstract class VcStmtSetProperty 320, which is an abstract class for the octet code declarations in order to program the value of a property of the form when executed. The classes derived from VcStmtSetProperty 320 represent each type of data. The abstract class VcStmtSetProperty 320 stores the symbolized name of the form and a set of property identities needed to uniquely focus the property. VcStmtSetProperty 320 has a m_objectId property that is a member of the Cstring 322 class and an m_propPath property that is a member of the VcPropertyPath 324 class. VcPropertyPath 324 stores an identifier for a property that is unique within the property set of the form, and provides a flag, m_next, to a linked list VcPropertyPath to support aggregate forms. VcStmtSetProperty 320 in turn receives an inheritance from VcStmtSetStringProperty 326 that programs the value of the property in a way to a string value, and that contains an indicator for an abstract string function VcSftn 328 in order to evaluate the value of the property before programming the property of the form. VcSftn 328 is derived from VcFunction that evaluates the string for a given context and the function is the root element for an analyzed expression that contains the analyzed elements of the function. An implementation of the VcStmtSetStringProperty 326 octet code is shown in block 330. In this implementation, to program the property in a way, when the VcStmtSetStringProperty 's Perform () method is requested, the shape of the context copying table is retrieved. Then evaluate the string function with the given context and pass the result to the form through the property path. Turning now to Figure 5, a diagram illustrating an analyzed property function of the sample is shown. The function in this case is the VcStmtSetStringProperty 350 function. Function 350 has an object identification value? Textl = 352, which is a member of the Cstring class. This is the symbolized name of the object in the form that contains the property to be programmed. VcStmtSetStringProperty 350 is a declaration of the octet code of the sample that sets the value of the property of the text owned by the Textl object to the calculated value resulting from appended last_name to first_name, separated by a space character. In this example, m_objectId points to a string that identifies the target object, Textl; m_propPath points to the address of the property to be programmed into the text object, and m_ftn points to a string function that evaluates the value of the property. VcStmtSetStringProperty 350 has a property path whose values are programmed in block 354. Finally, VcStmtSetStrigProperty 350 has been designed to execute a VcSftnConcatenate 360 function. VcSftnConcatenate 360 is a string function derived from VcSftn that links the results of the two functions of member string, m_ftnl (first_name +? =) and m_ftn2 (last_name). Within block 360, two functions are also specified. Traversing down the left branch of the tree, a function VcSftnConcatenate 362 is designated. VcSftnConcatenate 362 is responsible for evaluating the expression (first_name +? =) Using its two member string functions, m_ftnl and m_ftn2. Within block 362 there are two additional functions, a function VcSftnLookup 364, a string function responsible for searching the current value of the identifier stored in m_ref (? First_names), and a function VcSftnConstant 370, a string function responsible for storing a constant string value The evaluation of the search function 364 is determined by the string of the character 366, which is a standard string class to provide storage for the identifier name,? First_names. The evaluation of the constant function 370 results in a character string that is a space (the string constant? S) in block 372. Traversing down the right side of the tree from the crawler function VcSftn 360, a function is evaluated VcSftnLookup 380. VcSftnLookup 380 is a string function responsible for finding the current value of the identifier stored in m_ref (? Last__name =). The evaluation of the function VcSftnLookup 380 results in a string of characters. An object model of the process of generating codes from a scenario is illustrated in more detail in Figure 6. The scenario contains a list of illustration nodes that represent the code generators for each logical element and form within the scenario . A VcScene 400 object defines an illustration or frame layer for all projected graphic objects in the display area. A CreateMethod () function generates a series of octet code declarations that create and fill the stage with graphical objects when they are executed. These statements are stored in an object named VcCgMethod 410. VcScene 400 contains a m_nodes list of objects derived from the VcDrawingNode 402 class. VcDrawingNode 402 is an abstract base class for all logical nodes and so they represent the content of a scenario. VcDrawingNode 402 defines an interface, GetExecStmts' (), to generate the list of the execution declarations VcStmt in derived classes. VcDrawingNode 402 is subclassified in VcShapeNode 404. VcShapeNode 404 is an abstract base class for nodes that generate shapes. The classes derived from VcShapeNode 404 generate the declarations of the octet code necessary to build and program the properties of each type of form. VcShapeNode 404 is subclassified in turn in the class VcDataNode 406, which is a class of the node in the form that joins a data source with a graphic mold representing the sketch of the objects for each row in a question. The octet code generated by VcDataNode reiterates the programmed result supplied by the data source, creates a set of objects and adds them to the active scenario. VcDrawingNode 402 is also inherited from an example node class VcLogicNode 408, which in turn is inherited by VcDataSource 410. VcLogicNode 408 is an illustration node class that generates an octet code that defines relationships between the nodes of the form and the user. VcDataSource 410 is a class of logical node that represents an abstract source of data. The derived classes are responsible for generating the octet code that results in a data table used by the data node to generate the graphs in a beceto. The class VcDataNode 406 contains a case of VcDataSource 410. The VcDataSource 410 is inherited by a class VcQueryDataSource 412. VcQueryDataSource 412 is a class of data source responsible for interacting with a question object to generate the octet code that builds a case of Question, replace the parameters of the execution time and carry out the question. The VcQueryDataSource 412 in turn points to a question object m_query, a member of VcQuery 414 that stores information about an SQL question, including the names and types of columns and parameters. The VcQuery object 414 in turn has a set of columns stored in a VcColumn 416 class and a set of parameters stored in the VcParameter 417 class. VcVolumn 416 stores information about a column of data that can be retrieved from the database in such a way which can be taken as a reference by the context object used by the octet code execution declarations. VcParameter 417 represents a named site support object that acts as an argument to a SQL SELECT statement. / Before the SQL statement can be executed, the parameter is replaced with the value of the parameter execution time. The VcScene 400 object generates a case of the VcCGMethod 410 class when the CreateMethod () member function is requested. VcCGMethod 410 in turn has a set of objects that belong to an abstract base class VcStmt 420. VcStmt 420 is an abstract base class for all octet code declarations. Its pure virtual method, Perform (), defines an execution interface that must be implemented by all derived classes. The abstract base class VcStmt 420 is inherited by a number of octet code declarations including 422, 424, 426, 428 and 430. VcStmtCreateShape 422 is a declaration of the octet code that creates a case of an object in a particular way when execute The declaration 422 registers a symbolized name for the object for the search in the copy table. VcStmtCreateQuery 424 is a declaration of the octet code that creates a case of a particular question object when executed. VcStmtBeginProperties 426 is a declaration of the octet code that notifies a case of how its properties will be scheduled soon. VcStmtSetProperty 428 is an abstract class for octet code declarations that program the value of a property of the form when executed. The derived classes represent each type of data that stores the symbolized name of the form and the set of Property Identifications Needed to uniquely focus the property. Finally, VcStmtEndProperties 430 is a declaration of the octet code that notifies a case in such a way that it changes its properties and completes them, and that it can carry out any calculation that depends on more than one property.

The object model of the code execution process is similar to the model of the object shown in Figure 4. Briefly, the octet code VcStmtCreateShape records a symbolized name for the object in a copy search table and creates a case of an object in particular when it is executed. The VcStmtCreateShape octet code declaration contains a factory object derived from an abstract base class VcShapeFactory that is responsible for creating a form within a scenario. In addition, the abstract class VcStmtSetProperty stores the symbolized name of the form and set of Identifications Property needed to uniquely focus the property. The octet code declaration VcStmtSetStringProperty programs the value of a form property to a string value and contains a • flag for an abstract string function in order to evaluate the value of the property before scheduling the property of the form. Turning now to Figure 7, an entry process of property sheets 440 is shown. By using the property sheet, the user accesses an expression (step 442). This expression is analyzed later (step 444) and revised for its validity (step 446). In the event that the expression is invalid, the process erases the value of the travel time using the design value as necessary (step 448) and displays an error message (step 450). Otherwise, in the event that the expression is valid, the process creates a function and stores the function as the value of the travel time (step 452). Next, the process determines whether the function is a constant (step 454), and if so, clones the function and stores the value of the design time instead of the same (step 456). Next, the process invalidates an execution image of the octet code, which contains an executable code by the execution time for the octet code (step 458). Then check if the run time screen needs to be updated automatically (step 460). If so, an octet code is generated (step 470) and carried out (step 472). From step 460 or step 472, the process exits the program (step 474). Turning now to Figure 8, a process 820 for visually manipulating an object is detailed. First, the process determines which property of the object is traced to which changed attribute (step 822). Next, a constant function is created to represent the new value of the attribute that is subsequently stored as the property value of the design time and property value of the design time (step 824). The octet code execution image is subsequently invalidated (step 826). The process then checks if the run-time screen needs to be updated automatically (step 828). If so, the octet code is generated (step 830). Step 830 is illustrated in more detail in Figure 9. From step 830, the process subsequently executes the octet code (step 832). Step 832 is illustrated in more detail in Figure 11. From step 828 or step 832, the process exits (step 834). Turning now to Figure 9, a process 600 is shown to generate an octet code. The process takes as input the previously stored application resources (step 602) and obtain a first scenario (step 604). The process subsequently obtains a first node in the scenario (step 606). Next, the execution declarations the octet code for the node are retrieved (step 608). This step is illustrated in more detail in Figure 10. From step 608, the process determines whether additional nodes need to be processed (step 610), and if so, obtains the next node (step 612) before going back into the circuit to step 608. When all the nodes have been processed, the process creates the VcVGMethod and stores declarations associated with the scenario (step 614). Then, the process determines if they need to be processed in additional scenarios (step 616). If so, the following scenario is obtained (step 618) and the process returns in the circuit to step 606 to continue the process of generating the octet code. When all scenarios have been handled, the process subsequently creates the execution image the octet code (step 620) before exiting (step 622). Referring now to Figure 10, a process 630 is shown to obtain the execution declarations of the octet code for an object node. First, the process determines the type of node (step 632). If the node is a form, the process generates a form creation declaration (step 634) as well as a declaration to initiate the capture of the property (step 636). Subsequently, steps 638-644 generate declarations to program each property recovered. Finally, the process creates a declaration to compromise the properties (step 646). On the other hand, if the node is a question data source, the process gets a question and generates a parametrized SQL statement (step 648). The process then determines the names of the columns to be used as referenced identifiers (step 650). Next, a statement is created to create a question (step 652). Then steps 654-660 create one or more statements that program each value of the question parameter. Finally, the process creates a statement to execute the question (step 662). From step 646 or step 662, the process exits (step 664). Referring now to Figure 11, a 666 process for executing the octet code is shown. First, an execution context is created (step 668). The process subsequently requests the VcCGMethod Perform () method (step 670). Statements are retrieved (step 672). The statement is then classified (step 674). From step 674, when a VcStmtCreateShape declaration is found, the process generates a new form (step 676) and stores the form in a copying table of context copying using a symbolized form name (step 678). From step 674, when a VcStmtBeginProperties declaration is found, the process looks for the form information on the copy table (step 680). The process subsequently requests the OnPropertiesBegin () method of the form (step 682). When a VcStmtSetProperty declaration is found, the process looks for the form information on the copy table (step 684). They then evaluate the property expression (step 686) before requesting the SetProperty () method of the form to assign the value to the property. When the declaration VcStmtEndProperties is found, the process looks for the information of the form on the copy table (step 690). It then requests the OnPropertiesEnd () method of the form (step 692).

The form is subsequently initialized (step 694) and added to a table screen list (step 696). From step 678, 682, 688 or 696, the process then checks whether additional statements need to be executed (step 698) and if so, the following statement is obtained (step 800) before the process is returned in the circuit to step 674. From step 698, the process subsequently clears the execution context (step 802) and renews the frame (step 804). Finally the process comes out (step 806). Figure 12 shows a diagram that illustrates the graphic editing system. A scenario graph 480 provides a hierarchical representation of an application. Each element of the graph of scenario 480 is requested by a node and the node is used to generate an octet code. In addition, two views 482 and 484 of the data are shown. View 482 is a sketch (a map) showing the data that has been retrieved from the two data sets. In view 484, a data point may be represented as a single image 485, which is highlighted in Figure 12. Image 485 is shown in design mode with an image of the site support. The attributes associated with the image 485 are displayed in a window 486. The user can avoid any data element since each data element has its own illustration window. In this way, a graph can be placed on the data point in such a way that there is a graph inside a data point. As the editing system of Figure 12 allows the user to define graphs within the data point that are nested within the graphs themselves, the editing system of Figure 12 provides a way to search in a specialized manner and observe with more details. In this way, when used to display scenarios with different levels of detail, the user can quickly approach a point that becomes a graph and, when the user approaches the graph, his or her points become additional graphs. to allow the user a specialized search for more details. The Graphic Editing System provides a convenient way to edit the representation of a single data point and any arbitrary representation for a data point that could be as general as the matrix scenario itself. Next, the mathematics of the holes is discussed. Holes are special objects that allow a user to observe through a window on a stage to another scenario. Figure 13 illustrates this effect and shows how a composite approach factor is calculated for the target scenario.

Figure 13 shows a hole, which is a type of hyperlink that allows the user to pass context information through the hyperlink and at the same time observe through the hyperlink to the other side. Since the other side of the hyperlink is observable, this side is transparent to the user. In Figure 13, a hole 490 is shown as a window from a first scenario 492 to a second scenario 494. The hole 490 provides information about the state, opposing a conventional hyperlink that does not have a state. From the location of a user 491, the relationships between a first elevation (elevj) 496 to the first scenario 492 and a second elevation (eleva2) 498 to the second scenario 494 can be expressed as follows: elevx = 1. Approach, scenario 1 . elev2 = Approach the stage li Approachguy In this case, each of the approach factors represents an amplification factor. In addition, the approach factors are the reciprocal values for the associated elevation parameters. For example, at a zoom factor of 100% the elevation parameter is 1, while at a zoom factor of 200%, the elevation parameter is 0.5. The hole window programs the values of the parameters that have been defined for the scenario. The hole window can also act as a type of lens that can apply amplification to the target scenario. The goal scenario of a hole can be the same as the source scenario for the recursive screen of the same scenario. This is particularly useful since an incremental zoom factor applied by the hole can be used to reduce clogging in dense data regions or alternatively provide additional amplification for increasing levels of detail. The hole has a parameter that defines the limit of recurrence in such a way that the recurrence does not continue infinitely. The user can jump through a hole in order to perform a specialized search for more information and also to activate the objects in the meta scenario. This also eliminates the effects of the incremental approach factor, as well as freeing the memory used by the objects in the first scenario. As the user navigates within a world and interacts with objects using the mouse, notification events that can trigger a behavior are generated. This behavior is determined by the designer at the time of design and consists of the following two optional steps (in order) to program the value of the scenario and / or the global parameters and execute an action. The holes provide control over the values of the parameters of the scenario through the SceneParameters object listed in the Object Inspector. The SceneParameters object is a child object of the hole and contains a property for each parameter. If the target scenario is not parameterized, the SceneParameters object may not be displayed in the Object Inspector. The values contained in the object are used to program the properties of the scenario at runtime. Three types of parameters drive the values of the execution time in the questions and also monitor and control the different variables of the user's context: global parameters, parameters of the scenario and question parameters. The global parameters are exposed in the runtime user as properties that must be programmed or monitored by the container application. In addition, built-in global parameters can be used: UserX (tracks or programs the user's current horizontal offset from the center in inches); UserY (track or program * the user's current vertical offset from the center in inches); UserZoom (tracks or programs the user's current approach (amplification level)); and UserClass (contains the name of the user's profile class). The question parameters are programmed with the data source before executing the question. The parameters of the scenario can be programmed through holes or through event actions. They have the following attributes: Name - identifier of the parameter. Type of data - type of value. Description - available for internal documentation. Implicit value - value used if it is not programmed by a child object SceneParameters from the hole or by an event action. If the implicit value is not available, the scenario can not be displayed. User classes can be used to adapt the behavior or appearance of the virtual mute based on the identity of the user. For example, a hole towards sales forecasts may be visible only to sales personnel and executive staff members, or a sketch of a hospital floor plan may highlight baccarat beds for an administrator against beds for cardiac patients. for a cardiologist. The implicit user class in all the new worlds is anonymous £. The current user class for a world is stored in the global UserClass parameter. A property value or an event method can be based on the current user class by using the IsUser property (class_name) function that returns a true or false value depending on whether the UserClass variable is a member of the user class class_name . Standard boolean expressions can also contain the UserClass parameter for direct comparison or visualization. User classes can be subclassified in order to define one more class. A subclass of the user of a class can also be a subclass of another class, which in this way results in a flexible hierarchy, of multiple inheritance of user classes. When a user class is deleted by the user and exists as a subclass of more than one user class, the user may be asked to delete all occurrences of the user's class or simply delete the selected case. Turning now to Figure 14, an object model of a hole is shown in more detail. A VcScene 500 class defines the illustration layer (frame) for all graphic objects displayed in the display area. VcScene 500 provides a set of parameters that can be referenced by the properties of the nodes contained within the scenario. Before the scenario can be provided, each parameter must be programmed in a similar way to the arguments so that a function can be defined before requesting the function. Subsequently, the hole programming node supplies the calculated schedules for each scenario parameter when the scenario is visualized through the hole. The VcScene 500 class has properties that are a member of a VcParameter 502 class and a list of nodes derived from a VcDrawingNode 504 base class. VcParameter 502 stores information about a scenario parameter, including its name and data type, while VcDrawingNode 504 is an abstract base class for all logical nodes and so that they represent the content of a scenario. VcDrawingNode 504 contains properties that can be constant or calculated. The calculated properties may depend on one or more parameters of the scenario. The abstract base class VcDrawingNode 504 in turn is inherited by a VcShapeNode 506, which is subsequently inherited by VcWormholeNode 508. VcShapeNode 506 is an abstract base class for all visible node types. Classes derived from VcShapeNode 506 implement the specific attributes and behavior of each type so. VcWormholeNode 508 is a form node class in a scenario that is bound to another scenario. It contains an indicator to a programming node to adjust the values of all the parameters of the scenario before delivering the scenario. VcWormholeNode 508 has a m_sceneParamSettings property that is a member of the VcWormholeSettingsNode 512 class. VcWormholeSettingsNode 512 is a class of the logical node that has specific hole settings for each parameter in the connection scenario. These schedules are evaluated and transmitted to the stage before being supplied to the hole. VcWormholeSettingsNode 512 is also derived from VcLogicNode 510, which in turn is derived from VcDrawingNode 504. VcLogicNode 510 is an abstract base class for nodes that defines the relationships between the shape and user nodes. Figures 15 and 16 show example uses of the hole. Figure 15 shows four holes. A portfolio risk management hole 700, a 710 market data hole, an inventions hole under consideration 720 and a first call analyst recommendation hole 730. The portfolio risk management hole 700, in turn , shows three detailed holes 702, 704 and 706 showing a view of three levels of the stage and a diagram 708. Each of the three detailed holes 702, 704 and 706 shows the financial performance associated with three separate funds of portfolios. In addition, the views of a given scenario that arise from a hole representing a phone or a wallet may be different from the views of the same scenario that arise from another hole representing a different fund. In this way, for example, when performing the specialized search of the portfolio risk management hole 700, through one of the funds 702, 704 or 706, and specialized search of a company in a particular portfolio, the information The context is accumulated with each specialized search in such a way that the resulting opinion of the company is generated in relation to the specific fund or portfolio. The information may include the amount of company stocks owned by the fund, and the duration of ownership of the company's stock, among other things. The scenario that is presented in each hole in Figure 16 is parameterized in company_ID in an analog way of an argument with a function. In this case, the scenario itself has an argument that specifies which company the user is looking for and the scenario adapts accordingly. In this way, when the user searches through any of these holes, the scenario looks different because it takes on the identity of the specific hole that is being viewed by the user. As explained above, the System provides dynamic data views without programming experience. Therefore, users move closer to the data so that the development time of the application is reduced. User interfaces can be increased quickly and easily for information-rich databases and for applications such as data storage and decision support. In addition, the limits inherent in applications based on conventional forms or applications based on reports are avoided. In addition, the techniques described herein can be implemented in hardware or software, or a combination of the two. Preferably, the techniques are implemented in computer programs that run on programmable computers where each one includes a processor, a storage medium that can be read by the processor (including volatile and non-volatile memory and / or storage elements), and suitable input and output devices. The program code is applied to the accessed data using an input device to carry out the functions described and to generate the output information. The output information is applied to one or more output devices.

Each program is preferably implemented in a programming language oriented to the object or by a high-level procedure to communicate with the computer system. However, programs can be implemented in assembly or machine language, if desired. In any case, the language can be a compiled or interpreted language. Each mentioned computer program is preferably stored in a storage medium or device (for example, CD-ROM, hard disk or magnetic floppy disk) that can be read by a programmable computer for general or special purposes, to configure and operate the computer when the means or storage device is read by the computer to carry out the described procedures. The system can also be implemented as a storage medium that can be read by the computer, configured with a computer program, where the storage medium configured in this way makes the computer operate in a specific and predefined way. Other embodiments are within the scope of the following claims.

Claims (60)

1. Claims 1. A method for executing an application expressed as a scenario graph, the scenario graph is a hierarchical representation of one or more objects, each object capable of generating a code associated with the object, which includes: traversing the hierarchy of the stage graphics; and for each object stored in the scenario graph, instruct each object to autoexecute itself.
2. 2. The method of claim 1, further including the generation of an execution image for each scenario of the scenario graph.
3. The method of claim 2, further including: recovering an octet code associated with each node of the object; store the octet code as part of the scenario; and generate the execution image of the octet code for the scenario.
4. 4. The method of claim 3, further including characterizing a node as one of several types.
5. 5 . The method of claim 4, further including determining whether the type of node is a type of form and if so: generating a form creation declaration; generate a declaration of starting property; for each property, generate a declaration to program each property associated with the object; and generate a declaration to commit each property.
6. The method of claim 4, which further includes determining whether the node type is a type of data source, and if so: generating a question from the database; determine the names of the columns for referenced identifiers; generate a declaration to create the question, - for each parameter, create a declaration to program a value of the question parameter; and generate a statement to execute the question.
7. The method of claim 3, further including supplying the image of the octet code to an execution engine.
8. The method of claim 7, further including creating an execution context for the octet code.
9. 9. The method of claim 8, which further includes eliminating the execution context.
10. The method of claim 8, further including executing each declaration in the octet code.
11. The method of claim 10, which further includes determining whether the statement is a statement of creating form, and if so: creating the form; and store the form on a context copying table using a symbolized form name.
12. The method of claim 10, which further includes determining whether the declaration is a declaration of initiating ownership, and if so: finding the form in a context copying table; and execute a startup method associated with the form.
13. The method of claim 10, which further includes determining whether the statement is a statement of scheduled property, and if so: find the form on a context copying table; evaluate an expression of property associated with the form; and assign a value to the property.
14. 14. The method of claim 10, which further includes determining whether the declaration is a declaration of ending property, and if so: finding the form on the context copying table; execute a method of ending properties associated with the way to compromise the properties; initialize the form; and add the form to a list of screens.
15. 15. The method of claim 8, further including renewing a frame associated with the shape.
16. 16. The method of claim 1, further including programming each property of the object.
17. 17. The method of claim 16, further including notifying the object before scheduling the property of the object.
18. 18. The method of claim 17, further including carrying out a series of declarations to program the property of the object.
19. 19. The method of claim 18, further including notifying the object after scheduling all object properties.
20. 20. The method of claim 19, where the scenario graph has a plurality of nodes.
21. 21. Computer software to execute an application expressed as a scenario graph, the scenario graph being a hierarchical representation of one or more objects, each object capable of generating a code associated with the object, where the computation software resides in a means that can be read by the computer and that includes instructions to make the computer perform the following operations: plot the hierarchy of the scenario graph; and for each object stored in the scenario graph, instruct each object to autoexecute itself.
22. 22. The computer software of the claim 21, which also includes instructions to generate an execution image for each stage scenario scenario.
23. 23. The computer software of the claim 22, which also includes instructions for: recovering the octet code associated with each node of the object; store the octet code as part of the scenario; and generate the execution image of the octet code for the scenario.
24. 24. The computer software of the claim 23, which also includes instructions for characterizing the node as one of several types.
25. 25. The computation software of claim 24, which further includes instructions for determining whether the type of node is a type of form and if so: generate a declaration of creation of the form; generate a declaration of starting property; for each property, generate a declaration to program each property associated with the object; and generate a declaration to commit each property.
26. 26. The computer software of the claim 24, which also includes determining if the type of node is a type of data source, and if so: generate a question from the database; determine the names of the columns for referenced identifiers; generate a statement to create the question; for each parameter, create a declaration to program a value of the question parameter; and generate a statement to execute the question.
27. 27. The computer software of the claim 23, which further includes instructions for providing the image of the octet code to an execution engine.
28. 28. The computer software of claim 27, further including instructions for creating an execution context for the octet code.
29. 29. The computer software of claim 28, which further includes instructions for eliminating the execution context.
30. 30. The computer software of claim 28, further including instructions for executing each statement in the octet code.
31. 31. The computer software of claim 30, which further includes instructions for determining whether the statement is a declaration of creating form, and if so: creating the form; and store the form on a context copying table using a symbolized form name.
32. 32. The computer software of claim 30, further including instructions for determining whether the declaration is a declaration of initiating ownership, and if so: finding the form on the context copying table; and execute a startup method associated with the form.
33. 33. The computer software of the claim 30, which also includes instructions to determine if the statement is a declaration of programming property, and if so: find the form in a context copying table; evaluate an expression of property associated with the form; and assign a value to the property.
34. 34. The computer software of claim 30, which further includes instructions for determining whether the statement is a declaration of ending ownership, and if so: finding the form on the context copying table; execute a method of ending properties associated with the way to compromise the properties; initialize the form; and add the form to a list of screens.
35. 35. The computer software of claim 28, further including instructions for renewing a frame associated with the shape.
36. 36. The computer software of claim 21, further including instructions for programming each property of the object.
37. 37. The computer software of claim 26, further including instructions for notifying the object before scheduling ownership of the object.
38. 38. The computer software of claim 27, further including instructions for carrying out a series of declarations to program the property of the object.
39. 39. The computer software of claim 28, further including instructions for notifying the object after scheduling all object properties.
40. 40. The computer software of claim 29, wherein the scenario graph has a plurality of nodes.
41. 41. An editor to visually edit the data representation, where the data has a matrix graph and one or more elements of graphical data nested recurrently in the matrix graph, which includes: a window to edit a matrix graph; and one or more specialized search windows to edit each or more of the graphical data elements nested in the matrix graph, where each of the elements of the graphical data contains a nested graph.
42. 42. The editor of claim 41, further including an attribute window associated with each of the graphic data elements.
43. 43. The editor of claim 42, wherein the attribute window is used to edit properties associated with an object implemented with a computer having an object state and one or more interfaces that provide access to the state of the object through a plurality of objects. Attributes, each attribute defined as a functional expression and referenced at runtime as a data value.
44. 44. The editor of claim 43, wherein the functional expression includes one or more of the following: a function; an operator; a column name of the database; one variable; and a constant.
45. 45. The editor of claim 43, wherein the attribute is a static data value.
46. 46. The editor of claim 43, wherein the functional expression is analyzed to generate a function that is stored as a value of the execution time.
47. 47. The editor of claim 43, further including an octet code associated with the function.
48. 48. The editor of claim 43, wherein the function is cloned and stored as a design time value if the function is a constant.
49. 49. The editor of claim 43, wherein an error message is displayed if the expression is invalid.
50. 50. The editor of claim 49, wherein it also includes an execution image associated with each scenario of the graph.
51. 51. Computer software for visually editing data representation, where the data have a matrix graph and one or more elements of the graphical data are recurrently nested in the matrix graph, the computation software resides in a medium that can be read by the computer and includes instructions to get the computer to carry out the following operations: visualize a window to avoid a matrix graphic; and generating one or more specialized search windows to edit each or more of the graphical data elements nested in the matrix graph, where each of the elements of the graphical data contains a nested graph.
52. 52. The computer software of the claim 51, which also includes a code for generating an attribute window for each of the elements of the graphic data.
53. 53. The computer software of claim 52, wherein the attribute window is used to edit properties associated with a software object having an object state and one or more interfaces that provide access to the state of the object through a plurality. of attributes, each of these attributes defined as a functional expression and referenced in the runtime as a data value.
54. 54. The computer software of claim 53, wherein the functional expression includes one or more of the following: a function; an operator; a column name of the database; one variable; and a constant.
55. 55. The computer software of claim 53, wherein the attribute is a static data value.
56. 56. The computer software of claim 53, wherein the functional expression is analyzed to generate a function that is stored as a value of the execution time.
57. 57. The computer software of claim 53, further including the code for generating the octet code associated with the function.
58. 58. The computer software of claim 53, further including the code for cloning the function and storing the function as a value of the design time if the function is a constant.
59. 59. The computer software of claim 53, which further includes the code to display an error message if the expression is invalid.
60. 60. The computer software of claim 59, which is further encoded to generate an execution image associated with each scenario of the graph.