uml

前言 用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示一个外部用户能够观察到的系统功能模型图。用例图多用于静态建模阶段（主要是业务建模和需求建模），帮助开发团队以一种可视化的方式理解系统的功能需求。下面将从各个部分来分析和理解用例图。 参与者（Actor） 在系统外部与系统直接交互的人或事物；需要注意以下两点： 参与者是角色而不是具体的人，它代表了参与者在与系统打交道的过程中所扮演的角色。所以在系统的实际运作中，一个实际用户可能对应系统的多个参与者。不同的用户也可以只对应于一个参与者，从而代表同一参与者的不同实例。 参与者作为外部用户（而不是内部）与系统发生交互作用，是它的主要特征。 在UML中，参与者使用如图所示的一个小人表示： 用例（Use Case） 系统外部可见的一个系统功能单元。系统的功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。用椭圆表示，椭圆中的文字简述系统的功能： 子系统（Subsystem） 用来展示系统的一部分功能，这部分功能联系紧密。 关系（Relationship） 用例图中涉及的关系有： 关联 泛化 包含 扩展 关联（Association） 表示参与者与用例之间的交互，通信途径，任何一方都可发送或接受消息。 箭头指向：指向消息接收方。 泛化（Inheritance） 在编程中，泛化关系是一种很重要的关系

来自: IBM Rational Edge 　 现在是二月，而且到如今你或许已经读到、或听到人们谈论UML 2.0 —— 包括若干进步的 UML 的新规范，所做的变化。考虑到新规范的重要性，我们也正在修改这个文章系列的基础，把我们的注意力从 OMG 的 UML 1.4 规范，转移到 OMG 的已采纳 UML 2.0草案规范（又名 UML 2）。我不喜欢在一系列文章的中间，把重点从 1.4 变为 2.0 ，但是 UML 2.0 草案规范是前进的重要一步，我感觉需要扩充文字。 由于一些理由，OMG 改良了 UML 。主要的理由是，他们希望 UML 模型能够表达模型驱动 架构 （MDA），这意味着 UML 必须支持更多的模型驱动的符号。同时， UML 1.x 符号集合有时难以适用于较大的应用程序。此外,为了要使图变成更容易阅读，需要改良符号元件。（举例来说，UML 1.x 的模型逻辑流程太复杂，有时不可能完成。对UML 2 中的序列图的符号集合的改变，已经在序列化逻辑建模方面取得巨大的进步)。 注意我上面所述的文字：“已采纳UML2.0草案规范。”确实，规范仍然处于草案状态，但是关键 是草案规范已经被 OMG 采用，OMG是一个直到新标准相当可靠，才会采用它们的组织。 在 UML 2 完全地被采用之前，规范将会有一些修改，但是这些改变应该是极小的。主要的改变将会是在 UML 的内部 ——

0. 前言 相信大家在学习UML类图的时候，最大的困难可能来自两个方面： 类图中各种关系的区别； 多种关系的符号记忆容易混淆； 本着"Do one thing and do it well."的原则，本文不介绍UML类图中各种关系的区别。而重在介绍UML类图的符号理论，以及利用该理论帮助大家更好的记忆。 1. 准备 在开始阅读本文之前，你需要了解的知识有： UML类图的概念； UML类图有几种关系； 各种关系的强弱； 2. UML类图符号理论基础 UML类图主要有以下几种关系： 泛化 Generalization 实现 Realization 组合 Composition 聚合 Aggregation 关联 Association 依赖 Dependency 以上这六种关系的强弱是： 泛化 > 实现 > 组合 > 聚合 > 关联 > 依赖 这六种关系，每一种都对应着一个符号。加起来就有六种符号，要想在较短的时间内记住这六种符号而且不产生混淆是一件不太容易的事情。那么该如何更有效的来记忆这些符号？ 接下来我们将首先认识一下关于符号的基础知识。 2.1 类图符号基础知识 首先我们从整体上来认识一下表达类图关系的符号，类图关系的符号由三部分组成：箭头、线条和箭尾。 箭头形状有两种，分别为箭头和三角箭头。 线条形状有两种，分别为实线和虚线。 箭尾形状有三种，分别为点、空心菱形和实心菱形。