radexamples.htm

dmbs project which we did in our cs class which creates a simple database

suggested possibility is that the odometer has not changed by more than 0.1 
miles. It has also been suggested that this be possible to change after 
manufacture -- perhaps by taking the car into a service center to change the 
onboard computer settings.&nbsp;<A name=Example9></A> 
<H2>3.3.6 System Interfacing - Maintenance Subsystem</H2>This system is 
primarily standalone. It interfaces with the authentication subsystem to 
authenticate the driver and dealer. There is a Bonus Points system to reward the 
driver for maintenance requests. This will be implemented in the future. See the 
System Design Document for further information. There will be an Event 
Notification System and a Name Service that will allow the Maintenance Assistant 
to communicate with its user interface. It will also allow it to communicate 
with any other Assistant or system that uses the Event Notification and Name 
Service. They will communicate using standard Java and CORBA. CORBA was decided 
over RMI because it allows the system to talk to other systems there are not 
necessarily written in Java.&nbsp;<A name=Example10></A> 
<H2>3.3.7 Quality Issues - Travel Subsystem</H2>The system must be reliable, in 
the sense that it must provide the correct route information to the user. This 
means that the route and sites of interest are displayed correctly. The system 
response time for a user request, such as View Trip, should take a maximum of 5 
seconds. The user must be notified if the current GPS location does not lie 
along the planned trip. The system must also be compatible with the Schlumberger 
standards so that it does not damage the SmartCard in any way. 
<P>The system must recognize when certain components that it relies on are down. 
For example, if the GPS is not responding, the system must deal with the problem 
appropriately. 
<P>The system must be aware of how much space there is left on the card. It 
should notify the user when there no more trips could be stored on the card. 
Although, right now, the card may only allow one assistant at a time, it is 
expected to increase in memory and become a Multi Functional Card ( MFC ). This 
means that the card will allow to have different assistants running at the same 
time, as well as allow dynamic downloading of assistants. The Travel Subsystem 
should recognize that there are other applications running on the card. It 
should never interfere with the other applications. 
<P>The component of the system which plans the route must be able to run on any 
hardware/operating system environment which has a Java Virtual Machine. It is 
important not to restrict the user's choice on where they can plan their trip. 
The component of the system which contains the specific trip information must be 
compatible with the Cyberflex SmartCard architecture. The cardlet should never 
perform actions which will damage the Java Virtual Machine on the 
SmartCard.&nbsp;<A name=Example11></A> 
<H2>3.3.8 System Modifications - Vehicle Subsystem</H2>Initially the only 
component that will be simulated will be the seat. It will be simulated first 
through a Java stub and then through the AIM/Canalyzer or SA/rt. If time permits 
this would be expanded to other vehicle components. The implementation side of 
the vehicle bridge is likely to get changed as new seat, mirror, entertainment, 
etc. units are introduced. This may involve simply new CAN bus ID's, or entirely 
new transactions on the bus. New units may also require modifications to the 
server side, for example if there are new parameters that must be set or read 
from the unit. These are not as likely as modifications to the implementation 
side.&nbsp;<A name=Example12></A> 
<H2>3.3.9 Physical Environment - VIP Subsystem</H2>At this time, the target 
equipment is the Cyberflex JavaCard. However, the design of this system should 
be generic enough to take on new features of cars, as well as new types of 
cards. For example, if there is more room on a new JavaCard, then there should 
be more data stored.&nbsp;<A name=Example13></A> 
<H2>3.3.10 Security Issues - Bonus Subsystem</H2>Access to data must be 
controlled. No driver may alter any bonus point data. Mercedes policy makers 
shall dictate bonus points earned for service and bonus points cost for service 
or product. This information will then be given to the system administrator of 
the web server, who will change the information. The only information dealers 
may change are the bonus points on a Smart Card, and only after the driver has a 
service done or purchases a service or product using their bonus points. 
<P>Physical security is also an issue. Any employee at a dealership should not 
be able to view all the information about a customer. Access to the web server 
must be restricted to the system administrator only.&nbsp;<A name=Example14></A> 

<H2>3.3.11 Resource Issues - Logbook Subsystem</H2>The resources in the LogBook 
use the card as a data transfer medium and will be backed up on the external 
system whenever the card is inserted to the card reader attached thereof. The 
LogBook system will be installed along with the rest of the JAMES system, most 
likely at the factory with the rest of the car. The administrator will be free 
to administrate the logs as they see fit. Data on the external system will be 
considered to be the master data; if an administrator modifies data on the 
external system and the resulting data conflicts with newly arrived data from 
the vehicle or car, the external system data will be used.&nbsp;<A 
name=Example15></A> 
<H2>3.4 Constraints - Maintenance Subsystem</H2>The system will be developed 
with Java (JDK 1.1.4) with CORBA using VisiBroker. Object and case models will 
be constructed using the CASE tool Rational Rose 4.0. Source control will be 
handled using Perforce. See Section 9. Issues of the System Design Document for 
further discussion. There will be an interface to the legacy system, depending 
on the access granted to us by Mercedes.&nbsp;<A name=Example16></A> 
<H2>3.5.1 Scenarios - Travel Subsystem</H2>A driver wants to plan a business 
trip. He calls up the travel application on his pc at home, and calls upon it to 
create a route. The travel application calls upon the map service, which 
displays a map, including the sites of interest which are along the way of his 
route to be planned. He selects a route, then saves this route on the card. 
<P>A driver who has saved a route on the card is driving along the route planned 
and wants to see how far he is along on the trip. He goes to the travel 
application and selects view trip, which calls the navigation system to find the 
car's current location, then the map service to get the map of the location, 
correlating that with the route that was planned, showing the current location 
of the car on the map. 
<P>A driver decides that he doesn't have time to stop at all of the sites of 
interest along the way between the beginning of his trip to the final 
destination. He calls upon the update trip part of the travel application, which 
calls the navigation system to determine the current location of the car, and 
correlates the map service map with the route planned on the card to show on the 
screen the current location of the car on the map. Then, he deletes the location 
at which he is unable to stop at. If he wishes to add it again, or add another 
location, he calls upon update trip to show his current location, then selects a 
location from the map provided by the map service to add a location to his 
route.&nbsp;<A name=Example17></A> 
<H2>3.5.2.2 Use Case - Vehicle Subsystem</H2><B><FONT color=#ff0000>NAVIGATIONAL 
TEXT FOR THE USE CASE BELOW -- </FONT></B>The top level use case illustrates the 
relationship between the various subsystems and the vehicle. The vehicle 
subsystem provides the other subsystems with interface services to the vehicle. 
In terms of the services it provides to other subsystems, the vehicle subsystem 
is divided into four areas. They are services to Logbook for getting odometer, 
clock, date, and location readings. Maintenance for diagnostic testing. Travel 
for getting GPS information, and VIP subsystems for controlling and getting 
information about components of the vehicle. 
<CENTER>
<P><B>TOP-LEVEL DESIGN USE CASE</B></CENTER><IMG 
src="RADExamples_files/UseCase.JPG"><A name=Example18></A> 
<H2>3.5.3 Object Model - VIP Subsystem</H2>
<H4>3.5.3.1 Data Dictionary</H4><B>Driver Info:</B> <BR>This will consist of a 
driver name and a password and is used for the purpose of authentication and 
driver identification. <BR><B>Car Description:</B> <BR>This is the description 
of the Car that will include the model of the car and a list of installed 
components in the car. <BR><B>Component Settings Data:</B> <BR>This data is what 
will be returned to the VIP system from the car and will describe the settings 
of a component. <BR><B>Other Assistant HCI settings:</B> <BR>This data will be 
returned from HCI and will describe the current settings and layout for the user 
interface settings of another Assistant program. <BR><B>Default Data:</B> 
<BR>This data will be some default setting for the both component settings and 
for the other Assistants HCI settings. <BR><B>Messages:</B> <BR>These are simple 
event notification that tells one process that something has occurred that is of 
importance to it. <BR><B>VIP Settings:</B> <BR>This is simply the data stores 
the current settings of the VIP User interface. <BR>&nbsp; 
<H4>3.5.3.2 Class Diagrams</H4>The most basic object that VIP can manipulate is 
the CarComponent module. A CarComponent is any piece of the car that can have a 
setting. It can be hardware, such as a seat or a mirror, or it can be software, 
such as an "interface setting" for HCI. 
<P>In order to store and retrieve these CarComponents, a list object must be 
maintained. The list object is simply a container for the CarComponents. It 
allows one to add or remove CarComponents, as well as query for a certain type 
of component. 
<CENTER>
<P><B>Figure 3.5.3.2.1 Car Component Object</B> 
<P><IMG src="RADExamples_files/Object1.GIF"></CENTER>
<P>Three different list of object must be maintained. The CardList is the list 
of CarComponents which the JavaCard currently knows about. The HardwareList is a 
list of CarComponents that the Vehicle currently has installed. The SoftwareList 
is a list of settings for components that are do not map to any physical object. 

<CENTER>
<P><B>Figure 3.5.3.2.2 Car Component List</B> 
<P><IMG src="RADExamples_files/Object2.GIF"></CENTER><A name=Example19></A>
<H2>3.5.4 Dynamic Models - Logbook Subsystem</H2>
<H4>3.5.4.1 Sequence Diagrams</H4>Start Vehicle 
<CENTER><B>Figure 3.6 The user is starting the vehicle.</B> <BR><IMG 
src="RADExamples_files/Sequence.GIF"></CENTER><A name=Example20></A>
<H2>3.5.5.1 Navigational Path for the Web Application - Bonus Subsystem</H2>The 
customer at home will be access the bonus points system using a PC through the 
internet. The customer will be able to view his or her points and looks through 
the Mercedes Benz catalog finding out if his or her points will be sufficient to 
buy goods listed on the catalog. 
<CENTER><B>Web Application Navigational Path</B> 
<P><IMG src="RADExamples_files/Navigati.GIF"></CENTER><A name=Example21></A>
<H2>3.5.5.2 Screen Mockup - Maintenance Subsystem</H2>Below is the application 
that a mechanic would interact with. The interface provides a way to view and 
edit the maintenance history of the vehicle and view recommendation. The driver 
would use a similar interface at home, except the option to generate a new 
maintenance entry would not be available. 
<CENTER><B>Screen mockup of mechanic application</B> 
<P><IMG src="RADExamples_files/Screen1.GIF"></CENTER></P></BODY></HTML>