From Modules to Objects Professor James Landay CS

From Modules to Objects Professor James Landay CS 169: Software Engineering Spring 2001 February 14, 2001 2/14/2001 1

Outline z. Review z. Modules z. Cohesion z. Administrivia z. Coupling z. Encapsulation & ADTs 2/14/2001 2

Review z Testing doesn’t show the absence of bugs z Major assumptions of testing yinference from behavior, known environment, choosing the right test cases z Why shouldn’t SEs do all their own testing? z What to test? yutility, reliability, robustness, performance, correctness z Why is correctness not enough? ythe spec might be bad! z When are correctness proofs useful? yif the benefits outweigh the costs (lives, space, etc. ) 2/14/2001 3

Modules z. What is a module? ylexically contiguous sequence of program statements, bounded by boundary elements, with aggregate identifier z. Examples yprocedures & functions in classical PLs yobjects & methods within objects in OO PLs 2/14/2001 4

Good vs. Bad Modules z. Modules in themselves are not “good” z. Must design them to have good properties i) CPU using 3 chips (modules) 2/14/2001 ii) CPU using 3 chips (modules) What is the problem here? 5

Good vs. Bad Modules z Two designs functionally equivalent, but the 2 nd is yhard to understand yhard to locate faults ydifficult to extend or enhance ycannot be reused in another product. Implication? y-> expensive to perform maintenance z Good modules must be like the 1 st design ymaximal relationships within modules (cohesion) yminimal relationships between modules (coupling) ythis is the main contribution of structured design 2/14/2001 6

Modules to Objects 2/14/2001 Objects with high cohesion and low coupling Ý Objects Ý Information hiding Ý Abstract data types Ý Data encapsulation Ý Modules with high cohesion and low coupling Ý Modules 7

Cohesion ? z. Degree of interaction within module z. Seven levels of cohesion y 7. Functional | Informational y 5. Communicational y 4. Procedural y 3. Temporal y 2. Logical y 1. Coincidental 2/14/2001 (best) (worst) 8

1. Coincidental Cohesion z Def. ? ymodule performs multiple, completely unrelated actions z Example ymodule prints next line, reverses the characters of the 2 nd argument, adds 7 to 3 rd argument z How could this happen? yhard organizational rules about module size z Why is this bad? ydegrades maintainability & modules are not reusable z Easy to fix. How? ybreak into separate modules each performing one task 2/14/2001 9

2. Logical Cohesion z Def. ymodule performs series of related actions, one of which is selected by calling module z Example 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 z Why is this bad? yinterface difficult to understand ycode for more than one action may be intertwined ydifficult to reuse 2/14/2001 10

3. Temporal Cohesion z Def. ? ymodule performs series of actions related in time z Initialization example open old db, new db, transaction db, print db, initialize sales district table, read first transaction record, read first old db record z Why is this bad? yactions weakly related to one another, but strongly related to actions in other modules ycode spread out -> not maintainable or reusable z Initialization example fix ydefine these intializers in the proper modules & then have an initialization module call each 2/14/2001 11

4. Procedural Cohesion z Def. ? ymodule performs series of actions related by procedure to be followed by product z Example yupdate part number and update repair record in master db z Why is this bad? yactions are still weakly related to one another ynot reusable z Solution ybreak up! 2/14/2001 12

5. Communicational Cohesion z Def. ymodule performs series of actions related by procedure to be followed by product, but in addition all the actions operate on same data z Example 1 update record in db and write it to audit trail z Example 2 calculate new coordinates and send them to window z Why is this bad? ystill leads to less reusability -> break it up 2/14/2001 13

7. Informational Cohesion z Def. ymodule performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure This is an ADT! 2/14/2001 14

7. Functional Cohesion z Def. ymodule performs exactly one action z Examples y get temperature of furnace y compute orbital of electron y calculate sales commission z Why is this good? ymore reusable ycorrective maintenance easier xfault isolation xreduced regression faults yeasier to extend product 2/14/2001 15

Coupling ? z. Degree of interaction between two modules z. Five levels of coupling y 5. Data y 4. Stamp y 3. Control y 2. Common y 1. Content 2/14/2001 (best) (worst) 16

1. Content Coupling z Def. yone module directly references contents of the other z Example ymodule a modifies statements of module b ymodule a refers to local data of module b in terms of some numerical displacement within b ymodule a branches into local label of module b z Why is this bad? yalmost any change to b requires changes to a 2/14/2001 17

2. Common Coupling z Def. ytwo modules have write access to the same global data z Example ytwo modules have access to same database, and can both read and write same record yuse of Java public statement while (global variable == 0) if (argument xyz > 25) z Why is this bad? module 3 (); yresulting code is unreadable else xmodules can have side-effects module 4 (); xmust read entire module to understand ydifficult to reuse ymodule exposed to more data than necessary 2/14/2001 18

3. Control Coupling z Def. yone module passes an element of control to the other z Example ycontrol-switch passed as an argument z Why is this bad? ymodules are not independent xmodule b must know the internal structure of module a xaffects reusability 2/14/2001 19

4. Stamp Coupling z Def. ydata structure is passed as parameter, but called module operates on only some of individual components z Example calculate withholding (employee record) z Why is this bad? yaffects understanding xnot clear, without reading entire module, which fields of record are accessed or changed yunlikely to be reusable xother products have to use the same higher level data structures ypasses more data than necessary 2/14/2001 xe. g. , uncontrolled data access can lead to computer crime 20

5. Data Coupling z Def. yevery argument is either a simple argument or a data structure in which all elements are used by the called module z Example display time of arrival (flight number) get job with highest priority (job queue) z Slippery slope between stamp & data (see queue) z Why is this good? ymaintenance is easier ygood design has high cohesion & weak coupling 2/14/2001 21

Modules to Objects 2/14/2001 Objects with high cohesion and low coupling Ý Objects Ý Information hiding Ý Abstract data types Ý Data encapsulation Ý Modules with high cohesion and low coupling Ý Modules 22

Data Encapsulation ? z Def. y data structure together with actions to be performed on that structure z Bad job queue example y define job queue w/ 1 op together in module (repeat for init, add, etc. ) y low cohesion z Better job queue example y put all job queue ops together w/ 1 definition of job queue in 1 module y informational cohesion & data encapsulation z Abstraction or stepwise refinement y easier development & maintenance y helps us cope w/ change 2/14/2001 23

Abstract Data Types z Def. ydata type together with actions to be performed on instantiations of that data type ysubtle difference with encapsulation z Example class Job. Queue { public int queue. Length; // length of job queue public int queue = new int[25]; // up to 25 jobs // methods public void initialize. Job. Queue (){ // body of method } public void add. Job. To. Queue (int job. Number){ // body of method } } // Job. Queue 2/14/2001 24

Information Hiding z Really “details hiding” yhiding implementation details, not information z Example ydesign modules so that items likely to change are hidden xfuture change localized xchange cannot affect other modules ydata abstraction xdesigner thinks at level of ADT 2/14/2001 25

Information hiding z Example class Job. Queue { private int queue. Length; // length of job queue private int queue = new int[25]; // up to 25 jobs // methods public void initialize. Job. Queue (){ // body of method } public void add. Job. To. Queue (int job. Number){ // body of method } } // Job. Queue y. Now queue and queue. Length are inaccessible 2/14/2001 26

Objects z Def. y class – abstract data type which supports inheritance y objects are instantiations of classes z Inheritance y new data types defined as extensions to previously defined types xdon’t have to define from scratch -> provides more data abstraction y Example 2/14/2001 Define human. Being to be a class A human. Being has attributes, such as age, height, gender Assign values to attributes when describing object Define parent to be a subclass of human. Being A parent has all attributes of human. Being, plus attributes of his/her own (name of oldest child, number of children) 27 A parent inherits all attributes of human. Being

Inheritance (UML) Human. Being (base class) UML notation: boxes represent classes open triangle represent inheritance inherits from(“is. A ”) Parent derived part 2/14/2001 (derived class) incremental part 28

Inheritance (Java) class Human. Being { private int age; private float height; public // declarations of operations on Human. Being } // class Human. Being class Parent extends Human. Being { private String name. Of. Oldest. Child; private int number. Of. Children; public // declarations of operations on Parent } // class Parent 2/14/2001 29

Inheritance z Method Foo (b : Base) can be applied to objects of any subclass of Base 2/14/2001 30

Aggregation (UML) Personal. Computer UML notation: diamond (1 or more) no diamond (1) CPU Monitor 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 31

Polymorphism & Dynamic Binding z. Classical paradigm function draw_rectangle function draw_circle function draw_line ymust explicitly invoke the correct version 2/14/2001 32

Polymorphism & Dynamic Binding z Object-oriented paradigm Graph. Obj. Class method draw Rect. Class Implementation of method draw for a rectangle Circle. Class Implementation of method draw for a circle Line. Class Implementation of method draw for a line y all that is needed is my. Graph. Obj. draw() z Dynamic binding y correct method invoked at run-time (dynamically) z Polymorphic y method draw can be applied to objects of different classes 2/14/2001 33

Polymorphism & Dynamic Binding z Advantages ? ycan build for the future xeasy to add a new shape w/o changing previous code • don’t ever want to mess w/ code that works yeasy to iterate over similar but distinct objects xdraw all Graph. Objs z Disadvantages ? yperformance (have to look things up at run time) yhave to design classes better xhave to understand how it will be extended over time yharder to understand the code 2/14/2001 xmust understand multiple possibilities for specific method 34

Advantages of Objects z. Same as abstract data types yinformation hiding ydata abstraction yprocedural abstraction xstart code design at high level & continue down levels until using primitives z Inheritance provides further data abstraction yeasier and less error-prone product development yeasier maintenance 2/14/2001 35

Summary z. Good modules have strong cohesion and weak coupling z. Data encapsulation, ADTs, information hiding, & objects ease maintenance & reuse z. Polymorphism has advantages & disadvantages 2/14/2001 36

Next Time z. Questions? z. Friday’s lecture on Requirements yread Chapter 9 from Schach 2/14/2001 37