Practical Project: Design

UNIT 4 - ⇑ The Computing Practical Project ⇑
← Analysis	Design	Technical Solution →

This section should be where you are going to plan out your entire system before you build it. It doesn't always work out this way and you might find yourself coming back and changing things as you actually code your project. It is not recommended to write the design before you have done some coding. From your Analysis you should have an idea of what you are going to produce and have sourced some text books to get you started. Complete a couple of simple example programs before writing your Design, this way you'll have a better idea of the capabilities of the language you are using. And remember, don't be afraid to come back and change things!

Sections to Include

To get full marks you should aim to write something about all of the following. Some projects won't require all sections, for example you might not have a database and therefore have no need to include SQL. It's always best to check with your teacher about what you need to include.

Overall System Design

To give a clear idea of how we are going to complete our project it's a good idea to use an IPSO chart. IPSO stands for Input, Process, Storage, Output. Every project should have information under these headings. An example is below:

Input - these might include various types of human interaction and loading data from external sources such as databases, web feeds, scientific instruments etc.
Process - this is the important bit. What are you going to process, what is it going to calculate?
Storage - this will record all the ways that you are going to store data, it might include database table names, structure names and external files such as xml and csv.
Output - What will the end user be given, what will be output to the screen?

Let's take a look at an example:

Inputs	Processes	Storage	Outputs
User Details New purchase	Monthly sales Highest performing Salesperson Highest paying customer	Database tables: Customer Stock Item Purchase	Receipt Monthly sales chart

Modular Design

When you design your system you need to split it into smaller components. Like this book having different chapters about different things, your project should have different parts (modules) that do different things, but when they are combined they make up a complete whole.

There are two ways to split your project into modules, one is code based and the other is form based. Ideally, your project should be using both methods.

Form/Navigation Based

If your program has lots of different functions and uses a website or an application you probably have different pages to perform different tasks. You are also able to navigate from one page to another starting at your main menu. You need to show the different forms/pages that you use and how you would get from one to another:

Main Menu
- Adjust Products
  - Add Products
  - Remove Products
  - Update Products
- Sell Item
- Adjust Staff
  - Add Staff
  - Remove Staff
  - Update Staff
- Reports
  - Chocolates
  - Beer
  - Sausages

Even better than this you could draw a nice diagram on how everything links together.

Code Based

If you are writing a very complicated coding project then you might be using modules of code, some modules that build off other modules. You might also be using Classes and you need to show the class inheritance diagrams

Definition of data requirements (Design Data Dictionary)

Incredibly similar to your Analysis. If you haven't made any changes since then and it is normalised, just copy the data into here. You'll have to do a little more work in a second on the validation areas. Write down how the values are to be stored while the program is running and what data needs to be stored long-term, is the data to be stored in database tables or files?

Definition of record structure

If you are saving anything to text files or XML files mention here how those files are organised.

If you are using records or structures in your code mention them here and how they work.

Validation required

If you are getting the user to input data you will definitely need to validate the data that they insert. For example if you are getting them to fill in a new customer record you will have fields such as Title, First Name, Date of Birth, Number of toes. You want them to input data such as:

Mr.
Peter
16/07/93
10

And what will happen if they type in the following:

Mrr.
PeanutButter
jellytime
-8

Well it'll probably break your system, we need to prevent them from entering garbage into our system. If we allow rubbish data our calculations won't work, our reports will be wrong and the data will be useless. Remember this rule:

Garbage In, Garbage Out

To prevent garbage being input we are going to validate, that means check, each item of data that a person inputs into the system. We can do this in many ways

Validation Check	Description	Suitable Applicable Field	Valid data	Erroneous Data
Datatype	Checks that only a certain data type is inserted into a field. Such as a date or an integer	date of birth	18/02/97	13/13/13 or "clot"
Length	Checks that the data entered has the correct number of characters. For example a British phone number is always 11 characters, or the ID of a shopping item might always be 5 characters	Postcode	E4 7HJ	EEE668 JUY
Range	Checks that the data is within a set range, being greater than, less than, between, etc. For example the age of someone will be greater than 0, the number of days in a month would be greater or equal to 28 and less than 31.	Number of kidneys	2	45
Presence	This is when you need to make inputting data compulsory, the user isn't allowed to miss a field out. For example, they must state whether they agree or disagree with a legal statement, they must enter a postcode	Phone number	07070707070	(blank)
Lookup/List	This is when you only allow set values into a field. For example a Title would only allow for "Mr.", "Ms.", "Miss.", "Mrs.", "Dr.". Anything else would be erroneous. You can implement this normally by using a drop down list	Gender	Female	AttackHelicopter

Most of these validation checks are built into database packages, so if you create a database and then use a development suite to create the forms, the validation will be built into the forms automatically. If you don't have this privilege, you'll have to hard code it. That of course will come in the Technical Solution stage. Let's take a look at our original garbage data, did we manage to use validation to stop all the nonsense getting into our database?

Field Name	Validation Checks	Description	Error message	Data	Caught
Title	Lookup ("Mr.", "Ms.", "Miss.", "Mrs.", "Dr.")	only allow correct formatted titles	Please insert a valid Title	Mrr.	Yes
First Name	Presence	make sure name is a sensible length and present	Please insert a name	Peter8	No, we can't catch people being purposely malicious, you could try and code some checks but beware of the 'Scunthorpe problem'!
Date of Birth	Datatype(Date)	Make sure they have input a correct DoB	Please insert a valid date	jelly	Yes
Number of toes	14 > Length >= 0	Make sure they have a sensible number of toes	Please insert a number between 0 and 13	-8	Yes

For your report you need to write a table like the one above, though you can omit the last two columns.

Validation notation: Regex

When you are trying to enforce a format to data being input, you might want to use validation notation. For example if you want to specify that a class name must be a two digit number followed by three letters, for example 12PKP, You could write:

Or even more simply:

99LLL

The regex expression equivalent could be:

/^[0-9][0-9][a-zA-Z][a-zA-Z][a-zA-Z]$/

or

/^[0-9]{2}[a-zA-Z]{3}$/

File organisation and processing (if appropriate)

File sizes
Data Volumes

Database design including normalised relations (if appropriate)

If you are making a database then you need to include an E-R Diagram. You should show the diagram and explain what each of the relationships mean. For example:

A student can have many bookings
Each booking only has one student
Each booking only has one book
A book can be involved in many bookings

Sample of planned SQL queries (if appropriate)

If you are making a database you need to write about the SQL that you use to SELECT, INSERT, UPDATE and DELETE things from your tables. In some cases you might also be writing the code behind making the individual tables, the data definition language. In fact those headings are exactly what you need to use.

Reserved words

When you are querying your database you might get some unexpected errors, where a query fails to run when it doesn't appear to have any problem with it. This may be due to using a resevered word in your query. SQL has a lot of reserved words, words that have special meanings, and if you use one of these in a query it won't treat it as a field name. For example:

SELECT Username, Password FROM tblUsers

This might bring up an error as Password is a reserved word in SQL. To get by this problem you might want to change your fieldnames to something a little more sensible or put the fieldname in square brackets:

SELECT Username, [Password] FROM tblUsers

There are many other reserved words out there, so be careful:

PERCENT, PLAN, PRECISION, EXISTS, PRIMARY, PRINT, PUBLIC,
BACKUP, FOREIGN, READ,FREETEXT, FROM, REFERENCES, BULK, 
FULL, RESTORE, GROUP, IDENTITY, RULE, SAVE, INDEX, SELECT, 
STATISTICS, KEY, TABLE, NATIONAL, DATABASE, UNION, DELETE, 
DISK, ON, USER, PASSWORD

Different databases have different sets of reserved words, you can find a good list here

Note: If you are not using a SQL server (for example, using MySQL with PHP) you may need to use `backticks` instead of square bracket notation.

SELECT

This section should list all the SQL you have written that returns selections of records. You should describe in plain English where the SQL is used and what it does and then include the SQL with any annotations that you need. For example:

English Description:
This SQL statement selects the details (ID, Name, Price, Description) of a product which has been selected by the user. So that the user can view the product detail on the preview screen before buying the product

SQL:

SELECT ID, Name, Price, Description FROM Products
WHERE ID=?

INSERT

This section should list all the SQL you have written that inserts new records into your database. You should describe in plain English where the SQL is used and what it does and then include the SQL with any annotations that you need. For example:

English Description:
This SQL statement adds a new high score along with the date the score was achieved for a users account.

SQL:

INSERT INTO Scores (ID, DateofScore, Score)
VALUES (?,?,?)

UPDATE

This section should list all the SQL you have written that updates an old record with new details. You should describe in plain English where the SQL is used and what it does and then include the SQL with any annotations that you need. For example:

English Description:
This SQL statement updates the date of birth of a user, after they have updated the form that launches when they first log into the program.

SQL:

UPDATE User
SET DoB=?
WHERE ID=?

Data Definition Language

If you have designed your database tables using a program such as Open ModelSphere you can then define the code behind making your tables which you can then feed into MySQL or MSSQL to create your database. Get some credit for this and list your DDL. For example, the command to create a table named employees with a few sample columns would be:

CREATE TABLE employees (   
    id            INTEGER   PRIMARY KEY,
    first_name    CHAR(50)  null,
    last_name     CHAR(75)  not null,
    dateofbirth   DATE      null
);

Identification of storage media

(Note: not required for new AQA spec)

This is quite easy if you remember the hardware section of Unit 2. You must recommend how your system will be distributed to and then run by the user.

You need to start off by calculating how much space the program will take up to distribute and how much space it will take up when it is running.

Distributing your software will require that you transmit the data to the user somehow. This could be through a CD-ROM, USB drive, DVD-ROM or internet connection. Why would you pick each? Which would be most suitable? Think about security, speed, having a backup, size of files to transmit.

Running the system will in most cases require the user to be able to write new files to your system, saving high scores, new purchases etc. How big will the system feasibly get? You need to recommend something that will allow the user to read and write to, something that is secure and reliable, and something that will be big enough and fast enough to handle everything. A CD-ROM would not be suitable here, why? Hard Disks could be suitable, why?

Identification of suitable algorithms for data transformation, pseudocode of these algorithms

You will be asked to provide examples of designing your code. If you have lots of code then pick the 6-8 most interesting examples. For each bit of code try to include the following:

Title
Plain English explanation
Pseudo code

For example with a log in screen you could write the following:

Plain English

This code takes the username and password input by the user and then checks them against the login details stored in the login file.

Pseudo Code

var userName = Textbox.username var password = Textbox.password

load the acceptable login names and passwords from the text file and store it into var acceptableLogins

If userName and password are in acceptableLogins Then

Login Allowed

Show Menu screen

Else

Show error message

End If

Class definitions(diagrams) and detail of object behaviours and methods (if appropriate)

this is a simple diagram, you would have to explain each of the attributes and subroutines

If you have used Object Orientation in writing your program (highly recommended to get in the top mark band) you need to describe it here. You must mention the following:

Class names
Any inheritance
Attributes (variables) and whether they are public or private, explaining what they are for
Function names with return values and description
Procedures names with return values and description
Any overriding performed

User interface design (HCI) rationale

In all projects you will have some form of user interface, in nearly all cases this will be a GUI. This section actions you to show and explain the methods that you are going to capture data (inputs), and the ways you are going to display/print out data(outputs). Notice in each case it says sample, so you don't have to show how every form/printout will look, 4 examples of each should suffice. You could hand draw each, or draw them using an arts package like inkscape, alternatively you could design them in a package like Visual Studio and use the design views of the form. DO NOT use screen shots of the final code running, we need to see your designs.

UI sample of planned data capture and entry designs

This section needs to show the designs of your forms / interfaces. Don't be afraid to include early screen shots of forms in design view. Remember we are not marking this section on working code, but on the design ideas behind each form / interface. You must mention your reasoning:

Tick Boxes / radio buttons
Drop down lists
positioning of elements
colour schemes
ease of navigation

You can do this by annotating each screen shot.

UI sample of planned valid output designs

This might be one or more of several things:

the designs of reports that your system is planned to produce
the high score board of a game or quiz
the game screen showing points health etc.
a graph showing data
anything that is calculated and shown to the user

Using the same rationale as the previous section you must complete annotated versions of these.

Description of measures planned for security and integrity of data

(Note: Not required for new spec)

Security and integrity are slightly different things.

Security means preventing unauthorised people accessing areas of your work. This might include students accessing each others marks for a test, customers accessing other customers' details, students accessing the marks to a test or anything that conflicts with the data protection act. To do this you need to implement security systems such as usernames and passwords, access rights and restricted areas. You might have certain buttons and areas that only appear for certain users. If they are restricted users there will be parts of your system that they won't see, and for the admin user, they should be able to see everything.

Integrity is making sure that your data doesn't 'corrupt'. This means making sure that certain bits of data always take on the correct format or don't violate certain rules. For example, if you had a date of birth, you wouldn't want people to be inserting their name in that field. How do you do this? With validation rules. Write about them here. You might also want to make sure that your database maintains its referential integrity. This will prevent people linking to records in other tables that don't exist. Talk about how you would do this.

Description of measures planned for system security

(Note: Not required for new spec)

You don't want unauthorised people gaining access to your data. This might include stalkers trying to find out personal details stored on your system, students trying to cheat etc. You might recommend that the end user keeps data in secure locations or behind operating system passwords. Or that there is a main password to get into your system.

You should also mention how the system will be recovered in the circumstance that it becomes corrupted or lost. Mention the method by which you will recover the system/reinstall etc.

Overall test strategy

(Note: Not required for new spec)

There are several different ways that you could test your system. This section asks you to consider each and mention how you are going to test your system with regard to each. Don't just describe each, you must talk about how you will use them to test your system.

Black-box testing

Black box testing diagram

In this mode you don't care about the code behind what you are testing, you just know what results should come about from particular data inputs. This is useful for complex sub routines that have multiple possible inputs. For example testing a search algorithm. If you do come across any problems then you will have to find and fix them. For that we use...

White-box testing

White box testing diagram, where each coloured line is a route through the code

In this you are going to test as many routes 'through' your code as you can. This means looking at your code and trying to come up with tests that will test every logical statement that you have written. For example if you have an if statement that checks if a password is correct or not, put a test in place to see if it works when the correct password is inserted AND when an incorrect password is inserted. Things you should include:

If statements
While loops

Trace tables

This is a great way to find and fix problems. You should try to pick two or three of your most complex pieces of code to perform a trace table upon. By using this you prove that the code works.