Architecture
As written before, AbstractALM only supports the migration of file revisions. But since the framework is extensible to support other artifacts in later versions of the framework, this is not a real problem, only a limitation of this diploma thesis. The next figure shows the class overview of the library:
AbstractALM Class Overview
Most of the items shown on the diagram are interfaces. The interfaces are implemented in the vendor specific implementations, as described later in this section. All interfaces are derived from the interface Object which declares methods common to all derived interfaces, such as getNativeObject. All artifacts that are migrated from the source repository are derived from Artifact. To extend the library with other artifacts from the ALM approach, it is possible to define interfaces for them, such as ChangeRequest, TestCase, etc. Therefore, it is easy to extend the library for more artifacts.
Interfaces
A typical AbstractALM interface looks like the one shown in the next figure:
Artifact Interface
Interfaces like the Artifact interface define the general features and data structures of the supported SCM systems. Note that not each system needs to support each features. Most methods of this interface throw a NotImplemented exception if the method cannot provide sufficient information from the SCM system or if the method is not yet implemented (but supported by the SCM system in principal). Several artifacts are available in the system, including files and folders.
The interface Artifact is derived from org.abstractalm.Object which defines the obligatory information each object must provide, that is
-
The underlying connection to the repository this object belongs to
-
The native object (from the vendor SDK) that provides more functionality
-
The repository-wide unique ID of the object.
Generic Object Interface
Properties
The library also declares properties, a feature currently not implemented by the vendor specific implementations (because of time constraints). The concept behind the properties is that each SCM system supports information that is not covered by the AbstractALM interfaces shown before. For example, the Serena Adaption defines the property Visible for the repository. Other SCM systems do not support the Visible property, therefore, the property is not defined in the interface.
AbstractALM Properties
On the other hand, the goal of AbstractALM is to define as much properties as possible. If a SCM system does not support the property, an exception NotImplemented is thrown by the implementation. Each application using an AbstractALM adapter needs to check for this exception and define an alternative if the property is not supported by the SCM system.
Properties are Objects as well. Therefore, they support the native object method. In both cases, the method getNativeObject provides the native object that the AbstractALM implementation is using behind the scenes.
Note that the native object is provided as a java.lang.Object. That means that the object must be casted before using the native object. Most adoptions provide an additional method in the implementing class that returns an already casted object for convenience.