一、UML(Unified Modeling Language)统一建模语言。其结构如下
二、详解（因为历年软考题主要出用例图和类图（多重度问题），所以本文主要回忆这两个图）
1、用例图
解析：用例模型描述的是外部执行者所理解的系统功能。用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成共识。
用例三要素：参与者（Actor）、用例（Use Case）、包含和扩展（Include and Extend）
在历年的软考下午题中都会考到用例图，题型大部分为填用例或参与者，遇到这样的问题只要是仔细读题的都可以作对，还有一个考点就是填关系名称。用例图中的关系主要是包含和扩展。下面举例说明什么是包含和扩展。
引用于《http://www.cnblogs.com/fan0136/archive/2008/12/14/1354730.html》
（1）包含(include)
包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。
（2）扩展(extend)
扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。
对于一个扩展用例，可以在基用例上有几个扩展点。
例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：
用例图做题中药注意的几点：
①正确识别参与者：角色不仅可以由人承担，还可以是其它系统、硬件设备，甚至是时钟。
②参与者一定在系统之外，不是系统的一部分。
2、类图和对象图
解析：所谓类是一类具有相同特征的对象的描述。对象是类的实例。类由类的名字、属性、操作构成。分别分布在三格上中下的位置。
重点一：类之间的关系
①依赖关系（dependency）
有两个元素X，Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖于元素X。用带箭头的虚线表示依赖关系
引起依赖的原因有一个类向另一个类发送消息；一个类是另一个类的数据成员；一个类是另一个类的某个操作参数等。
②泛化关系（Generalization）
泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说子类是从父类中继承的，而父类则是子类的泛化。使用带空心箭头的实线表示，箭头指向父类。
③关联关系（association）
关联表示两个类之间存在某种语义上的联系。例如，一个人为一家公司工作，一家公司有许多办公室。那么人和公司、公司和办公室之间存在某种语义关系。
关联关系提供了通信的路径，它是所有关系中最通用、语义最弱的。用一条实线来表示。
3.1聚合关系（aggregation）
聚合是一种特殊形式的关联。聚合表示类之间的关系式整体与部分的关系。例如一个轿车包含4个车轮、一个方向盘、一个发动机和一个底盘，这就是聚合。用一个带空心菱形的实线表示
3.2组合关系（composite）
如果聚合关系表示部分的类的存在，与表示整体的类有着紧密的关系，例如公司和部门之间的关系，那么就应该使用组合关系来表示。在UML中使用带有实心菱形的实线表示
④实现关系（Implementation ）
实现关系式用来规定接口和实现接口的类或组件之间的关系。接口是操作的集合，这些操作作用于规定类或组件的服务、用带有空心箭头的虚线表示
重点二：多重度问题
最常见的多重性有：0..1 ; 0..* ; 1..1 ; 1..* ; *
多重性用来说明关联的两个类之间的数量关系，例如：
- 书与借书记录之间的关系就应该是1对0..1的关系，也就是一本书可以有0或者1个借书记录；
- 经理与员工之间的关系则应为1对0..*的关系，也就是一个经理可以领导0个或多个员工；
- 学生与选修课程之间的关系就可以表示为0..*对1..*的关系，也就是一个学生可以选择1门或多门课程，而一门课程有0个或多个学生选择。
软考UML部分的基础分析的部分就到这里，具体在做题的时候一定要认真审题，不要错过任何信息，也不要自以为是，要以题干为基础进行分析。在历年的UML题型中，大部分会考到以下几部分：
【问题一】（5分）根据说明中的描述，给出图中A1和A2..An所对应的参与者,U1和U2..Un所对应的用例，以及（1）、（2)..(n)中所对应的关系。
仔细审题圈出能做出操作的参与者，根据具体题干进行填空。在题干中寻找动宾短句，根据题意填空。这几分是很容易得到的，但是还是要细心，如果填反了一样没有分。
至于填关系的题，不是《include》就是《extend》，所以要分析题干，根据上文对包含和扩展关系的分析来填空。还有一个技巧就是如果箭头万众归一，指向大的用例，则一般都是扩展，如果是万箭齐发，指向小的用例，则大部分都是包含。
【问题二】（7分）根据说明中的描述，给出图中缺少的C1~Cn所对应的类名以及（3）~（n）处所对应的多重度。
本题找对应的类名不是难点，难点是容易弄反，所以还是要细心。难点还有多重度的分析，每次做模拟题都会错一两个，一个就是1分，这分好得也好丢，关键看题干分析，只要是认真细心的人就一定会分析正确，如果懒得思考的人就很难做对。考试的时候是现场直播，没有演习，所以要付出百分百的脑力去分析它，啃透它消化它。
【问题三】（3分）图中的类图设计采用了某某设计模式，请说明该模式的内涵。
多么无耻的出题者啊，光是有设计模式的大题、上午题还是不过瘾，还嵌在UML里一道题。23个设计模式虽然看类图能回想起来设计模式的内涵但是就是有人无法用具体的语句来描述出来。这就是得靠总结，靠背。真烦！这也是UML题不能得满分的原因。
总结这么多，还是一点，做UML题就是要心细、细心的分析。
