UML实验实践训练体系
第一部分 课程与实验综述
一．课程简介及实践要求：
《UML与面向对象分析与设计》是以介绍面向对象的统一建模语言UML为主,使学生了解面向对象技术的基本概念,掌握面向对象的分析和设计方法,以及与面向对象技术相关的一些软件开发技术,同时掌握在Rational Rose环境下用UML进行分析和设计的技术。本课程在教学内容方面着重基本理论、基本知识和基本方法，在培养实践能力方面着重设计构思和设计技能的基本训练，熟练的上机操作能力和基本系统分析能力。
实验实践训练是UML与Rose建模教学的重要技能环节。通过实验，使学生加深理解、验证、巩固课堂教学内容，特别是通过设计和综合实验，发挥学生的想象力和创新能力。 二．课程实验目的要求：
通过UML的实验,学生应该: 1．学会用面向对象的思想去简单地分析和设计相关系统; 2．学会用Rose建模工具进行软件建模。 三．课程实验参考资料
1.(美)Joseph Schmuller著.UML基础、案例与应用.人民邮电出版社,2004 2.(美)Hans-Erik Erikon.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”－>“Cla Diagram”，双击图标，出现图1，为编辑类图做好准备。
图1
（2）在逻辑视图中，从工具栏中选择cla图标，在右边的绘图区中添加一个新元素，并取名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． 小结实验心得体会。
实验五
正（反）向工程
一、实验目的
1. 理解正向工程的基本概念 2. 利用Rose工具生成代码框架
二、实验器材
1.计算机一台；
2.Rational Rose 工具软件；
三、实验内容
进入编码阶段，为了加快编码进度，可以利用建模工具执行正向工程，将系统中的模型转换成指定语言类型的代码框架，现要求您完成该项任务。
四、实验步骤
使用Rose工具将设计的模型通过正向工程生成代码框架。按照使用Rose工具生成代码的6步基本步骤可以顺利的完成代码框架的生成工作。 （1）检查模型， （2）创建组件 （3）将类映射到组件 （4）设置代码生成属性 （5）选择类，组件和包 （6）生成代码
五、实验报告要求
1． 整理实验结果。 2． 小结实验心得体会。
实验六
数据建模
关系数据库管理系统是最常见的数据库使用形式。IBM Rational 的 UML 数据建模配置文件提供了一种为满足数据库建模和数据库设计的需要而使用和理解 UML 的简单的方法。数据库中使用的表和关系的概念在核心 UML 中被映射为类和关联的概念。但是在数据库建模中还有其他的构造和约束（比如数据库和模式）必须被可视化地建模。
图 1 数据库实现的多样性
图 1 显示了数据库部署的多样性。以下这些复杂分配：表与视图到模式、模式到数据库、数据库到表空间（tablespace）和节点，把需要底层构架的一种简单表示的每个数据库管理员（DBA）搞得晕头转向。因此计划数据库的分发和配置成为一项关键能力。 节点 数据库所在的物理实体（计算机）被表示为节点。该表示法是核心 UML 的一部分。 节点用于部署图中，代表了软件部署的物理配置。部署图包括节点以及节点间的连接。这些连接代表了通信协议。
图 2 部署图
\"DB2 Server Lexington\"、\"Oracle Server Cupertino\"和\"Oracle Sever Redmond\"代表了节点，XML、JDBC 和 OraNet代表了通信协议。所有的软件和数据库都必须部署在物理节点上。 部署图对于数据管理员配置服务器和跟踪问题很重要（首先开始部署，然后开始钻研细节）。 表空间
表空间是数据的存储器，代表了一个数据库系统。它是称为 Database 的用户透明物理结构（在下文中描述）和节点之间的链接。表空间是 UML 数据建模配置文件中的原型化组件。
表空间可理解为物理存储上的一个区域，其中该物理存储由数据库来维护。数据库本身可以被分发给数个表空间，这些表空间由数据的大小、数据访问需求和安全需求来决定。 表空间利用依赖关系在数据库中关联，并且在数据库实现的设计阶段是可选的。如果没有使用，将采用数据库维护的默认表空间。
图 3 两个表空间中的数据库实现
表空间在数据库实现中的价值在于计划节点环境和建立节点需求。借助于组件图的帮助，跟踪部分数据库的问题变得更容易。可利用数据库或表空间来实现表。在利用数据库实现时，会使用默认的表空间。
表空间作为物理存储单元的基本结构是由不同的数据库供应商实现的。他们在存储需求和存储内部结构上给予表空间或多或少的控制。 数据库
数据库是用于物理数据存储以及对已存储数据的受控访问的系统。它是用于数据建模的最大的专门元素。数据库是一个原型化组件，并且是 UML 数据建模配置文件的一部分。 数据库定义了数据库类型，以及用于数据建模的约束，比如数据类型、存储过程、语法等。数据库级别是对信息的基本访问级别，可以在更高级别上进行精化。
数据库与组件图中的其他组件结合使用，来定义应用程序和数据库之间的依赖关系。
图 4 组件图中的数据库
数据库组件对于设计者的价值在于计划数据库的可访问性。对数据库的模式分配定义了信息存储的基本结构。 数据库管理员使用部署图来找出应用程序和数据库之间的通信问题，并定义数据以及部署图的物理部署。 模式
表的基本组织单元就是模式。模式是 UML 的组织单元，用包表示。模式是原型化的包，并且是 UML 数据建模配置文件的一部分。
模式是应用程序使用的基本单元。它还是一个可以被授予特权的单元。模式在下一个细节级别上被指定给数据库组件。 模式是在类图中组织的。
图 5 类图解释了模式依赖关系
模式应该分配给数据库，因为数据库定义了语言约束、数据类型、可用触发器、可能的数据库约束以及存储过程类型。
模式不仅仅是一个组织单元；它还是一种安全机制。类图允许数据库管理员和分析人员找出基于应用程序的包和数据之间的依赖关系，从而产生数据库的使用模式。 表
表是关系数据库的基本建模结构。它代表了具有相同结构的一组记录，也被称作行（row）。每条记录都包含数据。有关表结构的信息存储在数据库中。 表是一种原型化类，并且是UML数据建模配置文件的一部分。 表是在数据模型图中表示的。
图 6 数据模型图代表了表和关系上的视图
由于该图只是模型的一个视图，因此它可以代表面向表焦点的解决方案。这避免了由于构建一个巨型的模型图而导致无法找到您正在寻找的物理数据模型的范围。
该数据模型图具有表、视图、表间的关系、视图的依赖关系和存储过程容器，精确地表示了数据词典的一部分。数据管理员可以在更加可读的图形表示中找出数据库的结构。 在设计方面，利用图形表示更容易调整数据库，因为您能够看到表的内容以及文档的每个细节。由于调整经常是一个手动过程，所以表间的数据移动是一项必需的功能。只需要知道所有模型约束的知识就能实现该功能。
构架师不关心数据模型图的详细信息，但是他可以检查是否所有信息都表示在数据库中。 视图
视图是一个虚拟表。它代表了具有相同结构的一组记录，这与表完全一样，唯一的区别在于数据的物理资源在其他表中。
视图是一个原型化类，并且是 UML 数据建模配置文件的一部分。 视图是在数据模型图中表示的。
图 7 从两个表派生而来的视图
由于该图只是模型的一个视图，所以它可以代表面向视图中焦点表中焦点的解决方案。 在视图中对表进行建模的价值不仅仅在于为数据库定义数据结构，还在于数据的面向问题的分析（这不能在数据库本身的知识库中完成）。很容易发现数据结构和数据源之间的依赖关系。 列
列是关系数据库内部的基本组织元素。每个数据都必须存储在表中的行的一列中。这些列作为原型化属性是 UML 数据建模配置文件的一部分。
列添加了必须指定的数据类型标签值。另外，列数据可以作为工件物理存储在数据库中，或者利用表达式从其他列进行计算。
列还具有其他标签值，他们指定了数据模型的细节，比如 null 和唯一性。
图 8 具有四列的表
列定义的价值在于数据结果的规格说明。另外，它还可用于不同数据源的集成以及实现互相之间相同点和不同点的发现。 键
键用于访问表。主键唯一标识了表中的一行，而外键则访问其他相关表中的数据。 主键通常是内容无关的，并且由数据库自动生成，以方便数据的更新。 外键总是从与其他表的关系派生而来。
键是键约束（Key Constraints）的实现。键约束指定了键的内容（哪些列生成了键），以及键的物理实现。为了轻松识别表中的键列，它们被用主键（>）或外键（>）原型标记。在将外键用做主键的情况下，组合键被标记为(>)原型。
图 9 具有主键和外键的表
键代表数据的识别。因此它们是识别数据库（所有链接都位于数据之间）的完整结构，以获得纯工件之外的信息所必需的。 索引
索引是支持快速数据访问的物理数据结构。它完全不改变数据的质量。 索引在 UML 数据建模配置文件中被表示为操作上的原型。 索引和键都包含了几个列。索引中的列必须有顺序。
索引规格说明不但包含索引的列，还包含索引的类型（唯一性等）。
图 10 有两个索引的表
当某些因素影响了应用程序的性能时，索引的价值就被体现出来。索引是首先要注意的地方。 约束 约束是应用于数据库结构的规则。该规则可应用于列和/或表，并且可能被限制到一个模式或数据库。
UML 数据建模配置文件中定义了几种类型的约束，但是，它们作为原型化操作来实现。
图11 有约束的表
定义的约束值位于规格说明的细节中。约束描述了数据库的动态行为，而列和表则没有描述这些内容。 主键
主键约束定义了表的一个主键。每个表只能有一个主键。
主键约束在 UML 数据建模配置文件中使用了原型>。
外键
外键是实现一个关系的约束。该约束总是在子表上实现的。
外键约束在 UML 数据建模配置文件中使用了原型>。
触发器
作为其他活动的结果自动被执行的一个活动就是一个触发器。它经常是数据库中数据修改的副产品，并且大部分情况下保证了数据库的一致行为。
触发器约束在 UML 数据建模配置文件中使用了原型>。
值验证
列中的值可以利用触发器验证。触发器不但能与固定范围的值进行比较，还能与数据库中的其他数据进行比较。
值验证约束在 UML 数据建模配置文件中使用了原型>。
唯一性
唯一性约束保证了指定列的所有值都是不同的。
唯一性约束在UML数据建模配置文件中使用了原型>。 关系
数据模型中表之间任意种类的依赖关系被称作关系。
关系是原型化关联和一组主键和外键的汇总。每个关系都位于一个父表和一个子表之间，其中父表必须定义一个主键。子键创建了一个外键列和外键约束，以满足父表的要求。 non-identifying 关联代表了两个独立表之间的关系。子表的外键不包含所有的主键列。
图 12 Non-Identifying 关系
一个识别关系是两个依赖表间的关系，其中如果没有父表子表就不能存在。父表（本例中为 Person）的所有主键在子表（Account）中同时变成了主键列和外键列。
图 13 识别关系
一个关系有两个与之关联的角色。它们定义了与其他表关联的一个表的角色。可以利用不同角色在两个表间指定一个以上的关系。 每个关系都创建了从父表到子表的迁移键。
