摘要：软件架构是一个系统的草图。把一个项目按照一定的原则进行切分，给每个人分配模块任务，最后再有机的集合在一起。遵从“需求进，架构出”的方法体系ADMEMS：第一阶段Pre-Architecture是需要全面理解需求，预备架构，在这一阶段画出需求层次-需求方面二维矩阵，确定关键质量，关键功能；第二阶段Conceptual Architecture界定系统高层组件关系，概念架构，与接口无关，在这一阶段绘制概念体系架构图；第三阶段Refined Architecture，即细化架构，本文对逻辑架构重点解释，其他一概而过。本文是我对《软件体系架构》这门课程的总结。
关键词：质量属性，架构，架构设计方法体系，关键质量，关键功能，鲁棒图，逻辑视图；
- 认识软件体系结构
①什么是架构？
把一个项目按照一定的原则进行切分，给每个人分配模块任务，最后再有机的集合在一起。
②为什么要出现架构?
当一个项目不可能由一个人完成或者在有限的时间内完成，需要多人分工分模块完成时
③架构解决谁的问题？
解决人的问题：拿到一个特定的项目，为了人在有限时间内解决这一问题
- 质量属性
日常，你怎么去评价一个东西的好坏呢？假如你要征婚，那么你对征婚对象的标准是什么呢？请看以下三个问题：
①理想中的伴侣的评价标准
身高153-163cm，体重40-55kg，学历至少高中毕业，性格开朗，话不能太少（不能太蔫）
②将评价标准归纳为几个方面
外在体型，学历，内在性格，社会经历，有过几任男朋友
③你认为那几个方面最重要
身高（至少要比我矮）；
学历（不能太低，否则共同语言少）；
性格（不能太蔫）；
系统的好坏也有这样一套标准，可以归纳为六个方面：
可用性（Availability）：指系统正常运行时间的比例，是通过两次故障之间的时间长度或在系统崩溃情况下能够恢复正常运行的速度来衡量的。
场景样例：能够连续运行的时间不小于240小时，意外退出后能够在10秒之内自动重启。
可修改性（Modifiability）：两个关注点：可以修改什么？何时以及谁进行修改。
场景样例：开发人员想修改用户界面。需要在设计时改变代码，并要求在3小时内完成代码修改及测试，且不产生有副作用的变化。
性能（Performance）：指系统的响应能力----即对外部刺激(事件)做出反应时所需要的时间或在某段时间内所处理的事件个数。
场景样例：在初始需求中定义的机器性能条件下，对于一个包含50个对象的设计模型，将其转换为相应代码框架时所消耗时间不超过5秒。
安全性（Security）：衡量系统在向合法用户正常提供服务的情况下，阻止非授权使用的能力。
场景样例：支持相关开发数据在云端存储，需要保证在云端存储数据的机密性和完整性。
可测试性（Testability）：指通过测试揭示软件缺陷的难易程度。
场景样例：一个单元测试。
易用性（Usability）：关注的是对用户来说完成某个期望任务的难易程度。
场景样例：记住账户功能。
- “需求进，架构出”架构设计方法体系（结合会议室项目实战分析）
3个阶段，1个贯穿环节：
“Pre-architecture”阶段（简称PA阶段）是需要全面理解需求，预备架构
“Conceptual Architecture”阶段（简称CA阶段）界定系统高层组件关系，概念架构
“Refined Architecture”阶段（简称RA阶段）即细化架构
对非功能目标的考虑贯穿整个过程
3.1PA阶段：不仅是理解需求
3.11本阶段目的：
分析业务需求和约束背后的衍生需求；
发现遗漏需求；
确定关键功能；
确定关键质量；
权衡质量属性之间的矛盾关系；
3.12倡导的需求过程：
第1步：需求结构化
第2步：分析约束影响
第3步：确定关键质量
第4步：确定关键功能
3.121第一步第二步生成需求层次-需求方面二维矩阵：
|
|
功 能 |
质 量 |
约 束 |
|
组织 |
业务目标、及业务愿景： 为用户快速准确提供会议室； 用户修改删除会议室操作方便；
未来： 扩大增加新的会议室 |
商业质量： 系统操作方便准确 |
商业约束： 宣传到位，会议室环境好，有常客
集成约束： 邮局邮寄会议信息、电子邮箱 |
|
用户 |
用户： 会议召开申请者； 会议管理员； 系统维护人员； 会议召开申请者功能： 申请会议室； 更改申请； 取消申请；
会议管理员功能： 定义会议； 删除会议； 修改会议；
系统维护人员功能： 设置预定时限； 会议室维护；
|
运行期质量： 易用性：便捷的操作方式 性能：快速确定会议室 安全性：用户数据安全，会议信息安全 可用性：系统崩溃，再5s内重启 可修改性：可更新功能，添加会议室 可测试性：可对系统进行测试 |
用户级约束： 便捷的预定会议室流程；
客户心理： ①只要出现一次预订出错耽误我召开会议，以后再也不来了； ②对系统体验：“操作简洁”“操作麻烦，不会用” |
|
开发 |
|
开发期质量： 可扩展性 |
开发方约束： 系统发展前景 |
3.122确定关键质量：
会议召开申请者，会议管理员：
易用性：便捷的操作方式
性能：快速确定会议室
安全性：用户数据安全，会议信息安全
可用性：系统崩溃，再5s内重启
系统维护人员：
可修改性：可更新功能，添加会议室
可扩展性
可测试性：可对系统进行测试
3.123确定关键功能：
会议召开申请者功能：
申请会议室；
更改申请；
取消申请；
系统维护人员功能：
设置预定时限；
3.2CA阶段：界定系统高层组件关系，概念架构
3.21概要架构定义：
满足“架构=组件+交互”的基本定义；
对高层组件的“职责”进行笼统界定，并给出高层组件的相互关系；
不应涉及接口细节；
3.22概要架构之初步设计：初步设计的目标就是发现职责，运用“职责协作链”原理画鲁棒图
3.221鲁棒图的三种对象：
边界对象对模拟外部环境和未来系统之间的交互进行建模。边界对象负责接 收外部输入、处理内部内容的解释、并表达或传递相应的结果。
控制对象对行为进行封装，描述用例中事件流的控制行为
实体对象对信息进行描述，它往往来自领域概念，和领域模型中的对象有良好的对应关系。
3.222项目实战绘制鲁棒图：
3.23概要架构-高层分割：
“一步到位”还是“两步到位”：
3.231切系统为系统：这里不再概述；
3.232切系统为子系统：
绘制系统的概念体系架构图：
3.24概要架构-考虑非功能需求
通过“目标-场景-决策表”分析非功能需求
3.3RA阶段：细化结构
3.31“细化架构”与“概念架构”的区别：
接口：在细化架构中占核心地位，概念架构不关心；
子系统：细化架构重视通过子系统和模块来分割整个系统，并且子系统往往有明确的接口；而概念架构中只有抽象的组件，这些组件没有接口。
交互机制：细化架构基于接口编程、消息机制或远程方法调用进行实在的交互，而概念架构的交互是“概念化”的，如“A层使用B层服务”。
3.32细化架构概述
细化架构的多视图：业界现状：RUP4+1视图；SEI 3视图（模块视图，组件-连接器视图，分配视图）
细化架构的多视图-实践要领：
5视图方法提出，每个视图，一个思维角度：逻辑视图；物理视图；开发视图；数据视图；运行视图
3.33细化架构之逻辑架构
划分子系统策略可归纳为 3 种：分层的细化；分区的引入；机制的提取。子系统的划分必须三管齐下。
子系统划分：4个重要原则
职责不同的单元划归不同子系统；
通用性不同的单元划归不同子系统；
需要不同开发技能的单元划归不同子系统；
兼顾工作量的相对均衡，把太大的子系统进一步做切分。
接口的设计：协作决定接口（xBank与SAP）
整体思路：
第一步，根据当前理解运用3手段切分；
第二步，找到某功能的参与单元；
第三步，通过行为让他们协作完成功能；
第四步，质疑并推进设计的深入。
3.34细化架构之物理架构、运行架构、开发架构
3.341细化架构-物理架构
物理架构的设计内容：硬件选择与物理拓扑；软件到硬件的映射关系；方案的优化
3.342细化架构-运行架构
运行架构的设计内容：确定引入哪些控制流；确定每条控制流的任务；控制流的创建、销毁、通信机制等；控制流之间的同步关系，加锁机制等。
3.343细化架构-开发架构
开发架构设计的工作内容：
将“逻辑职责”映射为“程序单元”：要自主编写的源程序；可重用的库、框架；其他方式（shell脚本，平台配置文件）
开发技术选型：开发语言，开发工具
“程序单元”间关系：Project划分；Project目录结构；编译依赖关系
3.35细化架构之数据架构
数据分布的6种策略：独立Schema；集中；分区；复制；子集；重组。