我以往做复杂点的系统设计，通常是分为需求和设计两部分梳理：
1、需求

1.1、采用usecase图，来识别并描述业务场景； 1.2、将整个系统视为黑盒，识别周围与其交互的actor，用时序图描述系统与周边的交互；

2、设计

2.1 逻辑架构，用你画的类似线框图就可以，主要是从逻辑功能层面分出不同的子系统，以及子系统中的各个功能模块，这里同一个子系统中的功能模块通常是分层的。 2.2 物理架构，这里主要是表述你软件的部署方式，比如几台应用服务器、文件服务器、缓存服务器、数据库服务器等等，逻辑架构中的子系统是如何部署在不同的硬件设备上。当然，如果是自己在机房中搭建的话，网络、安全设备之前我也放在这里定义。 2.3 技术架构，其实就是你所选择的技术栈，包括服务器、数据库、web服务器、语言、中间件等等； 备注：如果存在几个独立的子系统，比如某些项目中包含商城、仓储两个大的子系统需要对接，那么基于逻辑架构中的划分，可以再画一些时序图，这里的时序图用以清晰描述子系统之间的接口和交互流程。后续可以指导输出子系统的接口文档。

3、其他

部分像可维护类的、运营类的、可靠性的需求和设计，不一定能在上述设计中描述的，你用文字单独罗列也可以。其实图只是一种辅助工具，能清晰表述，大家都能看懂就好：），因为文档一般是给上下游的其他人看的。

框架图的作用是: 让你能理清整个项目的思路，从全局俯瞰整个架构，做到胸有成足。

因此，图的规范并不重要。哪怕你是用你灵魂画师的画风画在草稿纸上也无可厚非，只要能帮你理清思路即可。