<软件工程基础与实用教程>期末复习

软件工程概述

  1. 软件 = 程序+数据+文档
  2. 软件危机
    1. 软件危机指的是在计算机软件的开发和维护过程中所遇到的一系列严重问题,导致开发延期成本激增或者软件运行质量事故等。
    2. 软件危机包含的问题 — 什么导致
      • 软件开发方面的问题
        软件规模日趋增大,内容日趋复杂,开发困难
        缺乏质量保证体系,没有成熟的开发流程,产品质量得不到保证
      • 软件维护方面的问题
        需求和环境不断变化,使得维护数量不断膨胀
      • 软件发展速度跟不上硬件的发展
    3. 软件危机的根本原因 — 没有把软件的加工当作工程来管理
    4. 工程化 — 生产活动要按照目标话,规范化,文档化,标准化进行
    5. 软件工程三要素:过程(第二章)、方法(第三章) 和 工具

软件工程子集 — 软件过程

  1. 软件过程是 软件开发的活动集合

    软件过程三类: 基本过程,支持过程,组织过程

    基本过程:主干活动集 支持过程:辅助活动集 组织过程:软硬件环境建设

  2. 软件过程的活动集合活动顺序贯穿了软件开发的方法论

  3. 生存周期的基本划分:分成三个大的阶段也称三个时期: 即计划时期、开发时期和运行时期。

    1. 软件生存周期:软件产品从定义到开发、使用和维护,直到最终被弃用,要经历一个漫长的时期,通常把软件经历的这个漫长的时期称为生存周期。
    2. image-20210531110250880
    • 软件过程 = 软件生存周期
    • 软件过程 ≠ 软件工程,软件过程是软件工程的子集。
  4. 软件过程与开发方法

    ​ **软件开发的本质**就是将“客观世界”,映射(虚拟)到“计算机世界”。映射的过程也称“软件开发过程”或简称“软件过程”。

软件开发模型

介绍了哪四种传统开发模型?各有何特点?

**答:**瀑布、原型、增量、螺旋四个传统模型:

(1) 瀑布模型:主要体现了分阶段、有控制的思想。活动间强调按顺序、文档化;存在的问题是:过于理想化,每一步的工作必须完整准确,否则无法进行下一步工作。

(2) 原型模型:需求分析入手快速、表达直观、容易交流。在需求分析阶段融进了循环往复的思想,重点解决瀑布模型需求分析入手难的问题。

(3) 增量模型:对于需求复杂的系统,采用分块开发,逐步集成的开发策略。增量体现了演进迭代思想,每一块就是一个增量。每个增量是一次迭代。增量模型的新版本叫做“极限编程”(XP)。

(4) 螺旋模型:融合了上述三种模型,融进了循环往复、强化了演进迭代的思想,客户始终参与每个阶段的开发,增加风险控制环节。但风险分析的正确性是左右软件演进的关键因素。

瀑布模型 — 线性顺序模型

  1. 没有回头路
  2. 瀑布模型的特点
    • 活动间具有顺序性和依赖性。前一个活动的输出是下一活动的输入,必须等前一阶段的工作完成之后,才能开始后一阶段的工作
    • 推迟实现的观点。充分做好前期的分析和设计工作,将逻辑设计与物理实现分离,不要急于编码,尽可能推迟程序的物理实现,减少返工量
    • 质量保证的观点
      每个阶段必须完成规定的、完整的、准确的合格文件
      前一阶段的输出文档就是后一阶段的输入文档
  3. 瀑布模型的局限性
    需求分析是成败关键;
    不适合需求模糊的系统;
    很难适应需求变化

快速原型模型 — 循环往复思想

  1. 引入循环往复思想
  2. 基本活动顺序依然按照瀑布模型,主要在 需求分析阶段融入了 循环往复的思想
image-20210531112431202
  1. 快速原型模型的特点

    • 借助原型开发工具可较容易地做出系统原型,及早向用户展示系统要实现的界面及功能,增强用户的合作信心;
    • 直观化的表达,容易交流,消除理解上的歧义;
    • 修改集中在前期的原型确认上,较大程度减少后期实施中的返工。后续活动遵循瀑布模型;
    • 入手快,加快开发进度
    • 克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险
  2. 快速原型模型的缺点
    所选用的 开发技术和工具不一定符合主流的发展
    快速建立起来的系统结构加上 连续的修改可能会 导致产品质量低下。
    使用这个模型的前提是要有一个展示性的产品原型, 因此在一定程度上可能会 限制开发人员的创新。

增量模型 — 迭代思想

  1. 引入了迭代思想

  2. 先完成一个系统子集的开发,再按同样的开发步骤增加子集,如此递增下去直至满足全部系统需求。每个增量可按快速原型法进行。

  3. 增量模型的特点

  • 对于需求不能完全被掌握和了解的系统,无须等待做出完整的需求就可入手,使用户尽快见到开发的成果,增强双方信心**;**

  • 分步骤分块开发,降低开发的复杂性和难度,减少技术风险,并可并行开发;

  • 边开发边投入,可及早发现问题,减少投资风险;

  • 各个子集是逐渐并入已有的系统中,加入子集不能破坏已构造好的部分,这需要软件具备开放式的体系结构;

  • 适用于需求不完整的软件开发,指的是需求逐渐摸清、逐步完善,并非随意改变,需求改变过大会导致整体性失控。

  1. 增量模型的优缺点
    优点
    有利于增加客户对系统的信心;
    降低系统失败风险;
    提高系统可靠性;
    提高了系统的稳定性和可维护性;

    缺点
    增量粒度难以选择;
    确定所有的基本业务服务比较困难。

螺旋模型 — 迭代思想,风险分析

  1. 引入了风险分析

  2. 每圈对应线性顺序模型中的一个开发活动,每圈演进一个活动层次

    每圈按顺时针运行分四个象限,这四个象限要完成这一圈的制定计划、风险分析、实施工程、客户评估四个步骤

  3. 螺旋模型的特点
    多种模型结合的一种演进模型,融合了瀑布模型、快速原型和增量模型的所有特点,融进了循环往复、迭代演进的思想;
    增加前三种模型所忽略的风险分析,一旦风险成立,原方案应终止、修订,力求风险可控,
    **客户始终参与每个阶段的开发,**每个阶段的成果需客户确认,避免错误的积累。
    缺点
    风险分析是一把双刃剑!

统一过程RUP

  1. 双重迭代

  2. 分为时间轴(横轴) 活动内容轴(纵轴)

    横轴的时间组织,划分四个阶段、四个里程碑

image-20210531115159847

检查点、基线、里程碑

​ 检查点:是指在整个项目生命周期中有几个时间点需要进行重大的检查动作,一般是均等的分布在项目整个生命周期的时间点上

​ 里程碑:是计划中确定的阶段性工作完成目标,要求提交阶段交付物,作为阶段评估的标准

​ 基线: 是在连续工作的分界点,得到上一个时期结束时刻点的“快照”,作为下一步开发的出发点和参考点

​ 检查点比较细、里程碑比较粗、基线最粗。

​ 检查点一般依据时间的先后顺序设定、里程碑一般依据关键成果的产出设定、基线依据一组关键成果的产出设定

敏捷开发

  1. 客户全面参与、以快为特点的迭代、循序渐进的开发方法
  2. 软件项目被切分成多个子项目,小项目相互联系,可独立运行

极限编程XP

  1. 主要特征是要 适应环境变化和需求变化,让客户全面参与软件的开发设计
  2. 测试驱动开发TDD 隐喻
image-20210531122740921 image-20210531122804250

敏捷开发要提供可用的实例给客户,可以不断地测试和需求变更

需求没有明确,反复迭代增加了工作量

软件生命周期 — 软件计划

结果: 可行性研究报告

问题定义

编写 项目报告 提交审查

可行性研究 — 可行性研究报告

  1. 目的:确定项目用最小的代价在尽可能短的时间里是否能够开发,是否值得开发

  2. 任务:

    1. 可行性分析:进一步分析和澄清问题的定义

      技术可行性,经济可行性,社会可行性

    2. 写可行性研究报告 — 可行性分析的结果写入

    3. 开发计划

制定项目计划

计划时期的结果 — 项目计划

软件生命周期 — 需求分析

输入: 可行性研究报告

输出: 需求规格说明书

  1. 问题定义:大体做什么; 可行性研究:做不做; 需求分析:具体做什么

  2. 需求分析是需求工程的部分内容 — 需求分析 == 软件工程中需求开发

    image-20210604095259510

需求获取

软件需求包括三个不同的层次业务需求;用户需求;功能需求–也包括非功能需求。

用户需求说明书

需求建模(分析建模)

  1. 根据用户需求建立的目标软件的逻辑模型

    从物理模型过渡到逻辑模型

  2. 建模方法:

    结构化分析 SA (Structured Analysis),又分面向数据建模和面向数据流建模。

    面向对象分析OOA

需求说明

  1. 需求规格说明书SRS — 是需求分析的结果形成的文档

需求验证

为了及早消除隐藏的错误,确保需求说明准确、完整、清晰、无二义地表达产品的功能和质量要求

软件什么周期 — 软件设计

  1. ==软件开发的本质:==把客观世界映射到计算机的过程,这个映射的过程就是从抽象到具体逐步细化

  2. 输入: 需求规格说明书

    输出: 设计规格说明书

  3. 衡量软件独立性的标准 P97

    1. 内聚度
    2. 耦合度
  4. 模块的作用域应该在控制域之内

面向结构化的分析到设计

  1. 结构的基本单元是 模块
  2. 面向数据结构的方法:结构化分析SA,结构化设计方法SD,结构化程序设计SP
  3. DFD:数据流图;DD:数据字典

例题

简化的资格和水平考试的考务处理系统
分成多个级别,如初级程序员、程序员、高级程序员、系统分析员等,凡满足一定条件的考生都可参加某一级别的考试
考试的合格标准将根据每年的考试成绩由考试中心确定
考试的阅卷由阅卷站进行,因此,阅卷工作不包含在软件系统中

分析:

1.对考生送来的报名单进行检查
2.对合格的报名单编好准考证号后将准考证送给考生,并将汇总后的考生名单送给阅卷站
3.对阅卷站送来的成绩清单进行检查,并根据考试中心制订的合格标准审定合格者
4.制作考生通知单送给考生
5.进行成绩分类统计(按地区、年龄、文化程度、职业、考试级别等分类)和试题难度分析,产生统计分析表

DFD

image-20210620182046639 image-20210620182112632

考务处理系统1层图:

image-20210620182346012 image-20210620182423851

DFD->SC

image-20210620182346012 image-20210621204044862 image-20210620182807489 image-20210620182909185

面向对象从分析到设计

购物系统用例图,用例描述,活动图例题

客户通过相应的网址访问网上购物系统,进入系统后,客户即可通过多级分类目录逐级浏览商品的名称、规格、单价、图片等信息,直至阅浏览某个商品的详细技术指标。浏览过程中,客户可随时将需要的商品放到购物车内,系统可显示购物车内已选购的商品、单价、数量及价格,客户还可随时删去购物车内尚未结账的任何商品。
当客户选择好所需的商品后,可要求结账,此时,系统首先要求客户注册/登录(对新客户需先注册,填写客户信息,然后登录;对老客户只需通过用户名和密码直接进行登录即可),然后根据购物车中所选的商品形成初始的订单,同时选择支付方式,填写相关的派送信息,如送货地址、建议的送货时间段等,此时即可提交订单,系统向客户返回一个订单号。(最后形成了网上在线订购用例)

系统提供网上在线支付和货到现金支付两种支付方式。网上在线支付方式由专门的网上支付系统实现在线支付,需根据网上支付系统的要求填写相关的账户信息,如账号、密码等,并进行扣款,网上在线支付的结果或者是付款成功,或者是付款失败。货到现金支付方式由送货员在送达商品时向客户收取现金。客户还可通过订单号查询自己订单的当前状态,如已提交未付款、已发货已付款等,并允许取消尚未发货的订单。
系统业务员将客户提交的订单交由物流系统或快递公司向客户发货,又称派送,物流系统或快递公司送达商品后对未付款的客户收款,并将客户签收单返回给系统业务员,系统业务员负责更新订单的状态,以便跟踪和了解订单的执行情况。

  1. 识别执行者
    使用网上购物系统的人
    客户
    系统业务员
    与网上购物系统交互的其他外部系统
    实现网上在线支付功能的网上支付系统
    创建和维护客户信息的客户信息管理系统
    创建和维护商品信息的商品信息管理系统

  2. 识别用例
    客户使用网上购物系统的功能:
    商品信息浏览
    网上在线订购
    订单查询
    注册/登录
    支付
    系统业务员使用系统的功能:
    订单状态更新

进一步的说明:

  1. 由于注册/登录具有相对独立性,又可以被多个用例引用,因此,将其作为一个独立的用例

  2. 客户订购过程中会多次在购物车中添加商品、删除商品、显示购物车内的商品,可以将其合并成一个购物车管理的用例

  3. 由于商品信息有不同的详细程度,可以有多种多级分类目录的浏览方案,商品信息浏览功能相对独立,因此将其作为一个用例,称为商品信息浏览

  4. 网上在线订购是网上购物系统的主要功能,显然是一个用例。由于选购商品时都需要浏览商品信息,并在购物车中添加、删除商品,所以网上在线订购用例包含了购物车管理用例和商品信息浏览用例

  5. 物流系统或快递公司向客户送货、收款(只对未付款的客户),以及向系统业务员返回客户签收单都不属于本案例的网上购物系统

  6. 本案例中有网上在线支付和货到现金支付两种支付方式,通常可以标识出支付、网上在线支付和货到现金支付3个用例,后2个用例都继承支付用例。考虑到本案例对货到现金支付方式的处理比较简单,可以取消“货到现金支付”用例,此时,将上述3个用例简化成1个主要实现网上在线支付的用例“支付”

  7. 本案例的订单管理只包括订单查询、订单状态更新、取消订单等简单功能,可将其合并成一个用例,称为订单管理。如果订单管理还包括其他更多的功能,也可将其拆分成几个用例

  8. 由于选择支付方式和填写送货信息都比较简单,不作为独立的

网上购物系统的用例及其简要描述如下。

  1. 注册/登录:对新客户需先注册,即填写客户信息,然后进行登录;对老客户或系统业务员只需登录,即输入用户名和密码,并经校验合格即可

  2. 网上在线订购:在线订购商品,包括商品浏览、购物车管理、选择支付方式、填写送货信息等

  3. 商品信息浏览:显示商品信息

  4. 购物车管理:在购物车中添加商品、删除商品、显示购物车内的商品

  5. 支付:分为网上在线支付和货到现金支付,在采用网上在线支付时,调用网上支付系统,输入且确认账户信息,并进行扣款,网上支付系统返回付款成功或付款失败信息,供系统下一步决策使用

  6. 订单管理:订单查询、订单状态更新、取消订单等

  7. 用例之间的关系
    客户只能查询或取消自己的订单,所以客户在查询或取消订单前必须先登录,以确定其身份
    修改订单状态应该由授权的系统业务员进行操作,所以,系统业务员也必须登录后才可修改订单状态
    网上在线订购在要求结账时,需注册/登录
    网上在线订购用例和订单管理用例都使用了注册/登录用例
    由进一步说明得知“网上在线订购用例包含了购物车管理用例和商品信息浏览用例”

    image-20210620192324833

用例的描述
(1)网上在线订购用例的描述
用例名称:网上在线订购
参与的执行者:客户
前置条件:一个客户已进入网上购物系统
事件流:
基本流程
。。。

​ 可选流程:在选择提交订单前的任何时候,客户都可以退出系统,这次订购没有被保存,用例结束。
​ 后置条件:如果订单提交成功,订单将保存在系统中,并标记为已提交未付款状态

​ (2)订单管理用例的活动图描述
​ 客户成功登陆后系统自动显示该客户的订单列表
​ 客户可选择列表中的订单号,查看该订单的信息和执行状态
​ 客户在查看某订单的信息和状态后,执行取消该订单的操作。本案例规定只能取消未发货的订单,对已付款的订单,还应给予退款。为 避免客户误操作,通常在处理取消订单操作时应提醒客户确认,本活动图中省略了确认步骤。
​ 系统业务员成功登陆后可以由系统自动显示所有的订单列表,然后选择列表中的订单号,查看该订单的信息并修改其状态
​ 系统业务员也可以输入需查询或修改状态的订单的号码,如果订单库中存在与该订单号匹配的订单,则认为是有效订单号,允许进行查 询或修改状态操作。本活动图给出的是后一种处理方式。

网上购物系统类图例题

  1. 标识候选对象
    外部实体:客户,系统业务员,网上购物系统,物流系统,网上支付系统,客户信息管理系统,商品信息管理系统
    需要存储、处理的信息:商品的名称、规格、单价,购物车中的物件,订单的订单项(即选购的商品)、支付信息、送货信息。由此可导出候选对象是商品,购物车,订单

  2. 筛选候选对象
    物流系统:**未出现在用例图**中,删除
    网上支付系统:仅作为外部执行者完成网上在线支付功能,删除
    客户信息管理系统和商品信息管理系统:只是作为外部执行者参与创建和维护客户信息和商品信息,本案例并不关心这些外部系统的具体细节,删除
    系统业务员:在本案例中主要作为修改订单状态的输入者,其自身没有属性,删除

    网上购物系统:代表本案例的完整系统,所有信息的显示、操作界面等都由网上购物系统来展示,保留,称为“网上商城”
    客户、商品、购物车、订单:有明确的属性和操作,保留
    考虑到一份订单可以由多个订单项组成,一辆购物车可以放多件物品,因此增加订单项和物件两个对象

  3. 标识属性和操作

  4. 确定类之间的关系

    网上商城拥有多件商品和购物车,并能从网上商城查到所有的商品信息
    任意多个客户可以到网上商城订购商品,网上商城能查到所有的注册客户信息
    一个客户可以拥有多份订单,客户可以查看自己的全部未到货订单
    一份订单由多个订单项组成
    一个客户只有一辆购物车
    一辆购物车可以放多件物件,从购物车可以查到车内所有的物件
    一个订单项或物件对应一个商品,但一个商品可对应多个订单项或购物车中的多个物件

image-20210620214019115

电梯升降状态图例题

1)列出对象具有的所有状态
状态分为起始状态、结束状态和中间状态。一张状态图可以有一个起始状态和若干个(可以为0)结束状态
2)标识导致状态转换的事件
当一个对象接收到某个事件时,会导致从一个状态转换到另一个状态,称为状态迁移(transition)
3)为状态和迁移定义状态变量和动作
在状态迁移到某个状态中时都可能需要执行一些相应的动作,综合这些动作,使得对象完成相应的功能,必要时可以加入一些状态变量。

image-20210620221027647

订单对象状态图例题2

订单对象的状态图
分析案例描述和顺序图得知,订单的执行状态有创建订单时的未提交状态、提交订单时的已提交状态、完成派送调度时的已发货状态、客户签收时的已交付状态,还有取消订单时的已取消状态
订单的付款状态有未付款状态已付款状态
二者相结合得到如下订单状态:未提交、已提交未付款、已提交已付款、已发货未付款、已发货已付款、已交付、已取消
其中,未提交状态和已取消状态一定是未付款,已交付状态一定是已付款

image-20210621085649104

喝饮料活动图例题

image-20210622094756264

image-20210622094838113

在线订购顺序图例题

网上在线订购的顺序图
该图只描述了形成一张订单的消息发送顺序,省略了形成一张订单后再次购物等复杂情况。

image-20210622095637621

选课系统活动图与顺序图例题

某学校的网上选课系统主要包括如下功能:管理员通过系统管理界面进入,建立本学期要开的各种课程,将课程信息保存在数据库中并可以对课程进行修改和删除,学生通过客户机浏览器根据学号和密码进入选课界面,在这里学生可以进行两种操作,查询已选的课程,选课。同样,通过业务层,这些操作结果存入数据库中。
画出管理员添加课程操作的活动图
画出学生选课的顺序图

image-20210621090833607

image-20210621090853753

Guess you like

Origin blog.csdn.net/qq_43779658/article/details/118426730
Recommended