11 缓存设计

![11](https://www.ericturbo.top/static/img/60834956dffe2504df45d9c1f91438e6.image.webp)



## 3.1 版型
版型（stereotype)，是对一个UML元素基础定义的扩展，在同一个元素基础定义的基础上赋予特别的含义，使得这个元素适用于特定的场合。

* uml中每个元模型都有很多版型，例如用例有业务用例、业务用例实现等版型，类有接口、边界类、实体类、控制类等版型。
* 版型也是可以自己定义的，例如包元素有子系统、组织结构、模块等默认版型
## 3.2 参与者
建模是从寻找抽象角度开始的，那么定义人，就是定义参与者，就是我们寻找抽象角度的开始。

### 基本概念
actor是在系统之外与系统交互的某人或某事物。
> 参与者只可能存在边界之外，边界之内所有人和事物都不是参与者

要弄懂谁是参与者，首先弄懂系统边界，可以通过回答下面两个问题确定：
1. 谁对系统有着明确的目标和要求并且主动发出动作？
2. 系统是为谁服务的？

> 参与者可以非人

例如有这样一个需求：每天自动统计网页访问量，生成统计报表，并发送至管理员信箱。这个需求的参与者是谁？（计时器）

任何需求都必须至少有一个启动者，如果找不到启动者，那么可以肯定地说这不是一个功能性需求。

例如这样一个需求：`客户提出要建立的系统界面要很友好，在每个页面上都要有操作提示`。这个要求就找不到启动者，我们可以肯定他不是一个功能性需求

那它是什么呢？实际上它是补充规约中的一个要求，具体说是系统可用性的一个具体要求。


### 发现参与者
参与者的一个重要来源是涉众，从涉众中找出那些直接对系统发出动作，或者直接从系统中接收反馈的涉众。

另一个来源是客户岗位设置，为他假定一个参与者
* 列出他在系统要做的事情
* 再与另一些客户代表访谈
* 分析可以在系统中要做的事情，找出共同性

`可以询问以下问题以帮助确定参与者`：
* 谁负责提供、使用或删除信息？
* 谁将使用此功能？
* 谁对某个特定功能感兴趣？
* 在组织种的什么地方使用系统？
* 谁负责支持和维护系统？
* 系统有哪些外部资源？
* 其他还有哪些系统将需要与该系统进行交互

查找参与者时，`参与者一定是直接并且主动地向系统发出动作并获得反馈的，否则就不是参与者`
### 业务主角
业务主角是参与者的一个版型，特别用于定义业务的参与者，在需求阶段使用。


![image.png](/static/img/37d61d3cca70afc2e74e4971997a674e.image.webp)

在软件项目里，业务范围和系统范围是不同的。
* 业务范围指这个项目所涉及的所有客户业务，这些业务有没有计算机系统参与都客观存在
* 系统范围是指软件将要实现的那些对应于业务功能的系统功能，从功能性需求来说系统范围是业务范围的一个子集。但是一些系统功能会超出业务范围：操作日志

业务主角的特殊性在于，它针对的是业务任务而非计算机用户，没有抽象的计算机角色。必须在实际业务里找到对应的岗位或人员

`要建设一个符合客户需要的计算机系统，首要条件是完全彻底地搞清楚客户的业务，而不是预先假设已经有了一个计算机系统，再让客户来假想需要计算机系统帮他们做什么`

如果你对获得的业务主角不是很自信，请回答以下问题：
* 业务主角的名称是否是客户的业务术语？
* 业务主角的职责是否在客户的岗位手册里有对应的定义？
* 业务主角的业务用例是否都是客户的业务术语？
* 客户是否对业务主角能顺利理解？


### 业务工人
有些人员参与了业务，但是身份很尴尬，他是被动参与业务的，不好说他有什么具体目的，但是他又的确在业务过程中做了事情，到底要不要为这样的人建模？例如人工坐席


![image.png](/static/img/aee0b5e85037c5013cd2b5e67eb53c70.image.webp)

这种困扰是因为违背了参与者的定义：参与者必须要在边界之外。如果视图把边界内和边界外的参与了业务的人都叫做参与者而建立模型，就会出现混乱和尴尬。

那么如何区分是参与者还是业务工人呢？三个问题帮助澄清：
* 他是主动向系统发出动作的吗？
* 他有完整的业务目标吗？
* 系统是为他服务的吗？

如果是否定的，那一定是业务工人


### 参与者与涉众的关系
涉众，也称为干系人，是与要建设的这个系统有利益相关的一切人和事，涉众的利益要求会影响系统的建设。

例如一个系统的建设是由一家国际风险投资机构投资的，这个系统必然与这家投资机构有着利益关系，有时系统必须满足投资方的一些特殊要求，作为涉众，投资方的意见或许有些约束，但不会参与系统建设。

* 参与者是涉众的代表
* 参与者通过对系统提出要求来获得他说代表的涉众的利益
### 参与者与用户的关系
* 用户是系统的使用者，用户是参与者的代表，或者说是参与者的实例或代理
* 并非所有的参与者都是用户，但一个用户可以代理多个参与者

### 参与者与角色的关系
* 角色是参与者的职责，从众多参与者的职责中抽象出相同的那一部分，将其命名而形成一个角色
* 角色一般适合在概念阶段的模型里，以表达业务的逻辑理解
* 一个用户可以代理多个参与者，可以拥有多个职责，也就是可以被指定多个角色


### 参与者的核心地位
* 参与者代表涉众对系统的利益要求，并向系统提出建设要求
* 通过代理给其他用户或将自身实例化成用户来使用系统
* 参与者的职责可以用角色来归纳，用户被指定扮演哪个角色
![image.png](/static/img/349e5c6aedf34515de522cb817e807bb.image.webp)
### 检查点
统一过程的官方文档给出了一个检查点列表，回答这个检查点列表中的问题非常有助于检查发现的参与者是否正确：

![image.png](/static/img/f02ab595d0bd861bdd945e93c1c2f0f3.image.webp)

![image.png](/static/img/8ca4eac9f6619f9cffa41696887c028f.image.webp)
## 3.3 用例
用例是对对象施加这一外力的元素，正是用例使得其他哪些“孤独”的uML元素能够共同组成一篇有意义的文字。


### 基本概念
用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值

一个用例就是与参与者交互的，并且给参与者提供可观测的有意义的结果的一系列活动的集和。

![image.png](/static/img/9e08d91217a498811ee05850f8cc56db.image.webp)

用例的作用：捕捉功能性需求

一个系统的功能性是由一些对系统有愿望的参与者要做的一些事情构成的，事情完成后就达成了参与者的一个愿望，当全部参与者的所有愿望都能通过用例来达到，那么这个系统就被确定下来了。


### 用例的特征
1. 用例是相对独立的：意味着它不需要与其他用例交互而独自完成参与者的目的

![image.png](/static/img/2cba843d41896bed6eda4ff6f1b949e2.image.webp)
2. 用例的执行结果对参与者来说是可观测的和有意义的

![image.png](/static/img/f920621a87385d3283f3cbc58ee57165.image.webp)
4. 这件事必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例

![image.png](/static/img/f6905ba1cb7e9b39c302140393f943f2.image.webp)
5. 用例必然是以动宾语短语形式出现的

![image.png](/static/img/c8ed062264208144922b2b9979260d81.image.webp)
6. 一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元

![image.png](/static/img/b3f54e1f86660e360adbd303e77ce1c0.image.webp)


### 用例的粒度
* 在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜，即一个用例可以描述一项完整的业务流程。例如：取钱、报装电话，不用细到验证密码、填写申请单等业务中的一个步骤
* 在用例分析阶段，用例的粒度以每个用例能够描述一个完整的事件流为宜。`需要注意的是：这个阶段需要采用一些面向对象的方法，归纳和抽象出业务用例中的关键概念模型并为之建模`。例如，宽带业务需求中有申请包装和申请迁移地址用例，在用例分析时，可归纳和分解为提供申请资料、受理业务、现场安装等多个业务流程中使用的概念用例
* 在系统建模阶段，用例视角是针对计算机的，用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。在RUP中，项目计划要依据系统模型编写，因此另一个可参考的粒度是一个用例的开发工作量在一周左右为宜。

用例粒度的划分依据最标准的方法是以该用例是否完成了参与者的某个完整目的为依据的。`例如：某人去图书馆，查询了书目，出示了借书证，图书管理员查询了该人以前的借阅记录以确保没有未归还的书，最后借到了书`。这段话的实际用例就是借书，所有的操作都是围绕着这个展开的。

一般情况下，一个系统的业务用例定义在多于10个，少于50个之间，否则就应该考虑一下粒度选择是否合适了。


### 用例的获得
用例的来源就是参与者对系统的期望


![image.png](/static/img/981d66da2dc6b5fecc89f2c32572abb3.image.webp)

可以开始对主角，进行访谈，有以下需注意的点：
* 不要视图让业务代表为你描述整个业务流程
* 不要涉及表单填写一类的业务细节
* 你可以不关系业务规则
* 不要试图让业务代表理解将来的计算机系统如何工作

你只需要让业务代表从他自己的本职工作出发来谈谈他的期望：
* 您对系统有什么期望？
* 您打算在这个系统里做些什么事情
* 您做这件事的目的是什么？
* 您做完这件事希望有一个什么样的结果？

在这个过程中，你应当确保：
* 一个明确的有效的目标才是一个用例的来源
* 一个真实的目标应当完备地表达主角的期望
* 一个有效的目标应当在系统边界内，由主角发动，并具有明确的结果。


若需要重新访谈，你需要调整一下策略：
* 调整系统边界和主角
* 扩大或缩小系统边界
* 变更主角
* 重新开始

![image.png](/static/img/045210b9c8b62a3ab36645ad911458da.image.webp)

### 用例和功能的误区

![image.png](/static/img/45740faf523c5f1b19d17166d16c1859.image.webp)

1. 功能是脱离使用者的愿望存在的。我们常说某某工具有某个功能，他是描述工具的，而不是站在使用者的角度描述使用者愿望的。
2. 功能是孤立的，给一个输入，通过计算就有一个固定的输出——只要按下开关灯就亮
3. 如果非要从功能的角度解释用例，那么用例可以解释为一系列完成一个特定目标的“功能”的组合，针对不同的应用场景，这些“功能”体现不同的组合方式。


### 目标和步骤的误区
### 用例粒度的误区
* 分不清目标和步骤
* 在同一个需求阶段的用例粒度大小不一

![image.png](/static/img/cb24ee5ece3e9c918cb5d68c9fd15587.image.webp)

![image.png](/static/img/d0942f7af7e54e344081a263b4373307.image.webp)
### 业务用例
业务用例是用例版型的一种，专门用于需求阶段的业务建模


### 业务用例实现
### 概念用例
### 系统用例
### 用例实现

## 3.4 边界
### 边界决定视界
### 边界决定抽象层次
### 灵活使用边界

## 3.5 业务实体
### 业务实体的属性
### 业务实体的方法
### 获取业务实体

## 3.6 包
## 3.7 分析类
### 边界类
### 控制类
### 实体类
### 分析类的三高

## 3.8 设计类
### 类
### 属性
### 方法
### 可见性

## 3.9  关系
### 关联关系
### 依赖关系
### 扩展关系
### 包含关系
### 实现关系
### 精化关系
### 泛化关系
### 聚合关系
### 组合关系

## 3.10 组件
### 完备性
### 独立性
### 逻辑性
### 透明性
### 使用组件

## 3.11 节点
### 分布式应用环境
### 多设备应用环境

03 uml核心元素

![image.png](/static/img/71ce6339a55211955f17af7d176441cc.image.webp)



## 1 建模
建模（Modeling），是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，构成一种对所观察的向的内部结构和工作原理的便于理解的表达

建模包含两个问题：一个是怎么建？另一个是模是什么？

怎么建？
* 首先要决定抽象角度，即建立这个模型的目的是什么。抽象的角度不同决定了建模方向的不同
* 要弄清楚有多少业务参与者？参与者的目标是什么？

“模是什么？”，则依赖于确定了抽象角度下的场景模型

找出那些能够满足这一目标的事物。

![image.png](/static/img/922838ad697fd4d55eb539ae59e2684f.image.webp)
## 2 用例驱动

![image.png](/static/img/583961e0726c40dd426a240bf06d5af5.image.webp)

用例可以驱动的内容包括：
* 逻辑视图：系统只有一个逻辑视图，该视图以图形方式说明关键的用例实现、子系统、包和类，他们包含在构架方面具有重要意义的行为，即建模公式中的那些”人“、”事“、”物“、”规则“是如何组织的。
* 进程视图：系统只有一个进程视图，以图形方式说明了系统中进程的详细组织结构，其中包括类、子系统到进程和线程的映射，即建模公式中的人、事、物、规则是如何交互的，关系是如何的
* 部署视图：只有一个部署视图，以图形方式说明了处理活动在系统中各节点的分布，包括进程和线程的物理分布，即建模公式中的那些人、事、物、规则是如何部署在物理节点上的。
* 实施视图：
    * 是获取为实施制定的构架决策，包括：
        * 列举实施模型中的所有子系统
        * 描述子系统如何组织为层次和分层结构的构件图
        * 描述子系统间的导入依赖关系的图解

    * 实施视图用于
        * 为个人、团队或分包商分配实施工作
        * 估算要开发、修改或删除的代码数量
        * 考虑发布策略

## 3 抽象层次
抽象层次越高，具体信息越少，但是概括能力越强；反之，具体信息越丰富，结果越确定，但相应的概括能力越弱。

由于人脑对信息的处理能力是有限度的，如果信息量超过了人脑的处理能力，人就会失去对这个事物的理解能力。


![image.png](/static/img/f81c3f08f4d0d7265914f68f1c59d366.image.webp)


## 4 视图
uml里定义了用例图、对象图、类图、包图、活动图等不同的视图。这些视图从不同的方面描述了一个软件的结构和组成，所有这些视图的结合表达了一个软件的完整含义。

所以，建模的主要工作室为绘制那些表达软件含义的视图来完整地表达软件的含义。



## 5 对象分析方法

* 一切都是对象
* 对象都是独立的。对象与对象之间是天然独立的，只是在某个特定的场景下，他们的某一个特定的实例才相互联系在一起。

![image.png](/static/img/f34ae46837192a1359a3d1fbeb1a3dc7.image.webp)
* 对象都具有原子性。在同一抽象层次上，在分析过程中都应当将对象视为一个不可分割的院子。
* 对象都是可抽象的
* 对象都有层次性


![image.png](/static/img/b19c9a6e7bafa31b1aedb383b853c62d.image.webp)

02 建模基础

# 概览

![image.png](/static/img/10d0ac2c0f22a352028d19c2090d09e6.image.webp)



## 1. 面向过程还是面向对象
世界的本质是由对象组成的，平时看上去相互无关的独立对象在不同的驱动力和规则下体现出不同的运动过程，然后这些过程便展现了我们找个生动的世界。

在面向过程眼中，世界一切都不是孤立的，他们相互紧密联系在一起，缺一不可，互相影响，互相作用，并形成一个具有严格因果律的小系统；而更多的小系统组成了更大的系统，所有小系统之间的关联也是紧密和不可分割的。

### 1.1 面向过程方法
面向过程的分析方法是找到过程的起点，然后顺藤摸瓜，分析每一个部分，直至达到过程的终点。如图

`DFD图`：表达了“（从上一步）输入数据——>（在这一步）功能计算——>（向下一步）输出数据”


![image.png](/static/img/35cbb64581c8d93ae11ec61cc368b01e.image.webp)

由此发现，数据很重要。为了更好地管理数据，人们通过定义主键、外键等手段将数据之间的关系描绘出来，结构化地组织他们，利用关系理论，即数据库的三大范式来保证他们的完备性和一致性。

对关系型数据库起到了重要的促进作用，分析方法ER模型由此而生。

`但随着需求复杂、系统越来越大、功能点越来越多，经常出现一份数据被多个过程分享，经常出现矛盾的数据需求。为了解决这个问题，IBM在20世纪70年代提出了UC矩阵，来求解功能和数据之间的依赖问题。`

UC矩阵：将功能点和数据分别作为横纵坐标来组成一个二维矩阵，，在横纵坐标的每个交叉点上标记功能点对数据的需求，即U(use)和C(Create)。

标记完成后，对功能点位置和数据位置在各自坐标系上进行调整，调整的目标是尽量将C放在整个矩阵的对角线上，这时，各个功能点对数据的交叉依赖是最小的。

![image.png](/static/img/cb95d19236023fb9f51f48f8c6230479.image.webp)
最后，再把相邻的一些功能点分组，由此来获得数据交叉依赖性最小，功能最紧密的子系统。

例如，在煤炭企业管理信息系统的子系统划分案例中，通过建立U/C矩阵、进行正确性检验、求解及子系统划分，最终将系统划分为经营决策、煤炭生产、运销、财务和人事等子系统，每个子系统具有高内聚和低耦合的特点，减少了子系统之间的信息依赖，提高了管理效率和经济效益。


UC矩阵尽管是一个有用的方法，但面向过程的困难并没有从根本上解决：
* 将世界视为过程的前提是：这个过程是稳定的，所有的工作成果依赖于对这个过程的步步分析
* 并且还导致：面向过程的每一步都是预设好的，有着严谨的因果关系。

如今，SOA已经提上日程，IBM也提出了著名的口号：On-Demand Business（随需应变的商务）

### 1.2 面向过程的困难
因为构成一个系统的因素太多，要把所有可能的因素都考虑到，把所有因素的因果关系都分析清楚，再把这个过程模拟出来实在是太困难了。

我们的精力有限，计算能力有限，只能放弃对整个过程的了解，重新寻找一个方法，能够将复杂的系统转换为一个我们可以控制的小单元。

### 1.3 面向对象方法
面向对象（Object Oriented，简称OO）方法将世界看做一个个相互独立的对象，相互之间并无因果关系。只有在某个外部力量的驱动下，对象之间才会根据某种规律相处传递信息。

这些交互构成了这个生动世界的一个“过程”。在没有外力的情况下，对象则保持着静止的状态。

面向对象是多个独立的对象通过某种外力驱动的，这些独立的独享有着一些奇怪的特性：
* 封装： 对象有着坚硬的外壳，从外部来看，除了与外界交互的消息通道外，对象内部就是一个黑匣子，什么也看不到。
* 聚合：对象可以结合在一起形成新的对象，结合后的对象具有前两者特性的总和
* 继承：对象可以繁育，产下的孩子将拥有父辈全部的本领
* 接口：每个对象有多个外貌，在不同情况下可以展现不同的外貌，但本质只有一个。
* 多态：多个对象可能长着相同的脸，但同样的脸背后却是不同的对象，有着不同的行为

对象与它有着联系的身边的一小群伙伴，有这几种关系：
* 依赖：对象只知道与它有着联系的一群小伙伴
* 耦合：与小伙伴保持着信息交流的关系
* 类属性：即便在伙伴之间，每个对象也保护着自己的领地
* 方法：对象只允许其他人通过它打开的小小窗口，进行交流。

其他概念：
* 抽象：对象寻找相似性质并组成部落的过程，称为抽象
* 类：组成的部落
* 实例化：部落里每个成员既有共同的性质也有自己的个性，只有把个性赋给部落成员才能区分它们并使它们活动起来
* 复用：对象可以用于其他地方
### 1.4 面向对象的困难
* 对象是怎么被抽象出来的？为什么要这么抽象而不是那么抽象？
* 什么样的组合是最好的？什么组合是最坏的？
* 如果只给我一个对象组合，我怎么才能理解它表达了怎么样的含义呢？


![image.png](/static/img/5708d6561a8374f93d20eee0a92d9ee1.image.webp)

想要解决困难，需要：
* 一种把现实世界映射到对象世界的方法
* 一种从对象世界描述现实世界的方法
* 一种验证对象世界行为是否正确反映了现实世界的方法

UML就是来解决这些困难的
> 你今天OO了吗？


![image.png](/static/img/6eafd8a358a1687618a52f7bd5d4dba3.image.webp)
## 2. uml带来了什么？
### 2.1 什么是UML
UML是一种建模语言，UML定义了一些建立模型所需要的、表达某种特定含义的基本元素，这些元素称为：元模型，例如用例、类等。

还定义了元模型互相之间关系的规则，以及如何用这些元素和规则绘制图形以建立模型来映射现实世界，这些规则和图形称为表示法和视图(view)


### 2.2 统一语言
统一语言的意义：
* 试图用统一的语言来覆盖整个软件过程，让不同的团队操着同一个口音顺畅地沟通
* 要让人和机器都能懂
### 2.3 可视化
解决可读性的问题

### 2.4 从现实世界到业务模型
建立模型：
* 知道如何抽象现实世界。本质是人、事、物和规则组成，人为核心。uml称之为参与者，参与者是模型信息来源的提供者，也是第一驱动者。
* uml称之为：用例。用来表示驱动者的业务目标，也就是参与者想要做什么并且获得什么。而这件事怎么做的，依据什么规则，通过称之为业务场景和用例场景的UML视图来描绘的。

![image.png](/static/img/8393b28cd34271808ea4810f0c1e4766.image.webp)
### 2.5 从业务模型到概念模型
通过称之为概念化的过程 来建立适合计算机理解和实现的模型，这个模型称为：分析模型。

分析模型介于原始需求和计算机实现之间，是一种过渡模型。

绘制分析模型最主要的元模型：
1. 边界类

![image.png](/static/img/52bcb4f848592e5cc126eb66d450ff34.image.webp)

狭义上说：边界就是界面，所有对计算机的操作都要通过计界面进行

广义上说：任何实物都分为里面和外面，他们之间的交互都需要一个边界。只有两个不同职责的簇之间的交互都需要一个边界，换句话说，边界决定了外面能对里面做什么事儿？
2. 实体类

![image.png](/static/img/e03999b990e05449ccb2a8516ecf448b.image.webp)

原始需求中领域模型中的业务实体映射了现实世界中参与者完成业务目标时所涉及的事物。

这些实体类可以看做是业务实体的实例化结果
3. 控制类

![image.png](/static/img/d0faebae1611385cac1c2ce42f694cc0.image.webp)

采用控制类表述原始需求中的动态信息，即业务或用例场景中的步骤和活动。


![image.png](/static/img/37dbccf5b24c71aac844488fc9135dc0.image.webp)
### 2.6 从概念模型到设计模型
设计模型的工作就是建造零件，组装汽车的过程。

实现类可以简单地从分析类映射而来
* 概念模型的边界类可以转换为操作界面或者系统接口
* 控制类可以被转换为计算程序或控制程序，例如工作流、算法体等
* 实体类可以转换为数据表、XML文档或者其他带有持久化特征的类。

一般来说，可以遵循的规则有：
* 软件架构和框架：规定了实现类必须实现的接口、必须继承的超类、必须遵守的编程规则等。例如采用J2ee架构时，Home和Remote接口就是必需的
* 编程语言：各类编程语言有不同的特点
* 规范或中间件： 需要遵循规范或中间件规定的那必须特性


![image.png](/static/img/8445c44ad3d89ef238f74e0a80ad0f89.image.webp)

### 2.7 面向对象的困难解决了吗？

![image.png](/static/img/dfcf8e31d3028c068398f2fa2a8ed705.image.webp)

UML作为标准的面向对象建模语言，它需要再某个建模方法的知道下进行建模工作。

统一过程是这其中最为著名的额建模方法
## 3. 统一过程简介
### 3.1 RUP是什么？
RUP（Rational Unified Process）译为统一过程。

是一个采用了面向对象思想，使用UML作为软件分析设计语言，并且结合了项目管理、质量保证等许多软件工程知识综合而成的一个非常完整和庞大的软件方法。

* 定义了软件开发过程中最重要的阶段和工作（四个阶段和九个核心工作流）
* 定义了参与软件开发过程的各种角色和他们的职责
* 定义了软件生产过程中产生的工件，并提供了模板
* 最后采用了演进式软件生命周期（迭代）将工作、角色和工件串在一起，形成了统一过程。


![image.png](/static/img/5fe3209c5673b0289f56bbc78a0d3c6b.image.webp)


![image.png](/static/img/3345637dd4a19dcf0657a730b5bf6a69.image.webp)
### 3.2 RUP与UML
统一过程和UML是不同的两个领域：
* UML是一种语言，用来描述生产过程中要产生的文档
* 统一过程则是指导如何产生这些文档以及这些文档要讲述什么的方法。
### 3.3 RUP与软件工程

### 3.4 RUP与最佳实践

![image.png](/static/img/137dc94a90e1ab37b28442a3058a60e8.image.webp)
### 3.5 RUP与本书

11.1 缓存的收益和成本

概览

python 任务调度框架-APScheduler

1. 简介