Todd

Hi, it's Todd here, and I'm joined by Alen. Today we're going to look at a tool called Klocwork Architect that will help you visualize the architecture of your source code. So, Alen, what are we going to talk about here?

Alen

Today I want to cover a little on code visualization, impact analysis, and what you can do help you with "what if" scenarios.

Todd

You mentioned code visualization. Now that's just seeing the structure of your source code.

Alen

Yes, that's exactly that. Right now, we're looking at just an open source project called CVS. It's an open source configuration management system. What I want to do is just show you how you can look at the code and see how it's all structured. It's just your regular directory structure. I drilled down through that. I can see what's underneath that. These are the C and header files that are associated with this project. I can drill at any level. You can see all the different colors that are associated with whether we're talking about actual functions themselves or declarations or types or variables.

Todd

Okay. Moving on to impact analysis. From what I understand, impact analysis basically lets users understand the impact their changes will make on their code. Can you give us an example?

Alen

Yes. What we're looking at here is how we've drilled down to, right now, the very lowest level, the function level, the actual low level entities. You'll notice, obviously, a big part of this is all these black lines are connecting each and every one of these components. These represent the dependencies or relationships between these. Anything that's connected to one other component, it's showing you a relationship between the two. Anything connected to the outside of the box, meaning it's connecting to something else outside of the current diagram that we're looking at.

Now to show impact analysis, obviously, these dependencies become very important. They help us show, for example, what are the uses or what are the changes that I made to this one function, called diff2files, or you can look at any particular direction. So whether we're looking at this particular function itself or any other one to say, "Highlight Users," this will show me all the direct things that if I make any changes to this function at this current level, what will get impacted by that. That applies to any level that you're looking at. So, for example, if I expand this one file out and I say, "Highlight Users," again you get the dependencies that are directly reliant on this.

Now, something that's very important to talk about is it's not very helpful just to look at a bunch of red lines here that's being showed to us in the diagram. What you really care about is getting the details of that. So, that's when we'll go into Users Detail. Again, just a click of a button will show us all those dependencies that actually are applied here. So this, essentially, you get your impact analysis report. You can export this out and off you go.

Todd

All right. Let's turn the tables here a little bit to the "what if" scenarios. How are these "what if" scenarios different from the impact analysis you just talked about?

Alen

There are a number of things we can look at. For example, what I want to show you is something that we call, an anomaly called clusters. First of all, let's look at a certain type of relationship. I'm gong to call these references relationships. We create that. We can just save that accordingly. So now we have this new relationship type called references. You can see how the dependencies change automatically in terms of what we're looking at here.

One thing that I want to do, like I said, is find all the clusters. What's a cluster? Here we've highlighted one. This is something where you have a dependency between two or more components, where one depends on the other. It comes right back to the original. What you get is a circular dependency. Not exactly ideal. They're okay to have, but it certainly adds to the maintainability and complexity of your system.

You can use Klocwork Architect to really drill into these and see what can I do to optimize this. One anomaly here, I see that source calls Lib 346 times, but Lib calls source only 4 times. That's a little bit odd. Let's investigate. We click on the line. We go and see what those dependencies are. They belong to this one file called Error.h. Now, we were talking about "what if" scenarios. So, what we mean by that is, what if I just play around with this architecture? I'm not changing anything in the source code. All I'm doing here is just playing around with this database to see what happens if I drag and drop this right at the main diagram. Do you see those four dependencies? They do, in fact, go to Error.h, and there are a huge number of relationships going to that as well from the source component.

In fact, I'm just going to cut this out. I'm going to paste it right into the Lib, because that's probably where it belongs. You can see that I don't have those four dependencies to source anymore. Now, I can just do my Find Clusters, and it tells me immediately "No clusters found." So it's really about identifying different types of anomalies and playing around with the architecture. You're not changing your source code. You can bet a Compare With Report so it tells you what's changed of anything that you do change with the architecture. It's just a tool, think of this like your whiteboard. You can play around and make the necessary changes to make it more maintainable, more reusable, and less complex going forward.

Todd

Could I have prevented that cluster ahead of time?

Alen

Yes, and that's exactly a great value that the Architect can do as well is create architectural enforcement. So I could have said from the beginning that Lib should never call source. Lib is where all the libraries are. This is where our reusable code should be. It should never be calling our implementation code. So we could have simply created a rule, saying from this component to that one, I don't want to see any issues. Then anytime you're running Klocwork's full analysis, you'll always get these reports telling you about any kinds of architecture violations.

Todd

All right, Alen. Thanks for the demo.

Alen

You're welcome.

Todd

For more information, check out our website at www.Klocwork.com/documentation.