Use the Project Portability button (Project->Configure Project->Files) to make your project sharable/portable.

More details

We’ve developed a UML Class Diagram for Understand. You can grab it from the plugins page. Update: This diagram is now shipped with Understand and is available in the Graphs menu.

As of build 516 If you are editing a code file you can quickly switch to the corresponding header file and back again with Ctrl+’ (apostrophe).

Last month, we decided to temporarily close the forum. We have finished setting up a new forum and are “open for business” again.

We are focusing the new forum on Understand 2.5 so are not migrating the content from the old forum. If you need to access old posts for some reason you can temporarily find them here.

You will need to create a new user account, and to prevent spam, all new user registrations are reviewed before you can post the first time. We apologize for the initial inconvenience but feel it will make the forum much more useable for everyone in the long run.

You can access the forum on the support page of the website, or here:

http://www.scitools.com/support/forum

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a ‘refactoring’) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.  — Martin Fowler  http://www.refactoring.com/

In other words, refactoring is making your code cleaner, safer, and easier to use. Understand can be a very powerful tool in your re-factoring arsenal. Here are a few ways you can use Understand in your refactoring process.

Read the rest of this entry »

Understand has many different metrics, including a large number that focus on counting the number of statements and lines of code, including Lines of Code (LOC or SLOC), Lines with Comments (CLOC), empty lines (BLOC), Number of Statements, Number of Executable Statements, etc.

The short C/C++ example below shows how each line and statement contribute to these metrics in Understand. You can view the larger version here.

We have made a lot of changes to the licensing in Understand 2.5. How does this affect you?

1. These changes require a new license key.
2. All Understand features are now available to all users

As always, as long as your maintenance is up-to-date, there is no cost for the new version of Understand, we just need to generate a new license for you. The dialog that pops up when you start Understand has three options for getting that new license, whichever you choose, we will get the license to you quickly and without any hassle.

What if your maintenance is not current? You can still use any of these options, and we will get you a quote for getting back up-to-date. Also, the 2.5 install does not overwrite your previous version, so you can continue to use Understand 2.0 with your previous license.

Read the rest of this entry »

We’ve added a new dependency graph with some great interactive capabilities. If you’ve been looking for a way to visualize your high level code layout and intra-project dependencies, this is it. Watch this short video to get a taste of how useful these graphs are.

Dr. A. Gunes Koru and Dr. Khaled El Emam’s latest paper in IEEE Software, titled “The Theory of Relative Dependency: Higher Coupling Concentration in Smaller Modules”, turns conventional thoughts on where to test upside down by showing that smaller modules, not larger or more complex modules, can provide more effective testing payback in terms of defects eliminated:

Abstract:

Recent studies have repeatedly found that smaller modules are proportionally more defect-prone. In this article, the authors formulate and test a hypothesis stating that smaller modules are proportionally more coupled, given that dependencies caused by coupling have been consistently associated with defect-proneness. Strong evidence supports this hypothesis. Furthermore, refactoring exacerbates this effect. On the basis of this study’s highly consistent results, the authors state the empirically based theory of relative dependency. That is, in large-scale software systems, smaller modules will be proportionally more dependent compared to larger ones. These findings have two implications for practice. First, we now have an empirically supported mechanism explaining the observations that defect concentration is higher in smaller modules. Practitioners can use this mechanism as evidence while seeking resources and support to revise or amend their organizations’ quality assurance and quality control practices. Second, particularly for the projects that refactor extensively, such as those using agile methods, focusing defect detection activities on smaller modules will increase their efficiency and effectiveness even more.

They used Understand to generate the C++ measurements of many large open source projects.  We donate licenses of Understand to worthy research projects frequently. We’ve e-mailed many times with Dr. Koru to support his efforts and are pleased his work was accepted by IEEE.

The team extensively used the DIT (Depth Inheritance Tree) and CBO (Coupling Between Objects) that Understand provides.

We’ve noted a few ideas for product enhancements from reading their article.

We changed our website concurrent to introducing Understand 2.5.  We hope you like it. We’ve tried to keep it stylish and focused on information, not fluff.

You will notice, however, that the Support Forum hasn’t been moved.  We’ve had trouble with it and our searching for a replacement.

It will come back on line, but not until we have a replacement we think we can stick with long term.

For now, use support@scitools.com or the Chat available on the website for support.