UML精粹第一章-李译.docVIP

UML精粹第一章第一节-UML 统一建模语言（Unified Modeling Language，UML）为单一元模型支持的图形符号族，这些图形符号有助于我们描述与设计软件系统，特别是那些用面向对象（object-oriented，OO）方式构建的软件系统。这个定义似乎有点简单化了，事实上，UML 是因人而异的，究其原因，一半源自于它的历史，另一半是因为大家为了实现一个有效的软体工程开发流程，往往从不同的角度来使用它。因此，本章的主要任务是对大家看待和使用UML的不同方式予以解释与说明，为全书作出一个铺垫。 在软件业，图形化建模语言已出现多年。引发大家使用这些建模语言的基本原因是：原有程序设计语言的抽象程度不够高，无法满足对设计进行讨论与交流的需要。 虽然图形化建模语言（graphical modeling language）已出现多年，不过业界对它们所扮演的角色还是存在很大的争议，这些争议直接影响到人们如何看待UML 的作用。 UML是由对象管理组（Object Management Group，OMG）管理控制的一种开放标准。OMG是一个由多家公司所组成的开放性联合组织，成立的宗旨是建立互操作（interoperability）的相关标准，特别是面向对象系统间的互操作问题。OMG 最广为人知的事迹或许是CORBA（Common Object Request Broker Architecture，CORBA）标准。 UML起源于多种图形建模语言的融合，这些建模语言在上世纪80年代末到上世纪90年代初非常繁荣。UML在1997年出现，使原本一片混乱的局面成为了历史，这使得包括我在内的广大开发人员深感欣慰。 第二节 UML的不同用法UML 在软件开发中所起作用的实质是人们使用它不同方式，这些差异其实是从其他图形化建模语言延续而来的，也因此导致了一个长期难以解决的争论：我们该如何使用UML？ 为了解决这一纷争，Steve Mellor和我分别针对人们使用UML的特点提出了三种使用模式，即分别把 UML当成草图绘制语言、蓝图绘制语言或编程语言来用。以我个人的观点，将UML视为草图绘制语言应该是到目前为止最常见的一种用法。在这一用法中，开发人员使用UML来帮他们实现系统某些层面的交流。和用作蓝图绘制语言一样，我们可以从正向工程（forward-engineering）或逆向工程（reversee engineering）两个不同方向来使用草图绘制语言。如果是采用正向工程的话，我们会在写程序之前先画出UML图，而逆向工程则是由现存代码产生UML图，以帮助我们理解代码。 绘制草图的实质是选择。以正向使用草图来看，先针对要编码的某些议题粗略画出草图，然后与项目组的同事进行讨论。使用草图的目的是帮助我们沟通想法，并且针对要做的事情探讨可供选择的方法。讨论不要涉及所有要编写的代码，只需针对那些打算先交给同事去做的重要议题，或者在开始写代码之前想以可视方式展现出来的部分展开。像这样的会议通常非常短，有可能开十分钟的会讨论未来几小时的编码工作，或者花费一天来讨论未来为期2个星期的迭代（iteration）工作。 对于逆向工程，通常利用草图说明系统的某个部分如何工作。因此，不必展示所有的类，仅需展示那些有意义或在深入研究代码之前值得一提的问题。 由于草图是非正式的，变动性也很大，需要快速、相互协作完成，所以白板是最为常用的一种工具。草图对于设计文档也有用，在这种情形下，重点在于沟通和交流，而不是苛求完备。用来画出草图的都是简易的画图工具，而且大家也不会刻意遵守UML中的每一条严谨规则。多数书（例如我的其他书）中所给出来的UML图，大多是草图，其重点在于有选择地交流，而不是完整地说明。 与此相反，将UML视为蓝图绘制语言则强调完整性。在正向工程中，蓝图绘制由设计师完成，设计师的工作就是做出详细设计，供程序员依葫芦画瓢完成编码。设计结果必须足够完整，要做出所有的设计选择，程序员不需要太多思考，就可以按照它完成代码编写。当然，设计师和程序员有可能是同一个人，不过一般来说设计师通常是比较资深的开发人员，由他替整个程序员团队做出设计。这种做法得益于其他类型工程的启发，在那些工程中，往往先由专业工程师画出工程图，然后，再把这些图纸交给建筑公司去施工。 蓝图绘制可以用于所有细节性工作，即，设计师可以针对特定部份画出蓝图。对于设计师，通常的做法是建造出蓝图级的模型，直到子系统的接口，稍后再让开发人员给出实现的具体细节。 在逆向工程中，蓝图的目的是传递关于代码的详细信息，可以借助纸质文档，也可以通过交互式的图形浏览器。蓝图可用图形方式展示某个类的所有细节，让开发人员更容易理解。 与草图绘制相比，蓝图绘制需要更复杂的工具，以便处理工作任务所需要的细节。专用的CASE（