1 object-oriented design in practice. could/should we do better? dr. radu marinescu timişoara,...

Timişoara, 12.02.2003 1

Object-Oriented Design in Practice. Could/Should We Do Better?

Dr. Radu Marinescu

Object-Oriented Design in Practice.

Could/Should We Do Better?

Dr. Radu Marinescu

Timişoara, 12.02.2003 2


Dr. Radu Marinescu

Problems with (Object-Oriented) Design

From Dreams to Reality Dreams: object-oriented mechanisms will automatically increase

the quality of software e.g. make systems easier to maintain or reuse

Reality: uncountable number of OO legacy systems in the industry inflexible, hard to understand, hard to extend…

Why? Time Pressure Changing Requirements Immature Developers

Timişoara, 12.02.2003 3


Dr. Radu Marinescu

Design and Quality

…“Design is hard ” [Opdyke92] Object-oriented design makes no exception... Quality is in danger

Pressure of the market to control of quality but… …“You can’t control what you can’t measure”[DeMarco82]

What should we measure?

How should we measure?

Software needs design but…

Timişoara, 12.02.2003 4


Dr. Radu Marinescu

Design Flaws…

Design problems are frequent legacy systems with high business value must maintain and enhance the system

Design problems are expensive high effort required for maintenance and extension

Design problems will always be there! at least because of time pressure. …but I believe also because of changing requirements

Why care?

... are malign characteristics of design entities hinder the maintenance and evolution of the system by violating the principles and rules of good (OO) design

Timişoara, 12.02.2003 5


Dr. Radu Marinescu

...you would change just a small design fragment and suddenly...

...33% of all the classes in thesystem may require changes?!

Just Imagine that...

Timişoara, 12.02.2003 6


Dr. Radu Marinescu

But there is hope! Design rules, guidelines and heuristics

Apply them and they will provide the desired quality Break them and they will break your design!

Is There Any Hope?

“There is no silver bullet!” [Brooks84]

Encapsulation? Inheritance? Polymorphism? NO! These are just mechanisms Like in chess...

… just knowing the pieces and the moves is not enough

Hard to control, because rules are hard to quantify!

How could we control the usage of design rules ?

Timişoara, 12.02.2003 7


Dr. Radu Marinescu

Detection of Design Problems

Problem DetectionThe process of identifying the parts of a software system affected by a particular design flaw

It‘s not easy!

manual and empirical

time-expensive and non-scalable

"Measuring" the Designmap source-code entities to numerical values

used as quality indicators

Idea: Use metrics to detect design problems!

Timişoara, 12.02.2003 8


Dr. Radu Marinescu

Problems with Software Measurement

Definitions of MetricsMapping attributes of a software product to numeric values [Fent97]

Imprecise, confusing, or conflicting definitions

Interpretation ModelsNot provided or hardly reusable in a different contextInterpretation level is too fine-grained to lead to design decisions

metrics values are like symptomsindicate an abnormality, but can’t indicate the causereduces the relevance of measurement results

There is a large gap between what we do measure and what we should measure!

Need mechanism for higher-level interpretation of metrics!

Timişoara, 12.02.2003 9


Dr. Radu Marinescu

The measurable expression of a rule, by which

design fragments that are conformant to the rule

can be identified in the source-code

Detection Strategy

Generic mean for defining metrics-based design rules use metrics together! Based on mechanisms of filtering and composition

Filtering Mechanism Statistical functions that return a subset of a data-set

Composition Operators articulate the composition of a detection rule

Timişoara, 12.02.2003 10


Dr. Radu Marinescu

Defining a Detection Strategy

Analysis DetectionTechnique

Select MetricsDetection Strategy

InformalRules

(design-related)

•Top-level classes in a design should share work uniformly• Beware of classes with much non-communicative behavior• Beware of classes that access directly data from other classes

• access many “foreign” data• large and complex classes• or non-cohesive

AOFD TopValues(20%) and ...

WMCHigherThan(30) or

TCCLowerThan(0.33)

Timişoara, 12.02.2003 11


Dr. Radu Marinescu

Classification of Design Flaws

Timişoara, 12.02.2003 12


Dr. Radu Marinescu

ProDeOOS at Work ...

Timişoara, 12.02.2003 13


Dr. Radu Marinescu

Sources(Java, C++) Meta-Model

parsing

usingMetrics

Detection Strategy (*.sod)

Statistical

Filters

1 .. n

1 .. m

executing with PRODEOOS

List of Candidates

manual inspection

Process of Design Inspection

Timişoara, 12.02.2003 14


Dr. Radu Marinescu

Summary

Design flaws are dangerous the larger the system, the higher the risk

We can assess the quality of design by measuring its conformance to principles of OO design

Ability to detect a significant set of design flaws

at all levels, from methods to subsystems

Strong tool support for the entire approach high degree of automatization and scalability

Timişoara, 12.02.2003 15


Dr. Radu Marinescu

Could We Do Better ... for You?

Approach successfully applied on industrial systems > 100.000 LOC and up to 5.000.000 LOC proved to be scalable and accurate

Concepts already implemented in two important CASE tools metrics (since 2001) and detection strategies (since 2002)

in Borland Together CC and WSE

second important CASE tool provider interested in implementing the concepts.

Consultancy for software companies on quality assurance and re-engineering all over Europe, for the last 3.5 years !

This is not just about science and research!

Timişoara, 12.02.2003 16


Dr. Radu Marinescu

Should We Do Better... Together?

1 object-oriented design in practice. could/should we do better? dr. radu marinescu timişoara,...

Documents