软件系统可以按如下分层
- Iass: 基础设施软件，包括操作系统(网络，存储，计算)，虚拟机，Docker等基础软件。
- Paas 平台即服务: 包括我们日常的消息，缓存，数据库，等中间件。也应该包括框架和 类库。例如ioc，orm，rpc框架; 图片，特殊文件处理的第三方类库等
- Saas 软件即服务: 我们日常的一些应用，无论是2B，2C都属于此。
用例图
用例图是最清晰，最容易理解的图表，用例图从用户角度出发
要素
- 如何使用我们的系统。如果系统已经完成，可以使用简洁版本的 用户使用手册代替。
- 有哪几种使用流程，哪些应用场景。
- 每种流程需要做哪些事情。
用例图首先需要分析系统有哪些使用人员，可以借助以下问题分析
- 谁将使用该系统的主要功能。
- 谁 将需要该系统的支持以完成其工作。
- 谁将需要维护、管理该系统，以及保持该系统处于工作状态。
用例图因为其简单直白，容易被系统设计者忽略，实际上 对于一个完全未接触系统的人，用例图是最友好，最直白的，可以让小白 快速的了解我们的系统 给哪些人提供了哪些功能。功能之间的联系是什么
用例规约
用例规约是对用例的详细描述，一般包括简要说明、主事件流、备选事件流、前置条件、后置条件和优先级等
用例规约既关注主事件流所描述的成功场景，也关注备选事件流所描述的异常场景，有利于促进系统化思维、发现异常场景、完善系统功能和提高易用性；
后置条件应覆盖所有可能的用例结束后的状态。即后置条件不仅仅是用例成功结束后的状态，还应该包含用例因发生错误而结束后的状态
数据模型图
程序=数据结构+算法，软件程序就是对输入数据进行处理，按照一定的算法，输出特定的数据。 数据是程序的核心，也是容易变化的部分，例如最常见的变化: 需要增减字段。
此时需要对数据进行建模，梳理模型之间的关联关系，为的是把关系最紧密的数据 放到一个模型里，独立扩展。 数据模型图描述了 模型之间的关联关系，每个模型有哪些字段 。 三要素 ● 模型 ● 属性 ● 模型间关联关系
数据模型图包括 E-R图，数据库实体图。等。
- E-R图使用中文，不涉及表结构，更简单。
- 数据库模型层: 描述数据库层面的关联关系和表设计， 虽然比ER图更复杂， 但是更全面，适用人群都可以看懂。
- 大多数情况下 我们的设计文档是给产品和研发，技术管理者看的。使用数据库实体图也可以看懂。(看不懂的让他去学)
个人认为设计文档里可以忽略E-R图，直接上数据库实体图。但是这就要求数据库实体图 有充分的文字说明，例如属性注释，关联关系说明等。
设计文档基本原则
设计文档的编写 应该遵循以下基本原则
- 文档是给人看的。 要给目标读者 讲的足够透彻，每个读者的视角都要考虑到
- 可落地。要求文档具备足够的设计细节，能准确预判技术难点，对于技术难点提出明确的解决方案（要覆盖关键需求和流程）
- 一个架构图只需要描述清楚 一个视图即可。追求大而全的架构图只会让人看不懂，自己也无法再修改。(职责尽量单一)
