面向对象问题解决的核心是构建一个模型。该模型从其通常复杂的现实世界中抽象出基本问题的基本细节。几个建模工具被包裹在UML ™ 的标题下,代表统一建模语言™。本课程的目的是介绍UML的重要亮点。
UML的中心是我们在这里描述的九种建模图。
- 用例图
- 类图
- 对象图
- 序列图
- 协作图
- 状态图
- 活动图
- 组件图
- 部署图
本课程的某些部分包含具有更详细信息的页面的链接。每个部分都有简短的问题。使用它们来测试您对本节主题的理解。
为什么UML很重要?
从建造业的角度来看,我们来看看这个问题。建筑师设计建筑。建筑商使用设计来创建建筑物。建筑越复杂,建筑师和建筑师之间的沟通越重要。蓝图是建筑师和建筑商必须学习的标准图形语言,作为其交易的一部分。
写作软件与建筑物不同。底层系统越复杂,每个参与创建和部署软件的人之间的沟通就越重要。在过去十年中,UML已经成为分析师,设计师和程序员的软件蓝图语言。它现在是软件贸易的一部分。UML让所有人从业务分析师到设计人员到程序员一个常见的词汇来谈论软件设计。
UML适用于面向对象的问题解决。任何有兴趣学习UML的人都必须熟悉面向对象问题解决的基本原则 - 这一切都是从构建模型开始的。甲模型是根本问题的抽象。该领域是问题来自的实际世界。
模型由通过发送彼此消息进行交互的对象组成。把一个对象看成是“活着的”。对象有他们知道的东西(属性)和他们可以做的事情(行为或操作)。对象属性的值决定其状态。
类是对象的“蓝图”。类将属性(数据)和行为(方法或函数)包装到单个不同的实体中。对象是实例的类。
用例图
用例图从外部观察者的角度描述系统的作用。重点是什么样的系统呢,而不是如何。
用例图与情景密切相关。一个情景是当某人与系统进行交互时会发生的情况的示例。这是一个诊所的场景。
“病人呼叫诊所预约一年一次的检查,接待员找到预约书中最近的空时间段,并安排该时间段的约会。
一个 用例是单个任务或目标的场景概要。一个演员是谁或什么启动与该任务有关的事件。演员只是人或物体的角色。下面的图片是医疗诊所的预约用例。演员是病人。actor和用例之间的连接是通信关联(简称为通信)。
演员是棒人物。用例是椭圆形。通信是将演员与用例联系起来的线条。
用例图是一组actor,用例和通信。我们已经将“约会”作为四个演员和四个用例的图表的一部分。请注意,单个用例可以有多个actor。
用例图在三个方面有所帮助。
- 确定特征(要求)。随着系统的分析和设计的形成,新的用例经常会产生新的需求。
- 与客户沟通。他们的简明易懂使得用例图成为开发人员与客户沟通的好方法。
- 生成测试用例。用例情景的收集可能会为这些场景提供一套测试用例。
类图
类图通过显示系统的类和它们之间的关系来概述系统。类图是静态的 - 它们显示出什么交互,但不会发生什么交互。
下面的类图从零售目录模拟客户订单。中央阶级是秩序。与此相关的是客户进行购买和付款。一个付款是三种:现金,检查,或信用。该订单包含OrderDetails(行项目),每个都有其关联的项目。
UML类符号是一个矩形,分为三个部分:类名,属性和操作。抽象类的名称,如Payment,以斜体表示。类之间的关系是连接链接。
我们的类图有三种关系。
- 关联 - 两个类的实例之间的关系。如果一个类的实例必须知道另一个类才能执行其工作,则有两个类之间的关联。在图中,关联是连接两个类的链接。
- 聚合 - 一个类属于一个集合的关联。聚合具有指向包含整体的部分的钻石端。在我们的图中, Order有一个OrderDetails的集合。
- 泛化 - 一个继承链接,表示一个类是另一个类的超类。泛化有一个指向超类的三角形。付款是现金,支票和信用证的超类。
协会有两方面。结束可能有一个角色名称来澄清协会的性质。例如, OrderDetail是每个订单的一个订单项。
一个 关联上的导航箭头显示可以遍历或查询关联的方向。一个的OrderDetail可以查询有关其项目周围,而不是其他方式。箭头还可以让您知道谁拥有该协会的实施; 在这种情况下, OrderDetail有一个项目。没有导航箭头的协会是双向的。
该 关联端的多重性是与另一端的单个实例相关联的类的可能实例的数量。倍数是单个数字或数字范围。在我们的示例中,每个订单只能有一个客户,但客户可以有任意数量的订单。
这个表给出了最常见的多重性。
多重 | 含义 |
---|---|
0..1 | 零或一个实例。符号n。。m表示n到m个实例。 |
0 .. * 或 * | 对实例数量没有限制(包括无)。 |
1 | 正是一个例子 |
1 .. * | 至少一个实例 |
每个类图都有类,关联和多重性。导航和角色是放置在图中以提供清晰度的可选项。
软件包和对象图
为了简化复杂的类图,您可以将类分组 包。一个包是逻辑上相关的UML元素的集合。下面的图是一个业务模型,其中类被分组成包。
软件包显示为顶部小标签的矩形。包名称在标签上或矩形内。虚线箭头是依赖关系。一个包装取决于另一个包装是否可能会在第一个更改中强制更改。
对象图显示实例而不是类。它们用于解释具有复杂关系的小件,特别是递归关系。
这个小类图显示,大学部可以包含很多其他部门。
下面的对象图实例化了类图,用一个具体的例子代替了它。
对象图中的每个矩形对应于单个实例。实例名称在UML图中加下划线。只要图意义仍然清晰,可以从对象图中省略类或实例名称。
序列图
类和对象图是静态模型视图。 互动图是动态的。他们描述对象如何协作。
一个 序列图是一个交互图,详细介绍了如何执行操作 - 发送什么消息以及什么时间。序列图按时间组织。随着时间的推移,您在页面下滑。根据参与消息序列的时间,从左到右列出了操作中涉及的对象。
以下是进行酒店预订的序列图。启动消息序列的对象是一个预留窗口。
的预约窗口发送makeReservation()消息到HotelChain。所述HotelChain然后发送makeReservation()消息到饭店。如果酒店有空房,那么预订和确认。
每条垂直虚线都是a 生命线,表示对象存在的时间。每个箭头都是一个消息调用。箭头从发送者到顶部接收机生命线上消息的激活条。激活条表示消息的执行持续时间。
在我们的图表中,酒店发出一个自我呼叫以确定房间是否可用。如果是这样,酒店将创建一个预订和确认。自我呼叫上的星号意味着迭代(以确保在酒店的每一天的可用空间)。方括号[]中的表达式是一个条件。
该图有一个澄清 注意,这是一个狗耳朵的矩形内的文本。Notes可以放在任何一种UML图中。
协作图
协作图也是交互图。它们传达与序列图相同的信息,但它们专注于对象角色,而不是发送消息的时间。在序列图中,对象角色是顶点,消息是连接链接。
对象角色矩形用类或对象名称(或两者)标记。类名前面是冒号(:)。
协作图中的每个消息都有一个 序列号。顶级消息编号为1.相同级别的消息(在相同呼叫期间发送)具有相同的十进制前缀,而后缀为1,2等,根据发生的时间。
状态图
对象有行为和状态。对象的状态取决于当前的活动或状态。一个状态图显示了对象的可能状态和导致状态改变的转换。
我们的示例图模拟了网上银行系统的登录部分。登录包括输入有效的社会保险号码和个人身份证号码,然后提交信息进行验证。
登录可以分为四个不重叠的状态:获取SSN,获取PIN,验证和拒绝。从每个国家来的都是一套完整的确定后续状态的转换。
国家是圆角矩形。过渡是从一个国家到另一个国家的箭头。触发过渡的事件或条件写在箭头旁边。我们的图有两个自我转换,一个是获取SSN,另一个在获取PIN。
初始状态(黑色圆圈)是一个虚拟的开始动作。最终状态也是终止动作的虚拟状态。
由于事件或条件而发生的动作以表单/动作表示。当处于“ 验证”状态时,对象不会等待外部事件触发转换。相反,它执行一个活动。该活动的结果决定了其后续状态。
活动图
一个 活动图本质上是一个花哨的流程图。活动图和状态图与之相关。虽然状态图将焦点集中在正在进行过程(或作为对象的进程)上的对象上,活动图集中在单个进程中涉及的活动流。活动图显示了这些活动如何依赖于彼此。
对于我们的例子,我们使用了以下过程。
“通过ATM从银行帐户提款”。
活动的三个课程(人员等)是客户,ATM和银行。该过程从顶部的黑色起始圆开始,并在底部的同心白/黑停止圆处结束。活动是圆角矩形。
活动图可以分为对象 决定哪个对象负责哪个活动的泳道。单身转换出来的每一项活动,将其连接到下一个活动。
过渡可能 分支到两个或多个相互排斥的转换。保护表达式(在 []内))标记从分支出来的转换。一个分支及其后续合并标记分支的末端在图中显示为空心钻石。
过渡可能 叉进入两个或更多的并行活动。叉和随后从叉子出来的螺纹的连接在图中显示为实心条。
组件和部署图
甲组件是一个代码模块。组件图是类图的物理类型。部署图显示了软件和硬件的物理配置。
以下部署图显示了涉及房地产交易的软件和硬件组件之间的关系。
物理硬件由节点组成。每个组件都属于一个节点。组件显示为在左上角有两个选项卡的矩形。