About ArchMapper

ArchMapper is a Tool for mapping high-level architecture descriptions of a program to implementation artifacts. More precisely, it offers two main functions:

1. Generating Java source code stubs from an architecture
2. Checking a Java implementation for conformance with an architecture

ArchMapper can generate more specific sourcecode if the implementation is based on a Middleware or application framework. The Specifics of the Middleware must be given in a style-specific mapping for this to work. There can also be conformance checks that are specific for a Middleware.

Architecture Description

The architecture must be defined as a configuration of components and connectors. Currently, the Architecture Description Language (ADL) Acme can be used for this purpose. There is an Eclipse plug-in (AcmeStudio), which allows graphical editing of such an architecture.

Alternatively, the architecture can be defined with a simple XML format. The conceptual elements are the same as in Acme, but the syntax is simpler because some advanced Acme-Features have been omitted.

Architecture Mapping

The architecture description can be very abstract. Every Component or Connector can be implemented in several classes. Not every class in a component should be visible for other components. That means ports should be used only by some classes and ports should expose only the interface of a component.

Consequently, we need a mapping from components, connectors, and ports to classes. This mapping can be defined in an XML file. For every component and connector, classes and interfaces can be defined explicitly or with classname patterns.

As an alternative or complement, mappings can be defined with Java-Annotations directly on a class. The drawback is that sourcecode generation does not work with this approach.

Style Mapping

An architecture can be based on an architectural style. An architectural style defines component and connector types and restrictions about how an architecture may be composed. If the style is influenced by a middleware, then something can be said about the implementation of each component type.

For each supported style, there must be an XML file with style mapping information. This includes class types for each component or connector type with information about super classes and interfaces. Port types can be defined that export only certain class types. For file types, a template for the code generator can be defined.

Code Generation

The code generator gathers information from the architecture, the architecture mapping and, optionally, the architectural style mapping. This includes information about superclasses and interfaces, class name, package and known classes from the interface of connected components. Furthermore, files can be generated with a template content defined in the style mapping. There can also be style-specific generators for a Middleware. For example, there is a generator that can generate Spring configuration files.

Conformance Checking

The most important question concerning the conformance of architecture and implementation is: "Do the classes indeed communicate in the way that is defined in the architecture?". This is called "communication integrity" and is one of the rules that can be checked. More precisely, it is checked whether a class has any references to classes in non-connected components or to classes that are not exposed through the port of a connected component.

Other generic rules check if all components are present in the source code, if every class belongs to a component, and if all classes are implemented in the way defined in the mappings.

There are also rules that check the structure of the architecture itself. They check if there are cyclic dependencies among the components and how complex the dependency structure is.

Moreover, every Middleware style can define its own rules. That means that restriction for classes in components of a distinct type can be checked, based on rules defined in the style.