UML期末大作业

UML建模期末大作业 设计报告

 

题 目： 公交线路管理系统

学生姓名： 王帅

专业班级： 软工20103

指导教师： 潘梅森

设计时间： 2022年下学期

指导老师意见:

评定成绩： 签名： 日期：

 

目录

一、 设计任务书 1

1.1“4+1”视图模型 1

1.2操作步骤 3

二、 本组课题及本人任务 3

2.1本组课题 3

2.2本人任务 3

三、 公交线路管理系统功能简介 4

3.1 系统概述 4

3.2需求分析 4

四、 公交线路管理系统主体内容 5

4.1业务建模 5

（1） 公交线路管理系统的业务参与者 5

（2） 公交线路管理系统的业务用例 5

（3） 公交线路管理系统的业务活动图 6

4.2用例建模 6

（1） 分析公交线路管理系统的需求 6

（2） 公交线路管理系统的参与者 7

（3） 公交线路管理系统的用例 7

（4） 公交线路管理系统的用例图 7

（5） 公交线路管理系统的用例文档 10

4.3用例分析 15

（1） 分析公交线路管理系统的用例 15

（2） 完善交线路管理系统的用例文档 15

（3） 公交线路管理系统的分析类 20

（4） 公交线路管理系统的顺序图 21

（5） 公交线路管理系统的类图 24

4.4设计重构 25

（1）面向用户的观点 25

（2）严格按阶段进行 25

（3）采用系统的观点处理 25

（4）采用模块化设计方法 25

（5）整个系统的设计主要采用快速原型法 25

五、 心得体会 26

六、 参考文献 27

1. 设计任务书

1.1“4+1”视图模型

参考“4+1”视图模型，采用UML技术进行公交线路管理系统建模，完成公交线路关系统的相关UML图。“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容。

逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。

在面向对象技术中，通过抽象，封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。

逻辑视图中使用的风格为面向对象的风格，逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统。总而言之，逻辑视图就是把功能模块分出来，功能模块封装成类，然后对象类与功能类之间所有的关系表示出来。

开发视图也称模块视图，主要侧重于软件模块的组织和管理。

开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。

开发视图通过系统输入输出关系的模型图和子系统图来描述。

在开发视图中，最好采用4-6层子系统，而且每个子系统仅仅能与同层或更低层的子系统通讯，这样可以使每个层次的接口既完备又精练，避免了各个模块之间很复杂的依赖关系。

设计时要充分考虑，对于各个层次，层次越低，通用性越强，这样，可以保证应用程序的需求发生改变时，所做的改动最小。开发视图所用的风格通常是层次结构风格。总而言之，开发视图就是将系统分成4-6层，越底层的就越通用也越小，底层的可以组成上一层的，相邻两层的联系比较大。

进程视图侧重于系统的运行特性，主要关注一些非功能性的需求。

进程视图强调并发性、分布性、系统集成性和容错能力，以及从逻辑视图中的主要抽象如何适合进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。

进程视图可以描述成多层抽象，每个级别分别关注不同的方面。在最高层抽象中，进程结构可以看作是构成一个执行单元的一组任务。它可看成一系列独立的，通过逻辑网络相互通信的程序。它们是分布的，通过总线或局域网、广域网等硬件资源连接起来。总而言之，进程视图就是描述逻辑视图中一个具体功能是怎样在线程中执行。着重于逻辑视图中的工作细节。

物理视图主要考虑如何把软件映射到硬件上，它通常要考虑到系统性能、规模、可靠性等。解决系统拓扑结构、系统安装、通讯等问题。

当软件运行于不同的节点上时，各视图中的构件都直接或间接地对应于系统的不同节点上。因此，从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响最小。总而言之，物理视图就是分配构件的物理资源，将构件或进程的物理资源分配情况展示。

场景视图。场景可以看作是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。在开发体系结构时，它可以帮助设计者找到体系结构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。总而言之，场景视图描述现实中的系统运用场景的过程，将牵涉到的对象、服务和操作都展示。

逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。

1.2操作步骤

参考“4+1”视图模型，利用UML工具对系统进行视图建模：

1、业务建模主要操作步骤：识别业务参与者、识别业务用例、绘制活动图等。

2、用例建模主要操作步骤：分析需求、识别参与者、识别用例、绘制用例图、编写用例文档、重构用例模型等。

3、用例分析主要操作步骤：分析用例、完善用例文档、识别分析类、绘制顺序图、绘制类图等。

4、根据面向对象的设计原则和常用设计模式对设计进行重构并进行总结。

1. 本组课题及本人任务

2.1本组课题

本组的课题是公交线路管理系统。

2.2本人任务

本人的任务是对公交线路管理系统统一建模，进行业务建模、用例建模、用例分析以及设计重构。

1、业务建模——采用软件建模方法分析和理解待开发的业务，描述业务流程（≥10个业务功能）。

2、用例建模——用UML用例技术描述软件需求。

3、用例分析——采用UML用例分析技术分析软件需求，建立软件系统的分析模型。

4、设计重构——根据面向对象的设计原则和常用设计模式对设计进行重构。

1. 公交线路管理系统功能简介

3.1 系统概述

公交线路管理系统中有两种角色：普通用户和系统管理员。系统管理员可以使用站点管理、路线管理、实时路况发布及管理用户四大功能。普通用户包括线路查询、站点查询 、实时路况查看等多种核心公交查询功能。

本设计主要实现公交路线管理系统的路线基本查询，从而满足群众的出行需要。系统的主要功能是实现车况、路况、客流的实时监控，通过监控数据实现公交车辆的灵活查询，还包括录入线路信息，显示所有路线信息，删除路线，站与站路线查询（输入起始站和终点站，查询经过两站的路线）。

3.2需求分析

（1）登录：用户以注册邮箱或者id号配合密码进行登录。当用户进入 web 登录界面，用户以用户名id号配合密码进行登录。登录界面有id输入框，密码输入框，以及“登录”按钮。

（2）登录验证:用户输入者id号，系统将暂时不进行 id 号合法与否的检查。用户在输入完账号后，将进行密码输入。密码输入框也将暂时不进行字符串检查。用户在点击“登录”按钮后，系统将首先检查账号。如符合id 格式，则进行id的登录。若不符合，则弹出消息框显示“账号不存在”。系统在进行id登录时，首先要检查密码串，若密码串存在少于 8 位、多于16位、含有非法字符等情况，则弹出消息框显示“密码错误”。若密码串格式无误，则进行登录，与数据库中记录的id号以及密码串进行比对，如果比对成功，则登录成功，页面将转到用户的个人主页。如果比对失败，则弹出消息框显示“登录失败，请检查 id 号和密码是否有误。”

（3）登录之后可以使用的功能：

1 ）车次查询：登录以后，系统管理员和普通用户都可以进行车次查询。即输入任一需要查询的公交线路（如18），点击查询按钮，反馈结果为这条公交线路的起点到终点之间的所有公交站点，包括首末班车时间。

2 ）站与站之间查询：登录以后，系统管理员和普通用户都可以进行站站查询。即输入任意两个站点，点击查询按钮，反馈结果为这两个公交站点之间的所有可达线路。如果没有直达路线就显示最优换乘路线。

3 ）实时路况发布：登录以后，系统管理员可以进行发布相关信息。即在实时路况发布版块编写并发布即时交通路况信息，比如发布18公交车上的乘客数量，路与路之间堵不堵等信息，然后点击发布按钮即可发布到系统里，其他所有用户都可以查看发布的这条信息，并可以在文本框下留言回复。

4 ）投诉：普通用户登录以后可以对在公交车上发生的不公平现象或者违章违规现象进行投诉。即在投诉版块的文本框内编写需要投诉的现象，系统会把投诉情况显示给系统管理员，由系统管理员对这些投诉情况进行及时处理。

5 ）线路更新：系统管理员登录以后可以对城市的公交线路以及站点进行修改更新。即可以添加新的公交线路、修改已有公交线路和删除旧的公交线路，同样可以添加新的公交站点、修改已有公交站点和删除旧的公交站点。

6 ）投诉管理：系统管理员登录以后可以对普通用户提交的投诉进行处理。即系统管理员需要及时地对普通用户所提出的投诉进行审核处理，并向当事人司机进行核实，最后总结结果向公司报告且把结果反馈给当时所投诉的乘客。

1. 公交线路管理系统主体内容

4.1业务建模

1. 公交线路管理系统的业务参与者

业务参与者包括普通用户、系统管理人员、公交车司机和公交车公司。

1. 公交线路管理系统的业务用例

业务用例包括公交查询与管理、站站之间查询与管理、线路查询与管理、乘车查询与管理、实时路况发布与投诉管理、用户登录与管理共10个业务用例。

1. 公交线路管理系统的业务活动图

图 1公交线路管理系统业务活动图

4.2用例建模

1. 分析公交线路管理系统的需求
2. 登录：用户以注册邮箱或者id号配合密码进行登录。
3. 登录验证:检查 id 号和密码是否有误。
4. 车次查询：登录以后，系统管理员和普通用户都可以进行车次查询。返回结果为公交线路的起点到终点之间的所有公交站点，包括首末班车时间。
5. 站与站之间路线查询：登录以后，系统管理员和普通用户都可以进行站站查询。返回结果为这两个公交站点之间的所有可达线路。如果没有直达路线就显示最优换乘路线。
6. 实时路况发布：登录以后，系统管理员可以编写并发布即时交通路况信息，比如乘客数量，路与路之间堵不堵等信息。所有用户可以查看发布信息。
7. 投诉：普通用户登录以后可以对在公交车上发生的不公平现象或者违章违规现象进行投诉。系统会把投诉情况显示给系统管理员，由系统管理员对这些投诉情况进行及时处理。
8. 线路更新：系统管理员登录以后可以对城市的公交线路以及站点进行修改更新。即可以添加新的公交线路、修改已有公交线路和删除旧的公交线路，同样可以添加新的公交站点、修改已有公交站点和删除旧的公交站点。
9. 处理投诉：系统管理员登录以后可以对普通用户提交的投诉进行处理。即系统管理员对普通用户所提出的投诉进行审核处理，向当事人司机进行核实，最后总结结果向公司报告且把结果反馈给当时所投诉的乘客。
10. 公交线路管理系统的参与者

参与者包括普通用户、系统管理人员、公交车司机和公交车公司。

1. 公交线路管理系统的用例

用例包括登录、登录验证、车次查询、站与站之间路线查询、实时路况发布、实时路况查看、投诉、处理投诉、查看投诉结果、更新公交路线、更新公交站点。

1. 公交线路管理系统的用例图

公交线路管理系统用例图

图 2公交线路管理系统用例图

站与站之间的子用例图

图 3站与站之间的子用例图

线路查询与管理子用例图

图 4线路查询与管理子用例图

乘车查询与管理子用例图

图 5乘车查询与管理子用例图

投诉与管理子用例图

图 6投诉与管理子用例图

1. 公交线路管理系统的用例文档

表 1“登录”用例文档

用例名	登录
简要描述	普通用户或管理员利用该用例登录系统，登录验证通过后，获取相应的权限
参与者	普通用户、系统管理员
涉众	普通用户、系统管理员
相关用例	登录验证
前置条件	无
后置条件	如果登录成功，则获取相应的权限功能
基本事件流 用例起始于用户需要登录到该系统 系统显示欢迎界面，并要求用户输入用户名和密码 用户输入用户名和密码 系统验证用户名和密码，允许用户登录系统（A-1） 系统根据用户类型启动不同的主操作界面
备选事件流 A-1 用户名错误或者密码错误 系统显示用户名错误或者密码错误的提示信息，并进入第（2）步 用户可以重新输入用户名和密码（B-1），也可以选择结束该用例
补充约束 B-1 系统允许用户重试3次登录操作，超过3次后系统自动结束，不允许用户重试 补充约束-非功能需求 安全性：密码应该采用加密的方式存储，有关密码的加密算法待定
待解决问题 关于用户名和密码的管理与维护功能还需要进一步明确
相关图 暂无

表 2“车次查询”用例文档

用例名	车次查询
简要描述	普通用户或者系统管理员通过该用例查询相应公交车的公交路线包括首末班车时间
参与者	普通用户、系统管理员
涉众	普通用户、系统管理员、公交车司机、公交车公司
相关用例	公交路线与公交站点的添加、修改、删除
前置条件	普通用户、系统管理员正确登录到该系统
后置条件	如果查询成功，则系统返回相应的车次信息给用户
基本事件流 用例起始于用户需要查询车次 用户输入需要查询车次信息的公交车 系统验证该公交车是是否存在（A-1） 系统根据用户的输入查询相应公交车的车次信息（D-1） 系统显示车次信息（A-2）
备选事件流 A-1 未查询到相应的公交车 系统显示错误的提示信息，并进入第（2）步 用户重新输入要查询的公交车号，也可以结束该用例 A-2 查询的车次信息不符合用户要求 （1）用户重新输入要查询的公交车号，也可以结束该用例
补充约束-数据需求 D-1 车次信息包括该公交车的行驶路线、到达每个站点的时间
待解决问题 暂无
相关图 暂无

表 3“站与站之间查询”用例文档

用例名	站与站之间查询
简要描述	普通用户或者系统管理员通过该用例查询2个公交站之间的所有可达公交路线
参与者	普通用户、系统管理员
涉众	普通用户、系统管理员、公交车司机、公交车公司
相关用例	公交路线与公交站点的添加、修改、删除
前置条件	普通用户、系统管理员正确登录到该系统
后置条件	如果查询成功，则系统返回站与站之间的公交路线信息给用户
基本事件流 用例起始于用户需要查询站与站之间的公交车路线 用户输入需要查询的2个站点 系统验证该站点是是否存在（A-1） 系统根据用户的输入查询相应站点之间的公交路线信息（D-1） 系统显示2个站点之间的公交路线（A-2）
备选事件流 A-1 未查询到相应的公交车站点 系统显示错误的提示信息，并进入第（2）步 用户重新输入要查询的公交站点，也可以结束该用例 A-2 查询的公交路线不符合用户期待 （1）用户重新输入要查询的公交车号，也可以结束该用例
补充约束-数据需求 D-1 公交路线信息包括站点之间公交路线、到达中途每个站点的时间
待解决问题 暂无
相关图 暂无

表 4“实时路况查看”用例文档

用例名	实时路况查看
简要描述	普通用户或者系统管理员通过该用例查看实时发布的交通路况
参与者	普通用户、系统管理员
涉众	普通用户、系统管理员、公交车司机、公交车公司
相关用例	实时路况发布
前置条件	普通用户、系统管理员正确登录到该系统且系统管理员发布实时路况
后置条件	如果查看成功，则系统返回实时路况信息给用户
基本事件流 用例起始于用户需要查看交通路线路况的实时信息 用户输入要查看的交通路线 系统查询数据库中是否存在管理员发布的实时路况信息（A-1） 系统根据用户的要求查询相应公交路线的实时路况信息（D-1） 系统显示实时路况信息（A-2）
备选事件流 A-1 未查询到实时路况信息 系统显示错误的提示信息，并进入第（2）步 用户重新输入要查询的实时路况的公交路线，也可以结束该用例 A-2 查询的实时路况的公交路线不符合用户期待（过时） （1）用户重新输入要查询的实时路况的公交路线，也可以结束该用例
补充约束-数据需求 D-1 实时路况信息包括发布的时间、公交路线、交通路况、预计到达站点的时间
待解决问题 暂无
相关图 暂无

表 5“实时路况发布”用例文档

用例名	实时路况发布
简要描述	系统管理员通过该用例发布实时的交通路况
参与者	系统管理员
涉众	普通用户、系统管理员
相关用例	实时路况查看
前置条件	系统管理员正确登录到该系统
后置条件	如果发布成功，则系统存储实时路况信息
基本事件流 用例起始于系统管理员需要发布实时路况信息 系统管理员编写公交路线的实时路况信息（A-1） 系统管理员发布公交路线的实时路况信息（A-2） 系统存储系统管理员发布的实时路况信息（D-1）
备选事件流 A-1 公交路线的实时路况信息不符合要求或者管理员删除信息 系统显示错误的提示信息，并根据选择进入第（2）步或者第（3）步 管理员重新编写公交路线的实时路况信息，也可以结束该用例 管理员删除信息，结束该用例 A-2 公交路线的实时路况信息过时 管理员更新公交路线的实时路况信息，也可以结束该用例 管理员删除该公交路线的实时路况信息，再结束该用例
补充约束-数据需求 D-1 实时路况信息包括发布的时间、公交路线、交通路况、预计到达站点的时间 补充约束-非功能需求 可用性：发布的信息是一定范围内时间的信息才能发布
待解决问题 暂无
相关图 暂无

表 6“投诉”用例文档

用例名	投诉
简要描述	普通用户通过该用例投诉
参与者	普通用户
涉众	普通用户、系统管理员
相关用例	处理投诉
前置条件	普通用户正确登录到该系统
后置条件	如果投诉成功，则系统显示信息给系统管理员
基本事件流 用例起始于用户需要投诉 用户根据实际情况编写投诉的现象 系统存储用户编写的投诉信息（A-1）（D-1） 系统通知系统管理员处理投诉
备选事件流 A-1 投诉信息不符合要求或者用户要删除信息 系统显示错误的提示信息，并根据选择进入第（2）步或者第（3）步 用户重新编写投诉信息，也可以结束该用例 用户删除信息，结束该用例
补充约束-数据需求 D-1 投诉信息包括投诉的时间、投诉的当事人司机及公交车、投诉者 补充约束-非功能需求 可靠性：投诉的信息必须要在规定的时间内处理
待解决问题 暂无
相关图 暂无

表 7“处理投诉”用例文档

用例名	处理投诉
简要描述	系统管理员通过该用例处理投诉
参与者	系统管理员
涉众	普通用户：投诉者 系统管理员：处理投诉 公交车司机：投诉现象当事人 公交车公司：收集投诉结果
相关用例	投诉、总结报告反馈投诉结果、核实投诉情况
前置条件	系统管理员正确登录到该系统且有用户进行投诉
后置条件	如果处理投诉成功，则系统管理员需要核实投诉情况、总结报告反馈投诉结果
基本事件流 用例起始于管理员需要处理投诉 管理员接收到系统的通知和相关的投诉信息（D-1） 管理员审核处理投诉，并向当事人司机核实情况（A-1） 管理员判定并总结结果（D-2） 管理员报告公司和反馈用户结果（A-2） 公交车公司收集总结报告
备选事件流 A-1 管理员向当事人司机核实情况不符合 当事人提交公交车行驶记录，接收投诉，返回结果给管理员 当事人反驳投诉，告知投诉者进行对峙，得出并返回结果给管理员 A-2 公司或者用户对总结结果不满意 管理员对公司或者用户进行解释说明 管理员重新进行基本事件流的第（3）、（4）步
补充约束-数据需求 D-1 投诉信息包括投诉的时间、投诉的当事人司机姓名及公交车牌号、投诉者姓名 D-2 总结结果信息包括处理投诉者姓名、投诉者姓名、投诉的结果信息、总结结果的时间、核实情况信息 补充约束-非功能需求 可靠性：处理投诉必要在规定的时间内完成，并提交总结报告和反馈用户投诉结果
待解决问题 暂无
相关图 暂无

4.3用例分析

1. 分析公交线路管理系统的用例

用例包括登录、登录验证、车次查询、站与站之间路线查询、实时路况发布、实时路况查看、投诉、处理投诉、管理投诉、总结报告反馈投诉结果、收集投诉结果、查看投诉结果、添加新的公交路线、修改已有公交线路、删除旧的公交线路、添加新的公交站点、修改已有公交站点、删除旧的公交站点。

1. 完善交线路管理系统的用例文档

表 8“添加新的公交路线”用户文档

用例名	添加新的公交路线
简要描述	系统管理员通过该用例添加新的公交路线
参与者	系统管理员
涉众	普通用户：查询公交路线的人 系统管理员：添加新的公交路线 公交车司机：行驶新的公交路线
相关用例	无
前置条件	系统管理员正确登录到该系统
后置条件	如果添加新的公交路线成功，则系统需要更新数据库并通知用户
基本事件流 用例起始于管理员需要添加新的公交路线到该系统 管理员填写并提交新的公交路线（D-1） 系统审核后录入数据库中（A-1） 系统更新并显示新的公交路线
备选事件流 A-1 审核未通过 系统通知管理员，发出提示信息，此处可以结束该用例或者进入第（2）步 管理员对审核未通过的公交路线进行修改后再次提交
补充约束-数据需求 D-1 新的公交路线 补充约束-非功能需求 可靠性：添加进数据库中的数据要完整，增加后其他用户要能够查询到且无错误
待解决问题 无
相关图 无

表 9“修改已有的公交路线”用例文档

用例名	修改已有的公交路线
简要描述	系统管理员通过该用例修改已有的公交路线
参与者	系统管理员
涉众	普通用户、系统管理员、公交车司机
相关用例	无
前置条件	系统管理员正确登录到该系统
后置条件	如果修改已有的公交路线成功，则系统需要更新数据库并通知用户
基本事件流 用例起始于管理员需要修改系统中已有的公交路线 管理员填写并提交修改后的公交路线（D-1） 系统审核后录入数据库中并将修改前的路线标记作废（A-1）（D-2） 系统更新并显示修改后的公交路线
备选事件流 A-1 审核未通过 系统通知管理员，发出提示信息，此处可以结束该用例或者进入第（2）步 管理员对审核未通过的公交路线进行修改后再次提交
补充约束-数据需求 D-1 修改后的公交路线包括修改的时间，修改之前公交路线，修改之后的公交路线 D-2 修改前的公交路线 补充约束-非功能需求 正确性：添加进数据库中的数据要正确完整的
待解决问题 无
相关图 无

表 10“删除旧的公交路线”用例文档

用例名	删除旧的公交路线
简要描述	系统管理员通过该用例删除旧的公交路线
参与者	系统管理员
涉众	普通用户、系统管理员、公交车司机
相关用例	无
前置条件	系统管理员正确登录到该系统
后置条件	如果删除旧的公交路线成功，则系统需要更新数据库并通知用户
基本事件流 用例起始于管理员需要删除系统中已有的公交路线 管理员填写并提交要删除的公交路线（D-1） 系统审核后将数据库中旧的公交路线标记作废（A-1）（D-2） 系统更新并通知用户
备选事件流 A-1 审核未通过 系统通知管理员，发出提示信息，此处可以结束该用例或者进入第（2）步 管理员对审核未通过的公交路线进行修改后再次提交
补充约束-数据需求 D-1 删除后的公交路线包括修改的时间，删除之前公交路线，删除之后的公交路线 D-2 删除前的公交路线 补充约束-非功能需求 正确性：添加进数据库中的数据要正确完整的
待解决问题 无
相关图 无

表 11“添加新的公交站点”用例文档

用例名	添加新的公交站点
简要描述	系统管理员通过该用例添加新的公交站点
参与者	系统管理员
涉众	普通用户、系统管理员、公交车司机
相关用例	无
前置条件	系统管理员正确登录到该系统
后置条件	如果添加新的公交站点成功，则系统需要更新数据库并通知用户
基本事件流 用例起始于管理员需要添加新的公交站点 管理员填写并提交要添加新的公交站点 系统审核后将添加新的公交站点到数据库中（A-1）（D-1） 系统更新并通知用户
备选事件流 A-1 审核未通过 系统通知管理员，发出提示信息，此处可以结束该用例或者进入第（2）步 管理员对审核未通过的公交站点进行修改后再次提交
补充约束-数据需求 D-1 添加后的公交站点包括站点经过的公交车，站点地理位置 补充约束-非功能需求 正确性：添加进数据库中的数据要正确完整的
待解决问题 无
相关图 无

表 12“修改已有的公交站点”用例文档

用例名	修改已有的公交站点
简要描述	系统管理员通过该用例修改已有的公交站点
参与者	系统管理员
涉众	普通用户、系统管理员、公交车司机
相关用例	无
前置条件	系统管理员正确登录到该系统
后置条件	如果修改已有的公交站点成功，则系统需要更新数据库并通知用户
基本事件流 用例起始于管理员需要修改已有的公交站点 管理员填写并提交要修改的公交站点 系统审核后将数据库中修改前的公交站点标记为作废（A-1） 系统更新并通知用户
备选事件流 A-1 审核未通过 系统通知管理员，发出提示信息，此处可以结束该用例或者进入第（2）步 管理员对审核未通过的公交站点进行修改后再次提交
补充约束-非功能需求 正确性：添加进数据库中的数据要正确完整的
待解决问题 无
相关图 无

表 13“删除旧的公交站点”用例文档

用例名	删除旧的公交站点
简要描述	系统管理员通过该用例删除旧的公交站点
参与者	系统管理员
涉众	普通用户、系统管理员、公交车司机
相关用例	无
前置条件	系统管理员正确登录到该系统
后置条件	如果删除旧的公交站点成功，则系统需要更新数据库并通知用户
基本事件流 用例起始于管理员需要删除旧的公交站点 管理员填写并提交要删除的旧公交站点 系统审核后将数据库中旧的公交站点标记为作废（A-1） 系统更新并通知用户
备选事件流 A-1 审核未通过 系统通知管理员，发出提示信息，此处可以结束该用例或者进入第（2）步 管理员对审核未通过的公交站点进行修改后再次提交
补充约束-非功能需求 可行性：对数据库进行操作要保证ACID原则
待解决问题 无
相关图 无

1. 公交线路管理系统的分析类
2. 公交线路管理系统的边界类

图 7公交线路管理系统的边界类

1. 公交线路管理系统的控制类

图 8公交线路管理系统的控制类

1. 公交线路管理系统的实体类

图 9公交线路管理系统的实体类

1. 公交线路管理系统的顺序图

公交线路管理系统“查询车次用例”顺序图

图 10公交线路管理系统“查询车次用例”顺序图

公交线路管理系统“查询实时路况”用例顺序图

图 11公交线路管理系统“查询实时路况”用例顺序图

公交线路管理系统“查询站与站之间路线”用例顺序图

图 12公交线路管理系统“查询站与站之间路线”用例顺序图

公交线路管理系统“投诉”用例顺序图

图 13公交线路管理系统“投诉”用例顺序图

公交线路管理系统“登录用例”顺序图

图 14公交线路管理系统“登录用例”顺序图

1. 公交线路管理系统的类图

公交线路管理系统分析类图

图 15公交线路管理系统分析类图

公交线路管理系统实体类图

图 16公交线路管理系统实体类图

4.4设计重构

（1）面向用户的观点

公交线路管理系统是为广大乘客用户开发研制的，用户是系统的最终使用者和评价者，所以在网络通信系统的开发设计的过程中，我们树立了从用户的寻求出发，面向用户，一切为了用户的观念，在分析与设计系统的前期，为了保证系统的功能的完善多次寻求周围同学和老师的意见，了解他们的要求，依照功能完善，界面美观，操作简单的原则进行设计。

（2）严格按阶段进行

（3）采用系统的观点处理

在系统分析阶段，在对原系统进行全面调查和分析的基础上，构造系统的最佳逻辑模型，使用户对将来完整系统的轮廓有个初步的了解和认识，以便及时和用户进行交流和探讨，不断提高系统的完善性。在此基础上进行系统的物理实现和设计，切实完成逻辑模型的具体功能。逻辑设计和物理实现二者是相辅相成、密不可分的，这样使系统的设计更加稳妥合理。

（4）采用模块化设计方法

系统模块化设计方法是从计算机实现的角度出发对整个系统进行审核和校验，将整个系统划分为不同的功能模块，实现系统的一个特定功能。各个功能模块之间具有相对独立性，便于整个系统的设计、实施、维护和扩充。这种模块化结构设计方法，为整个系统顺利进行奠定了基础。

（5）整个系统的设计主要采用快速原型法

快速原型法是信息系统设计的一个重要方法。它是根据用户提出的需求，由用户和开发者共同确定系统的基本要求和主要功能，并在一个较短的时间内建立一个实验性的、简单的信息系统模型，通过用户不断提出的意见和建议，对模型进行不断的修改和完善，直到用户比较满意为止，以便形成一个相对稳定、较为理想的管理信息系统。该方法的主要优点：

1）脉络清楚，所有问题都围绕一个模型展开，使彼此之间联系紧密。

2）有助于发现用户需求，通过对原形和用户接触，能够启发开发人员去挖掘问题，从而不断的修正、完善，最终得到一个理想的系统。

3）系统开发效率高，此方法的开发周期短、使用灵活、容易修改，这对于管理体制不够稳定的系统更加适合。

4）系统的可扩展性好，由于此方法是在原型应用中不断发展完善和修改的，所以有较强的扩展性。

1. 心得体会

这次UML建模期末大作业花费了将近两周时间，在这期间我第一次体验到UML建模的困难，期间还犯了一次低级错误，绘图完成后未进行保存导致一个上午的努力白费。但最终在成功完成时回顾自己的成果时也体验到了很大的成就感，自己从前也从未有过如此的经历，从零到壹完整的按部就班进行了整个过程。这种成就感让我兴奋不已。我自知自己还有许多不足的地方，整个建模的过程只是简单的完成，还有很大的提升空间，有限的时间内我难以交出满意的答卷。

这次经历给我感触最深的地方就是，注重细节。在刚阅读完UML建模大作业指导书的时候，我只粗略想了一下总体设计和大概的设计任务书，感觉可以较为轻松完成任务。但在接下来的时间中，我才感受到什么叫做细节决定成败，在绘制UML图时，常常会出现绘制出来的图形与需求不对等，然后频繁的进行修改，修改后图形也需要更改，更完又会发现新的需要没有考虑到，如此往复导致时间浪费了很多，效率很低下。

就在画一个用例图时，我就遇到了不小的麻烦。看似不长的需求说明，其中往往包含了很多用例，总是考虑不全，画起来十分费力。中间不容有一点儿大意，一点小小的错误会浪费很多的时间去寻找与改错。期间不断地发现错误，不断地改正错误，在这样的过程中收获也是很多的。

虽然建模过程中遇到数不尽的难题，但在同学的启发与老师的帮助下。我终于克服重重困难完成了建模，这是我自己努力付出的结果，也有同学和老师的热心帮助的回报，没有他们的帮助，我没有信心能够完成。这是一次难得的历练，它让我认识到建模不仅需要丰富的只是和经验，更需要认真仔细的态度去面对。

1. 参考文献
2. 谭火彬 UML2面向对象分析与设计(第二版)[M].北京：清华大学出版社 2013