Method and apparatus for pattern-based flowcharting of source code

[0002] The invention relates to systems and methods for reverse engineering software and more particularly relates to a method and apparatus for pattern-based Flowcharting of source code.

[0003] Source code is the most important object of the software engineering process. Significant effort is put into understanding source code through reverse engineering, and in fact understanding source code is the main issue of the reverse engineering process. Many existing tools are available which assist in understanding source code. These include tools which produce listings of source code and cross reference tools. There are many tools available today which are capable of producing various types of graphical representations of source code. These include for example flowcharts which graphically illustrate control flow of individual procedures or functions, and class hierarchy diagrams which show inheritance relations between classes.

[0004] In reverse engineering tasks it would be desirable for any graphical diagrams created to have a uniform presentation style which is independent of the individual style of the original author of the source code. The reason is that the person performing the reverse engineering task is usually not the original author of the source code. Also, reverse engineering is usually performed across several software units which have different original authors.

[0005] Graphical diagrams usually consist of primitive graphical symbols connected with lines. Existing graphical tools are generally only capable of presenting and manipulating primitive graphical symbols and lines independently. This leads to a situation where graphical diagrams of source code are subject to individual layout style.

[0006] It is an object of the invention to obviate or mitigate one or more of the above mentioned disadvantages.

[0007] The invention provides systems and methods for extracting information from source code and presenting this information in the form of graphical diagrams which consist of predefined building blocks (called graphical patterns). Each graphical pattern consists of a number of primitive graphical symbols which are graphically arranged and connected with lines. An important characteristic of these graphical patterns is that they may contain predefined places where further patterns can be inserted recursively. These predefined places in the graphical patterns are called nested sockets.

[0008] The final appearance of a graphical pattern depends on the patterns inserted into the nested sockets. All layout and editing operations are applied to graphical patterns and not to individual primitive symbols and lines. A particular pattern is represented in the form of a set of formulae for the computation of layout attributes. When a graphical diagram of a particular source code construct is required, the source code entity is first converted into nested patterns and then the layout attribute computations are performed. The graphical diagram is created by further converting the nested patterns into display directives. The display directives when executed by a suitable graphical engine produce the desirable graphical image which can be scaled without re-evaluating layout attributes.

[0009] FIG. 1 is a block diagram of a pattern-based visualization system according to an embodiment of the invention;

[0010] FIG. 2A is a flowchart of the steps performed in defining a particular implementation of the invention;

[0011] FIG. 2B is a flowchart of the steps executed in a pattern-based flowcharting method according to an embodiment of invention;

[0012] FIG. 2C is a flowchart of the steps executing in computing layout attributes;

[0013] FIG. 3 is an illustration of a set of top-level patterns (section pattern and procedure pattern);

[0014] FIG. 4 is an illustration of a set of primitive patterns, which can be contained in the section diagram;

[0015] FIG. 5 is an illustration of composite patterns which can be contained in the procedure diagram;

[0016] FIG. 6 is an illustration of primitive patterns which can be contained in a procedure diagram;

[0017] FIG. 7 is an illustration of a set of display primitives for use in generating graphical display;

[0018] FIGS. 8, 9, and 10 illustrate layout attributes for the full conditional construct;

[0019] FIGS. 11-14 are examples of graphical diagrams created using systems and methods provided by embodiments of the invention;

[0020] FIG. 15 is an example of an N-ary tree in pictorial form; and

[0021] FIG. 16 is a tabular version of the N-ary tree of FIG. 15.

[0022] FIG. 1 is a simplified block diagram of an apparatus according to an embodiment of the invention for use in generating graphical representations of source code. A general purpose processing platform 10 is connected to a pattern language repository 12 and a display 14. In addition, there is a source code repository 16 in which the source code to be graphically represented is stored. There is a set of language dependent definitions 18 accessible by the processing platform 10, and a set of language independent definitions 20 also accessible by the processing platform 10. The processing platform 10 may be any general purpose processing platform capable of running software implementing the flowchart generation methods described herein, for example a personal computer, or a mainframe to name a few examples. The source code repository 12 may be any conventional repository for source code. The pattern language repository 12 is preferably in random access memory for fast readability, but not necessarily be so. There may be a different language dependent definitions file 20 for each source language to be input for graphical representation. The language independent definitions file 18 contains definitions which are not a function of a particular source code. The language independent definitions file 18 and the language dependent definitions file 20 may be separate or combined entities. The information they contain may alternatively be encoded directly as part of the software running on the processing platform.

[0023] There are many ways of implementing the flowchart generation methods provided by embodiments of the invention. The steps in defining a particular implementation will be described by way of overview with reference to the flowchart appearing in FIG. 2A. The details of each of the steps appearing in this flowchart will be presented later.

[0024] To begin, graphical patterns must be defined. Any graphical representation will ultimately be composed of these graphical patterns, so the graphical patterns are the building blocks of the graphical representations. Each graphical pattern is source language independent and corresponds with structured programming constructs available in most programming languages. For example, almost all programming languages include some sort of IF-THEN-ELSE programming construct, and there would be a graphical pattern defined for this programming construct which is the same for all programming languages. The definitions of graphical patterns are part of the language independent definitions 18 of FIG. 1.

[0025] The next step is to specify a pattern language. A source code pattern language is an intermediate language which is the same for all source languages which is basically a common ground from which to start generating the graphical displays.

[0026] Next, a series of mapping rules need to be defined which permit a given source language to be translated into the above defined pattern language. These mapping rules will of course be source language dependent and form part of the language dependent definitions 18 of FIG. 2.

[0027] For each pattern, a series of layout attributes are defined. The attributes of a given pattern define a particular realization of the pattern. A set of formulae for computing these layout attributes must also be defined. These are source language independent.

[0028] Display directives must also be defined, or alternatively these may already be defined in an existing graphics package. Display directives are the lines, blocks etc. used to physically generate the graphical patterns. These are language independent.

[0029] Finally, a set of layout attribute to display directive mappings are defined, these enabling an actual graphical display to be generated from a set of defined layout attributes. These are source language independent.

[0030] Now with reference to FIG. 2B, the steps carried out in generating a graphical representation of source code once a particular implementation of the invention has been defined will be described by way of overview. Further details are presented below.

[0031] To begin, the source code is translated into pattern language using the above defined mapping rules. Next, all of the layout attributes in the resulting pattern language are computed using the above referenced set of formulae. Next, the layout attribute to display directive mappings are executed and used to generate an actual display.

[0032] FIGS. 3, 4, 5, and 6 illustrate a complete set of graphical patterns which can be used to visualize source code in traditional imperative programming languages (e.g. C, Pascal, Modula-2, etc.). The actual graphical appearance of the suggested set of patterns can vary.

[0033] To enhance the understanding of graphical representation of patterns, various text regions may be added. In the illustrated embodiments, ovals are used to represent text regions. The contents of these region depends on the source code construct. Ovals with diagonal lines represent predefined text labels. The text of predefined labels is independent of source code constructs (but can depend on the source language). Star-like symbols with a frame represent nested sockets, i.e. variable size areas, which contain other patterns. It is important to understand that the star-like symbols for nested sockets are not actually displayed when a final flow chart is created nor is the frame in which it is shown. Rather, these are used to act as placeholders in the creation of the final flow chart which will contain some nested diagrams in accordance with the structure of the source code. Furthermore, the text regions and predefined labels are not part of the graphical pattern per se, but rather are simply part of a notation selected for describing the graphical pattern. Other lines belong to the patterns themselves. The actual appearance of each pattern may vary because of the nested patterns as well as because of the scale. Patterns may use colour to emphasize certain elements (e.g. continue lines in loops, labels, symbols containing function calls, local variable names, global variable names, etc). The display primitives used in patterns are illustrated in FIG. 7 and include a vertical line 50, horizontal line 52, text line 54, rectangle 56, open rectangle 58, rectangle with one double side 60, rectangle with two double sides 62, rectangle with a folded corner 64, rhomb 66, circle 68, return 70, start 72 and ground (finish) 74. These display primitives are described in detail below.

[0034] Referring next to FIG. 3 two top-level patterns are shown, one each for a section diagram pattern generally indicated by 100 (a section may be equivalent to a file in some systems), and a procedure diagram pattern generally indicated by 110. It is noted that an object-oriented language (e.g. C++, Java) will need an additional top-level pattern to represent class (class pattern).

[0035] The section diagram pattern 100 represents global definitions of a section. A heading region 102 contains the text which describes the section. A nested socket 104 labelled “Definitions” contains a vertically stacked list of primitive patterns relevant to the section. The primitive patterns of a section diagram will be described below with reference to FIG. 4. The nested patterns in the Definitions socket 104 correspond to entities defined in the section.

[0036] The procedure diagram pattern 110 represents a flowchart for a single procedure definition. A heading region 112 contains text which describes the procedure (procedure name and procedure signature including return type and parameter types). A comment region 114 contains comment text describing the procedure. A nested socket 116 labelled “Body” corresponds to the body of the procedure. This socket contains a vertically stacked list of composite (see FIG. 5) and primitive (see FIG. 5) patterns of a procedure diagram. Also shown are start and finish primitives 118, 120.

[0037] Referring next to FIG. 4, the primitive patterns which can be contained in the section diagram 100 of FIG. 3 will be described. A section diagram does not contain any composite patterns.

[0038] The data definition primitive pattern 130 represents a single data declaration. It consists a rectangle with a folded corner, and containing a single text region labelled “declaration” which contains the text of the data declaration.

[0039] The procedure definition primitive pattern is generally indicated by 131 and is used to represent a single procedure definition. It includes a name region 132 which contains a procedure name. It also includes an open rectangle 134 labelled “signature” which contains the procedure signature which may for example include the return type of the procedure if any and parameter types.

[0040] The macro definition primitive pattern is generally indicated by 135 and is used to represent a single macro definition. It includes a name region 136 which contains a macro name. It also includes an open rectangle 138 labelled “Body” which contains macro parameters and the body of the macro definition.

[0041] The comment primitive pattern 140 is used to represent a comment. It simply consists of a dotted line open rectangle with a text region labelled “comment” which corresponds to the text of the comment. Consecutive comments are preferably merged into a single comment pattern. The dotted lines are shown for the purpose of locating and sizing the comment. However, when displayed, preferably the comment primitive does not include these dotted lines.

[0042] FIG. 5 illustrates a set of composite patterns, which can be contained in the procedure diagram. A single branch conditional pattern is generally indicated by 150 and is used to represent a conditional statement in the short form (if..then). A rhomb 152 is indicative of the start of a conditional pattern. There is an open rectangle 154 labelled “condition” which contains the text of the boolean expression in the if-part of the conditional. There is a nested socket 162 labelled “statement” which corresponds to the then-part of the conditional statement. This pattern contains predefined text labels 153, 158, and 160 which might for example contain the text “IF”, “THEN” and “ENDIF” respectively.

[0043] A full conditional pattern is generally indicated by 170 and is used to represent a conditional statement with two branches, for example in the form (if..then..else). A rhomb 172 is indicative of the start of a conditional pattern. There is an open rectangle 174 labelled “condition” which contains the text of the boolean expression in the if-part of the conditional. There is a nested socket 182 labelled “statement1” which corresponds to the then-part of the conditional statement. There is a second nested socket 184 labelled “statement2” which corresponds to the else-part of the conditional statement. This pattern contains predefined text labels 173, 176, 178, and 180 which might for example contain the text “IF”, “THEN”, “ELSE” and “ENDIF” respectively.

[0044] A loop pattern is generally indicated by 190 and corresponds to loops with preconditions (for and while-loops). A rhomb 192 is indicative of the start of a conditional pattern. There is an open rectangle 194 labelled “condition” which contains the text of the boolean expression in the pre-condition part of the loop. There is a nested socket 202 labelled “body” which corresponds to the body of the loop. This pattern contains predefined text labels 193, 196, 198 which might for example contain the text “WHILE”, “DO”, “END-DO” respectively. The left vertical line 191 corresponds to the exit from the loop. The right line 195 corresponds to the continuation of the loop.

[0045] A repeat-until loop pattern is generally indicated by 210 and corresponds to loops with postconditions (do-until loops). The pattern starts with a nested socket 222 labelled “body” which corresponds to the body of the loop which is always executed at least once. A rhomb 212 is indicative of the conditional and has an open rectangle 214 labelled “condition” which contains the text of the boolean expression in the post-condition part of the loop. This pattern contains predefined text labels 213, 216, which might for example contain the text “DO”, “UNTIL” respectively. The left vertical line 211 corresponds to the continuation of the loop.

[0046] The switch pattern is generally indicated by 230 and corresponds to the switch construct. A rhomb 231 is indicative of the start of a conditional pattern. There is an open rectangle 232 labelled “condition” which contains the text of the boolean expression under test. Depending upon the result of the test, in this example one of three branches are taken. One branch has a nested socket 234 labelled “branch1”, another branch has a nested socket 236 labelled “branch2”, and another branch has a nested socket 238 labelled “default”. Each branch of a switch statement may result in an exit from the switch as in branch1 (for example break statement in C), or a fall-through to the next branch of the switch as in branch2 (for example absence of a break statement in C). There may be an exit path 254 which results in all of the branches being skipped. The nature of the flow between the branches is specified by the flow of the connecting lines. It can be seen that there may be many different specific patterns for a switch. Each branch starts with a text region 240,242,246 corresponding to the label of that branch. This pattern also uses some predefined labels 248,250,252 which may for example contain the text “SWITCH”, “EXIT” and “END”.

[0047] A block pattern is generally indicated by 260 and corresponds to a block statement. It contains a single nested socket 261 labelled “Body” which correspond to the body of the block. This pattern uses some predefined labels 262, 264 which may for example contain the text “block”, “endblock” or “{” and “}” for example.

[0048] A labelled statement pattern is generally indicated by 270 and corresponds to a labelled statement. This is represented by a circle 272 and a text region 274 containing the text of the label (represented as a solid grey oval). There is a nested socket 276 labelled “statement” which corresponds to the labelled statement.

[0049] The primitive patterns of procedure diagrams will now be described with reference to FIG. 6. The local data declaration primitive pattern is generally indicated by 300 and corresponds to local data declarations which might appear in blocks for example. The pattern consists of a rectangle 302 with an open rectangle 304 containing text labelled “Declarations” which contains the text of one or many data declarations. Multiple local data declarations can be merged into a single region. This pattern uses a predefined label 306 which may for example contain the text “dcl”.

[0050] A task primitive pattern is generally indicated by 310 and corresponds to assignment statements. The pattern consists of a rectangle 312 with an open rectangle 314 containing text labelled “statements” which contains the text of one or many assignment statements. Multiple assignment statements can be merged into a single region. This pattern uses a predefined label 316 which may for example contain the text “task”.

[0051] A procedure call primitive pattern is generally indicated by 320 and corresponds to a procedure call statement. The pattern consists of a rectangle with two double sides 322 with an open rectangle 324 containing text labelled “parameters” which contains the name of the procedure being called and the actual parameters of the procedure call. optionally, the name of the procedure can be used in a text region 326.

[0052] A return primitive pattern is generally indicated by 330 corresponds to a return statement. The pattern consists of a return symbol 332 with an open rectangle 334 containing text labelled “expression” which corresponds to the return expression.

[0053] A goto primitive pattern is generally indicated by 340 and corresponds to any statement which results in unconditional transfer of control (e.g. break, continue, goto statements). The pattern consists of a circle 342 and a text region 344 labelled “label” which corresponds to the name of the statement or to the label in a goto statement for example.

[0054] A macro call primitive pattern is generally indicated by 350 corresponds to a macro call statement. The pattern consists of a rectangle with one double side 352 with an open rectangle 354 containing text labelled “parameters” which contains the name of the macro being called and the actual parameters of the macro call. Optionally, the name of the macro can be used in a text region 356.

[0055] The comment primitive 360 is the same as that described previously in the context of section primitive patterns.

[0056] FIG. 7 illustrates the set of display primitives, which can be used to produce the actual graphical diagrams from nested pattern expressions with layout attributes. The suggested set of display directives can be easily implemented in any graphical language (e.g. Postscript, Java, Tk, etc.). The suggested set of display directives is used as an example. The actual appearance of the display directives can vary. The suggested set of directives is not necessarily the minimal set of graphical primitives, which can be used to produce graphical images of diagrams.

[0057] The vertical line display primitive 50 is defined by four attributes, namely StartH, StartV, EndV, and Colour. StartH specifies the horizontal position of the starting point of the line. StartV specifies the vertical position of the starting point of the line. EndV specifies the vertical position of the end point of the line. Colour specifies the colour of the line.

[0058] The horizontal line display primitive 52 is defined by five attributes, namely StartH, StartV, EndH, Colour, and Dash. StartH specifies the horizontal position of the starting point of the line. Startv specifies the vertical position of the starting point of the line. EndH specifies the horizontal position of the end point of the line. Colour specifies the colour of the line. Dash specifies whether the line is dashed or not.

[0059] The text line display primitive 54 is defined by three attributes, namely PosH, PosV, and String. PosH specifies the horizontal position of the beginning of the first character of the text. PosV specifies the vertical position of the first character of the text. String specifies the contents of the text.

[0060] The rectangle display primitive 56 is defined by five attributes, namely PosH, PosV, Width, Height, and colour. PosH specifies the horizontal position of the upper left corner of the rectangle. PosV specifies the vertical position of the upper left corner of the rectangle. Width specifies the width of the rectangle. Height specifies the height of the rectangle. Colour specifies the colour of the rectangle.

[0061] The open rectangle display primitive 58 is defined by five attributes, namely PosH, PosV, Width, Height, and Dash. PosH specifies the horizontal position of the upper left corner of the open rectangle. PosV specifies the vertical position of the upper left corner of the open rectangle. Width specifies the width of the open rectangle. Height specifies the height of the open rectangle. Dash specifies the whether the open rectangle is made of dashed lines or not.

[0062] The rectangle with one double side display primitive 60 is defined by four attributes, namely PosH, PosV, Width, and height. PosH specifies the horizontal position of the upper left corner. PosV specifies the vertical position of the upper left corner. Width specifies the width of the figure. Height specifies the height of the figure.

[0063] The rectangle with two double sides display primitive 62 is defined by four attributes, namely PosH, PosV, Width, and height. PosH specifies the horizontal position of the upper left corner. PosV specifies the vertical position of the upper left corner. Width specifies the width of the figure. Height specifies the height of the figure.

[0064] The rectangle with a folded corner display primitive 64 is defined by four attributes, namely PosH, PosV, Width, and height. PosH specifies the horizontal position of the upper left corner. PosV specifies the vertical position of the upper left corner. Width specifies the width of the figure. Height specifies the height of the figure.

[0065] The rhomb display primitive 66 is defined by four attributes, namely PosH, PosV, Width, and height. PosH specifies the horizontal position of the left corner of the rhomb. PosV specifies the vertical position of the left corner of the rhomb. Width specifies the width of the rhomb. Height specifies the height of the rhomb.

[0066] The circle display primitive 68 is defined by two attributes, namely PosH and PosV. PosH specifies the horizontal position of the centre of the circle. PosV specifies the vertical position of the centre of the circle.

[0067] The return display primitive 70 is defined by two attributes, namely PosH and PosV. PosH specifies the horizontal position of the centre of the figure. PosV specifies the vertical position of the centre of the figure.

[0068] The start display primitive 72 is defined by four attributes, namely PosH, PosV, Width, and Height. PosH specifies the horizontal position of the upper left corner of the figure. PosV specifies the vertical position of the upper left corner of the figure. Width specifies the width of the figure. Height specifies the height of the figure.

[0069] The ground display primitive 74 is defined by two attributes, namely PosH, and PosV. PosH specifies the horizontal position of the centre of the figure. PosV specifies the vertical position of the centre of the figure.

[0070] The first step in developing a graphical representation of source code is to translate the source code into a pattern language provided by an embodiment of the invention. The pattern language is an intermediate language between the source code and the full graphical representation which is source language independent. Of course, the process of translating from an actual source language to the intermediate language will be source language dependent.

[0071] A formal specification of the pattern language will now be presented. The pattern language captures some essential structural characteristics of the graphical patterns. An algebraic specification notation is used. Each algebraic specification is a set of types (sorts), and a set of constructor functions, which can be used to create values of these types. A type describes a category of similar entities. Each is a collection of many (possible an infinite number of) entities. Each entity within a type is distinct from others, yet all entities share some common characteristics. In the case of our graphical patterns, these characteristics include the visual appearance (as presented in FIGS. 3 and 4 described above and layout attributes (as presented in further detail below. Constructors are used to uniquely represent individual entities. Each constructor can have parameters. In the terminology of graphical patterns, parameters correspond to regions and nested sockets. Constructors with parameters capture the idea that one graphical pattern can be contained within other graphical patterns, thus resulting in potentially very complex diagrams.

[0072] The provided algebraic specification of the pattern language introduces a concise textual notation to describe the structural properties of graphical diagrams. It also describes the so-called “well-formedness” rules for graphical diagrams by providing formal guidelines to how diagrams could be built. In general, there is a one-to-one relationship between elements of visual diagram language (referred to as graphical patterns) and constructors. Constructor terms (expressions, containing nested constructors) uniquely describe complex diagrams. The specification uses the following typesetting conventions:

[0073] MyType—the name of the type

[0074] Constructor—the name of the constructor function

[0075] Notation F: T1Type, T2Type→T3Type defines constructor F such that the domain of constructor F is a type of type <T1Type, T2Type> and that it creates a value of type T3Type.

[0076] The pattern language for section diagrams is a type S=<Ts,Σs>, where Ts is a particular set of subtypes defined below, and Σs is a set of rules defined below for combining the subtypes in Ts.

[0077] The set of subtypes Ts used in the pattern language for section diagrams is:

[0078] Ts={TextType, SectionDiagramType, DeclListType, DeclType}.

[0079] The TextType type applies to any textual regions within graphical patterns. The SectionDiagramType is a type which corresponds to a Section Diagram pattern, the ultimate product of the language specification for section diagrams. The type DeclListType is a grouping/vertically stacked list of primitive patterns. Each individual primitive pattern of a section diagram pattern is of the type DeclType (see FIG. 4). Entities of type DeclType include: Data Definition, Procedure Definition, Macro Definition and Comment patterns.

[0080] The set of rules Σs for combining the above four subtypes in the pattern language for section diagrams is:

[0081] Σs={

[0082] Section: TextType, DeclListType→SectionDiagramType

[0083] DataDecl: TextType→DeclType

[0084] ProcDecl: TextType, TextType→DeclType

[0085] MacroDecl: TextType, TextType→DeclType

[0086] Comment: TextType→DeclType

[0087] DeclList: DeclType, DeclListType→DeclListType

[0088] DeclList: DeclType→DeclListType

[0089] }

[0090] The rules consist of constructors which act upon one or more entities of the allowed types (those belonging to Ts) to produce another entity of one of the allowed types.

[0091] The first constructor, Section relates to a Section pattern 100 of FIG. 3. It takes an entity of type TextType and an entity of type DeclListType, and creates an entity of type SectionDiagramType. The entity of type TextType is the heading field, and the entity of type DeclListType is the list of primitives represented by nested socket 104.

[0092] The second constructor, DataDecl relates to the Data Definition pattern. It takes an entity of type TextType and creates an entity of type DeclType. Referring to FIG. 4, the element of type TextType relates to the text within the rectangle with folded corner element 130.

[0093] The ProcDecl constructor relates to the Procedure Definition pattern 131 of FIG. 4. Constructor ProcDecl has two parameters. The first parameter, which has type TextType, corresponds to the name region of the Procedure Definition pattern. The second parameter, which is also of type TextType, corresponds to the Signature region of the Procedure Definition pattern.

[0094] The MacroDecl constructor relates to the Macro Definition pattern 135 of FIG. 4. Constructor MacroDecl has two parameters. The first parameter (of type TextType) corresponds to the Name region of the Macro Definition pattern. The second parameter (also of type TextType) corresponds to the Body region 138 of the Macro Definition pattern.

[0095] The Comment constructor relates to the Comment pattern 140 of FIG. 2. A parameter of type TextType corresponds to the Comment region of the Comment pattern.

[0096] The DeclList constructor relates to the grouping of primitive patterns. This corresponds to the nested socket 104 in the Section Diagram of FIG. 1.

[0097] The above specification of Section Diagrams emphasises the distinction between type TextType and the other three types (SectionDiagramType, DeclType, DeclListType) because type TextType is left undefined within the specification, while other types are defined (by mentioning the resulting types of constructors).

[0098] For the purpose of illustrating the Section pattern language specification, consider the following small Section module in the C language. The corresponding section diagram for this example is illustrated in FIG. 11.

[0099] - - - module MyFile.c - - -

[0100] #define ONE 1

[0101] int x;

[0102] int y;

[0103] /* increment function */

[0104] f(int x) {return x+ONE;}

[0105] /* complex computation */

[0106] g(int x) {return f(x)+y;}

[0107] The corresponding specification in pattern language is as follows (where indentation is shown for readability):

[0108] Section(“MyFile.c”,

[0109] DeclList(MacroDecl(“ONE”, “1”),

[0110] DeclList(DataDecl(“int x;”),

[0111] DeclList(DataDecl(“int y;”),

[0112] DeclList(Comment(“/* increment function */”),

[0113] DeclList(ProcDecl(“f”,“int x”),

[0114] DeclList(Comment(“/* complex computation */”,

[0115] DeclList(ProcDecl(“g”,“int x”)))))))))

[0116] The actual rules for generating the pattern language version of a segment of source code are language dependent and will be described in detail below.

[0117] The pattern language specification for procedure diagrams is a type P=<Tp,Σp>, again where Tp is a set of subtypes, and where Σp is a set of constructors using the type defined in Tp.

[0118] Tp={

[0119] TextType,

[0120] ProcedureDiagramType,

[0121] StmtListType,

[0122] StmtType,

[0123] BranchType,

[0124] BranchListType

[0125] }

[0126] Σp={

[0127] Procedure: TextType, TextType, StmtListType→ProcedureDiagramType

[0128] StmtList: StmtType, StmtListType→StmtListType

[0129] StmtList: StmtType→StmtListType

[0130] Task: TextType→StmtType

[0131] ProcCall: TextType, TextType→StmtType

[0132] Return: TextType→StmtType

[0133] Goto: TextType→StmtType

[0134] MacroCall: TextType, TextType→StmtType

[0135] Comment: TextType→StmtType

[0136] SimpleCond: TextType, StmtListType→StmtType

[0137] FullCond: TextType, StmtListType, StmtListType→StmtType

[0138] WhileLoop: TextType, StmtListType→StmtType

[0139] DoLoop: TextType, StmtListType→StmtType

[0140] Block: StmtListType→StmtType

[0141] Labelled: TextType, StmtType→StmtType

[0142] Switch: TextType, BranchListType→StmtType

[0143] BranchList: BranchType, BranchListType→BranchListType

[0144] BranchList: BranchType→BranchListType

[0145] Branch: TextType, StmtListType→BranchType

[0146] }

[0147] The specification of the pattern language for procedures can be interpreted in the same manner as that described previously for the pattern language for sections. Procedure diagrams consist of entities, belonging to six different types each of which will briefly be described.

[0148] The TextType type is the same as in Section Diagrams. TextType represents textual regions in diagrams.

[0149] The ProcedureDiagramType corresponds to top-level procedure diagram.

[0150] The StmtListType type corresponds to a vertical stack of procedure diagrams.

[0151] The StmtType type corresponds to any of the primitive procedure diagrams (see below).

[0152] The BranchType type is a special grouping, corresponding to a branch of a switch statement (see below).

[0153] The BranchListType type is a special grouping, corresponding to a set of branches in a switch statement (see below).

[0154] Now several of the constructors rules in Σp will be briefly described. The remaining constructors are similarly defined and will not be described in further detail here.

[0155] The Procedure constructor relates to the Procedure Diagram 110 of FIG. 3. The first parameter of this constructor corresponds to the Heading region 112 of the ProcedureDiagram pattern. The second parameter corresponds to the Comment region 114. The third parameter corresponds to the Body nested socket 116 of the Procedure Diagram pattern.

[0156] The Task constructor represents the Task pattern 310 of FIG. 6. This constructor has a single parameter which corresponds to the Statements region 314 of the Task pattern.

[0157] The ProcCall constructor represents the Procedure Call pattern 320 of FIG. 6. This constructor has a first parameter corresponding to the name of the procedure being called and a second parameter corresponding to the Parameters region 324.

[0158] The Return constructor represents the Return pattern 330 of FIG. 6. The single parameter corresponds to the Expression 334 region of the Return pattern.

[0159] The Goto constructor represents the Goto pattern 340 of FIG. 6. The single parameter corresponds to the Label region.

[0160] For the purpose of illustrating the Procedure pattern language specification, consider the following small Procedure in the C language. The corresponding section diagram for this example is illustrated in FIG. 12.

[0161] /* example procedure */

[0162] f(int x) {

[0163] int y;

[0164] int i;

[0165] y=x+1;

[0166] if(y>3) y=3;

[0167] else if (x+1==6) x++;

[0168] for(i=0; i<10; i++) {

[0169] printf(“%d\n”,x);

[0170] }

[0171] /* now switch */

[0172] switch (x) {

[0173] case 1: return 1;

[0174] case 2; x=x+1; break;

[0175] default: return 0;

[0176] }

[0177] return x;

[0178] }

[0179] The corresponding specification in pattern language is as follows (indentation shown for readability):

[0180] Procedure(“F(int x)”,“/* example procedure */”,

[0181] StmtList(DataDecl(“int y”),

[0182] StmtList(DataDecl(“int I;”),

[0183] StmtList(Task(“x=x+1;”),

[0184] StmtList(FullCond(“y>3”,

[0185] StmtList(Task(“y=3”)),

[0186] StmtList(SimpleCond(“x+1==6”,

[0187] StmtList(Task(“x++”))),

[0188] StmtList(WhileLoop(“for(i=0; i<10; i++)”,

[0189] Block(

[0190] StmtList(ProcCall(“printf”,“printf(\“%d\\n\”,x))),

[0191] StmtList(Comment(“/* now switch */”),

[0192] StmtList(Switch(“(x)”,

[0193] BranchList(Branch(“case 1:”,

[0194] StmtList(Return(“1”))),

[0195] BranchList(Branch(case 2:”,

[0196] StmtList(Task(“x=x+1;”),

[0197] StmtList(Labelled(“break”))),

[0198] BranchList(Branch(“default:”,

[0199] StmtList(Return(“0”))))))),

[0200] StmtList(Return(“x”))))))))))

[0201] This section contains a formal specification of mapping rules used to generate nested pattern expressions from the source code constructs. Each mapping rule defines a transformation of a certain syntactic construct into a pattern language expression, which may also contain nested application of mapping rules to parts of the syntactic construct. Each mapping rule has a name and consists of one or many clauses. Each clause contains a left-hand side and a right-hand side. Each mapping rule has a type. The domain of each rule is the syntax of the source language. The range of each rule is the pattern language.

[0202] The mapping rules are specific to the source language. This section contains an example of such mapping rules for the C language.

[0203] The left-hand side of each mapping clause describes the applicable syntactic pattern as well as the decomposition of that pattern into parts. The left-hand side also provides the naming for the elements of the syntactic pattern.

[0204] The right-hand side of the mapping clause describes the resulting pattern expression, which may contain nested applications of mapping rules to parts of the syntactic pattern. Mapping rules assume standard applicative order of execution. First, for the input syntactic expression, the applicable mapping rule is selected. When the rule is selected, the input expression is decomposed into syntactic parts. Then the nested rules are applied to these parts recursively until the complete nested pattern expressions are returned as the result of such applications. Then the final result of the application of the current mapping rule is constructed and returned. It is assumed that the set of rules is unambiguous. Any ambiguities are resolved by applying more specific syntactic patterns first. The set of rules is assumed to be completely covering the syntax of the source language.

[0205] The specification of mapping rules uses the following typesetting conventions:

[0206] Rule—is the name of a mapping rule

[0207] Syntax—is syntactic type or element of syntactic pattern

[0208] PatternType—is one of the types of the resulting pattern expression

[0209] [syntax]—defines the syntactic pattern (the left-hand side of the mapping clause or the argument of a nested application of some mapping rule in the right-hand side of a mapping clause).

[0210] Rule[]—is an application of mapping rule Rule to some syntactic pattern.

[0211] Constructor—is the name of the pattern constructor of the pattern language.

[0212] Rule[syntax]→Constructor(Rule[syntax]) defines a mapping clause for mapping rule Rule, which transforms source language construct Syntax into pattern language constructor Constructor with a nested application of the mapping rule Rule to the syntactic construct Syntax.

[0213] A set of mapping rules for the C language will now be presented by way of example:

[0214] Mapping rule G: Program→SectionDiagramType

[0215] G[prog-name decl-list]→Section(SN[prog-name], L[decl-list])

[0216] Mapping rule G describes how the top-level section diagram pattern is created. Nested application of the mapping rule L transforms the list of definitions within the source language unit into the list of primitive patterns of section diagram.

[0217] Mapping rule L: decl-list→DeclListType

[0218] L[decl decl-list]→DeclList(D[decl], L[decl-list])

[0219] L[decl]→DeclList(D[decl])

[0220] Mapping rule L describes how a list of declarations in the source language unit is transformed into a list of primitive patterns of section diagram.

[0221] Mapping rule D: decl→SectionPatternType

[0222] D[declaration;]→DataDecl(DT[declaration; ])

[0223] D[func-headfunc-body]→ProcDecl(FN[func-head], FT[func-head])

[0224] D[#define macro-name macro-body]→MacroDecl(MN[macro-name],

[0225] MT[macro-body])

[0226] Mapping rule D describes how individual declarations are transformed into different primitive patterns of the section diagram.

[0227] Mapping rule SN:prog-name→TextType

[0228] This rule describes the transformation of the source language unit name into the string of text (represented by type TextType).

[0229] Mapping rule DT:declaration→TextType

[0230] Rule DT describes the extraction of the body of the data declaration as the value of TextType type.

[0231] Mapping rule FN:func-head→TextType

[0232] Rule FN describes extraction of the name of the function from the function declaration.

[0233] Mapping rule FT:func-head→TextType

[0234] Rule FT describes extraction of the function heading (e.g. formal parameters and their types) from the declaration of the function.

[0235] Mapping rule MN:macro-name→TextType

[0236] Rule MN describes extraction of the name of the macro from a macrodefinition.

[0237] Mapping rule MT:macro-body→TextType

[0238] Mapping rule MT describes extraction of the macro definition body (e.g. macro formal parameters and the macrosubstitution string) from the macro definition.

[0239] Mapping rule P:program×name→ProcedureType

[0240] P[decl-list decl]×name→E[decl-list]×name

[0241] P[decl]×name E[decl]×name

[0242] Mapping rule E decl×name→ProcedureType

[0243] E[declaration;]×name→

[0244] E[func-def]×name→

[0245] where FN[func-def]≠name

[0246] E[func-def]×name→M[func-def]

[0247] where FN[func-def]=name

[0248] Mapping rule M:func-def→ProcedureType

[0249] M[func-def block]→Procedure(FH[func-def], B[block])

[0250] Mapping rule B:statement→StmtListType

[0251] B[statement]→StmtList(S[statement])

[0252] Mapping rule S:statement→StmtType

[0253] S[block]→C[block]

[0254] S[if (expr) statement1 else statement2]→FullCond(ET[expr],

[0255] B[statement1],

[0256] B[statement2])

[0257] S[return expr;]→Return(ET[expr])

[0258] The two examples of pattern expressions given previously in the discussion of the section diagram pattern specification language and the pattern diagram pattern specification language were created using the above discussed set of rules. A third example of applying the mapping rules to derive the pattern expression from a source code fragment will now be presented respecting the following source code fragment: myproc()

[0259] {

[0260] if(2>3){

[0261] return 0;

[0262] }

[0263] else

[0264] return 1;

[0265] }

[0266] The mapping rules will be applied in the following order.

[0267] P[“myproc(){if(2>3){return 0;} else return 1;}”], “myproc” results in

[0268] E[“myproc(){if(2>3){return 0;} else return 1;}”], “myproc”

[0269] E[“myproc(){if(2>3){return 0;} else return 1;}”], “myproc” results in

[0270] M[“myproc(){if(2>3){return 0;} else return 1;}”] since

[0271] FN[“myproc(){if(2>3){return 0;} else return 1;}”] results in “myproc” which is equal to the second parameter of the E-rule.

[0272] M[“myproc(){if(2>3){return 0;} else return 1;}”] results in

[0273] Procedure(FH[“myproc()”],

[0274] B[“{if(2>3){return 0;} else return 1;}”]

[0275] )

[0276] FH[“myproc()”] results in text string “myproc()”

[0277] B[“{if(2>3){return 0;} else return 1;}”] results in StmtList(S[“{if(2>3){return 0;} else return 1;

[0278] }”])

[0279] S[“{if(2>3){return 0;} else return 1;}”] results in C[“{if(2>3){return 0;} else return 1;}”]

[0280] C[“{if(2>3){return 0;} else return 1;}”] results in FullCond(ET[“2>3”], B[“{return 0;}”], B[“return

[0281] 1;”])

[0282] ET[“2>3”] results in text string “2>3”

[0283] B[“{return 0;}”] results in StmtList(S[“{return 0;}”])

[0284] S[“{return 0;}”] results in Return(ET[“0”])

[0285] ET[“0”] results in text string “0”

[0286] B[“return 1”] results in Return(ET[“1”])

[0287] ET[“1”] results in text string “1”

[0288] The resulting pattern expression is provided below (indentation is used to emphasise the structure of the expression).

[0289] Procedure (“myproc ()”,

[0290] StmtList(

[0291] FullCond(“(2>3)”,

[0292] StmtList(

[0293] Block(

[0294] StmtList(

[0295] Return(“0”)))),

[0296] StmtList(

[0297] Return(“1”)))))

[0298] In order to perform different computations required for the pattern-based visualization of source code, a suitable physical representation of the pattern language needs to be selected. A particularly suitable representation which may be used as part of this invention is described below.

[0299] Pattern language is preferably represented and stored as so-called N-ary trees. An N-ary tree is a tree-like data structure consisting of nodes connected via pointers. The conventional linked list is an example of a regular (unary) tree, where each link is connected to only one other node. The conventional binary tree is another example, where each node is connected to exactly two other nodes. N-ary trees consist of nodes of several types. Nodes of each node type may be connected to a different number of other nodes. All nodes belonging to one node type are always connected to the same number of other nodes. N-ary trees include “well-formedness” rules, limiting the node types to which a node of a particular node type can be connected. Another characteristic of an N-ary tree is that each connection is named. Each connection can have different “well-formedness” rules, limiting the allowed node types for this particular connection.

[0300] N-ary trees are very suitable for representing the pattern expressions. Each constructor of the pattern language is physically represented by a node type of the N-ary tree. Parameters of constructors are physically represented by connections(pointer fields) to other nodes. Additionally, each node of the n-ary tree has a common field containing a tag which uniquely identifies the node type of this node (and thus—the corresponding constructor of the pattern language).

[0301] N-ary trees will be described in further detail by way of example for the pattern language expression immediately above. An N-ary tree is illustrated in a pictorial manner in FIG. 15 for the above expression. The top level node 500 is a Procedure node having three parameters and hence three pointers 502,503,504. Recall that the Procedure constructor has three parameters these being the Heading of type TextType, the Comment of type TextType, and the Body of type StmtList. Pointer 502 points to the first parameter which is the text field “myproc()” 505, pointer 503 points to the second parameter which is an empty text field 507, and pointer 504 points to the third parameter which is a StmtList node 506. The StmtList node 506 has a single pointer 508 to a single parameter which in this case is the FullCond node 510. The FullCond node 510 has three parameters and hence three pointers, the first 512 pointing to a text field “2>3” 513 representing the conditional test, the second 514 pointing to a first StmtList node 516, and a third 518 pointing to a second StmtList node 520. The first StmtList node 516 has a pointer 522 to a node which is a Block node 524. The Block node 524 has a pointer 526 to a StmtList node 528 which in turn has a pointer 530 to a Return node 532. The Return node 532 points with pointer 533 to a single parameter which is text field “0” 534. The second StmtList node 520 has a pointer 535 to a Return node 536 which in turn has a pointer 538 pointing to a single parameter which is a text field “1” 540.

[0302] In the above, there are five node types, namely Procedure, StmtList, FullCond, Block and Return. Each node type is further defined by a node type tag, by how many parameters it expects. Assume that the following node types are defined:

[0303] In the above table, only node types relating to constructors which appear in the above pattern language expression are included. Of course, it is to be understood that a node type would need to be defined for each different type of constructor.

[0304] The above discussed N-ary tree is a data structure which lends itself to the exemplified pictorial presentation. The N-ary data structure in tabular form will be further defined with reference to FIG. 16.

[0305] In the N-ary data structure of FIG. 16 the node field 600 contains a node identifier such as an address which can be used to access the particular node. The Node type field 602 is for identifying a particular node as relating to a constructor of one of the types identified above. The Pointer 1 604, Pointer 2 606, Pointer 3 610 fields are for storing pointers to parameters for a particular node. The nesting depth field 612 indicates the level of nesting that the particular node appears at within the pattern language with 0 being the top level, i.e. the first node, and each time a parameter of a node is introduced, that increases the nesting depth by one. The nesting depth field is not essential as the most nested expressions can be determined by other means.

[0306] The remaining four fields 614,616,618,620 relate to layout attributes and these will be described in further detail below.

[0307] The generation of the above data structure starts with the first constructor appearing in the pattern language expression which in this case is a Procedure constructor, which becomes a node of type 1 and has a nesting depth of 0. A first pointer is stored which points to the location of a text string, the first parameter in the constructor. This is indicated by the notation P>A1, where A1 is the address being pointed to. The text string “myproc()” is stored at address A1, and its nesting depth of 2 is stored. A second pointer is stored pointing to address A5 which stores the empty string “”. A third pointer is stored which points to the location of the third parameter which in this case is a StmtList constructor which is stored at address 2 along with its nesting depth of 2.

[0308] Next, the fields for the StmtList constructor at node 2 and subsequent nodes are filled in a similar manner resulting in the completed data structure above.

[0309] Pattern language expressions introduced previously were designed to enable the mapping of source code to source code independent language which is directly mappable onto a graphical diagram layout. Additional information is required to describe the graphical layout of patterns. Information about the layout of graphical diagrams is preferably separated from the information about their structure. Specifically, this is achieved by providing additional attributes for constructors of the pattern language these additional attributes being referred to as layout attributes. The separation of structural issues and layout issues is achieved by introducing an intermediate mapping which changes constructors of the pattern language without layout attributes into equivalent constructors with layout attributes. Layout attributes are left undefined during the mapping from source code to pattern language i.e. during the initial development of the N-ary tree. Then the intermediate mapping fills in the layout attributes. The advantage of such separation is that the intermediate mapping is to a large extent independent from the source language because it only has to compute layout attributes in a pattern expression. On the other hand, all issues of parsing the source code expressions and generating the resulting pattern expression are independent of the details of the layout of resulting diagrams and deal only with the source language.

[0310] The layout attributes of graphical patterns will be described by way of example with reference to FIGS. 8, 9, and which relate to a FullConditional construct (IF, THEN, ELSE)170 of FIG. 5. Referring firstly to FIG. 8, each graphical pattern occupies a rectangular box, which is characterized by height, width and position. There are four essential graphical characteristics of each graphical pattern which are:

[0311] Pattern Reference Point 400—horizontal and vertical coordinates of the specifically selected point at the outer border of the pattern which is used in embedding patterns into nested sockets. This attribute characterizes the position of the pattern.

[0312] LeftWidth 402—distance from the reference point to the left side of the pattern box.

[0313] RightWidth 404—distance from the reference point to the right side of the pattern box. Note that LeftWidth+RightWidth specify the total width of the pattern box

[0314] Height 406—height of the pattern box.

[0315] Specifying the left width, the right width, and the reference point actually turns out to include redundant information. More efficiently, the total width, and the reference point can be used to determine the left width and right width.

[0316] These attributes become part of the pattern expressions which are stored in the N-ary data structure of FIG. 16. More particularly, they are stored in the following form, for a given construct “Construct”:

[0317] Construct.Center.w (element 614 of FIG. 16)—specifying the reference point horizontal component;

[0318] Construct.Center.h (element 616 of FIG. 16)—specifying the reference point vertical component, the default being zero;

[0319] Construct.Size.w (element 618 of FIG. 16)—specifying the width; and

[0320] Construct.Size.h (element 620 of FIG. 16)—specifying the height.

[0321] Physically, these attributes are stored during the computation of layout attributes by the layout algorithm (see next section).

[0322] In addition to these layout attribute for each node/pattern, the final layout of a given pattern is characterized by a number of other dimensions. Below is a list of dimensions which may be used to completely describe the visual appearance of the FullConditional pattern. The dimensions are also defined in FIGS. 8, 9 and 10.

[0323] dwDecision 410 is the width of the rhomb 172;

[0324] dhDecision 412 is the height of the rhomb 174;

[0325] dwTextBox 414 is the width of the text box 174;

[0326] dhTextBox 416 is the height of the text box 174;

[0327] dhStatement1 418 is the minimum vertical distance of any nested socket from a horizontal branch line;

[0328] dwStatement1 420 is the minimum horizontal distance of any nested socket statement from the centre line 173 of the construct;

[0329] dwLineToText 424 is the length of the line connecting the text box 174;

[0330] dwBranch is a default branch width (not shown);

[0331] dhBranch is a default branch height (not shown);

[0332] dhLab 430 is the minimum vertical distance of any label from any line;

[0333] dwLab 432 is the minimum horizontal distance of any label from a vertical branch line;

[0334] dwLab2 434 is the minimum horizontal distance of any label from the centre line 173 of the pattern;

[0335] dhEndLab 436 is the minimum vertical distance between the end label and the bottom horizontal branch line;

[0336] dhEndLab 438 is the minimum horizontal distance between the end label and the centre line 173 of the pattern;

[0337] Additional attributes are required for the computation of the main four attributes as well as for the subsequent generation of display primitives (both processes are described below). There are two possible strategies in physical representation of additional attributes.

[0338] In the first strategy, the additional attributes are stored in the n-ary tree. The trade-off is that these attributes are computed only once and are used twice. The disadvantage is that they occupy quite a lot of extra space in the physical representation of the n-ary tree.

[0339] In the second strategy, the additional attributes are computed each time they are needed. The advantage of this strategy is that no additional space is required, but the attributes are computed twice. This strategy is assumed throughout the rest of the this description.

[0340] This section describes how a pattern-based layout algorithm for source diagrams is defined. The pattern-based layout algorithm treats each pattern as an entity without breaking it into individual elements like figures, text and lines.

[0341] First, the layout attributes of each pattern are identified and formulae for evaluating these attributes are developed. This is done manually for each pattern. This is performed only once when patterns are defined. Firstly, the layout attributes are defined for each pattern. Layout attributes represent the size of each element of a pattern. Secondly, the layout of each pattern is captured as a set of formulae. Each formula describes how to compute each individual layout attribute for a particular pattern expression, which includes the pattern being described. The computation of layout attributes for composite patterns can only be completed given the complete nested pattern expression because the final sizes of the elements of the given instance of composite pattern depend on the sizes of the nested patterns.

[0342] An example set of layout attribute evaluation formulae for the FullConditional pattern will now be presented. The layout attributes for this pattern have been presented previously. The ultimate output of the formulae are the four layout attributes which are to be stored with the N-ary tree for the node relating to the particular construct. Inputs to the formulae are the basic layout attributes computed for the nested patterns and for the labels. Recall that for any stored construct, Construct, the following attributes are stored: Size.w, Size.h, Centre.w, and Centre.h. To associate these attributes with a given construct, the notation Construct.attribute will be used. Thus the inputs to the layout formulae for the FullConditional construct are all of the basic layout attributes of the subconstructs. These inputs are as follows:

[0343] For the left nested pattern 182:

[0344] Statement1.Size.w

[0345] Statement1.Size.h

[0346] Statement1.Centre.w

[0347] Statement1.Centre.h

[0348] For the right nested pattern 184:

[0349] Statement2.Size.w

[0350] Statement2.Size.h

[0351] Statement2.Centre.w

[0352] Statement2.Centre.h

[0353] For the text in the text box 174

[0354] expr.Size.w

[0355] expr.Size.h

[0356] expr.Centre.w

[0357] expr.Centre.h

[0358] For the left branch label

[0359] Label1.Size.w

[0360] Label1.Size.h

[0361] label1.Centre.w

[0362] Label1.Centre.h

[0363] For the right branch label:

[0364] Label2.Size.w

[0365] Label2.Size.h

[0366] Label2.Centre.w

[0367] Label2.Centre.h

[0368] For the end branch label:

[0369] EndLab.Size.w

[0370] EndLab.Size.h

[0371] Endlab.Centre.w

[0372] Endlab.Centre.h

[0373] Now, using the above inputs, and the previously defined dimensions, the following are the layout formulae for the FullConditional construct:

[0374] FullConditional

[0375] LOCAL int Left, Right

[0376] Left=max(dwDecision/2,

[0377] dwLab2+Lab1.Size.w+dwLab,

[0378] dwBranch,

[0379] dwStatement1+Statement1.Size.w

[0380] dwEndLab+EndLab.size.w

[0381] Right=max(

[0382] dwDecision/2+dwLineToText+max(dwTextBox,Expr.Size.w),

[0383] dwLab2+Lab2.Size.w+dwLab,

[0384] dwBranch,

[0385] dwStatement1+Statement2.Size.w)

[0386] Center.w=Left

[0387] Center.h=0

[0388] Size.w=Left+Right

[0389] Size.h=max(dhDecision,

[0390] dhTextBox,

[0391] Condition.Size.h)

[0392] +dhBranch

[0393] +dhStatement1+max(Statement1.Size.h,

[0394] Statement2.size.h)+dhStatement2

[0395] +dhEndLab+EndLab.Size.h

[0396] }

[0397] The outputs of the above formulae are Size.w, Size.h, Center.w and Centre.h which are then stored in the N-ary tree in the node relating to the FullConditional construct.

[0398] A similar set of formulae can be defined for each type of construct. The set of formulae for a given construct will depend upon the dimensions of other constructs that it contains, and upon fixed dimensions selected during initial pattern design.

[0399] Next a mapping from the computed layout attributes to display directives is defined. The end goal of the visualization process is to get the graphical display of the diagram. To achieve that, a graphical engine is required. The graphical engine should be capable of drawing graphical figures at some sort of graphical device (monitor, printer, plotter, etc.). We assume that the graphical engine is capable of drawing a small set of lines and figures collectively referred to as display primitives.

[0400] Display primitives have been summarized in previously with respect to FIG. 7. Below is an algebraic specification of display primitives which uses the same notation introduced earlier for the section and procedure patterns. The display primitives are a type:

[0401] D=<Td,Sd>

[0402] where Td is a set of types, and Sd a set of constructers using the types defined in Td.

[0403] Types Td={ColorType,CoordType,DashType,DimensionType,TextType, DisplayType}

[0404] The types in Td have the following meaning:

[0405] ColorType represents a Color attribute of a display primitive;

[0406] CoordType represents horizontal and vertical positions of display primitives;

[0407] DashType represents the type of line used in a display primitive (dash or straight);

[0408] DimensionType represents width and height attributes of display primitives;

[0409] TextType attribute represents string attribute of display primitives;

[0410] The following is the set of relevant constructors for display primitives:

[0411] Constructors Sd={

[0412] Vertical: CoordType, CoordType, CoordType, ColorType→DisplayType;

[0413] Horizontal: CoordType, CoordType, CoordType, ColorType, DashType—>DisplayType;

[0414] Text: CoordType, CoordType, TextType—>DisplayType;

[0415] Rectangle: CoordType, CoordType, DimensionType, DimensionType, ColorType—>DisplayType;

[0416] Open: CoordType, CoordType, DimensionType, DimensionType, DashType—>DisplayType;

[0417] Double: CoordType, CoordType, DimensionType, DimensionType —>DisplayType;

[0418] DoubleDouble: CoordType, CoordType, DimensionType, DimensionType—>DisplayType;

[0419] Folded: CoordType, CoordType, DimensionType, DimensionType —>DisplayType;

[0420] Rhomb: CoordType, CoordType, DimensionType, DimensionType —>DisplayType;

[0421] Circle: CoordType, CoordType—>DisplayType;

[0422] Return: CoordType, CoordType—>DisplayType;

[0423] Start: CoordType, CoordType, DimensionType, DimensionType —>DisplayType;

[0424] Ground: CoordType, CoordType—>DisplayType;

[0425] The above has described how Layout attribute evaluation formulae as derived and how a Layout Attribute Display Directives Mapping is defined. Referring to FIG. 2C, a flowchart describing how layout attributes are calculated for all patterns in a nested pattern expression. These calculations are done automatically once for each nested pattern expression. Recall that a “nesting depth” parameter was stored with each node of an N-ary tree pattern expression. These innermost patterns of the nested pattern expression are always primitive patterns, so they do not contain any nested patterns and their layout attributes can be finalized without any input to the correspondent attribute evaluation formulae. As computations proceed, some information is propagated from the inner patterns to outer patterns.

[0426] Next, the layout attributes for the next highest level of nesting are computed using the computed layout attributes of the higher nested patterns as inputs. Thus the size of the nested patterns is used as the input for layout formulae of lower nested patterns, and the output of the layout formulae is the size of the current pattern.

[0427] After the bottom-up computation of layout attributes for the pattern expression is completed, the actual graphical diagram of that nested pattern expression can be created.

[0428] The input to the computations of actual display directives are the nested pattern expression with layout attributes computed as discussed previously. The computation of display directives is done automatically by computing positions and sizes as well as some other attributes for each individual element of each pattern.

[0429] The generation of display directives is performed in top-down fashion starting from the outermost pattern of the nested pattern expression. The goal of the third phase is to identify the display directives for each pattern as well as to compute positions, sizes and some other attributes of each display directive. Display directives correspond to the individual elements of patterns. Additional attributes of the display directives include the style of line (straight or dashed) and the colour of the element. Additional attributes may vary for different instances of the same pattern.

[0430] Display directives are generated from the pattern expression enriched with layout information. The pattern expression contains enough information about what display directives need to be generated (since the set of display directives to be generated depends only on the graphical pattern and the selected set of available display primitives). Parameters to the display primitives are derived both from layout attributes and text attributes of the pattern expression.

[0431] Formally, the process of generating display directives from a pattern expression can be specified by a set of mapping rules, similar to the ones, describing generation of pattern expression from source language constructs. However the process of generating display directives is even more simple, since it does not involve any parsing of the input. The reason for that is the straightforward pattern language and storage format for the physical representation of diagrams (described above), which allow instant recognition of the nodes of the N-ary tree and thus the corresponding pattern language constructors.

[0432] Display directives are in many ways similar to patterns. One can think of them as “simple micro patterns”, or “primitive patterns”. Similarities include the following:

[0433] display directives have graphical representation (same as patterns);

[0434] display directives are formalized as “display directives language” (see above section “Layout Attributes to Display Directives Mapping”). Same algebraic specification style is used.

[0435] Transformation from pattern nested expression (enriched with layout attributes) into a “display expression” (i.e. a sequence of display directives) is described by similar “mapping rules”, same as the transformation from source code into nested pattern expression.

[0436] Some differences between display directives and patterns are as follows:

[0437] display directives are never nested;

[0438] display directives include such information as placement, coordinates, colors, etc.

[0439] According to our principle of “separation of concerns”, “display expressions” are much more detailed compared to nested pattern expressions with layout attributes.

[0440] Mapping rules from patterns expression with layout into display directives formalize the visual appearance of “graphical patterns”, by describing how such pattern can be constructed from similar building blocks (e.g. on screen or as postscript).

[0441] In fact these building blocks (or primitives) can be chosen more or less arbitrarily (provided that they can describe the visual appearance of graphical patterns). The most detailed language of display primitives will consist of a single primitive “dot” (but the mapping will be rather complex). A better display language will include lines and arcs.

[0442] The language described herein language includes complete figures. This is a trade-off between complexity of a mapping description and “intelligence” of the graphical engine. This also involves performance considerations (like network traffic, when diagram descriptions need to be transferred over network it is beneficial to reduce traffic by making a more “intelligent” graphical engine and transferring more compact descriptions).

[0443] A display expression is a SEQUENCE of display directives (separated by “;”). Mapping rules are defined from nested pattern expressions with layout attributes into display expressions. The preferred notation is the same as that for the above described mapping rules from source code into nested patterns expressions. Each rule has a left hand side and a right hand side. The Left hand side is a pattern language expression (with layout attributes). The Right hand side is a display expression (possibly with nested applications of further mapping rules). Again applicative order of evaluation is assumed. Note, that square brackets are used to represent application of a mapping rule to some expression.

[0444] Layout attributes are not part of the left hand side of the mapping rule. Instead, they will be used directly in right hand side where needed using the following notation:

[0445] xxx.yyy where xxx is the name from the right hand side (matching some construct in pattern expression), and yyy is the name of some layout attribute. This notation is consistent with notation used in attributed grammars. Notation yyy will be used to represent layout attributes of the expression, to which the rule was applied directly (rather than one of its subexpressions).

[0446] An example of display directives generated from a pattern expression will be given using the following simple fragment in C:

[0447] If(2>3) return 0;

[0448] The corresponding pattern expression is provided below.

[0449] SimpleCond(“(2>3)”, Return(“0”))

[0450] Below is an example of a mapping rule from nested pattern expression with layout attributes into a display expression, corresponding to the above example. This example, Rule S, relates to the translation into a display expression of a SimpleCond pattern language expression

[0451] Rule S

[0452] S [SimpleCond (Condition, Stmts)]—>

[0453] Rhomb (Centre.w, Centre.h, 10,10);

[0454] Text (“if”);

[0455] Horizontal (Centre.w+10, Centre.h+5,

[0456] Centre.w+15, BLACK);

[0457] Open (Centre.w+15, Centre.h+5,

[0458] Condition.Size.h, Condition.Size.w, SOLID);

[0459] Text (Condition);

[0460] Vertical (Centre.w+5, Centre.h+10, Centre.h+15, BLACK);

[0461] Horizontal (Centre.w+5, Centre.h+12,

[0462] Centre.h+12+Stmts.Left+Stmts.Right+3, BLACK);

[0463] Text (Centre.w+8, Centre.h+13, “then”);

[0464] S[Stmts];

[0465] Horizontal (Centre.w+5,

[0466] Centre.h+12+Stmts.Left+Stmts.Right+3, Centre.h+12, BLACK);

[0467] Vertical (Centre.w+5, Centre.h+10,

[0468] Centre.h+10+Stmts.Size.h);

[0469] Text (Centre.w+8, Centre.h+10+Stmts.Size.h, “endif”);

[0470] Vertical (Centre.w+5, Centre.h+10+Stmts.Size.h,

[0471] Centre.h+10+Stmts.Size.h+2, BLACK);

[0472] S[Return (RetExpr)]—>Return (Centre.w, Centre.h);

[0473] Text (Centre.w+5, Centre.h+5, RetExpr);

[0474] Vertical (Centre.w+5, Centre.h+10, Centre.h+12, BLACK).

[0475] The above is a very specific example, and of course, there are many ways of generating display directives from the nested pattern expressions.

[0476] Broadly speaking, the invention, in one embodiment provides a stored definition of a set of patterns which can be used for a broad class of imperative programming languages each pattern including a specification of layout attributes, and a number of software modules. Each module might be a function or application program for example, or alternatively the modules collectively might function as a particular application program. There needs to be a module for executing a plurality of mapping rules for generating patterns from source code, a module for executing a plurality of algorithms for computing layout attributes for each pattern, a module for executing algorithms for generating display directives from the patterns and their layout attributes, and a graphical display engine for displaying graphical diagrams by executing the display directives.

[0477] Numerous modifications and variations of the present invention are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the invention may be practised otherwise than as specifically described herein.

[0478] For example, above a specific example has been provided using the C source language. It is of course to be understood that the translation from a source language to pattern language will be different for each different source language.

[0479] Specific patterns have been defined above for specific pattern language constructs. It is of course to be understood that a different pattern language could be defined which has the same purpose, namely that it is a common intermediary language which can uniformly be mapped onto patterns. Similarly, depending upon the desired physical appearance of the flowcharts, in a other implementations a different set of patterns could be defined.

[0480] Furthermore, a particular example of how display directives are computed and implemented has been presented. It is to be understood that within the scope of the invention other implementations of these steps may be used. Furthermore, since graphical display engines are available off the shelf, the step of translating the pattern language and attributes into display directives may be done differently for different display engines. For this reason, the pattern language expressions and their attributes alone constitute an inventive product according to an embodiment of the invention in their own right, as are the methods of generating these.