基于UML建模语言的开放式智能卡应用模型
文章出处：http://www.nexussmartsolutions.com 作者：邵 华，王恒奎，王东琳 人气： 发表时间：2011年10月09日
1 概述
1.1开放式智能卡概述
随着Internet在电子商务和人类生活中占有越来越重要的地位，人们对认证和安全交易的要求也越来越高。智能卡具有体积小、轻便易携带、可以自行存储和处理数据并执行加密解密操作等优点，与网络服务的结合还使它成为一个可以方便地存储用户密钥和下载保密数据的设备。
智能卡中包含CPU、RAM、EEPROM、ROM和I/O，如同一部规模较小的电脑。智能卡的软件结构由操作系统、虚拟机、智能卡应用模型及其具体应用服务程序所构成，如图1所示。
在此结构中，最底层的操作系统负责底层硬件的管理；虚拟机这一层隐藏了不同的操作系统平台，解释执行用类汇编语言表示的应用程序；开放式智能卡应用模型定义了一整套编程接口类，提供应用程序需要的统一的应用环境；应用程序提供具体的智能卡服务。
1.2 开放式智能卡应用模型概述
当今智能卡的功能及其终端(读卡设备)由于制造商的不同而种类繁多，使得智能卡的应用程序很难在不同智能卡开发平台(智能卡的终端，智能卡操作系统和编程环境)之间移植；另外开发智能卡所使用的编程语言比较低级，开发困难、成本高。
开放式智能卡模型的提出满足了智能卡应用开发的不同部分的需要，使得这些部分可以分别由应用程序开发者、智能卡发行商、智能卡开发者、智能卡终端开发者来完成，并都可以独立开发并兼容使用。应用程序开发者希望开发的智能卡应用程序能够在不同发行商发行的卡上运行，相应的智能卡发行商也希望能够采用不同应用程序开发者提供的应用程序，自由地选择操作系统而能适用于所有应用程序，任意地选择卡终端提供者所提供的装置和硬件驱动。开放式智能卡应用模型使得每个角色不需要随着任何其它部件的更新而改变，每个角色所完成的功能独立而协同。
2 基于UML的开放式智能卡应用模型
本文描述了一种位于智能卡应用程序和智能卡平台之间的中间层，即开放式智能卡应用模型(Open Card Framework)来解决以上这些问题。目的是为了：
(1) 高层APIs(Application Program Interfaces)标准化：智能卡及其终端是通过交换命令对APDU(Application Protocol Data Unit)来完成各种各样的功能，而对于不同的智能卡终端交互的机制是不同的，模型必须提供标准接口隐藏这些机制的复杂性。
(2)智能卡终端透明。智能卡的终端各式各样(如POS机，指纹录入设备)，模型应尽可能隐藏设备的具体特征，并透明地提供它们的功能。
(3) 智能卡操作系统透明。一定的命令集完成一定的任务，智能卡操作系统将这些命令集包装起来，只提供给应用程序相应的接口。不同的操作系统提供的接口是不同的，框架应隐藏这些接口的不同。
(4) 智能卡的发行商透明。智能卡的发行商决定了智能卡上所装载的应用程序及其组织,框架同样要隐藏这些管理和组织的细节。
(5) 可扩展性：中间层必须能够满足未来的技术发展需要。
开放式智能卡应用模型是基于智能卡应用的面向对象框架，是给智能卡开发者提供的统一框架，它符合ISO7816相关标准的特点使得开放式智能卡应用模型可以适用于任何智能卡种类[4]。
开放式智能卡应用模型将应用系统的任务按照它们的共性和个性分成两个部分，分别是智能卡终端组件(Card Terminal Package)和智能卡服务组件(Card Service Package).UML是一种能够将应用程序中的信息用标准的图形元素直观显示的建模语言，它是面向对象分析与设计的一种标准表示，本文通过UML对开放式智能卡应用模型建立相关模型。下面将用UML具体解释它们的任务及其内部关系。
2.1 智能卡终端组件的建模
智能卡终端组件包含所有与智能卡终端相关的类，是由智能卡终端开发商提供的。主要任务是提供对智能卡物理终端的访问，并可动态地添加和删除智能卡终端。下面介绍这个组件中主要的类及它们之间的关系：
类CardTerminal：从各种智能卡终端抽象出来可被继承的类，由其对应的CardTerminalFactory生产得到。
类CardTerminalRegistry：这个类只有唯一一个实例，管理应用系统中安装的所有智能卡终端，可对CardTerminal进行实例注册、注销等操作。
类CardTerminalFactory：同特定的工厂生产一定的产品一样，不同的智能卡终端制造商提供具体的CardTerminalFactory子类，由这些子类生产对应的CardTerminal实例。
类SlotChannel：向插入插槽的智能卡发送和接收APDU命令对的通道。
运用abstract factory和singleton模式[1]构建开放式智能卡应用模型的终端组件。框架中所有CardTerminal实例都要在CardTerminalRegistry 的唯一实例中注册， 然后由CardTerminalRegistry决定用哪家制造商提供的CardTerminal 实例，用UML表示的智能卡终端组件静态类图如图2所示。
在开放式智能卡应用模型中，智能卡插入读卡器或移除的动作触发外部应用系统获得对象CardTerminal，此对象利用CardID(与插入的智能卡一一对应的)表示所插入的智能卡，并通过对象SlotChannel与智能卡传递APDU。相关的静态类图用UML表示如图3所示。
2.2 智能卡服务组件的建模
智能卡所提供的服务是通过外部应用和智能卡之间的交互(交换APDU命令对)来完成的。在开放式智能卡应用模型中，这些命令集被集成在卡上的服务中，外部应用只需通过标准的APIs来访问这些服务即可。这个框架还应具有可扩展性，能够添加新的服务模块。下面介绍这个组件中主要的类及其关系：
类CardService：这是一个抽象类，其意义是卡上的服务，它的子类通过包装一系列APDUs来提供具体的服务内容。如子类FileSystemCardService是为了完成访问智能卡的文件系统的任务。
类CardServiceFactory：同类CardTerminalFactory功能相似，应用服务商提供自己的CardServiceFactory代表其自身， 由CardServiceFactory产生它们各种服务即一些CardService实例。
类CardServiceRegistry：管理卡上的所有CardService对象，包括不同应用服务商提供的服务。
类CardServiceSheduler：为服务所需的通信安排通道，给CardService对象提供一个逻辑通道发送接收命令对来完成任务。
类SmartCard：外部系统通过它访问开放式智能卡应用模型来完成智能卡服务。
类似CardTerminal部件，CardServiceRegistry对象管理卡上所有的服务。当应用程序对插入的智能卡要求一个特定的服务如电子钱包服务，CardServiceRegistry询问所注册的所有CardServiceFactory子类是否能为这张智能卡提供需要的服务，一旦某个CardServiceFactory子类如PurseServiceFactory说明它能提供电子钱包服务PurseService，于是子类PurseServiceFactory生产出服务实例PurseService。这个部件的静态类图如图4所示。
CardServiceScheduler为具体的服务实例和智能卡一一对应的SmartCard实例安排逻辑通道CardChannel，进行APDU的交换。一旦完成任务它就释放这个CardChannel实例，以便将其提供给别的服务。这些动作都是由智能卡插入读卡终端或移除触发的事件CardTerminalEvent引起的，其静态类图如图5。
2.3 智能卡的应用服务
在开放式智能卡模型中还需要建立一些重要的应用服务，对于大多数智能卡来说这些服务是必需的。
类CardManagementCardService是为了在能够在一张智能卡上装载、运行、管理多个应用程序，它是类CardSevice的子类。
类FileSystemCardService提供了一系列接口来访问操作
系统中的文件系统。
类SignatureCardService进行安全管理，用来完成持卡人的身份认证、文件访问权限控制、安全报文传输、数据加密和解密等任务。
其它应用程序也可以利用以上这些类完成相应的服务。外部应用智能卡服务的系统都是通过在2.2节中提到的类SmartCard访问整个应用模型。我们给出一个服务应用实例化过程，表现出对象之间是如何配合完成功能。假设外部应用需要一个A CardService对象，整个动态过程用UML的动态Collabartion框图表示如图6所示。
3 总结
开放式智能卡的应用框架的提出给应用程序开发者、智能卡和智能卡终端投资商等带来了极大的方便。使得智能卡的应用实现了从“一对一”到“多对多”的转换，并为开放式智能卡应用构造了一个统一标准结构。
(1) 对于遵循开放式智能卡应用框架应用程序，可以适用于任何一张开放式智能卡，应用程序不需重复开发，开发费用大大减少。
(2) 对于遵循开放式智能卡应用框架开发的智能卡，不仅可装载不同组织提供的多个应用程序，且一旦运用环境变化，可方便地装载和卸载来更换卡上的应用程序。
本文描述的开放式智能卡应用框架满足了应用程序的开放性和独立性，不需要像传统式智能卡的应用程序都是为操作系统和芯片量身定做。
