信息化和信息系统（4）

软件工程

一、需求分析

软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。
1、需求的层次
（1）业务需求：业务需求是指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。
（2）用户需求：用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务。
（3）系统需求：****系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。
①功能需求：也称为行为需求。它规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务 ，满足业务需要。
② 非功能需求：是指系统必须具备的属性或品质 ,又可细分为软件质量属性和其他非功
能需求。
③设计约束：也称为限制条件或补充规约 ,通常是对系统的一些约束说明。
2、质量功能部署
质量功能部署（ QFD）是一种将用户要求转化成软件需求的技术，它将软件需求分为三类，分别是常规需求、期望需求和意外需求。
（1）常规需求：用户认为系统应该做到的功能或性能，实现越多用户会越满意。
（ 2）期望需求：用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现 ，会让用户感到不满意。
（ 3）意外需求：意外需求也称为兴奋需求，是用户要求范围外的功能或性能，实现这需求用户会更高兴，但不实现也不影响其购买的决策。
3、需求获取是一个 确定和理解不同的项目干系人的需求和约束的过程。常见的需求获取方法包 括用户访谈、问卷调查、采样、情节串联板、联合需求计划等。
4、需求分析
一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性。使用 SA 方法进行需求分析，其建立的模型的核心是数据字典，围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型。在实际工作中，一般使用实体联系图（E-R 图）表示数据模型，用数据流图（ DFD）表示功能模型，用状态转换图（ STD）表示行为模型。
5、软件需求规格说明书
软件需求规格说明书（ SRS）是需求开发活动的产物，编制该文档的目的 是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。
6、需求验证
需求验证也称为需求确认，其活动是为了确定以下几个方面的内容。
① SRS 正确地描述了预期的、满足项目干系人需求的系统行为和特征。
② SRS 中的软件需求是从系统需求、 业务规格和其他来源中正确推导而来的。
③ 需求是完整的和高质量的。
④ 需求的表示在所有地方都是一致的。
⑤ 需求为继续进行系统设计、实现和测试提供了足够的基础。
在实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。需求评审就是对SRS 进行技术评审。

二、UML

UML 是一种定义良好、易于表达、功能强大且普遍适用的建模语言。
1、UML 中的关系
UML 用关系把事物结合在一起，主要有下列四种关系：
（1）依赖：依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
（2）关联：关联描述一组对象 之间连接的结构关系。
（3）泛化：泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。
（4）实现：实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。
2、UML2.0 中的图
UML2.0 包括 14 种图，分别列举如下：
（1）类图：类图描述一组类、接口、协作和它们之间的关系。类图给出了系统的静态
设计视图，活动类的类图给出了系统的静态进程视图。
（2）对象图：对象图描述一组对象及它们之间的关系。
（3）构件图：构件图描述一个封装的类和它的接口、端口，以及由内嵌的 构件和连接件构成的内部结构。
（4）组合结构图：组合结构图描述结构化类的内部结构，包括结构化类与系统其余部分的交互点。
（5）用例图：用例图描述一组用例、参与者及它们之间的关系。
（6）顺序图（也称序列图）：顺序图是一种交互图，交互图展现了一种交互，它由一组对象或参与者以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。
（ 7）通信图：通信图也是一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图强调的是时序，通信图强调的是对象之间的组织结构（关系）。
（8）定时图（也称计时图）：定时图也是一种交互图，它强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序。
（ 9）状态图：描述了一个特定对象的所有可能状态以及由于各种 事件的发生而引起的状态之间的转移。
（10）活动图：活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它强调对象间的控制流程。
（11）部署图：部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图。
（12）制品图：制品图描 述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件。
（13）包图：包图描述由模型本身分解而成的组织 单元，以及它们之间的依赖关系。
（14）交互概览图：交互概览图是活动图和顺序图的混合物。
3、UML 视图
（1）逻辑视图：逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要
意义的部分，即类、子系统、包和用例实现的子集。
（2）进程视图：进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一
次执行实例，描述了并发与同步结构。
（3）实现视图：实现视图对组成基于系统的物理代码的文件和构件进行建模。
（ 4）部署视图：部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分
布结构。
（5）用例视图：用例视图是最基本的需求分析模型。
4、类之间的关系表示
（1）关联关系。关联提供了不同类的对象之间的结构关系，它在一段时间内将多个类
的实例连接在一起。。
（2）依赖关系。两个类 A 和 B，如果 B 的变化可能会引起 A 的变化，则称类 A 依赖于类B。
（3）泛化关系。泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间 的关系。继承关系是泛化关系的反关系，也就是说，子类继承了父类，而父类则是子类的泛化。
（4）共享聚集。表示类之间的整体与部分的关系，例如，汽车和车轮就是聚合关系，车子坏了，车轮还可 以用：车轮坏了，可以再换一个新的。
（5）组合聚集。类之间的整体与部分的关系。例如，一个公司包含多个部门，它们之
间的关系就是组合关系。公司一旦倒闭，也就没有部门了。
（6）实现关系。实现关系将说明和实现联系起来。

三、软件架构设计

1、软件架构风格
软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构件之间的对应关系，提供了一些 设计决策的基本原理。
软件架构研究的主要内容涉及软件架构描述、软件架构风格、软件架构评估和软件架构的形式化方法等。解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。
软件架构设计的核心问题：是能否达到架构级的软件复用。
（1）数据流风格：包括批处理序列和管道／过滤器两种风格。
（2）调用／返回风格：包括主程序／子程序、数据抽象和面向对象，以及层次结构。
（3）独立构件风格：包括进程通信和事件驱动的系统。
（4）虚拟机风格：包括解释器和基于规则的系统。
（5）仓库风格：包括数据库系统、黑板系统和超文本系统。
2、软件架构评估
①不同类型的系统需要不同的架构，甚至一个系统的不同子系统也需要不同的架构；
②软件架构评估可以只针对一个架构，也可以针对一组架构；
③在架构评估过程中，评估人员所关注的是系统的质量属性。

四、软件设计

需求分析阶段解决“做什么”的问题，而软件设计阶段解决“怎么做”的问题。从方法上来说，软件设计分为结构化设计与面向对象设计。
1、结构化设计
SD 是一种面向数据流的方法，基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构，分为 概要设计和详细设计两个阶段。在 SD 中，需要遵循一个基本的原则：高内聚，低耦合。内聚表示模块内部各成分之间的联系程度；耦合表示模块之间联系的程度。
2、面向对象设计（OOD）
OOD 是 OOA（面向对象分析）方法的延续，对于 OOD 而言，在支持可维护性的同时，提高软件的可复用性是一个至关重要的问题，如何同时提高软件的可维护性和可复用性，是 OOD需要解决的核心问题之一。
3、设计模式
（ 1）设计模式是前人经验的总结，它使人们可以方便地复用成功的软件设计。设计模式包含模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式等基本要素。
（ 2）根据处理范围不同，设计模式可分为类模式和对象模式。类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，属于静态关系；对象模式处理对象之间的关系，这些关系在运行时刻变化，更具动态性。
（ 3）根据目的和用途不同，设计模式可分为创建型模式、结构型模式和行为型模式三种。创建型模式主要用于创建对象；结构型模式主要用于处理类或对象的组合；行为型模式主要用于描述类或对象的交互以及职责的分配。

五、过程管理

（1）阶段式模型。
表 1-2 过程域的阶段式分组

（2）连续式模型
表 1-3 连续式模型的过程域分组

六、软件测试

软件测试的目的是验证软件是否满足软件开发合同或项目开发计划、系统／子系统设计文档、SRS、软件设计说明和软件产品说明等规定的软件质量要求。 GB/T 15532-2008 还规定了测试用例设计原则和测试用例要素。
软件测试方法可分为静态测试和动态测试。静态测试是指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态测试包括对文档的静态测试和对代码的静态测试。对文档的静态测试主要以检查单的形式进行，而对代码的静态测
试一般采用桌前检查、代码走查和代码审查。
动态测试是指在计算机上实 际运行程序进行软件测试，一般采用白盒测试和黑盒测试方法。
1、测试的方法
白盒测试也称为结构测试，主要用于软件单元测试中。它的主要思想是，将程序看作是一个透明的白盒，测试人员完全清 楚程序的结构和处理算法。白盒测试方法主要有控制流测试、数据流测试和程序变异测试等。另外，使用静态测试的方法也可以实现白盒测试。
黑盒测试也称为功能测试，主要用于集成测试、确认测试和系统测试中。黑盒测试将程序看作是一个不透明的黑盒，完全不考虑（或不了解）程序的内部结构和处理算法，而只检查程序功能是否能按照 SRS 的要求正常使用。
2、测试的类型
软件测试可分为单元测试、集成测试、确认测试、系统测试、配置项测试和回归测试等类别。
（1）单元测试也称为模块测试，其目的是检查每个模块能否正确地实现设计说明中的功能、性能、接口和其他设计约束等条件，发现模块内可能存在的各种差错。单元测试的技术依据是软件详细设计说明书。
（2）集成测试。集成测试的目的是检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。
（3）**确认测试。确认测试主要用于验证软件的功能、性能和其他特性是否与用户需求一致。**根据用户的参与程度，通常包 括以下类型。
•内部确认测试。
•Alpha 测试和 Beta 测试。Alpha 测试是指由用户在开发环境下进行测试； Beta 测试是指由用户在实际使用环境下进行洌试。
•验收测试。验收测试 的目的是，在真实的用户工作环境下，检验软件系统是否满足开发技术合同或 SRS。
（4）系统测试。系统测试的目的是在真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统／子系统设计文档和软件开发合同规定的要求。
（5）配置项测试。配置项测试的对象是软件配置项，配置项测试的目的是检验软件配置项与 SRS 的一致性。
（6）回归测试。回归测试的目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。
3、软件测试管理
（1）过程管理：包括测试活动管理和测试资源管理；
（2）配置管理：结束软件测试工作时，全部测试工 具、被测软件、测试支持软件和评审结果已纳入配置管理；
（3）评审：测试过程中的评审包括测试就绪评审和测试评审。
七、软件集成技术
企业应用集成技术可以消除信息孤岛，它将多个企业信息系统连接起来，实现无缝集成，使它们就像一个整体一样。包括表示集成、数据集成、控制集成和业务流程集成等多个层次和方面。
1、表示集成也称为界面集成，这是比较原始和最浅层次的集成，但又是常用的集成。这种方法将用户界面作为公共的集成点，把原有零散的系统界面 集中在一个新的界面中。表示集成是黑盒集成。

2、数据集成
数据集成是白盒集成，为了完成控制集成和业务流程集成，必须首先解决数据和数据库的集成问题。在集成之前，必须首先对数据进行标识并编成目录，另外还要确定元数据模型，保证数据在数据库系统中分布和共享。
3、控制集成
控制集成也称为功能集成或应用集成，是在业务逻辑层上对应用系统进行集成的。控制集成是黑盒集成。
4、业务流程集成
业务流程集成也称为过程集成，这种集成超越了数据和系统，它由一系列基于标准的、统一数据格式的工作流组成。当进行业务流程集成时，企业 必须对各种业务信息的交换进行定义、授权和管理，以便改进操作、减少成本、提高响应速度。
5、企业之间的应用集成
EAI 技术可以适用于大多数要实施电子商务的企业，以及企业之间的应用集成。 EAI 使得应用集成架构里的客户和业务伙伴都可以通过集成供应链内的所有应用和数据库实现信息共享。能够使企业充分利用外部资源。