Design a software program structure DTG 7-6
Achievement standard 2.45 AS91372
Design a software program focuses on designing the structure of a software program.
Learning objective: DTG 7-6
Students will:
- demonstrate ability to design the structure of an advanced software program.
Indicators
Students can:
- specify well-chosen scopes for variables, their scopes and data types
- specify an indexed data structure
- specify a modular structure for the program with well-chosen parameters, including details of the procedural structures of the modules, that constitute a well-structured logical decomposition of the task
- specify a comprehensive set of expected, boundary, and exceptional input cases for testing the program
- specify variables, constants, and derived values effectively so as to maximise the flexibility and robustness of an independently constructed plan.
Progression
At level 6, students learn to specify variables and their data types, construct flexible and robust plans, and determine structures that combine well-chosen actions, conditions and control structures that provide well-structured logical solution to tasks. They establish sets of test cases with expected, boundary and invalid input for testing programs.
At level 7, students progress to designing the structure of an advanced software program where the plan has a modular structure (depending on the language, modules might be called functions, procedures, methods or subroutines), an indexed data structure (usually an array or list), input and output, and procedural structures that combine sequential, conditional, and iterative structures. (Sequential structures are simply consecutive instructions; conditional structures are typically an “if/else” or “case/switch” statement; and iterative structures are typically “for”, “while”, “repeat”, or “do” loops).
TOP
Teacher guidance
To support students to develop an ability to design the structure of an advanced software program at level 7, teachers could guide students on how to specify:
- well-chosen scopes for variables, their scopes and data types
- indexed data structures
- modular structures for programs with well-chosen parameters, including details of procedural structures of modules, that constitute well-structured logical decomposition of tasks
- a comprehensive set of expected, boundary and exceptional input cases for testing programs
- variables, constants, and derived values effectively so as to maximise the flexibility and robustness of independently constructed plans.
TOP
Contexts for teaching and learning
The learning associated with DTG 7-6 Design a software program structure (AS91372 Digital technologies 2.45) and
DTG7-7 Construct a software program (AS913723 Digital technologies 2.46) are strongly interlinked, and normally both should be taught at the same time. Requiring students to finalise their plan (for 2.45) before implementing their program (for 2.46) reflects the "waterfall" model of software development, and is not really appropriate for small programs or for novice programmers. A more appropriate, and more common approach in industry, is "agile" software development, where an aspect of the design is done and then implemented, and this process is iterated so that each step of the process informs the next, allowing errors found in implementation and testing to feedback to improve and extend the design. The latter is recommended for teaching these topics as students will learn what is reasonable in a design as they implement it. The key to producing a design is that students take a loose requirement (such as "count the number of times each character occurs in a text") and turn it into an algorithmic description (plan) that is a set of executable steps (in this case, probably a loop that goes through each character in the text and increments its count in an array). The implementation would involve taking the algorithmic description and turning it into a debugged and tested program. It is to be expected that the final design may have been changed from the initial design, but this is not a problem for assessing the standards as long as students are able to express their final design clearly and precisely as an algorithmic description.
Teachers are referred to the
Support for Schools website prepared by staff from the Computer Science Department at The University of Otago. This resource has numerous ideas for teaching and assessing this topic.
This learning objective DTG 7-6 is often done in conjunction with the learning objective (Demonstrate ability to construct an advanced software program). While it is not an absolute requirement for this objective that students must carry on and code the program they design, the implementation will make the design process more meaningful, and it would be difficult to teach students to design a program when they don’t know how to code it.
Literacy considerations
Teachers need to ensure students understand the specialist language related to constructing a plan for an advanced program such as "modular structure" or "exceptional input cases". In addition, students must be able to present their plan in a way that is clear to others. Students will need guidance on how to present coherent documents that communicate the structure and function of a computer program.
Resources to support teaching and learning
TOP
Assessment for qualifications
The following achievement standard(s) could assess learning outcomes from this learning objective:
- AS91372 Digital technologies 2.45: Construct a plan for an advanced program for a specified task
Key messages from the standard
- At level 7 the plan must be for an advanced computer program. An advanced computer program is defined in explanatory note 4. The essential step up from level 6 is that it must have a modular structure (typically functions, procedures, methods or subroutines) and an indexed data structure such as an array or list (in addition to the other requirements expected at level one and set out in explanatory note 4).
- What a plan is in the context of this standard is defined in explanatory note 3. It must be developed in the context of a target programming language. The plan can be communicated using a range of tools such as natural language, diagrams, or pseudocode. See explanatory note 3.
- Explanatory note 5 gives details about the requirements for the modular structure. The plan for a modular structure involves a collection of named modules where each module specifies a procedural structure for a sub-task. At least the top-level module must contain calls to other modules. The modules should include parameters as necessary. Parameter passing between modules is not required by the standard, although would be normal for good style and should be used if a module needs to receive or return values.
- The merit criteria requires specifying well-chosen scope for the variables (see explanatory note 7) and specifying well-chosen parameters for the modules (see explanatory note 8). For example, in most languages the use of global variables to communicate between modules would be considered to be a poor choice.
- As part of the task, students need to specify a set of input cases for testing the program. These need to be clearly set out in writing in the student evidence for this standard. Students need to understand expected input cases, boundary input cases, and exceptional input cases. Some of these may become clearer once the program has been implemented, which is an example of how the plan might be informed by the implementation. Refer to the table below:
| Achieved
| Merit
| Excellence
|
| Expected input cases
| Expected and boundary input cases
| Comprehensive set of expected, boundary, and exceptional input cases
|
| Expected – input that is expected, that is, if a number between 1 and 10 is expected then you would test the program for input of say 2 or 5 or 9
| Boundary – input values that are right at the limit of being too large, too small, too long, or too short, or too... they are valid, but because they are right at the end of the range, programmers may have got their conditions just a little bit wrong. Boundary testing when iterating through a list or array is particularly relevant to this standard. What happens when the length of the list or array is reached?
| Exceptional – these are special cases which may cause the program to have to do something unusual. The inputs could be invalid (for example, a string when an integer is expected) or otherwise exceptional (for example, a list of names that has zero names in it).
|
- Part of the step-up to merit is that students need to construct the plan independently. To make a judgment for independence, the following guidelines might be helpful. The student:
- The step-up to excellence is about the efficiency of the plan for the program. In the context of designing a program, this involves making good design choices so that the design does not have to be redesigned substantially if the program needs to be extended or modified, and that the design can be understood easily and quickly by a later programmer. This involves a well-structured logical decomposition of the task (see explanatory note 10) and using variables, constants and derived values well (see explanatory note 9). It also involves specifying a comprehensive set of input cases for testing the program so that design and implementation errors can be found quickly.
- Although not a formal requirement of the standard, teachers are encouraged to show students suitable ways of desk checking an algorithm.
- The evidence for this standard may be part of a larger project or may be from a standalone activity.
Resources to support student achievement
Last updated June 8, 2018
TOP
