目的
|
定义设计人员用来对他们的对象赋予“生命”的分析机制和服务。
|
当重点为在先启阶段执行体系结构合成时,此任务不包括此步骤。
分析机制可用自上而下(演绎法)或者自下而上(进展中发现)的方法来确定。在自上而下模式中,经验让软件设计人员知道领域中存在某些问题,需要有某些种类的解决方案。在分析期间可能会表现为机制的常见体系结构问题的示例有:持久性、事务管理、故障管理、消息传递和推理引擎。所有这些问题的共同方面是每一个都是广泛的系统类的一般功能,而且每一个提供的功能都能与基本的应用程序功能交互或者支持基本的应用程序功能。分析机制支持系统的基本功能要求中要求的功能,而不管它的部署平台或实施语言是什么。分析机制也可以用许多不同的方法进行设计和实施;一般情况下,会有多个设计机制与每个分析机制相对应,而且可能会有多种方法实施每个设计机制。
自下而上的方法用在分析机制最终生成的地方 -
当软件设计人员看见(也许一开始很微弱)各种问题的一组解决方案中显露出一个共同的主题时,分析机制得以创建。有必要提供让不同线程中的元素将它们的时间同步的方法,也有必要有分配资源的共同方法。简化分析语言的分析机制从这些模式中显露出来。
确定分析机制意味着您确定存在着一个共同的、可能是暗含的(即系统要求暗示)子问题,并且您将它命名。一开始,名称可能就是现有的名称;例如软件设计人员认识到系统将要求一个持久性机制。最后,该机制将通过类集的协作来实施(请参阅
[BOO98]),其中一些类不直接提供应用程序功能,它们的存在只是为了支持机制。 这些支持类经常位于分层体系结构的中低层,从而向所有应用程序级别的类提供共同的支持服务。
如果确定的子问题足够普通,那么或许会存在一个模式,机制可以从该模式实例化 -
通过绑定现有的类并根据模式的要求实施新的类。用这种方式制作的分析机制将是抽象的,并需要在设计和实施中进一步改进。
关于更多信息,请参阅概念:分析机制。
|