| Home¡úReport |
You can download word formatted report or wait for the loading of the report on this page.
Click below to go to the specific part of our report:
3D Maze Generator Game 2002
Version 1.0
u Body
Ø Requirements Analysis and Specification
Ø Design
¡¡
In this practice, we are exposed to an application program called 3D Maze Generator Game. The game is basically to find the way out given the starting place and ending place with a given time limit.
The user can see the 2D view for just a while to help him/her to complete the game. The game is divided into 10 levels of difficulty. The time limit for each level is also different. Starting 10 minutes for level 1 (10 X 10 maze) to 28 minutes for level 10 (55 X 55 maze) with 2 minutes increment for each level.
¡¡
A primary goal of software engineering is to produce quality software systems. Once software has been developed and installed there are 3 different categories of people to whom good quality software is important:
These people/organizations have different criteria for quality; however these criteria are not independent. This interaction of the different quality characteristics makes an important point concerning the creation of a software system. Some common qualities that they look for are:
Broadly, software can be seen to have a childhood, adulthood, and retirement, just as humans do. During the childhood, the software is developed and tested. Once the software is matured, it is ready to go out into the world and serves its functions as an adult. As with humans, being adult does not mean development and change stop. Finally, the software is retired.
In this project, Maze Generator Game, we emphasize the activities in the production of the game. These activities are called software development cycle as shown below.
User interface design
Preliminary design
Detailed design and choosing a programming language
Coding
Unit testing
Integration
System testing
2.1. Requirements Analysis and Specification
We are adapting the ¡®5 W and 1 H¡¯ golden rule and use case diagram to help us to understand the requirements given to us.
We need to answer these questions when this stage is finished:
To answer question 1 and 2, we have built our use case diagram to see all the actors and the action that they will perform.
The above Use Case diagram can be described as follows: the user basically plays the Maze 3D game. The user can toggle the view to 2D to see the current position. The user can also see the time that he or she spends during the game. After the user finds a way out, the user will proceed to next level. Before proceeding to next level, the user can view the best solution to go out from the current maze. In case of not finding the way out, the user can see the best solution generated by computer.
We have been given a deadline by the lecturer which is due in Week 10. The proposed system must be able to be installed in Windows 95/98/NT platform and for the sake of demonstration; the system must be working in Design and Automation Laboratory.
The system is built to understand every step in software development cycle. There is no constraint of how the system will be developed. We are given a freedom to implement the software in any programming language, although object-oriented programming language is preferred.
In this project, we decide to choose object-oriented approach, though we have not chosen the language we are going to use. So, based on the requirements from client below, we propose a number of potential objects:
3D maze game: Maximum of 10 levels with the size of each level being increased linearly. The number of obstacles is linearly increased and randomly generated. The stairway to the next level is generated randomly to ensure that there is always a way to the next level. Time limit to complete the game. Computer should provide the best solution for each level of game. User-friendly interfaces is needed.
Potential Object/Class General Classification
3D Game Thing to remember
Player Role
Levels Thing to remember
Obstacles Thing to remember
Stairway Thing to remember
Timer Thing to remember
Best solution/Solver Thing to remember
User-friendly interface External entity
The maze Things to remember
Potential Object/Class Characteristics
3D Game the system
Player Accepted
Levels Rejected ¨C attribute of maze
Obstacles Rejected ¨C attribute of maze
Stairway Rejected ¨C attribute of maze
Timer Accepted
Best solution/Solver Accepted
User-friendly interface Accepted
The maze Accepted
The summary can be drawn as follows:
¡¡
Software Structure Design
We adopt the object-oriented methodologies. Object-oriented design is basically based on the use of data and procedural abstraction. The system itself comprises of collection of objects. The output is refined class diagram. The diagram can be seen as follows:
The interconnection amongst the classes can be described in a Sequence Diagram which is as below:
Detailed
Design and Choosing a programming language
In the
detailed design phase, the actual contents of each module in the proposed system
are design. A decision is made concerning the algorithm to be used in each
module.
Selecting a
Programming Language
As stated
before, the broad range of Java[tm] and its portability give us an idea of using
it for the system. Also, the client does not provide us with any programming
language. Moreover, most of us have been exposed to programming experiment using
Java[tm] in semester 3. Some features Java[tm] has that support our current
development:
Refining the
Class Diagram
To fit with
the actual implementation we need some other help classes to display the game,
as well as to play the game, for example Applet Class. Below is the final
refined class diagram:
User
interface design
The design
of the interface of the maze 3D game is crucial to the success of finding the
way out from a maze. Even though, we haven¡¯t concluded the programming language
yet at this phase. But most likely, we choose Java[tm] as our language. Given a
broad range of Java[tm] API and sophisticated GUI which are difficult to find in
any other language; we think the programmers and the users will find it
easy-to-learn and interesting.
This maze
game will definitely require the user to move forward, rotate left, rotate
right; hence it is almost never that a user enters a command or large number of
data. Also, to make user feel comfortable the options and other features will
have to be made simple, easy to understand, and do not block user view, or
distract user¡¯s view while playing. For this reason, we find that menu-based
display in an applet will be the best.
The Semantic Design of the User Interface for the System
Overall: The
major tasks for the user of the 3D Maze Generator are listed below. The order in
which the tasks are listed indicates the order the user will be required to
follow.
A.
Starting The System
Description:
Activities related to starting up the system
Task
sequencing:
1.
Open an internet
browser
2.
Run the maze.html
3.
Click open
B.
Playing The Game
Description:
Activities related to running the game
Task
sequencing:
1.
Use the arrows in
the keyboard to move until finding the place to proceed to next level
2.
Look the hints by
toggling the view (make it 2D)
3.
Travel until finding
the way out before time out
4.
See the best
solution
5.
Generate a new maze
Having known
the semantic design of the user interfaces for the game, we expect to have a
display like below:
First
Appearance
Main Menu
The game in
3D view
The game in
2D View
¡¡
Coding
As soon as
the coding of the modules begins, formal testing also begins. Throughout the
integration phase, coding and testing are closely interwoven. We adopt Bottom-up
integration for our system. In this method, the lowest-level modules are coded,
unit tested, and integrated first. Then modules from the next higher level are
added on, forming subsystems. Because of the incremental nature of this method,
it is easier to isolate errors.
In the
coding, we try our best to keep the code:
Unit
Testing, System testing, and Integration
For our unit
testing, we have to develop a simulating class to test the lower-level class. If
there is no error amongst the classes, then we proceed to integration level.
Even though,
there are 2 types of testing, namely White-box testing and Black-box testing; in
our system, we emphasize on the Black-box testing to make sure that any
combination of the inputs provide predicted outputs.
¡¡
User¡¯s
Manual
One of the
most crucial part of user interfaces is the user¡¯s manual. We purposely write a
user¡¯s manual to accompany the system to make users comfortable when playing.
Basically there are 3 different implementations of user¡¯s manual:
1. Reference
guide
2. Tutorial
3. User¡¯s
guide
We choose
user¡¯s guide implementation because the clients have different level of
understanding about the GUI of the software we¡¯re developing. We find that the
time of debugging the software is quite large in portion, so we also provide
additional last-minute information that did not get into the manual which the
users can read in README file.
In this
practice of developing software using a structured software engineering (SE)
concept, we find that we gain a lot in terms of developing quality software on
time. At the first time, we think using the software engineering concept will be
time-consuming and unnecessary. But understanding the complexity of the classes
that we develop, we find SE concept is very helpful particularly when the
requirement from the clients is still vague. We capture the idea of Use Case
diagram to satisfy the clients with what the product will do for them. Then, we
develop it into classes, and refine them as time goes by.
SE concept
basically divides software life cycle into certain phase:
1.
Requirement Analysis and Specification
2. Design
3.
Implementation
Every phase
has different outputs, and that can be a stick measurement for project manager,
particularly, and the development team, generally. ¡¡ CopyRight @ 2002 Victory
Software Ltd. All Rights Reserved.
