Documented Design Guidelines

What is Documented Design?

Before programming code or a solution is implemented, it needs to be designed. This design can be understood easier if you include certain design tools that can can take various forms including diagrams, charts, algorithms and screen designs.

Whilst it is likely that some of your solution will be designed before any implementation takes place, AQA accepts that it is most likely that you will utilise some form of iterative methodology. This allows you to design or redesign something that did not work or needs adding in the next iteration of this process and means that your documented design is a working document throughout your project.

When you are designing your solution and find that you want to add an image, diagram or chart it is important that you give some kind of textual overview to the teacher or moderator to explain the images being used.

Structure/Hierarchy Diagrams

Your project will involve producing a substantial amount of program code. The problem will be too large to simply start coding the solution immediately.

Decomposition is the technical term for splitting a large problem into smaller ones. It is important that you hold off programming your project too early to avoid errors where your code has become difficult to manage because it has not been suitably broken down into small easy to solve and testable subprograms.

Once you have split the problem up, it becomes easier to track progress through it. The smaller the parts, the easier they become to solve and manage.

One method of showing a structure is shown below, but you could use other diagrams, charts or layouts. Remember that these diagrams are only examples and your diagram is likely to contain more information.

Whilst these diagrams can be easy to create, careful consideration should be made at this stage so that the problem is decomposed into meaningful parts.

System Flowcharts

A system flowchart allows a third party to see very quickly and overview of how the system works. The symbols used are similar to those used in flowcharts for algorithms. At this level, though, remember that the diagram is showing an overview of the system. Algorithms can be shown using flowcharts and pseudocode later.

The key symbols are shown below.

Data Flow Diagrams

Data Flow Diagrams (DFDs) show the inputs, outputs and how the data moves within your system.

Datastores are databases or files within the system. In the analysis, the users of the system will have been identified along with the actions they need to carry out.

Here is a very simple Data Flow Diagram for a student registering on a course in college.

This very simple diagram shows that the student would pass their details on to a process called 'Enrol on Course'. This would then store the details in the 'Course' database.

DFDs are a really good way to show how data moves around within your system.

Object-Oriented Design

This looks at creating entities known as objects which interact with each other. Each object can interact with another object, but the code determines how.

If you are using Object-Oriented Programming (OOP) you need to be aware that it focuses on three core ideas

• Inheritance to help reusability

• Polymorphism for flexibility

• Encapsulation to keep states and behaviours within each object.

Building Object-Oriented Designs

Object orientation requires you to be able to spot common areas in parts of your problem that need a class to implement them.

You should be able identify what Classes, Objects, Sub-Classes are required for your design.

For each of the classes created you will need to identify the attributes and behaviours for your classes.

Class Diagrams

Class diagrams are a standard way of showing an object-oriented design. They are drawn using Unified Modelling Language (UML).

Class Diagrams show:

1. Each of the classes used

2. The attributes available within each class

3. The methods available within each class

4. Whether classes are sub-classes, and inherit attributes and methods from parent classes

An example of a Class Diagram can be found below.

If your project relies heavily on OOP then you should make sure you consider which of the following key aspects are relevant to your project

• Classes

• Objects

• Instantiation

• Encapsulation

• Inheritance

• Aggregation

• Composition

• Polymorphism

• Overriding

• Interfaces

• Abstract, virtual and static methods

• Public (+), private (-) and protected (#) specifiers

Database Design

Many systems will rely on a database to store data. You will need to make sure you have designed the database structure or schema before it is built.

The key considerations that you will need to make when designing your database are found below.

Data Storage

Although a project may need to store data, it doesn't mean that a database is required. Some data storage could be done through a simple file storage method. However, systems such as stock storage, orders and bookings will likely need the more complex facilities of a database.

Data Relationships

If the database required has more than one table then it is likely that there will be relationships between the data. Most database designs will need to be normalised to remove data redundancy.

Database-Program Connections

There must be a way to connect your main program to the database. In some cases this is easy, but in others, it may be more complex. You will also need to be confident in writing SQL statements for database for database queries.

Database Design

Database design will require the creation of one or more Entity Relationship Diagrams (ERDs)

SQL

Knowledge of Structured Query Language (SQL) will be needed in order to access the data from the database.

Remember that SQL isn't considered a programming language. It is a query language which can be used in your project , but you must make use of a text language such as C#, VB or Python. Use languages such as these to connect to a database if one is required. SQL can then be used to make necessary queries to the database.

SQL Syntax

Some of the key terms that you may need to use are found below.

Parameterised SQL

Basic queries tend to be written in the following style

SELECT column1, column2, column3 FROM TableName WHERE criteria
For example:
SELECT customerID, name FROM Sales WHERE spend > amountRequested

Although the above SQL query shows the use of the parameter amountRequested, it only uses one table. As such, it would only be demonstrating a Group B skill.

To Demonstrate a Group A skill, parameterised SQL statements that use more than one table should be written where appropriate.
For example:
SELECT Customers.name, Orders.total
FROM Customers, Orders
WHERE Customers.customerID = Orders.customerID AND spend > amountRequested

Additional SQL Features

If your project relies heavily on databases and SQL then you should aim to use both Aggregate SQL functions and a script to create and initialise the database (DDL script).

Aggregate SQL functions to perform basic calculations on data. The most commonly used of these are given in the table below.

A DDL script is where a Data Definition Language has been used in a script to create the tables and other parts of the data model for a database. The script can be made using SQL and the following commands will be useful to research when doing this:

CREATE DATABASE databaseName;

CREATE TABLE tablename ( col1 datatype, col2 datatype,...);

There are also other SQL statements that specify whether fields are primary keys, if they auto increment or should not be null.

Multi-Table Databases

At A Level, you are likely to need a multi-table database and the use of several tables is a Group A technical skill. The tables will need to be normalised and typically will be in 3rd Normal Form (3NF).

Both SQL and Normalisation are topics within the A Level specification.

Carefully consider the database design before and implementation. Well organised data can be retrieved easily and help your program to work effectively.

Data Tables

Data tables will show the core properties of each field in your database, as well as the table name and keys used. Each table should have a data table associated with it.

There are several important things to show in your data tables:

1. Table name

2. Field names

3. Primary key

4. Any secondary or foreign keys

5. Data types

6. Validation

Data tables can be set up quite easily in a word processor like the example below which is for a Customer table.

Entity Relationship Diagram (ERD)

Entity Relationship Diagrams should be made for any database that you intend to create.

The minimum requirement for an ERD will be that it show all the entities (tables) and the relationships between them. Relationships will be given as one-to-one, one-to-many and many-to-many. ERDs can also contain attributes (field names) that are associated with particular entities.

The following is an example of an ERD for an ordering system. A customer has one order which contains many line items. Each order line contains a single item but an item may be ordered more than once on a different line or different order.

Algorithms

It is important that all algorithms for the solution are designed accurately and appropriately. The algorithms that are included in your design can be both algorithms that you have created and algorithms that you have found, such as the A* pathfinding algorithm or a method to sort a binary tree.

The algorithms will demonstrate how the more challenging or essential parts of your project work. They will also be used as evidence of the technical difficulty of your solution.

Algorithm Design

Algorithms can be described in a number of different ways. Typically a style of pseudocode that is similar to program code will be the easiest to use later during the creation of your project.

Some complex algorithms may require explanations of how they work in English or as flow chart to make them easier to understand.

The following are examples of how algorithms can be shown in your design section to show an algorithm. The examples show a very simple algorithm which will multiply two numbers together. The algorithms you will need to create will be much more complex.

Algorithm using structured English

This algorithm will need to take two numbers as inputs and multiply them together. The result will then be returned to the main program

Algorithm using pseudocode

function multiply (num1:int, num2:int)
result = num1 * num2
return result
end multiply

Algorithm using flow diagram

Improving algorithms

If you are developing your programs iteratively, you may find that the algorithm changes significantly from your first ideas. Whether the algorithm is simplified or becomes more complicated, it is important to record the changes in the design and the reasons for the changes. This will help with demonstrating excellent coding style because the solution will match the algorithm.

Data Structures and Advanced Techniques

Identifying and justifying your use of data structures will often be a significant part of the design process.

Your Design section should, where possible , demonstrate your use of technical skills from Group A below. Other data structures from Group B and C are worth adding to your report if they add to the clarity and understanding of your designs.

Each of these data structures has standard ways of being represented. If your project requires these structures, show the structure and then illustrate it in your report with sample data.

Remember that you need to justify your decisions. For instance, the use of a queue may be appropriate top determine the next player in a game due to the way the data structure provides the facility to add (enqueue) a new player to the queue and remove (dequeue) the player at the front of the queue.

Justifications for other data structured, classes or databases may include the simplicity of the program required, speed of execution or requirements for re-usability.

File Structure

A file structure shows how you plan to arrange files into folders or directories. The following is a simple example file structure for a dynamic website.

-settings.txt
-public_html
-javascript
-images
-css
-admin
-index.php
-index.php
-search.php
-results.php

For many apps and software programs, the file structures will be very easy to understand and can be described to aid understanding of the files and directories in the program.

For dynamic websites and applications, file structures may become more complex. Indeed, it is possible for queries to appear as a directory structure.

For example, the URL: https://www.mydynamicsite.co.uk/project/ideas/Jan/23, might not have directories for Jan or 23. Instead it might be converted to GET parameters that are interpreted using server-side-scripting. In this case, the taxonomy should be designed that shows how areas of the site are classified and grouped together.

Alternatively your project may be saving files with specific file formats and filenames to describe their content and make the correct file easier to import into your project later. If you were doing this you would need to explain this process.

HCI (Human-Computer Interaction)/Screen Designs

Designs should be shown for any point where the user interacts with the computer. This will probably be a screen design because almost all projects will need some sort of on-screen interaction.

When designing your Graphical User Interface (GUI) your need to think about where you will place all the objects you are adding to the screen so that they are clear and easy to use.

You may want to sketch these out by hand, use shapes and text in word processing software or you could use the designer on the IDE you will be using and take a screenshot of the design. You need to make sure that you are annotating your designs with the justification and reasons for your choice of the objects and style that have been used.

Hardware Selection

If your project only uses standard hardware such as a Windows Computer, you will not need to mention hardware selection or design.

If you are using any specialist hardware such as a raspberry pi, Arduino boards or connecting to other hardware components or peripherals then you will need to make sure these are listed. If you are joining hardware together to to use it in your project you may need to give circuit diagrams of how the hardware will be constructed.

Fully Articulated Design

You need to demonstrate that you have a fully articulated design for your project. Most projects will be produced using an iterative approach and this will mean that this will probably be produced over time.

Your design should allow a third party (such as your teacher or the moderator) to fully understand how your solution will work. It should demonstrate all the key aspects of the project that is being undertaken.