Most Read This Week
JDJ Industry Interviews
Integrating with Eclipse: Exclusive interview with Lee Nackman VP, Desktop Development Tools & CTO, Rational Software
IBM Announced that the Rational Tool Set Would be Fully Integrated within Eclipse
By: Bill Dudney
Oct. 20, 2004 12:00 AM
In July IBM announced that the Rational tool set would be fully integrated within the Eclipse tool set and would provide an integrated set of tools to support the full life cycle of software development. Recently I was able to interview Lee Nackman, the CTO of the Rational division of IBM.
In the press release IBM announced that the Rational tool set would fully embrace Eclipse. What does "fully embrace" mean?
The next release (due by year's end) will have the ability to address several different roles in the software development process - analysts, architects, developers, and even project managers. The development platform is an integrated tool set that supports each of these roles and allows them to work together toward a common goal. Eclipse becomes the key technology to integrate all the tools for each of these roles and for integrating all the capabilities that are needed across all these roles. For example, requirements affect each of the roles (analyst, architect, designer, developer, and tester), and quality affects the people playing each of these roles as well. The tools need to integrate very tightly to allow these people to work together, and Eclipse is the technology to integrate the tools. For example, we support the various roles with Eclipse's perspective mechanism, which allows users in different roles to have a different view of the tool than users in some other role.
We think it's important for the tools to share internal models rather than export, import, and transform, which has been the traditional integration point behind these tool sets in the past. Consider the Eclipse Modeling Framework (EMF): we use EMF and some of the standard metamodels, like the UML 2.0 model that is also provided by Eclipse, as a means to provide integration across the tool set.
The extensibility features of Eclipse are also very important for us. Our tools are open and have to be extensible both by our customers and our partners and other third parties. Eclipse is central to this whole notion of integration and extensibility.
It sounds like the model that the analyst is working with is the same model that, for example, the tester is working with; they just have a different view into the same information.
Exactly. Let me give you a concrete example. When a developer uses Eclipse to edit some source code, assume a method is added. The class in the UML model is automatically updated to reflect these changes. If instead of editing the code the developer added the method to the UML model, the method would be automatically added to the Java code. In essence the code and the model are basically views into the same information, the same model. This is already being done in our current product set.
What about the architect who does not want to model all the detail? Is he or she able to work in a disconnected mode, where the model is not directly tied to the code?
Yes, but one of the things that we think is very important is for the tools to have the ability to analyze the code and let the architect see the architecture as built, as opposed to merely specifying the architecture. With our tool set the architect can see what is actually built and then compare that with what was designed.
Architects don't necessarily want to see all the detail, however. What support does the tool set provide for a more abstract view of the application?
With our current product set you can reverse engineer an entire J2EE application and see an abstract view of the code. For example, instead of seeing the local interface, home interface, and implementation of an EJB entity, you would see that as a single UML class. You can then create (or view) associations between the entities that are converted to EJB relationships behind the scenes, but as the architect or developer you don't have to see all that detail (or complexity). We do this today in our shipping product and we will deliver more features like this in our next release.
Often an architect is concerned with an even more abstract view of the code. Is it possible to see the implementations patterns like Session Façade, for example, in the model?
Basically yes, but there is no magic here. You can take a big set of code and visualize that. You don't have to see all of it at once either. Various aspects of the application can be represented in different diagrams. The tool will show you the artifacts of your application in UML and allow you to see the relationships that exist. It's up to the developer, designer, and/or architect to discern if a particular pattern is correctly applied.
When you say "not all at once" do you mean that the tool will build multiple diagrams for you?
No, the tool will build a model of your application and the model will be rich in terms of including a lot of detail about the code, relationships, etc., but the tool will not automatically build the interesting diagrams. It's a manual process for the designer to draw the diagrams. The tool makes it simple though. Since the model exists, it's simply a matter of selecting which elements of the model should be shown on which diagram. Making things look nice still requires human intervention.
Back to the integration provided between the analyst and the tester. What supportdoes the tool set provide to allow these two people to work together? For example, a tester might update a test case because a particular condition was incorrect. How does the tool support a change like this getting propagated back into the use case?
This is a two-part answer. The first part takes us all the way back to requirements. With our ReqPro product the analyst can drop a requirement onto the use case model. The tool will automatically create the use case and then connect the use case back to the requirement through a traceability link. Now let's move on to your specific question. In the same way that the requirements and use cases can be tied together with traceability links, there are ways to connect test cases with use cases. In addition you can connect the test cases with the results of running the tests. Then the project manager has insight into the current state of the project at any time. And the analyst and testers have insight into dependencies being changed. Now the integration is not as complete as we'd like it to be, but we are making good progress in this next release.
Moving on to the use of the Eclipse UML 2.0 model. To what extent are you using this model and to what extent is your team involved in providing feedback to Eclipse?
We are using the model and providing feedback to the team. We are continuing to invest very heavily in the combined IBM and Rational teams providing quality feedback to the Eclipse ecosystem.
How would you characterize your use of Eclipse? Has it been an advantage to start with the large base of tools already delivered with Eclipse?
It's working quite well for us. It's more expensive for us to work within the open source model because of the level of communication that's required to make sure that everyone is on board with whatever changes are being proposed and/or made. That expense is repaid because of the ecosystem that is developing around Eclipse. There is a large group of vendors building on top of Eclipse. This group helps to refine and flesh out the extensibility features. There is a huge user group that (1) provides usability feedback on how Eclipse can be improved and (2) if someone knows how to use Eclipse they already know a lot about how to use our tool set.
The excitement for us is not so much in saving engineering costs by using Eclipse but rather the ecosystem that is developing around Eclipse. This ecosystem together with the fact that the technology in Eclipse is so good is what makes building on top of Eclipse so exciting for us. We don't need to build a new Java parsing infrastructure but we also don't have to try to teach our customers how to use the output of that infrastructure nor do we have to invest in educating our partners in how the infrastructure works. It's all a part of Eclipse that is widely adopted and documented. We can concentrate on building additional capabilities on top of Eclipse for our customers.
How does the use of Eclipse fit into your portability picture? Will your tool set be strictly reliant on the Eclipse platform so that they will run anywhere that Eclipse runs?
In the next release there has been a big focus on integrating our products with Eclipse. There are still some clients that will not work on all Eclipse-supported platforms. The idea going forward is to make our tools run on all platforms that are supported by Eclipse, however, there are still the practical issues of being able to test the products on each platform that will prevent us from supporting them on every platform.
On the Model Driven Architecture (MDA) front, where do you see Rational fitting into that market?
There are certainly markets where MDA will be valuable and we think there is opportunity and value in building models and generating code. For example, we've seen our customers generate a lot of value from defining data models and generate code from them. Take an XML Schema. Our customers have been able to achieve value in defi-ning a model and having the tool build the XML Schema and database schema for them. User interfaces is another place where we have found modeling to be valuable. Having our users be able to draw out a user interface in a modeling tool and then have the tool generate all the code behind that UI is extremely valuable. In our current tools, for example, you can fully define your user interface in a visual editor and the tools will generate a JavaServer Faces implementation behind the scenes.
We don't believe in programming with pictures, however; there are things that are best represented in a textural format.
Finally how are you integrated with the Hyades project?
We provide integration with our testing tools so that you can deploy your J2EE application. With the monitoring pieces of Hyades in place you can see what is happening on the server; for example, if you have a search page that is having performance problems. With the Hyades integration the developer is provided with clues that will help nail down where this problem is happening and what needs to be fixed to make the problem go away.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads