ECE 30861/46100: Software Engineering 1 Software

Validation asks for sufficient evidence, not certainty 4 Validation does not demand certainty.
It asks whether the available evidence justifies acting under the remaining uncertainty. Software is updatable.
Sometimes it is right to deliver under known uncertainty,
then observe, and repair. But an update repairs the software,
not its past consequences.
It cannot recover lost money or reverse an injury. What uncertainty can we responsibly carry through this delivery?<br>

Claims become more precise toward implementation 5 Requirements
world outcomes Specification
machine obligations Architecture + Design system subsystem mechanism Implementation A chain of models growing more precise, not a schedule of phases. A submitted payment shall cause at most one charge.
Validation inherits its claims from these models. Customer is charged at most once for one payment Payment service suppresses duplicates Idempotency component catches duplicates Record payment ID before charging provider lookup ID → record ID → charge provider<br>

Why not just test the whole system? 6 THE OBVIOUS STRATEGY
Assemble the service; verify at most one charge appears. client API payments ledger provider The test failed. Where is the defect? Any component — or any interaction — could be responsible. LOCALIZE
The failure names a symptom, not a part. REPRODUCE
Timing, state, and environment may not repeat on demand. DIAGNOSE
The further the observation from the fault, the more it costs to explain. So engineers seek evidence at multiple scopes. System evidence is realistic and expensive to act on.<br>

One claim, several scopes of evidence 7 SPEC: a submitted payment shall cause at most one charge. LOCAL Does the idempotency component reject a duplicate payment ID? COMPOSITION When client retry and server retry interact, can one payment be submitted twice? SYSTEM Can one submitted payment ever produce two charges at the boundary? WORLD Under the provider’s actual semantics, can the customer still be charged twice? Some properties exist only in composition — and only world evidence can expose a false assumption. Check at the lowest scope that can establish it but no lower.<br>

The V: models and evidence at matching scopes 8 Requirements Specification Architecture + Design Implementation Acceptance System Integration Unit Unit, integration, system, acceptance name
scopes of evidence, not mechanisms. MODELS / CLAIMS EVIDENCE SCOPES<br>

Three ways to obtain evidence 9 HUMAN
JUDGMENT Interpret an artifact
finite attention 👁 REASONING OVER
POSSIBLE BEHAVIOR Analyze a representation
model limits 🗺 OBSERVING
EXECUTION Run and observe
selected executions ▶ Mechanism and scope are independent choices.
A unit, a subsystem, or the whole system can be
judged, reasoned about or executed. Three ways engineers come to know things about software.<br>

Three ways to obtain evidence 10 HUMAN
JUDGMENT Interpret an artifact
finite attention 👁 REASONING OVER
POSSIBLE BEHAVIOR Analyze a representation
model limits 🗺 OBSERVING
EXECUTION Run and observe
selected executions ▶ Mechanism and scope are independent choices.
A unit, a subsystem, or the whole system can be
judged, reasoned about or executed. Three ways engineers come to know things about software. NOW ▼<br>

Which one is different? 11 Row 2, column 3 — the JP2 link is missing. Twelve boards. One is different. Ten seconds.<br>

Now find the defect 12 RULE: record the payment ID BEFORE charging the provider. 1 def submit_payment(req: PaymentRequest) -> Receipt: 2 idem = req.idempotency_key 3 log.info("payment.submit id=%s amount=%s", idem, req.amount) 4 5 if not auth.may_initiate(req.user, req.account): 6 raise Forbidden("user may not initiate payments") 7 if req.amount <= 0 or req.amount > ACCOUNT_LIMIT: 8 raise InvalidAmount(req.amount) 9 10 with ledger.lock(req.account): 11 prior = ledger.find_charge(idem) 12 if prior is not None: 13 metrics.incr("payment.duplicate_suppressed") 14 return prior.receipt 15 16 receipt = provider.charge(req.account, req.amount, idem) 17 ledger.record_charge(idem, receipt) 18 ledger.commit() 19 20 metrics.observe("payment.latency_ms", clock.elapsed_ms()) 21 log.info("payment.ok id=%s ref=%s", idem, receipt.provider_ref) 22 return receipt Lines 16–17 are inverted — charged first, recorded second; a crash between them charges twice. One procedure. One rule, stated above. Twenty seconds.<br>

🧙 MAGE Moment: attention does not scale 13 12 artifacts · 1 defect 10,000 artifacts · ? At volume, “a human reviews everything”
stops being credible assurance. AIRPORT SECURITY SCREENING
Humans miss rare targets in consequential real-world inspection.
Trained screeners are covertly tested against planted threats: inspection is capacity-limited.
GAO-19-374 (2019) RARE-TARGET SEARCH
Rare targets are disproportionately missed in visual search.
Wolfe et al., Nature (2005) Human review is valuable, but attention is not a reliable exhaustive search mechanism.
Spend human judgment where judgment is required. Not that humans are bad validators, but attention is finite.<br>

Three ways to obtain evidence 14 HUMAN
JUDGMENT Interpret an artifact
finite attention 👁 REASONING OVER
POSSIBLE BEHAVIOR Analyze a representation
model limits 🗺 OBSERVING
EXECUTION Run and observe
selected executions ▶ Mechanism and scope are independent choices.
A unit, a subsystem, or the whole system can be
judged, reasoned about, or executed. Three ways engineers come to know things about software. NOW ▼<br>

Reasoning over possible behavior 15 THE REPRESENTATION
an abstraction or an explicit model
of what the software can do THE CONCLUSION
what can or cannot happen in it
over every behavior it represents Every formal technique chooses:
representation · behaviors · property · assumptions · bounds ABSTRACT STATIC ANALYSIS
reasons over an abstraction of possible program behavior MODEL CHECKING
searches the behaviors an explicit model admits — often within stated bounds Not a rigid taxonomy — a conceptual comparison for this course. The next slides take these in turn. The conclusion is limited by the representation and its assumptions.<br>

Static analysis tracks what can be true at each point 16 x = request.amount
if x > ACCOUNT_LIMIT:
reject()
charge(x) THE QUESTION
Can charge(x) be reached with x > ACCOUNT_LIMIT? x = ? x > ACCOUNT_LIMIT ? yes no reject() x ≤ ACCOUNT_LIMIT charge(x) WHAT THE ANALYZER KNOWS At entry
x ∈ all possible amounts After the false branch
x ≤ ACCOUNT_LIMIT At charge(x)
x ≤ ACCOUNT_LIMIT No path in the abstraction permits it. Sets of possibilities are propagated, without execution.<br>

What analysis inherits from abstraction 17 THE COST OF ABSTRACTION
Startup validates the config file, so loadConfig() never returns null yet the analyzer reports “possible null dereference.” REAL PROGRAM BEHAVIORS abstraction POSSIBLE BEHAVIORS SEEN BY THE ANALYZER some impossible behaviors may remain What can we conclude about the real program
from what we proved about the abstraction?<br>

Model checking searches modeled behavior 18 assert(balance >= 0); MODEL + PROPERTY
the behavior we chose to represent
and the property it must satisfy SYSTEMATIC SEARCH
explore the model’s state space
up to bound k
↓ two outcomes COUNTEREXAMPLE FOUND
a trace that violates the property NONE FOUND
no violation within the model and bound model · assumptions · semantics · bound define the claim Mars: ~45K lines of C → a ~1.6K-line verification model;
model checking joined routine regression testing (Holzmann, CACM 2014) We found no counterexample up to depth k.
What have we established?<br>

Three ways to obtain evidence 19 HUMAN
JUDGMENT Interpret an artifact
finite attention 👁 REASONING OVER
POSSIBLE BEHAVIOR Analyze a representation
model limits 🗺 OBSERVING
EXECUTION Run and observe
selected executions ▶ Mechanism and scope are independent choices.
A unit, a subsystem, or the whole system can be judged, reasoned about, or executed. Three ways engineers come to know things about software. NOW ▼<br>

Observing execution (Testing) 20 PICK INPUTS RUN OBSERVE ORACLE SIMULATION BUYS
speed · repeatability · controllability · cost FIDELITY BUYS
evidence under the actual delivery conditions SIMULATED REAL A test cannot establish behavior that depends on what its environment omitted. THINK · PAIR · SHARE
Statement and condition coverage both reached 100%. What have we established — and what have we not? What can executions we observed tell us about executions we did not observe?<br>

Stretch break 21<br>

Choosing Evidence 22 HUMAN
JUDGMENT REASONING OVER
POSSIBLE BEHAVIOR OBSERVING
EXECUTION what we already established We have ways to obtain evidence.
Now: which evidence should we seek? STRATEGY → STRENGTH → SUFFICIENCY<br>

Testing requires an oracle 23 AN INPUT RUN IT AN OUTPUT IS IT CORRECT? generating an execution — often cheap the oracle — the hard part WHEN WE CAN STATE THE ANSWER
sort([3,1,2]) must be [1,2,3]
Duplicate payment → rejected WHEN WE CANNOT

The right machine code?
The right rendering? Ranking? A testing strategy determines two things:
WHERE we search · WHAT ORACLE makes failure observable An execution is evidence only when something can say it was wrong.<br>

Properties let us search beyond known answers 25 EXAMPLE-BASED PROPERTY-BASED Known input → known answer.
You state the answer. sort([3,1,2])
→ [1,2,3] one case, one answer State what must remain true → generate inputs → search for a counterexample. ORIGINAL x rotate 90° ROTATED T(x) f y f y′ PROPERTY
Detecting edges and rotating should commute
edge(rotate(x)) = rotate(edge(x)) Instead of stating every correct answer,
state a property that many executions must satisfy.<br>

Weak self-oracles enable enormous search 26 SEED INPUTS MUTATE RUN CRASH · HANG · ASSERTION ✕ ✕ ✕ the inputs nobody wrote down — and the failures they reach A weak oracle enables enormous search.
“Did it crash?” needs no expected answer,
so, we can afford millions of runs. Cheap robustness evidence, little about functional correctness. “fuzzing”<br>

Another implementation can become the oracle 27 THE SAME INPUT IMPLEMENTATION A
the one we are validating IMPLEMENTATION B
reference · older version output A output B = ? AGREE — weak signal
both can be wrong the same way DISAGREE — at least one is wrong
you have a lead WHERE MUST THEY AGREE?
MUST, not MAY
RFC 2119 When answers are costly, compare independent realizations. “differential testing”<br>

Different strategies expose different failures 28 Example-based known answers; cases you understand Property-based known properties; counterexample search Fuzzing self-failures; crash · hang · assertion Differential another implementation as the oracle WHAT YOU ALREADY KNOW answers example-based properties property-based almost nothing fuzzing Choose the strategy for the uncertainty you need to reduce. A strategy changes how you search not how strong evidence is.<br>

Evidence strength has dimensions 29 PROPERTY METRIC MEASUREMENT EVIDENCE JUDGMENT Coverage how much did we examine? Detection power would we notice the failure? Representativeness did we examine the right conditions? Independence could one mistaken assumption undermine it all? Residual uncertainty what remains unresolved? Strength is not one number. It has dimensions.<br>

Does more data give us more confidence? 30 SCENARIO A
5 tests
5 passed SCENARIO B
5,000 tests
5,000 passed THINK · PAIR · SHARE
Which gives you more confidence in the claim? How much more? Suppose each test has an independent 1% chance of exposing the defect, if the defect exists.
If the defect exists, what is the probability that all n tests miss it? P(all miss) = (1 − 0.01)n = 0.99n
n = 5:   0.995 ≈ 95.1%
n = 5,000:   0.995000 ≈ 1.5 × 10−22 Now suppose all 5,000 tests were generated from the same mistaken interpretation of the requirement. WRONG INTERPRETATION T1 T2 … T4999 T5000 All 5,000 pass.
What assumption made our calculation valid? ONE INTERPRETATION 5,000 tests vs TESTS MODEL CHECK REVIEW different assumptions / failure modes CLAIM Strong validation combines evidence with different assumptions and failure modes. Independence. Each test had to provide a separate chance of exposing the defect.
With correlated tests, P(all miss) does not necessarily shrink like 0.99n.<br>

“Enough” depends on consequence, margin, containment 31 Evidence is judged against consequence.
The same residual uncertainty may be acceptable for a scratchpad and unacceptable for a medical device. QUANTITATIVE: MARGIN Specification: p99 ≤ 500 ms
measured 420 ms → observed margin
measured 499 ms → almost no margin DISCRETE: CONTAINMENT authorization bypass · duplicate charge · unexpected state
FAULT → CONTROL BOUNDARY → contained
permissions · isolation · transactions · quotas · timeouts · rollback Where margin cannot be measured, containment is the engineering answer. For quantitative uncertainty, ask how much margin remains.
For discrete behavior, ask how far failure may propagate.<br>

What should we do now? 32 THE EVIDENCE ON THE TABLE
Property tests pass. Load model predicts p99 < 500 ms.
Production workload untested. One rare double-charge reported.
Consequence: real money. No transaction limit, no rollback. DELIVER GATHER MORE CHANGE REVISIT UPSTREAM REFUSE Justify from: claims covered · strength · representativeness · independence · margin · containment · consequence Which action follows from what we now know?
Validation outputs a justified engineering action, not a score.<br>

The Assurance Case 33 CLAIMS Payment charged at most once · p99 latency ≤ 500 ms EVIDENCE property tests · model checking · load model · measured result · operational evidence JUDGMENT How strong? What assumptions remain? What margin? What containment? What consequence? ACTION deliver · gather more · change the system · revisit upstream · refuse THE REUSABLE QUESTIONS
What is at stake?
What must be true?
Where must evidence attach?
How can we obtain it?
How strong is it?
Is it enough to act? The argument we promised at the start — now populated with the payment example. An assurance case makes that reasoning inspectable.<br>