# Presentation: 415102

## Modeling your Application, Data or Service

***Enumerating Value Lists ***

## Session 2: Enumerating Value ListsOverview

**Outline**
- Two Value Domain Types
- Four options for Curating Value Domains
- Creating a Value Domain in a UML Model
- Adding Permissible Values
- Linking the Value Domain to a Model Attribute
- Exercise
**Objectives**
- Define the two types of value domains used in the caDSR
- Identify at least two options for curating Value Domains for your UML Models
- Identify the two stereotyped class types that are supported by the UML Loader for curating Value Domains in your UML Model

## Session 2: Enumerating Value ListsValue Domains – Two Types

**Enumerated: **contains a specific list of values called “Permissible Values”
- Permissible Values are composed of three component parts:
- Value (what appears on the form or interface)
- Value Meaning (a short, more meaningful description of what the value is)
- Value Meaning Description/Definition (a detailed description/definition for the value meaning)
- NOTE: VM / VMD are recorded as unique pairings. Enter them with care because once registered, they are reused within contexts. (EVS vs. Not)
**Non-enumerated: **describes the format and content of how a value should be represented
- Should use caDSR Value Domains

## Session 2: Enumerating Value ListsExample of Enumerated Permissible Values

**Values from the enumerated Value Domain:                                ****	****	*****Best Response Veterinary Treatment Type***

| Value | Value Meaning | Value Meaning Definition / Description |
| --- | --- | --- |
| CR | Complete Response | The disappearance of all signs of cancer in response to treatment |
| PD | Progressive Disease | A disease process that is increasing in scope or severity |
| SS | Significant Stabilization | Response to treatment/intervention in which disease stabilizes |
| TE | Too Early | Too early to assess, per protocol  |

## Session 2: Enumerating Value ListsCreating Value Domains - 4 Options

**Use the UML generated DE** as is.
- i.e. ‘Patient Race Category java.lang.String’
**Select an existing Value Domain** using the SIW during the Semantic Integration Process
**Create a Value Domain in your UML Model**
- Create a UML Class with a stereotype of “CADSR Value Domain”
- Include appropriate class tags
- See caCORE SDK Programmer’s Guide v1.1 for details
**Reference a large value list** (i.e.  >100 items) that is externally described somewhere (and is not in EVS)
- Create new non-enumerated VD, with a Reference Document that points to a specific standard (you do not have to actually instantiate a 1000 item pick list)
- Add value list to EVS or point to a parent concept within the external standard
- Classify the new VD within your Project classification scheme

## Session 2: Enumerating Value ListsCreating a Value Domain in Your Model

**Create a UML Class with a stereotype of “caDSR Value Domain” or “enumerated” **
- Note: It is recommended that all value domains for a model be put into one package (separate from regular domain objects)
- Note: only for model attributes that are NOT inherited
**Include the following Class Tags:**
- CADSR_ValueDomainDefinition
- CADSR_ValueDomainDatatype
- caDSR_ValueDomainType
- CADSR_ConceptualDomainPublicID
- CADSR_ConceptualDomainVersion
**Optional semantic tags are given in the SDK Programmers Guide on p.130**

**Notes:**
Besides being able to select existing caDSR Value Domains, model owners have the ability to create a Value Domain using a UML Modeling Tool (such as Enterprise Architect). For the UML Loader to create a Value Domain, the model owner must first create a UML class and stereotype it as <<caDSR Value Domain>>. When a UML class is stereotyped in this fashion, the SIW considers it as a Value Domain rather than a class. The name of the caDSR VD class will become the name of the VD. caDSR naming conventions specify that the representation term should be the last term in the VD name. For example, for the VD State Code, code is the representation term.

NOTE: When creating Value Domains for a model, be sure to put all Value Domains into a package in the Logical model that is separate from regular domain objects in the UML Modeling Tool.
NOTE: Value Domains can ONLY be created in the UML Model for attributes that are NOT inherited.
Include the following Class Tags for your caDSR Value Domain:
CADSR_ValueDomainDefinition
CADSR_ValueDomainDatatype – must be one of the valid caDSR datatypes
caDSR_ValueDomainType – the value for this tag is E for Enumerated and N for Non Enumerated)
CADSR_ConceptualDomainPublicID – best practice is to choose one of the 20 Conceptual Domains that represent EVS top levels
CADSR_ConceptualDomainVersion
Optional semantic tags are given in the SDK Programmers Guide on p.130
The next few slides will lead us through an example of creating a Value Domain and then linking it to appropriate attributes using a UML Modeling Tool.

## Session 2: Enumerating Value ListsExample of a Value Domain Specification 

**Notes:**
This slide is an example of a UML Value Domain specification in the project view of Enterprise Architect (EA). Note that the Value Domains are located in a separate folder than the other classes but are still in the Logical Model Package.

## Session 2: Enumerating Value ListsUML Class Properties

***Notes are not loaded to caDSR**

**Stereotype**

**Value Domain Name**

**Notes:**
Here is an example of a Value Domain called BinaryObject. Note that the “class” is stereotyped as caDSR Value Domain.

It is always a good idea to enter text into the notes section. However, in this case notes are not loaded to caDSR since all pertinent information of the Value Domain is captured as tags. 

## Session 2: Enumerating Value ListsAdd PVs for Enumerated VDs

- Value Meanings are specified as Attributes of a “CADSR Value Domain” Class
- Model Owner Value Meaning Descriptions are added as ‘description’ tags
- Semantics for Value Meanings are added during the SIW process, the Value Meaning in caDSR will be the Concept Preferred Name if the VM is associated with a concept, if not, the model supplied ‘description’ tagged value is used
- Map each attribute to one or more EVS concepts
- Attribute name = value
- Concept name(s) = value meaning
- Concept definition(s) = value meaning description
- Using the “no concept” concept

**Notes:**
Each attribute within a caDSR Value Domain class is considered a Value Meaning.
Adding UML attributes to a VD class is the preferred way to create Value Meanings. 
Value Meanings should be annotated with EVS Concepts.
This annotation is performed the same way as it is for attributes with the exception that the tag names are different.
The Model Owner creates description tags for Value Meaning Descriptions 
ValueMeaningConceptCode
ValueMeaningQualifierConceptCode(n)
ValueMeaningConceptPreferredName
ValueMeaningQualifierConceptPreferredName(n)
ValueMeaningConceptPreferredDefinition
ValueMeaningQualifierConceptPreferredDefinition(n)
ValueMeaningConceptDefinitionSource
ValueMeaningQualifierConceptDefinitionSource(n)
During the SIW process, semantics for Value Meanings are added. If the VM is associated with a Concept (and it should be), the VM in the caDSR will be the concept Preferred Name. If the VM is not associated to a concept, the “description” tag is used.

## Session 2: Enumerating Value Lists Value Domain Tags

**Notes:**
There are 5 mandatory tags required for each Value Domain as shown in this slide. 

CADSR_ConceptualDomainPublicID 
CADSR_ConceptualDomainVersion
CADSR_ValueDomainDatatype – must be one of the valid caDSR datatype
CADSR_ValueDomainDefinition
caDSR_ValueDomainType – the value for this tag is E for Enumerated and N for Non Enumerated)

## Session 2: Enumerating Value ListsAdding Value Meanings for a Value Domain

- Create a  <<CADSR Value Domain>> Class
- Value Meanings are specified as Attributes of a <<CADSR Value Domain>> Class
- Model Owner Value Meaning Descriptions are added as ‘description’ tags
- Semantics for Value Meanings are added during the SIW process , the Value Meaning in caDSR will be the Concept Preferred Name if the VM is associated with a concept, if not, the model supplied ‘description’ tagged value is used

## Session 2: Enumerating Value ListsPointing a UML Attribute to a Value Domain

- If an Attribute in the model uses a Value Domain that is created as part of the model, add a tag named CADSR Local Value Domain specifying the name of the Value Domain.

## Session 2: Enumerating Value ListsPointing a UML Attribute to a Value Domain 

**For Example:**
**The Value Domain ‘BinaryObject’ would be linked by adding the tag name of CADSR Local Value Domain to the attribute with the value of ‘BinaryObject’**

## Session 2: Enumerating Value ListsExercise

**Use the step-by-step instructions to complete the exercises **