1 Object-Oriented Design in Practice. Could/Should We Do Better? Dr. Radu Marinescu Timişoara, 12.02.2003 Object-Oriented Design in Practice. Could/Should.

Slides:



Advertisements
Similar presentations
Object-Oriented Application Frameworks Much of the cost and effort stems from the continuous re- discovery and re-invention of core concepts and components.
Advertisements

1 Object-Oriented Reengineering © S. Demeyer, S.Ducasse, O. Nierstrasz Lecture 2 Radu Marinescu Reverse Engineering.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Design Principles for Reusable, Composable and Extensible Frameworks Jilles van Gurp.
OORPT Object-Oriented Reengineering Patterns and Techniques 7. Problem Detection Prof. O. Nierstrasz.
Page 1 Building Reliable Component-based Systems Chapter 7 - Role-Based Component Engineering Chapter 7 Role-Based Component Engineering.
Object-Oriented Metrics. Characteristics of OO ● Localization ● Encapsulation ● Information hiding ● Inheritence ● Object abstraction.
Building Reliable Software Requirements and Methods.
Software Quality Metrics
Soft. Eng. II, Spr. 02Dr Driss Kettani, from I. Sommerville1 CSC-3325: Chapter 6 Title : The Software Quality Reading: I. Sommerville, Chap: 24.
1 SWE Introduction to Software Engineering Lecture 23 – Architectural Design (Chapter 13)
Object-Oriented Metrics
Ch2: Software: Its Nature and Qualities. 1 Introduction  Difference between a software and other engineering products.  Difference between software.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Investigating the Evolution of Bad Smells in Object-Oriented Code Alexander Chatzigeorgiou Anastasios Manakos University of Macedonia Thessaloniki, Greece.
WEL COME PRAVEEN M JIGAJINNI PGT (Computer Science) MCA, MSc[IT], MTech[IT],MPhil (Comp.Sci), PGDCA, ADCA, Dc. Sc. & Engg.
Chapter 22 Object-Oriented Design
Chapter 24 - Quality Management 1Chapter 24 Quality management.
Software Process and Product Metrics
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
UML and Object Oriented Concepts
Dr. Ken Hoganson, © August 2014 Programming in R STAT8030 Programming in R COURSE NOTES 1: Hoganson Programming Languages.
Design Patterns OOD. Course topics Design Principles UML –Class Diagrams –Sequence Diagrams Design Patterns C#,.NET (all the course examples) Design Principles.
GENERAL CONCEPTS OF OOPS INTRODUCTION With rapidly changing world and highly competitive and versatile nature of industry, the operations are becoming.
BCS 2143 Introduction to Object Oriented and Software Development.
1/19 Component Design On-demand Learning Series Software Engineering of Web Application - Principles of Good Component Design Hunan University, Software.
“Enhancing Reuse with Information Hiding” ITT Proceedings of the Workshop on Reusability in Programming, 1983 Reprinted in Software Reusability, Volume.
1 CS 456 Software Engineering. 2 Contents 3 Chapter 1: Introduction.
Profiling Metadata Specifications David Massart, EUN Budapest, Hungary – Nov. 2, 2009.
© S. Demeyer, S. Ducasse, O. Nierstrasz Intro.1 1. Introduction Goals Why Reengineering ?  Lehman's Laws  Object-Oriented Legacy Typical Problems  common.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Instructor Kostas Kontogiannis.
Object-Oriented Programming and the Progress ABL Tomáš Kučera Principal Solution Engineer / EMEA Power Team.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
R2PL, Pittsburgh November 10, 2005 Copyright © Fraunhofer IESE 2005 Identifying Domain-Specific Reusable Components from Existing OO Systems to Support.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
1 The Modular Structure of Complex Systems Presented by: SeyedMasoud Sadjadi and Wei Zhu David L. Parnas, Paul C. Clement, and David M. Weiss ICSE 1984.
GRASP: Designing Objects with Responsibilities
OBJECT-ORIENTED PROGRAMMING (OOP) WITH C++ Instructor: Dr. Hany H. Ammar Dept. of Electrical and Computer Engineering, WVU.
An Automatic Software Quality Measurement System.
Chapter 3: Software Project Management Metrics
CS551 - Lecture 5 1 CS551 Lecture 5: Quality Attributes Yugi Lee FH #555 (816)
1 Towards an Automated Approach for Quality Improvement in OO Design Dr. Radu Marinescu Timişoara, Towards an Automatic Approach for Quality.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
CSc 461/561 Information Systems Engineering Lecture 5 – Software Metrics.
Application of Design Heuristics in the Designing and Implementation of Object Oriented Informational Systems.
Chapter 5: Software Re-Engineering Omar Meqdadi SE 3860 Lecture 5 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Testing OO software. State Based Testing State machine: implementation-independent specification (model) of the dynamic behaviour of the system State:
More Design Patterns From: Shalloway & Trott, Design Patterns Explained, 2 nd ed.
Metadata By N.Gopinath AP/CSE Metadata and it’s role in the lifecycle. The collection, maintenance, and deployment of metadata Metadata and tool integration.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 15a: Product Metrics for Software Software Engineering: A Practitioner’s Approach, 6/e Chapter.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Design Patterns in Context ©SoftMoore ConsultingSlide 1.
Diagnosing Design Problems in Object Oriented Systems Adrian Trifu, Radu Marinescu Proceedings of the 12th IEEE Working Conference on Reverse Engineering.
Object-Oriented Software Engineering Chapter 1 Software and Software Engineering.
Watching the movie the hard way…. Page 256 – Head First Design Patterns.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
A Survey of Object-Oriented Concept Oscar Nierstrasz.
1 Good Object-Oriented Design Dr. Radu Marinescu Lecture 4 Introduction to Design Patterns.
CS223: Software Engineering Lecture 21: Unit Testing Metric.
COP 4331 – OOD&P Lecture 7 Object Concepts. What is an Object Programming language definition: An instance of a class Design perspective is different.
A Survey of Object-Oriented Concepts, by Oscar Nierstrasz Reviewed by Odd Petter N. Slyngstad for DT8100, 27/1/2005.
A Hierarchical Model for Object-Oriented Design Quality Assessment
CHAPTER 5 GENERAL OOP CONCEPTS.
Software Verification and Validation
Object-Oriented Metrics
Why Object-oriented Programming?
Chapter 13 Quality Management
Chapter 19 Technical Metrics for Software
Presentation transcript:

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

2 Object-Oriented Design in Practice. Could/Should We Do Better? Dr. Radu Marinescu Timişoara, 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 Object-Oriented Design in Practice. Could/Should We Do Better? Dr. Radu Marinescu Timişoara, 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…

4 Object-Oriented Design in Practice. Could/Should We Do Better? Dr. Radu Marinescu Timişoara, 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

5 Object-Oriented Design in Practice. Could/Should We Do Better? Dr. Radu Marinescu Timişoara, you would change just a small design fragment and suddenly % of all the classes in the system may require changes?! Just Imagine that...

6 Object-Oriented Design in Practice. Could/Should We Do Better? Dr. Radu Marinescu Timişoara,  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 ?

7 Object-Oriented Design in Practice. Could/Should We Do Better? Dr. Radu Marinescu Timişoara, Detection of Design Problems 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 Idea: Use metrics to detect design problems!

8 Object-Oriented Design in Practice. Could/Should We Do Better? Dr. Radu Marinescu Timişoara, 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 Object-Oriented Design in Practice. Could/Should We Do Better? Dr. Radu Marinescu Timişoara, 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

10 Object-Oriented Design in Practice. Could/Should We Do Better? Dr. Radu Marinescu Timişoara, Defining a Detection Strategy Analysis Detection Technique Select Metrics Detection Strategy Informal Rules (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... WMC HigherThan(30) or TCC LowerThan(0.33)

11 Object-Oriented Design in Practice. Could/Should We Do Better? Dr. Radu Marinescu Timişoara, Classification of Design Flaws

12 Object-Oriented Design in Practice. Could/Should We Do Better? Dr. Radu Marinescu Timişoara, ProDeOOS at Work...

13 Object-Oriented Design in Practice. Could/Should We Do Better? Dr. Radu Marinescu Timişoara, Sources (Java, C++) Meta-Model parsing using Metrics Detection Strategy (*.sod) Statistical Filters 1.. n 1.. m executing with PRODEOOS List of Candidates manual inspection Process of Design Inspection

14 Object-Oriented Design in Practice. Could/Should We Do Better? Dr. Radu Marinescu Timişoara, 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 Object-Oriented Design in Practice. Could/Should We Do Better? Dr. Radu Marinescu Timişoara, Could We Do Better... for You?  Approach successfully applied on industrial systems  > LOC and up to LOC  proved to be scalable and accurate  Concepts already implemented in two important CASE tools  metrics (since 2001) and detection strategies (since 2002) metricsdetection strategies  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 Object-Oriented Design in Practice. Could/Should We Do Better? Dr. Radu Marinescu Timişoara, Should We Do Better... Together?