Rohini Sharma Roll No. RA1809A01 Regd. No. 40800065 M.Tech.(CSE) Part Time 3 rd Semester.

Slides:



Advertisements
Similar presentations
Understand and appreciate Object Oriented Programming (OOP) Objects are self-contained modules or subroutines that contain data as well as the functions.
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Chapter 11 Component-Level Design
Communication between modules, cohesion and coupling
Lecture 9 Improving Software Design CSC301-Winter 2011 – University of Toronto – Department of Computer Science Hesam C. Esfahani
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
UHD::CS3320::CHAP61 INTRODUCTION TO OBJECTS Chapter 6.
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.
Object-Oriented Metrics
Criteria for good design. aim to appreciate the proper and improper uses of inheritance and appreciate the concepts of coupling and cohesion.
Chapter 25 More Design Patterns. Polymorphism Issue: Conditional variation –If-then-else or switch statements –New variation or case: Conditional statements.
Developed by Reneta Barneva, SUNY Fredonia Component Level Design.
PRESENTED BY SANGEETA MEHTA EECS810 UNIVERSITY OF KANSAS OCTOBER 2008 Design Patterns.
OBJECT ORIENTED PROGRAMMING IN C++ LECTURE
Inheritance. © 2004 Pearson Addison-Wesley. All rights reserved 8-2 Inheritance Inheritance is a fundamental object-oriented design technique used to.
Introduction To System Analysis and design
Design Patterns.
11 1 Object oriented DB (not in book) Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel Learning objectives: What.
MT311 Java Application Development and Programming Languages Li Tak Sing( 李德成 )
CISC6795: Spring Object-Oriented Programming: Polymorphism.
An Object-Oriented Approach to Programming Logic and Design
Coupling and Cohesion Pfleeger, S., Software Engineering Theory and Practice. Prentice Hall, 2001.
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
11 Chapter 11 Object-Oriented Databases Database Systems: Design, Implementation, and Management 4th Edition Peter Rob & Carlos Coronel.
1 Software Design Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13, 5 th edition and Ch. 10, 6 th edition.
SOFTWARE DESIGN Design Concepts Design is a meaningful engineering representation of something that is to be built It can be traced to a customer’s requirements.
Software Design Deriving a solution which satisfies software requirements.
1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13.
Concepts of Software Quality Yonglei Tao 1. Software Quality Attributes  Reliability  correctness, completeness, consistency, robustness  Testability.
Copyright 2003 Scott/Jones Publishing Standard Version of Starting Out with C++, 4th Edition Chapter 13 Introduction to Classes.
Cohesion and Coupling CS 4311
Programming Logic and Design Using Methods. 2 Objectives Review how to use a simple method with local variables and constants Create a method that requires.
GRASP: Designing Objects with Responsibilities
Relationships Relationships between objects and between classes.
ITEC 3220A Using and Designing Database Systems Instructor: Gordon Turpin Course Website: Office: CSEB3020.
CSC 131 Fall 2006 Lecture # 6 Object-Oriented Concepts.
CS451 - Lecture 2 1 CS451 Lecture 2: Introduction to Object Orientation Yugi Lee STB #555 (816) * Acknowledgement:
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 11a: Component-Level Design Software Engineering: A Practitioner’s Approach, 6/e Chapter.
Object Oriented Programming
Testing OO software. State Based Testing State machine: implementation-independent specification (model) of the dynamic behaviour of the system State:
Final Review. From ArrayLists to Arrays The ArrayList : used to organize a list of objects –It is a class in the Java API –the ArrayList class uses an.
CHAPTER 3 MODELING COMPONENT-LEVEL DESIGN.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Week 6: Software Design HNDIT Software Engineering Software Design Learning Outcomes  Understand the activities involved in the Design process.
Lecture 12 Implementation Issues with Polymorphism.
Testing in OO Environment The reasons for testing is not any different for any of the design and implementation methodologies, including OO methodology.
 Description of Inheritance  Base Class Object  Subclass, Subtype, and Substitutability  Forms of Inheritance  Modifiers and Inheritance  The Benefits.
Basic Characteristics of Object-Oriented Systems
Programming Logic and Design Fifth Edition, Comprehensive Chapter 7 Using Methods.
SOFTWARE DESIGN & SOFTWARE ENGINEERING Software design is a process in which data, program structure, interface and their details are represented by well.
Coupling and Cohesion Schach, S, R. Object-Oriented and Classical Software Engineering. McGraw-Hill, 2002.
Coupling and Cohesion Pfleeger, S., Software Engineering Theory and Practice. Prentice Hall, 2001.
MAITRAYEE MUKERJI Object Oriented Programming in C++
7. Modular and structured design
Coupling and Cohesion Rajni Bhalla.
Coupling and Cohesion 1.
Chapter 11 Object-Oriented Design
Software Design Mr. Manoj Kumar Kar.
Component-Level Design
Improving the Design “Can the design be better?”
CS223: Software Engineering
Programming Logic and Design Fourth Edition, Comprehensive
Software Design Lecture : 9.
ITEC 3220A Using and Designing Database Systems
Object Oriented Analysis and Design
Cohesion and Coupling.
DESIGN CONCEPTS AND PRINCIPLES
Chapter 20 Object-Oriented Concepts and Principles
Presentation transcript:

Rohini Sharma Roll No. RA1809A01 Regd. No M.Tech.(CSE) Part Time 3 rd Semester.

Contents  Object Oriented Concepts  Coupling in OOS  Cohesion in OOS  Conclusion

Object Oriented Concepts  Object: Encapsulation of state & behavior  Inheritance Hierarchy: A class inherits instance variables and methods from another class. This relationship is transitive, reflexive and antisymmetric.  Message Passing: Implies interaction relationship. Only means for an object to access and alter another object’s state.  Overriding: Redefinition of inherited instance variables and methods in subclasses.  Polymorphism: Same method may be invoked on objects of different classes.  Dynamic Binding: Binding b/w method invocation and code to be executed takes place during runtime.

Coupling Factor of dependency of one class on another class or one object on another object. High coupling system are  Unstable  Require more effort to modify  Leads to ripple effect  Increases Cost  Decreases reusability First formal definition given by Chidamber & Kemerer: “…any evidence of a method of one object using methods or instance variables of another object constitutes coupling”

Types of Coupling  Content Coupling- One class use variable of another class. How to reduce: Private access.  Common Coupling-Classes share global data. How to reduce: Class containing global data with public methods.  External Coupling-Dependency of classes on third party classes like MFC. How to reduce: Use Façade Pattern  Control Coupling-One class controls logic or sequence of execution of another class. How to reduce: Using Polymorphic operations. Contd../

 Stamp Coupling-Two classes modify or access data in the same object. How to reduce: Use methods.  Data Coupling-One class passes data to another as an argument. How to reduce: Pass few arguments containing abstract information  Message Coupling-Lowest possible Coupling.  Routine Call Coupling-When one routine calls another. How to reduce: Keep routine calls minimum. Sequence of calls be encapsulated in single routine.  Inclusion Coupling-One component includes source code of another component. How to reduce: Components not required should not be included.

Importance of Coupling in OOS  Change dependencies of server on client.  Hard to understand an object in isolation.  High coupling increases probability of remote effects. Loose coupling helps in tracking error, thus increases testability, eases debugging.

Broad Classification of Coupling Loose Coupling  Dependent Class contains pointer to interface.  Provides extensibility to designs. TestingShape Interface Draw() Erase() Area() Circle Draw() Erase() Area() Rectangle Draw() Erase() Area() Triangle Draw() Erase() Area() Fig. 1: Loose Coupling 1

Strong Coupling  Dependent class contains pointer to concrete class. Fig. 2: Strong Coupling TestingShape Draw() Erase() Area() 1

Measuring Coupling Coupling between two classes A and B increases if  A has an attribute that refers to B.  A calls on services of an object B.  A has a method which references B via return type or parameter.  A is a subclass of B. Loose Coupling is measured by noting the number of changes in data elements that could occur without changing the way systems communicate to each other  Adding new data elements to messages.  Changing the order of data elements.  Changing the names of data elements.  Changing the structures of data elements.  Omitting data elements.

Performance Issues  Message Creation Overhead and Performance  Longer Messages require more CPU time and memory  Message Transmission Overhead and Performance  Longer Messages require more CPU time and memory  Message Translation Overhead and Performance  Message form and content must be reduced and refined to maximize its meaning and reduce translation.  Message Interpretation Overhead and Performance  Complex messages may require string transformer to exhibit intended meaning.

Cohesion Generally Cohesion is a measure of how strongly related and focused the various modules of a software are. In Object Oriented Paradigm, if the methods serving the given class tend to be similar in many aspects, then class is said to have high Cohesion. Cohesion decreases if:  The responsibilities (methods) of a class have little in common.  Methods carry out many varied activities.

High Cohesion leads to:  Robustness  Reliability  Reusability  Understandability Low Cohesion leads to:  Difficulty to testing  Difficulty to reuse  Difficulty to understand  Difficulty to maintain

Types of Cohesion in OOS  Method Cohesion  Class Cohesion  Inheritance Cohesion

Method Cohesion Seven degrees defined from weakest to strongest  Coincidental (worst)- Parts have no significant relation.  Logical Cohesion- Only logical similarity  Temporal- Parts execute at same time  Procedural Cohesion- Parts follow certain sequence of execution  Communicational- Parts are connected by control flow and operate on same set of data  Sequential- Parts have communicational cohesion and connected by sequential control flow  Functional (best)- Parts contribute to a single task and are sequentially cohesive. Mostly Communicational Cohesion is the highest level of Cohesion achieved.

Class Cohesion Addresses relationship between non-inherited methods and non-inherited attributes of a class. Four degrees from weakest t strongest are defined:  Separable- When objects of a class represent multiple unrelated data abstractions.  Multifaceted- When objects of a class represent multiple related data abstraction. Alternatively when relational schema representing the class is not in second normal form Contd../ Class Order{ item orderitem; company Fromorder int discount; int quantity; ….. Public bool exprevenue() …}

 Non-delegated- When certain attributes do not describe the whole data abstraction represented by class, but only a component of it. Alternatively when relational schema representing the class is not in third normal form Contd../ Class Employee{ String name; Date birthdate; Project curpro; Employee projmanager; ….. Public float compsal(); …}

 Concealed- When useful data abstraction is concealed in data abstraction represented by class. Class Employee { int dayofbirth; int monofbirth; int yearofbirth; int dayofhire; int monofhire; int yearofhire; }

Inheritance Cohesion Describes binding of newly defined elements together with the inherited elements. Inheritance Cohesion is strong if hierarchy is generalization hierarchy and weak if hierarchy is merely used for code sharing among otherwise unrelated classes. Weak Inheritance Cohesion makes system difficult to understand, maintain and reuse.

Measuring Cohesion Five graphical metrics that use inheritance cohesion and class cohesion to asses design quality of inheritance hierarchy:  Inheritance Cohesion versus Inheritance Level.  Average Inheritance Cohesion of Children versus Number of Children of Parent Classes.  Inheritance Cohesion versus Number of Overridden Methods.  Class Cohesion of Parent Classes versus Number of Children.  Class Cohesion versus Number of Implemented Methods.

Inheritance Cohesion v/s Inheritance level  The graph should be horizontal ie. Cohesion does not change as we move down the hierarchy.  If graph level drops it means inheritance have been misused.  If plot rises up, it means children classes are more cohesive than parents.  Two types of graphs used:  Cohesion of classes sorted in increasing order of Inheritance level  Average Inheritance Cohesion v/s Inheritance Level.

Cohesion of classes sorted in increasing order of Inheritance level: Average Inheritance Cohesion v/s Inheritance Level. Fig. 4: Plot for a system of four classes. Fig. 5: Plot for four inheritance level

Average Inheritance Cohesion of Children versus Number of Children of Parent Classes. Super Class may be used as ‘Container of Service Methods’. Designer might include more and more classes as direct children to save coding. Fig. 6: Plot for system with four non-leaf classes

Inheritance Cohesion versus Number of Overridden Methods. If a class overrides some of the methods such that implementation is completely changed, cohesion of subclass can be adversely affected. Fig. 7: Plot for system of four classes

Class Cohesion of Parent Classes versus Number of Children. Sometimes superclass is used as ‘Container of Service Methods’ that are usually unrelated in superclass and fulfills the requirement of subclasses only. Fig. 8: Plot for system with four non-leaf classes.

Class Cohesion versus Number of Implemented Methods. A class with large number of implemented methods may be less cohesive as the class may abstract more than one entity. Fig. 9: Plot for system of four classes.

THANK YOU