软件需求模式基础架构的解决方案

    一些类型的需求依赖于基础架构,就像错误!未找到引用源。错误!未找到引用源。中“错误!未找到引用源。“中讨论的。需求模式使我们有机会确定一种类型的需求所依赖的基础架构,而不必为某一个需求考虑。而且我们可以进一步讨论每一个基础架构——也就是当为系统需要的基础架构定义需求时必须记住的。但是它不可能非常详细,也不可能针对实际的需求,因为每个组织,每个系统的不同要求,会使需求差别极大。为了清楚起见,它们被称作基础架构概述。

 

    不能指望让每一个需求模式描述它需要的任何基础架构,这个解释的责任被给予了模式所属的领域。这是因为每个基础架构一般都会被领域中的多个模式使用。为了避免重复,每种基础架构只在一个领域中描述。本书中的每一章的模式中包含一节关于该领域的基础架构。本书讨论了三个基础架构:信息存储(错误!未找到引用源。错误!未找到引用源。),用户界面,以及报表(都在错误!未找到引用源。错误!未找到引用源。)。这几个关键概念的相互关系如图所示。

南昌软件开发公司

    Domain: 领域
    Infrastructure: 基础架构
    Requirement Pattern: 需求模式
    Depends Upon: 依赖
    需求模式,以及基础架构之间的关系:需求模式可以自由使用其他领域中的基础架构。但是最好避免相互依赖,所以如果一个领域依赖另一个领域,那么后一个领域就不应该依赖前一个领域——如果可以避免的话。一个基础架构也可以依赖另一个基础架构。

 

    基础架构概述应该说些什么呢?它的角色是指导和建议如何定义一个特定系统的基础架构的需求,提出需求需要覆盖的主题。最少,它应该陈述系统需要基础架构提供什么:它存在的目的是什么,它的主要功能。有些问题有很明显的替代解决方案,概述应该避免做判断。

 

    每个基础架构概述分成下列小节:
    1. 目的解释基础架构存在的理由,以及扮演的角色。
    2. 调用需求关于系统与基础架构如何交互的需求定义的建议——基础架构必须提供这些功能给系统——以及系统期望的其他的能力(比如访问控制)。需要的功能可以被看作是基础架构提供给调用者的接口。
    3. 实现需求为了使基础架构站得住脚所需要的一些特性的想法(例如,查询,维护和配置功能)。这些是比较简短的,只是在定义基础架构时提醒一些需要考虑的可能的主要功能域。

 

    例如,对于报表基础架构,调用需求可能是很简单:只是让系统请求运行一个选定的报表的功能。而另一方面,实现需求则相当多,包括交付报告给用户的各种方式的复杂性,其他请求报告的方式,设计报告,等等。(这些主题在错误!未找到引用源。错误!未找到引用源。进一步讨论。)以建造房屋类推,我们需要的基础架构之一是电力供应。这种情况下,调用需求是每个屋子需要多少插座,实现需求处理的是看不见的部分,像是与电网的连线,遵守建筑质量法。