模块化设计 20240448

• 模块不包含数据，通过实例的指针，实现对实例的操作；
• 唯一包含的数据是用于管理这些模块的侵入式链表
• 模块只负责更具定义的数据结构，执行对应的逻辑，实现不同实例的功能；

参考资料

• 使用模块时，必须专注于模块的使用，而必须有意忽视模块的实现逻辑，必须要在心理上信任模块。简而言之，必须把模块视作黑盒子！

“Service模型”

• 模块的头文件，接口头文件遵循“最小信息公开原则”，即，该头文件中只存放用户使用模块最少最少所必须知道的信息。
• 类型定义、宏定义、函数和全局变量声明都应该首先放置在对应的源代码中（或是后面会提到的模块内私有的接口头文件中）；当且仅当我们发现用户要使用模块的某一功能必须要用到某一信息时，才“极不情愿”地、“抠门”的、且尽可能将其它能剥离和隐藏的信息剥离开后，放置到接口头文件中。
• 每一个模块内部都会有一个专门的头文件用于实现对模块的配置：该头文件用于“从模块外部向模块内部”输入配置信息；app_cfg.h
  
• 多个C源文件之间需要共享一些非公开的私有信息:双下划线为前缀的接口头文件（比如，叫做__common.h），并视其为模块的私有财产。

• 模块的嵌套，父模块的接口头文件包含子模块的接口头文件

层次模块

• 模块的内部不仅对外是不可见的，本质上也不依赖于模块的外部环境；
• 模块自成一体（队列、内存池、加密模块、数据校验模块），平时用起来就好比是平铺在桌面上的积木一样——它们平起平坐，缺乏立体的层次关系。
• 另外一类模块，他们本身需要由众多的子模块拼接而成——这里的拼接可不是简单的平面拼接——它需要一个层次关系

设备的故障如何分级

第一章

面向对象

• 文件充当封装边界
• UML中的继承 ，使用封闭箭头表示，
• 状态机，在状态中等待，指导发生某个事件；
• 同步事件，发送者等待事件被处理的结果；

第二章

设计模式

• 设计模式是对经常出现的问题的通解；
• 位域的问题：编译器的字节不固定，是否是原子操作；标量的位域强制转换；

硬件代理

硬件适配器

中介者模式

观察者模式 发布-订阅

去抖模式

中断模式

轮训模式

第三章 资源并发

• 顺序动作的例子

循环执行模式

静态优先级模式## 临界区模式

收尾调用模式

队列模式

#############################

UML

类

• 对象的“包含”关系，表明他们是“共生死”，一起构建，一起析构；
• 组合/部分 关系 APO (a part of) --实心菱形，是“共生死”
• 包含/内容/共享 关系 — 空心菱形
• 从领域概念找到类：概念–概念之间的联系

用例-行为需求

• 用例表达了系统提供用户（actor）的服务，一个用例表达一个服务
• 用例在系统的众多"系统功能"中，属于直接提供用户服务的部分（具有用户感知的功能）,其他功能只是用户感知不到；
• 用例类的实例化是一种场景（scenario）；一般类的实例化是对象；
• 用例描述该服务的名称以及返回的信息类型，解释“是什么”
• 用例描述服务过程中，用户与系统之间“如何”交互；
• 用例描述用户的角色，“是谁”
• 用例关系：“包含”-一个用例包含了“包含用例”；“扩展”-一个基础用例会在一定条件下触发“扩展用例”