CS 501: Software Engineering

1. CS 501: Software Engineering Lecture 20 Reliability 2

2. Administration Projects Four weeks to the end of the semester. Leave time for system testing and to make small changes discovered when the complete system is assembled. Better to deliver a limited first phase done well than a fuller system that is incomplete, untested, or without documentation.

3. Quiz 3: Sports equipment online A company that makes sports equipment decides to create a system for selling sports equipment online. The company already has a product database with specification, marketing information, and prices of the equipment that it manufactures. To sell equipment online the company will need to create: a customer database, and an ordering system for online customers. The plan is to develop the system in two phases. During Phase 1, simple versions of the customer database and ordering system will be brought into production. In Phase 2, major enhancements will be made to these components.

4. Quiz 3 Q1 (a) For the system architecture of Phase 1: i Draw a UML deployment diagram. DeptServer Product DB PersonalComp Ordering system WebBrowser Customer DB

5. Quiz 3 Q1 Product DB (a) For the system architecture of Phase 1: i Draw a UML interface diagram. Ordering system WebBrowser Customer DB

6. Quiz 3 Q1 (b) For Phase 1: i What architectural style would you use for the customer database? Repository with Storage Access Layer ii Why would you choose this style? It allows the DB to be replaced without changing the applications that use the DB.

7. Quiz 3 Q1 (b) For Phase 1: iii Draw an UML diagram for this architectural style showing its use in this application. Customer DB Input components Storage Access Ordering System optional Data Store

8. Quiz 3 Q2 Carefully design during Phase 1 will help the subsequent development of new components in Phase 2. (a) For the interface between the ordering system and the customer database: i Select a design pattern that will allow a gradual transition from Phase 1 to Phase 2. Bridge design pattern (b) Draw a UML class diagram that shows how this design pattern will be used in Phase 1. If your diagram relies on abstract classes, inheritance, delegation or similar properties be sure that this is clear on your diagram. [See next two slides]

9. Quiz 3 Q2 Abstract class Abstract classes are superclasses which contain abstract methods and are defined such that concrete subclasses extend them by implementing the methods. Before a class derived from an abstract class can become concrete, i.e. a class that can be instantiated, it must implement particular methods for all the abstract methods of its parent classes. The incomplete features of an abstract class are shared by a group of subclasses which add different variations of the missing pieces. Wikipedia 4/2/08

10. Quiz 3 Q2 Ordering System Client OrderingAbstraction DBImplementor RefinedOrderingAbstraction ConcreteDBImplementorA ConcreteDBImplementorB

11. Quiz 3 Q2 (c) How does this design pattern support: i Enhancements to the ordering system in Phase 2? By subclassing OrderingAbstraction ii A possible replacement of the customer database in Phase 2? By allowing several ConcreteBDImplementor classes

12. Static Validation & Verification Carried out throughout the software development process. Validation & verification Requirements specification Program Design REVIEWS

13. Reviews: Design and Code Concept Colleagues review each other's work: can be applied to any stage of software development can be formal or informal Design and code reviews are a fundamental part of good software development

14. Review Team (Full Version) A review is a structured meeting, with the following people Moderator -- ensures that the meeting moves ahead steadily Scribe -- records discussion in a constructive manner Developer -- person(s) whose work is being reviewed Interested parties -- people above and below in the software process Outside experts -- knowledgeable people who are not working on this project Client -- representatives of the client who are knowledgeable about this part of the process

15. Example: Program Design Moderator Scribe Developer -- the design team Interested parties -- people who created the system design and/or requirements specification, and the programmers who will implement the system Outside experts -- knowledgeable people who are not working on this project Client -- only if the client has a strong technical representative In a small team, an individual may have several roles

16. Static and Dynamic Verification Static verification: Techniques of verification that do not include execution of the software. • May be manual or use computer tools. Dynamic verification: • Testing the software with trial data. • Debugging to remove errors.

17. Static Verification: Program Inspections Formal program reviews whose objective is to detect faults • Code may be read or reviewed line by line. • 150 to 250 lines of code in 2 hour meeting. • Use checklist of common errors. • Requires team commitment, e.g., trained leaders So effective that it is claimed that it can replace unit testing

18. Inspection Checklist: Common Errors Data faults: Initialization, constants, array bounds, character strings Control faults: Conditions, loop termination, compound statements, case statements Input/output faults: All inputs used; all outputs assigned a value Interface faults: Parameter numbers, types, and order; structures and shared memory Storage management faults: Modification of links, allocation and de-allocation of memory Exceptions: Possible errors, error handlers

19. Static Analysis Tools Program analyzers scan the source of a program for possible faults and anomalies (e.g., Lint for C programs). • Control flow: loops with multiple exit or entry points • Data use: Undeclared or uninitialized variables, unused variables, multiple assignments, array bounds • Interface faults: Parameter mismatches, non-use of functions results, uncalled procedures • Storage management: Unassigned pointers, pointer arithmetic

20. Static Analysis Tools (continued) Static analysis tools • Cross-reference table: Shows every use of a variable, procedure, object, etc. • Information flow analysis: Identifies input variables on which an output depends. • Path analysis: Identifies all possible paths through the program.

21. Security in the Software Development Process The security goal The security goal is to make sure that the agents (people or external systems) who interact with a computer system, its data, and its resources, are those that the owner of the system would wish to have such interactions. Security considerations need to be part of the entire software development process. They may have a major impact on the architecture chosen. Example. Integration of Internet Explorer into Windows

22. Agents and Components A large system will have many agents and components: • each is potentially unreliable and insecure • components acquired from third parties may have unknown security problems • commercial off-the-shelf (COTS) problem The software development challenge: • develop secure and reliable components • protect whole system from security problems in parts of it

23. Techniques: Barriers Place barriers that separate parts of a complex system: • Isolate components, e.g., do not connect a computer to a network • Firewalls • Require authentication to access certain systems or parts of systems Every barrier imposes restrictions on permitted uses of the system Barriers are most effective when the system can be divided into subsystems with simple boundaries

24. Techniques: Authentication & Authorization Authentication establishes the identity of an agent: • What the agent knows (e.g., password) • What the agent possess (e.g., smart card) • Where does the agent have access to (e.g., crt-alt-del) • What are the physical properties of the agent (e.g., fingerprint) Authorization establishes what an authenticated agent may do: • Access control lists • Group membership

25. User Roles Example: An Access Model for Digital Content Actions Digital material Access Operations Attributes Policies

26. Techniques: Encryption Allows data to be stored and transmitted securely, even when the bits are viewed by unauthorized agents • Private key and public key • Digital signatures Encryption Y X Decryption X Y

27. Security and People People are intrinsically insecure: • Careless (e.g, leave computers logged on, use simple passwords, leave passwords where others can read them) • Dishonest (e.g., stealing from financial systems) • Malicious (e.g., denial of service attack) Many security problems come from inside the organization: • In a large organization, there will be some disgruntled and dishonest employees • Security relies on trusted individuals. What if they are dishonest?

28. Design for Security: People • Make it easy for responsible people to use the system • Make it hard for dishonest or careless people (e.g., password management) • Train people in responsible behavior • Test the security of the system • Do not hide violations

29. Suggested Reading Trust in Cyberspace, Committee on Information Systems Trustworthiness, National Research Council (1999) http://www.nap.edu/readingroom/books/trust/ Fred Schneider, Cornell Computer Science, was the chair of this study.

30. Failures and Faults Failure: Software does not deliver the service expected by the user (e.g., mistake in requirements, confusing user interface) Fault (BUG): Programming or design error whereby the delivered system does not conform to specification (e.g., coding error, interface error)

31. Faults and Failures Actual examples (a) A program dies because the programmer typed: x = 1 instead of x == 1. (b) A mathematical function loops for ever from rounding error. (c) A distributed system hangs because of a concurrency problem. (d) After a network is hit by lightning, it crashes on restart. (e) The head of an organization is paid $5 a month instead of $10,005 because the maximum salary allowed by the program is $10,000. (f) An operating system fails because of a page-boundary error in the firmware.

32. Terminology Fault avoidance Build systems with the objective of creating fault-free (bug-free) software Fault tolerance Build systems that continue to operate when faults (bugs) occur Fault detection (testing and validation) Detect faults (bugs) before the system is put into operation.

33. Fault Avoidance Software development process that aims to develop zero-defect software. • Formal specification • Incremental development with customer input • Constrained programming options • Static verification • Statistical testing It is always better to prevent defects than to remove them later. Example: The four color problem.

34. Defensive Programming Murphy's Law: If anything can go wrong, it will. Defensive Programming: • Redundant code is incorporated to check system state after modifications. • Implicit assumptions are tested explicitly. • Risky programming constructs are avoided.

35. Defensive Programming: Error Avoidance Risky programming constructs • Pointers • Dynamic memory allocation • Floating-point numbers • Parallelism • Recursion • Interrupts All are valuable in certain circumstances, but should be used with discretion

36. Defensive Programming Examples • Use boolean variable notinteger • Test i <= nnot i == n • Assertion checking (e.g., validate parameters) • Build debugging code into program with a switch to display values at interfaces • Error checking codes in data (e.g., checksum or hash)

37. Maintenance Most production programs are maintained by people other than the programmers who originally wrote them. (a) What factors make a program easy for somebody else to maintain? (b) What factors make a program hard for somebody else to maintain?

38. Fault Tolerance General Approach: • Failure detection • Damage assessment • Fault recovery • Fault repair N-version programming -- Execute independent implementation in parallel, compare results, accept the most probable.

39. Fault Tolerance Basic Techniques: • Timers and timeout in networked systems • After error continue with next transaction (e.g., drop packet) • User break options (e.g., force quit, cancel) • Error correcting codes in data • Bad block tables on disk drives • Forward and backward pointers in databases Report all errors for quality control

40. Fault Tolerance Backward Recovery: • Record system state at specific events (checkpoints). After failure, recreate state at last checkpoint. • Backup of files • Combine checkpoints with system log (audit trail of transactions) that allows transactions from last checkpoint to be repeated automatically. • Test the restore software!

41. Software Engineering for Real Time The special characteristics of real time computing require extra attention to good software engineering principles: • Requirements analysis and specification • Special techniques (e.g., locks on data, semaphores, etc.) • Development of tools • Modular design • Exhaustive testing Heroic programming will fail!

42. Software Engineering for Real Time Testing and debugging need special tools and environments • Debuggers, etc., can not be used to test real time performance • Simulation of environment may be needed to test interfaces -- e.g., adjustable clock speed • General purpose tools may not be available

43. Some Notable Bugs Even commercial systems may have horrific bugs • Built-in function in Fortran compiler (e0 = 0) • Japanese microcode for Honeywell DPS virtual memory • The microfilm plotter with the missing byte (1:1023) • The Sun 3 page fault that IBM paid to fix • Left handed rotation in the graphics package • The preload system with the memory leak Good people work around problems. The best people track them down and fix them!