概念:
|
类别 | 模式 |
---|---|
结构 | Layers |
Pipes and Filters | |
Blackboard | |
分发式系统 | Broker |
交互式系统 | Model-View-Controller |
Presentation-Abstraction-Control | |
适用的系统 | Reflection |
Microkernel |
在此将更详细地说明其中的两种模式,以阐明这些观点;关于完整的阐释,请参阅 [BUS96]。这些模式是采用以下广泛使用的形式来说明的:
层
需要分解的大型系统。
必须按不同的抽象程度来处理问题的一个系统。例如:硬件控制问题、常见服务问题和特定于领域的问题。如果要编写处理所有级别问题的纵向组件,那将是非常没有必要的。同样的问题将不得不在不同组件中多次处理(有可能不一致)。
影响力
- 系统的部件应是可替换的。
- 组件的更改不应引起连锁反应。
- 相似职责应组织在一起。
- 组件的大小(复杂组件可能必须分解)。
将系统构化为几组组件,这些组件相互堆叠成层。使靠上的层仅可使用其下的层的服务(绝不能向上使用)。尽量使用紧挨的下一层的服务(不要跳层使用,除非中间层仅补充直通的组件)。
示例:
1. 一般层
严格分层的体系结构规定,设计元素(类、包、子系统)仅使用其下方的层的服务。服务可包括事件处理、错误处理、数据库访问等。与底层中记录的原始操作系统级别调用相比,它包含了更具体的机制。
2. 业务系统层
上图显示了另一分层示例,其中存在特定于应用程序的纵向层以及横向的基础结构层。注意,目标是拥有极短的业务“管道”并充分利用应用程序中的共同性。否则,可让多人解决同一问题,解决方法可能有所不同。
关于该模式的更多讨论,请参阅指南:分层。
Blackboard
一个领域,其中尚不知道或没有可行的任何封闭(算法)方法来解决问题。示例为 AI 系统、语音识别和监视系统。
多个问题解决代理程序(知识代理程序)必须协作起来才能解决任一代理程序无法解决的问题。各代理程序的工作结果必须可供所有其它代理程序访问,这样它们就可判断是否对找到解决方案有帮助并公布它们的工作结果。
影响力
知识代理程序可帮助解决问题的序列并不具有确定性,且可能取决于问题解决策略。
不同代理程序的输入信息(结果或部分解决方案)可能有不同的表示法。
代理程序并不直接知道彼此的存在,但可以评估彼此的公布结果。
许多知识代理程序可访问名为 Blackboard 的共享数据存储。黑板提供检查和更新其内容的接口。控制模块/对象按照某种策略来激活代理程序。一旦激活,代理程序将检查黑板,以查看它是否对解决问题有所帮助。如果代理程序确定它有助于问题的解决,控制对象可允许代理程序将其部分(或最终)解决方案输入到黑板上。
示例:
这显示了使用 UML 建模的结构视图或静态视图。这将成为参数化协作的一部分,然后将结合实参来对模式进行实例化。
软件体系结构,或只是体系结构视图,可能具有被称为体系结构风格的属性,这将减少要选择的一批可能的形式,并对体系结构强加一定程度的统一性。 风格可通过一组模式、通过选择特定的组件或连接器作为基本构建块来定义。对于给定的系统,可将某种风格作为体系结构描述的一部分而记录在体系结构样式指南。风格在体系结构的可理解性和完整性方面起主要作用。
一个新兴而重要的体系结构样式示例是面向服务的体系结构(SOA):SOA 是建立在面向对象和基于组件的开发上的演进步骤,用以提供(通过服务层)与某些业务功能相似的服务,这些业务功能实现所捕获(例如在业务用例中)的全部或部分业务流程。虽然服务可以通过组件提供,但它们有合成的一面,这在于它们管理一组组件的协作(映射到较低级别的业务实体)以提供粒度更粗、价值更高的业务功能。这些想法仍在发展中,并且关于 SOA 的必要特征尚未就术语或精确度达成普遍的一致,但似乎已有某种程度的广泛接受,例如:
要进一步探索 SOA,请参阅 IBM Rational Software 白皮书“使用面向服务的体系结构和基于组件的开发来构建 Web 服务应用程序”。
体系结构视图的图形描绘被称为体系结构蓝图。对上述的多种视图而言,蓝图是由统一建模语言(Unified Modeling Language)[UML01] 中的以下各图组成的:
在 RUP 中,体系结构主要是分析与设计工作流程的输出结果。由于项目在每个迭代后均重新制定该工作流程,所以体系结构将趋于完美。因为每个迭代都包含集成和测试,所以体系结构在产品交付时已相当强健。该体系结构是精化阶段中各迭代的主要焦点,该阶段结束时体系结构通常已设置了基线。
Rational Unified Process
|