软件模型设计基础(7)
- 格式：doc
- 大小：38.50 KB
- 文档页数：3
软件模型设计基础（7）
1. 4注释事物
1.4. 1注解(note)
附加定义性告诉被注解对象的性质、特征、用途等。
如果这样理解注解似乎是可以的，但描述性字符太少，免不了心里不塌实，但如何理解注解呢？就是说明性的文字。
说明什么，什么都可以被说明，只要是这个世界上存在的事物就可以被说明。
但在UML的定义中，这些描述性的文字常常被隐藏起来，并不直接地表示成为注解（事物），作者本人也是如此认为，注解最好的表述方式是隐性。
作为被描述的事物本身由于没有直观的表述注解，其脉络是清晰的。
其实这个东西不用来解释，我记得张五常先生的《经济解释》中首先提及的套套逻辑即是如此，因为我们采用的注解的方式来注?quot;注解"这个词。
1.5关系事物
关系是UML中最难表示的一"件"东西（我自己认为，但不知道专家们如何看），难在那里，它就是从系统分析到系统构架的关键。
关于关系我会在下一章详细地说明，其实软件开发仔细想就是我们对现实事物的描述，而这个描述就是关系，其现实事物就是对象(Object)。
以下说明UML中几个典型的关系。
1.5. 1依赖(dependency)
一个元素(被依赖事物的提供者)的变化将影响到另一个元素(依赖事物的接收者)，或向其(接收者)提供信息。
关于依赖的语义，我举个简单的例子，一个小孩（依赖事物）是没有获取食物的能力的行为，他的生存就是依赖于他的父母（被依赖事物）对他的抚养（依赖方式）。
故依赖被这样定义：一个事物为了达到某个目的，而采用一种依赖方式依赖于被依赖事物。
依赖的形式可能是多样的，这样我们就用依赖关系来表述它，针对不同的依赖的形式，依赖关系有不同的变体
(varieties)：
<1>抽象(abstraction)：从一个对象中提取一些特性，并用类方法表示。
<2>绑定(binding)：为模板参数指定值，以定义一个新的模板元素。
<3>组合(combination)：对不同类或包进行性质相似融合。
<4>许可(permission)：允许另一个对象对本对象的访问。
<5>使用(usage)：声明使用一个模型元素需要用到已存在的另一个模型元素，这样才能正确实现使用者的功能(包括调用、实例化、参数、发送)。
<6>跟踪(trace)：声明不同模型中元素的之间的存在一些连接。
<7>访问或连接(access)：允许一个包访问另一个包的内容。
<8>调用(call)：声明一个类调用其他类的操作的方法。
<9>导出(derive)：声明一个实例可从另一个实例导出。
<10>友员(friend)：允许一个元素访问另一个元素，不管被访问的元素的具有可见性。
<11>引入(import)：允许一个包访问另一个包的内容并被访问组成部分增加别名。
<12>实例(instantitate)：关于一个类的方法创建了另一个类的实例声明。
<13>参数(parameter)：一个操作和它参数之间的关系。
<14>实现(realize)：说明和其实之间的关系。
<15>精化(refine)：声明具有两个不同语义层次上的元素之间的映射。
<16>发送(send)：信号发送者和信号接收者之间的关系。
UML本身没有提供如此之多的定义，作者根据自身对UML的认识，添加一些，这些东西会在下一章中详细描述。
1.5.2关联(association)
关联是两个或多个特定类之间的关系，它描述了这些类元的实例的联系。
参与其中的类元在关联内的位置有序。
在一个关联中同一个类可以出现在多个位置上，关联的每一个实例链是引用对象的有序表，关联的外延即这种链的一个集合。
在链集合中给定对象可以出现多次，或者在关联的定义允许的情况下可以在同一链中（不同的位置）出现多次。
关联将一个组织在一起。
如果没有关联，那只是一个无连接类集合。
关联可以有一个名称，但是它的大部分描述建立在关联端点中，每个端点描述了关联中类对象的参与。
关联端点只是关联描述的一部分，不是可区分的语义或可用符号表示的概念。
关联名称在包含包的所有关联和类中它必须是唯一的。
若名称不唯一，关联的端点并不明确。
关联的端点定义在关联位置中给定位置的一个类（角色的参与）。
同一个类可以出现在出现在多个位置，但位置是不可以交换的，这个位置的关系就是关联?quot;关系"。
当然位置的端点也可以是其他情况下的类元。
在UML 的语义中，位置的关系（类元的关联）称为链。
链在系统执行过程中可以被创建和销毁，服从每个关联端点可变性的限制（类元本身的对应或所属关系）。
以下的关联图是两个参数类，简单的关联就是羊毛的加工是由操作者来实现的，一个操作者可以加工很多羊毛，而羊毛在一个步骤仅仅需要一个加工者（不考虑多个步骤）。
1.5. 3泛化(Generalization)
泛化是什么？是一个较广泛的元素和一个较特殊元素之间的类元关系。
较特殊的元素完整地包含了较广泛元素，并含有更多的信息。
较特殊的元素的实例可以用于任何使用较广泛的元素的地方。
泛化是两个同类的可泛化元素（如类、包或其他元素）之间的关系，其中一个元素被称为父，另一个为子。
对类而言，父类称为超类，子类称为子类。
父类说明的直接实例带有所有子类的共同特性，子所说明的实例是上述实例的对象。
在类（这里指的是C++或JA V A中面向对象编程中类）的继承中，泛化的概念被广泛地应用，其实所谓的泛化就是将特殊的事物抽象出来，主要是面对这些事物的特征，将这些特
征和与之相关的事物进行比较，将其共同的特征抽取出来，进行归纳，所得到的结果就是我们需要表现出的该事物的泛化特性。
在类的实例中，最常见的一个例子就是图形的问题，如描述三角形，或描述正方形，或椭圆等，这些都是图形，好了我从三角形、正方形、椭圆等中抽取该部分的共同特征，将其描述，这个就得到一个图形（从三角形泛化出的结果）描述。
学习JA VA或C++的兄弟们一看便知，问题的关键就是基类和继承类的关系。
但关于参数类的泛化成一般的类（这个关系比较模糊），我们将在下一章的关系中进行更详细的描述。
1.5.4实现(Implementation)
1．定义某事物是如何构造的、计算的。
例如，类是类型的实现，方法是操作的实现。
实现和说明之间是实现关系。
2．用可执行的媒体（如程序设计语言、数据库、数字化硬件）描述系统功能的一个步骤。
对实现而言，必须产生下层的决策以使设计适合具体的实现，并与环境相适应（每种语言有各自的限制）。
如果设计得好、实现任何决策不会影响系统的全局。
这一步由实现层模型捕捉。
特别是静态视图和代码。
实现是一种关系，是一种将模型元素（如类）与另一种模型元素（如接口）连接起来，其中接口只是行为的说明而不是结构或者实现。
客户必须至少支持提供者的所有操作（通过继承或者直接声明）。
虽然实现关系意味着有像接口这样的说明元素，它也可以用一个具体的实现元素来暗示它的说明（而不是它的实现）必须被支持。
例如，这可以用来表示类的一个优化形式和一个简单低效的形式关系。
泛化和实现关系都可以将一般描述与具体的描述联系起来。
泛化将在同一个语义层内的元素连接起来，而且在同一模型内。
实现关系将在不同的语义层内元素连接起来，（接口或类）并且通常建立在不同的模型内。
