运用软件工程的方法论

1、运用软件工程的方法论软件工程专业以计算机科学与技术学科为基础，强调软件开发的工程性，使学生在掌握计算机科学与技术方面知识和技能的基础上熟练掌握从事软件需求分析、软件设计软件测试、软件维护和软件项目管理等工作所必需的基础知识、基本方法和基本技能，突出对学生专业知识和专业技能的培养，培养能够从事软件开发、测试、维护和软件项目管理的高级专门人才。软件工程是一个方法论，就是我们在开始一个项目时，大体框架一定要有这么一个概念，而具体实施时，必须根据公司一些特点，优化项目开发的流程，这样才是有实效的而方法论只是软件工程的结果而已，软件工程可以指导我们如何根据特定的环境制定自己的方法论。试想，如果软件工程刚

2、刚开始就是一个方法论的话，所有的工程只需要按照这个方法去做就可以成功了，可是实际情况不是这样。每个公司都有自己的方法论，每个行业都有自己的方法论，而软件工程是凌驾在方法论之上的。她是众多方法（成功的、失败的）的抽象。1、瀑布式方法论瀑布模型将软件生命周期的各项活动规定为依固定顺序联接的若干阶段工作，形如优点：强调开发的阶段性；强调早期计划及需求调查；强调产品测试。缺点：依赖于早期进行的唯一的一次需求调查，不能适应需求的变化；由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程风险往往迟至后期的开发阶段才显露，因而失去及早纠正的机会。+十*J*tKTK*tTLJT*tI+牛ST*tFTWi

3、fi昶描|昶就BDFDDDMK1PT-STCT-UT鯉1爲赭酣f翹城其中，BD是BasicDesign的缩写，这一部分完成“本系统要做什么”的文档记录工作，即系统的分析阶段工作；FD是FunctionDesign的缩写，这一部分完成本系统功能块的划分，是“怎么去做”的第一阶段工作，即系统的设计初期阶段工作；DD是DetailDesign的缩写，这一部分完成本系统各个功能模块的详细设计工作，是编程阶段的准备设计阶段；MK是Making的缩写，即具体编程实施阶段；UT是UnitTest的缩写，即单元测试阶段；CT是CombineTest的缩写，即结合测试阶段；ST是SystemTest的缩写，即系

4、统测试阶段；PT是ProductTest的缩写，即商品测试阶段。从上图中可以看出，BD和PT、FD和ST、DD和CT、MK和UT都是成对出现的。每一对的前一部分完成之后，应该马上着手后一部分的文档制作工作。对较大的系统开发，实际测试和文档的担当者应该不同。2、生鱼片式方法论前一阶段完成70%到80%时，即可并行进入到下一个阶段。3、螺旋式方法论瀑布模型与演化模型相结合，并加入两者所忽略的风险分析所建立的一种软件开发模型。该模型于1998年由美国TRW公司(B.W.Boehm)提出。软件项目风险的大小作为指引软件过程的一个重要因素，引入这一概念有可能使得软件开发被看作一种元模型，因为它能包容任何

5、一个开发过程模型。Ailutsn/救打/弁閱世汁产屈/j呀-叙汇俺工程螺旋模型基本的做法是在“瀑布模型”的每一个开发阶段之前，引入非常严格的风险识别、风险分析和风险控制。直到采取了消除风险的措施之后，才开始计划下一阶段的开发工作。否则，项目就很可能被取消。另外，如果有充足的把握判断遗留的风险已降低到一定的程度，项目管理人员可作出决定让余下的开发工作采用另外的生命周期模型，如“演化模型”，“瀑布模型”，或自定的混合模型。优点：强调严格的全过程风险管理。强调各开发阶段的质量。提供机会检讨项目是否有价值继续下去。缺点：a引入非常严格的风险识别，风险分析，和风险控制，这对风险管理的技能水平提出了很高的

6、要求。这需要人员，资金，和时间的投入。4、阶段性发布式方法论该模型主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程。第一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。下面为生鱼片型阶段性发布式方法论图示。在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为

7、这个产品的原型的新增功能。于是，设计就不断地演化出新的系统。实际上，这个模型可看作是重复执行的多个“生鱼片方式”。5、Booch方法论Booch方法的过程包括以下步骤：在给定的抽象层次上识别类和对象识别这些对象和类的语义识别这些类和对象之间的关系实现类和对象这四种活动不仅仅是一个简单的步骤序列，而是对系统的逻辑和物理视图不断细化的迭代和渐增的开发过程。类和对象的识别包括找出问题空间中关键的抽象和产生动态行为的重要机制。开发人员可以通过研究问题域的术语发现关键的抽象。语义的识别主要是建立前一阶段识别出的类和对象的含义。开发人员确定类的行为（即方法）和类及对象之间的互相作用（即行为的规范描述）。该

8、阶段利用状态转移图描述对象的状态的模型，利用时态图（系统中的时态约束）和对象图（对象之间的互相作用）描述行为模型。在关系识别阶段描述静态和动态关系模型。这些关系包括使用、实例化、继承、关联和聚集等。类和对象之间的可见性也在此时确定。在类和对象的实现阶段要考虑如何用选定的编程语言实现，如何将类和对象组织成模块。在面向对象的设计方法中，Booch强调基于类和对象的系统逻辑视图与基于模块和进程的系统物理视图之间的区别。他还区别了系统的静态和动态模型。然而，他的方法偏向于系统的静态描述，对动态描述支持较少。Booch方法的力量在于其丰富的符号体系，包括：类图（类结构静态视图）对象图（对象结构静态视图）

9、状态转移图（类结构动态视图）时态图（对象结构动态视图）模块图（模块体系结构）进程图（进程体系结构）用于类和对象建模的符号体系使用注释和不同的图符（如不同的箭头）表达详细的信息。Booch建议在设计的初期可以用符号体系的一个子集，随后不断添加细节。对每一个符号体系还有一个文本的形式，由每一个主要结构的描述模板组成。符号体系由大量的图符定义，但是，其语法和语义并没有严格地定义。6、OMT方法论Rumbaugh的OMT方法从三个视角描述系统，相应地提供了三种模型，对象模型，动态模型和功能模型。对象模型描述对象的静态结构和它们之间的关系。主要的概念包括：类属性操作继承关联（即关系）聚集动态模型描述系统

10、那些随时间变化的方面，其主要概念有：状态子状态和超状态事件行为活动功能模型描述系统内部数据值的转换，其主要概念有：加工数据存储数据流控制流角色(源/潭)该方法将开发过程分为四个阶段：分析基于问题和用户需求的描述，建立现实世界的模型。分析阶段的产物有：问题描述-对象模型=对象图+数据词典动态模型=状态图+全局事件流图功能模型=数据流图+约束系统设计结合问题域的知识和目标系统的体系结构(求解域)，将目标系统分解为子系统。该阶段的主要产物是系统设计文档：基本的系统体系结构和高层次的决策。对象设计基于分析模型和求解域中的体系结构等添加的实现细节，完成系统设计。主要产物包括：细化的对象模型细化的动态模型

11、细化的功能模型实现将设计转换为特定的编程语言或硬件，同时保持可追踪性、灵活性和可扩展性。7、OOSE方法论Jacobson方法（OOSE）与上述三种方法有所不同，它涉及到整个软件生命周期，包括需求分析、设计、实现和测试等四个阶段。需求分析和设计密切相关。需求分析阶段的活动包括定义潜在的角色（角色指使用系统的人和与系统互相作用的软、硬件环境），识别问题域中的对象和关系，基于需求规范说明和角色的需要发现usecase，详细描述usecase。设计阶段包括两个主要活动，从需求分析模型中发现设计对象，以及针对实现环境调整设计模型。第一个活动包括从usecase的描述发现设计对象，并描述对象的属性、行为

12、和关联。在这里还要把usecase的行为分派给对象。在需求分析阶段的识别领域对象和关系的活动中，开发人员识别类、属性和关系。关系包括继承、熟悉（关联）、组成（聚集）和通信关联。定义usecase的活动和识别设计对象的活动，两个活动共同完成行为的描述。Jacobson方法还将对象区分为语义对象（领域对象）、界面对象（如用户界面对象）和控制对象（处理界面对象和领域对象之间的控制）。在该方法中的一个关键概念就是usecase。usecase是指行为相关的事务（transaction）序列，该序列将由用户在与系统对话中执行。因此，每一个usecase就是一个使用系统的方式，当用户给定一个输入，就执行一

13、个usecase的实例并引发执行属于该usecase的一个事务。基于这种系统视图，Jacobson将usecase模型与其它五种系统模型关联：领域对象模型。usecase模型根据领域来表示。分析模型。usecase模型通过分析来构造。设计模型。usecase模型通过设计来具体化。实现模型。该模型依据具体化的设计来实现usecase模型。测试模型。用来测试具体化的usecase模型。8、UML方法论面向对象的分析与设计（OOA&D）方法的发展在80年代末至90年代中出现了一个高潮,UML是这个高潮的产物。软件工程领域在1995年至1997年取得了前所未有的进展,其成果超过软件工程领域过去15年来

14、的成就总和。其中最重要的、具有划时代重大意义的成果之一就是统一建模语言(UML:UnifiedModelingLanguage)的出现。在世界范围内，至少在近10年内,UML将是面向对象技术领域内占主导地位的标准建模语言。UML的中心体现了统一、建模和可视化语言三个方面。统一是指它不仅统一了Booch、Rmbaugh和Jacobson的表示方法,而且对其作了进一步(综合了其他方法的优势)的发展,并最终统一为大众所接受的标准建模语言。建模是指从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求;其次根据需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为。其中在第一步与第二步

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

16、cdiagram),包括类图、对象图和包图。其中类图描述系统中类的静态结构。不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。类图描述的是一种静态关系,在系统的整个生命周期都是有效的。对象图是类图的实例,几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。包由包或类组成,表示包与包之间的关系。包图用于描述系统的分层结构。第三类是行为图(Behaviordiagram),描述系统的动态模型和组成对象间的交互关系。其中状态图描述类

17、的对象所有可能的状态以及事件发生时状态的转移条件。通常,状态图是对类图的补充。在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。第四类是交互图(Interactivediagram),描述对象间的交互关系。其中顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。除显示信息交换外,合作图还显示对象以及它们之间的关系。如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则选择合作图。这两种图合称为交互图。第五类是实现图(Implementationdiagram)。其中构件图描述代码部件的物理结构及各部件之间的依赖关系。一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。它包含逻辑类或实现类的有关信息。部件图有助于分析和理解部件之间的相互影响程度。配置图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性。在节点内部,