西安工业大学《软件工程》第十二章 统一建模语言(UML)

第十二章统一建模语言（UML）UML（统一建模语言UnifiedModelingLanguage）是一种建模语言，是一种为面向对象开发系统的产品进行可视化的说明和编制文档的方法。它是由信息系统（IS，InformationSystem）和面向对象领域的三位著名的方法学家：GradyBooch、JamesRumbaugh、和IvarJacobson提出的，由OMG组织（ObjectManagementGroup）采纳作为业界标准。UML取代目前软件业众多的分析和设计方法（Booch、Coad、Jacobson、Odell、Rumbaugh、Wirfs-Brock等），成为一种标准，这是软件界第一次有了一个统一的建模语言。OMG已经把UML作为公共可得到的规格说明（PubliclyAvailableSpecification，PAS）提交给国际标准化组织（ISO）进行国际标准化，使UML最终正式成为信息技术的国际标准。12.1UML简介12.1.1UML的产生和成长.面向对象的分析与设计(OOA＆D)方法的发展在80年代末至90年代中出现了一个高潮，UML是这个高潮的产物。它不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而且对其作了进一步的发展，并最终统一为大众所接受的标准建模语言。从1989年到1994年，面向对象建模语言的数量增加到了五十多种。众多的建模语言有各自的表示法。但是，OO方法的用户并不了解不同建模语言的优缺点及相互之间的差异，因而很难根据应用特点选择合适的建模语言，于是爆发了一场“方法大战”。90年代中，一批新方法出现了，其中最引人注目的是Booch1993、OOSE和OMT-2等。Booch是面向对象方法最早的倡导者之一，他提出了面向对象软件工程的概念。Rumbaugh等人提出了面向对象的建模技术（OMT）方法，采用了面向对象的概念，并引入各种独立于语言的表示符。Jacobson于1994年提出了OOSE方法，其最大特点是面向用例(Use-Case)，并在用例的描述中引入了外部角色的概念。此外，还有Coad/Yourdon方法，即著名的OOA/OOD，它是最早的面向对象的分析和设计方法之一。该方法简单、易学，适合于面向对象技术的初学者使用，但由于该方法在处理能力方面的局限，目前已很少使用。概括起来，首先，面对众多的建模语言，用户由于没有能力区别不同语言之间的差别，因此很难找到一种比较适合其应用特点的语言；其次，众多的建模语言实际上各有千秋；第三，虽然不同的建模语言大多类同，但仍存在某些细微的差别，极大地妨碍了用户之间的交流。因此在客观上，极有必要在精心比较不同的建模语言优缺点及总结面向对象技术应用实践的基础上，组织联合设计小组，根据应用需求，取其精华，去其糟粕，求同存异，统一建模语言。1994年10月，GradyBooch和JimRumbaugh开始致力于这一工作。他们首先将Booch93和OMT-2统一起来，并于1995年10月发布了第一个公开版本，称之为统一方法UM0.8（UnitiedMethod）。1995年秋，OOSE的创始人IvarJacobson加盟到这一工作。经过Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分别发布了两个新的版本，即UML0.9和UML0.91，并将UM重新命名为UML（UnifiedModelingLanguage）。1996年，UML的开发者得到了来自公众的正面反应，并倡议成立了UML成员协会，以完善、加强和促进UML的定义工作。当时的成员有DEC、HP、I－Logix、Itellicorp、IBM、ICONComputing、MCISystemhouse、Microsoft、Oracle、RationalSoftware、TI以及Unisys。这一机构对UML1.0（1997年1月）及UML1.1（1997年11月17日）的定义和发布起了重要的促进作用。UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。1996年底，UML已稳占面向对象技术市场的85％，成为可视化建模语言事实上的工业标准。1997年11月17日，OMG采纳UML1.1作为基于面向对象技术的标准建模语言。UML代表了面向对象方法的软件开发技术的发展方向，具有巨大的市场前景，也具有重大的经济价值和国防价值。12.1.2UML的应用领域UML被用来为系统建模，它可应用的范围非常广泛。可以描述许多类型的系统，它也可以用来描述系统开发的不同阶段，从需求规格说明到对已完成系统的测试。1．在不同类型系统中的应用UML的目标是用面向对象的方式描述任何类型的系统，最直接的是用UML为软件系统创建模型。但UML也可用来描述其它非计算机软件的系统或者是商业机构或过程。总之，UML是一个通用的标准建模语言，可以对任何具有静态结构和动态行为的系统进行建模。UML常见的应用有：信息系统（InformationSystem）：向用户提供信息的储存、检索、转换和提交。处理存放在关系或对象数据库中大量具有复杂关系的数据技术系统（TechnicalSystem）：处理和控制技术设备。如电信设备军事系统或工业过程。它们必须处理设计的特殊接口，标准软件很少。技术系统通常是实时系统。嵌入式实时系统（EmbeddedReal-TimeSystem）：在嵌入到其它设备，如移动电话、汽车家电上的硬件上执行的系统，通常是通过低级程序设计进行的，需要实时支持。分布式系统（DistributedSystem）：分布在一组机器上运行的系统。数据很容易从一个机器传送到另一台机器上，需要同步通信机制来确保数据完整性。通常是建立在对象机制上的，如CORBA、COM/DCOM、或JavaBeans/RMI上。系统软件（SystemSoftware）：定义了其它软件使用的技术基础设施。操作系统数据库和在硬件上完成底层操作的用户接口等，同时提供一般接口供其它软件使用。商业系统（BusinessSystem）：描述目标、资源（人、计算机等）规则、法规（商业策略、政策等）和商业中的实际工作（商业过程）。要强调的是，通常大多数系统都不是单纯属于上面的某一种系统，而是一种或多种的结合。例如现在许多信息系统都有分布式和实时的需要。商业工程是面向对象建模应用的一个新的领域。面向对象建模非常适合为公司的商业过程建模。运用商业过程再工程（BusinessProcessReengineering，BPR）或全质量管理（TotalQualityManagementTQM）等技术，可以对公司的商业过程进行分析、改进和实现，使用面向对象建模语言为过程建模和编制文档，使过程易于使用。总之，UML具有描述以上这些类型的系统的能力。2．在软件开发的不同阶段中的应用UML适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。在需求分析阶段，可以用用例来捕获用户需求。通过用例建模，描述对系统感兴趣的外部角色及其对系统（用例）的功能要求。分析阶段主要关心问题域中的主要概念（如抽象、类和对象等）和机制，需要识别这些类以及它们相互间的关系，并用UML类图来描述。为实现用例，类之间需要协作，这可以用UML动态模型来描述。在分析阶段，只对问题域的对象（现实世界的概念）建模，而不考虑定义软件系统中技术细节的类（如处理用户接口、数据库、通讯和并行性等问题的类）。这些技术细节将在设计阶段引入，因此设计阶段为构造阶段提供更详细的规格说明。编程（构造）是一个独立的阶段，其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。在用UML建立分析和设计模型时，应尽量避免考虑把模型转换成某种特定的编程语言。因为在早期阶段，模型仅仅是理解和分析系统结构的工具，过早考虑编码问题十分不利于建立简单正确的模型。UML模型还可作为测试阶段的依据。系统通常需要经过单元测试、集成测试、系统测试和验收测试。不同的测试小组使用不同的UML图作为测试依据：单元测试使用类图和类规格说明；集成测试使用部件图和合作图；系统测试使用用例图来验证系统的行为；验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。总之，标准建模语言UML适用于以面向对象技术来描述任何类型的系统，而且适用于系统开发的不同阶段，从需求规格描述直至系统完成后的测试和维护。12.2UML语言概述UML由视图（views）、图（Diagrams）、模型元素（Modelelements）和通用机制（generalmechanism）等几个部分构成。12.2.1视图（views）视图用来表示被建模系统的各个方面。视图由多个图（Diagrams）构成，它不是一个图片（graph），而是在某一个抽象层上对系统的抽象表示。如果要为系统建立一个完整的模型图，只需定义一定数量的视图，每个视图表示系统的一个特殊的方面就可以了。另外，视图还把建模语言和系统开发时选择的方法或过程连接起来。描述一个系统涉及到该系统的许多方面，比如：功能性方面（它包括静态结构和动态交互）、非功能性方面（定时需求、可靠性、展开性等）和组织管理方面（工作组、映射代码模块等）。完整地描述系统，通常的做法是用一组视图反映系统的各个方面，每个视图代表完整系统描述中的一个抽象，显示这个系统中的一个特定的方面，每个视图由一组图构成。图中包含了强调系统中某一方面的信息。视图与视图之间有时会产生轻微的重叠，从而使得一个图实际上可能是多个视图的一个组成部分，如果用不同的视图观察系统，每次只集中地观察系统的一个方面。视图中的图应该简单，易于交流且与其他的图（图用图形符号表示，图符号代表系统中的模型元素）和视图有关联关系。UML中的视图包括用例视图（Use-caseview）、逻辑视图（Logicalview）、构件视图（Componentview）、并发视图（ConcurrencyView）、部署视图（DeploymentView）等五种。1．用例视图（Use-caseview）用例视图用于描述系统应该具有的功能集，它是系统的外部用户所能观察到的系统功能的模型图。用例视图中可以包含若干个用例（use-case），用例用来表示系统能够提供的功能，一个用例是系统用法（功能请求）的一个通用描述。系统的最终目标是提供用例视图中描述的功能，同时附带一些非功能性的性质，所以用例视图是其他视图的核心和基础，其他视图的构造和发展依赖于用例视图中所描述的内容。用例视图还可用于测试系统是否满足用户的需求和验证系统的有效性。用例视图主要为用户、设计人员、开发人员、和测试人员而设置。用例视图静态地描述系统功能，为了动态地观察系统功能，偶尔也用活动图（activitydiagram）描述。2．逻辑视图（Logicalview）逻辑视图展示了系统内部如何提供系统的功能。它利用系统的静态结构和动态行为来刻画系统功能，静态结构描述类、对象和它们之间的关系等。动态行为主要描述对象之间的动态协作，当对象之间彼此发送消息给给定的函数时产生动态协作，一致性（persistence）和并发性（concurrency）等性质以及接口和类的内部结构都要在逻辑视图中定义。静态结构在类图和对象图中描述，动态建模用状态图、顺序图、协作图和活动图描述。3．构件视图（Componentview）构件视图用来显示代码构件的组织方式。它描述了实现模块（implementationmodule）和它们之间的依赖关系。构件视图由构件图构成，构件是代码模块，不同类型的代码模块形成不同的构件，构件按照一定的结构和依赖关系呈现。构件的附加信息（比如为构件分配资源）或其他管理信息（比如进展工作的进展报告）也可以加入到构件视图中。构件视图主要供开发者使用。4．并发视图（ConcurrencyView）并发视图用来显示系统的并发工作状况。并发视图将系统划分为进程和处理机方式，通过划