软件工程复习

第一章.软件工程概述

软件危机

• 什么是软件危机？为什么会出现软件危机？

  • 定义：

    软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是不能正常运行的软件才具有的。

  • 为什么会出现？

    • 软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件。

    • 软件不同于一般程序，它的一个显著特点是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。

软件工程

• 软件工程的定义
  将系统化的，规范的，可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。
• 软件过程
  — 是把输入转换为输出的一组彼此相关的资源或活动。
  — 从软件开发的角度来看，就是使用适当的资源（人员、硬件软件工具、时间等），为软件开发进行的一组开发活动，在过程结束的时候将用户的要求转换为软件产品
  — 软件工程就是一组引发软件产品生产的活动。
• 怎样利用软件工程消除（至少是缓解）软件危机？

第二章.软件过程

软件生命周期

1. 软件定义：问题定义 可行性研究 需求分析
2. 软件开发：概要设计 详细设计 编码和单元测试 综合测试
3. 运行维护： 本质上是一次简化的软件定义和软件开发

软件开发模型

1. 瀑布模型

• 模型

  image

• 概念：

  各个活动自上而下，相互衔接的固定次序，如同瀑布逐级下落，每项活动均处于一个质量环（输入-处理-输出-评审）中

• 优点：

  • 采用规范的方法

  • 严格要求每个阶段交出的产物必须经过验证

• 缺点：
  ​ ​ - 对用户需求变更的响应很困难

  • 客户通常很难清楚地描述所有的需求

  • 客户只有在项目接近尾声的时候，才能看见可运行的产品界面

• 适用于什么项目
• 适用于需求明确，并且在开发过程中不会产生大的需求变更的项目

2. 快速原型模型

• 模型

image

• 概念

演化模型先开发一个“原型”软件，完成部分主要功能，展示给用户并征求意见，然后逐步完善，最终获得满意的软件产品。

• 优点：

  • 降低了适应用户需求变更的成本

  • 开发过程中更容易得到用户对于对于开发工作的反馈意见

• 缺点：

  • 如果没有抛弃原型，而是在其基础上进行开发，可能会导致系统设计差，难以维护。

• 适用于什么样的项目
  • 如果用户有一个合理的需求，但是对细节没有思路，可以采用这种模型，先开发一个原型。

3. 增量模型

• 模型

image.png

• 概念

  分批次地向用户提交产品，每次提交一个满足用户需求子集的可运行的产品。 直到最后一次得到一个满足全部需求的完整产品。

  • 本质上就是版本迭代

• 优点

  • 降低了适应用户需求变更的成本。
  • 开发过程中更容易得到用户对于已做的开发工作的反馈意见。
  • 用户有充裕的时间学习和适应新产品

• 缺点：

  • 缺乏过程的可见性

  • 结构往往不好

• 适用于什么样的项目
• 适用于小或者中等规模的交互式系统、短生命周期的系统。

4. 螺旋模型

• 模型：

  image

• 概念

  可以把它看作为在每个阶段之前增加了风险分析的快速原型模型

• 优点：

  • 设计上的灵活性，可以在项目的各个阶段进行变更

  • 以小的分段来构建大型系统，使得成本计算简单容易。

  • 风险驱动，减小问题的发生。

• 缺点

  • 建设周期长，然而技术发展快，所以无法满足当前用户的需求。

• 适用于什么样的项目

  • 对于新近开发，需求不明确，大型的昂贵系统，更适用于此模型

敏捷开发及Scrum流程

• 敏捷开发

  • 需求是涌现式的、范围是不确定的

    • 使用逐步完善而并非大而全的计划
    • 分版本迭代，尽早交付，以获得反馈
    • 每个迭代结束的时候进行检视和调整。调整包括需求、范围、人员以及计划。

• Scrum 框架

  image

• 三个角色：Product Owner 、Scrum Master、 Scrum Team

• 六个时间箱：发布会议计划、Sprint、Sprint计划会议、每日站会、Sprint评审会议、Sprint回顾会议。

• 四个工件：产品 Backlog（待办事项） 、发布燃尽图、Sprint Backlog 、Sprint 燃尽图

• 能力成熟度模型(CMM)

image.png

第三章.结构化分析

结构化分析就是一种建立模型的活动，通常建立数据模型、功能模型和行为模型3种模型。

概述

• 需求工程7项明确任务

  1. 起始
  2. 获取
  3. 细化
  4. 协商
  5. 规格说明
  6. 确认
  7. 需求管理

• 软件需求（需求分析）

  • 用户需求

    • 描述了要求系统必须完成的任务，用户对系统的目标要求。

    • 通常只涉及系统的外部可见行为，不涉及系统的内部特性。

    • 用户需求一般采用自然语言和直观图形相结合的方式描述，例如采用用例（Use Case）文档或场景（Scenario）等方式说明。

  • 系统需求

    • 系统需求详细地给出系统将要提供的服务以及系统所受到的约束。
    • 系统需求来自于系统分析和结构设计。系统需求文档也称为功能描述，应该是精确的，它可能成为买方和开发方之间合同的主要内容。

  • 功能需求

    • 功能需求定义了开发者应提供的软件功能或服务，但不涉及这些功能或服务的实现。

  • 非功能需求

    • 非功能需求则是对功能需求的补充，包括了对系统的各种限制和用户对系统的质量要求。

数据流图

• 数据流图符号

  image

• 第三章 例一

  image

状态转换图

• 主要符号

  image

结构化分析的3个阶段

• 结构化分析的三个阶段：

  • 问题定义

  • 可行性研究

  • 需求分析

第四章.结构化设计

一些重要的名词解释

• 模块化

  就是把程序划分成可独立命名且独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求。

  例如：子程序、类、方法

目的： 使一个复杂的大型系统或程序更容易被人所理解，降低系统及程序开发的复杂度。

模块化定义地五条准则：

• 可分解性
• 可组装性
• 可理解性
• 连续性
• 保护性

作用：

• 有助于提高软件的可靠性

• 提高软件的可修改性；

• 有助于软件开发工程的组织管理

• 抽象

  • 概念

    把这些相似的方面集中和概括起来，暂时忽略它们之间的差异，这就是抽象。

• 逐步求精

  • 概念

    为了能集中精力解决主要问题而尽量推迟对问题细节的考虑

    一项把一个时期内必须解决的种种问题按优先级排序的技术。逐步求精确保每个问题都将被解决，而且每个问题都在适当的时候解决。

• 信息隐藏

  • 概念

    使得一个模块内包含的信息（过程和数据）对于不需要这些信息的模块来说，是不能访问的。

• 耦合和内聚

  • 耦合

    一个软件结构内不同模块之间互连程度的度量

  • 内聚

    标志一个模块内各个元素彼此结合的紧密程度

​ 低耦合高内聚

试卷上的题目

• 重点（12点）

  1. 用例图，用例规格说明

image

image

image

2. 类图、时序图

   • 类图

     image

     1. 类的关联

        类之间具有的关系，每个类都必须包含他有联系的类的一些信息，关联可以有方向。

     2. 类的聚合

        image

     3. 类的组合

     上面的图，小汽车由轮胎和发动机还有其他的组合而成。

     4. 类的泛化

        image

     5. 类的接口和实现

        一个类和它的接口之间的关系叫做实现，一个类可以实现多个接口，一个接口也可以被多个类实现。上面的自行车和汽车共同继承了接口---跑，

     6. 类的依赖
        上述的图形，学生依赖自行车。这只是暂时的

   • 时序图

     见文章最后的例题。

3. 软件工程

   软件工程是将系统化的、规范的可度量的方法应用于软件开发、运行和维护的过程。即将工程化应用于软件开发。

4. 瀑布模型、增量模型、快速原型

   • 瀑布模型：各项活动按自上而下，相互衔接的固定次序，如同瀑布逐级下落，每项活动均处于一个质量环（输入-处理-输出-评审）中。

   • 增量模型：增量模型把软件产品分解成一系列的增量构件，在增量开发迭代中逐步加入。

   • 快速原型模型：演化模型先开发一个“原型”软件，完成部分主要功能，展示给用户并征求意见，然后逐步完善，最终获得满意的软件产品。

5. 用户需求、系统需求、功能需求、非功能需求

   • 用户需求：
     • 描述了要求系统必须完成的任务，用户对系统的目标要求。
     • 通常只涉及外部可见行为，不涉及系统内部特性
     • 用户需求一般采用自然语言和直观的图形相结合的方式描述
   • 系统需求
     • 系统将要提供的服务，以及系统所受到的约束
     • 系统需求来源于系统分析和结构设计
   • 功能需求
     • 定义了开发者应当提供的软件功能或服务，但不涉及它们的实现。
   • 非功能需求
     • 对功能需求的补充，包括了对系统的各种限制和用户对系统的质量要求

6. UML

   • 定义：统一建模语言，可以对任何具有静态结构和动态行为的系统进行可视化的建模

7. 项目管理五大过程和九大知识领域

   • 五大过程： 起始、规划、执行、结案、监督和控制
   • 九大知识领域：范围、时间、成本、质量、人力资源、风险、采购、沟通、项目整体

8. MVC模式

   M(Model),模型层，负责将数据库模型化

   V(View),视图层，负责模板的渲染

   C(Controller),控制器层，负责接受用户的数据，处理逻辑业务

9. 模块化，信息隐藏，类的聚合和泛化

   • 模块化：

     就是把程序划分成可独立命名且独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能，满足用户的需求。

   • 信息隐藏：

     使得一个模块内包含的信息（过程和数据）对于不需要这些信息的模块来说，是不能访问的。

10. 面向对象编程设计的基本原则

    1. 模块化
    2. 抽象
    3. 信息隐藏
    4. 弱耦合
    5. 强内聚
    6. 可重用

11. 软件开发过程主要包括那些文档？内容以及它们之间的关系

    • 可行性研究报告
    • 项目开发计划
    • 软件需求说明书
    • 数据要求说明书
    • 概要设计说明书
    • 详细设计说明书
    • 用户手册
    • 操作手册
    • 测试计划
    • 测试分析报告
    • 开发进度月报
    • 项目开发总结报告
    • 维护修改建议

12. 传统软件按开发模型和敏捷开发模型的区别？Scrum框架的基本流程

• 区别：

  1. 敏捷开发需求是涌现式的，范围是不确定的，计划驱动开发的目标具有可预见性的、稳定性和高可靠性

  2. 敏捷开发适合于规模比较小的项目，计划驱动开发比较适合于大型复杂的项目

  3. 敏捷开发是“计划行为驱动“，而并非”计划驱动“，计划驱动用计划来沟通协调

  4. 敏捷开发是非正式的，由用户指定的优先级素材作为需求，计划驱动开发偏爱于明确的、形式化的需求。

• Scrum的基本流程

  （1）Product Owner根据需求的优先级确定一个排序好的产品 Backlog;
  （2）Scrum Team通过Sprint 计划会议，根据产品Backlog按优先级选出一组需求作为迭代的目标，即Sprint Backlog。这个阶段一般的时间是4周。
  （3）Scrum Team完成Sprint Backlog过程中，Scrum Master需要召开每日站会,每个人都要汇报所完成的进度和遇到的问题，总结经验，通过Sprint燃尽图记录工作的整个过程。
  （4）当本次Sprint把Sprint Backlog都实现完之后进行Sprint 评审会议，这个会议总管理层和产品负责人以及开发团队都要参加，讨论本次Sprint交付的产品，以及根据产品负责人的需求变动及时调整。
  （5）最后进行Sprint 回顾会议，回顾本次迭代整个过程中遇到的问题，以及解决方案，为下一轮Sprint做准备。

设计题

1. 随心记是一款App应用,用户可以随意记录心事的平台,还可以进行交友,将自己的心事分享给好友.

• 请使用用例描述系统边界(5分,从用例图规范及是否完全描述系统进行增减分考虑),请对记录心情及好友互动功能进行详细的用例描述(每个用例描述各5分,根据描述的严谨、完整性、规范性考虑进行增减分考虑)

  • 使用用例描述系统边界

  • 记录心情的用例描述

  • 好友互动的用例描述

• 请对该应用业务进行建模并画出系统的主要类图关系(5分),并分别画出登录及记录心情功能的时序图(提示:该应用设计采用分层体系结构)(每个时序图分别5分)

  • 主要类图关系

  • • 登录
    image
    • 心情记录时序图
    image