软件架构的4+1视图

软件架构的4+1视图模型发展过程：

1.首次提出

       1995年11月 Philippe Kruchten发表于《IEEE Software》的论文《The 4+1 View Model of Architecture》首次提出如图所示的4+1视图，分别为：逻辑视图、开发视图、过程视图、物理视图和场景视图。

       其中，

（1）逻辑视图的利益相关人是最终用户，关注点是系统的功能，系统应该向用户提供什么服务。（使用：可使用类图来描述）

（2）开发视图（实现视图）的利益相关人是开发人员和项目经理，关注点是组织，可复用性，可移植性，产品线。对于非常小的系统，逻辑视图和开发视图可能几乎是一样的，那就没必要分开来描述。（使用：可使用组件图来描述）

（3）过程视图（流程视图）的利益相关人是系统设计人员和集成人员，关注点是一些非功能需求，例如：性能，可用性，软件容错，完整性。从逻辑视图可以分析出有哪些进程，可以用文字进行描述，可不用画出图形。如果只有一个处理器而且只有一个进程或者程序时，可以省略过程视图（使用：文字描述、序列图、活动图、状态图等方式来进行展示）。

（4）物理视图（部署视图）的利益相关人是系统设计人员，关注点是可扩展性、性能，可用性。它是建立软件和硬件的映射关系，考虑系统的非功能需求。（使用：可使用部署图进行展示）

         注：可以看到过程视图和物理视图关注点是有点相似的，都是关注系统的非功能需求，比如性能、可用性等，但是他们考虑的方法和角度是完全不一样的，过程视图考虑的是对系统的进程进行分解，要设计哪些进程，哪些对象要放在哪些进程来运行，通过这样的方式来提高系统的性能和可用性的问题。而物理视图考虑的是把哪些软件部署在哪些硬件上，来解决系统的性能和可用性问题。

（5）场景视图的利益相关人是最终用户、开发人员，关注点是可理解性。场景是最重要的需求的抽象。（使用：可使用用例图描述）

2.演变

               

        演变后，只是更详细和具体了，逻辑视图和过程视图没有变、开发视图变为实现视图，物理视图变为部署视图，场景视图变为用例视图。

3.视图之间的关联

3.1从逻辑视图到过程视图

逻辑视图关系系统的功能，具体就是识别对象与对象的关系，从逻辑视图到过程视图，就是识别对象的并发。

3.2从逻辑视图到开发视图

逻辑视图本身识别出了系统的对象和类，开发视图就是在逻辑视图的基础上，通过类来识别系统模块和子系统，以及模块和子系统之间的关系，从而形成开发视图。

3.3从过程视图到物理视图

4.裁剪模型

       不是所有的软件架构都需要完整的4+1视图，架构描述时可以将没什么用的视图省略掉，例如：如果只有一个处理器而且只有一个进程或者程序时，可以省略过程视图。对于非常小的系统，逻辑视图和开发视图可能几乎是一样的，那就没必要分开来描述。

        但是场景视图在任何情况下都是有用的。

5.总结

视图	逻辑	过程	开发	物理	场景
组件	类	任务	模块， 子系统	节点	步骤， 脚本
连接器	关联， 继承， 包含	Rendez-vous， 消息， 广播， RPC，等等	编译依赖, "with" 子句， "include"	通信介质， 局域网，广域网， 总线，等等
容器	类的类别	进程	子系统（库）	物理子系统	Web
利益相关人	最终用户	系统设计人员， 集成人员	开发人员， 项目经理	系统设计人员	最终用户 开发人员
关注点	功能	性能， 可用性， 软件容错， 完整性	组织， 可复用性， 可移植性， 产品线	可扩展性 性能， 可用性	可理解性
工具支持	Rose	UNAS/SALE DADS	Apex, SoDA	UNAS, Openview DADS	Rose