ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 软件架构概念思辨

软件架构概念思辨

原创 Linux操作系统 作者:ITPUB_PMSpace 时间:2008-01-17 22:19:45 0 删除 编辑
一个词(比如“电脑”),可能并不代表一件单独的东西,而是代表了一类事物。这个一般性的表述就是我们通常所说的“概念”。

  也许读者期待一个干净利落的软件架构概念,但这不是现实。对此,Martin Fowler给出的评价是,“软件业的人乐于做这样的事——找一些词汇,并把它们引申到大量微妙而又相互矛盾的含义。一个最大的受害者就是‘架构’这个词。……很多人都试图给‘架构’下定义,而这些定义本身却很难统一。”

  软件架构概念:组成派

  关于软件架构的概念,有太多版本,这对我们的实践也造成了很多麻烦。笔者认为,可以将这些概念大致分为两大流派:组成派和决策派。

  Mary Shaw在《软件体系结构:一门初露端倪学科的展望》中,为“软件架构”给出了精致利索的定义:

  软件系统的架构将系统描述为计算组件及组件之间的交互(The architecture of a software system defines that system in terms of computational components and interactions among those components.)。

  必须说明,上述定义中的“组件”是广泛意义上的元素之意,并不是指和CORBA、DCOM、EJB等相关的专有的组件概念;“计算组件”也是泛指,其实计算组件可以进一步细分为处理组件、数据组件、连接组件等。总之,“组件”可以指子系统、框架、模块、类等不同粒度的软件单元,它们可以担负不同的计算职责。

  上述定义是“组成派”软件架构概念的典型代表,有如下两个显著特点:
  • 关注架构实践中的客体——软件,以软件本身为描述对象;
  • 分析了软件的组成,即软件由承担不同计算任务的组件组成,这些组件通过相互交互完成更高层次的计算目的。

  软件架构概念:决策派

  下面来看看RUP(Rational Unified Process,Rational统一过程)为软件架构下的定义:

  软件架构包含了关于以下问题的重要决策:
  • 软件系统的组织;
  • 选择组成系统的结构元素和它们之间的接口,以及当这些元素相互协作时所体现的行为;
  • 如何组合这些元素,使它们逐渐合成为更大的子系统;
  • 用于指导这个系统组织的架构风格:这些元素以及它们的接口、协作和组合。
  软件架构并不仅仅注重软件本身的结构和行为,还注重其他特性:使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制及权衡、以及美学等。

  上述定义看似冗长,其实核心思想非常明确:软件架构是在一些重要方面所做出的决策的集合。

  该定义是“决策派”软件架构概念的典型代表,有如下两个显著特点:
  • 关注架构实践中的主体——人,以人的决策为描述对象;
  • 归纳了架构决策的类型,指出架构决策不仅包括关于软件系统的组织、元素、子系统、架构风格等的几类决策,还包括关于众多非功能需求的决策。

  深入解析:找准软件架构的位置

  既然窗帘是用来遮光的,为什么非要用一整块布呢?于是百叶窗发明了。

  既然建模有助于认清复杂问题,为什么非守着软件架构的“文字定义”方式不放呢?于是我们开始了下面“模型驱动”的思辨过程。

  从Shaw的架构概念开始

  “软件系统的架构将系统描述为计算组件及组件之间的交互”,Shaw的这个定义从“软件组成”角度解析了软件架构的要素:组件、以及组件之间的交互。通过UML类图,我们可以将这个关系表达得更加清晰,参见图1。如图所示,组件和组件之间可以有交互关系,图中的“交互”采用了关联类的语法。

       

        图1    软件架构的要素:组件、以及组件之间的交互

  Shaw的架构定义高度抽象地将软件架构概括为“组件+交互”,我们有必要举例说明之——就以大家熟悉的MVC为例吧(如图2所示):

  采用MVC架构的软件会包含了这样三种组件:Model、View、Controller。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12639375/viewspace-150453/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-01-04

  • 博文量
    188
  • 访问量
    375140