In this example, we also require that component subassemblies are identifiable. Graph Algorithms accompany the Graph package that help accomplish this task.
As with Graphs, the Graph Algorithms package simulates parameterized types and we must declare them using declare and implement constructs similar to those needed for the Graph classes:
//in a .h file #include <Graph_alg.h> . . . Graphdeclare2(Product,Module,Transport_Time) Graph_algdeclare(Product,Module,Transport_Time) . . . //in a .c file . . . Graph_algimplement(Product,Module,Transport_Time) . . .
Note that the Graph_alg declare takes exactly the same arguments as the Graphdeclare macros, and follows the Graph version: Graph_algdeclare(...) requires the Graph declarations to be in place before it is invoked.
To answer the question ``Where is a given module needed?'', we simply invoke either the depth-firstsearch algorithm, dfs, or the breadth-first search algorithm, bfs. (In this application, either algorithm can be used, since we are not specifically interested as to the order of the Module pointers returned.) dfs and bfs are defined to take a root Vertex and return a list of pointers to Vertices that can be reached from the root. The ordering in the list reflects the order in which the Vertices were visited in the search, which is useful in many applications. (See the section, ``Traversals'', for more information on these algorithms.) Using the directed version of dfs or bfs, with module K as the root Module, we will then get returned all Modules that can be reached from module K, or, in other words (relevant to our example), which ``need'' K:
List_of_p<Module> mlist = dfs(widget, &m7); // or List_of_p<Module> mlist = bfs(widget, &m7);
(where widget is the Product, and m7 is module K).