大多数工程师,尤其是稍有经验的工程师,都直观地认为软件体系结构是一个容易理解的概念,但是很难确切地定义。明确区分设计和体系结构尤其困难,体系结构是设计的一个方面,它着重于某些具体的特性。
在软件体系结构的简介中,David Garlan 和 Mary Shaw 提出,软件体系结构是某一层面的设计,它涉及以下问题:“超越计算的算法和数据结构,设计并指定整个系统结构成为了新一类的问题。
结构问题包括整个组织和全局控制结构;关于通信、同步和数据访问的协议;向设计元素分派功能;实际分发;组装设计元素;规模缩放和性能;以及设计备用项的选择。”[GAR93]
但是对体系结构而言,要考虑的就不仅是结构了;IEEE 体系结构工作组(IEEE Working Group on Architecture)将其定义为“体系结构环境中系统最高层次的概念”[IEP1471]。它还包括对系统完整性、经济约束、美学观念和风格的“适合性”。体系结构不限于内在焦点,而要考虑用户环境和开发环境中的整个系统 - 外在焦点。
在 RUP 中,软件系统的体系结构(在给定点)是系统中众多重要组件的组织或结构,这些组件通过接口与由更小的组件和接口相继组成的组件交互。
要说明并理解软件体系结构,您必须先定义一种体系结构表示法,它是一种描述体系结构重要方面的方式。在 RUP 中,该描述是记录在软件体系结构文档中的。
我们已选择在多个体系结构视图中展示软件体系结构。每个体系结构视图都针对了开发流程中特定于项目干系人(用户、设计人员、经理、系统工程师、维护人员等)的一组具体问题。
视图通过显示软件体系结构如何分解为组件以及连接器如何连接组件以生成有用的格式 [PW92],来获取主要的结构设计决策。 这些设计选项必须遵循需求约束、功能约束、补充约束和其他约束。但是反过来,这些选择对需求以及未来较低层次的设计决策进行了进一步的约束。
体系结构用一些不同的体系结构视图表示,这些视图实际上是说明“对体系结构有重要意义”模型元素的选萃。在 RUP 中,首先是一组称为“4+1 视图模型”的典型视图 [KRU95]。它的组成为:
-
用例视图,它包含用例和场景,这些用例和场景含有重要体系结构行为、类或技术风险。它是用例模型的子集。
-
逻辑视图,它包含最重要的设计类、包和子系统中类的组织,以及各层中这些包和子系统的组织。它还包含某些用例实现。它是设计模型的子集。
-
实施视图,它包含实施模型的概述,以及按模块划分为包和层的模型组织。还描述了从“逻辑视图”将包和类分配到“实施视图”中的包和类。它是实施模型的子集。
-
流程视图,它包含所涉及任务(进程和线程)的描述、任务的交互和配置以及从设计对象和类到任务的分配。仅当系统具有相当并行程度时,才需要使用该视图。在 RUP 中,它是设计模型的子集。
-
部署视图,它包含对最典型平台配置的多个实际节点的描述,以及从“流程视图”将任务分配到实际节点。仅当系统为分发式系统时,才需要使用该视图。它是部署模型的子集。
体系结构视图记载在软件体系结构文档中。您可设想额外的视图来表达不同的特殊关注点:用户界面视图、安全视图、数据视图等。对于简单的系统,您可以省略 4+1
视图模型中包含的某些视图。
尽管上述视图可代表系统的整个设计,但是体系结构本身只涉及几个具体的方面:
-
模型的结构 - 组织模式,例如分层。
-
基本元素 - 关键用例、主要类、常见机制等(与模型中的所有元素相对而言)。
-
显示系统范围内的主要控制流的一些关键场景。
-
用以获取模块性、可选特性和产品线的服务。
本质上,体系结构视图是整个设计的抽象或简化,其中重要特征的详细信息被略去,以使这些特征更为直观。当探讨以下问题时,这些特征是很重要的:
-
系统发展,进入下一个开发周期。
-
在产品线环境中重用体系结构或体系结构的某些部件。
-
评估补充品质,例如性能、可用性、可移植性和安全。
-
将开发工作分配给团队或转包商。
-
关于包括现成组件的决策。
-
插入更宽泛的系统。
体系结构模式是解决重现的体系结构问题的现成形式。体系结构框架或体系结构基础结构(中间件)是您可用以构建某种体系结构的一组组件。许多主要的体系结构难题都应在框架或基础结构中解决,这些难题通常以具体的领域(命令和控件、MIS、控制系统等)为目标。
体系结构模式示例
[BUS96] 根据体系结构模式最适用的系统特征对体系结构模式进行分组,其中每一类别都对应较常见的结构化问题。该表显示了 [BUS96] 中提出的类别以及这些类别包含的模式。
类别
|
模式
|
结构
|
层
|
Pipes and Filters
|
Blackboard
|
分发式系统
|
Broker
|
交互式系统
|
Model-View-Controller
|
Presentation-Abstraction-Control
|
适用的系统
|
Reflection
|
Microkernel
|
在此将更详细地说明其中的两种模式,以阐明这些观点;关于完整的阐释,请参阅 [BUS96]。这些模式是采用以下广泛使用的形式来说明的:
模式名称
层
环境
需要分解的大型系统。
问题
必须按不同的抽象程度来处理问题的一个系统。例如:硬件控制问题、常见服务问题和特定于领域的问题。 如果要编写处理所有级别问题的纵向组件,那将是非常没有必要的。 同样的问题将不得不在不同组件中多次处理(有可能不一致)。
影响力
-
系统的部件应是可替换的。
-
组件的更改不应引起连锁反应。
-
相似职责应组织在一起。
-
组件的大小(复杂组件可能必须分解).
解决方案
将系统构化为几组组件,这些组件相互堆叠成层。使靠上的层仅可使用其下的层的服务(绝不能向上使用)。尽量使用紧挨的下一层的服务(不要跳层使用,除非中间层仅补充直通的组件)。
示例:
1. 一般层
严格分层的体系结构规定,设计元素(类、包、子系统)仅使用其下方的层的服务。服务可包括事件处理、错误处理、数据库访问等。 与底层中记录的原始操作系统级别调用相比,它包含了更具体的机制。
2. 业务系统层
上图显示了另一分层示例,其中存在特定于应用程序的纵向层以及横向的基础结构层。注意,目标是拥有极短的业务“管道”并充分利用应用程序中的共同性。 否则,可让多人解决同一问题,解决方法可能有所不同。
关于该模式的更多讨论,请参阅指南:分层。
模式名称
Blackboard
环境
一个域,其中尚不知道或没有可行的任何封闭(算法)方法来解决问题。示例为 AI 系统、语音识别和监视系统。
问题
多个问题解决代理程序(知识代理程序)必须协作起来才能解决任一代理程序无法解决的问题。各代理程序的工作结果必须可供所有其他代理程序访问,这样它们就可判断是否对找到解决方案有帮助并公布它们的工作结果。
影响力
-
知识代理程序可帮助解决问题的序列并不具有确定性,且可能取决于问题解决策略。
-
不同代理程序的输入信息(结果或部分解决方案)可能有不同的表示法。
-
代理程序并不直接知道彼此的存在,但可以评估彼此的公布结果。
解决方案
许多知识代理程序可访问名为 Blackboard 的共享数据存储。Blackboard 提供检查和更新其内容的接口。控制模块/对象按照某种策略来激活代理程序。 一旦激活,代理程序将检查
Blackboard,以查看它是否对解决问题有所帮助。如果代理程序确定它有助于问题的解决,控制对象可允许代理程序将其部分(或最终)解决方案输入到 Blackboard 上。
示例:
这显示了使用 UML 建模的结构视图或静态视图。这将成为参数化协作的一部分,然后将结合实参来对模式进行实例化。
软件体系结构,或只是体系结构视图,可能具有被称为体系结构风格的属性,这将减少要选择的一批可能的形式,并对体系结构强加一定程度的统一性。风格可通过一组模式、通过选择特定的组件或连接器作为基本构建块来定义。对于给定的系统,可将某种风格作为体系结构描述的一部分而记录在
体系结构风格指南(通过 RUP 中的 特定于项目的指南工作产品提供)中。风格在体系结构的可理解性和完整性方面起主要作用。
体系结构视图的图形描绘被称为体系结构蓝图。对上述的多种视图而言,蓝图是由统一建模语言(Unified Modeling Language)[UML01]
中的以下各图组成的:
在 RUP 中,体系结构主要是分析与设计工作流程的输出结果。由于项目在每次迭代后均重新制定该工作流程,所以体系结构将趋于完美。因为每次迭代都包含集成和测试,所以体系结构在产品交付时已相当强健。该体系结构是精化阶段中各迭代的主要焦点,该阶段结束时体系结构通常已设置了基线。
|