架构师之路-【1】架构方法
架构方法
如何学习?
- 学习东西很重要的一点是 悟。悟性来自思维方式和知识体系。
- 收获的不只是概念,而是从知识之间的关系,找寻背后的原理,探索底层的本质。
架构师的核心输出:
- 架构方案
- PPT 套路、设计套路、技术选型
成为架构师的途径:
- 跳槽
- 内部晋升
招聘职位要求:
- 分布式系统设计和开发经验;
- 设计到实现对齐业内一流产品标准;
- 沟通、组织、团队协作能力;
- 分布式中间件深入理解;
- 领域模型、微服务架构
招聘职位描述:
- 产品调研&整体设计;
- 难点技术攻坚、核心组件服务编码;
- 定位系统瓶颈,性能,稳定性&业务扩展性;
- 主导跨部门协作和复杂功能调研,设计,协调,实施和落地;
架构方法:
- 编写架构设计文档;
- 开发编程框架;
- 重构软件代码;
- 设计系统架构;
- 进行技术选型,解决应用中的问题;
- 优化系统性能;
- 模块分解与微服务架构重构;
- 保障系统安全与高可用;
- 大数据应用;
- 技术创新;
- 沟通管理;
软件架构的理解:
- 技术之外的东西决定了你如何看技术。越做越整,而不是越做越散。
- 是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。【维基百科】
图解:
- 元素间的关系分为静态关系和动态关系;
- 整个架构中,相关方尤为重要。
对架构师的定位:
- 系统、软件都需要架构师;
- 是做架构设计,对系统架构负责的那个人;
- 是一顶帽子,不是一把椅子;是一个角色,不是一个职位。
如何练习:
- 架构方法、架构模式、关键知识点可以训练,但是架构一定要实践,一定要关注场景;
- 通过例子,总结模式,通过模式,构建知识体系。
•
软件建模与设计文档
4+1 视图模型
4+1 架构视图
软件架构 ={元素,形式,关系/约束}
单一的视图无法完整的表达架构,因此需要具备完整的视图集。
- 逻辑视图(Logical View),设计的对象模型。
- 过程视图(Process View),捕捉设计的并发和同步特征。
- 物理视图(Physical View),描述了软件到硬件的映射,反映了部署特性。
- 开发视图(Development View),描述了在开发环境中软件的静态组织结构。
- 场景视图(Scenarios),描述用例场景。
视图之间的关系:
什么是模型?
模型是一个系统的完整的抽象。人们对某个领域特定问题的求解及解决方案,对它们的理解和认识都蕴含在模型中。
通常,开放一个计算机系统是为了解决某个领域特定问题,问题的求解过程,就是从领域问题到计算机系统的映射。
为什么要建造模型?
建造传统模型的目的:
- 为了证明某件事物能否工作。
- 前提:建造模型的成本远远低于建造实物的成本。
- 造飞机
- 造高楼。
建造软件模型的目的:
- 为了与它人沟通;
- 为了保存软件设计的最终成果;
- 前提:除非模型比代码更说明问题。
何时、何处画图?
何时画图?
- 讨论、交流时
- 最终设计文档
- 只保留少量的、重要的图;
- 避免涉及过多内容和实现细节;
何处画图?
- 白板;
- 绘图工具,如:Visio、Aastah
- draw.io
UML 简介
什么是 UML?
- Unified Modeling Language,或统一建模语言;
- 以图形方式描述软件的概念;
思考:
- 为什么叫语言?反映 uml 是用来沟通交流的
UML 可用来描述:
- 某个问题领域;
- 构思中的软件设计;
- 描述已经完成的软件实现。
UML 图的分类-静态图
静态图-通过描述类、对象和数据结构以及它们之间存在的关系,来描述软件要素中不变的逻辑结构。
- 用例图(Use Case Diagrams)
- 对象图(Object Diagrams)
- 类图(Class Diagrams)
- 组件图(Component Diagrams)
- 包图(Package Diagrams)
- 部署图(Deployment Diagrams)
UML 图的分类-动态图
动态图-通过描绘执行流程或者实体状态变化的方式,来展示软件实体在执行过程中的变化过程。。
- 协作图(Collaboration Diagrams):描述相互合作对象间的交互关系,即对象间的消息连接关系。
- 序列图(Sequence Diagrams):交互图,描述对象之间的动态合作关系以及合作过程中的行为次序,常描述一个用例的行为。
- 活动图(Activity Diagrams):着重描述操作实现中完成的工作以及用例实例或对象中的活动,活动图是状态图的变种。
- 状态图(State Diagrams):描述对象,子系统,系统的生命周期。
通用模型元素
图中使用的概念统称为模型元素。模型元素在图中用其相应的视图元素(符号)表示。下图是常用的元素符号。
通用模型元素关系
模型元素与模型元素之间的连接关系也是模型元素,常见的关系有关联(association)、泛化(generalization)、依赖(dependency)和聚合(aggregation)。
关联:连接(connect)模型元素及链接(link)实例。
依赖:表示一个元素以某种方式依赖于另一种元素。
泛化:表示一般与特殊的关系,即一般元素是特殊关系的泛化。
聚合:表示整体与部分的关系。
思考:
依赖和关联的区别是:
- 关联是更强的依赖;举例:依赖是局部变量,关联是成员变量
聚合和组合的区别是:
- 组合:生命周期一致;汽车,车轮,方向盘,拆解后组件无意义;整体消亡,组成部分消亡。
用例建模
描述系统的功能需求。在宏观上给出模型的总体轮廓。
描述执行者和用例之间的关系。
主要元素:用例和执行者及其它们之间的联系。
创建用例模型的工作包括:
- 定义系统;
- 确定执行者和用例;
- 描述用例;
- 定义用例间的关系;
- 确认模型;
执行者(Actor):可以是人,也可以是一个外界系统。
注意:用例总是由执行者启动的。
大白话:系统供什么样的人使用,功能之间的关系是什么?
举例:
用例之间的关系:使用 and 扩展,是两种不同形式的泛化关系。
- use 表示一个用例使用另一个用例;
- extend 通过向被扩展的用例添加动作来扩展用例。
静态建模
任何建模语言都以静态建模机制为基础,标准建模语言 UML 也不例外。静态建模是指对象之间通过属性互相联系,而这些关系不随时间而转移。
动态建模
动态建模主要描述系统的动态行为和控制结构。
动态行为包括系统中对象生存期内可能的状态以及事件发生时状态的转移,对象之间动态合作关系,显示对象之间的交互过程以及交互顺序,同时描述了为满足用例要求所进行的活动以及活动间的约束关系。
动态模型中,对象间交互通过对象间消息的传递完成。
UML 中的消息
- 简单消息:描述对象的传递,不描述通信细节;
- 同步消息:等待;
- 异步消息:不等的消息的处理;
时序图
两个轴:
- 水平轴表示一组对象;
- 垂直轴表示时间;
垂直虚线是对象的生命线,用于表示在某段时间内对象是存在的。
对象间的通信通过在对象的生命线之间消息来表示,消息的箭头类型指明消息的类型。
活动图
即可用来描述操作(类的方法)的行为,也可以描述用例和对象内部的工作过程,并可用于表示并行过程。
活动图的模型元素
构成活动图的模型元素有:活动、转移、对象、信号、泳道等。
泳道:
- 描述完成活动的对象,并聚合一组活动。
- 描述采取何种动作,做什么(对象状态改变),何时发生(动作序列),以及在何处发生(泳道)。
实现模型
实现模型描述系统实现时的一些特性,又称为物理体系结构建模。包括源代码的静态结构和运行时刻的实现结构。
实现模型包括:
- 组件图
- 部署图
状态图
描述一个特定对象所有可能的状态及其引起状态转移的事件。
单初态,多终态。
编程的本质与未来
要明确的自己的想法和目标,不能被老板或者业务推动;
已有的开源软件进行反设计;破局;
编程语言的实质
编程目的:
- 用计算机解决现实世界的问题
编程过程:
- 在计算机所能理解的模型(解空间)和现实世界(问题空间)之间,建立一种联系。
编程语言是一种抽象的机制,问题是对谁来抽象:
问题领域:
- 包含与系统所要解决的问题相关的实物和概念的空间。
抽象的种类:
- 机器代码和汇编语言
- 对基础机器进行抽象
- 非结构化的高级语言(如Basic、Fortran)
- 对计算处理逻辑抽象
- 结构化的程序设计
- 开始对问题领域进行一定程度的抽象
- 面向对象的程序设计
- 直接表达问题空间内的元素
编程方法的演进:
- 汇编语言
- 高级语言
- 结构化程序
- OOP
编程的核心要素(参考马克思的生产关系三要素)
- 计算机(劳动工具)
- 人(劳动者)
- 客观业务领域(劳动对象)
软件开发的历史即围绕着三个要素发展,大致经历三个阶段:
- 由以计算机为核心的汇编语言;
- 以人为核心的,能让人阅读和理解的高级语言和结构化语言;
- 以客观业务领域为核心的面向对象编程。
OOP 能更真实地反映我们需要解决的问题领域,也能对问题进行更好地抽象。
什么是面向对象编程
smalltalk 描述
- 万物皆对象
- 程序是对象集合,通过发消息告知彼此所要做的
- 每个对象由其他对象构成存储
- 每个对象都有其类型
- 某一特定类型的所有对象都可以接收同样的消息。
什么是对象
对象具有状态、行为和标识
- 状态:表明每个对象可以有自己的数据
- 行为:表明每个对象可以产生行为
- 标签:表明每个对象都区别于其它的对象(唯一的地址)
面向对象编程的三要素
- 封装性-隐藏实现
- 继承性-接口的重用
- 多态性-对象互换的魔法