Object-Oriented Design Quality

Report on OOPSLA'97 Workshop #12

Rudolf K. Keller* Alistair Cockburn** Reinhard Schauer*

*University of Montreal
Montreal, Quebec, Canada

**Humans and Technology
Salt Lake City, Utah, U.S.A.





  1. Introduction


Despite the burst in the availability of OO analysis and design methodologies, languages, database management systems, and tools, relatively little work has been done in the area of OO design quality assurance, assessment, and improvement. We badly need a better understanding of the properties of OO system design, in the small and in the large, and their effect on quality factors such as maintainability, evolvability, and reusability. The understanding of desirable and non-desirable properties may contribute to improvement of risk assessment and product selection, better planning, more accurate assessment of maintenance efforts, improved productivity evaluation, a better foundation of design methods, improved system evolvability, and eventually to better design practices.


This workshop sought participants to cover practical and theoretical issues related to the quality of OO designs, addressing the two key questions:


  • What makes a good OO design?
  • How do we achieve a good OO design?



Theme topics were the following, as they helped resolve those two key questions:


  • Examples of good OO design;
  • Conflicts and contradictions in asking for "good" OO designs;
  • Characteristics of good OO designs;
  • Design techniques to obtain good designs;
  • Evaluation experiences of existing proposed OO design metrics;
  • New design metrics (only if attached to motivating examples);
  • Relationship between good OO analysis and good OO design; and
  • Testing OO designs for quality.


In this report, we summarize the workshop activities, which included pre-distribution of position papers (via the workshop web site), initial round-table discussion, short presentations, discussions of selected topics in work groups, and final gathering to compare impressions and identify consensus, issues and directions of the topic. Section 2 summarizes some of the arguments made in the participantsí position statements. Section 3 digests the main points of the discussion. Section 4 rounds up this report with some concluding remarks about the workshop.


  1. Contributions

    The profile of the workshop participants was a healthy mix of 21 software professionals from academia and industry. Participants from both groups were in general supporters of either more formal or more informal techniques for software design and assessment. Those who supported formal software design techniques argued that metrics be the only way for objective decision-making among the different design trade-offs in software design. The counter-argument of those who supported more informal techniques was that software design quality is subjective [4], and there is no principled method for characterizing the interaction among different quality properties [7]. Contributions that shed light on some forms of design quality came in the area of objective quality assessment [1, 2, 3, 5, 12, 15], subjective quality assessment [4, 8, 11, 13], life-cycle quality assessment [9, 14] and architectural design quality assessment [6, 7, 10, 16].


    1. Objective Quality Assessment

      The common baseline supported by all workshop participants was that quality is a multi-faceted concept. Carrying over this idea in his arguments, Bansiya [2] emphasized that metrics can provide an unbiased assessment of the different facets of quality, such as reusability, flexibility, understandability, functionality, extendibility, or effectiveness. Benlarbi [3] underlined this by stressing the necessity of metrics for early risk assessment. Most of the metrics for design measurement focused on cohesion and coupling. Briand et al. [5] organized coupling metrics within a three-dimensional classification scheme. Ponnambalam [15] presented a model for object-oriented designs balancing cohesion and coupling.


      Several participants reported the development of tools for software assessment [1, 2, 12]. Abounader and Lamb [1] reported the development of a university prototype addressing evaluation of complexity metrics, based on a schema for a database of design information. Bansiya [2] reported about another metrics tool, QMOOD++ (Quality Model for Object-Oriented Designs represented in C++), which supports a suite of thirty-plus object-oriented design quality metrics. Laguë and Leduc [12] discussed Datrix, an industrial-strength metrics evaluation tool for C++ systems, which is used by Bell Canada to assess telecommunications software of potential suppliers.


    3. Subjective Quality Assessment

      Some participants moderately supported traditional object-oriented metrics for measurement of design quality. They rather emphasized the necessity of design guidelines [8] and a development culture that encourages simplicity, intuitiveness, and understandability of software designs to humans. Most controversial to metrics supporters, Ben-Yehuda [4] argued that quality depends on its context and that metrics cannot provide accurate numbers for the many viewpoints one can have on an application domain. Similarly, Maetzel and Riehle [13] argued that quality could only be measured relatively to a particular viewpoint. Kriha, Kesch, and Pluess [14] elaborated on some of these viewpoints and their impact on architectural structures (analytic, logical, physical, social, reflective, extension, usage, source code, generation, run-time).


    5. Life-cycle quality assessment

      To achieve good object-oriented design, some contributions addressed a seamless transition of development artifacts from one phase to the next within an object-oriented development cycle. Fernandez [9] focused on the transition of artifacts between analysis and design. OíRourke [14] investigated software design from the perspective of completeness and variability. He stressed that good software design should include views that explicitly show the mapping between the use cases to classes and objects, the analysis model to the design model, and the logical work units to the physical work products.


    7. Architectural design quality assessment


    Several participants reported on methods and tools for investigating architectural design quality. Butler [6] motivated tool support by arguing that simplicity and clarity of documentation is a compelling indicator that the underlying architecture and design is also simple and clear. For efficient support of framework understanding, documentation should include "a graded set of training examples". Similarly, Carrière and Kazman [7] stressed that design quality flows from architectural reasoning, which calls for documentation of the many different perspectives on the application. Carrière and Kazman discussed Dali, a tool for architectural reasoning for large software systems. Dali allows for the extraction of a source model from a systemís implementation, the creation of architectural design rules, the visualization of the design, and the evaluation of design. Grotehen and Dittrich [10] described the core components of MeTHOOD, a catalogue of design knowledge, consisting of design heuristics, transformational rules, and measures. Keller and Schauer [16] reported about a prototype for design pattern based software engineering. They construct an environment that manages both source code models and design patterns in a central repository and allows for seamless evolution of design patterns into executable software. They further plan to pursue analysis of software with respect to its adherence to design patterns.


  3. Discussion


The afternoon session aimed at discussing the various positions towards software quality. The participants split into three groups. One group applied a bottom-up explorative approach to design quality based on a case study discussion, using the design of a coffee machine. Two other groups investigated design quality by top-down exploration of its properties and the perspectives from which one can look at a problem domain.


The first group tackled design quality with a bottom-up approach. They started out with a case study for the design of a coffee machine (provided by Alistair Cockburn; see workshop web site), looked into possible change scenarios, and discussed how to address these with different design strategies. Given the time constraints and the diverse backgrounds of the group members, the participants agreed on focusing discussion on design simplicity. Based on two design alternatives of the coffee machine case study, they came up with the following list characterizing design simplicity:


  • Simplicity of control and data flow (unidirectional, synchronous, asynchronous)
  • Simplicity of components
  • Simplicity of collaborations (central and distributed, count of messages, and content of messages)
  • Redundancy
  • Extensibility
  • Consistency
  • Conformance to existing knowledge


The first group did reach a consensus of surprise as to how difficult it is to evaluate a design even just for simplicity, and how many ways there are to characterize simplicity.


The second group started out with a summary of the workshop position statements and a general discussion of design quality. The common denominator of this group was that quality assessment is relative to the perspective from which one looks at a problem, and each of the different perspectives should be assessed with appropriate techniques, such as metrics, heuristics, inspections, or case studies. The group members agreed upon the following list of perspectives, with each having substantial influence on the quality of design artifacts:


  • Maintainability
  • Documentation
  • Extensibility
  • Cost
  • Reliability
  • Ease of use
  • Internationalization
  • Usability
  • Market goals
  • Performance
  • Team structure


The third group tackled design quality by first investigating who in a software development project has interest on high-quality software designs. The came up with the following list of roles:


  • User
  • Architect
  • Designer
  • Developer
  • Maintainer
  • Tester
  • Manager
  • Technical Writer
  • Marketer

Based on this list, they discussed design properties that are of interest for the different project participants:


  • Clarity
  • Simplicity
  • Scalability
  • Modifiability
  • Extendibility
  • Reusability
  • Effectiveness
  • Reliability
  • Robustness
  • Security
  • Cost


The following design components should address above properties:


  • Classes
  • Interfaces
  • Class hierarchy
  • Aggregation hierarchy
  • Delegation hierarchy
  • Relationships
  • Ownership
  • Objects
  • Containment
  • Patterns
  • Frameworks


Time limits did not allow for creating a matrix mapping roles, properties, and components, but the workshop participants agreed that such a matrix would be of great value for software professionals.


Concluding Remarks


Workshop participants concluded in unison that the goodness of software design depends on the perspective from which one investigates it. Traditional OO complexity metrics can provide an analysis foundation, yet can lead to misguided analysis of the overall architecture as they may over- or undervalue certain perspectives. A better form of analysis of overall design quality is to evaluate it against the requirements and trade-offs made during system conceptualization, analysis, and design. An indicator for a good OO design is if it allows the viewer to reason on its architectural structures and design intents. To achieve quality in OO design, it is essential that design be addressed from different perspectives, each evaluated against a list of pre-established quality properties. To accomplish this, powerful tool support for documentation, measurement, and architectural reasoning is prerequisite.




This reference list contains the position papers of the workshop participants. They are published in electronic format at <http://www.iro.umontreal.ca/~keller/ Workshops/OOPSLA97/>.


[1] Joe Raymond Abounader and David Alex Lamb, Queen's University, Kingston, Ontario, Canada: Object-Oriented Design.

[2] Jagdish Bansiya, University of Alabama, Huntsville, AL, U.S.A.: Assessing Quality of Object-Oriented Designs Using a Hierarchical Approach.

[3] Saïda Benlarbi, CRIM, Montreal, Quebec, Canada: Object-Oriented Design Metrics for Early Quality Prediction.

[4] Shai Ben-Yehuda, SELA Labs, Israel: Object-Oriented Design Quality.

[5] Lionel Briand, J. Daly, V. Porter, and J. Wuest, Fraunhofer IESE, Kaiserslautern, Germany: The Dimensions of Coupling in Object-Oriented Design.

[6] Greg Butler, Concordia University, Montreal, Quebec, Canada: Documenting In Good Design.

[7] Jeromy Carrière and Rick Kazman, Software Engineering Institute, CMU, Pittsburgh, PA: Assessing Design Quality From a Software Architectural Perspective.

[8] Gerald Ehmayr and Werner Retschitzegger, Johannes Kepler University, Linz, Austria: Proactive Object Modeling - What can we Learn from Components and Interfaces?

[9] Eduardo Fernandez, Florida Atlantic University, Boca Raton, FL, U.S.A. Good Analysis as the Basis for Good Design and Implementation.

[10] Thomas Grotehen and Klaus R. Dittrich, University of Zürich, Switzerland: Object-Oriented Design with MeTHOOD.

[11] Walter Kriha, Daniel Kesch, and Stephan Pluess, Systor AG, Basel, Switzerland: Object-Oriented Design Quality Through Architectural Structures.

[12] Bruno Laguë and Charles Leduc, Bell Canada, Longueuil, Quebec, Canada: Assessment of the Partitioning of large OO design in Files using Metrics.

[13] Kai-Uwe Mätzel and Dirk Riehle, Ubilab, Zürich, Switzerland: Object-Oriented Design Quality.

[14] Tom O'Rourke, PaineWebber Inc.: Guerilla Design Evaluation Heuristics.

[15] Kumaraswamy Ponnambalam, University of Waterloo, Waterloo, Ontario, Canada: Characterization and Selection of Good Object-Oriented Design.

[16] Reinhard Schauer and Rudolf K. Keller, Université de Montréal, Montreal, Quebec, Canada: Software Quality by Design Composition.