|Publication number||US7877737 B2|
|Application number||US 11/157,074|
|Publication date||Jan 25, 2011|
|Filing date||Jun 20, 2005|
|Priority date||Jul 23, 2004|
|Also published as||US20060037019|
|Publication number||11157074, 157074, US 7877737 B2, US 7877737B2, US-B2-7877737, US7877737 B2, US7877737B2|
|Inventors||Mark A. Austin, Natalya Shmunis, Virnal Mayank, David Frank Everett|
|Original Assignee||University Of Maryland, The United States Of America As Represented By The United States National Aeronautics And Space Administration|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (9), Non-Patent Citations (3), Referenced by (15), Classifications (4), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application claims priority under 35 U.S.C. §119(e) to a U.S. Provisional Application filed on Jul. 23, 2004 and assigned U.S. Provisional Application No. 60/590,771; the entire contents of the provisional application are incorporated herein by reference.
The invention described herein was made in the performance of work under NASA contracts NAG513642 and NAG512464 and by employees of the United States Government and is subject to the provisions of Section 305 of the National Aeronautics and Space Act of 1958, as amended, Public Law 85-568 (72 Stat. 435, 42 USC 2457), and may be manufactured and used by or for the Government for governmental purposes without the payment of any royalties thereon or therefor.
1. Field of the Disclosure
This disclosure relates to a tree-to-graph folding procedure for systems engineering requirements. In particular, this disclosure relates to a system and method for generating a data representation graph for systems engineering requirements having no duplicate nodes.
2. Description of the Related Art
Management in systems engineering includes identifying and managing systems engineering requirements at an early phase of the design process of a system, validating the systems requirements against the purposes and functions of the system, and verifying the systems engineering requirements against appropriate specifications. A systems engineering requirement is a criterion that a system must meet. Systems engineering requirements can include things the system must do, characteristics it must have, and levels of performance it must attain. Systems engineers develop systems engineering requirements before a system is created. As it is developed, the system is evaluated according to how well it meets its system engineering requirements.
Prior art software systems engineering requirements management tools provide support for managing system development, even for systems having tens-of-thousands of systems engineering requirements, such as for providing support for top-down development, which may include providing a database representation of the systems engineering requirements and connections between the systems engineering requirements, also known as a requirements document. Examples of prior art software management tools for system engineering which are currently commercially available include SLATE™, DOORS™ and CORE™.
In prior art software requirements management tools, systems engineering requirements may be organized and visualized as a tree, which is defined as an acyclic connected directed hierarchical graph having a plurality of nodes including one or more parent nodes and one or more child nodes. A parent node represents a defining systems engineering requirement, and a child node represents a complying systems engineering requirement. The actual systems engineering requirements may have a number of complicating relationships, such as multiple inheritance relationships, where a systems engineering requirement document or other data representation needs to support such relationships. Furthermore, systems engineering requirements data representations need to support hierarchical representations for representing different organizational levels. The organizational levels may enhance team development, where a particular level may be associated with a particular team.
The term “tree” refers to an acyclic connected directed hierarchical graph. Visualization of requirements in a tree format may use duplication of nodes for representing complicated relationships, preserving of organizational levels and/or eased of implementation in a computer environment. In engineering projects having large numbers of systems engineering requirements, the presence of duplicate nodes complicates the task of interpreting and understanding the relationships between the systems engineering requirements. As the number of systems engineering requirements increases, the ability to comprehensively manually identify duplicate nodes and all complying and defining relationships associated with each node becomes undependable and unfeasible. Reliance on a tree having duplicate nodes may lead to decision making based on an incomplete picture of a systems engineering requirement's role in the system design.
Furthermore, prior art requirements management tools represent individual systems engineering requirements by using textual descriptions without underlying semantics. Accordingly, search mechanisms are limited to the use of keywords. As a result, computational support for the validation and verification of requirements and searching capabilities are limited.
In accordance with the present disclosure, a method is provided for generating a graph data representation having a plurality of nodes corresponding to respective systems engineering requirements. The method includes accessing a first data representation of a collection of systems requirements and relationships therebetween and generating a second data representation of the collection of systems requirements. The generating the second data representation includes accessing respective systems requirements of the collection of systems engineering requirements; creating a node to correspond to each accessed systems requirement if a node corresponding to the accessed systems requirement does not exist; and creating an edge between the created or pre-existing node and each node corresponding to a systems requirement having a relationship with the accessed systems requirement. Each node of the second data representation is a node of said graph data representation and corresponds to a different systems requirement of the collection of systems requirements.
In another embodiment of the disclosure a system is provided for generating a graph data representation having a plurality of nodes corresponding to respective engineering systems requirements. The system includes a processor assembly having at least one processor having access to a first data representation of a collection of systems engineering requirements and relationships therebetween, and a memory storing a series of executable instructions executable by the at least one processor for generating a second data representation. The execution of the series of executable instructions for generating the second data representations includes accessing respective systems requirements of the collection of systems requirements; creating a node to correspond to each accessed systems requirement if a node corresponding to the accessed systems requirement does not exist; and creating an edge between the created or pre-existing node and each node corresponding to a systems requirement having a relationship with the accessed systems requirement. Each node of the second data representation corresponds to a different systems requirement of the collection of systems requirements and is a node of said graph data representation.
In another embodiment of the disclosure a system is provided for generating a hierarchical graphic visualization of a graph data representation having a plurality of nodes corresponding to respective systems engineering requirements. The system includes a processor assembly having at least one processor for accessing a graph data representation having a plurality of first edges and a plurality of first nodes corresponding to the respective systems requirements, wherein each first node corresponds to a different systems requirement of the respective systems requirements and has an associated at least one attribute. Each first node is connected to at least one other first node by at least one first edge, wherein the at least one first edge defines relationships between the nodes of the plurality of first nodes. The system further includes a memory storing a series of executable instructions executable by the processor assembly for generating a hierarchical graphic visualization of the graph data representation having a plurality of second edges and a plurality of second nodes arranged graphically in at least two levels. Each second node corresponds to a respective first node and is connected to at least one other second node by at least one second edge. The at least one second edge preserves the relationships defined by the at least one first edge. Each node is arranged in a level of the at least two levels in accordance with an attribute of the at least one attribute associated with the node.
Various embodiments of the disclosure will be described herein below with reference to the figures wherein:
Reference should be made to the drawings where like reference numerals refer to similar elements throughout the various figures.
The present disclosure provides a system 200 for processing systems engineering requirements, including generating a graph data representation of the systems requirements and displaying a graphic visualization of the generated data representation. System 200 includes a processor assembly 202, a graph generator software module 204, a visualization software module 206, and a graphical user interface (GUI) module 208, where the software modules 204, 206 and 208 are executable on the processor assembly 202. The system 200 further includes an output device 210 for outputting a graphic visualization generated by the visualization module 206.
The processor assembly 202 includes at least one processor, such as a microprocessor, a PC, a handheld computing device, a mobile phone, a mainframe computer, a network of computers, etc. Processors of the at least one processor may be included in one or more networks, such as LAN, WAN, Extranet, the Internet, etc. The processors may communicate via wired and/or wireless communication. The processor assembly 202 has access to at least one storage device, such as RAM, ROM, flash RAM, a hard drive, a computer readable medium, such as a CD-ROM, etc.
The software modules 204, 206 and 208 each include a series of programmable instructions executable by the processor assembly 202. The series of programmable instructions may be stored on a storage device which is accessible by the processor assembly 202, or transmitted via propagated signals for execution by the processor assembly 202 for performing the functions described herein and to achieve a technical effect in accordance with the disclosure. The output device 210 outputs graphically information that was received from the processor assembly 202, where the output device 210 is a device such as a computer monitor, a display screen for a handheld computing device, a printing device, a plotting device, etc., and the output is a graphical layout of the information on a display screen, a printout, etc.
The graph generator module 204 receives a first data representation A of a collection of related systems engineering requirements, where at least one node corresponds to each systems requirement, and an edge corresponds to each relationship between the systems requirements. Exemplary relationships include defining and complying relationships, wherein for a parent node and a child node, the child node to parent node relationship is a complying relationship, and the parent node to child node is a defining relationship. Comply and define relationships are a form of directed link, with other terminology such as outgoing and incoming sometimes used.
The first data representation input to the graph generator module 204 may be created input using a word processing or spreadsheet program, a database program, an XML editor, a custom-XML requirements editor, an AP233 editor, a requirements management tool, etc. The input data may be received as it is entered in real time via user input or as a complete file transferred from storage, another software module or another processor. AP233 is a standard for exchanging systems engineering data between different types of platforms. By providing the capability to handle AP233, the system 200 may process information provided by any program or device which complies with AP233.
The graph generator module 204 transforms the first data representation A into a second data representation B in which all duplication of nodes existing in the first data representation A is eliminated. For each eliminated duplicate node of the first data representation A, each edge connected to the node being eliminated is incorporated into the second data representation B as appropriate. The resultant second data representation B is a directed graph including a collection of nodes and edges, in which there are no duplicate nodes. The second data representation B is a graph which may include one or more multiple inheritances, in which a child node of the directed graph may depend from (e.g., comply with) more than one parent node.
In the first and second data representations A, B, each systems engineering requirement represents a requirement or task for a particular project, such as a functional requirement, performance requirement or an interface requirement. The individual systems requirements are represented as data elements which are nodes. The systems requirements may be layered, e.g., where each node is associated with a particular level. Each systems requirement has a corresponding unique identification number, e.g., a requirement object identification number (ROIN); and may further have one or more tags or fields, such as for identifying and/or describing the systems requirement, including at least one associated attribute field, e.g., each attribute having a name and an associated value, such as for defining a level, e.g., a hierarchical level, assigned to the systems requirement; and connectivity data, such as a list of systems requirements which comply directly with the systems requirement, e.g., child nodes which depend directly from the systems requirement.
Table 1 below shows an exemplary systems requirement node written in extensible Metadata Language (XML), as provided by the systematic query and extraction of the requirement from a SLATE™ database. The systematic query and extraction procedure is implemented using a custom script file. Table 1 shows an exemplary system requirement having ROIN 8-378.
<Req ROIN=“8-378” type=“Mission Objective” level=“0”>
<Title text=“Programmatic Requirements”/>
<Description text=“The GPM shall adhere to program
as agreed between the NASA Earth Science
and the NASA/GSFC GPM program office.”/>
<Attribute text=“Assigned To” value=“None”/>
<Attribute text=“Change Proposals Allowed” value=
<Attribute text=“Criticality” value=“None”/>
<Attribute text=“ID” value=“”/>
<Attribute text=“Inheritable” value=“Yes”/>
<Attribute text=“Qualification Date/Time”
<Attribute text=“Rationale” value=“”/>
<Attribute text=“ Requirement State” value=
<Attribute text=“Requirement Status” value=“Active”/>
<Attribute text=“ Requirement Title” value=“Programmatic
<Attribute text=“Test Report Number” value=“”/>
<Attribute text=“Verification Date/Time”
<Attribute text=“Verification Description” value=“”/>
<Attribute text=“Verification Level” value=“None”/>
Attribute text=“Verification Method” value=“None”/>
<Attribute text=“Verification Status” value=“None”/>
<Attribute text=“Verified By” value=“None”/>
The connectivity data shows that ROIN's 8-2,8-4, 8-5,8-7, 8-8,8-10, 4-468, 8-251, 8-259, 8-57, 8-43 and 8-26 are listed as complying with ROIN 8-378. A collection of systems requirements nodes, including connectivity properties and associated attributes, together form an XML file also known as a specifications document. The specifications document may be stored as a database of systems specifications and connectivity data (e.g., links) showing the relationships between the systems requirements. Requirements management tools may generate a list, e.g., database, of requirements in an XML specifications document, which may be configured as a hierarchical tree.
When another ROIN of the specifications document lists a specifications requirement which is already listed as a child node of ROIN 8-378 in its connectivity data, e.g., ROIN 8-2, a multiple inheritance is created. In a graphic visualization of the specifications document, the multiple inheritance may be resolved by creating multiple nodes for the child node which has two or more parents. However, a user that views one child node of the multiple child nodes does not view all of the compliance relationships which apply to the viewed child node, and may not be aware that multiple nodes exist which correspond to the same systems requirement as the viewed child node corresponds to. Accordingly, the user may be missing vital information when making decisions.
With reference to
The processor assembly 202 receives as input a first data representation, which is the specifications document, the tree 306, or another type of data representation (e.g., a list). The graph generator module 204 processes the input to generate a second data representation shown in diagram 312, which is a graph not having any duplicate nodes, which is herein referred to as a non-duplicate graph 314 that allows multiple inheritances. The visualization module 206 processes the second data representation, e.g., the non-duplicate graph 314, and generates a visual representation of the non-duplicate graph 314 showing hierarchies.
The tree 306 includes duplicate nodes for systems requirements C and E. For a large scale project, a user of a tree having duplicate nodes may view only a segment of the tree, not be aware of the existence of duplicate nodes, not be able to locate all duplicates of a node, and/or not be able to determine all of the define and comply relationships corresponding to a systems requirement 302 represented as more than one node, e.g., nodes C and E.
The graph generator module 204 generates the non-duplicate graph 314 by folding or collapsing the first data representation, e.g., the tree 306, into the non-duplicate graph 314 by creating one node for each systems requirement 302, including removing all duplicate nodes, and creating an edge for each of the define and comply relationships provided in the first data representation for generating the non-duplicate graph 314. In the non-duplicate graph 314, there are no duplicate nodes, and there is only one occurrence of each systems requirement 302. For each systems requirement 302 a user can see all of the define and comply relationships corresponding to the systems requirement 302 by looking at the one node that corresponds with the systems requirement 302 and all of the edges that connect directly to that node.
Other types of first data representations, such as a list, graph, hash table data structure, or a combination thereof, may be created, such as from the requirements document, for representing the systems requirements. Requirements documents may employ, for example, a format compliant with the AP233 standard, a format compliant with systems modeling language (SysML) specification, such as XML Metadata Interchange (XMI) representation, a database representation of the requirements document, or a text file format outlining the nodes and connections between them. Accordingly, the input to the graph generator module 204 may be a tree, another type of first data representation, or the requirements document.
At step 404, a determination is made if all of the nodes of the first data representation A have been accessed. If “yes”, then END step 406 is executed. If “no”, then step 408 is executed. At step 408, a determination is made if the node accessed is a duplicate of another node already accessed, e.g., is already included in the second data representation B. For a first data representation A in which each systems requirement stored in the first data representation A has as a unique identifier, e.g., ROIN, the determination of step 408 may be performed by comparing the identifier of the systems requirement of the node accessed to the identifier of systems requirements of nodes already included in the second data representation. When the first data representation does not provide a unique identifier for each systems requirement, an algorithm may be used for comparing nodes and determining if a match exists between the node being accessed and the nodes already included in the second data representation.
If “no”, step 410 is executed. At step 410, a node is created in the second data representation B for holding the systems requirement of the node accessed from the first data representation A. If “yes”, step 410 is skipped, and step 412 is executed. At step 412, an edge is created for each of the accessed define and comply relationships which correspond with the accessed node. When no duplicate nodes are found in the first data representation A, it is possible that connectivity relationships among nodes in the second data representation B may be identical to the first data representation A.
The graph generator module 204 uses an algorithm for reading each node, determining if it is a duplicate of a node that was already read, and creating the non-duplicate graph of the second data representation by creating the nodes that were read without creating any duplicate nodes, and creating edges defining the relationships between all of the nodes. In one embodiment of the disclosure, the algorithm may be implemented using Resource Description Framework (RDF), which is a language for representing information about resources in the World Wide Web using a graph-based model. RDF provides semantics to encoded metadata and does not allow creation of duplicate resources, which adds capabilities of further processing of the second data representation.
Further processing of the second data representation may include (a) selecting a sub-section of the second data representation, such as for visualization thereof; (b) differential update of the first data representation, e.g., the specifications document or the tree, based on incremental changes to the second data representation; (c) annotating the nodes of a graphic visualization of the second data representation with their attributes of interest; and (d) graph related operations, such as union and intersection operations, e.g., merging, of more than one non-duplicate graph.
Selection of a sub-section of the second data representation may be facilitated, for example, using, a query language, such as RDF Document Query Language (RDQL), for writing queries to access selected nodes of the second data representation. Selection may be based, for example, on a connectivity property, an attribute, a specification of a node of interest for the sub-section of interest, a direction of visualization, where the directions include “up” for visualization of the defining requirements, and/or “down” for visualization of the complying requirements, and/or a number of levels to be included in the sub-section. A GUI may be provided by the GUI module 208 via which the user selects the node, direction and/or number of levels. The GUI may be menu based, include dialogue boxes, and/or a graphics editor for allowing the user to select the node of interest from the graphic visualization.
The differential update of the requirements document provides a mechanism for incorporating modifications to the second data representation into the first data representation, which may be, for example, the specifications document or the tree. Errors or the need to make modifications to the second data representation may be apparent when viewing the graphic visualization of the second data representation. In accordance with the present disclosure, the second data representation may be modified, such as by using a GUI provided by the GUI module 208 which may, for example, be menu based, include dialog boxes and/or include a graph editor for editing the graphic visualization of the second data representation and/or the second data representation. Edits to the graphic visualization of the second data representation may be incorporated into the second data representation, e.g., upon the user's request. Furthermore, the modifications made to the second data representation may be incorporated into the first data representation, the specifications document and/or the tree.
Annotating of the nodes allows for selectable attributes to be displayed for each node in addition to other information, such as the systems requirement's title and ROIN. When using the graph generator module 204 and the visualization module 206, the systems engineer is provided with a powerful and intuitive tool for submitting queries for selecting a subsection of the second data representation to be displayed, and selecting attributes associated with the systems requirements to be displayed.
Merging of two or more non-duplicate graphs may be useful for merging requirements documents of two or more different sources, such as sub-contractors or design teams. For example, a few requirements may be assigned to a particular group (such as a design team or a sub-contractor), where each group further defines its own particular set of systems requirements, or incorporates a dependency on a systems requirement assigned to another group. Merging of two or more non-duplicate graph may be facilitated using a tool such as Jena API.
The visualization module 206 receives as input a data representation which does not include any duplicate nodes. For example, the input to the visualization module 206 may be the specifications document, if it is believed that no duplicate nodes exist, or the second data representation. The visualization module 206 processes the input and generates a displayable version of the input data representation, e.g., the second data representation, for display on the output device 210, where the displayed data representation does not have any duplicate nodes and is displayed with a layout showing hierarchy of the nodes in accordance with a level or attribute.
The resulting display is easily comprehended by the user, as it shows the nodes in an easy to understand hierarchical layout with the systems requirements clustered in one direction, e.g., in layers stacked, such as from top to bottom, in accordance with an attribute or level associated with each systems requirements. Since the display does not include any duplicate nodes, all of the define and comply relationships for the systems requirement of each node are displayed for that node. Generation of the display may be implemented using a graph layout algorithm to position the systems requirement nodes on the screen of the output device 210.
The graphic visualization of the input data representation shows connectivity between nodes. Any node may be selected for visualization of connectivity and other properties associated with the node. For example, upon selecting a node, such as by clicking on the node, a window may appear adjacent the selected node in which information pertaining to the selected node is displayed. Using the graphic visualization, a node may be identified which is associated with a systems requirement which is a bottleneck requirement, e.g., a whole set of requirements comply with the bottleneck requirement and remain pending until the bottleneck requirement is resolved.
Determination of the layout for the graphic visualization may be performed using a variety of algorithms for laying out nodes in a hierarchical fashion. In one exemplary embodiment of the disclosure an algorithm disclosed by Sugiyama, K., et al., in “Methods for Visual Understanding of Hierarchical Systems, IEEE Transactions on Systems”, Man and Cybernetics, SMC-11(2):109-125, January 1981, and exemplified in “Graph Drawing and Applications for Software and Knowledge Engineers, World Scientific, Singapore, 2002, is modified and implemented for processing the second data representation for generating a graphic visualization.
Input to the modified Sugiyama algorithm is a directed acyclic graph, and the output is a hierarchy of nodes organized into horizontal layers. Systems requirements typically flow down in a directed acyclic nature. A hierarchical tree representation for systems requirements is, by definition, directed and acyclic. Additionally, if the first data representation is directed and acyclic, the second data representation will also be directed and acyclic. If the input data representation does, however, include a cycle, the algorithm executes for an infinite amount of time. The display on the output device 210 can indicate that a cycle was encountered and that a correction to the input should be made.
The modified Sugiyama algorithm is capable of performing the following steps:
1. Assigning vertical layers to the input data representation to form a proper hierarchy. Dummy nodes may be inserted during this step.
2. Minimizing the edge crossings in the displayed graphic visualization for readability.
3. Using priority layout heuristic to specify positions of the nodes within a particular layer.
4. Removal of dummy nodes which were inserted in Step 1, and replacing the nodes with bends in the line.
The steps are now described in greater detail.
In Step 1, the vertical level of each node is calculated in order to layout the entire graphic visualization in one direction (e.g., top to bottom) with the node which has no incoming edge (e.g., the source or root node) being at the top, and the rest of the nodes fanning out progressively downwards. This step partitions the entire directed graphic visualization G=(V, A) into V1, V2, . . . , Vh such that i<j when (u, v)εA, uεVi and vεVj. Accordingly, the source node is always placed higher than the target node for any edge belonging to the graphic visualization. For edge e=(u, v), uεVi, vεVj, the span of edge e is s(e)=j−i.
In this step, after assigning the nodes to the vertical layers, the hierarchical visual graph is transformed into a proper hierarchical graph. That is, for the long edge (u, v) joining vertex u on the ith layer and vertex von the jth layer, by adding dummy vertices v1, v2, . . . , vj−i−1, the edge (u, v) is replaced by path u=vo−>v1−> . . . −>vj−i=v. The reason for adding the dummy vertices is that it is difficult to handle crossings of long edges, and from Step 2 onwards, the span of all edges are one (i.e., the graph is assumed to be proper). It is desirable to have as few dummy vertices as possible to reduce machine computation time, reduce the number of bends that occur at dummy vertices, and to provide shorter edges which are easier for a human being to follow than long edges.
At Step 2, a determination of the order of vertices on each layer is made, which further achieves the step of minimization of edge crossings. The number of edge crossings in a drawing of a proper hierarchical graph is not dependent on the exact position of vertices, but on the order of vertices within each layer. Thus, the problem of minimizing the edge crossings is a combinatorial problem of choosing the appropriate order for each layer, and not a geometrical problem of choosing the x coordinate of each vertex.
Suppose that G=(V, A, h) is a proper hierarchical graph of height h. For G, the partition of V is expressed as V1, V2, . . . , Vh, and of A as A1, A2 . . . , Ah−1, where Ai is a subset of ViXVi+1. When an order σi for all elements in each layer Vi is given, then G is called an h layer graph and is written G=(V, A, h, σ). Where σ=(σ1, σ2, . . . , σh).
A matrix realization is used for the h layer graph G=(V, A, h, σ). The matrix M(i)=M(σi, σi+1) represents Ai as a ∥Vi∥X∥Vi+1∥ matrix, where the rows representing the vertices of Vi are ordered from the top by σi, and the columns are ordered by the order σi+1 on the vertices of Vi+1. The (k, λ) element m(kl) (i) of M(i) is given by:
M(i) is called the incidence matrix. When the incidence matrices are arranged in order, it is called the matrix realization ζ of the h layer graph, and is written as:
ζ(σ1, . . . σh)=M (i) . . . M (h−1)
The row vector r(v) corresponding to the vertex v of the incidence matrix M(i) expresses the incidence relationship of vertex v of the ith layer and vertices of the i+1th layer. When p and q are the number of vertices of the ith layer and the i+1th layer, the number c of crossings of the edge between the jth and the kth vertices vj and vk of the ith layer and vertices of the i−1th layer is given by:
Therefore the number of crossings between the ith layer and the i+1th layer is given by:
Therefore the total number of crossings C(ζ) of ζ can be found by:
C(ζ)=C(M (i))+ . . . +C(M (h−1))
The row barycenter γk and column center ρ1 of incidence matrix M=(mkl) are defined as:
γkΣl=1 q l.m kl|Σl=1 q m kl
p l=Σk=1 p k.m kl|Σk=1 p m kl
Using a barycenter method, for the matrix realization ζ=M(σ1, σ2) of a two-layer graph, the order of columns is fixed. When rearranging the order of rows, the row barycenters are calculated and arranged in monotonically increasing order (however, in the case of equal barycenters, the initial order is preserved). Likewise, the order of rows is fixed, and when rearranging the order of columns, the column barycenters are calculated and arranged in monotonically increasing order. When M(σ′1, σ2) is obtained by rearranging the columns of M(σ1, σ2), the process is called row barycenter ordering and written as BOR(M). The column barycenter ordering, BOC(M), is defined in the same way. By repeatedly alternating row and column barycenter ordering, a reduction in the number of crossings can be achieved.
In accordance with the Sugiyama algorithm, the edge crossings reduction procedure includes PHASE 1 and PHASE 2. In PHASE 1, the alternating row/column barycenter ordering is carried out for a predetermined number of iterations (or until the number of crossing ceases). In PHASE 2, if there are any rows or columns of equal barycenters left at the end of PHASE 1, the order of these rows or columns is reversed by units of equal barycenter groups, and PHASE 1 is carried out. Therefore, PHASE 2 contains PHASE 1 as a sub-algorithm. IN PHASE 2, the operation to reverse the order of equal barycenter rows for M is written ROR(M), and the operation to reverse the order of equal barycenter columns for M is written ROC(M).
For h layer graphs as for 2 layer graphs, the barycenter ordering can be applied repeatedly consecutively to each layer. That is, first the ordering of layer V1 is decided, then for i=1, 2, 3, . . . , h−1, the order of layer Vi is fixed and the order of layer Vi+1 is decided such that the number of crossings between layer Vi and layer Vi+1 is reduced, which is called the downward pass. Conversely, going from layer Vh to layer Vi is called the upward pass. The algorithm is the same as for two-layer graphs.
In Step 3, from the crossing number reduction methods of the previous section, the layout order of vertices σ* with few crossings is determined. To decide the placement of vertices in this step, σ* is received as input, and the aim is to achieve the four drawing rules, i.e., least separation, closeness, balance, straight lines. This can be achieved using either the quadratic programming method, or using a heuristic, namely, a priority layout method. In accordance with the exemplary algorithm of the present disclosure, a priority layout method is used to minimize machine computing time. The basic concepts are similar to the multi-layer barycenter method, and improvement steps for the layout coordinates of vertices on each layer of a multi-layer graph are consecutively repeated across all layers from top to bottom, and bottom to top. Priority is used for each vertex in improvement of vertex layout coordinates in each layer. The outline of algorithm is as follows:
In accordance with the present disclosure, the following modifications have been made to the Sugiyama algorithm:
1. The maximum number of iterations for PHASE 2 is selectable by the user, as opposed to the original Sugiyama algorithm which continues the PHASE 2 iterations until the minimum number of crossings ceases to decrease.
2. During execution of PHASE 1 and PHASE 2 iterations, a snapshot of the generated graph is saved whenever we encounter a topology having a lower number of edge crossings than what is stored in a variable defined as the minimum global crossings, as it was discovered during testing that sometimes the minimum number of global crossings achieved is not the final result outcome of the algorithm.
3. The user may select whether to use a random method or the reverse barycenter method described above for minimizing edge crossings. In the random method, a node is randomly assigned at each starting point of PHASE 1 and PHASE 2 is eliminated. Accordingly, using the random method, computation steps are reduced relative to the reverse barycenter method.
4. Using a priority layout method for achieving a final graph balance, the user may heuristically select a horizontal level at which to start the iterations, which may result in a better graph balance.
5. In PHASE 2 of the Sugiyama algorithm, the procedure for swapping two nodes with equal barycenters followed by carrying out PHASE 1 is performed by swapping all nodes with equal barycenters and then carrying out phase 1 minimizing computational steps.
6. A clustering constraint for clustering of requirements is user selectable. A clustering constraint forces the requirement nodes to be positioned at respective coordinates defining vertical displacement along a horizontal level so that all of the requirement nodes along a horizontal level have a same attribute value (e.g., assigned level, geographical location, etc.) for a particular attribute. The attribute to be used for determining the horizontal level within which the requirement nodes are clustered may also be selectable. When a user chooses not to enforce (e.g., select) the clustering constraint, the requirement nodes are not clustered in horizontal levels in accordance with their attribute values for any particular attribute. Accordingly, a horizontal level of requirement nodes may contain requirement nodes having a variety of attribute values for any particular attribute. When the clustering constraint is not enforced, a layout of requirement nodes may be possible with even fewer edge crossings.
The graphic visualization 500 may also be generated without selecting the clustering constraint. The requirement nodes 502 shown in levels 504 and 506 may be mixed in one or more horizontal levels, and even fewer edge crossings may result. The requirement nodes 502 may be color coded in accordance with their respective associated attribute values for visual distinction.
The GUI module 208 provides a GUI upon activation by a user of the graph generator module 204 and/or the visualization module 206. The GUI presents the user with options for selecting an action, e.g., via menus, an interactive graphical editor and/or dialogue boxes. Examples of actions which may be selected include selecting a first data representation (which may be a data structure), generating a second data representation based on the first data representation, selecting sub-sections of the second data representation to display, selecting attributes to display with the respective systems requirements, merging the second data representation or sub-section thereof with another data representation, modifying the second data representation, applying the modifications to the first data representation or another data representation related to the second data representation, displaying the first and second data representations and/or displaying information related to sub-sections or selected systems requirements of the second data representation.
For example, link 618 a represents a relationship between node 604 a and element 612 a, link 618 b represents a relationship between node 604 b and element 608 b, link 618 c represents a relationship between node 604 c and element 608 a, link 618 d represents a relationship between element 608 a and element 616 a, link 618 e represents a relationship between element 608 a and element 616 b, and link 618 f represents a relationship between element 608 b and element 616 c. Furthermore, the relationship between node 604 b and element 616 c is represented by links 618 b and 618 f, the relationships between node 604 c and elements 616 a and 616 b are represented by links 618 c, 618 d and 618 e.
Information pertaining to the relationships between nodes 604 of the hierarchical graph of representation 602 and elements of representations 606, 610 and 614 can be accessed, such as by displaying a graphic visualization of the system 600 and/or accessing the node 604, or the elements of the representations 606, 610 and 614 via a GUI provided by GUI module 208 (or a network of GUI's). By providing the relationships 618, all of the systems requirements involved in developing an element of the system 600 are readily accessible. Since there are no duplicate nodes 604, it is possible to determine visually, or by submitting a query, all of the nodes which must be resolved in order to resolve an element of the representations 606, 610 and 614. Conversely, by clicking on an object in the engineering element 616, reverse traceability links are provided for allowing engineers to see the list of requirements to which the object 616 complies.
The described embodiments of the present disclosure are intended to be illustrative rather than restrictive, and are not intended to represent every embodiment of the present disclosure. Various modifications and variations can be made without departing from the spirit or scope of the disclosure as set forth in the following claims both literally and in equivalents recognized in law.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4953106 *||May 23, 1989||Aug 28, 1990||At&T Bell Laboratories||Technique for drawing directed graphs|
|US5606654||Dec 21, 1993||Feb 25, 1997||International Business Machines Corporation||Computer screen and memory organization enabling presentation of a tree|
|US5892682||Jun 17, 1996||Apr 6, 1999||Motorola, Inc.||Method and apparatus for generating a hierarchical interconnection description of an integrated circuit design and using the description to edit the integrated circuit design|
|US5977971||Aug 14, 1998||Nov 2, 1999||Microsoft Corporation||Tree view control|
|US6105062||Feb 26, 1998||Aug 15, 2000||Novell, Inc.||Method and system for pruning and grafting trees in a directory service|
|US6151024||Mar 31, 1998||Nov 21, 2000||International Business Machines Corporation||Data processor controlled display interface with tree hierarchy of elements view expandable into multiple detailed views|
|US6789054 *||Apr 25, 1999||Sep 7, 2004||Mahmoud A. Makhlouf||Geometric display tools and methods for the visual specification, design automation, and control of adaptive real systems|
|US7207038 *||Aug 29, 2003||Apr 17, 2007||Nokia Corporation||Constructing control flows graphs of binary executable programs at post-link time|
|US20030177018 *||Mar 18, 2002||Sep 18, 2003||Eastman Kodak Company||System for designing virtual prototypes|
|1||http://www.sdrc.com/slate/ (2 pages).|
|2||http://www.telelogic.com/products/doorsers/doors/ (2 pages).|
|3||http://www.vitechcorp.com/CORE/productline.html (2 pages).|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7971193 *||Jul 14, 2006||Jun 28, 2011||Hewlett-Packard Development Company, L.P.||Methods for performining cross module context-sensitive security analysis|
|US8266519 *||May 15, 2008||Sep 11, 2012||Accenture Global Services Limited||Document analysis, commenting, and reporting system|
|US8271870||Sep 11, 2009||Sep 18, 2012||Accenture Global Services Limited||Document analysis, commenting, and reporting system|
|US8286135 *||Oct 17, 2007||Oct 9, 2012||Cray Inc.||Performance visualization including hierarchical display of performance data|
|US8412516||Nov 27, 2007||Apr 2, 2013||Accenture Global Services Limited||Document analysis, commenting, and reporting system|
|US8442985||Feb 17, 2011||May 14, 2013||Accenture Global Services Limited||System for requirement identification and analysis based on capability mode structure|
|US8566731||Jul 6, 2010||Oct 22, 2013||Accenture Global Services Limited||Requirement statement manipulation system|
|US8671101||Apr 30, 2013||Mar 11, 2014||Accenture Global Services Limited||System for requirement identification and analysis based on capability model structure|
|US8843819||Jul 29, 2010||Sep 23, 2014||Accenture Global Services Limited||System for document analysis, commenting, and reporting with state machines|
|US8935654||Jan 9, 2012||Jan 13, 2015||Accenture Global Services Limited||Analysis system for test artifact generation|
|US20110231418 *||Sep 22, 2011||Biron Ran||Graph transformation|
|US20120296940 *||Nov 22, 2012||Accenture Global Services Limited||Document analysis, commenting, and reporting system|
|US20120311537 *||Dec 6, 2012||Cray Inc.||Performance visualization including hierarchical display of performance data|
|US20130325529 *||May 29, 2012||Dec 5, 2013||International Business Machines Corporation||Analyzing Engineering Requirements|
|US20140208292 *||Mar 25, 2014||Jul 24, 2014||International Business Machines Corporation||Generating application model build artifacts|
|Nov 4, 2005||AS||Assignment|
Owner name: UNIVERSITY OF MARYLAND, MARYLAND
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:AUSTIN, MARK A.;SHMUNIS, NATALYA;MAYANK, VIMAL;AND OTHERS;SIGNING DATES FROM 20050617 TO 20051017;REEL/FRAME:017185/0282
|Mar 20, 2006||AS||Assignment|
Owner name: MARYLAND, UNIVERSITY OF, MARYLAND
Free format text: RECORD TO REMOVE 4TH ASSIGNOR S NAME FROM AN ASSIGNMENT DOCUMENT PREVIOUSLY RECORDED ON REEL 017185FRAME 0282;ASSIGNORS:AUSTIN, MARK A.;SHMUNIS, NATALYA;MAYANK, VIMAL;SIGNING DATES FROM 20050617 TO 20050720;REEL/FRAME:017647/0399
|Jul 23, 2014||FPAY||Fee payment|
Year of fee payment: 4