The Student Room Group

A-level computer science NEA - need help with design section

I'm currently writing up the documentation for my CS NEA (AQA spec) after I've already programmed the majority (literally like 95%) of my project. I had already completed the analysis section before I started programming, but I left most of the design section because at the time I didn't really know what I was designing - I just wanted to get into the actual project.

Now that I'm done with the code, I really need to go back and do the design section. The problem I'm facing is that I was very, very ambitious with my code. I made a pretty big game - I counted that there are a total of 43 classes (which are all different! the game is just huge LOL). My problem now is trying to do all of these diagrams and descriptions of key algorithms etc.

For example, with regard to structure/hierarchy/flow charts, how would I even make those for a game? Would I need to cover every single thing that happens within it? Even when trying to simplify everything there's still such a huge amount of stuff to document. As well as that, do I need to do 43 class diagrams?? That sounds ridiculous???

Basically, I'd appreciate some guidance on what should be covered in the design section, and in how much detail. I've already looked at the official AQA notes and guidance for the NEA, but it really doesn't feel like it's helped much. All exemplar work I can find revolves around heavy use of databases, so the design sections for those are almost entirely different from what mine probably should be like. Please help :')
(edited 7 months ago)
Reply 1
Original post by eperkons
I'm currently writing up the documentation for my CS NEA (AQA spec) after I've already programmed the majority (literally like 95%) of my project. I had already completed the analysis section before I started programming, but I left most of the design section because at the time I didn't really know what I was designing - I just wanted to get into the actual project.

Now that I'm done with the code, I really need to go back and do the design section. The problem I'm facing is that I was very, very ambitious with my code. I made a pretty big game - I counted that there are a total of 43 classes (which are all different! the game is just huge LOL). My problem now is trying to do all of these diagrams and descriptions of key algorithms etc.

For example, with regard to structure/hierarchy/flow charts, how would I even make those for a game? Would I need to cover every single thing that happens within it? Even when trying to simplify everything there's still such a huge amount of stuff to document. As well as that, do I need to do 43 class diagrams?? That sounds ridiculous???

Basically, I'd appreciate some guidance on what should be covered in the design section, and in how much detail. I've already looked at the official AQA notes and guidance for the NEA, but it really doesn't feel like it's helped much. All exemplar work I can find revolves around heavy use of databases, so the design sections for those are almost entirely different from what mine probably should be like. Please help :')

You probably want to be using LaTeX or ConTeX etc for a report like this. That way it would be fairly trivial to write a small script to auto-generate LaTeX class diagrams from your source code (I wrote one for Java). You could do that anyway, and export the LaTeX to PDF then copy-paste the images in, but that's a bit.... eh...
(And if you can have 43 class diagrams... why not have 43 class diagrams?)

You can dumb down the data flow diagrams a lot, eg one flow might be
User --inputs--> Input handler --event flags--> game objects
But they aren't really that important for a game.

The flow chart can start with the game's start, so it'd be START->displayMenu()->c=getUserSelection()
Then branch off to whatever subroutine based on the user's selection. I only used the flowchart to show how the user navigates the main menu (in my case the IDE GUI). For the complex stuff you'd just have boxes with playGame() or saveGame() or quit() or something. Or you could break up playGame() and decompose further, but it's much easier to show that as pseudocode in the algorithms section.

The hierarchy structure should show everything in the game (because we can't have stuff in your code that you didn't design beforehand) but it'll depend on your game so I can't help much sorry シゝ
Reply 2
Original post by Teruko
You probably want to be using LaTeX or ConTeX etc for a report like this. That way it would be fairly trivial to write a small script to auto-generate LaTeX class diagrams from your source code (I wrote one for Java). You could do that anyway, and export the LaTeX to PDF then copy-paste the images in, but that's a bit.... eh...
(And if you can have 43 class diagrams... why not have 43 class diagrams?)

You can dumb down the data flow diagrams a lot, eg one flow might be
User --inputs--> Input handler --event flags--> game objects
But they aren't really that important for a game.

The flow chart can start with the game's start, so it'd be START->displayMenu()->c=getUserSelection()
Then branch off to whatever subroutine based on the user's selection. I only used the flowchart to show how the user navigates the main menu (in my case the IDE GUI). For the complex stuff you'd just have boxes with playGame() or saveGame() or quit() or something. Or you could break up playGame() and decompose further, but it's much easier to show that as pseudocode in the algorithms section.

The hierarchy structure should show everything in the game (because we can't have stuff in your code that you didn't design beforehand) but it'll depend on your game so I can't help much sorry シゝ


Thanks, I'll look into using LaTeX for the class diagrams.

I did not realise the data flow diagram could be so simple haha! I'll make sure to include that, I assumed that because there were no databases in my project, I couldn't use them.

About the flowchart - I'll probably approach it in the same way. I had already done a pretty in-detail flowchart for the menu which reassures me to know that you also did that!

For your algorithms section - what kind of stuff did you include? I'm not really sure what defines which algorithms are 'key', especially according to AQA. I have maybe 3 algorithms in mind which I definitely need to include, but obviously that does not cover the whole extent of my program, so would I need to include more? Would I need to explain, for example, player collision mechanics and enemy spawning?

Thanks a lot for the help though! Sorry that I'm asking so much, my teachers are very unfamiliar with the libraries and methods I'm using so I've been mostly left to my own devices, and they've not really answered my questions on how to actually write up the report in a way that doesn't relate to database use LOL
Reply 3
Original post by eperkons
Thanks, I'll look into using LaTeX for the class diagrams.

I did not realise the data flow diagram could be so simple haha! I'll make sure to include that, I assumed that because there were no databases in my project, I couldn't use them.

About the flowchart - I'll probably approach it in the same way. I had already done a pretty in-detail flowchart for the menu which reassures me to know that you also did that!

For your algorithms section - what kind of stuff did you include? I'm not really sure what defines which algorithms are 'key', especially according to AQA. I have maybe 3 algorithms in mind which I definitely need to include, but obviously that does not cover the whole extent of my program, so would I need to include more? Would I need to explain, for example, player collision mechanics and enemy spawning?

Thanks a lot for the help though! Sorry that I'm asking so much, my teachers are very unfamiliar with the libraries and methods I'm using so I've been mostly left to my own devices, and they've not really answered my questions on how to actually write up the report in a way that doesn't relate to database use LOL


Happy to help :smile:
For key algorithms you'll need to choose 8-10 of the most important ones. In terms of deciding which ones are most important, it's a pretty arbitrary decision that doesn't actually matter much (just don't pick some pointless 3-line algorithm or whatever).
It's probably best to pick the most complex ones however, so that you have more to write about.
If you've got algorithms to handle the player collisions and enemy spawning, might as well put them in, can't hurt. Sounds probably pretty important so I would-

I had quite a lot of algorithms in mine. Just converted my java to pseudocode and added some explanations of what they do and why. Specifically, I used the methods for lexing, parsing, execution, autocompletion, and text-searching.

Have you looked at the wikibook? I found it very helpful in guiding me through what to do.
Reply 4
Original post by Teruko
Happy to help :smile:
For key algorithms you'll need to choose 8-10 of the most important ones. In terms of deciding which ones are most important, it's a pretty arbitrary decision that doesn't actually matter much (just don't pick some pointless 3-line algorithm or whatever).
It's probably best to pick the most complex ones however, so that you have more to write about.
If you've got algorithms to handle the player collisions and enemy spawning, might as well put them in, can't hurt. Sounds probably pretty important so I would-

I had quite a lot of algorithms in mine. Just converted my java to pseudocode and added some explanations of what they do and why. Specifically, I used the methods for lexing, parsing, execution, autocompletion, and text-searching.

Have you looked at the wikibook? I found it very helpful in guiding me through what to do.


I have looked at the wikibook a bit, but I'll go back to it and look at it further. Thank you very much for the advice! I really appreciate it.

Quick Reply

Latest

Trending

Trending