Characterizing Essential and Incidental Complexity in Software

Characterizing Essential and Incidental Complexity in Software Architectures Raghvinder S. Sangwan and Colin J. Neill The Pennsylvania State University {rsangwan, cjneill}@psu.edu Abstract This paper reports results from an experimental case study that seeks to characterize essential and incidental complexity in the design of a complex software product using design structure matrices (DSMs). A DSM captures structural dependencies among the modules and can be used to identify parts of a system that lack cohesion and/ or are highly coupled. We consider such parts as excessively complex. In the case study, we capture the complexity of an Internetbased collaborative system as it was originally designed and after it was redesigned using an architecture-centric development methodology. We find significant reduction in excessive complexity of the redesigned system suggesting that excessive complexity can be an incidental byproduct of a development methodology that lacks focus on the systemic properties of a system that strongly influence its architecture.

1. Introduction It has long been known that software systems are complex. Brooks asserted that much of this complexity was inherent to the domain: “the systems we produce are themselves the solutions to complex problems that are constantly changing; the intangible nature of software defies our abilities to represent or visualize it without eliminating essential detail; and it provides the connective tissue between a vast array of other systems, both man and machine.” [2] In the twenty years that have passed since Brooks made those assertions the scale of systems has grown enormously, making the problem even more daunting. Fortunately this period has also seen significant advances in our understanding of what constitutes complexity in those systems. We now have catalogs of heuristics, principles, and patterns that document how to construct software designs that are extensible, robust, and comprehensible along with tools and techniques that identify and highlight when these guidelines are transgressed. Despite these advances, however, the problem remains – we continue to develop overly complex systems.

c 978-1-4244-4985-9/09/$25.00 2009 IEEE

Hoare states: “there are two ways of constructing a software design: one way is to make it so simple that there are obviously no deciencies; the other way is to make it so complicated that there are no obvious deciencies. The first method is far more difficult.” [4] Hoare implies, therefore, that while creating simple designs is anything but easy, it is far easier to create complicated designs. From our perspective, a design becomes complicated not because it needs to contend with the essential complexity inherent in a system but introduction of excessive complexity that can be an incidental byproduct of a chosen development methodology. We demonstrate this through an experimental case study of a commercial system developed using conventional object-oriented analysis and design (OOAD) that soon reached a level of complexity that brought development to a halt and the system to be abandoned. By employing architecturecentric methods, however, we were able to develop the same system without the accompanying complexity while still meeting all quality and functionality expectations. The paper is organized as follows: Section 2 describes the approach we use to analyze the complexity of a software system. Section 3 presents the complexity analysis of an Internet-based collaborative system. Section 4 uses an architecture-centric approach to reengineer the whiteboard subsystem of the Internetbased collaborative system and discusses the implication of results obtained from this experiment. Section 5 presents the conclusions.

2. Analyzing software system complexity Complexity in software is perceived as the number of interacting elements within a software system, the internal structure of these elements, and the number and nature of interdependencies among them [7]. At the design-level complexity is related to the degrees of cohesion and coupling within and between a software system’s various elements [5]. Design-level cohesion and coupling in a system can be analyzed using DSMs [3, 6]. Figure 1 shows a DSM for a system that has been decomposed into 4 modules, namely A, B, C and D. The rows and columns of the

265

matrix represent the same modules. The dependencies of a module are read down a column. For example, reading down the first column we can see module A depends on module C with the number of dependencies being 40. We also see that module A does not depend on modules B and D as those cells are empty. The identity diagonal (shown in black) represents a dependency of a subsystem to itself. A

C

D

A

10

20

B

30

C

B

40

3. An Internet-based collaborative system: a case study 50

D Figure 1. A dependency structure matrix (DSM) A DSM can be reordered starting with modules that use most of the other modules and ending with those that provide most to the others while grouping modules that are highly interdependent together in the ordering. Figure 2 shows this reordering for the DSM from figure 1. The reordering yields three groups or blocks first consisting of module D, second consisting of modules A and C, and the third consisting of module B. D

A

C

B

D A

20

C

50

B

10 40 30

Figure 2. A reordered DSM with 3 blocks DSMs thus can give us a sense of which modules underlie which other modules, and how coupled and cohesive they are. For example, the system represented by the DSM in figure 2 can be envisioned as a layered system with the first block as the top layer followed by the second block and finally the third block as the bottom layer. Modules A and C in the second block are highly coupled due to their cyclic interdependencies. Such cyclic dependencies form ‘tangles’ that makes the modules within a tangle harder to develop, understand,

266

maintain and test. The number of dependencies from one module to another can be indicative of its cohesiveness. The more the number of these dependencies, the more ‘fat’ a module has become and, therefore, will be harder to understand and maintain. Threshold levels can be set for tangles and fat whereby only elements exceeding these threshold values are considered complex. For this paper the threshold for tangles is 0 and the maximum number of dependencies of one module on another is 120 (exceeding this implies low cohesion).

To test our hypothesis that complexity is an incidental byproduct of a development methodology, we chose a system that allowed virtual teams to collaborate over the Internet using speech, video, email, file sharing, and whiteboards. After a number of successful releases, performance and reliability emerged as two significant issues making the system harder to maintain and extend. Significant degradation in performance was experienced when many shared whiteboards were active and the system would freeze if Internet connectivity was compromised. Despite rewriting thousands of lines of code, the team failed to overcome these issues and eventually abandoned the project. Figure 3 shows a DSM representation of this system. There are 5 blocks 2 of which are tangles of 9 and 3 modules respectively, indicating high coupling. There are many fat cells that exceed our dependency threshold value of 120 indicating lack of cohesion. These fat cells are shown in a lighter shade of gray in the figure. We wanted to determine the cause of this high coupling and lack of cohesion. A closer analysis of the abandoned system revealed that systemic concerns such as performance and reliability were distributed throughout the application. This was not a case of poor initial design, however. On the contrary, the initial architecture exhibited good object-oriented design. Given the requirements of the system we would anticipate separate components for voice, media, mail, drawing, etc. and that is what we found (as reflected in the DSM of figure 3). So what went wrong? As is typical in objectoriented analysis, the primary driver of design is the use-case model. This promotes functional and data requirements and this is reflected in the resulting architecture. Non-functional requirements are treated as secondary concerns that all components should exhibit, but when those requirements are not met there

2009 IEEE/IFIP WICSA/ECSA

server order

util

net

file

media

voip

mail

data

store

ui

draw

4 4

client

16 13

Skin

3 14 87

36

Ui store

skin

14 5

member

Draw

client

member

order

server

is no single source of the problem to be repaired – the flaw is distributed across the application. In a general sense, while functional requirements can be achieved in any structure, only certain structures enable the qualities desired from those functions or the system as a whole.

372 83 408 2518 2

1

3

2

63

7

Data

241 44 236 280

22

Mail

45

Voip

14 3

98 218

media

173 141

22

File

110

4

6

46

Net

2173 197 199 1525

Util

667 87 83 1640 37 30 149 37 86 156 111 91 101 173

36 128 160 118

1 11 70

1 32

Figure 3. DSM for Internet-based collaboration system The failure of the collaborative system project can be attributed to treating its significant non-functional requirements, such as performance and reliability, as secondary such that it became problematic to address these concerns late in the development lifecycle.

4. Using an architecture-centric approach In order to test the hypothesis that arbitrary complexity is a byproduct of the development method we chose to develop a new version of the system employing a development approach that explicitly considers the important systemic properties from the start in the hope that this would limit the incidental complexity that plagued the original system. Rather than focus on the entire system, we chose the whiteboard subsystem of the Internet-based collaboration environment since this was the part that suffered most from performance degradation and lack of reliability. We chose to use attribute-driven design (ADD) [1], in the re-engineering of the whiteboard subsystem since it begins with a prioritized set of architectural drivers that describe the critical systemic properties of the system. These drivers are elicited from stakeholders of the system in the form of quality

attribute scenarios. Table 1 shows the scenarios for the Whiteboard subsystem in a priority order. Table 1. Architectural drivers for the whiteboard Quality Attribute Modifiability

Architectural Drivers

The system shall be capable of receiving inputs from different devices such as a wireless pen tablet or touch screen, and sending output to different devices such as a display station or a smart phone. Performance The system shall respond within no more than one second for sketching or drawing and no more than five seconds for any other operation. Testability Tracking progress of execution and troubleshooting any failures shall be possible at runtime. Interoperability It shall be possible to capture whiteboard sessions so they can be loaded and played back in external systems. Reliability The system shall recover from unstable network connections.

Starting from a monolithic representation of the system, ADD describes progressive decomposition through the application of a series of architectural tactics corresponding to the identified quality attributes. The result of the decomposition is shown in Figure 4. Figure 5 shows the DSM for the original whiteboard subsystem. This subsystem is embedded in a tangle of 9 modules and the complete DSM appears as a single block. Besides this high degree of coupling, the DSM also shows numerous fat cells that exceed the threshold of 120 dependencies indicating lack of cohesion. The proportion of the code involving the tangle and fat is 23% or 23K of the 100K lines of code!

2009 IEEE/IFIP WICSA/ECSA

267

logging

messaging

testing

event mgt

whiteboard whiteboard event mgt testing messaging logging

90 1 16 39 30 70 37 32 29

Figure 6. DSM for reengineered whiteboard subsystem

5. Conclusion Our exploratory results show development approaches to design of a software system that focus on systemic properties are more likely to keep excessive complexity under check. Design methodologies lacking this focus are likely to generate incidental complexity that can make systems harder to develop, understand, maintain, test and evolve.

6. References

Figure 4. ADD decomposition of whiteboard subsytem

server 14 order 5 4 member 4 3 client 16 13 skin 87 draw 36 372 Ui 83 408 2518 2 store 1 63 data 241 44 236 280

data

store

ui

draw

skin

client

member

order

server

What is particularly noteworthy about the attributedriven design is that the system may still appear complex (in the sense of the number of dependencies, in Figure 4), but when represented as a DSM (shown in Figure 6) this newly created subsystem is free of any tangles or fat thus providing positive support for our hypothesis.

14

3

[1] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Second Edition, Boston, MA: Addison-Wesley, 2003. [2] F.P. Brooks, The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, Boston, MA, 1995. [3] S. D. Eppinger, “Model-based approaches to managing concurrent engineering,” Journal of Engineering Design, 2(4):283–290, 1991. [4] C.A.R. Hoare, “The Emperor’s Old Clothes,” Communications of the ACM, Vol. 24, No. 2, February 1981, pp. 75 – 83. [5] W. P. Stevens, G. J. Myers, and L. L. Constantine, “Structured design.” IBM Systems Journal, 13(2):115– 39, 1974. [6] D. V. Steward, “The Design Structure System: A Method for Managing the Design of Complex Systems.” IEEE Trans. on Eng. Mgmt EM-28.3: 71-74, Aug, 1981. [7] R. Taylor, N. Medvidovic and E. Dashofy, Software Architecture: Foundations, Theory and Practice, Hoboken, NJ: John Wiley & Sons, 2009.

2 7 22

14 3

Figure 5. DSM for legacy whiteboard subsystem

268

2009 IEEE/IFIP WICSA/ECSA