本周主要了解了何为软件架构、何为架构师以及架构师的主要能力；

了解了4+1架构视图、常用的UML图、各个UML图的使用场景以及介绍了架构设计文档书写的模板。

1       何为软件架构

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

关于软件架构的架构对象图：





解释：

a.     每个系统都有架构；

b.     架构是由架构元素及元素间关系组成；

架构元素：

指系统的组成部分（比如：服务器、子系统、模块、组件、类等）。

元素间关系：

各个元素之间的关系分为两类：

静态关系（关联、依赖、组合、聚合、泛化、实现等）

动态关系（指元素间交互）

c.     架构关联架构文档；

d.     架构文档是由多个架构视图组成的；

e.     架构视图关联一些关注点；

f.      系统关联一些相关方；

g.     各个相关方都有自己的一些关注点；

h.     给不同的相关方需要展示不同内容的架构文档；

注意:

       架构设计的重点是相关方，架构是给相关方做的！

2       何为架构师

架构师是做架构设计、对系统架构负责的人。

架构师是一个角色而不是一个职位，只要负责了架构设计那就是架构师，而不是必须有个架构师的Title。

3       架构师的主要能力

编程能力

基础技术掌握能力

常用技术产品的理解与应用能力

性能优化与分析故障的能力

常用架构模式和框架的理解与应用能力

建模以及设计文档的方法和能力

业务理解与功能模块及非功能模块拆解能力

快速学习能力

沟通与领导能力

4       4+1架构视图

逻辑视图(Logical View)，设计的对象模型（使用面向对象的设计方法时）。

              相关方:客户,用户,开发组织管理者。

视角:系统的功能元素,以及它们接口,职责,交互。

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

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

开发视图(Development View),描述了在开发环境中软件的静态组织结构。

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

视角:系统如何开发实现

主要元素:描述系统的层,分区,包，框架,系统通用服务，业务通用服务,类和接口,

系统平台和相关基础框架。

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

物理视图(Physical View) ,描述了软件到硬件的映射，反映了部署特性。

              相关方:系统集成商,系统运维人员。

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

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

用途：描述系统安装和部署情况。

过程视图(Process View)，捕捉设计的并发和同步特征。

              相关者:性能优化，开发相关人员。

视角:系统运行时线程,进程的情况。

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

用途：关注设计的并发和同步方面，考虑了一些非功能性需求，

比如性能和可用性。

场景视图(Scenarios)，描述用例场景。

       4+1视图关系如下:





5       什么是模型

模型是一个系统的完整的抽象。人们对某个领域特定问题的求解及解决方案，对它们的

理解和认识都蕴涵在模型中。

通常,开发一个计算机系统是为了解决某个领域特定问题,问题的求解过程,就是从领

域问题到计算机系统的映射。



6       模型元素之间的关系





依赖:

       对于两个相对独立的对象，当一个对象负责构造另一个对象的实例，或者依赖另一个对象的服务时，这两个对象之间主要体现为依赖关系。



关联:

       对于两个相对独立的对象，当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时，这两个对象之间为关联关系。关联关系分为单向关联和双向关联。





聚合：

       聚合关系是关联关系的一种，耦合度强于关联，他们的代码表现是相同的，仅仅是在语义上有所区别：关联关系的对象间是相互独立的，而聚合关系的对象之间存在着包容关系，他们之间是“整体-个体”的相互关系。



组合：

       相比于聚合，组合是一种耦合度更强的关联关系。存在组合关系的类表示“整体-部分”的关联关系，“整体”负责“部分”的生命周期，他们之间是共生共死的；并且“部分”单独存在时没有任何意义。



继承：

       继承表示类与类（或者接口与接口）之间的父子关系。



实现:

       表示一个类实现一个或多个接口的方法。



7       常用的UML图及使用场景

软件建模与设计过程可以拆分成需求分析、概要设计和详细设计三个阶段。

UML 规范包含了十多种模型图，常用的有 7 种：

静态图：用例图、类图、组件图、部署图。

动态图：序列图、状态图和活动图。

用例图：

用例图主要用在需求分析阶段。

用例图通过反映用户和软件系统的交互，描述系统的功能需求。





图中小人形象的元素，被称为角色，角色可以是人，也可以是其他的系统。

系统的功能可能会很复杂，所以一张用例图可能只包含其中一小部分功能，这些功能被一个矩形框框起来，这个矩形框被称为用例的边界。

框里的椭圆表示一个一个的功能，功能之间可以调用依赖，也可以进行功能扩展。

用例图可以自顶向下不断细化，抽象出不同层次的用例图来。

类图：

              类图主要是在详细设计阶段画。

类图描述类的特性和类之间的静态关系。

       通常不需要把一个软件所有的类都画出来，把核心的、有代表性的、有一定技术难度的类图画出来，一般就可以了。





       部署图：

                     部署图主要用在概要设计阶段。

部署图描述软件系统的最终部署情况。

通常建议架构师画的第一张图是部署图。



       组件图：

                     组件图一般用在概要设计阶段。

组件图描述组件之间的静态关系，主要是依赖关系。

组件图通常用来描述物理上的组件，比如一个 JAR，一个 DLL 等等。

组件是比类粒度更大的设计元素，一个组件中通常包含很多个类。

因为组件的粒度比较粗，通常用以描述和设计软件的模块及其之间的关系。



       序列图：

                     在软件设计的不同阶段，都可以画序列图。

                     序列图用来描述参与者之间的动态调用关系。

       序列图通常用于表示对象之间的交互，这个对象可以是类对象，也可以是更大粒度的参与者，比如组件、服务器、子系统等，总之，只要是描述不同参与者之间交互的，都可以使用序列图。





       状态图：

状态图要在需求分析阶段画，描述状态变迁的逻辑关系，在详细设计阶段也要画，这个时候，状态要用枚举值表示，以指导具体的开发。

                     状态图用来展示单个对象生命周期的状态变迁。



       活动图：

                     在软件设计的不同阶段，都可以画活动图。

                     活动图用来描述过程逻辑和业务流程。很多时候，人们用活动图代替流程图。

       活动图引入了一个重要的概念——泳道。活动图可以根据活动的范围，将活动根据领域、系统和角色等划分到不同的泳道中，使流程边界更加清晰。

活动图比较有普适性，可以在需求分析阶段描述业务流程，也可以在概要设计阶段描述子系统和组件的交互，还可以在详细设计阶段描述一个类方法内部的计算流程。