一、UML中基本的图范畴：在UML2中有二种基本的图范畴：结构图和行为图。每个UML图都属于这二个图范畴。结构图的目的是显示建模系统的静态结构。它们包括类，组件和（或）对象图。另一方面，行为图显示系统中的对象的动态行为，包括如对象的方法，协作和活动之类的内容。行为图的实例是活动图，用例图和序列图。
name:attributetype=defaultvalue如balance:Dollars=0，这是带有默认值的表达形式
·类方法列表：name(parameterlist):typeofvaluereturned
在面向对象的设计中，存在属性及操作可见性的记号。UML识别四种类型的可见性：public，protected，private及package。
UML规范并不要求属性及操作可见性必须显示在类图上，但是它要求为每个属性及操作定义可见性。为了在类图上显示可见性，放置可见性标志于属性或操作的名字之前。虽然UML指定四种可见性类型，但是实际的编程语言可能增加额外的可见性，或不支持UML定义的可见性。表4显示了UML支持的可见性类型的不同标志。
UML支持的可见性类型的标志
标志
可见性类型
注意：关联的一方关联对象位于直线的上端，关联数目位于同侧的直线下端，另一方则相反
多重值和它们的表示
可能的多重值描述
一个单向的关联，表示为一条带有指向已知类的开放箭头（不关闭的箭头或三角形，用于标志继承）的实线。如同标准关联，单向关联包括一个角色名和一个多重值描述，但是与标准的双向关联不同的时，单向关联只包含已知类的角色名和多重值描述。
简单的说就是OverdrawAccountReport中包含了BankAccount属性，而BankAccount中不需要包含OverdrawnAccountsReport对象
6.聚合的表示：
聚合是一种特别类型的关联，用于描述“总体到局部”的关系。在基本的聚合关系中，部分类的生命周期独立于整体类的生命周期。
举例来说，我们可以想象，车是一个整体实体，而车轮轮胎是整辆车的一部分。轮胎可以在安置到车时的前几个星期被制造，并放置于仓库中。在这个实例中，Wheel类实例清楚地独立于Car类实例而存在。然而，有些情况下，部分类的生命周期并不独立于整体类的生命周期--这称为合成聚合。举例来说，考虑公司与部门的关系。公司和部门都建模成类，在公司存在之前，部门不能存在。这里Department类的实例依赖于Company类的实例而存在。
让我们更进一步探讨基本聚合和组合聚合。
InstanceName:ClassName如Donald:Person
以下是：序列图
序列图主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。很象类图，开发者一般认为序列图只对他们有意义。然而，一个组织的业务人员会发现，序列图显示不同的业务对象如何交互，对于交流当前业务如何进行很有用。除记录组织的当前事件外，一个业务级的序列图能被当作一个需求文件使用，为实现一个未来系统传递需求。在项目的需求阶段，分析师能通过提供一个更加正式层次的表达，把用例带入下一层次。那种情况下，用例常常被细化为一个或者更多的序列图。
组织的技术人员能发现，序列图在记录一个未来系统的行为应该如何表现中，非常有用。在设计阶段，架构师和开发者能使用图，挖掘出系统对象间的交互，这样充实整个系统设计。
序列图的主要用途之一，是把用例表达的需求，转化为进一步、更加正式层次的精细表达。用例常常被细化为一个或者更多的序列图。序列图除了在设计新系统方面的用途外，它们还能用来记录一个存在系统（称它为“遗产”）的对象现在如何交互。当把这个系统移交给另一个人或组织时，这个文档很有用。
UML规范给图类型提供特定的文本值。（举例来说，sd代表序列图，activity代表活动图，usecase代表用例图）。
图8作为一个变体的组合碎片如何阅读的例子，显示序列从顶部开始，即bank对象获取支票金额和帐户结余。此时，序列图中的变体组合碎片接管。因为约束“[balance>=amount]”，如果余额超过或等于金额，然后顺序进行bank对象传递addDebitTransaction和storePhotoOfCheck消息给account对象。然而，如果余额不是超过或等于金额，然后顺序的过程就是bank传递addInsuffientFundFee和noteReturnedCheck消息给account对象，returnCheck消息给它自身。因为“else”约束，当余额不大于或者等于金额时，第二个序列被调用。在变体的组合碎片中，不需要“else”约束；而如果一个操作元，在它上面没有一个明确的约束，那么将假定“else”约束。
以下是：用例图：
用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
1、包含(include)
包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
2、扩展(extend)
泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。
转：UML中扩展和泛化的区别泛化表示类似于OO术语“继承”或“多态”。UML中的UseCase泛化过程是将不同UseCase之间的可合并部分抽象成独立的父UseCase，并将不可合并部分单独成各自的子UseCase；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：●泛化侧重表示子用例间的互斥性；●包含侧重表示被包含用例对Actor提供服务的间接性；●扩展侧重表示扩展用例的触发不定性；详述如下：
既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：⒈无条件发生：肯定发生的；⒉有条件发生：未必发生，发生与否取决于系统状态；
因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。
另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。
以下是：活动图
下面的活动图描述了大学新生第一次将如何办理入学的商业逻辑。
退出活动可能有几种方法，如您看到的“填写入学表”活动的那样。如果正确填写了表格，那么可以继续进行大学的入学手续。但是，如果表格不正确，那么必须获得帮助（可能从注册员获得帮助）以正确填写它们。
中标识的几个用例的逻辑。用例模型没有很好地表达处理的顺序是件好事。例如，虽然中显示的用例图为您清楚地描述了该系统所执行的功能类型，但是它没有明确地表达这些用例可能发生的顺序。但是，的活动图做到了这一点。总之，不同模型的优缺点各有不同。
泳道将模型中的活动按照职责组织起来通常很有用。例如，可以将一个商业组织处理的所有活动组织起来。这种分配可以通过将活动组织成用线分开的不同区域来表示。由于它们的外观的缘故，这些区域被称作泳道。图7–2表示了泳道。
图7–2泳道和对象流
·2.对象流
活动图能表示对象的值流和控制流。对象流状态表示活动中输入或输出的对象。对输出值而言，虚线箭头从活动指向对象流状态。对输入值而言，虚线箭头从对象流状态指向活动。如果活动有多个输出值或后继控制流，那么箭头背向分叉符号。同样，多输入箭头指向结合符号。
图7–2表示一个活动和对象流状态都被分配到泳道中的活动图。
·活动和其他图活动图没有表示出计算处理过程中的全部细节内容。它们表示了活动进行的流程但没表示出执行活动的对象。活动图是设计工作的起点。为了完成设计，每个活动必须扩展细分成一个或多个操作，每个操作被指定到具体类。这种分配的结果引出了用于实现活动图的对合协的设计工作。
以下是数据流图DFD：
研究了一下DFD:
结构化分析是面向数据流开展需求分析工作的一种有效方法。一般采用自顶向下，逐层分解的演义分析法来定义系统的需求，即先把分析对象抽象成一个系统，然后自顶向下的逐层分解，将复杂的系统分解成简单的、能够清楚地被理解和表达的若干个子系统，如图1（逐层分解的数据流程图）所示。这样就可以分别理解系统的每个细节、前后顺序和相互关系，找出各部分之间的数据接口。在结构化分析方法所采用的工具有数据流程图（DFD）、数据字典（DD）、结构化语言、判定树、判定表等。
结构化分析的核心是数据流程图，数据流程图是以图形的方式表达在问题中信息的变换和传递过程。它把系统看成是由数据流联系的各种概念的组合，用分解及抽象手段来控制需求分析的复杂性，采用分层的数据流程图来表示一个复杂的系统。
数据流图：简称DFD，就是采用图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
基于计算机的信息处理系统由数据流和一系列的加工构成，这些加工将输入数据流加工为输出数据流
数据流图描述数据流和加工
数据流图用图形符号表示数据流、加工、数据源及外部实体
数据流图具有层次结构，支持问题分解、逐步求精的分析方法
它是数据驱动的数据流图既可以表示基于计算机的系统，也可以表示软件
数据流图可以用来抽象地表示系统或软件。它从信息传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程，同时可以按自顶向下、逐步分解的方法表示内容不断增加的数据流和功能细节。因此，数据流图既提供了功能建模的机制，也提供了信息流建模的机制，从而可以建立起系统或软件的功能模型。
数据流图的基本符号的意思：
1.矩形表示数据的外部实体；
2.圆角的矩形表示变换数据的处理逻辑；
3.少右面的边矩形表示数据的存储；
4.箭头表示数据流。数据流程图中有以下几种主要元素：→：数据流。数据流是数据在系统内传播的路径，因此由一组成分固定的数据组成。如订票单由旅客姓名、年龄、单位、身份证号、日期、目的地等数据项组成。由于数据流是流动中的数据，所以必须有流向，除了与数据存储之间的数据流不用命名外，数据流应该用名词或名词短语命名。□：数据源（终点）。代表系统之外的实体，可以是人、物或其他软件系统。○：对数据的加工（处理）。加工是对数据进行处理的单元，它接收一定的数据输入，对其进行处理，并产生输出。〓：数据存储。表示信息的静态存储，可以代表文件、文件的一部分、数据库的元素等。