课程复习资料软件工程.docx
《课程复习资料软件工程.docx》由会员分享，可在线阅读，更多相关《课程复习资料软件工程.docx（43页珍藏版）》请在冰豆网上搜索。
课程复习资料软件工程
《软件工程》
一、绪论
1.软件：
计算机程序及其说明程序的各种文档。
软件产品的生产主要是研制，成本主要体现在软件的开发和研制上。
2.软件工程内容：
软件开发技术和软件开发管理。
3.软件生存周期：
一个软件从提出开发要求开始直到该软件报废为止的整个时期。
4.软件生存周期模型：
确立了软件开发和演绎中个阶段的次序限制以及个阶段活动的准则，例如：
瀑布模型、增量模型、螺旋模型、喷泉模型、变换模型和基于知识的模型。
瀑布模型是将软件生存周期个个活动规定为依线性顺序连接的若干阶段的模型，属于整体生存周期。
5.软件开发环境：
由于工具箱存在的问题，人们在工具系统的整体化及集成化方面展开一系列研究工作，使之形成完整的软件开发环境。
6.结构化方法：
由结构化分析SA、结构化设计SD和结构化程序设计SP构成其总的指导思想是：
自顶向下、逐步求精。
基本原则是功能的分解和抽象。
二、可行性研究（可不可行，值不值的）
1.可行性研究：
目的是用最小的代价在尽可能短的时间内确定该软件项目是否能够开发，是否值得去开发。
其可从三个方面入手：
技术可行性、经济可行性和社会可行性。
2.项目开发计划：
是一个管理性文档，主要内容有：
项目概述；实施计划；人员组织及分工；交付期限等。
三、软件需求分析（做什么）
1.结构化分析SA基本思想：
是面向数据流进行需求分析的方法，是一种建模活动，自顶向下逐层分解功能要求。
其描述工具有：
数据流图DFD；数据字典DD；描述加工逻辑的结构化语言、判定表、判定树。
2.DFD：
数据流图，是SA方法中标识系统逻辑模型的一种工具，它以图形的方式描绘数据在系统中流动和处理的过程，只反映系统必须完成的逻辑功能，市一中功能模型。
它有四种基本图形符号：
箭头－>表示数据流；椭圆表示加工（还应该有编号）；双杠＝表示数据存储；方框表示源点或终点。
3.画DFD的步骤：
（1）先画系统的输入和输出即顶层数据流图；
（2）画系统内部即画下层数据流图（0层、1层…）。
注意分清只画数据流，且父图和子图需要平衡：
子图的输入和输出数据流同父图相应加工的输入输出数据流必须一致。
4.数据字典：
用来定义数据流图种的各个成分的具体含义。
由数据项组成；一般有数据流条目、数据存储条目、数据项条目和加工条目等内容。
具体的可以用相关的符号和数据项来定义。
如：
姓名＝｛字母｝182,表示姓名由2－18个字母组成。
5.判定树与判定表：
判定树是判定表的变形，一般情况下比判定表更直观且易于理解和使用。
也可二者结合，先用判定表作底稿，在此基础上产生判定树。
四、概要设计
1.概要设计：
描述软件的总的体系结构，基本任务有：
软件结构设计（关键）；数据结构和数据库设计（概念、逻辑和物理上的）；编写概要设计文档；评审。
2.问题复杂性经验公式：
C（P1+P2）>C（P1）+C（P2）；因为还要设计他们的接口。
3.模块独立性：
每个模块只完成系统要求的独立子功能，并且与其他模块的练习最少且接口简单。
它是模块化、抽象、信息隐蔽的产物。
可以用两个定性的度量标准来衡量：
（1）耦合性：
软件系统结构中各模块间相互练习紧密程度的一种度量。
无直接耦合<数据耦合<标记耦合<控制耦合<公共耦合<内容耦合（高）
数据耦合指两模块间传递简单的数据值，而控制耦合指传递的是控制变量，所以可以将被调用模块内的判定上移到调用模块中去，同时将被调用模块按其功能分解为若干单一功能的模块。
（２）内聚性：
模块的功能强度的度量即模块中个元素彼此结合的紧密程度。
偶然内聚<逻辑内聚<时间内聚<通信内聚<顺序内聚<功能内聚（高）
将软件系统划分模块时，尽量做到高内聚低偶合，提高模块的独立性。
4．软件结构图SC：
软件系统的模块层次结构，反映了整个系统的功能实现。
SC图的形态特征有：
（１）深度：
模块的层次，根算一层；（２）宽度：
一层中最大的模块个数；（３）扇出：
一个模块直接诶下属模块的个数。
（４）扇入：
一个模块直接上属模块个数。
画结构图时应该注意：
同一名字的模块在结构图中仅出现一次；调用关系只能从上到下；习惯上从左到右表示模块的调用次序。
5．模块的作用范围（作用域）：
指模块内一个判定影响的所有模块的集合。
模块的控制范围（控制域）：
指模块本身及其所有下属模块的集合。
软件结构设计的一个优化准则就是一个模块的作用范围应该在其控制范围之内，且判定所在的模块应与受其影响的模块在层次上尽量靠近。
因此同常可以采用上移判断点和下移受判断影响的模块来满足要求。
6．数据流图的类型：
（１）变换型。
由输入、变换和输出组成，是顺序结构。
变换分析的步骤：
ａ．确定变换中心、逻辑输入和逻辑输出。
ｂ．设计软件结构的顶层和第一层－变换结构。
ｃ．设计中下层模块。
（２）事务型。
某加工将输入数据流分离成许多发散的数据流，形成许多加工路径，并根据输入值选择一个路径执行。
事务分析步骤：
ａ．确定事务中心和加工路径。
ｂ．设计软件结构的顶层和第一层－事务结构。
ｃ．中下层模块的设计与优化。
五、详细设计（过程设计）
１．基本任务：
详细的算法设计；块内数据结构设计；数据库物理设计；其它设计；编写详细设计说明书；评审。
２．结构化程序设计ＳＰ基本要点：
（１）采用自顶向下、逐步求精的程序设计方法；（２）使用三种基本控制结构构造程序：
顺序、选择、循环方式；（３）主程序员组的组织形式：
一个主程序员、一个后备程序员和一个程序管理员组成核心，再加上一些专家、其它技术人员组成小组。
３．PAD图的应用：
排序算法。
?
?
４．Jackson方法：
是面向数据结构的设计方法。
JSP方法定义了一组以数据结构为指导的映射过程，它根据输入、输出的数据结构，按一定的规则映射成软件的过程描述（即程序结构），而不是软件的体系结构，因此使用于详细设计。
六、软件编码
１．程序设计语言的选择关键因素：
是项目的应用领域。
（１）科学工程计算：
如FORTRAN,Pascal,C,PL/1；（２）数据处理与数据库应用：
如Cobol广泛用于商业数据处理；SQL为IBM卡发的数据库查询语言；4GL第4代语言；FoxPro等；（３）实时处理：
汇编语言；Ada等；（４）系统软件：
汇编、C、Pacal、Ada等；（４）人工智能：
Prolog，Lisp。
２．程序设计风格：
指一个人编制程序时所标心出来的特点、习惯、逻辑思路等。
良好的编成风格可以减少编码的错误，减少读程序的时间，提高软件的开发效率。
（１）源程序文档化；（２）数据说明条理化；（３）语句结构规格化；语句构造原则：
简单直接，不能为了追求效率才而使代码复杂化；（４）输入输出的工程学化；（５）可读性第一，效率第二。
七、软件测试
１．目的：
为了发现错误而执行程序得过程，能够发现至今尚未发现得错误。
２．动态测试：
通过运行程序发现错误得测试。
一般有两种方法：
一是测试产品得功能（黑盒法），二是测试产品内部结构及处理过程（白盒法）。
３．逻辑覆盖：
是白盒技术之一，又分语句覆盖，判定覆盖，条件覆盖，判定、条件覆盖，条件组合覆盖，路径覆盖等。
４．黑盒测试：
等价类划分；边界值分析；错误推测；因果图；综合策略。
５．测试过程：
单元测试；集成测试；确认测试；系统测试。
６．集成测试的方法：
（１）非渐增式测试：
首先对每个模块分别进行单元测试，然后再把所有的模块按设计要求组装在一起进行测试。
（２）渐增式：
逐个把未经过测试的模块组装到已经过测试的模块上去，进行集成测试。
以此重复直至程序组装完成。
又分自顶向下结合和自底向下结合。
７．调试（纠错）目的：
在成功的测试之后，确定错误的原因和位置，并改正错误。
尽可能多地发现程序中的错误，
调试技术：
简单的调试方法，归纳调试法，演绎调试法和回溯调试法。
八、软件维护
１．软件维护：
是软件生存周期中时间最长的一段，所花费的精力和费用也是最多的一个阶段。
其内容：
校正性维护，适应性维护，完善性维护和预防性维护。
其中完善性维护是为了适应这些变化，应用软件原来的功能和性能需要扩充和增强。
这种增加软件功能、增强软件功能、提高软件运行效率而进行的维护活动称完善性维护。
2.维护性困难性：
由于软件需求分析和开发方法的缺陷。
读懂别人的程序是困难的；文档的不一致性；软件开发和软件维护在人员和时间上的差异；软件维护不是一项吸引人的工作。
3.维护的副作用：
编码副作用；数据副作用；文档副作用。
4.软件的可维护性：
软件能够被理解、校正、适应及增强功能的容易程度。
软件的可维护性、可使用性、可靠性是衡量软件质量的几个主要特性，可维护性是软件开发阶段的关键目标。
九、软件开发的增量模型
1.快速原型的原理：
经过简单快速分析，快速实现一个原型，用户与开发者在试用原型过程中加强通信与反馈，通过反复评价和改进原型，减少误解，弥补遗漏、适应变化，最终提高软件质量。
十、面向对象的方法
１．对象：
人们研究的任何事物，是数据和操作的封装体。
类：
具有相同和相似性质的对象的抽象就是类；分一般－具体（分类）结构和整体－部分（组装结构）。
２.消息和方法：
对象之间进行通信的构造叫做消息，消息包括说明接收消息的对象名、发送给该对象的消息名（对象名.方法名），一般还有参数的说明。
3.面向对象的特征：
对象唯一性；分类性；继承性；多态性（多形性）；
4.OMT：
面向对象的建模与设计，主要包括OOA（对象模型、动态模型、功能模型）、OOD、OOP三过程。
UML：
统一建模语言。
５.面向对象设计的原则：
模块化；抽象；信息隐蔽；低耦合；高内聚（操作、类和一般－具体内聚）。
十一、软件质量与质量保证
1.软件质量保证：
向用户及社会提供满意的高质量的产品，确保软件产品从诞生到消亡为止的所有阶段的质量的活动，即确定、达到、和维护需要的软件质量而进行的所有有计划、有系统的管理活动。
２．McCall质量度量模型：
（１）面向软件产品操作：
正确性，可靠性，效率，完整性，可用性；（２）面向软件产品修改：
课维护性、课测试性和适应性；（３）面向软件产品适应：
可移植性（从一个计算机系统或环境移动到另一个计算机系统和环境运行时所需的工作量），可重用性，可互操作性。
３．软件的可靠性：
是最重要的软件特性，通常衡量在规定的条件与时间内，软件完成规定功能的能力。
其要求程序是正确的、完整的、一致的和健壮的。
４．容错软件：
在因错误而发生错误时，仍然能在一定程度上完成预期的功能的软件。
容错主要手段是冗余：
实现系统规定功能是多余的那部分资源，包括硬件、软件、信息和时间。
冗余技术可分四类：
结构冗余，信息冗余，时间冗余，冗余附加技术。
十二、软件工程管理
１．软件项目计划内容：
范围；资源（人员、硬件、软件、其它）；进度安排（工程网络图、cantt图、任务资源表）；成本估算；培训计划。
２．软件配置管理SCM：
用于整个软件工程过程，目标是：
标识变更；控制变更；确保变更正确地实现；报告有关变更，其是一组管理整个软件生存期各阶段中变更地活动。
其基本单位是：
软件配置项SCI，
基线：
是软件生存期中各阶段地一个特定点，它的作用是把开发各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，以便检查与肯定阶段成果。
３．文档：
某种数据媒体和其中所记录的数据，使软件的一部分。
十四、软件开发环境
１．软件开发环境：
在计算机的基本软件的基础上，为了支持软件的开发而提供的一组工具软件系统。
实质是：
（１）软件开发环境是一组相关工具的集合；（２）这些工具按一定的卡发方法或开发处理模型组织起来；（３）工具支持整个软件生存期的各阶段或不分阶段。
２．软件工具：
为支持计算机软件的开发、维护、模拟、移植或管理而研制的程序系统。
通常由工具、工具接口和工具用户接口构成。
３．计算机辅助软件工程CASE：
是一组工具和方法的集合。
可以辅助软件开发生命周期各阶段进行软件开发，其是由种类繁多的软件开发和系统集成的产品及软件工具的集合。
CASE系统按支持范围可分为：
工具、工作台和环境。
面向对象软件工程的一些学习笔记
第一部分概述
在以前,我觉得在阅读一本技术文章时,觉得最没有兴致的就是前面的概述部分,但是,当自己想写这么一样的东西时,又发现有必要写一些概述的东西,呵呵,或许我以后会对那些概述的印象会有所改变.
在这一部分中,我将谈一些软件工程的一些理解,这也是我后面可能存在的文章的基础.必须注意的是,我这里并没有过多地谈论一些概念,因为那些东西在许多书中有详细的定义,无论那些定义是不是准确,但也有助于你对软件工程的理解的.
我所理解的软件工程,它贯穿于一个软件项目的整个生命周期,即从项目立项,需求分析,系统分析（功能分析）,到详细设计,到代码编制,直到测试然后交付使用,最后还有售后服务,其实更深一步说,此生命周期还包括本项目中的部分软件部件可以在其它项目中使用,则生命周期因此而增加.
我觉得现在我国做软件的时候,一般没有考虑这么远,首先有很多软件公司的软件开发队伍中根本没有软件工程的概念,二是即使有软件工程的概念,也是基于软件生命周期的前期,即认为它只存在于系统分析,和功能设计,最多到编码,而测试安装及售后服务都不是他们的考虑之列,我觉得这是我国软件发展尚没有完善的一点.我们来考虑一下,如果在系统分析时,没有考虑到将来维护的需要,而没有给将来的出错留下太多的提示信息,只是简单地报一下错,这样,在将来系统出现问题后,将会有多少麻烦的事.而如果没有考虑到本次项目中的某些技术或部件在将来的项目中的重用性,则必然增加软件开发成本,增加软件开发期.这也是对一个软件企业的成长不利的.
就软件工程的作用而言,在我所看过的书籍有列有许多,我觉得最重要的一点在于它的长期效益,其实就一个项目本身而言,软件工程可能会增加成本的,这也是许多小型的软件公司不愿意进行完善的软件工程的原因.当然,这也是有道理的,在没有解决生存问题的时候,就要考虑一个五年甚至十年计划,那也太难为了一点!
但是如果一个软件公司要想获得长期战略优势,或是要将其经验转化为战略优势,软件工程势在必行的.这也是为什么软件工程学在近些年在国外比较流行的原因.在国内,由于发展的滞后性,目前尚没有在企业中广泛地使用软件工程,但作为一种趋势,对于软件工程学的学术上的讨论目前正在加强,在未来的几年内,软件工程学有可能是软件企业最为关心的话题.
软件工程学发展到今,也已经经历了几代,同时它的发展是与开发工具的发展息息相关的.最初软件是为了效率而存在的,没有什么软件工程的概念,而这个时候的开发工具主要是汇编之类的较为原始的语言,后来发展得比较好的是以结构为基础的软件工程,包括结构化分析与结构化设计,这与当时开发工具主要是以过程和函数为主有关.而目前,面向对象的软件开发工具大行其道,而与之相关的,面向对象的软件工程也就浮出了水面.
与传统的软件工程（主要是结构化的）相比,面向对象的软件工程,更好的支持了前面所说的软件生命周期的后几个环节,即售后服务,特别是重用.这表现为对象比函数在将来的项目中,更具有生命力.
函数倾向于一种功能,在将来的项目中,实现同样的功能的方法变化会是很大的,这样,当这功能实现方法变化时,你的函数也就要重新写,再编译,连接.而对象不同,它表现为一个完整的实体,它是存储一些数据并实现一些功能的整合体.它隐藏了功能实现的具体细节.这就好比,你要建一栋房子,而用什么样的砖,你的操作方法也就不一样,这里你的操作方法也就是功能（函数或过程）,而砖也就是数据,由于数据是独立于功能而存在的,它的变化,功能不能及时反映,比如别的一个模块调用了这样的一个建房子的功能,那么它就必须根据不同的砖头来判断调用哪一个建房子功能.
而如果你把建房子当作一个对象,那么砖（也就是其中的数据）和建房子的方法（过程）都被封装在其中了,假设这个对象提供了一个接口（建房子）,别的人用这个对象时,只需要执行这个方法,而其中的细节它也就不用管了,让我们来看一下,如果砖头变化了呢?
我们只要修改对象内部的实现细节,而别人在用这个对象时,依然是调用建房子这样的一个方法,它是不用知道用什么砖头的.
好啦,这些就做为概述部分吧,也该结束了,如果概述就写了太多,就不能算是概述了.下回再说吧.
第一章需求分析
１．１软件生命周期
在这一章中，我们首先来回顾一下软件生命周期，前面我已经提到过，我所认为的软件工程是贯穿于一个软件生命周期中的全部。
与生命周期在其它范畴的意义相似，它包括一个软件的：
需求分析，系统分析／系统设计，编码，测试／验收，售后服务。
前面也提到过，如果本次软件中运用到的技术在以后的项目中得
以运用，那么，这一软件的生命周期将在以后的项目中延伸。
之所以要强调这一点，是因为与
此相对应，软件工程就需要考虑到这一生命周期的延长。
顺便提一下，在这一生命周期中，其与客户有接触的有需求分析，验收及售后服务。
其它部分
一般没有用户的参与（当然，具体的项目可能有不同）。
将这一点提出来，是因为如果注意到
这一点，就需要在这些步骤中，充分考虑客户的因素。
１．２需求分析概述
其实，无论你用什么样的软件工程方法，需求分析都是差不多的，所以，在这一部分中，我并不会特别注意面向对象这一点。
但是，在软件生命周期的后续阶段，面向对象与其它软件工程方法需要的数据会有一些差别，所以，在这一阶段需求分析与其它软件工程方法也是有一些差别的。
下面将首先说它们共通的东西。
需求分析是第一个与客户接触的环节，客户将根据需求分析的优劣来产生第一印象，如果做得好，将为后续工作带来极大的方便，当然这一点与软件工程无关，只是随便说一点吧。
需求分析是了解用户需求的过程，它的结果将是以文档形式表示的客户需求。
理想情况是，做出了需求说明文档后，在β测试之前，都不再需要与用户进行交流。
当然这只是一种理想情况，再好的需求分析也不能够达到这一点，因为即使在做需求分析时，已经考虑得很充分了，但是，做软件是有一个过程的，我在实际工作中碰到了这样的情况：
客户单位与另外一个单位合并，呵呵，可想而知，合并前的两个公司对同样的事做法是不一样的，需求当然也就有区别，这时，也就难免要修改设计文档了，当然，修改文档客户是要另外给钱的，但设计文档还是得改了呀！
当然还有另外的一种情况，比如公司内部部门调整（目前常见的情况是：
客户单位为
通过ISO9000系列认证而修改公司管理结构，没有办法，在这种情况下，给你钱是好的，不给钱，你也得做。
题外话，反正这不是什么非常专业的文档，没有关系吧？
：
），之所以在这里大倒需求分析人员的苦水，也是要告诉那些做开发的，有时，不是需求分析人员没有做得好，有时需求分析的变化是与他们无关的。
而且有时，会在需求分析说明文档中留下余地，以使将来可能的变化时，可以灵活一些。
需求分析的结果是需求分析文档。
那么需求分析的结果有什么要求呢？
因为需求分析联结的是用户和系统分析人员，前者是没有什么技术背景的人，而后者恰好相反，没有什么业务背景。
系统分析的结果是要给用户确认的，而其后使用它最多的将是系统分析员。
所以，做需求分析，写需求分析文档是比较有难度的，它不能是技术文档，因为用户不会关心你是用什么技术实现的，但也是岗位职责说明书，那不是系统分析员想知道的。
要写一份让用户能够放心签字，同时也要让系统分析员觉得好的文档并不太容易。
有这样的一个故事，说的是为什么英国的海军可以一度称霸海洋的。
说原因在于它在建造军舰之前，就建了一个模型，还没有开始建造，就让将来可能使用这个军舰的人站在模型旁，讨论如果让他来操作，是不是合适；而让可能负责建造的人也站在模型旁，看它的设计是否符合技术要求。
提这样的一个故事，是为了说，需求分析说明的作用与那个模型的作用一样，在软件开发之前，给用户一个模型，让他考虑，就在目前这个说明文档中所描述的情况下，是否已经实现了它的全部功能。
而它给系统分析人员看时，就是让他们考虑，所描述的系统是不是可以实现。
１．２需求分析方法
在实践中，需求分析方法有很多的，根据具体情况采用不同的方法，以下提供一种分类：
一、被动法
这种方法适用于一些静态的、确定的数据的收集，比如发票格式，报关单格式，入／出库单格式等。
用这种方法的优点是对被调查人员影响较小，同时，投入人力也较小。
其缺点是不容易发现一些不太显然的信息，如发票中背书内容，因为这一部分在一定工作中没有一定之规，所以，容易被被调查对象忽略。
而且这种方法也有很多偶然性因素，比如一个刚与人吵过架的人来填写答卷与一位心平气和的人来填写答卷，就同样原调查目标，可能有不同的结果。
被动法主要有：
问卷法，样张收集，资料整理。
二、主动法
这种方法容易发现一些容易被被调查对象漏掉的信息，比如发票的背书信息，如果你用问卷，则十个人可能有十种答案，而且说法还可能不可以归类。
而如果用访谈方式进行，则调查者可以引导访谈对象将这些答案归类，比如可以问：
你刚才所说的情况是不是与．．．类似之类的提示性的话。
但访谈法也是有缺点的，它的缺点是对于执行人的要求比较高，而且可能在那种环境下，被访问对象可能会对一些数据漏掉，因为在访谈中，被访问对象有可能没有时间整理
其思路。
主动法主要有：
开座谈会，深度访谈等。
１．３面向对象软件工程对需求分析的要求
前面已经提到过，在需求分析阶段，是否面向对象软件工程并不太明显，但是，如果考虑到以的需要的话，在细节上可能会有一些不同，说白了，也就是考虑到以后需求说明书中的功能都将是由对象实现的，可以在需求分析时，考虑一下现在的资料是不是适合由对象来实现，以及如何实现，当然，这个时候的考虑也只是初步的，同时这对需求分析人员也提出了更高的要求，但如果考虑到了，那就会为将来的系统分析有好处。
这里我也只是提一个思路，但是，具体有什么例子，我也一时也说不上，以后的例子中也许会有相应的内容出现。
说句实话，在我的经历中所知道的需求分析，一般做得都不怎么样，如果我自己去做，或许做得比他们做得还差，这是中国式企业管理造成的，最后提客观一句，只是为了说一个意思，如果一个企业是封闭式生产，即生产成型的软件产品去出售，那么他的需求分析可以做得相对好些，而如果是以项目为主导，即强调了客户的作用的话，那么？
需求分析即使写好了，最后做些改动，甚至是结构性变化都是“合理”的，没有办法呀，毕竟有些东西是写不进需求分析说明文档，将其搬到桌面上来讲的。
第二章系统分析／设计
（一）
前面的需求分析没有什么独特的地方，这也下体现了一个系统中是稳定的东西是需求，所以，对于需求分析的方法比较成熟，没有什么太大的变化。
从系统分析开始，就有很多不确定因素在其中做怪了，所以，面向对象与否，差别就已经很大了。
２．１对象的一般知识
既然是面向对象软件工程，那么，对象就是贯穿整个软件工程过程的。
首先我们来看一下，什么是对象：
对象就是存有一些数据并实现一些方法的实体。
当然这也不是什么精确的定义。
在我的理解中，一个对象中有四样：
一是数据（属性），二是动作（方法），三是事件（响应），四是消息（接口）。
下面用一个简单但不是很规范的例子来说明这四个方面。
我将以自行车为例：
如果将自行车当作一个对象，那么，数据包括元数据与对象数据，这也是组成对象的结构化信息，自行车里的数据也就是它有两个轮子，一个三角架，一个龙头等等，这些东西也可以看成是对象，例如轮子是由钢丝与轮箍组成的。
动作是指对象内部的一些功能，在我们的自行车对象中，动作也就是加速，减速，停车这些动作。
其中消息分为内部消息与外部消息，外部消息是指此对象与其它对象的关联，也就是说，对象是通过消息与其它对象通讯的；内部消息是指组
升级会员 