The way you develop applications has changed greatly since the days when data was stored on punched cards—and the process continues to change. Learn how repository- based application development can help you manage component-based programming.

Lan guag e wa rs a side , th e tr end in a ppli cati ons prog ramm ing is t o mo ve t owar d co mpon ent- base d pr ogra mmin g.

And because of the improvements in productivity of PC-based integrated development environments (IDEs), source files containing applications are now being dispersed across the machines of various members of project teams. Another problem is that the new iterative and incremental development strategies for application refinement result in more software versions that then need to be maintained and supported.

So whether your applications programming language is Visual Basic, C++, Java, or RPG, the fact is that, where you once dealt with a dozen or so source files per project, you must now deal with hundreds, or even thousands, of source files. Compound those numbers by the number of programmers, platforms, and managers on your team, and you have a problem.

Most IDE products alleviate these source and version control problems by bundling a source control package. Many AS/400 programmers have been exposed to some form of source control, with its check-out and check-in of source files, and are comfortable with source control as a solution. However, while these source control packages do control multitudes of source files, the sheer volume of files ultimately complicates software engineering. Consider, for instance, the effect of modifying the interface on a component. What applications use that component? How many other components might be affected by the modification?

The Need for Repositories

A new strategy for storing application source and object code has evolved to provide a different kind of solution to the problems of source control: repository-based file management systems. A repository is a single file that stores the entire source for all your

projects. In addition, the repository stores not only your source but also different versions of your source and can even store the object code for your applications.

Don’t go out and buy a repository just yet. Instead, buy an IDE product that uses repository technology for storing application source. The repository-based development environment with which I’m most familiar is IBM’s VisualAge for Java (VAJ). If I remove the other Java IDEs (INPRISE’s JBuilder and Symantec’s Visual Café) from my system as well as all associated projects, source files, and object code, I would be left with one file that contains hundreds of my Java classes, thousands of third-party Java classes, and a dozen or so projects. That one file is ivj.dat, and, on my system, it’s 62 MB in size even though I’m not working on any industrial-strength development efforts.

The cool thing about VAJ’s repository is that you can place it on your AS/400, enabling all the members of your VisualAge development team to work from that same repository. All of IBM’s VisualAge product lines (VAJ, RPG, SmallTalk, and COBOL) implement source control using a facility called Team Developer. VAJ’s Team Developer provides source control and versioning coupled tightly with the VAJ IDE.

If you’re working on a project by yourself, VAJ’s repository has some surprisingly powerful facilities. Figure 1 shows you that my ivj.dat repository file contains many projects. Some of those projects aren’t even mine; some are IBM’s, and some are Sun’s. My repository includes those projects because I use IBM’s, Sun’s, and even some third-party Java classes to develop my own Java classes and applications. Integration of these various projects makes it easy for me to reuse both existing classes developed by other people on my team (me, myself, and I, but you get the point) and classes developed by other companies.

When you modify the interface of one class, the All Problems panel displays all other classes adversely affected by that change (see Figure 2). This is another powerful feature of VAJ’s repository.

Moreover, VAJ’s repository automatically keeps versions, or editions (as IBM calls them), of your source. Figure 3 shows the Repository Explorer panel from which you can browse editions of Java projects and the packages within those projects.

The Downside

Is there a negative side to VAJ’s repositories? There are a few. First, because all the source is contained in a single file and VAJ is so highly integrated with so many features, the startup time for the VAJ IDE is slow. Second, it’s difficult to get your “hands” on your Java source files; unlike my JBuilder and Visual Café projects, the Java source files of my VAJ projects are not available anywhere as text files. That’s not too much of a problem, however, because I can “import” individual classes or complete Java packages from .java source files to my ivj.dat repository and “export” individual classes or complete Java packages from the repository to .java, .class, .jar, and other VAJ repositories.

The biggest problem I have with VAJ’s repositories is their integration with object- oriented (OO) design tools. Products such as the Unified Modeling Language (UML)- compliant GDPro from Advanced Software Technologies and T og et he r/ J fr om Object International provide round-trip engineering of Java applications. Still, the round-trip engineering of these and other UML tools requires the use of standard .java source files, not IBM’s VAJ repository.

IB M’s repo sito ry-b ase VAJ is a n ex cell ent deve lopm ent envi ronm ent for grou p de velo pmen t of Jav a ap plic atio ns. Real ize, how ever , th at V AJ r equi res beef ier ma chin es t han do m ost othe r to p-se llin g Ja va I DEs. You wil l ha ve p robl ems usin g UM L de sign too ls w ith VAJ, but IBM has pro mise d to imp rove fac ilit ies for the in tegr atio n of UML too ls w ith VAJ’ s re posi tory .

Figure 1: VAJ’s Workbench window shows all the projects that reside in the repository.

Figure 2: The All Problems panel reflects the far-reaching effect of modifying the interface of a class.