团队作业2
目录
1.概述
1.1 开发背景
1.2 开发目标
1.3 参考资料
1.4 设计原则
2.需求分析
2.1 需求陈述
2.2 操作用例
2.3 功能分析划分
2.3.1 系统登录
2.3.2 用户管理
2.4 运行环境
3.总体设计
3.1 系统建模
3.1.1 层次方框图
3.1.2 ER图（实体-联系图）
3.1.3 类图设计
3.2 接口设计
3.2.1 内部接口设计
3.2.2 登录界面设计
3.2.3 用户管理界面设计
3.3数据库结构设计
3.3.1 数据库E-R图
3.3.2 数据库逻辑设计
3.4 出错处理
3.5 安全保密设计
4.详细设计
4.1 程序流程图
4.2 伪代码编写
5.实现
5.1 编码
5.1.1 代码约定
5.1.2 代码编写原则
5.2 测试要点
5.2.1 登录测试要点
5.2.2 主界面测试要点
5.3 测试结果和总结
6.维护
6.1 维护方法
6.2 维护文档
6.3 功能拓展方法
1 概述
1.1 开发背景
目前市场尚未出现或基本没有这方面的软件:基于社会组织或特定志愿爱心活动，在软件上实现登录、预约、参与的这么一个服务系统，经过我们的调研和思考，认为这方面服务应该被发现和发倔，使得有更多的人参与到爱心志愿活动中来。
1.2 开发目标
基本功能：1.实现用户登录和管理员登录两种。用户需先注册用户帐号和密码，管理员统一使用固定账号与密码。
2.主界面分为三个部分：首页、推荐、我的
首页模块主要包括“我的预约”、“活动信息公布”。
推荐主要包括“近期活动”、“精彩回顾”。
我的主要包括“我的信息”、“设置”、“退出账户”。
设置可包括“修改帐户密码”、“网办进度”。
1.3 参考资料
暂无
1.4 设计原则
第一原则：简洁性。软件设计并不是一种随意的过程，在软件设计中需要考虑很多因素。所有的设计都应该尽可能简洁，但不是过于简化。这有助于构建更易于理解和易于维护的系统。这并不是说那些特征甚至是内部特征应该以“简练”为借口而取消。的确，优雅的设计通常也是简洁的设计，简练也不意味着“快速和粗糙”。事实上，它经常是经过大量思考和多次工作迭代才达到的，这样做的回报是所得到的软件更易于维护且存在更少错误。
第二原则：调用数据库。由于用户需要预约或进行相关操作，故需要调用数据库，完成相应功能。
第三原则：可拓展性。通过软件框架来实现：动态加载的插件、顶端有抽象接口的认真设计的类层次结构、有用的回调函数构造以及功能很有逻辑并且可塑性很强的代码结构。可扩展性是软件设计的原则之一，它以添加新功能或修改完善现有功能来考虑软件的未来成长。可扩展性是软件拓展系统的能力。
2 需求分析
2.1 需求陈述
本次作业需要完成的是题名为爱心服务平台的互联网+项目。主要需求为用户能够通过登录或注册进入主界面查看到推送的信息，即身边的社会组织或特定的志愿活动，并且能够预约申请加入他们的团队，包括预约和取消预约功能，用户还可以查看并且修改自己的个人信息和自己预约过的活动。最后，需要有退出账户功能。
2.2 操作用例
首先具有登录和注册功能，登录功能包括用户登录和管理员登录功能，登录或注册之后进入主界面，其中有三个选择，为：“首页”，“推荐”和“我的”。点击“首页”会弹出一个下拉框，包括“我的预约”和“活动信息分布”两部分；“推荐”部分主要包括“近期活动”和“精彩回顾”；“我的”部分主要包括“我的信息”、“设置”和“退出账户”，可包括点击任一部分会推送相应的内容。其中“设置”部分可包括“修改账户密码”和“网办进度”，点击“退出账户”之后，页面弹回到登录界面。
2.3 功能分析划分
2.3.1 系统登录
登录模块分为三种，注册，普通登录，自动登录。
点击注册需要填写如姓名，设置密码等信息，，完成注册进入主界面。其中可能出现的情况：姓名含有字符、特殊符号（如*、￥、%、@等）、密码无特殊符号（可以是数字或者大小写均可））以上情况都会导致注册或者登录失败，需重新点击注册或清空重新登录。
登录需要填写账号和密码作为登录条件，若账号和密码不符，则会弹出账号或密码错误，需重新登录。
自动登录功能：点击选择框选中自动登录功能，即可实现下次进入是自动登录。
2.3.2 预约管理
主页推送的“活动信息公布”，点击进去之后会显示活动的详细信息并且下方有是否预约活动的选项，点击预约即可预约成功。若不预约，点击返回即可。
“我的预约”功能能够将用户预约的活动详情以列表形式展现出来，点击每个活动连接即可显示活动明细，点击右上角“选择”，会在每个预约信息后出现一个复选框，点中即可选择删除，复选框可以多选和全选。
2.3.3用户管理
在“设置”部分中会对用户的个人信息进行管理，可以查看和修改用户的详细信息，比如说点击修改密码，会弹出一个界面，需要填写旧密码、新密码和再一次填写新密码。如果就密码输入错误或两次输入的新密码不一致，则修改失败，刷新修改界面，若果放弃修改，点返回即可。
2.4 运行环境
使用Android Stdio1.0软件编写
运行要求：Android 4.0及以上
2.5 出错处理
（1）“用户”界面可能出现的错误
a.注册时出错
1）用户名，密码中出现非法字符或超出额定长度；
2）验证码错误。
b.登录出错
1）用户名或密码错误
2）软件可能出现的错误
（2）首页包括：我的预约、志愿活动
“志愿活动”页面可能出现的错误：
1）出现过期活动；
2）活动信息出错：时间，地点与实际志愿活动不符，活动简介与活动信息不符；
3）点击确定参加后，界面无响应；
“我的预约”界面错误：
1）在志愿活动界面成功预约后，在我的预约中无记录；
2）预约记录与实际预约情况不符；
（3）“我的”界面
1）修改界面无响应，无法修改信息；
2）显示成功修改后，信息不变；
3）退出后会清空账号信息
2.6保障安全性
初次注册的用户会绑定一个手机号码用作验证，另外用户可选择数字密码或图案密码对涉及个人信息的页面进行保护。
密码启动机制
1.用户可选择开启密码输入，开启后用户在每一次需要访问个人信页面时都需输入预先设置的密码才能进入页面。（可直接实现防盗，但操作不便）
2.防盗应急机制（可选择开启，推荐开启）
用户在开启防盗应急机制后，需要绑定另一个手机号码作为备用号码。当手机失窃或更换手机号码时，需在使用备用号码的手机上重新注册账户，收取验证码的手机号码即为备用号码，系统检测到该号码后会提示用户选择启动密码保护（提前未开启密码保护），手机丢失可选择冻结账号，无法登陆，用户可使用备用号码进行重新注册，个人信息允许相同；更换手机号码则可以选择正常登陆。
3 总体设计
3.1 系统建模
3.1.1 层次方框图
3.1.2 ER图（实体-联系图）
3.1.3 类图设计
【使用UML画出各个类的属性、继承和方法】
3.2 接口设计
【各个子系统之间的接口和用户接口】
3.2.1 内部接口设计
【各个部件是通过何种方式进行连接，比如通过远程数据库，http等】
3.2.2 登录界面设计
效果展示：
3.2.3 用户管理界面设计
3.3 数据库结构设计
3.3.1 数据库E-R图
3.3.2 数据库逻辑设计
user
message
4 详细设计
4.1 程序流程图
【具体来说就是把经过总体设计得到的各个模块详细的加以描述。】
4.2 伪代码编写
【使用中文或者英文进行伪代码编写，以后这些伪代码将会成为代码的注释】
5 实现
5.1 编码
5.1.1 代码约定
1.零注释（公共 API 除外）
2.不要用 “Test” 为测试方法开头
3.不要使用@Override
4.不要使用 getX()/setY() 这样的函数名
5.可运行的代码>高性能的代码
6.使用自己的异常类型
5.1.2 代码编写原则
(1) 类名首字母应该大写。字段、方法以及对象(句柄)的首字母应小写。对于所有标识符，其中包含的所有单词都应紧靠在一起，而且大写中间单词的首字母。
若在定义中出现了常数初始化字符，则大写static final基本类型标识符中的所有字母。这样便可标志出它们属于编译期的常数。
Java包(Package)属于一种特殊情况：它们全都是小写字母，即便中间的单词亦是如此。对于域名扩展名称，如com，org，net或者edu等，
全部都应小写(这也是Java 1.1和Java 1.2的区别之一)。
(2) 对于自己创建的每一个类，都考虑置入一个main()，其中包含了用于测试那个类的代*。为使用一个项目中的类，我们没必要删除测试代*。
若进行了任何形式的改动，可方便地返回测试。这些代码也可作为如何使用类的一个示例使用。
(3) 应将方法设计成简要的、功能性单元，用它描述和实现一个不连续的类接口部分。理想情况下，方法应简明扼要。
若长度很大，可考虑通过某种方式将其分割成较短的几个方法。这样做也便于类内代码的重复使用(有些时候，方法必须非常大，但它们仍应只做同样的一件事情)。
(4) 设计一个类时，请设身处地为客户程序员考虑一下(类的使用方法应该是非常明确的)。
然后，再设身处地为管理代码的人考虑一下(预计有可能进行哪些形式的修改，想想用什么方法可把它们变得更简单)。
5.2 测试要点
5.2.1 登录测试要点
【描述该如何测试，数据的输入，类型】
5.2.2 主界面测试要点
……
5.3 测试结果和总结
6 维护
6.1 维护方法
1.迅速发现需要变更内容的工具
无论是修复 bug 还是系统增强，首先都要找到该用例调用的你需要修改的类及方法。基本有两种方式理解一个用例的工作方式，静态代码分析和运行时分析。
源码分析统计扫描所有代码并且展示类之间的关系。市场上有很多设备与工具。比如：Architexa， AgileJ， UModel， Poseidon 等。
所有的静态代码分析工具缺点在于无法确切展示用例中类或方法的运行时调用情况。因此 Java 新加入了特性，如回调机制（callback patterns）。如静态分析工具无法推断出当页面提交按钮被点击时哪个 Servlet 被调用了。
运行时分析工具能够展示类和方法在用例运行时的状态。工具包括：MaintainJ， Diver，jSonde，Java Call Tracer 等。这些工具可以捕获运行时的堆栈状态，并以此为一个用例 生成序列图和类图。
序列图展示了该用例在运行时所有调用的方法。若你在修复一个 bug，那这个 bug 很可能就是这些被调用的方法之一。
若你在增强已有功能，利用序列图理解调用流程然后再修改。可能是新增一个验证，修改 DAO 等。
若你在新增功能，找到一些相似的特性，利用序列图理解调用流程然后模仿开发新功能。
要小心挑选运行时分析工具。信息过多是这类工具的主要问题。选择一些提供简单过滤无效信息并能够方便的查看各种视图的工具。
2 迅速发现需要变更内容的工具
若单元测试有效，可以通过运行单元测试发现变更有没有破坏其他测试用例。有效维护并且覆盖大型企业应用的单元测试还是比较少的。下面有一些针对该情况的工具。
仍然是有两种技术静态代码分析和运行时分析可以使用。市场中有很多静态代码分析工具可用。如：Lattix， Structure101, Coverity， nWire and IntelliJ's DSM。
给定一个变更后的类，上述工具均可识别对该类存在依赖的类的集合。开发者需要根据这些信息“猜测”可能产生影响的用例，因为这些工具无法展示运行时类之间的调用关系。
市场上的可以用于运行时影响分析的工具并不多，除了 MaintainJ。MaintainJ 先捕获在一个用例中调用的所有类和方法。当所有用例的上述信息都被捕获之后，就很容易发现类的变更对用例的影响。MaintainJ 能够有效工作的前置条件就是项目的所有用例都应当先运行一遍，以便能够获得运行时的依赖关系。
总之，目前你在迅速准确分析变更影响方面，还是可以从工具中获得有限的帮助。首先根据需要实施一些影响分析，然后根据自己或小组其他高级成员评审来判断变更的影响。你可能需要上面提到的工具对你的判断进行反复确认。
6.2 维护文档
把生成API文档作为构建过程的一部分。不同语言下有不同的工具，比如Java内置了javadoc，python则可以考虑Sphinx。生成所得的html文档，打包成压缩包，保存起来。
搭建一个用作文档浏览的web服务器，把各个项目的文档压缩包，按项目+版本，直接解压放到文件系统上，就可以对外提供浏览。这就是 Home | Read the Docs 在做的事了。不过，只要生成的文档是html格式，我们并不需要局限在python项目。
API文档只是需要被高效维护的文档之一。项目中还有其他形式的文档，同样需要被维护。文档就别用word来写了，可以考虑引入Sphinx、gitbook一类的工具，然后用markdown/rst之类的手段来编写文档。这样的文档，可以像代码一样被存放到scm中，便于追踪和协作编写。也可以像API文档那样，在构建时生成，然后送到存放文档的web服务器上。
6.3 功能拓展方法
1.可以增加评论和评价的功能，当一个项目完成时，参与者可以对此项目进行评价，包括项目的真实性，有效性，体验性进行评价，评价可以按5颗星进行，星越高越好，项目发起人的信誉就会更好，一个人的信誉越好系统就会优先推广他发起的项目。
2.可以增加分享的功能包括微博，微信，qq，朋友圈，qq空间等。
