第4章 类图实战
类图、对象图实验报告
UML建模课程实验三、UML类图、对象图模型的设计班级：信息0702 组别：指导老师：徐凯波姓名：王姗学号：2007030331205一、实验要求：掌握利用UML建模工具建立类图和对象图的方法。
二、实验内容：利用UML建模工具设计类图和对象图三、实验环境：Windows 2000 Professional以上环境、Rational Rose2003、Sybase Power Designer 10四、操作步骤：五、遇到的问题和解决方法：类图是所有图中比较好画的一种图，就是将角色、系统它们所具有的属性和活动输入到软件中去，我的类图中角色有管理员、学生，管理员的属性有：管理学的账号、管理员的姓名、管理员的性别、管理员的年龄，他所参与的活动有添加课程信息、删除课程信息、修改课程信息、查询课程信息、登录系统、添加学生信息、删除学生信息、修改学生信息、查询学生信息、查询学生信息；学生的属性有：学生账户、学生姓名、学生性别、学生年龄，他所参与的活动有：查询课程信息、选课、查询个人选课信息，登录系统。
系统的包括：学生信息维护系统、课程管理系统、选课管理系统，学生信息维护系统的属性有：学生的账号、姓名、性别、年龄、管理员的账号；选课管理系统：学生账号、课程编号、课程名称、课程地点、课程时间、课程学分、课程学时；课程管理系统：课程编号、课程名称、课程地点、课程时间、课程学分、课程学时。
在画整个类图的过程中，我没有遇到太多的问题。
六、实验心得和体会：在老师的辅导下，我经过前一阶段的练习，基本掌握了UML的要领，类图我基本上没有太费时间，只是想好属性和动作，还有就是个角色之间的关系，类图的难点是角色与角色之间的关系，究竟是一对多、一对一、多对多。
确定好角色与角色的关系，类图就很容易完成了。
实验4-类图与对象图
设计题目：类图与对象图的建立一、实验目的1．熟悉类图的基本功能和使用方法。
2．掌握如何使用建模工具绘制类图方法。
二、实验内容1、分别设计“图书馆管理系统”、“汽车租赁系统”、“网络教学系统”和“网上图书销售系统”的类图。
汽车租赁系统：网络教学系统：网上图书销售系统：2、假设你是一个系统分析员，要建立篮球比赛模型。
现在你正在会见一名教练员来了解比赛规则情况。
谈话的过程可能如下:分析员：“教练，请大致介绍一下篮球比赛”教练员:“比赛的目标是要把篮球投入蓝框并且要尽量比对手得更多的分。
每个篮球队由5名队员组成:两名后卫、两名前锋和一名中锋。
每个队要将球推进到篮框附近，将篮球投中篮框。
”分析员:“如何将球推进?”教练员:“通过运球和传球。
但是某一方必须在规定的进攻时间内投篮。
”分析员:“规定的进攻时间?”教练员:“是的，在某一方获得控球权后，必须在规定的进攻时间内投篮。
美国职业篮球比赛是24秒，国际篮球比赛是30秒，美国大学篮球比赛是35秒。
”分析员: “如何计算篮球比赛得分？教练员: “三分线之内每投中一次篮框得两分，三分线之外投中一次得三分。
一次罚球得一分。
顺便说一下，罚球是对方犯规后判罚的投球。
如果某一个队员犯规，则比赛暂停，由被侵犯的队员在罚球线处罚球。
”分析员: “再详细说明一下每个篮球队员在比赛中的情祝好吗?”教练员: “后卫队员通常主要是运球和传球。
他们一般都比前锋队员矮，前锋队员通常又比中锋矮。
所有的队员必须都要能运球、传球、投球、抢篮板球，大部分抢篮板球和中距离投篮都由前锋队员完成，而中锋通常离篮框最近，一般由他来篮下进攻。
”分析员:“场地大小如何?另外，每场比赛时间是多少?”教练员:“国际比赛场地为28米长、15米宽。
篮框离地面3.05米高。
在美国职业篮球比赛中，一场比赛为48分钟，分为4节，每节12分钟。
在美国大学和国际比赛中，一场比赛40分钟，分为上下两个20分钟的半场。
有专门的比赛时钟记录比赛还剩下多少时间。
UML类图详细教程
UML类图详细教程UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言。
在软件开发过程中，通过使用UML类图可以清晰地描述系统中的类、对象、方法和关系等要素，以帮助开发人员更好地理解和设计软件系统。
本文将详细介绍UML类图的基本元素、关系类型和用法，以及一些实际应用的示例。
接下来将分为以下几个部分进行阐述：1.基本元素2.类的属性和方法3.类之间的关系4.实际应用示例1.基本元素：a) 类（Class）：类是UML类图的基本元素，用矩形框表示。
每个框内部分别包含类名、属性和方法。
b) 对象（Object）：对象是类的实例，用一条带箭头的直线连接到类。
对象可以有自己的属性和方法。
c) 接口（Interface）：用一个带有虚线的矩形框表示，包含接口的名称和方法。
d) 抽象类（Abstract Class）：用一个带有斜线的矩形框表示，表示只能被继承，不能被实例化的类。
e) 枚举（Enumeration）：用一个带有斜线和虚线的矩形框表示，表示一个有限个数的类。
2.类的属性和方法：a) 属性（Attribute）：用于描述类或对象的状态，用名称和数据类型表示。
b) 方法（Method）：用于描述类或对象的行为，用名称和参数列表表示。
3.类之间的关系：a) 关联（Association）：用一条直线连接两个类，表示两者之间存在关系。
关联可以有方向、多重性和角色等属性。
b) 继承（Inheritance）：用一条带箭头的直线连接两个类，并在箭头上方标识出继承关系。
子类继承了父类的属性和方法。
c) 实现（Realization）：用一条带虚线的直线连接两个类，表示实现关系。
一个类实现了一个接口，需要实现接口中定义的方法。
d) 依赖（Dependency）：用一条带箭头的虚线连接两个类，表示类之间的依赖关系。
一个类依赖于另一个类时，使用到了另一个类的属性或方法。
4.实际应用示例：假设我们要设计一个简单的图书馆管理系统，其中包括书籍（Book）、图书馆（Library）和借阅记录（BorrowRecord）等类。
UML业务建模实例分析四例
UML业务建模实例分析在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。
我们在日常生活中也经常和ATM打交道。
本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。
参与者"银行储户"和ATM机。
简化后的ATM机仅有取款、存款及其余功能。
其余功能不做详细说明。
图5.1 自动取款机（ATM）系统用例图银行储户在ATM机上完成取款、存款及其他业务。
图5.2所示的银行系统类图和图3.5是类似的，只是将工作人员换成了ATM。
整个银行系统包括了帐户库、银行储户库及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机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
类图实验报告
类图实验报告类图实验报告引言：类图是面向对象分析和设计中最常用的工具之一。
通过类图，我们可以清晰地展示系统中的类、属性和方法之间的关系，从而帮助我们更好地理解系统的结构和功能。
本篇实验报告将介绍我在进行类图实验时的设计思路、方法和结果。
一、实验目的本次实验的目的是通过使用类图工具，对一个简单的学生选课系统进行建模。
通过实践操作，我们可以更加熟悉类图的使用方法，掌握类之间的关系表示和类的属性与方法的定义。
二、实验过程1. 确定系统需求在开始实验之前，我们首先需要明确学生选课系统的需求。
该系统主要包括学生、课程和教师三个核心类。
学生类具有学号、姓名和选课列表等属性，以及选课、退课和查询成绩等方法。
课程类具有课程编号、课程名称和授课教师等属性，以及查询选课学生和修改课程信息等方法。
教师类具有教师编号、姓名和授课课程等属性，以及录入成绩和修改学生信息等方法。
2. 绘制类图根据系统需求，我们可以开始绘制类图。
在类图中，我们使用类名、属性和方法来表示类的结构和功能。
通过关联、继承和聚合等关系符号，我们可以清晰地展示类之间的关系。
在绘制类图时，我们需要注意类的可见性、多重性和关联的方向等细节。
3. 完善类图在绘制初步的类图之后，我们需要对其进行完善和优化。
通过仔细检查类之间的关系，我们可以进一步优化类图的结构，使其更加简洁和易于理解。
同时，我们还可以添加必要的注释和说明，以便他人更好地理解和使用该类图。
4. 验证类图完成类图之后，我们需要对其进行验证。
通过使用类图工具提供的功能，我们可以对类图进行语法和语义的检查，确保其符合规范和逻辑。
在验证过程中，我们还可以运行类图生成代码，并进行功能测试，以验证类图的正确性和可用性。
三、实验结果通过以上的实验过程，我们成功地完成了学生选课系统的类图设计。
该类图清晰地展示了学生、课程和教师三个核心类之间的关系，以及类的属性和方法。
经过验证，该类图符合规范和逻辑，能够正常生成代码并实现系统功能。
UVM实战指南-第四章
% irun -uvm myfile.sv
使用非仿真器自带的 UVM 库，使用命令行：
% irun -uvmhome $UVM _HOME myfile.sv
4.2 基本类
实例 4–1: 非 UVM 类定义 1 typedef enum bit { APB _READ, APB_WRITE} apb _direction _enum; 2 class apb_transfer; 3 rand bit [ 31:0] addr; 4 rand bit [ 31:0] data; 5 rand apb _direction _enum direction; 6 function void print(); 7 $display("%s transfer: addr=%h data=%h", (), addr, data); 8 endfunction : print 9 endclass : apb_transfer
域自动有多种形式，请参考 UVM 参考手册。
4
Design IC
/
electron64@
4.3.2 uvm_object 定义指南
建议从 uvm_sequence_item 继承对象，此方式能够给对象增加一些额外的域，同时允许对象成 为 uvm_sequence 随机的一部分。
Design IC
/
electron64@
ＵＶＭ 实战指南第四章
UVM 是功能验证的第一个最佳实践和方法学。如之前提到，UVM 实现了成熟的高级验证方法。尽管其类 库可以任意使用，我们强烈建议按照后续章节描述的方式来使用，因为这些方式源自于成功经验。
OOAD_UML_Chapter 4(北大青鸟课件)
更适合于过程设计
16
使用协作图
17
活动图
• 在执行操作时捕获动作（工作）。这是最常 见的用途
• 描述相关对象之间的交互是如何发生的 • 用动作和对象状态更改来描述用例的执行 • 捕获对象的内部过程 • 用对象描述系统的功能流
5
状态图
• 状态图是有助于描述系统动态特性的一组图 • 任意时间点上对象的状态是对象在该瞬间的状况 • 对象的状态是由对象的所有属性和对象所维护的
链接定义的
6
状态和转换
• 状态更改的过程称为状态转换 • 转换通常是导致状态发生重要更改的操作调
用的结果 • 事件 • 监护条件 • 动作
7
子状态
• 对象的状态可以包含子状态 • 子状态是复合状态的一部分 • 子状态可以是并发的，也可以是顺序的
3
消息和消息表示法
在消息的发送方和接收方之间绘制一条带箭头的线， 以表示消息。箭头指示所发送消息的类型
4
动态视图
所有系统都具有静态结构和动态行为。 UML 提供多种图以捕获和描述系统的这 两个方面。 类图最适用于记录和描述系统的静态结构。 而状态图、时序图、协作图和活动图最适 用于表示系统的行为（动态特性）
分布
26
12
terface
投入硬币 验证硬币
:Vendor
拒收假硬币并显示消息
发送真硬币
出售茶叶
13
递归
• 它是指一再重复同一活动，直到符合条件为 止
• 在显示递归时，事件箭头会回到从其开始的 同一对象处
14
使用时序图
UML中的类图详解及其应用场景
UML中的类图详解及其应用场景在软件开发过程中，UML（统一建模语言）被广泛应用于需求分析、系统设计和软件开发等各个阶段。
其中，类图作为UML的核心图表之一，用于描述系统中的类、对象以及它们之间的关系。
本文将详细介绍UML中的类图，并探讨其在实际应用中的场景。
一、类图的基本概念类图是一种静态结构图，用于表示系统中的类、接口、关联、继承、依赖等元素及其之间的关系。
在类图中，类用矩形表示，类名位于矩形顶部，类的属性位于矩形中部，类的操作（方法）位于矩形底部。
类之间的关系通过连线表示，如关联关系用实线箭头表示，继承关系用空心三角箭头表示，依赖关系用虚线箭头表示等。
二、类图的元素及其关系1. 类（Class）：类是对象的抽象表示，用于描述具有相同属性和行为的一组对象。
类图中的类用矩形表示，类名位于矩形顶部。
2. 接口（Interface）：接口是一组方法的集合，用于描述类的行为。
接口在类图中用带有<<interface>>标记的矩形表示。
3. 属性（Attribute）：属性是类的特征，描述了类的状态。
属性在类图中用名称:类型的形式表示，例如“name:String”。
4. 操作（Operation）：操作是类的行为，描述了类的方法。
操作在类图中用名称(参数列表):返回类型的形式表示，例如“getName():String”。
5. 关联关系（Association）：关联关系描述了类之间的连接，表示一个类与另一个类之间的关联。
关联关系在类图中用实线箭头表示。
6. 继承关系（Inheritance）：继承关系描述了类之间的继承关系，表示一个类继承自另一个类。
继承关系在类图中用空心三角箭头表示。
7. 依赖关系（Dependency）：依赖关系描述了类之间的依赖关系，表示一个类依赖于另一个类。
依赖关系在类图中用虚线箭头表示。
三、类图的应用场景1. 系统设计：类图是系统设计的重要工具之一。
UML类图的建模细节与规范实战分享
UML类图的建模细节与规范实战分享UML（Unified Modeling Language）是一种用于软件系统设计、描述和分析的标准建模语言。
在软件开发过程中，使用UML类图可以更好地理解和展示系统的结构和关系，帮助开发人员更好地进行软件设计和开发。
本文将分享一些UML类图建模的细节和规范实战经验。
1. 类与对象的关系在UML类图中，类和对象是两个重要的概念。
类代表一类具有相同属性和行为的对象，而对象则是类的实例。
在建模过程中，我们需要清晰地定义类与对象之间的关系。
首先，要注意类与对象之间的关联关系。
关联关系表示类之间的相互连接，可以是单向的、双向的或者多重的。
在建模时，要明确关联的名称、方向和多重性，以便更好地描述类之间的交互。
其次，要注意类与对象之间的依赖关系。
依赖关系表示一个类的实现需要另一个类的支持，通常体现为方法的参数或者返回值。
在建模时，要明确依赖的方向和类型，以便更好地理解类之间的依赖关系。
2. 类的属性与方法在UML类图中，类的属性和方法是描述类的重要元素。
属性表示类的特征和状态，而方法表示类的行为和操作。
在建模过程中，我们需要注意合理地定义类的属性和方法。
首先，要注意属性的可见性。
属性可以是公有的、私有的或者受保护的，这取决于属性是否对外可见和可访问。
在建模时，要根据实际需求和设计要求，合理地定义属性的可见性。
其次，要注意方法的命名和参数。
方法的命名应该具有一定的规范和语义，以便更好地理解方法的功能和用途。
同时，方法的参数也需要明确定义和描述，以便更好地理解方法的输入和输出。
3. 继承与接口在UML类图中，继承和接口是描述类之间关系的重要机制。
继承表示一个类继承另一个类的属性和方法，而接口表示一个类实现了一组特定的方法。
在建模过程中，我们需要合理地使用继承和接口。
首先，要注意继承的使用。
继承应该符合"是一个"的关系，即子类是父类的一种特殊情况。
在建模时，要明确类之间的继承关系，以便更好地理解和展示类之间的层次结构。
04 静态视图
《access》、《import》、《friends》
绑定（Binding）依赖
《binding》
泛化（Generalization）
定义
泛化关系是继承机制中产生的类与类之间的关
系
“is a kind of”关系：属于„„的一种
图形表示
一条带有空心大箭头的有向实线，箭头指向父
（1）在系统中确定的类，它的状态必须超过其应用系统生命周期。
（2）创建包含这些类的类图，并把它们标记成永久的（persistent）。 （3）展开这些类的结构信息，即详细的描述属性的细节，并注重关联和构造 这些类的基数。 （4）观察系统中的公共模式（如循环关联、一对一关联等），它们往往使物 理数据库设计复杂化。如果必要，系统分析师需要创建简化逻辑结构的中间 抽象。 （5）考虑这些类的行为，扩充那些对于数据存储和数据完整性很重要的操作。 （6）如果可能，用工具来把逻辑设计换成物理设计。
关联（Association）
4种应用于关联的修饰：
聚合
“has a”，类间关系是整体与部分的关系。
University
1
n
Institute
关联（Association）
组成关系
另一种形态的聚合
表示整体有管理部分的特有的职责
导航性
表示从源类的任何对象到目标类的一个或多个对象 遍历 分单向关联和双向关联
例：客户类的表示
客户
客户 姓名 单位 电话 Email
客户
姓名 单位 电话 Email 付款(金额)
客户
付款(金额)
UML第4课数据建模
7. 创建列(column)。在表中创建每一列，包括列名、列的属性等。
8. 创建关系(relationship)。如果表与表之间存在关系，则创建它们 之间的关系。
9. 在必要的情况下对数据模型进行规范化，如从第二范式转变为 第三范式。
第4章 数据建模
3
4．1 基本概念
数据库数据的总体逻辑结构称为模式(Schemas)。
关系数据库数据的总体逻辑结构是关系模式，这些数据结构的关 系模式通过各种表来描述。
一个面向对象的系统，要利用关系数据库来表示对象模型 需要进行一定的转换，即把面向对象模式的数据模型转换 成关系模式的数据模型。其思想可以用如图所示的建模方 法表示。
对象类间的一对一关联。
可以在两个对象类转换成的关系模式中的任意一个模式内加 入一个外键，指向另一个模式的主键，即可建立两个表之间 的连接。
对象类间的一对多关联。
可以通过在具有多个对象的类的关系模式中加入一个外键， 指向另一模式的主键建立两个表的连接。
实现对象类间的多对多关联。
需要将类之间的关联也设计成一个类——关联类，把一个多 对多的关联转化成两个一对多的关联。引入的该关联类映射 为关系数据库中的一个关联表，用来映射关联对象。在新增 的关联表中设置一个标识符作为主键，加入两个外键分别指 向初始关联的两个关系模式表的主键。
16
4.3 数据库设计的步骤
结合Rose 2003工具提供的功能来说明如何用UML的类图进 行数据库设计，在Rose 2003中数据库设计的步骤如下：
1. 创建数据库对象。这里所说的数据库对象是指Rose中构件图中 的一个构件，其版型为Database。
类图实例和习题要点
图书基本信息
图书类别信息 读者借阅图书信息
9
10 11 12
BorrowType
Store Reserve Fine
读者借阅类型信息
图书在图书馆中的存放位置信息 读者预订图书信息 读者罚款信息
系统的用户接口可以作为系统的边界类:
（如果采用页面形式表示用户接口，可把页面看成边界类）
Login（登录）、Main（主界面）、 SystemManage（系统管理）、 ReadrManage（读者管理）、 BookManage（图书管理）、 BorrowManage（借阅管理）、 FineManage（罚款管理）等窗体
2.每个HouseKeeper都有一个Manager负责，有的 Manager可能负责多个HouseKeeper，有的Manager 可能一个HouseKeeper都没有，下面哪幅图适合描述 类HouseKeeper和类Manager的关系？ A
HouseKeeper
0..n 1
Manager
B
HouseKeeper
Librarian Manage Book
Borrow-Lend
Reader
顶层用例图
administrator delete user add user
update user
query user
系统管理员Manage User 子用例图
Librarian Set ReaderCard Query ReaderInfo
1.
（3）根据MVC模式寻找 根据用例图找出边界类；在用例图中找出控制类； 数据库设计完毕后，可以根据数据表获得实体类。 （4）有些类无法通过上述方法找到，可能还需要 从后面的动态模型（如时序图和协作图）中通过 分析对象来确定。
uml类图实验报告
UML类图实验报告1. 引言UML（Unified Modeling Language）是一种用于软件系统建模的标准化图形化语言。
它提供了一种统一的方式来描述和设计软件系统的结构、行为和交互。
在本实验中，我们将学习如何使用UML类图来表示系统中的类和它们之间的关系。
2. 实验目的本实验的主要目的是通过绘制UML类图，加深对面向对象概念的理解，并学会使用类图来描述系统的结构。
3. 实验步骤3.1 确定需求首先，我们需要明确系统的需求和功能。
在本实验中，我们以一个简单的图书馆管理系统为例。
该系统需要管理图书馆的图书、读者和借阅记录。
3.2 确定类根据系统的需求，我们可以确定需要以下几个类：图书、读者、借阅记录。
3.3 绘制类图根据确定的类，我们可以开始绘制UML类图。
在类图中，我们使用矩形表示类，并在矩形内部写下类的名称。
类之间的关系使用箭头表示。
3.3.1 图书类首先，我们绘制图书类。
图书类具有以下属性和方法： - 属性：书名、作者、出版日期、ISBN号 - 方法：借出、归还class 图书 {书名作者出版日期ISBN号借出()归还()}3.3.2 读者类接下来，我们绘制读者类。
读者类具有以下属性和方法：- 属性：姓名、年龄、性别、借阅记录 - 方法：借书、还书class 读者 {姓名年龄性别借阅记录借书()还书()}3.3.3 借阅记录类最后，我们绘制借阅记录类。
借阅记录类具有以下属性：- 属性：图书、读者、借阅日期、应还日期class 借阅记录 {图书读者借阅日期应还日期}3.4 描述关系在类图中，类之间的关系可以通过箭头来表示。
根据系统需求，我们可以得出以下关系： - 图书和借阅记录之间是一对多的关系，一个图书可以对应多条借阅记录。
- 读者和借阅记录之间也是一对多的关系，一个读者可以对应多条借阅记录。
我们可以使用带箭头的实线来表示一对多的关系。
图书 --> 借阅记录读者 --> 借阅记录4. 实验结果根据上述步骤，我们成功绘制了一个简单的图书馆管理系统的UML类图。
实验四 类图参考答案
实验四类图【实验目的】1．掌握类的定义，类的3要素，UML中类的表示方法。
2．掌握类与类之间的各种关系代表的含义及表示方法。
3．掌握实体类、边界类、控制类的概念和表示方法。
4．接口和抽象类的概念和表示方法，类的多重性关系。
【实验性质】设计性实验。
【实验要求】1．通过网上选课系统学习识别类和类之间关系的方法；2．学习使用Rational Rose绘制类图的方法；3．掌握类图中属性和操作的添加方法。
【实验内容】设计绘制选课系统中的类图和对象图。
【实验步骤】1.分析实验三中选课用例的顺序图，除了角色之外，有以下名词：课程，界面和控制对象。
从而抽象出三个类：课程类Course、界面类FormObject和控制对象类ControlObject。
2.课程类Course应具有的属性有：课程名称、开课教室、授课教师、选课的学生、开课起始时间、允许选课的学生人数，操作有设置课程名称、设置开课教师、设置课程号、设置授课教师信息、设置开课起始时间、设置允许选课的学生人数、查询课程名称、查询开课教师、查询授课教师信息、查询开课起始时间、查询允许选课的学生人数。
根据以上分析，绘制课程类Course的类图。
3.类似的，自己分析建立界面类FormObject和控制对象类ControlObject的类图。
4.在选课系统中，涉及到的用户包括Student（学生）和Registrar（管理员），其主要特性相似，所以可以建立统一基类People，Student和Registrar由People派生。
如下图所示：PeopleStudent (from Use Case View)Registrar (from Use Case View)5.在选课系统中涉及到的角色包括：（1）学生Student；（2）管理员Registrar；（3）学生和管理员的父类People；（4）数据库Database。
这些类和角色之间的关系如下：(1)角色Student和Register从People派生；(2)学生、管理员在与系统交互时，都有一个界面与之对应；(3)一个界面可能和课程相关（0-多门）；(4)控制对象负责课程的处理，处理结果显示在界面上；(5)控制对象完成对数据库的操作；(6)界面请求控制对象的服务。
UML类图教程
UML类图教程：理解、设计和构建软件系统UML类图是一种在软件开发过程中用于描述系统结构的静态结构图。
它显示了类、属性、操作以及对象之间的关系。
以下是关于如何绘制UML类图的详细教程：一、UML类表示法在UML中，类表示封装状态（属性）和行为（操作）的概念。
类图中的每个类都包含一个类名、属性（成员变量）和操作（成员方法）。
下面是一个简单的Java类的UML表示法示例：public class Person {private String name;private int age;public Person(String name, int age) { = name;this.age = age;}public String getName() {return name;}public void setName(String name) { = name;}public int getAge() {return age;}public void setAge(int age) {this.age = age;}}对应的UML类图表示法如下：Class Diagram: Person Class+name: String+age: int#constructors: Person(String name, int age) [e2e], Person(String name, int age) -> e2e [e2e]#getters: getName() [e2e], setName(String name) [e2e]#setters: setAge(int age) [e2e]在类图中，类名通常使用“+”表示公共、"-"表示私有或"#"表示受保护的访问修饰符来表示。
属性使用"+"表示公共、"-"表示私有或"#"表示受保护的访问修饰符，而操作使用同样的修饰符或使用"()"表示方法。
UML中的类图实践案例
UML中的类图实践案例UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言，它提供了一套丰富的图形符号和规范，用于描述软件系统的结构、行为和交互。
其中，类图是UML中最常用的一种图形表示方法，用于描述系统中的类、属性和方法之间的关系。
在本文中，我们将通过一个实践案例来展示UML中类图的应用。
假设我们要设计一个简单的图书管理系统，该系统包括图书馆、图书、读者和管理员四个主要类。
首先，我们可以创建一个名为"Library"的类，该类表示整个图书馆系统。
在类图中，我们可以使用一个长方形框表示一个类，类名位于框的顶部。
接下来，我们需要在"Library"类中定义一些属性和方法。
例如，我们可以添加一个名为"books"的属性，用于存储图书馆中的图书。
在类图中，我们可以使用一个矩形框表示一个属性，属性名位于框的顶部，类型位于框的底部。
除了属性，我们还可以在类图中表示类的方法。
例如，我们可以在"Library"类中添加一个名为"addBook"的方法，用于向图书馆中添加新的图书。
在类图中，我们可以使用一个带有括号的矩形框表示一个方法，方法名位于括号的左侧。
在图书馆系统中，图书是一个重要的类。
我们可以创建一个名为"Book"的类，表示图书的基本信息。
在类图中，我们可以使用一个长方形框表示一个类，类名位于框的顶部。
在"Book"类中，我们可以定义一些属性，例如书名、作者和出版社。
在类图中，我们可以使用一个矩形框表示一个属性，属性名位于框的顶部，类型位于框的底部。
此外，我们还可以在"Book"类中定义一些方法，例如借书和还书。
在类图中，我们可以使用一个带有括号的矩形框表示一个方法，方法名位于括号的左侧。
除了图书馆和图书，读者和管理员也是图书管理系统中的重要角色。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第4章类图实战4.1从分析到设计首先，我们先来简单归纳一下在分析阶段生成的文件，如下：1. 类图。
类图描述系统内部的静态结构，以领域概念为参考对象。
如果应用BCE 模式的话，原先的类图会是实体类图，而在序列图生成后，会额外生成边界类图和控制类图。
2. 用例图。
用例图描述系统的外部行为，也就是描述参与者如何与系统交互，以便获取服务的使用过程。
3. 序列图。
序列图描述系统的内部行为，针对每一个用例，至少会有一张描述主要流程的序列图。
在应用BCE 模式之后，序列图内部的一群对象，将由边界对象、控制对象和实体对象所组成。
换言之，序列图的一群对象必须来自于类图，而对象之间的交互过程，则来自于用例描述。
分析阶段与设计阶段最大的差别在于，分析阶段所关注的重点在领域概念、业务流程等，并未考虑并涉及实际工作平台。
所以，到了设计阶段，不再需要花费太多时间在业务概念上，取而代之的是，必须把精力放在实际工作平台上，承接分析阶段的类图、用例图、序列图再加上实际工作平台或者是开发人员的观点，生成可以交付给程序员的设计文件。
因此，在本书的开发流程规划中，我们会让设计师直接承接分析师的生成文件，进行下述的加工：1. 类图。
分析师所生成的类图通常跟实际工作平台有些差别，所以设计师要补上一些实际工作平台的概念，让设计出来的类图可以真正交付给程序员实际工作。
2. 用例图。
之前我们没有教给分析师用例之间的包含关系和扩展关系如何处理，只是让用例图保持单纯化，以便将焦点聚焦在业务流程上。
此处，我们会教设计师如何加入开发人员的观点，使用包含关系和扩展关系，罗列出可以共享的部分，并且让用例图更为细致化。
3. 序列图。
在分析阶段的序列图并没有太重视消息上的参数，在设计阶段，每张序列图都要拿出来再检查一次，加上所需要的参数。
由于，有些分析师已经太久没摸过程序代码了，所以生成的序列图偏离实际工作情况太大，需要设计师来补上这一块，否则程序员是很难直接参考分析文件编写程序代码。
好了，接下来，我们要再来多谈一些类图中的元素，这些元素可能对分析师意义不大，但是对设计师而言，会是非常实用的概念。
4.2设计师必学元素4.2.1依赖关系之前，我们学到了类之间的关联或组合关系，它们都是一种需要长期保存在数据库中的静态关系。
相较之下，“依赖关系（dependency relationship）”是一种暂时的、动态的关系，它不需要被长期保存，可以在使用的瞬间建立，如果不用了就回收。
因此，当两个对象之间可以互传消息时，意味着两个对象之间存在需要长期保管的静态关系，或者是暂时性的动态关系。
例如，在图4-1 中，边界对象与实体对象之间可以通过动态的依赖关系交互，用完就丢，不需要将这个动态关系保存在数据库中。
而房型和景观图片两者之间由于存在组合关系，所以它们可以通过静态关系交互。
需要特别注意到，既然说是“依赖”则意味着连动性，支持端只要一变动，很可能客户端会受到连动。
所以，在建构依赖关系时，被依赖的支持端愈稳定愈好，像是在BCE 模式的概念中，您会发现边界对象、控制对象比较不稳定，所以我们不让稳定的实体对象依赖它们，避免因此而导致整个结构的不稳定。
总之，如果两对象之间已经存在静态关系时，可以优先使用静态关系交互，而且记得要将静态关系保存在数据库中。
如果两个对象之间没有静态关系，也可以建立暂时性的依赖关系，以便进行交互，而且用完即丢，不需要费心保存在数据库中。
4.2.2泛化关系泛化关系（generalization relationship）是一种分类关系；针对同一种概念的事物，区分成一般性的（general）和特定性的（specific），然后再构建起两类之间的一般性关系。
例如，在订房系统中，我们可以将景观图片分为两大类：酒店图片和房型图片。
相较于原先的景观图片，酒店图片和房型图片两者都属于较为特定的图片，因此我们可以通过泛化关系构建出三者的关系，如图4-3 所示。
在泛化关系中，有个很重要的特色是，子对象可以替代父对象；这是因为子类继承了父类的特征，具体来说，子类可以通过泛化关系继承父类的属性、操作与静态关系。
还记得，前面我们说过静态关系是指关联，而组合关系则是关联的一种。
所以，请看图4-5 的例子，虽然酒店图片和房型图片并未定义任何属性、操作和关系，但其实它们已经拥有景观图片已经定义好的属性、操作和关系了，这就好比小孩继承了父母留下来的财产一样。
不过，在图4-5 的例子中，如果我们不想继承关系，可以改成图4-6 的设计，特别注意原来图4-5 中0..1 的多重性，到了图4-6 中则改成了1，这样才是正确的多重性。
再者，继承而来的属性、操作和关系，也可以在子类处“重新定义（redefine）”，不一定要全盘接受。
例如，在景观图片中的“场所”属性并没有默认值，继承之后，我们在它的子类处加上了默认值，重新定义了场所，如图4-7 所示。
4.2.3保护等级虽然，通过泛化关系，子类可以继承父类已经定义好的属性、操作和关系。
不过，要是父类将这些成员定义成私有等级（private）的话，子类虽然还是可以继承，但是却无法在子类中直接访问私有成员，使用上颇为不便。
特别是属性，一般为了封装性，都会建议设置成私有等级可见性。
4.2.5类层级之前，我们所看到的属性和操作都属于“对象层级（object-scoped, instance-scoped）”，代表该类所生成的每一个对象都拥有一份对象层级的属性，而且外界也只能通过对象调用对象层级的操作。
相对的，有另一种称为“类层级（class-scoped, classifier-scoped）”的属性与操作，代表整个类共享一份属性，而且外界只要通过类就可以调用操作，不需要先生成对象。
例如，在订房系统中，会员类内部的“验证”操作，要是设置为类层级的操作，或许会比设置为对象层级的操作，更为恰当。
因为，当我们请会员进行验证时，其实根本就还没有正确找出某一个会员对象，所以可能不是请某一个会员对象来进行验证，而是应该找会员类先进行验证，通过验证之后，再找出正确的会员对象才对。
所以，如图4-13 所示，类层级的属性与操作名称有下划线，之前我们看到没有下划线的属性或操作都属于对象层级的。
还有，由所有会员对象共同维护一份会员总数量即可，所以这个属性也适合设置成类层级的属性。
另外，其他像生成对象、删除对象的操作，其实都适合设置成类层级，因为在对象生成之前，该对象根本不存在，怎么能请这个对象执行生成自己的动作呢？至于删除对象也应该同样交给所属类来执行，或许会比请对象自动释放，要合适得多。
4.2.7枚举类型前面，我们都在谈类或对象，最后我们来看一个特殊的数据类型（data type）概念，即“枚举类型（enumeration）”。
枚举类型也采用矩形图标，不过名称上面多了<<enumeration>>的字眼，而且除了属性和操作外，矩形内部最底部多了一行放置“枚举值（enumerationliteral）”，如图4-15 所示。
4.3从面向对象到关系型数据库在UML 中，系统以对象的方式在运行，当然也包含以对象的方式存储在数据库中。
可是，实际工作的中，并不总是如此完美，虽然面向对象数据库（Object-Oriented Database，OODB）已经发展多年，但关系型数据库却是目前的主流技术。
所以，从面向对象到关系型数据库，一直是一个鸿沟，却也是许多年来微软等大厂商一直努力投入的主题。
所幸，近年来，关于“对象关系映射（Object-Relational Mapping, ORM）”技术有较大的进展，例如，Java 阵营发展出来的Hibernate，或是微软自家发展出来的“实体框架（Entity Framework）”，填补了面向对象与关系型数据库之间的鸿沟。
因此，很幸运地，我们可以比过去的前辈们，更专心在面向对象技术中，无须太过担心数据库端的转换。
本书假设后端采用关系型数据库，而且我们也不愿意花时间绘制实体关系图（ERD）的情况下，设计师可以选择在类中加入关系型数据库的“主键（Primary Key，PK）”和“外键（foreign key, FK）”的概念，让实体类图可以一图两用，同时落实到程序代码和关系型数据库。
特别注意到，在面向对象的程序设计中，对象之间通过连接就可以连接到对方，因此类之间有静态关系，也就不需要额外加入键值，特别是外键的概念。
所以，如4-17 所示，每一个类中的属性都是自己的属性，并没有抓别的类的属性过来当外键。
4.4酒店联合订房系统4.4.1用例——会员登录在会员登录用例中，主要用到“会员”实体类，如图4-20 所示。
至于主键的部分，之前举例时已经加工过了，这里就不再说明了；外键的部分，等出现与其他类之间的静态关系，再来修改。
4.4.2 用例——查询酒店数据“查询酒店数据”用例很简单，连控制对象都没设置，仅做数据库查询的工作，它的BCE 类依赖关系如图4-22 所示。
在图4-23 中，有几个重点，如下：1. 在景观图片的部分，我们并没有使用前面谈到的泛化架构，而是让酒店和房型都连到这个景观图片。
所以，景观图片的外键会有两个来源，一个是来自酒店，另一个来自房型。
因此，另外取了“场所序号（placeNumber）”做为景观图片的外键名称。
2. 再者，我们为景观图片的“场所（place）”属性，设计了一个PicturePlace 枚举类型，其枚举值有酒店和房型两个。
3. 至于酒店序号也一并通过“自动生成序号（NumberGenerator）”公有类自动生成。
4.4.3 用例——查询房型数据见图4-24 关于“查询房型数据”的BCE 类图，其中的“景观图片（Picture ）”实体类前面已经加工过了，所以这里就仅列出实体类的图标，把它的属性和操作隐藏起来了。
接着，加工后的如图4-25 所示，几项重点内容介绍如下：1. 房型类中的“计算房价”操作，一直都还没用到，所以我们就先把它删除了，日后有需要再补上。
2. 由于订房系统中可能会用到房间（Room ） 类， 所以这里的“房型”就翻译成“RoomType”了。
3. 还有，房型类已经有“床型（bed ）”属性了，所以似乎不再需要用到“种类”属性，所以我们也把这个属性删除了。
4. 再者，房型名称是指酒店经营者为房型取的名称，例如，尊贵总统房、紫色浪漫屋之类的房型昵称。
5. 自动生成序号（NumberGenerator ）公有类增加了一个“产生房型序号（generate-RoomTypeNumber ）”的操作，所以我们又将这个类更新了一次。
4.4.6 类图还记得，我们在第2 章的末尾，汇总了一张类图，我把它贴到图4-30 中。
在后续发展的用例中，都暂时没用到“入住”和“房间”这两个实体类，所以我想先删除它们，让类图简单些，如果我们分析新的用例使用到新的实体类，再来扩展实体类图好了。