2/14/20011 From Modules to Objects Professor James Landay CS169: Software Engineering Spring 2001...
-
Upload
bruce-arnold -
Category
Documents
-
view
221 -
download
0
Transcript of 2/14/20011 From Modules to Objects Professor James Landay CS169: Software Engineering Spring 2001...
2/14/2001 1
From Modules to Objects
Professor James LandayCS169: Software EngineeringSpring 2001February 14, 2001
2/14/2001 2
Outline
ReviewModulesCohesionAdministriviaCouplingEncapsulation & ADTs
2/14/2001 3
ReviewTesting doesn’t show the absence of bugsMajor assumptions of testing
inference from behavior, known environment, choosing the right test cases
Why shouldn’t SEs do all their own testing?What to test?
utility, reliability, robustness, performance, correctnessWhy is correctness not enough?
the spec might be bad!When are correctness proofs useful?
if the benefits outweigh the costs (lives, space, etc.)
2/14/2001 4
Modules
What is a module? lexically contiguous sequence of program
statements, bounded by boundary elements, with aggregate identifier
Examples procedures & functions in classical PLs objects & methods within objects in OO
PLs
2/14/2001 5
Good vs. Bad Modules
Modules in themselves are not “good”Must design them to have good properties
ALU
SHIFTER
RegistersALU
Shifter
Chip 1 Chip 2
Chip 3
i) CPU using 3 chips (modules)
Chip 1 Chip 2
Chip 3
AND gates OR gates
NOT gates
ii) CPU using 3 chips (modules)
What is the problem here?
2/14/2001 6
Good vs. Bad Modules
Two designs functionally equivalent, but the 2nd is hard to understand hard to locate faults difficult to extend or enhance cannot be reused in another product. Implication? -> expensive to perform maintenance
Good modules must be like the 1st design maximal relationships within modules (cohesion) minimal relationships between modules (coupling) this is the main contribution of structured design
2/14/2001 7
Modules to Objects
Objects with high cohesion and low coupling
Objects
Information hiding
Abstract data types
Data encapsulation
Modules with high cohesion and low coupling
Modules
2/14/2001 8
Cohesion ?
Degree of interaction within moduleSeven levels of cohesion
7. Functional | Informational (best) 5. Communicational 4. Procedural 3. Temporal 2. Logical 1. Coincidental (worst)
2/14/2001 9
1. Coincidental CohesionDef. ?
module performs multiple, completely unrelated actions
Example module prints next line, reverses the characters of the
2nd argument, adds 7 to 3rd argumentHow could this happen?
hard organizational rules about module sizeWhy is this bad?
degrades maintainability & modules are not reusableEasy to fix. How?
break into separate modules each performing one task
2/14/2001 10
2. Logical CohesionDef.
module performs series of related actions, one of which is selected by calling module
Examplefunction 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
Why is this bad? interface difficult to understand code for more than one action may be intertwined difficult to reuse
2/14/2001 11
3. Temporal CohesionDef. ?
module performs series of actions related in time Initialization example
open old db, new db, transaction db, print db, initialize sales district table, read first transaction record, read first old db record
Why is this bad? actions weakly related to one another, but strongly
related to actions in other modules code spread out -> not maintainable or reusable
Initialization example fix define these intializers in the proper modules & then
have an initialization module call each
2/14/2001 12
4. Procedural Cohesion
Def. ? module performs series of actions related by
procedure to be followed by productExample
update part number and update repair record in master db
Why is this bad? actions are still weakly related to one another not reusable
Solution break up!
2/14/2001 13
5. Communicational CohesionDef.
module performs series of actions related by procedure to be followed by product, but in addition all the actions operate on same data
Example 1update record in db and write it to audit trail
Example 2calculate new coordinates and send them to window
Why is this bad? still leads to less reusability -> break it up
2/14/2001 14
7. Informational CohesionDef.
module performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure
initialize_sales_region_table
update_sales_region_table
print_sales_region_table
••
••
••
••
•
••
••
••
••
•
Entry
Entry
Entry
Exit
Exit
Exit
Definition of sales_region_table
This is an ADT!
2/14/2001 15
7. Functional Cohesion
Def. module performs exactly one action
Examples get temperature of furnace compute orbital of electron calculate sales commission
Why is this good? more reusable corrective maintenance easier
fault isolationreduced regression faults
easier to extend product
2/14/2001 16
Coupling ?
Degree of interaction between two modules
Five levels of coupling 5. Data (best) 4. Stamp 3. Control 2. Common 1. Content
(worst)
2/14/2001 17
1. Content CouplingDef.
one module directly references contents of the other
Example module a modifies statements of module b module a refers to local data of module b in
terms of some numerical displacement within b module a branches into local label of module b
Why is this bad? almost any change to b requires changes to a
2/14/2001 18
2. Common CouplingDef.
two modules have write access to the same global dataExample
two modules have access to same database, and can both read and write same record
use of Java public statementWhy is this bad?
resulting code is unreadablemodules can have side-effectsmust read entire module to understand
difficult to reuse module exposed to more data than necessary
cca
ccb
global variable
while (global variable == 0)if (argument xyz > 25)
module 3 ();else
module 4 ();
2/14/2001 19
3. Control CouplingDef.
one module passes an element of control to the other
Example control-switch passed as an argument
Why is this bad? modules are not independent
module b must know the internal structure of module aaffects reusability
2/14/2001 20
4. Stamp CouplingDef.
data structure is passed as parameter, but called module operates on only some of individual components
Examplecalculate withholding (employee record)
Why is this bad? affects understanding
not clear, without reading entire module, which fields of record are accessed or changed
unlikely to be reusableother products have to use the same higher level data structures
passes more data than necessarye.g., uncontrolled data access can lead to computer crime
2/14/2001 21
5. Data CouplingDef.
every argument is either a simple argument or a data structure in which all elements are used by the called module
Exampledisplay time of arrival (flight number) get job with highest priority (job queue)
Slippery slope between stamp & data (see queue)
Why is this good? maintenance is easier good design has high cohesion & weak coupling
2/14/2001 22
Modules to Objects
Objects with high cohesion and low coupling
Objects
Information hiding
Abstract data types
Data encapsulation
Modules with high cohesion and low coupling
Modules
2/14/2001 23
Data Encapsulation ?
Def. data structure together with actions to
be performed on that structure Bad job queue example
define job queue w/ 1 op together in module (repeat for init, add, etc.)
low cohesion Better job queue example
put all job queue ops together w/ 1 definition of job queue in 1 module
informational cohesion & data encapsulation
Abstraction or stepwise refinement easier development & maintenance helps us cope w/ change
initialize_job_queue ();
add_job_to_queue (job_a);
m_encapsulationm_123
implementation ofjob_queue
initialize_job_queue () { }
••
•
••
•
add_job_to_queue (job j) { }
••
•
••
•
remove_job_from_queue (job j) { }
••
•
••
•
••
•
remove_job_from_queue (job_b);
••
••
••
••
•
••
•
••
•
••
•
••
•
{ job job_a, job_b;
}
2/14/2001 24
Abstract Data Types
Def. data type together with actions to be performed on instantiations of that data type subtle difference with encapsulation
Exampleclass JobQueue {
public int queueLength; // length of job queuepublic int queue = new int[25]; // up to 25 jobs
// methodspublic void initializeJobQueue (){
// body of method}public void addJobToQueue (int jobNumber){
// body of method }
} // JobQueue
2/14/2001 25
Information Hiding
Really “details hiding” hiding implementation details, not information
Example design modules so that items likely to change
are hiddenfuture change localizedchange cannot affect other modules
data abstractiondesigner thinks at level of ADT
2/14/2001 26
Information hiding
Exampleclass JobQueue {
private int queueLength; // length of job queueprivate int queue = new int[25]; // up to 25 jobs
// methodspublic void initializeJobQueue (){// body of method}public void addJobToQueue (int jobNumber){// body of method }
} // JobQueue
Now queue and queueLength are inaccessible
2/14/2001 27
Objects
Def. class – abstract data type which supports inheritance objects are instantiations of classes
Inheritance new data types defined as extensions to previously defined types
don’t have to define from scratch -> provides more data abstraction Example
Define humanBeing to be a classA humanBeing has attributes, such as age, height, genderAssign values to attributes when describing object Define parent to be a subclass of humanBeing A parent has all attributes of humanBeing, plus attributes of his/her own
(name of oldest child, number of children)A parent inherits all attributes of humanBeing
2/14/2001 28
Inheritance (UML)
(base class)
(derived class)
inherits from (“isA ”)
derived part
incremental part
HumanBeing
Parent
UML notation: boxes represent classes open triangle represent inheritance
2/14/2001 29
Inheritance (Java)
class HumanBeing{
private int age;private float height;
public
// declarations of operations on HumanBeing} // class HumanBeing class Parent extends HumanBeing{
private String nameOfOldestChild;private int numberOfChildren;
public
// declarations of operations on Parent} // class Parent
2/14/2001 30
Inheritance
Method Foo (b : Base) can be applied to objects of any subclass of Base
Base
2/14/2001 31
Aggregation (UML)
UML notation: diamond (1 or more) no diamond (1)
PersonalComputer
MonitorCPU Keyboard Printer
Aggregation refers to the components of a class- used to group related items- each of these (CPU, etc.) would be instance var
2/14/2001 32
Polymorphism & Dynamic Binding
Classical paradigm
must explicitly invoke the correct version
function draw_linefunction draw_circlefunction draw_rectangle
2/14/2001 33
Polymorphism & Dynamic Binding Object-oriented paradigm
all that is needed is myGraphObj.draw() Dynamic binding
correct method invoked at run-time (dynamically) Polymorphic
method draw can be applied to objects of different classes
GraphObjClass
LineClassCircleClass
Implementation of method draw for a rectangle
method draw
Implementation of method draw for a line
Implementation of method draw for a circle
RectClass
2/14/2001 34
Polymorphism & Dynamic Binding
Advantages ?
can build for the futureeasy to add a new shape w/o changing previous code
• don’t ever want to mess w/ code that works
easy to iterate over similar but distinct objectsdraw all GraphObjs
Disadvantages ? performance (have to look things up at run time) have to design classes better
have to understand how it will be extended over time harder to understand the code
must understand multiple possibilities for specific method
2/14/2001 35
Advantages of Objects
Same as abstract data types information hiding data abstraction procedural abstraction
start code design at high level & continue down levels until using primitives
Inheritance provides further data abstraction easier and less error-prone product development easier maintenance
2/14/2001 36
Summary
Good modules have strong cohesion and weak coupling
Data encapsulation, ADTs, information hiding, & objects ease maintenance & reuse
Polymorphism has advantages & disadvantages
2/14/2001 37
Next Time
Questions?Friday’s lecture on Requirements
read Chapter 9 from Schach