需求分析和概念原型

　　这学期的工程实践要做的是一个火车售票系统。这次借着软件工程老师的这次作业，对这个工程实践进行需求分析，采用用例建模，业务领域建模和数据建模的方式，形成概念原型。

1.系统功能的概述：

　　售票系统主要是通过游客在网上或者线下查询购买火车票等一系列的需求进行服务。而要在这些过程中要使得数据不出错，或者数据出错时能对一些数据进行修改和更新，需要有一个系统管理员在后台进行系统信息的更新和维护工作，否则的话系统可能随时会崩溃，会给用户带来很差的用户体验。

　　可以看出，在众多需求中，参与者有用户和系统管理员，而承载他们一系列操作的软件系统就是这个售票系统。而整个系统的功能主要有两个模块，一是用户对系统的操作，包括注册用户信息，登陆系统，查询车次信息，查询车票，购买查票，退票和改签等操作；二是管理员对该系统的信息进行更新和维护，包括增加用户信息，删除用户信息，修改用户信息，查找车票信息，更新车票信息，更新车次信息等操作。

 

2.需求建模（用例建模）

　　什么是用例？

　　用例的核心概念中首先它是一个业务过程，经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务的一系列活动就是业务过程。简单的说就是一个参与者要做什么，做了什么。

 　　如何进行用例建模？

　　第一步，从需求表述中找出用例，往往是动名词短语表示的抽象用例；

　　第二步，描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；

　　第三步，对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；

　　第四步，进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。

　　其中第一步到第三步是计划阶段，第四步是增量实现阶段。

　　根据项目进行用例建模

　　在火车购票系统中，提取用例可以看有哪些动名词。对于参与者是用户，用例有注册信息，查询车次信息，查询车票，购买车票，查看订单，退票，改签；对于参与者是系统管理员，用例有查找车次信息，更新车票信息，更新车次信息，统计数据，数据备份，数据恢复。

下面描述这些用例的高层用例：

参与者为用户	开始状态	终止状态
注册信息	用户点击注册开始填写信息	用户收到了注册成功或者失败的反馈
查询车次信息	用户开始输入查询条件	系统返回查询的信息
查询车票	用户开始输入查询条件	系统返回查询的信息
购买车票	用户查到了车票开始购买	用户收到了购票成功或者失败的反馈
退票	用户查看自己的订单开始退票	用户收到了退票成功或者失败的反馈
改签	用户查看自己的订单开始改签	用户收到了改签成功或者失败的反馈
查看订单	用户登录系统后开始查看订单	系统展示了订单页面

 

参与者为系统管理员	开始状态	结束状态
查找车票信息	管理员打开查找页面开始查找数据库中的车票信息	管理员收到了系统返回的查找结果
更新车次信息	管理员打开管理页面开始更新车次信息	管理员收到了更新成功或者失败的反馈
更新车票信息	管理员打开管理页面开始更新车票信息	管理员收到了更新成功或者失败的反馈
统计数据	管理员打开统计页面开始统计	系统展示了统计数据
数据备份	管理员开始备份数据	管理员收到了备份成功或者失败的反馈
数据恢复	管理员开始恢复数据	管理员收到了恢复成功或者失败的反馈

基于以上的这些，我们可以画出用例图：

 

 

3.业务领域建模

 

　　业务领域建模基本介绍　　

　　业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。

　　开发团队获取业务领域知识的过程一般包括收集业务领域相关信息，执行团队头脑风暴、对业务领域相关的知识概念进行分类，最后用UML类将业务领域知识图形化展示。

　　业务领域建模的方法：

1. 收集业务领域的信息。聚焦在功能需求层面。
2. 头脑风暴。列出重要的业务领域概念以及这些概念的属性和概念之间的关系。
3. 给这些业务领域分类。列出哪些是类、属性值以及这些类之间的关系。
4. 将结果用UML图画出来。

　　工程实践中的业务领域建模

　　下面着重分析这个工程实践中的业务领域概念和概念之间的关系。

（1）    用户账户类

属性：账户id，密码

操作：登录

（2）    普通用户

属性：名字，身份证id，手机号，密码

操作：注册信息，修改信息，查看订单，查询车次，查询车票，订票，退票，改签

（3）    系统管理员

属性：名字，密码

操作：查找车次信息，修改车次信息，查找车票信息，修改车票信息，统计数据，数据备份，数据恢复

（4）    车次信息：

属性：车次id，出发站，终点站，出发时间，到达时间

（5）    车票信息

属性：价格，车次信息

（6）    订单信息

属性：车票信息，购票时间，购买人

（7）    售票系统

属性：

操作：显示车次信息，显示车票信息，记录订单信息，创建用户信息，显示订单信息。

　　其中普通用户和系统管理员继承了用户账户类。车票信息类继承了车次信息类，订单信息类继承了车票信息类，车次信息类和用户账户类与售票系统是关联关系。

　　下面是UML图

 

 

 

 

数据模型

下面分析一下这个项目中的关系型数据模型。研究一下之前类图中的关联关系。

观察一下用户这个类和车票这个类，他们之间没有继承的关系，也没有聚合关系，但是确是在这个系统的数据库中要占用绝大部分空间的一个关系数据。联接这两个类的就是订单信息，每一个订票信息中都有包括一个用户和一个车票。一个用户可以购买多张车票，但一张车票同一时间内只能属于一个用户，是典型的一对多的关系。

 

 

所以整合后的UML图为：

 

 

 

 

关系数据的数据表如下：

用户表

用户id	名字	省份证	密码	手机号

车次表

车次id	出发站	终点站	出发时间	到达时间

车票表

车票id	车次id	价格	剩余数量

订票表

订单号	用户id	车票id	订票时间

 

形成的过程

　　以上的结果，是在需求分析这样一个要求下形成的。要想高质量地分析需求，首先就要弄清楚几个问题。什么是需求？需求对于这个项目的意义？有什么类型的需求？和这些需求相关的主题是什么？这些主体之间又怎样的一种联系？就好像从一个项目中提取中很多的语句，要理清这些语句的主谓宾是什么。

　　这些问题涉及到这个项目要实现哪些业务逻辑，要有哪些类，每个类有哪些属性和方法。以上的建模就是在这样的一个思考过程中形成的。

概念原型

火车售票系统概念原型由一个用例图和7个类构成。整个工作过程为：用户从系统中查询车票信息，系统返回车次信息，用户决定是否订票，若订票又向系统中写入信息。管理员登录系统后，可以查看增删查改各种信息，系统接受到这些操作对数据库的数据进行更新后，反馈给管理员。

比如说用户用户搜索苏州到上海的车票，系统返回一系列苏州到上海的列车信息，用户点击某个车次信息后能进行购票，购票后就可以在自己的购票记录中查看订单，查看订单后可以决定退不退票。如果某个车次突然没有了或者晚点了，系统管理员就要修改信息。

总结 

这篇博客经过了用例建模，业务领域建模和数据建模，完成了项目的需求分析，让我对项目的整体有了一个宏观的把握，十分感谢老师布置这次作业。