《UML面向对象分析》课程
实践项目报告
项目名称：网上订购火车票系统
项目组成员：
学号：
班级：
指导教师：
2008年11 月10 日
目录
1 需求分析 (1)
1.1 需求概述 (1)
1.2 需求分析 (2)
1.3 需求模型（用例图） (6)
2 静态模型 (8)
2.1 类图 (8)
2.2 对象图 (10)
2.3 包图 (12)
3 动态模型 (13)
3.1 时序图 (13)
3.2 状态图 (16)
3.3 协作图 (17)
3.4 活动图 (18)
4 项目组成员分工说明 (19)
5 总结 (20)
6 参考资料 (21)
1需求分析
1.1 需求概述
线上预订火车票系统是一款功能强大、操作简便、易维护的、具有良好人机交互界面的线上订票系统，它包括用户管理模块、系统参数设置模块、票务信息模块（提供票价、列车的实时信息）、订票管理模块（提供订票和退订功能）、实时信息提示模块（提供车况、路况、列车晚点等实时信息）、数据管理模块（提供数据备份、数据操作功能）。实现火车票线上预定的自动化的计算机系统，为旅客提供准确、精细、迅速的火车票销售信息和方便、简单的订票功能。
线上预订火车票系统主要是对于订票信息的统一管理，满足了中小型线上订票网站对于用户的管理，订票信息的收集和处理方面的要求。用现代化的方式取代以前的传统模式，更有利于信息的流通，资源的宏观管理。具有体积小，代码简洁，易维护、易修改的优点。
线上订购火车票系统
用户管理模块系
统
参
数
设
置
模
块
票
务
信
息
模
块
订
票
管
理
模
块
实
时
信
息
管
理
模
块
数
据
管
理
模
块
1.2 需求分析
用户管理模块
用户管理模块包括如下几个部分。
（1） 添加用户信息：管理员可以对用户信息进行添加操作。 （2） 删除用户信息：管理员可以对已有用户信息进行删除操作。
（3） 查看用户信息权限：每个用户都具有一定的权限，管理员可以查看用户的管理权限。 （4） 修改用户信息权限：管理员可以修改用户的管理权限。 （5） 删除管理权限：管理员在权限管理中可以删除管理权限。 （6） 添加管理权限：管理员在权限管理中可以添加管理权限。
系统参数设置模块
系统参数设置模块有如下几个部分。
（1） 用户信息：管理员可以修改用户信息并保存。 （2） 订票信息：对订票信息进行添加、删除操作。 （3） 退订信息：对退订信息进行添加、删除操作。 （4） 旅客订票记录：对旅客订票记录进行添加、删除操作。
（5） 其他信息：对其他信息进行编辑、删除操作。在编辑时可以修改附件存放路径和备份文
件存放路径。
用户管理模块
用户管理 权限管理
添加用户信息 删除用户信息
查看用户信息权限 修改用户信息权限
删除管理权限
查看管理权限 添加管理权限
票务信息模块
票务信息模块包括如下几个部分。
（1） 车次信息：对车次信息进行添加、删除操作。 （2） 列车时间信息：对列车时间信息进行添加、删除操作。 （3） 座位信息：对座位信息进行添加、删除操作。 （4） 价格信息：对价格信息进行添加、删除操作。 （5） 车站信息：对车站信息进行添加、删除操作。
系统参数设置模块
退订信息
订票信息
其他信息
旅客订票记录
用户信息
票务信息模块
车次信息
列车时间信息
座位信息 价格信息 车站信息
订票管理模块
订票管理模块包括如下几个部分。 （1） 用户注册：注册新用户。 （2） 用户登录：已注册用户登录。 （3） 列车信息：浏览可预定车辆信息。 （4） 车票预订：预定车票。
实时信息管理模块
实时信息管理模块包括如下几个部分。
（1） 实时信息查看：在窗口现在最新实时信息。
（2） 实时信息更新：对于最新路况、车况信息进行更新。 （3） 实时信息修改：对于最新路况、车况信息进行修改。
订票管理模块
用户注册 用户登录 列车信息 车票预订
数据管理模块
数据管理模块包括：
（1） 数据查看：对所有数据查看。 （2） 数据备份：备份所有数据。 （3） 数据恢复：恢复受损数据。
实时信息管理模块 实时信息查看 实时信息更
新 实时信息修改
数据管理模块
数据查看 数据备份 数据恢复
1.3 需求模型（用例图）
用户
查询
(from Logical View)
票价
(from Logical View)
订购
(from Logical View)
实时信息提示
(from Logical View)
车况
(from Logical View)
路况
(from Logical View)
退订(from Logical View)
管理员
修改票务信息
(from Logical View)
用户管理
(from Logical View)
修改时间
(from Logical View)
修改票价
(from Logical View)
添加用户信息
(from Logical View)
预定
(from Logical View)
删除用户信息
(from Logical View)
查看用户信息
(from Logical View)
修改用户信息
(from Logical View)
客户先通过网站系统查询各种情况（票的价格，车的情况，以及一些铁路状况），再通过系统数据库给与的实时信息提示去预定想要的火车票，完成订票的过程，客户也可以通过网站系统对自己已经订购的票进行退订手续。
管理员可以通过系统对客户进行管理，查看客户信息，修改客户信息，添加客户信息，以及删除客户信息等等，管理员也可以去修改票务信息，修改变动后的时间以及车票价格等等。
2静态模型
2.1 类图
旅客（姓名、性别、需求信息、有效证件）
列车班次（发车时间、起点、终点、乘坐人数、价格）
火车站（名称、所在地）
订票（票号、班次号、旅客号、票价）
管理员（密码、姓名）
旅客表
字段类型含义说明Customer_Name String() 旅客的名字旅客的名字Customer_Sex Varchar() 旅客的性别旅客的性别Customer_Want Varchar() 旅客的需求旅客的需求信息Customer_Iden Varchar() 旅客的证件旅客的有效证件
班次表
字段类型含义说明Train_Time Time 班次时间列车的发车时间Train_Start Varchar() 班次起点列车的始发站Train_End Varchar() 班次终点列车的终点站Train_Number Int() 班次乘坐人数列车的乘坐人数Train_Price Int() 班次价格本次列车的价格
订火车票表
字段类型含义说明Order_ID Varchar() 订火车票号主键（PK）
Order_FID Varchar() 班次号外键（FK）
Order_CID Varchar() 旅客号外键（FK）
Order_Price Int() 票价外键（FK）
管理员表
字段类型含义说明Admin_password Varchar() 管理员密码管理员密码Admin_Name Varchar() 管理员姓名管理员姓名
火车站表
字段类型含义说明Station_Name Varchar() 火车站名字火车站名字Station_addr Varchar() 火车站所在地火车站所在地
2.2 对象图
1.管理员管理顾客信息，管理车票信息。
customer_sex : customer customer_name :
customer customer_iden :
customer admin_name :
admin
custoner_want :
customer
train_time :
train train_number :
train
train_price :
train
order_price :
order
order_FID : order
customer_name :
customer
order_CID :
order
order_ID : order
train_time :
train train_strat :
train train_number :
train
train_price :
train
2.3 包图
1.创建管理员包，内有管理员类。
2.创建顾客包，内有顾客类。
3.创建订票包，内有订票类。
4.创建车站包，内有车站类，主要是车站信息。
5.创建火车票包，内有车票类，主要为火车票信息。
admin package
customer package
order package
station package
train package
3动态模型
3.1 时序图
: 客户电脑票务信息帐户
1: 联网
2: 网站搜索
3: 检索
4: 显示给客户
5: 选票
6: 输入账号密码
7: 验证账号密码
8: 提交正确并扣钱
9: 显示给客户代码
1.客户首先要使用一台已经联网的电脑
2.在网站上搜索票务信息
3.检索票务信息数据库
4.电脑将检索的信息传递给客户
5.客户经查看信息后进行订票
6.客户输入自己的银行账号
7.系统验证账号正确性
8.提交信息并进行缴费
9.系统给客户票务
: admin
电脑
票务信息客户
车况信息1: 输入管理员帐户及密码
3: 修改票务信息
6: 查看票务信息2: 修改客户信息
8: 预定火车票
5: 客户登陆
4: 修改车况信息
7: 查看车况信息
1.管理员登陆到系统。
2.管理员拥有权限修改票务信息、客户信息、车况信息。
3.用户登陆的网站。
4.用户可以查看票务信息、车况信息。
5.用户预定火车票
3.2 状态图
初始状态
数据库系
统页面
Login
退订页面预定页面
终止状态
成功失败
connected
connected
can't connected
1.进入数据库系统页面
2.进入预定车票界面
3.预定成功后退出
4.进入退订车票界面
5.退订成功后退出
6.不能成功预、退车票则退出
: 客户
电脑
2:网站搜索
票务信息
2: 检票3: 显示票务信息给客户
4: 选票
帐户
1: 联网
5: 输入账号验证提交扣钱
6: 显示票代码给客户
1. 客户首先要连接上网络的电脑
2. 客户进行网站搜索，检索有关的票务信息
3. 电脑将显示的票务信息给予客户
4. 客户再通过查看信息后选择买票
5. 客户输入自己的账号
6. 验证帐户并提交扣钱
7. 电脑将票的代码显示给客户，凭证取票
联网
检索给予客户票务代码
search
订票界面退票界面
预定购票
输入账号
corrent
error
connect
enter
票务数据库系统页面
用户
1.客户先进行网络连接，进入票务数据库信息管理系统页面
2.进入退票界面，客户可以进行退票的操作
3.进入订票界面，客户可以查看票务的实时信息情况
4.检索信息之后，客户进行预定购票
5.进入账号管理系统，输入自己的账号
6.验证后给予客户票的代码，凭证取票
7.结束则退出
《UML技术》课程实验报告 专业： 班级： 学号： 姓名： 日期： 2013 年 10 月 11 日
一、实验题目 活动图及状态图 二、实验目的 1．熟悉活动图的基本功能和使用方法。 2．掌握如何使用建模工具绘制活动图方法。 三、实验内容及原理 通过前面内容的学习，完成了对TJKD图书馆的图书馆管理系统的需求的初步分析，得出系统的用例图和相应的活动态。通过这两类图我们可以初步了解系统的业务处理过程，但对业务处理过程的处理状态间转换了解仍不够，这不利于设计人员对系统业务的进一步理解，而状态图能从对象的动态行为的角度去描述系统的业务活动。因此，指派你运用本节所学的状态图，完成如下任务： 1. 完成图书业务模块中还书用例的状态图。 1．业务分析：由前面章节对图书馆管理系统中的还书主要业务的描述和分析可知，还书业务的动态行为是由：空闲（idle）、图书查找（finding）、还书（reversion）、失败（Failure）、归还成功（Success）5种状态及激活相互转换的事件。 2．绘制状态图：请您根据分析运用UML绘制还书用例的状态图。 分析： 还书的状态图，还书的主要业务都是由管理员来完成，首先管理员必须先登录系统，并通过验证后，便可以进行下一步的操作，查找该书的相关信息，如存在，则进行还书操作，如不存在该信息，则给出提示信息； 四、实验步骤 第一个 （1）在用例图中，找到删除的用例，在删除用例上单击右键，在弹出的快捷菜单中选“New”，Rose 工具也会弹出一个菜单，选”Activity Diagram”，选中后单击，便可以新建好一个活动图。 (2)新建好活动图后，双击删除的活动图，然后把在左边的工具栏内点击“Swinlane“，在右边的图添加一个泳道，并命名为administrator.按照此步骤，再添加另一个泳道，并命名为SystemTool （3）接着在左边的工具上选取开始点，并在administrator的泳道上添加；添加完开始结点后，再来为此活动图添加活动，在左边的工具栏上选中Activity这个图标，在administrator这边的泳道上添加一个活动，命名为登录（login），再在开始结点和活动登录（login）之间添加活动关系 （4）完成步骤（2）后，登录输入需要对输入的信息进行验证，则在图中添加一个验证框结束（5）验证后，下一步的操作是查询需要删除的记录，添加一个活动，命名为delete （6）最后，在删除后，系统会返回操作结果给操作者；删除成功或删除失败系统都会有信息返回给操作者。 （7）根据分析设计情况，进一步添加或细化活动图 第二个 （1）在用例图中的还书（revesion）用例，单击右键，新建一个状态图，命名为revesion状态图，（2）双击“receivesion”状态图，展开后，在左边的工具栏上选取一个实心圆点，此结点为开始结点；当还书的时候，操作者先要询问系统的状态，如果系统忙，操作者则必需等待，因此，得到系统的两种状态
UML用例图 用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块。展示了一个外部用户能够观察到的系统功能模型图。 用例图中涉及的关系： 1》泛化(Inheritance) 就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用 例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。 2》包含(Include) 包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。 3》扩展(Extend) 扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。
包含(include)、扩展(extend)、泛化(Inheritance)的区别： 条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的； 直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include 中被包含的用例为参与者提供间接服务。 对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内 容。 对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的 关系； UML类图 类名：如果是抽象类，则采用斜体（继承用实线）
'. 1》接口的表示： 一个类和一个接口不同：一个类可以有它形态的真实实例，然而一个接口必须至少有一 个类来实现它。在 UML 2 中，一个接口被认为是类建模元素的特殊化。因此，接口就象类 那样绘制，但是长方形的顶部区域也有文本“interface”。 2》UML 支持的可见性类型的标志 标志可见性类型 +Public #proteted -private ~package 3》多重值和它们的表示 可能的多重值描述 表示含义 0..1 0个或1个 1只能1个 0..*0个或多个 * 0个或多个 1..*1个或多个 3只能3个 0..50到5个 5..15 5到15个
一、类图主要构成元素 1.类（Classes） 类包含3个组成部分。第一个是Java中定义的类名。第二个是属性（attributes）。第三个是该类提供的方法。 属性和操作之前可附加一个可见性修饰符。加号（+）表示具有公共可见性。减号（-）表示私有可见性。#号表示受保护的可见性。省略这些修饰符表示具有package（包）级别的可见性。如果属性或操作具有下划线，表明它是静态的。在操作中，可同时列出它接受的参数，以及返回类型，如下图所示： 2.包（Package） UML类图中包是一种常规用途的组合机制。UML中的一个包直接对应于Java中的一个包。在Java中，一个包可能含有其他包、类或者同时含有这两者。进行建模时，你通常拥有逻辑性的包，它主要用于对你的模型进行组织。你还会拥有物理性的包，它直接转换成系统中的Java包。每个包的名称对这个包进行了惟一性的标识。 3.接口（Interface） 接口是一系列操作的集合，它指定了一个类所提供的服务。它直接对应于Java中的一个接口类型。接口既可用下面的那个图标来表示（上面一个圆圈符号，圆圈符号下面是接口名，中间是直线，直线下面是方法名），也可由附加了<
UML实践----用例图、顺序图、状态图、类图、包图、协作图 2009-01-20 作者：Randy Miller 来源：网络 面向对象的问题的处理的关键是建模问题。建模可以把在复杂世界的许多重要的细节给抽象出。许多建模工具封装了UML（也就是Unified Modeling Language?），这篇课程的目的是展示出UML的精彩之处。 UML中有九种建模的图标，即： ?用例图 ?类图 ?对象图 ?顺序图 ?协作图 ?状态图 ?活动图 ?组件图 ?配置图 本课程中的某些部分包含了这些图的细节信息的页面链接。而且每个部分都有一个小问题，测试一下你对这个部分的理解。 为什么UML很重要？ 为了回答这个问题，我们看看建筑行业。设计师设计出房子。施工人员使用这个设计来建造房子。建筑越复杂，设计师和施工人员之间的交流就越重要。蓝图就成为了这个行业中的设计师和施工人员的必修课。 写软件就好像建造建筑物一样。系统越复杂，参与编写与配置软件的人员之间的交流也就越重要。在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”。现在它已经成为了软件行业的一部分了。UML提供了分析师，设计师和程序员之间在软件设计时的通用语言。 UML被应用到面向对象的问题的解决上。想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的。一个模型model就是根本问题的抽象。域domain就是问题所处的真实世界。 模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的。记住把一个对象想象成“活着的”。对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）。对象的属性的值决定了它的状态state。 类Classes是对象的“蓝图”。一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）。对象是类的实例instances。 用例图 用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象。强调这个系统是什么而不是这个系统怎么工作。 用例图与情节紧紧相关的。情节scenario是指当某个人与系统进行互动时发生的情况。下面是一个医院门诊部的情节。 “一个病人打电话给门诊部预约一年一次的身体检查。接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录。”
父用例通常是抽象的。
1 一个类和一个接口不同：一个类可以有它形态的真实实例，然而一个接口必须至少有一个类来实现它。在 UML 2 中，一个接口被认为是类建模元素的特殊化。因此，接口就象类那样绘制，但是长方形的顶部区域也有文本“interface”。 2》UML 支持的可见性类型的标志 3》多重值和它们的表示
4》类图之间的关系有：泛化（继承），依赖，关联，聚合/组合。 1.聚合/组合 聚合是一种特别类型的关联，用于描述“总体到局部”的关系。在基本的聚合关系中，部分类的生命周期独立于整体类的生命周期。 举例来说，我们可以想象，车是一个整体实体，而车轮轮胎是整辆车的一部分。轮胎可以在安置到车时的前几个星期被制造，并放置于仓库中。在这个实例中，Wheel类实例清楚地独立地Car类实例而存在。然而，有些情况下，部分类的生命周期并不独立于整体类的生命周期-- 这称为合成聚合。举例来说，考虑公司与部门的关系。公司和部门都建模成类，在公司存在之前，部门不能存在。这里Department类的实例依赖于Company类的实例而存在。 ·基本聚合（聚合） 有聚合关系的关联指出，某个类是另外某个类的一部分。在一个聚合关系中，子类实例可以比父类存在更长的时间。为了表现一个聚合关系，你画一条从父类到部分类的实线，并在父类的关联末端画一个未填充棱形。 图中清楚的表明了类Car对象包含了另一类Wheel的4个实例，这两者在概念上是密不可分的，其中的一个类是另一个类的构成成分。菱形表示“包含”，箭头表示被包含的对象，数字4表示包含的数目。 ·组合聚合（组合） 组合聚合关系是聚合关系的另一种形式，但是子类实例的生命周期依赖于父类实例的生命周期。 注意:组合关系如聚合关系一样绘制，不过这次菱形是被填充的。 2.依赖 依赖可以说是要完成C5里的所有功能，一定要有C6的方法协助才行 3.关联 可以分为单向关联，双向关联
统模语言UML 课程设计报告 指导老师: 班级: 学号: : 完成日期：
【课程设计名称】网络教学系统-使用UML进行系统的分析和设计 【课程设计目的】1.掌握UML建模的基础知识和其应用； 2.熟悉Rational Rose环境及功能,能够设计出完整系统。 【课程设计要求】1.对系统功能进行必要的描述； 2.绘制系统的主要模型图； 3.模型图要有说明性文字解释。 【课程设计容】1.网络教学系统的需求分析； 2.网络教学系统UML建模。 【课程设计步骤】 一: 网络教学系统的需求分析 1、系统功能需求 （1）学生可以登陆浏览和查找各种信息以及下载文件。 （2）教师可以登陆给出课程见解、发布、修改和更新消息以及上传课件。 （3）系统管理员可以对页面进行维护和批准用户的注册申请。 满足上述需求的系统主要包括下面几个模块 （1）数据库管理模块：提供使用者录入、修改并维护数据的途径。 （2）基本业务模块：教师可以上传文件、发布消息、修改和更新消息；学生可以下载文件；管理员可以维护页面，批准注册等。 （3）信息浏览、查询模块：主要用于对的信息进行浏览、搜索查询。 图 1.1系统功能需求 2、数据库管理模块 图 1.2数据库管理模块 （1）教师信息管理：负责教师信息的管理。 （2）课程简介信息管理：负责课程简介信息的管理。 （3）文件上传信息管理：负责文件上传信息的管理。
3、基本业务模块 图 1.3基本业务模块 （1）文件上传：教师可以使用此模块将课程的数据上传到服务器。 （2）文件下载：学生可以使用此模块从上下载课件及其他资料。 （3）消息发布：教师可以通过此模块发布学习方法、课程重点等和教学相关的文章，以及和课程相关的通知等。 （4）消息修改和更新：教师可以通过此模块对自己发布的信息进行修改和更新。 （5）页面维护：管理员可以使用此模块对的页面进行维护。 （6）用户注册批准：管理员可以使用此模块批准用户注册。 4、信息浏览、查询模块 图 1.4信息查询模块功能 （1）网页信息浏览：用户浏览信息。 （2）文章信息搜索：用户根据关键字搜索文章。 二: 系统的UML建模 1、系统的用例图 创建用例图之前首先需要确定参与者。 ①在网络教学系统中，需要学生和教师的参与。学生可以浏览课程简介，教学计划，学习方法等教 师发布的文章，并可以根据关键字查询文章。此外，学生可以从上下载课件。教师作为教学的主导者，使用此可以发布学习方法，课程重点等和教学相关的文章，以及和课程相关的通知等，还可以将某一门课程的课件上传。 ②需要一个专门的管理者进行日常维护与管理，所以需要有系统管理员的参与。 （1）系统用户参与的总的用例图 教师和学生都可以从“用户”这个参与者泛化而来，用户是指的注册用户，注册用户可以登录系统完成相应的操作。 系统用户参与的总的用例图如图所示。从图中可以清楚地看到泛化关系与各个参与者所参与的用例。
软件工程的5个阶段：需求分析(Requirements Capture)，系统分析与设计(System Analysis and Design)，实现(Implement)，测试(Test)，维护(Maintenance)。 2.UML的定义包括UML语义和UML表示法两个部分。UML语义描述基于UML 的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致和通用的定义性说明。UML表示法，为开发者或开发工具使用图形工具和文本语法为系统建模提供了标准。 3.UML(Unified Modeling Language)由视图(View)，图(Diagram)，模型元素(Model Element)，通用机制(General Mechanism)等组成，还提供了扩展机制(Extension Mechanism)，使得UML语言能够适应一个特殊的方法或者扩充到一个组织或用户。 a)视图是表达系统的某一方面特征的UML建模元素的子集，由多个图构成，是在某一个抽象层上，对系统的抽象表示。 b)图是模型元素集的图形表示，通常由弧(关系)和顶点(其他模型元素)相互连接构成。 c)模型元素代表面向对象中的类、对象、消息和关系等概念，是构成图的基本概念。 d)通用机制用于表示其他信息，比如注释、模型元素的语义等。 4.UML用模型来描述系统的结构或静态特征，以及行为或动态特征，从不同的视角为系统架构建模，形成不同视角： a)用例视图(Use Case View)，强调从用户角度看到的或需要的系统功能，是被称为参与者的外部用户所能观察到的系统功能的模型图。 b)逻辑视图(Logical View)，展现系统的静态或结构组成及特征，也被称为结构模型视图(Structural Model View)或者静态视图(Static View)。 c)并发视图(Concurrent View)，体现了系统的动态或者行为特征，也称为行为模型视图(Behavioral Model View)或动态视图(Dynamic View)。 d)组件视图(Component View)，体现了系统实现的结构和行为特征，也称为实现模型视图(Implementation Model View)。 e)配置视图(Deployment View)，体现了系统实现环境的结构和行为特征，也被称为环境模型视图(Environment Model View)或者物理视图(Physical View)。 5.视图由图构成，UML提供了9种不同的图： a)用例图(Use Case Diagram)，描述系统功能；
一．UML简介 UML（统一建模语言，Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。其实简单的理解，也是个人的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。 二．用例建模简介 用例建模是UML建模的一部分，它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为。依我的理解用例建模可分为用例图和用例描述。用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例，用文本文档来完成。 1．用例图 参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。 用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。 系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
本文和大家重点讨论一下UML活动图和状态图的概念，这两种图都有各自的特点和作用，那么他们之间有什么区别和联系呢，请看本文详细介绍。 UML活动图和状态图 一、UML活动图： ◆流程图常被用来建立算法模型 ◆UML活动图与流程图类似，不同在于它支持并行活动. ◆缺点：不能清楚的表示 二、作用： 1、描述一个操作的执行过程中所完成的工作或者动作 2、描述对象内部的工作 3、描述用例的执行 4、处理多线程 5、显示如何执行一组相关的动作，以及这些动作如何影响周围对象 三、以下情况不用UML活动图 1、显示对象之间的合作 2、显示对象在其生命周期内的运转情况。 这两点是通过序列图和协作图完成的。 四、UML活动图的基本要素： ◆活动状态 ◆活动状态之间的转移（箭头） ◆判断（决策点） ◆保证条件 ◆同步条：活动之间的同步 ◆起点和终点 --起点有且只有一个，终点可以有n个。 五、泳道： 用于对UML活动图中的活动进行分组，用于描述对象之间的合作关系。 ----所谓泳道技术，就是将活动用线分成一些纵向区域，这些纵向区域称为泳道。 UML状态图 一、状态图： ◆描述一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态之间的转换。例如呼叫中心系统。
◆状态图符 --状态：矩形（四角圆弧） --转移 --起点 --终点 1、状态机： ◆一种行为：描述了一个对象或一个交互在生命周期内响应事件所经历的状态序列。 ◆单个类或者一组类之间协作的行为可以用状态机来描述 ◆一个状态机涉及到一些其他元素，包括状态、转换、事件 2、状态： 在对象的生命周期中满足某些条件、执行某些活动或等待某些事件的一个条件活状况。1）名称 2）进入协作和退出动作 3）内部转换 4）子状态 5）延迟事件 3、转换：两个状态之间的一种关系，表示对象将在第一个状态中执行一定的动作并在某个特定事件发生而某个特定条件满足时进入第二个状态。 1）源状态 2）事件触发 3）监护条件 4）动作 5）目标状态 例子：电话机状态图 二、UML活动图与状态图的区别： 状态：行为的结果 活动：行为的动作 在uml中图符不一样。 注意：实际项目中，UML活动图不是必须的。 用到UML活动图的情况： --描述并行的过程或这行为 --描述一个算法 --描述一个跨越多个用例的活动 状态图描述了一个具体对象的可能状态以及他们之间的转换。 单独的说UML活动图很抽象，但是当把UML活动图与流程图进行简单的比较之后就
内容： UML状态图和活动图的绘制 作业提交时间：20 年月日 姓名：学号：班级：计算机短号： 1 在操作系统中，进程包括就绪、运行、阻塞、挂起等状态，以及初态就绪和程序运行结束后的终态。就绪状态获得CPU时间片转为运行态；运行态时间片用完转为就绪态；运行态不满足所需资源转为阻塞态，阻塞态若资源满足则回到就绪态。考虑到内存空间，还有挂起和唤醒行为。请结合操作系统上上述相关知识，给出一般进程的可能的状态图，并要求给出每个状态具体的进入工作、退出动作以及驻留改状态时可能执行的动作。 答：首先确定好进程的基本状态以及个状态之间的转换关系。 进程的基本状态：就绪，运行，阻塞，挂起，终止。 进程各个状态之间的转换关系如下图所示： 2 在图书管理系统中，"新增读者信息"用例属于读者信息管理中的一个功能，主要用于在系统中增加新的读者信息，其具体的办理流程是：（1）"读者"填写申请表，并交给"图书管理员"； （2）"图书管理员"将申请表中的信息通过录入界面，输入到图书管理系统；（3）系统中的"业务逻辑"组件将判断输入的信息是否合法； （4）如果不合法则转入步骤（5），否则转入步骤（6）; （5）显示"添加错误信息"，转到（8）； （6）在“数据库”添加相信的用户信息； （7）显示"添加成功信息"；
（8）结束。 请绘制该过程的活动图。 答： 按照题目要求画出读者增添信息活动图如下所示： 作业心得： 通过本次作业更深的了解了状态图和活动图的基本概念。结合实际问题画出对应的状态图和活动图给人一种特别形象的流程感觉。通过开始到结束之间的状态之间的转换关系清楚的体现出一个工作的循序以及各种判断。两种图主要用于描述用例内部的工作流程。显示如何执行一组相关的动作，以及这些动作如何影响周围对象的基本路线。在此过程当中更进一步的掌握了如何使用建模工具的方法和思路。特定对象的所有可能状态以及由于各种事件的发生而引起的状态之间的转换充分展示一各活动的全部层面。 教师评语：
?UML需求分析步骤实例解析 在UML使用过程中，经常会遇到UML需求分析问题，这里就向大家介绍一下UML的需求分析大致步骤，为了便于大家理解以实例向大家介绍，希望通过本文的介绍你对UML需求分析步骤有所了解。 本节向大家介绍一下UML需求分析的一般步骤，本节用实例向大家介绍，相信通过本节的介绍你对UML需求分析有一定的认识。下面让我们一起来学习具体介绍吧。 基于UML需求分析 在初步的业务需求描述已经形成的前提下，基于UML需求分析大致可分为以下步骤： （1）利用用例及用例图表示需求。从业务需求描述出发获取执行者和场 景；对场景进行汇总、分类、抽象；形成用例；确定执行者与用例、用例与用例图之间的关系，生成用例图。 （2）利用包图及类图表示目标软件系统的总体框架结构。根据领域知识、业务需求描述和既往经验设计目标软件系统的顶层架构；从业务需求描述中提取“关键概念”，形成领域概念模型；从概念模型和用例出发，研究系统中主要的类之间的关系，生成类图。 上述两个步骤并没有时序关系，它们可以并行展开，如图5-3-1所示。 图5-3-1 UML需求分析过程
本节将依次介绍上述步骤中涉及的UML语言机制，并结合“家庭保安系统”实例说明每步骤中基于UML需求分析方法。 开发场景 场景是指从单个执行者的角度观察目标软件系统的功能和外部行为。这种功能通过系统与用户之间的交互来表征。因此也可以说，场景是用户与系统之间进行交互的一组具体的动作。相对于用例而言，场景是用例的实例，而用例是某类场景的共同抽象。 对场景的完整描述应包含场景名称、执行者实例，前置条件、事件流和后置条件。 例如，“家庭保安系统”的初步需求描述：“家庭保安系统”的软件允许用户在安装时进行系统配置，实施对传感器的监控并通过控制面板与用户进行信息交互。 配置操作包括： （1）指定每一传感器的种类和编号； （2）设置开、关机密码； （3）指定报警电话电码； （4）指定报警延迟和电话重拨延迟时间（以秒为单位）； 当软件系统收到传感器发出的数据后，判别是否出现异常事件。如果是，则在指定的延迟时间内拨报警电话号码，拨号操作将按照重拨延迟反复进行，直至电话接通。然后软件系统负责报告时间、地点和异常事件的性质。 开机后，软件系统负责显示当前工作状态，接收并处理用户指令。 根据以上描述，该系统具有“系统配置”、“开机”、“关机”、“门窗监测”、“烟雾监测”和“复位”等场景。其中，门窗监测场景的具体描述如下： 场景名称：门窗监测。 参与执行者实例：警报器、报警电话、显示器和门窗监视器。 前置条件：系统已开机。 事件流： （1）门窗监视器发现门或窗户发生异动，向软件系统报告异常事件。
湖南文理学院实验报告 课程名称：UML建模技术实验 实验名称：UML状态图和活动图的设计成绩： 学生姓名：傅湘黔专业：计算机科学与技术班级、学号： 201017010220 同组者姓名：实验日期： 一、实验目的： ①掌握状态的设计、名字域、转移域、动作域的设计、状态转移的设计； ②掌握状态图和活动图的设计。 二、实验原理： 时序图（Sequence Diagram），亦称为序列图或顺序图，是一种UML行为图。它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。它可以表示用例的行为顺序，当执行一个用例行为时，时序图中的每条消息对应了一个类操作或状态机中引起转换的触发事件。时序图描述对象是如何交互的，并且将重点放在消息序列上。也就是说，描述消息是如何在对象间发送和接收的。 所谓协作是指在一定的语境中一组对象以及用以实现某些行为的这些对象间的相互作用。它描述了在这样一组对象为实现某种目的而组成相互合作的“对象社会”。协作图就是表现对象协作关系的图，它表示了协作中作为各种类元角色的对象所处的位置，在图中主要显示了类元角色（Classifier Roles）和关联角色（Association Roles）。类元角色描述了一个对象，关系角色描述了协作关系中的链。 与序列图中明确表示了角色之间的关系，通过协作角色来限定协作中的对象和链接。另一方面，协作图不将时间作为单独的维来表示，所以必须使用顺序号判断消息的顺序以及并行线程。序列图和协作图表达的是类似的信息，虽然它们使用的不同的方法表示，但是可以通过适当的方式将它们进行转换。 三、实验内容： ①通过对BBS论坛系统的需求分析，绘制状态图； ②通过对BBS论坛系统的需求分析，绘制活动图。 具体内容如下： （一）BBS论坛系统的需求分析 1、系统功能需求 （1）从前台用户和游客角度，系统应包括：用户注册，用户登录，浏览文章，发表文章，帖子查询。 （2）从论坛管理员角度：会员管理，帖子管理，论坛分类管理，帖子分类。
用例图： 描绘不同系统用户群是如何同这个系统交互。用例定义和描述用户从系统中获取价值的各种方法。 创建一个用例模型需要三个步骤： 1 确定使用这个系统的人群 2 确定这些人群是如何从系统中获取价值 3 用一个简单易懂的视图来描述这些用户以及他们如何使用系统 第一步： 寻找参与者(actor) 确定使用该系统的各种人群，一种人群称为参与者(actor)，使用这个系统或被这个系统使用的其他系统也是参与者。 参与者定义：指在某个系统的外部并和该系统交互的一群人或一个系统。 例：下列小组都是参与者 1 银行客户和柜员分别是单独的参与者，因为他们有着不同的需求和权限 2 大多数游戏系统中，男人和女人没必要分成单独的参与者 3 学生和登记管理员是单独的参与者，有不同的需求和访问 第二步： 寻找用例(use case) 系统为参与者提供一个独立的价值所采用的方式称之为用例. 用例必须是集中的，并有一个明确的目标 如果用例满足以下条件，则是集中的： 1 用例应带来独立的好处 2 可以用20-30个单词来描述这个好处 3 参与者能通过一次会话完成该用例 例： 银行系统有输入帐号、选择帐号、取款、存款、选择源帐号、选择目标帐号、资金转移等功能，如果将这些动作都作为用例则显得太细，不能满足独立条件。比如，没有一个用户会在选择一个帐号后就满意的离开！但是，如果只为一个用例---资金管理，则又显得太笼统。好的用例应提供一个具体的用途！ 取款、存款、转账等都可以是好的用例，均提供了具体的用途！ 第三步 描述参与者与用例 UML中，参与者用棒形人表示，用例用带标记的椭圆来表示 参与者指向用例的带箭头的实线表示这个参与者触发该用例，比如：
UML各种图例 面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language?），这篇课程的目的是展示出UML的精彩之处. UML中有九种建模的图标，即： ?用例图 ?类图 ?对象图 ?顺序图 ?协作图 ?状态图 ?活动图 ?组件图 ?配置图 本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解. 为什么UML很重要? 为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成为
了这个行业中的设计师和施工人员的必修课. 写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言. UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界. 模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state. 类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances. 用例图 用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作. 用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节. “一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.” 用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）
UML中的用例(Use Case)概念分析及实例 文/登峰 2005-02-25 在UML中use case似乎最簡單的，用例建模的最主要功能就是用来表达系统的功能性需求或行为，依我的理解用例建模可分为用例图和用例描述。用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例，用文本文档来完成，以及由箭头所组成的各种关系，包括泛化，包含，扩展等。本文准备向大家介绍以下内容,所有图示均用PowerDesigner所画. ◆用况 ◆参与者 ◆泛化 ◆<
参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。 ３．泛化 泛化和类中的泛化概念是一样的，子用况继承父用况的行为和含义，还可以增加或覆盖父用况的行为;子用况可以出现在任何父用况出现的位置（父和子均有具体的实例）。下面给出两种图示来说明泛化的概念和含义 图２含义继承图３行为继承 ４．<
UML 用例图：准则 在 Visual Studio 旗舰版中，可以绘制“用例图”来概括使用您的应用程序或系统的用户以及该应用程序或系统的用途。若要创建 UML 用例图，请在“体系结构”菜单上，单击“新建关系图”。 用例图有助于讨论和传达以下内容： 您的系统或应用程序与人、组织或外部系统进行交互的几种方案。 它帮助参与者实现的目标。 系统的范围。 用例图不显示用例的详细信息：它只概括用例、参与者和系统之间的某些关系。特别是，用例图不显示每个用例为实现目标所执行步骤的顺序。可以在其他关系图和文档中描述这些详细信息，这些关系图和文档可与各用例相链接。有关更多信息，请参见本主题中的详细描述用例。 您为用例提供的描述将使用与系统所用于的领域相关的一些词汇，如“销售”、“菜单”、“顾客”等。明确定义这些词汇及其关系是非常重要的，您可以借助 UML 类图来进行定义。有关更多信息，请参见 UML 类图：准则。 用例只处理系统的功能要求。诸如业务规则、服务质量要求和实现约束等其他要求必须另外表示。体系结构和内部细节也必须另外说明。有关如何定义用户需求的更多信息，请参见用户需求建模。 本主题中使用的示例与顾客可在其上从本地餐馆订餐的网站有关。
“参与者”(1) 是与您的系统进行交互的一类人、组织、设备或外部软件组件。例如，“顾客”、“餐馆”、“温度传感器”、“信用卡授权方”都是参与者。 “用例”(2) 表示一个或多个参与者为实现特定目标而执行的操作。例如，“订餐”、“更新菜单”、“处理付款”都是用例。 在用例图中，用例与执行它们的参与者相关联 (3)。 “系统”(4) 是您开发的任何成果。系统可以是小型软件组件，其中的参与者只是其他软件组件；系统也可以是完整的应用程序；系统还可以是部署在多台计算机和设备上的大型分布式应用程序套件。例如，“订餐网站”、“送餐业务”、“网站版本 2”都是子系统。 用例图可以显示系统或其子系统支持的用例。 主题内容 绘制用例图的基本步骤 绘制参与者和用例 详细描述用例 结构化用例 使用子系统边界 绘制用例图的基本步骤
《UML 面向对象分析》课程 实践项目报告 项目名称：网上订购火车票系统 项目组成员：学号：班级：指导教师： 2008年 11 月 10 日 目录 1 需求分析 .................................................................................... 1 1.1 需求概述 ............................................................................ 1 1. 2 需求分 析 ............................................................................ 2 1.3 需求模型（用例 图） ........................................................ 6 2 静态模 型 .................................................................................... 7 2.1 类 图 .................................................................................... 7 2.2 对象 图 ................................................................................ 9 2.3 包 图 .................................................................................. 11 3 动态模 型 .................................................................................. 12 3.1 时序 图 .............................................................................. 12 3.2 状态 图 .............................................................................. 15 3.3 协作 图 .............................................................................. 16 3.4 活动 图 .............................................................................. 17 4 项目组成员分工说 明 .............................................................. 18 5 总 结 .......................................................................................... 19 6 参考资 料 (20) 1 需求分析 1.1 需求概述
面向对象分析与设计课程实验考核大作业报告
目录 实验一用例图 (3) 实验二活动图 (8) 实验三状态图 (16) 实验四类 (22) 实验五类的关系 (29) 实验六、七交互图 (33) 实验八、九对象图和包 (41) 实验十、十一组件图和部署图 (43)
实验一用例图 一、实验目的 1．熟悉用例图的基本功能和使用方法。 2．掌握如何使用建模工具绘制用例图方法。 二、实验器材 1．计算机一台。 2．Rational Rose 工具软件。 三、实验内容 根据某图书管理系统开发进度，在完成对系统的需求建模，得到用例模型后，应针对每个用例进行业务分析，说明其具体的业务流程，现系统分析部指派您完成该项任务。要求：对其中主要功能的用例书写书面用例。 四、实验步骤 书写“删除读者信息”用例的书面用例。一般应包含以下信息： （1）管理员在录入界面，输入待删除的读者名； （2）“业务逻辑”组件在数据库中，查找待删除的读者名； （3）如果不存在，则显示出错信息，返回步骤（1），如果存在则继续； （4）“业务逻辑”组件判断“待删除的读者”是否可以删除； （5）如果不可以，则显示出错信息，返回步骤（8），如果可以则继续； （6）在数据库中，删除相关信息； （7）显示删除成功信息； （8）结束。 分析: 在图书管理系统中,管理员首先登录系统,系统验证通过后,管理方可向系统查询数据,在查询后,系统会给出提示,有没有找到相关的数据,管理员根据系统查询的返回结果,进行下一步的操作,就是删除读者,在删除的过程中,系统会对查询得到的结果判断该记录是否可以删除,若可以删除,则给删除提示,若不能删除,也给相关的提示信息。 绘图步骤: (1)在用例图上双击main,出现如图1.1所示,为绘制用例图做好准备。