·单向关联
在一个单向关联中，两个类是相关的，但是只有一个类知道这种联系的存在。
一个单向的关联，表示为一条带有指向已知类的开放箭头（不关闭的箭头或三角形，用于标志继承）的实线。如同标准关联，单向关联包括一个角色名和一个多重值描述，但是与标准的双向关联不同的时，单向关联只包含已知类的角色名和多重值描述。
简单的说就是OverdrawAccountReport中包含了BankAccount属性，而BankAccount中不需要包含OverdrawnAccountsReport对象
6.聚合的表示：
聚合是一种特别类型的关联，用于描述“总体到局部”的关系。在基本的聚合关系中， 部分类 的生命周期独立于 整体类 的生命周期。
举例来说，我们可以想象，车 是一个整体实体，而 车轮 轮胎是整辆车的一部分。轮胎可以在安置到车时的前几个星期被制造，并放置于仓库中。在这个实例中，Wheel类实例清楚地独立于Car类实例而存在。然而，有些情况下， 部分 类的生命周期并 不 独立于 整体 类的生命周期 -- 这称为合成聚合。举例来说，考虑公司与部门的关系。 公司和部门 都建模成类，在公司存在之前，部门不能存在。这里Department类的实例依赖于Company类的实例而存在。
让我们更进一步探讨基本聚合和组合聚合。
注意：聚合与普通的关联的区别在于：普通的关联可能只是一个简单的“包含、引用”关系，关联和被关联类之间在逻辑概念上不一定有紧密的联系，而聚合则不同，它表示的是一种内在关系紧密，相互依存，相互包含的概念，其中的一部分是构成另外一部分的不可或缺的成分。
·基本聚合
有聚合关系的关联指出，某个类是另外某个类的一部分。在一个聚合关系中，子类实例可以比父类存在更长的时间。为了表现一个聚合关系，你画一条从父类到部分类的实线，并在父类的关联末端画一个未填充棱形。
图中清楚的表明了类Car对象包含了另一类Wheel的4个实例，这两者在概念上是密不可分的，其中的一个类是另一个类的构成成分。菱形表示“包含”，箭头表示被包含的对象，数字4表示包含的数目。
·组合聚合
组合聚合关系是聚合关系的另一种形式，但是子类实例的生命周期依赖于父类实例的生命周期。
注意:组合关系如聚合关系一样绘制，不过这次菱形是被填充的。
7.反射关联的表示：
类也可以使用反射关联与它本身相关联。起先，这可能没有意义，但是记住，类是抽象的。当一个类关联到它本身时，这并不意味着类的实例与它本身相关，而是类的一个实例与类的另一个实例相关。
图描绘的关系说明一个Employee实例可能是另外一个Employee实例的经理。然而，因为“manages”的关系角色有 0..*的多重性描述；一个雇员可能不受任何其他雇员管理。
三、UML中的对象图：
实例的记号和类一样，但是取代顶端区域中仅有的类名，它的名字是经过拼接的:
Instance Name : Class Name 如 Donald : Person
因为显示实例的目的是显示值得注意的或相关的信息，没必要在你的模型中包含整个实体属性及操作。相反地，仅仅显示感兴趣的属性及其值是完全恰当的。
UML 2 也允许在实体层的关系/关联建模。绘制关联与一般的类关系的规则一样，除了在建模关联时有一个附加的要求。附加的限制是，关联关系必须与类图的关系相一致，而且关联的角色名字也必须与类图相一致。
四、UML中的角色图：
建模类的实例有时比期望的更为详细。有时，你可能仅仅想要在一个较多的一般层次做类关系的模型。在这种情况下，你应该使用 角色 记号。角色记号类似于实例记号。为了建立类的角色模型，你画一个方格，并在内部放置类的角色名及类名，作为实体记号，但是在这情况你不能加下划线。
注意：角色图和对象图的一个明显区别就是：对象图每个对象名称下面都加了下划线，而角色图没有
以下是：序列图
序列图主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。很象类图，开发者一般认为序列图只对他们有意义。然而，一个组织的业务人员会发现，序列图显示不同的业务对象如何交互，对于交流当前业务如何进行很有用。除记录组织的当前事件外，一个业务级的序列图能被当作一个需求文件使用，为实现一个未来系统传递需求。在项目的需求阶段，分析师能通过提供一个更加正式层次的表达，把用例带入下一层次。那种情况下，用例常常被细化为一个或者更多的序列图。
组织的技术人员能发现，序列图在记录一个未来系统的行为应该如何表现中，非常有用。在设计阶段，架构师和开发者能使用图，挖掘出系统对象间的交互，这样充实整个系统设计。
序列图的主要用途之一，是把用例表达的需求，转化为进一步、更加正式层次的精细表达。用例常常被细化为一个或者更多的序列图。序列图除了在设计新系统方面的用途外，它们还能用来记录一个存在系统（称它为“遗产”）的对象现在如何交互。当把这个系统移交给另一个人或组织时，这个文档很有用。
Java应用程序由许多类所构成，是Java实现面向对象应用程序的核心。类图主要描述Java应用程序中各种类之间的相互静态关系，如类的继承、抽象、接口以及各种关联。要利用UML设计Java应用程序，仅仅使用类图来描述这些静态关系，利用可视化工具，要实现Java应用程序的代码自动生成，是远远不够的。我们还必须描述各种类相互之间的协作关系、动态关系，如时间序列上的交互行为。其中UML序列图就是用来描述类与类之间的方法调用过程（或消息发送）是如何实现的。
一、UML中的新元素－框架：
在 UML 2中，框架元件用于作为许多其他的图元件的一个基础，但是大多数人第一次接触框架元件的情况，是作为图的图形化边界。当为图提供图形化边界时，一个框架元件为图的标签提供一致的位置。在 UML 图中框架元件是可选择的。
除了提供一个图形化边框之外，用于图中的框架元件也有描述交互的重要的功能, 例如序列图。在序列图上一个序列接收和发送消息（又称交互），能通过连接消息和框架元件边界，建立模型（如图 2 所见到）。
对于序列图，图的标签由文字“sd”开始。当使用一个框架元件封闭一个图时，图的标签需要按照以下的格式：图类型 图名称。
UML 规范给图类型提供特定的文本值。（举例来说，sd代表序列图，activity代表活动图，use case代表用例图）。
二、UML中的序列图：
序列图主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。
在项目的需求阶段，分析师能通过提供一个更加正式层次的表达，把用例带入下一层次。那种情况下，用例常常被细化为一个或者更多的序列图。
序列图的主要用途之一，是把用例表达的需求，转化为进一步、更加正式层次的精细表达。用例常常被细化为一个或者更多的序列图。序列图除了在设计新系统方面的用途外，它们还能用来记录一个存在系统（称它为“遗产”）的对象现在如何交互。
序列图的主要目的是定义事件序列，产生一些希望的输出。重点不是消息本身，而是消息产生的顺序；不过，大多数序列图会表示一个系统的对象之间传递的什么消息，以及它们发生的顺序。图按照水平和垂直的维度传递信息：垂直维度从上而下表示消息/调用发生的时间序列，而且水平维度从左到右表示消息发送到的对象实例。
1.生命线：
生命线画作一个方格，一条虚线从上而下，通过底部边界的中心（图 3）。生命线名字放置在方格里。
UML 的生命线命名标准按照如下格式: 实体名:类名
生命线名称带下划线。当使用下划线时，意味着序列图中的生命线代表一个类的特定实体，不是特定种类的实体（例如，角色）。序列图的实例名称有下划线，而角色名称没有。
一个生命线能用来表现一个匿名的或未命名的实体。当在一个序列图上，为一个未命名的实例建模时，生命线的名字采用和一个命名实例相同的模式；但是生命线名字的位置留下空白，而不是提供一个例图名字。
2.消息体：
为了显示一个对象（例如，生命线）传递一个消息给另外一个对象，你画一条线指向接收对象，包括一个实心箭头（如果是一个同步调用操作）或一个棍形箭头（如果是一个异步讯号）。消息/方法名字放置在带箭头的线上面。正在被传递给接收对象的消息，表示接收对象的类实现的一个操作/方法。
返回消息是可选择的；一个返回消息画作一个带开放箭头的虚线，向后指向来源的生命线，在这条虚线上面，你放置操作的返回值。为了要画一个调用本身的对象，如你平时所作的，画一条消息，但是不是连接它到另外的一个对象，而是你把消息连接回对象本身。
三、UML中的约束：
约束的符号很简单；格式是: 【Boolean Test】
四、UML中的新元素－组合碎片（变体方案、选择项、循环）：
一个组合碎片用来把一套消息组合在一起，在一个序列图中显示条件分支。
1.变体：
变体用来指明在两个或更多的消息序列之间的、互斥的选择。一个变体的组合碎片元件使用框架来画。单词“alt”放置在框架的namebox里。然后较大的长方形分为 UML 2 所称的操作元。操作元被虚线分开。每个操作元有一个约束进行测试，而这个约束被放置在生命线顶端的操作元的左上部。如果操作元的约束等于“true”，然后那个操作元是要执行的操作元。
图 8作为一个变体的组合碎片如何阅读的例子，显示序列从顶部开始，即bank对象获取支票金额和帐户结余。此时，序列图中的变体组合碎片接管。因为约束“[balance >= amount]”，如果余额超过或等于金额，然后顺序进行bank对象传递 addDebitTransaction 和 storePhotoOfCheck 消息给account对象。然而，如果余额不是超过或等于金额，然后顺序的过程就是bank传递addInsuffientFundFee 和 noteReturnedCheck 消息给account对象，returnCheck 消息给它自身。因为“else”约束，当余额不大于或者等于金额时，第二个序列被调用。在变体的组合碎片中，不需要“else”约束；而如果一个操作元，在它上面没有一个明确的约束，那么将假定“else”约束。
2.选择项：
一个选择项用来为简单的“if then”表达式建模。（例如，如果架上的圈饼少于五个，那么另外做两打圈饼）。
选择项组合碎片符号与变体组合碎片类似，除了它只有一个操作元并且永不能有“else”约束以外（它就是如此，没有理由）。要画选择项组合，你画一个框架。文字“opt”是被放置在框架的 namebox 里的文本，在框架的内容区，选择项的约束被放置在生命线顶端上的左上角。 然后选择项的消息序列被放在框架的内容区的其余位置内。
注意：变体用于为if then else建模，选择项用于为if then建模，因为只有一个分支，所以不能出现[else]
以下是：用例图：
用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。
用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。
共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
1、包含(include)
包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。
2、扩展(extend)
扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。
对于一个扩展用例，可以在基用例上有几个扩展点。
例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：
4、泛化(generalization)
泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。
例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示： 
上面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目(在线购物系统)的用例做了整体的描绘。
*****************************************************************
(1)系统整体用例图
(商品用例图)
（购买信息用例）
(用户资料用例)
按照先整体用例，后子系统用例来进行描绘的，欢迎大家提出好的建议!
转：UML中扩展和泛化的区别
泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：
●泛化侧重表示子用例间的互斥性；
●包含侧重表示被包含用例对Actor提供服务的间接性；
●扩展侧重表示扩展用例的触发不定性；详述如下：
既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：
⒈无条件发生：肯定发生的；
⒉有条件发生：未必发生，发生与否取决于系统状态；
因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。
另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。
以下是：活动图
UML 活动图记录了单个操作或方法的逻辑，单个用户案例，或者单个业务流程的逻辑。在很多方面，活动图是结构化开发中流程图和数据流程图 (DFD) 的面向对象等同体,要创建一个 UML 活动图，您需要反复执行下列步骤。
第一步，定义活动图的范围首先应该定义您要对什么建模。单个用户案例力？一个用户案例的一部分？一个包含多个用户案例的商务流程？一个类的单个方法？一旦您定义了您所作图的范围，您应该在其顶部，用一个标注添加标签，指明该图的标题和唯一的标示符。您有可能也想要包括该图的时间甚至作者名。
第二步，添加起始和结束点每个活动图有一个起始点和结束点，因此您也要马上添加它们。在 《UML 精粹》(UML Distilled) (参见参考资料)，Fowler 和 Scott 认为结束点是可选的。有时候一个活动只是一个简单的结束，如果是这种情况，指明其唯一的转变是到一个结束点也是无害的。这样，当其他人阅读您的图时，他或她知道您已经考虑了如何退出这些活动。
第三步，添加活动如果您正对一个用户案例建模，对每个角色(actor)所发出的主要步骤引入一个活动(该活动可能包括起始步骤，加上对起始步骤系统响应的任何步骤)。如果您正对一个高层的商务流程建模，对每个主要流程引入一个活动，通常为一个用户案例或用户案例包。最后，如果您正对一个方法建模，那么对此引入一个活动是很常见的。
第四步，添加活动间的转变我的风格总是应该退出一个活动，即使它是转变到一个结束点。一旦一个活动有多个转变时，您必需对每个转变加以相应标示。
第五步，添加决策点有时候，您所建模的逻辑需要做出一个决策。有可能是需要检查某些事务或比较某些事务。要注意的是，使用决策点是可选的。
第六步，找出可并行活动之处当两个活动间没有直接的联系，而且它们都必需在第三个活动开始前结束，那它们是可以并行运行的。
下面的活动图描述了大学新生第一次将如何办理入学的商业逻辑。
- 实心圆表示活动图的起点，实际上是一个占位符，带边框的实心圆表示终点。
- 圆角矩形表示执行的过程或活动。在该图中，虽然您会注意到“登记研习班”用例将多次调用“登记研习班”活动，但这些活动却相当紧密地映射到用例。活动可以细致得多，特别在选择记录方法逻辑，而不是高级商业过程时。
- 菱形表示判定点，虽然在此示例中判定点只有两种可能结果；但即使有更多可能结果，它也同样容易。
- 箭头表示活动之间的转换，各种活动之间的流动次序。
- 箭头上的文字表示继续转换所必须满足的条件，总是使用格式“[条件]”来描述。我猜想，在 UML 的将来版本中，我们将会看到使用 UML 约束表示法（如“{condition}”）记录的条件。
- 粗线条表示可能会并行进行的过程的开始和结束；在大学里成功入学后，必须参加指定的概况介绍，还要至少登记一个研习班并交付一部分的学费。
退出活动可能有几种方法，如您看到的“填写入学表”活动的那样。如果正确填写了表格，那么可以继续进行大学的入学手续。但是，如果表格不正确，那么必须获得帮助（可能从注册员获得帮助）以正确填写它们。
这个活动图非常有趣，因为它省掉了
中标识的几个用例的逻辑。用例模型没有很好地表达处理的顺序是件好事。例如，虽然 中显示的用例图为您清楚地描述了该系统所执行的功能类型，但是它没有明确地表达这些用例可能发生的顺序。但是， 的活动图做到了这一点。总之，不同模型的优缺点各有不同。
图 2 中标识的几个用例的逻辑。用例模型没有很好地表达处理的顺序是件好事。例如，虽然 图 2 中显示的用例图为您清楚地描述了该系统所执行的功能类型，但是它没有明确地表达这些用例可能发生的顺序。但是， 图 1 的 活动图做到了这一点。总之，不同模型的优缺点各有不同。
泳道
将模型中的活动按照职责组织起来通常很有用。例如，可以将一个商业组织处理的所有活动组织起来。这种分配可以通过将活动组织成用线分开的不同区域来表示。由于它们的外观的缘故，这些区域被称作泳道。 图 7–2 表示了泳道。
图 7–2 泳道和对象流
· 2. 对象流
活动图能表示对象的值流和控制流。对象流状态表示活动中输入或输出的对象。对输出值而言，虚线箭头从活动指向对象流状态。对输入值而言，虚线箭头从对象流状态指向活动。如果活动有多个输出值或后继控制流，那么箭头背向分叉符号。同样，多输入箭头指向结合符号。
图 7–2 表示一个活动和对象流状态都被分配到泳道中的活动图。
· 活动和其他图
活动图没有表示出计算处理过程中的全部细节内容。它们表示了活动进行的流程但没表示出执行活动的对象。活动图是设计工作的起点。为了完成设计，每个活动必须扩展细分成一个或多个操作，每个操作被指定到具体类。这种分配的结果引出了用于实现活动图的对合协的设计工作。
以下是数据流图DFD：
研究了一下DFD:
结构化分析是面向数据流开展需求分析工作的一种有效方法。一般采用自顶向下，逐层分解的演义分析法来定义系统的需求，即先把分析对象抽象成一个系统，然后自顶向下的逐层分解，将复杂的系统分解成简单的、能够清楚地被理解和表达的若干个子系统，如图1（逐层分解的数据流程图）所示。这样就可以分别理解系统的每个细节、前后顺序和相互关系，找出各部分之间的数据接口。在结构化分析方法所采用的工具有数据流程图（DFD）、数据字典（DD）、结构化语言、判定树、判定表等。
结构化分析的核心是数据流程图，数据流程图是以图形的方式表达在问题中信息的变换和传递过程。它把系统看成是由数据流联系的各种概念的组合，用分解及抽象手段来控制需求分析的复杂性，采用分层的数据流程图来表示一个复杂的系统。
数据流图：简称DFD，就是采用图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
基于计算机的信息处理系统由数据流和一系列的加工构成，这些加工将输入数据流加工为输出数据流
数据流图描述数据流和加工
数据流图用图形符号表示数据流、加工、数据源及外部实体
数据流图具有层次结构，支持问题分解、逐步求精的分析方法
它是数据驱动的数据流图既可以表示基于计算机的系统，也可以表示软件
数据流图可以用来抽象地表示系统或软件。它从信息传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程，同时可以按自顶向下、逐步分解的方法表示内容不断增加的数据流和功能细节。因此，数据流图既提供了功能建模的机制，也提供了信息流建模的机制，从而可以建立起系统或软件的功能模型。
数据流图的基本符号的意思：
1.矩形表示数据的外部实体；
2.圆角的矩形表示变换数据的处理逻辑；
3.少右面的边矩形表示数据的存储；
4.箭头表示数据流。
数据流程图中有以下几种主要元素：
→：数据流。数据流是数据在系统内传播的路径，因此由一组成分固定的数据组成。如订票单由旅客姓名、年龄、单位、身份证号、日期、目的地等数据项组成。由于数据流是流动中的数据，所以必须有流向，除了与数据存储之间的数据流不用命名外，数据流应该用名词或名词短语命名。
□：数据源（终点）。代表系统之外的实体，可以是人、物或其他软件系统。
○：对数据的加工（处理）。加工是对数据进行处理的单元，它接收一定的数据输入，对其进行处理，并产生输出。
〓：数据存储。表示信息的静态存储，可以代表文件、文件的一部分、数据库的元素等。
扫一扫
7975
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
