WebSphere Studio Application Developer Version 5 Programming Guide part 72 ppt

684 WebSphere Studio Application Developer Version 5 Programming GuideObject references The Object References view shows patterns of references in varying detail, both to and from a set

Trang 1

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

Trang 2

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

Trang 3

Trang 4

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

Trang 5

Trang 6

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

Trang 7

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

Trang 8

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

Trang 9

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

Trang 10

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

Định dạng
Số trang	10
Dung lượng	196,24 KB