GBT26239-2010软件工程开发方法元模型.pdf 71页

'ICS35．080L77a亘中华人民共和国国家标准GB／T26239--201O／ISO／IEC24744：2007软件工程开发方法元模型2011-01-14发布Softwareengineering--Metamodelfordevelopmentmethodologies(IS0／IEC24744：2007，IDT)2011—05—01实施宰瞀粥紫瓣警糌瞥星发布中国国家标准化管理委员会及111 标准分享网www.bzfxw.com免费下载GB／T26239--2010／ISO／IEC24744：2007目次前言··⋯···⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·⋯⋯⋯⋯引言⋯⋯⋯⋯⋯⋯⋯⋯⋯···⋯·⋯⋯⋯⋯⋯⋯⋯··1范围⋯⋯⋯·⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯···1．1目的⋯⋯⋯⋯⋯·⋯⋯··⋯⋯⋯⋯⋯⋯⋯⋯·1．2读者⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·2符合性⋯⋯⋯⋯⋯⋯·⋯⋯⋯⋯⋯⋯⋯⋯⋯···3术语和定义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·4命名、图示和定义的约定及缩略语⋯⋯⋯⋯⋯·4．1命名、图示和定义的约定⋯⋯⋯⋯⋯⋯⋯⋯·4．2缩略语⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·5基本概念⋯⋯⋯⋯⋯⋯⋯⋯⋯·⋯⋯⋯⋯⋯⋯5．1方法工程⋯⋯⋯⋯⋯⋯··⋯⋯⋯⋯⋯⋯⋯-·5．2双层建模⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·5．3强类型和类对象⋯⋯⋯⋯⋯⋯⋯·⋯⋯⋯⋯5．4过程和产品的联合⋯··⋯⋯⋯⋯⋯⋯⋯⋯··5．5过程评估⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·6SEMDM引论⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯‘6．1高级别抽象视图⋯⋯⋯··⋯⋯⋯⋯⋯⋯⋯-·6．2抽象视图和核心类⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·6．3过程类⋯⋯⋯⋯··⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯··6．4生产者类⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·6．5产品类⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯-6．6过程和产品的连接⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯··6．7支持类⋯·⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·7元模型元素⋯⋯⋯⋯⋯⋯·⋯·⋯⋯⋯⋯⋯⋯⋯7．1类⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯--7．2枚举类型··⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯8元模型的采用⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯··8．1用法规则⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯··8．2用法指南⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·⋯⋯⋯⋯·9对元模型的扩展⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯··9．1扩展规则⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯··9．2扩展指南⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯··附录A(资料性附录)实用示例⋯⋯⋯··⋯⋯⋯附录B(资料性附录)到其他元建模途径的映射参考文献⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯··IⅡ●●●●23456799加¨¨u锄盯眈船船娼弭％叭∞ www.bzfxw.com刖罱GB／T26239--2010／ISO／IEC24744：2007本标准使用翻译法等同采用ISO／IEC24744：2007((软件工程开发方法元模型》(英文版)。本标准的附录A和附录B是资料性附录。本标准由全国信息技术标准化技术委员会(SAC／TC28)提出并归口。本标准起草单位：上海超算并行软件有限责任公司、复旦大学、中国电子技术标准化研究所。本标准主要起草人：袁俊、吴毅坚、赵文耘、王宝艾、钱乐秋、何志峰、彭鑫、冯惠、王秀娟。 www.bzfxw.com标准分享网www.bzfxw.com免费下载GB／T26239--2010／ISO／IEC24744：2007引言开发方法可在基础元模型的语境中进行描述，但以相应的元模型定义这些方法的精确机制通常难以阐明，且不能涵盖所有的需要。例如，难以设计这样一种实践，该实践在允许定义构成方法的各元素的性质的同时，还能定义在应用这些方法时所创建的实体(如工作产品)。本标准介绍了软件工程开发方法元模型(SEMDM，Softwaz"eEngineeringMetamodelforDevelopmentMethodologies)。这是一种综合性的元模型，它利用了基于强类型概念定义方法的一种新途径。SEMDM旨在基于信息的领域中定义方法。所谓基于信息的领域是以强烈依赖于信息管理和信息处理为表征的这样一些领域，如软件、业务或系统工程。SEMDM将其他元建模途径的主要优点结合起来，并去除了其已知的不足，使方法中过程、建模以及人的方面达到无缝集成。附录B将其他元模型映射到SEMDM上，并提供了一个简要的问题大纲。越来越多的标准中定义、使用或隐含了各种各样的方法，将每个方法中所用的概念协调起来非常值得。协调化的一个载体就是SEMDM。对该元模型的符合性将确保以一致的途径、一致的概念和术语来定义每个方法。Ⅱ www.bzfxw.com1范围GB／T26239--2010／ISO／IEC24744：2007软件工程开发方法元模型本标准规定了软件工程开发方法元模型。该元模型为定义和扩展基于信息的领域(IBD)(例如软件、业务或系统)的开发方法建立了一个形式的框架，其中包括三个主要的方面：所遵循的过程，所使用和生成的产品，以及所涉及的人员和工具。该元模型能用作定义和扩展任何IBD开发方法和任何关联的元模型的形式基础，并由方法工程师典型地用于承担此类定义和扩展任务中。该元模型既不依赖于又不硬性限定IBD开发方法的任何特指途径，实际上是通用的，足以适应于任何特定的途径，例如面向对象、面向代理、基于构件的开发等。1．1目的本标准遵循最小深度、甚丰富广度(包容了各种由单一途径难以处置的领域)的途径。因此，它仅包括那些较高级别的、跨各种各样应用领域的、真正通用的概念，比现有的其他元模型的抽象级别更高。SEMDM的主要目的是交付一个高度通用的元模型，不会不必要地约束由此产生的方法，同时为创建丰富且具有表达能力的实例做好准备。为了达到这个目标，SEMDM纳人了来自多种元建模途径的理念，并加人了一些近期的研究成果(见参考文献[1]～[7])。这将促进：a)方法工程师之间、方法工程师与方法用户(即开发者)之间的沟通；b)来自先前存在的方法片段库中的多个方法的汇编；c)通过专门提供的扩展机制扩展标准元模型，来创建方法元模型；d)各个方法和关联的元模型的比较和集成；e)建模和方法支持工具的互操作性。SEMDM与一些已有的方法和元模型的关系在附录B中说明。1．2读者由于SEMDM中许多类表述的是实践域(与方法域相对)，可能看上去施行该方法的开发者会是该元模型的直接用户，但事实上并非如此。SEMDM中对实践层元素建模的类，是为方法工程师建立实践域结构和行为服务，而不是在方法施行期间直接使用。只有方法元素，即方法工程师从元模型创建的类和对象，才在实践层由开发者使用，从而既支持创建“打包的”方法，又支持创建经裁剪的、特定项目的方法。这里，“方法工程师”一词或指为特定目的创建方法的人，或指创建“打包的”方法、并把该方法作为“收缩包装的(shrink—wrapped)”过程产品的人。2符合性依照本标准，可定义一个元模型，如果它：a)描述了该元模型中概念的范围，并涉及到第7章中所定义元素的范围；并且b)定义了该元模型中表述的以及本标准范围内的概念与本标准相应的元素之间的映射(即，其元素不能被意图相同、但构造不同的其他元素替换)。依照本标准，可定义一个开发方法，如果它是由与本章(2符合性)第一段定义相符的元模型生成的。1 www.bzfxw.com标准分享网www.bzfxw.com免费下载GB／T26239--2010／ISO／IEC24744：2007依照本标准，可开发一种开发工具或工程工具，如果它实现了与本章(2符合性)第一段定义相符的元模型。如果该工具的目的涉及方法的创建，那么依照本标准，它还要实现必要的特征以使8．1中描述的机制对该工具的用户可用。如果该工具的目的涉及对元模型的扩展，那么依照本标准，它还要实现必要的特征以使9．1中描述的机制对该工具的用户可用。注1：据此定义的元模型没有必要一定包含第7章定义的所有元素——只有与上述元模型的目的相关的元素才是所要求的。注2：完全不必要显式地包含任何相关的工作产品种类或模型单元种类的详细的元模型，就能建立起对方法的符合性或对工具的符合性。只要定义从这些工作产品到SEMDM中WorkProductKind类和ModelUnitKind类的映射就足够了。3术语和定义下列术语和定义适用于本标准。注：本标准使用内部一致的核心概念集，尽可能与其他标准(如GB／T8566，ISO／]EC15504等)兼容。3．1基于信息的领域information-basoddomain}IBD将信息作为最有价值资产的活动领域。注：这意味着信息创建、操纵和传播是基于信息的领域中最重要的活动。软件和系统工程、业务过程再工程和知识管理都是典型的基于信息的领域。3．2方法(学)methodology在IBD开发工作期间要遵循的过程连同拟使用和生成的工作产品的规范，以及对所涉及的人和工具的考虑。注：方法规定了拟执行的过程，通常是一组相关的活动、任务和／或技术，连同在每一时刻必须被操纵(创建、使用或修改)的工作产品以及由谁来操纵，其中有可能包括模型、文档和其他输入输出。而规定必须处置的模型又隐含着要定义应当用于构造该模型的基础构建块。3．3方法method方法(学)的同义词。注：本标准通篇使用“方法(学)”这一术语，而在“方法工程师”或“方法片断”等常规词组中保留术语“方法”。3．4元模型metamodel用于定义方法的概念、关系和规则的规范。3．5实践endeavour贯穿于方法应用过程的始终，旨在交付某一产品或服务的IBD开发工作。示例：项目、程序、基础设施职责都是实践的示例。3．6方法元素methodologyelement方法的简单组件。注：通常，方法元素包括在应用该方法时能或必须使用哪些任务、活动、技术、模型、文档、语言和／或记法的规范。方法元素互相有关，构成了一个抽象概念网。典型的方法元素有“获取需求”、“为方法书写代码”(任务的种类)、“需求工程”、“高级别建模”(活动的种类)、“伪代码”、“依赖图”(记法)、“类”、“属性”(模型构建块的种类)、“类模型”、“类图”、“需求规约”(工作产品的种类)等。2 www.bzfxw.comGB／T26239--2010／ISO／IEC24744：20073．7实践元素endeavourelement实践的简单组件。注：在实践的执行期间，开发者创建一些实践元素，如任务、模型、类、文档等。实践元素的例子有“客户”、“发票”(类)、“名称”、“年龄”(属性)、“17号高级别类模型”(模型)、“系统需求描述”(文档)、“第2编码周期”、“第3编码周期”(任务)等。3．8生成generation由特指的元模型对方法进行定义和描述的动作。生成一个方法包括使用所选的元模型解释每种方法元素的结构位置和语义。因此，可能有哪些方法元素及其如何相关，都受这一元模型的约束。通常，方法工程师实施生成来生产一个完整的、可使用的方法。3．9方法施行enactment为某一特指目的应用方法的动作。实践是典型的方法施行。注：施行一个方法包括使用已经生成的方法创建实践元素，并最终获得目标的]BD系统。因此，能创建哪些种类的实践元素及其如何相关，都受所使用方法的支配。通常，由技术经理与其他开发者一同实施方法施行。3．10方法工程师methodengineer设计、构建、扩展和维护各种方法的人。注：方法工程师通过生成、由元模型创建方法。3．11开发者developer为某一特定的作业(通常是一个实践)应用方法的人。注：开发者通过方法施行应用方法。3．12强类型powertype另一类型(称为分区类型)的强类型，是如下的类型：其实例是该分区类型的子类型。这一定义在面向对象范型的语境中解释。例如，类TreeSpecies是类Tree的一个强类型，因为TreeSpecies的每一实例也是Tree的一个子类。3．13类对象clabject同时既是一个类又是一个对象的双重实体。注：这一定义在面向对象范型的语境中解释。因为类对象的双重性质，所以它们展现出类的一面和对象的一面，并且在任何时刻都能以任何一面工作。强类型的实例通常被视为类对象，因为它们既是对象(因为它们是一个类型——强类型——的实例)，又是类(分区类型的子类型)。4命名、图示和定义的约定及缩略语4．1命名、图示和定义的约定SEMDM使用不同种类的、互为补充的手段来定义。这些手段有：a)定义——sEMDM的每一概念都使用自然语言定义。同时，给出一个描述，包括该概念出现的语境及其最具特色的性质。对每一概念都给出了示例；b)类图——sEMDM所关心的概念都形式化为类。因此，使用类图显示这些类及其属性和关系。通篇使用了UMLl．4．2(即IsO／IEc19501)，但有某些值得注意的例外。首先，使用了专用记法来描绘强类型模式——由强类型和分区类型之间的一条虚线及强类型一端的一个实心3 www.bzfxw.com标准分享网www.bzfxw.com免费下载GB／T26239--2010／iso／mc24744：2007圆点组成。其次，使用了“空心菱形”来描绘整体一部分关系，而不对其次要特性作任何引用(参见参考文献Es])；c)文本表——包括了文本表来提供对属性和关系的附加描述；d)到其他方法的映射——sEMDM中的每一概念与其他元建模途径中等价或类似的概念有关，这使得不同途径间的翻译更加容易。这些手段是同时使用的。这里提供了两个不同类型的类图。第6章所示的图，旨在给出SEMDM的结构全貌。设计这些图是为了给出元模型中主要的类和关系的基本思想，而并非详尽，即不显示元模型的每一个细节。另一方面，对元模型中每一个类，第7章都给出了一个类图。所讨论的类被画在中心，它周围环绕着与它最近的近邻。每一幅图，连同随附的属性和关系表，确实包含了所讨论的指定类的所有细节。SEMDM的基本观点是广泛覆盖方法定义中发现的所有重大问题，同时避免对最后得到的方法的不必要的结构约束。因此，在元模型中只提供属性和关联的最小集合。通过使用强类型模式实例化(见8．1．2)和在元模型中使用强类型，能在方法域中轻易地添加属性和关联。4．2缩略语IBD基于信息的领域(informationbaseddomain)SEMDM软件工程开发方法元模型(softwareengineeringmetamodelfordevelopmentmethodologies)5基本概念元模型对规定用于定义方法的概念、规则和关系是有用的。尽管有可能不通过显式的元模型来描述方法，但将所考察方法的基础思想形式化，在检查方法一致性时或在计划扩展或修改该方法时仍是有价值的。一个好的元模型应当给出方法的所有不同的方面，即要遵循的过程，要生成的工作产品，以及那些使所有这些发生的责任者；而要规定必须开发的工作产品，其中也隐含着要定义构建这些工作产品的基本的建模构建块。元模型经常被方法工程师用来构造或修改方法。而方法又在实践的语境中被开发者用来构造产品或交付服务。在该途径中，元模型、方法和实践构成了三个不同的专门经验域，同时这三个专门经验域对应到三个不同的抽象级别和三个不同的基础概念集。开发者在实践层的工作受到所使用的方法的约束和指导的同时，方法工程师在方法层的工作受到所选择元模型的约束和指导。传统上，这些“建模层”——在此称做“领域”——之间的关系被看作instance—of关系。在这样的关系中，一层或一个领域中的元素是其下层或下方领域中某个元素的实例(图1)。图1充当SEMDM语境的三个专门经验域，即领域至于方法域，必须注意到在这一级别中可存在一个以上的“方法”，通过精化关系相互链接。例如，组织从一个元模型创建了全组织通用的方法，然后为每个特定的实践调整和定制上述方法；这是很常见的。在这样的情形下，两个类型的方法(整个组织的和特定实践的)同属于方法域，并且通过一个精化的关系连接起来(与instance—of相对)。也可能有超过两步精化的情况。 www.bzfxw.comGB／T26239--2010／ISO／1EC24744：20075．1方法工程根据上面提到的大多数元建模途径，SEMDM接受了方法工程的思想(见参考文献[9，101)，将元模型定义为类的集合，从这些类能生成“方法块”，然后组装成一个可使用的方法[11]。然而，方法工程的手段主要用在过程领域中(因此经常使用“过程工程”这一名称)，而SEMDM将它扩展到建模领域(见5．2)。5．2双层建模大多数元建模途径把元模型定义为开发者可以采用的建模语言、过程或方法的模型。遵循这个常规的途径，方法工程师用元模型中的类在方法域中创建实例(即对象)，从而生成一个方法。然而，这些方法域中的对象经常被开发者当作类用于在方法麓行期间创建实践域中的元素。这种显而易见的矛盾在任何一种已有的元建模途径中都没有解决，而SEMDM处置了这种矛盾并设想了一种能同时作为方法域和实践域的模型的元模型来解决这个矛盾。SEMDM在提出元模型中实践域的一个严格模型的同时，还维护了高度的灵活性，允许方法工程师配置开发过程，并且在必要时处置建模重大问题。5．3强类型和类对象为了支持SEMDM要求的这些特征，必须引入方法建模的两个新概念。首先，同时对方法域和实践域建模，使得元模型中产生了类对，用于表示在不同分类级别中的相同的概念。例如，元模型中的Document类，代表由开发者管理的文档，而元模型中的DocumentKind类，代表了可由开发者管理的不同种类的文档。注意Document代表了实践域中的概念(人们管理的文档)，而DocumentKind代表了方法域中的概念(由方法描述的文档种类)。例如，ClassDiagram这一概念是DocumentKind的一个实例，但实践域中一个给定的类图，有特定的作者和创建时间，则是Document的一个实例。而这两个类又通过分类关系相关，因为每个文档(实践域)是某一特定文档种类(在方法域中定义)的例子(实例)。两个类的这种模式——一个是另一个的“种类”——称作强类型模式，因为带有“种类”后缀的类(类名带有后缀“Kind”)，是另一个类的强类型(强类型概念介绍见参考文献[12])。在本标准中，记号Docu—ment／*Kind用于指通过强类型DocumentKind和分区类型Document形成的强类型模式。同时，实践层元素必须是某些方法层元素的实例，并且方法层元素必须是元模型层元素的实例。这意味着(至少某些)方法域中的元素同时充当对象(因为它们是元模型类的实例)和类(因为实践层元素是它们的实例)。文献[131描述了这种类对象的混合概念，并命名为类对象。类对象既有类的一面也有对象的一面。在本标准中，类对象是用来从元模型中的强类型模式构造出方法的手段。这样，通过将类对象的对象一面变为强类型模式中强类型类的一个实例，并将类对象的类的一面变为强类型模式中分区类型的一个子类，一个强类型模式就可以“实例化”为一个类对象。例如，方法工程师想要在他构建的方法中支持需求规约文档，他就要(在方法域中)创建类对象RequirementsSpecificationDocument，作为DocumentKind的实例和Document的子类。通过在方法层使用类对象，每一个需要在方法施行期间实例化的元素，通过一个适于实例化的类和一个适于通过工具进行自动操纵的对象来表示。注意强类型类的一个给定的属性如何充当该强类型模式的鉴别器，这意味着该属性的唯一值将赋给这个强类型类的每一个实例，并且此同一值将用于命名分区类型的相应子类。例如，在Document／*Kind强类型模式中，DocumentKind．Name是鉴别器。这意味着DocumentKind的每个实例的Name属性将有唯一的值，并且它的关联类(Document的子类型)将用该值命名。紧接着前一个例子，DocumentKind的一个给定的实例，它的Name一“ClassDiagram”，而Document的相应的子类将被称为ClassDiagram。这样鉴别器属性就充当了类对象两个方面的粘合剂。5．4过程和产品的联合大多数已有的元建模途径要么关注于方法的过程一面，要么关注于方法的建模一面(即产品)。然而，这些途径中的大多数都提供了一些连接点，用于“插入”成熟方法的(到当时为止未定义的)补充组件。SEMDM更进了一步，它提供了一个完整的元模型，均匀地覆盖了方法的过程和建模方面。如果不这样做，就如同试图定义要实施的动作而不定义这些动作必须对哪些概念发生作用(过程焦点)，或者定义要使用的概念而不知道该用这些概念做什么事情(建模焦点)。这种途径的优点是，允许在方法层为 www.bzfxw.com标准分享网www.bzfxw.com免费下载GB／T26239--2010／ISO／IEC24744：2007过程和由该过程生成的产品间的交互给出丰富的定义。5．5过程评估通常，考察一个组织实施一个过程的成熟度或能力，是通过对方法施行赋予麓力等级来测量的。SEMDM采用了能力等级概念，并将其附加到工作单元种类上，用类WorkUnitKind的MinCapabili—tyLevel属性来表达。因此方法工程师可以轻而易举地建立每个工作单元种类被实施的最低的能力等级。尽管不同的评估方法和标准对能力等级有细微的差别(例子参见参考文献[14])，但下面的示例列表仍不失一般性，可适用于几乎所有情况：a)不完全(o级)——组织无法成功执行过程；b)已实施(1级)——过程成功地执行，但可能无法严格计划和跟踪；c)已管理(2级)——过程是有计划的，且在实施中是受跟踪的；工作产品符合规定的标准和需求；d)已建立(3级)——过程根据一个良定义的规约来实施，该规约可使用剪裁过的标准；e)可预测(4级)——收集和分析过程实施的测度，导致对过程能力的定量的理解，并提高了预计实施的能力；f)优化(5级)——通过定量反馈达到针对业务目标的持续过程改进。6SEMDM引论6．1高级别抽象视图从最抽象的视角来看，SEMDM定义了两个类：MethodologyElement和EndeavourElement，分别表示方法域和实践域的基本建模元素。而MethodologyElement又特化为Resource和Template，对应于在实践层原样使用的方法元素(即资源)和在实践层通过实例化使用的方法元素(即模板)E3]。由于Template是方法层所有元素的抽象类型，这些元素在实践层会有实例，而EndeavourElement是这些元素的抽象超类，因此这两个类形成了一个强类型模式，其中Template是超类型，EndeavourElement是分区类型，Template．Name是鉴别符。强类型模式和它们的用法在5．3中讨论。图形描绘见图2。图2SEMDM的高抽象视图同时，定义顶层类Element来泛化MethodologyElement和EndeavourElement，并且在必要时，能够跨方法域和实践域地为所有元素提供同构的处理方法。Element的DisplayText属性给出描述每个实例的、适于展示给该实例最终用户的简短文本。6．2抽象视圈和核心类核心类分为三个簇：方法模板(特化自Template)、方法资源(特化自Resource)和实践类(特化自EndeavourElement)。Template和EndeavourElement组成的强类型模式精化为更特殊的、由这两者的子类组成的强类型模式，即：StageKind和Stage(表示一次实践中一个受管理的时间片)；workunitKind和WorkUnit(在一次实践中实施的或意图实施的作业)；WorkProductKind和WorkProduct(实践中关心的制品)；ProducerKind和Producer(有责任执行工作单元的行为主体)；以及ModelUnitKind和ModelUnit(模6 www.bzfxw.com型的原子组件)。图形描绘见图3。GB／T26239--2010／ISO／IEC24744：2007图3SEMDM的抽象视图，显示了元模型中的核心类同时，Resource特化为Language(模型单元种类的一个结构，关注于特定的建模视角)，Notation(一个具体句法，通常是图形化的，能用于描绘以某些语言创建的模型)，Guideline(指示方法元素如何使用)，Constraint(在某个时间点成立或必须成立的条件)，以及0utcome(成功实施工作单元的可观察的结果)。6．3过程类强类型模式workunit／*Kind特化为Process／*Kind(大粒度的，在给定的专门经验域内操作)，Task／*Kind(小粒度的，关注于为了达到给定目的必须做什么)，以及Technique／*Kind(小粒度的，关注于如何达到给定的目的)。workunitKind由目的和使之在实施时有意义的最小能力等级来表征，以一对多的形式与Outcome相关。因此能为每一种类的工作单元定义成果的集合。另外，WorkUnit／*Kind与Task／*Kind是整体一部分关系，因此能把工作单元或工作单元种类分别定义为任务或任务种类的汇集。这就为将工作单元递归地定义到需要的细节程度留有了余地。由于独立的工作单元在特定的时间段(见下)内发生在实践域，因此类workUnit纳入了必要的属性来对此加以描述。然而，类workunitKind仅仅是对必须做什么的规定，而不包含对任一特定的时间片的引用，故没有时间相关的属性。图形描绘见图4。从时间方面看，Stage／*Kind特化为StageWithDuration／*Kind(一个实践中受管理的时间间隔)和Instantaneousstage／*Kind(一个实践中受管理的时间点)。而StageWithDuration／*Kind又特化为TimeCycle／*Kind(以最终产品或服务的交付为目标)、Phase／*Kind(以认知框架的转换为目标)和Build／*Kind(以交付已有工作产品集合的一个增量版本为目标)。TimeCycle／*Kind与Stage／*Kind同样是整体部分关系，为时间周期和其他阶段的递归组合留有余地。另一方面，Phase／*Kind和Build／*Kind也是整体部分关系，这样任何构建或构建种类可链接到产生相应构建或构建种类的时段或时段种类。与此同时，StageWithDuration／*Kind与Process／*Kind关联，因此过程的时间一端可7 www.bzfxw.com标准分享网www.bzfxw.com免费下载GB／T26239--2010／ISO／IEC24744：2007与作业一端合适的元素相关。图形描绘见图5。8图4工作单元图5阶段 GB／T26239--2010／ISO／IEC24744：2007注：在SEMDM中以两种不同的方式达到时序和顺序。在高抽象层上，阶段种类允许方法学家定义方法的总体时间结构。从这个角度，阶段种类是可以装工作单元种类的“空的容器”，定义什么时候完成事情。然而在细节层上，时序和顺序不是显式地规定的，而是从关联到每一任务种类的动作种类的集合上浮现出来。任一给定的任务种类的动作种类确定了为了完成关联的任务，哪些种类的工作产品是必要的。因此．在方法施行期间的任一时间点上，都可通过观察已有工作产品池和与每个候选任务种类关联的动作种类，来确定“可执行”任务的集合。6．4生产者类Producer／44-Kind特化为Role／-)6Kind(生产者能承担的责任的汇集)，Tool／*Kind(帮助另一生产者以自动的方式执行其责任的器具)，以及Team／*Kind(生产者的一个有组织的集合，一同关注于共同的工作单元)。Producer有一个附加的子类Person，允许在实践层考虑单个的人员。Producer／*Kind总是通过WorkPerformance／*Kind与workunjt／*Kind相关，从而可能在工作单元与被指派的和／或负责的生产者之间建立链接。图形描绘见图6。图6生产者6．5产品类WorkProduct／*Kind有五种子类型：Softwareltem／*Kind，HardwareItem／*Kind(实践所关心的软件片段或硬件单元)，Model／*Kind(为了某个良好定义的目的，充当某个主体的替代品的该主体的抽象表示)，Document／*Kind(现实片断的持久描绘)，以及CompositeWorkProduet／*Kind(其他元素的聚合)。尽管文档通常描绘模型，但它们也能描述其他关心的实体，甚至其他文档。事实上，Document／*Kind有一个到workProduct／*Kind的关联来表示该事实。同样，Document／*Kind对自己也有递归的整体部分关系，因此给定一个工作产品或工作产品种类+能相应地定义为其他工作产品或工作产品种类的汇集。图形描绘见图7。而Model／*Kind又与ModelUnitUsage／*Kind保持了整体部分关系，这也关联到一个特定的ModelUnit／*Kind。这个关系链使得我们能够描述哪些模型单元用在哪些模型中，以及它们如何被使用。另外，每个ModelUnitKind总是定义在至少一个I，anguage的语境下。共享同一模型单元种类的不同语言为系统内形成模型单元和模型的单一互联网络留有余地，而不是形成孤立隔离的不同模型。另外，ModelKind和Language是通过一个关联直接链接的，这是为了支持如下情况：方法工程师希望9 标准分享网www.bzfxw.com免费下载GB／T26239--2010／ISO／IEC24744：2007规定某个模型种类使用哪种语言而不给出所组成的模型单元种类的详情。同样，Language和Notation是关联的，表示不同的记法支持(或能描绘)不同的语言这一事实。最后，Notation也和DocumentKind相关，表示每个文档种类采用至少一种记法。注意Language和ModelUnit／*Kind能生成任何所需的建模语言。图7工作产品和建模类6．6过程和产品的连接元模型中过程和产品两方面的交互通过强类型模式Action／*Kind达到。一个Action／*Kind总是在给定的Task／*Kind(过程端)实施，作用于给定的WorkProduct／*Kind(产品端)。ActionKind．Type属性的值显示特定种类的动作是否创建、修改或只是读取指定种类的工作产品。注意某些任务种类可能不实施任何动作种类。图形描绘见图8。图8动作和约束 GB／T26239--2010／ISO／IEC24744：2007ActionKind也与Constraint相关。Constraint特化为PreCondition(进行关联的动作前必须成立的条件)和P。stcondition(成功实施关联的动作后必定成立的条件)。6．7支持类除了构建方法的必要的类以外，为了方便方法工程师使用SEMDM，还有一些支持类。图形描绘见图9。图9支持类定义可复用方法片断的机制是必要的。定义Conglomerate类用于表示相关方法元素的汇集(即MethodolotyElement类的实例)。这些方法元素可由方法工程师定义，然后在不同的方法语境下复用。注意，Conglomerate也是MethodologyElement的一个子类型，因此聚结可能递归组合。同样，管理对文献源和最佳实践的引用的某些手段也是必要的。Source类表示文献项或其他信息和经验的来源，这些是方法工程师在定义方法元素时可能想使用的。Reference类充当Source和MethodologyElement之间的链接，这样就能在方法元素和源之间规定任何数目的链接。7元模型元素7．1类在本条中，SEMDM的类以字母顺序进行描述。对每个类，用斜体给出一个定义，后跟一段可选的描述。对每一个类还给出了一幅图，在元模型的直接近邻的语境中明示出正在定义的该类。然后列出该类的属性，对每个属性包括名称、数据类型和语义。属性的数据类型总是属于一种基本的简单类型(布尔型、整型、时间戳或字符串)或一种在7．2中定义的枚举类型。最后从类的视角列出该类涉及的关系，对每个关系包括：关系的名称(如果有)，在所述关系中所述类扮演的角色(如果有)，该类所关联的目标类，以及语义。7．1．1Action(动作类)动作是一个工作产品上的由某个任务实麓的有用的事件。动作表示如下事实：完成特定的任务需要特定的工作产品。Action是EndeavourElement的抽象子类。这是一个与过程和产品相关的类。7．1．1．1属性这个类没有自身的属性。 标准分享网www.bzfxw.com免费下载GB／T26239--2010／ISO／IEC24744：2007712关系713示倒在一个软件扦发项日期间．开发者小张执行一个¨11=发任务(一个任务)会对源代码文件“Invoicecs”(一个工作产品)撇一些修改。上述的任务改变rt述的工作产品．这就是个动作。712ActianKind(动作种类类)动怍种类是1、动怍所艘的特定种类．南I．给定的动因({壬驽种类)．一给定的i体(【怍!盘：品种癸j和一特定的用法类型米击赶。动作种类描述了特定种类的任务如何使刷特定种凳的[作产品，乜辐这种用法的原始特征．即创建、修改等；町选性(关联种类的任务是否总是通过该动作种类选掸使JIl荧联种类的工作产品，或是番在某种程度上是町选的)；以及在运行关联的任务时这种工作产品种类所扮演的角色(可选)。最后一个特征在一个任务种类(通过动作种类)被多次链接到同个工作产品种类时．能用于区分不同的工作产品。鉴于此我们希望为每个动作利，类标记不同的工作产品角色。ActionKind是Template的子类。这是一个与过程和产品相关的类。7121属性一*Ⅸ∞任#种类g《☆*H∞1．作P8#粪E∞月法∞原镕#Ⅲ。目能m值M721№n¨。v。m*联∞Ⅱ*#女作月f*Ⅸ白勺I*P日#女t∞4萄面破I口r能R值Ⅱ72口☆施行Ⅻ目．Ⅱ谆#女∞自”自月关联"*冉勺工#，＆#扮演∞角色7122关系女践#十∞自”自≈Ⅷf目*城十2Z¨#十动作#类∞作#女≈镕*月f一#￡∞I*P∞#女∞ActsUD(¨1行～±镕Z动作种*总g一特≈任*#娄∞镕*无自###目＆m十某些自m cB／T26239--2010／ISO／1EC24744-20077123示例在个给定的疗法一}·．定义一个任务种类“确定、№务概念”和一个T作产品种类”业务溉念闻典”。阿青通过以下事实相关：“确定业务概念”类型的任务在执行时将会创建‘、lp务概念词典”类型的I作产品。L述关系建模为一个动作种类，其中I’ype—Create．Optionality—Mandatnry。713Build(构建类)№逄娃一t持续性阶段．其主要R标是在E经存在的I作产品集的蕈础E交付十增毓艇夺，掏建经常用于盘觋增罐的、迭代的时问J；5J期。HujId是StageWithI)uration的抽象子类。这灶个与过程卡u关的类。7131属性g称女』构a白勺％{。m据2R，掏a％镕t∞，目此％烈推荐月##r{＆￡统7132关系#称m色镕*娄女践域十∞日建≈B月f月☆域十《女∞*t均建#《7133示倒在一个软件开发项目期间，小张的团队用了两周的时问点分析、实现和测试一些新的系统特“l：。任这两周之后，他们变付r晶终的系统十部分实现。凡这些完成他们就挑选r一些新的特征进行什析，建模、实现和测试．从而构建系统的个增}，{咂水。他们反复地这样做直到系统具有所有需要的特征。立u小张的团队实施的将特征的新的集舟增错地纳入到系统中的每一短的时间跨度．都是一十杠J建。714BuildKind(构建种类类)梅建聃娄廷构建的一十特定种豢．由娃旨在牛产的结果的娄型来表短，t{uildKind足StagcWithDurationKind的于类。这星一个与过程相关的燮。7141属性这个娄没有n身的属性7142美系女＆域十日构建目g月f方女域中￡女∞某t恂建种女一裟吾蓄 标准分享网www.bzfxw.com免费下载cB／T26239--2010／ISO／1EC2474420077143示例在一个给定的方法中．定义一个构建种类“ConslructionBuil(I”来表示如下事实：当施行所述力法时，为增景地构造产品．将实施一系列的构造构建。715ComposlteWorkProduct(组合工作产品类)组合1一作产品足曲其他I作产品蚶台府戚肿工作产，精。CompositeWorkProduct是Worm’roduct的抽象子类。过是一个与产品相关的类。7151属性这个类没有自身的属性7152美系名称角色“m一⋯一m⋯“；；篙：；：三：黧“”“”“”IsMadeO[w。，kP。d。。t十组音I作F￡％自十或若f十I作，＆目成丑勺7153示例一个系统开发项目的终结时．硬仲、软件、文档的复杂配置信息被交付给客户。每一个单独发布的1作产品都能被建模为一个硬件项、个软件项或个文档；交付给客户的完整的最终产品是一个组合工作产品。710CompositeWorkProductKind(组台工作产品种娄类)组合工作产品种类是掰台工作产品所属的特定舯种类，曲共各部分舯1：作产，培种类幕襄赶；Cornposi㈣WrkProduciK】nd是WorkProd∽tKind的子类。这足一个与产品相关的娄。7161属性这个类没有自身的属性7162关系g#Classi[ies女践域十∞m☆I”P＆eB月f^＆域十￡z∞#tm音I作Ps粪女lsMadeOf一十组台I作P￡#粪&自十或若f十』*F日*娄构成的 GB／T26239--2010／ISO／IEC24744：20077163示倒在一个给定的方法中完成个项目后交付给客广的最终产品建模为一个组台I作产品种类。{寰组合包括软件和硬件项的种类驶关联的文档的种类。717Conglomerate(聚结类)聚结是艚复用于币同疗法淆墙的相关方沽无亲的汇襞。聚结提供SEMDM巾的基本的复用机制。Conglogmerate是Method()J。gyEIen⋯t的子类。这是一个支持类．7173示例在一个给定的打法中．过程种娄“质鞋保征”、文档种类‘质请标准”和“质最报告”、团队种类+质景保证团队”归人名为“质最相关片段”的聚结．这样．方法学家就能在单一步骤中简单地将该聚结纳入一个定制的方法或从一个方法中移除该聚结。718Constraint(约柬类)r个约柬是在某个时剧点上=戚-n龙学=|页成止肋条件。约束纬常Ⅲ束声明陆地描述动作的进人和退出条件。Constraint星Resource的抽象子类．特化为PreCandhiml和P卅tL、ond⋯nn。这是一十与过程和产品相盖的类。7181属性目匿3案目目g称Expressifm∞r使!勺柬成iR值“m∞真∞《4式＆《．#B十m象∞Ⅸ性，目此Tld∞}央会附iT同∞特定语女 标准分享网www.bzfxw.com免费下载GB／T26239--2010／ISO／lEC24744．20077102关系g稀角色目**^一十∞mE镕#*一给《∞∞*#类7183示例在一个给定的方法中-，庄义r个任务种类“Deliveruserdocument”和个工作产品种类UserDocumentation”。l埘者通过以下事实相关：“Deliveruserdncumenl”的任务在执行时使用“UserDncumemation”的工作产品。上述关系建模为一个．rype—ReadOnly的动作种类。然而．方法T程师要捕获这样一个要求用户文档仅在关联的“UserInterfaceSpecification”这个工作产品被批准后才交付。遮通过创建一个约束：Expression一(us盯Interf—speclflcatlonWorkProductStatuslsApproved)(前置条件)、并把诚约束附加到上述动作上．可完成这一要求。这样．该动作只有在满足条件时才被允许执行。719D0cument(文档类)文挡足对捌实中一个片断的稳窟持幺肿耕蛰。史挡经常表示模型．但也能表示其他的主体，Dncumem是WorkProduct的抽象子类。这是一个10产品相美的光。7191属性#称女Ⅻ口女|T-／evt⋯nsⅢn日女挡肿版$际m．目为女*拦#自定持A的定R∞，应该自版$∞控d7192关系g称目*娄*女实践域十*女档≈是月f方☆域中2z∞#十女％#女女档日作自些z文8∞}女#I)epicts7193示例为r组纵一次代码审查，小毒打印了待审查的代码和一份审查检查表。在审沓期问，小李记录r代码中发现的缺陷井把这些结果编辑成一十审查掇告。待审查的代码、小李所用的审查检盎表和审查报告都是文档。7110DocumenlKind(文档种娄娄)史挡袖燕娃文档的一个特定种类．由接结构．内窑娄型和目的来表征，DoeumentKind是WorkProductKind的子娄；16 这是一个与产品相关的类71101属性这个类没有自身的属性71102美系GB／T26239--2010／ISO／IEC24744：2007自e“*粪女践域十白勺女目＆％月}方＆域十2女∞某十女##粪女##娄日镕*f女档#女∞2辈Z档种类日作为些2Z档种粪白gfZ档种类女档种粪日描连些工作P￡#粪女##女使月某些镕￡∞记法71103示例在一个给定的方法中．定义文档种类“SystemRequirementsSpecification”用于表示如下事实：所述方法被施行时，该种类的文档就会被创建或使用。7111Element(元素粪)元素是元模型所关一￡·舯实体。由于SEMDM闸述片法域和实践域(见52)．田此这些领域的fE一实体都会敞SEMDM建模从而表示为一个元素。Element是一个抽象类．特化为MelhodologyElement和EndeavourEIemenl。这是一个高级别的娄。71111属性圈E雪E刍g#类Ⅻ《f向*兀紊∞&终ⅢP＆mlI勺g#或m《Ⅱi索的许多f粪十该月t白勺《自其nW性H#mm71112关系这个娄没有自身的关系。71113示例这个娄对于抽象．无法给出具体的例子。见Element的任，子类型的示例，7112EndeavourElement(实践元素粪)实践元素是属于霎艘域的元素。开发者用方法创建的仟一元索都由EndeavourE}ement表示。EndeawurElement是Elemem的抽象子类．特化为Stage、WorkUnit、TaskTechniqueMapping 标准分享网www.bzfxw.com免费下载GB／r26239—2010／ISO／IEc247442007Aorion、WorkProduct、ModelUnl这是一个高级别的类。7112{属性这个类投有自身的属性71122关系g称自E“X女*z^template女践元i总％W十方*域中定z∞某种模扳71123示例这个类过于抽象，无法给出具体的例子。见EndeavourElement的任一于类型的示例7113Guideline(指南类)指南娃在方法施行期间相何使甩一组方法凡袈的指示，Guideline是Resource的子类。这是个高级别的类。7131属性l㈣"lpn％却口“l，．0+E兰j之三兰兰J71132关系g#自色D。¨】”⋯1HMrllmlologyFhl洲☆自e*#*#方*i※％^女#71133示例在一个特定的面向代理的软件开发方法中．定义模型单元种类“Role”来表示代理在运行时可扮演的角色。由于在这个语境中的“角色”概念不同于面向对象方法中的‘角色”，因此方法J程师决定创建一个指南解释在此特定方法中模型单元种类“Role”应如何使用．并将所违指南附加到所述模型单元种类中。R茎：菌 7114Hardwareltem(硬件项类)硬件项是实戚所关心的埂，牛单元。Hardwarehem是WorkProduct的抽象于类这是个与产品相关的类。1141属性这个类没有自身的属性1142关系GB／T26239--2010／ISO／IEC247442007g#¨*女☆ZHardwarellemK[ndI。：：：+”8”4428+。8“+24”2+41143示例在个信息技术基础设施部署项目期司．许多于网络通过路由器组织和q联。缚个子网络和缚个路由器都是一个硬件项。115HardwareltemKind(硬件项种类类)硬件项种类是疆件碗的一个持定种类．由其机械和电子特性，要求和特祉米表祉，HardwareltemKind是WorkProductKind的抽象子类。这是个与产品相关的类。1151属性这个类社}有自身的属性1152关系g#*女Classifies女践域十自№#《nB月r^＆蛾中≈女M#十《*Ⅷ#女1153示例在个特定的系统开发方法中，定义硬件项种类“Network”求表示如下事实：所述靠法在施行H『．将会创建或使用酶种类的硬件项。116InstantaneousStage(瞬时阶段类)瞬时阶段是在实威中一个受管婵的时间点。瞬时阶段通常与实践过程中具有重要意义的事件材}埘府。lnstant一()usst8群是Stage的抽象于类，特化为Mile==t