1.4软件工程

IEEE对软件工程的定义是:将系统的,规范的,可度量的工程化方法应用于软件开发,运行和维护的全过程及上述方法的研究.
软件工程由方法,工具和过程三个部分组成.软件工程方法是完成软件工程项目的技术手段,它支持整个软件生命周期;软件工程使用的工具是人们在开发软件的活动中智力和体力的扩展与延伸,它自动或半自动的支持软件的开发和管理,支持各种软件文档的生成;软件工程中的过程贯穿于软件开发的各个环节,管理人员在软件工程过程中,要对软件开发的质量,进度,成本进行评估,管理和控制,包括人员组织,计划跟踪与控制,成本估算,质量保证和配置管理等.

1.4.1 需求分析

软件需求是指用户对新系统在功能,行为,性能,设计约束等方面的期望.

1. 需求的层次
   软件需求就是系统必须完成的事以及必须具备的品质.需求是多层次的包括业务需求,用户需求和系统需求.这三个不同层次从目标到具体,从整体到局部,从概念到细节.
   1.)业务需求 业务需求是指反映企业或客户对系统高层次的目标要求,通常来自项目投资人,购买产品的客户,客户单位的管理人员,市场营销部门或产品策划部门等.通过业务需求可以确定简单的文档,为开发奠定基础.
   2)用户需求 用户需求描述的是用户的具体目标.通常才去用户访谈和问卷调查等方式,对用户使用的场景进行整理,从而建立用户需求.
   3)系统需求 是从系统的角度来说明软件的需求,包括功能需求,非功能需求和设计约束等.功能需求规定了开发人员必须在系统中实现的软件功能,用户利用这些功能来满足业务需要.功能需求通常是通过系统特性的描述表现出来的,所谓特性,是指一组逻辑上相关的功能需求,表示系统为用户提供某项功能,使用户的业务目标得以满足;非功能需求是指系统必须具备的属性或品质,又可细分为软件质量属性(例如,易用性,可维护性,效率等)和其他非功能需求,设计约束也成为限制条件或补充规约,通常是对系统的一些约束说明,例如,必须采用国有自主知识产权的数据库系统,必须运行在UNIX操作系统之下等.

2. 质量功能部署
   是一种将用户要求转化成软件需求的技术,其目的是最大限度的提升软件工程过程中用户的满意度.为了打到这个目标,QFD将软件需求分为三类,分别是常规需求,期望需求和意外需求.
   1).常规需求: 用户认为系统应该做到的功能或性能,实现越多用户会越满意
   2).期望需求: 用户想当然认为系统应具备的功能或性能,但是,并不能正确描述自己想要得到的这些功能或性能需求.如果没实现,会让用户不满意.
   3).意外需求: 用户要求范围外的功能或性能,实现这些需求用户会更高兴.

3. 需求获取
   需求获取是一个确定和理解不同的项目干系人的需求和约束的过程.需求获取是否科学,准备充分,对获取出来的结果影响很大,这是因为大部分用户无法完整的描述需求,因此需求获取只有与用户有效合作才能成功.

4. 需求分析
   一个好的需求应该具有无二义性,完整性,一致性,可测试性,确定性,可跟踪性,正确性,必要性等特性,因此,需要分析人员吧杂乱无章的用户要求和期望转化为用户需求,这就是需求分析的工作.

7. UML
   是一种定义良好,易于表达,功能强大且普遍使用的建模语言,它融入了软件工程领域的新思想,新方法和新技术,他的作用域不限于支持OOA和OOD,还支持从需求分析开始的软件开发的全过程.
   总总体上开,UML的结构包括结构块,规则和公共机制三个部分.
   构造块: UML有三种基本的构造块,分别是事物,关系和图.事物是UML的重要组成部分,关系把事物紧密联系在一起,图是多个相互关联的事物的集合.
   规则: 是构造块如何放在一起的规定,包括为构造块命名;给一个名字以特定含义的语境,即范围;怎样使用或看见名字,即可见性;事物如何正确,一致的相互联系,即完整性;运行或模拟动态模型的含义是什么,即执行.
   公共机制: 是指达到特定目标的公共UML方法,主要包括规格说明,修饰,公共分类和扩展机制四种.
   1).UML中的事物
   也成为建模元素,包括结构事物,行为事物,分组事物和注释事物.这些事物是UML模型中最基本的OO构造块.
   结构事物: 模型中属于最静态的部分,代表概念上或物理上的元素.UML有七种结构事物,分别是类,接口,协作,用例,活动类,构件和节点.
   行为事物: 是UML模型中的动态部分,代表时间和空间上的动作.UML有两种主要的行为事物.一种是交互(内部活动),交互是由一组对象之间在特定上下文中,为达到特定目的而进行的一系列消息交换而组成的动作.交互中组成动作的对象的每个操作都要详细列出,包括消息,动作次序(消息产生的动作),连接(对象之间的连接);第二种是状态机,由一系列对象的状态组成.
   分组事物: UML模型中组织的部分,可以把他们看成是个盒子,模型可以在其中进行分解.UML只有一种分组事物,称为包.是一种将有组织的元素分组的机制.与构件不同的是,包纯粹是一种概念上的事物,只存在于开发阶段,而构件可以存在于系统运行阶段.
   注释事物: UML模型的解释部分
   2).UML中的关系
   UML用关系把事物结合在一起,主要有四种关系:
   依赖: 两个事物之间的语义关系,其中一个事物发生变化会影响另一个事物的语义
   关联: 关联描述一组对象之间连接的结构关系.
   泛化: 是一般化和特殊化的关系,描述特殊元素的对象可替换一般元素的对象
   实现: 类之间的语义关系
   3).UML2.0中的图
   包括14种图,分别列举如下:
   (1). 类图: 描述一组类,接口,协作和他们之间的关系.给出了系统的静态设计视图,活动类的类图,系统的静态进程视图.
   (2).对象图: 描述一组对象及它们之间的关系.
   (3).构件图: 描述一个封装的类和他的接口,端口,以及由内嵌的构件和连接件构成的内部结构.
   (4).组合结构图: 描述结构化类的内部结构,包括结构化类与系统其余部分的交互点.
   (5).用例图: 描述一组用例,参与者及他们之间的关系.给出系统的静态用例视图.对系统的行为进行组织和建模时是非常重要的.
   (6).顺序图: 是一种交互图,展现了一种交互,它由一组对象或参与者以及它们之间可能发送的消息构成.专注于系统的动态视图.强调消息的时间次序的交互图
   (7).通信图: 也是一种交互图,强调收发消息的对象或参与者的结构组织.
   (8).定时图: 一种交互图,强调消息跨越不同对象或参与者的实际时间,而不仅仅只关心消息的相对顺序.
   (9).状态图: 描述一个状态机,它由状态,转移,事物和活动组成.给出了对象的动态视图,对于接口,类或协作的行为建模尤为重要,强调事件导致的对象行为,这非常有助于对反应式系统建模.
   (10).活动图: 将进程或其他计算结构展示为计算内部一步步的控制流和数据流.强调对象间的控制流程.
   (11).部署图: 描述对运行时的处理节点及在其中生存的构件的配置.
   (12).制品图: 描述计算机中一个系统的物理结构.制品包括文件,数据库和类似的物理比特集合.制品图通常与部署图一起使用.制品也给出了他们实现的类和构件.
   (13).包图: 描述由模型本身分解而成的组织单元,以及他们之间的依赖关系.
   (14).交互概念图: 是活动图和顺序图的混合物.
   4).UML视图
   UML对系统架构的定义是系统的组织结构,包括系统分解的组成部分,以及他们的关联性,交互机制和指导原则等提供系统设计的信息.以下五个系统视图介绍:
   (1).逻辑视图: 也称为设计视图,表示了设计模型中在架构方面具有重要意义的部分,即类,子系统,包和用例实现的子集.
   (2).进程视图: 是可执行线程和进程作为活动类的建模,它是逻辑视图的一次执行实例,描述了并发与同步结构.
   (3).实现视图: 对组成基于系统的物理代码的文件和构件进行建模
   (4).部署视图: 把构件部署到一个物理节点上,表示软件到硬件的映射和分布结构.
   (5).用例视图: 最基本的需求分析模型.

8. 面向对象分析
   OOA的基本任务是运用OO方法,对问题进行分析和理解,正确认识其中的事物及他们之间的关系,找出描述问题域和系统功能所需的类和对象,定义他们的属性和职责,以及他们之间所形成的各种联系.最终产生一个符合用户需求,并能直接反映问题域和系统功能的OOA模型及其详细说明.
   面向对象分析阶段的核心工作是建立系统的用例模型与分析模型.
   1).用例模型
   SA(结构化分析)方法采用功能分解的方式来描述系统功能,在这种表达方式中,系统功能被分解到各个功能模块中,通过描述细分的系统模块的功能来达到描述整个系统功能的目的.
   从用户的角度来看,他们并不像了解系统的内部结构和设计,他们所关心的是系统所能提供的服务,这就是用例方法的基本思想.用例方法是一种需求合成技术,先获取需求,然后从这些要求和期望中整理,提炼,从而建立用例模型.构建用例模型需要四个阶段,识别参与者,合并需求获得用例,细化用例描述和调整用例模型.前三个阶段是必须的.
   (1)识别参与者: 是与系统交互的所有事物,可以是人,还可以是其他系统和硬件设备,甚至是系统时钟.
   (2)合并需求获得用例: 将参与者都找到之后,为每个参与者确定用例.首先,要将获取到的需求分配给与其相关的参与者,一遍可以针对每个参与者进行工作,而无遗漏;其次,进行合并操作.
   (3)细化用例描述: 用例建模的主要工作是书写用例规约,而不是画图,用例模板为一个给定项目的所有人员定义了用例规约的结果,其内容至少包括用例名,参与者,目标,前置条件,事件流和后置条件等,其他的还可以包括非功能需求和用例优先级等.
   (4)调整用例模型: 建立了初步的用例模型后,还可以利用用例之间的关系来调整用例模型.用例之间的关系主要有包含,扩展和泛化,利用这些关系,把一些公共的信息抽取出来,以便于复用,使得用例模型更易于维护.
   包含关系: 当可以从两个或两个以上的用例中提取公共的行为时,应该使用包含关系来表示他们.其中这个提取出来d额公共用例称为抽象用例,而把原始用例称为基本用例或基础用例.
   扩展关系: 如果一个用例明显的混合了两种或两种以上的不同场景,即根据情况可能发生多种分支,则可以将这个用例分为一个基本用例和一个或多个扩展用例,这样是描述更加清晰.
   泛化关系: 当多个用例共同拥有一种类似的结构和行为时候,可以将他们的共性抽象成父用例,其他的用例作为泛化关系中的子用例.
   2).分析模型
   描述系统的基本逻辑结构,展示对象和类如何组成系统(静态模型),以及他们如何保持通信,实现系统行为(动态模型).
   例如:用例的事件流会对应产生一个顺序图,描述相关对象如何通过合作来完整整个事件流,复杂的备选事件流也可以产生一个或多个顺序图.所有这些图的集合就构成了系统的分析模型.
   建立分析模型的过程大致包括定义概念类,确定类之间的关系,为类添加职责,建立交互图等.其中前三个步骤统称为CRC建模.
   类之间的主要关系有关联,依赖,泛化,聚合,组合和实现等.

1.4.2 软件架构设计

软件架构为软件系统提供了一个结构,行为和属性的高级抽象,由构件的描述,构件的相互作用(连接件),指导构件集成的模式以及这些模式的约束组成.软件架构不仅制定了系统的组织结构和拓扑结构,并且显示了系统需求和构件之间的对应关系,提供了一些设计决策的基本原理.
软件架构研究的主要内容设计软件架构描述,软件架构风格,软件架构评估和软件架构的形式化方法等.解决好软件的复用,质量和维护问题,是研究软件架构的根本目的.

1. 软件架构风格
   软件架构设计的一个核心问题是能否达到架构级的软件复用.软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式.架构风格定义了一个系统”家族”,即一个架构定义,一个词汇表和一组约束.词汇表中包含一些构件和连接件类型,而约束指出系统是如何将这些构件和连接件组合起来的.架构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个构件有效的组织称一个完整的系统.
   软件架构分为数据流风格,调用/返回风格,独立构件风格,虚拟机风格和仓库风格.
   1).数据流风格: 包括批处理序列和管道/过滤器两种风格.
   2).调用/返回风格: 包括主程序/子程序,数据抽象和面向对象,以及层次结构.
   3).独立构件风格: 包括进程通信和时间驱动的系统.
   4).虚拟机风格: 包括解释器和基于规则的系统.
   5).仓库风格: 包括数据库系统,黑板系统和超文本系统.
2. 软件架构评估
   敏感点: 是一个或多个构件的特性;
   权衡点:是影响多个质量属性的特性,是多个质量属性的敏感点.
   可归纳为三类主要评估方式,调查问卷方式,基于场景的方式和基于度量的方式.通过这几种方式来对软件架构进行验证BUG.

1.4.3 软件设计

软件设计是需求分析的延伸与拓展.需求分析阶段解决”做什么”的问题,软件设计阶段解决”怎么做”.同时它也是系统实施的基础,为系统实施工作做好铺垫.

1. 结构化设计
   SD是一种面向数据流的方法,它以SRS(软件需求规格说明书)和SA(结构化分析方法)阶段所产生的的DFD和数据字典等文档为基础,是一个自顶向下,逐步求精和模块化的过程.SD方法的基本思想是将软件设计成由相对独立且具有单一功能的模块阻证的结构,分为概要设计和详细审计两个阶段,其中概要设计又称为总体结构设计,他是开发过程中很关键的一步,主要任务是将系统的功能需求分配给软件模块,确定每个模块的功能和调用关系,行程软件的模块结构图,即系统结构图.
   SD基本原则: 高内聚,低耦合
2. 面向对象设计
   OOD是OOA方法的延续,其基本思想包括抽象,封装和可扩展性(继承和多态).在OOD中,数据结构和在数据结构上定义的操作算法封装在一个对象中.
   主要任务是hi对类和对象进行设计,包括属性,方法,以及类与类之间的关系.OOD的结构就是设计模型.对于OOD,在支持可维护性的同时,提高软件的可复用性是一个至关重要的问题,可维护性的复用是以设计原则为基础的.常用的OOD原则如下:
   1).单一职责原则: 设计功能单一的类(高内聚);
   2).开放-封闭原则: 对扩展开放,对封装封闭;
   3).李氏替换原则: 子类可以替换父类;
   4).接口隔离原则: 使用多个专门的接口比使用单一的总接口更好;
   5).组合重用原则: 要尽量使用组合,而不是继承关系打到重用目的.
   6).依赖倒置原则: 要依赖于抽象,而不是具体实现;针对接口编程,不要针对实现编程.
   7).艾米特原则(最少知识法则): 一个对象应当对其他对象有尽可能少的了解(低耦合).
3. 设计模式
   根据处理范围不同,设计模式可分为类模式和对象模式.类模式处理类和子类之间的关系,这些关系通过集成建立,在编译时刻就被确定下来,属于静态关系;对象模式处理对象之间的关系,这些关系在运动时刻变化,更具动态性.

1.4.4 软件工程的过程管理

在软件过程管理方面,最著名的是能力成熟度模型集成(CMMI),它融合了多重模型,形成了组织范围内过程改进的单一集成模型,其主要目的是消除不同模型之间的不一致和重复,降低基于模型进行改进的成本.CMMI继承了CMM的阶段表示法和EIA/IS731的连续式表示法.这两种表示方法各有优缺点,均采用统一的24个过程域,它们在逻辑上是等价的,对同一个组织采用两种模型分别进行CMMI评估,得到的结论应该是相同的.
过程域的阶段式分组

• 可管理级: 需求管理,项目计划,配置管理,项目监督与控制,供应商合同管理,度量和分析,过程和产品质量保证.
• 已定义级: 需求开发,技术解决方案,产品集成,验证,确认,组织级过程焦点,组织级过程定义,组织级培训,集成项目管理,风险管理,集成化的团队,决策分析和解决方案,组织级集成环境.
• 量化管理级: 组织级过程性能,定量项目管理.
• 优化管理级: 组织级改革与实施,因果分析和解决方案
  当组织通过了某一等级过程域中的全部过程,即一位置该组织的成熟度达到了这一等级.

连续式模型的过程域分组

连续式模型与阶段是模型相比,连续式模型没有与组织成熟度相关的几个阶段.

• 过程管理: 组织级过程焦点,组织级过程定义,组织级培训,组织级过程性能,组织级改革与实施.
• 项目管理: 项目计划,项目监督与控制,供应商合同管理,集成项目管理,风险管理,集成化的团队,定量项目管理.
• 工程: 需求管理,需求开发,技术解决方案,产品集成,验证,确认.
• 支持: 配置管理,度量和分析,过程和产品质量保证,决策分析和解决方案,组织级集成环境,因果分析和解决方案.

1.4.5 软件测试及其管理

GB/T15532-2008规定了测试用例设计原则和测试用例要素.其中,测试用例设计的原则有基于测试需求的原则,基于测试方法的原则,兼顾测试充分性和效率的原则,测试执行的可再现性原则;每个测试用例应包括名称和标识,测试追踪,用例说明,测试的初始化要求,测试的输入,期望的测试结果,评价测试结果的准则,操作过程,前提和约束,测试中止条件.

1. 测试的方法
   软件测试方法可分为静态测试和动态测试.静态测试是指被测试程序不在机器上运行,而采用人工检测和计算机辅助静态分析的手段对程序进行检测.静态测试包括对文档的静态测试和对代码的静态测试.对文档的静态测试主要是检查单的形式进行,而对代码的静态测试一般采用桌前检查,代码走查和代码审查.通常使用这种方法能够有效地发现30%-70%的逻辑设计和编码错误.
   动态测试是指在计算机上世纪运行程序进行软件测试,一般采用白盒测试和黑盒测试方法.白盒测试也成为结构测试,主要用于软件单元测试中.它的主要思想是,将程序看成是一个透明的白盒,测试人员完全清楚程序的结构和处理算法,按照程序内部逻辑结构设计测试用例,检测程序中的主要执行通路是否都能按预定要求正确工作.另外,使用静态测试的方法也可以实现白盒测试.
   黑盒测试也称为功能测试,主要用于集成测试,确认测试和系统测试中.黑盒测试只检查程序功能是否能按照SRS的要求正常使用,程序是否能适当的接收输入数据并产生正确的输出信息等.
2. 测试的类型
   软件测试可分为单元测试,集成测试,确认测试,系统测试,配置项测试和回归测试等类别.
   单元测试: 也称模块测试,测试对象是可独立编译或汇编的程序模块,软件构件或OO软件中的类,目的是检查每个模块是否正确的实现设计功能.依据是软件详细设计说明书.
   集成测试: 目的是检查模块之间,以及模块和已集成的软件之间的接口关系,并验证已集成的软件是否符合设计要求.技术依据是软件概要设计文档.
   确认测试: 目的是验证软件功能,性能和其他特性是否与用户要求一致.
   1).内部确认测试.
   2).Alpha测试和Beta测试:Alpha测试是指由用户在开发环境下测试,Beta测试是指用户在实际使用环境下测试.
   3).验收测试:在真实的用户工作环境下测试
   4).系统测试:在真实系统工作环境下,验证完整的软件配置项是否满足系统设计文档和软件开发合同规定.一居室用户需求或开发合同.
   5).配置项测试:测试的对象是软件配置项,目的是检验软件配置项与SRS的一致性.技术依据是SRS(含接口需求规格说明)
   6).回归测试:目的是测试软件变更之后,变更部分的正确性和变更需求的符合性(变更部分需要重新走一遍测试流程).
3. 面向对象的测试
   OO系统测试目标与传统信息系统的测试目标是一致的,但OO系统的测试策略有很大的不同,主要体现在测试的焦点从模块过度到类,测试的视角扩大到了分析和设计模型.
   OO系统三个明显特征,封装性决定了OO系统的测试必须考虑到信息隐蔽原则对测试的影响,以及对象状态与类的测试序列;继承性决定了OO系统测试必须考虑到继承对测试的影响,多态性决定了OO系统的测试必须要考虑到动态绑定对测试的影响.
4. 软件调试
   调试就是为了修改测试出来的错误
5. 软件测试管理
   包括过程管理,配置管理和评审工作
   1).过程管理: 根据项目规格,合理分配测试人员.
   开始软件测试工作,一般应具备下列条件.具有测试合同(项目计划);具有软件测试所需的各种文档;所提交的被测试软件已受控;软件源代码已正确通过编译或汇编.
   结束软件测试工作:完成合同(项目计划)所规定的的测试任务;记录发现的问题;软件测试文档齐全,符合规范;软件测试中的问题或异常有合理解释或正确有效的处理;测试工作通过了测试评审;测试工具,被测软件,测试支持软件和评审结果已纳入配置管理.
   2).配置管理: 应按照软件配置管理要求,将测试过程中产生的各种工作产品纳入配置管理.由开发组织实施的软件测试,应将测试工作产品纳入软件项目的配置管理;由独立测试组织实施的软件测试,应建立配置管理库,将被测试对象和测试工作产品纳入配置管理.
   3).评审: 测试过程中的评审包括测试就绪和测试评审.测试就绪评审是指在测试执行前对测试计划和测试说明等进行评审,评审测试计划的合理性和测试用例的正确性,完整性和覆盖充分性,以及测试组织,测试环境和设备,工具是否齐全并符合技术要求等;测试评审是指在测试完成后,评审测试过程和测试结果的有效性,确定是否打到测试目的,主要对测试记录和测试 告进行评审.

1.4.6 软件集成技术

企业应用集成(EAI)可以消除信息孤岛,它将多个企业信息系统连接起来,实现无缝集成.

1. 表示集成
   也称为界面集成,这是比较原始和最浅层次的集成,但有时常用的集成.
   表示集成是黑盒集成,无序了解程序与数据库的内部构造.
   表示集成出来的界面很可能成为系统的性能瓶颈.
2. 数据集成
   为了完成控制集成和业务流程集成,必须首先解决数据和数据库的集成问题.在集成之前,必须首先对数据进行表示并编成目录,另外还要确定元数据模型,保证数据在数据库系统中分布和共享.因此,数据集成是白盒集成.
   当业务逻辑发生变化时,数据集成会面临困难.
3. 控制集成
   控制集成也称为功能集成或应用集成,在业务逻辑层上对应用系统进行集成的.控制集成属于黑盒集成.
4. 业务流程集成
   业务流程集成也称为过程集成,这种集成超越了数据和系统,它由一系列基于标准的,统一数据格式的工作流组成.当进行业务流程集成时,企业必须对各种业务信息的交换进行定义,授权和管理,以便改进操作,减少成本,提高响应速度.
5. 企业之间的应用集成
   两个企业通过EAI技术将所有应用和数据实现信息共享.能够使企业充分利用外部资源.