Testing, Module To Object, Reusability

Transcription

1 Testing, Module To Object, Reusability CMPSC 487 Lecture 09 Topics: Schach - Chap 6. Testing Schach - Chap 7. From module to object Schach - Chap 8. Reusability and portability Chap 6. Testing Verification: Validation: V&V denotes testing. The quality of software: the extent to which it meets its specifications. a) Software quality assurance (SQA) group An independent group whose primary responsibility is to ensure that the delivered product is what the client needs and that the product has been built correctly in every way. One aspect of the role of the SQA group is to test that the developers product is correct. Managerial independence between development team and SQA group: development should be under one manager, SQA under a different manager, and neither manager should be able to overrule the other.

2 b) Review non-execution-based testing Review is one of non-execution-based testing method that carefully reading through it. The review task must be assigned to someone other than the original author of the document, It has two types of review: walkthrough, and inspection. Workthrough Walkthroughs have fewer steps and are less formal than inspections. In case of analysis workflow, the team consists of: Process: There are 2 ways of doing workthrough: Participant driven: Document driven: Note: During workthrough, team does not correct faults, but merely records them for later correction. Workthrough leader elicits question and facilitate discussion, and leader should not be responsible evaluating member.

3 Inspection Inspections were first proposed by Fagan (1976) for testing designs and code. An inspection goes far beyond a walkthrough and has five formal steps. 1. Overview: 2. Preparation: 3. Inspection: 4. Rework: 5. Follow-up: In case of design inspection, the team consists of: Inspection uses: Note: Check list of potential faults The record of fault statistics. Discover 70-90% faults before unit testing. Decrease the cost of detecting fault by 85-90%. Testers need not deal with failures. Example of check list: Is each item of the specification document adequately and correctly addressed? For each interface, do the actual and formal arguments correspond? Have error-handling mechanisms been adequately identified? Is the design compatible with the hardware resources or does it require more hardware than actually is available? Is the design compatible with the software resources?

4 Note Comparison workthrough and inspection Strength of review: Weakness: c) Execution-based testing Execution-based testing is a process of inferring certain behavioral properties of a product based, in part, on the results of executing the product in a known environment with selected inputs. (Goodenough, 1979) Three troubling implications: Behavioral properties that should be tested: Utility: the extent to which a user s needs are met when a correct product is used under conditions permitted by its specifications.

5 Reliability: a measure of the frequency and criticality of product failure. robustness: a function of a number of factors, such as: Performance: the extent to which the product meets its constraints with regard to response time or space requirements. Correctness: whether a product satisfies its output specifications, independent of its use of computing resources, when operated under permitted conditions (Goodenough, 1979). Sorting Problem: New compiler: Binary file is 20% smaller 45% faster Error message is much more clear Postdelivery maintenance & update are better than old compiler One problem: if for statement appear in a function, compiler just shows an error message but compiles.

6 Chap 7. From module to object When a large product consists of a single monolithic block of code, maintenance is a nightmare. The solution is to break the product into smaller pieces, called modules. A module is a lexically contiguous sequence of program statements, bounded by boundary elements, having an aggregate identifier. (Yourdon and Constantine, 1979) Case story) Case A Case B Case C Initial product in one chip Same functionality in 3 chips Use same gates in a chip All three designs has the same functionality, but case C has problems: Definition: Module cohesion (or strength): Module coupling (or binding): If software design achieves maximal cohesion and minimal coupling, then

7 a) Cohesion There are 7 levels of cohesions. 1. Coincidental cohesion (Bad) InitializeSumAndOpenFile() 2. Logical cohesion double AlgebraicOperation (int op, double v1, double v2) { switch(op) { case 1: return v1 + 1; case 2: return v1 + v2; case 3: return v1 \ v2; // A/B case 4: return v2 \ v1; // A\B case 5: return sin(v1); case 6: return tan(v1, v2);... }

8 3. Temporal Cohesion InitSalesRegionTable_And_InitMasterFile() QueryInSalesRegionTable_And_RetrieveMasterAccountList() UpdateSalesRegionTable_And_PrintSalesRegionTable() CloseSalesRegionTable_And_CloseMasterFile() 4. Procedural Cohesion ReadPartNumberFromDatabase_And_UpdateRepairRecordOnMaintenanceFile()

9 5. Communication Cohesion updaterecordindatabase_and_writeittotheaudittrail() calculatenewtrajectory_and_sendittotheprinter() Flowchart cohesion (Dan Berry, 1978) 6. Functional Cohesion gettemperatureoffurnace() computeorbitalofelectron() writetoharddrive() calculatesalescommission()

10 7. Informational Cohesion (Good, Ideal) Abstract Data Type Cohesion Example

11 Assign level of cohesion If a function has more than one cohesions, then assign the lowest level. InitializeSumAndOpenFiles CloseFileAndPrintAverageTemperature b) Coupling Coupling is the degree of interaction between two modules. There are 5 levels of couplings. 1. Content Coupling (Bad)

12 2. Common coupling 3. Control coupling Logical cohesion (passing function code) Module A calls another module B, and B returns a with what A should do (such as showing error message ) 4. Stamp coupling

13 5. Data coupling (good, desired goal) DisplayTimeOfArrival (fl ightnumber) ComputeProduct (fi rstnumber, secondnumber, result) DetermineJobWithHighestPriority (jobqueue) Coupling Example

14 Chap 8. Reusability and Portability Portable: Reuse: 2 types of reuse: Opportunistic reuse (accidental reuse): Systematic reuse (deliberate reuse): Impediment to reuse: Connection between cohesion and reuse

15 b) Reuse Design & Implementation Library: Toolkit: Application framework Design Pattern Antipattern Software architecture Why reuse is recommended?