架构的直观展示

接上篇《初探架构，随便整理》本篇内容了解如何通过多个可复用视图表示软件架构。通过这几个视图清晰表达出软件架构的相关方所关心的意图。并且独立处理功能和非功能性需求。

一个架构模型

软件架构模型目的是设计，实现结构更加合理的软件。最终的结果是通过几个明确的架构元素以特定的表现形式去满足一个系统的功能和性能要求。同样也要满足其他非功能性需求如：可靠性（reliability），扩展性（scalability），移植性（portability）和可用性（availability）。以下是软件架构公式：

公式：Software architecture = {Elements, Forms, Rationale/Constraints}

4 + 1 视图模型

软件架构是对抽象的概念，分解和构成，风格和美学的处理。去描述一个软件架构的时候，我们会使用一个 模型去构建多个视图或者观点。文章开头的 5 种视图模型将满足构建大型和有挑战性的架构。

逻辑视图

对象模型设计（当采用面向对象的设计方法时候）。

逻辑视图首先支持功能需求，软件系统可用将怎样的服务提供给用户。软件系统将问题域的问题，对象或类对象，拆解成一组关键抽象的结合。充分利用了抽象，封装，继承的原则。这种拆解不只是用于功能性的评估，还可以为一个系统中的跨域多个部分的通用的结构和设计元素提供服务。

过程视图

捕捉并发，同步方面的设计。

过程视图中的过程分解需要考虑说明一些非功能性需求，比如性能，可用性。过程视图解决并发，分布，系统完整性，容错及怎样将逻辑视图中的主要抽象与过程视图结合（一个控制线程操作一个对象的真正的执行）。过程视图可以描述不同层级的抽象，每一个层级解决不同的问题。在最高层，过程视图可以在通信程序表示一组独立执行的逻辑网络，分布在一组被 “LAN” 或“WAN” 连接的硬件资源中。多重的逻辑网络有可能同步存在，并且共享硬件资源。比如独立的逻辑网络可能被用来支持从一个线下系统分离出线上系统，同样对其软件的模拟，测试版本也有同样很好的支持。一个过程是被可执行单元分配的一组任务，每一个过程处理都会被所在层级的处理架构有目的的控制（启动，回复，重新配置，关机）。

另外过程可被复制来提高分发处理能力或提高可用性。软件被分割成一个独立任务的集合。每个任务由隔离的线程控制，可以按照计划独立的分布在一个处理结点上。任务也可以被区分的：主任务，它们是架构元素中可以被唯一处理，次要任务为附加任务被认为局部实现（周期活动，缓冲，超时等）。

物理视图

描述软件如何在硬件上的部署

将软件到映射硬件，物理视图首先关注是一个系统的非功能需求如可用性，可靠性（容错处理），性能（吞吐量），和可扩展性。软件执行在一个网络的计算机，或者处理结点上。不同元素被确定-网络，处理器，任务，对象，都需要被影射到不同的结点。不同的物理配置将会被使用，针对开发者的，测试，和其他开发中的系统中的不同的消费者。这种软件的映射到结点必须保持高的灵活性和较小的影响对于源码本身。

开发视图

描述软件在开发环境下的静态组织结构。

开发视图主要关注软件在开发环境中的真正的模块组织架构。软件的打包（软件类库文件），子系统（其他开发人员开发的）。子系统被有层次的管理，每一层提供为上层提供定义好的接口。系统的开发视图通过模块和子系统图程序，表示“导入”，“导出” 的关系。复杂的开发视图只有当软件的全部元素被定义之后才可以完成定义。但是，也会列举角色来管理开发视图：分割，分组，可见性。其中最主要的部分，开发视图关注考虑内部需求关联到开发，软件管理，重用或共性和由开发语言或工具集产生的约束。开发视图服务基础的分配需求，团队工作的分配，评估成本和计划。监控项目进度，合理的软件重用，可移植性和安全。是建立产品线的基础。

场景视图

描述用例场景（Putting it all together）。

结合业务场景把以上四种视图一起组合在一起工作呈现（如通常的用例）。场景是重要需求的某种意义上的抽象。它们的设计可以使用对象场景图和对象交互图进行表达。这个视图是其他视图的冗余，但是它主要呈现了两个关键点。1.作为软件架构设计中的一个驱动者去发现架构元素的设计。2.作为一个检验和说明的角色在设计完成之后，同样可以作为架构熟悉测试的一个开始点。