csce 431 final exam review n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
CSCE 431: Final Exam Review PowerPoint Presentation
Download Presentation
CSCE 431: Final Exam Review

Loading in 2 Seconds...

play fullscreen
1 / 59

CSCE 431: Final Exam Review - PowerPoint PPT Presentation


  • 134 Views
  • Uploaded on

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. Final Exam. Wed 5/7 8:00-10:00am, RICH 106

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'CSCE 431: Final Exam Review' - lynley


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
outline
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
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
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
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
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
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
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 demeter 1
Law of Demeter1
  • Method Mof an object Omay only invoke the methods of the following kinds of objects:
    • Oitself
    • 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 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
Example from ARENA: League, Tournament, Player
  • Constraints:
    • 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

outline1
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
Transformations

CSCE 431 Final Exam Review

model transformation example
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
Same Transformation in Code: Refactoring: Pull Up Field

public class Player {

private String email;

//...

}

public class LeagueOwner {

private String eMail;

//...

}

public class Advertiser {

private String email_address;

//...

}

public class User {

private String email;

}

public class Player extends User {

//...

}

public class LeagueOwnerextends User {

//...

}

public class Advertiser extends User {

//...

}

CSCE 431 Final Exam Review

summary of models to implementation
Summary of Models to Implementation
  • Four mapping concepts
    • Model transformations
      • Improve the compliance of the object design model with a design goal
    • Forward engineering
      • Consistent transformation of models to code
    • Refactoring
      • “Preserve semantics, improve readability/modifiability”
    • 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

outline2
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
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
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
Interface
  • Simple
  • General
  • Regular
  • Predictable
  • Robust
  • Adaptable

CSCE 431 Final Exam Review

broad issues to consider in api design
Broad Issues to Consider in API Design
  • Interface
    • Classes, methods, parameters, names
  • Resource Management
    • How is memory, other resources dealt with
  • Error Handling
    • What errors are caught and what is done to handle them
  • Information Hiding
    • How much detail is exposed
    • Impacts all three of the above

CSCE 431 Final Exam Review

abrahams categorization
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

outline3
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
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
Typical Test Categorization
  • Unit testing
  • Integration testing
  • System testing
  • Reliability testing
  • Stress testing
  • Acceptance testing

CSCE 431 Final Exam Review

verification vs validation
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
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
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
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 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
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 trueand 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
Some Coverage Criteria

all-defsexecute at least one def-clear sub-path between every definition of every variable and at least one reachable use of that variable

all-p-uses execute at least one def-clear sub-path from everydefinition of every variable to every reachable p-use of that variable

all-c-uses execute at least one def-clear sub-path from everydefinition of every variable to every reachable c-use of the respective variable

CSCE 431 Final Exam Review

some coverage criteria1
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 onedef-clear sub-path from everydefinition of every variable to every reachable use of that variable

CSCE 431 Final Exam Review

who tests the tester
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
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 non-inspected 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
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

outline4
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
Program Properties
  • Well-formed formulas: “Hoare triples”
    • {P} A {Q}
  • Ais a program fragment
  • P; Q predicates over the program state
  • If A is started in any state that satisfies P, the state after Aterminateswill satisfy Q
    • Partial correctness – A may not terminate
    • Total correctness – A will terminate

CSCE 431 Final Exam Review

rules
Rules
  • Inference Rules
    • Consequence
    • Conjunction
  • Language-specific rules
    • Skip
    • Abort
    • Assignment
    • Conditional
    • Composition
    • While – loop invariant

CSCE 431 Final Exam Review

weakest preconditions
Weakest Preconditions
  • Compute least-constraining P condition that satisfies Q after A terminates

CSCE 431 Final Exam Review

outline5
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
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
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
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 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
System vs. Scripting Language Level

1000

[Ousterhout 1998]

Scripting

Visual Basic

100

Java

Instructions/statement

C++

Tcl/Perl

C

10

Assembly

System programming

1

None

Strong

Degree of Typing

CSCE 431 Final Exam Review

not either or
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
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
What is Rapid Prototyping?
  • Quick assembly of a partial or complete system for experimentation prior to full requirements, specification and implementation
  • 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
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
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

outline6
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
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
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 cont1
Licensing Process (cont.)
  • Software Engineering PE Exam
    • Requirements 17.5%
    • Design 13.75%
    • Construction 11.25%
    • Testing 12.5%
    • Maintenance 7.5%
    • Configuration Management 7.5%
    • Engineering Processes 7.5%
    • Quality Assurance 7.5%
    • Safety, Security, and Privacy15%

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
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
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
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
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