CDE基本概念

面向对象问题处理的关键是建模问题。

建模可以把在复杂世界的许多重要的细节给抽象出来。

许多建模工具封装了UML（也就是Unified Modeling Language），UML中有九种建模的图标，即：用例图、类图、对象图、顺序图、协作图、状态图、活动图、组件图、配置图。

本文重点讲述类图。

为什么UML很重要？为了回答这个问题，我们看看建筑行业。

设计师设计出房子。

施工人员使用这个设计来建造房子。

建筑越复杂，设计师和施工人员之间的交流就越重要。

蓝图就成为了这个行业中的设计师和施工人员的必修课。

写软件就好像建造建筑物一样。

系统越复杂，参与编写与配置软件的人员之间的交流也就越重要。

在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”。

现在它已经成为了软件行业的一部分了。

UML提供了分析师，设计师和程序员之间在软件设计时的通用语言。

UML被应用到面向对象的问题的解决上。

想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的。

一个模型model就是根本问题的抽象。

域domain就是问题所处的真实世界。

模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的。

记住把一个对象想象成“活着的”。

对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）。

对象的属性的值决定了它的状态state。

类Classes是对象的“蓝图”。

一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）。

对象是类的实例instances。

UML中的4种关系UML 中类与类, 类与接口, 接口与接口之间的关系有: 泛化(generalization) 关系, 关联(association)关系( 关联, 聚合, 合成), 依赖(dependency)关系，实现(realization)关系.泛化(generalization)关系是一种特殊/一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象。

用这种方法，子元素共享了父元素的结构和行为。

泛化关系其实是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；在Java中此类关系通过关键字extends明确标识，在设计时一般没有争议性。

实现(realization)关系是类元之间的语义关系，其中一个类元指定了由另一个类元保证执行的契约。

它其实是一个class类实现interface接口（可以是多个）的功能；实现是类与接口之间最常见的关系；在Java中此类关系通过关键字implements明确标识，在设计时一般没有争议性；依赖(dependency)关系: 表示两个事物间的语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义。

它也是类与类之间的连接. 表示一个类依赖于另一个类的定义. 依赖关系总是单向的。

可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method方法中使用。

在java 中. 依赖关系体现为: 局部变量方法中的参数和对静态方法的调用.关联(association)关系: 表示类与类之间的联接, 它使一个类知道另一个类的属性和方法. 关联可以使用单箭头表示单向关联, 使用双箭头或不使用箭头表示双向关联,不建议使用双向关联. 关联有两个端点, 在每个端点可以有一个基数, 表示这个关联的类可以有几个实例. 常见的基数及含义:0..1: 0 或1 个实例.0..*: 对实例的数目没有限制.1: 只能有一个实例.1..*: 至少有一个实例.他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的,表现在代码层面，为被关联类B以类属性的形式出现在关联类A 中，也可能是关联类A引用了一个类型为被关联类B的全局变量；在java 语言中关联关系是使用实例变量实现的.关联关系描述的是类与类之间的连接，他表示一个类知道另一个类的属性和方法。

关联关系可以是单向的或者双向的。

在Java语言中，单向的关联关系是通过以实例变量的方式持有被关联对象的引用来实现的。

一般来说是不建议使用双向的关联关系的。

下面举例介绍单向的关联关系。

上面的类图表现的是骑手和马之间的关系。

Rider中有一个实例变量类型是Horse。

每个连接都会有两个端点，上面的Rider和Horse就是端点，且每个端点都可以有(optional)一个基数(multiplicity)，表示这个类可以有几个实例。

左侧的Rider端点的1表示只有一个Rider，右侧Horse端点的1..n表示至少有1个Horse，也就是说Rider方是1，而Horse方是n，体现的是Rider和Horse之间的1对多关系。

聚集/聚合(aggregation)关系:关联关系的一种特例, 是强的关联关系. 聚合是整体和个体之间的关系,即has-a的关系，此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享；比如计算机与CPU、公司与员工的关系等；表现在代码层面，和关联关系是一致的，只能从语义级别来区分；聚合关系也是使用实例变量实现的. 从java 语法上是分不出关联和聚合的. 关联关系中两个类是处于相同的层次, 而聚合关系中两个类是处于不平等的层次, 一个表示整体, 一个表示部分.组合(合成)关系(composition): 也是关联关系的一种特例，他体现的是一种contains-a的关系，这种关系比聚合更强，也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束；比如你和你的大脑；合成关系不能共享。

表现在代码层面，和关联关系是一致的，只能从语义级别来区分。

组合跟聚合几乎相同，唯一的区别就是“部分”不能脱离“整体”单独存在，就是说，“部分”的生命期不能比“整体”还要长。

总结：对于继承、实现这两种关系没多少疑问，他们体现的是一种类与类、或者类与接口间的纵向关系；其他的四者关系则体现的是类与类、或者类与接口间的引用、横向关系，是比较难区分的，有很多事物间的关系要想准确定位是很难的，前面也提到，这几种关系都是语义级别的，所以从代码层面并不能完全区分各种关系；但总的来说，后几种关系所表现的强弱程度依次为：组合>聚合>关联>依赖。

类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统。

类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响。

下面是一个顾客从零售商处预定商品的模型的类图。

中心的类是Order。

连接它的是购买货物的Customer和Payment。

Payment有三种形式：Cash，Check，或者Credit。

订单包括OrderDetails（line item），每个这种类都连着Item。

UML类的符号是一个被划分成三块的方框：类名，属性，和操作。

抽象类的名字，像Payment是斜体的。

类之间的关系是连接线。

类图有三种关系。

关联association－表示两种类的实例间的关系。

如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联。

在图中，关联用两个类之间的连线表示。

聚合aggregation－当一个类属于一个容器时的一种特殊关系。

聚合用一个带菱形的连线，菱形指向具有整体性质的类。

在我们的图里，Order是OrderDetails的容器。

泛化generalization－一个指向以其他类作为超类的继承连线。

泛化关系用一个三角形指向超类。

Payment是Cash，Check和Credit的超类。

一个关联有两个尾端。

每个尾端可以有一个角色名role name来说明关联的作用。

比如，一个OrderDetail实例是一个Order实例的项目。

关联上的方向性navigability箭头表示该关联传递或查询的方向。

OrderDetail类可以查询他的Item，但不可以反过来查询。

箭头方向同样可以告诉你哪个类拥有这个关联的实现；也就是，OrderDetail拥有Item。

没有方向性的箭头的关联是双向。

关联尾端的数字表示该关联另一边的一个实例可以对应的数字端的实例的个数，通过这种方式表达关联的多样性multiplicity。

多样性的数字可以是一个单独的数字或者是一个数字的范围。

在例子中，每个Order只有一个Customer，但一个Customer可以有任意多个Order。

下面这个表给出了最普遍的多样性示例。

每个类图包括类，关联和多样性表示。

方向性和角色是为了使图示得更清楚时可选的项目。

CDE基本概念The fundamental information component in the ISO/IEC 11179 model is the data element,which constitutes a single（单个）unit of data considered indivisible（不可分割的）in the context in which it is used. Another way of saying this is that a data element is the smallest unit of information that can be exchanged in a transaction between cooperating systems.A critical notion（概念）in the metadata model is that any concept represented by a data element must have an explicit（明确的）definition that is independent of any particular representation. In order to achieve this in the model, the ISO/IEC 11179 standard specifies the following four components:1. A DataElementConcept consists of an object and a selected property of that object;2. The ConceptualDomain is the set of all intended meanings for the possible values of an associated DataElementConcepts;3. The V alueDomain is a set of accepted representations for these meanings;and4. A DataElement is a combination of a selected DataElementConcept and a ValueDomain.A simple example should help to clarify these definitions. Figure 3.1-1 shows a DataElement that might be used to represent hair color. The associated DataElementConcept use the ObjectClass Hair and the Property Color to define the intended concept. The intended meanings for this data element are the familiar hair colors blonde,brunette,etc.,but the ValueDomain uses a numeric representation that is mapped to these intended meanings. Both the DataElementConcept and the ValueDomain are components of the DataElement，and each references the same ConceptualDomain, which is defined outside the DataElement. Important principles of this design are:●The DataElementConcept is used to signify a concept independent of representation.●The ValueDomain specifies a set of representational values independent of meaning.●The DataElement combines a specific object and property with a value representation.●The ConceptualDomain specifies the complete set of value meanings for the conceptand allows the interpretation of the representation.Figure 3.1-2 uses a UML Class diagram to show the cardinality constraints that hold for these relations. Each DataElement must specify exactly one DataElementConcept and one V alueDomain in order to fully specify the data element. Similarly, each DataElementConcept and ValueDomain must specify exactly one ConceptualDomain. Conversely, a ConceptualDomain may be associated with any number of ValueDomains and any number of DataElementConcepts. Figure 3.1-3 shows an example of this, using the color property of different geometric objects as DataElementConcepts, and alternate color representations for the ValueDomains.A constraint not show in any of these figures is that it is not possible to reuse the same DataElementConcept-ValueDomain pair to define a new DataElement, as this defines a logical redundancy. Thus, the “0..*”cardinality constraints implied by Figure 3.1-2 are not quite as open-ended as they imply. Specifically,● a DataElement specifies exactly one DataElementConcept and one ValueDomain;● a DataElementConcept specifies exactly one ConceptualDomain;● a ValueDomain specifies exactly one ConceptualDomain;● a ConceptualDomain may be associated with any number of ValueDomains;● a ConceptualDomain may be associated with any number of DataElementConcepts;● a DataElementConcept may be associated with as many DataElements as there areValueDomains(i.e.,alternate representations) associated with be ConceptualDomain; and● a ValueDomain may be associated with as many DataElements as there areDataElementConcepts associated with the ConceptualDomain.Many additional information components collaborate with these four core elements to provide the ISO/IEC 11179 infrastructure for content representation. These are described in the caDSR model in the next section, along with the organizational and administrative components that are used to document, classify, and, in general, manage the information components.The caDSR MetamodelFigure 3.2-1 again shows the four elements discussed thus far,but this time in the context of other components that collectively(共同) define the infrastructure for content representation. All of the components in Figure 3.2-1 that are highlighted in light gray must be administered.Pragmatically, this means that there is a formal protocol for creating these components, that there is an approval(批准) process in place for accepting newly proposed elements, and that there is a designated authority in charge of stewarding the component. Technically, this means that each of the highlighted components is an instance of an AdministeredComponent.An AdministeredComponents is literally a component for which administrative information must be recorded. It may be a DataElement itself or one of its associated components that requires explicit specifications for reuse in or among enterprises-an AdministeredComponent is a generalization for all of the descendant components that are highlighted in Figure 3.2-1.Several new components are introduced in Figure 3.2-1. Two of these are used to explicitly(明确的) represent relationships between components defined in the ISO/IEC 11179 standard. A DataElementConceptRelationship is used to associate DataElementConcepts with one another; a V alueDomainPermissibleValue associates PermissibleValue with EnumeratedValueDomains. Table 3.2-1 provides concise definitions for all of the components in Figure 3.2-1.Table 3.2-2 lists the attribute fields of an AdministeredComponent. The attributes listed there however, tell only half the story. Additional information about an AdministeredComponent derives from its associations with the organizational and administrative components depicted in Figure 3.2-2. Of these components, the only element that is also itself an AdministeredComponent is the ClassificationScheme.Two “regions” are outlined in Figure 3.2-2: (1) the Naming and Identification region (upper right), and (2) the Classification region (lower left). The ReferenceDocument component is not included in either region. Each AdministeredComponent may be associated with one one or more ReferenceDocuments that identify where and when the component was created and provide contact information for the component’s designated registration authority.The purpose of the Naming and Identification region is manage the various names by which components are referenced in different contexts. Many components may be referenced by different names depending on the discipline, locality, and technology in which they are used. In addition to the name attributes contained in the component itself (preferredName,longName), an administered component may have any number of alternative designations. Each Designation is associated with exactly one Context reflecting its usage. The Classification region is used to manage classification schemes and the administered components that are in those classification schemes. Classification is a very fundamental and powerful way of organizing information to make the contents more accessible. Abstractly, a ClassificationScheme is any set of organizing principles or dimensions along which data can be organized. In the ISO/IEC 11179 model, a ClassificationScheme may be something as simple as a collection of keywords or as complex as an ontology. The classificationScheme element in Figure 3.2-2 is highlighted in light gray to reflect that it is an AdministeredComponent.ClassificationSchemes that define associations among components can greatly assist navigation through a large network of elements; the associations may describe simple subsumption hierarchies or more complex relations such as causal or temporal relations. In particular, ClassificationSchemes with inheritance can enhance self-contained definitions by contributing the definition of one or more ancestors. In caDSR 2.0, only Data Elements and DataElementConcepts may be assigned ClassificationSchemes; future plans include the ability to classify ConceptualDomains and ValueDomains.The ClassificationScheme component serves as container-like element that collects the classification scheme items participating in the scheme. In addition, the ClassificationScheme component identifies the source of the classification system and contains an indicator specifying that the scheme is alphanumeric, character, or numeric.A ClassificationSchemeItem may be a node in a taxonomy, a term in a thesaurus, a keyword in a collection, or a concept in an ontology-in all cases, it is an element that is used to classify AdministeredComponents. It is quite natural for an AdministeredComponent that is used in different Contexts to participate in several ClassificationSchemes. ClassificationSchemes may coexist and classified component may have a different name in each one, since each scheme is from a different context.The ClassSchemeClassSchemeItem in the caDSR model is not component of the ISO/IEC 11179 metamodel, but serves an important role in the implementation of the many-to-many mappings between ClassificationSchemeItems and ClassificationSchemes. This component is used to associate a set of ClassificationSchemeItems with a particular ClassificationScheme, and to store details of that association, such as the display order of the items within that scheme.In addtion to the caDSR components corresponding to elements of the ISO/IEC 11179 metamodel, the caDSR model defines a collection of domain-specific elements for capturing clinical trials data. All of the components described up to this point provide the infrastructure for managing shared data. The clinical trials components exercise the representational power of themetamodel, and are used to specify how clinical trials data should be captured and exchanged.All of the components in Figure 3.2-3 are highlighted in light gray, as they are AdministeredComponents designed for use in NCI-sponsored clinical trials. Note that because these elements are part of the ISO-11179 specification, they are not, technically speaking, ISO adminitered components. This caDSR design decision was made to ensure that the shared DataELements could be stewarded and controlled adequately. Definitions for these clinical trials metadata components are provided in Table 3.2-3.。