CSCE 606:
Final Exam Review
Outline
• Interfaces and Contracts
• From Models to Implementation
• API Design
• Testing
• Verification
• Model Checking
• Scripting Languages and Rapid Prototyping
• Licensing and SE Code of Ethics
10/2/2015
CSCE 606 Final Exam Review
2
Final Exam
• Wed 12/11 3:30-5:30pm, HRBB 124
• 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
10/2/2015
CSCE 606 Final Exam Review
3
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
10/2/2015
CSCE 606 Final Exam Review
4
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
10/2/2015
CSCE 606 Interfaces and Contracts
5
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.
10/2/2015
CSCE 606 Interfaces and Contracts
6
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
10/2/2015
CSCE 606 Interfaces and Contracts
7
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”
10/2/2015
CSCE 606 Interfaces and Contracts
8
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.
10/2/2015
CSCE 606 Interfaces and Contracts
9
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
10/2/2015
CSCE 606 Interfaces and Contracts
10
Example from ARENA:
League, Tournament, Player
• Constraints:
1.
2.
3.
10/2/2015
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 606 Interfaces and Contracts
11
Outline
• Interfaces and Contracts
• From Models to Implementation
• API Design
• Testing
• Verification
• Model Checking
• Scripting Languages and Rapid Prototyping
• Licensing and SE Code of Ethics
10/2/2015
CSCE 606 Final Exam Review
12
Transformations
10/2/2015
CSCE 606 Interfaces and Contracts
13
Model Transformation
Example
• Object design model before transformation:
• Object design model after transformation:
10/2/2015
CSCE 606 Interfaces and Contracts
14
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 {
//...
}
//...
}
10/2/2015
CSCE 606 Interfaces and Contracts
15
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
10/2/2015
CSCE 606 Interfaces and Contracts
16
Outline
• Interfaces and Contracts
• From Models to Implementation
• API Design
• Testing
• Verification
• Model Checking
• Scripting Languages and Rapid Prototyping
• Licensing and SE Code of Ethics
10/2/2015
CSCE 606 Final Exam Review
17
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
10/2/2015
CSCE 606 API Design
18
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
10/2/2015
CSCE 606 API Design
19
Interface
• Simple
• General
• Regular
• Predictable
• Robust
• Adaptable
10/2/2015
CSCE 606 API Design
20
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
10/2/2015
CSCE 606 API Design
21
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
10/2/2015
CSCE 606 API Design
22
Outline
• Interfaces and Contracts
• From Models to Implementation
• API Design
• Testing
• Verification
• Model Checking
• Scripting Languages and Rapid Prototyping
• Licensing and SE Code of Ethics
10/2/2015
CSCE 606 Final Exam Review
23
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)
10/2/2015
CSCE 606 Testing
24
Typical Test Categorization
• Unit testing
• Integration testing
• System testing
• Reliability testing
• Stress testing
• Acceptance testing
10/2/2015
CSCE 606 Testing
25
Verification vs. Validation
• Validation: “Are you building the right thing?”
• Verification: “Are you building it right?”
• Acceptance testing about validation, other
testing about verification
10/2/2015
CSCE 606 Testing
26
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
10/2/2015
CSCE 606 Testing
27
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
10/2/2015
CSCE 606 Testing
28
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
10/2/2015
CSCE 606 Testing
29
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
10/2/2015
CSCE 606 Testing
30
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
10/2/2015
CSCE 606 Testing
31
Some Coverage Criteria
all-defs
all-p-uses
all-c-uses
10/2/2015
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 606 Testing
32
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
10/2/2015
CSCE 606 Testing
33
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?
10/2/2015
CSCE 606 Testing
34
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)
10/2/2015
CSCE 606 Testing
35
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
10/2/2015
CSCE 606 Testing
36
Outline
• Interfaces and Contracts
• From Models to Implementation
• API Design
• Testing
• Verification
• Model Checking
• Scripting Languages and Rapid Prototyping
• Licensing and SE Code of Ethics
10/2/2015
CSCE 606 Final Exam Review
37
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
10/2/2015
CSCE 606 Final Exam Review
38
Rules
• Inference Rules
• Consequence
• Conjunction
• Language-specific rules
•
•
•
•
•
•
10/2/2015
Skip
Abort
Assignment
Conditional
Composition
While – loop invariant
CSCE 606 Final Exam Review
39
Weakest Preconditions
• Compute least-constraining P condition that
satisfies Q after A terminates
10/2/2015
CSCE 606 Final Exam Review
40
Outline
• Interfaces and Contracts
• From Models to Implementation
• API Design
• Testing
• Verification
• Model Checking
• Scripting Languages and Rapid Prototyping
• Licensing and SE Code of Ethics
10/2/2015
CSCE 606 Final Exam Review
41
Model Checking
• Idea of temporal logic
• Path operators
• A p – all paths starting from a state have property p
• E p – some path from a state have property p
• Temporal operators
•
•
•
•
•
X p – p holds in next state
F p – p holds in a future state
G p – p holds always
p U q – q holds for some state, and p holds until then
p R q – q holds up to and including a state where p holds
10/2/2015
CSCE 606 Final Exam Review
42
Outline
• Interfaces and Contracts
• From Models to Implementation
• API Design
• Testing
• Verification
• Model Checking
• Scripting Languages and Rapid Prototyping
• Licensing and SE Code of Ethics
10/2/2015
CSCE 606 Final Exam Review
43
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
10/2/2015
CSCE 606 Scripting Languages & Rapid
Prototyping
44
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
10/2/2015
CSCE 606 Scripting Languages & Rapid
Prototyping
45
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
10/2/2015
CSCE 606 Scripting Languages & Rapid
Prototyping
46
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
10/2/2015
CSCE 606 Scripting Languages & Rapid
Prototyping
47
System vs. Scripting
Language Level
1000
[Ousterhout 1998]
Scripting
Instructions/statement
Visual Basic
100
Java
C++
Tcl/Perl
C
10
Assembly
1
System programming
None
10/2/2015
Degree of Typing
CSCE 606 Scripting Languages & Rapid
Prototyping
Strong
48
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
10/2/2015
CSCE 606 Scripting Languages & Rapid
Prototyping
49
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
10/2/2015
CSCE 606 Scripting Languages & Rapid
Prototyping
50
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
10/2/2015
CSCE 606 Scripting Languages & Rapid
Prototyping
51
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
10/2/2015
CSCE 606 Scripting Languages & Rapid
Prototyping
52
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!
10/2/2015
CSCE 606 Scripting Languages & Rapid
Prototyping
53
Outline
• Interfaces and Contracts
• From Models to Implementation
• API Design
• Testing
• Verification
• Model Checking
• Scripting Languages and Rapid Prototyping
• Licensing and SE Code of Ethics
10/2/2015
CSCE 606 Final Exam Review
54
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
10/2/2015
CSCE 606 Licensing and SE Code of
Ethics
55
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)
10/2/2015
CSCE 606 Licensing and SE Code of
Ethics
56
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
10/2/2015
CSCE 606 Licensing and SE Code of
Ethics
57
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
10/2/2015
CSCE 606 Licensing and SE Code of
Ethics
58
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
10/2/2015
CSCE 606 Licensing and SE Code of
Ethics
59
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
10/2/2015
CSCE 606 Licensing and SE Code of
Ethics
60
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
Model Checking – just basic ideas
Scripting Languages and Rapid Prototyping – key
ideas, where to use
• Licensing and SE Code of Ethics – licensing
process, basic points of ethics
10/2/2015
CSCE 606 Final Exam Review
61
Descargar

Document