CSCE 431:
Final Exam Review
Outline
• Interfaces and Contracts
• From Models to Implementation
• API Design
• Testing
• Verification
• Scripting Languages and Rapid Prototyping
• Licensing and SE Code of Ethics
CSCE 431 Final Exam Review
Final Exam
• Wed 5/7 8:00-10:00am, RICH 106
• Covers Interfaces and Contracts through
Licensing and SE Code of Ethics
• Covers Homework 3
• Focus on material covered in slides
• Assigned readings are background material to
aid your understanding
CSCE 431 Final Exam Review
Interfaces and Contracts
Object design
 Object design model (class diagrams)
 Interface contracts, syntactic and semantic
 Library APIs, error handling
Implementation
Interface contracts, syntactic and semantic
Library APIs, error handling
Source code
CSCE 431 Final Exam Review
Object Design
• Purpose
• Prepare for implementing the system model
• Transform the system model for better
implementability, extensibility, performance, …
• Explore ways to implement the system model
• The result of object design should match the
structure of the implementation
CSCE 431 Final Exam Review
Activities
• Reuse: identify and adapt existing solutions
• Off-the-shelf components
• Libraries
• Design patterns
• Interface specification
• Specs of each class interface
• APIs of subsystems
• Object model restructuring
• To improve some characteristics (extensibility,
understandability, etc.)
• Object model optimization
• Greater speed, lower memory use, etc.
CSCE 431 Final Exam Review
Executive Summary
• UML models can be gradually refined to
include more details about interfaces
• UML+OCL: Notations and language to express
contracts (pre/post conditions, invariants) in
UML
• Interesting part is constraints that span multiple
classes (constraints over UML associations)
• Language neutral constraints
CSCE 431 Final Exam Review
Access Control Guidelines
• Expose as little as possible
• But the “basis” should be complete—and efficient
• The less exposed, the more freedom to change the
class implementation
• Fewer things to learn and document
• Access attributes only via operations (except when
no class invariant)
• Hide substructures
• Do not apply an operation to the result of another
operation
• Write a new operation that combines the two operations
• “Law of Demeter”
CSCE 431 Final Exam Review
Law of Demeter1
• Method M of an object O may only invoke the methods of the following
kinds of objects:
•
•
•
•
•
O itself
M’s parameters
Any objects created/instantiated within M
O’s direct component objects
Global variables, accessible by O, in the scope of M
• Example violation: x.y.foo().bar()
• Layered architectures satisfy the law
• One goal: compositionality
• The meaning of a complex expression is determined by the meanings of its
immediate constituent expressions and the rules used to combine them
• Testimonial (from JPL):
We have found, however, that breaking the LoD is very expensive! On Mars
Pathfinder, the integration costs of the law breaking parts of the system were at
least an order of magnitude higher, and we had to pay that cost on every integration
cycle – not just once! We should have paid the cost once by implementing a more
sophisticated protocol that did obey the LoD.
1Karl
Lieberherr and Ian Holland, Assuring Good Style for Object-Oriented Programs, IEEE Software,
Sep. 1989, pp. 38-48.
CSCE 431 Final Exam Review
Contracts and Formal
Specification
• Contracts enable the caller and the provider to
share the same assumptions about the class
• A contract is an exact specification of the
interface of an object
• A contract include three types of constraints:
• Invariant:
• A predicate that is always true for all instances of a class
• Pre-condition (“rights”):
• Must be true before an operation is invoked
• Post-condition (“obligation”):
• Must be true after an operation is invoked
CSCE 431 Final Exam Review
Example from ARENA:
League, Tournament, Player
• Constraints:
1.
2.
3.
A Tournament’s planned
duration must be under
one week
Players can be accepted in
a Tournament only if they
are already registered with
the corresponding League
The number of active
Players in a League are
those that have taken part
in at least one Tournament
of the League
CSCE 431 Final Exam Review
Outline
• Interfaces and Contracts
• From Models to Implementation
• API Design
• Testing
• Verification
• Scripting Languages and Rapid Prototyping
• Licensing and SE Code of Ethics
CSCE 431 Final Exam Review
Transformations
CSCE 431 Final Exam Review
Model Transformation
Example
• Object design model before transformation:
• Object design model after transformation:
CSCE 431 Final Exam Review
Same Transformation in Code:
Refactoring: Pull Up Field
public class Player {
public class User {
private String email;
private String email;
//...
}
}
public class Player extends User {
public class LeagueOwner {
//...
private String eMail;
}
//...
public class LeagueOwner extends User {
}
//...
public class Advertiser {
}
private String email_address;
public class Advertiser extends User {
//...
}
//...
}
CSCE 431 Final Exam Review
Summary of Models to
Implementation
• Four mapping concepts
1. Model transformations
• Improve the compliance of the object design model with a design goal
2. Forward engineering
• Consistent transformation of models to code
3. Refactoring
• “Preserve semantics, improve readability/modifiability”
4. Reverse engineering
• “Extract design from code”
• Model transformations and forward engineering techniques
•
•
•
•
“Optimizing” within the class model
Mapping associations to collections
Mapping contracts to exceptions
Mapping class model to storage schemas
CSCE 431 Final Exam Review
Outline
• Interfaces and Contracts
• From Models to Implementation
• API Design
• Testing
• Verification
• Scripting Languages and Rapid Prototyping
• Licensing and SE Code of Ethics
CSCE 431 Final Exam Review
Characteristics of a Good API
• Easy to learn
• Easy to use even without documentation
• Hard to misuse
• Easy to read and maintain code that uses it
• Sufficiently powerful to satisfy requirements
• Easy to extend
• Appropriate to audience
CSCE 431 Final Exam Review
Designing an API: “Eat your
own dog food”
• Write to your API early and often
• Even if not yet implemented
• Even if not yet fully specified
• These avoid wasted implementation and specification effort
• Code you write lives on as unit tests and example uses
(documentation)
• Expect the API to evolve
• “The rule of Threes” (Will Tracz:, Confessions of A Used
Program Salesman, Addison-Wesley, 1995)
• Write one client before release, will not support another
• Write two clients before release, will support more with difficulty
• Write three clients before release, will work fine
CSCE 431 Final Exam Review
Interface
• Simple
• General
• Regular
• Predictable
• Robust
• Adaptable
CSCE 431 Final Exam Review
Broad Issues to Consider in
API Design
1. Interface
• Classes, methods, parameters, names
2. Resource Management
• How is memory, other resources dealt with
3. Error Handling
• What errors are caught and what is done to handle
them
4. Information Hiding
• How much detail is exposed
• Impacts all three of the above
CSCE 431 Final Exam Review
Abrahams’ Categorization
• The basic guarantee: invariants of component are
preserved, no resources are leaked
• Basically, an object can be assigned to
• The strong guarantee: that the operation has either
• Completed successfully, or
• Thrown an exception, leaving the program state exactly
as it was before the operation started
• The no-throw guarantee: that the operation will not
throw an exception
http://www.boost.org/community/exception_safety.html
CSCE 431 Final Exam Review
Outline
• Interfaces and Contracts
• From Models to Implementation
• API Design
• Testing
• Verification
• Scripting Languages and Rapid Prototyping
• Licensing and SE Code of Ethics
CSCE 431 Final Exam Review
Fault Avoidance and Detection
• Static Analysis
•
•
•
•
Hand execution: Reading the source code
Walk-Through (informal presentation to others)
Code Inspection (formal presentation to others)
Automated Tools checking for
• Syntactic and semantic errors
• Departure from coding standards
• Dynamic Analysis
• Black-box testing (Test the input/output behavior)
• White-box testing (Test the internal logic of the
subsystem or class)
• Data-structure based testing (Data types
determine test cases)
CSCE 431 Final Exam Review
Typical Test Categorization
• Unit testing
• Integration testing
• System testing
• Reliability testing
• Stress testing
• Acceptance testing
CSCE 431 Final Exam Review
Verification vs. Validation
• Validation: “Are you building the right thing?”
• Verification: “Are you building it right?”
• Acceptance testing about validation, other
testing about verification
CSCE 431 Final Exam Review
Another Test Categorization –
By Intent
• Regression testing
• Retest previously tested element after changes
• Goal is to assess whether changes have
(re)introduced faults
• Mutation testing
• Introduce faults to assess test quality
CSCE 431 Final Exam Review
Goal – Partition Testing
• Cannot test for all possible input data
• Idea: For each test, partition input data into equivalence classes,
such that:
• The test fails for all elements in the equivalence class; or
• The test succeeds for all elements in the equivalence class.
• If this succeeds:
• One input from each equivalence class suffices
• No way to know if partition is correct (likely not)
• Heuristics - could partition data like this:
•
•
•
•
Clearly good values
Clearly bad values
Values just inside the boundary
Values just outside the boundary
CSCE 431 Final Exam Review
Mock Objects
• Often (practically) impossible to include real objects,
those used in full application, into test cases
• To test code that depends on such objects, one often
uses mock objects instead
• Mock object simulates some part of the behavior of
another object, or objects
• Useful in situations where real objects
• Could provide non-deterministic data
• States of real objects are hard to reproduce (e.g. are result of
interactive use of software, erroneous cases)
• Functionality of real objects has not yet been implemented
• Real objects are slow to produce results
• Tear-up/tear-down requires lots of work and/or is time
consuming
CSCE 431 Final Exam Review
White Box Testing
• White box – you know what is inside, i.e. the code
• Idea
• To assess the effectiveness of a test suite, measure how much
of the program it exercises
• Concretely
• Choose a kind of program element, e.g., instructions
(instruction coverage) or paths (path coverage)
• Count how many are executed at least once
• Report as percentage
• A test suite that achieves 100% coverage achieves the
chosen criterion. Example:
• “This test suite achieves instruction coverage for routine r ”
• Means that for every instruction i in r, at least one test executes i
CSCE 431 Final Exam Review
Coverage Criteria
• Instruction (or statement) coverage
• Measure instructions executed
• Disadvantage: insensitive to some control structures
• Branch coverage
• Measure conditionals whose paths are both/all executed
• Condition coverage
• How many atomic Boolean expressions evaluate to both
true and false
• Path coverage
• How many of the possible paths are taken
• path == sequence of branches from routine entry to exit
CSCE 431 Final Exam Review
Some Coverage Criteria
all-defs
all-p-uses
all-c-uses
execute at least one def-clear sub-path
between every definition of every
variable and at least one reachable use
of that variable
execute at least one def-clear sub-path
from every definition of every variable to
every reachable p-use of that variable
execute at least one def-clear sub-path
from every definition of every variable to
every reachable c-use of the respective
variable
CSCE 431 Final Exam Review
Some Coverage Criteria
all-c-uses/some-p-uses apply all-c-uses; then if any
definition of a variable is not
covered, use p-use
all-p-uses/some-c-uses symmetrical to all-c-uses/
some-p-uses
all-uses
execute at least one def-clear
sub-path from every definition
of every variable to every
reachable use of that variable
CSCE 431 Final Exam Review
Who Tests the Tester?
• All tests pass. Is the software really that good?
• How does one know?
• Is the software perfect or is the coverage too
limited?
• Test the tests
• Intentionally introduce defects
• If tests find the defects, test suite good
• If no bugs are found, test suite insufficient
• Have to plan defect types and locations
• Random?
• Weight based on code criticality?
• Amount of coverage?
CSCE 431 Final Exam Review
Code Reviews
• Method shown to be effective in finding errors
• Ratio of time spent in review vs. later testing and error
correction
• Ranges from 1:20 to 1:100
• Reduced defect correction from 40% of budget to 20%
• Maintenance costs of inspected code is 10% of noninspected code
• Changes done with review: 95% correct vs. 20% w/o
review
• Reviews cut errors by 20% to 80%
• Several others (examples from Code Complete)
CSCE 431 Final Exam Review
Reviews vs. Testing
•
•
•
•
•
•
Finds different types of problems than testing
Unclear error messages
Bad commenting
Hard-coded variable names
Repeated code patterns
Only high-volume beta testing (and prototyping)
find more errors than formal inspections
• Inspections typically take 10-15% of budget, but
usually reduce overall project cost
• Reviews can provide input to test plan
CSCE 431 Final Exam Review
Outline
• Interfaces and Contracts
• From Models to Implementation
• API Design
• Testing
• Verification
• Scripting Languages and Rapid Prototyping
• Licensing and SE Code of Ethics
CSCE 431 Final Exam Review
Program Properties
• Well-formed formulas: “Hoare triples”
• {P} A {Q}
• A is a program fragment
• P; Q predicates over the program state
• If A is started in any state that satisfies P, the
state after A terminates will satisfy Q
• Partial correctness – A may not terminate
• Total correctness – A will terminate
CSCE 431 Final Exam Review
Rules
• Inference Rules
• Consequence
• Conjunction
• Language-specific rules
•
•
•
•
•
•
Skip
Abort
Assignment
Conditional
Composition
While – loop invariant
CSCE 431 Final Exam Review
Weakest Preconditions
• Compute least-constraining P condition that
satisfies Q after A terminates
CSCE 431 Final Exam Review
Outline
• Interfaces and Contracts
• From Models to Implementation
• API Design
• Testing
• Verification
• Scripting Languages and Rapid Prototyping
• Licensing and SE Code of Ethics
CSCE 431 Final Exam Review
Scripting Language
• Programming language that supports scripts - programs written for
a special run-time environment that can interpret (rather than
compile) and automate the execution of tasks which could
alternatively be executed one-by-one by a human operator
• Can be viewed as a domain-specific language for a particular
environment; in the case of scripting an application, this is also
known as an extension language
• High-level language, ~10x less code than system programming
language
• Often implies “small” (≤ few thousand lines of code)
• Can be domain-specific, e.g. Awk, Sed string processing
languages
• Can be environment-specific, e.g. UNIX Shell, Visual Basic for
Applications
- http://en.wikipedia.org/wiki/Scripting_language
CSCE 431 Final Exam Review
Scripting Languages
• Used for one-time tasks
• Customizing administrative tasks
• Simple or repetitive tasks
• Example: run an application with a sequence of
different parameters
• Extension language
• LISP in EMACS an early example
• Controls execution of an application
• Programmatic interface to graphical application
CSCE 431 Final Exam Review
Classes of Scripting
• Web browser – PHP, Javascript,…
• Extension language – Lua, Tcl, VBA,…
• GUI – JavaFX, Tcl/Tk,…
• String processing – Awk, Sed,…
• OS scripting – Shell, Cshell,…
• General languages – Perl, Python, Ruby,…
• Overlap among these
CSCE 431 Final Exam Review
System Programming Languages
vs. Scripting Languages
• System programming languages
• C, C++, Java,…
• Designed for building data structures and
algorithms from scratch
• Concerns: efficiency, expressiveness, strong typing,
design support, read-only code, compiled
• Scripting languages
• Tcl, Perl, Python, Ruby, Awk, Sed, Shell, Lua,…
• Designed for gluing components together
• Concerns: rapid prototyping, typeless, higher level
programming, interpreted, code-on-fly
CSCE 431 Final Exam Review
System vs. Scripting
Language Level
1000
Scripting
[Ousterhout 1998]
Instructions/statement
Visual Basic
100
Java
C++
Tcl/Perl
C
10
Assembly
1
System programming
None
Degree of Typing
CSCE 431 Final Exam Review
Strong
Not Either/Or
• Most platforms provide scripting and system PL
• IBM
• Job Control Language (JCL) - sequence jobs on OS/360
• ~1st scripting PL
• Jobs ran in FORTRAN, PL/1, Algol, COBOL, Assembler
• UNIX
• Shell – sh/csh
• C
• PC
• Visual Basic
• C/C++
• Web
• JavaScript, Perl, Tcl
• Java
CSCE 431 Final Exam Review
Observations
• People write similar LOC/h
• Scripting takes 2-3x less code
• So 2-3x less development time
• Scripting memory consumption ~higher
• Java outlier
• Lot of variation
• Scripting ~10-20x longer load and preprocess
• Scripting ~similar search times
• String-oriented application
• C/C++ code had more bugs
CSCE 431 Final Exam Review
What is Rapid Prototyping?
1. Quick assembly of a partial or complete system for
experimentation prior to full requirements,
specification and implementation
2. Quick assembly of a tool or system for temporary or
permanent use, using special-purpose languages and
existing tools
• Goals
• Rapid! - <10% of time for traditional C/C++ implementation
• Functionality – implement functions to permit experimentation
or use
• Okay performance – system only needs to be fast enough to
try it out or to be acceptable
• Easily modified – for iteration during experimentation, or for
maintainability
CSCE 431 Final Exam Review
Relationship to Agile
• Agile
• Build system using “final” technology
• Each iteration is a working system, gradually
adding features
• User stories more than requirements/specs
• Rapid prototyping
• May never be a “production” system
• Need the system to elicit user stories
• What does user want?
• “I know it when I see it” – Potter Stewart
CSCE 431 Final Exam Review
Rapid Prototyping Tools
• Shells
• Bourne shell (sh), C shell (csh), Korn shell (ksh), born-again shell (bash),
PowerShell
• Pattern languages
• Awk, gawk, sed, grep, perl
• Extension languages
• Emacs LISP
• Scripting languages
• Tcl, Python, Ruby,…
• Parser generators
• Lex, yacc
• Utilities
• UNIX: comm, diff, ed, find, sort, uniq, wc
• Existing tools
• Reuse, don’t code!
CSCE 431 Final Exam Review
Outline
• Interfaces and Contracts
• From Models to Implementation
• API Design
• Testing
• Verification
• Scripting Languages and Rapid Prototyping
• Licensing and SE Code of Ethics
CSCE 431 Final Exam Review
Licensing Process
• Earn 4-year engineering degree from ABET-accredited
university
• Pass Fundamentals of Engineering (FE) exam
•
•
•
•
Covers engineering fundamentals
One test for all engineers
Taken during senior year or soon after graduation
Become engineer-in-training (EIT)
• Complete 4 years of progressive engineering
experience under a PE
• Keep journal of engineering work – verified by supervisor
• Engineering MS/PhD partially counts in most states
CSCE 431 Final Exam Review
Licensing Process (cont.)
• 3 confidential references from PEs who are familiar
with your work record
• Pass Principles and Practice of Engineering (PE)
exam
• 8 hour open-book exam in your area of practice
• Software Engineering Principles and Practice PE exam
• Offered first in April 2013 in Texas and several other states
• Mac Lively and other TAMU faculty worked on the development
of a PE in Software Engineering
• Covers Software Engineering Body of Knowledge
(SWEBOK)
CSCE 431 Final Exam Review
Licensing Process (cont.)
• Software Engineering PE Exam
•
•
•
•
•
•
•
•
•
Requirements
Design
Construction
Testing
Maintenance
Configuration Management
Engineering Processes
Quality Assurance
Safety, Security, and Privacy
17.5%
13.75%
11.25%
12.5%
7.5%
7.5%
7.5%
7.5%
15%
http://www.tbpe.state.tx.us/downloads/ncees_PESoftware_2013.pdf
CSCE 431 Final Exam Review
ACM/IEEE-CS Software
Engineering Code of Ethics
and Professional Practice
• Software engineers shall commit themselves to
making the analysis, specification, design,
development, testing and maintenance of
software a beneficial and respected profession
• In accordance with their commitment to the
health, safety and welfare of the public,
software engineers shall adhere to the
following Eight Principles
CSCE 431 Final Exam Review
SE Ethics Principles (1)
• PUBLIC - Software engineers shall act consistently
with the public interest
• CLIENT AND EMPLOYER - Software engineers
shall act in a manner that is in the best interests of
their client and employer consistent with the public
interest
• PRODUCT - Software engineers shall ensure that
their products and related modifications meet the
highest professional standards possible
• JUDGMENT - Software engineers shall maintain
integrity and independence in their professional
judgment
CSCE 431 Final Exam Review
SE Ethics Principles (2)
• MANAGEMENT - Software engineering managers and
leaders shall subscribe to and promote an ethical
approach to the management of software development
and maintenance
• PROFESSION - Software engineers shall advance the
integrity and reputation of the profession consistent with
the public interest
• COLLEAGUES - Software engineers shall be fair to and
supportive of their colleagues
• SELF - Software engineers shall participate in lifelong
learning regarding the practice of their profession and
shall promote an ethical approach to the practice of the
profession
CSCE 431 Final Exam Review
Final Exam Summary
• Interfaces and Contracts – good principles
• From Models to Implementation - process
• API Design – good design principles
• Testing – types of testing
• Verification – pre/post conditions, invariants,
Dafny
• Scripting Languages and Rapid Prototyping –
key ideas, where to use
• Licensing and SE Code of Ethics – licensing
process, basic points of ethics
CSCE 431 Final Exam Review