微信小程序-日历-地图-天气-记事本-便利贴-互助论坛-成绩查询-java后端-myql数据库
最近花大时间做完了自己的毕业设计,因为工作量的关系,把功能做的很全。
emmmm 想要学习的可以去我的资源里面找,也可以联系我ID。
大致情况如下
微信小程序-日历-地图-天气-记事本-便利贴-互助论坛-成绩查询-java后端-myql数据库
目 录
1.1 研究的目的和意义
1.1.1 研究目的
智能手机的普及和移动互联网的繁荣发展的背景下,一起促成了今天APP产品在应用市场数量众多,且经常需要更新,这就带来了一些不方便,这些应用需要经常性的更新和卸载。APP卸载垃圾导致手机内存不够,经常的安装卸载使得手机卡顿[1]。传统手机APP的确在工作和生活中帮助了用户,但多数传统手机APP功能过多,占用内存大,而其中只有小部分功能会被用户经常使用,这就造成了资源的浪费。小程序是一种应用,有别于传统应用它运行在微信上不需要单独下载安装就可使用的。为了方便学生们更好的了解校园、查询成绩、获取帮助而设计这个校园帮小程序,使得学生们在使用小程序的时候就和以前使用传统APP一样方便、简洁、且同样高效。校园帮小程序可以提高滨州学院对于学生们服务质量,提高学校口碑,对于学校的品牌打造具有好的影响,使得在学校的推广上,有一定的推动作用。
1.1.2 研究意义
微信小程序作为一种轻型应用,它非常有可能会是未来移动互联网应用中的主要形式,它的主要特点是小而且快,它主要还是用来解决小应用的问题,重点在于灵活性、快捷性而且用完即走[2]。
目前在数字化校园的建设主要集中在PC端,学校宣传先前只是通过官网,学生们查询信息都是在官网查询,后来出现了微信公众号,但公众号可实现功能较少,在移动端建设的规划和投入方面略显不足,所以重视数字化校园的移动端建设是很有必要的[4]。
校园帮小程序具有多种常用功能,而且可以实现学校信息的查询,使得学生们可以更加方便的使用手机来做到类似学校信息系统的一些功能,方便快捷。校园帮小程序符合了学校的发展理念,弥补了我校在移动端建设上的不足,在一定程度上,校园帮小程序在数字化校园移动端的建设上具有一定开拓意义。
1.2 国内外研究现状
随着微信的不断成长和扩大,微信的用户基数达到了9亿人次,并且现在每一天每一人花费在微信上的时间也长,大约占了其他所有手机程序的30%以上,由于其庞大用户群体以及生态链条,微信成了商家抢占流量入口的必争之地[5]。小程序在这个基础上流量大而且入口多外加功能简单便捷。小程序功能得到了快速的更新和升级,这让微信小程序成了移动互联网时代背景下的下一个风口,可以给企业带来无限的可能。现在各行业内许多企业与单位都把小程序开发列上了日程,并且提前开通了小程序功能[6]。
就现在来说,小程序能够实现消息通知、线下扫码、公众号关联等等七大功能,其中,值得主要关注的是通过公众号的关联,用户们可以实现公众号与小程序之间相互跳转,由于跳转对用户是封装的,用户就感觉不到自己一直切换应用软件,由于小程序不存在入口,所以这种跳转优化用户使用体验 ,于此同时,更加方便小程序的使用者向品牌粉丝之间转化[7]。
在国外也有小程序的案例,如IDS大眼睛团队在没有技术背景下,仅通过第三方支持,就推出了IDS大眼睛社区,“IDS大眼睛社区”是给消费者纯分享消费经验而设定的,而另外两个小程序则是国内小众精品和海淘精品的电商。每日平均商品交易量超过100万.
IDS大眼睛的创始人于小戈说:她原来做订阅号的时候,都是把广告插入微商场,这样用户打开商品界面的几率就是1%,更别说是有购买转换率了,而通过小程序,会有26%的机会看到商品,从而转化率也会相对提高。
目前,学生信息查询与日常生活辅助工具欠缺,学生信息查询主要依靠PC端进行查询,一些日常生活应用也大多通过手机APP完成,没有相结合的便利性工具,本次设计主要是基于微信小程序的校园帮的开发,就是结合信息查询与日常生活辅助的系统的移动端建设,与以往的信息查询相比,校园帮限制小,不用PC端,又免于日常应用的下载。
1.3 课题研究的切入点
相对于PC端学校官网的教务系统,学生们更希望放弃笨重的电脑,使用更轻便的移动设备查询。
虽然学校已上线的信息系统在手机上也可以通过浏览器访问, 获取相应的服务和功能。但是, 毕竟手机和个人电脑有较大的不同, 如果让学生在手机上操作根据电脑设计的系统, 增加了使用难度。
为了方便学生们更好的了解校园、查询成绩、获取帮助,微信小程序是运行在微信应用的服务小程序,使学生们查询不受时间与空间的限制,符合学生的操作习惯。使得学生使用小程序更加方便、简洁。
第二章 系统分析
2.1 系统可行性分析
程序可行性研究主要是在软件开发过程中分析所需要的资金和软硬件配备以及所掌握的技术层次方面等条件来判断当前项目是否可以进行开发工作[9]。
2.1.1 经济可行性
2.1.2 软件和硬件条件
目前来说软件和硬件市场中各种开发软件一应俱全,功能也是非常丰富,小程序接口众多,且开发者工具不断更新,性能相当优异。小程序对硬件的性能要求较低,支持微信的手机都可以完美的运行的,这样可以对小程序的研发工作提供有力支持。因此,在软件与硬件方面来分析是可行的。
2.1.3 技术可行性
微信小程序开发需要用的WXML、WXSS以及WXS。WXSS+WXML+WXS,语法简单明了,与XML,CSS3以及JS有许多相通的地方,有一定前端基础入门快,而且微信内部API接口众多,使用方便,功能强大,使得脚本编程更加简单。小程序的样式表引用CSS3的伸缩盒子模型,页面布局更加方便。它可以充分展示小程序的前端界面、显示网页中的内容,是一种很灵活的技术。
微信小程序样式设计采用rpx来划分像素,使用户不论是ios系统还是Android系统,无论屏幕尺寸都可以完美适用,不需要根据不同手机来重新划分,使得样式设计更加方便简洁。因此,在技术可行性方面来分析是可行的。
2.2 需求分析
2.2.1 功能需求分析
(1)学生用户需求
①成绩查询:学生用户身边临时没有电脑时,需要查成绩,虽然可以借助移动端平台进行,但查询较麻烦,没有合适客户端可以使用;
②快递查询:查询快递需要在网页打开相应页面进行搜索,且好多浏览器不支持扫码搜索,需要记录快递单号,且下次查询需要重新进行输入操作,无记录;
③天气,日历,记事本等日常软件:需要安装众多软件,导致手机卡顿,而且现在APP广告消息众多,各种推送防不胜防,而且各个软件内容较分散。
(2)程序需求
①API接口:需要用到众多API接口,旧接口的替换需要及时更新;
②域名:域名租用后需要对域名进行备案后才能使用;
③服务器:租用服务器后需要对服务器安装部署SSL证书,安装HTTPS协议;
2.2.2 非功能需求分析
(1)性能需求分析:
①简洁性:小程序的操作必须简洁明了、容易操作。
②稳定性:小程序的稳定性直接影响到它是不是一个完善的应用程序,因此,必须为该小程序提供稳定性的保障。
③可升级性:以后随着学生用户的不断增多,为了保障小程序的运行效率,需要对代码的合理性以及服务器的处理性能进行加强,对服务器的容量进行增加,来对小程序的功能提供保障。
④可扩展性:当新技术可以应用时,可以用新技术对已经实现的功能进行更新和在系统原有的功能基础之上进行扩展,让系统效率得到优化。
⑤可维护性:就是小程序在运行过程中可能出现未知的错误,需要人员针对这些错误到小程序后台进行相关的调整和记录。合理的维护能够减轻一定的经济性负担,同时也可以延长小程序的使用寿命,而且目前API接口还在不断更新换代,新接口与旧接口的用法改变,需要维护人员去更新。
(2)运行环境:
本小程序是一个小程序快速启用模板的小程序,使用微信专用的微信开发者共同来开发,开发工具具有模拟器、编译器、调试器三个主要功能模块,三者相结合,使得小程序的编程开发更加便捷。
- 硬件平台:
CPU:酷睿i3 -2.5GHZ
内存:2G以上
硬盘:16GB
- 软件平台:
操作系统:Windows 10
开发工具:微信开发者工具
(3)相关技术介绍:
开发语言:本小程序使用的微信小程序开发自主的开发语言—WXSS+WXML+WXS,语法简单明了,与XML,CSS3以及JS有许多相通的地方,有一定前端基础入门快,而且微信内部API接口众多,使用方便,功能强大,使得脚本编程更加简单。小程序的样式表引用CSS3的伸缩盒子模型,页面布局更加方便。它可以充分展示小程序的前端界面、显示网页中的内容,是一种很灵活的技术。
第三章 系统总体设计
3.1 系统项目结构
通过小程序接口,创建的应用程序实例对象APP Instance相当于工作台,它可以实现所有应用之间的呈现,页面与页面之间的转换,页面之间包括 .JS、.JSON、.WXML、.WXSS,四个项目文件。抽象的公共编码放于公共文本Utils内
图3.1小程序架构设计图
3.2 系统架构图
小程序从主页面开始主要分两个方面,一个是日常应用,主要包括天气,地图,日历,备忘录模块,备忘录模块包括记事本跟记事贴功能。另一方面是学生学校生活常用工具,主要包括成绩查询跟学校展示,成绩查询主要包括英语四六级查询,计算机层级考试成绩查询以及一些证书考试查询。框架图如图3.2。
图3.2系统架构图
3.3 数据库设计
3.3.2 数据库实体
在进行概念模式设计中可以根据需求画出实体图,考虑数据库的设计是否与用户需求相符合,一般采用E-R模型法进行设计。
通过对上述数据库需求的分析,我们可以通过以E-R图的方式展现出来。
实体 属性 实体间关系
(1)用户信息实体E-R图如图3.3.1所示:
user |
View |
comment |
回复 |
发布 |
发布 |
N |
1 |
1 |
N |
1 |
N |
View_id |
Content
|
Photo
|
Create_time
|
name |
School
|
User_id
|
Content
|
Time
|
View_id
|
图 3.3.1用户信息实体图
3.3.2数据库表
系统主要表的设计结果如下:
列名 |
数据类型 |
长度 |
是否可空 |
注释 |
userId |
int |
11 |
否 |
编号 |
userName |
varchar |
450 |
是 |
用户名 |
School |
Varchar |
450 |
是 |
学校 |
Name |
Varchar |
450 |
是 |
姓名 |
3.3.2-1 user 用户信息表
列名 |
数据类型 |
长度 |
是否可空 |
注释 |
user_id |
int |
11 |
否 |
用户编号 |
classify |
varchar |
450 |
是 |
类别名称 |
content |
varchar |
3000 |
是 |
内容 |
Create_time |
varchar |
450 |
是 |
创建时间 |
update_time |
varchar |
450 |
是 |
修改时间 |
View_id |
int |
11 |
是 |
求助编号 |
3.3.2-2 view 求助信息表
列名 |
数据类型 |
长度 |
是否可空 |
注释 |
user_id |
int |
11 |
否 |
用户编号 |
View_id |
Int |
11 |
否 |
求助编号 |
Content |
text |
|
是 |
内容 |
Create_time |
varchar |
450 |
是 |
创建时间 |
update_time |
varchar |
450 |
是 |
修改时间 |
3.3.2-3 comment 评论信息表
列名 |
数据类型 |
长度 |
是否可空 |
注释 |
View_id |
int |
11 |
否 |
求助编号 |
url |
varchar |
450 |
是 |
图片路径 |
3.3.2-1 photo 图片信息表