当前位置：首页 > news >正文

11、软件需求工程

news 2025/8/17 16:58:39

软件需求概述

软件需求

需求分类【记忆】

常规分类

业务需求：高层次的功能描述
用户需求：用户操作流程，使用系统能带来什么。
系统需求：描述系统功能

从质量功能分类：

习题

1、视频

1、 A
2、B C A

软件需求模型

需求获取

是一个确定和理解不同项目干系人的需求和约束的过程。

需求获取的方法：【记忆】

用户访谈
问卷调查
采样
情节串联板
联合需求计划
需求记录技术

习题

1、视频

ADC

需求分析

需求分析概述

需求分析分为：结构化分析、面向对象分析。

需求分析的任务：

面向问题域的分析PDOA：

结构化需求分析

3大模型：功能模型、行为模型、数据模型

数据流图

数据字典

面相对象需求分析【重要】

基本

对象：由数据及其操作所组成的封装体

类：实体的形式化描述
类分为：实体类、接口类、控制类
实体类：表示真实实体。如用户、订单
接口类（边界类）：与其他类进行连接交互的(实体)类。如用户界面、窗体、各种系统接口。依赖交互环境。
控制类：控制活动、充当协调者，单纯就是控制。

抽象：提取主要特征。

封装：一种信息隐蔽技术
继承：类的层次关系

多态：有参数多态、包含多态、过载多态（类似重载），强制多态。继承时重写父类方法从而达到同一接口，不同行为的效果。

接口：
消息
覆盖
函数重载

习题

1、视频

1、方法重载

2、客户属于实体类，二维码属于边界，所以是接口类

面相对象需求分析

面相对象的分析：为了确定问题域，理解问题。包括5个活动：认定对象、组织对象、描述对象间的相互作用、确定对象的操作、定义对象的内部信息。

面向对象的需求建模：

用例模型：步骤：识别参与者、合并需求获得用例、细化用例描述、调整用例模型
分析模型：步骤：定义概念类、识别类之间的关系、为类添加职责、建立交互图

统一建模语言-UML

UML

基本概念

UML（统一建模语言）：是一种可视化的建模语言，不是程序设计语言。支持从需求分析开始的软件开发的全过程。

UML结构包括：构造块、规则、公共机制3部分。
构造块：UML3种基本的构造块：事物、关系、图。事物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合。
公共机制：达到特定目标的公共UML方法。
规则：构造块如何放在一起的规定。

1、事物分类

结构事物：模型的静态部分、如类、接口、用例、构件等。
行为事物：模型的动态部分，如交互、活动、状态机。
分组事物：模型的组成事物，如：包。
注释事物：模型的解释部分，依附于一个元素或一组元素上对其进行约束或解释的简单符号。

2、关系分类【重要，记住图】

依赖：一个事物的寓意依赖于另一个食物的语义的变化而变化。
关联：一种结构关系，描述一组链、链地对象之间的连接，分为组合和聚合，都是部分和整体的关系，其中组合事物之间关系更强。两个类之间的关联，实际上是两个类所扮演角色的关联。因此，两个类之间可以有多个不同角色标识的关联。【最广泛，几乎一切都有关联关系】
泛化：一般/特殊的关系，子类和父类之间的关系。
实现：一个类元指定了另一个类保证执行的契约。

习题

1、视频

1、D，音乐系统不是组成汽车必须的。

2、实线是关联关系
菱形是组合关系
UML类图不用于对【对象快照】记下来建模。

UML图

类图

类图：静态图，系统的静态设计图，展现一组对象、接口、协作和他们之间的关系。

对象图

对象图：静态图，展示某一时刻一组对象以及他们之间的关系，为类图的某一快照。在没有类图的前提下，对象图就是静态设计视图。

用例图【重要】

用例图：静态图，展现了一组用例、参与者以及他们之间的关系。
用例图的参与者是人、硬件或其他系统可以扮演的角色；用例是参与者完成的一系列操作，用例之间的关系有扩展、包含、泛化。

会员注册包含电话和邮件两种注册方式，他们是什么关系？

扩展：一个用例在特定条件下增强另一个用例的行为。基础用例可独立执行，扩展用例仅在触发条件下执行。
这里电话和邮件是注册的不同方式，并非扩展动作。
比如：【基础用例：购物，扩展：优惠券】、【基础：查询航班信息，扩展：导出行程单】、【基础：用户登录，扩展：短信验证。系统检测异地登录时触发短信验证。】、【登录时的忘记密码功能】
包含：表示一个用例必须调用另一个用例的功能，被包含用例是公共行为的一部分，不可或缺。。
电话和邮件（注意是和，一起）并非会员注册必须执行的部分，所以不是包含关系。
比如：【订单生成必须有用户验证】、【提现必须绑定账户】
泛化：描述父用例与子用例的继承层次，子用例特殊化父用例的行为。
电话和邮件注册是会员注册的具体实现，符合泛化中子用例特殊化父用例的情况。
例如：【支付泛化出微信支付和银行卡支付】、【员工管理泛化出管理层、工程师多角色。】

序列图

即顺序图、动态图，是场景的图形化表示，描述了以时间顺序组织的对象之间的交互活动，有同步消息、异步消息、返回消息。
同步消息：进行阻塞调用，调用者终止执行，等待控制权的返还，需要等待返回消息，用实心三角箭头表示。
异步消息：发出消息后继续执行，不引起调用者阻塞，也不等待返回消息，由空心箭头表示。
返回消息：从右到左的虚线箭头表示。

通信图

通信图：动态图、协作图。强调参与交互的对象的组织。

状态图【重要】

状态图：动态图。展现了一个状态机，描述单个对象在多个用例中的行为，包括简单状态和组合状态。
转换可以通过事件触发器触发。事件触发后相应的监护条件会进行检查。
状态图中转换和状态是两个独立的概念。图中方框表示状态，箭头上的代表触发的事件，实心圆点为起点和终点。

UML状态图详解

UML状态图（State Diagram）是一种行为图，用于描述一个特定对象在其生命周期所有可能的状态、状态间的转换以及触发这些转换的事件，它关注对象的动态行为而非操作流程。以下详细介绍其核心知识点：

1. ‌核心组成元素‌

状态图由五种基本元素构成：

状态（State）‌：表示对象在生命周期中的一种条件或情况，如“待支付”或“已发货”，通常用圆角矩形表示，包含状态名和可选的活动代码（如入口动作、出口动作）。
转换（Transition）‌：连接两个状态，表示状态迁移路径，由事件触发，可附加监护条件（如 [条件]）和效果动作。
事件（Event）‌：引发状态转换的外部或内部刺激，如用户操作或系统信号（例如“订单提交”事件）。
动作（Action）‌：原子计算单元，在转换或状态中执行，不可中断（如 entry/生成物流单号）。
活动（Activity）‌：非原子执行序列，在状态内持续进行（如 do/数据校验），由多个动作组成。

2. ‌状态图的要素与类型‌

特殊状态‌：
初始状态：用实心圆表示，标识对象生命周期的起点。
终止状态：用内部实心的同心圆表示，标识生命周期的结束，可以有多个或无。
状态内部行为‌：
入口动作（entry/动作）：进入状态时自动执行。
出口动作（exit/动作）：离开状态时自动执行。
Do活动（do/活动）：状态存续期间持续执行。
组合状态‌：包含子状态，用于简化复杂逻辑：
顺序子状态：子状态互斥，对象同一时刻仅处于一个子状态（如“支付中”包含“信用卡支付”和“微信支付”）。
并发子状态：子状态同时执行，用分叉和合并节点表示。

3. ‌功能与应用场景‌

状态图的核心功能是捕捉对象对事件的响应逻辑：

功能优势‌：
精确模拟复杂行为（如协议栈或GUI交互），避免设计漏洞如死锁状态或无法到达的状态。
提升团队沟通效率，作为开发、测试、产品人员的通用语言。
支持代码生成，减少编码错误。
适用场景‌：
对象行为高度依赖当前状态（如电梯控制系统、订单生命周期）。
需验证状态转换健壮性的系统（如金融交易审核）。