软考-嵌入式系统设计师-笔记：嵌入式系统的项目开发与维护

文章目录

系统开发过程及其项目管理过程模型过程评估软件能力成熟度模型（CMM）能力成熟度模型集成（CMMI）工具与环境ISO/ICE 25010系统和软件质量模型系统分析知识系统设计知识系统设计概述结构化设计面向对象设计其它杂项系统实施知识基线系统测试测试目的测试原则测试过程测试方法测试级别系统调试系统运行和维护知识

系统开发过程及其项目管理

过程模型

瀑布模型：结构化开发，需求不明确时有很大缺陷；

增量模型：每次开发一部分功能（每个版本可独立操作）；

原型模型（演化模型）：针对需求不明确的情况，不适合超大项目；

螺旋模型（演化模型结合瀑布模型）： 增加风险分析，适合大型项目开发；

喷泉模型：面向对象模型，迭代思想和无间隙开发；

形式化方法模型：建立在严格数学基础上；

统一过程（UP） 模型

针对大型项目；

特点：用例和风险驱动；以架构为中心；迭代并且增量；

阶段：起始（确认需求和风险评估）；精化（完成架构设计）；构建（开发剩余构建，组装构件）；移交（进行测试，交付系统）；生产阶段；

RUP：是UP的商业扩展，针对前面四个阶段；

敏捷方法

极限编程（XP）：对费用控制严格的公司中使用；水晶法（Crystal）：以人为中心，用最少纪律约束而仍能成功的方法，效率与运作平衡；并列争球法（Scrum）：把每段时间一次的迭代称为一个“冲刺”，按需求的优先级来实现产品；自适应软件开发（ASD）：三个非线性的、重叠的开发阶段——猜测、合作与学习；功用驱动开发方法（FDD）：开发人员分为首席程序员和类程序员；

过程评估

软件能力成熟度模型（CMM）

能力成熟度模型集成（CMMI）

阶段式模型（关注组织的成熟度）：

连续式模型（关注每个过程域的能力）：

工具与环境

开发工具

需求分析工具、设计工具、概要设计工具、实现和排错工具、测试工具；

维护工具

版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具；

项目管理和支持工具

项目管理工具、配置管理工具、评价工具；

ISO/ICE 25010系统和软件质量模型

ISO/ICE 9126已被ISO/ICE 25010取代

系统分析知识

系统需求的定义

功能需求：所开发的系统必须具备什么样的功能；非功能需求：产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性、扩展性、保密性和安全性等；设计约束：也称为限制条件、补充规约，这通常是对解决方案的一些约束说明；

需求分析的基本任务

需求分析阶段主要解决“做什么”的问题，而“怎么做”则是由设计阶段来完成。

确定系统的综合要求：主要包括系统界面要求、系统的功能要求、系统的性能要求、系统的安全和保密性要求、系统的可靠性要求、异常处理要求和将来可能提出的要求；分析系统的数据要求：包括基本数据元素、数据元素之间的逻辑关系、数据量和峰值等；常用的数据描述方法是实体-关系模型（E-R模型）；导出系统的逻辑模型：在结构化分析方法中可用数据流图来描述；在面向对象分析方法中可用类模型来描述；修正项目开发计划：在明确了用户的真正需求后，可以更准确地估算系统的成本和进度，从而修正项目开发计划；如有必要，可开发一个原型系统。对一些需求不够明确的软件，可以先开发一个原型系统，以验证用户的需求；

需求建模

面向数据流的结构化分析方法（SA）；

面向数据结构的分析方法：数据流图、实体联系图、状态迁移图；

面向对象的分析方法（OOA）；

系统设计知识

系统设计概述

系统设计主要目的：为系统指定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理地使用各种资源，最终勾画出新系统的详细设计方法；

系统设计方法：结构化设计方法、面向对象设计方法；

系统设计主要内容：概要设计、详细设计；

概要设计基本任务：系统总体结构设计，将系统的功能需求分配给软件的模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图；

详细设计基本任务：模块内详细算法设计、模块内数据结构设计、数据库的物理设计、其他设计（代码、输入/输出格式、用户界面）、编写详细设计说明书、评审；

结构化设计

结构化设计内容：

体系结构设计：定义软件的主要结构元素及其关系；数据设计：基于实体联系图确定软件涉及的文件系统的结构及数据库的表结构；接口设计：描述用户界面，软件和其它硬件设备、其它软件系统及使用人员的外部接口，以及各种构件之间的内部接口；过程设计：确定软件各个组成部分内的算法及内部数据结构，并选定某种过程的表达形式来描述各种算法；

**结构化设计原理：**抽象化、自顶向下、模块化、模块独立；

**结构化设计原则：**保持模块的大小适中、尽可能减少调用的深度、多扇入少扇出、单入口单出口、模块的作用域应在该模块内、功能应该是可预测的；

**内聚种类：**内聚高到低

功能内聚：这是最强的内聚，指模块内所有元素共同作用完成一个功能，缺一不可；顺序内聚：指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素的输出就是下一功能元素的输入；通信内聚：指模块内所有处理元素都在同一个数据结构上操作，或者指各处理使用相同的输入数据或者产生相同的输出数据；过程内聚：指一个模块完成多个任务，这些任务必须按指定的过程执行；时间内聚：把需要同时执行的动作组合在一起形成的模块称为时间内聚模块；逻辑内聚：指模块内执行若干个逻辑上相似的功能，通过参数确定该模块完成哪一个功能；偶然内聚（巧合内聚）：指一个模块内的各处理元素之间没有任何联系；

**耦合种类：**耦合低到高

无直接耦合：指两个模块之间没有直接的关系，它们分别从属于不同模块的控制与调用，它们之间不传递任何信息，因此模块间耦合性最弱，模块独立性最高；数据耦合：指两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言中的值传递；标记耦合：指两个模块之间传递的是数据结构；控制耦合：指一个模块调用另一个模块时，传递的是控制变量，被调用模块通过该控制变量的值有选择地执行模块内某一功能。因此，被调用模块内应具有多个功能，哪个功能起作用受调用模块控制；外部耦合：模块间通过软件之外的环境联结（如I/O将模块耦合到特定的设备、格式、通信协议上）时，称为外部耦合；公共耦合：指通过一个公共数据环境相互作用的那些模块间的耦合；内容耦合：当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部，这种模块之间的耦合为内容耦合；

面向对象设计

**面向对象设计原则：**单一职责、开放—封闭、李氏替换、依赖倒置、接口隔离、组合重用、迪米特原则（最少知识法则）；

其它杂项

UML构造块

事务结构事务行为事务分组事务注释事务关系依赖：可能有方向的虚线关联：一条直线聚合：直线，一端是空心菱形组合：直线，一端是实心菱形泛化：直线，一端是空心箭头实现：虚线，一端是空心箭头图

常见UML图：

类图（class diagram）：展现了一组对象、接口、协作和它们之间的关系；对象图（object diagram）：展现了一组对象以及它们之间的关系，描述了在类图中所建立的事物实例的静态快照；用例图（use case diagram）：展现了一组用例、参与者（actor）以及它们之间的关系，描述了谁将使用系统以及用户期望以什么方式与系统交互；序列图（sequence diagram）：是场景（scenario）的图形化表示，描述了在一个用例或操作的执行过程中以时间顺序组织的对象之间的交互活动；通信图（communication diagram）：强调收发消息的对象之间的结构组织；交互概览图（interaction overview diagram）：组合了序列图和活动图的特征，显示了每个用例的活动中对象如何交互；定时图（timing diagram）：是另一种交互图，关注一个对象或一组对象在改变状态时的时间约束条件，描述对象状态随着时间改变的情况，很像示波器，适合分析周期和非周期性任务；状态图（state diagram）：展现了一个状态机，它由状态、转换、事件和活动组成，用于建模时间如何改变对象的状态以及引起对象从一个状态向另一个状态转换的事件；活动图（activity diagram）：是一种特殊的状态图，展现了在系统内从一个活动到另一个活动的流程；组合结构图（composite structure diagram）：用于描述一个分类器（类、组件或用例）的内部结构，分类器与系统中其他组成部分之间的交互端口，展示一组相互协作的实例如何完成特定的任务，描述设计、架构模式或策略；组件图（component diagram）：展现了一组构件之间的组织和依赖；部署图（deployment diagram）：展现了运行时处理结点以及其中构件（制品）的配置；包图（package）：用于把模型本身组织成层次结构的通用机制，描述类或其他UML构件如何组织成包，以及这些包之间的依赖关系；

设计模式：

创建性设计模式——创建对象

工厂方法模式、抽象工厂模式、建造者模式、原型模式、单例模式；

结构性设计模式——处理类或对象的组合

适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式、代理模式；

行为性设计模式——描述类与对象怎样交互、怎样分配职责

职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式；

系统实施知识

基线

功能基线：在系统分析与软件定义阶段结束时，经过正式批注签字的系统规格说明书、项目任务书、合同或协议书中所规定的对待开发软件系统的规格说明；分配基线：在需求分析阶段结束时，经过正式评审和批准的需求规格说明。分配基线是最初批准的分配配置标识；产品基线：在综合测试阶段结束时，经过正式评审和批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最终批准产品的配置标识；

系统测试

测试目的

测试的目的就是希望能以最少的人力和时间发现潜在的各种错误和缺陷。

测试原则

应尽早并不断地进行测试；测试工作应该避免由原开发软件的人或小组承担；在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期输出结果；在设计测试用例时，不仅要设计有效、合理的输入条件，也要包含不合理、失效的输入条件；在测试程序时，不仅要检验程序是否做了该做的事，还要检验程序是否做了不该做的事；严格按照测试计划来进行；妥善保存测试计划、测试用例;测试用例可以为重新测试或追加测试提供方便;

测试过程

拟定测试计划；编制测试大纲；根据测试大纲设计和生成测试用例；实施测试；生成测试报告；

测试方法

静态测试桌前检查代码审查代码走查动态测试黑盒测试（功能性测试，不需要知道软件代码结构，根据功能设计测试） 功能分解等价类划分边界值分析判定表因果图随机测试猜错法正交试验法 白盒测试（结构性测试，需要软件知道代码结构，根据代码逻辑设计测试） 语句覆盖：使程序中每一条语句至少执行一次；判定（分支）覆盖：使程序中每个分支语句至少执行一次；条件覆盖：使每个判断中的每个条件至少满足一次；MC/DC（判定/条件）覆盖：使每个判断中的每个条件在可能的情况下至少影响判定结果一次；条件组合覆盖：使每个判断中条件的各种组合至少出现一次（这种覆盖包含了分支覆盖和条件覆盖）；路径覆盖：使程序沿所有可能的路径执行； 灰盒测试（黑盒+白盒）

测试级别

单元测试、部件测试、配置项测试、系统测试；

系统调试

系统运行和维护知识

软件维护根据原因分类：

改正性维护：识别和纠正错误、改正性能缺陷；适应性维护：使用过程中外部环境、数据环境变化，为了适应变化；完善性维护：使用过程中扩充功能、增强性能、改进效率和可维护性等；预防性维护：预先提高可维护性、可靠性等；

软件维护根据内容分类：

程序维护：为了改正错误或改进效率而改写一部分或全部程序，通常充分利用源程序；数据维护：对文件或数据中的记录进行增加、修改和删除等操作，通常采用专用的程序模块；代码维护：为了适应用户环境的变化，对代码进行变更，包括修订、新设计、添加和删除等内容；硬件设备维护：为了保证系统正常运行，应保持计算机及外部设备的良好运行状态。如建立相应的规章制度、定期检查设备、保养和杀病毒；

遗留系统评价与演化：