架构师都是PPT设计师吗?最值钱的编程语言是什么?架构设计只是画图吗?
问题:架构设计的产出物是什么
虽然软件研发同学自嘲码农,但是按照“本质思维”思考其实我们都是“专业人士”,专业人士指的具备专业技能并且能够通过技能解决某一领域问题的职业人士。软件的专业人士都有自己的技术工具箱,软件研发同学主要使用如下技术工具箱组装软件系统提供用户使用。
技术工具箱
架构设计的学习有一个前提,需要积累一定的专业技术工具箱。这个工具箱不仅仅是上面的软件技术,还需要了解一定的物理硬件,才能提升设计的合理性和全面性。
产出物思维
产出物思维是一种思维方式,思维方式和“指标”类似,指标有两种类型:过程性指标和结果性指标,在此不展开。产出物思维类似结果性指标,需要着重思考我们的成果是什么。
架构设计的产出物(成果)是什么呢?通过“PPT架构师”这个梗可以看出一些,设计的产出物就是PPT内的一堆图,所以某一维度上可以说架构师就是画图的,但是只说画图的不够专业,无法体现出我们的专业性。
成果导向
设计视图
架构师都是PPT设计师吗?是的,某种维度上就是PPT设计师,架构师的设计产出物更专业的术语是“视图View”。
视图View - 架构设计的表现形式一般使用“视图View”表示,视图是通过一种点、线、面的方式抽象描述一个系统切面的图形,从不同角度描述整体边界和模块关系,重点在边界。
举个例子,针对三层云计算采用三种不同的描述方式,对比展示“视图View”的设计表达方式优缺点。
1.文字描述方式
云计算采用三层架构方式,分别是IaaS/PaaS/SaaS层,每一层又分为计算/存储/网络三种资源类型,比如“IaaS层-计算资源”包括Linux/Windows等底层操作系统,“PaaS层-网络资源”包括Nginx/反向代理服务器/负载均衡等。
以上是文字版设计描述。
2.二维表方式
以上是二维表设计描述。
3.视图方式
以上是视图图形化设计描述。
以上三种方式都不用使用表格进行优劣对比,明显视图方式更具有优势,这个优势就是“边界”,图形化天然可以直观展示“上下左右中”的布局和分层模块间的边界。
回答:架构设计的产出物是视图View
模型映射方法
PPT架构师是对的,但是PPT不仅指的是MS Office中的一个工具,一般把PPT当做“演示文档”的一种简称。PPT架构师其实不是一种贬义,因为PPT是非美术专业人士能够做出“图形化”的最好的工具(还有动画效果)。
下面以一个巡逻监控机器人的业务背景举个例子,按照“模型映射方法”进行设计描述。
1.用户故事
以用户场景抽象故事
角色 | 行为 | 目的 |
---|---|---|
管理员 | 管理巡逻计划 | 管理巡逻时间路线等数据 |
管理员 | 设置巡逻计划 | 机器人按照巡逻计划执行 |
管理员 | 查看监控记录 | 查看巡逻计划执行结果 |
设备 | 获取巡逻计划 | 按计划执行监控 |
设备 | 上报监控记录 | 保存监控记录 |
2.技术故事
以技术角度抽象故事
角色 | 行为 | 目的 | 备注 |
---|---|---|---|
质量测试 | 远程查看设备日志 | 功能验证分析 | |
质量测试 | 登录密码单向加密 | 防止密码泄露 | |
网络维护 | 获取设备网络信号强度信息 | 网络质量监控 |
以上用户故事+技术故事仅作为例子使用,未充分考虑全面性,上面两类故事构成了整体需求输入,下面分别以“部署视图”和“开发视图”举例PPT视图设计。
3.开发视图
以功能/模块/子系统为基本元素设计
4.部署视图
以设备/硬件/网络为基本元素设计
按照“模型映射设计方法”,除以上几个环节外,还可以进行“领域模型”、“重点过程”的设计。除了这些重点环节外,还有“非功能性需求”设计贯穿所有环节,非功能性需求比如安全性、可靠性和可用性等约束条件。
非功能性约束
参考资料
架构师作为非美术专业人士,在视图View的设计上除了考虑技术因素,也需要考虑一些视觉和配色效果,行业中有一些比较好的方法(套路+经验)参考如下。
- C4视图 - c4model.com
- 4+1视图 - http://www.ibm.com/developerworks/cn/rational/r-4p1-view
- UML设计