传统软件工程

第一章 软件与软件工程

1. 软件的概念，软件的特点，软件发展的四个阶段。

软件的概念(6): 软件是计算机系统的重要组成部分; 软件是逻辑产品, 需要计算机硬件和系统软件的支撑; 软件是计算机控制系统的指挥中枢; 软件是信息转换器, 它能对信息进行 加工 处理 变换; 软件是工具, 在人们的 生活 工作 休闲, 会的 经济 军事 政治 文化 科技 教育 中发挥具大作用; 软件是能够完成预定功能和性能, 并对相应数据进行加工的程序和描述程序及其操作的文档.

  软件 = 程序+数据+文档

  程序 = 算法+数据结构

软件的特点(3): 软件是被开发设计的, 而不是传统意义上被制造的; 软件不会”磨损”; 软件产业逐步走向基于构件的组装, 但还是定制的.

软件发展的四个阶段:

  1950-1965 没有系统的软件开发方法和管理机制; 自定义软件, 批处理, 有限分布.

  1965-1975 产生人机交互的新概念; 新技术软件产品, 多用户, 实时, 数据库.

  1973-1988 微处理器的出现并广泛应用; 分布式系统, 嵌入智能, 低成本硬件, 消费者的影响.

  1986-2000 广域和局域 络迅速普及; 强大的桌面系统, 面向对象技术, 专家系统, 人工智能, 神经 络, 并行计算, 络计算机.

2. 软件危机产生的原因, 解决软件危机的方法

软件危机原因(5): 软件的规模加大, 复杂性高, 性能增强; 软件是逻辑产品, 尚未完全认识其本质和特点; 缺乏 有效的系统的 开发维护 大型软件项目的技术手段和管理方法; 用户对软件需求的描述和软件开发人员对需求的理解往往存在差异, 用户经常要求修改需求, 开发人员很难适应; 软件开发的技术人员和管理人员缺乏软件工程化的素质和要求, 对工程化的开销认识不足.

解决方法: 软件工程

3. 软件工程的概念, 软件工程的三要素

软件工程的概念:

  A. 为了经济的获得可靠的, 在实际机器上高效运行的软件, 而建立和使用的好的工程原则.

  B. 软件工程是运用 工程 科学 数学 的原则与方法 研制 维护 计算机软件有关技术和管理的方法.

  C. 将 系统的 规范的 可度量的 方法应用于软件的 开发 运行 维护 的过程.

软件工程的三要素:

  过程: 过程贯穿软件开发的各个环节. 管理者在软件工程过程中对软件开发的 质量 进度 成本 进行评估 管理 控制; 技术人员采用相应的方法和工具生成软件工程产品(模型文档数据 告表格…).

  方法: 软件工程方法是完成软件工程项目的技术手段. 它支持 项目计划和估算 系统和软件需求分析 设计 编程 测试 维护. 软件工程方法依赖一组原则, 它贯穿软件工程的各个环节. 软件工程方法分两类: 传统方法和面向对象方法.

  工具: 为了支援开发和维护活动而使用的软件: 项目估算工具 需求管理工具 设计建模工具 编程和调试工具 测试工具 维护工具

4. 软件生命周期各阶段及其基本任务

软件生命周期阶段及任务: (三个时期, 七个阶段)

  软件定义 问题定义: 确定系统的总体目标; 可行性分析: 研究 经济 技术 操作… 的可行性; 需求分析: 收集需求, 需求建模;

  软件开发 系统设计: 软件结构设计 数据设计 接口设计 过程设计; 编码: 产生源程序清单; 测试: 产生软件测试计划和软件测试 告;

  软件运行 维护: 修改 完善 扩展软件

5. 软件开发过程模型几种模型的形式与特点及适用范围

  瀑布模型: 软件开发过程与软件生命周期是一致的: 相邻二阶段之间存在因果关系; 需对阶段性产品 进行评审. Opt: 软件生命周期模型, 使软件开发过程可以在 分析 设计 编码 测试 维护 的框架下 进行; 软件开发过程具有 系统性 可控性, 克服了软件开发的随意性. Neg: 项目开始阶段用户很难精确的提出产品需求, 由于技术进步, 用户对系统深入的理解, 修改需求十分普遍. 项目开发晚期才能得到程序的运行版本, 这时修改软件需求和开发中的错误代价很大; 采用线性模型组织项目开发经常发生开发小组人员“堵塞状态”, 特别是项目的开始和结束.

  快速原型模型: 用户给出软件产品的一般需求; 开发小组和用户共同定义软件总体目标, 标识已知需求; 对 界面 功能 人机交互方式… 进行设计并建造原型; 强调“快速”, 釆用基于构件的软件开发方法, 尽量缩短软件开发周期, 不宜釆用过多的新技术; 用户对原型进行评估; 修改需求->更新设计->完善原型->确定需求. Opt: 原型模型支持软件需求开发, 帮助用户和开发人员理解需求, 是软件需求工程的关键. 它产生的正式需求文挡, 是软件开发的基础. 如果开发的原型是可运行的, 它的若干高质量的程序片段和开发工具可用于工作程序的开发. 原型的开发和评审是系统分析员和用户共同参予的迭代过程, 每个迭代循环都是线性过程.

  螺旋模型: 螺旋模型 = 线性模型 + 迭代原型 + 系统化; 适用于计算机软件整个生命周期. Opt: 符合人们认识现实世界和软件开发的客覌规律; 支持软件整个生命周期; 保持瀑布模型的 系统性 阶段性; 利用原型评估降低开发风险; 开发者和用户共同参与软件开发, 尽早发现软件中的错误, 不断推出和完善软件版本, 有助于需求变化, 获取用户需求, 加强对需求的理解.

6. 结构化设计方法

结构化设计方法是基于模块化、自顶向下细化、结构化程序设计等程序设计技术基础发展起来的。

将软件设计成由相对独立且具有单一功能的模块组成的结构, 分为概要设计和详细设计两个阶段.

第二章 软件项目管理

1. 软件项目管理的基本概念

  图: 初步需求 分 析 快速设计 建造原型 用户评估原型（新需求） 对原型加工 开发产品 开 始 结 束

目的: 为了使软件项目能够在预定 成本 进度 质量 的前提下顺利完成, 必须对软件工程项目进行 计划 组织 监控 管理

任务: 制定软件项目的实施计划和方案; 对人员进行组织和分工; 按照计划进度, 以及 成本管理 风险管理 质量管理 的要求进行软件开发, 完成软件项目的各项要求和任务.

2. 软件项目估算(代码行功能点估算) 略

面向规模: 

  生产率（LOC/PM）= 代码行数／工作量(人月 PM)

代码出错率 = 代码错误数／代码行数 每行代码平均成本 = 总开销／代码行数 文档与代码比 = 软件项目文档页数／代码行数 面向功能： 生产率 = 功能点数／工作量 代码出错率 = 代码错误数／功能点数 每个功能点平均成本 = 总开销／功能点数 文档与功能点比 = 软件项目文档页数／功能点数

3. McCabe 度量法

巡回秩数 V(G) 作为程序结构复杂性的度量(复杂度分析) V(G) = e – n + 2 (边-点+2)

4. 成本估算方法及其特点

期望值 E = (乐观值 + 4 × 一般值 ＋ 悲观值) / 6;

  根据“从前的”, “局部的”数据得出的, 估算模型不可能完全适用于当前所有的软件项目和全部开发环境. (计算结果仅供参考)

5. 关键路径法

完成关键路径上所有任务时间的总和, 就是项目开发所需要的最短时间.

  甘特图

6. CMM 与 CMMI 的基本概念

软件能力成熟度模型 CMM

  L1: 初始级; L2: 可重复级 [软件项目计划, 软件项目跟踪和监督]; L3: ; L4: ; L5: ;

能力成熟度模型集成 CMMI

  L1: 初始级;

  L2: 可重复级 [需求管理 项目计划 配置管理 项目监督和控制 供应商合同管理 度量 和分析 过程和产品质量保证];

  L3: 己定义级 [需求开发 技术解决方案 产品集成 验证 确认 组织级过程焦点 组织级过程定义 组织级培训 集成化项目管理 风险管理 集成化的团队 决策分析和解决方组织级集成环境];

  L4: 己管理级 [组织级过程性能 项目定量管理];

  L5 优化级 [组织级改革和实施 因果分析 解决方案]

第三章 需求分析基础

1. 软件需求内容

软件需求： 用户对目标软件系统在功能、行为、性能、设计约束等方面的期望.

2. 需求分析常用技术

技术和方法: 初步需求获取技术、需求建模技术、快速原型技术、问题抽象、问题分解与多视点分析

3. 结构化分析(SA)方法

结构化分析方法是软件需求分析中公认的、有成效的、技术成熟、使用广泛的一种方法, 较适合于开发数据处理类型软件的需求分析.

该方法利用图形等半形式化工具表达需求，简明、易读，也易于使用，为后一阶段的设计、测试、评价提供了有利的条件。

但SA方法也存在有不足之处:

  传统的SA方法主要用于数据处理方面的问题, 主要工具DFD体现了系统“做什么”的功能, 但它仅是一个静态模型, 没有反映处理的顺序, 即控制流程. 因此, 不适合描述实时控制系统.

  SA方法使用DFD在分析与描述“数据要求”方面是有限的, DFD应与数据库技术中的实体联系图(ER) 结合起来.

  DFD不是和描述人机界面系统的需求。SA方法则对这一部分用自然语言作补充，对这类系统可采取其它的分析方法.

  为了更精确地描述软件需求，提高软件系统的可靠性、安全性，也便于实现自动化，SA方法可与形式化方法结合起来。

面向数据流进行数据分析的方法。采用自顶向下逐层分解的分析策略。顶层抽象地描述整个系统，底层具体地画出系统工程的每个细节。中间层则是从抽象到具体的过渡。使用数据流图，数据字典，作为描述工具，使用结构化语言，判定表，判定树描述加工逻辑。

[核心]

  数据字典: 描述软件工程项目的所有数据对象;

[中间层]

  实体-关系图: 描述数据对象之间的关系;

  数据流图: 功能建模的基础: 系统或子系统对数据实施的变换 变换的功能: 提供信息分析的信息

  状态-变迁图：行为建模的基础；系统的行为模式（称“状态”）以及状态变迁的方式

[最外层]

  数据对象: 表示实体-关系图中每个数据对象的属性

  加工规格说明 PSPEC: 描述数据流图的每个功能

  控制规格说明 CSPEC: 描述软件控制的附加信息

4. 数据流图 DFD

  分层数据流图; 数据字典 见后面大题分析

第四章 软件设计基础

1. 设计阶段主要任务

软件设计过程是对程序结构、数据结构和过程细节逐步求精、复审并编制文档的过程。包 括总体结构设计、系统的数据设计和系统的过程设计。 数据设计：把信息?述转换为实现软件所要求的数据结构。 总体结构设计：旨在确定程序各主要部件之间的关系。 过程设计：完成每一部件的过程化?述。 结构化程序设计定义：采用自顶向下逐步求精的设计方法和单入口单出口的控制构件.

2. 软件设计准则

抽象与逐步求精: 层次结构的上一层是下一层的抽象，下一层是上一层的求精

模块化: 把软件划分为可独立命名和编址的部件，每个部件称为一个模块,当把所有模块组装到一起 时则获得满足问题需要的一个解.

信息隐藏: 模块应该设计得使其所含信息(过程和数据)对于那些不需要这些信息的模块不可访问; 每个模块只完成一个相对独立的特定功能; 模块之间仅仅交换那些为完成系统功能必须交换的信息, 即模块应该独立.

3. 高内聚低耦合

内聚度: 模块内部各成分彼此结合的紧密程度;

耦合度: 软件结构中模块间关联程度的一种度量.

高内聚低耦合有利于模块独立性, 得到更好的重用性, 维护性, 扩展性, 可以更高效的完成系统的维护开发, 持续支持业务的发展, 而不会成为业务发展的障碍.

4. 模块的作用域和控制域

作用域: 模块中判定的作用范围, 是指所有受这个判定影响的模块. 如果模块中含有受判定影响的操作, 则该模块在这个判定的作用范围之中. 如果模块执行与否取决于判定的结果, 则该模块及其直接或间接调用的模块均在这个判定的作用范围之中.

控制域: 是指模块本身及其直接或间接调用的模块.

如果模块的作用域不在控制域之内, 则会增加模块间数据的传递量, 使模块间出现控制耦合。

5. 熟悉中心变换分析和事务分析

略

6. 详细设计工具

程序流程图、盒图(N-S 图)与 PAD 图之间的转化 见后面大题分析

第八章 软件测试

1. 软件测试的目的和原则

软件测试的目标: 软件测试是为了发现程序中的错误. 软件测试的过程亦是程序运行的过程. 程序运行需要数据,为测试设计的数据称测试用例. 设计测试用例的原则自然是尽可能暴露错误. 软件测试是一个找错过程. 测试只能找出程序中的错误, 而不能证明程序无错.

2. 软件可测试性(7)

  可操作性: “操作的容易程度”

  可观察性: “你所看见的就是你所测试的”

  可操控性: “对软件控制的越好, 测试越能被自动执行和优化”

  可分解性: “通过控制测试范围, 能够很快地鼓励问题, 完成更灵巧的再测试”

  简单性: “需要测试都可内容越少, 测试的速度越快”

  稳定性: “更变越少, 对测试的破坏越小”

  易理解性: “对根变越少, 对测试的破坏越小”

3. 软件测试流程

软件工程的开发过程和测试过程应该是对应的。采用 V 型图表示开发—测试的对应关系， 也可以采用螺旋型图表示。 每旋转一圈,测试的范围加大一次: 螺旋中心对应单元测试,它测试源程序的每一模块; 下一步是综合测试,它测试软件总体结构; 再下一步是确认(验收)测试,测试软件是否满足需求; 最后一步是系统测试,检查软件与系统中其他元素是否协调.

4. 软件测试计划

/em>

5. 软件测试技术

白盒测试: 已知产品内部工作过程, 通过测试检验产品内部动作是否按照产品规格说明规定正常进行;

黑盒测试: 已知产品应该具有的功能, 通过测试检验每个功能是否都能正常使用;

利用软件测试技术进行软件测试: 软件测试技术见后面大题分析.

6. 软件测试策略的基本概念

单元测试: 单元测试的对象是软件设计的最小单位 – 模块. 单元测试任务包括：模块接口测试;模块局部数据结构测试;模块边界条件测试;模块中所有 独立执行通路测试;模块的各条错误处理通路测试.

集成测试: 综合测试是组装软件的系统测试技术,按设计要求把通过单元测试的各个模块组装在一起 之后,进行综合测试以便发现与接口有关的各种错误.

确认测试: 确认测试应检查软件能否按合同要求进行工作,即是否满足软件需求说明书中的确认标准。 实现软件确认要通过一系列黑盒测试。确认测试的另一个重要环节是配置复审。复审的目 的在于保证软件配置齐全、分类有序,并且包括软件维护所必需的细节.

验收测试: 软件是否真正满足最终用户的要求应由用户进行一系列“验收测试”。α测试是指软件开 发公司组织内部人员模拟各类用户行为对即将面市的软件产品(称为α版本)进行测试，试图发 现错误并修正。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司 组织各方面的典型用户在日常工作中实际使用β版本，并要求用户 告异常情况、提出批评意 见。然后软件开发公司再对β版本进行改错和完善。

系统测试: 计算机软件是基于计算机系统的一个重要组成部分,软件开发完毕后应与系统中其他成份 集成在一起,此时需要进行一系列系统集成和确认测试. (恢复测试 安全测试 强度测试 性能测试)

第十章 软件维护

1. 软件维护的定义

在软件 运行/ 维护 阶段对软件产品进行的修改就是所谓的维护.

2. 软件维护类型(4)

  改正性维护: 为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用， 应当进行的诊断和改正错误的过程就叫做改正性维护;

  适应性维护: 为使软件适应这种变化，而去修改软件的过程就叫做适应性维护;

  完善性维护: 为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性;

  预防性维护: 采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进 行设计、编制和测试(为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础)

3. 软件可维护性(7)

  可理解性: 可理解性表明人们通过阅读源代码和相关文档, 了解程序功能及其如何运行的容易程度;

  可使用性: 可使用性定义为程序方便、实用、及易于使用的程度;

  可测试性: 可测试性表明论证程序正确性的容易程度;

  可移植性: 可移植性表明程序转移到一个新的计算环境的可能性的大小;

  可修改性: 可修改性表明程序容易修改的程度;

  效率: 效率表明一个程序能执行预定功能而又不浪费机器资源的程度;

  可靠性: 表明一个程序按照用户的要求和设计目标，在给定的一段时间内正确执行的概率.

4. 软件维护的技术种类

 

面向对象软件工程

第六章 面向对象的需求分析

1. 面向对象的概念

客观世界中的应用问题都是由实体及其相互关系构成的。 可以将客观世界中与应用问题有关的实体及其属性抽象为问题空间中的对象。 为应用问题寻求软件解，是借助于计算机语言对其?供的实体施加某些动作，以动作的结 果给出问题的解。 面向对象(Object-Oriented,简称 OO)的需求分析方法通过?供对象、对象间消息传递等语言 机制让分析人员在解空间中直接模拟问题空间中的对象及其行为 面向对象 = 对象 + 类 + 继承 + 聚集 + 消息

2. 面向对象特性与原则

面向对象特性: 封装, 继承, 多态;

面向对象原则:
  单一职责原则 (SRP)
  开放封闭原则 (OCP)
  里氏替换原则 (LSP)
  依赖倒置原则 (DIP)
  接口隔离原则 (ISP)
  迪米特原则 (LKP)

2. 统一建模语言 UML 及十种视图

见后面大题分析

https://my.oschina.net/ares1899/blog/812517

3. 基于 UML 的软件开发过程

初启: 在初启阶段, 软件项目的发起人确定项目的主要目标和范围, 并进行初步的可行性分析和经济效益分析;

细化:

  a) 初步的需求分析 (用例图, 领域模型类图, 活动图)

  b) 初步的高层设计 (包图)

  c) 部分的详细设计 (交互图, 精化类图)

  d) 部分的原型构造 (详尽的交互图, 明确的属性和操作定义)

构造:

  1) 用例及用例图: 它们是开发人员在构造阶段进行分析和设计的基础.

  2) 类图: 在领域概念模型的基础上引进为软件实现所必需的类、属性和方法.

  3) 交互图: 表示针对用例设计的软件实现方法.

  4) 状态图: 表示类的对象的 状态-事件-响应 行为.

  5) 活动图: 表示复杂的算法过程, 尤其是过程中的并发和同步.

  6) 包图: 表示目标软件系统的顶层结构.

  7) 构件图:

  8) 部署图:

移交：在移交阶段, 开发人员对构造阶段获得的软件系统在用户实际工作环境(或接近实际的模拟环境)中试运行, 根据用户的修改意见进行少量调整.

4. 基于 UML 的需求分析

1) 从业务需求描述出发标识用例，生成表示用例内容的活动图(可选)，生成表示用例之间 用例与执行者之间关系的用例图;

2) 根据 领域知识 业务需求描述 既往经验 建立以包图表示的目标软件系统的顶层架构, 形成以类图表示的领域概念模型.

5. 基于 UML 的需求建模

个人认为和需求分析差不多

6. UML 用例图的构建

?见后面大题分析

7. UML 类图构建，类之间的关系描述

见后面大题分析

第一部分 UML 介绍（概念）

什么是 UMLnified Modeling Language 面向对象软件工程使用的统一建模语言 一种图形化了的语言，主要用图形方式表示 一种开放的标准

UML 的特点 统一标准 面向对象 可视化 表达能力强

UML 的十种视图（分类、名称、?述）

UML 静态建模、动态建模、架构建模

什么是用例图用例图的模型元素

从系统的外部用户的观点看系统应具有的功能 用例图主要用于对系统，子系统或类的行为进行建模 它只说明系统实现什么功能，而不必说明如何实现

模型元素: 参与者描述系统外部元素所起的作用 关联?供用例与参与者间的通信路径

用例描述系统所提供的功能

什么是类图的模型元素与表示法

描述类之间的关系有几种strong>

符 与画法.

 依赖的强化是关联，关联的强化是聚合，聚合的强化是构成。

什么是包图是对象图strong>

模型元素与画法.

什么是时序图strong>

模型元素与画法.

什么是协作图strong>

模型元素与画法.

时序图与活动图的区别strong>

定 时序图是对象之间的消息传递顺序 活动图是工作流中动作的顺序

什么是状态图strong>

模型元素与画法.

什么是活动图strong>

模型元素与画法.

什么是部署图strong>

模型元素与画法.

什么是构件图strong>

模型元素与画法.

第二部分 RUP 中的需求分析(概念)

在 RUP 中描述需求的相关制品有哪些p>

参与者、用例、用例描述、用例补充规约的功能是什么bsp;

什么是用例模型p>

第七章 面向对象的设计方法

建模题_见后面大题分析

1. 面向对象的软件设计过程

2. 基于 UML 的设计

3. UML 顺序图的构建

4. UML 协作图的构建

5. UML 状态图的构建

6. UML 活动图的构建

第三部分 用例分析(概念)

补充用例描述的功能是什么/strong>

用例描述的功能定

从用例行为中查找分析类。包括边界类、控制类、实体类、辅助类的划分

边界类: 为用例中涉及到的每对参与者/用例设计一个边界类来封装面向这个参与者的接口 用户接口类 系统接口类 设备接口类

控制类: 封装一个或多个用例所特有的控制行为；控制类有效地分离了边界对象和实体对 象，使系统更能承受系统边界的变更

实体类: 存储（通常具有持久性）一些现象的信息，并包含与这些信息相关的业务规则 如学生，计划表，课程清单

辅助类:

第四部分 基于 RUP 的分析与设计（概念）

在 RUP 中分析与设计有什么不同活动和设计活动由哪些/strong>

分析：关注于问题的理解；理想化的设计；行为；系统结构；功能需求；较小的模型 设计：关注于解决方法；操作和属性；性能；接近源代码；对象生存期；非功能性需求； 较大的模型

系统架构师和设计人员的任务分别是什么

软件系统架构师负责在整个项目中对技术活动和制品进行领导和协调, 设计人员必须知道用例建模技术, 系统需求和软件设计技术

什么是系统架构

软件系统架构（architecture）包含关于软件系统组织的许多重要决定： 选择组成系统的结构元素以及它们的接口 充当这些元素间协作的渠道 把这些结构和行为元素组织成更大的子系统 指导开发组织的架构风格

模式、设计模式、框架有什么不同

模式：描述了对环境中的通用问题的通用解决方法 分析/设计模式：?供了小范围技术问题的解决方法；?供了解决方法的一部分，或问题的 一块 框架：定义了解决问题的普通方法；?供了解决方法的骨架， 它的细节可能是分析/设计 模式

什么是设计模式的设计模式你知道吗strong>

设计模式是对通用设计问题的解决方法 描述了通用的设计问题 描述了问题的解决方法 讨论应用模式产生的结果 设计模式提供了复用成功设计的能力 常用设计模式： 命令（行为模式）；抽象工厂（创建模式）；代理（结构模式）；观察者（行为模式）

什么是架构模式的架构模式有几种

架构模式表示软件系统的基本结构组织方案。它提供了一组预定义的子系统、指定它们的 职责，并且包括用于组织其间关系的规则和指导 典型的架构模式： 层次；模型-视图-控制器 (M-V-C)；管道和过滤器；黑板

什么是用例实现/strong>

add

RUP(Rational Unified Process) 概念

是软件工程的过程. 它提供了在开发组织中分派任务和责任的纪律化方法. 它的目标是在可预见的日程和预算前提下, 确保满足最终用户需求的高质量产品. RUP以适合于大范围项目和机构的方式捕捉了许多现代软件开发过程的最佳实践

RUP几个阶段及作用: 

  先启: 定义整个项目的范围;

  精化: 制定项目计划 描述功能 建立体系架构框架;

  构建: 构造软件产品;

  产品化: 将软件产品移交到最终用户手中.

数据流图作用

1. 便于用户表达功能需求和数据需求及其联系;

2. 便于两类人员共同理解现行系统和规划系统的框架;

3. 清晰表达数据流的情况;

4. 有利于系统建模

需求分析作用

通过对问题及环境的 理解 分析, 将用户需求 精确化 完全化, 最终形成需求规格说明, 描述系统 信息 功能 行为.

面向对象部分的综合题

1. 根据问题的陈述，能画出用例图描述、类图描述及其间的相关关系

2. 针对用例构建该用例的时序图与协作图

3. 基于某个对象，构造其状态转换图

4. 能用活动图描述系统或子系统的工作过程.

 

题型

一. 名词解释（每道题 4 分*5 道=20 分)

二. 简答题 (每道题 6 分*5 道=30 分)

三. 设计题（每道题 15 分*2 道=30 分）

1. 给程序伪代码，画程序流程图，盒图，设计测试用例，McCabe 复杂度分析 20 分

  例:盒图, (另例)

2. 构建类及类之间的关联 10 分 例

四. 建模（每道题 10 分*2 道=20 分） 给一大段陈述

1. 传统软件工程角度分析：数据流图，顶级流图等 数据流图例

2. 面向对象角度分析：抽取类，类的行为，属性，构建类图（精化类图），类的关联图等

文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览35229 人正在系统学习中 相关资源：水亦恒直销管理软件V1.0-专业指导文档类资源-CSDN文库