Getting Started with RDi’s Application Diagram, Part 1: Source Call Diagram
October 7, 2009 Susan Gantner
|
RDi’s Application Diagram tool has some features that developers may find very useful, but initially finding your way around with the tool isn’t always easy. For that matter, many developers have never even noticed that the feature exists. So in this tip, I’ll take a look at how to get started using the Application Diagram. If you ever used CODE (a.k.a., CODE/400) in the past, you may be familiar with a feature of that pre-RSE toolset called Navigator. I didn’t use Navigator very often, but when I needed it, it saved me a lot of time. The basic idea of Navigator was to produce a diagram of the logic flow between subroutines and/or subprocedures to graphically depict the relationships between the various routines in a source member. When faced with trying to make sense of the flow of complex program logic, it could save hours of pouring through source code line by line. As its name implies, Navigator also could be used to navigate around the member to locate the code for a particular routine. RSE’s updated version of the CODE Navigator tool is called Application Diagram. Before I describe how to get started using the Application Diagram, I should warn you of a few limitations before we get started. This feature exists in RDi 7.1, but in my experience, it didn’t seem to work consistently until I updated to RDi 7.5.0.3. Also, it doesn’t work for all languages. The parts of the diagram that work with source code only work with RPG IV, ILE COBOL, and CL (either ILE or OPM). There are 2 ways to work with the Application Diagram. I’m going to concentrate here on the one called the Source Call Diagram. To begin using the Source Call Diagram, choose a source member in the RSE view, right click on it and choose the “Visualize Application Diagram” option. Next you should see a diagram of the routines (subroutines or subprocedures) in that source member and their relationships with each other and the main program logic.
You can see in this example that the main program calls a subroutine called Main. Main calls subroutines ACDESr and EditSl and a subprocedure called ValidDate. Note that the icons attached to the box depicting each routine identifies it as either a subroutine or a subprocedure. You can also see an arrow going outside the box to an external piece of code (a program in this case) called CvtDate. This is a much quicker way “visualize” the flow of logic in this program than trying to sort through the raw source code, even with the help of RSE’s Outline View. Try it with your most infamous monster source member. You can move the boxes around in the diagram with your mouse, which is something I do often to ensure all the connections are easily visible. The diagram is also interactive to an extent. If you were to click on the box representing ACDESr, the three lines coming into it from the left (from Main) turn red, and the four lines going out from the right to other subroutines turn green to highlight the called and calling relationships. In this relatively simple source example, that isn’t necessary, but in a larger, more complex source member it could make the relationships far more clear. You can also double click on any of the boxes and your editor view will be positioned to that routine in the source code (opening the source member in the editor first, if it’s not already there.) This feature is most effective when you have your source code in a split screen editor view with the diagram. If you don’t know how to split your editor screen, take a look at my earlier tip, Giving RSE a Split Personality. I have one update to that previous tip: a new feature in RDi 7.5 means we no longer need to create a special perspective to make split-screen work in full screen mode. Speaking of larger source members, if your source call diagram doesn’t fit inside the window, you can use the zoom feature. There are several ways to use the zoom. You may have noticed a zoom tool on the Palette attached to the right of the diagram. But I find that an easier way to zoom the diagram is to use a zoom percentage box that appears in the workbench toolbar above the diagram. The drop-down menu attached to that percentage zoom box offers many zoom options, including selecting a different percentage and “zoom to fit.” Of course, with very large diagrams, zooming out to be able to see it all just makes everything too small to read. So for those cases, take a look at your Outline View. The default format of the outline shows a gray box that can be moved to scroll around the diagram like moving a magnifying glass around to enlarge specific portions of the diagram at a time. The Outline View also has a text view that looks much more like the Outline View we’re accustomed to with the editor. It contains a list of the resources (i.e., the boxes in the diagram). You can use this list to select a routine and the diagram will highlight that routine and automatically scroll the diagram, if necessary, to make it visible. By the way, you’re not limited to a single source member with the Source Call diagram. You can select as many source members as you like at once and visualize a diagram for all of them. Just make sure you haven’t selected source members for any unsupported languages. You’re also not limited to generating and working with a Source Call diagram separately from the other kind of diagram, the Program Structure Diagram. Whereas a Source Call diagram focuses inward, looking at the logic within source members, the Program Structure diagram focuses on the relationships between the objects, such as programs and the Service Programs they use. Personally, I find it easier to deal with the two types of diagrams separately, but they can appear together. There is more to know about Source Call Diagrams, but I hope I’ve given you enough information to get you started working with them. I haven’t covered the Program Structure Diagram at all yet, but I think I’ve gone on long enough for one tip. I’ll cover the other type of diagram in a follow-on tip. Susan Gantner is one of the most respected System i gurus in the world and is one of the co-founders of System i Developer, an organization dedicated to RPG, DB2, and other relevant software technologies for the System i platform that hosts the new RPG & DB2 Summit conference. Gantner, who has worked in IBM’s Rochester and Toronto labs, left IBM to focus on training OS/400 and i5/OS shops on the latest programming technologies. She is also a regular speaker at COMMON and other user groups. Send your questions or comments for Susan to Ted Holt via the IT Jungle Contact page. RELATED STORY Giving RSE a Split Personality
|
