Computer Science 9618/22 — May/June 2022

Background Concept

When a program is being tested in an IDE, the programmer often uses debugging tools to pause execution and inspect what is happening inside the program. A breakpoint is a marker placed on a particular line or instruction so that, when the program reaches that point, execution stops automatically.

This is useful because the programmer can then check values stored in variables, follow the path taken through the code, and see whether the program is behaving as expected.

Understanding the Question

The question describes a programmer who wants the program to stop at a specific instruction or statement so they can check the value of a variable.

The key clue is the phrase "stop when it reaches a specific instruction or program statement". That is the standard description of a breakpoint in debugging.

Approach

This is a terminology recall question. The method is simply to recognise which IDE feature matches the description.

• It is not asking for a type of error.
• It is not asking for a test method.
• It is asking for the name of the position where execution is paused.

That term is breakpoint.

Step-by-Step Reasoning

A programmer places a marker at a chosen line in the code.

When the program runs and reaches that line:

• execution pauses
• the programmer can inspect variable values
• the programmer can step through the code from that point if needed

The technical term for that stopping position is a breakpoint.

Key Takeaways

• A breakpoint is used during debugging to pause a program at a chosen statement.
• It helps the programmer inspect values and track logic errors.
• IDEs provide breakpoints as a standard testing and debugging tool.

Common Mistakes

• Writing debugging instead of breakpoint. Debugging is the whole process, not the specific stop position.
• Writing trace or trace table. A trace table is a manual testing aid, not an IDE stopping point.
• Writing syntax error or another error type. The question is about a debugging feature, not an error.

Things to Be Careful About

• The question asks for the position at which the program stops, so the answer must be the specific term breakpoint.
• Do not give a sentence about what it does if only the term is required.

Background Concept

The program development life cycle breaks software creation into stages so that a problem can be solved in a planned and structured way. At this level, the main stages are usually:

• Analysis: finding out what the user or customer needs
• Design: planning the solution, including algorithms, structures and identifier tables
• Coding: writing the program in a programming language or pseudocode form
• Testing: checking whether the program works correctly and finding errors

Different activities belong naturally to different stages.

Understanding the Question

You are given four activities and must write which life cycle stage each one belongs to.

The activities mention:

• producing an identifier table
• syntax errors occurring
• discussing requirements with the customer
• producing a trace table

So the task is not to describe the stages, but to match each activity to the correct stage.

Approach

The best way is to think about what happens in each stage:

• If the customer is being asked what they want, that is analysis.
• If the solution is being planned or documented, that is design.
• If source code is being written and syntax errors appear, that is coding.
• If the program or algorithm is being checked with test methods such as trace tables, that is testing.

Step-by-Step Reasoning

1. An identifier table is produced.

An identifier table is part of planning the program. It lists variables, constants or other identifiers and details about them, such as type and purpose. That makes it part of the design stage.

2. Syntax errors can occur.

A syntax error happens when the code breaks the rules of the programming language or pseudocode format. This occurs while writing the program, so it belongs to coding.

3. The developer discusses the program requirements with the customer.

This is where the developer finds out what the system needs to do. That is the analysis stage.

4. A trace table is produced.

A trace table is used to step through an algorithm or program and check variable values and logic. That is a testing activity.

So the completed matches are:

• identifier table → Design
• syntax errors → Coding
• requirements discussion → Analysis
• trace table → Testing

Key Takeaways

• Analysis is about understanding requirements.
• Design is about planning the solution.
• Coding is where syntax errors arise.
• Testing includes tools such as trace tables.

Common Mistakes

• Putting identifier table under analysis. The requirements are gathered in analysis, but the identifier table is part of planning the solution, so it is design.
• Putting trace table under design. A trace table is mainly used to check behaviour, so it is classed as testing here.
• Confusing coding and testing. Syntax errors are associated with writing code, not with later checking logic.
• Writing stages like implementation or maintenance if those are not the best match for the given activity.

Things to Be Careful About

• Use the standard stage names expected in the syllabus: Analysis, Design, Coding, Testing.
• Match the activity to the stage where it most naturally belongs.
• For exam questions like this, one clear stage is expected for each row, so avoid giving combined answers such as design/testing.

Background Concept

An identifier table is a design document used to record information about the identifiers in a program. Identifiers include names such as variables, constants, arrays and subprograms.

The table helps the programmer keep the program organised and reduces errors by clearly recording what each identifier is for.

Typical information in an identifier table includes:

• identifier name
• data type
• purpose or description
• initial value
• size or length
• valid range

Understanding the Question

The question already tells you that the table includes the names of identifiers. It asks for two other pieces of information that should be included.

So you must not repeat name. You need two additional valid fields.

Approach

Choose two standard items that are commonly found in an identifier table. The safest answers are:

• data type
• description/purpose

These are widely accepted and directly useful when designing a program.

Step-by-Step Reasoning

If a programmer only has the identifier name, that is not enough to understand how the identifier should be used.

For example, they also need to know:

Data type

This tells whether the identifier stores an integer, real, string, Boolean and so on. That matters because different operations are valid for different data types.

Description / purpose

This explains what the identifier is used for in the program. Without this, a name alone may not make the intended use clear.

Therefore, two correct extra items are:

• data type
• description or purpose

Key Takeaways

• An identifier table is part of the program design documentation.
• It records more than just names.
• Common fields include data type and purpose.

Common Mistakes

• Repeating name of identifier, which the question has already given.
• Giving vague answers like value without making it clear what information the table stores.
• Listing something that is not really identifier-table information, such as algorithm or flowchart.

Things to Be Careful About

• The question asks for two other pieces of information, so give exactly two clear items.
• Use standard design-table terms such as data type and description/purpose.
• If you choose alternatives such as initial value or range, make sure they are clearly stated as fields in the table.

Background Concept

This question is about checking whether pseudocode statements are valid according to the functions and operators listed in the exam insert.

To do that, you need to know three things:

1. Expressions must use compatible data types

   • numeric values should be compared with numeric values
   • string values should be used where string parameters are expected

2. Built-in functions have specific parameter requirements

   • for example, a function that expects a string should not be given a number
   • a function designed for a single character should not be given a whole string

3. Some statements may be perfectly valid even if they look unusual

   • for example, a Boolean expression can be assigned directly to a Boolean variable

Understanding the Question

You are given four separate pseudocode statements. For each one, you must either:

• state what the error is, or
• write NO ERROR if the statement is valid.

The question also says you may assume that none of the variables referenced are of an incorrect type. That means you should not invent type errors for variables such as Status, Code or Result. Instead, focus on the statement itself, the literals, and the built-in functions.

Approach

For each row:

• check whether the operator usage is valid
• check whether the built-in function name and argument are valid
• check whether a literal is the correct type, such as string or number
• decide whether the whole statement is acceptable pseudocode

This is essentially a careful syntax-and-semantics check.

Step-by-Step Reasoning

1. Status ← TRUE AND FALSE

TRUE AND FALSE is a valid Boolean expression.

Its value is FALSE, and assigning a Boolean result to a variable such as Status is valid if Status is Boolean. The question tells us not to assume incorrect variable types.

So this statement has NO ERROR.

2. IF LENGTH("Password") < "10" THEN

LENGTH("Password") returns the number of characters in the string "Password", which is an integer.

But "10" is in quotation marks, so it is a string, not a number.

That means the comparison is between:

• a numeric result from LENGTH(...)
• a string literal "10"

This is the error. The 10 should not be in quotes.

So the error is that "10" is a string; it should be the number 10.

3. Code ← LCASE("Electrical")

In the pseudocode function list, LCASE is intended for a single character, converting it to lower case.

"Electrical" is a whole string, not one character.

So the problem is not that lowercase conversion is impossible in general; the problem is that this function is being used with the wrong kind of argument.

Therefore, the error is that LCASE should be used with a single character, not a whole string.

4. Result ← IS_NUM(-27.3)

IS_NUM checks whether a string can be interpreted as a number.

Here the argument is -27.3, which is already a numeric value, not a string.

So the function has been given the wrong kind of parameter.

Therefore, the error is that IS_NUM should be given a string, not a numeric value.

Key Takeaways

• A Boolean expression such as TRUE AND FALSE can be assigned directly to a Boolean variable.
• LENGTH(...) returns a number, so compare it with a number, not a string in quotes.
• Built-in functions must be used with the correct parameter type.
• In pseudocode, quotation marks matter because they change a value into a string literal.

Common Mistakes

• Saying the first statement is wrong because it contains two Boolean values. It is valid: TRUE AND FALSE is just a Boolean expression.
• Missing the quotes around "10". Those quotes are exactly what make the second statement wrong.
• Saying the third statement is wrong because LCASE does not exist, when the real issue is the parameter being a full string rather than a single character.
• Thinking IS_NUM(-27.3) is valid because -27.3 is a number. The point of IS_NUM is usually to test whether a string represents a number.

Things to Be Careful About

• Read literals carefully: 10 and "10" are different data types.
• Do not assume variable type errors, because the question explicitly tells you not to.
• Use the exam insert's function definitions exactly. Some functions operate on strings, some on characters, and some return numeric values.
• If the question asks for NO ERROR, write that clearly rather than explaining why the statement is valid.