I have a legacy system I need to plan a migration for. It's mainly developed in Ingres+4GL (an old Ingres based form system).

I have the following information:

  • Data Structures (data base relations and their relationships)
  • All programs accessing the underlying Ingres Data Structure

I coded a parser for Ingres and 4GL programs using ANTLR4 and using that I also extracted the following information:

  • What program access which data structures (tables)
  • What program run which stored procedure
  • What stored procedure access with data structures (tables)
  • What tables are accessed together (from the same programs)
  • What tables have READ and/or WRITE access from which programs

My question is:

What can I use to graphically represent all these relationships? Is there a Software/Standard that may help me on this?

I was thinking of running a clustering algorithm on the gathered data to see if there are any clusters that might be migrated together?


What you have and what you can do

A first look suggests that you have a nice graph:

  • Programmes, stored procedures and data structures, are all some kind of nodes. The first are processing nodes, the latter are storage nodes
  • Read and write relations, are directed edges that show the flow of data between the nodes.

With such a graph, you can already:

  • analyze the potential impacts of a change in a node, by looking downstream, just following the direction of the edges.
  • analyse migration requirements, by going down and upstream (ignore direction of the edge).
  • compute closure sets to identify "clusters" that should be migrated together.

How to represent your data ?

There are plenty of graphical standards that you could use. However, basically, what you have is a data flow graph, and the easiest way to picture it, would be to show a data flow diagram (DFD). Two popular representations are Yourdon&Demarco and Gane&Sarson: both DFD show little difference and basically they have processor nodes, storage notes and flow edges, exactly what you have.

DFD diagrams are a little bit outdated nowadays. This is because they represent a procedural view of the world, separating passive data from active processes. This is certainly why there is no real equivalent in UML which is build on the object oriented paradigm. The UML information flow diagram is a fair approximation (although it doesn't really have stores). The UML communication diagram is another approximation, if you consider programs and individual tables as object instances.

Addendum: The UML component diagram (see Doc Brown's answer) is also a viable approximation, if you consider your passive data as an active component (after all, it's behavior is ensured by the RDBMS engine). However the interface connectors that you will need (at least one for a read and one for a write, if you don't want to loose the direction of the edges), will make it less readable and more difficult to draw.

What's maybe missing in your toolset ?

I don't know INGRES. But if it's a RDBM with stored procedures, comes the question if there is any referential integrity mechanism (e.g. hidden procedures that could cascade deletion and changes), or any foreign keys that could give a better understanding of how tables are related between them. This could help you to further analyse your mesh by taking into account non obvious dependencies.

  • Honestly, though your overall answer is fine, I heavily disagree that DFD represent a "procedural view" of the world. Quite the opposite, they show a view which maps much better to functional and event driven programming than to OO and procedural thinking. And I guess the real reason DFD were introduced way too late into UML again (as information flow) are political and trademark reasons, or maybe because of the "Not Invented Here" phenomenon. – Doc Brown Nov 27 '17 at 19:13

An UML component diagram is probably your best shot if you are looking for some kind of standard graphical notation to show the dependencies betweens components like programs, stored procedures, or tables. Read vs Write acess can be expressed as sterotypes for the dependency relationships.

If, however, this stays readable and understandable, depends heavily on the size of the system and the number of components involved (but that's probably not a fault of the UML notation, but a problem with any graph notation you will pick).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.