Frank Tsui Software Engineering

Slides:



Advertisements
Similar presentations
Pfleeger and Atlee, Software Engineering: Theory and Practice CS499 Chapter 7 Writing the Programs Shari L. Pfleeger Joann M. Atlee 4 th Edition.
Advertisements

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.
Chapter 13 Recursion. Topics Simple Recursion Recursion with a Return Value Recursion with Two Base Cases Binary Search Revisited Animation Using Recursion.
COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler
Coupling and Cohesion Schach, S, R. Object-Oriented and Classical Software Engineering. McGraw-Hill, 2002.
Ms N Nashandi Dr SH Nggada Week 08 – Recursion. Outline We shall be covering the following What is a recursion? Iteration versus Recursion. Recursion.
Arrays Chapter 7.
PROGRAMMING: What’s It All About?
CSC 421: Algorithm Design & Analysis
Introduction to Algorithms
Why Metrics in Software Testing?
Software Testing.
CompSci 280 S Introduction to Software Development
Configuration Management, Integration, and Builds
CompSci 280 S Introduction to Software Development
Topic: Recursion – Part 2
Software Metrics 1.
REPETITION CONTROL STRUCTURE
OBJECT ORIENTED PROGRAMMING II LECTURE 23 GEORGE KOUTSOGIANNAKIS
Analysis of Algorithms
Data Structure and Algorithms
CS1371 Introduction to Computing for Engineers
Numeric Arrays Numeric Arrays Chapter 4.
Algorithm Analysis CSE 2011 Winter September 2018.
Recursion.
JavaScript: Functions.
CSC 421: Algorithm Design & Analysis
Version 3 April 21, 2006 Takahiro Yamada (JAXA/ISAS)
CS 213: Data Structures and Algorithms
Recursive Thinking Chapter 9 introduces the technique of recursive programming. As you have seen, recursive programming involves spotting smaller occurrences.
Data Structures Recursion CIS265/506: Chapter 06 - Recursion.
Hash Functions/Review
Recursive Thinking Chapter 9 introduces the technique of recursive programming. As you have seen, recursive programming involves spotting smaller occurrences.
Recursion 12-Nov-18.
One-Dimensional Array Introduction Lesson xx
Chapter 4 Functions Objectives
Recursion UW CSE 160 Winter 2017
Software Engineering Lecture #8.
Writing Methods AP Computer Science A.
Recursion UW CSE 160 Spring 2018
IAS 0600 Digital Systems Design
EKT150 : Computer Programming
Recursion 2-Dec-18.
Recursion 2-Dec-18.
Java Programming Loops
Lecture 18 Arrays and Pointer Arithmetic
Software Architecture
FP Foundations, Scheme In Text: Chapter 14.
This Lecture Substitution model
CS 201 Fundamental Structures of Computer Science
Recursion 29-Dec-18.
Chapter 7 Writing the Programs Shari L. Pfleeger Joann M. Atlee 4th Edition.
Parameter Passing in Java
Software Design Lecture : 9.
IAS 0600 Digital Systems Design
Multidimensional Arrays
Recursion UW CSE 160 Winter 2016
Introduction to Algorithms
Overloading functions
Dr Tripty Singh Arrays.
This Lecture Substitution model
Data Structures & Algorithms
Recursion 23-Apr-19.
ECE 103 Engineering Programming Chapter 18 Iteration
Design Yaodong Bi.
This Lecture Substitution model
Chapter 11: Configuration Management, Integration, and Builds
Chapter 1: Creating a Program.
Dictionaries and Hash Tables
Lecture 6 - Recursion.
Presentation transcript:

Frank Tsui Software Engineering CSE Colloquium Frank Tsui Software Engineering

4 Topics 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: 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

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.

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 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 ?

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 { tax = tax + .10 * taxable_income; goto EXIT; } if (taxable_income > 20000) tax = tax + 1200; else{ tax = tax + .12 * (taxable_income – 10000); if (taxable_income > 30000) tax = tax +1500; tax = tax + .15 * (taxable_income – 20000); if (taxable_income ≤ 40000) { tax = tax + .18 * (taxable_income – 30000); 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

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 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

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?

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.

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: 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. Moving towards

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

Inter-Artifacts Relationship Matrix Example Requirements Elements Design Code Logic UI Screens DB tables Initialization data Test cases 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 How to Relate ? Software Project: good morale good product meets schedule meets cost Communications: types structure amount Future Research Predict ?

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

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

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