Presentation is loading. Please wait.

Presentation is loading. Please wait.

Frank Tsui Software Engineering

Similar presentations


Presentation on theme: "Frank Tsui Software Engineering"— Presentation transcript:

1 Frank Tsui Software Engineering
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
5 Instance variables in a class 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 Plauger on 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 ; else { tax = tax * taxable_income; goto EXIT; } if (taxable_income > 20000) tax = tax ; else{ tax = tax * (taxable_income – 10000); if (taxable_income > 30000) tax = tax +1500; tax = tax * (taxable_income – 20000); if (taxable_income ≤ 40000) { tax = tax * (taxable_income – 30000); 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

11 Code structure is different because the algorithm is
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

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 = Suppose we keep this up and ask you to add the first 50 integers! y = 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 This ADD function is parametric polymorphic in two ways:
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 Intra & Inter Relationships

20 Inter-Artifacts Relationship Matrix Example
Requirements Elements Design Code Logic UI Screens DB tables Initialization data Test cases X 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 Project Teams by Success and Amount of Communications

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

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 Distribution of Communications by Groups


Download ppt "Frank Tsui Software Engineering"

Similar presentations


Ads by Google