PAT 2010 Grade 12

Western Cape Education Department
INFORMATION TECHNOLOGY
PAT 2010 for Grade 12 unpacked and (hopefully) demystified – Phase 2
Phase 2 – the design phase of the PAT – is probably the most important section of the PAT: After describing
WHAT the program must achieve in Phase 1, the learner must now focus on HOW this is going to be achieved.
If planned properly you can expect a good project (broken up into several logical classes and methods), if
neglected probably a mediocre one at best (all in one class or messy break-up because done while programming).
It would therefore help considerably if any diagrams were drawn up at this stage: Use case diagrams, data-flow
diagram and/or IPO diagram. While some models are out-dated and newer models have superseded the older
ones, ANY diagrammatic planning at this stage is beneficial!
We can recommend the following links:
http://en.wikipedia.org/wiki/Structure_chart
http://en.wikipedia.org/wiki/Use_case_diagram
http://en.wikipedia.org/wiki/Unified_Modeling_Language
http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/use_case.htm
http://www.agilemodeling.com/essays/amdd.htm
http://www.agilemodeling.com/artifacts/useCaseDiagram.htm
Two examples:
1.
A structure chart is a top-down modular design tool, constructed of squares representing the different
modules in the system, and lines that connect them. The lines represent the connection and or
ownership between activities and sub-activities as they are used in organization charts.
In structured analysis structure charts, according to Wolber (2009), "are used to specify the high-level
design, or architecture, of a computer program. As a design tool, they aid the programmer in dividing
and conquering a large software problem, that is, recursively breaking a problem down into parts that
are small enough to be understood by a human brain (our emphasis). The process is called top-down
design, or functional decomposition. Programmers use a structure chart to build a program in a
manner similar to how an architect uses a blueprint to build a house. In the design stage, the chart is
drawn and used as a way for the client and the various software designers to communicate. During the
actual building of the program (implementation), the chart is continually referred to as the master-plan"
(our emphasis).
A structure chart depicts

the size and complexity of the system, and

number of readily identifiable functions and modules within each function and

whether each identifiable function is a manageable entity or should be broken down into smaller
components. (From: http://en.wikipedia.org/wiki/Structure_chart )
2.
A use case diagram in the Unified Modeling Language (UML) is a type of behavioral diagram defined
by and created from a Use-case analysis. Its purpose is to present a graphical overview of the
functionality provided by a system in terms of actors, their goals (represented as use cases), and any
dependencies between those use cases.
The main purpose of a use case diagram is to show what system functions are performed for which
actor. Roles of the actors in the system can be depicted.
WCED
875099718: Phase 2
Page 2 of 6
From: http://en.wikipedia.org/wiki/Use_case_diagram
From the first example we can take the notion of successively breaking the problem down into smaller and
smaller parts until they become single entities, and the notion of referring to the plan while programming, i.e.
stressing how important planning is! From the second example we can take the notion of functions of and actors
in a system. It also focuses on the data flow.
From this follow two planning strategies. In each case ignore the order presented in the rubric and let the learner
start with action statements. This does not, however, mean that the order of the rubric must be discarded for the
formal presentation/write-up of phase 2, merely for the planning process!
Route 1
Step 1
Step 2
Step 3
Step 4
Route 2
Step 1
(same as
in route
1)
Step 2
Step 3
Step 4
We believe learners find it easier to spell out processes than to extract data, because that’s
how they experience computers, its all about action. What can we do in this game? How do
I…?
What must the program be able to do, what happens when the user takes a certain action?
Now let them interrogate each action and list all the data involved in that action.
Compare these lists and decide which data items belong together. These groupings can
possibly point to how the database and the classes must be designed.
Design the database tables and class diagrams.
Design the GUIs.
We believe learners find it easier to spell out processes than to extract data, because that’s
how they experience computers, its all about action. What can we do in this game? How do
I…?
What must the program be able to do, what happens when the user takes a certain action?
Design the GUIs for the processes based on user interaction and in so doing decisions about
grouping of data needs to be taken.
These groupings can possibly point to how the database and the classes must be designed.
Design the database tables and class diagrams.
By focusing on the actions (functions – see list of requirements from phase 1) and the data needed for the
actions, the learners have to look at the inputs, what happens to the data (processing) and the outputs. And once
the data that will be passed around is identified, the following questions can be tackled: What variable names to
WCED
875099718: Phase 2
Page 3 of 6
use? What data types? Is validation required? If so, what is the validation rule? What error message? How many
decimal places? What formats will the input take, e.g. date (dd/mm/yyyy), textfield or dropdown list, etc?
This information can be presented in tabular form.
The Rubric:
The first section of the rubric concerns the “Specifications” and picks up on the list of specifications drawn up
in Phase 1. Here the focus is on the data flow: It is broken down clearly into “Input”, “Processing” and “Output”.
To do justice to this planning stage the learners MUST present separate paragraphs/lists for each of the three,
describing fully what the inputs are (from the user or from the database), what and how the processing is done,
and what (and in which groupings) output is presented to the user (or written back to the database). If the learner
has taken the trouble to draw a use case diagram, it will be easy to describe each one in turn.
WCED
875099718: Phase 2
Page 4 of 6
If all inputs are clearly listed in table format, then new columns can be added easily and format, validation and
error messages can be added, e.g.
NB: Where it says “all” (in Processing, Data validation, Error messages) that is what it means. If “all” applicable
instances are not described, then the maximum mark should not be awarded!
The next section concerns the “database design”: fields (types and sizes) and tables (normalization and key
fields). While a table format is most appropriate for fields, types and sizes (see table immediately below), screen
dumps of the design view of the actual tables are permissible. Screen dumps of relationships between tables can
also be used but the primary key and foreign keys must be clearly labeled.
WCED
875099718: Phase 2
Page 5 of 6
NB: In the rubric sections above, ALL descriptors have to covered in order to obtain the maximum mark!
The next section concerns “data structures”, i.e. data structures in the program (not database), which should be
planned as classes and objects. These should be user-defined “abstract data types”, i.e. classes written by the
learner him/herself that are then instantiated in the program. This does NOT include the use of pre-defined/builtin classes/objects such as Frames and other swing objects, etc. The easiest (although not strictly necessary) is to
write objects for the database entities, i.e. a Book class if there is a table of books in the database. But it should
contain more than merely gets and sets, and contain some of the validation! One can then package a book’s
details in a Book object and sent to the DatabaseManager for insertion into the BookTbl. As mentioned, another
function usually written into a separate class (with lots of different methods containing all the SQL statements) is
a DatabaseManager.
NB: A 3 may only be awarded if the “entire program is object-oriented” (see rubric below, 2).
What is an “abstract data type”?
“In computing, an abstract data type or abstract data structure is a mathematical model for a certain class of
data structures that have similar behavior.” (from: http://en.wikipedia.org/wiki/Abstract_data_types)
WCED
875099718: Phase 2
Page 6 of 6
Finally the user interface (probably a GUI) must be planned. We have touched on that in the preamble on
planning (see “two strategies” on page 2 of this document). It must be mentioned here that the GUI could not
only be done in javax.swing but also in html as web pages or – for weaker candidates – in text mode. In each
case it must be pointed out that the chosen mode should be applied in its entirety (i.e. no mixing of interface
modes) and that it needs to be planned: for grouping, placing, ease-of-use, uniformity, neatness, etc. This applies
even to text mode!
What are “appropriate input/output components”?
The learner has to make decisions regarding the number of screens/frames, whether they contain input or output
(or both). Whether the input is from text fields, drop-down boxes/menus, or tick boxes. Whether prompting
needs to be done (formats!) or not. Whether the output should be presented in tabular format or any other way.
Whether editing is done on empty text fields or populated with data, etc. As before, the maximum mark can only
be awarded if the components specified are “appropriate” AND if “all instances” have been addressed. For the
inputs the learner should also motivate/substantiate why he/she selected the particular form of input (text fields,
drop-down boxes/menus, or tick boxes).
Finally the planning/design is measured against the requirements specified in phase 1. It really helps if (as we
suggested) there is a list of requirements which is used as a tick-list. A 2 may not be awarded unless ALL
requirements are in fact addressed.
© Max Brock and Shamiel Dramat
This guidance document may only be distributed free-of-charge for educational purposes.
April 2010