| dc.description.abstract | A significantly large fraction of time during development
and maintenance is spent on understanding unfamiliar
parts of software systems. The existence of software documentation,
such as software architecture design documentation can
significantly reduce the amount of time spent on this task.
However in reality, few software systems have an up-to-date documentation
because project time pressure makes it impractical to
do so. During comprehension therefore, software engineers often
try to recover these lost design documentation through reverse
engineering. However, current reverse engineered diagrams show
only one perspective of a software system; the components that
exist in the system and the relationship between them. Often,
software engineers require additional perspectives in order to
understand how a system works. In this research, we aim to
solve this problem by providing one such perspective on top
of reverse engineered diagrams. We provide a framework and
tool for automatically identifying common system concerns that
are found in modern software systems, and then map them
back to the software components in the system that implement
them. An example of such system concerns are user interfaces,
persistence, security etc. A regular question that comes up
during comprehension is which software components in a system
implement these concerns. We propose a taxonomy of these
common concerns, and a framework and tool for automatically
identifying and labelling system components that implement
them. Our framework is based one lightweight static analysis. It
calculates three metrics that are then used during identification.
An evaluation of the Concern Detector tool (and in essence the
framework) on 4 software systems showed that, authors of the
systems agreed 65.5% - 76.8% with the tool’s classification of
components in their systems. This indicates that, the tool is
useful for describing the roles of these components in terms of
implementing these concerns. The current implementation is for
the java programming language; however the approach is designed
to be generalizable for most object oriented programming
languages. | sv |
