软件系统设计方案
一.项目概述运行环境和技术选型说明
本项目主要是模仿12306平台,进行订票系统的开发,客户端分为安卓端和iOS端,后端用的是go语言,其中最核心的功能是,车票查询,数据库检索,车票预定,退票,用户服务,等功能。而登录的用户分为两类,普通用户和管理员,普通用户是普通的订票用户,而管理员则承担服务用户的功能,以及对车票进行管理。
其中iOS端开发用的是xcode环境,语言为objective-c 用到foundation框架以及uikit框架.
二、系统架构
MVC的全名是Model View Controller,是模型(model)-视图(view)-控制器(controller)的缩写,是一种软件设计典范。它是用一种业务逻辑、数据与界面显示分离的方法来组织代码,将众多的业务逻辑聚集到一个部件里面,在需要改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑,达到减少编码的时间。
MVC开始是存在于桌面程序中的,M是指业务模型,V是指用户界面,C则是控制器。
使用的MVC的目的:在于将M和V的实现代码分离,从而使同一个程序可以使用不同的表现形式。比如Windows系统资源管理器文件夹内容的显示方式,下面两张图中左边为详细信息显示方式,右边为中等图标显示方式,文件的内容并没有改变,改变的是显示的方式。不管用户使用何种类型的显示方式,文件的内容并没有改变,达到M和V分离的目的。
在网页当中,V即View视图是指用户看到并与之交互的界面。比如由html元素组成的网页界面,或者软件的客户端界面。MVC的好处之一在于它能为应用程序处理很多不同的视图。在视图中其实没有真正的处理发生,它只是作为一种输出数据并允许用户操纵的方式。M即model模型是指模型表示业务规则。在MVC的三个部件中,模型拥有最多的处理任务。被模型返回的数据是中立的,模型与数据格式无关,这样一个模型能为多个视图提供数据,由于应用于模型的代码只需写一次就可以被多个视图重用,所以减少了代码的重复性。C即controller控制器是指控制器接受用户的输入并调用模型和视图去完成用户的需求,控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求,然后再确定用哪个视图来显示返回的数据。
接口举例
注册接口:
{ "username":"", "password":"" }
返回
{ "code":"", // 消息代码 "msg": "", // 消息 说明是否注册成功 "data":{} // 这里是无 }
查询车票
{ "startCity":"", // 城市名或站名 "endCity":"", "date":"", "type":"" // 0 全类, 1高铁动车票 }
订单
{ "username":"",//用户名 "token":"",//验证信息 "date":"",//发车日期 "train_number":"",//车次 "start_station":"",//上车站 "end_station":"",//下车站 "passengers":{//乘客数据 "passenger_seq":"",//乘客序号 "seat_class":"",//座位等级 "seat_type":""//座位类型 } }
三、软件系统概念原型视图
系统功能模块视图
项目部署视图
分解视图
软件用户用例图
工作分配视图
成员 | 分工 |
A | 后端编写,文档撰写,项目管理 |
B | 后端编写,文档撰写,接口对接 |
C | 测试,文档撰写,接口对接 |
D | 前端编写,文档撰写,页面设计 |
支付依赖视图
逻辑视图
订票执行视图
执行视图展示了系统运行时的时序结构特点,比如流程图、时序图等。执行视图中的每一个执行实体,一般称为组件,都是不同于其他组件的执行实体。如果有相同或相似的执行实体那么就把他们合并成一个。
执行实体可以最终分解到软件的基本元素和软件的基本结构,因而与软件代码具有比较直接的映射关系。在设计与实现过程中,我们一般将执行视图转换为伪代码之后,再进一步转换为实现代码。
因此,执行视图其实表现的是系统中间比较动态的那一部分。鉴于此,我们可以通过UML的流程图来表示执行视图:
四 项目实现视图
用户页视图
车站视图
主页视图
时间视图
项目架构
五 数据库设计
person表
属性名 | 类型 | 可否取空 | 注释 |
ID | string | 否 | 账号 |
name | string | 否 | 名字 |
是否学生 | bool | 否 | |
password | string | 否 | 密码 |
phone | string | 否 | 联系方式 |
学生表
属性名 | 类型 | 可否为空 | 注释 |
ID | string | 否 | 账号 |
学校 | string | 否 | |
学号 | string | 否 |
ticket表
属性名 | 类型 | 可否为空 | 注释 |
ID | string | 否 | 账号 |
车次 | string | 否 | 车次信息 |
时间 | string | 否 | |
价格 | string | 否 | |
座位 | string | 否 |
订单表
属性名 | 类型 | 可否为空 | 注释 |
ID | string | 否 | 订单ID |
personID | string | 否 | 用户ID |
ticketID | string | 否 | 票的ID |
是否付款 | bool | 否 | |
售后信息 | string | 否 |
管理员表
属性名 | 类型 | 可否为空 | 注释 |
ID | string | 否 | |
name | string | 否 | |
权限 | string | 否 | 管理员可进行的操作 |
六 系统概念原型的核心工作机制
每个视图都是从不同的角度对软件架构进行描述和建模,比如从功能的角度、从代码结构的角度、从运行时结构的角度、从目录文件的角度,或者从项目团队组织结构的角度。
软件架构代表了软件系统的整体设计结构,它应该是所有这些视图的集合。但我们不会将不同角度的这些视图整合起来,因为不便于阅读和更新。不过我们会有意识地将不同角度的视图之间的映射关系和重叠部分了然于胸,从而深刻理解软件架构内在的一致性和完整性,这就是系统概念原型。
基于以上各视图,我们就可以总结出此项目的概念原型,以下总结本系统的工作流程:
用户通过点击界面的订票按钮进入订票页面,查看出发地到目的地的车次和车票,可以进行时间段的排序和筛选,也可以重新输入地点进行中转,用户定好订单后可以再订单页面对订单进行查看还可以进行退票操作,订票退票查票都是数据库数据经过后端传递到客户端页面进行展示,用户动作也是通过客户端经过后端处理,将数据更新到数据库。