Note: Descriptions are shown in the official language in which they were submitted.
12103/96 14:17 u:lpatentslword124739wo.doc
~1854~~
1 ~NiENDED SHEEfi
APPARATUS & METHOD FOR STORING DIAGRAM DATA
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.
When storing data for use in displaying diagrams, it is desirable that the
data can both be stored and retrieved in an efficient manner. In particular,
it is
desirable to be able to store data representing a particular diagram entity so
that
the diagram entity can be displayed in more than one diagram.
In EP-A-0 415 796 there is described an object-oriented display system
which allows the creation of graphic diagrams. In this system, each diagram is
created independently and there is no disclosure of using data representing a
particular diagram entity in more than one diagram.
According to one aspect of this invention there is provided 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 and a pointer to the software-object which describes the entity;
means for retrieving data describing the individual entities of a diagram;
and
means for using the retrieved data for displaying a diagram.
The present invention provides the advantage that data describing a
particular diagram entity can be used in displaying that diagram entity in
more than
one diagram.
The entities may include graphical shapes and flow lines connecting the
graphical shapes together.
1 1 /03/96 16:07 u:\patentslwo~d124739wo.doc
185439
When the entities 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, and 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.
According to a second aspect of this invention, there is provided 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
and a pointer to the software object which describes the entity;
retrieve data describing the individual entities of a diagram; and
use the retrieved data for displaying a diagram.
According to a third aspect of this invention, there is provided 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, said
method 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;
11!03!96 16:07 u:lpatents\word124739wo.doc
2185439
3
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 and a pointer to the software object which describes the entity;
retrieving data describing the individual entities of a diagram; and
using the retrieved data for displaying a diagram.
This invention will now be described in more detail, by way of example,
with reference to the accompanying drawings in which:
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;
Figure 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;
WO 95/26532 ~ ~: ~ PCT/GB95/00631
~1 y~43
- 4 -
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;
and
Figure 20 is a flow chart of a routine MAP which may
form part of the main program.
Referring now to Figure 1, there is shown an apparatus
10 for storing data for use in displaying diagrams. 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. By
providing three computers 11, 12, 13, three people may use
the apparatus simultaneously and access the data stored in
the file server 15. However, where it is required that only
one person should be able to use the apparatus at any one
time, it is sufficient to provide only one computer and the
WO 95/26532 ~ PCT/GB95/00631
- 5 -
apparatus will be described below with reference to only
computer 11.
The computer 11 is of conventional construction and
its main components are shown in Figure 2. These components
include a mouse~l9, 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.
Referring now to Figure 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 Ilog Limited of the
Surrey Technology Centre, 40 Occam Road, Guildford, GU2 SYH,
England. As the construction of GUIs is well known to those
skilled in the art, GUI 30 will not be described in further
detail.
The database management system 30 is the well known
Oracle Database Management System. The main program 31
compri s es routi nes STORE, RETRI EVE, LI NR, ADD, I NTERPOLATE
and LIST which are described in detail below. In the present
example, 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 Ilog 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.
Referring now to Figure 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. In the present example, these components
comprise switches A, B, C, alarm collection centre A, repair
team A and a network management centre. In Figure 4 these
WO 95/26532 ~ a PCTIGB95/00631
- 6 -
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. As represented by flow lines 50, 51, 52, each of
the switches A, B, C sends alarms to the alarm collection
centre A. As illustrated by 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 obj ects are modelled by software obj ects.
The real world objects may be divided into object types. For
example, 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 obj ect. 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. The attributes for these
software classes are listed in Tables 1 to 4 below and these
WO 95/26532 1 PCT/GB95/00631
tables will now be described in turn. The attributes for the
obj ect cl as s APPLI CATI ON are s hown i n Tabl a 1 bel ow:
TABLE 1
Name of object class: APPLICATION
Attribute Description
ID , unique identifier for entity
NAME name of entity
START-DATE start date of entity
END-DATE end date of entity
VIEWER security category for viewer
The object class APPLICATION is used to describe a
diagram entity in the form of a box. For a particular
instance of the object class APPLICATION, 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.
I n the pres ent exampl e, the obj ect cl as s APPLI CATI ON
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.
The attributes for the object class INTERFACE are
shown below in Table 2.
TABLE 2
Name of object class: INTERFACE
Attribute Descri tion
ID unique identifier for entity
WO 95/26532 ~ ~ ~ PCT/GB95/00631
_ g _
NAME name of entity
VIEWER security category for viewer
SOURCE-CLASS-ID class of entity at source of line
SOURCE-ENTITY-ID identifier of entity at source of line
DEST-CLASS-ID class of entity at destination of line
DEST-ENTITY-ID identifier of entity at destination of
line
An instance of INTERFACE describes a diagram entity in
the form of a flow line. For each instance of this object
class, 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. In the present
example, 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.
The attributes for the class DIAGRAM are given in
Table 3 below.
T'~BLE 3
Name of obj ect class: DIAGRAM
Attribute Descrirtion
ID unique identifier for diagram
NAME name of diagram
VIEW-DATE date of diagram
VIEWER security category for viewer
Each instance of DIAGRAM provides general data
relating to a particular diagram. A description of the
attributes is set out clearly in Table 3.
WO 95/26532 ~ ~ ~ ~ 4 3 ~ PCT/GB95/00631
_ g -
The attributes for the object class CONTENT are set
out below in Table 4.
TABLE 4
Name of object class: CONTENT
Attribute Descries
ID unique identifier for this entity on
the diagram
X-COORD x co-ordinate of this entity on the
diagram
Y-COORD y co-ordinate of this entity on the
diagram
BOX-TYPE type of box
LINE-TYPE type of line
VIEWER security category for viewer
DIAGRAM-ID pointer to identifier for diagram
CLASS-ID pointer to object clas s of entity
ENTITY-ID pointer to unique identifier
of entity
Each instance of CONTENT gives the location and other
details of an entity of a diagram on that diagram. Thus, X-
COORD and Y-COORD give the x and y co-ordinates of the entity
on the diagram. In the present example, 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
WO 95/26532 ~ ~ ~ PCT/GB95/00631
- 10 -
this routine is shown in Figure 5 and the flow chart will be
described with reference to storing the diagram of Figure 4.
In a step S1, general data for the diagram is entered
and stored as an instance of DIAGRAM.
Then, in a step S2, data describing one of the boxes
40 to ~ 45, for example box 40, is entered and stored as an
instance of APPLICATION. In a 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.
In a 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.
Where data is being stored for a whole set of
diagrams, it is possible that some of the boxes and flow
lines may appear in more than one diagram. Where this is the
case, for each box or flow line which is present in more than
one diagram, it is necessary to create only one instance of
APPLICATION or INTERFACE. If the data for a particular
instance of APPLICATION or INTERFACE is subsequently updated,
this is effective for all diagrams which include this
instance.
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.
In a step 520, the identifier for the instance of
DIAGRAM relating to the diagram of Figure 4 is entered.
Then, in a step S21, the instance of DIAGRAM is retrieved.
In a step 522, an instance of CONTENT is retrieved
which points to the instance of DIAGRAM retrieved in step
521. The instance of CONTENT retrieved in S22 points to an
WO 95/26532 2 7 ~ ~ 4 J ~ pCT/GB95/00631
- 11 -
instance of APPLICATION or INTERFACE. In 523, this instance
of APPLI CATI ON or I NTERFACE i s retri eyed. I n a s tep S 2 4, 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
APPLI CATI ON or I NTERFACE.
At thi s poi nt i n exe cuti ng the routi ne RETRI EVE, al 1
the instances of CONTENT, APPLICATION and INTERFACE for the
boxes 40 to 45 and flow lines 50 to 54 will be retrieved.
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.
In a step S25, 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.
If the user has an adequate security level, in a step
527, the diagram is displayed using the data which has been
retrieved.
In a step 528, the user is asked if he wishes to edit
the displayed diagram. I f 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. The procedure of
step S29 for editing the diagram will now be described.
In step 529, 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 523. The user may edit any of
WO 95/26532 ~ ~ ~ ~ PCT/GB95/00631
- 12 -
these instances by displaying the attributes and their values
and then changing the attribute value by using the keyboard
20. Alternatively, and preferably, 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.
When editing the instance of DIAGRAM retrieved in step
521, the user might change the security category of the
viewer or the name of the diagram.
When editing one of the instances of CONTENT retrieved
in step 522, 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.
When editing one of the instances of APPLICATION or
INTERFACE retrieved in step 523, 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.
If an instance of APPLICATION or INTERFACE is edited
in step 529, the changes will be effective in all diagrams in
which the instance is used.
In step 529, 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. In the present
example, the same security category is used for both viewing
and editing. Thus, if a user has an adequate security level
to view a diagram, he may also edit the diagram. By way of
modification, there may be separate security categories for
viewing and editing. This would be achieved by providing two
attributes in each class for security categories, one for
WO 95/26532 ~ ~ PCTlGB95/00631
- 13 -
viewing and one for editing. Where there are separate
security categories for viewing or editing, a user may be
given authority to view a diagram without being given
authority to edit it.
When the present invention is used in a windowing
environment, two or more diagrams may be displayed
simultaneously on screen 21. Also specific diagram entities
may be dragged by using mouse 19 from one diagram to another.
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.
When a diagram entity is dragged from one diagram to
another, the manner in which it is displayed may change.
Thus, 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. Thus, the display
attributes could include an attribute COLOUR for specifying
the colour in which an entity is displayed. Thus, for a
particular instance of APPLICATION, 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, GU15 3XD, together with
the software package MASAI and LeLisp from Ilog Limited,
Surrey Technology Centre, 40 Occam Road, Guildford, GU2 SYH.
When retrieving the data contained in the software
objects, it is retrieved from the file server 15 and stored
in RAM 24 of computer il.
WO 95/26532 r- . r. PCT/GB95/00631
~~ c~543':
- 14 -
Referring back to Figure 4, this figure shows the box
45 connected by flow line 54 to box 43. In other diagrams
stored in the file server 15, there may be other boxes
connected by other flow lines to the box 45. 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 LINR 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. In the present example, box 45 is selected. Then,
in a step 540, 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. Alternatively, 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.
In a step S41, the selected instance of APPLICATION is
retrieved.
In a step 542, 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. In a step 543, 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 543. In a step S44, a
WO 95/26532 PCT/GB95/00631
- 15 -
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.
In step 545, 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.
If the user has an adequate security level, in a step
547, the retrieved instances of APPLICATION are counted. In
the present example, there are four such instances. In a
step S48, 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.
In a step S49, the new diagram is displayed.
In the routine LINK, the instances of APPLICATION and
INTERFACE retrieved in steps S41, S42 and S43 are retrieved
from the file server 15 and loaded into RAM 24 of computer
11. Steps 545, 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. At the date shown in Figure 9, switch A
no longer exists and a new switch, namely switch D, has been
added. In Figure 9, 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
WO 95/26532 ~ ~ ~ ~ ~ ! PCT/GB95/00631
- 16 -
dates. For example, it can combine the diagrams of Figures
4 and 9 to produc a the di agram s hown i n Fi gure 10. I n Fi gure
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
i n Fi gure 9, are s hown i n the di agram of Fi gure 10 i n a thi rd
manner, namely with chain dotted lines. On a colour display
screen, the solid, dashed and chain dotted lines of Figure 10
may be replaced by three different colours.
The operation of combining two diagrams is performed
by the routine ADD and the flow chart for this routine is
shown in Figure 11. The flow chart of Figure 11 will now be
described with reference to Figures 4, 9 and 10.
At the start of the routine, in a step S70 the user
enters the identifier for the instance of DIAGRAM which
contains general data for the first diagram. Thus, in the
present example, the user enters the identifier for the
instance of DIAGRAM for the diagram shown in Figure 4. Then
in a step 571, this instance of DIAGRAM is retrieved.
In a step 572, 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
2 5 Fi gure 6.
Then, in a step 573, the user enters an identifier for
the instance of DIAGRAM for the second diagram. In both
steps S70 and S73, the identifier can be entered either by
keying the characters which form the identifier or, if the
3 0 di agrams are al ready di s pl ayed, by pos i ti oni ng a poi nter over
the diagram with the aid of mouse 19 and then clicking a
button on mouse 19.
In steps S74 and 575, the instance of DIAGRAM and the
instances of CONTENT, APPLICATION and INTERFACE for the
35 second diagram are retrieved. In 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
WO 95/26532 21 ~ 5 4 3 ~ pCT~GB95/00631
- 17 -
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
577.
In a step S78, the diagram entities which are present
in both the first and second diagrams are found. Step S78 is
performed as follows. 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.
In a step 579, the diagram entities which are present
in both diagrams are displayed in the first manner mentioned
above. Thus, at this stage, boxes 41 to 45 and flow lines 51
to 54 are displayed as shown in Figure 10.
In a step 580, the diagram entities which are present
only in the first diagram are found. In order to achieve
this, 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. If there is no corresponding instance of
CONTENT for the second diagram, then the instance of CONTENT
for the first diagram relates to a diagram entity present
only in the first diagram. These instances of CONTENT
together with the corresponding instances of APPLICATION and
INTERFACE are then associated together.
Then, in a step S81, 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.
In a step 582, the diagram entities which are present
only in the second diagram are found. This step is analogous
to step 580.
WO 95/26532 ~ ~ ~ ~ ~ -~ ~ PCT/GB95/00631
- 18 -
Lastly, in a step 583, 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.
In steps 571, S72, S74 and 575, 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.
By way of modification, instead of combining Figures
4 and 9 to produce a new diagram in which the boxes and flow
lines are represented in three different ways, the two
diagrams may be kept separate. In this case, in both
diagrams, 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.
Where 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. Thus, 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.
In the present example, 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. Thus, at the date
of Figure 12, 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
WO 95/26532 ~ PCT/GB95/00631
- 19 -
thi s routi ne i n s hown i n Fi gure 13. The f 1 ow chart of Fi gure
13 will now be described with reference to Figures 4, 9 and
12.
After entering this routine, in a set of steps 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
and 1 oaded i nto RAM 2 4. Thus , i n the pres ent exampl e, the
data for both Figures 4 and 9 is retrieved in these steps.
Subsequent steps are performed with the data in RAM 24.
10 In a step 596, 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.
15 Then, in a step 598, the user enters the date of
interpolation. In the present example, this will be the date
of the diagram shown in Figure 12.
Then, in a step 599, the diagram entities which are
present at the date of interpolation are found. In order to
achieve this, for each instance of CONTENT for the first
diagram which points to an instance of APPLICATION, 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.
If the interpolation date does not fall within the
period covered by the values of START-DATE and END-DATE, then
the instance of CONTENT and the corresponding instance of
APPLICATION are put on a list of entities which are not to be
displayed.
Instances of CONTENT for the second diagram which
point to instances of APPLICATION not present in the first
diagram are then examined in a similar manner.
For each instance of APPLICATION which is on the list
of entities which are not to be displayed, each instance of
INTERFACE which describes a flow line connected to the box
WO 95/26532 ~ ~ Q PCT/GB95l00631
- 20 -
described by the instance of APPLICATION is found and also
put on the list of entities which are not to be displayed.
In the present example, all of the diagram entities of
Figure 4 and in addition box 70 and flow line 71 of Figure 9
are to be displayed and no diagram entities are excluded.
'Then, in a step S100, the diagram entities present at
the interpolation date are displayed.
Referring now to Figure 14, there is shown the flow
chart for the routine LIST. This routine is capable of
producing a list of all the diagrams which contain a selected
box.
After entering this routine, in 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.
Next, in a step S111, 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 i ns tance of APPLI CATI ON f or the s el ected box. Then, i n
a step S112, a list is displayed of these instances of
DI AGRAM.
If the user wishes to display a diagram corresponding
to one of the instances of DIAGRAM on the list, the user may
achieve this by using the routine RETRIEVE.
The diagram of 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. Thus, Figure 14 shows the main board
represented box 100, department A represented by box 101,
CA 02185439 1999-04-30
- 21 -
sections A, B, C represented by boxes 102, 103, 104, and the
reporting lines represented by flow lines 105 to 108.
In a development of this invention, the 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.
By way of example, 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 coht~~.ns 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.
With this development, 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 defines the data
which he can view or edit.
Each instance of APPLICATION, INTERFACE, DIAGRAM and
CONTENT i s owned by a s i ngl a s c enari o. The VI EWER attri bute
is modified to point to the owning s~;~nario rather than an
individual user. Instances owned by t~?e parent scenario can
be viewed by the child scenario, but i-nstances owned by the
child scenario cannot be viewed by the parent. In addition,
instances of APPLICATION and INTERFACE which are owned by the
parent scenario may be used as diagram entities in the child
scenario. In this case, the DIAGRAM and CONTENT instances
are owned by the child scenario, but ownership of the
APPLICATION and INTERFACE instances remain with the parent
scenario.
The attributes of an instance may only be edited
whilst working in its owning scenario. However, 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
CA 02185439 1999-04-30
- 22 -
the child scenario. Instances created or modified in the
child scenario may then be promoted to the parent scenario.
I n order to achi eve this , routi nes COPY and PROMOTE are added
to the main program 31. These two routines will now be
described.
The routi ne COPY i s us ed f or c opyi ng di agram data from
a parent scenario to a child scenario. Referring now to
Figure 17, after entering the routine COPY, in a step S132 a
check is made to determine if the user wishes to copy the
data for any of the diagrams owned by the parent scenario.
I f the user does wish to copy data for one or more of the
diagrams in the parent sce~~a~rio, -this is achieved in step
S133.
In step 5133, 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. In
addition, 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. _. After step S132 or step S133, the routine
continues with step S134.
In step-5134, a check is made to determine whether the
user wishes tc~ copy any individual instances of APPLICATION
or INTERFACE from the parent scenario to the child scenario.
If the user does wish to copy any of these instances, this is
achieved in step 5135. In step 5135, 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. In addition, each copied instance is given a
pointer which points to the corresponding instance in the
parent scenario.
After step S134 or 5135, the routine continues with
step S136 in which the diagrams in the child scenario are
CA 02185439 1999-04-30
- 23 -
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 5133 or 5135 to copy further diagrams
or instances if this is necessary during editing.
The routi ne PROMOTE i s us ed f or promoti ng di agram dat
a
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. .-
After entering the routine PROMOTE, in a step 5140 a
check is made to determine if the user wishes to promote all
the data from the child scenario to the parent scenario. If
the user does wish to transfer all the data, this is achieved
in a step S141.
In step 5141, 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 scenar~,o 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.
Periodically, the database is purged to'Pe~anently remove
instances which have been marked as DELETED for a significant
peri od, e. g. 6 months .
WO 95/26532 j"~ PCT/GB95/00631
- 24 -
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 i n step 5141 for resolution in step 5146. The
routine continues with step 5146 after step 5141.
If the user does not wish to promote the entire child
scenario to the parent scenario, a check is made in step 5142
to determine 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 5143.
In step 5143, the data for the instance of DIAGRAM for
the selected diagram, together with the data for the
as s oci ated i ns tances of APPLI CATI ON, I NTERFACE 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 5142 or step 5143, the routine continues with step
5144.
In step 5144, 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
5146.
In step 5145, the user may select the instances to be
promoted from an index of instances. Alternatively, a
diagram from the child scenario may be displayed
simultaneously with the corresponding diagram from the parent
scenario. In this case, 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.
WO 95/26532 218 5 4 3 a PCT/GB95/00631
- 25 -
After step 5144 or step S145, the routine continues
with step 5146 in which conflicts are resolved. By way of
example, in step 5146, 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.
I n a further devel opment, the pres ent i nventi on 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" ). By way of example, this further development will
be described with reference to a public telecommunications
network in which the input domain is the process domain and
the output domai n i s the s ys terns domai n. Fi gure 19 s hows , 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.
In this further development, 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. With this further
development, 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
bel ow:
TABLE 5
Name of object class: PROCESS
Attribute Description
ID Unique identifier for entity
NAME Name of entity
VIEWER Security category for viewer
WO 95/26532 PCT/GB95/00631
2135439_
A1 though i n the pres ent exampl a there i s onl y a s i ngl a
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 obj ect 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 domai n ( f or exampl e, an i ns tance o f APPLI CATI ON ) .
A diagram component in the input domain may have more than
one link to diagram components in the output domain. For
exampl e, i n Fi gure 19, the di agram component named Probl em
Reception in the process domain has a link to Alarm Control
and a link to Load Fault Manager in the output domain.
The attributes for the obj ect class CONTEXT MAP are
shown in Figure 6 below.
TABL E 6
Name of object class: CONTEXT MAP
Attribute Description
ID Unique dentifier for instance
i
INPUT CLASS ID Pointer to object class of diagram
entitiesin input domain
INPUT INSTANCE ID Pointer to unique identifier for
diagram entity in input domain
OUTPUT CLASS ID Pointer to object class of diagram
entitiesin output domain
OUTPUT INSTANCE ID Pointer to unique identifier for
diagram entity in output domain
CONTEXT Context in which mapping occurs
VIEWER Securitycategory for viewer
The attributes ID and VIEWER are set in a similar
manner to the corresponding attributes for the other classes
described above. INPUT CLASS ID is set to the name of one of
WO 95/26532 2 18 5 4 3 9 PCT/GB95/00631
- 27 -
the obj ect classes (" the input obj ect class" ) used to
describe the diagram entities which represent the components
of the modelled structure in the input domain. In the
present example, 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
obj ect 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. In the present
exampl e, the output obj ect cl as s i s APPLI CATI ON.
OUTPUT INSTANCE ID is set to the value of the unique
identifier for the instance ("the output instance") of this
obj ect 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.
Referring now to Figure 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.
After entering the routine MAP, in a step 5150, the
user enters the identifier for the instance of DIAGRAM which
describes the diagram in the input diagram. In the present
example, the user enters the identifier for the diagram shown
in the upper half of Figure 19. Then in a step S152, the
user enters the value of the attribute CONTEXT. In the
present example, the value indicates that the context for
mapping from the input domain to the output domain is the
trunk network.
CA 02185439 1999-04-30
- 28 -
Next, in a step 5153, data is retrieved far an
instance of CONTENT which points to the instance of DIAGRAM
retrieved in step 5150.
In step 5154, 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 5153 is put on a list of unmapped
instances in a step S155.
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 5153, the routine goes from step 5154 to
step 5156. In 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 obj ect class
APPLI CATI ON are retri eved.
After step S155 or step S156, the routine continues
with step S157. In this step, a check is made to determine
if there are.any more instances of CONTENT which point to the
instance of DIAGRAM retrieved in step 5150. If there are anx
such instances, the routine returns to step 153. If there
are no such instances, the routine continues with step 5158.
By the time the routine reaches step 5158, in the
present example there will have been retrieved a number of
instances of APPLICATZOt~. 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-
116 4, November 19 91.
WO 95/26532 ~ PCTIGB95/00631
- 29 -
Next, in a step 5159, the output domain diagram
generated in step 5158 is displayed. However, if any
unmapped instances have been found in step 5154, the diagram
will be incomplete.
Finally, in a step 5160, the list of unmapped
instances is displayed. If there are any unmapped instances,
the user can then create appropriate instances of CONTEXT MAP
so that the instances are no longer unmapped. The routine
may then be run again so as to obtain a complete diagram in
the output domain.
