第一周学习笔记

先说说这次参加架构训练营的初衷，工作以来，做设计写方案，图画了不少，从来没有系统梳理过，按部就班的画图，也不考虑太多的地方，大学学的东西，也还给老师了。这次就是抱着实战和学习的态度，重新梳理。下面是第一周的笔记：

交互

· 4+1架构视图

· 软件架构二｛元素,形式,关系/约束｝ 单一的视图无法完整的表达架构，因此需要具备完整的视图集。

· 逻辑视图(Logical View) ,设计的对象模型。

· 相关方：客户，用户，开发组织管理者。

· 视角：系统的功能元素，以及它们接口,职责，交互。 主要元素：系统，子系统，功能模块，子功能模块/接口。

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

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

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

· 视角：系统运行时线程/进程的情况。

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

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

· 相关者：系统集成商，系统运维人员。

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

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

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

· 相关者：开发相关人员,测试人员。

· 视角：系统如何开发实现。

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

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

· 场景视图(scenarios),描述用例场景（类似用例图）

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

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

· 软件建模语言UML

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

· 建造软件模型的目的

· 为了与它人沟通

· 为了保存软件设计的最终成果

· 前提：除非模型比代码更说问题

· 何时画图？

· 讨论、交流时

· 最终设计文档

· 只保留少量的、重要的图

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

· UML简介

· 什么是UML?

· Unified Modeling Language,或统一建模语言

· 以图形方式描述软件的概念

· UML图的分类

· 静态图-通过描述类、对象和数据结构以及它们之间存在的关系,来描述软件要素中不 变的逻辑结构。任何建模语言都以静态建模机制为基础,标准建模语言UML也不例外。所谓静态建模是指 对象之间通过属性互相联系/而这些关系不随时间而转移。

· •用例图(Use Case Diagrams)，在需求分析、概要设计、详细阶段使用。用例图细化程度，取决于参与者是谁，能说明问题。图示可以层层分解。

· •对象图(Object Diagrams)

· •类图(Class Diagrams)

· • 组件图(Component Diagrams)

· • 包图(Package Diagrams)：解决该问题的思路之一是 将许多类集合成一个更高层次的单位/形成一个高内聚、低耦合的类的集合。UML中这 种分组机制叫包(Package)。引入包是为了降低系统的复杂性。

· •部署图(Deployment Diagrams)

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

· •状态图(state diagram):状态图用来描述对象,子系统/系统的生命周期。

· •活动图(activity diagram):着重描述操作实现中完成的工作以及用例实例或对象中的活动, 活动图是状态图的一个变种。

· •时序图(sequence diagram)):是一种交互图，主要描述对象之间的动态合作关系以及合 作过程中的行为次序，常用来描述一个用例的行为。

· •合作图(collaboration diagram):用于描述相互合作的对象间的交互关系/它描述的交互 关系是对象间的消息连接关系。

· 通用模型元素

· 用例建模

· 用例模型描述的是外部执行者（Actor）所理解的系统功能。它描述了待开发系统的功能 需求。

· 它驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现, 而且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和UML的各个 模型。

· 用例模型由若干个用例图构成/用例图中主要描述执行者和用例之间的关系。在UML 中，构成用例图的主要元素是用例和执行者及其它们之间的联系。

· 创建用例模型的工作包括：定义系统、确定执行者和用例、描述用例、定义用例间的关 系、确认模型。

· 执行者（Actor）

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

· 如何确定执行者:

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

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

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

· 4. 系统需要控制哪些硬件设备？

· 系统需要与其它哪些系统交互？ 谁需要使用系统产生的结果（值）?

· UML中的消息

· 简单消息(simple) ：表示控制流/描述控制如何从一个对象传递到另一个对象/但不描述通信的细节

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

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

· 部署图

·