boss心血来潮想要做个股票预测系统，预测算法用python已经实现了，现在想做一个web平台可以访问并提供预测结果展现给用户。
NAME：GUS！
在需求方面，最主要从性能、功能、用户界面和运行环境等进行分析。
在架构方面，最主要从技术选型和模块视图等进行分析。
需求分析
需求分析的核心就是讲清楚用户的使用场景，最起码要包括以下四点：
1）系统使用人员角色
Ⅰ.系统管理员（负责给最终用户分配不同的权限，管理整个系统等）；Ⅱ.免费用户（拥有免费功能）；Ⅲ.付费用户（拥有高级功能）；
2）系统关键的使用场景
Ⅰ.注册用户（可选择普通用户/高级用户，高级用户旁有个标记，点击弹出悬浮窗口列出普通用户和高级用户的区别）;
Ⅱ.搜索股票（By代码/名称/拼音缩写）;
Ⅲ.显示股票预测方案（在搜索股票界面回车或单击Go！显示股票预测方案，次日涨跌情况、涨跌幅、涨停和不涨停的概率，有一个标记点击则将该股加入收藏夹，也可以拖拽）;
Ⅳ.历史记录（用户24小时/48小时/7天<<高级会员>>内预测过的股票，为侧标签栏，主窗体即Ⅲ不改变，收藏夹显示股票名称和股票代码，单击则在主窗体显示这只股票，主窗体<
Ⅴ.收藏夹（用户收藏的股票，普通会员10只股，高级会员无限制，为侧标签栏，主窗体即Ⅲ不改变，收藏夹显示股票名称和股票代码，单击则在主窗体显示这只股票，主窗体<
Ⅵ.反馈群体预测结果（在系统首页滚动<<当前有x人猜中y只股，正确率为z%>>）；
Ⅶ.反馈个人预测结果（在用户登录后界面显示一个浮窗，<
————————————————————————以下为option场景—————————————————————————
Ⅷ.Gus VS Your Guess（在搜索股票界面有一个小小的标记<>，点击弹出一个可调节也可输入的调整条，浮窗，浮窗上面写明<
Ⅸ.Gus VS Your Guess（当一个用户进行了对比预测实验后，在用户预测股票的界面有个小叹号标记，点开可以查看之前用户自己预测和Gus预测的结果对比，是一个弹窗，单击了后<
4）系统规模、性能要求
注重处理高并发访问的问题，MUST创建一个仿真测试系统来模拟上百万级的并发访问请求。
5）操作系统、部署方式
Ⅰ.满足PC端 和 安卓端 的自适应；
Ⅱ.B/S架构（安卓端考虑做成app）；
Ⅲ.与操作系统无关的平台，即部署服务器的操作系统可是Linux也可是Win;
Ⅳ.前后端分离，前端MAY部署到nginx，Web后端MAY部署到tomcat等，这样的好处是易于横向扩展；
Ⅴ.JDK1.6或以上；
Ⅵ.开发环境：前端webStorm,后台Eclipse,算法pycharm；
6）商业模式
前期：会员制，分为<<普通会员>> 和<< 高级会员>>；具体功能的区别在下文中用UML用例图表示；
后期：会员制+广告推广（option)；
功能设计
给出<<系统管理员>> ,<<普通会员>>，<<高级会员>>的UML用例图。
系统架构设计
技术选型及开发路线（想到再加）
前端：Vue.js+ElementUI
前端选择单页应用的模式，因为系统大部分界面会有许多重复部分，除了主窗体和侧边栏以外，大背景等基本不会产生变动，所以选择单页应用模式可以很好地节省资源。
后台：SSM(spring+springMVC+mybatis)
负载均衡：nginx
数据库：数据库选型参考文献
Ⅰ.百万级数据：mysql
Ⅱ.亿级数据：重OLTP则mysql
重OLAP则Hadoop（如果要一个分布式的MySQL，在Hadoop家族中有Impala）
对于股票预测分析的模块，是分析型数据库，以多维分析技术为基础，侧重OLAP。对数据进行多角度的模拟和归纳，从而得出数据中所包含的信息和知识。
对于用户信息及运行时产生的数据这一块，是面向前台应用的，应用比较简单，但是是重吞吐和高并发的OLTP类型。
【不可用MongoDB】：mongoDB在同样的数据量下，占用的空间多，而且消耗内存大，不可处理OLAP。
机器学习模块：python语言；
<
模块详细设计
1.登录界面
2.注册界面
在选择框如果选择高级会员则
3.登录后预测前界面
4.单击Go显示股票预测方案界面：
5.单击精灵球或者<>后的界面
6.单击历史记录
7.单击收藏夹
8.登出后，和登录界面一样（这里忘记画登出界面），应该在除了登录和注册界面以外做一个logout按钮。登录界面还缺一个忘记密码。