UML Metrics Semrug presentation from RIIS LLC. Agenda Introduction Who are we The need for Metrics What’s in your Style Guide Automating the process Conclusion.

UML MetricsSemrug presentation from RIIS LLC

Agenda

• Introduction

• Who are we

• The need for Metrics

• What’s in your Style Guide

• Automating the process

• Conclusion

Play Blackjack

Play Craps

Play Roulette

Gambler

(from System Actors)

RIIS LLC

• Based in Royal Oak• Founded in 1998

– Software development– Rational tools

• Rational Skill set– ReqPro, Clearcase, ClearQuest, Rose etc.– Extending Rational Suite through Tool

Customization

• Why the interest in UML– Client driven– Process improvement

• Why the interest in Metrics…

Data<<layer>>

Presentation<<layer>>

Business<<layer>>

System Actors(from System Use-Case Model)

Why the interest in Metrics• Improve quality of the models

– Easier to understand– More accurate

• Improve overall productivity– Better models, one less round of questions

• Moving to a global development environment– Offshore– 3rd Party modelers– Enterprise modeling with multiple teams

• Hidden UML secret – Just like any development

……large scale modeling tends to falls apart

Play Craps

Play Craps(from Games)

Why the interest (cont’d)

• SQL and Java– Coding standards– Code reviews

• Aims and Objectives– Codify what makes good code– Provide consistency– Make it easier for new developers to

understand code

• Now do the same for UML– UML is a language

CStockManager

<<stdmethod>> getQuantity()

<<atlobject>>

StockManager(from CoClasses)

<<coclass>>

<<Implements>>

IStockManager

getQuantity()

<<default>>

Today’s UML Models

• No consistency– Too much detail– Or maybe too little detail

• Difficult to teach new modelers

• UML code reviews– Very Subjective– Time consuming– Need tools to automate

CStockManager

<<stdmethod>> getQuantity()

<<atlobject>>

StockManager(from CoClasses)

<<coclass>>

<<Implements>>

IStockManager

getQuantity()

<<default>>

Frequently occurring UML Errors(Bolloju & Leung)

So what’s in your style guide?

• Nothing cast in stone– What works best for you– Define company wide conventions

• General Rules– Consistent naming conventions– Consistent use of UML diagrams– What diagrams should your

modelers be using– Consistent arrangement of diagrams– More….

PropellerAssembly

bladeCount : intbladeType : BladeTypeMounting_Hardware : MountingHardware

set_BladeType()set_BladeCount()setMountingHardware().ctor()~()ToString()

(from Classes)

This class's members and operations are not consistent in their naming conventions.

Style Guide (cont’d)• What are your company specific rules

– Define how your people should be modeling– What makes a good model depends upon the

purpose of the model• Decide what style of UML works for your

organization– XP

• Quickstart, throwaway UML– Martin Shoemaker’s UML in 5 steps

• Iterative but not detailed– CMMI

• Final UML model matches the developed application

• Including any change controls etc.– MDA

• Are you generating code and round-tripping

Communication

(from Use Cases)

Reporting

(from Use Cases)

Status

(from Use Cases)

Control

(from Use Cases)

Pilot

(from Actors)

Pilot should communicate with Tower Use actor - verb - noun

Style Guide (cont’d)

• If a model is used to discuss and explore the high-level functionality of a system– If the equivalent code would be equally clear, you’re

modeling too scrupulously (setProperties)– Activity diagrams should be preferred, sequence

diagrams should be avoided• If a model is used to document a system (e.g.

for government work)– Object and class relationships become more

important– Sequence and collaboration diagrams become more

relevant• Find a UML model that works for you and use it

as a metric template

LandingGear(from Classes)

Airplane(from Classes)

M

M

M

3..n

1

Choose your Metrics

• List of UML Metrics (from SDMetrics)– Pick and choose what you need– Or create your own

Metrics – Use Cases

• number of actors and use cases• number use cases per actor• number times use cases reused• number state diagrams related with particular actor• number of associations the use case participates in • number of extension points of the use case • number of use cases which this one includes • number of use cases which include this one • number of use cases which extend this one • number of use cases which this one extends• using standardized noun and verb list

Metrics – Class Diagrams• number of attributes in the class (number variables in a class)• number of operations in a class (Weighted Method Complexity)• number of operations with a name starting with 'set'. (setters and

getters)• nesting level of the class (for inner classes). • number of interfaces the class implements• number of children of the class • number of descendents of the class • number of ancestors of the class• depth of the class in the inheritance hierarchy • class to leaf depth • number of inherited attributes

Metrics – Class Diagrams (cont’d)

• number of elements on which this class depends • number of elements that depend on this class. • number of associated elements in the same scope (namespace) as the class • number of associated elements in the same scope branch as the class • number of associated elements not in the same scope branch as the class • number of times the class is externally used as attribute type • number of attributes in the class having another class or interface as their type • number of times the class is externally used as parameter type • number of parameters in the class having another class or interface as their type. • number of connectors owned by the class • number of instance specification where the class is a classifier • number of lifelines that represent a property of which this class is the type • number of messages sent • number of messages received • number of messages sent to instances of the same class • number of times the class appears on a diagram

Metrics – Interface

• number of operations in the interface • number of times the interface is used as attribute type • number of times the interface is used as parameter type • number of parameters in the interface having an

interface or class as their type • number of elements the interface has an association with • number of elements directly implementing the interface • number of elements implementing a descendent of the

interface • number of ancestors of the interface • number of descendents of the interface

Metrics - Packages• number of classes in the package • number of classes in the package, its subpackages, and so on • number of operations in the classes of the package • number of interfaces in the package • number of relationships between classes and interfaces in the package • average number of internal relationships per class/interface • number of elements outside this package that depend on classes or interfaces in this package • number of elements outside this package that classes or interfaces in this package depend on • ratio of abstract classes and interfaces in the package to the total number of interfaces and

classes in the package • distance from the main sequence • Nesting level of the package in the package hierarchy • classes and interfaces of a package, and their dependencies, form a graph. This metric counts

the number of connected components of that graph • number of UML dependencies where the package is the client. • number of UML dependencies where the package is the supplier • number of packages on which classes and interfaces of this package depend • number of messages sent to instances of classes outside the package • number of messages received by classifier instances of classes outside the package • number of messages sent between classifier instances of classes in the package • number of times the package appears on a diagram

Metrics – State Machine

• number of transitions in the state machine • number of transitions with an effect in the state

machine • number of transitions with a guard in the state

machine • number of triggers of the transitions of the state

machine • number of states in the state machine • number of activities defined for the states of the

state machine

Metrics – Activity Diagrams

• number of actions of the activity • number of object nodes of the activity • number of pins on nodes of the activity • number of control nodes of the activity • number of activity partitions in the activity • number of activity groups or regions of the activity • number of control flows of the activity • number of object flows of the activity • number of guards defined on object and control flows of

the activity • number of exception handlers of the activity

Metrics – Component• number of operations of the component • number of subcomponents of the component • number of packages of the component • number of classes of the component • number of interfaces of the component • number of artifacts of which this component is a manifestation • number of connectors owned by the component • number of interfaces the component provides • number of interfaces the component requires • number of outgoing UML dependencies • number of incoming UML dependencies • number of associated elements via outgoing associations • number of associated elements via incoming associations • number of times the component appears on a diagram

Metrics – Diagram• type of diagram • total number of design elements on the diagram • number of classes on the diagram • number of interfaces on the diagram • number of packages on the diagram • number of associations on the diagram • number of generalizations on the diagram • number of UML dependencies and UML usage dependencies on the diagram • number of interface realizations on the diagram • number of instance specifications on the diagram • number of lifelines on the diagram • number of connectors on the diagram • number of messages on the diagram • number of actors on the diagram • number of use cases on the diagram • number of extension points on the diagram • number of use case extensions on the diagram • number of use case includes on the diagram

Automating Metric Capture • So many metrics, big need for automation• Existing tools

– OSMAT– Cool Uml – SDMetrics

• Other Approaches– Rational API– Decompile the ptl– XSLT over exported XMI files

• RIIS tools– Read into database– Query any metrics you want– Perform global updates– Write out to file

Class Metrics (OSMAT)

• Total number of classes• Total number of inheritance relationships• Total number of uses relationships• Total number of realize relationships• Total number of operation/methods• Total number of parameters• Total number of class attributes• Total number of associations• Total number of roles

Class Metrics (OSMAT)

• Fault-proneness metrics – Weighted method per class (explain)– Number of children per class– Depth of inheritance tree– Coupling between object classes– Response for class– Lack of cohesion in methods

OSMAT outputMetrics UML Models

File1 File2 File3 File4 File5

Basic Total No of Class 8 57 55 101 36

Total No of Inheritance Relationship 0 4 0 2 35

Total No of Uses Relationship 0 6 54 52 0

Total No of Realize Relationship 0 2 0 0 1

Total No of Operation(Method) 9 7 61 387 313

Total No of Parameter 0 0 11 223 567

Total No of Class Attribute 73 393 407 906 164

Total No of Association 6 50 24 39 0

Total No of Role 12 102 48 78 0

Class Metrics ‘Cool UML’

• Design metrics:– Maximum length from the node to the root of the tree– Average operations per class

• Size metrics:– Number of operations per class– Number of attributes per class– Total number of classes– Total number of operations– Total number of attributes

• Complexity metrics:– Number of immediate children per class– Number of sub-classes that inherits directly or indirectly– Number of super classes– Total number of edges in the inheritance hierarchy

Metric Display

• Save metrics in data warehouse– Dimension and Fact tables

• Weekly or daily scheduled job creates metrics

• Display using – Rational Project Console– Business Objects Dashboard– RIIS Application Dev Dashboard

References

• The Elements of UML(TM) 2.0 Style by Scott W. Ambler

• Anything by Martin Fowler

• Writing Effective Use Cases by Alistair Coburn

Conclusion

• Turning subjective into objective • Automate the process• Improve the quality of your metrics• Improve the link between requirements and code by

building better models• Use only as much formalism, advanced tactics, and

ceremony as your situation requires and your audience is able to take (MAT).

• Questions• Contact Details

– [email protected]