如果一个项目的系统架构（包括理论基础）尚未确定，就不应该进行此系统的全面开发。——Barry Boehm,《Engineering Context》
如果选择试图的工作没有做好，或者以牺牲其他视图为代价，只注重一个视图，就会冒掩盖问题以及延误解决问题（这里的问题是指那些最终会导致失败的问题）的风险。——Grady Booch,《UML用户指南》
从概念架构到细化架构，先设计概念架构，构思关键问题的解决策略；在进行细化架构的设计，以保证为开发提供足够的指导和限制......这符合人类解决问题的规律，因此被广泛采用。
Refined Architecture是相对与Conceptual Architecture而言的，他们是架构设计的两个层次，分别对应与“概念级”解决方案和“规约级”解决方案。需注意的是，Refined Architecture（细化架构）属于架构设计，不能与Detailed Design（详细设计）相混淆。
“细化架构”与“概念架构”的区别
接口，在细化架构中占核心地位，概念架构不关心；
子系统，细化架构重视通过子系统和模块来分割整个系统，并且子系统往往有明确的接口；而概念架构中只有抽象的组件，这些组件没有接口。
交互机制，细化架构基于接口编程、消息机制或远程方法调用进行实在的交互，而概念架构的交互是“概念化”的，如“A层使用B层服务”。
细化架构的多视图-业界现状：RUP4+1视图
细化架构的多视图 业界现状：SEI 3视图（模块视图，组件-连接器视图，分配视图）
细化架构的多视图：每个视图，一组技术关注点
多视图方法是业界广泛认同的一种架构设计思路，具体的多视图方法种类繁多；
SEI的3种视图法： 模块视图 组件-连接器视图、分配视图
西门子的4种视图：概念视图、模块视图、代码视图、执行视图
RUP的4+1视图：用例视图、逻辑视图、开发视图、进程视图、物理视图
联邦企业架构框架（Federal Enterprise Architecture Framework）技术架构视图、信息架构视图、应用架构视图、业务架构视图。
设计逻辑架构：使用UML来描述，静态方面包括包图、类图、对象图；动态方面包括序列图、协作图、状态图和活动图。
逻辑架构的设计应该完成的工作：
- 细化功能单元
- 发现通用机制
- 细化领域模型
- 确定子系统接口和交互机制
因为软件架构的重点在于‘软件系统的各部分是如何相关的’，那么我们可以经过适度的抽象分析，将几组协作中的公共行为提取出来成为‘通用机制’，这样用利于所有涉众对软件架构的共同认识——即提高了系统的概念完整性。
什么是机制？所谓机制，是模式的实例，机制必须进一步细化才能成为特定模型中的协作，因此，机制是独特上下文中重复出现的问题的特定解决方案。可以说，机制符合模式的定义，任何协作都可以被称为机制，但通常，机制仅表示‘软件应用系统中重复出现的问题的解决方案’的协作，例如可以采用模式的持久化处理等等。
具有良好架构的系统具备概念完整性，它通过对系统架构建立一种清晰的认识来发现通用的抽闲机制，利用这种共性使得最终产生的系统结构更加简单，因而规模更小且更可靠。一个系统使用10000行代码实现远比1000000行代码好的多。
一流是每个程序设计人员向往并为之奋斗却又无法具体说出的、难以达到的境界。一流的软件非常简明，它灵活而清晰，能通过创造性的机制解决复杂的问题，这些机制语义丰富，可以应用于其他可能完全无关的问题。一流意味着寻求恰当的抽象，意味着通过新的途径合理利用有限的资源。
设计开发架构：着重考虑开发期间的质量属性，例如可扩展性、可重用性、可移植性等，开发架构的关注点是在软件开发环境中软件模块的实际组织方式，具体涉及源程序文件、配置文件、源程序包、编译后的目标文件、第三方库文件等。使用UML进行描述的话，涉及到包图、类图、组件图等。
开发架构的设计工作包括：
- 确定要开发或直接利用的程序包之间的依赖关系
- 确定采用的技术
- 确定采用的框架
设计数据架构：着重考虑‘数据需求’，系统=程序+数据+硬件。数据架构的关注点是持久化数据的组织，对于很多集成系统，数据需要在不同系统之间传递、复制、暂存等，这往往涉及到不同的物理机器。数据架构的描述一般采用E-R图和数据流图来表示，采用UML时，涉及到类图和活动图。
数据架构的设计工作包括：
- 持久化数据存储方案
- 数据传递、数据复制、数据同步等策略
设计运行架构：着重考虑运行期间质量属性，例如性能、可伸缩性、持续可用性等。运行架构关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。采用UML图，静态方面涉及包图、类图、对象图；动态方面涉及序列图、协作图等。
开发架构一般偏重于程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，运行架构比较关注的是这些运行时单元的交互问题，运行架构是在开发架构的基础上，从宏观上规划多条控制流的并发和同步。
运行架构的设计工作包括：
- 确定引入哪些进程和线程
- 确定主动对象、被动对象、以及控制流关系
- 处理相关问题：进程线程的创建、销毁、通信机制、资源争用等。
- 协议设计，例如基于TCP/IP协议定义本系统的‘应用协议’。
运用主动类规划并发
进行并发设计的原因：1. 软件系统要支持的业务本身可能是并发的。2. 处于对性能和伸缩性的考虑。3. 在某种情况下，并发性设计是最直观的。
实现并发的两种方法：进程和线程。在面向对象方法中，线程也应通过对象来封装，这包括两个概念：主动对象和主动类。主动对象是一组属性和服务的封装体，其中至少由一个服务是主动服务，主动服务不需要接收‘消息’就能主动执行。与主动对象相对的概念是被动对象，它的所有服务都是被动服务，需要被调用才能执行。主动类则是描述主动对象的类。
主动对象对于并发性设计之所以重要，是因为它是控制流的驱动者，主动对象的主动服务是控制流的源头，该主动服务被创建成进程或线程，从而它可以获得处理机资源并开始活动。从主动对象的主动服务开发，层层调用其他对象的服务，形成一个控制流。把系统中的所有主动对象表示清楚，就抓住了系统中每个控制流的源头，就可以吧并发执行的所有控制流梳理清楚。
设计物理架构：着重考虑‘安装和部署需求’，物理视图描述了运行软件的计算机、网络、硬件设施等情况。还包括如何将软件包部署到这些硬件资源上，以及它们运行时的配置情况。相对于运行架构，物理架构重视目标程序的静态位置问题。如果采用UML，涉及到部署图和组件图。
物理架构的设计工作包括：
- 确定物理配置方案
- 确定如何将目标程序映射到物理节点
进行架构设计时，还需要注意要满足所有约束性的软件需求，忽视它们可能导致架构设计的失败。