Declarative specification of model visualizations

Techniques for generating a visual representation for a model representation in a manner whereby the model representation is not coupled to the visual representation. An abstract representation is generated based upon the model representation. Mapping rules are configured and used for generating the abstract representation from the model representation. A visual representation is then generated based upon the abstract representation.

1. A method performed by a computer of generating a visual representation for a model representation, the method comprising:

identifying a set of one or more model elements in the model representation;

automatically generating at a data processing system an abstract representation for the model representation using a set of mapping rules, each mapping rule in the set of mapping rules providing a mapping of a model element type to a visual element type, the abstract representation comprising a set of one or more visual elements and associated one or more properties, the set of visual elements determined based upon the set of model elements and the set of mapping rules;

automatically generating a first visual representation for a first graphics engine, the first graphics engine being a first type of graphics engine, based upon the abstract representation, the first visual representation comprising a set of one or more graphic elements determined based upon (i) the set of visual elements and their associated properties and (ii) the first type of graphics engine;

displaying the first visual representation to a first user via a first output device;

automatically generating a second visual representation for a second graphics engine, the second graphics engine being a second type of graphics engine distinct from the first type, based upon the abstract representation, the second visual representation comprising a set of one or more graphic elements determined based upon (i) the set of visual elements and their associated properties and (ii) the second type of graphics engine, at least one of the graphic elements in the second visual representation being different than at least one of the graphic elements in the first visual representation because of a difference in graphical ability between the first and second types of graphics engines; and

wherein automatically generating the first abstract representation comprises:

identifying a first model element of a first type from the set of model elements;

automatically determining a first mapping rule from the set of mapping rules that maps the first type to a first visual element type; and

automatically creating a visual element of the first visual element type identified by the first mapping rule for the first model element.

2. The method of claim 1 further comprising:

receiving user input indicating a change to the first visual representation;

making a change to the abstract representation to reflect the change to the first visual representation; and

updating the second visual representation based on the change to the abstract representation.

3. The method of claim 2 farther comprising:

making a change to the model representation based upon the change made to the abstract representation to reflect the change made to the first visual representation.

4. The method of claim 1 wherein the set of mapping rules that is used to generate the abstract representation depends upon a type of the model representation.

5. The method of claim 1 wherein generating the first visual representation comprises:

determining one or more graphic elements for a first visual element from the set of visual elements based upon a type of the first visual element and one or more properties associated with the first visual element.

6. The method of claim 1 wherein generating the first visual representation comprises:

determining the first type of graphics engine associated with the first output device for outputting the first visual representation.

7. The method of claim 6 wherein the first type of graphics engine is at least one of a scalable vector graphics engine, a vector graphics rendering engine, or a Graphic Editing Framework engine.

8. A method performed by a tool executing on a computer system, the method comprising:

receiving input identifying a model representation;

processing the model representation to identify a set of one or more model elements;

determining a set of mapping rules to be used for the model representation, each mapping rule in the set of mapping rules providing a mapping of a model element type to a pictogram type;

automatically mapping at the computer system each model element in the set of model elements to a pictogram using the set of mapping rules to generate a set of one or more pictograms;

setting one or more properties associated with the one or more pictograms in the set of pictograms;

generating a first visual representation to be displayed via a first type of graphics engine, based upon the set of pictograms and their associated properties, the first visual representation comprising a set of one or more graphic elements;

outputting a signal associated with the first visual representation to a first user display device;

generating a second visual representation to be displayed via a second type of graphics engine, based upon the set of pictograms and their associated properties, the second visual representation comprising a set of one or more graphic elements; and

outputting a signal associated with the second visual representation to a second user display device, at least one of the graphic elements in the second visual representation being different than at least one of the graphic elements in the first visual representation because of a difference in graphical ability between the first and second types of graphics engines; and

wherein automatically generating the first abstract representation comprises:

identifying a first model element of a first type from the set of model elements;

automatically determining a first mapping rule from the set of mapping rules that maps the first type to a first visual element type; and

automatically creating a visual element of the first visual element type identified by the first mapping rule for the first model element.

9. The method of claim 8 wherein generating the first visual representation comprises:

determining the first type graphics engine; and

generating the first visual representation based upon the first type of graphics engine.

10. A system for generating visual representations for a model representation, the system comprising:

a memory storing a set of one or more mapping rules, the set of mapping rules mapping of a set of model element types to a set of visual element types;

an output port coupled to the processing engine to provide one of the first and second visual representations to a display monitor; and

wherein automatically generating the first abstract representation comprises;

Identifying a first model element of a first type from the set of model elements;

automatically determining a first mapping rule from the set of mapping rules that maps the first type to a first visual element type; and

automatically creating a visual element of the first visual element type identified by the first mapping rule for the first model element.

11. The system of claim 10 wherein the processing engine is further configured to:

receive user input indicating a change to the first visual representation; and

make a change to the abstract representation to reflect the change to the first visual representation.

12. The system of claim 11 wherein the processing engine is further configured to:

make a change to the model representation based upon the change made to the abstract representation to reflect the change made to the first visual representation.

13. The system of claim 10 wherein the set of mapping rules that is used by the processing engine to generate the abstract representation depends upon a type of the model representation.

14. The system of claim 10 wherein the processing engine is configured to generate the first visual representation by:

determining one or more graphic elements for a first visual element from the set of visual elements based upon a type of the first visual element and one or more properties associated with the first visual element.

15. The system of claim 10 wherein the processing engine is configured to generate the first visual representation by:

determining the first type graphics engine for outputting the first visual representation; and

generating the first visual representation based upon the first type of graphics engine.

16. The system of claim 15 wherein the first type of graphics engine is at least one of a scalable vector graphics engine, a vector graphics rendering engine, or a Graphic Editing Framework engine.

17. A system for generating visual representations, the system comprising:

an input device;

a processing engine coupled to the input device, the processing engine configured to:

receive input via the input device identifying a model representation;

process the model representation to identify a set of one or more model elements;

determine a set of mapping rules to be used for the model representation, each mapping rule in the set of mapping rules providing a mapping of a model element type to a pictogram type,

a processing engine coupled to the memory, the processing engine configured to:

identify a set of one or more model elements in the model representation; generate an abstract representation for the model representation using the set of mapping rules, the abstract representation comprising a set of one or more visual elements and associated one or more properties, the set of visual elements determined based upon the set of model elements and the set of mapping rules;

generate a first visual representation based upon the abstract representation, the first visual representation being generated for a first type of graphics engine and comprising a set of one or more graphic elements determined based upon (i) the set of visual elements and their associated properties and (ii) the first type of graphics engine; and

generate a second visual representation based upon the abstract representation, the second visual representation being generated for a second type of graphics engine, different than the first type of graphics engine, and comprising a set of one or more graphic elements determined based upon (i) the set of visual elements and their associated properties and (ii) the second type of graphics engine, at least one of the graphic elements in the second visual representation being different than at least one of the graphic elements in the first visual representation because of a difference in graphical ability between the first and second types of graphics engines; and

map each model element in the set of model elements to a pictogram using the set of mapping rules to generate a set of one or more pictograms;

set one or more properties associated with the one or more pictograms in the set of pictograms;

generate a first visual representation to be displayed via a first type of graphics engine, based upon the set of pictograms and their associated properties, the first visual representation comprising a set of one or more graphic elements; and

generate a second visual representation to be displayed via a second type of graphics engine, based upon the set of pictograms and their associated properties, the second visual representation comprising a set of one or more graphic elements, at least one of the graphic elements in the second visual representation being different than at least one of the graphic elements in the first visual representation because of a difference in graphical ability between the first and second types of graphics engines; and

an output port coupled to the processor to provide a signal associated with the first visual representation; and

wherein automatically generating the first abstract representation comprises:

Identifying a first model element of a first type from the set of model elements;

automatically determining a first mapping rule from the set of mapping rules that maps the first type to a first visual element type; and

automatically creating a visual element of the first visual element type identified by the first mapping rule for the first model element.

18. The system of claim 17 wherein the processing engine generates the first visual representation by:

determining the first type graphics engine for outputting the first visual representation; and

generating the first visual representation based upon the first type of graphics engine.

19. The system of claim 17 further comprising an output device coupled to the output port and configured to receive the signal associated with the first visual representation and to display the first visual representation.

20. A storage subsystem storing a plurality of instructions for controlling a data processor to generate visual representations for a model representation, the plurality of instructions comprising:

instructions that cause the data processor to identify a set of one or more model elements in the model representation;

instructions that cause the data processor to automatically generate an abstract representation for the model representation using a set of mapping rules, each mapping rule in the set of mapping rules providing a mapping of a model element type to a visual element type, the abstract representation comprising a set of one or more visual elements and associated one or more properties, the set of visual elements determined based upon the set of model elements and the set of mapping rules;

instructions that cause the data processor to automatically generate a first visual representation for a first type of graphics engine based upon the abstract representation, the first visual representation comprising a set of one or more graphic elements determined based upon (i) the set of visual elements and their associated properties and (ii) the first type of graphics engine;

instructions that cause the data processor to automatically generate a second visual representation for a second type of graphics engine, different than the first type of graphics based upon the abstract representation, the second visual representation comprising a set of one or more graphic elements determined based upon (i) the set of visual elements and their associated properties and (ii) the second type of graphics engine, at least one of the graphic elements in the second visual representation being different than at least one of the graphic elements in the first visual representation because of a difference in graphical ability between the first and second types of graphics engines; and

instructions that cause the data processor to output a signal associated with the first visual representation; and

wherein automatically generating the first abstract representation comprises:

identifying a first model element of a first type from the set of model elements;

automatically determining a first mapping rule from the set of mapping rules that maps the first type to a first visual element type; and

automatically creating a visual element of the first visual element type identified by the first mapping rule for the first model element.

21. A storage subsystem storing a plurality of instructions for controlling a data processor to generate visual representations, the plurality of instructions comprising:

instructions that cause the data processor to receive input identifying a model representation;

instructions that cause the data processor to process the model representation to identify a set of one or more model elements;

instructions that cause the data processor to determine a set of mapping rules to be used for the model representation, each mapping rule in the set of mapping rules providing a mapping of a model element type to a pictogram type;

instructions that cause the data processor to map each model element in the set of model elements to a pictogram using the set of mapping rules to generate a set of one or more pictograms;

instructions that cause the data processor to set one or more properties associated with the one or more pictograms in the set of pictograms;

instructions that cause the data processor to generate a first visual representation for a first type of graphics engine based upon the set of pictograms and their associated properties, the first visual representation comprising a first set of one or more graphic elements; and

instructions that cause the data processor to generate a second visual representation for a second type of graphics engine, of a type different than the first type of graphics engine, based upon the set of pictograms and their associated properties, the second visual representation comprising a second set of one or more graphic elements, wherein the second set of one or more graphic elements includes at least one graphic element not included in the first set because of a difference in graphical ability between the first and second types of graphics engines; and

wherein automatically generating the first abstract representation comprises:

identifying a first model element of a first type from the set of model elements;

automatically determining a first mapping rule from the set of mapping rules that maps the first type to a first visual element type; and

automatically creating a visual element of the first visual element type identified by the first mapping rule for the first model element.

The present invention relates to visualization of models, and more specifically to techniques for declaratively mapping a canonic model representation to one or more visual representations.

In the computing domain, information is commonly stored in the form of models. For example, a particular model may be used to store information for an application. The model may store information related to various entities or components of the application, information describing inputs or outputs of the components, information describing dependencies between the various components and their input and outputs, a component's response to signals, and other information for the application. The model that is used for storing information for an application may be configured by a designer of the application after taking into consideration various factors such as the domain in which the application is to be used, the memory resources available for storing the information, the computing resources available for processing the model, tools to be used for manipulating the model, and other factors. A model representation (also referred to as canonic model representation) thus provides a convenient way to persist information for an application in a machine-readable representation.

While a canonic model representation is the preferred form in which models are persisted and manipulated by software tools, it is not very well suited for human users, due to its usually technically verbose nature. Therefore, a model representation is usually transformed to a visual representation and the visual representation output to the user. The user may use the visual representation to comprehend the model information and also to manipulate or make changes. The visual representation thus provides a visual interface through which the user perceives and manipulates the model representation.

The transformation from a canonical model representation to a visual representation is usually performed by visualization tools (e.g., design tools) used by the user. These transformations depend on the graphics engine used by the tool to render the visual representation, on the characteristics of the output device used to output or display the visual representation, and other factors that are specific to the manner in which the visual representation will be displayed to the user.

Conventionally, such transformations from the model representation to the visual representation are hard-coded into the visualization tool implementation. The model representation is thus tightly coupled to the graphics engine of the renderer and the output device. Due to this tight coupling, many times, different model representations have to be provided for different renderers. As a result, it becomes very difficult to evolve visual representations to meet changing design-time needs, or to migrate visual representations between different visualization tools.

Embodiments of the present invention provide techniques for generating a visual representation for a model representation in a manner whereby the model representation is not coupled to the visual representation. An abstract representation is generated based upon the model representation. Mapping rules are configured and used for generating the abstract representation from the model representation. A visual representation is then generated based upon the abstract representation.

According to an embodiment of the present invention, techniques are provided for generating a visual representation for a model representation. A set of one or more model elements may be identified in the model representation. An abstract representation may be generated for the model representation using a set of mapping rules, each mapping rule in the set of mapping rules providing a mapping of a model element type to a visual element type. The abstract representation may comprise a set of one or more visual elements and associated one or more properties, the set of visual elements determined based upon the set of model elements and the set of mapping rules. A first visual representation may be generated based upon the abstract representation, the first visual representation comprising a set of one or more graphic elements determined based upon the set of visual elements and their associated properties.

According to an embodiment, the abstract representation may be generated by identifying a first model element of a first type from the set of model elements, determining a first mapping rule from the set of mapping rules that maps the first type to a first visual element type, and creating a visual element of the first visual element type identified by the first mapping rule for the first model element.

In one embodiment, user input may be received indicating a change to the first visual representation. A change may be made to the abstract representation to reflect the change to the first visual representation. A change may also be made to the model representation based upon the change made to the abstract representation to reflect the change made to the first visual representation.

Different visual representations may be generated for different graphics engines. For example, a first visual representation may be generated for a first graphics engine using an abstract representation. The same abstract representation may be used to generate a second visual representation for a second graphics engine, wherein the second graphics engine is distinct from the first graphics engine. Generating the first visual representation may comprise determining one or more graphic elements for a first visual element from the set of visual elements based upon a type of the first visual element and one or more properties associated with the first visual element. Generating the first visual representation may comprise determining a graphics engine for outputting the first visual representation, and generating the first visual representation based upon the graphics engine. Examples of graphics engines include a scalable vector graphics engine, a vector graphics rendering engine, a Graphic Editing Framework engine, a Java2D graphics engine, a Flash graphics engine, an OpenGL graphics engine, and others.

The set of mapping rules that is used to generate the abstract representation may depend upon a type of the model representation. For example, a first set of mapping rules may be used for generating an abstract representation for a first type of model representation and a second set of mapping rules that are different from the first set of mapping rules may be used for generating the abstract representation for a second type of model representation.

According to an embodiment of the present invention, techniques are provided for generating visual representation where input is received identifying a model representation. The model representation may be processed to identify a set of one or more model elements. A set of mapping rules to be used for the model representation may be determined. Each mapping rule in the set of mapping rules may provide a mapping of a model element type to a pictogram type. Each model element in the set of model elements may be mapped to a pictogram using the set of mapping rules to generate a set of one or more pictograms. One or more properties associated with the one or more pictograms in the set of pictograms may be set. A visual representation may be generated based upon the set of pictograms and their associated properties, the visual representation comprising a set of one or more graphic elements. The visual representation that is generated may be output.

The foregoing, together with other features, embodiments, and advantages of the present invention, will become more apparent when referring to the following specification, claims, and accompanying drawings.

In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of the invention. However, it will be apparent that the invention may be practiced without these specific details.

Embodiments of the present invention provide techniques for generating a visual representation for a model representation in a manner whereby the model representation is not coupled to the visual representation. FIG. 1 depicts a simplified environment 100 in which an embodiment of the present invention may be used. As depicted in FIG. 1, a model representation 102 may be provided storing information for an application. Model representation 102 may be a machine-readable representation of an application or domain specific model. Model representation provides a form in which a model(s) is persisted and transported, and possibly handled by various tools such as code generators, runtime interpreters, analysis and validation tools, merge tools, and the like. In one embodiment, model representation 102 may be a collection of XML document with a well-formed syntax. Model representation 102 may have been generated using one or more modeling tools 104. Examples of modeling tools include Visual Composer provided by SAP AG of Germany, Rational Rose, Borland Together, Microsoft Visio, and others.

As previously described, a model representation is typically not very well suited for human users, due to its usually technically verbose nature. Accordingly, a visual representation 106 is usually generated for model representation 102 and possibly displayed using output device 108. Visual representation 106 represents a human-readable representation of the model representation and typically comprises a collection of graphical elements (also referred to as graphic primitives) such as boxes, circles, lines, etc. Visual representation is the form in which model representation 102 is presented to the user and possibly edited by the user. The visual representation enables the user to manipulate the manner in an intuitive manner.

According to the teachings of the present invention, model representation 102 is decoupled from visual representation 106 by providing an abstract representation 110. According to the teachings of the present invention, when a visual representation 106 is to be generated for a model representation 102, the model representation is first transformed into abstract representation 110 which is then used to generate visual representation 106. For example, a user may use a visualization tool 112 (e.g., a design tool) executing on a data processing system 114 to select a model representation and request display of a visual representation corresponding to the model representation. In response, the visualization tool may be configured to generate abstract representation 110 from model representation 102 and then use abstract representation 110 to generate visual representation 106 which may then be displayed or output to the user via output device 108. The generation of graphic primitives for visual representation 106 may depend on various factors such as graphics engine 116 used for rendering the visual representation, characteristics of output device 108, the target platform, and other factors. In some embodiments, the same tool may be used as the modeling tool and the visualization tool. An example of such as tool is Visual Composer provided by SAP. The abstract representation may also be generated by other entities/components other than tool 112.

Since the visual representation is generated based upon abstract representation 110 rather than model representation 102, the model representation 102 is decoupled from visual representation 106. The model representation itself may be of various forms or types depending on the tool/language used for the modeling. These various different model representations may be mapped to the abstract representation. Mapping rules may be provided for mapping a model representation to an abstract representation. Different mapping rules may be provided for mapping the various model representations to an abstract representation. As previously described, after an abstract representation has been generated for a model representation, the visual representation is generated based upon the abstract representation. Rules may be provided for converting an abstract representation to a particular type of visual representation, where the type of visual representation may depend on the graphics engine used for the rendering, characteristics of the output device, and other factors.

FIG. 2 depicts a process for mapping a model representation to a visual representation according to an embodiment of the present invention. Model representation 102 may comprise one or more model elements. Abstract representation 110 comprises one or more abstract visual elements (also referred to as pictograms) and properties associated with the abstract visual elements or pictograms. Visual representation 106 comprises one or more graphic elements or primitives such as boxes, circles, lines, etc. The graphic primitives generally depend on the graphics engine used for rendering the visual representation, the target platform, and characteristics of the output device.

As depicted in FIG. 2, the model elements of model representation 102 are mapped into abstract visual elements or pictograms using a topological transformation. The pictograms are then mapped into concrete graphic elements or primitives (e.g., boxes, lines) that make up the visual representation using a geometrical transformation. The mapping also works in the opposite direction. For example, low-level events triggered by the graphic primitives are captured by the abstract pictograms and transformed into generic model events that are used to update model representation 102. Accordingly, changes to the visual representation may be mapped back to the model representation.

The abstract representation comprising the pictograms thus creates an abstraction layer that decouples the model representation from the visual representation. Consequently, the model representation is no longer tied to or dependent on the graphics engine (such as Scalable Vector Graphics (SVG), vector graphics rendering (sometimes referred to as VML), Graphic Editing Framework (GEF) from Eclipse, Java2D, Flash, OpenGL, etc.) that is used to render the visual representation. The abstract representation can thus be ported between different design tool implementations. The same abstract representation may be used for different visual representations. The abstract representation also shields model designers from having to learn the intricate ins and outs of graphic engines. The model representation is no longer tied to the target platform or characteristics of the output device. By using only a small number of abstract pictograms, together with simple visual mapping rules, it is possible to produce virtually all the visual representations accepted in the industry today, such as Unified Modeling Language (UML), Visual Composition Language (VCL), entity-relationship diagrams (ERD), Business Process Execution Language (BPEL), Realtime Object-Oriented Modeling (ROOM), and others.

The pictograms encapsulate both appearance and behavior. Therefore, by mapping model elements to pictograms, one does not only specify how the elements will look like in the visual representation, but also how they will behave in reaction to events such as user gestures such as clicking, dragging, scrolling, etc.

FIG. 3 depicts a simplified high-level flowchart 300 showing a method for generating a visual representation for a model representation according to an embodiment of the present invention. The processing depicted in FIG. 3 or a portion thereof may be performed by software (code modules or instructions) executed by a processor, hardware modules, or combinations thereof. Flowchart 300 depicted in FIG. 3 is merely illustrative of an embodiment of the present invention and is not intended to limit the scope of the present invention. Other variations, modifications, and alternatives are also within the scope of the present invention. The method depicted in FIG. 3 may be adapted to work with different implementation constraints.

As depicted in FIG. 3, processing may be initiated when a signal is received to generate a visual representation for a model representation (step 302). The signal may be generated for example when a user using a tool, such as Visual Composer provided by SAP, selects a particular model and requests information from the model to be displayed. Various other actions may also generate the signal in 302.

Visual mapping rules are then used to generate an abstract representation from the model representation using a topology transform, the abstract representation comprising abstract visual elements (also referred to as pictograms) and their associated properties (step 304). According to an embodiment of the present invention, as part of 304, one or more model elements are determined from the model representation. The visual mapping rules are then used to map the one or more model elements to one or more abstract visual elements (or pictograms) and set their associated properties.

The visual mapping rules specify the mapping between a model representation to an abstract representation. According to an embodiment of the present invention, visual mapping rules specify a mapping of model elements from a model representation to pictograms in the abstract representation. Each model element is mapped to a pictogram and appropriate properties set for the pictogram based upon the properties or attributes of the model element. One or more model elements may be mapped to a particular pictogram. Since multiple model elements may be mapped to the same pictogram, a relatively small number of pictograms may be used to generate the abstract representation for a model representation. Since there may be different types of model representations, different sets of visual mapping rules may be provided for mapping the model representation to the abstract representation (e.g., to map their corresponding model elements to pictograms).

According to an embodiment of the present invention, a visual mapping rule provides a mapping between a type of model element to a type of pictogram. Accordingly, in 304, when a particular model element of a particular type is identified in the model representation, a visual mapping rule that maps the particular type of model element to a particular type of pictogram is determined. The determined visual mapping rule is then used to map the model element to the pictogram of the particular type.

A visual representation is then generated based upon the abstract representation generated in 304 (step 306). In one embodiment, the abstract representation generated in 304 is mapped to a visual representation by applying geometrical transforms. As part of 306, a geometrical transform is applied to each pictogram determined in 304 to generate one or more graphic elements or primitives that make up the visual representation. The geometrical transformation process is also called rendering, and it largely depends on the graphics engine and the characteristics of the target display device. Typically, each pictogram is transformed into a set of one or more graphic elements or primitives according to the pictogram's type and properties. For example, in the Visual Composer tool from SAP, the rendering phase is implemented using the SVG graphics engine. Other design tools may be implemented using other graphic engines and thus may use different geometrical transformations, but the end result is usually substantially the same. Accordingly, as part of the processing performed in 306, the graphics engine to be used to output the visual representation is determined and the visual representation generated based upon and for that graphics engine. It is not expected or required that all geometric transformations produce exactly the same results, because the graphic engines usually differ on qualities such as geometric precision, anti-aliasing optimizations, text legibility, rendering speed, etc.

The visual representation generated in 306 may then be output to the user using an output device (step 308). For example, the visual representation may be displayed to the user on an output device such as a monitor. The visual representation may also be provided to other applications that may display the visual representation or use the visual representation for further processing.

The processing depicted in FIG. 3 and the features of embodiments of the present invention may be illustrated using an example based on the Visual Composer tool provided by SAP. It should be understood that the example described below is not intended to limit the scope of the invention as recited in the claims.

FIG. 4 depicts a sample Visual Composer based model representation unit written in a particular modeling language called Visual Composition Language (VCL) according to an embodiment of the present invention. The example below describes how this model representation is mapped into a visual representation that can be displayed in Visual Composer. It should be understood that the same principles may also be applied to any other model or visual representation that are employed by other design or display tools.

The model representation depicted in FIG. 4 comprises a number of model elements. Each model element in FIG. 4 is an instance of a corresponding VCL meta-model class. For instance: element 402 “Scenario T” (id=BV) is an instance of class “gml:ScenarioUsage”, element 404 “form1” (id=CJ) is an instance of class “ur:FormView”, and so forth. The model representation depicted in FIG. 4 includes approximately 20 model elements, which are instances of 10 different VCL classes.

The model elements are mapped to pictograms using mapping rules. Each mapping rule identifies a type (e.g., a particular class) of model element and the type of pictogram to which the model element maps to. When an instance of a particular class of model element is found in the model representation, a mapping rule is selected from the set of mapping rules that governs the mapping of that type of model element. The selected mapping rule is then used to create an instance of a pictogram of the type identified by the mapping rule. Different mapping rules may be provided for mapping different types of model representations to pictograms. Table A shown below depicts examples of mapping rules for mapping model elements from a model representation using UML 2.0 to pictograms.

Table B shown below depicts examples of mapping rules for mapping model elements from a model representation using UML 2.0 DI to pictograms.

Table C shown below depicts examples of mapping rules for mapping model elements from a model representation using VCL 1.3 to pictograms.

FIG. 5 depicts a sample mapping of the 10 VCL classes to 4 different pictograms. The mapping in FIG. 5 is performed using the mapping rules depicted in Table C. The mapping rules specify which pictogram is attached to which meta-model class or element. The cardinality of the mapping is one-to-many, i.e., the same pictogram can be attached to one or more classes or elements, but each class may be attached to at most one pictogram (in the same visual representation). Classes or elements that are not attached to pictograms may not be shown in the visual representation. The mapping rules also enable overriding the properties of the attached pictograms, to produce different graphic symbols for different meta-model classes. In this manner, a relatively small number of pictograms can be used for achieving a desired graphical notation.

In one embodiment in Visual Composer, the pictograms are implemented as GmlScript aspects. GmlScript is an object based programming language. In one embodiment, it is an extension of JavaScript that adds support for: namespaces and self-contained components (kits); classes, methods, and properties; aspects for aspect-oriented programming; prototypes for multiple inheritance; event and listeners for implementing dynamics and constraints; transactions for ensuring model consistency and for undo/redo; objects persistency; dynamic loading; introspection; self documentation; preprocessing pragmas; etc. In object-oriented programming, the natural unit of modularity is the class. GmlScript provides aspects which encapsulate behaviors that affect multiple classes in reusable modules. According to an embodiment of the present invention, an aspect is a special kind of class that can be attached to one or more regular classes. An aspect can be attached to one or more classes. All aspects attached to a class are implicitly attached also to its derived classes. The aspects implementing the pictograms are attached to their corresponding classes using “attach” statement in GmlScript. One sample mapping is depicted in FIG. 6A. The sample mapping in FIG. 6A produces a graphic primitive of a round rectangle 602 depicted in FIG. 6A. Another sample mapping is depicted in FIG. 6B. The sample mapping in FIG. 6B produces a graphic primitive of a round rectangle 604 depicted in FIG. 6B. Examples and description for GmlScript aspects is provided in U.S. Provisional Application No. 60/691,890 filed Jun. 16, 2005, the entire contents of which are herein incorporated by reference for all purposes.

The implementation of the pictograms, and the methods by which they are attached to meta-model classes or model elements, may vary in different implementations. Consequently, the mapping rules may be written using other formats (for example, using XMI and Xlink). But regardless of how the mapping rules are written, their contents remain the same, across all design tools that support a particular specification.

According to an embodiment of the present invention, a visual mapping rule defined on a meta-model class is inherited by all its derived sub-classes. This inheritance may be applied on two levels:

• (1) A pictogram attached to a class is implicitly attached also to all its derived sub-classes. The pictogram inherited by a derived sub-class can be replaced with another pictogram by overriding the mapping rule.
• (2) The pictogram properties defined by a mapping rule on a class are also inherited by all its derived sub-classes. The pictogram properties can be individually overridden on mapping rules defined on the derived sub-classes.

The first inheritance level is illustrated in FIG. 7 which shows a sample hierarchy of VCL meta-model classes 702 and their mapping to pictograms 704. As depicted in FIG. 7, a Configurable model class and all its derived model sub-classes such as Interactor, Infoset, Usage, and so on, are mapped to the Bipolar pictogram. However, the Port class overrides this mapping and is attached to the Unipolar pictogram instead. The new mapping is then inherited also by all sub-classes of Port, such as Inport and Outport.

The second inheritance level is illustrated in FIG. 8. As depicted in FIG. 8, the Outport class is mapped to the Unipolar pictogram, and the properties are defined to produce the graphic symbol 802 shown in FIG. 8. The ErrorPort class is derived from Outport, and thus it inherits the mapping rule defined for Outport and the corresponding graphic symbol. The ErrorPort class overrides some of the color properties to change the color (denoted by change in fillColor value) of the graphic symbol and produces graphic symbol 804 shown in FIG. 8. The EventOutport class is also derived from Outport, and thus it inherits the same mapping rule and corresponding graphic symbol. The EventOutport class overrides just the frameParts property to change the frame of the graphic symbol to produce graphic symbol 806 shown in FIG. 8.

By recursively applying the visual mapping rules over all model elements in the model representation, the model representation is thereby transformed into an abstract visual representation consisting of pictograms and their mapped properties. FIG. 9 illustrates an abstract representation generated for the sample model representation depicted in FIG. 4 according to an embodiment of the present invention. The abstract visual representation comprises topological information, such as which pictogram instances exist, how they are nested, and how they are connected. According to an embodiment of the present invention, the topology is defined as follows:

• • Each model element instance is transformed into a corresponding pictogram instance, according to the mapping rule defined on its meta-model class. If no mapping rule is defined, then no pictogram will be instantiated.
  • Composite pictograms (pictograms that contain other pictograms) are defined by specifying the meta-model aggregation they represent.
  • Connector pictograms (pictograms that connect other pictograms) are defined by specifying the meta-model association they represent.

Generally, the topology of the abstract representation is isomorphic to the topology of the underlying model representation. Depending on the capabilities of the modeling framework and the design tool, more complex topology transformations may be achieved by specifying the aggregations and associations using dynamic views or queries of the model. Even if these dynamic capabilities are not available, then a static transformation step may be applied on the model representation to achieve the desired topology.

The abstract representation is then used to generate the visual representation. As described above, this is done by generating a visual representation by applying a geometrical transformation on all the pictograms in the abstract representation. FIG. 10 depicts an example of a visual representation that may be produced based upon the abstract representation depicted in FIG. 9 according to an embodiment of the present invention. The geometrical transformation process is also called rendering, and it largely depends on the graphics engine and the characteristics of the target display device. Typically, each pictogram is transformed into a set of one or more graphic elements or primitives according to the pictogram's type and properties.

In a version of Visual Composer from SAP, the rendering phase is implemented using the SVG graphics engine. The listing in FIG. 11 shows a partial listing of the SVG markup that may be generated for rendering the visual representation depicted in FIG. 10 according to an embodiment of the present invention. The listing depicted in FIG. 11 shows that each pictogram is transformed into several SVG graphic primitives, resulting in a quite verbose SVG markup. Other design tools may be implemented using other graphic engines and may thus use different geometrical transformations, but the end result is usually substantially the same. All geometric transformations may not produce exactly the same results, because the graphic engines usually differ on qualities such as geometric precision, anti-aliasing optimizations, text legibility, rendering speed, etc. The mapping of pictograms to graphic primitives may be different in different implementations.

Most design tools enable a user to directly manipulate the visual representation by repositioning, resizing, or rotating elements, changing colors, adjusting bend points, and so on. To support direct manipulation, the visual mapping is used also in the other direction, namely from the visual representation back to the model representation. User gestures such as a mouse click, drag and drop, key press, etc. generate low-level graphic events, which are then captured and processed by the pictograms.

According to an embodiment of the present invention, the events may be classified into two categories:

• (1) Drawing events: Drawing events affect only the visual representation. They are captured and handled directly by the pictograms, according to their prescribed behavior (e.g., moving, resizing, rotating, etc.) without affecting the underlying model representation.
• (2) Semantic events: Semantic events affect the underlying model representation. They are captured by the pictograms and translated into generic events which are then propagated into the modeling framework where the actual handling will take place (for example, adding or removing elements, reconnecting or regrouping elements, etc.). The changes are stored in the model representation.

FIG. 12 depicts an example of a reaction to a semantic event called “quick-create”. The event is generated when a user drags a connector line 1202 from “Service M” shape 1204, but then releases the mouse over an empty region of the canvas (instead of over a valid connection target). This gesture translates into a “quick-create” event, which by default does nothing. However, in this case the event is intercepted by the modeling framework and used for presenting the user with a popup menu 1206 containing the relevant model elements that can be created in this context.

Whenever the user directly manipulates the visual representation, the corresponding pictograms in the abstract representation are modified accordingly. These modifications are considered valuable user work and are persisted. The abstract representation may be persisted either inside the model's repository or beside it. The persistence of the abstract representation is done in a non-intrusive way. The method used for persisting the pictograms and their properties may depend and vary based upon the design tool. For example, in the case of Visual Composer, since the pictograms are implemented as aspects, their properties are persisted as aspect properties. The aspect properties are stored together with other properties of the model elements, but in their own separate namespace (see, for example, the properties with the g: prefix in FIG. 4). Other design tools may employ other methods for persisting the pictograms and their properties. For example, pictograms may be specified as a Meta-Object Facility (MOF)-compliant metamodel (details of MOF are available at www.omg.org), enabling pictogram instances to be stored in XMI files, and linked to the model files using XLink.

Pictograms Examples

This section describes a set of pictograms according to an embodiment of the present invention. A predefined set of pictograms may be provided that constitutes the vocabulary from which the visual representation is constructed. FIG. 13 depicts a metamodel diagram for a set of pictograms according to an embodiment of the present invention. The metamodel diagram depicted in FIG. 13 shows a set of pictogram classes and their relationships. The pictogram properties and events are also shown in the second and third compartments of the pictogram classes, respectively. In the embodiment depicted in FIG. 13, the pictogram classes are classified into diagrams, shapes, groups, and lines. The pictogram metamodel depicted in FIG. 13 may be used to generate a variety of visual representations including but not restricted to VCL, UML, ROOM, ERD, and others.

Datatypes may be defined for the pictogram properties. Table D shown below identifies examples of datatypes that may be associated with pictogram properties according to an embodiment of the present invention.

Some pictogram property values may be expressed using dynamic formulas. For example, in one embodiment, a dynamic formula may be a string containing a valid expression. In one embodiment, an executable GUI language (XGL) expression that involves one or more property references may be used. XGL is a generic executable specification of graphical user interfaces for business applications. XGL is a declarative specification language designed to serve as the common-ground between user interface modeling tools and a plurality of user interface runtime frameworks. It provides a self-contained, closed, and deterministic definition of all aspects of a graphical user interface in a device- and programming-language independent manner. An XGL expression has a simple structure and may be parsed and handled by any implementation. The XGL semantics are defined using an abstract model of a GUI framework. The XGL expression syntax is a subset of the expressions syntax used in the C-style family of programming languages (such as, Java, JavaScript, GmlScript, C++, and C#). Informally, an XGL expression is made of:

• • String, Numeric, and Boolean literals
  • Property references (using (prefix)
  • Method invocations (using @ prefix)
  • Arithmetic operators (+, −, *, /, %)
  • Comparison operators (==, !=, <, <=, =>, >)
  • Logical operators (!, ∥, &&, ?:)
  • Expression grouping (parentheses, ternary ?: operator, comma operator)
  • A set of built-in macros (functions) that can be ported to any platform (e.g., UPPER, TRIM, LEN, MID, ABS, MAX, CEIL, SIN, COS, etc.).

According to an embodiment of the present invention, property references are written by adding the @ prefix to the property name (e.g., @fontSize). A formula may reference properties either on the pictogram itself, or on the underlying model object. Whenever a property value is modified, the design tool reevaluates all dependant pictogram formulas and adjusts the visual representation accordingly. For example, the following formula may be used to specify the path of a pictogram frame:
frame::JOIN(“M”, −@w/2, −@h/2, “L”, −@w/2+7.5, “0”, −@w/2, @h/2, @w/2, @h/2, @w/2, −@h/2, “Z”)
The formula is reevaluated (and the frame visual primitive is accordingly redrawn), whenever the pictogram's size property is changed. For instance, if the pictogram's size is equal to {w:80, h:30}, then the formula evaluates to:
frame=“M −40 −15 L −32.5 0 −40 15 40 15 40 −15 Z”

In case of ambiguous property names, the ! suffix may be added to distinguish model properties from pictogram properties. For example, if both a pictogram and its underlying model object contain a property named “text”, then @text may be used to reference the property on the pictogram, and @text! may be used to reference the property of the model object.

Method invocations may also be written by adding the @ prefix to the method name (e.g.,@method(args . . . )). The methods are invoked on the underlying model object. For example, the following formula may be used to determine whether to show or hide a pictogram part depending on a method return value:
display::@isPrimary( )?“none”:“block”

Unlike property references, a method invocation does not expose any explicit dependencies in one embodiment. Accordingly, a formula containing only method invocations (no property references) is reevaluated only when the owning pictogram is fully repainted. In case the methods internally depend on property values, then these dependencies are made explicit using the -> operator. For example, the following formula invokes the getEventLabel method to get a formatted event name for display. The formula is reevaluated whenever the event, guard, or scope properties are modified (since these are the properties that internally affect the formatted event name):
text::@event, @guard, @scope−>@getEventLabel( )

As described above, a set of one or more pictograms may be defined in order to facilitate generation of a visual representation from a model representation (and to make changes to the model representation when the visual representation is changed) in a manner that decouples the model representation from the visual representation. A few pictograms defined for an embodiment of the present invention and their associated properties are described below. These pictograms do not in any manner limit the scope of the present invention as recited in the claims.

Diagrams

The diagram is the drawing surface upon which the visual representation is drawn. The Diagram pictogram aggregates any number of Shape and Line pictograms, which are the visual elements that are actually drawn in a diagram. The diagram itself has no visual appearance (it is drawn as a white canvas). The diagram is infinite for each dimension of the coordinates space, but rendering occurs relative to a finite rectangular region of the diagram called the diagram's viewport. The viewport is defined by the diagram origin and scale properties. Whenever the user translates or magnifies the diagram viewport, these properties are updated to reflect the new viewport settings. The following diagram pictograms may be provided:

(1) Diagram

The Diagram pictogram is an abstract pictogram that has no layout and thus cannot be drawn. Concrete diagram pictograms are derived from Diagram by specifying a particular layout method.

Properties:

(2) PlanarDiagram

A PlanarDiagram is a diagram drawn on a single plane with no overlapping shapes. Whenever the user moves or resizes a shape, all other shapes that become touched as a result are pushed away.

Properties:

(3) LayeredDiagram

A LayeredDiagram is a diagram drawn as a collection of super-imposed layers. Each shape belongs to exactly one layer. Shapes in different layers can overlap. The user can control the visibility of individual layers.

(4) AutoDiagram

An AutoDiagram is a diagram with automatic layout. The diagram shapes are arranged according to the defined layout property. The user cannot control the arrangement of the shapes in an AutoDiagram.

Properties:

Shapes

A shape is an abstract element (pictogram) that occupies a finite, non-rectangular, region in the diagram. The shape's coordinates system is defined by the innermost group or diagram that contains the shape. All the geometric shape properties are defined relative to this coordinates system. The shape's bounding box is defined as the smallest rectangular region that completely contains the shape. The following pictograms may be provided as shapes:

(1) Shape

The Shape pictogram is an abstract pictogram that has no visual parts and thus cannot be drawn. Concrete shape pictograms are derived from Shape by adding specific visual parts that can be drawn.

Properties:

FIG. 16 illustrates various shape colors according to an embodiment of the present invention.

A shape pictogram may also have computed properties. Computed shape properties are virtual properties that are automatically recomputed by the shape pictogram. The computed properties are not persisted, but they can be used in dynamic formulas just like any other pictogram property. Examples include:

While the shape's center position (cx,cy) and size (w,h) are not affected by the rotation angle, the shape's bounding box (x1,y1,x2,y2) always depend on the rotation angle. This is illustrated in FIG. 18.

(2) Polyshape

A Polyshape is a shape composed of one or more visual parts (hence the name).

Properties:

SvgParts: The SvgParts structure is an array of shape part definitions, each defined using a single SVG graphic element. For each shape part, the type attribute defines the type of SVG element that will be created. Only the basic SVG element types are allowed, to enable compatibility with any graphics engine. Specifically, the examples of allowed types are: rect, circle, ellipse, line, polyline, polygon, path, text, and image. The remaining attributes are visual attributes specific to the SVG element selected by the type attribute. See the SVG 1.1 Specification (www.w3.org/TR/2003/REC-SVG11-20030114) for the full description of the SVG elements and their visual attributes, the entire contents of this specification are herein incorporated by reference for all purposes. All shape part attributes (except for type) can be expressed using dynamic formulas. FIGS. 19A and 19B illustrate how various frame and body SvgParts are mapped to the visual representation.

(3) Bipolar

A Bipolar pictogram is a Polyshape containing input and output anchor pins. The input/output pins are automatically arranged on two opposite shape sides (poles), and the shape is automatically resized to accommodate all pins. Bipolar shapes are typically used in orthogonal layouts. Examples are depicted in FIG. 20.

(4) Unipolar

A Unipolar pictogram is a Polyshape containing either input or output anchor pins. The input or output pins are automatically arranged on one of the shape's sides (pole), and the shape is automatically resized to accommodate all pins. Unipolar shapes are typically used in orthogonal layouts. Examples are depicted in FIG. 21.

(5) Textbox

A Textbox pictogram is used for drawing text boxes with multiple lines of text. The textbox is automatically resized to fit its contents. Examples are depicted in FIG. 22.

Properties:

Groups

A group is a shape that can contain other shapes, including other groups. Operations performed on a group are performed on all its members as a whole. The group defines a new coordinates system for its member shapes, relative to its position and scale. Examples of pictograms for groups are provided below.

(1) Group

A Group pictogram has no specific layout. Therefore, the members of a Group pictogram are arranged using the same layout as defined by the owning diagram. However, other pictograms derived from Group may provide specialized layout methods of their own. Examples are depicted in FIG. 23.

Properties:

(2) Tessellation

A Tessellation pictogram is a group that arranges its members so that they completely cover the group's contents area without overlaps. The members of a tessellation are usually all groups. The order of the members in a tessellation is important. Examples are depicted in FIG. 24.

Properties:

(3) Progression

A Progression pictogram is a group that arranges its members along a time line. The order of the members in a progression is important. An example is depicted in FIG. 25.

Properties:

Lines

A line is a directed path that connects two shape anchors (the line ends). The line's coordinates system is defined by the innermost group or diagram that contains both line ends. Examples of line pictograms are provided below.

(1) Line

The Line pictogram represents a straight line that is drawn directly from the source anchor to the target anchor.

The start and end arrows can be any one of the combinations depicted in FIG. 26.

FIG. 30 illustrates the various line colors.

(2) AngularLine

The AngularLine pictogram represents an angular line with two control points. An example is depicted in FIG. 30.

(3) CurvedLine

The CurvedLine pictogram represents a Bezier curve with two control points, as shown in FIG. 31.

(4) OrthogonalLine

The OrthogonalLine pictogram represents a line drawn using only horizontal or vertical line segments. The orthogonal line is automatically routed around the shapes it is connected to. The number of control points in an orthogonal line varies depending on its route. An example is depicted in FIG. 32.

(5) Anchor

The Anchor pictogram represents a line connection point. Anchors are aggregated by shapes and are connected by lines.

Properties:

The remaining properties apply to anchors of type PIN:

An example of a set of pictograms and their associated properties is described above. Embodiments of the present invention decouple the model representation from the visual representation. As a result, the model and visual representations can be evolved separately, and by the most appropriate experts. For example, a meta-modeling expert can extend the model representation (for example, by adding new meta-model elements) without needing to become a graphics expert. The visual mapping from the model representation to the visual representation may already be available, or can be created in a very simple way. Similarly, a usability expert can refine and improve the visual appearance of an already existing meta-model without impacting the meta-model itself.

Embodiments of the present invention provide a generic visualization process that enables transforming any model representation (using possibly different modeling languages) to any visual representation. The visualization process is not tied down to any modeling representation type (e.g., not tied to any particular modeling domain format or language) or to any visual representation. Different visualization tools may be used to output or display the same model representation. Likewise, different model representations may be visualized using the same visualization tool.

The same model representation may be mapped to multiple visual representations. This enables displaying the model at different levels of details or with different perspectives for users with different roles. Because all visual representations are declaratively mapped to the same underlying model, the design-time tools can ensure that the different views on the model are kept in sync.

Different design tools may interpret the mapping between the model and visual representations, because the mapping is fully declarative and language independent. Therefore, it is possible to define the visual mapping once and then, without any additional implementation effort, achieve the same consistent model visualization in other different design-time tools that support this method. Whenever the modeling language is extended, the new elements will also become visible in all the supporting design-time tools without any additional effort.

In some embodiments of the present invention, the visual mapping itself be generated by automated tools, due to mapping being fully declarative. This enables tools that automate the development of a modeling language to provide also a visual representation of the generated meta-model elements. For example, a Visual Composer kit developer may be able to develop new meta-model elements using the kits development infrastructure in Eclipse, and then let the tools generate automatically the skeleton Visual Composer model classes, complete with their visual representation, so they are available for use in Visual Composer.

FIG. 36 is a simplified block diagram of a computer system 3600 that may be used to perform processing according to an embodiment of the present invention. As shown in FIG. 36, computer system 3600 includes a processor or processing engine 3602 that communicates with a number of peripheral devices via a bus subsystem 3604. These peripheral devices may include a storage subsystem 3606, comprising a memory subsystem 3608 and a file storage subsystem 3610, user interface input devices 3612, user interface output devices 3614, and a network interface subsystem 3616.

Bus subsystem 3604 provides a mechanism for letting the various components and subsystems of computer system 3600 communicate with each other as intended. Although bus subsystem 3604 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple busses.

Network interface subsystem 3616 provides an interface to other computer systems, networks, and devices. Network interface subsystem 3616 serves as an interface for receiving data from and transmitting data to other systems, networks, devices, etc. from computer system 3600.

User interface input devices 3612 may include a keyboard, pointing devices such as a mouse, trackball, touchpad, or graphics tablet, a scanner, a barcode scanner, a touchscreen incorporated into the display, audio input devices such as voice recognition systems, microphones, and other types of input devices. In general, use of the term “input device” is intended to include all possible types of devices and mechanisms for inputting information to computer system 3600. A user may use an input device to manipulate and make changes to the visual representation.

User interface output devices 3614 may include a display subsystem, a printer, a fax machine, or non-visual displays such as audio output devices, etc. The display subsystem may be a cathode ray tube (CRT), a flat-panel device such as a liquid crystal display (LCD), or a projection device. In general, use of the term “output device” is intended to include all possible types of devices and mechanisms for outputting information from computer system 3600. An output device may be used to output the visual representation to the user.

Storage subsystem 3606 may be configured to store the basic programming and data constructs that provide the functionality of the present invention. Software (code modules or instructions) that provides the functionality of the present invention may be stored in storage subsystem 3606. These software modules or instructions may be executed by processor(s) 3602. Storage subsystem 3606 may also provide a repository for storing data used in accordance with the present invention. Storage subsystem 3606 may comprise memory subsystem 3608 and file/disk storage subsystem 3610.

Memory subsystem 3608 may include a number of memories including a main random access memory (RAM) 3618 for storage of instructions and data during program execution and a read only memory (ROM) 3620 in which fixed instructions are stored. File storage subsystem 3610 provides persistent (non-volatile) storage for program and data files, and may include a hard disk drive, a floppy disk drive along with associated removable media, a Compact Disk Read Only Memory (CD-ROM) drive, an optical drive, removable media cartridges, and other like storage media.

Computer system 3600 can be of various types including a personal computer, a portable computer, a workstation, a network computer, a mainframe, a kiosk, or any other data processing system. Due to the ever-changing nature of computers and networks, the description of computer system 3600 depicted in FIG. 36 is intended only as a specific example for purposes of illustrating the preferred embodiment of the computer system. Many other configurations having more or fewer components than the system depicted in FIG. 36 are possible.

Although specific embodiments of the invention have been described, various modifications, alterations, alternative constructions, and equivalents are also encompassed within the scope of the invention. The described invention is not restricted to operation within certain specific data processing environments, but is free to operate within a plurality of data processing environments. Additionally, although the present invention has been described using a particular series of transactions and steps, it should be apparent to those skilled in the art that the scope of the present invention is not limited to the described series of transactions and steps.

Further, while the present invention has been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of the present invention. The present invention may be implemented only in hardware, or only in software, or using combinations thereof.

The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that additions, subtractions, deletions, and other modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims.