软考下午题详解---uml图

        在上篇博客中，小编主要简单的对软考下午题当中的数据流图设计进行了一系列总结，今天我们继续来看软考下午题当中大题部分，uml图的相关知识，在我们学习的过程中，我们也已经接触过，西安交大刘惠老师讲解过uml的相关知识点，我们学习完了之后画了一套机房收费系统的uml图，那时年少，画的图太过稚嫩，画的图一遍又一遍的让师傅验收，一次又一次的修改，终于在14年的春节绽放她的笑颜，后来在个人重构、机房合作中和uml也陆陆续续的打过交道，就是在这样一个反复的过程中，小编对uml图的理解一步又一步的加深，学习呢，本来就是一个反复的过程`(*∩_∩*)′，后来，小编在软考中又再一次与uml图相遇但是没有擦肩哦，uml是如何在软考中彰显她的美丽呢，好的，我们首先来看这样一张图：

          

         接下来，小编就随着上面思维导图的历史脉络，一一对各个知识点进行击破，让小伙伴们在软考中游刃有余，首先我们来看第一个知识点，uml的结构。

         uml结构

         

        如上面思维导图所展示的，uml的构造块包括三个方面内容，其中的图就是我们通常所说的uml的九种图形，可以分为两类，一个是静态模型，另一个动态模型，静态模型有类图，构件图，部署图，动态模型有对象图，用例图，顺序图，协作图，状态图和活动图。还有一种图叫做包图，包图是类的集合。在公共机制里，指的是达到特定目标的一些公共的uml的方法，主要包括规格说明，修饰，公共分类和扩展机制。接下来就是我们的重头戏了，uml的九种图形，在前面的学习中，小编写过一系列关于uml的博客，为此申请了一个专栏，其中对每个图形进行了详细的阐述，有需要的小伙伴可以去看看哦，今天再次看见那个曾经熟悉的她，她又会带给小编怎样的惊喜和期待呢，随小编娓娓道来。

         uml图

         uml图之用例图

         什么是用例nie，就是在系统中执行的一系列的动作。用例模型描述是外部执行者所理解的系统功能，用例模型主要用于系统分析阶段，她的建立是系统开发者和用户反复讨论的一个结果，表明了开发者和用户对需求规格达成的共识。外部行为指的可能是使用用例的人，也可能是外部的系统，所以有可能是系统也可能是人，执行者不一定是人。在uml中，用例用椭圆来表示，如图是一个简单的图书管理系统的用例图。在用例图中，两个用例之间可能存在关系，主要有两个包含关系和扩展关系。包含关系：当可以从两个或两个以上的用例当中提取公共行为，或者是发现能够使用一个构件，来实现某一个用例的一部分功能，这个时候使用包含关系。用inculude表示，如下所示：

        

       查询、修改、删除三个用例都有一个公共的行为登录，也就是在某个查询信息当中，查询信息，修改信息，删除信息的前提条件是输入用户名和密码登录系统之后，才能进行相关的操作，所以登录是查询、修改和删除这三个用例的公共行为，所以需要单独提出来，所以登录与这三个用例的关系就是include的关系，用include表示，用一个箭头指向被包含的用例，其中，把登录这个用例称为抽象用例，可以理解为从查询，修改和删除三个用例中抽象得出来的用例，这是包含关系。当若干个用例当中有共同的行为的时候，把共同的部分抽取出来，组成一个用例。第二个关系扩展关系：指的是一个用例明显的混合了两种或者两种以上的不同场景，或者是根据情况可能会发生多种事情，
       这个时候，我们就可以将这个用例分为一个主用例和一个或多个辅助用例来描述，这样更加清晰。这样两个用例之间的关系用extend来表示。修改数据信息和查询数据信息，显然，要修改书籍信息，首先要查询数据信息，查询出来以后，看到有关结果来进行修改，这两个用例我们可以合成一个用例就叫修改书籍信息，但是我们刚才讲了，这个大的修改包括先查询后修改，其实是包括了两种详情，所以应该分开包括查询书籍信息和修改书籍信息，这样一样，他们之间的关系是扩展关系。

        uml之类图和对象图

        首先我们来看下面这张图：

         

        在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图之交互图

        交互图分为两种，顺序图和协作图，交互图：表示各组对象如何按照某一种行为进行协作的一个模型。在uml图中，交互图包括顺序图和协作图。从本质上来说，顺序图和协作图没有区别，但是在版式上的排版有所不同，所以一般把顺序图和协作图统称为交互图。我们先来看顺序图：

       

       顺序图也叫序列图，他是用来描述对象之间动态的交互关系，体现的是对象之间消息传递的时间顺序，强调的是时间顺序，谁在前，谁在后，顺序图直观的表现了对象的生存期，在生存期内，对象可以对输入的消息做出响应，并且可以发送信息，如图，三个对象，客户，工厂和产品，有七个交互序列，按照时间排列，强调的是一种顺序，是时间的先后，虚线叫做对象的生命线，所以顺序图强调的是一种先后顺序，说明了对象之间的交互过程以及系统执行过程当中，在某一个具体的位置将会发生的事情。生命线上的小矩形表示对象已经被激活。

         我们再来看协作图，如下所示，是一张协作图的图片：

         

        协作图，用于描述相互合作的对象之间，他的交互关系和连接关系，协作图和顺序图本质上是一样的，只是表现的形式不一样。协作图和顺序图都是用来表示对象之间的交互关系，但是他们的侧重点不一样，顺序图，着重体现的是交互的时间顺序，协作图着重体现的是交互对象之间的静态连接关系，协作图是用来展示对象之间的动作的协作关系，所以协作图能够消息的编号来表示消息的顺序。一般来讲，如果强调时间和顺序的话，使用顺序图，如果强调的是上下级的关系，选择协作图。

        uml图之状态图

        

        用来描述对象，状态和事件之间的一种关系，那么通常是用状态图来描述单个对象的行为，他确定了由时间序列所引出的状态序列，但是并不是所有的类都需要状态来来进行描述，那么究竟哪些类，需要使用状态图nie？一般来讲，只有那些具有重要交互行为的类才需要使用状态图来描述，如上图的订单状态图。状态分为初始状态，结果状态和状态转移，初始状态也就是初态，用一个黑色圆心表示，在一个状态图中，只能有一个初始状态。结果状态也叫终态，用黑色圆心再在外面套上一个圆来进行表示，表示状态的结束，在一个状态图当中，可能有多个结束状态。一个起始状态多个结束状态。中间的部分表示状态的转移。用箭头表示状态转移的情况，箭头上面的文字来表示引发这个状态变化的相应事件是什么。
        状态图从理论上来讲，适合表达不同用例之间的对象的行为，但是并不适合于包括若干个对象协作的行为。他是单个对象的行为。状态图是对类图的补充。他说明这个类的对象所有可能的一个状态以及哪些事件将导致状态的改变。在实际建模当中，不是所有的类都需要状态图。只是为那些有多个状态行为受到外界环境的影响并且发生改变的类来画状态图。

        uml图之活动图

         

         如上所示，是一张活动图的图片，活动图用来表示系统中各种活动的次序，应用较广，既可以用来描述用例的工作流程，也可以用来描述类当中某个方法的操作行为。活动图是由状态图变化而来的。所以活动图所描述的是满足用例要求所要进行的活动以及活动之间的约束关系。在活动图当中也是有一个起始状态和一个终止状态。一个活动到另外一个活动，就发生了状态的迁移。活动图有两种，一种是基本的活动图，另外一种是带泳道的活动图，上图所示的是基本的活动图，表示是活动之间的递推关系。在基本的活动图当中，我们可以描述系统发生了什么，但是没有办法说明完成这个活动的对象是什么，而对于面向对象的程序设计语言而言，这就意味着活动图没有准确描绘出各个活动是由哪个类来完成的，没有主体，解决这个问题，引进泳道，如下所示：

       

       犹如游泳比赛的时候的泳道，由上图很容易的看出来，各个活动是由哪个类来完成的，明确了活动的主体。这种图叫做带泳道的活动图。我们从活动图来看，会发现uml的活动图和我们传统的数据流程图是有一定的相似性的，程序流程图是明确的指定了每个活动的先后顺序，而活动图只是描述了活动和必要的工作顺序，这是活动图和流程图的根本区别。

        uml图之构件图

         

         构件图，显示一组构件，以及构件之间的关系，构件图中包括构件，接口以及各种关系，图中，四个构件。通过构件图，我们可以完成四个方面的工作：
        a、是对源代码进行建模，可以清晰的表示出各个不同的源程序文件之间的关系。
        b、是对可执行体的发布建模。
        c、对物体数据库建模。
        d、对系统建模。

        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，活出自己的精彩！