首页 前端知识 【软件工程】需求分析

【软件工程】需求分析

2024-05-19 09:05:20 前端知识 前端哥 163 715 我要收藏

目录

  • 前言
    • 需求分析
    • 需求获取
    • UML概述
    • 用例图
      • 用例图的组成
      • 用例图中的符号和含义
        • 包含的两种使用场景
      • 用例图补充:“系统”
      • 用例模型建模
        • 确定系统参与者
        • 确定系统用例
    • 用例文档
      • 用例文档组成部分
    • 活动图
      • 组成元素
        • 初始节点和终点
        • 活动节点
        • 转换
        • 决策与分支、合并
        • 分岔与汇合
    • 类图
      • 类的表示
        • 类的命名
        • 类的属性
        • 类的方法的命名规范
        • 类的职责
      • 类图中的关系
        • 关联
        • 聚集
          • 聚合和组合的区别
        • 依赖
        • 泛化
        • 实现
    • 顺序图
      • 顺序图组成元素
        • 对象
        • 生命线
        • 控制焦点(激活期)
        • 消息
        • 顺序图补充-----1.消息编号
        • 分析类
          • 边界类(Boundaryclass)
          • 控制类Control
          • 实体类(Entityclass)
    • OOA动态模型-状态图(未完)

前言

软件工程生命周期分为八个阶段:
问题定义—>可行性研究—>需求分析
—>概要设计—>详细设计—>编码与单元测试
—>综合测试—>软件维护

这节我们讲的是软件开发流程中的一个阶段,需求分析。


需求分析

任务:系统必须做什么?

  • 获取用户需求,从用户角度考虑,用户需要系统完成哪些工作,也就是对目标系统提出完整、准确、清晰、具体的要求
  • 提交的主要文档:
    软件需求规格说明书:以书面形式准确地描述软件需求。

需求获取

  • 自悟
  • 访谈
  • 小组会
  • 快速建立软件原型

UML概述

UML (Unified Modeling Language-----统一建模语言)为面向对象软件设计提供统一的、标准的、可视化的建模语言。
UML是一种可视化的建模语言。

  • 建模:
    建立模型,通过对客观事物建立一种抽象的方法,用来表征事物并获得对事物本身的理解,是对事物的一种无歧义的书面描述。
  • 建模是一种常用的、深入理解并解决问题的方法
  • 建模原则:
    现实世界能够映射到模型
    模型能够描述现实世界;
    模型行为能够正确反映现实世界方法

用例图

用例图是指由参与者(Actor)、用例(Use Case)以
及它们之间的关系(Relationship)构成的用于描述系统功能的静态视

  • 用例图是外部参与者所能观察到的系统功能的模型图。
  • 用例是参与者要实现的最终目标
  • 用例图还是软件测试人员进行测试的指导

用例图示例:
请添加图片描述

用例图的组成

  • 参与者(Actor)
  • 用例(Use Case)
  • 关系(Relationship)

用例图中的符号和含义

请添加图片描述

  1. 参与者与用例之间如果有明显的使用关系,可以加箭头
  2. 由于一个用例代表一个系统功能,扩展是指在用例上扩展一个功能,这个功能不一定被执行,扩展用例在一定条件下才执行。扩展用例是可选的,如果缺少扩展用例,不会影响到基用例的完整性。
  3. 包含用例是属于从基用例分解出来的用例,包含用例一定会被执行,如果缺少包含用例,基用例就不完整。
    请添加图片描述
包含的两种使用场景
  1. 使用包含用例来封装一组跨越多个用例的相似动作,以便被多个基用例复用。包含关系最典型的应用就是复用。
  2. 当某用例的事件流过于复杂时,为了简化用例的描述,我们也可以把某一段事件流抽象成一个被包含的用例

用例图补充:“系统”

  1. 系统被看作是一个提供用例的黑盒子
  2. 描述该系统功能的用例置于方框内,代表外部实体的行为置于方框外
    请添加图片描述

用例模型建模

任务:获取需求,建立需求模型

  1. 确定系统参与者
  2. 确定场景
  3. 确定系统用例
  4. 确定用例之间关系
  5. 用例文档的编写。
确定系统参与者

参与者是指直接和系统交互的一类事物,参与者
主要有如下三类:

  • 直接使用系统的人,如 图书管理员,普通读者等(角色)
  • 与该系统相关的其他系统,如支付系统、邮件系统
  • 自动发生的事件,如时间,温度等自动驱动用例功能的事件。
确定系统用例

用例是对一组场景共同行为的抽象。
重点在于参与者与系统之间的交互而不是系统内部的活动。

  • 可观测:
    用例是参与者与系统的交互,不是系统内部的活动,且一定是参与者主动发起的,最后结果一定要反馈给参与者。习惯说用例止于边界。
  • 结果值:
    每个用例都会对外界参与者产生一个有价值的结果。
  • 系统执行:结果值由系统所生成
  • 由参与者执行:用例的识别和定义都是从参与者角度出发,要以参与者的视角获取和定义

用例文档

  • 用例文档是用于描述用例的文档,每一个用例对应于一个用例文档。
  • 在用例文档中需要用文字的方式描述用例的执行过程,即执行者与系统的交互过程。
  • 用例建模包括用例图的绘制和用例文档的编写。

用例文档组成部分

  • 用例名称
  • 用例描述
  • 参与者
  • 前置条件
  • 后置条件
  • 基本事件流
  • 异常事件流
  • 其他事件流
  • 扩展点
    请添加图片描述
    请添加图片描述

活动图

活动图是动态行为图:用于描述系统的工作流程或用例的内部行为。

组成元素

  • 初始节点和终点
  • 活动节点
  • 转换
  • 决策与分支,合并
  • 分岔与汇合
初始节点和终点
  • 初始节点表示活动的起点,用一个实心圆表示
  • 终点表示活动的终结点,用一个圆圈内加一个实心圆来表示活动终点.
  • 在活动图中,可能包含多个活动终点

请添加图片描述

活动节点

表示一个活动,一个活动表示一个或多个动作的集合。

转换
  • 当一个活动结束时,活动控制流就会传递给下一个活动节点,在活动图中称之为“转换”.
  • 用一条带箭头的直线(或折线)来表示转换。
决策与分支、合并
  • 决策与分支:
    用菱形表示的一个或多个离开转换。
    • 每个离开转换上都会有一个监护条件,
    • 用来表示满足什么条件的时候执行该转换。
  • 合并:
    指两条或多条控制路径汇合的情况
    • 用菱形符号表示。
      在这里插入图片描述
分岔与汇合

分岔:
表示一个控制流被两个或多个控制流代替,经过分岔后,这些控制流是并发进行的。
汇合与分岔相反,表示两个或多个控制流被一个控制流代替。
在这里插入图片描述

类图

  • 类(Class)、对象(Object)和它们之间的关系是面向对象技术中最基本的元素。

类的表示

请添加图片描述

类的命名

在这里插入图片描述

类的属性

请添加图片描述
请添加图片描述

类的方法的命名规范

请添加图片描述

类的职责

职责指的是类所担任的任务:即类要完成什么样的功能,要承担什么样的义务。

类图中的关系

  • 关联
  • 聚集:包括聚合和组合
  • 依赖
  • 泛化
  • 实现
关联

关联表示两个类的对象之间存在某种语义上的联系。
长期的,稳定的。
表现在代码实现中,一个对象会作为另一个对象的属性关联关系。
某个类的对象可以和其他类的多个对象联系。

举例:
购物功能:管理员查询用户的订单情况。用户和订单之间的关系就是关联。
请添加图片描述
请添加图片描述

聚集
  • 聚集是关联的一种特殊情况。
  • 聚集表示类与类之间的关系是整体与部分的关系。
    请添加图片描述
    聚集分为聚合和组合:
  • 聚合
    请添加图片描述
    重点:
    课题组没了,不会导致人的消失。
    即“整体不存在了,部分还存在”。

    设计中:
    • 人的数组作为课题组的一个属性。
    • 课题组集合作为人的一个属性。

数据库操作中,课题组的删除,不涉及到人员删除。

  • 组合
    如果部分类完全隶属于整体类,部分与整体共存,整体不存在了部分也会随之消失,则该聚集称为组合。

在这里插入图片描述
请添加图片描述

聚合和组合的区别

在这里插入图片描述
请添加图片描述

依赖

依赖关系描述两个类之间的使用关系:

  • 两个类之间是没有关系的
  • 但是一个类的实现需要另一个类的协助,这就产生了依赖。

依赖关系的代码表现:
方法的局部变量、方法参数、对静态方法的调用
注意:依赖关系不会增加属性

泛化

UML中的泛化关系就是通常所说的继承关系,它是通用元素和具体元素之间的一种分类关系。具体元素完全拥有通用元素的信息,并且还可以附加一些其他信息。

在UML中,用一端为空心三角形的连线表示泛化关系,三角形的顶角紧挨着通用元素。
在这里插入图片描述
抽象类或者抽象操作的名字用斜体表示
请添加图片描述

实现

对应于类和接口之间的关系。

  • 接口:
    接口通常是指一组方法的抽象集合,它们定义了类或结构体应该实现的行为。
  • 接口中只包含方法的名字而不包含方法的具体实现。(多态)
    在这里插入图片描述

顺序图

  • 顺序图是动态交互图,用于显示对象间的交互活动,它关注对象之间消息传送的时间顺序。
  • 目的:通过顺序图来对执行者和系统的交互过程进行建模,方便用户更好地理解系统的工作流程

顺序图组成元素

  • 对象-----Object
  • 生命线-----Lifeline
  • 控制焦点(激活期)-----Activation
  • 消息-----Message
对象

一般命名方式:

对象名:类名
在这里插入图片描述

生命线
  • 表示对象存在的时间
  • 如果对象生命期结束,则用注销符号表示
    在这里插入图片描述
控制焦点(激活期)
  • 对象执行某个动作的时期
    在这里插入图片描述
消息
  • 对象间交互信息的方式,表示为从一条生命线到另一条生命线的箭头
  • 箭头指向详细的接收者,表示对其操作的调用。
  • 每种消息的箭头不一样
    同步消息:
    发送者把消息发送后,等待,直到接收者返回控制,即必须得到回应才能进行下一项操作。
    在这里插入图片描述
    异步消息:
    消息可以是一个信号或一次操作调用,收到消息即为事件。
  • 可以有两种异步消息:
    • 一种是发送者向接收者发送信号
    • 另一种是由调用者调用接收者的操作

在这里插入图片描述
返回消息(虚线表示):
表示消息的返回。一般同步的返回不需画出,直接隐含,也可使用返回消息强调返回结果值。
在这里插入图片描述

顺序图补充-----1.消息编号
  • 顺序编号——在每个消息的前面加上一个用冒号隔开的顺序号来表示其顺序。
    在这里插入图片描述
  • 嵌套编号——把属于同一个对象发送和接收的消息放
    在同一层进行编号。
    在这里插入图片描述
分析类

对象系统中所有功能都是由类来实现,这些类是从用例文档中找出,并将其所描述的系统行为分配到这些类中,在面向对象分析阶段所定义的这些类通称为分析类。

  • 分析类对应MVC架构的三个层次:Boundary,Control,Entity。
边界类(Boundaryclass)

位于系统与外界的交界处,处于系统最上层,处理系统环境和系统内部间的通信。
边界类分为两类:

  • 用户界面类:系统与外部进行交互的类,在分析阶段关注于为用户提供哪些操作,如用户输入数据,展示数据给用户。
  • 系统/设备接口类:系统与外部系统或设备之间交互的接口类,在分析阶段关注交互的协议。

UML中边界类的表示:
在这里插入图片描述

控制类Control
  • 处于中间层,封装上层的边界类和下层的实体类之间的交互行为,是整个用例行为的协调器
  • 控制类可以有效的将边界对象和实体对象分开
    • 将用例所特有的行为与实体对象分开,使实体对象有更高的复用性。
    • 更适应系统边界对象的变更;

特点:

  • 独立于外部环境,不依赖于环境的变更
  • 定义控制逻辑和事务逻辑
  • 实体类内部结构或行为发生变更时控制类不会有大的变更。

UML中控制类的表示:
在这里插入图片描述

实体类(Entityclass)

代表系统的核心概念,来自对业务中的实体对象的抽象,用于记录系统所需要维护的数据和对这些数据的处理行为。
UML中实体类的表示:
在这里插入图片描述

在这里插入图片描述

OOA动态模型-状态图(未完)

  • 一个UML状态图是为了以下的研究目的:研究类、角色、子系统、或组件的复杂行为。
  • 状态图作用:
    • 描述一个特定对象的所有可能状态及其引起状态转移的事件。
    • 描述业务领域的业务流程:在什么状态下,有什么事件发生,导致了什么后果。

在这里插入图片描述

转载请注明出处或者链接地址:https://www.qianduange.cn//article/8823.html
评论
会员中心 联系我 留言建议 回顶部
复制成功!