UML是用来描述模型的，它用模型来描述系统的结构或静态特征以及行为或动态特征。它从不同的视角为系统建模，形成不同的视图(View)，每个视图代表完整系统描述中的一个抽象，显示系统中的特定的方面每个视图由一组图(Diagram)构成，图中包含了强调系统中某一方面的信息。UML包括了两类图和5种视图。
图是系统构架在某个侧面的表示，UML提供了两大类———静态图和动态图，共计9种不同的图。
静态图(Static Diagram)包括用例图、类图、对象图、构件图和实施图。
- 用例图(use case diagram)描述系统功能，展现了一组用例、角色(一种特殊的类)及它们之间的关系。用例图给出系统的静态用例视图。这些图对于系统的行为组织和建模是非常重要的。
- 类图(class diagram)描述系统的静态结构，展现了一组对象、接口、协作和它们之间的关系。在面向对象系统的建模中所建立的最常见的图就是类图。
- 对象图(object diagram)描述系统在某个时刻的静态结构，展现了一组对象以及它们之间的关系。对象图描述了在类图中所建立的事物的实例的静态映射。
- 构件图(component diagram)描述实现系统的元素的组织，展现了一组构件之间的组织和依赖。它与类图相关，通常把构件映射成一个或多个类、接口或协作。
- 实施图(deployment diagram)描述系统环境元素的配置，展现了对运行时处理节点以及其中的构件的配置，它与构件图相关，通常一个节点包含一个或多个构件。
动态图(Dynamic diagram)包含状态图、活动图、顺序图、协作图。
其他行为模型
- 状态图(state chart diagram)描述系统元素状态条件和响应，它由状态、转换、事件和活动组成。它对于接口、类或协作的行为建模尤为重要，而且它强调对象行为的事件顺序。
- 活动图(activity diagram)描述系统元素的活动，是一种特殊的状态图，它展现了在系统内从一个活动到另一个活动的流程。活动图专注于系统的动态视图，它强调对象间的控制流程，对于系统的功能建模特别重要。
交互模型
- 顺序图（序列图）(sequence diagram)按时间顺序描述系统元素间的交互，是交互图。交互图(interaction diagram)展现了一种交互，它由一组对象和它们之间的关系组成，包括在它们之间可能发送的消息。
- 协作图（通信图）(collaboration diagram)按照时间和空间的顺序描述系统元素间的交互和关系，也是交互图，强调收发消息的对象的结构组织，顺序图和协作图是同构的，这意味着它们可以互相转换。
视图
- 用例视图(use case view)表达从用户角度看到的系统应有的外部功能，有时也叫用户模型视图。它用用例图来描述，有时也用活动图来进一步描述其中的用例。
- 逻辑视图(logicalview)主要用类图和对象图来描述系统的静态结构，它同时也描述对象间为实现给定功能发送消息时出现的动态协作关系，故称结构模型视图。动态行为用状态图、顺序图、协作图和活动图来描述。
- 并发视图(concurrent view)用于展示系统的动态行为及其并发性，也称行为模型视图。它用状态图、顺序图、协作图、活动图、构件图和实施图来描述。
- 构件视图(component view)展现系统实现的结构和行为特征，包括实现模块和它们之间的依赖关系，也称实现模型视图。构件视图用构件图来描述。
- 部署视图(deployment view)显示系统的实现环境和构件被部署到物理结构中的映射
11.1 试题1(2018年上半年试题1)
答案：A
解析：
对象：有意义的一切事物都是对象
- 它是系统用来描述客观事物的一个实体，是构成系统的一个基本单位。
- 对象包括：对象名，属性（静态特征）和方法（动态特征）
- 对象之间通过消息进行通信
11.2 试题2(2018年上半年试题2)
答案：B
解析：
（1）组合结构图（composite structure diagram）。组合结构图描述结构化类（例如，构件或
类）的内部结构，包括结构化类与系统其余部分的交互点。组合结构图用于画出结构化类的
内部内容。
（2）包图（package diagram）。包图描述由模型本身分解而成的组织单元，以及它们之间的
依赖关系。
（3）部署图（deployment diagram）。部署图描述对运行时的处理节点及在其中生存的构件
的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图。
（4）构件图（component diagram）。构件图描述一个封装的类和它的接口、端口，以及由内
嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的
部件构建大的系统来说，构件图是很重要的。构件图是类图的变体。
11.3 试题3(2018年上半年试题3-5)
答案：CDA
解析：
11.4 试题4(2018年上半年试题33-34)
答案：AB
解析：
11.5 试题5(2017年上半年试题1-2)
答案：CD
解析：
- is-a基于类继承或接口实现，is-a是表达这句话的一种方式：“这个东西是那个东西的一种”。例如：野马是一种马。
- has-a关系是基于用法（即引用）而不是继承。换句话说，如果类a中的代码具有对类b实例的引用，则“类a has-a类b”。例如：马有缰绳。
- is part of是一种整体与部分的关系。
11.6 试题6(2017年上半年试题3-4)
答案：AD
11.7 试题7(2017年上半年试题19-21)
答案：ABC
解析：
- 用户访谈：用户访谈是最基本的一种需求获取手段，其形式包括结构化和非结构化两种。用户访谈是通过1对1（或1对2，1对3）的形式与用户面对面进行沟通，以获取用户需求。用户访谈具有良好的灵活性，有较宽广的应用范围。但是，也存在着许多困难，例如，用户经常较忙，难以安排时间；面谈时信息量大，记录较为困难；沟通需要很多技巧，同时需要系统分析师具有足够的领域知识等。另外，在访谈时，还可能会遇到一些对于企业来说比较机密和敏感的话题。因此，这看似简单的技术，也需要系统分析师具有丰富的经验和较强的沟通能力。
- 采样是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。对于信息系统的开发而言，现有系统的文档（文件）就是采样种群。当开始对一个系统做需求分析时，查看现有系统的文档是对系统有初步了解的最好方法。但是，系统分析师应该查看哪些类型的文档，当文档的数据庞大，无法一一研究时，就需要使用采样技术选出有代表性的数据。采样技术不仅可以用于收集数据，还可以用于采集访谈用户或者是采集观察用户。在对人员进行采样时，上面介绍的采样技术同样适用。通过采样技术，选择部分而不是选择种群的全部，不仅加快了数据收集的过程，而且提高了效率，从而降低了开发成本。另外，采样技术使用了数理统计原理，能减少数据收集的偏差。但是，由于采样技术基于统计学原理，样本规模的确定依赖于期望的可信度和已有的先验知识，很大程度上取决于系统分析师的主观因素，对系统分析师个人的经验和能力依赖性很强，要求系统分析师具有较高的水平和丰富的经验。
- 联合需求计划：为了提高需求获取的效率，越来越多的企业倾向于使用小组工作会议来代替大量独立的访谈。联合需求计划（Joint Requirement Planning，JRP）是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发（Joint Application Development，JAD）的一部分
11.8 试题8(2017年上半年试题32)
答案：A
11.9 试题9(2016年上半年试题1)
答案：B
解析：
11.10 试题10(2016年上半年试题2)
答案：A
解析：
11.11 试题11(2016年上半年试题3-4)
答案：CC
解析：
11.12 试题12(2016年上半年试题5)
答案：D
解析：
在 OOA 方法中，构建用例模型一般需要经历四个阶段，分别是识别参与者、合并需求获得用
例、细化用例描述和调整用例模型，其中前三个阶段是必需的
11.13 试题13(2016年上半年试题34)
答案：C
解析：
首先从进程视图的动态性质可以了解到应用动态图，所以 A 与 B 可以直接排除，而 C 与 D
中，只有活动图能表达并发，所以应选活动图（活动图粗线引出的分支即为并发）。
11.14 试题14(2015年上半年试题1-2)
答案：AD
解析：
从总体上来看，UML 的结构包括构造块、规则和公共机制三个部分。
（1）构造块。UML 有三种基本的构造块，分别是事物（thing）、关系（relationship）和图（diagram）。事物是 UML 的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合。
（2）公共机制。公共机制是指达到特定目标的公共 UML 方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制四种。规格说明是事物语义的细节
描述，它是模型真正的核心；UML 为每个事物设置了一个简单的记号，还可以通过修饰来表达更多的信息；UML 包括两组公共分类，分别是类与对象（类表示概念，而对象表示具体的实体）、接口与实现（接口用来定义契约，而实现就是具体的内容）；扩展机制包括约束（扩展了 UML 构造块的语义，允许增加新的规则或修改现有的规则）、构造型（扩展 UML 的词汇，用于定义新的构造块）和标记值（扩展了 UML 构造块的特性，允许创建新的特殊信息来扩展事物的规格说明）。
（3）规则。规则是构造块如何放在一起的规定，包括为构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行
11.15 试题15(2015年上半年试题3-4)
答案：BC
11.16 试题16(2015年上半年试题5)
答案：C
解析：
通信图(communication diagram)在 UML1.X 中称为协作图，顺序图和通信图都是交互图(interaction diagram)。交互图展现了一种交互，它由一组对象或角色以及它们之间可能发送的消息构成。顺序图强调时序，通信图强调消息流经的数据结构。定时图(timing diagram)展现了消息交换的实际时间。活动图(activity diagram). 活动图将进程或其他计算的结构展示为计算内部一步步的控制流和数据流。
11.17 试题17(2015年上半年试题26)
答案：C
11.18 试题18(2015年上半年试题29)
答案：D
11.19 试题19(2015年上半年试题34)
答案：A
解析：
参考[https://www.cnblogs.com/silent2012/archive/2011/09/07/2169946.html]
11.20 试题20(2015年上半年试题35)
答案：C
11.21 试题21(2014年上半年试题1)
答案：A
解析：
11.22 试题22(2014年上半年试题2)
答案：B
解析：
参考：介绍
11.23 试题23(2014年上半年试题3-4)
答案：AD
解析：
11.24 试题24(2014年上半年试题20-21)
答案：AD
解析：
11.25 试题25(2014年上半年试题22)
答案：B
解析：
11.26 试题26(2014年上半年试题24-26)
答案：AAB
解析：
11.27 试题27(2014年上半年试题33-34)
答案：AC
解析：
11.28 试题28(2013年上半年试题1)
答案：C
解析：
11.29 试题29(2013年上半年试题2-3)
答案：BD
解析：
（1）事物:
事物是是实体抽象化的最终结果，是 UML 构建块最重要的组成部分，事物的分类如下:
- 结构事物
- 行为事物
- 分组事物
- 注释事物
结构事物:
结构事物是模型中的静态部分，用以呈现概念或实体的表现元素，是软件建模中最常见的元素，接下来是对结构化物件的简要描述：
- 类：类是指具有相同属性、方法、关系和语义的对象的集合；
- 接口：接口是指类或组件所提供的服务（操作），描述了类或组件对外可见的动作；
- 协作：协作定义元素之间的相互作用；
- 用例：用例定义了执行者（在系统外部和系统交互的人）和被考虑的系统之间的交互来实现的一个业务目标；
- 组件：组件描述物理系统的一部分；
- 节点：一个节点可以被定义为在运行时存在的物理元素；
行为事物:
行为事物指的是 UML 模型中的动态部分，代表语句里的 “动词”，表示模型里随着时空不断变化的部分，包含两类：
- 交互:交互被定义为一种行为，包括一组元素之间的消息交换来完成特定的任务。
- 状态机:状态机由一系列对象的状态组成，它是有用的，一个对象在其生命周期的状态是很重要的。
分组事物:
可以把分组事物看成是一个"盒子"，模型可以在其中被分解。目前只有一种分组事物，即包（package）。结构事物、动作事物甚至分组事物都有可能放在一个包中。包纯粹是概念上的，只存在于开发阶段，而组件在运行时存在。
- 包:封装是唯一一个分组事物可收集结构和行为的东西。
注释事物:注释事物可以被定义为一种机制来捕捉UML模型元素的言论，说明和注释。注释是唯一一个注释事物。
- 注释:注释用于渲染意见，约束等的UML元素。
11.30 试题30(2013年上半年试题4-5)
答案：AD
解析：
11.31 试题31(2013年上半年试题30-31)
答案：CD
解析：
11.32 试题32(2013年上半年试题32)
答案：A
解析：
11.33 试题33(2013年上半年试题33-34)
答案：DA
解析：
11.34 试题34(2012年上半年试题1)
答案：B
解析：
11.35 试题35(2012年上半年试题2-3)
答案：CD
解析：在UML中有两种类型的图：结构图和行为图。
- 结构图用来描述事物之间的关系，包括类图、对象图、组件图和部署图。
- 行为图用来描述参与者和用例之间的交互，或者描述参与如何使用系统，行为图包括用例图、顺序图、活动图、状态图和通信图。
11.36 试题36(2012年上半年试题24)
答案：D
解析：
系统分析阶段的基本任务是系统分析师在充分了解用户需求的基础上，把双方对待建系统的理解表达为系统需求规格说明书。
11.37 试题37(2012年上半年试题28-29)
答案：CA
解析：
11.38 试题38(2012年上半年试题61)
答案：D
解析：
用户的功能性需求发生变化时常需要对系统进行适应性维护，而不是调整系统性能。
11.39 试题39(2011年上半年试题27)
答案：BA
解析：
需求分析的过程，也叫做需求工程和需求阶段。包括需求开发和需求管理两个阶段。
需求开发阶段
- 情况收集
- 分析
- 制定规格说明
- 评审
需求管理阶段
- 变更控制
- 版本控制
- 需求跟踪
- 需求状态跟踪
11.40 试题40(2011年上半年试题28)
答案：C
解析：C选项已经涉及到了系统的设计与实现，因而不属于需求开发活动的范畴。
11.41 试题41(2011年上半年试题29)
答案：B
解析：参考上题
11.42 试题42(2011年上半年试题30-32)
答案：BCA
解析：
软件需求包括三个不同的层次：业务需求、用户需求、功能需求。
- 业务需求：反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
- 用户需求：描述了用户使用产品必须要完成的任务，这在用例文档或方案脚本说明中予以说明。
- 功能需求：定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
11.43 试题43(2010年上半年试题1)
答案：D
解析：
1、用例描述业务场景或事件，系统必须对这些场景或事件提供确定的响应，是用例图的主要结构元素，用例图用来描述系统与外部熊以及用户之间的交互视图。
2、类是共享相同属性喝行为的对象集合，是类图的主要组成元素，类图是系统静态对象结构的图形描述。
3、抽象用例通过组合几个用例公共的步骤降低用例之间的冗余，抽象类是包含一种或多种抽象方法的类，它本身不需要构造实例。
11.44 试题44(2010年上半年试题3)
答案：B
解析：
1、顺序图用例描述对象按照时间顺序的消息流来建模用例；
2、数据流图是一种描述数据通过系统的流程以及系统实施的工作或处理过程的过程模型；
3、流程图以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程。
11.45 试题45(2010年上半年试题19)
答案：D
解析：
需求是软件项目成功的核心所在，它为其他许多技术和管理活动奠定了基础。在软件需求工程中，需求管理贯穿整个过程。需求管理最基本的任务是明确需求，并使项目团队和用户达成共识，即建立需求基线。
11.46 试题46(2010年上半年试题20)
答案：C
解析：
需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。常见需求获取 方式有用户访谈、问卷调查、抽样和联合需求计划。根据题干描述，应该采用抽样的方法。
11.47 试题47(2010年上半年试题53)
答案：C
放假毁所有，眼看就要考试了，可进度赶不上去鸭
