chapter 7 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
CHAPTER 7 PowerPoint Presentation
Download Presentation
CHAPTER 7

Loading in 2 Seconds...

play fullscreen
1 / 75

CHAPTER 7 - PowerPoint PPT Presentation


  • 106 Views
  • Uploaded on

CHAPTER 7. INTRODUCTION TO OBJECTS. Overview. What is a module? Cohesion Coupling Data encapsulation product maintenance Abstract data types Information hiding Objects Inheritance, polymorphism and dynamic binding Cohesion and coupling of objects. Introduction to Objects.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'CHAPTER 7' - janice


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
chapter 7
CHAPTER 7

INTRODUCTION TO OBJECTS

overview
Overview
  • What is a module?
  • Cohesion
  • Coupling
  • Data encapsulation product maintenance
  • Abstract data types
  • Information hiding
  • Objects
  • Inheritance, polymorphism and dynamic binding
  • Cohesion and coupling of objects
introduction to objects
Introduction to Objects
  • What is a module?
    • A lexically contiguous sequence of program statements, bounded by boundary elements, with an aggregate identifier (name)
design of computer
Design of Computer
  • A highly incompetent computer architect decides to build an ALU, shifter and 16 registers with AND, OR, and NOT gates, rather than NAND or NOR gates.
design of computer contd
Design of Computer (contd)
  • Architect designs 3 silicon chips
design of computer contd1
Design of Computer (contd)
  • Redesign with one gate type per chip
  • Resulting “masterpiece”
computer design contd
Computer Design (contd)
  • The two designs are functionally equivalent
    • Second design is
      • Hard to understand
      • Hard to locate faults
      • Difficult to extend or enhance
      • Cannot be reused in another product
  • Modules must be like the first design
    • Maximal interactionswithin modules, minimal interactions between modules
composite structured design c sd
Composite/Structured Design (C/SD)
  • Method for breaking up a product into modules for
    • Maximal interaction within module, and
    • Minimal interaction between modules
  • Module cohesion
    • Degree of interaction within a module
  • Module coupling
    • Degree of interaction between modules

High Cohesion but Low Coupling is desirable

action logic and context of module
Action, Logic, and Context of Module
  • The action of a module – what it does
  • The logic of a module – how the module performs its action
  • The context of a module is the specific usage of that module
  • In C/SD, the name of a module is its action
  • Example
    • Module computes square root of double precision integers using Newton’s algorithm. Module is named compute square root
cohesion
Cohesion
  • The degree of interaction within a module
  • Seven categories or levels of cohesion
    • Functional cohesion is optimal for the structured paradigm
    • Informational cohesion is optimal for OO paradigm
1 coincidental cohesion
1. Coincidental Cohesion
  • A module has coincidental cohesion if it performs multiple, completely unrelated actions
  • Example
    • print next line, reverse string of characters comprising second parameter, add 7 to fifth parameter, convert fourth parameter to floating point
  • Arise from rules like
    • “Every module will consist of between 35 and 50 statements”
why is coincidental cohesion so bad
Why Is Coincidental Cohesion So Bad?
  • Degrades maintainability
  • Modules are not reusable
  • This is easy to fix
    • Break into separate modules each performing one task
2 logical cohesion
2. Logical Cohesion
  • A module has logical cohesion when it performs a series of related actions, one of which is selected by the calling module
  • Example 1

function code = 7;

new operation (op code, dummy 1, dummy 2, dummy 3);

// dummy 1, dummy 2, and dummy 3 are dummy variables,

// not used if function code is equal to 7

  • Example 2
    • Module performing all input and output
  • Example 3
    • One version of OS/VS2 contained logical cohesion module performing 13 different actions. Interface contained 21 pieces of data
why is logical cohesion so bad
Why Is Logical Cohesion So Bad?
  • The interface is difficult to understand
  • Code for more than one action may be intertwined, leading to maintenance problems
  • Difficult to reuse
why is logical cohesion so bad contd
Why Is Logical Cohesion So Bad? (contd)
  • Example: If a new tape unit is installed, what sections of code should be modified?
3 temporal cohesion
3. Temporal Cohesion
  • A module has temporal cohesion when it performs a series of actions related in time
  • Example
    • open old master file, new master file, transaction file, print file, initialize sales district table, read first transaction record, read first old master record (a.k.a. perform initialization)
why is temporal cohesion so bad
Why Is Temporal Cohesion So Bad?
  • Actions of this module are weakly related to one another, but strongly related to actions in other modules.
    • Consider sales district table
  • Not reusable
4 procedural cohesion
4. Procedural Cohesion
  • A module has procedural cohesion if it performs a series of actions related by the procedure to be followed by the product
  • Example
    • read part number and update repair record on master file
why is procedural cohesion so bad
Why Is Procedural Cohesion So Bad?
  • Actions are still weakly connected, so module is not reusable
5 communicational cohesion
5. Communicational Cohesion
  • A module has communicational cohesion if it performs a series of actions related by the procedure to be followed by the product, but in addition all the actions operate on the same data
  • Example 1
    • update record in database and write it to audit trail
  • Example 2
    • calculate new coordinates and send them to terminal
7 informational cohesion
7. Informational Cohesion
  • A module has informational cohesion if it performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure
why is informational cohesion so good
Why Is Informational Cohesion So Good?
  • Essentially, this is an abstract data type
  • Optimal for the OO paradigm
7 functional cohesion
7. Functional Cohesion
  • Module with functional cohesion performs exactly one action
  • Example 1
    • get temperature of furnace
  • Example 2
    • compute orbital of electron
  • Example 3
    • write to floppy disk
  • Example 4
    • calculate sales commission
why is functional cohesion so good
Why is functional cohesion so good?
  • More reusable
  • Corrective maintenance easier
    • Fault isolation
    • Fewer regression faults
  • Easier to extend product
coupling
Coupling
  • Degree of interaction between two modules
  • Five categories or levels of coupling
1 content coupling
1. Content Coupling
  • Two modules are content coupled if one directly references contents of the other
  • Example 1
    • Module a modifies statement of module b
  • Example 2
    • Module a refers to local data of module b in terms of some numerical displacement within b
  • Example 3
    • Module a branches into local label of module b
why is content coupling so bad
Why Is Content Coupling So Bad?
  • Almost any change to b, even recompiling b with new compiler or assembler, requires change to a
2 common coupling
2. Common Coupling
  • Two modules are common coupled if they have write access to the same global data
  • Example 1
    • Modules cca and ccb can access and change value of global variable
2 common coupling contd
2. Common Coupling (contd)
  • Example 2
    • Modules cca and ccb both have access to same database, and can both read andwrite same record
  • Example 3
    • FORTRAN common
    • COBOL common (nonstandard)
    • COBOL-80 global
why is common coupling so bad
Why Is Common Coupling So Bad?
  • Contradicts the spirit of structured programming
    • The resulting code is virtually unreadable
why is common coupling so bad contd
Why Is Common Coupling So Bad? (contd)
  • Modules can have side effects
    • This affects their readability
  • If a maintenance change is made to a global data in a module then every module that can access that global data has to be changed
  • Difficult to reuse
  • Module exposed to more data than necessary
3 control coupling
3. Control Coupling
  • Two modules are control coupled if one passes an element of control to the other
  • Example 1
    • Operation code passed to module with logical cohesion
  • Example 2
    • Control-switch passed as argument
why is control coupling so bad
Why Is Control Coupling So Bad?
  • Modules are not independent; module b (the called module) must know internal structure and logic of module a.
    • Affects reusability
  • Associated with modules of logical cohesion
4 stamp coupling
4. Stamp Coupling
  • Some languages allow only simple variables as parameters
    • part number
    • satellite altitude
    • degree of multiprogramming
  • Many languages also support passing of data structures
    • part record
    • satellite coordinates
    • segment table
4 stamp coupling contd
4. Stamp Coupling (contd)
  • Two modules are stamp coupled if a data structure is passed as a parameter, but the called module operates on some but not all of the individual components of the data structure
why is stamp coupling so bad
Why Is Stamp Coupling So Bad?
  • It is not clear, without reading the entire module, which fields of a record are accessed or changed
    • Example

calculate withholding (employee record)

  • Difficult to understand
  • Unlikely to be reusable
  • More data than necessary is passed
    • Uncontrolled data access can lead to computer crime
  • There is nothing wrong with passing a data structure as a parameter, provided all the components of the data structure are accessed and/or changed

e.g., - invert matrix (original matrix, inverted matrix)

- print inventory record (warehouse record)

5 data coupling
5. Data Coupling
  • Two modules are data coupled if all parameters are homogeneous data items (simple parameters, or data structures all of whose elements are used by called module)
  • Examples
    • display time of arrival (flight number)
    • compute multiplication (first number, second number, result)
    • get job with highest priority (job queue)
why is data coupling so good
Why Is Data Coupling So Good?
  • The difficulties of content, common, control, and stamp coupling are not present
  • Maintenance is easier
coupling case study contd
Coupling Case Study (contd)
  • Interface description
coupling case study contd1
Coupling Case Study (contd)
  • Coupling between all pairs of modules
data encapsulation
Data Encapsulation
  • Example
    • Design an operating system for a large mainframe computer. It has been decided that batch jobs submitted to the computer will be classified as high priority, medium priority, or low priority. There must be three queues for incoming batch jobs, one for each job type. When a job is submitted by a user, the job is added to the appropriate queue, and when the operating system decides that a job is ready to be run, it is removed from its queue and memory is allocated to it.
  • Design 1 (Next slide)
    • Low cohesion—operations on job queues are spread all over product
data encapsulation1
Data Encapsulation
  • m_encapsulation has informational cohesion
  • m_encapsulation is an implementation of data encapsulation
    • Data structure (job_queue) together with operations performed on that data structure
  • Advantages of using data encapsulation
    • Development
    • Maintenance
data encapsulation and development
Data Encapsulation and Development
  • Data encapsulation is an example of abstraction
  • Job queue example
    • Data structure
      • job_queue
    • Three new functions
      • initialize_job_queue
      • add_job_to_queue
      • delete_job_from_queue
  • Abstraction
    • Conceptualize problem at higher level
      • job queues and operations on job queues
    • not lower level
      • records or arrays
stepwise refinement
Stepwise Refinement

1. Design in terms of high level concepts

    • It is irrelevant how job queues are implemented

2. Design low level components

    • Totally ignore what use will be made of them
  • In 1st step, assume existence of lower level
    • Concern is the behavior of the data structure
      • job_queue
  • In 2nd step, ignore existence of high level
    • Concern is the implementation of that behavior
  • In a larger product, there will be many levels of abstraction
data encapsulation and maintenance
Data Encapsulation and Maintenance
  • Identify aspects of product likely to change
  • Design product so as to minimize the effects of change
    • Data structures are unlikely to change
    • Implementation may change
  • Data encapsulation provides a way to cope with change
data encapsulation and maintenance contd
Data Encapsulation and Maintenance (contd)
  • What happens if queue is now implemented as a two-way linked list ofJobRecord?
    • Module that uses JobRecord need not be changed at all, merely recompiled
    • C++

Java

abstract data types
Abstract Data Types
  • Problem with both implementations
    • Only one queue
  • Need
    • We need:

Data type + operations performed on instantiations of that data type

  • Abstract data type
abstract data type
Abstract Data Type
  • (Problems caused by public attributes solved later)
information hiding
Information Hiding
  • Data abstraction
    • Designer thinks at level of an ADT
  • Procedural abstraction
    • Define a procedure—extend the language
  • Instances of a more general design concept, information hiding (or details hiding)
    • Design the modules in way that items likely to change are hidden
    • Future change is localized
    • Changes cannot affect other modules
information hiding contd
Information Hiding (contd)
  • C++ abstract data type implementation with information hiding
information hiding contd1
Information Hiding (contd)
  • Effect of information hiding via private attributes
objects
Objects
  • First refinement
    • Product is designed in terms of abstract data types
    • Variables (“objects”) are instantiations of abstract data types
  • Second refinement
    • Class: abstract data type that supports inheritance
    • Objects are instantiations of classes
inheritance
Inheritance
  • Define humanBeing to be a class
    • A humanBeing has attributes, such as age, height, gender
    • Assign values to attributes when describing object
  • Define Parent to be a subclass of HumanBeing
    • A Parent has all attributes of a HumanBeing, plus attributes of his/her own (name of oldest child, number of children)
    • AParentinherits all attributes of humanBeing
  • The property of inheritance is an essential feature of object-oriented languages such as Smalltalk, C++, Ada 95, Java (but not C, FORTRAN)
inheritance contd
Inheritance (contd)
  • UML notation
    • Inheritance is represented by a large open triangle
aggregation
Aggregation
  • UML Notation
association
Association
  • UML Notation
equivalence of data and action
Equivalence of Data and Action
  • Classical paradigm
    • record_1.field_2
  • Object-oriented paradigm
    • thisObject.attributeB
    • thisObject.methodC ()
polymorphism and dynamic binding
Polymorphism and Dynamic Binding
  • Classical paradigm
    • Must explicitly invoke correct version
polymorphism and dynamic binding contd1
Polymorphism and Dynamic Binding (contd)
  • All that is needed is myFile.open()
    • Correct method invoked at run-time (dynamically)
  • Method open can be applied to objects of different classes
    • Polymorphic
polymorphism and dynamic binding contd2
Polymorphism and dynamic binding (contd)
  • MethodcheckOrder (b : Base)can be applied to objects of any subclass ofBase
polymorphism and dynamic binding contd3
Polymorphism and Dynamic Binding (contd)
  • Can have a negative impact on maintenance
    • Code is hard to understand if there are multiple possibilities for a specific method
    • The cause of a failure can be very difficult to determine
  • Polymorphism and dynamic binding
    • Strength and weakness of the object-oriented paradigm
cohesion and coupling of objects
Cohesion and Coupling of Objects
  • No new forms of cohesion or coupling
    • Object-oriented cohesion and coupling always reduces to classical cohesion
  • The only feature unique to the object-oriented paradigm is inheritance
    • Cohesion has nothing to do with inheritance
    • Two objects with the same functionality have the same cohesion
    • It does not matter if this functionality is inherited or not
    • Similarly, so-called object-oriented coupling always reduces to classical coupling
advantages of objects
Advantages of Objects
  • Same as advantages of abstract data types
    • Information hiding
    • Data abstraction
    • Procedural abstraction
  • Inheritance provides further data abstraction
    • Easier and less error-prone product development
    • Easier maintenance
  • Objects are more reusable than modules with functional cohesion