WebSphere Studio Application Developer Version 5 Programming Guide part 72 ppt

684 WebSphere Studio Application Developer Version 5 Programming Guide
Object references
The Object References view shows patterns of references in varying detail, both
to and from a set of objects (if such references exist). To display information, this
view requires profiling data that contains object reference information. You can
use this view to locate objects that still have references to them, study data
structures, and find memory leaks. An example of an Object References view is
shown in Figure 20-28.
Figure 20-28 Object References view
This view displays the following information:

Base set of objects—Appears in the gray area on the left. Each new object
resides in this area once, but its instances also reside elsewhere. The view
shows references to and from this base set of objects. You can select the
base set of objects from the Display field.

Objects—Represented by squares, each colored uniquely by class. Squares
come in two forms:
– A single square denotes a single instance
– Twin squares represent multiple instances

Class objects—Represented by diamonds.
Note: To interpret this view, you need to have a good understanding of how
objects are allocated and referenced in your application and how Java handles
object referencing.
Chapter 20. Profiling applications 685
 References between instances—Denoted by black arrows between the
instances. An arrow points to the objects being referenced. Arrows point right
to left.

Repetition of an object—Represented by a blue, upward-pointing arrow.

Click this arrow to display a long, blue arrow that leads to another place
where the same object is displayed.

Old objects—Denoted by a red font color for the number of objects and the
class name, both of which appear to the right of each instance.

New-generation objects—Denoted by a black font color for the number of
objects and the class name, both of which appear to the right of each
instance.
Some things to be aware of
Here are some further considerations:
 Because communications with the IBM Agent Controller is done via TCP/IP
sockets, firewalls may block the communication.
 Views have to be refreshed to show the latest data by using
Refresh Views

from the context menu in any profiling view, or by clicking in the Profile
Monitor view.
 You cannot use profiling and debugging at the same time.
Summary
In this chapter, we covered the profiling tools of Application Developer and
included examples of the different statistics that are accumulated.
Note: Old objects are those created prior to a certain point during the
profiling session. You can specify that point as you create a dump of the
object references using the
Collect Object References icon in the
toolbar. Objects that are created after that point in time are referred to as
New-generation objects.
686 WebSphere Studio Application Developer Version 5 Programming Guide
© Copyright IBM Corp. 2003. All rights reserved. 687

Part 5 Team programming
Part 5 covers how to use Application Developer in a team development
environment. We cover team development with both Common Versions System
(CVS) and Rational ClearCase LT.
Part 5
688 WebSphere Studio Application Developer Version 5 Programming Guide
© Copyright IBM Corp. 2003. All rights reserved. 689
Chapter 21. Version control
Application Developer is a file based integrated development environment (IDE).
It operates on a workspace where all of the data relative to the environment
options and to the loaded projects is stored. This workspace has a root directory
and is composed of regular files. You may have as many workspaces as you
want, but you can only work with one at a time per each IDE instance.
A local history of resource changes is maintained within the workspace. This
allows developers to compare and replace resources with earlier editions.
In most cases, though, developers do not work alone, but rather as part of a
team. Application Developer’s open architecture allows software configuration
management (SCM) systems to be plugged-in to support such kinds of
development effort.
This chapter includes the following topics:
 Workspace activities in standalone development
 Team development and terminology
 SCM integration with Application Developer
21
690 WebSphere Studio Application Developer Version 5 Programming Guide
Local history
In Application Developer, a local history of changes is maintained when you
create or modify and save a file. This allows you to compare the current file
edition to a previous one, replace the file with a previous edition, or even restore
a deleted file. Each edition in the local history is identified by the date and time

the file was saved.
Comparing files
To compare the current edition of a file with a different one, choose
Compare
With -> Local History
from the file’s context menu. You can select different local
editions and compare them against the currently loaded edition (Figure 21-1).
Figure 21-1 Comparing the TransRecordBean class with its local history
There are three panels in the
Compare with Local History
window:
 The top left panel lists all the available editions in the local history for the
selected file. These editions are grouped by the save date.
Note: Only files have local histories. Projects and folders do not. The local
history is independent of the team development environment and the shared
team repository.
Chapter 21. Version control 691
 The top right panel lets you select what Java structure you want to compare.
The default is to compare the whole file, but if you had more than one class in
the compilation unit, you could want to limit the comparison to just on class by
selecting it in the list.
 The bottom panel shows the current edition on the left and the selected
edition on the right. Graphical cues indicate where the code has changed and
what kind of change occurred. You can see in Figure 21-1, for instance, that
the setAccount method that exists in the current edition did not exist in the
previous edition. There are also two arrow buttons that let you scroll through
the individual changes.
Replacing files
A similar dialog (Figure 21-2) lets you replace the loaded edition of a file for
another one. To do that, select

Replace With -> Local History
from the file’s
context menu.
Figure 21-2 Replacing the loaded edition with another one from the local history
This time around, the dialog presents you with just two panels. It would make
little sense to show the
Java Structure
panel because a replace would affect the
whole compilation unit.
692 WebSphere Studio Application Developer Version 5 Programming Guide
Restoring deleted files
To restore a deleted file, select the container where the file used to be (like a
folder or a Java package) and select
Restore From Local History
from its context
menu. The dialog in Figure 21-3 is displayed:
Figure 21-3 Restoring a deleted file from the local history
Preferences
Finally, you can set how Application Developer manages the local history by
selecting
Window -> Preferences
and then selecting
Workbench -> Local History

(Figure 21-4).
Figure 21-4 Setting the local history preferences
Chapter 21. Version control 693
Team development
The Eclipse platform is based on the concept of letting users create and edit
resources that are stored in the file system. Unfortunately, network file systems

do not offer the necessary flexibility and set of services to support team
development. If you project calls for more than just one person, chances are that
you are going to need a software configuration management (SCM) system, or at
least a subset of it.
The U.S Department of Defense, in its standard on software development
(DOD-STD-2167A), defines SCM as follows:
Software Configuration Management is the discipline of identifying the
configuration of software systems at discrete points in time for the purpose of
controlling changes and maintaining traceability of changes throughout the
software life cycle.
These tools must support a set of related and sometimes overlapping functional
areas, among which are:

Version control—This is the ability to store and retrieve snapshots of the
state of components at any given point in time. The mechanism usually
employed to store these versions is called forward-delta versioning, that
enables version branching with a minimum of storage wasted.

Problem tracking—Problem tracking usually works through two
mechanisms: defects and features. Defects track the life cycle of a problem
with any of the software components from identification all the way through to
final resolution. Features are additional requirements that must be
implemented in the system.

Change management—It is the process of identifying, tracking, and
controlling changes to software components.
Change management commonly provides an audit track that identifies which
files have gone through what changes, when these changes occurred, who
modified the files, and why. A defect or feature may result in the modification
of hundreds of files across more than one product, including documentation

and test cases.
Change management, through the mechanism of tracks, should produce and
keep records of each file modified in each separate product as related to the
particular defect or feature. When you are ready to include the changes for
the defect in the release and build the release, you should only need to
specify the track number and all the changes would be committed to the
repository and included in the release.

Build and deployment management—Gives you the ability to build and
deploy your software product in a repeatable manner.