by Andrea Caracciolo, Mircea Filip Lungu and Oscar Nierstrasz

Dictō is a declarative language for specifying architectural rules that uses a single uniform notation. Once defined, the rules can automatically be validated using adapted off-the-shelf tools.

Quality requirements (e.g., performance or modifiability) and other derived constraints (e.g., naming conventions or module dependencies) are often described in software architecture documents in the form of rules. For example:

  • “Repository interfaces can only declare methods named ‘find*()’”; or
  • “If an exception is wrapped into another one, the wrapped exception must be referenced as the cause”; and
  • “Entity bean attributes of type ‘Code’ must be annotated with @Type(type = “com.[..].hibernate.CodeMapping”)”.

Ideally, rules such as these should be checked periodically and automatically. However, after interviewing and surveying dozens of practitioners [1], we discovered that in approximately 60% of cases, these architectural rules are either checked using non-automated techniques (e.g., code review or manual testing) or not checked at all. This situation arises because the automated tools currently available are highly specialized and not always convenient to use. Typically, these tools only handle one kind of rule based on various (often undocumented) theoretical and operational assumptions that hinder their adoption. For a practitioner to be able to validate all their architectural rules, they would need to learn about multiple automated tools, conduct experimental evaluations and set up a proper testing environment. This process requires a significant time and resource investment with no evident payoff.

Our approach in a nutshell
Our goal is to enable practitioners to automatically check that their software systems are evolving without straying from previously established architectural rules. To support this idea, we propose that Dictō [2], a unified DSL (domain specific language), could be used to specify the architectural rules, thus allowing them to be automatically tested using adapted off-the-shelf tools.

This proposed approach supports a fully automated verification process, allowing even non-technical stakeholders to be involved in the specification of rules. Once the rules are expressed, their verification can be integrated into the continuous integration system. This ensures the correct implementation of the planned architecture over time and helps prevent architectural decay.

How it works
Using Dictō, an architectural rule such as “The web service must answer user requests within 10ms”can be expressed as “WebService must HaveResponseTime LessThan (“10 ms”)”.

Rules are composed of subject entities and logical predicates. In this example, the subject (“WebService”) is an entity defined by the user, which maps to a concrete element of the system. The predicate (“HaveResponseTimeLessThan”) is formulated to prescribe the expected properties on the specified subjects. To increase expressivity without sacrificing readability, we support four types of rules: must, cannot, only-can and can-only.

Figure 1: Our approach, from the specification of the rules to their testing.
Figure 1: Our approach, from the specification of the rules to their testing.

Dictō rules are parsed and fed to the most appropriate tool through purpose-built adapters (Figure 1). These are plug-ins designed to accept rules that match a specific syntactic structure. The accepted rules are then analyzed and used to generate a valid input specification for the adapted tool. The results obtained from each of the supported tools can eventually be aggregated and used to build an overall report for the user. The adapters are written by tool experts and, by contributing the necessary code to the Dictō project, can be shared with a larger user-base.

The current version of Dictō is capable of testing rules defined over various aspects of a system from observable behaviours (e.g., latency, load or uptime) to implementation (e.g., dependencies or code clones). It features adapters for six different tools (JMeter, JavaPathFinder, PMD, grep, Moose and ping). By collaborating with interested stakeholders, we plan to extend this catalogue of testable rules. This future step will offer invaluable insights into the needs of actual users.

This work has been developed by Andrea Caracciolo (Software Composition Group, University of Bern). It is part of the “Agile Software Assessment” project funded by the Swiss National Science Foundation. The tool is freely available for download on our website (http://scg. and the source code is open under the MIT license. We are interested in both academic and industry collaborations to further develop and assess our approach.


[1] A. Caracciolo, M. F. Lungu, and O. Nierstrasz: “How Do Software Architects Specify and Validate Quality Requirements?”, in Software Architecture, LNCS 8627, p. 374-389, Springer, 2014
[2] A. Caracciolo, M. F. Lungu, and O. Nierstrasz: “Dicto: A Unified DSL for Testing Architectural Rules”, in ECSAW ‘14, ACM, 2014.

Please contact:
Andrea Caracciolo
University of Bern, Switzerland
E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.

Next issue: July 2018
Special theme:
Human-Robot Interaction
Call for the next issue
Image ERCIM News 99 epub
This issue in ePub format
Get the latest issue to your desktop
RSS Feed