October Object-Oriented System Complexity: An Integrated Model of Structure and Perceptions

Transcription

1 October 1992 Object-Oriented System : An Integrated Model of Structure and Perceptions David P. Tegarden Information and Decision Sciences School of Business and Public Administration California State University, San Bernardino San Bernardino, California tegarden@gallium.csusb.edu (714) Steven D. Sheetz Graduate School of Business University of Colorado Boulder, Colorado SHEETZ_S@CUBLDR.COLORADO.EDU (303) Presented at: OOPSLA '92 Workshop on Metrics for Object-Oriented Software Development Send Comments to: David P. Tegarden Information and Decision Sciences School of Business and Public Administration California State University, San Bernardino San Bernardino, California tegarden@gallium.csusb.edu (714)

2 Object-Oriented System : An Integrated Model of Structure and Perceptions 1. Introduction For the many claimed benefits of object-oriented (OO) systems to be realized, measures of OO systems are necessary. The problem complexity of a task is an inherent and essential property that can not be reduced. OO techniques merely control this type of complexity; they do not reduce or eliminate the complexity. This control of complexity is accomplished by supporting hierarchical decomposition through both data and procedural abstraction, encapsulation, and polymorphism [6]. Software complexity measurement for OO systems must address the OO life cycle. Measurements are required for the constructs of structural complexity, perceptual complexity, and system complexity. The measures must adhere to the principles of measurement theory. Currently, most work in the measurement of OO systems either have addressed the structural complexity of code representations or cognitive issues of OO systems Related Work Measurement of the complexity of OO systems either has applied traditional software complexity metrics to OO systems [46], created new metrics for OO systems [12,23,31,33,40,44,45], or investigated both approaches [28,29,30]. Other related work that includes measures of object reuse [5,17,25,27], OO CASE effectiveness [2,3], project management concerns [13,18], planning and estimation models [22,26], testing approaches [4,16,32,43,47], and cognitive issues with OO systems [7,8,10,11,24,25,34,35,36,37,38,39]. 2. Software Measurement Program Measurement of OO system complexity requires the understanding of several constructs and the relationships between those constructs. Figure 1 presents a model of OO system complexity. The model consists of the system complexity, structural complexity, and perceptual complexity constructs. System complexity represents aspects of OO techniques and characteristics inherent to the problem. This construct influences the structural aspects of the system and the perceptual complexity of the OO model. Structural complexity deals with the measurable characteristics of the resulting OO system such as the number of classes and the interconnections between the classes. Perceptual complexity deals with the ability of the developer to understand the problem, the structural components of the OO system, the use of OO techniques, and how to integrate these ideas to create an OO system. These constructs have various meanings when evaluated on an OO system development life cycle that separates analysis (what), design (how), coding, and maintenance. Therefore, measures are required for each construct for each phase of the life cycle. At the end of the analysis phase, the analyst has specified the generalization, aggregation, and association relationships. By the end of the design phase, the designer has specified the inheritance and message passing relationships, and the methods. The programming phase ends with a working OO system. The maintenance phase includes not only the typical maintenance activities, but also the modification of the class definitions so that they may be included into a class library. This life cycle is a simplification of the O-O-O life cycle [19,20] System System complexity captures the concepts of problem complexity [9] and the complexity of using OO techniques to represent the problem. Together these ideas represent the initial complexity

3 for the development of an OO system. The concept of problem complexity is demonstrated by the fact that simple problems, such as balancing a checkbook, are inherently less complex than harder problems, such as optimizing network communications. Given that we must address both simple and harder problems, it is clear that this type of complexity is beyond the control of developers. The complexity of OO techniques includes understanding and applying concepts such as reuse, inheritance, message passing, and polymorphism. As developers gain experience with OO techniques this type of complexity is continually refined until a stable representation is developed. When the stable representation is reached this type of complexity helps to reduce the structural and perceptual complexity of OO systems Structural Measures A model of structural complexity identifies four levels at which the complexity of OO systems can be described: variable, method, object, and system. Figure 2 shows the levels and the relationships between the levels. At each level, measures are identified that account for the cohesion (Intra) and coupling (Inter) aspects of the system. The measures based in graph theory account for both procedural and data characteristics of an OO system that are applicable throughout the lifetime of an OO system. When combined with lexically based measures, they provide analysts, designers, and programmers of OO systems the ability to identify which components of an OO system are the most complex, and may therefore require additional analysis, design, or testing. [40,44,45] The combination of the description levels of Fig. 2 and the OO life cycle provides a comprehensive OO systems measurement framework (see Fig. 3). As a system moves through its life cycle, more measures become applicable. For example, by the end of the analysis phase, measures at the system and object levels are applicable. But by the end of the design phase, measures at the method and variable levels are applicable also. In general, the lexically based measures are not applicable until later in the life cycle Cognitive Measures In addition the structural measures defined above, the perceptions of the developers must be considered when evaluating the complexity of an OO system. This is necessary due to individual differences in the perceived complexity. These perceptions can be usefully represented as a group cognitive map. Cognitive mapping is a technique for studying people's perceptions of the world around them. Cognitive maps are comprised of concepts and relationships between concepts. They have been successfully applied to such abstract areas as corporate strategic planning [21], beliefs of political elites [1], and knowledge acquisition for expert systems [15]. They also have been demonstrated to be effective in group environments [14]. Figure 4 shows the perceptions of complexity identified by students who have successfully completed a graduate course in OO analysis, design, and programming. The map shows that the perceived complexity of the structure of an OO system influences the perceived complexity of the development process and therefore, the perceived complexity of the resulting solution and problem domains. [41,42] 3. Summary We believe that an accurate assessment of actual OO systems complexity is possible through the combination of the structural complexity aspects of OO systems and developers' perceptions of OO system complexity (see Fig. 1). We are currently developing a set of criteria that will allow us to map the model of perceptions to our structural measures.

4 - Structural System Problem Technique - Perceptual Fig. 1 - Model of Object-Oriented Systems System Level Object Level Intra Inter Variable Level Intra Inter Method Level Intra Inter Contributes To Fig. 2 - Object-Oriented Systems Description Levels

5 Analysis Design Programming Maintenance Message Passing Inheritance Association (AMO) Aggregation (APO) Generalization (AKO) System Object Method Variable Fig. 3 - Object-Oriented Systems Measurement Framework Class Design Maintenance Method Design Solution Domain Message Passing Structure Reusability - Methodology and Tools Problem Domain Project Management Fig. 4 - Cognitive Map of Perceptions of Object-Oriented Systems

6 4. References [1] R. Axelrod, Structure of Decision: The Cognitive Maps of Political Elites (Princeton University Press, Princeton, NJ, 1976). [2] R.D. Banker, R.J. Kauffman, and R. Kumar, Output Measurement Metrics in an Object-Oriented Computer Aided Software Engineering (CASE) Environment: Critique, Evaluation and Proposal, Proceedings of the Twenty-Fourth Hawaii International Conference on System Sciences, vol. III (IEEE Computer Society Press, Jan. 1991) [3] R.D. Banker, R.J. Kauffman, and R. Kumar, An Empirical Test of Object-based Output Measurement Metrics in a Computer Aided Software Engineering (CASE) Environment, Journal of Management Information Systems, Vol. 8 (Winter ) [4] B. Bently, Testing Object Oriented Software [Special Debate], Proceedings of Quality Week '92 Conference (Software Research, Inc., San Francisco, CA, May 1992). [5] J. M. Bieman, Deriving Measures of Software Reuse in Object Oriented Systems, Technical Report CS , Department of Computer Science, Colorado State University (July 1991). [6] G. Booch, Object-Oriented Design (The Benjamin/Cummings Publishing Company,Redwood City, CA, 1991). [7] R.L. Campbell, Developmental Scenario Analysis of Smalltalk Programming, CHI '90 Conference Proceedings (Apr 1990) [8] S.N. Cant, B. Henderson-Sellers, and D.R. Jeffrey, Application of Cognitive Me trics to Object-Oriented Programs (Submitted to Journal of Object-Oriented Programming, May 1992). [9] D. N. Card and R. L. Glass, Measuring Software Design Quality ( Prentice Hall, Englewood Cliffs, NJ, 1990). [10] J.M. Carroll and M.B. Rosson, Human-Computer Interaction Scenarios as a Design Representation, Proceedings of the Twenty-Third Hawaii International Conference on System Sciences, (IEEE Computer Society Press, Jan. 1990) [11] J.M. Carroll, J.A. Singer, R.K.E. Bellamy, and S.R. Alpert, A View Matcher for Learning Smalltalk, CHI '90 Conference Proceedings (Apr 1990) [12] S.R. Chidamber and C.F. Kemerer, Towards a Metrics Suite for Object Oriented Design, OOPSLA '91 Conference Proceedings, ACM SigPlan Notices Vol 26, No. 11 (Nov 1991) [13] P. Coffee, Objects At Work: Striking the Cost/Benefit Balance, Proceedings of The 1992 Borland International Developers Conference (Apr 1992). [14] C. Edin, Strategy Development and Implementation: Cognitive Mapping for Group Support, unpublished working paper, Department of Management Science, University of Strathclyde, Scotland (1991). [15] L. Finch, J. Landry, D. Monarchi, and D. Tegarden, A Knowledge Acquisition Methodology Using Cognitive Mapping and Information Display Boards, Proceedings of the Twentieth Hawaii International Conference on System Sciences, vol. 1 (IEEE Computer Society Press, Jan. 1987) [16] M.J. Harrold, Incremental Testing of Class Structures, Proceedings of Quality Week '92 Conference (Software Research, Inc., San Francisco, CA, May 1992).

7 [17] B. Henderson-Sellers, Some Metrics for Object-Oriented Software Engineering, TOOLS6 ( Prentice- Hall, Englewood Cliffs, NJ, 1991). [18] B. Henderson-Sellers, Managing and Measuring Object-Oriented Information Systems Development, Workshop on Object-Oriented Software Engineering Practice, Denver, CO (Feb 1992). [19] B. Henderson-Sellers and J.M. Edwards, The Object-Oriented Systems Life Cycle, Communications of the ACM, Vol. 33, No. 9 (Sept 1990) [20] B. Henderson-Sellers, J.M. Edwards, and L.L. Constantine, The O-O-O/EUON Handbook, Version No. 1.0, Information Technology Research Centre Report No. 58, University of New South Wales (June 1992). [21] A.S. Huff, Mapping Strategic Thought (John Wiley and Sons, Chichester, England, 1990). [22] R.L. Jenson and J.W. Bartley, Parametric Estimation of Programming Effort: An Object-Oriented Model, Journal of Systems and Software, vol. 15 (1991) [23] J. Keyes. New Metrics Needed for New Generation, Software Magazine, Vol. 12, No. 6 (May 1992) [24] J. Kim and F.J. Lerch, Towards a Model of Cognitive Process in Logical Design: Comparing Object- Oriented and Traditional Functional Decomposition Software Methodologies, CHI '92 Conference Proceedings (May 1992) [25] B.M. Lange and T.G. Moher, Some Strategies of Reuse in an Object-Oriented Programming Environment, CHI '89 Conference Proceedings (May 1989) [26] L.A. Laranjeira, Software Size Estimation of Object-Oriented Systems, IEEE Transactions on Software Engineering, vol. 16 (May 1990) [27] J.A. Lewis, S.M. Henry, D.G. Kafura, and R.S. Schulman, An Empirical Study of the Object-Oriented Paradigm and Software Reuse, OOPSLA '91 Conference Proceedings, ACM SigPlan Notices Vol. 26, No. 11 (Nov 1991) [28] D.R. Moreau, A Programming Environment Evaluation Methodology for Object-Oriented Systems, unpublished Ph. D. Dissertation, University of Southwestern Louisiana (1987). [29] D.R. Moreau and W.D. Dominick, Object-Oriented Graphical Information Systems: Research Plan and Evaluation Metrics, The Journal of Systems and Software, vol. 10 (1989) [30] D.R. Moreau and W.D. Dominick, A Programming Environment Evaluation Methodology for Object- Oriented Systems: Part I - The Methodology, Journal of Object-Oriented Programming, vol. 3 (May/Jun 1990) [31] K.L. Morris, Metrics for Object-Oriented Software Development Environments, unpublished Masters Thesis, M.I.T., Cambridge, MA (1988). [32] D.E. Perry and G.E. Kaiser, Adequate Testing and Object-Oriented Programming, Journal of Object- Oriented Programming, vol. 2, no. 5 (1990) [33] C. Rajaraman and M.R. Lyu, A Study of Coupling in C Programs, TOOLS8 (In Press). [34] M.B. Rosson and S.R. Alpert, The Cognitive Consequences of Object-Oriented Design, Human Computer Interaction, vol. 5 (1990)

8 [35] M.B. Rosson and J.M. Carroll, Climbing the Smalltalk Mountain, SigChi Bulletin, vol. 21, no. 3 (Jan 1990) [36] M.B. Rosson and J.M. Carroll, A V iew Matcher for Reusing Smalltalk Classes, CHI '91 Conference Proceedings (Apr 1991) [37] M.B. Rosson and J.M. Carroll, Demonstrating a View Matcher for Reusing Smalltalk Classes, CHI '91 Conference Proceedings (Apr 1991) [38] M.B. Rosson, J.M. Carroll, and R.K.E. Bellamy, Smalltalk Scaffolding: A Case Study of Minimalist Instruction, CHI '90 Conference Proceedings (Apr 1990) [39] M.B. Rosson and E. Gold, Problem-Solution Mapping in Object-Oriented Design, OOPCLA '89 Conference Proceedings, SigPlan Notices, vol. 24, no. 10 (Oct 1989) [40] S.D. Sheetz, D.P. Tegarden, and D. E. Monarchi, Measuring Object-Oriented System, Proceedings of the First Workshop on Information Technologies and Systems (Dec. 1991) [41] S.D. Sheetz, D.P. Tegarden, I. Zigurs, and K.A. Kozar, Group Support Systems: An Application to Cognitive Mapping, University of Colorado, College of Business and Administration, Faculty Working Paper Series (Submitted to the Twenty-Sixth Hawaii International Conference on System Sciences, June 1992). [42] S.D. Sheetz and D.P. Tegarden, Perceptions of Object-Oriented System (in preparation). [43] S. Siegel, Strategies for Testing Object Oriented Software, Proceedings of Quality Week '92 Conference (Software Research, Inc., San Francisco, CA, May 1992). [44] D.P. Tegarden and S.D. Sheetz, Structural Measures for Object-Oriented Analysis and Design (Submitted to the Second Workshop on Information Technologies and Systems - WITS-92, July 1992). [45] D.P. Tegarden, S.D. Sheetz, and D.E. Monarchi, A Software Model of Object-Oriented Systems, Faculty Working Paper No, 92-09, College of Business and Administration, University of Colorado, Boulder, CO (Submitted to Decision Support Systems: The International Journal, Jun. 92). [46] D.P. Tegarden, S.D. Sheetz, and D.E. Monarchi, The Effectiveness of Traditional Metrics For Object- Oriented Systems, Proceedings of the Twenty-Fifth Hawaii International Conference on System Sciences, vol. IV (IEEE Computer Society Press, Jan. 1992) [47] N.N. Thuy, Testability and Unit Tests in Large Object Oriented Software, Proceedings of Quality Week '92 Conference (Software Research, Inc., San Francisco, CA, May 1992).