UML是一U通用的徏模语aQ其表达能力相当的强Q不仅可以用于Y件系l的建模Q而且可用于业务徏模以及其它非软gpȝ建模。UMLl合了各U面向对象方法与表示法的优点Q至提出之日起就受到了广泛的重视q得C工业界的支持?
本章按视图、模型元素、图以及公共机制依次介绍UML的构造和基本元素Q以使得读者对UML有一个M了解Q其具体l节在后箋章节中详l描q?/p>
d工具QeDraw、jude
Ƣ迎大家l箋支持和关注我的博客:
http://blog.csdn.net/IBM_hoojo
也欢q大家和我交、探讨IT斚w的知识?/p>
emailQ?a href="mailto:hoojo_@126.com">hoojo_@126.com
如果你觉得本文不错的话,请你点击屏幕右下方的
。如果你以后会用到这文章的或觉得以后要重新阅的话Q你可以点击屏幕右下角的
。如果你觉得我的博文不错或是惛_W一旉看到我的动态的话,你可以点dq右下角
。如果你惌点什么的话,你可以点dq右下方?a >
。如果你都点q了Q那真的太谢谢你了,兄弟太支持了。此Ӟ或许你可以点?a >
按钮Q然后看看博文的Dl箋览其他文章?/p>
1. UML的组?/font>
UMLp?View)、图(Diagram)?a name="OLE_LINK13">模型元素(Model Element)?a name="OLE_LINK14">通用机制(General Mechanism){几个部分组成?
a) 视图(View)Q?是表辄l的某一斚w的特征的UML建模元素的子集,由多个图构成Q是在某一个抽象层上,对系l的抽象表示?
b) ?Diagram)Q?是模型元素集的图形表C,通常是由弧(关系Q和点Q其他模型元素)怺q接构成的?
c) 模型元素(Model Element)Q代表面向对象中的类、对象、消息和关系{概念,是构成图的最基本的常用概c?
d) 通用机制(General Mechanism)Q用于表C其他信息,比如注释、模型元素的语义{。另外,UMLq提供扩展机Ӟ使UML语言能够适应一个特D的ҎQ或q程Q,或扩充至一个组l或用户?
2. UML视图的分c?/font>
UML是用来描q模型的Q用模型来描q系l的机构或静态特征,以及行ؓ或动态特征。从不同的视角ؓpȝ构架建模QŞ成系l的不同视图?
(1) 用例视图(Use Case View)Q?/strong>从用L角度看到的或需要的pȝ功能Q是被称为参与者的外部用户所能观察到的系l功能的模型图?
(2) 逻辑视图(Logical View)Q?/strong>展现pȝ的静态或l构l成及特征,也称为结构模型视?Structural Model View)或静态视?Static View)?
(3) q发视图(Concurrent View)Q?/strong>体现了系l的动态或行ؓ特征Q也UCؓ行ؓ模型视图(Behavioral Model View)或动态视?Dynamic View)?
(4) lg视图(Component View)Q?/strong>体现了系l实现的l构和行为特征,也称为实现模型视?Implementation Model View)?
(5) 配置视图(Deployment View)Q?/strong>体现了系l实现环境的l构和行为特征,也称为环境模型视?Environment Model View)或物理视?Physical View)?
视图是由囄?/b>的,UML提供9U不同的图:
(1) 用例?/a>(Use Case Diagram)Q描q系l功能;
(2) cd(Class Diagram)Q描q系l的静态结构;
(3) 对象?Object Diagram)Q描q系l在某个时刻的静态结构;
(4) lg?Component Diagram)Q描qC实现pȝ的元素的l织Q?
(5) 配置?Deployment Diagram)Q描qC环境元素的配|,q把实现pȝ的元素映到配置上;
(6) 状态图(State Diagram)Q描qCpȝ元素的状态条件和响应Q?
(7) 时序?Sequence Diagram)Q按旉序描述pȝ元素间的交互Q?
(8) 协作?Collaboration Diagram)Q按照时间和I间序描述pȝ元素间的交互和它们之间的关系Q?
(9) zd?Activity Diagram)Q描qCpȝ元素的活动;
建模Ҏ?b>建模语言和徏模过E?/b>两部分构成。其中徏模语a是用来表q设计方法的表示法,建模q程是对设计中所应采取的步骤的描q。UML是一U徏模语aQ它在很大程度上独立于徏模过E。在实际建模中,建模人员最好把UML用于以用案驱动的、以体系机构Z心的、P代的和渐增式的开发过E中?
一般而言QY件系l的体系l构l出了Y件系l的l织、组成系l的构造元素及其接口的选择、系l的行ؓ和体pȝ构风格等信息。也是_它不仅关心系l的l构和行为等功能性需求,而且也涉及系l的性能、易理解性、易复用性等非功能性需求。如下图所C,UML利用用户模型视图、结构模型视图、行为模型视图、实现模型视囑֒环境模型视图来描qY件系l的体系l构?
Ҏ它们在不同架构视囄应用Q可以把9U图分成Q?/b>
(1) 用户模型视图Q用例图Q?/a>
(2) l构模型视图Q类囑֒对象Q?
(3) 行ؓ模型视图Q状态图、时序图、协作图和活动图Q动态图Q;
(4) 实现模型视图Q组件图Q?
(5) 环境模型视图Q配|图?
用户模型视图׃门描q?b>最l用戗分析h员和试人员看到的系l行为的用案l成Q它实际上是从用戯?/b>来描q系l应该具有的功能。用h型视图所描述的系l功能依靠外部用h者另外一个系l来Ȁz,为用h者另一pȝ提供服务Q从而实现用h另一pȝ与系l的交互。系l实现的最l目标是提供用户模型视图中所描述的功能。在UML中,用户模型视图是由用案囄?/b>?
l构模型视图描述l成pȝ?b>cR对象以及它们之间的关系{静态结构,用来支持pȝ的功能需求,xq系l内部功能是如何设计的。结构模型视囄cd和对象图构成Q?b>主要供设计h员和开发h员?/b>?
行ؓ模型?/b>图主要用来描qŞ?b>pȝq发与同步机制的U程和进E?/b>Q其x的重Ҏpȝ的性能、易伸羃性和pȝ的吞吐量{非功能性需求。行为模型视囑ֈ用ƈ发来描述资源的高效用、ƈ行执行和处理异步事g。除了讲pȝ划分为ƈ发执行的控制U程之外Q行为模型还必须处理通信和这些线E及q程之间的同步问题。行为模型视图主要供pȝ开发h员和pȝ集成人员使用Q它?b>序列图、协作图、状态图和活动图l成?
实现模型视图用来描述pȝ的实现模块它们之间的依赖关系以及资源分配情况。这U视图主要用于系l的配置理Q它是由一些独立的构gl成的。实现模型视囄构g囄?/b>。其中构件是代码模块Q不同类型的代码模块形成不同的构件。实现模型视图主要供开发h?/b>使用?
环境模型视图用来描述物理pȝ?b>g拓扑l构。例如,pȝ中的计算机和讑֤的分布情况以及它们之间的q接方式Q其中计机和设备统UCؓ节点。在UML中环境模型视图是由部|图来表C的。系l部|图描述了系l构件在节点上的分布情况Q即用来描述软g构g到物理节点的映射。部|图主要?b>开发h员、系l集成h员和试人员使用?
上面每一U视囑֏映了pȝ的一个特定方面,不同人员可以单独的用其中每一U视图,从而可以关注特定的体系l构问题。但在通常情况下,׃pȝ的最l目标是提供用户模型视图中描q的功能以及其它一些非功能性需求,因此Q用h型视图是其它视图的核心基Q其它视囄构造都依赖与用h型视图中所描述的类宏V?
l心的读者已l发玎ͼ每一UUMLN是由多个囄成的Q每一U图都是体系l构某个侧面的表C,各种囑֮际上是一致的Q所有的囑֜一L成了pȝ的完整视图。如下图所C,UML中d提供了用案图、类图、对象图、序列图、协作图、状态图、活动图、构建图和部|图9U图。根据它们描q的是系l的静态结构还是动态行为,可以它们分为静态图和动态图两类。再q一步介l这9中UML图时Q先了解下什么是模型元素Q?
3. UML的徏模机?/b>
UML有两套徏模机Ӟ静态徏模机制和动态徏模机制。静态徏模机制包括用例图、类图、对象图、包、组件图和配|图。动态徏模机制包括状态图、时序图、协作图、活动图?
(1) 用例图:用例的可视化工具Q它提供计算机系l的高层ơ的用户视图Q表CZ外部zd者的角度来看pȝ是怎样使用的?
用例图(用案图)是用于描qCl用案,参与者以及它们之间的q接关系。一个用案图描述了一l动作序列,每一个序列表C系l的外部设施Q系l的参与者)与系l本w的交互。从一个特定参与者的角度看,一个用案完成对其有价值的工作。如?.5所C,用案图仅仅是从参与者用系l的角度来描q系l中的信息,即站在系l外部查看系l应该具有什么功能,而ƈ不描q该功能在Y件内部是如何实现的。用案可以应用于整个pȝQ也可以应用于系l的一个部分,包括子系l、单个的cL者接口。通常Q用案不仅代表这些元素所期望的行为,而且q可以把q些元素用作开发过E中试用案的基?
用例囑括以?斚w内容Q?
(a) 用例(Use Case)
(b) 参与?Actor)
(c) 依赖、泛化和兌关系
用例囄例:
(2) cdQ描q类、接口、协作以及它们之间关pȝ图?
cd是用于描qCl类、接口、协作以及它们之间的静态关pR在面向对象pȝ的徏模中Q类图是最为常用的图,它用来阐明系l的静态结构。事实上cL对一l具有相同属性、操作、关pd语义的对象的描述Q其中对cȝ属性和操作q行描述时的一个最重要的细节就是它的可见性?
cd以以多种形式q接Q例如关联、泛化、依赖和实现{。一个典型的pȝ中通常有若q个cd。一个类图不一定要包含pȝ中所有的c,一个类可以加到几个cd中?
cdCZQ?
(3) 对象图:表示在某一旉上一l对象以及它们之间的关系的图。对象图可以被看做是cd在系l某一时刻的实例?
对象图是cd的实例,用来描述特定q行时刻一l对象之间的关系。也是_对象用于描述交互的静态部分,它由参与协作的有兛_象组成。但不包括在对象之间传递的M消息?
在创建对象图Ӟ建模人员q不需要用单个的对象图来描q系l中的每一个对象。事实上Q绝大多数系l中都会包含成百上千的对象。用对象来描q系l的所有对象以及它们之间的关系一般是不太现实的。因此,建模人员可以选择所感兴的对象极其之间的关pL描述?
对象图中所使用的符号和cd中用的W号几乎完全相同Q区别仅在于对象囄对象名带有下划线Q而且cMcM间关pȝ所有的实例都要d来?
(4) lg?/a>Q描qY件组件以及组件之间的关系Q组件本w是代码的物理模块,lg囑ֈ昄了代码的l构?
lg图(构g图)是用于描qCl构件之间的l织和依赖关p,用于建模pȝ的静态实现视图。构件可以是可执行程序集、库、表、文件和文{,它包含了逻辑cL者逻辑cȝ实现信息Q因此结构模型视囑֒实现模型视图之间存在映射关系?
构徏图中也可以包括包或子pȝQ它们都是用于将模型元素l成较大的组块?
lg图例图:
(5) 配置?/a>Q描q系l硬件的物理拓扑l构以及在此l构上执行的软g。配|图可以昄计算节点的拓扑结构和通信路径、结点上q行的Y件组件、Y件组件包含的逻辑单元Q对象、类Q等。配|图常常用于帮助理解分布式系l?
配置图(部v图)用来描述pȝq行是进行处理的节点以及在节点上zd的构件的配置。部|图用来对系l的环境模型视图q行建模。在大多数情况下Q部|图用来描述pȝg的扩普结构?
在UML中,建模人员可以用类图来描述pȝ的静态结构,可以用序列图、协作图、状态图、活动图来描q系l的动态行为,而用部v图来描述软g所执行所需的处理器和设备的拓扑l构?
(6) 状态图Q通过cd象的生命周期建立模型来描q对象随旉变化的动态行为?
状态图实际上是一U由状态、变q、事件和zdl成的状态机。状态图描述从状态到状态的控制,常用于系l的动态特性徏模。在大多数情况下Q它用来对反应型对象的行为徏模?
在UML中,状态图可以用来对一个对象按事g排序的行为徏模。一个状态图是强调从状态到状态的控制的状态机的简单表C。一般而言Q状态图是对cL描述的设施的补充说明Q它描述了类的所有对象可能具有的状态以及引L态变化的事g?
(7) 时序图:交互图描qC一个交互,它由一l对象和它们之间的关pȝ成,q且q包括在对象间传递的信息。交互图表达对象之间的交互,是描qCl对象如何协作完成某个行为的模型化工兗?
序列囑֒协作囄UCؓ交互图。其中,序列囄来描q对象之间消息发送的先后ơ序Q阐明对象之间的交互q程以及在系l执行过E中的某一具体时刻会发生什么事件。序列图是一U强调时间顺序的交互图,其中对象沿横轴方向排列,消息沿纵轴方向排列?
序列图中的对象生命线是一条垂直的虚线Q它表示一个对象在一D|间内存在。由于序列图中大多数对象都存在于整个交互q程中,因此q些对象全部排列在图的顶部,它们的生命线从图的顶部画到图的底部。每个对象的下方有一个矩形条Q它与对象的生命UK叠,它表C对象的控制焦炏V序列图中的消息可以有序P但由于这U图上的消息已经从纵轴上按时间顺序排序,因此消息序号通常予以省略?
(8) 协作图:包含cd角色和关联角Ԍ而不仅仅是类元和兌。协作图参加交互的各对象的组l。协作图只对怺间有交互作用的对象和q些对象间的关系建模Q而忽略了其他对象和关联。协作图也是一U交互图Q它收发消息的对象的l织l构?
协作囑֒序列图是协作的,它们可以互相转换。在多数情况下,协作图主要对单调的、顺序的控制徏模,但它也可以用来对包括q代和分支在内的复杂控制进行徏模?
一般而言Q徏模h员可以创建多个协作图Q其中一些是主要的,另外一些是可选择的\径或者异常条件。徏模h员可以用包来l织q些协作图,q给每个图v一个合适的名字Q以便与其它囑别开?
(9) zd图:用于展现参与行ؓ的类的活动或动作?
zd图是状态图的一U特D情况,其中几乎所有或大多数状态都处于zd状态,而且几乎所有或者大多数变迁都是由源状态中zd的完成触发的。活动图本质上是一U流E图Q它描述了从zd到活动的控制?
可以把活动图看作是新L交互图,但交互图观察的是传递消息的对象Q而活动图观察到的是对象之间传送的消息。尽两者在语义上的区别很细微,但它们用不同的方式来看pȝ的?
如果你觉得本文不错的话,请你点击屏幕右下方的
。如果你以后会用到这文章的或觉得以后要重新阅的话Q你可以点击屏幕右下角的
。如果你觉得我的博文不错或是惛_W一旉看到我的动态的话,你可以点dq右下角
。如果你惌点什么的话,你可以点dq右下方?a >
。如果你都点q了Q那真的太谢谢你了,兄弟太支持了。此Ӟ或许你可以点?a >
按钮Q然后看看博文的Dl箋览其他文章?/p>
最后,Ƣ迎大家l箋支持和关注我的博客:
http://blog.csdn.net/IBM_hoojo
也欢q大家和我交、探讨IT斚w的知识?/p>
本h是做Java开发的Q在E序开发中会经怋用到OpenSource开源框Ӟq些框架大多都灵zR简单、易用、方ѝ而且开源框架一般会提供一些基本的配置Q如我们常用的框架就有Hibernate要配|对象实体到数据库的映射QSpring要配|bean的管理及其对象、属性的注入QStruts要配|Action对象和返回的资源路径QMyBatis要配|CRUDQ增删改查)的相关SQL语句。这些配|你不能省略Q必d有,没有E序也不会自动添加。我们也是极可能的简化这些配|,不管怎么L化但q些配置是不能省略,虽然q些框架l我们开发程序都提供了很大方面上的便利?/p>
但有时候你是否有纠l这么样的一个问题:到底是用XML配置Q还是用Annotation注解配置Q或是用XML和Annotation混合配置Q?/font>
首先看看两种配置的优~点比较
XML它是无可代替的超文本标记语言Q可L、传输性好Q它q具有一下优点:
1、可L、传输性好QXML可扩展标记语aQ最大的优势在于开发者能够ؓ软g量n定制适用的标讎ͼ使代码可L大大提升?br>2、灵zL、易用性、扩展性、移植性好Q利用XML配置能软g更具扩展性。如Springclass间的依赖配置在XML中,最大限度地提升应用的可扩展性。同P如果是基于接口注入方式,可以随便切换接口实现c进行注入即可?br>3、验证机Ӟh成熟的验证机制确保程序正性。利用Schema或DTD可以对XML的正性进行验证,避免了非法的配置D应用E序出错?br>4、修攚w|而无需变动现有E序、无需重新~译?
虽然XML有如此多的好处,但它也不是万能的QXML也有自n的缺点:1、开发友好性支持:需要解析工hcd的支持。如果你的XML配置需要用到XML的提C或是解析编译,需要用到Schema或DTDq行验证?br>2、性能影响Q解析XML势必会媄响应用程序性能Q占用系l资源。至你会用C些解析XML的技术去解析节点元素内容?br>3、维护性高Q配|文件过多导致管理变得困难?br>4、编译期无法对其配置的正确性进行验证,或要查错只能在运行期。如Spring Bean配置了一个错误的c\径class?br>5、IDE 无法验证配置的正确性无能ؓ力。如Spring注入一个错误的对象或属性?br>6、查错变得困难。往往配置的一个手误导致莫名其妙的错误?br>7、开发h员不得不同时l护代码和配|文Ӟ开发效率变得低下?br>8、配|项与代码间存在潜规则,改变了Q何一斚w有可能媄响另外一斏V?
让我们来看看Annotation的优?br>1、保存在class文g中,降低l护成本?br>2、无需工具支持Q无需解析?br>3、编译期卛_验证正确性,查错变得ҎQ虽然有部分错误需要在q行期间才能看到?br>4、配|简单、简U,提升开发效率?
同样Annotation也不是万能的Q它也有很多~点1、若要对配置进行修改,不得不修改Java文gQ重新编译打包应用?br>2、配|项~码在Java文g中,可扩展性差、移植性性低?
那到底用什么样的配|呢Q在q里我谈谈我个h的看法:
1、在开发期间我们用Annotation注解Q这样在一定程度上不仅可以省去对XML配置文g的维护,而且大大的提高了开发效率,~短了开发周期?br>2、开发后期,目功能完成Q我们可以将Annotation配置转换为XML配置Q禁用Annotation卛_。这样做的理由是如果目上线Q我们需要修改相关代码的配置Q直接改XML、properties配置文g卛_。这样就不需要开发h员找到相应的代码修改源代码、重新编译打包发布。而xml的配|是可以直接修改的,不需要重新编译,只需重启下你的服务器卛_?如果q样是不是即利用到框架给我们提供的Annotation注解Q也利用CXML配置。充分的发挥了开源框架给我们提供的技术应用?
3、合模式,Annotation和XML怺q用。需要动态配|、后期经常性修改的qXML配置Q如果是不怎么修改的就用Annotation。或许这U合模式更适合我们Q你觉得呢?O(∩_?O~