CSCE 431 Lecture 22

« previous | Thursday, April 24, 2014 | next »

End Exam 2 content

Wednesday, May 7, 8:00–10:00 am

Covers

• interfaces and contracts through licensing and SE code of ethics.
• homework 3
• focus on material covered in slides
• assigned reading are background material

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

Object Design

purpose:

• Take system model and map it to implementation model
• Transform system model for better implementability, extensibility, performance

Explore ways to implement system model Result should match structure of implementation.

Activities

• Reuse: identify and adapt existing solutions (off-the-shelf components, libraries, design patterns)
• Interface Specification: specs of each class interface and APIs of subsystems
• Object model restructuring: improve some characteristics (extensibility, understandability, etc.)
• Object model optimization: greater speed, lower memory use, etc.

Executive Summary

• UML Models can be gradually refined to include more details about interfaces
• UML+OCL: notatinos and language to express contracts (pre/post conditions, invariants) in UML
• Interesting part is that constraints that span multiple classes (constraints over associations)

Access Control Guidelines

Expose as little as possible, but "basis" should be complete and efficient.

• Less exposed, more freedom to change class implementation.
• Fewer things to learn and document.

Access attributes only via getter and setter operations (except when no class invariants)

Hide substructures

• Do not apply an operation to the result of another operation.
• Write a new operation that combines two operations
• Law of Demeter

Law of Demeter

Method $M$ of object $O$ may only invoke methods of:

• $O$ itself
• $M$'s parameter
• any objects instantiated within $M$
• $O$'s direct component objects
• Global variables accessible by $O$ in the scope of $M$

Example violation: x.y.foo().bar()

Contracts and Formal Specification

Contracts enable caller and provider to share the same assumptuons about the class

A contract is an exact specification of the interface of an object

Contract includes 3 types of constraints:

• invariant: predicate that is always true for all instances of a class
• pre-conditions (rights): predicate that holds true before running
• post-conditions (obligations): predicate that holds true after running

Models to Implementation

Example: 3 different types of users, all of whom have an email address, can be abstracted to subtypes of a User

Mapping concepts:

• model transformations: improve compliance of the object design model with design goal
  (model space → model space)
• forward engineering: consistent transformation of models to code
  (model space → source code)
• Refactoring: preserve semantics, improve readability/modifiability
  (source code → source code)
• Reverse engineering: extract design from code.
  (source code → model space)

Model transformations and forward engineering techniques:

• Optimizing within class model
• mapping associations to collections
• mapping contracts to exceptions
• mapping class model to storage schemas

API Design

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 power to satisfy requirements
• Easy to extend
• Appropriate to audience

Eat your own Dog Food

Write to your API early and often:

• even if not yet implemented
• even if not yet fully specified.

Avoid wasted implementation and specification effort.

This code lives on as unit tests and example uses (in documentation)

Expect the API to evolve

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

Interface

• Simple
• General
• Regular
• Predictable
• Robust
• Adaptable

Broad Issues to Consider

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

Abraham's Categorization

(If a bad thing happens, maintain invariants and don't lose data)

• Basic guarantee: invariants conserved, no resources leaked
• Strong guarantee: operation has either completed successfully or thrown an exception, leaving program state exactly as it was before the operation started.
• No-throw guarantee: operation will not throw an exception

Testing

Fault avoidance and Detection

Static Analysis

• hand execution: reading source code
• walk-through (informal presentation to others)
• code inspection (formal presentation to others)
• automated tools for checking syntax and semantic errors, departing from coding standards.

Dynamic Analysis

• block-box testing (test input and output behavior)
• white-box testing test internal logic of the subsystem or class)

Test Categorization

• Unit Testing
• Integration Testing
• System Testing
• Reliability Testing
• Stress Testing
• Acceptance Testing

Verification vs. Validation

Validation: Are you building the right thing?
Verification: Are you building it right?

Acceptance testing is about validation, everything else is verification

Test Categorization by Intent

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

Goal: Partition Testing

Cannot test all possible data, so we partition input data into equiv. classes:

• Obviously bad data
• Obviously good data
• Borderline good/bad data (just inside/outside)

Test should succeed (or fail) the same for all elements in the class.

Test at least one from every class.

Mock Objects

Objects that fit in where implementation might be lacking.

Simulate part of behavior of another object (or objects)

Useful in situations where real objects

• could provide non-deterministic data
• real objects are hard to reproduce
• etc.

White Box Testing

Assess effectiveness of test suite, measure how much of the program it exercises

Concretely:

1. choose kind of program element (e.g. instructions, or control paths
2. Count how many are executed at least once)
3. report as coverage percentage

A test suite that achieves 100% coverage achieves chosen criterion.

Coverage Criteria

• Instruction (or statement) coverage: Measure instructions executed
• Branch Coverage: make sure all cases executed
• Condition Coverage:
• Path Coverage:

p-use: predicate use (branch control flow)

c-use: computation use (performing computation)

all-defs

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

all-p-uses

execute at least one def-clear sub-path from every definition of every variable to every reachable p-use of that variable.

all-c-uses

..

Testing the Tester

Inject faults to see if tests catch errors

Code Reviews

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 budget costs of up to 40%

Review 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 reviews.

Program Properties

Hoare triples: $\left\{P\right\}\ A\ \left\{Q\right\}$, where

• $A$ is program fragment
• $P$ and $Q$ are predicates
• If $A$A is started in any state that satisifies $P$, then $A$ will terminate, and $Q$ will be satisfied.

Rules

Inference: consequence and conjenctions

Language-specific:

• skip
• abort
• assignment
• conditional
• composition
• while (loop invariant)

Scripting Languages and Rapid Prototyping

High-level language: write less code, but do more stuff with the code

Used for:

• one-time tasks
• customizing administrative tasks
• Simple or repetitive tasks
• Extension languages: control execution of an application; programmatic interface to graphical application (e.g. elisp in emacs)

Classes of Scripting

• Web browser: PHP, Javascript
• Extension: Lua, Tcl, VBA
• GUI: JavaFX, Tcl/Tk
• String Processing: Awk, Sed
• OS Scripting: Shell

vs. System Languages

(e.g. C, C++, Java)

Designed for building structure for performant execution

Rapid Prototyping

Quick assembly of a partial of complete system for experimentation prior to full requirements, specification, and implementation.

Agile Programming

• Build system using "final" technology
• Each iteration is a working system, but with gradually added features

Licensing and Ethics

Licensing Process

• Earn 4 year programming degree from ABET-accredited univ.
• Pass Fundamentals of Engineering (FE) exam
• Complete 4 years of progressive engineering experience under a PE, keep a journal
• 3 Confidential references familiar with work record
• Pass Principles and Practice of Engineering (PE) exam

Software Engineering Body of knowledge (SWEBOK) exam

SE Ethics principles:

1. Public: act consistently with public interest
2. Client and Employer: best interests of client and employer consistent with public interest
3. Product: product meet highest professional standards possible
4. Judgment: engineers shall maintain integrity and independence in professional judgment
5. Management: managers shall promote ethical approach to managing software development
6. Profession: engineers shall advance integrity and reputation of profession consistent with public interest
7. Colleagues: Engineers shall be fair and supportive of colleagues
8. Self: Software engineers shall participate lifelong learning regarding the practice of their profession.