|
|
知识路径： > 信息系统开发和运行管理知识 > 系统分析设计基础知识 > 面向对象分析设计与统一建模语言（UML） >
|
被考次数：16次
被考频率：高频率
总体答错率：40%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
考试要求：了解
相关知识点：15个
|
|
|
|
|
|
|
UML （Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍实用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。它不仅可以支持面向对象的分析与设计，更重要的是能够有力地支持从需求分析开始的软件开发的全过程。UML是一种建模语言，而不是一种方法。
|
|
|
|
UML由信息系统和面向对象领域的三位著名的方法学家Grady Booch、Ivar Jacobson和Jim Rumbaugh提出，并得到业界的广泛支持，由OMG组织（Object Management Group）采纳作为业界标准。UML取代了目前软件业众多的分析和设计方法而成为一种标准，成为软件界的第一个统一的建模语言。目前OMG已经把UML作为公共可得到的规格说明提交给国际标准化组织（ISO）进行国际标准化，UML最终将正式成为信息技术的国际标准。
|
|
|
|
|
|
对于很多程序员来说，把实现的思想变成代码，其间没有什么距离可言，就是思考和编码。事实上，对有些事情的处理最好就是直接编码。但是，软件开发并不仅仅是编码，程序员还需要做一些建模。但这其中存在几个问题：一些概念模型容易产生错误的理解，因为并不是每个人都使用相同的语言。一种有代表性的情况是：假设项目开发单位建立了自己的语言，如果你是外来者或是加入项目组的新人，你就难以理解该单位在做什么事情。除非建立了模型（不仅仅是文字的编程语言），否则你就不能够理解软件系统中的某些事情。例如，阅读一个类层次的所有代码，虽可推断出对象的物理分布和可能移动，但也不能直接领会它。如果一个开发者仅写下代码而没有写下他头脑中的模型，一旦他另寻高就，那么这些信息就会永远丢失，最好的情况也只能是通过实现而部分地重建。
|
|
|
|
针对第一个问题，UML是一组图形符号，UML表示法中的每个符号都有明确语义。UML使一个开发者可以用UML绘制一个模型，而另一个开发者（甚至工具）可以无歧义地解释这个模型。针对第二个问题，UML是一种图形化语言，它用图形建模。针对第三个问题，UML建立了清晰的模型有利于将来的重建。
|
|
|
|
|
|
UML不是一种可视化的编程语言，但用UML描述的模型可与各种编程语言直接相连。这意味着一种可能性，即可把用UML描述的模型映射成编程语言，如Java、C++和Visual Basic等，甚至映射成关系数据库的表或面向对象数据库的永久存储。对一个事物，如果表示为图形方式最为恰当，则用UML，而如果表示为文字方式最为恰当，则用编程语言。
|
|
|
|
这种映射允许进行正向工程：从UML模型到编程语言的代码生成。也可以进行逆向过程：由编程语言代码重新构造UML模型。逆向工程并不是魔术。除非你对实现中的信息编码，否则从模型到代码会丢失这些信息。逆向工程需要工具支持和人的干预。把正向代码生成和逆向工程这两种方式结合起来就可以产生双向工程，这意味着既能在图形视图下工作，又能在文字视图下工作，这需要用工具来保持两者的一致性。
|
|
|
|
除了直接映射之外，UML具有丰富的表达力，而且无歧义性，这允许直接执行模型，系统地模拟以及对运行系统进行操纵。
|
|
|
|
|
|
一个健壮的软件组织除了生产可执行的源代码之外，还要给出各种制品。这些制品包括内容如下。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
依靠于开发背景，有些制品或多或少地比另一些制品要正规些。这些制品不但是项目交付时所要求的，而且无论是在开发期间还是在交付使用后对控制、度量和理解系统也是关键的。
|
|
|
|
UML适于建立系统体系结构及其所有的细节文档。UML还提供了用于表达需求和用于测试的语言。最终UML提供了对项目计划和发布管理的活动进行建模的语言。
|
|
|
|
|
|
|
|
.与具体的实现无关，可应用于任何语言平台和工具平台。
|
|
|
|
|
|
.简单并且可扩展，具有扩展和专有化机制，便于扩展，无需对核心概念进行修改。
|
|
|
|
.为面向对象的设计与开发中涌现出的高级概念，例如协作框架模式和组件提供支持，强调在软件开发中对架构框架模式和组件的重用。
|
|
|
|
|
|
|
|
|
|
|
|
UML的目的是建模，在UML中，建立的模型有三个要素：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
结构事物是UML模型中的静态部分，描述概念或物理元素。共有7种结构事物。
|
|
|
|
①类（class）是对一组具有相同属性、相同操作、相同关系和相同语义的对象的描述。一个类实现了一个或多个接口。在图形上，把一个类画成一个矩形，通常矩形中写有类的名称、类的属性和类的操作，如下图所示。
|
|
|
|
|
|
|
|
②接口（interface）是描述了一个类或构件的一个服务的操作集。因此，接口描述元素的外部可见行为。一个接口可以描述一个类或构件的全部行为或部分行为。接口定义了一组操作的描述（即特征标记），而不是操作的实现。在图形上，把一个接口画成一个带有名称的圆。接口很少单独存在，而是通常依附于实现接口的类或构件，如下图所示。
|
|
|
|
|
|
|
|
③协作（collaboration）定义了一个交互，它是由一组共同工作以提供某协作行为的角色和其他元素构成的一个群体，这些协作行为大于所有元素的各自行为的总和。因此，协作有结构、行为和维度。一个给定的类可以参与几个协作。这些协作因而表现了系统构成模式的实现。在图形上，把一个协作画成一个通常仅包含名称的虚线椭圆，如下图所示。
|
|
|
|
|
|
|
|
④用例（Use Case）是对一组动作序列的描述，系统执行这些动作将产生一个对特定的参与者有价值而且可观察的结果。用例用于对模型中的行为事物结构化。在图形上，把一个用例画成一个实现椭圆，通常仅包含它的名称，如下图所示。
|
|
|
|
|
|
|
|
⑤活动类（Active Class）也是一种类，其对象至少拥有一个进程或线程，因此它能够启动控制活动。活动类的对象所描述的元素的行为与其他元素的行为并发，除了这一点之外，它和类是一样的。在图形上，活动类很像类，只是它的外框是粗框，通常它包含名称、属性和操作，如下图所示。
|
|
|
|
|
|
|
|
⑥组件（component）是可重用的系统片段，具有良好定义接口的物理实现单元。组件包含了系统设计中某些类的实现。组件设计的原则：良好的组件不直接依赖于其他组件，而是依赖于其他组件所支持的接口。这样的好处是系统中的组件可以被支持相同接口的组件所取代。在一个系统中，你将遇到不同类型的部署组件，如COM+构件和Java Bean，以及在开发过程中所产生的制品组件，如源代码文件。通常组件是一个描述了一些逻辑元素（如类、接口和协作）的物理包。在图形上，把一个组件画成一个带有小方框的矩形，通常在矩形中只写该组件的名称，如下图所示。
|
|
|
|
|
|
|
|
⑦结点（node）是在运行时存在的物理元素，它表示了一种可计算的资源，它通常至少有一些记忆能力和处理能力。一个组件集可以驻留在一个结点内，也可以从一个结点迁移到另一个结点。在图形上，把一个结点画成一个立方体，通常在立方体内只写它的名称，如下图所示。
|
|
|
|
|
|
|
|
|
|
行为事物是UML模型的动态部分，描述了跨越时间和空间的行为，共有两类主要的行为事物。
|
|
|
|
①交互（interaction）是这样一种行为，它由在特定语境中共同完成一定任务的一组对象之间交换的消息组成。一个对象群体的行为或单个操作的行为可以用一个交互来描述。交互涉及一些其他元素，包括消息、动作序列（由一个消息所引起的行为）和链（对象间的连接）。在图形上，把一个消息画成一条有向直线，通常在表示消息的线段上总有操作名，如下图所示。
|
|
|
|
|
|
|
|
②状态机（state machine）是这样一种行为，它描述了一个对象或一个交互在生命期内响应事件所经历的状态序列。单个类或一组类之间协作的行为可以用状态机来描述。一个状态机涉及到一些其他元素，包括状态、转换（从一个状态到另一个状态的流）、事件（触发转换的事物）和活动（对一个转换的响应）。在图形上，把一个状态画成一个圆角矩形，通常在圆角矩形中含有状态的名称及其子状态，如下图所示。
|
|
|
|
|
|
|
|
|
|
分组事物是UML模型的组织部分。它们是一些由模型分解成的“盒子”。在所有的分组事物中，最主要的分组事物是包。
|
|
|
|
包（package）是把元素组织成组的机制，这种机制具有多种用途。结构事物，行为事物甚至其他的分组事物都可以放进包内。包不像构件（仅在运行时存在），它纯粹是概念上的（即它仅在开发时存在）。在图形上，把一个包画成一个左上角带有一个小矩形的大矩形，在矩形中通常仅含有包的名称，有时还有内容，如下图所示。
|
|
|
|
|
|
|
|
|
|
注释事物是UML模型的解释部分。这些注释事物用来描述，说明和标注模型的任何元素。有一种主要的注释事物，称为注解。注解（note）是一个依附于一个元素或一组元素之上，对它进行约束或解释的简单符号。在图形上，把一个注解画成一个右上角是折角的矩形，其中带有文字或图形解释，如下图所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
①依赖（dependency）是两个事物间的语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义。在图形上，把一个依赖画成一条可能有方向的虚线，偶尔在其上还有一个标记，如下图所示。
|
|
|
|
|
|
|
|
②关联（association）是一种结构关系，它描述了一组链，链是对象之间的连接。聚合是一种特殊类型的关联，它描述了整体和部分间的结构关系。在图形上，把一个关联画成一条实线，它可能有方向，偶尔在其上还有一个标记，而且它经常还含有诸如多重性和角色名这样的修饰，如下图所示。
|
|
|
|
|
|
|
|
③泛化（generalization）是一种特殊／一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象。用这种方法，子元素共享了父元素的结构和行为。在图形上，把一个泛化关系画成一条带有空心箭头的实线，它指向父元素，如下图所示。
|
|
|
|
|
|
|
|
④实现（realization）是类元之间的语义关系，其中的一个类元指定了由另一个类元保证执行的契约。在两种地方要遇到实现关系：一种是在接口和实现它们的类或构件之间；另一种是在用例和实现它们的协作之间。在图形上，把一个实现关系画成一条带有空心箭头的虚线，它是泛化和依赖关系两种图形的结合，如下图所示。
|
|
|
|
|
|
|
|
|
|
图（diagram）是一组元素的图形化表示，大多数情况下把图画成顶点（代表事物）和弧（代表关系）的连通图。为了对系统进行可视化，可以从不同的角度画图，这样图是对系统的投影。除了非常微小的系统外，图是系统组成元素的省略视图。有的元素可以出现在所有图中，有的元素可以出现在一些图中（很常见），还有的元素不能出现在图中（很罕见）。在理论上，图可以包含任何事物及其关系的组合。然而，实际上仅存在着少量的常见组合，它们要与5种最有用的组成了软件密集型系统的体系结构的视图相一致。由于这个原因，UML中的图可以分为几下几类：
|
|
|
|
①第一类是用例图，从用户角度描述系统功能，并指出各功能的操作者。
|
|
|
|
②第二类是静态图（Static Diagram），包括类图、对象图和包图。
|
|
|
|
.类图描述系统中类的静态结构。不仅定义系统中的类，表示类之间的联系如关联、依赖、聚合等，也包括类的内部结构（类的属性和操作）。类图描述的是一种静态关系，在系统的整个生命周期都是有效的。
|
|
|
|
.对象图是类图的实例，几乎使用与类图完全相同的标识。它们的不同点在于对象图显示类的多个对象实例，而不是实际的类。一个对象图是类图的一个实例。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。
|
|
|
|
.包由包或类组成，表示包与包之间的关系。包图用于描述系统的分层结构。
|
|
|
|
③第三类是行为图（Behavior Diagram），描述系统的动态模型和组成对象间的交互关系。包括状态图和活动图。
|
|
|
|
.状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常，状态图是对类图的补充。在实际应用时并不需要为所有的类画状态图，仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。
|
|
|
|
.活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。
|
|
|
|
④第四类是交互图（Interactive Diagram），描述对象间的交互关系。包括顺序图和合作图。
|
|
|
|
.顺序图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互。
|
|
|
|
.合作图描述对象间的协作关系，合作图跟顺序图相似，显示对象间的动态合作关系。除显示信息交换外，合作图还显示对象以及它们之间的关系。如果强调时间和顺序，则使用顺序图；如果强调上下级关系，则选择合作图。这两种图被合称为交互图。
|
|
|
|
⑤第五类是实现图（Implementation Diagram）。包括组件图和配置图。
|
|
|
|
.组件图描述代码部件的物理结构及各部件之间的依赖关系。一个组件可能是一个资源代码部件、一个二进制部件或一个可执行部件。它包含逻辑类或实现类的有关信息。组件图有助于分析和理解部件之间的相互影响程度。
|
|
|
|
.配置图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设备（用结点表示）以及它们之间的连接关系，也可显示连接的类型及部件之间的依赖性。在结点内部，放置可执行部件和对象以显示结点跟可执行软件单元的对应关系。
|
|
|
|
使用用例图、类图、对象图、构件图和配置图等5个图形建立的模型都是静态的，是标准建模语言UML的静态建模机制；使用状态图、活动图、顺序图和协作图等4个图形建立的模型或者可以执行，或者可以表示执行时的时序状态或交互关系，是动态的、是标准建模语言UML的动态建模机制。因此，标准建模语言UML的主要内容也可以被归纳为静态建模机制和动态建模机制两大类。
|
|
|
|
|
|
UML是一种建模语言而不是方法，这是因为UML中没有过程的概念，而过程正是方法的一个重要组成部分。UML本身独立于过程，这意味着用户在使用UML进行建模时，可以选用任何适合的过程。一般采用的建模过程有：瀑布开发模型和迭代递增开发模型。
|
|
|
|
|
|
|
|
|
|
我们以采取迭代递增开发模型为例，说明UML的建模过程。
|
|
|
|
.需求分析该阶段产生的最初需求规格说明应当由代表系统最终用户的人员提供，内容包括系统基本功能需求和对计算机系统的要求。
|
|
|
|
.分析分析的任务是找出系统的所有需求并加以描述，同时建立模型，以定义系统中的关键领域类，应由系统用户和开发人员合作完成。
|
|
|
|
分析的第一步是定义用例，以描述所开发系统的外部功能需求。用例分析包括阅读和分析需求说明，此时需要与系统的潜在用户进行讨论。
|
|
|
|
.设计设计阶段的任务是通过综合考虑所有的技术限制，以扩展和细化分析阶段的模型。设计阶段可以分为两个部分：第一部分是结构设计，结构设计是高层设计，其任务是定义包（子系统），包括包间的依赖性和主要通信机制。我们希望得到尽可能简单和清晰的结构，尽可能地减少各部分之间的依赖，并尽可能的减少双向的依赖关系。一个设计良好的系统结构是系统可扩充和可变更的基础。包实际上是一些类的集合。类图中包括有助于用户从技术逻辑中分离出应用逻辑（领域类），从而减少它们之间的依赖性；第二部分是详细设计，细化包的内容，使编程人员得到所有类的一个足够清晰的描述。详细设计的目的是通过创建新的类图、状态图和动态图（顺序图、协作图和活动图），描述新的技术类，并扩展和细化分析阶段的对象类。
|
|
|
|
.实现构造或实现阶段是对类进行编程的过程。可以选择某种面向对象对象编程语言（如Java）作为实现系统的软件环境。Java很容易实现从逻辑视图到代码部件的映射，因为类到Java代码文件之间是一一映射关系。在实现阶段中，可以选取各种图的说明来辅助编程，比如：类图，状态图和动态图等。
|
|
|
|
.测试和配置完成系统编码后，需要对系统进行测试，它通常包括：单元测试、集成测试、系统测试和验收测试。在单元测试中使用类图和类的规格说明，对单独的类或一组类进行测试；在集成测试中，使用组件图和合作图，对各组件的合作情况进行测试；在系统测试中，使用用例图，以检验所开发的系统是否满足例图所描述的需求。
|
|
|
|
|
|
UML的目标是以面向对象图的方式来描述任何类型的系统，具有很宽的应用领域。其中最常用的是建立软件系统的模型，但它同样可以用于描述非软件领域的系统，如机械系统、企业机构或业务过程，以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。总之，UML是一个通用的标准建模语言，可以对任何具有静态结构和动态行为的系统进行建模。
|
|
|
|
此外，UML适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。UML在软件开发不同阶段的应用包括：
|
|
|
|
|
|
在需求分析阶段，可以用用例来捕获用户需求。通过用例建模，描述对系统感兴趣的外部角色及其对系统（用例）的功能要求。建模的每个用例都指定了客户的需求（他或她需要系统干什么）。
|
|
|
|
|
|
分析阶段主要关心问题域中的主要概念（如抽象、类和对象等）和机制，需要识别这些类以及它们相互间的关系，并用UML类图来描述。为实现用例，类之间需要协作，这可以用UML动态模型来描述。在分析阶段，只对问题域的对象（现实世界的概念）建模，而不考虑定义软件系统中技术细节的类（如处理用户接口、数据库、通信和并行性等问题的类）。这些技术细节将在设计阶段引入。
|
|
|
|
|
|
在设计阶段把分析阶段的结果扩展成技术解决方案，加入新的类来提供技术基础结构。用户接口、数据库操作等分析阶段的领域问题类被嵌入在这个技术基础结构中，设计阶段的结果是构造阶段的详细的规格说明。
|
|
|
|
|
|
实施是一个独立的阶段，其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。在用UML建立分析和设计模型时，应尽量避免考虑把模型直接转换成某种特定的编程语言。因为在早期阶段，模型仅仅是理解和分析系统结构的工具，过早考虑编码问题十分不利于建立简单正确的模型。
|
|
|
|
|
|
UML模型可作为测试阶段的依据。系统的测试通常分为单元测试、集成测试、系统测试和验收测试几个不同级别。
|
|
|
|
.单元测试是对几个类或一组类的测试，通常由程序员进行。
|
|
|
|
.集成测试集成组件和类确认它们之间是否恰当的协作。
|
|
|
|
.系统测试将系统当成一个黑箱，验证系统是否具备用户所要求的所有功能。
|
|
|
|
.验收测试由客户完成，与系统测试类似，验证系统是否满足所有的需求。
|
|
|
|
不同的测试小组使用不同的UML图作为测试依据：单元测试使用类图和类规格说明；集成测试使用组件图和合作图；系统测试使用用例图来验证系统的行为；验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。
|
|
|
