您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 管理学资料 > 7-UML中的几种其他图
第七章UML中的几种其他图•通讯图•活动图•包图7.1通讯图通讯图表示围绕着对象角色以及对象角色之间的链所组织的交互。与顺序图不同:1)通讯图表示扮演不同角色的对象之间的关系。2)通讯图不表示作为单独维度的时间,所以交互的顺序和并发进程必须用顺序数决定。顺序图表示执行消息的显式顺序,最好用于描述实时系统和复杂的场景。5.2.1概念与表示法通信图是一种强调发送和接收消息的对象结构组织的交互图,展示围绕对象以及它们之间的连接器而组织的交互。连接器是由关联实例化的链以及通过过程参数、局部变量或全局变量而产生的对象之间的临时连接。通讯图由对象(参与者)、连接器以及连接器上的消息构成。这些概念及表示法与前述中的都完全相同。为表示一个消息的时间顺序,可以给消息加一个数字前缀(从1号消息开始),在控制流中,每个新的消息的顺序号单调增加(如2,3等等)。为了显示嵌套,可使用带小数点的号码(1表示第一个消息;1.1表示嵌套在消息1中的第一个消息;1.2表示嵌套在消息1中的第二个消息;等等)。嵌套可为任意深度。要注意的是,沿同一个链,可以显示多个消息(可能发自不同的方向),并且每个消息都有唯一的一个顺序号。顺序图和通讯图在语义上是等价的,它们可以从一种形式的图转换为另一种。C:Clientt:Transactionp:ODBCProxysaction《create》SetActions(a,d,o)》《destroy》SetValue(d,3.4)SetValue(a,”CO”).4){transient}c:Clientt:Transactionp:ODBCProxysaction1:create2:setAction(a,d,o)3:destroy2.1:setValues(d,3.4)2.2:setValues(a,”CO”)上图与下图在语义上是等价的5.2.2建立通讯图应遵循如下策略建立通讯图:n设置交互的语境,不管它是一个系统、子系统、类,还是用况的脚本。n通过识别对象在交互中扮演的角色,设置交互的场所。将它们作为图的顶点放在通讯图中,较重要的对象放在图的中央,然后放置邻近的对象。n若对象之间可能要传递消息,说明对象之间的连接器。n从引起这个交互的消息开始,然后将随后的每个消息附到适当的连接器上,恰切地设置其顺序号。并用带小数点的编号来显示嵌套。n如果需要展示消息的循环或分支,就是使用相应的表示法。n如果需要说明时间或空间约束,则用时间标记修饰每个消息,并附上合适的时间和空间约束。像顺序图一样,建议一个单独的通讯图只描述一个控制流。一般来说,可能要建立许多通讯图,其中一些是基本的,另一些描述的是可选择的路径或例外情况。可以使用包来组织一组通讯图,并给每个图起一个合适的名称,以便与包中其它图的相区别。7.2活动图活动图可用于对业务过程和操作的算法建模7.2.1概念与表示法活动图显示从活动到活动的流。下面详述有关的概念。1、动作和活动动作的定义与状态图中的是一致的。如调用另一个操作,发送一个信号,创建或撤销一个对象,或者某些纯计算(例如对一个表达式求值),都是一个动作。活动可由动作和其他活动组成,最底层的活动是由动作执行的。在活动图中,动作和活动均具有图形表示法,且是一样的发送邮件审批发票2、控制流当动作或活动结束时,马上进入下一个动作或活动。一系列的动作和活动的执行构成了一个控制流。在图形上,用一个箭头表示从一个动作或活动到下一个动作或活动的转移开幕式比赛闭幕式控制流的分支与合并控制流也可以是并发的。用同步条表示并发控制流的分岔和汇合。3、对象流定购销售订单4、泳道在对业务过程建模时,可以把活动或动作分成组,每组由特定的履行者来执行。履行者可为人员、组织或其他业务实体。把每个组分别称为一个泳道。5、活动图活动图是展示从动作或活动间的控制流和对象流的图,其中的结点描述动作或活动,边描述控制流或对象流。一般用它对计算过程中的步骤建模,也可用它对步骤间的数值的流动建模。上述的计算过程可为业务过程,也可为操作的算法。注意,顺序图强调对象间的控制流,而活动图强调的是活动间的控制流。对于活动图中一个活动结点,可用另一张活动图(子活动图)进行详述。7.2.2建立活动图对业务过程建模,要遵循如下的策略:n设置业务过程的语境。即要考虑在特定的语境中要对哪些业务的履行者和业务实体建模。n考虑为每个重要的业务的履行者建立一个泳道。n建立初始状态和终止状态,并识别该业务过程的前置条件和后置条件。n从初始状态开始,说明随着时间发生的动作或活动,并在活动图中表示它们。n如果涉及到重要的对象,则把它们也加入到活动图中。如果有必要,可展示对象的属性值和状态。n连接这些动作和活动结点的流。n如果需要,使用分支和合并来描述条件路径和迭代,使用分岔和汇合来描述并发的动作或活动流。n针对活动建立子活动图。对一个操作建模时,应遵循如下策略:n收集该操作所涉及的事物,包括操作的参数、可能的返回类型、它所属于的类以及某些邻近的类的特征。n识别操作的前置条件和后置条件以及操作所属的类在操作执行期间必须保持的不变式。n从该操作的初始状态开始,按照时间顺序设立活动或动作,并在活动图中将它们表示出来。n如果需要,使用分支和合并来描述条件路径和迭代。n仅当这个操作属于一个主动类时,才在必要时用分岔和汇合来描述并发的控制流。在OOA阶段,仅用活动图对关键的复杂操作进行建模,用以展示关于算法的一些信息。除非想直接从模型生成代码,即使在OOD阶段并也不要求用活动图对每个操作的算法都建立模型。7.3包图对一个较为复杂的系统建模,要使用大量的模型元素,这时就必要把这些元素分组进行组织。这样把在语义上接近且倾向于一起变化的模型组织在一起,不但控制模型的复杂度,有助于理解,而且也有助于按组控制元素的可见性。7.3.1概念与表示法包是对模型元素分组的机制。使用包的最常见目的是把建模元素组织成为组,作为一个集合进行命名和处理。包可以拥有类、接口、构件、节点、用况和图,甚至可以是其它包。拥有是一种组成关系,这意味着被拥有的元素被声明在包中。如果包被撤消了,元素也要被撤消。一个元素只能被一个包所拥有。设计良好的包,把在语义上接近并倾向于一起变化的元素组织在一起。因此结构良好的包是松耦合、高内聚的,而且对其内容的访问具有严密的控制。编号包名类名类名······类名······包名包名半展开方式压缩方式全展开方式……包的层次性因为包中还可以有包,这样包之间可以有一个层次,且在组织结构上是一棵严格的树。在实际使用中,最好要避免过深地嵌套包,一般两、三层即可。对过多的嵌套,要用“引入依赖”来组织包。对包中元素的命名一个包形成了一个命名空间,这意味着在一个包的语境中同一种元素的名字必须是唯一的。例如,同一个包不能拥有两个名为Queue的类,但在P1包中可以有一个名为Queue的类,而在P2包中又有另一个(不同的)名为Queue的类。实际上,类P1::Queue和类P2::Queue是不同的类,这可以由各自的路径名区别开来。如果一个包位于另一个包中,外层的包可作为里层包的前缀。例如,在包Vision中有一个名为Camera的类,而包Vision又在包Sensor中。类Camera的全名为Sensor::Vision::camera。在一个包中不同种类的元素可以有相同的名字。这样,在同一个包中,对一个类命名为Timer,对一个构件也可以命名为Timer。为了不造成混乱,最好对一个包中所有元素也都唯一地命名。如果包的内容没有被显示在大矩形中,那么可以把该包的名字放在大矩形中。如果包的内容被显示在大矩形中,那么可以把该包的名字放在左上角的小矩形中。包中元素的可见性一个包中的元素在包外的可见性,通过在元素名字前加上一个可见性符号来指示。模型元素的可见性可为+(公共的)、-(私有的)、#(受保护的)或~(包范围的),它们的含义为:+:标有“+”号的模型元素对所有的引入包以及它们的后代是可见的。包的各公共部分一同构成包的接口。-:标有“-”号的模型元素只对包内的元素是可见的。#:标有“#”号的模型元素只对那些与包含这些元素的包有泛化关系的子包是可见的。~:标有“#”号的模型元素只对在同一包内声明的其他元素是可见的。包间的关系包之间不但可以具有拥有关系,包之间也可以具有引入关系、访问关系或泛化关系。定义引入依赖是两个包之间的一种许可依赖关系,一个包中的可见性为公有的模型元素,可以在指定的包(包括嵌套在该包中的子包)中被引用,相当于把提供者包的内容附加到客户包的公共命名空间中,而不必对名称进行限制。把引入依赖绘制成带有箭头的虚线,其上标有串import。定义访问依赖是两个包之间的一种许可依赖关系,一个包中的可见性为公有的模型元素,可以在指定的包(包括嵌套在该包中的子包)中被引用,相当于把提供者包的内容附加到客户包的私有命名空间中,而不必对名称进行限制。把访问依赖绘制成带有箭头的虚线,其上标有串access。包间的泛化关系与类间的泛化很类似,即特殊包可以继承一般包中的可见性为公共的或受保护的元素,而且在特殊包中还可以有自己的元素,自己的元素可以覆盖继承来的元素。Server-Database-LoggingServiceClient+OrderForm+TrackingForm-OrderPolicies+OrderRulesGUI+Window+Form#EventHandlerPolicies显式地引入包GUI。因此,对于类GUI::Window和类GUI::Form,包Policies的内容使用简单名Window和Form就能访问它们。然而,由于GUI::EventHandler是受保护的,因此它是不可见的。由于包Server没有引入GUI,Server中的内容必须用限定名才能访问GUI的公共内容,例如,GUI::Window。类似地,由于Server中的内容是私有的,GUI的内容无权访问Server中的任何内容,即使用限定名也不能访问它们。引入和访问依赖是传递的。在本例中,Client引入Policies,Policies引入GUI,所以Client就传递地引入了GUI。因此,Client的内容可以访问Policies的引出,同样可以访问GUI的引出。如果Policies访问GUI,而不是引入它,Client则不能把GUI中的元素添加到自己的命名空间,但是仍然能通过限定名(如GUI::Window)引用它们。《import》《import》嵌套的包之间也存在着可见性问题:1)里层的包中的元素能够访问其外层包中定义的可见性为公共的元素,也能访问其外层包通过访问或引入依赖而得来的元素。2)一个包要访问它的内部包的元素,就有与内部包有引入、访问关系或使用限定名。3)里层包中的元素的名字会掩盖外层包中的同名元素的名字,在这种情况需要用限定名引用外层包中的同名元素。7.3.2如何划分与组织包识别低层包每个具有泛化关系或聚合关系的元素位于一个包关联密集的类划分到一个包独立的类暂时作为一个包合并或组织包如果低层包数量过多,则把它们合并,或用高层包组织它们。若低层包之间在概念上接近或具有较强的相关性,从作用上属于某项大的功能,在图上有较强的耦合性,或在分布上处于同一台处理机,则考虑把它们合并,或用高层包组织它们。建议每个包有7±2个内层成分。——在一张A4纸上表达不清楚时就划分包(MartinFowler)组织包的层次层次不宜太多包的划分不是唯一的,有一定的随意性标识包中的模型元素的可见性对每一个包,确定哪些元素在包外是可以访问的,把它们标记为公共的。把所有其它的元素标记为受保护的或私有的。建立包间的关系根据需要,在包之间建立引入依赖、访问依赖或泛化关系。包的用处1、组织相关元素,以便于管理和便于复用。包是一个命名空间,外部使用要加限定名。2、包引入放松了限制。被引入的元素与引入包中的元素可以进行关联,或建立泛化关系。3、便于组合可复用的元建模特征,以创建扩展的建模语言。也即把被合并包的特征结合到合并包,以定义新的语言
本文标题:7-UML中的几种其他图
链接地址:https://www.777doc.com/doc-3421721 .html