信息系统项目管理（三）软件工程相关知识

软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生成率、提高软件质量、降低软件成本。

一、需求分析

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

1.1 软件需求层次

软件的需求主要分为三个层次，从低到高依次是系统需求、用户需求和业务需求

1.1.1 系统需求

系统需求主要是从系统角度来说明软件需求，包括功能需求、非功能需求和设计约束

1. 功能需求：规定开发人员必须在系统中实现的软件功能，满足业务需要
2. 非功能需求：系统必须具备的除功能需求外的特性，其中包括软件质量属性
   • 性能需求：响应时间、吞吐量、资源利用率等
   • 安全性、可靠性、可维护性与易用性等等
3. 设计约束：系统的限制条件或补充说明，如系统必须采用国产数据库系统

1.1.2 用户需求

用户需求指用户要求系统必须能完成的任务或功能

1.1.3 业务需求

业务需求是客户对相同高层次的目标要求，通过业务需求可以确定项目范围和视图，来自于项目投资人

1.2 需求分析与定义

1.2.1 质量功能部署

质量功能部署(Quality Function Deployment, QFD)是将用户要求转化成软件需求的技术，目的是最大限度的提升用户的满意度。QFD将软件需求分成三类，分别是常规需求、期望需求和意外需求

1. 常规需求：用户认为系统应该做到的功能或性能，实现越多用户越满意
2. 期望需求：用户不能正确描述想要得到的功能需求，想当然认为系统应具备的功能或性能
3. 意外需求：用户要求范围外的功能或性能，实现这些需求用户会更高兴，但不实现也不影响其购买的决策

二、对象和类

2.1 面向对象的基本概念

1. 对象：由数据及其操作所构成的封装体，是构成系统的基本单位
2. 类：类和对象的关系为，对象是类的实例，类是对象的模板
3. 抽象：通过特定的实例抽取共同特征以后形成概念的过程。比如对象是现实中某个实体的抽象，类是一组对象的抽象
4. 封装：将相关概念组成一个单元模块，并通过一个名称来引用它。只能通过对象对外提供的接口进行调用
5. 继承：表示类之间层次关系，这种关系使得某类对象可以继承另外一类对象的特征
6. 多态：使得在多个类可以定义同一个操作或属性名，并在每个类中可以有不同的实现
7. 接口：描述对操作规范的说明
8. 消息：体现对象间的交互，通过它向目标对象发送操作请求
9. 组件：表示软件系统中可替换的、物理的组成部分
10. 复用：指将已有的软件及其有效成分用于构造新的软件或系统。组件技术是软件复用实现的关键
11. 模式：描述了一个不断重复发生的问题，以及该问题的解决方案。包括特定环境、问题和解决方案三个组成部分。

2.2 类之间的关系

类与类之间有不同的关系，主要有这六类：

1. 关联(Association)：关联提供了不同类对象之间的结构关系，关联系统的是对象实例之间的关系，不表示两个类之间的关系
2. 依赖(Dependency)：两个类A和B，如果B的变化可能引起A的变化，则称类A依赖于类B
3. 泛化(Generalization)：泛化描述一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。而继承关系是泛化关系的反面，可以这样说，子类继承了父类，父类是子类的泛化。
4. 聚合(Aggregation)：表示类之间的整体与部分的关系，部分可能同时属于多个”整体”，”部分”与”整体”的生命周期可以不相同
5. 组合(Composition)：表示类之间的整体与部分的关系，但不可分
6. 实现(Realization)：一个类或多个类可以实现一个接口，而每个类分别实现接口中的操作

三、统一建模语言UML

UML(Unified Modeling Language) 是一种定义良好、易于表达、功能强大而且普遍使用的建模语言，它融入软件工程领域的新思想、新方法和新技术，作用域不限于支持面向对象分析（Object-Oriented Analysis，OOA）和面向对象设计（Object-Oriented Design，OOD）,支持从需求分析开始的软件开发全过程。

UML 独立于软件开发过程，它不是程序设计语言，是一种可视化的建模语言。

3.1 UML中的关系

UML 用关系把事物结合在一起，主要有以下四种关系（也就是类与类之间的6种关系）：

1. 依赖（dependency）：两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义

2. 关联（association）：描述一组对象之间连接的结构关系

   • 聚合(Aggregation)：两个对象是整体与部分，可以分割
   • 组合(Composition)：两个对象是整体与部分，但是无法分割

3. 泛化（generalization）：一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象

4. 实现（Realization）：一个类或多个类实现一个接口，其中的每个类分别实现接口的操作

四、软件架构设计

软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构件之间的对应关系，提供了一些设计决策的基本原理。

4.1 软件架构风格

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式（idiomatic paradigm），核心问题是达到架构级的软件复用。Garlan 和Shaw对通用软件架构风格进行了以下分类：

4.1.1 数据流风格

数据流风格顾名思义，所有的数据是按照流的形式在执行过程中前进，不存在结构的反复与重构。主要包括批处理序列和管道-过滤器两种具体的架构风格。

1. 批处理序列：每一步处理都是顺序且独立执行的，如下图所示：

4.1.2 调用/返回风格

调用返回就是指在系统中采用了调用和返回的机制。包括面向对象风格、主程序/子程序，层次结构三种：

1. 主程序/子程序风格：这种风格是结构化开发时期的经典架构风格，比如方法调用子函数就是这种架构风格

2. 面向对象风格：这种风格建立在数据抽象和面向对象的基础上，对象是通过函数和过程的调用来交互

4.1.3 独立构件风格

独立构件风格主要强调系统中的每个构件都是相对独立的个体，它们之间不通信，以降低耦合度，提升灵活度。主要包括进程通讯和事件系统子风格

1. 进程通讯架构风格：构件是独立的过程，连接件是消息传递。
2. 事件系统风格：构件不直接调用一个过程，而是触发或广播一个或多个事件。

4.1.4 虚拟机风格

人为构建一个运行环境，在这个环境之上，可以解析与运行自定义的一些语言，这样可以增加架构的灵活性。主要包括解释器和规则为中心的两种架构风格。

1. 解释器：具有解释器风格的软件中含有一个虚拟机，可以仿真硬件执行过程和一些关键应用。
2. 规则为中心：基于规则的系统包括规则集、规则解释器、规则选择器及工作内存

4.1.5 仓库风格

仓库风格中有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行，仓库与外构件间的相互作用在系统中会有大的变化。仓库风格主要包括数据库系统、超文本系统和黑板风格。

1. 数据库系统：也就是常见的数据库系统设计

2. 超文本系统：早期的静态 页

3. 黑板系统：解决复杂的非结构化问题，能在求解过程中综合运用不同知识源，使得问题的表达、组织和求解变得容易。

   7.2 数据集成

   数据集成是白盒集成，必须首先对数据进行标识并编成目录，另外还要确定元数据模型，保证数据在数据库系统中分布和共享。如分布式数据库提供连接的数据库访问中间件技术（数据中间件）

   7.4 业务流程集成

   也叫做过程集成，这种集成超越了数据和系统，它由一系列基于标准的、统一数据格式的工作流组成。它不仅要提供底层应用支撑系统之间的互联，同时要实现存在于企业内部的应用之间，本企业和其他合作伙伴之间的端到端的业务流程的管理。比如企业-银联-银行资金业务及流程集成。

   声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！