UML基础知识.docx

一：UML定义了5类，10种模型图UML提供的基本模型图包括：(1)、用例图：展示系统外部的各类执行者与系统提供的各种用例之间的关系(2)、类图：展示系统中类的静态结构(类是指具有相同属性和行为的对象，类图用来描述系统中各种类之间的静态结构)(3)、对象图：是类图的一种实例化图(对象图是对类图的一种实例化)(4)、包图：是一种分组机制。在UML1.1版本中，包图不再看作一种独立的模型图)(5)、状态图：描述一类对象具有的所有可能的状态及其转移关系(它展示对象所具有的所有可能的状态以及特定事件发生时状态的转移情况)(6)、顺序图：展示对象之间的一种动态协作关系(一组对象组成，随时间推移对象之间交换消息的过程，突出时间关系)(7)、合作图：从另一个角度展示对象之间的动态协作关系(对象间动态协作关系，突出消息收发关系)(8)、活动图：展示系统中各种活动的执行流程(各种活动的执行顺序、执行流程)(9)、构件图：展示程序代码的物理结构(描述程序代码的组织结构，各种构件之间的依赖关系)(10)、配置图：展示软件在硬件环境中(特别是在分布式及网络环境中)的配置关系(系统中硬件和软件的物理配置情况和系统体系结构)建模过程首先：描述需求次之：根据需求建立系统的静态模型，以构造系统的结构第三：描述系统的行为其中第一步与第二步中所建立的模型都是静态的，包括用例图、类图（包括包图）、对象图、构件图和配置图等六种图。这些图构成了标凖建模语言UML的静态建模机制。第三步中所建立的模型或者可吧执行或者表示执行时的时序状态或交互关系，它包括状态图、活动图、顺序图和合作图等四种图。这些图构成了标准建模语言UML的动态建模机制。可用以下常用视角来描述一个系统：(1)、系统的使用实例：从系统外部的操作者的解度描述系统的功能(2)、系统的逻辑结构：描述系统内部的静态结构和动态行为，即从内部描述如何设计实现系统功能(3)、系统的构成：描述系统由哪些程序构件所组成(4)、系统的并发性：描述系统的并发性，强调并发系统中存在的各种通信和同步问题(5)、系统的配置：描述系统的软件和各种硬件设备之间的配置关系二：软件开发过程(RUP概述)：迭代开发过程：由四个阶段构成，每个阶段都包含软件开发的每个过程：分析、设计、实现和测试阶段四个阶段：初始阶段、细化阶段、构造阶段、移交阶段通常在移交阶段后进行总体测试、性能测试、用户培训等1. 初始阶段：项目的总体需求、可行性分析等，并确认是否启动该项目2. 细化阶段：（1/5周期）启动该项目后，（1）、实际要做什么？（2）、如何做？（3）、将采用什么技术？风险分析和风险管理（1）、需求风险：不能偏离用户需要，要充分了解用户需求及各需求的相对优化程度处理需求风险：用例分析技术。列出该系统的所有用例，安排开发人员与客户交流，以便收集用例。其中要对领域概念模型作充分说明（行业术语，如电信中的产品）。建立域模型：类图、活动图（2）、技术风险：你是否有相关技术经验，熟悉程度如何？使用类图和交互图来描述构件间的通信使用包图来描述构件的高层结构使用配置图来描述系统功能的分配（3）、技能风险：能否得到相关技术人才或专家？（4）、政策风险：是否存在一些政策性因素影响整个项目的进行细化阶段的重要结果之一：建立系统的基线体系结构（1）、用例表：用于描述系统需求（2）、域模型：用于获取应用领域中的关键类的起点，反映你对系统将要提供的业务和服务的理解（3）、技术平台：描述重要的实现技术以及技术间的协作和集成细化阶段何时结束：（1）、开发人员能给项目估算（2）、考虑所有的风险，并制定出相应对策和计划计划：1.第一阶段：用例是制定项目计划的基chu，对用例进行分类：（1）、用户应当列出用例的优先级。通常为三级，首先要实现的，短期内可以没有，长期内可以没有的（2）、对于每一个用例，开发人员都应考虑体系结构风险。三级：高风险，可能的风险，完全不可能的风险（3）、开发人员还应评价自己对每个用例开发工作量的做算，称之为进度风险。三级：确信自己对时间的估算，只能估算到人月，无法估算注意：估算应由开发人员估算，项目经理只是评审复核作用。由些开发人员可以充分理解用例，应估算到人周2.第二阶段：确定每次迭代的开发周期，每次迭代的工作量（迭代次数3至5次）3. 构造阶段两个概念：（1）、程序重组：指对程序中与新添功能相关的成分进行适当改造，使其在结构上完全适合新功能的加入。（2）、模式：构造阶段是通过一系列迭代过程建设系统。每次迭代开发都是一个小项目，需要对所有要求的用例进行分析、设计、编码、测试和集成。完成一次迭代后，应向用户演示，并完成系统测试，以表明所要求的用例已正确实现。4. 移交阶段：迭代式开发关键在于规范化地进行整个开发过程。在移交阶段，不能再开发新的功能（除了个别小功能或非常基本的以外），而只是集中精力进行纠错工作，优化工作。三：用例用例的基本概念及相关介绍主要方法：与客户交流，一系列用例的集合，就是整个系统的需求如何区分用户目标和系统交互功能用例模型的获取：用例模型是获取需求、规划和控制项目迭代过程的基本工具。是初始阶段首先要做的工作，是细化阶段的主要任务之一。a、获取执行者获取用例首先要找出系统的使用者。（1）、谁使用系统的主要功能（主要使用者）？（2）、谁需要系统支持他们的日常工作？（3）、谁来维护、管理系统使其能正常工作（辅助使用者）？（4）、系统需要控制哪些硬件？（5）、系统需要与其他哪些系统交互？这是系统包含其他计算机系统和其他应用程序。（6）、对系统产生的结果感兴趣的是哪些人或哪些事物？b、获取用例对每个执行者提出一些问题，然后从执行者对这些问题的答案中获取用例（1）、执行者要求系统提供哪些功能（执行者需要做什么）？（2）、执行者需要读、产生、删除、修改或存储系统中的信息有哪些类型？（3）、必须提醒执行者的系统事件有哪些？或者（4）、执行者必须提醒系统事件有哪些？怎样把这些事件表示成用例中的功能？针对系统的问题（1）、系统需要何种输入输出？输入从何处来？输出到何处去？（2）、当前运行系统（也许是一些手工操作而不是计算机系统）的主要问题是什么？UML 2 定义了13种基本的图，它们被分成两大类:1. 结构建模图结构图定义了一个模型的静态架构。它们通常被用来对那些构成模型的要素建模，诸如：类，对象，接口和物理组件。另外，它们也被用来对元素间关联和依赖关系进行建模。类或结构图用来定义模型的基本建立模块 : 类型、类和构成完整模型的一般素材。对象图显示结构元素的实例间如何关联，以及在运行时如何使用。复合结构图提供了一种对元素结构进行分层的方法，并着重体现了元素内部的细节，结构和关系。组件图被用来构造更高层次或更复杂的结构，通常由一个或多个类构成，并提供一个定义明确的接口。部署图显示现实环境中重要物件的物理配置。包图用来将模型划分成不同的逻辑容器或“包”，并在更高层次上描述它们之间的交互关系。包图（Package diagrams）：用来将模型划分成不同的逻辑容器或“包”，并在更高层次上描述它们之间的交互关系。类或结构图（Class or Structural diagrams） 用来定义模型的基本建立模块 : 类型、类和构成完整模型的一般素材。对象图（Object diagrams） 显示结构元素的实例间如何关联，以及在运行时如何使用。复合结构图（Composite Structure diagrams） 提供了一种对元素结构进行分层的方法，并着重体现了元素内部的细节，结构和关系。组件图（Component diagrams） 被用来构造更高层次或更复杂的结构，通常由一个或多个类构成，并提供一个定义明确的接口。部署图（Deployment diagrams） 显示现实环境中重要物件的物理配置。2. 行为建模图行为图用来记录在一个模型内部，随时间的变化，模型执行的交互变化和瞬间的状态；并跟踪系统在真实环境下如何表现，以及观察系统对一个操作或事件的反应，以及它的结果。交互概览图融合活动图和顺序图，使交互部分容易与判断点和流程结合。用例图用来对用户/系统的交互关系建模。 用脚本和情形的形式来定义行为，要求和约束。活动图广泛使用于定义基本程序流程和在一般化过程中，记录判断点和动作。状态机图对于了解模型执行时的瞬时状态，即模型的运行状态是重要的。通信图显示协作实例中，对象间实时消息和通信的网络结构与顺序。顺序图与通信图联系紧密，并在垂直时间线上显示对象间消息传递的顺序。时间图融合顺序图和状态图，以提供观察对象随时间变化的状态和改变这个状态的消息。用例图（Use Case diagrams） 用来对用户/系统的交互关系建模。 用脚本和情形的形式来定义行为，要求和约束。活动图（Activity diagrams） 广泛使用于定义基本程序流程和在一般化过程中，记录判断点和动作。状态机图（State Machine diagrams） 对于了解模型执行时的瞬时状态，即模型的运行状态是重要的。通信图（Communication diagrams） 显示协作实例中，对象间实时消息和通信的网络结构与顺序。顺序图（Sequence diagrams） 与通信图联系紧密，并在垂直时间线上显示对象间消息传递的顺序。时间图（Timing diagrams） 融合顺序图和状态图，以提供观察对象随时间变化的状态和改变这个状态的消息。交互概览图（Interaction Overview diagrams） 融合活动图和顺序图，使交互部分容易与判断点和流程结合。UML中的模型元素包括事物和事物之间的联系。事物是UML中重要的组成部分，它代表任何可以定义的东西。事物之间的关系能够把事物联系在一起，组成有意义的结构模型。每一个模型元素都有一个与之相对应的图形元素。一、 事物1、 结构事物结构事物分为：类、接口、协作、用例、活动类、组件和节点（1） 类。类是对具有相同属性、方法、关系和语义的对象的抽象，一个类可以实现一 个或多个接口。类用包括类名、属性和方法的矩形表示。活动类。活动类是类对象有一个或多个进程或线程的类。在UML中活动类的表示法和类相同，只是边框用粗线条。（2） 接口。接口是为类或组件提供特定服务的一组操作的集合。（3） 用例。用例描述系统对一个特定角色执行的一系列动作。在模型中用例通常用来组织动作事物，它是通过协作来实现的。UML中，用例用标注了用例名称的实线椭圆表示。协作。协作定义了交互操作。一些角色和其他元素一起工作，提供一些合作的动作，这些动作比元素的总和要大。不常用，和用例的表示区别是它是虚线画的椭圆。（4） 参与者。在系统外部与系统直接交互的人或事物。（5） 组件。组件是实现了一个接口集合的物理上可替换的系统部分。（6） 节点。节点是在运行时存在的一个物理元素，它代表一个可计算的资源，通常占用一些内存和具有处理能力。一个组件集合一般来说位于一个节点，但也可以从一个节点转到另一个节点。2、 动作事物动作事物是UML模型中的动态部分，它们是模型的动词，代表时间和空间上的动作。交互和状态机是UML模型中最基本的两个动态事物元素。（1） 交互。交互是一组对象在特定上下文中，为达到某种特定的目的而进行的一系列消息交换组成的动作。在交互中组成动作的对象的每个操作都要详细列出，包括消息、动作次数（消息产生的动作）、连接（对象之间的连接）。（2） 状态机。状态机由一系列对象的状态组成。3、 分组事物分组事物是UML模型中组织的部分，分组事物只有一种，称为包。4、 注释事物注释事物是UML模型的解释部分。二、 UML中的关系1、 关联关系has关联关系连接元素和链接实例，它用连接两个模型元素的实线表示，在关联的两端可以标注关联双方的角色和多重性标记。2、 依赖关系use依赖关系描述一个元素对另一个元素的依附。依赖关系用源模型指向目标模型的带箭头的虚线表示。3、 泛化关系extend泛化关系也称为继承关系，泛化用一条带空心三角箭头的实线表示，从子类指向父类。4、 实现关系implement实现关系描述一个元素实现另一个元素。下面的图其实有两个实现关系，只是因为在rational rose中把class的stereotype设为Interface时类是个圆圈，实现它的时候直接使用直线就可以明了。如果没有设置stereotype时，依然使用虚线加三角形。5、 聚合关系aggregation聚合(aggregation)关系: 关联关系的一种特例, 是强的关联关系. 聚合是整体和个体之间的关系,即has-a的关系，此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享，表现在代码层面，和关联关系是一致的，只能从语义级别来区分；聚合关系也是使用实例变量实现的. 从java 语法上是分不出关联和聚合的。这也是我纠结的地方，正因如此rational rose貌似没有表示聚合的符号，所以我就只好换用visio了，所以我又加了一些visio的图，大家不要赶脚奇怪哈。关联关系中两个类是处于相同的层次, 而聚合关系中两不类是处于不平等的层次, 一个表示整体, 一个表示部分.6、组合(合成)关系composition组合 也是关联关系的一种特例，他体现的是一种contains-a的关系，这种关系比聚合更强，也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束；比如你和你的大脑；合成关系不能共享. 。表现在代码层面，和关联关系是一致的，只能从语义级别来区分。组合跟聚合几乎相同，唯一的区别就是“部分”不能脱离“整体”单独存在，就是说， “部分”的生命期不能比“整体”还要长。类图是最常用的UML图，它用于描述系统的结构化设计。其中包括类关系以及与每个类关联的属性及行为。类图能出色地表示继承与合成关系。为了将类图作为一种高效的沟通工具使用，开发者必须理解如何将类图上出现的元素转换到Java中。下面来进一步探索这一转换过程。元素在后面的小节中，分别讲解了类图的各个元素及其在Java中相应的表示。我会列出元素名，后续简短的代码片断和一幅图来表示元素在类图上的样子。每一节的最后简要总结了该元素。类（Class）类（图A）是对象的蓝图，其中包含3个组成部分。第一个是Java中定义的类名。第二个是属性（attributes）。第三个是该类提供的方法。属性和操作之前可附加一个可见性修饰符。加号（+）表示具有公共可见性。减号（-）表示私有可见性。#号表示受保护的可见性。省略这些修饰符表示具有package（包）级别的可见性。如果属性或操作具有下划线，表明它是静态的。在操作中，可同时列出它接受的参数，以及返回类型，如图A的“Java”区域所示。图A包（Package）包（图B）是一种常规用途的组合机制。UML中的一个包直接对应于Java中的一个包。在Java中，一个包可能含有其他包、类或者同时含有这两者。进行建模时，你通常拥有逻辑性的包，它主要用于对你的模型进行组织。你还会拥有物理性的包，它直接转换成系统中的Java包。每个包的名称对这个包进行了惟一性的标识。图B接口（Interface）接口（图C）是一系列操作的集合，它指定了一个类所提供的服务。它直接对应于Java中的一个接口类型。接口既可用图C的那个图标来表示，也可由附加了的一个标准类来表示。通常，根据接口在类图上的样子，就能知道与其他类的关系。图C关系后面的例子将针对某个具体目的来独立地展示各种关系。虽然语法无误，但这些例子可进一步精炼，在它们的有效范围内包括更多的语义。依赖（Dependency）实体之间一个“使用”关系暗示一个实体的规范发生变化后，可能影响依赖于它的其他实例（图D）。更具体地说，它可转换为对不在实例作用域内的一个类或对象的任何类型的引用。其中包括一个局部变量，对通过方法调用而获得的一个对象的引用（如下例所示），或者对一个类的静态方法的引用（同时不存在那个类的一个实例）。也可利用“依赖”来表示包和包之间的关系。由于包中含有类，所以你可根据那些包中的各个类之间的关系，表示出包和包的关系。图D关联（Association）实体之间的一个结构化关系表明对象是相互连接的。箭头是可选的，它用于指定导航能力。如果没有箭头，暗示是一种双向的导航能力。在Java中，关联（图E）转换为一个实例作用域的变量，就像图E的“Java”区域所展示的代码那样。可为一个关联附加其他修饰符。多重性（Multiplicity）修饰符暗示着实例之间的关系。在示范代码中，Employee可以有0个或更多的TimeCard对象。但是，每个TimeCard只从属于单独一个Employee。图E聚合（Aggregation）聚合（图F）是关联的一种形式，代表两个类之间的整体/局部关系。聚合暗示着整体在概念上处于比局部更高的一个级别，而关联暗示两个类在概念上位于相同的级别。聚合也转换成Java中的一个实例作用域变量。关联和聚合的区别纯粹是概念上的，而且严格反映在语义上。聚合还暗示着实例图中不存在回路。换言之，只能是一种单向关系。图F合成（Composition）合成 （图G）是聚合的一种特殊形式，暗示“局部”在“整体”内部的生存期职责。合成也是非共享的。所以，虽然局部不一定要随整体的销毁而被销毁，但整体要么负责保持局部的存活状态，要么负责将其销毁。局部不可与其他整体共享。但是，整体可将所有权转交给另一个对象，后者随即将承担生存期职责。Employee和TimeCard的关系或许更适合表示成“合成”，而不是表示成“关联”。图G泛化（Generalization）泛化（图H）表示一个更泛化的元素和一个更具体的元素之间的关系。泛化是用于对继承进行建模的UML元素。在Java中，用extends关键字来直接表示这种关系。图H实现（Realization）实例（图I）关系指定两个实体之间的一个合同。换言之，一个实体定义一个合同，而另一个实体保证履行该合同。对Java应用程序进行建模时，实现关系可直接用implements关键字来表示。图I精确映射如本文所述，UML类图上的元素能精确映射到Java编程语言。开发团队的成员可利用这种精确性来加强沟通，取得对系统结构化设计的共识。类与类图1) 类(Class)封装了数据和行为，是面向对象的重要组成部分，它是具有相同属性、操作、关系的对象集合的总称。2) 在系统中，每个类具有一定的职责，职责指的是类所担任的任务，即类要完成什么样的功能，要承担什么样的义务。一个类可以有多种职责，设计得好的类一般只有一种职责，在定义类的时候，将类的职责分解成为类的属性和操作（即方法）。3) 类的属性即类的数据职责，类的操作即类的行为职责一、依赖关系(Dependence)依赖关系（Dependence）：假设A类的变化引起了B类的变化，则说名B类依赖于A类。依赖关系(Dependency) 是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系。大多数情况下，依 赖关系体现在某个类的方法使用另一个类的对象作为参数。在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方。public class Driver public void drive(Car car) car.move(); public class Car public void move() 依赖关系有如下三种情况：1、A类是B类中的（某中方法的）局部变量；2、A类是B类方法当中的一个参数；3、A类向B类发送消息，从而影响B类发生变化；二、泛化关系（Generalization）泛化关系（Generalization）：A是B和C的父类，B,C具有公共类（父类）A，说明A是B,C的一般化（概括，也称泛化）泛化关系(Generalization)也就是继承关系，也称为“is-a-kind-of”关系，泛化关系用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。在UML中，泛 化关系用带空心三角形的直线来表示。在代码实现时，使用面向对象的继承机制来实现泛化关系，如在Java语言中使用extends关键字、在C+/C#中使用冒号“：”来实现。public class Person protected String name; protected int age; public void move() public void say() public class Student extends Person private String studentNo; public void study() 在UML当中，对泛化关系有三个要求：1、子类与父类应该完全一致，父类所具有的属性、操作，子类应该都有；2、子类中除了与父类一致的信息以外，还包括额外的信息；3、可以使用父类的实例的地方，也可以使用子类的实例；三、关联关系（Association）关联关系（Association）:类之间的联系，如客户和订单，每个订单对应特定的客户，每个客户对应一些特定的订单，再如篮球队员与球队之间的关联（下图所示）。其中，关联两边的employee和“employer”标示了两者之间的关系，而数字表示两者的关系的限制，是关联两者之间的多重性。通常有“*”（表示所有，不限），“1”（表示有且仅有一个），“0.”（表示0个或者多个），“0，1”（表示0个或者一个），“n.m”(表示n到m个都可以),“m.*”（表示至少m个）。关联关系(Association) 是类与类之间最常用的一种关系，它是一种结构化关系，用于表示一类对象与另一类对象之间有联系。在UML类图中，用实线连接有关联的对象所对应的类，在使用Java、C#和C+等编程语言实现关联关系时，通常将一个类的对象作为另一个类的属性。在使用类图表示关联关系时可以在关联线上标注角色名。1) 双向关联: 默认情况下，关联是双向的。public class Customer private Product products; public class Product private Customer customer; 2 ) 单向关联:类的关联关系也可以是单向的，单向关联用带箭头的实线表示.public class Customer private Address address; public class Address 3) 自关联: 在系统中可能会存在一些类的属性对象类型为该类本身，这种特殊的关联关系称为自关联。public class Node private Node subNode; 4) 重数性关联: 重数性关联关系又称为多重性关联关系(Multiplicity)，表示一个类的对象与另一个类的对象连接的个数。在UML中多重性关系可以直接在关联直线上增加一个数字表示与之对应的另一个类的对象的个数。public class Form private Button buttons; public class Button 四、聚合关系（Aggregation）聚合关系（Aggregation）:表示的是整体和部分的关系，整体与部分 可以分开.聚合关系(Aggregation) 表示一个整体与部分的关系。通常在定义一个整体类后，再去分析这个整体类的组成结构，从而找出一些成员类，该整体类和成员类之间就形成了聚合 关系。在聚合关