Changes to the Tool Environment


Two significant changes occurred in our tool environment during the Elaboration phase. We switched our primary development platform ”our Java programming IDE ”from the Forte Community Edition to Rational XDE (and the Eclipse IDE). And, we started to use Groove more extensively. We discuss the reasons behind these changes, and their ramifications , in the next few sections.

Forte to XDE ”Good-bye to the GUI Builder

Rational introduced a new tool, XDE (eXtended Developer Experience), that:

  • Enables easy integration of UML models and code

  • Lets developers forward- or reverse-engineer applications with little effort

  • Keeps code and models synchronized automatically

While Gary and Chris are not advanced modelers, they do appreciate the value of a diagram and thought it would be beneficial to use the XDE diagramming features.

There were other reasons for switching from Forte to XDE. Chris was beginning to use XDE as his development environment at Rational, and he was looking forward to learning more about the environment. Gary had less-than -optimal experiences with Forte and was looking for an IDE with which he was more comfortable. The Forte environment hung on several occasions and also had a significantly " sluggish " feel. However, Chris didn't experience these problems, so perhaps they were due to the configuration of Gary's computer. Since then, Gary has upgraded to a professional version of the operating system and the Forte platform has evolved, giving us reason to believe that he wouldn't experience the same problems today.

A side effect of switching IDEs was the loss of a GUI builder. Forte has a nice tool set for creating user interfaces. With Forte, you construct a user interface by dragging the visual components to windows , defining behavior by modifying component properties, and writing the methods to implement the behavior. Other integrated GUI builders behave similarly.

We were anxious about giving up the Forte GUI builder because it was easy to use. There is a comfort in working in a visual environment without worrying about the underlying mechanisms. It turned out that with Eclipse, we had better control over the final look and behavior of the user interface, as well as an assurance that the resulting code was portable to different development environments.

IDE GUI builders typically generate highly stylized code, with comments that are often cryptic to humans and used by the GUI builder to recreate the code. There are often sections of code that you are forbidden to modify; if you do, the IDE might not be able to recreate the components correctly. If you switch to a different development environment with its own GUI builder, you may not be able to recreate your user interface with the new tools. Some environments also have their own visual components, such as custom layout managers. If you use one of the custom components, you are locked into using that environment or its libraries.

In fact, when we switched from Forte to XDE, we were able to use the Forte GUI code as a starting point. Fortunately, we hadn't gotten very far with GUI design in Forte, and we had made minimal use of Forte's unique features.

You might wonder whether we traded one set of problems for another when we switched environments. We felt that we made a good choice in our switch. Rational XDE is built on the open -source Eclipse environment. This allowed us to use just the Eclipse environment for our code development, other Eclipse plug-ins such as the JUnit plug-in, and the XDE product when we wanted to work with UML diagrams. We decided not to generate code from our diagrams, but to use diagrams for human communication. Therefore we avoided locking ourselves into specific coding conventions imposed by the tool.

The lessons learned: Do not rely on features specific to one development environment, especially its GUI builder. Learn how to develop the user interface from the basic components. Find an environment that lets you develop generic code quickly and reliably. Proceed cautiously if you do use features that are unique to your environment.

New Uses for Groove

Until the Elaboration phase, we used the Groove workspace as a vehicle for sharing documents and informal communication between the team members . During the Elaboration phase, we found new uses for Groove.

Even though Chris and Gary both worked at the Rational Lexington, Massachusetts campus, they were in different buildings , and Gary often traveled or worked from home. They needed a way to record and assign engineering work between them. They created an engineering backlog (a term used in the SCRUM methodology). [10] It is simply a list of tasks we needed to perform to realize the requirements in our software and satisfy Russell, our customer.

[10] See Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle.

They added a tab to Groove that we called "Engineering Backlog." [11] This was a simple discussion tool that comes with all Groove editions. Each engineering task was set up as a separate discussion item. They used a stylized form to identify open items, who was responsible, and when items were implemented in the code. Figure 6.9 shows what the engineering backlog looks like. This approach worked well for our two developers. For a larger system or for more people, we recommend using a more formal work assignment mechanism.

[11] In Groove, you add another tab to a workspace when you add a tool. You can have several copies of the same tool in the workspace, giving each copy a different name .

Figure 6.9. Project engineering backlog

graphics/06fig09.jpg



Software Development for Small Teams. A RUP-Centric Approach
Software Development for Small Teams: A RUP-Centric Approach (The Addison-Wesley Object Technology Series)
ISBN: 0321199502
EAN: 2147483647
Year: 2003
Pages: 112

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net