Object-Oriented Analysis and Design

Object-Oriented Analysis and Design Lecture 7 Metrics for O-O Design

Principles for O-O Design • Encapsulation • “Connascence” • Domains • Cohesion

Encapsulation Class/ object Raw lines of code Procedural module Level 0 Level 1 Level 2

Encapsulation • First, there was machine code, and then assembly language. • Then there were functions/procedures. • Then there were classes. • Then there were…what?

Packages • Groups of classes • “Horizontally” (by subject area), e.g., • Passengers • Aircraft • Personnel • “Vertically” (by business activity), e.g., • Banking • Securities • Real estate

Design Criteria • These govern (and measure) “goodness” of interaction. To: Lines of code Procedure From: Structured programming Lines of code Fan-out Procedure Cohesion Coupling

Design Criteria • Structured programming: three structures: • Sequence of instructions • Selection of instructions (if-then-else) • Iteration of instructions • Fan-out: number of references to other procedures by code in a given procedure • Cohesion: “single-mindedness” of code within a procedure • Coupling: number and strength of connections between procedures

Extension to Classes To: Lines of code Procedure Class From: Structured programming Lines of code Fan-out - Procedure Cohesion Coupling - Class cohesion Class coupling - Class

Class Interdependencies (“Connascence”) • Software elements a and b are interdependent if • Some change to a requires a change to b to maintain correctness, or • Some change elsewhere requires both a and b to be changed.

Examples • Lines of code: • Functions: • Classes: • Sometimes directional, sometimes non-directional int i = 3; … i++; void myFunction() { … int j = yourFunction(); } Class Elephant { Trunk t; … }

More Examples • Connascence of name: subclass inherits a variable, it must use the same name. • Connascence of convention: in C++, a non-zero int is considered TRUE. Also, enumeration types. • Connascence of algorithm: Binary search expects the members of a Tree to be sorted ascending.

Dynamic Connascence • Connascence of execution: this is what sequence diagrams are for. • Connascence of value: corners of a rectangle must have a certain relationship; redundant databases. • Connascence of identity: two reference-counted string objects pointing to the same character array.

“Contranascence” • Connascence implies that two things are related; contranascence implies that two things are distinct. • Class A has an int i, so does class B. But they are different. • If multiple inheritance is allowed, this can be a problem.

Connascence & Encapsulation • Encapsulation is a way of controlling interdependencies. • You write some C code, with global variable myVar. I do the same. We try to join our code… • I look at your code, and see two lines, one after the other. Must they be together?

Encapsulation • Back to the tree example: • Some code inserts into the tree • Some code reads from the tree • If we find a better storage structure, all this code needs to change. • Make the tree a class, with well-defined public methods, and these problems go away.

Good Rules • Minimize overall dependencies by breaking the system into encapsulated elements. • Minimize dependencies across encapsulation boundaries. • Maximize dependencies within encapsulation boundaries.

Good, Bad, Ugly Level 3 Level 3

Other Dangers • Friend classes and functions in C++ • Overuse of inheritance with protected members. • Relying on a specific implementation (e.g., inserting into a map)

Class Domains • Application domain: classes are useful for one (or just a few) applications • Event-recognizer classes (fuel mixture too rich) • Event-manager classes (reduce injector pressure) • Very narrow reusability

Class Domains • Business domain: classes for one business or company • Attribute classes (AlloyType) subject to business rules • Role classes (WingSpar) • Relationship classes (AccountOwnership) resulting from associations

Class Domains • Architecture domain: classes used in one style of implementation • GUI classes (Window, Button) • Database classes (Transaction) • Machine communication classes (Socket) • Useful across many businesses and applications, but only on a single architecture

Class Domains • Foundation classes: classes useful in all businesses and architectures • Fundamentals: Int, Complex, Boolean • Structural: Stack, List, Array • Semantic: Date, Time, Currency • These are the most valuable for reuse.

Where Do Classes Come From? • Foundation classes: buy them! • Everyone needs them, they’re high volume commodities, so relatively inexpensive. • They’re well tested. • Architectural classes: buy them if you can. • Microsoft, Sun, etc. • Watch out for nagging incompatibilities between vendors. • Were two sets of classes built on the same foundation classes?

Where Do They Come From? • Business classes • Available for more and more businesses. • They will likely need to be tailored---that’s why we have subclassing! • Probably more volatile; what’s the change history? • Maybe better to build yourself.

Encumbrance • All the classes that a given class needs in order to work. • A way to think of the domain of a class. • This can be measured.

Direct Class References • A inherits from B • A has an attribute of type B • A has a method with argument of type B • A has a method with return type B • A has a method with local variable of type B • A supplies B as a parameter type • C has a friend class D (but this implies one of the above?)

Indirect Class References • Class A has direct class references to A1, A2, …, An • A has indirect class references to those classes directly and indirectly referenced by A1, A2, …, An (recursive definition) • Direct encumbrance is the count of direct class references • Indirect encumbrance is the count of indirect class references

The Law of Demeter • Inside a method it is only permitted to access or send messages to the following objects: • The arguments associated with the method being executed, • Instance variables defined in the class containing the method being executed, • Global variables, and • Temporary variables created inside the method. • Variants to #2: access instance variables only through accessor functions.

Class Cohesion • A measure of the interrelatedness of a class’s public interface. • Low cohesion indicates that the class does many different things. • High cohesion suggests a class is a good conceptual “chunk”.

Types of Class (In-) Cohesion • A class with mixed-instance cohesion has some features that are undefined for some objects of the class. Class GuitarAmp { int volumeSetting; int bassSetting; int trebleSetting; int toneSetting; }

Types of Class (In-) Cohesion • A class with mixed-domain cohesion contains an element that directly encumbers the class with an extrinsic class of a different domain. • (The class B is extrinsic to A if A can be defined with no knowledge of B.) class List { Product headOfList; … }

Types of Class (In-) Cohesion • A class C has mixed-role cohesion if it contains an element that directly encumbers the class with an extrinsic class that lies in the same domain as C. class Course { int NumQuizzes; … }

Part II • Process improvement depends on metrics. • What metrics are right for O-O design? • One contender: Chidamber & Kemerer: “A Metrics Suite for O-O Design,” (IEEE TSE `94) • Verification study by Basili et al. `95 (U. Maryland CS Dept. CS-TR-3443) • Let’s look at both:

Background • Increased emphasis on the process of software development. • Wholesale movement toward O-O languages and methodologies. • Can `80’s metrics of complexity hold up? • lines of code • “cyclomatic complexity” • “fan-in, fan-out” • function points

Background (cont.) • Why is measuring complexity important? • cost estimation (assuming complexity can be measured early) • estimation of resource allocation for • building • testing

Criticisms of Older Metrics • Not “theoretical”: • no basis in sound theory • lacking “appropriate mathematical properties” • unpredictable behavior • Not “O-O”: • based on functional decomposition • O-O induces different problem-solving behavior

What C & K Provide • They propose new metrics • Evaluate them against normative criteria • Illustrate them in real-world settings

Where Are They Used? • In the context of Booch’s (or anybody’s) OOD. The steps: • identify classes • identify semantics • identify relationships • implement • In the class design stage • Dynamic complexity is not measured

Measurement Theory • Basically, measurement moves from empirical relations to quantitative ones. • We have a subjective notion of what makes an O-O design D complex: A is a set of objects R’s are empirical relations on objects (e.g., >, <) O’s are binary operations on elements of A (e.g., combination)

What? • The empirical relations satisfy our intuitions (class A is more complex then class B,...) • The binary operations let us combine intuitions (e.g., two classes combined give a more complex class). • A “viewpoint” • summarizes this, and • has nice properties • transitivity, etc.

I Said, “What?” • We do this all the time: empirical relations become quantitative systems. • Think of • meters • kilograms • grades (!) • now, complexity...

Objects • Object X = (x, p(x)), where • x is the individual and • p(x) is the set of its properties (think of attributes and methods)

Viewpoints • Coupling: “Two objects are coupled if one of them acts upon the other. X acts on Y if Y’s history of states is affected by X.” • Given then any action by a method of Mx which acts on either My or Iy constitutes a coupling.

Examples • X alters a public instance variable of Y • X calls a public method of Y • X calls a public or protected method of a superclass of Y • X calls a member of Z, which calls a member of Y.

Another Viewpoint • Cohesion: “...the degree of internal consistency within the parts of a design.” • A measure of a class, relating to encapsulation. Define similarity of two methods within a class: If all the methods in a class are similar, in that they perform different operations on the same set of instance variables, then the class is cohesive.

Other Measures • Complexity of an object: how many members does it have? • Scope of properties: roughly, how wide and deep is the inheritance hierarchy? • depth of inheritance • number of (immediate) children

More Measures • Measures of communication: think of methods as responses to messages; define • Response set of a class: all methods that can be invoked in response to a message to an object of the class. • This may include methods outside the class as well as global functions.

Desirable Properties • Non-coarseness: there are in fact two classes that measure differently. • Non-uniqueness: there may be two classes that measure the same. • Importance of design details: two classes with the same functionality may measure differently.

More Desirable Properties • Monotonicity: the measure of the combination of two classes is greater than the measure of either. • Non-equivalence of interaction: suppose X and Y measure the same; there may be a Z such that X+Z measures differently from Y+Z • Interaction increases complexity: The measure of X+Y is greater than the measure of X plus the measure of Y

Weighted Methods Per Class Consider a class C with methods M1,...,Mn and let c1,..., cn be the complexity of these methods. Then set

Object-Oriented Analysis and Design