CSE Colloquium -2007

Download Report

Transcript CSE Colloquium -2007

CSE Colloquium
Frank Tsui
Software Engineering
4 Topics
1.
2.
3.
4.
Software Cohesion and Coupling
Software Style and Metrics
Software Configuration Management
Software Process and Communications
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
High Cohesion and Low Coupling
Research:
philosophical
& conceptual
numerically
measurable
predictor
•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
Example of a “simple” Class Cohesion
Metric
1
M1
Let:
2
3
4
Instance variables in a class
5
M2
M3
methods in a class
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.
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.
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 );
}
Consider two more sample code for answering
the “sum of the first n integers”
Using for Loop
Using Recursion
Sum ( n )
sum = 0 ;
for ( int z = 1; z <= n ; z++ )
sum = sum + z;
Sum ( n )
if ( n ==1 ) sum = 1;
else {
sum = n + sum ( n – 1 );
}
return sum ;
What do you think about these two in terms of
- cohesion and coupling ?
- control structure?
- algorithm ?
- data ?
- and STYLE ?
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
tax = 0
if (taxable_income == 0) go to EXIT;
if (taxable_income > 10000) tax = tax + 1000;
else {
10% tax for the first $10,000 or less
tax = tax + .10 * taxable_income;
goto EXIT;
}
if (taxable_income > 20000) tax = tax + 1200;
12% tax for $10,001 to $20,000
else{
tax = tax + .12 * (taxable_income – 10000);
goto EXIT;
}
if (taxable_income > 30000) tax = tax +1500;
15% tax for $20,001 to $30,000
else{
tax = tax + .15 * (taxable_income – 20000);
goto EXIT;
}
if (taxable_income ≤ 40000)
{ tax = tax + .18 * (taxable_income – 30000);
18% tax for $30,001 to $39,999
goto EXIT;
}
else
tax = tax +1800 + .20 * (taxable_income – 40000);
20% tax for above $40,000
EXIT: ;
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
0
10000
20000
30000
40000
0
1000
2200
3700
5500
percent
.10
.12
.15
.18
.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
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” ---
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 ?
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?
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.
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.”
3. Software Configuration Management
• Software Configuration Management is the
discipline of controlling the evolution of
software.
Has 2 main components:
1.
Identifying & Defining the artifacts
that need to be controlled
2.
Mechanism to control the artifacts
Configuration Management Research
Understanding and
Controlling “Relationships”
Among Artifacts
Focused on the “Control”
Mechanism
- versioning
- conflicts
- security
-access speed
-etc.
Requirements
3
Design
Code
general
general
general
general
general
1
general
2
French
4
general
Test Cases
general
general
French
French
French
French
Japanese
Japanese
Japanese
Japanese
Brazilian
Brazilian
Brazilian
Brazilian
Intra & Inter Relationships
Requirements
Elements
Requirements
Elements
Design
Elements
Code Logic
UI Screens
X
X
X
X
X
X
X
X
X
X
Design
Elements
X
Code Logic
X
X
UI Screens
X
X
X
DB tables
X
X
Initialization
data
X
X
Test cases
X
X
DB tables
Initialization
data
Test
cases
X
X
X
X
X
X
X
X
Inter-Artifacts Relationship Matrix Example
4. Software Process and Communications
• It is conjectured that communications affects the
success of software projects , especially with
“Global Software Development”
Current
Research
Communications:
• types
• structure
• amount
How to
Relate ?
Future
Research
Predict ?
Software Project:
• good morale
• good product
• meets schedule
• meets cost
100
95
Success
90
85
80
75
1k
2k
3k
4k
5k
6k
7k
8k
Communications in person-minutes
Project Teams by Success and Amount of Communications
39.7
40
30
% of
Total
Comm.
26.5
23.1
20
10.7
10
Req.
Des/code
Test
Proj. Mgmt
Distribution of Communications
45
40
35
30
% of
Total 25
Comm.
B
9 teams
overall
20
15
10
A
C
5
Req.
Des/code
Test
Proj. Mgmt
Distribution of Communications by Groups