UML 建模
76
UML建模/1 UML笔记之模型和视图.md
Normal file
@@ -0,0 +1,76 @@
|
||||
UML概念
|
||||
|
||||
UML的全称,统一建模语言(UML是 Unified Modeling
|
||||
Language的缩写)是用来对软件系统进行可视化建模的一种语言。UML为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。
|
||||
|
||||
**什么是模型**
|
||||
|
||||
> 模型是对现实世界的形状或状态的抽象模拟和简化。
|
||||
|
||||
**模型的分类**
|
||||
|
||||
描述系统的模型:软件模型分为逻辑模型和物理模型。逻辑模型描述未来系统用来做什么。物理模型描述未来系统做什么,规定了系统所采用的的技术,在设计阶段使用物理模型。
|
||||
|
||||
描述事物的模型:交通模型、建筑模型、设计模型、数据分析模型。用图形符号对现实世界中某个事物
|
||||
|
||||
**按照模型的用途分类:**
|
||||
|
||||
用例模型:表示业务系统或软件系统功能的模型。
|
||||
|
||||
对象模型:用来表示业务或软件系统的组成和结构。
|
||||
|
||||
动态模型:展现了系统的内部行文。包括顺序图、活动图、状态图。
|
||||
|
||||
**使用模型的理由最简单的理由:**
|
||||
|
||||
为了能够更好地理解正在开发的系统。通过建模,可以达到四个目的:
|
||||
|
||||
> 1、有助于按照需求对系统进行可视化的分析
|
||||
|
||||
> 2、能够系统的结构或行为
|
||||
|
||||
> 3、给出了知道构造系统的模板
|
||||
|
||||
> 4、对做出的决策进行文档化
|
||||
|
||||
UML中建模与视图
|
||||
|
||||
> 当我们用RUP软件开发模型开发软件系统时,可以从5个角度对软件系统进行建模,5个视图分别是用例视图、设计视图、构件视图、并发视图和部署视图,即从5个角度来描述系统的五个方面。在这五个视图中,以用例视图为目标,分别构造其它四个视图。
|
||||
|
||||
1.用例视图
|
||||
|
||||
描述了系统的功能和参与者,由多个用例图组成,是主要的需求模型。
|
||||
|
||||
2.设计视图
|
||||
|
||||
又称逻辑视图,描述了软件系统的组成、结构和行为,是软件系统的蓝图。该视图常由类图、交互图、状态图和活动图组成。
|
||||
|
||||
3.构件视图
|
||||
|
||||
描述了软件系统的组成成分,即软件发布时,系统包含的软件构件和文件。该视图常用构件图、交互图、状态图和活动图描述。
|
||||
|
||||
4.并发视图
|
||||
|
||||
描述系统各部分之间的同步和异步执行情况。该视图常用状态图和协作图来描述。
|
||||
|
||||
5.部署视图
|
||||
|
||||
描述了软件系统的各部分如何部署到各硬件节点上。该视图常用部署图、交互图、状态图和活动图描述。
|
||||
|
||||
下面是描述软件系统的5种视图,如图28所示。
|
||||
|
||||

|
||||
|
||||
图 2-28 软件系统
|
||||
|
||||
UML中七中视图
|
||||
|
||||
本文是我们主要介绍UML的七种视图,所谓一张图胜于千言万语,我们就用图来介绍UML的视图:
|
||||
|
||||
**UML的七种视图:**
|
||||
|
||||

|
||||
|
||||
**七种视图的基本含义:**
|
||||
|
||||

|
||||
155
UML建模/10 UML笔记之协作图.md
Normal file
@@ -0,0 +1,155 @@
|
||||
协作图概述
|
||||
|
||||
**协作**
|
||||
|
||||
> 包含一组对象和链,用于描述系统的行为是如何由系统成分协作实现的。在一定的语境中一组对象以及实现某些行为的对象间的相互作用。协作图就是表现对象协作关系的图。强调组织机构和交互角色。以生命线之间的链接为核心来描述对象之间的消息交互。
|
||||
|
||||
**作用**
|
||||
|
||||
显示对象及其交互关系的空间组织结构
|
||||
|
||||
表现一个类操作的实现
|
||||
|
||||
**组成**
|
||||
|
||||
协作图基本元素:活动者、对象、链接、消息。
|
||||
|
||||
> 对象:用来表示操作图中参与交互的对象。
|
||||
|
||||
> 多对象:用来表示协作图中参与交互的多个对象。
|
||||
|
||||
> 链接:两个或多个对象之间的独立连接,是对象引用元组,是关联的实例。链的表示形式:一个或多个相连的线或弧。
|
||||
|
||||
> 消息:对象之间发送的消息。
|
||||
|
||||
**示例**
|
||||
|
||||

|
||||
|
||||
**通信图的建立**
|
||||
|
||||
> 1\. 确定交互过程的上下文(context);
|
||||
|
||||
> 2\. 识别参与交互过程的对象;
|
||||
|
||||
> 3\. 如果需要,为每个对象设置初始特性;
|
||||
|
||||
> 4\. 确定对象之间的链(link),以及沿着链的消息;
|
||||
|
||||
> 5\. 从引发这个交互过程的初始消息开始,将随后的每个消息附到相应的链上;
|
||||
|
||||
> 6\. 如果需要表示消息的嵌套,则用Dewey十进制表示法;
|
||||
|
||||
> 7\. 如果需要说明时间约束,则在消息旁边加上约束说明;
|
||||
|
||||
> 8\. 如果需要,可以为每个消息附上前置条件和后置条件。
|
||||
|
||||
**协作图建模风格**
|
||||
|
||||
> •把注意力集中于关键的交互。
|
||||
|
||||
> •对于参数,优先考虑使用参数名而不是参数类型。
|
||||
|
||||
> •不要对明显的返回值建模。
|
||||
|
||||
> •可以把返回值建模为方法调用的一部分。
|
||||
|
||||
> •为每个消息画出箭头。
|
||||
|
||||
> •注明导航性(Navigability)时要慎重。
|
||||
|
||||
**顺序图协作图对比**
|
||||
|
||||
> •顺序图强调消息的时间顺序,协作图强调参加交互的对象的组织,两者可以相互转换。
|
||||
|
||||
> •顺序图不同于协作图的两个特征:
|
||||
|
||||
> –顺序图有对象生命线
|
||||
|
||||
> –顺序图有控制焦点
|
||||
|
||||
> •协作图不同于顺序图的两个特征:
|
||||
|
||||
> –协作图有路径
|
||||
|
||||
> –协作图必须有消息顺序号
|
||||
|
||||
> •顺序图可以表示某些协作图无法表示的信息;同样,协作图也可以表示某些顺序图无法表示的信息。
|
||||
|
||||
■顺序图是按照时间顺序从上到下排列消息来描述系统中生命线之间的消息交互情况。
|
||||
|
||||
通信图是着眼于生命线之间的链接来描述生命线之间的消息交互情况。
|
||||
|
||||
■ 顺序图中的消息可以省略消息番号。
|
||||
|
||||
通信图中的消息必须明确消息番号来表示消息发送的先后顺序。
|
||||
|
||||
■ 顺序图中,用组合片段“par”来描述消息的并行处理。
|
||||
|
||||
通信图中,用“数字+字母”的消息番号定义方式来描述消息的并行处理。
|
||||
|
||||
协作图的详细描述
|
||||
|
||||
**消息分类**
|
||||
|
||||
- 同步消息
|
||||
|
||||

|
||||
|
||||
- 异步消息
|
||||
|
||||

|
||||
|
||||
- 返回消息
|
||||
|
||||

|
||||
|
||||
**消息编号**
|
||||
|
||||
通过消息编号指明消息的先后顺序
|
||||
|
||||
**消息标签的格式**
|
||||
|
||||

|
||||
|
||||
**与类图的一致性**
|
||||
|
||||
类图表示的是系统的静态结构,交互图表示的是系统的动态行为。两者之间要保持一致性。
|
||||
|
||||
- 交互图中的生命线对应于类图中适当的类。
|
||||
|
||||
- 交互图中有消息交互的两个生命线,在类图中对应的两个类之间应该有一定的关系。
|
||||
|
||||
- 交互图中的消息,在类图中接受该消息的生命线所对应的类中应该有某个操作与之相对应。
|
||||
|
||||
**协作图的表示**
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
协作图的控制结构
|
||||
|
||||
**并行处理**
|
||||
|
||||
相同数字的消息番号后面跟上不同字母来识别并行消息
|
||||
|
||||

|
||||
|
||||
**循环表示:(以后补充)**
|
||||
|
||||
**分支表示:(以后补充)**
|
||||
|
||||
序列图和协作图对比
|
||||
|
||||
协作图和序列图表达的信息一样,只是方法不同,可通过适当的方式进行转化。协作图和序列图的不同点:
|
||||
|
||||
- 协作图明确表示了角色关系,通过协作角色来限定协作中的对象或链。
|
||||
|
||||
- 协作图不将时间作为单独的维来表示,必须使用顺序号来判断消息的顺序以及并行线程。
|
||||
|
||||
- 序列图和协作图都表示对象间的交互作用,序列图侧重时间顺序,协作图侧重对象间的关系,时间顺序可以从对象流经的顺序编号中获得。
|
||||
|
||||
- 序列图被用于表示方案,而协作图被用于过程的详细设计。
|
||||
167
UML建模/11 UML笔记之活动图.md
Normal file
@@ -0,0 +1,167 @@
|
||||
UML活动图
|
||||
|
||||
**概念**
|
||||
|
||||
> 活动图是另一个种动态视图,描述动作和动作导致对象状态改变的结果,而不用考虑引发状态改变的事件。描述了系统从一种活动转换到另一种活动的过程。
|
||||
|
||||
**活动图的作用:**
|
||||
|
||||
> 用来描述系统或者某个业务的处理流程,业务相关的工作流描述、用例的事件流描述、程序的算法描述。描述业务或软件系统的活动轨迹。说明了了一系列活动控制流。
|
||||
|
||||
**活动图的图组成元素:**
|
||||
|
||||
1、起点
|
||||
|
||||
【作用】描述活动图的开始状态
|
||||
|
||||
【表示方式】黑的实心圆
|
||||
|
||||

|
||||
|
||||
2、终止点
|
||||
|
||||
【作用】描述活动图的终止状态
|
||||
|
||||
【表示方式】实心圆的空心圆
|
||||
|
||||

|
||||
|
||||
3、活动
|
||||
|
||||
【作用】可以是手动也可以自动的执行任务。构成业务和处理的一个单位,用圆角长方形表示。
|
||||
|
||||
【表示方式】圆角矩形
|
||||
|
||||

|
||||
|
||||
4、状态
|
||||
|
||||
【作用】活动的所处状态
|
||||
|
||||
【表示方式】椭圆矩形
|
||||
|
||||

|
||||
|
||||
5、转换,控制流
|
||||
|
||||
【作用】描述一个活动转向另一个活动
|
||||
|
||||
【表示方式】带箭头的实线段,指向转向的活动
|
||||
|
||||

|
||||
|
||||
6\. 判决节点和监护条件
|
||||
|
||||
【作用】一个输入转换,多个输出转换,每个输出转换上都有一个监护条件,用来表示满足条件时才进行转换。
|
||||
|
||||
【表示方式】菱形表示
|
||||
|
||||

|
||||
|
||||
7\. 分叉和汇合(fork并发节点和join并发节点)
|
||||
|
||||

|
||||
|
||||
8\. 泳道(参与者)
|
||||
|
||||
由组织内的某个人执行活动图。每个泳道代表一个责任区
|
||||
|
||||
**状态图中“动作”和活动图中的“动作状态”区别:**
|
||||
|
||||
> 相同点:都是原子性的,动作要么不执行,要么就完全执行,不能中断。执行时间都极短
|
||||
|
||||
> 不同点:动作状态和状态图中的状态不同,不能有入口动作和出口动作,也不能有内部转移
|
||||
|
||||
**活动图建模**
|
||||
|
||||
> 确保从判决节点出来的每个转移都有一个监护条件。
|
||||
|
||||
> 确保决策点上的监护条件形成一个完备集。
|
||||
|
||||
> 监护条件不重叠,互斥。
|
||||
|
||||
> 确保每个分叉只有一个进入转移
|
||||
|
||||
> 确保每个汇合只有一个退出转移
|
||||
|
||||
> 小于5条泳道。
|
||||
|
||||
活动图的详细描述
|
||||
|
||||

|
||||
|
||||
**泳道**
|
||||
|
||||
由组织内的某个人执行活动图。每个泳道代表一个责任区
|
||||
|
||||
**分支合并**
|
||||
|
||||

|
||||
|
||||
**分叉汇合(并发)**
|
||||
|
||||

|
||||
|
||||
**对象节点使用**
|
||||
|
||||

|
||||
|
||||
**发送接收信号活动**
|
||||
|
||||
> 发送信号活动和事件受理活动
|
||||
|
||||
> 发送信号活动:表示的是让外部发生某种事件的活动。
|
||||
|
||||
> 事件受理活动:表示的是对于外部发生的事件进行接收的活动。
|
||||
|
||||

|
||||
|
||||
**活动图与状态图比较**
|
||||
|
||||
活动图描述的是从activity到activity的控制流,而状态图描述的是对象的状态及状态之间的转移。
|
||||
|
||||
–对于以下几种情况可以使用活动图:
|
||||
|
||||
> 分析用例
|
||||
|
||||
> 理解涉及多个用例的工作流
|
||||
|
||||
> 处理多线程应用
|
||||
|
||||
–对于下面的情况要使用状态图:
|
||||
|
||||
显示一个对象在其生命周期内的行为。
|
||||
|
||||
活动图的示例:
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
活动图处理具体复杂的不同事物:
|
||||
|
||||
**标识永道的活动图**
|
||||
|
||||
**标识对象流的活动图**
|
||||
|
||||
**标识参数的活动图**
|
||||
|
||||
**标识别针的或从图**
|
||||
|
||||
**标识中断的活动图**
|
||||
|
||||
**标识异常的活动图**
|
||||
|
||||
**标识扩展区的活动图**
|
||||
|
||||
**标识信号的活动图**
|
||||
|
||||
**标识嵌套的活动图**
|
||||
|
||||
活动图的建模方式:
|
||||
|
||||
**对工作流程进行建模**
|
||||
|
||||
**对操作流程进行建模**
|
||||
224
UML建模/12 UML笔记之状态图.md
Normal file
@@ -0,0 +1,224 @@
|
||||
UML状态图
|
||||
|
||||
**定义**
|
||||
|
||||
> 对象在生命周期内、在外部时间的作用下,对象从一中状态迁移到另一种状态构成的完整系列图,就是一个状态机。
|
||||
|
||||
记录下给定时刻状态的机器,根据不同的输入对每个给定的变化而改变其状态或引发一个动作。
|
||||
|
||||
> 在UML中,状态机由对象的各个状态和连接这些状态的转换组成,是展示状态与状态转换的图。
|
||||
|
||||
> 状态图本质上就是一个状态机或是状态机的特殊情况。由表示状态的节点和表示状态之间转换的带箭头的直线组成。
|
||||
|
||||
**状态机图的作用:**
|
||||
|
||||
> 状态机图用来描述一个对象从生成到消失整个生命周期内所经历的状态变化。。状态机图用来反映型对象的行为建模(时间响应)
|
||||
|
||||
- 表示一个对象对于来自外部的事件如何做出反应的情况。
|
||||
|
||||
- 当生命周期内有复杂状态变化的对象,或者需要把握其状态迁移变化的对象才需要画状态机图。
|
||||
|
||||
- 包括状态序列、引发事件、一系列响应动作
|
||||
|
||||
**状态机的组成元素:**
|
||||
|
||||
状态(初始状态结束状态一般状态)、转移、事件、动作。
|
||||
|
||||
**认识状态的概念和分类:**
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
**状态图示例**
|
||||
|
||||

|
||||
|
||||
状态图的表示
|
||||
|
||||
**状态的表示方法:**
|
||||
|
||||
初始状态:对象的起始状态
|
||||
|
||||
终止状态:对象最后的状态。
|
||||
|
||||

|
||||
|
||||
中间状态:使用对象的属性来描述对象的状态。
|
||||
|
||||
分类:简单状态、组合状态、历史状态。
|
||||
|
||||
描述:状态名称、进入退出动作、内部事务、子状态、活动。
|
||||
|
||||

|
||||
|
||||
**动作表示方法:**
|
||||
|
||||
entry/action:进入状态时执行的动作
|
||||
|
||||
exit/action:退出状态时执行的动作
|
||||
|
||||
do/activity:处于改状态时执行的动作
|
||||
|
||||
event/action(argument):对象内部迁移,状态相应某个事件锁执行的活动。
|
||||
|
||||
**迁移的表示方法:**
|
||||
|
||||
使用带箭头实线表示,包括三个要素,事件。监护条件,动作。下面是对水池的操作
|
||||
|
||||

|
||||
|
||||
其中事件是turnON的动作,haswater是监护条件,监护条件成立,则执行后边的flowWater动作
|
||||
,最终转换为ON状态。
|
||||
|
||||
- 触发事件,触发对象状态改变的原因、分为四类:调用事件,调用者给接受者发送的时间。信号事件,异步传递信息包。改变时间,改变事件是指对系统的某个条件表达式不断
|
||||
进行的循环测试。时间事件,当时间达到某个特定的时刻。
|
||||
|
||||
- 监护条件是一个布尔型表达式。
|
||||
|
||||
- 动作是原子性的,在执行过程中不能被中断。
|
||||
|
||||
**分支的表示方法:**
|
||||
|
||||
对象在外部时间的作用下,根据监护条件的不同值,转向不同的目标状态,对象的状态根据监护条件的取值二发生分支。根据监护条件的真假触发不同的分支。
|
||||
|
||||
**完整的状态机图:**
|
||||
|
||||

|
||||
|
||||
状态图的迁移分类
|
||||
|
||||
**外部迁移:**使用带箭头实线表示,包括三个要素,事件。监护条件,动作。下面是对水池的操作
|
||||
|
||||

|
||||
|
||||
> 其中事件是turnON的动作,haswater是监护条件,监护条件成立,则执行后边的flowWater动作
|
||||
> ,最终转换为ON状态。
|
||||
|
||||
> 能够触发对象状态改变的对象分为四类:调用事件,调用者给接受者发送的时间。信号事件,异步传递信息包。改变时间,改变事件是指对系统的某个条件表达式不断进行的循环测试。时间事件,当时间达到某个特定的时刻。
|
||||
|
||||
> 监护是一个布尔型表达式。
|
||||
|
||||
> 动作是原子性的,在执行过程中不能被中断。
|
||||
|
||||
> 活动是对象处于某个状态时执行的一系列动作
|
||||
|
||||
**自身迁移:**状态可以有返回自身状态的转移,称之为自身转移(Self-Transitions)
|
||||
|
||||

|
||||
|
||||
**自动迁移:**没有时间出发时,监护条件为真时执行的动作。
|
||||
|
||||
**复合迁移:**由多个外部迁移组成。符合迁移有判决节点和多个简单迁移组合而成。
|
||||
|
||||

|
||||
|
||||
**同期迁移(为了实现并发状态)**
|
||||
|
||||

|
||||
|
||||
状态图的状态分类
|
||||
|
||||
**简单状态**
|
||||
|
||||
> 状态机描述了门对象的生存期间的状态序列,引起转移的事件,以及因状态转移而伴随的动作(Action).
|
||||
|
||||

|
||||
|
||||
> 状态有Opened、Closed、Locked。
|
||||
|
||||
> 事件有 Open、Close、Lock和Unlock。
|
||||
|
||||
**组合状态**
|
||||
|
||||
> 嵌套在另外一个状态中的状态称之为子状态(sub-state),一个含有子状态的状态被称作组合状态(Compound
|
||||
> States). 如下图,【Check PIN】是组合状态,【Enter PIN】是子状态。
|
||||
|
||||

|
||||
|
||||
> 也可用以下方式进行描述
|
||||
|
||||

|
||||
|
||||
> 如上图,状态机【Check PIN】的细节被分割到另外一个图中了。
|
||||
|
||||
> 示例:
|
||||
|
||||

|
||||
|
||||
**历史状态**
|
||||
|
||||
> 历史状态是一个伪状态(Pseudostate),其目的是记住从组合状态中退出时所处的子状态,当再次进入组合状态,可直接进入这个子状态,而不是再次从组合状态的初态开始。
|
||||
|
||||
> 历史状态符为H符号外加一圆圈来表示。
|
||||
|
||||

|
||||
|
||||
> 在上图的状态图中,正常的状态顺序是:【Washing】-
|
||||
> \>【Rinsing】-\>【Spinning】。
|
||||
|
||||
> 如果是从状态【Rinsing】突然停电(Power
|
||||
> Cut)退出,,洗衣机停止工作进入状态【Power
|
||||
> Off】,当电力恢复时直接进入状态【Running】。
|
||||
|
||||

|
||||
|
||||
**并发状态**
|
||||
|
||||
> 在一个组合状态中,同时有多个子状态存在的时候,该组合状态称为并发状态。
|
||||
|
||||

|
||||
|
||||
绘制状态机图
|
||||
|
||||
**建模风格**
|
||||
|
||||
- 把初态放置在左上角;把终态放置在右下角。
|
||||
|
||||
- 用过去式命名转移事件。
|
||||
|
||||
- 警戒条件不要重叠。
|
||||
|
||||
- 不要把警戒条件置于初始转移上。
|
||||
|
||||
**问题**
|
||||
|
||||
考虑一个培训课程。
|
||||
|
||||
该培训课程由讲义和练习两部分组成,最初由讲义开始。
|
||||
|
||||
在讲义或者练习的过程中会插入休息。如果是在讲义过程中插入休息,那么休息完毕后再继续讲义。如果在练习过程中插入休息,那么休息之后再继续练习。
|
||||
|
||||
**解答**
|
||||
|
||||

|
||||
|
||||
状态机图和交互图的一致性
|
||||
|
||||

|
||||
|
||||
活动图和状态图的各自作用:
|
||||
|
||||
**状态图的作用:**
|
||||
|
||||
1、清晰描述状态之间的转换顺序,通过转换顺序可以清晰看出事件的执行顺序
|
||||
|
||||
2、清晰的事件顺序有利于程序员在开发程序时避免出现事件错序的情况
|
||||
|
||||
3、清晰地描述了状态转换时所必须触发德尔事件、监护条件和动作等影响转换的因素,有利于程序员汇总非法事件的进入
|
||||
|
||||
4、通过判断更好地描述工作流因为不同的条件发生的分支
|
||||
|
||||
**活动图的作用:**
|
||||
|
||||

|
||||
|
||||
**活动图和状态图的区别:**
|
||||
|
||||
1、目的不同
|
||||
|
||||
活动图的主要目的是描述动作及对象的改变结果,而状态图则是描述对象、子系统、系统在生命周期中的各种行为
|
||||
|
||||
2、活动图中的状态转换不需要任何触发事件,状态图则需要触发事件
|
||||
|
||||
3、活动图种的动作可以放在泳道中,状态图不可以
|
||||
138
UML建模/13 UML笔记之构件图和部署图.md
Normal file
@@ -0,0 +1,138 @@
|
||||
UML构件图与部署图
|
||||
|
||||
**定义**
|
||||
|
||||
为了描述系统实现方面的信息,使系统具有可重用性和可操作性的目的,构件图和部署图来表示实现单元。用来描述系统的文件构成,软件运行环境和硬件构成的两种图形—构件图和部署图。主要用来描述系统中能用眼睛看到的那一部分。
|
||||
|
||||
构件图
|
||||
|
||||
**构件图定义**
|
||||
|
||||
构件图是用来表示系统中构件与构件之间、构建内部结构的关系图
|
||||
|
||||
构件之间的依赖关系:与类图中类间依赖关系相同,都是使用虚线箭头表示
|
||||
|
||||
构件和接口之间的依赖关系:
|
||||
一个构件使用了其他元素的接口,依赖关系可以用箭头的虚线表示,箭头指向接口符号
|
||||
|
||||
**构件图要素**
|
||||
|
||||
构件、接口
|
||||
|
||||
**构件图示例**
|
||||
|
||||

|
||||
|
||||
**构件定义**
|
||||
|
||||
将系统中可重用的模块封装为具有可替代性的物理单元,称为构件。构件表示的是系统内预先定义好访问接口的可以再利用的软件部件。
|
||||
|
||||
构件的特征:
|
||||
|
||||
1、代码特征:包含和封装了实现系统功能的类、其他元素的实现代码以及某些构成系统状态的实例对象
|
||||
|
||||
2、身份特征:构件拥有身份和状态,用于定位在其上的物理对象
|
||||
|
||||
构件的表示:
|
||||
|
||||

|
||||
|
||||
**接口定义**
|
||||
|
||||
构件之间通过接口连接起来。接口定义了操作调用的方法,并且不包含操作的具体实现。
|
||||
|
||||
- 提供接口:构件提供给外部的接口
|
||||
|
||||

|
||||
|
||||
- 要求接口:构件访问外部需要的几口
|
||||
|
||||

|
||||
|
||||
接口表示示例:
|
||||
|
||||

|
||||
|
||||
**构件之间的关系**
|
||||
|
||||

|
||||
|
||||
**构件的内部结构**
|
||||
|
||||
- 部分(part) - 构成构件的组成部分。
|
||||
|
||||
- 端口(port)- 构件内部和外部的边界。一个端口可连接若干个接口。
|
||||
|
||||
- 连接(connect) -
|
||||
连接构件的组成部分;同类之间的关联一样,可以指定连接端名和多重度。
|
||||
|
||||
内部结构示例
|
||||
|
||||

|
||||
|
||||
部署图
|
||||
|
||||
**定义:**
|
||||
|
||||
> 部署图用来描述运行时,部署着系统的物理文件的硬件设备(计算机,打印机)之间的相互关系(通信联接)。
|
||||
|
||||

|
||||
|
||||
**组成要素**
|
||||
|
||||
- 节点
|
||||
|
||||
- 节点间的关联
|
||||
|
||||
**节点**
|
||||
|
||||
硬件设备+运行环境
|
||||
|
||||
立方体表示
|
||||
|
||||
分为节点类型:节点实例。
|
||||
|
||||
节点示例:
|
||||
|
||||

|
||||
|
||||
**节点间的关系**
|
||||
|
||||
> 部署图中节点和节点之间的关系表示的是节点间的通信连接
|
||||
|
||||
- 节点之间的关系可以用构造型来表示。
|
||||
|
||||
- 节点间的关联可指定多重度。
|
||||
|
||||
节点间关系的示例:
|
||||
|
||||

|
||||
|
||||
**成果物**
|
||||
|
||||
> 在部署图的节点中还可以指定配置在该节点中的成果物。
|
||||
> 成果物为系统所使用的物理文件。成果物可以是源代码文件,执行文件,构件的实现文件,数据库文件,文书等物理文件实体。
|
||||
|
||||
> 成果物表示
|
||||
|
||||

|
||||
|
||||
**成果物和节点之间的依赖关系**
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
**部署图的作用**
|
||||
|
||||
1、描述一个具体应用的主要部署结构。硬件、内部运行环境、部署的软件。
|
||||
|
||||
2、平衡系统运行时的计算资源分布
|
||||
|
||||
超市信息管理系统的部署图:
|
||||
|
||||

|
||||
|
||||
**部署图的示例**
|
||||
|
||||

|
||||
217
UML建模/14 UML笔记之用例图.md
Normal file
@@ -0,0 +1,217 @@
|
||||
用例图基本概述
|
||||
|
||||
**概念**
|
||||
|
||||
用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约。**站在用户角度**描述**用户的需求**。
|
||||
|
||||
用例图是由参与者、用例以及它们之间的关系构成的用于**描述系统功能**的**动态视图**。
|
||||
|
||||
> 用例图的作用是描述参与者和用例的关系,表示系统的用户使用了系统中的哪些用例。
|
||||
|
||||
**组成**
|
||||
|
||||
用例图组成的概念
|
||||
|
||||

|
||||
|
||||
- 参与者:可以是系统使用者、外部硬件、现有系统。既可以与对象进行信息交换、也可以被动接受来自于对象系统的信息。
|
||||
|
||||
- 用例:系统提供的功能。一个用例会涉及到多个参与者和系统本身。消息序列+错误条件。
|
||||
|
||||
**用例图实例**
|
||||
|
||||

|
||||
|
||||
用例图详细描述
|
||||
|
||||
**用例模型准则**
|
||||
|
||||
1. 首先确保系统边界
|
||||
|
||||
2. 确保关注参与者。
|
||||
|
||||
3. 每个用例必须给用户提供价值。
|
||||
|
||||
4. 用例是非形式化的。
|
||||
|
||||
**用例特点**
|
||||
|
||||
- 用例描述了用户提出的需求
|
||||
|
||||
- 用例可大可小
|
||||
|
||||
- 用例对应一个具体的用户目标
|
||||
|
||||
**用例图目的**
|
||||
|
||||
- 明确开发系统的主要功能
|
||||
|
||||
- 明确开发对象的范围
|
||||
|
||||
- 明确开发对象和外界的关系
|
||||
|
||||
**用例描述**
|
||||
|
||||
- 是对用例图的补充,用例描述和用例图合称为用例模型。
|
||||
|
||||
- 用来详细描述用例内部的业务流程。
|
||||
|
||||
- 包括概要、脚本(一段藐视具体流程的文字)、事件流(各种条件下的执行流程:前提条件、时候条件、基本条件、代替流、错误流)。
|
||||
|
||||
**用例模板**
|
||||
|
||||
> •用例名称:处理订单
|
||||
|
||||
> •标识符:UC1701
|
||||
|
||||
> •用例描述:当一个订单初始化或者被查询的时候这个用例开始。它处理有关订单的初始化定义和授权等问题。当订单业务员完成了同一个顾客的对话的时候,
|
||||
> 它就结束了。
|
||||
|
||||
> •参与者:订单业务员
|
||||
|
||||
> •优先级:1
|
||||
|
||||
> •状态:通过审查
|
||||
|
||||
> •前置条件:订单业务员登录进系统
|
||||
|
||||
> •后置条件:下订单;库存数目减少
|
||||
|
||||
> •基本操作流程:
|
||||
|
||||
> –1. 顾客来订购一个吉他,并且提供信用卡作为支付手段。……
|
||||
|
||||
> –2. …..
|
||||
|
||||
> •可选操作流程:
|
||||
|
||||
> –顾客来订购一个吉他,并且使用汇票的方式。……
|
||||
|
||||
> –顾客来订购一个风琴,并且提供信用卡作为支付手段。……
|
||||
|
||||
> –顾客使用信用卡下订单,但那张信用卡是无效的。
|
||||
|
||||
> –顾客来下订单,但他想要的商品没有存货。
|
||||
|
||||
> •被泛化的用例:无
|
||||
|
||||
> •被包含的用例:登录 (UC1706)。
|
||||
|
||||
> •被扩展的用例:无
|
||||
|
||||
> •修改历史记录:
|
||||
|
||||
> –张三,定义基本操作流程,2003年5月4日
|
||||
|
||||
> –张三,定义可选操作流程,2003年5月8日
|
||||
|
||||
**用例描述中常见错误**
|
||||
|
||||
- 只描述系统的行为,没有描述actor的行为。
|
||||
|
||||
- 只描述actor的行为,没有描述系统的行为。
|
||||
|
||||
- 设定对用户界面的设计的要求。
|
||||
|
||||
- 过于冗长。
|
||||
|
||||
错误例子:
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
错误说明:
|
||||
|
||||
分别对应常见错误的1234.
|
||||
|
||||
改进:
|
||||
|
||||

|
||||
|
||||
**用例图建立步骤**
|
||||
|
||||
> (1) 找出系统外部的参与者和外部系统,确定系统的边界和范围;
|
||||
|
||||
> (2) 确定每一个参与者所期望的系统行为;
|
||||
|
||||
> (3) 把这些系统行为命名为Use Case;
|
||||
|
||||
> (4) 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分;
|
||||
|
||||
> (5) 编制每一个Use Case的脚本;
|
||||
|
||||
> (6) 绘制Use Case图;
|
||||
|
||||
> (7) 区分主事件流和异常情况的事件流,可以把表示异常情况的事件流作为单独的Use
|
||||
> Case处理;
|
||||
|
||||
> (8) 细化Use Case图,解决Use Case间的重复与冲突问题。
|
||||
|
||||
**实例分析!!!**
|
||||
|
||||
用例图中的关联
|
||||
|
||||
**参与者-用例关联关系**
|
||||
|
||||
表示参与者和用例之间的通信。关联可以是多重度的。
|
||||
|
||||

|
||||
|
||||
**参与者-参与者泛化关系**
|
||||
|
||||
某一个参与者相关联的所有用例,都和另外一个参与者相关联
|
||||
|
||||

|
||||
|
||||
**包含**
|
||||
|
||||
> 【表示方式】虚线箭头 + include;箭头由基础用例指向被包含用例
|
||||
|
||||
> 【作用】提高用例模型的可维护性;简化描述避免多个用例中重复描述同一段行为或对同一段行为描述不一致
|
||||
|
||||
> 【包含图】
|
||||
|
||||

|
||||
|
||||
**扩展**
|
||||
|
||||
> 【表示方式】虚线箭头 + extend;箭头指向基础用例
|
||||
|
||||
> 【作用】一定条件下,扩展用例为基础用例增加新的行为
|
||||
|
||||
> 【扩展图】
|
||||
|
||||

|
||||
|
||||
**泛化**
|
||||
|
||||
> 【表示方式】实线空三角箭头;箭头指向父用例
|
||||
|
||||
> 【作用】子用例继承父用例所有的结构、行为和关系,是父用例的一种特殊形式
|
||||
|
||||
> 【泛化图】
|
||||
|
||||

|
||||
|
||||
扩展关系和包含关系的比较:
|
||||
|
||||
1、扩展关系:基础用例提供一个或多个插入点,扩展用例为插入点提供需要插入的行为
|
||||
|
||||
包含关系中只有一个插入点
|
||||
|
||||
2、扩展关系:基础用例执行,扩展不一定执行
|
||||
|
||||
包含关系:基础用例执行,包含用例必须执行
|
||||
|
||||
3、扩展关系:即使没有扩展用例,基础用例本身是完整的
|
||||
|
||||
包含关系:没有包含用例,基础用例本身不完整
|
||||
|
||||
用例图的表示
|
||||
|
||||

|
||||
269
UML建模/2 UML笔记之语言体系.md
Normal file
@@ -0,0 +1,269 @@
|
||||
UML语言的组成:
|
||||
|
||||
包括构造块、规则、公共机制
|
||||
|
||||
**构造快:**
|
||||
|
||||
事物:事物代表了系统中最简单的实体。
|
||||
|
||||
关系:关系代表了实体间的联系。
|
||||
|
||||
图:代表了实体间按某种规则链接在一起组成的更大的实体。
|
||||
|
||||
**规则:**构造块应该遵守的规则,名称、作用范围、可见性、完整性、可执行等属性,在软件系统或业务系统中事物应该遵守的约束或规定。
|
||||
|
||||
名称:值每个构造块代表的事务应该有一个名字。
|
||||
|
||||
范围:每个构造快代表的事物的使用范围。
|
||||
|
||||
可见性:方位构造快代表的事物是,授予访问者的权限或者级别。
|
||||
|
||||
完整性:构造块代码的事物应该有完整的含义。
|
||||
|
||||
可执行性:构造块代表的事物具有实际含义和合理性。
|
||||
|
||||
**公共机制:**每个事物都必须遵守的通用规则。细分为:项数、修饰、通用划分、扩展机制。
|
||||
|
||||
构造块——事物(也成为符号)的解释
|
||||
|
||||
> 结构符号代表了业务系统或软件系统中的某个简单事物。结构符号代表的简单事物有7种,分别是类(对象)、接口、主动类、用例、协作、构件和节点。结构符号常用名词命名。下面分别介绍7种结构符号的表示法和含义。
|
||||
|
||||
**结构符号**
|
||||
|
||||
结构符号代表了业务系统或软件系统中的某个简单事物。结构符号代表的简单事物有7种,分别是类(对象)、接口、主动类、用例、协作、构件和节点。结构符号常用名词命名。下面分别介绍7种结构符号的表示法和含义。
|
||||
|
||||
1.类和对象
|
||||
|
||||
类是对具有相同属性、相同操作以及相同关系的一组对象的共同特征的抽象,类是对一组对象共同特征的描述,即,类是对象的模板,而对象是类的一个实例。
|
||||
|
||||
(1)类的表示
|
||||
|
||||
> 在UML中,类表示为一个长方形,垂直地把长方形分为三个区,如图5
|
||||
> 所示。顶部区域显示类的名字。中间的区域列出类的属性。底部的区域列出类的操作。在表示一个类时,类名不能省略,属性和操作可以省略。
|
||||
|
||||
图5是Flight类(航线)的图形表示。正如我们所能见到的,类名是 Flight;
|
||||
|
||||
我们可以在中间区域看到Flight类的3个属性:flightNumber,departureTime 和
|
||||
flightDuration。
|
||||
|
||||
在底部区域中我们可以看到Flight类有两个操作:delayFlight 和 getArrivalTime。
|
||||
|
||||

|
||||
|
||||
图 1: Flight类的类图
|
||||
|
||||
图5 表示Flight类的UML符号
|
||||
|
||||
(2)对象的表示
|
||||
|
||||
> 对象也是用一个矩形表示的,但在矩形框中不再写出属性名和方法名,只是用“对象名:类名”的格式表示一个对象,并且,对象名和类名下面必须带下划线。例如,属于类People中的对象“李世民”的表示方法如图6所示。
|
||||
|
||||
图6表示对象“李世民”的UML符号
|
||||
|
||||
| 李世民:People |
|
||||
|----------------|
|
||||
|
||||
2.接口
|
||||
|
||||
因为外界是通过类或对象(或构件)的方法类访问对象或类的(或构件),因此把类或构件的方法集合称为接口。接口向外界声明了类(或构件)能提供的服务。
|
||||
|
||||
接口分为供给接口和需求接口两种,供给接口只能向其他类(或构件)提供服务,需求接口表示类(或构件)需要用到其他类(或构件)提供的服务。
|
||||
|
||||
上述两种接口的表示方法如图7所示。
|
||||
|
||||

|
||||
|
||||
图7 表示接口的UML符号
|
||||
|
||||
3.主动类
|
||||
|
||||
> 一个对象可以是主动的也可以是被动的。主动对象是可以改变自身状态的对象。例如,定时器和时钟就可以在没有外部事件触发的情况下,能自已改变它们自身状态。通常使用进程或者线程来实现创建主动对象。被动对象只有在接受到消息后才会改变自身的状态。例如,银行账户的属性不会发生变化,除非银行账户(对象)接收到一条设置余额(一种用于更新账户余额的操作)的消息。因为大多数对象都是被动对象,所以,我们假设所有对象都是被动对象。
|
||||
|
||||
主动类是指创建主动对象的类。主动类的表示与一般类相似,只是最外框是粗线描述而已,如主动类Radio的表示方法如图8所示。
|
||||
|
||||

|
||||
|
||||
图8 表示主动类Radio的符号
|
||||
|
||||
4.用例
|
||||
|
||||
> 在系统中,为完成某个任务而执行的一系列动作的集合称为用例实例。用例是对一组用例实例共同行为的描述,这组用例实例具有相似的特征。因此,用例是对一组用例实例共同特征的描述;用例实例是用例的一次具体执行过程,用例是对一组用例实例的描述。用例与用例实例的关系正如类与对象的关系。
|
||||
|
||||
> 在UML中,用例是用一个实线椭圆来表示的,在椭圆中写入用例名称,如用例“取款”的表示方法如图9所示。
|
||||
|
||||

|
||||
|
||||
图9 用例“取款”的表示方法
|
||||
|
||||
5.协作
|
||||
|
||||
协作是指有意义的交互,即一组对象为了完成某个任务,而在相互间进行的交互。
|
||||
|
||||
用例的实现是指实现某个用例的一组对象之间的交互,即把一个用例表示为多个对象间的交互(协作)。从本质上说,协作就是用例的实现。
|
||||
|
||||
协作用一个带两个分栏的虚线椭圆表示的,例如,用例“销售”,用协作“销售”表示时,其对应的表示方法如图10所示。
|
||||
|
||||

|
||||
|
||||
图10 协作“销售”
|
||||
|
||||
协作图“销售”表示的语义如下:
|
||||
|
||||
(1)生产商生产出产品并以低价售给批发商和零售商,从中获得了利润。
|
||||
|
||||
(2)批发商以比生产商较高的价格出售给销售商或零售商,零售商在自己的商店得到
|
||||
更高利润。
|
||||
|
||||
(3)顾客以较高的价格买到自己想要的商品。
|
||||
|
||||
6.构件
|
||||
|
||||
构件也称组件,它是指系统设计中的一个相对独立的软件部件,它把功能实现部分隐藏在内部,对外声明了一组接口(包括供给接口和需求接口)。因此,两个具有相同接口的构件可以相互替换。
|
||||
|
||||
构件是比“对象”更大的软件部件,例如一个COM组件、一个DLL文件、一个JavaBeans以及一个执行文件都可以是构件。为了更好地在UML模型中对它们进行表示,于是引入了构件(也译为组件)。
|
||||
|
||||
构件通常采用带有两个小方框的矩型表示,构件的名字写在方框中,如图11所示。
|
||||
|
||||

|
||||
|
||||
图11 表示构件的UML符号
|
||||
|
||||
7.节点
|
||||
|
||||
节点是指硬件系统中的物理部件,它通常具有存储空间或处理能力,如PC机、打印机、服务器、显示器等都是节点。在UML中,用一个立方体表示一个节点,例如,节点“显示器”的表示方法如图12所示。
|
||||
|
||||

|
||||
|
||||
图12 节点“显示器”的UML符号
|
||||
|
||||
**行为符号**
|
||||
|
||||
> 行为符号是用来表示业务系统或软件系统中事物之间的交互以及交互引起的事物本身的状态变化。行为符号描述了事物的动态特征。描述事物的行为特征在两个方面:事物之间的交互和事物本身的状态变化,描述这2个方面的符号也有2种:一种符号代表事物间的交互;一种符号代表事物本身的状态。
|
||||
|
||||
1.交互
|
||||
|
||||
交互(interaction)是指为了完成某个任务的对象之间的相互作用,这种作用通过信息的发送和接收来完成。
|
||||
|
||||
交互的表示方法很简单,只需使用一条有向直线来表示对象间的交互,并在有向直线上方标注消息名称即可,如图13所示。
|
||||
|
||||

|
||||
|
||||
图13 表示交互的UML符号
|
||||
|
||||
2.状态
|
||||
|
||||
在对象生命周期内,在事件驱动下,对象从一种状态迁移到另一状态,这些状态序列就构成了状态机,即一个状态机由多个状态组成。
|
||||
|
||||
在UML中,将状态表示为一个圆角矩形,并在矩形中写上状态名称。例如,手机处在“正在通话”状态的表示方法如图14所示。
|
||||
|
||||

|
||||
|
||||
图14 表示“正在通话”状态的UML符号
|
||||
|
||||
**分组符号**
|
||||
|
||||
对于一个中大型的软件系统而言,通常会包含大量的类、接口以及协作,因此也就会存在大量的简单事物和行为特征,为了能有效地对这些事物进行分类和管理,就需要对其进行分组。在UML中可通过“包(Package)”来实现这一目标。
|
||||
|
||||
表示“包(Package)”的图形符号与Windows中表示文件夹的图符很相似,包的作用与文件夹的作用也很相似。如“java.awt”包的表示方法如图15所示。
|
||||
|
||||

|
||||
|
||||
图15 表示“java.awt”包的UML符号
|
||||
|
||||
**注释符号**
|
||||
|
||||
在UML中,用来对其他事物进行解释的部分(文本解释)称为注释。注释符号用一个右上角折起来的矩形表示,解释的文字就写在矩形框中,如图16所示。
|
||||
|
||||

|
||||
|
||||
图16 表示注释的UML符号
|
||||
|
||||
**构造块——关系符号的解释**
|
||||
|
||||
前面介绍了表示事物的元素符号,本节将介绍反映事物之间关系的关系符号。在UML中,共定义了24种关系,相应的有24种关系符号,如表2-1所示。
|
||||
|
||||
表2-1 UML中的关系及其符号
|
||||
|
||||
| 关系大类 | 关系变种 | UML中的关系 | UML符号 | 关系大类 | 关系变种 | UML中的关系 | UML符号 |
|
||||
|----------|-----------|-------------|---------------------|----------|----------|-------------|---------------------|
|
||||
| 抽象 | 派生 | 依赖关系 | 《derive》 | 导入 | 私有 | 依赖关系 | 《access》 |
|
||||
| | 显现 | | 《manifest》 | | 公有 | | 《import》 |
|
||||
| | 实现 | 实现关系 | 虚线加空心三角 | 信息流 | | | 《flow》 |
|
||||
| | 精化 | 依赖关系 | 《refine》 | 包含并 | | | 《merge》 |
|
||||
| | 跟踪 | | 《trace》 | 许可 | | | 《permit》 |
|
||||
| 关联 | | 关联关系 | 实线 | 协议符合 | | | 未指定 |
|
||||
| 绑定 | | 依赖关系 | 《bind》 (参数表) | 替换 | | 依赖关系 | 《substitu-te》 |
|
||||
| 部署 | | | 《deploy》 | 使用 | 调用 | | 《call》 |
|
||||
| 扩展 | Extend | | 《extend》 (扩展点) | | 创建 | | 《create》 |
|
||||
| 扩展 | extension | 扩展关系 | 实线加实心三角 | | 实例化 | | 《instanti-ate》 |
|
||||
| 泛化 | | 泛化关系 | 实线加空间三角 | | 职责 | | 《responsi-bility》 |
|
||||
| 包含 | | 依赖关系 | 《include》 | | 发送 | | 《send》 |
|
||||
|
||||
上述有24种关系,在UML中,可以归纳为关联关系、实现关系、泛化关系、扩展关系和依赖关系5种,下面介绍这些关系的表示方法。
|
||||
|
||||
1.关联关系
|
||||
|
||||
> 只要2个类之间存在某种关系,我们就认为2个类之间存在关联。关联是人们赋予事物之间的联系,即,只要我们认为2个事物之间有某种联系,就认为事物之间存在关联。实现关系、泛化关系、扩展关系和依赖关系都属于关联关系,是更具体的关联关系。关联关系是最高层次的关系,在所有关系中,关联的语义最弱的。
|
||||
|
||||
在关联关系中,有两种比较特殊的关系,它们是聚合关系和组合关系。
|
||||
|
||||
(1)关联关系的表示
|
||||
|
||||
> 关联关系是是比较抽象的关系,它包含的语义较少;聚合关系和组合关系是更具体的关联关系,它包含的语义更具体。在UML中,使用一条实线来表示关联关系如图17所示。
|
||||
|
||||

|
||||
|
||||
图17 表示关联关系的UML符号
|
||||
|
||||
(2)聚合关系
|
||||
|
||||
> 聚合(Aggregation)是一种特殊形式的关联,表示类之间的关系是整体与部分的关系。聚合关系是一种松散的对象间关系——计算机与它的外围设备就是聚合关系。一台计算机和它的外设之间只是很松散地结合在一起,这些外设可有可无,可以与其他计算机共享。即,部分可以离开整体而存在。
|
||||
|
||||
> 聚合的表示方法如图18(a)所示。其中棱形端表示事物的整体,另一端表示事物的部分。如计算机就是整体,外设就是部分。
|
||||
|
||||
(3)组合关系
|
||||
|
||||
> 如果发现“部分”类的存在是完全依赖于“整体”类的,那么就应使用“组合”关系
|
||||
> 来描述。组合关系是一种非常强的对象间关系,就像树和树叶之间的关系。树和它的叶子紧密联系在一起,叶子完全依赖树,它们不能被其他的树所分享,并且当树死去时,叶子也会随之死去——这就是组合,在组合关系中,部分依赖于整体而存在。组合是一种强的聚合关系,它的表示方法如图18(b)所示。
|
||||
|
||||

|
||||
|
||||
(a) (b)
|
||||
|
||||
图18 表示聚合关系和组合关系的UML符号
|
||||
|
||||
2.泛化关系
|
||||
|
||||
> 泛化关系描述了从特殊事物到一般事物之间的关系,也就是子类到父类之间的关系,或者子接口到父接口的关系。表示泛化关系的符号是从子类指向父类的带空心箭头的实线,其表示方法如图19所示。而从父类到子类的关系则是特化关系。
|
||||
|
||||

|
||||
|
||||
图19 表示泛化关系的UML符号
|
||||
|
||||
3.实现关系
|
||||
|
||||
> 实现关系是用来规定接口与实现接口的类之间的关系。接口是操作的集合,这些操作声明了类或组件所提供的服务。表示实现关系的符号是从类指向接口的带空心箭头的虚线,其表示方法如图20所示。
|
||||
|
||||

|
||||
|
||||
图20 表示实现关系的UML符号
|
||||
|
||||
4.依赖关系
|
||||
|
||||
假设有两个元素X、Y,如果元素X的值发生变化,就会引起元素Y的值的变化,则称元素Y依赖(Dependency)于元素X。依赖关系的表示如图21所示。
|
||||
|
||||

|
||||
|
||||
图21 表示依赖关系的UML符号
|
||||
|
||||
如果两个元素是类,则类间的依赖现象有多种,如一个类向另一个类发消息;一个类是另一个类的数据成员;一个类是另一个类的某个方法的参数。
|
||||
|
||||
从本质上说,聚合、组合、泛化以及实现关系都属于依赖关系,但是它们有更特别的语义。
|
||||
|
||||
5.扩展关系
|
||||
|
||||
在UML中,用一个带箭头的实线表示扩展关系,如图22所示。这里的扩展含义是指对一个元类的扩展,即,通过扩展元类的语义,获得新的元类。
|
||||
|
||||

|
||||
|
||||
图22 表示扩展关系的UML符号
|
||||
249
UML建模/3 UML笔记之图和视图.md
Normal file
@@ -0,0 +1,249 @@
|
||||
UML构造块——图的解释
|
||||
|
||||
UML中的图可分为两大类:结构图和行为图。结构图描绘系统中事物的组成及结构关系;行为图描绘系统中事物间的相互交互行为。下面是UML图的组成,如图23所示。(图是根据UML中存在的构造块进行说明的,视图是根据要具体解决的问题对系统进行说明。也就是说,要想完成某个视图,需要使用一个或者多个UML中的构造块,由事物构成的图)
|
||||
|
||||

|
||||
|
||||
图23 UML图的组成
|
||||
|
||||
**1.结构图(静态结构图)**
|
||||
|
||||
结构图又分为6种,如图24所示。
|
||||
|
||||

|
||||
|
||||
图6-24 结构图组成
|
||||
|
||||
(1)类图
|
||||
|
||||
类图是使用UML建模时最常用的图,它展示了系统中的静态事物、它们的结构以及它们之间的相互关系。这种图的典型用法是描述系统的逻辑设计和物理设计。
|
||||
|
||||
(2)构件图
|
||||
|
||||
构件图可以展示一组构件的组织和彼此间的依赖关系,它用于说明软件系统如何实现,以及软件系统内构件如何协同工作等。
|
||||
|
||||
(3)对象图
|
||||
|
||||
对象图可以展示系统中的一组对象,它是系统在某一时刻的快照,也可以说对象图是类图在某一时刻的快照。
|
||||
|
||||
(4)部署图
|
||||
|
||||
部署图可以展示物理系统运行时的架构,同时可以描述系统中的硬件架构和硬件上驻留的软件架构。
|
||||
|
||||
(5)组合结构图
|
||||
|
||||
组合结构图可以展示系统的内部结构。
|
||||
|
||||
(6)包图
|
||||
|
||||
包图用于描绘包之间的依赖关系(包是一个用于组织其他模型元素的通用模型元素)。
|
||||
|
||||
**2.行为图(动态性位图)**
|
||||
|
||||
行为图又细分为4种,如图6-25所示。
|
||||
|
||||

|
||||
|
||||
图6-25 行为图组成
|
||||
|
||||
(1)活动图
|
||||
|
||||
活动图显示系统内部的活动控制流程。通常需要使用活动图描述不同的业务过程。
|
||||
|
||||
(2)状态图
|
||||
|
||||
状态图显示对象从一种状态迁移到其它状态的转换过程。状态图是一个动态视图,对事件驱动的行为建模尤其重要,例如可以利用状态图描述一个电话路由系统中交换机的状态,不同的事件可以令交换机转移至不同的状态,用状态图对交换机建模有助于理解交换机的动态行为。在
|
||||
UML 2.0中,状态图被称为状态机图(state machine diagram)。
|
||||
|
||||
(3)协作图
|
||||
|
||||
协作图(也称通信图)是交互图的一种,交互图还包括顺序图(以及UML
|
||||
2.0中新定义的其他几种图,稍后将介绍)。协作图突出对象之间的合作与交互。
|
||||
|
||||
(4)顺序图
|
||||
|
||||
顺序图是另一种交互图,它强调一个系统中间相互作用时消息的时间顺序。
|
||||
|
||||
UML 2.0中又增加了下列几种行为图:
|
||||
|
||||
(5)时间图
|
||||
|
||||
时间图也是一种交互图,它描绘与交互对象的状态转换或条件变化有关的详细时间 信息。
|
||||
|
||||
(6)交互概观图
|
||||
|
||||
交互概观图是一种高层视图,用于从总体上显示交互序列之间的控制流。
|
||||
|
||||
注意:在实际进行系统建模时,几乎没有人会使用到UML标准中定义的所有图。
|
||||
|
||||
(7)用例图
|
||||
|
||||
用例描述了系统的工作方式,以及系统能提供的服务。用例图描述了系统外部参与者如何使用系统提供的服务。
|
||||
|
||||
注意:组合结构图、包图及用例图是UML 2.0中新增的结构图。
|
||||
|
||||
3\. 图的功能
|
||||
|
||||
在UML 2.0中共定义了13种图。
|
||||
|
||||
| 图分类 | 作 用 | 描述 |
|
||||
|------------|----------------------------------------------------------------------------|-------------------|
|
||||
| 类图 | 描述系统中的类组成和类之间的关系 | 与UML 1.0相同 |
|
||||
| 对象图 | 描述系统在某个时刻对象的组成和关系 | UML 1.0非正式图 |
|
||||
| 复合结构图 | 描述复合对象的内部结构 | UML 2.0新增 |
|
||||
| 构件图 | 描述构件的结构与组成 | 与UML 1.0相同 |
|
||||
| 部署图 | 描述在系统中各个节点上的构件及其构件之间的关系 | 与UML 1.0相同 |
|
||||
| 包图 | 描述系统的宏观结构,并用包来表示 | UML中非正式图 |
|
||||
| 用例图 | 描述用户与系统如何交互及系统提供的服务 | 与UML 1.0相同 |
|
||||
| 活动图 | 描述活动控制流程及活动节点的转换过程 | 与UML 1.0相同 |
|
||||
| 状态机图 | 描述对象生命周期内,在外部事件的作用下,对象从一种状态如何转换到另一种状态 | 与UML 1.0相同 |
|
||||
| 顺序图 | 描述对象之间的交互,重点在强调消息发送的顺序 | 与UML 1.0相同 |
|
||||
| 协作图 | 描述对象之间的交互,重点在于强调对象的职责 | UML 1.0中的协作图 |
|
||||
| 定时图 | 描述对象之间的交互,重点在于描述时间信息 | UML 2.0 新增 |
|
||||
| 交互概观图 | 是一种顺序图与活动图的混合嫁接 | UML 2.0新增 |
|
||||
|
||||
表2-2 UML 2.0中的图
|
||||
|
||||
从使用的角度来看,可以将UML的13种图分为结构模型(也称为静态模型)和行为模型(也称为动态模型)两大类。
|
||||
|
||||
构造块——图与视图的实现关系
|
||||
|
||||
图可视化地描绘了系统某个方面的局部特征;多个相关的图可以描述系统的某个方面的全部特征,我们把描述系统某个方面全部特征的多个图的集合称为视图。
|
||||
|
||||
在UML参考手册第2版中,将UML图划分为4大应用类型和9种视图,如表2-3所示。
|
||||
|
||||
表2-3 UML图和视图
|
||||
|
||||
| 应用类型 | 视 图 | 组成 |
|
||||
|----------|--------------|------------------------------------|
|
||||
| 结构领域 | 静态视图 | 类图,对象图 |
|
||||
| | 设计视图 | 复合结构图、协作图、构件图,对象图 |
|
||||
| | 用例视图 | 用例图 |
|
||||
| 动态领域 | 状态视图 | 状态机图 |
|
||||
| | 活动视图 | 活动图 |
|
||||
| | 交互视图 | 顺序图、通信图,时间图,交互概述图 |
|
||||
| 物理领域 | 部署视图 | 部署图 |
|
||||
| 模型管理 | 模型管理视图 | 包图 |
|
||||
| | 特性描述 | 包图 |
|
||||
|
||||
其中,结构领域的视图描述了系统中的结构成员及其相互关系;动态领域的视图描述了系统随时间变化的行为;物理领域的视图描述了系统的硬件结构和部署在这些硬件上的系统软件;模型管理领域的视图说明了系统的分层组织结构。
|
||||
|
||||
构造块——对各种图的简单描述
|
||||
|
||||
13、用例图(use case diagrams)
|
||||
|
||||
> 【概念】描述用户需求,从用户的角度描述系统的功能
|
||||
|
||||
> 【描述方式】椭圆表示某个用例;人形符号表示角色
|
||||
|
||||
> 【目的】帮组开发团队以一种可视化的方式理解系统的功能需求
|
||||
|
||||
> 【用例图】
|
||||
|
||||

|
||||
|
||||
1、类图(class diagrams)
|
||||
|
||||
> 【概念】显示系统的静态结构,表示不同的实体是如何相关联的
|
||||
|
||||
> 【描述方式】三个矩形
|
||||
|
||||
> 【目的】表示一个逻辑类或实现类,逻辑类通常是用户的业务所涉及的事物;实现类是程序员处理的实体
|
||||
|
||||
> 【类图】
|
||||
|
||||

|
||||
|
||||
3、 对象图(object diagrams)
|
||||
|
||||
> 【概念】类图的一个实例,描述系统在具体时间点上所包含的对象以及各个对象的关系
|
||||
|
||||
> 【对象图】
|
||||
|
||||

|
||||
|
||||
10、 序列图(顺序图)
|
||||
|
||||
> 【概念】描述对象之间的交互顺序,着重体现对象间消息传递的时间顺序
|
||||
|
||||
> 【描述方式】横跨图的顶部,每个框表示每个类的实例或对象;类实例名称和类名称使用冒号分开
|
||||
|
||||
> 【目的】显示流程中不同对象之间的调用关系,还可以显示不同对象的不同调用。
|
||||
|
||||
> 【序列图】
|
||||
|
||||

|
||||
|
||||
4、 协作图(Collaboration diagrams)
|
||||
|
||||
【概念】描述对象之间的合作关系,侧重对象之间的消息传递
|
||||
|
||||
8、 状态图(Statechart diagrams)
|
||||
|
||||
【概念】描述对象的所有状态以及事件发生而引起的状态之间的转移
|
||||
|
||||
【描述方式】
|
||||
|
||||
- 起始点:实心圆
|
||||
|
||||
- 状态之间的转换:使用开箭头的线段
|
||||
|
||||
- 状态:圆角矩形
|
||||
|
||||
- 判断点:空心圆
|
||||
|
||||
- 一个或多个终止点:内部包含实心圆的圆
|
||||
|
||||
【目的】表示某个类所处的不同状态以及该类在这些状态中的转换过程
|
||||
|
||||
7、 活动图(Activity diagrams)
|
||||
|
||||
> 【概念】描述满足用例要求所要进行的活动以及活动时间的约束关系
|
||||
|
||||
> 【描述方式】
|
||||
|
||||
- 起始点:实心圆
|
||||
|
||||
- 活动:圆角矩形
|
||||
|
||||
- 终止点:内部包含实心圆的圆
|
||||
|
||||
- 泳道:实际执行活动的对象
|
||||
|
||||
【目的】表示两个或多个对象之间在处理某个活动时的过程控制流程
|
||||
|
||||
【活动图】
|
||||
|
||||

|
||||
|
||||
活动图和状态图区别:
|
||||
|
||||

|
||||
|
||||
2、构件图(Component diagrams)
|
||||
|
||||
> 【概念】描述代码构件的物理结构以及各构件之间的依赖关系
|
||||
|
||||
> 【描述方式】构件
|
||||
|
||||
> 【目的】提供系统的物理视图,根据系统的代码构件显示系统代码的整个物理结构
|
||||
|
||||
> 【构架图】
|
||||
|
||||

|
||||
|
||||
4、 部署图(Deployment diagrams)
|
||||
|
||||
> 【概念】系统中硬件的物理体系结构
|
||||
|
||||
> 【描述方式】
|
||||
|
||||
1. 三维立方体表示部件
|
||||
|
||||
2. 节点名称位于立方体上部
|
||||
|
||||
【目的】显示系统的硬件和软件的物理结构
|
||||
|
||||
【部署图】
|
||||
|
||||

|
||||
82
UML建模/4 UML笔记之规则和公共机制.md
Normal file
@@ -0,0 +1,82 @@
|
||||
规则
|
||||
|
||||
> 在UML中,代表事物的元素符号在使用时应遵守一系列规则,每个元素必须遵守的3种语义规则如下:
|
||||
|
||||
> l
|
||||
> 名称:每个元素应该有一个名字,即,事物、关系和图都应该有一个名字。和任何语言一样,名字即是一个标识符。
|
||||
|
||||
> l 范围:每个元素起作用的范围。相当于程序设计语言中变量的“作用域”。
|
||||
|
||||
> l
|
||||
> 可见性:我们知道,UML元素可能属于一个类或包中,因此,所有元素都具有可见属性。在UML中,为元素定义了4种可见性,如表2-4所示。
|
||||
|
||||
表2-4 UML元素的可见性
|
||||
|
||||
| 元素的可见性 | 规 则(假设被访问的元素在包中) | 标准表示法 |
|
||||
|--------------|----------------------------------------------|------------|
|
||||
| public | 任一元素若能访问包,则就可以访问包中的元素它 | + |
|
||||
| protected | 只有包中的元素或子包才能访问它 | \# |
|
||||
| private | 只有包中的元素才能访问它 | - |
|
||||
| package | 只有声明在同一个包中的元素才能访问该元素 | ~ |
|
||||
|
||||
公共机制
|
||||
|
||||
在UML语言中,定义了4种公共机制:规格描述、修饰、通用划分和扩展机制。
|
||||
|
||||
**规格描述**
|
||||
|
||||
> 在UML语言中,对每一个元素有一个图形符号来表示,同时,对每个图形符号的语义有一个详细的文字描述,这种对图形符号的语义进行的文字描述称为规格描述,也称为详述。
|
||||
|
||||
> 如图26所示,在左边的方框中有三个用图形符号表示的用例,分别是:“存款“、“取款”
|
||||
> 、”转账”,在右边的方框中,分别对每个图形符号表示的用例进行了详细的文字描述,即规格描述。
|
||||
|
||||

|
||||
|
||||
图26 图形符号与对应的规格描述
|
||||
|
||||
**修饰**
|
||||
|
||||
> 在UML中,每个元素符号对事物的主要方面提供了可视化表示,而若想将事物的细节表示出来,则必须对元素符号加以修饰。例如,用斜体字表示抽象类,用+,-符号表示元素的访问级别,这些都是通过修饰符号来表示事物的细节。所谓修饰就是增加元素符号的内涵,为被修饰的元素提供更多的信息。
|
||||
|
||||
**通用划分**
|
||||
|
||||
> UML通用划分,即对UML元素进行分组,包括两组:类与对象、接口与实现。
|
||||
|
||||
> l 类与对象:类是对对象共同特征的描述、是对象的模板,而对象则是类的实例。
|
||||
|
||||
> l
|
||||
> 接口与实现:接口是一种声明、一个合同、是一组方法的集合,而实现则是完成一个合同、实现接口中的声明。
|
||||
|
||||
> 在UML中,用例就是一种对功能的声明和定义,是对事物功能的抽象描述;而协作则是实现用例声明的功能;操作名是声明服务的,而方法体则是实现服务的。因此,用例与协作、操作名与方法体之间就是接口与实现的关系。
|
||||
|
||||
**扩展机制**
|
||||
|
||||
> 由于UML中定义的元素符号不能表示所有的事物,因此需要通过一些方法对元素符号进行扩展,主要的扩展机制有:构造型、标记值和约束。
|
||||
|
||||
1.构造型
|
||||
|
||||
> 构造型就是指分析师自已定义一种新的UML元素符号,给这种新的元素符号赋予特别的含义,例如,分析师可以定义一个元素符号《Interrupt》,用该元素符号代表“中断”。
|
||||
|
||||
> 表示同一构造型元素符号的方法有3种,图27所示就是用3种不同方式来表示设备“中断”这种构造型,其中假设Equipment(设备)是类名称。
|
||||
|
||||

|
||||
|
||||
> 图27 构造型的3种表示方法
|
||||
|
||||
> l
|
||||
> 第一种表示方法:创建一种新的UML元素符号《Interrupt》,表示“中断”,在构造元素符号右边放置一个图标。构造符号“《Interrupt》”与图标一起代表“中断”。
|
||||
|
||||
> l
|
||||
> 第二种表示法:创建一种新的UML元素符号《Interrupt》,表示“中断”,这是一种标准表示方法。
|
||||
|
||||
> l 第三种表示方法:直接用一个图标表示新的构造元素符号,该符号的语义是“中断”。
|
||||
|
||||
2.标记值
|
||||
|
||||
> 标记值是用来为事物(元素符号)添加新特征的,其表示方法是用格式如“{标记信息}”的字符串表示。标记信息通常是一个字符串,它由名称、分隔符和值3个部分组成。例如,标记信息:{name=“李小平”}
|
||||
> 。在这个标记信息中,名称是name ; 分隔符是= ;标记值是”李小平”
|
||||
> 。其中,名称表示了事物的属性。标记值表示了事物的属性值。
|
||||
|
||||
3.约束
|
||||
|
||||
> 约束是用来标识元素之间约束条件,是用来增加新的语义或改变已存在规则的一种机制(通过文本和OCL两种方法表示约束)。约束的表示方法和标记值的表示方法类似,都是使用花括号括起来的字符串来表示,不过不能够把它放在元素中,而是要放在相关的元素附近。
|
||||
173
UML建模/5 UML笔记之类图关系.md
Normal file
@@ -0,0 +1,173 @@
|
||||
几种关系
|
||||
|
||||
在UML类图中,常见的有以下几种关系: 泛化(Generalization), 实现(Realization),
|
||||
关联(Association), 聚合(Aggregation), 组合(Composition), 依赖(Dependency)
|
||||
|
||||
**1. 泛化(Generalization)**
|
||||
|
||||
【泛化关系】:(is a)是一种继承关系, 表示一般与特殊的关系,
|
||||
它指定了子类如何特化父类的所有特征和行为。子类拥有超类所欲的属性和擦偶偶。
|
||||
例如:老虎是动物的一种, 即有老虎的特性也有动物的共性.
|
||||
|
||||
【箭头指向】:带三角箭头的实线,箭头指向父类
|
||||
|
||||

|
||||
|
||||
**2. 实现(Realization)**
|
||||
|
||||
【实现关系】:是一种类与接口的关系, 表示类是接口所有特征和行为的实现.
|
||||
|
||||
【箭头指向】:带三角箭头的虚线,箭头指向接口
|
||||
|
||||

|
||||
|
||||
**3. 关联(Association)**
|
||||
|
||||
【关联关系】:(has a )是一种拥有的关系,
|
||||
它使一个类知道另一个类的属性和方法;如:老师与学生,丈夫与妻子
|
||||
|
||||
【关系要素】:
|
||||
|
||||
- 关联名:动词、有方向(黑三角表示)。
|
||||
|
||||

|
||||
|
||||
- 关联端名:关联的一端相对于另一端的特征,功能和离场。
|
||||
|
||||

|
||||
|
||||
- 多重度:相关联的实例对象之间的对应关系。
|
||||
|
||||
必须是1 1
|
||||
|
||||
0或者1 0. .1
|
||||
|
||||
0以上 0. . \* 或 \*
|
||||
|
||||
1以上 1 . . \*
|
||||
|
||||
指定区间 1 . . 10
|
||||
|
||||

|
||||
|
||||
- 关联方向:
|
||||
|
||||
关联的两个类互相之间都会去向对方发送消息的情况下,称为双向关联。关联端两端都要用箭头明示。
|
||||
|
||||

|
||||
|
||||
关联的两个类之间,只能由一端向另外一端的类发消息,而反过来不行时,称为单向关联。接受消息一方的关联端用箭头表示,不能接受消息一方的关联端用“X”进行表示。
|
||||
|
||||

|
||||
|
||||
关联的某一端的关联方向尚未明确的情况下,可不标明方向性。
|
||||
|
||||

|
||||
|
||||
- 限定符:为了减少相关联的对象数目而设置的条件。限定符用小矩形框表示,矩形框加在关联端上,矩形框内要写明限定符属性。限定符属性对应于关联的另一侧类中的一个属性。
|
||||
|
||||

|
||||
|
||||
【代码体现】:拥有者含有一个成员变量,指向被拥有者。
|
||||
|
||||
【箭头及指向】:带普通箭头的实心线,指向被拥有者
|
||||
|
||||

|
||||
|
||||
上图中,老师与学生是双向关联,老师有多名学生,学生也可能有多名老师。但学生与某课程间的关系为单向关联,一名学生可能要上多门课程,课程是个抽象的东西他不拥有学生。
|
||||
|
||||
【特殊关系】
|
||||
|
||||
- 递归关联:一个类和自身具有某种关联时,称为递归关联。
|
||||
|
||||

|
||||
|
||||
- 多重关联:两个类之间具有多个不同意义的关联,可以通过附加关联名或者关联端名来进行区分。
|
||||
|
||||

|
||||
|
||||
**4. 依赖(Dependency)**
|
||||
|
||||
【依赖关系】:是一种使用的关系, 即一个类的实现需要另一个类的协助,
|
||||
所以要尽量不使用双向的互相依赖.
|
||||
|
||||
【关系分类】:
|
||||
|
||||
- 一个类的对象作为另外一个类的参数被调用。
|
||||
|
||||

|
||||
|
||||
- 一个类的对象作为局部变量被调用。
|
||||
|
||||

|
||||
|
||||
- 一个类的对象作为全局变量被调用
|
||||
|
||||

|
||||
|
||||
【代码表现】:局部变量、方法的参数或者对静态方法的调用
|
||||
|
||||
【箭头及指向】:带箭头的虚线,指向被使用者
|
||||
|
||||

|
||||
|
||||
**5. 聚合(Aggregation)**
|
||||
|
||||
【聚合关系】:(part of)是整体与部分的关系, 且部分可以离开整体而单独存在.
|
||||
如车和轮胎是整体和部分的关系, 轮胎离开车仍然可以存在.
|
||||
|
||||
聚合关系是关联关系的一种,是强的关联关系;关联和聚合在语法上无法区分,必须考察具体的逻辑关系。
|
||||
|
||||
【代码体现】:成员变量
|
||||
|
||||
【箭头及指向】:带空心菱形的实心线,菱形指向整体
|
||||
|
||||

|
||||
|
||||
**6. 组合(Composition)**
|
||||
|
||||
【组合关系】:是整体与部分的关系, 但部分不能离开整体而单独存在.
|
||||
如公司和部门是整体和部分的关系,
|
||||
没有公司就不存在部门.组合关系是关联关系的一种,是比聚合关系还要强的关系,它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期
|
||||
|
||||
【代码体现】:成员变量
|
||||
|
||||
【箭头及指向】:带实心菱形的实线,菱形指向整体
|
||||
|
||||

|
||||
|
||||
各种关系的强弱顺序:
|
||||
|
||||
**泛化 = 实现 \> 组合 \> 聚合 \> 关联 \> 依赖**
|
||||
|
||||
下面这张UML图,比较形象地展示了各种类图关系:
|
||||
|
||||

|
||||
|
||||
聚合与组合的区分
|
||||
|
||||
**途径**
|
||||
|
||||
1)物理上整体的事物与它的部分事物,例如:人体与各种人体器官
|
||||
|
||||
2)组织机构与它的下级组织或部门,例如:市场部与公关部、产品部
|
||||
|
||||
3)团体(组织)与成员,例如:班级与学生
|
||||
|
||||
4)空间上的包容关系,例如:教室与桌椅
|
||||
|
||||
5)抽象事物的整体与部分,例如:学科与学科分支
|
||||
|
||||
6)具体事物和它的某个抽象方面,例如:人员基本信息与各个阶段的信息
|
||||
|
||||
7)在材料上的组成关系,例如:面包与面包材料
|
||||
|
||||
**原则**
|
||||
|
||||
1)聚合中的整体对象和部分对象,若不属于问题域,则应该去掉,例如:业务系统中,职工与家庭的聚合关系。
|
||||
|
||||
2)聚合中的整体对象和部分对象,若不是系统责任需要的,则应该去掉,例如:赛车系统中,车和车轮的聚合关系。
|
||||
|
||||
3)聚合中的部分对象若只有一个属性,则应该考虑取消它,把属性放到整体对象中去。例如:汽车销售系统中,汽车和只有规格一个属性的车轮聚合。
|
||||
|
||||
4)如果两个对象不能明显分出整体---部分关系,则不应该用聚合关系表示。例如:财务系统中,名细帐和总帐,不明显有整体部分结构。
|
||||
165
UML建模/6 UML笔记之类图.md
Normal file
@@ -0,0 +1,165 @@
|
||||
类图概述
|
||||
|
||||
**类图定义**
|
||||
|
||||
> 类图显示了系统的静态结构。类图就是用于对系统中的各种概念进行建模,并描绘类图之间的静态关系。再简单一点,类就是一组具有相同结构、行为、关系的一群对象。
|
||||
|
||||
**组成要素**
|
||||
|
||||
类(类名,属性,操作)、关系(关联,泛化,聚合等)
|
||||
|
||||
**类图示例**
|
||||
|
||||

|
||||
|
||||
**类的表示**
|
||||
|
||||

|
||||
|
||||
**类的关系**
|
||||
|
||||
已经单独说明
|
||||
|
||||
类的详细描述
|
||||
|
||||

|
||||
|
||||
**类的名称**
|
||||
|
||||
**类的属性**
|
||||
|
||||
\- hello : String = "hello"
|
||||
|
||||
**类的操作**
|
||||
|
||||
\+getHello(in num:int = 1):String
|
||||
|
||||
**可见性:**公有类型(public)、受保护类型(protected)、私有类型(private)、Implementation。
|
||||
|
||||
- 公有类型(public):允许在类的外面使用或查看该属性
|
||||
|
||||
- 受保护类型(protected):允许子类访问父类中受保护类型的属性
|
||||
|
||||
- 私有类型(private):只有类本身能够访问,外部一概不能
|
||||
|
||||
- 包访问类型(package)Implementation:该属性仅仅在被定义的包中才能够可见
|
||||
|
||||
**作用域**
|
||||
|
||||
- 类作用域:类的所有对象共享的属性或者操作,成为类作用域属性或者类作用域操作。即静态的属性和方法。在属性名或者操作名加下划线,或者之前加{static}标记。类作用域的属性值在该类的所有对象中共享。类作用域的操作是通过类来调用的。
|
||||
|
||||
- 实例作用域:类得所有对象拥有各自独立的值的属性作为实例作用域属性。需要通过访问对象来调用的操作成为实例作用域操作。默认情况下属性和操作为实例作用域。实例作用域要调用具体具体的对象来实现。
|
||||
|
||||
用到的构造块——事物有:类、接口、协作、注释、约束和包。
|
||||
|
||||
用到的构造块——关系:依赖、繁华、关联关系、实现关系。
|
||||
|
||||
类版型
|
||||
|
||||
**边界类(boundary class)**
|
||||
|
||||
- 定义:位于系统与外界的交界处,包括所有窗体(form)、报表(report)、与外部设备的接口(interface),以及与其它系统的接口等。
|
||||
|
||||
- 表示方式:
|
||||
|
||||

|
||||
|
||||
- 说明:通过usecase可以确定需要的边界类。每个actor/usecase至少需要一个边界类。
|
||||
|
||||

|
||||
|
||||
**实体类**
|
||||
|
||||
- 定义:保存持久存储的信息。
|
||||
|
||||
- 表示方式:
|
||||
|
||||

|
||||
|
||||
- 说明:对应数据库表。可以通过事件流和交互图发现。
|
||||
|
||||
**控制类**
|
||||
|
||||
- 负责其他类工作的类。
|
||||
|
||||
- 表示方式:
|
||||
|
||||

|
||||
|
||||
- 说明:每个usecase有一个控制类,控制usecase中事件的顺序。控制类负责发送接收消息。
|
||||
|
||||
类图的抽象层次
|
||||
|
||||
**概念层**
|
||||
|
||||
类图描述应用领域中的概念,一般地,这些概念和类有很自然的联系,但两者并没有直接的映射关系。概念层的类图应独立于具体的程序设计语言。
|
||||
|
||||
**说明层**
|
||||
|
||||
类图描述软件的接口部分,而不是软件的实现部分。
|
||||
|
||||
**实现层**
|
||||
|
||||
类图才真正考虑类的实现问题,揭示实现细节。实现层的类图可能是大多数人最常用的类图,但在很多时候,说明层的类图更易于开发者之间的相互理解和交流。
|
||||
|
||||

|
||||
|
||||
特殊的类图
|
||||
|
||||
**抽象类和抽象方法**
|
||||
|
||||
不能直接实例化的类。抽象类和抽象方法的名字要用斜体表示(标准方法法)或者使用草图表示法《》
|
||||
|
||||
示例:
|
||||
|
||||

|
||||
|
||||
**接口**
|
||||
|
||||
> 定义:接口是一种特殊的类,所有接口都是有构造型的类,定义类或者组件,或者子系统公开给外部的操作的功能之定义操作的功能,不对操作进行实现。
|
||||
|
||||
> 表示方式:有两种方式来表示接口,一种使用图标表示,没有列出接口包含的具体的方法。一种是构造型表示接口,列出了接口的内部方法。
|
||||
|
||||
接口关系:接口同样具有依赖和泛化的关系
|
||||
|
||||
> 依赖:一个类通过依赖关系与接口相连接,仅仅依赖于接口中的操作
|
||||
|
||||
> 泛化:跟类之间泛化关系同理
|
||||
|
||||
> 接口优点:只要接口定义不变,对接口的实现进行改变,也不用改变调用接口的操作。
|
||||
|
||||
示例:
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
**关联类**
|
||||
|
||||
在多对多关系中,有些属性不属于关联两端的任何一个类。在分析阶段使用关联类代替。
|
||||
|
||||
在设计阶段必须将关联类设计为具体的可实现编程的类。关联类和关联线之间使用虚线连接,没有箭头三角。
|
||||
|
||||
通过关联类描述关联的属性和操作以及其他信息。
|
||||
|
||||

|
||||
|
||||
**模板类**
|
||||
|
||||
模板类又称作参数化类。模板类定义了一族类,模板类拥有一个参数,这个参数表中的参数称为形参,当用实际参数代替形参之后,才能穿件一个具体的类。右上角有一个虚线框,列出了形参表。
|
||||
|
||||
示例:
|
||||
|
||||

|
||||
|
||||
**主动类**
|
||||
|
||||
程序在运行时能够主动改变自身状态的对象就是主动对象。用于创建主动对象的类就是主动类。在程序执行期间一个主动对象能够控制自身的活动,具有独立的控制权。不需要外界消息的驱动。是种类,创建时钟对象能改变自身状态。
|
||||
|
||||
**嵌套类**
|
||||
|
||||
在类的内部定义新的类。
|
||||
|
||||
示例:
|
||||
|
||||

|
||||
57
UML建模/7 UML笔记之对象图.md
Normal file
@@ -0,0 +1,57 @@
|
||||
对象图概述
|
||||
|
||||
**定义**
|
||||
|
||||
表示系统在某一时刻内部的对象状态,是系统的快照。对象图显示了一组对象和他们之间的关系。对象是客观存在的事物,所有的对象都有属性。
|
||||
|
||||
**三要素**
|
||||
|
||||
状态:对象状态值在某一时刻对象所有属性的集合。
|
||||
|
||||
行为:没有一个对象是孤立存在的,对象可以被操作,也可以操作别的对象,对象的这些动态特征成为对象的行为。
|
||||
|
||||
标识:为了讲一个对象和其他对象分开,赋予对象一个标识,以区别其他对象。
|
||||
|
||||
**对象与类的区别**
|
||||
|
||||
对象是类的一个实例,类是对一组对象的共同特征进行概括和描述。
|
||||
|
||||
对象是存在于时间空间中的具体实体,二类是一个类型。
|
||||
|
||||
类泛华了对象,对象特化了实体。类是定义,对象是实例。
|
||||
|
||||
**对象分类**
|
||||
|
||||
物理对象和概念对象。物理对象是客观存在的事物,概念对象是无形的事物。
|
||||
|
||||
领域对象和实现对象。从现实世界中识别出来的对象是领域对象。为了满足需求而构造的对象成为实现对象。
|
||||
|
||||
主动对象和被动对象。主动对象能够改变自身状态的对象,被动对象,只有接收到消息后才会改变自身状态。
|
||||
|
||||
**对象表示**
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
对象图实例:类在某一时刻的实例。在系统给的某一时刻存在。
|
||||
|
||||
对象图中的元素:对象、协作、注释、约束和包。
|
||||
|
||||
**对象图表示**
|
||||
|
||||

|
||||
|
||||
**对象图的用途**
|
||||
|
||||
- 系统快照,表示体统在某一时刻的状态。
|
||||
|
||||
- 辅助分析类图中的多重度关系。
|
||||
|
||||
对象图中的关系
|
||||
|
||||
**双向链接和单向链接**
|
||||
|
||||
实例:
|
||||
|
||||

|
||||
105
UML建模/8 UML笔记之包图.md
Normal file
@@ -0,0 +1,105 @@
|
||||
包图概述
|
||||
|
||||
**包图定义**
|
||||
|
||||
使用包图可以将相关元素归入一个系统。一个包中可以包含附属包、图表或单个元素。
|
||||
|
||||
**包的表示**
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
**组成元素**
|
||||
|
||||
类、接口、构建、节点、协作、用例、子包。
|
||||
|
||||
**包图优点:**
|
||||
|
||||
为了方便对类和接口的开发进行管理。
|
||||
|
||||
- 用于组织模型中的元素进行分组以便更容易理解。
|
||||
|
||||
- 对包中的元素进行可见性控制。
|
||||
|
||||
- 对于以上相关的元素进行分组。
|
||||
|
||||
- 以包为单位对系统进行配置管理。
|
||||
|
||||
- 以包为单位分配设计任务。
|
||||
|
||||
- 包提供了一个封闭的空间,避免命名冲突。
|
||||
|
||||
**包的应用**
|
||||
|
||||
- 对建模元素进行分组。提高模型的可读性和可维护性。
|
||||
|
||||
**包的设计原则**
|
||||
|
||||
前三个原则互斥。共同闭包原则希望包越大越好。共同重用原则要求包越小越好。
|
||||
|
||||
- 重用等价原则:指的是把类放入包中时,应考虑把包作为可重用的单元。
|
||||
|
||||
- 共同闭包原则:指的是把那些需要同时改变的类放在一个包中。如果一个类的行为和/或结构的改变要求另一个类作相应的改变,则这两个类应放在一个包中;•共同闭包原则就是要提高包的内聚性、降低包与包之间的耦合度,希望在改动或升级一个包的时候要尽量少影响别的包。
|
||||
|
||||
- 共同重用原则:指的是不会一起使用的类不要放在同一包中。修改了一个对用户实际上毫无影响的类,却逼得用户不得不重新检查是否还可以同样方式使用新的包是不合理的
|
||||
|
||||
- 非循环依赖原则:指的是包之间的依赖关系不要形成循环。
|
||||
|
||||
**包图建模风格**
|
||||
|
||||
- 内聚性
|
||||
|
||||
- 垂直分层类包图。显示了系统的逻辑分层。自上而下的方式画出分层结构。
|
||||
|
||||

|
||||
|
||||
- 用版型指明体系结构的层次
|
||||
|
||||
详细说明
|
||||
|
||||
**包图表示**
|
||||
|
||||

|
||||
|
||||
**包中的元素:**
|
||||
|
||||
可以包含其他建模元素类和接口、用例、子包、构件。包图可以嵌套。包图没有实例。
|
||||
|
||||
**包中元素的可见性:**
|
||||
|
||||
\+ public 共有的,任何元素都可以访问。
|
||||
|
||||
\# protected 保护的,继承可以访问。
|
||||
|
||||
\- private 私有的,同一个包内可以访问。
|
||||
|
||||
**包中类的表示**
|
||||
|
||||
包名::类名来表示包和类的对应关系。com.ykl::Server
|
||||
|
||||
**包的层次化表示**
|
||||
|
||||
包中还包含另外的包。
|
||||
|
||||

|
||||
|
||||
包之间的关系
|
||||
|
||||
包之间的关系可以是依赖关系或者泛化关系。包之间的故障逆袭取决于保内的关系。
|
||||
|
||||
**依赖关系:**用虚线箭头表示
|
||||
|
||||
> **《use》关系:**客户包中的元素以某种方式使用提供者包中的某些公共元素。被访问元素可见性为+
|
||||
|
||||
> **《import》关系:**客户报和提供者包命名空间合并。(若重名会出现命名冲突。)
|
||||
|
||||
> **《access》关系:**客户包通过全名访问提供者包中的元素。被访问元素可见性为+
|
||||
|
||||
> **《trace》关系:**客户报从提供者包进化而来。表示两个包不是属于同一级别。
|
||||
|
||||

|
||||
|
||||
**泛化关系:**子包继承了父包所有的公共元素和保护元素。
|
||||
|
||||

|
||||
213
UML建模/9 UML笔记之序列图.md
Normal file
@@ -0,0 +1,213 @@
|
||||
序列图概述
|
||||
|
||||
**定义**
|
||||
|
||||
> 交互图是一种表示对象之间以及对象与系统外部的参与者actor之间动态联系的图形文档。序列图和协作图都是交互图,彼此等价,可以相互转化。
|
||||
|
||||
> 序列图是对对象之间传送消息的时间顺序的可视化表示。序列图用于表现交互,侧重于强调时间顺序。协作图着重描述系统成分如何系统协同工作。
|
||||
|
||||
> **序列图将交互关系表示为一个二维图,**一个顺序图显示了一系列的对象和在在这些对象之间发送和接受消息的先后顺序。顺序图中水平方向为对象维,沿水平方向排列参与交互的对象;竖向方向为时间维,沿垂直向下方向按时间递增顺序列出各对象所发出和接收的消息。
|
||||
|
||||
**序列图示例**
|
||||
|
||||

|
||||
|
||||
> 注:虚线表示,此时对象不处于激活状态,双道线,表示对象处于激活状态;消息使用从一个对象的生命线到另一个对象的生命线的箭头表示。
|
||||
|
||||
**序列图的作用:**
|
||||
|
||||
> 检查用例图中描述的用户需求,。
|
||||
|
||||
> 和类图相互补充,表示对象之间的消息交互。
|
||||
|
||||
**序列图与类图的关系**
|
||||
|
||||
> 描述系统静态结构的类图和描述系统动态行为的交互图之间要保持一致性:
|
||||
|
||||
- 交互图中的生命线对应于类图中的类。
|
||||
|
||||
- 交互图中有消息交互的生命线,对应在类图中的两个类之间应该有一定的关联。
|
||||
|
||||
- 交互图中的消息对应于类图中接受该消息生命线所对应的类的某个操作。
|
||||
|
||||
**序列图的组成:**
|
||||
|
||||
> 序列图是由对象、生命线、激活和消息等构成的。
|
||||
|
||||

|
||||
|
||||
**建立顺序图的步骤**
|
||||
|
||||
> 1\. 确定交互过程的上下文(context);
|
||||
|
||||
> 2\. 识别参与交互过程的对象;
|
||||
|
||||
> 3.
|
||||
> 为每个对象设置生命线,即确定哪些对象存在于整个交互过程中,哪些对象在交互过程中被创建和撤销;
|
||||
|
||||
> 4.
|
||||
> 从引发这个交互过程的初始消息开始,在生命线之间从顶到下依次画出随后的各个消息;
|
||||
|
||||
> 5\. 如果需要表示消息的嵌套,或/和表示消息发生时的时间点,则采用FOC;
|
||||
|
||||
> 6\. 如果需要说明时间约束,则在消息旁边加上约束说明;
|
||||
|
||||
> 7\. 如果需要,可以为每个消息附上前置条件和后置条件。
|
||||
|
||||
**顺序图建模风格**
|
||||
|
||||
- 把注意力集中于关键的交互
|
||||
|
||||
- 对于参数,优先考虑使用参数名而不是参数类型。
|
||||
|
||||
- 不要对明显的返回值建模。
|
||||
|
||||
- 可以把返回值建模为方法调用的一部分。
|
||||
|
||||
**顺序图建立的问题**
|
||||
|
||||
- 顺序图中消息的循环发送,在消息名字前加循环条件
|
||||
|
||||
\*[ for all order lines]: message1()
|
||||
|
||||
- 顺序图中消息的条件发送,在消息名字前加条件子句; 使用文字说明;
|
||||
|
||||

|
||||
|
||||
- 顺序图中时间约束的表示,用constraint(约束)来表示。
|
||||
|
||||

|
||||
|
||||
- 顺序图中递归的表示,利用嵌套的FOC表示
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
序列图的详细描述
|
||||
|
||||
**生命线**
|
||||
|
||||
矩形框+虚线
|
||||
|
||||

|
||||
|
||||
**控制焦点(也叫作激活)**
|
||||
|
||||
> 对象生命周期,矩形表示对象处于激活状态。对象获得CPU控制权。完成工作后,释放控制权,对象处于空闲状态,成为去激活。
|
||||
|
||||
- 表示方法:在生命线上用细长的矩形框来表示。矩形框最上端表示处理的开始时点,矩形框的最下端表示处理的结束时点。
|
||||
|
||||
**消息**
|
||||
|
||||
用来描述对象之间所进行的通信。发送消息用实线箭头,返回消息用虚线箭头。
|
||||
|
||||
消息可以分为以下类别:
|
||||
|
||||
- **同步消息**:对象发送消息后,等到接收消息的对象执行完所有操作才能继续执行自己的操作。实心箭头。
|
||||
|
||||
- **异步消息**:发送消息的对象发送后,不用等待接受对象,继续执行自己的操作。空心箭头
|
||||
|
||||
- **返回消息**:接受消息的对象,返回数据并交回控制权,非发送消息的对象。对于同步消息的应答。可以省略。
|
||||
|
||||
- **创建消息**:《create》
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
- **销毁对象:--\>×**
|
||||
|
||||

|
||||
|
||||
- **发现消息**:发送方不明确的消息。
|
||||
|
||||

|
||||
|
||||
- **丢失消息**:接收方不明确的消息。
|
||||
|
||||

|
||||
|
||||
**递归调用:**从生命线下个自身通过折现进行消息发送的表示。
|
||||
|
||||

|
||||
|
||||
**消息的编号**
|
||||
|
||||
> 顺序编号、分层编号。顺序图中的消息可以省略消息番号。通信图中的消息必须明确消息番号来表示消息发送的先后顺序。
|
||||
|
||||
**顺序图的示例**
|
||||
|
||||

|
||||
|
||||
序列图的复杂结构
|
||||
|
||||
**高级概念:**
|
||||
|
||||

|
||||
|
||||
**组合区:**有多个区域组成,每个组合区有一个操作符。操作符表示对象执行方式,分支、并发或者循环。区域之间用虚线隔开。每个区域拥有一个监护条件和一个组合语句。监护条件写在方括号中。
|
||||
|
||||
**操作符:**操作符表示对象的执行方式。声明组合区的类型,写在组合区的左上角。
|
||||
|
||||
**分支结构**
|
||||
|
||||
alt和opt能够表示分支结构。alt表示多选一,opt表示判断单选一。
|
||||
|
||||
实例描述:上面区域的监护条件是x\<10,执行calculate(x)函数。下面区域的监护条件(else),执行put(x)
|
||||
|
||||
实例逻辑:\*\*\*\*\*
|
||||
|
||||
序列图:
|
||||
|
||||

|
||||
|
||||
**循环结构**
|
||||
|
||||
操作符:Loop(1,3)表示for(i = 1,i\<n;i++)
|
||||
|
||||
序列图:
|
||||
|
||||

|
||||
|
||||
**并发控制**
|
||||
|
||||
par组合区域中的多个区域种的操作是并行执行,没有先后顺序。
|
||||
|
||||
序列图:输入用户名和输入money是没有先婚后顺序。
|
||||
|
||||

|
||||
|
||||
**consider消息列表**
|
||||
|
||||
只有消息列表中的消息才能被执行。通过asser组合区进行判断。
|
||||
|
||||
序列图:
|
||||
|
||||

|
||||
|
||||
**ignore消息列表**
|
||||
|
||||
ignore消息列表中的信息被忽略。通过assert组合区进行判断。
|
||||
|
||||
序列图:(以后补充)
|
||||
|
||||
**break**
|
||||
|
||||
与循环操作配合使用,如果执行,则跳出循环语句,表示在给定条件满足时退出交互序列。
|
||||
|
||||
序列图:(以后补充)
|
||||
|
||||
**critical**
|
||||
|
||||
组合临界区,在临界区中的操作要么全被直行,要么都不执行。为了保持事务的原子性。
|
||||
|
||||
序列图:(以后补充)
|
||||
|
||||
**交互调用ref**
|
||||
|
||||
> 在一个交互的执行过程中去参照调用另外一个在它处定义好了的交互序列称为交互调用。
|
||||
|
||||
> 序列图:在框架的head部分用关键字“ref”进行标识,框架中央指明要调用的交互序列名称。方便合理组织顺序图中的元素,简化图中的交互调用关系,增强复杂交互关系的可读性和可维护性。
|
||||
|
||||

|
||||
BIN
UML建模/media/009a02aa8b59db9e6ba0fc8f72769fab.png
Normal file
|
After Width: | Height: | Size: 16 KiB |
BIN
UML建模/media/00adff0e60eea4a17e761e07368d7677.png
Normal file
|
After Width: | Height: | Size: 6.7 KiB |
BIN
UML建模/media/01e03214f015842a683c0746d155acce.gif
Normal file
|
After Width: | Height: | Size: 3.0 KiB |
BIN
UML建模/media/0228649fa7b573082e6ac1ffe36506c3.png
Normal file
|
After Width: | Height: | Size: 10 KiB |
BIN
UML建模/media/02dc6c31a791e8a2808757f1d1fb59a7.png
Normal file
|
After Width: | Height: | Size: 2.1 KiB |
BIN
UML建模/media/04fc607da03f5e238b786ffef721e16b.gif
Normal file
|
After Width: | Height: | Size: 66 KiB |
BIN
UML建模/media/05a46d19516799aadd88d5b0b81c5d91.gif
Normal file
|
After Width: | Height: | Size: 8.6 KiB |
BIN
UML建模/media/06ad57633dd34faa8b7ae54e40a51ead.png
Normal file
|
After Width: | Height: | Size: 6.7 KiB |
BIN
UML建模/media/089394f391e284710c98aa77bec97451.png
Normal file
|
After Width: | Height: | Size: 3.6 KiB |
BIN
UML建模/media/08c3ab7ee9c9ba79a70b401e21e66ab2.png
Normal file
|
After Width: | Height: | Size: 5.2 KiB |
BIN
UML建模/media/08d35b441ac05f71ead4dd16ec59d766.png
Normal file
|
After Width: | Height: | Size: 6.5 KiB |
BIN
UML建模/media/09bea9bd5c6eb8e6e61ae8e3a12385e0.png
Normal file
|
After Width: | Height: | Size: 261 B |
BIN
UML建模/media/0b444ee3bcbd0c0f119345a137e88587.png
Normal file
|
After Width: | Height: | Size: 2.3 KiB |
BIN
UML建模/media/0de89a168a270d0ddd756a698356624c.png
Normal file
|
After Width: | Height: | Size: 2.7 KiB |
BIN
UML建模/media/0f6d7f88e8cd4eac4039cf2935373c89.png
Normal file
|
After Width: | Height: | Size: 7.2 KiB |
BIN
UML建模/media/0faf0b794c5211197e773b0017324c41.png
Normal file
|
After Width: | Height: | Size: 6.8 KiB |
BIN
UML建模/media/119be8639192e86fc24fecc2587db2d3.png
Normal file
|
After Width: | Height: | Size: 291 KiB |
BIN
UML建模/media/1286369b775185a15174dc63ed297031.gif
Normal file
|
After Width: | Height: | Size: 114 B |
BIN
UML建模/media/12f54accea9a0639f898e8365a94463b.png
Normal file
|
After Width: | Height: | Size: 12 KiB |
BIN
UML建模/media/1473846f9f2575ef53bfc338f69131e7.png
Normal file
|
After Width: | Height: | Size: 5.1 KiB |
BIN
UML建模/media/150c52602095d9e9ec86dc9b543d4e86.gif
Normal file
|
After Width: | Height: | Size: 6.4 KiB |
BIN
UML建模/media/15c97169d595fd9db3fd65daff00a6d0.png
Normal file
|
After Width: | Height: | Size: 7.0 KiB |
BIN
UML建模/media/16848a47e139809f92ffa8b002dc457a.png
Normal file
|
After Width: | Height: | Size: 7.2 KiB |
BIN
UML建模/media/19e0aa64d369f207d6ae7f8d6e2a3bc8.jpeg
Normal file
|
After Width: | Height: | Size: 802 B |
BIN
UML建模/media/1b1985740c8e6c1690c11177de137226.gif
Normal file
|
After Width: | Height: | Size: 6.1 KiB |
BIN
UML建模/media/1c5b60dd4fbc67fb63d92cc9e5aa40d3.png
Normal file
|
After Width: | Height: | Size: 9.7 KiB |
BIN
UML建模/media/1d1383b8c56ee1e43f1543bc1a98cd2b.jpeg
Normal file
|
After Width: | Height: | Size: 2.6 KiB |
BIN
UML建模/media/1d48fd24a28d5d1e5cb1ae11eb86097a.png
Normal file
|
After Width: | Height: | Size: 10 KiB |
BIN
UML建模/media/1e0496771a12fb2c442fe99af3aae6ef.png
Normal file
|
After Width: | Height: | Size: 11 KiB |
BIN
UML建模/media/1fd844719db1af91d5c8c923ee4d7f87.png
Normal file
|
After Width: | Height: | Size: 42 KiB |
BIN
UML建模/media/20b5459381f45759a066942d042f58fe.gif
Normal file
|
After Width: | Height: | Size: 7.3 KiB |
BIN
UML建模/media/21482dbb5b07c0004c0b990bf3ccfc58.png
Normal file
|
After Width: | Height: | Size: 15 KiB |
BIN
UML建模/media/2244115842bb55161e5ea87f00282323.png
Normal file
|
After Width: | Height: | Size: 25 KiB |
BIN
UML建模/media/22f703054a8c70bd3010f3274c67a7fe.png
Normal file
|
After Width: | Height: | Size: 22 KiB |
BIN
UML建模/media/22fed633bfc79a97c0edd15eede9f10c.png
Normal file
|
After Width: | Height: | Size: 36 KiB |
BIN
UML建模/media/23e1149fb3a4a002bcacfdc307355052.png
Normal file
|
After Width: | Height: | Size: 80 KiB |
BIN
UML建模/media/24a8a05fe0c6a00d01b45c415cfc3a87.png
Normal file
|
After Width: | Height: | Size: 23 KiB |
BIN
UML建模/media/25f130cb8e9cfccb2c55edbde70a32b9.png
Normal file
|
After Width: | Height: | Size: 7.8 KiB |
BIN
UML建模/media/269d638221d98b1373a09c3685dac87c.png
Normal file
|
After Width: | Height: | Size: 2.9 KiB |
BIN
UML建模/media/27a02a8f906aad6d92e9374bfbbb0666.jpeg
Normal file
|
After Width: | Height: | Size: 3.8 KiB |
BIN
UML建模/media/2973c690d538aee2d892a0bca402538b.png
Normal file
|
After Width: | Height: | Size: 62 KiB |
BIN
UML建模/media/29d5c823c0c961fc6b0abdea4dbfdc22.png
Normal file
|
After Width: | Height: | Size: 48 KiB |
BIN
UML建模/media/2c2a586dd7672a8067f66de491013ac6.png
Normal file
|
After Width: | Height: | Size: 97 KiB |
BIN
UML建模/media/2c7b1a7320383287a5c048629598fe38.jpeg
Normal file
|
After Width: | Height: | Size: 1.3 KiB |
BIN
UML建模/media/2fd9ff33db2f848bde9cd380c8b4b2b6.png
Normal file
|
After Width: | Height: | Size: 4.9 KiB |
BIN
UML建模/media/302afee56df15ae56105661cc15053f8.png
Normal file
|
After Width: | Height: | Size: 3.3 KiB |
BIN
UML建模/media/313c34f6c69e0ff536cc30b4e4871228.png
Normal file
|
After Width: | Height: | Size: 623 B |
BIN
UML建模/media/32de30301698a6ef75b45884718f8c45.jpeg
Normal file
|
After Width: | Height: | Size: 7.1 KiB |
BIN
UML建模/media/333038cb99aaef5ca8a753f22f5cbe1b.png
Normal file
|
After Width: | Height: | Size: 16 KiB |
BIN
UML建模/media/33795c65eabdb9238dc701ac3744f671.png
Normal file
|
After Width: | Height: | Size: 60 KiB |
BIN
UML建模/media/33f213159b0675d8095e4436e500ebe3.png
Normal file
|
After Width: | Height: | Size: 45 KiB |
BIN
UML建模/media/340d5ea484809118899384a5bfd9207a.png
Normal file
|
After Width: | Height: | Size: 2.4 KiB |
BIN
UML建模/media/362272a90628e264421d41fb89d4ecf6.png
Normal file
|
After Width: | Height: | Size: 9.8 KiB |
BIN
UML建模/media/36cc04042c53343343986878d4d60868.png
Normal file
|
After Width: | Height: | Size: 2.0 KiB |
BIN
UML建模/media/36f0aaec2025d0d0869969a17f7e5c0f.png
Normal file
|
After Width: | Height: | Size: 2.8 KiB |
BIN
UML建模/media/37a4d3aaa7b31f9aeb236d5347999005.png
Normal file
|
After Width: | Height: | Size: 3.5 KiB |
BIN
UML建模/media/3934bfda9de5f29d1bded35127d178eb.gif
Normal file
|
After Width: | Height: | Size: 18 KiB |
BIN
UML建模/media/39b63187fcff998962ad189d633965bc.png
Normal file
|
After Width: | Height: | Size: 7.2 KiB |
BIN
UML建模/media/3f9a978462eedaf6238623d983b1bbe2.png
Normal file
|
After Width: | Height: | Size: 76 KiB |
BIN
UML建模/media/45046eb80870370faf2544ca04ec0da7.gif
Normal file
|
After Width: | Height: | Size: 2.2 KiB |
BIN
UML建模/media/4538a8aa7a813f18b99f919373c1efdc.png
Normal file
|
After Width: | Height: | Size: 5.7 KiB |
BIN
UML建模/media/46c572e81dce35c7f95bd04e57ba91cf.gif
Normal file
|
After Width: | Height: | Size: 6.2 KiB |
BIN
UML建模/media/470e16d83ca676533c37c5270adadb5d.png
Normal file
|
After Width: | Height: | Size: 27 KiB |
BIN
UML建模/media/48e578455910e09cf54364772cd63819.png
Normal file
|
After Width: | Height: | Size: 78 KiB |
BIN
UML建模/media/49704876b771302b8bf64ed1ec48c910.png
Normal file
|
After Width: | Height: | Size: 11 KiB |
BIN
UML建模/media/49d77eac7a5fbcd2e61c7beba5335c4d.png
Normal file
|
After Width: | Height: | Size: 9.3 KiB |
BIN
UML建模/media/4d4ec73102e34a31c1f6626c04beed22.png
Normal file
|
After Width: | Height: | Size: 527 B |
BIN
UML建模/media/4ff2de8fb2c5bc5b9f1b7f9e14b6d153.png
Normal file
|
After Width: | Height: | Size: 321 B |
BIN
UML建模/media/518e6c41b5241ede6987c65aafbe3153.png
Normal file
|
After Width: | Height: | Size: 29 KiB |
BIN
UML建模/media/51bfd4609744021d927ee8ceec4ce853.png
Normal file
|
After Width: | Height: | Size: 27 KiB |
BIN
UML建模/media/5267a9e026e1048d0aaf585a1bf985d9.png
Normal file
|
After Width: | Height: | Size: 18 KiB |
BIN
UML建模/media/533a342ffe6e44fe144a2a8998b9379c.png
Normal file
|
After Width: | Height: | Size: 35 KiB |
BIN
UML建模/media/54527425badb144ba7ed210f5ecf9211.png
Normal file
|
After Width: | Height: | Size: 17 KiB |
BIN
UML建模/media/5475679fe2bf7e5981e324069ef38eee.png
Normal file
|
After Width: | Height: | Size: 21 KiB |
BIN
UML建模/media/54ab29edc35a027fb6c7af4d3f520a94.png
Normal file
|
After Width: | Height: | Size: 329 B |
BIN
UML建模/media/55595b991f3bebe5539286ab57335a86.png
Normal file
|
After Width: | Height: | Size: 50 KiB |
BIN
UML建模/media/57563308b2c4a4fd35c50912278b1a2f.png
Normal file
|
After Width: | Height: | Size: 25 KiB |
BIN
UML建模/media/590174b80ff629c22983c5c7d68847d2.png
Normal file
|
After Width: | Height: | Size: 1.9 KiB |
BIN
UML建模/media/5977f71950072b1d3976134c01c6b411.png
Normal file
|
After Width: | Height: | Size: 7.6 KiB |
BIN
UML建模/media/5b5ef29163f2f535aeb31650dbe0e7d9.png
Normal file
|
After Width: | Height: | Size: 102 KiB |
BIN
UML建模/media/5c3f7c5f70c83eb6ee29811335dfd379.png
Normal file
|
After Width: | Height: | Size: 2.3 KiB |
BIN
UML建模/media/5ed45ef28a6e410a2d4f96ed07581c42.png
Normal file
|
After Width: | Height: | Size: 14 KiB |
BIN
UML建模/media/5fb9f238d15eb2effb360c136ea56c7d.png
Normal file
|
After Width: | Height: | Size: 12 KiB |
BIN
UML建模/media/60f1ee0b2bd12852382d97a50d3e0bd9.png
Normal file
|
After Width: | Height: | Size: 21 KiB |
BIN
UML建模/media/637ca121515a9f9bde80486aa7b1f44e.png
Normal file
|
After Width: | Height: | Size: 1.3 KiB |
BIN
UML建模/media/650e5c74e0db2a53c5045abc1be72a80.png
Normal file
|
After Width: | Height: | Size: 27 KiB |