CS1132_Fall_2011_Lecture4_BB

CS1132_Fall_2011_Lecture4_BB - Chapter 4 Modularity and...

Info iconThis preview shows pages 1–14. Sign up to view the full content.

View Full Document Right Arrow Icon
1 Chapter 4 Modularity and Data Abstraction - We will look at a Priority Queue ADT - Build a module with the PQ ADT - Use the module to sort - Show two different implementations hidden from the user s
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Modularity Splits a large program into smaller modules Myers 1978: “Modularity is the single attribute of software that allows a program to be intellectually manageable.”
Background image of page 2
Modularity
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Interfaces
Background image of page 4
Functional independence Cohesion: Each module should do one thing We want high cohesion Coupling: Each module should have a simple interface We want low coupling
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Cohesion Measure of interconnection within a module The degree to which one part of a module depends on another Maximize cohesion
Background image of page 6
Types of cohesion Coincidental – avoid meaningless relations Logical - same idea Temporal - same time Procedural - calls Communicational - shared data Change together
Background image of page 7

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Types of cohesion Coincidental cohesion (worst) -- when parts of a module are grouped arbitrarily; the only relationship between the parts is that they have been grouped together. Logical cohesionL -- when parts of a module are grouped because they logically are categorized to do the same thing, even if they are different by nature (e.g. grouping related routines). Temporal cohesion -- when parts of a module are grouped by when they are processed - the parts are processed at a particular time in program execution (e.g. a function which is called after catching an exception which closes open files, creates an error log, and notifies the user). 8
Background image of page 8
Types of cohesion (Contd.) Procedural cohesion -- when parts of a module are grouped because they always follow a certain sequence of execution (e.g. a function which checks file permissions and then opens the file). Communicational cohesion -- when parts of a module are grouped because they operate on the same data (e.g. a module which operates on the same record of information). Sequential cohesion -- when parts of a module are grouped because the output from one part is the input to another part like an assembly line (e.g. a function which reads data from a file and processes the data). Functional cohesion (best) -- when parts of a module are grouped because they all contribute to a single well-defined task of the module 9
Background image of page 9

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Coupling Measure of interconnection among modules The degree to which one module depends on others Minimize coupling
Background image of page 10
Information hiding Each module should hide a design decision from others Ideally, one design decision per module, but usually design decisions are closely related
Background image of page 11

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Trade-offs Suppose moving functionality from one module to another will Decrease coupling between modules Increase cohesion in one module Decrease cohesion in another Should you do it?
Background image of page 12
How to get modularity Think about reuse capability Think about design decisions – hide them Reduce coupling and increase cohesion By making small changes Reduce impact of changes If adding a feature requires changing large part of the system, refactor so change is easy
Background image of page 13

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 14
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 11/14/2011 for the course CSCI 1132 taught by Professor Haya during the Fall '11 term at GWU.

Page1 / 62

CS1132_Fall_2011_Lecture4_BB - Chapter 4 Modularity and...

This preview shows document pages 1 - 14. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online