Foreword – Software Architecture: A Case Based Approach


Every field uses case studies. Artists study the masters and the lesser amateurs. Civil engineers study bridges that stand up as well as bridges that fall down. The virtue of case studies is their concreteness. Students can see realizations of the concepts that might have been mainly abstractions before. A basic pattern such as model view controller becomes much more meaningful when the context in which it is used is observable.

Case studies can span eras as well. Forty years ago, the concept of “re-entrant” code was well known. Today, it is far less well known. I frequently run into programmers and designers who do not know the concept. The degradation of knowledge is inevitable because there are always new things to learn and only a limited amount of time to learn them. Consequently, some things must be left out of any curriculum. A case study of a 40-year-old system might still be illuminating because of this degradation of knowledge.

More case studies are always useful. New techniques and application domains are continually emerging and the new case studies can illuminate those techniques and domains. Organizational and cultural contexts change and case studies can define these contexts as well.

Software engineering provides challenges in constructing case studies. Software systems of any interest are large and ungainly. Not only are the systems themselves complicated but, usually, the organizational context is also complicated. A recent exercise I was involved in had 14 different stakeholder types. Add to this the fact that many of these stakeholders represent different organizations and the organizational context is inherently complicated.

A case study must present the system and its organizational context in sufficient detail so that students can draw lessons from the case study and, yet, not in so much detail that students must be totally immersed in the case study for extended periods of time in order to get anything of interest out.

Luckily, there are two moderating factors when considering case studies. The first is the abstraction ability of the human brain. I became interested in software architecture initially because I was fascinated by the amount of time a group of people could spend arguing about two circles and an arrow on a whiteboard. Add a third circle and several more arrows and literally months could be spent. The second moderating factor is an explanation of the case study. An instructor or a textbook can present guidance as to what to look for in the case study and what lessons to take away from the case study. If the case study has sufficient detail, the student can come up with alternative interpretations, and the exchange between the student and the instructor adds richness to the case study and to the lessons that the student is able to derive from the case study.

The case studies in the book provide as much detail as is possible in a chapter and provide an interpretation of the lessons. They span a variety of different application domains and circumstances. They also span a variety of different phases of the life cycle. This spanning of the life cycle allows the lessons from one case study to be applied to another. For example, one case study is about architectural evaluation. Another is about architecture design. The design fragment presented in the design case study can be evaluated using the techniques discussed in the architectural evaluation case study. Another case study discusses re-factoring the architecture for performance. Can the architectures in both the architecture evaluation case study and the design case study be re-factored in case the performance requirements became more stringent?

Because the case studies are elaborated in some detail, every decision made by the development team can be second guessed by a student and discussed with the instructor. This will provide ample opportunity for independent work. For example, in the component-based case study, the development team decides to construct a content management system (the e-Publish component). Why construct this component rather than use one of the open source content management systems? This is a decision that was not explained in the case study, and a possible assignment is to analyse the factors that might have led to that choice.

Another virtue of the range of case studies is that different approaches to the same problem can be studied. Design, for example, is a matter of generate and test. That is, generate a hypothesis, test it and gain insight that enables the intelligent generation of a new hypothesis. In the case studies in this book, several different approaches to the generation of the initial hypothesis can be observed. In the component-based case study, the initial hypothesis is the concatenation of the components to be used in the solution. The next hypothesis in this case would add connectors to the components. The case study on the mobile trading system generated the initial hypothesis through examining particular use cases. Subsequent iterations might cause techniques to achieve various quality attributes to be added to the design.

In summary, examining case studies is an important portion of the education process for both students and professionals who have entered this field. An analysis of the case studies in this book and the explanations associated with them will help shorten the process by which software architects are created.

Len Bass

Pittsburgh, PA