GB T 26239-2010 软件工程 开发方法元模型.pdf

1、GB ICS 35. 080 L77 . 和国国家标准=lI工/、中华人民GB/T 26239-20 1 O/ISO/IEC 24744 :2007 开发方法元模型软件工程Software engineering Metamodel for development methodologies CISO/IEC 24744:2007 ,IDT) 2011-05-01实施2011-01-14发布发布中华人民共和国国家质量监督检验检茂总局中国国家标准化管理委员会AV曹iho飞KURdhqSRz mh【川30二，5652 60吨7eF/二4ua萨-dH as伪创刊罹GB/T 26239-2010/IS

2、O/IEC 24744 :2007 目次前言. 1 引言.II l 范围-1. 1 目的-1. 2 读者2 符合性. 3 术语和定义4 命名、图示和定义的约定及缩略语34. 1 命名、图示和定义的约定34.2 缩略语45 基本概念45. 1 方法工程5. 2 双层建模-5. 3 强类型和类对象5. 4 过程和产品的联合55.5 过程评估6 SEMDM引i仓66. 1 高级别抽象视图6. 2 抽象视图和核心类. 6. 3 过程类6.4 生产者类96. 5 产品类96. 6 过程和产品的连接106. 7 支持类7 元模型元素7. 1类117.2 枚举类型508 元模型的采用8. 1 用法规则8.

3、2 用法指南529 对元模型的扩展539. 1 扩展规则539.2 扩展指南M附录A(资料性附录)实用示例55附录B(资料性附录)到其他元建模途径的映射61参考文献.66 GB/T 26239一201 O/ISO/IEC 24744 :2007 目。昌本标准使用翻译法等同采用ISO/IEC24744:2007(软件工程开发方法元模型机英文版)。本标准的附录A和附录B是资料性附录。本标准由全国信息技术标准化技术委员会CSAC/TC28)提出并归口。本标准起草单位:上海超算并行软件有限责任公司、复旦大学、中国电子技术标准化研究所。本标准主要起草人:袁俊、吴毅坚、赵文耘、王宝艾、钱乐秋、何志峰、彭鑫

4、、冯惠、王秀娟。I G/T 26239-20 1 O/ISO/IEC 24744 :2007 引开发方法可在基础元模型的语境中进行描述，但以相应的元模型定义这些方法的精确机制通常难以阐明，且不能涵盖所有的需要。例如，难以设计这样一种实践，该实践在允许定义构成方法的各元素的性质的同时，还能定义在应用这些方法时所创建的实体(如工作产品)。本标准介绍了软件工程开发方法元模型CSEMDM，SoftwareEngineering Metamodel for Development Methodologies)。这是一种综合性的元模型;它利用了基于强类型概念定义方法的一种新途径。SEMDM旨在基于信息的领

5、域中定义方法。所谓基于信息的领域是以强烈依赖于信息管理和信息处理为表征的这样一些领域，如软件、业务或系统工程。SEMDM将其他元建模途径的主要优点结合起来，并去除了其己知的不足，使方法中过程、建模以及人的方面达到无缝集成。附录B将其他元模型映射到SEMDM上，并提供了一个简要的问题大纲。越来越多的标准中定义、使用或隐含了各种各样的方法，将每个方法中所用的概念协调起来非常值得。协调化的一个载体就是SEMDM。对该元模型的符合性将确保以一致的途径、一致的概念和术语来定义每个方法。E G/T 26239一2010/ISO/IEC24744:2007 软件工程开发方法元模型1 范围本标准规定了软件工程

6、开发方法元模型。该元模型为定义和扩展基于信息的领域(IBD)(例如软件、业务或系统)的开发方法建立了一个形式的框架，其中包括三个主要的方面:所遵循的过程，所使用和生成的产品，以及所涉及的人员和工具。该元模型能用作定义和扩展任何IBD卅发方法和任何关联的元模型的形式基础，并由方法工程师典型地用于承担此类定义和扩展任务中。该元模型既不依赖于又不硬性限定IBD开发方法的任何特指途径，实际上是通用的，足以适应于任何特定的途径、例如面向对象、面向代理、基于构件的开发等。1. 1 目的本标准遵循最小深度、甚丰富广度(包容了各种由单一途径难以处置的领域)的途径。因此，它仅包括那些较高级别的、跨抨种各样r，z

7、用领域的、真正通用的概念.比现有的其他元模型的抽象级别更高。SEMDM的主要目的是交付一个高度咀用的兀模型.小会不必要地约束由此产生的方法，同时为创建丰富且具有表达能力的实例做好准备为了达到这个目标，SEMDM纳入了米自多种兀建模i主任的理在.并加入了一些近期的研究成果(见参号文献17J)寸这将促进:a) 方法工程师之间、方法工程师IjH法用户(问1汗发者)之间的沟通;b) 来自先前存在的方法片段库中的多个方法的汇编;c) 通过专门提供的扩展机制扩展标准元模型，来创li!Ji法元模刑;d) 各个方法和关联的元模型的比较和集成:e) 建模和方法支忏L具的互捉(性cSEMDM与一些已有的方法和元模

8、型的关系在附录B中说明。1.2 读者由于SEMDM中许多类表述的是实践域(与方法域相对)，可能看上去施行该方法的开发者会是该元模型的直接用户，18.事实上并非如此。SEMDM中对实践层元素建梧的类，是为方法工程师建立实践域结构和行为服务，而不是在方法施行期间在接使用。只有方法元素，即方法工程师从元模型创建的类和对象，才在实践层由开发者使用.从而既支持创建打包的方法，又支持创建经裁剪的、特定项目的方法。这里，方法工程师一词或指为特定目的创建方法的人，或指创建打包的方法、并把该方法作为收缩包装的(shrink-wrapped)过程产品的人。2 符合性依照本标准，可定义一个元模型，如果它:a) 描述

9、了该元模型中概念的范围，并涉及到第7章中所定义元素的范围;并且b) 定义了该元模型中表述的以及本标准范围内的概念与本标准相应的元素之间的映射(即，其元素不能被意图相同、但构造不同的其他元素替换)。依照本标准，可定义一个开发方法，如果它是由与本章(2符合性)第一段定义相符的元模型生成的。GB/T 26239-20 1 O/ISO/IEC 24744 :2007 依照本标准，可开发一种开发工具或工程工具，如果它实现了与本章(2符合性)第一段定义相符的元模型。如果该工具的目的涉及方法的创建，那么依照本标准，它还要实现必要的特征以使8.1中描述的机制对该工具的用户可用。如果该工具的目的涉及对元模型的扩

10、展，那么依照本标准，它还要实现必要的特征以使9.1中描述的机制对该工具的用户可用。注1:据此定义的元模型没有必要一定包含第7章定义的所有元素一一只有与上述元模型的目的相关的元素才是所要求的。注z:完全不必要显式地包含任何相关的工作产品种类或模型单元种类的详细的元模型，就能建立起对方法的符合性或对工具的符合性。只要定义从这些工作产品到SEMDM中WorkProductKind类和ModelUnitKind类的映射就足够了。3 术语和定义下列术语和定义适用于本标准。注:本标准使用内部一致的核心概念集，尽可能与其他标准(如GB/T8566 , ISO/IEC 15504等)兼容。3.1 3.2 基于

11、信息的领域information-based domain; IBD 将信息作为最有价值资产的活动领域。注:这意味着信息创建、操纵和传播是基于信息的领域中最重要的活动。软件和系统工程、业务过程再工程和知识管理都是典型的基于信息的领域。方法(学)methodology 在IBD开发工作期间要遵循的过程连同拟使用和生成的工作产品的规范，以及对所涉及的人和工具的考虑。3.3 3.4 3.5 3.6 2 注:方法规定了拟执行的过程，通常是一组相关的活动、任务和/或技术，连同在每一时刻必须被操纵(创建、使用或修改)的工作产品以及由谁来操纵，其中有可能包括模型、文档和其他输入输出。而规定必须处置的模型又隐

12、含着要定义应当用于构造该模型的基础构建块。方法method 方法(学)的同义词。注:本标准通篇使用方法(学)这一术语，而在方法工程师或方法片断等常规词组中保留术语方法。元模型metamodel 用于定义方法的概念、关系和规则的规范。实践endeavour 贯穿于方法应用过程的始终，旨在交付某一产品或服务的IBD开发工作。示例:项目、程序、基础设施职责都是实践的示例。方法元素methodology element 方法的简单组件。注:通常，方法元素包括在应用该方法时能或必须使用哪些任务、活动、技术、模型、文档、语言和/或记法的规范。方法元素互相有关，构成了一个抽象概念网。典型的方法元素有获取需求

13、、为方法书写代码(任务的种类)、需求工程、高级别建模(活动的种类人伪代码、依赖图(记法)、类、属性(模型构建块的种类)、类模型、类图、需求规约(工作产品的种类)等。3. 7 3.8 实践元素endeavour element 实践的简单组件。GB/T 26239-20 1 O/ISO/IEC 24744:2007 注:在实践的执行期间，开发者创建一些实践元素，如任务、模型、类、文档等。实践元素的例子有客户、发票(类)、名称飞年龄(属性)、17号高级别类模型(模型)、系统需求描述(文档)、第2编码周期、第3编码周期(任务)等。生成generation 由特指的元模型对方法进行定义和描述的动作。生

14、成一个方法包括使用所选的元模型解释每种方法元素的结构位置和语义。因此，可能有哪些方法元素及其如何相关，都受这一元模型的约束。通常，方法工程师实施生成来生产一个完整的、可使用的方法。3.9 方法施行enactment 为某一特指目的应用方法的动作。实践是典型的方法施行。注:施行一个方法包括使用已经生成的方法创建实践元素，并最终获得目标的IBD系统。因此，能创建哪些种类的实践元素及其如何相关，都受所使用方法的支配。通常，由技术经理与其他开发者一同实施方法施行。3. 10 方法工程师method engineer 设计、构建、扩展和维护各种方法的人。注:方法工程师通过生成、由元模型创建方法。3. 1

15、1 开发者developer 为某一特定的作业(通常是一个实践)应用方法的人。注:开发者通过方法施行应用方法。3.12 强类型powertype 另一类型(称为分区类型)的强类型，是如下的类型:其实例是该分区类型的子类型。这一定义在面向对象范型的语境中解释。例如，类TreeSpecies是类Tree的一个强类型，因为TreeSpecies的每一实例也是Tree的一个子类。3. 13 类对象c1a时ect同时既是一个类又是一个对象的双重实体。注:这一定义在面向对象范型的语境中解释。因为类对象的双重性质，所以它们展现出类的一面和对象的一面，并且在任何时刻都能以任何一面工作。强类型的实例通常被视为类

16、对象，因为它们既是对象(因为它们是一个类型强类型的实例)，又是类(分区类型的子类型)。4 命名、圈示和定义的约定及缩略语4. 1 命名、图示和定义的约定SEMDM使用不同种类的、互为补充的手段来定义。这些手段有za) 定义一一-SEMDM的每一概念都使用自然语言定义。同时，给出一个描述，包括该概念出现的语境及其最具特色的性质。对每一概念都给出了示例;b) 类图一-SEMDM所关心的概念都形式化为类。因此，使用类图显示这些类及其属性和关系。通篇使用了UML1.4. 2(即ISO/IEC19501)，但有某些值得注意的例外。首先，使用了专用记法来描绘强类型模式由强类型和分区类型之间的一条虚线及强类

17、型一端的一个实心3 GB/T 26239-2010/ISO/IEC 24744 :2007 圆点组成。其次，使用了空心菱形来描绘整体-部分关系，而不对其次要特性作任何引用(参见参考文献8J);c) 文本表一一包括了文本表来提供对属性和关系的附加描述;d) 到其他方法的映射一一一SEMDM中的每一概念与其他元建模途径中等价或类似的概念有关，这使得不同途径间的翻译更加容易。这些手段是同时使用的。这里提供了两个不同类型的类图。第6章所示的图，旨在给出SEMDM的结构全貌。设计这些图是为了给出元模型中主要的类和关系的基本思想，而并非详尽，即不显示元模型的每一个细节。另一方面，对元模型中每一个类，第7章

18、都给出了一个类图。所讨论的类被画在中心，它周围环绕着与它最近的近邻。每一幅图，连同随附的属性和关系表，确实包含了所讨论的指定类的所有细节。SEMDM的基本观点是广泛覆盖方法定义中发现的所有重大问题.同时避免对最后得到的方法的不必要的结构约束。因此，在元模型中只提供属性和关联的最小集合。通过使用强类型模式实例化(见8. 1. 2)和在元模型中使用强类型，能在方法域中轻易地添加属性和关联。4.2 缩略语IBD 基于信息的领域(information-baseddomain) SEMDM软件工程开发方法元模型(softwareengineering metamodel for development

19、 methodol ogies) 5 基本概念元模型对规定用于定义方法的概念、规则和关系是有用的。尽管有可能不通过显式的元模型来描述方法，但将所考察方法的基础思想形式化，在检查方法一致性时或在计划扩展或修改该厅法时仍是有价值的。一个好的元模型应当给出方法的所有不同的方面，即要遵循的过程，要生成的工作产品，以及那些使所有这些发生的责任者;而要规定必须开发的王作产品，其中也隐含着要定义构建这些工作产品的基本的建模构建块。元模型经常被方法工程师用来构造或修改方法。而方法又在实践的语境中被开发者用来构造产品或交付服务。在该途径中，元模型、方法和实践陶成了三个不同的专门经验域，同时这三个专门经验域对应到

20、三个不同的抽象级别和三个不同的基础概念集。开发者在实践层的工作受到所使用的方法的约束和指导的同时，方法工程师在方法层的工作受到所选择元模型的约束和指导。传统上，这些建模层一一-在此称做领域，一之间的关系被看作instance-of关系。在这样的关系中，一层或一个领域中的元素是其下层或下方领域中某个元素的实例(图1)。y在校域图1充当SEMDM语境的三个专门经验域，即领域至于方法域，必须注意到在这一级别中可存在一个以上的方法，通过精化关系相互链接。例如，组织从一个元模型创建了全组织通用的方法，然后为每个特定的实践调整和定制上述方法;这是很常见的。在这样的情形下，两个类型的方法(整个组织的和特定实

21、践的)同属于方法域，并且通过一个精化的关系连接起来(与instance-of相对)。也可能有超过两步精化的情况。GB/T 26239-20 1 O/ISO/IEC 24744 :2007 5. 1 方法工程根据上面提到的大多数元建模途径，SE肌IDM接受了方法工程的思想(见参考文献9，10J)，将元模型定义为类的集合，从这些类能生成方法块飞然后组装成一个可使用的方法口1J。然而，方法工程的手段主要用在过程领域中(因此经常使用过程工程这一名称)，而SEMDM将它扩展到建模领域(见5.2)。5.2 双层建模大多数元建模途径把元模型定义为开发者可以采用的建模语言、过程或方法的模型。遵循这个常规的途径

22、，方法工程师用元模型中的类在方法域中创建实例(即对象)，从而生成一个方法。然而，这些方法域中的对象经常被开发者当作类用于在方法施行期间创建实践域中的元素。这种显而易见的矛盾在任何一种已有的元建模途径中都没有解决，而SEMDM处置了这种矛盾并设想了一种能同时作为方法域和实践域的模型的元模型来解决这个矛盾。SEMDM在提出元模型中实践域的一个严格模型的同时，还维护了高度的灵活性，允许方法工程师配置开发过程，并且在必要时处置建模重大问题。5.3 强类型和类对象为了支持SEMDM要求的这些特征，必须引人方法建模的两个新概念。首先，同时对方法域和实践域建模，使得元模型市产生了类对，用于表示在不同分类级别

23、中的相同的概念。例如，元模型中的Document类，代表白开发者管理的文档，而元模型中的Doc旧nentKind类、代表了可由开发者管理的不同神类的文档。注意Dcument代表了实践域中的概念(人们管理的文档)，而DocumentKind代表了方法域中的概念(由方法描述的文档种类)。例如，ClassDiagram这一概念是DocumentKind的一个实例，但实践域中一个给定的类图，有特定的作者和创建时间，则是Document的)个实例。而这两个类又通过分类关系相关，因为每个文档(实践域)是某一特定文档种类(在方法域中走义)的例子(实例)。两个类的这种模式一一一个是另一个的种类一一称作强类型模

24、式，因为带有种类Jf.j缀的类(类名带有后缀Kind勺，是另一个类的强类型(强类型概念介绍见参考文献12J)。在本标准中，记号Document/怜Kind用于指通过强类型DocumentKind和分区类型Document形成的强类型模式。同时，实践层元素必须是某些方法层元素的实例，并且方法层元素必须是元模型层元素的实例。这意味着(至少某些)方法域中的元素同时充当对象(因为它们是元模型类的实例)和类(因为实践层元素是它们的实例)。文献【13J描述了这种类-对象的棍合概念，并命名为类对象。类对象既有类的一面也有对象的一面。在本标准中，类对象是用来从元模型中的强类型模式构造出方法的手段。这样，通过将

25、类对象的对象一面变为强类型模式中强类型类的一个实倒，并将类过象的类的一面变为强类型模式中分区类型的一个子类，一个强类型模式就可以实例化为一个类对象。例如，方法工程师想要在他构建的方法中支持需求规约文档，他就要(在方法域中)创建类对象RequiremntsSpecficationDocument，作为DocumentKind的实例和Document的子类。通过在方法层使用类对象，每一个需要在方法施行期间实例化的元素，通过一个适于实例化的类和一个适于通过工具进行自动操纵的对象来表示。注意强类型类的一个给定的属性如何充当该强类型模式的鉴别荐，这意味着该属性的唯一值将赋给这个强类型类的每一个实例，并且

26、此同一值将用于命名分区类型的相应子类。例如，在Document/并Kind强类型模式中，DocumentKind. Name是鉴别器。这意味着DocumentKind的每个实例的Name属性将有唯一的值，并且它的关联类CDocument的子类型)将用该值命名。紧接着前一个例子，DocumentKind的一个给定的实例，它的Name=ClassDiagram ，而Document的相应的子类将被称为ClassDiagram。这样鉴别器属性就充当了类对象两个方面的粘合剂。5.4 过程和产品的联合大多数已有的元建模途径要么关注于方法的过程一面，要么关注于方法的建模一面(即产品)。然而，这些途径中的大

27、多数都提供了一些连接点，用于插入成熟方法的(到当时为止未定义的)补充组件。SEMDM更进了一步，它提供了一个完整的元模型，均匀地覆盖了方法的过程和建模方面。如果不这样做，就如同试图定义要实施的动作而不定义这些动作必须对哪些概念发生作用(过程焦点)，或者定义要使用的概念而不知道该用这些概念做什么事情(建模焦点)。这种途径的优点是，允许在方法层为GB/T 26239-20 1 O/ISO/IEC 24744:2007 过程和由该过程生成的产品间的交互给出丰富的定义。5.5 过程评估通常，考察一个组织实施一个过程的成熟度或能力，是通过对方法施行赋予能力等级来测量的。SEMDM采用了能力等级概念，并将

28、其附加到工作单元种类上，用类WorkUnitKind的MinCapabilityLevel属性来表达。因此方法工程师可以轻而易举地建立每个工作单元种类被实施的最低的能力等级。尽管不同的评估方法和标准对能力等级有细微的差别(例子参见参考文献14J)，但下面的示例列表仍不失一般性，可适用于几乎所有情况:a) 不完全(0级)一一组织无法成功执行过程;b) 已实施(1级)一一过程成功地执行，但可能无法严格计划和跟踪;c) 己管理(2级)-一过程是有计划的，且在实施中是受跟踪的;工作产品符合规定的标准和需求;d) 己建立(3级)过程根据一个良定义的规约来实施，该规约可使用剪裁过的标准;e) 可预测(4级

29、)收集和分析过程实施的测度，导致对过程能力的定量的理解，并提高了预计实施的能力;f) 优化(5级)通过定量反馈达到针对业务目标的持续过程改进。6 SEMDM引论6. 1 高级别抽象视图从最抽象的视角来看，SEMDM定义了两个类:MethodologyElement和EndeavourElement，分别表示方法域和实践域的基本建模元素。而MethodologyElement又特化为Resource和Template，对应于在实践层原样使用的方法元素(即资源)和在实践层通过实例化使用的方法元素(即模板)3J。由于Template是方法层所有元素的抽象类型，这些元素在实践层会有实例，而Endeav

30、ourElement是这些元素的抽象超类，因此这两个类形成了一个强类型模式，其中Template是超类型，EndeavourElement是分区类型，Template. Name是鉴别符。强类型模式和它们的用法在5.3中讨论。图形描绘见图20图2SEMDM的高抽象视图同时，定义顶层类Element来泛化MethodologyElement和EndeavourElement，并且在必要时，能够跨方法域和实践域地为所有元素提供同构的处理方法。Element的DisplayText属性给出描述每个实例的、适于展示给该实例最终用户的简短文本。6.2 抽象视固和核心类核心类分为三个簇:方法模板(特化自T

31、emplate)、方法资源(特化自Resource)和实践类(特化自EndeavourElement)。Template和EndeavourElement组成的强类型模式精化为更特殊的、由这两者的子类组成的强类型模式，即:StageKind和Stage(表示一次实践中一个受管理的时间片);WorkUnitKind和WorkUnit(在一次实践中实施的或意图实施的作业); W orkProductKi时和WorkProduct (实践中关心的制品hProducerKind和Producer(有责任执行工作单元的行为主体);以及ModelU ni tKind和ModelUnit(模GB/T 262

32、39-2010/ISO/IEC 24744:2007 型的原子组件)。图形描绘见图3。固3SEMDM的抽象视圈，显示了元模型中的核心类同时，Resource特化为Language(模型单元种类的一个结构，关注于特定的建模视角)，Notation (一个具体句法，通常是图形化的，能用于描绘以某些语言创建的模型), Guideline (指示方法元素如何使用)，Constraint(在某个时间点成立或必须成立的条件)，以及Outcome(成功实施工作单元的可观察的结果)。6.3 过程类强类型模式WorkUnit/头Kind特化为Process/祷Kind(大粒度的，在给定的专门经验域内操作), T

33、ask/祷Kind(小粒度的，关注于为了达到给定目的必须做什么)，以及Technique/铃Kind(小粒度的，关注于如何达到给定的目的)。WorkUnitKind由目的和使之在实施时有意义的最小能力等级来表征，以一对多的形式与Outcome相关。因此能为每一种类的工作单元定义成果的集合。另外，WorkUnit/关Kind与Task/提Kind是整体部分关系，因此能把工作单元或工作单元种类分别定义为任务或任务种类的汇集。这就为将工作单元递归地定义到需要的细节程度留有了余地。由于独立的工作单元在特定的时间段(见下)内发生在实践域，因此类WorkUnit纳入了必要的属性来对此加以描述。然而，类Wo

34、rkUnitKind仅仅是对必须做什么的规定，而不包含对任一特定的时间片的引用，故没有时间相关的属性。图形描绘见图4。从时间方面看，Stage/提Kind特化为StageWithDuration/养Kind(一个实践中受管理的时间间隔)和InstantaneousStage/并Kind(一个实践中受管理的时间点)。而StageWithDura tion/祷Kind又特化为TimeCycle/传Kind(以最终产品或服务的交付为目标)、Phase/并Kind(以认知框架的转换为目标)和Build/祷Kind(以交付已有工作产品集合的一个增量版本为目标)0 TimeCycle/祷Kind与Stag

35、e/头Kind同样是整体部分关系，为时间周期和其他阶段的递归组合留有余地。另一方面，Phase/祷Kind和Build/祷Kind也是整体部分关系，这样任何构建或构建种类可链接到产生相应构建或构建种类的时段或时段种类。与此同时，StageWithDuration/铃Kind与Process/祷Kind关联，因此过程的时间一端可GB/T 26239-20 1 O/ISO/IEC 24744 :2007 与作业一端合适的元素相关。图形描绘见图5。F 11 11 11 11 O. I +Context 11 11 11 11 11 士:0. T H 11 11 +Component O. 十Cont

36、ext图4工作单元HHHHHHHHHHHHnHHHHHH协HMHHHHHWHH协HHHHHHHHHHHH图5阶段8 1ll11llllIll-GB/T 26239-20 1 O/ISO/IEC 24744 :2007 注:在SEMDM中以两种不同的方式达到时序和顺序。在高抽象层上，阶段种类允许方法学家定义方法的总体时间结构。从这个角度，阶段种类是可以装工作单元种类的空的容器，定义什么时候完成事情。然而在细节层上，时序和顺序不是显式地规定的，而是从关联到每一任务种类的动作种类的集合上浮现出来。任一给定的任务种类的动作种类确定了为了完成关联的任务，哪些种类的工作产品是必要的。因此，在方法施行期间的

37、任一时间点上，都可通过观察已有工作产品池和与每个候选任务种类关联的动作种类，来确定可执行任务的集合。6.4 生产者类Producer/铃Kind特化为Role/铃Kind(生产者能承担的责任的汇集)，Tool/祷Kind(帮助另一生产者以自动的方式执行其责任的器具)，以及Team/铃Kind(生产者的一个有组织的集合，一同关注于共同的工作单元)0 Producer有一个附加的子类Person，允许在实践层考虑单个的人员。Producer/关Kind总是通过WorkPerformance/头Kind与WorkUnit/并Kind相关，从而可能在工作单元与被指派的和/或负责的生产者之间建立链接。图

38、形描绘见图6。11 11 11 11 11 11 11 l川山山H川川川口山川.A阱u灿叫句uFrMu山，.皿事.&.，町l 11 11 11 11 11 11 11 11 11 H 11 11 11 11 n 11 lf 11 11 11 11 11 11 11 11 11 11 11 11 11 6.5 产晶类O +Member 吐了吗产 11 H 11 11 11 11 11 11 11 lll 1Phvs, 0.; H ，、*+Member 图6生产者4J 。*11 11 11 11 11 11 四11 I O. W orkProduct/关Kind有五种子类型:Softwarelte

39、m/头Kind，HardwareItem/长Kind(实践所关心的软件片段或硬件单元)，Model/铃Kind(为了某个良好定义的目的，充当某个主体的替代品的该主体的抽象表示)，Document/祷Kind(现实片断的持久描绘)，以及CompositeW orkProduct/祷Kind(其他元素的聚合)。尽管文档通常描绘模型，但它们也能描述其他关心的实体，甚至其他文挡。事实上，Document/祷Kind有一个到WorkProduct/头Kind的关联来表示该事实。同样，Document/头Kind对自己也有递归的整体-部分关系，因此给定一个工作产品或工作产品种类，能相应地定义为其他工作产品

40、或工作产品种类的汇集。图形描绘见图70而Model/铃Kind又与ModelUnitUsage/提Kind保持了整体甲部分关系，这也关联到一个特定的ModelUnit/头Kind。这个关系链使得我们能够描述哪些模型单元用在哪些模型中，以及它们如何被使用。另外，每个ModelUnitKind总是定义在至少一个Language的语境下。共享同一模型单元种类的不同语言为系统内形成模型单元和模型的单一互联网络留有余地，而不是形成孤立隔离的不同模型。另外，ModelKind和Language是通过一个关联直接链接的，这是为了支持如下情况:方法工程师希望GB/T 26239-20 1 O/ISO/IEC

41、24744:2007 规定某个模型种类使用哪种语言而不给出所组成的模型单元种类的详情。同样，Language和Notation是关联的，表示不同的记法支持(或能描绘)不同的语言这一事实。最后，Notation也和DocumentKind相关，表示每个文档种类采用至少一种记法。注意Language和ModelUnit/铃Kind能生成任何所需的建模语言。气| 11 H H H H 11 11 11 11 11 11 11 11 H H H H U 11 H 11 11 11 11 11 11 H =dI 0.: rHHHHHMHHHHHnnul Uses 11 11 +ParentDocumen

42、t 11 11 11 11 11 11 11 11 11 H 11 11 ). 15J一.Unified Modeling Language (UML) version 1. 4. 2. ISOjIEC 19501 :2005. International Organization for StandardizationjInternational Electrotechnical Commission, 2005. (统一建模语言). 16J一.Software Life Cycle Processes. ISOjIEC 12207: 1995. International Organiza

43、tion for StandardizationjInternational Electrotechnical Commission, 1995. (软件生存周期过程.GBjT 8566一2007. ). 66 GB/T 26239-20 1 O/ISO/IEC 24744 :2007 17J -. Software Life Cycle Processes , Amendment 2. ISO/IEC 12207: 1995/ Amd 2: 2004. In ternational Organization for Standardization/lnternational Electrot

44、echnical Commission, 2002. (软件生存周期过程(第2修正案). 18J System Life Cycle Processes. ISO/IEC 15288: 2002. International Organization for Standardization/lnternational Electrot巳chnicalCommission, 2002. (系统生存周期过程).GB/T 22032-2008. ). hOONJE寸NhE同。自OFON|白的NNH阁。华人民共和国家标准软件工程开发方法元模型GB/T 26239-2010/ISO/IEC 24744: 2007 国中E 法中国标准出版社出版发行北京复兴门外三里河北街16号邮政编码:100045网址电话:6852394668517548 中国标准出版社秦皇岛印刷厂印刷各地新华书店经销9峰印张4.5 字数132千字2011年5月第一次印刷开本880X 1230 1/16 2011年5月第一版9峰定价60.00元如有印装差错由本社发行中心调换版权专有侵权必究举报电话:(010)68533533书号:155066 1-42871 GB/T 26239-2010