初步计划

1．引言

1.1编写目的

此份文档为开发手机的应用转换网关这个项目提供计划，描述了项目的出发点、目标，并对项目的大体规模，进度进行说明。

 

1.2项目背景

无

1.3定义

无。

1.4参考资料

无

2．项目概述

2.1工作内容

以当今的网络应用来讲，最成功的应用应当数HTML，它是互联网中当之无愧的杀手级应用。网络上大部分的信息都是通过HTML来进行发布，各式各样的技术也围绕着html来展开，例如JSP、ASP等等。

 而手机，作为近两年内最为引人注目的嵌入式移动开发，当然也不会放弃利用互联网中的这一资源。于是就出现了一些为手机而开发、或是移植到手机平台上的浏览器。在这个领域比较著名的当属Opera浏览器，比如Nokia9500就进行了内嵌。而就在最近，FireFox在桌面PC上开拓出一片疆土的同时，Mozilla也推出了针对移动设备的迷你浏览器项目Minimo，同Opear展开竞争。

但是在手机这种特殊环境下，比如，可显示区域较小，按键相对于PC太小，大部分没有坐标定位设备（只有一些使用触摸屏来解决），目前的HTML页还是不适合进行直接显示。

首先，大部分的html页面的适合大小为800*600以上，这对于手机小屏幕这种特殊的应用环境来讲，只有使用滚动条才可以显示，。这一点也许就成为制约手机浏览器开发的主要因素。不过针对这个问题 Opera 最新推出了Small-Screen Rendering(SSR)技术。该技术通过变更Web网页结构使之适应于移动式设备的小型屏幕，因此浏览时无需在水平方向滚动，不过相信其效果也将是很有限的, 毕竟并不是每部手机都可以拥有像Nokia9500的 640x200像素超大屏幕，而在一个小屏幕，比如200*200内，无论如何变化也不能很好的进行布局。

其次，HTML页面中还有很多其他的附加元素，最常见的比如FLASH，以及一些脚本语言，比如JAVAscript，等等，这些元素在手机中，在目前来看短期内是无法全部显示（目前手机上已经出现播放flash的软件,Opera 在一定程度上支持JavaScript以及VBScript）。而且一般的网页中还有很多对用户来讲是无用的信息，比如广告 ，这在一些门户网站占了很大的篇幅，对于手机宝贵的显示区域来讲，他们都是不应该出现的内容。

       就目前来说，对大多数用户，比较实际的，同时也使最广泛的，还是使用GPRS访问wml网页。这就限制了对互联网众多的资源的访问，因为毕竟不是所有的页面都有对应的wml页，而且用户只能等待网页维护者开发出相应的xml，对用户来讲是非常被动的一件事。

 

因此我们设想，如果可以建立一种转换网关，将HTML这种描述性的语言作某种转换，保持其必要的语义信息不变，抽取其中的需要用户进行交互的内容（比如：表单），并以手机适合显示的某种格式传送至手机，就可以在不更改手机硬件与更改WEB页面的同时来使手机访问WEB资源。而且这种转换应当是可定制的，即用户可以选择保留哪些信息，剔除哪些信息，这样就使用户有更大的权力来选择，或者说，定制WEB服务。

 

在这一方面，已经出现了一些尝试,http://www.rss2wap.com，已经实现了将RSS转换为wap，这种转换由于是将一个XML转换为手机可以访问的方式，因此来讲相对的较为简单。但是其中也有很大可以借鉴的部分，比如XML格式在这种转换中的应用。

项目还试图将这种服务扩展到其他方式，例如SMS，虽然在此版本中预计不会进行实现，但是应当进行相关方面考虑，使转换服务拥有良好的外部接口，应与特定的连接方式分离，成为一个相对独立的服务器。

同时，还需要一套辅助工具。他应该可以通过某种方式对转换业务本身进行配置，即可以决定转换哪个页面，这个页面中哪个部分需要转换，哪部分需要删除（比如广告）。为此需要定制一套描述语言，这个语言可以采用XML格式，以便于进行分析管理。这个辅助工具最好是图形化界面，使一个即使不了解HTML格式的用户也可以通过这个工具来定制转换服务。

为了使手机可以连接转换服务器，还需要一个用于处理手机连接的服务器，即手机连接服务器，这个服务器将与应用转换服务器进行合作，实现整套业务，他将把转换服务器同外界进行隔离。

同时与之相配套的，在手机平台还需要编制一个客户端程序，用来作为这个转换服务的终端。

2.2条件与限制

项目本身是一套应用转换系统，他将包括服务器端及客户端两个部分。
在开发过程中，可以使用开发者本身的PC做为服务器临时的运行环境，而手机端在一开始先使用SUN的标准模拟器作为开发平台，而之后需要真机进行测试，目前并不具备。

2.3产品

2.3.1 程序

应用转换服务器程序：应用转换服务器是项目的核心部分，其功能为实现HTML到手机可显示格式的转换功能。
手机连接服务器：连接服务器处理各项连接事务，负责与手机直接通信。
应用转换配置程序：用户可以通过这个用户来定制转换服务。
手机客户端程序：系统客户端。

2.3.2 文档

开发文档，对项目进度进行控制，并进行初步设计与需求分析。
实现文档，对项目的具体实现进行描述。
各部分说明书，对实现后的各部分的功能，使用方式，错误处理等等进行叙述，使最终用户可以通过阅读说明书来使用系统。

2.4运行环境

预计环境为JAVA环境，JVM为 1.5.0 。
服务器端运行硬件平台待定。
数据库待定。
手机端运行环境为MIDP 2.0，支持MIDP2.0的手机都应当可以正常使用。开发中如果必要，可以开发针对某个厂家SDK的产品，但是将尽力使用标准API。

2.5服务

包括两个服务器的配置，调试，测试。
以及手机端的配置，调试，测试。

2.6验收标准

最后的系统应当完成成的目标待定，具体需求特性由需求分析文档给出。

3．实施计划

3.1任务分解

项目将分为四个部分：

       第一部分：对系统整体结构进行分析，制定各部分数据结构，制定初步的服务器—客户端交互协议。其中系统整体设计要求得到整体设计文档以及相关UML图，注意此时的设计针对整体架构，并不对具体实现做设计。

       第二部分：进行快速的迭代式开发，每次迭代将发布一个可执行版本 ，并根据这个版本为参考为下一个制定需求特性以及开发目标，第一个版本的迭代开发实现系统的核心功能，即对HTML格式的文件进行格式化，提取表单等交互内容。
预计总共进行六次迭代，采用测试驱动，由于开发人员较少，降低文档要求，每次迭代只要求测试用例及测试说明。每次迭代平均持续时间为2个星期，结束时会报告进度以及启动下一版本迭代。

       第三部分：交由测试人员进行整体测试，同时由开发人员编制使用说明书，并对文档进行整理。

       第四部分：实际进行部署，并且在部署过程中继续进行测试，并就下一个版本的工作展开设计。

3.2进度

第一部分预计需要一个人月的工作量来进行。

第二部分预计三个人月，这个过程由于开发人员较少，测试的编写与代码的构建无法并行的进行，因此进度较慢。同时考虑六七月份有其他事情的干扰（考试），进度将会延后。

第三部分预计需时一个月。

第四部分无法预计。

3.3预算

无

3.4关键问题

就目前考虑，手机端的配置问题是一个难点，即用户以何种方式对服务进行定制，是用户通过PC连接至服务器进行配置，还是用户直接使用手机来进行配置，无论哪一个方案，实现起来都很复杂。

此外，转换服务的定制部分，如果采取图形化界面的拖放式配置，由于以前并没有开发过类似程序的经验，所以这次项目在这方面将会处于摸索状态，有可能成为项目中最大的难点。

4．人员组织及分工
暂无

5．交付期限
暂无

6．专题计划要点

暂无