用户需求模式

(一)模式

模式的概念最早是由著名的建筑学家Christopher Alexander提出的。他在建筑学研究中发现,在不同时代伟大的建筑师们所留下的建筑作品中,有很多重复出现的设计,于是他从建筑学角度出发,研究建筑物的通用结构,捕捉可重用的部分并尝试用形式化的方法对其加以描述,期望在建筑结构设计中能达到设计的自动化、标准化和规范化。他为这些描述的结果起了一个名字叫模式(pattern)。他在《The Timeless Way of Building》一书中指出:“模式是在同一时间里发生在世界上的一切事物和如何创建这个事物以及我们何时必须创建它的规则。它既是一个过程,又是一个事物;既是一个活生生事物的描述,又是产生那个事物的过程描述”。

之后,随着模式应用领域的进一步扩展,人们对于模式的认识也逐步走向全面和深入,各种各样关于模式的解释和描述应运而生。

在《Webster》大字典中,模式被定义为:一种被认可的、原创的、为模仿而提出的模型或标准实例的形式。R.Johnson认为模式就是成对的“问题-解决方案”,它倾向于形成相似的“问题-解决方案”的系列,且每一个系列体现一种在问题和解决方案中的模式。Michaiel A.Beedle认为每一个模式描述了一个在我们周围不断重复发生的问题以及该问题的解决方案的核心。这样你就能一次又一次地使用该方案而不必做重复劳动。Palepu认为所谓模式就是在特定场合下,对特定问题的惯用解决方案。Stephen P.Berczuk认为模式是指从某个具体的形式中得到的一种抽象,在特殊的非任意环境中,该形式不断地重复出现。E.Gamma等认为每个模式是一条由三部分组成的规则,它表示了一个特定的环境、一个问题和一个解决方案之间的关系。P.S.C.Alencar等认为模式是在特定上下文情形下对某一特定问题的经反复验证的解,其中的解包括解决策略、依据、组成部件、部件的职能及相互关系、部件间的协同方式等。

模式表达就是通过一定的方式对模式所包含的基本内容进行描述。模式表达的方式目前主要有:非形式化描述(主要是语言文字形式)、半形式化描述(语言文字＋数学模型形式、语言文字＋计算机语言形式等)和形式化描述(数学模型形式、计算机语言形式等)3种。在模式所表达的内容组成上,现在主要有如下一些方式:

Alexander将模式用一个三元组来描述,即给定上下文、问题以及解之间的关系。所谓上下文(context)是指产生某一问题的情形。问题(problem)是指在上下文情形下反复出现的待解问题,它包含一系列设计要素,即解决问题必须考虑的各个方面,诸如解的部分所必须满足的要求,必须考虑的约束条件以及解应该具备的特性等。解(solution)是指对这一类问题经反复验证的成功解决方案。

E Gamma和R Helm分4个部分对一个模式进行描述,即①模式名称:用于描述一个问题,其解决方案和后果的词。它使人们可以在更高的抽象层次上进行设计并交流设计思想。②问题:描述何时使用模式,解释问题及其背景,还可以包括该模式的适用条件。③解决方案:描述设计的基本要素、它们的关系、各自的任务以及相互之间的协作。因为模式更像一个模板,能够被用于很多不同的场景,所以解决方案并不描述一个具体的设计与实现。④后果:描述应用该模式所得到的效果和所需要做的权衡取舍。

采用五元组来描述模式:

模式(pattern)＝[名称(name)、上下文(context)、解决的问题(problem)、解(solution)、结果(consequences)]

其中

名称:模式的标识,表明该模式的核心内容。

上下文:模式使用的环境和前提条件。

解决的问题:说明模式主要用于解决哪类问题以及选择该模式的原因。

解:一般采用结构化的方式描述模式的结构和行为。

结果:模式使用的效果,存在的主要问题,可选择的其他模式。

为了完整说明较为复杂领域中的模式内容,Scott Ambler在定义过程模式时,把模式表达分成十二部分。

名称:模式的名称。

别名:模式的另一个名称。

意图:模式内容的简要叙述。

上下文:模式的动机。

示例:通常是基于案例研究展开的。

问题:对模式所处理问题的简要描述。

方法:各种解决方案,有不同的侧重点,同样是基于案例研究的。

解决方案:模式对问题的推荐解法的简要描述。

何时使用(或何时不使用):是否使用模式的思考,一般是研究基于案例的。

适用性:是否使用模式的简要描述。

已知应用:模式曾经的应用之处。

相关模式:和当前模式相关的其他模式以及它们的关系。

当对一个特定领域模式进行描述时,应该采用何种描述方式和内容结构,需要根据该领域问题的应用特点来决定。只要是能清晰地表达出模式的主要内容,便于使用者理解和使用,都可称为一个完整的模式表达方式。

模式目前主要应用在软件工程领域,在软件工程领域,受到普遍认可的模式定义是由Dirk Riehle和Heinz Zullighoven给出的。他们认为,软件模式是指在特定的环境中,从某个具体的、重复发生的形式中得到的一种抽象。在短短的几年中,模式在软件工程领域中的应用已经有了较快的发展,不仅各种不同类型的模式纷纷出现,而且其应用也日渐成熟,应用范围不断扩大。目前在信息系统领域中模式已拥有多种类型,如软件系统模式、分析模式、过程模式、反模式等。其中最基础的也是应用最成熟的当属设计模式,它已成为模式在信息系统领域中成功应用的典范。设计模式(design pattern)提供一个用于细化软件系统的子系统或组件,以及它们之间关系的图式。它描述了通信组件的公共再现结构,通信组件可以解决特定语境中的一个一般设计问题。通俗地讲,设计模式是一类被用来在特定场景下解决一般软件设计问题的通用解决方案。它是对面向对象设计专家设计经验的总结,描述了一般设计问题的方案和效果,其价值在于重用抽象的、通用的面向对象设计思想来解决具体的设计问题。在软件系统模式中,设计模式属于中等抽象层次,它描述的是系统中局部(子系统及部件)的结构和行为。设计模式是一种高级软件复用技术。在面向对象软件设计中,一个设计模式系统的命名、抽象、解释和评价了一个通用设计结构的主要方面,这些设计结构能被用来构造可重用和支持特定形式变化的面向对象设计。设计模式确定了所包含的类和实例,它们的角色、协作方式以及职责分配。每一个设计模式都集中于一个特定的面向对象设计问题或设计要点,描述了什么时候使用它,在另一些约束条件下是否还能使用以及使用的效果和如何取舍。为了方便设计模式的使用,在《Design Patterns》一书中,Gamma等依据“目的”准则(即模式是用来完成什么工作的)以编目分类的形式把设计模式分成三大类,即创建型模式(creational)、结构型模式(structural)和行为型模式(behavioral)。创建型模式主要用于对象的创建;结构型模式主要用于处理类或对象的组合;行为型模式主要对类或对象怎样交互和怎样分配职责进行描述。在此基础上又进一步归纳细分出23种常见的设计模式。

从上述的概念和应用中可以看出,模式并非是人类发明和创造的新东西,而是对有经验的实践者所拥有的知识或经验的提炼、总结和重用。它其实是解决一系列类似问题的一种共同机制。它关注的是那些在不同的应用领域中,以不同的面貌重复出现,而实质却相同的东西,通常采用一种公共的词汇和形式对其加以描述。如今模式之所以被人关注,是因为它在收集和表达已有的经验和知识方面以易于获得的方式和所希望的良好的书写格式捕获了那些已被证实的解决方案,因而容易被人们所理解和应用。

(二)用户需求模式的结构及其与用户需求模型的映射关系

用户需求模型是用户需求层理论的抽象表达,在实际的过程中,还需要具体形式表达的分析结果,这就是用户需求模式。用户需求模式是需求重用的重要手段。用户需求模式是对过往经验的总结与规范化,通过用户需求模式的匹配和重用,能够指导获取、分析用户需求的过程,并且能够快速、准确的定位满足用户需求的领域服务。在RDAA的用户需求层中引入用户需求模式,既能够发挥模式对于一类问题的指导作用,又能够指引具体的用户需求在体系结构中的运行,是用户需求层知识的主要组成部分。

RDAA中的用户需求模式与软件工程领域中模式的概念有相似之处,也存在着很大的不同。相似之处体现在用户需求模式是对经常出现的案例的规范化表达,是对一类知识的总结;而不同之处在于,用户需求模式是具体的,可以实现的。由于用户需求模式是根据用户需求模型对用户需求进行分析的结果,因此,用户需求模式是以用户需求模型为参考。但是,为了实现的便利以及与领域服务层的交互,还需要进行进一步的信息补充和重构。

进行需求分析,首先需要识别用户。按照用户需求模型,用户分为系统投资者(investor)、系统所有者(owner)、系统建设者(builder)和客户(customer);系统建设者进一步细分为系统设计者(designer)、编程人员(programmer)和维护人员(repairer),如果系统建设需要外包,还有承包商(subcontractor);客户进一步细分为外部客户(outer customer)和内部客户(inner customer)。因此,按照用户需求模型进行需求分析,得到的结果如下。

＜User＞

＜Investor＞＋

＜Owner＞

＜Builder＞

＜Designer＞

＜Programmer＞?

＜Repairer＞?

＜Subcontractor＞*

＜Customer＞

＜InnerCt＞*

＜OutterCt＞*

下一步,需要识别目标。按照用户需求模型,目标既有总体目标(overall objective),又有业务目标(business objective)和信息技术目标(i T objective)。而业务目标既有社会目标,也有组织目标和个人目标。因此,按照用户需求模型进行需求分析,得到的结果如下。

＜Objective＞

＜Overall Ob＞

＜BusinessOb＞＋

＜Content＞

＜Type＞

＜ITOb＞＋

对于业务目标的类型,用户需求模式通过如下的类型定义,实现与用户需求模型的映射,Schema片断如下。

＜xs:element name＝“Type”type＝“tBusinessOb”/＞

＜xs:simple Type name＝“t BusinessOb”＞

＜xs:restriction base＝“xs:string”＞

＜xs:enumeration value＝“Social Ob”/＞

＜xs:enumeration value＝“Organizational Ob”/＞

＜xs:enumeration value＝“Individual Ob”/＞

＜/xs:restriction＞

＜/xs:simple Type＞

下一步,需要分析任务。任务是指为了实现目标,用户要求系统完成的工作。按照用户需求模型,任务分为核心任务(core assignment)和辅助任务(aided assignment)。在用户需求模式中,不会对任务的详细流程、功能和数据进行分析,领域服务层将根据用户需求层的任务来组织相应的服务,调用业务流程;业务流程层将根据领域服务层的流程要求,细化流程,组织功能实现流程。因此,用户需求模式只需要包括任务的内容、输入和输出即可。

＜Assignment＞＋

＜Content＞

＜Type＞

＜Input＞*

＜Content＞

＜Type＞

＜Output＞*

＜Content＞

＜Type＞

对于任务的类型,用户需求模式通过如下的类型定义,实现与用户需求模型的映射,Schema片断如下。

＜xs:element name＝“Type”type＝“t Assignment Type”/＞

＜xs:simpleType name＝“t Assignment Type”＞

＜xs:restriction base＝“xs:string”＞

＜xs:enumeration value＝“Core As”/＞

＜xs:enumeration value＝“Aided As”/＞

＜/xs:restriction＞

＜/xs:simple Type＞

下一步,需要分析环境。按照用户需求模型,环境分为社会环境(social environment)和技术环境(i T environment)。技术环境进一步细分为网络环境(Network)、硬件环境(hardware)、软件环境(software)、操作系统环境(operation system)和用户认知程度(understand);软件环境又可细分为操作系统(operation system)、应用服务器(server)和数据库管理系统(database management system)。因此,按照用户需求模型进行需求分析,得到的结果如下。

＜Environment＞

＜SocialEv＞*

＜ITEv＞

＜Network＞＋

＜Hardware＞＋

＜Software＞

＜OS＞＋

＜Server＞＋

＜DBMS＞＋

＜Understand＞?

下一步,需要分析知识。知识是用户需求层的基础,用户需求层的运行依赖于知识是否可靠和全面。在用户需求模型中,知识包括本体(ontology)和规范(norm),这两类知识的获取和表达已经在本文的第四篇中进行介绍。在用户需求分析阶段,按照相应的方法获取与系统有关的本体和规范,用OWL和NDL表达,并将其嵌入到用户需求模式中。用户需求层的规范有3种类型,即社会规范(social norm)、组织规范(organizational norm)和运作规范(operational norm)。因此:

＜Knowledge＞

＜Ontology＞*

＜Norm＞*

＜Content＞

＜Type＞

对于规范的类型,用户需求模式通过如下的类型定义,实现与用户需求模型的映射,Schema片断如下。

＜xs:element name＝“Type”type＝“t Norm”/＞

＜xs:simpleType name＝“t Norm”＞

＜xs:restriction base＝“xs:string”＞

＜xs:enumeration value＝“Social Norm”/＞

＜xs:enumeration value＝“Organizational Norm”/＞

＜xs:enumeration value＝“Operational Norm”/＞

＜/xs:restriction＞

＜/xs:simple Type＞

下一步,需要分析元素之间的关系。按照用户需求模型,主要是任务和目标之间的关系(R1)、环境和目标之间的关系(R2),因此:

＜Relation＞

＜R1＞*

＜Objective＞＋

＜Assignment＞＋

＜R2＞*

＜Objective＞＋

＜Environment＞＋

随后,需要在时间因素下,分析系统可能的变化。按照用户需求模型,对于用户、目标、任务、环境和知识要分析今后可能的变动,对于元素之间的关系要重新进行分析,因此:

＜Time＞

＜UF＞*

＜OF＞*

＜AF＞*

＜EF＞*

＜KF＞*

＜RF＞*

最后,需要按照用户需求模型进行需求分析,得到用户需求模式的ID、名称、领域和相关模式,并对其进行总结和说明。

＜ID＞

＜Name＞

＜Domain＞

＜Related URP＞*

＜ID＞

＜Name＞