BI Tools

Tips and tricks for building information maps, OLAP cubes, reports, and dashboards

BI Admin

Learn your way around a SAS BI installation.

Visual Analytics

Learn your way around the SAS Visual Analytics tool

Coding & Data

Extract, transform, and load your data into the SAS BI toolset

Stored Processes

Create and design stored processes like a rock star

Home » Coding & Data, Data Visualization, Enterprise Guide

How Do You Flowchart a SAS Program?

Submitted by on 2015-03-02 – 8:00 AM 5 Comments

library_of_congress_00439rI’m a visual person – I always need a picture. As a consultant, many times I’m given a thumb drive full of code and asked to make modifications.  When you are on a project with me, you’ll grow weary of hearing me say “Can you draw it?” Something magical happens for me when I see a flow or see an idea.

One of the most confusing projects I ever worked on required completely re-writing a job that had more than 100,000 lines of code and had grown out of control over a 5 year period.  I’ve come to see this situation as an industry hazard. For SAS Global Forum 2011 I wrote a paper called Plate of Spaghetti Anyone? about learning someone’s else code.  I created a flowchart for the code before I started but it was impossible to read. It was so impossible, we finally started taking requirements from the code and tossed  most of the code in the Unix trash can.

For the remake,  I created many flowcharts with my good friend MS Visio. It helped the managers understand what was going to happen. The person who came behind me most likely thought the process was confusing but received more documentation than I did about what the code was designed to do and how the flow worked. It was a good learning experience for me as well. Now the first thing I do is start creating flowcharts when I’m handed code or even requirements documents.

Really when you think about it, flowcharts are just another example of data visualization. You are creating a drawing from words to show how the data flows through the program and quickly communicate the data transformation.

Here’s what I learned from drawing and reading a gazillion flowcharts for SAS programs.

It’s Not Always 1:1 Relationship with Code

It’s useless to map SAS programs in a flowchart step by step. Unless the program has macro code in it, any logic statements are usually within a data step or perhaps a PROC SQL statement. When I have tried to do it in the past, I realized that the diagram usually looked like the following one and rarely explained anything other than it took a lot of steps to get where it was going.

sas program flow chart

Click for a larger view

The above example really could be any one of 10,000 SAS programs.  All it really shows is the actual steps the programmer used but it doesn’t really help you understand why the dataset was created.  You really just know it was taken from a data source, changed in some way, sorted and given to an information map. You could have guessed that much before you looked at the flowchart!  In this example, the logic is all occurring in the data step.  This is why programs that map the steps are useless for understanding the code.

Now consider what happens when we actually plot the purpose or the logic of the same program.  We can see where the 3 steps are used but now we understand that we are determining if the customer orders are on time by business unit. It outputs the results to a table ready for an information map – this is a simple example because an information map could have complete these steps. [You can create info maps from code – did you know that?]

flowchart_02

 

Flowcharts that Make You Groan Like Broken-down Machinery

Here’s an example of a flowchart that  breaks all the rules of communicating a process quickly and with ease.  I did find this on the Web but it’s not important who did it or what it’s really about – you can learn from the example.

flowchart_04a

Where does it start and when does it end?

Use indicators that show where the process starts and ends. Users need to understand what causes the process to start and when it ends. Remember the person reading the chart doesn’t have any idea how it works so they don’t know where the user or data enters the process. I start at the upper left corner for no reason other than that’s how most people read text on a page.

It’s helpful if you use the same shapes everyone else does – like a process is a box, a decision is a diamond – you get the idea. Check Wikipedia for more flowcharting basics.

Check your logic!

Study this flow chart – notice that the same steps are there twice and it’s based on if the child comes to the appointment.  Why not have the person review the records and then determine if the child is present?  It would only have to be there once.   If the child shows up 95% of the time – do the chart from that perspective.  Think of your SAS program the same way, what is the main logic path. You want to show how you handle exceptions but typically your program is about handling what is right. When the chart wraps around itself the main path is not clear.  This is a smaller chart so there are probably less consequences, but complicated logic could make this really confusing.  Try to avoid having your logic wrap around the page – use more pages instead.  Remember you are trying to communicate clearly not save a PDF page.

Be consistent!

Have your decision points always go the same way. Its confusing when the Yes is sometimes going down and sometimes going to the side.  Change the question to make the logic flow the same way.  In this chart, only one Yes actually goes down so the reader can be tricked.  Many flowchart professionals say the “Yes” or “True” always goes down – I say just be consistent.

Flowcharts You Love Like Your Momma’s Cookin’

Ok – it’s my flowchart – of course we love it! It’s the flow for my macro that check the batch log and sends an email based on what happened.  Here’s how I might have done the flowchart for the code. Notice that you never see a SAS word like data step, proc sql, and so on.

flowchart_03

Click for larger image

 

Notice that the logic inside Step A is a little more complicated so I expanded that into a second chart.  This is an example of how to handle a larger process when you have multiple paths that need explanation.

Never miss a BI Notes post!

Click here for free subscription. Once you subscribe you'll be asked to confirm your subscription through your email account. You email address is kept private and you can unsubscribe anytime.
The following two tabs change content below.

Tricia Aanderud

Director of Data Visualization at Zencos Consulting
Tricia Aanderud is a SAS Business Intelligence and Visual Analytics consultant based in Raleigh, NC who works for Zencos Consulting. She has written several books about SAS, presented papers at many SAS conferences, and has been using SAS since 2001. Contact her for assistance with your next project.

Tags: ,

5 Comments »

  • Chris Jones says:

    This starts off awesomely, and just keeps getting better.

  • Tricia says:

    Oh good points and a good link Jaap! I’ve never even heard of this method. Thanks!

  • jakarman says:

    Nice post again Tricia. There were times drawing flow-charts were mandatory before being allowed to code. Flow-charts got standard approaches and being bashed for the goto usage. Edsel Dijkstra http://en.wikipedia.org/wiki/Edsger_W._Dijkstra was trying to get that banned.

    There is an other way of bringing program logic into a visualization. That is http://en.wikipedia.org/wiki/Nassi%E2%80%93Shneiderman_diagram.
    The loop is there in both constructs as the selection. You can extend it to a contrstruct for map/reduce (parallel processing).
    The order of execution logic is the vertical line the actions that can be executed in the same time-frame in the horizontal.
    When needing duplicate processes you are into funstions/routines.

    This approach is forcing a very structured way of thinking.

  • Tricia says:

    Thanks Don – good points. Many times what the code is supposed to do and the code are two different things. 🙂

  • Great points. Permit me to add what I think are a couple of important questions to ask:

    – what is the code supposed to do?
    – what is the desired output?

    I always make these my first priority. By just focusing on the code, the techniques to implement that code become the functional requirement instead of the true underlying requirement.

    Back in the 70s when I was just out of school I learned a lot from a fellow programmer (Bob). Bob did most of his work in Fortran. And the first thing he did when someone send him a card deck to review was go to the card sorted and sort the cards on column 1. In other words he got rid of all the comments. He explained his rationale (which I still agree with):

    I want to read what the program is doing, not what the programmer thinks it is doing