| Identification |
The unique name for the component and the location
of the component in the system. |
| Type |
A module, a subprogram, a data file, a control procedure,
a class, etc |
| Purpose |
Function and performance requirements implemented by the
design component, including derived requirements. Derived requirements
are not explicitly stated in the SRS, but are implied or adjunct
to formally stated SDS requirements. |
| Function |
What the component does, the transformation process, the
specific inputs that are processed, the algorithms that are used,
the outputs that are produced, where the data items are stored,
and which data items are modified. |
| Subordinates |
The internal structure of the component, the constituents
of the component, and the functional requirements satisfied by
each part. |
| Dependencies |
How the component's function and performance relate to other
components. How this component is used by other components. The
other components that use this component. Interaction details
such as timing, interaction conditions (such as order of execution
and data sharing), and responsibility for creation, duplication,
use, storage, and elimination of components. |
| Interfaces |
Detailed descriptions of all external and internal interfaces
as well as of any mechanisms for communicating through messages,
parameters, or common data areas. All error messages and error
codes should be identified. All screen formats, interactive messages,
and other user interface components (originally defined in the
SRS) should be given here. |
| Resources |
A complete description of all resources (hardware or software)
external to the component but required to carry out its functions.
Some examples are CPU execution time, memory (primary, secondary,
or archival), buffers, I/O channels, plotters, printers, math
libraries, hardware registers, interrupt structures, and system
services. |
| Processing |
The full description of the functions presented in the Function
subsection. Pseudocode can be used to document algorithms, equations,
and logic. |
| Data |
For the data internal to the component, describes the representation
method, initial values, use, semantics, and format. This information
will probably be recorded in the data dictionary. |
| Identification |
POS Module |
| Type |
Module |
| Purpose |
The POS module will be the program that facilitates communication
between a third party Point Of Sale application, and our eWallet card.
The main purpose of the program is to provide the ability to get and
put data on the smart card. |
| Function |
A calling program would pass this module a request for information.
This request could include wanting a credit card number, a
verification of identity, or to use money stored on the card. The
module would return this data to the calling application. |
| Subordinates |
The module will be a java program. The main part of the program will
be our code for reading and writing to the smart card reader. The
rest of the application will center on sending and receiving data that
needs to be applied to the card. |
| Dependencies |
The module needs a calling program, in the form of the POS
application. This will be a pre-existing application. The module
also depends on the smart card and relates to all other modules in the
system by the smart card. The data that all modules read or write is
on the smart card. Obviously there is a huge issue with timing and
dependancy that the smart card is actually present. The user should
be sure the smart card is in the reader before the external
application calls this module. If the module is called and there is
no card present, the module will return an error. |
| Interfaces |
There are no user interfaces for this module. The external
application will pass parameters to the module when it is executed.
The initial parameter will be the request type. The next parameter
will be the file to write the data back into when the module is done.
The ensuing parameters will be dependant on the initial parameter. A
request to the module for identification information would not need
any other parameters, where a request to deduct cash off the card will
need a cash amount. The module will communicate with the smart card,
and then write out a temporary file with a file name that was provided
previously by the calling application. This will be a simple text
file containing the requested information, with each piece being on a
pre-determined line. For example, a status code would be the first
line, containing a number for OK or for defined error codes. The next
lines would also be dependant on the request type. |
| Resources |
The module will run on the computer that the POS software is running
on. It will require minimal memory and space. The smart card reader
will require a port to be plugged into, so the application will also
need to be able to access this port. The module will also need
permission to create a temporary fine, so disk write privileges are
required. |
| Processing |
The pseudo program flow might look like:
Application called with parameters
Parameters are read and action is determined.
Appropriate function called to access data on card
Create a return file based on filename passed in parameters
if there is an error, the card cannot be read or is not present report to file
else write requested data to file created previously
Exit Program |
| Data |
The program has minimal data requirements. Data being passed between
card and the calling application can generally be represented as basic
primitive data types. There is no need for structures as only one
piece of data will ever be requested at a time. |
| Identification |
Card Manager |
| Type |
Module |
| Purpose |
Provides the ability for a user to interact with the card by several interfaces. |
| Function |
Provides the user with an interface to modify applets installed on the eWallet smartcard. A user provides inputs that are processed and the outputs are produced and stored on the card. |
| Subordinates |
Card and card applet classes along with classes modeling the commands to send to the card. |
| Dependencies |
This component will rely on the security component which will be necessary before access to the card can be granted. It will also rely on the Card component to obtain information about installed applets to provide the user with available options. |
| Interfaces |
Login Screen: The Login screen is responsible for authenticating the user before allowing any access to data stored on the card. It simply prompts for a fingerprint scan, and then hands that scan off to the Security component for verification. The Security component then notifies the Login screen as to whether or not authentication was successful. The Login screen keeps track of the number of invalid login attempts and after a certain number of unsuccessful attempts will disable login.
Card Options Menu: The main responsibility of the Card Options menu is to provide an interface for managing applets on the card. The Card Options menu presents the user with options to install or delete applets as well as select an available applet to work with. This menu interacts with the Card component to obtain information about installed applets, as well as installing and removing them.
Applets Option Menu:
This is a generic class that provides information about an applet installed on the card. The main method it provides is getAppletID. Any subclass of this class needs this method, as the AppletID is the way to uniquely identify applets installed.
Credit Card Applet Options:
As a subclass of Applet Options menu this class allows the applet id to be queried but it also provides methods specific to dealing with credit cards. One of the responsibilities this class has is to interact with the Card component and provide the user with a list of available credit card accounts. It also facilitates the user’s need to add credit card accounts to their eWallet, as well as remove them.
|
| Resources |
smart card reader, usb port, pure java drivers or use of pcsc to connect to the card reader |
| Processing |
Login Screen: login(), maxFailures()
Card Options Menu: installApplet(), deleteApplet(), selectApplet()
Applet Options Menu: getAppletID()
Credit Card Applet Options: ListCreditCardAccounts(), addCreditCard(), removeCreditCard()
|
| Data |
All data is handled by the Card Component |
| Identification |
Card |
| Type |
Module |
| Purpose |
Provides users with an interface to the card and the applets
stored on it. Includes card applet classes and means to update
information on the applets as well as methods to add and remove applets
from the card
|
| Function |
Manange card |
| Subordinates |
Card and card applet classes along with classes modeling
the commands to send to the card.
|
| Dependencies |
Smart card reader |
| Interfaces |
The card reader is used to communicate to the card, and
communication is facilitated by APDU's (application protocol data units)
which contain structured command and response information. These apdu's
are exchanged between the user and the card via the card reader.
|
| Resources |
smart card reader, usb port, pure java drivers or use of pcsc
to connect to the card reader
|
| Processing |
Applet Management: InstallApplet(applet identifier),
RemoveApplet(applet identifier), SelectApplet(applet identifier)
ID Applet: get and set Photo, Name, Address,
Fingerprint, get and set DriversLicense
Payment Applet: get, debit, and credit Cash, get, add
and remove CreditCard
|
| Data |
Photo is stored as a compressed jpeg, fingerprint as a special
points file, credit card accounts as text in a text file, name, address,
etc are strings in text files, drivers license information is in a text
file, cash value is a long, and apdu's are essentially hexidecimal strings.
|
| Identification |
Security |
| Type |
Module |
| Purpose |
To provide protection and security for the owner/user of the card against theft and illegal use. The security component must provide a method for authentication in order to offer a secure system. The security component provides fingerprint and/or pin number authentication for all transactions on the card.
|
| Function |
The security component provides a means for system security through fingerprint and/or pin number authentication. The system takes either fingerprint images and/or pin numbers as inputs. The security component stores the data (fingerprint image and pin number) and manages these. The security component compares and validates or rejects the input. This data is only modified by the Card Manager or upon issuance of a card. |
| Subordinates |
There is a User Fingerprint class, a User Pin Number class, and a Validation class. The User Fingerprint class stores and manages the image of the valid user fingerprint. It also reads the fingerprint from the fingerprint scanner for comparison. The User Pin Number class stores the valid user pin number for authentication and can read in a pin number for comparison. The Validation class provides a means of comparing the input fingerprint and/or pin number for authentication by comparision with the stored data.
|
| Dependencies |
The security component of the eWallet depends on a fingerprint scanner and/or a pin number pad for inputs. The POS and Card Manager components use the security component to determine whether the user's authentication is valid for the card. The Card Manager is responsible for creating the authentication data, including fingerprint image and pin number, for the eWallet card.
|
| Interfaces |
User Finger Print: This class is responsible for managing the user fingerprint to use as authentication against a fingerprint stored on a card. Along with just a fingerprint image, this class also contains a reader object so that the class can obtain a fingerprint by scanning from a fingerprint reader. This class is then used to validate against another print.
Validation: The Validation class does the actual comparison between two fingerprints. The main method compareFingerprints method compares the prints of the two fingerprint members and then returns a Boolean value representing whether or not the comparison was successful.
|
| Resources |
A card reader, pin pad and/or fingerprint scanner.
|
| Processing |
User FingerPrint: getReader(), ScanFingerprint(), reader, fingerprint
Validation: compareFingerprints(), userFingerprint, cardFingerprint
|
| Data |
Stored pin number will be represented as a character string. The stored fingerprint will be represented by an image file. Initial values will be 0000 and an empty file, respectively.
|
