A Borland Paper
By Ian Buchanan
March 2005
Although many people think of Eclipse as only a free Java IDE, it is much more. Considering the state of development
tools today, there is a strong need for tighter integration with other aspects of development than just
"edit-compile-debug." This paper provides an overview of the Eclipse IDE, the need for a tools platform, and
how the Borland notion of "synergistic integration" is being realized on the Eclipse platform. Using
Borland's Software Development Platform on Eclipse, developers can work more effectively within a software
development team.
If you work in software development, you've probably heard the buzz around Eclipse. Perhaps you are already using
Eclipse in some form. What you might not know is that Borland offers a suite of complementary solutions (plug-ins) for
the Eclipse environment that add rich capabilities for requirements management, design, performance and testing, and
configuration management.
Although many people know that Borland has provided first-rate developer tools for more than 20 years, many software
developers have been pleasantly surprised to find that Borland provides a complete set of tools for Application Lifecycle
Management (ALM). Furthermore, by offering solutions for Eclipse, Borland is proving its commitment to platform
independence and modular solutions.
More and more organizations who develop custom software are finding themselves in a position to ask whether it's
worth it. Many software development groups are unable to deliver complex software projects on time, on budget, and with
reasonable quality. The risks of failure grow with the size and complexity, making it difficult to accurately forecast
and set expectations with executive management. The inability to consistently meet business expectations, quality
benchmarks, compliance mandates and process maturity levels is forcing organizations to turn to new ways of meeting
business needs.
Some organizations have given up custom software development in favor of customization of off-the-shelf software. Other
organizations are looking to outsourcing and off-shoring as a way to bring accountability and affordability to software
development. Yet other organizations have discovered agile methodologies such as XP, FDD, and Scrum. These options are
attempts to solve the same needs of the business; namely, to minimizing risk by providing greater control and visibility.
Borland's ALM products provide tooling for all of these options precisely because they share this need. By enabling a
managed business process for the entire software development and delivery cycle, Borland helps customers address the
constraints of modern day software development that limit the efficiency of their efforts, and thus drive more value back
to the business.
This is Borland's vision of Software Delivery Optimization (SDO). By providing a Software Delivery Platform (SDP),
Borland helps software teams with the following:
- Deliver quality software on time, on budget, and within scope with flexible, automated, and customized workflows.
- Streamline cross-role information flow for better team collaboration and visibility to management with integrated,
real-time project reports that reflect business metrics.
- Automate routine tasks and create custom processes to maximize individual and team productivity and increase
efficiencies throughout the software development process.
- Reduce risk with a predictable development process that delivers repeatable success.
Given Borland's long history of providing IDEs and tools for software developers, the choice to support Eclipse might
come as a surprise. However, leveraging Eclipse broadens support for many types of development projects and organizations
where Borland has not been cover. Eclipse does not comprimise the Borland value of "no lock-in" - Eclipse is a
standards-based environment that provides common tooling supporting large, distributed development teams. Eclipse also
provides an extensible, open platform allowing developers to leverage third-party plug-ins or create their own customized
enhancements for capabilities not provided by Borland. In short, Eclipse is a natural choice for a veteran software
development vendor such as Borland.
Skip McGaughey, chairperson of the Eclipse board of directors, said this about Borland's Eclipse plug-ins, "It
is exciting to have Borland leverage its years of experience of building products for developers and provide this
technology to Eclipse developers." To be more speciric, Borland's SDP on Eclipse provides perspectives specific
to the tasks of analysts, architects, developers and testers, which helps maximize the individual contribution of each
specialized IT role. The Core SDP provides the following capabilities:
- Requirements management: manage requirements from definition thru to implementation.
- Asset management: central repository to manage all assets.
- Change management: manage and track each change request thru to resolution.
- Task management: create, manage and track tasks.
- Software configuration management: build and release management processes.
- Ease of use: high-performance and scalable platform; low impact adoption and training costs.
- Ease of administration: fewer administrators and server resources to configure and run.
- Integrated lifecycle: common tasks and activities for each role are tightly integrated using best-in-class Borland
tools.
Borland's SDP on Eclipse enables development teams to be more agile and responsive with centralized access to
requirements and automatic real-time notification of approved changes. Teams can automate routine tasks, such as
documentation generation, and promote reuse and sharing with ready access to a common repository of all software assets.
Overall, Borland's SDP ensures greater consistency in software quality and reliability by standardizing on a single
development environment that meets the needs of an entire development team.
While Eclipse has grown in popularity in the Java development community, it is more than a framework for Java IDEs.
Technically, the Java Development Tooling (JDT) plug-in provides Java development capabilities on top of a flexible
framework known as the Eclipse Platform. This platform provides capabilities such as basic UI components found in
software development, a help system, and team repository support. In this way, Eclipse is a universal, open-source tool
platform that can be used for multiple languages and development paradigms. In fact, the managing consortium of vendors,
such as Borland, represents a great many platforms and languages beyond Java. This notion of Eclipse as a platform is not
just important for vendors to write more tools, it is also important to the enterprise developer who must work with many
different languages such as HTML, C/C++, COBOL, PHP, Perl, XML, etc. Today's heterogeneous computing environments can
benefit from an IDE that supports multiple languages.
Moreover, modern software development takes more than just "edit-compile-debug." Requirements are needed to
drive the design and testing phases of the application lifecycle and ensure successful deployment. Few applications are
purely "green field" projects without any dependencies on other systems. Effective architecture and design is
critical to ensure that applications integrate and meet requirements. Although requirements and design contribute to
better-quality software, other techniques are used to assure quality. For Java development, unit testing, refactoring,
audit/metrics, and profiling have become industry standard practices for ensuring high quality. Of course, configuration
management plays an important role in quality as well. Without a system for managing the digital assets of a software
project, it is nearly impossible to balance rapid development with a manageable process. With tools to manage all of
these aspects, a developer's world can easily be full of jarring interruptions and duplicated effort. Fortunately,
Borland products are both innovative and integrated, bringing best-in-class tools together as a modular solution.
As a developer, it is easy to dismiss requirements management as something done upstream by someone else. Even if
requirements are written by someone else, ineffective requirements management can easily become a burden for developers.
As an illustration, the following is a well-written requirement:
Requirement 3.2.2.1.5
The system shall be able to identify allocated COTS licenses that will expire within 60 and 120 days. The system shall
provide the capability to generate an Expiring License Summary Report that will include a list of the COTS licenses, or
associated maintenance agreements, by project/user organization, that will expire in the selected timeframe (either
<=60 days, or <=120 days). The list will include the product version/revision, vendor, platform, license
expiration date, maintenance agreement expiration date and Point-of-Contact information (name, phone, organization,
address, etc.)
Although it clearly and unambiguously explains what a developer needs to implement, there is a lot of context missing. To
get the additional context, the developer now needs to go back to the upstream role to ask the following kinds of
questions:
- Who owns or is responsible for this requirement? Who created it?
- What is the current status and priority of this requirement?
- Is this the most current version of the requirement? Has this requirement changed since I last looked at it?
- What relationships does this requirement have to other requirements? To other development deliverables? What is the
current status of these relationships?
Borland® CaliberRM is a powerful solution for managing requirements for software projects. Using CaliberRM,
developers can view the list of requirements, assigned to them within Eclipse, which help them to correctly implement the
requirements without communication gaps. Answering these questions takes more than just a well-written document; it takes
a well-defined requirements process that forces business users to provide the correct requirements from the beginning in
order to minimize the amount of project rework.
Borland CaliberRM manages each requirement as an individual object. Each requirement is well defined with its own status
and priority attributes, version history, and discussion threads. CaliberRM helps a team work collaboratively on
requirements, even in a distributed environment. These requirements can be tied to individual developers who in turn
implement them without a communication gap. CaliberRM facilitates communication among project teams, helps to reduce
errors, and improves project quality. Designed to promote better understanding and control of projects, CaliberRM is a
pivotal definition and design component of the Borland suite of application lifecycle management technologies. With
CaliberRM, a developer can answer all of the previous questions from within the Eclipse environment.
Figure 1: A view of requirements stored in CaliberRM from within Eclipse
While capturing up-front requirements as simple text is appropriate when dealing with primary stakeholders, this often
leads to a problem of organizing and understanding a large number of requirements. In order to assemble a complete
application, developers must understand the big picture. As visual creatures, we are able to comprehend more information
faster when it is presented visually. Industry-standard techniques such as use-case modeling help structure requirements
analysis, put the requirements into context, and ensure that all the important questions get asked. The Unified Modeling
Language (UML®) was created for just this kind of purpose-providing many perspectives of a business and/or
software system in one cohesive model.
Although UML has been around since 1996, many people still suffer from a lack of standardization, homegrown design
templates, and nonstandard notation. This increases the challenge of effective collaboration and communication among
those with different roles on the development team. Leveraging UML as the industry standard for visual modeling ensures
that all roles can communicate using UML as the common language. Because UML is commonly taught in universities and used
throughout the software development industry, new additions to a team likely already know UML and can become productive
sooner.
The core problem with the adoption of UML is typically the tooling-UML tools are difficult to learn and use. But Borland®
Together® technologies are among the most intuitive, easy-to-use modeling tools available. With extensive samples and
built-in helpers to aid those new to modeling, UML becomes accessible to everyone. Moreover, Together offers a flexible
modeling environment that is not tied to a particular process.
Another disconnect from real software development is the nonexistent or poor integration between requirements and design
tools. The transition from text documents into UML is frequently a source of rework as the same textual information is
re-entered into a model. Once the information has been recreated, tracking the linkages between changing text
requirements and changing models can be difficult. Borland Together and CaliberRM help eliminate such hassles.
A right-click on a requirement is all it takes to create new diagram elements from existing information. As model
elements are created, they can be traced to the appropriate requirements-making understanding the impact of a
requirements change on the UML model much easier.
Figure 2: Tracing requirements to UML elements
One of the advantages of using UML in analysis is the ease with which analysis information can be incorporated into
architecture and design. For example, an analysis of the business domain as a class diagram can become the starting point
for design. Within Together, hyperlinks between analysis models and design models provide an easy mechanism for
representing traceability and providing navigability through the models.
One the biggest advantages Borland Together has over other UML modeling solutions is the LiveSource capability that
keeps models synchronized with source code. During design, this means the architecture is already being implemented in
Java. Extensive support for Gang of Four1 and J2EE design
patterns2 help create more working code faster. Because
Eclipse does incremental builds of the Java code, one can understand any potential compilation errors immediately. Not
only is the design already validated against the compiler, but also, Borland Together provides audits and metrics to help
ensure quality of design. Together audits provide static analysis of source code that checks for compliance with common
coding guidelines such as Sun's Code Conventions for Java.3 Together metrics provide similar static analysis to quantitatively understand aspects of object-oriented
design such as coupling, cohesion, and complexity.
Figure 3: Model and code synchronized with LiveSource
Another challenge addressed by LiveSource is the difficulty in keeping design documents current with changes to source
code. Because LiveSource keeps the diagrams synchronized with source code, the challenge of creating up-to-date design
documents is reduced to clicking the menu option to generate project documentation. Because there is no manual
synchronization step, the documentation always reflects the latest "as is" picture of the system. Changes made
to the code by a developer can be seen by the architect in the application model; changes made to the model can be
immediately viewed in code. In this way, development stays synchronized with design. Up-to-date design is critical for
scalability, reuse, and maintenance.
Many other vendors claim to synchronize source with class diagrams; however, LiveSource is a robust and mature technology
that makes Together perform far better than most. Even so, class diagrams are only a structural view of the software. To
understand the behavior one needs a sequence diagram. The ability of Together to do deep parsing on the source code
allows for accurate and efficient generation of sequence diagrams from a right-click option on any method. With this
on-demand generation, it is now possible to visualize the sequence of messages between objects as declared in the source
code.
Figure 4: Generate sequence diagrams from existing code
With such powerful synchronization between source code and UML, Together facilitates the understanding of existing
projects. For projects that have no design documentation whatsoever, Together eases the reverse-engineering of existing
code and the generation of class and sequence diagrams. This can be helpful when you are new to a project or when your
team has inherited new code. This technique also can help you understand third-party libraries used on the project.
If you are a developer using Eclipse, you might have downloaded it for any number of coding features. For example, by
creating navigable "snippets" of commonly used code, live templates provide great productivity when one is
writing code. Borland Together Edition for Eclipse takes this kind of productivity to an even higher level. Source code
is generated at the design phase. Class diagrams lead to classes, attributes, and methods. Sequence diagrams provide
skeletal code for method bodies. When design patterns are applied, working code implements the behavior of the pattern.
With custom patterns, a team can find new ways to reuse common relationships between classes. All of this helps the
developer focus more on implementing the critical business logic than on tediously coding the design.
Figure 5: Editing code with Eclipse
As important as code generation techniques are to enhancing productivity, much more must happen in a team development
context. In this context, developers need tools that help them work collaboratively on software, in such a way that
parallel efforts do not cause quality to slip. Fortunately, Eclipse helps developers use industry-standard techniques,
such as unit testing and refactoring, to build quality into an application during implementation. But complementing those
capabilities with Borland tools drives quality to the next level without sacrificing productivity. For Together product
demonstrations, please visit http://www.borland.com/together/viewlets.html
Any team project likely involves more relationships in the source code than any one person can keep in his head. Such
complexity makes it difficult for a developer to answer, "Did my change break something else?" JUnit provides a
convenient regression testing framework that allows developers to capture the assertions about how the software should
work at the method level. The simple nature of unit testing with JUnit allows developers to run tests frequently to check
for defects that might have been caused by a recent change. Eclipse makes writing and running unit tests easy.
Although a good unit testing framework goes a long way toward helping developers make changes with confidence, Borland®
Optimizeit Suite provides more detailed information when a unit test runs. Rather than just "pass or fail",
Optimizeit Suite provides insight into the runtime characteristics. With Optimizeit Suite, a developer can answer the
following questions:
- What objects are allocated when my method runs? What objects will remain after the method completes?
- Where are the bottlenecks in the flow of my method? How much CPU time is spent working in methods that I do not
control?
- Have I tested all the branches through a method? If I know my tests are thorough, are there any sections of code that
did not get run?
- Does my method have any common runtime problems such as uncaught exceptions, inefficient sizing of collections, or
critical resources that go unclosed?
While Optimizeit Suite provides considerable insight during unit testing, additional problems arise when the application
is brought together for integration in a Java 2 Platform, Enterprise Edition (J2EE) environment. The application might
talk to different back-end databases, have multiple front-end Web containers, and live in a clustered application server.
With such complex interactions, the next level of integration testing needs a similar complement to the "pass or
fail" results in order to provide insight into the interactions between these tiers. Borland® Optimizeit
ServerTrace can aggregate the information from these different locations into one cohesive view of the system and allow a
development team to drill down into trouble spots-right to the line of source code that might be causing the problem.
Figure 6: Understanding application performance across J2EE containers
Another approach to source code quality is the code review. Research and industry case studies reveal that code reviews
as a part of an overall software inspection might be the most cost-effective technique a team can use to reduce
defects.4 Yet many groan at the thought of a code review
because they are often time-consuming and inefficient. As developers argue over the best convention for curly braces, the
real issue of implementing the right business logic is easily lost.
With Together UML capabilities, code reviews can take advantage of a higher level of abstraction focused on the key
aspects of the system rather than on the fine-grained details. In fact, a group from the National Research Council Canada
conducted experiments comparing a traditional approach to code review, known as checklist-based reading (CBR), to a
UML-based approach, called perspective-based reading (PBR).5
The following indicates some startling results (emphasis added):
Our results indicate that PBR is more effective than CBR (i.e., it resulted in inspection teams detecting on
average 41% more unique defects than CBR). Moreover, the cost of defect detection using PBR is significantly
lower than CBR (i.e., PBR exhibits on average a 58% cost per defect improvement over CBR). This study
therefore provides evidence demonstrating the efficacy of PBR scenarios for defect detection in UML design documents.
In addition, it demonstrates that a PBR inspection is a promising approach for improving the quality of models
developed using the UML notation.
Within Eclipse, Borland Together can help in these efforts by allowing developers to rapidly create a domain model around
a selected class and easily visualize all dependency relationships. The team can quickly generate sequence diagrams for
complex methods. Furthermore, audits and metrics can be gathered to identify problems in the code base. Using audits to
find and fix problems before the code review, developers can focus on the logic of the code rather than on conformance to
corporate standards. Results from the metrics can help focus the attention of the team on the most complex sections of
code. With Together and a projector, the code review becomes as much an active coding session as it is a review.
Figure 7: Checking quality with audits and metrics
Such active modification of existing code driven by audits and metrics need not wait for code reviews. The combination of
UML, audits, and metrics found in Together and the refactoring support found in Eclipse provides the basic tools for a
technique called Software Remodeling.6 This technique builds
on the notion of "refactoring" popularized by Martin Fowler from the Extreme Programming community. He defines
refactoring7 as:
a disciplined technique for restructuring an existing body of code, altering its internal structure without changing
its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called
a "refactoring") does little, but a sequence of transformations can produce a significant restructuring.
Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each
small refactoring, reducing the chances that a system can get seriously broken during the restructuring.
In short, refactoring can be described as improving the design of existing code without breaking it. As such, refactoring
is the recognition that some aspects of design are driven from implementation-not all the details of an applications
structure can be planned up front. For Extreme Programming, refactoring is a constant part of day-to-day development. For
others, refactoring might occur only at certain points in the development cycle. Whatever the strategy, there is still a
question about where to spend refactoring effort. Some refactoring techniques actually might conflict or undo the
benefits of another. How do developers know where to focus their refactoring efforts? And how can developers know whether
the efforts are effectively improving design?
The Software Remodeling approach recommends using source code audits and metrics to drive refactoring. The results of the
audits and metrics point to areas of code that need improvement. After making changes with Eclipse refactoring support,
unit tests verify that the changes have not broken the code. Running audits and metrics again verifies the effectiveness
of the refactoring exercise. Combined with the refactoring capabilities in Eclipse, audits and metrics make it easy to
find and fix design and coding problems.
Overall, coding an application is only a part of delivering high-quality applications on time and within budget. With
Borland solutions, many additional techniques can be brought to bear on making higher-quality code without sacrificing
valuable development time.
The previous techniques provide developers with a great deal more control over the quality of the software they develop.
However, many factors that affect quality involve all the stakeholders. Enterprises have a separate testing team that
must report defects back to the development team. For that matter, end users, customers, or other stakeholders might need
to report defects found in production. Combined with all of the incoming requirements, these defects must be prioritized,
assigned, and worked on. If done in only an ad hoc manner, many defects can slip through the cracks. Or-worse-fixing one
defect can cause many new ones to appear.
Most development teams already use version control as a part of configuration management. Many popular configuration
management solutions are available, including Borland® StarTeam.® By providing, rich, full-featured capabilities, Borland
StarTeam allows Eclipse developers access to all configuration and change management capabilities. In order to balance
development speed and quality concerns, the changes requested of a system also are tracked in a "bug tracking"
tool. Unfortunately, most configuration management solutions offer poor integration between source code version control
and change request management. This makes tracking the status of change requests across parallel development efforts
difficult. In other words, there is no way to answer, "What change requests did we address in this branch?"
StarTeam provides the benefits of integrated version control, requirements, and change management; task and process
management; and knowledge sharing. The integration between these capabilities improves performance and communication
between distributed, remote teams. Extensive process management and reporting capabilities heighten visibility and
control of the application development lifecycle. With StarTeam, development teams are enabled to:
- Create traceability between file versions, requirements, change requests, defects, discussion topics, authors, and
status
- Gain easy identification of workload
- Identify each change with a unit of work
- Ensure that everyone works on approved changes
- Reduce handoff and approval times between engineering, management, and QA
- Build knowledge while preserving project context
- Build, deploy, and maintain critical applications more efficiently
Furthermore, with integration in Eclipse, developers have access to all the digital assets from within their development
environment. Checking in files directly from Eclipse allows developers to update the files that were checked out and
places the changes into StarTeam as a file revision. Developers can get up-to-date status on all their change requests
and edit them. By integrating these two products, Borland brings the power of StarTeam configuration and change
management capabilities to the Eclipse development environment. Such integration reduces the task interruptions that
often affect the engineer who has to launch a separate solution. This integration also permits developers to perform
essential configuration management tasks, including the creation and revision of change requests activities directly from
the Eclipse interface, and ensures that they work on the "correct" version of the code, thereby increasing
efficiency and improving productivity.
Figure 8: Viewing Change Requests from the StarTeam repository within Eclipse
Eclipse as an IDE is just one component of application development. By itself, it is a potent coding environment;
however, with solutions from Borland, the Eclipse platform becomes a truly enterprise-ready development environment. The
integration of requirements management, design, QA, testing, and configuration management functions enables developers to
keep projects on track. Borland solutions represent the latest and greatest from a company with more than 20 years of
experience and innovation in tools to enable software development.
Further information and trial versions of Borland solutions for the Eclipse platform are available on the Borland Web
site:
Borland® Together® - http://www.borland.com/together
Borland® StarTeam® - http://www.borland.com/starteam
Borland® CaliberRM - http://www.borland.com/caliberrm
Borland® Optimizeit - http://www.borland.com/optimizeit
Borland® Enterprise Server - http://www.borland.com/bes
1
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides,
Design Patterns (Boston: Addison-Wesley, 1995).
2
Deepak Alur, John Crupi, and Dan Malks, Core J2EE
Patterns: Best Practices and Design Strategies ( Upper Saddle River NJ: Sun Microsystems, 2001).
3
Sun Microsystems, Code Conventions for the Java
Programming Language, http://java.sun.com/docs/codeconv/
4
James H. Dobbins, CQA, "Inspections As an Up-Front
Quality Technique," Handbook of Software Quality Assurance, Edited by G. Gordon Schulmeyer and James I.
McManus, pp 247-252 (Upper Saddle River, NJ, Prentice Hall, 1999).
5
Oliver Laitenberger, Colin Atkinson, Maud Schlich, and Khaled
El-Emam, An Experimental Comparison of Reading Techniques for Defect Detection in UML Design Documents,
(National Research Council Canada, December 1999).
6
Richard Gronback, Software Remodeling: Improving Design
and Implementation Quality Using audits, metrics and refactoring in Borland Together ControlCenter, January 2003.
7
ThoughtWorks, Refactoring Home Page, Martin Fowler,
http://www.refactoring.com/
Made in Borland® Copyright © 2005 Borland Software Corporation. All rights reserved. All Borland brand and product names are trademarks or registered trademarks of Borland Software Corporation in the United States and other countries. Microsoft, Windows, and other Microsoft product names are trademarks or registered trademarks of Microsoft Corporation in the U.S. and other countries. All other marks are the property of their respective owners. Corporate Headquarters: 100 Enterprise Way, Scotts Valley, CA 95066-3249 831-431-1000 www.borland.com Offices in: Australia, Brazil, Canada, China, Czech Republic, Finland, France, Germany, Hong Kong, Hungary, India, Ireland, Italy, Japan, Korea, Mexico, the Netherlands, New Zealand, Russia, Singapore, Spain, Sweden, Taiwan, the United Kingdom, and the United States.
