基于UML公共自行车服务系统的分析设计

基于UML公共自行车服务系统的分析设计

摘要:本文介绍了使用面向对象的开发方法及UML，并对公共自行车服务系统

进行建模,形成一个完整的建模系统实例，分析了该系统的需求分析过程，并详细介绍了该系统的设计过程。

关键字：UML 面向对象公共自行车服务系统

一：定义

UML，即统一建模语言，是一种概念清晰，表达能力丰富，适用范围广泛的面向对象建模语言，它主要以Booch方法，OMT方法和OOSE方法为基础，同时也吸收了其他面向对象建模方法的优点。它可以对任何具有静态结构和动态行为的系统进行建模，主要作用就是帮助用户进行面向的描述和建模，它可以描述软件从需求分析到软件实现和测试的全过程。UML通过图形化的表示机制从多个侧面对系统的分析和设计模型进行刻画。它共定义了十种试图，如图1：

二：需求分析

目前，国外很多城市诸如巴黎，马赛，里昂等都实施了公共自行车项目，取得了非常好的环保和社会效应。自行车是最好的短途交通工具，具有方便、健康、低碳环保等诸多优点。公共自行车系统是将自行车纳入到公共交通系统，基于“随用随借，公众使用”的开发理念，解决城市“最后1-3公里”的交通问题。既可以提到道路资源利用率，缓解道路拥堵，促进节能减排，减少尾气污染，还能强身健体，提高城市品位。

2.1 系统总体功能需求

公共自行车系统是利用计算机实现大量租车信息处理的电子档案管理系统，本系统主要满足市民和系统管理员，以及管理柱方面的需求。不但要让市民通过这个系统可以方便的借到自行车，而且这个系统更易于管理。

其分析如图2：

图 2

2.2 系统详细功能需求

2.2.1 借车模块

将具有租车功能的IC卡放在有公共自行车的锁止器的刷卡区刷卡，此时，锁止器界面上的绿灯闪一下变常亮，听到蜂鸣器发出“嘀”响声，表示锁止器已打开，租车人应及时（30秒内）将车取出，则完成租车。租车流程如下图3所示：

图 3

2.2.2 还车模块

将所租的自行车推入锁止器，当绿灯闪亮时，及时将租车时的IC卡在锁止装置的刷卡区进行刷卡，当绿灯停止闪亮，听到蜂鸣器发出“嘀”响声，表示车辆已锁止，还车成功。同时还车刷卡时，系统已停止计时并完成计时收费结算。流程如下图4所示：

图 4

2.2.3 缴费模块

当还车时，系统会按照图5所示

1小时之内免费1小时以上2小时以内：1元

2小时以上3小时以内：2元3小时以上：每小时3元

图 5

对所持的IC卡进行扣款。

若要归信用保证金的，可直接在自助服务机上按以下流程操作，如图6所示：

图 6

2.2.4 信息查询模块

若租用者需要查询本次租还车消费情况，按以下流程操作，如图7所示：

图 7

2.3 数据库模块

数据库模块主要是对各种信息进行管理，主要是对用户的收费情况和个人信息进行管理，如图8：

三：系统的UML基本模型

3.1 系统的用例图

3.1.1 定义参与者

用例图在需求分析阶段有很重要的作用,它是作为参与者的外部用户所能观察到的系统功能的模型图。整个开发过程都是围绕需求阶段的用例进行的。

公共自行车系统是使用计算机实现自行车大量信息处理的电子档案管理系统，在本系统中主要满足借车者（市民）、管理柱和系统管理员3 方面的需求。对借车者来说主要是查询个人信息、查询自行车信息、借自行车和返还自行车等；管理柱是负责借车处理和还车处理，对IC卡进行扣费，其自助服务机可对自己的租车信息进行查询和退款；系统管理员主要负责系统的维护工作，涉及到市民信息管理，自行车信息管理，系统状态维护等。系统的功能分析如图9 所示。

图 9

3.1.2 用例图设计

用例是系统的一个功能单元，可以被描述为参与系统之间的一次交互作用。用例图的用途是列出系统的用例和参与者，并且显示那个事用例的执行，根据以上的系统分析，用例图如下图10, 11, 12所示：

图10 图11 图 12

3.2 领域概念模型

领域概念模型是描述业务用例实现的对象模型。它是对领域角色和领域实体之间应该如何联系和协作以执行业务的一种抽象。领域对象模型从领域角色内部的观点定义了领域用例。

本系统的领域概念模型如图13所示：

图 13

3.3 系统的交互图

3.3.1分析类

有三种分析类:边界类、实体类和控制类。每一种在精化的系统模型中执行

一种特定的作用。

（1）边界类：用于描述目标软件系统与外部环境之间的交互，并负责实现如下功能：界面控制，外部接口，环境隔离。在此系统中，控制柱上的传感器，以及自动服务机上的显示面板都是边界类。

(2) 实体类：表示目标软件系统中具有持久意义的信息项及其操作。实体类的操作具有“内向收敛”特征，他们仅向目标软件系统的其余部分提供读，写信息项内容的必要的操作接口，并不涉及业务逻辑处理。在本系统中，“读卡异常”即为实体类。

（3）控制类：作为完成用例任务的责任承担者，协调，控制其他类共同完成用例规定的功能或行为。对于比较复杂的用例，控制类通常并不处理具体的任务

细节，但是它应知道如何分解任务，如何将子任务分派给适当的辅助类，以及如

何在辅助类之间进行信息传递和协调。

在公共自行车系统中定义的控制类如表14所示:

图 14

3.3.2 交互图设计

3.3.2.1 公共自行车系统的顺序图和协作图

顺序图：建模过程中，用力定义后应为一些重要的用例建立简单的行为模型，

从而使该用例更为清晰，也为在建立结构模型时更容易把握这些类构件，通常用

顺序图描述对象间动态的交互关系，着重体现对象间消息传递的时间顺序. 图15既是“公共自行车租赁”用例的交互顺序图：