SUMMARY Architecture compliance checking (ACC) is an approach to verify conformance of implemented program code to high-level models of architec tural design. Static ACC focuses on the modular software architecture and on the existence of rule violating dependencies between modules. Accurate tool support is essential for effective and efficient ACC. This paper presents a study on the accuracy of ACC tools regarding dependency analysis and violation reporting. Ten tools were tested and compare d by means of a custom-made benchmark. The Java code of the benchmark testware contains 34 different types of dependencies, which are based on an inventory of dependency types in object oriented program code. In a second test, the code of open source system FreeMind was used to compare the 10 tools on the number of reported rule violating dependencies and the exactness of the dependency and violation messages. On the average, 77% of the dependencies in our custom-made test software were reported, while 72% of the dependencies within a module of FreeMind were reported. The results show that all tools in the test could improve the accuracy of the reported dependencies and violations, though large differences between the 10 tools were observed. We have identified10 hard-to-detect types of dependencies and four challenges in dependency detection. The relevance of our findings is substantiated by means of a frequency analysis of the hard-to-detect types of dependencies in five open source systems. DOI: 10.1002/spe.2421
In software architecture, the Layers pattern is commonly used. When this pattern is applied, the responsibilities of a software system are divided over a number of layers and the dependencies between the layers are limited. This may result in benefits like improved analyzability, reusability and portability of the system. However, many layered architectures are poorly designed and documented. This paper proposes a typology and a related approach to assign responsibilities to software layers. The Typology of Software Layer Responsibility (TSLR) gives an overview of responsibility types in the software of business information systems; it specifies and exemplifies these responsibilities and provides unambiguous naming. A complementary instrument, the Responsibility Trace Table (RTT), provides an overview of the TSLR-responsibilities assigned to the layers of a case-specific layered design. The instruments aid the design, documentation and review of layered software architectures. The application of the TSLR and RTT is demonstrated in three cases.
Author-supplied abstract: Developing large-scale complex systems in student projects is not common, due to various constraints like available time, student team sizes, or maximal complexity. However, we succeeded to design a project that was of high complexity and comparable to real world projects. The execution of the project and the results were both successful in terms of quality, scope, and student/teacher satisfaction. In this experience report we describe how we combined a variety of principles and properties in the project design and how these have contributed to the success of the project. This might help other educators with setting up student projects of comparable complexity which are similar to real world projects.
