说明书修改
需求规格说明书Github链接
不足之处
1、最终软件版本的需求考虑还不完善，用户模块成了一个没有实际功能的毫无意义的模块，因此我们增加了对用户模块的基本功能需求，拟实现日程的云同步功能，使得用户可以在不同设备对日程进行查看。
2、针对第一点的改动，修改了类图以及原型界面等。
3、原稿中存在图片尺寸不合适，同类图片尺寸不一致等情况，生成的文档十分不便于阅读，我们调整了统一的图片尺寸，并把用例图等图片的过大尺寸放小，使得文档更便于阅读。
代码规范
命名规范
控件缩写局部变量命名{范围描述+}意义描述+类型描述 的组合，用驼峰式，首字母小写。
例子：
private TextView headerTitleText; // 标题栏的标题 private Button loginBtn; // 登录按钮
静态变量命名
全部为大写单词，单词之间用下划线分开。
例子：
public final static int PAGE_SIZE=20;
类成员变量命名
{范围描述+}意义描述+类型描述的组合，用驼峰式。
private TextView HeaderTitleText; // 标题栏的标题 private Button LoginBtn; // 登录按钮
类命名
使用大驼峰规则，用名词或名词词组命名，每个单词的首字母大写。 以下为几种常用类的命名：
activity 类，命名以 Activity 为后缀，如：LoginActivity，放在根目录下。
fragment 类，命名以 Fragment 为后缀，如：DialogFragment，放在 fragment文件夹下。
service 类，命名以 Service 为后缀，如：DownloadService，放在 service 文件夹下。
adapter 类，命名以 Adapter 为后缀，如：CouponListAdapter，放在 adapter 文件夹下。
canvas 类，命名以 canvas 为后缀，如 StepCanvas，放在 Canvas 文件夹下。
painter 类，命名以 Painter 为后缀，如 ShapePainter，放在 Painter 文件夹下。
基础类，命名以 base 为后缀，如 CanvasBase，放在 Base 文件夹下。
通用类，如简单的自定义控件、辅助类，放在 common 文件夹下。
方法命名
使用小驼峰规则，用动词命名，第一个单词的首字母小写，其他单词的首字母大写。
以下为几种常用方法的命名：
初始化方法，命名以 init 开头，例：initView()。
按钮点击方法，命名以 on 开头，Click 结尾，例：onLoginClick()。
设置方法，命名以 set 开头，例：setData()。
具有返回值的获取方法，命名以 get 开头，例：getData()。
通过异步加载数据的方法，命名以 load 开头，例：loadData()。
布尔型的判断方法，命名以 is 或 has，例：isEmpty()
layout 命名
组件类型_{范围_}功能，范围可选，以下为几种常用的组件类型命名：
activity_{范围_}功能，为 Activity 的命名格式。
fragment_{范围_}功能，为 Fragment 的命名格式。
dialog_{范围_}功能，为 Dialog 的命名格式。
item_list_{范围_}功能，为 ListView 的 item 命名格式。
item_grid_{范围_}功能，为 GridView 的 item 命名格式。
header_list_{范围_}功能，为 ListView 的 HeaderView 命名格式。
footer_list_{范围_}功能，为 ListView 的 FooterView 命名格式
书写规范
括号花括号不要单独一行，和它前面的代码同一行。而且，花括号与前面的代码之间用一个空格隔开。
public void method() {}
空格
if、else、for、switch、while等逻辑关键字与后面的语句留一个空格隔开。
if(boolVar) {} else {}
运算符两边各用一个空格隔开。
int c = a + b;
方法的每个参数之间用一个空格隔开。
public void method(String param1, String param2);method(param1, param2)
缩进统一使用4个空格，因为不同编辑器对tab显示不同。
空行
空行之空一行，不要多空行。在一下情况需要用一个空行：
1、两个方法之间
2、方法内的两个逻辑段之间
3、方法内的局部变量和方法的第一条逻辑语句之间。
4、常量与变量之间
其他
1、应用中的字符串同一在strings.xml中定义，然后在代码和布局文件中引用。
2、一行声明一个变量，不要一行声明多个变量，这样有利于注释。
private String param1;private String param2;
3、当一个表达式无法容纳在一行内时，可换行显示，另起的新行用八个空格缩进。
someMethod(longExpression1, longExpression2longExpression3,longExpression4)
注释规范
文件头注释文件顶部统一添加版权声明，声明格式如下：
/*** /10/16* Copyright (c) Jun yu Inc. All rights reserved*/
类和接口的注释
类和接口统一添加注释，格式如下：
/***类或接口的描述信息*/
方法注释
方法同一添加注释，说明用途，参数说明和返回值说明。
/***登录**@param loginName 登录名*@param password 密码*/
变量与常量注释
下面几种情况的变量和常量，都要添加注释，有限采用右侧//来注释，若注释太长则在上方添加注释。
1、接口中定义的所有常量
2、公有类的公有常量
3、枚举类定义的所有枚举常量
4、实体类的所有属性变量
public static final int TYPE_CASH = 1; //现金券public static final int TYPE_DEBIT = 2; //折扣券private int id; //券idprivate String name//券名称
总结
制定代码规范“看似表面文章，实则非常重要”，合理的代码规范有助于团队开发过程有更高的效率，因此我们遵循简明，易读，无二义性的原则制定了我们团队的代码规范，主要体现在:
1、变量名和方法名用小驼峰规则，一眼就能看出它的作用，简洁明了。
2、括号和运算符加空格，整体代码看起来更工整舒服。
3、注释采用javadoc注释格式，能让其他人快速看懂方法和接口的作用，增强了代码的可读性，使代码改写和维护更加方便。
数据库ER图
解释：
ActivityTime:活动时间
Activity:活动内容
Clock:闹钟（提醒时间）
ActivityClass:活动类型
ActivityTitle:活动标题
PhoneNum:手机号
Id:日程编号
UserName:用户名
PhoneNum:手机号
PassWord：密码
QQ：qq号
WeiBo:微博号
Picture：头像
后端架构设计
主要功能描述
在Android开发中，Activity并不是一个标准的MVC模式中的Controller，它 的首要职责是加载应用的布局和初始化用户界面，并接受并处理来自用户的操作请求，进而作出响应。随着界面及其逻辑的复杂度不断提升，Activity类的 职责不断增加，以致变得庞大臃肿。当我们将其中复杂的逻辑处理移至另外的一个类（Presneter）中时，Activity其实就是MVP模式中 View，它负责UI元素的初始化，建立UI元素与Presenter的关联（Listener之类），同时自己也会处理一些简单的逻辑（复杂的逻辑交由 Presenter处理）。
View不直接与Model交互，而是通过与Presenter交互来与Model间接交互，Presenter与View的交互是通过接口来进行的，更有利于添加单元测试，通常View与Presenter是一对一的，但复杂的View可能绑定多个Presenter来处理逻辑。
1.用户登录注册
2.手动添加日程事件
3.语音识别添加日程事件
4.图像识别提取日程信息
5.完善和修改用户信息
MVP框架
模型（Model）：数据层为UI层提供的数据，或者保存UI层传下来的数据负责对数据的存取操作，比如存储、检索、操纵数据。
视图（View）：显示数据（model）并且将用户指令（events）传送到presenter以便作用于那些数据的一个接口。负责绘制UI元素、与用户进行交互(在Android中体现为Activity)View，通常含有Presenter的引用。
Presenter:作为View与Model交互的中间纽带，处理与用户交互的负责逻辑。View与Model并不直接交互，而是通过与Presenter交互来与Model间接交互。Presenter层会从Model层获得所需要的数据，进行一些适当的处理后交由View层进行显示。这样通过Presenter将View与Model进行隔离，使得View和Model之间不存在耦合，同时也将业务逻辑从View中抽离。
选用该框架的原因有如下几点：
1.模型与视图完全分离，我们可以修改视图而不影响模型。分离了视图逻辑和业务逻辑，降低了，耦合。
2.所有的交互都发生在一个地方——Presenter内部，高效地使用模型。
3.Presenter 被抽象成接口，可以有多种具体的实现，所以方便进行单元测试
4.Activity 代码变得更加简洁
数据库模型
文件目录模型
分而治之
Alpha版本WBS图
Issues任务认领结果
TODO List
102：好记整体框架绘制
513：用户基本界面绘制+用户基本功能实现
427：用户基本界面绘制+用户基本功能实现
124：用户基本界面绘制+用户基本功能实现
538：后台数据库搭建
118：日程表单日显示界面绘制
529：日程表多日自由定制显示
500：文本日程输入
燃尽图
分工比例
叶文滔：
李嘉群：
张岳：
俞鋆：
刘晓：
黄梅玲：
王国超：
林炜鸿：
