1       Week1:架构方法：架构师如何做架构；

1、架构师职责；

2、架构师面试；

3、架构概论；

4、4+1视图模型；

5、软件建模语言；

6、软件设计文档；

7、案例：我如何利用UML成为软件架构师？

1.1       什么是软件架构

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

每一个系统都有各自的架构，架构由元素以及元素之间的关系组成，在设计阶段，软件架构需要使用架构文档来表达设计的内容，架构文档需要根据不同的相关方所关注的内容全身提供不同的文字说明，以及架构视图。







两图的区别

1、 架构元素和元素间关系聚合成架构，所以之间的软线使用是组合的箭头；

2、 架构图与架构文档之间也是使用的组合的箭头。

聚合：表示整体与部分的关系，聚合后的才是一个完事的，一旦分开，各元素之间就没有作用了，比如一个动物有各种身体部分组成，一旦分开就没用了。

组合：表示依赖条件组合到一起，分开后仍然有用，比如一车辆车，分开之后有些部分还是可以继续使用的。

架构师的职责：软件做大，如何持续发展，让程序员更少的关注事情，架构师让程序员不用关注太多的技术细节，只用来实现代码。

1.2       4+1架构

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

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

1.2.1       4+1架构的关系图





1.2.2        逻辑视图（Logical View）：设计的对象模型

相关方：客户、用户、开发组织管理者

视角：系统的功能元素，以及它们的接口，职责，交互

主要元素：系统，子系统，功能模块，子功能模块，接口。

用途：开发组织划分，成本/进度的评估。

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

1.2.3        开发视图（Development View）：描述了在开发环境中软件静态组织结构，也就是如何开发落地

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

视角：系统如何开发实现

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

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

1.2.4        过程视图（Process View）:捕捉设计的并发和同步特征

相关方：性能优化，开发相关人员

视角：系统运行时的线程，进程的情况

主要元素：系统进程，线程以及处理队列等。

1.2.5        物理视图（Physical View）：描述了软件到硬件的映射，反映了部署特性，也就是最终系统开发出来是什么样的。

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

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

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

1.2.6        场景视图（Scenarios View）：描述用例场景，即运行场景是什么样的

相关者：用户，设计和开发人员。

视角：概括了架构上最重要的场景（最典型或者最有风险）及其非功能性需求，通过这些场景的实现，阐明了架构的广度或众多架构元素运行的方式。

1.3        UML：统一建模工具

UML有什么用：UML建模的方式进行设计架构；

什么是模型：一个系统的完整的抽象，如将业务点，关键关系抽象出来；

什么是UML：Unified Modeling Language，统一建模语言，用图形方式描述软件的概念。

为什么要有设计：通过使用UML工具，来设计系统。如果业务没有理清楚，然后去开发一个不知道要干什么的系统，最终将会朝完全未知的方向走，完全不知道要做什么。

1.3.1        UML作用

某个问题领域；

构思中的软件设计；

描述已经完成的软件实现。





领域问题->经过分析、抽取->形成概念模型（领域模型、设计模型）->提取->系统需求->再经过分析、设计->最终形成解决方案

何时、何处画图

讨论、交流时

最终设计文档

只保留少量的、重要的图

避免涉及过多内容和实现细节

1.3.2       视图的分类

软件架构要用多个视图进行表达的，

静态图：用例图（Use Case Diagrams）、对象图（Object Diagrams）、类图（Class Diagrams）、组件图（Component Diagrams）、包图（Package Diagrams）、部署图（Deployment Diagrams）

动态图：协作图（Collaboration Diagrams）、序列图（Sequence Diagrams）、活动图（Activity Diagrams）、状态图（State Diagrams）

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

不常用：包图，协作图、对象图

各种视图可以描述的关系：

1、 描述静态关系：依赖（表示一个元素以某种方式依赖于另一种元素）、继承、实现、关联（连接connect模型元素及链接link实例）、聚合（表示整体与部分的关系）、组合

2、 描述动态关系：

继承：如继承了一个父类，实现：如实现了某一个接口。

用例模型：用例建模技术是需求分析阶段的主要表示模型

方框为用例的边界

软件开发三个阶段：需求分析、概要设计、详细设计

类图与对象图

类图：由一个个的类组成的，详细设计阶段要用的UML图。包括类名、方法名都有，目的是为了方法落地，代码实现。

包图：包图一般为组件一级别的，一般画包图。

1.3.3       UML中的消息分类

简单消息（simple）:表示控制流，描述控制如何从一个对象 传递到另一个对象，但不描述通信的细节。

同步消息（synchronous）：是一种嵌套的控制流，用操作调用实现。操作的执行者要到消息相应操作执行完并回送一个简单消息后，再继续执行。

异步消息（asynchronous）：是一种异步的控制流，消息的发送者在消息发送后就继续执行，不等待消息的处理。

面向对象编程语言：一般是同步消息。

1.3.4       部署图

是系统最大的一张蓝图，是概要设计的最重要的图，是系统开发完成后，最终的部署架构。

1.3.5       时序图（Sequence Diagra）

定义：用来描述对象之间动态的交互行为，着重体现 对象间消息传递的时间顺序。时序图可以在所有阶段（需求、概要、详设）使用

时序图存在两个轴：

       水平轴表示一组对象，这个对象是广义的对象：可以是真实的类，也可以是组件，也可以是某一个系统。

       垂直轴表示时间：由垂直的虚线表示时间，方块表示生命周期。

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

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

1.3.6       活动图（也称泳道图）也是一种分组机制。

       泳道：进一步描述完成活动的对象，并聚合一组活动。活动图是另一种描述交互的方式，描述采取何种动作，做什么（对象状态改变），何时发生（动作序列），以及在何处发生（泳道）。

1.3.7       状态图

用来描述状态的变化及变化的依据，在描述复杂状态变迁的情况非常有用。

1.3.8       组件图

用来 描述业务组件模块关系的图

       物理组件：打包开发出来的组件，如dll

       逻辑组件：系统逻辑上应该分成哪些组件，

详细设计阶段，类的组件图是非常重要的。

1.3.9       合作图是一种没有时序的时序图