软件架构师的设计语言

关注
发布于: 2020 年 06 月 10 日
架构师是什么样的人﻿
做架构设计，对系统架构负责的那个人，是一个角色，而不是一个职位。
﻿
架构师最重要是需悟其中的道。在遇到困难时，解决问题的方法？ 我们需要找到问题本质，及背后原理和关系，同时还需符合更多的利益诉求。
﻿
i) 架构师之路上遇到疑惑﻿
1. 架构师 VS 全栈工程师
﻿
架构师：是一个全才型的。把握整个大型系统的设计，协调并管理相关人员，包含：项目经理，产品经理，技术经理，测试经理。
全栈工程师：是一个全能型的。一个人搞定前端/客户端，服务端，运维等相关开发工作，能完成一个简单系统的开发、测试、上线、运维工作。
﻿
2. 技术深度 VS 技术广度
﻿
技术深度：对一个领域有足够的深度，不局限于技术，也可以是运动、游戏或其他方面，体会和思考到卓越与普通的区别，这是一个架构师必须具备的。
技术广度：技术，商业最底层运行逻辑都是相通，各技术的最底层的逻辑都是相互借鉴，精通某一类技术，学习其他技术也是很简单的。当前计算机领域，底层基于三大基础组件组成：计算，存储，网络， 在这个基础上通过数据结构和算法，构建可运行的程序，再通过设计模式、编程范式构建大型应用系统。
﻿
3. 怎么提高自己，成为一名架构师
﻿
通过架构方法、模式、关键知识点进行训练，但架构一定要实践，并要关注场景
通过例子，训练架构思维、总结模式、构建知识体系
﻿
ii) 架构师的主要职责﻿
架构设计：输出设计文档
编码能力：开发核心组件和功能，框架
代码重构
系统设计
技术选型：解决技术应用中的问题，中间件/微服务/分布式应用
性能优化：了解基础知识包含：计算，存储，网络相关的知识
模块分解与微服务架构重构
保障系统安全与高可用
大数据应用
技术创新：区块链，物联网等
管理&沟通：符合更多利益诉求
...
﻿
何为软件架构﻿
是有关软件整体结构与组件的抽象描述，用于指导大型软件各个方面的设计。
﻿
﻿
一个软件系统为不同的相关方提供服务，每个相关方的关注点不同，从而形成了不同的视角，编写不同视角的架构文档。相关方包含：你的老板，产品，运营，技术，测试等。
﻿
i) 软件架构4+1视图模型﻿
软件架构用来处理软件高层次结构的设计和实施，以精心选择的形式将若干结构元素进行装配，满足系统的主要功能，性能需求，并满足其他非功能性需求，如：可靠性、可伸缩性、可移植性、可用性。可用下面公式表示：软件架构 = {元素，形式，关系/约束}
﻿
软件架构涉及到抽象、分解、组合、风格、美学。需使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定所关注的方面的集合。单一的视图无法完整的表达架构，需要具备完整的视图集。4+1 模型是通过多个视角，立体看待一个问题，具体包含：
﻿
﻿
逻辑视图(Logical View)：设计对象模型，提供功能性需求；
过程视图(Process View)：捕捉设计的并发和同步特征，提供非功能性需求，以及逻辑视图的主要抽象如何与进程结构配合；
物理视图(Physical View)：软件(过程视图)到硬件(物理视图)的映射，识别的各种元素需被映射至不同的计算机网络或处理节点上；
开发视图(Development View)：开发中软件的静态组织结构，子系统分解并组织成分层结构，每层提供良好定义的接口；
用例(Use cases)/场景(Scenarios)：用以上视图来组织，由一些用例/场景来说明;
﻿
架构师的设计语言（统一建模语言UML）﻿
模型是一个系统的完整的抽象，从一个业务的领域问题映射成 一个计算机系统问题
﻿
﻿
建造模型目标：
﻿
传统模型：为了证明某件事物能否工作，同时成本远远低于建造实物的成本
﻿
软件模型：为了与他人沟通，保存软件设计的最终成果，同时模型比代码更能说问题
﻿
UML(Unified Modeling Language) 统一建模语言：用于沟通、交流，同时用于思考、理清思路，UML符号集只是一种语言而不是一种方法学，可以在不做任何更改的情况下很容易地适应任何公司的业务运作方式。
﻿
UML模型本身概念和工具使用并不难， 难的是通过uml来表达我们的设计意图。
﻿
i) 静态图﻿
通过描述类，对象和数据结构以及他们之间存在的关系，来描述软件要素中不变的逻辑结构。
﻿
用例图（Use Case Diagrams）：系统提供的功能单元
对象图（Ojbect Diagrams）
类图（Class Diagrams）：表示不同实体如何彼此相关
组件图（Component Diagrams）：提供系统的物理视图，显示系统中软件对其他软件组件的依赖关系
包图（Package Diagrams）
部署图（Deployment Diagrams）：软件系统如何部署到硬件环境中，系统中不同的组件将在何处物理地运行，以及彼此通信
﻿
通用模型元素的关系表示
﻿
依赖： 一个元素以某种方式依赖于另一种元素
关联：更强的依赖，连接或链接模型元素/实例
实现：实现接口的契约
继承：继承父类方法实现
聚合：表示整体与部分的关系，每个部分可单独存在；并可以有不同的生命周期
组合：更强的聚合；生命周期一致，一起开始，一起结束
﻿
﻿
ii) 动态图﻿
通过描绘执行流程或实体状态变化的方式，来展示软件实体在执行过程中的变化过程。结构体状态及行为变化由状态图和活动图展现，结构体间交互行为有时序图和协作图展现。
﻿
协作图（Collaboration Diagrams）：对象间的上下文关系，没有时序的序列图
时序图（Sequence Diagrams）：显示具体用例的详细流程，流程中不同对象之间的调用关系
活动图（Activity Diagrams）：在处理某个活动时，类对象之间的过程控制流
状态图（State Diagrams）：某个对象所处的不同状态和该类的状态转换信息
﻿
UML动态图中的消息表示
﻿
简单消息：表示控制流，描述如何从一个对象传递到另一个对象
同步消息：类之间的方法调用，操作执行完并回送一个简单消息后，再继续执行
异步消息：系统之间调用，消息发送者在发送后就继续执行，不等待消息的处理
﻿
iii) 系统设计几个阶段使用UML图﻿
需求分析：用例图，时序图，活动图，状态图
概要设计：部署图，组件图，时序图，活动图
详细设计：类图，时序图，活动图，状态图
﻿