The way you develop applications has changed greatly since the days when data was stored on punched cardsand 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.
Dont 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 Im most familiar is IBMs VisualAge for Java (VAJ). If I remove the other Java IDEs (INPRISEs JBuilder and Symantecs 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, its 62 MB in size even though Im not working on any industrial-strength development efforts.
The cool thing about VAJs 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 IBMs VisualAge product lines (VAJ, RPG, SmallTalk, and COBOL) implement source control using a facility called Team Developer. VAJs Team Developer provides source control and versioning coupled tightly with the VAJ IDE.
If youre working on a project by yourself, VAJs repository has some surprisingly powerful facilities. Figure 1 shows you that my ivj.dat repository file contains many projects. Some of those projects arent even mine; some are IBMs, and some are Suns. My repository includes those projects because I use IBMs, Suns, 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 VAJs repository.
Moreover, VAJs 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 VAJs 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, its 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. Thats 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 VAJs 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 IBMs VAJ repository.
IB Ms 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 .
LATEST COMMENTS
MC Press Online