umlsummary005.htm

软件开发文档大全

      </b><p align="JUSTIFY">UML是在Booch、OMT、OOSE等面向对象的方法及许多其他来源的基础上发展起来的。UML包含了来自许多人员的各种不同的观点，也受到了非面向对象方法的影响。UML表示法混合了不同的图形表示方法，剔除了其中容易引起混淆、冗余的、或者很少使用的符号，同时增添了一些新的符号。UML中的概念来自于面向对象技术领域中众多人员的思想。UML开发者们并没有提出其中大部分的观点，而只是对优秀的面向对象和计算机科学的方法加以选择和综合。表示法和语义的实际发展历程是非常复杂的，这里介绍的只是一些简单的背景知识，而不是详细的发展史。</p>    
      <p align="JUSTIFY">UML<i>用例图</i>与OOSE方法类似。</p>    
      <p align="JUSTIFY">UML的<i>类图</i>综合了OMT、Booch等面向对象方法中的类图。各种图表可以通过进程特定的扩展（如构造型及相应的符号）来支持其他的建模方法。</p>    
      <p align="JUSTIFY">UML的<i>状态图</i>是对David Harel所提出的状态图的改进。UML<i>活动图</i>的基本语义与状态图大致相同，它类似于许多方法（包括面向对象技术以前的一些方法）中的工作流图。</p>     
      <p align="JUSTIFY">你可以在许多面向对象的方法中发现UML<i>时序图</i>的影子（如<i>交互作用、消息流     
      </i>、<i>事件流</i>）等，甚至可以追溯到面向对象技术以前的方法。UML的<i>协同图</i>是通过对Booch方法的<i>对象图</i>、Fusion方法的<i>对象交互作用图</i>以及其他一些方法中的相关图表改造而来的。</p>     
      <i><p align="JUSTIFY">协同</i>是比较基本的建模元素，它构成了<i>模式</i>的基础。</p>     
      <p align="JUSTIFY">UML的<i>实现图（构件 </i>和<i>安装维护图）</i>是在Booch方法中的<i>模块</i>和<i>进程图（处理器关系图、处理器图）</i>的基础上发展起来的，但UML的实现图以构件为中心而不是以模块为中心，相互之间的联系也更紧密。</p>     
      <i><p align="JUSTIFY">构造型</i>是UML扩展机制中的一种，它扩展了UML元模型的语义。构造型还可以附带用户定义的符号，以满足特定开发流程的需要。</p>     
      <p align="JUSTIFY">上述的这些概念有着深远的渊源和影响，我们只能进行简单扼要的介绍。UML实际上是计算机科学和软件工程学长期发展的产物。</p>     
      <font size="5"><b><h4>4.2<a name="4.2"></a>UML未涉及的领域</h4>     
      </b></font><p align="JUSTIFY">UML定义1.0版并没有提出开发工具和开发流程的标准，这是因为两者所考虑的问题有很大不同。标准化的建模语言是开发工具和流程的必要基础。</p>     
      <b><p>工具</p>     
      </b><p align="JUSTIFY">对象管理小组的RFP（OADTF RFP-1）是推动UML开发的重要力量。RFP的初衷是增强开发工具彼此之间相互协作的能力，但实际上，开发工具及其可协作性在很大程度上依赖于一致的语义和表示法定义（如UML）。虽然UML定义的是<i>语义</i>元模型，而不是<i>工具</i>元模型，但这两者是非常接近的。在语义和表示法定义的基础上，很容易制订出一致的开发工具交互标准。</p>     
      <p align="JUSTIFY">在向OMG提交UML的同时，UML开发者们还提交了一个依从UML的工具接口定义。这个定义在大批量数据传送的编码和语法方面采用了CDIF/     
      EIA标准。</p>     
      <p align="JUSTIFY">UML文档中包括一些给工具开发者的有关具体实现的建议，但并没有对所有的问题作出回答。例如，文档中没有关于图表设计、色彩、用户索引、生动性等特点的内容。</p>     
      <b><p>开发流程</p>     
      </b><p align="JUSTIFY">许多组织都把UML作为框架设计的通用语言，并在各种不同类型的开发流程中使用UML的图表。UML并不依赖于特定的开发流程方法，定义标准的开发流程并不是UML开发的计划，也不是OMG的要求。</p>     
      <p align="JUSTIFY">但UML的开发者确实认识到了开发流程的重要作用。是否存在一个严格定义、管理方便的工作流程是区别项目水平高低的关键。繁重的编程并不是持久的商业开发方法。开发流程可以1）指导制订开发小组的行动规划，2）确定开发的框架，3）从总体上指导个人和开发小组的工作，4）提供监督和衡量项目成果及开发工作的标准。</p>     
      <p align="JUSTIFY">项目的流程在本质上要满足不同组织、不同风格、不同应用领域的需要。在某些情况（例如错综繁绕的软件的开发）下有效的开发流程方法很可能在其他情况（如严格实时的系统开发）下效果并不是很好。应用领域、实现技术和开发小组的技能在很大程度上决定了工作流程的选择。</p>     
      <p align="JUSTIFY">Booch、OMT、OOSE以及许多其他方法都有自己严格定义的开发流程，UML可以支持其中大部分的开发流程方法。虽然人们已经认识到了开发流程的重要作用，但流程标准化的问题还没有引起足够的重视。目前，更有可能发生的情况是人们普遍认同一些优秀的方法，选择某种开发流程的框架，并在这个框架的基础上规划自己的工作流程。虽然UML没有强制使用特定的开发流程，但UML的开发者们更提倡从用例驱动到以体系结构为中心最后反复改进、不断添加的软件开发过程，因此在UML定义中谨慎的提出了这个方法。</p>     
      <font size="5"><b><h4>4.3<a name="4.3"></a>UML与Booch、OMT、OOSE以及其他建模方法的比较</h4>     
      </b></font><p align="JUSTIFY">首先必须明确统一建模语言并没有从根本上脱离Booch、OMT或OOSE方法，而是对这些方法的有批判的继承。这就意味着，如果目前你是一名Booch、OMT     
      或OOSE方法的使用者，你接受的培训、你的工作经验和所偏好的开发工具都可以保留下来，因为统一建模语言是对这些方法的延续。对于其他方法的使用者来说，UML同样很容易接受。但这些方法的作者必须决定是否在他们的方法中采用UML的概念和表示法。</p>     
      <p align="JUSTIFY">与Booch、OMT、OOSE等<font face="Times New Roman">??</font>他方法相比，统一建模语言有表达力更强、更清晰和一致的优点。因此，转而采用UML并不是毫无意义的，它可以使工程在更广的范围内建模。其他大多数方法和建模语言的使用者也会因采用UML而受益，因为UML消除了各种方法在表示法和术语上的不必要的差异，而正是这些差异隐藏了不同方法之间重要的相似之处。</p>     
      <p align="JUSTIFY">相对于其他可视化建模语言，例如基于实体和关系的模型化方法、BPR流图、状态驱动的建模语言等，UML更富有表达力，机能更完善。</p>     
      <p align="JUSTIFY">从现有的方法到UML，在表示法上会有略微的变化，但这并不需要使用者花很长的时间从头学习，而且可以使关键性的语义更加明确。如果UML统一的目标得以实现，那么随着有关UML的开发工具，书籍和培训课程的逐渐推广，UML将成为开发项目首选的建模方法。目前，许多可视化的建模工具将现有的表示法，如Booch、OMT、OOSE等方法，作为模型的不同视图；随着这些工具对UML的支持，使用者将会很容易的把其他方法的模型转换成UML模型，而不会丢失任何信息。</p>     
      <p align="JUSTIFY">任何面向对象方法的使用者都可以通过短期的学习而获得与以前相同的表达能力。你可以很快就熟练掌握UML的基本使用。高级的UML技术，如构造型和属性的使用，还需要你更深入的学习。这些高级技术可以使模型更精确，更富有表达力。</p>     
      <font size="5"><b><h4>4.4<a name="4.4"></a>UML的新特点</h4>     
      </b></font><p align="JUSTIFY">UML的开发是为了简化建模方法，它抛弃了Booch、OMT和OOSE方法中的糟粕，而代之以其他方法中的精华。只有在没有现有的解决方法时，UML的开发者们才考虑增加新的特点。UML的开发者们是在设计一门语言（尽管只是一门图式语言），因此必须在简单（所有元素一律用方框和文字表达）和烦琐（为每个元素设计单独的符号）之间取得平衡。UML的设计者对增加新的元素非常谨慎，因为他们不想使UML过于复杂。尽管如此，UML中还是增添了一些新的元素，因为这些元素在其他建模语言的实践中已经被证明是非常有用的。</p>     
      <p align="JUSTIFY">UML中增加了下列新概念：</p>     
      <blockquote>     
        <p align="JUSTIFY">构造型</p>     
        <p align="JUSTIFY">责任</p>     
        <p align="JUSTIFY">扩展机制：构造型、特征值及限制条件</p>     
        <p align="JUSTIFY">线程和进程 </p>     
        <p align="JUSTIFY">分布及并发（如建模ActiveX/DCOM 和CORBA）</p>     
        <p align="JUSTIFY">模式/协同</p>     
        <p align="JUSTIFY">活动图（用于商业进程再工程）</p>     
        <p align="JUSTIFY">类型、类和实例的明确区分</p>     
        <p align="JUSTIFY">求精（处理不同抽象层次）</p>     
        <p align="JUSTIFY">界面和构件</p>     
      </blockquote>     
      <p align="JUSTIFY"><br>     
      这些概念中的大部分都已经在其他方法和理论中提出了，UML把它们统一成一个整体。除了这些较大的变化外，我们还对Booch、OMT和OOSE方法的语义和表示法作了一些局部改动。</p>     
   
<p align="JUSTIFY"><a href="umlsummary000.htm">返回目录</a></p>
  
</body>