Introducing tool-supported architecture review into software design education

While modularity is highly regarded as an important quality of software, it poses an educational dilemma: the true value of modularity is realized only as software evolves, but student homework, assignments and labs, once completed, seldom evolve. In addition, students seldom receive feedback regarding the modularity and evolvability of their designs. Prior work has shown that it is extremely easy for students and junior developers to introduce extra dependencies in their programs. In this paper, we report on a first experiment applying a tool-supported architecture review process in a software design class. To scientifically address this education problem, our first objective is to advance our understanding of why students make these modularity mistakes, and how the mistakes can be corrected. We propose tool-guided architecture review so that modularity problems in students' implementation can be revealed and their consequences can be assessed against possible change scenarios. Our pilot study shows that even students who understand the importance of modularity and have excellent programming skills may introduce additional harmful dependencies in their implementations. Furthermore, it is hard for them to detect the existence of these dependencies on their own. Our pilot study also showed that students need more formal training in architectural review to effectively detect and analyze these problems.

[1]  Kim B. Clark,et al.  The power of modularity , 2000 .

[2]  Jan Venselaar,et al.  DESIGN RULES , 1999 .

[3]  Benjamin S. Bloom,et al.  A Taxonomy for Learning, Teaching, and Assessing: A Revision of Bloom's Taxonomy of Educational Objectives , 2000 .

[4]  Paul Clements,et al.  Software architecture in practice , 1999, SEI series in software engineering.

[5]  Yuanfang Cai,et al.  Detecting software modularity violations , 2011, 2011 33rd International Conference on Software Engineering (ICSE).

[6]  Ralph Johnson,et al.  design patterns elements of reusable object oriented software , 2019 .

[7]  Yuanfang Cai,et al.  Analyzing the Evolution of Large-Scale Software Systems Using Design Structure Matrices and Design Rule Theory: Two Exploratory Cases , 2008, Seventh Working IEEE/IFIP Conference on Software Architecture (WICSA 2008).

[8]  D. L. Parnas,et al.  On the criteria to be used in decomposing systems into modules , 1972, Software Pioneers.

[9]  Leigh Ann Sudol-DeLyser,et al.  Analyzing the strength of undergraduate misconceptions about software engineering , 2010, ICER '10.

[10]  Ward Cunningham,et al.  The WyCash portfolio management system , 1992, OOPSLA '92.

[11]  簡聰富,et al.  物件導向軟體之架構(Object-Oriented Software Construction)探討 , 1989 .

[12]  Leonard J. Bass,et al.  Scenario-Based Analysis of Software Architecture , 1996, IEEE Softw..

[13]  Rick Kazman,et al.  Evaluating Software Architectures: Methods and Case Studies , 2001 .

[14]  Kathy Sierra,et al.  Head First Design Patterns , 2004 .

[15]  Yuanfang Cai,et al.  Leveraging design structure matrices in software design education , 2011, 2011 24th IEEE-CS Conference on Software Engineering Education and Training (CSEE&T).

[16]  Mark Klein,et al.  Experience with performing architecture tradeoff analysis , 1999, Proceedings of the 1999 International Conference on Software Engineering (IEEE Cat. No.99CB37002).

[17]  Yuanyuan Song,et al.  Automatic modularity conformance checking , 2008, 2008 ACM/IEEE 30th International Conference on Software Engineering.