The Class Blueprint: Visually Supporting the Understanding of Classes

1
The Class Blueprint Visually Supportingthe
Understanding of Classes
Stephane Ducasse and Michele Lanza IEEE
TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 31,
NO. 1, JANUARY 2005 pp. 75-90

• Presentation by Darren Reist

2
Background

• Maintenance Phase Accounts for 50-75 TOC
• In Maintenance Phase, Software Engineers spend at
  least half of their time trying to understand the
  code
• A thus a tool to aid in this task is a worthwhile
  endeavor

3
Context OOP Legacy Systems

• It is very common for Software Engineers to
  inherit legacy code
• Not all legacy code is procedural in nature
• Many legacy systems are either poorly documented
  or undocumented
• Object Oriented Code is much harder to understand
  that procedural code

4
Difficulties of OOP Code

• Inheritance
• Late Binding
• Order of written code on the page is not so
  relevant (jumps around, non-sequitur) as opposed
  to top-down structural systems

5
The Key to Understanding

• The Class is the central building block and most
  important entity in Object Oriented Programming.
• Visualization of Classes at both a structural and
  behavioral level will increase the understanding
  of the code
• Code can be browsed as needed as the high-level
  views are absorbed

6
Contributions of this Article

• Class Blueprint Defined
• Identification of Visual Patterns
• Definition of a vocabulary based on these
  patterns

7
The Class Blueprint

• They Say
• Coined by the Authors to describe their
  Visualization of a semantically augmented
  call-graph and its specific semantics based
  layout.
• To help the Programmer develop a mental model of
  the classes s/he browses
• I Say
• A diagram that adds internal behavioral and code
  information to what is essentially a broken up
  UML Class Diagram, with implied tool support.

8
Class Visualization and Scope

• Display of
• Methods
• Attributes
• Method Invocations
• Attribute Accesses
• Inheritance Tree
• Promotes Opportunistic Code Reading Reading
  code as you need to

9
Class Blueprint Display

• Proposed Prefer to Fit on One page (screen), or
  in rare cases 2 pages.
• Authors believe that good visualization can be
  grasped in a glance
• Additional semantics through color and entity
  metrics

10
Class Blueprint Diagram Structure

• Layered, grouping methods and attributes
  according to visibility (and typical call order)
  Left to Right in western world.
• Nodes and Edges, essentially a graph
• Nodes represent class element, Edges represent
  method invocation or attribute access

11
Class Blueprint Layers

• Initialization Layer Constructors and Init
• Interface Layer Public and Protected Methods
• Internal Implementation Layer Private Methods
• Accessor Layer Accessors and Mutators
• Attribute Layer Private Attributes

12
Class Blueprint Visualization
13
Initialization Layer

• Anything that initializes the object. In a tool,
  this would be determined by syntax
• Not all languages have constructors
• Parse for certain syntax initialize or init

14
External Interface Layer

• Public Interface to the external callers
• Anything that it declared as Public or Protected
  (interface for subclasses)
• Or is not invoked my any methods in the same class

15
Internal Implementation Layer

• Function core of class
• Essentially these are private methods, called on
  by the external interface to fulfill some
  contract with the outside world
• Or a method is invoked by some other method in
  same class

16
Accessor Layer

• Accessors and Mutators for Private Data
• Getters and Setters, and thats all they do

17
Attribute Layer

• The private data of the class
• Manipulated by the previous layer (Accessor Layer)

18
Edges

• Represent Invocations
• Typically move Left to Right
• Lines from Top of Node (invoker) to Bottom of
  Node (invoked)

19
Edges
20
Additional Semantic Information

• Semantically Augmented
• Color determines Node Type and invocation type
• Node Metrics determine
• For attributes
• Height Number of external access,
• Width Number of internal accesses
• For Methods
• Height Lines of Code in Method
• Width Number of Invocations

21
Color Coding
22
Handling Inheritance

• Inheritance poses a problem, as pertinent
  functionality can be distributed over a hierarchy
• Organize Class Blue Prints in a Inheritance Tree
  Hierarchy

23
Comment The Scaling Issue
Inheritance Tree Is this diagram actually
useful?
24
Observed Visual Patterns

• Four Classes of Visual Patterns Emerge
• Size-Based
• Size of Class Blueprint
• Layer Distribution-Based
• Distribution of Members across layers
• Semantics-Based
• Semantics among members
• Call-Flow-Based
• Invocation between members

25
Size-Based Patterns

• Single
• Micro
• Large-Implementation
• Giant

26
Layer Distribution-Based Patterns

• Three Layers
• Wide Interface
• Interface

27
Semantics-Based Patterns

• Delegate
• Data Storage
• Constant Definer
• Accessor User
• Direct Access
• Access Mixture

28
Call-Flow-Based

• Single Entry
• Method Clumps
• Funnel

29
Tools

• CodeCrawler the tool implementing the system
  described in the paper
• Built on Moose, a reverse-engineering environment
  written in small talk

30
Strengths / Weaknesses

• Strengths
• Interesting approach to pack more information
  into a single diagram.
• Would prove very useful in the right scenario
• Weaknesses
• Doesnt scale any better than any other visual
  system.
• Weak implementation for hybrid or poorly designed
  systems (which will often be the systems with
  poor/no documentation)

31
Questions

• 1) Given your experience with legacy systems in
  either academia or in the workplace, how neatly
  do you think a typical undocumented legacy system
  would map onto a tool implementing the Class
  Blueprint Visualization?
• E.G. Many legacy systems are hybrid OOP /
  Procedural (think VB and Delphi) This tool would
  essentially show you only what classes are
  available and discard any procedural glue
• Also, does this system scale well?

32
Questions

• 2) The Authors contend that undocumented object
  oriented systems are harder to understand than
  undocumented procedural systems. Do you agree?
  Why or why not?

33
Questions

• 3) What do you believe the usefulness of this
  tool to be in the workplace from a statistical
  perspective (i.e. how often would this tool be
  useful to you)? Explain your reasoning.
• 4) Can you think of a better way to implement the
  inheritance visualization while maintaining the
  Class Blueprint visualization?