ITPub博客

首页 > 应用开发 > IT综合 > 第13章 术 语 大 全 (3) (转)

第13章 术 语 大 全 (3) (转)

原创 IT综合 作者:amyz 时间:2007-10-11 13:40:41 0 删除 编辑
第13章 术 语 大 全 (3) (转)[@more@]

53.规范表示法(canonical notation)
UML定义了规范表示法,它用单色线和文字表示任何模型。这就是UML模型的标准"出版格式",可用于印刷图。
图形编辑工具可以扩展规范表示法并且提供交互能力。比如,一个工具提供突出屏幕中被选择元素的能力。其他交互能力包括模型中的导航和按照选择的特性过滤显示的模型。这种格式是暂时的,并且不受UML制约。交互显示减少了模棱两可的弊端。所以,UML标准的焦点是印刷的规范形式,一个交互工具可以而且应该提供交互扩展。
54.基数(cardinality)
基数是集合中元素的数量。它是一个具体的数值。基数不同于多重性,多重性是一个集合拥有的可能基数的范围。
讨论
请注意基数这个术语被许多作者错用为我们所谓的多重性,但是基数在数学上定义为一个数字,而不是数的范围。这正是我们所用的定义。
55.修改事件(change event)
由于所引用的一个或多个值的改变而使布尔表达式得到满足的事件称为修改事件。
见监护条件(guard condition)。
语义
修改事件包含由一个布尔表达式指定的条件。事件没有参数。由于条件所依赖的一个或多个变量的改变而使条件(从假)变成真时,事件就发生。
这种事件隐含一个对条件的连续的测试。而实际上,通过分析条件输入改变的时间点,开发者可以在良好定义的、抽象的时间上执行测试,这样就不需要连续的测试了。
当表达式的值从假改变到真(一个正值状态变化)时,事件就发生。当这种情况发生时事件发生一次,除非值又先变成假,否则,事件不会再发生。
请注意与监护条件的区别。当转换上的事件发生时,监护条件只计算一次。如果条件是假的,那么转换不激发并且事件被遗失(除非这个事件又触发了其他的转换)。一个修改事件隐含连续计算,并且当值变成真时事件发生一次。在那个时刻,它可以触发一个转换或被忽略。如果它被忽略,因为条件还是真所以修改事件不触发处于后继状态的转换。修改事件已经发生,因此被抛弃。条件必须变成假,然后再变成真时,才能引发另一个修改事件。
布尔表达式的值必须是对象的属性,这个对象拥有包含从它可到达的转换或值的状态机。
表示法
与信号不同,修改事件没有名字并且不被声明。它们仅仅被用作转换的触发。修改事件表示成关键字when,后面是圆括弧中的布尔表达式。例如:
when(self.waitingCustomers>6)
讨论
修改事件是对条件满足的测试。实现起来是十分昂贵的,虽然有技巧来编译它而不必连续地测试,但是修改事件本身隐含着高成本和一种特定的关系,即值的改变与由它触发的结果之间的直接因果关系。有时,这是令人满意的,因为它封装了结果,但应该小心使用修改事件。
修改事件表示对对象可见的值的测试。如果一个对象中属性改变意味着触发另一个对象(该对象不知道第一个对象的属性改变)的修改,那么这种情况应该建模成属性拥有者上的修改事件,它触发一个内部转换,向第二个对象发送信号。
请注意一个修改对象并不是明确地向任何地方发送。如果试图与另一个对象进行明确地通信,应该用信号。
修改事件可以通过多种方式实现,有些通过在合适的时间点在应用程序内部进行测试,而有些则通过利用基本的操作系统机制来完成。
56.可变性(changeability)
说明某属性值或者链是否可变的一种特性。
语义
本特性可以赋给关联端或者属性。此特性还可以赋给一个类,表明该类中的所有关联和属性都满足本特性(例如,特性值为"冻结")表示该类的对象的值在初始化后不可改变)。在特性表中代表可变性的关键字可取下列枚举值。
可变的(changeable)
属性值可以任意变换,包括在多重性允许的范围内增加或者删除值。链可以随意变更,或者在多重性及其他约束允许的范围内被增加或者删除。如果没有指定其他值,则以此为默认值。
冻结的(frozen)
属性值在初始化后不可变更;不可增加或者删除变量。当关联的另一端(即与带有冻结值的一端相对另一边)的对象初始化后,则不可增加,删除或者修改链。但是,当另一端生成新的对象时,作为初始化的一部分,将生成指向冻结端的新连接。
只可增加(addonly)
如果多重性不是固定值,或者尚未达到最大值,则可以增加新的属性值。一旦生成,只要类的对象仍然存在,就不能更改或删除属性值。可以增加新的链,但是不能在其生成后进行修改或删除。当一个参与者对象被删除时,其中包含的所有链,无论是否是"只可增加"类型的,都将被删除。
57.子(child)
泛化关系中更具体的元素。被称为一个类的子类。一个或者多个子关系的链称为后代。反义词:父(parent)
语义
子元素继承了其父元素的特征(同样间接继承了其祖先的特征)而且可以声明自己附加的特征。它还继承了涉及其祖先的关联和约束。子元素遵循替代原则--即描述符的实例满足任何该描述符祖先声明的变量。子的实例是其父的间接实例。
58.类(class)
说明一系列拥有相同的属性,操作,方法,关系,行为的对象集。一个类就代表了被建模系统中的一个概念。根据模型种类的不同,此概念可能是现实世界的(对于分析模型),或还可能含有算法和计算机实现的概念(对于设计模型)。类元是类的泛化,包含其他类似类的元素,如数据类型、参与者、构件。
语义
对对象集的数据结构及行为的描述称为类。类用于声明变量。作为变量值的对象必须属于一个类,该类应与声明该变量的类兼容--也就是说,该类必须是声明变量的类或其后代类。类还用来实例化对象。一个创建操作生成给定类的一个新实例。
类的实例对象,是这个类的直接实例,同时是该类的父类的间接实例,对象保存
每一个属性的值;接受本类的所有操作和信号。同时还可以出现在与本类或本类的父类相关的关联链中。有些类可能不会被直接实例化,而只用于描述其后代类共享的结构;这种类被称为抽象类。可以实例化的类称为具体类。
一个类还可以被当作全局对象,该类任何类作用域属性是这个隐式对象的属性。这样的属性有全局性,在整个系统中拥有唯一的值。类作用域的操作是指适用于类本身,而不适用于对象的操作。最常见的类作用域操作就是创建操作。
在UML中,类是一种类元,类元包括一系列类似于类的元素,但是它的完整表述仍在类中。

结构
一个类有名字以及一些操作、方法和属性。类可能属于某种关联、泛化关系、依赖关系,或者约束关系。类是在其命名空间内声明,比如在一个包或者其他的类内,在其名字域内有不同的特性,比如多重性或者可见性。类还拥有其他不同特性,比如用于说明它是抽象类还是主动类。还将有一个状态机来说明类的反应行为--就是说当接收到某事件时的反应。类可声明其所处理的事件集(包括异常处理)。类可为由零个或多个的接口提供实现,或为一个行为实现提供不同类型。接口列出了该接口支持的并由类实现的操作集。
类包含属性表和操作表,它们各自在类内建立了一个命名空间。继承的属性和操作同样出现在相应的命名空间内。属性的命名空间中还包括伪属性,例如联系的角色名,用于类和用于涉及该类或它的一个祖先的泛化关系的区分符的,每个名字在该类和其祖先中仅能声明一次,否则,将产生冲突,模型建立错误。如果所代表的操作相同,相应的操作名可重复,否则将产生冲突。
类也是一个命名空间,并为嵌套类元声明建立了的作用域。嵌套类元并不是类的实例的结构性部分。在类对象与嵌套类对象之间并没有数据联系。嵌套类是一个可能被外层类的方法所使用的类的声明。在类内的类声明是私有的,除非清楚的设定为可见,否则在该类的外部是不可访问的。 没有可见的标识符来表示嵌套类的声明。只有在利用超级链接工具时,才有可能对它们进行访问。嵌套的名字必须用路径名来指定。

图13-40 基类声明

表示法
一个类是用实线边框的矩形来表示的,矩形用两条水平线分为三部分。顶部分格包含类的名字以及其他适用于整个类的特性。中部分格包含属性表。底部分格包含操作表。中部和底部可以在类的标识内隐藏。
使用 类是在类图中声明的,并且在许多其他图中被使用。UML为声明和使用类提供了一种图形表示法,同时为了在其他模型元素的指明类提供了文字表示法。在类图中对类的声明定义了类的内容:类的属性、操作以及其他特性。其他的图中定义与类相关的其他关系和附件。
图13-40表示了带有属性和操作的基类声明。
图13-41表示了相同类的声明,其中包括了更详细的内容,主要是与实现有关的性质, 例如可见性、类层次作用域的创建操作以及依赖于实现的操作。
所有与类相关的内部信息在图13-42中没有表示。这些信息仍出现内部模型中,通常会在至少一幅图中表示。
表示选项(presentation options)
隐藏分格。隐藏属性和操作其中之一或全部(图13-43)。没有表示的间隔将不出现分隔线。如果某个分格被隐藏,则无法推断其中的元素是否存在。请注意,空的分格(即有分隔线,但是没有内容)说明相应的列表中没有元素。如果使用某种筛选程序,则说明没有符合其要求的元素。例如,只有公共操作是可见的,则相应的操作分格为空就说明没有公有操作。对于私有操作不能得出任何结论。

图13-41 带有可见性特征的详细的类声明

图13-42 隐藏了所有详细内容的类的例子

图13-43 隐藏了属性以及非公共操作的类的声明。
附加分格 附加分格用于表示其他预定义或者用户定义的模型特性--例如用于表示事务规则,职责,变化,信号处理,异常处理等等。附加分格的顶部写有分格名字,并用特殊的字体与其内容区分开来(见图13-44)。标准分格(属性,操作)则不需要分格名字,尽管在只有一个分格可见时,可能会用分格名以示强调或区别。多数的分格中只是简单的字符串表,其中的每一个字符串代表一个特性。这里的"字符串"包括图标和嵌入的文档,例如电子表格或者图形。还可能有更复杂的格式,但是UML并没有为这些格式作特别说明。这种说明是用户或工具的职责。如果分格的性质可以从其中内容 的格式判断出来,则分格的名字可以省略。
见字体的使用(font usage)、字符串(string)

图13-44 带有额外命名的分格的类的声明

图13-45 带有构造类型的类
构造型 构造型在类的名字上方以括在书名号(《》)内的文本字符串来表示(见图13-45)。还可以在分隔的右上角用图标来代替这行文字。带有构造型图标的类的标识可以被"压缩"为只表示类的构造类型图标,并在图标内,或者图标下方标明类的名字(见图13-170)。类的其他内容被隐藏。
见 构造型(stereotype)。
格式指导
。 用正常字体在类名字的上方书写构造类型
。 用黑体字居中或者向左对齐,书写类名
。 用正常字体,向左对齐书写属性和操作
。 用斜体字书写抽象类的名字,或者抽象操作的符号
。 在需要处表示类的属性格和操作格(在一套图中至少出现一次),在其他上下文或提及处可以隐藏它们。最好为一套图中的每个类定义一个"原始位置(home)",并在此处对类进行详细描述。在其他位置,可以使用类的最小化表示形式。
讨论
类的概念既适用于逻辑建模中的一些用例,也适用于实现。既包括类型的概念,又包括类的实现的概念。在UML中,在特定语义模糊的地方,一个对象可以有多个类,还可以在运行时变更类。在多数程序设计语言中常见的有更严格限制的类的定义,可以被视为特殊的类。
标准元素
实现类(implemetationClass),类型(type)
59.类图(class diagram)
类图,用静态视的方式表示声明的(静态的)模型元素,比如类、类型及其元素
及相互关系。类图可能表示包,甚至包含嵌套的包的符号。类图包含一些具体的行为元素,如操作,但是它们的动态特征是在其他图中表示的,例如状态图、合作图。
见类元(classifier)、对象图(object diagrams)

表示法
类图是用图形方式表示静态视图。通常,为了表示一个完整的静态视图,需要几个类图。每个独立的类图不需要说明基础模型中的划分,即使是某些逻辑划分,例如包是构成该图的自然边界。
60.状态类(class-in-state)
一个类,以及其对象可能存在的状态。
见活动图(activity graph)
语义
带有状态机的类有许多状态,每个状态说明了处于这种状态的实例的行为,取值,以及约束。在某些情况下,某些属性,关联,或者操作仅适用于处于特定的一种或几种状态的实例。还有些情况中,某个操作的参量必须是特定状态下的对象。通常情况下,上述特殊情况只是行为模型的一个部分。但是有时,最好在交互视图或者静态视图中将它们直接标明。
状态类仍然是类,只是带有类的对象可能拥有的合法状态。如果该类有并发的子状态,那么状态说明将列出一系列该类的对象可能同时存在的几种状态。状态类可以被当作一种类元。它的行为类似所描述类的一个子类。它可以被当作变量类或参数类使用。它可以参加那些只适用于所给定状态的对象的关联。在图13-46中,请看SubmittedPaper与ConferenceSession之间的Assignment关联。这种关联仅在SubmittedPaper处于accepted状态时才适用(目标多重性为1),而在rejected状态时则不存在。对于SubmittedPaper而言,目标多重性为0或1,因为类中同时含有accepted和rejected的报告。然而在对处于accepted状态下的SubmittedPaper和ConferenceSession间的关联建模时,那么其目标多重性就是1。

图13-46 状态类
在表示活动图中操作的输入输出值时,状态类元素也是有用的。
表示法
状态类用类符号表示,在类名后,跟着在方括号内的状态名(类名[状态名])。方括号中也可以是用逗号分开的几个并发状态名,表示对象可以是这些状态中的几种。
讨论
状态类和动态类元是为了实现允许对象在其生命周期内改变结构而采用的两种不同方法。根据实现环境的不同,其中之一可能更方便适用。
61.类名(class name)
每个类都必须有一个非空的类名,这在类的外壳(例如包或者包含类)内对于类元而言是唯一的。名字的作用域是类的外壳包,或者可以看到该包的其他包。
见名字,以得到关于命名以及唯一性规则的完整说明。
表示法
类名在表示类的矩形内顶部里表示。名字分格中可能还有关键字或者构造型名,和/或构造类型图标,以及用花括号括住的一系列标签值。(见图13-47)。
处于书名号内可选的构造类型关键字可置于类名字的上方,和/或在分格的右上角表示构造类型的图标。构造型名不得与预定义的关键字重复,例如enumeration。

图13-47 名字分格

图13-48 在其他包中的类的路径名
接下来表示类的名字,类名用粗体字在分格的水平正中标出。如果此类为抽象类,类名就用斜体表示。注意,任何明确的泛化状态的说明(例如抽象或者具体),其字体应大于类名所用的字。
在类名下,可以在方括号中列出标识特性的字符串表(元模型的属性或者特性值)。此列表可以表示那些在UML中没有符号表示的类级属性,还可以表示特征值。可以用某些无值的关键字来表示某种属性与值的联合体。例如,一个leaf类表示属性为{leaf},与{isLeaf=true} 作用相同。
没有特别说明,假定表示在某个包内的类是时在此包内定义的。要引用在其他包中定义的类,作为名字分格中的名字字符串使用的语法为(图13-48)
Package-name::Class-name
用符号(::)将包的名字与类名分开,从而提供完整的路径名。如果路径名可以区分它们,在不同包内的不同的类中可以使用相同的类名。但是这种情况容易造成错误,应该尽量避免。
在文本的描述中,也会引用类,尤其是在属性和变量的类型说明中。在文本
描述中,引用一个类只要使用它的名字,包括可能包的名字,这服从于表达式的语法规则。
62.类元(classifier)
类元是一种描述行为和结构特征的模型元素。类元的种类包括类、行为、构件、数据类型、接口、节点、信号、子系统以及用例。类是最常见的类元。虽然每种类元都有各自的元模型为代表,但是它们都可以按照类的概念来理解,只是在内容和使用上有某些特殊限制。类的大多数特性都适用于类元,通常只是为每种类元而增加了某些特殊限制条件。
见泛化元素(generalizable element)、静态视图(static view)。
标准元素
枚举(enmeration)、位置(location)、元类(metaclass)、持久性(persistence)、强类型(powertype)、进程(process)、语义(semantics)、构造型(stereotype)、线程(thread)、效用(utility)。
63.类元角色(classifier role)
这是在合作中的一个片段,用于描述各个参与者在合作中的角色。
见合作(collaboration)。
语义
合作说明了在一系列参与者之间的交互方式,它是类或者数据类型的实例。类元角色是对一个参与者的描述。每个角色处在自己独特的上下文中,是类元的一个独特使用。一个类元可能有多个角色,每个角色在一个合作中与其他角色有着不同的关系。一个角色不是独立的对象,而是某个可能参与合作实例的所有对象的描述。每当这个合作实例化时,就有不同的对象与链来扮演这些角色。
每个类元角色有其类元(其基础)的引用以及多重性。基础类元限制了可以充当角色的对象种类。对象所属的类可以与该基础类元的类相同,或是其子类。多重性说明在合作的一个实例中,同一时刻有多少个对象来充当这种角色。
类元角色可以有名字,也可以匿名。当需要多重类元时,类元角色可以有多个基础类元。
类元角色可以通过关联角色与其他类元角色相连接。
对象。一个合作代表了为了完成某个目标而共同工作的一组对象。角色表示一个对象(或一组对象)在完成目标的过程中所应起的那部分作用。一个对象是角色所属的基类直接或者间接的实例。在合作中,不需要基类所有的对象都出现,同一个基类的对象在一个合作中也可能要充当多个角色。
在不同的合作中,同一个对象可以充当不同角色。合作代表了对象的一个方面。单独的一个物理对象可能包括多个方面,因此隐含了该对象与其起作用的合作间的联系。

图13-49 类元角色
表示法
类元角色是用类元的符号(矩形)表示,符号中带有用冒号分格开的角色名和类元名字,即:角色名:基类。一个角色不是独立的对象,而是一个用于描述不同类元实例中出现的多个对象的类元。
角色名和类元的名字都可以省略,但是分号必须保留,从而与普通的类相区别。在一个合作中,由于所有的参与者都是角色,因而不易混淆。
类元角色可能会表示类元特征的一个子集,即在给定的上下文中的属性和操作。其余未被用到的特征将可以被隐藏。
图13-49表示了类元角色不同的表示法。
标准元素
被销毁的(destroed)、新建(create)、暂时(transient)。
64.客户(client)
是指一个需要其他元素提供服务的元素。它用于描述在依赖关系中的角色。在表示时,
客户出现在依赖关系箭头的尾部。反义词:提供者。
见依赖(dependency)
65.合作(collaboration)
是对对象和链总体安排的一个描述,这些对象和链在上下文中通过互操作完成一个行为,例如一个用例或者操作。合作由静态部分和动态部分组成。静态部分描述在合作实例中对象和链可能承担的角色。动态部分包括一个或多个动态交互,表示在执行计算过程中不同时间里合作中消息流。
见关联角色(association role)、类元角色(classifier role)、交互(interaction)、消息(message)。
语义
一组对象在给定的上下文范围内,为了完成某个目标而交换消息,从而实现了一种行为。要理解设计机制,应该重点着眼于实现一个或一组相关目标时涉及的对象和消息,
它们在一个更大的系统中也完成其他目标。使对象和链共同工作以实现某种目标而进行的安排称为合作;在合作中实现行为的消息序列称为交互。合作是对"对象的组织"的一种描述。它是大型复杂模型中的一个片段,在模型中合作是为了实现一个目标。
例如,商业销售代表了对于一些对象的一种安排,这些对象在事务处理中有着特定的相互关系。在事务处理范围之外,这种相互关系就没有意义了。销售的参与者包括销售者,购买者和代理人。为了实现某个特殊的交互,例如出售房屋,参与者们交换特定消息序列,例如报价或者签订合同。
在合作中流动的消息流,可以选用状态机来进行描述,状态机将规定合法的行为顺序。状态机中的事件代表了合作中各角色间的消息交换。
合作由角色组成。角色是指在合作中起作用的类元或者关联的一部分。实例化时,角色可以带有类元或者关联的实例。同一个类元或关联可以承担不同的角色;每个角色有不同的对象和链。例如,在商业事务处理中,两个公司中一方可能是销售者,另一方为购买者。seller和buyer是合作关系Sale中Company类所承当的角色。角色只在合作中才有意义;在合作之外就无意义了。实际上,在其他合作关系中,角色可能会对调。某个对象在一个合作实例中可能是seller,而在另一个中就是buyer。同一个对象可能在不同的合作中承担多种角色。这与角色在关联限定的作用域不同。无论对象是否参与了关联,关联所描述的关系对于一个类在所有的上下文中有全局性的意义。合作所描述的关系局限于特定的上下文中,在此范围之外,关系就没有意义了。
实现。合作实现了某个操作或者用例。它描述了该操作或者用例的执行实现所处的上下文--- 即,开始执行时,对于存在的对象和链的安排,以及在执行过程中生成的和销毁的实例。交互中的行为序列的说明可以用顺序图或者合作图表示。
合作也可完成类的实现。类的合作是类操作的合作的联合。为同一个类,系统,子系统可以设计不同的合作;每个合作表示了与实体的一个视图相关的属性,操作和相关对象的一个子集,(例如某个特定操作的实现)
模式。参数化的合作代表了一种可以在不同的设计中重用的设计结构。通常基本类元是参数。这种参数化的合作符合模式结构。
见模板(template)
通过给基础类元参数提供具体的类元,可以得到设计模式的实例。每个实例产生模型中特定的类元集上的一个合作。一个模式可与模型中的不同类元集多次绑定,从而避免为每次出现定义新的合作。例如,一个模型视图模式定义了模型元素间的常规关系,它可与代表模型视图对的多个模型视图类对进行绑定。每个实际模型视图类代表了对模式一次绑定。这些类对中的某对可能是房屋和房屋里的图像,另一对可能是股票和表示股票当前价格的图形。
请注意,一个模式还包括使用指导,以及对与其优缺点的明确描述。这些内容可
以作为注释,或写在单独的文本文件中。
合作的层次 合作可以在不同的粒度水平(granularity)上表示。一个粗粒度的合作可以通过进一步细化成为另一个粒度更细的合作。这是通过扩展一个或者多个操作来实现由高层次的合作到低层次的合作的细化。
合作还可以通过下级合作来实现。每个下级合作实现整个功能中的一个部分,并有其独立的角色集。整体合作中的每个角色可以与嵌套部分中的一个或者多个角色绑定。如果一个外层角色被绑定为多个内层角色,则其隐含了与低层合作的连接。这是用例之间交互作用的唯一方式。一个设计思路是从内层向外的。首先构造内层,限定角色,而后将它们结合生成外层,拓宽角色使其拥有多重责任。
运行时绑定 。在运行时,对象和链与合作中的角色绑定。通常在不同的合作中,一个对象可以绑定到一个或 者多个角色上。如果一个对象绑定到多重角色,那么它代表了角色之间的一种"偶然"交互关系--即,这种交互不是由角色本身固有的,而只是它们在更广的上下文中使用时的一种副作用。通常一个对象在组成大型合作的多个协
作中承担角色。这种合作的重叠提供了一种隐含的,合作间的控制和信息流动。

结构
角色。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10752019/viewspace-975910/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
  • 博文量
    3984
  • 访问量
    7363160