Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/28—Databases characterised by their database models, e.g. relational or object models
  • G06F16/289—Object oriented databases

Definitions

• This invention relates to an apparatus for storing data for use in displaying diagrams and also to a method of storing diagram data and using the stored data for displaying diagrams.
• a computer apparatus for storing data for use in displaying diagrams, each diagram comprising a plurality of entities, said apparatus comprising: means for entering data for use in displaying diagrams; means for storing data describing an individual diagram entity as a software object having a set of attributes which includes an identifier for the software object; means for storing general data relating to an individual diagram as a software object whose attributes include an identifier for the software object; means for storing data relating to the location of an individual entity on a diagram as a software object whose attributes include the location of the entity on the diagram; means for retrieving data describing individual diagram entities; and means for using the retrieved data for displaying a diagram.
• the data can both be stored and retrieved in an efficient manner.
• the entities may include graphical shapes and flow lines connecting the graphical shapes together.
• data describing an entity in the form of a graphical shape may be stored as a software object belonging to a software object class for graphical shapes
• data describing an entity in the form of a flow line may be stored as a software object belonging to a software object class for flow lines whose attributes include a pair of pointers which point to the identifiers of the two software objects which describe, respectively, the entity at one end and the entity at the other end of the flow line.
• the apparatus may includes means for operating on the retrieved data in a predetermined manner to produce a desired diagram.
• a computer apparatus including a central processing unit, a memory, means for entering data and a display unit, said memory containing a program for controlling the computer apparatus and which is arranged to: receive data for use in displaying diagrams; store data representing an individual diagram entity as a software object having a set of attributes which includes an identifier for the software object; store general data relating to an individual diagram as a software object whose attributes include an identifier for the software object; store data relating to the location of an individual entity on a diagram as a software object whose attributes include the location of the entity on the diagram; retrieve data describing individual diagram entities; and use the retrieved data for displaying a diagram.
• a method of operating a computer apparatus for storing diagram data and using the stored data for displaying diagrams, each diagram comprising a plurality of entities comprising the steps of: storing data describing each individual diagram entity as a software object having a set of attributes which includes an identifier for the object; storing general data relating to each individual diagram as a software object whose attributes include an identifier for the software object; storing data relating to the location of each individual entity of a diagram as a software object whose attributes include the location of the entity on the diagram; retrieving data describing individual diagram entities; and using the retrieved data for displaying a diagram.
• Figure 1 is a block diagram of an apparatus embodying this invention
• Figure 2 is a block diagram showing the components of a computer forming part of the apparatus
• FIG 3 shows the components of the software used in the apparatus of Figure 1;
• Figure 4 is a diagram illustrating some of the components of an alarm management system for a telecommunications network which are present on a particular day;
• Figure 5 is a flow chart of a routine STORE forming part of the main program of the apparatus of Figure 1;
• Figure 6 is a flow chart of a routine RETRIEVE used in the main program;
• Figure 7 is a diagram showing the network management centre together with four alarm collection centres which belong to the alarm management system of Figure 4;
• Figure 8 is a flow chart of a routine LINK forming part of the main program;
• Figure 9 is a diagram of the alarm management system of Figure 4 and generally similar in layout to the diagram of Figure 4 but showing the components which are present at a later date;
• Figure 10 is a diagram formed by combining Figures 4 and 9;
• Figure 11 is a flow chart of a routine ADD forming part of the main program;
• Figure 12 is a flow chart of the alarm management system of Figure 4 and generally similar to Figure 4 but showing the components which are present at a date between the dates of the diagrams of Figures 4 and 9;
• Figure 13 is a flow chart of a routine INTERPOLATE forming part of the main program
• Figure 14 is a flow chart of a routine LIST forming part of the main program
• Figure 15 is a diagram illustrating part of the management structure of a company
• Figure 16 illustrates how stored data may be partitioned into scenarios
• Figure 17 is a flow chart of a routine COPY which may form part of the main program
• Figure 18 is a flow chart of a routine PROMOTE which may form part of the main program
• Figure 19 illustrates the mapping between two diagrams representing a real world structure in two different domains.
• Figure 20 is a flow chart of a routine MAP which may form part of the main program.
• the apparatus 10 comprises three general purpose computers or workstations 11, 12, 13 connected by a communication link 14 to a file server 15.
• the file server 15 functions as a centralised data store for all three computers 11, 12, 13 and data for storage may be entered either at one of the computers 11, 12, 13 or directly into the file server.
• three computers 11, 12, 13, three people may use the apparatus simultaneously and access the data stored in the file server 15.
• the computer 11 is of conventional construction and its main components are shown in Figure 2. These components include a mouse 19, a keyboard 20, a visual display unit or screen 21, a central processing unit (CPU) 22, a read only memory (ROM) 23, and a random access memory (RAM) 24. In operation, programs and data may be loaded from the file server 15 into RAM 24.
• FIG 3 there are shown the components of the software or programs used in the apparatus 10. These components comprise a graphical user interface (GUI) 30, a main program 31, an interface 32 and a database management system 33. GUI 30 is formed from the two software packages AIDA and MASAI available from Hog Limited of the Surrey Technology Centre, 40 Occam Road, Guildford, GU2 5YH, England.
• the database management system 30 is the well known Oracle Database Management System.
• the main program 31 comprises routines STORE, RETRIEVE, LINK, ADD, INTERPOLATE and LIST which are described in detail below.
• the main program 31 is written in the programming language LISP.
• the interface 32 functions as an interface between the main program 31 written in LISP and the Oracle Database management system 33.
• the interface 32 is the software package Asquell available from Hog Limited.
• the software components shown in Figure 3 are stored in the file server 15 and may be loaded into the computer 11 when it is desired to use the apparatus.
• FIG 4 there is shown a diagram illustrating some of the components of an alarm management system for a telecommunications network which are present at a certain date.
• these components comprise switches A, B, C, alarm collection centre A, repair team A and a network management centre.
• these components are represented, respectively, by boxes 40 to 45. Each of these boxes is labelled with text which provides information, such as the name, about the component which it represents.
• flow lines 50, 51, 52 each of the switches A, B, C sends alarms to the alarm collection centre- A.
• flow lines 53, 54 the alarm collection centre A sends reports to repair team A and the network management centre.
• Each of the flow lines 50 to 54 has a source and a destination.
• the source is located at the box which represents the component where information in the form of reports or alarms originates and the destination is connected to the box which represents the component to which the information is delivered.
• Each of the flow lines has an arrow at its destination. As may be observed, each of the flow lines is provided with text ("reports" or "alarms") indicating the name of the information which it carries.
• the boxes 40 to 45 belong to one type of diagram entity while the flow lines 50 to 54 belong to another type of diagram entity.
• the apparatus 10 operates in what is known as an object-oriented environment. In this environment, abstract or physical real world objects are modelled by software objects.
• the real world objects may be divided into object types.
• the diagram boxes 40 to 45 belong to one type of real world object and the diagram flow lines 50 to 54 belonging to another type of real world object.
• the software implementation of an object type is known as an object class.
• a particular example of a software object class is known as instance of the object class or, more simply, as an object.
• Each software object class has a set of attributes. In the case of an instance of an object class, the attributes have values which collectively describe features of interest of the real world object which it models.
• the apparatus 10 uses four software object classes and these are: APPLICATION, INTERFACE, DIAGRAM and CONTENT.
• APPLICATION INTERFACE
• DIAGRAM DIAGRAM
• CONTENT The attributes for these software classes are listed in Tables 1 to 4 below and these tables will now be described in turn.
• the attributes for the object class APPLICATION are shown in Table 1 below:
• the object class APPLICATION is used to describe a diagram entity in the form of a box.
• the attributes are set as follows.
• ID is a unique identifier for the entity.
• NAME is both the name of the real world object represented by the box and also the text appearing inside the box.
• START- DATE and END-DATE together define the period of validity or existence of the real world object represented by the box.
• VIEWER gives the security level required by a viewer or user to see or edit a diagram which includes the box.
• the object class APPLICATION is the only object class for describing a graphical shape. More generally, there may be other object classes for other graphical shapes such as circles and ellipses. Each object class may also be associated with a certain type of data, for example data relating to a monitoring system, a group of people or a database. If desired, the graphical shape assigned to a particular class may be changed by the user.
• An instance of INTERFACE describes a diagram entity in the form of a flow line.
• the attributes are set as follows. ID and VIEWER are set in a similar manner to the corresponding attribute for an instance of APPLICATION. NAME is set to the text which appears on the flow line.
• SOURCE-CLASS-ID and SOURCE-ENTITY- ID are set to the name of the class and the identifier for the instance of that class for the diagram entity which appears at the source of the flow line.
• the class is always APPLICATION but, more generally, flow lines could be connected to diagram entities of other classes for other graphical shapes such as circles or ellipses.
• DEST-CLASS-ID and DEST-ENTITY-ID give the name of the class and the identifier for the instance of that class for the diagram entity at the destination of the flow line.
• DIAGRAM provides general data relating to a particular diagram.
• a description of the attributes is set out clearly in Table 3.
• the attributes for the object class CONTENT are set out below in Table 4.
• Each instance of CONTENT gives the location and other details of an entity of a diagram on that diagram.
• X- COORD and Y-COORD give the x and y co-ordinates of the entity on the diagram.
• the entity can be only a box or a flow line. If it is a box, BOX-TYPE describes the type of box. For example, the box may be rectangular with straight sides or rectangular with curved sides.
• LINE-TYPE describes the type of line, for example thick or thin, used to draw the box or the flow line.
• DIAGRAM-ID gives the unique identifier for an instance of DIAGRAM which contains general data relating to the diagram on which this entity is present.
• CLASS-ID and ENTITY-ID together define the instance of the object class which describes this entity. Thus, if the entity is a box, CLASS- ID is set to APPLICATION. If it is a flow line, then CLASS- ID is set to INTERFACE.
• the routine STORE is used for storing data for subsequent use in displaying a diagram.
• the flow chart for this routine is shown in Figure 5 and the flow chart will be described with reference to storing the diagram of Figure 4.
• general data for the diagram is entered and stored as an instance of DIAGRAM.
• data describing one of the boxes 40 to 45, for example box 40 is entered and stored as an instance of APPLICATION.
• step S3 data describing the location of the box and other associated data is entered and stored as an instance of CONTENT. Steps S2 and S3 are then repeated until an instance of APPLICATION and an instance of CONTENT have been created for each of the boxes 40 to 45.
• step S4 data is entered which describes one of the flow lines, for example flow line 50, and stored as an instance of INTERFACE. Then in a step S5, data describing the location of the flow line and other associated data is stored as an instance of CONTENT. Steps S4 and S5 are repeated until an instance of INTERFACE and an instance of
• CONTENT has been created for each of the flow lines 50 to 54.
• the routine RETRIEVE is used for retrieving data for displaying a diagram.
• the flow chart for this routine is shown in Figure 6 and this will now be described with reference to the diagram of Figure 4.
• a step S20 the identifier for the instance of DIAGRAM relating to the diagram of Figure 4 is entered.
• a step S21 the instance of DIAGRAM is retrieved.
• an instance of CONTENT is retrieved which points to the instance of DIAGRAM retrieved in step S21.
• the instance of CONTENT retrieved in S22 points to an instance of APPLICATION or INTERFACE.
• S23 this instance of APPLICATION or INTERFACE is retrieved.
• a step S24 a check is made to determine if there are any more instances of CONTENT. Steps S22 and S23 are repeated for each remaining instance of CONTENT which points to the instance of DIAGRAM retrieved in step S21 and for the associated instance of APPLICATION or INTERFACE.
• Each user of the apparatus has an associated security level.
• the security level will normally be allocated to each user by the person responsible for managing the apparatus.
• a check is made to determine if the user has an adequate security level to view the diagram. This is achieved by comparing the user' s security level with the value of VIEWER for each instance of APPLICATION, INTERFACE, DIAGRAM and CONTENT which has been retrieved. If any one of these instances requires a security level greater than that possessed by the user, the user is denied access to the diagram. This is achieved by putting a suitable caption onto the display screen in a step S26 and then terminating execution of the routine.
• step S27 the diagram is displayed using the data which has been retrieved.
• step S28 the user is asked if he wishes to edit the displayed diagram. If the user indicates that he does not wish to edit the displayed diagram, the routine is terminated. If the user indicates in step S28 that he wishes to edit the displayed diagram, the diagram is edited in step S29 and the routine is then terminated.
• step S29 for editing the diagram will now be described.
• step S29 the user may edit the instance of DIAGRAM retrieved in step 21, any of the instances of CONTENT retrieved in step S22 and any of the instances of APPLICATION or INTERFACE retrieved in step S23.
• the user may edit any of these instances by displaying the attributes and their values and then changing the attribute value by using the keyboard 20.
• the user may edit an instance by positioning a pointer over the relevant diagram entity with the aid of mouse 19. The user then clicks a button on the mouse and this causes an edit menu to be displayed. The user then edits the relevant instance by following the instructions on the edit menu.
• the user When editing the instance of DIAGRAM retrieved in step S21, the user might change the security category of the viewer or the name of the diagram.
• the user When editing one of the instances of CONTENT retrieved in step S22, the user might change its location by altering the values for its x and y co-ordinates.
• the user could also change the entity (box or flow-line) which is displayed by changing the pointer for the diagram entity.
• the user could also transfer the displayed entity to another diagram by altering the pointer for the diagram identifier.
• the user When editing one of the instances of APPLICATION or INTERFACE retrieved in step S23, the user might change its name. In the case of an instance of INTERFACE, the user could change the identifier for the entity at its source or the identifier for the entity at its destination.
• step S29 If an instance of APPLICATION or INTERFACE is edited in step S29, the changes will be effective in all diagrams in which the instance is used.
• step S29 a user may also delete or add instances of CONTENT, APPLICATION, INTERFACE and DIAGRAM.
• Each of the classes APPLICATION, INTERFACE, DIAGRAM and CONTENT includes the attribute VIEWER which is used to specify the security of the viewer or user.
• the same security category is used for both viewing and editing.
• two or more diagrams may be displayed simultaneously on screen 21.
• diagram entities may be dragged by using mouse 19 from one diagram to another.
• a diagram entity When a diagram entity is dragged from one screen to another, it may be deleted from the first diagram and added to the second diagram. Alternatively, the diagram entity may be copied so that it remains in the first diagram and is added to the second diagram. This is achieved by creating and deleting instances of CONTENT as appropriate.
• the manner in which it is displayed may change.
• the shape, colour and scale of a diagram entity may change when it is dragged from one diagram to another. This is achieved by providing a set of display attributes for each class of diagram entity and providing values for these attributes for each instance of DIAGRAM.
• the display attributes could include an attribute COLOUR for specifying the colour in which an entity is displayed.
• the attribute COLOUR could be set to a value red for one instance of DIAGRAM and to a value green for another instance of DIAGRAM.
• the ability to display two or more diagrams simultaneously and to drag diagram entities from one diagram to another may be achieved by using the following software: the Solaris operating system from SUN Microsystems Ltd, 31-41 Pembroke Broadway, Camberley, Surrey, GUI5 3XD, together with the software package MASAI and LeLisp from Hog Limited, Surrey Technology Centre, 40 Occam Road, Guildford, GU2 5YH.
• the routine LINK is capable of finding these other boxes and flow lines and generating a diagram which shows all the boxes and flow lines connected to box 45.
• An example of a diagram which may be produced by the routine LINK is shown in Figure 7.
• Figure 7 shows box 43 connected by flow line 54 to box 45. This information is, of course, present on Figure 4.
• Figure 7 also shows boxes 60, 61, 62 connected by flow lines 63, 64, 65 to box 45. Boxes 60, 61 and 62 represent three further alarm collection centres, namely, alarm collection centres B, C and D.
• the flow chart for the routine LINK is shown in Figure 8 and this flow chart will be described with reference to generating the diagram shown in Figure 7.
• the user initially selects the box which is of interest.
• box 45 is selected.
• the user enters the identifier for the instance of APPLICATION containing data describing box 45.
• the user may perform step S40 by typing in the characters of the identifier.
• there may already be a diagram displayed on the screen which shows box 45 and the user then positions a pointer over box 45 with the aid of the mouse 19 and clicks a button to indicate that this is the selected box.
• a step S41 the selected instance of APPLICATION is retrieved.
• a step S42 an instance of INTERFACE which describes a flow line connected to box 45 is retrieved. In the present example, this may be the instance of INTERFACE which describes the flow line 54.
• a step S43 the instance of APPLICATION which describes the box connected to the other end of the flow line is retrieved. For example, if the instance of INTERFACE retrieved in step S42 describes flow line 54, then the instance of APPLICATION which describes box 43 is retrieved in step S43.
• a step S44 a check is made to determine if there are any more instances of INTERFACE. Steps S42 and S43 are then repeated for all remaining instances of INTERFACE which describe flow lines connected to box 45 and the corresponding remaining instances of APPLICATION which describe the boxes connected to the other ends of these flow lines.
• step ⁇ 45 a check is made to determine if the user has an adequate security level to view the boxes and flow lines which will be displayed. This step is similar to step S24 described with reference to Figure 6. If the user does not have an adequate security level, access is denied to him in a step S46.
• a step S47 the retrieved instances of APPLICATION are counted. In the present example, there are four such instances.
• the diagram is formatted. This is achieved by positioning the selected box at the centre of the diagram and then positioning the flow lines and boxes which are connected to the selected box at equal angular spacings around the selected box. In the present example, as there are four boxes connected to the selected box, they are displayed at 90° angles around the selected box.
• step S49 the new diagram is displayed.
• Steps S45, S47, S48 and S49 are then performed with the data in RAM 24.
• Figure 9 shows the alarm management system of Figure 4 at a later date.
• switch A no longer exists and a new switch, namely switch D, has been added.
• switch D is represented by box 70 and flow line 71 shows alarms being passed from switch D to alarm collection centre A.
• the apparatus 10 is capable of combining two diagrams representing a particular real world arrangement, such as the alarm management system of Figures 4 and 9, at two different dates. For example, it can combine the diagrams of Figures 4 and 9 to produce the diagram shown in Figure 10.
• the boxes and flow lines which are present in both Figures 4 and 9 are shown in a first manner, namely by solid lines.
• the box 40 and flow line 50 which are present only in Figure 4, are shown in a second manner, namely by dashed lines.
• the box 70 and the flow line 71 which are shown only in Figure 9, are shown in the diagram of Figure 10 in a third manner, namely with chain dotted lines.
• the solid, dashed and chain dotted lines of Figure 10 may be replaced by three different colours.
• a step S70 the user enters the identifier for the instance of DIAGRAM which contains general data for the first diagram.
• the user enters the identifier for the instance of DIAGRAM for the diagram shown in Figure 4.
• this instance of DIAGRAM is retrieved.
• Step S72 the instances of CONTENT, APPLICATION and INTERFACE for the first diagram are retrieved. Step S72 thus corresponds generally to steps S22 and S23 shown in Figure 6.
• a step S73 the user enters an identifier for the instance of DIAGRAM for the second diagram.
• the identifier can be entered either by keying the characters which form the identifier or, if the diagrams are already displayed, by positioning a pointer over the diagram with the aid of mouse 19 and then clicking a button on mouse 19.
• steps S74 and S75 the instance of DIAGRAM and the instances of CONTENT, APPLICATION and INTERFACE for the second diagram are retrieved.
• a step S76 a check is made to determine if the user has an adequate security level to view the boxes, flow lines and other data which will be shown in the eventual diagram. Thus step S76 corresponds generally to step S24 shown in Figure 6. If the user does not have an adequate security level, access is denied to him in a step S77.
• step S78 the diagram entities which are present in both the first and second diagrams are found. Step S78 is performed as follows.
• CONTENT For each instance of CONTENT for the first diagram, it is determined if there is a corresponding instance of CONTENT for the second diagram which points to the same instance of APPLICATION or INTERFACE as the instance of CONTENT for the first diagram. The resulting instances of CONTENT, APPLICATION and INTERFACE are then associated with each other.
• a step S79 the diagram entities which are present in both diagrams are displayed in the first manner mentioned above.
• boxes 41 to 45 and flow lines 51 to 54 are displayed as shown in Figure 10.
• a step S80 the diagram entities which are present only in the first diagram are found.
• These instances of CONTENT together with the corresponding instances of APPLICATION and INTERFACE are then associated together.
• the diagram entities present only in the first diagram are displayed in the second manner. Thus, at this stage, box 40 and flow line 50 are added to the displayed diagram.
• step S82 the diagram entities which are present only in the second diagram are found. This step is analogous to step S80.
• step S83 the entities present only in the second diagram are displayed in the third manner. Therefore, at this stage, box 70 and flow line 71 are added to the displayed diagram.
• steps S71, S72, S74 and S75 data is retrieved from the file server 15 and stored in RAM 24. Steps S76 to S83 are then performed on data in RAM 24. Because these steps are performed on data held in RAM 24, rather then in the file server 15, these steps are performed relatively quickly.
• the two diagrams may be kept separate.
• the boxes and flow lines which are present in both diagrams are shown in a first manner, for example by solid lines. Boxes and flow lines which are present only in the first diagram are shown in the first diagram in a second manner, for example by dashed lines. Boxes and flow lines which are present only in the second diagram are shown in the second diagram in a third manner, for example by chain dotted lines.
• file server 15 contains data for two diagrams having different dates but both showing the same real world arrangement, for example the alarm management system of Figure 4, the apparatus 10 is capable of producing a further diagram showing those entities of the arrangement which are present at a specified date which is between the dates of the two diagrams.
• the apparatus is able to interpolate between two diagrams.
• Figure 12 shows the result of interpolating between Figures 4 and 9 on a specified date.
• Figure 12 shows all the boxes and flow lines which are present in Figure 4 and, in addition, shows box 70 and flow line 71 of Figure 9.
• switch D has been added but switch A has not yet been removed from the alarm management system.
• the routine INTERPOLATE is responsible for interpolating between two diagrams and the flow chart for this routine in shown in Figure 13.
• the flow chart of Figure 13 will now be described with reference to Figures 4, 9 and 12.
• step S90 to S95 corresponding to steps S70 to S75 shown in Figure 11
• the data for the two diagrams is retrieved from the file server 15 and loaded into RAM 24.
• the data for both Figures 4 and 9 is retrieved in these steps.
• step S96 corresponding to step S24 of Figure 6
• a check is made to determine if the user has an adequate security level to view the retrieved diagram entities. If the user does not have an adequate security level, access is denied in a step S97.
• step S98 the user enters the date of interpolation. In the present example, this will be the date of the diagram shown in Figure 12.
• a step S99 the diagram entities which are present at the date of interpolation are found.
• the values of START-DATE and END-DATE are compared with the date of interpolation. If the date of interpolation falls within the period covered by the values of START-DATE and END-DATE, then both the instance of CONTENT and the corresponding instance of APPLICATION are put on a list for display.
• step S100 the diagram entities present at the interpolation date are displayed.
• a step 110 the user selects a box and enters the identifier for the instance of APPLICATION which describes the selected box. If a diagram is being displayed, the user may enter the identifier by clicking a button on mouse 19 with the mouse pointer over the selected box.
• a step Sill the routine finds each instance of DIAGRAM which contains general data about a diagram which includes the selected box. This is achieved as follows. For each instance of DIAGRAM, all the instances of CONTENT which point to the instance of DIAGRAM are found. Each of these instances of CONTENT is examined to determine if it points to the instance of APPLICATION for the selected box. Then, in a step SI12, a list is displayed of these instances of DIAGRAM.
• Figure 4 representing an alarm management system is only one example of the type of diagram which may be stored in the apparatus 10.
• Figure 15 represents another type of diagram which may be stored and this figure shows part of the structure of a company together with reporting lines.
• Figure 14 shows the main board represented box 100, department A represented by box 101, sections A, B, C represented by boxes 102, 103, 104, and the reporting lines represented by flow lines 105 to 108.
• diagram data is partitioned into scenarios and the scenarios are arranged in a hierarchical or parent-child structure.
• This development is suitable for modelling an evolving structure.
• Figure 16 shows how diagram data for modelling a telecommunications network may be partitioned into a parent scenario, namely a reference scenario, and three child scenarios, namely development scenarios A, B, C.
• the reference scenario contains diagram data for the network as presently existing and planned.
• the development scenarios contain diagram data for proposed developments to the network. If desired, the number of levels in the hierarchy may be increased, for example by creating child scenarios for development scenarios A, B and C.
• a user of the system opts to work in a single scenario.
• Each user has a personal access profile which determines which scenarios he has permissions to read or edit.
• the scenario he selects defmes the data which he can view or edit.
• Each instance of APPLICATION, INTERFACE, DIAGRAM and CONTENT is owned by a single scenario.
• the VIEWER attribute is modified to point to the owning scenario rather than an individual user.
• Instances owned by the parent scenario can be viewed by the child scenario, but instances owned by the child scenario cannot be viewed by the parent.
• instances of APPLICATION and INTERFACE which are owned by the parent scenario may be used as diagram entities in the child scenario.
• the DIAGRAM and CONTENT instances are owned by the child scenario, but ownership of the APPLICATION and INTERFACE instances remain with the parent scenario.
• an instance owned by the parent scenario may be modified in a child scenario by creating a copy of the instance which is owned by the child scenario. Instances created or modified in the child scenario may then be promoted to the parent scenario.
• routines COPY and PROMOTE are added to the main program 31. These two routines will now be described.
• the routine COPY is used for copying diagram data from a parent scenario to a child scenario.
• a check is made to determine if the user wishes to copy the data for any of the diagrams owned by the parent scenario. If the user does wish to copy data for one or more of the the diagrams in the parent scenario, this is achieved in step S133.
• step S133 for each diagram selected by the user, data is copied for the respective instance of DIAGRAM and all instances of CONTENT which point to the copied instance of DIAGRAM.
• Each copied instance is given a new identifier so that a particular instance is owned by one scenario only.
• each copied instance is given a pointer which points to the corresponding instance in the parent scenario.
• the new instances of CONTENT point to instances of APPLICATION and INTERFACE which are owned by the parent scenario.
• step S134 a check is made to determine whether the user wishes to copy any individual instances of APPLICATION or INTERFACE from the parent scenario to the child scenario.
• step S135 the data for each selected instance is copied from the parent scenario to the child scenario.
• Each copied instance is given a new identifier so that a particular instance is owned by one scenario only.
• each copied instance is given a pointer which points to the corresponding instance in the parent scenario.
• step S134 or S135 the routine continues with step S136 in which the diagrams in the child scenario are edited. This is achieved in the manner described with reference to step S28 in Figure 6. Although not shown, the use may return to steps S133 or S135 to copy further diagrams or instances if this is necessary during editing.
• the routine PROMOTE is used for promoting diagram data from a child scenario to a parent scenario. This routine may be used to promote all the data owned by the child scenario to the parent scenario, or the data for selected diagrams to the parent scenario, or the data for selected instances to the parent scenario. This routine will now be described with reference to Figure 18.
• step S141 the data for each instance in the child scenario is used to replace the existing data for the corresponding instance in the parent scenario. This is achieved by using the pointers in the instances in the child scenario which point to the corresponding instances in the parent scenario. Data for new instances in the child scenario is also added to the data contained in the parent scenario. Deletion of instances in the child scenario is handled by marking the instances as DELETED, rather than physically removing them from the database. Consequently, if an instance is deleted in the child scenario, the corresponding instance in the parent scenario will be overwritten by an instance marked as DELETED. This ' soft deletion' method ensures that deletion of the instance is made visible to all scenarios which make use of the instance and gives users of these scenarios an opportunity to make any necessary changes.
• the database Periodically, the database is purged to permanendy remove instances which have been marked as DELETED for a significant period, e. g. 6 months. It is possible that there will be a conflict between data contained in the child scenario and data contained in the parent scenario. For example, promoting data from the child scenario to the parent scenario may result in a new diagram entity in the child scenario overlapping with an existing entity in the parent scenario. Any such conflicts are recorded in step S141 for resolution in step S146. The routine continues with step S146 after step S141.
• step S142 determines if the user wishes to promote the data for any of the diagrams of the child scenario to the parent scenario. If the user does wish to promote any of the individual diagrams, this is achieved in step S143.
• step S143 the data for the instance of DIAGRAM for the selected diagram, together with the data for the associated instances of APPLICATION, INTERFACE and CONTENT which are owned by the child scenario are used to replace the data for the corresponding instances in the parent scenario. Any conflicts are recorded for resolution in step S146. After step S142 or step S143, the routine continues with step S144.
• step S144 a check is made to determine if the user wishes to promote the data for any individual instances of APPLICATION or INTERFACE from the child scenario to the parent scenario. If the user does wish to promote the data for any of the individual instances, this is achieved in step S146.
• step S145 the user may select the instances to be promoted from an index of instances.
• a diagram from the child scenario may be displayed simultaneously with the corresponding diagram from the parent scenario.
• the individual instances are promoted by dragging the corresponding diagram entities with the aid of mouse 19 from the child diagram to the parent diagram.
• step S144 or step S145 the routine continues with step S146 in which conflicts are resolved.
• step S146 where a diagram entity in the child scenario has been found to overlap a diagram entity in the parent scenario, the conflict may be resolved by the user by deleting the diagram entity in the parent scenario.
• the present invention can generate a diagram representing a real world structure in one domain ("the output domain") from a diagram representing the same real world structure in another domain ("the input domain").
• the input domain is the process domain
• the output domain is the systems domain.
• Figure 19 shows, by way of example, a diagram in its upper half which represents fault management for part of the network in the process domain. In its lower half, Figure 19 shows the corresponding diagram in the systems domain.
• the dashed lines show the links or mappings between the components of the diagram in the process domain and the components of the diagram in the systems domain.
• the object class APPLICATION is used to describe diagram entities in the form of boxes which represent components of the telecommunications network in the systems domain.
• an additional object class PROCESS is used.
• the object class PROCESS is used to describe diagram entities in the form of boxes which represent components of the telecommunications network in the process domain.
• the attributes for the object class PROCESS are shown in Table 5 below:
• each domain there is only a single object class for describing diagram entities in each domain, in general there may be one or more object classes for describing diagram entities in each domain.
• the links between diagram components in the input domain and diagram components in the output domain are held in instances of an object class CONTEXT MAP. More specifically, each instance of CONTEXT MAP holds a link between one diagram component in the input domain (for example, an instance of PROCESS) and one diagram component in the output domain (for example, an instance of APPLICATION).
• a diagram component in the input domain may have more than one link to diagram components in the output domain.
• the diagram component named Problem Reception in the process domain has a link to Alarm Control and a link to Load Fault Manager in the output domain.
• INPUT_CLASS_ID Pointer to object class of diagram entities in input domain
• INPUT CLASS ID is set to the name of one of the object classes ("the input object class") used to describe the diagram entities which represent the components of the modelled structure in the input domain.
• the input object class is PROCESS.
• INPUT_INSTANCE_ID is set to the value of the unique identifier for the instance ("the input instance") of this object class.
• OUTPUT_CLASS_ID is set to the name of one of the object classes ("the output object class" ) used to describe the diagram entities which represent the components of the modelled structure in the output domain.
• the output object class is APPLICATION.
• OUTPUT_INSTANCE_ID is set to the value of the unique identifier for the instance ("the output instance” ) of this object class.
• CONTEXT specifies the context in which the mapping occurs. For example, for fault management in a public telecommunications network there may be one mapping for fault management in the trunk network and another mapping for fault management in the access network. Where mappings can occur only in a single context, the attribute CONTEXT is not needed. In the present example, it is assumed that the mapping is in the trunk network.
• FIG. 20 there is shown a flow chart for a routine MAP which is used to generate a diagram in an output domain from a diagram in an input domain.
• a step S150 the user enters the identifier for the instance of DIAGRAM which describes the diagram in the input diagram.
• the user enters the identifier for the diagram shown in the upper half of Figure 19.
• the user enters the value of the attribute CONTEXT.
• the value indicates that the context for mapping from the input domain to the output domain is the trunk network.
• step S153 data is retrieved for an instance of CONTENT which points to the instance of DIAGRAM retrieved in step S150.
• step S154 it is determined if there are any instances of CONTEXT MAP for which the input instance is the instance found in step 153. If there are no such instances, the instance found in step S153 is put on a list of unmapped instances in a step S155.
• step S154 If, in step S154, it is found that there are instances of CONTEXT MAP for which the input instance is the instance retrieved in step S153, the routine goes from step S154 to step S156.
• step S156 for each instance of CONTEXT MAP for which the input instance is the instance retrieved in step S153, the identifier and the class name for the corresponding output instance are retrieved. Thus, in the present example, one or more identifiers for the object class APPLICATION are retrieved.
• step SI57 a check is made to determine if there are any more instances of CONTENT which point to the instance of DIAGRAM retrieved in step SI50. If there are any such instances, the routine returns to step 153. If there are no such instances, the routine continues with step S158.
• step SI58 By the time the routine reaches step SI58, in the present example there will have been retrieved a number of instances of APPLICATION. Some of these instances may have been retrieved several times. In the example shown in Figure 19, providing all the relevant instances of CONTEXT MAP exist, the instance of APPLICATION for the box labelled Central Fault Manager will have been retrieved three times. In step S158, using an appropriate algorithm, these instances of APPLICATION are used to generate the layout for a diagram in the output domain. A suitable diagram is described in an article entitled "Graph Drawing by Force Directed Placement", Software Practice and Experience, Volume 21(11), pages 1129- 1164, November 1991. This article is incorporated herein by reference.

Landscapes

• Engineering & Computer Science (AREA)
• Databases & Information Systems (AREA)
• Theoretical Computer Science (AREA)
• Data Mining & Analysis (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Stored Programmes (AREA)

Priority Applications (2)

Applications Claiming Priority (4)

Publications (1)

Family

ID=8217625

Family Applications (1)

Country Status (5)

Families Citing this family (3)

Family Cites Families (2)

• 1995
  • 1995-03-22 AU AU19546/95A patent/AU1954695A/en not_active Abandoned
  • 1995-03-22 CA CA002185439A patent/CA2185439C/en not_active Expired - Fee Related
  • 1995-03-22 JP JP7525025A patent/JPH09511348A/ja active Pending
  • 1995-03-22 EP EP95912322A patent/EP0753177A1/de not_active Ceased
  • 1995-03-22 WO PCT/GB1995/000631 patent/WO1995026532A1/en not_active Application Discontinuation

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events