ics 52: introduction to software engineeringtaylor/ics_52_wq04/ics52wq04-07.pdf · ics 52:...
TRANSCRIPT
![Page 1: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/1.jpg)
University of California, Irvine 1
ICS 52: Introduction to SoftwareEngineeringWinter Quarter 2004
Professor Richard N. TaylorLecture Notes
Week 7 Integration Testing and Implementation Issues
http://www.ics.uci.edu/~taylor/ICS_52_WQ04/syllabus.htmlCopyright 2004, Richard N. Taylor. Duplication of course
material for any commercial purpose without written permission is prohibited.
![Page 2: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/2.jpg)
University of California, Irvine 2
V-Model of Development and Testing
Develop Acceptance TestsAcceptance Test Review
Requirements ReviewDevelop Requirements Execute System Tests
Develop Integration TestsIntegration Tests Review
Design ReviewDesign Execute Integration Tests
Develop Unit TestsUnit Tests Review
Code ReviewCode Execute Unit Tests
![Page 3: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/3.jpg)
University of California, Irvine 3
Integration Test Plan Ensures module implementations adhere to assumptions and interfaces as
designed– Uncovering interactions that highlight problems with assumptions is
difficult Approach
– Combine more and more modules– Use USES hierarchy
» Work up from level zero Use test harnesses to test each group of modules
» Work down from highest number Use stubs as mockups to test each group of modules
Can be done during implementation effort
![Page 4: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/4.jpg)
University of California, Irvine 4
Integration Test Example
Provided Interface
Main componentRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
SubcomponentRequired Interface
![Page 5: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/5.jpg)
University of California, Irvine 5
Test Harnesses
Provided Interface
SubcomponentRequired Interface
Provided Interface
Test HarnessRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
Test HarnessRequired Interface
![Page 6: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/6.jpg)
University of California, Irvine 6
Test Harnesses
Provided Interface
Test HarnessRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
SubcomponentRequired Interface
![Page 7: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/7.jpg)
University of California, Irvine 7
Stubs
Provided Interface
Main componentRequired Interface
Provided Interface
StubRequired Interface
Provided Interface
StubRequired Interface
Provided Interface
StubRequired Interface
![Page 8: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/8.jpg)
University of California, Irvine 8
Stubs
Provided Interface
Main componentRequired Interface
Provided Interface
StubRequired Interface
Provided Interface
StubRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
StubRequired Interface
Provided Interface
StubRequired Interface
![Page 9: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/9.jpg)
University of California, Irvine 9
Stubs
Provided Interface
Main componentRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
StubRequired Interface
Provided Interface
SubcomponentRequired Interface
Provided Interface
StubRequired Interface
Provided Interface
StubRequired Interface
![Page 10: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/10.jpg)
University of California, Irvine 10
ICS 52 Life CycleRequirements
phaseVerify
DesignphaseVerify
ImplementationphaseTest
TestingphaseVerify
![Page 11: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/11.jpg)
University of California, Irvine 11
Design/Implementation Interaction
Design(previous lectures)
Implementation(this lecture)
![Page 12: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/12.jpg)
University of California, Irvine 12
A Good Design… …is half the implementation effort!
– Rigor ensures all requirements are addressed– Separation of concerns
» Modularity allows work in isolation because components are independent ofeach other
» Abstraction allows work in isolation because interfaces guarantee thatcomponents will work together
– Anticipation of change allows changes to be absorbed seamlessly– Generality allows components to be reused throughout the system– Incrementality allows the software to be developed with intermediate
working results
![Page 13: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/13.jpg)
University of California, Irvine 13
A Bad Design… …will never be implemented!
– Lack of rigor leads to missing functionality– Separation of concerns
» Lack of modularity leads to conflicts among developers» Lack of abstraction leads to massive integration problems (and headaches)
– Lack of anticipation of change leads to redesigns and reimplementations– Lack of generality leads to “code bloat”– Lack of incrementality leads to a big-bang approach that is likely to
“bomb”
![Page 14: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/14.jpg)
University of California, Irvine 14
From Design to Implementationo Choose a suitable implementation languageo Establish coding conventionso Divide work efforto Implement
o Codeo Unit testso Code reviewso Inspections
o Perform integration tests
![Page 15: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/15.jpg)
University of California, Irvine 15
Choose a Suitable Language 4th Generation language
– Databases– Visual Basic– Forms
“Real” programming language– Java + Class Libraries– C++/C + STL (Standard Template Library)– Cobol– Fortran
Assembly language– Machine specific
![Page 16: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/16.jpg)
University of California, Irvine 16
Choose a Suitable Language Maintain the design “picture”
– Mapping of design elements onto implementation– Module inside versus outside
» Does the language enforce a boundary?» Interfaces!
– Explicit representation of uses relationship» Just function calls?
Error handling– Return values– Exceptions
![Page 17: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/17.jpg)
University of California, Irvine 17
Establish Coding Conventions Naming
– Avoid confusing characters» 1, l, L, o, O, 0, S, 5, G, 6
– Avoid misleading names– Avoid names with similar meaning– Use capitalization wisely -- and consistently
Code layout– White space / blank lines– Grouping– Alignment– Indentation– Parentheses
![Page 18: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/18.jpg)
University of California, Irvine 18
Divide Work Effort Assign different modules to different developers
– Assignments can be incremental– Assignments change
» Illness» New employees» Employees who quit» Schedule adjustments» Star programmers
Interfaces are tremendously important– “Contracts” among modules
![Page 19: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/19.jpg)
University of California, Irvine 19
Coding FIRST MAKE IT WORK CLEANLY FIRST MAKE IT WORK CLEANLY FIRST MAKE IT WORK CLEANLY FIRST MAKE IT WORK CLEANLY FIRST MAKE IT WORK CLEANLY FIRST MAKE IT WORK CLEANLY FIRST MAKE IT WORK CLEANLY FIRST MAKE IT WORK CLEANLY FIRST MAKE IT WORK CLEANLY
![Page 20: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/20.jpg)
University of California, Irvine 20
Code Optimizations Only make optimizations to a cleanly working module if absolutely necessary
– Performance– Memory usage
Isolate these optimizations Document these optimizations
Empirical evidence has proven that these optimizationsare rarely needed and that if they are needed, they are
only needed in a few critical places
![Page 21: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/21.jpg)
University of California, Irvine 21
Defensive Programming Make your code robust and reliable
– Use assertions– Use tracing– Handle, do not ignore, exceptions
» Contain the damage caused» Garbage in does not mean garbage out
– Anticipate changes– Check return values
Plan to be able to remove debugging aids in the final, deliverable version
Do not sacrifice any of these when facing a deadline
![Page 22: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/22.jpg)
University of California, Irvine 22
Comments Self documenting code does not exist!
– Meaningful variable names, crisp code layout, and small and simplemodules all help…
– …but they are not enough Every module needs a description of its purpose Every function needs a description of its purpose, input and output
parameters, return values, and exceptions Every piece of code that remotely may need explanation should be explained
![Page 23: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/23.jpg)
University of California, Irvine 23
Unit Tests Developer tests the code just produced
– Needs to ensure that the code functions properly before releasing it to theother developers
Benefits– Knows the code best– Has easy access to the code
Drawbacks– Bias
» “I trust my code”» “I always write correct code”
– Blind spots
![Page 24: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/24.jpg)
University of California, Irvine 24
Code Reviews (“Walk-throughs”) Developer presents the code to a small group of colleagues
– Developer describes software– Developer describes how it works
» “Walks through the code”– Free-form commentary/questioning by colleagues
Benefits– Many eyes, many minds– Effective
Drawbacks– Can lead to problems between developer and colleagues
![Page 25: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/25.jpg)
University of California, Irvine 25
Inspections Developer presents the code to a small group of colleagues
– Colleagues look for predefined types of errors» Checklists
– Colleagues read code beforehand– Moderator leads discussion
Benefits– Avoids personal “attacks”– Effective
Drawbacks– Only verifies code with respect to a predefined list of problem areas
![Page 26: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_WQ04/ICS52WQ04-07.pdf · ICS 52: Introduction to Software Engineering Winter Quarter 2004 Professor Richard N. Taylor Lecture](https://reader031.vdocuments.mx/reader031/viewer/2022022504/5ab7c2837f8b9ac60e8bf7de/html5/thumbnails/26.jpg)
University of California, Irvine 26
Use the Principles Rigor and formality Separation of concerns
– Modularity– Abstraction
Anticipation of change Generality Incrementality