Using Eclipse Plug-ins from Borland to Gain

Transcription

Borland Application Lifecycle
Management (ALM) for Eclipse
Extend the Eclipse framework with Borland ALM
solutions for requirements, design, development,
performance and testing, and change management
A Borland White Paper
By Ian Buchanan
September 2004
Borland Application Lifecycle Management (ALM) for Eclipse
Contents
Introduction ......................................................................... 3
There’s more to development than “edit-compile-debug” .................................................... 3
Requirements management ................................................... 4
Analysis: Supplementing requirements with Unified Modeling Language™ (UML®) models
.............................................................................................................................................. 6
UML modeling for architecture and design ............................. 8
Borland® Together® makes understanding large code bases easy......................................... 9
Implementation is more than just coding .............................. 11
Testing for developers: Coding with confidence ................................................................ 12
Audits and metrics reduce the tedium of code reviews....................................................... 14
Software remodeling is the realization of iterative development ........................................ 16
Collaborating on software development ................................ 17
Borland® StarTeam®: Beyond version control.................................................................... 18
Conclusion .......................................................................... 19
2
Introduction
Although many teams 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 Application Lifecycle
Management (ALM) solutions, developers can work more effectively within a software
development team, without being locked into a particular platform.
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 ALM. Furthermore, by offering solutions for Eclipse,
Borland is proving its commitment to platform independence and modular solutions.
There’s more to development than “edit-compile-debug”
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
3
must work with many different languages such as HTML, C/C++, 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.
Requirements management
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.
4
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 welldefined requirements process that forces business users to provide the correct requirements
from the beginning in order to minimize the amount of project rework.
5
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
Analysis: Supplementing requirements with Unified
Modeling Language™ (UML®) models
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
6
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-touse 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.
7
Figure 2: Tracing requirements to UML elements
UML modeling for architecture and design
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
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 Proactices and Design
Strategies (Upper Saddle River, NJ: Sun Microsystems, 2001).
8
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
Borland® Together® makes understanding large code
bases easy
Another challenge addressed by LiveSource is the difficulty in keeping design documents
current with changes to source code. Because LiveSource keeps the diagrams synchronized
3
Sun Microsystems, “Code Conventions for the Java Programming Language,”
http://java.sun.com/docs/codeconv/
9
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
10
team has inherited new code. This technique also can help you understand third-party libraries
used on the project.
Implementation is more than just coding
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
11
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
Testing for developers: Coding with confidence
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?
12
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
13
Audits and metrics reduce the tedium of code reviews
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 UMLbased approach, called perspective-based reading (PBR).5
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)
14
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
15
Software remodeling is the realization of iterative
development
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 refactoring as:7
… 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?
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/
16
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.
Collaborating on software development
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
17
development efforts difficult. In other words, there is no way to answer, “What change
requests did we address in this branch?”
Borland® StarTeam®: Beyond version control
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
18
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 the StarTeam repository within Eclipse
Conclusion
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.
19
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
Made in Borland® Copyright © 2004 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. Java and all
Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. 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. • 22818
20

Using Eclipse Plug-ins from Borland to Gain

Transcription

Similar documents

GAYLAN`S LUNAR ECLIPSE 6/23/97 – 6/22/09

How to use Eclipse.net (library software)

solar eclipse special

Shake that FUD

Time Out New York - Feature - March 26 - April 1, 2015

Tribal Eclipse—Color Us Impressed

eclipse

Eclipse™ R.O. - Water

18-Feb-2015 - Institute of Astronomy