Object oriented analysis and design
Download
1 / 83

Dependencies - PowerPoint PPT Presentation


  • 398 Views
  • Updated On :

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Dependencies' - issac


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Object oriented analysis and design l.jpg

Object-Oriented Analysis and Design

Lecture 7

Metrics for O-O Design


Principles for o o design l.jpg
Principles for O-O Design

  • Encapsulation

  • “Connascence”

  • Domains

  • Cohesion


Encapsulation l.jpg
Encapsulation

Class/

object

Raw lines

of code

Procedural

module

Level 0

Level 1

Level 2


Encapsulation4 l.jpg
Encapsulation

  • First, there was machine code, and then assembly language.

  • Then there were functions/procedures.

  • Then there were classes.

  • Then there were…what?


Packages l.jpg
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 l.jpg
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 criteria7 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
“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 l.jpg
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?


Encapsulation15 l.jpg
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 l.jpg
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 l.jpg
Good, Bad, Ugly

Level 3

Level 3


Other dangers l.jpg
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 l.jpg
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 domains20 l.jpg
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 domains21 l.jpg
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 domains22 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 cohesion31 l.jpg
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 cohesion32 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
What C & K Provide

  • They propose new metrics

  • Evaluate them against normative criteria

  • Illustrate them in real-world settings


Where are they used l.jpg
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 l.jpg
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)


Slide40 l.jpg
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 l.jpg
I Said, “What?”

  • We do this all the time: empirical relations become quantitative systems.

  • Think of

    • meters

    • kilograms

    • grades (!)

    • now, complexity...


Objects l.jpg
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 l.jpg
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.


Examples44 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
Weighted Methods Per Class

Consider a class C with methods M1,...,Mn

and let c1,..., cn be the complexity of these

methods. Then set


Properties of wmc l.jpg
Properties of WMC

  • There can be two classes that measure differently

  • There can be two classes that measure the same

  • The choice of number of methods is a design decision

  • Etc.

  • But,

  • Empirical data: most classes < 10 methods.


Depth of inheritance tree l.jpg
Depth of Inheritance Tree

  • A class is measured according to how far down it is in its tree.

  • A class deeper down is likely to inherit more methods, making its behavior more complex.

  • Deeper trees suggest greater design complexity.

  • The deeper the class, the greater the reuse potential for inherited methods.


More on dit l.jpg
More on DIT

  • Properties 4 (monotonicity) & 6 (interaction increases complexity) are violated.

  • Empirical data

    • C++ GUI class hierarchy was seldom deeper than 4 (“top-heavy”). Maybe not taking advantage of reuse potential.

    • Smalltalk engineering classes, a uniform distribution over 1-7.

    • One class with DIT = 8, 132 methods...


Number of children l.jpg
Number of Children

  • The more children, the more reuse.

  • The more children, the greater chance for improper abstraction.

  • More children mean more influence on the design (more testing too?).


More on noc l.jpg
More on NOC

  • Property 6 violated.

  • Empirical data: 70% of classes had no children. Suggests reuse through inheritance not being adopted?

  • Lack of communication between designers?

  • Design practices dictated shallow trees?


Coupling between classes l.jpg
Coupling Between Classes

  • Count the number of other classes to which a given class is coupled.

  • Excessive coupling is bad for modular design & reuse.

  • The larger the number of couples, the higher the sensitivity to changes in design.

  • More coupling, greater complexity in testing.


More on cbc l.jpg
More on CBC

  • Property 6 not satisfied.

  • Empirical data: Smalltalk site measured much larger (the nature of the language?).

  • The Smalltalk library was much larger. Coupling increases with size?

  • 50% of classes at both sites had no coupling.


Response for a class l.jpg
Response For a Class

  • The size of the response set (all methods that can be invoked in response to a message to the class).

  • Larger implies more testing.

  • More methods means greater complexity.

  • Helps allocate testing time.


More on rfc l.jpg
More on RFC

  • C++ site binomial out to 60, Smalltalk binomial out to 210.

  • By using high RFC classes as focus of testing, broader coverage results.


Lack of cohesion in methods l.jpg
Lack of Cohesion in Methods

  • Example: Suppose class C has methods M1, M2, M3. Let I1 = {a,b,c,d} be the variables used by M1, I2 = {a,b,e} and I3 = {x,y,z}.

  • I1Ç I2 is nonempty, but the other two intersections are empty.

  • LOCM is then 2 - 1 = 1.

  • Lower LCOMs are “better”.


More on lcom l.jpg
More on LCOM

  • Cohesiveness desirable, since it promotes encapsulation.

  • Lack of cohesion implies the class should be split.

  • This measure helps identify design flaws.

  • Low cohesion increases complexity.

  • Empirical: median values around 2. One class had LOCM=200; what would this be?


What about property 6 l.jpg
What about Property 6?

  • It says that complexity should decrease when a class is divided into more classes.

  • Experienced designers say that more classes make memory management and run-time error detection more difficult.


Implications for managers l.jpg
Implications for Managers

  • Designers tend to keep inheritance hierarchies shallow.

    • reduces complexity

    • reduces opportunities for reuse

  • These metrics can

    • help manage reuse opportunities

    • alert misuse of subclassing

    • help allocate testing resources

    • help maintain architectural control


Validation of o o design metrics as quality indicators l.jpg
“Validation of O-O Design Metrics as Quality Indicators”

  • Basili et al., Maryland CS

  • Premises:

    • Accurate info essential to managers

    • Scheduling & resource allocation require metrics

    • Where to test for best effect?

    • Metrics reflecting the specificities of O-O must be defined and validated.


Experimental goals design l.jpg
Experimental Goals, Design

  • Evaluate whether the C-K metrics are useful in predicting probability of faulty classes.

  • All six C-K metrics studied.

  • Four month study, graduate CS class.

  • Students had C++, RBDMS courses.

  • Analysis, design, implement, test, repair

  • Documents delivered after each phase.


Experiment cont l.jpg
Experiment (cont.)

  • OMT was used, as were C++, GNU, Motif.

  • Subjects given MotifApp, GNU library, C++ database classes, no special training.

  • Sample Motif library programs provided.

  • Video store problem.


Data collection l.jpg
Data Collection

  • Source code

  • Defect report form

  • Component origination form

  • Repaired code

  • C-K metrics, automated

  • Defective modules


Analysis l.jpg
Analysis

  • Binary response variable (fault yes/no)

  • Regression to see which metrics predict faults

  • They found:

    • WMC has very low p for new/highly modified classes

    • DIT was very significant (always)

    • RFC was always significant


More results l.jpg
More Results

  • NOC was very significant

    • Larger NOCs correlated with smaller defect probability

    • Explanation: most of the classes with large NOC reused verbatim

  • LCOM insignificant

  • CBO significant, especially for UI classes


Other results l.jpg
Other Results

  • For a multiple regression model,

    • 80 classes out of 180 would be predicted faulty (so inspected); 48 out of 58 faulty classes would be identified before testing

    • 250 out of 268 faults would be detected during pre-testing inspection


Example 7 minute presentation l.jpg
Example 7 Minute Presentation

  • Brooks Chapter 3: The Surgical Team


The problem l.jpg
The Problem

  • Young software managers often say they favor a small, sharp team.

  • Who doesn’t?

  • The gap between the best and worst performers (even with the same salary and experience) may be 10:1.

  • If you have 200 people, and 25 are really good, fire the 175.


But what about large jobs l.jpg
But What About Large Jobs?

  • A large job might be 3000 person-years.

  • When will a 10-person team finish?

  • Suppose those 10 people are 7 times more productive than average.

  • Suppose reduced communication between fewer people gives a 7 times improvement.

  • The job is done in 6 years. Is the product still interesting or marketable?


The solution l.jpg
The Solution

  • Organize like a surgical team, rather than a hog-butchering team.

  • The chief surgeon:

    • Complete responsibility for designing, writing and testing the code.

    • Great talent, 10 years experience

  • The co-pilot:

    • Can do the job, but is less experienced.

    • Helps by being thinker, discussant, evaluator.

    • Knows all the code.

    • Is insurance against disaster to the chief surgeon.


Other players l.jpg
Other Players

  • The administrator:

    • Handles money, people, space and machines.

  • The editor:

    • Takes draft documentation from the chief surgeon, edits and checks, publishes it.

  • Two secretaries:

    • Handle project correspondence and non-product files.


Other players76 l.jpg
Other Players

  • The program clerk:

    • Maintains all technical records of the team. Does the version control.

  • The toolsmith:

    • Provides all the facilities the surgeon needs. Builds special purpose classes, libraries and tools.


Other players77 l.jpg
Other Players

  • The tester:

    • Builds “scaffolding” and test cases at the request of the surgeon. Helps with day-to-day debugging.

  • The language lawyer:

    • Expert in several languages, finds clever ways to exploit a language for special purposes.


How it works l.jpg
How It Works

  • 10 people, all working hard, but one mind designs and builds.

  • The programming work is not divided between many people.

  • Everyone else is subordinate to the chief surgeon; no differences of opinion or interest.

  • Communication needs are reduced to the lowest possible level.


Scaling up l.jpg
Scaling Up

  • A 200 person problem now requires the coordination of only 20.

  • The co-pilot does the talking for 10 people in meetings.

  • The conceptual integrity of each piece of the product is far greater.

  • We see in the next chapter how the coordination is done…



How many big successes l.jpg
How Many Big Successes?

  • One.

  • The New York Times clipping file:

    • 83,000 lines of code, two years

    • Most of the code written in the last 6 months!

    • Only 21 defects found in the first 5 weeks of use.

  • But other reports of chief programmer teams are very ordinary.

  • The NYT team (from IBM) was specially selected from the best people in the company.


What s wrong with the idea l.jpg
What’s Wrong With the Idea

  • The chief programmer is superbly skilled as programmer and manager.

  • Where will you find this person?

  • The skills possessed by the best programmers and the best managers are different.

  • The chances of finding a chief programmer are small.


What else is wrong l.jpg
What Else is Wrong

  • The co-pilot is as good as the chief programmer, but has lower salary and less prestige.

  • The co-pilot basically waits for something to happen to the chief.

  • Who would take a job like this?

  • The program clerk must love paperwork, but software professionals hate paperwork.


ad