Ntp-Iso 29481-2 PDF

NORMA TÉCNICA NTP-ISO 29481-2
PERUANA 2018
Dirección de Normalización - INACAL
Calle Las Camelias 817, San Isidro (Lima 27) Lima, Perú
L
IA
C
R
PA
O
L
TA
TO
Modelado de la información de los edificios. Manual de
N
entrega de la información. Parte 2: Marco de trabajo para la

IO
C
interacción
C
U
Building information models. Information delivery manual. Part 2: Interaction framework

D
O
(EQV. ISO 29481-2:2012 Building information models - Information delivery manual - Parte 2: Interaction
R
framework)
EP
R
SU
2018-12-28
1ª Edición
A
ID
IB
H
O
PR
R.D. N° 048-2018-INACAL/DN. Publicada el 2019-01-17 Precio basado en 128 páginas

I.C.S.: 91.010.01 ESTA NORMA ES RECOMENDABLE
Descriptores: BIM, modelado, edificación, guía, requisito, proyecto
© ISO 2012 - © INACAL 2018

L
IA
C
R
PA
O
L
TA
TO
N
IO
C
© ISO 2012
C
U
Todos los derechos son reservados. A menos que se especifique lo contrario, ninguna parte de esta
D
publicación podrá ser reproducida o utilizada por cualquier medio, electrónico o mecánico, incluyendo
O
fotocopia o publicándolo en el Internet o intranet, sin permiso por escrito del INACAL, único representante
R
de la ISO en territorio peruano.

EP
R
© INACAL 2018
SU
Todos los derechos son reservados. A menos que se especifique lo contrario, ninguna parte de esta
A
publicación podrá ser reproducida o utilizada por cualquier medio, electrónico o mecánico, incluyendo
D
fotocopia o publicándolo en el internet o intranet, sin permiso por escrito del INACAL.
I
IB
H
INACAL
O
PR
Calle Las Camelias 817, San Isidro

Lima - Perú
Tel.: +51 1 640-8820
administracion@inacal.gob.pe
www.inacal.gob.pe
i
© ISO 2012 - © INACAL 2018 - Todos los derechos son reservados
ÍNDICE
Página
ÍNDICE ii
PRÓLOGO iii
PRÓLOGO ISO v
L
IA
INTRODUCCIÓN vi
C
R
1 Objeto y campo de aplicación 1
PA
2 Referencias normativas 1
O
L
3 Términos y definiciones 2
TA
4 Principios de normalización TO 3
N
5 Formato de un marco de interacción 14
IO
C
ANEXO A (NORMATIVO) Definición del esquema de marco 19

C
de interacción
U
D
ANEXO B (NORMATIVO) Definición de plantillas 73

O
R
EP
ANEXO C (INFORMATIVO) Ejemplo de mapa 107

interacción simplificado de una oficina de diseño
R
SU
ANEXO D (INFORMATIVO) Principios para el algoritmo 127

Promotor
A
D
BIBLIOGRAFÍA 128
I
IB
H
O
PR
ii
PRÓLOGO
A. RESEÑA HISTÓRICA
A.1 El Instituto Nacional de Calidad - INACAL, a través de la Dirección de

Normalización es la autoridad competente que aprueba las Normas Técnicas Peruanas a
nivel nacional. Es miembro de la Organización Internacional de Normalización (ISO) y
la Comisión Electrotécnica Internacional (IEC), en representación del país.
L
IA
C
R
A.2 La presente Norma Técnica Peruana ha sido elaborada por el Comité
PA
Técnico de Normalización de Edificaciones y obras de ingeniería civil - Subcomité
Técnico de Normalización de Organización de la información sobre obras de
O
construcción, mediante el Sistema 1 o de Adopción, durante los meses de setiembre a
L
octubre de 2018, utilizando como antecedente a la norma ISO 29481-2:2012 Building
TA
information models - Information delivery manual - Parte 2: Interaction framework.
TO
N
A.3 El Comité Técnico de Normalización de Edificaciones y obras de
IO
ingeniería civil - Subcomité Técnico de Normalización de Organización de la información

C
sobre obras de construcción, presentó a la Dirección de Normalización -DN-, con fecha

C
2018-10-26, el PNTP-ISO 29481-2:2018, para su revisión y aprobación, siendo sometido

U
a la etapa de discusión pública el 2018-11-07. No habiéndose recibido observaciones, fue

D
oficializada como Norma Técnica Peruana NTP-ISO 29481-2:2018 Modelado de la

O
información de los edificios. Manual de entrega de la información. Parte 2: Marco

R
EP
de trabajo para la interacción, 1ª Edición, el 17 de enero de 2019.

R
SU
A.4 La presente Norma Técnica Peruana presenta cambios editoriales referidos

principalmente a terminología empleada propia del idioma español y ha sido estructurada
A
de acuerdo a las Guías Peruanas GP 001:2016 y GP 002:2016.

I D
IB
H
O
B. INSTITUCIONES QUE PARTICIPARON EN LA ELABORACIÓN

PR
DE LA NORMA TÉCNICA PERUANA
Secretaría UNIVERSIDAD DE LIMA
Presidente Javier Eduardo Arrieta Freyre
iii
Secretario Alexandre Almeida Del Savio
ENTIDAD REPRESENTANTE
Colegio de Arquitectos del Perú José Burgos Ventura

Juan Palacios Rojas
Corporación Aceros Arequipa S.A. Grace Atkins Zelada

Alberto Ogata Marcelo
L
IA
COSAPI S.A. Elmer Chávez Mauricio
C
Raúl Eyzaguirre Vela
R
PA
Graña y Montero José Taboada García
O
IDandBIM Felipe Quiroz Mory
L
TA
Municipalidad de San Isidro Paola Beltrán Nuñez
TO
Binmi Bravo Rosas
N
Pontificia Universidad Católica del Perú Xavier Brioso Lescano
IO
Diego Fuentes Hurtado

C
C
SENCICO José Luis Amado Travezaño

U
Gabriela Esparza Requejo

D
O
UNACEM Daniel Espinoza Gonzalez

R
EP
Jeffery Lewis Arriarán

R
Universidad de Lima Christian Iván Izquierdo Cárdenas

SU
Ana Luna Torres

A
Universidad Nacional de Ingeniería Félix Wilfredo Ulloa Velásquez

I D
IB
Universidad Peruana de Ciencias Aplicadas José Rodríguez Barboza

H
Carlos Huerta
O
PR
Consultor Christian Leyton Dávalos
Consultor José Salinas Saavedra.
iv
PRÓLOGO
(ISO)
La ISO (Organización Internacional de Normalización) es una federación mundial de

organismos nacionales de normalización (organismos miembros de ISO). El trabajo de
preparación de las normas internacionales normalmente se realiza a través de los comités
técnicos de ISO. Cada organismo miembro interesado en una materia para la cual se haya
establecido un comité técnico, tiene el derecho de estar representado en dicho comité. Las
organizaciones internacionales, públicas y privadas, en coordinación con ISO, también
L
IA
participan en el trabajo. ISO colabora estrechamente con la Comisión Electrotécnica
C
Internacional (IEC) en todas las materias de normalización electrotécnica.
R
PA
Las normas internacionales se redactan de acuerdo con las reglas establecidas en la Parte
O
2 de las Directivas ISO/IEC.
L
TA
TO
La tarea principal de los comités técnicos es preparar normas internacionales. Los
proyectos de normas internacionales adoptados por los comités técnicos se envían a los
N
organismos miembros para votación. La publicación como norma internacional requiere
IO
la aprobación por al menos el 75 % de los organismos miembros que emiten voto.

C
C
U
Se llama la atención sobre la posibilidad de que algunos de los elementos de este

D
documento puedan estar sujetos a derechos de patente. ISO no asume la responsabilidad

O
por la identificación de cualquiera o todos los derechos de patente.

R
EP
R
La NTP-ISO 29481-2 fue preparada por el Comité Técnico ISO/TC 59, Edificación y
SU
obra civil, Subcomité SC 13, Organización de información relativo a obras de

construcción.
A
D
I
IB
La NTP-ISO 29481 consta de las siguientes partes, bajo el título general Modelado de la
H
información de los edificios. Manual de entrega de la información:

O
PR
- Parte 1: Metodología y formato.  
- Parte 2: Marco de trabajo para la interacción. Las siguientes partes están

en proceso de elaboración:
- Parte 3: Definiciones de vista del modelo.
v
INTRODUCCIÓN
El modelado de la información de edificios proporciona un concepto para describir y

mostrar la información requerida en el diseño, construcción y operación de las
instalaciones construidas. Puede reunir diversos conjuntos de información utilizados en
la construcción, en un entorno de información común; reduciendo y a menudo
eliminando, la necesidad de tener en papel muchos tipos de documentación que
actualmente se usan.
L
IA
Un manual de entrega de información (IDM, Information Delivery Manual) proporciona
C
una ayuda significativa para obtener el máximo beneficio de un modelo de información
R
de un edificio o construcción (BIM, Building Information Model). Si la información
PA
requerida está disponible cuando se necesita y la calidad de la información es
O
satisfactoria, el proceso de construcción en sí se mejora mucho. Para que esto ocurra
debería haber una comprensión común de los procesos de construcción y de la
L
TA
información que se necesita y resulte de su ejecución.
TO
Esta parte de la Norma ISO 29481 se centra en aspectos del proceso de construcción que
N
se refieren a la gestión y coordinación de las partes involucradas. La coordinación

IO
depende de la comunicación, que debería estar bien estructurada, ser inequívoca, explícita
C
y ágil. Como se incide mucho en la coordinación y en la interacción, esta parte de la

C
U
Norma ISO 29481 proporciona un complemento natural a las normas que se centran en
D
la construcción de modelos, como son las Normas ISO 10303-239 e ISO 16739.
O
R
EP
Esta parte de la Norma ISO 29481, establece una metodología y un formato para describir
R
las labores de coordinación entre los actores de un proyecto de construcción. Describe

cómo identificar y definir los procesos de coordinación emprendidos y la información
SU
requerida para su ejecución. Los marcos de interacción resultantes permiten la

estandarización de la interacción en los procesos de construcción a nivel nacional, local
A
D
y de proyecto. También ofrece un formato para dar soporte a las soluciones

I
proporcionadas por los proveedores de soluciones TIC. Esta parte de la Norma ISO 29481
IB
integra diferentes sistemas de gestión de procesos para dar soporte a diferentes soluciones
H
O
TIC. De este modo, proporciona una base para el intercambio y la compartición fiable de
PR
información entre los usuarios, para que puedan confiar en que la información que envían
o reciben sea exacta y suficiente para las actividades de coordinación que necesitan
realizar.
El desarrollo de esta parte de la Norma ISO 29481, ha sido impulsado por la necesidad
de los usuarios de contar con un intercambio de información fiable. Se basa
principalmente en el estándar holandés VISI desarrollado en 2003.
vi
PERUANA 1 de 128
Modelado de la información de los edificios. Manual de

entrega de la información. Parte 2: Marco de trabajo para la
interacción
L
IA
C
1 Objeto y campo de aplicación
R
PA
Esta parte de la NTP-ISO 29481, especifica una metodología y un formato para describir las
O
“acciones de coordinación” entre los agentes de un proyecto de construcción durante todas
L
TA
las fases del ciclo de vida del bien.
TO
Por lo tanto, especifica:
N
IO
– Una metodología que describe un marco de interacción,

C
C
– Una manera adecuada de asignar responsabilidades e interacciones, que

U
proporciona un contexto del proceso para el flujo de la información,

D
O
–
R
Un formato en el que se debería especificar un marco de interacción.

EP
R
Esta parte de NTP-ISO 29481, pretende facilitar la interoperabilidad entre las aplicaciones
SU
de software utilizados en el proceso de construcción, promover la colaboración digital entre

los agentes en el proceso de construcción de edificios y proporcionar una base para un
A
intercambio de información precisa, fiable, repetible y de alta calidad.

D
I
IB
H
O
2 Referencias normativas
PR
Los documentos indicados a continuación, en su totalidad o en parte, son normas para

consulta indispensables para la aplicación de este documento. Para las referencias con fecha,
solo se aplica la edición citada. Para las referencias sin fecha se aplica la última edición
(incluida cualquier modificación de esta).
ISO 29481-1 Modelado de la información de los edificios.

Manual de entrega de la información. Parte 1:
Metodología y formato
PERUANA 2 de 128
3 Términos y definiciones
Para los fines de este documento, se aplican los términos y definiciones siguientes:
L
IA
3.1
C
IDM
R
manual para entrega de información:
PA
documentación que recoge el proceso de negocio y da especificaciones detalladas de la
información que cualquier agente del proyecto podría necesitar proporcionar en cada
O
momento particular dentro de un proyecto
L
TA
3.2 TO
marco de interacción:
N
descripción formal de los elementos de interacción, incluyendo la definición de atribuciones,
IO
transacciones, mensajes en la transacción y datos en los mensajes

C
C
U
3.3
D
esquema del marco de interacción:

O
descripción formal de las atribuciones con las que se han de cumplir los marcos de
R
EP
interacción
R
SU
3.4
esquema de interacción:
A
descripción formal de las atribuciones con las que se han de completar los mensajes enviados
D
y recibidos
I
IB
H
O
3.5
PR
promotor:
algoritmo que genera un esquema de interacción, desde un marco de interacción, un esquema
del marco de interacción y ficheros de plantillas como entradas
3.6
archivo de plantillas:
archivo que contiene una serie de plantillas, independiente del marco de interacción, para
generar un esquema de interacción

PERUANA 3 de 128
3.7
VISI:
acrónimo del estándar holandés para la comunicación entre socios en los proyectos de
construcción.
NOTA 1: VISI viene de “Voorwaarden scheppen voor Invoeren Standaardisatie ICT in de
L
Infrastructuursector”, lo que se traduce como “Creación de condiciones para la implementación de la
IA
estandarización de TICs para la industria de la construcción”.
C
R
PA
O
4 Principios de normalización
L
TA
4.1 Generalidades
TO
N
Este apartado se incluye para destacar y ayudar a explicar los conceptos esenciales en los
IO
que se basa esta parte de la NTP-ISO 29481.

C
C
U
D
4.2 BIM e IDM

O
R
EP
El modelado de información de los edificios integra los diversos conjuntos de información

utilizados en la construcción en un entorno de información común. Para que esto suceda,
R
debe haber una comprensión común de los procesos de construcción y de la información que
SU
se necesita, para y desde su ejecución.

A
D
La NTP-ISO 29481, es un estándar que establece un método para el desarrollo de un Manual

I
IB
de Entrega de la Información.
H
O
PR
La metodología de IDM dada en la NTP-ISO 29481-1 debe utilizarse para todas las
referencias, para el desarrollo y uso del IDM.
4.3 Componentes del IDM
La metodología y los componentes del IDM son descritos en la NTP-ISO 29481-1. En esta
parte, se aporta una ilustración que muestra esquemáticamente cuáles son los distintos
componentes del IDM y cómo están relacionados entre sí.

PERUANA 4 de 128
Dentro del IDM hay dos perspectivas. Puede verse como requisitos de los usuarios, o como
soluciones técnicas. Dentro de las dos perspectivas, hay una serie de zonas que caracterizan
a los distintos componentes del IDM (véase la Figura 1).
L
IA
C
R
PA
O
L
TA
TO
N
IO
C
C
U
D
O
R
EP
Figura 1 – Zonas del IDM

R
SU
Dentro de la perspectiva de los requisitos del usuario las zonas son:

A
- Mapas de interacción, describiendo las atribuciones de cada agente y la

D
relación entre ellos.

I
IB
H
- Mapas de procesos, haciendo una descripción de aquellos procesos en los que

O
ocurre el intercambio de información.

PR
- Entrega de información, describiendo las necesidades del intercambio de la

información.
- Procesos de referencias (descripciones de intercambio almacenadas).
- El calendario del proyecto (ocurrencias de sucesos en el contexto de un

proyecto).

PERUANA 5 de 128
La perspectiva de soluciones técnicas incluye:
- Los objetos del negocio incluyendo los requisitos de intercambio del modelo.
 
- Las especificaciones de información, describiendo el esquema en el que se
L
basa el intercambio de información.
IA
C
- El modelo de la información de los edificios.
R
PA
Esta parte de la NTP-ISO 29481 se centra en el mapa de interacción y se basa en los
O
principios generales de la comunicación empresarial.
L
TA
4.4 TO
Principios básicos de la comunicación empresarial
N
IO
Una vez que un cliente ha pedido la entrega de un producto o servicio, se pone en marcha
C
una cadena de actividades en operación, cuyo efecto combinado es proporcionar el producto

C
o servicio. Esta cadena de actividades se denomina proceso de negocios. Más

U
específicamente, hablamos aquí de un proceso de negocio primario porque se inicia

D
externamente.
O
R
EP
Parte del proceso de negocios es la comunicación entre las partes involucradas. Esta parte
R
de la NTP-ISO 29481 se centra en la comunicación que se relaciona con la entrega de un

SU
resultado (comunicación performativa). La iniciación y ejecución de una solicitud es a través

de acciones comunicativas. En una acción comunicativa, las dos partes están siempre
A
involucradas: la persona que realizó la acción y la persona a quien se dirige la acción. El

D
manejo de una solicitud ocurre en un patrón particular llamado transacción.

I
IB
H
O
PR

PERUANA 6 de 128
L
IA
C
R
PA
O
L
TA
TO
N
IO
Figura 2 - Patrón de una transación (Dietz, 2006)

C
C
U
En la Figura 2, se presenta la forma más simple de este patrón de transacción. Se demuestra

D
que la creación de un nuevo resultado de producción (por ejemplo, el "resultado deseado" es

O
la entrega de un documento) comienza con la solicitud de este resultado por alguien en el

R
papel de cliente a alguien en el papel de productor. Esto lleva el proceso al estado "resultado
EP
solicitado". El productor responde a la solicitud prometiendo producir el resultado deseado,

R
lo que lleva el proceso al estado "resultado prometido". Esto representa una tarea para el
SU
productor: tiene que cumplir con la promesa al preparar realmente el documento y decidir
entregárselo. En el acto de entrega del documento al cliente, el productor afirma que ha
A
cumplido con su promesa. El cliente responde a este estado, aceptando el resultado tal como
D
se produce. Esta acción completa la transacción.

I
IB
H
O
En la ejecución del proceso de un negocio, a menudo participan muchos actores. Su

PR
comportamiento depende de sus atribuciones en el proceso. Los roles/actores hacen negocios

con otros roles/actores ejecutando transacciones. Una representación útil de la interacción
entre roles/actores se denomina mapa de interacción.
4.5 Mapa de interacción
Un mapa de interacción debe identificar los tipos de atribuciones de cada actor y los tipos
de transacciones relevantes para un proceso determinado. El IDM establece una distinción
entre el rol del que hace una solicitud, el iniciador y el rol del que da efecto a esa petición,
PERUANA 7 de 128
el ejecutor. Una transacción sólo debe tener un iniciador y un solo ejecutor. La figura 3
muestra los componentes del mapa de interacción.
NOTA: La notación del mapa de interacción se basa en el modelo de construcción descrito en la

publicación del Prof. Jan L.G. Dietz. Esta notación difiere del BPMN (Business Process Model and
L
Notation, en español Modelo y Notación de Procesos de Negocios) y se utiliza para preparar mapas de
IA
forma que sean tan simples como sea posible. Además, proporciona el concepto de "transacción", que
C
no está disponible en el BPMN.
R
PA
O
L
TA
TO
N
IO
C
C
U
D
O
R
EP
R
SU
A
D
Figura 3 - Componentes de un mapa de interacción

I
IB
H
O
La ventaja del mapa de interacción es que concentra la atención en las relaciones entre los
PR
roles o atribuciones de cada actor, y a la vez, esconde tanto la complejidad del proceso dentro
del rol de cada actor, como los detalles de la interacción entre estos roles. El uso de roles
abstractos hace que el mapa de interacción sea válido para muchas situaciones diferentes. El
mapa de interacción es una valiosa herramienta para analizar y definir elementos esenciales
de un proceso de negocio. La figura 4 muestra un ejemplo simplificado de un mapa de
interacción de una oficina de diseño.

PERUANA 8 de 128
L
IA
C
R
PA
O
L
TA
TO
N
IO
C
C
U
D
Figura 4 - Ejemplo de un mapa de interacción

O
R
EP
En un mapa de interacción deben incluirse todas las transacciones necesarias para el manejo
R
de las contribuciones requeridas de funciones relevantes al BIM. Todos los roles y

SU
transacciones dentro del mapa de interacción deben tener una identidad y un nombre único.
La numeración es arbitraria. El nombre de la función se deriva de la actividad principal
A
realizada por cada actor; esto centra la contribución de los roles dentro del BIM. Un papel
D
compuesto es un papel que puede consistir en múltiples roles, pero cuya composición es
I
IB
desconocida o no relevante.
H
O
PR
Las interacciones se pueden resumir en una tabla de transacciones.
Tabla 1 - Tabla de transacción de una oficina de diseño simplificada
Resutlado de la transacción Tipo de transacción

Entrega del diseño T1, Entregar diseño
Entrega del sistema de especificación T2, Entregar el sisteam de especificación
Entrega del modelo 3D T3, Entregar el modelo 3D
Entrega del presupuesto T4, Entregar el presupuesto

PERUANA 9 de 128
4.6 Mensajes en la transacción
Una transacción debe contener un conjunto de mensajes que se intercambian para un

propósito particular. La transacción también estipula los papeles participantes, el punto en
el ciclo de vida y la secuencia en la que se deberían entregar los mensajes (si procede).
L
IA
C
R
Un ejemplo de una transacción, es el manejo de una solicitud para un modelo 3D. Véase la
PA
figura 5, que muestra los mensajes en una transacción como un diagrama de secuencia en la
notación UML (Unified Modeling Language). La transacción sólo puede iniciarse con el R1,
O
jefe de Proyecto, con el mensaje “Solicitud de modelo 3D”. El ingeniero 3D (rol R3) puede
L
responder con el mensaje "Trabajo hecho y pendiente de aprobación". Después del mensaje
TA
"Trabajo aprobado" o "Trabajo no aprobado", se completa la transacción.
TO
N
IO
C
C
U
D
O
R
EP
R
SU
A
ID
IB
H
O
PR
Figura 5 - Ejemplo de mensajes de una transacción
Un mensaje es un modelo de información complejo, que contiene más o menos datos. Los
mensajes pueden llevar archivos adjuntos vinculados. Así como un archivo adjunto, un
requisito de intercambio se puede transferir al rol del agente ejecutor, y el resultado
(contribución al BIM) se entrega al agente iniciador. Mediante el uso de transacciones, la
transferencia de información se introduce en un contexto de procesos.
PERUANA 10 de 128
4.7 Marco de interacción
Con el fin de orientar un proceso y la transferencia de información, los elementos de

interacción se describirán de manera coherente. Esta descripción coherente se denomina
marco de interacción. Un marco de interacción debe incluir:
L
IA
C
R
- Definición de roles.
PA
- Transacciones.
O
L
- Mensajes de la transacción.
TA
- El orden de los mensajes de la transacción. TO
N
- Los elementos de los datos en el mensaje.
IO
C
C
Se puede preparar un marco de interacción para un área de aplicación definida y utilizarse

U
como un estándar a nivel internacional, nacional, de organización o de proyecto. Por

D
ejemplo, en los Países Bajos, se desarrolla un marco de interacción a nivel nacional para la
O
finalización de todos los procedimientos contractuales durante la ejecución del proyecto de

R
EP
construcción. Esta parte de la NTP-ISO 29481, puede ser utilizada como una plantilla por
organizaciones y proyectos; y también permite ser ajustada a las necesidades específicas de
R
cada caso.
SU
EJEMPLO: Un marco de interacción puede incluir el atributo CostEstimation como un ejemplar de

A
SimpleElementType que se utilizará como elemento obligatorio para un determinado mensaje. También
D
puede incluir una restricción en el formato del atributo CostEstimation (por ejemplo, sólo soles, dólares
I
o euros con dos decimales).

IB
H
O
4.8 Apoyo de soluciones de software

PR
4.8.1 Visión de conjunto
El siguiente paso es apoyar el marco de interacción con soluciones de software. El objetivo

es:
- Apoyar la edición de un marco de interacción.

PERUANA 11 de 128
- Garantizar la integridad y validez de un marco de interacción.
- Apoyar la portabilidad de un marco de interacción.
- Apoyar el funcionamiento de los sistemas de información.
L
IA
- Apoyar la interoperabilidad de la comunicación.
C
R
PA
Se pueden identificar dos niveles en lo que respecta al apoyo de soluciones de software. El
primer nivel se refiere al marco de interacción. El segundo nivel se refiere a la comunicación
O
real en la que se basa el marco de interacción. Esta parte de la NTP-ISO 29481 se aplica a
L
ambos niveles.
TA
TO
En la Figura 6 se ofrece una descripción general de cómo funcionan las soluciones de
N
software. En las secciones siguientes se da una explicación de las figuras.
IO
C
C
4.8.2 Apoyo al marco de interacción

U
D
O
A fin de apoyar la portabilidad de un marco de interacción, debería quedar claro qué reglas
R
EP
ha de cumplir un marco de interacción. Estas reglas deben incluirse en un esquema de marco

de interacción, que se graba como un archivo de esquema XSD. Un marco de interacción
R
comprende a los ejemplares de las clases definidas en el esquema, y debe registrarse como
SU
un archivo XML.
A
EJEMPLO
D I
IB
El esquema del marco de interacción define que se puede incluir la definición de atributos
H
(SimpleElementType) y las restricciones a los atributos (UserdefinedType) en un marco de

O
interacción.
PR
El Capítulo 5 describe el esquema del marco de interacción y las clases disponibles.
Todos los marcos de interacción deberían cumplir con el esquema del marco de interacción.
Para validar el marco de interacción debería usarse un editor de la estructura del esquema
del marco de interacción.
PERUANA 12 de 128
4.8.3 Promotor
Una vez que un marco de interacción válido está disponible, puede ser interpretado por un
sistema de información adecuado. A continuación, este sistema puede soportar las
comunicaciones de acuerdo con las opciones establecidas en el marco de interacción.
L
IA
Finalmente, es deseable poder validar los mensajes recibidos y enviados. Esto se hace con
C
el esquema de interacción.
R
PA
El esquema de interacción es generado con un algoritmo genérico llamado Promotor, quien
O
“promueve” ejemplares XML en clases XSD. La entrada es:
L
TA
- Marco de interacción (XML).  
TO
- Esquema del marco de interacción (XSD). 
N
IO
- Archivo de plantillas (XSD), que contiene un número de plantillas no

C
descritas en un marco de interacción, pero son válidos para cada esquema de

C
interacción, por ejemplo, el encabezado del mensaje.

U
D
O
R
La salida es un esquema de interacción, que se guarda como un archivo XSD.

EP
EJEMPLO
R
SU
El “Promotor” toma información del marco de interacción para incluir el atributo

CostEstimation, para ser utilizado como un elemento obligatorio para un determinado
A
mensaje y crea un esquema de interacción que define el mensaje con el atributo

DI
CostEstimation.
IB
H
O
El Anexo B describe el archivo XSD de plantillas.

PR
El Anexo D da los principios del Promotor.

PERUANA 13 de 128
L
IA
C
R
PA
O
L
TA
TO
N
IO
C
C
U
D
O
Figura 6 – Validez de las soluciones de software

R
EP
R
4.8.4 Apoyo a la comunicación

SU
A
D
Todo sistema de información que participe en la comunicación, tal como se define en el

I
marco de interacción, debería operar sobre la base del marco de interacción y del esquema
IB
de interacción correspondiente. Cada mensaje enviado o recibido debería ser válido según el
H
O
esquema de interacción.
PR
4.8.5 Implementación técnica de la comunicación
Con el fin de garantizar que los mensajes con archivos adjuntos en sentido técnico puedan
intercambiarse entre sistemas de información, se necesitan directrices de implementación.
Los temas a cubrir incluyen:
- Protocolo de comunicación.

PERUANA 14 de 128
- Arquitectura/servidores de comunicaciones.
- Cifrado.
- Llamadas de función SOAP (Simple Objet Access Protocol)
L
IA
C
Las directrices de aplicación están fuera del alcance de esta parte de la NTP-ISO 29481.
R
PA
O
5 Formato de un marco de interacción
L
TA
5.1 Introducción TO
N
IO
El capítulo 4 explica que, con la finalidad de apoyar las soluciones de software, cada marco
C
de interacción ha de cumplir con el esquema de la estructura de interacción. Este capítulo se

C
incluye para definir el formato de un marco de interacción a través de una descripción del
U
esquema del marco de interacción.

D
O
R
EP
El subcapítulo 5.2 proporciona una visión general de las clases de información que pueden
ocurrir en un marco de interacción y se definen en el esquema del marco de interacción.
R
Dado que un marco de interacción se define en XML, la palabra "tipo" se utiliza en lugar de
SU
clase. El Anexo A, da la descripción completa del esquema del marco de interacción. El

anexo C, proporciona un ejemplo de un ejemplar de un marco de interacción.
A
D I
IB
5.2 Tipos de información en el esquema del marco de interacción

H
O
PR
5.2.1 Introducción
Un esquema consta de muchas clases o tipos. En esta sección, se da una breve descripción
de los tipos disponibles en el esquema del marco de interacción. El Anexo A, contiene una
descripción completa en XML del esquema del marco de interacción. Debe crearse un marco
de interacción a partir de ejemplares de estos tipos y debe tener un encabezado que señale al
esquema con los tipos disponibles definidos.

PERUANA 15 de 128
5.2.2 AppendixType
El AppendixType define la estructura de los elementos referentes a los metadatos. Un

ejemplar de un tipo de apéndice se utiliza para definir ciertos tipos de archivos o documentos
que pueden formar parte de los mensajes de envío/recepción. La estructura de los elementos
L
IA
relacionados con una instancia de un AppendixType representa los metadatos específicos que
C
se requieren para cierto tipo de archivo o documento.
R
PA
5.2.3 ComplexElementType
O
L
TA
Un ComplexElementType es una colección de SimpleElementTypes. Cada
SimpleElementType ocurre exactamente el número de veces que está relacionado.
TO
N
5.2.4 ElementCondition
IO
C
C
Un ejemplar de un ElementCondition describe el comportamiento de los valores de los

U
elementos en los mensajes sucesivos. Por ejemplo, cuando se crea un ejemplar del tipo
D
O
ElementCondition con el valor FIXED, se indica que los elementos de los mensajes
R
sucesivos han de copiarse cuando el mismo elemento está disponible y no se puede cambiar
EP
el valor. Un ElementCondition puede referirse a diferentes niveles en un marco. Puede estar

directamente relacionado con un SimpleElement, pero también es posible relacionar un
R
ElementCondition con un ComplexElement o un MessageInTransactionType. En este caso,

SU
el ElementCondition es válido para todos los elementos que forman parte de la

estructura/colección de elementos de los tipos relacionados.
A
I D
IB
5.2.5 GroupType
H
O
PR
Un GroupType hace posible crear varios ejemplares de un grupo con su propio contenido
específico. El GroupType puede utilizarse para categorizar mensajes dentro de una
transacción o documentos relacionados con mensajes dentro de una transacción.
5.2.6 MessageType
El MessageType se utiliza para definir el contenido de un mensaje. Los elementos que

forman parte de un mensaje, están a su vez, agrupados en uno o más ejemplares de un
ComplexElementType.
PERUANA 16 de 128
5.2.7 MessageInTransactionType
Un MessageInTransactionType (MITT) es una definición que se utiliza para relacionar un

MessageType con un TransactionType. El mismo tipo de mensaje puede darse más de una
vez en un tipo de transacción dada y viceversa. Es posible relacionar más de un ejemplar de
L
IA
MessageType a un ejemplar de TransactionType, y un ejemplar de MessageType a varios
C
ejemplares de TransactionType. Además, un MITT ofrece una opción para invertir la
R
dirección de ejecutor a iniciador. Otra opción controla si el flujo de mensajes es bloqueado
PA
por transacciones secundarias abiertas o no.
O
L
5.2.8 OrganizationType
TA
TO
Es la definición de un cierto grupo de organizaciones. En el marco, al menos un ejemplar
N
esta disponible en común, con el objeto de definir la estructura de los elementos de una
IO
organización.
C
C
U
5.2.9 PersonType
D
O
R
EP
Es la definición de un tipo de persona. En el marco de trabajo, al menos un ejemplar esta

disponible en común, con el objetivo de definir la estructura de los elementos que definen a
R
una persona. PersonType se puede utilizar para categorizar los grupos de personas que están
SU
relacionadas con un rol.

A
D
5.2.10 ProjectType
I
IB
H
O
Es la definición de un tipo de proyecto. En el marco, al menos un ejemplar esta disponible

PR
en común, con el objeto de definir la estructura de los elementos para definir el proyecto.
5.2.11 RoleType
Es la definición de un rol. Los ejemplares de un RoleType son requisitos previos para crear
un TransactionType dentro de un marco de trabajo.

PERUANA 17 de 128
5.2.12 SimpleElementType
El SimpleElementType es una definición que describe las propiedades que pueden darse
dentro de estructuras de objetos. La relación con un objeto es siempre a través de un
ComplexElementType.
L
IA
C
R
5.2.13 TransactionPhaseType
PA
O
Es la definición que se puede utilizar para definir un ejemplar que describe la fase en la que
L
se encuentra una transacción. Por ejemplo, un ejemplar de TransactionPhaseType puede ser
TA
"resultado requerido" o "en espera".
TO
N
5.2.14 TransactionType
IO
C
C
Es la definición de una transacción. En un ejemplar de una transacción, se definen las

U
funciones del iniciador y del ejecutor.

D
O
R
EP
5.2.15 UserDefinedType
R
SU
El UserDefinedType se utiliza para establecer los tipos de datos (por ejemplo, una cadena de
texto) y restricciones al XSD. Por ejemplo, con un ejemplar de un UserDefinedType, se
A
puede definir la longitud mínima de una cadena de texto.

ID
IB
H
La Figura 7 visualiza el modelo del esquema del marco de interacción, incluyendo todas sus
O
referencias.
PR

PERUANA 18 de 128
L
IA
C
R
PA
O
L
TA
TO
N
IO
C
C
U
D
O
R
EP
R
Figura 7 - Tipos y referencias del esquema del marco de interacción

SU
A
D
I
IB
H
O
PR

PERUANA 19 de 128
ANEXO A
(NORMATIVO)
Definición del esquema de marco de interacción
L
IA
C
R
A.1 Introducción
PA
O
Un marco de interacción ha de cumplir con las reglas que se incluyen en un esquema de
L
marco de interacción. En este anexo, la definición del esquema de la estructura de interacción
TA
se da en formato EXPRESS y en formato XSD. Además, se describen los tipos de elementos,
atributos, elementos y referencias. TO
N
IO
Todos los objetos en un marco de interacción requieren una fecha de inicio y una fecha de
C
finalización. Este requisito permite limitar el tiempo de validez de un determinado objeto.

C
U
D
A.2 Definición del esquema de marco de interacción (formato EXPRESS)

O
R
EP
SCHEMA ISO 29481_Part_2A;

R
SU
ENTITY ProjectType; – La definición de un grupo específico de proyectos. Generalmente

solo estará presente un ejemplar en un marco de interacción que defina la estructura de los
A
elementos que debería exponer cada ejemplar de proyecto.

I D
IB
namespace: STRING; 
H
O
description: STRING; 
PR
startDate: DATETIME; 
endDate: DATETIME; 
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
PERUANA 20 de 128
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
L
IA
code: OPTIONAL STRING;
C
R
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
PA
END_ENTITY;
O
L
ENTITY PersonType; – La definición de un grupo específico de personas. Generalmente
TA
solo estará presente un ejemplar en un marco de interacción que defina la estructura de los
TO
elementos que debería exponer cada ejemplar de organización.
N
description: STRING;
IO
C
startDate: DATETIME;
C
U
endDate: DATETIME;
D
O
state: STRING;
R
EP
dateLaMu: DATETIME; 
R
SU
userLaMu: STRING; 
A
D
language: OPTIONAL STRING; 

I
IB
H

O
PR
END_ENTITY;
ENTITY OrganisationType; – La definición de un grupo específico de organizaciones.

Generalmente solo estará presente un ejemplar en un marco de interacción que defina la
estructura de los elementos que debería exponer cada ejemplar de persona.
PERUANA 21 de 128
endDate: DATETIME;
L
IA
state: STRING;
C
R
dateLaMu: DATETIME;
PA
userLaMu: STRING;
O
L
TA
category: OPTIONAL STRING; TO
N
IO
C

C
U

D
O
END_ENTITY;
R
EP
ENTITY AppendixType; – Un AppendixType contiene la definición de un archivo adjunto.

R
Los elementos de datos que se debería registrar con un archivo adjunto se pueden especificar
SU
en la sección de elementos complejos.

A
ID
IB
H
O
endDate: DATETIME;
PR
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;

PERUANA 22 de 128
L
IA
END_ENTITY;
C
R
ENTITY ComplexElementType; – Un ComplexElementType contiene un juego de
PA
SimpleElementTypes. Cada SimpleElementType declarado se da exactamente el número de
veces que se menciona.
O
L
TA
startDate: DATETIME; TO
N
endDate: DATETIME;
IO
C
state: STRING; dateLaMu: DATETIME;

C
U
userLaMu: STRING; language: OPTIONAL STRING;

D
O
R

EP

R
SU

A
simpleElements: OPTIONAL SET [0:?] OF SimpleElementType;

D
I
IB
END_ENTITY;
H
O
ENTITY MessageType; – La definición de un tipo de mensaje (MessageType), especifica la

PR
estructura del mensaje y qué juego de SimpleElementType (a través de

ComplexElementType) puede acompañar.
endDate: DATETIME;
state: STRING;
PERUANA 23 de 128
dateLaMu: DATETIME;
language: OPTIONAL STRING; 
L
IA
category: OPTIONAL STRING; 
C
R
PA
O
L
TA
appendixTypes: OPTIONAL SET [1:?] OF AppendixType;TO
N
END_ENTITY;
IO
ENTITY ElementCondition; – La condición de cómo se utiliza un SimpleElementType

C
C
dentro de un tipo de mensaje.

U
D
O
R
condition: STRING;
EP
R

SU
complexElement: OPTIONAL ComplexElementType;

A
D
simpleElement: OPTIONAL SimpleElementType;

I
IB
messageInTransaction: OPTIONAL MessageInTransactionType;

H
O
END_ENTITY;
PR
ENTITY SimpleElementType; – La definición de un tipo de elemento simple

(SimpleElementType). Este tipo de elemento especifica una propiedad que se puede dar
dentro de varias estructuras de objetos, por ejemplo, en MessageType (véase también
AppendixType, ProjectType, PersonType y OrganizationType). Un SimpleElementType
siempre está incrustado en un ComplexElementType.

PERUANA 24 de 128
interfaceType: STRING;
state: STRING; 
L
IA
dateLaMu: DATETIME;
C
R
userLaMu: STRING;
PA
O
L
TA
helpInfo: OPTIONAL STRING; TO
N
valueList: OPTIONAL STRING;
IO
C
userDefinedType: UserDefinedType;
C
U
END_ENTITY;
D
O
R
ENTITY UserDefinedType; – Una especificación de un tipo de datos (que se utilizará en un

EP
SimpleElementType). Este tipo de datos encapsula áreas de relleno en el mensaje final, por
ejemplo un código postal holandés comienza siempre con cuatro dígitos y luego dos
R
caracteres.
SU
A
ID
state: STRING;
IB
H
dateLaMu: DATETIME;
O
PR
userLaMu: STRING;
baseType: STRING;
xsdRestriction: OPTIONAL STRING;

PERUANA 25 de 128
END_ENTITY;
ENTITY MessageInTransactionType; – La participación de un MessageType dentro de un

TransactionType relacionado con un cierto tipo de grupo (GroupType).
requiredNotify: INTEGER;
L
IA
C
dateLaMu: DATETIME;
R
PA
userLaMu: STRING;
O
received: BOOLEAN;
L
TA
send: BOOLEAN;
TO
state: STRING;
N
IO
initiatorToExecutor: OPTIONAL BOOLEAN;

C
C
openSecondaryTransactionsAllowed: OPTIONAL BOOLEAN;

U
D
firstMessage: OPTIONAL BOOLEAN;

O
R
EP
message: MessageType;
R
previous: OPTIONAL SET [0:?] OF MessageInTransactionType;

SU
transaction: TransactionType;
A
D
transactionPhase: OPTIONAL TransactionPhaseType;

I
IB
H
group: GroupType;
O
PR
appendixTypes: OPTIONAL SET [1:?] OF AppendixType;
END_ENTITY;
ENTITY TransactionPhaseType; – La definición de una fase relacionada con una

transacción. Algunos ejemplos pueden ser "asignación aceptada" o "parte de resultado
recibida".

PERUANA 26 de 128
endDate: DATETIME;
state: STRING;
L
IA
dateLaMu: DATETIME;
C
R
userLaMu: STRING;
PA
O
L
TA
helpInfo: OPTIONAL STRING; TO
N
IO
C
END_ENTITY;
C
U
ENTITY TransactionType; – La definición de un tipo de transacción. Un tipo de transacción

D
puede hacer referencia a otros tipos de transacción. Una transacción será iniciada por una
O
persona perteneciente a una organización que desempeñe un determinado rol. En este nivel,
R
EP
el tipo de rol del iniciador debería declararse (que lo hará cumplir el esquema
promocionado). Lo mismo ocurre con el ejecutor.
R
SU
A
ID
IB
endDate: DATETIME;
H
O
state: STRING;
PR
dateLaMu: DATETIME;
userLaMu: STRING;

PERUANA 27 de 128
result: OPTIONAL STRING;
subTransactions: OPTIONAL SET [1:?] OF TransactionType;
L
IA
initiator: RoleType;
C
R
executor: RoleType;
PA
appendixTypes: OPTIONAL SET [1:?] OF AppendixType;
O
L
END_ENTITY;
TA
TO
ENTITY RoleType; - La definición de un tipo de rol específico.
N
IO
C
C
U
endDate: DATETIME;
D
O
R
state: STRING;
EP
dateLaMu: DATETIME;
R
SU
userLaMu: STRING;
A

ID
IB

H
O

PR
responsibilityScope: OPTIONAL STRING;
responsibilityTask: OPTIONAL STRING;
responsibilitySupportTask: OPTIONAL STRING;
responsibilityFeedback: OPTIONAL STRING;

PERUANA 28 de 128
END_ENTITY;
ENTITY GroupType; – La definición de un grupo para almacenar archivos adjuntos

enviados con un mensaje dentro de una transacción.
L
IA
C
R
PA
endDate: DATETIME;
O
state: STRING;
L
TA
dateLaMu: DATETIME;
TO
userLaMu: STRING;
N
IO

C
C

U
D

O
R
EP
END_ENTITY;
R
END_SCHEMA;
SU
A
A.3 Definición del esquema de marco de interacción (formato XSD)

ID
IB
H
<?xml version=”1.0” encoding = ”UTF-8”? >

O
<xsd:schema targetNamespace=http://www.ISO 29481_Part_2A.com/schemas xmlns:iso29481p2a =

PR
http://www.ISO 29481_Part_2A.com/schemas” xmlns:xsd = ”http://www.w3.org/2001/XMLSchema”

elementFormDefault = ”qualified” >
<!– root element declaration (for SCHEMA definitions) →
<xsd:element name=”ISO 29481_Part_2A” >
<xsd:complexType>
<xsd:choice maxOccurs=”unbounded” >
<xsd:element ref=”iso29481p2a:AppendixType”/ >
<xsd:element ref=”iso29481p2a:ComplexElementType”/ >
<xsd:element ref=”iso29481p2a:ElementCondition”/ >
<xsd:element ref=”iso29481p2a:GroupType”/ >
<xsd:element ref=”iso29481p2a:MessageInTransactionType”/ >
<xsd:element ref=”iso29481p2a:MessageType”/ >
<xsd:element ref=”iso29481p2a:OrganisationType”/ >
PERUANA 29 de 128
<xsd:element ref=”iso29481p2a:PersonType”/ >

<xsd:element ref=”iso29481p2a:ProjectType”/ >
<xsd:element ref=”iso29481p2a:RoleType”/ >
<xsd:element ref=”iso29481p2a:SimpleElementType”/ >
<xsd:element ref=”iso29481p2a:TransactionPhaseType”/ >
<xsd:element ref=”iso29481p2a:TransactionType”/ >
<xsd:element ref=”iso29481p2a:UserDefinedType”/ >
L
IA
</xsd:choice>
</xsd:complexType>
C
</xsd:element>
R
<!– element declarations (for ENTITY definitions) →
PA
<xsd:element name=”AppendixType” type = ”iso29481p2a:AppendixTypeType” >
<xsd:annotation>
O
<xsd:documentation>An AppendixType contains the definition of an appendix.
L
Which data items should be recorded with an appendix can be specified in the complex element
TA
section.</xsd:documentation>
</xsd:annotation>
</xsd:element> TO
<xsd:element name=”ComplexElementType”type=”iso29481p2a:ComplexElementTypeType” >
N
<xsd:annotation>
IO
<xsd:documentation>A ComplexElementType contains a set of SimpleElementTypes.

Each stated SimpleElementType occurs exactly the number of times mentioned.</xsd:documentation>
C
</xsd:annotation>
C
</xsd:element>
U
<xsd:element name=”ElementCondition” type = ”iso29481p2a:ElementConditionType” >

D
<xsd:annotation>
O
<xsd:documentation>The condition of a SimpleElementType as used within a specific

R
MessageType.</xsd:documentation>
EP
</xsd:annotation>
</xsd:element>
R
<xsd:element name=”GroupType” type = ”iso29481p2a:GroupTypeType” >

SU
<xsd:annotation>
<xsd:documentation>The definition of a group to store appendices sent with a message
within a transaction.</xsd:documentation>
A
</xsd:annotation>
D
</xsd:element>
I
IB
<xsd:element name=”MessageInTransactionType” type =

H
”iso29481p2a:MessageInTransactionTypeType” >
O
<xsd:annotation>
PR
<xsd:documentation>The occurrence of a MessageType within a TransactionType

related to a certain group type (GroupType).</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”MessageType” type = ”iso29481p2a:MessageTypeType” >
<xsd:annotation>
<xsd:documentation>The definition of a type of message (MessageType),
specifying the structure of the message and which set of SimpleElementType's (via ComplexElementType's)
may accompany.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”OrganisationType” type = ”iso29481p2a:OrganisationTypeType” >
<xsd:annotation>
PERUANA 30 de 128
<xsd:documentation>The definition of a specific group of organisations.

Generally only one instance will be present in a interaction framework defining the structure of elements that
each instance of organisation should expose.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name=”PersonType” type = ”iso29481p2a:PersonTypeType” >
<xsd:annotation>
L
<xsd:documentation>The definition of a specific group of persons. Generally only one
IA
instance will be present in a interaction framework defining the structure of elements that each instance of person should
C
expose.</xsd:documentation>
R
</xsd:annotation>
</xsd:element>
PA
<xsd:element name=”ProjectType” type = ”iso29481p2a:ProjectTypeType” >
<xsd:annotation>
O
<xsd:documentation>The definition of a specific group of projects. Generally only one
instance will be present in a interaction framework defining the structure of elements that each instance of project should
L
expose.</xsd:documentation>
TA
</xsd:annotation>
</xsd:element>
TO
<xsd:element name=”RoleType” type = ”iso29481p2a:RoleTypeType” >
<xsd:annotation>
N
<xsd:documentation>The definition of a specific role type.</xsd:documentation>
IO
</xsd:annotation>
</xsd:element>
C
<xsd:element name=”SimpleElementType” type = ”iso29481p2a:SimpleElementTypeType” >

C
<xsd:annotation>
U
<xsd:documentation>The definition of a simple element type (SimpleElementType). This

D
element type specifies a property whic may occur within various object structures like for example in MessageType (see
O
also AppendixType, ProjectType, PersonType and OrganisationType). A SimpleElementType is alway embedded in a

ComplexElementType.</xsd:documentation>
R
</xsd:annotation>
EP
</xsd:element>
<xsd:element name=”TransactionPhaseType” type = ”iso29481p2a:TransactionPhaseTypeType” >
R
<xsd:annotation>
SU
<xsd:documentation>The definition of a phase related to a transaction. Examples are

'assignment accepted' or 'result part received'.</xsd:documentation>
</xsd:annotation>
A
</xsd:element>
D
<xsd:element name=”TransactionType” type = ”iso29481p2a:TransactionTypeType” >

I
<xsd:annotation>
IB
<xsd:documentation>The definition of a type of transaction. A transaction type may

H
reference again other transaction types. A transaction will be initiated by a person belonging to an organisation
O
fulfilling a certain role. At this level the role type of the initiator should be stated (the promoted schema will enforce
PR
this). The same holds for the executor.</xsd:documentation>

</xsd:annotation>
</xsd:element>
<xsd:element name=”UserDefinedType” type = ”iso29481p2a:UserDefinedTypeType” >
<xsd:annotation>
<xsd:documentation>A specification of a data type (to be used in a
SimpleElementType).</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!– element reference declarations (for ENTITY definitions) →

<xsd:element name=”AppendixTypeRef” type = ”iso29481p2a:AppendixTypeTypeRef”/ >
<xsd:element name=”ComplexElementTypeRef” type = ”iso29481p2a:ComplexElementTypeTypeRef”/ >
<xsd:element name=”ElementConditionRef” type = ”iso29481p2a:ElementConditionTypeRef”/ >
<xsd:element name=”GroupTypeRef” type = ”iso29481p2a:GroupTypeTypeRef”/ >
PERUANA 31 de 128
<xsd:element name=”MessageInTransactionTypeRef” type =

”iso29481p2a:MessageInTransactionTypeTypeRef”/ >
<xsd:element name=”MessageTypeRef” type = ”iso29481p2a:MessageTypeTypeRef”/ >
<xsd:element name=”OrganisationTypeRef” type = ”iso29481p2a:OrganisationTypeTypeRef”/ >
<xsd:element name=”PersonTypeRef” type = ”iso29481p2a:PersonTypeTypeRef”/ >
<xsd:element name=”ProjectTypeRef” type = ”iso29481p2a:ProjectTypeTypeRef”/ >
<xsd:element name=”RoleTypeRef” type = ”iso29481p2a:RoleTypeTypeRef”/ >
<xsd:element name=”SimpleElementTypeRef” type = ”iso29481p2a:SimpleElementTypeTypeRef”/ >
L
IA
<xsd:elementname=”TransactionPhaseTypeRef”type = ”iso29481p2a:TransactionPhaseTypeTypeRef”/ >
<xsd:element name=”TransactionTypeRef” type = ”iso29481p2a:TransactionTypeTypeRef”/ >
C
<xsd:element name=”UserDefinedTypeRef” type = ”iso29481p2a:UserDefinedTypeTypeRef”/ >
R
<!– complex types for element declarations (for ENTITY definitions) →
PA
<xsd:complexType name=”AppendixTypeType” >
<xsd:complexContent>
<xsd:extension base=”iso29481p2a:elementType” >
O
<xsd:sequence>
L
<xsd:element name=”description” type = ”xsd:string”/ >
TA
<xsd:element name=”startDate” type = ”xsd:dateTime”/ >
<xsd:element name=”endDate” type = ”xsd:dateTime”/ >
TO
<xsd:element name=”state” type = ”xsd:string”/ >
<xsd:element name=”dateLaMu” type = ”xsd:dateTime”/ >
<xsd:element name=”userLaMu” type = ”xsd:string”/ >
N
<xsd:element name=”language” type = ”xsd:string” minOccurs = ”0”/ >

IO
<xsd:element name=”category” type = ”xsd:string” minOccurs = ”0”/ >

C
<xsd:element name=”helpInfo” type = ”xsd:string” minOccurs = ”0”/ >

<xsd:element name=”code” type = ”xsd:string” minOccurs = ”0”/ >
C
<xsd:element name=”complexElements” minOccurs = ”0” >

U
<xsd:complexType>
D

O

R
<xsd:element
EP
ref=”iso29481p2a:ComplexElementTypeRef”/ >
</xsd:choice>
R
</xsd:complexType>
</xsd:element>
SU
</xsd:sequence>
</xsd:extension>
A
</xsd:complexContent>
D
</xsd:complexType>
<xsd:complexType name=”ComplexElementTypeType” >
I
IB
H
O
<xsd:sequence>
PR

<xsd:element name=”language” type = ”xsd:string” minOccurs = ”0”/ >
<xsd:element name=”category” type = ”xsd:string” minOccurs = ”0”/ >
<xsd:element name=”helpInfo” type = ”xsd:string” minOccurs = ”0”/ >

<xsd:complexType>
<xsd:element
PERUANA 32 de 128
ref=”iso29481p2a:ComplexElementTypeRef”/ >
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name=”simpleElements” minOccurs = ”0” >
<xsd:complexType>
<xsd:element ref=”iso29481p2a:SimpleElementType”/ >
L
IA
<xsd:element ref=”iso29481p2a:SimpleEleme
ntTypeRef”/ >
C
</xsd:choice>
R
</xsd:complexType>
PA
</xsd:element>
</xsd:sequence>
O
</xsd:extension>
L
</xsd:complexType>
TA
<xsd:complexType name=”ElementConditionType” >
TO
<xsd:sequence>
N
<xsd:element name=”condition” type = ”xsd:string”/ >

IO
<xsd:element name=”helpInfo” type = ”xsd:string” minOc-

C
curs = ”0”/ >

<xsd:element name=”complexElement” minOccurs = ”0” >
C
<xsd:complexType>
U
<xsd:choice>
D
<xsd:element ref=”iso29481p2a:ComplexElem
O
entType”/ >
R
EP
entTypeRef”/ >
</xsd:choice>
R
</xsd:complexType>
</xsd:element>
SU
<xsd:element name=”messageInTransaction” minOccurs = ”0” >

<xsd:complexType>
A
<xsd:choice>
D
ntType”/ >
I
IB
ntTypeRef”/ >
H
O
</xsd:choice>
</xsd:complexType>
PR
</xsd:element>
<xsd:element name=”messageInTransaction” minOccurs = ”0” >
<xsd:complexType>
<xsd:choice>
<xsd:element ref=”iso29481p2a:MessageInTr
ansactionType”/ >
ansactionTypeRef”/ >
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
PERUANA 33 de 128
</xsd:complexType>
<xsd:complexType name=”GroupTypeType” >
<xsd:sequence>
L
IA
C
R
PA
<xsd:element name=”language” type = ”xsd:string” minOc-
curs = ”0”/ >
<xsd:element name=”category” type = ”xsd:string” minOc-
O
curs = ”0”/ >
L
TA
curs = ”0”/ >
</xsd:sequence>
</xsd:extension>
TO
N
</xsd:complexType>
<xsd:complexType name=”MessageInTransactionTypeType” >
IO
C

C
<xsd:sequence>
<xsd:element name=”requiredNotify” type = ”xsd:integer”/ >
U

D

O
<xsd:element name=”received” type = ”xsd:boolean”/ >

R
<xsd:element name=”send” type = ”xsd:boolean”/ >

EP

<xsd:element name=”initiatorToExecutor” type = ”xsd:boolean”
R
minOccurs = ”0”/ >

<xsd:element name=”openSecondaryTransactionsAllowed”
SU
type = ”xsd:boolean” minOccurs = ”0”/ >

<xsd:element name=”firstMessage” type = ”xsd:boolean”
A

<xsd:element name=”message” >
I D
<xsd:complexType>
IB
<xsd:choice>
H
<xCsOdP:IetloeCmNeBnt
ref=”iso29481p2a:MessageType”/ >
O
<xsd:element ref=”iso29481p2a:MessageType
PR
Ref”/ >
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name=”previous” minOccurs = ”0” >
<xsd:complexType>
ansactionType”/ >
ansactionTypeRef”/ >
</xsd:choice>
</xsd:complexType>
</xsd:element>
PERUANA 34 de 128
<xsd:element name=”transaction” >

<xsd:complexType>
<xsd:choice>
<xsd:element ref=”iso29481p2a:Transaction
Type”/ >
TypeRef”/ >
L
</xsd:choice>
IA
</xsd:complexType>
</xsd:element>
C
<xsd:element name=”transactionPhase” minOccurs = ”0” >
R
<xsd:complexType>
PA
<xsd:choice>
PhaseType”/ >
O
L
PhaseTypeRef”/ >
TA
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name=”group” >
TO
N
<xsd:complexType>
<xsd:choice>
IO
<xsd:element
C
ref=”iso29481p2a:GroupType”/ >
<xsd:element ref=”iso29481p2a:GroupTypeRe
C
f”/ >
U
</xsd:choice>
D
</xsd:complexType>
O
</xsd:element>
R
<xsd:element name=”appendixTypes” minOccurs = ”0” >

EP
<xsd:complexType>
R
<xsd:element ref=”iso29481p2a:AppendixTyp
eRef”/ >
SU
</xsd:choice>
</xsd:complexType>
A
</xsd:element>
D
</xsd:sequence>
I
</xsd:extension>
IB
H
</xsd:complexType>
<xsd:complexType name=”MessageTypeType” >
O
PR

<xsd:sequence>
curs = ”0”/ >
curs = ”0”/ >
curs = ”0”/ >
PERUANA 35 de 128

<xsd:complexType>
<xsL :choice maxOccurs=”unbounded” >
entType”/ >
entTypeRef”/ >
L
IA
</xsd:choice>
</xsd:complexType>
C
</xsd:element>
R
PA
<xsd:complexType>
O
e”/ >
L
TA
eRef”/ >
</xsd:choice>
TO
</xsd:complexType>
</xsd:element>
N
</xsd:sequence>
</xsd:extension>
IO
C
</xsd:complexType>
<xsd:complexType name=”OrganisationTypeType” >
C
U

D
<xsd:sequence>
O

R

EP

R

SU

curs = ”0”/ >
A

curs = ”0”/ >
D

I
IB
curs = ”0”/ >

H

O
<xsd:complexType>
PR

entType”/ >
entTypeRef”/ >
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name=”PersonTypeType” >
PERUANA 36 de 128

<xsd:sequence>
L
IA
curs = ”0”/ >
C
R
curs = ”0”/ >
PA
curs = ”0”/ >
O
L
<xsd:complexType>
TA
entType”/ > TO
entTypeRef”/ >
N
</xsd:choice>
IO
</xsd:complexType>
C
</xsd:element>
C
</xsd:sequence>
</xsd:extension>
U
D
</xsd:complexType>
O
<xsd:complexType name=”ProjectTypeType” >

R
EP

<xsd:sequence>
R
<xsd:element name=”namespace” type = ”xsd:string”/ >

SU

A

D

I
IB

curs = ”0”/ >
H

O
curs = ”0”/ >

PR

curs = ”0”/ >
<xsd:complexType>
entType”/ >
entTypeRef”/ >
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
PERUANA 37 de 128
</xsd:extension>
</xsd:complexType>
<xsd:complexType name=”RoleTypeType” >
<xsd:sequence>
L
IA
C
R
PA
curs = ”0”/ >
O
L
curs = ”0”/ >
TA
curs = ”0”/ >
TO
<xsd:element name=”responsibilityScope” type = ”xsd:string”
N
<xsd:element name=”responsibilityTask” type = ”xsd:string”

IO

C
<xsd:element name=”responsibilitySupportTask”
type = ”xsd:string” minOccurs = ”0”/ >
C
<xsd:element name=”responsibilityFeedback” type = ”xsd:string”

U

D
</xsd:sequence>
O
</xsd:extension>
R
EP
</xsd:complexType>
<xsd:complexType name=”SimpleElementTypeType” >
R
SU
<xsd:sequence>
A
<xsd:element name=”interfaceType” type = ”xsd:string”/ >

D

I
IB

H
curs = ”0”/ >

O

PR
curs = ”0”/ >

curs = ”0”/ >
<xsd:element name=”valueList” type= ”xsd:string” minOc-
curs = ”0”/ >
<xsd:element name=”userDefinedType” >
<xsd:complexType>
<xsd:choice>
<xsd:element ref=”iso29481p2a:UserDefinedT
ype”/ >
<xsd:element ref=”iso29481p2a:UserDefinedT
ypeRef”/ >
</xsd:choice>
</xsd:complexType>
PERUANA 38 de 128
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name=”TransactionPhaseTypeType” >
L
IA
<xsd:sequence>
C
R
PA
O
L
curs = ”0”/ >
TA
curs = ”0”/ >
curs = ”0”/ >

TO

N
</xsd:sequence>
IO
</xsd:extension>
C
C
</xsd:complexType>
<xsd:complexType name=”TransactionTypeType” >
U
D

O
<xsd:sequence>
R

EP

R

SU

A
curs = ”0”/ >

D
curs = ”0”/ >

I
IB

curs = ”0”/ >
H

O
<xsd:element name=”result” type = ”xsd:string” minOc-

PR
curs = ”0”/ >

<xsd:element name=”subTransactions” minOccurs = ”0” >
<xsd:complexType>
Type”/ >
TypeRef”/ >
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name=”initiator” >
<xsd:complexType>
<xsd:choice>
PERUANA 39 de 128
<xsd:element
ref=”iso29481p2a:RoleType”/ >
<xsd:element ref=”iso29481p2a:RoleTypeRef
”/ >
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name=”executor” >
L
IA
<xsd:complexType>
<xsd:choice>
C
<xsd:element
R
ref=”iso29481p2a:RoleType”/ >
PA
<xsd:element ref=”iso29481p2a:RoleTypeRef
”/ >
O
</xsd:choice>
</xsd:complexType>
L
</xsd:element>
TA
<xsd:complexType>
TO
e”/ >
N
IO
eRef”/ >
C
</xsd:choice>
C
</xsd:complexType>
</xsd:element>
U
</xsd:sequence>
D
</xsd:extension>
O
R
</xsd:complexType>
EP
<xsd:complexType name=”UserDefinedTypeType” >

R

<xsd:sequence>
SU

A

D
<xsd:element name=”baseType” type = ”xsd:string”/ >

I
IB
<xsd:element name=”xsdRestriction” type = ”xsd:string”

H

O
curs = ”0”/ >

PR

curs = ”0”/ >
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<!– complex types for element reference declarations (for ENTITY definitions) →
<xsd:complexType name=”AppendixTypeTypeRef” >
<xsd:extension base=”iso29481p2a:elementTypeRef”/ >
</xsd:complexType>
<xsd:complexType name=”ComplexElementTypeTypeRef” >
PERUANA 40 de 128

</xsd:complexType>
<xsd:complexType name=”ElementConditionTypeRef” >
L
</xsd:complexType>
IA
<xsd:complexType name=”GroupTypeTypeRef” >
C
R
PA
</xsd:complexType>
<xsd:complexType name=”MessageInTransactionTypeTypeRef” >
O
L
TA
</xsd:complexType>
<xsd:complexType name=”MessageTypeTypeRef” >
<xsd:complexContent> TO
N
</xsd:complexType>
IO
<xsd:complexType name=”OrganisationTypeTypeRef” >

C
C
U
</xsd:complexType>
D
<xsd:complexType name=”PersonTypeTypeRef” >

O
R

EP
</xsd:complexType>
R
<xsd:complexType name=”ProjectTypeTypeRef” >

SU

A
</xsd:complexType>
<xsd:complexType name=”RoleTypeTypeRef” >
I D
IB

H
O
</xsd:complexType>
<xsd:complexType name=”SimpleElementTypeTypeRef” >
PR
</xsd:complexType>
<xsd:complexType name=”TransactionPhaseTypeTypeRef” >
</xsd:complexType>
<xsd:complexType name=”TransactionTypeTypeRef” >
</xsd:complexType>
PERUANA 41 de 128
<xsd:complexType name=”UserDefinedTypeTypeRef” >

</xsd:complexType>
<!– group declarations (for SELECT data type definitions) →
<!– enumeration type declarations (for ENUMERATION data type definitions) →
<!– simple type declarations (for TYPE defined data type definitions) →
L
IA
<!– standard declarations, elementType, simpleType, logical (for each translation) →
<xsd:complexType name=”elementType” >
C
<xsd:attribute name=”id” type = ”xsd:ID” use = ”required”/ >
R
</xsd:complexType>
PA
<xsd:complexType name=”elementTypeRef” >
<xsd:attribute name=”idref” type = ”xsd:IDREF” use = ”required”/ >
O
</xsd:complexType>
<xsd:simpleType name=”logical” >
L
<xsd:restriction base=”xsd:string” >
TA
<xsd:enumeration value=”true”/ >
<xsd:enumeration value=”false”/ >
<xsd:enumeration value=”unknown”/ >
</xsd:restriction>
TO
N
</xsd:simpleType>
</xsd:schema>
IO
C
C
U
A.4 Tiposdeelementos
D
O
R
EP
A.4.1 AppendixType
R
SU
Atributos: id 
A
I D
IB
Elementos: description, startDate, endDate, state, dateLaMu, userLaMu, language,

H
category, helpInfo, code 

O
PR
Referencias: complexElements
Un AppendixType contiene la definición de un archivo adjunto. Los elementos de datos que

se debería registrar con un archivo adjunto se pueden especificar en la sección de elementos
complejos.

PERUANA 42 de 128
EJEMPLO
<AppendixType id=”StandardAppendixType” >

<description>Standard appendix type</description>
<startDate>2007-01-23T00:00:00Z</startDate>
<endDate>2007-12-31T00:00:00Z</endDate>
L
IA
<state>active</state>
C
<dateLaMu>2007-01-23T00:00:00Z</dateLaMu>
R
<userLaMu>bapa</userLaMu>
PA
</AppendixType>
O
NOTA: Referencia appendixType. Si un marco de interacción especifica muchos tipos de archivos
L
adjuntos, puede ser difícil para los usuarios seleccionar el tipo de archivo adjunto apropiado en
TA
determinadas situaciones. Esta referencia filtra el conjunto de todos los tipos de archivos adjuntos a los
que son válidos para esta transacción o mensaje.
TO
N
A.4.2 ComplexElementType
IO
C
C
Atributos: id
U
D
O
R

EP
category, helpInfo
R
SU
Referencias: elements
A
I D
Un tipo de elemento complejo contiene un conjunto de SimpleElementTypes. Cada uno de

IB
los elementos declarados de ElementType se da exactamente el número de veces que se

H
menciona.
O
PR
EJEMPLO
<ComplexElementType id=”MenuItem” >

<description>Item on menu</description>
<elements>
PERUANA 43 de 128
<SimpleElementTypeRef idref=”Name”/ >

<SimpleElementTypeRef idref=”Price”/ >
<SimpleElementTypeRef idref=”Description”/ >
<SimpleElementTypeRef idref=”Calories”/ >
</elements>
</ComplexElementType>
L
IA
C
R
A.4.3 ElementCondition 
PA
O
Atributos: id 
L
TA
TO
Elementos: description, requiredNotify, minValue, maxValue, format, helpInfo
N
IO
Referencias: message, element

C
C
U
D
La condición de un SimpleElementType se usa dentro de un MessageType específico.

O
R
EJEMPLO
EP
R
<ElementCondition id=”Price restriction” >

SU
<description>Minimal price of a menu item</description>

<requiredNotify>0</requiredNotify>
A
<minValue>5.00</minValue>
D
<element>
I
IB
<SimpleElementType>Price</SimpleElementType>
H
</element>
O
<message>
PR
<MessageTypeRef idref=”ProvideWithMenuMessage”/ >

</message>
</ElementCondition>

PERUANA 44 de 128
A.4.4 GroupType
Atributos: id
L
IA
C
category, helpInfo
R
PA
La definición de un grupo para enviar archivos adjuntos enviados en un mensaje en el seno
O
de una transacción.
L
TA
EJEMPLO
TO
<GroupType id=”StandardGroupType” >
N
<description>Standard group</description>
IO
C
C
U
D
O
</GroupType>
R
EP
R
A.4.5 MessageType
SU
A
Atributos: id
ID
IB
H

O
category, helpInfo, code

PR
Referencias: complexElements, appendixTypes 
La definición de un tipo de mensaje (MessageType), la cual especifica la estructura del

mensaje y en el cual el conjunto de SimpleElementType (a través de ComplexElementType)
puede incorporar.

PERUANA 45 de 128
EJEMPLO
<MessageType id=”ProvideWithMenuMessage” >

<description>Message that contains the menu.</description>
L
IA
C
R
PA
<complexElements>
<ComplexElementTypeRef idref=”Menu”/ >
O
</complexElements>
L
<appendixTypes>
TA
<AppendixTypeRef idref=”Menucard” / >
</appendixTypes> TO
</MessageType>
N
IO
NOTA Elemento firstmessage. En general, una transacción será iniciada por el rol iniciador
C
satisfaciendo a la persona con un tipo de mensaje que es independiente de cualquier tipo de mensaje
C
anterior. Sin embargo, este principio no puede aplicarse a una transacción que actúa como sub-
U
transacción de otra transacción. Este elemento indica explícitamente si se puede utilizar un tipo de
D
mensaje para iniciar una nueva transacción.

O
R
EP
A.4.6 MessageInTransactionType
R
SU
Atributos: id
A
D
Elementos: requiredNotify, dateLaMu, userLaMu, received, send, state,

I
IB
initiatorToExecutor, openSecondaryTransactionsAllowed, firstMessage

H
O
Referencias: message, previous, transaction, transactionPhase, group, appendixTypes.

PR
La participación de un MessageType dentro de un TransactionType relacionado con un

cierto tipo de grupo (GroupType).
EJEMPLO
<MessageInTransactionType id=”MiTT_002” >

PERUANA 46 de 128
<received>true</received>
<send>true</send>
<initiatorToExecutor>false</initiatorToExecutor>
<openSecondaryTransactionsAllowed>true</openSecondaryTransactionsAllowed>
L
IA
<firstMessage>false</firstMessage>
C
<message>
R
<MessageTypeRef idref=”ProvideWithMenuMessage”/ >
PA
</message>
<previous>
O
<MessageInTransactionTypeRef idref=”MiTT_001”/ >
L
</previous>
TA
<transaction>
TO
<TransactionTypeRef idref=”ObtainMenuTransaction”/ >
</transaction>
N
<transactionPhase>
IO
<TransactionPhaseTypeRef idref=”MenuDelivered” >

C
</transactionPhase>
C
<group>
U
<GroupTypeRef idref=”StandardGroupType”/ >

D
</group>
O
<appendixTypes>
R
<AppendixTypeRef idref=”Menucard” / >

EP
</appendixTypes>
R
</MessageInTransactionType>
SU
A
A.4.7 OrganisationType
ID
IB
H
Atributos: id
O
PR

La definición de un grupo específico de organizaciones. Generalmente, sólo un ejemplar

estará presente en un marco de interacción que defina la estructura de los elementos que
debería exponer cada ejemplar de organización.
PERUANA 47 de 128
EJEMPLO
<OrganisationType id=”StandardOrganisationType” >

<description>Standard organisation type</description>
L
IA
C
R
PA
</OrganisationType>
O
L
A.4.8 PersonType
TA
TO
Atributos: id
N
IO
C

C

U
D
O
R
EP
R
La definición de un grupo específico de personas. Generalmente, sólo un ejemplar estará

SU
presente en un marco de interacción que defina la estructura de los elementos que debería
exponer cada ejemplar de persona.
A
ID
IB
EJEMPLO
H
O
PR
<PersonType id=”StandardPersonType” >

<description>Standard person type</description>
</PersonType>

PERUANA 48 de 128
A.4.9 ProjectType
Atributos: id
Elementos: namespace, description, startDate, endDate, state, dateLaMu, userLaMu,
L
IA
language, category, helpInfo, code.
C
R
PA
O
L
La definición de un grupo específico de proyectos. En general, sólo un ejemplar estará
TA
presente en un marco de interacción que defina la estructura de los elementos que debería
exponer cada ejemplar de proyecto. TO
N
EJEMPLO
IO
C
<ProjectType id=”StandardProjectType” >

C
<namespace>http://www.ISO 29481_Part_2A.com/testproject</namespace>
U
<description>Standard project type</description>

D
O
R
EP
R
SU
</ProjectType>
A
D
A.4.10 RoleType
I
IB
H
O
Atributos: id
PR

category, helpInfo, code, responsibilityFeedback, responsibilityScope,
responsibilitySupportTask, responsibilityTask
La definición de un tipo específico de rol.

PERUANA 49 de 128
EJEMPLO
<RoleType id=”waiter” >

<description>Responsible for taking and posting of orders</description>
<startDate>2008-05-04T00:00:00:00Z</startDate>
<endDate>2008-05-04T00:00:00.00Z</endDate>
L
IA
C
<dateLaMu>2008-05-04T00:00:00.00Z</dateLaMu>
R
<userLaMu>MMA</userLaMu>
PA
<language/>
<category/>
O
<helpInfo/>
L
<code/>
TA
<responsibilityScope/>
<responsibilityTask/> TO
<responsibilitySupportTask/>
N
<responsibilityFeedback/>
IO
</RoleType>
C
C
U
A.4.11 SimpleElementType
D
O
R
EP
Atributos: id
R
SU
Elementos: description, interfaceType, state, dateLaMu, userLaMu, language, category,

helpInfo, valueList
A
D
I
IB
Referencias: composedOf, userDefinedType

H
O
PR
La definición de un tipo de elemento simple (SimpleElementType). Este tipo de elemento

especifica una propiedad que puede darse dentro de varias estructuras de objetos, por
ejemplo, en MessageType (véase también AppendixType, ProjectType, PersonType y
OrganizationType). Un SimpleElementType siempre está incrustado en un
ComplexElementType.

PERUANA 50 de 128
EJEMPLO
<SimpleElementType id=”Name” >

<description>Name of the menu item</description>
<interfaceType/>
L
IA
C
R
<userDefinedType>
PA
<UserDefinedTypeRef idref=”String”/ >
</userDefinedType>
O
</SimpleElementType>
L
TA
A.4.12 TransactionPhaseType TO
N
IO
Atributos: id
C
C
U

D

O
R
EP
La definición de una fase relacionada con una transacción. Algunos ejemplos pueden ser
R
"asignación aceptada" o "parte de resultado recibido".

SU
EJEMPLO
A
D
<TransactionPhaseType id=”WaitingForMenu” >

I
IB
<description>Menu requested but not yet delivered</description>

H
O
PR
</TransactionPhaseType>

PERUANA 51 de 128
A.4.13 TransactionType
Atributos: id
L
IA
category, helpInfo, code, result
C
R
PA
Referencias: initiator, executor, subTransactions
O
L
La definición de un tipo de transacción. Un tipo de transacción puede hacer referencia de
TA
nuevo a otros tipos de transacción. Una transacción será iniciada por una persona
TO
perteneciente a una organización que desempeñe un determinado papel. En este punto se
debería declarar el tipo de rol del iniciador (el esquema refuerza este concepto). Lo mismo
N
ocurre con el ejecutor.
IO
C
EJEMPLO
C
U
<TransactionType id=”MenuObtainingTransaction” >

D
<description>The transaction to obtain the proper menu</description>

O
R
EP
R
SU
<initiator>
A
<RoleTypeRef idref=”Customer”/ >

D
</initiator>
I
IB
<executor>
H
<RoleTypeRef idref=”Employee”/ >

O
</executor>
PR
</TransactionType>
A.4.14 UsedDefinedType
Atributos: #id
Elementos: description, state, dateLaMu, userLaMu, baseType, xsdRestriction, language,

helpInfo
PERUANA 52 de 128
Una especificación de un tipo de datos (que se utilizará en un SimpleElementType). Este

tipo de datos encapsula áreas de relleno en el mensaje final.
EJEMPLO
<UserDefinedType id=”String” >
L
IA
<description>Standard string</description>
C
R
PA
<baseType>STRING</baseType>
O
<xsdRestriction/>
L
</UserDefinedType>
TA
TO
A.5 Attributes
N
IO
A.5.1 id
C
C
U
Nombre "corto" único del evento. Después de la promoción, este nombre será un nombre de
D
objeto.
O
R
EJEMPLO
EP
R
Framework object
<OrganisationType id=”TNO Building and Construction” >
SU
<description>The attributes of an organisation</description>

A
D
I
IB
H
O
<userLaMu>testmanagement</userLaMu>
PR
<language>NL</language>
<category>S</category>
<helpInfo>http://.../</helpInfo>
<code>DEFAULT</code>
</OrganisationType>
Message object
<name>TNO Building & Construction</name>
<userLaMu>Peter Bonsma</userLaMu>
</Organisation>
PERUANA 53 de 128
A.6 Elements
A.6.1 baseType
L
IA
Guarda el tipo de base de un SimpleElementType.
C
R
EJEMPLO
PA
<SimpleElementType id=”Height” >
O
...
L
<userDefinedType>
TA
<UserDefinedType id=”...” >
... TO
<baseType>INTEGER</baseType>
N
...
IO
</UserDefinedType>
C
</userDefinedType>
C
U
D
O
Aquí, el SimpleElementType Height siempre es un número entero (posiblemente con una

R
EP
restricción: xsdRestriction).
R
SU
A.6.2 category
A
D
Categoría asociada con este objeto (valor opcional).

I
IB
H
O
A.6.3 code
PR
Código de marco de interacción acordado para este objeto.
EJEMPLO
<... id=”...” >

...
EAN 33156
... </...>
PERUANA 54 de 128
A.6.4 dateLaMu
Día y hora de la última mutación de este objeto.
L
IA
<... id=”...” >
C
R
...
PA
...
O
L
</...>
TA
TO
A.6.5 description
N
IO
C
Descripción del objeto.

C
U
EJEMPLO
D
O
<... id=”Doorleaf” >

R
EP
...
<description>The leaf of a flat door.</description>
R
...
SU
</...>
A
D
A.6.6 endDate
I
IB
H
O
Día y hora final de validación de este objeto.

PR
EJEMPLO
<... id=”...” >

...
...
</...>

PERUANA 55 de 128
A.6.7 firstMessage
Valor booleano opcional para indicar que este objeto MessageInTransactionType se puede
utilizar como un mensaje de inicio para una nueva transacción. El valor predeterminado es
falso.
L
IA
C
EJEMPLO
R
PA
<MessageInTransactionType id=”...” >
...
O
<firstMessage>true</firstMessage>
L
...
TA
TO
N
A.6.8 format
IO
C
C
La disposición de un elemento (opcional).

U
D
O
A.6.9 helpInfo
R
EP
R
Vínculo URL/URI para mayor información sobre este objeto.

SU
EJEMPLO
A
D
<... id=”...” >

I
IB
...
H
<helpInfo> http://www.ISO 29481_Part_2A.com/helpInfo_object0001.html</helpInfo>

O
...
PR
</...>
A.6.10 initiatorToExecutor
Valor booleano que representa la dirección a la que se supone que se va a enviar el mensaje.

PERUANA 56 de 128
EJEMPLO

...
...
L
IA
<message>
<MessageType id=”TenderAcceptance” >
C
R
...
PA
</MessageType>
</message>
O
<transaction>
L
<TransactionType id=”TenderTraject” >
TA
...
<initiator> TO
<RoleType id=”Performer” >
N
...
IO
</RoleType>
C
</initiator>
C
<executor>
U
<RoleType id=”Client” >

D
...
O
</RoleType>
R
EP
</executor>
...
R
</TransactionType>
SU
</transaction>
...
A

D
I
IB
Se prevé que el mensaje TenderAcceptance se enviará desde el cliente (ejecutor) al actor

H
(iniciador).
O
PR
A.6.11 interfaceType
Tipo interfaz o vista en este SimpleElementType para un mensaje específico.
A.6.12 language

PERUANA 57 de 128
Lenguaje a usar tras la promoción de este objeto.
EJEMPLO
<... id=”...” >

...
L
IA
C
...
R
</...>
PA
O
A.6.13 namespace
L
TA
TO
Nombre de destino del espacio de nombres para identificar los mensajes que pertenecen a
este marco de interacción.
N
IO
EJEMPLO
C
C
<ProjectType id=”...” >

U
<namespace>http://www.visi.nl/testraamwerk</namespace>
D
...
O
</ProjectType>
R
EP
NOTA. Espacio de nombres de elemento. Anteriormente, todos los esquemas de la estructura de

R
interacción se referían al mismo espacio de nombres de destino, que pasó a ser el mismo que el espacio
SU
de nombres del propio esquema de interacción. Utilizando este elemento, cada esquema de interacción
puede especificar su propio espacio de nombres.
A
ID
A.6.14 openSecondaryTransactionsAllowed
IB
H
O
Valor booleano opcional que permite la continuación de la transacción primaria incluso si

PR
no se completan todas las transacciones secundarias. Un valor "TRUE" se interpreta como

una luz verde para la continuación (puerta OR). Un valor "FALSE" se interpreta como una
luz roja para continuar hasta que se completan todas las transacciones secundarias (puerta
AND). Si no se especifica openSecondaryTransactionsAllowed, la interpretación equivale a
"TRUE".

PERUANA 58 de 128
A.6.15 received
Valor booleano que indica que el mensaje anterior se ha recibido.
L
IA
A.6.16 requiredNotify
C
R
PA
No se ha asociado ningún significado a este elemento.
O
L
A.6.17 responsibilityFeedback
TA
TO
Respuesta esperada en la dirección de otros roles (cadena opcional).
N
IO
C
A.6.18 responsibilityScope
C
U
D
Alcance/marco de las responsabilidades definidas del rol (cadena opcional).

O
R
EP
A.6.19 responsibilitySupportTask
R
SU
Tareas para ser ejecutadas con el objeto de apoyar otros roles. Por ejemplo, la delegación de
A
responsabilidades (cadena opcional).

D
I
IB
H
A.6.20 responsibilityTask
O
PR
Tareas originadas por las responsabilidades de este rol (cadena opcional).
A.6.21 result
Resultado esperado por la ejecución de la transacción.

PERUANA 59 de 128
A.6.22 send
Valor booleano que indica si el mensaje ha sido enviado o no.
L
IA
A.6.23 startDate
C
R
PA
Fecha y hora de inicio de la validación de este objeto.
O
EJEMPLO
L
TA
<... id=”...” >
... TO
N
... </...>
IO
C
C
A.6.24 state
U
D
O
Estado de visibilidad de este objeto, valores posibles:

R
EP
EJEMPLO
R
SU
<... id=”...” >

...
A
D
...
I
IB
</...>
H
O
y
PR
<... id=”...” >

...
<state>passive</state>
...
</...>

PERUANA 60 de 128
A.6.25 userLamu
Usuario de la última mutación de este objeto.
EJEMPLO
L
IA
<... id=”...” >
C
R
...
PA
...
O
</...>
L
TA
A.6.26 valueList TO
N
IO
Lista de valores separados por punto y coma que puede tomar un evento a nivel de mensaje.
C
Origi- nalmente, este elemento se destinaba a apoyar enumeraciones. Actualmente, esto se

C
implementa con el tipo de elemento UserDefinedType y el elemento xsdRestriction. En

U
xsdRestriction, se especifican los valores de enumeración. No se vincula ningún significado

D
a este elemento.
O
R
EP
EJEMPLO
R
<SimpleElementType id=”...” >

SU
...
<valueList>Groen;Rood;Oker Geel</valueList>
A
...
D
I
IB
H
O
A.6.27 xsdRestriction
PR
Este elemento especifica una restricción que se realizará a nivel de mensaje en el

SimpleElementType de este UserDefinedType.

PERUANA 61 de 128
A.7 References
A.7.1 appendixTypes
L
IA
Conjunto de tipos de archivos adjuntos seleccionables.
C
R
PA
A.7.2 complexElements
O
L
Referencia a un conjunto de SimpleElementType (recogido en un ComplexElementType).
TA
EJEMPLO TO
N
<... id=”Abc” >
IO
...
C
<complexElements>
C
<ComplexElementType id=”ElementsSet1” >

U
...
D
<elements>
O
<SimpleElementType id=”Element_A” >

R
EP
...
R
<SimpleElementType id=”Element_B” >

SU
...
A
</elements>
D
I
IB

H
...
O
PR

...
</complexElements>
</...>
A nivel de mensaje, esto se elabora en:
<Abc id=”...” >

...
PERUANA 62 de 128
<elementsSet1>
<ElementsSet1>
<Element_A>...</Element_A>
<Element_B>...</Element_B>
</ElementsSet1>
...
L
IA
<ElementsSet1>
C
<Element_A>...</Element_A>
R
<Element_B>...</Element_B>
PA
</ElementsSet1>
</elementsSet1>
O
<elementsSet2>
L
<ElementsSet2>
TA
...
</ElementsSet2> TO
...
N
<ElementsSet2>
IO
...
C
</ElementsSet2>
C
</elementsSet2>
U
<elementsSet3>
D
<ElementsSet3>
O
...
R
EP
</ElementsSet3>
...
R
<ElementsSet3>
SU
...
</ElementsSet3>
A
</elementsSet3>
D
</...>
I
IB
H
O
A.7.3 composedOf
PR
Un SimpleElementType puede consistir en un conjunto de SimpleElementType (recogido

en un ComplexElementType).
EJEMPLO
<SimpleElementType id=”Doorleaf” >

...
<composedOf>
PERUANA 63 de 128
<ComplexElementType id=”Measurement” >

...
<elements>
...
L
IA
<SimpleElementType id=”Width” >
C
...
R
PA
<SimpleElementType id=”Thickness” >
...
O
L
</elements>
TA
<ComplexElementType id=”Material-selection” > TO
...
N
<elements>
IO
<SimpleElementType id=”Type-of-wood” >

C
...
C
U
</elements>
D
O
</composedOf>
R
EP
R

SU
<Doorleaf>
A
...
D
<Measurement id=”...” >

I
IB
<Height>...</Height>
H
<Width>...</Width>
O
<Thickness>...</Thickness>
PR
</Measurement>
<Material-selection id=”...” >
<Type-of-wood>...</Type-of-wood>
</Material-selection>
</Doorleaf>

PERUANA 64 de 128
A.7.4 element
La condición en un SimpleElementType que se utilizará en de un MessageType.
EJEMPLO
L
IA
<ElementCondition id=”...” >
C
R
...
PA
<minValue>2000</minValue>
...
O
<element>
L
<SimpleElementTypeRef idref=”Doorheight” >
TA
</element>
<message> TO
<MessageType id=”M” >
N
...
IO
<complexElements>
C
<ComplexElementType>
C
...
U
<elements>
D
<SimpleElementType id=”Doorheight” >

O
...
R
EP
</elements>
R
SU
</complexElements>
</MessageType>
A
</message>
D
</ElementCondition>
I
IB
H
O
Se especifica que dentro de MessageType, el valor de M, que es la altura de la puerta

PR
(Doorheight) debería ser al menos 2000, aunque esto no se aplica a nivel

SimpleElementType.
A.7.5 elements
Conjunto de SimpleElementType disponible dentro de un ComplexElementType.

PERUANA 65 de 128
EJEMPLO
<ComplexElementType id=”Door” >

...
<elements>
L
IA
...
C
</message>
R
PA
<SimpleElementType id=”Fastenings” >
...
O
L
<SimpleElementType id=”UpperWindow” >
TA
...
</SimpleElementType> TO
</elements>
N
</ComplexElementType
IO
C

C
U
<... id=”...” >

D
...
O
<door>
R
EP
<Door>
<Doorleaf>...</Doorleaf>
R
<Fastenings>...</Fastenings>
SU
<UpperWindow>...</UpperWindow>
</Door>
A
...
D
<Door>
I
IB
H
<Fastenings>...</Fastenings>
O
<UpperWindow>...</UpperWindow>
PR
</Door>
</door>
</...>
Es obligatorio es que todos los elementos se expresen con precisión sólo una vez. Estas
puertas siempre tienen una ventana superior. El número de puertas no tiene restricciones.

PERUANA 66 de 128
A.7.6 executor
Es el rol de ejecutor de una tarea (RoleType) asociado con una transacción particular.
L
IA
EJEMPLO
C
R
PA
...
<executor>
O
<RoleType id=”Client” >
L
...
TA
</RoleType>
</executor> TO
...
N
</TransactionType>
IO
C
C
A.7.7 group
U
D
O
El GroupType que está asociado con un mensaje dentro de una transacción particular.
R
EP
EJEMPLO
R
SU

...
A
<message>
D

I
IB
...
H
</MessageType>
O
<message>
PR
<group>
<GroupType id=”G” >
...
</GroupType>
</group>
<transaction>
<TransactionType id=”T” >
...
</TransactionType>
</transaction>
PERUANA 67 de 128
...
El mensaje M dentro de la transacción T pertenece al grupo G (puede haber más mensajes M

dentro de la transacción T que pertenezcan al mismo o a otro grupo).
L
IA
C
A.7.8 iniciador
R
PA
Es el rol de iniciador de una tarea (RoleType) asociado con una transacción particular.
O
L
EJEMPLO
TA
<TransactionType id=”TenderTraject” > TO
...
N
<initiator>
IO
<RoleType id=”Performer” >

C
...
C
</RoleType>
U
</initiator>
D
...
O
</TransactionType>
R
EP
R
A.7.9 message
SU
A
Es el mensaje que hay en un MessageInTransactionType.

ID
IB
EJEMPLO
H
O

PR
...
<message>
<MessageType id=”...” >
...
</MessageType>
</message>
...
</MessageInTransactionType

PERUANA 68 de 128
A.7.10 previous
Un MessageInTransactionType puede reforzar que un mensaje previo dentro de una

transacción particular debería ejecutarse (este MessageInTransactionType anterior no
necesita pertenecer al mismo TransactionType).
L
IA
C
R
EJEMPLO
PA
O
...
L
<previous>
TA
... TO
<message>
N
<MessageType id=”Tender” >
IO
...
C
</MessageType>
C
</message>
U
...
D
O
</previous>
R
EP
...
<message>
R
<MessageType id=”TenderAcceptance” >

SU
...
</MessageType>
A
</message>
D
...
I
IB
</MessageInTransactionType>subTransactions
H
O
Trasacciones que podrían operar en esta transacción.

PR
EJEMPLO
<TransactionType id=”AcquireWork” >

...
<subTransactions>
<TransactionType id=”AcquisitionTrack” >
...
</TransactionType>
<TransactionType id=”TenderTrack” >
PERUANA 69 de 128
...
</TransactionType>
</subTransactions>
</TransactionType>
L
IA
El TransactionType AcquireWork consta de la AcquisitionTrack y de la TenderTraject de la
C
TransactionType.
R
PA
A.7.11 simpleElements
O
L
TA
Conjunto de tipos de elementos simples pertenecientes a este tipo de elementos complejos.
TO
EJEMPLO
N
IO
<ComplexElementType id=”Door” >

C
...
C
<simpleElements>
U

D
...
O
R
<SimpleElementType id=”HingesAndLocks” >

EP
...
R
SU
<SimpleElementType id=”UpperWindow” >

...
A
D
</simpleElements>
I
IB
H
O
PR
A nivel de mensaje, esto puede conducir a:
<... id=”...” >

...
<door>
<Door>
< HingesAndLocks >...</ HingesAndLocks >
< UpperWindow >...</ UpperWindow >
PERUANA 70 de 128
</Door>
...
<Door>
< Doorleaf >...</ Doorleaf >
< HingesAndLocks >...</ HingesAndLocks >
< UpperWindow >...</ UpperWindow >
L
IA
</Door>
C
</door>
R
</...>
PA
O
A.7.12 subTransactions
L
TA
TO
Transacciones que se pueden iniciar desde esta transacción.
N
EJEMPLO
IO
C
<TransactionType id=”AcquisitionOfWork” >

C
...
U
<subTransactions>
D
<TransactionType id=”AcquisitionTraject” >

O
...
R
EP
</TransactionType>
R
...
SU
</TransactionType>
</subTransactions>
A
</TransactionType>
D
I
IB
H
A.7.13 Transaction
O
PR
Una transacción en un MessageInTransactionType.
EJEMPLO

...
<transaction>
<TransactionType id=”...” >
...
PERUANA 71 de 128
</TransactionType>
</transaction>
...
L
IA
A.7.14 transactionPhase
C
R
PA
Una TransactionPhase para un MessageType específico dentro de TransactionType
específico.
O
L
EJEMPLO
TA
<MessageInTransactionType id=”...” > TO
...
N
<message>
IO

C
...
C
</MessageType>
U
</message>
D
<transaction>
O
<TransactionType id=”T” >

R
EP
...
</TransactionType>
R
</transaction>
SU
...
<transactionPhase>
A
<TransactionPhaseType id=”TP” >

D
...
I
IB
H
</transactionPhase>
O
...
PR
Donde un MessageType M dentro de un TransactionPhaseType TP.
A.7.15 userDefinedType
Referencia a un UserDefinedType, especifica la forma del SimpleElementType.

PERUANA 72 de 128
EJEMPLO

...
<userDefinedType>
<UserDefinedType id=”...” >
L
IA
...
C
<baseType>INTEGER</baseType>
R
...
PA
</UserDefinedType>
</userDefinedType>
O
L
TA
TO
El SimpleElementType Height especifica un entero para cada evento (posiblemente con una
restricción como xsdRestriction).
N
IO
C
C
U
D
O
R
EP
R
SU
A
ID
IB
H
O
PR

PERUANA 73 de 128
ANEXO B
(NORMATIVO)
Definición de plantillas
L
IA
C
R
B.1 Introducción
PA
O
Una vez que se dispone de un marco de interacción válido, se necesita un archivo de esquema
L
de inter- acción que incluya reglas para la comunicación real. Las reglas que son
TA
independientes de la comu- nicación real se incluyen en el archivo de plantillas. En este
TO
anexo, se da la definición de plantillas en formato EXPRESS. Además, se describen tipos de
elementos, atributos, elementos y referencias.
N
IO
C
B.2 Definición de plantillas

C
U
D
O
SCHEMA ISO 29481_Part_2B;

R
EP
ENTITY GroupTemplate;
R
name: STRING;
SU
A
D
creationDate: DATETIME;
I
IB
H
O
PR
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME; 
versionNo: STRING; 

PERUANA 74 de 128
transaction: TransactionTemplate;
END_ENTITY; 
ENTITY AppendixGroup; 
L
IA
state: STRING;
C
R
dateLaMu: DATETIME;
PA
O
userLaMu: STRING;
L
TA
group: GroupTemplate;
END_ENTITY; TO
N
ENTITY AppendixTemplate;
IO
C
name: STRING;
C
U
D
fileLocation: STRING;
O
R
fileType: STRING;
EP
R
fileVersion: STRING;
SU
documentIdentification: STRING;
A
D
documentVersion: STRING;
I
IB
documentReference: STRING;
H
O
PR
objectCode: OPTIONAL STRING;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
PERUANA 75 de 128
message: MessageTemplate;
appendixGroup: AppendixGroup;
L
IA
template: ComplexElementTemplate;
C
R
END_ENTITY;
PA
ENTITY MessageTemplate;
O
L
identification: STRING;
TA
dateSend:DATETIME; TO
N
dateRead: DATETIME;
IO
C
state: STRING;
C
U
dateLaMu: DATETIME;
D
O
userLaMu: STRING;
R
EP
initiatingTransactionMessageID: OPTIONAL STRING;

R
SU
initiatorToExecutor: BOOLEAN;
A
messageInTransaction: MessageInTransactionTemplate;
ID
IB
transaction: TransactionTemplate; 
H
O
PR
END_ENTITY;
ENTITY MessageInTransactionTemplate;
identification: STRING;
dateSend: DATETIME;
dateRead: DATETIME;
PERUANA 76 de 128
state: STRING; 
dateLaMu: DATETIME;
userLaMu: STRING;
L
IA
END_ENTITY; 
C
R
ENTITY TransactionTemplate;
PA
O
number: INTEGER; 
L
TA
name: STRING;
TO
N
IO
C
C
endDate: DATETIME;
U
D
state: STRING;
O
R
dateLaMu: DATETIME;
EP
R
userLaMu: STRING;
SU
result: OPTIONAL STRING;

A
D
initiator: PersonInRole;
I
IB
H
executor: PersonInRole;
O
PR
project: ProjectTypeInstance;
END_ENTITY;
ENTITY TransactionPhaseTemplate;
name: STRING;

PERUANA 77 de 128
dateReached: DATETIME; 
state: STRING; 
L
IA
dateLaMu: DATETIME;
C
R
PA
userLaMu: STRING;
O
transaction: TransactionTemplate;
L
TA
END_ENTITY;
ENTITY PersonTemplate;
TO
N
IO
userName: STRING;
C
C
name: STRING;
U
D
state: STRING;
O
R
dateLaMu: DATETIME;
EP
R
userLaMu: STRING;
SU
A
D
END_ENTITY;
I
IB
H
ENTITY OrganisationTemplate;
O
PR
name: STRING;
abbreviation: STRING;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
contactPerson: PersonTemplate;
PERUANA 78 de 128
END_ENTITY;
ENTITY PersonInRole;
L
IA
state: STRING;
C
R
dateLaMu: DATETIME;
PA
userLaMu: STRING;
O
L
successor: OPTIONAL PersonInRole;
TA
substituting: OPTIONAL PersonInRole; TO
N
contactPerson: PersonTemplate;
IO
C
organization: OrganisationTemplate;
C
U
role: RoleTemplate;
D
O
END_ENTITY;
R
EP
ENTITY RoleTemplate;
R
SU
name: STRING;
A
ID
IB
state: STRING;
H
O
dateLaMu: DATETIME;
PR
userLaMu: STRING;
END_ENTITY;
ENTITY ProjectTypeInstance;
name: STRING;
PERUANA 79 de 128
endDate: DATETIME;
L
IA
state: STRING;
C
R
dateLaMu: DATETIME;
PA
userLaMu: STRING;
O
L
TA
END_ENTITY; TO
N
ENTITY ComplexElementTemplate;
IO
C
template: SimpleElementVirtual;
C
U
END_ENTITY;
D
O
END_SCHEMA;
R
EP
R
B.3 Plantillas
SU
A
B.3.1 AppendixGroup
ID
IB
H
Atributos: id
O
PR
Elementos: state, dateLaMu, userLaMu
Referencias: group
La tabla de mapeado para las relaciones n:m entre apéndices y grupos.

PERUANA 80 de 128
EJEMPLO
Ejemplo al nivel de mensaje:
<AppendixGroup id=”AppendixGroup_1” >

L
IA
C
<group>
R
<StandardGroupType id=”...” >
PA
...
O
</StandardGroupType>
</group>
L
</AppendixGroup>
TA
Parte asociada al marco de interacción TO
N
IO
C
C
U
D
O
R
</GroupType>
EP
R
B.3.2 AppendixTemplate
SU
A
D
Atributos: id
I
IB
Elementos: name, fileLocation, fileType, fileVersion, documentIdentification,

H
O
documentVersion, documentReference, objectCode, startDate, endDate, state, dateLaMu,

PR
userLaMu, language
Referencias: appendixGroup, message
Registro de los archivos adjuntos.

PERUANA 81 de 128
EJEMPLO
<Appendix id=”ExampleDocument” >

<name>Voorbeeld</name>
L
IA
<fileLocation>\\srv-bouw\Public\project\docs\msword\</fileLocation>
<fileType>application/msword</fileType>
C
<fileVersion>2007</fileVersion>
R
PA
<documentIdentification>345899</documentIdentification>
<documentVersion>1</documentVersion>
O
<documentReference>FG783990</documentReference>
L
TA
TO
N
<language>EN</language>
IO
<appendixGroup>
<AppendixGroup id=”...” >
C
C
...
U
</AppendixGroup>
D
</appendixGroup>
O
</Appendix>
R
EP
Parte asociada al marco de interacción

R
<description>Standard appendix definition (no user defined data fields)</description>

SU
A
D
I
IB
H
O
</AppendixType>
PR
B.3.3 ComplexElementTemplate
Atributos: id

PERUANA 82 de 128
B.3.4 GroupTemplate
Atributos: id
L
IA
Elementos: name, description, creationDate, startDate, endDate, state, dateLaMu,
C
userLaMu, versionNo
R
PA
Referencias: transaction
O
L
TA
Agrupación de archivos adjuntos de un mensaje para recuperar los documentos asociados.
TO
EJEMPLO
N
IO

C
C
<StandardGroupType id=”MenuBackgrounds” >

U
<name>Menu Pictures</name>
D
<description>A set of background pictures to decorate the menu</description>

O
<creationDate>2008-02-04T00:00:00Z</creationDate>
R
EP
R
<state></state>
SU
<versionNo>1</versionNO>
A
<transaction>
D
<MenuObtainingTransaction id=”...” >

I
IB
...
H
</MenuObtainingTransaction>
O
</transaction>
PR
</StandardGroupType

PERUANA 83 de 128
</GroupType>
L
IA
C
<initiator>
R
<RoleTypeRef idref=”Consumer”/ >
PA
</initiator>
<executor>
O
L
</executor>
TA
</TransactionType>
TO
B.3.5 MessageInTransactionTemplate
N
IO
Atributos: id
C
C
U
D
Elementos: identification, dateSend, dateRead, state, dateLaMu, userLaMu,

O
initiatorToExecutor
R
EP
R
Guarda el MessageInTransactionType real dentro del mensaje para recuperar el estado de

flujo de trabajo de la transacción.
SU
A
D
B.3.6 MessageTemplate
I
IB
H
O
Atributos: id
PR
Elementos: identification, dateSend, dateRead, state, dateLaMu, userLaMu,

initiatingTransaction MessageID, initiatorToExecutor
Referencias: transaction, messageInTransaction, template
Un ejemplar de MessageType. Esta entidad lleva el intercambio de información real entre

Organization Template (organizaciones).
PERUANA 84 de 128
EJEMPLO
<HandOutOfMenuMessage id=”a002” >

<identification>id a002</identification>
L
IA
<dateSend>2008-01-23T00:00:00Z</dateSend>
<dateRead>2008-01-23T00:00:00Z</dateRead>
C
R
PA
O
<initiatingTransactionMessageID>a009</initiatingTransactionMessageID>
L
<messageInTransaction>
TA
<MessageInTransaction12Ref idref=”BiT001”/ >
</messageInTransaction>
<transaction>
TO
N
<MenuObtainingTransaction id=”...” >
IO
...
</MenuObtainingTransaction>
C
C
</transaction>
U
<menu>
D
<Menu id=”...” >

O
...
R
</Menu>
EP
...
<Menu id=”...” >
R
... </Menu>
SU
</menu>
</HandOutOfMenuMessage>
A
D

I
IB
H

O

PR
<initiator>
</initiator>
<executor>
</executor>
</TransactionType>
PERUANA 85 de 128
<MessageType id=”HandOutOfMenuMessage” >

<description>Message that contains the menu.</description>
L
IA
<complexElements>
C
<ComplexElementTypeRef idref=”Menu”/ >
R
</complexElements>
PA
</MessageType>
<ComplexElementType id=”Menu” >
O
<description>Available menu items</description>
L
TA
TO
N
<elements>
IO
<SimpleElementTypeRef idref=”MenuItems”/ >

C
</elements>
C
U
D
O
R
B.3.7 OrganisationTemplate
EP
R
Atributos: id
SU
A
Elementos: name, abbreviation, state, dateLaMu, userLaMu

I D
IB
H
Referencias: contactPerson, template

O
PR
La organización que participa en el proyecto iniciando o ejecutando TransactionTemplate

(transacción).
EJEMPLO
<StandardOrganisationType id=”TNO” >

<name>Netherlands organisation for Applied Scientific Research<name>

PERUANA 86 de 128
<abbreviation>TNO</abbreviation>
<contactPerson>
<StandardPersonType id=”...” >
L
...
IA
</StandardPersonType>
C
</contactPerson>
R
</StandardOrganisationType>
PA
O
L
TA
TO
N
IO
C
</PersonType>
C

U
D

O
R
EP
R
SU
</OrganisationType>
A
D
B.3.8 PersonInRole 
I
IB
H
Atributos: id 
O
PR
Elementos: state, dateLaMu, userLaMu 
Referencias: organization, contactPerson, role, substituting, successor 
Una persona que cumple un papel particular para una organización determinada.

PERUANA 87 de 128
EJEMPLO
<PersonInRole id=”JohnAsCustomer” >

L
IA
C
<contactPerson>
R
<StandardPersonType id=”...” >
PA
...
O
</contactPerson>
L
<organisation>
TA
<StandardOrganisationType id=”...” >
...
</StandardOrganisationType>
TO
N
</organisation>
IO
<role>
<Consumer idref=”...” >
C
C
...
U
</Consumer>
D
</role>
O
</PersonInRole>
R
EP

R

SU

A
D
I
IB
H
O
</PersonType>
PR

</OrganisationType>
<RoleType id=”Consumer” >
<description>Consuming person</description>
PERUANA 88 de 128
</RoleType>
L
IA
B.3.9 PersonTemplate 
C
R
PA
Atributos: id 
O
L
TA
Elementos: userName, name, state, dateLaMu, userLaMu
TO
La persona que participa en el proyecto cumpliendo un determinado papel o como persona
N
de contacto de una organización en particular.

IO
C
C
EJEMPLO
U
D
O

R
EP
<StandardPersonType id=”PBonsma” >

<userName>bapa<userName>
R
<name>Peter Bonsma<name>
SU
A
D
I
IB
H

O
PR

</PersonType>

PERUANA 89 de 128
B.3.10 ProjectTemplate
Atributos: id
L
IA
Elementos: name, description, startDate, endDate, state, dateLaMu, userLaMu
C
R
PA
El proyecto a ser integrado en este marco de trabajo.
O
EJEMPLO
L
TA
<StandardProjectType id=”IDM2” >

TO
N
<name>The project IDM2</name>
IO
<description>Formalising of the IDM2 Systematics</description>

C
C
U
D
O
R
</StandardProjectType>
EP

R
SU
<ProjectType id=”StandardProjectType” >

<description>Standard project type</description>
A
D
I
IB
H
O
PR
</ProjectType>
B.3.11 RoleTemplate
Atributos: id
Elementos: name, description, state, dateLaMu, userLaMu, category

PERUANA 90 de 128
El papel en una organización cumplido por un PersonTemplate (persona).
EJEMPLO
L
IA
<Consumer id=”Customer” >
C
<name>Role as customer</name>
R
<description>The role as customer</description>
PA
dateLaMu>2008-01-23T00:00:00Z</dateLaMu>
O
</Consumer>
L
TA
TO
<RoleType id=”Consumer” >
N
<description> Consuming person</description>
IO
C
C
U
D
O
</RoleType>
R
EP
R
B.3.12 TransactionPhaseTemplate
SU
A
Atributos: id
ID
IB
H
Elementos: name, description, dateReached, state, dateLaMu, userLaMu

O
PR
Referencias: transaction
La fase actual de una transacción.
EJEMPLO
<WaitForMenu id=”tp003” >

PERUANA 91 de 128
<name>...</name>
<description>Transaction Phase ...</description>
<dateReached>2008-02-04T00:00:00Z</dateReached>
<dateLaMu>2008-02-04T00:00:00]]</dateLaMu>
L
</WaitForMenu>
IA
C
R
PA
<TransactionType id=”ObtainMenuTransaction” >
O
L
TA
TO
N
<initiator>
IO

</initiator>
C
<executor>
C

U
D
</executor>
O
</TransactionType>
R
<TransactionPhaseType id=”WaitForMenu” >

EP
<description>Menukaart gevraagd maar nog niet gegeven</description>

R
SU
A
D
I
IB
H
O
B.3.13 TransactionTemplate
PR
Atributos: id
Elementos: number, name, description, startDate, endDate, state, dateLaMu, userLaMu,

result
Referencias: initiator, executor

PERUANA 92 de 128
La transacción que permite que MessageTemplates (mensajes) se intercambien para ejecutar

determinadas tareas.
EJEMPLO
L
IA
<ObtainMenuTransaction id=”TheTransaction” >
C
R
<number>001</number>
PA
<name>...</name>
<description>...</description>
O
L
TA
<userLaMu>bapa</userLaMu> TO
<initiator>
N
<PersonInRole id=”...” >
IO
...
C
</PersonInRole>
C
</initiator>
U
<executor>
D

O
...
R
</PersonInRole>
EP
</executor>
</ObtainMenuTransaction>
R
SU

A
<TransactionType id=”ObtainMenuTransaction” >

ID

IB
H
O
PR
<initiator>
</initiator>
<executor>
</executor>
</TransactionType>

PERUANA 93 de 128
B.4 Atributos
B.4.1 id
Código único para identificar un ejemplar de objeto dentro de un mensaje.
L
IA
C
NOTA: El valor ID debería ser único dentro del documento XML. En consecuencia, un número de serie
R
sencillo ya sería suficiente para satisfacer esta condición. Como resultado, no hay ninguna razón
PA
convincente para limitar los valores de ID a GUIDs (aunque la mayoría de las implementaciones aplican
GUID). Marque que el estándar XML (http://www.w3.org/XML/) requiere que un ID comience con
una letra o '_'.
O
L
TA
B.5 Elementos TO
N
IO
B.5.1 Abbreviation
C
C
Abreviatura del nombre de la organización. Este elemento se utilizará como prefijo del
U
número de transacción para la identificación de la transacción.

D
O
R
NOTA: Abreviatura del elemento. La abreviatura contiene el nombre abreviado de una organización.
EP
Una de sus aplicaciones es marcar las transacciones (en combinación con un número de secuencia)
que fueron iniciadas por esta organización para ser útil para la comunicación informal entre los
R
participantes humanos.
SU
B.5.2 category
A
I D
IB
Categoría para clasificar este ejemplar de objeto

H
O
PR
EJEMPLO
<... id=”...” >

...
<category>...</category>
...
</...>

PERUANA 94 de 128
B.5.3 creationDate
Fecha de creación de un ejemplar de objeto específico en este mensaje.
EJEMPLO
L
IA
C
R
PA
<... id=”...” >
...
O
<creationDate>2007-12-03T00:00:00Z</creationDate>
L
...
TA
</...>
TO
N
B.5.4 dateLaMu
IO
C
C
Fecha de la última mutación 

U
D
O
EJEMPLO
R
EP

R
<... id=”...” >

SU
...
A
...
D
</...>
I
IB
H
O
B.5.5 dateReached
PR
Fecha "dateReached" es un atributo de fecha y hora de "TransactionPhaseTemplate". Es la

fecha y la hora en la que se alcanzó una fase particular.
EJEMPLO
<... id=”...” >

...
PERUANA 95 de 128
<dateReached>2008-02-04T00:00:00Z</dateReached>
...
</...>
B.5.6 dateRead
L
IA
C
R
Fecha de lectura de este mensaje.
PA
O
EJEMPLO
L
TA
<... id=”...” >

TO
...
N
<dateRead>2007-12-03T00:00:00Z</dateRead>
IO
...
C
</...>
C
U
D
O
B.5.7 dateSend
R
EP
Fecha de envío de este mensaje.

R
EJEMPLO
SU

A
D
<... id=”...” >

I
IB
...
H
<dateSend>2007-12-03T00:00:00Z</dateSend>
O
...
PR
</...>
B.5.8 description
Descripción de este ejemplar de objeto.
EJEMPLO

PERUANA 96 de 128
<Projectexecutor id=”TNO” >

...
<description>...</description>
...
</Projectexecutor>
L
IA
B.5.9 documentIdentification
C
R
PA
Número único o referencia de un documento o archivo para identificar el documento.
O
NOTA: Esta parte de la NTP-ISO 29481 ofrece la libertad de distinguir entre versiones de documentos
y versiones de archivos (véase B.5.13).
L
TA
B.5.10 documentReference TO
N
IO
Referencia para identificar un archivo o documento.

C
C
U
B.5.11 documentVersion
D
O
R
EP
Versión de un documento o archivo.

R
SU
B.5.12 endDate
A
ID
Fecha de caducidad de un ejemplar de objeto específico en este mensaje.

IB
H
EJEMPLO
O
PR
<... id=”...” >

...
<endDate>2007-12-03</endDate>
...
</...>

PERUANA 97 de 128
B.5.13 fileLocation
Ubicación del archivo, preferiblemente en una dirección de Internet o una ruta compartida
de servidor.
L
IA
EJEMPLO
C
R
PA
<... id=”...” >
O
...
L
<fileLocation>\\srv-path\Public\project-x\docs\</fileLocation>
TA
...
</...> TO
N
NOTA: Esta parte de la NTP-ISO 29481 ofrece la libertad de distinguir entre versiones de documentos
IO
y versiones de archivos (véase B.5.9).

C
C
U
B.5.14 fileType
D
O
R
Tipo del archivo, preferiblemente de tipo MIME (Multipurpose Internet Mail Extensions).
EP
R
SU
EJEMPLO
A

D
I
<... id=”...” >

IB
H
...
O
<fileType>text/plain</fileType>
PR
...
</...>
B.5.15 fileVersion
Versión del archivo, un número entero creciente o la fecha.

PERUANA 98 de 128
EJEMPLO
<... id=”...” >

...
L
IA
<fileVersion>20071202</fileVersion>
C
...
R
</...>
PA
O
B.5.16 identification
L
TA
Identificación de este mensaje orientada a humanos. TO
N
EJEMPLO
IO
C

C
U
<AssignmentConfirmation id=”X” >

D
<identification>This message contains the assignment X related to part Y</identification>

O
...
R
</AssignmentConfirmation>
EP
R
B.5.17 initiatingTransactionMessageID
SU
A
D
Referencia al mensaje perteneciente a una transacción secundaria que inició este mensaje.
I
IB
H
O
B.5.18 iniciatorToExecutor
PR
La dirección de comunicación de este mensaje específico.
EJEMPLO
<ExampleMessage id=”...” >

...
PERUANA 99 de 128
...
<transaction>
<ExampleTransaction id=”...” >
...
<initiator>
L
<PersonInRole id=”A” >
IA
...
C
</PersonInRole>
R
</initiator>
PA
<executor>
<PersonInRole id=”B” >
O
...
L
</PersonInRole>
TA
</executor>
</ExampleTransaction>
</transaction>
TO
...
N
</ExampleMessage>
IO
C
En este ejemplo, ExampleMessage viajará desde B (ejecutor) a A (iniciador). B.5.19

C
language
U
D
O
R
B.5.19 language
EP
R
El lenguaje del contenido del archivo adjunto.

SU
EJEMPLO
A
ID

IB
H
<... id=”...” >

O
...
PR
<language>EN</language>
...
</...>
B.5.20 name
El nombre (STRING).

PERUANA 100 de 128
B.5.21 number
Número de transacción. 
L
NOTA: Número de elemento. El número de secuencia de una transacción (véase también el elemento
IA
anterior).
C
R
PA
B.5.22 objectCode
O
Posibilidad de relacionarse con un índice externo. Por ejemplo, una estructura de desglose
L
de trabajo, paquetes de trabajo o las especificaciones del edificio.
TA
B.5.23 result
TO
N
IO
C
Resultado de esta transacción.

C
U
D
B.5.24 startDate
O
R
EP
Fecha de comienzo de un ejemplar de objeto en este mensaje.

R
SU
EJEMPLO
A
D

I
IB
H
<... id=”...” >

O
...
PR
<startDate>2007-12-03</startDate>
...
</...>
B.5.25 state
Estado actual de este ejemplar de objeto.

PERUANA 101 de 128
EJEMPLO
<... id=”...” >

...
L
IA
...
C
</...>
R
PA
O
B.5.26 userLaMu
L
TA
Usuario que realizó la última modificación (MINS: no se trata de una ejemplarización
PersonTypeInstance).
TO
N
IO
EJEMPLO
C
C
U

D
O
<... id=”...” >

R
...
EP
...
R
</...>
SU
A
B.5.27 userName
I D
IB
H
Iniciales del usuario, por ejemplo un conjunto compuesto por tres letras.
O
PR
EJEMPLO
<... id=”...” >

...
<userName>BAP</userName>
...
</...>

PERUANA 102 de 128
B.5.28 versionNo
Número de versión del ejemplar de objeto conectado a este proyecto. Después de una
modificación de este ejemplar de objeto, este campo también debería actualizarse.
L
IA
EJEMPLO
C
R
PA
<... id=”...” >
O
...
L
<versionNo>23</versionNo>
TA
...
</...>
TO
N
IO
B.6 Referencias
C
C
U
B.6.1 appendixGroup
D
O
R
Una subdivisión para identificar un cierto archivo adjunto.

EP
R
EJEMPLO
SU

A
D
<Appendix id=”...” >

I
...
IB
<appendixGroup>
H

O
...
PR
</AppendixGroup>
</appendixGroup>
...
</Appendix>
Se considera que el marco asociado ha definido un AppendixType Appendix.

PERUANA 103 de 128
B.6.2 contactPerson
La persona conectada a un objeto PersonInRole o conectada a una organización específica.
EJEMPLO
L
IA
C
R
PA
<Organisation id=”...” >
...
O
<contactPerson>
<Person id=”...” >
L
TA
...
</Person>
</contactPerson> TO
</Organisation>
N
IO
Se considera que el marco asociado ha definido un OrganisationType Organization y un

C
PersonType Person.
C
U
D
O
B.6.3 executor
R
EP
La PersonInRole que hará de ejecutor de esta transacción.

R
SU
B.6.4 group
A
I D
El grupo general para montar un conjunto de archivos adjuntos.

IB
H
O
EJEMPLO
PR

...
<group>
<Group id=”...” >
...
</Group>
</group>
...
PERUANA 104 de 128
</AppendixGroup>
Se considera que el marco asociado ha definido un GroupType Group.
B.6.5 initiator
L
IA
C
R
La PersonInRole que hará de iniciador de esta transacción.
PA
O
B.6.6 message
L
TA
El mensaje que contiene un archivo adjunto específico.TO
N
EJEMPLO
IO
C

C
U
<Appendix id=”...” >

D
...
O
<message>
R
<Message id=”...” >

EP
...
R
</Message>
</message>
SU
...
</Appendix>
A
D
Se considera que el marco asociado ha definido un AppendixType Appendix y un

I
IB
MessageType Message.
H
O
PR
B.6.7 messageInTransaction
Referencia a la posición de este mensaje en el flujo de la transacción.
B.6.8 organization
La organización perteneciente a un objeto PersonInRole.

PERUANA 105 de 128
EJEMPLO

...
L
IA
<organisation>
<Organisation id=”...” >
C
...
R
PA
</Organisation>
</organisation>
O
...
</PersonInRole>
L
TA
Se considera que el marco asociado ha definido un OrganisationType Organization.
TO
N
B.6.9 role
IO
C
C
Referencia a un papel de una organización, cumplido por un PersonTemplate (persona).

U
D
O
R
B.6.10 substituting
EP
R
PersonInRole que en nombre de esta persona está autorizado a enviar mensajes.

SU
NOTA: Referencia substituting. Una referencia formal de la PersonInRole de esta transacción para
A
habilitar otra persona a actuar en ausencia de la PersonInRole formal que cumple esta función. Ambos
D
deberían referirse al mismo tipo de rol.

I
IB
H
O
B.6.11 succesor
PR
Sucesor de otra persona en un determinado papel.
B.6.12 transaction
La transacción que contiene un grupo específico, un mensaje o una fase de transacción.

PERUANA 106 de 128
EJEMPLO
<Message id=”...” >

...
L
IA
<transaction>
<Transaction id=”...” >
C
...
R
PA
</Transaction>
</transaction>
O
...
</Message>
L
TA
Se considera que el marco asociado ha definido un MessageType Message y un
TransactionType Transaction. TO
N
IO
C
C
U
D
O
R
EP
R
SU
A
ID
IB
H
O
PR

PERUANA 107 de 128
ANEXO C
(INFORMATIVO) 
Ejemplo de mapa de interacción simplificado de una oficina
L
de diseño
IA
C
R
PA
C.1 Generalidades
O
L
En nuestro ejemplo de creación de un marco de interacción, el alcance de la interacción se
TA
ha simplificado en el seno de una oficina de diseño (véase el ejemplo en capítulo 4). La
interacción se define en el marco de la declaración de:TO
N
- funciones,  
IO
- transacciones,  
C
- mensaje en transacciones,  
C
- el orden de los mensajes en la transacción,  

U
D
- elementos de datos en los mensajes.  

O
R
EP
C.2 Funciones y transacciones  

R
SU
Para ilustrar el alcance de la interacción en nuestro ejemplo, las acciones comunicativas se

A
representan en un "mapa de interacción", que muestra los roles vinculados por las
D
transacciones.  
I
IB
H
O
Roles:  
PR
- CR1: Cliente;
 
- R1: Jefe de proyecto;
 
- R2: Ingeniería de sistemas;  
- R3: Ingeniería 3D;

PERUANA 108 de 128
– R4: Ingeniería de costes. Las interacciones se pueden resumir en una tabla de rol

de transacción.  
Tabla C.1 - Tabla de rol de transacción de una oficina de diseño simplificado  
L
IA
Tipo de transacción Rol de iniciador Rol de ejecutor
C
T1 Entrega diseño CR1 Cliente R1 Jefe de proyecto
R
PA
T2 Entrega de las especificaciones del sistema R1 Jefe de proyecto R2 Ingeniería de sistemas
T3 Entrega modelo 3D R1 Jefe de proyecto R3 Ingeniería 3D
O
T4 Cálculo del coste de entrega R1 Jefe de proyecto R4 Ingeniería de costes
L
TA
TO
N
IO
C
C
U
D
O
R
EP
R
SU
A
D
I
IB
H
O
Figura C.1 – Mapa de interacción, identificando los tipos de rol y tipos de

PR
transacciones relevantes

PERUANA 109 de 128
C.2.1 RoleType
Los roles se definen como 'RoleTypes' en el marco de trabajo. Cada RoleType se puede
definir en términos de:
L
IA
- un ID (identificación de roleType),
C
R
- [Debería ser un valor de ID XML válido (nombre calificado). Hay
PA
ciertas restricciones: * Único dentro del modelo, * No se permiten ciertos
caracteres ('/', '$', '#', '@', ...), * Sin espacios, * No se debería empezar con un
O
dígito]
L
TA
– descripción (especificación de roleType),  
TO
– responsabilidades (alcance, tarea, tarea de apoyo y retroalimentación),  
N
IO
– metadatos (última mutación, información de ayuda, etc.).  

C
C
U
D
Los cuatro roles de nuestro ejemplo se han definido en el marco de trabajo (véase el ejemplo
O
siguiente en XML):
R
EP
<RoleType id=”CR1_Client” >

<description>CR1: Client</description>
R
<startDate>2010-10-29T00:00:00.000+02:00</startDate>
SU
<endDate>2099-10-29T00:00:00.000+02:00</endDate>
A
<dateLaMu>2010-10-29T00:00:00.000+02:00</dateLaMu>
D
<userLaMu>Ronald</userLaMu>
I
IB
<language></language>
H
<category></category>
O
<helpInfo></helpInfo>  
PR
<code></code>
<responsibilityScope>Is responsable for the realistarion of the Project in terms of time,
Quality and
cost < /responsibilityScope>
<responsibilityTask></responsibilityTask>
<responsibilitySupportTask></responsibilitySupportTask>
<responsibilityFeedback></responsibilityFeedback>
</RoleType>
<RoleType id=”R1_Project_Leading” >
<description>R1: Project Leading</description>
PERUANA 110 de 128
<helpInfo></helpInfo>
L
<code></code>
IA
<responsibilityScope>Has to deliver the project according to the contract
C
requirements</responsibilityScope>
R
PA
O
</RoleType>
L
<RoleType id=”R2_System_Engineering” >
TA
<description>R2: System Engineering</description>
TO
N
IO
C
C
U
D
<code></code>
O
<responsibilityScope>Has to deliver a system specification according to contractual

R
EP
agreements</responsibilityScope>
R
SU
</RoleType>
<RoleType id=”R3_3D_Engineering” >
A
D
<description>R3: 3D Engineering</description>
I
IB
H
O
PR
<code></code>
<responsibilityScope>Has to deliver a 3D model according to contractual
</RoleType>

PERUANA 111 de 128
<RoleType id=”R4_Cost_Engineering” >

<description>R4: Cost Engineering</description>
L
IA
C
R
PA
<code></code>
<responsibilityScope>Has to deliver a cost calculation according to contractual
O
L
TA
</RoleType>
TO
N
IO
C
C.3 Mensaje en una transacción

C
U
D
O
Una transacción contiene un conjunto de mensajes que se intercambian para un propósito

R
determinado. La transacción también estipula los papeles participantes, el punto en el ciclo

EP
de vida, y la secuencia en la que los mensajes deberían entregarse (si procediera).

R
SU
C.3.1 TransactionType
A
D
I
Las transacciones se definen como 'TransactionTypes' en el marco de trabajo. Cada

IB
TransactionType se puede definir en términos de:

H
O
– un ID (identificación de TransactionType),  
PR
– descripción (especificación de TransactionType),

 
– metadatos (resultado de TransactionType, helpinfo, etc.),
 
– los RoleTypes que están involucrados en el TransactionType. 
Los cuatro TransactionTypes en nuestro ejemplo se representan a continuación en una vista

XML:  
PERUANA 112 de 128
- T1: Entrega del diseño;
- T2: Entrega de la especificación del sistema;
- T3: Entrega del modelo 3D;
L
 
IA
- T4: Entrega del cálculo de costes.  
C
R
PA
<TransactionType id=”T1” >
O
<description>T1 Deliver design </description>
L
TA
TO
N
IO
C
C
<code></code>
U
<result>Design is delivered</result>
D
<initiator>
O
<RoleTypeRef idref=”CR1_Client”/ >

R
</initiator>
EP
<executor>
R
<RoleTypeRef idref=”R1_Project_Leading”/ >

</executor>
SU
</TransactionType>
A
<description>T2 Deliver system specification</description>

D
I
IB
H
O
PR
<code></code>
<result>System specification is delivered</result>
<initiator>
</initiator>
<executor>
<RoleTypeRef idref=”R2_System_Engineering”/ >
</executor>
PERUANA 113 de 128
</TransactionType>
<TransactionType id=”T3” > 
<description>T3 Deliver 3D model</description>
L
IA
C
R
PA
<code></code>
O
<result>3D model is delivered</result>
L
<initiator>
TA
</initiator>
<executor>
TO
<RoleTypeRef idref=”R3_3D_Engineering”/ >
N
IO
</executor>
</TransactionType>
C

C
<description>T4 Deliver cost calculation</description>

U
D
O
R
EP
R
SU
A
<code></code>
D
<result>Cost calculation is delivered</result>

I
<initiator>
IB

H
</initiator>
O
<executor>
PR
<RoleTypeRef idref=”R4_Cost_Engineering”/ >

</executor>
</TransactionType>
IDM establece una distinción entre un rol que hace una petición (el iniciador) y el rol que da
efecto a esa petición (el ejecutor). Una transacción sólo tendrá un rol iniciador y un solo rol
ejecutante. Por ejemplo, TransactionType 'T3 Deliver 3D model' solo puede ser iniciado por
el rol R1 Jefe de proyecto y ejecutado por el rol R3, que es la Ingeniería 3D.

PERUANA 114 de 128
Mediante el uso de transacciones, la transferencia de información se introduce en un

contexto procedimental.
C.3.2 TransactionPhaseType
L
IA
C
Para indicar el estado de interacción dentro de una transacción, las fases pueden estar
R
relacionadas con los TransactionTypes. De hecho, los TransactionPhaseTypes dentro de
PA
TransactionType representan el patrón de transacción. Las definiciones
TransactionPhaseType proporcionan una identificación de TransactionPhaseType y algunos
O
metadatos. El número de fases y su descripción no están restringidos.
L
TA
TO
En nuestro ejemplo, se han definido los siguientes TransactionPhaseTypes, que se refieren
a la Figura 2 del Capítulo 3:
N
IO
- resultado deseado;
C
 
C
- resultado solicitado;
U
 
D
O
- resultado prometido;  
R
EP
- resultado producido;
 
R
- resultado declarado;
SU
 
A
- resultado aceptado.  
D I
IB
H
El ejemplo siguiente muestra la definición de TransactionPhaseType en XML:

O
PR
<TransactionPhaseType id=”Desired_Result” >

<description>Desired result</description>
<code>-</code>
PERUANA 115 de 128
<TransactionPhaseType id=”Result_Accepted” >

<description>Result accepted</description>
L
IA
C
R
PA
<code>-</code>
O
<TransactionPhaseType id=”Result_Produced” >
L
<description>Result produced</description>
TA
TO
N
IO
C
C
U
<code>-</code>
D
O
<TransactionPhaseType id=”Result_Promised” >

R
EP
<description>Result promised</description>
R
SU
A
D
I
IB
H
<code>-</code>
O
PR
<TransactionPhaseType id=”Result_Requested” >

<description>Result requested</description>
<code>-</code>

PERUANA 116 de 128
<TransactionPhaseType id=”Result_Stated” >
<description>Result stated</description>
L
IA
C
R
PA
<code>-</code>
O
L
TA
C.3.3 MessageType TO
N
IO
Un mensaje es un modelo de información que contiene datos. El MessageType define la

C
estructura y proporciona los elementos para el contenido del mensaje.

C
U
D
Dentro de cada mensaje, hay grupos de segmentos (elementos compuestos). Estos elementos
O
compuestos son definidos por ComplexElementTypes. Dentro de cada segmento, puede

R
EP
haber una mezcla de elementos compuestos y/o elementos singulares. Los elementos
singulares son definidos por SimpleElementTypes.
R
SU
El ejemplo siguiente muestra en XML la definición de los MessageTypes que se representan

A
gráfica- mente en la Figura 5 del Capítulo 3:

DI
IB
- solicitud de modelo 3D;  

H
O
- trabajo realizado y solicitud de aprobación;  

PR
- solicitar ajustes;  
- trabajos aprobados;  
- trabajo no aprobado.
<MessageType id=”Request_for_3D_model” >

<description>Request for 3D model</description>
PERUANA 117 de 128
L
IA
C
<code>-</code>  
R
<complexElements>
PA
<ComplexElementTypeRef idref=”ResultRequestedComplexElement”/ >
<ComplexElementTypeRef idref=”WorkIdentificationComplexElement”/ >
O
<ComplexElementTypeRef idref=”WorkSpecificationComplexElement”/ >
L
<ComplexElementTypeRef idref=”RemarksComplexElement”/ >
TA
<ComplexElementTypeRef idref=”DeadlineComplexElement”/ >
</complexElements>
</MessageType>
TO
<MessageType id=”Work_done_and_request_approval” >
N
IO
<description>Work done and request approval</description>

C
C
U
D
O
R
EP
R
<code>-</code>
SU
<complexElements>
<ComplexElementTypeRef idref=”RequestApprovalComplexElement”/ >
A

D

I

IB

H
</complexElements>
O
</MessageType>
PR
<MessageType id=”Request_adjustments” >

<description>Request adjustments</description>
<code>-</code> 
PERUANA 118 de 128
<complexElements>
<ComplexElementTypeRef idref=”RequestAdjustmentsComplexElement”/ >
L
</complexElements>
IA
</MessageType>
C
<MessageType id=”Work_approved” > 
R
<description>Work approved</description>
PA
O
L
TA
TO
N
IO
<code>-</code>
<complexElements>
C
<ComplexElementTypeRef idref=”ApprovalComplexElement”/ >

C

U

D
O

R
</complexElements>
EP
</MessageType>
<MessageType id=”Work_not_approved” >
R
<description>Work not approved</description>

SU
A
D
I
IB
H
O
PR
<code>-</code>
<complexElements>
<ComplexElementTypeRef idref=”DisapprovalComplexElement”/ >
</complexElements>
</MessageType>

PERUANA 119 de 128
MessageType también se utiliza para identificar mensajes dentro de una transacción. La

relación entre un messageType y un transactionType se define en otro Type: el
MessageInTransactionType.
C.3.4 MessageInTransactionType
L
IA
C
R
Una transacción contiene un conjunto de mensajes que se intercambian para un propósito
PA
particular. Las definiciones MessageInTransactionType proporcionan la vinculación de
MessageTypes a TransactionTypes. Un MessageType idéntico se puede vincular a todos los
O
TransactionTypes definidos. También es posible vincular un MessageType idéntico más de
L
una vez (incluso ilimitado) con el mismo TransactionType.
TA
TO
Cada MessageInTransactionType se puede definir en términos de:
N
IO
C
- un ID (identificación del MessageInTransactionType),

C
 
U
- la dirección en la que se debería enviar el mensaje (Del Initiator al Executor

D
= true, del Executor al Initiator = Falso),  

O
R
EP
- metadatos de MessageInTransactionType,
 
R
- la referencia al MessageType (cuya posición se define en

SU
MessageInTransactionType),  
A
D
- la referencia a los TransactionType (s) para enlazar los referidos

I
IB
MessageTypes,
H
O
- la referencia a la TransactionPhase en qué estado se lleva el proceso (después

PR
de enviar el MessageType dentro de TransactionType como ha sido definido por el

MessageInTransactionType),
- la referencia al GroupType.
El ejemplo siguiente muestra en XML la definición de dos MessageInTransactionTypes en

nuestro ejemplo de entrega de un modelo 3D. El ejemplo se puede entender haciendo
referencia a la Figura 5 (en el proyecto de Norma ISO/WD 29481-2 IDM parte 2 Mapa de
interacción; Capítulo 3).

PERUANA 120 de 128
El ejemplo en XML expuesto a continuación ilustra que el TransactionType T3 comienza

con MessageType 'Solicitud de modelo 3D'. Es el primer mensaje dentro de la transacción
porque no hay MessageInTransactionType definido en MessageInTranactionType
'MessageInTransaction1'. La dirección de MessageInTransaction1 se señala de Iniciator a
Executor (value = true).
L
IA
C
El segundo MessageInTransactionType definido por 'MessageInTransaction2' hace
R
referencia a MessageType 'Trabajo realizado y solicitud de aprobación'. La Figura 5 muestra
PA
que este mensaje debería seguir dos mensajes anteriores:
O
- Solicitud de modelo 3D;  
L
TA
- Solicitar ajustes.  
TO
N
Estos dos mensajes anteriores se han definido como MessageInTransactionTypes (no 1 y 3)
IO
dentro de El MessageInTransactionType2. La dirección de MessageInTransaction1 se señala

C
desde Executor hasta Iniciator (valor = falso).

C
U
<MessageInTransactionType id=”MessageInTransactie1” >

D
O
R
EP
<received>0</received>
R
<send>0</send>
SU
<state></state>
<initiatorToExecutor>true</initiatorToExecutor>
A
<message>
D
I
<MessageTypeRef idref=”Request_for_3D_model”/ >

IB
</message>
H
<transaction>
O
<TransactionTypeRef idref=”T3”/ >

PR
</transaction>
<transactionPhase>
<TransactionPhaseTypeRef idref=”Result_Requested”/ >
</transactionPhase>
<group>
<GroupTypeRef idref=”StandardGroup”/ >
</group>
<MessageInTransactionType id=”MessageInTransactie2” >
PERUANA 121 de 128
<received>0</received>
<send>0</send>
<state></state>  
L
IA
<message>
C
<MessageTypeRef idref=”Work_done_and_request_approval”/ >
R
</message>
PA
<previous>
<MessageInTransactionTypeRef idref=”MessageInTransactie1”/ >
O
<MessageInTransactionTypeRef idref=”MessageInTransactie3”/ >
L
</previous>
TA
<transaction>
<TransactionTypeRef idref=”T3”/ > TO
</transaction>
N
<transactionPhase> 
IO
<TransactionPhaseTypeRef idref=”Result_Produced”/ >

C
</transactionPhase>
C
<group>
U
<GroupTypeRef idref=”StandardGroup”/ >

D
O
</group>
R
EP
R
C.3.5 AppendixTypes
SU
A
Los archivos adjuntos pueden estar vinculados a mensajes. Un requisito de intercambio se

ID
puede transferir como archivo adjunto al papel de ejecutor y el resultado (contribución al

IB
BIM) se entrega al iniciador.

H
O
PR
Las definiciones de AppendixType proporcionan restricción de información de elementos

de los elementos relacionados con documentos mediante la adición de metadatos a
documentos adjuntos a un mensaje.
En el listado en XML siguiente se muestra la definición del AppendixType. Los metadatos

se definen por SimpleElementTypes en el ComplexElementType
'AppendixComplexElement'.

PERUANA 122 de 128
<AppendixType id=”StandardAppendixType” >

<description>Standard Appendix</description>
L
IA
C
R
PA
<complexElements>
<ComplexElementTypeRef idref=”AppendixComplexElement”/ >
O
</complexElements>
L
</AppendixType>
TA
C.3.6 Limitando el contenido de los mensajes
TO
N
IO
C
El tercer y último paso para definir el marco de interacción es definir los componentes dentro
C
de MessageTypes con el fin de:

U
D
- estructurar los MessageTypes;

O
 
R
EP
- restringir la entrada de contenido.

R
SU
La definición de MessageType ya contiene los elementos compuestos de un mensaje. Estos

elementos compuestos se definen como ComplexElementTypes.
A
DI
IB
Los ComplexElementTypes consisten en SimpleElementTypes (también son posibles otros

H
Complex ElementTypes). Los SimpleElementTypes están relacionados con

O
UserDefinedTypes para definir restricciones a la entrada de contenido. Esta estructura se

PR
representa gráficamente a continuación.

PERUANA 123 de 128
L
IA
C
R
PA
O
L
TA
TO
Figura C.2 – Componentes del modelado de un mensaje
N
IO
C.3.7 ComplexElementTypes  
C
C
U
D
Las definiciones de ComplexElementType proporcionan:

O
 
R
elementos de información de elementos de restricción,  

EP
-
R
- utilizando los mecanismos de la jerarquía de definición de tipos (en XML)

SU
para derivar un tipo complejo de otro tipo simple o complejo,  

A
- especificación de las contribuciones infoset de validación post-esquema para

D
elementos,
I
IB
 
H
- limitar la capacidad de derivar tipos adicionales de un tipo complejo dado,  

O
PR
- controlar el permiso para sustituir, en un ejemplar, elementos de un tipo

derivado para que los elementos declarados en un modelo de contenido sean
de un tipo complejo dado.  
Refiriéndonos a nuestro ejemplo de MessageType 'Solicitud de un modelo 3D', relacionado

con la tran- sacción T3 (Entrega del modelo 3D), este MessageType contiene los siguientes
ComplexElementTypes:  

PERUANA 124 de 128
- resultRequestedComplexElement; 
- workIdentificationComplexElement;
- workSpecificationComplexElement;
L
IA
- remarksComplexElement; 
C
R
- deadlineComplexElement.
PA
O
El ComplexElementType 'WorkSpecification' se muestra a continuación en XML. Un
L
ComplexElementType define su identificación, la referencia a los elementos simples que
TA
dan contenido al complexElement Type y a sus metadatos.
TO
El listado XML de ComplexElementType 'WorkSpecificationComplexElement' muestra que
N
IO
Complex ElementType contiene dos tipos SimpleElementTypes:

C
C
- ScopeOfWork;
U
D
- CostEstimation.
O
R
EP
<ComplexElementType id=”WorkSpecificationComplexElement” >

<description>Work specification</description>
R
SU
A
D
I
IB
H
O
PR
<simpleElements>
<SimpleElementTypeRef idref=”ScopeOfWork”/ >
<SimpleElementTypeRef idref=”CostEstimation”/ >
</simpleElements>
C.3.8 SimpleElementTypes
Las definiciones de SimpleElementType proporcionan:

PERUANA 125 de 128
- definición de su identificación,  
- establecimiento del "espacio de valores" y las restricciones de entrada.
L
El listado XML que se expone a continuación muestra la definición de un
IA
SimpleElementType: CostEstimation. Este SimpleElementType es parte del
C
ComplejoElementType 'WorkSpecification ComplexElementType' (ejemplo anterior).
R
PA
<SimpleElementType id=”CostEstimation” >
<description>Cost estimation</description>
O
<interfaceType/>
L
<state>active</state>  
TA
<language/>
TO
N
<category/>
IO
<helpInfo>Indication of costs </helpInfo>

<valueList/>
C
<userDefinedType>
C
<UserDefinedTypeRef idref=”EURO”/ >

U
D
</userDefinedType>
O
R
EP
C.3.9 UserDefinedTypes
R
SU
Los UserDefinedTypes se utilizan para definir las restricciones a las entradas de contenido
A
(definiendo dataTypes). A todas las posibles restricciones XML se les permite definir los
DI
UserDefinedTypes dentro de un marco de interacción. En nuestro ejemplo, sólo se han

IB
utilizado el tipo de datos 'STRING' y 'EURO'.

H
O
PR
El ejemplo siguiente muestra en el listado XML la definición de un UserDefinedType:
- identificación,  
- metadatos,  
- baseType,
- restricción XSD (para definir una restricción más específica o definir tipos de
enumeración).
PERUANA 126 de 128
- <UserDefinedType id=”EURO” >

<description>Euro</description>
<baseType>DECIMAL</baseType>
L
<xsdRestriction><xs:fractionDigits value=”2”/ > < /xsdRestriction >
IA
<helpInfo>amounts in Euro, specified in two decimals</helpInfo>
C
</UserDefinedType>
R
- <UserDefinedType id=”STRING” >
PA
<description>Character strings</description>
O
<dateLaMu>2010-10-01T00:00:00</dateLaMu> 
L
TA
<baseType>STRING</baseType>
<xsdRestriction />
<language />
TO
N
<helpInfo>The string datatype represents character strings in XML. The ‘value  
IO
space’ of string is the set of finite-length sequences of

C
characters.</helpInfo>
C
</UserDefinedType>
U
 
D
O
C.3.10 Finalización
R
EP
R
Todos los ElementTypes han sido definidos para completar el marco de interacción. Con el
SU
fin de verificar la corrección, el marco debe validarse contra su esquema XSD. El siguiente
paso es promover el marco de interacción para obtener un esquema de interacción. Estas
A
acciones se han descrito en el subcapítulo 4.8.

D
I
IB
H
O
PR

PERUANA 127 de 128
ANEXO D
(INFORMATIVO)
Principios para el algoritmo Promotor
L
IA
C
D.1 Principios para el algoritmo Promotor
R
PA
Un Promotor es un algoritmo que convierte un marco de interacción en un esquema de
O
interacción. Dado que un marco de interacción se registra en XML y un esquema de
L
interacción en XSD, se puede concluir que un Promotor extracta los elementos de datos del
TA
marco de interacción en la estructura entidad-relación de un esquema de interacción.
TO
N
El algoritmo básico de un Promotor eleva todos los elementos de datos "* Type" del marco
IO
de inter- acción (RoleType, TransactionType, MessageType, ComplexElementType,

C
SimpleElementType, etc.) en elementos tipo XSD complejos. Por supuesto, han de

C
cumplirse ciertas reglas para garantizar que el XSD resultante sea un esquema XML
U
significativo. Por ejemplo, el valor de atributo ID de un elemento de tipo * Type se interpreta

D
O
como el nombre de su equivalente de elementos complejos XSD. Como resultado, el

R
atributo ID en un marco de interacción no debería ser del tipo ID = "Role003" sino más bien
EP
como ID = "Project_Manager".
R
SU
El XSD está organizado de tal manera que los MessageTypes son los elementos complejos
primarios para estructurar el contenido de un mensaje a nivel del intercambio real en una
A
transacción. Dicho mensaje debería contener suficiente información para rastrear la posición
D
real de este mensaje en el flujo total de mensajes y para determinar qué mensajes sucesivos
I
IB
pueden ser enviados desde esta posición.

H
O
PR
Para generar los tipos de atributos y tipos de relación correctos para el XSD resultante, el
Promotor consulta un archivo que describe qué plantilla se debería utilizar para cada tipo de
elemento complejo (archivo de plantillas).

PERUANA 128 de 128
BIBLIOGRAFÍA
[1] Dietz J.L.G. (2006). Enterprise Ontology: Theory and Methodology, Springer; 1
edition, 240 pages, ISBN: 3540291695
L
IA
C
R
PA
O
L
TA
TO
N
IO
C
C
U
D
O
R
EP
R
SU
A
ID
IB
H
O
PR

Ntp-Iso 29481-2 PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ntp-Iso 29481-2 PDF

Загружено:

Авторское право:

Доступные форматы

NORMA TÉCNICA NTP-ISO 29481-2

entrega de la información. Parte 2: Marco de trabajo para la

Building information models. Information delivery manual. Part 2: Interaction framework

R.D. N° 048-2018-INACAL/DN. Publicada el 2019-01-17 Precio basado en 128 páginas

© ISO 2012 - © INACAL 2018

de la ISO en territorio peruano.

Calle Las Camelias 817, San Isidro

ANEXO A (NORMATIVO) Definición del esquema de marco 19

ANEXO B (NORMATIVO) Definición de plantillas 73

ANEXO C (INFORMATIVO) Ejemplo de mapa 107

ANEXO D (INFORMATIVO) Principios para el algoritmo 127

A.1 El Instituto Nacional de Calidad - INACAL, a través de la Dirección de

ingeniería civil - Subcomité Técnico de Normalización de Organización de la información

sobre obras de construcción, presentó a la Dirección de Normalización -DN-, con fecha

2018-10-26, el PNTP-ISO 29481-2:2018, para su revisión y aprobación, siendo sometido

a la etapa de discusión pública el 2018-11-07. No habiéndose recibido observaciones, fue

oficializada como Norma Técnica Peruana NTP-ISO 29481-2:2018 Modelado de la

información de los edificios. Manual de entrega de la información. Parte 2: Marco

de trabajo para la interacción, 1ª Edición, el 17 de enero de 2019.

A.4 La presente Norma Técnica Peruana presenta cambios editoriales referidos

de acuerdo a las Guías Peruanas GP 001:2016 y GP 002:2016.

B. INSTITUCIONES QUE PARTICIPARON EN LA ELABORACIÓN

DE LA NORMA TÉCNICA PERUANA

Secretaría UNIVERSIDAD DE LIMA

Presidente Javier Eduardo Arrieta Freyre

Colegio de Arquitectos del Perú José Burgos Ventura

Corporación Aceros Arequipa S.A. Grace Atkins Zelada

Diego Fuentes Hurtado

SENCICO José Luis Amado Travezaño

Gabriela Esparza Requejo

UNACEM Daniel Espinoza Gonzalez

Jeffery Lewis Arriarán

Universidad de Lima Christian Iván Izquierdo Cárdenas

Ana Luna Torres

Universidad Nacional de Ingeniería Félix Wilfredo Ulloa Velásquez

Universidad Peruana de Ciencias Aplicadas José Rodríguez Barboza

Consultor Christian Leyton Dávalos

Consultor José Salinas Saavedra.

La ISO (Organización Internacional de Normalización) es una federación mundial de

la aprobación por al menos el 75 % de los organismos miembros que emiten voto.

Se llama la atención sobre la posibilidad de que algunos de los elementos de este

documento puedan estar sujetos a derechos de patente. ISO no asume la responsabilidad

por la identificación de cualquiera o todos los derechos de patente.

obra civil, Subcomité SC 13, Organización de información relativo a obras de

información de los edificios. Manual de entrega de la información:

- Parte 1: Metodología y formato.

- Parte 2: Marco de trabajo para la interacción. Las siguientes partes están

- Parte 3: Definiciones de vista del modelo.

El modelado de la información de edificios proporciona un concepto para describir y

se refieren a la gestión y coordinación de las partes involucradas. La coordinación

y ágil. Como se incide mucho en la coordinación y en la interacción, esta parte de la

las labores de coordinación entre los actores de un proyecto de construcción. Describe

requerida para su ejecución. Los marcos de interacción resultantes permiten la

y de proyecto. También ofrece un formato para dar soporte a las soluciones

Modelado de la información de los edificios. Manual de

– Una metodología que describe un marco de interacción,

– Una manera adecuada de asignar responsabilidades e interacciones, que

proporciona un contexto del proceso para el flujo de la información,

Un formato en el que se debería especificar un marco de interacción.

de software utilizados en el proceso de construcción, promover la colaboración digital entre

intercambio de información precisa, fiable, repetible y de alta calidad.

Los documentos indicados a continuación, en su totalidad o en parte, son normas para

ISO 29481-1 Modelado de la información de los edificios.

- Parte 1: Metodología y formato.  

- Parte 2: Marco de trabajo para la interacción. Las siguientes partes están