Kenton Lee

X Application Software Engineering: The Benefits of Modular X Software

by Kenton Lee

Published in The X Journal, September, 1994.
Copyright © 1994 Kenton Lee. All rights reserved.

Key words: X Window System, X11, Motif widgets, software engineering, programming.


Software modularity is an important concept in all modern software engineering methodologies. This paper discusses several ways to use software modularity when developing X-based application programs.


  1. Introduction
  2. Analysis and Design
  3. Prototyping
  4. Unit Testing
  5. Debugging
  6. Conclusion
  7. The Author


A software module is a portion of an application program that can be designed, developed, and tested relatively independently of the rest of the program. It should have well-defined functionality and interfaces.

Because the concept of software modularity is very powerful, virtually all modern software engineering methodologies and text books strongly advocate it. Most X programmers use the concept to a certain extent, but, unfortunately, many do not fully take advantage of it.

In this issue's X Application Software Engineering column, I will examine the benefits of software modularity in these phases of software engineering:

Analysis and Design

The first two phases of a software development project are the analysis and design phases. In these phases, you turn the application's functional requirements into a detailed design. This design should map easily into the actual code.

While different software engineering methodologies propose different analysis and design techniques, almost all generate modular designs. Each module in the design should have well-defined functionality and interfaces. Modules are often hierarchical, with higher level modules being each composed of several lower level modules.

For X-based programs, the user interface as a whole is often a module; with well defined programming interfaces to the rest of the program. The user interface itself is often composed of many smaller sub- modules, such as modules for menu systems, for graphical windows, for control panels, etc.

Modular designs are generally much easier to code and produce better quality results than non-modular designs. Most software developers take modularity at least this far.


For many software developers, the modular design is only the first benefit of modularity. A second benefit is modular prototyping.

Prototyping is an independent stage of software development that lies between design and coding. Sometimes prototyping is used to "flesh out" a design. You may want to demonstrate that a complex algorithm can be implemented. You may want to study several possible algorithms to see which offers the best performance or best robustness. You may want to mock-up several different user interfaces to see which is the most usable.

Prototyping can also be used to enhance the development process. In a prototype, a difficult-to-implement algorithm can be efficiently im- plemented, as well as tested and optimized.

When possible, you should keep your prototypes small to more efficiently study the problem at hand. Keeping the prototype small is usually beneficial, as small programs are more quickly coded than larger ones. Small programs also compile more quickly, and you will probably need more than a few passes through the compiler before it is done.

As mentioned above, user interface prototypes are very valuable for X- based application programs. The prototype allows you to test usability, as well as various X programming techniques.

Several X-based user interface builders are now on the market. These can be beneficial in the prototyping stage, as they often allow user interfaces to be rapidly composed and modified. I will discuss these tools in greater detail in a future column.

Unit Testing

Another benefit of modularity is in testing. Since your modules should have well-defined interfaces, you can often test the modules independently by testing the interfaces.

Many modules can be tested alone. Others will need to be linked with small driver or stub procedures that simulate the behavior and interfaces of related application modules.

If your modules were prototyped, as discussed in the previous section, the prototype environment can easily be used as a unit test

Unit tests will greatly improve the quality of your program. They also accelerate the development of your program, since unit testing allows individual modules to be tested before the entire program is complete.

Unit tests are especially valuable when several programmers are independently developing modules for a program. If each programmer can develop unit tests for their own modules, integrating the programmers' work later is greatly simplified.

Unit tests are also valuable after the integration takes place. At that phase in the development, adding buggy code will probably negatively affect several programmers. Thoroughly testing new features and bug fixes to modules helps to maintain the quality of the overall application program.

In the X world, unit testing is very useful for testing interoperability and portability. Individual modules can be tested on different platforms or against a variety of X servers and window managers.

While unit testing can never replace system level testing, it always helps. Finding and fixing bugs early in the development of a product always greatly improves product quality.


In the previous section, we discussed unit testing of software modules. Obviously, any problems you find in these tests are most easily fixed by debugging in the particular unit test environment, rather than in the complete application environment.

Debugging at a module level can also be very beneficial when bugs are discovered during application level testing. Since you'll probably have created a large collection of unit tests and prototypes of your modules, you can often isolate and fix the problem more quickly by trying to reproduce the problem in the unit tests and prototypes. If the problem also appears there, debugging at that level is probably your most efficient route.

Even if an application-level problem does not appear in previously developed unit tests, the most efficient way to debug the problem is often to create a small module-level unit test that reproduces the problem.

People often ask me to help them debug huge X-based programs. I ask them if they have tried to create a small test program that to reproduce the problem and all too often they say "no". I always recommend that they start with that first step. If they had followed the modularity techniques discussed above, that first step might be very easy.

In general, debugging in a small, limited environment is always simpler, and usually much simpler, than debugging in a large, complex environment. You should always look for easy ways to move to a small debugging environments.


In this issue's column, I have discussed four ways that modularity can help you design, code, and debug your X-based application programs.

You are probably already creating modular designs. Going a little further to prototype some of these designs could help make your designs and code more robust. Module-based unit testing could help find bugs earlier in your development cycle, saving time and enhancing quality. Finally, module-based debugging could help speed up your debugging chores.

All major software engineering methodologies advocate these techniques, or similar. You've probably heard of them. Give them a try.


Kenton Lee is an independent software consultant specializing in X Window System and OSF/Motif software development. He has been developing UNIX graphical user interface software since 1981.

Ken has published over two dozen technical papers on the X Window System. Most are available over the World Wide Web at

Ken may be reached by Internet electronic mail to kenton @ or the World Wide Web at

[HOME] For more information on the X Window System, please visit my home page..

Please send me your comments on this paper:

Name: E-mail:

[X Consulting] [Home] [Mail] [X Papers] [X WWW Sites]