Assessing the complexity of software architecture

ABSTRACT

A central activity of software architecture design is decomposing the system into subsystems (i.e. components) that work together to satisfy the required functionality. The purpose of this activity is to reduce problem complexity into smaller manageable parts. Complexity can never be totally eliminated; however the designer/architect can reduce it.The decomposition process is an art form; the architect must decide whether to assign a specific functionality to a given component or to defer some or all of the functionality to other components, with a goal of minimizing complexity. Deferring work decreases the responsibilities of a component (intracomponent complexity) but also may increase the dependencies between components (inter-component complexity).In this paper, our goal is to formulate an approach that identifies and measures those complexity factors that reflect interand intra-complexity for the purpose of introducing a new metric for assessing the overall complexity of software architecture. To accomplish this, we have chosen to use Full Function Points (FFP) methodology, which is the latest form of Functional Size Measure (FSM), as a building block for measuring complexity.However, since FFP was designed to measure the size of architecture; it fails to address some important issues with regard to complexity. Therefore, we identify those areas of weakness for FFP and exploit them to measure overall system complexity. The main feature of the approach is the integration of Full Function Points measure with a specification of the architecture to evaluate its overall complexity.

REFERENCES

• 1: Albrecht, A. J. (1979). Measuring application development productivity, in Proc. IBM Applications Development Symp. GUIDE Int. and SHARE Inc., IBM Corp., Monterey, CA, Oct. 14--17, p. 83.
• 2: Len Bass , Paul Clements , Rick Kazman, Software architecture in practice, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1998
• 3: Common Software Measurement International Consortium. (2001, May 3). COSMIC-FFP Measurement Manual, version 2.1.
• 4: Edsger W. Dijkstra, Guarded commands, nondeterminacy and formal derivation of programs, Communications of the ACM, v.18 n.8, p.453-457, Aug. 1975 [doi>10.1145/360933.360975]
• 5: Norman Fenton , Shari Lawrence Pfleeger, Software metrics (2nd ed.): a rigorous and practical approach, PWS Publishing Co., Boston, MA, 1997
• 6: Garlan, D. and Shaw, M. (1993). An Introduction to Software Architecture. Advances in Software Engineering and Knowledge Engineering, vol2, 1--39.
• 7: Henry, S. and Kafura, D.(1981). Software Structure Measures Based on Information Flow. IEEE Transaction on Software Engineering, 7(5):510--518.
• 8: Rick Kazman , Gregory Abowd , Len Bass , Paul Clements, Scenario-Based Analysis of Software Architecture, IEEE Software, v.13 n.6, p.47-55, November 1996 [doi>10.1109/52.542294]
• 9: Rick Kazman , Mark Klein, Performing architecture tradeoff analysis, Proceedings of the third international workshop on Software architecture, p.85-88, November 01-05, 1998, Orlando, Florida, United States [doi>10.1145/288408.288430]
• 10: McCabe (1976). A Complexity Measure IEEE Transactions on Software Engin., 2:308--320.
• 11: D. L. Parnas, On the criteria to be used in decomposing systems into modules, Communications of the ACM, v.15 n.12, p.1053-1058, Dec. 1972 [doi>10.1145/361598.361623]
• 12: Jianjun Zhao, On assessing the complexity of software architectures, Proceedings of the third international workshop on Software architecture, p.163-166, November 01-05, 1998, Orlando, Florida, United States [doi>10.1145/288408.288450]

INDEX TERMS

Primary Classification:
  D. Software
  D.2 SOFTWARE ENGINEERING
        D.2.11 Software Architectures

Additional Classification:
  D. Software
  D.2 SOFTWARE ENGINEERING
      D.2.8 Metrics
          Subjects: Complexity measures

General Terms:
Design

Keywords:
Full Function Points, architecture assessment, architecture complexity, coupling, software architecture