Product Reviews

As the software development process becomes ever more complex, end users demand more and more functionality in less and less time. Companies are extending their business applications to run on both intranets and the Internet, and new applications have to run on many different platforms. All this calls for large development teams to design, build and maintain applications.

Often, an entire team of managers, developers and testers have to work together to deliver an end product. Team members share more than responsibility for developing the code; they also share the actual files that contain the code. Thus it's essential to control each team member's access to the code and how code changes affect others. To manage the activities of the team, many application development products provide source code management tools and team programming environments in which the roles of individual developers are clearly defined and enforced.

IBM VisualAge for Java, Enterprise Edition, is a good example of an application development product that provides a collaborative team development environment. This article examines the concepts of the source repository, program element ownership and team roles in VisualAge for Java. It also walks you through a scenario that helps you understand how team development works.

Repository
VisualAge for Java, Enterprise Edition, has a collaborative team development environment based on a shared repository. The repository is a source control mechanism that allows you to track changes made to program elements. When you start the IDE, it connects to a shared repository on a server. As team members create and modify program elements in their individual workspaces, their changes are automatically saved in the shared repository. (The workspace is a storage area on your client machine; it contains the Java code that you are currently developing and the class libraries on which your code depends.) When you remove program elements from your workspace, they remain in the repository so you can undo changes by retrieving previous editions. The repository contains all editions of all program elements.

The Repository Explorer window provides a visual interface to your repository (see Figure 1).

Within the Repository Explorer you can open or compare program elements that are stored in the repository. Programmers select the editions they want to add to their workspace, and then work with those program elements in another window called the Workbench.

Ownership
In the team development environment, source control management is based on program element ownership. VisualAge for Java shows code to you as a hierarchy of program elements (see Table 1).

A project is an organizational construct that groups packages together. In VisualAge for Java every program element - projects, packages and classes - has an "owner" who is responsible for its stability and coherence.

Team members have certain privileges based on their team role. These privileges help the team manage their code development by ensuring that developers don't overwrite each other's code and that they're working from the same code baseline.

A class can be "owned" by only one developer, but several developers can work concurrently on the same class, in separate open editions. Each developer can version only their own edition of the class, and create a new open edition of it.

The owner of a class is the only developer with the authority to compare various editions of the class and merge them to create a single new version. And only the class owner can release the new version of the class into its containing package. Releasing indicates to other team members that this is a good baseline to work from; they can pick up the latest changes by reloading the whole package (or project) into their workspaces. A project or package can be versioned or reopened only by its owner.

Open Editions
Open editions are works in progress. Before you can make changes to an existing project, package or class, its owner must create an open edition of it. Only one open edition of a program element is permitted in your workspace at any one time. In the repository, however, you can have multiple open editions of the same program element, with each one implemented differently. For example, if you're adding features to an application that you've customized for different industries, you might have multiple open editions of a package with the same name stored in the repository.

Versioned Editions
Versioned editions can't be changed. You may version your open editions for any of the following reasons:

• To keep a copy of a program element at some significant development point so you can return to it at a later date. In the case of packages and projects, versioning freezes a specific configuration of the contained classes.
• To make your changed classes available to other team members browsing the repository. Only versioned editions are visible to other team members.
• To release a class into its containing package in order to update the team baseline. Only versioned editions can be released.

After you've versioned a program element, you can open a new edition if you want to make more changes. You can restore the open edition of a program element in your workspace to a versioned edition of it at any time.

Team Roles
There are four main development roles and one administrative role in VisualAge for Java. In a development team that consists of a manager, a team leader, a senior developer and junior developers, the roles are often distributed as shown in Table 2. What follows is a brief explanation of each role.

Repository Administrator
The repository administrator is responsible for the creation, installation and maintenance of shared repositories on a server, and for controlling access to these repositories. The administrator creates the shared repositories, prepares a list of the repository users and enables password validation. User lists and password validation ensure that only the appropriate team members can access the code in the repository.

Project Owner
A project owner is responsible for the overall quality of a project. A project owner coordinates the activities of the package owners who release their packages into the project owner's project.

Only the owner of a project can perform the following tasks:

• Create an open edition of the project so that package owners can update the team baseline by releasing their packages.
• Add packages to the project and delete packages from the project.
• Version the project to preserve a team baseline.

If the project owner doesn't create an open edition of the project, package owners can't release their packages into the project. This gives the project owner complete control over when a project is frozen and when it's reopened for further development.

Package Owner
As you might guess, a package owner is responsible for the overall quality of a package. The owner of a package coordinates the activities of the class owners who are releasing their versioned classes into that package.

The creator of a package is, by default, the owner of that package. Each edition of a package has a group of developers who are assigned to work with classes in that package. These developers are the package group for that edition. Only package group members can own, create and change classes in the package.

Only the owner of a package can perform the following tasks:

• Add members to the package group and delete members from the group.
• Create an open edition of the package so that class owners can update the team baseline by releasing or deleting classes.
• Version the package to preserve a team baseline.

Package owners control when a package is frozen and when it's opened for further development. Both the project owner and the package owner can release the package into, or delete it from, its containing project edition.

Class Owner
A class owner is responsible for the integrity of a particular class and its methods. Only the owner of a class can update the team baseline, in the following ways:

• Release editions of the class into the containing package.
• Delete editions of the class from the containing package.

Often the owner and developer of the class are the same person. If two or more developers are working on the same class, the class owner is responsible for comparing and merging everyone's changes into a single edition of the class. The class owner then versions the merged edition and releases it.

Class Developer
Any team member can create new classes and open editions of existing classes, thereby becoming the developer of that open edition of the class.

Only the developer of a particular class edition can version that edition, and only the class owner can release the version. The class developer and the class owner are usually the same person, but there may be more than one developer working on the same class.

A Team Programming Scenario
The following simple scenario shows how a small development team would use VisualAge for Java to create a new business application for Xyz Corporation. In the scenario the team works together to develop some sample program elements for the application. There are five developers in the following roles (see Figure 2 for who reports to whom).

In a team development environment, there are two main steps in project development:

1. Setting up the project
2. Concurrent development

When the project is set up, ownership of the project elements is assigned to the team members.

Step 1: Setting up the project

1. Caitlin creates a new project, Xyzcorp, and a new package within that project, com.ibm.xyz. Open editions of these program elements reside in both Caitlin's workspace and the shared repository.
2. Caitlin adds Daniel, Frank, Oscar and Chris as package group members. She makes Daniel the owner of the com.ibm.xyz package. They can all now work with classes in the com.ibm.xyz package.
3. The team members add the package to their workspaces. They now all work with the same open project and package editions.

Now that the project is set up and ownership is assigned, the developers can begin working concurrently on the code.

Step 2: Concurrent development

1. Frank creates a new class, Xyzgrid, and Oscar and Chris load it into their workspaces.
2. Oscar adds a new method to the class, XyzGetCol. He versions the class, so it's available to the other team members. He then creates an open edition of the class and starts working on another method, XyzGetRow. His new changes won't be available to the rest of the team until he versions his class again.
3. Chris adds a new method to the class, XyzLayout. He versions the class, so it's available to the other team members.
4. Frank takes the versioned classes that Chris and Oscar own and merges their changes. He then versions the new edition of Xyzgrid and releases it.
5. Daniel releases the com.ibm.xyz package and Caitlin versions the Xyzcorp project.

After Caitlin has versioned the project, the development cycle can begin again. New editions of the Xyzcorp project and the com.ibm.xyz package can be opened, and the team members can reload these new editions into their workspaces and start enhancing the code again.

Conclusion
As an application grows and becomes more complex, its development team also grows and becomes more complex. Managing and integrating source code are key to successful project development. The team development environment in VisualAge for Java provides change control and stability without sacrificing flexibility or programmer productivity. Emphasis is on roles and responsibilities rather than on file locking. This approach is especially well suited to the iterative, collaborative, object-oriented development that tends to characterize most successful large e-business applications.