📄 radexamples.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0073)file://H:\SoftwareEng\SEFall01\N_SE_Fall01\template\Examples\Examples.htm -->
<HTML><HEAD><TITLE>RAD Examples</TITLE>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="MSHTML 5.50.4915.500" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff>
<CENTER>
<H2>Examples of RAD from JAMES</H2></CENTER>
<HR>
<A name=Example1></A>
<H2>1.0 General Goals - Bonus Subsystem</H2>The bonus system is a way for a
Mercedes owner that also owns a Smart Card to receive benefits for using
Mercedes dealers for their service needs. Whenever maintenance is performed on
the owner's Mercedes, they will earn a certain number of bonus points based on
the type of service. These bonus points can be redeemed for other services or
products. <A name=Example2></A>
<H2>2.0 Current System - Vehicle Subsystem</H2>The current simulators from
Daimler-Benz consist of a Windows SA/RT simulator written in C, that simulates
only the vehicle seat. There is also the AIM/CANalyzer simulator software
written in a Canalyzer language similar to C, from Daimler-Benz that can
simulate multiple vehicle functions running on a laptop computer. <A
name=Example3></A>
<H2>3.0 Proposed System - VIP Subsystem</H2>
<H4>3.1 Overview</H4>The VIP subsystem will be designed to provide
personalization functionality of the JAMES system. Essentially, the VIP system
is intended to maintain a record of the user's personalized preferences and data
which may be applied or accessed in any JAMES enhanced vehicle. The settings
that the users can manipulate fit into two categories. First, the user can
adjust settings on physical devices within the car such as seat position, mirror
position, radio channel presets, dashboard light intensity, fuel economy, and
climate control. The second group of settings are those which do not have a
real-world component. This group will include the database portions of the
currently implemented phone book, address book, and related applications as well
as extensions to other configurable objects. The VIP system behavior will be
almost entirely automatic, leaving its activity transparent to the user. This
will lend a continuity to the feel of user's driving experience across all JAMES
enhanced vehicles.
<H4>3.2 Functional Requirements</H4>The functional requirements of the VIP
Subsystem system are to store and retrieve data in an efficient, and flexible
manner. In order to accomplish this, the VIP system, upon insertion of the
JavaCard, will query the vehicle to get a list of objects installed on the
system. Once this list of objects, everything from radio presets to seat
position, is returned, the VIP system will attempt to find the best match
between what settings are currently saved, and what settings the car requires.
After the user has restored his old settings, and makes any new adjustments, the
saving of settings will be done without any knowledge by the user. If the user
wants to manually save and restore his settings, he will be able.
<H4>3.3 Non-Functional Requirements</H4><A name=Example4></A>
<H2>3.3.1 User Interface and Human Factors - Maintenance Subsystem</H2>This
system will be used by two main groups of people: First it can be used by an
authorized representative of the owner of the car which could be the driver,
friend of the driver, fleet manager or someone else. Second, it can be used by
the mechanic or some other representative of the garage, such as a manager. The
complete user definitions are described in section 3.5.2.1 User Model.
<P>For simplicity, in the rest of this document driver will refer to the driver
or any authorized representative of the driver, while mechanic will refer to any
authorized representative of the garage.
<P>The central database, as used in this document is physically several
databases, including several legacy servers. These servers will be distributed
across separate sites on the Inter/IntraNet. It will be used for long term
storage of the maintenance history and possibly other information. See the
System Design Document for additional information on databases.
<P>The assistant will exist on several different locations. There will be a home
assistant for the owner to use at home, an assistant on the vehicle for the
driver to use, as well as an assistant in the dealer's garage for him to use.
For the owner/driver, the assistant should be simple and easy-to-learn. This is
especially important for the home assistant, as users will have only occasional
interaction with them. The mechanic will have more frequent interaction with the
assistant, so the interface in the dealer garage should enable mechanics to
enter transactions quickly and easily. In both cases, users should be protected
from making significant errors, as these records are maintained for the life of
the car.
<P>In terms of hardware, the driver will need a computer and a card reader in
his home to download the maintenance applet and view the maintenance history.
Software will be needed to interface with the card reader. The mechanic will
also need a similar computer and card reader in the garage. In the vehicle, the
maintenance system expects access to a touch-sensitive screen that can display
our assistant and receive input from the driver.
<P>A final design goal for the user interface is to achieve the same elegant
simplicity of interaction for which Mercedes-Benz vehicles are known. The
interface should not appear complicated, nor require extensive explanation.
<BR><A name=Example5></A>
<H2>3.3.2 Documentation - Travel Subsystem</H2>Documentation should be included
which covers all use cases of the travel application. Within it, there shall be
sections covering the user interface and how it is to be utilized in conjunction
with the rest of the travel application in order to provide all the
functionality covered in the problem statement. Documentation will be available
on how to plan a route, update the SmartCard, edit a route and view the route.
Documentation will account for different environment settings where the system
is used, such as planning the trip on the user's home pc, or viewing a route on
the road. The target audience of the documentation are the users of a Mercedes
vehicle. The documentation will take into consideration that both drivers and
passengers could be using the system while on or off the road. <A
name=Example6></A>
<H2>3.3.3 Hardware Consideration - Logbook Subsystem</H2>The LogBook application
will have pieces running on three different hardware platforms: the car's
computer, the SmartCard, and the user's computer. The logging of trips will be
done on the car's on-board computer, and the tax forms will be printed on the
user's computer or prepared by a service center. The only thing left for the
SmartCard to do is transfer trips between the user's computer and the car.
<P>The car's computer is comparable to a desktop personal computer, probably
with a real-time operating system, and should be capable of running full Java.
Also, the storage capacity should be much greater than what the SmartCard has,
however space will still be a consideration in this application.
<P>The SmartCard itself runs a watered down version of java with no threads, no
garbage collection, no exceptions, or much of anything that makes Java useful.
The card has a total of 2.8KB of space available for our program and any data we
need to store. The other risk with the card is that the Java operand stack only
has 32 bytes. So, you can't have a deep call tree, use class hierarchy, or have
lots of local variables. The code that goes on the card has to be without
excess. Making a good, reusable, application to run on the card will not be
easy.
<P>The user's computer, which handles the tax forms and final storage of trips,
should present many design challenges. Talking to the card maybe somewhat
difficult, as it is necessary to go through an old DLL, but any ugliness there
can be encapsulated. Once the communication is taken care of the tax form
generator shouldn't in any way stress the resources of a modern desktop
computer. <A name=Example7></A>
<H2>3.3.4 Performance Characteristics - Bonus Subsystem</H2>The web interface
used by the driver should be relatively fast over a 14.4 Kbps modem connection.
A page should take no longer than 10 seconds to load at this speed. The web page
therefore can not hold more than 30 KB of information. This includes the
information transferred to the user as well as information obtained from
databases through queries. The system should be able to sustain this rate with a
moderate load of users.
<P>The dealer terminal should have a user interface with no noticeable delays.
Any delay in the system should be accompanied by a status message or at least an
indicator that the slowdown is a result of information retrieval and not poor
programming. The dealer should be able to download any needed information and
present it to the customer within 10 seconds, barring hardware or network
problems.
<P>The Smart Card can only hold 2.8 KB of data. Anything placed on the card must
be smaller than that. Information traveling over the network should be as small
as possible to eliminate delays. The servers holding the information should have
large enough storage to accommodate the data with at least 15% breathing room
and redundancy, if cost effective. The servers holding the information should be
expandable so in storage need increases, more space can be added. <A
name=Example8></A>
<H2>3.3.5 Error Handling and Extreme Conditions - Logbook
Subsystem</H2><B>3.3.5.1 Error Handling</B> <BR>There are three components to
the LogBook Assistant software: the on-board computer code, the personal
computer code, and SmartCard transfer code. These are subject to various types
of input errors, to be discussed separately. The onboard computer code
communicates with the user (during driving) via three buttons: "Start Trip,"
"Pause Trip" and "End Trip." In each state (in a trip, or not in a trip) the
behavior of these is well-defined: pressing "Start Trip" when a trip is in
progress shall start a new trip, pressing "Pause Trip" when a trip is in
progress shall suspend or resume the trip (as appropriate), and do nothing if no
trip is in progress, and pressing "End Trip" when no trip is in progress shall
be ignored. The onboard computer code communicates with the administrator (or
the server, when retrieving trip information) via the onboard touch screen. The
data retrieval mode (copying information onto the card) will be designed to
eliminate, as much as possible, any opportunities to make invalid input: trips
or legs which may be retrieved or deleted are displayed in a list box, and no
buttons may be pressed for invalid operations (e.g., if the user does not have
permission to delete a trip's information, the 'delete' button shall be either
disabled or hidden). The personal computer component of the system has the most
complicated user interface, since t must allow the user to select trips for
which to print tax deduction forms and possibly to edit trip data (join or split
trips). Until the functionality of this component is determined, input errors
and their handling cannot be fully analyzed.
<P><B>3.3.5.2 Exceptional Conditions</B> <BR>'Exceptional conditions' in the
context of the LogBook assistant are assumed to be limited to starting or
stopping a trip very shortly after starting the car or very shortly before
stopping the car (i.e., turning the motor on or off). In these cases, the trip's
data is 'rounded off' to reflect he car's location when the engine starts or
stops, rather than when the 'Start Trip,' 'Pause Trip' or 'End Trip' buttons are
pressed. The conditions for performing such round-off are not yet defined, but a
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -