MIE350 — Final Exam Review

Section I

Exam Logistics

When & Where

Date: Saturday, April 18, 2026
Time: 2:00 PM – 4:30 PM EDT
Duration: 2 ½ hours
Location: VO AUDB — St Volodymyr Institute
Address: 620 Spadina Ave
Arrive by: 1:45 PM with TCard

Format

6 long-answer questions · 100 pts
Calculator Type 4 (non-programmable)
Exam Type B (no aids except calculator)
Examiner: E. Cohen

Typical point breakdown

Q	Topic	Pts
1	UML Class Diagram	15
2	UML Sequence Diagram	14–16
3	UML Statechart	15
4	UML Activity Diagram	14–16
5	Architecture OR Short Essays	20
6	Software / Structural Testing	20

Time budget: 2.5 hrs / 100 pts ≈ 1.5 min per point. The UML questions are ~60% of the exam and draw directly from scenario text — practice sketching fast. Structural testing Q6 is always 20 pts and always includes CFG, coverage, and cyclomatic complexity.

Instructor tips from the practice exams: for coverage questions, "to receive full points, make sure your set of test cases is minimal." For activity diagram analysis, justify all your answers. For class diagrams, pay attention to subtyping cues in the scenario ("each X is either a Y or a Z").

Lecture II

Software Development Methodologies

◊ ◊ ◊

The SDLC (Software Development Life Cycle) has four phases: Planning (why + how), Analysis (who / what / where / when), Design (how the system will operate), and Implementation (construct, install, maintain). A methodology is a formalised approach to implementing the SDLC.

Structured Design

Waterfall — sequential phases with approvals. Good when requirements are well understood; bad for long gaps / inflexibility. Royce himself warned it "invites failure" if run strictly.
Parallel — high-level design divides work into parallel sub-projects, integrated later.
V-Model — waterfall variant emphasising testing. Left side: Analysis → Design → Implementation. Right side: Unit → Integration → System → Acceptance. Each analysis/design level has a matching test-design level.

Fig. 2 — V-Model: analysis/design on the left, unit/integration/system/acceptance testing on the right.

Rapid Application Development (RAD)

Iterative — series of versions, each a complete mini-waterfall. User gets value early; requirements can emerge.
System Prototyping — analysis/design/implementation concurrent; iterate with user feedback. Metaphor: prototyping = rough draft then revision; iterative = one perfect sentence at a time.

Agile

Agile Manifesto: individuals/interactions > processes/tools; working software > documentation; customer collaboration > contract negotiation; responding to change > following a plan.

Scrum roles: Dev Team (3–9), Product Owner (owns backlog), Scrum Master (coach / removes impediments).
Sprint: 1–4 weeks; Product Backlog → Sprint Planning → Sprint Backlog → Execution + Daily Scrum → Review → Retrospective → Shippable Increment.
Daily Scrum: 15 min — done / next / blockers. Burndown chart tracks remaining work. User story: "As a [role], I [want to], [so that]."
XP practices: pair programming, on-site customer, small releases, continuous integration, test-first, refactoring, collective ownership.

Selection cheatsheet: Unclear requirements → RAD / XP. High reliability → V-Model. Short schedule → Iterative / Prototyping / XP. Schedule visibility → RAD / XP.

Lecture III

Software Architecture

◊ ◊ ◊

SEI definition: the architecture is "the structure or structures of the system, which comprise software components, the externally-visible properties of those components, and the relationships among them." Two views: static (what components exist and their arrangement) and dynamic (runtime interactions and control).

Every component has

A clearly defined set of responsibilities
A clearly defined boundary
Defined interfaces (services it provides)

Externally-visible properties: functional (inputs/outputs, interfaces, response to input) and quality / non-functional (performance, security, availability, modifiability, testability, usability).

Static Architectural Styles

Layered

Layers of services; each depends only on layer below.

+ replaceable layers, localised changes, security isolation
− clean separation hard, overhead from multiple layers

Repository

Shared central data; all components read/write it.

+ efficient sharing, components independent, central mgmt
− single point of failure, schema compromise, data evolution hard

Client–Server

Services distributed over network; clients call servers.

+ distributed load, easy to add servers, networked CPUs
− unpredictable performance, each service a failure point

Pipe & Filter

Output of one component is input to the next (Unix pipes).

+ easy to understand, reusable filters, matches workflows
− must agree on format, overhead, limited reuse

Dynamic Control Styles

Centralised — Call-Return: top-down hierarchical controller, sequential systems.
Centralised — Manager: one process controls concurrent processes.
Decentralised — Broadcast: event broadcast to all; registered components respond. Good for distributed systems; sender doesn't know if/when event handled.
Decentralised — Interrupt-Driven: handler per interrupt type passes to component. Fast response; complex to validate (nuclear plant example).

Fig. 3 — Compiler architecture evolves: pipeline → pipeline-with-symbol-table → full repository (attributed parse tree + symbol table). Drivers: shared data, tool support.

Exam move: when asked to choose an architectural pattern for a scenario, name it, then state two advantages and two disadvantages specific to that scenario. The airline reservation diagram (clients with Presentation/BL/DB/Network over WAN to central DB) is client–server (thin/fat hybrid).

Lecture IV

Requirements Engineering

◊ ◊ ◊

Requirement (IEEE 610): "a condition or capability needed by a user to solve a problem or achieve an objective." Fred Brooks: "the hardest single part of building a software system is deciding precisely what to build."

Four activities

Elicitation — understanding the problem.
Specification — describing it.
Validation — agreeing on it.
Negotiation — fitting the problem to the situation.

Elicitation techniques

Interviews, JAD sessions, questionnaires, document analysis, observation.

Questionnaires — two strengths / two weaknesses

+ Reach many stakeholders at low cost. + Data is easily aggregated / quantified.
− No follow-up, so tacit knowledge and context are lost. − Low response rates and self-selection bias skew results.

Functional vs Non-Functional

Functional = a process the system must perform, OR information it must maintain (what it should / should not do). Non-functional = behavioural properties / constraints on services. Failing a non-functional can render the system unusable.

Test: Is this a specific process? Is this specific information? If both no → it's non-functional.

Non-functional taxonomy

Quality of Service: safety, security, reliability, performance, interface.
Architectural Constraint: installation, distribution.
Development Constraint: cost, maintainability.

Common pitfalls: requirements confusion (mixing F and NF); amalgamation (many in one sentence); lack of clarity ("user-friendly", "fast" — not testable). Quality requirements must be objective and measurable.

Lecture V + IX

Use Cases

◊ ◊ ◊

A use case is a step-by-step description of how an actor uses the system-to-be to achieve a goal. Each use case covers one or more functional requirements.

Use case template

Name · ID · Importance level · Brief description
Primary actor (initiator) + secondary actors
Trigger — external (customer places order) or temporal (book overdue)
Preconditions / Postconditions (chain use cases: postcondition of one = precondition of next)
Normal flow — 3 to 9 numbered steps (break larger ones into multiple use cases)
SubFlows (optional) and Alternate / Exceptional flows (non-normal paths)
Summary of inputs / outputs for every step, with source and destination

Use case diagrams

Components: system boundary (rectangle), actors (stick figures outside), use cases (ovals inside), associations (solid lines).
«include» — base ALWAYS invokes the included use case. Arrow goes from base to included. Used to factor shared functionality (e.g. Request Statement «include» Identify Customer).
«extend» — extension runs only under specific conditions. Arrow goes from extension to base (e.g. Get Help «extend» Registration).
Inheritance / generalisation — hollow triangle from child to parent. Applies to actors AND use cases.

Alternate / Exceptional flows (short-essay prompt)

Alternate flows are valid variations of the normal path that still achieve the use case goal. Exceptional flows handle failure or abnormal input (e.g. invalid credentials, system offline). Both are enumerated separately from the normal flow so that requirements tied to error handling and variation are traceable.

Traceability matrix: rows = requirements with priority weight (PW), columns = use cases, X marks coverage. Lets you (1) confirm every requirement is covered, (2) spot orphan use cases, (3) prioritise by Max PW and Total PW per use case.

Lecture V-B + V-C

Process Modelling & DFD

◊ ◊ ◊

A process model represents how a business system operates, abstracted from implementation. MIE350 uses Data Flow Diagrams (DFDs) — business processes and the data passed between them.

Four symbols

External Entity — square (often shadowed); labelled with a noun (Customer, Supplier, Inventory System). Outside the system.
Process — rounded rectangle with a number; labelled verb-adjective-noun ("Get Customer Record", "Calculate Sales Tax"). Exception: a whole-system process uses just the noun phrase.
Data Flow — arrow with single direction; labelled with a noun / adjective-noun. Two-way traffic ⇒ two arrows.
Data Store — open-ended rectangle with ID (D1, D2, …) and noun label. Any stored data (DB, file, table, manual records).

Hierarchy & numbering

Context Diagram = Process 0. Whole system as one process, external entities only, no data stores.
Level 0 — major processes (1, 2, 3). Adds data stores.
Level 1 — decompose one Level 0 process into sub-processes (1.1, 1.2, 1.3).
Level 2 — further decompose when needed (1.1.1, 1.1.2).
Continue until each process is a single-purpose primitive.

Balancing: data flows on the parent must match those on the child. Adding data flows not reflected on the parent breaks balancing and loses marks.

Common errors

Syntax: every data flow must connect to a process; every process has at least one inflow and one outflow (no "miracles" or "black holes").
Semantic: walk through with the user; verify inputs can logically produce outputs; keep decomposition levels and terminology consistent.

Lecture VI Exam Q1 — 15 pts

UML Class Diagrams

◊ ◊ ◊

Class diagrams give a static view of the system: what classes exist and how they're related. From scenario text: nouns become classes, verbs become methods, relationships between nouns become associations.

Notation

Three-compartment box: name / attributes / operations.
Visibility: + public · # protected · – private · ~ package · / derived. Underline static members. Italicise abstract class / method names.
Interface: label «interface» above the name.
Attribute syntax: visibility name: type · Operation: visibility name(params): return.

Relationships

Relationship	Arrow	Meaning
Inherits (class)	Solid line, white triangle	Is-a. Points to parent.
Inherits (abstract)	Solid line, white triangle, parent italic	Is-a, parent cannot be instantiated.
Implements (interface)	Dashed line, white triangle	Realises interface. Can implement many.
Association	Plain line + multiplicity	Uses / knows-about.
Aggregation	Line with white diamond at container	Has-part. Parts may outlive whole.
Composition	Line with filled diamond at container	Strong has-part. Parts die with whole.
Dependency	Dashed arrow, e.g. `«create»`	Uses temporarily.

Multiplicity cheatsheet

1 exactly one · 0..1 zero or one · * or 0..* zero+ · 1..* one+ · 2..4 2 to 4 · 1..3, 5 disjoint ranges.

Association class

When the association itself has attributes (e.g. Pharmacist works at Pharmacy with hoursPerWeek), attach an association class by a dashed line to the association line. The association class carries the extra attributes.

Pharmacy scenario cues (Practice Exam 1): "Each pharmacy is either public or private" → generalisation (abstract Pharmacy, subclasses PublicPharmacy / PrivatePharmacy). "Pharmacists can work for more than one pharmacy… hours-per-week" → many-to-many + association class. "Not required to stock all drugs… drugs not stocked by any pharmacy" → multiplicities 0..* on both sides of the stocks association, with a Stock association class recording units.

Lecture VI-B Exam Q2 — 14–16 pts

UML Sequence Diagrams

◊ ◊ ◊

A sequence diagram models a single scenario — the dynamic view of how objects collaborate over time.

Parts

Participant (object box): labelled objectname : Classname, underlined. Named, anonymous (: Classname), or unknown-class (objectname).
Lifeline: dashed vertical line below each participant.
Axes: horizontal = participant, vertical = time flowing downward.
Activation bar: thick vertical rectangle on the lifeline while the object is active. Nest bars for self-calls.
Found message: arrow from a filled circle, origin outside scope.

Message arrow styles

Type	Arrow
Synchronous call	Solid line, filled arrowhead
Asynchronous call	Solid line, stick arrowhead
Return	Dashed line, stick arrowhead
Create	Arrow labelled `new` into a new participant box placed lower on the page
Destroy	Large `X` at the bottom of the lifeline

Combined fragments

opt [condition] — optional block, executed if condition true.
alt [c1] / [else] — if / else; alternatives split by horizontal dashed line.
loop [condition or for each x] — repetition.
break [c] — like opt but exits enclosing sequence.
ref — reference to another named sequence diagram.

Control style signals: many short activations spreading off one object → centralised ("fork" shape). Activations chaining down objects → distributed ("stair-step" shape).

Sequence diagram recipe

Identify objects from the scenario (tip on the exam).
Place them left-to-right in interaction order.
For each step: determine caller, callee, and sync / async / return.
Wrap conditional steps in opt / alt; repeated steps in loop.
Use new / X only if the scenario clearly creates or ends objects.

Lecture VIII-A Exam Q3 — 15 pts

UML Statecharts

◊ ◊ ◊

Statecharts describe the lifetime of one object whose behaviour depends on history. A state is an interesting configuration of attributes; statecharts abstract the real state space into a manageable FSM.

Syntax

State: rounded rectangle labelled with a noun phrase.
Initial pseudo-state: filled circle.
Final state: filled circle inside a ring (bull's-eye).
Transition: solid arrow, label event [guard] / action.
Composite / nested states: states can contain sub-states with their own initial and final pseudo-states.

Four event types

Change — condition becomes true, keyword when[cond] (e.g. when[balance < 0]).
Call — object receives an operation call (e.g. Push()).
Signal — explicit real-time signal from another object.
Elapsed-time — after[10 seconds], after[>2 weeks].

Shipment scenario (Practice Exam 2): states chain Created → Verified → Collected → Checked → Shipped → Waiting-for-Delivery → Out-for-Delivery → Delivered, with side branches for Cancelled, Mismatched, Waiting-for-Client. Watch for: "two more attempts" → self-loop with counter guard; "five days to pay difference" → after[5 days] elapsed-time event; "if delivery fails… second fails" → guarded self-transitions.

Lecture VIII-B

Linear Temporal Logic

◊ ◊ ◊

LTL expresses properties of a single infinite trace. Model checking computes model ⊨ property; if false, you get a counter-example trace.

Temporal operators

Symbol	Name	Reads
`□f` / G f	Globally / henceforth	f holds in this and all future states.
`◊f` / F f	Eventually	f holds now or in some future state.
`○f` / X f	Next	f holds in the very next state.
`f U g`	Until	g eventually holds, and f holds at every state until g. Implies `◊g`.
`f W g`	Weak until / unless	f holds indefinitely OR until g. `f W g ≡ (f U g) ∨ □f`.

Compound idioms

□(◊f) — f happens infinitely often.
◊(□f) — eventually f is permanent.
□(push → ◊enter) — every push is eventually followed by enter (response / liveness).
□(locked → (locked W coin)) — stay locked until at least a coin arrives.

Turnstile pattern (per state): one "stay" formula (□(S → (S W e))) and one "transition" formula (□((S ∧ e) → ○S')). For branching: □(X → (X W (a∨b))), plus one transition formula per outgoing edge.

Lecture VIII-C Exam Q4 — 14–16 pts

UML Activity Diagrams

◊ ◊ ◊

Activity diagrams model workflows — algorithms, business processes, and concurrent execution. They do NOT show which object executes each activity; for that, use a sequence diagram.

Notation

Activity: rounded rectangle, verb-phrase label.
Start state: filled circle. End state: bull's-eye (multiple allowed).
Decision (branch): diamond, one in, multiple out; each outgoing arrow labelled with a [guard].
Merge: diamond, multiple in, one out. Does NOT synchronise — only one predecessor ran.
Fork (concurrency split): thick bar, one in, many out. Parallel branches.
Join (concurrency sync): thick bar, many in, one out. Waits for ALL incoming.
Swim lanes: columns that show who / where performs each activity (Customer / ATM / Bank).

Analysis rules (Q4 pattern)

Sequential edge A→B: on any execution that reaches B, A already occurred.
Fork branches: concurrent — no ordering guarantee between activities on different branches.
Join: all incoming branches must complete before the successor starts.
Decision: exactly one outgoing branch fires; guards are mutually exclusive and exhaustive. Activities on the NOT-taken branch do NOT occur.
Merge: only one predecessor actually executed.
Minimum activities = shortest valid path, cheapest guard choices, no loop iterations. Maximum = longest path; unbounded if loops exist.
"Can X occur after Y?" — trace forward from Y; if any reachable path hits X (via decision branches, loops, or concurrent branches not yet completed), yes.

Worked reasoning — "Will F always occur before G?"

If F is on the same sequential edge directly feeding into G (F→G with no parallel path to G), answer yes. If F and G are on different branches of a fork, answer no: they are concurrent and execution order is not constrained. If G is guarded by a decision that excludes F's branch, answer yes (trivially) when F occurs G cannot follow. Always justify by naming the specific fork / decision / sequential edge.

Lecture X + XI-A Exam Q6 — 20 pts

Software Testing

◊ ◊ ◊

"Testing can be used to show the presence of bugs, but never their absence." — Dijkstra. Testing investigates system quality with sequences of stimuli, observations, and verdicts.

Terminology

Fault — a mistake / omission in the code.
Failure — an execution that yields an incorrect result.
Test case — Initialization + Test Steps (input, oracle) + Tear Down. Independent and repeatable.
Test suite — collection of test cases executed together. Projects may have multiple suites for different needs (smoke, regression, performance).

Why multiple test suites?

Different suites serve different resource / time budgets and goals (fast smoke suite per commit, heavier integration / performance suite nightly, long-running system suite before release). Splitting lets teams get rapid feedback without waiting for the slowest tests.

Test oracles

Expected-value — hard-coded expected output for a single input, e.g. assertEquals(7, max(3, 7)). Simplest, not reusable across inputs.
Property-based — assert properties that hold for any input, e.g. a sorted list's items are non-decreasing. Reusable but less precise per test.
Implicit — check general failures: crashes, memory leaks, deadlocks, buffer overruns, poor performance. No expected output required.

False positive vs false negative

False positive = oracle says "pass" when a real fault exists (missed bug). False negative = oracle says "fail" when there is no fault (spurious alarm). A faulty oracle produces either.

Testing stages (V-Model)

Unit — smallest testable piece (class + methods), isolated with mocks/stubs. Highly automated.
Integration — modules working together.
System — whole system through real interfaces.
Acceptance / Alpha / Beta — controlled users against formal criteria. Often human-driven.

Black box vs white box

Functional (black box): derive tests from requirements / docs / intuition. What the code should do. Allows test-driven development.
Structural (white box): derive tests from the code itself, usually to satisfy an adequacy criterion (e.g. branch coverage). Oracles still come from requirements.

The two are complementary — structural testing fills gaps in functional tests.

Structural testing: CFG

Control Flow Graph: nodes = basic blocks / statements, edges = possible flow of control.
if-then-else: node for condition splits into two branches that merge.
while / for: condition node has a true branch returning back above it, and a false branch exiting.
switch: one node with many outgoing branches, merging at the end.
Every test execution corresponds to a path through the CFG.

Coverage criteria

Statement coverage: every statement executed by at least one test.
Branch (decision) coverage: every branch from every decision taken (both true and false paths).
Path coverage: every unique path executed — infeasible with loops.
Condition coverage: each boolean sub-expression evaluates true and false.

Subsumption: criterion A subsumes B iff every test suite that achieves 100% A also achieves 100% B. Branch coverage subsumes statement coverage (executing every branch visits every statement). Statement coverage does NOT subsume branch — an if with no else can be 100% statement but not 100% branch.

"Minimal" test case design (scored on the exam)

After you list each test case, walk through the CFG and mark every statement / branch each test covers. Then justify that removing any test breaks 100% coverage. Examiner marks off if a suite has redundant cases.

Lecture XII-A Always on Q6

Cyclomatic Complexity

◊ ◊ ◊

McCabe's cyclomatic complexity V(G) counts the number of linearly independent paths through a program's control flow graph. It is an upper bound on the number of test cases needed for branch coverage.

Three equivalent formulas

V(G) = E − N + 2 (edges minus nodes plus 2) V(G) = P + 1 (decision points + 1) V(G) = number of regions (in a planar CFG)

where E = edges, N = nodes, P = decision points (predicates). For an && or || inside a condition, each short-circuit boolean operator counts as an additional decision point.

Fig. 4 — V(G) = E − N + 2 · independent paths through the CFG.

Worked example — `findMax(a,b,c)`

int findMax(int a, int b, int c) { int temp; if (a > b) temp = a; else temp = b; // decision 1 if (c > temp) temp = c; // decision 2 return temp; }

CFG has 2 decisions ⇒ V(G) = 2 + 1 = 3. Verify: nodes = 6 (entry, cond1, temp=a, temp=b, cond2, temp=c, return — merge handled), edges = 7. V(G) = 7 − 6 + 2 = 3. ✓

Risk thresholds (McCabe)

1–10 — simple, low risk · 11–20 — moderate · 21–50 — complex, high risk · 50+ — untestable, refactor.

On the exam: always show the computation. Draw the CFG, count E / N / P, and state the formula you used. A correct number with no justification loses marks.

Practice Exam

Final Exam — 6 Questions · 100 Points

◊ ◊ ◊

Based on MIE350 Practice Finals #1 and #2. Scenarios are from the real practice exams; click "Show Answer" for a model response. For the UML questions, an answer outline replaces the drawn diagram.

Q1. UML Class Diagram — Pharmacy Association

15 pts

"Create a class diagram that describes the classes and their relationships based on the following scenario description for the pharmacies information system."

Pharmacy: unique number, name, address. Either Public (govt license number) or Private (owner name, address).
Each pharmacy employs Pharmacists (license number, expiration) and Administrative Staff (role). Both inherit from Employee (first name, last name, unique ID).
Pharmacists can work for multiple pharmacies with different hours-per-week per pharmacy. Administrative staff work for one pharmacy full-time.
Each pharmacy stocks a range of drugs (not required to stock all; drugs may be unstocked). Drug = common name, unique code, manufacturer. System records units in stock per pharmacy.

Q2. UML Sequence Diagram — Art Gallery Order

16 pts

Customer searches the gallery, adds paintings to cart, and checks out for delivery or pickup. For delivery: payment details + address, painting marked "ordered", confirmation number. For pickup: painting marked "reserved", reservation number.

Q3. UML Statechart — Quiz Object (Undergrad Office)

15 pts

Quiz uploaded → plagiarism check → if detected, professor reviews and records mark; if not, TA records mark. Marks posted on Quercus → 7-day appeal window. If no appeal, final; if appeal, professor reviews and records final mark.

Q4. Activity Diagram Analysis

14 pts

Given an activity diagram with a top fork into two concurrent branches. Left branch has a sequential activity A on one path and a decision leading to B or B→C→D on the other. Right branch has E, a decision to F or G (with G nested under F), and H. Branches join at the end.

a. F before G? b. C after D? c. F implies H? d. A and E both occur? e. A then C possible? f. min activities? g. max activities?

Q5. Architecture & Short Essays

20 pts

a. Choose an architectural pattern for a personal health app with sensors + analysis components; justify. b. Pattern for a photo-editor with a chain of filters; justify. c. Identify pattern in the airline reservation diagram (clients ↔ WAN ↔ central DB) with advantages / disadvantages.

Q6. Unit Testing — `findMax(a,b,c)`

20 pts

int findMax(int a, int b, int c) { int temp; if (a > b) temp = a; else temp = b; if (c > temp) temp = c; return temp; }

a. Expected-value oracles for (1,5,2), (1,5,5), (1,1,1). b. Draw CFG. c. Minimal test set for 100% statement coverage. d. Minimal test set for 100% branch coverage. e. T/F: branch coverage guarantees statement coverage. f. Compute cyclomatic complexity.

Q6-alt. Testing — `doSomething(x, y)` (Practice #2)

20 pts

int doSomething(int x, int y) { if (y > 0) print("y is positive"); while (y > 0) { if (x > 0) y = y - x; else x = x + 1; print("loop"); } return x + y; }

a. Draw CFG. b. Minimal set giving 100% statement but NOT 100% branch coverage. c. Minimal set giving 100% branch coverage. d. Cyclomatic complexity. e. What does "A subsumes B" mean?

Model Answer

a. CFG: entry → D1 (y>0): T → print(pos); both paths merge at D2 (y>0, loop head). D2=T → D3 (x>0): T → y=y-x; F → x=x+1; merge → print("loop") → back to D2. D2=F → return x+y → exit.
b. Statement but not branch — 1 test: (x=2, y=3). Execution: y>0 true, prints pos; enters loop, x>0 true, subtracts; loops until y≤0, then exits. Every statement executed but D3 false branch (x=x+1) never taken → branch coverage < 100%. Actually this misses x=x+1 statement too. Better single test: (x=−1, y=2) enters loop, x>0 false, hits x=x+1 repeatedly, then when y>0 fails exits. But misses y=y-x. To cover every statement you need both branches of D3, so minimum = 2 tests for statement coverage. One accepted answer: (x=2, y=3) + (x=−5, y=2, exits after x becomes 0) covers all statements but if in the second case D1 is skipped we don't hit print(pos). The intended minimal answer is (x=2, y=3): this hits every statement except x=x+1 — so strictly we need a second case, and both achieve branch coverage anyway. Practical accepted answer: single test (x=2, y=3), acknowledging it misses the else-branch of the inner if, which demonstrates the "statement yes, branch no" gap if we ignore the else branch's statement. (On the real exam, state your assumption about whether the else statement counts.)
c. Branch coverage — 2 tests: T1 = (x=2, y=3) drives D1=T, D2=T(loop runs), D3=T. T2 = (x=−1, y=0) drives D1=F (skips print) and D2=F (skips loop). Still missing D3=F; replace T2 with (x=−1, y=2) which keeps D2=T and takes D3=F via x=x+1, and also hits D1=T. Add a third test (x=0, y=0) for D1=F and D2=F. Minimum = 3 tests.
d. V(G) = P + 1 = 3 + 1 = 4. Three decision points: outer if, while, inner if. Verify: E−N+2 on the CFG (roughly 11−9+2) = 4. ✓
e. "A subsumes B": any test suite achieving 100% A also achieves 100% B. Branch coverage subsumes statement coverage.

Study Checklist

Track Your Review

0 / 14 complete

MIE350Design & Analysis of Information Systems

Exam Logistics

Course Topics

Software Development Methodologies

Structured Design

Rapid Application Development (RAD)

Agile

Software Architecture

Every component has

Static Architectural Styles

Dynamic Control Styles

Requirements Engineering

Four activities

Elicitation techniques

Functional vs Non-Functional

Non-functional taxonomy

Use Cases

Use case template

Use case diagrams

Process Modelling & DFD

Four symbols

Hierarchy & numbering

Common errors

UML Class Diagrams

Notation

Relationships

Multiplicity cheatsheet

UML Sequence Diagrams

Parts

Message arrow styles

Combined fragments

UML Statecharts

Syntax

Four event types

Linear Temporal Logic

Temporal operators

Compound idioms

UML Activity Diagrams

Notation

Analysis rules (Q4 pattern)

Software Testing

Terminology

Test oracles

Testing stages (V-Model)

Black box vs white box

Structural testing: CFG

Coverage criteria

Cyclomatic Complexity

Three equivalent formulas

Worked example — findMax(a,b,c)

Final Exam — 6 Questions · 100 Points

Q1. UML Class Diagram — Pharmacy Association

Q2. UML Sequence Diagram — Art Gallery Order

Q3. UML Statechart — Quiz Object (Undergrad Office)

Q4. Activity Diagram Analysis

Q5. Architecture & Short Essays

Q6. Unit Testing — findMax(a,b,c)

Q6-alt. Testing — doSomething(x, y) (Practice #2)

Track Your Review

MIE350
Design & Analysis of Information Systems

Worked example — `findMax(a,b,c)`

Q6. Unit Testing — `findMax(a,b,c)`

Q6-alt. Testing — `doSomething(x, y)` (Practice #2)