Research Report 10/99 Software Architecture - Design and Evaluation by PerOlof Bengtsson Department of ISSN 1103-1581 Software Engineering and Computer Science ISRN HK/R-RES99/10SE University of Karlskrona/Ronneby S-372 25 Ronneby Sweden ISSN 1103-1581 ISRN HK-R-RES--99/10--SE © PerOlof Bengtsson, 1999 Printed in Sweden Kaserntryckeriet AB Karlskrona 1999 to Hans and Kristina for everlasting support This thesis is submitted to the Research Board at University of Karlskrona/Ronneby, in partial fulfillment of the requirements for the degree of Licentiate of Engineering. Contact Information: PerOlof Bengtsson Department of Software Engineering and Computer Science University of Karlskrona/Ronneby Soft Center SE-372 25 RONNEBY SWEDEN Tel.: +46 457 787 41 Fax.: +46 457 271 25 email: [email protected] URL: http://www.ipd.hk-r.se/pob Abstract The challenge in software development is to develop software with the right quality levels. The main problem is not to know if a project is technically feasible concerning functionality, but if a solution exists that meet the software quality requirements. It is therefore desired to get an early indication of the qualities of the resulting software. Software architecture is concerned with what modules are used to compose a system and how these modules are related to each other, i.e. the structure of system. The software architecture of a system sets the boundaries for these qualities. Hence, to design the software architec- ture to meet the quality requirements is to reduce the risks of not achieving the required quality levels. In this thesis we present the experiences from a software architecture design project with two industry partners. Based on these we propose a method for reengineering architectures and exemplify by an applying the method on a real world example. The method is based on architec- ture transformations and software quality evaluation of the architecture. Further, we present a method for predicting software maintenance effort from the software architecture, for use in the design and reengineering method. The method uses change scenario profiles to describe future changes to the system and architecture impact analysis provide knowl- edge of the modification volume required for the realization of each sce- nario. The results from a quasi experiment supports that groups consisting of prepared members create better scenario profiles. Also, the results suggest that there is a large room for variation between scenario profiles created by individual persons. Acknowledgements I would like express my gratitude and appreciation to my advisor Profes- sor Jan Bosch, for offering me this opportunity, for his guidance, and for being a good friend. I would also like to thank my colleague, Michael Mattsson, who always have time for me and my research. I would also like to thank my colleagues at the department, especially the members of the RISE research group. The results presented in this thesis would not have been possible if it were not for; the people at the companies I have worked with, Lars-OlofSandberg at Althin Medical, Anders Kambrin and MogensLundholm at EC-gruppen, the students volunteers in the experi- ments, and the staff at Infocenter in Ronneby. From the library at Cam- pus Gräsvik I would like to thank Peter Linde who assisted me swiftly when time was scarce before printing. I would also like to express my gratitude to all my friends, especially Magnus C. Ohlsson for his friendship and lots of fun. An important per- son in my life is my friend and teacher, Olle Tull, who taught me lots more than playing the trumpet. I am greatly indebted to my family; to my father Hans and my mother Kristina for their never failing support and wisdom, to my brother Jonas and my sister Elisabeth for. I give my greatest love to Kris- tina for sharing her life with me. Contents Introduction 3 1. Software Architecture ..............................................................................5 2. Software Architecture Design ..................................................................9 3. Software Architecture Description ........................................................22 4. Software Architecture Analysis ..............................................................29 5. Contributions in this Thesis .................................................................33 6. Further Research ...................................................................................37 Paper I: Haemo Dialysis Software Architecture Design Experiences 41 1. Introduction .........................................................................................41 2. Case: Haemo Dialysis Machines ...........................................................42 3. Lessons Learned ....................................................................................49 4. Architecture ..........................................................................................54 5. Conclusions ..........................................................................................67 Paper II: Scenario-based Software Architecture Reengineering 71 1. Introduction .........................................................................................71 2. Example: Beer Can Inspection ..............................................................73 3. Architecture Reengineering Method .....................................................74 4. Measurement Systems ...........................................................................81 5. Applying the Method ............................................................................84 6. Related Work ........................................................................................93 7. Conclusions ..........................................................................................94 Design and Evaluation of Software Architecture 1 Paper III: Architecture Level Prediction of Software Maintenance 97 1. Introduction ......................................................................................... 97 2. Maintenance Prediction Method .......................................................... 99 3. Example Application Architecture ...................................................... 103 4. Prediction Example ............................................................................ 110 5. Related work ...................................................................................... 115 6. Conclusions ....................................................................................... 116 Paper IV: An Experiment on Creating Scenario Profiles for Software Change 119 1. Introduction ....................................................................................... 119 2. Scenario Profiles ................................................................................. 121 3. The Experiment ................................................................................. 124 4. Analysis & Interpretation ................................................................... 134 5. Related Work ..................................................................................... 140 6. Conclusions ....................................................................................... 141 Appendix I: Individual Information Form 144 Appendix II: Individual Scenario Profile 145 Appendix III: Group Scenario Profile 146 2 Design and Evaluation of Software Architecture Introduction The challenge in software development is to develop software with the right quality levels. The problem is not so much to know if a project is technically feasible concerning functions required, but instead if a solu- tion exists that meets the software quality requirements, such as throughput and maintainability. Traditionally the qualities of the devel- oped software have, at best, been evaluated on the finished system before delivering to the customer. The obvious risks of having spent much effort on developing a system that eventually did not meet the quality requirements have been hard to manage. Changing the design of the system would likely mean rebuilding the system from scratch to the same cost. In software development it is therefore desired to get an early indica- tion of the qualities of the resulting software. Such an indication would allow the software engineers to make changes to the design of the system before expensive resources have been used for programming parts that is removed later in the development process. In 1972 Parnas [22] argued that the way a software system is decom- posed into modules affects its abilities to meet levels of efficiency in cer- tain aspects, e.g. flexibility, performance. Software architecture is concerned with what modules are used to compose a system and how these modules are related to each other, i.e. the structure of system. The software architecture of a system sets the boundaries for these qualities [2, 9, 11, 22, 28]. Hence, to design the software architecture to meet the quality requirements is to reduce the risks of not achieving the required quality levels. Design and Evaluation of Software Architecture 3 Introduction The result from the software architecture design activity is a software architecture. But, the description of that software architecture is far from trivial. A reason is that it is hard to decide what information is needed to describe a software architecture, and hence, it is very hard to find an optimal description technique. The problems of not having a notation with clear