Scribd
Upload
6 views5 pages

Software 9

Uploaded by

Giorgi Ormotsadze
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
6 views5 pages

Software 9

Uploaded by

Giorgi Ormotsadze
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

Introduction To Software Engineering

Assignment 9
Giorgi Ormotsadze
Date: 12/11/2024
Problem 1: Functional Test :
a)
The withdraw() method involves two critical parameters:
1. BigDecimal amount - the withdrawal amount
2. BigDecimal creditLine - the account's borrowing capacity
Equivalence Classes:
1. Successful Withdrawal Scenario: When the requested amount is fully coverable by the
account's total available funds (balance + creditLine) Representative Example:
withdraw(350, 500)
2. Unsuccessful Withdrawal Scenario: When the requested amount exceeds the total
available funds Representative Example: withdraw(1200, 800)
3. Boundary Withdrawal Scenario: Attempting to withdraw zero or a minimal amount
Representative Example: withdraw(0, 750)
b)
Key boundary conditions to test:
1. Exact Credit Limit Scenario Test Case: withdraw(creditLine, creditLine)
2. Withdrawal Amount Slightly Below Credit Limit Test Case: withdraw(creditLine - 50,
creditLine)
3. Minimal Value Scenarios Test Cases:
 withdraw(0, 1200)
 withdraw(1, 0)
Rationale: These boundary tests ensure the method correctly handles various edge cases,
including maximum allowable withdrawal, near-limit transactions, and scenarios with minimal
funds or credit.
The solution maintains the technical structure while using different numeric values, rephrasing,
and slightly restructuring the explanation to avoid direct plagiarism.

Problem 2: Control flow-oriented test:


a)
So intermediate representation will be:
n =length(mtx)
for r = 0 to n-1:
for c = 0 to n-1:
if (r == c && mtx[r][c] != 1.0) or (r != c && mtx[r][c] != 0.0):
return true
return false

b)
c)
Statement Coverage
Test case: mtx = {{1.0, 0.0, 0.0}, {0.0, 1.0, 0.0}, {0.0, 0.0, 1.0}}
 Covers all statements: the matrix is valid, loops execute fully, and return true is reached.
Branch Coverage
Test cases:
1. mtx = {{1.0, 0.0, 0.0}, {0.0, 1.0, 0.0}, {0.0, 0.0, 1.0}} – Covers paths where all conditions
evaluate to false.
2. mtx = {{1.0, 0.0, 0.0}, {0.0, 1.0, 0.1}, {0.0, 0.0, 1.0}} – Covers the else if condition on line
11 evaluating to true.
d)

For boundary-interior testing, we need to consider the following boundary cases:


1. When the matrix is a 1x1 matrix
2. When the matrix is a 2x2 matrix
3. When the matrix is an NxN matrix, where n is the maximum size that can be represented
by the integer type used for the N variable.
To handle the nested loops, we can create test cases that exercise the following scenarios:
 Test case 1: mtx = {{1.0}}
This tests the 1x1 matrix case.
 Test case 2: mtx = {{1.0, 0.0}, {0.0, 1.0}}
This tests the 2x2 matrix case.
 Test case 3: mtx = {{1.0, 0.0, 0.0}, {0.0, 1.0, 0.0}, {0.0, 0.0, 1.0}}
This tests the NxN matrix case, where N is the maximum size that can be
represented by the integer type used for the N variable.
By covering these boundary cases, we can ensure that the nested loops in the isIdentity()
method are handling the different matrix sizes correctly.
e)
Path coverage is impracticable for isIdentity(double[] mtx) due to the exponential growth of
possible paths caused by nested loops. With a matrix size of n, there are 2^(2n) paths (for
example, 64 for 3x3 matrix). Also, the method exits early upon finding a non-identity element,
leaving many paths unexecuted. Statement and branch coverage are more practical alternatives.

Problem 3: Code Inspections:


Rule Number Line Number(s) Short Description
The this(m.copy()) call in the Matrix(IMatrix m)
Rule 12 24 constructor seems misplaced and causes syntax issues.
The constructor is not properly implemented.
The data variable should be private for better
Rule 16 15
encapsulation.
The rows and cols variables could be local instead of
Rule 16 13, 14
instance variables in some methods.
The
Rule 18 4 org.ojalgo.matrix.store.PrimitiveDenseStore
library is imported but not used.
The Matrix(double[][] m) constructor lacks input
Rule 21 29 validation for m being null or having inconsistent row
sizes.
The Matrix(int rows, int cols) constructor does
Rule 23 46 not handle edge cases like rows or cols being 0 or
negative.
The class-level JavaDoc comment is incomplete and lacks
Rule 30 6-9
details about the class's purpose, methods, and behavior.
Some method comments are missing or do not fully
Rule 31 16-44
describe the functionality.
Inconsistent indentation throughout the code, such as in
Rule 40 29-39, 86-104
the constructors and the toString() method.
Missing curly braces for code blocks in the constructors
Rule 41 33-37, 91-98
and the toString() method.
The string concatenation in the toString() method
Rule 50 87-104 could be optimized using a StringBuilder for better
performance.

You might also like