Dr. Dobb's | Lessons Learned | November 01, 2006

When moving complex commercial software to new platforms, third-party components can shorten development time.

Alion Science and Technology is a technology solutions provider delivering technical expertise and operational support to the Department of Defense, civilian government agencies, and commercial customers. Alion's MA&D Operation (www.maad.com) provides expertise in human-systems integration, human-factors engineering, computer simulation and modeling, and custom software development. Our main commercial simulation tool is Micro Saint Sharp, a discrete event network simulation software package for building models that simulate real-life processes. With Micro Saint Sharp models, you can acquire useful information about processes that might be too expensive, dangerous, or time consuming to test in the real world. Any process that can be represented by a flow chart can be modeled using Micro Saint Sharp (see Figure 1). Micro Saint Sharp is designed to be flexible for use in a variety of applications, including manufacturing, health care, air-traffic control, human performance, and military scenarios.

[Click image to view at full size]

Figure 1: Micro Saint Sharp. Network diagram created using the GoDiagram graph-drawing tool from Northwoods Software (www.nwoods.com).

It's common for software products that have been around for more than 20 years to undergo numerous rewrites. Micro Saint Sharp is no exception. It was first developed in DOS and VAX, followed by a Macintosh version. In the early 1990s the product switched to Windows. When I first started working on Micro Saint Sharp in 2001, it was still being compiled on a 16-bit version of Borland C++. Although the product had served its main purpose, it had a few problems (including speed issues) and was starting to look dated in terms of the user interfaces. Because of these concerns, I came up with the idea of rewriting the application using new technologies. In particular, I believed that using third-party components would save hours of development time. In this article, I share the lessons learned in redeveloping and updating this commercial application.

What Went Right

Platform/language choice was the first and most critical decision we had to make. The legacy product used a custom C-like language. Users only had access to integers, floating-point numbers, and arrays, although they often clamored for language features such as strings, return values from functions, and more robust function libraries. We determined that adding to the existing Micro Saint Sharp platform was not the best option because of time constraints and that we would need to implement future language features ourselves. I strongly felt that we should first look at what was available off-the-shelf before investing in creating software entirely on our own.

We considered using several programming languages, including C++, C#, Visual Basic (VB), Python, Perl, JavaScipt, and Java. C++ was dismissed because of the language complexity and a concern of having modelers crash their applications because of the lack of built-in exceptions. VB, Python, and to a lesser extent Perl did not meet our requirements because the syntax would be unfamiliar to our existing customers. I decided against Java primarily because I encountered problems with it in my previous programming experience. These problems were mostly related to memory consumption and performance—important improvements we hoped to gain with this rewrite. We were left with deciding between C# and JavaScript. Both would have been good candidates for our users from a model-coding perspective. In the end we chose C# for two reasons:

n C# was compiled so we expected to get a big performance boost over our old simulation engine. (In fact, we have seen some simulation models run 1000 times faster over the original tool.)

n C# software developers could be resources to the users/modelers that would be transitioning to the new language.

The main downside to using C# was that users could no longer pause their model, make changes to the code, and then resume it—a capability available in the original version.

Much of the software used in our company is Windows based. In addition, I was comfortable using Visual Studio. Consequently, we opted for this route. Microsoft .NET 1.0 had also recently been released and we chose to embrace it creating the new tool in C#. I have been pleased using C# and .NET, mainly because it offers a great blend between the performance of C++ and the development speed of Java.

Language Converter

To import the legacy simulation models, a language translator was required. One option was to use simple parsing to convert the language. For example, I could provide a simple substitution to convert Example 1(a) to the C# in Example 1(b).

(a)

if(x <> y) then
   start(1),
   suspend(2),
   a = a + 1;

(b)

if(x != y)
{
   Model.Start(1);
   Model.Suspend(2);
   a = a + 1;
}

Example 1: Language conversion.

Unfortunately, this system quickly fell apart with the case of Example 2, where x, y, and z are integers. Example 2 could run in the old language (although it was probably a mistake). However, it was not valid C# because you cannot implicitly cast an integer to a Boolean. I decided that I needed to implement a real parser to do the model translation. Since our company was already using Antlr (www.antlr.org), I used it to write a translator between the original C-like language and C#. While the resulting translated code is difficult to understand in some cases, we know it will always compile. Antlr is a great tool, and if I have to do compiler/translation tasks in the future, I would definitely consider it.

if (x < y < z)
{
   a = 2;
}

Example 2: This example worked in the old system, but not the new.

Third-Party Components

Given the timesaving benefits related to using third-party components, we decided early on to purchase a number of .NET components. We had a limited time to work on this rewrite project so it made sense to focus on the simulation engine code that represents the core of Micro Saint Sharp, rather than focus on features such as the menu.

While researching which tools to use, I found that most companies offered very good support. We decided to purchase the GoDiagram graph-drawing tool (see Figure 1) from Northwoods Software (www.nwoods.com). We had numerous questions for them and found that they usually responded quickly; often within only a few hours. They were much cheaper than some of their competitors and were royalty free for deployment. (All of the vendors we chose offered royalty-free licensing.)

We bought a C# editing component and a docking layout control from Actipro Software (www.actiprosoftware.com). If this tool had not existed, we would most likely still be using a text box to define C# code. Now we have several of the text-editing features of a modern IDE to help modelers create their code.

Doing the research for available tools and looking at their relative prices was worth our time. Again, there is no way we could have the full capability of the tools that our vendors are providing if I had done the programming myself. We have also gotten benefit over time from the component updates, giving us many new features that we can pass along to our users with limited work on our part.

Plug-In Architecture

Early on we added code for plug-ins that extend the functionality of Micro Saint Sharp. Initially, we added this capability to include additional developers without having them step on each other's toes in the source-control database. But in the long run, it has been an asset that lets us have standard and premium versions of our application with just one set of binaries. It also has allowed tools to be created and shared with all the users of our tools.

We have developed plug-ins for animation (both 2D and 3D), importing and exporting data from Microsoft Visio, adding a human model to the simulation engine, interacting with Microsoft Excel, and optimization. Additionally, a number of our customers have written their own plug-ins to modify the simulation and add capabilities to their simulation models. The concept of developing plug-ins has also benefited the consulting side of our business. We can develop custom plug-ins that can be easily integrated with Micro Saint Sharp by adding the necessary DLLs to their application folder and launching the application.

Inheritable Forms

A common scenario for our company is a customer wants to have a custom tool based on Micro Saint Sharp. For example, a customer might want a personalized tool that simulates how a hospital operates. There are a number of inputs that might change in such a simulation—the number of doctors and nurses, for instance. In the old version of the software, we had a tedious way to create these custom tools, which often led to developers doing the same steps for each project over and over, increasing the likelihood of errors. In addition, there was no way for bug fixes or enhancements to get added into the custom tools we developed. With the new version, there is a base form that developers can extend to add or subtract functionality from Micro Saint Sharp.

The base form works by letting you make a custom tool by creating a form that extends either the simulation engine or graph-drawing form. They can make extensive changes to the GUI of Micro Saint Sharp or the functionality of the simulation engine.

Thanks to this new form, we save several weeks of developer time for every custom tool project. Now developers can spend more time adding functionality to their applications, which lets us provide better service to our clients.

XmlSerializer

The XmlSerializer class (built into .NET) has been a great time saver for us. The serializer is flexible enough that files created in Micro Saint Sharp 1.0 can still be opened in later versions without any code that customizes the serializer. Additionally, when custom tools extend the document class, they do not need to be concerned about what fields are being added or removed from the parent class. Documents get automatically upgraded as long as we do not change property names.

Other Considerations

Our flow-chart system lets nodes be nested. We had several bugs related to making sure connectors were able to link into and out of node folders. Often fixing one would cause another bug (or more than one). We did not get this area under control until we implemented unit tests. We waited far too long to get those tests created.

Conclusion

We are excited about our new version of Micro Saint Sharp. Investing in the rewrite has given our users more speed, greater power, more flexibility, better visualization, interoperability, and an improved look-and-feel. It has given us new capabilities for our consulting services and increased product sales.

In developing a new, updated version of our commercial simulation tool, we feel that by choosing C# and .NET we were able to take advantage of the extensible framework and gain the benefits of using quality third-party components. And during the process, lessons were learned that will be applied to future development projects.