基于工程实践的需求分析和概念原型

订票系统的需求分析

用例图

什么是用例

 用例（Use Case）的核心概念中首先它是一个业务过程（business process），经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务（business task）的一系列活动就是业务过程。

用例的几个基本要素：

A use case is initiated by (or begins with) an actor. 一个用例应该由业务领域内的某个参与者（Actor）所触发。

A use case must accomplish a business task (for the actor).用例必须能为特定的参与者完成一个特定的业务任务。

 

A use case must end with an actor. 一个用例必须终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。

 用例建模的基本步骤

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

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

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

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

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

 

下面画出工程实践的用例图

 

 

 

 业务类图

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

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

业务领域建模的步骤

第一步，收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；

第二步，头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；

第三步，给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。

第四步，将结果用 UML 类图画出来。

第一步更多地在获取需求的阶段已经完成，这里不做赘述；第四步 UML 类图的画法前面已经给出，接下来我们重点将头脑风暴的做法和业务领域概念分类的方法具体探讨一下

 

 

数据模型

person表

ID	name	是否学生	phone	password

学生表

 

ID	学校	学号

 

ticket

 

ID	车次	时间	价格	座位

 

订单

ID	personID	ticketID	是否付款	售后信息

 

 管理员

ID	name	权限

 

概念原型及工作过程

 

概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论。
概念原型是一种虚拟的、理想化的软件产品形式。

概念原型=用例+数据模型

订票系统概念模型分为两个用例图和五个数据模型：
用例分为用户用例图、管理员用例图；
数据模型分为普通用户、学生用户、车票，订单，管理员。

整个概念模型的工作过程为：

用户在系统中完成注册登录功能，并且其余的信息如电话等可以由用户进行修改。所有用户的账号信息都由管理员进行管理，用户分为普通用户和学生用户，学生用户可以获得折扣。用户选择车票进行购买，产生一条订单信息，这个车票可以进行购买和退货，退货就涉及到了订单中的售后信息。用户中，学生用户和普通用户是继承自用户类，而订单类是作为用户与车票关联关系的关联类。管理员也有自己的ID，可以对库存的车票进行操作，也可以对用户的订单进行操作。用户和管理员之间也可以进行沟通。

 

总结

 当然系统还有其余的功能不过因为工程实践暂时没有讨论和开会，目前暂定的基础功能就这些。

参考

 https://gitee.com/mengning997/se/blob/master/ppt/%E4%BB%8E%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90%E5%88%B0%E8%BD%AF%E4%BB%B6%E8%AE%BE%E8%AE%A1.pptx