目录
- 宏观上的“系统架构”
- 系统架构图(举例)
- 微观上的系统设计
- 生产者-消费者 设计图(举例)
- 宏观架构与微观设计的区别
- 孰轻孰重?
- 三种线程
- 泵的作用
- 代码中泵的作用
- 常见泵结构(1)
- 常见泵结构(2)
- 常见泵结构(3)
- 常见泵结构(4)
- 常见泵结构(5)
- 串行处理数据的泵
- 并行处理数据的泵
- 泵对于系统的意义
- 什么是框架?
- 框架的特点
- 框架的作用(1)
- 框架的作用(2)
- “机场资源调度模拟仿真系统”设计草图
- 几个问题
- 问题答案(1)
- 问题答案(2)
- 微观上看机场系统
- PPT下载
- 系统主要功能(需求分析)
- 确定系统最终使用场合
- 系统划分模块
- 各模块间怎样协作
- 每个模块技术模式(C/S(或单机)、B/S、移动app)
- 每个模块采用什么技术开发
- 出系统架构图、相关文档
- 系统框架搭建(编码)、项目组成员培训(指导)
- 系统运行的持续性(动力)
- 系统处理数据的重复性
- 系统的可扩展性(=>框架)
- 系统的容错性
- 系统的通用性(=>框架)
前者:
- 站得高看得远,将重点放在整个系统组成上。几乎不涉及到“编码”;
- 架构者需要熟悉各种技术,了解各种技术优劣以及适用场合;
- 架构者需要丰富的项目经验。
后者:
- 注重代码实现,侧重系统内部实现原理;
- 设计者需要丰富的编码经验;
- 设计者与if/else/while等打交道。
当你为了解决某个具体问题而设计一个系统时,如果做到了:
- 通用性好。不过分依赖其他模块,不限制处理特定业务;
- 容错性高。内部包含一套专门异常处理机制;
- 扩展性强。方便增加新的功能;
- 提供一套专门类库。
这时候,就可以把该系统当作一个框架。它可以用来处理某一类问题。
框架的特点- 动力性
- 持续性
- 通用性强
- 可扩展性高
- 容错性好
理论上,任何一个框架不做任何改变,直接编译即可运行。
- 整个系统怎样维持一个“持续运转“的状态?
- 服务端怎样能够持续处理客户端的输入?
- 怎样维持地图中各元素的状态?
- 系统时间怎样统一?
- 怎样维护训练脚本状态?