3架构设计

?

1.架构设计

1.1.用户分析

本版本暂时只考虑一个用户使用情况。

1.2.用例分析

?

1.3.系统部署图

?

1.4.数据存储方式选择

不同存储方式对比考虑。

方式名称优点缺点

数据库（mysql）支持Sql,查询方便

稳定

支持事务客户还得安装数据库，比较复杂

嵌入式数据库同上

小巧，不用客户安装详细见下表

Nosql数据库不熟悉，暂不考虑

xml格式化数据，大量的开源解析库无事务控制

存储空间大

文本可以直接查看解析工作量大

不支持事务

二进制存储空间小不支持事务

嵌入式数据库对比

数据库名称sqllitederkeley dbfirebird嵌入服务器版

当前版本3.3.84.5.202.0

速度最快快快

数据库容量2TB256TB64TB

sql支持大部分sql-92不支持sql-92和大部分 sql-99

win32下最小体积374kb840kb3.68MB

sqllite缺点：

◇并发访问的锁机制,在并发（包括多进程和多线程）读写时，数据库可能会被写操作独占，从而导致其它读写操作阻塞或出错。

◇SQL标准支持不全,不支持外键约束。

◇网络文件系统（以下简称NFS），在并发读写的情况下可能会出问题（比如数据损坏）。原因据说是由于某些NFS的文件锁实现上有Bug。

使用SQLite的人越来越多（从Google Trends可以反应出来）。包括一些大公司也开始把它整合到产品中（比如Google的Gears、Apple的Safari、Adobe的AIR）。这说明它的健壮性、稳定性等方面不会有太大问题。

综合以上考虑，打算选用sqlite，看中速度快，支持事务，标准sql,下面是以前开发选用的文本存储，当时觉得嵌入式数据库不稳定，这次做架构好好查询了下，其实不然。看来做架构时不了解的知识要多学习啊。

?

系统使用文件存储，本版本使用txt文件，以后会考虑改为二进制文件。

文本文件以换行来标识不同数据，一行为一个数据。

文件存储在当前用户目录下，不存放在程序目录，为了数据安全。

每个电影的相关文件放在一起，方便进行数据按照电影进行备份，以及导入，导出。

文本文件内容的更新，每次是删除文件再重写，使用整个文件重写保存，所以每次删除前会对文件做备份。

?精通单词存储格式：

about

accept

?字幕生词存储格式：

act~@%行为

agenda~@%议程

?字典文件 格式

blew~@%吹

cave~@%洞穴

1.5.组件图

?

1.6.系统分层及包设计

?

1.7.技术框架选型

选用Spring框架来处理依赖注入，事务，以及数据库访问。

测试框架选用junit，发布时不发布。

日志选用log4j。

1.8.原系统数据移植

原系统采用文件系统存储数据，新系统要能把原来系统的数据移值过来。可以把原来的文件存储变为一种备份机制。

方案如下：

a.重构系统，把用文件进行的数据访问整理为资源库的一种实现，文件实现。

b.加入资源库接口的数据库实现类，系统使用此实现来存储数据

c.加入数据还原功能，使用a重构好的接口。把数据从文件还原到数据库中。

d.加入数据备份功能，支持两种方式，备份数据库文件和使用a进行文件备份。

?