第一篇：基于UML的综合设计--图书馆
实验三 基于UML的综合设计
[实验名称]
基于UML的综合设计 [实验目的]
1、熟练使用Rational rose2003或其它UML建模工具。
2、综合应用用例图、类图、序列图、活动图和状态图进行面向对象的分析和设计。
[实验内容] 题目：图书管理系统的分析和设计
描述：在一个图书馆中，书可外借1个月，期刊可外借3天，学生可以预约已被借出的书。当一本书被归还时，如果已经有学生预约了这本书，则这本书将放在大厅中的借书处，否则放回书库。倘若过了预约期限还没有人来取，预约的书也将放回书库。图书馆工作人员由1位领导、20位正式的图书管理员和10位学生图书管理员（帮助大厅借书处或书库中工作的正式图书管理员）组成。在任何时候，大厅中的借书处有两位正式的图书管理员、两位学生管理员以及另外可能是领导、学生图书管理员或正式图书管理员的人。正式图书管理员负责监督学生图书管理员并向领导汇报工作。该图书馆准备开发一个图书借阅系统，学生可以利用该系统借书。在使用该系统时，如果想借的书在图书馆，这本书将借给借阅者。该系统由一个扩展版供图书馆管理员们维护图书馆的数据库并跟踪借阅情况和发送过期通知。
完成：
1）给出学生使用该系统的用例图； 2）给出描述学生借书的序列图； 3）给出描述图书馆中工作人员的类图； 4）给出一本书在流通过程中的状态图； 5）为每个用例制作活动图。1.学生使用用例图
借书/还书预定/解除预定图书检索图书信息管理图书订购借阅信息查询个人信息查询/修改读者信息管理 读者借阅超期罚款 图书管理员系统管理
2.学生借书的序列图
图书管理员读者信息图书信息修改图书借出刷卡进入并选书核对读者信息 图书扫描并消磁修改读者借阅信息 3.图书馆中工作人员的类图
4.活动图。
：图书管理员：借出窗口：书目：书籍：借阅者：借出书籍1：登录系统（）2：查询书目（）3：查找书籍（书目）4：Available5：鉴定借阅者（）6：建立预约（）
三.实验心得
这次实验让我学会了很多的知识。
第二篇：基于UML的图书馆管理系统建模设计
基于UML的图书馆管理系统建模设计
一、图书馆管理系统可行性分析
随着政府机关与广大企事业单位内部网络的广泛建立，在通用信息平台上构筑高效实用的协同工作和自动化办公应用系统，满足信息高度共享和即时发布的需求，有效实现内部知识管理，已成为众多用户的共同需求。
该图书管理系统，为图书馆管理提供了一个较好的解决方案。在开发过程中，按照软件工程的步骤，从设计到开发采用了面向对象的思想和技术，采用了SQL SERVER 2000数据库，使得本系统可以方便的和其他子系统进行数据交换。同时，注意从软件的图形应用界面上优化软件质量，使得本系统具有很强的可操作性。
二、需求分析
需求分析的目的是深入描述软件功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求。2．
1、客户需求分析
①能够对图书进行注册登记，也就是将图书的基本信息（如：书的编号、书名、作者、价格等）预先存入数据库中，供以后检索。
②能够对借阅人进行注册登记，包括记录借阅人的姓名、编号、班级、年龄、性别、地址、电话等信息。
③提供方便的查询方法。如：以书名、作者、出版社、出版时间（确切的时间、时间段、某一时间之前、某一时间之后）等信息进行图书检索，并能反映出图书的借阅情况；以借阅人编号对借阅人信息进行检索；以出版社名称查询出版社联系方式信息。
④提供旧书注销功能，对于淘汰、损坏、丢失的书目可及时对数据库进行修改。
⑤能够对使用该管理系统的用户进行管理，按照不同的工作职能提供不同的功能授权。⑥对所借图书情况进行登记，包括借阅时间、借阅人等 ⑦对超出借阅时间、损坏或丢失图书的读者进行相应处理 ⑧读者可以查询自己的信息 ⑨借书、还书、续借书
2．2 定义系统的边界和范围 该系统的边界为学校的图书馆
该系统的范围可包括“读者管理子系统”、“书籍管理子系统”、“借阅管理子系统”、“系统管理子系统” 2.3确定执行者
根据前面介绍的客户需求分析可以看出。“图书馆管理系统”有三个执行者，即“读者”、“图书管理员”、“系统管理员”
1）2）读者：查询个人信息、查询图书信息、借阅图书、返还图书、续借图书、接受相应处理
图书管理员：借书处理、还书处理、新旧书登记处理、办理相应处理手续
3）系统管理员：系统维护工作——学生信息管理、图书信息管理、系统状态维护 2.4确定用例
（1）“图书馆管理系统”中的用例
在第一层，根据客户对“图书馆管理系统”的整体业务功能要求，可选的用例有：
·基本业务功能管理
·基本数据修改 ·信息查询
·数据库管理
（2）“基本业务功能子系统”中的用例
在第二层，客户对“基本业务功能子系统”的整体业务功能要求，可选的用例有： ·借阅管理 ·借书
·续借书 ·还书
（3）“基本数据修改功能子系统”中的用例
在第二层，客户对“基本数据修改功能子系统”的整体业务功能要求，可选的用例有： ·读者信息管理 ·读者信息录入 ·读者信息修改 ·读者信息注销 ·书籍信息管理 ·书籍信息录入 ·书籍信息修改
·书籍信息注销（4）“信息查询子系统”中的用例
在第二层，客户对“信息查询子系统”的整体业务功能要求，可选的用例有： ·图书信息查询 ·读者信息查询
（5）“数据库管理子系统”中的用例
在第二层，客户对“数据库管理子系统”的整体业务功能要求，可选的用例有： ·借阅管理 2.5分层绘制用例图
根据系统需求分析中客户对系统的功能要求，我们一确定了系统和子系统的边界、执行者和用例，现在就可以绘制用例图了。
1． 最高层用例图
根据客户对“图书馆管理系统”的整体业务功能要求，可以绘制如图1-1所示的最高层用例图 2． 第2层用例图
在第2层用例图中包括四个用例图：基本业务功能子系统、基本数据修改功能子系统、信息查询子系统、数据库管理子系统。如下图所示：
System<
System读者信息销毁<
System借阅管理系统管理员图1-5 数据库管理子系统
2.6 描述用例
1．“借书”用例
用例编号：0102（共有两层用例图，每层用2位数字表示，采用4位编号）用例名：借书
执行者：直接执行者：图书管理员，涉及到的执行者有：读者、系统管理员 目的：借阅图书
过程描述：
（1）图书管理员登陆基本数据修改功能子系统，点击“借阅管理”中的“借阅”（2）输入图书证编号
若输入不正确，则提示“您输入的借阅证号码有误，请重新输入！”；输入正确后，显示读者已借阅图书信息，提示超期未归还的图书；（3）输入图书编号
若读者已借满，提示“您已借满，请先归还部分图书再来借，谢谢！”；若读者可以正常 4 借阅，提示“您确定要借阅这本书吗？”
（4）确定借阅图书，则借阅证号增加一条借阅信息记录；读者选择 “放弃”，回到步骤（3）重新选择图书；
（5）读者成功借阅图书，系统管理员保存借阅记录并修改库存图书数量、读者借出数量。
（6）借阅完成，点击“退出”，退出系统。2．“还书”用例 用例编号：0103 用例名：还书
执行者：直接执行者：图书管理员，涉及到的执行者有：读者、系统管理员 目的：归还图书 过程描述：
（1）图书管理员登陆基本数据修改功能子系统，点击“借阅管理”中的“还书”；（2）输入图书证编号；
若输入不正确，则提示“您输入的借阅证号码有误，请重新输入！”；输入正确后，显示读者已借阅图书信息，提示超期未归还的图书，有超期未还的图书，调用“超期罚款”；若读者说自己丢失图书，调用“丢失罚款”
（3）输入要还的图书编号； 若输入错误，提示“您未借阅该图书！” 若输入正确，提示“您确定要归还这本书吗？”（4）读者选择“确定”，读者借阅的图书信息记录消失；读者选择 “放弃”，返回到步骤（3）
（5）完成还书，点击“退出”，退出系统；
（6）读者成功归还图书，系统管理员删除借阅记录，并修改数据库管理子系统的图书数量和读者借出数量。
3．“读者信息录入”用例
用例编号：0302 用例名：读者信息录入
执行者：直接执行者：系统管理员，间接执行者：读者 目的：录入新读者相关信息，包括姓名、身份、学院 过程描述：
（1）系统管理员登陆基本数据修改功能子系统，点击“读者信息录入”（2）写入读者相应信息，将读者信息保存至数据库
（3）发放图书证
（4）创建完成，读者信息录入成功，在数据库管理子系统增加图书信息，退出系统
4．“读者信息注销”用例 用例编号：0303 用例名：读者信息销毁
执行者：直接执行者：系统管理员，间接执行者：读者
目的：当读者由于工作地点变化或其他原因，无需再使用图书馆的图书资料时，应当为其办理注销
过程描述：
（1）系统管理员登陆基本数据修改功能子系统，点击“读者信息注销”（2）查询读者的借阅记录
若有未归还图书，给出提示：暂时不能注销
否则注销读者，提示：注销后，不能借阅图书 若不确定，返回上一层界面
（3）注销图书证，删除基本数据修改功能子系统中的读者信息（4）注销完成，在数据库管理子系统删除读者信息，退出系统 5．“书籍信息录入”用例 用例编号：0305 用例名：书籍信息录入
执行者：直接执行者：系统管理员，间接执行者：图书管理员，数据库管理子系统 目的：图书馆里的图书根据馆藏需求进行更新 过程描述：
（1）系统管理员登陆基本数据修改功能子系统，点击“书籍信息录入”
（2）写入图书相应信息
（3）图书管理员给图书进行分类编号，记录条形码信息（4）图书管理员为图书张贴条形码
（5）图书管理员检查图书编号是否入库
（6）在数据库管理子系统增加图书信息，书籍信息录入成功，退出系统 相应活动图如下：
系统管理员界面图书管理员数据库管理子系统登陆基本数据修改功能子系统点击书籍信息录入图书进行分类编号，记录条形码信息图书张贴条形码检查图书编号是否入库增加图书信息[否]退出系统[是]
6．“书籍信息注销”用例
用例编号：0306 用例名：书籍信息注销
执行者：直接执行者：系统管理员，间接执行者：图书管理员，数据库管理子系统
目的：当图书馆里藏书，由于受到毁损或其他意外的破坏而无法再使用的情况下，需要对馆藏图书进行注销。过程描述：
（1）系统管理员登陆基本数据修改功能子系统，点击“书籍信息注销”
（2）输入图书编号，若该书借阅出库，则暂时不能注销，提示“该书借阅中，不能注销”；若该书未被借阅，提示“确定要注销此书吗？”若不确定，返回上一层界面（3）成功注销图书后，在数据库管理子系统删除图书信息，退出系统
三、系统分析
3.1建立对象类（1）reader 类名：reader 类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，不可以共享 功能：负责读者信息并对这些信息进行处理，便于对读者借阅信息进行统一管理。属性：读者的编号ID（reader_id）、姓名（reader_Name）、身份（identification）、学院（academy）、所借书籍的编号（borrowed）等 操作：借书和还书、接受相应处理
(2)system admin 类名：system admin 类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，不可以共享 属性：编号和姓名等
操作：读者信息管理、书籍信息管理、借阅管理、（3）books admin 类名：books admin
类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，不可以共享 属性：编号和姓名等
操作：借阅管理、书籍信息录入、书籍信息修改、书籍信息注销（3）Books 类名：Books 类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，可以共享 属性：书名、作者、书籍编码、类别、价钱、入库时间 操作：分类编号、记录条形码信息、（4）borrow 类名：borrow 类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，不可以共享 属性：借阅书籍的编号、借阅时间、操作：借书、还书、续借书、交欠款、交罚款（5）data 类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，不可以共享 属性：书籍信息、读者信息、借阅信息
操作：读者信息录入、读者信息修改、读者信息注销、书籍信息录入、书籍信息修改、书籍信息注销、增加借阅信息、删除借阅信息 3.2 建立对象类图
reader+编号+姓名+身份+学院+所借书籍的编号+借书()+还书()+接受相应处理()data+书籍信息+读者信息+Attribute1+读者信息录入()+读者信息修改()+读者信息注销()+书籍信息录入()+书籍信息修改()+书籍信息注销()+增加借阅信息()+删除借阅信息()system admin+编号+姓名+读者信息管理()+书籍信息管理()+借阅管理()Books+书名+作者+书籍编码+类别+价钱+入库时间+分类编号()+记录条形码信息()borrow+借阅书籍的编号+借阅时间+借书()+还书()+续借书()+交欠款()+交罚款()books admin+编号+姓名+借阅管理()+书籍信息录入()+书籍信息修改()+书籍信息注销()图2-1 图书馆管理系统类图
四、系统设计
4.1顺序图建模
◆在“借书”用例中涉及的对象间的交互分析如下：
1）登录系统。图书管理员登陆“基本数据修改功能子系统”，对读者的借书要求进行处理。涉及的对象：
·消息的发送者：“系统管理员”对象 ·消息的接收者：“基本数据修改功能子系统借阅窗口”对象 传递的消息：
·消息：口令密码（）
·消息的类型：同步消息
·返回消息：口令密码正确或出错信息 2）输入图书证编号。涉及的对象：
·消息的发送者：“基本数据修改功能子系统借阅窗口”对象 ·消息的接收者：“基本数据修改功能子系统借阅窗口”对象
传递的消息：
·消息：核对图书证编号（）·消息的类型：自调用消息
·返回消息：图书证编号正确或出错信息 3）输入图书编号。涉及的对象：
·消息的发送者：“基本数据修改功能子系统借阅窗口”对象 ·消息的接收者：“reader”对象
传递的消息：
·消息：[最大借书额为0]:核对借书额（）·消息的类型：同步消息
·返回消息：可以借书 4）确定借阅图书。涉及的对象： ·消息的发送者：“reader”对象 ·消息的接收者：“reader”对象 传递的消息：
·消息：[确定借书]: 借阅证号增加借阅信息记录（）·消息的类型：自调用消息 ·返回消息：借书成功 5）修改数据库。涉及的对象： ·消息的发送者：“reader”对象 ·消息的接收者：“数据库管理系统借阅管理”对象
传递的消息：
·消息：[借书成功]: 保存借阅记录并修改库存图书数量、读者借出数量（）·消息的类型：同步消息
·返回消息：退出系统
根据以上确立的“借书”用例图中涉及的对象，建立“借书”用例的顺序图如图3-1：
基本数据修改功能子系统借阅窗口reader数据库管理系统借阅管理窗口 : 图书管理员1 : 登录系统()2 : 核对图书证编号()3 [最大借书额为0] : :核对借书额()4 [确定借书] : 借阅证号增加借阅信息记录()5 [借书成功] : 保存借阅记录并修改库存图书数量、读者借出数量()图3-1 “借书”用例顺序图
◆在“还书”用例中涉及的对象间的交互分析如下：
1）登录系统。图书管理员登陆“基本数据修改功能子系统”，对读者的还书要求进行处理。涉及的对象：
·消息的发送者：“系统管理员”对象 ·消息的接收者：“基本数据修改功能子系统还书窗口”对象 传递的消息：
·消息：口令密码（）
·消息的类型：同步消息
·返回消息：口令密码正确或出错信息
2）输入图书证编号。涉及的对象：
·消息的发送者：“基本数据修改功能子系统还书窗口”对象 ·消息的接收者：“基本数据修改功能子系统还书窗口”对象
传递的消息：
·消息：核对图书证编号（）
·消息的类型：自调用消息
·返回消息：图书证编号正确或出错信息
3）超期罚款处理。涉及的对象：
·消息的发送者：“基本数据修改功能子系统还书窗口”对象 ·消息的接收者：“基本数据修改功能子系统超期罚款窗口”对象 传递的消息：
·消息：[超期]：超期罚款（）·消息的类型：同步消息 ·返回消息：销毁超期信息
3）丢失罚款处理。涉及的对象：
·消息的发送者：“基本数据修改功能子系统还书窗口”对象 ·消息的接收者：“基本数据修改功能子系统丢失罚款窗口”对象
传递的消息：
·消息：[丢失]：丢失罚款（）·消息的类型：同步消息 ·返回消息：销毁超期信息
4）输入图书编号。涉及的对象：
·消息的发送者：“基本数据修改功能子系统还书窗口”对象 ·消息的接收者：“reader”对象 传递的消息：
·消息：[借阅]：核对是否借阅此书（）·消息的类型：同步消息 ·返回消息：是否借阅此书 5）确定还书。涉及的对象： ·消息的发送者：“reader”对象 ·消息的接收者：“reader”对象
传递的消息：
·消息：[确定还书]: 借阅证号删除借阅信息记录（）·消息的类型：自调用消息 ·返回消息：还书成功
6）修改数据库。涉及的对象：
·消息的发送者：“reader”对象 ·消息的接收者：“数据库管理系统借阅管理”对象
传递的消息：
·消息：[还书成功]: 删除借阅记录并修改库存图书数量、读者借出数量（）·消息的类型：同步消息 ·返回消息：退出系统
根据以上确立的“还书”用例图中涉及的对象，建立“还书”用例的顺序图如图：
基本数据修改功能子系统还书窗口基本数据修改功能子系统超期罚款窗口基本数据修改功能子系统丢失罚款窗口reader : 图书管理员1 : 登录系统()2 : 核对图书证编号()3 [超期] : ：超期罚款()4 [丢失] : ：丢失罚款()5 [借阅] : ：核对是否借阅此书()6 [确定还书] : : 借阅证号删除借阅信息记录()
图3-2 “还书”用例顺序图一
reader数据库管理系统借阅管理5 [确定还书] : : 借阅证号删除借阅信息记录()6 [还书成功] : :删除借阅记录并修改库存图书数量、读者借出数量()
图3-3 “还书”用例顺序图二
4.2 构件图建模
构件图主要用于建立系统的静态实现视图模型，通过构件之间的依赖关系描述系统软件的组织结构，展示了系统中的不同物理构件机器之间的联系。
图3-4所示的是图书馆管理系统部分构件图，图书管理员登陆“基本数据修改功能子系统”并成功通过验证后，进入基本数据修改功能子系统主界面
图书管理员登陆验证基本数据修改功能子系统主界面续借书借书还书丢失罚款超期罚款图3-4 基本数据修改功能子系统构件图
4.3 配置图建模
实用配置图定义的软硬件结构及通讯机制，表示软硬件系统之间的合作关系；使用构件图描述系统由哪些构件组成。
图书馆管理系统是一个客户/服务器和服务器/浏览器相结合的系统，可以同配置图显示系统的物理结构，如图3-5所示：
TCP/IP应用服务器ODBC图3-5 图书馆管理系统配置图SQL SERVER13 客户程序数据库服务器
第三篇：UML与面向对象分析与设计
UML与面向对象分析与设计
实验实践训练体系
适用专业: 计算机科学技术、软件工程
第一部分 课程与实验综述
一．课程简介及实践要求：
《UML与面向对象分析与设计》是以介绍面向对象的统一建模语言UML为主,使学生了解面向对象技术的基本概念,掌握面向对象的分析和设计方法,以及与面向对象技术相关的一些软件开发技术,同时掌握在Rational Rose环境下用UML进行分析和设计的技术。本课程在教学内容方面着重基本理论、基本知识和基本方法，在培养实践能力方面着重设计构思和设计技能的基本训练，熟练的上机操作能力和分析能力。
实验实践训练是UML与面向对象分析与设计教学的重要技能环节。通过实验，使学生加深理解、验证、巩固课堂教学内容，特别是通过设计和综合实验，发挥学生的想象力和创新能力。
二．课程实验目的要求：
通过UML的实验,学生应该: 1．学会用面向对象的思想去分析和设计相关系统;2．学会用Rose建模工具进行软件建模。三．课程实验参考资料
1.(美)Joseph Schmuller著.UML基础、案例与应用.人民邮电出版社,2004 2.(美)Hans-Erik Eriksson.UML 2工具箱.电子工业出版社,2004 3.吴际,金茂忠.UML面向对象分析.北京航空航天大学出版社,2002 4.赵从军.UML设计及应用.机械工业出版社,2004 5.Grady Booch,James Rumbaugh,Ivar Jacobson.UML用户指南.机械工业出版社,2001 6.吴建,郑潮,汪杰.UML基础与Rose建模案例.人民邮电出版社,2004 第二部分 实验实践指导
实验一
用例图
一、实验目的
1.学会分析系统中的参与者和用例 2.掌握用例图的绘制方法
二、实验器材
1.计算机一台；
2.Rational Rose 工具软件；
三、实验内容
画出ATM系统的用例图
四、实验步骤
1.分析
ATM自动取款机：客户可以取钱，存钱，查询余额，转帐，修改密码。通过分析可找出如下几个参与者： 1．ATM 2．客户
通过分析得到如下用例：
（1）存款（2）取款（3）查询余额（4）转帐（5）修改密码（6）打印收据 2．绘图步骤：
下面介绍在Rose2003中创建用例图的过程：
（1）在“Use Case View“中双击Main图，或者右击“Use Case View“，弹出在快捷菜单中选择“New”－>“UseCase Diagram”，双击图标，出现图1，为编辑用例图做好准备。
（2）在用例视图中，从工具栏中选择Actor图标，在右边的绘图区中添加一个新元素，并取名客户表明新增一个参与者，如图2所示。
图2（3）同样的方法添加参与者“ATM”,如图3所示。
图3(4)在工具栏上选择用例的图标，依次添加存款、取款、查询余额、转帐、修改密码、打印收据，如图4所示。
图4（5）添加参与者和用例间的关联关系，如图5所示。
图5
五、实验报告要求
1． 整理实验结果。2． 小结实验心得体会。
实验二
交互图
一、实验目的
1.学会用协作图实现用例
2.掌握顺序图的绘制方法以及顺序图和协作图的相互转换。
二、实验器材
1.计算机一台；
2.Rational Rose 工具软件；
三、实验内容
画出ATM取款的顺序图，并转换为协作图。
四、实验步骤
1.分析
ATM取款的场景：
（1）通过读卡机，用户插入ATM卡；
（2）ATM系统从卡上读取银行ID、帐号、加密密码、并用主银行系统验证银行ID和帐号；
（3）用户输入密码，ATM系统根据上面读出的卡上加密密码，对密码进行验证；（4）用户输入取款数量；
（5）ATM系统通知主银行系统，传递储户帐号和取款数量，并接收返回的确认信息；（6）ATM系统输出先进、ATM卡和显示帐户余额的收据；（7）ATM系统记录事务到日志文件。寻找场景中的对象：ATM、客户和帐户。2．绘图步骤：
下面介绍在Rose2003中创建顺序图的过程：
（1）在“Logical View”中新建“Sequence Diagram“，双击图标，出现图1，为编辑顺序图做好准备。
（2）在顺序图编辑窗口中，从工具栏中选择Object图标，在右边的绘图区中添加一个新元素，并取名Customer表明新增一个对象，如图2所示。
图2
（3）同样的方法，添加ATM对象和Account对象，如图3所示。
图3（4）根据ATM取款的场景，获得第一条消息为“客户向ATM机提交取款需求”，向图中添加消息，如图4所示。
图4
（5）同样的方法添加其它消息，如图5所示。
图5（6）根据顺序图生成协作图，步骤如下：“Browse”－>“Create Collaboration Diagram”，生成的协作图，如图6所示。
图6
五、实验报告要求
1． 整理实验结果。2． 小结实验心得体会。
实验三 类图
一、实验目的
1.理解类的基本概念 2.理解类间的关系 3.掌握类图的绘制方法
二、实验器材
1.计算机一台；
2.Rational Rose 工具软件；
三、实验内容
分析选课系统中的类及关系，然后画出它们的类图。
四、实验步骤
1.分析
在选课系统中，通过分析可抽象出如下几个类： 1．学生类 2．管理员类 3．课程类
学生类和管理员类的属性较容易分析，这里只列出课程类的属性和方法：（1）课程名称（2）开课教室（3）课程号（4）授课教师（5）选课的学生（6）开课起始时间（7）允许选课的学生人数（8）设置课程号（9）设置课程名称（10）查询课程号
（11）查询允许选课的学生人数 2．绘图步骤：
下面介绍在Rose2003中创建类和它们之间关系的过程：
（1）在“Logical View“中双击Main图，或者右击“Logical View“，弹出在快捷菜单中选择“New”－>“Class Diagram”，双击图标，出现图1，为编辑类图做好准备。
图1
（2）在逻辑视图中，从工具栏中选择class图标，在右边的绘图区中添加一个新元素，并取名Student表明新增一个类。
图2
（3）选择新创建的元素，点击鼠标右键，在弹出的菜单中选择“Open Sepcification”,弹出图3对话框。
（4）在对话框中，可以修改元素的名称，这里新元素的名称定为“Student”，如图4所示。
图3
图4（5）点击“Attributes”选项卡，添加属性，如图5所示。
图5（6）点击“operations”选项卡，添加方法如图6所示。
图6（7）同样的方法添加Course类，如图7所示。
图7（8）创建两个类之间的关系，通过分析得出：学生类和课程类之间为单向关联。选择图标栏的“关联”，由学生类指向课程类。如图8所示。
图8（9）创建关联名。右击关联，选择“open specification“，键入关联名，如图9所示。
图9（10）分别在“Role A Detail“和“Role B Detail“选项卡中键入名称和多重性，如图10所示。
图10（11）重复（2）－（10）中的步骤完成选课系统整个类图的创建。
五、实验报告要求
1． 整理实验结果。2． 小结实验心得体会。实验四 状态图和活动图
一、实验目的
1． 熟悉状态图和活动图的基本功能和使用方法。2． 掌握如何使用建模工具绘制状态图和活动图方法。
二、实验器材
1.计算机一台；
2.Rational Rose 工具软件；
三、实验内容
（1）分析图书管理系统中的书和借书证的状态，画出它们的状态图；（2）分析管理员的活动状态，画出管理员的活动图。
四、实验步骤
1.分析
在图书管理系统中，分析书的状态如下： 1．可借 2．被借 3．被预约 4．删除
借书证的状态如下： 1．可用 2．不可用 3．删除
管理员的活动如下： 1． 处理还书 2． 处理借书 3． 处理罚款 读者的活动如下： 1．登录 2．找书 3．预约 4．浏览 2．绘图步骤：
下面介绍在Rose2003中创建类和它们之间关系的过程：
（1）在“Logical View“中信件“StateChart Diagram”，双击图标，出现图1，为编辑状态图做好准备。
图1（2）在工具栏中选择“Start State”图标添加到编辑窗口中，如图2所示。
图2（3）在工具栏中选择“State”图标，添加一个元素，命名为“New book”，如图3所示。
图3
（4）同样的方法添加其它状态，如图4所示。
图4
（5）书的各个状态之间添加转移及相应的事件，如图5所示。
图5
（6）同样的方法得借书证的状态图，如图6所示。
图6
（7）在Rose2003中，绘制图书管理员的活动图，新建“Activity Diagram”，如图7所示：
图7
（8）读者的活动图如图8所示：
图8
五、实验报告要求
1． 整理实验结果。2． 小结实验心得体会。
第四篇：UML实验报告
一：需求分析
在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。我们在日常生活中也经常和ATM打交道。本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。二：银行ATM机系统UML建模设计 1.用例图
参与者“银行储户”和ATM机。简化后的ATM机仅有取款、存款及其余功能。其余功能不做详细说明。
银行储户在ATM机上完成取款、存款及其他业务。2.类图
整个银行系统包括了帐户库、银行储户库及ATM系统。
许多单个的帐户组成了帐户库。帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。
setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。getType获取帐户类型，返回类型为char，无参数。
setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。getAccountNumbe获取帐户号，返回类型为int，无参数。
caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。getBalance获取帐户余额，返回类型为double，无参数。
许多银行储户组成了储户库。ATM系统包含了许多ATM机。银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。更多的属性及操作都可以一一加上，使这个类图更详细更完整，从而使参与项目的每个成员都能无歧义的明了整个设计的类的结构。同样对于一个真正的银行系统，这个类图过于简单。比如帐户类型我们可以先定义一个abstract class，它包含一个帐户最基本的属性及操作。而有些操作先定义为abstract，如余额的计算。然后再继承这个abstract class，我们可以有saving account 和checking account等等。不同的帐户有不同的余额计算方法，我们可以加上具体的算法。对于不同的帐户可能还有一些它特有的操作，我们也可以加上，比如saving account在存款达到多少时可以享受机票打折的优惠。通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮组自己整理思路，充实及优化自己的设计。
3.顺序图
描述顾客在ATM机上取款时信息的流动情况。以时间为顺序。因为是示例图，所以整个过程是没有出现任何故障时的流程，并且只画到了取款结束。通过这个图，我们可以看出消息是如何在系统中不同对象之间进行交互。
通过流程图我们可以很清楚地看到系统是如何工作的，系统各部分之间的信息及控制是如何发送的，整个流程是否合理。流程图对我们的设计起到了很好的帮助作用。注意在本图没有一个生命线终端有一个“X”，这是因为这个流程中还未遇到有对象生命结束。当有对象生命结束时需在对应的生命线终端画“X”，表明这个对象在这时被销毁。
首先银行储户将ATM卡插入读卡机，读卡机将信息传给客户管理，客户管理提出查询密码，显示部分将输入密码请求显示出来….银行储户读卡机显示输入设备客户管理点钞机事务管理1: 插入ATM卡2: 接受ATM卡3: 查询密码4: 显示输入密码请求5: 输入密码6: 密码传递7: 请求确认密码的合法性8: 确认密码的合法性9: 询问服务类别10: 显示输入服务类别请求11: 输入取款请求12: 取消请求13: 询问取款数额14: 显示输入数额请求15: 输入取款数额16: 传递取款数额17: 询问取款数额确认18: 显示确认数额请求19: 输入确认20: 传递确认信息21: 数额合法性确认请求22: 确认数额的合法性23: 计算储户余额24: 出钞请求25: 出钞26: 取钞27: 传递余额并询问是否需要其它服务28: 显示储户余额并显示其它服务
第五篇：UML实验报告[推荐]
UML实验报告
班 级：软件0841
姓 名：张文成 学 号：081842173
实验内容：
用例建模、分析建模、设计建模（1）、设计建模（2）
实验一：用例建模
[实验目的] 〃掌握客户需求分析的方法和步骤
〃了解以用例驱动的软件开发方法 〃识别并编写用例
〃掌握用Rose 进行用例建模的具体方法和步骤
[实验内容] 要求学生根据周围的实际情况，自选一个小型应用项目，分析业务需求，识别并编写用例、绘制用例图以理解系统需求。亦可采用教师指定的“企业综合信息管理系统”中的“进销存管理子系统”
[实验原理和步骤] 建模原理：
(1)需求获取。以任务和客户为中心，通过会议、面谈等手段对客户需求进行调研，获得系统目标、范围和功能要求的初步说明。(2)用例分析。确定用例，同时采用分层思想，对用例的层次级别进行划分（高层用例、子系统级、用户目标级）
（3）用例描述。分层绘制用例图，撰写用例的文字描述（采用单栏格式）。
步骤：
（1）需求获取。自选题目，与相关客户、领域专家等反复商讨，获得系统目标、范围和功能要求的初步说明。（也可采用教师指定的题目：“企业综合信息管理系统”中的“进销存管理子系统”，但要仔细研读“企业现状”、“系统目标、范围和功能要求”等文字说明）。（2）用例分析。确定系统范围和边界、确定参与者、确定用例。（3）用例描述。分层绘制用例图、描述用例。
画图原理：
采用Rose 软件进行用例建模必须建立在完好的系统用例分析基础之上．只有做好系统用例分析，系统用例建模才能这到预期的效果。步骤：
（1）分层绘制用例图，每层采用“包”进行管理。
（2）以“企业综合信息管理系统”-> “进销存管理”子系统-> “销售管理”-> “合同管理”->“收款单处理”为主线，完成附录2 中的操作过程（亦可选择“企业综合信息管理系统”-> “进销存管理”子系统-> “库存管理”-> “原材料出库”->“领料单处理”主线）
[ 实验结果]
实验2 分析建模
[ 实验目的](1)理解面向对象系统分析和对象类建模(概念建模)的概念(2)了解和掌握面向对象系统分析的方法和步骤(3)了解和掌握寻找待开发系统中类(概念)的方法和技巧(4)掌握使用ROSE 绘制概念模型的方法
[ 实验内容] 在用例分析的基础上，选择第一个迭代周期打算开发的用例，建立相关的概念模型。
[ 实验原理和步骤] 建模原理：
(1)使用概念目录列表（见下图）和非正式分析法（识别出问题域的文本描述中的名词短语，然后将其作为概念或属性的候选对象。）相结合的方法识别概念。因此，待开发用例的文字描述中，名词可能成为概念或属性的候选对象；表示行为的动词词组有可能成为事务型或过程型对象；形容词词组有可能对应抽象的名词型概念。
采用的技术基本上就是：ER 图+纯行为+OO 的聚合、泛化。（2）最终关联的数量介于“需要知道”型关联与【“需要知道”型关联+“需要理解”型（从通用关联列表中派生出 的，见下图）】之间。
步骤：
（1）识别关键用例作为第一个迭代周期的开发目标（一般是在用例图中被依赖得比较多的用例）。可以选“企业综合信息管理系统”-> “进销存管理”子系统-> “库存管理”-> “原材料出库”->“领料单处理”主线中的“领料单处理”用例；也可以选“企业综合信息管理系统”-> “进销存管理”子系统-> “销售管理”-> “合同管理”->“收款单处理”主线中的“增加销售合同”或“收款单处理”用例。（其实，选“库存管理”主线更合适；当然，如果要实现产销一体化，以销售订单指导生产和采购，并实现零库存目标，那么一切工作就以销售管理为中心。即便如此，首选“增加合同”用例也更为合适。）
（2）识别概念和重要属性。
（3）建立概念间的关联。
画图原理：
（1）可以采用“逻辑视图”下的类图描述概念模型，只不过每个类中只有类名和属性，没有方法。在概念建模 阶段也没有必要确定属性的类型和访问属性。
（2）概念间的关联可以采用一般关联（无方向实线），当然，对于聚合和泛化，应采用相应的连线（组合：实心菱形+实线；聚合：空心菱形+实线；泛化：空三角形+实线）
步骤：
（0）前提条件：第一个迭代周期可以选“企业综合信息管理系统”
-> “进销存管理”子系统-> “库存管理”->“原材料出库”->“领料单处理”主线中的“领料单处理”用例；也可以选“企业综合信息管理系统”->“进销存管理”子系统-> “销售管理”-> “合同管理”->“收款单处理”主线中的“增加销售合同”或“收款单处理”用例。做好与此用例相关的概念模型
（1）建立相关的概念模型的基础上，在“逻辑视图”下的类图中描述概念模型，可以直接在类图main 中绘制，也可采用类似用例图中用过的分包机制
(2）绘制概念和重要属性。（3）绘制概念间的关联。
[ 实验结果]
[ 实验总结] ① 对重点实验结果进行分析；
② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。
③ 收获与体会：筛选概念的要点；区分概念与属性的要点；关联取舍的要点；画图时如何防止关联重名。
实验3 设计建模（1）
[ 实验日期]2011年5月20日 [ 实验目的](1)理解顺序图的基本概念
（2）了解和掌握软件工程中用例逻辑时序的分析方法（3）掌握使用ROSE 创建顺序图的方法
[ 实验内容] 在用例模型和概念模型的基础上，对首选的用例进行事件分解，识别出系统事件（系统操作），（并写出契约的后置条件）；为每个系统事件画顺序图，为对象分配职责。
[ 实验原理和步骤] 原理：
(1)在系统顺序图中，所有的系统都被当成黑盒子看待，顺序图的重点是参与者发起的跨越系统边界的事件。
(2)系统事件是由某参与者发起的指向系统的输入事件。一个事件的发生能够触发一个响应操作的执行。
(3)请仔细研究下图,考察它是如何从左边的“购买商品”用例的文字描述中分解出3 个系统事件的。
（4）参照用例模型和概念模型，为每个系统操作估计后置条件。（实例创建、形成关联、属性修改）（5）按照设计模式为对象分配职责。
步骤：
（1）分析首选用例的文字描述，按事件进行分解，识别出系统事件。（下面以“企业综合信息管理系统”-> “进销存管理”子系统-> “销售管理”-> “合同管理”->“收款单处理”主线中的“收款单处理”用例为例）。
我们暂不考虑批处理。第一个核对，因为要将“货款金额填写到合同中”。后置条件显然有“销售合同”的属性修改。此合同显然已经存在，不需要创建，但需要根据合同编号find，然后形成关联。第二个核对需要根据合同明细到仓库的“存货明细”（概念模型中还没有）中去查。此核对发生前虽然敲了一下键盘，但随后并没有新的消息穿越系统边界，因此这仍然是同一个系统事件。先考虑成功场景，应该向库存系统发提货单（概念模型中还没有）就结束了。后续的削减库存（核销）、预警显然不是销售管理员的职权，并且真正的核销必须由仓库的发货人执行，才能保证货帐一致。并且“生产厂家”与“邮购公司”的运作方式不同，后者是自己的员工取货并邮寄，而前者还有可能是来人来车取货，这时仓库收到取货单后并不能立即自动处理（开发货单），必须等取货人到达才能处理。
根据题意，本项目应该是“生产厂家”模式。这又存在一个问题，如
果在开出提货单后不修改库存，可能影响并发用户和后续付款单的处理。所以有必要设计一个“临时存货明细”（概念模型中还没有）（不是真实的“存货明细”）供修改，何时按存货明细”进行刷新应该是库存管理系统的事（比如每天夜里刷新，但因为雨雪天气，取货 人迟迟不提货，是提货单作废（相当于退回销售系统，付款单变为未处理）还是就强行刷新（此时有冲突危险）？）失败场景。向“生产调度部门”发送“产品生产申请单”。如果是专门为此单进行生产，那么还应该有库存系统发来的“产品入库通知处理”用例来调用本用例进行发货。本题显然一概根据付款单运作，因此如果失败，就不处 理付款单，但按日期把它排在待处理付款单的前面。从前面的分析来看，就一个系统事件，我们就命名为“付款单处理(pb:付款单)”（2）为每个系统事件估计后置条件。(以上已做了部分分析)（3）按设计模式进行设计。
首先考虑控制者,领域控制者选参与者角色，即“销售人员”。为了避免使用FORM,窗口等表示层对象,我们人造一 个类”应用协调者”向控制者发送消息。
[ 实验结果]
① 对重点实验结果进行分析；
② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。
③ 收获与体会：事件分解的要点；控制者选择的要点；绘制顺序图的要点。
[ 实验总结] ① 对重点实验结果进行分析；
② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。
③ 收获与体会：事件分解的要点；控制者选择的要点；绘制顺序图的要点。
实验4 设计建模（2）
[ 实验日期] 2011年5月27日 [ 实验目的](1)理解面向对象类之间关联关系的概念(2)了解和掌握分析类之间的关联关系的方法
(3)了解和掌握待开发系统中类之间关联关系的分析方法(4)完善设计类图，掌握使用ROSE 对关联进行建模的过程
[ 实验内容] 根据设计建模（1）中的交互分析，进一步设计关联和对象可见性（补
上遗漏的关联）,完善设计类图。
[ 实验原理和步骤] 建模原理：
（1）关联关系描绘了给定类的对象个体之间的语义连接，是类与类之间的连接。关联可以分为一般关联、聚合关 联、组合关联和依赖关联等。
（2）一般关联包括一对类的二元关联及多个类之间的多元关联。
（3）聚合(Aggregation)表示整体和部分之间较强的关联关系，聚合关系的多重性大于1，则称为共享聚合。
（4）组合(Composition)关系表示整体和部分之间有比聚合关系更强的关系，它们之间是一对一的关系，即同生死共存亡，组合关系不能共享。
（5）依赖关系是一种使用关系，表现为一个对象仅仅调用了另一个对象的服务。可以使用下列的指导方针列出暂时性的关系：
(1)存在两个或两个以上的类相互之间就可能有关联。(2)类的操怍(成员函数)的参数列表里出现其他类的对象。(3)一个类包含另一个类的对象(对象成员)。(4)根据一般常识可能会出现的关联。步骤：
（1）分析已建立的设计类图和交互图，进一步设计关联和
对象可见性（补上遗漏的关联）。（下面以“企业综合 信息管理系统”-> “进销存管理”子系统-> “销售管理”-> “合同管理”->“收款单处理”主线中 的“收款单处理”用例为例）。
在销售管理子系统中，定义的各个类之间一般都有关系发生。销售人员和客户(大客户)共同签署销售合同，销售合同中涉及到多种可以销售的产品，合同经公司经理审查并签字后该合同才能生效，付款单需要客户付款，销售人员签发催款单向客户催缴欠款，销售人员制定销售计划，销售人员要检查督促执行期合同按合同执行、履 约，履约后的合同转到履约合同数据库存档备查等等。例如：
（a）销售人员与客户：一般关联，多对多
（b）销售合同与合同明细，销售计划与计划明细：组合。（c）付款单与客户：依赖关系。《如果付款单类中有“统计付款金额(客户类客户对象)”操作的话，付款 单类就依赖客户类》（2）完善设计类图 画图原理：
（1）关联关系描绘了给定类的对象个体之间的语义连接，是类与类之间的连接。关联可以分为一般关联、聚合关 联、组合关联和依赖关联等。
（2）一般关联包括一对类的二元关联及多个类之间的多元关联。
（3）聚合(Aggregation)表示整体和部分之间较强的关联关系，聚合关系的多重性大于1，则称为共享聚合。
（4）组合(Composition)关系表示整体和部分之间有比聚合关系更强的关系，它们之间是一对一的关系，即同生死共存亡，组合关系不能共享。
（5）依赖关系是一种使用关系，表现为一个对象仅仅调用了另一个对象的服务。步骤：
（1）在关联和对象可见性分析的基础上，补充一般关联、组合，泛化、依赖
（a）一般关联关系要注意关联的命名以及哪个是role A 哪个是role B。
(b)一般关联选中role B detail 中的aggregate，就变成聚合；再选中by value 就变成组合。(c)依赖画虚线箭头。（2）完善设计类图
[实验结果] ① 对重点实验结果进行分析；
② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。
③ 收获与体会：分析依赖关系的要点，绘制关联的要点。通过实验了解UML的建模的步骤和方法，了解用例图和类图等的画法，了解系统的分析和建模方法。增加动手和思维能力，使自己更加的了解软件系统前期开发的软件定义和分析方法。
点击咨询 