1 / 16

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

Object-Oriented Design in Practice. Could/Should We Do Better?. 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

coby
Télécharger la présentation

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

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Object-Oriented Design in Practice.Could/Should We Do Better? Dr. Radu Marinescu

  2. 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

  3. Design and Quality • …“Design is hard”[Opdyke92] • Object-oriented design makes no exception... • Quality is in danger Software needs designbut… Pressure of the market to control of qualitybut… • …“You can’t control what you can’t measure”[DeMarco82] • What should we measure? • How should we measure?

  4. Design Flaws… Why care? • Design problems are frequent • legacy systems with high business value • must maintain and enhancethe 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 ... are malign characteristics of design entities • hinder the maintenance and evolution of the system • by violating the principles and rules of good (OO) design

  5. ...33% of all the classes in the system may require changes?! Just Imagine that... ...you would change just a small design fragment and suddenly...

  6. 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 • 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! How could we control the usage of design rules ? Hard to control, because rules are hard to quantify!

  7. Problem Detection • The 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 Design • map source-code entities to numerical values • used as quality indicators Detection of Design Problems Idea:Use metrics to detect design problems!

  8. Problems with Software Measurement • Definitions of Metrics • Mapping attributes of a software product to numeric values [Fent97] • Imprecise, confusing, or conflicting definitions • Interpretation Models • Not provided or hardly reusable in a different context • Interpretation level is too fine-grained to lead to design decisions • metrics values are like symptoms • indicate an abnormality, but can’t indicate the cause • reduces 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!

  9. 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 Themeasurable expression of a rule, by which design fragments that are conformant to the rule can be identified in the source-code

  10. Analysis Select Metrics Detection Strategy Defining a Detection Strategy Detection Technique Informal Rules (design-related) • access many “foreign” data • large and complex classes • or non-cohesive • 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 AOFD TopValues(20%)and... WMCHigherThan(30) or TCCLowerThan(0.33)

  11. Classification of Design Flaws

  12. ProDeOOS at Work ...

  13. Sources (Java, C++) parsing Meta-Model using Metrics 1 .. n Detection Strategy (*.sod) executing with PRODEOOS List of Candidates 1 .. m Statistical Filters manual inspection Process of Design Inspection

  14. 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

  15. 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!

  16. Should We Do Better... Together?

More Related