【架构师第一周】总结

发布于: 2020 年 06 月 10 日

一、架构方法

关键词

  • 悟性

  • 要追问为什么要这么做

  • 从不懂到懂的路径

  • 架构是给人做的,最重要的是要搞清楚相关方

  • 做架构的人就是架构师,不一定非要有title

 

面试小技巧小捷径

对过往经验、项目重新设计,并不一定经过验证和实践,但是可以用来优化简历,通过面试相当于让对方不断的review,不断的充实直到能落地

面试别人的技巧

1、自我介绍

2、找一个你认为最有技术含量的项目,详细说一下

  • 强调背景,解决了哪些问题,然后提出使用的技术方案。

  • 有条理的画出时序图,流程图,架构图。

  • 面试官提出建议,为什么不这么做?如果你能否掉的话,是能加分的。

3、如果上面的问题回答的很好,很有条理,那就开始问一些技术细节,基础知识

4、最后手写10行以内的代码

二、软件建模与设计文档

关键点

重要的不是怎么把图画好,首要任务是要搞清楚你的图是给谁看,针对不同的相关方需要输出不同的架构图。

4+1视图模型

重点:一个系统是由不同的视图、不同的层面、不同的方向组织起来的,当给不同的相关方看的时候,需要呈现的内容也是不同的

  1. 逻辑视图

相关方:关注的是功能模块逻辑关系

  1. 开发视图

相关方:开发、测试人员

主要元素:架构分层、分区、包、框架、服务、类、接口

  1. 物理视图:

相关方:运维、系统集成

主要呈现服务器部署关系、网络等

  1. 过程视图:

相关方:开发、系统集成

  1. 场景视图

UML软件建模

重点:不在于图怎么画,而在于用UML图表达什么样的设计意图,给什么样的人看。重点关注:用UML在什么情况下,使用什么UML模型,去达成什么样的设计意图。

什么是UML

  • 什么是模型?模型是一个系统的完整抽象,关键词:抽象

  • UML统一建模语言,它是一种交流和沟通的工具

  • 一张图不要包含太多的东西,如果需要表达的东西很多,可以用多张图表达,图之间设置好边界,逐步展开,向下扩展。

  • 需求设计分为三个阶段

  • 需求分析

  • 概要设计

  • 详细设计

静态图

静态关系:依赖、关联(关联耦合性强于依赖)、继承、实现、聚合(可分割)、组合(元素有相同的生命周期)

  • 用例图

  • 描述系统的功能需求,宏观上描述系统的总体轮廓。主要描述系统有哪些功能,功能供什么人使用,功能之间的关系是什么

  • 对象图

  • 类图

  • 组件图

  • 架构设计最重要的一个图

  • 组件图用来描述模块组件,依赖关系。也可以描述人员的关系

  • 一个组件通常细化到可以由一个人开发的粒度,一个物理组件可以是一个jar包,一个jar包也可以分成若干个逻辑组件。

  • 组件可以用来把控开发进度

  • 开发时长

  • 开发依赖关系,优先级

  • 工作分派,复杂组件分配给经验更丰富的开发人员

  • 包图

  • 部署图

  • 架构设计的第一张图,概要设计阶段

动态图

动态关系:三种消息,简单消息、同步消息、异步消息。对象之间的消息是同步消息,方法调用就是对象之间的消息,A调用B就是A给B发了消息。

  • 协作图,可以用时序图自动生成

  • 序列图(时序图)

  • 在所有阶段都可以用

  • 系统之间的依赖关系、调用关系

  • 组件、类之间的调用关系

  • 活动图

  • 在所有阶段都可以用

  • 关键的处理流程

  • 状态图

  • 在需求分析阶段、详细设计阶段使用

 

架构设计文档

重点:自上而下,逐渐细化

项目背景

1.1 设计概述

1.2 功能概述

1.3 非功能约束

预期单量、用户数、日pv等等

 

概要设计阶段

2.1 系统部署图

2.2 重要场景子系统的时序图等

…….

2.n 重要场景子系统的活动图等

 

3.1 组件图

组件的关系

3.1.1 某场景的组件时序图

3.1.2 某场景的组件活动图

3.1.3 某场景的组件状态图

 

详细设计阶段

3.2.1 类的时序图

3.2.2 类的活动图(方法的活动图)

3.2.3 类的状态图,状态的枚举值,状态之间变化的布尔值

用户头像

浪浪

关注

还未添加个人签名 2020.04.28 加入

还未添加个人简介

评论

发布
暂无评论
【架构师第一周】总结