软考讲课中暴露出了几个问题，其实这几个问题都是一个问题——我对ＵＭＬ的了解不够深。做题的时候我根据自己的理解把题做对了我就认为我理解的没错，可是表达出来大家不懂我的意思，因为是我自己的理解没有权威性我也不敢给大家保证就是没错；还有的就是对某个知识点有了异议；甚者对同学们提出的问题我就压根没有准备到。下面是我对这次讲课涉及到的内容进一步做的总结，希望能帮到大家
１.ＵＭＬ图
讲课的时候大家问我每种图分别出现在哪个设计阶段，当时也是没有给大家一个完美的答复，下来找了UML书，书中表明各种图并没有绑定到软件开发的各个阶段，这个是没有严格的划分界限的，UML图和文档不是一一对应的，除了几个核心图（用例图，类图）其他都是可以在任何文档中出现的，比如：需求分析阶段，主要是使用用例图，概要设计和详细设计书中可以由UML中类图，状态图，活动图，顺序图填充，而在其他文档中根据实际需要适当填充UML图
翻了翻做过的几套题发现上午题涉及到的ＵＭＬ这部分知识，考的形式是某种图是用来干什么的。如：（？）显示了类及其相互关系，所以说大家一定要了解常见的九种图的用途，总结如下：
分类
定义
（1）类图(ClassDiagram)
类图描述系统所包含的类、类的内部结构及类之间的关系；
（2）对象图(ObjectDiagram)
对象图类似类图，但并不描述对象类，它们对实际的对象实例建模—显示实例属性的当前值；
（3）组件图(CompomentDiagram，也称构件图)
组件图描述代码部件的物理结构以及各部件之间的依赖关系；
（4）部署图(DeploymentDiagram)
部署图定义系统中软硬件的物理体系结构；
（5）用例图(UsecaseDiagram)
用例图以图形化的方式描述系统与外部系统及用户的交互。换句话说，它们以图形化的方式描述了谁将使用系统，以及用户期望以什么方式与系统交互；
（6）序列图(Sequence Diagram)
是场景的图形化表示 ，描述以时间顺序组织的对象之间的交互活动；
（7）协作图(CollaborationDiagram)
合作图描述对象之间的协作关系，强调收发消息的对象的结构组织，类似序列图，但重点不是消息的时间顺序，它以一种网状格式表现对象之间的交互；
（8）状态图(StatechartDiagram)
对一个特定对象的动态行为建模，说明一个对象的生命周期---对象可以经历各种状态，以及引起对象从一个状态向另一个状态转换的事件；
（9）活动图(ActivityDiagram)
活动图是一种特殊的状态图，它展示了在系统内从一个活动到另一个活动的流程。
2.UML关系
定义
（1）依赖
其中一个事物（独立事物）发生变化会影响另一事物（依赖事物）的语义
（2）关联
两个相对独立的系统，当一个系统的实例与另一个系统的一些特定实例存在固定的对应关系，这两个系统之间为关联关系。关联关系包括单向关联、双向关联、聚合关联、合成关联、反射关联关系
下面介绍一下多重度，试题中喜欢在这做文章
UML中关联的多重度是指一个类的实例能够与另一个类的多少个实例相关联。关联表示了对象间的结构关系，在很多建模问题中，说明一个关联的实例中有多少个互相连接的对象是很重要的。这个“多少”被称为关联角色的多重度， 指定关联一端的多重度，就是说明：在关联另一端的类的每个对象要求在本端的类必须有多少个对象。
注：0..*与*表达的意思一样
（3）聚合
是一种特殊类型的关联，它描述了整体和部分间的结构关系。在一个聚合关系中，子类可以独立于父类生存。例如：车子与铃铛，铃铛可以独立于车子生存
（4）组合
是一种特殊类型的关联，也表示类之间整体与部分的关系，但是组合关系中部分和整体具有统一的生存期，一旦整体对象不存在了，部分对象也将不存在。部分对象与整体对象之间有同生共死的关系。例如：桌子和桌面
组合与聚合的区别：聚合关系是“has -a”关系，组合关系是“contains-a”关系，聚合关系表示整体与部分的关系不如组合关系强
（5）泛化
是一种特殊/一般关系，在其中特殊元素（子元素）基于一般元素（父元素）而建立。用这种方法，子元素共享了父元素的结构和行为（也就是说“子元素”继承了“父元素”）表示类与类之间的继承关系，接口与接口之间的继承关系，或类对接口的实现关系。一般化关系是子类指向父类的，或从实现接口的类指向被实现的接口，与继承或实现的方向相反。
（6）实现
是类目之间的语义关系，其中的一个类目指定了由另一个类目保证执行的合约。在两种地方会遇到实现关系：一种是在接口和实现它们的类或构件之间；另一种是在用例和实现它们的协作之间
强度比较： 泛化=实现>组合>聚合>关联>依赖
3.包含与扩展
（1）包含
包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
（2）扩展
将基用例中一段相对独立并且可选的动作，用扩展用例加以封装，再让它从基用例中声明的扩展点上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。
4. 总结：
从真题中发现下午题中UML这一题的最后一题往往会问这些关系的内涵，也就是让你说一下他们的定义，你再说上句他们的优点就更完美了，至于那些让你填参与者，用例，类啊什么的你要根据图中的已知的关系去题目中找，前边的说明说的很详细，如果细心一些这些是没问题的。