公司计算机软件培训文件_第1页
公司计算机软件培训文件_第2页
公司计算机软件培训文件_第3页
公司计算机软件培训文件_第4页
公司计算机软件培训文件_第5页
已阅读5页,还剩19页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、XX公司计算机软件培训讲义1、背景20世纪是一个革命化变革的世纪。机械化革命、电气化革命、信息化革命不管是对社会依旧对人类都起到了全然性的变化阻碍。特不是自动化生产的理念,对机械化革命、电气化革命和信息化革命中的骨骼部分(硬件产品:例如计算机及其相关部件、通信产品、存储介质等)都起到了突飞猛进的推动作用。但关于信息化革命中的神经或血液部分的软件,如何将自动化生产的理念引入到其开发研制中来,是20世纪60年代以来给人类留下的始终未解决好的一个重大课题。20世纪80年代初,国际闻名的软件学家布鲁思曾经发表过一片闻名的论文没有银弹,在软件界引起了专门大的震动。论文的中心散布了一种软件悲观论的思想,布

2、鲁思个人认为软件的自动化生产,由于受各种外界条件的制约,是几乎无法实现的。这种悲观的事实虽完全解决不了,但通过软件工程及其相关联的优秀的方法论,通过优秀的人才是能够缓解的。在以后的信息化革命中,起着神经或血液角色的软件作用越来越重要,据国际权威调查机构的资料,工程费用上软硬的比例目前已达到了6:4的数值。由此可见软件工程及其相关联的优秀的方法论、优秀的软件人才在信息化革命革命中的重要性。2、软件工程软件工程是一类工程。工程是将理论和知识应用于实践的科学。就软件工程而言,它借鉴了传统工程的原则和方法,以求高效地开发高质量软件。其中应用了计算机科学、数学和治理科学。计算机科学和数学用于构造模型与算

3、法,工程科学用于制定规范、设计范型、评估成本及确定权衡,治理科学用于打算、资源、质量和成本的治理。 软件工程这一概念,要紧是针对20世纪60年代“软件危机”而提出的。它首次出现在1968年NATO(北大西洋公约组织)会议上。自这一概念提出以来,围绕软件项目,开展了有关开发模型、方法以及支持工具的研究。其要紧成果有:提出了瀑布模型,开发了一些结构化程序设计语言(例如PASCAL语言,ADA语言)、结构化方法等。同时围绕项目治理提出了费用估算、文档复审等方法和工具。综观60年代末至80年代初,其要紧特征是,前期着重研究系统实现技术,后期开始强调开发治理和软件质量。70年代初,自“软件工厂”这一概念

4、提出以来,要紧围绕软件过程以及软件复用,开展了有关软件生产技术和软件生产治理的研究与实践。其要紧成果有:提出了应用广泛的面向对象语言以及相关的面向对象方法,大力开展了计算机辅助软件工程的研究与实践。尤其是近几年来,针对软件复用及软件生产,软件构件技术以及软件质量操纵技术、质量保证技术得到了广泛的应用。目前各个软件企业都十分重视资质认证,并想通过这些工作进行企业治理和技术的提升。软件工程所涉及的要素可概括如下:软件工程框架图依照这一框架,能够看出:软件工程涉及了软件工程的目标、软件工程原则和软件工程活动。软件工程的要紧目标是:生产具有正确性、可用性以及开销合宜的产品。正确性意指软件产品达到预期功

5、能的程度。可用性指软件差不多结构、实现及文档为用户可用的程度。开销合宜性是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上依旧在实践中均存在专门多问题有待解决,它们形成了对过程、过程模型及工程方法选取的约束。 软件工程的四项差不多原则是:第一,选取适宜开发范型。该原则与系统设计有关。在系统设计中,软件需求、硬件需求以及其他因素之间是相互制约、相互阻碍的,经常需要权衡。因此,必须认识需求定义的易变性,采纳适宜的开发范型予以操纵,以保证软件产品满足用户的要求。 第二,采纳合适的设计方法。在软件设计中,通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合

6、适的设计方法有助于这些特征的实现,以达到软件工程的目标。 第三,提供高质量的工程支持。“工欲善其事,必先利其器”。在软件工程中,软件工具与环境对软件过程的支持颇为重要。软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。 第四,重视开发过程的治理。软件工程的治理,直接阻碍可用资源的有效利用,生产满足目标的软件产品,提高软件组织的生产能力等问题。因此,仅当软件过程得以有效治理时,才能实现有效的软件工程。 软件工程活动是“生产一个最终满足需求且达到工程目标的软件产品所需要的步骤”。要紧包括需求、设计、实现、确认以及支持等活动。需求活动包括问题分析和需求分析。问题分析猎取需求定义,又

7、称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件体系结构,包括子系统、模块以及相关层次的讲明、每一模块接口定义。详细设计产生程序员可用的模块讲明,包括每一模块中数据结构讲明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程,实现完成后的确认,保证最终产品满足用户的要求。支持活动包括修改和完善。伴随以上活动,还有治理过程、支持过程、培训过程等。这一软件工程框架告诉我们,软件工程的目标是可用性、正确性和合算性;实施一个软件工程要选取适宜的开发范型,要采纳合适的设计方法,要提供高质量的工程支撑,要实行开发过程的有效治理;软件

8、工程活动要紧包括需求、设计、实现、确认和支持等活动,每一活动可依照特定的软件工程,采纳合适的开发范型、设计方法、支持过程以及过程治理。依照软件工程这一框架,软件工程学科的研究内容要紧包括:软件开发范型、软件开发方法、软件过程、软件工具、软件开发环境、计算机辅助软件工程(CASE) 及软件经济学等。 自从软件工程概念提出以来,通过30多年的研究与实践,尽管“软件危机”没得到完全解决,但在软件开发方法和技术方面差不多有了专门大的进步。尤其应该指出的是,自80年代中期,美国工业界和政府部门开始认识到,在软件开发中,最关键的问题是软件开发组织不能专门好地定义和治理其软件过程,从而使一些好的开发方法和技

9、术都起不到所期望的作用。也确实是讲,在没有专门好定义和治理软件过程的软件开发中,开发组织不可能在好的软件方法和工具中获益。 依照调查,中国的现状几乎和美国10多年前的情况一样,软件开发过程没有明确规定,文档不完整,也不规范,软件项目的成功往往归功于软件开发组的一些杰出个人或小组的努力。这种依靠于个不人员上的成功并不能为全组织的软件生产率和质量的提高奠定有效的基础,只有通过建立全组织的过程改善,采纳严格的软件工程方法和治理,同时坚持不懈地付诸实践,才能取得全组织的软件过程能力的不断提高。这一事实告诉我们,只有坚持软件工程的四条差不多原则,既重视软件技术的应用,又重视软件工程的支持和治理,并在实践

10、中贯彻实施,才能高效地开发出高质量的软件。3、方法论如何运用软件工程,从20世纪70年代初开始,围绕着那个问题,诞生了许多闻名的方法论。下面对几个典型的方法论进行简单的介绍。3.1、瀑布式方法论瀑布模型将软件生命周期的各项活动规定为依固定顺序联接的若干时期工作,形如瀑布流水,最终得到软件产品。优点:强调开发的时期性;强调早期打算及需求调查;强调产品测试。 缺点:依靠于早期进行的唯一的一次需求调查,不能适应需求的变化;由因此单一流程,开发中的经验教训不能反馈应用于本产品的过程;风险往往迟至后期的开发时期才显露,因而失去及早纠正的机会。 其中,BD是Basic Design的缩写,这一部分完成“本

11、系统要做什么”的文档记录工作,即系统的分析时期工作;FD是Function Design的缩写,这一部分完成本系统功能块的划分,是“如何去做”的第一时期工作,即系统的设计初期时期工作;DD是Detail Design的缩写,这一部分完成本系统各个功能模块的详细设计工作,是编程时期的预备设计时期;MK是Making的缩写,即具体编程实施时期;UT是Unit Test的缩写,即单元测试时期;CT是Combine Test的缩写,即结合测试时期;ST是System Test的缩写,即系统测试时期;PT是Product Test的缩写,即商品测试时期。从上图中能够看出,BD和PT、 FD和ST、DD和

12、CT、MK和UT差不多上成对出现的。每一对的前一部分完成之后,应该立即着手后一部分的文档制作工作。对较大的系统开发,实际测试和文档的担当者应该不同。3.2、生鱼片式方法论前一时期完成70%到80%时,即可并行进入到下一个时期。3.3、螺旋式方法论瀑布模型与演化模型相结合,并加入两者所忽略的风险分析所建立的一种软件开发模型。该模型于1998年由美国TRW公司(B.W.Boehm)提出。软件项目风险的大小作为指引软件过程的一个重要因素,引入这一概念有可能使得软件开发被看作一种元模型,因为它能包容任何一个开发过程模型。螺旋模型差不多的做法是在“瀑布模型”的每一个开发时期之前,引入特不严格的风险识不、

13、风险分析和风险操纵。直到采取了消除风险的措施之后,才开始打算下一时期的开发工作。否则,项目就专门可能被取消。 另外,假如有充足的把握推断遗留的风险已降低到一定的程度,项目治理人员可作出决定让余下的开发工作采纳另外的生命周期模型,如“演化模型”,“瀑布模型”,或自定的混合模型。 优点: 强调严格的全过程风险治理。强调各开发时期的质量。提供机会检讨项目是否有价值接着下去。 缺点: a.引入特不严格的风险识不,风险分析,和风险操纵,这对风险治理的技能水平提出了专门高的要求。这需要人员,资金,和时刻的投入。 3.4、时期性公布式方法论该模型要紧针对事先不能完整定义需求的软件开发。用户能够给出待开发系统

14、的核心需求,同时当看到核心需求实现后,能够有效地提出反馈,以支持系统的最终设计和实现。软件开发人员依照用户的需求,首先开发核心系统。当该核心系统投入运行后,用户试用之,完成他们的工作,并提出精化系统、增强系统能力的需求。软件开发人员依照用户的反馈,实施开发的迭代过程。第一迭代过程均由需求、设计、编码、测试、集成等时期组成,为整个系统增加一个可定义的、可治理的子集。下面为生鱼片型时期性公布式方法论图示。在开发模式上采取分批循环开发的方法,每循环开发一部分的功能,它们成为那个产品的原型的新增功能。因此,设计就不断地演化出新的系统。 实际上,那个模型可看作是重复执行的多个“生鱼片方式”。 3.5、B

15、ooch方法论Booch方法的过程包括以下步骤:在给定的抽象层次上识不类和对象识不这些对象和类的语义识不这些类和对象之间的关系实现类和对象这四种活动不仅仅是一个简单的步骤序列,而是对系统的逻辑和物理视图不断细化的迭代和渐增的开发过程。类和对象的识不包括找出问题空间中关键的抽象和产生动态行为的重要机制。开发人员能够通过研究问题域的术语发觉关键的抽象。语义的识不要紧是建立前一时期识不出的类和对象的含义。开发人员确定类的行为(即方法)和类及对象之间的互相作用(即行为的规范描述)。该时期利用状态转移图描述对象的状态的模型,利用时态图(系统中的时态约束)和对象图(对象之间的互相作用)描述行为模型。在关系

16、识不时期描述静态和动态关系模型。这些关系包括使用、实例化、继承、关联和聚拢等。类和对象之间的可见性也在现在确定。在类和对象的实现时期要考虑如何用选定的编程语言实现,如何将类和对象组织成模块。在面向对象的设计方法中,Booch强调基于类和对象的系统逻辑视图与基于模块和进程的系统物理视图之间的区不。他还区不了系统的静态和动态模型。然而,他的方法偏向于系统的静态描述,对动态描述支持较少。Booch方法的力量在于其丰富的符号体系,包括:类图(类结构静态视图)对象图(对象结构静态视图)状态转移图(类结构动态视图)时态图(对象结构动态视图)模块图(模块体系结构)进程图(进程体系结构)用于类和对象建模的符号

17、体系使用注释和不同的图符(如不同的箭头)表达详细的信息。Booch建议在设计的初期能够用符号体系的一个子集,随后不断添加细节。对每一个符号体系还有一个文本的形式,由每一个要紧结构的描述模板组成。符号体系由大量的图符定义,然而,其语法和语义并没有严格地定义。3.6、OMT方法论Rumbaugh的OMT方法从三个视角描述系统,相应地提供了三种模型,对象模型,动态模型和功能模型。对象模型描述对象的静态结构和它们之间的关系。要紧的概念包括:类属性操作继承关联(即关系)聚拢动态模型描述系统那些随时刻变化的方面,其要紧概念有:状态子状态和超状态事件行为活动功能模型描述系统内部数据值的转换,其要紧概念有:加

18、工数据存储数据流操纵流角色(源/潭)该方法将开发过程分为四个时期:分析基于问题和用户需求的描述,建立现实世界的模型。分析时期的产物有:问题描述对象模型对象图数据词典动态模型状态图全局事件流图功能模型数据流图约束系统设计结合问题域的知识和目标系统的体系结构(求解域),将目标系统分解为子系统。该时期的要紧产物是系统设计文档:差不多的系统体系结构和高层次的决策。对象设计基于分析模型和求解域中的体系结构等添加的实现细节,完成系统设计。要紧产物包括:细化的对象模型细化的动态模型细化的功能模型实现将设计转换为特定的编程语言或硬件,同时保持可追踪性、灵活性和可扩展性。3.7、OOSE方法论Jacobson方

19、法(OOSE)与上述三种方法有所不同,它涉及到整个软件生命周期,包括需求分析、设计、实现和测试等四个时期。需求分析和设计紧密相关。需求分析时期的活动包括定义潜在的角色(角色指使用系统的人和与系统互相作用的软、硬件环境),识不问题域中的对象和关系,基于需求规范讲明和角色的需要发觉use case,详细描述use case。设计时期包括两个要紧活动,从需求分析模型中发觉设计对象,以及针对实现环境调整设计模型。第一个活动包括从use case的描述发觉设计对象,并描述对象的属性、行为和关联。在那个地点还要把use case的行为分派给对象。在需求分析时期的识不领域对象和关系的活动中,开发人员识不类、

20、属性和关系。关系包括继承、熟悉(关联)、组成(聚拢)和通信关联。定义use case的活动和识不设计对象的活动,两个活动共同完成行为的描述。Jacobson方法还将对象区分为语义对象(领域对象)、界面对象(如用户界面对象)和操纵对象(处理界面对象和领域对象之间的操纵)。在该方法中的一个关键概念确实是use case。use case是指行为相关的事务(transaction)序列,该序列将由用户在与系统对话中执行。因此,每一个use case确实是一个使用系统的方式,当用户给定一个输入,就执行一个use case的实例并引发执行属于该use case的一个事务。基于这种系统视图,Jacobso

21、n将use case模型与其它五种系统模型关联:领域对象模型。use case模型依照领域来表示。分析模型。use case模型通过分析来构造。设计模型。use case模型通过设计来具体化。实现模型。该模型依据具体化的设计来实现use case模型。测试模型。用来测试具体化的use case模型。3.8、UML方法论面向对象的分析与设计(OOA&D)方法的进展在80年代末至90年代中出现了一个高潮,UML是那个高潮的产物。软件工程领域在1995年至1997年取得了前所未有的进展,其成果超过软件工程领域过去15年来的成就总和。其中最重要的、具有划时代重大意义的成果之一确实是统一建模语言(UML

22、:Unified Modeling Language)的出现。在世界范围内,至少在近10年内,UML将是面向对象技术领域内占主导地位的标准建模语言。UML的中心体现了统一、建模和可视化语言三个方面。统一是指它不仅统一了Booch、Rmbaugh和Jacobson的表示方法,而且对其作了进一步(综合了其他方法的优势)的进展,并最终统一为大众所同意的标准建模语言。建模是指从应用的角度看,当采纳面向对象技术设计系统时,首先是描述需求;其次依照需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为。其中在第一步与第二步中所建立的模型差不多上静态的,包括用例图、类图(包含包)、对象图、组件图和

23、配置图等五个图形,是标准建模语言UML的静态建模机制。其中第三步中所建立的模型或者能够执行,或者表示执行时的时序状态或交互关系。它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制。因此,标准建模语言UML的要紧内容也能够归纳为静态建模机制和动态建模机制两大类。可视化的语言是指建模的要素及其关系均可用图形要素(共9种图形)及明确的可视性关系来表示,其种类大约有近400种,且可扩展。 UML的5种建模图归纳如下:第一类是用例图,从用户角度描述系统功能,并指出各功能的操作者。第二类是静态图(Static diagram),包括类图、对象图和包图。其中类图描述系统中类的

24、静态结构。不仅定义系统中的类,表示类之间的联系如关联、依靠、聚合等,也包括类的内部结构(类的属性和操作)。类图描述的是一种静态关系,在系统的整个生命周期差不多上有效的。对象图是类图的实例,几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时刻段存在。包由包或类组成,表示包与包之间的关系。包图用于描述系统的分层结构。第三类是行为图(Behavior diagram),描述系统的动态模型和组成对象间的交互关系。其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常,状态图是对类图的补充。在有用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的阻碍同时发生改变的类画状态图。而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识不并行活动。第四类是

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论