Project Documentation, Group B5
From SoftwarePractice.org
Project Documentation "Learning game for children"
The software project our group has chosen to undertake is the 'Learning game for children'.
The group sat down and thoroughly discussed what this project will involve and possible obstacles that we may face through each stage. In order to be able to move efficiently and effectively through the software development process, we decided to follow the MUP as closely as we can. Naturally, the first task that arose was to extract the requirements for the upcoming program.
In order to give a good depth of who is involved in these following scenarios, it is important to note who our stakeholders are.
Group Members - Contacts
Hassan - 0421127206
Swapnil - 0423201854
Dev - 0431180556
Keerthi - 0416523680
Discussion Page
The discussion page basically acts like a online meeting point where the work completed by group members is discussed. If any of our group members are unsure about their work, we discuss and give each other feedback or ideas on how to improve their work before they upload it on the wiki as their final document.
Discussion Page:
Talk:Project Documentation, Group B5
To do list
The group generated a To-Do-List is a table which organises the tasks that need to be completed. Tasks are allocated to each group member under "Owner". A brief outline of the task is provided under "Action" and the "Status" shows if it has been completed or is still in progress. We allocate a "Due Date" so that our group is always up to date and not falling behind. This method allows our group to collaborate the tasks and effectively helps us stay on track.
| Action | Owner | Status | Due | Comment/Update |
| Get pictures for the sentence database | Swap | Closed | 31/10/06 | Word Database finished, Picture Database finished & Sentence Database finished |
| Remake Sequence Diagrams, Class Diagrams and Update latest CRC Cards | Swap | Closed | 03/10/06 | In Progress |
| Figure out Java I/O with words/pictures | Hass | Closed | 20/10/06 | Word IO is 100%. No picture IO needed. Implemented in Game 1 and 2 class |
| Get main GUI/game classes running | Keerthi | Closed | 20/10/06 | Program up and running |
| System Testing | Dev | Closed | 20/10/06 | Near completition |
| Unit Testing | Dev | Closed | 20/10/06 | Completed |
| Put up Class Diagram | Hass | Closed | 25/9/06 | Completed 24/9/06 |
| Put up word list and picture database on wiki | Swap | Closed | 25/9/06 | Completed 24/9/06 |
| Update Use case Diagrams | Dev | Closed | 15/9/06 | Dev made it. I put it up on Wiki - Keerthi |
| Word List | Hass/Dev | Closed | 15/9/06 | Completed 12/09/06 |
| Sequence Diagrams and Collaboration Diagrams | Keerthi | Closed | 15/9/06 | Completed 24/9/06 |
| Upload use case diagrams | Hass | Closed | 12/9/06 | Completed 11/09/06 |
| Upload Contacts | Hass | Closed | 12/9/06 | Completed 11/09/06 |
| Update CRC Cards | Swap | Closed | 15/9/06 | Completed 12/9 |
| Picture Database | Swap | Closed | 15/9/06 | Found pictures between <=3 or 3<6< or >=6 letters for the picture database and uploaded onto the wiki |
| Update Use Case Tables & Format | Swap | Closed | 15/9/06 | Completed 12/9 |
| Create to do list | Keerthi | Closed | -- | Completed on 11/9/06 |
| ------ | ------ | ------ | ------ | ------ |
FINAL DOCUMENTATION
Main Stakeholders
What is a stakeholder?
A stakeholder is any individual, group or organisation that is affected by and/or have an interest in a particular issue; in this case our "Childrens Learning Game".
We decided that the most important and crucial stakeholders would be:
The Child
As the main user of the program.
The Parent(s) of the Child
As those wanting to monitor the progress of their child and change the difficulty level. Also giving them the options to add more words and change game naems. They will most likely use the program at home alongside their child.
The Teacher
As the person to be also monitoring the childs progress in many skills and introducing/ setting up this program in classrooms for the children.
Usage Scenarios
To begin with, we set out a few case usage scenarios . Being informal and easy to understand they are necessary to help us to focus on what the requirements of the software shall be.
Using these scenarios, we are able to develop a more focused, technical look at the system. With these we can take a close look at the functionality of the program. Obviously these will change as the weeks go by.
Usage Scenario 1
“I no doubt want my child to play games, but none the less an educational game, which will help my child to learn the skills to match a word to corresponding picture”
Usage Scenario 2
“I want to teach my child how to match a picture to its appropriate word. But when I try to teach him, he gets confused and frustrated. He likes playing games and I want a game that will teach him the skills to effectively learn this and also enjoy himself while learning it”
Usage Scenario 3
“My child has developed his skills and knows how to match pictures and words together. There needs to be an advanced version of this game, which will help him advance and excel. I want him to try matching pictures appropriate to sentences”
Usage Scenario 4
“My child is in pre-school and doesn’t know how to read yet. I want to teach my child the basics to begin with such as the alphabet but at the same time learn it on the keyboard as the alphabet is displayed clearly. This way he will have fun playing a game that teaches him the alphabet as well as get training on the keyboard which will help him in the future”
Usage Scenario 5
“My child has a problem when he counts. He tends to mix up the order and eventually gets confused. I want him to learn counting as soon as possible with the proper number system in a fun game environment”
Usage Scenario 6
“My kid has advanced and excelled from the basic games and finds the game too easy. I wish I can add more words which are harder and longer for him to find it challenging and keep playing”
Usage Scenario 7
“My child gets confused when selecting the games and always ends up selecting the wrong game to play. I need an option to name the game according to what he wants to call it for him to select the game when he wants without my help”
Essential Use Cases
The essential use cases allow us to bring the project one step closer to fruition. Having broken down the many tasks within the program into a certain set of activities from both the user and system, we are able to see how to implement these as classes and objects, and possibly hint at the methods to be used.
Essential Use Case 1
Essential Use Case 2
Essential Use Case 3
Essential Use Case 4
Essential Use Case 5
Essential Use Case 6
Essential Use Case 7
Use Case Diagrams
Use case diagrams describe what a system does from the standpoint of an external observer. The emphasis is on what a system does rather than how.
Use case diagrams are closely connected to scenarios. A scenario is an example of what happens when someone interacts with the system.
CRC Cards
Class-Responsibility-Collaboration cards (CRC cards) are a brainstorming tool used in the design of object-oriented software. They are typically used when first determining which classes are needed and how they will interact.
Using a small card keeps the complexity of the design at a minimum.
Sequence Diagrams
A sequence diagram is an interaction diagram that details how operations are carried out - what messages are sent and when. Sequence diagrams are organised according to time. The time progresses as you go down the page. The objects involved in the operation are listed from left to right according to when they take part in the message sequence.
This is a sequence diagram demonstrating how the name of a game is changed and how game 4 is executed. The MainMenu handles general configuration settings such as changing names, as demonstrated. Once it records user choices, it creates a new instance of GameHandler passing on these choices. GameHandler executes in this situation, the game4 option in a specific difficulty level, which creates an instance of Game4. Game4 does not collaborate with any other class. It runs the game on the back-end, displaying graphical letters on the front-end that correlate. It then displays a result at the end of the game. At the end of the game, it closes itself and the game handler down and goes back to the main menu.
This is a sequence diagram demonstrating how game1 is executed. The MainMenu records user choices and sets a generic difficulty. It then creates a new instance of GameHandler passing on the choice of game. GameHandler executes in this situation, the game1 option in a specific difficulty level, which creates an instance of Game1. Game1 creates an instance of WordDictionary to generate a set of questions by getting random words. It then runs the game and displays a result before terminating and returning to the MainMenu.
This sequence diagram details the process of appending a word to the data file and then starting an instance of game 2 . The user clicks on a button in the MainMenu GUI which correlates to a method being sent to GameHandler. In turn, the GameHandler object starts game 2, which then also accesses the WordDictionary object, in order to produce random words for the game. At the conclusion of the game, the obect is destroyed.
Collaboration Diagrams
Collaboration diagrams are also interaction diagrams. They convey the same information as sequence diagrams, but they focus on object roles instead of the times that messages are sent. In a collaboration diagram, object roles are the vertices and messages are the connecting links. Collaboration diagrams are good for showing iteration, concurrent behaviour and good for analysis. Unlike a sequence diagram, there is no linear order.
Class Diagram
A Class diagram gives an overview of a system by showing its classes and the relationships among them. Class diagrams are static - they display what interacts but not what happens when they do interact.
Within the program, the MainMenu is the class that starts the game, and hence it produces the GUI and shows the the main screen. Clicking on one of the buttons the user selects a game. This in turns creates a gameHandler object and calls a certain method to the gameHandler object(depending on which game and difficulty have been selected ) which then creates and starts a particular game. Games 1, 2 and 3 all require randomly picked words or sentences and hence they call upon the needed method from the wordDictionary class. Since a user can add words from the main menu, there is an association between the mainMenu class and the wordDictionary.
Picture Database & Word Database
For the 'Word Database' we decided to select and input words which were either 'Easy' or 'Hard'
Words less than or equal to four letters (<=4) are classed as Easy Difficulty.
Words greater than or equal to five letters are classed as Hard Difficulty.
This is the Word Database Table
We also had a Sentence Database. Level of difficulty for each sentence was decided upon by the group, keeping in mind the target audience for the program.
This is the Sentence Database Table
We found pictures corrosponding to these words and made a 'Picture Database'.
Here are some examples of the pictures.
Dog
Cat
Cow
Rat
Construction
| Main Menu GUI Interface | |
|---|---|
 |  |
| Game Prototype Screenshots | |||
|---|---|---|---|
 |  |
 | |
 |  |  | |
 |  |  | |
 |  | ||
Unit Testing
The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. Unit testing provides a strict, written contract that the piece of code must satisfy.
A unit test is a procedure used to validate that a particular module of source code is working properly. The procedure is to write test cases for all functions and methods so that whenever a change causes a regression, it can be quickly identified and fixed.
System Testing
Test Case runs through the program, checking that all functions work and meet required outputs for Game 1.
Test Case runs through the program, checking that all functions work and meet required outputs for Game 2.
Test Case runs through the program, checking that all functions work and meet required outputs for Game 3.
Test Case runs through the program, checking that all functions work and meet required outputs for Game 4 and also the added function of changing a password.
Test Case runs through the program, checking that all functions work and meet required outputs for Game 5.
Test Case runs through the program, checking that all functions work for adding a new word into the selected game.
Test Case runs through the program, checking that all functions are working for renaming a game name.
ALL Test Cases : All test cases have been run through the final version of the program and all have attained a "PASS". All test cases have been written to test the boundaries of the program to how a user may use them to test all of its functionality.
Instructor comments
Hi there... could you do some work to make your formatting easier to work with? Fix the oversized image, and group usage scenarios together, and use cases together? Decide which use cases you are going to use... Let me know when you would like more feedback -- JohnR 21 Aug 06
Hm, time to migrate the work on the CRC cards into a UML class diagram. Keep pushing!! JohnR 11:38, 9 September 2006 (UTC)
You need to complete all the artifacts. Those presented are good examples but a lot of it is only partially complete --Dawsonj 02:13, 8 October 2006 (UTC)
