用uml做订单类型有哪些分类应该用什么图

首页 文档 视频 音频 文集

点击文档標签更多精品内容等你发现~


VIP专享文档是百度文库认证用户/机构上传的专业性文档,文库VIP用户或购买VIP专享文档下载特权礼包的其他会员用戶可用VIP专享文档下载特权免费下载VIP专享文档只要带有以下“VIP专享文档”标识的文档便是该类文档。

VIP免费文档是特定的一类共享文档会員用户可以免费随意获取,非会员用户可以通过开通VIP进行获取只要带有以下“VIP免费文档”标识的文档便是该类文档。

VIP专享8折文档是特定嘚一类付费文档会员用户可以通过设定价的8折获取,非会员用户需要原价获取只要带有以下“VIP专享8折优惠”标识的文档便是该类文档。

付费文档是百度文库认证用户/机构上传的专业性文档需要文库用户支付人民币获取,具体价格由上传人自由设定只要带有以下“付費文档”标识的文档便是该类文档。

共享文档是百度文库用户免费上传的可与其他用户免费共享的文档具体共享方式由上传人自由设定。只要带有以下“共享文档”标识的文档便是该类文档

还剩23页未读, 继续阅读
}

1) 类(Class)封装了数据和行为是面向对潒的重要组成部分,它是具有相同属性、操作、关系的对象集合的总称

2) 在系统中,每个类具有一定的职责职责指的是类所担任的任务,即类要完成什么样的功能要承担什么样的义务。一个类可以有多种职责设计得好的类一般只有一种职责,在定义类的时候将类的職责分解成为类的属性和操作(即方法)。

3) 类的属性即类的数据职责类的操作即类的行为职责

依赖关系(Dependence):假设A类的变化引起了B类的變化,则说名B类依赖于A类

?  依赖关系(Dependency) 是一种使用关系,特定事物的改变有可能会影响到使用该事物的其他事物在需要表示一个事物使鼡另一个事物时使用依赖关系。大多数情况下依       赖关系体现在某个类的方法使用另一个类的对象作为参数。

?   在UML中依赖关系用带箭头嘚虚线表示,由依赖的一方指向被依赖的一方

      图字:由于Reporting Tool组件绘制在IBM WebSphere内部,后者又绘制在节点内部因而我们知道,用户将通过运荇在本地机器上的浏览器来访问Reporting Tool浏览器通过公司intranet上的HTTP协议与Reporting Tool建立连接。

    WebSphere内部后者又绘制在节点内部。Reporting Tool使用Java语言通过IBM DB2数据库的JDBC接口连接箌它的报告数据库上然后该接口又使用本地DB2通信方式,与运行在名为的服务器上实际的DB2数据库通信除了与报告数据库通信外,Report

      尽管本文仅提供了对统一建模语言UML的简要介绍但还是鼓励大家把从这里学到的基本信息应用到自己的项目中,同时更深入地钻研UML已经有哆种软件工具可以帮助您把UML图集成到软件开发过程中,不过即使没有自动化的工具您也可以使用白板上的标记或者纸和笔来手工绘制UML图,仍然会获益匪浅

    用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型圖

      【用途】:帮助开发团队以一种可视化的方式理解系统的功能需求。

      用例图所包含的元素如下:

       MVC作为表示层整体使用彡层架构。那么用户模块体系的实现类图大体是这样子(不准确):
          有了静态结构,我们还要给出动态结构这样,才能看清系统间的類是如何交互的从而有效帮助程序员进行编码工作。
    上图给出的是用户登录的序列图首先注册会员作为Actor,调用UserController的Login方法启动序列然后序列按图示步骤执行。其中UserServices作为业务组件首先调用数据访问组件的GetByName确定用户是否存在,如果存在再调用GetByNameAndPassword确定输入密码是否是此用户的密码。从而完成业务功能
          要注意,序列图在实际中是很多的几乎每个类方法都配有相应的序列图。
          在完成了上面的过程后就可以进荇编码、调试、测试等工作了。但这些已经超出了本文讨论的范围
    本文简要给出了使用UML进行OOA&D的过程。当然由于示例较小,而且本人水岼有限所以给出的相关内容可能不是很准确。而且软件分析设计本来就不是一个固定模式的过程随着系统的不同整个过程会有变化。夲文只是想起到一个抛砖引玉的作用让朋友们大致了解UML的使用流程。至于实际的分析设计还需要深入的学习和实践的积累。

    继承、实現、依赖、关联、聚合、组合的联系与区别

    指的是一个类(称为子类、子接口)继承另外的一个类(称为父类、父接口)的功能并可以增加它自己的新功能的能力,继承是类与类或者接口与接口之间最常见的关系;在Java中此类关系通过关键字extends明确标识在设计时一般没有争議性;

    指的是一个class类实现interface接口(可以是多个)的功能;实现是类与接口之间最常见的关系;在Java中此类关系通过关键字implements明确标识,在设计时┅般没有争议性;

    可以简单的理解就是一个类A使用到了另一个类B,而这种使用关系是具有偶然性的、、临时性的、非常弱的但是B类的變化会影响到A;比如某人要过河,需要借用一条船此时人与船之间的关系就是依赖;表现在代码层面,为类B作为参数被类A在某个method方法中使用;

    他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系比如我和我的朋友;这种关系比依赖更强、不存在依赖关系的耦然性、关系也不是临时性的,一般是长期性的而且双方的关系一般是平等的、关联可以是单向、双向的;表现在代码层面,为被关联類B以类属性的形式出现在关联类A中也可能是关联类A引用了一个类型为被关联类B的全局变量;

    聚合是关联关系的一种特例,他体现的是整體与部分、拥有的关系即has-a的关系,此时整体与部分之间是可分离的他们可以具有各自的生命周期,部分可以属于多个整体对象也可鉯为多个整体对象共享;比如计算机与CPU、公司与员工的关系等;表现在代码层面,和关联关系是一致的只能从语义级别来区分;

    组合也昰关联关系的一种特例,他体现的是一种contains-a的关系这种关系比聚合更强,也称为强聚合;他同样体现整体与部分间的关系但此时整体与蔀分是不可分的,整体的生命周期结束也就意味着部分的生命周期结束;比如你和你的大脑;表现在代码层面和关联关系是一致的,只能从语义级别来区分;

    对于继承、实现这两种关系没多少疑问他们体现的是一种类与类、或者类与接口间的纵向关系;其他的四者关系則体现的是类与类、或者类与接口间的引用、横向关系,是比较难区分的有很多事物间的关系要想准备定位是很难的,前面也提到这幾种关系都是语义级别的,所以从代码层面并不能完全区分各种关系;

    但总的来说后几种关系所表现的强弱程度依次为:组合>聚合>关联>依赖;

    聚合跟组合其实都属于关联 只不过它们是两种特殊的关联 因为本是同根生 所以它们之间难免会有相似之处 下面让我们一起来看一下咜们之间有何不同

    聚合与组合的概念相信不用我在此赘述大家就已经了解了 下面直接上例子

    程老师的《大话》里举大那个大雁的例子很贴切 在此我就借用一下 大雁喜欢热闹害怕孤独 所以它们一直过着群居的生活 这样就有了雁群 每一只大雁都有自己的雁群 每个雁群都有好多大雁 大雁与雁群的这种关系就可以称之为聚合 另外每只大雁都有两只翅膀 大雁与雁翅的关系就叫做组合 有此可见 聚合的关系明显没有组合紧密 大雁不会因为它们的群主将雁群解散而无法生存 而雁翅就无法脱离大雁而单独生存——组合关系的类具有相同的生命周期

    从从代码上看這两种关系的区别在于:

    聚合关系的类里含有另一个类作为参数 
    雁群类(GooseGroup)的构造函数中要用到大雁(Goose)作为参数把值传进来 大雁类(Goose)鈳以脱离雁群类而独立存在 
    组合关系的类里含有另一个类的实例化 
    大雁类(Goose)在实例化之前 一定要先实例化翅膀类(Wings) 两个类紧密耦合在┅起 它们有相同的生命周期 翅膀类(Wings)不可以脱离大雁类(Goose)而独立存在
    信息的封装性不同 
    在聚合关系中,客户端可以同时了解雁群类和夶雁类因为他们都是独立的 
    而在组合关系中,客户端只认识大雁类根本就不知道翅膀类的存在,因为翅膀类被严密的封装在大雁类中

    UML-泛化、关联、聚合、组合、依赖

    表示类与类之间的继承关系,接口与接口之间的继承关系或类对接口的实现关系。一般化的关系是从孓类指向父类的与继承或实现的方法相反。

    父类 父类实例=new 子类();

    对于两个相对独立的对象当一个对象的实例与另一个对象的一些特定實例存在固定的对应关系时,这两个对象之间为关联关系

    表示类与类之间的联接,有双向关联和单向关联双向关联有两个箭头或者没囿箭头,单向关联有一个箭头表示关联的方向。

    关联关系以实例变量的形式存在在每一个关联的端点,还可以有一个基数(multiplicity),表明这一端點的类可以有几个实例

    双向关联在代码的表现为双方都拥有对方的一个指针,当然也可以是引用或者是值

    关联关系是使用实例变量来實现。

    关联关系的一种是强的关联关系。聚合是整体和个体的关系聚合关系也是通过实例变量实现的。例如汽车、发动机、轮胎一個汽车对象由一个发动机对象,四个轮胎对象组成

    当类之间有整体-部分关系的时候,我们就可以使用组合或者聚合

    与关联关系一样,聚合关系也是通过实例变量来实现这样关系的关联关系和聚合关系来语法上是没办法区分的,从语义上才能更好的区分两者的区别

    四、组合关系(合成关系)(composition)

    合成关系也是关联关系的一种,是比聚合关系更强的关系合成关系是不能共享的。例如人有四肢、头等

    表示类之间整体和部分的关系,组合关系中部分和整体具有统一的生存期一旦整体对象不存在,部分对象也将不存在部分对象与整体對象之间具有共生死的关系。

    //同聚合关系不过说语义不同

    对于两个相对独立的对象,当一个对象负责构造另一个对象的实例或者依赖叧一个对象的服务时,这两个对象之间主要体现为依赖关系

    与关联关系不同的是,依赖关系是以参数变量的形式传入到依赖类中的依賴是单向的,要避免双向依赖一般来说,不应该存在双向依赖

    依赖是一种弱关联,只要一个类用到另一个类但是和另一个类的关系鈈是太明显的时候(可以说是“uses”了那个类),就可以把这种关系看成是依赖

    依赖关系表现在局部变量,方法的参数以及对静态方法嘚调用

    (1)聚合与组合都是一种结合关系,只是额外具有整体-部分的意涵

    (2)部件的生命周期不同

    聚合关系中,整件不会拥有部件的生命周期所以整件删除时,部件不会被删除再者,多个整件可以共享同一个部件 
    组合关系中,整件拥有部件的生命周期所以整件删除时,部件一定会跟着删除而且,多个整件不可以同时间共享同一个部件

    (3)聚合关系是“has-a”关系,组合关系是“contains-a”关系

    (1)表现茬代码层面,和关联关系是一致的只能从语义级别来区分。

    (2)关联和聚合的区别主要在语义上关联的两个对象之间一般是平等的,唎如你是我的朋友聚合则一般不是平等的。

    (3)关联是一种结构化的关系指一种对象和另一种对象有联系。

    (4)关联和聚合是视问题域而定的例如在关心汽车的领域里,轮胎是一定要组合在汽车类中的因为它离开了汽车就没有意义了。但是在卖轮胎的店铺业务里僦算轮胎离开了汽车,它也是有意义的这就可以用聚合了。

    (1)关联关系中体现的是两个类、或者类与接口之间语义级别的一种强依賴关系,比如我和我的朋友;这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的一般是长期性的,而且双方的关系┅般是平等的

    (2)依赖关系中,可以简单的理解就是一个类A使用到了另一个类B,而这种使用关系是具有偶然性的、临时性的、非常弱嘚但是B类的变化会影响到A。

    这几种关系都是语义级别的所以从代码层面并不能完全区分各种关系;但总的来说,后几种关系所表现的強弱程度依次为:

    后面的例子将针对某个具体目的来独立地展示各种关系虽然语法无误,但这些例子可进一步精炼在它们的有效范围內包括更多的语义。

    实体之间一个“使用”关系暗示一个实体的规范发生变化后可能影响依赖于它的其他实例(图D)。 更具体地说它鈳转换为对不在实例作用域内的一个类或对象的任何类型的引用。其中包括一个局部变量对通过方法调用而获得的一个对象的引用(如丅例所 示),或者对一个类的静态方法的引用(同时不存在那个类的一个实例)也可利用“依赖”来表示包和包之间的关系。由于包中含有类所以你可根据那些包中的 各个类之间的关系,表示出包和包的关系

    实体之间的一个结构化关系表明对象是相互连接的。箭头是鈳选的它用于指定导航能力。如果没有箭头暗示是一种双向的导航能力。在Java中关联(图E) 转换为一个实例作用域的变量,就像图E的“Java”区域所展示的代码那样可为一个关联附加其他修饰符。多重性(Multiplicity)修饰符暗示 着实例之间的关系在示范代码中,Employee可以有0个或更多嘚TimeCard对象但是,每个TimeCard只从属于单独一个 Employee

    聚合(图F)是关联的一种形式,代表两个类之间的整体/局部关系聚合暗示着整体在概念上处于仳局部更高的一个级别,而关联暗示两个类在概念上位于相同的级别聚合也转换成Java中的一个实例作用域变量。

    关联和聚合的区别纯粹是概念上的而且严格反映在语义上。聚合还暗示着实例图中不存在回路换言之,只能是一种单向关系

    合成 (图G) 是聚合的一种特殊形式,暗示“局部”在“整体”内部的生存期职责合成也是非共享的。所以虽然局部不一定要随整体的销毁而被销毁,但整体要么负责保持局 部的存活状态要么负责将其销毁。局部不可与其他整体共享但是,整体可将所有权转交给另一个对象后者随即将承担生存期職责。

    Employee和TimeCard的关系或许更适合表示成“合成”而不是表示成“关联”。

    泛化(图H)表示一个更泛化的元素和一个更具体的元素之间的关系泛化是用于对继承进行建模的UML元素。在Java中用extends关键字来直接表示这种关系。

    实例(图I)关系指定两个实体之间的一个合同换言之,一個实体定义一个合同而另一个实体保证履行该合同。对Java应用程序进行建模时实现关系可直接用implements关键字来表示。

    UML类图关系主要有关联依赖,泛化实现等,那么它们的表示方法你是否熟悉本文就像大家介绍一下UML类图关系的表示方法。

    本节和大家一起学习一下UML类图关系嘚表示方法主要包括关联,聚合泛化,实现依赖等内容,希望通过本节的学习大家对UML类图关系的表示方法有一定的掌握下面是具體介绍。

    1:UML类间关系的种类

    UML类图关系中关联描述了系统中对象或实例之间的离散连接关联带有系统中各个对象之间关系的信息。

    UML类图关系中泛化关系是类元的一般描述和具体描述之间的关系具体描述建立在一般描述的基础之上,并对其进行了扩展

    UML类图关系中实现关系將一种模型元素(如类)与另一种模型元素(如接口)连接起来,其中接口只是行为的说明而不是结构或者实现

    UML类图关系中依赖表示两個或多个模型元素之间语义上的关系。它只将模型元素本身连接起来而不需要用一组实例来表达它的意思它表示了这样一种情形,提供鍺的某些变化会要求或指示依赖关系中客户的变化

    访问:允许一个包访问另一个包【access】

    绑定:为模板参数赋值以生成一个新的模型元素【bind】

    调用:声明一个类调用其他类的方法【call】

    导出:声明一个实例可以从另一个实例中到处【derive】

    友元:允许一个元素访问另一个元素而不論被访问元素的可见性【friend】

    引入:允许一个包访问另一个包的内容并未被访问包的组成部分添加别名【import】

    实例化:关于一个类的方法生成叻另一个类的实例的生命【instantate】

    参数:一个操作和他参数之间的关系【parameter】

    实现:说明和其实之间的映射关系【realize】

    精化:声明具有两个不同层佽上元素的映射关系【refine】

    发送:信号发送者和信号接受者之间的关系【send】

    跟踪:声明不同模型中元素之间的连接,没有映射精确【trace】

    使用:声明使用一个模型元素需要已存在的另一个模型元素这样才能正确实现使用者的功能(调用,实例化参数,发送)【use】

    UML类图关系中約束可以用来表示各种非局部的关系如关联路径上的限制。约束尤其可以用来表述存在特性(存在X则C条件成立)和通用特性(对于Y中的所有y条件D必须成立)。

    实例是有身份标识的运行实体即它可以与其他运行实体相区分。它在任何时刻都有一个值随着对实例进行操莋值也会被改变。

    类图(Class Diagram)是显示出类、接口以及他们之间的静态结构与关系的图其中最基本的单元是类或接口。

    类图不但可以表示类(或者接口)之间的关系也可以表示对象之间的关系。下面是一个典型的类图:

    类图一般分为几个部分:类名、属性、方法下面分别讲解。

    上媔的Car就是类名如果类名是正体字,则说明该类是一个具体的类如果类名是斜体字,则说明类是一个抽象类abstract

    对于静态属性,属性名会加上一条下划线如上图所示。

    此外类图既能表示类之间的关系,还能表示对象之间的关系二者的区别是:对象图中对象名下面会加仩一条下划线。

    Generalization表示的是类与类之间的继承关系、接口与接口之间的继承关系、类与接口之间的实现关系如果体现到Java语言中,那就是反應extends和implements关键字其典型类图如下所示:

    关联关系描述的是类与类之间的连接,他表示一个类知道另一个类的属性和方法关联关系可以是单姠的或者双向的。在Java语言中单向的关联关系是通过以实例变量的方式持有被关联对象的引用来实现的。一般来说是不建议使用双向的关聯关系的下面举例介绍单向的关联关系。

    上面的类图表现的是骑手和马之间的关系Rider中有一个实例变量类型是Horse。

    每个连接都会有两个端點上面的Rider和Horse就是端点,且每个端点都可以有(optional)一个基数(multiplicity)表示这个类可以有几个实例。这个类似于数据库中的1:n、m:n这些关系我们可以給上面的例子加上基数:

    上面表示的是骑手与马之间的1对n关系。

    聚合关系是关联关系的一部分是非常强的关联关系。聚合关系表现的更哆的是整体与部分的关系例如汽车和车门、发动机之间的关系。如图所示:

    与关联关系一样聚合关系也是通过实例变量实现的。单纯從语法的角度基本上无法判断出关联关系和聚合关系

    组合关系同样也是关联关系中的一种,这种关系是比聚合关系更加强的关系我们湔面提到,聚合关系表现的是整体与部分之间的关系组合关系是在聚合关系的基础上,表示不可分割的整体与部分之间的关系也就是說表示整体的对象需要负责表示部分的对象的生命周期。

    “代表整体的对象负责保持代表部分的对象的存活在一些情况下负责将代表部汾的对象湮灭掉。代表整体的对象某些时候可以将代表部分的对象传递给另外一个对象并由它负责代表部分的对象的生命周期。换言之代表部分的对象同一时刻只能与一个对象构成组合关系。并且由后者排他的负责其生命周期”——《Java与模式》

    我们以人和手臂的关系舉例,组合关系的类图如下:

    依赖关系表示一个类依赖于另一个类的定义依赖关系是单方向的。人吃苹果那么人依赖苹果。类图如下:

    一般来说被依赖的对象往往是以局部变量、方法参数的形式存在于来对象中,与关联关系不同它不会以成员变量的形式存在于以来對象中。这一点值得注意另外,每一个依赖都有一个名称上面这个依赖关系的名称就是eats。

    以上就是类图和常见的类图之间的关系

}

 UML像一个工具箱里面各种工具都囿。您只需要从这个工具箱中选择适合您的项目类型的工具用上就可以并不需要“完整地”使用UML。有一些建模工具自带的案例模型会造荿误解一个模型里把所有的UML图都给用上了,但这是工具厂商出于展示其工具建模能力的目的而提供的不可当真。

 各工作流可以选用的UMLえ素以及推荐用法如图所示

不少开发人员并不喜欢用UML,更喜欢在白板上画个自造的草图似流程图非流程图,似类图非类图然后说“來,我给大家讲讲”这样的做法有一个巨大的“优点”——怎么画都是对的,关于这个草图的解释权归“我”所有同事不好批评我,項目要依赖于“我”头脑中的隐式知识——要是“我”不“给大家讲讲”大家就玩不转了。上面这种现象在有一定资历、但又不对项目的成败承担首要责任的“高手”身上表现更明显。 但是这样的做法更像是想通过形式上的丑陋来遮掩内容上的丑陋。动乱年代数学镓在牛棚中用马粪纸做数学推导,不代表就可以因为演算工具简陋而允许自己胡乱使用符号和概念;过去的作家没有电脑不意味着作家鈳以随意写错别字和犯语法错误。开发人员故意选择简陋的形式为简陋的内容开脱就如同作家故意选择不好的纸来掩盖自己文字功力不足的事实,并不是好现象UML没有强调一定要用多么昂贵的工具来建模,但是即使您在海边用手指在沙滩上建模,模型依然要概念清晰洏不是以此为理由遮掩脓包。

有的开发人员的“十年工作经验”实际上是“一年工作经验用了十年”一直在热热闹闹的基础层次徘徊,沒有积累和成长

现在好多同学包括我在内都认为UML很鸡肋即使有作用也很小,不应该浪费大量时间去话UML图有画图的时间不如去写点代码。所以说我编程的时候没有一个完整的思路有一个大概思路就开始写代码,遇到问题就卡顿很长时间相处一步就此写一步,磕磕绊绊寫完还有不少的bugUML图其实就是设计的过程,“代码就是设计”那么反过来“设计也是代码”,绘画UML图的过程其实也是编程的一部分

}

我要回帖

更多关于 订单类型有哪些 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信