object oriented analysis and design
Download
Skip this Video
Download Presentation
Object-Oriented Analysis and Design

Loading in 2 Seconds...

play fullscreen
1 / 83

Dependencies - PowerPoint PPT Presentation


  • 402 Views
  • Uploaded 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

Object-Oriented Analysis and Design

Lecture 7

Metrics for O-O Design

principles for o o design
Principles for O-O Design
  • Encapsulation
  • “Connascence”
  • Domains
  • Cohesion
encapsulation
Encapsulation

Class/

object

Raw lines

of code

Procedural

module

Level 0

Level 1

Level 2

encapsulation4
Encapsulation
  • First, there was machine code, and then assembly language.
  • Then there were functions/procedures.
  • Then there were classes.
  • Then there were…what?
packages
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
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
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
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
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
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
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
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
“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
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
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
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
Good, Bad, Ugly

Level 3

Level 3

other dangers
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
What C & K Provide
  • They propose new metrics
  • Evaluate them against normative criteria
  • Illustrate them in real-world settings
where are they used
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
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
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
I Said, “What?”
  • We do this all the time: empirical relations become quantitative systems.
  • Think of
    • meters
    • kilograms
    • grades (!)
    • now, complexity...
objects
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
“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
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
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
Data Collection
  • Source code
  • Defect report form
  • Component origination form
  • Repaired code
  • C-K metrics, automated
  • Defective modules
analysis
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
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
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
Example 7 Minute Presentation
  • Brooks Chapter 3: The Surgical Team
the problem
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
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
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
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
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
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
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
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
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
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
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