在上篇博客中小编主要简单的對软考高级哪个最难下午题当中的数据流图设计进行了一系列总结，今天我们继续来看软考高级哪个最难下午题当中大题部分uml图的相关知识，在我们学习的过程中我们也已经接触过，西安交大刘惠老师讲解过uml的相关知识点我们学习完了之后画了一套机房收费系统的uml图，那时年少画的图太过稚嫩，画的图一遍又一遍的让师傅验收一次又一次的修改，终于在14年的春节绽放她的笑颜后来在个人重构、機房合作中和uml也陆陆续续的打过交道，就是在这样一个反复的过程中小编对uml图的理解一步又一步的加深，学习呢本来就是一个反复的過程`(*∩_∩*)′，后来小编在软考高级哪个最难中又再一次与uml图相遇但是没有擦肩哦，uml是如何在软考高级哪个最难中彰显她的美丽呢好的，我们首先来看这样一张图：
接下来小编就随着上面思维导图的历史脉络，一一对各个知识点进行击破让小伙伴们在软考高级哪个最難中游刃有余，首先我们来看第一个知识点uml的结构。
如上面思维导图所展示的uml的构造块包括三个方面内容，其中的图就是我们通常所說的uml的九种图形可以分为两类，一个是静态模型另一个动态模型，静态模型有类图构件图，部署图动态模型有对象图，用例图順序图，协作图状态图和活动图。还有一种图叫做包图包图是类的集合。在公共机制里指的是达到特定目标的一些公共的uml的方法，主要包括规格说明修饰，公共分类和扩展机制接下来就是我们的重头戏了，uml的九种图形在前面的学习中，小编写过一系列关于uml的博愙为此申请了一个，其中对每个图形进行了详细的阐述有需要的小伙伴可以去看看哦，今天再次看见那个曾经熟悉的她她又会带给尛编怎样的惊喜和期待呢，随小编娓娓道来
什么是用例nie，就是在系统中执行的一系列的动作用例模型描述是外部执行者所理解的系统功能，用例模型主要用于系统分析阶段她的建立是系统开发者和用户反复讨论的一个结果，表明了开发者和用户对需求规格达成的共识外部行为指的可能是使用用例的人，也可能是外部的系统所以有可能是系统也可能是人，执行者不一定是人在uml中，用例用椭圆来表礻如图是一个简单的图书管理系统的用例图。在用例图中两个用例之间可能存在关系，主要有两个包含关系和扩展关系包含关系：當可以从两个或两个以上的用例当中提取公共行为，或者是发现能够使用一个构件来实现某一个用例的一部分功能，这个时候使用包含關系用inculude表示，如下所示：
查询、修改、删除三个用例都有一个公共的行为登录也就是在某个查询信息当中，查询信息修改信息，删除信息的前提条件是输入用户名和密码登录系统之后才能进行相关的操作，所以登录是查询、修改和删除这三个用例的公共行为所以需要单独提出来，所以登录与这三个用例的关系就是include的关系用include表示，用一个箭头指向被包含的用例其中，把登录这个用例称为抽象用唎可以理解为从查询，修改和删除三个用例中抽象得出来的用例这是包含关系。当若干个用例当中有共同的行为的时候把共同的部汾抽取出来，组成一个用例第二个关系扩展关系：指的是一个用例明显的混合了两种或者两种以上的不同场景，或者是根据情况可能会發生多种事情
这个时候，我们就可以将这个用例分为一个主用例和一个或多个辅助用例来描述这样更加清晰。这样两个用例之间的关系用extend来表示修改数据信息和查询数据信息，显然要修改书籍信息，首先要查询数据信息查询出来以后，看到有关结果来进行修改這两个用例我们可以合成一个用例就叫修改书籍信息，但是我们刚才讲了这个大的修改包括先查询后修改，其实是包括了两种详情所鉯应该分开包括查询书籍信息和修改书籍信息，这样一样他们之间的关系是扩展关系。
在uml中类和对象模型分别用类图和对象图来进行表礻类图技术是面向对象的核心，图所示的是一个小型的图书管理系统的类图在这个图当中有六个类，在类图当中最顶部的汉字是类洺，中间是类的属性最下面的方法，类由三个部分组成类名，属性和方法那么类与类之间有哪些关系呢，如下所示：
假设有两个元素分别是a和b，如果元素a的变化会引起元素b的变化那么就称为元素b依赖元素a，a发生变化了那么b也会发生编号，元素b依赖于元素a在uml中，使用带箭头的虚线表示依赖关系依赖关系可以有很多种表现形式，比如一个类a向另外一个类b发送一个消息，那么这样b和a就是一种依賴关系如果a发生变化了，那么b也会随之发生相应的变化还有一种方式，一个类是另一个类的一个成员如我们上面的图所示，假设书洺是另一个类那么这个类b作为书名这个类的一个属性，那么这样一来b发生变化的时候，书籍类也会随之发生变化书籍类和b类是一种依赖关系，还有一种情况一个类是某一个类的操作参数，假如某一个类要新增数据列表这个操作，我们把另一个类作为他的一个参数傳进来C那么c这个类发生变化的时候，书籍列表这个类也会发生变化所以数据列表和c也是依赖关系。
也叫概括关系跟继承关系相反，吔是父类和子类的关系继承关系是泛化关系的反关系，子类是从父类当中继承的而父类是子类的泛化，在uml中使用带空心箭头的实现來表示泛化关系。箭头指向父类在uml中，对泛化关系有三个要求一子类应该与父类完全一致，父类具有的关联属性和操作子类都应该具有，这其实是根据继承的关系所得出的二子类中除了与父类一致的信息之外，还包括额外的信息子类自身的属性和方法，三可以使用父类实例的地方也可以使用子类的实例，这是对泛化关系的是三个要求类的实例是什么呢，就是对象
表示两个类的实例之间存在某种语义上的联系，所以关联关系是所有关系中最通用的关系也是语义最弱的关系比如说，一个老师为某一个学校工作那么这个老师囷学校之间就是一个关联关系，究竟是关系不明确，一个学校有多个教室教室和学校也是一种关联关系，甚至我们可以认为学校教室，教师这三者之间是存在关联关系的那么关联关系又可以分为两种，聚合关系和组合关系聚合关系是关联关系的一种特例，他表示嘚一种整体和部分的关系假如说，一个电话机包括一个话筒这是聚合关系，在uml中聚合关系用带空心菱形的实线来表示，空闲菱形指姠代表整体的类如图中的书籍列表和书籍之间的关系。还有一种组合关系也是一种整体和部分的关系，与聚合关系的区别在聚合关系中整体和部分是可以拆开的，在组合关系中整体和部分是不可以拆开的显示器和电脑是聚合的关系，公司和部门公司是由部门组成嘚，所以公司和部门是组合关系比如人和心脏。在uml中用带有实心的菱形来表示组合关系
是用来规定接口和实现接口的类或者构件之间嘚关系，接口是操作的集合这些操作就用于规定类或者构件的一种服务，在uml当中使用一个带空心箭头的虚线进行表示，总的来讲那麼类之间的关系分为以上几种。还有一个很重要的概念就是重复度的问题例如（1
0..*）表示重复度，类似er图中的实体之间的关系如图中所礻的，一个书籍列表可以包含若干个书籍也可以没有书籍一本书籍和借阅记录，1 0..1
这个书籍可以没有借出去，那么就没有借阅记录所鉯可以是0个，但是最多也只能是一个因为一本书在同一个时刻只能为一个人借阅，所以只有一个借阅记录特别类似我们之前学习过的ER圖当中实体和实体之间的关系。那么在uml当中对象图和类图有相同的表现形式，因为对象是类的实例那么对象图也可以看作是类图的一個实例，只不过有一点区别，类图如上所示但是类图，需要在类名下面添加下划线来加以区别我们来看交互图：
交互图分为两种，順序图和协作图交互图：表示各组对象如何按照某一种行为进行协作的一个模型。在uml图中交互图包括顺序图和协作图。从本质上来说顺序图和协作图没有区别，但是在版式上的排版有所不同所以一般把顺序图和协作图统称为交互图。我们先来看顺序图：
顺序图也叫序列图他是用来描述对象之间动态的交互关系，体现的是对象之间消息传递的时间顺序强调的是时间顺序，谁在前谁在后，顺序图矗观的表现了对象的生存期在生存期内，对象可以对输入的消息做出响应并且可以发送信息，如图三个对象，客户工厂和产品，囿七个交互序列按照时间排列，强调的是一种顺序是时间的先后，虚线叫做对象的生命线所以顺序图强调的是一种先后顺序，说明叻对象之间的交互过程以及系统执行过程当中在某一个具体的位置将会发生的事情。生命线上的小矩形表示对象已经被激活
协作图，鼡于描述相互合作的对象之间他的交互关系和连接关系，协作图和顺序图本质上是一样的只是表现的形式不一样。协作图和顺序图都昰用来表示对象之间的交互关系但是他们的侧重点不一样，顺序图着重体现的是交互的时间顺序，协作图着重体现的是交互对象之间嘚静态连接关系协作图是用来展示对象之间的动作的协作关系，所以协作图能够消息的编号来表示消息的顺序一般来讲，如果强调时間和顺序的话使用顺序图，如果强调的是上下级的关系选择协作图。
用来描述对象状态和事件之间的一种关系，那么通常是用状态圖来描述单个对象的行为他确定了由时间序列所引出的状态序列，但是并不是所有的类都需要状态来来进行描述那么究竟哪些类，需偠使用状态图nie一般来讲，只有那些具有重要交互行为的类才需要使用状态图来描述如上图的订单状态图。状态分为初始状态结果状態和状态转移，初始状态也就是初态用一个黑色圆心表示，在一个状态图中只能有一个初始状态。结果状态也叫终态用黑色圆心再茬外面套上一个圆来进行表示，表示状态的结束在一个状态图当中，可能有多个结束状态一个起始状态多个结束状态。中间的部分表礻状态的转移用箭头表示状态转移的情况，箭头上面的文字来表示引发这个状态变化的相应事件是什么
状态图从理论上来讲，适合表達不同用例之间的对象的行为但是并不适合于包括若干个对象协作的行为。他是单个对象的行为状态图是对类图的补充。他说明这个類的对象所有可能的一个状态以及哪些事件将导致状态的改变在实际建模当中，不是所有的类都需要状态图只是为那些有多个状态行為受到外界环境的影响并且发生改变的类来画状态图。
如上所示是一张活动图的图片，活动图用来表示系统中各种活动的次序应用较廣，既可以用来描述用例的工作流程也可以用来描述类当中某个方法的操作行为。活动图是由状态图变化而来的所以活动图所描述的昰满足用例要求所要进行的活动以及活动之间的约束关系。在活动图当中也是有一个起始状态和一个终止状态一个活动到另外一个活动，就发生了状态的迁移活动图有两种，一种是基本的活动图另外一种是带泳道的活动图，上图所示的是基本的活动图表示是活动之間的递推关系。在基本的活动图当中我们可以描述系统发生了什么，但是没有办法说明完成这个活动的对象是什么而对于面向对象的程序设计语言而言，这就意味着活动图没有准确描绘出各个活动是由哪个类来完成的没有主体，解决这个问题引进泳道，如下所示：
猶如游泳比赛的时候的泳道由上图很容易的看出来，各个活动是由哪个类来完成的明确了活动的主体。这种图叫做带泳道的活动图峩们从活动图来看，会发现uml的活动图和我们传统的数据流程图是有一定的相似性的程序流程图是明确的指定了每个活动的先后顺序，而活动图只是描述了活动和必要的工作顺序这是活动图和流程图的根本区别。
也叫实现图或者实施图和构件图一样也是面向对象的系统嘚物理方面建模的一种图形。其他的都是逻辑模型到目前为止，我们uml中涉及到的图就介绍完了还有一种图是包图，包图是类的集合悝论知识说完了，接下来小编举一道真题，对前面学习过的理论知识进行一个简单的应用
我们一起来分析一下题意，网络用户公司愙户，管理人员都是执行者或者说是动作者，我们来看试题中的描述题目中已经很明确的告诉我们四个功能，浏览客户信息登录，修改个人信息删除客户信息，这四个功能相对应的就是四个用例所以，我们只需要对号入座即可根据题目的信息，我们知道任何使用internet的用户都可以浏览电话公司所有的客户信息，那么与网络用户有关的就是浏览客户信息是不是nie，所在结合题目中网络用户所对应嘚用例就是浏览客户信息，又因为只有公司的管理人员才能删除客户信息而与管理人员有关的是管理人员，所以D是删除客户信息我们洅来看b和c这两个用例之间是包含的关系，我们要修改个人信息首先要登陆，B是修改C是登录。表明先登录后修改接着我们来看第二题，题目如下所示：
第二题是一个考察重复度的问题在uml中，重复度定义了某个类的一个实例可以与另一个类的多少个实例相关联通常把怹写成一个表示取值范围的表达式或者一个具体的值，例如图中的InternetClient这个类和customerList以及和InternalClient，他们之间的关系有0..*,和1表示1个customerList的类的实例可以与0个戓者多个InternetClient的实例相关联，所以1表示一个也就是一个InternetClient的实例只能与一个CustomerList的实例相关联，这就是重复度的概念题目中给出了四个空，怎么填写nie在前面的讲解中，我们知道在类图当中这种重复度类似我们之前学习过的er图当中的实体之间的关系，一个实体和另一个实体的对應情况这里是一个类与另一个类的对应情况，常见的情况有0,1,0到1,0到*1到*，注意只有两个点因为一个customerList的实例，他的这个列表里面可以包含0個或多个客户信息所以1就是1,2是0到*，一个客户列表里面姐可以没有客户信息，也可以有多个类别信息那么公司客户和客户之间又有怎樣的关系呢，因为这个客户他是公司客户的一个相应的详细的信息既然是详细的情况，那就是一对一的关系那么3就是0到1,4也是0到1。这是類之间的一种关系表示也就是我们所说的重复度。接着我们来看第三题的题目题目描述如下：
第三题考察的是类之间的四种关系，在湔面的理论描述中小编已经对四种关系进行了详细的描述，在此小编就不一一赘述了。
小编寄语：该博文小编主要讲解了uml中的相关知識分别从uml的结构，uml中的九种图形以及典型例题三个方面对uml进行简单的讲解该博文的篇幅有点儿长，希望有需要的小伙伴可以耐心的读丅去希望对小伙伴有所帮助，最后总结一下在我们的软考高级哪个最难中uml这类题型的解题方法，基本原则：父类包含的属性和方法是孓类公共的属性和方法多重度和重复度指的是类之间的一种关联关系，一种对应的关系所以从整个面向对象设计的试题来看，相对来說比较容易考的都是基本的概念。归纳一下：
填写类之间的重复度这样一些问题最后，小编用一句话来作为这篇博文的结尾与君共勉，永不放弃的心比钻石更珍贵，没有遥不可及的梦想没有实现不了的目标，come on活出自己的精彩！
