下载文档原格式
UML建模课程实验三、UML类图、对象图模型的设计班级：信息0702 组别：指导老师：徐凯波姓名：王姗学号：2007030331205一、实验要求：掌握利用UML建模工具建立类图和对象图的方法。
二、实验内容：利用UML建模工具设计类图和对象图三、实验环境：Windows 2000 Professional以上环境、Rational Rose2003、Sybase Power Designer 10四、操作步骤：五、遇到的问题和解决方法：类图是所有图中比较好画的一种图，就是将角色、系统它们所具有的属性和活动输入到软件中去，我的类图中角色有管理员、学生，管理员的属性有：管理学的账号、管理员的姓名、管理员的性别、管理员的年龄，他所参与的活动有添加课程信息、删除课程信息、修改课程信息、查询课程信息、登录系统、添加学生信息、删除学生信息、修改学生信息、查询学生信息、查询学生信息；学生的属性有：学生账户、学生姓名、学生性别、学生年龄，他所参与的活动有：查询课程信息、选课、查询个人选课信息，登录系统。
系统的包括：学生信息维护系统、课程管理系统、选课管理系统，学生信息维护系统的属性有：学生的账号、姓名、性别、年龄、管理员的账号；选课管理系统：学生账号、课程编号、课程名称、课程地点、课程时间、课程学分、课程学时；课程管理系统：课程编号、课程名称、课程地点、课程时间、课程学分、课程学时。
在画整个类图的过程中，我没有遇到太多的问题。
六、实验心得和体会：在老师的辅导下，我经过前一阶段的练习，基本掌握了UML的要领，类图我基本上没有太费时间，只是想好属性和动作，还有就是个角色之间的关系，类图的难点是角色与角色之间的关系，究竟是一对多、一对一、多对多。
确定好角色与角色的关系，类图就很容易完成了。
设计题目：类图与对象图的建立一、实验目的1．熟悉类图的基本功能和使用方法。
2．掌握如何使用建模工具绘制类图方法。
二、实验内容1、分别设计“图书馆管理系统”、“汽车租赁系统”、“网络教学系统”和“网上图书销售系统”的类图。
汽车租赁系统：网络教学系统：网上图书销售系统：2、假设你是一个系统分析员，要建立篮球比赛模型。
现在你正在会见一名教练员来了解比赛规则情况。
谈话的过程可能如下:分析员：“教练，请大致介绍一下篮球比赛”教练员:“比赛的目标是要把篮球投入蓝框并且要尽量比对手得更多的分。
每个篮球队由5名队员组成:两名后卫、两名前锋和一名中锋。
每个队要将球推进到篮框附近，将篮球投中篮框。
”分析员:“如何将球推进?”教练员:“通过运球和传球。
但是某一方必须在规定的进攻时间内投篮。
”分析员:“规定的进攻时间?”教练员:“是的，在某一方获得控球权后，必须在规定的进攻时间内投篮。
美国职业篮球比赛是24秒，国际篮球比赛是30秒，美国大学篮球比赛是35秒。
”分析员: “如何计算篮球比赛得分？教练员: “三分线之内每投中一次篮框得两分，三分线之外投中一次得三分。
一次罚球得一分。
顺便说一下，罚球是对方犯规后判罚的投球。
如果某一个队员犯规，则比赛暂停，由被侵犯的队员在罚球线处罚球。
”分析员: “再详细说明一下每个篮球队员在比赛中的情祝好吗?”教练员: “后卫队员通常主要是运球和传球。
他们一般都比前锋队员矮，前锋队员通常又比中锋矮。
所有的队员必须都要能运球、传球、投球、抢篮板球，大部分抢篮板球和中距离投篮都由前锋队员完成，而中锋通常离篮框最近，一般由他来篮下进攻。
”分析员:“场地大小如何?另外，每场比赛时间是多少?”教练员:“国际比赛场地为28米长、15米宽。
篮框离地面3.05米高。
在美国职业篮球比赛中，一场比赛为48分钟，分为4节，每节12分钟。
在美国大学和国际比赛中，一场比赛40分钟，分为上下两个20分钟的半场。
有专门的比赛时钟记录比赛还剩下多少时间。
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业务建模实例分析在我国十年前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. 验证类图完成类图之后，我们需要对其进行验证。
通过使用类图工具提供的功能，我们可以对类图进行语法和语义的检查，确保其符合规范和逻辑。
在验证过程中，我们还可以运行类图生成代码，并进行功能测试，以验证类图的正确性和可用性。
三、实验结果通过以上的实验过程，我们成功地完成了学生选课系统的类图设计。
该类图清晰地展示了学生、课程和教师三个核心类之间的关系，以及类的属性和方法。
经过验证，该类图符合规范和逻辑，能够正常生成代码并实现系统功能。
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（Unified Modeling Language）是一种用于软件系统设计、描述和分析的标准建模语言。
在软件开发过程中，使用UML类图可以更好地理解和展示系统的结构和关系，帮助开发人员更好地进行软件设计和开发。
本文将分享一些UML类图建模的细节和规范实战经验。
1. 类与对象的关系在UML类图中，类和对象是两个重要的概念。
类代表一类具有相同属性和行为的对象，而对象则是类的实例。
在建模过程中，我们需要清晰地定义类与对象之间的关系。
首先，要注意类与对象之间的关联关系。
关联关系表示类之间的相互连接，可以是单向的、双向的或者多重的。
在建模时，要明确关联的名称、方向和多重性，以便更好地描述类之间的交互。
其次，要注意类与对象之间的依赖关系。
依赖关系表示一个类的实现需要另一个类的支持，通常体现为方法的参数或者返回值。
在建模时，要明确依赖的方向和类型，以便更好地理解类之间的依赖关系。
2. 类的属性与方法在UML类图中，类的属性和方法是描述类的重要元素。
属性表示类的特征和状态，而方法表示类的行为和操作。
在建模过程中，我们需要注意合理地定义类的属性和方法。
首先，要注意属性的可见性。
属性可以是公有的、私有的或者受保护的，这取决于属性是否对外可见和可访问。
在建模时，要根据实际需求和设计要求，合理地定义属性的可见性。
其次，要注意方法的命名和参数。
方法的命名应该具有一定的规范和语义，以便更好地理解方法的功能和用途。
同时，方法的参数也需要明确定义和描述，以便更好地理解方法的输入和输出。
3. 继承与接口在UML类图中，继承和接口是描述类之间关系的重要机制。
继承表示一个类继承另一个类的属性和方法，而接口表示一个类实现了一组特定的方法。
在建模过程中，我们需要合理地使用继承和接口。
首先，要注意继承的使用。
继承应该符合"是一个"的关系，即子类是父类的一种特殊情况。
在建模时，要明确类之间的继承关系，以便更好地理解和展示类之间的层次结构。
第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 中。
在后续发展的用例中，都暂时没用到“入住”和“房间”这两个实体类，所以我想先删除它们，让类图简单些，如果我们分析新的用例使用到新的实体类，再来扩展实体类图好了。
