GB2360367A - A configurable framework for composition of connected entities in a data processing application or logic sequence - Google Patents

Abstract

A configurable framework for composition of components making up a data processing application or logic sequence, has: a visual composition framework for displaying on a display screen a plurality of components and supporting a set of user-initiated actions; and a constraint framework for providing a generic interface to a plurality of underlying application models, each of which supports the set of user-initiated actions in a unique manner.

Description

2360367 A CONFIGURABLE FRAMEWORK FOR COMPOSITION OF CONNECTED ENTITIES IN

AN APPLICATION OR LOGIC SEQUENCE

Field of the Invention

The invention relates to the field of computer programming and more specifically to the composition of a data processing application or logic sequence.

Background of the Invention

Often the most natural way to compose an application or a sequence of logic is through visual manipulation of the entities that make up the is application. A number of products and research projects have proposed solutions to the problem of composing applications graphically. However, many of these efforts provide different ways of doing similar things. It is very common that these various composition tools become combined into a single tool. The various tools are different enough that the user gets confused when moving from one to another within the combined tool.

Description of the Invention

The present invention provides a configurable framework for composition of components making up a data processing application or logic sequence, having: a visual composition framework for displaying on a display screen a plurality of components and supporting a set of user-initiated actions; and a constraint framework for providing a generic interface to a plurality of underlying application models, each of which supports the set of user-initiated actions in a unique manner.

The framework of the present invention provides a common infrastructure and a customisable view that provides the same concepts and actions whatever is being composed. In addition, it is preferably based on XML (extensible Markup Language) so that whatever form the application model is in, it can be used in this framework by converting to the XML representation. This framework may use the DTD (data type definition) representation of the application model to provide a natural way to express the constraints on how the composition can be made. If the constraints 2 cannot be expressed by a DTD, this framework may also provide the mechanism to augment these constraints with behaviour written in Java.

Thus, with the present invention, a single generic view is provided in a visual framework for the composition of applications (or logic sequences) with connected entities. Because a common infrastructure is provided, the same actions can be carried out regardless of what is being composed.

Brief Description of the Drawings

The present invention will be better understood by reading the detailed description of preferred embodiments below, which will be is presented by making reference to the following drawing figures:

Figure 1 shows a data model for components in the visual composition framework according to a preferred embodiment of the present invention;.

Figure 2 shows an example of a displayed composition with nodes, ports and connections; Figure 3 shows an example of a displayed composition with nodes, ports (centre location), connections and containers; Figure 4 shows different renderings of displayed ports depending on the desired layout. a) top to bottom, b) bottom to top, c) right to lef t, d) left to right; Figure 5 shows the composition area and palette of the visual framework of the preferred embodiment; Figure 6 shows an example of an application model that might be a target of visual composition; and Figure 7 shows interactions for three actions: creation, copying and pasting, and deletion.

3 Detailed Description of the Preferred Embodiments

1 overview The preferred embodiment of this invention is described as two dependent pieces of software. The first piece is the visual framework which provides the look and interactions with the graphical composition editor. The second piece is the constraint framework which provides the interface to the underlying application model that is required to support the interactions in the visual framework.

2 Visual Framework There are four components in the visual framework. A visual composition consists of nodes, ports, connections and containers. A node is the entity that represents the objects to be connected. Ports are the is connection points for the node. Connections are the lines between the ports of the nodes. Containers are boxes that show nodes inside them. An object in the application model is conf igured to be one or more of these types so that it can be visualised and visually composed. objects in the application model can be configured to be rendered in different ways. For example an object could be rendered as a node or a port depending on whether it is being viewed as a node in the exploded view of a compound node or if it is rendered when the compound node is viewed as a single icon. The visual framework also supports a standard set of actions. These allow the user to view the composition in a number of different orientations, and at different zoom factors, and also provides a set of common manipulation actions.

2.1 Components Figure 1 shows the data model for the various components and their properties. Each component has a component type. The component type gives the specification of the component. The component itself contains data that needs to be saved with the application object that it represents if the data is to be persistent. When certain parts of the object model are configured to be of these component types and have the appropriate properties set then the application model can be displayed as shown in f igures 2 and 3. Figure 2 shows an example with only ports, nodes and connections. The ports are on the "north" and "south" side but since the view is left-to-right, these appear on the left and right, respectively.

Figure 3 shows an example with nodes, ports, containers and connections. In this case the ports are configured as "centre" which means that no port is 4 drawn and connections appear to come f rom the centre of the node. Note that the connections are not bound by the container boundaries in this model.

2. 1. 1 Node A node is represented by a GIF image. The icon specifies the image file to use. Different GIF's for different zoom levels are supported for two reasons. Scaling images algorithmically tends to make the images less crisp. Secondly, the amount of detail shown for each zoom level may be different since it may or may not be visible. The algorithm for the icon names is <name>_< size>. gif where the icon is specified as <name>.gif. If the co-ordinates are to be stored persistently with the object in the application model then it must store the x and y properties. The following in an extract from the Data Type Definition (DTD) according to an example:

is <!ELEMENT nodeType> <!ATTLIST nodeType scaleableIcon CDATA I'll> <IATTLIST nodeType icon CDATA <!ELEMENT node> <!ATTLIST node x CDATA <1ATTLIST node y CDATA I'll> 2.1.2 Port A port is also represented by a gif image. The port is given a virtual location of north, east, south, west or centre. This virtual location is correct for the top-to-bottom layout. As different layouts are chosen the ports are displayed in the appropriate location. For the same reasons as for nodes, discrete gif ' s for each zoom level are supported. In addition, there can be gif's for each zoom level for each location. This enables the images to have different shadow locations depending on their location.The direction is also specified to indicate which way a connection should be specified when being made.

Figure 4 shows the different layout orientations. The ports in this example, the arrowhead port is configured to be "north" and the arrow tail icon is configured to be "south". There is no mapping required for these ports in a top-to-bottom orientation as shown in figure 4a. Figure 4b, c, and d show the other three layout orientations. The application object that stores the port does not need to store any other metadata. The following is an extract <!ELEMENT portType> <!ATTLIST portType direction (inloutlinout) "in,,> <!ATTLIST portType location (north 1 south least lwest 1 centre) "north,,> <1ATTLIST portType portIcon CDATA <!ELEMENT portType> is 2.1.3 Connection The connection is drawn as a line. It can be conf igured with a colour to use when it is displayed and also a colour to use when it is selected.

The source and target decorations can be specified to be a number of different shapes as well as specified to be solid or empty. The sourceType and targetType are used to discover which connections are valid in the composition. The sourceType and targetType need to specify the Element that the connection will be connected from and to respectively. The connecting algorithm checks that there is a connectionType available for the selected port. The line is then drawn and only ports that can satisfy a connection are activated for the target. If there are multiple connections that can connect the ports then the list is shown to the user so that they can select the appropriate one. The application object that is represented by the connection must store the actual source and target for the connection for it to be persistent.

<!ELEMENT connectionType> <!ATTLIST connectionType color (black 1 blue 1 cyan J darkGray 1 gray green 1 lightGray 1 magenta 1 orange 1 pink 1 red 1 white 1 yellow) "black"> <!ATTLIST connectionType sourceDecoration (none 1 arrow 1 box 1 circle diamond 1 triangle) "nonel> <!ATTLIST connectionType sourceDecorationFill (emptylsolid) "empty"> <!ATTLIST connectionType selectedColor (black 1 blue 1 cyan 1 darkGray gray 1 green 1 lightGray 1 magenta lorange 1 pink 1 red 1 white 1 yellow) "black"> <!ATTLIST connectionType sourceType WATA1111) <!ATTLIST connectionType targetType CDATA1111) so <!ELEMENT connection> 6 <!ATTLIST connection source CDATA11 11) <1ATTLIST connection target CDATAl"1) 2.1.4 Container The container has no specific properties. It is possible that an object in the model could be both a node and a container. This would be the case if it makes sense to connect this object to others.

<!ELEMENT container> 2.2 Actions 2.2.1 Layout Graph often different users like to have their graphical compositions laid out in different orientations. The orientations are:

Top to bottom all connections are directed vertically with "north" icons on the top and "south" icons on the bottom Bottom to top all connections are directed vertically with "north" icons on the bottom and,south" icons on the top Left to right all connections are directed horizontally with "north" icons on the left and "south" icons on the right Right to left all connections are directed horizontally with "north" icons on the right and,south" icons on the left An automatic layout is performed to do the layout in the desired orientation. The automatic layout using an algorithm that minimises the number of crossing lines.

2.2.2 Zoom The framework supports a continuous zoom capability. As well, because of the scaling problems with gifs, it also supports discrete zoom levels.

The ones that are currently supported are 25, 50, 75, 100 %. This is a percentage of the image area not the linear dimensions. In addition a "Fit to window,, option scales everything on the drawing space so that it fits in the window. This action uses the closest gif size and then algorithmically scales it so that everything fits. if the discrete gifs are not found then the default gif will be scaled to the correct size.

7 2.2.3 Manhattan style This term is taken f rom circuit design. It is also called rectilinear in some tools. This draws lines from line components that are either horizontal or vertical with 90 degree angles between them. This is optional so that the user can select their preference. If this option is not set then the lines are drawn as straight lines from point to point.

2.2.4 Snap to grid This provides a larger step size for the movement of nodes than the default 1 pixel.

2.2.5 Print Since these graphical compositions become documentation, it is important that the diagrams can be exported in some way. using the default is platform printing mechanism provides this support.

3 Constraint Framework This framework is used for all composition mechanisms but is especially applicable for visual composition. Its use in the visual composition paradigm is described below. But it should be fairly obvious how this is used to do tree based composition as well as dynamically configuring menu items.

3.1 Augmentor Interface Each object in the model has a <object>Augmentor that defines its behaviour. The object is defined by its tagname when using XML. These Augmentors extend the default Augmentor which uses the DTD as its constraint mechanism. The methods on the Augmentor allow constraints that cannot be described in a DTD to be enforced. The methods can also be used to support having a palette of application objects that are composed using an association.

3.1.1 void addEntity (Element parent, Element child) This method adds the child to the parent. One reason why a method is required to perform this action is that the child may not be the actual entity that is added as a child of the parent. For example, using the model in figure 6. the palette will typically contain a list of Type objects. The composer will be used to compose a Type. The TypeAugmentor will be asked to add a Type. The TypeAugmentor will instead add a Property to the parent 8 Type and set the hasType relationship f rom the Property to the Type that was passed in as the child.

3.1.2 Element cloneEntity(Element entity) This method is used to copy an entity. In some cases the entity may have a unique key in which case the close would have a different unique identifier. In other cases a clone may simply be able to be made. The Augmentor decides what the semantics of a clone are.

3.1.3 Element createEntityo This method returns an entity created by the Augmentor.

3.1.4 void del e teEnti ty (Element entity) This method may need to perform some cleanup of any side effects that is it caused during the addEntity method.

3.1.5 String getDisplayName (Element entity) This gets the string name that should be displayed for this entity.

3.1.6 String getlconName(Element entity) This method gets the icon. This method enables the icon to be changed depending on the context of the element.

3.1.7 boolean isInsertable (Element parent, Element prospectiveChild) This method asks whether the child can be inserted under the parent.

One important aspect of this method is that the prospectiveChild that is passed in may not be the one that will eventually be physically inserted under the parent. For example, using the model in figure 6. the palette will typically contain a list of Type objects. The composer will be used to compose a Type. The TypeAugmentor will be asked if a Type can be inserted.

The TypeAugmentor will need to check in this case that a Property can be created to reference the Type and the Property can be added to the parent Type being composed.

3.1.8 boolean isDeletable(Element entity) This method checks whether the entity can be deleted. Because of certain constraints, it may not be possible to remove an entity without creating an invalid composition. If this method returns false then a message will be shown to indicate to the user that the entity cannot be deleted.

9 3.1.9 void replaceEntity (Element current, Element replacement) This method is used for the undo functionality. If an entity is edited then the old instance is placed in the undo list. Performing undo will do call this method which replaces the later entity with the previous one.

3.2 Augmentor Interactions Figure 7 shows the interactions for performing three common actions in a graph composer. The first action shown is what happens when something is created on the composition surface. The element is dragged from the palette and then handed to the augmentor for the parent element being edited in the graph composer. The parent element is asked whether it will accept this element. Note that the basic functionality will simply check that the DTD allows it. However, the augmentor can decide whether it can is be added based on its current state of the parent. The actual element that is dropped may not be the one that will be added to the parent but the parent can check using it. If the element is insertable ie. can be added, then the addEntity method is called on the augmentor for the parent element and it will add the element, or any corresponding element to itself. The duplicate action is used for copy and paste. When an item is to be duplicated, the parent element augmentor is asked whether it can be inserted. If so, then the augmentor is asked to clone the element and then the element is added. The delete action detects whether the element can be deleted. There may be a number of reasons why an element cannot be deleted and the parent element can decide. If the element is deletable then it is deleted. All of these actions are easily integrated to provide a simple undo mechanism for removing changes.

The present invention is preferably embodied as a computer program product for use with a computer system. Such an implementation may comprise a series of computer readable instructions either fixed on a tangible medium, such as a computer readable media, e.g., diskette, CD- ROM, ROM, or hard disk, or transmittable to a computer system, via a modem or other interface device, over either a tangible medium, including but not limited to optical or analog communications lines, or intangibly using wireless techniques, including but not limited to microwave, infrared or other transmission techniques. The series of computer readable instructions embodies all or part of the functionality previously described herein.

Those skilled in the art will appreciate that such computer readable instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Further, such instructions may be stored using any memory technology, present or future, including but not limited to, semiconductor, magnetic, or optical, or transmitted using any communications technology, present or future, including but not limited to optical, infrared, or microwave. It is contemplated that such a computer program product may be distributed as a removable media with accompanying printed or electronic documentation, e. g., shrink wrapped sof tware, pre - loaded with a computer system, e. g., on a system ROM or fixed disk, or distributed from a server or electronic bulletin board over a network, e.g., the Internet or World Wide Web.

is

Claims (9)

1. A configurable framework for composition of components making up a data processing application or logic sequence, comprising: 5 a visual composition framework for displaying on a display screen a plurality of components and supporting a set of user-initiated actions; and a constraint framework for providing a generic interface to a plurality of underlying application models, each of which supports the set of user-initiated actions in a unique manner.
2. 2. The configurable framework of claim 1 wherein the plurality of components includes nodes, ports, connections and containers.

   is
3. 3. The configurable framework of claim 1 wherein the constraint framework provides a configuration file for each of the underlying application models, the configuration file providing a mapping between the objects of the respective application model and the components displayed by the visual composition framework on the display screen.
4. 4. The configurable framework of claim 3 wherein the configurable framework is based on XML such that a configuration file for an application model is used to convert data in a corresponding underlying application model to XML form.
5. 5. The configurable framework of claim 4 wherein the configuration file uses the DTD representation of the corresponding application model to express constraints on the visual composition framework.
6. 6. The configurable framework of any preceding claim wherein the user-initiated actions include a zoom capability and the selection of a layout graph.
7. 7. The configurable framework of any preceding claim, wherein the configurable framework is stored on a computer-readable storage medium.
8. 8. A configurable framework substantially as hereinbefore described, with reference to and as illustrated by, the appended drawings.

   12
9. 9. A computer program product stored on a computer readable storage medium for, when run on a computer system, instructing the computer system to implement the configurable framework of any preceding claim.