关键词：

前言

第3章 软件工程

3.3 需求工程

3.3.1 概述

需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。

它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。

需求工程是指应用已证实有效的原理 、方法 , 通过合适的工具和记号 ,系统地描述待开发系统及其行为特征和相关约束 。需求工程覆盖了体系结构设计之前的各项开发活动 , 主要包括分析客户要求、对未来系统的各项功性及非功能性需求进行规格说明 , 并针对不同的对象可分为系统需求工程 (如果是针对由软硬件共同组成的整个系统 )和软件需求工程(如 果仅是 专门针对纯软件部分 )。 在系统开发中 , 需求工程往往与体系结构设计交替进行 ,直到分解的子问题可以单纯地由软件或硬件系统解决 。软件需求工程则是对应用于纯软件系统开发生命期中系统设计之前的第 一 阶段 。

因此 , 需求工程的目标相当简单明了 : 确定客户需求 , 定义设想中系统的所有外部特征。

综合了几种观点，可以把需求工程的活动划分为以下5个独立的阶段：

• 需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；

• 需求分析与建模：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；

• 形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；

• 需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性，包含有效性检查，一致性检查，可行性检查和确认可验证性；

• 需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。

3.3.2 需求获取

需求获取首先需要的是技术的支持，其次，在需求获取工作中主要涉及了 3 个至关重要的因素：应搜集什么信息（输出/目标）；从什么来源中搜集信息（输入）；用什么机制或技术搜集信息（手段、方法）。再次，需求获取的开始，代表着软件项目正式开始实施，正所谓万事开头难。

综合上述 3 个点使得需求获取成为软件开发中最困难、最关键、最易出错也是最需要交流的方面。

在工作开展中，主要是就业务流程、组织架构、软硬件环境和现有系统等相关内容进行沟通，挖掘系统最终用户的真正需求，把握需求的方向。在需求获取调研会中首先对需求获取方法作了验证。现行的需求获

取方法一般有基于调查的需求获取方法、基于用例的需求获取方法、原型法等几种方法。各种需求获取方法各有利弊。

（1）功能需求：业务、用户、系统三大功能需求，如业务场景和系统界面。

（2）性能需求（非功能需求/质量需要）：吞吐率、实时性、各种利用率、延时、容量、用户数等。

（3）设计约束：时间约束、预算约束、技术约束、人员约束、组织约束等。

（4）基本需求：基本的明面上的、显式的需求。

（5）期望需求：隐含的、非明面上的需求，如默认需要、质量需求、性能需求等。

（6）兴奋需求：超出客户需要之外的增量的需求，镀金式需求。

3.3.3 结构化、形式化的需求分析SA（做什么what）

需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的结构化需求定义，从而确定系统必须做什么的过程。

需求分析是软件计划阶段的重要活动，也是软件生存周期中的一个重要环节，该阶段是分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。

需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。

此外，软件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展性等)，软件设计的约束条件，运行时与其他软件的关系等也是软件需求分析的目标。

备注：

无论是数据流图，还是状态转换图，或是E-R图，都源于现实世界，都是对现实世界的抽象和展现。

只是他们从不同的角度对现实世界进行抽象与展现：

E-R图：又称为对象图，它抽象与展现的是现实业务中的各种对象以及对象之间的关系。

数据流图/功能图：它抽象和展现的现实业务中的数据在不同业务实体（对象）中的流动，它是以数据为主线。

状态图：它抽象和展现的是现实业务中的实体对象收到外部事件影响后的行为和动作、状态的变化。它是以对象为载体，以事件和状态为主线。

数据字典：三种图进行详细的说明。

3.3.3.1 实体对象关系图：E-R图 （实现世界抽象的对象关系图）

E-R图也称实体-联系图(Entity Relationship Diagram)，提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。

它是描述现实世界关系概念模型的有效方法。是表示概念关系模型的一种方式。

E-RU是现实世界的抽象和展现，因此，是需求层面上的，而不是设计层面上的。

用“矩形框”表示实体型，矩形框内写明实体名称；即对象或类名称。

用“椭圆图框”或圆角矩形表示实体的属性，并用“实心线段”将其与相应关系的“实体型”连接起来；即对象的属性。

用”菱形框“表示实体型之间的联系成因，在菱形框内写明联系名，并用”实心线段“分别与有关实体型连接起来，同时在”实心线段“旁标上联系的类型（1:1,1:n或m:n）。即两个不同对象之间的关系。

如下图所示：

E-R关系图是对现实世界的总结和抽象。

最终会转换成软件设计中的“类图”和类的关系图。

转换成“对象”与对象关系图。

3.3.3.2 数据流图DFD（功能图）

数据流图（Data Flow Diagram）：简称DFD，它从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。

参考：https://blog.csdn.net/weixin_46694417/article/details/120588235

数据流图是结构化分析方法中使用的工具,它以图形的方式描绘数据在系统中流动和处理的过程，由于它只反映系统必须完成的逻辑功能，所以它是一种功能模型。在结构化开发方法中，数据流图是需求分析阶段产生的结果。

数据流图或数据流程图（Data Flow Diagram），缩写为DFD。数据流图DFD是描述系统中数据流程的一种图形工具，它标志了一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换逻辑输出所需的加工处理。

值得注意的是，数据流图不是传统的流程图或框图，数据流也不是控制流。数据流图是从数据的角度来描述一个系统，而框图是从对数据进行加工的工作人员的角度来描述系统。

DFD显示系统将输入和输出什么样的信息，数据如何通过系统前进以及数据将被存储在何处。它不显示关于进程计时的信息，也不显示关于进程将按顺序还是并行运行的信息，而不像传统的关注控制流的结构化流程图，或者UML活动工作流程图，它将控制流和数据流作为一个统一的模型。

数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。

3.3.3.3 状态转换图

状态转换图，即STD图(State Transform Diagram)，表示行为模型。

STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出作为特定事件的结果将执行哪些动作（例如处理数据等）。STD描述系统对外部事件如何响应，如何动作。

STD图发生在软件工程的需求分析阶段。状态模型是一种描述系统对内部或者外部事件响应的行为模型。它描述系统状态和事件，以及事件引发系统在状态间的转换。这种模型适用于描述实时系统。

3.3.3.4 数据字典

数据字典是指对数据的数据项、数据结构、数据流、数据存储、处理逻辑等进行定义和描述，其目的是对数据流图中的各个元素做出详细的说明，使用数据字典为简单的建模项目。

简而言之，数据字典是描述数据的信息集合，是对系统中使用的所有数据元素的定义的集合。

数据字典（Data dictionary）是一种用户可以访问的记录数据库和应用程序元数据的目录。

主动数据字典是指在对数据库或应用程序结构进行修改时，其内容可以由DBMS自动更新的数据字典。

被动数据字典是指修改时必须手工进行更新内容的数据字典。

3.3.3.5 面向对象分析

Object-Oriented Analysis（面向对象分析方法）是确定需求或者业务的角度，按照面向对象的思想来分析业务。例如：OOA只是对需求中描述的问题，进行模块化的处理，描述问题的本质，区别每个问题的不同点相同点，确定问题中的对象。OOA与结构化分析有较大的区别。OOA所强调的是在系统调查资料的基础上，针对OO方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。

结构分析

OOA（面向对象的分析）模型由5个层次（主题层、对象类层、结构层、属性层和服务层）和5个活动（标识对象类、标识结构、定义主题、定义属性和定义服务）组成。

在这种方法中定义了两种对象类之间的结构，一种称为分类结构，一种称为组装结构。

分类结构就是所谓的一般与特殊的关系。

组装结构则反映了对象之间的整体与部分的关系。

定义属性

OOA在定义属性的同时，要识别实例连接。实例连接是一个实例与另一个实例的映射关系。

OOA在定义服务的同时要识别消息连接。当一个对象需要向另一对象发送消息时，它们之间就存在消息连接。

OOA 中的5个层次和5个活动继续贯穿在OOD（面向对象的设计）过程中。OOD模型由4个部分组成。它们分别是设计问题域部分、设计人机交互部分、设计任务管理部分和设计数据管理部分。

用例图：从用户的角度描述系统的功能！！！！

包含：整体到个体

泛化：抽象到具体

3.3.3.4 需求开发

3.3.3.4.1 需求定义=》 SRS

软件项目需求说明书是指在研究用户要求的基础上，完成可行性分析和投资效益分析以后，由软件系统工程师或分析员编写的需求说明书。

它详细定义了信息流和界面，功能需求，设计要求和限制，测试准则和质量保证要求。

当然，软件项目需求规格说明书是站在用户的角度看到的系统功能。而不是从软件系统内部的角度看到的外部接口的需求。前者是由外向内看，后者是由内向外看。

这是写需求规格说明书，必须有的立足点。

需求规格说明书关注的是从外看到系统的功能需求，而不是内部的具体设计，更不是具体的实现。

软件需求规格说明书是需求分析阶段最后的成果，它是作为需求分析的一部分而制定的可交付文档。软件需求说明书，又称为软件规格说明书，是分析员在需求分析阶段需要完成的文档，是软件需求分析的最终结果。

https://blog.csdn.net/HiWangWenBing/article/details/126924855

3.3.3.4.2 需求验证

对需求规约的验证活动，用以检查需求规约中的错误。

常用的方法包括需求审查、原型与模拟、自动化分析等。

需求验证是需求开发的最后一个环节，它是一个质量关。

其目标是发现尽可能多的错误，减少因为需求的错误而带来的工作量浪费。

而需求验证的主要手段就是Review(复查，也常译为评审）。

但是许多需求团队都觉得需求验证比较容易变得“务虚”，收效很少，本文的目标就是帮助大家缓解这个问题。

在KarlE.Wiegers所著的《软件同级评审》一书中，根据评审的正式化程度将其分成了6个等级。

不同正式化程度的评审

3种相对正式的评审特点如下：

3种相对不正式的评审的特点：

审查过程

审查是企业级的评审，其过程由规划、准备、会议、返工、跟踪一系列活动组成，输入是初始工作产品，输出为完成基线的产品。

①规划

规划内容、规划人员，即谁参加？评审什么？

需求相关的评审会议，参加的人员主要包括以下几种角色：

•需求规格说明书的作者、同级伙伴

•提供规格说明信息的人：分析员、客户

•要根据规格书开展工作的人：开发人员、测试人员……

•负责相关接口工作的人

而在需求评审会议中，主要的角色有主持人、作者、读者（也就是评审者）、记录员，一般来说评审者不宜超过6个（也就是除了主持人、作者、记录员之外），否则容易使评审会过于发散，难以控制。另一方面则是需要规划内容，通常不建议一次对整个需求规格说明书进行评审，应该做适当的分解。

②总体会议

在召开正式的评审会议之前，召集参加评审会议的所有成员开一个简短的会议，讨论、明确要评审的内容、评审的要点、评审时所需的资料、缺陷检查表。

③准备

审会的效果好不好，关键在于评审者是否提前做了阅读、做了准备，要想让大家在现场提出有价值的、完整的建议是不可能的。因此，应该为每位评审者提供完整的参考资料，提供一些时间，预先阅读、查找错误。同时，要求所有的评审者将阅读时发现的文字、版面类的错误直接发给作者，不要让这些东西浪费评审会的时间。

④审查会议

准备阶段的目标是发现问题，召开审查会议的目标是暴露问题、讨论问题，大家对预先找到的问题，逐一讨论，给出结论。在审查之前，待审查的文档应该符合以下几点要求：

•文档遵循标准模板：统一的模板能够易于阅读、评审；

•文档已经进行了拼写检查：也就是尽可能减少文字错误带来的问题；

•作者已经检查了版面上的错误：这也是为了尽可能减少对评审者产生干扰；

•所有未解决的问题应该做好标记：避免大家花精力找出那些本来就没搞清楚的地方。

⑤返工

这一步骤是评审活动中经常被忽略。评审活动直接目标是找出需求规格说明书中的问题，但更有价值、更有意义的是解决问题，并且避免它。

解决问题：对提出的问题是否解决进行跟踪、督促；

避免问题出现：对所有的问题都进行分类、因果分析，找到出现这些问题的深层次原因。

二、需求验证的主要误区与解决方案

需求验证的5大要点

①思想

由于Review被翻译成“评审”，导致很多人将其与中国人常说的评审相混淆。中国人常说的评审是评价，而Review应该是复查，是发现问题。这一点，须成为所有组织、参加需求评审会的人员都应该建立的统一认识。

②方法

东西方文化上的差异：西方人：AllOpen,ButDeny，也就是先是全开放、都是朋友，而遇到不诚信之类的现象后，就将其Deny掉（拒绝）；东方人：AllDeny,ButOpen，也就是先是防备心很重，轻易不是朋友，真到通过一系列的事之后才会Open(开放）友谊。

中国人通常是不太愿意接受“当面指出问题”的这种沟通方式的，更不要说在“众目睽睽”之下被人指出问题。

所以，需要注重建立评审文化，采用正式化程度较低的评审手段（即时评审、同级桌查）。

③语言

东方人通常不是一个好的、积极的“被评审者”，还经常不是一个好的、有效的“评审者”。不良的语言习惯是破坏评审会气氛的一大杀手，因为你一不小心变成了高高在上的“评价者”。同样一个意思，换一种表达方式，效果会更好。

④人员

要点在于合适，而不是越多越好。包括三个方面的要点：

同级：在CMM/CMMI中提到的是PeerReview，Peer就是同级，不要一开评审会就请高阶领导。很多人连“当着别人面被指出问题”都受不了，更何况是当着领导的面。

该来的人要请：评审内容所涉及的第一责任人，一定请他们参加。

不该来的人不要请：也就是评审不是越多人参加越好，通常应该保持比较小的范围，要直接相关的人员参与；一方面可以保证参与者对评审内容熟悉，另一方面也可以保证参与者关心评审过程。

⑤内容

评审时要确保评审内容、缺陷检查表的规模适合，内容应该按每小时30〜40页的速度来准备，缺陷检查表尽量在9条之内。

需求验证常见的5大问题

①评审会上，上面开大会、下面开小会

在评审会的进程中，经常出现部分参与者交头接耳，讨论一些与评审会没有直接关系或联系不紧密的话题，对会议气氛和进程产生了很明显的影响。

出现这种现象，有一半的责任是主持人的！原因就是在评审会中安排了一些与会议主题、内容关注度不高的人。

解决建议是按照评审者关注的内容拆分分场，与其大家聚在一起讨论，还不如分主题、分场次、分人员进行周期更短的评审会。

②评审会成了审判会

在评审会中，大家对作者提出了很多的批评，做了不少负面的评价，作者的处境就像是“受审”一样，带来了很大的挫折感，从而对评审产生了抵制。

出现原因是在评审会中，所有的评审者以“评价者”的角色以较生硬的语气给出意见，并且作者的资历相对较浅，不敢直接提出反对意见。

解决建议是让参与评审会的评审者转换为“建议者”、“协作者”的角度，改进语气、语句。这既可以通过培训评审者的方式来实现，也可以通过主持人以身作则的方法示范。

③评审会成了吵架会

在评审会中，大家对作者提出了很多的批评，做了不少负面的评价；作者忍不住就开始进行不够理智的反抗，双方可能产生争执，甚至可以升级为人之间的冲突。

出现原因是在评审会中，所有的评审者以“评价者”的角色以较生硬的语气给出意见，并且作者的资历与评审者相当、甚至有可能更高，因此将会直接提出反对意见。

解决建议是，要通过让参与评审会的评审者转换为“建议者”、“协作者”的角度，改进语气、语句。

④评审会成了语法纠错会

在评审会中，听到的很多错误都是“这个字写错了”、“这个词用得不好”、“这个段落没有缩进”……之类的语法、版面错误。最终导致所暴露的问题都是琐碎、无价值的细节。

出现原因有两个方面：一是好人主义，评审者心想“如果我提出一些真的问题，他面子上会过不去”，所以就不在会议上说大问题，只谈小问题；二是准备不足，评审者之前没有阅读，当轮到他提出建议时，只好现场找，结果就只能找到这种问题。

解决建议是，要通过让参与评审会的评审者转换为“建议者”、“协作者”的角度，改进语气、语句。

⑤评审会成了翻书会

在评审会议的过程中，提出的问题根本不按页码序，一会翻到第20页，一会又翻回第10页，整场听到很多的翻书声，甚至有不少评审者跟不上评审节奏。

出现原因是主持人准备不足，临时让大家的思绪随意地展开，导致组织不利，影响评审结果。

解决建议是，可以采用的方法应该与前面的方法结合起来，当所有评审者返回了问题之后，先按页码序进行排列，然后在会议上按顺序逐一解决；每翻过一页之前，还可以停一下，让大家现场再补充一些意见和建议。

3.3.3.5 需求管理

3.3.3.5.1 需求基线

什么是需求基线？

需求基线就是把固定的需求都划一根“线”,说明这些需求已经确定下来，添加新的需求或修改原有的需求都必须通过需求变更流程来操作

建立需求基线的目的：防止需求的变化给程序架构造成重大影响。

需求基线定义：已经通过正式评审和批准的规格说明或产品，可作为进一步开发的基础，而且只有通过正式的变更控制过程才能修改它。

需求基线要以一种持续、衡定和易于项目涉众访问的方式存在。

需求基线通常以文档的方式纳入配置管理中。

需求基线的内容：

• 标识符：为后续的项目工作提供一个共同的交流参照；

• 当前版本号：保证项目的各项工作都建立在最新的一致需求基础之上；

• 源头：在需求进一步深入理解或者改变需求时，可以回溯到需求的源头；

• 理由：提供需求产生的背景知识；

• 优先级：后续的项目工作可以参照优先级进行安排和调度；

• 状态：交流和具体需求相关的项目工作情况；

• 成本、工作量、风险和可变性：为需求的设计和实现提供参考信息，驱动设计和实现工作。

• 其他

• 需求创建的日期

• 和需求相关的项目工作人员

• 需求涉及的子系统

• 需求涉及的产品版本号

• 需求的验收和验证标准

3.3.3.5.2 需求跟踪

需求跟踪是指跟踪一个需求使用期限的全过程，需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括其他类型的需求，体系结构，其他设计部件，源代码模块，测试，帮助文件等。

需求跟踪为我们提供了由需求到产品实现整个过程范围的明确查阅的能力。

需求跟踪就是落实前面辛辛苦苦获得的客户的需求的过程！！！

需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。

需求跟踪矩阵（Requirement traceability matrix [1] ），也译作需求追溯矩阵，是一种主要管理需求变更和验证需求是否得到了实现的有效工具，借助RTM，可以跟踪每个需求的状态。

3.3.3.5.3 需求变更

• 参考：

https://blog.csdn.net/HiWangWenBing/article/details/129292331

[架构之路-116]-《软考-系统架构设计师》-软架构设计-9-构件与中间件技术

前言：第9节构件与中间件技术9.1定义构件是系统中实际存在的可更换部分。它实现特定的功能，符合一套接口标准并能实现一组接口。构件代表系统中的一部分物理实施，包括软件代码（源代码、二进制代码或可... 查看详情

系统架构设计师软考简介(软考好处|职称晋升|工作居住证|积分落户|系统架构设计师与系统分析师备考及难度|软考报名考试注意事项)

文章目录一、软考简介二、软考的好处三、系统架构设计师与系统分析师备考及难度四、软考报名考试注意事项一、软考简介软考中的系统架构设计师,有一定的难度,范围较广,难度较高,即使你真的是架构师,但是如果对考试的具... 查看详情

软考高级系统架构设计师系列论文之：软考高级架构设计师百篇范文

软考高级系统架构设计师系列论文之：软考高级架构设计师百篇范文软考高级架构设计师论文写作技巧：软考高级系统架构设计师系列论文：详细介绍一篇论文的万能模版，快速了解如何写好一篇架构设计师论文... 查看详情

[架构之路-131]-《软考-系统架构设计师》-软件工程-1-软件工程方法大全（软件开发过程方法软件开发过程模型逆向工程净室软件工程）

前言：第3章软件工程3.1软件开发过程方法3.1.1什么是软件工程软件工程是一门研究用工业硬件生产的工程化方法构建和维护有效、实用和高质量的软件的学科。它涉及程序设计语言、数据库、软件开发工具、系统平台、标准... 查看详情

[架构之路-5]：架构师-中国计算机技术职业资格（软考）考试是如何定义系统架构师？

...149第6章系统计划174第7章系统分析与设计方法195第8章软件架构设计246第9章设计模式287第10章测试评审方法307第11章嵌入式系统设计319第1 查看详情

[架构之路-114]-《软考-系统架构设计师》-软件架构设计-7-软件架构评估

前言第7节软件架构评估7.1什么是架构评估/为什么要软件架构评估在软硬件系统总体架构设计完成之后，为保证架构设计的合理性、完整性和针对性，从根本上保证系统质量，降低成本及投资风险，需要对总体架... 查看详情

[架构之路-109]-《软考-系统架构设计师》-软件架构设计-2-软件架构概述：架构风格

引言建筑风格指建筑设计中在内容和外貌方面所反映的特征，主要在于建筑的平面布局、形态构成、艺术处理和手法运用等方面所显示的独创和完美的意境。建筑风格因受时代的政治、社会、经济、建筑材料和建筑技术等的... 查看详情

[架构之路-110]-《软考-系统架构设计师》-软件架构设计-3-架构描述语言adl与uml

前言：第3节架构描述语言ADL3.1ADL概述3.1.1什么是ADLADL，即架构描述语言(ArchitectureDescriptionLanguage)。两个重要的团体在使用架构描述语言术语。它们是：软件工程团体企业建模和工程团体。在软件工程团体，架构描... 查看详情

[架构之路-111]-《软考-系统架构设计师》-软件架构设计-4-特定领域软件架构

前言：第4节特定领域软件架构4.1概述（1）定义特定领域软件架构（DomainSpecificSoftwareArchitecture，DSSA）是一种有效实现特定领域软件重用的手段。简单地说，DSSA就是在一个特定应用领域为一组应用提供... 查看详情

[架构之路-115]-《软考-系统架构设计师》-软件架构设计-8-软件工程与基于架构的软件开发流程absd

前言第8节软件产品线8.1什么是软件产品线软件产品线（softwareproductline）是指具有一组可管理的公共特性的软件密集性系统的合集。核心思想：大平台小产品。大平台：公共特征产品线：小产品产品线(ProductLine... 查看详情

软考架构设计师参考资料

...件专业技术资格（水平）考试，报考的科目为《系统架构设计师》，这是一个高级资格考试。上一次参加软考时的高级资格考试还只有《系统分析师》，一转眼的时间，高级资格考试已经有5门了，不得不感叹飞速的变化。本人... 查看详情

[架构之路-107]-《软考-系统架构设计师》-0-系统分析师与系统架构设计师简介与官网介绍

官网链接：https://www.ruankao.org.cn/index/ind计算机技术与软件专业技术资格（水平）考试简介计算机技术与软件专业技术资格（水平）考试（以下简称计算机软件资格考试）是原中国计算机软件专业技术资... 查看详情

[架构之路-122]-《软考-系统架构设计师》-操作系统-1-操作系统原理-进程管理

前言：操作系统的本质就是创建一个并发的应用程序执行的环境，使得各种应用程序可以动态、共享相同的计算机物理硬件资源，计算机的三大物理资源包括：CPU内存外设应用程序（管理应用程序）：... 查看详情

[架构之路-135]-《软考-系统架构设计师》-软件工程-5-软件系统设计（面向对象设计基础）

前言：第4节系统设计4.3面向对象设计4.3.1概述面向对象程序设计（ObjectOrientedProgramming，OOP）是一种计算机编程架构。OOP的一条基本原则是计算机程序由单个能够起到子程序作用的单元或对象组合而成。OOP达到了软... 查看详情

[架构之路-133]-《软考-系统架构设计师》-软件工程-3-软件系统的建模与uml

前言：第三章软件工程3.3软件系统的建模软件分析建模体现了软件设计的思想，在系统需求和系统实现之间架起了一座桥梁。软件工程师按照设计人员建立的模型，开发出符合设计目标的软件系统，而且软件的维... 查看详情

[架构之路-125]-《软考-系统架构设计师》-操作系统-4-浅谈vxworks与linux操作系统的区别

相同点（1）都可以用于嵌入式操作系统（2）都提供多任务的执行环境（3）WindRiverSystem公司可以提供者两种操作系统的硬件定制化（BSP)2.不同点2.1内核结构不同vxworks是微内核，只提供基本的服务... 查看详情

[架构之路-124]-《软考-系统架构设计师》-操作系统-3-操作系统原理-io设备微内核嵌入式系统

第11章操作系统第5节设备管理/文件管理：IO5.1文件管理5.2IO设备管理（内存与IO设备之间）数据传输控制是指如何在内存和IO硬件设备之间传输数据，即：设备何时空闲？设备何时完成数据的传输？SPOOLIN... 查看详情

[架构之路-120]-《软考-系统架构设计师》-计算机体系结构-2-一文了解armsoc体系结构原理（cpu工作原理指令内存中断堆栈io初始化）

知识准备：(890条消息)[架构之路-17]：目标系统-硬件平台-ARMCPU架构与系列选型_arm硬件架构_文火冰糖的硅基工坊的博客-CSDN博客第9章计算机体系结构第1节ARMSOC芯片体系结构1.1ARM家族1.2SOC芯片总体架构ARMCore内核系统（... 查看详情