DependencyHunter for IBM® Rational® XDE® for Java® Release Notes

Version 0.5 Java, Windows®

© 2005 Dominik Enkelmann. All Rights Reserved.

Any reproduction or distribution of this work is expressly prohibited without the prior written consent of the copyright owner.

Product Definition

DependencyHunter allows Rational XDE users to enrich models with dependencies present in existing Java source code. This enables developers and software architects to correctly model existing java applications at a detail level otherwise not reached. Knowing associations and dependencies between classes in source code is the basis for the evaluation of the impact of change to any existing class.

Rational XDE2003.06 does not provide any support for dependencies in source code. If you would like to see them in your model, you had to add and maintain them manually - an impossible task in real projects. With DependencyHunter users can add and update dependencies in the model in a minute.

Contents

Hardware/Software Information
User Documentation
Using DependencyHunter
Technical Support
License and Warranty

Hardware/Software Information

System and Software Requirements

Since DependencyHunter is a new ane free product, the development focus has not been to support a vast collection of possible environments. It should run with most Windows/XDE versions.

DependencyHunter has been tested in the following environments:

User Documentation

DependencyHunter is a stand-alone application that integrates with IBM Rational XDE to add reverse engineered dependencies between Java classes to existing XDE models.

What are Dependencies?

In UML Dependencies are used to describe the fact that a class depends on the existance of another class, without having a structural relationship (e.g. Class is a Field of other class).
Especially when evaluating the impact of a change to be implemented in a class, knowing the classes that depend on the class to be changed enables you to estimate the impact the planned change will have

A dependency is used to model the following situations:

Local Variable Usage

Consider this snippet of a method of ClassA:

public void OpUsesClassB() {
   ClassB myClassBVariable;
   myClassBVariable = new ClassB();
   // do something
}

Code snippet from "ClassA"

The above code shows a dependency through local variable usage in Java code. Inside the method OpUsesClassB() an object of ClassB is declared and instantiated.
Since all this happens inside a method, it is not modeled as an Association, but ClassA depends on the existance of ClassB.

Parameter Usage

If a class is used as parameter or return value of another class this is modelled as a Dependency.

public ClassB OpWithClassBParameter( ClassB aParam ) {
   // do something
}

Code snippet from "ClassA"

in the above sample code, the usage of ClassB as return value ( public ClassB ...) gives a dependency of ClassA on ClassB, the usage of ClassB as type of a parameter (ClassB aParam) dito.

Global Code

When using globally available code, such as utility functions, this is also modelled as a Dependency. In Java code this is possible through the use of static member functions.

import GlobalClass;
...

public void OpUsesGlobalClass( ) {
  GlobalClass.Do();
}

Code snippet from "ClassA"

In the above sample, the GlobalClass is made visible to ClassA through the import statement. There is no instantiation of class GlobalClass, since all of its member functions are declared static. ClassA uses functionality provided by the GlobalClass (GlobalClass.Do()), so it depends on the existance of class GlobalClass.
Please note that this type of programming violates the object oriented paradigm and thus its usage should be limited to situations where you have really generic utility functions. An example for this is the class Math from the JDK.

DependenyHunter does not support this type of dependency.

Using DependencyHunter

The general usage model is straightforward:

1. Start DependencyHunter
2. Select your Model (Must be a Java Code Model)
3. Set options
4. Select Process
5. Exit DependencyHunter
6. Open generated Model with XDE and add dependencies to diagrams

When starting to use DependencyHunter you should not check the option "Update original model file", so you can play around without modifying your input model.

Please read the section Limitations and Issues below.

Check the Report or Log file for errors. If there are any errors, probably the generated model will miss some dependencies.

Figure 1, DependencyHunter Main Window

Options

Model File

The Rational XDE Java model file you are going to analyze. You set the file using the Browse... command.

Output and Log File

The output model file of the enriched model. By default this will be a new model with path and name of the input model, with "with dependencies" appended to the model name.
If you check the Update original model file option, you perform an update to your existing input file.

The log file will always be located in the same folder as the DependencyHunter executable. The log contains all messages shown in the DependencyHunter main window during elaboration.

Update original model file

Check this option if you want to update your input Java code model. Use this only after having tried and checked the results. There is no undo for this exept restoring your input model from a backup.

If unchecked, a new model file will be generated.

Merge multiple dependencies

Unchecked by default.

If you check this option, multipe dependencies between two classes are summarized to only one dependency element. The description of the generated dependency will contain the details about all found dependencies.

If this is unchecked, one dependency will be created for every occurence of a dependency, for example one for parameter to operation usage and another one for return value from operation.

Set stereotype <<generated>>

Checked by default.

If this option is checked, all generated dependencies are stereotyped "<<generated>>". This allows you on one hand to destinguish between manually created dependencies already present in your model and new generated ones, on the other hand this information is used by DependencyHunter itself to identify generated dependencies when updating a model.

If this is unchecked, no stereotype is set.

Set dependency name to name of originating operation

Checked by default.

If this option is checked, the generated dependencies receive the name of the operation in which they are located as dependency name.

If this is unchecked, no name is set.

Existing Dependencies

Default is Don't touch.

If this option is set to Don't touch, dependencies already existing in the input model will not be touched and the new ones found by DependencyHunter will be added.
Note: Dependencies stereotyped <<generated>> will be removed prior adding anything anyway.

If this option is set to Delete, all dependencies in the input model are deleted before the new ones are added.

Note: DependencyHunter cares only about dependencies between two classes, dependencies between Packages or Components are never touched. (Java interfaces are considered classes in this context).

Functions

Browse...

Select the XDE Java model to be processed.

Note: You must select a Java Code Model, otherwise there would be no source files associated and no dependencies could be found.

Process

Process the selected model. DependencyHunter processes the input data as follows:

• The XDE model is opened and scanned for classes with ".java" files associated
• The source files represented in the model are opened and scanned for dependencies one by one
• Remove eventually existing dependencies in the input file according to the setting of the Existing Dependencies option
• Add found dependencies to model
• Write model as update to input file or as new model file

Exit

Exits the DependencyHunter application. The log file can be found in the program folder as "DependencyHunter-log.txt".

Known Limitations and Issues 

Technical Support

If you have questions about installing, using, or maintaining this product, contact Dominik Enkelmann at contact @ dominikenkelmann.de.

Please include the following information:

• Your name, company name, telephone number, and e-mail address
• Your operating system, version number, and any service packs or patches you have applied
• Detailed problem description

License and Warranty

(C) Copyright 2005 by Dominik Enkelmann, Untere Weingarten 6, D-73092 Heiningen, contact @ dominikenkelmann.de.

Permission to use this version (see top of document) of this software and its documentation for any purpose is hereby granted without fee to elegible users.
Elegible users are all individuals and organisations not resident of, or physically located in the United States of America.

Dominik Enkelmann makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty.
Dominik Enkelmann disclaims all warranties with regard to this software, including all implied warranties of merchantability and fitness, in no event shall Dominik Enkelmann be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use of this software.

---

IBM, Rational, XDE sind Warenzeichen oder eingetragene Warenzeichen der International Business Machines Corporation in den Vereinigten Staaten, anderen Ländern, oder beiden.
Java is a trademark or registered trademark of Sun Microsystems, Inc. in the U.S. and other countries.
Microsoft ist eingetragenes Warenzeichen von Microsoft Corporation in den Vereinigten Staaten, anderen Ländern, oder beiden.