Post History

Source: https://writers.stackexchange.com/a/42411
License name: CC BY-SA 3.0
License URL: https://creativecommons.org/licenses/by-sa/3.0/

Source: https://writers.stackexchange.com/a/42411
License name: CC BY-SA 3.0
License URL: https://creativecommons.org/licenses/by-sa/3.0/

Adding to Maura's answer:

" **Detailed design**" implies you will go in-depht showing the abstract structure of your project. This means showing what the program does, without looking at the code. Design decisions have to be discussed and explained, often with the aid of UML-like diagrams, either showing a [class diagram](https://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/index.html)

[![UML-classdiagram](https://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/bell_fig5.jpg)](https://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/bell_fig5.jpg)

or maybe a [process](https://www.process.st/uml-tutorial/):[![enter image description here](https://i.stack.imgur.com/hrSHx.png)](https://i.stack.imgur.com/hrSHx.png)

Those of course are examples. There are a lot of things that can be done with UML in standardized notation - you have to decide what would be the most relevant depending on your program. If the code interacts with external services (e.g. a database, web API's, the internet) it may be worth showing an architectural diagram.

In this section you may also want to describe how you designed _your method_. It's a paper: it implies you have done your research. So it may be relevant to show here how you designed the process of testing.

" **Key Implementation Decisions**" is where you are supposed to show that you got your hands dirty, as a figure of speech. Here you are allowed to talk about your code, or whatever tech-related mechanism you have used in your research.

Keep in mind that you don't need to comment everything: just the "key" parts that are required to understand your program. Nobody wants to read a paper where you describe how you defined an array, since everyone can do that. Essentialy, you have to show how you implemented your design, what's interesting about it, what's new, what's difficult, and what challenges you did undertake.

You may want to show a "core" part of your program; you may want to discuss how you decided to improve the overall performance by using different data-structures during development; you may discuss why a particular method gives you best results, commenting the code. Those are the "decisions" that belong in a paper.

Original score: 1