ch3-软件工程需求工程课件

上传人:风*** 文档编号:240745892 上传时间:2024-05-04 格式:PPT 页数:88 大小:2.73MB
返回 下载 相关 举报
ch3-软件工程需求工程课件_第1页
第1页 / 共88页
ch3-软件工程需求工程课件_第2页
第2页 / 共88页
ch3-软件工程需求工程课件_第3页
第3页 / 共88页
点击查看更多>>
资源描述
ch3 软件工程需求工程软件工程需求工程56、极端的法规,就是极端的不公。西塞罗57、法律一旦成为人们的需要,人们就不再配享受自由了。毕达哥拉斯58、法律规定的惩罚不是为了私人的利益,而是为了公共的利益;一部分靠有害的强制,一部分靠榜样的效力。格老秀斯59、假如没有法律他们会更快乐的话,那么法律作为一件无用之物自己就会消灭。洛克60、人民的幸福是至高无个的法。西塞罗需求概述n需求的重要性需求的重要性q软件开发的基础和前提软件开发的基础和前提q最终目标软件系统验收的标准最终目标软件系统验收的标准q避免或者尽早剔除早期的错误避免或者尽早剔除早期的错误n需求分析是软件生存期的一个需求分析是软件生存期的一个重要阶段重要阶段,是软件开发,是软件开发项目得以项目得以成功的基础成功的基础。n其最根本的任务是确定为了满足用户的需要,其最根本的任务是确定为了满足用户的需要,“系统系统必须做什么?必须做什么?”的问题。的问题。6需求概述n需求分析的复杂性和面临的困难需求分析的复杂性和面临的困难q片面片面,不完全不完全q模糊模糊,不准确不准确q不一致不一致,歧义歧义q需求复杂和庞大需求复杂和庞大n因此必须使用系统的方法、借助于一系列行之因此必须使用系统的方法、借助于一系列行之有效的技术和工具进行软件需求分析有效的技术和工具进行软件需求分析7需求的重要性nStatistical material:In 1994,the Standish Group surveyed over 350 companies about their over 8000 software projects to find out how well they were faring.The results are sobering.31%of the software projects were canceled before they were completed.Moreover,in large companies,only 9%of the projects were delivered on time and cost what they were budgeted,and 16%met those criteria in small companies(Standish 1994).8需求的重要性nTo understand why,Standish(1995)asked the survey respondents to explain the causes of the failed projects.The top factors were reported to be 1.incomplete requirements(13.1%)2.lack of user involvement(12.4%)3.lack of resources(10.6%)4.unrealistic expectations(9.9%)5.lack of executive support(9.3%)6.changing requirements and specifications(8.7%)7.lack of planning(8.1%)8.system no longer needed(7.5%)9需求的重要性nFive Facts1.软件生命周期中,一个错误发现得越晚,软件生命周期中,一个错误发现得越晚,修复错误的费用越高。修复错误的费用越高。10需求出错的高成本“All together,the results show as much as a 200:1 cost ratio between finding errors in the requirements and maintenance stages of the software lifecycle.”1002.551025.5-1Requirements TimeDesignCodingUnit TestAcceptance TestMaintenanceStageThe 1-10-100 Rule11需求的重要性2.许多错误是潜伏的,并且在错误产生后很长一段许多错误是潜伏的,并且在错误产生后很长一段时间才被检查出来。时间才被检查出来。3.在需求过程中会产生很多错误。在需求过程中会产生很多错误。qDeMarco在一份研究报告中指出,被检查出来的错误的在一份研究报告中指出,被检查出来的错误的56产生的根源可以追溯到需求阶段。产生的根源可以追溯到需求阶段。qAIRMICS所进行的一项调查发现,在一份美国军方大所进行的一项调查发现,在一份美国军方大型管理信息系统的需求现格说明书型管理信息系统的需求现格说明书(SRS)中存在着中存在着500多多个错误,当然这仅仅是一个软件项目中的一次调查。个错误,当然这仅仅是一个软件项目中的一次调查。12需求的重要性4.4.在需求阶段,代表性的错误为疏忽、不一致和在需求阶段,代表性的错误为疏忽、不一致和二义性。二义性。q美国海军研究实验室从美国海军研究实验室从2020世纪世纪7070年代起就对软件开年代起就对软件开发技术不断地进行研究。他们对海军发技术不断地进行研究。他们对海军A A7E7E飞机上飞机上的并行操作程序进行实地测试,以验证许多新设想的并行操作程序进行实地测试,以验证许多新设想的可行性。得出的研究数据表明:的可行性。得出的研究数据表明:A7EA7E项目中项目中7777的需求错误特点是不明确、疏忽、不一致和二义的需求错误特点是不明确、疏忽、不一致和二义性。按错误类型对这些错误分布进行分析的结果是:性。按错误类型对这些错误分布进行分析的结果是:q4949不正确的事实,不正确的事实,3131疏忽,疏忽,l3l3不一致,不一致,5 5二义性。二义性。13需求的重要性5.需求错误是可以被检查出来的需求错误是可以被检查出来的。14发现错误的比例发现错误的比例发现错误的比例发现错误的比例检查检查检查检查单元测试单元测试单元测试单元测试集成测试集成测试集成测试集成测试维护维护维护维护其它其它其它其它65 10 5614发现错误的方法发现错误的方法发现错误的比例()发现错误的比例()15什么是需求工程软件需求作为软件生存周期的第一个阶段,其重要性越来越突出,到20世纪80年代中期,逐步形成了软件工程的子领域需求工程。需求工程:对系统应该提供的服务和所受到的约束进行理解、分析、建立文档、检验的过程16需求工程需求开发需求管理需求开发17需求获取需求分析编写需求规格说明需求确认需求管理18需求跟踪需求变更控制版本管理需求复用需求层次19n业务需求反映企业/组织对软件系统的高层次目标需求,也就是说是软件需求的建设目标。n系统建立的战略出发点,表现为高层次的目标(Objective),它描述了组织为什么要开发系统。n为了满足用户的业务需求,需求工程师需要描述系统高层次的解决方案,定义系统应该具备的特性(Feature)n参与各方必须要对高层次的解决方案达成一致,以建立一个共同的前景(Vision)n特性说明了系统为用户提供的各项功能,它限定了系统的范围(Scope)业务需求20n执行实际工作的用户对系统所能完成的具体任务的期望,描述了系统能够帮助用户做些什么。n通常是在业务需求定义的基础上通过用户访谈、调查,对用户使用的场景进行整理,从而建立用户角度的需求。用户需求是需求捕获的结果。n特性q模糊、不清晰 q多特性混杂 q多逻辑混杂用户需求21n对所有的用户需求,都应该有充分的问题域知识作为背景支持。n用户需求是从用户角度描述的系统功能需求和非功能需求,通常只涉及系统的外部行为,而不涉及系统的内部特性。用户需求22v用户对软件系统行为的期望,一系列的行为联系在一起可以帮助用户完成任务,满足业务需求。v软件需求可以直接映射为系统行为,定义了系统中需要实现的功能,描述了开发人员需要实现什么 v将用户需求转化为软件需求的过程是一个复杂的过程首先需要分析问题领域及其特性,从中发现问题域和计算机系统的共享知识,建立系统的知识模型;然后将用户需求部署到系统模型当中,即定义系列的系统行为,让它们联合起来实现用户需求,每一个系统行为即为一个系统需求。该过程就是需求工程当中最为重要的需求分析活动,又称建模与分析活动。系统需求23软件需求可以分为:功能需求非功能需求设计约束软件需求的三种类型24功能需求描述系统应该提供的功能或服务,通常涉及用户或外部系统与该系统之间的交互,一般不考虑系统的实现细节。传统的需求开发方法中,通常会以软件系统-子系统-模块-子模块的层次结构来组织。现代需求理论更强调需求分析人员从用户的角度,将系统理解为一个黑盒子,从使用角度来整理需求,不管是RUP或者是XP 方法都是如此。功能需求25非功能需求从各个角度对系统的约束和限制,反映了应用对软件系统质量和特性的额外要求,例如响应时间、数据精度、可靠性、开发过程的标准等。一般在软件开发过程中可以将非功能需求划分为:性能需求,质量属性,对外接口等。l 性能需求:速度(Speed)、容量(Capacity)、吞吐量(Throughput)、负载(Load)、实时性(Time-Critical)。l系统为了满足规定的及隐含的所有要求而需要具备的要素称为质量。质量属性是为了度量质量要素而选用的特征。l对外接口是系统和其他系统之间的软硬件接口,以及用户界面。非功能需求26n设计约束一般包括非技术因素决定的技术选型问题,以及预期的软硬件环境,预期的使用环境等。n设计约束非常重要,不要认为是可用可无的。n非技术因素决定的技术选型:对于软件开发而言,有些技术不是由技术团队决定的,而是会受到企业/组织实际情况的影响。例如:必须采用具有自主知识产权的数据库系统,系统开发必须使用J2EE技术等。nLanguage、OS、SW to HW interface、Algorithm、Power、Timing、Memory、Processor utilization设计约束27n有一大学图书馆系统,该系统能够为学生和教工 提供查询和借阅图书和文献资料的服务。因此本系统具备以下功能:基本数据维护功能基本业务功能数据库管理功能信息查询功能例28(1)基本数据维护提供使用者录入、修改并维护基本数据的途径。基本数据包括读者的信息,可以对这些信息进行修改和更新。(2)基本业务功能读者借、还书籍的登记功能,随时根据读者借、还书籍的情况更新数据库系统,如果书籍已经借出,可以进行预留操作以及书籍的编目、入库、更新等操作。1.功能需求29(3)数据库管理功能对所有图书信息及作者信息进行统一管理维护的功能,对书籍的借还也要进行详细的登记,以便协调整个图书馆的运作。(4)信息查询功能提供对各类信息的查询的功能,如对本图书馆的用户借书信息、还书信息、书籍源信息、预留信息等进行查询,对其他图书馆的书籍、资源源的查询。30(1)系统安全性需求为保证系统安全性,对本图书馆的各项功能进行分级、分权限操作。对其他图书馆的查询控制访问范围,如限ID、限用户等。(2)对系统可用性的需求为了方便使用者,要求对所有交互操作提供在线帮助功能。2.非功能需求 31(3)对系统查询速度的要求要求系统在20s内响应查询服务的请求。(4)对系统可靠性需求要求系统失败发生率小于1%。32对“大学图书管理系统”提出一些与图书管理的业务相关的需求:图书编目要求按照中国图书馆分类法进行;由于版权限制,某些文献资料只能在图书馆规定的阅览室阅读,并限制复制和打印。第一条需求是遵循我国图书管理的规定,执行对图书的分类管理的标准。而第二条需求则是版权法对图书馆文献资料的保护的需要,描述了对一类文献资料有限制的使用和服务。3.领域需求33outlinen需求工程概述需求工程概述n需求获取需求获取n需求分析需求分析n需求规格说明书需求规格说明书34需求获取n软件需求分析总是从两方或多方之间的通信开始。用户面临的问题需要用基于计算机的方案来解决;开发者应该对用户的需求作出反应,给用户提供帮助。这样就产生了相互通信的需求。n需求获取的目的是从项目的战略规划开始建立最初的原始需求,需要研究系统将来的应用环境,确定系统的涉众,了解现有的情况,建立新系统的目标,获取为支持新系统目标而需要的业务过程细节和具体的用户需求。35Requirements Elicitation is difficultn用户和开发人员的背景不同,立场不同 q首先是知识理解的困难。n尽力去研究应用的背景,理解组织的状况,形成一个能够和用户进行有效沟通的粗略的知识框架 q默认(Tacit)知识现象 n利用有效的获取方法与技巧(角色扮演、观察等)来发现并获取默认知识 36Requirements Elicitation is difficultn普通用户缺乏概括性、综合性的表述能力q普通用户的知识结构就相对局限于一些具体的业务细节 n善于表达具体业务的细节问题 q专家用户的知识结构因其渊博性而具有概括性和广泛性 n能够回答概括性和综合性的问题 q开发人员在与用户接触之前就先行确定获取的内容主题,然后设计具体的应用环境和场景条件,由用户根据细节业务的执行来描述问题、表达期望。37Requirements Elicitation is difficultn缺乏用户参与 q用户数量太多,选择困难 q用户认识不足,不愿参与 q用户情绪抵制,消极参与 q没有明确的用户 q对系统的用户以及用户的替代源等相关涉众进行分析 38需求获取技术39获取信息的方法 n传统方法 q问卷调查、访谈、硬数据分析、文档检查、需求剥离等 n集体获取方法 q头脑风暴(Brainstorming)、专题讨论会(Workshop)等 n快速建立软件原型n认知方法 q任务分析(Task Analysis)、协议分析(Protocol Analysis)等 n基于上下文的方法 q观察、民族志(Ethnography)和话语分析(Conversation Analysis)40访谈1.正式访谈n系统分析员将提出一些事先准备好的具体问题。2.非正式访谈n分析员将提出一些用户可以自由回答的开放性问题,以鼓励被访问人员说出自己的想法。3.调查表n经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确。414.情景分析技术n对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。情景分析技术的用处:n能在某种程度上演示目标系统的行为,从而便于用户理解,而且还可能进一步揭示出一些分析员目前还不知道的需求。n能保证用户在需求分析过程中始终扮演一个积极主动的角色。让用户起积极主动的作用对需求分析工作获得成功是至关重要的。42快速建立软件原型 n快速建立软件原型是最准确、最有效、最强大的需求分析技术。n快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。n构建原型的要点是,它应该实现用户看得见的功能,省略目标系统的“隐含”功能。43快速原型的特性:快速原型的特性:n“快速”。快速原型的目的是尽快向用户提供一个可在计算机上运行的目标系统的模型。因此,原型的某些缺陷是可以忽略的。n“容易修改”。如果原型的第一版不是用户所需要的,就必须根据用户的意见迅速地修改它,构建出原型的第二版,以更好地满足用户需求。如果修改耗时过多,势必延误软件开发时间。44outlinen需求工程概述需求工程概述n需求获取需求获取n需求分析需求分析n需求规格说明书需求规格说明书45Objectives of Software Analysis46n需求分析的目的是保证需求的完整性和一致性。以需求获取阶段的原始需求和业务过程细节出发,将目标、功能和约束映射为软件行为,建立系统模型系统模型,然后在抽象后的系统模型中进行分析,标识并修复其中存在的不一致问题,发现并弥补遗漏的需求。47Tasks of Software Analysis48Software ModelnA model is an abstract representation of a system that enables us to answer questions about the system.qWhen we represent it with real world language,its user modelqWhen we represent it with computing world language,its design modelqWhen we represent it with codes,its program modelqWhen we represent it with a neutral,formal language,its analysis modelq49Different means of“model”in SEnGeneral knowledgeqSoftware modelnA view of general knowledgeqViewpoint:design model,analysis modelqContent type:data model,function modelnA perspective language and its usageqE-R model,UML model,DFD modelnProcess model?50Software modelingnSoftware modeling is the process of developing abstract models of a system,with each model presenting a different view or perspective of that system.nSoftware modeling has now come to mean representing a system using some kind of graphical notation,which is now almost always based on notations in the Unified Modeling Language(UML).nSoftware modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers.,51nEntity-Relationship DiagramqComposition(semantic data)modelnUMLqObject diagram nClassification model qBehavioral diagramqOCLqUse case diagramnProcess Model(DFD)qData processing modelnState Machine ModelqStimulus/response modelnFact ModelnEntity-event modelnObject Role ModelnOrganization modelnPetri Netsn52Notation,Technology,Method,ToolnNotationqGraphic mapping of one or many technique modelsqFor example,UMLnTechnology qModeling things using notationsqFor example,Object modelingnMethodqApproach to solve problem of modeling,composite of many technologiesqFor example,OOAnMethodologyqA world view to do different workqFor example object-oriented methodologynToolqSoftware system which support at least one notation or technologyqFor example,Rational Rose53Common analysis technologies and methodsnStructure analysisqDFD,ERD,ORM,STDnInformation engineeringqA special structure analysis method for information systemsqFDD,DD,BPM,besides abovenObject-Oriented analysisqUML54nMethod Based Analysis(In historical order,we have)qNone Methodn“Traditional”analysis(1950s)qStructured MethodnClassical Structured Analysis(late 1960s)n“Modern”Structured Analysis(late 1970s)nInformation Engineering(late 1980s)qOO MethodnObject Oriented Analysis(1990s)Approaches to analysis55DFD1960s“Classical”Structured Analysis“Modern”Structured AnalysisERDData separatedEvent separatedFSM,STDInformation EngineeringAdjust for IEFDD,DDlate of 1970s1980sBPMBPR1990sELHOOUMLORMPNRules separatedWorkflowNowFMEnterprise ModelFutureOntology?OOAGoal ModelDomain Model56Technique Models VS Analysis TechnologiesEntity-relationship modelObject modelProcess modelState machine modelOthersERDUMLDFDFDD,DDFSMSC,STDDecision Table(tree),Structured EnglishAction diagram,Data dictionaryGraspGraspKnowUnderstandGraspUnderstandUnderstandKnowNone:Goal Model,Enterprise Model,Domain Model57结构化建模思想n怎么理解复杂世界?q复杂简单(分解)n简单可理解性(最基本单位)n简单(高内聚)n简单 VS 简单(低耦合)q简单复杂(接口和实现)n结构化建模q复杂世界复杂处理过程(事情的发生发展)q简单过程(可表达的“函数”)n软件“函数”、程序q复杂简单n功能分解结构q简单复杂(函数调用)58结构化分析n结构化分析(Structured Analysis,SA)是一种确定模型的活动。nSA用抽象模型的概念,按照软件内部数据传递、变换的关系,自顶向下逐层功能分解的系统分析方法来定义系统的需求。59Structured Analysis(SA)Context DiagramsData Flow DiagramsData DictionariesEntity-Relation DiagramModule Hierarchy(FDD,PDD/DD)Mini-SpecificationStructured Analysis(SA)60分析模型的结构分析模型的结构nSA应该建立应该建立3种种模型,分别是:模型,分别是:q数据模型数据模型q功能模型功能模型q行为模型行为模型 61数据建模n数据模型包含三种相互关联的信息:数据对象、描述数据对象的属性及数据对象彼此间相互连接的关系。n最常用的表示概念性数据模型的方法,是实体联系方法(Entity-Relationship Approach)nER图描述现实世界中的实体,而不涉及这些实体在系统中的实现方法。62E-R图元素63 Entities 例:例:,StudentInstructorClass 实体是客观世界中存在的且可相互区分的事务。实体可以是人也可以是物,可以是具体的事物也可以是抽象概念。例如,职工、学生、课程、教师等都是实体。E-R图元素n属性是实体或联系所具有的性质,通常一个实体由若干个属性来刻画。应该根据对所要解决的问题的理解,来确定特定数据对象的一组合适的属性。n例如,“学生”实体有学号、姓名、性别、系、年级64(2)Attributes 例:例:,NameI D#E-R图元素n实体彼此之间相互连接的方式称为关系,也称为联系。n(1)一对一联系(11),(2)一对多联系(1N)n(3)多对多联系(MN)n例如,教师与课程间存在“教”这种联系。65(3)Relations 例:例:Enrolled inTeach111NMN某校教学管理系统的E-R图66InstructorStudentEnrolled inTeachCourseI D#I D#NameNamegendergenderTitleInstructor IDClass IDGradeStudent IDClass IDCreditI D#Subject1NMN例:银行储蓄系统的ER图 银行计算机储蓄系统的工作过程大致如下:n储户填写的存款单或取款单由业务员键入系统,如果是存款则系统记录存款人姓名、住址(或电话号码)、身份证号码、存款类型、存款日期、到期日期、利率及密码(可选)等信息,并印出存单给储户;n如果是取款而且存款时留有密码,则系统首先核对储户密码,若密码正确或存款时未留密码,则系统计算利息并印出利息清单给储户。67银行储蓄系统的银行储蓄系统的ER图图 68变换变换输入信息输入信息输出信息输出信息外部实体外部实体外部实体外部实体外部实体外部实体输入信息输入信息外部实体外部实体外部实体外部实体输出信息输出信息输出信息输出信息数据存储数据存储系统逻辑模型系统逻辑模型功能建模(DFD)69DFDn数据流图说明(Yourdon表示):q 表示外部实体,代表数据源和数据目的地q 表示加工,代表接收输入,经过变换,继而产生输出的处理过程。q 表示数据流,代表数据的流向和路径。q 表示数据存储,代表系统加工的数据所存储的地方。70外部实体外部实体变换变换数据存储数据存储人事工资管理系统人事工资管理系统71系统逻辑模型系统逻辑模型人事工资管理系统人事工资管理系统1层层DFD图图72人事工资管理系统2层DFD:功能3分解图7374n在多层数据流图中,顶层流图仅包含一个加工,它代表被开发系统。它的输入流是该系统的输入数据,输出流是系统所输出数据n底层流图是指其加工不需再做分解的数据流图,它处在最底层n中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化,形成子图。75数据字典nDD是对所有与系统相关的数据元素的一个有组织的列表,以及精确的、严格的定义,使得用户和系统分析员对于输入、输出、存储成分和中间计算有共同的理解。n数据字典的任务是:对于数据流图中出现的所有被命名的图形元素在字典中作为一个词条加以定义,使得每一个图形元素的名字都有一个确切的解释。76数据字典举例:数据库表77数据字典举例:数据库表78数据字典举例:数据库表79数据字典举例:数据库表80Example:data dictionary descriptionnWe define telephone no.as follows:qtelephone no.=local extension|outside no.|0 qLocal extension=30-93qoutside no.=9+service code|domestic no.qservice code=110|120|qdomestic no.=(0)+area code)+local numberqarea code=30-93qLocal number=80-9881outlinen需求工程概述需求工程概述n需求获取需求获取n需求分析需求分析n需求规格说明书需求规格说明书82软件需求规格说明 n通过需求分析除了创建分析模型之外,还应该写出软件需求规格说明书,它是需求分析阶段得出的最主要的文档。n需求规格说明的目的是将完整、一致的需求与能够满足需求的软件行为以文档的方式明确地固定下来。在文档中,可以使用非形式化的文本进行描述,也可以用半形式化的图形语言进行描述(如UML),还可以采用形式化的语言进行描述。n通常描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。83GB856D-1988国家标准,需求规格说明的内容框架:国家标准,需求规格说明的内容框架:84Case Analysis 385江苏省二代身份证人像采集系统需求规格说明书江苏省二代身份证人像采集系统需求规格说明书 HX-2DZ-1000产品需求规格说明书产品需求规格说明书-V1.0习题1ER图练习题:图练习题:n请为某仓库的管理设计一个请为某仓库的管理设计一个ER模型。该仓库模型。该仓库主要管理零件(包括零件编号、名称、颜色、主要管理零件(包括零件编号、名称、颜色、重量)的定购和供应等事项。仓库向工程项目重量)的定购和供应等事项。仓库向工程项目(包括项目编号、项目名称、开工日期)供应(包括项目编号、项目名称、开工日期)供应零件,并且根据需要向供应商(包括供应商编零件,并且根据需要向供应商(包括供应商编号、名称、地址)定购零件。号、名称、地址)定购零件。86习题2DFD图练习题:图练习题:某个学生成绩管理系统的部分功能如下:某个学生成绩管理系统的部分功能如下:(1)基本信息管理:教务管理人员输入或修改学期教学)基本信息管理:教务管理人员输入或修改学期教学执行计划、学生名单和教师名单;执行计划、学生名单和教师名单;(2)学生选课:学生根据教学执行计划进行选课;)学生选课:学生根据教学执行计划进行选课;(3)分配任课教师:教务管理人员为符合开课条件的课)分配任课教师:教务管理人员为符合开课条件的课程分配教师,并打印任课通知单给教师;程分配教师,并打印任课通知单给教师;(4)成绩管理:每门课程的教师在考试评分结束后将考)成绩管理:每门课程的教师在考试评分结束后将考试成绩交给教务管理人员,教务管理人员输入、维护成绩,试成绩交给教务管理人员,教务管理人员输入、维护成绩,系统可生成成绩单(发给学生)、成绩统计分析表(发给教系统可生成成绩单(发给学生)、成绩统计分析表(发给教务管理人员)。务管理人员)。请使用请使用SA方法画出该问题的分层方法画出该问题的分层DFD图(要求画出顶层图(要求画出顶层和和1层层DFD图)。图)。8766、节制使快乐增加并使享受加强。德谟克利特67、今天应做的事没有做,明天再早也是耽误了。裴斯泰洛齐68、决定一个人的一生,以及整个命运的,只是一瞬之间。歌德69、懒人无法享受休息之乐。拉布克70、浪费时间是一桩大罪过。卢梭
展开阅读全文
相关资源
相关搜索

最新文档


当前位置:首页 > 办公文档 > 教学培训


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!