第1章软件工程概述2.docx
《第1章软件工程概述2.docx》由会员分享，可在线阅读，更多相关《第1章软件工程概述2.docx（32页珍藏版）》请在冰豆网上搜索。
第1章软件工程概述2
第1章软件工程概述
本章要点
✧软件工程产生的原因
✧软件工程的基本原理
✧软件工程方法学和面向对象方法学基本原理
✧软件过程
✧软件工程有关工具和环境
本章学习目标
✧了解软件工程产生的原因
✧掌握软件工程的基本原理
✧了解软件工程方法学和面向对象方法学基本原理
✧了解软件过程
✧了解软件工程有关工具和环境
§1.1软件工程的产生
软件工程（Software Engineering）是在克服60年代末所出现的“软件危机”的过程中逐渐形成与发展的。
在不到40年的时间里，在软件工程的理论和实践两方面都取得了长足的进步。
软件工程是一门指导计算机软件系统开发和维护的工程学科，是一门新兴的边缘学科，涉及到计算机科学、工程科学、管理科学、数学等多学科，研究的范围广，主要研究如何应用软件开发的科学理论和工程技术来指导大型软件系统的开发。
例如现代操作系统的开发，如果不采用软件工程的方法是不可能的。
在我国加入ＷＴＯ后，大力推广、应用软件工程的开发技术及管理技术，提高软件工程的应用水平，对促进我国软件产业与国际接轨,推动我国软件产业的迅速发展起着十分重要的关键作用。
软件工程的产生和发展是与软件的发展紧密相关的。
自从第一台计算机诞生以来，就开始了软件的生产，到目前为止，软件发展经历了三个阶段：
1、程序设计时代（1946－1956年）
采用“个体生产方式”，即软件开发完全依赖于程序员个人的能力水平。
2、程序系统时代（1956－1968年）
由于软件应用范围及规模的不断扩大，个体生产已经不能够满足软件生产的需要，一个软件需要由几个人协同完成，采用“生产作坊方式”。
该阶段的后期，随着软件需求量、规模及复杂度的增大，生产作坊的方式已经不能够适应软件生产的需要，出现所谓“软件危机”。
3、软件工程时代（1968年至今）
这阶段的主要任务是为了克服软件危机，适应软件发展的需要，而采用“工程化的生产”方式。
“软件危机”（Software crisis）的出现是由于软件的规模越来越大，复杂度不断增加，软件需求量增大。
而软件开发过程是一种高密集度的脑力劳动，软件开发的模式及技术不能适应软件发展的需要。
致使大量质量低劣的软件涌向市场，有的软件花费了大量人力财力，却在开发过程中就夭折。
例如：
IBM公司的OS/360，共约100万条指令，花费了5000多个人年；经费达数亿美圆，而结果却令人沮丧，错误多达2000个以上,系统根本无法正常运行。
OS/360系统的负责人Brooks这样描述开发过程的困难和混乱:
“…像巨兽在泥潭中作垂死挣扎，挣扎得越猛，泥浆就沾得越多，最后没有一个野兽能够逃脱淹没在泥潭中的命运。
…”
1963年，美国飞往火星的火箭因为一个软件错误而爆炸。
1967年8月23日，原苏联”结盟一号”载人宇宙飞船，也由于忽略了一个小数点，在进入大气层时因打不开降落伞而烧毁。
“软件危机”主要表现在两个方面：
（1）软件产品质量低劣，甚至开发过程就夭折。
（2）软件生产率低，不能满足需要。
软件工程是一门新兴的边缘学科,涉及的学科多，研究的范围广。
归结起来软件工程研究的主要内容有以下两个方面：
1、软件开发技术，它包括软件开发方法、技术和软件开发工具及环境、软件管理技术。
2、软件规范（国际规范）包括：
（1）软件开发技术（软件结构、开发方法、工具与软件工程环境、软件工程标准化）
（2）软件工程管理（质量管理，软件工程经济学：
成本估算，计划安排）
软件工程研究的目标是“以较少的投资获取较高质量的软件”。
§1.２软件工程及其基本原理
软件工程就是将工程学原理应用于软件开发与维护的实践中来，是人们为解决60年代开始出现的软件危机中逐步形成和发展起来的。
随着软件产品的系列化，软件开发的工程化、标准化、产业化，软件工程学成为软件产业发展的重要理论技术基础。
１.２.１软件工程定义
软件工程是指导计算机软件开发和维护的工程学科。
采用工程学的概念、原理、技术和方法，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来开发与维护软件，这就是软件工程。
软件开发方法的发展过程可分为3个阶段，即程序设计时代、程序系统时代、软件过程学时代。
如表1．1所示，可从名称、生产方式、质量、设计对象、开发工具、维护等方面进行比较，了解3个阶段各自的特点。
从根本上说，软件工程学时代摆脱了软件“个体式”或“作坊式”的生产方法，把软件作为一种社会产品，并进行批量生产。
软件工程学研究这种生产过程的有关基础理论、方法论和工具系统。
下面先说明软件工程学的一些主要概念：
表1．1软件开发方法的三个发展阶段
项目
程序设计时代
程序系统时代
软件工程学时代
名称
程序
软件
软件产品
生产方式
个人
作坊式项目小组
软件组织
质量
取决于个人水平
取决于小集团水平
生产管理可靠性评价和质量控制
设计对象
以硬件为中心
硬件／软件为中心
以软件为中心
开发工具
无
无系统工具且个人所有
软件生成器等，为组织所公有
维护
无
由开发者进行维护，且在设
计中不重视设计维护问题。
设计制作时均考虑维护问题，维护占成本主要部分，近年已达到80％以上。
设计方法
没有系统的方法
自顶向下的方法
结构化程序设计及自顶向下和
自底向上结合的方法
程序：
为了使计算机实现预期的目的（如解某一算题或控制某一过程）而编排的一系列步
骤称为程序。
程序可以用机器指令来编写，也可以用程序设计语言来编写。
软件：
计算机的程序加上该程序的各种规格书或文档。
软件方法是以大型程序为研究对象的。
相应文档是软件的核心之一。
软件工程：
生产软件的工程。
研究软件工程的学问叫软件工程学（有时人们也把软件工程学简称为软件工程）。
在某些书中，软件工程也称为软件产品工程学和软件生产管理法。
软件可靠性：
软件在所给条件下和规定时间内，能完成所要求的功能的性质。
软件可靠度：
软件在所给条件下和规定时间中，能完成所要求功能的概率。
很明显软件可靠性和硬件可靠性完全不同。
对硬件而言，经过早期的故障排除之后，它稳定在一定的故障频率范围内，这个期间的故障是随机的。
使用若干年后，故障率增大。
但对软件而言，不存在由于工作中的损耗而发生故障。
软件的故障差不多均是在设计、制作阶段中已存在但未被发现的。
因此，只有通过维护才可能使软件可靠度随时间增加而增加。
１.２.２软件工程的基本原理
自从1968年在联邦德国召开的国际会议上正式提出并使用了“软件工程”这个术语以来，研究软件工程的专家学者们陆续提出了100多条关于软件工程的准则或“信条”。
著名的软件工程专家B．W．Boehm综合这些学者们的意见并总结了TRW公司多年开发软件的经验，于1983年在一篇论文中提出了软件工程的七条基本原理。
他认为这七条原理是确保软件产品质量和开发效率的原理的最小集合。
这七条原理是互相独立的，其中任意六条原理的组合都不能代替另一条原理，因此，它们是缺一不可的最小集合，然而这七条原理又是相当完备的，人们虽然不能用数学方法严格证明它们是一个完备的集合，但是，可以证明在此之前已经提出的100多条软件工程原理都可以由这七条原理的任意组合蕴含或派生。
下面简要介绍软件工程的七条基本原理：
1．用分阶段的生命周期计划严格管理
有人经统计发现，在不成功的软件项目中有一半左右是由于计划不周造成的，可见把
建立完善的计划作为第一条基本原理是吸取了前人的教训而提出来的。
在软件开发与维护的漫长的生命周期中，需要完成许多性质各异的工作。
这条基本原理意味着，应该把软件生命周期划分成若干个阶段，并相应地制定出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。
Boehm认为，在软件的整个生命周期中应该制定并严格执行六类计划，它们是项目概要计划，里程碑计划，项目控制计划，产品控制计划，验证计划，运行维护计划。
不同层次的管理人员都必须严格按照计划各尽其职地管理软件开发与维护工作，绝不能受客户或上级人员的影响而擅自背离预定计划。
2．坚持进行阶段评审
当时已经认识到，软件的质量保证工作不能等到编码阶段结束之后再进行。
这样说至少有两个理由：
第一，大部分错误是在编码之前造成的，例如，根据Boehm等人的统计，设计错误占软件错误的63％，编码错误仅占37％；第二，错误发现与改正得越晚，所需付出的代价也越高。
因此，在每个阶段都进行严格的评审，以便尽早发现在软件开发过程中所犯的错误，是一条必须遵循的重要原则。
3．实行严格的产品控制
在软件开发过程中不应随意改变需求，因为改变一项需求往往需要付出较高的代价。
但是，在软件开发过程中改变需求又是难免的，由于外部环境的变化，相应地改变用户需求是一种客观需要，显然不能硬性禁止客户提出改变需求的要求，而只能依靠科学的产品控制技术来顺应这种要求．也就是说，当需求改变时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理。
所谓基准配置又称为基线配置，它们是经过阶段评审后的软件配置成分（各个阶段产生的文档或程序代码）。
基准配置管理也称为变动控制：
一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。
绝对不能谁想修改软件（包括尚在开发过程中的软件），就随意进行修改。
4．采用现代程序设计技术
从提出软件工程的概念开始，人们一直把主要精力用于研究各种新的程序设计技术。
60年代末提出的结构程序设计技术，已经成为绝大多数人公认的先进的程序设计技术。
以后又进一步发展出各种结构分析（SA）与结构设计（SD）技术。
实践表明，采用先进的技术既可提高软件开发的效率，又可提高软件维护的效率。
5．结果应能清楚地审查
软件产品不同于一般的物理产品，它是看不见摸不着的逻辑产品。
软件开发人员（或开发小组）的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比一般产品的开发过程更难于评价和管理。
为了提高软件开发过程的可见性，更好地进行管理，应该根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。
6．开发小组的人员应该少而精
这条基本原理的含义是，软件开发小组的组成人员的素质应该好，而人数则不宜过多。
开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。
素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍，而且素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件中的错误。
此外，随着开发小组人员数目的增加，因为交流情况讨论问题而造成的通信开销也急剧增加。
当开发小组人员数为N时，可能的通信路径有N（N一1）／2条，可见随着人数N的增大，通信开销将急剧增加。
因此，组成少而精的开发小组是软件工程的一条基本原理。
7．承认不断改进软件工程实践的必要性
遵循上述六条基本原理，就能够按照当代软件工程基本原理实现软件的工程化生产，但是，仅有上述六条原理并不能保证软件开发与维护的过程能赶上时代前进的步伐，能跟上技术的不断进步。
因此，Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条基本原理。
按照这条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验，例如，收集进度和资源耗费数据，收集出错类型和问题报告数据等等。
这些数据不仅可以用来评价新的软件技术的效果．而且可以用来指明必须着重开发的软件工具和应该优先研究的技术。
§1.3软件生存期
软件生存期又称软件生命周期，是指一个软件系统从目标提出到最后丢弃的整个过程。
软件工程基本原理强调软件生命周期的阶段性，其基本思想是各阶段任务相对独立，具有明确的完成标志。
阶段的划分使得人员分工职责清楚，项目进度控制和软件质量得到确认。
原则上，前一阶段任务的完成是后一阶段工作的前提和基础；而后一阶段的任务则是对于前一阶段问题求解方法的具体化。
为了描述软件生存期的活动，提出了多种生存期模型：
例如：
瀑布模型、循环模型、演化模型、螺旋模型等。
整个软件生命周期可以划分为三个阶段，即软件定义、系统实现和运行维护。
一般用经典的瀑布模型来描述。
瀑布模型如图所示。
GB8567中规定，软件生命周期分为7个阶段：
1、可行性研究和项目开发计划
2、需求分析 3、概要设计
4、详细设计 5、编码
6、测试 7、维护
在大部分文献中将生存周期划分为5个阶段，即要求定义、设计、编码、测试及维护。
其中要求定义阶段包括可行性研究和项目开发计划、需求分析，设计阶段包括概要设计和详细设计。
下面扼要地介绍一下软件生存周期每个阶段的基本任务和结束标准。
一、问题定义
问题定义阶段必须回答的关键问题是：
“要解决的问题是什么?
”因此，分析员通过对系统的实际用户和使用部门负责人的访问调查，扼要地写出他们对问题的理解，并在用户和使用部门负责人的会议上认真讨论这份书面报告，澄清含糊不清的地方，改正理解不正确的地
方，最后得到一份双方都满意的文档，此文档中系统分析员应该写明问题的性质、工程目标和规模。
问题定义阶段是软件生存周期中最简短的阶段，一般只需一天甚至更少的时间。
二、可行性研究
此阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解决，
是否有可行的解决办法。
在这个阶段，系统分析员应该导出系统的高层逻辑模型，并且在此基础上更准确、更具体地确定工程规模和目标。
然后分析员更准确地估计系统的成本和效益，对建议的系统进行仔细的成本／效益分析，这是这个阶段的主要任务之一。
可行性研究的结果是使用部门负责人做出是否继续进行这项工程的决定的重要依据。
三、需求分析
这个阶段的任务，主要是确定目标系统必须具备哪些功能。
因此，系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。
通常用数据流图根据字典和简要的算法描述表示系统的逻辑模型。
需求分析阶段确定的系统逻辑模型，是以后设计和实现目标系统的基础，因此必须准确完整地体现用户的要求。
四、总体设计
这个阶段必须回答的关键问题是：
“应该如何解决这个问题?
”
首先应该考虑几种可能的解决方案，一般包括：
1．低成本的解决方案。
系统只能完成最必要的工作，不能多做一点额外的工作。
2．中等成本的解决方案，这样的系统不仅能够很好地完成预定的任务，使用起来很方便，而且可能还具有用户没有具体指定的某些功能和特点。
3．高成本的“十全十美”的系统。
这样的系统具有用户可能希望有的所有功能和特点。
系统分析员应该使用系统流程图或其他工具描述每种可能的系统，估计每种方案的成本和效益；还应该在充分权衡各种方案利弊的基础上，推荐一个较好的系统，并且制定实现所推荐的系统的详细计划。
要完成上述任务，通常采用结构设计的一条基本原理就是程序应该模块化，因此，总体设计还应设计软件的结构，通常用软件结构图表示。
五、详细设计
详细设计阶段的任务就是把解法具体化，设计出程序的详细规格说明，包括必要的细节，
程序员可以根据它们写出实际的程序代码。
通常用程序流程图，N—S图，PAD图，}{IPO图或PDI_．语言描述详细设计的结果。
六、编码和单元测试
这个阶段的任务是程序员根据目标系统的性质和实际环境，选取一种适当的高级程序设
计语言（必要时用汇编语言），把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。
程序员在书写程序模块时，应使它的可读性、可理解性和可维护性良好。
七、综合测试
这个阶段的任务是通过各种类型的测试，使软件达到预定的要求。
最基本的测试是集成测试和验收测试。
集成测试是根据设计的软件结构，把经单元测试的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。
验收测试是按照需求规格说明书的规定，由用户对目标系统进行验收。
通过对软件测试结果的分析可以预测软件的可靠性；反之，根据对软件可靠性的要求也可以决定测试和调试过程什么时候可以结束。
在进行测试的过程中，应该用正式的文档把测试计划、详细测试方案以及实际测试结果保存下来，作为软件配置的一部分。
八、软件维护
维护阶段的任务，是通过各种必要的维护活动使系统持久地满足用户的需要。
通常维护活动有四类：
改正性维护，即诊断和改正在系统使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化；完善性维护，即根据用户的要求改进或扩充软件使它更完善；预防性维护，即修改软件为将来的维护活动预先做准备。
每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。
软件的生存周期划分为上述8个阶段，前3个阶段称为软件的定义阶段，第4至第7个阶段称为软件的开发阶段，最后一个阶段称为软件的维护阶段。
在软件开发期间，测试的工作量最大，约占总开发量的40％；而软件的维护阶段周期最长，工作量非常大。
软件系统的研制工作，不可能是直线进行，研制人员常常需从后面阶段回复到前面。
为了减少返工现象，研制人员通常在各个阶段进行阶段复审，以确保研制工作顺序进行。
在软件生存周期的各个阶段完成研制任务后，应提交各阶段的格式文档资料。
§1.4软件工程方法学
软件开发的目标就是在规定的投资和时间限制内，开发出符合用户需求的高质量软件。
软件开发是一种高智能的活动，必须用软件工程的方法和技术指导软件开发的全过程。
1.4.1软件工程方法学
已经提出的各种软件开发方法和技术，对软件工程的发展和软件产业的进步，起到了不可估量的积极作用。
各种的开发方法和技术可归纳为三大类：
瀑布型模型、原型化模型和变换型。
一、软件开发的瀑布型模型
严格按照软件生命周期的阶段划分，顺序执行各阶段构成软件开发的瀑布型模型，。
瀑布模型的特点是：
1．阶段间具有顺序性和依赖性
顺序性要求每个阶段工作开始的前提是其上一阶段工作结束。
因此前一阶段输出的文档就是其后一阶段的输入文档。
依赖性是指各阶段工作正确性依赖与上一阶段工作的正确性。
因此当某一阶段的工作出现问题时不仅要考察本阶段的工作，还必须追溯前面阶段的工作。
2．推迟实现的观点
软件开发失败的许多实例都是软件人员急于系统编码实现。
编码开始的越早，项目完成的时间很可能越长。
这是因为过早进入编码往往意味着大量的返工。
因此瀑布型模型明确要求在项目前期，即需求分析和总体设计阶段只考虑系统的逻辑模型，不涉及系统物理实现。
即详细设计，其重点也是数据结构与算法设计，要求仅仅用图形或者伪码描述。
因此，直到设计结束，软件开发人员考虑的主要是系统逻辑实现模型。
将系统逻辑设计与物理实现严格分开，尽可能的推迟物理实现，这是瀑布型模型的一个重要指导思想。
3．质量保证的观点
为保证软件开发质量，瀑布型模型在生命周期的各阶段强调：
第一，制作规定的文档是各阶段完成的里程碑，没有交出合格的文档也就没有完成该阶段的任务。
完整、准确的文档即是软件开发过程中各类人员之间相互通信的媒介，也是将来软件维护的重要依据。
进度管理和软件管理也是阶段评审的对象和依据。
第二，每个阶段结束之前都必须对完成的文档进行评审，以便及早发现问题，改正错误。
愈是早期潜伏的故障，暴露的时间愈晚，则排除该故障付出的代价愈高。
对每阶段文档的评审，是保证软件质量，降低软件成本的重要措施。
隐含在瀑布型模型各阶段任务后面的指导思想和观点是软件工程的根本性质。
只要在软件开发中明确这些观点，才能将软件开发与程序设计区别开来，才能在软件开发中发挥主动性和自觉性，使软件工程方法得到恰当的应用。
瀑布型模型是60～70年代为克服软件危机提出的主要软件开发模型，它在纠正软件开发人员的错误观点，认识软件开发与程序设计的本质区别，在克服软件危机方面能起到一定作用。
对于技术成熟的项目开发应用瀑布型模型是十分有效的。
但是对于有一定技术风险的项目，人们的认识不可能在项目早期阶段就完全符合客观实际。
软件生命周期的每个阶段都可能犯错误，完全按照瀑布型模型的阶段划分进行软件开发，前一阶段遗留的错误必然导致后一阶段工作结果中也存在相应错误。
在软件生命周期的各阶段中的错误会积累放大。
所谓“瀑布”即是指错误传递的“瀑布”，为发现和改正错误必须向前的追溯。
因此，在工程实践中，许多严格按照瀑布型模型开发的项目常常交付的是“遗憾的”系统。
二、原型化开发模型
瀑布型模型的缺陷在于软件开发阶段推进是直线型的，工程实践说明这是一个“理想化”模型，不完全符合人们认识问题的规律。
只有当分析员能够做出完整准确的需求分析时软件开发才可能少走弯路。
不幸的是，在软件计划时期定义的用户需求常常是不完全和不准确的。
软件开发初期，分析员对用户业务领域的了解往往并不深入。
许多用户对于“计算机可以做什么?
目标系统应该实现那些功能?
”通常只有一个总体的，轮廓并不分明的要求。
有人断言：
“对软件产品的某个版本试用之前，要求用户（即使有软件工程师配合）完全，精确和正确地对该产品提出确切地需求，在实际上是不可能的。
”在硬件产品开发中，常常先设计实现一个产品原型（即所谓“样机”）。
这样可以对“样机”的各功能、性能进行评价，测试。
通过对“样机”的不断修改完善，成功后再投人批量生产。
借助这种产品开发模式，在事先不能完整准确定义需求的软件开发时，提出了软件产品的原型化开发方法。
其主要思想是：
先建立一个能够反映用户需求的原型系统（“样机”），使得用户和开发者可以对目标系统的概貌进行评价、判断。
然后对原型进行若干轮反复的扩充、改进、求精，最终建立完全符合用户需求的目标系统。
原型化开发过程如图1.2所示。
初始原型可以非常简单，它只实现未来系统的主要功能，系统主要模块之间的重要接口。
初始原型主要用于向用户展示系统功能概貌。
确认开发人员对系统主要功能的理解。
对系统应该具备的功能的演示运行通常可以对用户与开发人员之间的沟通起到催化剂作用，确立用户对项目开发的信心。
基于初始原型的评价可以建立实验性进化原型。
利用实验性进化原型可以不断激发好的设计思想，对用户具体需求进行确认和补充，对系统的关键性能细节（如数据采样的精度与实时性能，数据通信的可靠性，资源冲突的处理策略等）进行评价优化。
实验性进化原型的建立是一个逐步迭代的增量过程，每次迭代的新版本应该具有更强的功能，更优的性能。
当实验性进化原型得到最终确认以后，开发进入目标系统的实现阶段：
将原型转换为完全符合系统运行环境要求的目标系统，并进行最终集成和验收测试。
一个项目的原型系统与目标系统主要区别是：
原型的每次实现要求“快”，成本要低。
原型通常是用适当的软件工具（例如第四代语言）快速实现的。
对于系统实现的枝节问题，例如系统的出错处理，系统支持、运行资源开销优化问题等在原型中可以不作过多考虑。
而目标系统可能要求精雕细刻，反复求精。
由原型转化为目标系统的途径有：
（1）抛弃原型法：
建立原型系统的目的主要是准确定义系统需求，严格验证方案设计。
原型使用完毕后抛弃，然后在重新建立目标系统。
应用抛弃原型法建立原型的过程相当于瀑布型模型的需求分析和总体设计过程。
（2）演化原型法：
目标系统是对实验性原型不断扩充、完善迭代的结果。
每次迭代都要求再分析、再设计、再实现以及再测试评价。
当认为问题求解基本满意时就可以交付系统的初始版本了。
演化原型法的实施要求用户和开发人员在一个相当长的时期中对信息交流和系统修改持一种开放的态度。
许多面向市场的软件产品采用所谓β版发布，就是施行演化原型法开发的一种策略。
瀑布型模型中推迟实现的观点要求软件开发人员与用户之间反复地“纸上谈兵”。
相比之下，“快速”原型实现的要求则是“真枪实弹”。
通过原型运行，用户能够容易地判断它是否真正满足自己的
升级会员 