Chapter 1 Software Engineering

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

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.

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

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.

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.

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.

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.

Abstraction (cont.)

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.

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

Visual Aids – CRC Cards

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

Functional Design Modules

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

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.

UML Class Diagram for the Date Class

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…

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.

UML Class Diagram Showing Inheritance

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.

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

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

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.

Types of Errors Specification Design Coding Input

Cost of a Specification Error Based on When It Is Discovered

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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

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

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”

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

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

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

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)

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

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

First Pass at a List of Classes

Filtered List

CRC Cards