MXPA99007845A - Dynamic properties of obje - 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 representing the world virtua1 can be executed by means of a runtime control to provide the desired information to the users.

Description

DYNAMIC PROPERTIES OF OBJECTS 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 frames, 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), in a set of operations that will be performed in 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 supports objects with dynamic properties which can be edited using a property input sheet that supports the dynamic properties. In one aspect, a computer-implemented property entry sheet for contextually assigning a property of an object associated with an application includes an attribute name section adapted to receive ownership identification; and a property introduction section adapted to receive a functional expression for the property identified by the name and attribute section, the functional expression being capable of being referred to at the runtime as a data value. Implementations of the property entry sheet may include one or more of the following. The functional expression can be a function, an operator, a database column name, a variable and / or a constant. The property entry sheet may also include a name and attribute section adapted to receive a property identification and a property introduction section adapted to receive a static value of data for the property identified by the name and attribute section. In addition, the object has a plurality of properties and wherein the name and attribute section and the property introduction section of each property form a name and value pair for each property. The functional expression can be analyzed to generate a function which is stored as a runtime value and the octet code associated with the function can be generated. The function can also be cloned and stored as a design time value if the function is a constant. Additionally, an error message may be displayed and an existing octet code execution image may be invalidated and a new octet code generated to replace the existing octet code execution image if the expression is invalid. In another aspect, a method for assigning a property of an object associated with an application includes the reception of an expression in a property input section of the property entry page, the expression being able to be referred to at runtime as a value of data; the analysis of the expression; the generation of the expression of a function; and storing the function as a runtime value. Implementations of the invention include the following.

The method may invalidate the execution image of the octet code of the object. The method can also determine if a representation of the object's runtime is updated automatically and, if so, the method can generate and execute the octet code. The method can also change an attribute of the object by determining which property of the object represents the changed attribute; creating a constant function representing the value of the changed attribute; storing the constant function as a runtime property value and a design time property value. When the object has an execution image in octet code, the method can invalidate the execution image in octet code and can also determine if a representation of the object's runtime is automatically updated and, if so, the code of the object. octets is generated and executed. The method can also clone and store the function as a design time value if the function is a constant. In another aspect, an object increased by computer is provided with an object state and one or more interfaces that give access to the object state through a plurality of attributes, each of the attributes defined as a functional expression and capable of being referred to at runtime as a data value. The implementations of the object include the following. The functional expression of the object includes a function, an operator, a database column name, a variable and / or a constant. In addition, the attribute can be a static data value. Each property can have a pair of name and value. The functional expression of the object can be analyzed to generate a function which is stored as a runtime value. The function can be cloned and stored as a design time value if the function is a constant. Furthermore, in the event that the expression is invalid, an error message is displayed, the execution image in existing octet code is invalidated and the new octet code is generated to replace the existing octet code execution image. 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 brought 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 hole. Figure 14 is a diagram of an object model of a needle. 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 can 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 peters, 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 & 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 their drawing order. 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 box 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 2 EditorType: WorldName [. ExtendedContents], Where -EditorType is the type of editor ("Scenario", "Data 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 long name for the object that is edited that includes the symbolized names of all parent objects, separated by periods (for example, "Scenel. ScatterChartl." can be opened More than one editor window for a particular part of a world, for example, the same scenario can be edited in an editor in a 100% amplification to see the whole scenario, while another editor can be approached to a smaller portion of the A scenario change in any editor can be reflected in both windows.The scenario editor window is used to graphically edit and debug the content of a higher level scenario.The editor has two modes: a mode of design 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 toggle 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 port to the other with a resulting "rubber 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 parameterization 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 a scenario or question parameters are set to a parameter or column higher in the hierarchy, the text box of the parameter is "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 the brackets ('[' and x] ') denote optional text and vertical separations (|') denote alternatives. Global parameter format DataType ParamName [(Incorporated)] Description: Description Implicit value: (None) | Access Value: [Private | Public] Format of user classes ClassName Parent classes: (None) | 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] = valueor [(ColorNameo)] ColorseqName [N-l] = valueN-1 [(ColorNameN-1)] Stock image format: ImageName Format: [Bitmap | indows Metafile | JPEG] Format of database connections: ConnectionName Server: Server Database: Database User: User Implicit scheme: Format of data sources: DataSourceName [(DataType paraml, ...)] Connection: Connect ionName SQL: SQL Scenario format: Scene? Ame [(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 to 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 - Used to present a series of information. Maps - used to design multiple curves or series of information within a single data source. Hierarchies - used to show object dependencies. Patterns - used to design independent objects in an ordered pattern. Forms - used to display a single record in a data source (if the data source results in more than one row, the subsequent rows are ignored. Sketches can be placed anywhere in a scenario or drawing of data elements. Some sketch types 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 to be presented at larger approach levels. The axis nodes are attached to the sketches that require them. For some types of tables such as tables of bars 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 in this way they can be linked to the data. The axes that can be supported include 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 property expressions result in one of the following base data types: Boolean, numeric, string, pointList, 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 coupled and both vertically and horizontally when 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 "point" is used to denote compound objects. For example, "ScatterChartl .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, Bottom Left, Top 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 object of property 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_designValue 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 a 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. Finally, 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 of so 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 Figure 4. Figure 4 shows the execution of an octet code VcStmtCreateShape of example 302. The octet code 302 creates a case of an object in particular form at the time of its execution and records a symbolized name for the object for a copy table display. 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 of VcStmtSetStringProperty 326 that sets 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 octet code VcStmtSetStringProperty 326 is shown in block 330. In this implementation for programming the property of a form, when the VcStmtSetStringProperty 's Perform () method is requested, the form 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 function VcStmtSetStringProperty 350. The function 350 has an identification value of the object "Textl" 352, which is a member of the class Cstring. 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_name"), 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_name". The evaluation of the constant function 370 results in a character string that is a space (the string constant "") 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 searching 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 list m_nodes of objects derived from the class VcDrawingNode 402. VcDrawingNode 402 is an abstract base class for all logical nodes and so that they represent the content of a scenario. VcDrawingNode 402 defines an interface, GetExecStmts (), to generate the list of 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 a class of 'VcLogicNode 408 illustration node, 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 data source. 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 VcQuer DataSource 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. VcStmtCxeateShape 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. By last, 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 an indicator 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 obtains 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). Next, 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 copying 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. The image 485 is shown in the 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 (elevi) 496 to the first scenario 492 and a second elevation (elev2) 498 to the second scenario 494 can be expressed as follows: eleVi = 1 Approach, scenario 1 elev2 = Acer cami ent oesCenio rio Ac e r c ami ento, agu3 ero 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, in a zoom factor of 100% the elevation parameter is 1, while in a zoom factor of 200%, the elevation parameter is The window of the hole program 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 meta scenario.The goal scenario of a hole can be be the same as the source scenario for the recursive screen of the same scenario.This is particularly useful since an incremental approach 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 recurrence limit of such a form that 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 frees up 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): 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 (tracks or programs 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 of form. 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 form nodes and the user. Figures 15 and 16 show example uses of the hole. Figure 15 shows four holes. A portfolio risk management hole 700, a market data hole 710, a 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 stage levels and a 708 diagram. Each of the three detailed holes 702, 704 and 706 show the financial performance associated with three separate portfolio funds. 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 length 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 here 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 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 (51)

1. CLAIMS: 1. A property input sheet implemented by computer to contextually assign a property of an object associated with an application, comprising: A section of attribute name adapted to receive an identification of the property; and A property introduction section adapted to receive a functional expression for the property identified by the name and attribute section, the functional expression being capable of being referenced at runtime as a data value.
2. 2. The property entry sheet of claim 1, wherein the functional expression includes one or more of the following: A function; An operator; A database column name; A variable; and A constant.
3. 3. The property entry sheet of claim 1, further comprising: A section of attribute name adapted to receive an identification of the property; and A property introduction section adapted to receive a static value of data for the property identified by the name and attribute section.
4. 4. The property entry sheet of claim 1, wherein the object has a plurality of properties and wherein the section the name and attribute section and the property introduction section of each property form a name and value pair for each property.
5. 5. The property entry sheet of claim 1, wherein the functional expression is analyzed to generate a function which is stored as a time-of-execution value.
6. 6. The property entry sheet of claim 5, further comprising the octet code "associated with the function
7. 7. The property entry sheet of claim 1, wherein the function is cloned and stored as a value. of design time if the function is a constant
8. 8. The property input sheet of claim 1, wherein an error message is shown if the expression is invalid.
9. 9. The property entry sheet of claim 1, wherein an execution image of the existing octet code is invalidated.
10. 10. The property entry sheet of claim 9, wherein the new octet code is generated to replace the execution image of the existing octet code 11.
11. A method for editing an object implemented by computer, the object having a sheet Property input to assign a property of an object associated with an application, comprising: Receiving an expression in a property entry section of the property entry sheet, the expression being able to be referenced in the execution time as a data value; The analysis of the expression; The generation of the expression of a function; and The storage of the function as a runtime value.
12. The method of claim 11, wherein the object has an execution image of the octet code, further comprising the step of invalidating the execution image of the octet code.
13. The method of claim 11, further comprising the step of determining whether a runtime representation of the object is automatically updated and, if so, the steps of generating and executing the octet code.
14. The method of claim 11, further comprising the step of changing an attribute of the object.
15. The method of claim 14, further comprising: determining which object property the changed attribute plans; Create a constant function representing the changed attribute value; Store the constant function as a runtime property value and a design time property value.
16. 16. The method of claim 14, wherein the object has an octet code execution image, further comprising the step of invalidating the octet code execution image.
17. 17. The method of claim 14, which also includes the step of determining if an execution time representation of the object is automatically updated, and thus, the steps of generating and executing the octet code.
18. The method of claim 11, further comprising the steps of cloning and storing the function as a design time value if the function is a constant.
19. The method of claim 11, further comprising the step of displaying an error message if the expression is invalid.
20. The method of claim 11, further comprising the step of invalidating an execution image of the existing octet code and the step of replacing the execution image of the existing octet code with a new execution image of the associated octet code. with the function.
21. 21. A method implemented by computer to assign a property to an object, the object having a value input adapted to receive a functional expression for the property, the functional expression being able to be referenced in the runtime as a data value , the method comprising: The step of receiving an expression for the property in the value entry; The step of analyzing the expression and storing the expression as a function; and The step of evaluating the expression at runtime in the context to generate a data value capable of being referenced for the property.
22. 22. The method of claim 21, wherein the step of analyzing the expression identifies one or more of the following: A function; An operator; A database column name; A variable; and A constant.
23. The method of claim 21, further comprising: The step of receiving an identification of the property in an attribute name section; and The step of receiving a static data value for the property identified by the name and attribute section in a property introduction section.
24. 24. The method of claim 21, wherein the object has a plurality of properties and wherein the attribute name section and the property introduction section of each property form a name and value pair for each property.
25. 25. The method of claim 21, further comprising the step of analyzing the functional expression to generate a function which is stored as a time-of-execution value.
26. 26. The method of claim 25, further comprising the step of associating an octet code with the function.
27. The method of claim 24, further comprising the step of determining whether a runtime representation of the object is automatically updated, and, if so, the steps of generating and executing the octet code.
28. The method of claim 21, further comprising the steps of cloning and storing the function as a design time value if the function is a constant.
29. 29. The method of claim 21, further comprising the step of displaying an error message if the expression is invalid.
30. The method of claim 21, further comprising the step of invalidating an execution image of the existing octet code and the step of replacing the execution image of the existing octet code with a new execution image of the associated octet code. with the function.
31. 31. - - An object implemented by computer, comprising: An object state; and One or more interfaces providing access to the object state through a plurality of attributes, each of the attributes defined as a functional expression and capable of being referred to at runtime as a data value.
32. 32. The object of claim 31, wherein the functional expression includes one or more of the following: A function; An operator; A database column name; A variable; and A constant.
33. 33. The object of claim 31, wherein the attribute is a static data value.
34. 34. The object of claim 31, further comprising a pair of name and value for each property.
35. 35. The object of claim 31, wherein the functional expression is analyzed to generate a function which is stored as a runtime value.
36. 36. The object of claim 35, further comprising the octet code associated with the function.
37. 37. The object of claim 31, wherein the function is cloned and stored as a design time value if the function is a constant.
38. 38. The object of claim 31, wherein an error message is shown if the expression is invalid.
39. 39. The object of claim 31, wherein an execution image of the existing octet code is invalidated.
40. 40. The object of claim 39, wherein a new octet code is generated to replace the execution image of the existing octet code.
41. 41. A computer system comprising: A processor; A memory device coupled to the processor; A screen coupled to the processor; A data storage device coupled to process to store an object implemented by computer, including: An object state; and One or more interfaces providing access to the object state through a plurality of attributes, each of the attributes defined as a functional expression and capable of being referred to at runtime as a data value.
42. 42. The computer system of claim 41, wherein the functional expression includes one or more of the following: A function; An operator; A database column name; A variable; and A constant.
43. 43. The computer system of claim 41, wherein the attribute is a static data value.
44. 44. The computer system of claim 41, further comprising a pair of name and value for each property.
45. 45. The computer system of claim 41, wherein the functional expression is analyzed to generate a function which is stored as a runtime value.
46. 46. The computer system of claim 45, further comprising the octet code associated with the function.
47. 47. The computer system of claim 41, wherein the function is cloned and stored as a design time value if the function is a constant.
48. 48. The computer system of claim 41, wherein an error message is displayed if the expression is invalid.
49. 49. The computer system of claim 41, wherein an execution image of the existing octet code is invalidated.
50. 50. The computer system of claim 49, wherein a new octet code is generated to replace the execution image of the existing octet code.
51. 51. Computer software to assign a property to an object, the object having an input of value adapted to receive a functional expression for the property, the functional expression being able to be referred to in the execution time as a data value, the computer software residing in a computer-readable medium and comprising instructions for making a computer perform the following operations: Receive an expression for the property in the value entry; Analyze the expression and store the expression as a function; and Evaluate the expression in the execution time in the context to generate a data value capable of being referenced for the property.