Program Slice Program slice was a concept first discussed by Mark Weiser in the early 1980’s –He especially noticed that when people debug, they trace a specific of interest variable backwards in the program to the point where the variable is defined (assigned a value) –This traced path is a condensed path of execution that allows us to check processing of that variable of interest.

A simple example of Program Slice Pseudo code example 1. int limit = 10; 2. int y = 0; 3. int x = 0; 4. for (int i = 0; i < limit ; i++) 5. {x = x + i; 6. y = y + i 2 ; } 7. print (“ x = “, x, “y =“, y); - Consider that our variable of interest is y at statement 7. - We would pick up statements: (because the loop influences statement 6) 2 1 (because limit influences statement 4) - Statements form a Program Slice - Note that: in executing just this slice, the value of y is the same at statement 7 as executing the whole example

Program Slice and Cohesion Besides, debugging, the notion of program slice also allow people to reduce the program to its “essentials” by looking at “key” variables. –e.g. the major output may be a key variable. This view allowed the possibility of looking at program cohesion through a set of program cohesion metrics.

Using Program and Data Slices to Measure Program Cohesion Bieman and Ott (early 1990’s) introduced a measure of program cohesion using the following concepts from program and data slices: –A data token is any variable or constant in the program –A slice within a program is the collection of all the statements that can affect the value of some specific variable of interest. –A data slice is the collection of all the data tokens in the slice that will affect the value of a specific variable of interest. –Glue tokens are the data tokens in the program that lie in more than one data slice. –Super glue tokens are the data tokens in the program that lie in every data slice of the program Measure Program Cohesion through 2 metrics: - weak functional cohesion = (# of glue tokens) / (total # of data tokens) - strong functional cohesion = (#of super glue tokens) / (total # of data tokens)

A Pseudo-Code Example of Functional Cohesion Measure Finding the maximum and the minimum values procedure: MinMax ( z, n) Integer end, min, max, i ; end = n ; max = z[0] ; min = z[0] ; For ( i = 0, i = < end, i++ ) { if z[ i ] > max then max = z[ i ]; if z[ i ] < min then min = z[ i ]; } return max, min; Data Tokens: z1 n1 end1 min1 max1 i1 end2 n2 max2 z2 01 min2 z3 02 i2 03 i3 end3 i4 z4 i5 max3 max4 z5 i6 z6 i7 min3 min4 z7 i8 max5 min5 (33) Slice max: z1 n1 end1 max1 i1 end2 n2 max2 z2 01 i2 03 i3 end3 i4 z4 i5 max3 max4 z5 i6 max5 (22) Slice min: z1 n1 end1 min1 i1 end2 n2 min2 z3 02 i2 03 i3 end3 i4 z6 i7 min3 min4 z7 i8 min5 (22) Glue Tokens: z1 n1 end1 i1 end2 n2 i2 03 i3 end3 i4 (11) Super Glue: z1 n1 end1 i1 end2 n2 i2 03 i3 end3 i4 (11)

Example of pseudo-code Cohesion Metrics For the example of finding min and max, the glue tokens are the same as the super glue tokens. –Super glue tokens = 11 –Glue tokens = 11 The data slice for min and data slice for max turns out to be the same number, 22 The total number of data tokens is 33 The cohesion metrics for the example of min-max are: weak functional cohesion = 11 / 33 = 1/3 strong functional cohesion = 11 / 33 = 1/3 But, if we had only computed one function (e.g. only max), then : weak functional cohesion = 22 / 22 = 1 strong functional cohesion = 22/ 22 = 1 Note The change

Now look at the cohesion of the two earlier program samples - Are they “equally” cohesive based on Bieman and Ott metrics? - Perhaps it is coupling that we need to worry about ? - What type of coupling do you think this is?

Code Sample From Page Of Text For Tax problem tax = 0 if (taxable_income == 0) go to EXIT; if (taxable_income > 10000) tax = tax ; else { tax = tax +.10 * taxable_income; goto EXIT; } if (taxable_income > 20000) tax = tax ; else{ tax = tax +.12 * (taxable_income – 10000); goto EXIT; } if (taxable_income > 30000) tax = tax +1500; else{ tax = tax +.15 * (taxable_income – 20000); goto EXIT; } if (taxable_income < 40000) { tax = tax +.18 * (taxable_income – 30000); goto EXIT; } else tax = tax * (taxable_income – 40000); EXIT: ; 10% tax for the first $10,000 or less 12% tax for $10,001 to $20,000 15% tax for $20,001 to $30,000 18% tax for $30,001 to $39,999 20% tax for above $40,000 is this correct? See requirements

In Control Flow form Tax = 0.0 Inc= 0? Inc > 10k Tax = Tax + 1,000 Inc > 20k Tax = Tax + 1,200 Inc > 30k Tax = Tax + 1,500 Inc < 40k Tax = [Tax +.18(Inc -30k)] Tax = [Tax +1,800+.2(Inc -40k)] Tax = [Tax +.15(Inc -20k)] Tax = [Tax +.12(Inc -10k)] Tax = [Tax +.1(Inc ) ] Exit Cyclomatic complexity # = 5 +1 = 6 yes no yesno yesno yesno

Code sample from page 344 of text for same problem for (int i=2 ; level = 1; i <= 5; i++ ) { If (taxable_income > bracket [ i ] ) level = level + 1; else {tax = base [ level ] + percent [ level ] * (taxable_income – bracket [level] ) ; i = 6; } Tax table showing the bracket, base, and the percent columns bracket base percent Code structure is different because the algorithm is dependent on a table of Information, which may be implemented with 3 arrays e.g. float [ ] percent = {.10,.12,.15,.18,.20} and assume array indexing start with 1

In Control Flow form i=2 L =1 i = 6 L = L + 1 Tax = base[L] + ( percent[L] * (inc- bracket[L] )) i <=5 Exit Inc > bracket[i] i = i + 1 No Yes No Cyclomatic complexity # = = 3 With 3 defined arrays of: - base {0,10000, ---, 40,000} - bracket {0, 1000, - - -, 5500} - percent {.1,.12, - - -,.2}

Reuse After reviewing these two code examples, what do you think cohesion and coupling have to do with reuse? Did you not hear that highly cohesive and loosely coupled code is good for re-use? Which one do you think is more re-usable? If you are the reuse producer, would you do anything differently?