Recommendations of the Software Tools Working Group
Code Development Environment
DØ Note #2936

Pushpa Bhat, Krzysztof Genser, Herb Greenlee, John Hobbs, Alan Jonchkeere,
Stan Krzywdzinski, Lee Lueking, Qizhong Li-Demarteau, Laura Paterno,
Harrison Prosper, Serban Protopopescu

The Software tools group believed that the compiler/debugger topic that we were supposed to resolve did not cover the full scope of the tools necessary for writing software. Therefore, we have changed the topic of compiler/debuggers to the broader term of code development environment to include design tools and integrated code development systems.

PRINCIPLES

The Software Tools Committee feels that the following principles should be adhered to when choosing the code development environment that we recommend for use by the DØ Collaboration in Run II and beyond:

• We will support multiple platforms. Since the best compilers on each platform are by and large written to take advantage of that platform's strengths we cannot dictate a single "generic" and therefore transportable compiler.
• On the other hand, not everyone will be able to afford to purchase the best possible compilers for their particular platform(s). Therefore at least one "generic" and cheap compiler must be allowed.
• We must realize that the choice of particular "best" compilers will change with time, perhaps not as fast as the "best" platforms change, but they will change.
• Because we will support multiple platforms, the code we write must compile and run on all of the supported platforms. This is also true of any third party libraries we use.
• The code management system as described in the recommendations of the Software Tools Working Group for a Code Management System (DØ Note#XXXX) will make it trivial to release code to multiple platforms. The tools necessary to achieve this should also be available to code developers to enable them to test whether their code is platform independent prior to insertion in the code repository. Any other tools such as standards checking, etc. should also be readily available to code developers.

The following sections will list what we feel should be the minimum requirements for each part of the code development system. As technology changes these recommendations may be changed to reflect the new advances if they are deemed necessary.

DESIGN TOOLS

In accordance with the recommendations from the Languages and Data Structures (DØ Note #2819) we recommend the following be the minimum requirements for design tools used for coding either in C++ or FORTRAN. We further recommend that a limited set of licenses be purchased for these tools. (A list of examples of what is currently available appears in an appendix at the end of this document).

• allow for reverse engineering (taking code from the language and creating diagrams from the code)
• it should automatically generate the appropriate language specific code fragments from the diagrams created
• it supports the chosen design methodology for the language

EDITORS

This is the central piece of the DØ code development environment. Any tools that we use should be able to run from the editor. Therefore, it should provide all of the functionality as stated in the Software Tools group recommendation on editors. (DØ Note #2853).

COMPILER RECOMMENDATIONS

Adhering to these principles implies that we cannot recommend particular compilers as "DØ Standard" compilers. They imply, rather, that we need a set of coding standards that will be accepted by all allowed compilers. We also need the tools necessary to enforce these coding standards. Depending on the standards, it would be very worthwhile if the compilers could do the enforcement. (A list of currently available compilers appears in an Appendix at the end of this document).

Therefore, we make the following recommendations:

• all code must adhere to the DØ coding standards. (DØ Note #XXXX)
• it must support at minimum the language requirements as specified by DØ
• there must be a preprocessor to handle any DØ extensions and if necessary any platform specific differences. (This would allow us to replace DØFLAVOR with a generic platform-independent code preprocessor,such as CPP or KPP, for all FORTRAN code)
• all code must compile under all of the supported compilers.
• a list of supported compilers must be maintained and a contact person must be associated with each compiler to help with any problems. The contact person should maintain a WEB Page of frequently asked questions regarding the compiler.

DEBUGGER RECOMMENDATIONS

We realize that most people will use the debugger that comes with whatever system they are running on. However, we still feel that there are some requirements that the debuggers will have to meet. We list them below.

• any debugger that works with the allowed compiler is acceptable.
• a full-featured symbolic debugger must be provided for each supported development platform.
• for C++ a class/object browser integrated with the debugger is essential.

OTHER TOOLS

We also see that the need for a suite of tools to aide in code development. Below are a few that we feel will surely be necessary. This list will obviously grow with time.

• library browser.
• procedure to allow code to be compiled on another platform than the one it is currently being developed on.
• automated code standards checking.
• automated documentation aid/CASE tool.
• script to determine the compiler type and version installed.

APPENDIX A - CURRENT DESIGN TOOLS AVAILABLE

Currently the following design tools are available for C++:

• Rational Rose/C++ by the Rational Software Corporation - generates C++ code (can customize the code), reverse engineers C++ (can customize this too), keeps track of previous designs and implementations, some automatic documentation generation (there is a separate product called SoDA also by Rational that provides a more robust documentation solution) and supports parallel development. It supports both the Booch '93 methodology and the Rumbaugh OMT (Object Modelling Techniques) methodology. Supported platforms include Windows 3.1, 95 & NT, SunOS or Solaris on Sun SPARC, AIX on IBM RS/6000, HP-UX on HP PA-RISC. (URL: http://www.rational.com/)
• Paradigm Plus by Clear Lake Lab (formerly Protosoft, Inc) - CASE tool that does a lot more than just generate code, reverse engineer code and create class diagrams. It also does code documentation at a variety of levels, integrates with a variety of code testing tools like Purify (checks for memory leaks), GUI builders (Powerbuilder & Forte only), debugging tools (Codecenter, Objectcenter, C++ Developer), configuration management tools (PVCS, ClearCase) and generates database schemas to give access to a variety of commercial databases (both OO and relational). Currently it supports Windows 3.1 & NT, SGIs Irix 5.x, DEC Alpha OSF/1, IBM AIX 3.2.x, SunOS 4.1.x, Sun Solaris 2.x, AT&T NCR 3000 & HP HP-UX 9.01. (URL: http://protosoft.com/home/home.html)

Currently the following design tools are available for Fortran 90:

• FLINT - there is a beta release from a company called IPT of this product. It can analyze and document source code and detect problems which are beyond the scope of the compiler (common block inconsistencies, etc). It can also be linked into Cadre Technologies' Ensemble package to provide a complete reverse engineering toolset for Fortran. (URL: http://www.iptweb.com/)

APPENDIX B - CURRENT COMPILERS AVAILABLE

The following compilers are available which support the minimum C++ language standards for DØ coding requirements:

• GNU C++ V 2.7.2
• Borland C++ V 5.0
• Microsoft Visual C++ V4.0

At this time the only Fortran 90 compiler we have at DØ is

• Microsoft Fortran Powerstation

As yet no coding requirements have been specified for Fortran 90 save that it must compile all of our existing Fortran 77 code. Certainly major changes to a large portion of the DØ would have to be done before it would compile in MS Fortran Powerstation.