ATAR Notes: Forum

HSC Stuff => HSC Technology Stuff => HSC Subjects + Help => HSC Software Design and Development => Topic started by: Justin_L on June 09, 2021, 11:46:25 pm

Title: SDD Skills - Systems Modelling
Post by: Justin_L on June 09, 2021, 11:46:25 pm
SDD Skills: System Modelling Tools

Welcome to part 2 of the SDD Skills Series! An important but often somewhat confusing part of software development is the systems modelling process – before starting development, it’s important to understand what you’re planning on developing! This is a skill also often assessed in the HSC exams and even in your internal major work, so it's good to have a solid understanding of how to use these tools.

To assist with this, NESA has a set of standard systems modelling tools to help us. You’ll be expected to be understand each of these tools and the standard symbols used as you can be asked to model a system in an exam.  Generally, systems modelling questions are placed as a precursor to algorithms questions to assess your understanding of the question and to help you plan out your algorithm.

Not that we will only be focusing on systems modelling tools and not other forms of documentation such as project management tools. This is because systems modelling tools are the only type of documentation you’ll be expected to reproduce from scratch in an exam. While you will need to be familiar with all these types, you will only need to be able to read an interpret other types of documentation as a standalone multiple choice question or to explain part of a larger system.

IPO Diagrams
IPO, or Input-Process-Output Diagrams are used to document the individual functions or subroutines of a program. There is no convention on the specific structure or terminology of how you outline the process unlike in pseudocode, so you have a lot of flexibility in how you represent your functions.

The Input represents the variables or information you would need
The Process represents the high level actions needed to fulfill the task
The Output represents the resulting various effects and user messages
 
Example IPO Diagram
(https://i.imgur.com/nJ5T7Pi.png)
Source: NESA SDD Course Specifications

This IPO Diagram models three functions of a voting system –
Function 1: Checks whether a voter is allowed to vote
Function 2: Allows a voter to vote
Function 3: Creates a report of the election

Generally, IPO Diagrams are less commonly featured in HSC Exams and would most likely come up as a multiple choice question. As a result, it is more important that you understand how to read and interpret them than writing them. Nevertheless, they should be easy marks if they come up due to their simple layout and flexible style.

Context Diagrams
Context diagrams are used to outline how your system interacts with external entities, ie other systems which are outside of your control.

Context Diagrams are also called Level 0 Data Flow Diagrams due to the higher level overview of information.
In a context diagram, your entire system is represented as a single process, represented by a circle. External entities are listed as squares, with annotated arrows representing the flow of information.
 
This example shows a potential modelling of the voting system described above – note that databases are not external entities (we’ll discuss this further with data flow diagrams).

Example Context Diagram
(https://i.imgur.com/7BQGvMq.png)
Source: NESA SDD Course Specifications

Drawing a context diagram from as part of a question’s specification is common in HSC exams, and so you should be well familiar. Note that the symbols used (Circle for the system, squares for external entities, annotated directional arrows) are specifically mandated by NESA, and you can get marks deducted for not using the right symbols or format. However, these are often easy marks so long as your model is reasonable.

Data Flow Diagrams
Data flow diagrams (also know as Level 1 DFDs in this case – more detailed DFDs are not covered in this course) are a refinement of a context diagram (A Level 0 DFD). They show how the functions and subroutines inside a system interact, and the flow of information (variables) between these functions.
 
DFDs have one additional symbol from a context diagram – a data store. External entities also change to represent any input for output not controlled by the system (eg. Users or other systems).

Standard DFD Symbols
(https://i.imgur.com/5JlkUrX.png)
Source: NESA SDD Course Specifications

Example DFD
(https://i.imgur.com/91v5QzY.png)
Source: NESA SDD Course Specifications

This is a DFD of the same system described above. In an exam environment, make sure you’ve accounted for all variables, entities, and functions mentioned in the questions specification.

Due to the increased level of detail, DFDs are much easier to lose marks on but are also generally worth more marks. Again, you’ll often be asked to draw a DFD from scratch in exams and so it is important you memorise NESA’s symbol notation and be confident with those types of modelling questions.

Structure Charts
Structure Charts are a way to model individual modules in order to represent the logic behind how subroutines interact. You can think of a structure chart as a way to model how you would break a problem down if you were to code it.

Standard Structure Chart Symbols
(https://i.imgur.com/yneQ2xh.png)
Source: NESA SDD Course Specifications


Example Structure Chart
(https://i.imgur.com/g36gf2a.png)
Source: NESA SDD Course Specifications

You can be asked to draw a structure chart based on an question specification much like for context diagrams for DFDs. However, you’ll also likely encounter this in multiple choice questions. For example, you may be shown several variants of a structure chart with minor changes (eg. Flags and Parameters swapped) and asked to identify the most correct chart. In these questions, it is essential to be able to remember the meaning of each NESA’s symbol notation and be familiar with interpreting and constructing these charts on the fly.

System Flowcharts
System Flowcharts are a way to represent how data moves through a system, somewhat similarly to a Data Flow Diagram. However, a System Flowchart provides a more holistic and higher level overview, showing the different ways data is represented and transmitted.

Standard System Flowchart Symbols
(https://i.imgur.com/CJ2Fd58.png)
Source: NESA SDD Course Specifications

Example System Flowchart
(https://i.imgur.com/9PKlpBb.png)
Source: NESA SDD Course Specifications

Many of the symbols used in system flowcharts are becoming outdated, and questions involving system flowcharts are becoming less common. However, it is still important to be able to reproduce the most common symbols and be able to interpret system flowcharts as they are still assessed in the HSC. If you’re short on time however, I wouldn’t recommend spending too much time on this.

Data Dictionary
A data dictionary is a less commonly used system modelling tool, and is simply a table representation of the data a system holds. Much like the IPO Diagram, this is fairly self-explanatory and you should be able to reproduce one with ease if asked during an exam.

The exact contents of a data dictionary varies, but I recommend the following format for an exam:

Data Name // Data Type // Description // Example

Story Board
Story Boards are simply screen mockups of a system, and show what each individual screen would look like if the program were to exist.

This is a really common exam question which requires a fair understanding of the various user interface (UI) elements taught in the course. The story board doesn’t have to be pretty and you won’t lose marks on artistic skill as the examiners are mainly looking for if you understand the purpose of different UI elements:

Common User Elements
Text Box: Free Response
Dropdown: Fixed Response (Single Selection)
Radio Buttons (Single Selection)
Checkboxes (Multiple Selections)
Buttons (Navigation)

Generally, it’s best to use simple, utilitarian design styles to represent your storyboard to minimise confusion and reduce the amount of work you’re spending on the exam. This style of question of often a nice break from the other more content heavy styles, but can be a big time waster if you have to redo a design or get distracted. It’s often useful to bring a ruler to speed up your drawing.

Summary
These are all of the system modelling tools defined in the course specifications and syllabus, which you can be tested on in exams or asked to produce as documentation for your major work. This doesn't cover project management tools, which are also assessed but not in a practical application (you won't be asked to draw or reproduce project management tools). However, you could be asked to draw or reproduce any of these system modelling tools, which is why it's important you practice modelling program with them.

For study, I would recommend finding past exam questions and practicing on those, as they also come with answers which you can compare with. If you've exhausted those, it's also very helpful to practice on random programs and systems with friends, as it allows you to peer mark answers and gain insight into other ways of thinking about how a system may be represented.

I also very highly recommend you take a read of the NESA Software Design and Development Course Specifications (Available on the NESA website under Stage 6 Software Design & Development), as it provides the detailed and most up to date information on the official guidelines for these tools. Most of the examples in this article have been derived from this document. It might be a bit wordy, but I think it's an exceptionally valuable resource for this course and a good reference if you're unsure of anything.

If you want to have a go at trying out any of these tools for a system or have any questions, feel free to post them below and I’ll provide some feedback!

Otherwise, check out some of the other articles in the SDD Skills Series from the main thread here!