PowerDesinger联系的定义及使用


目标:本文主要介绍联系的定义及使用。

 一、 联系
联系(Relationship)是指实体集这间或实体集内部实例之间的连接。

 实体之间可以通过联系来相互关联。与实体和实体集对应,联系也可以分为联系和联系集,联系集是实体集之间的联系,联系是实体之间的联系,联系是具有方向性的。联系和联系集在含义明确的情况之下均可称为联系。

 按照实体类型中实例之间的数量对应关系,通常可将联系分为4类,即一对一(ONE TO ONE)联系、一对多(ONE TO MANY)联系、多对一(MANY TO ONE)联系和多对多联系(MANY TO MANY)。

 二、 建立联系
在CDM工具选项板中除了公共的工具外,还包括如下图所示的其它对象产生工具。

 在图形窗口中创建两个实体后,单击“实体间建立联系”工具,单击一个实体,在按下鼠标左键的同时把光标拖至别一个实体上并释放鼠标左键,这样就在两个实体间创建了联系,右键单击图形窗口,释放Relationship工具。如下图所示


三、 四种基本的联系
即一对一(ONE TO ONE)联系、一对多(ONE TO MANY)联系、多对一(MANY TO ONE)联系和多对多联系(MANY TO MANY)。如图所示

四、 其他几类特殊联系

除了4种基本的联系之外,实体集与实体集之间还存在标定联系(Identify Relationship)、非标定联系(Non-Identify RelationShip)和递归联系(Recursive Relationship)。

标定联系:
每个实体类型都有自己的标识符,如果两个实体集之间发生联系,其中一个实体类型的标识符进入另一个实体类型并与该实体类型中的标识符共同组成其标识符时,这种联系则称为标定联系,也叫依赖联系。反之称为非标定联系,也叫非依赖联系。
 注意:
在非标定联系中,一个实体集中的部分实例依赖于另一个实例集中的实例,在这种依赖联系中,每个实体必须至少有一个标识符。而在标定联系中,一个实体集中的全部实例完全依赖于另个实体集中的实例,在这种依赖联系中一个实体必须至少有一个标识符,而另一个实体却可以没有自己的标识符。没有标识符的实体用它所依赖的实体的标识符作为自己的标识符。


换句话来理解,在标定联系中,一个实体(选课)依赖 一个实体(学生),那么(学生)实体必须至少有一个标识符,而(选课)实体可以没有自己的标识符,没有标标识符的实体可以用实体(学生)的标识符作为自己的标识符。


 递归联系:
递归联系是实体集内部实例之间的一种联系,通常形象地称为自反联系。同一实体类型中不同实体集之间的联系也称为递归联系。

例如:在“职工”实体集中存在很多的职工,这些职工之间必须存在一种领导与被领导的关系。又如“学生”实体信中的实体包含“班长”子实体集与“普通学生”子实体集,这两个子实体集之间的联系就是一种递归联系。创建递归联系时,只需要单击“实体间建立联系”工具从实体的一部分拖至该实体的别一个部分即可。如图


五、 定义联系的特性

在两个实体间建立了联系后,双击联系线,打开联系特性窗口,如图所示。


 六、 定义联系的角色名
在联系的两个方向上各自包含有一个分组框,其中的参数只对这个方向起作用,Role Name为角色名,描述该方向联系的作用,一般用一个动词或动宾组表。
如:“学生 to 课目 ” 组框中应该填写“拥有”,而在“课目To 学生”组框中填写“属于”。(在此只是举例说明,可能有些用词不太合理)。

七、 定义联系的强制性
Mandatory 表洋这个方向联系的强制关系。选中这个复选框,则在联系线上产生一个联系线垂直的竖线。不选择这个复选框则表示联系这个方向上是可选的,在联系线上产生一个小圆圈。

八、 有关联系的基数
联系具有方向性,每个方向上都有一个基数。

举例,
“系”与“学生”两个实体之间的联系是一对多联系,换句话说“学生”和“系”之间的联系是多对一联系。而且一个学生必须属于一个系,并且只能属于一个系,不能属于零个系,所以从“学生”实体至“系”实体的基数为“1,1”,从联系的另一方向考虑,一个系可以拥有多个学生,也可以没有任何学生,即零个学生,所以该方向联系的基数就为“0,n”,如图所示


### PowerDesigner 中状态图与活动图的用法及区别 #### 状态图的核心概念 状态图(Statechart Diagram)是一种用于描述对象在其生命周期内的动态行为的工具。通过状态图,可以清晰地展现一个对象所经历的状态序列、触发这些状态变化的事件以及伴随的动作[^1]。 - **状态** 是指对象在一个特定时刻的表现形式。 - **事件** 是引发状态转换的因素。 - **动作** 则是在状态转换过程中执行的操作。 在 PowerDesigner 中创建状态图时,可以通过图形化界面定义不同的状态节点及其之间的转换条件和动作逻辑。这种图表非常适合对复杂系统的生命周期进行建模。 #### 活动图的关键特性 活动图(Activity Diagram)属于 UML 的一种动态行为图,主要用于展示系统内部的控制流和数据流[^4]。它的核心目标是对系统的动态视图进行建模,尤其适用于功能性和业务流程分析。以下是其几个显著特点: - 表达流程性的操作顺序。 - 支持并发行为的表示。 - 提供更抽象层次上的控制流视角,而不局限于具体的实现细节。 在 PowerDesigner 中构建活动图时,通常会涉及活动节点的设计,包括但不限于初始节点、决策节点、合并节点等。此外,还可以利用嵌套的方式进一步细化复杂的活动结构。 #### 两者的对比分析 尽管两者同属 UML 图表体系,但在实际应用中有明显差异: | 特性 | 状态图 | 活动图 | |--------------------|---------------------------------------------|-------------------------------------------| | 主要用途 | 描述单个对象的生命期动态行为 | 展现整个系统的控制流和数据流动态 | | 关注焦点 | 对象状态的变化 | 流程中的活动顺序 | | 节点类型 | 状态节点 | 活动节点 | | 是否支持并发 | 不直接体现并发 | 明确支持并发 | | 嵌套能力 | 较弱 | 强 | 从上述表格可以看出,虽然它们都能反映某种意义上的“动态”,但侧重点完全不同。例如,在设计自动化控制系统时可能更多依赖状态图来跟踪设备的工作模式切换;而在规划软件开发项目的任务分配上,则倾向于采用活动图以便更好地理解整体工作流。 另外值得注意的一点是关于活动状态的具体定义[^2]:作为一种特殊的非原子运行单元,它可以被细分为多个子活动或者动作状态,并且允许存在入口/出口动作甚至内部转移机制。这使得某些情况下难以严格区分简单的动作状态与更为复杂的活动状态界限变得模糊起来——当某项活动仅包含单一动作时即退化成了后者的一种特殊情况而已。 最后提到一点有关于如何具体运用PowerDesigner来进行这两种图表的实际制作方面[^3],用户需先新建相应类型的模型文件后再逐步添加所需元素完成最终作品呈现出来即可满足需求。 ```python # 示例代码片段:模拟简单状态机逻辑 class StateMachine: def __init__(self): self.state = 'idle' def handle_event(self, event): transitions = { ('idle', 'start'): 'running', ('running', 'stop'): 'idle' } current_state = self.state next_state = transitions.get((current_state, event)) if next_state is not None: self.perform_action(current_state, next_state) self.state = next_state def perform_action(self, from_state, to_state): print(f'Performing action: {from_state} -> {to_state}') machine = StateMachine() machine.handle_event('start') # 输出 Performing action: idle -> running ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值