不积跬步,无以至千里。 程序员在向架构师转型时,都希望尽早清除“什么是架构”。但是架构的额定义又多又乱。已造成“什么是架构”成了程序员向架构师转型的最大门槛。 1.1 软件架构的分类 一个词(比如电脑),可能并不代表一件单独的东西,而是代表了一类事物。这个一般性的表述就是我们通常所说的概念。 也许大家期待一个干净利落的软件架构概念,但这有点儿难。对此,马丁·福勒给出的评价是: 软件业的恶人乐于做这样的事——找一些词汇,并将它们引申到大量微妙而又相互矛盾的含义中。一个最大的受害者就是架构这个词。很多人都试图给架构下定义,而这些定义本身却很难统一。
本专栏将软件架构概念分为两大流派——组成派和决策派,帮助各级开发人员快速理清“什么是架构的”的基础问题。下面就采用这种方式介绍结构概念。 2.1.1 组成派 Mary Shaw在《软件体系结构:一门初露端倪学科的展望》中,为软件架构给出了非常简明的定义: 软件系统的架构将系统描述为计算机组件与组件之间的交互。
必须说明,上述定义的组件是广泛意义上的元素之意,并不是指和CORBA、DCOM、EJB等相关的专有的组件概念。计算组件页式泛指,其实计算组件可以进一步细分为处理组件、数据组件、连接组件等。总之,组件可以指子系统、框架、模块、类等不同粒度的软件单元,他们可以担负不同的计算职责。 上述定义是组成派软件架构的典型代表,有如下两个显著特点: 关注架构实践中的客体——软件,以软件本身为描述对象。 分析了软件的组成,即软件由承担不同计算任务的组件组成,这些组件通过相互交互完成更高层次的计算。
2.1.2 决策派 RUP(Rational Unified Process,统一软件开发过程)给出的架构的定义非常冗长,但其核心思想非常明确:软件架构是在一些重要方面所作出的决策集合。下面看看它的定义: 软件架构包含了关于以下问题的重要决策: 软件系统的组织; 选择组成系统的结构元素和他们之间的接口,以及当这些元素相互协作时所体现的行为; 如何组成这些元素,使他们逐渐合成为更大的子系统; 用于指导这个系统组织的架构风格:这些元素以及它们的接口、协作和组合。 软件架构并部基金注重软件本身的结构和行为,还注重其他特性:使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制及权衡,以及美学等。
该定义是“决策派”软件架构概念的典型代表,有如下两个显著的特点: 2.1.2 软件架构概念大观 下面再列举几个著名的软件架构定义,请大家: 结合实践,体会自己所认为的“架构”是什么,也可以问问周围同事对架构的理解; 体会到专家们对“架构”下的定义虽然多,但万变不离其宗——都是围绕“组成”和“决策”两个角度定义架构的; 注意区分,下面的定义1和定义2属于架构概念的“决策派”,而定义3、4、5、6、7属于架构概念的“组成派”; 关注定义7,它将架构的多视图“本性”体现到了定义当中,是相对比较新的定义,业界都深表认同。
1.Booch、Rumbaugh 和 Jacobson的定义 架构师一系列重要决策的集合,这些决策与以下内容有关:软件的组织,构成系统的结构元素及其接口的选择,这些元素在像话协作照片那个明确表现出的行为,这些结构元素和行为元素进一步组合所构成的更大规模的系统,以及指导这一组织——包括这些元素及其接口、它们的协作和它们的组合——架构风格。 2.2 概念思想的解析2.2.1 软件架构关注分割和交互 架构设计师分与合的艺术。 “软件系统的架构将系统描述为计算机组件及组件之间的交互”,shaw的这个定义从“软件组成”角度解析了软件架构的要素:组件及组件之间的交互。架构=组件 交互,组件和111组件之间有交互关系(图中的交互“关系”建模成UML关联类)。 下面以大家熟悉的MVC架构为例进行说明。如图2-1所示。 来源:https://www./content-4-785801.html
|