大学生兼职APP“兼并兼”软件设计
(由团队负责该模块成员完成)
对于具体如何写软件设计小组成员都没有经验,以下是在查询资料及参考有关资料后得出的结果。
一、用户界面设计
用户界面:又称人机界面,实现用户与计算机之间的通信,以控制计算机或进行用户与计算机之间的数据传送的系统部件。
GUI:即图形用户界面,一种可视化的用户界面,它使用图形界面代替正文界面。
我们APP将使用图形用户界面(GUI)与用户进行交互,做到用户接触软件后对界面上对应的功能一目了然,不需要很长的适应时间就可以熟练使用APP。
1.界面设计介绍
(1)软件启动封面设计
作为一个软件给用户的第一印象,软件的启动封面需要将一些有关APP的重点信息传递给用户。所以启动封面上需要在醒目的位置上设计软件的logo以及软件名称。除此以外,启动封面上应该醒目地标注制作或支持的公司标志、版本号、版权声明、序列号等信息,这样可以方便用户获得有关软件的一些信息。
(2)软件使用界面设计
软件的使用界面作为用户使用APP最经常接触的界面需要做到简介明快,不使用过多花哨的设计,这样用户在有需求时可以最快的找到相对应的功能。其次应考虑屏幕的空间布局,做到尽量节省屏幕空间,并需要在设计初期为将来可能需要加上的按钮、菜单、标签等控件预留位置。总体设计应符合用户使用需要和视觉流程。类似下面的图片(APP原型界面):
(3)软件按钮设计
软件的按钮应该具有良好的交互性,即至少拥有3种状态,正常状态、悬浮状态(例如鼠标悬浮在控件上)、点击状态,具体状态数目需要根据按钮功能决定。按钮的图示应简洁明了,使用户一眼就了解按钮具备的功能。所有的按钮设计应具备相同风格,避免风格差异给用户带来不好的体验。
(4)软件搜索框设计
软件搜索框应位于软件顶部并尽量占用较少的屏幕空间,方便用户使用搜索功能,当用户点击框内区域时能弹出键盘方便用户输入。
(5)软件色彩设计
软件色彩应避免使用过于强烈的颜色,以免用户使用一段时间产生眼部不适。软件的色彩设计大部分采用人眼看起来较为舒适,对眼部不会产生太大刺激的颜色。
(6)软件图标设计
软件图标应精美有新意,让用户第一眼就可以注意到我们的软件,产生想要使用的想法。
2.界面设计原则
(1)易使用
a.完成一系列操作的按钮或完成某一功能所需要的按钮应集中在一块区域,避免用户使用功能时大范围寻找按钮。
b.按功能将界面区域分块,并要有一定的说明和标题。
c.同一界面上的控件数不要太多,超出数量的控件可以采用分页显示。
d.选择选项少时使用选项框,反之使用下拉框。
(2)规范性
a.按钮的图标要能准确直观的表达所完成的操作
b.字体大小统一。
c.按钮等控件的与界面的比例要协调。
(3)界面一致性
a.所有显示的信息的字体、大小和风格等保持一致。
b.布局合理,不要过于密集也不要过于空旷。
(4)出错信息以及警告
a.用户执行非法操作产生错误给出错误提示。
b.用户所要执行操作可能产生错误时给出警告。
二、数据库设计
数据库是存储用户数据并对用户数据进行管理的主要工具,设计一个好的后台数据库也十分重要,根据之前的需求分析,小组中负责搭建数据库的成员给出了以下数据库设计。
数据字典:
表1-用户表
中文 | 列名 | 数据类型 | 主外健 | 描述 |
用户名 |
User_Number |
varchar(20) |
PK | 用户名为用户每次登录“兼并兼”APP时候是需要输入的必要信息,一个用户只能有一个用户名 |
密码 |
User_Password |
Varchar(20) |
NOT NULL | 每一个用户都有自己设定的密码,此密码为用户登录APP时需要输入的密码 |
姓名 | User_Name | Varchar(10) | NOT NULL | 用户的姓名,不一定唯一 |
电话号码 | User_Phone | Varchar(13) | NOT NULL | 每一个用户都有一个电话,并且约束为13位 |
性别 | User_Sex | Char(2) | NOT NULL | 用户的性别 |
用户学校 | User_School | Varcahr(20) | NOT NULL | 该大学生用户所属的学校 |
用户专业 | User_Major | Varchar(20) | NOT NULL | 该大学生用户主修的专业 |
兼职经历 | User_Experience | Char(4) | NOT NULL | 该用户需要写明是否有过兼职经历 |
兼职意愿 | User_aspiration
| Varchar(50) | NOT NULL | 该用户需要简单填写自己的求职意愿,工资需求 |
用户年级 | User_Grade | Char(4) | NOT NULL | 该大学生用户所属年级 |
用户邮箱 | User_Email | Varchar(20) | NOT NULL | 管理员的邮箱约束必须有标识符@ |
表2-管理员信息表
中文 | 列名 | 数据类型 | 主外健 | 描述 |
管理员工号 | Administrator_No | varchar(10) | PK | 管理员的工号作为系统管理员的主键 |
管理员姓名 | Administrator_Name | Varchar(10) | NOT NULL | 管理员的姓名,不一定唯一 |
性别 | Sex | Char(2) | NOT NULL | 每一个管理员都有一个性别 |
管理员电话 | Administrator_Phone | Varchar(13) | NOT NULL | 管理员都有一个电话,并且约束为13位 |
管理员工龄 | Administrator_Age | Int | NOT NULL | 表示该管理员工作的时长 |
管理员邮箱 | Administrator_Email | Varchar(20) | NOT NULL | 管理员的邮箱约束必须有标识符@ |
管理员负责的模块 | Administrator_Nature | Varchar(20) | NOT NULL | 管理员所负责的模块 |
表3-商家表
中文 | 列名 | 数据类型 | 主外健 | 描述 |
商家编号 | Store_No | varChar(8) | PK | 商家的编号作为商家表的主键 |
商家名称 | Store_name | varchar(20) | NOT NULL | 相应商家的具体的名称 |
商家地址 | Store_address | Varchar(20) | NOT NULL | 表明该商家的具体位置 |
商家联系电话 | Store_telephone | Varchar(11) | NOT NULL | 商家的联系电话 |
商家提供的职业的编号 | Store_no | Char(4) | NOT NULL | 商家所提供的职业编号 |
表4-职业信息表
中文 | 列名 | 数据类型 | 主外健 | 描述 |
职业编号 | Work_No | Char(4) | PK,FK | 职业的编号作为职业表的主键 |
职业提供的薪水 | Work_Money | Varchar(4) | NOT NULL | 表明该职业所提供的大致薪水 |
职业剩余数量 | Work_Number | Varchar(4) | NOT NULL | 表明该实验的剩余数量 |
商家编号 | Store_No | Char(4) | PK,FK | 商家所提供的职业编号 |
职业要求 | Work_Claim | Varchar(50) | NOT NULL | 职业的要求不能为空 |
表5-职业表
中文 | 列名 | 数据类型 | 主外健 | 描述 |
职业编号 | Work_No | Char(4) | PK | 职业的编号作为职业表的主键 |
职业名称 | Work_Name | Varchar(20) | NOT NULL | 相应职业的具体名称 |
表6-订单信息表
中文 | 列名 | 数据类型 | 主外健 | 描述 |
用户名 |
User_Number |
varchar(20) |
PK,FK | 用户名为用户每次登录“兼并兼”APP时候是需要输入的必要信息,一个用户只能有一个用户名 |
商家编号 | Store_No | Char(4) | PK,FK | 商家所提供的职业编号 |
订单时间 | Order_Date_Start | Datetime | NOT NULL | 显示求职学生向商家提交个人信息的时间 |
订单属性 | Order_Nature | VarChar(8) | NOT NULL | 在求职者没有提交信息或者提交信息后没有得到商家回复,订单属性显示为待审核。商家确认需要对该生进行面试,订单属性就会显示通过审核 |
订单编号 | Order_No | Varchar(8) | NOT NULL | 表示订单的具体编号,便于查询 |
订单确认时间 | Order_Date_End | Datetime | NOT NULL | 显示商家确认要面试该求职者的时间点 |
表7-不良用户信息表
中文 | 列名 | 数据类型 | 主外健 | 描述 |
用户名 |
User_Number |
varchar(20) |
FK | 用户名为用户每次登录“兼并兼”APP时候是需要输入的必要信息,一个用户只能有一个用户名 |
不良用户信息编号 | Bad_Information_User_No | Char(4) | PK | 若用户未参加面试,则会产生不良信息(商家确认) |
不良信息产生时间 | Bad_Information_User_Date | Datetime | NOT NULL | 显示不良信息产生的时间 |
表8-不良商家信息表
中文 | 列名 | 数据类型 | 主外健 | 描述 |
用户名 |
User_Store |
varchar(20) |
FK | 用户名为用户每次登录“兼并兼”APP时候是需要输入的必要信息,一个用户只能有一个用户名 |
不良商家信息编号 | Bad_Information_Store_No | Char(4) | PK | 若用商家未及时清算用户酬劳,则会产生不良信息(用户确认) |
不良信息产生时间 | Bad_Information_Store_Date | Datetime | NOT NULL | 显示不良信息产生的时间 |
E-R图:
三、接口设计
手机端接口设计(安卓)
用户接口:
游客:只能浏览各种招聘信息,无法对其评价和接受、发布招聘信息。
委托方、受托方:注册成功的用户可以发布和接受招聘信息、对个人信息的修改已经评价。注册方法通过手机短信进行认证。
在登入的时候需要进行验证码验证,可以通过手机验证码形式修改个人密码
管理员:通过默认的用户名和密码进行登入,可以进行修改。
当登入失败超过3次时,锁定该管理员,通过软件设计方进行解锁。
外部接口:
能过运行在安装该软件的安卓手机上。
内部接口:
系统内部分为:信息录入系统、用户管理系统、招聘信息管理系统。
业务分类处理系统又分为:注册登入、招聘信息处理、评价等子系统。
网页端接口设计
用户接口:
基本与手机端类似,不过网页端可以通过手机的二维码扫码进行登入。
外部接口:
能过运行在360浏览器、谷歌浏览器等主流浏览器。
内部接口:
与手机端类似。
四、编程规范
一个完整的项目不可能完全由一个人完成代码的编写,需要小组成员共同努力编写代码,这就意味着需要统一不同人的编程风格,所以就需要对编程进行规范。
(1)程序块采用缩进风格编写,缩进的空格数为4。
(2)代码注释一律接在代码后,注释后加空行。
(3)较长的语句分成多行。
(4)不允许多个短语写在同一行。
(5)程序块的分界符(如“{}”)独占一行,且对应的分界符号对齐,即处在同一列。
(6)对于某些编写较为复杂难理解的语句应当加上注释,但应注意代码中注释的比例,只对重点语句进行注释即可。
(7)函数头部应加上注释,解释该函数的作用参数等。
(8)对于某些变量、常量也应有一定的注释。
(9)变量的命名应注意规范,尽量使用有意义的名字,避免使用一些无规律的名字(如:a,b,c)
(10)变量的命名风格应一致,如尽量避免一会使用中文拼音,一会使用英文。
(11)代码编写完成后在小组内进行一遍完整的代码审查,小组成员对其他成员编写的代码进行交叉审查。