uml_uml类图 - CSDN
uml 订阅
统一建模语言(Unified Modeling Language,UML)是一种为面向对象系统的产品进行说明、可视化和编制文档的一种标准语言,是非专利的第三代建模和规约语言。UML是面向对象设计的建模工具,独立于任何具体程序设计语言。 [1] 展开全文
统一建模语言(Unified Modeling Language,UML)是一种为面向对象系统的产品进行说明、可视化和编制文档的一种标准语言,是非专利的第三代建模和规约语言。UML是面向对象设计的建模工具,独立于任何具体程序设计语言。 [1]
信息
作品别名
标准建模语言
作    用
支持模型化和软件开发
产    源
OOA&D,OOAD
外文名称
UML
作品名称
统一建模语言
创作年代
1997年
统一建模语言简介
UML作为一种统一的软件建模语言具有广泛的建模能力。UML是在消化、吸收、提炼至今存在的所有软件建 模语言的基础上提出的,集百家之所长,它是软件建模语言的集大成者。UML还突破了软件的限制,广泛吸收了其他领域的建模方法,并根据建模的一般原理,结合了软件的特点,因此具有坚实的理论基础和广泛性。UML不仅可以用于软件建模,还可以用于其他领域的建模工作。 [1]  UML立足于对事物的实体、性质、关系、结构、状态和动态变化过程的全程描述和反映。UML可以从不同角度描述人们所观察到的软件视图,也可以描述在不同开发阶段中的软件的形态。UML可以建立需求模型、逻辑模型、设计模型和实现模型等,但UML在建立领域模型方面存在不足,需要进行补充。 [1]  作为一种建模语言,UML有严格的语法和语义规范。UML建立在元模型理论基础上,包括4层元模型结构,分别是基元模型、元模型、模型和用户对象。4层结构层层抽象,下一层是上一层的实例。UML中的所有概念和要素均有严格的语义规范。 [1]  UML采用一组图形符号来描述软件模型,这些图形符号具有简单、直观和规范的特点,开发人员学习和掌握起来比较简单。所描述的软件模型,可以直观地理解和阅读,由于具有规范性,所以能够保证模型的准确、一致。 [1] 
收起全文
精华内容
参与话题
  • UML项目设计----企业项目设计详解

    千人学习 2019-10-18 09:52:02
    肖老师详细介绍了企业项目设计时使用的方法,如UML,提供了一套完善的设计模板
  • 浅谈UML的概念和模型之UML九种图

    万次阅读 多人点赞 2014-04-28 20:17:05
    UML的视图 UML的九种图 UML中类间的关系  上文我们介绍了,UML的视图,在每一种视图中都包含一个或多种图。本文我们重点讲解UML每种图的细节问题:   1、用例图(use case diagrams) 【概念】描述用户需求...

    目录: 

    1. UML的视图 
    2. UML的九种图 
    3. UML中类间的关系

                上文我们介绍了,UML的视图,在每一种视图中都包含一个或多种图。本文我们重点讲解UML每种图的细节问题: 

             1、用例图(use case diagrams)

    【概念】描述用户需求,从用户的角度描述系统的功能

    【描述方式】椭圆表示某个用例;人形符号表示角色

    【目的】帮组开发团队以一种可视化的方式理解系统的功能需求

    【用例图】

     2、静态图 

       类图(class  diagrams) 

    【概念】显示系统的静态结构,表示不同的实体是如何相关联的

    【描述方式】三个矩形 

    【目的】表示一个逻辑类或实现类,逻辑类通常是用户的业务所涉及的事物;实现类是程序员处理的实体

    【类图】

        对象图(object      diagrams)

    【概念】类图的一个实例,描述系统在具体时间点上所包含的对象以及各个对象的关系

    【对象图】

       

              3、交互图

              用来描述对象之间的交互关系 

    1. 序列图(顺序图)

    【概念】描述对象之间的交互顺序,着重体现对象间消息传递的时间顺序

    【描述方式】横跨图的顶部,每个框表示每个类的实例或对象;类实例名称和类名称使用冒号分开

    【目的】显示流程中不同对象之间的调用关系,还可以显示不同对象的不同调用。

    【序列图】

        协作图(Collaboration     diagrams)

    【概念】描述对象之间的合作关系,侧重对象之间的消息传递 

            4、行为图:描述系统的动态模型和对象之间的交互关系 

                 1.状态图(Statechart       diagrams) 

        【概念】描述对象的所有状态以及事件发生而引起的状态之间的转移

        【描述方式】 

    1. 起始点:实心圆 
    2. 状态之间的转换:使用开箭头的线段 
    3. 状态:圆角矩形 
    4. 判断点:空心圆 
    5. 一个或多个终止点:内部包含实心圆的圆

    【目的】表示某个类所处的不同状态以及该类在这些状态中的转换过程

      2.活动图(Activity      diagrams)

    【概念】描述满足用例要求所要进行的活动以及活动时间的约束关系

    【描述方式】 

    1. 起始点:实心圆 
    2. 活动:圆角矩形 
    3. 终止点:内部包含实心圆的圆 
    4. 泳道:实际执行活动的对象

    【目的】表示两个或多个对象之间在处理某个活动时的过程控制流程

    【活动图】 

    活动图和状态图区别:

    5、实现图  

    1. 构件图(Component       diagrams) 

    【概念】描述代码构件的物理结构以及各构件之间的依赖关系

    【描述方式】构件

    【目的】提供系统的物理视图,根据系统的代码构件显示系统代码的整个物理结构

    【构架图】

      

    1. 部署图(Deployment      diagrams)

    【概念】系统中硬件的物理体系结构

    【描述方式】 

    1. 三维立方体表示部件 
    2. 节点名称位于立方体上部

    【目的】显示系统的硬件和软件的物理结构

    【部署图】

    九种UML图详解到此为止,下篇文章专门给大家讲解UML中类间的关系,感谢您的访问。

     

    展开全文
  • UML图学习入门

    万次阅读 2019-06-13 09:57:49
    1.1 UML基础知识扫盲 UML这三个字母的全称是Unified Modeling Language,直接翻译就是统一建模语言,简单地说就是一种有特殊用途的语言。 你可能会问:这明明是一种图形,为什么说是语言呢?伟大的汉字还不是从图形...

    推荐:编写UML在线工具

    1.1 UML基础知识扫盲

    UML这三个字母的全称是Unified Modeling Language,直接翻译就是统一建模语言,简单地说就是一种有特殊用途的语言。

    你可能会问:这明明是一种图形,为什么说是语言呢?伟大的汉字还不是从图形(象形文字)开始的吗?语言是包括文字和图形的!其实有很多内容文字是无法表达的,你见过建筑设计图纸吗?里面还不是很多图形,光用文字能表达清楚建筑设计吗?在建筑界,有一套标准来描述设计,同样道理,在软件开发界,我们也需要一套标准来帮助我们做好软件开发的工作。UML就是其中的一种标准,注意这可不是唯一标准,只是UML是大家比较推崇的一种标准而已,说不定以后有一个更好的标准可能会取代她呢!UML并不是强制性标准,没有法律规定你在软件开发中一定要用UML,不能用其它的,我们的目标是善用包括UML在内的各种标准,来提高我们软件开发的水平。

    UML由1.0版发展到1.1、1.2、...,到现在的2.0、2.x,本书将会以2.x版本为基础开展讨论。网络上、书籍、还有各种UML工具软件,各自基于的UML版本可能会不一样,大家在学习过程中可能会有一些困惑,不过没关系,本课程在某些关键地方会描述1.x与2.x的差异。

    UML有什么用?

    有很多人认为,UML的主要用途就是软件设计!也有人认为,如果你不是开发人员,是难以理解UML的。

    然而我第一次在实际工作中应用UML的却不是软件设计,而是软件需求分析!当时我们和客户面对面沟通调研需求的时候,直接用类图、顺序图、活动图、用例图等UML。我们并没有因此和客户无法沟通,反而是沟通得更加顺畅。客户在我们的引导下,很快就会读懂这些UML图,因为UML图,让我们和客户的沟通效率和效果更好!你可能觉得很神奇,在后续章节中,我将会为你逐一揭开神奇背后的“秘密”。

    UML可帮助我们做软件需求分析和软件设计的工作,在我工作中大概各占了50%的比例,当然在你的实际工作中不一定是这样的比例。UML会让你的需求分析或者软件设计工作更上一层楼,本书将会介绍UML在需求分析方面的最佳实践。

    告诉你一个秘密,UML应用于软件需求分析时,其学习门槛将会大大降低!语法复杂度会降低,而且你基本不需要掌握软件开发的知识。只要你对软件需求分析感兴趣,认真学习和应用UML,就很有机会成为软件需求分析高手。

    UML的分类

    结构型的图(Structure Diagram)

    类图(Class Diagram)

    对象图(Object Diagram)

    构件图(Component Diagram)

    部署图(Deployment Diagram)

    包图(Package Diagram)

    行为型的图(Behavior Diagram)

    活动图(Activity Diagram)

    状态机图(State Machine Diagram)

    顺序图(Sequence Diagram)

    通信图(Communication Diagram)

    用例图(Use Case Diagram)  

    时序图(Timing Diagram)

    本书所描述的UML的各种图的名字,以上述的为准。

    UML各种图的中文译名,因为翻译的原因可能会有所不一样,如:Sequence Diagram和Timing Diagram有时候都会被译成“时序图”,这是最让人困扰的地方!Sequence Diagram 除了被译为顺序图,还有序列图的译法。

    中国软件行业协会(CSIA)与日本UML建模推进协会(UMTP)共同在中国推动的UML专家认证,两个协会共同颁发认证证书、两国互认,CSIA与UMTP共同推出了UML中文术语标准,该标准全称为:CSIA-UMTP UML中文术语标准v1.0(本书后文将会简称为UML中文术语标准)。本书将会遵循UML中文术语标准,并且我们会同时给出中文译名和英文原名,大家要留意看英文名字噢,这样能帮助你不会被众多的中文译名混淆。

    UML图为什么会分为结构型和行为型两种呢?

    顾名思义,结构型的图描述的是某种结构,这种结构在某段时间内应该是稳定的,“静态”的;而结构型的图描述的是某种行为,是“动态”的。

    分析系统需求时,我们会面对很多业务概念,它们之间会有某些关系,这些内容可以看成是“静态”的,我们可以利用UML的结构性的图来分析。同时,业务会涉及大量的流程、过程等,这些内容是“动态”的,我们可以用行为型的UML图来分析。

    在我们软件设计时,我们需要考虑需要那些类、哪些构件、系统最后怎样部署等,这些内容可以看成是“静态”的,我们可以利用UML的结构型的图来设计。同时,我们也需要考虑软件如何和用户交互,类、构件、模块之间如何联系等“动态”内容,我们可以利用行为型的图来设计。

    所谓“静态”和“动态”不是绝对的,下文我们将会进一步介绍结构型的UML和行为型的UML。通过下面的学习,你将会初步认识UML的各种图,你可能还会有很多问题,本章的主要目的是让你对UML有一个宏观的认识,带着你的问题继续阅读后面的章节吧!

    1.2 结构型的UML(Structure Diagram)

    类图(Class Diagram)

    请看下面这个类图:

    图 1.1 某模具系统类图

    此图截取自某模具管理系统的业务概念分析图,图中一个一个的矩形就是类,这些类之间有各种线条连接,这些线条表示类之间的关系。类图是分析业务概念的首选,类图可能是使用率最高的UML图。

    再看下面这个Person类图,这时软件设计时用到的一个图:

    图 1.2 Person类图

    该Person类有以下属性(Attribute):Name(姓名),Sex(性别),Department(部门)等,有以下操作(Operation):Work(工作)等。类有属性和操作,但用类图分析业务模型时,往往不需要使用操作,如图1.1中的类就只有属性。

    Attribute有特性、特征等译法,Operation也称作方法,但本书遵循UML中文术语标准,即Attribute为属性,Operation为操作。

    对象图(Object Diagram)

    一般情况下只有在软件开发中才会使用到对象图,下面的内容以开发的角度来说明对象图,如果你没有开发经验,阅读起来可能有一点难度。

    图1.2中的Person类,用代码实例化如下:

    Person person = new Person();

    ……

    类(Class)实例化后就是对象(Object),对象person是类Person的实例,上述代码可以用对象图表示如下:

    图 1.3 Person类的对象图

    对象图和类图的样子很相似,对象是类的实例化,“person : Person”表示对象person是类Person的实例。对象图往往只在需要描述复杂算法时才会使用,画出来的对象图往往不会只有一个对象,该图只画了一个对象,其目的是尽量简化以便读者的理解什么是对象图。

    在需求分析工作中基本上不需要使用对象图,从严谨的角度来看某些情况下应该使用对象图,但我往往还是会用类图来处理,这样更加简便而且容易理解。我们将在类图一章再次讲解对象图。

    构件图(Component Diagram)

    构件图也叫组件图,两个名字均符合UML中文术语标准。

    一辆汽车由轮子、发动机等物理部件组成,一个软件往往也是由很多“物理部件”(如:控件、重用构件等)组成的,构件图就是用来描述软件内部物理组成的一种图。下图是某权限构件设计图:

    图 1.4 某权限构件设计图

    图1.4右上方有这样标志 的矩形表示一个构件,构件可以再包含构件。

    软件需求分析工作中,需要用到构件图的情况不是很多,以下情况除外:

    1. 待开发的系统需要与第三方的系统、原有系统、某些老系统等交互,这时可用构件图描述交互要求。

    2. 客户对软件设计有某些特殊要求,这时可用构件图来描述要求。

    构件图有时不会单独使用,还会和部署图一起结合使用。

    部署图(Deployment Diagram)

    部署图是用来描述系统如何部署、本系统与其他系统是怎样的关系的一种图,如下图:

    图 1.5 某24小时便利店的管理系统部署图

    图中一个个立体的矩形是部署图的“节点”,一个节点表示一个物理的设备,节点之间的线条表示节点间的物理连接关系。

    大部分客户都会具备一定的IT基础环境(如具备局域网、一些服务器、某些软件平台等),软件系统需要基于当前的IT基础环境来规划,这时我们可以使用部署图来做这个规划。

    分析系统的需求,不能忽略系统架构、部署、IT架构等方面的要求,我们要基于客户当前的IT基础环境,做一个最符合客户利益的规划。

    要活用构件图、部署图来分析需求,需要具备一定的IT基础架构知识和软件设计知识,如果你还不具备相关知识,那么可以考虑抓紧补充相关知识。不过需求分析工作更多的还是分析业务,提炼功能性需求,这部分工作能做好是相当不容易的事情。对于技术方面的非功能性需求分析,可交由有技术背景的专业人士负责。

    包图(Package Diagram)

    Package有“打包”的意思,包图的主要用途是“打包”类图。用类图描述业务概念时,很多时候会因为业务类太多,而导致类图非常庞大,不利于阅读,这时可以将某些类放入“包”中,通过包图来组织业务概念图。

    下图是包图的一个示例:

    图 1.6 包图

    图中好像文件夹样子的就是一个“包”,包之间的线条表示包之间的关系。

    1.3 行为型的UML(Behavior Diagram)

    活动图、状态机图、顺序图处于三种不同的角度来描述流程,是分析业务流程的三种不同利器,下面将会逐一说明。

    活动图(Activity Diagram)

    我们将起床到出门上班这个过程画成活动图,可能是这样的:

    图 1.7 起床到出门上班的活动图

    活动图中的一个圆边框框表示一个“活动”,多个活动之间的带箭头线条表示活动的先后顺序,该图只是表达了一个顺序流程,活动图还可以表达分支结构。如果你以前曾学过流程图的话,你会发现活动图和流程图很相似。活动图可能是三种能表示流程的UML图中最接近我们思维习惯的一种,下面来学习另外两种能表达流程的图。

    状态机图(State Machine Diagram)

    状态机图又叫状态图,但状态图这个译名并没有译出Machine的意思。

    状态机图从某个物品的状态是如何变化的角度来展示流程,下图某请假条审批流程:

    图 1.8 请假处理流程

    整个请假审批流程是围绕“请假条”这个物体进行的,随着不同的审批阶段,请假条具备不同的状态。我们分析业务流程时会发现很多流程其实是围绕某个物品进行的,这时可考虑使用状态机图。

    顺序图(Sequence Diagram)

    你去餐厅吃饭,向服务员点餐到服务员送菜上来,这个过程用顺序图可表示如下:

    图 1.9 点菜的顺序图

    该图有三个“小人”,每个“小人”下面的文字说明(如:顾客)表示其代表的角色。角色与角色之间有一些线条链接,表示角色之间是如何交互的。该图表示的意思是:顾客向服务员点菜后,服务员将点菜信息传递给厨师,然后厨师做菜,最后再由服务员送菜给你。

    点菜过程涉及几个环节,每个环节均由不同的角色来负责,如果遇到类似的情况,你可以考虑使用顺序图来分析。用顺序图来分析的好处是能清晰表达整个过程所参与的角色,角色与角色之间的关系,各角色是如何被卷入这个过程当中的。

    通信图(Communication Diagram)

    UML1.1时,该图英文名为Collaboration Diagram;UML2.x时,英文名为Communication Diagram。将英文名字直接翻译,原来的英文名字可译为协作图,而新的英文名字译为通信图。

    通信图是顺序图的另外一种画法,点菜的顺序图,如果用通信图来画可表示如下:

    图 1.10 点菜的通信图

    三个“小人”分表表示三种角色:顾客、服务员、厨师;角色之间有直线联系表示他们之间有关系;带序号的文字和箭头,表示角色之间传递的信息。

    顺序图更强调先后顺序,通信图更强调相互之间的关系。我觉得顺序图实用性更好一点,比通信图能表达更多的信息,更容易读懂,在需求分析工作中我基本不会使用通信图。

    用例图(Use Case Diagram)

    下图是用例图的示意图:

    图 1.11 用例图

    用例图表达的是什么角色通过软件系统能做什么事情,我们可以使用用例图系统地表达软件系统的绝大部分需求。

    时序图(Timing Diagram)

    时序图也叫时间图,时序图是UML中文术语标准的说法,而时间图不是标准的说法。

    时序图是表示某东西的状态随时间变化而变化的一种图,参见下图:

    图 1.12 灯的开关状态随时间变化图

    此图表示在0秒到30秒,灯的状态是关的,30-60秒灯的状态为开,60秒后状态为关。

    在实际工作中我基本上没有试用过时间图。

    下面通过这个表格来总结一下我在需求分析工作中应用各种UML图的情况:

    表 1.1 各种UML图实际应用情况

    上表是根据我的工作经验总结的,相信会适用于很多情况。但每个人的工作经历、情况、环境等不太一样,上表仅作参考。

    1.4 如何学好UML?

    UML的认识误区

    误区一:认为UML主要用于软件设计。

    前面的文章你可以看到,UML除了用于软件设计,还能用于需求分析,而本书就是专门来说明如何在需求分析工作中活用UML的。

    误区二:客户无法理解UML,在需求分析中应用UML实际意义不大。

    我还不熟悉UML时,确实也有这样的怀疑,而实际工作中发现UML恰恰成为与客户沟通的良好桥梁!UML其实不难读懂,只要稍加解释客户马上就能读懂。我在所有的项目需求分析工作中,都直接使用UML图与客户沟通,并且给客户签署的需求规格说明书中含有大量的UML图。

    UML能直观、形象、严谨地描述出业务概念、业务流程、客户的期望和需求,只要稍加引导客户,客户将会很容易读懂UML,甚至会主动使用UML与项目组交流。我曾经遇到过客户向我们索要画UML图的工具,客户见识过UML的威力后,也想在自己实际工作中使用。

    误区三:认为UML语法繁杂,难以学习和应用。

    某些UML资料和书籍可能将UML说得过于复杂了,官方的UML标准资料也确实是枯燥难懂、人见人晕。我刚开始学习UML时,也看过一些UML书籍,觉得UML的语法太多、太复杂、太容易混淆了!

    在实际工作中,其实经常需要用到的UML语法并不多,而且很容易掌握。当我们在需求分析方面应用UML时,需要掌握的语法更少(在软件设计方面应用UML时需要掌握稍多一点的语法)。“二八原则”在这里完全适用,我们经常用到的UML语法,其实只占全部语法的20%,而本书将会重点介绍实用性强的UML语法。

    误区四:UML用途不大。

    很多人推崇UML,但也有不少人士不太认可UML。不认可的原因主要是因为一些人士学习UML后,发现在实际工作中发挥的作用并不是很大,有时候不用UML效果更好。

    我不敢说UML能帮助我们解决所有问题,至少从我的多年使用经验上来说,UML对于提升我的需求分析能力帮助还是很大的。有人之所以感觉UML不太好用,我觉得原因还是只掌握了UML的形而没有领会UML的神。UML的常用语法可能几天就能学会了,而要真正做到“thinking in UML”却没有这么容易,需要长期的锻炼。

    我的学习经历

    我读大学时没有听说过UML,出来工作两三年后才开始接触UML,当时的感觉就好像找到了新大陆,很想好好发掘一番!而我当时的运气还是相当不错的,我的上司是UML达人,他带领我参加了项目的需求分析工作。我很快就见识了UML威力,在他的言传身教之下,迅速掌握了UML。

    在那个项目以后,我便独立担当了多个项目管理及需求分析工作,没有一个项目不应用UML,而且我毫不保留地传授UML知识给项目组的其他成员。多年的工作进一步磨练了自己,对UML在实际工作中的应用有了更深刻的认识,形成自己的一套方法。

    我的UML知识绝大部分来自于工作实践,期间虽然也看过一些书籍,但对我的帮助很少。当然我最大的得益还是来自我的UML启蒙老师,他在实际工作中教会了我UML,帮助我踏上自我成长的道路。

    我的UML学习最大体会就是:实践太重要了!如果有名师指导则会让你事半功倍!希望本书能成为你在实际工作中学习和应用UML的好帮手!

    UML学习难点

    学UML之难,不在于学习语法,关键是要改变思维习惯。UML是一种新的工具,但同时也是代表了一种新的先进的思考方法,如果不能掌握这样的方法,只能学到了UML的形,而没有掌握其神髓。

    要用好UML,你需要在平时多多培养下面的能力:

    1. 书面表达能力。

    2. 归纳总结能力。

    3. “面向对象”的思维能力和抽象能力。

    平时你可以利用各种机会来提升第1和第2种能力,如多写写项目文档、写写日记或博客等,多思考和总结平时自己的工作得失等。

    第3种能力说起来有点虚,大家在大学中可能也学过相关知识。训练这种能力的最好方法就是多应用类图,我们将会在类图的章节再重点介绍,通过实例来体会什么才叫“面向对象”!

    本书将会重点培养你的这三种能力,只要你有进步之心,多练习、多实践、多思考、多总结,一定会取得长足进步!

    1.5 小结

    本章的主要目标是让你不需要阅读全书的情况下,就可以了解到UML的全貌,大概知道UML各种图的用途,同时给你说明学习UML的难点,为最终活用UML做好准备。下面我们一起来复习一下本章的主要内容:

    UML是Unified Modeling Language的简称,是软件开发界的一套标准,UML不仅可用于软件设计,也可以用于软件需求分析。但UML并不是强制标准,我们应该善用包括UML在内的各种标准来提高我们的水平。

    UML可分为两类:结构型、行为型,结构性的UML有:类图、对象图、构件图、部署图、包图,行为型的图有活动图、状态机图、顺序图、通信图、用例图、时间图。

    类图是业务概念模型分析的有利武器,也是面向对象分析能力的强有力训练工具。

    对象图在需求分析工作中并不常用。

    构件图、部署图是分析IT基础架构、软件架构等方面需求的有利分析工具,但需要你具备IT基础架构、软件设计方面的知识和经验。

    包图可用来组织类图,在需求分析工作中应用的机会不是很大。

    活动图、状态机图、顺序图是分析业务流程的强力武器。活动图的表达思路与流程图很类似,很容易掌握,而且大部分情况下都可以使用活动图来分析业务流程;某流程如果是围绕某个物品进行,该物品在流程中转换多种状态,那么使用状态机图来分析是首选;用顺序图来分析的好处是能清晰表达整个过程所参与的角色,角色与角色之间的关系,各角色是如何被卷入这个过程当中的。

    通信图可以看作是顺序图的另外一种表达形式,顺序图更强调先后顺序,通信图更强调相互之间的关系。而从我的工作经验看,顺序图更加实用一点。

    有人会将用例图称作“公仔图”,用例图表达的是什么角色通过软件系统能做什么事情,我们可以使用用例图系统地表达软件系统的绝大部分需求。

    时间图是表示某东西的状态随时间变化而变化的一种图,我在实际工作中很少有机会能用到这种图。

    学UML之难,不在于学习语法,避免陷入UML的认识误区,多练习、多实践,培养良好的“think in UML”思想,锻炼面向对象分析的能力,成为活用UML的需求分析高手不远矣!

    展开全文
  • UML学习入门就这一篇文章

    万次阅读 多人点赞 2019-05-11 09:17:57
    1.1 UML基础知识扫盲 UML这三个字母的全称是Unified Modeling Language,直接翻译就是统一建模语言,简单地说就是一种有特殊用途的语言。 你可能会问:这明明是一种图形,为什么说是语言呢?伟大的汉字还不是从图形...

    1.1 UML基础知识扫盲

    UML这三个字母的全称是Unified Modeling Language,直接翻译就是统一建模语言,简单地说就是一种有特殊用途的语言。

    你可能会问:这明明是一种图形,为什么说是语言呢?伟大的汉字还不是从图形(象形文字)开始的吗?语言是包括文字和图形的!其实有很多内容文字是无法表达的,你见过建筑设计图纸吗?里面还不是很多图形,光用文字能表达清楚建筑设计吗?在建筑界,有一套标准来描述设计,同样道理,在软件开发界,我们也需要一套标准来帮助我们做好软件开发的工作。UML就是其中的一种标准,注意这可不是唯一标准,只是UML是大家比较推崇的一种标准而已,说不定以后有一个更好的标准可能会取代她呢!UML并不是强制性标准,没有法律规定你在软件开发中一定要用UML,不能用其它的,我们的目标是善用包括UML在内的各种标准,来提高我们软件开发的水平。

    UML由1.0版发展到1.1、1.2、...,到现在的2.0、2.x,本书将会以2.x版本为基础开展讨论。网络上、书籍、还有各种UML工具软件,各自基于的UML版本可能会不一样,大家在学习过程中可能会有一些困惑,不过没关系,本课程在某些关键地方会描述1.x与2.x的差异。

    UML有什么用?

    有很多人认为,UML的主要用途就是软件设计!也有人认为,如果你不是开发人员,是难以理解UML的。

    然而我第一次在实际工作中应用UML的却不是软件设计,而是软件需求分析!当时我们和客户面对面沟通调研需求的时候,直接用类图、顺序图、活动图、用例图等UML。我们并没有因此和客户无法沟通,反而是沟通得更加顺畅。客户在我们的引导下,很快就会读懂这些UML图,因为UML图,让我们和客户的沟通效率和效果更好!你可能觉得很神奇,在后续章节中,我将会为你逐一揭开神奇背后的“秘密”。

    UML可帮助我们做软件需求分析和软件设计的工作,在我工作中大概各占了50%的比例,当然在你的实际工作中不一定是这样的比例。UML会让你的需求分析或者软件设计工作更上一层楼,本书将会介绍UML在需求分析方面的最佳实践。

    告诉你一个秘密,UML应用于软件需求分析时,其学习门槛将会大大降低!语法复杂度会降低,而且你基本不需要掌握软件开发的知识。只要你对软件需求分析感兴趣,认真学习和应用UML,就很有机会成为软件需求分析高手。

    UML的分类

    结构型的图(Structure Diagram)

    类图(Class Diagram)

    对象图(Object Diagram)

    构件图(Component Diagram)

    部署图(Deployment Diagram)

    包图(Package Diagram)

    行为型的图(Behavior Diagram)

    活动图(Activity Diagram)

    状态机图(State Machine Diagram)

    顺序图(Sequence Diagram)

    通信图(Communication Diagram)

    用例图(Use Case Diagram)  

    时序图(Timing Diagram)

    本书所描述的UML的各种图的名字,以上述的为准。

    UML各种图的中文译名,因为翻译的原因可能会有所不一样,如:Sequence Diagram和Timing Diagram有时候都会被译成“时序图”,这是最让人困扰的地方!Sequence Diagram 除了被译为顺序图,还有序列图的译法。

    中国软件行业协会(CSIA)与日本UML建模推进协会(UMTP)共同在中国推动的UML专家认证,两个协会共同颁发认证证书、两国互认,CSIA与UMTP共同推出了UML中文术语标准,该标准全称为:CSIA-UMTP UML中文术语标准v1.0(本书后文将会简称为UML中文术语标准)。本书将会遵循UML中文术语标准,并且我们会同时给出中文译名和英文原名,大家要留意看英文名字噢,这样能帮助你不会被众多的中文译名混淆。

    UML图为什么会分为结构型和行为型两种呢?

    顾名思义,结构型的图描述的是某种结构,这种结构在某段时间内应该是稳定的,“静态”的;而结构型的图描述的是某种行为,是“动态”的。

    分析系统需求时,我们会面对很多业务概念,它们之间会有某些关系,这些内容可以看成是“静态”的,我们可以利用UML的结构性的图来分析。同时,业务会涉及大量的流程、过程等,这些内容是“动态”的,我们可以用行为型的UML图来分析。

    在我们软件设计时,我们需要考虑需要那些类、哪些构件、系统最后怎样部署等,这些内容可以看成是“静态”的,我们可以利用UML的结构型的图来设计。同时,我们也需要考虑软件如何和用户交互,类、构件、模块之间如何联系等“动态”内容,我们可以利用行为型的图来设计。

    所谓“静态”和“动态”不是绝对的,下文我们将会进一步介绍结构型的UML和行为型的UML。通过下面的学习,你将会初步认识UML的各种图,你可能还会有很多问题,本章的主要目的是让你对UML有一个宏观的认识,带着你的问题继续阅读后面的章节吧!

    1.2 结构型的UML(Structure Diagram)

    类图(Class Diagram)

    请看下面这个类图:

    图 1.1 某模具系统类图

    此图截取自某模具管理系统的业务概念分析图,图中一个一个的矩形就是类,这些类之间有各种线条连接,这些线条表示类之间的关系。类图是分析业务概念的首选,类图可能是使用率最高的UML图。

    再看下面这个Person类图,这时软件设计时用到的一个图:

    图 1.2 Person类图

    该Person类有以下属性(Attribute):Name(姓名),Sex(性别),Department(部门)等,有以下操作(Operation):Work(工作)等。类有属性和操作,但用类图分析业务模型时,往往不需要使用操作,如图1.1中的类就只有属性。

    Attribute有特性、特征等译法,Operation也称作方法,但本书遵循UML中文术语标准,即Attribute为属性,Operation为操作。

    对象图(Object Diagram)

    一般情况下只有在软件开发中才会使用到对象图,下面的内容以开发的角度来说明对象图,如果你没有开发经验,阅读起来可能有一点难度。

    图1.2中的Person类,用代码实例化如下:

    Person person = new Person();

    ……

    类(Class)实例化后就是对象(Object),对象person是类Person的实例,上述代码可以用对象图表示如下:

    图 1.3 Person类的对象图

    对象图和类图的样子很相似,对象是类的实例化,“person : Person”表示对象person是类Person的实例。对象图往往只在需要描述复杂算法时才会使用,画出来的对象图往往不会只有一个对象,该图只画了一个对象,其目的是尽量简化以便读者的理解什么是对象图。

    在需求分析工作中基本上不需要使用对象图,从严谨的角度来看某些情况下应该使用对象图,但我往往还是会用类图来处理,这样更加简便而且容易理解。我们将在类图一章再次讲解对象图。

    构件图(Component Diagram)

    构件图也叫组件图,两个名字均符合UML中文术语标准。

    一辆汽车由轮子、发动机等物理部件组成,一个软件往往也是由很多“物理部件”(如:控件、重用构件等)组成的,构件图就是用来描述软件内部物理组成的一种图。下图是某权限构件设计图:

    图 1.4 某权限构件设计图

    图1.4右上方有这样标志 的矩形表示一个构件,构件可以再包含构件。

    软件需求分析工作中,需要用到构件图的情况不是很多,以下情况除外:

    1. 待开发的系统需要与第三方的系统、原有系统、某些老系统等交互,这时可用构件图描述交互要求。

    2. 客户对软件设计有某些特殊要求,这时可用构件图来描述要求。

    构件图有时不会单独使用,还会和部署图一起结合使用。

    部署图(Deployment Diagram)

    部署图是用来描述系统如何部署、本系统与其他系统是怎样的关系的一种图,如下图:

    图 1.5 某24小时便利店的管理系统部署图

    图中一个个立体的矩形是部署图的“节点”,一个节点表示一个物理的设备,节点之间的线条表示节点间的物理连接关系。

    大部分客户都会具备一定的IT基础环境(如具备局域网、一些服务器、某些软件平台等),软件系统需要基于当前的IT基础环境来规划,这时我们可以使用部署图来做这个规划。

    分析系统的需求,不能忽略系统架构、部署、IT架构等方面的要求,我们要基于客户当前的IT基础环境,做一个最符合客户利益的规划。

    要活用构件图、部署图来分析需求,需要具备一定的IT基础架构知识和软件设计知识,如果你还不具备相关知识,那么可以考虑抓紧补充相关知识。不过需求分析工作更多的还是分析业务,提炼功能性需求,这部分工作能做好是相当不容易的事情。对于技术方面的非功能性需求分析,可交由有技术背景的专业人士负责。

    包图(Package Diagram)

    Package有“打包”的意思,包图的主要用途是“打包”类图。用类图描述业务概念时,很多时候会因为业务类太多,而导致类图非常庞大,不利于阅读,这时可以将某些类放入“包”中,通过包图来组织业务概念图。

    下图是包图的一个示例:

    图 1.6 包图

    图中好像文件夹样子的就是一个“包”,包之间的线条表示包之间的关系。

    1.3 行为型的UML(Behavior Diagram)

    活动图、状态机图、顺序图处于三种不同的角度来描述流程,是分析业务流程的三种不同利器,下面将会逐一说明。

    活动图(Activity Diagram)

    我们将起床到出门上班这个过程画成活动图,可能是这样的:

    图 1.7 起床到出门上班的活动图

    活动图中的一个圆边框框表示一个“活动”,多个活动之间的带箭头线条表示活动的先后顺序,该图只是表达了一个顺序流程,活动图还可以表达分支结构。如果你以前曾学过流程图的话,你会发现活动图和流程图很相似。活动图可能是三种能表示流程的UML图中最接近我们思维习惯的一种,下面来学习另外两种能表达流程的图。

    状态机图(State Machine Diagram)

    状态机图又叫状态图,但状态图这个译名并没有译出Machine的意思。

    状态机图从某个物品的状态是如何变化的角度来展示流程,下图某请假条审批流程:

    图 1.8 请假处理流程

    整个请假审批流程是围绕“请假条”这个物体进行的,随着不同的审批阶段,请假条具备不同的状态。我们分析业务流程时会发现很多流程其实是围绕某个物品进行的,这时可考虑使用状态机图。

    顺序图(Sequence Diagram)

    你去餐厅吃饭,向服务员点餐到服务员送菜上来,这个过程用顺序图可表示如下:

    图 1.9 点菜的顺序图

    该图有三个“小人”,每个“小人”下面的文字说明(如:顾客)表示其代表的角色。角色与角色之间有一些线条链接,表示角色之间是如何交互的。该图表示的意思是:顾客向服务员点菜后,服务员将点菜信息传递给厨师,然后厨师做菜,最后再由服务员送菜给你。

    点菜过程涉及几个环节,每个环节均由不同的角色来负责,如果遇到类似的情况,你可以考虑使用顺序图来分析。用顺序图来分析的好处是能清晰表达整个过程所参与的角色,角色与角色之间的关系,各角色是如何被卷入这个过程当中的。

    通信图(Communication Diagram)

    UML1.1时,该图英文名为Collaboration Diagram;UML2.x时,英文名为Communication Diagram。将英文名字直接翻译,原来的英文名字可译为协作图,而新的英文名字译为通信图。

    通信图是顺序图的另外一种画法,点菜的顺序图,如果用通信图来画可表示如下:

    图 1.10 点菜的通信图

    三个“小人”分表表示三种角色:顾客、服务员、厨师;角色之间有直线联系表示他们之间有关系;带序号的文字和箭头,表示角色之间传递的信息。

    顺序图更强调先后顺序,通信图更强调相互之间的关系。我觉得顺序图实用性更好一点,比通信图能表达更多的信息,更容易读懂,在需求分析工作中我基本不会使用通信图。

    用例图(Use Case Diagram)

    下图是用例图的示意图:

    图 1.11 用例图

    用例图表达的是什么角色通过软件系统能做什么事情,我们可以使用用例图系统地表达软件系统的绝大部分需求。

    时序图(Timing Diagram)

    时序图也叫时间图,时序图是UML中文术语标准的说法,而时间图不是标准的说法。

    时序图是表示某东西的状态随时间变化而变化的一种图,参见下图:

    图 1.12 灯的开关状态随时间变化图

    此图表示在0秒到30秒,灯的状态是关的,30-60秒灯的状态为开,60秒后状态为关。

    在实际工作中我基本上没有试用过时间图。

    下面通过这个表格来总结一下我在需求分析工作中应用各种UML图的情况:

    表 1.1 各种UML图实际应用情况

    上表是根据我的工作经验总结的,相信会适用于很多情况。但每个人的工作经历、情况、环境等不太一样,上表仅作参考。

    1.4 如何学好UML?

    UML的认识误区

    误区一:认为UML主要用于软件设计。

    前面的文章你可以看到,UML除了用于软件设计,还能用于需求分析,而本书就是专门来说明如何在需求分析工作中活用UML的。

    误区二:客户无法理解UML,在需求分析中应用UML实际意义不大。

    我还不熟悉UML时,确实也有这样的怀疑,而实际工作中发现UML恰恰成为与客户沟通的良好桥梁!UML其实不难读懂,只要稍加解释客户马上就能读懂。我在所有的项目需求分析工作中,都直接使用UML图与客户沟通,并且给客户签署的需求规格说明书中含有大量的UML图。

    UML能直观、形象、严谨地描述出业务概念、业务流程、客户的期望和需求,只要稍加引导客户,客户将会很容易读懂UML,甚至会主动使用UML与项目组交流。我曾经遇到过客户向我们索要画UML图的工具,客户见识过UML的威力后,也想在自己实际工作中使用。

    误区三:认为UML语法繁杂,难以学习和应用。

    某些UML资料和书籍可能将UML说得过于复杂了,官方的UML标准资料也确实是枯燥难懂、人见人晕。我刚开始学习UML时,也看过一些UML书籍,觉得UML的语法太多、太复杂、太容易混淆了!

    在实际工作中,其实经常需要用到的UML语法并不多,而且很容易掌握。当我们在需求分析方面应用UML时,需要掌握的语法更少(在软件设计方面应用UML时需要掌握稍多一点的语法)。“二八原则”在这里完全适用,我们经常用到的UML语法,其实只占全部语法的20%,而本书将会重点介绍实用性强的UML语法。

    误区四:UML用途不大。

    很多人推崇UML,但也有不少人士不太认可UML。不认可的原因主要是因为一些人士学习UML后,发现在实际工作中发挥的作用并不是很大,有时候不用UML效果更好。

    我不敢说UML能帮助我们解决所有问题,至少从我的多年使用经验上来说,UML对于提升我的需求分析能力帮助还是很大的。有人之所以感觉UML不太好用,我觉得原因还是只掌握了UML的形而没有领会UML的神。UML的常用语法可能几天就能学会了,而要真正做到“thinking in UML”却没有这么容易,需要长期的锻炼。

    我的学习经历

    我读大学时没有听说过UML,出来工作两三年后才开始接触UML,当时的感觉就好像找到了新大陆,很想好好发掘一番!而我当时的运气还是相当不错的,我的上司是UML达人,他带领我参加了项目的需求分析工作。我很快就见识了UML威力,在他的言传身教之下,迅速掌握了UML。

    在那个项目以后,我便独立担当了多个项目管理及需求分析工作,没有一个项目不应用UML,而且我毫不保留地传授UML知识给项目组的其他成员。多年的工作进一步磨练了自己,对UML在实际工作中的应用有了更深刻的认识,形成自己的一套方法。

    我的UML知识绝大部分来自于工作实践,期间虽然也看过一些书籍,但对我的帮助很少。当然我最大的得益还是来自我的UML启蒙老师,他在实际工作中教会了我UML,帮助我踏上自我成长的道路。

    我的UML学习最大体会就是:实践太重要了!如果有名师指导则会让你事半功倍!希望本书能成为你在实际工作中学习和应用UML的好帮手!

    UML学习难点

    学UML之难,不在于学习语法,关键是要改变思维习惯。UML是一种新的工具,但同时也是代表了一种新的先进的思考方法,如果不能掌握这样的方法,只能学到了UML的形,而没有掌握其神髓。

    要用好UML,你需要在平时多多培养下面的能力:

    1. 书面表达能力。

    2. 归纳总结能力。

    3. “面向对象”的思维能力和抽象能力。

    平时你可以利用各种机会来提升第1和第2种能力,如多写写项目文档、写写日记或博客等,多思考和总结平时自己的工作得失等。

    第3种能力说起来有点虚,大家在大学中可能也学过相关知识。训练这种能力的最好方法就是多应用类图,我们将会在类图的章节再重点介绍,通过实例来体会什么才叫“面向对象”!

    本书将会重点培养你的这三种能力,只要你有进步之心,多练习、多实践、多思考、多总结,一定会取得长足进步!

    1.5 小结

    本章的主要目标是让你不需要阅读全书的情况下,就可以了解到UML的全貌,大概知道UML各种图的用途,同时给你说明学习UML的难点,为最终活用UML做好准备。下面我们一起来复习一下本章的主要内容:

    UML是Unified Modeling Language的简称,是软件开发界的一套标准,UML不仅可用于软件设计,也可以用于软件需求分析。但UML并不是强制标准,我们应该善用包括UML在内的各种标准来提高我们的水平。

    UML可分为两类:结构型、行为型,结构性的UML有:类图、对象图、构件图、部署图、包图,行为型的图有活动图、状态机图、顺序图、通信图、用例图、时间图。

    类图是业务概念模型分析的有利武器,也是面向对象分析能力的强有力训练工具。

    对象图在需求分析工作中并不常用。

    构件图、部署图是分析IT基础架构、软件架构等方面需求的有利分析工具,但需要你具备IT基础架构、软件设计方面的知识和经验。

    包图可用来组织类图,在需求分析工作中应用的机会不是很大。

    活动图、状态机图、顺序图是分析业务流程的强力武器。活动图的表达思路与流程图很类似,很容易掌握,而且大部分情况下都可以使用活动图来分析业务流程;某流程如果是围绕某个物品进行,该物品在流程中转换多种状态,那么使用状态机图来分析是首选;用顺序图来分析的好处是能清晰表达整个过程所参与的角色,角色与角色之间的关系,各角色是如何被卷入这个过程当中的。

    通信图可以看作是顺序图的另外一种表达形式,顺序图更强调先后顺序,通信图更强调相互之间的关系。而从我的工作经验看,顺序图更加实用一点。

    有人会将用例图称作“公仔图”,用例图表达的是什么角色通过软件系统能做什么事情,我们可以使用用例图系统地表达软件系统的绝大部分需求。

    时间图是表示某东西的状态随时间变化而变化的一种图,我在实际工作中很少有机会能用到这种图。

    学UML之难,不在于学习语法,避免陷入UML的认识误区,多练习、多实践,培养良好的“think in UML”思想,锻炼面向对象分析的能力,成为活用UML的需求分析高手不远矣!

    用例图实践:https://edu.csdn.net/course/play/2086/32567

    活动图实践:https://edu.csdn.net/course/play/2086/32569

    状态图实践:https://edu.csdn.net/course/play/2086/195362

    软件工程实践者的研究方法视频教程: https://edu.csdn.net/course/detail/2086

    展开全文
  • UML精简教程

    千人学习 2018-10-22 21:38:07
    剔除繁杂的理论,注重实践,深入浅出讲解UML的基本使用
  • 常见UML

    千次阅读 2020-04-29 16:30:51
    打个广告,帮朋友卖点东西,东西超...UML中的图有: 一、用况图 用况图展示了用况之间以及同用况与参与者之间是怎样相互联系的。用况图用于对系统、子系统或类的行为进行可视化,使用户能够理解如何使用这些...

    UML中的图有:

     

    一、用况图

            用况图展示了用况之间以及同用况与参与者之间是怎样相互联系的。用况图用于对系统、子系统或类的行为进行可视化,使用户能够理解如何使用这些元素,并使开发者能够实现这些元素。用况图呈现了一些参与者和一些用况,以及它们之间的关系。主要用于对系统(子系统)的功能行为进行建模。使用用况图可以:

    • 通过表示在语境中参与者如何与系统交互,使得系统、子系统和类对于用户和开发者易于探讨和理解。
    • 易于对需求规范化
    • 有利于进行OOA
    • 有助于发现主动对象
    • 对系统测试来说,产生测试用例。
    • 有助于人机界面设计

        在图形上,用况图是一幅由一组参与者、一组用况以及这些元素之间的关系组成的图。这些关系是参与者和用况之间的关联、参与者之间的泛化,以及用况之间的泛化、扩展和包含。可以选择把一些用况用一个矩形围起来,用来表示系统、子系统或“类”的边界。用况图可以包含注解和约束。 

    1、概念说明

    1.系统相关概念

    系统:是由“用户”使用的软件,以及所有与其相关的硬件。指被开发的计算机软硬件系统,不是指现实世界的系统。

    系统边界:一个系统所包含的所有系统成分与系统以外各种事物的分界线。

    系统成分:在OOA和OOD中定义,在编程时加以实现的系统元素——对象

    2.参与者

            简言之,参与者是在系统之外的与系统进行交互的任何事物。一个参与者定义了用况的使用者在与这些用况交互时所扮演的一组功能高内聚的角色:

    • 参与者可以发出对系统服务的请求。
    • 所有参与者的请求/响应的完全集构成了可以觉察到的系统的问题域边界。
    • 一个参与者的一个实例代表以一种特定的方式与系统进行的单独的交互。
    • 尽管在模型中使用参与者,但参与者实际上并不是系统的一部分。它们存在于系统之外。 
    • 如果一组参与者具有共同的性质,可以把这些性质抽取出来放在另一个参与者中,它们再从中继承,把这种关系称为参与者之间的泛化关系。 从参与者A到参与者B之间的泛化关系是指,A的实例能与和B实例进行通讯的用况实例进行通信。

    如何发现参与者?

    • 从人员角度

    系统的直接使用者

    直接为系统服务的人员

    • 从设备角度

    与系统直接相联的设备

    为系统提供信息

    在系统控制下运行

    • 从外部系统角度

    上级系统

    子系统

    其它系统

    3.用况

            用况是对参与者使用系统的一项功能时所进行的交互过程的描述。 几点说明:

    (1)一个用况描述参与者对一项或几项系统功能的使用情况。而且只有当外部的参与者与该系统或类目进行交互时,该功能才发挥作用。 

    (2)用况中描述的行为实际上是系统级的。在用况内所描述的交互中的动作应该是详细的,准则是对用况的理解不产生歧义即可;若描述得过于综合,则不易认识清楚系统的功能。

    (3)陈述参与者和系统在交互过程中双方所做的事。而且描述彼此为对方直接地做什么事,不描述怎么做,内部细节不要在其中描述。 

    (4)用况既表达了系统的功能需求,也表达了系统的功能划分。 

    (5)描述应力求准确、清晰,允许概括,但不要把双方的行为混在一起。

    (6)系统执行该动作序列来为参与者产生一个可观察的结果值。

    (7)用况描述的是一个参与者所使用的一项系统功能,该项功能应该相对完整。这就要求一个用况描述的功能,即不能过大以至于包含过多的内容,也不能过小以至于仅包含完成一项功能的若干步骤。

    (8)用况描述中的一个步骤应该描述且仅描述参与者或系统要完成的一件事情。 

    (9)可以使用类图、活动图等对用况进行详细说明。

    1.用况间的关系

            在下述情况下,就需要考虑产生新的用况,并在用况间建立关系:

    •  在一个用况中存在着几处重复使用的动作序列;
    •  在几个用况中存在着重复使用的动作序列;
    •  一个用况中的主要动作序列或分支动作序列过于冗长或复杂,而且分离它们有助于管理和理解。

    1.扩展关系

            按基用况中指定的扩展条件,把扩展用况的行为插入到由基用况中的扩展点定义的位置。 

           通过敞开的虚线箭头表示用况之间的扩展关系,该箭头从提供扩展的用况指向基用况。这个箭头用关键字<<extend>>标记。可以在这个关键字附近表示这个关系的条件。

    2.包含关系

            基用况在它内部说明的某一(些)位置上显式地使用供应者用况的行为的结果。

            通过一个敞开的虚线箭头表示用况之间的包含关系,该箭头从基用况指向被包含的用况。这个箭头用关键字<<include>>标记。

     

    3.泛化关系

            用况之间的泛化关系就像类之间的泛化关系一样。子用况继承父用况的行为和含义;子用况还可以增加或覆盖父用况的行为;子用况可以出现在父用况出现的任何位置(父和子均有具体的实例)。

            用一个指向父用况的带有封闭的空心箭头的实线来表示用况之间的泛化关系。

     

    2.捕获用况

    1)利用参与者捕获用况 

    对所有的参与者(把自己作为参与者),提问下列问题:

    • 每个参与者的主要任务是什么?
    • 为了达到某种目的,它们参加什么活动?该参与者是否将读写系统的任何信息?参与者是否该把系统外部的变化通知系统?参与者是否希望系统把预料之外的变化通知自己?
    • 在交互过程中,它们是怎样使用系统的服务来完成它们的任务以达到目的?
    • 它们参加了什么在本质上是不同的过程?
    • 是什么事件引起了与系统进行交互的序列?

       能完成特定功能的每一项活动明确地是一个用况。这些参与者参与的活动,通常会导致其它用况。 

    2)从系统功能角度捕获用况

    用于本步骤的一些简单的指导如下:

    •  一个用况描述一项功能,这项功能不能过大。例如,把一个企业信息管理系统粗略地分为生产管理、供销管理、财务管理和人事管理等几大方面的功能,就显得粒度太大了,应该再进行细化。
    • 全面地认识和定义每一个用况,要点是以穷举的方式考虑每一个参与者与系统的交互情况,看看每个参与者要求系统提供什么功能,以及参与者的每一项输入信息将要求系统作出什么反映,进行什么处理。
    • 以穷举的方式检查用户对系统的功能需求是否能在各个用况中体现出来。
    • 一个用况应该是一个完整的任务,通常应该在一个相对短的时间段内完成。如果一个用况的各部分被分配在不同的时间段,尤其被不同的参与者执行,最好还是将各部分作为单独的用况对待。
    • 考虑对例外情况的处理。针对用况描述的基本流,要详尽地考虑各种其他的情况 

    3)使用场景技术

           如果不能顺利地确定一个用况的描述,可尽早使用人们熟知的“角色扮演”技术。 

     

    2、使用案例

            很多软件系统在一开始都需要登录,若用户登录成功,则可进入系统。如下以一个研究生学籍管理系统为例,描述四种登录方法。为了简化起见,假设此处仅描述登录、选课和查看学分这3项功能。 

    方案一:

            由于选课和查看学分都需要登录,故专门设立一个“登录”用况。若登录成功,则可以进行选课,也可以进行查看学分。

     

     分析:

            该方法的缺点是,必须要了解系统的所有其它模块,才能描述清楚“登录”用况。向系统增加新用况时,也要修改登录用况。此外,从维护的角度看,有时会忘记对“登录”用况进行修改。 

     

    方案二:

            让所有的相关用况都包含登录用况。

     

    分析: 

            这个方法中的“登录”用况仅描述有关登录的信息,研究生执行系统的每项功能都要先登录。其缺点为,对研究生要进行多次验证。 

     

    方案三:

      使用扩展,设计系统登录。

    分析:

            该方法与方法一相比,对“登录”用况的描述要清楚一些。在增加新用况时,仅在登录用况中添加扩展点即可。 

     

    方案四:

      登录用况完全独立于其它用况 。

     

    分析:

            若使用该方法,必须要在“选课”用况和“查看学分”用况中指定前置条件:只有在登录成功后才能执行自己。

    二、类图

            在模型中用类符号来表示一个类,它代表属于该类的全部对象实例。

     

    说明:最上面的那个名称栏包含类名;中间的分栏包含属性列表;最下面的分栏包含操作列表。每个属性和操作各占一行。

     

    属性/操作表示格式:[可见性] 属性名/操作名[‘:’类型][‘ =’初始值]

     其中可见性分为+(公有的)、#(受保护的)或 -(私有的)、 ~(包,只有在同一包中声明的类能够使用这一属性)。 

    1、类(及其对象)之间的关系

    1.泛化(一般-特殊)

            泛化(generalization)是较特殊的类和较一般的类之间的直接关系(继承关系),其中较一般的类具有较特殊的类的共同性质,较特殊的类继承较一般的类的性质,且还具有自己的性质,或额外的关联,较特殊的类的对象是较一般的类的对象的子集。

             如果类A具有类B的全部属性和全部操作,而且具有自己特有的某些属性或操作,则A叫做B的特殊类,B叫做A的一般类。其表示方法为:

     2.关联(实例连接)

    1.基本介绍

            对象之间的静态联系是指,最终可通过对象属性来表示的一个对象对另一个对象的联系。用链* (link)表示类对象之间的静态联系。对象之间的动态联系是指,对象之间在行为(操作)上的依赖关系。 用关联* (association)表示类之间的静态联系。如果类的对象之间通过属性有连接关系,那么这些类之间的语义关系就是关联(association)。 其表示为:

    2.常见概念

    1) 多重性

    • 多重性是非负整数开集的一个子集。
    • 另一端上的多重性是指,对于本端的一个对象,需要另一端对象的个数。
    • 把多重性规约表示成由用逗号分开的整数间隔序列组成的字符串,间隔代表整数的范围(可能无限),其格式为:下限..上限

    其中的下限和上限都是文字整型值,说明从下限到上限的整数闭区间。此外星号(*)可以用于上限,表明不限制上限。 如果多重性规约由单个的(*)构成,那么它就表明了无穷的非负正整数的范围,也即它等价于0..*。

    2) 关联类 (association class)

    • 具有关联和类的特征的建模元素。关联类既可以被看作是具有类的性质的关联,也可以被看作为具有关联性质的类。
    • 如果在具有关联关系的类中,存在着一个属性放在哪个类中都不合适的情况,就考虑使用关联类。 

    如下:

     

    3) N元关联

            N元关联是三个或三个以上类之间的一个关联。可以规约N元关联的多重性,但与二元关联的多重性相比,并不那样明显。在一个角色上的多重性,当该N元关联中的其它N-1个值被确定时,表示该关联潜在的实例元组的数目。

            通过一个大的菱形(指的是比在路径上的终端符大)表示一个N元关联,这个菱形有很多与各参与的类相连接路径。关联的名字(如果有的话)显示在菱形附近。同二元关联一样,角色修饰可以显示在每一个路径上。

            可以用虚线把关联类符号与菱形连接起来,表示具有属性、操作或关联的N元关联。 

    它也可以转换为二元关系如下:

     4) 限定关联

           在使用关联时,一种常见的用法是查找。给定关联一端类中的一个对象,按照另一端类的对象的特点,查找其中的对象或对象集时,就需要使用限定关联。 

           例如,通常产品订单由若干定单行和一些其它描述信息组成, 使用限定关联描述产品订单、订单行以及它们之间的关系。 

    3.聚合(整体-部分)

            用于描述系统中各类对象之间的组成关系,通过它可以看出某个类的对象,以另外一些类的对象作为其组成部分。聚合(aggregation)是关联的一种特殊形式,表示整体和部分之间的“整体-部分”关系。聚集 (aggregate)是聚合关系中作为“整体”的类,而把作为“部分”的类称为 成分或部分。

            类与类之间的聚合关系指的是,一个类的对象实例,以另一个类的对象实例作为其组成部分, 是种“a part of”或“has a” ;也可理解为,一个类定义引用另一个类定义。

            组合是聚合的一种形式,其部分和整体之间具有很强的“属于”关系,整体类的对象管理部分类的对象, 决定部分类的对象何时属于它,何时不属于它。部分可以先于整体消亡。这种聚集末端的多重性不能超过1。组合对象是组合类的实例。 

    举例说明:

    4.依赖

           一个依赖规约了两个或多个模型元素(或两个模型元素集合)之间的一种语义关系,对目标元素的改变可能需要改变该依赖中的源元素。如:

            仅当被建模的关系不是结构关系时,才使用依赖。关联主要用于类间有结构关系的地方。把依赖表示为两个模型元素之间的虚线箭头。在箭头尾部的模型元素(客户)依赖箭头头部的模型元素(提供者)。箭头可以用放在双尖括号内的字符串标识。

    2、接口

            平时在定义类时,可见性为公共的操作就构成了一组外部可访问的操作,为其它的类提供服务。把这组操作组织起来,作为该类的一个或几个接口,说该类提供了对其接口的实现。还有一种接口是纯粹的,就象Java中的接口那样。这种接口仅具有操作说明,没有实现,它作为实现它和使用它的类的桥梁。在UML中,把一个接口定义为一个类、构件或子系统的对外可见的一组操作的描述符。它定义了类、构件或子系统对外提供的服务。接口定义了一个契约,在接口两端的遵循该接口的任何类、构件或子系统可以独立变更,但必须忠实地履行这个契约。 

     

            抽象类可以作为接口,但严格地讲,二者是有区别的,是不相同的建模元素。抽象类可以含有属性和一些具体操作,而接口没有属性,且不能在其中定义任何具体操作的方法 。接口更像一个其所有的操作都是抽象的抽象类。

    三、顺序图

            顺序图(Sequence Diagram)是一种详细表示对象之间以及对象与系统外部的参与者之间动态联系(交互)的图形文档。顺序图详细而直观地表现了一组相互协作的对象在执行一个(或少量几个)用况时的行为依赖关系,以及操作和消息的时序关系。它可以:

    • 帮助分析员对照检查每个用况中描述的用户需求,是否已经落实到一些对象中去实现。提醒分析员去补充遗漏的对象类或操作。
    • 帮助分析员发现哪些对象是主动对象
    • 通过对一个特定的对象群体的动态方面建模,深刻地理解对象之间的交互。 

     

     1、重要概念

    1.对象生命线

            把对象表示成称之为“生命线”的垂直虚线。生命线代表一个对象在特定时间内的存在。如果对象在图中所示的时间段内被创建或者销毁,那么它的生命线就在适当的点开始或结束。否则,生命线应当从图的顶部一直延续到底部。

         在生命线的顶部画对象符号。如果一个对象在图中所规定的时间段被创建,那么就把创建对象的箭头的头部画在对象符号上。如果对象在图中被销毁,那么用一个大的“X” 标记它,该标记或者放在引起销毁的箭头处,或者放在从被销毁的对象最终返回的箭头处。

         在图的顶部(第一个箭头之上)放置在转换开始时就存在的对象,而在整个转换完成时仍然存在的对象的生命线,要延伸超出最后一个箭头。

      生命线可以分裂成两条或更多条并发的生命线,以表示条件性。这样的每一个生命线对应于通讯中的一个条件分支。生命线可以在某个后续点处合并。  

    2.执行规约

            执行规约表示一个对象直接或者通过从属例程执行一个行为的时期。它既表示了行为执行的持续时间,也表示了活动和它的调用者之间的控制关系。

         用一个窄长的矩形表示执行规约,矩形顶端和它的开始时刻对齐,末端和它的结束时刻对齐。

         在程序的控制流中,执行规约符号的顶端画在进入的箭头的尖端(开始该动作的那个箭头),底端画在返回的箭头的尾部。

        当一个对象处于执行规约期时,该对象能够响应或发送消息,执行对象或活动。当一个对象不处于执行规约期时,该对象不做什么事情,但它是存在的,等待新的消息执行规约它。

    3.消息

          消息是对象之间的通讯的规格说明,这样的通讯用于传输将发生的活动所需要的信息。它即包含了控制信息(如调用)也包含了所使用的数据的规格说明。 一个消息会调用另一个对象的操作,调用本对象的操作,向另一个对象发送一个信号,创建或者撤消一个对象(可以自己销毁自己),还可能向调用者返回一个结果。

           把消息表示为从一个对象生命线到另一个对象生命线的一个水平实线箭头,即从源对象指向目标对象,以触发目标对象中的特定操作。对于对象到自身的消息,箭头就从同一个对象符号开始和结束。用消息(操作或信号)的名字及其参数值或者参数表达式标示箭头。

    消息表示为:

    消息返回表示为:

    同步消息:一般把它用于普通的过程调用。在外层控制恢复之前,要完成整个嵌套序列。通常把它用于普通的过程调用。 若在一个主动对象发送信号并等待完成一个嵌套的行为序列才继续时,也可以把它用于并发的主动对象。 

    异步消息:用它表示异步通讯,也即发送者发出消息后,立即继续执行中的下一步,不进行等待。

    4.接口

            从发送方到接受方的请求。

    消息:包括预期操作信息和完成操作所需要的数据,也即包含了控制信息也包含了数据。发送方构造消息、送到通讯系统;接受方从通讯系统取消息、解析消息、处理消息。

    接口:定义提供服务的一组操作,要处理的数据也通过接口传输。发送方产生调用、发出调用;接受方接收调用、执行操作。

    比较:接口定义严格且可视,消息需解析。

    5.信号

            对象之间的异步传送的消息的规格说明。信号名 ‘(‘用逗号分隔的参数列表‘)’从一个对象可以向另一个对象或对象的集合发送信号。例如消息广播。发送者在发送信号时,要实例化其参数。对于接收者来说,它收到的是一个事件。

            在类图中,在类符号上用关键字<<signal>>声明信号。把参数说明为属性。信号没有操作。在类的描述模板中,要指定所能接收的信号。通常用信号对异常情况建模。

     

    2、顺序图中的结构化控制

             序列性的消息能很好地说明单一的线性的序列,但是我们通常需要展示条件和循环。有时候我们想要展示多个序列的并行执行。在顺序图中用结构化控制操作符能展示这种高层控制。为了表示顺序图的边界,可以把顺序图用一个封闭的矩形包围起来,并在矩形的左上角放一个小五边形。在这个小五边形内先写上sd,再后面写出图的名字。对每个子顺序图加上一个矩形区域作为外框,再在其左上角放一个小五边形,在这个小五边形内写上用来表明控制操作符的类型的文字。 常见标签有:

    • 可选执行  标签是opt

            如果控制进入该操作符标识的交互区域时监护条件成立,那么执行该交互区域。监护条件是一个用方括号括起来的布尔表达式,它要出现在交互区域内部第一条生命线的顶端,在其中可以引用该对象的属性。 

    • 条件执行  标签为 alt。

            用水平虚线把交互区域分割成几个分区,每个分区表示一个条件分支并有一个监护条件。如果一个分区的监护条件为真,就执行这个分区,但最多只能执行一个分区。如果有多于一个监护条件为真,那么选择哪个分区是不确定的。若没有应对措施,在模型中要避免这种情况。如果所有的监护条件都不为真,那么控制流将跨过这个交互区域而继续执行。其中的一个分区可以用特殊的监护条件[else],这意味着如果其他所有区域的监护条件都为假,就执行该分区。 

    • 并行执行  标签是 par。

            用水平虚线把交互区域分割为几个分区。每个分区表示一个并发计算。当控制进入交互区域时并发地执行所有的分区;在并行分区都执行完后,那么该并行操作符标识的交互区域也就执行完毕。每个分区内的消息是顺序执行的。需要指出的是,并发并不总是意味着物理上的同时执行。并发其实是说两个动作没有协作关系,而且可按任意次序发生。如果它们确实是独立的动作,那么它们还可以交叠。 

    • 循环(迭代)执行  标签是 loop。

            在交互区域内的顶端给出一个监护条件。只要在每次迭代之前监护条件成立,那么循环主体就会重复执行。一旦在交互区域顶部的监护条件为假,控制就会跳出该交互区域。 

     

    案例:

    解释:

            用户启动这个序列。第一个操作符是循环操作符,圆括号内的数字(1,3)表示循环执行的最少次数和最多次数。因为最少是一次,所以在检测条件之前主体至少执行一次。在循环内,用户输入密码,系统验证它。只要密码不正确,那么该循环就会继续。但是,如果超过了三次,那么无论如何循环都会结束。

            下一个操作符是可选操作符。如果密码是正确的,那么就执行这个操作符的主体;否则就跳过该顺序图后面的部分。这个可选操作符的主体内还包括了一个并行操作符。正如图中所表明的,操作符可以嵌套。

    四、状态机图

            状态转换图(简称为状态图),通过描绘系统的状态及引起系统状态转换的事件,来表示系统的行为。此外,状态图还指明了作为特定事件的结果系统将做哪些动作(例如,处理数据)。

     1、重要概念

    1.状态

            状态是任何可以被观察到的系统行为模式,一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。系统对事件的响应,既可以是做一个(或一系列)动作,也可以是仅仅改变系统本身的状态,还可以是既改变状态又做动作。一张状态图中只能有一个初态,而终态则可以有0至多个。在实际系统中,无法建立全系统的状态图。

    2.事件

            事件是在某个特定时刻发生的事情,它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。例如,内部时钟表明某个规定的时间段已经过去,用户移动或点击鼠标等都是事件。简而言之,事件就是引起系统做动作或(和)转换状态的控制信息。在OO中,事件是对一个可观察的事情的规格说明,这种事情的发生可以引发状态的转换。事件可以分为多种:信号事件、调用事件、时间事件、改变事件

    1、举例

    1.绘制一个状态图,它能分析如下格式的字符流:‘<’标记串‘>’字母串;如deFC<ejb-name>Account;

    2.为简易微波炉(只有一个按钮)建模

    五、通信图

            通信图表示围绕着对象角色以及对象角色之间的链所组织的交互。通信图是一种强调发送和接收消息的对象结构组织的交互图,展示围绕对象以及它们之间的连接器而组织的交互。连接器是由关联实例化的链以及通过过程参数、局部变量或全局变量而产生的对象之间的临时连接。 通信图由对象(参与者) 、连接器以及连接器上的消息构成。这些概念及表示法与前述中的都完全相同。与顺序图不同:

    • 通信图表示扮演不同角色的对象之间的关系。
    • 通信图不表示作为单独维度的时间,所以交互的顺序和并发进程必须用顺序数决定。
    • 顺序图表示执行消息的显式顺序,最好用于描述实时系统和复杂的场景。

            为表示一个消息的时间顺序,可以给消息加一个数字前缀(从1号消息开始),在控制流中,每个新的消息的顺序号单调增加(如2,3等等)。为了显示嵌套,可使用带小数点的号码(1表示第一个消息;1.1表示嵌套在消息1中的第一个消息;1.2表示嵌套在消息1中的第二个消息;等等)。嵌套可为任意深度。要注意的是,沿同一个链,可以显示多个消息(可能发自不同的方向),并且每个消息都有唯一的一个顺序号。 顺序图和通信图在语义上是等价的,它们可以从一种形式的图转换为另一种。

    六、活动图

            活动图可用于对业务过程和操作的算法建模,活动图显示从活动到活动的流。活动可由动作和其他活动组成,最底层的活动是由动作执行的。在活动图中,动作和活动均具有图形表示法,且是一样的。

    1、控制流

          当动作或活动结束时,马上进入下一个动作或活动。一系列的动作和活动的执行构成了一个控制流。在图形上,用一个箭头表示从一个动作或活动到下一个动作或活动的转移 

    控制流也可以是并发的。用同步条表示并发控制流的分岔和汇合。 

     2、对象流 

     3、泳道

            在对业务过程建模时,可以把活动或动作分成组,每组由特定的履行者来执行。履行者可为人员、组织或其他业务实体。把每个组分别称为一个泳道。 

    七、包图

            对一个较为复杂的系统建模,要使用大量的模型元素,这时就必要把这些元素分组进行组织。这样把在语义上接近且倾向于一起变化的模型组织在一起,不但控制模型的复杂度,有助于理解,而且也有助于按组控制元素的可见性。包是对模型元素分组的机制。使用包的最常见目的是把建模元素组织成为组,作为一个集合进行命名和处理。包可以拥有类、接口、构件、节点、用况和图,甚至可以是其它包。拥有是一种组成关系,这意味着被拥有的元素被声明在包中。如果包被撤消了,元素也要被撤消。  一个元素只能被一个包所拥有。设计良好的包,把在语义上接近并倾向于一起变化的元素组织在一起。因此结构良好的包是松耦合、高内聚的,而且对其内容的访问具有严密的控制。 

     1、基本事项

    1.包的层次性

            因为包中还可以有包,这样包之间可以有一个层次,且在组织结构上是一棵严格的树。在实际使用中,最好要避免过深地嵌套包,一般两、三层即可。对过多的嵌套,要用“引入依赖”来组织包。

    2.对包中元素的命名

            一个包形成了一个命名空间,这意味着在一个包的语境中同一种元素的名字必须是唯一的。例如,同一个包不能拥有两个名为Queue的类,但在P1包中可以有一个名为Queue的类,而在P2包中又有另一个(不同的)名为Queue的类。实际上,类P1::Queue和类P2::Queue是不同的类,这可以由各自的路径名区别开来。如果一个包位于另一个包中,外层的包可作为里层包的前缀。例如,在包Vision中有一个名为Camera的类,而包Vision又在包Sensor中。类Camera的全名为Sensor::Vision::camera。

    3.包中元素的可见性

            一个包中的元素在包外的可见性,通过在元素名字前加上一个可见性符号来指示。模型元素的可见性可为+(公共的)、-(私有的)、 #(受保护的) 或~(包范围的),它们的含义为:

    +:标有“+”号的模型元素对所有的引入包以及它们的后代是可见的。包的各公共部分一同构成包的接口。

    -:标有“-”号的模型元素只对包内的元素是可见的。

    #:标有“#”号的模型元素只对那些与包含这些元素的包有泛化关系的子包是可见的。

    ~:标有“#”号的模型元素只对在同一包内声明的其他元素是可见的。

    4.包的用处

         1、组织相关元素,以便于管理和便于复用。包是一个命名空间,外部使用要加限定名。

         2、包引入放松了限制。被引入的元素与引入包中的元素可以进行关联,或建立泛化关系。

         3、便于组合可复用的元建模特征,以创建扩展的建模语言。也即把被合并包的特征结合到合并包,以定义新的语言。

    5.如何划分包

    • 识别低层包

    每个具有泛化关系或聚合关系的元素位于一个包

    关联密集的类划分到一个包

    独立的类暂时作为一个包

    • 合并或组织包

    如果低层包数量过多,则把它们合并,或用高层包组织它们。

    若低层包之间在概念上接近或具有较强的相关性,从作用上属于某项大的功能,在图上有较强的耦合性,或在分布上处于同一台处理机,则考虑把它们合并,或用高层包组织它们。

    建议每个包有7±2个内层成分。——在一张A4纸上表达不清楚时就划分包(Martin Fowler)

     

    2、包间的关系

            包之间不但可以具有拥有关系,包之间也可以具有引入关系、访问关系或泛化关系。

    • 引入依赖:是两个包之间的一种许可依赖关系,一个包中的可见性为公有的模型元素,可以在指定的包(包括嵌套在该包中的子包)中被引用,相当于把提供者包的内容附加到客户包的公共命名空间中,而不必对名称进行限制。把引入依赖绘制成带有箭头的虚线,其上标有串<<import>>。
    • 访问依赖:是两个包之间的一种许可依赖关系,一个包中的可见性为公有的模型元素,可以在指定的包(包括嵌套在该包中的子包)中被引用,相当于把提供者包的内容附加到客户包的私有命名空间中,而不必对名称进行限制。把访问依赖绘制成带有箭头的虚线,其上标有串<<access>>。
    • 泛化关系:与类间的泛化很类似,即特殊包可以继承一般包中的可见性为公共的或受保护的元素,而且在特殊包中还可以有自己的元素,自己的元素可以覆盖继承来的元素。 

     

    展开全文
  • 什么是UMLUML类图

    万次阅读 多人点赞 2018-07-17 08:05:16
    1.什么是UML?  UML是统一建模语言,是一种可视化的面向对象建模语言,是一种用来对真实世界物理进行建模的标准标记,用图形方式表现典型的面向对象系统的整个结构。它的作用域不局限于支持面向对象的分析与设计,...
  • uml

    2019-05-14 10:43:08
    类图(class diagram) 描述一组类、接口、协作和它们之间的关系 对象图(object diagram) 描述一组对象及它们之间的关系 包图(package diagram) 描述由模型本身分解而成的组织单元,以及它们之间的依赖关系。...
  • UML 是统一建模语言的简称,它是一种由一整套图表组成的标准化建模语言。UML用于帮助系统开发人员阐明,展示,构建和记录软件系统的产出。UML代表了一系列在大型而复杂系统建模中被证明是成...
  • 浅谈UML中常用的几种图

    万次阅读 多人点赞 2020-01-08 16:33:02
    浅谈UML中常用的几种 浅谈UML中常用的几种图 1.UML简介 2.UML常见图分类 3.用例图 浅谈UML中常用的几种图——类图 第三次作业—画类图 浅析UML之时序图 协作图(Collaboration Diagram)—UMLUML之状态...
  • UML是什么?

    千次阅读 2018-11-04 16:40:03
      统一建模语言(Unified Modeling Language——UML)是一种面向对象的建模语言,它可以实现大型复杂系统各种成分描述的可视化、说明并构造系统模型,以及建立各种所需的文档,是一种定义良好、易于表达、功能强大...
  • UML(统一建模语言)

    万次阅读 多人点赞 2018-09-24 14:27:13
    软件设计和软件工程 任何事情都要先想清楚了才能做,软件开发更是如此!软件开发过程不可能一上来就开始盲目写代码,写代码之前必须搞清楚下面一些基本问题: 1、要做什么? 2、做成什么样?...
  • uml实例uml实例uml实例uml实例uml实例

    千次下载 热门讨论 2020-06-27 23:30:16
    uml实例uml实例uml实例uml实例uml实例uml实例uml实例uml实例uml实例uml实例uml实例uml实例uml实例uml实例uml实例uml实例uml实例uml实例
  • UML图-类与接口

    千次阅读 2019-08-26 11:29:47
    UML 图 —— 类之间的关系 UML-类图 UML-接口图 UML-继承关系 UML-实现关系 UML 图 —— 类之间的关系 UML-Unified Module Language 统一建模语言,可以很方便的用于描述类的属性,方法,以及类和类之间的关系...
  • UML学习笔记--导航

    千次阅读 2016-01-19 16:48:02
    UML基础概述 UML与需求分析 UML类图与对象图 UML活动图 UML状态机图 UML顺序图和通信图 UML用例图 UML部署图和构件图 UML包图 UML与需求分析进阶 UML全家福 考勤管理系统需求文档
  • UML 官方规范文档列表

    2019-06-15 11:26:27
    2019独角兽企业重金招聘Python工程师标准>>> ...
  • Axure 的UML设计元件库

    2020-07-30 23:33:16
    基于Axure的UML绘图元件库。可用于绘制UML用例图、流程图、时序图、泳道图、状态机图、类图等。
  • 最全UML【统一建模】视频之8套视频

    千次阅读 2019-08-19 18:35:23
    第一套:【圣思园】UML教程 第二套:【尚学堂】UML教程 第三套:UML统一建模基础教程 第四套:【传智播客】韩顺平 uml视频教程 第五套:UML基础到实战教程 带项目案例 第六套:【东华大学】面向对象建模技术...
  • UML讲义UML讲义UML讲义

    2020-05-25 23:30:17
    UML讲义UML讲义UML讲义UML讲义UML讲义UML讲义UML讲义UML讲义UML讲义UML讲义UML讲义UML讲义UML讲义UML讲义
  • 免费的UML工具

    万次阅读 2017-12-11 14:03:03
    Visual Paradigm Community Edition是自2004年以来推出的,旨在提供免费的UML软件,用于非商业目的,支持在UML建模方面迈出第一步的用户,以及需要免费的跨平台UML建模软件的用户个人使用,如在学生项目中使用UML。...
1 2 3 4 5 ... 20
收藏数 210,542
精华内容 84,216
关键字:

uml