计算机软件培训讲义文档格式.docx
《计算机软件培训讲义文档格式.docx》由会员分享，可在线阅读，更多相关《计算机软件培训讲义文档格式.docx（11页珍藏版）》请在冰点文库上搜索。
提出了应用广泛的面向对象语言以及相关的面向对象方法，大力开展了计算机辅助软件工程的研究与实践。
尤其是近几年来，针对软件复用及软件生产，软件构件技术以及软件质量控制技术、质量保证技术得到了广泛的应用。
目前各个软件企业都十分重视资质认证，并想通过这些工作进行企业管理和技术的提升。
软件工程所涉及的要素可概括如下：
软件工程框架图
根据这一框架，可以看出：
软件工程涉及了软件工程的目标、软件工程原则和软件工程活动。
软件工程的主要目标是：
生产具有正确性、可用性以及开销合宜的产品。
正确性意指软件产品达到预期功能的程度。
可用性指软件基本结构、实现及文档为用户可用的程度。
开销合宜性是指软件开发、运行的整个开销满足用户要求的程度。
这些目标的实现不论在理论上还是在实践中均存在很多问题有待解决，它们形成了对过程、过程模型及工程方法选取的约束。
软件工程的四项基本原则是：
第一，选取适宜开发范型。
该原则与系统设计有关。
在系统设计中，软件需求、硬件需求以及其他因素之间是相互制约、相互影响的，经常需要权衡。
因此，必须认识需求定义的易变性，采用适宜的开发范型予以控制，以保证软件产品满足用户的要求。
第二，采用合适的设计方法。
在软件设计中，通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。
合适的设计方法有助于这些特征的实现，以达到软件工程的目标。
第三，提供高质量的工程支持。
“工欲善其事，必先利其器”。
在软件工程中，软件工具与环境对软件过程的支持颇为重要。
软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。
第四，重视开发过程的管理。
软件工程的管理，直接影响可用资源的有效利用，生产满足目标的软件产品，提高软件组织的生产能力等问题。
因此，仅当软件过程得以有效管理时，才能实现有效的软件工程。
软件工程活动是“生产一个最终满足需求且达到工程目标的软件产品所需要的步骤”。
主要包括需求、设计、实现、确认以及支持等活动。
需求活动包括问题分析和需求分析。
问题分析获取需求定义，又称软件需求规约。
需求分析生成功能规约。
设计活动一般包括概要设计和详细设计。
概要设计建立整个软件体系结构，包括子系统、模块以及相关层次的说明、每一模块接口定义。
详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。
实现活动把设计结果转换为可执行的程序代码。
确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。
支持活动包括修改和完善。
伴随以上活动，还有管理过程、支持过程、培训过程等。
这一软件工程框架告诉我们，软件工程的目标是可用性、正确性和合算性；
实施一个软件工程要选取适宜的开发范型，要采用合适的设计方法，要提供高质量的工程支撑，要实行开发过程的有效管理；
软件工程活动主要包括需求、设计、实现、确认和支持等活动，每一活动可根据特定的软件工程，采用合适的开发范型、设计方法、支持过程以及过程管理。
根据软件工程这一框架，软件工程学科的研究内容主要包括：
软件开发范型、软件开发方法、软件过程、软件工具、软件开发环境、计算机辅助软件工程（CASE）及软件经济学等。
自从软件工程概念提出以来，经过30多年的研究与实践,虽然“软件危机”没得到彻底解决，但在软件开发方法和技术方面已经有了很大的进步。
尤其应该指出的是，自80年代中期，美国工业界和政府部门开始认识到，在软件开发中，最关键的问题是软件开发组织不能很好地定义和管理其软件过程，从而使一些好的开发方法和技术都起不到所期望的作用。
也就是说，在没有很好定义和管理软件过程的软件开发中，开发组织不可能在好的软件方法和工具中获益。
根据调查，中国的现状几乎和美国10多年前的情况一样，软件开发过程没有明确规定，文档不完整，也不规范，软件项目的成功往往归功于软件开发组的一些杰出个人或小组的努力。
这种依赖于个别人员上的成功并不能为全组织的软件生产率和质量的提高奠定有效的基础，只有通过建立全组织的过程改善，采用严格的软件工程方法和管理，并且坚持不懈地付诸实践，才能取得全组织的软件过程能力的不断提高。
这一事实告诉我们，只有坚持软件工程的四条基本原则，既重视软件技术的应用，又重视软件工程的支持和管理，并在实践中贯彻实施，才能高效地开发出高质量的软件。
3、方法论
如何运用软件工程，从20世纪70年代初开始，围绕着这个问题，诞生了许多著名的方法论。
下面对几个典型的方法论进行简单的介绍。
3.1、瀑布式方法论
瀑布模型将软件生命周期的各项活动规定为依固定顺序联接的若干阶段工作，形如瀑布流水，最终得到软件产品。
优点：
a.强调开发的阶段性；
b.强调早期计划及需求调查；
c.强调产品测试。
缺点：
a.依赖于早期进行的唯一的一次需求调查，不能适应需求的变化；
b.由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；
c.风险往往迟至后期的开发阶段才显露，因而失去及早纠正的机会。
其中，BD是BasicDesign的缩写，这一部分完成“本系统要做什么”的文档记录工作，即系统的分析阶段工作；
FD是FunctionDesign的缩写，这一部分完成本系统功能块的划分，是“怎么去做”的第一阶段工作，即系统的设计初期阶段工作；
DD是DetailDesign的缩写，这一部分完成本系统各个功能模块的详细设计工作，是编程阶段的准备设计阶段；
MK是Making的缩写，即具体编程实施阶段；
UT是UnitTest的缩写，即单元测试阶段；
CT是CombineTest的缩写，即结合测试阶段；
ST是SystemTest的缩写，即系统测试阶段；
PT是ProductTest的缩写，即商品测试阶段。
从上图中可以看出，BD和PT、FD和ST、DD和CT、MK和UT都是成对出现的。
每一对的前一部分完成之后，应该马上着手后一部分的文档制作工作。
对较大的系统开发，实际测试和文档的担当者应该不同。
3.2、生鱼片式方法论
前一阶段完成70%到80%时，即可并行进入到下一个阶段。
3.3、螺旋式方法论
瀑布模型与演化模型相结合，并加入两者所忽略的风险分析所建立的一种软件开发模型。
该模型于1998年由美国TRW公司（B.W.Boehm）提出。
软件项目风险的大小作为指引软件过程的一个重要因素，引入这一概念有可能使得软件开发被看作一种元模型，因为它能包容任何一个开发过程模型。
螺旋模型基本的做法是在“瀑布模型”的每一个开发阶段之前，引入非常严格的风险识别、风险分析和风险控制。
直到采取了消除风险的措施之后，才开始计划下一阶段的开发工作。
否则，项目就很可能被取消。
另外，如果有充足的把握判断遗留的风险已降低到一定的程度，项目管理人员可作出决定让余下的开发工作采用另外的生命周期模型，如“演化模型”，“瀑布模型”，或自定的混合模型。
a.强调严格的全过程风险管理。
b.强调各开发阶段的质量。
c.提供机会检讨项目是否有价值继续下去。
a.引入非常严格的风险识别，风险分析，和风险控制，这对风险管理的技能水平提出了很高的要求。
这需要人员，资金，和时间的投入。
3.4、阶段性发布式方法论
该模型主要针对事先不能完整定义需求的软件开发。
用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。
软件开发人员根据用户的需求，首先开发核心系统。
当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。
软件开发人员根据用户的反馈，实施开发的迭代过程。
第一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。
下面为生鱼片型阶段性发布式方法论图示。
在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。
于是，设计就不断地演化出新的系统。
实际上，这个模型可看作是重复执行的多个“生鱼片方式”。
3.5、Booch方法论
Booch方法的过程包括以下步骤：
・在给定的抽象层次上识别类和对象
・识别这些对象和类的语义
・识别这些类和对象之间的关系
・实现类和对象
这四种活动不仅仅是一个简单的步骤序列，而是对系统的逻辑和物理视图不断细化的迭代和渐增的开发过程。
类和对象的识别包括找出问题空间中关键的抽象和产生动态行为的重要机制。
开发人员可以通过研究问题域的术语发现关键的抽象。
语义的识别主要是建立前一阶段识别出的类和对象的含义。
开发人员确定类的行为（即方法）和类及对象之间的互相作用（即行为的规范描述）。
该阶段利用状态转移图描述对象的状态的模型，利用时态图（系统中的时态约束）和对象图（对象之间的互相作用）描述行为模型。
在关系识别阶段描述静态和动态关系模型。
这些关系包括使用、实例化、继承、关联和聚集等。
类和对象之间的可见性也在此时确定。
在类和对象的实现阶段要考虑如何用选定的编程语言实现，如何将类和对象组织成模块。
在面向对象的设计方法中，Booch强调基于类和对象的系统逻辑视图与基于模块和进程的系统物理视图之间的区别。
他还区别了系统的静态和动态模型。
然而，他的方法偏向于系统的静态描述，对动态描述支持较少。
Booch方法的力量在于其丰富的符号体系，包括：
・类图（类结构－静态视图）
・对象图（对象结构－静态视图）
・状态转移图（类结构－动态视图）
・时态图（对象结构－动态视图）
・模块图（模块体系结构）
・进程图（进程体系结构）
用于类和对象建模的符号体系使用注释和不同的图符（如不同的箭头）表达详细的信息。
Booch建议在设计的初期可以用符号体系的一个子集，随后不断添加细节。
对每一个符号体系还有一个文本的形式，由每一个主要结构的描述模板组成。
符号体系由大量的图符定义，但是，其语法和语义并没有严格地定义。
3.6、OMT方法论
Rumbaugh的OMT方法从三个视角描述系统，相应地提供了三种模型，对象模型，动态模型和功能模型。
对象模型描述对象的静态结构和它们之间的关系。
主要的概念包括：
・类
・属性
・操作
・继承
・关联（即关系）
・聚集
动态模型描述系统那些随时间变化的方面，其主要概念有：
・状态
・子状态和超状态
・事件
・行为
・活动
功能模型描述系统内部数据值的转换，其主要概念有：
・加工
・数据存储
・数据流
・控制流
・角色（源/潭）
该方法将开发过程分为四个阶段：
1）分析
基于问题和用户需求的描述，建立现实世界的模型。
分析阶段的产物有：
・问题描述
・对象模型＝对象图＋数据词典
・动态模型＝状态图＋全局事件流图
・功能模型＝数据流图＋约束
2）系统设计
结合问题域的知识和目标系统的体系结构（求解域），将目标系统分解为子系统。
该阶段的主要产物是系统设计文档：
基本的系统体系结构和高层次的决策。
3）对象设计
基于分析模型和求解域中的体系结构等添加的实现细节，完成系统设计。
主要产物包括：
・细化的对象模型
・细化的动态模型
・细化的功能模型
4）实现
将设计转换为特定的编程语言或硬件，同时保持可追踪性、灵活性和可扩展性。
3.7、OOSE方法论
Jacobson方法（OOSE）与上述三种方法有所不同，它涉及到整个软件生命周期，包括需求分析、设计、实现和测试等四个阶段。
需求分析和设计密切相关。
需求分析阶段的活动包括定义潜在的角色（角色指使用系统的人和与系统互相作用的软、硬件环境），识别问题域中的对象和关系，基于需求规范说明和角色的需要发现usecase，详细描述usecase。
设计阶段包括两个主要活动，从需求分析模型中发现设计对象，以及针对实现环境调整设计模型。
第一个活动包括从usecase的描述发现设计对象，并描述对象的属性、行为和关联。
在这里还要把usecase的行为分派给对象。
在需求分析阶段的识别领域对象和关系的活动中，开发人员识别类、属性和关系。
关系包括继承、熟悉（关联）、组成（聚集）和通信关联。
定义usecase的活动和识别设计对象的活动，两个活动共同完成行为的描述。
Jacobson方法还将对象区分为语义对象（领域对象）、界面对象（如用户界面对象）和控制对象（处理界面对象和领域对象之间的控制）。
在该方法中的一个关键概念就是usecase。
usecase是指行为相关的事务（transaction）序列，该序列将由用户在与系统对话中执行。
因此，每一个usecase就是一个使用系统的方式，当用户给定一个输入，就执行一个usecase的实例并引发执行属于该usecase的一个事务。
基于这种系统视图，Jacobson将usecase模型与其它五种系统模型关联：
・领域对象模型。
usecase模型根据领域来表示。
・分析模型。
usecase模型通过分析来构造。
・设计模型。
usecase模型通过设计来具体化。
・实现模型。
该模型依据具体化的设计来实现usecase模型。
・测试模型。
用来测试具体化的usecase模型。
3.8、UML方法论
面向对象的分析与设计（OOA&
D）方法的发展在80年代末至90年代中出现了一个高潮,UML是这个高潮的产物。
软件工程领域在1995年至1997年取得了前所未有的进展,其成果超过软件工程领域过去15年来的成就总和。
其中最重要的、具有划时代重大意义的成果之一就是统一建模语言（UML:
UnifiedModelingLanguage）的出现。
在世界范围内,至少在近10年内,UML将是面向对象技术领域内占主导地位的标准建模语言。
UML的中心体现了统一、建模和可视化语言三个方面。
统一是指它不仅统一了Booch、Rmbaugh和Jacobson的表示方法,而且对其作了进一步（综合了其他方法的优势）的发展,并最终统一为大众所接受的标准建模语言。
建模是指从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求;
其次根据需求建立系统的静态模型,以构造系统的结构;
第三步是描述系统的行为。
其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图（包含包）、对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制。
其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。
它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制。
因此,标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。
可视化的语言是指建模的要素及其关系均可用图形要素（共9种图形）及明确的可视性关系来表示，其种类大约有近400种，且可扩展。
UML的5种建模图归纳如下：
・第一类是用例图,从用户角度描述系统功能,并指出各功能的操作者。
・第二类是静态图（Staticdiagram）,包括类图、对象图和包图。
其中类图描述系统中类的静态结构。
不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构（类的属性和操作）。
类图描述的是一种静态关系,在系统的整个生命周期都是有效的。
对象图是类图的实例,几乎使用与类图完全相同的标识。
他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。
一个对象图是类图的一个实例。
由于对象存在生命周期,因此对象图只能在系统某一时间段存在。
包由包或类组成,表示包与包之间的关系。
包图用于描述系统的分层结构。
・第三类是行为图（Behaviordiagram）,描述系统的动态模型和组成对象间的交互关系。
其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。
通常,状态图是对类图的补充。
在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。
而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。
・第四类是交互图（Interactivediagram）,描述对象间的交互关系。
其中顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;
合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。
除显示信息交换外,合作图还显示对象以及它们之间的关系。
如果强调时间和顺序,则使用顺序图;
如果强调上下级关系,则选择合作图。
这两种图合称为交互图。
・第五类是实现图（Implementationdiagram）。
其中构件图描述代码部件的物理结构及各
部件之间的依赖关系。
一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。
它包含逻辑类或实现类的有关信息。
部件图有助于分析和理解部件之间的相互影响程度。
配置图定义系统中软硬件的物理体系结构。
它可以显示实际的计算机和设备（用节点表示）以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性。
在节点内部,放置可执行部件和对象以显示节点跟可执行软件单元的对应关系。
3.9、RUP
UML是独立于开发过程的，但工程项目或产品的开发又离不开过程。
所以又有了RPM的概，即推荐过程模式的概念。
本文中一到四结叙述方法中的过程概念均属于RPM的范畴。
但3位大师在设计UML的期间，脑海中也始终以一种开发过程对照检验着UML。
所以，当UML问世时，一种新的开发方法也水到渠成地诞生了，这就是UP（UnifiedProcess），即统一软件开发过程。
3.10、其他
另外，还有Fusion、Martin-Odell等几十种方法论。
所以，80年代被成为方法论战争的时代。
战争在何时被终结的，我们在下一小结中介绍。
4、面向对象
参照『面向对象讲义』和『面向对象技术的研究与发展』文档。
5、统一建模语言和统一建模过程
参照『UML和UP介绍讲义』文档。
6、工具
参照『Rational公司产品介绍』文档。
升级会员 