软考高级之系统架构师之系统开发基础
架构
场景
场景（scenarios）在进行体系结构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该体系结构优劣的标准。为得出这些目标而采用的机制做场景。场景是从风险承担者的角度对与系统的交互的简短描述。在体系结构评估中，一般采用刺激（stimulus）、环境（environment）和响应（response）三方面来对场景进行描述
在进行体系结构（架构）评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该体系结构优劣的标准。我们把为得出这些目标而采用的机制叫做场景。场景是从风险承担者的角度对与系统的交互的简短描述。在体系结构评估中，一般采用刺激、环境和响应三方面来对场景进行描述。刺激是场景中解释或描述风险承担者怎样引发与系统的交互部分。例如，用户可能会激发某个功能，维护可能会做某个更改，测试人员可能会执行某种测这些都属于对场景的刺激。环境描述的是刺激发生时的情况。例如，当前系统处于什么状态？有什么特殊的约束条件？系统的负载是否很大？某个网络通道是否出现了阻塞等。响应是指系统是如何通过体系结构对刺激作出反应的例如，用户所要求的功能是否得到满足?维护人员的修改是否成功?测试人员的测试是否成功等。
软件
软件重用
分垂直式重用与水平式重用，垂直式重用是指局限于某一垂直领域的重用，如只在电力系统中用到的构件；而水平式重用是指通用领域的重用，如标准函数库，任何软件都能用，所以是水平式重用。
软件复用
软件复用过程：创建、复用、支持、管理4个过程。
创建过程：界定和提供可复用资产，以满足复用者的需要
复用过程：利用可复用资产来生产应用软件产品
支持过程：全面支持可复用资产的获取、管理和维护工作
管理过程：执行计划、启动、资源、跟踪，并协调其他各个过程；
SDE
软件开发环境（Software Development Environment，SDE）是指支持软件的工程化开发和维护而使用的一组软件，由软件工具集和环境集成机制构成。
软件开发环境应支持多种集成机制：如平台集成、数据集成、界面集成、控制集成和过程集成。软件开发环境应支持小组工作方式，并为其提供配置管理，环境的服务可用于支持各种软件开发活动，包括分析、设计、编程、调试和文档等。 较完善的软件开发环境通常具有多种功能，例如，软件开发的一致性与完整性维护，配置管理及版本控制，数据的多种表示形式及其在不同形式之间的自动转换，信息的自动检索与更新，项目控制和管理，以及对开发方法学的支持。软件开发环境具有集成性、开放性、可裁减性、数据格式一致性、风格统一的用户界面等特性，因而能大幅度提高软件生产率。
软件开发环境应支持多种集成机制，根据功能的不同，集成机制可以划分为环境信息库、过程控制与消息服务器、环境用户界面三个部分。
- 环境信息库。环境信息库是软件开发环境的核心，用以存储与系统开发有关的信息，并支持信息的交流与共享。环境信息库中主要存储两类信息，一类是开发过程中产生的有关被开发系统的信息，例如分析文档、设计文档和测试报告等；另一类是环境 提供的支持信息，如文档模板、系统配置、过程模型和可复用构件等。
- 过程控制与消息服务器。过程控制与消息服务器是实现过程集成和控制集成的基础。过程集成时按照具体软件开发过程的要求进行工具的选择与组合，控制集成使各工具之间进行并行通信和协同工作。
- 环境用户界面。环境用户界面包括环境总界面和由它实行统一控制的各环境部件及工具的界面。统一的、具有一致性的用户界面是软件开发环境的重要特征，是充分发挥环境的优越性、高效地使用工具并减轻用户的学习负担的保证。
文档
在初步项目范围说明书中已文档化的主要的可交付物、假设和约束条件的基础上准备详细的项目范围说明书，是项目成功的关键。范围定义的输入包括以下内容：① 项目章程。如果项目章程或初始的范围说明书没有在项目执行组织中使用，同样的信息需要进一步收集和开发，以产生详细的项目范围说明书。② 项目范围管理计划。③ 组织过程资产。④ 批准的变更申请。
用户文档
用户文档主要描述所交付系统的功能和使用方法，并不关心这些功能是怎样实现的。用户文档是了解系统的第一步，它可以让用户获得对系统准确的初步印象。 用户文档至少应该包括下述5方面的内容：
功能描述：说明系统能做什么
安装文档：说明怎样安装这个系统以及怎样使系统适应特定的硬件配置
使用手册：简要说明如何着手使用这个系统（通过丰富的例子说明.怎样使用常用的系统功能，并说明用户操作错误是怎样恢复和重新启动的）
参考手册：详尽描述用户可以使用的所有系统设施以及它们的使用方法，并解释系统可能产生的各种出错信息的含义（对参考手册最主要的要求是完整，因此通常使用形式化的描述技术）
操作员指南（如果需要有系统操作员的话）：说明操作员应如何处理使用中出现的各种情况。 系统文档是从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是非常重要的。
系统文档
项目
项目范围说明书
项目范围定义的输入有：
①项目章程。如果项目章程或初始的范围说明书没有在项目执行组织中使用，同样的信息需要进一步收集和开发，以产生详细的项目范围说明书
②项目范围管理计划
③组织过程资产
④批准的变更申请
项目范围是为了达到项目目标，为了交付具有某种特制的产品和服务，项目所规定要做的。在信息系统项目中，产品范围是指信息系统产品或者服务所应该包含的功能，项目范围是指为了能够交付信息系统项目所必须做的工作。产品范围是项目范围的基础，产品的范围定义是信息系统要求的度量，而项目范围的定义是生产项目计划的基础。产品范围描述是项目范围说明书的重要组成部分。
初步范围说明书
最初的项目范围说明书是依据发起人或赞助人提供的信息制定的，并由项目管理团队在范围定义过程中进一步细化。内容包括：
- 项目和范围的目标
- 产品或服务的需求和特性
- 项目的需求和可交付物
- 产品验收的标准
- 项目的边界
- 项目约束条件
- 项目假设
- 最初的项目组织
- 最初定义的风险
- 进度里程碑
- 对项目工作的初步分解
- 初步的量级成本估算
- 项目配臵管理的需求
- 审批要求
详细范围说明书
范围定义的主要交付物是范围说明书，它详细描述项目的可交付物以及产生这些可交付物所必须做的项目工作。项目范围说明书在在所有干系人之间建立一个对项目范围的共同理解，描述项目的主要目标，使项目团队能进行更详细的计划，指导项目团队在项目实施期间的工作，并为评估是否为客户需求进行变更或附加的工作是否在项目范围之内提供基准。内容如下：
（1）项目的目标。包括成果性目标和约束性目标。
（2）产品范围描述。描述项目承诺交付的产品、服务或成果的特征。
（3）项目的可交付物。包括项目的产品、服务或成果，以及附属产出物例如项目管理报告和文档。
（4）项目边界。边界严格定义了哪些事项属于项目，也明确说明什么事项不属于项目的范围。
（5）产品验收标准。明确界定了验收可交付物的过程和原则。
（6）项目的约束条件。描述和列出具体的于西南股范围有关的约束条件，约束条件对项目团队的选择会造成影响。
（7）项目的假设。描述并列出特定的与项目范围相关发的假设，以及当这些假设不成立时对项目潜在的影响。
成本管理
成本管理过程包括：成本估算、成本预算与成本控制。成本预算的含义是将总的成本估算分配到各项活动和工作包上，来建立一个成本的基线。成本估算是对完成项目活动所需资金进行近似的估算。
时间管理
包括使项目按时完成所必需的管理过程。项目时间管理中的过程包括：活动定义、活动排序、活动资源估算、活动历时估算、制定进度计划、进度控制。
SV，Schedule Variance，进度偏差=已完工程计划时间—已完工程实际时间。
当进度偏差为负值时，表示进度滞后；当进度偏差等于零时，表示实际与计划相符。当进度偏差为正值时，表示进度提前。
CV，Cost Variance，成本偏差 = 挣值（EV）- 实际成本（AC）
当CV为正值时，表示实际消耗的人工（或费用）低于预算值，即有结余或效率高；当CV等于零时，表示实际消耗的人工（或费用）等预算值；当CV为负值时，表示实际消耗的人工（或费用）超出预算值或超支。
为了得到工作分解结构（Work Breakdown Structure，WBS）中最底层的交付物，必须执行一系列的活动。对这些活动的识别以及归档的过程就是活动定义。
鱼骨图（Ishikawa图）是一种发现问题根本原因的方法，通常用来进行因果分析。
可行性分析
可行性分析是所有项目投资、工程建设或重大改革在开始阶段必须进行的一项工作。项目的可行性分析是对多因素、多目标系统进行的分析、评价和决策的过程。
可行性研究通常从经济可行性、技术可行性、法律可行性和用户使用可行性4个方面来进行分析：
- 经济可行性也称为投资收益分析或成本效益分析，主要评价项目的建设戍本、运行成本和项目建成后可能的经济收益。经济收益可以分为直接收益、间接收益、有形收益和无形收益等。
- 技术可行性也称为技术风险分析，研究的对象是信息系统需要实现的功能和性能，以及技术能力约束。
- 法律可行性也称为社会可行性，具有比较广泛的内容，它需要从政策、法律、道德、制度等社会因素来论证信息系统建设的现实性。
- 用户使用可行性也称为执行可行性，是从信息系统用户的角度来评估系统的可行性，包括企业的行政管理和工作制度、使用人员的素质和培训要求等。
配置项
软件产品配置是指一个软件产品在生存周期各个阶段所产生的各种形式和各种版本的文档、计算机程序、部件及数据的集合。该集合的每一个元素称为该产品配置中的一个配置项。
配置项是构成产品配置的主要元素，配置项主要有以下两大类：
- 属于产品组成部分的工作成果：如需求文档、设计文档、源代码和测试用例等;
- 属于项目管理和机构支撑过程域产生的文档：如工作计划、项目质量报告和项目跟踪报告等。这些文档虽然不是产品的组成部分，但是值得保存。
配置项的状态通常包括：草稿、正式发布、正在修改。
管理工具
软件配置管理工具是指支持完成配置项标识、版本控制、变化控制、审计和状态统计等任务的工具，主要有下述功能：
- 配置支持：配置是一组有共同目的的中间软件产品，其中每一个中间软件产品称为一个配置项。软件配置管理支持用户建立配置项之间的各种关系，并对这些关系加以维护，维护这些关系有助于完成某些特定任务(例如Build)和标识某一变化对整个系统开发的影响。
- 版本控制：版本控制是软件配置管理的基本要求，它可以保证在任何时刻恢复任何一个版本、版本控制还记录每个配置项的发展历史，这样就保证了版本之间的可追踪性，也为查找错误提供了帮助，版本控制也是支持并行开发的基础。
- 变更控制：是指在整个软件生存周期中对软件变更的控制。变更控制系统记录每次变更的相关信息(变更的原因、变更的实施者以及变更的内容等)。这些信息有助于追踪出现的各种问题。
- 构造支持：软件系统往往由许多配置项构成，建立整个系统是个复杂和费时的过程，软件配置管理工具可以记录和追踪每个配置项信息，帮助用户自动和快速地建立系统，和版本控制结合在一起，可以有效地支持同时开发系统的多个版本。
- 过程支持。过程详细描述各种人员在整个软件生存周期中如何使用整个系统，过程控制可以保证每一步都按照正确的顺序由合适的人员实施。过程控制本来是软件开发环境中一个独立的部分，软件配置管理也开始提供这部分功能。软件配置管理工具对过程的支持还很不够，而且支持方式差别也很大，许多管理只是提供一个预先定义好的生存周期模型，并保证开发的每一步都按照这个模型规定进行。
- 团队支持。团队支持是指多个开发人员同时开发一个软件系统。大多数软件系统都需要多个开发人员参与，有效的团队支持对开发人员是很有用的。团队支持主要包括工作区管理、并行开发管理和远程开发管理（某些软件配置管理工具还包括对开发人员支持）。
基准测试
大多数情况下，为测试新系统的性能，用户必须依靠评价程序来评价机器的性能。把应用程序用的最多、最频繁的那部分核心程序作为评价计算机性能的标准程序，称为基准测试程序（benchmark）。
真实程序、核心程序、小型基准程序和合成基准程序，其评测的准确程度依次递减。
事务处理性能委员会（Transaction Processing Performance Council，TPC）是制定商务应用基准程序（Benchmark）标准规范、性能和价格度量，并管理测试结果发布的非营利组织，其发布的TPC-C是在线事务处理的基准程序，TPC-D是决策支持的基准程序。
Web服务器性能指标主要有请求响应时间、事务响应时间、并发用户数、吞吐量、资源利用率、每秒钟系统能够处理的交易或者事务的数量等。
需求
需求特性
理想情况下，每一项用户、业务需求和功能需求都应具备下列性质：
- 完整性：每一项需求都必须完整地描述即将交付使用的功能
- 正确性：每一项需求都必须正确地描述将要开发的功能
- 可行性：需求必须能够在系统及其运行环境的已知能力和约束条件内实现
- 必要性：每一项需求记录的功能都必须是用户的真正需要
- 无歧义：每一项需求声明对所有读者应该只有一种一致的解释
- 可验证性：如果某项需求不可验证，那判定其实现的正确与否就变成主观臆断。
需求定义
需求定义的过程也就是形成需求规格说明书的过程，通常有两种需求定义的方法： 严格定义方法和原型方法。
严格定义方法，也称为预先定义，需求的严格定义建立在以下基本假设之上：
- 所有需求都能够被预先定义。这意味着在没有实际系统运行经验的情况下，全部的系统需求均可通过逻辑推断得到。但这种假设在许多场合是不能成立的。
- 开发人员与用户之间能够准确而清晰地交流。
- 采用图形（或文字）可以充分体现最终系统。在使用严格定义需求的开发过程中，开发人员与用户之间交流与沟通的主要工具是定义报告，包括文字、图形、逻辑规则和数据字典等技术工具。
原型化的需求定义过程是一个开发人员与用户通力合作的反复过程。从一个能满足用户基本需求的原型系统开始，允许在开发过程中提出更好的要求，根据用户的要求不断地对系统进行完善，它实质上是一种迭代的循环型的开发方式。
使用原型方法时需注意几个问题：
- 并非所有的需求都能在系统开发前被准确地说明
- 项目干系人之间通常都存在交流上的困难
- 需要实际的、可供用户参与的系统模型
- 有合适的系统开发环境
- 反复是完全需要和值得提倡的。需求一旦确定，就应该遵从严格定义的方法
需求管理
需求管理的活动包括：
- 变更控制
- 版本控制
- 需求跟踪
- 需求状态跟踪
需求跟踪
需求跟踪包括编制每个需求与系统元素之间的联系文档，这些元素包括别的需求、体系结构、其他设计部件、源代码模块、测试、帮助文件和文档等。跟踪能力信息使变更影响分析十分便利，有利于确认和评估实现某个建议的需求变更所必须的工作。 利用需求跟踪能力链（traceability link）可以跟踪一个需求使用的全过程，也就是从初始需求到实现的前后生存期。跟踪能力是优秀需求规格说明书的一个特征，为了实现跟踪能力，必须统一地标识出每一个需求，以便能明确地进行查阅。
客户需求向前追溯到软件需求。这样就能区分出开发过程中或者开发结束后，由于客户需求变更受到影响的软件需求，这也就可以确保软件需求规格说明包括所有客户需求。
从软件需求回溯响应的客户需求。这也就是确认每个软件需求的源头。如果使用实例的形式来描述客户需求，那么客户需求与软件需求之间的跟踪情况就是使用实例和功能性需求。从软件需求向前追溯到下一级工作产品。由于开发过程中系统需求转变为软件需求、设计、编码等，所以通过定义单个需求和特定的产品元素之间的（联系）链，可以从需求向前追溯到下一级工作产品。这种联系链告诉我们每个需求对应的产品部件，从而确保产品部件满足每个需求。从产品部件回溯到软件需求。说明了每个部件存在的原因。如果不能把设计元素、代码段或测试回溯到一个需求，可能存在“画蛇添足”的程序。然而，如果这些孤立的元素表明一个正当的功能，则说明需求规格说明书漏掉一项需求
需求抽取和分析的过程
- 发现需求
- 需求分类和组织
- 需求优先级划分和协商
- 需求规格说明
用例
是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。它确定一个和系统参与者进行交互，并可由系统执行的动作序列。用例模型描述的是外部执行者（Actor）所理解的系统功能。用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。 两个用例之间的关系主要有两种情况：一种是用于重用的包含关系，用构造型 include表示；另一种是用于分离出不同行为的扩展，用构造型extend表示。
①包含关系：当可以从两个或两个以上的原始用例中提取公共行为，或者发现能 够使用一个构件来实现某一个用例的部分功能是很重要的事时，应该使用包含关系来表示它们。
②扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种事情，可以断定将这个用例分为一个主用例和一个或多个辅用例描述可能更加清晰。
软件质量
软件质量是指反映软件系统或软件产品满足规定或隐含需求的能力的特征和特性全体。软件质量管理是指对软件开发过程进行的独立的检查活动，由质童保证、质量规划和质量控制三个主要活动构成。软件质量保证是指为保证软件系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是生产髙质量的软件。软件评审是软件质量保证的主要活动之一。
用户界面设计
用户界面设计的基本原则是从实践中总结出来的一些设计规则。Theo Maiidel在他的界面设计著作中提出3条“黄金规则”：
- 让用户拥有控制权：用户希望控制计算机，而不是被计算机控制，因此在设计人机界面时应遵循以下原则：交互模式的定义不能强迫用户进入不必要的或不希望的动作的方式；提供灵活的交互；允许用户交互可以被中断和撤销；当技能级別增长时可以使交互流水化并允许定制交互；使用户隔离内部技术细节。
- 减少用户的记忆负担：要求用户记住的东西越多，与系统交互时出错的可能也越大，因此好的用户界面设计不应加重用户的记忆负担。减少用户记忆负担的设计原则为：减少对短期记忆的要求;建立有意义的默认值；定义直觉性的捷径；界面的视觉布局应该基于真实世界的隐喻；以不断进展的方式祸示信息。
- 保持界面一致：用户应该以一致的方式展示和获取信息，这意味着：所有可视信息的组织遵循统一的设计标准，所有屏幕显示都遵守该标准。输入机制被约束到有限的集合内，在整个软件系统中被一致地使用，同时从任务到任务的导航机制也被一致地定义和实现。保持界面一致性的设计原则包括以下内容：允许用户将当前任务放在有意义的语境中；在应用系列内保持一致性；不要改变用户己经熟悉的用户交互模型。
安全
重放攻击
重放攻击，Replay Attacks，又称重播攻击、回放攻击或新鲜性攻击(Freshness Attacks)，是指攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程，破坏认证的正确性。Kerberos系统采用的是时间戳方案来防止重放攻击，这种方案中，发送的数据包是带时间戳的，服务器可以根据时间戳来判断是否为重放包，以此防止重放攻击。