[Impressum]
[E-Mail]
Platform-specific Smartcard Model (1)
The
platform-specific class diagram contains only those classes that are
relevant for the platform. The types of the attributes are replaced by
datatypes of the platform. In the smartcard PSM e.g. the type
Number is replaced by short, a String is converted into a byte array
representation. The methods used for communication with a terminal are
stored in a class called SimpleComm which is a superclass of class
Copycard. This class implements the javacard.framework.Applet class.
The stereotypes <<HashData>>, <<PlainData>> and <<SignData>> are replaced by interfaces.
The communication with a smartcard is done using Application Protocol
Data Unit's (APDU). An APDU is a byte arrays that has a predefined
format. To send a message to a card, it is necessary to serialize the
message objects into byte arrays. After receiving an APDU, the byte
array representation of a message object has to be deserialized. The
se-/deserialization of messages is application-specific and is
generated automatically (without Reflection, since JavaCard does not
support Reflection). The class Coding contains method to serialize
(encode) an deserialize (decode) message objects. The class Code
defines a typflag for every class that has to be serialized which is
used for serialization.
The class Store contains the object management of the smartcard. Since
JavaCard has no garbage collection, the allocated memory is never
deallocated. For this reason, one has to be careful with creation of
objects. The SecureMDD project solves this problem by generating
an object manager (Store) that creates all required objects in advance.
If the smartcard component (e.g. the Copycard) needs an object during a
protocol run, it requests this object from the Store.
- The deployment diagram of the platform-specific smartcard model ist the same as the one in the platform-independent model.
Back, Next Step: Detailed model with activity diagrams
