四、软考·系统架构师——软件工程基础

系列文章

一、程序员进阶架构师的基础知识【计算机基础】
二、程序员进阶架构师的基础知识【操作系统】
三、程序员进阶架构师的基础知识【计算机网络基础】
四、程序员进阶架构师的专业知识【软件工程基础】
五、程序员进阶架构师的专业知识【UML建模工具】
六、程序员进阶架构师的专业知识【系统分析】
七、程序员进阶架构师的专业知识【系统设计】
八、程序员进阶架构师的专业知识【架构设计】
九、程序员进阶架构师的专业知识【架构质量及评估】
十、程序员进阶架构师的专业知识【软件测试及维护】

前言

• 软件的第一个时期：自己开发，自己使用
  20世纪50年代，软件伴随着第一台电子计算机诞生了。以写软件为职业的人也开始出现，他们多是经过训练的数学家和电子工程师。大多数软件是由使用该软件的个人研发的，主要依靠个人编程技巧，没有什么系统的方法可循。
• 软件的第二个时期：团队开发，别人使用
  20世纪60年代至70年代，随着计算机的发展，软件也开始作为一种产品被广泛使用，出现了“软件作坊”，小团队合作专职为别人写软件，但是仍然以个人编程为主。
• 软件危机
  随着软件的数量增大，需求也日趋复杂，维护难度也越来越大，失败的软件项目也越来也多，原来以个人设计、开发的方式已经无法满足，“软件危机”就这样开始了。1968年NATO组织的计算机学术会议上提出的“软件危机”概括来说包含两方面：
  1. 如何开发软件以满足不断增长、日趋复杂的需求。
  2. 如何维护数量不断膨胀的软件产品。

概述

软件工程是研究如何用系统化、规范化、数量化等工程原则和方法去进行软件的开发和维护，包括两方面：

1. 软件开发技术：软件开发技术包括软件开发方法、软件开发工具、软件工程环境。
2. 软件项目管理：软件项目管理包括软件开发计划、成本管理、进度管理、人力资源管理、质量管理、风险管理等。

• 软件工程的诞生
  1968年秋季NATO召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策，在会议上第一次提出了“软件工程”的概念。
• 软件工程的发展
  软件工程的不断发展中，人们进行了不懈的努力，这些努力大致沿着2个方向同时进行的：
  1. 从管理的角度，希望软件开发过程如建筑一样工程化：
     业主提出需求->设计建筑方案->施工->验收交付
     这方面最著名的成果就是提出了大家都很熟悉的“瀑布式”生命周期模型：
     分析->设计->实现>运行和维护
     它是在“软件危机”后出现的第一个生命周期模型。后来，又有人针对该模型的不足，提出了原型模型、螺旋模型、喷泉模型等对“瀑布式”模型进行补充。
  2. 第二个方向侧重于对软件开发过程中分析、设计的方法研究。这方面最著名的成果就是70年代风靡一时的结构化开发方法。

一句话理解软件工程：按照某种方法使用某种工具执行相关过程研制开发出具有良好软件质量和费用合算的产品。 这里的“某种方法”即开发方法（比如结构化开发方法）、“某种工具”（比如建模工具、开发软件等）、相关过程即为软件的生命周期。

软件生命周期

  软件生命周期是软件的产生到报废的生命周期，把整个生命周期分为三大阶段，分别为定义、软件开发、软件维护。使得每个阶段有明确的任务，使规模大、结构复杂和管理复杂的软件开发变的容易控制和管理。

• 定义阶段：该阶段的目的是为了确定总目标，通常把该阶段细分为问题定义、可行性研究、需求分析3个阶段。其中：
  • 问题定义、可行性研究阶段是软件开发方和需求方共同讨论，确定软件开发的目标及可行性。
  • 需求分析阶段在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，它直接决定软件项目的成败。（具体分析过程请移步《系统分析》）
• 软件开发阶段：该阶段的目的是为了设计与实现，又可以分为软件设计、编码、测试3个阶段。其中：
  • 软件设计阶段（概要设计、详细设计）主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。
  • 软件编码阶段是将软件设计的结果转换成计算机可运行的程序代码。
  • 软件测试阶段需要经过严密的测试，以发现软件在整个设计及实现过程中存在的问题并加以纠正。
• 软件运行和维护阶段：该阶段是将软件交付给用户后，软件生命周期中持续时间最长的阶段，包括更正性维护、适应性维护、预防性维护、完善性维护，其中：
  • 更正性维护是诊断和修正系统中遗留的错误，出现错误后修正。
  • 适应性维护是系统适应环境的变化而进行的维护工作。
  • 完善性维护是软件在使用过程中为了满足用户提出新的功能及性能要求而对系统进行扩展及改进的工作。
  • 预防性维护是说应对系统进行主动的发现或分析即将可能会出现的问题，不应总是被动地等待用户提出要求后才进行，目的是为未来的修改与调整奠定更好的基础。

软件开发模型

  软件开发模型是对软件开发过程的抽象和概括，是对开发过程各阶段之间关系的描述、约束和表示，能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。

瀑布模型

  瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

  各活动之间有以下关系：

• 上一次活动结果为本次活动的输入。
• 利用这一次输入实施本活动。
• 本次活动的输出给下次活动。
• 对本次活动成果进行评审，若取得确认继续下一项活动，否则返回前一项甚至更前项活动。

  这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：

• 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
• 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险。
• 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

快速原型模型

  快速原型模型是通过和客户的交流快速建立原型，实现客户和系统的交互，通过用户对原型的评价，进一步细化软件的需求，通过逐步调整原型满足客户的需求。

• 优点：通过与客户的频繁交流，任何功能一经开发就可测试，以便验证是否符合产品需求。克服了瀑布模型的缺点，减少因需求不明确带来的风险。
• 缺点：如果不加以控制让用户接触开发中尚未稳定的功能，可能对开发人员及用户都会产生负面影响。

螺旋模型

  螺旋模型将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

  螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：

• 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件。
• 风险分析：分析评估所选方案，考虑如何识别和消除风险。
• 设计实施：实施软件设计、开发和验证。
• 客户评估：评价开发工作，提出修正建议，制定下一步计划。

喷泉模型

  喷泉模型认为软件开发过程自下而上，周期的各阶段是相互迭代和无间隙的特性。迭代是指软件的某个部分会被重复工作多次，相关对象在每次迭代中加入渐进的软件成分，逐步完善。无间隙指在各项活动之间无明显边界，如分析工作没有完全结束就可以先进行部分设计工作。

• 优点：
  1. 以用户需求为驱动的模型，支持逐步完善需求，不要求用户早期确定所有需求。
  2. 由于各阶段无间隙的特征，各阶段开发人员可以同步开发，提高开发效率，节省项目时间。
• 缺点：
  1. 由于各阶段无间隙的特征，因此在开发过程中需要大量的开发人员，不利于项目的管理。
  2. 要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。

RUP统一过程模型

  软件开发模型的出现是为了消除软件危机，随着客观世界不断变化，面对新情况、新问题，原有的模型将无法胜任。90年代开始，出现了一些现代软件开发模型，如RUP、敏捷模型等。
  RUP经过多年总结了商业化验证的6条最有效的软件开发经验，被称为“最佳实践”。分别为：迭代式开发、管理需求、使用基于构件的体系结构、可视化建模、验证软件质量、控制软件变更。如图所示，它是一个大的迭代过程：横坐标表示软件所处的4个阶段，纵坐标表示软件在每个阶段的工作流。

• 初始阶段：建立初步的系统模型，掌握大致用户的需求，定义开发环境的初步方案。包括明确项目规模、评估项目风险、制定项目计划、阶段技术评审。
• 细化阶段：进行详细的系统分析、设计系统的架构，进一步细化需求。包括确定架构、制定构件阶段计划、建立支持环境、选择构件、阶段技术评审。
• 构建阶段：对系统进行详细设计，并进行编码、测试、集成等。
• 移交阶段：确定目标是否实现，是否开始另一次迭代。补充各种文档，并把系统移交给用户。

RAD快速应用开发

  RAD是基于构件的开发模型，其目的是为了快速实现软件的开发，在确定需求后选择一些现有的构件进行组装、设计、修改等，达到快速开发。其分为以下几个阶段：

• 规划阶段：用户、开发人员、管理人员确定业务需求、项目范围、系统需求等，审核后进入下一阶段。
• 设计阶段：获取需求的细节，构建原型。
• 实现阶段：编码、单元测试、系统测试。
• 运行阶段：数据准备、用户培训。

软件能力成熟度模型CMM

   软件能力成熟度模型（Capability Maturity Model ，简称CMM）是一种对软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述形成的标准，用于评价软件机构的软件过程能力成熟度的模型。分为5个等级：

• 初始级：未加定义的随意过程，软件的过程是无秩序的，有时甚至是混乱的。软件的过程定义几乎处于无章法和步骤可循的状态。
• 可重复级：规则化和纪律化的过程，软件过程已经定义了基本的项目管理过程，对项目的成本、进度和功能特性进行跟踪，对类似的项目有章可循并能重复以往的成功。
  已定义级：用于管理的软件过程均已文档化、标准化，并形成了整个软件组织的标准软件过程。全部项目均可采用此软件过程进行操作。
  已管理级：已管理级是可预测过程，软件过程和产品质量有详细的度量标准。软件过程和产品质量得到定量的认识和控制。
  优化级：持续改进的过程，通过对新概念、新技术等方面进行定量分析，不断的、持续的对过程进行改进。

软件开发方法

  软件开发方法是对软件开发过程中分析、设计两个阶段的方法论以及研究成果。从70年代发展至今诞生了不同类别的开发方法，对于不同需求的系统使用不同的开发方法。

• 开发方法按照开发风范有：
  • 自顶向下：将一个大问题划分多个小的问题，逐一解决。每个问题都有一个模块去解决，且每个问题包括抽象步骤和具体步骤。
  • 自底向上：根据系统功能要求，从具体的器件、逻辑部件或相似的系统开始，凭借设计者熟练的技巧和丰富的经验对其进行连接、修改和扩大，构成所要求的一个系统。
• 开发方法按照性质有：
  • 形式化：基于严密的、数学上的形式机制的系统研究方法。
  • 非形式化：各种开发模型。

结构化开发方法

  结构化方法由结构化分析、结构化设计、结构化程序设计构成，它是一种面向数据流的开发方法。结构化方法总的指导思想是自顶向下、逐层分解。其特征为：

• 开发目标清晰：保持与客户沟通，明确系统的功能需求，确定系统的边界，让客户了解工作进展、校准工作方向。
• 开发工作阶段化：每个阶段完成后进行评审，便于项目管理与控制。
• 开发文档规范化：每个阶段完成后按照要求完成相应的文档，保证系统维护工作的便利。
• 设计方法结构化：自顶向下分解，进行分析与设计。根据设计要求编写各功能模块，自底向上实现。

  其缺点是：开发周期长，难以适应需求变化。

  结构化分析是根据分解和抽象的原则，按照系统中数据处理的流程，用数据流图建立系统功能模型，从而完成需求分析工作。结构化分析结果由以下几部分组成：

• 数据流图：便于用户理解、分析系统数据流程的图形工具。
• 数据字典：对数据流图中的数据流、加工及其他数据项加以描述。
• 加工逻辑的描述：利用结构化语言、判定表和判定树对加工逻辑进行描述。
• 补充材料

  结构化设计是根据模块独立性准则、 软件结构优化准则将数据流图转换成软件的体系结构，用软件结构图来建立系统的物理模型，实现系统的概要设计。
  结构化程序设计使用3种基本控制结构构造程序，任何程序都可以由顺序、选择和 重复3种基本控制结构构造。

面向对象开发方法

  面向对象开发方法将面向对象的思想应用于软件开发过程中，指导开发活动，是建立在“对象”概念基础上的方法学，简称OO( Object-Oriented)方法。由面向对象分析(OOA)、面向对象设计(OOD)、面向对象程序设计(OOP)构成。
  面向对象开发方法发展历程

名称	描述
Coad/Yourdon方法	强调OOA和OOD采用完全一致的概念和表示法，使两者不需要转换
Booch方法	开发模型包括静态模型和动态模型，静态模型分为逻辑模型（类图、对象图）和物理模型（模块图、进程图），用来描述系统的构成和结构。动态模型包括状态图和顺序图，用来描述对象的状态及交互过程
OMT方法	使用了建模的思想，采用对象模型（对象图）、动态模型（状态图）和功能模型（数据流图）来建立应用模型
OOSE方法	使用用例取代了DFD进行需求分析和建立功能模型

  面向对象分析是确定需求或者业务的角度，按照面向对象的思想来分析业务。以用例驱动进行建模（UML建模工具）分析出功能模型（用例图）、动态模型（状态图、顺序图、活动图）、对象模型（类图）。
  面向对象设计是对分析阶段的模型进行细化并延伸，额外产出架构图、包图等。

构件化开发方法

  构件化是指软件体系结构可重组以及软件成分可以复用的开发方法，基于构件的软件开发是解决复杂环境下软件规模与复杂性的一种手段，可以提高软件的开发效率和质量。构件通过连接件连接在一起，其特征是可独立部署的单元、作为第三方的组装单元、没有外部可见状态。

• 构件的获取
  1. 从现有构件中获取、直接使用或做适应的修改得到可复用的构件。
  2. 通过遗留工程，将具有潜在复用价值的构件提取出来，得到可复用的构件。
  3. 从市场购买现成的构件。
  4. 开发新的符合需求的构件。
• 构件的分类
  • 关键字分类：将应用领域的概念从抽象到具体的顺序逐次分解为树形或有向无回路图结构，每个概念用一个关键字描述。
  • 刻面分类：用于刻画构件特征的“刻面”，每个面包含若干概念，这些概念描述构件在刻面上的特征。
  • 超文本分类：所有构件必须辅以详细的功能或行为说明文档。检索者在阅读文档的过程中可以任意跳转到相关构件或概念的文档。
• 构件的复用方法
  1. 检索与提取构件
  2. 理解与评价构件
  3. 修改构件
  4. 组装构件
• 构件的检索方法
  • 关键字检索：系统在图形用户界面上将构件库的关键字以树形结构展现，复用者通过对树形结构逐级预览，寻找需要的关键字并提取相应的构件。
  • 刻面检索：基于刻面分类法，由3步构成，分别是构造查询、检索构件和对构件进行排序。
  • 超文本检索：复用者给出数个关键字，系统在构件说明文档进行精准或模糊匹配，匹配成功后向复用者列出响应的构件说明。

面向服务开发方法

  在构件化基础上产生的思想，对于跨构件的功能调用，采用接口的形式暴露出来，进一步将接口的定义与实现进行解耦，催生了面向服务开发方法。其有3个抽象级别：

• 操作：单个逻辑单元的事务，包含特定的结构化接口，并返回结构化响应。
• 服务：操作的逻辑分组。
• 业务流程：为实现特定业务目标而执行一组长期运行的活动。

  在面向服务开发的过程中，存在多个服务，通常复杂的IT环境中的服务层都同时使用了多种技术，而实现不同技术的服务之间的互联性障碍给应用集成带来了极大的困难，这时候引入了服务总线（ESB）。ESB支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。ESB的功能主要体现在通信、服务交互、应用集成、服务质量、安全性以及管理和监控等方面。

• 通信：ESB能够支持消息路由/寻址，支持多种通信技术、通信协议(如JMS、HTTP)，支持发布/订阅的通信模式，能够处理请求/响应、同步以及异步的消息传递方式，并且要求以可靠的方式传递消息。
• 服务交互：ESB上所发布的服务是以当前标准的Web服务描述语言(WSDL)来定义Web服务的，并且ESB上通常配备有服务目录和发现机制。
• 服务质量：集成不同系统的同时，必须考虑服务质量方面的问题，如事务性和消息传递的可靠性。
• 安全性：对于关键的Web服务，ESB需要以加密的方式进行消息传递，并且必须验证访问者的权限。

快速原型法

   原型法与结构化方法对立，结构化方法在系统开发初期必须明确系统的功能，确定系统边界，原型法则是根据用户的初步需求利用系统工具快速建立系统模型与用户交流。

• 按照实现功能划分
  • 水平原型：行为原型，用于界面。细化需求但未实现功能。
  • 垂直原型：结构化原型，用于复杂算法的实现，实现部分功能。
• 按照最终结果划分
  • 抛弃式：探索式原型，解决需求的不确定性，与用户需求不一致时直接抛弃。
  • 演化式：逐步演化成最终系统，用于易于升级和优化的系统。

敏捷开发方法

   敏捷开发方法是一种应对快速变化的需求的一种软件开发能力，相对于“非敏捷”，其思想是：小步快走、以人为本，与客户紧密协作、面对面沟通，减少不必要的文档、尽早发布增量功能、小而自主的开发团队，适用于规模小的项目。

• xp极限编程
  极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法，通常采用测试先行的方式执行。
  • 为什么称为“Extreme”（极限）？“Extreme”（极限）是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、做到最好；其它所不提倡的，XP则一概忽略（如开发前期的整体设计等）。一个严格实施XP的项目，其开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。由以下几点保证：
    • 在更短的周期内，更早地提供具体、持续的反馈信息。
    • 在迭代的进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断的发展它。
    • 依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。
    • 依赖于口头交流、测试和源程序进行沟通。
    • 倡导持续的演化式设计。
    • 依赖于开发团队内部的紧密协作。
    • 尽可能达到程序员短期利益和项目长期利益的平衡。
  • 核心价值观是：沟通、简单、反馈和勇气；即任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。
• Scrum争求并列
  Scrum 是一个用于开发和维护复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周。迭代周期工作：
  • 高优先级的需求驱动：使用Product Backlog来管理需求，在开发需求的时候，从Backlog最上层的高优先级的需求开始开发。
  • 执行Sprint：只要有足够1-2个Sprint开发的细化了的高优先级的需求，我们就可以启动Sprint了。
  • 每日检视和调整：每个开发团队成员都应该参与每日站会，一起检验Sprint目标的进展情况，跟进当天的工作情况调整计划。
  • 梳理产品列表：每个Sprint都需要花一些时间来准备下一个Sprint，主要用来梳理产品列表，包括PBI的创建和细化、估算和排列优先级顺序。
  • 检视和调整产品与过程：每个Sprint结束后，开发团队都要参加两个检视和调整的活动，即Sprint评审会议（Sprint Review Meeting）和 Sprint回顾会议（Sprint Retrospective Meeting）。
• Cockburn水晶方法
  水晶方法遵循敏捷方法思想，保证了产品开发的进度，较好的满足了客户的需求，使开发过程顺利实施。但在产品开发过程中，不能运用单一的敏捷方法，应该要根据项目的具体情况，借鉴多种方法，取长补短，形成新的敏捷思维（不同项目，不同策略）。