Embedded Files
Speaker notes from the presentation above:
IPO charts are tables that show the inputs, outputs and the processes that occur in between these two. They are used to provide a simple calculation of the input, to achieve the output wanted. This particular chart will show the data needed, the type of code/formula needed to produce the final product. An IPO chart is layed out with 3 columns next to each other, all three stating the three different stages of the diagram (input, process and output). This is also made with the arrow from the processes to the output if there is more than one output from the input. An example of this being non technological would be a cow entering a process factory which would be your input. Your process would be the cow being slaughtered and the meat being processed, and your output would be a burger with the cows meat on it.
Here is an example of an IPO chart with the inputs on the left, processes involved in the middle, and the outputs on the right.
The context diagram shows the system under consideration as a single high-level process and then shows the relationship that the system has with other external entities like systems, organizational groups, external data stores and more.
Context diagrams were created for systems analysis and design, but like many analysis tools they have been leverages for other purposes.
For example, they can also be leverages to capture and communicate the interactions and flow of data between business processes, so they don’t have to be restricted to system analysis.
A context diagram provides no information about the timing, sequencing, or synchronization of processes such as which processes occur in sequence or in parallel. Therefore it should not be confused with a flowchart or process flow chart which can show these things.
Example:
A context diagram is a graphical representation of the movement of data between an information system and the people and organization(s) associated with it.
Information system (Process) - Circle
External Entities - boxes
Context diagrams identifies the data passing between external entities and information system.
Data flow lines (arrows) must show the relevant data on the flow lines.
Decisions and order of events are not represented in context diagrams.
Two (or multiple external entities) are never directly joined together. They must interact via a process.
Data flow diagrams are paths which data takes through a system.
To make it easier to remember, think of data flow diagrams as railroad tracks with many stops and destinations.
There are four parts which the data flow diagrams contain: boxes, vectors/arrows, circles and an open rectangle.
Boxes in a data flow diagram represents the entities in a system which could be things such as customers, companies and many more.
Circles are the processes that occur in a data flow diagram. A process could be a calculator calculating with the number values and bodmas it has been
Vectors/arrows represent the data flowing that goes through the entities, process and data store. A data flow example could be an enrolment form or academic record in a school system.
The open rectangles represents the data store which stores all the data in a data flow diagram. Data stores could store data such as disks, files, paper files and many more.
A perfect example of a data flow diagram would the streaming service itself, Netflix.
As you can see here, the arrows point at the external entities in a netflix data flow diagram. This is shown by the “netflix user” and the “bank” entities.
Here you can see the processes in a netflix data flow diagram. This is shown by the watch movie, generate customer receipt, login and many more.
These arrows shows the data store in a netflix data flow diagram which is shown by the “movie database” and “user database”
Last one is the data flow that flows throughout the system. This is shown through “movie”, “confirmation of payment” and more.
So basically there are two different types of storyboards:
A designer one... and a programmer one.
Storyboards are used for a better visualisation, and to observe and see the flow of the events in the game/story, whatever you are making.
It’s effect if you are working in a team, for others to see what you as the planner or creator is envisioning.
An important part for a porgrammer storyboard, is that it incorperates the needs of a programmer and a designer.
For a programmer storyboard, it should provide a straightforward idea for what the programmer needs to do
To develop and code the function.
And as a programmer you should be able to easily interpret the code from the storyboard.
Structure charts show the flow of data between modules in a program or system. They allow you to see what information will influence different parts of your project and which parts are absolutely necessary for your project. A Structure chart shows the breakdown of a system to its lowest manageable levels. They are used in structured programming to arrange program modules into a tree. Each module is represented by a box, which contains the module’s name. Structure charts use different symbols to identify where data will be moved to and where repetition and decisions will occur.
The data movement symbol shows the direction where data will be moving to for example when you try to store information in a different location you are moving the data and therefore the this symbol would be used. The flag symbol shows when the criteria for the module is fulfilled, for example a search result returns via a flag.
The decision symbol is indicated by a diamond shape such as when you as the user have to choose an option on the game you are playing. The repetition symbol is shown by a circular arrow, illustrating going around and around on something. An example of this would be someone knitting, as they keep repeating the same motion with their hands in order to make their scarf. An example of this is from the 2019 Software Design and Development HSC exam in which the students were asked to describe the system making reference to each symbol used. In this example you can see a the repetition symbol, the data movement symbol, the flag symbol and the decision symbol.
System Flowcharts are a way of displaying the flow of data in a system and how decisions are made to control the events. They describe the interactions that occur between input, processes, output and storage, as well as the nature of each of these components. They show an overall view of the entire system.
Symbols are used to illustrate what happens to the data and where it goes. The text inside the symbol describes its specific function.
Although certain symbols are the same as in algorithm flowcharts, the design of system flowchart differs. Flowcharts for algorithms are designed to precisely show the logic of an algorithm, whereas system flowcharts describe a system. Logic is only shown where necessary to describe the flow between components.
A data dictionary provides detailed information about the data, such as standard definition of data elements. It also describes its meaning or description as well as showing what values are allowed and hot they are restricted. It can be used for the benefit of programmers who can refer to these data dictionaries to keep consistent and meaningful data
Some key attributes of a data dictionary table include its name, type of data, its restrictions/field size and a description.
Here is a data dictionary outlining a Database on driver details in New South Wales.
The key attributes mentioned previously can all be observed in this example such as the name, data type, field size and a description. Some other features are also present in this example such as the data format and the example
This is an example of how a data dictionary can be implemented in software development. In this scenario it’s showing the assets involved in the game being developed. The field name is replaced by the asset name and the description is replaced by the properties of this asset. The other attributes are there for the same purpose which is to provide rules about certain data but in a way that is more appropriate and relevant to video game development.
Test data is a tool used to ensure that the code works correctly for the intended dataset.
Test data is inputed and run and is compared to the expected value to determine if the code is working as intended.
Test data should include datasets intended for the variable and also test the limits of the variable to ensure it is working as intended through the entire range of data.
Say we were trying to calculate the player health given amount of damage.
Assume the player health is 100 the damage variable’s test data should be a number between 0 and 100 , the two limits 0 and 100 as well as something exceeding both limits so -1 and 101.
https://www.youtube.com/watch?v=n7xnED5cEk8
Algorithms are used to illustrate the logic in modules and subroutines. This means that they highlight the order in which things will happen and what will then occur after this. It’s like a recipe in a way. You start from the top and work your way to the bottom until the recipe or in this instance the algorithm is completed. Using algorithms allows for a better understanding of the flow of your program.
IPO Diagrams
IPO Diagrams
These diagrams are used to document a system by identifying the inputs into each major process, the general nature of these processes, and the outputs produced.
The IPO diagram is in the form of a table with 3 columns, one for Input, Process and Output. The following IPO diagram describes the voting system subsequently shown as a data flow diagram.
Context diagrams
Context diagrams
Context diagrams are used to represent an overview of the system. The system is shown as a single process along with the inputs and outputs. The external entities are connected to the single process by data flow arrows. Each elements represented is labelled. A context diagram does not show data stores or internal process.
data flow diagrams
data flow diagrams
Data flow diagrams represent a system as a number of processes that together form a single system. A data flow diagram is a refinement of a context diagram. Data flow diagrams therefore show a further level of detail not seen in the context diagram. Data flow diagrams identify the source of data, its flow between processes and its destination along with data generated by the system.
storyboards
storyboards
A storyboard shows the various interfaces (screens) in a system as well as the links between them. The representation of each interface should be detailed enough for the reader to identify the purpose, contents, and design elements. Areas used for input, output and navigation should be clearly identified and labelled. Any links shown between interfaces should originate from the navigational element that triggers the link.
structure charts
structure charts
Structure charts represent a system by showing the separate modules or subroutines that comprise the system and their relationship to each other.
Rectangles are used to represent modules or subroutines, with lines used to show the connections between them. The chart is read from top to bottom, with component modules or subroutines on successively lower levels, indicating these modules or subroutines are called by the module or subroutine above. For all modules or subroutines called by a single module or subroutine, the diagram is read from left to right to show the order of execution.
structure chart.pngsystem flowcharts
system flowcharts
System flowcharts show how hardware, software and participant interact in a system.
The images below show the symbols used in a system flowchart and a sample chart.
data dictionaries
data dictionaries
A data dictionary shows all assets, objects, variables and values you will use in your development. It should show parameters and scope of variables including initial values, maximum and minimum values, and any other porperties ptogrammers may need. Part of a data dictionary is included below.
In SDD, data dictionaries are tools that programmers use to keep track of assets. In IPT and indeed in database management, data dictionaries are used to define and describe the structure of data in a database. The SDD version of a data dictionary is an enhancement of this.
algorithms used to document the logic in modules and subroutines
algorithms used to document the logic in modules and subroutines
It is expected that students are able to develop and interpret algorithms using pseudocode and flowcharts. Pseudocode uses English-like statements with defined rules of structure and keywords. In pseudocode:
Keywords are written in capitals. Structural elements come in pairs, e.g. for every BEGIN there is an END, for every IF there is an ENDIF.
Indenting is used to identify control structures in the algorithm
The names of subprograms are underlined. This means that when refining the solution to a problem, a subroutine can be referred to in an algorithm by underlining its name, and a separate subprogram developed to show the logic of that routine. This feature enables the use of the top-‐down development concept, where details for a particular process need only be considered within the relevant subroutine.
Flowcharts are a diagrammatic method representing algorithms, which are read from top to bottom and left to right.
Flowcharts use the following symbols connected by lines with arrowheads to indicate the flow. It is common practice to show arrowheads to avoid ambiguity.
It is important to start any complex algorithm with a clear, uncluttered main line. This should reference the required subroutines, whose detail is shown in separate flowcharts.
A subroutine should rarely require more than one page, if it correctly makes use of further subroutines for detailed logic.
test data and expected output
test data and expected output
Developing suitable test data to ensure the correct operation of algorithms is an important aspect of algorithm development. Test data should test every possible route through the algorithm as well as testing each boundary condition. Testing each route makes sure that all statements are correct and that each statement works correctly in combination with every other statement. Testing boundary conditions ensures that each decision is correct.
Commonly, a decision will be out by 1 as a result of an incorrect operator, for example < instead of <=. When designing test data it must take into account the:
Legal and expect values: i.e. critical values (values which a condition is based on) and boundary values.
Legal but unexpected values: i.e. data in an incorrect format (e.g. decimal) but accepted by the program’s guidelines.
Illegal but expect values: i.e. illegal data due to ignorance, typing errors or poor instructions. These errors should be trapped and not halt the execution of the program.
When initial test data items are created the expected output from these inputs should be calculated by hand. Once the subroutine has been coded, the test data is entered and the output from the subroutine is compared to the expected outputs.
If the actual and expected outputs match then this provides a good indication that the subroutine works. If they don’t then clearly a logic error has occurred. Further techniques must be employed to determine the source of the error.
Page updated
Report abuse