Extracting Platform Dependencies of Third-party Components

Finding out the platform dependencies for your own software models and/or source code is relatively straightforward, compared to finding out the platform depencies of third-party binaries. PlatformKit can help you to extract the platform dependencies for third-party Java jar files and Java projects (including any jar files on its class path). It uses the UML models generated by the Jar2UML tool for this. PlatformKit provides a number of built-in API models, which can be compared against a dependency model of your jar files or Java project.

You can compare the dependencies of any jar file in your workspace against a built-in API model of PlatformKit:

1. Right-click the jar file for which you want to determine the compatibility.
2. Select “PlatformKit (Java) → Determine compatibility with built-in API”.
   The “Select API models” dialog is now shown:
   
3. Select up to one API model per category.
4. Check the box “Create/update platform dependency ontology” if you want to automatically generate the platform dependency constraint ontology.
   See also Translating compatibility reports into platform dependency constraints.
5. Now click “OK”.
   A progress dialog comes up. As the process may take a while, you may choose to run the process in the background while you do something else.
6. The result – compatible or not – is displayed in a dialog window:
   
7. Click “OK” to close the dialog. If the selected API turned out to be incompatible, the detailed comparison results can be viewed in a report that automatically comes up:
   

The compatiblity report shows a number of things:

• The byte code format version detected by Jar2UML. This includes whether or not the bytecode was preverified for use with J2ME MIDP for mobile phones. See Class_(file_format) for more information.
• Packages, classes, interfaces, primitive types, operations and attributes that were part of the dependency model, but were missing in the API model(s).
• Packages, classes and interfaces that contain missing elements, and are tagged as incompatible.
• Elements that are referenced by other elements, and therefore necessary for a complete model.

In addition, it's possible to browse the dependency model that was generated from the selected jar file. It has the same base name as the jar file, with the file extension ”.deps.uml”:

You can compare the dependencies of any Java project in your workspace against a built-in API model of PlatformKit:

1. Right-click the Java project for which you want to determine the compatibility.
2. Select “PlatformKit (Java) → Determine compatibility with built-in API”.
   The “Select API models” dialog is now shown:
   
3. Select up to one API model per category.
4. Check the box “Create/update platform dependency ontology” if you want to automatically generate the platform dependency constraint ontology.
   See also Translating compatibility reports into platform dependency constraints.
5. Now click “OK”.
   A progress dialog comes up. As the process may take a while, you may choose to run the process in the background while you do something else.
6. The result – compatible or not – is displayed in a dialog window:
   
7. Click “OK” to close the dialog. If the selected API turned out to be incompatible, the detailed comparison results can be viewed in a report that automatically comes up:
   

The compatiblity report shows a number of things:

• The byte code format version detected by Jar2UML. This includes whether or not the bytecode was preverified for use with J2ME MIDP for mobile phones. See Class_(file_format) for more information.
• Packages, classes, interfaces, primitive types, operations and attributes that were part of the dependency model, but were missing in the API model(s).
• Packages, classes and interfaces that contain missing elements, and are tagged as incompatible.
• Elements that are referenced by other elements, and therefore necessary for a complete model.

In addition, it's possible to browse the dependency model that was generated from the selected jar file. It has the same base name as the jar file, with the file extension ”.deps.uml”:

Using the generated dependency models and compatibility reports, you can determine what platform dependency constraints you need to define. If you chose “Create/update platform dependency ontology” when determining compatibility with selected APIs, a platform dependency constraint ontology has been generated (or updated, if it already existed).

This file sits in the same folder and has the same name as the ”.deps.uml” file that is described above, and has the ”.owl” file extension. This ontology contains exactly one platform dependency constraint, which describes the required JRE, Java VM, bytecode format, and class libraries:

Depending on the APIs you chose to check against, class library dependency constraints are generated or not. All satisfied package dependencies are translated into class library dependencies on the provided API package. If multiple API packages satisfy the same package dependency, the least specific API is selected for the dependency constraint (such that the most specific will automatically satisfy the same constraint). If an API package is neither more, nor less specific (i.e. a sibling), it is just added to the class library dependency constraint.

This strategy is also followed when updating an existing platform dependency ontology. Any existing class library dependencies are updated with API packages that are either less specific, or siblings of existing API package dependencies:

Modelling platform dependencies is further described in the next task: Modelling Platform Dependencies.

In addition, a ”.platformkit” file with the same name has been generated. This file contains exactly one ConstraintSet with one Constraint in it, which points to the OWL dependency constraint class in the generated ontology:

The ”.platformkit” model can be used for several reasoning tasks, which are described in the tasks Setting up a Platform-Aware Configuration Language and Platform-Driven Deployment.