Rakesh Kumar et al. / International Journal of Engineering Science and Technology (IJEST)
OBJECT ORIENTED DESIGN HEURISTICS RAKESH KUMAR Department of Computer Applications, Kurukshetra University, Kurukshetra, Haryana, India
DEEPALI GUPTA Geeta Institute of Management and Technology, Department of Computer Science, Kurukshetra University, Kurukshetra, Haryana, India
[email protected] Abstract Object-oriented design is a process of identifying relevant objects, factoring them into classes, organizing hierarchically, and establishing dynamic collaborations among the objects. It is a difficult process especially for novice designers. In order to guide the novices, software engineers used some hints, guidelines and tips to communicate design experience from the expert. Design heuristic is common solution to design problems that developers encounter during software development. Heuristic is defined as the use of general knowledge gained by experience. Design heuristics are design experience from object-oriented developers. It is small and simple design expertise. This knowledge from the experienced designers is used to guide the novices. The purpose of this paper is to document design heuristics of object-oriented approach from literature study. Keywords- Heuristics, Object Oriented Design, Software Metrics and Software Engineering. 1. Heuristics in Software Engineering A heuristic is described as explicit and non-explicit knowledge necessary in order to organize the sequence of thinking operations, including modifying operations (searching and finding) and testing operations (checking and assessing) [Pahl and Beitz, (1996)]. More commonly, it is a general procedure or rule of thumb, which is used to suggest solutions or strategies for solving a problem, often in the absence of “deep” knowledge about a system [Dasgupta, (1996)]. Central to the concept of heuristic design is the understanding that a heuristic is not necessarily prescribed solution. This is, in fact, the key distinction between heuristic and “rule of thumb.” Whereas a rule of thumb generally provides an estimated or default value for some parameter, a heuristic suggests an avenue for further investigation. More commonly, a heuristic simply suggests a method of attack for solving a particular problem. The heuristics are not written as hard and fast rules; they are meant to serve as warning mechanisms which allow the flexibility of ignoring the heuristic as necessary. Use of heuristics in modern OO software engineering has also been observed [Churcher, (2007)]. Design is a difficult task because it involves finding compromises between conflicting pressures, cost and reliability and many of these pressures ultimately arise from human concerns, with all that implies in complexity, diversity and changeability. Object-orientation (OO) allows software to be structured in a way that helps to manage complexity and change. However, as software reuse practitioners have discovered, realizing the benefits of OO is not straightforward. Competence with the mechanisms of OO classes and objects, attributes and methods, inheritance and polymorphism is far from sufficient to ensure successful designs. Over some decades, software engineers have developed a number of approaches and principles to elevate design considerations above programming language mechanisms. Concepts such as abstraction, separation of concerns, information hiding, cohesion and coupling provide guidance to designers. On top of these general principles, the OO design community has developed a rich doctrine of principles and practices to inform designers. This is supplemented by design patterns and idioms, which provide prototypical solutions to common problems. Some authors have collated parts of this complex web of concepts into sets of heuristics. Riel [Riel, (1996)] has categorized design heuristics into eight categories; Class and objects, topologies of action-oriented versus object-oriented application, the relationship between class and objects, inheritance relationship, multiple inheritance, association relationship, class-specific and data-behavior, and physical object-oriented design; which accumulated into sixty guidelines. Johnson and Foote [Johnson and Foote, (1988)] provide an early example, which describes design maxims intended to promote reuse. Riel [Riel, (1996)] documents 61 ‘golden rules’ for OO design, while Fowler and Beck describe 22 code smells [Fowler, (1999)]. Smells evokes a subjective, subtle process of perceiving something about a design. Beck and Fowler note that code smells do not lend themselves to automatic
ISSN : 0975-5462
Vol. 3 No. 1 Jan 2011
459
Rakesh Kumar et al. / International Journal of Engineering Science and Technology (IJEST)
quantification [Fowler, (1999)]. The designer must form an impression of the net product of many factors at work in the design. This requires judgment and insight beyond the capabilities of simple automata. Class is a concept that captures the notion of data and behavior in one package. The relationship between the notion of class and object is instantiation relationship. In addition to fixed data and behavioral descriptions, objects have local state (i.e., a snapshot) at runtime of the dynamic values of an object's data descriptions. The collection of all possible states of a class's objects, along with the legal transitions from one state to another, is called the dynamic semantics of the class. Dynamic semantics allow an object to respond differently to the same message sent at two different times in the life of the object. Classes with interesting dynamic semantics include those classes having a finite number of states, with welldefined transitions from one state to another. Abstract classes are the classes that do not know how to instantiate objects where as classes that do know how to instantiate objects are called concrete classes. The object-oriented paradigm uses the concepts of class and object as basic building blocks in the formation of a consistent model for the analysis, design, and implementation of applications. There are many things in the real world that we are capable of using without knowing anything about their implementation: refrigerators, cars, photocopy machines, and computers, just to name a few. The reason they are easy to use without knowledge of their implementation is that they are designed to be used via a well-defined public interface. This interface is heavily dependent on, but hides from its users, the implementation of the device. All implementation constructs in your system should be hidden from their users behind a well-defined, consistent public interface. Users of the construct need to know about the public interface but are never allowed to see its implementation. This allows the implementer to change the implementation whenever he or she desires, so long as the public interface remains the same. Classes and Objects are the Building Blocks of the Object-Oriented Paradigm. Some of the heuristics proposed by Riel [Riel, (1996)] are listed in Table 1 as follows:
Table 1. List of heuristics proposed by Riel.
Sno. 1 2 3 4 5
Heuristics All data should be hidden within its class. Users of a class must be dependent on its public interface, but a class should not be dependent on its users. Minimize the number of messages in the protocol of a class. Implement a minimal public interface that all classes understand.
8
Do not put implementation details such as common-code private functions into the public interface of a class. Do not clutter the public interface of a class with things that users of that class are not able to use or are not interested in using. A class should only use operations in the public interface of another class or has nothing to do with that class. A class should capture one and only one key abstraction.
9
Keep related data and behavior in one place.
10
Spin off non related information into another class (i.e., non communicating behavior).
11
Be sure the abstractions that you model are classes and not simply the roles objects play.
6 7
A notable characteristic of design patterns is that they often break rules. For example, the Composite pattern advocates the use of methods that are overridden to do nothing, contrary to a common maxim, expressed by Riel’s heuristic as “It should be illegal for a derived class to override a base class method with a NOP method, i.e. a method which does nothing.” However, the Gang of Four chose to break this rule deliberately, in their words preferring transparency over safety. Many similar examples of conflicting forces can be found. Some conflicts are so pervasive that they apply to nearly all design situations. Separation of concerns, for example, encourages decoupling portions of a design, while another heuristics, “Keep related data and behavior
ISSN : 0975-5462
Vol. 3 No. 1 Jan 2011
460
Rakesh Kumar et al. / International Journal of Engineering Science and Technology (IJEST)
in one place” often suggests the opposite. Even within an organized set of heuristics, conflicts occur. One heuristic says “Theoretically, inheritance hierarchies should be deep, i.e. the deeper the better”, while another adds the qualification that “In practice, inheritance hierarchies should be no deeper than an average person can keep in his or her short-term memory. A popular value for this depth is six”. Heuristics are a valuable tool for identifying design forces (whether conflicting or not) and evaluating design quality, but their application is not straightforward for many reasons [Churcher, (2007)], such as: Lack of consensus on which heuristics should be adopted: Some conflicting heuristics usefully illuminate matters of concern to the designer. Other conflicts, however, reflect differing design philosophies, and a particular designer is likely to be interested only in one side of the debate. Many of the tenets arising from software reuse culture, for example, are in opposition to more recent refactoring and agile methods approaches. The open/closed principle, for example, encourages anticipation of future needs by making the design open for extension (reusable), but without requiring modification of existing code; refactoring culture discourages anticipation of future needs and prefers modifying existing code when necessary. This cultural difference might show up in unexpected ways, such as a stronger preference for small methods in the reuse culture, so that methods constitute small overridable units. Nebulous definitions: One heuristic, for example, says “A class should capture one and only one key abstraction”, but rigorously specifying the meaning of “key abstraction” is problematic. Similarly, heuristic “Model the real world whenever possible”, is only as firm as our grip on reality. Subjectivity and calibration: Code smells require the designer to judge when some intangible threshold has been crossed. The “large class smell”, “lazy class smell” and “long method smell” are obvious examples where different standards might apply. The relative importance of conflicting heuristics is also dependent on the value system of the designer. If breaking up a large class produces a lazy class, is the result better? Interpretation in different contexts: Many heuristics are expressed abstractly, in order to apply to any OO design. It may be necessary, however, to adapt a heuristic to local conditions. For example, when deciding if an inheritance hierarchy is too deep, should the root class be counted in programming languages that enforces a single root? Or, in an organisation that has adopted a refactoring approach to software development, how much emphasis should be placed on a heuristic motivated by software reuse, such as heuristic “All base classes should be abstract classes”? Diverse levels of abstraction. Some heuristics can be interpreted at different levels. For example, “All data should be hidden within its class”, might be viewed as a syntactic restriction—make attributes private—or as a semantic one, which might also discourage the use of getters. A “long method smell” could be detected at a lexical level by counting lines of code, at a syntactic level by counting statements and expressions, at a language semantic level by counting method invocations, collaborators, etc, or at a problem-domain semantic level by gauging the conceptual size of the method. Information overload: Heuristics are intended to help software engineers manage the complexity of software, but injudicious application of heuristics could compound the problem. Acquiring relevant data and relating it to heuristics: Many heuristics require substantial data gathering. Heuristic “Minimize fan-out in a class” and another “Most of the methods defined on a class should be using most of the data members most of the time” are examples. Additionally, the correspondence between available information and heuristics is not always clear. These issues, and the inherent fuzziness of heuristics, make automated support of heuristics difficult. In consequence, designers usually must gauge the quality of their products without assistance from tools. The designer builds a mental model of the software, and evaluates, according to a subjective, and perhaps even subconscious, process that is likely to be informed by heuristics, but may explicitly apply few. Heuristics are an important part of software design and are becoming more widely used. Effective visualization of heuristics includes quantitative, qualitative and ambient aspects. Visualization of heuristics provides many challenges. Heuristics are likely to be studied both individually and in comparison with others.
2. Role of Heuristics and Metrics Software metrics and heuristics based on them suggest ways to help designers with the task of understanding, evaluating and improving their products. Software design and development involves a range of practices with varying levels of formality: examples include formal methods, coding styles, design patterns and test-driven development. The common goal is the production of high quality software. However, quality is a concept that can not be measured directly. In order to measure and understand quality, it is necessary to relate it to measurable quantities. The field of software metrics deals with the identification of meaningful quantitative measures of specific properties of software. Heuristics enable a ‘softer’ model to be constructed in order to obtain a more holistic and subjective, view of quality. This potentially places a greater burden on the developers who must interpret this view since it consists of potentially conflicting indicators with varying degrees of
ISSN : 0975-5462
Vol. 3 No. 1 Jan 2011
461
Rakesh Kumar et al. / International Journal of Engineering Science and Technology (IJEST)
precision and relevance. Heuristics may occur as individual pieces of developers’ or may be presented as a suite covering multiple aspects of software development. Metric-based heuristic framework to detect and locate object-oriented design flaws from the source code [Salehie et al., (2006)]. It is accomplished by evaluating design quality of an object-oriented system through quantifying deviations from good design heuristics and principles. While design flaws can occur at any level, the proposed approach assesses the design quality of internal and external structure of a system at the class level which is the most fundamental level of a system. 3. Heuristics for object oriented Design Design evaluation is effective and beneficial to both expert and novice designers during software development process. Design heuristics are proposed as a more accessible and informal means by which developers can evaluate OO software. Software heuristics are small, simple, legible, self-contained nuggets of design expertise. They target specific design problems within OO software and provide guidance on how to affect a solution. Unlike metrics, heuristics are outwardly defined in terms of the observable problems that occur during OOD and not low level design concepts such as coupling, cohesion and size. Instead, the lessons learned from applying these design concepts throughout metric research provide a solid theoretical foundation that heuristics build upon to document recurring and observable problems within OO systems. Design heuristics are: available to all developers performing OOD; applicable within a number of software domains; permit small, incremental enhancements to maintainability; provide a common vocabulary for expressing design problems [Gibbon, (1997)]. Heuristics offer insightful information based upon experience that is known to work in practice. They provide a means by which knowledge and experience can be delivered from the expert to the novice. To achieve this goal, heuristics must identify and encapsulate experience; their subsequent application ultimately results in the reuse of this experience. A heuristic is not a metric, nor vice-versa. A heuristic is a rule of thumb that places its users in the region of what is correct [Booch, (1995)]. It is not meant to be exact; in fact, heuristics derive their benefits from this imprecision by providing an informal guide to good and bad practices. In short, metrics define what complexity is and what needs to be done to reduce it, whereas heuristics provide the knowledge and judgement. For example, when determining what to do with a complex class in an unstable inheritance hierarchy, the metric provides a means to determine when a class is complex or when an inheritance hierarchy is unstable. It is the heuristic that makes informed decisions in light of these metric observations, taking into consideration the subtleties of the paradigm and context in which the design elements are set. In the context of OOD, a design heuristic focuses upon a single, self-contained design problem. The design heuristic not only imparts knowledge of the documented problem but also the ways in which to solve it. By representing small yet focused design problems, heuristics are applicable within a number of diverse software domains and at different phases of the life-cycle. Typically, the problems documented by design heuristics are visible as early as the latter stages of analysis right through to implementation. Riel [Riel, (1996)] presented heuristics in an example-driven manner that focused directly upon the need and use of OOD heuristics within software development. However, there were no common mechanisms for documenting the design heuristics as self-contained, transferable pieces of design expertise, no means by which to describe how they inter-relate and no plan of how to deploy heuristics in support of an informal approach to design evaluation. Furthermore, although a number of Riel's design heuristics were qualitative, those that could be automated were not. Gibbon [Gibbon, (1997)] proposed Design heuristics and developed a design heuristic catalogue and automated the heuristic in a tool named TOAD (Teaching Objected Oriented Analysis and Design). Gibbon uses design heuristics as a form of informal design evaluation to identify design flaws. There are two main types of design heuristic namely class and relationship. Class heuristics are the simplest type of heuristic that acts upon individual classes. They evaluate class properties pertaining to method complexity, size, behavioural content, and encapsulation, mechanisms that breach information hiding, centralised control, and so on. They are purposefully simple and typically used in conjunction with relationship heuristics. Relationship heuristics are defined for the inheritance, aggregation and using class relationships. A relationship heuristic acts upon a group of classes, or class group, that participates in a specific class relationship. A head class is representative of a class group such that all relationship heuristics are directed at the head classes. For example, the head class in an inheritance relationship is the root of a class hierarchy and the members of the class group are its descendent classes. Design heuristics are shown to be concentrated pieces of design expertise that deliver knowledge and experience from the expert to the novice. These need to be small, simple and legible in order for them to be useful to the majority of developers performing design evaluation.
ISSN : 0975-5462
Vol. 3 No. 1 Jan 2011
462
Rakesh Kumar et al. / International Journal of Engineering Science and Technology (IJEST)
4. Conclusion Today’s practices of software metrics utilize global indicators, which provide insights into improving the software development and maintenance process. The improved process helps to achieve organizational goals established for improving software quality and development team productivity. The use of metrics can be a valuable aid in understanding the effect of actions that are implemented for improving the software development process. The metrics provide visibility and control for the complex software development process, and therefore they are valuable for providing guidance on improving the software development process, and for meeting organizational goals to improve software quality and productivity. Object oriented heuristics encapsulate software problems and their solutions and provide a link between sets of software development principles and quantitative software metrics to produce high quality software. Metrics use in the future will be applied more frequently for the prevention of faults within a feedback mechanism to analyze where problems have occurred so that the development process can be improved, which will reduce the time delays from the point when a software development process improvement is implemented to when it positively impacts quality and productivity. References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25]
S.R. Chidamber and C.F. Kemerer, “A Metric Suite for Object Oriented Design”, IEEE Trans. on Software Engineering, Vol. 20, pp. 476-493, 1994. S.R. Chidamber and C.F. Kemerer, “Towards a Metrics Suite for Object Oriented Design,” 11, pp.197-211. Paul Goodman, “Practical Implementation of software Metrics”, McGraw Hill Book Company, UK, 1993. Software Engineering: “A Practitioner’s Approach”, Sixth Edition by Roger S. Pressman. Harrison, Counsell and Nithi. “An Evalution of mood Set for Object Oriented Software Metrics”, IEEE Transactions on Software Engineering, Vol.SE-24, #6, June 1998, pp. 491-496. Basili, V.R., Briand, L.C., Melo W.L., “A Validation of Object-Oriented Design Metrics as Quality Indicators”, IEEE Transactions on Software Engineering, vol.22, no.10, Oct 1996, pages 751 – 761 Lem O. Ejiogu, Software engineering with formal metrics, QED Information Sciences, Inc., Wellesley, MA, 1991. Subramanyam, R. and Krishnan, M.S., “Empirical Analysis of CK Metrics for Object-Oriented Design Complexity: Implications for Software Defects”, IEEE Transactions on Software Engineering, vol.29, no.4, April 2003, pages 297 – 310. Lorenz, M., and J. Kidd, Object-oriented software metrics, prentice-Hall, 1994. Grady, R.G., Practical Software Metrics for Project Management and Process Improvement, Prentice-Hall, 1992. Hetzel, W., Making Software Measurement Work, QED Publishing Group, 1993. Churcher, N., “Supporting OO Design Heuristics”, Proceedings of the 2007 Australian Software Engineering Conference, IEEE Computer Society, pp. 101—110, 2007. Möller, K.H. and Paulish, D.J., Software Metrics: A Practitioner's Guide to Improved Product Development, 1993. Johnson, R. and Foote,B., “Designing reusable classes”, Journal of Object-Oriented Programming, vol 1, no.2 , pp. 22--35 , 1988. Riel, A., Object-Oriented Design Heuristics, Addison-Wesley, 1996. Fowler, M., Refactoring: Improving the Design of Existing Code, Addison - Wesley, 1999. Bieman, J.M. and L.M. Ott, “Measuring Functional Cohesion,” IEEE Trans. Software Engineering, vol. SE-20, no. 8, August 1994, pp. 308–320. Dhama, H., “Quantitative Models of Cohesion and Coupling in Software,” Journal of Systems and Software, vol. 29, no. 4, April 1995. Sears, A., “Layout Appropriateness: A Metric for Evaluating User Interface Widget Layout, IEEE Trans. Software Engineering, vol. SE-19, no. 7, July 1993, pp. 707–719. Binder, R. V., “Object – Oriented Software Testing”, CACM, VOL. 37, NO. 9, September 1994, pp. 29. Salehie, M., Li, S., Tahvildari, L., “A Metric-Based Heuristic Framework to Detect Object-Oriented Design Flaws”, Proceedings of 14th IEEE International Conference on Program Comprehension, IEEE Computer Society, pp. 159—168, 2006. Booch, G., Rules of thumb, Report on Object Analysis and Design, 2(4), Nov-Dec 1995, pages 2-3. Gibbon, C.A, PhD Thesis, Object-Oriented Design Heuristics, University of Nottingham, 1997. Pahl G, Beitz W, Engineering design: a systematic approach, Springer-Verlag, Berlin Heidelberg New York, 1996. Dasgupta, S., Technology and creativity, Oxford Press, London, 1996.
ISSN : 0975-5462
Vol. 3 No. 1 Jan 2011
463
