DictōKeeping Software Architecture Under Control

Andrea Caracciolohttp://scg.unibe.ch/staff/caracciolo

DADA ’14 @ ECSA

Architectural Rules

�2

“Repository interfaces can only declare methods named find..()”!

"“The rendering operation has to be

completed in less than 4ms”!"“Only Service classes are allowed to

throw AppException” !

Architectural Rules

�3

“Repository interfaces can only declare methods named find..()”!

"“The rendering operation has to be

completed in less than 4ms”!"“Only Service classes are allowed to

throw AppException” !

Naming Conventions

Architectural Rules

�4

“Repository interfaces can only declare methods named find..()”!

"“The rendering operation has to be

completed in less than 4ms”!"“Only Service classes are allowed to

throw AppException” !

Performance

Architectural Rules

�5

“Repository interfaces can only declare methods named find..()”!

"“The rendering operation has to be

completed in less than 4ms”!"“Only Service classes are allowed

to throw AppException” !

Dependencies

Architectural Rules

�6

“Repository interfaces can only declare methods named find*()”

public interface RepositoryI .. { /** * .. */}

?

Rule Validation

�7

xml

java

uml

Rule Validation

�8

xml

java

uml

Multiple "spec. languages

Rule Validation

�9

xml

java

uml

Poor functionality

Poor usability

Concrete Example

�10

Model Database

UtilView

Model Database

UtilView

org.app.Model must depend on org.app.Database!org.app.Database must depend on org.app.Util!org.app.Model cannot depend on org.app.View!org.app.Util cannot depend on org.app.Database

The web service must answer user requests within 10ms.

Concrete Example

�11

The architect plans to ensure the first requirement bystrictly separating the user interface, the business logic, andthe persistent data. To ensure this separation and validatethe second requirement, she defines the following rules onher Java implementation:

R1a. org.app.Model must depend on org.app.Database

R1b. org.app.Database must depend on org.app.Util

R1c. org.app.Model cannot depend on org.app.View

R1d. org.app.Util cannot depend on org.app.Database

R2a. The web service must answer user requests within10ms.

Such rules have been encountered multiple time during aprevious on-the-field study [3] and can therefore be consid-ered representative for the architect’s needs.

To verify those rules, we organized a small experimentinvolving five tools. The rules were tested on an implemen-tation complying to R1a, R1d and R2a, but not to R1b andR1c. The violation of rule R1b is commonly defined in lit-erature as an absence (the model prescribes a dependencythat does not exist in the source code). The violation of R1cis called a divergence (a dependency that is not included inthe model actually exists in the source code).

The results are summarized in Table 1.

Rule T1 T2 T3 T4 T5

R1a: Model ! Database X � X N/A �R1b: Database ! Util X � X N/A �R1c: Model ! View � � � N/A �R1d: Util ! Database � X � N/A �R2a: RT < 10ms � � � � X

Table 1: Five constraints (rows) have been tested us-

ing five tools (T1: Dependometer; T2: Classcycle;

T3: JDepend; T4: Macker; T5: JMeter). Testing

outcome can be: X(successfully tested), �(wrong re-

sult), � (rule type not supported), N/A (tool could

not be operated)

As we can see, none of the selected tools was able to verifyall defined rules. We also observed that:

• Dependometer (T1) didn’t o↵er su�cient guidelines fordefining dependency rules. The most helpful piece ofinformation that helped us setting up the experimentwas a poorly commented XML template containing alarge number of parametrized options.

• Classcycle (T2) reported a wrong result for R1c anddidn’t raise any error when attempting to test for adependency involving a non-existent package.

• JDepend (T3), one of the most popular dependencytesting tools, also revealed some shortcomings. Thistool not only requires us to specify each single packageof the analyzed system, but also fails without expla-nation when the user forgets to do so. This importantfact appears to be undocumented and forces the userto write needlessly long test specifications.

• Macker (T4) could not be correctly configured and of-fered very poor configuration.

• JMeter (T5) performed well in our test but, due toits complexity and poor user interface, required us toconstantly refer to the documentation.

Our experiment shows how testing five simple rules mayoften require the user to: install multiple tools; deal withvarious kinds of configuration annoyances; encode rules ac-cording to di↵erent specification models and notations.

3. OUR APPROACH IN A NUTSHELLTo address the issues highlighted in the previous section,

we propose Dicto, a DSL for the specification of architecturalrules. Our approach distinguishes itself from others (seesection 5) in the following three aspects:

1. It has a lightweight and uniform syntax that allows auser to specify a wide range of rule types.

2. It is designed to allow easy integration of specializedthird-party tools for testing user-defined rules on a con-crete system implementation.

3. It supports incremental specification, since it does notrequire a full description of the architecture.

Using Dicto, we can encode the rules defined in section 2as follows:

Model: Component with package="org.app.Model"DB: Component with package="org.app.Database"View: Component with package="org.app.View"Util: Component with package="org.app.Util"App: WebService with url="http://app.com/"

Model must DependOn(DB)DB must DependOn(Util)Model cannot DependOn(View)Util cannot DependOn(DB)App must HaveResponseTimeLessThan(10ms)

Our DSL is built on top of a framework that o↵ers anextension point for developing tool-specific adapters. If suchadapters exist (in our case we would need one for T1, T2,and T5), the individual rules in the above specification areautomatically dispatched to the appropriate backend (i.e.,T1, T2 and T5).An adapter must be able to:

1. Analyze user-defined Dicto rules to generate a testspecification that can be given as input to the adaptedtool;

2. Execute the generated test;

3. Interpret the obtained test result to be able to reportback to the user.

Adapters must declare which kind of rules they are ca-pable of handling. This requires them to specify the mainproperties that rules (e.g., predicate names, number of pred-icates, number of subjects) and subject entities (e.g., entitytype, number of specifiers, negated specifiers) must exhibitin order to be recognized by the adapter.Adapters enable a fully automated verification process

that does not require any further interaction with the un-derlying testing tools. This allows for a good separationbetween conceptual design (i.e., writing rules) and technicalrealization (i.e., developing adapters). Even non-technicalstakeholders can be involved in the specification of rules.

Rule Validation

�12

xml

java

uml

Rule Validation

�13

Rule

:  Website  with  url=“http://www.abc.com/api”

�14

MyService  

MyService   must HandleLoadFrom("10  users")  

MyService   cannot HaveResponseTimeLessThen(“1000  ms")  

MyService   can  only HandleSOAPMessages()  

.  .  .

.  .  .

Rule

:  Website  with  url=“http://www.abc.com/api”

�15

MyService  

MyService   must HandleLoadFrom("10  users")  

Element

Element

Element}

Mapping

�16

X.att1

Y.att2

 }

:  Attribute  with  name=“att*”MyAttibute  

Attribute getElements()

Rule Simplification

�17

Model,    Controller     cannot DependOn(View),    

ContainCodeClones(Test)  

      ʌ       ʌ       ʌ      

  can  only         —> cannot                    

    can     —> cannot    only

Adapter Assignment

�18

<Class>     cannot HaveMethodsNamed(<String>)  

           

Rule Validation

�19

<Class>     cannot HaveMethodsNamed(<String>)  

     

Periodic Validation

�20

     

     

Rule Examples

�21

• Website response time"• Website load testing""

• Dependencies""

• Code clones""

• Deadlock freeness""

• File Content""

grep

Future Work

�22

     

     

     

     

Summary

�23

:  Website  with  url=“http://www.abc.com/api”MyService  

MyService   must HandleLoadFrom("10  users")  

http://scg.unibe.ch/dicto/