原文地址
文章中内容:
讲解画图的方法论,有哪些视图(4+1),推荐的画图方法(C4模型:主要针对软件架构师和开发人员),同时分享了"三画"他们公司数据工具的案例,同时文章尾部分享了一些画图工具
- Keynote
- Xmind
- EdrawMax
- Visio
- OmniGraffle
- Process On
学习到的地方:
画图是为了和别人更好的讲解和交流,受众有没有准确的接受到想要传递的信息,有时候会被外面的条条框框被约束着,比如(虚线,实线)在不需要解释和的前提下可以直接看懂,对应的 管理人员,产品,运维,开发,测试,项目经理,项目的归档,
现在的市面上使用的(4+1):场景视图、逻辑视图、物理视图、处理流程视图和开发视图
系统的参与者和功能用例的关系,讲需求和设计,正常使用的由用例图来进行表示的.
(开发):功能拆解后的组件关系,组件约束和边界,可以直观的看到整体的组成和构建(UML/类图)
物理视图.png
系统软件到硬件的映射关系,反映出系统的组件的节点是如何部署的,涉及(中间件层,数据库,NoSql,Mysql,Mq,Zk,E-job,ng,cdn,大数据,防火墙,网卡,ip库)
处理流程视图.png
软件组件之间的通信时序,数据的输入输出,功能流程和数据的输入和输出,数据的处理,(时序图/流程图)
描述系统的模块和组成,内部包的组成开发时候的实施过程
C4模型:官网
[语境图]
(System Context Diagram)
受众:比较广,技术和非技术都可以看懂的
内容有:
- 构建的系统是什么,可以直观的理解
- 谁会使用他
- 如何和现在的系统打通和融合
- 哪些是先有的能力,还有待开发的内容
[容器图] (Container Diagram)
待开发的内容进行完善,展开来进行讲解,(名称、技术选择、职责,以及这些框图之间的交互)
- 系统的整体形态
- 技术决策
- 职责是如何分布和交互的
- 在哪里写代码,哪写api需要提供和完善
[组件图] (Component Diagram)
受众人员;内部人员
- 组件/服务 组成
- 关系和依赖
- 系统的分解提供架构图
[类图] (Code/Class Diagram)
受众人员;内部人员,项目文档
类和类的关系,字段
- 显示系统中分类器的静态结构
- 该图提供了UML规定的其他结构图的基本表示法
- 业务分析师可以使用类图来从业务角度对系统进行建模
可以落地的:
在开发中我们正常的是在画 类图或者流程图,偶尔是UML图,开发对开发的是没有问题的,但是和运维,PM,产品讲解我们系统(平台),只能从新画一个草图,沟通效率也慢,当文中的 物理视图给我
画图的工具有:
- Keynote
- Xmind
- EdrawMax
- Visio
- OmniGraffle
- Process On
文中物理视图 Download 地址:
- Win:t.cn/EXAGBDW
- Mac:t.cn/EXAqtxI
总结
不忘记初心,画图的目的是为了什么,对应的受众人.C4模型的使用不同的图对应的不同受众者,多练习和实践
近期评论