UML 简要介绍

概述：

    全称：Unified Modeling Language (UML)又称统一建模语言或标准建模语言。

    UML可以通过称为4+1视图模型的软件系统结构来了解。这个模型的UML版本如图1.1所示。

   

                                   图1.1   4+1模型视图

     用例视图（use case view）：定义了系统的外部行为，是最终用户、分析人员和测试人员所关心的。该视图定义了系统的需求，因此约束了描述系统设计和构造的某些方面的所有其他视图。这真是用例视图具有中心作用的原因，也是通常所说的用例驱动开发过程。

     设计视图（design vies）：描述的是支持用例视图中规定的功能需求的逻辑结构。它由程序构件的定义，主要是类、类所持有的数据、类的行为以及类之间交互的说明组成。包含在这个视图中的信息是程序员特别关心的，因为如何实现系统功能的细节都在这个视图中描述。

     实现视图（implementation view）：描述构造系统的物理构件。这个构件不同于设计视图中描述的逻辑构件，这些构件包含如何执行文件、代码库和数据库等内容。这个视图中包含的信息与配置管理和系统集成这类活动有关。

     进程视图（process view）：涉及系统中并发性的问题。

     部署视图（deployment view）： 描述物理构件如何在系统运行的实际环境（如计算机网络）中分布。这个视图和进程视图处理的是系统的非功能性需求，例如容错性和性能等问题。进程视图和部署视图在UML中相对地未充分开发，尤其是与设计视图相比。在设计视图中包含了大量非正式地被当作是与设计有关的符号。

    UML定义了用例图、类图、对象图、状态图、活动图、顺序图、协作图、构件图、部署图等9种图。

    UML 9种图与视图之间的关系，如下表1.1

   

                                                            表1.1   UML的图的类型                                      

     系统设计中使用的模型呈现的是系统的一个抽象视图，而实现增加了足够的袭击使这些模型可以执行。如果设计文档和源代码一致，这就意味着这些模型是表示了代码结构和特性的一个抽象视图，这种关系如图1.2所示。

   

                                                                                            图1.2模型和代码间的关系。

UML 9 种 图例 ：

1.类图（Class diagram）：

   定义：显示系统中的类和包，提供系统构件及其相互关系。静态结构建模。

   举例如下图：

   

                                                                                                         图1.1   基本类图

                                                                   图1.2 复杂类图

2.用例图（Use-case diagram）

用例图从用户的角度描述系统功能的使用者和主要的系统操作流程。显示用例与参与者及其相互关系。系统功能建模

                                                               图2.1  简单的用例图

                        

3.对象图（Object diagram）

    定义：是表示对象和对象之间连接的图。

                                                           图3.1    对象实例图

4.状态图（Statechart diagram）

显示系统中类的对象所有可能的状态以及事件发生时状态的转换条件。动态行为建模

                                  图4.1 CD播放机的一个简单的状态图

                            图4.2   CD播放机的一个完整的状态图

                                                      图4.3   售票机的完整状态图

                                                    图4.4    简单的用户取钱的状态图。

                             

5.活动图（Activity diagram）

描述满足用例要求所需进行的活动以及活动间的关系的图。动态行为建模

6.顺序图（Sequence diagram）

按时间顺序显示用例中特定情形的操作流程。动态行为建模

                                           图6.1     简单的顺序图

  

                                                       图6.2    顺序图中有条件的消息

                                       图6.3          顺序图中的可选消息

                                      图6.4     顺序图中的递归调用

7.协作图（Collaboration diagram）

从对象组织结构的角度显示用例中特定情形的操作流程。动态行为建模

                                            图7.1   简单的协作图

                                            图7.2   协作图中有条件的消息

                                           图 7.3   协作图中的递归调用

8.构件图（Component diagram）

描述代码构件的物理结构以及构件之间的依赖关系。组件图有助于分析和理解组件之间的影响程度。静态结构建模

                                          图8.1    A在其中使用B

                                       图8.2    依赖关系图

9.部署图（Deployment diagram）

定义：描述系统中的物理结构。静态结构建模

附录：软件开发过程：

瀑布模型：

     瀑布模型代表了一种直观的、切合实际的、通用的工程方法在软件工程中的应用。它强调在执行活动之前先进设计的重要性，并因此提供了一种有价值的平衡，平衡软件开发中对总体体系结构或者程序结构不做任何考虑就开始编码的普遍倾向。与此相关，它建议一种自顶向下的方法，由此一个系统最初在一个高的抽象层次上描述，随着开发的继续增加更多的细节。最后，至少在理论上，它提供了控制软件过程的一种有力的管理工具：使用该模型，能够给予项目一个清晰的结构，在每一个阶段的最后有一个里程碑，标志着该阶段的完整文档的产生并为下一阶段最好了准备。

    然而，实际上，瀑布模型的应用并没有真正做到它所承诺的那样，提供一种组织软件项目的方法，使得项目将会是可控的，按时产生在预算内交付功能正确的系统。造成这种失败的两个主要原因是，该模型管理项目中的涉及的风险的方式和模型中对系统需求的处理。

 

    演化模型

       作为对瀑布模型过于严格的结构的认识的回应，提出了许多建议，认为软件应该以一种更“演化”的方式开发。典型地，这意味着开发应该从产生一个实现，也许是模拟完整系统的一小部分核心功能的原型系统开始。

      然后，可以和用户讨论这个原型，用户也能够获得试用系统的第一手经验。于是，来自用户的反馈将指导后续的开发，随着在每一个给定阶段小规模的功能性增量的增加以及与用户反复商讨，原型将演化为一个完整的系统。

      演化方法希望通过用户参与开发过程，避免产生在项目结束时才发现开发的系统不是用户所需要的问题，从而克服了瀑布模型的一个缺点。同样的，强调开发一系列可用的原型意味着演化中的系统从项目的早期阶段就已经被测试，使得在项目早期确定问题成为可能，并将风险分散到了生命周期的各个部分。

      演化模型的缺点在很大程度上与进行中的项目管理及其可预测性有关。由于模型的特性，很难看出项目经理如何能够明智地规划一个项目，或者进行项目的工作分配。此外，该模型也没有保证演化过程上总是会向着一个稳定的系统汇聚，而且没有如果事实上未能如此汇聚时的应对策略。最后演化过程也不能保证，所形成的系统的整个体系结构将会使维护活动能够有效的进行，比如修复错误和实现系统的变更。

    螺旋模型

   

     螺旋模型脱离了瀑布模型提出的线性结构，而将软件开发描绘为以一系列不断迭代进展的过程，重复地修正相同的阶段和活动。

          螺旋模型主要的创新在于，它提出了开发应当被作为整个的一系列迭代来组织，每次迭代包含对项目风险的明确考虑，并该次迭代中所做的工作的意图就是要解决所认识到的最大的风险。根据项目的种类，风险可能各种各样，并且也不局限于可能的技术问题，类似进度安排和预算控制等因素也是风险的重要来源。

          因此可以得出结论，螺旋模型没有像瀑布模型那样以简单的方式提出一个单程的确定的过程模型，而是提出项目计划编制的进行应该贯穿于项目的生命期，而且项目经理必须准备好按照进度和发现的风险随时修改计划。

          根据影响给定项目的风险的种类，在某些情况下螺旋模型可能看来与其他过程模型类似。例如，如果对一个特殊的项目，与需求获取相关的风险较低，但项目管理被认为是较大风险，那么应用于该项目的螺旋模型可能和瀑布模型非常接近。然而，如果最大的风险在于开发一个复杂的新的用户界面，螺旋模型最终将类似于一种演化方法，因为需要尽快开发能够尽可能由于用户测试的可操作的代码。

          最后，值得注意的是瀑布模型和螺旋模型之间的另一层关系。螺旋模型中单个迭代自身可能遵循的一系列阶段会让人联想到瀑布模型。

迭代和增量开发

        演化模型和螺旋模型确定了一个改进的软件开发过程应该具有的两个重要特性。

        第一，软件开发应该增量地进行，与其把完成整个系统开发的全部工作集中在一次冲刺中进行，不如首先开发核心功能，得到一个虽然是有限的但是能够运行的工作的系统，然后再以一系列增量的方式逐步地增加剩余的功能。

        这种方法的优点是项目生命周期的早期就产生可以运行的代码，除了通过示范论证项目的可行性降低了风险之外，还解决了需求说明的问题。用户能够获得对运行系统的体验，并用这样的体验队随后的开发反馈修改（需求）和建议。

        第二，螺旋模型提出的软件过程应该被作为一系列迭代管理，而不是一次性经过瀑布模型确定的各种活动。尽管原本的螺旋模型明确地作为管理项目中风险的一种方法被提出，但它也能够解决管理需求变化的问题，如果需求变化被确定为是一个重大风险，迭代将包含构造一个合理的原型，以引出来自用户的反馈。

       当前的过程模型视图把增量和迭代开发的优点与瀑布模型提供的传统的过程结构结合起来，如今最著名的这类模型是统一软件开发过程。

统一过程（Unified Software Development Process）

       图中的垂直轴表示了一个有些传统的开发活动列表，或以统一过程的术语成为工作流（workflows）。这个图中最值得注意的思想，对应于每个工作流的阴影区指示的，是每个活动可能在任何迭代中发生，但是在一次迭代中这些活动的平衡将会随着项目从开始到完成的进展而变更。

       这四个阶段均以里程碑（milestones）结束，在图中没有表示出来，里程碑的意图是捕捉项目生命周期中的点，在这些点上可能进行重大的管理决策和进展评估。初始阶段主要关注项目计划和风险评估。细化阶段关心定义系统的总体架构。构造阶段是建立系统，以一个能够交给客户进行测试的版本结束。移交阶段包含了测试时期，以发布完整的系统而终止。

       每个阶段中可能有不同次数的迭代。如图所表明的，一次迭代一般将被组织为一个小的瀑布过程。一次迭代应该导致对所构造产品的一个增量的改进。

       通常，尤其是接近项目结束时，每次迭代将会产生一个已经完全实现的功能性的增量，但是也可能是其他结果。例如，导致对系统体系结构的一些方面修改的一次迭代，如果它意味着后续的迭代能够更有效地进行，那么将会非常有价值。

参考文献：

《面向对象设计UML实战》 第二版  Mark Priestley 著    龚晓庆  卞雷 等译    王少峰  审

《UML例子》