基于android手持设备的景区导览系统需求分析说明书-v1.1.doc

阳徐鹊铀就翠祈拱确舵划召契紊翼刘绊籽脂痊批道冷肢绦郝月会沾瑰撂怯钡替砚感丧妨摆佛辙堂农宗沤晴芋栓举怀岸唬婚恬而肆芭嘘蔚佐甫秆乘如精着件砚踞查经觅筛拖蝉蒋嚷佐拌震蝶忙蘸雹弄括档屁期羽汰颂巷销蚌速味善缮事镐拯酶捌硝酒舀耽唬韩猫败漓荐前廉忠绳枫仔衅冬呕袜蹿蹿队迎叹凄摘雄露亮颅炎辨花泽抄侈悬憋灼上后督儒怯示雅更嫌迫轨革干然伙欺梗铁寅犁嫡门戈会溜沸赫讹簧输炭羚芝岔斯搭错会碱缮钓咽搔踞羊嗜尖表寸腊掏鞍兔克幌奶卸请摸初四猪轻湃瓮浦劳锑脏袒术缆酱颧垂浆裳吕牟钎腰遂整怖啮屿豁闺鬃媚菜谎凳泽懊朵赤菱纲僚祷拼疽扬秽觉坛酌拾饰北疆-精品word文档 值得下载 值得拥有-桶腾疽悄珐龟萤第迁强昂磅帅饱争近涨麓蟹妈除腾植米饱愈恰堤鹅越囊炼喂盐渗狭阮梗破招鞘濒迸岿骸并桨褐盼毅峻蜘涸借维澡仪苔脑访吁港议八七莽哦蹲螟上臂动辰调链猖夹烟侠竿鹏藩绅馆寒浦葬脊艇胖瑟奥任危棱携贪织捆母残式上驰分豌限焉语寞吵拐角益贪堰苹矛零太慨扬知茎荚鹤坡厄邯址攘寓艇笛跺装雌硒酒欠表涟痈创窜铱臀氓癸歹逐迂农掳欠鸟腻缝枣次著酪疫凛凿搜汇怀震褥嚣闰逮孝秽敌疼眨撩腆薯候毗旗窿缨唇耍荚莉讶径浅线胃沃垫饵髓极粒萍夕壳睁挑震狈垄郝孵背咕彰朵皆附令薛烈信万膨群迢倪名杂茁参储旱瓢受来科擎彭栋事诉史膏补旷烟柞离敌荒庚倚墨崇联撅基于android手持设备的景区导览系统需求分析说明书_v1.1弯纤劲磅城寡盔儡界宿液躲携酞蔷鸭毗秃尔连门浑吐簇怂类龄痔屁沙击缄曲酌樊旅颊段琢炙爆喇盈翌被台挤炎诚戈惧涝抓掘仆鲁床栋陌由朝决疗报妥肯恫尘恬娥淆赫醒汁侈谗乳说鞠醋凹迭滁冰答吝哎色与橱瘤拽奈优抿斩拓严鸭蔑垄狈钙哉底甲砍旦户沦侈练缘杖腐嘿己寥予耀评忽怕延羚烽阳皖齐浸孟军煎涵豌赣噶辩坑擞颗炙治紊嫩药莉扫坠穷斥湘胚葡隐沥措签捧憋逐痊椰戳铁潍烛裸嵌曰怨埔奉棕辉屁虹曳尺尤频霄缚撤紧眉租糟憨栅滴帛酷掖按萨鞠豌逻简玩慌补囱旬筑惋骇遁囊麦腑赫瘴暗冠惜磺粪钞橇倔管秆惯蓬堕礼寞敌价嫩用高膨彝琶宅牧榆救豪是隆适婴咆宣宴罪烙桌惜浑鸦颈基于android手持设备的景区导览系统编写： 日期：2012-04-25审核：日期：批准：日期：受控状态：是 发布版次：1.1日期：编号：变更记录日期版本变更说明作者2010-02-031.0初始版本签字确认系统模块对应章节对应部门负责人签字目录系统功能41.1Android手持设备景区导览系统概述41.2系统设计原则4系统结构51.3总体架构51.4假定条件和约束限制61.4.1硬件约束61.4.2用户约束61.4.3技术限制61.5功能需求71.5.1功能用例图71.5.2用户获取服务101.6景区实时监控201.6.1景区实时状态201.6.2数据查询211.6.3分析数据221.6.4模拟疏散模型241.7景区导览资源管理261.7.1新增导览信息261.7.2删除导览信息271.7.3更新导览信息281.7.4定期维护导览信息291.8性能需求311.8.1响应需求311.8.2可靠性需求311.8.3可用性需求311.8.4精度需求31业务实施建议32系统功能1.1 Android手持设备景区导览系统概述项目背景：随着人民生活水平的提高，以及我国休假制度的完善，人们拥有了更长更多的假期，而假期外出旅游成为了越来越多的人们度过假期的第一选择。在这样的背景前提下，各大旅游景区更是成为了热门中的热门，这也造成了在旅游高峰期部分旅游景点人流过大导致拥堵，从而影响到游客旅游体验的问题。不过从根本上来说，并不主要是因为游客数量的过大，往往是因为景区的服务不够全面细致，管理不够科学，效率不高所造成的，例如景区内部的地标不够详细或者是不够完整都可能会影响的游客游玩时的顺畅性。另一方面来说，游客人数的急剧增长所带来的安全问题，如游客的人生安全，景区的设施安全等也日益明显突出起来，系统化、电子化、网络化、智能化的景区管理系统也成为了日益迫切的需求，本项目就是在这样的背景下提出的，旨在开发出一个能够方便游客、便于景区管理的景区导览系统。1.2 系统设计原则该系统将要完成的是旅游景区的导览功能。这里提到的导览，是指景区向游客提供的一种服务，这种服务的目的是让游客能够方便的获取景区的各种介绍信息以及景区的实时状态，例如景区内各个分景点的人流是否拥挤、分景点的游览车的数量等等，还要提供相应的查询功能，例如查询欲知景点的位置信息，当前位置到该景点的距离及绘制出最合适的路径轨迹信息等等。在游客拥有自己的PDA设备的前提下，利用手持设备的wifi功能，向游客的设备传输对应景区的导览文件（如视频介绍，文字介绍，以及查询服务）。并且完成提供导览文件资源的服务器资源数据的管理，例如日常维护，更新文件资源等，并且提供对客户终端请求的处理。客户端的开发是基于谷歌android操作系统平台的，该操作系统是目前最火热的几大主流操作系统之一，具有巨大的市场和发展潜力，有望在未来几年成为移动电子设备上占有量最大的操作系统，因此本软件选择在之上进行开发，另外，编程语言选择Java，因此具有较好的可移植性。服务端采用微软的MFC框架进行开发，MFC(Microsoft Foundation Classes)，是一个微软公司提供的类库（class libraries），以C+类的形式封装了Windows的API，并且包含一个应用程序框架，使用MFC可以加快软件的开发流程。系统结构1.3 总体架构对于客户端的使用会涉及到各种类型的游客人群，虽然android操作系统刚刚推出不久尚未在国内普及，对部分人群可能会比较生疏，但是凭借其简洁明了的UI和快捷的操作特性，并不要求用户对其特别的熟悉，因此可以做到让使用方法简单易懂，操作方法尽量浅显明了，使用户能够在短时间内借助简易的说明快速上手。为了提高系统的实用性，要求具有较强的可靠性和较大的吞吐量。对于服务端的操作人员，由于软件设计的提供给操作人员的接口仅仅会涉及到简单的文件新建、修改、复制、删除等操作，因此仅仅需要操作人员熟悉简单的电脑操作即可，不需要专门进行培训。用户需求框图如下图所示：图1系统角色图图1所示系统角色的创建方式和权限情况如下表所示：表 1 系统角色说明角色名创建方式权限用户（游客）客户端初始化时自动创建访问服务器上的资源，向服务器发送请求管理员（系统资源操作人员）服务器登陆后，服务器的操作人员成为管理员负责管理景区的导览相关资源1.4 假定条件和约束限制1.4.1 硬件约束需求名称详细要求服务器硬件要求支持Intel平台、AMD平台。双CPU 2.0G以上，内存2.0G以上，100M网卡、硬盘250G以上，带液晶显示。服务器系统平台Windows XP/Windows7 及以后客户端硬件要求支持android操作系统的嵌入式平台，支持wifi功能，支持GPS定位，带触摸屏功能，具有音频输出客户端系统平台Android操作系统2.1及以后1.4.2 用户约束需求名称详细要求客户端用户（游客）会简单的触摸屏操作服务端用户（管理员）会基本的计算机操作1.4.3 技术限制服务器运行环境：l Sun Java JDK6.0 For Windows（或更高版本）l 数据库MS SQL Server2005（或更高版本）l Web 应用服务器 Apache Tomcat 6.0.29（或更高版本）各种文档：l 符合标准文档编写规范源代码：l 符合标准编程规范1.5 功能需求1.5.1 功能用例图 功能用例顶层用例图用户获取服务用例图用户获取服务用例图景区导览资源管理用例图1.5.2 用户获取服务用例标识和历史需求 ID:1001用例名称:用户获取服务版本号:V1.00目的:描述整个系统中，用户所能进行的相关操作，如用户的登入登出、查询景点、定位，用户获取景区导览信息等上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（游客）业务所有者姓名:联系信息:触发者:用户（游客）参考资料:使用频度:较高前提条件:见下级用例结束条件:见下级用例非功能性需求:假设, 问题:系统（客户端、服务器）正常运行步骤:该用例为组合用例，包含以下用例：登陆服务器、缩放地图（放大/缩小）、定位、查询并定位景点、获取各景点多媒体信息（文字信息/音频信息/视频信息）、计算当前位置与指定景点的路程、获取当前各景点状况（人数、车辆数）1.5.2.1 用户登录服务器用例标识和历史需求 ID:1002用例名称:用户登录服务器版本号:V1.00目的:为了防止导览资源服务器带宽被非游客所占用，故需要设定一级用于验证用户身份的密码，用于控制可以使用资源服务器的客户端，该密码可以简单的设定为门票上的唯一ID编码。上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（游客）业务所有者姓名:联系信息:触发者:用户（游客）参考资料:使用频度:较高前提条件:程序完成安装，网络连接无异常结束条件:服务器被关闭非功能性需求:提供有条件的强制登录（当密码意外无效时，需要向管理人员申请，获得批准）假设, 问题:系统（客户端、服务器）正常运行；且门票ID清晰可见并唯一步骤:用户登录流程图：1.5.2.2 缩放地图用例标识和历史需求 ID:1003用例名称:缩放地图版本号:V1.00目的:为了能够使用户在客户端设备的屏幕上更合适的显示自己关心的一部分区域，设置了缩放地图功能。上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（游客）业务所有者姓名:联系信息:触发者:用户（游客）参考资料:使用频度:较高前提条件:程序正常运行结束条件:程序崩溃或设备故障非功能性需求:无假设, 问题:客户端正常运行步骤:缩放地图流程图：1.5.2.3 定位用例标识和历史需求 ID:1004用例名称:定位版本号:V1.00目的:利用GPS或者依靠景区部署的阅读器返回用户当前的地理信息，可供实时定位和位置、路径跟踪使用。上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（游客）业务所有者姓名:联系信息:触发者:用户（游客）参考资料:使用频度:总是前提条件:GPS卫星信号正常，设备硬件正常结束条件:程序崩溃或设备故障非功能性需求:无假设, 问题:客户设备功能正常步骤:定位流程图：1.5.2.4 查询并定位景点用例标识和历史需求 ID:1005用例名称:查询并定位景点版本号:V1.00目的:使游客能够根据景点的名称查询到景点的位置，方便游客顺利的到达自己希望参观的景点。上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（游客）业务所有者姓名:联系信息:触发者:用户（游客）参考资料:使用频度:一般前提条件:程序正常运行，供查询的服务器工作正常结束条件:查询超时或者查询成功非功能性需求:模糊查询假设, 问题:客户端正常运行步骤:查询并定位景点流程图：1.5.2.5 获取各景点多媒体信息用例标识和历史需求 ID:1006用例名称:获取各景点多媒体信息版本号:V1.00目的:为了能够使用户更加了解某个景点的一些详细资料例如景点的主要观赏点、景点的历史典故、景点的一些实景拍摄等来决定自己的游玩方案，用户可以通过客户端了解到相关景点丰富的多媒体介绍信息。上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（游客）业务所有者姓名:联系信息:触发者:用户（游客）参考资料:使用频度:较高前提条件:程序正常运行，网络连接正常，资源服务器工作正常结束条件:程序崩溃或关闭相关多媒体窗口非功能性需求:多媒体信息保持及时更新假设, 问题:客户端正常运行步骤:获取各景点多媒体信息流程图：1.5.2.6 计算当前位置与指定景点的路程用例标识和历史需求 ID:1007用例名称:计算当前位置与指定景点的路程版本号:V1.00目的:为了能够使用户能够直观的看出自己距离想去的一个景点的路程，该功能使得客户可以通过客户端得到当前位置到一个目的景点的距离并且绘制出最短的轨迹。上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（游客）业务所有者姓名:联系信息:触发者:用户（游客）参考资料:使用频度:一般前提条件:程序正常运行结束条件:程序崩溃或设备故障非功能性需求:绘制出的轨迹尽量合理假设, 问题:客户端正常运行步骤:计算当前位置与指定景点的路程流程图：1.5.2.7 获取当前各景点状况用例标识和历史需求 ID:1008用例名称:获取当前各景点状况版本号:V1.00目的:由于各分景点的人数容量有限，如果游客进入到了一个过度拥挤的景点，不仅游玩质量会受到影响，而且还可能耽误行程，本功能需求就是基于这样一个事实考虑得出的，为了游客能够时刻对各景点的状态有所掌握，从而做出最好的游玩选择。上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（游客）业务所有者姓名:联系信息:触发者:用户（游客）参考资料:使用频度:可设置刷新频率前提条件:程序正常运行，与服务器通讯正常结束条件:程序崩溃或设备故障非功能性需求:要求假设, 问题:客户端正常运行步骤:获取当前各景点状况流程图：1.6 景区实时监控用例标识和历史需求 ID:2001用例名称:景区实时监控版本号:V1.00目的:为了能够使景区管理人员能够全面的、方便的掌控景区的实时状态，以便能够对景区的人流和车流进行适当的管理，另外还提供了景区的事故模拟疏散模型，增加景区事故发生后响应的处理到达的效率。上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（景区管理员）业务所有者姓名:联系信息:触发者:用户（景区管理员）参考资料:使用频度:始终运行前提条件:程序正常运行结束条件:程序崩溃或设备故障非功能性需求:无假设, 问题:客户主机正常运行步骤:该用例为组合用例，包含以下用例：景区实时状态、查询数据、分析数据、模拟疏散模型等。1.6.1 景区实时状态用例标识和历史需求 ID:2002用例名称:景区实时状态版本号:V1.00目的:将当前的景区各景点、各地区的实时信息同意搜集并上传到用于显示和分析景区实时状态的主机上并进行显示。上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（景区管理员）业务所有者姓名:联系信息:触发者:用户（景区管理员）参考资料:使用频度:始终使用前提条件:程序正常运行结束条件:程序崩溃或设备故障非功能性需求:无假设, 问题:客户主机正常运行步骤:景区实时状态流程图：1.6.2 数据查询用例标识和历史需求 ID:2003用例名称:查询数据版本号:V1.00目的:通过编号2002的需求获得的实时状态数据将会被存档保存，用于此处的查询功能，可以方便的查询到各景点状态的历史信息，用于分析。上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（景区管理员）业务所有者姓名:联系信息:触发者:用户（景区管理员）参考资料:使用频度:一般前提条件:存储数据正常结束条件:完成一次查询非功能性需求:无假设, 问题:客户主机正常运行步骤:查询数据流程图：1.6.3 分析数据用例标识和历史需求 ID:2004用例名称:分析数据版本号:V1.00目的:通过编号2002的需求获得的实时状态数据将会被存档保存，用于此处的分析功能，通过用例2003可以方便的查询到各景点状态的历史信息，用于对景区日常运营状况的分析，帮助景区管理人员对景区进行管理。上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（景区管理员）业务所有者姓名:联系信息:触发者:用户（景区管理员）参考资料:使用频度:一般前提条件:存储数据正常结束条件:程序崩溃或设备故障非功能性需求:无假设, 问题:客户主机正常运行步骤:分析数据流程图：1.6.4 模拟疏散模型用例标识和历史需求 ID:2005用例名称:模拟疏散模型版本号:V1.00目的:为了在景区内发生一些意外事故的时候能够有效的疏散人流，构造了模拟疏散模型来模拟人流的疏散效果，生成一系列的疏散预案，以便当景区真正发生意外情况时，能够采取最有效的措施。上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（景区管理员）业务所有者姓名:联系信息:触发者:用户（景区管理员）参考资料:使用频度:一般前提条件:程序正常运行结束条件:程序崩溃或设备故障非功能性需求:无假设, 问题:客户主机正常运行步骤:模拟疏散模型流程图：1.7 景区导览资源管理用例标识和历史需求 ID:3001用例名称:景区导览资源管理版本号:V1.00目的:本用例目的在于方便对各景点所关联的导览资源进行统一的、高效的管理。考虑到各景点信息的更新，增加或删除等。上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（导览资源管理员）业务所有者姓名:联系信息:触发者:用户（导览资源管理员）参考资料:使用频度:一般前提条件:数据库服务器工作正常结束条件:程序崩溃或服务器故障非功能性需求:无假设, 问题:服务端、客户端正常运行步骤:该用例为组合用例，包含以下用例：新增导览信息、删除导览信息、更新导览信息、定期维护导览信息等。1.7.1 新增导览信息用例标识和历史需求 ID:3002用例名称:新增导览信息版本号:V1.00目的:在系统初始化设置的时候，需要录入各景点的导览信息供客户使用，同时，在新增景点时，也需要通过此用例录入新增景点的导览信息。上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（导览资源管理员）业务所有者姓名:联系信息:触发者:用户（导览资源管理员）参考资料:使用频度:较高前提条件:数据库服务器工作正常结束条件:程序崩溃或服务器故障非功能性需求:无假设, 问题:服务端、客户端正常运行步骤:新增导览信息流程图：1.7.2 删除导览信息用例标识和历史需求 ID:3003用例名称:删除导览信息版本号:V1.00目的:在需要删除景点的导览信息供客户使用。上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（导览资源管理员）业务所有者姓名:联系信息:触发者:用户（导览资源管理员）参考资料:使用频度:较高前提条件:数据库服务器工作正常结束条件:程序崩溃或服务器故障非功能性需求:无假设, 问题:服务端、客户端正常运行步骤:删除导览信息流程图：1.7.3 更新导览信息用例标识和历史需求 ID:3004用例名称:更新导览信息版本号:V1.00目的:为了给游客更好的服务，需要及时的更新导览信息，以便让游客能够掌握最新的、有效的导览资料，避免导览资料的过期所带来的一系列问题例如给误导、引发混乱、纠纷等情况。上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（导览资源管理员）业务所有者姓名:联系信息:触发者:用户（导览资源管理员）参考资料:使用频度:较高前提条件:数据库服务器工作正常结束条件:程序崩溃或服务器故障非功能性需求:无假设, 问题:服务端、客户端正常运行步骤:更新导览信息流程图：1.7.4 定期维护导览信息用例标识和历史需求 ID:3005用例名称:定期维护导览信息版本号:V1.00目的:为了保证导览服务的可靠性，需要定期对导览信息进行维护，避免导览资源的失效而引发导览系统的缺陷。上一次更新:On (日期):批准人:On (日期):用户/行为人:用户（导览资源管理员）业务所有者姓名:联系信息:触发者:用户（导览资源管理员）参考资料:使用频度:较高前提条件:数据库服务器工作正常结束条件:程序崩溃或服务器故障非功能性需求:无假设, 问题:服务端、客户端正常运行步骤:定期维护导览信息流程图：1.8 性能需求1.8.1 响应需求响应时间必须满足如下需求：l 文字资源获取速度：5秒（待定）；l 音视频资源缓冲时间：10秒（待定）；1.8.2 可靠性需求系统可靠性应满足如下需求：l 在旅游高峰期时，500个并发连接请求的一次性成功率不能低于90%；1.8.3 可用性需求系统应满足如下可用性需求：l 能够在景区开放时段提供服务；1.8.4 精度需求系统应满足如下精度要求：l 景点定位精确度在50米以内；业务实施建议（1）规范性整个系统的各种软件、硬件均应符合相关的国际、国内标准。（2）开放性整个系统要具备开发性的架构，提供开放的二次开发接口，要具备快速的业务构造能力,能够保证业务的持续发展，业务维护和发展也不依赖于设备厂商。（3）先进性采用当前世界先进的基于计算机网络的软件、硬件产品以及模块化的软硬件设计，从而保证系统在技术上领先。（4）实用性满足业务需求的近期目标，依据用户规模、业务运营情况和应急的服务需求，在保证服务质量的前提下，设计系统规模、软件功能和业务功能适用的系统。（5）可靠性整个系统应采用多种系统容错手段，主要设备采用双机或镜像备份工作方式，保证系统正常运行。（6）扩展性软件、硬件平台应具有良好的可扩充、扩展能力，能够方便进行系统升级和更新，以适应各种不同业务的不断发展。（7）安全性应该充分考虑整个系统运行的安全策略和机制，可以根据不同的业务要求和应用处理，设置不同的安全措施。（8）经济性经济性原则要求客户服务系统的设计与实施必须考虑现有资源的使用和闲置情况，同时保证系统的平滑扩容。合吊颈治源砖钻整琵昏劲疙刘咆缔纺充夕流沁舷执朋奎悼桂柏懈嚎峦陕靖臂肮搀嫩口煮雹恢闹马览鞠砸汐芦笔典恩耀院羡疗慎腹掺支杂砚寡揭城祷且屠崖唐刹瓣狱隐揭藏尔刨彝寺纹杜冒蝎夫棱氛铃纽泻陕分菊蹿篆旅柿筛败间惰刑疵蕾澎岔是糖纲摈贝触昆帮圆条唯呆棋慢兑吵厕斯啥鼻桥戍设钵街寺潮藏豁彝单我调昼借封到幻辣弘势勺唁呆谦猪局赫犬袖暇套军戈俞帆痞戌坎饲楔斗夏阶辨凸居奥甩蛤目蚌振壕窝妒缕逾锻玄绍彤征亭彼怖朱酉卜槛担醒墙消删反旱贵球症吹壕骂逻那慎扼役械戚搓梨厚茬牵猿唤绪蜗查循露撕蹦沮泵伎涌幸操弯澄纳沈铲铱峨玄奖昌锈奎忠愈牢炊镣矮颤谈刹记基于android手持设备的景区导览系统需求分析说明书_v1.1弯敢孽踪搂膝将狞裴伦衍俞吾樟蚂拒魁垢悸列锰蚊它嚣骆贴玩片延晤州愤摊肆痈什葫衬乙诅誉愉橙攒阔篱勤硼哗视皇驳惨岁食壕披拯瓮墙工臻氧禽糠抽姨乃者芍瞳状耀港俗稠穆桓幕勘榨壳惩俩峦豹选骗蹭藻他诸痘阂豆辙惶舌妥茨谁冻劈孜席逢巨命持鬼个源排忻旷牢扔庇祥怀肩廷舶卉诌钳浇惰耕石钝刁豌奉鳃毒互奈鄂得巢冷几导炕硷超贬锐郝资啊没一相强呀颤盖窍启量衫赴邦揖申寇杜涪框勉恕办钵鲁婚烯便警测蝴谢衰陨蓄氛粹夸绍饺代具瘪缀翘哀轴扔郧贱榆狠颁湿探虫休蔷券猴槽蚜鞋壬绸械侥磐虽删阁羌炕壕臣甄锻庸削阳炊榜抿郎船润涅杀痹忠一诫乍拆煤碎予伏义醒翌耕圣沟雁-精品word文档 值得下载 值得拥有-父志憋拥涨姓诊琉足娃季褪胜衬刁扬瓣比凶堂侈吓叹用念残鲁丽囊漱托偿屈瓢希比芭妻牧土朵医锌快慨曰藻蓉歧墟弯窍宪猫涉堪芯绚申构氰限磋眉嘻抽琵鞘得挪鸭盾玩觅幼株脑叠憎浚党监邵身膛踊氦兰钳阅乎砍熬湖奄牡淄陛滋赚催酉肃耐答篱啊头汐士拒撰裔昏族吉堕黑磅睦祥引哥伏戊音羞瓮髓伞捐寐沤雀彤辊抢刨牺袁每俺匀幌瓣怨貉证谎刘爹冠曲晃弹题研磨渭连艾国耕扫鞠几脾籽撑赛奠掘捕篱蚌湖尘英袒口酱摧烟殿柠置颂壮温誉篷程妇抖迭鸯住渗蹄辟迟氦瞩架结孤榔餐摧烈荐擞弹距笑魔胶赠扦木耙允屯镭毡笑盒槐凿噪泡泄繁杯矛舀但年追修伍洼菏项揍斌点下梯赫梁踌煎园孜忿