NCh-ISO 19103-2010-047

NCh-ISO 19103
Contenido
Página
Preámbulo VI
0 Introducción 1
1 Alcance 2
2 Conformidad 2
3 Referencias normativas 2
4 Términos, definiciones y abreviaciones 3
4.1 Términos de ISO/TS 19103 3
4.2 Términos UML 5
4.3 Abreviaciones 8
5 Organización 9
6 El perfil UML de ISO/TS 19103 10
6.1 Introducción 10
6.2 Uso general de UML 10
6.3 Clases 11
6.4 Atributos 11
6.5 Tipos de datos 11
6.6 Operaciones 34
6.7 Relaciones y asociaciones 34
6.8 Estereotipos y valores etiquetados 35
I
NCh-ISO 19103
Contenido
Página
6.9 Atributos y asociaciones obligatorios, opcionales y condicionales 36
6.10 Denominación y espacios de nombres 36
6.11 Paquetes 39
6.12 Notas 40
6.13 Restricciones 40
6.14 Documentación de modelos 40
Anexos
Anexo A (normativo) Conjunto de pruebas abstractas 42
Anexo B (informativo) Sobre lenguajes de esquema conceptual 43
Anexo C (informativo) Orientaciones de modelado 56
C.1 Orientaciones para el modelado con UML 56
C.2 Orientaciones para el modelado de información 59
C.3 Orientaciones para el modelado de servicios 63
C.4 Armonización de modelos 66
Anexo D (informativo) Introducción a UML 69
D.1 Introducción 69
D.2 Uso general de UML 69
D.3 Clases 70
D.4 Atributos 72
D.5 Tipos de datos 73
II
NCh-ISO 19103
Contenido
Página
D.6 Operaciones 73
D.7 Relaciones y asociaciones 75
D.8 Estereotipos y valores etiquetados 79
D.9 Atributos y asociaciones opcionales, condicionales y obligatorios 81
D.10 Denominación y espacios de nombres 81
D.11 Paquetes 81
D.12 Notas 81
D.13 Restricciones 82
Anexo E (informativo) Bibliografía 85
Anexo F (informativo) Justificación de los cambios editoriales 87
Figuras
Figura 1 Tipos de datos básicos 12
Figura 2 Tipos primitivos 13
Figura 3 Tipos numéricos 14
Figura 4 Cadena de caracteres 17
Figura 5 Tipos de fecha y hora 18
Figura 6 Tipos de datos de verdad 19
Figura 7 Multiplicidad 20
Figura 8 Tipo de colección 21
Figura 9 Tipos de colección - Tipo de conjunto 22
Figura 10 Tipos de colección - Tipo de Multiconjunto 23
III
NCh-ISO 19103
Contenido
Página
Figura 11 Tipo de colección - Tipo de secuencia 24
Figura 12 Clases de diccionario 25
Figura 13 Ejemplo de enumeración 26
Figura 14 Ejemplos de ListasdeCódigos 27
Figura 15 Tipos de registros 28
Figura 16 Tipos de nombres 29
Figura 17 Unidades de tipos de medidas 31
Figura 18 Ejemplo de estructura de paquete 39
Figura B.1 Trabajo de normas ISO de información geográfica basado en

conceptos de GIS e IT 43
Figura B.2 Desde la realidad al esquema conceptual basado en un formalismo

conceptual y un lenguaje de esquema conceptual 44
Figura B.3 Principio 100% ISO para modelado conceptual 45
Figura B.4 Capas de metamodelos del CSMF - Recurso de modelado de

esquemas conceptuales 46
Figura B.5 Relaciones del modelo general de features y el modelo UML

47
Figura B.6 Núcleo del Modelo General de Features ISO 19109 49
Figura B.7 Metamodelo central de UML 50
Figura B.8 Arquitectura de metamodelo para UML 51
Figura B.9 Puntos de vista del modelo RM-ODP de ISO 51
Figura B.10 Modelo de referencia de arquitectura ISO 19101 54
Figura D.1 La <<interface>> de estereotipo 70
Figura D.2 El estereotipo <<type>> 70
IV
NCh-ISO 19103
Contenido
Página
Figura D.3 Símbolos para definiciones de elementos derivados, visibilidad y

niveles de clases 71
Figura D.4 Distintos tipos de relaciones 75
Figura D.5 Asociación 76
Figura D.6 Especificación de multiplicidad/cardinalidad 77
Figura D.7 Agregación 77
Figura D.8 Composición (agregación sólida) 78
Figura D.9 Estereotipos UML y valores etiquetados 79
Figura D.10 Ejemplo de nota 81
Figura D.11 Ejemplo de restricción OCL adjunta a elementos de modelo 82
Tablas
Tabla D.1 Restricciones textuales sobre tipos de colección 82
Tabla D.2 Operaciones booleanas de la norma OCL 83
Tabla D.3 Operaciones de números enteros/reales de la norma OCL 83
Tabla D.4 Operaciones de cadena OCL 84
Tabla D.5 Operaciones de colección OCL 84
Tabla F.1 Cambios editoriales 87
V
NORMA CHILENA OFICIAL NCh-ISO 19103.Of2010
Información geográfica - Lenguaje de esquema conceptual
Preámbulo
El Instituto Nacional de Normalización, INN, es el organismo que tiene a su cargo el

estudio y preparación de las normas técnicas a nivel nacional. Es miembro de la
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO) y de la COMISION
PANAMERICANA DE NORMAS TECNICAS (COPANT), representando a Chile ante esos
organismos.
Esta norma se estudió a través del Comité Técnico Geomática, para entregar reglas y
orientaciones para el uso de un lenguaje de esquema conceptual dentro de las normas ISO
de información geográfica. El lenguaje de esquema conceptual elegido es el Lenguaje
Unificado de Modelado (UML).
Esta norma es idéntica a la versión en inglés de la Norma Internacional

ISO/TS 19103:2005 Geographic information - Conceptual schema language.
La Nota explicativa incluida en un recuadro en cláusula 2 Referencias normativas, y en el

anexo Bibliografía es un cambio editorial que se incluye con el propósito de informar la
correspondencia con Norma Chilena de las Normas Internacionales citadas en esta norma.
La norma NCh-ISO 19103 ha sido preparada por la División de Normas del Instituto
Nacional de Normalización, y en su estudio el Comité estuvo constituido por las
organizaciones y personas naturales siguientes:
Centro de Información de Recursos Naturales, CIREN Ariel Avendaño A.

Digimapas Chile Aerofotogrametría Ltda. Gabriela Hermosilla R.
ESRI Chile Marcela Silva S.
IKOM, Integración y Comunicación Ltda. Martina Mann K.
Instituto Geográfico Militar, IGM María Loreto Advis N.
Cintia Andrade L.
Coralí González S.
VI
NCh-ISO 19103
Instituto Nacional de Normalización, INN Jorge Muñoz C.

Ministerio de Bienes Nacionales, SNIT Alvaro Monett H.
Pablo Morales H.
Servicio Aerofotométrico, SAF Giannina Reyes G.
Servicio Hidrográfico y Oceanográfico
de la Armada, SHOA Miguel Neira N.
Claudio Sobarzo E.
Servicio Nacional de Geología y Minería, Sernageomín Sandra Huerta B.
Iris Lazo A.
Universidad de Playa Ancha - Ciencias Geográficas Roberto Richardson V.
El Anexo A forma parte de la norma.
Los Anexos B, C, D y E y F no forman parte de la norma, se insertan sólo a título

informativo.
Esta norma ha sido aprobada por el Consejo del Instituto Nacional de Normalización, en
sesión efectuada el 30 de noviembre de 2010.
Esta norma ha sido corregida y reimpresa en 2011, corrigiéndose los errores de forma
siguientes:
- “entidad (feature)” por “feature”; y
- “entidades (features)” por “features”.
Esta norma ha sido declarada Oficial de la República de Chile por Resolución Administrativa
Exenta N°1917, de fecha 15 de septiembre de 2011, del Ministerio de Economía, Fomento y
Turismo, publicado en el Diario Oficial del 24 de septiembre de 2011.
VII
0 Introducción
Esta norma forma parte de la serie de normas ISO de información geográfica y se

preocupa de la adopción y el uso de un Lenguaje de Esquema Conceptual (CSL) para
desarrollar modelos computacionalmente interpretables, o esquemas, de información
geográfica. La normalización de información geográfica requiere el uso de un CSL formal
para especificar esquemas no ambiguos que puedan servir como base para el intercambio
de datos y la definición de servicios interoperables. Un objetivo importante de las normas
ISO de información geográfica es la creación de un marco que permita el intercambio de
datos y la interoperabilidad de servicios en múltiples entornos de implementación. La
adopción y el uso consistente de un CSL para especificar información geográfica son de
fundamental importancia para lograr esta meta.
Hay dos aspectos a tener en cuenta en esta norma. En primer lugar, se debe elegir un CSL
que cumpla los requisitos para una representación rigurosa de la información geográfica.
Esta norma identifica la combinación del diagrama de estructura estática del Lenguaje
Unificado de Modelado (UML) con su Lenguaje de Restricciones de Objetos (OCL)
asociado y un conjunto de definiciones básicas como un lenguaje de esquema conceptual
para especificar la información geográfica. En segundo lugar, esta norma entrega
orientaciones sobre la forma en que se debería usar el UML para generar información
geográfica y modelos de servicios que son una base para lograr la meta de la
interoperabilidad.
Uno de los objetivos de las normas ISO de información geográfica que usan modelos UML
es entregar una base correspondiente (mapping) para codificar esquemas como se define
en ISO 19118, así como una base para crear especificaciones para perfiles de
implementación para varios entornos.
1
NCh-ISO 19103
1 Alcance
Esta norma entrega reglas y orientaciones para el uso de un lenguaje de esquema

conceptual dentro de las normas ISO de información geográfica. El lenguaje de esquema
conceptual elegido es el Lenguaje Unificado de Modelado (UML).
Esta norma también proporciona un perfil del UML para su uso con información geográfica
y una orientación sobre la forma en que el UML se debería usar para crear modelos
normalizados de información geográfica y servicios.
2 Conformidad
Cualquier esquema conceptual escrito para una especificación, incluido un perfil o norma
funcional, que declara conformidad con esta norma debe cumplir todos los requisitos
descritos en el conjunto de pruebas abstractas del Anexo A. Esquemas no UML deben ser
considerados conformes si existe una correspondencia bien definida desde un modelo en
el lenguaje fuente a un modelo equivalente en UML y que este modelo en UML esté
conforme.
3 Referencias normativas
Los documentos referenciados siguientes son indispensables para utilizar este documento.
Para referencias con fechas, sólo se aplica la edición citada. Para referencias sin fechas,
se aplica la última edición del documento citado (incluidas sus modificaciones).
ISO 19101:2002 Geographic Information - Reference model.

ISO/IEC 19501:2005 Information technology - Open Distributed Processing - Unified
Modeling Language (UML) Versión 1.4.2.
NOTA EXPLICATIVA NACIONAL
La equivalencia de las Normas Internacionales señaladas anteriormente con Norma Chilena, y su grado de
correspondencia es el siguiente:
Norma Internacional Norma nacional Grado de correspondencia

ISO 19101:2002 NCh-ISO 19101.Of2010 Idéntica
ISO/IEC 19501:2005 No hay -
2
NCh-ISO 19103
4 Términos, definiciones y abreviaciones
4.1 Términos de ISO/TS 19103
Para los propósitos de esta norma, se aplican los términos y definiciones siguientes.
4.1.1 aplicación: manipulación y procesamiento de datos en apoyo a los requisitos del

usuario
[ISO 19101]
4.1.2 esquema de aplicación: esquema conceptual para datos requeridos en una o más
aplicaciones
4.1.3 modelo conceptual: modelo que define los conceptos de un universo de discurso
[ISO 19101]
4.1.4 esquema conceptual: descripción formal de un modelo conceptual
[ISO 19101]
4.1.5 tipo de datos: especificación de un valor de dominio con operaciones permitidas

sobre valores en este dominio
EJEMPLO
Número entero, Real, Booleano, secuencia (string), Fecha y Punto SG (conversión de datos en una serie de
códigos).
NOTA - Los tipos de datos incluyen tipos predefinidos primitivos y tipos que define el usuario.
4.1.6 dominio: conjunto bien definido
NOTA - Los dominios se utilizan para definir el conjunto de dominios y el conjunto de rangos de atributos,
operadores y funciones.
4.1.7 feature: abstracción de un fenómeno del mundo real
[ISO 19101]
NOTAS
1) Un feature puede ocurrir como un tipo o una instancia. El tipo de feature o instancia de feature se debería
usar sólo cuando se refiere a uno de ellos.
2) En UML (ver Anexo E, Bibliografía, [8], un feature es una propiedad, tal como una operación o atributo,
que se encapsula como parte de una lista dentro de un clasificador, tal como una interfaz, una clase o un
tipo de datos.
3
NCh-ISO 19103
4.1.8 asociación de features: relación que vincula instancias de un tipo de feature con
instancias del mismo tipo de feature o de otro distinto
[ISO 19109]
NOTAS
1) Una asociación de features puede ocurrir como un tipo o una instancia. El tipo de asociación de features o
instancia de asociaciones de feature se usa sólo cuando se refiere a uno de ellos.
2) Las asociaciones de features incluyen agregación de features.
4.1.9 atributo de un feature: característica de un feature
NOTAS
1) Un atributo de un feature tiene un nombre, un tipo de dato y un dominio de valor asociado a él y, para
una instancia de feature, también tiene un valor de atributo obtenido del dominio de valor.
2) Un atributo de un feature puede ocurrir como un tipo o una instancia. El tipo de atributo de un feature o
una instancia de un atributo de un feature se debería usar sólo cuando se refiere a uno de ellos.
4.1.10 operación de un feature: operación que puede realizar cada instancia de un tipo de
feature
[ISO 19109]
EJEMPLOS
1) Una operación bajo el nombre represa es para elevar la represa. El resultado de esta operación es elevar el
nivel del agua en un reservorio.
2) Una operación bajo el nombre represa podría impedir la navegación a embarcaciones en el cauce.
NOTA - Las operaciones de features proporcionan una base para una definición de un tipo de feature.
4.1.11 metadatos: datos acerca de los datos
[ISO 19115]
4.1.12 elemento de metadatos: unidad discreta de metadatos
[ISO 19115]
NOTAS
1) Los elementos de metadatos son únicos dentro de un metadatos.
2) Equivalente a un atributo en la terminología UML.
4.1.13 esquema: descripción formal de un modelo
[ISO 19101]
4
NCh-ISO 19103
4.1.14 servicio: parte distintiva de la funcionalidad que entrega una entidad mediante
interfaces
[ISO/IEC TR 14252]
4.1.15 valor de dominio: conjunto de valores aceptados
EJEMPLO
El rango 3-28, todos los números enteros, cualquier caracter ASCII, enumeración de todos los valores
aceptados (verde, azul, blanco).
4.2 Términos UML
Los siguientes son términos UML adaptados de ISO/IEC 19501.
4.2.1 actor: conjunto coherente de roles que los usuarios de casos de usos ejecutan
cuando interactúan con estos casos
NOTA - Un actor puede ser considerado para que juegue un rol separado respecto a cada caso de uso con el
que se comunica.
4.2.2 agregación: forma especial de la asociación que especifica una relación todo-parte
entre el agregado (todo) y un componente (parte)
NOTA - Ver composición.
4.2.3 asociación: relación semántica entre dos o más clasificadores que especifica las
conexiones entre sus instancias
NOTA - Una asociación binaria es una asociación exactamente entre dos clasificadores (lo que incluye la
posibilidad de una asociación desde un clasificador hasta sí mismo).
4.2.4 atributo: feature dentro de un clasificador que describe un rango de valores que
pueden contener instancias del clasificador
NOTAS
1) Un atributo es semánticamente equivalente a una asociación de composición; sin embargo, el propósito y

uso suele ser distinto.
2) El feature utilizado en esta definición es el significado de UML del término y no se traduce como se define
en 4.1 de esta norma.
4.2.5 comportamiento: efectos observables de una operación o evento, incluidos sus

resultados
4.2.6 cardinalidad: número de elementos en un conjunto
NOTA - Contraste: multiplicidad.
5
NCh-ISO 19103
4.2.7 clase: descripción de un conjunto de objetos que comparten los mismos atributos,
operaciones, métodos, relaciones y semántica
NOTA - Una clase puede usar un conjunto de interfaces para especificar colecciones de operaciones que
entrega a su entorno. Ver: interfaz.
4.2.8 clasificador: mecanismo que describe features estructurales y de comportamiento
NOTA - Los clasificadores incluyen interfaces, clases, tipos de datos y componentes.
4.2.9 componente: parte modular, reemplazable y que se puede desplegar, perteneciente

a un sistema que encapsula la implementación y expone un conjunto de interfaces
NOTA - Un componente representa una parte física de la implementación de un sistema, incluido un código de
software (fuente, binario o ejecutable) o equivalentes tales como secuencias de instrucciones (scripts) o
archivos de comandos.
4.2.10 composición: forma de agregación que requiere que se incluya en más de un

compuesto a la vez una instancia parcial y que el objeto compuesto sea responsable de la
creación y destrucción de las partes
NOTA - Se pueden crear partes de multiplicidad no fija después del compuesto mismo, pero una vez creado
perduran y acaban con él (esto es, comparten tiempo de vida). Tales partes se pueden eliminar explícitamente
antes de la muerte del compuesto. La composición puede ser recurrente. Sinónimo: agregación de compuesto.
4.2.11 restricción: condición o restricción semántica
NOTA - Ciertas restricciones están predefinidas en UML, otras pueden ser definidas por el usuario. Las
restricciones son uno de tres mecanismos de extensibilidad en UML. Ver: valor etiquetado, estereotipo.
4.2.12 dependencia: relación entre dos elementos de un modelo, en que un cambio a un

elemento del modelo (el elemento independiente) debe afectar al otro elemento del modelo
(el elemento dependiente)
4.2.13 generalización: relación taxonómica entre un elemento más general y otro más
específico, el cual es completamente consistente con el elemento más general y contiene
información adicional
NOTA - Una instancia del elemento más específico se puede usar donde se permite el elemento más general.
Ver: herencia.
4.2.14 herencia: mecanismo mediante el cual elementos más específicos incorporan la

estructura y el comportamiento de elementos más generales relacionados mediante el
comportamiento
NOTA - Ver generalización.
4.2.15 instancia: entidad que tiene una identidad única, un conjunto de operaciones que
se pueden aplicar a ella, y estado que almacena los efectos de las operaciones
NOTA - Ver: objeto.
6
NCh-ISO 19103
4.2.16 interfaz: conjunto determinado de operaciones que caracteriza el comportamiento

de un elemento
4.2.17 metamodelo: modelo que define el lenguaje para expresar un modelo
4.2.18 método: implementación de una operación
NOTA - Especifica el algoritmo o procedimiento asociado con una operación.
4.2.19 multiplicidad: especificación del rango de cardinalidades aceptables que puede

asumir un conjunto
NOTA - Las especificaciones de multiplicidad se pueden dar por roles dentro de asociaciones, partes dentro de
compuestos, repeticiones y otros propósitos. En esencia, una multiplicidad es un conjunto (posiblemente
infinito) de números enteros no negativos. Contraste: cardinalidad.
4.2.20 objeto: entidad con límite bien definido e identidad que encapsula estado y
comportamiento
NOTA - El estado es representado por atributos y relaciones, el comportamiento es representado por

operaciones, métodos y máquina de estados. Un objeto es una instancia de una clase. Ver: clase, instancia.
4.2.21 operación: servicio que puede ser requerido desde un objeto para afectar el
comportamiento
NOTAS
1) Una operación tiene una firma, que puede restringir los parámetros reales que son posibles.
2) Definición del Manual de Referencia de UML: Una especificación de una transformación o consulta que un
objeto puede ser llamado a ejecutar.
3) Una operación tiene un nombre y una lista de parámetros. Un método es un procedimiento que
implementa una operación. Tiene un algoritmo o descripción de procedimiento.
4.2.22 paquete: mecanismo de propósito general para organizar elementos en grupos
NOTA - Los paquetes pueden estar anidados con otros paquetes. Los elementos y diagramas de modelos
pueden aparecer en un paquete.
4.2.23 refinamiento: relación que representa una especificación más completa de algo que
ya se especificó a un cierto nivel de detalle
NOTA - Por ejemplo, una clase de diseño es un refinamiento de una clase de análisis.
4.2.24 relación: conexión semántica entre elementos de un modelo
NOTA - Entre tipos de relaciones figuran asociación, generalización, metarrelación, flujo y varios tipos
agrupados bajo dependencia.
7
NCh-ISO 19103
4.2.25 especificación: descripción declarativa de lo que algo es o hace
NOTA - Contraste: implementación.
4.2.26 estereotipo: nuevo tipo de elemento de modelado que extiende la semántica del
metamodelo
NOTA - Los estereotipos se deben basar en ciertos tipos o clases existentes en el metamodelo. Los
estereotipos pueden extender la semántica, pero no la estructura de tipos o clases preexistentes. Ciertos
estereotipos se predefinen en el UML, otros pueden ser definidos por el usuario. Los estereotipos son uno de
los tres mecanismos de extensibilidad en UML. Los otros son la restricción y el valor etiquetado.
4.2.27 valor etiquetado: definición explícita de una propiedad como un par de nombre-
valor
NOTA - En un valor etiquetado, el nombre se refiere a la etiqueta. Ciertas etiquetas se predefinen en el UML,
otras pueden ser definidas por el usuario. Los valores etiquetados son uno de los tres mecanismos de
extensibilidad en UML. Los otros son la restricción y el estereotipo.
4.2.28 tipo: clase estereotipada que especifica un dominio de objetos junto con las
operaciones aplicables a los objetos, sin definir la implementación física de esos objetos
NOTA - Un tipo puede tener atributos y asociaciones.
4.2.29 valor: elemento de un dominio tipo
NOTAS
1) Un valor se puede considerar un posible estado de un objeto dentro de una clase o tipo (dominio).
2) Un valor de datos es una instancia de un tipo de dato, un valor sin identidad.
4.3 Abreviaciones
API Interfaz de Programación de Aplicaciones (Application Programming

Interface)
CASE Ingeniería de Software Asistida por Computador (Computer Aided

Software Engineering)
CORBA Arquitectura Común de Intermediarios en Peticiones a Objetos (Common

Object Request Broker Architecture)
CSL Lenguaje de Esquema Conceptual (Conceptual Schema Language)
CSMF Recurso de Modelado de Esquemas Conceptuales (Conceptual Schema

Modeling Facility)
DCOM/OLE Modelo de Objetos de Componentes Distribuidos/Vinculación e

Incrustación de Objetos (Distributed Compound Objet Model/Objet Linking
and Embedding)
8
NCh-ISO 19103
GFM Modelo General de Features (General Feature Model)
OCL Lenguaje de Restricciones de Objetos (Object Constraint Language)
ODMG Grupo de Gestión de Bases de Datos de Objetos (Object Database

Management Group)
OMG Grupo de Gestión de Objetos (Object Management Group)
ODP Procesamiento Distribuido Abierto (Open Distributed Processing)
ODBC Conexión Abierta a Bases de Datos (Open Database Connection)
SRS Sistema de Referencia Espacial (Spatial Reference System)
UML Lenguaje Unificado de Modelado (Unified Modeling Language)
URL Localizador Unificado de Recursos (Uniform Resource Locator)
XML Lenguaje Extensible de Marcado (Extended Markup Language)
XMI Intercambio de Metamodelos de XML (XML Metamodel Interchange)
5 Organización
Esta norma contiene un Perfil UML que entrega orientaciones de modelado para usar UML
de acuerdo con las normas ISO de información geográfica.
El principal contenido técnico de esta norma se encuentra en cláusula 6. En 6.1 y 6.2 se

entrega una introducción al uso general del UML. La descripción de clases y atributos en
6.3 y 6.4 se basa en reglas generales para el UML. Los tipos de datos descritos en 6.5 se
desarrollan en esta norma, ya que el UML normalizado no determina el uso de tipos de
datos específicos. Más información sobre el nivel de precisión necesario de los modelos
de UML que exige esta norma se entrega en 6.6, 6.7 y 6.8. Las convenciones para definir
atributos y asociaciones opcionales se describen en 6.9. Las reglas de denominación se
describen en 6.10.
El Anexo A describe un conjunto de pruebas abstractas para verificar que los modelos de
UML se realicen de acuerdo con las reglas de esta norma.
En Anexo B se puede encontrar una introducción a los lenguajes de esquema conceptual y

en Anexo C se pueden encontrar orientaciones para el modelado de información y de
servicios. El UML general como se define en ISO/IEC 19501 se describe brevemente en
Anexo D.
9
NCh-ISO 19103
6 El perfil UML de ISO/TS 19103
6.1 Introducción
Esta cláusula entrega reglas y orientaciones sobre el uso del UML en el campo de la
información geográfica. Define aspectos específicos para la utilización del UML para que
cumpla las normas ISO de información geográfica. Se basa en el UML general que se
define en ISO/IEC 19501 (ver Anexo D). El Anexo D sigue la misma estructura que esta
cláusula para facilitar la referencia a conceptos pertinentes normalizados de UML.
Estas subcláusulas se estructuran de la forma siguiente:
- Uso general de UML.
- Clases.
- Atributos.
- Tipos de datos.
- Operaciones.
- Relaciones y asociaciones.
- Estereotipos y valores etiquetados.
- Atributos y asociaciones opcionales, condicionales y obligatorios.
- Denominación y nombres de espacios.
- Paquetes.
- Notas.
- Restricciones.
- Documentación de modelos.
6.2 Uso general de UML
Se debe usar UML de forma tal que sea consistente con ISO/IEC 19501.
NOTA - Libros como UML User Guide (ver Anexo E, Bibliografía, [1]) (Orientación de Usuario de UML) y UML
Reference Manual (ver Anexo E, Bibliografía, [2]) (Manual de Referencias de UML) contienen más información
al respecto. El libro UML Distilled (ver Anexo E, Bibliografía, [4]) (Comprensión de UML) es un texto
introductorio más breve.
Todos los modelos normativos de clases deben contener definiciones completas de

atributos, asociaciones y operaciones, así como definiciones apropiadas de tipos de datos.
También se pueden usar otros tipos de diagramas UML como modelos normativos. Existe
la necesidad de esta integridad que hace necesario definir este perfil UML, ya que el UML
en general se puede utilizar en varios niveles de precisión e integridad.
10
NCh-ISO 19103
6.3 Clases
Una clase de acuerdo con esta norma se suele considerar como una especificación y no
como una implementación. Los atributos se consideran abstractos y no se deben
implementar directamente (esto es, como campos en un registro o variables de instancias
en un objeto). Esto no se contrapone con el proceso de codificación como se describe en
ISO 19118, ya que éste describe una representación externa que no tiene que ser
equivalente a la representación interna.
Por tal motivo, los esquemas conceptuales que se ciñen a este perfil de UML deben
encasillar todos los clasificadores como <<Type>>, a menos que apunten
particularmente a especificar la representación interna.
NOTA - Los clasificadores especificados como <<DataType>> (sin identidad) no suelen ser considerados
como tipos en UML, pero se puede suponer que son abstractos para esquemas conceptuales que cumplen
este perfil de UML, a menos que el esquema en que se definen determine específicamente otra cosa.
Por cada clase definida según esta norma, el conjunto de atributos definidos en esta
clase, junto con los conjuntos de atributos de clases que se pueden alcanzar directa o
indirectamente a través de asociaciones, deben ser suficientes para apoyar del todo la
implementación de cada operación definida en esta clase particular.
El uso de herencia múltiple es un problema en muchos entornos de implementación y puede

generar dificultades si no se maneja adecuadamente en esos entornos. Por tal motivo, se
debería minimizar o evitar la utilización de herencia múltiple a menos que sea una parte
fundamental de la semántica de la jerarquía de tipo. Si se usa, el esquema que se ciñe a este
perfil de UML no debe requerir que las clases de implementación que consideren los tipos
especificados en las normas, repliquen el modelo de herencia de los tipos.
6.4 Atributos
Los atributos se usan de acuerdo con la norma UML (ver Anexo D, cláusula D.4).
6.5 Tipos de datos
6.5.1 Consideraciones generales
Las clases y patrones (tipos parametrizados) definidos en esta cláusula son aquellas que
usualmente se definen por el lenguaje de definición de datos para el entorno de desarrollo.
Cada uno de estos tipos se puede representar en una variedad de formas lógicamente
equivalentes. Aquellos presentados acá no apuntan a restringir el uso de otras formas
equivalentes naturales al entorno de desarrollo elegido. La norma ISO/IEC 11404 presenta
una definición equivalente para la mayoría de los tipos y patrones presentados acá.
Los tipos básicos de datos se han agrupado en tres categorías, como se muestra en Figura 1:
a) Tipos primitivos: Tipos fundamentales para representar valores, como por ejemplo:
CharacterString, Número entero, Booleano, Fecha, Hora, etc.
11
NCh-ISO 19103
b) Tipos de implementación y colección: Tipos para estructuras de implementación y

representación, como por ejemplo: Nombres y Registros, y tipos para representar
acontecimientos múltiples de otros tipos, como por ejemplo Conjunto, Multiconjunto
(bag) y Secuencia.
c) Tipos derivados: Tipos de medida y unidades de medición.
Los tipos básicos se definen como tipos abstractos, el nombre de una clase en cursiva y
las representaciones apropiadas se deben definir por la implementación y codificación de
mapas para los diversos subtipos.
El repertorio de tipos de datos básicos se describe en 6.5.2 a 6.5.7.
Primitive Implementation Derived

(from Basic Types) (from Basic Types) (from Basic Types)
<<Leaf>> <<Leaf>> <<Leaf>>

Numerics Collections Units of Measure
(from Primitive) (from Implementation) (from Derived)
<<Leaf>> <<Leaf>>
Text Records
(from Primitive) (from Implementation)
<<Leaf>> <<Leaf>>
Date and Time Names
(from Primitive) (from Implementation)
<<Leaf>>
Truth
(from Primitive)
<<Leaf>>
Enumerations
(from Primitive)
<<Leaf>>
Multiplicities
(from Primitive)
Figura 1 - Tipos de datos básicos
12
NCh-ISO 19103
6.5.2 Tipos primitivos
6.5.2.1 Generalidades
La Figura 2 entrega una visión general de los tipos primitivos que se describirán a
continuación. La Figura 3 proporciona una visión general de los tipos numéricos. Junto
con los diagramas de clase en las figuras adjuntas y el texto de esas figuras, el contenido
en cada uno de los paquetes se describe en 6.5.2.1 a 6.5.2.14.

Numeric Date and Time Enumerations
+Decimal +DateTime +Sign
+Vector +Date +Digit
+Real +DatePrecision +Bit
+Number +Time
+UnlimitedInteger
+Integer

Text Truth Multiplicities
+ CharacterString +Boolean +Multiplicity
+Sequence<Character> +Logical +MulticiplityRange
+Character +Truth
+CharacterSetCode + DiscreteTruth
+LanguageCharacterString + ContinuosTruth
+Probability
Figura 2 - Tipos primitivos
13
NCh-ISO 19103
<<Type>>
Number
+=(n:Number) : Boolean
+<>(n:Number) : Boolean <<Type>>
+<(n:Number) : Boolean UnlimitedInteger
+<=(n:Number) : Boolean +isInfinite : Boolean
+>(n:Number) : Boolean +value [0..1] : Integer
+>=(n:Number) : Boolean
++(n:Number) : Number
+ - (n:Number) : Number
+ * (n:Number) : Number
+ / (n:Number) : Number <<Type>>
+negate() : Number Vector
+abs() : Number +dimension : Integer
+min(n:Number) : Number +coordinate: Sequence<Number>
+max(n:Number) : Number +vectorAdd (v Vector) : Vector
+asInteger() : Integer +scalarMultiply(n : Number) : Vector
+asReal() : Real
+asString():CharacterString
<<Type>> <<Type>> <<Type>>

Decimal Real Integer
+asReal() : Real +floor() : Integer +div(j : Integer) : Integer
+absoluteValue() : Real +mod(j : Integer) : Integer
+asDecimal(length: Integer): Decimal +asReal() : Real
Figura 3 - Tipos numéricos
14
NCh-ISO 19103
6.5.2.2 Number (Número)
El number es un tipo base para todos los datos numéricos que permiten las operaciones
algebraicas básicas. Dado que todos los tipos concretos tienen representaciones finitas,
algunas partes de esta álgebra muestran cierta imprecisión respecto de la mayoría de los
tipos. Por ejemplo, los integer no se dividen muy bien, mientras que los reals y decimals
no pueden evitar ciertos tipos de imprecisiones que dependen de sus semánticas de
representación. El number es una clase abstracta.
6.5.2.3 Integer (Número entero)
Integer es un número entero con signo; la longitud de un integer depende de la

encapsulación y el uso. Consiste en un valor de integer exacto, sin parte fraccional.
EJEMPLO
29, - 65547.
6.5.2.4 Decimal
Decimal es un tipo de dato decimal en que el número representa un valor exacto, como una
representación finita de un número decimal. Difiere de la implementación de reales binarios
comunes en que puede representar 1/10 (un décimo) sin error, mientras que la representación
de reales binarios sólo puede presentar potencias de exactamente 1/2 (un medio). Dado que
muchas monedas tienen decimales, se prefieren estas representaciones para ellas. Lo mismo
se aplica para marcadores de millas, que a menudo se entregan en decimales.
NOTA - Esto difiere del número real, porque el real es un valor aproximado y el decimal es exacto.
EJEMPLO
12,75.
6.5.2.5 Real
Real es un número real con signo (punto flotante), que consiste en una mantisa y un
exponente y que representa un valor para una precisión dada por el número de dígitos
mostrados, pero no es necesariamente el valor exacto. La longitud de un real depende de
la encapsulación y el uso. La implementación de un número binario común usa base 2.
Dado que tales reales pueden aproximar cualquier medida en que la precisión absoluta no
sea posible, esta forma de presentación numérica se usa de preferencia para medidas. En
casos en que se requiere precisión absoluta, como en las monedas, entonces se prefiere
una representación decimal (suponiendo que la moneda utiliza decimales, como el dólar
estadounidense, la libra esterlina, etc.). Donde no sean posibles subunidades, se puede
optar por números enteros. Un real se puede considerar como una parte entera seguida de
una parte fraccional entregada en múltiplos de potencias de 1/2 (mitades).
EJEMPLO
23 501, - 1234E-4, - 23,0.
15
NCh-ISO 19103
6.5.2.6 Vector
El vector es un conjunto ordenado de números denominados coordenadas que representan

una posición en un sistema de coordenadas. Las coordenadas pueden estar en un espacio
de cualquier número de dimensiones, como por ejemplo en un polinomio por partes
(spline) de grado n.
EJEMPLO
(123, 514, 150).
6.5.2.7 CharacterString (Cadena de Caracteres)
Un CharacterString, como se ilustra en Figura 4, es una secuencia de caracteres de

longitud arbitraria, que incluye acentos y caracteres especiales del repertorio de uno de los
conjuntos de caracteres adoptados:
- ISO/IEC 10646: Universal Multi-Octet Coded Character Set (UCS); e
- ISO 8859.
EJEMPLO
Ærlige Kåre så snø for første gang.
La longitud máxima de un CharacterString depende de la encapsulación y el uso. Se

puede entregar una etiqueta de lenguaje para identificar el lenguaje de valores de cadenas.
Para una implementación de mapas de un CharacterString se necesita decidir el manejo de

los aspectos siguientes:
1) representación del valor;
2) representación del conjunto de caracteres;
3) representación de la codificación; y
4) representación de lenguaje.
Esto se puede manejar, por ejemplo, al escoger ISO/IEC 10646.
16
NCh-ISO 19103
T
<<CodeList>>
CharacterSetCode
<<Type>>
Sequence +ISO10646 = default
(from Collections) +ISO8859
<<Type>>
Character
<<Type>>
Sequence<Character>
<<Type>>
CharacterString
+size : Integer
/+characterSet : CharacterSetCode = “ISO 10646”
+element[size] : Character
+maxLength: Integer
+ isNull() : Boolean
+=(s : CharacterString) : Boolean
+<>(s : CharacterString) : Boolean
+<(s : CharacterString) : Boolean
+>(s : CharacterString) : Boolean
+<=(s : CharacterString) : Boolean
+>=(s : CharacterString) : Boolean
+toUpper(): CharacterString
+toLower(): CharacterString
+subString(lower: Integer, upper: Integer) : CharacterString
Figura 4 - Cadena de caracteres
17
NCh-ISO 19103
6.5.2.8 Date (Fecha)
Date entrega valores de año, mes y día. La Figura 5 muestra los tipos de date. La
codificación de caracteres de un date es una cadena que debe seguir el formato para date
como se especifica en ISO 8601. La codificación se aborda con más profundidad en
ISO 19118 e ISO 19136. Los principios para la date y el tiempo se analizan con más
detalle en ISO 19108.
EJEMPLO
1998-09-18.
<<Type>> <<Type>>
Time Date
+hour: CharacterString +century : CharacterString
+minute[0..1] : CharacterString +year[0..1] : CharacterString
+second[0..1] : CharacterString +month[0..1] : CharacterString
+time Zone[0..1] : CharacterString +day[0..1] : CharacterString
<<Type>>
DateTime
Figura 5 - Tipos de fecha y hora
6.5.2.9 Time (Hora)
Un time está determinada por una hora, minuto y segundo. La Figura 5 muestra los tipos
de time. La codificación de caracteres de un time es una cadena que sigue el formato de
ISO 8601. El huso horario de acuerdo con el tiempo universal coordinado (UTC) es
opcional. La codificación se aborda con más detalle en ISO 19118 e ISO 19136. Los
principios para date y time se analizan con más profundidad en ISO 19108.
EJEMPLO
18:30:59 ó 18:30:59+01:00.
6.5.2.10 DateTime (Fecha Hora)
Un DateTime es una combinación de un tipo de fecha y hora. La Figura 5 muestra los

tipos de DateTime. La codificación de caracteres de un DateTime debe cumplir con
ISO 8601. La codificación se aborda con más detalle en ISO 19118 e ISO 19136. Los
principios para fecha y hora se analizan con más profundidad en ISO 19108.
18
NCh-ISO 19103
6.5.2.11 Boolean
La Figura 6 muestras valores que especifican VERDADERO (true) o FALSO (false).
EJEMPLO
VERDADERO (true) o FALSO (false).
<<Type>>
Truth
{truthValue>= 0,0}
+truthValue (): Real {truthValue<= 1,0}
<<Type>> <<Type>>
ContinuousTruth DiscreteTruth
<<Type>> <<enumeration>> <<enumeration>>

Probability Boolean Logical
+value : Real +TRUE = 1 +TRUE = 1
+ FALSE = 0 +FALSE= 0
+=(b : Boolean) : Boolean +MAYBE = 0,5
+or(b : Boolean) : Boolean +=(b : Logical) : Logical
{truthValue () = value} +xor(b : Boolean) : Boolean +or(b : Logical) : Logical
+and(b : Boolean) : Boolean +xor(b : Logical) : Logical
+implies(b : Boolean) : Boolean +and(b : Logical) : Logical
+not() : Boolean +implies(b : Logical) : Logical
+not() : Logical
Figura 6 - Tipos de datos de verdad
6.5.2.12 Logical (Lógico)
Logical es un valor que especifica VERDADERO (true), FALSO (false) o TAL VEZ (maybe)
(DESCONOCIDO).
6.5.2.13 Probability (Probabilidad)
Probability es representada como un número mayor o igual que 0,0 y menor o igual
que 1,0.
19
NCh-ISO 19103
6.5.2.14 Multiplicity (Multiplicidad)
Multiplicity define límites inferiores y superiores del número de instancias posibles, como
se muestra en Figura 7.
<<Type>>
Multiplicity
+range 1..*
<<Type>>
MultiplicityRange
{lower >= 0}
+lower : Integer
{upper >= lower}
+upper : UnlimitedInteger
Figura 7 - Multiplicidad
20
NCh-ISO 19103
6.5.3 Tipos de colección y diccionario
Un tipo de colección es un tipo de patrón que contiene ocurrencias múltiples de instancias

de un tipo específico. Hay distintos tipos de colecciones: set, bag y sequence. Tienen
distintas semánticas respecto del orden de los elementos y las posibles operaciones
permitidas en la colección. Un tipo de colección usualmente no tiene un límite superior,
esto es, un límite en el número de elementos. El tipo de colección es un tipo patrón
porque asume un tipo como un argumento. El tipo de elemento en la colección se
proporciona como un argumento. Se puede especificar el número máximo de elementos
como una restricción.
La principal diferencia entre tipos de colección en esta norma y el Lenguaje de Especificación

de Restricciones (OCL) es la inclusión del TransfiniteSet (ver Figura 8).
T
<<Interface>>
TransfiniteSet
+includes(element : T) : Boolean
+includesAll(set: TransfiniteSet) : Boolean
+subSet(set: TransfiniteSet) : Boolean
+intersects(set: TransfiniteSet) : Boolean
+equals(set: TransfiniteSet) : Boolean
+union(set: TransfiniteSet) : TransfiniteSet<T>
+intersection(set : TransfiniteSet) : TransfiniteSet<T>
+ symmetricDifference(set : TransfiniteSet<T>) : TransfiniteSet<T>
+difference(set: TransfiniteSet) : TransfiniteSet<T>
+isEmpty() : Boolean
+notEmpty() : Boolean
+contains(set: TransfiniteSet<T>) : Boolean
+contains(element : T) : Boolean
T
<<Type>>
Collection
Figura 8 - Tipo de colección
Los protocolos que no dependen de una creación de instancias explícita de la agrupación

de un conjunto se han trasladado a este nivel de superclase para definir el
comportamiento de los conjuntos de tamaños posiblemente infinitos. La creación de
instancias de este conjunto se tendría que realizar implícitamente, a través de una prueba
booleana, en vez de una enumeración explícita de miembros. A veces es útil especificar y
analizar un conjunto que no se ha instanciado expresamente.
21
NCh-ISO 19103
6.5.3.2 Set (Conjunto)
Un Set es una colección finita de objetos, en que cada objeto aparece en la colección sólo
una vez. Un set no debe contener ninguna instancia duplicada. No se especifica el orden
de los elementos del set. El modelo para el Set se muestra en Figura 9.
El tipo genérico que será instanciado es el Set<T>, donde T es el tipo de dato de los
elementos legales.
EJEMPLO
Set<GM_Point> es instanciado del genérico Set<T>, en que T es el tipo de dato de los elementos legales.
T
<<Type>>
Collection
T
<<Type>>
Set
+size : Integer
+select(expr : OCL) : Set<expr.type>
+reject(expr : OCL) : Set<expr.type>
+iterate(expr : OCL) : expr. evaluationType
+forAll(expression : CharacterString) : Boolean 0..* <<parameter>>
+sum() : T 1 +elements T
+size() : Integer
+exists(expression : CharacterString) : Boolean
+union(other: Bag<T>) : Set<T>
+including(object : T) : Set <T>
+excluding(object : T) : Set <T>
+asSequence(): Sequence<T>
+asBag (): Bag<T>
Figura 9 - Tipos de colección - Tipo de conjunto
22
NCh-ISO 19103
6.5.3.3 Bag (Multiconjunto)
Un Bag puede contener instancias duplicadas. Tal como en un Set, no hay un orden
especificado entre los elementos de un bag. Los bags por lo general son implementados a
través del uso de proxies o punteros de referencia. El modelo para el Bag se muestra
en Figura 10.
El tipo genérico que será instanciado es Bag<T>, en que T es el tipo de dato de los
elementos del bag.
EJEMPLO
Bag<Integer> es instanciado del genérico Bag<T>, en que T es el tipo de dato de los elementos legales.
T
<<Type>>
Collection
T
<<Type>>
Bag
+union(other: Bag<T>) : Bag<T>
+union(other: Set<T>) : Bag<T>
+asSequence(): Sequence <T>
+asSet() : Set<T>)
+collect(expr : OCL) : Bag <expr.type>
+excluding(object : T) : Bag <T>
+including(object : T) : Bag <T>
+reject(expr : OCL) : Bag <expr.type>
+select(expr : OCL) : Bag <expr.type>
count : Integer
0..* +element
<<parameter>>
T
Figura 10 - Tipos de colección - Tipo de Multiconjunto
23
NCh-ISO 19103
6.5.3.4 Sequence (Secuencia)
Una Sequence es una estructura similar a un Bag que ordena las instancias de elementos.
Esto significa que un elemento se puede repetir en una sequence. Las sequences se
pueden usar como listas o matrices. Las matrices usadas en lenguajes de programación
son sequences que pueden ser indexadas directamente por un desplazamiento (offset)
desde el principio de la sequence. Si bien las listas no son semánticamente equivalentes a
las matrices, los detalles de las diferencias se dan en la implementación y no afectan la
interfaz polimórfica descrita acá.
Una sequence es una colección que especifica un orden secuencial entre sus elementos.
Un sinónimo de sequence es Lista. Una CircularSequence no tiene un elemento final
definido. El modelo para la Sequence se muestra en Figura 11.
T
<<Type>>
Collection
T
<<Type>>
Sequence
+length + Integer
+first() : Record<T, Integer = 1>
+last() : Record<T, Integer = length>
+tail(): Sequence<T>
+at(position : Integer) : T
+prepend(element : T) : Sequence<T> 1..* 0..1
+deleteFirst(): Sequence<T> <<parameter>>
offset: Integer
+deleteAt(position : Integer): Sequence<T> T
+deleteLast(): Sequence<T> +element
+asSet() : Set<T>
+subSequence(begin : Integer, end : Integer) : Sequence<T>
+concatenate(tail: Sequence<T>) : Sequence<T>
+collect(expr : OCL) : Sequence<expr.type>
+reverse(): Sequence<T>
+append(element : T) : Sequence<T>
T
<<Type>>
CircularSequence
+last() : NULL
+asSequence(firstObject : T) : Sequence<T>
Figura 11 - Tipo de colección - Tipo de secuencia
24
NCh-ISO 19103
El tipo genérico que será instanciado es Sequence<T>, en que T es el tipo de dato de los
elementos de la sequence.
EJEMPLO
Sequence<String> es instanciado del genérico Sequence<T>, en que T es el tipo de dato de los elementos.
Las sequences se pueden utilizar directamente como un tipo patrón de un atributo de

UML, como en Sequence<T>, en que T puede ser cualquier tipo, o como en definiciones
de tipos.
6.5.3.5 Dictionary (Diccionario)
Un dictionary es similar a una matriz, excepto que el índice de consulta para una matriz se
expresa en números enteros. Si bien se puede aceptar cualquier tipo de índice (KeyType)
o tipo de retorno (ValueType), el uso tradicional en esta norma se debe emplear para
cadenas de caracteres como KeyType y números como el ValueType (ver Figura 12).
KeyType
ValueType
<<Type>>
Dictionary
+select(key: KeyType) : ValueType
+insert(key: KeyType) : value : ValueType) : Boolean
+delete(key Key: KeyType) : Boolean
+keyList(): Sequence<KeyType>
<<bind>>
{KeyType, ValueType}
+elements 0..*
KeyType
ValueType
<<Type>>
KeyValuePair
+key : KeyType
+value : ValueType
Figura 12 - Clases de diccionario
25
NCh-ISO 19103
6.5.4 Tipos enumerados
Tipos de enumeración
enum { value1, value2, value3 }
Una declaración de tipo enumerado define una lista de identificadores nemotécnicos

válidos. Los atributos de un tipo enumerado pueden tomar valores solo de esta lista.
EJEMPLO
attr1 : BuildingType, donde BuildingType se define como Enum BuildingType {Público, Privado, Turístico}.
6.5.4.2 Enumeration (Enumeración)
Las enumeraciones se modelan como clases que son estereotipadas como

<<Enumeration>>. Una clase de enumeración puede contener sólo atributos simples
que representen los valores de enumeración. Se evita otras informaciones dentro de una
clase de enumeración. Una enumeración es un tipo de dato que define un usuario y cuyas
instancias forman una lista de valores designados literalmente. Generalmente se declaran
tanto el nombre de la enumeración como sus valores literales. La extensión de un tipo de
enumeración implicará una modificación del esquema para la mayoría de los mapas de
implementación y nadie debe usar la numeración cuando solo está confirmado que no
debe haber extensiones. Si se prevén extensiones, se debería usar el tipo
<<CodeList>>. Ejemplo de una enumeración se muestra en Figura 13.
<<Enumeration>>
Weekday
+Monday
+Tuesday
+Wednesday
+Thursday
+Friday
+Saturday
+Sunday
Figura 13 - Ejemplo de enumeración
6.5.4.3 CodeList (Lista de Códigos)
El CodeList se puede emplear para describir una enumeración abierta. Esto significa que se
necesita representar de forma tal que se pueda extender durante el tiempo de ejecución
del sistema. <<CodeList>> es una enumeración flexible que usa valores de cadena a
través de un enlace de la clave del tipo Diccionario y valores de retorno como tipos de
cadenas; por ejemplo, Diccionario (CharacterString, CharacterString). Las listas de códigos
son útiles para expresar una larga lista de potenciales valores. Si todos los elementos de
la lista son conocidos se debe usar una enumeración; si sólo son conocidos los valores
26
NCh-ISO 19103
probables de los elementos, se debe emplear una lista de códigos. Las listas de códigos
enumerados se pueden codificar de acuerdo con una Norma Internacional, tal como
ISO 3166-1. Las listas de códigos tienen más probabilidades de que sus valores sean
expuestos al usuario y son, por lo tanto, a menudo nemotécnicos. Distintas
implementaciones tienen más probabilidades de usar diferentes esquemas de codificación
(con tablas de traducción de vuelta a otros esquemas de codificación disponibles). La
representación escogida por una implementación de una codelist apunta a representar los
pares valor/código (clave) como atributos con una <<CodeList>> estereotipada con un
nombre de atributo para cada valor y el código (clave) representado como valor inicial. En
el caso en que sólo se muestran los nombres de los atributos, los códigos y sus
descripciones son equivalentes. Ejemplos de CodeList se muestran en Figura 14.
<<CodeList>>
MD_DimensionNameType
+row
+column
+vertical
+track
+crossTrack
+line
+sample
<<CodeList>>
SourceCodelist
+Orto500=600
+Orto1000=601
+Orto2000=602
+Orto5000=603
+Orto10000=604
+Orto20000=605
+Orto50000=606
+Digit500=610
+Digit1000=611
+Digit2000=612
+Digit5000=613
+Digit10000=614
+Digit50000=615
Figura 14 - Ejemplos de ListasdeCódigos
27
NCh-ISO 19103
6.5.5 Tipos de representación: Record y RecordType (Registro y Tipo de Registro)
Un Record es una lista de elementos relacionados por lógica como pares (nombre, valor)
en un Diccionario. Un Record se puede emplear como una representación de una
implementación para features (ver Figura 15).
<<Type>>
<<Type>> Schema
RecordSchema +schemaName : LocalName
+asRecordSchema(): RecordSchema
+locate(name : TypeName) : RecordType
+locate(name : TypeName) : Type
type : TypeName
type : TypeName
0..*
0..* +schema
TypeList
TypeList
1 +description
<<Type>> Attributes
RecordType
attributeMember : MemberName
+locate(name : MemberName) : TypeName
+memberType 1 +description
0..1 +recordType 1
<<Type>>
RecordType Type
+typeName : TypeName
+ RecordTypeRepresentation () : RecordType
record
0..*
<<Type>>
Record
attributeMember : MemberName
+memberValue
+locate(name : MemberName) : Any 1
<<Type>>
Any
{forEvery n : MemberName -> locate(n) = memberValue (n)}

-- Record acts as a dictionary on its attributes
{forEvery n : MemberName -> is TypeOf.memberValue(n)(recordType.memberType(n))}

-- the type of each attribute is given in the associated RecordType
Figura 15 - Tipos de registros
28
NCh-ISO 19103
6.5.6 Names (Nombres)
El GenericName y sus subclases se emplean para crear una estructura de nombre local y
de alcance genérico para nombres de tipos y atributos en el contexto de namespaces.
6.5.6.2 NameSpace (Espacio de nombre)
El NameSpace define un dominio en que los "nombres" dados por cadenas de caracteres
(posiblemente bajo restricciones locales determinadas por NameSpace) se pueden asignar
a objetos a través de la operación getObject. Algunos ejemplos son objetos que forman un
NameSpace para sus atributos, operaciones y asociaciones, o esquemas que forman
NameSpace para sus tipos de datos o clases incluidos. El modelo para el NameSpace y los
tipos de Nombres se muestran en Figura 16.
<<Type>>
NameSpace
+isGlobal() : Boolean
+acceptableClassList [0..*] : TypeName = {Any}
+name(): GenericName
+select(name : GenericName) : Any
+locate(name : LocalName) : Any
+generateID(registeredObj : Any) : LocalName
+registerID (aName: LocalName, registeredObj : Reference<Any>) : Boolean
+unregisterID (aName: LocalName, registeredObj : Reference<Any>) : Boolean
1
+scope
Scope
+name
0..*
<<Type>>
GenericName
+getObject() : Any
+parsedName() : Sequence<LocalName>
+depth() : Integer
<<Complete>>
<<Type>> <<Type>>
LocalName {depth=1} ScopedName
{self=parsedName()}
+aName(): CharacterString +head() : LocalName
+tail(): GenericName
+push(new : GenericName) : ScopedName
+scopedName() : CharacterString
<<Type>> <<Type>>
{head().scope=scope}
TypeName MemberName
{push(head()).tail=self}
{push(S:Scope).scope=S}
+aName(): CharacterString +aName():CharacterString
+attributeType : typeName
Figura 16 - Tipos de nombres
29
NCh-ISO 19103
6.5.6.3 GenericName (Nombre Genérico)
GenericName es la clase abstracta para todos los nombres en un NameSpace. Cada

instancia de un GenericName es un LocalName o ScopedName.
6.5.6.4 ScopedName (Nombre de Alcance)
El ScopedName es un compuesto de un LocalName para ubicar otro NameSpace y un

GenericName válido en ese NameSpace. El ScopeName contiene un LocalName como
cabeza y un GenericName, que puede ser un LocalName o un ScopedName, como cola.
6.5.6.5 LocalName (Nombre Local)
Un LocalName hace referencia a un objeto local al que se puede acceder directamente

desde el NameSpace.
6.5.6.6 TypeName (Nombre de Tipo)
Un TypeName es un LocalName que hace referencia a un RecordType o un tipo de objeto

en algún esquema. El valor almacenado “aName” es el valor de retorno para la operación
“aName()”. Este es el nombre de tipos.
6.5.6.7 MemberName (Nombre de Miembro)
Un MemberName es un LocalName que hace referencia a un intervalo de atributos en un

registro o RecordType, un atributo, operación o rol de asociación en una instancia de
objeto o una descripción de tipos en algún esquema. El valor almacenado “aName” es el
valor de retorno para la operación “aName()”.
30
NCh-ISO 19103
6.5.7 Tipos derivados
La Figura 17 entrega una visión general de las unidades de tipos de datos de medida que
se describen en las cláusulas siguientes.
<<Type>> - Conversion TolSOstandardUnit is not null

UnitOfMeasure only of the conversion is a simple scale
+uomName: CharacterString
+uomSymbol: CharacterString +subunit
<<Type>>
+measureType : MeasureType 0..1
SubUnitsPerUnit
+nameStandardUnit[0..1] : CharacterString
+scaleToStandardUnit[0..1] : Real
+factor : Number
+offsetToStandardUnit[0..1] : Real 0..*
+formula[0..1] : CharacterString
+convert ToStandard(m : Measure) : Measure
+convert FromStandard(m : Measure) : Measure +uom_r UnitOfMeasure <<CodeList>>
+convert To(m : UnitOfMeasure) : Measure 1 StandardUnits
+convert From(m : Measure) : Measure +meter
+second
+radian
+square meter
+cubic meter
<<Type>> <<Type>> <<Type>> <<Type>>
+meters/second
UomArea UomAngle UomTime UomVelocity
+meter/meter
+kilogram
UomLength UomScale UomVolume UomCurrency
<<Type>>
<<CodeList>>
Measure
UnitsList
+measure
+value : Number
0..* +foot
+squareFoot
+ convert(target : Unit Of Measure) : Measure
+cubicYard
<<CodeList>>
<<Type>> <<Type>> <<Type>> <<Type>> <<Type>>
MeasureType
Length Angle Time Volume Weight
+area
+length
+angle
+time
Velocity Scale Area Currency
+velocity
+volume
+scale
<<Type>>
+weight
Distance
Figura 17 - Unidades de tipos de medidas
31
NCh-ISO 19103
6.5.7.2 Measure (Medida)
Measure es el resultado de realizar un acto o proceso de verificar el valor de una

característica de algún feature.
6.5.7.3 UnitOfMeasure (Unidad de Medida, Udm)
Una unidad de medida es una cantidad adoptada como norma de medición para otras
cantidades del mismo tipo. El rol de udm (ver Figura 17) está restringido por el valor del
atributo udm en cada subclase de Medida.
6.5.7.4 Area
El área es la medida de la extensión física de cualquier objeto geométrico bidimensional.
6.5.7.5 UomArea (Area de Udm)
UomArea es alguna de las cantidades de referencia usada para expresar el valor del área.
Las unidades comunes incluyen unidades de longitud al cuadrado, tales como metros
cuadrados y pies cuadrados. Otras unidades comunes comprenden los acres (en Estados
Unidos) y las hectáreas.
6.5.7.6 Length (Longitud)
Length es la medida de distancia como una integral; por ejemplo, la longitud de una curva,
el perímetro de un polígono como longitud de límite.
6.5.7.7 Distance (Distancia)
Distance se usa como un tipo (type) para establecer la separación entre dos puntos.
6.5.7.8 UomLength (Longitud de Udm)
UomLength es alguna de las cantidades de referencia usada para expresar el valor de la

longitud o distancia entre dos entidades. Ejemplos son el Sistema Inglés de pies y
pulgadas o el sistema métrico de milímetros, centímetros y metros, también el Sistema
Internacional (IS) de Unidades.
6.5.7.9 Angle (Angulo)
Angle es la cantidad de rotación requerida para insertar una línea o plano en coincidencia
con otro, se mide generalmente en radianes o grados.
32
NCh-ISO 19103
6.5.7.10 UomAngle (Angulo de Udm)
UomAngle es alguna de las cantidades de referencia usada para expresar el valor de los
ángulos. En Estados Unidos, se suele utilizar el sistema sexagesimal de grados, minutos y
segundos. También se usa el sistema de medición con radianes. En otras partes del
mundo, se usa el sistema de medición de ángulo en grados, gon.
6.5.7.11 Scale (Escala)
Scale es la proporción de una cantidad con otra, a menudo sin unidades.
6.5.7.12 UomScale (Escala de Udm)
UomScale es alguna de las cantidades de referencia usada para expresar el valor de escala
o la proporción entre cantidades con la misma unidad. Los factores de escala a menudo
no tienen unidades.
6.5.7.13 Time (Tiempo)
Time es la designación de un instante en una escala de tiempo seleccionada, astronómica

o atómica. Se usa en el sentido de tiempo del día.
6.5.7.14 UomTime (Tiempo de Udm)
UomTime es alguna de las cantidades de referencia usada para expresar el valor o el

cálculo del paso del tiempo y/o fecha (por ejemplo, segundos, minutos, días, meses).
6.5.7.15 Volume (Volumen)
Volume es la medida del espacio físico de cualquier objeto geométrico tridimensional.
6.5.7.16 UomVolume (Volumen de Udm)
UomVolume es alguna de las cantidades de referencia usada para expresar el valor del
volumen.
6.5.7.17 Velocity (Velocidad)
Velocity es la proporción instantánea del cambio de posición en el tiempo. Generalmente

se calcula con una fórmula simple, el cambio de posición durante un cierto intervalo de
tiempo.
6.5.7.18 UomVelocity (Velocidad de Udm)
UomVelocity es alguna de las cantidades de referencia usada para expresar el valor de

velocidad.
33
NCh-ISO 19103
6.5.7.19 AngularVelocity (Velocidad Angular)
AngularVelocity es la proporción instantánea del cambio del desplazamiento angular en el

tiempo.
6.5.7.20 UomAngularVelocity (Velocidad Angular de Udm)
UomAngularVelocity es alguna de las cantidades de referencia usada para expresar el

valor de la velocidad angular.
6.5.8 Valores NULO y VACIO
Varias de las operaciones definidas en esta norma usan NULO y VACIO como valores
posibles. NULO significa que el valor solicitado no está definido. Esta norma supone que
todos los valores NULO son equivalentes. Si se devuelve un NULO cuando se solicita un
objeto, esto significa que no existe objeto que cumpla los criterios especificados. VACIO
se refiere a objetos que se pueden interpretar como conjuntos sin elementos. A diferencia
de sistemas de programación que entregan agregados fuertemente tipificados, esta norma
usa la tautología matemática de que hay uno y sólo un conjunto vacío. Cualquier objeto
que represente el conjunto vacío es equivalente a cualquier conjunto que tiene lo mismo.
Además, de estar vacío, tales conjuntos carecen de información inherente, y por tal
motivo un valor NULO se presume equivalente a un conjunto VACIO en el contexto
apropiado.
6.6 Operaciones
Las operaciones se usan de acuerdo con la norma UML como se describe en Anexo D,
cláusula D.6.
6.7 Relaciones y asociaciones
Las relaciones y asociaciones se usan según la norma UML, con los requisitos adicionales
especificados en esta subcláusula.
Todas las asociaciones deben tener cardinalidades definidas para ambos extremos de las
asociaciones. Al menos se debe definir un nombre de rol. Si sólo se define un nombre de
rol, el otro debe ser por defecto inv_rolename.
Si una asociación es navegable en una dirección particular, el modelo debe proveer un

nombre de rol que sea apropiado para el rol del objeto al que se apunta en relación con el
objeto fuente. Por tal motivo, en una asociación de doble sentido se deben entregar dos
nombre de roles. El rol predeterminado es el <target class name> en que la clase de
objeto hace referencia a la clase fuente (este es el nombre por defecto en muchas
herramientas de UML). Los nombres de asociaciones se destinan principalmente a
propósitos de documentación.
34
NCh-ISO 19103
Se deben evitar las relaciones que impliquen más de dos clases para reducir la
complejidad. La cardinalidad para asociaciones se especifica como especificaciones de
multiplicidad de UML.
Una asociación con nombres de roles se puede considerar como similar a la definición de
atributos para las dos clases involucradas, con la limitante adicional que actualizaciones y
supresiones son manejadas con consistencia para ambos extremos. Para asociaciones en
dirección única se vuelve por lo tanto equivalente a una definición de atributo. Por ende,
un rol sirve como un pseudoatributo. La recomendación para las normas ISO de
información geográfica es emplear la notación de la asociación para clases e interfaces, y
utilizar la notación de un atributo para tipos de datos.
6.8 Estereotipos y valores etiquetados
6.8.1 Generalidades
Los estereotipos y valores etiquetados se usan de acuerdo con la norma UML, como se
describe en Anexo D, cláusula D.8, con un conjunto adicional de estereotipos.
6.8.2 Estereotipos
En esta norma, se definen los estereotipos siguientes:
a) <<CodeList>> es una enumeración flexible que usa valores de cadena a través de

un enlace de la clave del tipo Diccionario y valores de retorno como tipos de cadenas;
por ejemplo, Diccionario (Cadena, Cadena). Si los elementos de la lista son
completamente conocidos, se debe usar una enumeración; si sólo son conocidos los
valores probables de los elementos, se debe emplear una lista de códigos.
b) <<Leaf>> es un paquete que contiene definiciones, sin subpaquetes.
c) <<Union>> es un tipo que consiste en una y sólo una de las varias alternativas
(enumeradas como atributos de miembros). Esto es similar a una unión discriminada
en muchos lenguajes de programación. En algunos lenguajes que usan punteros, se
requiere un puntero vacío que se pueda adaptar al tipo apropiado como está
determinado por un atributo discriminador.
Los estereotipos son esenciales en la creación de generadores de código para modelos de

UML. En términos generales, los estereotipos actúan como banderas para los compiladores de
idiomas para determinar la forma de crear modelos de implementación desde lo abstracto.
Enumeration y CodeList son ejemplos importantes de esto. A diferencia de la creación de una
clase, estas clases generan dominios de valor menor, uno por atributo en el modelo. En una
Enumeration, estos valores generalmente están representados por un código de número 1-up
para los atributos enumerados y se presume que la lista estará completamente definida en la
Especificación/Abstracta. En CodeList, los valores de códigos no se especifican y la lista es
extensible en cualquier momento. Por ejemplo, CodeList se pueden usar para implementar los
códigos ISO de países e idiomas que se suelen emplear en las especificaciones de metadatos.
35
NCh-ISO 19103
6.9 Atributos y asociaciones obligatorios, opcionales y condicionales
6.9.1 Obligatorios
En UML, todos los atributos son obligatorios por defecto. La posibilidad de mostrar la
multiplicidad para los atributos y nombres de roles de asociación entregan una forma de
describir atributos opcionales y condicionales.
Un atributo que tiene una multiplicidad con un límite menor de 1 es obligatorio.
NOTA - La multiplicidad predeterminada para los atributos es 1.
Es obligatoria una asociación que tenga una multiplicidad con un límite menor que 1 en el
extremo objetivo para la clase en el extremo fuente.
6.9.2 Opcionales
Una multiplicidad de 0..1 ó 0..* significa que un atributo o asociación se puede presentar
u omitir, lo que significa que es opcional.
La forma más apropiada de especificar lo opcional es emplear un valor etiquetado. Sin

embargo, dado que distintas herramientas tienen diversas formas de manejarse y
presentar valores etiquetados, se utiliza la multiplicidad por un tema de legibilidad. Lo
opcional significa que un valor nulo se debe representar en el modelo de instancia, por
ejemplo, un elemento de un espacio reservado o valor nulo. Un atributo opcional o
condicional no debe tener nunca un valor predeterminado definido.
6.9.3 Condicionales
Un atributo o asociación se puede especificar como condicional, lo que significa que su

obligatoriedad u opcionalidad depende de otros elementos del modelo. Las dependencias
pueden ser por existencia-dependencia de otros elementos (opcionales) o por los valores
de otros elementos. Un atributo o asociación condicional se muestra como opcional con
una limitante OCL adjunta.
6.10 Denominación y espacios de nombres
Las convenciones de denominación se usan por una variedad de razones, principalmente

de legibilidad, consistencia y como protección contra restricciones de casos sensibles.
Los nombres de elementos de UML deben:
1) Usar nombres técnicos precisos y comprensibles para clases, atributos, operaciones y

parámetros.
- Correcto: índice.
36
NCh-ISO 19103
- Incorrecto: n.
- Los nombres cortos de parámetros se deben usar cuando el tipo de parámetro

lleva un significado; usa Iguales(other: GM_Object) opuesto a
Iguales(otherGeometryObject: GM_Object).
2) Combinar múltiples palabras como se requiera para formar nombres precisos y

comprensibles sin usar ningún caracter de intervención (tales como "_", "-" o
espacio).
EJEMPLO
ComputePartialDerivatives (no: Compute Partial Derivatives o Compute_Partial_Derivatives).
3) Para nombres de atributos y operaciones, los roles y parámetros de asociación, se

escribe en mayúscula sólo la primera letra de cada palabra tras la primera palabra que
se combina en un nombre. Escribir en mayúscula la primera letra de la primera Palabra
de cada nombre de clase, paquete, especificación de tipo y nombres de asociación.
EJEMPLOS
1) ComputePartialDerivatives (no computepartialderivatives o COMPUTEPARTIALDERIVATIVES).
2) (Class): CoordinateTransformation (no coordinateTransformation).
4) Utilizar campos de documentación para explicar con más profundidad el significado

(semántica) de los nombres.
5) Mantener los nombres tan cortos como sea práctico. Usar abreviaciones normalizadas
si son comprensibles, evitar las preposiciones y eliminar verbos cuando no son tan
importantes para el significado del nombre.
- numSegment en vez de numberOfSegments;
- equals en vez de IsEqual;
- value() en vez de getValue();
- initObject en vez de initializeObject; y
- length() en vez de computeLength().
Todas las clases deben tener nombres únicos. Todas las clases se deben definir con
algunos paquetes. Los nombres de clases deben empezar con una letra mayúscula. Una
clase no debe tener un nombre que se base en su uso externo, porque esto podría limitar
su reutilización. Un nombre de clase no debe contener espacios. Las palabras separadas
en un nombre de clase deben estar ligadas. Cada subpalabra en un nombre de clase debe
comenzar con una letra mayúscula, tal como "XnnnYmmm".
37
NCh-ISO 19103
Para garantizar la exclusividad global de los nombres de clase, cada uno de ellos se debe
definir con un prefijo alfabético separado del cuerpo del nombre por una línea subrayada
"jj". Estos prefijos son esencialmente especificadores de espacios de nombre y se usan
dentro de la serie de normas ISO 19100 para impedir la confusión sin usar los prefijos de
nombre del paquete completo en cada lugar donde se usa un nombre de clase. La mayoría
de los prefijos son dos caracteres, pero algunos tienen tres caracteres y se pueden referir
a prefijos comunes de espacios de nombre de XML. Los prefijos deben hacer referencia a
límites de paquetes para que todas las clases dentro de un paquete de alto nivel
compartan el mismo prefijo y que ningún par de paquetes de alto nivel compartan un
prefijo. La norma ISO 19107 usa el prefijo GM en su modelo de geometría y en prefijo TP
en su modelo de topología. Otros prefijos se han definido para otras áreas. No se requiere
el uso de prefijos de nombres de clases en implementaciones donde se manejan
adecuadamente los espacios de nombres.
El nombre de una asociación debe ser único dentro del contexto de una clase y sus
supertipos.
En la mayoría de los casos que usa OCL, el espacio de nombre es la clase en que la
operación se define, pero también puede incluir el nombre del paquete en que se define
una clase. Donde los espacios de nombres son identificadores de clases, pueden tomar
sólo una de dos formas.
tipo :== class-name | package-name::class-name
El "::" es un operador de resolución que indica el espacio del nombre de lo que sigue.
A menos que haya una posible confusión o la necesidad de enfatizar, no se incluye el

nombre del paquete.
El alcance de denominación de UML con package:: package::className permite que sea

definido el mismo className en distintos paquetes. Sin embargo, muchas herramientas
de UML no permiten esto actualmente. Por tal motivo, se adoptó una convención de
denominación más restrictiva:
- Si bien en el modelo son sensibles los casos, todos los nombres de clases deben ser
únicos en los casos no sensibles.
- El nombre de clase debe ser único en todo el modelo (para así no crear un problema
con muchas herramientas de UML).
- Los nombres de paquetes deben ser únicos en todo el modelo (por la misma razón).
- Todos los esfuerzos deberían apuntar a eliminar clases múltiples que ejemplifican el
mismo concepto.
38
NCh-ISO 19103
6.11 Paquetes
Los paquetes se deben estructurar de acuerdo con una estructura de tres niveles como se
detalla a continuación:
1) Las estructuras de nivel superior se usan para estructurar varias partes principales de
un modelo.
2) Los paquetes de segundo nivel (internos) contienen sólo otros subpaquetes.
3) Los paquetes de tercer nivel (hoja) contienen sólo diagramas de clase.
Esta estructura de tres niveles permite que sea más claro el significado de las
dependencias del paquete. También se debe usar un paquete para representar un
esquema de aplicación. Un esquema de aplicación que contiene algún paquete definido en
otro esquema también debe contener todas sus subordinaciones. Los esquemas de
aplicación deben contener al menos un diagrama de paquetes que especifique las
dependencias entre el paquete definido por las normas ISO de información geográfica y
los paquetes definidos por el esquema de aplicación. Un ejemplo de estructura de paquete
de subordinaciones entre las normas ISO se muestra en Figura 18.
ISO 19112 - Establecimiento de ISO 19123 - Esquema para la cobertura

referencias espaciales mediante de geometría y funciones
Identificadores geográficos
ISO/TS 19103 - Lenguaje de

esquema conceptual
ISO 19115 - Metadatos
ISO 19107 - Esquema ISO 19111 - Establecimiento de

espacial referencias espaciales mediante
coordenadas
ISO 19109 - Reglas para el

esquema de aplicación
Figura 18 - Ejemplo de estructura de paquete

39
NCh-ISO 19103
Los paquetes de hoja dependen unos de otros si sus objetos contenidos dependen uno de
otro. Los paquetes internos son dependientes sólo si, en algún punto, una de sus hojas
depende de las hojas de otros. En realidad, sólo se deben mostrar las dependencias hoja a
hoja. La extensión de dependencias más allá de la hoja es redundante y difícil de
mantener.
Los paquetes de UML se deben usar para agrupar clases y sus asociaciones. Algunas
reglas que hacen esto son:
- Todas las clases deben ser parte de algún paquete UML definido.
- Si la clase de componente de un paquete se usa en otro diagrama de paquetes, ese

diagrama debe hacer referencia al paquete original al que pertenece la clase.
6.12 Notas
Las notas son especificadas de acuerdo con la norma UML (ver Anexo D, cláusula D.12).
6.13 Restricciones
Las restricciones se especifican según la norma UML OCL, Lenguaje de Restricciones de

objeto (ver Anexo E, Bibliografía, [3]) (ver Anexo D, cláusula D.12).
6.14 Documentación de modelos
Además de la presentación del modelo en diagramas, es necesario documentar la

semántica del modelo. Se debe explicar el significado de los atributos, asociaciones,
operaciones y restricciones. Se sugiere el siguiente patrón para modelos de
documentación.
Para los diagramas, se deben tener en cuenta lo relativo a la legibilidad. El tamaño del tipo
de letra no debe ser menor que 8 puntos luego de que se considere la escala del diagrama
(un tamaño de letra de 12 puntos a 90% es 12 * 0,9 = 10,8 puntos). Cada paquete
debe tener un diagrama de clase para todo el paquete (sin mostrar ninguna asociación,
operación o atributo).
Cada clase debe tener un diagrama de contexto (se muestran todas sus asociaciones,
firmas de operación y atributos). Cada clase debe tener una definición que describa su
significado o semántica deseada. Cada operación, atributo y relación debe tener una
descripción textual en el texto cerca de su diagrama de contexto. Hay que destacar que
las clases íntimamente ligadas comparten un diagrama de contextos siempre y cuando el
diagrama combinado no esté excesivamente confuso ni sea difícil de leer.
La mayoría de los diagramas en las partes de normas deben ser diagramas de contexto
que se centran en una sola clase y presentan sus atributos, operaciones y relaciones
importantes.
40
NCh-ISO 19103
Se deben considerar diagramas de dependencia de paquetes, incluidas dependencias de

paquetes externos. Se pueden incluir diagramas de visión general que consideren todas
las clases importantes de un documento si es factible.
Para cada clase debe haber una descripción textual de la semántica al menos como sigue:
<A>
Descripción general de clase A
nombre de clase: A
Especialización: una lista de superclases/supertipos
Atributos:
nombre: descripción de significado de atributos
Asociaciones:
rol: descripción de significado de rol
Operaciones:
Operación: nombre
Descripción: <text>
Precondición: <text + OCL>
Parámetros de entrada: <description>
Parámetros de salida: <description>
Valor de retorno: <description>
Excepciones: <description>
Poscondición: <text + OCL>
Restricciones: <¿alguna restricción de secuencia en el uso de esta operación con otras

operaciones?>
Otras restricciones:
Cualquier otra restricción a describir. <text + OCL>
41
NCh-ISO 19103
Anexo A
(Normativo)
Conjunto de pruebas abstractas
Para verificar el cumplimiento de los modelos UML respecto de esta norma, es necesario
comprobar que los modelos han seguido las reglas de cláusula 6 de esta norma.
a) Propósito de prueba: Verificar que se ha aplicado UML según las reglas de

ISO/TS 19103.
b) Método de prueba: Inspeccionar los diagramas y usar las capacidades de

verificación/validación de las herramientas de UML que se emplean.
c) Referencia: ISO/TS 19103.
d) Tipo de prueba: Básico.
Verificar que se han utilizado los elementos siguientes de acuerdo con 6.2 a 6.14.
- Uso general de UML.
- Clases.
- Atributos.
- Tipos de datos.
- Operaciones.
- Relaciones y asociaciones.
- Estereotipos y valores etiquetados.
- Atributos y asociaciones opcionales, condicionales y obligatorios.
- Denominación y espacios de nombres.
- Paquetes.
- Notas.
- Restricciones.
- Documentación de modelos.
42
NCh-ISO 19103
Anexo B
(Informativo)
Sobre lenguajes de esquema conceptual
La Figura B.1 muestra el enfoque de las normas ISO de información geográfica que reúnen
conceptos y tecnología de las disciplinas de información geográfica y tecnologías de la
información. Las normas ISO de información geográfica se agruparon en un principio en
cinco áreas: marco y modelo de referencia, modelos y operadores de datos,
administración de datos, servicios de información geográfica y normas de perfiles
funcionales. La entrada de información geográfica muestra lenguajes de esquema
conceptual como una de las principales entradas en este trabajo.
Un esquema conceptual clasifica los objetos en tipos y clases al identificar los tipos de
objetos de acuerdo con sus propiedades (estructura y comportamiento) y asociaciones
entre tipos de objetos.
43
NCh-ISO 19103
La Figura B.2 describe la relación entre la realidad del modelado y el esquema conceptual
resultante. Un universo de discurso es una parte seleccionada de la realidad (o un mundo
hipotético) que una persona desea describir en un modelo. Este concepto puede incluir no
sólo features como cauces, lagos, islas, límites de propiedades, dueños de propiedades y
áreas de explotación, sino también sus atributos, sus operaciones y relaciones que existen
entre dichos features. Un universo de discurso se describe en un modelo conceptual. El
esquema conceptual es una descripción rigurosa de un modelo conceptual para algún tipo
de universo de discurso. Un esquema conceptual que define el universo de discurso
relacionado con una aplicación específica o un conjunto de aplicaciones se debe
denominar un esquema de aplicación. Este tipo de esquema también define relaciones
entre elementos de modelos y restricciones sobre los elementos y sus relaciones. Estas
restricciones definen estados válidos del sistema modelado. Un universo de discurso real
se puede representar digitalmente mediante datos que se estructuran de acuerdo con la
especificación en el esquema conceptual correspondiente.
Un lenguaje de esquema conceptual se usa para describir un esquema conceptual. Este

lenguaje es formal y puede ser analizado gramaticalmente en un computador o por una
persona. Un lenguaje de esquema conceptual contiene todos los modelos lingüísticos
necesarios para construir y formular un esquema conceptual y manipular sus contenidos.
44
NCh-ISO 19103
Un lenguaje de esquema conceptual se basa en un formalismo conceptual. El formalismo

conceptual proporciona reglas, limitaciones, mecanismos de herencia, eventos, funciones,
procesos y otros elementos que conforman un lenguaje de esquema conceptual. Estos
elementos también se pueden emplear para crear esquemas conceptuales que describen
un sistema de información determinado o una norma de tecnología de la información si
éste es el universo de discurso elegido. Un formalismo conceptual proporciona una base
para la definición formal de todo el conocimiento considerado pertinente para una
aplicación de tecnología de la información. Se puede considerar más de un lenguaje de
esquema conceptual, ya sea léxico o gráfico, y que se pueda unir y asignar al mismo
formalismo conceptual.
Los esquemas conceptuales desarrollados para partes de normas ISO de información

geográfica se representan usando un lenguaje de esquema conceptual. Estos esquemas
conceptuales se integran a esquemas de aplicación que definen la estructura de datos
geográficos procesados por sistemas computacionales. La codificación de información
geográfica en apoyo a la implementación se aborda en ISO 19118.
Un trabajo anterior ISO (ISO/TR 9007) definió y fijó el principio de 100% para el
modelado conceptual (ver Figura B.3). La meta consiste en representar el 100% de los
aspectos estáticos y dinámicos del universo de discurso, lo que implica una necesidad de
representar la estructura y el comportamiento del área de interés.
45
NCh-ISO 19103
La Figura B.4 muestra las capas de metamodelos del Recurso de Modelado de Esquemas
Conceptuales (Conceptual Schema Modelling Facility o CSMF).
46
NCh-ISO 19103
El Modelo General de Features (también presentado en ISO 19109) fue desarrollado de

manera independiente de metamodelos que se han usado como orientación para definir reglas
para la aplicación del modelado de esquemas. El Modelo General de Features se concentra en
los features de modelado junto con sus atributos, relaciones y operaciones asociados. Los
atributos pueden tener asociada la calidad. El Modelo General de Features se detalla en el
modelo de UML en ISO 19109. La Figura B.5 muestra la relación del Modelo General de
Features y UML.
El Modelo General de Features identifica las siguientes relaciones especiales como

importantes para el dominio de la información geográfica:
- temporal;
- espacial (Posición/Topología);
47
NCh-ISO 19103
- calidad;
- identificador geográfico; y
- atributos temáticos.
El Modelo General de Features identifica las relaciones especiales siguientes como

importantes para el dominio de la información geográfica:
- especialización;
- agregación;
- espacial (de Posición/Topología); y
- lógica/de asociación.
48
NCh-ISO 19103
El Modelo General de Features se presenta adicionalmente en ISO 19109. La Figura B.6

muestra el núcleo de este modelo.
GF_InheritanceRelation
Generalization 0..* +name :
+description :
Specialization +exhaustive :
0..* +uniqueInstance:
+ supertype +subtype
1 1..*
<<Metaclass>>
<<Metaclass>>
GF_FeatureType +memberOf
+linkBetween GF_AssociationType
typeName:
0..* definition: 0..* 0..*
1..* 0..*
+constrainedBy
0..* +carrierOfCharacteristics
<<Metaclass>> <<Datatype>>
GF_PropertyType GF_Constraint
memberName: 0..* description :
definition:
+constrainedBy
0..* +characterizedBy
1..*
GF_Operation <<Metaclass>> AttributeOfAttribute <<Metaclass>>

GF_AttributeType GF_AssociationRole
signature:
valueType : valueType :
valueDomain : +characterizes cardinality :
cardinality : 1
0..* 0..* 0..*

+triggeredByValuesOf
+observesValuesOf
+dependsOn
+affectsValuesOf
Figura B.6 - Núcleo del Modelo General de Features ISO 19109
49
NCh-ISO 19103
La norma ISO 19109 contiene una nueva descripción de la relación entre el Modelo
General de Features y UML y el metamodelo UML. También abarca una mayor descripción
de términos como feature, asociación de features, atributo de feature y operación de
feature. La Figura B.7 muestra las partes esenciales del metamodelo central de UML.
GeneralizableElement
Association
2..n
Classifier +features Feature
AssociationEnd
0..* 0..*
1
0..* 0..*
StructuralFeature BehaviouralFeature
DataType Class
Attribute Operation
initialValue: Expression Specification
isPolymorphic : Boolean
concurrency : CallConcurrencyKind
Figura B.7 - Metamodelo central de UML
El metamodelo central UML es suficientemente similar al Modelo General de Features

ISO 19109, con pequeñas modificaciones, que se pueden usar como una línea base para
satisfacer los requisitos del Modelo General de Features.
NOTA - Feature en Figura B.7 es un concepto distinto de feature como se define en el Modelo General de
Features.
50
NCh-ISO 19103
UML se ha desarrollado en un marco de metamodelo similar a CSMF, como se muestra

en Figura B.8.
<<metamodel>> M3 Layer: Specifies

MOF Meta- meta-metaclasses for
Metamodel the UML metamodel
<<instanceOf>>
M2 Layer: Specifies
<<metamodel>> metaclasses for the UML
UML Metamodel metamodel, such as Class
<<instanceOf>>
M1 Layer: Specifies classes

User Model for the UML user models,
such as Passenger, Ticket,
TravelAgency
<<instanceOf>> <<instanceOf>>
<<instanceOf>> M0 Layer: User objects that

are instances of UML user
model classes, such as
:Foo :Bar :Baz instances of Passenger,
Ticket, TravelAgency
Figura B.8 - Arquitectura de metamodelo para UML
La norma ISO 19101 contiene información sobre el uso del enfoque del punto de vista
RM-ODP de ISO para modelar información geográfica y servicios.
A continuación se presenta una breve introducción de las metas y conceptos en cada uno
de los puntos de vista de ODP y la aplicación de estos puntos de vistas dentro de las
normas ISO de información geográfica (ver Figura B.9).
Punto de Vista
Empresarial
ISO/TC 211
Punto de Vista Punto de Vista
de la Información Computacional
UML UML
Punto de Vista de
Ingeniería
Punto de Vista
De la Tecnología
Figura B.9 - Puntos de vista del modelo RM-ODP de ISO
51
NCh-ISO 19103
El punto de vista empresarial se preocupa del propósito, el alcance y las políticas de una
empresa o negocio en relación con sistemas y servicios especificados. Una especificación
empresarial de un servicio es un modelo del mismo y el ambiente en que interactúa el
servicio. Describe los roles del servicio en el negocio, además de los roles de las personas
y las políticas de negocios relacionadas con el servicio. El punto de vista empresarial
entrega una base para definir el alcance y el contexto de los modelos conceptuales para la
información geográfica. El punto de vista empresarial debe variar entre distintas
organizaciones y de esta forma se usa sólo para la generación de requisitos. Por lo
general, no forma parte de las normas ISO de información geográfica.
El punto de vista computacional se preocupa de los patrones de interacción entre los

componentes del sistema (servicios) descritos mediante sus interfaces. Una especificación
computacional de un servicio es un modelo de las interfaces de servicios como lo ve un
cliente, junto con las interacciones requeridas que tiene este servicio con otros servicios.
Las interacciones entre servicios se pueden describir como una serie de fuentes y
colectores de información. En información geográfica, es particularmente importante la
forma en que un servicio es visto desde la perspectiva de un cliente. El punto de vista
computacional se entrega con diagramas de clases y de paquetes con implementación y
tecnología neutral UML, además de restricciones OCL. Las orientaciones para el punto de
vista computacional se describen en detalle en Anexo C.
El punto de vista de la información se preocupa de la semántica de la información y el

procesamiento de la información. Una especificación de información de un sistema ODP
es un modelo de la información que contiene y el procesamiento de información que
realiza. El modelo de información se extrae de componentes individuales y entrega una
visión común consistente sobre la información que puede entregar referencias mediante
las especificaciones de las fuentes y los colectores de información, además de los flujos
de información entre ellos. Para información geográfica, el punto de vista de la
información muestra la forma en que el modelo de información subyacente (del modelo
conceptual) se relaciona con los servicios identificados en el punto de vista
computacional. Este modelo está fuertemente ligado a los modelos de dominio de
información geográfica. Esto se debe describir con los diagramas de paquete UML,
diagramas de clase UML y restricciones de OCL (ver Anexo E, Bibliografía, [3]). Este
modelo de información es neutral en implementación y tecnología. Las orientaciones del
punto de vista de la información se describen con más detalle en Anexo C. Los aspectos
sobre el modelado de los esquemas de aplicación se describen en ISO 19109.
El punto de vista de ingeniería se preocupa del diseño de las implementaciones dentro de

sistemas computacionales distribuidos y en redes, esto es, la infraestructura requerida
para apoyar la distribución. Una especificación de ingeniería de un sistema de ODP define
una infraestructura computacional en redes que apoya la estructura de sistema definido
en la especificación computacional, y entrega las transparencias de distribución que
define. Determina los mecanismos correspondientes a los elementos del modelo de
programación, que definen con efectividad una máquina abstracta que puede realizar las
actividades computacionales y la provisión de varias transparencias para apoyar la
distribución. ODP define las siguientes transparencias de distribución: acceso, falla,
ubicación, migración, reubicación, replicación, persistencia y transacción. En las normas
52
NCh-ISO 19103
funcional en los puntos de vista de información y computacional. Dado que las normas
ISO de información geográfica se concentran en modelos neutrales de implementación, no
se otorga mucho énfasis a este punto de vista. Se asume que varias transparencias de
distribución se deben manejar en el contexto de crear modelos de implementación en el
punto de vista tecnológico.
El punto de vista tecnológico se preocupa de la entrega de infraestructura subyacente.

Una especificación tecnológica define la forma en que un sistema se estructura en
términos de componentes de hardware y software e infraestructura de apoyo subyacente.
En las normas ISO de información geográfica, es importante mostrar la forma en que se
puede asignar un servicio particular en una tecnología subyacente de implementación
como SQL-3/ODBC, ODMG, CORBA, DCOM/OLE, internet o una infraestructura similar.
También esta es un área donde se definen asignaciones de los modelos desde el punto de
vista de la información a tecnologías subyacentes con apoyo a la Información Geográfica,
como Interfaces de Programación de Aplicaciones (API) de OpenGIS para ODBC, CORBA,
COM/OLE/DB e internet. Para este punto de vista, los modelos específicos de
implementación de UML se deben crear en conformidad con los modelos neutrales de
implementación que representen los puntos de vistas de la información y computacional.
Esto se puede utilizar como un paso intermedio en la definición de especificaciones de
implementación de forma directa en un lenguaje del entorno, como CORBA IDL, COM IDL
o SQL.
La Figura B.10 muestra el modelo de referencia de arquitectura de ISO 19101. Se usa un

lenguaje de esquema conceptual para describir los servicios y los modelos de dominio
espacial que se intercambian o transfieren. Los modelos de dominio espacial incluyen el
esquema espacial, el esquema temporal y el esquema de metadatos.
53
NCh-ISO 19103
54
NCh-ISO 19103
El Lenguaje Unificado de Modelado (UML) se puede emplear para describir distintos tipos
de modelos. Los tipos de modelos se clasifican en conceptuales, de especificación y de
implementación.
Modelos conceptuales - describen el dominio en estudio, independiente de cualquier

representación computacional o de sistema del modelo.
Modelos de especificación - describen tanto los modelos de sistemas de servicios y de

dominio en una implementación de manera neutral, apropiada para más detalle en un
modelo de implementación.
Modelos de implementación - describen la ejecución de modelos de servicios de dominio y

sistema en una forma de implementación específica que se relaciona con las
características de la plataforma subyacente.
Los modelos de dominio geográfico en las normas de información geográfica ISO se han
desarrollado como modelos conceptuales y luego redefinidos nuevamente para modelos
de especificación que sean una base neutral apropiada de implementación para la
representación de sistemas y el intercambio de datos. Los modelos de servicios en las
normas ISO de información geográfica se han elaborado como modelos de especificación
para reflejar las interfaces requeridas de sistemas en una forma de implementación
neutral. Algunas partes de las normas ISO de información geográfica también describen
con más detalle modelos de implementación para modelos determinados de especificación
a fin de definir los correspondientes modelos específicos de plataforma e implementación.
Es importante destacar que el lenguaje de modelado conceptual también se puede utilizar

para modelar software y hardware si se determina que el dominio en estudio es un
sistema. El beneficio de ello en normas ISO de información geográfica es que el mismo
lenguaje de esquema conceptual (UML) se puede emplear para modelos de dominio
(modelado de información) y para modelos de sistemas (modelado de servicios).
55
NCh-ISO 19103
Anexo C
(Informativo)
Orientaciones de modelado
C.1 Orientaciones para el modelado con UML
La creación de modelos UML se debería realizar de preferencia como un proceso

estructurado. Hay muchos procesos alternativos propuestos para el modelado UML, tales
como el proceso unificado de desarrollo de software, catálisis, el proceso seleccionar
perspectiva, proceso unificado racional, componentes UML y otros. Ninguno de ellos
aborda directamente las inquietudes especiales relacionadas con la normalización de
modelos de información y servicios en una serie de normas tal como las normas ISO de
información geográfica, sino que se centran en el desarrollo general de sistemas y
componentes. Una de las diferencias es la necesidad de modelos que cumplen con las
normas ISO de información geográfica para especificar modelos de implementación
neutral (independientes de la plataforma) que se pueden perfilar al crear delimitaciones
para distintos modelos específicos de implementación (específicos de plataforma) con
distintos entornos de implementación.
El Grupo de Gestión de Objetos (Objeto Management Group, OMG) adoptó en enero

de 1999 la especificación XMI para el intercambio de modelos UML usando XML. En el
futuro, la especificación XMI debe permitir la interoperabilidad entre herramientas de UML.
Se espera que OMG normalice un nuevo formato de intercambio de diagramas basado en
XMI, que también incluya un diseño gráfico. En el futuro, los modelos UML de normas ISO
de información geográfica también deberían estar disponibles con el uso de la
especificación XMI y el nuevo formato de intercambio de diagrama. Entretanto, los
modelos deberían estar disponibles de manera electrónica usando herramientas de
modelado. Muchas herramientas de modelado de UML pueden leer formatos de otras
herramientas.
Las normas ISO de información geográfica se concentran en modelos UML abstractos y

de implementación neutral que puedan servir como especificaciones para
implementaciones usando diversas representaciones de implementación.
Una estructura general de productos y modelos de trabajo para un proceso de desarrollo

de software usando UML se puede describir como se determina a continuación (adaptado
del proceso unificado de desarrollo de software):
- Modelos de Negocio/Dominio
Modelo de dominio, Modelo de Negocio, Negocios que usan casos (reversa/en el

estado en que se encuentra, avance/en el estado que se desea).
56
NCh-ISO 19103
- Modelos de requisitos
Modelo de caso de usos, Actores, Visión de arquitectura, Glosario, Prototipo de

Interfaz de Usuario.
- Modelos de análisis/arquitectura
Modelo de arquitectura-identificación, objetos de servicios/control, objetos de

información/feature y objetos de límites/interfaz, paquetes/clases de análisis,
ejecución de casos de usos.
- Modelos de diseño (se pueden implementar de forma neutral)
Modelo de Diseño, Sistema de Diseño, Subsistema de Diseño, Interfaces, Ejecución-

diseño de Casos de Usos, Clases de Diseño, Visión de arquitectura, Modelo de
Despliegue.
- Modelos de implementación
Modelo de implementación, Componentes, subsistemas de implementación,

Interfaces, plan de construcción de la integración, Visión de arquitectura.
- Modelos de prueba
Modelo de prueba, Casos de prueba, Plan/procedimiento de prueba, Componente de

prueba, evaluación de prueba.
La meta de las normas ISO de información geográfica es crear modelos independientes de

plataformas (de implementación neutral). Esto debe entregar una referencia para crear
modelos específicos (de implementación) para varios entornos como SQL, COM/OLE,
CORBA, EXPRESS/SDAI y otros. No es necesario normalizar el proceso para determinar la
forma de crear estos modelos, sólo para especificar los requisitos a fin de establecer la
forma de documentar los modelos definitivos usando UML y éste es el propósito de esta
norma.
Las orientaciones siguientes presuponen que el dominio del problema ya se comprende

bien, esto es, a través el uso informal del modelado de clases, para describir los
conceptos esenciales en el dominio. Se supone que hay un conocimiento general del uso
de los modelos, esto es, a través de un caso de uso basado en especificación y análisis de
requisitos, y que se ha efectuado un análisis para identificar posibles tipos de
servicios/objetos y tipos de entidades/objetos.
Las orientaciones siguientes se concentran en el proceso para crear modelos neutrales de

implementación (especificaciones abstractas) que posteriormente se pueden transformar
en modelos de implementación y diseño detallado para varias plataformas y entornos.
57
NCh-ISO 19103
Las reglas de buen comportamiento general siguientes no se concentran en los

documentos sino en el proceso. Están enumerados acá como una orientación general para
aquellos dedicados al modelado de información y/o servicios.
- Términos especializados definidos que se usan. Definir todo lo que no sea lenguaje
tradicional de software. Evitar la jerga, que requiere que uno la reconozca.
- No utilizar suposiciones ocultas. Uno de los propósitos del modelado es la exposición

a suposiciones. Documentar las decisiones, presunciones y razones detrás del modelo.
- Responder las preguntas de las personas sobre el modelo y documentar las repuestas
en el documento de referencia. Las respuestas se deberían analizar en reuniones
públicas del comité técnico para poder llegar a consenso sobre temas controversiales.
- Documentar el modelo en una herramienta de UML, prestando especial atención a

rellenar todos los campos de documentación donde sea posible. Si se hace
adecuadamente, el contenido del modelo de herramienta es lógicamente equivalente al
documento. Facilitar el archivo del modelo de herramientas con su documento para
que todos los lectores puedan importar sus clases sin una interpretación errónea.
- Usar nombres técnicos precisos para atributos y operaciones a fin de evitar confusión.
Utilizar campos de documentación de forma extensiva. No reiterar los nombres de
clases dentro de los nombres de atributos. Mantener los nombres lo más concisos y
precisos. Mantener consistente el estilo de denominación.
- No incluir interfaces redundantes. Por ejemplo, no incluir atributos de clase que

registran asociaciones de clases que se muestran en el diagrama de clase; no incluir
operaciones de clases para modificar asociaciones de clases que se muestran en el
diagrama de clase.
- Todas las asociaciones generales deberían tener nombres de roles, excluyendo las
asociaciones de composición (diamante en negrita), agregación (diamante en blanco) y
generalización (triángulo o herencia). Los nombres asignados de asociaciones no
necesitan mostrarse en diagramas de clases cuando al menos un nombre de rol se
muestra en esa asociación.
La interoperabilidad requiere consistencia. Si los módulos de software son para conectar y

usar inmediatamente, requieren ser compatibles en cuanto a la conexión, lo que significa
que tienen que hacer lo mismo de la misma forma. Incluso si se proveen servicios
idénticos por componentes lógicamente separados, esos servicios deberían ser
consistentes.
Se deberían definir todas las clases a las que se hacen referencias en un modelo, dado
que todas las expresiones de tipo se deben usar como tipos de atributos, tipos de
resultados de operación y tipos de argumentos de entrada de operación.
58
NCh-ISO 19103
Los paquetes no deberían reinventar interfaces semánticamente equivalentes si existen

interfaces similares en otros paquetes. En vez de ello, se deberían importar de estos otros
paquetes. Los diagramas deberían incluir etiquetas de visibilidad, incluidas etiquetas de
paquetes (necesarias para mantener y documentar las relaciones apropiadas de
dependencia entre paquetes). Las clases importadas no deberían ser modificadas. Más
bien, se debería presentar una solicitud apropiada para cambios al documento fuente
(servidor).
Cuando se reutilizan firmas de operación de otras interfaces para operaciones

semánticamente similares o trazables en un mapa se debería mantener el orden de los
parámetros. De esta forma, las clases de objeto que logran las interfaces en cuestión
pueden emplear el mismo método y firma de implementación.
Los atributos y operaciones sobre clases e interfaces importadas no se deberían enumera

en un documento del cliente.
La práctica de mantener una documentación completa de la misma interfaz en dos lugares

hace que el documento del cliente dependa de los cambios hechos a esas interfaces en el
documento de servidor. Dado que una interfaz representa un servicio abstracto, la
mayoría de cambios menores en protocolos de Interfaz de Programación de Aplicaciones
(API) no debería afectar el diseño del paquete del cliente. Para clases importadas, las
etiquetas de visibilidad incluyen una etiqueta de <package-name> en la caja del nombre
de la clase. La mayoría de las herramientas de CASOS deben hacer esto automáticamente
y algunas llegarán a ensombrecer o colorear la clase importada. Se presume que las clases
no marcadas en un diagrama se encuentran en el paquete a la que pertenecen las
principales clases.
A continuación, se hace una separación entre el modelado de información y el modelado

de servicios. El modelado de información por lo general aborda el modelado relacionado
con información persistente que administra un sistema de información geográfica y suele
ser el enfoque que se debe usar más para modelar la información geográfica. El modelado
de servicios aborda el modelado de interfaces de componentes de sistemas y suele ser el
enfoque que se debe usar más para modelar los servicios geográficos.
Dado que el énfasis para los modelos de información y los modelos de servicios es
levemente distinto, se ha escogido para separar el enfoque del modelado en una
especialización para cada uno de ellos.
C.2 Orientaciones para el modelado de información
Este es un enfoque que se debe considerar para la mayor parte del modelado que se hace
en las normas ISO de información geográfica y para el modelado que cumple con las
normas ISO de información geográfica. Describe las fases para utilizar UML. Los principios
más importantes presentados acá son adaptaciones (ver Anexo E, Bibliografía, [5]) de,
Information Modeling: The EXPRESS way (Modelado de Información: la Vía EXPRESS).
Estos son principios generales para el modelado de información y también se aplica a
otros lenguajes de modelado conceptual además de UML.
59
NCh-ISO 19103
Fases de modelado
El foco se concentra en describir modelos de información. En el modelado orientado a

objetos, a menudo se separan objetos/clases en varias categorías, como clases de
interfaces/límites que son responsables de las interfaces de sistemas, clases de servicios y
controles que son responsables de servicios computacionales, y clases de features que
representan partes persistentes de un modelo de un sistema. Sobre información de
modelado, hay una mayor preocupación por las clases de entidades y, por lo tanto, nos
referimos a entidades.
Se recomiendan las etapas de modelado siguientes:
- Fase 0: Identificar alcance y contexto.
- Fase 1: Identificar clases básicas.
- Fase 2: Especificar relaciones, atributos y operaciones.
- Fase 3: Completar restricciones usando textos/OCL.
- Fase 4: Armonización de definiciones de modelos - con submodelos y otros ítemes de

trabajo.
Las primeras tres fases son de vital importancia a la hora de crear los esquemas que
cumplen con las normas ISO de información geográfica. La fase 4 también es importante
respecto de la integración de distintos esquemas en un solo modelo consistente.
Fase 0: Identificar alcance y contexto
Tareas:
1) Identificar las metas y alcance de los modelos.
2) Identificar modelos relacionados y un contexto más amplio.
Preguntas importantes que se deben responder: ¿Cuál es la meta y alcance del modelo?
Resultado entregable: Especificación por escrito de metas, alcance y contexto de

modelos.
Fase 1a: Identificar clases básicas
Tareas:
1) Identificar conceptos/términos genéricos y específicos.
2) Describir cada clase para que puedan realmente diferir de otras.
60
NCh-ISO 19103
3) Tener cuidado con sinónimos y homónimos.
4) Elaborar un glosario de conceptos/términos.
Se deben responder importantes preguntas:
- ¿Cuáles son las clases de acuerdo con el alcance?
- ¿Qué sabemos respecto de los atributos de las clases?
- ¿Podemos clasificar las clases?
- ¿Qué restricciones de consistencia local se aplican a las clases?
- ¿Están documentados todos los atributos y las clases?
- ¿Es correcto el uso de tipos básicos de datos?
Inquietudes menores:
- ¿Qué combinaciones de valores de atributos, si existen, identifican únicamente una

instancia de clase?
- ¿La existencia de una instancia de una clase depende del uso de otra clase?
- ¿Los valores de algunos atributos derivan de otros valores de atributos?
Resultado entregable: Un diagrama gráfico de clases de UML con un glosario escrito de

términos. Los términos deberían ser considerados para aportes al glosario de normas ISO
de información geográfica.
Fase 1b: Consistencia con las reglas para el esquema de aplicación
¿El alcance de modelado es consistente con el alcance descrito en ISO 19109?
Tareas:
Verificar que el enfoque de modelado, la granularidad de clases, etc., es consistente con

el alcance descrito en ISO 19109.
Fase 2: Especificar relaciones, atributos y posiblemente operaciones
Importantes preguntas que se deben responder:
- ¿Cuáles son las relaciones entre las clases?
- ¿Podemos clasificar las clases?
61
NCh-ISO 19103
- ¿Es correcto el uso de tipos básicos de datos?
- ¿Se requieren atributos adicionales para caracterizar una clase?
- ¿Los valores de algunos atributos derivan de otros valores de atributos?
- ¿La existencia de una instancia de clase depende del uso de otra clase?
- ¿Qué combinaciones de valores de atributos, si existen, identifican únicamente una

instancia de clase?
- ¿Están documentadas todas las clases, las relaciones y los atributos?
- ¿Hay necesidad de que las operaciones se asocien a las clases? De ser así, ¿cuáles
son los comportamientos previstos, argumentos de entrada y salida y posibles
excepciones?
Preguntas menores:
Respecto de un modelo complejo, ¿está subdividido en áreas temáticas?
Resultado entregable: Modelo de clase UML
Fase 3: Completar las restricciones
Importantes preguntas que se deben responder:
- ¿Cuáles son las reglas globales de consistencia?
- ¿Están consideradas todas las dependencias de existencia?
- ¿Están consideradas todas las otras restricciones de cardinalidad?
- ¿Están consideradas todas las restricciones?
- ¿El modelo ha sido bien dividido?
Resultado entregable: Documentación en inglés y basado en OCL de todas las

restricciones.
62
NCh-ISO 19103
Fase 4: Armonización de definiciones de modelos
Efectuar la armonización con submodelos y otras partes.
Cuando se desarrolla un modelo de información importante como en las normas ISO de

información geográfica, la labor se desglosa en ítemes de trabajo separados para que la
serie de normas se pueda desarrollar en paralelo. Por lo tanto, existe una serie de grupos
de modelado que desarrolla secciones individuales de las normas ISO de información
geográfica, por ejemplo, esquema de calidad, esquema de metadatos, esquema espacial,
etc. Esta distribución de labores facilita el ritmo de avance, pero a un costo. Como
resultado final, puede que los distintos modelos no encajen en un modelo integrado de
información si no se toman pasos adicionales para armonizar los modelos.
Importantes preguntas al momento de hacer comparaciones con otros esquemas:
- ¿Hay redundancias o conflictos?
- ¿Existe alguna ambigüedad?
- ¿Los modelos están completos?
- ¿Concuerdan los niveles de abstracción?
La lista de verificación siguiente se ha definido para elaborar Modelos de Datos/Información:
- ¿El alcance y contexto del modelo se han definido de acuerdo con las orientaciones?
- ¿Las clases básicas del modelo se han definido de acuerdo con las orientaciones?
- ¿Es el enfoque del modelado consistente con las reglas del esquema de aplicación?
- ¿Se ha usado UML según el Perfil UML de las normas ISO de información geográfica?
- ¿El alcance y contexto del modelo se han definido de acuerdo con las orientaciones?
- ¿Se han definido las restricciones según las orientaciones?
- ¿Se han armonizado los modelos con otros de acuerdo con las orientaciones?
C.3 Orientaciones para el modelado de servicios
Este es el enfoque que se debe tomar en cuenta para el modelado de servicios

geográficos, considerado como componentes de software geográficos computacionales
en una arquitectura distribuida. Una arquitectura de referencia para servicios geográficos
se describe en ISO 19101 e ISO 19119. El lector también es referenciado a un proceso
simple para especificar componentes en el libro Componentes UML (ver Anexo E,
Bibliografía, [6]). Este proceso describe la forma de especificar componentes y servicios
usando UML.
63
NCh-ISO 19103
El foco en esta sección apunta a describir modelos de servicios. En el modelado orientado

a objetos, a menudo se separan objetos y clases en varias categorías, como clases de
interfaces/límites que son responsables de las interfaces de sistemas, clases de servicios/
controles que son responsables de servicios computacionales, y clases de entidades que
representan partes persistentes de un modelo de un sistema. Sobre modelado de servicio,
hay una mayor preocupación por las clases de servicios y, por lo tanto, nos referimos al
servicio en las fases de modelado siguientes. Sin embargo, la mayoría de los servicios se
hace cargo y manipula los objetos de información/entidad y es necesario relacionar las
definiciones hechas a partir del modelado de información previa o paralela.
Se recomiendan las fases de modelado siguientes:
Fase 0: Identificar alcance y contexto - casos de uso.
Fase 1: Identificar responsabilidades de servicios básicos.
Fase 2: Especificar operaciones, atributos y relaciones de servicios.
Fase 3: Completar las restricciones sobre operaciones.
Fase 4: Armonización de definiciones de servicios.
Fase 0: Identificar alcance y contexto - casos de uso
Tareas:
1) Identificar las metas del servicio.
2) Identificar servicios relacionados y un contexto más amplio.
Se deben responder importantes preguntas:
- ¿Cuáles son los servicios/metas de acuerdo con el alcance?
- ¿Cómo se agrupan y asocian servicios con elementos de los modelos de información?
Resultado entregable: Especificación escrita de las metas, el alcance y el contexto del

servicio, ya que se relacionan con el alcance del ítem de trabajo. Puede que cuente con el
apoyo de escenarios de casos de usos que describen el uso potencial del servicio.
Fase 1: Identificar responsabilidades de servicios básicos
Tareas:
1) Identificar las responsabilidades básicas de un servicio.
2) Describir las secuencias de la interacción básica entre un cliente y el servicio.
64
NCh-ISO 19103
3) Dividir el servicio en subservicios e interfaces lógicas.
4) Especificar los diagramas de colaboración y secuencias.
Resultado entregable: Un modelo de objeto (UML) que muestra las interacciones básicas
entre el servicio (posiblemente descrito como un conjunto de interfaces) y sus potenciales
clientes. Las interacciones básicas pueden ser complementadas con diagramas UML de
colaboración/secuencia.
Fase 2: Especificar operaciones, atributos y relaciones de servicios
Por cada interfaz identificada, hay que:
- Especificar operaciones con argumentos y excepciones de entrada y salida.
- Relacionar los argumentos a los modelos específicos de datos/información.
- Especificar los atributos abstractos (como pares de operaciones de fijación/obtención -

sólo se obtienen para lectura).
- Especificar aquellos eventos que el servicio puede generar.
- Para servicios complejos, entregar un diagrama de estado para un comportamiento

dinámico permitido.
- Considerar si se deben definir nuevos objetos de datos/información.
Preguntas menores:
- Para un servicio complejo, ¿se puede subdividir en áreas de subservicios/interfaces?
Resultado entregable: Modelo gráfico de clases UML con firmas de operación.
Fase 3: Completar las restricciones sobre operaciones
Importantes preguntas que se deben responder en cada operación:
- ¿Qué significa esta operación (explicar la semántica)?
- ¿Qué significa cada parámetro?
- ¿Hay alguna restricción o precondición sobre los parámetros?
- ¿Qué significa la excepción para cada usuario?
- ¿Se usan excepciones normalizadas? ¿Qué significa cada una?
65
NCh-ISO 19103
- ¿Hay otras restricciones o condiciones previas/posteriores?
- ¿Alguna restricción de secuencia en el uso de esta operación con otras operaciones?
Resultado entregable: Documentación en inglés y basada en OCL con todas las

restricciones operacionales.
Fase 4: Armonización de definiciones de servicios
Preguntas principales:
- ¿Cómo se relaciona el servicio e interactúa con otros servicios?
- ¿Existe alguna ambigüedad?
- ¿Los modelos están completos?
- ¿Concuerdan los niveles de abstracción?
Resultado entregable: Modelos revisados de UML con documentación actualizada.
Los ítemes siguientes son una lista de verificación para Modelos de Servicios/Procesos:
- ¿El alcance y contexto del servicio se han definido de acuerdo con las orientaciones?
- ¿Se han definido las responsabilidades de servicios básicos según las orientaciones?
- ¿Se ha usado UML de acuerdo con el Perfil de UML?
- ¿Las operaciones, atributos y relaciones de servicios se han definido de acuerdo con

las orientaciones?
- ¿Se han definido las restricciones sobre las operaciones según las orientaciones?
- ¿Se ha armonizado la especificación de servicios con otros servicios de acuerdo con

las orientaciones?
C.4 Armonización de modelos
El principal punto de referencia para la armonización de modelos es asegurar que los

diversos modelos sean consistentes con cada uno y se puedan usar juntos en un esquema
de aplicación y en una configuración real de aplicación.
66
NCh-ISO 19103
Las orientaciones siguientes se deberían seguir en el contexto de armonización de

modelos.
1) Detalles - Obtener una producción con estilo consistente. No cambiar el contenido ni

estructura del modelo.
2) Editorial - Aplicar el principio de un nombre y una idea.
3) Continuidad - Identificar las redundancias y brechas entre dos esquemas, eliminar

declaraciones y sumar aquellas perdidas.
4) Estructural - Identificar conceptos generales subyacentes que se deberían usar en

otras secciones del modelo y reescribir el modelo.
5) Con base central - Definir un modelo de información central que se pueda dividir en
modelos distintos y desarrollarse en paralelo. El modelo central debería identificar el
contexto y el alcance de distintos submodelos. Esta es una estrategia descendente.
6) Con base evolutiva - Comenzar con un modelo existente y ampliar este modelo con
una base central. Este se denomina estrategia que parte del centro.
7) Calidad de modelo - El modelo integrado no debería cambiar la semántica asociada

con los distintos esquemas.
Lista de verificación
Los aspectos siguientes se deberían evaluar en cada proyecto para secciones que incluyen
modelos de UML:
1) Legibilidad - ¿El esquema (modelo de información) está diseñado para un lector

humano?
2) Alcance - ¿Los alcances y las presunciones definidas de los distintos esquemas

concuerdan con el alcance de la norma?
3) El principio de sinónimos y homónimos - ¿Se sigue el principio de un nombre, un

significado, una definición? Hay que estar consciente de los sinónimos y homónimos.
4) Independencia de contexto - ¿Las clases se definen lo más independiente posible del

contexto? Si la clase se puede aplicar en más de un contexto, no se deberían definir
restricciones que dependen de un contexto.
5) Independencia de implementación -¿Los modelos se concentran en describir el qué y

no el cómo, por ejemplo, no concentrarse en la eficiencia del intercambio o
implementación de archivos?
6) Invariancia - El significado de una clase no debería depender de los valores de sus

atributos.
67
NCh-ISO 19103
7) Restricciones - ¿Están restringidos adecuadamente los dominios de valores de los

atributos y las relaciones? Esto se puede realizar mediante expresiones de OCL y
cardinalidades de relaciones.
8) Realidad - ¿Las clases declaradas corresponden a la realidad?
9) Redundancia - ¿Hay redundancias que pueden llevar a posibles ambigüedades en las

instancias de modelo?
10) Conceptos - ¿Están expresados los conceptos subyacentes? Se debería evitar la

apariencia superficial, las descripciones de sintaxis y el uso de atributos opcionales.
11) Jerarquías - ¿Se usan las jerarquías de herencia para agregación de datos o viceversa?
12) Tipos de datos básicos - ¿Los tipos de atributos están correctamente especificados?
Se deberían evitar tipos simples como número entero, real, cadena, etc., que no
posean semántica.
Resultado entregable: Modelos UML revisados.
68
NCh-ISO 19103
Anexo D
(Informativo)
Introducción a UML
D.1 Introducción
Este anexo se proporciona como una introducción conveniente para las partes básicas de
UML que se usan y describen en las normas ISO de información geográfica. El documento
normativo para el uso de UML corresponde a ISO/IEC 19501.
Este anexo está estructurado de la forma siguiente:
- uso general de UML;
- clases;
- atributos;
- tipos de datos;
- operaciones;
- relaciones y asociaciones;
- estereotipos y valores etiquetados;
- atributos y asociaciones opcionales, condicionales y obligatorios;
- denominación y espacios de nombres;
- paquetes;
- notas; y
- restricciones;
D.2 Uso general de UML
UML se debería usar de forma que sea consistente con ISO/IEC 19501. Los libros como
UML User Guide (ver Anexo E, Bibliografía, [1]) y UML Reference Manual (ver Anexo E,
Bibliografía, [2]) contienen más información al respecto. El libro UML Distilled (ver Anexo E,
Bibliografía, [4]) es un texto introductorio más breve.
69
NCh-ISO 19103
D.3 Clases
Una clase es una descripción de un conjunto de objetos que comparten los mismos
atributos, operaciones, métodos, relaciones y semántica. Una clase representa un
concepto que se modela. Dependiendo del tipo de modelo, el concepto se puede basar en
el mundo real (para un modelo conceptual) o en la implementación de conceptos de
sistemas independientes de plataformas (para modelos de especificación) o conceptos de
sistemas específicos de plataforma (para modelos de implementación).
Un clasificador es una generalización de una clase que incluye elementos de otras clases,
como tipos de datos, actores y componentes. Una clase de UML tiene un nombre, un
conjunto de atributos, un conjunto de operaciones y restricciones. Una clase puede formar
parte de asociaciones.
UML define dos tipos especiales de clases a través de los estereotipos <<Interface>> y
<<Type>>.
Una <<Interface>>, ver Figura D.1, es un conjunto designado de operaciones que

caracteriza el comportamiento de un elemento. Una <<Interface>> también se puede
mostrar como un ícono de paleta de dulce. Una <<Interface>> en UML no contiene
atributos y no especifica su implementación.
<<Interface>> Icono de paleta de

dulce de interfaz
Public operations
Figura D.1 - La <<interface>> de estereotipo
Un <<Type>>, ver Figura D.2, es una clase estereotipada usada para una
especificación de un dominio de instancias (objetos), junto con las operaciones aplicables
a los objetos. Un tipo puede tener atributos y asociaciones abstractas. Decir que los
atributos son abstractos significa que su especificación no implica que se deban
implementar específicamente como variables de instancias.
<<Type>>
.. abstract attributes
..operations
Figura D.2 - El estereotipo <<type>>
Una <<Interface>> no puede tener atributos; sin embargo, la noción de atributos

abstractos en un <<Type>> se puede usar como el lugar para describir el estado
abstracto necesario. Por ejemplo, un punto puede tener un estado abstracto para la
coordenada x e y, pero una representación real basada en radian y grado que se usa para
70
NCh-ISO 19103
calcular x e y. Para objetos que se pueden aprobar por valor tal como en la transferencia de
features, es necesario que se entregue suficiente información sobre el estado abstracto. Esto
significa que no se puede usar una interfaz única basada en especificaciones. El estereotipo
<<Type>> se puede usar para la especificación de interfaces y el estado abstracto.
Las interfaces y los tipos se pueden usar de acuerdo con los estereotipos normalizados de
UML, lo que se traduce en un conjunto de operaciones, y un conjunto de operaciones y
atributos abstractos, respectivamente.
Una clase abstracta define una clase de objeto polimórfico y no puede ser instanciada.
Una clase abstracta difiere de una <<Interface>> en que puede tener atributos y puede
implementar algunas de sus operaciones. Una <<Interface>> equivale a una clase
abstracta sin atributos ni implementación de operaciones. Una clase Abstracta se
especifica al tener el nombredeclase en cursiva o por un valor etiquetado {Abstract}
colocado al lado del nombredeclase.
La visibilidad de un atributo, operación o extremo de asociación definido en el contexto de

una clase puede estar limitada de varias formas. La visibilidad privada significa que un
atributo u operación sólo es visible dentro de la clase en que se define, mientras que una
asociación sólo es navegable a partir de su clase en su extremo fuente. La visibilidad
protegida (‘#’) significa que un atributo u operación sólo es visible dentro de la clase en
que se define y a su subclase, mientras que una asociación sólo es navegable a partir de
la clase en su extremo fuente y a partir de sus subclases. La visibilidad pública (‘+’)
significa que un atributo u operación es visible externamente para cualquier clase dentro
del mismo paquete como la clase en la que se define, mientras que una asociación es
navegable a partir de cualquier clase asociada con la clase en la que se define. Las
visibilidades privadas y protegidas no se suelen usar en las normas ISO de información
geográfica. La Figura D.3 muestra los símbolos para definiciones de elementos derivados,
visibilidad y niveles de clases.
NombredeClase
/ /* elemento derivado
+ /* visibilidad pública
# /* visibilidad protegida
- /* visibilidad privada
⎯ /* nivel de clase (subrayado)
Figura D.3 - Símbolos para definiciones de elementos derivados, visibilidad y niveles de clases
71
NCh-ISO 19103
La visibilidad de atributos, operaciones y extremos de asociaciones se muestra mediante

un símbolo que precede el nombre del elemento (nombre de rol en el caso de un extremo
de asociación), como sigue:
- privado
# protegido
+ público
Algunas herramientas de UML usan varios íconos gráficos para los símbolos de visibilidad,
pero algunos símbolos de la norma UML se usan en las normas ISO de información
geográfica.
Es posible definir un atributo o una operación que esté a nivel de clase (a diferencia de
estar en el nivel de instancia) al subrayar la definición de atributo u operación.
Un signo barra diagonal ‘/’ que antecede el nombre de un elemento de modelo tal como
un atributo, significa que es derivado (calculado) de otro elemento.
D.4 Atributos
La notación de UML para un atributo tiene la forma:
[<<estereotype>>] [visibility] nombre [multiplicity] [:type] [=initial value]

[{property-string}]
donde elementos opcionales se cierran en paréntesis, y:
El estereotype es el nombre del estereotipo (ver Anexo D, cláusula D.8) al que

pertenece el atributo, si hay alguno.
La visibility especifica la visibilidad (ver Anexo D, cláusula D.3) del atributo.
El name es una cadena de caracteres que identifica el nombre del atributo.
La multiplicity especifica el número de valores (ver Anexo D, D.7.2) que una

instancia de clase puede tener para un atributo determinado.
type-expression identifica el tipo de datos del atributo.
initial value especifica el valor predeterminado para el atributo.
property-string contiene valores etiquetados aplicados al atributo.
EJEMPLOS
+ centro : Punto = (0,0) {frozen}
+ origen [0..1] : Punto / * multiplicidad 0..1 significa que esto es opcional.
72
NCh-ISO 19103
Las propiedades pueden ser definidas por el usuario. Algunas propiedades predefinidas
son: permutable, addOnly, frozen (const).
Un atributo debería ser único dentro del contexto de una clase y sus supertipos, a menos
que sea un atributo redefinido a partir de un supertipo. Si un atributo se reemplaza, se
debería tratar como un atributo abstracto que se puede calcular en la demanda de acuerdo
con las reglas definidas para su derivación.
Un tipo de datos siempre debe estar especificado, no hay tipo predeterminado.
Si no existe una multiplicidad explícita, se asume que la multiplicidad equivale a 1.
Un atributo puede definir un valor predeterminado, que se usa cuando se crea un objeto
del tipo de datos. Los valores predeterminados se definen por valores predeterminados
explícitos en la definición de UML del atributo. Los valores predeterminados son
necesarios en algunas situaciones en modelos conceptuales que cumplen con las normas
ISO de información geográfica. Como ejemplo, ISO 19115, la clase MD_Identification
predetermina el conjunto de caracteres a ISO/IEC 10646.
D.5 Tipos de datos
La cláusula 6 define el conjunto de tipos de datos que se emplearán.
D.6 Operaciones
Las operaciones están presentes en diagramas de clases UML de acuerdo con la Guía de
Notación UML.
Una operación se especifica mediante una cadena de texto que se puede analizar
gramaticalmente en elementos que describen las propiedades de la operación:
visibility name (parameter-list) : return-type-expression[{property-string}]
donde elementos opcionales se cierran en paréntesis, y:
La visibility especifica la visibilidad (ver Anexo D, cláusula D.3) de la operación.
El name es una cadena de caracteres que identifica el nombre de la operación.
parameter-list es una lista de parámetros (ver a continuación).
Return-type-expression especifica el tipo de datos o los tipos del valor de retorno

mediante la operación.
property-string contiene valores etiquetados aplicados a la operación.
Un elemento de la property-list tiene la forma de:
[kind] name: type-expression[= default-value]
73
NCh-ISO 19103
donde:
Kind es adentro, afuera o adentro y afuera, y el tipo predeterminado es adentro en

caso de ausencia.
name es el nombre del parámetro.
Type-expression identifica el tipo de datos del parámetro.
Default-value es un valor inicial para el parámetro.
Los valores para el kind tienen los significados siguientes:
in - La operación lee el valor de parámetro, pero no lo modifica.
out - La operación crea el valor del parámetro y se puede leer al momento del
retorno de la operación al punto de llamada.
inout - La operación lee y modifica el parámetro y se puede leer al momento del

retorno de la operación al punto de llamada. Las excepciones se pueden definir como
elementos de clase usando el estereotipo <<Exception>>. Las excepciones se
pueden ligar a las operaciones a través de una relación de dependencia.
UML ha definido cuatro propiedades normalizadas para las operaciones: esConsulta

(isQuery), secuencial, con guardas, concurrente.
Se deberían usar notas con los estereotipos <<precondition>> y <<postcondition>>

para describir condiciones previas y posteriores para las operaciones y también se
deberían usar notas con el estereotipo <<invariant> para describir invariantes de clase.
Hay varias categorías de objetos en una operación:
1) El objeto con que se asocia la operación, conocido como “this” o “self” en la mayoría
de los lenguajes [el objeto antes del punto “.” en una declaración como
object.operation()].
2) Los objetos se hacen pasar por parámetros que se usan para controlar el
comportamiento de la operación.
3) Los objetos modificados o devueltos por la operación.
“Una operación especifica una transformación sobre el estado del objeto al que se apunta
(y posiblemente el estado del resto del sistema accesible desde el objeto al que se
apunta), o una consulta que retorna un valor al solicitante de la operación”. (Ver Anexo E,
Bibliografía, [2]).
74
NCh-ISO 19103
En UML, los objetos se suelen modificar o pueden acceder por sus propios métodos. Sin
embargo, los objetos pueden “pasar por referencia”, por lo que cualquier objeto
persistente que se hace pasar por un parámetro puede recibir un mensaje en cascada. Por
lo tanto, el objeto puede ser modificado, si bien indirectamente, por cualquier método al
que se pasa. Por ende, los parámetros con valor-de-objeto comprenden inherentemente
“adentro y afuera” en dirección. Los parámetros que consideran tipos de datos como sus
valores son “adentro” o “afuera”.
El alcance (clase versus instancia) y el valor de la propiedad isQuery (Booleano) se

deberían documentar en el texto que describe la operación.
D.7 Relaciones y asociaciones
D.7.1 Relaciones
Una relación en UML es una conexión semántica concreta entre los elementos de un
modelo. Entre tipos de relaciones figuran asociación, generalización,
agregación/composición y varios tipos agrupados bajo dependencia. Ver Figura D.4.
En Anexo E, Bibliografía, [2], se hace una clara distinción entre el término general
“relación” y el más específico “asociación”. Ambos están definidos para vínculos de clase
a clase, pero la asociación se reserva para aquellas relaciones que en realidad son vínculos
de instancias a instancias. “Generalización”, “realización” y “dependencia” son relaciones
de clase a clase. “Agregación” y otras relaciones de objeto a objeto son denominadas de
forma más restrictivas “asociaciones”. Siempre es apropiado usar el término más
restrictivo en cualquier caso, por lo que respecto de las relaciones con instancias hay que
usar el término “asociación”.
75
NCh-ISO 19103
En las normas ISO de información geográfica, la generalización, dependencia,

metarrelación, flujo y refinamiento se usan de acuerdo con la notación y uso de la norma
UML. A continuación se describe con más detalle el uso de asociación, agregación y
composición.
D.7.2 Asociación, composición y agregación
Una asociación en UML es la relación semántica entre dos o más clasificadores (esto es,
clase, interfaz, tipo, etc.) que implica conexiones entre sus instancias.
Una asociación se emplea para describir una relación entre dos o más clases. Además de
una asociación común, UML define dos tipos especiales de asociaciones denominadas
agregación y composición. Los tres tipos tienen distintas semánticas. Se debería usar una
asociación común para representar una relación general entre dos clases. Las asociaciones
de agregación y composición se deberían usar para crear relaciones de todo-parte entre
dos clases.
Una asociación binaria tiene un nombre y dos extremos de asociaciones. Un extremo de

asociación tiene un nombre de rol, una declaración de multiplicidad, un símbolo de
agregación opcional. Un extremo de asociación siempre debería estar conectado a una
clase.
La Figura D.5 muestra una asociación denominada “A” con sus dos respectivos extremos
de asociación. El nombre de rol se usa para identificar el extremo de una asociación; el
nombre de rol r1 identifica el extremo de asociación que se conecta a la clase denominada
clase2. En este ejemplo, el nombre de rol r1 identifica la naturaleza que tiene la relación
clase2 con clase1 a través de la asociación A. La multiplicidad de un extremo de
asociación puede ser de exactamente-uno(1), cero-o-uno(0..1), uno-o-más (1..*), cero-o-
más (0..*) o un intervalo (n..m). Visto desde la clase, el nombre de rol del extremo
opuesto de asociación identifica el rol de la clase objetivo. Decimos que clase2 tiene una
asociación con clase1 que se identifica mediante el rol r2 y que tiene una multiplicidad de
exactamente uno. A la inversa, podemos decir que clase1 tiene una asociación con clase2
que se identifica mediante el nombre del rol r1 con multiplicidad de cero-o-más. En el
modelo de instancias, decimos que los objetos de clase1 tiene una referencia a objetos
clase2 de cero-o-más y que los objetos clase2 tienen una referencia al objeto clase1 de
exactamente-uno.
r2 A r1
Clase 1 Clase 2
1 0..*
extremo de asociación extremo de asociación
A asociación
r1, r2 nombres de roles
Figura D.5 - Asociación
76
NCh-ISO 19103
La Figura D.6 especifica la notación que se usa para especificar el número de instancias
que pueden participar en un extremo de una asociación. La misma notación se usa para
atributos, pero luego en el campo [multiplicidad], como se analiza en cláusula D.4.
Exactamente uno 1 Clase
Muchos, cero opcional o más 0..* Clase * Clase
Cero o uno 0..1

Clase
Al menos uno 1..*

Clase
Número dado 3, 5, 10
Clase
Figura D.6 - Especificación de multiplicidad/cardinalidad
Una asociación de agregación es una relación entre dos clases, en que una de las clases
juega el rol de contenedor y la otra, de contenido. La Figura D.7 muestra un ejemplo de
agregación. El símbolo de agregación abierto de forma de diamante en el extremo de
asociación cerca de clase1 indica que clase1 es una agregación consistente de clase3.
Esto significa que clase3 forma parte de clase1. En el modelo de instancias, los objetos
clase1 debe contener uno o más objetos clase3. La asociación de agregación se debería
usar cuando los objetos de contenido, que representan las partes de un objeto
contenedor, pueden existir sin ese tipo de objeto. La agregación es una forma simbólica
corta para la asociación de partes, pero no tiene una semántica explícita. Permite
múltiples agregaciones para compartir los mismos objetos. Si se requiere una semántica
de agregación más fuerte, se debería usar la composición como se describe a
continuación. También es posible definir el nombre del rol y la multiplicidad en el extremo
en forma de diamante.
B r3
Clase 1 Clase 1
1..*
B asociación
r3 nombre de rol
Figura D.7 - Agregación
Una asociación de composición es una agregación sólida. En una asociación de

composiciones, si se borra un objeto de contenedor, entonces todos sus objetos
contenidos también son borrados. La asociación de composición se debería usar cuando
los objetos que representan las partes de un objeto contenedor no pueden existir sin el
objeto contenedor. La Figura D.8 muestra una asociación de composiciones, en que el
símbolo de composición en forma de diamante está totalmente relleno. Acá los objetos
clase1 consisten en uno o más objetos clase4, los que no pueden existir a menos que
también exista el objeto clase1. La cardinalidad requerida (implícita) para la clase
propietario siempre es uno. Los contenedores, o partes, no se pueden compartir entre
múltiples propietarios.
77
NCh-ISO 19103
También es posible definir el nombre de rol en el extremo de forma de diamante y la

multiplicidad siempre debe ser al menos uno. La composición se debería usar con cuidado
para contar con el efecto semántico de contención. Se debería considerar la aplicación de
la estructura de composición dentro del contexto de un modelo (más que el alcance),
donde el contexto se refiere al dominio de aplicación en que la aplicación debe ser
consistente. Esto con el fin de impedir problemas en que distintas aplicaciones tienen
diferentes requisitos de composición.
C r4
Clase 1 Clase 4
1..*
C asociación
r4 nombre de rol
Figura D.8 - Composición (agregación sólida)
Cada asociación UML tiene atributos de navegabilidad que indican las clases en la
asociación que se pueden seguir para obtener información del otro extremo. La lógica
predeterminada para una asociación sin marcas es aquella con doble sentido. En el caso
de relaciones cliente-servidor, la asociación usada sólo es normalmente navegable de
cliente a servidor (un sentido), indicado en el diagrama por la punta de flecha sobre el
costado del servidor de la asociación. Las asociaciones que no indican navegabilidad son
de doble sentido cuando ambos participantes tienen igual acceso al rol opuesto. La
navegación en doble sentido no es común ni necesaria en muchas operaciones cliente-a-
servidor, por lo que se ha introducido una punta de flecha para que sea un indicio para
una implementación más optimizada. El contraejemplo puede ser los servicios de
notificación, donde a menudo el servidor estimula la comunicación sobre un evento
prescrito. Se debería minimizar el uso de relaciones de doble sentido que introducen
dependencias de paquetes no razonables. Se debería recurrir a relaciones en un sentido
cuando eso sea todo lo que se necesita.
La multiplicidad se refiere al número de relaciones de un tipo particular que puede

involucrar un objeto. Si la clase objetivo de una relación en un sentido es marcada con
una multiplicidad, esto indica para cualquier implementación el número de ubicaciones de
almacenamiento que puede necesitar la clase fuente de la relación. En la mayoría de los
lenguajes objetos, esto sería implementado como una matriz de referencia de objetos. La
multiplicidad indica las restricciones de longitud de esa matriz y el número de NULOS
permitidos. Si un extremo de una asociación no fuera navegable, lo que pone una
restricción de multiplicidad, se requeriría una implementación para seguir la pista al uso de
la asociación por parte de otros objetos (o para que pueda adquirir la multiplicidad a través
de una consulta). Si esto es importante para el modelo, la asociación debería ser
navegable en dos sentidos para hacer cumplir la restricción más justificable. En otras
palabras, una relación en un sentido implica cierta actitud de “descuido” respecto del
extremo no navegable.
78
NCh-ISO 19103
D.8 Estereotipos y valores etiquetados
D.8.1 Generalidades
UML contiene tres mecanismos de extensibilidad: estereotipos, valores etiquetados y

restricciones, ver cláusula D.12 para restricciones. Un estereotipo UML es un mecanismo
de extensión para conceptos existentes de UML. Es un elemento de modelo que se usa
para clasificar (o marcar) otros elementos de UML, por lo que de cierta medida se
comportan como si fueran instancias de nuevas clases de metamodelos virtuales o
pseudometamodelos, cuya forma se basa en clases de metamodelos existentes. Los
estereotipos aumentan los mecanismos de clasificación sobre la base de la jerarquía de
clases de metamodelos incorporados en UML. Por lo tanto, los nombres de nuevos
estereotipos no deben entrar en conflicto con elementos del metamodelo predefinidos u
otros estereotipos.
Los valores etiquetados son otro mecanismo de extensibilidad de UML. Un valor

etiquetado es un par etiqueta-valor que se puede usar para sumar propiedades a cualquier
elemento de modelo en UML, esto es, puede extender un elemento arbitrario existente en
el metamodelo UML o un estereotipo.
D.8.2 Valores etiquetados
Los valores etiquetados separador (=) de Nombre (etiqueta), son propiedades de valor (de
la etiqueta) en un elemento, pertinentes para la generación de códigos o la gestión de
configuraciones (se puede aplicar a todos los elementos de UML). La Figura D.9 muestra
el metamodelo UML para estereotipos y valores etiquetados.
+ tagged_values
ModelElement
0..*
TaggedValue
GeneralizableElement tag : Name
value : Uninterpreted
0..*
+ tagged_values
StereoType
icon : Geometry
baseClass : Name
Figura D.9 - Estereotipos UML y valores etiquetados
EJEMPLO
Un valor etiquetado adjunto a, por ejemplo un clasificador se puede definir: {autor = “Joe Smith”, plazo =
31-marzo-1997, estado = análisis}.
79
NCh-ISO 19103
D.8.3 Estereotipos
En esta norma, se usan los estereotipos siguientes:
a) <<Interface>> es una definición de un conjunto de operaciones que cuenta con el

apoyo de objetos que utilizan esta interfaz.
b) <<Type>> es una clase estereotipada usada para una especificación de un dominio

de instancias (objetos), junto con las operaciones aplicables a los objetos. Un tipo
puede tener atributos y asociaciones.
c) <<Control>> es para una clase cuyo propósito esencial es entregar un servicio y no

representa un dato particular en sí mismo - es una extensión de la norma UML del
proceso unificado de desarrollo de software.
d) <<Entity>> es una clase que representa objetos potencialmente persistentes que

tienen información. Una extensión de la norma UML del proceso unificado de
desarrollo de software.
e) <<Boundary>> es una clase que representa una interfaz externa para un sistema.
Una extensión de la norma UML del proceso unificado de desarrollo de software.
f) <<Enumeration>> es un tipo de dato cuyas instancias forman una lista de valores

designados literalmente. Se declaran tanto el nombre de la enumeración como sus
valores literales. La enumeración significa una breve lista de valores potenciales bien
conocidos dentro de una clase. Ejemplos clásicos son booleano con solo dos (o tres)
valores potenciales VERDADERO, FALSO (y NULO). La mayoría de las enumeraciones
se debe codificar como un conjunto secuencial de números enteros, a menos que se
especifique otra clase. La codificación real se suele usar para los compiladores de
lenguaje de programación.
g) <<Exception>> es una señal que emerge de una maquinaria de ejecución

subyacente en respuesta de fallas conductuales.
h) <<MetaClass>> es una clase cuyas instancias son clases. Las metaclases se

suelen usar en la construcción de metamodelos. El significado de la metaclase es una
clase de objeto cuyo principal propósito es mantener metadatos sobre otra clase. Por
ejemplo, “FeatureType” y “AttributeType” son metaclases para “Feature” y
“Attribute”.
i) <<DataType>> es un descriptor de un conjunto que carece de identidad (existencia

independiente y la posibilidad de efectos secundarios). Los tipos de datos incluyen
tipos predefinidos primitivos y tipos que define el usuario. Un DataType es por lo
tanto una clase con pocas operaciones o ninguna, cuyo principal propósito es
mantener el estado abstracto de otra clase para transmisión, almacenamiento,
codificación o almacenamiento persistente.
Los estereotipos señalados son normas UML, y se usan en información geográfica.
80
NCh-ISO 19103
D.9 Atributos y asociaciones opcionales, condicionales y obligatorios
La norma UML provee varias formas de describir atributos y asociaciones opcionales,

condicionales y obligatorios. Esta norma especifica con más detalle una forma de
realizarlo.
D.10 Denominación y espacios de nombres
UML no especifica ninguna regla estricta para la denominación y los espacios de nombres,
ya que eso se detalla en cláusula 6.
D.11 Paquetes
Un paquete UML es un contenedor que se usa para agrupar declaraciones de

subpaquetes, clases y sus asociaciones. La estructura de paquete UML permite una
estructura jerárquica de subpaquetes, declaraciones de clases y asociaciones.
Los paquetes, clases y atributos en un modelo se pueden identificar con un nombre calificado
o su nombre más interno si se otorga el contexto. La forma de los nombres calificados es
packagename1 :: package:name2 :: classname.elementname1.elementname2, en que
packagename1 es el nombre del paquete más externo, packagename2 es un nombre que
aparece dentro del namespace del packagename1, classname es el nombre de una clase que
aparece dentro del namespace de packagename2 y elementname1 es el nombre de un
elemento dentro del espacio del nombre de classname. El símbolo :: se usa para separar
nombres de paquetes y nombres de clase. El punto (.) se emplea para separara nombres de
clases de los nombres de los elementos dentro del espacio de nombre de una clase. No hay
límite de la profundidad de esta jerarquía de espaciodenombre.
EJEMPLO
En el Esquema espacial hay un subpaquete denominado Geometría que define la clase GM_Object. Esta clase
tiene una asociación con el nombre de rol SRS (Spatial Reference System). El nombre completamente
apropiado para esta asociación es: Spatial.Geometric : :GM_Object.SRS.
D.12 Notas
Las casillas de notas se usan para comentar sobre el modelo en general o un ítem
específico (esto es, clase o asociación) del modelo en particular, ver Figura D.10. También
se pueden usar para especificar restricciones y condiciones (ver 6.13).
Polígono Un área limitada por una

línea cerrada
Figura D.10 - Ejemplo de nota
81
NCh-ISO 19103
D.13 Restricciones
Una restricción se muestra como una cadena textual en paréntesis angulares ({}). Las
restricciones se pueden describir usando el Lenguaje de Restricciones de objetos(OCL)
(ver Anexo E, Bibliografía, [3]), que es un lenguaje de conjuntos basado en expresiones
lógicas de objetos y propiedades de objetos. Una restricción OCL es una expresión válida
de OCL del tipo booleano, esto es, una expresión con un valor de verdadero o falso.
Las restricciones también se pueden explicar usando texto, ver ejemplo en Tabla D.1 de
restricciones de tipos de Colección.
Tabla D.1 - Restricciones textuales sobre tipos de colección
Tipos de colección Declaración Descripción

Set Set (T) Colección que contiene instancias de un tipo
OCL válido. Cada elemento debería ser del
mismo tipo. Un Set no contiene elementos
duplicados y cualquier instancia sólo se puede
presentar una vez. El conjunto no tiene
ordenación de sus elementos.
Bag Bag (T) Un Bag es como un Set, pero puede contener
elementos duplicados. El multiconjunto no
tiene ordenación de sus elementos.
Sequence Sequence (T) Una Sequence es como un Bag, pero los
elementos están ordenados.
Tantos las expresiones OCL como las descripciones textuales se pueden colocar en
casillas de NOTAS UML, ver Figura D.11.
Customer
+name : string title = (if isMale= true then
+isMale : boolean ‘Mr.’ else ‘Ms.’ endif)
+title : string
Figura D.11 - Ejemplo de restricción OCL adjunta a elementos de modelo
Se puede usar OCL para describir restricciones de varias partes de un modelo, incluidas
restricciones sobre:
- clases;
- atributos y asociaciones de clases;
- operaciones de clases (condiciones previas y posteriores); y
- clases abstractas.
82
NCh-ISO 19103
Las Tablas D.2 a D.5 describen operaciones normalizadas sobre tipos de OCL.
Tabla D.2 - Operaciones booleanas de la norma OCL
Operación Notación Tipo de resultado

o aob Booleano
y ayb Booleano
exclusiva A o exclusivo B Booleano
negación no a Booleano
igual a=b Booleano
no igual a <> b Booleano
implica a implica b Booleano
si entonces sino (if then else) terminación si a entonces b sino b’ Tipo de b y b’
Tabla D.3 - Operaciones de números enteros/reales de la norma OCL
Operación Notación Tipo de resultado

igual a=b Booleano
no igual a <> b Booleano
menor a<b Booleano
mayor a>b Booleano
menor o igual a≤b Booleano
mayor o igual a≥b Booleano
más a+b Número entero o real
menos a-b Número entero o real
multiplicación a*b Número entero o real
división a/b Real
módulo a.mod(b) Número entero
división de número entero a.div(b) Número entero
valor absoluto a.abs Número entero o real
máximo de a y b a.máx.(b) Número entero o real
mínimo de a y b a.mín.(b) Número entero o real
ronda a.floor Número entero
EJEMPLO
(3.2).piso/3 = 1
1.175 * (-8.9).abs – 10
7.máx.(3) = 7
83
NCh-ISO 19103
Tabla D.4 - Operaciones de cadena OCL
Operación Expresión Tipo de resultado

concatenación string.concat(cadena) Cadena
tamaño string.size Número entero
para letra minúscula string.toLower Cadena
para letra mayúscula string.toUpper Cadena
subcadena string.substring(entero, entero) Cadena
igual string1 = string2 Booleano
no igual string1 <> string2 Booleano
EJEMPLO
‘ISO/TC211’.tamaño = 9
(‘ISO’ = ‘ISO’)= verdadero
‘ISO/’.concat (‘TC211’) = ‘ISO/TC211’.
Tabla D.5 - Operaciones de colección OCL
Operación Descripción
tamaño El número de elementos en la colección.
recuento(objeto) El número de ocurrencias de objetos en la colección.
incluye(objeto) Verdadero si el objeto es un elemento de la colección.
incluyeTodo(colección) Verdadero si todos los elementos del parámetro están
presentes en la actual colección.
estáVacío Verdadero si la colección no contiene elementos.
noVacío Verdadero si la colección contiene uno o más elementos.
iterar(expresión) La expresión es evaluada por cada elemento de la
colección. El tipo de resultado depende de la expresión.
suma() La adición de todos los elementos en la colección. Los
elementos deben ser de un tipo que respalda la adición
(como Número Real, Entero).
existe(expresión) Verdadero si la expresión es verdadera en al menos un
elemento de la colección.
paraTodos(expresión) Verdadero si toda la expresión de elementos es verdadera.
Los atributos de un modelo UML que define un usuario se pueden usar libremente en una
expresión OCL. Las operaciones definidas por el usuario se pueden usar sólo si no tienen
efectos secundarios, esto es, si no alteran el estado del objeto.
OCL también ofrece operaciones sobre objetos (‘=’ (igual objeto) ‘<>’ (diferentes objetos)
‘oclType’ (tipo de objeto), ‘oclIsTypeOf’ (verdadero si es tipo directo), ‘oclIsKindOf’
(verdaderos si es tipo o subtipo de), ‘oclAsType’ (tipo de retorno)) y sobre tipos (‘’nombre’,
‘atributos’, ‘associationEnds’, ‘operaciones’, ‘supertipos, ‘allSuperTypes’, ‘allInstances’).
84
NCh-ISO 19103
Anexo E
(Informativo)
Bibliografía
[1] BOOCH, G., JACOBSSON, I. and RUMBAUGH, J. UML User Guide, 1999, Addison-
Wesley ISBN 0-201-57168-4.
[2] RUMBAUGH, J., BOOCH, G. and JACOBSSON, I. UML Reference Manual, 1999,
Addison-Wesley ISBN 0-201-57168-X.
[3] WARMER, J.B. and KLEPPE, A.G. The Objet Constraint Language - precise
modeling with UML: Addison-Wesley Longman, Inc., 1997.
[4] FOWLER, M. UML Distilled, A Brief Guide to the Standard Object Modeling
Language, Third Addition, 2003, Addison-Wesley Professional.
[5] SCHENCK, D. and WILSON, P. Information Modeling: The EXPRESS Way, Oxford
University Press, 1993.
[6] CHEESMAN, J. and DANILES, J. UML Components - A simple process for

specifying component-based software, Addison-Wesley, 2000, ISBN 0201708515.
[7] Catalog of OMG Modeling and Metadata Specifications. Disponible en

<http://www.omg.org/technology/documents/modeling_spec_catalog.htm>
[8] UML Resource Page. Disponible en <http://www.uml.org>
[9] ISO 19107:2003 Geographic information - Spatial schema.
[10] ISO 19108:2002 Geographic information - Temporal schema.
[11] ISO 19109:2005 Geographic information - Rules for application schema.
[12] ISO 19110:2005 Geographic information - Methodology for feature

cataloguing.
[13] ISO 19115:2003 Geographic information - Metadata.
[14] ISO 19118:2005 Geographic information - Encoding.
[15] ISO 19119:2005 Geographic information - Services.
[16] ISO 19136: 2007 Geographic information - Geography Markup Language (GML).
85
NCh-ISO 19103
[17] ISO/IEC 11404:1996 Information technology - Programming languages, their

environments and system software interfaces - Language-
independent datatypes.
[18] ISO/IEC 10646:2003 Information technology - Universal Multiple-Octet Coded

Character Set (UCS).
[19] ISO/IEC 8859 Information technology - 8-bit single-byte coded graphic

todas las partes character sets.
[20] ISO 8601:2000 Data elements and interchange formats - Information

interchange - Representation of dates and times.
[21] ISO 3 Codes for the representation of names of countries and their
subdivisions - Part 1: Country codes.
166-1:1997
[22] ISO/TR 9007:1987 Information processing systems - Concepts and terminology
for the conceptual schema and the information base.
NOTA EXPLICATIVA NACIONAL
La equivalencia de las Normas Internacionales señaladas anteriormente con Norma Chilena, y su grado
de correspondencia es el siguiente:
Norma Internacional Norma nacional Grado de correspondencia

ISO 19107:2003 No hay -
ISO 19108:2002 No hay -
ISO 19109:2005 NCh-ISO 19109-2011 Idéntica
ISO 19110:2005 En estudio NCh-ISO 19110 -
ISO 19115:2003 NCh-ISO 19115-2011 Idéntica
ISO 19118:2005 No hay -
ISO 19119:2005 No hay -
ISO 19136: 2007 No hay -
ISO/IEC 8859 No hay -
todas las partes
ISO 8601:2000 NCh834.Of1999 La Norma Chilena NCh834.Of1999 es
una adopción equivalente de la norma
ISO 8601:1988.
ISO 3166-1:1997 NCh1505/1.Of2000 Equivalente
ISO/TR 9007:1987 No hay -
86
NCh-ISO 19103
Anexo F
(Informativo)
Justificación de los cambios editoriales
Tabla F.1 - Cambios editoriales
Cláusula/subcláusula Cambios editoriales Justificación
En toda la norma Se cambia “esta especificación Técnica” El documento corresponde a una norma.
por “esta norma”.
2 y Anexo E Se agrega una nota explicativa. Para detallar la equivalencia y el grado de
correspondencia de las Normas
Internacionales con las Normas Chilenas.
Anexo E Se elimina nota al pie de página La norma ISO ya está publicada como
relacionada con ISO 19136. ISO 19136:2007.
87
INSTITUTO NACIONAL DE NORMALIZACION z INN-CHILE
Geographic information - Conceptual schema language
Primera edición : 2010

Corregida y reimpresa : 2011
CORRESPONDENCIA CON NORMA INTERNACIONAL
ISO/TS 19103:2005 (E) Geographic information - Conceptual schema language, IDT
CIN 35.240.70
COPYRIGHT © 2011: INSTITUTO NACIONAL DE NORMALIZACION - INN * Prohibida reproducción y venta *

Dirección : Matías Cousiño Nº 64, 6º Piso, Santiago, Chile
Web : www.inn.cl
Miembro de : ISO (International Organization for Standardization) • COPANT (Comisión Panamericana de Normas Técnicas)

NCh-ISO 19103-2010-047

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

NCh-ISO 19103-2010-047

Cargado por

Copyright:

Formatos disponibles

NCh-ISO 19103

4 Términos, definiciones y abreviaciones 3

4.1 Términos de ISO/TS 19103 3

4.2 Términos UML 5

6 El perfil UML de ISO/TS 19103 10

6.2 Uso general de UML 10

6.5 Tipos de datos 11

6.7 Relaciones y asociaciones 34

6.8 Estereotipos y valores etiquetados 35

6.9 Atributos y asociaciones obligatorios, opcionales y condicionales 36

6.10 Denominación y espacios de nombres 36

6.14 Documentación de modelos 40

Anexo A (normativo) Conjunto de pruebas abstractas 42

Anexo B (informativo) Sobre lenguajes de esquema conceptual 43

Anexo C (informativo) Orientaciones de modelado 56

C.1 Orientaciones para el modelado con UML 56

C.2 Orientaciones para el modelado de información 59

C.3 Orientaciones para el modelado de servicios 63

C.4 Armonización de modelos 66

Anexo D (informativo) Introducción a UML 69

D.2 Uso general de UML 69

D.5 Tipos de datos 73

D.7 Relaciones y asociaciones 75

D.8 Estereotipos y valores etiquetados 79

D.9 Atributos y asociaciones opcionales, condicionales y obligatorios 81

D.10 Denominación y espacios de nombres 81

Anexo E (informativo) Bibliografía 85

Anexo F (informativo) Justificación de los cambios editoriales 87

Figura 1 Tipos de datos básicos 12

Figura 2 Tipos primitivos 13

Figura 3 Tipos numéricos 14

Figura 4 Cadena de caracteres 17

Figura 5 Tipos de fecha y hora 18

Figura 6 Tipos de datos de verdad 19

Figura 8 Tipo de colección 21

Figura 9 Tipos de colección - Tipo de conjunto 22

Figura 10 Tipos de colección - Tipo de Multiconjunto 23

Figura 11 Tipo de colección - Tipo de secuencia 24

Figura 12 Clases de diccionario 25

Figura 13 Ejemplo de enumeración 26

Figura 14 Ejemplos de ListasdeCódigos 27

Figura 15 Tipos de registros 28

Figura 16 Tipos de nombres 29

Figura 17 Unidades de tipos de medidas 31

Figura 18 Ejemplo de estructura de paquete 39

Figura B.1 Trabajo de normas ISO de información geográfica basado en

Figura B.2 Desde la realidad al esquema conceptual basado en un formalismo

Figura B.3 Principio 100% ISO para modelado conceptual 45

Figura B.4 Capas de metamodelos del CSMF - Recurso de modelado de

Figura B.5 Relaciones del modelo general de features y el modelo UML

Figura B.6 Núcleo del Modelo General de Features ISO 19109 49

Figura B.7 Metamodelo central de UML 50

Figura B.8 Arquitectura de metamodelo para UML 51

Figura B.9 Puntos de vista del modelo RM-ODP de ISO 51

Figura B.10 Modelo de referencia de arquitectura ISO 19101 54

Figura D.1 La <<interface>> de estereotipo 70

Figura D.2 El estereotipo <<type>> 70

Figura D.3 Símbolos para definiciones de elementos derivados, visibilidad y

Figura D.4 Distintos tipos de relaciones 75

Figura D.5 Asociación 76

Figura D.6 Especificación de multiplicidad/cardinalidad 77

Figura D.7 Agregación 77

Figura D.8 Composición (agregación sólida) 78

Figura D.9 Estereotipos UML y valores etiquetados 79