CSE Colloquium

1. CSE Colloquium Frank Tsui Software Engineering

2. 4 Topics • Software Cohesion and Coupling • Software Style and Metrics • Software Configuration Management • Software Process and Communications

3. 1. Software Cohesion and Coupling • Cohesion and Coupling are attributes of software • Conjectured and shown to be associated with: • software quality and • maintainability • Cohesion addresses the “relatedness” within a module or Class. • Coupling addresses the “relatedness” among modules or Classes

4. High Cohesion and Low Coupling Research: predictor numerically measurable philosophical & conceptual • If we consider a software system, the entities • in the system (e.g. for a Class, methods and • attributes form the entities of a Class) are evaluated • syntactically. • The number of attributes shared or the number of • methods evoked with in a class formulate the • basis for the cohesion metric of a Class. • The number of attributes “passed” or the number • of evocation of methods from one class to another • class formulate the basis for Class coupling metric

5. Example of a “simple” Class Cohesion Metric Instance variables in a class 5 1 2 3 4 M1 M2 M3 methods in a class Let: ivj = instance variable j N = Σ ivj sivk = shared instance variable k M = Σ sivk then Class Cohesion = M/N Many variants of this simple Class Cohesion metrics exist today.

6. 2. Software Style • Research: • Is “Style” a software attribute ? • Style is still a philosophical and conceptual discussion • There is no clear concept or accepted definition • for “Style” of software. • It exists in other disciplines: • Music • Architecture • Clothes fashion • Etc.

7. Example from Kernighan and Plaugeron identity matrix for (int i = 1; i ≤ n ; i ++ ) { { for ( int j = 1; j ≤ n; j++ ) M ( i,j ) = 0; } M( i,i ) = 1 ; } for (int i = 1; i ≤ n ; i ++ ) { for ( int j = 1; j ≤ n; j++ ) M ( i,j ) = ( i/j ) * ( j/I ); }

8. Consider two more sample code for answering the “sum of the first n integers” Using Recursion Sum ( n ) if ( n ==1 ) sum = 1; else { sum = n + sum ( n – 1 ); } return sum ; Using for Loop Sum ( n ) sum = 0 ; for ( int z = 1; z <= n ; z++ ) sum = sum + z; What do you think about these two in terms of - cohesion and coupling ? - control structure? - algorithm ? - data ? - and STYLE ?

9. Example from Pfleeger and Atlee on Tax Problem Develop a software program that will compute tax according to the following set of rules: 0 tax if income is zero . 10% tax for the first $10,000 or less 12% tax for next $10,000 above $10,000 OR ($10,001 to $20,000) 15% tax for next $10,000 above $20,000 OR ($20,001 to $30,000) 18% tax for next $10,000 above $30,000 OR ($30,001 to $40,000) 20% tax for above $40,000

10. tax = 0 if (taxable_income == 0) go to EXIT; if (taxable_income > 10000) tax = tax + 1000; else { tax = tax + .10 * taxable_income; goto EXIT; } if (taxable_income > 20000) tax = tax + 1200; 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 +1800 + .20 * (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

11. 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 • 0 0 .10 • 1000 .12 • 2200 .15 • 3700 .18 • 40000 5500 .20 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

12. Computational “form” vs “role” • Consider someone asking you to add the first two integers: You might say y = 1 + 2 • Suppose we say ‘add the first 5 integers” ; you may still do the following y = 1 + 2 + 3 + 4 + 5 • Suppose we keep this up and ask you to add the first 50 integers! y = 1+ 2+ ----------------------+ 49 + 50 • How about first 500 integers? ---- you may pause and try the following: • set iterator = 1 • compute set sum = 0 • sum <= sum + iterator • If iterator ≤ 500, compute iterator <= ( iterator + 1) and repeat the above statement; • otherwise, stop The “role” did not change ---- at some point we changed the “form” ---

13. Inspirations of Previous “form” change ? • Rephrasing of 18th century English poet, William Blake’s stanza: • Can you see the world in a grain of sand? • Can you imagine heaven in a wild flower? • Can you grasp infinity in the palm of your hand? • Can you experience eternity in an hour? Are these different forms of the same thing? Expressing infinite computation requires a “form” change. There may be many forms ---- is style defined by form ?

14. Application to general “Iterator” pattern • The general iterator function (role) is to provide: • First ( ) • Next ( ) • Done ( ) • Easy and similar to the previous example of adding integers • if the data type is integers. • - We also know the algorithms for data expressed with tree structure, by • specifying the traversal preference. • What about a non-structured set? { A, T, C, G, AAT, AATTCG } – do we • have to have a mapping to (some ordinal scale) ? If so, does that • mapping dictate the “form” of the iterator algorithm and thus the style?

15. Towards Polymorphism • ADD (max, data: dtype) • This ADD function is parametric polymorphic in two ways: • Max parameter gives us the capability of ADD to perform the sum of any arbitrary number of items, not just the first 25 items or first 600 items, etc. • Data parameter with potentially different data typing allows us to add different types of items. Expanding the “role” in two dimensionalities, required us to consider expanding the “form” differently ---- via parameters.

16. Related to “Polymorphism?” • Studying the various forms of design/coding leads us to some specific areas: • Varieties of polymorphism • Are the varieties of polymorphism a matter of: • “form” or • “role” • Would the number and type of “forms” and “roles” be a good starting point for the metric of “style?” ------ for programs since all programs range from monomorphism to some degree of polymorphism. The Component Based Design advocates will also find these concepts closely related to “interfaces” and “services.”

17. 3. Software Configuration Management • Software Configuration Management is the discipline of controlling the evolution of software. • Has 2 main components: • Identifying & Defining the artifacts • that need to be controlled • 2. Mechanism to control the artifacts

18. Configuration Management Research Understanding and Controlling “Relationships” Among Artifacts Focused on the “Control” Mechanism - versioning - conflicts - security -access speed -etc. Moving towards

19. Intra & Inter Relationships Requirements Design Code Test Cases general 3 general general general general 1 general general general general French 2 4 French French French French Japanese Japanese Japanese Japanese Brazilian Brazilian Brazilian Brazilian

20. Inter-Artifacts Relationship Matrix Example

21. 4. Software Process and Communications • It is conjectured that communications affects the success of software projects , especially with “Global Software Development” Current Research How to Relate ? • Software Project: • good morale • good product • meets schedule • meets cost • Communications: • types • structure • amount Future Research Predict ?

22. Project Teams by Success and Amount of Communications 100 95 Success 90 85 80 75 1 k 2 k 3 k 4 k 5 k 6 k 7 k 8 k Communications in person-minutes

23. Distribution of Communications 39.7 40 30 % of Total Comm. 26.5 23.1 20 10.7 10 Req. Des/code Test Proj. Mgmt

24. Distribution of Communications by Groups 45 40 35 B 30 9 teams overall % of Total Comm. 25 20 15 A 10 C 5 Req. Des/code Test Proj. Mgmt