对软件架构的理解杂记

架构是决策与结构的综合体，关注分割与交互，也是有层次的决策，既需业务知识，又要具备建模技能。

其成果物：1、《软件架构文档》；2、可供实际测试的架构原型。

use case是手段，各种OO的原则是指导，设计模式是经验，灵活运用是能力。

架构设计的主线

1、从需求向架构过渡（主要看经验，权衡考虑需求），作为架构设计文档当中一项；

需求对架构的影响因素：功能、质量、约束。实践要领：架构设计不单由功能驱动，采用合适你项目的质量分类，约束分析。

分析交织需求的维度：组织级、用户级、开发级；功能、质量、约束。

讨论用例时，首要要问的是，到底目前的研究对象是什么？

输入： 功能、质量、约束

步骤：全面整理需求、分析约束性需求、确定关键功能及质量需求

输出：关键功能及质量

2、概念性架构设计（工作量不大，对后期影响大），作为架构设计文档的概述部分等；

分析系统会涉及到什么职责，引入合适的架构模式，有秩序的组合离散的职责。此时需要考虑非功能性需求。

分层流派：逻辑层Layer、物理层Tier、按通用性分层、技术层次

架构模式：MVC架构、PAC架构、微内核架构、基于元模型架构、虚拟机架构、管道－过滤器架构

3、细化架构设计，成果物是多视图的的架构设计文档；

考虑设计接口及设计模式；具体有标准的多视图设计等体系化方法。

建模技能：要么面向对象的，要么结构化分析和设计。

对象基础里面的原理、原则、模式，原理不就那么几条吗，原则也就十几条，模式上千个。

但更重要的是对业务知识的理解，才知道哪些会变化，哪些不变。

5视图：逻辑架构、开发架构、运行架构、物理架构、数据架构。

质量指标：持续可用性、可伸缩性、安全性、可测试、松耦合与可扩展、可重用性。

架构设计的方法

1、偷；模仿前人经验。

2、创造；据实际需求完全创造自已的方法。

3、方法；不是完全照搬，也不是完全创造，通过理性的分析，权衡分析与设计。

分析项目源码方法

1、借助建模工具，正逆向工程；

2、删代码，读程序时把不关键代码删掉，读出代码的架构；

3、接触重构，修改核心代码时，一般都加注释，可借助重构的方式，把相关名称与职责划分开来； 

需求分析

需求规格说明书：需求变化、用例技术、系统分析

系统分析：结构化（数据流）、面向对象（类图、序列图）

领域分析与建模：领域类图、状态图；业务用例图、业务流程活动图；系统用例图、系统流程活动图

确认关键需求：细化状态图

概念性架构设计：引入架构模式、鲁棒式分析

细化架构设计：

验证架构：原型开发

5+1视图

1、用例视图（用例图）：

应用场景需求

2、逻辑视图（静态：包图、类图、对象图；动态：序列图、协作图、状态图、活动图）：

功能需求、逻辑单元的划分以及交互机制

逻辑架构设计的3大核心任务：识别功能模块；规划功能块的接口；明确功能块之间的使用关系和使用机制。

分析关键用例，从逻辑上将用例实现为一组功能模块的特定组合，综合用例分析成果，将独立的协作归纳合并成整个软件系统的逻辑架构。

3、开发视图（包图、类图、组件图）：

开发期质量属性（可扩展性、可重用性、可移植性、可维护性、易理解性、易测试性等）

源程序、第三方SDK、框架、类库、中间件等

4、处理视图（静态：包图、类图、对象图；动态：序列图、协作图）：

运行期质量属性（性能、安全性、易用性、持续可用性、可伸缩性、互操作性、可靠性、鲁棒性等）

进程、线程、任务、对象，并发、同步、通信等

持续可用性的含义= 可靠性+ 可维护性+安全性

99.99%：0.07小时（4分12秒）/每月、99.9%：0.7小时 /每月、98.6%：10小时

5、物理视图（）部署图、组件图：

安装和部署需求

6、数据视图（E-R图：特定版型的类图、数据流图：带对象流的活动图）：

数据需求（数据存储、数据传递、数据复制、数据同步等）

鲁棒式分析

分析的输入：

一个用例

这个用例的用例场景

这个用例的活动图（如果可以用到）

域模型（domain model）

分析的输出：

通过一个UML序列图和一些设计组件：边界、服务、实体组件，我们得出设计模型。

分析的过程：

1.选择一个适当的用例。

2.把一个参与者放到协作图里面。

3.分析这个用例（活动图）。

对于用例的每一个动作：

a.确定并增加边界组件

b.确定并增加服务组件

c.确定并增加实体组件

d.画出这些组件间的关联

e.把每个组件都贴上用来满足用例交互的动作标签

4.从另一个角度，把协作图转换成序列图（可选的）。

备注：协作图与序列图的元素