<日/月/年> <详细信息> <姓名> 2014/3/11 2．0 邱新海 ITS-系统架构设计文档 目录 1.简介 4 1.1目的 4 1.2范围 4 1.3定义、首字母缩写词和缩略语 4 1.4参考资料 4 1.5概述 错误！未定义书签。 2.整体说明 4 2.1简介 4 2.2构架表示方式 4 2.3构架目标和约束 4 3.用例说明 5 3.1核心用例 6 3.2用例实现 7 4.逻辑视图 8 4.1逻辑视图 8 4.2分层 8 4.2.1应用层 8 4.2.2业务层 8 4.2.3中间层 9 4.2.4系统层 9 4.3架构模式 9 4.4设计机制 错误！未定义书签。 4.5公用元素及服务 9 5.进程视图 9 6.部署视图 9 7.数据视图 9 8.大小和性能 9 9.质量 9 10.其它说明 9
ITS-系统架构设计文档 系统架构设计文档 1. 简介 系统构架文档的简介应提供整个系统构架文档的概述。它应包括此系统构架文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述 1.1 目的 本文档将从构架方面对系统进行综合概述，其中会使用多种不同的构架视图来描述系统的各个方面。它用于记录并表述已对系统的构架方面做出的重要决策,以便于开发人员高效的开发和快速修改和管理。 1.2 范围 本文档用于oto项目组目前正在开发的android app电器管家2.0和已经发布的1.0的开发或修改 1.3 定义、首字母缩写词和缩略语 参考系統需求文档电器管家APP2.020140214 1.4 参考资料 1、 系統需求文档电器管家APP2.020140214 2、 品牌品类及映射建议App数据结构及数据样例 2. 整体说明 2.1 简介 在此简单介绍系统架构的整体情况，包括用例视图、逻辑视图、进程视图、实施视图的简单介绍。另外，简要介绍各种视图的作用和针对的用户 2.2 构架表示方式 本文档将通过以下一系列视图来表示4In1系统的软件架构：用例视图、逻辑视图、部署视图。本文档不包括进程视图和实施视图。这些视图
都是通过PowerDesigner工具建立的UML模型。 2.3 构架目标和约束 系统架构在设计过程中有以下设计约束： 1、 安全性：通讯协议采用加密的方式、存放app端数据要进行混淆器加密、电话号码和logo不能通过反编译批量拿走。 2、 响应速度： 分类 细项 要求 安装 安装耗时 10秒 卸载 卸载耗时 5秒 系统消耗 CPU 9%
ITS-系统架构设计文档 RAM 10M 启动 Loading 5秒 EDGE网络环境 流量 流量消耗 电量 消耗电量 兼容 Android 95%手机支持安装 品牌 5秒 EDGE网络环境下 索引 品类 5秒 EDGE网络环境下 嵌入html 时间 3秒 EDGE网络环境下 3、 分辨率适配原则 分辨率 长宽比 市场占有率 是否适配 32 Y 1 800 480 60.0% 15 Y 2 480 320 66.7% 14 Y 3 1280 720 56.3% 12 Y 4 854 480 56.2% 8 Y 5 960 540 56.3% andriod 4 Y 1920 1080 56.3% 6 2 Y 1280 800 62.5% 7 1 320 240 75.0% 8 1 1184 720 60.8% 9 1 10 其他 0 3. 用例说明 本章选择了app2.0的部分功能用例,其他部分请参考系統需求文档电器管家APP2.020140214 原型
ITS-系统架构设计文档 功能说明 通过输入模糊查找和右边的首字母查找、查询出自己想要查找品牌、然后拨打电话进行报修。 3.1 核心用例 原型
ITS-系统架构设计文档 功能描述 此功能主要主要描述了app2.0的建党功能以及档案详情页面的呈现 3.2 用例实现 本节通过几个精选的用例（场景）实现来阐述系统的实际工作方式，并解释不同的设计模型元素如何促成其功能的实现
ITS-系统架构设计文档 4. 逻辑视图 4.1 逻辑视图 4.2 分层 试图 controller层 UI层 Ui Views View Controller DATA层 Data Provider Memory Cache Local Data Util/Config NetWork
DownLoad File DB 4.2.1 Ui层 数据展示于管理 用户交互 制
Adapter 4.2.2 业务层
持久化数据（内存中，相当于全局数据）
绘
数据加工
（数据层的数据有时候需要进行交工成UI层需要的数据） 数据变化的通知机制
ITS-系统架构设计文档 4.2.3 数据层 数据访问（DB，文件，网络等） 缓存
（图片，文件等） 4.2.4 系统层 4.3 架构模式 本系统主要采用的还是mvc的设计模式 1) 视图（View） 视图层能够实现数据有目的的显示（理论上，这不是必需的）。在视图中一般没有程序上的逻辑。 为了实现视图上的刷新功能，视图需要访问它监视的数据模型（Model），因此应该事先在被它监视的数据那里注册。2) 控制器（Controller） 控制器起到不同层面间的组织作用，用于控制应用程序的流程。它处理事件并作出响应。 “事件”包括用户的行为和数据模型上的改变。 3) 模型层（Model）：“数据模型”（Model）用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。“模型”有对数据直接访问的权力，例如对数据库的访问。“模型”不依赖“视图”和“控制器”，也就是说，模型不关心它会被如何显示或是如何被操作。但是模型中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监 视此模型的视图必须事先在此模型上注册，从而，视图可以了解在数据模型上发生的改变。 4.4 公用元素及服务 暂无 5. 进程视图 暂无 6. 部署视图 暂无 7. 数据视图 见app2.0数据结构 根据项目的实际情况，此节可以省略不写 8. 大小和性能 参考系統需求文档电器管家APP2.020140214 9. 质量 参考系統需求文档电器管家APP2.020140214 10. 其它说明 暂无
ITS-系统架构设计文档