架构师训练营

架构方法[week 1]

2020-09-20  本文已影响0人  架构师角色

第一周课后练习题

作业一：食堂就餐卡系统设计

请设计系统用例图，组件图，组件时序图，部署图。

系统用例图

image-20200920233755479.png

组件图

image-20200920235057879.png

组件时序图

image-20200920235215472.png

部署图

image-20200920235024630.png

第一周：学习总结

1.1 招聘JD解读

职位职责

进公司做什么？

职位要求

需要什么样的资历，什么样的背景，才能获得这个职位

项目经历是否匹配？技术广度和深度是否匹配公司当前和未来发展

可能遇到的问题

如何做好架构设计

架构设计包含： 1、业务逻辑设计，开发人员根据技术逻辑来实现 2、系统执行过程和维护设计，用于快速定位系统问题点以及方便运维维护系统 3、物理部署设计，方便运维维护以及定位系统问题点，同时能知道系统的可用性、稳定性是否有足够保障 4、场景设计，更多的是提供给产品、老板等懂业务不太懂技术的人看 5、这些设计有时候会有部分相似或一致，但是给不同的人看会有不同的效果 6、架构设计的目的是清晰业务方向以及未来维护时不至于没接触过系统的人抓瞎

1.2 常见面试题解读

掌握哪些关键技术点？

有没有自己的一系列架构方法论？

软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计

image-20200920114424211.png

架构由8个部分组成：

1、任何一个系统都有一个架构，架构由架构元素、元素间关系组成，元素间的关系有静态和动态两种关系

2、架构的落地应该有一系列的架构文档，开发工程、测试工程师、运维工程师、合作部门、老板等关注点都不一样，所以需要一系列架构文档，需要由架构文档来体现你的架构设计

3、架构文档是由一系列架构视图组成，由哪些视图来描述架构？给相关方看，相关方要有一个统一的认知

4、架构视图要将关注点表达清楚

5、不同的相关方，提供不同的架构视图，提供他们想要的信息

设计模式：里氏替换原则

设计模式：单例模式

主要解决什么问题？对于大型互联网应用有没有一个整体的认知

一致性、可用性，分区容错性是无法同时满足的，具体产品中是如何去跟CAP相关联？如何做取舍？

性能相关在第六周学习

DDD的优缺点是什么？

在微服务相关模块学习

高可用相关

大数据相关

各自的运行原理

大数据相关

推荐引擎如何实现的？

大数据相关

技术创新

技术创新

沟通是你对事务认知的规律

如何认知问题，发现问题，解决问题

培养自己的主要能力

技术基础是地基，决定技术人员的成长速度和高度

img

关于软件开发的几个事实

如何方程序员关注更少的事情？架构师能够为此做些什么？

什么是架构师？

架构师其实是一名超级整合人员，整合技术、产品、老板、客户等等人的思维，然后设计业务模型、监督落地

1.3 4+1视图模型

不同相关方，关注点不一样，需要用不同的视图模型去表达你的架构设计

要去描述我们的架构，不能单一的通过一种架构视图或者是某一个方面的架构视图，就能够完整的呈现我们的架构；而是要通过多维度的进行描述和呈现，4+1视图模型提供一种思路

软件架构

软件架构 = {元素，形式，关系/约束}

单一的视图无法完整的表达架构，因此需要具备完整的视图集

image-20200920162736809.png

逻辑视图

系统有哪些功能模块，有哪些子系统，子系统之间的一些逻辑关系

image-20200920163146780.png

功能模块图是逻辑视图的一种

过程视图

了解系统运行过程中的情况

image-20200920164419853.png
Apache的过程视图

物理视图

最终系统的物理呈现，物理部署是什么样的

物理部署视图

开发视图

与开发相关的元素，以及元素之间的关

主要指导开发过程中，开发工程师如何进行开发，如何实现系统进行落地

场景视图

            **用例图**

什么是模型？

模型是一个系统的完整抽象，人们对某个领域特定问题的求解及解决方案，对它们的理解和认识都蕴涵在这个模型中。
通常，开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程就是从领域问题到计算机系统的映射。


image-20200920171656057.png

为什么要建造模型？

我们画架构图、做架构设计，其实就是在建模，建造一个软件的模型，软件还没有代码的时候，系统还没有运行的时候，我们就通过这个模型与大家进行分析和评审，然后看这个模型本身能不能满足我们的业务需求，能不能实现我们的业务目标，能不能解决我们的领域问题，对这个模型的分析和设计对象评审，就能够看到未来的远景是什么样子的，就能够验证我们的系统未来能不能工作

建造传统模型的目的

建造软件模型的目的

何时、何处画图？

何时画图？

第一周：学习总结

1.1 招聘JD解读

职位职责

进公司做什么？

职位要求

需要什么样的资历，什么样的背景，才能获得这个职位

项目经历是否匹配？技术广度和深度是否匹配公司当前和未来发展

可能遇到的问题

如何做好架构设计

架构设计包含： 1、业务逻辑设计，开发人员根据技术逻辑来实现 2、系统执行过程和维护设计，用于快速定位系统问题点以及方便运维维护系统 3、物理部署设计，方便运维维护以及定位系统问题点，同时能知道系统的可用性、稳定性是否有足够保障 4、场景设计，更多的是提供给产品、老板等懂业务不太懂技术的人看 5、这些设计有时候会有部分相似或一致，但是给不同的人看会有不同的效果 6、架构设计的目的是清晰业务方向以及未来维护时不至于没接触过系统的人抓瞎

1.2 常见面试题解读

掌握哪些关键技术点？

有没有自己的一系列架构方法论？

软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计

image-20200920114424211.png

架构由8个部分组成：

1、任何一个系统都有一个架构，架构由架构元素、元素间关系组成，元素间的关系有静态和动态两种关系

2、架构的落地应该有一系列的架构文档，开发工程、测试工程师、运维工程师、合作部门、老板等关注点都不一样，所以需要一系列架构文档，需要由架构文档来体现你的架构设计

3、架构文档是由一系列架构视图组成，由哪些视图来描述架构？给相关方看，相关方要有一个统一的认知

4、架构视图要将关注点表达清楚

5、不同的相关方，提供不同的架构视图，提供他们想要的信息

设计模式：里氏替换原则

设计模式：单例模式

主要解决什么问题？对于大型互联网应用有没有一个整体的认知

一致性、可用性，分区容错性是无法同时满足的，具体产品中是如何去跟CAP相关联？如何做取舍？

性能相关在第六周学习

DDD的优缺点是什么？

在微服务相关模块学习

高可用相关

大数据相关

各自的运行原理

大数据相关

推荐引擎如何实现的？

大数据相关

技术创新

技术创新

沟通是你对事务认知的规律

如何认知问题，发现问题，解决问题

培养自己的主要能力

技术基础是地基，决定技术人员的成长速度和高度

img

关于软件开发的几个事实

如何方程序员关注更少的事情？架构师能够为此做些什么？

什么是架构师？

架构师其实是一名超级整合人员，整合技术、产品、老板、客户等等人的思维，然后设计业务模型、监督落地

1.3 4+1视图模型

不同相关方，关注点不一样，需要用不同的视图模型去表达你的架构设计

要去描述我们的架构，不能单一的通过一种架构视图或者是某一个方面的架构视图，就能够完整的呈现我们的架构；而是要通过多维度的进行描述和呈现，4+1视图模型提供一种思路

软件架构

软件架构 = {元素，形式，关系/约束}

单一的视图无法完整的表达架构，因此需要具备完整的视图集

image-20200920162736809.png

逻辑视图

系统有哪些功能模块，有哪些子系统，子系统之间的一些逻辑关系

image-20200920163146780.png

功能模块图是逻辑视图的一种

过程视图

了解系统运行过程中的情况

image-20200920164419853.png 
**Apache的过程视图**

## 物理视图

> 最终系统的物理呈现，物理部署是什么样的

*   相关方：系统集成商、系统运维人员

*   视角：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置

*   主要元素：物理节点以及节点的通信

  ![image-20200920164007360.png](https://img.haomeiwen.com/i5819972/0a771682f2abd59b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)


    **物理部署视图**

    ## 开发视图

    > 与开发相关的元素，以及元素之间的关系
    > 
    > 主要指导开发过程中，开发工程师如何进行开发，如何实现系统进行落地

    *   相关方：开发相关人员按，测试人员

    *   视角：系统如何开发实现

    *   主要元素：描述系统的层、分区、包、框架、系统通用服务、业务通用服务、类和接口、系统平台和相关基础框架

    *   用途：指导开发组织设计和开发实现

    ![image-20200920163715316.png](https://img.haomeiwen.com/i5819972/93779554e2e5cf07.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)


        **类图**

场景视图

什么是模型？

模型是一个系统的完整抽象，人们对某个领域特定问题的求解及解决方案，对它们的理解和认识都蕴涵在这个模型中。
通常，开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程就是从领域问题到计算机系统的映射。

          ![image-20200920171656057.png](https://img.haomeiwen.com/i5819972/06bae4550a393e76.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

为什么要建造模型？

我们画架构图、做架构设计，其实就是在建模，建造一个软件的模型，软件还没有代码的时候，系统还没有运行的时候，我们就通过这个模型与大家进行分析和评审，然后看这个模型本身能不能满足我们的业务需求，能不能实现我们的业务目标，能不能解决我们的领域问题，对这个模型的分析和设计对象评审，就能够看到未来的远景是什么样子的，就能够验证我们的系统未来能不能工作

建造传统模型的目的

建造软件模型的目的

何时、何处画图？

何时画图？

何处画图？

1.4 UML：软件架构建模的一般方法和工具

建模、画图、写设计文档

什么样的阶段，画什么样的图，表达什么样的意图

简介

ＵＭＬ的目标和价值是表达设计意图，规范不规范不重要

通过UML来做模型建设

什么是UML？

UML可用来描述

分类-静态图

通过描述类、对象和数据结构以及他们之间存在的关系，来描述软件要素中不变的逻辑结构

分类-动态图

通过描绘执行流程或者实体状态变化的方式，来展示软件实体正在执行过程中的变化过程

常用UML图

类图、用例图、组件图、部署图、时序图、活动图、状态图

通用模型元素

可以在图中使用的概念统称为模型元素。模型元素在图中用其相应的视图元（符号）表示，下图给出了常用的元素符号：类、对象、结点、包和组件等


image-20200920180350182.png

注释可以针对所有元素

模型元素与模型元素纸质件的连接关系也是模型元素，常见的关系有关联（association）、泛华（generalization）、依赖（dependency）和聚合（aggregation）。这些关系图示符号如图所示。


image-20200920180732716.png

依赖和关联都是表达两个元素、两个对象之间的关系，关联关系紧密一点，依赖关系相对来说松散一点

；一个对象的成员变量是关联关系，成员方法内的局部变量依赖于另外一个对象，那么就是依赖关系

继承我们一般说继承了一个父类，父类有自己的方法和成员变量；实现通常实现的是一个接口，接口只有方法的描述，而没有方法的实

用例建模[用例图]

用例建模技术，用于描述系统的功能需求，在宏观上给出模型的总体轮廓，通过对典型用例的分析，使开发者能够有效地了解用户的需求


image-20200920191206083.png

用例的关键角色

执行者

用例总是由执行者启动的

执行者是指用户在系统中所扮演的角色，执行者在用例图中是用类似人的图形来表示，但执行者可以是人，也可以使一个外界系统

如何确定执行者

1、谁使用系统的主要功能（主执行者）

2、谁需要从系统获得对日常工作的支持和服务

3、需要谁维护管理系统的日常运行（副执行者）

4、系统需要控制那些硬件设备

5、系统需要与其它那些系统交互

6、谁需要使用系统产生的结果（值）

image-20200920192055467.png image-20200920192156192.png

类与对象[类图、对象图]

面向对象的开发方法的基本任务是建立对象模型，是软件系统开发的基础，UML中的类图（Class Diagram ）与对象图（Object Diagram） 表达了对象模型的静态结构，能够有效地建立专业领域的计算机系统对象模型

image-20200920194818849.png image-20200920194839918.png

类图一般产生与详细设计阶段，开发人员按照类图开发，一定是符合架构师的设计的

包图

包图和组件图差不多，一般采用组件图

一个最古老的软件方法问题是：怎样将大系统拆分成小系统。解决该问题的思路之一是将许多类集合成一个更高层次的单位，形成一个高内聚、低耦合的类的集合。UML中这种分组机制叫包（Package）。引入包是为了降低系统的复杂性。

image-20200920195417334.png

动态建模

动态模型主要描述系统的动态行为和控制结构。动态行为包括系统中对象生存期内可能的状态以及事件发生时状态的转移，对象之间动态合作关系，显示对象之间的交互过程以及交互顺序，同时描述了为了满足用例要求所进行的活动以及活动间的约束关系。

在动态模型中，对象间的交互是通过对象间消息的传递来完成的，对象通过相互间的通信（消息传递）进行合作，并在其生命周期中根据通信的结果不断改变自身的状态。

动态模型

动态模型主要描述系统的动态行为和控制结构

包括四类图：状态图、活动图、时序图、合作图

UML中的消息

简单消息（simple）

image-20200920200622469.png

同步消息（synchronious）

image-20200920200720145.png

异步消息（asynchronous）

image-20200920200928351.png

时序图

用来描述对象之间动态的交互行为，着重体现对象间的消息传递的时间顺序

时序图存在两个轴

时序图中的对象用一个带有垂直虚线的矩形框表示，并标有对象名和类名。垂直虚线是对象的生命线，用于表示在某段时间内对象是存在的。

对象间的通信通过在对象的生命线之间消息来表示，消息的箭头类型指明消息的类型。

image-20200920201251589.png

对象是广义的，可以是类的对象，也可以是一个组件，也可以是一个子系统，也可以是一个服务器

时序图可以描述不同维度，系统之间的对象之间的交互

可以是对象时序图、组件时序图、系统时序图等

子系统、组件图可能存在异步消息

适用于需求分析、概要设计、详细设计三个阶段

活动图

UML中没有流程图，想要表达一些流程时可用活动图

活动图的应用非常广泛。它即可用来描述操作（类的方法）的行为，也可以描述用例和对象内部的工作过程，并可用于表示并行的过程

活动图描述了系统中各种活动的执顺序，刻化一个方法中所要进行的各项活动的执行流程

活动图中的一个活动结束后将立即进入下一个活动（状态图中的状态的变迁可能需要事件的出发）

泳道图

image-20200920203454636.png

在一个业务处理时，可能跨越多个领域时，可以泳道图描述由哪些领域协作共同完成

状态图

用来描述状态的变迁

image-20200920203915216.png

合作图

没有时序的时序图

通过时序图生成合作图

合作图，也成为协作图，用于描述相互合作的对象间的交互关系和连接（Link）关系。虽然顺序图和合作图都用来描述对象间的交互关系，但侧重点不一。顺序图着重体现交互的时间顺序，合作图则着重体现交互对象间的静态连接

image-20200920211212221.png

组件图[componet]

组件定义：系统中遵从一组接口且提供其实现的物理的、可替换的部分。对系统的物理方面建模时它是一个重要的构造块

组件可以看着包与类对应的物理代码模块，逻辑上与包、类对应，实际上是一个文件，可以有下列几种类型的构件：

组件之间的依赖关系是指结构之间在编译、连接、执行时的依赖关系。用虚线箭头表示组件图符：

image-20200920212128220.png image-20200920212326263.png

部署图

image-20200920212515995.png

不同阶段不同角色用途参考

上一篇下一篇

猜你喜欢

热点阅读