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.
2
The Software Life Cycle
• Problem analysis• Requirements definition• Software specification• High- and low-level design• Implementation• Testing and Verification• Delivery• Operation • Maintenance
3
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.
4
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.
5
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.
6
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.
7
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
8
Two Approaches to Building Manageable Modules
Object-Oriented Design
FunctionalDecomposition
Divides the problem into more easily handled subtasks, until the functional modules (subproblems) can be coded.
Identifies variousobjects composed of data and operations,that can be used together to solve the problem.
Focus on: processes Focus on : data objects
9
Object-Oriented Design
On
Off
Oven Egg
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.
SetSeparate
Crack
Private data Private data
11
Object-Oriented Design
• Class– A class describes a set of objects with the
same properties, behavior, and relationships– A class definition includes
• Attributes (properties)• Operations (behaviors)• Relations to other classes
– A class is similar to a data type with the addition of relations to other classes
12
Classes in Ada
• To build a class in Ada we use – the package along with – a special type called a tagged type
• To keep an object's data private we use– a special type called a private type
13
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.
14
Package Specificationfor Date Class
Dale and McCormick page 15• Simple types for class attributes• A type for the class (Date_Type)• Operations for the class
– Functions and Procedures• Private part that describes each object's
private data
15
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…
17
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.
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.
• Transformer An operation that changes the internal state of an object
20
Package Specificationfor Holiday Date
Dale and McCormick page 20• Child packages are used for subclasses
– Holiday is a child of package Date– Holiday_Date_Type is a subclass of Date_Type
• Operations for Holiday_Date objects include those defined in Date plus– New operations defined in Holiday.Date– Overridden operations that replace operations in the
superclass• New member data is added in the private part
21
Program Verification
Specifications• Inputs• Outputs• Processing
Requirements• Assumptions
The process of determining the degree to which a software product fulfills its specification.
Program
22
Verification (cont.)
Static verification Verifying a program without executing it.
Dynamic verification Verifying a program by executing it with a set of test data.
23
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.
24
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.
27
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.
28
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
29
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.
30
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.
31
Black-Box Testing(Example)
Develop a design and write a program to classify grapefruits received by a grocery wholesaler. The data for this program will be entered at the keyboard and consists of one line per grapefruit. Each line contains the grapefruit's diameter (in inches) and its condition (Excellent, Good, Fair, or Poor). The grapefruit's diameter is the first characteristic to consider in the classification as shown in the following table
Diameter GradeGreater than or equal to 4" ALess than 4" and greater than or equal to 3.5" BLess than 3.5" C
The above grades are for fruit in excellent condition. A fruit in Good condition is downgraded one level and a fruit in Fair condition is downgraded two levels. A fruit that is in Poor condition is downgraded three levels. Any grapefruit below grade C is rejected. 32
Black-Box Testing forClassification Program
Exhaustive Testing• All possible sizes (infinite number)• Four conditions
Impossible to do exhaustive testing of the grapefruit classification domain
33
Black-Box Testing forClassification Program
Subset of Functional Domain 12 tests• Three diameters (3 equivalence classes)• Four conditions (exhaustive)
34
Black-Box Testing forClassification Program
Boundary testing 6 tests
4.01” 3.51”4.00” 3.50”3.99” 3.49”
Run program 6 times with a single grapefruit in excellent condition
35
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.
36
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.
38
Integration Testing
• Is performed to integrate program modules that have already been independently unit tested.
FindWeighted Average
PrintWeighted Average
Main
Print Data
Print Heading
Get DataPrepare File for Reading
39
Integration Testing Approaches
Ensures correct overall design logic.
Ensures individual moduleswork together correctly, beginning with the lowest level.
TOP-DOWN BOTTOM-UP
USES: placeholder USES: a test driver to callmodule “stubs” to test the functions being tested.the order of calls.
40
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.
41
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.
42
Recommended