A5- 软件工程
需求分析
- 软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。
- 根据IEEE的软件工程标准词汇表，软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。
需求的层次 
- 业务需求。是指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。
- 用户需求。描述的是用户的具体目标，或用户要求系统必须能完成的任务。
- 系统需求。是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。
质量功能部署（Quality Function Deployment, QFD）
质量功能部署（Quality Function Deployment, QFD）是一种将用户要求转化成软件需求的技术。其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。
- 常规需求。用户认为系统应该做到的功能或性能，实现越多用户会越满意。
- 期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述白己想要得到的这些功能或性能需求。 如果期望需求没有得到实现， 会让用户感到不满意，
- 意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不实现也不影响其购买的决策。
需求获取
常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等。
需求分析 
一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。
在实际工作中，一般使用实体联系图（E-R图）表示数据模型，用数据流图（DFD）表示功能模型，用状态转换图（STD）表示行为模型。
软件需求规格说明书
- 软件需求规格说明书（Software Requirement Specification, SRS）是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。
在国家标准GB/T 8567-2006中，规定SRS应该包括以下内容：- 范围。
- 引用文件。
- 需求。
- 合格性规定。
- 需求可追踪性。
- 尚未解决的问题。
- 注解。
- 附录。
需求验证
需求验证也称为需求确认，其活动是为了确定以下几个方面的内容：
- SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。
- SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
- 需求是完整的和高质量的。
- 需求的表示在所有地方都是一致的。
- 需求为继续进行系统设计、实现和测试提供了足够的基础。
-
一般通过需求评审和需求测试工作来对需求进行验证。
-
UML
是一种定义良好、易于表达、功能强大且普遍适用的建模语言。 -
UML的结构包括
- 构造块，UML 有三种基本的构造块，分别是事物（thing）、关系（relationship）和图（diagram）。
- 规则，规则是构造块如何放在一起的规定
- 公共机制
-
UML中的事物
- 结构事物：结构事物在模型中属于最静态的部分，代表概念上或物理上的元素。
- 行为事物：行为事物是UML模型中的动态部分，代表时间和空间上的动作。
- 分组事物：分组事物是UML模型中组织的部分
- 注释事物：注释事物是UML模型的解释部分。
-
UML中的关系
- 依赖（dependency）：依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
- 关联（association）: 关联描述一组对象之间连接的结构关系。
- 泛化（generalization）: 泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。
- 实现（realization）: 实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。
-
UML视图
- 逻辑视图：逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
- 进程视图：进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
- 实现视图：实现视图对组成基于系统的物理代码的文件和构件进行建模。
- 部署视图：部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。
- 用例视图：用例视图是最基本的需求分析模型。
面向对象分析
image.png
ü 关联关系。关联提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。关联体现的是对象实例之间的关系。
image.png
依赖关系。两个类A和B, 如果B的变化可能会引起A的变化，则称类A依赖于类B。
image.png
泛化关系。泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说，子类继承了父类，而父类则是子类的泛化。
image.png
共享聚集。共享聚集关系通常简称为聚合关系，它表示类之间的整体与部分的关系，其含义是“部分”可能同时属于多个“整体"，"部分”与“整体”的生命周期可以不相同。
image.png
组合聚集。组合聚集关系通常简称为组合关系，它也是表示类之间的整体与部分的关系。与聚合关系的区别在于，组合关系中的”部分”只能属于一个“整体", "部分”与“整体”的生命周期相同，“部分”随着“整体”的创建而创建，也随着“整体”的消亡而消亡。
image.png
实现关系。实现关系将说明和实现联系起来。接口是对行为而非实现的说明，而类中则包含了实现的结构。一个或多个类可以实现一个接口，而每个类分别实现接口中的操作。
软件架构设计
-
软件架构为软件系统提供了一个结构、行为和属性的高级抽象
-
包括：
- 构件的描述
- 构件的相互作用（连接件）
- 指导构件集成的模式以及这些模式的约束
-
软件架构风格
-
软件架构设计的一个核心问题是能否达到架构级的软件复用，也就是说，能否在不同的系统中，使用同一个软件架构。
-
将软件架构分为
- 数据流风格
- 调用/返回风格
- 独立构件风格
- 虚拟机风格
- 仓库风格。
-
软件架构评估
从目前已有的软件架构评估技术来看， 可以归纳为三类主要的评估方式，分别是基于调查问卷（或检查表）的方式、基于场景的方式和基于度量的方式。这三种评估方式中，基于场景的评估方式最为常用。
软件设计
- 软件设计是需求分析的延伸与拓展。需求分析阶段解决“做什么”的问题，而软件设计阶段解决“怎么做”的问题。
- 结构化设计（SD）
SD方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构，分为概要设计和详细设计两个阶段。- 在概要设计中，将系统开发的总任务分解成许多个基本的、具体的任务
- 为每个具体任务选择适当的技术手段和处理方法的过程称为详细设计
- 面向对象设计（OOD）
OOD是OOA方法的延续，其基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。 - 设计模式
- 根据处理范围不同，设计模式可分为类模式和对象模式。
- 根据目的和用途不同，设计模式可分为创建型模式、结构型模式和行为型模式三种。
软件工程的过程管理
- 软件过程是软件生命周期中的一系列相关活动，即用于开发和维护软件及相关产品的一系列活动。
- 软件产品的质量取决于软件过程，具有良好软件过程的组织能够开发出高质量的软件产品。
软件测试及其管理
-
测试的方法
-
软件测试方法可分为静态测试和动态测试。
-
静态测试是指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检侧。
-
对文档的静态测试主要以检查单的形式进行，而对代码的静态测试一般采用桌前检查（Desk Checking）、代码走查和代码审查。
-
动态测试是指在计算机上实际运行程序进行软件测试，一般采用白盒测试和黑盒测试方法。
- 白盒测试也称为结构测试，主要用于软件单元测试中。
- 黑盒测试也称为功能测试，主要用于集成测试、确认测试和系统测试中。
-
测试的类型
根据国家标准GB/T 15532-2008, 软件测试可分为单元测试、集成测试、确认测试、系统测试、配置项测试和回归测试等类别。
软件集成技术
- 从单个企业的角度来说，EAI可以包括表示集成、数据集成、控制集成和业务流程集成等多个层次和方面。
- 表示集成是黑盒集成，常用的集成技术主要有屏幕截取和输入模拟技术。
- 数据集成是白盒集成。
- 控制集成也称为功能集成或应用集成，是在业务逻辑层上对应用系统进行集成的。控制集成的集成点存于程序代码中，集成处可能只需简单使用公开的 API （ApplicationProgramming Interface，应用程序编程接口）就可以访问，当然也可能需要添加附加的代码来实现。
- 业务流程集成也称为过程集成，这种集成超越了数据和系统，它由一系列基于标准的、统一数据格式的工作流组成。
- EAI技术可以适用于大多数要实施电子商务的企业，以及企业之间的应用集成。EAI 使得应用集成架构里的客户和业务伙伴，都可以通过焦成供应链内的所有应用和数据库实现信息共享。
