Code Analysis with jmove

jmove is based on a model centric approach which allows to analyze different kind of sources like source code, byte code and design models imported from Case Tools. So the toolkit is not limited to a specific Programming Language. Since jmove provides an extensible Meta-Model it is even not restricted to specific types of models. So it is possible to analyze object oriented, relational and other type of models which may be relevant within a software-system.

Model

The framework jmove provides a model, which offers basic elements to present an abstract view to software systems. This model is also called core model . The term core model is explicitly chosen to make a difference between the term meta model defined by OMG. In spite of OMG Meta-Model-Levels every jmove model is described by the same elements.

To map for example a concrete Java Software System into a model, jmove provides principally the same structures like the core model. The concrete structure elements for Java are specializations from the core structure elements, but the type of the elements is the same.

Basic Concept

In the context of jmove a Model is at concept-level a tupel of two sets. The first set contains elements describing model entities, an element of the this set is called Thing. The second set contains elements describing the connection between the model entities. In detail the elements of the second set are itself tupels consisting of Things. An element of the second set is called Link. In a more abstract view a jmove model is an undirected graph consisting of nodes and edges, where the nodes are called Things and the edges are called Links.

A Thing has an identifier. Things can be added to a model and can be retrieved from a model by specifying its identifier. Additionally a model can deliver subsets of Things by specifying a Filter for Things. Thing is a very general name to indicate explicitly the basic openness of the term Model, but you can call Things also elements of a Model.

A Link connects exactly two Things, each thing has a Role in the link relationship. The concrete implementation vary from the above abstract view, because Links are not directly retrieved from the model. The usage of LinkFilters to get subsets of Things by traversing all suiting links transitively from a given Thing gives many opportunities to inspect a model.

Finally every Thing may be extended dynamically by one or more Aspects. An Aspect is associated to exactly one Thing and can be defined arbitrarily.

The following diagram shows an excerpt of the concrete implementation of the jmove core model: Apart the main entities Thing, Link, Aspect, Model there exists describing interfaces like Identifiable and AspectOwner and base implementations for aspects and things.

Core model 

Furthermore the core model offers realisation for the following entities:

  • Link
    • Dependency - one thing takes the role Dependant, the other the role Target
    • Containment - one link end takes the role Element, the other the role Container
  • LinkFilter
    • AsRoleFilter - accepting only things with a given role
    • WithRoleFilter - accepting only things where the other link end has the given role
    • OtherFilter - accepting only things where the other link end is an instance of the given type
    • CompositeFilter - combining several filter with logical and
    • OrFilter - combining several filter with logical or
    • NoFilter - accepts all elements

Java Model

A model for programming language Java is described by a JModel. To build a java model physical resources (concretely byte code) are used. One or more resources are grouped in Modules. A java package is defined by the constructJPackage. A package is a Thing and has a unique name (its absolute package path), which is its identifier too. A package can contain classes and interfaces, which are collective represented by a Type. A Type is a Thing with additional modfiers. These modifiers marks properties like changeability or the scope of a Type. The fact that a Type represents a class or a interface is also stored in its modifiers. The full qualified classpath of a class or an interface is the identifier of the representing type. For inner, local and anonymous types the identifiers are built by the same rules the compiler uses.

Furthermore types can have members. A Member is an Attribute or a Method. Because members are ordinary things, they have an identifier. The identifier of a member is assembled by the identifier of the surrounding type, the character '.' and the name of the member. A specific feature of the language Java is the existence of primitives like int, double and boolean. In a jmove java model a Primitive is a thing, so there is no much difference to a type. The identifier of an Primitive is its unique name, one of the following: boolean, byte, char, short, int, long, float, double.

 Java model

A StrictlyConnectedComponent contains things, which are linked with each another in cycles. Thus it represents cyclic dependencies within the model.

While the above terms covers the structures in a java model, the following terms names the connectivity between these model elements. The link types

  • Inheritance with the roles Supertype and Subtype,
  • Dependency with the roles Target and Dependent,
  • Containment with the roles Container and Element

are supported by jmove java model. Inheritance is a specialized Dependency, but Containment not. At present the link ends have no cardinality, so if you have a dependency from type X to type Y, X can depend one or a hundred times on Y.

Additionally jmove offers the following realisations of an Aspect:

  • LoadState - Internal state for loading (unload, load, stub).
  • Location - Place where the attached Thing was found.
  • RCMartin - Abstractness, instability, distance, efferent and afferent coupling as defined by R.C.Martin of the attached type.
  • ModelInfo - Simple count metrics for models.
  • ModuleInfo - Simple count metrics for modules.
  • JarClassCollection - The module location of the attached thing.
  • DirClassCollection - The module location of the attached thing.



Further Reading

To get deeper into the jmove-api, check API Reference and the source code.