做了好几年架构设计的事了,一直没有好好的总结。实在不好,花点时间总结一下,写出来,有兴趣的朋友可以一起探讨。
软件架构设计的主题狠深狠难,本文打算从架构的概念,架构的表述方法,架构设计的过程三个方面来讲一下我的理解。
一、什么是软件架构?
温昱在《软件架构设计》一书中,给了下面的定义:
组合派:软件系统的架构将系统描述为计算组件及组件之间的交互。
决策派:架构是一系列重要决策的集合,这些决策与以下内容有关:软件的组织,构成系统的结构元素及其接口的选择,这些元素在相互协作中明确表现出的行为,这些结构元素和行为元素进一步组合所构成的更大规模的子系统,以及指导这一组织--包括这些元素及其接口、它们的协作和它们的组合--架构风格。
在我看来,决策派的定义更为具体和准确,注意决策派用了元素这一词而没有用组件,组件是有具体含义的,指一个可独立替换的物理单元,而架构需要能够指导涉众,如开发人员、用户、部署人员等等,对开发人员来讲,开发过程中如何分包、如何将包打包为组件,架构师需不需要提供指导呢,答案是肯定的。因此,如果将架构限定在组件和组件的交互上,是不完整的。
二、架构的表述方法
这个现在都有共识,就是4+1视图表述法:逻辑视图,实现视图,进程视图,部署视图,用例视图。 参见下图RUP 4+1视图:
用例视图关注系统的人、事、物、规则,人是指系统的Actor,包括业务主角和业务工人,事是指系统用例,物是指业务实体,规则指做事情的前置条件、后置条件,做事情过程中的规则。下面这个图很精辟:
用例视图是4+1视图中的+1,它定义需求标准,跟其它视图描述系统某一方面的结构有很大的不同。
逻辑视图关注系统的逻辑功能模块和领域模型,不仅包括用户可见的功能模块,还包括实现用户功能而必须提供的“辅助功能模块”;它们可能是逻辑层、功能模块、类等。
实现视图关注程序包,不仅包括要编写的源程序,还包括可以直接使用的第三方SDK和现成框架、类库,以及开发的系统将运行于其上的系统软件或中间件。开发架构和逻辑架构之间可能存在一定的映射关系:比如逻辑架构中的逻辑层一般会映射到实现架构中的多个程序包;再比如实现架构中的源码文件可以包含逻辑架构中的一到多个类(在C++里一个源码文件可以包含多个类,即使在Java里一个源码文件也可以同时包含一个类和几个内部类)。
进程视图关注进程、线程、对象等运行时概念,以及相关的并发、同步、通信等问题。
进程视图和实现视图的关系:实现视图一般偏重程序包在编译时期的静态依赖关系,而这些程序运行起来之后会表现为对象、线程、进程,进程视图比较关注的是这些运行时单元的交互问题。
物理视图关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器,以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理架构和运行架构的关系:运行架构特别关注目标程序的动态执行情况,而物理架构重视目标程序的静态位置问题;物理架构还要考虑软件系统和包括硬件在内的整个IT系统之间是如何相互影响的。
上面几个视图是最典型的视图,不管你是通信中间件,还是依赖于数据库的企业应用都需要的。对于依赖数据库的企业应用,通常还需要数据视图,数据视图关注对象如何存储,如数据库表等。
4+1视图不仅仅是软件架构的表述方法,它们各自从不同的视角去展现架构,因此,还是一种比较好的思维方式,引导我们从不同的视角去思考,从而做出比较系统的架构设计。
免责声明:本文系网络转载或改编,未找到原创作者,版权归原作者所有。如涉及版权,请联系删