Rule-Based Architectural Compliance Checks for Enterprise Architecture Management

Constanze Deiters, Patrick Dohrmann, Sebastian Herold, and Andreas Rausch Clausthal University of Technology

Department of Informatics – Software Systems Engineering P.O. Box 1253

38670 Clausthal-Zellerfeld, Germany {constanze.deiters, patrick.dohrmann, sebastian.herold, andreas.rausch}@tu-clausthal.de

Abstract

Modern enterprise application systems are parts of complex IT landscapes. The architecture of such a landscape may impose constraints upon the design of single applications, for example by the mandatory use of enterprise-wide reference architectures. It is of great importance for the sake of smooth operation and easy maintaining that single applications are com-pliant to the reference architectures. Checking this compliance is highly important for the architecture management to assure the quality of application sys-tems. Unfortunately, current tool support is not flexible enough to easily check different aspects of architectur-al compliance.

This paper proposes a rule-based approach based upon logic programming concepts towards a formal-ism for architectural compliance checking. In this ap-proach, the architecture and design are represented as logical knowledge base that can be queried for archi-tectural compliance. Furthermore, the paper presents a case study, in which the approach was prototypically implemented and applied in an industrial context. 1. Motivation

Nowadays, there is still no agreement on a single precise definition of the term “software architecture”. A bunch of definitions can be found at [1]. Most defi-nitions share a common view of the notion “software architecture”, which is more or less similar to the defi-nition in the corresponding ANSI/IEEE Standard [2]: Software architecture is defined by the recommended practice as the “fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles govern-

ing its design and evolution”. Thereby, one essential goal of software architecture is to provide a structure of components and their interrelationships to meet the behavioral, non-functional, quality, and life-cycle re-quirements of the considered application [3,4,5].

Based on the level of abstraction there exists a clear distinction between the notion of architecture, design, and implementation, as discussed and formalized in [6] and [7]. However, as already included in the AN-SI/IEEE definition software architecture “contains the principles governing design and evolution” of the cor-responding application. Hence, to attain one of the most important goals of software architecture, we have to guarantee that the elaborated and possibly even veri-fied architecture is correctly further refined and trans-formed into design and implementation of the corres-ponding application.

Moreover, modern enterprise applications are part of complex IT landscapes. Enterprise Architecture Management (EAM) claims to provide an approach to manage and evolve these IT landscapes by an IT man-agement process as strategic business demands and by providing standards and guidelines for enterprise ar-chitectures for the development of single enterprise applications [8]. Enterprise architectures of IT land-scapes define reference architectures for all enterprise applications. Thereby, reference architectures structure and specify interfaces between and within the enter-prise applications to document and minimize the de-pendencies between the corresponding enterprise ap-plications.

Similar to software architectures, designs, and im-plementations of single applications, it is also a crucial task of the involved software architects and developers to ensure the compliance of these artifacts towards the more abstract, coarse-grained, and application-spanning reference architectures. For example, the

design of a single application, like an information sys-tem, might be restricted by the enterprise-wide refer-ence architecture defining the separation into mandato-ry logical layers [9]. If this structure is violated by not allowed dependencies, the separation into different concerns that motivated the layers gets obsolete and may affect the whole IT landscape. As a consequence, it might become impossible to maintain and to adapt. Thus, compliance checking helps to ensure the quality of the enterprise application and the overall IT land-scape it is embedded in.

Even highly sophisticated experts, like the Eclipse developer team, are not able to completely fulfill their own architectural rules, like simple import rules be-tween packages [10]. Obviously, for large enterprise applications and IT landscapes this architectural com-pliance check cannot be manually performed due to size and complexity of the related applications, but must be supported by proper tool support [11]. Unfor-tunately, current tool support, like for instance SonarJ [12] or Architecture Rules [13], is not flexible enough to easily check different aspects of architectural com-pliance, but focus on single aspects like checking arc-hitectural layer structures in code.

Instead of checking the compliance between the ar-chitecture and the design or implementation one could argue using Model-Driven Development (MDD) [14] approaches would solve the problem. Thereby, models on different levels of abstraction and (semi-)automatic transformations between them can be used to refine an abstract model, like the architectural model, to a more specific model, like the design model, and finally gen-erate parts of the implementing code. If the transforma-tions preserve the architectural semantics the final de-sign and implementation is compliant with the in-tended architecture.

This approach does not really solve the problem: For instance, one abstraction the architectural model

provides is that it is an intensional model [6]. To gen-erate the concrete design model elements out of the architectural model, it would have to be an extensional model and, thus, would not provide a higher abstrac-tion level. Furthermore, since a transformation into a refining design model cannot be complete, we would have to check the architectural compliance after ma-nual changes anyway.

For that reasons we claim an approach to support architectural compliance checks between the intended architecture or reference architecture and the design and implementation of enterprise applications. The architectural compliance check is part of an overall enterprise architecture management approach.

The required tool support for architectural com-pliance checks must consist out of the following basic building blocks (see fig. 1): • A formal notation to represent the intended archi-

tecture or reference architecture. • A formal notation to represent the design or im-

plementation of the application. • A formal notation to represent mappings between

intended architecture and design/implementation. • A compliance checking technique based on the

representations of architecture, design, and map-ping.

This paper tackles these issues and introduces a rule-based approach to compliance checking. It was applied and evaluated in an industrial case study, in which the approach was used to check whether the implementation of a real-life enterprise application was compliant to a given reference architecture.

The remaining paper is structured as follows. Sec-tion 2 introduces the foundations of the proposed ap-proach. The industrial case study and the related expe-riences are described in section 3. Section 4 gives an overview of related work. Section 5 concludes the pa-per.

2. The approach at a glance

This section introduces the proposed approach to

rule-based architectural compliance checking. It bases on formal representations of architecture and design descriptions as logical knowledge bases. After an overview of the overall approach and its foundations, the formal representations will be described. The sec-tion ends with a description of the compliance check-ing technique and its prototypic implementation.

Figure 1. The different descriptions of the ap-proach and the formal representations

2.1 Overview and foundations

Common sense in the understanding of an architec-tural description is its task to describe the architectural building blocks and their connections and the prin-ciples that guide the further design and evolution of the system (see sec. 1). These principles can be seen as constraints for further descriptions that are only valid refinements if they obey the constraints of the more abstract description.

The constraints, that such a description defines, normally have free variables which are assigned to concrete objects of a semantic domain for which the constraints have to hold. Usually, that domain is infi-nite, and so are the possible valid assignments. Eden and Kazman [6,7] call such descriptions intensional and show that architectural descriptions (they use the term architectural specification instead) are intension-al.

For example, consider an architecture description that describes a system that is architecturally divided into two layers llower and lupper (see fig. 1). It might con-strain a Java implementation in that way that classes in packages representing llupper (p1, p2) might import classes from packages representing llower (p3) but not vice versa. Figure 1 shows a graphical design descrip-tion for Java that violates this constraint because C2 imports C1. Nevertheless, there are infinite many Java programs that obey this constraint, thus the architec-ture description is intensional. On the other hand, we call a description with a finite number of possible im-plementations extensional. In the following, we call the constraints, which an architectural description defines, architectural rules.

Thus, checking architectural compliance means to show whether a design or implementation description (e.g. the code of a system or a UML model of it) ful-fills the architectural rules of the architecture descrip-tion. In our approach, we use first-order logic to represent the architecture and design description ele-ments and the architectural rules as well. Figure 1 illu-strates the proposed approach. It bases on a description triple – the architecture and design descriptions whose compliance has to be checked and, in addition, a map-ping description. The latter relates elements from the architecture description to elements of the design de-scription, e.g. packages that are assigned to layers. It has to be created by the software architect before the compliance check can be executed. Every of the three descriptions is represented as a single logical know-ledge base which contains facts (and potentially logical rules) representing the single elements of the descrip-tions. Additionally, the architectural knowledge base comprises rules that reflect the intensional character of

the architecture description. It contains rules with free variables that can be instantiated with objects from the union of the knowledge bases. If all of these rules are satisfied for a given triple of descriptions as described above, meaning that the rules hold on the union of the knowledge bases, the design description is said to be compliant to the architecture description.

2.2 Formal representation of architecture de-scriptions

As mentioned in section 2.1 the architecture de-scription is represented as logical knowledge base con-sisting of logical facts and logical rules. While the facts represent (in an extensional manner) the existing elements in that description, the architectural rules define constraints upon the triple of descriptions de-picted in figure 1. For the sake of brevity, the available predicates are restricted to those that are necessary for the case study in section 3. Therefore, we will consider layers [9] and allowed dependencies relations, which define that dependencies may only exist between ele-ments of certain layers. Layers are identified by unique identifiers. Instances of those predicates are depicted in the lower left part of figure 1.

The architectural rules that are imposed by an archi-tectural description upon a design description are ex-pressed as logical rules that have to hold upon the un-ion of knowledge bases of architecture, mapping, and design descriptions. The predicates we can use to for-mulate these rules depend therefore partially upon the kind of design descriptions. We defer a detailed de-scription of the rule definitions to section 3, after the representation of design descriptions is introduced. 2.3 Formal representation of design descrip-tions

To transform design models into logical knowledge bases, the available predicates have to be known. For example, consider UML models as design descriptions [15]. The information that the UML element “Class” is transformed into a unary predicate “Class(?x)” (?x being a placeholder for an identifier) has to be known before a specific class “Book” can be transformed into a corresponding fact “Class(2)”, whereas “2” identifies the class “Book” (see figure 3). As one can see, that information about the available predicates can be de-rived from the meta model.

The left part of figure 2 shows a small cutout of the UML meta model that depicts how “Classes” can be connected by “Associations”. “Class” is a specializa-tion of “Classifer”, “Type”, and “NamedElement”

from whose it inherits meta attributes or meta associa-tions like “name” from “NamedElement”. The connec-tion between classes and associations is defined in the meta model by “Property”. On the one hand, a proper-ty is used to model attributes of classes. On the other hand it can represent an association end. In this case, it is owned by an instance of “Class” and is referred to by an instance of “Association”, or just the other way around. These alternatives are modeled by the two meta associations between “Property” and “Associa-tion”.

From this meta model cutout logical predicates and rules can be derived systematically. The relevant ele-ments to capture structural properties of an instance of this meta model, a specific UML model, are the meta classes and their properties, namely meta attributes and meta associations. For each meta class, we can define a unary predicate, e.g. Association/1, which is true, if and only if the argument is an instance of that class. Furthermore, the generalization structures between meta classes are reflected by logical rules of the form ClassGen(?x) :- ClassSpec(?x) indicating that if ?x is an instance of “ClassSpec” it is also an instance of “ClassGen”.

Meta attributes are represented as binary predicates. A predicate <class>_<attr>(?c,?value) is true, if and only if the instance “c” of “Class” has its attribute “attr” allocated with the value “?value”. Meta associ-ations are represented by defining binary predicates for their ends. <class>_<assocEnd>(?c,?d) is true, if and only if the instance c of “Class” is connected with an instance d (of some other meta class) by an associa-tion so that d plays the role indicated by “assocEnd”.

The right part of figure 2 shows the according pre-dicates and rules for the UML meta model cutout de-picted in the left part. There are seven unary predicates for the meta classes of the cutout. The rules reflect the specialization relationships. For the meta attribute “name” of “NamedElement” a predicate namedEle-ment_name/2 exists, for the meta association end

likewise, e.g. class_ownedAttribute/2 or prop-erty_class/2.

Figure 3 shows in the left part a small UML model in its concrete syntax as class diagram and aside as an object diagram showing its abstract syntax. Two classes “Author” and “Book” are connected by an as-sociation “wrote”. Simplified, this leads to five in-stances of meta classes: two classes, one association and two properties representing the association ends.

The predicates, which represent the meta model of UML, can now be used to create facts for this specific model (see right part of figure 3). It is assumed that we can uniquely identify the model elements. For every instance of a meta class a corresponding fact, like Class(1) for the class “Book”, is created. According-ly, their instances of meta attributes are represented, like for example namedElement_name(1,“Book”). Please notice, that it is possible by the defined rules to identify the class “Book” as an instance of “Named-Element”.

The connection between the instances is represented by facts according to meta association ends. For exam-ple, the ends of the association (id 4 and 5 in figure 3) are connected with the association (id 3) by the facts association_memberEnd(3,4) and associa-tion_memberEnd(3,5).

2.4 Formal representation of mapping descrip-tions

Assuming, that the architecture descriptions look like introduced in section 2.2 and that design descrip-tions are models written in UML (see sec. 2.3), we are able to define some very simple mapping description that determine, e.g how layers are mapped to UML elements of the design description. Packages are mapped to layers – if the package p is interrelated to a layer l by a mapping, elements that are contained in p or in one of its direct or indirect subpackages are also assigned to l. Since layers have unique identifiers (see

Class

PropertyisReadOnly : Boolean

Association

owned‐Attribute

class

0..10..*

association

type2..*

0..1

Classifier

Type

NamedElement

name : String

ownedEnd{subsets 

memberEnd}0..*

0..1

0..1memberEnd

Class/1, Classifier/1, Type/1, NamedElement/1, Property/1, TypedElement/1, Association/1

NamedElement(?x) :- Type(?x).Type(?x) :- Classifier(?x).Classifier(?x) :- Class(?x).TypedElement(?x) :- Property(?x).

namedElement_name/2isReadOnly/2

class_ownedAttribute/2 property_class/2property_association/2typedElement_type/2association_memberEnd/2association_ownedEnd/2

TypedElement

Figure 2. A cutout of the UML meta model and corresponding logical facts and rules

sec. 2.2) and UML packages have a unique qualified name (see [15]), both are unambiguously identifiable. Thus, a mapping between a layer and a package can be defined by a binary predicate (exemplary depicted in fig. 1). This mapping is necessary to formulate the architectural rules, as one will see in section 3.

2.5 Compliance Checking Technique and pro-totypical implementation

The knowledge bases generated from the descrip-tions (see fig. 1) can now be used to check whether the architectural rules defined by the architectural descrip-tion hold. The union of the knowledge bases can be interpreted as a program written in a logical program-ming language like Prolog. The checking of architec-tural compliance is thus technically realized as execut-ing the architectural rules as queries upon the union of knowledge bases. For user convenience, we classify architectural rules into prerequisite rules and con-straint rules. Prerequisite rules hold if their execution as query is successful, this means there is at least one result. Constraint rules hold if their execution as query returns no result. The distinction has practical reasons. By the use of constraint rules we are not only able to detect whether an architectural rule does not hold but also to detect the elements that cause a rule violation, since the corresponding query results would give in-formation about the violation. Examples of both kinds of rules will be illustrated in section 3.

The approach was prototypically implemented as Eclipse plugin in [16]. The prototype was developed to generally query structural properties of a UML model that is represented as knowledge base. It is able to gen-erate facts from a given UML model, for instance a design model, and to load user defined facts and rules, for example derived from an architecture description. After loading and generating all necessary information, the user can execute predefined queries upon the knowledge base or create new queries himself and execute them – for example queries consisting of the architectural rules of an architecture description. As query language and engine, a prolog-like programming

language system named TyRuBa is used (introduced in [17]). Figure 4 shows a screenshot of the query dialog where the user can execute arbitrary queries. The de-picted query, for example, determines all classes with their names from the loaded model. After execution, the result of the query is presented in a separate view (see lower part of figure 4).

In addition to the query engine the prototype in-cludes two subsystems: a meta model transformer and a model transformer. The meta model transformer ge-nerates predicate definitions for TyRuBa out of an arbitrary meta model which is loaded as an Ecore file by the EMF framework [18]. The model transformer generates facts for a given UML model which is avail-able as XMI file. To generate the facts for the UML model, the transformer uses the predicate definitions that were generated by applying the meta model trans-former to the UML meta model. During the model transformation the whole model is traversed and facts for model elements (instances of meta classes) and instances of meta attributes and meta associations are created. The values of the corresponding predicate parameters are read from the model.

Figure 3. A specific UML model and corresponding facts

Author

Book

1

2

3

4

5

wrote

: Classname=“Author”

: Association

name = “wrote”

: Property

: Property

1

3

5

4

Class(1). Class(2). Association(3). Property(4). Property(5).namedElement_name(1, “Author”). namedElement_name(2, “Book”). namedElement_name(3, “wrote”).class_ownedAttribute(1,5).class_ownedAttribute(2,4).property_class(5,1).property_class(4,2). association_memberEnd(3,4).association_memberEnd(3,5). property_association(4,3). property_association(5,3).typedElement_type(2,1).typedElement_type(5,2).

type

type

: Classname=“Book”

2

Figure 4. Screenshot of the prototypical tool implementation

3. Case study

This section first describes the environment in which the presented approach and prototype were ap-plied to evaluate the underlying concepts introduced in section 2.1 to 2.4. As example of use the architectural rule concerning the layered architecture is formulated in terms of logical facts and rules and executed against the design description. This design description is UML-based and is conform to the Java-based imple-mentation. Finally we sum up our results and discuss possible reasons for the identified architectural viola-tions.

3.1 Setting and architecture

Our experiences applying the above described ap-proach are taken from an industrial cooperation project as part of a process for quality assurance. This part was intended to check the implementation of a medium-sized information system developed by an extern ser-vice provider against the agreed logical reference ar-chitecture. However, a satisfying concept and tool support had not existed so far.

The considered system is, according to the layers pattern, subdivided into different layers (see fig. 5). Like a usual information system, it consists of a part containing the application logic (layer application core), a part handling the data access (layer persis-tence) and a part providing functionality for user inte-raction (presentation and client) or interaction with external applications (web services). In figure 5 layers are depicted as boxes and allowed dependency rela-tions as arrows, while used layers are located at the arrowheads and using layers at the ends.

According to the mentioned layer architecture sev-eral architectural rules the considered system has to obey can be identified. The first rule follows straight from the layered architecture: if layers and dependen-cies between these layers are defined, the design de-scription and the corresponding program code have to fulfill these constraints. At this point we can directly

attach a second rule: Before checking for compliance with the layered architecture there has to be assigned components/packages to each layer. Following the notation introduced in section 2.5 the first rule is a constraint rule and the second one a prerequisite rule. 3.2 Required architecture and mapping facts

The queries corresponding to the before mentioned architectural rules are formulated using the information in the knowledge bases regarding existing layers, as-signed packages, and allowed dependencies between these layers. This information is represented by facts using the predicates layer/1, allowedDependen-cy/2 and assignPkgToLayerByQualifiedName/2, whereas the first two belong to the architecture de-scription and the third to the mapping description. E.g., the fact layer("applicationcore") indicates that applicationcore is a layer’s name. Furthermore, allowedDependency("presentation","appli-cationcore") expresses that dependencies from presentation to applicationcore are allowed. To fill the layers with “life”, e.g. assignPkgToLa-yerByQualifiedName("org::anonymous::ad-ministration","applicationcore") assigns package org.anonymous.administration from the design description to layer applicationcore. Such packages which are directly assigned to a layer are called layer packages here. In contrast to the archi-tecture and mapping description the design description bases on the UML meta model which allows to auto-matically generate appropriate predicates and facts using the prototypic tool introduced in section 2.5.

3.3 Defining the logical rules

To formulate the aforementioned architectural rules

in terms of logic programming some logical auxiliary rules are helpful which will be defined in the follow-ing. Every dependency connects two elements of the design description, whereas each element belongs to a layer package. These elements and the corresponding layers are required to identify whether a dependency violates the layered architecture or not. Elements are arranged in packages which in turn are elements, too. To examine the layer which an element belongs to, the containing package is iteratively identified until a layer package is reached. The easiest case is the one in which the element itself is a layer package. In listing 1 this fact is expressed with the first elementInLay-er/2. The second elementInLayer/2 describes the other case, in which the considered element lies some-where inside the hierarchy beneath the layer package. First, the element’s surrounding package (ele-

Figure 5. The layered reference architecture of the considered system in the case study

clientutility

presentationweb services

application core

persistence

ment_owner/2) has to be identified and then the package hierarchy is navigated upward until a layer package was found (isSubpackageOrTheSame/2, packageIsLayer/2). The logical rule defined by packageIsLayer/2 evaluates whether a package corresponds to a layer. Used as a query with fixed layer package this rule returns the related layer; but only if an existing logical fact has assigned this pack-age to a layer before.

Between two elements various kinds of dependen-cies might be exist:

• Directed relations. Thinking about directed relations for descriptions corresponding to ja-va code mainly generalizations, interface im-plementations, and package imports have to be considered.

• Associations. Associations are often specified with a direction of navigation between its as-signed classes or interfaces.

• Attributes. Attributes of classes can be typed by other elements of the design description, like classes or interface.

• Operation parameters. Operations may have call or return parameters whose types refer to other elements of the design description.

To examine the dependencies used in the design de-scription a logical rule was formulated for each above mentioned case. The first alternative of elementDe-pendsOn/2 in Listing 2 covers directed relationships. The element ?fromEl depends on ?toEl if a directed dependency (EXISTS ?dep) with source ?fromEl and target ?toEl exists. After finding a result logical resolution tries to find more results by using backtrack-ing. Therefore, the expression EXISTS ?dep forces the evaluation to stop after finding one dependency.

Associations and classes are connected with each other by association ends. An association end is owned either by a class or by the association itself. These two cases regarding the ownership have to be distinguished and mapped on adequate logical rules as they are de-picted in Listing 2 at the second and third position. The

second alternative of elementDependsOn/2 de-scribes the case that the ownership of the association end belongs to the association. In reference to the UML meta model [15] association ends are instances of the meta element property (Property/1). Now, there is a dependency from ?fromEl to ?toEl if they are classifiers (Classifier/1) , like classes or inter-faces, and at least one association (Associa-tion(?dep)) between them exists. The choice of re-levant association ends (?fromEnd and ?toEnd) is limited to following constraints: ?toEnd has to be na-vigable and owned by the association (associa-tion_navigableOwnedEnd/2), and the property ?fromEnd is owned by the association ?dep (pro-perty_association/2). Finally, the type of both association ends is identified (typedEle-ment_type/2).

If a class holds the ownership of an association end (third alternative of elementDependsOn/2), the ele-ment ?fromEl has to be a class which owns the asso-ciation end ?toEnd (property_class/2). Finally, ?toEnd has the type of classifier ?toEl which leads to the depending of ?toEl on ?fromEl. Attributes are also instances of the UML meta model element proper-ty. Since they are therefore modeled similar to associa-tion ends, the third alternative of elementDepends-On/2 also covers dependencies due to attribute types.

Call or return parameters in operations may also cause dependencies. To detect such dependencies from classifier ?fromEl to ?toEl the fourth alternative of elementDependsOn/2 in listing 2 was formulated. If an operation ?op exists which belongs to ?fromEl (feature_featuringClassifier/2), and further,

elementDependsOn(?fromEl,?toEl) :- Element(?fromEl), Element(?toEl), (EXISTS ?dep : DirectedRelationship(?dep), directedRelationship_source(?dep,?fromEl), directedRelationship_target(?dep,?toEl)). elementDependsOn(?fromEl,?toEl) :- Classifier(?fromEl), Classifier(?toEl), (EXISTS ?dep,?fromEnd,?toEnd : Association(?dep), Property(?toEnd), Property(?fromEnd), association_navigableOwnedEnd(?dep,?toEnd), property_association(?fromEnd,?dep), typedElement_type(?toEnd,?toEl), typedElement_type(?fromEnd,?fromEl)). elementDependsOn(?fromEl,?toEl):- Classifier(?fromEl), Classifier(?toEl), (EXISTS ?toEnd : Property(?toEnd), property_class(?toEnd,?fromEl), typedElement_type(?toEnd,?toEl)). elementDependsOn(?fromEl,?toEl):- Classifier(?fromEl), Classifier(?toEl), (EXISTS ?op : Operation(?op), feature_featuringClassifier(?op,?fromEl), (EXISTS ?p : Parameter(?p), parameter_operation(?p,?op), typedElement_type(?p,?toEl))).

Listing 2. Definition of logical rules to check, if dependencies between two elements exist

packageIsLayer(?pkg,?layer) :- Package(?pkg), layer(?layer), packageByQualifiedName(?pkg,?pkgName), assignPkgToLayerByQualifiedName(?pkgName,?layer). elementInLayer(?el,?layer) :- Package(?el),packageIsLayer(?el,?layer). elementInLayer(?el,?layer) :- element_owner(?el,?nestingPkg), isSubpackageOrTheSame(?nestingPkg,?layerPkg) packageIsLayer(?layerPkg,?layer).

Listing 1. Definition of logical rules to assign packages to layers and check whether an ele-

ment belongs to a layer

if this operation has an parameter ?p whose type is ?toEl, the classifier ?fromEl depends on the classifi-er ?toEl. Executing elementDependsOn/2 as query with both parameters unbound, returns all known de-pendencies whether they are allowed or illegal.

A further logical auxiliary rule composes above de-fined predicates to find all existing dependencies (equal whether allowed or illegal) with involved ele-ments between two layers. This is accomplished by layerDependency/4 in listing 3. If two elements ?toEl and ?fromEl depending on ?toEl exist (ele-mentDependsOn/2) which lie in ?toLayer and ?fromLayer respectively (elementInLayer/2), then a dependency from ?fromLayer to ?toLayer exists. The predicate layer/1 confirms that the para-meters ?fromLayer and ?toLayer represent layers. The predicate illegalLayerDependency/4 (see lis-ting 3) tests each located dependency whether it is not allowed. Therefore, the expression NOT(allowedDe-pendency/2) is used.

According to section 2.1 and figure 1 the informal described architectural rules at the beginning of this section represents the intensional part of the architec-ture description. They can be noted formally by using the above defined logical (auxiliary) predicates. Leav-ing all variables free in illegalLayerDependen-cy/4, leads to the first mentioned rule regarding the compliance with the layered structure. The second rule, regarding the assignment of packages to layers, can be formulated by leaving the first parameter (for package) free in assignPkgToLayerByQualifiedName/2. For example, the query assignPkgToLayerByQua-lifiedName(?p,"applicationcore") returns all layer packages assigned to the layer "application core".

3.4 Results

The proposed approach for compliance checking was executed against a design model concluding about 1,600 classes and interfaces. As mentioned above the model represents the Java-based implementation which consists of about 130,000 lines of code. From the de-sign model about 30,000 logical facts were generated. The prototypic tool (see sec. 2.5) found some viola-tions regarding the compliance of the layered architec-ture, which are visualized in figure 6. The darker ar-

rows identify the violations and the numbers at each end of the arrows inform about the quantity of the layer’s involved classes or interfaces.

Additional, we were able to identify the precise classes and investigated the reasons for these viola-tions in more detail: A lot of violations between the presentation layer and the client result from using ob-jects for the transportation of data between these layers by data transfer objects [19]. These objects were de-fined inside the client and were used by the presenta-tion layer. Maybe it is a better solution to move the definitions to the presentation layer. The violations between application core and client appear due to a kind of searching functionality that was implemented in the client layer. The utility layer contains security functionality which accesses the persistence layer and therefore produces violations. Some violations are caused by imports which are used to realize callbacks, like needed for the observer pattern. The latter was found between application core and web services. 3.5 Lessons learned and future work

The case study and the requirements of the partici-pating partners show that architectural compliance checks in the field of enterprise application systems are highly necessary. The partners confirmed the useful-ness of the approach because of the rapid feedback produced by the prototype. The results of the checks were very helpful to identify conceptual design errors or errors made in haste that the participating architects were not even aware of. Executed in regular intervals, those checks would have been able to prevent those errors. It also showed that the formalism was efficient,

layerDependency(?fromLayer,?toLayer,?fromEl,?toEl) :- layer(?fromLayer), layer(?toLayer), elementInLayer(?fromEl,?fromLayer), elementInLayer(?toEl,?toLayer), elementDependsOn(?fromEl,?toEl). illegalLayerDependency(?fromLayer,?toLayer,?el1,?el2) :- layerDependency(?fromLayer,?toLayer,?el1,?el2), NOT(allowedDependency(?fromLayer,?toLayer)).

Listing 3. Definition of logical rules to get all dependencies with involved elements between two layers and identify violations of allowed dependencies

Figure 6. Number and locations of architectur-al violations detected in the case study

7

clientutility

presentationweb services

application core

persistence7

8

52029

4

2

~50~100

at least for the size and complexity of the system under investigation. A complete check whether the design description was compliant to the layers of the logical architecture took about 90 seconds on a common desk-top PC. The creation of a corresponding knowledge base took about 5 minutes. Thus, the complete process could easily be integrated into an automatic, regularly executed process like a nightly build of the project. Of course, more detailed performance analysis, especially for larger systems have to be made. Eventually, this may lead to more efficient but less expressive formal-isms like description logics [20], which are less com-putationally complex.

Furthermore, our partners found the declarative way of defining architectural rules, after some initial fami-liarization, easy to understand. Anyway, the approach has to be further elaborated w.r.t. architectural rule definitions because it is an error-prone task yet. Small details in the rule bodies can lead to execution times higher by magnitudes. A first version of the third alter-native of elementDependsOn/2 (see listing 2), which additionally tested for the existence of a connecting association instance leads to execution times of hours. Further work will focus on a meta model for descrip-tions for which the underlying knowledge base will be generated automatically.

Additionally, the approach is very flexible w.r.t. the kind of rules and documents that have to be checked. It was also used to formulate rules that check whether the design description (which reflected the Java code structure) was properly structured into components. Beside design descriptions, many different artifacts exists in practice, in which architectural rules should be enforced, for example, configuration documents like XML files for frameworks like Spring [21] or Hi-bernate [22]. For example, it might be necessary to define that Hibernate mapping files may only refer to classes in the persistence layer. Facts of those artifacts can be easily added to the knowledge base by defining corresponding predicates and facts. [16] describes how predicates can be automatically generated, independent of any specific meta model. However, in the case of adaption for other descriptions and artifacts, it might be necessary to adapt the architectural rules. If these changes are too complex, it would be a drawback to adaptability. 4. Related Work

In section 1, the work of Eden and Kazman [6,7] was already mentioned, which bases on similar thoughts as the approach proposed by this paper. How-ever, their approach bases on the assumption that there

is a common semantic foundation of all specification languages, namely design models [7]. Whether these are always adequate in practice for arbitrary descrip-tion techniques and artifacts must be further elabo-rated.

Related work regarding architectural compliance checking can be found in the field of consistency man-agement for models, an overview for UML models can be found in [23]. There exist numerous approaches to consistency management and checking consistency between arbitrary models. For example, [24] proposes an approach based on Communicating Sequential Processes (CSP), which might be more appropriate for behavioral consistency aspects. Other approaches are based on graphs and graph transformations, as for ex-ample [25] and [26]. However, examples mostly do not deal with the consistency or views on the same or a similar level of abstraction, and not with consistency towards an intensional model.

There are also approaches that deal specifically with the consistency of architecture and design models. For example, [27] deals with checking architectural fea-tures in component diagrams by using description log-ics. Contrarily, [28] uses the same logics to detect de-sign inconsistencies. Egyed, for example, outlines an approach in [29] for consistency checking between C2 ADL [30] architecture descriptions and refining UML high-level designs. For this approach holds the same limitation as for other Architecture Description Lan-guages [31]: they do not provide description tech-niques with intensional character.

On the implementation level, there are similar ap-proaches applying logic programming concepts. [32] describes the application of Prolog to query arbitrary models. It is not explicitly applied to architecture mod-els of enterprise applications, but has similar founda-tions as our approach. 5. Conclusion

The experiences from the case study presented here, the results, and the lessons learned show that architec-tural compliance checking is an important but difficult task for EAM and an important part for the assurance of the quality of enterprise applications.

A rule-based approach can provide enough flex-ibility to tackle this task. A (software) architecture does not only consist of layers but has many aspects that are relevant w.r.t. compliance checks. For that reason, the user (the software architect) should be able to define his own, customized rules. This is possible with the proposed approach.

The case-study also shows that the use of logic pro-gramming concepts is an appropriate founding formal-ism. However, its potential will be fully exploited when it is possible to define architectural rules by models like UML models that are common to software architects and to hide the logic-based formalism.

To further develop the approach, we will investigate how a meta model for architecture descriptions should look like that truly reflect the intensional characteris-tics of software architectures. Furthermore, the appli-cation to larger and more complex case studies will be useful to investigate whether the approach scales well or whether a change towards less expressive logics like description logic might be reasonable. Last but not least, we will identify more useful architectural rules in the field of enterprise applications to support control-ling and managing their architecture and, thus, to help assuring their quality. References [1] Software Engineering Institute (SEI), Carnegie Mellon University, How Do You Define Software Architecture?, 2009. http://www.sei.cmu.edu/architecture/definitions.html [2] The Institute of Electrical and Electronics Engineers, Recommended Practice for Architectural Description of Software-Intensive Systems, ANSI/IEEE Std 1471-2000. [3] D. Garlan and M. Shaw, An Introduction to Software Architecture, Technical Report, Carnegie Mellon University, Pittsburgh, PA, 1994. [4] D. Garlan and D. Perry, “Introduction to the Special Issue on Software Architecture”, IEEE Transactions on Software Engineering, Vol. 21(4), IEEE Press, 1995, pp. 269-274. [5] L. Bass, P. Clements, and R. Kazman, Software Architec-ture in Practice (2nd Edition), Addison-Wesley, 2003. [6] A. H. Eden and R. Kazman, “Architecture, design, im-plementation”. Proc. of the 25th Int. Conf. on Software Engi-neering (ICSE), IEEE Computer Society, 2003. [7] A. H. Eden, Y. Hirshfeld, and R. Kazman, “Abstraction classes in software design”, IEE Proceedings - Software, Vol. 153(4), Institution of Electrical Engineers, London, UK, 2006, pp. 163-182. [8] P. Bernus, L. Nemes, and G. Schmidt, Handbook on En-terprise Architecture, Springer, 2003. [9] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad and M. Stal, Pattern-Oriented Software Architecture Vol. 1: A System of Patterns, John Wiley & Sons, Chichester, UK, 1996. [10] M. Bennicke, W. Bischofberger, and F. Simon, “Eclipse auf dem Prüfstand: Eine Fallstudie zur statischen Programm-analyse”, in German, OBJEKTspektrum, Sigs Datacom, 2003, pp. 22-28. [11] F. Salger, M. Bennicke, G. Engels, and C. Lewerentz, “Comprehensive Architecture Evaluation and Management in Large Software Systems”, Proc. of the 4th Int. Conf. on the Quality of Software Architectures, Springer, 2008.

[12] hello2morrow, SonarJ Webpage, http://www.hello2morrow.com/products/sonarj [13] 72miles, Architecture Rules Webpage, http://72miles.com/architecturerules/ [14] M. Völter and T. Stahl, Model-Driven Software Devel-opment, Wiley & Sons, Chichester, UK, 2006. [15] Object Management Group (OMG), Unified Modeling Language (UML) 2.1.2 Superstructure Specification, 2007. [16] P. Dohrmann, Conception and Realization of a Logic-based Query Tool for UML Models, Diploma Thesis (in German), Clausthal Univ. of Technology, Germany, 2009. [17] K. de Volder, Type-Oriented Logic Meta Programming, Ph. D. Thesis, Vrije Univ. Brussel, Brussel, Belgium, 1998. [18] D. Steinberg, F. Budinsky, M. Paternostro, and E. Merks, Eclipse Modeling Framework (2nd Ed.), Addison-Wesley, Upper Saddle River, USA, 2008. [19] M. Fowler, Patterns of Entprise Application Architec-ture, Addison-Wesley Longman, Amsterdam, The Nether-lands, 2002. [20] F. Baader et al (Publ.), The Description Logic Hand-book: Theory, Implementation, and Application, Cambridge University Press, Cambridge, UK, 2007. [21] C. Walls and R. Breidenbach, Spring in Action, Man-ning, Greenwich, UK, 2007. [22] D. Minter and J. Linwood, Pro Hibernate 3, Apress, Heidelberg, Germany, 2005. [23] M. Elaasar, L. Briand, An Overview of UML Consisten-cy Management, Technical Report, Carleton University, Ottawa, Canada, 2004. [24] G. Engels, R. Heckel, J. Küster, “Rule-Based specifica-tion of behavioral consistency based on the UML meta-model”, Proc. of the Int. Conf. on UML 2001, LNCS 2185, Springer, 2001. [25] H. Ehrig, A. Tsiolakis, “Consistency Analysis of UML class and sequence diagrams using attributed graph gram-mars”, ETAPS 2000 workshop on graph transformation sys-tems, 2000. [26] S. Becker, S. Herold, S. Lohmann, B. Westefechtel, “A graph-based algorithm for consistency maintenance in in-cremental and interactive integration tools”, Software and Systems Modeling, Vol. 6(3), Springer, pp. 287-315, 2007. [27] J. Simmonds, M. Bastarrica, “Description Logics for Consistency Checking of Architectural Features in UML 2.0 Models”, Technical Report, Universidad de Chile, 2005. [28] R. v.d. Straeten, T. Mens, J. Simmonds, V. Jonckers, “Maintaining Consistency between UML Models Using De-scription Logic”, Proc. of the Int. Conf. on UML 2003, LNCS 2863, 2003. [29] A. Egyed, “Validating Consistency between Architec-ture and Design Descriptions”, Proc. of 1st Workshop on Evaluating Software Architecture Solutions, 2000. [30] R. Taylor, N. Medvidovic, K. Anderson, E. Whitehead et al., “A Component- and Message-based Architectural Style for GUI Software”, IEEE Transactions on Software Engineering, Vol. 22(6), IEEE, pp. 390-406, 1996. [31] N. Medvidovic, R. Taylor, “A Classification and Com-parison Framework for Software Architecture Description Languages”, IEEE Transactions on Software Engineering, Vol. 26(1), IEEE, pp. 70-93, 2000.