Quality of a Class Abstraction: Coupling & Cohesion Michael L. Collard, Ph.D. Department of Computer Science Kent State University.

Slides:



Advertisements
Similar presentations
Introduction to C Programming
Advertisements

Structured Design. 2 Design Quality – Simplicity “There are two ways of constructing a software design: One is to make it so simple that there are obviously.
Communication between modules, cohesion and coupling
1 Software Design Introduction  The chapter will address the following questions:  How do you factor a program into manageable program modules that can.
1 SOFTWARE DESIGN QUALITY COHESION and COUPLING (Part II)
Slide 7A.1 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach.
Lecture 9 Improving Software Design CSC301-Winter 2011 – University of Toronto – Department of Computer Science Hesam C. Esfahani
What is Software Design?  Introduction  Software design consists of two components, modular design and packaging.  Modular design is the decomposition.
Copyright Irwin/McGraw-Hill Software Design Prepared by Kevin C. Dittman for Systems Analysis & Design Methods 4ed by J. L. Whitten & L. D. Bentley.
UHD::CS3320::CHAP61 INTRODUCTION TO OBJECTS Chapter 6.
Chapter 12 File Management
Module: Definition ● A logical collection of related program entities ● Not necessarily a physical concept, e.g., file, function, class, package ● Often.
1 SOFTWARE DESIGN QUALITY COHESION and COUPLING (Part I)
Jump to first page 1 System Design (Finalizing Design Specifications) Chapter 3d.
Criteria for good design. aim to appreciate the proper and improper uses of inheritance and appreciate the concepts of coupling and cohesion.
Guide To UNIX Using Linux Third Edition
PVK-Ht051 Contents Introduction Requirements Engineering Project Management Software Design Detailed Design and Coding Quality Assurance Maintenance.
Contents Introduction Requirements Engineering Project Management Software Design Detailed Design and Coding Quality Assurance.
Chapter 9: Coupling & Cohesion Omar Meqdadi SE 273 Lecture 9 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
INTRODUCTION TO PROGRAMMING STRUCTURE Chapter 4 1.
สาขาวิชาเทคโนโลยี สารสนเทศ คณะเทคโนโลยีสารสนเทศ และการสื่อสาร.
Coupling and Cohesion Pfleeger, S., Software Engineering Theory and Practice. Prentice Hall, 2001.
Coupling and Cohesion Source:
Chapter 9 Defining New Types. Objectives Explore the use of member functions when creating a struct. Introduce some of the concepts behind object-oriented.
SWE © Solomon Seifu ELABORATION. SWE © Solomon Seifu Lesson 12-3 Cohesion.
Program Design Simple Program Design Third Edition A Step-by-Step Approach 9.
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
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.
1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13.
SE: CHAPTER 7 Writing The Program
Concepts of Software Quality Yonglei Tao 1. Software Quality Attributes  Reliability  correctness, completeness, consistency, robustness  Testability.
Cohesion and Coupling CS 4311
System Implementation
Coupling & Cohesion CMSC 201- Fall '11. Vocabulary Routine- A programming unit that performs a task, such as a function, procedure, method, or main class.
An Object-Oriented Approach to Programming Logic and Design Fourth Edition Chapter 6 Using Methods.
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.
Slide 7.1 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented Software Engineering WCB/McGraw-Hill, 2008 Stephen R.
Coupling Cohesion Chandan R. Rupakheti Steve Chenoweth (Chapter 18)
Chapter 10 Software Engineering. Understand the software life cycle. Describe the development process models. Understand the concept of modularity in.
CCSB223/SAD/CHAPTER131 Chapter 13 Designing the System Internals.
CS540 Software Design Lecture 3 & 4 1 Lecture 3 & 4: Modularity, Coupling, Cohesion and Abstraction Anita S. Malik Adapted from Schach.
Dr D. Greer, Queens University Belfast )Chapter Six 1 Software Engineering Chapter Six Software Design Quality Learning Outcomes.
Jump to first page (C) 1998, Arun Lakhotia 1 Design Quality Metrics Arun Lakhotia University of Southwestern Louisiana Po Box Lafayette, LA 70504,
Design and Planning Or: What’s the next thing we should do for our project?
Introduction to OOP CPS235: Introduction.
Systems Design.  Application Design  User Interface Design  Database Design.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Key Principles of Software Architecture and Design (II) adapted from Dave Penny’s.
Week 6: Software Design HNDIT Software Engineering Software Design Learning Outcomes  Understand the activities involved in the Design process.
Slide 1 Good Methods. Slide 2 Cohesion and Coupling l For structured design These software metrics were used extensively Proven to be effective l For.
Lecture 12 Implementation Issues with Polymorphism.
Chapter 9: Coupling & Cohesion Omar Meqdadi SE 273 Lecture 9 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Slide 7B.31 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach.
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.
Further Modularization, Cohesion, and Coupling. Simple Program Design, Fourth Edition Chapter 9 2 Objectives In this chapter you will be able to: Further.
7. Modular and structured design
Coupling and Cohesion Rajni Bhalla.
Coupling and Cohesion 1.
Cohesion and Coupling Chapter 5, Pfleeger 01/01/10.
Designing and Debugging Batch and Interactive COBOL Programs
Improving the Design “Can the design be better?”
CS223: Software Engineering
Programming Logic and Design Fourth Edition, Comprehensive
Software Design Lecture : 9.
Software Design Lecture : 8
Communication between modules, cohesion and coupling
Cohesion and Coupling.
DESIGN CONCEPTS AND PRINCIPLES
Presentation transcript:

Quality of a Class Abstraction: Coupling & Cohesion Michael L. Collard, Ph.D. Department of Computer Science Kent State University

Why Use Multiple Classes? ● Simplify testing ● Increase program understanding ● Increase reuse (internal and external) ● Reduce maintenance costs for fixes and enhancements ● Permit replacement

Desired Class/Object Interaction ● Maximize internal interaction (cohesion) – easier to understand – easier to test ● Minimize external interaction (coupling) – can be used independently – easier to test – easier to replace – easier to understand

Cohesion ● “degree of connectivity among the elements of a single module, and in object-oriented design, a single class/object” ● Internal measure: – on a single class/object/module ● Very difficult to measure (more later in metrics)

Cohesion: Good(high) to bad(low) ● Informational (best) ● Functional (best) ● Sequential (not bad) ● Communicational (not bad) ● Procedural ● Temporal ● Logical ● Coincidental (worst)

/* Joe's Stuff */ class Joe { public: // converts a path in windows to one in linux string win2lin(string); // number of days since the beginning of time int days(string); // outputs a financial report void outputreport(financedata, std::ostream&); };

Coincidental Cohesion ● Performs multiple, completely unrelated actions ● May be based on factors outside of the design: – skillset or interest of developers – avoidance of small modules ● No reusability ● Difficult corrective maintenance or enhancement

class Output { public: // outputs a financial report void outputreport(financedata); // outputs the current weather void outputweather(weatherdata); // output a number in a nice formatted way void outputint(int); };

Logical Cohesion ● Performs a series of related actions, one of which is selected by the calling module ● Parts are related in a logical way – -> but not the primary logical association

Logical Cohesion (cont) ● May include both high and low-level actions in the same class ● May include unused parameters for certain uses ● Interface is difficult to understand – in order to do something you have to wade through a lot of unrelated possible actions

class Init { public: // initializes financial report void initreport(financedata); // initializes current weather void initweather(weatherdata); // initializes master count void initcount(); }

Temporal Cohesion ● Perform a series of actions that are related by time ● Often happens in initialization or shutdown ● Degrades to logical cohesion if time of action changes ● Addition of parts to the system may require additions to multiple modules, e.g., shutdown, startup, etc.

class Data { public: // read part number from an input file and update // the directory count void readandupdate (data&); };

Procedural Cohesion ● Action based on the ordering of steps ● Related by usage in ordering ● Changes to the ordering of steps or purpose of steps requires changing the module abstraction ● Situations where this particular sequence is used is limited

class Data { public: // update record in database and write it to // the audit trail void updateandaudit (data); }; class Trajectory { // calculate new trajectory and send it to the printer void newtrajectoryandprint(); };

Communicational Cohesion ● Action based on the ordering of steps on all the same data ● Actions are related but still not completely separated ● Module cannot be reused

Sequential Cohesion ● Methods are together in a class because the output from one part is the input to another part like an assembly line

Functional Cohesion ● Module that performs a single action or achieves a single goal ● Maintenance involves the entire single module ● Very reusable because the module is completely independent in action of other modules ● Can be replaced easily

Information Cohesion ● Performs a number of actions ● Each action has its own entry point and independent code ● All actions are performed on a shared data structure ● Object-Oriented

Coupling: good(low) to bad(high) ● Data Coupling (best) ● Stamp Coupling ● Control Coupling ● Common Coupling ● Content Coupling (worst)

Content Coupling ● A module directly references the content of another module – module p modifies a statement of module q – Module p refers to local data of module q (in terms of a numerical displacement) – Module p branches to a local label of module q

Content Coupling (cont) ● Content coupled modules are inextricably interlinked – Change to module p requires a change to module q (including recompilation) – Reusing module p requires using module q also – Typically only possible in assembly languages

Common Coupling ● Using global variables (i.e., global coupling) ● All modules have read/write access to a global data block ● Modules exchange data using the global data block (instead of arguments) ● Single module with write access where all other modules have read access is not common coupling

Common Coupling (cont) ● Have to look at many modules to determine the current state of a variable ● Side effects require looking at all the code in a function to see if there are any global effects ● Changes in one module to the declaration requires changes in all other modules ● Identical list of global variables must be declared for module to be reused ● Module is exposed to more data than is needed

Control Coupling ● One module passes an element of control to another module ● One module explicitly controls the logic of another – Control switch is passed as an argument – Module p passes an argument to module q that directly tells it what control structure path to take

Control Coupling (cont) ● Control coupling? – Module p calls module q and q passes a flag back to p that indicates an error – Module p calls module q and q passes a flag back to p that tells p that it must output the error “I goofed up” ● Modules should pass data and leave control path decisions private to a module ● Independent reuse is not possible

Stamp Coupling ● One module passes more data then needed to another module – void swap(int v[], int i, int j); – double calcsalary(Employee& e); ● Often involves records (structs) with lots of fields ● Entire record is passed, but only a few fields are used ● Efficiency considerations?

Data Coupling ● Only required data is passed from one module to another ● All arguments are homogenous data items – simple data type – complex data type, but all parts are used ● Holy grail ● Allows for reuse, maintenance, understanding, etc.