UML参考手册 第三部分  参 考 资 料 第13章 术 语 大 全 <八>

UML参考手册  

  第三部分  参 考 资 料  

第13章 术 语 大 全

251.许可(permission)
许可是一种依赖关系,它授权客户元素可以使用供给元素的内容(受到内容元素的可见性声明的影响)。
语义
许可依赖关系的原型是访问(Access)、友元(Friend)和导入(Import)。没有原型的单纯的许可依赖关系不存在的。访问和导入依赖关系用在包里,而友元依赖关系则被用于类或者操作。
表示法
许可依赖关系显示为一条虚箭头。箭头方向从客户端(获得许可的元素)到提供者(给予许可的元素),箭头上标注有关键字。
标准元素
友元,导入
252.持续对象(Persistent Object)
持续对象就是在产生它的线程停止存在后继续存在的对象。
253.多态性(polymorphic)
多态是指一种操作的实现(方法或者被调用事件所触发的状态机)可能由它的的子类来提供。非多态性的操作是一个叶操作(leaf operation )。
见 抽象操作(Abstract operation)、泛化(generalization)、继承(inheritance)、方法(method)。
语义
如果操作是多态的,那在它的子类里可能会为它提供一种方法(不论在原来的类里是否已经提供了方法)。否则的话,在声明该操作的类里必须为该操作实现一个方法,并且该方法不能在子类里被重载。一个方法如果已经声明或者从祖先那里继承来,那它就是可以使用的。抽象操作必须是多态的 (因为它没有直接的实现)。如果一种操作被声明为叶操作,那它就是非多态的。
如果一种操作在类中被声明为多态的 --也就是说,没有被声明为叶操作--那它可能在子类里被声明为叶操作。这就可以阻止该操作在更下面的子类里被重载。叶操作不可以在它的子类里被声明为多态的。它也不可以被重载。
如果一个方法在一个类里声明了并且在它的子类里进行了重载,UML并没有指定方法结合的规则(参看下面的讨论)。 可以通过使用有标识的值以语言说明的方式来处理机制,比如在方法 的前面,后面或中间声明。在任何情况下,动作--如显式调用继承来的方法--当然依赖于动作语言。
表示法
非多态的操作是通过关键字{leaf}来声明的。否则的话,操作就被认为是多态的。
讨论
抽象操作必须是多态的 。否则,它根本就不能被实现。Bertrand Meyer 把这称为滞后操作(a deferrd operation ),因为它的定义是在一个类里,而它的实现却在它的子类里。这是继承在建模和编程方面一个重要,可能是最重要的应用。使用继承,操作就可以应用于不同类的对象。调用者不需要知道各个对象所属的类。唯一的要求就是所有的这些对象都继承自定义该操作的祖先。而祖先类不需要实现该操作。只需要定义它们的识别标志。调用者甚至不需要知道可能子类的列表。这意味着新的子类可以在以后加近来而不影响它的多态性操作。当新类加入时,调用操作的源代码不需要修改。在初始代码写完之后再加入新类的能力是面向对象技术的重要基础之一。
多态机制的一个更有争议的使用就是用子类里定义一个不同的方法来替换类里已经定义的方法。这经常被当作一种共享形式而被引用,但这是非常危险的。重载不是增加性的,所以原始方法里的一切都必须复制到子方法里,即使只是做一个很小的变化。这种重复是有可能出错的。特别的说,如果原始方法在以后有了改动,并不能保证子方法也被改动。有时子类使用一个完全不同的操作实现,但是很多专家不鼓励这种重载因为它有潜在的危险。通常来讲,方法应该没有重载的完全继承或者滞后实现;在后者的情况下,父类里没有实现,所以就不存在荣誉或者不一致的危险。
为了使子类能够扩展操作的实现而不失去继承的方法,大多数编程语言提供某种形式的方法合并(method combination),既使用继承的方法但同时也允许加入另外的代码。在C++里,继承的方法必须显式的通过类名和操作名来调用,它把类的继承机制严格的建立在代码之上,所以并不是完全的面向对象的方法。在Smalltalk里,方法可以用 Super 来调用操作,使继承来的方法处理这个操作。如果类的层次关系发生了变化,那继承仍然有效,只是可能这时使用的是另一个类的方法。但是,重载方法必须显式的提供对 Super 的调用。错误可能会发生,而且确实在发生,因为编程人员会忘记有改动的时候插入调用。最后,CLOS提供了非常普通和负责的自动方法合并的规则(automatic method combination rules),在一个操作的执行过程里可能会调用几个不同的方法。整个的操作由几个段共同实现而不是被强制成为一个单一的方法。这是非常普通的但是对使用者来说更难于控制。
UML没有强制只使用一种实现方法合并的办法。方法合并是一个语义变体点(semantic variant point。任何实现办法都可以使用。如果编程语言在方法合并方面比较差,那建模工具可以在生成合适的编程语言代码方面提供帮助,也可以在使用了重载方法而没有发现的情况下发出警告。
254.后置条件(Postcondition)
后置条件就是在操作完成时必须为真的约束(constraint)。
语义
后置条件就是一个在操作执行完成时必须为真的布尔表达式。它是一个断言,不是可执行语句。有时可以提前自动检验后置条件,这要取决于表达式的确切形式。操作完成之后检查后条件可能有用,但是这是调试程序的本质。条件应该是真,任何其他情况都是编程错误。一个后置条件就是作用在操作实现上的一个限制。如果它不被满足,那操作的实现就是被错误的。
见 不变式(invariant)、前置条件(precondition)
结构
后置条件被模型化为一个带有原形<postcondition>的约束,附加到操作上。
表示法
后置条件可以被显示在带有关键子 Postcondition 的说明里。该说明附加在受影响的操作上。
举例
图13-145显示了作用在数组排序的操作上的后置条件。数组(a')的新值与初始值(a)有关联。这个例子以结构化的自然语言表示。以更为正式的语言来声明也是可能的。

图13-145 后置条件
255.强类型(Powertype)
强类型就是其实例是给定类的子类的元类(meatclass)。
见 元类(metaclass)
语义
给定类的子类本身可以被看作元类的实例。这样的元类就被称为强类型。例如,类 Tree 可能有子类 Oak, Elm和Willow。当作对象来看,这些子类就是元类TreeSpecies的实例。TreeSpecies就是Tree范围里的强类型。
表示法
强类型被显示为带有原型<powertype>的类。通过标有原型<powertype>的虚箭头,它被连接到一个泛化路径的集合上去(图13-146)。

图13-146
256.前置条件(precondition)
前置条件是在一个操作被调用时必须为真的约束。
语义
前置条件是一个在操作被调用完成时必须为真的布尔表达式。满足这个表达式是调用者的责任。接收者不用去检查它。前置条件不是可执行语句而是断言;它必须为真,它不是执行操作的方式。为保证可靠性,在操作开始时检查前置条件可能有用,但是这是调试程序本身的性质。条件应该是真,任何其他情况都是编程错误。如果这个条件不被满足,那关于操作或系统的统一性不能做任何评价。它可以可靠的发现错误。实际上,接收者显式的检查前置条件可以发现许多错误。
见 不变式(invariant)、后置条件(postcondition)。
结构
后置条件被模型化为一个带有原形<postcondition>的约束,附加到操作上。
表示法
后置条件可以被显示在带有关键子 Postcondition 的说明里。该说明附加在受影响的操作上。
举例
图13-147显示了作用在矩阵乘法操作上的前置条件。

图13-147
257.表示元素(presentation element)
表示元素就是一个或多个建模元素的文本或图形方式的投影。
见 图(diagram)
语义
表示元素(有时也被称为视元素,尽管它们也包含非图形方式的表示)表示了一个模型中为人感知的信息。它们是表示法。它们显示了部分或者全部的关于一个模型元素的语义信息。它们也有可能加入对人有益的美学信息,例如,把概念上相互联系的元素归为一组。但是所加入的信息没有语义内容。人们希望表示元素应该作到在低层的模型元素发生变动时能够保持自身的正确。这样,模型元素不用为保证操作正确而担心表示元素。
该书中,UML 表示法的描述定义了从模型元素到屏幕上的图形表示的映射。表示元素作为对象的实现是工具实现的责任。
258.简单类型(primitive type)
简单类型就是一个事先定义好了的基本数据类型,比如整数或者字符串。
见 枚举(enumeration)
语义
简单类型的实例是没有标记。如果两个实例具有相同的表示法,那它们是无法区分的,可以通过值来传递而不会丢失任何信息。
简单类型包括数字和字符串,也可能是别的系统所依赖的数据类型,例如,日期和货币,它们的语义在UML以外已经事先定义好。
人们希望简单类型能够和编程语言里的类型紧密对应。
见 枚举(enumeration),它是用户自定义的数据类型而不是事先定义的简单类型。
259.私有性(private)
私有性是一个可见性值,它表明给定元素在它的名称空间以外是不可见的,即使是对该名称空间的后代也是不可见的。
260.私有继承(private inheritance)
私有继承是一种结构的继承,这种继承没有继承行为声明。
见 实现继承(implementation inheritance)、接口继承(enterface inheritance)、可替代性规则(substitutability)
语义
泛化(generalization)可能具有原型《implementation》.这就表明客户元素(通常是一个类)继承了提供者元素的结构(属性,关联和操作),但是没有必要使它自己的客户元素也能使用该结构。因为这样一个类(或者别的元素)的祖先对别的类是不可见的,这个类的实例不能作为变量使用,也不能作为提供者的类的参数使用。也就是说,类不能替代它私有继承的提供者。私有继承是不遵守替代性规则的。
表示法
在泛化箭头上标注关键字 Implementation 来表示私有继承,其中的箭头方向应该从继承元素(客户)到提供被继承结构的元素(提供者)。
讨论
私有继承只是一种实现,它不应该被认为是对泛化的一种应用。泛化要求可替代性。在不包含实现结构的分析模型里,私有继承不是非常有意义。即使对于实现,因为私有继承包含了对继承的非语义性质的应用,所以,对私有继承的使用也应该多加小心。通常,更为明智的替代方式就是使用与提供者类之间的关联。许多作者认为私有继承根本就不能使用,因为它以非语义方式使用继承,而这种方式在模型发生变动时是非常危险的。
261.过程表达式(procedure expression)
过程表达式就是其计算代表了一个过程的执行的表达式,而这个过程会影响到正在运行的系统的状态。
语义
过程表达式是一个可执行算法的编码。它的执行可能(实际上经常是)影响系统的状态--也就是说,他的执行具有副作用。通常,过程表达式并不返回值。它的执行目的就是改变系统的状态。
262.进程(Process)
1. 操作系统里的一个重量级(heavyweight)的并发和执行的单元。 参看 线程;线程包括重量进程和轻量进程。如果需要,可以通过使用构造型产生实现上的区别。
2. 一个软件开发过程--开发一个系统的步骤和指导。
3. 执行一个算法或者是动态处理一些事情。
263.产品(product)
产品就是开发的制品,比如 模型、代码、文档、工作计划。
264.投影(projection)
投影就是从一个集合到该集合的子集的映射。大多数的模型和图都是从可能得到的所有信息的集合上产生的投影。
265.特性(Property)
特性就是表示传递有关模型元素信息的值的一般性术语。属性具有语义效果。在UML中一部分属性已经事先定义好了;其他的特性是用户定义的。
见属性(attribute)、关系(relation)、带标签的值(tagged value)
语义
特性不但具有有带标签的值(用户定义的)和附加在元素上的关系(用户定义的),而且具有内建的标志(由UML定义的)。从一个用户的观点来看,属性是内嵌的还是作为带标签的值由用户实现的,这一点往往并不重要。
讨论
应该注意到我们是在非常普遍的意义上使用特性的,代表附加在元素上的任何可能值,包括属性(attribute),关联和带标签的值。在这种意义上,特性可能包括可以在一个给定元素开始找到的间接得到的值
266.特性列表(property list)

特性列表就是一个文本语法,其目的是显示附加到元素上的特性或特性组成,特别是带标签的值,还包括模型元素的内建的特性。
表示法
包含在括弧内的一个或者多个由逗号分隔的特性声明。每个特性声明具有下面的形式:
特性名 = 值

特性直接量
这里的特性直接量是一个唯一的枚举值,它的出现代表了一个唯一的特性名称。
举例
{abstract , author = Joe , visibility = private }
表示可选项
如果特性声明经过合适的标注后能够和其他的信息区分开来,有的工具可能就会在单独的行上表示特性声明,带有括弧或者不待括弧。例如,类的特性可以以一种不同的显示方式,例如斜体或者不同的字体,列在类的名字下面。这是工具的问题。
注意:特性串可能用于表示内嵌属性和代标签的值,但这种使用在规范形式简单时应避免。
267.受保护性(Protected)
受保护性是一个可见性值,它表示给定的元素在它自己的名称空间外只对它的后代的名称空间可见。
268.伪属性(Pseudoattribute)
与行为类似于属性的类相联系的值;也就是说,它的每个实例都有唯一的值。
见 鉴别器(discriminator)、角色名(rolename)
语义
伪属性 包含关联角色名称和泛化鉴别器。关联角色名称是在类里关联的另一端的伪属性。泛化鉴别器是在父元素里的伪属性。在每个子元素里,鉴别器的值就是子元素的名字。
伪属性可以被作为一个名字用在表达式里以便从对象里取得一个值。因为属性名称和伪属性名称都可以用在表达式里,它们处在相同的名称空间里所以必须在这个名称空间里保证唯一。对于继承来的属性,它们的名称也必须和伪属性名称保证唯一。
269.伪状态(pseudostate)
伪状态是在一个状态机中具有状态的形式而其行为却不同于完整状态的顶点。
参看 历史状态(history state)、初始状态(initial state)、连接状态(junction state)、桩状态(stub state)
语义
当一个伪状态处于活动的时候,状态机还没有完成它的运行到达结束,也不会处理事件。伪状态包括初始状态,连接状态,桩状态,历史状态。伪状态用来连接转换段,到一个伪状态的转换意味着会有一个到另一个状态的自动转换而不需要事件触发。
终结状态和同步状态不是伪状态。它们是特殊的状态,可以在状态机完成运行到达结束时仍然保持活动,但是从它们出发的转换存在限制。
270.公有(Public)
公有是表示给定元素在它的名称空间以外仍然可见的属性值。
271.限定词(qualifier)
限定词就是二进制关联上的属性或者属性组成的列表的插槽(slot),而在这个关联中,属性的值从整个对象集合里选择一个唯一的关联对象或者关联对象的集合。限定词是一个关联的遍历索引。
见 关联类(association class)、关联末端(association end)
语义
一个二进制关联把一个对象映射到一个关联对象的集合上。有时通过提供一个能够区分集合里其他对象的值,就可以把一个对象从集合里选取出来。这个值可以是目标类的一个属性。但是,通常来说,这个值可能是关联本身的一部分,即一个其值是在增加新的连接到关联类的时候有产生者提供的关联属性。这样一个在二进制关联上的属性就叫做限定词。一个对象连同一个限定值决定一个唯一的关联对象或者对象的子集(有点少见)。该值限定了关联。在一个实现语境中,这样的属性被叫做索引值。
限定词被用来从有关联联系到一个对象(被叫做 被限定对象)上的对象集合中选择一个或者多个对象(图13-148)。被限定值选中的对象称为目标对象。限定词总是作用于存在很多目标方向的关联。在最简单的情况下,每个限定词只从目标关联对象集合中选择一个对象。也就是说,一个被限定对象和一个限定值产生一个唯一的关联对象。给定一个被限定对象,每个限定值映射到一个唯一的目标对象。
很多种类的名称都是限定词。在一定的语境中这样的一个名称映射成一个唯一的值。被限定对象提供语境,限定词是名字,而目标对象就是结果。任何ID或者别的唯一代码都是限定词;目的是为了唯一的选定一个值。数组可以被设计成一个被限制的关联。数组是被限定对象,数组下标就是限定词,而数组元素就是目标对象。对于一个数组,限定词的类型是整数范围。
限定词可以被用在一个导航表达式里以选择通过关联联系的对象的一个子集--也就是说,那些具有限定词属性值或者值的列表的关联。限定词在通过关联联系的对象的集合中充当选择器。在大多数情况下,限定词的目的是为了从相联系的对象结合中选择出一唯一的对象,这样一个被限定关联行为就象是一个查询表。
结构
限定词。 一个限定词属性是二进制关联末端的一个可选部分。限定词限定了附加在关联上的类。一个类的对象和一个限定值从二进制关联的另一端的类中选择一个对象或者对象的集合。二进制关联的两端都有限定词是可能的,但是这种情况是很少见的。
限定词是一个关联属性或者属性的列表。每个属性具有一个名字和一个类型但是没有初始值,因为限定词不是独立的对象,当向关联中增加连接时,每个限定值都必须显式声明。
限定词不能用在n元关联中。
多重性。 被限定关系的多重性被放在二进制关联限定词的相对的一端(应该记住被限定的类和限定词一同形成一个和目标类相联系的复合值)。也就是说,限定词附加在关联的近端(neat end),而多重性和角色名称附加在远端(far end)。附加在目标关联末端的多重性表示通过一个组成(源对象,限定值)可以选择多少个对象。普通的多重性值包括0..1(可以选择一个唯一的值 ,但是每个可能的限定值不一定选择一个值),1(每个可能的限定值选择一个唯一的目标对象,所以限定值的取值域必须是有限的。),和*(限定值是把目标对象划分为各个部分的索引)。
在大多数情况下,是0或者1。这种选择意味者一个对象和一个限定词最多可能产生一个关联对象。为1的多重性意味者每个可能的限定值恰好产生一个对象。者显然要求限定词的取值域必须是有限的(至少在计算机实现范围内)。多重性在映射有限的枚举类型方面是有用的--例如,由PrimaryColor (是red, green和blue 的枚举)限定的 Pixel 可以为图象中的每个点产生由 red-green- blue 值组成的三位字节。
未限定关联的多重性没有显示说明。但一般假定它们的多重性是很多,至少是多于一个。否则,就没有需要限定词。
被限定关联上的方向很多的多重性没有很重要的语义影响,因为限定词没有减少目标集合的多重性。这样的多重性代表了一个设计要求:必须提供

阅读终点,创作起航,您可以撰写心得或摘录文章要点写篇博文。去创作
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
UML参考手册是一本提供了UML(统一建模言)的详细介绍和使用指南的PDF文件。它通常包含了UML的各种图形符号、概念、以及详细的用法说明。这本手册对于学习和使用UML的人来说是非常有价值的。 首先,UML参考手册可以帮助用户理解UML的核心概念和原则。它提供了UML的基本思想和理论基础,让读者能够准确地理解UML义和法。通过学习手册中的内容,读者可以快速掌握UML的核心概念,例如类、对象、关联和继承等,并能够将其应用于实际的软件开发项目中。 其次,UML参考手册还介绍了UML的各种图形符号和画法。UML包含了多种图表类型,如类图、序列图、状态图等,每种图表都有其特定的图形符号和用法。参考手册通过清晰的图例和实例,详细说明了每种图表的使用方法和约定。读者可以通过手册中的示例快速了解和掌握各种UML图表的绘制技巧,从而能够准确地表示和传达自己的设计意图。 此外,UML参考手册还提供了关于UML工具和方法的建议和推荐。随着UML的广泛应用,出现了很多UML工具和方法,如Rational Rose、Enterprise Architect等。参考手册通过对这些工具和方法的介绍和比较,帮助读者选择适合自己的工具,并提供了使用这些工具的指导和建议。这对于使用UML工具进行软件开发和项目管理的读者来说尤为重要。 总而言之,UML参考手册是学习和应用UML的重要工具。它提供了UML的核心概念、图形符号和使用方法的详细说明,帮助读者快速理解和掌握UML。对于软件开发人员和项目管理人员来说,掌握UML参考手册是提高工作效率和质量的必备技能。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

CandyCat

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值