DecidArch: Playing Cards as Software Architects

Teaching software architecture is a challenge because of the difficulty to expose students to actual meaningful design situations. Games can provide a useful illustration of the design decision making process, and teach students the power of team interaction for making sound decisions. We introduce a game –DecidArch– developed to achieve three learning objectives: 1) create awareness about the rationale involved in design decision making, 2) enable appreciation of the reasoning behind candidate design decisions proposed by others, and 3) create awareness about interdependencies between design decisions. The game has been played by 22 groups with a total of 83 players, all of them students of the VU software architecture course. We present some of the lessons learned, both from our observation and through participant survey. We conclude that the game well supports our three learning objectives, and we identify several improvement points for future game editions

Empirical Study on the Effect of a Software Architecture Representation's Abstraction Level on the Architecture-Level Software Understanding

Abstract-Architectural component models represent high level designs and are frequently used as a central view of architectural descriptions of software systems. Using the architectural component model it is possible to perceive the interactions between the system's major parts and to understand the overall system's structure. In this paper we present a study that examines the effect of the level of abstraction of the software architecture representation on the architecture-level understandability of a software system. Three architectural representations of the same software system that differ in the level of abstraction (and hence in the number of components used in the architecture) are studied. Our results show that an architecture at the abstraction level that is sufficient to adequately maps the system's relevant functionalities to the corresponding architectural components (i.e., each component in the architecture corresponds to one system's relevant functionality) significantly improves the architecturelevel understanding of the software system, as compared to two other architectures that have a low and a high number of elements and hence tangles or scatters the system's relevant functionalities into several architectural components