31 互联网程序设计

Tue, 05 May 2026 20:34:35 +0800

31-互联网程序设计

21 数据挖掘网课 7.12

Sat, 12 Jul 2025 20:07:33 +0800

7.12 b 站预习数据挖掘网课记录

15 概率论期末复习

Sat, 07 Jun 2025 15:28:42 +0800

考试范围：

概率论第1章统计学的基础知识
概率论第2章随机变量的分布与数字特征
概率论第3章随机向量

复习进度：

6.7 第3章基础

思科第六章小测应用层

Sat, 31 May 2025 20:41:28 +0800

19-思科第六章小测-应用层

思科第五章小测传输层

Sat, 31 May 2025 20:07:06 +0800

18-思科第五章小测-传输层

14 数据库第8章

Fri, 30 May 2025 11:55:37 +0800

关系数据库的设计

思科第四章小测 IP寻址

Fri, 23 May 2025 19:46:59 +0800

软件工程5.21

Wed, 21 May 2025 14:39:35 +0800

进程视图

面向系统架构师和开发人员
适用于多进程多视图，关注系统的并发性、分布性、性能和资源分配
形式
- UML类图
进程间的交互
- 进程间的交互可以用时序图表示
单线程的Web服务器

概率论-第三章笔记

Mon, 19 May 2025 23:42:02 +0800

第3章随机向量

概率论-第二章复习

Mon, 12 May 2025 23:52:10 +0800

第二章复习

2.3 常用的离散型分布

一、退化分布

定义：
- $$P{X=a} = 1$$
- X 服从 a 处的退化分布。也就是永远取一个确定的常数 a
期望：
- $$E(X) = 0$$
方差：
- $$D(X) = 0$$

二、两点分布

定义：
- 只有两个可能的取值
- $$P{X=x_1}=p,\quad P{X=x_2}=1-p,\quad 0<p<1,$$
- X 服从 a 处参数为 $x_1$, $x_2$ 的两点分布

三、均匀分布

四、二项分布

五、几何分布

六、超几何分布

七、泊松分布

2.4 常用的连续性分布

一、均匀分布

二、指数分布

三、正态分布

2.5 随机变量函数的分布

一、随机变量的函数

二、离散型随机变量函数的分布

三、连续性随机变量函数的分布

软件工程思路笔记

Sun, 11 May 2025 19:24:08 +0800

tags: [TOC]

需求工程

用例规约

1. 画出Use Case

2. 编写用例规约

1. 可选需求

2. 非功能需求

3. 黑盒用例规约和白盒用例规约

随着开发的过程要不断添加细节
- 1.识别用例：有哪些时间、actor
- 2.用例分布提纲：+前置条件 +后置条件
- 3.（非技术甲方）黑盒规约：+完整的事件流
- 4.（技术人员）白盒规约：+系统内部行为的细节描述
可以采用双列（用户视图 | 系统视图）

3. 用例图优化

符号：
- Include包含
  - 从基本用例→包含用例，包含用例为基本用例提供功能
  - <>衍型
- Extend扩展
- Generalization泛化（类似类中的继承关系）
Include关系
- 基数
- Include中，不需要处理条件，
- 分离非主要行为，突出用例的核心价值
- 提出多个用例存在一段共有的行为，可以提取出来反复使用
Extend关系（见图）
- Extension扩展用例——Base基本用例
- 基数
- 扩展关系符号是
Generalization泛化，

建立概念模型Conceptual Class

识别Conceptual Class

分类法
- 物理实体
- 逻辑实体
- 组织实体
名词提取法
- 1.从规约中提取所有名词，可重复
- 2.去掉：冗余、执行者和系统本身、边界类（菜单、链接）、类的属性
- 3.得到基本概念类
- 易错：类的实体当做属性被删掉（e.g.型号）
  - 属性特征：数字，文本
  - 因此如果一个东西不能简单用数字或文本描述，应该为类而非属性

建立Conceptual Class之间的关系

类图：类 + 类之间的关系
类是结构，结构是静态的
UML
- 类名 | 属性 | 操作
- 可见性Visibility
  - +公共可见性
  - #受保护
  - -私有
  - ~包可见
- 多重性Multiplicity
  - 描述关联
    - *无限多个
    - 1， 2， 0，正好1，2，0个
    - {1 or 2...4}离散值
  - vs
    - 基数：整个关系
    - 多重性：某一端，“从这边看过去，能连几个那边”
- 关联关系Relationship：Association
  - “一个类知道另一个类”
    - 无箭头实线：彼此都知道
      - ↑耦合性
      - 但更灵活
    - 单向实线：A知道B，A→B，订单→支付方式
      - 符合封装原则，↓耦合
      - 但导航性可能会比较麻烦，比如反向查询不方便
        
        导航性：一个类能否通过关联访问另一个类
        
        决定哪个类负责持有或访问数据
  - 需求分析阶段
  - 设计阶段
- 聚合关系Relationship：Aggregation
  - 整体-部分
  - 空菱形实线箭头，菱形在整体
- 组合关系Relationship：Composition
  - 生命周期，部分和组合一起消亡，强关联
  - 实菱形实线箭头
- 泛化关系Relationship：Generalization
  - 空心实线箭头，空心箭头在父类
  - 尽量避免用多重继承
    - 重复继承问题，“钻石问题”
  - 优化：
    - Liskov替换准则LSP
    - 继承是is a kind of关系，即子类应该能替换基类型
    - 区分：泛化 vs 聚合
      - 带滚动条的窗口
        
        带滚动条的窗口是窗口；带滚动条的窗口包含了滚动条
- 依赖关系Relationship：Dependency
  - 虚线带箭头，依赖类型<<自定义>>
- 接口
  - 一组操作的集合（不包含属性）
  - 表示方法
    - <>
    - 圆圈表示
  - 分类
    - 供给接口
      - 提供的服务
      - 圆圈
    - 需求接口
      - 需要得到的服务
      - 半圆
- 增加属性，类的属性（先）比操作（后）更重要
- 状态机图
  - 类的行为性特征
  - 分类
    - 行为状态机
      - 内部
    - 协议状态机
      - 外部
  - 核心元素
    - 初始状态：实心圆⚫
    - 终止状态：圆圈包围⚫
    - 其他状态：圆角矩形，内部显示状态名
    - 状态转移：
      - 箭头
    - 事件：状态机中事件触发迁移
      - 转移上的标号表示
    - entry-do-exit-event？
  - 为什么要用状态机图
    - 1.对象的职责或行为变化显著
    - 2.系统或对象的用例涉及复杂的逻辑，且这些逻辑由状态驱动时
    - ×：
      - 对象的逻辑简单明了，不需要额外的状态机抽象
      - 对象的行为不依赖状态变化
      - 对象单一状态
      - 总结：不存在复杂的状态变化

用例实现UCR

需求和设计之间的桥梁
用例中的每一个用力，在分析模型和设计模型中至少有一个用例实现与对应
分类
- 动态交互图
- 类图，静态视图

识别分析类

分析类：描述每个角色的职责
设计阶段：角色赋与台词和动作，变成实际的系统组件
分析类：
- 平台无关模型，与实现无关（可能做不出来）
- MVC模型-视图-控制器
  - 实体类
    - 描述存储的信息，及信息相关的行为
    - 反映逻辑数据结构
    - 实体类不是某个用力实现所特有的
    - 识别：名词过滤
  - 边界类
    - 分类
      - 用户界面类
      - 系统接口类
      - 设备接口类
    - 识别规则actor和用例之间的一条通信关联对应一个边界类，actor是什么类型对应对应的边界类
  - 控制类
    - 每一个用例一定会有一个控制类
    - 关注流程逻辑，是事件流的抽象

构建分析模型

交互图
- 顺序图/时序图

esparkl.top