Transcript Intro

CS 330
PROGRAMMING LANGUAGES &
SOFTWARE ENGINEERING
Dr. Blaise W. Liffick
Spring 2015
1
Programming
Techniques
Languages
Problem Analysis
Program Design
•Algorithms & Design Patterns
•Data Structures
Paradigms
Java
C++
Hardware
Network
Linux
Eclipse
Programming
Environments
2
Early Computers
• Late 1930’s, John Atanasoff, Clifford Berry
• ENIAC
–
–
–
–
1946
University of Pennsylvania
J. Presper Eckert and John Mauchley
John von Neumann, stored-program concept
3
First Generation: 1940 – 1956
•
•
•
•
Vacuum tubes
Scientific oriented
ENIAC
UNIVAC – first commercial computer
4
Second Generation: 1956 – 1963
•
•
•
•
Transistors replaced vacuum tubes
I/O via punch cards and printers
First “high-level” languages developed
Data processing introduced
5
Third Generation: 1964 - 1971
•
•
•
•
•
Integrated circuit (semiconductors)
Keyboards & monitors
Time sharing
Computer “families”
Minicomputers vs. mainframes
6
Fourth Generation: 1971 – ?
• VLSI
• CPU on a chip: Microprocessor
• Microcomputers & Supercomputers
7
Fifth Generation: ???
• Based on artificial intelligence
• Big “Fifth Gen” project by Japanese in
1980’s
• Voice recognition, parallel processing,
superconductors
8
Categories of Computers
•
•
•
•
•
Supercomputers
Mainframe
Minicomputers
Microcomputers
Mobile devices
Power
Size
Cost
9
Programming Languages
• Machine Language
– Most fundamental language of the computer
– Unique for each processor type
– Binary 0s and 1s that specify what to do
• 0010 0000 0000 0100
• 1000 0000 0000 0101
• 0011 0000 0000 0110
24
Table 1.2
A Program in Machine and Assembly
Language
25
High - Level Languages
• Resemble human language
– Java, C++, C, Pascal, FORTRAN, Ada
a = a + b;
• More compact and human understandable
than machine language
• Must be translated into machine language
26
1.4 Processing a High-Level
Language Program
• Set of programs used to develop software
• A key component is a translator
– Compiler
• Examples
– Java, g++, Microsoft Visual C++®
• Other programs needed
– Editor
– Linker
– Loader
IDE
(e.g. Eclipse)
27
Processing a Program
• Editor used to enter the program
– Like minimal word processor
– Creates source program file
• Compiler translates the source program
– Displays syntax errors
– Creates (usually) temporary object code file
• Linker/Loader to combine object file with
other object files and execute program
– Creates final executable program
28
Executing a Program
• CPU
– examines each program instruction in memory
– sends out command signals required to carry
out the instruction
• Special instructions used to
– input data into memory for the program to use
– output data to display or printer (or other
device)
29
Editor used to
create program
Compilers
Source File
Compiler
translates
program into
machine
language
successful
unsuccessful
Error Messages
Other Object
Files
Object File
Linker
connects object
files
Executable
File
Loader
prepares for
execution
30
Editor used to
create program
Source File
Compiler
translates
program into
machine
language
Java
.java
successful
unsuccessful
Error Messages
Other Object
Files
Byte Codes
.class
Java Runtime
Environment
31
1.5 Software Development
Method
1. Problem Analysis
–
–
–
Identify data objects
Determine Input / Output data
Constraints on the problem
2. Design
–
–
–
Decompose into smaller problems
Top-down design (divide and conquer)
Develop Algorithm (Desk check)
•
Algorithm refinement
32
Software Development Method
3. Implementation
Converting the algorithm into programming
language
4. Testing
–
–
Verify the program meets requirements
System and Unit test
5. Maintenance
–
All programs undergo change over time
33
Waterfall Software Development Lifecycle
34
Spiral Software Development Lifecycle
35
Iterative Software Development Lifecycle
36
Testing
• How?
–
–
–
–
Path coverage (impractical)
Statement coverage (imprecise)
Proof of correctness (also impractical)
Formal Testing Process
37
Types of Testing
•
•
•
•
•
•
Design verification
Unit testing
Integration testing
System testing
Regression testing
Top down vs. bottom up
38
Design Verification
• Tests the algorithms in pseudo-code form
before any coding takes place.
• Uses the test plan for testing.
39
Unit Testing
• Software is typically developed in units –
subprograms, methods, functions.
• Test each unit independently.
• Verifies the unit interface and basic
functioning.
• Involves drivers.
40
Integration Testing
• Combines multiple units to test collectively.
• May involve not only drivers, but stubs.
41
System Testing
• Testing of multiple programs that
collectively must work together.
• E.g. MS Office Suite
42
Regression Testing
• Retesting code previously tested.
• Done generally during maintenance updates
to ensure that any change does not cause
problems with other units or elements of a
system.
• Gopher effect!
43
Top Down Development
• Testing begins with development of highest
level units.
• Subunits are created as stubs, enabling the
testing of unit interfaces only (not unit
functionality).
• Helps ensure that the structure of the code is
correctly implemented based on the design.
44
Bottom Up Development
• Follows unit testing technique – as each unit
is implemented, it is immediately tested
independently.
• Unit is fully developed functionally.
• Requires integration testing once enough
units have been implemented and unit
tested.
45
Developing a Test Plan
• Theoretically, a program’s specifications
should be sufficiently defined for it to be
possible to identify classes on inputs (both
valid an invalid) and expected outputs.
• The collection of such classes is the Test
Plan, which should be sufficient for
ensuring the proper functioning of any
software.
46
The Paradox of Testing
• It is impossible (impractical) to prove a
program is correct, you can only prove it is
incorrect!
• The goal of testing, then, is to try every
trick possible to cause a program to either
crash or produce erroneous or anomalous
results – i.e. you try to show it has bugs.
• If you fail in showing that a program has
bugs, then you conclude that the program is
as bug-free as you can currently make it.
47
Components of a Test Plan
• Test Plan – a collection of test cases.
• Test Case – one instance of inputs from
which the code will operate to some final
state.
• Composed of
– Unique identifier (number or name).
– Description of the purpose of this test case – the
type of test.
– The data set for the test.
– A detailed description of expected results.
48
Types of Test Cases
• Valid
– Known inputs to produce known outputs
– Typically what are given as examples in
assignment specifications
• Invalid
– Exceptions
– Typically looking for anomalous input
– ALL input should typically be accepted by the
program, but only SOME of the input leads to
successful processing.
49
Types of Test Cases, con’t
• Boundary values
– Every condition in the code creates boundaries
between what will trigger the condition either
true or false.
– Each boundary is an opportunity for errors to
creep into the code (e.g. < versus <=).
– Set up test cases to force every condition to
trigger on either sides of each boundary.
– E.g.
if (0 <= exam && exam <= 100)
50
Types of Test Cases, con’t
• Constraints describe ranges and conditions
of valid operational parameters
– E.g. ranges of input or output values.
• Includes limits on resources
– E.g. capacities of input or output, memory
requirements, speeds of operation
• Constraints define additional boundary
conditions
• Should include not only maximums, but
minimums, e.g. empty files, missing data
51
Word Search Test Plan
52