下载文档原格式
9.1 名词解释（1）OODBS：是指面向对象数据库系统，它既具数据库管理的基本功能，又能支持面向对象的数据模型。
（2）ORDBS：基于对象关系数据模型的DBS称为对象关系数据库系统（ORDBS）。
（3）平面关系模型：传统的关系模型称为“平面关系模型”，它要求关系模式具有第一范式(1NF)性质，关系具有规范化的结构。
也就是规定属性值是不可分解的，即不允许属性值具有复合结构(元组或关系)。
（4）嵌套关系模型：是从平面关系模型发展而成的。
它允许关系的属性值又可以是一个关系，而且可以出现多次嵌套。
嵌套关系突破了1NF的定义框架，是“非1NF关系”。
（5）复合对象模型：在嵌套关系模型上进一步放宽要求。
在关系定义上，集合与元组不再有交替出现的严格限制，此时的关系中，属性类型可以是基本数据类型、结构类型(元组类型)或集体类型(即关系类型)。
（6）数据的泛化/细化：是对概念之间联系进行抽象的一种方法。
当在较低层上的抽象表达了与之联系的较高层上抽象的特殊情况时，就称较高层上抽象是较低层上抽象的"泛化"，而较低层上抽象是较高层上抽象的"细化"。
（7）对象关系模型：在传统关系数据基础上，提供元组、数组、集合等更为丰富的数据类型及处理新数据类型操作的能力而形成的数据模型。
(注：传统关系模型只支持字符、数值、字串，布尔值等等基本数据类型及其处理功能)（8）类型级继承性：当继承性发生在类型级时，子类型继承了超类型的属性。
也就是说，超类型所具有的属性，在子类上也具有。
（9）表级继承性：继承性也可发生在表级，(就是元组集合上发生继承)，子表继承超表全部属性，超表中每个元组最多可以与子表中一个元组对应，而子表中的每个元组在超表中恰有一个元组对应，并在继承的属性值上具有相同的值。
（10）引用类型：数据类型可以嵌套定义，在嵌套引用时，不是引用对象本身，而是个用对象标识符(即指针)，这种指针被称为引用类型。
第九章相变第九章相变前⼋章我们重点讨论了⽓体的各种性质，也介绍了液体、固体的基本热学性质。
可以说，我们基本上研究了所有的物质。
到此为⽌，我们对热学这门课的梗概应该有⼀个轮廓了。
但是事物之间是普遍联系的，普遍联系的原则是⾃然界最基本的原则。
⾃然界中许多物质都以固、液、⽓三种集聚态存在，然⽽物质的三态可以互相转化并为物质本的性所决定。
例如，常态下液体的⽔可变成⽔蒸汽，也可变成冰，⽽且冰可直接变成汽。
都⾮常形象地说明了这种联系。
显然，这⼀系列转化都与物质内部微粒的热运动有着密切关系。
因此，作为普通物理的热学，⾄少应当对这个问题有⼀个简明的回答，哪怕是最肤浅的。
物质为什么会发⽣物态变化？物态变化的条件什么？物态变化的规律是什么？这些都是我们必须回答的基本问题。
这正是本章的内容。
§1单元第⼀级相变的主要特征教学⽬的和要求：理解“相变”等概念，理解“相变潜热”的物理意义。
掌握单元系⼀级相变的普遍特点和简单规律。
教学时间：⼀课时教学内容：⼀.预备知识：1.何谓相？物理性质均匀的部分，它和其它部分之间有⼀定的分界⾯隔离开来。
例如：冰和⽔的混合物，冰块和⽔有分界⾯，冰块⾥⽔物理性质三均匀的，液体中的⽔物理性质也是均匀的。
那么，冰释⼀个相，⽔也是⼀个相。
2.单元复相系(1)单元：⼀种学化物质(2)单元单相：⼀种化学物质⼀个相的体系例如：冰总是⽔的单元单相系⽔、⽔蒸汽没有混合，是两个单元相性(3)单元复相系：⼀种化学物质，有两个或以上的相。
这样的体系为单元复相系例如，冰⽔混合物是⽔的单元：相系开着的⽔也是⽔的⼀个单元⼆相系固体中不同的点阵结构可视为不同的相。
本书只研究单元系3.相变：物体的相变发⽣变化叫相变相变是在⼀定的温度和压强下进⾏的。
例如，在1atm和100℃时，⽔由液体相变成汽相，但若P不是1atm时，沸点也不再是100℃。
⾼压锅就是这样。
4.⼆级相变：没有什么积的变化，也没有相变潜热，⼈有热容易膨胀系数，⾼温压缩系数发⽣突变。
汽轮机热力系统概述第一节主、再热蒸汽及旁路系统本机组主蒸汽及再热蒸汽系统采用单元制、一次中间再热型式。
通常我们将进入高压缸的蒸汽称为主蒸汽；高压缸排汽称为冷再热蒸汽；冷再热蒸汽经锅炉再热器重新加热后进入中压缸的蒸汽称为热再热蒸汽；从主蒸汽管道经高压旁路控制阀至冷再热蒸汽管道称为高压旁路管道；从热再热蒸汽管道经低压旁路控制阀以及喷水减温器后至凝汽器的管道称为低压旁路管道。
一、主蒸汽系统１、主蒸汽管道主蒸汽管道采用A335P91优质合金钢。
最大蒸汽流量为锅炉B-MCR工况时的最大连续蒸发量1025t/h。
设计蒸汽压力18.2Mpa，设计蒸汽温度546℃，主蒸汽管道计算压力降约为0.6556MPa(MCR工况)。
主蒸汽从锅炉过热器出口联箱，由单根管道接出通往汽机房。
至汽机主汽门前分成两根支管，各自接到汽轮机高压缸左右侧主汽及调节汽阀。
然后再由四根高压主汽管导入高压缸。
在高压缸内作功后的蒸汽通过两个高压排汽止回阀，在出口不远处汇合成单根管道进入锅炉再热器。
这种单管系统的优点〈比较双管系统〉是简化管道布置，并能节省管材投资费用，同时，还有利于消除进汽轮机的主蒸汽和热再热蒸汽由于锅炉可能产生的热偏差，以及由于管道阻力不同产生的压力偏差。
两个主汽门出口与汽轮机调速汽门阀壳相接。
主汽门的主要功用是在汽轮机故障或甩负荷情况下迅速切断进入缸内的主蒸汽，汽轮机正常停机时，主汽门也用于切断主蒸汽，调速汽门通过各自蒸汽导管进汽到汽轮机第一级喷嘴。
调速汽门用于调节进入汽轮机的蒸汽流量，以适应机组负荷变化的要求。
由过热器出口至汽轮机主汽门入口的范围内，在主蒸汽管道上依次设有两只电动对空排汽阀、一只高整定压力的弹簧安全阀、一只低整定压力的弹簧安全阀和一个电磁释放阀、水压试验堵阀。
水压试验堵阀的作用是当过热器水压试验时，隔离主蒸汽管道，防止由于主汽门密封不严而造成汽轮机进水。
由主汽主管上沿汽流方向依次接出的管道有：汽机高压旁路接管及启动初期向汽机汽封系统及汽机夹层加热的供汽管。
9.2安全性描述安全性要求极高的系统主要是控制系统，在这种系统中，所控制设备的失败将导致对人员的伤害。
在20世纪80年代和90年代，计算机控制变得十分普遍，安全工程团体制订了安全性要求极高系统描述和开发标准。
安全性描述和保证过程是总的安全生命周期中的一部分，安全生命周期是作为安全管理的一个国际标准IEC61508提出来的（IEC，1998）。
这个标准是专门为保护系统（比如阻止火车闯红灯的系统）而开发的。
尽管它可以用于更一般的安全性要求极高的系统，比如控制系统，但是，此标准将安全描述从更一般的系统描述中分离出来对于信息系统来说不是很恰当。
下图说明了由IEC61508标准所假设的一个系统模型下图是Redmill的安全生命周期表示法的一个简化形式。
上图可以看出，这个标准覆盖了安全管理的所有方面，从最初的范围定义到规划和系统开发，再到系统分解。
在这个模型中，控制系统控制某些设备，这些设备都有高水平的安全性需求。
这些高水平安全性需求生成两类更详细的安全需求，最后这些需求将作用于保护系统的设备上：1.功能性安全需求：定义系统的安全性功能。
2.安全完整性需求：定义保护系统的可靠性和可用性。
这些都是基于对保护系统所期待的用法，意在保证在需要使用时它能够工作。
系统根据安全完整性级别（SIL）1到4级进行分类。
每一个SIL级代表了一个更高级别的可靠性；要求越高，SIL所需要的级别越高。
IEC61508安全生命周期标准的第一个阶段是定义系统的范围，对系统潜在的危险及其带来的风险进行估计。
第二个阶段是安全性需求描述和分配这些需求到各个子系统。
开发活动包括规划和实现两部分，安全性要求极高的系统本身被设计和实现，同时，相关的能提供额外防护功能的外部系统也一同被设计和实现。
与此同时，还要对安全有效性验证和系统的安装、运行和维护进行规划。
安全管理的终点并不是系统的交付。
在系统交付之后，系统一定要按照规划中定义的那样安装以保证风险分析能保持有效。
安全有效性验证在系统使用之前开始。
安全性在系统运行过程中尤其是在维护过程中也需要管理。
许多与安全性相关的系统问题院子不好的维护过程，所以面向维护的设计就显得尤为重要。
最后一步是系统分解（举例来说，在线路板上布置危险性材料）中的安全性考虑。
9.3信息安全性描述系统的信息安全性需求描述与安全性需求有很多相似之处。
对它们进行量化的描述是不太现实的，信息安全性需求往往是“不应该”需求类型，它定义那些无法接受的系统行为，而不是定义系统功能。
但在信息安全性描述和安全性描述之间还是有重要的区别：1.安全生命周期的概念已经很完善了，它覆盖了安全管理的所有方面。
信息安全性的描述和管理还很不成熟，还没有一个得到接受的信息安全性生命周期的概念。
2.尽管有些保密威胁是系统所特有的，但是系统面对的信息安全性威胁是普遍存在的。
所有的系统必须保护自己免于入侵、拒绝服务等。
相反，在安全性要求极高的系统中危险通常是与领域相关的。
3.信息安全性方法和技术（如加密技术和认证策略）相对比较成熟。
不过，有效地使用这些技术需要高水平的技术整合能力。
安装、配置和保持更新是很困难的事情。
结果是，系统管理者不可避免的犯一些错误，致使系统带有一定的脆弱性。
4.如果某个软件提供商在国际市场上占有统治地位，那么将意味着，如果它们的程序的信息安全性受到皮坏，将会有大量的系统受到影响。
在计算体系结构的不充分的多样性造成系统很容易受到外部威胁的攻击。
安全性要求极高的系统总是专门的、定制的系统，所以类似状况不会发生。
传统的（非计算机处理的）信息安全性分析方法是基于资产及其对机构的价值进行的。
因此，一个银行将会对存储大量资金的地带提供比较高的信息安全性措施，而对于其他潜在的损失十分有限的公共区域给予较低的信息安全性防范。
相同的方法可以用于计算机系统的信息安全性。
一个可行的信息安全性描述过程如下图所示。
这个过程中有以下几个阶段：1.资产识别和评估：资产（数据和程序）及其所需要的保护级别要明确。
注意，所需的保护级别取决于这个资产的价值，所以密码文件（比如说）比其他网页文件通常更具有价值，对密码文件的成功攻击会给系统带来广泛而严重的后果。
2.威胁分析和风险评估：找出可能的信息安全性威胁，并对其相关的风险进行评估。
3.威胁确定：识别出的威胁都是与某些资产相关联的，所以对每一种资产，给出其相关的威胁清单。
4.技术分析：评估可用的信息安全性技术及其除掉这些威胁的可行性。
5.信息安全性需求的描述：定义信息安全性的需求。
在适当的地方，需要明确给出对系统的不同威胁所要使用的信息安全性技术。
对所有的要求极高的系统，信息安全描述和信息安全管理是至关重要的。
如果系统不是安全的，那么它就会受到病毒和蠕虫的感染，损坏数据或非法对数据进行修改，拒绝服务。
所有这些意味着我们无法相信在努力保证安全性和可靠性方面所做的工作的有效性。
系统所面对的不同威胁也就对应了不同类型的信息安全需求。
Firesmith找出了包含在系统中的10类信息安全需求：1.身份验证需求：定义系统是否应该在用户与之交互之前辨认其身份。
2.认证需求：定义系统如何辨认用户。
3.权限需求：定义对所辨认出来的合法用户的权利和访问许可。
4.免疫需求：定义系统如何保护自己免受病毒、蠕虫以及类似威胁的入侵。
5.完整性需求：定义如何避免数据损坏。
6.入侵检测需求：定义应该使用说明机制来检测对系统的攻击。
7.不可抵赖需求：定义参与交易的一方不能对自己已经做出的交易抵赖。
8.隐私需求：定义如何维护数据的私密性。
9.信息安全的审查需求：定义如何对系统的使用进行审核和检查。
10.系统维护的信息安全需求：定义应用如何避免信息安全机制的意外失败所导致的合法修改。
当然，并不是没一个系统都需要所有这些信息安全性需求。
特别的需求依赖于特别的系统、特别的使用环境以及特定的用户。
作为一个例子，下图所列出的事在LIBSYS系统中所包含的信息安全性需求。
9.4软件可靠性描述可靠性是一个复杂的概念，应该在系统层次上而不是在单个组件层次上来考虑。
因为系统中的组件是相互依赖的，一个组件中的失败能够传播到整个系统并影响其他组件的操作。
在计算机系统中定义总体系统可靠性的时候，必须考虑以下三个方面：1.硬件可靠性：硬件组件失败的可能性有多大以及修复这些组件所花费的时间。
2.软件可靠性：软件组件产生不正确输出的可能性有多大？软件失败不同于硬件失败，因为它不会损坏。
它能在产生不正确的结果之后重新启动继续正确的操作。
3.操作人员可靠性：系统的操作人员出现操作错误的可能性有多大？所有这些都是紧密关联的。
硬件失败能引起超出软件输入范围的信号，由此导致软件发生无法预计的行为。
料想不到的系统行为可能使操作人员困惑和给操作人员造成压力。
而操作人员操作错误最有可能发生在紧张的情况下。
操作人员可能采取不正确的操作，使得输入信息不能处理目前的失败情形。
这些输入进一步混乱了系统，由此导致系统产生更多的错误。
因此，单一子系统失败或许是可恢复的，但当其迅速扩展为严重问题时需要立即关闭系统。
系统可靠性应该被定义为非功能需求，由下一节中介绍的度量来量化描述。
为了达到非功能性的可靠性需求，对系统定义附加的功能和设计需求是很有必要的，用这些来定义系统将如何避免失败或容错。
可靠性需求的例子有：1.应该预先定义操作者输入值的范围，系统应该检查所有操作者的输入是否在这个范围之内。
2.作为初始过程的一部分，系统应该给检查所有磁盘的坏道。
3.在实现刹车控制系统时，应该使用N版本程序设计。
4.系统应该使用Ada的一个安全子集来实现，并使用静态分析来检查。
在导出功能性的可靠性需求中，没有一个简单规则可以使用。
在开发要求极高的系统的开发机构中，通常有自己的关于可靠性需求及其对实际系统可靠性影响的知识积累。
这些机构一般在开发某个专门类型的系统方面有所擅长，如铁路控制系统。
因此，可靠性需求一旦导出，就会在一系列系统中反复使用。
9.4.1可靠性度量可靠性度量最先是用在硬件组件上。
硬件组件失败是由于一些物理因素，如机械的磨损、电器发热等。
组件都有平均寿命，这反映在使用最广泛的硬件可靠性度量“平均无故障时间（MTTF）”上。
MTTF是对组件能正常工作的平均时间长短的期待值。
硬件一旦失败就不可能修复，“平均修复时间（MTTR）”能反映需要维修或更换的平均时间，也是一个重要的度量指标。
不过，这些硬件度量并不都适合软件的可靠性描述，因为软件失败和硬件失败有很多不同之处。
软件组件失败通常是短暂的，它们的失败只有对某些输入才发生。
如果数据是完好的，系统在失败之后仍能正常工作。
用于描述软件可靠性和可用性的度量如表9-2所示。
选择使用哪个度量取决于系统的类型以及应用领域需求。
这里给出了一些系统类型的例子，它们可使用不同的度量。
表9-2 可靠性度量1.请求时失败的可能性（POFOD）：这个度量最适合于对服务的请求是无法预知的和相对时间持续较长的系统、如果请求失败将有严重后果的系统。
这项度量可以用于定义保护系统的可靠性，如化工厂的减压系统和发电厂紧急关闭系统。
2.失败发生率（ROCOF）：这个度量适用于经常性的系统服务请求，正确提供服务很重要的一类系统。
这项度量可以用于银行柜员机系统，该系统处理客户的交易，或者用于宾馆预约系统。
3.平均无故障时间（MTTF）：这个度量可以用在有很长事务处理的系统中，也就是用户会长时间使用的系统。
平均无故障时间应该比这个事务处理的平均时间长才行。
这类系统的例子是字处理系统或CAD系统。
4.可用性（A V AIL）：这个度量应该用在不间断的系统中，即用户期待这个系统提供连续的服务。
此类系统的例子是电话交换系统和铁路信号系统。
在估计系统的可靠性上，使用的测量方法有三类：1.对确定数量的系统服务请求统计系统失败的次数。
这是用来测量POFOD指标的方法。
2.系统失败间隔时间（或事物处理的数目）。
这是用来测量ROCOF和MTTF的。
3.当系统失败发生时维修和重启所需要的时间。
假设系统需要连续的工作，这是用来测量A V AIL的。
在这些度量中使用的时间是日历时间、处理机时间或其他离散单位，如事务处理的数目。
在需要系统花许多时间来等待服务请求的响应的系统中，如电话交换系统，时间单位应该使用处理机时间。
在此使用日历时间就不是太合适。
日历时间对于连续操作的系统是一个合适的时间单位。
举例来说，监控系统、警报系统和其他类型的过程控制系统都属于这个类型。
处理事务的系统如银行ATM机或航班预定系统在一天中的负荷是不一样的。
在这种情况下，“时间”单位就应该使用事务处理的数目，也就是ROCOF是上千个事务中失败的事务数目。
9.4.2非功能性的可靠性需求在许多系统需求文档中，可靠性需求没有得到很好的定义。
