1.4 软件工程

定义：将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程即上述方法的研究

软件工程由方法、工具和过程三个部分组成

1.4.1 需求分析

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

需求层次

1. 业务需求：是反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门
2. 用户需求：描述的是用户的具体目标，或用户要求系统必须完成的任务
3. 系统需求：从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束

质量功能部署

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

• 常规需求：用户认为系统应该做到的功能或性能
• 期望需求：用户想当然认为系统应具备的功能或性能，但不能正确描述自己想要得到这些功能或性能需求，如果期望需求没有得到实现，用户会感到不满意
• 意外需求：也称为兴奋需求，使用户要求范围外的功能或性能

需求获取

需求获取是一个确定或理解不同的项目干系人的需求和约束的过程。

常见的需求获取方法：用户访谈、问卷调查、采样、情节串联版、联合需求计划
信息系统项目需求获取的方法：问卷调查、会议讨论、界面原型、可运行原型系统

需求分析

需求分析人员需要把杂乱无章的用户要求和期望转化为用户需求、这就是需求分析工作。

一个好的需求应该具有：无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性。

需求分析的方法：

• 结构化分析方法：
  • 数据模型：实体联系图、ER图
  • 功能模型：数据流图、DFD–Data Flow Diagram
  • 行为模型：状态转化图、STD–State Transform Diagram
• 面向对象分析方法：OOA
  • 使用用例模型方法来描述系统需求
  • 使用分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及他们如何保持通信，实现系统行为（动态模型）

需求软件规格说明书

需求软件规格说明书：Software Requirement Specification SRS，是需求开发活动的产物，编制目的是是项目干系人与开发团队对系统的初始规定有一个共同的理解，使其成为整个开发工作的基础。

• 范围
• 引用文件
• 需求（SRS主体部分）
• 合格性规定
• 需求可追踪性
• 尚未解决的问题
• 注解
• 附录

需求验证

需求验证也成需求确认，主要确认下面几个内容：

• SRS正确的描述了预期的、满足干系人需求的系统行为和特征
• SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的
• 需求是完整的和高质量的
• 需求的表示在所有的地方都是一致的
• 需求为继续进行系统设计、实现和测试提供了足够基础
• 通过需求评审和需求测试工作来对需求进行验证

对象 = 属性+方法

UML

UML：Unified Modeling Language，统一建模语言，支持从需求分析开始的软件开发的全过程。是一个支持模型化和软件系统开发的图形化语言、为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。

组成UML的3个要素

• 基本构造块（事物、关系和图）
• 规则（支配这些构造块如何放置在一起）
• 机制（运用于整个语言的机制）

事物：也成建模元素

• 结构事物：是静态部分，类、接口、协作、用例、活动类、构件和节点
• 行为事物：是动态部分，代表时间和空间上的动作，一种是交互，另一种是状态机
• 分组事物：是组织部分，UML只有一种分组事物，称为包
• 注释事物：UML解释部分

关系：UML用关系把事物结合在一起

• 依赖：两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义
• 关联：描述一组对象之间连接的结构关系
• 泛化：一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的额对象
• 实现：类之间的语义关系，其中的一个类指定了有另一个类保证执行的契约

图：

• 类图：实体类的静态关系，是软件的蓝图，详细描述了系统内各个对象的相关的类，以及这些类之间的静态关系
  

• 对象图：表示某一时刻类的对象静态结构和行为
  

• 构件图：描述类的实现环境
  

• 用例图：用户观察到系统功能的模型图，列出了系统中的用例和参与者。显示哪个参与者参与了哪个用例的执行。用于业务建模、需求获取、定义。静态
  

• 顺序图：用于显示对象间的交互活动，关注对象之间消息传送的时间顺序。
  

• 状态图：利用状态和事件描述对象本身的行为。动态
  

• 活动图：通过动态来组织，主要用于描述某一方法、机制或用例的内部行为
  

• 部署图：描述系统所需的硬件构件的物理部署。
  
  UML 视图：就是对上面图的分类

• 用例视图：最基本的需求分析模型，如用例视图

• 逻辑视图：也称为设计视图，如类图、对象图以及包图

• 进程视图：可执行线程和进程作为活动类的建模，他是逻辑视图的一次执行实例，描述了并发与同步结构，如状态图、活动图、时序图等

• 实现视图：对组成基于系统的物理代码的文件和构件进行建模，如构件图

• 部署视图：把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构，如部署图

面向对象分析

1.4.2 软件架构设计

软件架构设计核心问题：是能否达到架构级的软件复用，能否在不同的系统中，使用同一个软件架构。

解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。

软件复用有利于节省工期、减少成本、保持质量

软件架构的风格

1. 数据流风格：包括批处理序列和管道/过滤器风格
   

2. 调用/返回风格：包括主程序/子程序、数据抽象和面向对象，以及层次结构
   

3. 独立架构风格：包括进程通信和事件驱动系统
   基于事件驱动的系统，有点类似设计模型的观察者模式，由构件公布或者广播一些事件，其他构件对此事件进行注册。当这个事件被触发时，立即通知这个事件上注册的过程

4. 虚拟机风格：包括解释器和基于规则的系统
   具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键的应用，解释器通常被用来建立一种虚拟机一弥补语义上的差异

5. 仓库风格：包括数据库系统、黑板系统和超文本系统
   

软件架构评估

敏感点：一个或者多个构件的额特性

权衡点：是影响多个质量属性的特性，是多个质量属性敏感点

• 基于调查问卷方式
• 基于场景方式
• 基于度量方式

1.4.3 软件设计

软件设计是需求分析的延伸和拓展

需求分析阶段：解决“做什么”的问题
软件设计阶段：解决“怎么做”的问题

1. 结构化设计SD：
   • 自顶向下、逐步求精
   • 模块化、相对独立
   • 高内聚、低耦合
2. 面向对象的设计OOD
   • 抽象、封装和可扩展
   • 遵循OOD设计原则
3. 设计模式
   • 包含模式名称、问题、目的、解决方案、效果、实例代码等

1.4.4 软件工程的过程管理

CMMI：Capability Maturity Model Integration是指能力成熟度模型集成

CMMI是一种为组织有效性提供基本要素的过程改进方法，它的目的是帮助软件企业对软件工程进行管理和改进，增强开发与改进能力从而能按时、不超预算的开发出高质量的软件。

CMMI过程域可分为4类：项目管理、过程管理、工程和支持四个级别

CMMI有阶段式和连续式两种表现方式：

• 使用阶段式表示法使你能达到“成熟度级别”，阶段式表示法用于模型整体
• 使用连续式表示法使你能达成“能力级别”。连续式表示用于单个过程域

过程域的阶段式分组

连续式分组

1.4.5 软件测试及管理

测试是在软件交付给客户之前所必须完成的重要步骤。

1.4.5.1 测试方法

• 静态测试：采用人工检测和计算机辅助静态分析的手段对程序进行检测。
• 动态测试：在计算机上实际运行程序进行软件测试。白盒测试与黑盒测试

1.4.5.2 测试类型

• 单元测试：模块测试
• 集成测试：模块之间接口联调
• 确认测试：验证软件功能、性能和其它特性是否与用户需求一致
• 系统测试：对象是完整的、集成的计算机系统。黑盒测试，真实环境下验证
• 配置测试：软件配置
• 回归测试：软件变更之后

1.4.5.3 面向对象测试

• 封装性：考虑信息隐蔽对测试的影响
• 继承性：考虑继承对充分性的影响
• 多态性：考虑动态绑定对测试充分性影响

1.4.5.4 软件调试

测试与调试的区别

• 测试的目的是找出错误，调试的目的是定位错误并修正错误
• 调试是测试之后的活动，测试和调试在目标、方法和思路上都有所不同
• 测试从一个已知的条件开始，使用预先定义的过程，由预知的结果；调试从一个未知的条件开始，结束的过程不可预计
• 测试过程事先设计，进度可以事先确定；调试不能描述过程或持续时间

1.4.5.5 软件测试管理

• 过程管理
• 配置管理
• 评审工作
  • 测试就绪评审
  • 测试评审

1.4.5.6 软件集成技术

企业应用集成：Enterprise Application Integration EAI，企业应用集成可以消除信息孤岛，将多个企业信息系统连接起来，实现无缝集成，使之像一个整体一样。EAI所连接的应用包括各种电子商务系统、ERP、CRM、SCM、OA、数据库系统和数据仓库。

1. 表示集成
   也称页面集成，是把原有零散的系统页面集中在一个新的页面中；为用户提供看上去统一，但是有多个系统组成的应用系统；当只有可能在显示界面上实现集成时。
   

2. 数据集成

   • 通过不同的中间件工具完成数据集成
   • 数据集成比表示集成更加灵活，但是当业务逻辑发生变化时，数据集成就会面临困难
     

3. 控制集成
   也称功能集成和应用集成

   • 在业务逻辑层上对应用系统进行集成
   • 借助于远程过程或方法调用、面向消息的中间件、分布式对象技术和事物处理监控器来实现
   • 与数据集成和表示集成相比，灵活性更高
   • 当被集成业务系统没有提供API时，集成难度会增加
     

4. 业务集成
   也称过程集成
   业务流程集成超越了数据和系统，有一些列基于标准、统一数据格式的工作流完成

5. 企业之间集成
   EAI技术使用用大多数电子商务企业，完成企业之间的应用集成。目的是实现信息共享，是企业充分利用外部资源。