当前位置：文档之家 › 第3章类图、对象图和包图

第3章类图、对象图和包图

  • 格式：ppt
  • 大小：710.50 KB
  • 文档页数：27

下载文档原格式

  / 27

合集下载

UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明画法和功能

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）角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.UML类的符号是一个被划分成三块的方框：类名，属性，和操作.抽象类的名字，像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association－表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中，关联用两个类之间的连线表示.dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.。

UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明书画法和功能

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）标准文档角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求标准文档∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.标准文档UML类的符号是一个被划分成三块的方框：类名，属性，和操作.抽象类的名字，像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association－表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中，关联用两个类之间的连线表示.标准文档标准文档为了简单地表示出复杂的类图，可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型.dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.标准文档这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.标准文档每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.标准文档协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.标准文档对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.标准文档我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及 Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.标准文档状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和 Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.标准文档标准文档标准文档。

软件工程(第四版)习题及解答1-7

软件工程(第四版)习题及解答1-7
（2）在左侧浏览器区域用鼠标右键单击用例视图（Use Case View）文件夹节点，然后选择【New】菜单|【Use Case Diagram】选项，新建一个用例图，可根据需要重新命名用例图名称如book，参考图6.31所示。
判定树:
Байду номын сангаас重量<=2Kg——12元
重量>2Kg且<=20Kg——6W元
重量>20Kg——6.5(W-20)+120
重量<=2Kg——24元
重量>2Kg且<=20Kg——12W元
重量>20Kg——13(W-20)+240
6．
设汇款金额为W元。判定树如下：
汇额本埠/外埠汇费
<=200 ----------------------- 2元
scd = fst
fst=k[i]
T
F
k[i]>scd
Scd=k[i]
I=i+1
输出fst,scd
（3）求s=1- 1/2!+1/3!-1/4! +…. +1/n!，其中n的值由键盘输入。
PAD图如下：
2．根据伪码画PAD图
3．将程序流程图转化为PAD图
（1）
（2）
（3）
（4）
（5）
对于分支结构
if(f)
3、（1）模块功能的完善化（2）消除重复功能，改善软件结构（3）模块规模应该适中（4）模块的深度、宽度、扇出和扇入都应适当（5）模块的作用范围应该在控制范围之内（6）力争降低模块接口的复杂程度（7）设计单入口、单出口的模块（9）模块功能应该可以预测
四、应用题
1、模块A和B是数据耦合，模块B是功能内聚。

UML中文课件-用例图类图对象图包图

UML中文课件-用例图类图对象图包图
扩展用例依赖于被扩展用例（基本用例），它不是完 整的独立用例，无法单独执行，因此一定没有活动者 指向扩展用例；
扩展用例不一定每次都被执行和调用。 扩展用例
-12-
用例间的关系3-泛化关系（ generalization）
一个用例和其几种情形的用例间构成泛化； 往往将父用例用抽象用例（abstract）表示（即，父用例
-54-
3 客房预订分析
客房预订涉及到“学生”，“订单”，“宾馆”和“客房” 几个类
假设一个订单可以预订到多个客房。
-55-
4 画出完整类图
-56-
本章目录
2.1 UML结构 2.2 物件 2.3 关系 2.4 公共机制 2.5 构架
2.6 UML图概述 2.7 用例图 2.8 类图 2.9 对象图和包图 2.10 顺序图和通信图 2.11 状态图和活动图 2.12 组件图和部署图
而在OrderItem中有一个stateChange ()方法和 deliverState，不难猜出它就是用于改变其“是否交给 收货人”标志位的。
-29-
先调用Order的dispatch ()方法，它将根据其包含的 OrderItem中产品信息，来按供应商户分拆成若干个 DeliverOrder。商户登录系统后就可以获取其 DeliverOrder，并在执行完成后再调用close ()方法。 此时，就将调用OrderItem的stateChange()方法来改 变其状态。同时再调用Order的close()方法，判断该 Order的所有的OrderItem是否都已经送到了，如果是 就将其真正close()掉。
-37-
-38-
2.8.4 类图的构建步骤
类图的构建步骤 一个关于图书馆图书借阅管理的类图 一个实现旅游宾馆预订的类图

对象图,包图,序列图教案

对象图,包图,序列图教案

int i; do //倒数 { i = dc.count(); Console.Write(i + "，"); } while (i > 0); Console.WriteLine(); do //正数 { i=uc.count(); Console.Write(i+"，"); }while((i<uc.goal)); Console.WriteLine();
namespace space2 //第二个命名空间 { class UpCount //正数计数器 { private int v; public int goal; public UpCount(int n) //从0至n输出 { goal= n; v = 0; } public void reset(int n) { goal = n; v = 0; } public int count() { if (v < goal) return v++; else return goal; } } //在此可建立其他的类 }
对象是系统的详细状态在某一时刻的快照，通常用来 表示复杂类图的一个实例
• 在跟踪系统的交互过程时，往往会涉及到系统 交互过程的某一瞬间交互对象的状态，但系统 类图并没有对此进行描述。 • 在UML中引入对象图，用于描述一个参与交互 的对象在交互过程中某一时刻的状态。 • 对象图（Object Diagram）是描述在某一时刻， 一组对象以及它们之间关系的图形。 • 对象图是描述系统交互的静态图形，它由协作 的对象组成，但不包含在对象之间传递的任何 消息。
引入包
定义包
命名空间的嵌套： 程序中的命名空间就如同文件和文件夹。文件夹包含许多文 件和其他文件夹，同样，命名空间也可以包含其他命名空间。

UML实践----用例图、顺序图、状态图、类图、包图、协作图

UML实践----用例图、顺序图、状态图、类图、包图、协作图

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描述了作为一个外部的观察者的视角对系统的印象。

UML-03-类图-对象图-包图




类 接口 协作 依赖、泛化和关联关系
类图可以包含注解和约束； 类图还可以有包或子系统，二者都用于把 模型元素聚集成更大的组件。
类(Class)
A class is the descriptor for a set of objects with similar structure, behavior, and relationships.
课堂练习-网上书店系统





通过Internet接受订单 一个顾客可以拥有一个帐号，系统维护顾客最多达 1000000个的帐号 对所有的帐号提供密码保护 能够搜索标准的图书目录 提供多种搜索图书目录的方法，包括按作者搜索、按书名 搜索、按ISBN搜索、按关键字搜索 本系统采取货到付款的方式 根据顾客的定购量确定书价折扣 顾客可以发表图书评论 装货站工作人员负责根据订单装货 收货站工作人员确保商品数量同订单相符
类图的三个层次的例子
概念层
说明层
实现层
建立类图的一般步骤
1. 研究分析问题领域 2. 发现对象与类，明确它们的含义和责任，确定属 性。 3. 发现类之间的关系。把类之间的关系用关联、泛 化、聚集、组合、依赖等关系表达出来。 4. 设计类与关系。调整和细化已得到的类和类之间 的关系，解决诸如命名冲突、功能重复等问题。 5. 绘制类图并编制相应的说明。
对象图与类图
对象图的模型元素有对象和链(link)。对象是类 的实例；对象之间的链是类之间的关联的实例。 对象与类的图形表示相似，UML中对象图与类图 具有相同的表示形式。
对象图实质上是类图的实例。
对象图常用于表示复杂的类图的一个实例。 对象图的使用相当有限，主要用于表达数据结构 的示例，以及了解系统在某个特定时刻的具体情 况。

第3章 类图、对象图和包图.

用指定语言对系统进行描述； 除与问题无关或关系不大 从系统描述中标名名词、名词短的语类、名；词（性3）代删词除；模糊的类
或独立性不强的类：有些 识别、确定（取、舍）类； 初始类边界定义不确切，
或范围太广，应该删除。 为 统了分发析现的对文象档和中类查，找开名发词（作人和为4）员名对所要词象描在短类述系语，的统，并操需包被作求括其不和：自适系可身宜 感知的事物、角色、事件所、操互纵相，作所用描、述人的员只、是场实 所、组织、设备和地点等现。过程中的暂时的对象，
• 为类建模是一件重要而困难的事，因为并不存 在一个固定的模式和确定的过程，即使对于同一 应用领域项目，不同的系统分析员所得到的类及 其属性的集合也可能会不同，应该以用户的满意 度为标准。为类建模的过程是一个高度迭代增量
式的过程 。
10
• 掌握以下基础知识对类的成功设计是至关重要的： • （1）学习掌握为类建模的知识； • （2）对应用领域的正确、深入的理解； • （3）学习研究相似的和成功的设计经验； • （4）超前思维和预测结果的能力； • （5）不断精化模型和修正缺陷的实践。
类的识别是面向对象方法的一个难点，但又是 建模的关键。常用的方法有：
1、名词识别法
2、系统实体识别法
3、从用例中识别类
4、利用分解与抽象技术
注意：（1）关键是要定义类的“属性”及“操作”。 （2）抓住主要“属性”。
名1词、识性名别代词问词识题的别中形法的式实出体现，。实体的描专述描并根类个留家通述遵概最据类：共常过循念具下表(1同用)程问和有述述去名合命应 题描原 同掉词作与 域名述则 一冗、完领 中。能进 信余名成域 的力一 息类词，的步 ，：短类确 应如语。定 保、两 （2）去掉不相干的类：删
要资源，是逆向工程（将代码转化为模型）的生

UML复习题选填简答整理

第一章UML入门填空：1、如果把众多事物进行归纳和分类，那么所依据的面向对象的特性是抽象。

2、面向对象中的表示层用于提供给用户使用和显示的界面。

3、UML中的元元模型层位于结构最上层，是组成UML最基本的元素，代表要定义的所有事物。

4、在UML2.0中用来表示类、组件、协作等模型元素内部结构的是组合结构图。

5、UML中的实现关系使用一条空心三角作为箭头的虚线作为其图形表示。

选择：1、下列不属于对象特性的是。

A、对象都是唯一的B、一滴水是一个对象C、一个对象肯定属于某个类别D对象必须是可见的2、如果要解决系统做什么应该使用。

A、面向对象的分析B、面向对象的设计C、面向对象的编程D、面向对象的开发3、面向对象中的描述了系统内部对象及其关系的静态结构。

A、对象模型B、状态模型C、交互模型D、类模型4、UML中的用于描述系统的实现模块以及它们之间的依赖关系。

A、组件视图B、用例视图C、逻辑视图D、部署视图5、下列不属于UML2.0中图的是。

A、协作图B、包图C、交互图D、组合结构图6、下列UML事物中表示协作的是。

A、B、C、D、InterfaceName简答题：1、简要说明UML中视图与图的关系。

答：UML的视图都是由一个或多个图组成的，图就是系统架构在某个侧面的表示，所有的图一起组成了系统的完整视图。

第二章用例图填空题：1、用例图标准关系有扩展、泛化关系、关联关系和包含关系。

2、用例图的组成有关系、系统、参与者和用例。

3、在UML中，用例用一个圆形来表示。

4、泛化关系使用一条实线和一个三角箭头来链接用例。

选择题：1、下列说法正确的是。

A.用例间的关系是后期开发需要的，对用例图没有影响。

B.扩展关系可以是用例间的，也可以是参与者间的。

C.泛化关系可以是用例间的，也可以是参与者间的。

D.包含关系表示为虚线箭头。

2、下列符号中表示扩展的是。

A. B. C. <<extends>>D. <<extends>>简答题：1、用例描述主要包括哪些方面？答：用例描述一般包括有：名称、标识符（可选）、参与者（可选）、状态（可选）、频率、前置条件、后置条件、假设（可选）、基本操作流程、可选操作流程、修改历史记录（可选）2、泛化描述了什么？答：泛化描述的是子用例与父用例的关系，子用例是父用例的特化，它除了可以具有父用例的特性外，还可以有自己的另外特性。

第三章 类图


3.1 类图的概念
图3-1电子商务网站的对象模型
3.1 类图的概念
2、类图的作用 类图常用来描述业务或软件系统的组成、结构和关系。
3、类图的组成元素 类 接口 协作 关系 注释 约束 包
3.2 UML中的类
１、类的表示 （１）类的定义
类是具有相似结构、行为和关系的一组对象的描述 符。 （２）类的表示
关于聚合与组合
2、泛化-Generalization
表示两个类元间“一般”与“特殊”的关系。 对应面向对象编程语言中类与类之间的继承关系。 “is a kind of”关系，XX是一种XX
Athlete
SwimmerBiblioteka Golfer3、实现-Realization
表达一种说明元素与实现元素之间的关系； 类和接口之间的关系是实现关系，表示类实现接口提供的
3.2 UML中的类
（７）类的约束 约束指定了类所要满足的一个或多个规则。 在UML中，约
束是用花括号括起来的自由文本。
Washing Machine
Brand name Model name Serial number Capacity Add clothes( ) Add detergent( ) Remove clothes( )
表示客户与提供者之间用不同的方法表现同一个概念， 通常一个概念更抽象，一个概念更具体。包括：
① 跟踪<<trace>>--声明不同模型中的元素之间存在一些 连接但不如映射精确。
② 精化<<refine>>--声明具有两个不同语义层次上的元 素之间的映射。
③ 派生<<derive>>--声明一个实例可以从另一个实例导 出。
  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Computer
CPU
Monitor
11
3.2.5 组成
• 在类的众多关系中，再加强一步的耦合是组合关系。它与 聚合关系的异同之处在于组成的关联中，整体类同样都是 由部分类组成，但是部分类需要整体类才能存在，当整体 类被销毁时，部分类将同时被销毁。这正是组合所表达的 内涵：为组成类的内在部分建模。表示组成关系的符号与 聚集关系类似，但是端末的菱形是实心的。
DBEmployee
1 0..* 1 0..*
TableEmployee
TableSalory
12
3.3 泛化关系
• 泛化和继承用于描述一个类是另一个类的类型 。应用程序中通常会包含大量紧密相关的类，如 果一个类A的所有属性和操作能被另一个类B所继 承，则类 B 不仅可以包含自己独有的属性和操作 ，而且可以包含类 B 中的属性和操作，这种机制 就是泛化。在解决复杂问题时，通常需要将具有 共同特性的元素抽象成类别，并通过增加其内容 而进一步分类。例如，车可以分为火车、汽车、 摩托车等。泛化（Generalization）关系描述了一 般事物与该事物的特殊种类之间的关系。
Store +store(in art:Article) +retrieve()
3.7 接口
• 如果想要声明具体类应该实现的方法，但因为一个继承 关系而不想使用抽象类，那么可以使用接口（Interface ）。在进行系统建模时，接口起到十分重要的作用，因 为模型元素之间的协作是通过接口进行的。可以为类、 组件和包（随后将会介绍组件和包的概念）定义接口， 利用接口说明类、组件和包能够支持的行为。一个结构 良好的系统，通常都定义了比较规范的接口。 • 接口是一组没有相应方法实现的操作，非常类似于仅包 含抽象方法的抽象类。接口是对对象行为的描述，但是 并不给出对象的实现和状态。接口只包含操作而不包含 属性，并且接口也没有对外界可见的关联。一个类可以 实现多个接口。使用接口比使用抽象类要安全得多，因 为它可以避免许多与多重继承相关的问题。这也是为什 么像Java和C#等新型编程语言允许类实现多个接口，但 只能继承一个通用或抽象类。
1
本章学习要点：
• • • • • • • 理解类图的基本概念 为系统建模类 建模类之间的关联关系 理解并建模泛化关系 了解依赖关系和实现关系 了解对象图和包图的概念 构造类图
2
3.1 类图
• 构建面向对象模型的基础是类、对象以及它们之间的 关系。可以在不同类型的系统（例如，商务软件、嵌入式 系统、分布式系统等）中应用面向对象技术，在不同的系 统中描述的类可以是各种各样的。例如，在某个商务信息 系统中，包含的类可以是顾客、协议书、发票、债务等； 在某个工程技术系统中，包含的类可以有传感器、显示器 、I/O卡、发动机等。 • 在面向对象的处理中，类图处于核心地位，它提供 了用于定义和使用对象的主要规则，同时，类图是正向工 程（将模型转化为代码）的主要资源，是逆向工程（将代 码转化为模型）的生成物。因此，类图是任何面向对象系 统的核心，类图随之也成了最常用的UML图。
7
3.2.1 二元关联
• 关联意味着类实际上以属性的形式包含对 其他类的一个或多个对象的引用。在确定了参 与关联的类之后，就可以对关联进行建模了。 本章首先讨论只有两个类参与的关联，即二元 关联，稍后将会介绍多于两个类参与的关联， 即n元关联。在类图中，二元关联定义了两个类 的对象之间的关系准则，关联定义了什么是允 许的，什么是不允许的。如果两个类在类图中 具有关联关系，那么在对象图中，这两个类的 相应对象所具有的关系被称为链。关联描述的 是规则，而链描述的是事实。
ClassC
<<use>>
ClassA
17
3.5 构造类图模型
• 通过分析用例模型和系统的需求规格说明，可以初步构 造系统的类图模型。类图模型的构造是一个迭代的过程 ，需要反复进行，随着系统分析和设计的逐步深入，类 图会越来越完善。 • 系统对象的识别可以从发现和选择系统需求描述中的名 词开始进行。从图书管理系统的需求描述中可以发现诸 如借阅者（Borrower）、图书（Book）、图书标题（ Title）借阅信息（Loan）等重要名词，可以认为它们都 是系统的候选对象，是否需要为它们创建类可以通过检 查是否存在与它们相关的身份和行为进行判断，如果存 在，就应该为相应的候选对象在类图中建立模型。
8
3.2.2 关联类
• 有时关联本身会引进新类。当想要显示一个 类涉及到两个类的复杂情况中，关联类就显得特 别重要。关联类就是与一个关联关系相连的类。 关联类并不位于表示关联关系的直线两端，而是 对应一个实际的关联，用关联类表示该关联的附 加信息。关联中的每个连接与关联类中的一个对 象相对应。 • 虽然类的属性描述了类实例所具有的特性， 但有时却需要将对象的有关信息和对象之间的链 接放在一起而不是放在不同的类中。
5
3.1.3 定义类
• 由于类是构成类图的基础，所以，在构造类图之前，首先要 定义类，也就是将系统要处理的数据抽象为类的属性，将处理数 据的方法抽象为类的操作。要准确地定义类，需要对问题域有透 彻准确地理解。在定义类时，通常应当使用问题域中的概念，并 且，类的名字要用类实际代表的事物进行命名。 通过自我提问和回答下列问题，将有助于在建模时准确地定 义类： 在要解决的问题中有没有必须存储或处理的数据，如果有， 那么这些数据可能就需要抽象为类，这里的数据可以是系统中出 现的概念、事件或者仅在某一时刻出现的事务。 有没有外部系统，如果有，可以将外部系统抽象为类，该类 可以是本系统所包含的类，也可以是能与本系统进行交互的类。 有没有模板、类库、或者组件等，如果有，这些可以作为类。 系统中有什么角色，这些角色可以抽象为类，例如，用户、客户 等。 系统中有没有被控制的设备，如果有，那么在系统中应该有 与这些设备对应的类，以便能够通过这些类控制相应的设备。
13
3.3.1 泛化的含义和用途
• 泛化关系是一种存在于一般元素和特殊元素之间 的分类关系。这里的特殊元素不仅包含一般元素 的特征，而且包含其独有的特征。凡是可以使用 一般元素的场合都可以用特殊元素的一个实例代 替，反之则不行。 • 泛化关系只使用在类型上，而不用于具体的实例 。泛化关系描述了“is a kind of”（是……的一种 ）的关系。例如，金丝猴、猕猴都是猴子的一种 ，东北虎是老虎的一种。在采用面向对象思想和 方法的地方，一般元素被称为超类或者父类，而 特殊元素被称作子类。
3
3.1.1 概述
类图是描述类、接口以及它们之间关系的图 ，它显示了系统中各个类的静态结构，是一种静 态模型。类图根据系统中的类以及各个类的关系 描述系统的静态视图。可以用某种面向对象的语 言实现类图中的类。 类图是面向对象系统建模中最常用和最基本的 图之一，其他许多图，如状态图、协作图、组件 图和配置图等都是在类图的基础上进一步描述了 系统其他方面的特性。类图中可以包含了7个模 型元素，它们分别是：类、接口、依赖关系、泛 化关系、关联关系和实现关系等模型元素。在类 图中也可以包含注释、约束、包或子系统。
18
3.6 抽象类
• 使用泛化声明一个很好、可重用的通用类时，有此情况下 是无法实现此通用类需要的所有行为。例如，如果正在实 现一个Store类，该类包含两个操作store和retrieve，分别 实现了储存和检索文件的功能。但如何存储到文件、存储 到什么文件、如何检索文件等都是不确定的，这些都必须 留待子类决定。 • 为通过声明操作是抽象的，以指明store和retrieve操作的 实现将由子类决定，应以斜体字表示这些操作。如图3-47 所法：
Animal
Animal {constraint} Tiger Monkey
{constraint}
Tiger
Monkey
16
3.4 依赖关系和实现关系
模型元素之间的依赖关系描述的是它们之间语义上的关系。 当两个元素处于依赖关系中时，其中一个元素的改变可能会影响 或提供消息给另一个元素，即一个元素以某种形式依赖于另一元 素。在 UML 模型中，模型元素之间的依赖关系表示某一元素以 某种形式依赖于其他元素。从某种意义上说，关联关系、泛化关 系和实现关系都属于依赖关系，但是它们都有其特殊的语义，因 而被作为独立的关系在建模时使用。依赖关系用一个一端带有箭 头的虚线表示，在图 3-42 中，类 ClassC依赖于类 ClassA。在实 际建模时，可以使用一个构造型的关键字来区分依赖关系的种类 ，如图。
第3章 类图、对象图和包图
使用面向对象的思想描述系统，能够把复杂的系统简 单化、直观化，这有利于用面向对象的程序设计语言实现 系统，并有利于未来对系统的维护。构成面向对象模型的 基本元素有类、对象和类与类之间的关系等。类图和对象 图合称为结构模型视图或者静态视图，用于描述系统的结 构或静态特征。其中，类图用来描述系统中的类以及类与 类之间的静态关系等；对象用来描述特定时刻实际存在的 若干对象以及它们之间的关系。一个系统的模型中可以包 含多个对象图，每个对象图描述了系统在某个特定时刻的 状态。
6
•
• • • • •
3.2 关联关系
在使用面向对象的思想和方法开发的系统中， 使用类来描述应用程序所需资源的类型、目的和 它们所提供的特征（例如属性和操作）。除了需 要使用类定义软件所需的资源之外，在建模过程 中还需要描述资源之间的交互情况，以解释对象 之间是如何进行通信的。为了进行通信，对象之 间也需要定义通信手段，在UML规范中，对象之 间的通信手段就称为关系。 类图中的关联定义了对象之间的关系准则， 在应用程序创建和使用关系时，关联提供了维护 关系完整性的规则。
9
3.2.3 或关联与反身关联
• 前已述及，一个类可以参与多个关联关系，但是当两个关 联不能同时并存时，应该怎样表示呢？ • 图是保险业务的类图。个人可以同保险公司签订保险合同 ，其他公司也可以同保险公司签订保险合同，但是个人持 有的合同不同于一般公司持有的合同，也就是说，个人与 保险合同的关联关系不能跟公司与保险合同的关联关系同 时发生。UML提供了或关联来建模这样的关联关系。