Project Documentation for Group A3
From SoftwarePractice.org
Contents
|
AUOTOMOTIVE SIMULATOR
Introduction: Project Objectives
After discussing as a group, all project options, we came to a neutral agreement to do the “Automotive Simulator”. We began by making brief notes about the minimum requirements needed to be included so that the end users get the essentials of vehicle control. We came up with four essential requirements and these are:
• Accelerating
• Braking
• Steering
• Engine power
We believe that each of the above points will allow sufficient simulation of the main inputs of a driver and ultimately adequately equip them with knowledge of the behavior of a vehicle, as a result of the manner in which those inputs are applied.
Inception Phase
The Inception Phase was concerned with determining the scope and purpose of the project. This phase solidified who the key stakeholders are and our key concerns for each one. The challenges of the project were discussed further and risks were identified. From this phase we were able to proceed to the Elaboration phase.
Stakeholders
Individual and Corporate Client – Key concerns include:
• Assurance the program is an accurate simulator of vehicle control.
• Functionality of the program that it provides all the functions they require.
• Ease of use of the program. Easy to use and easy to learn from.
Software Developers (our group) – Key concerns include:
• Developing the program with full functionality required by the end users.
• Making sure the simulator is as accurate as it can be.
• The program is easy to update, add complexity and provide other functions for future markets.
• Easy to use interface.
• Timing. Making sure the program will be available to distributors at the agreed time.
• Quantity. Making sure there will be enough copies to be distributed amongst merchants.
Distributors – Key concerns include:
• Availability. Having enough stock available to meet customer demands.
• Price.
Challenges
- The software overlooks certain special case scenario's like weather conditions and gear functionality.
- There is unclear user conception of what tools the user likes to help him better understand how the motor vehicle behaves.
- The time frame to build the program whilst considering every possible constraint which would make the program more realistic is too shallow. Such considerations as tyre wear, cargo weight, sliding friction and other properties which would lead to a more realistic simulator are outside the scope of our time frame.
- Integrating the time and distance in order to produce accurate distance calculations.
Software Maintenance/Admin – Key concerns
- Software documentation. That the software is documented adequately so that updating and maintaining is as easy as possible.
- The program is completed by the due date.
- The program is adequatley tested so that it runs efficiently and does not contain bugs.
Risks
- Forgetting user requirements, which were stated in the original project document.
- Not correctly de-bugging the program, so in the future errors occur, rendering the program useless.
- Not correctly following the design plan and forgetting requirments, which later on may not be able to be implemented into the program.
In order to explain the functionality the software will ultimately provide, our team has created four scenarios of certain situations where the software application can be of critical use in the learning and understanding of vehicle control. The following details the scenario's (one of which is a true case) created by the team and the associated essential use-case diagrams. Each essential use case diagram has been roughly drawn up to explain what the system will do eventually, in order to meet the requirements of each scenario.
Elaboration Phase
The elaboration phase focuses on requirements capture and determining the structure of the system as a whole. It contains the details of the scenarios and their essential use-cases. The class diagrams are included and have been reviewed three successive times, throughout the design process. The collabration and sequence diagrams have been reviewed again also in more detail, inlcuding the changes that were made as the program was modified throughout its development. The last section highlights the interface prototype design of the program as a sketch and as a final design. The elaboration phase then proceeds into the construction phase.
Scenarios And Their Essential Use-Cases
1. Scenario
"John is given the program to run for the first time. He knows the purpose of the program, however he is oblivious as to how to make the program do what he wants it to."
1. Essential Use-Case: Reading the instructions and selecting an engine type
2. Scenario
“A driver usually drives a V6 Ford XR, but his friend has allowed him to drive his V8 Holden SV. Thinking he is now king of the road, the driver exceeds the speed limit to overtake and crashes. The driver's statement to the police stated: "I did not know I was going that fast" after being told his estimated speed when he crashed was 95km/h.”
2. Essential Use-Case: Determining the speed of the car
3. Scenario
"A driver is speeding when the lights turn amber. He brakes hard but can not stop in time and ends up in the middle of the intersection. He can not understand why it took the car so long to stop stop"
3. Essesntial Use-Case: Determining the braking of the car
4. Scenario
"Whilst making a right hand turn, Person A over turned the steering wheel, mounting the gutter crashing into a retaining wall. After an interview with the professional driving instructor (Gary Carr), it was concluded Person A was unable to judge the amount to turn the steering wheel for different turns"
Courtesy of Learn it Right driver education.
4. Essential Use-Case: The Steering of the car
Use-Case Diagram
The following use-case diagram depicts the functionality of the system from the user's perspective. Firstly, the user will be able to determine the acceleration of the car, depending upon certain values. These will include things like the weight, frontal area, engine capacity, drag coefficient and speed of the vehicle. Secondly, the user will be able to determine the braking of the vehicle. These will depend on the same values that were calculated for the acceleration but will also include the distance travelled by the vehicle and direction. Thirdly, the engine power conditions will be set by the user determining what type of engine is being used. This either being a four cylinder, V6 or V8 engine. Typical values of each engine type will also be set by the user before running the program. And lastly, the steering will be used by the user to determine their limitations when travelling around corners. The system will respond by telling the user that they have over-steered and then allow them to continue driving. Thus, the use-case diagram has broadly identified the main uses that the user will need in determining their capabilities behind the wheel of a car.
Class Diagram - Review 1
This first class diagram has been set out to determine the classes and what attributes and methods should be contained within them. The main class is to used to start and initialize the program. From here the MainWindow class will be linked because it is responsible for initializing the game. The other classes of the program will be called from within the MainWindow, thus initializing the automotive simulator.
The Car class is constructed in order to contain all the attributes and methods for the car. These will include the speed, braking, steering and distance of the car. Other specific attributes will include the weight, drag coefficient, engine power and many more. The Car class is linked to the MainWindow and the Display class.
In linking to the display class the Car class is being applied to the interface. The Display class will contain the values of the vehicle and its environment and place them on the user interface. These values include the time, speed, direction, vehicle display and the background display of the car. The Display class is once again linked to the MainWindow and also linked to the Driver class.
The Driver class contains values which are sent to the Display class to be displayed to the user in the form of buttons. These buttons will include accelerate, brake, left and right. There will also be an option in the Driver class for choosing what engine type the user wishes to use. The Track class is linked to the MainWindow.
The Track class contains methods which design the tracks for the car to run on. Only the basic idea of the track class has been thought out, once programming starts we are looking to see how we will implement the GUI in order to develop this class. The Animation class is linked to both the MainWindow and the Track class.
The Animation class will contain the methods which cause the track and car to move. Once again the implementation of this method has been left undecided until programming begins.
Thus, the initial class diagram depicts the structure of the classes with their attributes and operations (to some degree), together with very simple links between classes
Class Diagram - Review 2
The second review of the class diagram has only been updated in terms of the associations between classes. The vehicle and display class will have a one way association as will the track and animation classes. All other classes will have two way associations.
The vehicle will be “placed” on the display. This means that once the parameters for the vehicle have been set, the actual vehicle itself will be displayed. There is zero to many associations between both of these classes and for one MainWindow there will be zero to many cars.
The track class will be “allocated to” the MainWindow because the MainWindow class is what initializes the program. This is the same for the vehicle class. For one MainWindow there will be two tracks.
The vehicle class “liaises with” the driver class simply means that it will exchange information about the vehicle’s current status in the program in order to update one another. For zero to many cars there will be zero to five buttons.
The MainWindow will “conduct” the animation class by telling the animation class how to operate and when to perform its operations for the GUI of the program. For one MainWindow there will be zero to many animation objects.
The track class is “applied to” the animation class, which simply implies that the track will be placed on the interface of the program for the user to view, by the animation class. For every two tracks there will be zero to many animation objects.
Thus, the second review has highlighted the interactions between all the classes and why these will occur in the production of the program.
Class Diagram Review 3
Review three of the class diagram is the last and final review of the program, which changed throughout the programming and implementation of the automotive simulator.
The class names have changed, but the functionality of each class has remained relatively the same. There are seven classes in total, with the Main class being the initiator of the program.
The Main class holds the objects of all the other classes. It is associated with both the KeyboardButton class and the Interface class. Both of these classes have a one to one association with Main.
The KeyboardButton class contains the attributes and methods for the buttons and accelerator widget. These functions allow the user to drive and control the vehicle. The KeyboardButton class is associated with the Interface, Vehicle and Update classes. It has a one to one association with the Interface class and is “applied to” this class, which means that the buttons and widget are set on the interface for the user to observe. The KeyboardButton class has a one to one association with the Vehicle class and “liaises” with this class. This simply means that the KeyboardButton class obtains data from the Vehicle class, so that it can be updated regularly when the program is running. The KeyboardButton class is also associated with the Update class, in that the Update class “updates actions” between itself and the KeyboardButton class. As actions are performed by the buttons the Update class continually updates the timers and other attributes contained within it. For every action in the buttons class there are zero to many updates in the Update class.
The Update class contains the attributes and methods for the timers, process details, speed and track implementation. The class loops on itself from the timer method through to the class constructor because time is being continually updated. This class has associations with the KeyboardButton class, Vehicle, Interface and Instruct classes. The Update class “sets parameters” for the Vehicle class by determining the time and distance traveled by the vehicle. These values from the Update class are used in turn in the Vehicle class. For every update there is zero to many parameters set in the Vehicle class.
The Instruct class contains the method for creating the instructions frame at the start of the program. It is associated with the Update class in that it is “implemented” by this class. These two classes have a one to one relationship.
The Vehicle class contains the attributes and methods that define the vehicle. These include specific parameters of the vehicle itself, as well as parameters such as speed, distance and direction.The Vehicle class is associated with the Interface in that it is “applied to” the user interface. For every vehicle there is one interface that is displayed with the cars details. The Vehicle class has its “parameters set” by the MainMenu class, which obtains values of the vehicle from the user and sends these to the Vehicle class. For every MainMenu there is one to many attributes of the vehicle that are set in the Vehicle class.
The MainMenu class contains the methods for displaying a menu for different engine types. These engine types can be selected by the user and once the engine is selected the user is prompted to enter in the values of the vehicle before commencing the program. The MainMenu is associated with the Interface class in that it is “allocated to” the user interface. For every menu there is one interface.
The Interface class contains the methods and attributes of the interface GUI. It sets up the main user interface with the pictures and user displays. It is called by Main at the beginning of the program, in a one to one association. The Update class is associated to the Interface in that it is “allocated to” the user interface. The Interface class calls the Update class in order to display the timers, speed, crash dialog and repaint the track pictures. For every update there is one change in the interface.
Therefore, the final revision of the class diagram identifies exactly how the program will work and function. All the structures of the classes have been defined, together with their associations between one another.
Collaboration Diagrams
Accelerate
1. When user presses up-button, an event will be occurred in KeyBoardButtonClass.
2. KeyBoardButtonClass class calls method setDirection passing “straight” as parameter in vehicle class
2.1. vehicle class calls setspeed method passing accleratorSlider.setValue as parameter in interface class.
3. KeyBoardButtonClass Class calls method setSpeed passing 1 as parameter in vehicle class.
3.1 update Class calls method getspeed() to get speed from vehicle class
3. Update class calls method getDirection() to get speed from vehicle class
4. update class calls method repaint in interface class. Repaint method shows the screen with any changes
5. processDetails is called by class interface. This will calculate all details of the screen.
Decelerate
1. When user presses down-button, an event will be occurred in KeyBoardButtonClass.
2. KeyBoardButtonClass class calls method setDirection passing “straight” as parameter in vehicle class
2.1 vehicle class calls setspeed method passing accleratorSlider.setValue as parameter in interface class.
3. KeyBoardButtonClass Class calls method setSpeed passing -1 as parameter in vehicle class.
3.1 update Class calls method getspeed() to get speed from vehicle class
3. Update class calls method getDirection() to get speed from vehicle class
4. update class calls method repaint in interface class. Repaint method shows the screen with any changes
5. processDetails is called by class interface. This will calculate all details of the screen.
Turn Right
1. When user presses right-button, an event will be occurred in KeyBoardButtonClass.
2. KeyBoardButtonClass class calls method setDirection passing “right” as parameter in vehicle class. So that direction is set as “right” in vehicle class
2.1. vehicle class calls method setDirection passing “right” as parameter in interface class So that direction is set as “right” in inteface class
2.1.1 method processDetails is called by class interface. This will calculate all details of the screen.
2.1.1.1 update class calls getSpeed in interface class. This method will return speed to update class
2.1.1.2 update class calls getDirection in interface class. This method will return direction to update class
2.1.1.3. update class calls method repaint in interface class. Repaint method shows the screen with any changes
Turn Left
1. When user presses left-button, an event will be occurred in KeyBoardButtonClass.
2. KeyBoardButtonClass class calls method setDirection passing “left” as parameter in vehicle class. So that
direction is set as “right” in vehicle class
2.1. vehicle class calls method setDirection passing “left” as parameter in interface class So that direction is set as “left” in inteface class
2.1.1 method processDetails is called by class interface. This will calculate all details of the screen.
2.1.1.1 update class calls getSpeed in interface class. This method will return speed to update class
2.1.1.2 update class calls getDirection in interface class. This method will return direction to update class
2.1.1.3 update class calls method repaint in interface class. Repaint method shows the screen with any changes
Choose option
1. user press button “Choose your engine type”, an event will be occurred in actionPerformed() in mainMenu class.
2. mainMenu Class calls setWeight() in Vehicle class. This method asks user the value of Weight.
3. mainMenu Class calls setDragCoefficient() in Vehicle class. This method asks user the value of DragCoefficient.
4. mainMenu Class calls setEngineCapacity() in Vehicle class. This method asks user the value of EngineCapacity
5. mainMenu Class calls setFuelCapacity() in Vehicle class. This method asks user the value of FuelCapacity.
6. mainMenu Class calls setFrontalArea() in Vehicle class. This method asks user the value of FrontalArea
Sequence Diagrams
Sequence Diagram for Choosing Engine Type and Setting Vehicle Attributes
Following is the sequence diagram for use case "Reading Instructions and Selecting an Engine Type". When the user clicks on the menu button, a JOptionDialogBox appears, asking the user to select the Engine Type from the dropdown menu. After doing so, he is asked to set the attributes for the engine type chosen.
actionPerformed() method in the KeyboardButtonClass first takes the Engine type from the user, it then takes the attributes such as; weight, drag coefficient, engine capacity and frontal area from the user and stores them in the respective methods in the vehicle class.
Sequence Diagram for Determining the Speed of the Vehicle
Following is the Sequence Diagram for the use case Determining the Speed of the Vehicle". When the user presses the UP arrow on the key board, the vehicle atarts accelerating, which means that the distance and speed values start increasing. Once distance hits a certain value, the track changes direction, depending on the initial offset. This process continually repeats itself, until the user stops pressing the up arrow.
keyPressed(VK_UP) method in the KeyboardButtonClass takes the input from the user. It then calls the setDistance(1) method in the Update class, which maintains a timer of its own. It then calls the Interface class with increaseDistance()[this method increases the value for the acceleration slider], setDistance()[this method increases the value of distance on the display] and repaint()[this method changes the track image depending on the distance offset] method. The speed(1) and direction(0) values to the vehicle class are set by calling setSpeed(1) and setDirection(0) methods.
Sequence Diagram for Determining the Braking of the Vehicle
Following is the Sequence Diagram for the use case Determining the Braking of the Vehicle". This sequence diagram is similiar to the previous one, the only difference being that this works the opposite and describes the sequence when the user is decellerating.When the user presses the DOWN arrow on the key board, the vehicle atarts decellerating, which means that the speed value starts decreasing. This process continually repeats itself, until the user stops pressing the DOWN arrow or the speed hits "0", when the track, is no long synchronized with the timer and does not change and further.
keyPressed(VK_DOWN) method in the KeyboardButtonClass takes the input from the user. It then calls the setDistance(0) method in the Update class, which maintains a timer of its own. It then calls the Interface class with increaseDistance()[this method decreases the value for the acceleration slider], setDistance()[this method increases the value of distance on the display, based on decreasing speed] and repaint()[this method changes the track image depending on the distance offset, until the speed hits zero, it then remains in the state when the speed hit zero] method. The speed(0) and direction(0) values to the vehicle class are set by calling setSpeed(0) and setDirection(0) methods.
Sequence Diagram for Steering of the Vehicle
Following is the Sequence Diagram for the use case "Determining the Steering of the Vehicle". The sequence diagram here describes sequence that follows when the user presses the right arrow. The sequence of steps is similiar for when the user presses the LEFT arrow. So it has not been described here..
When the user presses the RIGHT arrow on the keyboard, the vehicle starts to drift right. Here the speed value remains constant. However, if the user continues to drift right, the crash() method will be called, if he drifts off the road. Then the distance and the speeed will be reset.
The KeyboardButtonClass instructs the Update class to check, if there is a crash, when the event is a RIGHT press on the keyboard. If the result is true, the update class calls the Vehicle class, and resets setDistance(0) and setTrackX(0)[that is the car will be reset to the middle of the screen]. If the crash() method hasn't been invoked, the setDirection() and setSpeed(1) methods of the vehicle class will be called to set the respective values. Since, there is no change in speed, the vehicle class will not ask the Interface class to update the speed. However, it will ask the interface, class to update the direction, setDirection().
Proposed User Interface
The following is a mockup of what we are aiming to achieve. The interface will contain a menu at the top of the screen.This menu will allow the user tp pick which engine type(V4, V6 or V8) that they wish to use. After they have choosen an engine type the user then will be able to enter values in for the vehicle, which will be prmopted by the system. if the user does not use their own values the system will provide default values for the user. The interface also contains a display for the attributes of the vehicle. These include the time, speed, distance, direction and fuel. A speedometer will also be provided, which will be created as a widget. The interface then shows the actual background and the track. The track will be animated so that it moves from left to right. The bottom of the screen displays the buttons for the vehicle and the inside display of the car. This is our initial vision of the interface, a more elaborate version will be developed, which includes an instructions frame at the beginning of the program.
Contracts: Pre and Post Conditions
The following contracts look at the pre and post conditions for the system. The conditions must be satisfied before the operations can take place and the conditions should still apply after the operation has been completed. The following contracts were written for the GUI interface, the vehicle and its specifications and the update methods for the program. They each state the pre and post conditions that must be met and how these conditions are implemented into the program code.
Construction Phase
The construction phase highlights the development of the program and the building of the software. The use-cases were revised and further detail was added to the designs in order to depict the user needs at a more comprehensive level. The unit tests and system tests have also been inlcuded to demonstrate how the system was tested throughout its construction. Further explanation of these is included below. The next phase that was entered was the transition phase.
Revision of Use-Cases
The following essential use cases are reviews of the initial essential use cases presented earlier in the elaboration phase. They take into consideration the end-user version of the program and provide the actual steps required to be performed so that the scenarios also presented in the eleboration phase can be modelled adequately.
1. Essential Use Case Review: Reading the instructions and selecting an engine type
2. Essential Use Case Review: Determining the speed of the car
3. Essential Use Case Review: Determining the braking of the car
4. Essential Use Case Review: The steering of the car
Unit Tests
A unit test is used to test the correctness of a class in storing and returning variables. The test cases below are all part of testing our Vehicle class. The vehicle class is an integral part of our program and therefore must be able to store and return the correct variables otherwise the program is literally useless. As is evident from the tables below, our methods rely on a pre-condition, that is, the checkValue variable. This variable is always set by the mainMenu class so that a valid checkValue is always stored for use in the pre-conditions for the methods of the Vehicle class.
System Testing
The following system tests test the GUI and event-handling classes in our program.
Class specification: Instruct
Class Instruct
Purpose: This class shows instructions to the user, it is displayed at the beginning of the program on top of the main frame.
General user interaction: Left-button click on OK button: closes the frame.
The input for this class is in the form of user-initiated mouse events.
The output is a visible change, in this case, the frame closes.
Attributes: okButton.
Operations:
actionPerformed(me: ActionEvent)
Input: me: ActionEvent
Output:
Pre-condition: An action event of type MOUSE_PRESSED has occured.
Post-condition: If the left mouse button has been pressed on the okButton the dialog will close.
Class specification: KeyboardButtonClass
Class KeyboardButtonClass
General user interation:
The (non-numpad) up-arrow allows the vehicle to increase in speed.
The (non-numpad) down-arrow allows the vehicle to decrease in speed.
The (non-numpad) left-arrow allows the vehicle to steer left.
The (non-numpad) right-arrow allows the vehicle to steer right.
The input for this class is in the form of user initiated keyboard events.
The output is visible changes on the user interface, including the slider moving to the left or right showing changes in speed, the distance timer incrementing showing a change in distance.
Attributes:
acelerateBtn: Allows the vehicle to speed up
brakeBtn: Allows the vehicle to slow down
leftBtn: Allows the vehicle to steer left
rightBtn: Allows the vehicle to steer right.
frame: initiates the interface class
userCar: initiates the vehicle class
Updater: initiates the update class.
acceleratorSlider: Moves to show and store the current speed
Operations:
keyPressed(me: KeyEvent)
Input: me: KeyEvent
Output:The slider has moved if up-arrow or down-arrow have been pressed.
The txtSpeed in interface is updated.
The txtDirection in interface is updated.
Pre-condition: A keyboard event of type KEY_PRESSED has occured.
Post-condition: The slider has moved depending on whether the up or down-arrows have been pressed.
The txtSpeed is updated according to slider position.
The txtDirection is updated according to whether the left or right-arrows have been pressed.
stateChanged(me: ChangeListener)
Input: me: ChangeListener
Output: The accelerator slider moves depending on how the state has changed
pre-condition: An event of type KEY_PRESSED or SLIDER_DRAGGED has occured
Post-condition: If the slider has moved, the value of the slider is converted to a string and shown in the txtSpeed display.
actionPerformed(me: ActionListener)
Input: me: ActionListener
Output: The displays for direction and speed change depending on what action was performed.
Pre-condition: A key event of type KEY_PESSED has occured
Post-condition: If the left arrow is pressed, the value -1 is stored in self.userCar.direction variable indicating to display "left" in the txtDirection display box.
If the right arrow is pressed, the value 1 is stored in self.userCar.direction variable indicating to display "right" in the txtDirection display box.
If the up arrow is pressed (and released), the value 0 is stored in self.userCar.direction variable indicating to display "straight" in the txtDirection display box.
If the up arrow is pressed and not released, the value 1 is stored in self.userCar.speed variable indicating that the car is accelerating.
If the down arrow is pressed and not released, the value -1 is set for self.userCar.speed variable indicating the car is decelerating.
System Tests
The system test below tests the instructions frame, the main frame and the main menu for functionality in terms of frames being displayed and ensuring the event listeners are working correctly. It also tests that the timer display on the userpanel increments when the instruction frame closes.
Assume blueJ is running with the vehicle simulator project open within blueJ
The system tests below test the functionality of the arrow buttons on the keyboard to ensure they are working correctly. They also test that the acceleratorSlider is working and all the displays, that is; the time, distance, speed and direction all display correctly according to the keyboard buttons invoked.
Assume blueJ is open with the vehicle simulator project open within blueJ. Also assume values have been entered into the system in the fashion described in the first test case
Transition Phase
The transition phase is the last and final phase of the project and deals with the product installation and presentation. This final phase highlights the end product and demonstrates its capabilities. The test - cases highlight what the program can do and its success rate. The further developments of the product are discussed in further detail below. These show how the program can be improved and the reasons for doin so. Thus, the transition phase concludes the project and the project documentation itself.
Polished User Interface
The interface that was created for the program, as well as all the input and message dialogs, appear below. This GUI and its corresponding dialogs were exactly what we were aiming for and mimics our initially proposed user interface. The exact description for each feature is decsribed in the above documentation. The GUI is left open to be imporved with further implementation of such things as dials for the speedometer and taco will improve the visualalisation as well as the realism of our simulator.
Further Developments
The Automotive Simulator has been designed so that other areas of the program can be developed further, depending upon the users needs and wants. The areas that can be developed further include the following:
• Vehicle display: The vehicle display currently displays a fuel gauge, taco and speedometer. All three of these pictures can be developed further in order to improve the usability of the program. The fuel gauge can be programmed to show the reduction of fuel levels as the user is driving. The taco and speedometer can have a gauge showing the user how fast they are traveling and the revs/min.
• The fuel display: the top of the screen shows various attributes of the car. One which has been left blank is the fuel gauge. This can be improved by adding in a timer, which calculates the fuel level of the car and the rate at which it decreases.
• Vehicle options: Currently the menu only allows the user to choose an engine type. Further development would allow the user to have another menu, which contains different types of vehicles. These could include a FWD, sports car, family sedan and smaller vehicles. The program would then be able to determine the different values for different vehicle types as well as the vehicles engine type.
• Weather conditions: Different weather conditions could have been implemented into the program. These would include night, fog, rain and snow. Formulas would be written which change the values of the cars attributes depending upon the conditions.
All these areas allow the program to be taken further and developed in order to provide the user with better functionality. In doing so, the user may gain a better understanding of driving in different conditions and with different vehicles, so that they may improve their driving skills.
Software Developers
Instructor comments
(I've been asked by some teams to make comments on their wiki. I don't know who exactly, but perhaps this is a good way to provide feedback to all teams.)
This is a nice start. You should read the Wiki help and learn about sections to help you format your documentation.
The use case diagram is not showing use cases. You ahve four main areas of functionality which you have identified, and then created scenarios and use cases in each of those areas. That is OK but the use cases themselves should have specific names. (There could be lots of different use cases related to acceleration, braking, etc)
(JohnR, 18 Aug 06)
Good effort, couple quick points: if you are going to use collaboration diagrams, please do them properly by numbering the operation calls. Also, CRC cards are not part of the deliverable. Focus on the class diagram. Perhaps it's time to try coding it to find out what's missing. JohnR 10:58, 9 September 2006 (UTC)
How is you coding going? Did you find you required more classes (especially contolling type)?? --Dawsonj 02:31, 8 October 2006 (UTC)
Notes on layout managers
[1]
Check out the section on size and alignment hints. Note that layout managers can be good but can also be a large consumption of time. If you are getting stuck with it then it might be advisable to not use a layout manager at all and just set everything absolute within a fixed frame size. For control panels, keyboards, etc this is quite acceptable and pragrmatic.
--Dawsonj 00:27, 11 October 2006 (UTC)
