Practical Project: Design
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[edit | edit source]
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[edit | edit source]
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:
Highest performing Salesperson
Highest paying customer
Monthly sales chart
Modular Design[edit | edit source]
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.
[edit | edit source]
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
- Adjust Products
Even better than this you could draw a nice diagram on how everything links together.
Code Based[edit | edit source]
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)[edit | edit source]
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[edit | edit source]
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[edit | edit source]
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. Pea nut Butt er 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||69|
|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||Attack Helicopter|
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.
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:
The regex expression equivalent could be:
File organisation and processing (if appropriate)[edit | edit source]
- File sizes
- Data Volumes
Database design including normalised relations (if appropriate)[edit | edit source]
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)[edit | edit source]
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.
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
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[edit | edit source]
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:
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
SELECT ID, Name, Price, Description FROM Products WHERE ID=?
INSERT[edit | edit source]
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:
This SQL statement adds a new high score along with the date the score was achieved for a users account.
INSERT INTO Scores (ID, DateofScore, Score) VALUES (?,?,?)
UPDATE[edit | edit source]
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:
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.
UPDATE User SET DoB=? WHERE ID=?
Data Definition Language[edit | edit source]
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[edit | edit source]
(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[edit | edit source]
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:
- Plain English explanation
- Pseudo code
For example with a log in screen you could write the following:
Plain English[edit | edit source]
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[edit | edit source]
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
- Show error message
Class definitions(diagrams) and detail of object behaviours and methods (if appropriate)[edit | edit source]
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[edit | edit source]
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[edit | edit source]
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[edit | edit source]
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[edit | edit source]
(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[edit | edit source]
(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[edit | edit source]
(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[edit | edit source]
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[edit | edit source]
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[edit | edit source]
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.