【本章学习建议】
根据考试大纲，本章主要考查系统架构设计师单选题，预计考14分左右，对应第二版教材第5章，属于重点考查的章节。
7.1 软件工程
7.1.1 软件工程概述
1. 软件工程定义
软件工程指的是应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，目的是提高软件生产率、提高软件质量、降低软件成本。
2. 软件开发生命周期
·软件定义时期：包括可行性研究和详细需求分析过程，任务是确定软件开发工程必须完成的总目标，具体可分成问题定义、可行性研究、需求分析等。
·软件开发时期：就是软件的设计与实现，可分成概要设计、详细设计、编码、测试等。
·软件运行和维护：就是把软件产品移交给用户使用。
3. 软件系统文档
软件系统文档可以分为用户文档和系统文档两类，用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。
4. 软件工程过程
软件工程过程是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动，包括以下4个方面。
(1) P (Plan) ——软件规格说明。规定软件的功能及其运行时的限制。
(2) D (Do) ——软件开发。开发出满足规格说明的软件。
(3) C (Check) ——软件确认。确认开发的软件能够满足用户的需求。
(4) A (Action) ——软件演进。软件在运行过程中不断改进以满足客户新的需求。
5. 软件设计
软件设计包括四个既独立又相互联系的活动，即数据设计、软件结构（体系结构）设计、人机界面（接口）设计和过程设计。
6. 软件系统工具
软件系统工具按软件过程活动可分为：
·软件开发工具：需求分析工具、设计工具、编码与排错工具、测试工具等。
·软件维护工具：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
·软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。
7.1.2 软件过程模型
软件过程模型习惯上称为软件开发模型，它是软件开发全部过程、活动和任务的结构框架。典型的软件过程模型有瀑布模型、原型模型、螺旋模型、增量模型、喷泉模型、基于构件的开发模型、形式化方法模型、敏捷模型和统一过程模型等。
1. 瀑布模型
瀑布模型将软件生命周期中的各个活动规定为依据线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、测试、运行与维护。如同瀑布流水逐级下落，如图所示。瀑布模型以项目的阶段性评审和文档控制为手段有效地对整个开发过程进行指导，所以它是以文档作为驱动、适合软件需求很明确的软件项目的开发。
优点：容易理解、成本低、强调开发的阶段性早期计划及需求调查和产品测试。
缺点：客户必须能完整、正确和清晰地表达需求；难以评估项目进度状态；项目快结束时，出现大量的集成与测试工作；需求或设计的错误往往只有到了项目后期才能被发现，对项目风险的控制能力较弱，通常会导致项目延期，开发费用超出预算。
2. 原型模型
原型模型（Prototype Model），又称快速原型模型，通过快速构建原型并交付用户使用，收集客户反馈意见，目的是明确当前系统的需求。原型模型适用于用户需求不明确、需求经常变化且系统规模不太大、不太复杂的软件项目。原型应该具备以下特点：（1）实际可行；（2）具有最终系统的基本特征；（3）构造方便、快速，造价低。原型法的特点在于原型法对用户的需求是动态响应、逐步纳入的。
3. 螺旋模型
螺旋模型（Spiral Model），是在快速原型的基础上扩展而成。对于一个复杂的大项目，开发一个原型往往达不到要求。螺旋模型将生命周期模型（瀑布模型）和原型模型结合起来，加入两种模型均忽略的风险分析。螺旋模型中的每个螺旋周期分为四个步骤：目标设定、风险分析、开发和有效性验证以及评审。螺旋模型强调风险分析，与瀑布模型相比，支持用户需求的动态变化。螺旋模型适合用于庞大、复杂且具有高风险的系统。
4. 增量模型
增量模型将需求分段为一系列产品，每一个增量都可以分别开发，如下图所示。
优点：第一个可交付的版本成本和时间很少；降低了适应用户需求变更的成本；具有瀑布模型所有的优点。
缺点：若没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定；由于并不是从系统整体角度规划各个模块，因此不利于模块划分。难点在于如何将客户需求划分为多个增量。与原型不同的是增量模型的每一次增量版本都可作为独立可操作的产品，而原型的构建一般是为了演示。
5. 喷泉模型
喷泉模型是以用户需求为动力、以对象为驱动的模型，适用于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。喷泉模型如下图所示。
优点：各个阶段没有明显的界线，开发人员可以同步进行；可以提高软件项目的开发效率，节省开发时间。
缺点：由于在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，不利于项目的管理；要求严格管理文档，使得审核的难度加大。
6. 基于构件的开发模型CBSD
基于构件的开发模型CBSD是指利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化成品软件构件。特点是增强了复用性，在系统开发过程中，会构建一个构件库，供其他系统复用，因此可以提高可靠性，节省时间和成本。
构件是面向软件体系架构的可复用软件模块。构件（Component）是可复用的软件组成成份，可被用来构造其他软件。它可以是被封装的对象类、功能模块、软件框架（Framework）、软件架构、文档、设计模式等。
7. 形式化方法模型
形式化方法是建立在严格数学基础上的一种软件开发方法，主要活动是生成计算机软件形式化的数学规格说明。
7.1.3 敏捷模型
敏捷开发宣言：个体和交互胜过过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划。
1. 敏捷方法的特点
（1）是“适应性”而非“预设性”。
（2）是“面向人的”而非“面向过程的”。
2. 敏捷方法的核心思想
（1）敏捷方法是适应型，而非可预测型。拥抱变化，适应变化。
（2）敏捷方法是以人为本，而非以过程为本。发挥人的特性。
（3）迭代增量式的开发过程。以原型开发思想为基础，采用迭代增量式开发，发行版本小型化。
3. 主要的敏捷方法
（1）极限编程（XP）：四大价值观：交流、朴素、反馈和勇气。即任何一个软件项目都可以从4个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。
（2）水晶法（Crystal）：与XP方法一样，都有以人为中心的理念，但在实践上有所不同。其目的是发展一种提倡“机动性的”方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。认为人对软件质量有重要的影响，随着开发人员素质的提高，项目和过程的质量也随之提高。
（3）并列争球法（Scrum）：一种迭代的增量化过程，把每段时间(如30天)一次的迭代称为一个“冲刺”(Sprint)，并按需求的优先级别来实现产品，多个自组织和自治的小组并行地递增实现产品。
（4）特征驱动开发方法（FDD) ：是一个迭代的开发模型。FDD认为有效的软件开发需要3个要素：人、过程和技术。FDD有5个核心过程：开发整体对象模型，构造特征列表、计划特征开发、特征设计和特征构建。
7.1.4 统一过程模型（RUP）
统一过程模型RUP描述了如何有效地利用商业的、可靠的方法开发和部署软件，是一种重量级过程。RUP类似一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针、模版以及事例支持。
1. RUP的生命周期
RUP软件开发生命周期是一个二维的软件开发模型，RUP中有 9 个核心工作流，这 9 个核心工作流如下。
• 业务建模(Business Modeling)：理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。
• 需求(Requirements)：定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。
• 分析与设计(Analysis & Design)：把需求分析的结果转化为分析与设计模型。
• 实现(Implementation)：把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统。
• 测试(Test) ：检查各子系统之间的交互、集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。
• 部署(Deployment) ：打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。
• 配置与变更管理(Configuration & Change Management) ：跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
• 项目管理(Project Management) ：为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。
• 环境(Environment) ：为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。
统一过程模型RUP把软件开发生命周期划分为多个循环，每个循环生成产品的一个新的版本，每个循环依次由4个连续的阶段组成，每个阶段完成确定的任务。这4个阶段如下：
（1）初始阶段：定义最终产品视图和业务模型，并确定系统范围。
（2）细化阶段：设计及确定系统的体系结构，制订工作计划及资源要求。
（3）构造阶段：构造产品并继续演进需求、体系结构、计划直至产品提交。
（4）移交阶段：把产品提交给用户使用。
2. RUP中的核心概念
RUP中定义了如下一些核心概念，理解这些概念对于理解RUP很有帮助。
• 角色（Role）：Who的问题。角色描述某个人或一个小组的行为与职责。RUP预先定义了很多角色，如体系结构师（Architect）、设计人员（Designer）、实现人员（Implementer) 、测试员（Tester）和配置管理人员（Configuration Manager）等，并对每一个角色的工作和职责都做了详尽的说明。
• 活动（Activity）：How的问题。活动是一个有明确目的的独立工作单元。
• 制品（Artifact）：What的问题。制品是活动生成、创建或修改的一段信息。也有些书把Artifact翻译为产品、工件等，和制品的意思差不多。
• 工作流（Workflow）：When的问题。工作流描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。
3. RUP的特点
RUP是用例驱动、以体系结构为中心、迭代和增量的软件开发过程。其特点为：
（1）用例驱动：需求分析、设计、实现和测试等活动都是用例驱动的。
（2）以体系结构为中心：包括系统的总体组织和全局控制、通信协议等。是一个多维的结构，会采用多个视图来描述。在典型的4+1视图模型中：
• 分析人员和测试人员关心的是系统的行为，会侧重于用例视图；
• 最终用户关心的是系统的功能，会侧重于逻辑视图；
• 程序员关心的是系统的配置、装配等问题，会侧重于实现视图；
• 系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，会侧重于进程视图；
• 系统工程师关心的是系统的发布、安装、拓扑结构等问题，会侧重于部署视图。
（3）迭代与增量。把整个项目开发分为多个迭代过程。在每次选代中，只考虑系统的一部分需求，进行分析、设计、实现、测试和部署等过程；每次迭代是在己完成部分的基础上进行的，每次增加一些新的功能实现，以此进行下去，直至最后项目的完成。
7.1.5 软件能力成熟度模型
软件过程的能力成熟度模型：
1. 能力成熟度模型CMM
能力成熟度模型CMM是对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步提高。将软件过程的改进分为五个成熟度级别。
2. 能力成熟度模型集成（CMMI）
CMMI是若干过程模型的综合和改进，是支持多个工程学科和领域的、系统的、一致的过程改进框架。CMMI提供了两种表示方法：阶段式模型和连续式模型。
①阶段式模型。结构类似于CMM，它关注组织的成熟度。CMMI-SE/SW/IPPD 1.1版本中有五个成熟度等级。
1）初始级：过程不可预测且缺乏控制。
2）已管理级：过程为项目服务。
3）已定义级：过程为组织服务。
4）量化管理级：过程已度量和控制。
5）优化级：集中过程改进。
②连续式模型。关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级（简称CL）。CMMI中包括六个过程域能力等级：未完成的、已执行的、已管理的、已定义级的、定量管理的、优化的。
7.1.6 逆向工程
1. 软件复用
软件复用是将已有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码级复用，被复用的知识专指程序，后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。
2. 软件的逆向工程
软件的逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。逆向工程的四个级别：
实现级：包括程序的抽象语法树、符号表、过程的设计表示。
结构级：包括反映程序各部分之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构。
功能级：包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型。
领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，例如E-R模型。
其中，领域级抽象级别最高，完备性最低，实现级抽象级别最低，完备性最高。
与逆向工程相关的概念有重构、设计恢复、再工程和正向工程。
（1）重构（重组）是指在同一抽象级别上转换系统描述形式。
（2）设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。
（3）再工程（重构工程）是指在逆向工程所获得信息的基础上，修改或重构已有的系统，产生系统的一个新版本。再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。它不仅能从已存在的程序中重新获得设计信息，而且还能使用这些信息来重构现有系统，以改进它的综合质量。在利用再工程重构现有系统的同时，一般会增加新的需求，包括增加新的功能和改善系统的性能。
（4）正向工程是指不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统，以改善其整体质量。
7.2 需求工程
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望，是指用户解决问题或达到目标所需的条件或权能，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能，以及反映这些条件或权能的文档说明。
软件需求包括3个不同的层次：
• 业务需求：反映了组织机构或客户对系统高层次的目标要求，通常来自项目投资人、客户、市场营销部门或产品策划部门。通过业务需求可以确定项目视图和范围。
• 用户需求：描述了用户使用产品必须要完成的任务，是用户对该软件产品的期望。通常采取用户访谈和问卷调查等方式，对用户使用的场景进行整理，从而建立用户需求。
• 功能需求（也包括非功能需求）：定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。它是从软件系统的角度来说明软件的需求。作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。
需求工程（Requirement Engineering，RE）是指应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述待开发系统及其行为特征和相关约束。
需求工程的活动包括5个阶段：
（1）需求获取
（2）需求分析
（3）形成需求规格，形成软件需求规格说明书SRS。
（4）需求确认与验证，形成需求基线（经过评审的SRS）。
（5）需求管理，包括变更控制、版本控制、需求跟踪、需求状态跟踪等管理性活动。需求管理是对需求基线进行管理。
7.2.1 需求获取
需求获取是开发者、用户之间为了定义新系统而进行的交流，需求获取是获得系统必要的特征，或者是获得用户能接受的、系统必须满足的约束。
常见的需求获取方法：
方法 |
特点 |
用户面谈 |
是理解用户需求最有效的方法。对1-3个有代表性的用户，了解其主观想法。成本高，需要有领域知识支撑 |
需求专题讨论会 |
在短暂而紧凑的时间段内将相关涉众集中在一起集体讨论，与会者可以在应用需求上达成共识，对操作过程尽快取得统一的意见 |
问卷调查 |
适用于用户多、无法一一访谈的情况，成本低 |
现场观察 |
针对较为复杂的流程和操作，全面了解需求细节 |
原型化方法（情节串联板） |
通过开发系统原型以及与用户的多次迭代反馈，解决在早期阶段需求不确定的问题 |
头脑风暴法 |
针对新业务，一群人发散思维，不断产生新的观点，从而确定具体的需求 |
抽样调查/采样 |
是指从种群中系统地选出有代表性的样本集的过程。样本数量=0.25*(可信度因子/错误率)2 |
联合需求计划(JRP) |
通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求 |
7.2.2 需求变更
1. 变更控制过程
变更控制过程用来跟踪已建议变更的状态，使已建议的变更确保不会丢失或疏忽。需求变更管理过程如图所示：
（1）问题分析和变更描述。当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议。
（2）变更分析和成本计算。当接受该变更提议后，需要对需求变更提议进行影响分析和评估。
（3）变更实现。当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型执行相应的变更。
常见的需求变更策略：
（1）所有需求变更必须遵循变更控制过程。
（2）对于未获得批准的变更，不应该做设计和实现工作。
（3）变更应该由项目变更控制委员会（CCB）决定实现哪些变更。
（4）项目风险承担者应该能够了解变更的内容。
（5）绝不能从项目配置库中删除或者修改变更请求的原始文档。
（6）每一个集成的需求变更必须能跟踪到一个经核准的变更请求，以保持水平可追踪性。
2. 变更控制委员会
变更控制委员会（Change Control Board , CCB）是项目所有者权益代表，负责裁定接受哪些变更。CCB是决策机构，不是作业机构。
7.2.3 需求跟踪
需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括其他需求、体系结构、其他设计部件、源代码模块、测试、帮助文件和文档等。
需求跟踪有两种方式：
（1）正向跟踪。检查《产品需求规格说明书》（SRS）中的每个需求是否都能在后继工作成果中找到对应点。
（2）反向跟踪。也称为逆向跟踪，是指检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》（SRS）中找到出处。
7.3 系统分析与设计
系统分析阶段基本任务是系统分析师和用户在充分了解用户需求的基础上，把双方对新系统的理解表达为系统需求规格说明书。
系统设计的目标是根据系统分析的结果，完成系统的构建过程。其主要目的是绘制系统的蓝图，权衡和比较各种技术和实施方法的利弊，合理分配各种资源，构建新系统的详细设计方案和相关模型，指导系统实施工作的顺利开展。
系统设计的主要内容包括概要设计和详细设计。其中概要设计的主要任务是确定软件系统的结构，对系统进行模块划分，确定每个模块的功能、接口和模块之间的调用关系；详细设计的主要任务是为每个模块设计实现的细节。
7.3.1 结构化开发方法
结构化开发方法，也称为面向数据流或功能的开发方法，包括结构化分析（SA）、结构化设计（SD）和结构化编程（SP）。结构化方法总的指导思想是自顶向下、逐层分解，它的基本原则是功能的分解与抽象。
1. 结构化分析
结构化分析方法给出一组帮助系统分析人员产生功能规约的原理与技术。主要包括数据流图、数据字典、结构化语言、判定表以及判定树等。
结构化特点：自顶向下，逐层分解，面向数据。
三大模型：功能模型（数据流图）、行为模型（状态转换图）、数据模型（E-R图）以及数据字典。
（1）数据流图（DFD）
1. 数据流图中的基本图形元素
数据流图中的基本图形元素包括数据流、加工、数据存储和外部实体。
• 数据流：数据的流向。在DFD中，数据流的流向可以有以下几种：从一个加工流向另一个加工；从加工流向数据存储(写)；从数据存储流向加工(读)；从外部实体流向加工(输入)；从加工流向外部实体(输出)。数据流必须与加工有关。除了流向数据存储或从数据存储流出的数据流不必命名外，每个数据流都必须有一个明确的名字。
• 加工：描述了输入数据流到输出数据流之间的变换，也就是输入数据流经过什么处理后变成了输出数据流。一个加工可以有多个输入数据流和多个输出数据流，但至少有一个输入数据流和一个输出数据流。“黑洞”：加工有输入但没输出。“奇迹”：加工没输入但有输出；“灰洞”：加工输入不足以产生输出。
• 数据存储：用来存储数据。DFD中的数据存储在具体实现时可以用文件系统实现，也可以用数据库系统实现。数据存储的存储介质可以是磁盘、磁带或其他存储介质。
• 外部实体：外部实体是指存在于软件系统之外的人员或组织，它指出系统所需数据的发源地和系统所产生的数据的归宿地。例如，对于一个考务处理系统而言，考生向系统提供报名单(输入数据流)，所以考生是考务处理系统的一个数据发源地；而考务处理系统要将考试成绩的统计分析表(输出数据流)传递给考试中心，所以考试中心是该系统的一个数据归宿地。
2. 数据流图的层次结构
一个复杂的软件系统可能涉及上百个加工或数据流，太复杂，也不易理解。于是根据自顶向下逐层分解的思想，将数据流图进行分层。
• 顶层图
顶层图也称上下文数据流图，只有一个加工，代表整个软件系统，该加工描述了软件系统与外界之间（外部实体）的数据流。
• 0层图
顶层图中的加工（即系统）经分解后的图称为0层图。
数据流图（DFD）举例：
3. 分层数据流图的审查
（1）一致性：父图与子图平衡、数据守恒、局部数据存储、输出不能与输入同名。
父图与子图：如果某图(记为A)中的某一个加工分解成一张子图(记为B)，则称A是B的父图，B是A的子图。父图与子图平衡：是指任何一张DFD子图边界上的输入/输出数据流必须与其父图中对应加工的输入/输出数据流保持一致。
数据守恒：通常是指一个加工的所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者能通过该加工的处理而产生。
局部数据存储：一个数据存储应该画在哪些DFD中，不应该画在哪些DFD中。
（2）完整性：①黑洞：是指只有数据输入、没有数据输出的数据加工；
②奇迹：是指没有数据输入只有数据输出的数据加工；
③灰洞：是指输入不足以产生输出的数据加工。
（2）数据字典（DD）
1. 相关概念
数据字典：就是为数据流图中的每个数据流、文件、加工，以及组成数据流或文件的数据项做出说明。
符号 |
含义 |
举例说明 |
= |
被定义为 |
|
+ |
与 |
x=a+b，表示x由a和b组成 |
[...,...]或[...|...] |
或 |
x=[a,b]，x=[a|b]，表示x由a或b组成 |
{...} |
重复 |
x={a}，表示x由0个或多个a组成 |
(...) |
可选 |
x=(a)，表示a可在x中出现，也可以不出现 |
举例：机票=姓名+日期+航班号+起点+终点+费用
终点=[上海|深圳|北京]
2. 数据字典的内容
数据字典的4类条目：数据流、数据项、数据存储、基本加工。
3. 加工逻辑描述（加工规格说明）
在数据流图的分解中，位于层次树最低层的加工也称为基本加工或原子加工，每一个基本加工都需要进一步说明，这称为加工规格说明。
在编写基本加工的规格说明时，主要目的是表达“做什么”而不是“怎么做”。
常用的加工逻辑描述方法（加工规格说明）有结构化语言、判定表（决策表）和判定树（决策树）三种。
2. 结构化设计
结构化设计（Structured Design，SD）是一种面向数据流的设计方法，与SA衔接，是一个自顶向下、逐步求精和模块化的过程，其基本思想是将系统设计成相对独立、功能单一的模块组成的结构，分为概要设计和详细设计两个阶段。
结构化设计的基本原理：
（1）抽象。抽象是一种重要的工具，用来将复杂的现场简化到可以分析、实验或者可以理解的程度。
（2）模块化。是指将一个待开发的软件分解成若干个小的简单部分--模块，每个模块可以独立地开发、测试，最后组装成完整的程序。
（3）信息隐蔽。是将每个程序的成分隐藏或封装在一个单一的设计模块中，在定义每一个模块时尽可能少地显露其内部的处理。对提高软件的可修改性、可测试性和可移植性都有着重要的作用。
（4）模块独立。是指每个模块完成一个相对独立的特定子功能，并且与其他模块之间的联系简单。
（5）耦合与内聚。衡量模块独立程度的标准有两个：耦合性和内聚性（高内聚，低耦合）。
• 耦合是模块之间的相对独立性（互相连接的紧密程度）的度量。
模块的耦合类型 |
|
耦合类型 |
描述 |
非直接耦合 |
两个模块之间没有直接关系，它们之间的联系完全是通过上级模块的控制和调用来实现的，独立性最高 |
数据耦合 |
模块之间通过值传递完成调用关系 |
标记耦合 |
模块之间传递的是数据结构 |
控制耦合 |
模块之间传递的是控制变量 |
通信耦合 |
模块之间共享了输入或输出 |
公共耦合 |
访问同一个公共数据环境（如全局数据结构、共享通信、公共内存等） |
内容耦合 |
一个模块直接访问另一个模块的内部数据；一个模块通过非正常入口转入另一个模块内部；模块之间一部分代码重叠；一个模块有多个入口等 |
• 内聚是模块内部各代码成分之间联系紧密程度的度量。
模块的内聚类型 |
|
内聚类型 |
描述 |
功能内聚 |
完成单一功能，各部分协同工作，缺一不可，是最强的内聚 |
顺序内聚 |
模块内的处理元素都密切相关且按顺序执行 |
通信内聚 |
模块内的所有处理元素集中在一个数据结构的区域上 |
过程内聚 |
模块内的处理元素都密切相关并按特定的次序执行 |
时间内聚 |
模块内的任务必须在同一时间间隔内执行 |
逻辑内聚 |
模块内通过参数确定完成逻辑上相关的一组任务 |
偶然内聚 |
也称巧合内聚，模块内的处理元素之间没有任何联系，是最弱的内聚 |
结构化设计工具：
• 程序流程图(Program Flow Diagram，PFD)，是使用最广泛的一种程序逻辑结构工具。它用方框表示处理步骤，菱形表示逻辑条件，箭头表示控制流向。优点：直观、结构清晰，易于理解、易于修改。缺点：只能描述执行过程而不能描述有关的数据。
• N-S图，也称为盒图，具有强烈的结构化特征，容易表示嵌套和层次关系。但是当问题很复杂时，N-S图可能很大，因此不适合于复杂程序的设计。
• PAD图(Problem Analysis Diagram，PAD)，问题分析图，是一种支持结构化程序设计的图形工具。相比程序流程图，更直观、结构更清晰。最大优点是能够反映和描述自顶向下的历史和过程。
• IPO图(Input-Process-Output，IPO)，也是流程描述工具，用来对每个模块进行详细设计，即详细设计每个模块的输入、输出和数据加工。
• HIPO图(Hierarchy Plus Input-Process-Output，HIPO)，是一种描述系统结构和模块内部处理功能的工具。HIPO图由层次结构图和IPO图两部分构成，前者描述整个系统的设计结构以及各类模块之间的关系，后者描述某个特定模块内部的处理过程和输入/输出关系。
3. 结构化编程
结构化程序设计（Structured Programing , SP）采用自顶向下、逐步求精的设计方法，各个模块通过“顺序、选择、循环”的控制结构进行连接，并且只有一个入口和一个出口。
程序 =（算法）+（数据结构）。
https://edu.csdn.net/course/detail/40283
http://系统架构设计师软考高级辅导班