1.4、软件工程

软件工程

指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程。目的是为了提高软件生产率、提高软件质量、降低软件成本。 IEEE对软件工程的定义是：讲系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程及以上方法的研究

软件工程由方法 、工具、过程三部分组成
 方法 是完成软件工程项目的技术手段，支持整个软件生命周期
 工具 是人在开发软件活动中智力和体力的扩展与延伸，自动或者半自动的支持软件的开发和管理
 过程 贯穿于软件开发活动的各个环节，对软件开发的质量、进度、成本进行评估、管理和控制，包括人员组织、计划跟踪与控制、成本估算、质量保证和配置管理等

1、需求分析做什么

概念 ：

指用户对系统在功能、行为、性能、设计约束等方面的期望。IEEE中的定义是：指用户解决问题或达到目标所需要的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。

1.1、需求的层级

软件需求就是软件必须完成的事以及必须具备的品质。需求是多层次的，包括业务需求、用户需求和系统需求，这三者是从目标到具体，从整体到局部，从概念到细节。

1、业务需求：反映企业或客户对系统高层级的目标要求（高层级需求）
2、用户需求：描述用户的具体目标，用户想要什么，以及要这些做什么（用户需求）
3、系统需求：从系统的角度说明软件的需求，包括功能需求、非功能需求、设计约束等

1.2、质量功能部署

质量功能部署（Quality Function Deployment, QFD），是一种将用户要求转化成软件需求的技术。目的是最大限度提升软件工程过程中用户满意度。

QDF将软件需求分为三类，分别是
1、常规需求：系统应该做到的，实现的越多，用户越满意
2、期望需求：用户想当然认为系统应该做到，但是不能正确表达的功能，没有实现会让用户不满意
3、意外需求：用户要求范围外的功能或性能，开发人员控制，实现会高兴，不实现也没关系

1.3、需求获取

需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。常见的方式有：用户访谈、问卷调查、采样、情节串联版、联合需求计划等。

1.4、需求分析（SA software analysis）

把杂乱无章的用户要求和期望转化为用户需求，输出需求规格说明书SRS(software requirement specification)

SA方法分析需求的核心是数据字典，分三个模型：
1、数据模型：常用实体关系(E-R)图描述实体、属性，以及实体间的关系；
2、功能模型：常用数据流图(DFD data flow diagram)，从数据传输加工的角度，用图形符号描述数据在系统间的传递情况；
3、行为模型：又称状态模型，常用状态转换图(STD state transform diagram)描述系统状态和引起系统状态转换的事件，表示系统行为，指出作为特定事件的结果将执行哪些动作

OOA基本任务是运用OO方法对问题域进行分析和理解，正确认识其中的事务及其关系，包括：
用例模型：一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模；
分析模型：描述系统的基本逻辑结构，展示对象和类如何组成系统，以及如何保持童心，实现系统行为；

一个好需求应具备：可验证性、无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等

1.5、软件需求规格说明书

需求开发活动的产物，目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。
是一个技术文档，非管理文档，不包括项目预算、进度计划、风险分析等管理内容。

1.6、需求验证

通过需求评审和需求测试工作来对需求进行验证。
需求验证/需求确认包括以下内容：

1、SRS正确的描述 了预期的、满足项目干系人需求的 系统行为和特征；
2、SRS中的软件需求是从系统需求、业务规格和其它内容正确推导出来的；
3、需求是完整的和高质量的；
4、需求的表示在所有地方都是一致的；
5、需求为继续惊喜系统设计、实现和测试提供了足够的基础；

需求管理步骤总结

1、需求获取：工具/技术有 访谈、问卷调查等方法
2、需求分析：工具/技术有 数据模型、功能模型和行为模型
3、需求验证：工具/技术有 需求评审（对SRS技术评审）、需求测试（建模验证是否为真实期望）

1.7、统一建模语言UML

UML，是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，是一种标准的建模方法，较适用于迭代式开发过程。

UML的构成：

1、构造块：
  1.1、 事物：对模型中最具有代表性部分的抽象，分为
  1.1.1、结构事物：概念或物理上的元素，模型中最静态的部分；分别为：类、接口、写作、用例、活动类、构件和节点
  1.1.2、行为事物：时间或空间上的动作，模型中动态的部分；分为：交互、状态机
  1.1.3、分组事物：只有一种，包，将有组织的元素分组的机制，包是概念上的事物; 只存在开发阶段，与构件不同，构件可存在系统运行阶段
  1.1.4、注释事物：解释部分

'-----------------------------------------------------------------------------
  1.2、关系：把事物联系在一起，主要有：
  1.2.1、依赖：两个事物之间的语义关系，一个事物的变化会影响另一个事物
  1.2.2、关联：一组对象间连接的结构关系
  1.2.3、泛化：一般和特殊的关系，描述特殊元素的对象可替换一般元素的对象
  1.2.4、实现：实现和类之间的语义关系，其中一个类制定了由另一个类保证执行的契约

'-----------------------------------------------------------------------------
  1.3、图：多个相互关联的事物的集合
   1.3.1、类图：描述一组类、接口、写作和它们之间的关系
   1.3.2、对象图：描述一组对象及他们之间的关系，描述的内容是在类图中所建立的事物实例的静态快照。
   1.3.3、构件图：描述一个封装的类和它的接口、端口以及由内嵌构建和连接件构成的内部结构。
   1.3.4、组合构件图：描述结构化类的内部结构，及其与系统其余部分的交互点。
   1.3.5、用例图：动态，描述一组用例、参与者及他们间的关系。
   1.3.6、顺序图：一种交互图，动态，展现了一组对象或参与者以及他们之间可能发送的消息构成。交互图专注于系统的动态视图，顺序图是强调消息的时间次序的交互图
   1.3.7、通信图：一种交互图，动态，强调收发消息的对象或参与者的结构组织。顺序图强调的是时序，通信图强调的是对象间的组织结构关系，又称协作图。
   1.3.8、定时图：一种交互图，动态，强调消息跨越不同对象或参与者的实际时间，而不仅仅只关注消息的相对顺序。
   1.3.9、状态图：描述一个状态机，动态，由状态、转移、事件和活动组成。
   1.3.10、活动图：动态，将进程或其它计算结构战示威计算内部一步步的控制流和数据流。
   1.3.11、部署图：描述对运行时的处理节点及在其中生存的构建的配置。
   1.3.12、制品图：描述计算机中一个系统的物理结构。
   1.3.13、包图：描述由模型本身分解而成的组织单元。
   1.3.14、交互概览图：动态，是活动图和顺序图的混合物。

'-----------------------------------------------------------------------------
1.4、UML视图
UML对系统架构的定义是系统的组织结构，包括系统分解的组成部分，以及它们的关联性、交互机制和指导原则等提供系统设计的信息。具体来说就是以下5个系统视图：
1.4.1、逻辑视图：又称设计视图，表示设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集；
1.4.2、进程视图：是可执行线程和进程作为活动类的建模，是逻辑视图的一次执行实例，描述了并发与同步；
1.4.3、实现视图：对组成基于系统的物理代码的文件和构件进行建模；
1.4.4、部署视图：把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构；
1.4.5、用例视图：是最基本的需求分析模型。


UML还允许在一定的阶段隐藏模型的某些元素，一楼某些元素，以及不保证模型的完整性，但模型逐步要达到完整和一致

1.8、面向对象分析

运用OO方法，对问题域进行分析和理解，正确认识其中的事物及它们见的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和指责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细说明。

OOA的任务是“做什么”，OOD的任务是“怎么做”

OOA阶段的核心工作是建立系统的用例模型和分析模型

面向对象分析阶段的核心工作是建立系统的用例模型和分析模型。

1.8.1、用例模型用户视角
SA（结构化分析）方法采用功能分解的方式来描述系统功能，系统功能被分解到各个功能模块中，通过细分的模块功能表达整个系统的功能。

用户不关注系统的内部结构和设计，只关注系统所提供的服务，这就是用例方法的基本思想。

面向对象分析方法中，构建用例模型一般需要经过四个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三阶段是必须的：

1.8.1.1、识别参与者：参与者是与系统交互的所有事物，在系统之外，不是系统的一部分。可通过一些问题帮助识别参与者。
1.8.1.2、合并需求获得用例：

1.8.1.2.1、将获取到的需求分配给相关的参与者；
1.8.1.2.2、进行合并操作，合并之前要了解合并的目的，才能正确的合并；
1.8.1.2.3、合并后产生用例，将参与者和合并后的用例，通过用例图的形式整理出来，获得用例模型的框架

1.8.1.3、细化用例描述：用例建模的主要工作是书写用例规约；
1.8.1.4、调整用例模型：用例之间主要有包含、扩展和繁华三种关系，利用这些关系，把一些公共的信息抽出出来，加以复用，使用例模型更易于维护

1.8.1.4.1、包含关系：表示从两个及以上的用例中提取公共行为。公共行为又称公共用例、抽象用例；原始用例又称基本用例、基础用例
1.8.1.4.2、扩展关系：若一个用例混合了多种场景，则可将该用例分为一个基本用例和多个扩展用例，使描述更加清晰
1.8.1.4.3、泛化关系：当多个用例共同拥有一种类似的结构和行为时，可将共性抽象为父用例，特殊的部分作为子用例。子用例时服用例的一种特殊形式，并且继承了父用例的所有结构、行为和关系。

1.8.2、分析模型系统视角
深入分析需求，获取问题域本质内容的分析模型。分析模型描述了系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持童心，实现系统行为（动态模型）。

建立分析模型过程包括：定义概念类、确定类之间的关系、为类添加职责、建立交互图。

类之间的关系主要有关联、依赖、泛化、聚合、组合和实现等

1.8.2.1、关联关系：两个类的对象实例间的关系，而不是类的关系。关联关系可用关联名称、角色、多重性和导向性说明；
1.8.2.2、依赖关系：一个类随另一个类的变化而变化，则称该类依赖另一个类；
1.8.2.3、泛化关系：一般和特殊的关系，继承是泛化的反关系
1.8.2.4、共享聚集：简称聚合关系，表示类之间的整体与部分的关系，部分可以同时属于多个整体，部分和整体的生命周期可以不同
1.8.2.5、组合聚集，简称组合关系，也是表示类之间的整体和部分的关系，部分只能属于一个整体，部分和整体的生命周期相同
1.8.2.6、实现关系：将说明和实现联系起来，接口是对行为的说明，类则包含了实现的结构，接口可被一个或多个类实现，每个实现可以做不同的操作。

2、软件架构设计

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

2.1、软件架构风格

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式，主要有以下五种

数据流风格：包括批处理序列和管道/过滤两种风格；
调用/返回风格：包括主程序/子程序、数据抽象和面向对象和层次结构
独立构件风格：包括进程通信和事件驱动的系统
虚拟机风格：包括解释器和基于规则的系统
仓库风格：包括数据库系统、黑板系统和超文本系统

2.2、软件架构评估

针对一个或一组架构，评估过程中着重关注系统的质量属性。

敏感点：一个或多个构件的特性
权衡点：影响多个质量属性的特性，是多个质量属性的敏感点。

软件架构评估方式：
2.2.1、基于问卷调查（或检查表）
2.2.2、基于场景（最常用）：

分析软件架构对场景的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。
基于场景的评估方式主要有：
2.2.2.1、架构权衡分析法ATAM
2.2.2.2、软件架构分析法SAAM
2.2.2.3、成本效益分析法CBAM


在架构评估中，通常用刺激、环境和响应三方面对场景进行描述
刺激：场景中解释或买哦书项目干系人怎样引发与系统的交互部分
环境：是刺激发生时的情况
响应：指系统是如何通过架构对刺激作出反应的


由于不同的系统对同一质量属性的理解不同，因此基于场景的评估方式是特定领域的

2.2.3、基于度量

3、软件设计怎么做

软件设计是对需求分析的延伸与拓展，系统实施工作的铺垫。分为结构化设计和面向对象设计

3.1、结构化设计：
结构化设计(SD)是一种面向数据流的方法，以SRS和SA阶段产生的DFD和数据字典等文档为基础，是一个自顶向下，逐步求精和模块化的过程。

3.1.1、基本思想：将软件设计成由相对独立且具有单一功能的模块组成的结构。可分为概要设计和详细设计两阶段

3.1.1.1、概要设计，又称总体结构设计，主要任务是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图(系统结构图)；
3.1.1.2、详细设计：概要设计过程中，将系统开发的总任务分解成多个基本的、具体的任务，为每个具体任务选择适当的技术手段和处理方法的过程称为详细设计。根据任务的不同，详细设计分为输入/输出设计、处理流程设计、数据存储设计、用户界面设计、安全性和可靠性设计等。

3.1.2、基本原则：高内聚、低耦合。内聚是模块内部各成分间的关系程度，耦合是指模块间的联系。

3.2、面向对象设计
OOD是OOA的延续，基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。

数据结构和算法封装在一个对象中。

OOD主要任务：对类和对象进行设计，包括类的属性、方法以及类之间的关系。

OOD的结果就是输出设计模型。

OOD需要解决的问题：支持可维护性的同事，提高软件的可复用性。可维护性的复用是以设计原则为基础，常用的OOD原则有

单一职责原则：设计功能单一的类，高内聚原则；
开放-封闭原则：对扩展开放，对修改封闭；
李氏替换原则：子类可以替换父类；
依赖倒置原则：依赖抽象而不是具体，针对接口编程而非现实；
接口隔离原则：使用多个专门的接口比使用单一的总接口好；
组合重用原则：尽量使用组合而不是继承关系达到重用的目的；
迪米特原则：最少知识法则，一个对象经可能少的了解其它对象，低耦合原则。

3.3、设计模式
前人经验的总结，可以更方便的复用成功的软件设计。

根据处理范围不同，可分为类模式和对象模式

类模式：处理类和子类的关系，通过继承建立关系，在编译时就被确定下来了，属于静态关系

对象模式：处理对象间的关系，关系在运行中时刻变化，动态关系

根据目的和用途不同，可分为创建型模式、结构型模式和行为型模式

创建型模式：主要用于创建对象，包括工厂方法模式、抽象工厂模式、原型模式、单例模式和建造者模式
结构性模式：主要用于处理类或对象的组合，包括适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式
行为型模式：主要用于描述类或对象的交互以及职责的分配，包括指责链模式、命定模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模版方法模式、访问者模式

4、软件工程的过程管理

软件过程是软件生命周期中的一系列相关活动，即用于开发和维护软件及相关产品的一系列活动。

软件产品质量取决于软件过程，具有良好软件过程的组织能够开发出高质量的软件产品。

能力成熟度模型(Capability Maturity Model Integration, CMMI)，融合了多种模型，形成了组织范围内过程改进的单一集成模型，主要目的是消除不同模型间的不一致和重复，降低基于模型进行改进的成本。

阶段式模型：
当组织通过了某一等级过程域中的全部过程，即意味着该组织的成熟度达到了这一等级。利用阶段式模型对组织进行成熟度度量，概念清晰、易于理解、便于操作

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

连续式模型：
将24个过程域按照功能划分为过程管理、项目管理、工程和支持四个过程组

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

5、软件测试及其管理

软件测试的目的是验证软件是否满足软件开发合同或项目开发计划、系统/子系统设计文档、SRS、软件设计说明和软件产品说明等规定的软件质量要求。通过测试，发现软件缺陷，为软件产品的质量测量和评价提供依据。

测试原则：基于测试需求的原则、基于测试方法的原则、兼顾测试充分性和效率的原则、测试执行的可再现性原则

测试用例：包括名称和标识、测试追踪、用例说明、测试的初始化要求、测试的输入、期望的测试结果、评价测试结果的准则、操作过程、前提和约束、测试终止条件。

5.1、测试方法：

静态测试：被测程序不在及其上运行。

文档测试：主要用检查单的形式进行
代码：桌前检查、代码走查和代码审查

动态测试：在计算机上实际运行程序

白盒测试：又称结构测试，主要用于软件单元测试，测试方法主要有控制流测试、数据流测试、程序变异测试、人工检查代码（静态）、逻辑覆盖（最常用）
黑盒测试：又称功能测试，主要用于集成测试、确认测试和系统测试中。测试方法主要有等价类划分、便捷之分析、判定表、因果图、状态图、随机测试、猜错发和正交试验法

5.2、测试的类型：

5.3、面向对象测试
面向对象测试与传统测试目标一致，但是策略不同，主要体现在两方面，一是测试焦点从模块转移向类，二是测试视角扩大到分析和设计模型。

基于面向对象的三大特征，面向对象测试也有三大难点：

封装性：决定面向对象系统的测试必须考虑到信息隐蔽原则对测试的影响，以及对象与类的测试序列
继承性：决定了面向对象系统的测试必须考虑到集成对测试充分性的影响，以及误用引起的错误
多态性：决定了面向对象系统的测试必须考虑到动态绑定对测试充分性的影响、抽象类的测试，以及误用对测试的影响。

5.4、软件调试
根据错误迹象确定错误原因和准确位置，并加以改正。

5.5、软件测试管理
软件测试的管理包括过程管理、配置管理和评审工作

过程管理：包括测试活动管理和测试资源管理，测试应有相对独立的人员进行
配置管理：应按照软件配置管理的要求，将测试过程中产生的各种工作产品(测试工具、被测软件、测试支持软件、评审结果)纳入配置管理。
评审工作：包括测试就绪评审（针对测试计划、测试用例）、测试评审（针对测试记录，测试报告）

6、软件集成技术

企业应用集成(Enterprise Application Integration,EAI),一种软件层次的集成技术，将多个企业信息系统连接起来，实现无缝集成，消除信息孤岛。
常用的集成手段包括：

表示集成：界面集成，黑盒集成，将用户界面作为集成点
数据集成：中间件作为集成点，白盒集成，比表示集成灵活
控制集成：功能集成、应用集成，黑盒集成，将应用逻辑作为集成点，集成处可以用API访问，兼容前两种集成方式的手段，且具有更高的灵活性和复杂性
业务流程集成：过程集成，超越了数据和系统，由一系列基于标准的统一数据格式的工作流组成
企业间应用集成：EAI可适用于大多数要实施电子商务的企业以及企业间的应用集成

7、软件维护

软件正式交付用户后，进入漫长的维护期，从性质上分为：

7.1、纠错型维护：纠正在开发阶段产生，但是在测试和验收过程中没有发现的错误，包括：设计错误、程序错误、数据错误、文档错误
7.2、适应型维护：为适应软件运行环境改变而做的修改，包括：规则或规律变化、硬件配置变化、数据格式或文件结构变化、软件支持环境变化
7.3、预防型维护：将潜在的漏洞在实际发生前就进行修复
7.4、完善型维护：主要工作，为扩充功能或改善性能而进行的修改，包括：扩充范围和算法优化；提高速度、节省空间；改进易读性增加注释；