1. Chapter 1
Software Engineering

2. The Software Life Cycle
Problem analysis
Requirements definition
Software specification
High- and low-level design
Implementation
Testing and Verification
Delivery
Operation
Maintenance

3. Software Engineering
A disciplined approach to the design, production, and maintenance of computer programs
that are developed on time and within cost estimates,
using tools that help to manage the size and complexity of the resulting software products.

4. Programmer Toolboxes
Hardware—the computers and their peripheral devices
Software—operating systems, editors, compilers, interpreters, debugging systems, test-data generators, and so on
Ideaware—shared body of knowledge
Algorithms
Data structures
Programming methodologies

5. An Algorithm Is . . .
A logical sequence of discrete steps that describes a complete solution to a given problem computable in a finite amount of time and space.

6. Goals of Quality Software
It works.
It can be modified without excessive time and effort.
It is reusable.
It is completed on time and within budget.

7. Software Specification
A detailed description of the function, inputs, processing, outputs, and special requirements of a software product.
It provides the information needed to design and implement the product
Tells what the program must do, but not how it does it.

8. Abstraction
A model of a complex system that includes only the details essential to the perspective of the viewer of the system.
Programs are abstractions.

9. Abstraction (cont.)

10. Information Hiding
The practice of hiding the details of a module with the goal of controlling access to the details from the rest of the system.
A programmer can concentrate on one module at a time.
Each module should have a single purpose or identity.

11. Stepwise Refinement A problem is approached in stages.
Similar steps are followed during each stage, with the only difference being the level of detail involved.
Some variations:
Top-down
Bottom-up
Functional decomposition
Round-trip gestalt design

12. Visual Aids – CRC Cards

13. Two Approaches to Building Manageable Modules
Functional Decomposition
Object-Oriented Design
Divides the problem
into more easily handled
subtasks, until the
functional modules
(subproblems) can
be coded.
Identifies various
objects composed of
data and operations,
that can be used
together to solve
the problem.
Focus on: processes Focus on : data objects

14. Functional Design Modules

15. Object-Oriented Design
A technique for developing a program in which the solution is expressed in terms of objects -- self- contained entities composed of data and operations on that data.
Oven
Egg On
Crack
Private data
Private data
Off
Separate
Set

16. Packages
Package A group of logically related entities that may include types and subtypes, objects of those types and subtypes, and subprograms with parameters of those types and subtypes.
Package Specification The visible portion of a package; specifies what resources are supplied by the package.
Package Body The implementation of a package.

17. UML Class Diagram for the Date Class

18. Classification of Operations
Constructor An operation used to create new values of a class
Observer An operation that returns an observation on the state of an object.
More later…

19. Inheritance A powerful reuse tool.
Allows programmers to create a new class that is a specialization of an existing class.
The new class is called a subclass of the existing class.
The existing class is the superclass of the new class.

20. UML Class Diagram Showing Inheritance

21. Identifying Classes Start brainstorming ideas.
Identify objects in the problem.
Objects are usually nouns and operations are usually verbs.
Filter the classes.
Consider some scenarios in which the objects interact to accomplish a task.
CRC cards help us enact such scenarios.

22. Program Verification
The process of determining the degree to which a software product fulfills its specification.
Specifications
Inputs
Outputs
Processing Requirements
Assumptions
Program

23. Verification (cont.)
Static verification Verifying a program without executing it.
Dynamic verification Verifying a program by executing it with a set of test data.

24. Verification vs. Validation
Program verification asks,
“Are we doing the job right?”
Program validation asks,
“Are we doing the right job?”
B.W. Boehm, Software Engineering Economics, 1981.

25. Types of Errors
Specification
Design
Coding
Input

26. Cost of a Specification Error Based on When It Is Discovered

27. Review Activities
Deskchecking Tracing an execution of a design or program on paper.
Walk-through A verification Method in which a team performs a manual simulation of the program or design
Inspection A verification method in which one member of a team reads the program or design line by line and the other point out errors.

28. Static Verification
Assertion A statement that is true or false but not both.
Preconditions Assertions of what must be true on entry into an operation for the postconditions to be guaranteed.
Postconditions Assertions that describe what results are expected at the exit of an operation, assuming that the preconditions were true.
Loop Invariant Assertion of what must be true at the start of each loop iteration and on exit from the loop.

29. Testing
The process of executing a program with data sets designed to discover errors.
Data Set 1
Data Set 2
Data Set 3
Data Set 4

30. Types of Testing (1)
Black-box testing Testing a program or operation based on the possible input values, treating the code as a “black-box.”
Clear (white)-box testing Testing a program or operation based on covering all of the branches or paths of the code.

31. Black-Box Testing (Data Coverage)
Functional Domain The set of valid input data for a program or operation.
Exhaustive Testing Testing with all the inputs in the functional domain.

32. Clear-Box Testing (Code Coverage)
Branch A code segment that is not always executed; for example a case statement has as many branches as there are case alternatives.
Path A combination of branches that might be traversed during a single execution of a program or operation.
Path Testing A testing technique whereby the tester tries to execute all possible paths in a program or operation.

33. Types of Testing (2)
Unit testing Testing a class or operation by itself.
Integration testing Testing that is performed on combined program modules that already have been independently tested.
Acceptance testing The process of testing the system in its real environment with real data.
Regression Testing Re-execution of program tests after modifications have been made in order to ensure the program still works correctly.

34. Integration Testing
Is performed to integrate program modules that have already been independently unit tested.
Find
Weighted
Average
Print
Main
Print Data
Print Heading
Get Data
Prepare
File for
Reading

35. Integration Testing Approaches
TOP-DOWN
BOTTOM-UP
Ensures individual modules
work together correctly,
beginning with the
lowest level.
Ensures correct overall
design logic.
USES: placeholder USES: a test driver to call
module “stubs” to test the functions being tested.
the order of calls.

36. Test Plan
Document showing the test cases planned for a program, class, or operation; their goals, inputs, expected outputs and criteria for success.
For program testing to be effective, it must be planned.
Ideally written simultaneously with the program specification.

37. Life-Cycle Verification Activities
Analysis
Make sure that requirements are completely understood.
Understand testing requirements.
Specification
Verify the identified requirements.
Perform requirements inspections with your client.
Write test plan system functionality.
Design
Design for correctness (using assertions such as preconditions, postconditions, and loop invariants).
Perform design inspections.
Plan testing approach.
Code
Understand programming language well.
Perform code inspections.
Add debugging output statements to the program.
Write test plan for unit testing of modules.
Construct test drivers.
Test
Unit test according to test plan.
Debug as necessary.
Integrate tested modules.
Retest after corrections.
Delivery
Execute acceptance tests of complete product.
Maintenance
Execute regression test whenever delivered product is changed to add new functionality or to correct detected problems.

38. Object-Oriented Design
A problem-solving methodology that produces a solution to a problem in terms of self-contained entities called objects
An object is a thing or entity that makes sense within the context of the problem
For example, a student

39. Object-Oriented Design
A group of similar objects is described by an object class, or class
A class contains fields that represent the properties and behaviors of the class
A field can contain data value(s) and/or functions (subprograms)
An operation is a named algorithm that manipulates the data values in the object

40. Relationships Between Classes
Containment
“part-of”
An address class may be part of the definition of a student class
Inheritance
Classes can inherit data and behavior from other classes
“is-a”

41. Object-Oriented Design Methodology
Four stages to the decomposition process
Brainstorming
Filtering
Scenarios
Responsibility algorithms

42. Brainstorming
A group problem-solving technique that involves the spontaneous contribution of ideas from all members of the group
All ideas are potential good ideas
Think fast and furiously first, and ponder later
A little humor can be a powerful force
Brainstorming is designed to produce a list of candidate classes

43. Filtering Determine which are the core classes in the problem solution
There may be two classes in the list that have many common attributes and behaviors
There may be classes that really don’t belong in the problem solution

44. Scenarios Simulate class interactions Ask “What if?” questions
Assign responsibilities to each class
There are two types of responsibilities
What a class must know about itself (knowledge)
What a class must be able to do (behavior)

45. Responsibility Algorithms
The algorithms must be written for the responsibilities
Knowledge responsibilities usually just return the contents of one of an object’s variables
Action responsibilities are a little more complicated, often involving calculations

46. Example
Let’s repeat the problem-solving process for creating an address list
Brainstorming and filtering
Circling the nouns and underlining the verbs

47. First Pass at a List of Classes

48. Filtered List

49. CRC Cards