Operationalizing Architecture in an agile Software Project

worked on by: ArsenijSolovjev

Expose

One form of technical debt is architectural erosion[1]. As a recent master's thesis[2] has shown, Saros is subject to it. The causes of this haven't been specifically investigated, however I would argue this is an issue of the development process. New developments on Saros are being rigorously reviewed, and sometimes these address technical debt. However, technical debt is not always obvious when it is commited to code, there is no comprehensive overview of technical debt and it is not being addressed systematically.

In my master's thesis I would like to improve the way architectural erosion is handled in the development process by applying the most-established in open-source architecture compliance checking (SonarQube[4]) on Saros. This would contribute to preventing architectural erosion, as well as support architectural changes in Saros. Using SonarQube it is possible to alert the developers of new architectural violations, to find and to inspect pre-existing violations. Also having a formal description of the architecture would ease new developers understand the system. Saros's build-infrastructure would be extended to convey differential architecture-checks upon a commit. This means the source code will be checked for conformance to certain architecture rules. This would be done by integrating SonarQube's architecture rule constraints into the development/build process. For the developer this would result in an additional criteria required to pass a gerrit review. This way a developer would need his patchset to be

• compilable,
• correct according to the unit test suite
• and to additionally conform to the Saros architecture.

It would also be of interest to see how we could use some of the other features of Sonar, some of them overlap with existing build steps inthe current build configuration. Currently Jenkins is responsible for a number of tasks such as computing code coverage, PMD source code analysis and FindBugs. All of these tasks belong to quality assurance, a field in which SonarQube excels, so it will be considered to delegate these tasks to SonarQube. This would leave Jenkins the responsibility to build, communicate with Gerrit, and to delegate to Sonar.

As of now the Saros architecture is documented on its homepage[5], in some theses as well as in the heads of it's developers. An aspiring Saros-developer mightnot be aware of these resources or could simply forget them. After my extension though, he would be forced to see whether his patchset makes sense from an architectural point of view and be forced to act upon that by either changing his patchsetor the architecture itself. The exact behaviour of the developer is unknown, and I would like to evaluate how this change would effect the current development process. Also it is to be evaluated if the effort needed to support this addition to the development process is worthwhile.

There are some obstacles to modifying the infrastructure in the desired manner, which I seek to overcome.

• Saros's architecture is not formulated in a series of formal rules/specification, but rather verbally and graphically[5]. To overcome this, I would consult the existing documentation, some developers, as well as research Saros's commit message history on architectural ideas in Saros. With that knowledge I would proceed to create a basic set of rules, which should be extended and modified by future developers as is seen fit.

• SonarQube's capabilites in terms of defining architecture rules are limited to Sonar's interface. This poses an inconvenience, since if a developer would like to make changes to the architecture rules, he would be forced to use yet another tool in an already difficult process. A more preferable approach would be to have a DSL describing the architecture in the source code itself. This was already done in Anne Augustine's recent master's thesis[3], however her approach is tailored to a specific build infrastructure and cannot be applied to Saros. Hence I would like to investigate the possibilities of extending Sonar to provide this feature (i.e. to be able to make architecture checks on the basis of a specific document within the source code).

• Sonar's capabilities in respect to architecture checking are limited to formulating dependency rules (i.e. allowing/denying access to specific packages and classes). Software architecture has more facets though, as described in Kruchten's 4+1 View Model for instance. I would like to investigate the feasibility of implementing additional levels of architectural formalism and modelling.

This being done, I intend to provide support to a major project within Saros, which involves abstracting Saros away from Eclipse. I believe architectural constraints might provide an overview of Saros's dependencies to Eclipse and would help developers keep them in check.

[1] Dewayne E. Perry and Alexander L. Wolf. Foundations for the study of software architecture. Software Engineering Notes, 17(4):40–52, 1992.

[2] Patrick Schlott. Analyse und Verbesserung der Architektur eines nebenläufigen und verteilten Softwaresystems, FU Berlin, AGSE, 2013.

[3] Anne Augustin. Integration von Architekturmodellen in einen agilen Softwareentwicklungsprozess, FU Berlin, 2013.

[4] SonarQube. http://www.sonarqube.org/

[5] Saros Homepage, architecture documentation page. http://www.saros-project.org/architectureDocumentation

Milestones

Submission Date: 10.10.2014 Weeks: CW16 - CW41

saros.build Infrastructure += Sonarqube

• Migration of code coverage, PMD and Findbugs to Sonarqube, (3 days)
• Saros profile, additional metrics and evaluation. (1 day)

Development process += Architecture as an Artifact

• Differential issue reports (1 week)
• Create DSL to describe layers (0,5 week)
• Teach Sonarqube to use DSL (2,5 weeks)
• ACC are used in development (0,5 week)

Evaluate both of the above

• Develop an approach on how to elicit feedback from current devs
• Collect and reflect on feedback, adjusting process if necessary

Find a language to describe meaningful architectural concepts in Saros

• Literature research on ADLs
• Research on agile architecting (nice to have)
• Research on Saros's architecture through…
• …theses
• …documentation
• …code and git history
• Determine Saros' most important architecture rationales
• Use new knowledge of the essential architectural elements of Saros to better evaluate ADLs and similar.

Implement found language as a DSL

• Find and implement a way for reflexion checking between DSL and code itself

Evaluate, whether this is helpful to the developers