软件工程复习L3

Requirements engineering 需求工程

1. 需求：反映了客户对有助于解决某些问题的系统的需求
2. 需求工程：发现、分析、记录和检查系统服务和约束的过程

The Requirements Process

在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复的。

Types of Requirements

• Requirements: 在环境域内定义的任何需求，包括系统接口
• Specification: 规范仅限于环境和系统域之间的交叉点

Software requirements 软件要求

• 用户需求--User requirements
  • 高级抽象需求--High-level abstract requirements
  • 以自然语言和图表表示的语句，说明系统预期提供的服务以及它必须在哪些约束条件下运行
• 系统要求--System requirements
  • 系统应执行的操作的详细说明
  • 详细说明系统的功能、服务和操作限制
  • 应该是准确的

Different kinds of software requirements for different users

Requirement Type

• 功能要求--Functional requirements
  • 系统应提供的服务声明、系统应如何对特定输入做出反应以及系统在特定情况下的行为
• 非功能性需求--Non-functional requirements
  • 对系统提供的服务或功能的限制，包括时间限制、开发过程和标准的限制
    • timing constraints, constraints on the development process and standards
• 域要求--Domain requirements
  • 来自系统的应用领域，并反映该领域的特征和约束
    • application domain of the system
    • characteristics and constraints of that domain

Functional requirements

• 描述系统应该做什么

• LIBSYS示例

  • 用户应能够搜索所有初始数据库集或从中选择子集

• 完整性--Completeness

  • 应定义用户所需的所有服务

• 一致性--Consistency

  • 需求不应有相互矛盾的定义

Non-functional requirements

非功能性需求

• 是与系统交付的特定功能不直接相关的需求
• 可能与紧急系统属性有关，如可靠性、响应时间和存储占用率
• 未能满足非功能性要求可能意味着整个系统无法使用（飞机系统：可靠性）

• 只要可能，您应该定量地编写非功能性需求，以将其目标转化为定量需求
  • 速度：处理事务/秒，用户/事件响应时间
  • 大小：K字节，RAM芯片数
  • 可靠性：平均失效时间
• 如果您可以在需求文档中区分功能性需求和非功能性需求，这将非常有用。实际上，这很难做到

Specification 规范

• 需求是用文本文档中的自然语言语句编写的
  • 缺乏清晰性，难以精确和明确

指导方针

• 发明一种标准格式
• 始终如一地使用语言
• 使用文本突出显示来选择需求的关键部分
• 尽可能避免使用计算机术语

自然语言问题

• 自然语言通常用于编写系统需求规范，它可能会造成混乱和难以理解
• 自然语言理解依赖于规范读者和作者对同一概念使用相同的词语
• 自然语言需求规范过于灵活
• 没有简单的方法来模块化自然语言需求

Structured language specifications

优点

• 保持自然语言的大部分表达性和可理解性
• 确保规范具有一定程度的一致性

Interface specification 接口规范

三种类型的接口

• 程序接口（如API）
• 数据结构
• 数据表示（如位的顺序）

The software requirements document 软件要求文档

• 或称为软件需求规范（SRS）-- Software requirements specification

• 软件需求规范的读者

  • 系统客户
  • 管理者
  • 系统工程师
  • 系统测试工程师
  • 系统维护工程师

• 需求文档的结构

  • 前言
  • 介绍
  • 用户需求定义
  • 系统架构
  • 系统需求说明
  • 系统模型
  • 系统演化
  • 附录
  • 指数

Modeling 建模

抽象--Abstraction

抽象有助于控制问题复杂度，抓住问题的本质,获取一般和特殊关系

Modeling Notations 建模符号

• 对于建模、记录和沟通决策，使用标准符号(standard notations)是很重要的

• 建模帮助我们彻底理解需求

Entity-Relationship Diagrams

一种用于表示概念模型的流行图形符号范式

• Entity
  • 描述为矩形，表示具有公共属性和行为的真实世界对象的集合
• Relationship
  • 描述为两个实体之间的边缘，边缘中的菱形指定关系类型
• attribute
  • 实体上的注释，用于描述与该实体关联的数据或属性

Event Traces 事件跟踪

• 真实世界实体之间交换的事件序列的图形描述

  • A graphical description of a sequence of events that are exchanged between real-world entities

  • 垂直线(Vertical line)：不同实体的时间线，其名称显示在该行的顶部

  • 水平线(Horizontal line)：围绕该线的两个实体之间的事件或交互

  • 时间是从上到下的

• 每个图都描述了一个跟踪，表示几种可能的行为之一

• Message Sequence Chart
  • 一种增强的事件跟踪表示法，具有创建和销毁实体、指定操作和计时器以及组成跟踪的功能
    • 垂直线(Vertical line)表示参与的实体
    • 消息(Message)被描述为从发送实体到接收实体的箭头
    • 动作(Action)被指定为位于实体执行行上的带标签的矩形
    • 条件(Condition)是实体演化中的重要状态，表示为标记的六边形

Petri Nets

一种形式或状态转换(state-transition)符号，用于对并发活动及其交互进行建模

• 圆圈(Circle)（地点）代表活动或条件

• 条形图(Bar)表示转换(transitions)

• 圆弧(Arcs)将transitions与其输入位置和输出位置连接起来

• 这些位置由令牌(tokens)填充，这些令牌充当转换的启用条件

• 可以为每个arc指定一个权重(weight)，该权重指定在触发转换时从arc的输入位置移除多少tokens

Functions and Relations

• 形式化方法或途径：基于数学的规范和设计技术
• 形式化方法将需求或软件行为建模为数学函数或关系的集合
  • 函数指定系统执行和输出的状态
  • 每当输入值映射多个输出值时，就会使用关系

Functions and Relations的示例：Parnas表

• 列标题和行标题是用于指定案例的谓词
• 条目“X”在指定条件下可能无效，或者条件组合不可行

Decision Tables

• 它是功能规范的表格表示，将事件和条件映射到适当的响应或操作
• 如果有n个输入条件，则有2n个可能的输入条件组合
• 映射到同一组结果的组合可以组合到单个列中

Decision Trees

• 三种类型的“节点”
  • 决策节点(Decision nodes)-由正方形表示
  • 机会节点(Chance nodes)-由圆表示
  • 终端节点(Terminal nodes)-由三角形表示（可选）
• 求解该树需要修剪决策节点上除最佳决策外的所有决策，并在机会节点上找到所有可能的自然状态的期望值
• 从左到右创建树
• 从右到左求解树

Logic

• 操作符号(operational notation)是用于描述问题或建议的软件解决方案的情景行为的符号
  • 基于案例的行为模型
  • 示例：状态机、事件跟踪、数据流图、功能方法
• 描述性表示(descriptive notation)法是根据问题的性质或变体来描述问题或建议解决方案的表示法
  • 示例：逻辑

Petri Nets

介绍

• Graphical and Mathematical modeling tools
  • 图形和数学建模工具
• 图形工具
  • 视觉传达辅助
• 数学工具
  • 状态方程、代数方程等
• 并发(concurrent)、异步(asynchronous)、分布式(distributed)、并行(parallel)、非确定性(nondeterministic)和/或随机(stochastic)系统

非正式定义

• Petri Nets的图形表示是一个二部图（bipartite graph）
• 有两种节点(node)
  • Places：通常是模型资源(resource)或系统的部分状态 圆形
  • transitions: 模型状态转换和同步 方形
• Arcs: 是有向的并且总是连接不同类型的节点

例子

State

• 系统的状态是通过用令牌(token)标记位置来建模的
• 一个地方可以用有限数量（可能为零）的标记来标记

Fire 触发

• 转换 t 在某个标记中被称为启用，如果对于从位置 p 到 t 的每条arc，标记中都存在一个不同的标记

• 启用的转换可以触发并产生新的标记

• 在标记中触发转换 t 是一个原子(atomic)操作

• 触发转换会导致两件事：

  • 对于连接 p 到 t 的每条弧线，从任何位置 p 的标记中减去一个记号
  • 对于连接 t 到 p 的每条弧线，在任何位置 p 的标记上添加一个记号

图形表示

Nondeterminism 不确定性

• Petri Networks的执行是不确定的
  • 可以同时启用多个转换，其中任何一个都可以触发
  • 不需要触发 - 它们随意触发，在时间 0 到无穷大之间，或者根本不触发

Concurrency 并发

独立输入允许“并发”触发转换

Conflict 冲突

重叠输入使转换发生冲突 -- Overlapping inputs put transitions in conflict

​ 可能激发序列\(t1,t3,t5\)无限循环，而 \(t2,t4,t6\)被“饿死”

Solution

Mutual Exclusion 互斥

两个子网强制同步

Bounded Buffers 有界缓冲区

Liveness and Deadlock 活性与死锁

• 活力：
  • 如果一个转换永远不能触发，它就是死锁的。
  • 如果转换永远不会死锁，它就是live的。

时间 Petri Network

• 时间Petri网的思想：即使一个变迁处于使能状态，它也必须经过\(t_{min}\)之后才能被触发，且必须在\(t_{max}\)之前。

Fork and Join

Iteration: 1 or more times

Exercise

一个交通灯

Example: Single traffic light

两盏交通灯

使用互斥的原理

Restaurant

Restaurant (Two Scenarios)

• Scenario 1:
  • Waiter takes order from customer 1; serves customer 1; takes order from customer 2; serves customer 2.
• Scenario 2:
  • Waiter takes order from customer 1; takes order from customer 2; serves customer 2; serves customer 1.

Formal Definition

Related Models

Finite State Processes

Finite State Nets

• Some Petri nets can be modelled by FSPs

Implementing Petri

• 我们可以以集中或分散的方式实现 Petri 网结构
  • 集中--Centralized
    • 单个“网络管理器”监视网络的当前状态，并触发启用的转换。
  • 分散--Decentralized
    • Transitions 是进程，places 是共享资源，transitions 竞争获取令牌。

Centralized schemes

在一种可能的集中式方案中，管理器选择并触发启用的转换。

可以并行触发并发启用的转换。

Decentralized schemes

转换是过程，令牌是地方持有的资源

Role of a token

token可以起到以下作用：

• 物理对象，例如产品、零件、药物、人；
• 信息对象，例如消息、信号、报告；
• 对象的集合，例如装有产品的卡车、装有零件的仓库或地址文件；
• 状态指示符，例如进程所处状态的指示符，或对象状态的指示符；
• 条件指示符：令牌的存在表明是否满足某个条件。
• 一种通信媒介，如电话线、中间人或通信网络；
• 缓冲区：例如，仓库、队列或邮筒；
• 地理位置，例如仓库、办公室或医院中的某个地方；
• 可能的状态或状态条件：例如，电梯所在的楼层，或有专家可用的条件。

Role of a transition

• 事件：例如，开始手术、患者死亡、季节变化或交通灯从红色变为绿色；
• 对象的转换，例如调整产品、更新数据库或更新文档；
• 对象的运输：例如，运输货物或发送文件。