用例分析开始的。基于用例的分析方法使逻辑架构的设计变得比较有序通过对每个关键用例的分析，从逻辑上将用例实现为一组功能块的特定组合，最后综合这些用例分析成果，将一个个独立的协作归纳合并成整个软件系统的逻辑架构。而在用例分析方法产生之前，功能模块的确定多多少少带有些“硬”想出来的味道，特别是并不直接承载业务功能的模块有时比较容易遗漏，直到大规模编程实现阶段才发现。物理架构软件的物理架构规定了组成软件系统的物理元素、这些物理元素之间的关系、以及它们部署到硬件上的策略。物理架构可以反映出软件系统动态运行时的组织情况。此时，上述物理架构定义中所提及的“物理元素”就是进程、线程、以及作为类的运行时实例的对象等，而进程调度、线程同步、进程或线程通信等则进一步反映物理架构的动态行为。随着分布式系统的流行，“物理层（Tier）”的概念大家早已耳熟能详。物理层和分布有关，通过将一个整体的软件系统划分为不同的物理层，可以把它部署到分布在不同位置的多台计算机上，从而为远程访问和负载均衡等问题提供了手段。当然，物理层是大粒度的物理单元，它最终是由粒度更小的组件、模块、进程等单元组成的。物理架构的应用很广泛。例如，架构设计中可能需要专门说明数据是如何产生、存储、共享和复制的，这时可以利于物理架构，展示软件系统在运行期间数据是由哪些运行时单元如何产生的，数据又如何被使用、如何被存储，哪些数据需要跨网络复制和共享等方面的设计决策。由于人们对组成软件系统的“物理元素”存在不同看法（如图3所示），所以在实践中物理架构的用法比较宽泛，不同的人认为的物理架构也可能不尽相同。因此，我们在交流和实践的过程中，应注意区分物理架构所指为何。（也正是因为这个原因，实践中所采用的基于多视图的架构设计方法往往包含更多的视图，从而使每个架构视图的职责更加明确。）
f图3
对“物理元素”的不同看法
从逻辑架构和物理架构到设计实现逻辑架构和物理架构是软件架构设计的重要方面。逻辑架构致力于将软件系统分解成不同的逻辑单元，并规定这些逻辑单元之间的交互接口和交互机制。物理架构则更重视软件系统运行时的动态结构，以及组成软件系统的目标程序如何部署到硬件上。在后续的详细设计和编程实现中，将贯彻和利用逻辑架构和物理架构设计中制定的架构决策，如图4所示。
图4
逻辑架构和物理架构对后续开发的作用
f逻辑架构中关于职责划分的r