以下我们将重点分析借助哪些图表工具可以分析应用软件系统(Saas层)。这些图表的阅读者应该是开发者，产品经理，业务架构师，系统架构师，技术管理者等。
用例图是最清晰，最容易理解的图表，用例图从用户角度出发
用例图首先需要分析系统有哪些使用人员，可以借助以下问题分析
用例图因为其简单直白，容易被系统设计者忽略，实际上对于一个完全未接触系统的人，用例图是最友好，最直白的，可以让小白快速的了解我们的系统给哪些人提供了哪些功能。功能之间的联系是什么
用例规约是对用例的详细描述，一般包括简要说明、主事件流、备选事件流、前置条件、后置条件和优先级等。
后置条件应覆盖所有可能的用例结束后的状态。即后置条件不仅仅是用例成功结束后的状态，还应该包含用例因发生错误而结束后的状态。
用例图和系统页面如果有更详细的使用手册，则可以更快速的全面理解系统的功能。例如展示一下我们的系统页面。更加直观和清晰。
只有更好的了解系统提供了哪些功能，有哪几种角色，才能理解系统为什么这么设计某些人之所以会觉得用例图多此一举，是因为其对系统本身足够了解。但是他们忽略其他人对系统还是完全一片陌生。需要借助用例图，最直白的了解系统
程序=数据结构+算法，软件程序就是对输入数据进行处理，按照一定的算法，输出特定的数据。数据是程序的核心，也是容易变化的部分，例如最常见的变化:需要增减字段。
此时需要对数据进行建模，梳理模型之间的关联关系，为的是把关系最紧密的数据放到一个模型里，独立扩展。数据模型图描述了模型之间的关联关系，每个模型有哪些字段。三要素●模型●属性●模型间关联关系
数据模型图包括E-R图，数据库实体图。等。
个人认为设计文档里可以忽略E-R图，直接上数据库实体图。但是这就要求数据库实体图有充分的文字说明，例如属性注释，关联关系说明等。
数据库ER图，实体图或者领域模型图的设计非常考验设计经验。需要领域专家根据用例图，用例流程图，反复的需求沟通。不断地推敲以下问题
数据库ER图的分析过程可以使用DDD等设计方法。
以营销系统为例，分为管理流程和用户流程
一般使用方框表示组件，连线表示调用方法，动作或者数据。
按照组件思维设计流程图。要求把系统的组件先抽象出来，每个组件处理哪个步骤。淡化了输入输出，是简化版的调用时序图。(时序图描述方法调用层次，更加细化和清晰。)
以下示例是dubboProvider端暴露一个服务的组件调用的控制流变化图
高可靠高可用性能瓶颈，流程图中可以介绍核心读写流程的高可用，高可靠设计;即数据可靠性如何保证，系统可用性如何保证。性能瓶颈在流程中哪个节点。如何优化等
以下仅供参考
可以看到时序图精确到某个类调用了某个类的某个方法，把方法的调用嵌套的深度和层次都能展现出来。配合重要的关键节点注释，可以让读者即使不读代码也可以看到整体的方法调用体系。通过时序图我们可以得到
类图描述了类和类之间的依赖关系（组合，继承，接口）
类图的箭头关系描述了两个类之间是否依赖，集成/组合/接口实现。
例如一个接口只有一个实现类，没有复杂继承关系基本上不用写类图。
类似于Spring等极为复杂的框架，为了实现最大程度的复用和可扩展性。使用了大量的继承、接口实现类提高高扩展性和可复用性。这个时候如果没有类图，根本无法全面的了解一个接口，一个类的继承体系。不清楚某个类在继承体系中的位置。
一般情况下只有流程图和时序图里面能具体精确到某个类。当读者在流程图、时序图里经常看到某个几个类，就会疑问，这几个类有什么关联关系呢？
此时可以择机是否需要梳理一个类图展示依赖关系。
系统架构图为了描述应用内部的组件，模块等。一般情况下分为全系统架构图，单应用架构图
例如CouponJob服务负责发券，上层会有各种形式的发券活动关联该服务。兑换码，领券页面领券等等都依赖CouponJob发券服务能力。
应用间依赖关系最理想的情况是单方向依赖，如果上下游的两个服务存在明显的循环依赖，此时需要考虑，两个系统是否耦合严重，两个系统是否实现了类似的功能呢是否需要合并为一个服务呢
是否可以把关联性很强的业务模块放到一个服务里比较合适呢
应用架构重在描述应用之间的依赖关系，以及应用所处在系统的位置。是上层应用还是底层应用设计应用架构图时不建议把应用内的模块划分也囊括在应用架构图中，这样会导致架构图过于庞大，不利于理解
一个架构图只需要描述清楚一个视图即可。(职责尽量单一)
可以从表中看到
部署架构图重在描述应用在线上部署的情况
以下部署架构描述了应用在容器上部署，用户请求经过SLB负载均衡。静态资源访问，数据库服务部署在RDS。
以下场景需要梳理全链路上下游依赖图
梳理后可能发现需要对接口进行鉴权，防止任意调用方可以调用我们的服务。至少可以让我们感知到接口被调用，防止大流量，不合理的业务场景进行调用。也方便我们日后升级。