/Moss

Project prepared for Course named SoftwareEnginnering

Primary LanguageCSS

Moss

Project prepared for Course named SoftwareEnginnering

一个完整的APP架构设计

需要经过

需求分析 -> 功能分析 -> 用户流程分析 -> 非功能需求分析 -> 架构层次分析

-> UI设计 -> 数据库设计 -> 模块设计

Goal

我们的目标是做一个基于聊天机器人的备忘录的软件应用。 特色点在于机器人的聊天风格是恋爱风格，吸引15-30岁的年轻目标用户对象。

产品定义

本团队经调研后针对15-30岁的年轻用户，打造一款陪伴风聊天互动式的移动端（安卓）备忘录力求以趣味性聊天对话回复，协助用户进行时间管理

备忘录意指任何一种能够帮助记忆,简单说明主题与相关事件的图片、文字或语音资料。 聊天机器人是经由对话或文字进行交谈的计算机程序。能够用于产生日常对话，模拟用户在生活中的社交关系联结。

在恋爱类风格应用中，恋爱的本质为“白日梦”。“白日梦”具有社会表演的虚幻叙事特质，其源于玩家对虚拟理想自我的建构需求、对理想恋爱对象的期待和现实生活中对话逻辑的渗透与传播。

创意来源

趣味记账软件（例如叨叨记账）

恋爱类游戏（例如恋与制作人）

背景调研

市场综述（分析实用性）

1.有实际存在的一群消费者 —— 备忘录为手机基础应用，受众广泛，需求强烈。

2.这群客户有明确的需求 —— 因为人类的记忆力有限，对备忘录有刚性需求。

3.是否有一系列产品来满足需求 ——

现在的备忘录软件主要分为两类：

  • 系统自带，简约但基本不具备提醒功能。

  • 市面上大部分app，主要是记录待做事项、重要事件的时间、日程安排等，且获得手机授权后，具有一定的提醒功能

但是缺少趣味性、且主要靠使用者自己整理。

4.在决策购买时，市场中消费者相互参考 —— 对日常生活工具类应用易产生使用依赖，通过趣味性进行产品营销传播。

竞争对手分析

目前聊天机器人广泛运用于即时通讯平台，例如脸书 Messenger，WeChat，LINE和 Kik，以娱乐、零售行销、以及客服为目的。此外，即时通讯平台提供易于整合的webhook，使得第三方开发商易于可通用于不同通讯平台之聊天机器人。这些软件机器人以客服的身份出现或是成为团体聊天的一员。

目前Siri等手机语音助手可以通过聊天功能完成日常事务的记录与提醒，但是对话过程较为枯燥乏味，且无法完成在聊天机器人中删除备忘录的功能。

在日常工具类应用中，很少有使用趣味聊天机器人为主要交互类型的应用。本应用正是为了填补这一空白市场而提出的。

核心功能需求分析

核心功能

  • 用户管理

    实现用户的注册、用户登录退出、忘记密码、找回密码等功能

    **Tips：**本地和远程备份相协调。（备忘等事件储存在本地，用户可以选择是否云端备份，用户名密码信息存在云端）

  • 用户聊天对象设置

    设置聊天对象的头像，称呼，姓名等。用户自定义聊天界面的背景。

    **Tips：**前期可以是简单的机械式回答，后期可以做成复杂的语料库来丰富聊天内容的匹配程度，增加趣味性。

  • 备忘事件功能

    基本的备忘录功能。即创建备忘（设定备忘时间，是否提醒，是否每天提醒，备忘标题和备忘内容等），编辑备忘，删除备忘，标记完成备忘

    **Tips：**被标记为完成的备忘在程序内保留一定时间（例24h）后删除。创建备忘的必选项为备忘标题，其余皆有默认值。

  • 打卡事件功能

    基本的打卡事件功能。包括打卡事件的创建（打卡事件标题，开始及结束日期，打卡周期（每天，每三天，每周等）），打卡事件的编辑，删除和标记完成。以及打卡事件的标记打卡。

    **Tips：**主要功能和备忘录功能相似。打卡事件的有总体完成和每周期完成的区分。备忘录和打卡时间的创建可作为相同弹窗不同标签页

  • 聊天交互功能

    聊天界面应该包含的接口有，备忘录和打卡事件的创建接口，打卡的每周期完成标记，和备忘以及打卡事件的完成接口以及所有接口相应的聊天内容创建和反馈。

    **Tips：**这个页面可以作为首页呈现。

  • 事件管理功能

    展示所有的备忘事件和打卡事件（包含打卡事件当前进度（已创建多久和打卡完成情况）），以及筛选功能（展示特定时间，或特定类型（备忘or打卡）的时间）

  • 提醒功能

    对于用户标记的需要提醒的备忘和设定周期的打卡，用应用提醒的方式提醒，或者发送邮件，发送短信的方式强行提醒。

    **Tips：**后期可以实现，生成当日事件的图片（可以作为锁屏壁纸的那种）

  • 日历式展示功能

    日历界面展示所有事件。

  • 适配

    包含设备本身适配，不同安卓系统的适配（深度定制化安卓系统太多了），以及手机端和WEB端的适配

非功能性需求分析

可用性

充分测试，出错处理并充分考虑程序崩溃无响应的出口，界面逻辑清晰，操作方便友好等等

兼容与性能

上一节适配中也提到了，兼容就是适配，然后在性能要肯定要运行流畅，不会出现闪退、ANR（？？）、内存泄漏（buffer overflow）等问题，主要体现在数据流、图片缓存、列表优化、数据库操作等等方面。

开发配置

预设应用场景：2000用户，可承受100-200并发访问不卡顿

  • 服务端：Android端，Web端可构造网页进行导流，然后后台管理界面就写成web端

  • 服务器：基本是文本传输，因为目前还不涉及云同步问题，只有Android端，只是涉及更新语料库问题，100-200并发访问量下，压力比较小。

    4核8G 5M带宽已经是高配了，

    当然后面还有更多技术，如果真做大的话，什么集群，负载均衡，异地缓存什么的

  • 数据库：暂定Mysql Community Server 充分学习优化技术 必要时可以考虑升级 Mysql Enterprise Server

    连接池技术，最大连接数

  • 短信服务：阿里云短信服务SMS，用以发送验证码，短信收费，一定是必要验证时发送

  • 身份认证：需要一定的计算性能，但是4核应该能Cover这个认证又不是并发的

程序总体设计

架构层次分析

界面层：

  • 登录

  • 注册

  • 聊天界面

    • 聊天主界面
    • 所有类型备忘录预览
    • 打卡快速写入界面
    • 普通备忘录书写界面

  • 我的Moss

    • 个人信息界面

    • 设置界面

    • 分享界面

  • 总览

    • 日历界面
    • 查看所有备忘录界面
    • 专门打卡界面

接口层：

  • 接口层封装了服务器提供的API，定义一个请求引擎类，对请求的发送响应结果进行处理，方便给核心层调用。
  • 搜索 用关键词找到商家
  • 首页信息 要么抓取，要么自己自动生成新闻（这就涉及到机器学习的技术了，但是很明显我们的机器是跑不成机器学习任务的，算力不够，做实验可以

数据模型/处理层 ：

  • 根据不同板块的需求，存取数据

数据库设计

  • 用户列表

    users_list
(
    userID(PK),//唯一标识，系统自动生成
    username(FK) REFERENCES users(username)//username 可以是邮箱或者手机号码
)

  • 用户信息表

    users
(
    username(PK),
    vipID(FK) REFERENCES vip(vipID)
    sex,
    nickName,
    phone,
    email,
    registerDate,
    lastLoginDate,
    lastLoginDevice,
    lastLoginLocation,//安全保护
    QRcode //要内嵌分享按钮 或者二维码生成程序
    
)

  • 登录表

    account
(
    username(PK),
    type,       //common users or DBM or Admin
    password   //extremely important 传输加密
)

  • 会员表

    vip
(
	vipID(PK),//暂定，其实这个版本用不到
	vipStartTime,
	vipEndTime,
	vipRestTime,
	vipScore,
	vipDiscount,
	vipLevel,
	autoRenew,
)

  • 备忘录列表

    memorandumList
(
	memorandumID(PK),//全局检索id
	Headline，//标题
	username,
	Content,//限制300字
	date	
)

  • 提醒表

    reminder(
	reminderID(PK),
	Headline,
	Type,
	username,
	content,
	Remind,//boolean True/False
	Time,//几点
	Date,//特定日期
	Status //是否已打卡
	
)

  • 打卡

    clockin(
	clockID(PK),
	username,
	content,
	location,
	date
)

  • 用户-语料库表

    corpusUser
(
	Id(PK),//全局检索id
	username(FK),
	corpusId(FK),指定类型语料
	name，//聊天角色名 可由用户自己定义
	iconURL,//用户自行上传图片作头像	
)

  • 语料表

    corpus(
dataId(PK)//全局检索id
corpusId,
type,//image or text
situation,
originname,//
imageURL,
)

SQLite 数据库设计

设计一个聊天记录cache表

时序图

时序图描述了对象之间消息发送的先后顺序，主要用途是把用例表达的需求，转换为进一步、更加正式层次的精细表达。

注册登录时序图

“尛事”的注册登陆功能的实现，需要调用接口后引入数据库。在登陆已有用户的情况下，系统会自动跳转到登陆后的首页；而新用户则需要进行注册，然后跳转到登陆界面进行操作。

聊天时序图

“尛事”的聊天功能，借助自带的语料库，在进行添加备忘录、添加打卡等操作之后，自动调用对应的接口，从语料库中选择合适的语句，机器人自动回复，同时在数据库中对数据进行修改，从而实现用户与app的可持续交流。

UI设计

进度管理

日期 规划进度
3.17-3.23 第一阶段，需求阶段，该阶段任务已圆满完成。 1.产品上，对产品 APP 整体功能体系进行再次规划。 参见本策划书项目产品模块，着重在产品重定义。 2.研发上，对整个软件架构规划进一步明晰，明确学习任务及分工，多线程并行。 参见完整架构设计板块。
3.24-3.30 第二阶段，编码筹备阶段，该阶段任务接近完成。 1.储备学习Android相关技术，整理安卓技术学习笔记。 2.做完Android的所有UI设计工作 2.开始编写Web官网
3.31-4.6 第三阶段，研发阶段，该阶段任务尚未全部完成 1.根据已有的需求分析，完成应用的UI界面。 2.设计数据库模型，规划数据处理方式。 3.确立后台框架，初步搭建并整合。
4.7-4.13 第三阶段，研发阶段，1.按需求完成各个功能的迭代开发，测试。
日期 完成情况
3.17-3.23 第一阶段，需求阶段，该阶段任务已圆满完成。
3.24-3.30 第二阶段，编码筹备阶段，该阶段任务已圆满完成。
3.31-4.6 第三阶段，研发阶段，该阶段任务尚未全部完成
4.7-4.13 第三阶段，研发阶段，语料库素材还不完备，尚未导入数据库；服务器端，只写好了登录注册等用户模块的接口，安卓端界面搭建还没有开始。