软件架构的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 |