0%
报错小仓库(持续更新)
发表于:
分类于:
大二
(venv) D:\administrator\College\课后笔记\SE-软工\newsAPI_project>vue ui
(node:23504) [DEP0040] DeprecationWarning: The punycode module is deprecated. Please use a userland alternative instead.
(Use node --trace-deprecation ... to show where the warning was created)
报错小仓库(持续更新)
发表于:
分类于:
大二
Django后端项目模仿
发表于:
在指定目录方便用管理员权限打开命令黑窗
发表于:
- 将以下代码复制到一个文本文件,然后保存成 cmd.reg,注意文件后缀是reg,注册表文件。
| |
- 哪天你不想要这个新加的选项了,请把下面的代码复制,同样保存到一个文本文件然后存为remove.reg,双击运行之。选项就会消失,菜单恢复正常。
| |
概率论-第二章复习
发表于:
分类于:
概率论/复习
第二章复习
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 随机变量函数的分布
一、随机变量的函数
二、离散型随机变量函数的分布
三、连续性随机变量函数的分布
软件工程思路笔记
发表于:
分类于:
软件工程
tags: [TOC]
需求工程
用例规约
1. 画出Use Case
2. 编写用例规约
1. 可选需求
2. 非功能需求
3. 黑盒用例规约 和 白盒用例规约
- 随着开发的过程要不断添加细节
- 1.识别用例:有哪些时间、actor
- 2.用例分布提纲:+前置条件 +后置条件
- 3.(非技术甲方)黑盒规约:+完整的事件流
- 4.(技术人员)白盒规约:+系统内部行为的细节描述
- 可以采用双列(用户视图 | 系统视图)
3. 用例图优化
- 符号:
- Include包含

- 从基本用例→包含用例,包含用例为基本用例提供功能
- <>衍型
- Extend扩展

- Generalization泛化(类似类中的继承关系)

- Include包含
- 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是什么类型对应对应的边界类
- 分类
- 控制类
- 每一个用例一定会有一个控制类
- 关注流程逻辑,是事件流的抽象
- 实体类
构建分析模型
- 交互图
顺序图/时序图





