UML建模
背景
对UML建模有一个系统的学习记录。
UML概念
UML通过图形化的表示机制从多个侧面对系统的分析和设计模型进行刻画。
为什么要用UML图？
通过使用UML使得在软件开发之前， 对整个软件设计有更好的可读性，可理解性，从而降低开发风险。同时，也能方便各个开发人员之间的交流。
UML提供了极富表达能力的建模语言，可以让软件开发过程中的不同人员分别得到自己感兴趣的信息。
Page-Jones 在《Fundamental Object-Oriented Design in UML》 一书中总结了UML的主要目的，如下：
- 为用户提供现成的、有表现力的可视化建模语言，以便他们开发和交换有意义的模型。
- 为核心概念提供可扩展性 (Extensibility) 和特殊化 (Specialization) 机制。
- 独立于特定的编程语言和开发过程。
- 为了解建模语言提供一个正式的基础。
- 鼓励面向对象工具市场的发展。
- 支持更高层次的开发概念，如协作，框架，模式和组件。
- 整合最佳的工作方法 (Best Practices)。
UML图分类
共定义了10种视图，并将其分为如下4类。
用例图
概念及重要性
用例是代表系统中各相关人员之间就系统的行为所达成的默契。
软件的开发过程可以分为需求分析、设计、实现等阶段。
在需求分析阶段，用例是分析人员与客户沟通的工具和项目规模估算的依据；
在设计阶段，用例是系统功能设计的主要输入；
在实现阶段，用例是检测类行为正确性的文档。
因此，面向对象的软件开发过程是用例驱动的。
用例分析可以支持领域建模，以确保定义正确的需求，是保证OO软件开发成功的基础。
但要在具体的项目中灵活使用用例来捕获用户的需求并不是一件容易的事情，往往需要用户的经验、沟通能力、丰富的领域知识等。
本质上，用例分析是一种功能分解（functional decomposition）的技术，并未使用到面向对象思想。但用例是UML的重要部分，确定一个系统的用例才是开发OO系统的第一步，用例分析这步做得好，接着的交互图分析、类图分析等才有可能做得好，整个系统的开发才能顺利进行。
用例图示例
如上所示的UML用例图反映了顾客（角色，英语：actor）在餐馆（系统，英语：system）中的交互
（1）参与者
角色（actor)是指系统以外的、需要使用系统或与系统交互的东西，包括人、设备、外部系统等。
参与者其实是一个版型化的类，其版型是:
1 | <<Actor>> |
（2）用例间的关系
用例与参与者有关联(association)关系
用例之间也存在着：泛化（generalization）关系、包含（include）关系、扩展（extend）关系等
包含关系描述的是一个用例需要某种功能，而该功能被另外一个用例定义，那么在用例的执行过程中，就可以调用已经定义好的用例。
也可以说，其中一个用例的行为包含了另一个用例的行为。包含关系是依赖关系的版型，即包含关系是比较特殊的依赖关系。
版型符号：
1 | <<include>> |
用一个用例（可选）扩展另一个用例（基本例）的功能，将一些常规的动作放在一个基本用例中，将可选的或只在特定条件下才执行的动作放在它的扩展用例中。
基本用例必须声明若干“扩展点”，而扩展用例只能在这些扩展点上增加新的行为和含义。扩展用例有更多的规则限制。
版型符号：
1 | <<extend>> |
（3）用例的描述
用例的描述是用例的核心部分，用例采用自然语言描述参与者与系统进行交互时双方的行为。
（4）系统边界system scope
系统边界system scope：确定系统的范围，边界是一个方框，用例在边界内，参与者在边界外；
关联关键词
UML (Unified Model Language) 统一建模语言
OMG (Object Management Group)
RTF (Revision Task Forces) 修订任务组
XMI (XML metadata Interchange)
DTD (Document Type Definition)
IDL (Interface Definition Language)
Object-Oriented 面向对象
Use Case 用例
domain modeling 领域建模
right requirement 正确的需求
extension use case 扩展用例
对UML的评价与展望
（1） UML已经取得重要成功，它已经成为软件工业中占支配地位的建模语言。并在许多领域的软件开发中得到应用。
（2） UML还存在着许多的问题，自它产生之日起就从未离开过匹配：用户和教授抱怨它内容庞大；学者认为它缺少一个精炼的核心和定义良好的外围，有些语义带着二义性；建模实践者认为它缺少支持自己领域建模要求的机制；工具开发商则因为规范本身的不确定性而产生理解上的偏差，它们对UML的自行诠释可能会误导用户。
（3） UML的关键问题是过于庞大和复杂，以及在语言体系结构、语义等方面存在理论缺陷。产生这些问题的一个重要原因是，在形成规范的过程中不得不照顾多种方法流派的观点和多家公司的利益。