架构师训练营第一周总结

下面是本周的总结

什么是架构？

架构包含了关于以下问题的重要决定：

1. 软件系统的组织

2. 选择组成系统的机构元素和他们之间的接口，以及当这些元素相互协作时所体现出的行为

3. 如何组合这些元素，使它们逐渐集成为更大的子系统

4. 架构风格，它将知道系统组织及其元素、它们之间的接口、协作和构成



架构的目的是什么？

是为了设计师、程序员、使用者、经理都能理解：

1.系统做什么   

2.系统怎样工作

3.完成系统的一部分工作

4.扩展系统

5.对系统的部分进行重用

6.智能控制：管理项目的复杂性，保持系统的完整性

7.开发的基础

为了达到这些目的，架构的表达必须精确，无二意。



有哪些人关注架构？

1.系统分析人员 - 通过架构组织需求，将需求明确表达出来，理解技术限制和风险

2.最终用户或客户 - 站在较高层次可视化地认识它们买的产品

3.软件项目经理 - 使用架构组织开发队伍，并指定开发计划

4.设计师 - 理解根本原则并确定自己的设计边界

5.其他开发组织 - 了解如何和系统衔接

6.子承包商 - 了解开发块的边界

7.架构师 - 推断扩展或重用



不同的项目相关人员关心架构的不同方面，一个完整的架构是多维的，而不是平面的



架构关注哪些东西？

系统内部，操作语境（它的最终用户）、开发语境（开发系统的组织），包含技术问题，经济问题，社会问题，风格，美学。



我对架构的看法：

《孙子兵法》“先计而后战”。架构就是类似与这个计算的阶段。1.计算一下系统应该做些什么，评审一下有没有漏掉的，有没有多余的。2. 计算一下系统怎么去做，评审一下，这样真的能实现吗？真的没有什么限制吗？技术上达不到怎么办，钱不够怎么办，人不够怎么办？3.计算一下，站在公司全局的角度，哪些功能，我们可以哪来直接用，哪些功能，这次我们建设一个，以后让别的人直接复用。等等

通过这么事先的谋划计算，达到先胜而后战的目标。为什么这个很重要？因为这样成功的把握就大，成本可控（省钱，省力，省心）



如何去架构？

通过建模的方式，模型是现实的简化，需要架构的系统肯定有一定复杂性，单独模型无法覆盖全部，需要多个模型



如何建模？

建模就是把问题，最终映射到解决方案上



一般用视图去建模，为了建模的准确，无二意，大家都能看懂（其实非技术人员还是看不懂），使用UML来创建视图，前人总结了一套4+1视图模型，从不同的维度或视角，作为载体去表达架构的思想

1. 逻辑视图：最终用户，功能性

2. 开发视图：程序员，软件管理

3. 过程视图：系统集成人员，性能，可伸缩性，吞吐量

4. 物理视图：系统工程，系统拓扑，交付、安装、通信

5. 场景视图：分析员/测试人员，行为



建模如何分类？

UML静态建模：主要摩艾殊系统中不随时间变化的关系

用例图，类图，对象图，包图，组件图，部署图

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

状态图，活动图，时序图，合作图



UML中的元素有哪些？

类，对象，结点，包，组件等



UML中类的六大关系

1. 泛化关系（Generalization）: 子类继承父类

2. 实现关系（Realization）：实现接口或继承某个抽象类

3. 组合关系（Composition）：成员变量，整体和部分的关系，部分不能独立存在

4. 聚合关系（Aggregation）：成员变量，整体和部分，整体能够独立存在

5. 关联关系（Association）：成员变量，平级关系，无整体和部分

6. 依赖关系（Dependency）：局部变量，方法的参数和静态方法的调用

聚合和关联的区别：语义的区别，关联关系双方是平等的，聚合不平等。

关联和依赖的区别：依赖是一种偶然的关系，并不明显，关系不明显，关联则很明显。



结语

架构是多维度的，平面立不起来。学习老师的课程应该也是这样的，光看PPT的内容，理解的始终欠点意思，于是我又找了一本书做参考《Rational 统一过程引论（第2版）》，结合着看看，希望能加深理解。

另外，其实我在工作中也遇到问题，就是感觉时间不够，早9晚9，每天只有早上1小时的时间学习架构，刚开个头呢，进入状态而后又嘎然而止。工作中各种琐事，各种问题也很烦人，工作中的问题，还真不能提，提了也没人听，然后大家还是照着原来习惯的，但并不高效的方式前进。