UNIVERSIDAD TECNOLÓGICA NACIONAL FACULTAD

UNIVERSIDAD TECNOLÓGICA NACIONAL
FACULTAD REGIONAL SANTA FE
DOCTORADO EN INGENIERÍA
Tesis Doctoral
UN MODELO INTEGRADO PARA LA
REPRESENTACIÓN DE PRODUCTOS CON
ESTRUCTURAS COMPLEJAS
Marcela Vegetti
Director: Dr. Horacio P. Leone
Co-directora: Dra. Gabriela P. Henning
Marzo, 2007
UNIVERSIDAD TECNOLÓGICA NACIONAL
FACULTAD REGIONAL SANTA FE
Doctorado en Ingeniería
Mención en Sistemas de Información
UN MODELO INTEGRADO PARA LA
REPRESENTACIÓN DE PRODUCTOS CON
ESTRUCTURAS COMPLEJAS
Marcela Vegetti
Director
Dr. Horacio Leone
Co-Directora
Dra. Gabriela Henning
Jurados de Tesis:
Dra. María Rosa Galli
Dr. Giancarlo Guizzardi
Dr. Jose Valdeni de Lima
Marzo, 2007
A Ivan, Facundo y Martina
A mis padres
AGRADECIMIENTOS
Quisiera agradecer en primer lugar a mis hijos Facundo y Martina, por soportar mi
ausencia de estos últimos meses con cariño y comprensión. A Iván y a mis padres por cubrir
esa ausencia; sin su apoyo y aliento constante no hubiese sido posible la realización del
presente trabajo.
A mi
director, el Dr. Horacio Leone, quien me brindó el espacio posible y las
herramientas para iniciarme en el camino de la investigación, además de sus guías y
consejos durante el desarrollo de este trabajo. Mi agradecimiento a mi codirectora, la Dra.
Gabriela Henning por su tiempo, formación y apoyo brindado en todo momento,
especialmente en el tedioso trabajo de correcciòn
A cada uno de los integrantes del CIDISI, muy especialmente a Manuel, Diego,
Celeste, Santiago y Luis, que con su esfuerzo y dedicación hicieron posible contar con las
herramientas computacionales que implementaron los modelos propuestos en esta tesis.
A mis compañeros de INGAR que colaboraron de alguna manera en este trabajo con
su ayuda desinteresada, brindándome importantes aportes y generando un ambiente de
trabajo propicio para el desarrollo del mismo. En especial a Silvio, quien siempre me alentó
para terminar esta tesis; y a Diego, por haber dedicado su tiempo a la lectura de esta tesis y
haber hecho importantes aportes.
A la Universidad Tecnológica Nacional y al Consejo Nacional de Investigaciones
Científicas y Técnicas (CONICET) por el aporte financiero, las herramientas y el material
brindado.
V
PREFACIO
Las empresas de producción industrial se desenvuelven en un contexto que les exige
incrementar su competitividad constantemente. Una de las estrategias empleadas con este
fin consiste en aumentar lo máximo posible los niveles de integración de todas las
actividades que a diario se desarrollan en las empresas, tanto en lo que respecta a la
gestión administrativa como a la producción de bienes físicos, lo cual en gran medida
implica, automatizar operaciones, compartir información y posibilitar la interoperación entre
aplicaciones. Internet es el más reciente capítulo en el largo camino hacia la integración
informática de los ambientes productivos, que comenzó por los años 60 con incorporación
de las herramientas CAD (“Computer Aided Design”), sistemas MRP (“Material Requirement
Planning”) y los primeros sistemas de gestión de inventarios.
Durante estas primeras etapas, la automatización se circunscribió a áreas
individuales de la empresa, no se incluyó a las interacciones entre las unidades de negocios
de la misma ni a las relaciones con clientes y proveedores. Posteriormente, los sistemas
MRP evolucionaron hacia los denominados MRP II, que apuntaron a la planificación de gran
parte de los recursos de manufactura dentro de una empresa. En la siguiente etapa, los
sistemas ERP (“Enterprise Resource Planning”), se centraron en la integración de las
diferentes áreas de una organización, permitiendo que éstas tengan una visión integral de
los distintos procesos de negocios intra-empresa.
Con el surgimiento de Internet, se tornó viable la integración entre empresas. Sin
embargo, al mismo tiempo que Internet brinda a las organizaciones la capacidad de
compartir información, las ha situado en un contexto de creciente competitividad, debido a
su exposición a mercados globales. En consecuencia, las empresas tuvieron que cambiar
sus formas de organizarse y hacer negocios para poder adaptarse a los nuevos
requerimientos: productos personalizados, de menor costo, mayor calidad y con ciclos de
vida más cortos. Estos nuevos requerimientos han ocasionado una explosión en la variedad
de productos, incorporando una exigencia nueva a los sistemas de información existentes.
En la actualidad, una empresa industrial debe ser lo suficientemente ágil para
responder a los frecuentes cambios que le presenta el mercado respecto a la demanda de
sus productos. Para dar respuesta a este requerimiento es importante que cada
organización comparta un modelo de productos común, que abarque todas las etapas del
ciclo de vida del mismo y que dé respuestas a las nuevas exigencias que impone sobre
estos modelos el avance de las Tecnologías de la Información y las comunicaciones.
VII
En virtud del interés de este tema, en esta Tesis se presenta la conceptualización
de un modelo integral de información de productos que concede mejoras tangibles e
intangibles en lo que respecta a la gestión de información. Dicho modelo cuenta, además,
con una flexibilidad considerable, ya que puede extenderse para cubrir las necesidades
específicas de cada empresa particular.
El modelo se sustenta en dos jerarquías de conceptos, que pueden definirse para
organizar la información relativa a los productos. Una de estas jerarquías especifica tres
niveles de abstracción en la definición de los productos. Los dos niveles superiores
representan información agregada de los productos, que sirve de soporte para las
actividades de toma de decisión de tipo estratégico-tácticas; en tanto, el último nivel de
abstracción se refiere a información detallada correspondiente a productos con existencia
física. La otra jerarquía propuesta, permite representar las relaciones entre materias primas,
semielaborados, y productos finales definidos en un mismo nivel de la jerarquía de
abstracción.
Para la introducción del modelo propuesto se ha adoptado una representación
híbrida, que utiliza tecnología de objetos. Esta última, con sus capacidades de
encapsulamiento, herencia y composición, contribuye a la generación de un modelo de
objetos extensible y adaptable a diferentes dominios. Esta potencialidad resulta
particularmente útil, pues diferentes entornos productivos imponen distintos requerimientos
al modelo de productos.
Las ambigüedades del modelo de objetos se han restringido mediante la definición
de axiomas, especificados en el leguaje O-Telos, un lenguaje de modelado conceptual que
integra propiedades de lenguajes deductivos y orientados a objetos. Esta especificación
permite la definición de un modelo computacional integrado en la base de objetos deductiva
ConceptBase.
El modelo se ha utilizado para la representación de información estructural de
productos correspondiente a dos casos de estudio reales, los cuales, no sólo permitieron
tomar contacto directo con la situación actual que evidencian las empresas industriales, en
cuanto a la gestión de información de productos, sino también afrontar problemas de
dimensiones reales que permitieron validar el modelo conceptual propuesto.
En esta Tesis se discute, además, el empleo del modelo propuesto para la definición
de dos aplicaciones que persiguen objetivos diferentes, y que se basan en tecnologías
disímiles. Por un lado, se presenta un sistema de procesamiento de BOMs (“Bill of
Materials”), desarrollado con tecnología J2EE, el cual permite verificar la factibilidad del
diseño e implementación de un sistema de información basado en el modelo previamente
presentado. Por otro lado, se introduce un prototipo basado en la tecnología de la Web
VIII
Semántica, que utiliza la conceptualización propuesta para definir una ontología que permite
la integración semántica de información de productos almacenada en repositorios
distribuidos.
Los resultados parciales del trabajo de investigación realizado y directamente
vinculados a esta Tesis, han sido plasmados y divulgados, fundamentalmente, a través de
las siguientes publicaciones:
PRoduct ONTOlogy. Defining product-related concepts for logistics planning
activities.
Diego Giménez, Marcela Vegetti, Gabriela Henning y Horacio
Leone. Computers in Industry. En prensa.
Product Ontology. Defining Product-related Concepts for Production Planning
Activities. Diego Giménez, Marcela Vegetti, Gabriela Henning y Horacio
Leone. Computer-Aided Chemical Engineering, 21, Elsevier, 2219–2224
(2006).
An Object-Oriented Model for Complex Bill of Materials in Process Industries.
Marcela Vegetti, Gabriela Henning y Horacio Leone. Brazilian Journal of
Chemical Engineering,19, 491-497 (2002).
An Object-Oriented Framework for Bill of Materials in Process Industries.
Marcela Vegetti, Gabriela Henning y Horacio Leone. Computer-Aided
Chemical Engineering, 10, Elsevier, 991-996 (2002).
Además, los resultados han sido presentados como contribuciones en los siguientes
congresos nacionales e internacionales:
An Object Oriented Model for Complex Bill of Materials in Process Industries.
Marcela Vegetti, Gabriela Henning y Horacio Leone. ENPROMER 2001- 3rd
Mercosur Congress on Process Systems Engineering – 1st Mercosur
Congress on Chemical Engineering, Santa Fe – Argentina, 16 al 20 de
setiembre de 2001.
Un Modelo de Estructura de Productos para Industrias de Procesos. Marcela
Vegetti, Gabriela Henning y Horacio Leone. CAIP 2001 - 5º Congreso
Interamericano de Computación Aplicada a la Industria de Procesos, Campos
do Jordão – Brasil, 22 al 25 de octubre de 2001.
Hacia un Framework Orientado a Objetos para Bill of Materials Complejos.
Marcela Vegetti, Gabriela Henning y Horacio Leone. 32 JAIIO - 32 Jornadas
Argentinas de Informática e Investigación Operativa, Buenos Aires –
Argentina, 1 al 5 de septiembre de 2003.
IX
A PDM System for the Derivation of Products with Complex Structure in
Process Industries. Marcela Vegetti, Gabriela Henning y Horacio Leone. 33
JAIIO - 33 Jornadas Argentinas de Informática e Investigación Operativa,
Córdoba – Argentina, 20 al 24 de septiembre de 2004.
PRoduct ONTOlogy. Definition of an Ontology for Complex Product Modelling
Domain. Marcela Vegetti, Gabriela Henning y Horacio Leone. ENPROMER
2005 – 2nd Mercosur Congress on Chemical Engineering and 4th Mercosur
Congress on Process Systems Engineering, Río de Janeiro – Brasil, 14 al 18
de Agosto de 2005.
Es importante mencionar que el trabajo de investigación que condujo al desarrollo del
modelo de productos propuesto en esta Tesis se llevó a cabo en el marco de un proyecto de
investigación mayor, vinculado a la integración informática de organizaciones industriales. El
proyecto posee como objetivo último alcanzar la integración informática de la cadena de
suministros desde una perspectiva intra- e inter-organizacional. Debe remarcarse que, para
el logro de esta meta, el modelo de productos cumple un rol fundamental. En este contexto,
se han desarrollado investigaciones que dieron lugar a los siguientes artículos que, si bien
no están directamente ligados a la propuesta expuesta en esta Tesis, hacen a un
conocimiento acabado del dominio de trabajo en que ésta se enmarca:
SCOntology: A formal approach towards a unified and integrated view of the
supply chain. Silvio Gonnet, Marcela Vegetti, Gabriela Henning y Horacio
Leone. En: Adaptive Technologies and Business Integration: Social,
Managerial and Organizacional Dimensions. M. Cunha, B. Cortes y G. Putnik
Editores. Idea Group, Inc., 137-158 (2007).
Information Logistics for Supply Chain Management within Process Industry
Environments. Marcela Vegetti, Silvio Gonnet, Gabriela Henning y Horacio
Leone. Computer-Aided Chemical Engineering, 20, Elsevier, 1231-1236.
(2005)
Towards a Supply Chain Ontology of Information Logistics within Process
Industry Environments. Marcela Vegetti, Silvio Gonnet, Gabriela Henning, y
Horacio Leone. ENPROMER 2005 – 2nd Mercosur Congress on Chemical
Engineering and 4th Mercosur Congress on Process Systems Engineering,
Río de Janeiro – Brasil, 14 al 18 de Agosto de 2005.
X
Índice
PREFACIO _______________________________________________________________ VII
ÍNDICE _________________________________________________________________ XI
LISTA DE FIGURAS _________________________________________________________ XV
LISTA DE TABLAS__________________________________________________________ XXI
I. EL MODELO DE PRODUCTOS EN LAS ORGANIZACIONES INDUSTRIALES ___________________1
I.1. Introducción ________________________________________________________ 2
I.2. Información de productos durante su ciclo de vida __________________________ 2
I.2.1. Sistemas que manejan la información de productos ________________________ 4
I.2.2. Estructura de productos ______________________________________________ 6
I.3. Influencia de las Tecnologías de la Información y de las Comunicaciones
en el modelo de productos ___________________________________________ 13
I.4. Análisis de las propuestas más relevantes _______________________________ 18
I.4.1. Propuestas tradicionales _____________________________________________ 18
I.4.2. Nuevos enfoques __________________________________________________ 22
I.4.3. Otros enfoques no tradicionales _______________________________________ 26
I.5. Necesidades a satisfacer por un modelo de productos ______________________ 29
I.6. Organización de la Tesis _____________________________________________ 31
II. DOMINIO DE TRABAJO. CARACTERIZACIÓN Y DEFINICIÓN DE SU ALCANCE ______________ 33
II.1. Introducción _______________________________________________________ 33
II.2. Clasificación de procesos productivos ___________________________________ 33
II.2.1.
Clasificación de procesos productivos basada en el flujo de materiales ______ 34
II.2.2.
Clasificación de ambientes productivos basada en el concepto de CODP
(Customer Order Decoupling Point) __________________________________ 42
II.3. Casos de estudio ___________________________________________________ 48
II.3.1.
Modelo de productos de una planta de producción de golosinas ___________ 49
II.3.2.
Modelo de productos de una industria frigorífica ________________________ 63
II.4. Conclusiones ______________________________________________________ 76
XI
____________________________________________________________________________ Índice
III. MODELO DE PRODUCTOS. DEFINICIÓN ________________________________________ 79
III.1. Introducción _______________________________________________________ 79
III.2. jerarquías relacionadas con la información de productos ____________________ 80
III.2.1.
Estructura de productos en los distintos niveles de abstracción____________ 84
III.3. Nivel de Abstracción Familia __________________________________________ 88
III.4. Nivel De Abstracción Conjunto de Variantes _____________________________ 102
III.5. Nivel de Abstracción Producto ________________________________________ 112
III.6. Administración de restricciones _______________________________________ 114
III.7. Sistema de Generación de BOMs _____________________________________ 120
III.7.1.
Actividades de creación de los miembros de los distintos niveles de abstracción
de productos __________________________________________________ 121
III.8. Conclusiones _____________________________________________________ 127
IV. MODELO DE PRODUCTOS. APLICACIONES _____________________________________ 129
IV.1. Introducción ______________________________________________________ 129
IV.2. Aplicación del Modelo a los Productos de la Planta de Golosinas_____________ 130
IV.2.1.
Especificación y gestión de productos definidos a nivel de Familia ________ 134
IV.2.2.
Especificación y gestión de conjuntos de variantes ____________________ 139
IV.2.3.
Especificación y gestión de productos_______________________________ 148
IV.3. Aplicación del Modelo a Productos de la Industria Frigorífica ________________ 153
IV.4. Conclusiones _____________________________________________________ 165
V. PROTOTIPO DE SISTEMA DE PROCESAMIENTO DE BOMS __________________________ 167
V.1. Introducción ______________________________________________________ 167
V.2. Arquitectura y tecnologías usadas en la implementación del prototipo _________ 167
V.3. Funcionalidades del Prototipo ________________________________________ 173
V.4. Definición de Familias_______________________________________________ 175
V.5. Definición de Conjuntos de Variantes___________________________________ 182
V.6. Definición de Productos _____________________________________________ 188
V.7. Conclusiones _____________________________________________________ 191
VI. USO DEL MODELO PROPUESTO EN UNA APLICACIÓN BASADA EN LA WEB SEMÁNTICA ____ 193
VI.1. Introducción ______________________________________________________ 193
VI.2. Las ontologías como pilares de la Web Semántica ________________________ 196
VI.3. Arquitectura de la Web Semántica _____________________________________ 199
VI.4. Un Primer Paso Hacia la Definición de un Sistema PDM Basado en la Web
Semántica _______________________________________________________ 202
VI.4.1.
Definición de PRoduct ONTOlogy __________________________________ 205
XII
____________________________________________________________________________ Índice
VI.4.2.
Definición de una arquitectura para integrar información de productos _____ 213
VI.5. Conclusiones _____________________________________________________ 219
VII. CONCLUSIONES Y FUTUROS TRABAJOS ______________________________________ 221
VII.1.Introducción ______________________________________________________ 221
VII.2.Principales Contribuciones ___________________________________________ 221
VII.3.Trabajos Futuros___________________________________________________ 227
VII.3.1.
Evolución del modelo conceptual __________________________________ 228
VII.3.2.
Evolución de PRoduct ONTOlogy y las ontologías locales ______________ 229
VII.3.3.
Evolución del prototipo de sistema DPDM ___________________________ 230
REFERENCIAS ____________________________________________________________ 231
APÉNDICE A. DEFINICIÓN DE VISTAS EN CONCEPTBASE _____________________________ 243
A.1. Introducción ______________________________________________________ 243
A.2. Definición de Consultas y Vistas en ConceptBase ________________________ 243
A.2.1.
Base de conocimientos y formas de representación. Conceptos generales _ 244
A.2.2.
Sublenguaje Predicativo CBL_____________________________________ 244
A.2.3.
Reglas Deductivas y Restricciones ________________________________ 246
A.2.4.
Consultas ____________________________________________________ 247
A.2.5.
Vistas _______________________________________________________ 248
A.3. Algunas de las Vistas Definidas en el Modelo Propuesto ___________________ 251
APÉNDICE B. ESPECIFICACIÓN OWL DE PRONTO __________________________________ 257
B.1. Introducción ______________________________________________________ 257
B.2. Elementos del lenguaje OWL _________________________________________ 257
B.2.1.
Clases ______________________________________________________ 257
B.2.2.
Propiedades _________________________________________________ 267
B.2.3.
Individuos ___________________________________________________ 270
B.3. Código OWL de PRoduct ONTOlogy ___________________________________ 271
B.3.1.
Definición de conceptos incluidos en PRONTO ______________________ 272
XIII
____________________________________________________________________________ Índice
XIV
Lista de Figuras
I. EL MODELO DE PRODUCTOS EN LAS ORGANIZACIONES INDUSTRIALES _________________ 1
|Figura I.1. Ciclos de vida de un producto _____________________________________ 3
Figura I.2. Principales módulos de un sistema PDM _____________________________ 6
Figura I.3. Especialización del concepto de parte _______________________________ 7
Figura I.4. Bill of Materials de un producto final _________________________________ 8
Figura I.5. Bill of Materials aplanado de un producto final _________________________ 8
Figura I.6. BOMs de un único nivel ___________________________________________ 9
Figura I.7. Diferentes tipos de estructuras de productos _________________________ 11
Figure I.8: Estructuras alternativas __________________________________________ 12
Figura I.9. Gestión de Variantes. Estrategia 1- BOM básico ______________________ 19
Figura I.10. Gestión de Variantes. Estrategia 1- BOM parte idéntica________________ 20
Figura I.11. Gestión de Variantes. Estrategia 1 – BOM más - menos _______________ 20
Figura I.12. Gestión de Variantes. Estrategia 1 – BOM múltiple ___________________ 21
Figura I.13. Manejo de Variantes. Estrategia 3_________________________________ 21
Figura I.14. Arquitectura de un sistema de procesamiento de BOMs generativo ______ 23
Figura I.15. Conceptos asociados a la propuesta OOBOM _______________________ 26
Figura I.16. Patrones incluidos en el lenguaje propuesto por Gzara y colab. (2003)____ 28
Figura I.17. Vista de los conceptos básicos de la propuesta de Mänisto y colab (2001) _ 29
II. DOMINIO DE TRABAJO. CARACTERIZACIÓN Y DEFINICIÓN DE SU ALCANCE ______________ 33
Figura II.1 Clasificación de procesos productivos_______________________________ 34
Figura II.2. Una posible clasificación de sustancias _____________________________ 39
Figura II.3. Ejemplo de representación STN___________________________________ 41
Figura II.4. Algunos de los conceptos involucrados en una representación STN
para un proceso con etapas “batch” ____________________________________ 41
Figura II.5 Entornos productivos definidos por la posición del CODP _______________ 43
Figura II.6 Estructura genérica de un producto_________________________________ 51
Figura II.7. Árbol de estructura multinivel para el producto PT112608
(FrutalRelleno5x750GR) _____________________________________________ 51
Figura II.8. Estructuras de tres semielaborados tomados como ejemplo_____________ 54
Figura II.9. Ejemplo de caramelos desenvueltos con estructuras similares ___________ 55
Figura II.10. Estructura de caramelos desenvueltos de diferentes sabores frutales ______
_______________________________________________________________ 56
Figura II.11. Composición de distintos rellenos frutales __________________________ 57
XV
_____________________________________________________________________Lista de Figuras
Figura II.12. Composición de las masas frutales _______________________________ 59
Figura II.13. Composición de rellenos sabor frutilla _____________________________ 61
Figura II.14. Algunos productos de valor comercial que se pueden obtener
a partir del cuarto trasero ____________________________________________ 66
Figura II.15 Estructura de los productos intermedios CCC1tipo1, CCCtipo2 y CCCtipo3 73
Figura II.16 Ejemplo de un producto que participa en una estructura híbrida _________ 74
Figura II.17 Diferentes semielaborados a partir de los cuales puede obtenerse el producto
MP1CarneCocida. __________________________________________________ 74
III. MODELO DE PRODUCTOS. DEFINICIÓN ________________________________________ 79
Figura III.1. Distintos niveles en la abstracción de productos______________________ 81
Figura III.2. Tres niveles de abstracción en la definición de un producto_____________ 83
Figura III.3. Estructuras de composición y de descomposición ____________________ 84
Figura III.4. SH para BolsínFrutalROC, instancia del nivel ConjuntodeVariantes ______ 86
Figura III.5. SH correspondiente a CarameloFrutalEnv, instancia del nivel Familia_____ 87
Figura III.6. Modelo de productos propuesto __________________________________ 88
Figura III.7. Conceptos del nivel Familia______________________________________ 89
Figura III.8. Modelo asociado a la clase Relación ______________________________ 92
Figura III.9. Ejemplos de instancias de ValorRestringido _________________________ 94
Figura III.10. Mecanismo de inferencia de los requerimientos de una familia _________ 98
Figura III.11. Diagrama de clases ConjuntodeVariantes ________________________ 103
Figura III.12. Clase Cambio y conceptos relacionados _________________________ 107
Figura III.13. Definición de Producto________________________________________ 112
Figura III.14. Diagrama de clases asociadas a la administración de restricciones ____ 115
Figura III.15. Módulos del sistema de procesamiento de BOMs __________________ 120
Figura III.16. Diagrama de Interacción correspondiente a la creación de
una instancia de la Clase FamiliaC ____________________________________ 122
Figura III.17. Diagrama de interacción CrearEstructuraC________________________ 122
Figura III.18. Diagrama de Interacción asociado a la creación de una instancia de la clase
ConjuntodeVariantesC _____________________________________________ 123
Figura III.19. Diagrama de Interacción asociado a la creación de una instancia ______ 124
de la clase Modificación _________________________________________________ 124
Figura III.20. Diagrama de interacción asociado a la creación de una instancia de la clase
ProductoC._______________________________________________________ 125
XVI
_____________________________________________________________________Lista de Figuras
IV. MODELO DE PRODUCTOS. APLICACIONES _____________________________________ 129
Figura IV.1. Jerarquía de abstracción de la familia CarameloFrutalEnv ____________ 131
Figura IV.2. Jerarquía de abstracción de tipo FamiliaS correspondiente a PapelEnvoltorio
______________________________________________________________ 133
Figura IV.3. Jerarquía de abstracción de tipo FamiliaC correspondiente a
CarameloFrutalDes ________________________________________________ 134
Figura IV.4. Jerarquía de abstracción del tipo FamiliaS correspondiente a
PapelSeparador___________________________________________________ 134
Figura IV.5 Definición de familia CarameloFrutalEnv ___________________________ 135
Figura IV.6 Árbol de composición de la familia CarameloFrutalEnv________________ 137
Figura IV.7. Resultado de la consulta FamiliaDerivada (Especificación III. 16) _______ 138
Figura IV.8. Conjuntos de variantes VaritaKIM y BolsínFrutalROC ________________ 140
Figura IV.9 Resultado de la vista estructuraVaritaKIM __________________________ 142
Figura IV.10 Resultado de la vista estructuraBolsínROC ________________________ 143
Figura IV.11 Familias componentes de BolsínFrutalROC y VaritaKIM _____________ 144
Figura IV.12. Ejemplo de preselección de conjuntos de variantes _________________ 145
Figura IV.13. Aplicación de las preselecciones de BolsínFrutalROC ______________ 146
Figura IV.14. Definición de Productos en el caso de estudio de la planta de golosinas 150
Figura IV.15. Restricción de obligatoriedad que aplica a PapelSeparador __________ 150
Figura IV.16. Restricción de incompatibilidad aplicable a OvaloFrutal______________ 151
Figura IV.17. Restricción de obligatoriedad en SE508219
(VaritaKIMFrutillaEnv) ______________________________________________ 152
Figura IV.18. Ejemplo de consulta VerIncompatibles ___________________________ 152
Figura IV.19. Familias de productos intermedios de la industria cárnica,
sus estructuras y sus miembros ______________________________________ 153
Figura IV.20. Estructura SECarneCocIdaCongeladaSTR _______________________ 155
Figura IV.21. Resultado de la consulta InfoCarneCocidaCongelada _______________ 157
Figura IV.22. Ejemplo de aplicación de la donsulta VerSTRalternativas ____________ 159
Figura IV.23. Resultado de efectuar la consulta InfoCuadrilConTapa ______________ 161
Figura IV.24. Resultado Parcial Vista RequerimientosFamilia aplicada a
CuadrilConTapa __________________________________________________ 162
Figura IV. 25. Definición del conjunto de variantes SECarneCocidaReb ____________ 163
Figura IV. 26. Resultado de la consulta denominada estructuraSECarneCocidaReb __ 164
Figura IV.27. Consulta VerMiembrosCV aplicada a SECarneCocidaReb ___________ 165
V. PROTOTIPO DE SISTEMA DE PROCESAMIENTO DE BOMS __________________________ 167
Figura V.1. Arquitectura J2EE_____________________________________________ 169
Figura V.2. Arquitectura de COOBOM ______________________________________ 170
Figura V.3. Diagrama de paquetes, interrelación entre los conceptos que conforman
COOBOM _______________________________________________________ 171
XVII
_____________________________________________________________________Lista de Figuras
Figura V.4. Relaciones entre las clases Familia de los paquetes de las
distintas capas
_________________________________________________ 172
Figura V.5 Flujo de comunicación dentro de la aplicación _______________________ 173
Figura V.6. Diagrama de casos de uso principal de la aplicación _________________ 174
Figura V.7. Formulario para la creación de usuarios ___________________________ 175
Figura V.8. Casos de uso que extienden Gestionar Familia _____________________ 176
Figura V.9. Listado de Familias “abiertas” cargadas en el sistema ________________ 177
Figura V.10. Listado de Familias “cerradas” cargadas en el sistema_______________ 177
Figura V.11. Pantalla para la creación de una Familia __________________________ 178
Figura V.12. Pantalla para la edición la información de una Familia _______________ 178
Figura V.13. Pantalla que permite la creación de las estructuras de una Familia _____ 179
Figura V.14. Creación de una estructura de composición _______________________ 180
Figura V.15. Creación de la relación para el componente CarameloFrutalDes _______ 180
Figura V.16. Visualización de la estructura de la familia CarameloFrutalEnv. Parte 1 _ 181
Figura V.17. Visualización de la estructura de la familia CarameloFrutalEnv. Parte 2 _ 182
Figura V.18. Reporte de generado para la familia CarameloFrutalEnv _____________ 182
Figura V.19. Caso de uso Gestionar Conjunto de Variantes _____________________ 183
Figura V.20. Caso de uso Gestionar Estructura de Conjunto de Variantes __________ 184
Figura V.21. Listado de conjuntos de variantes cargados en el sistema ____________ 184
Figura V.22. Pantalla que permite la creación del conjunto de variantes VaritaKIM ___ 185
Figura V.23. Pantalla que permite la edición del conjunto de variantes VaritaKIM ____ 185
Figura V.24. Gestión del conjunto de variantes VaritaKIM - Preselección de
PapelEnvoltorio ___________________________________________________ 186
Figura V.25. Gestión del conjunto de variantes VaritaKIM - Preselección
CarameloFrutalDes ________________________________________________ 187
Figura V.26. Gestión del Conjunto de Variantes VaritaKIM- Eliminación de
PapelSeparador___________________________________________________ 188
Figura V.27. Casos de uso asociados a Gestionar Producto _____________________ 189
Figura V.28. Creación del Producto SE508219 (VaritaKIMFrutillaEnv)_____________ 189
Figura V.29. Gestión del Producto SE508219 – Selección PapelEnvoltorio_________ 190
Figura V.30. Gestión del Producto SE508219 – Selección CarameloFrutalDes______ 191
VI. USO DEL MODELO PROPUESTO EN UNA APLICACIÓN BASADA EN LA WEB SEMÁNTICA ____ 193
Figura V.1. Distintos niveles de integración informática _________________________ 195
Figura VI.2. Capas de la arquitectura de la Web Semántica _____________________ 200
Figura VI.3. Capas que suelen participar en la arquitectura de aplicaciones de la
Web Semántica____________________________________________________ 201
Figura VI.4. Árbol de estructura de la familia CarameloFrutalEnv _________________ 203
Figura VI.5. Vista de la ontología SUMO en el editor de ontologías Protégé_________ 206
Figura VI.6. Información brindada por Protégé 4 beta acerca de PRONTO _________ 206
Figura VI. 7. Taxonomía de PRONTO ______________________________________ 208
XVIII
_____________________________________________________________________Lista de Figuras
Figura VI.8. Axioma de clase de FamiliaC ___________________________________ 209
Figura VI.9. Axioma de clase correspondiente a FamiliaEnsamblada ______________ 210
Figura VI.10. Definición de una partición de valores ___________________________ 211
Figura IV.11. Relaciones entre las ontologías utilizadas ________________________ 212
Figura VI.12. Clasificación de instancias efectuada con un razonador. _____________ 212
Figura VI. 13. Arquitectura propuesta para una red colaborativa de empresas de
producción _______________________________________________________ 213
Figura VI.14. Roles que pueden tomar los nodos de la arquitectura propueta _______ 214
Figura VI.15. Diagrama de secuencias correspondiente a una consulta sobre
estructuras_______________________________________________________ 215
Figura VI.16. Interfaz de la aplicación ejecutándose en el nodo A_________________ 216
Figura VI.17. Primer nivel del la jerarquía estructural de CarameloFrutaEnv ________ 217
Figura VI.18. Expansión de una de las ramas de la estructura de CarameloFrutaEnv _ 218
Figura VI.19. Alternativas para la obtención de un componente __________________ 219
VII. CONCLUSIONES Y FUTUROS TRABAJOS ______________________________________ 221
Figura VII.1. Modelo de productos propuesto_________________________________ 223
XIX
Lista de Tablas
I. EL MODELO DE PRODUCTOS EN LAS ORGANIZACIONES INDUSTRIALES _________________ 1
Tabla I.1: Listado indentado de componentes del producto P1 _____________________ 9
Tabla I.2: Listado de componentes del producto P1 _____________________________ 9
Tabla I.3: Listado de componentes del producto C1 ____________________________ 10
Tabla I.4: Listado de componentes del producto E1 ____________________________ 10
II. DOMINIO DE TRABAJO. CARACTERIZACIÓN Y DEFINICIÓN DE SU ALCANCE ______________ 33
Tabla II.1 Comparación de diferentes entornos productivos ______________________ 44
Tabla II.2. Clasificación de diferentes tipos de industria de acuerdo a la
posición del CODP y a la orientación de las inversiones.____________________ 46
Tabla II.3. Comparación de la información de productos en entornos MTS y ETO _____ 48
Tabla II.4. BOM de un nivel del producto PT112608 (FrutalRelleno5x750GR)________ 52
Tabla II.5. BOM de un nivel del producto PT109446 (RedondoFrutaKIM5x750GR) ____ 53
Tabla II.6. BOM de un nivel del producto PT1009449 (VaritaKIM5X750GR)__________ 53
Tabla II.7. BOM de un nivel del producto SE508219 (VaritaKIMFrutillaEnv) __________ 53
Tabla II.8. BOM de un nivel del producto SE511605 (BolsínFrutilla5GREnv) _________ 53
Tabla II.9. BOM de un nivel del producto SE511714 (FrutillaKIM5GREnv) ___________ 54
Tabla II.10. BOM de un nivel del producto SE508482 (BolsinFrutillaZ) ______________ 55
Tabla II.11. BOM de un nivel del producto SE411614 (BolsínFrutilla5GRDes) ________ 55
Tabla II.12. BOM de un nivel del producto SE408215 (BolsínFrutillaDes) ____________ 55
Tabla II.13. BOM de un nivel del producto SE808943 (RellenoPera) _______________ 56
Tabla II.14. BOM de un nivel del producto SE808944 (RellenoCereza) _____________ 57
Tabla II.15. BOM de un nivel del producto SE808945 (RellenoFrutilla) ______________ 57
Tabla II.16. BOM de un nivel del producto SE808946(RellenoPomelo)______________ 57
Tabla II.17. BOM de un nivel del producto SE808947 (RellenoLima) _______________ 57
Tabla II.18. BOM de un nivel del producto SE609150 (MasaPera) _________________ 58
Tabla II.19. BOM de un nivel del producto SE609152 (MasaCereza) _______________ 58
Tabla II.20. BOM de un nivel del producto SE609259 (MasaFrutilla)________________ 58
Tabla II.21. BOM de un nivel del producto SE609149 (MasaPomelo) _______________ 59
Tabla II.22. BOM de un nivel del producto SE60915 (MasaLima) __________________ 59
Tabla II.23. BOM de un nivel del producto SE609198 (MasaFrutillaMIX) ____________ 60
Tabla II.24. BOM de un nivel del producto SE313862 (MasaFrutillaOK) _____________ 60
Tabla II.25. BOM de un nivel del producto SE311862 (MasaFrutillaEFE) ____________ 60
Tabla II.26. BOM de un nivel del producto SE613935 (MasaCerezaOK) ____________ 61
XXI
_____________________________________________________________________ Lista de Tablas
Tabla II.27. BOM de un nivel del producto SE608394 (MasaCerezaA) ______________ 62
Tabla II.28. BOM de un nivel del producto SE609109 (MasaCerezaEFE)____________ 62
Tabla II.29. Algunos cortes frescos ofrecidos. Marca A. Mercado USA ______________ 63
Tabla II.30. Algunos cortes frescos ofrecidos. Marca B. Mercado Alemania __________ 63
Tabla II.31. Ejemplos de diferentes carnes cocidas congeladas ___________________ 64
Tabla II.32. Categorización del ganado bovino en base al peso ___________________ 65
Tabla II.33. Tipificación del ganado bovino y destino del mismo ___________________ 65
Tabla II.34. Diferentes calidades de ganado bovino_____________________________ 65
Tabla II.35. Descomposición O1CuartoTCorte1 aplicada sobre el producto CuartoTCorte1
_______________________________________________________________ 67
Tabla II.36. Descomposición OP2CuartoTCorte1 aplicada sobre el producto
CuartoTCorte1_____________________________________________________ 68
Tabla II.37. Descomposición OP1CuadrilCT aplicada sobre el producto CuadrilCT ____ 69
Tabla II.38. Descomposición OP2CuadrilCT aplicada sobre el producto CuadrilCT ____ 69
Tabla II.39. Descomposición OP3CuadrilCT aplicada sobre el producto CuadrilCT ____ 69
Tabla II.40. Descomposición OP1TapaCuadril aplicada sobre el productoTapaCuadril _ 69
Tabla II.41. Descomposición OP2TapaCuadril aplicada sobre TapaCuadril __________ 70
Tabla II.42. Descomposición OP3TapaCuadril aplicada sobre el producto TapaCuadril_ 70
Tabla II.43. Descomposición OP1NalgaDeAdentroST aplicada sobre el producto
NalgaDeAdentroST _________________________________________________ 71
Tabla II.44. Descomposición OP1NalgaDeAdentroCT aplicada sobre el producto
NalgaDeAdentroCT _________________________________________________ 71
Tabla II.45. Descomposición OP2NalgaDeAdentroCT aplicada sobre el producto
NalgaDeAdentroCT _________________________________________________ 71
Tabla II.46. BOM de un nivel para el producto final CCCCub1 ____________________ 72
Tabla II.47. BOM de un nivel para el producto final CCCCub2 ____________________ 72
Tabla II.48. BOM de un nivel para el producto final CCCCub3 ____________________ 72
Tabla II.49. BOM de un nivel del producto CCCtipo1 ____________________________ 73
Tabla II.50. BOM de un nivel del producto CCCtipo2 ____________________________ 73
Tabla II.51. BOM de un nivel del producto CCCtipo3 ____________________________ 73
Tabla II.52. Composición de algunos de los productos finales del negocio de carnes
cocidas __________________________________________________________ 75
IV.
MODELO DE PRODUCTOS. APLICACIONES __________________________________ 129
Tabla IV.1. Conjuntos de variantes de CarameloFrutalEnv ______________________ 132
Tabla IV.2. Jerarquías de abstracción correspondientes a dos familias de
carnes cocidas____________________________________________________ 154
Tabla IV.3. Familias de las cuales se puede obtener MP2CarneCocida ____________ 157
XXII
_____________________________________________________________________ Lista de Tablas
VI.
USO DEL MODELO PROPUESTO EN UNA APLICACIÓN BASADA EN LA WEB SEMÁNTICA _ 193
Tabla VI.1. Distribución de productos en las diferentes organizaciones ____________ 203
Tabla VI.2. Expresividad de la ontología ____________________________________ 207
VI.
USO DEL MODELO PROPUESTO EN UNA APLICACIÓN BASADA EN LA WEB SEMÁNTICA _ 193
Tabla VI.1. Distribución de productos en las diferentes organizaciones ____________ 203
Tabla VI.2. Expresividad de la ontología ____________________________________ 207
APÉNDICE A. DEFINICIÓN DE VISTAS EN CONCEPTBASE_____________________________ 243
Tabla A.1: Formato de sentencias en un frame en CB__________________________ 245
Tabla A.2: Formato de una fórmula ________________________________________ 245
Tabla A.3: Posibles alternativas para “literal1” ________________________________ 245
Tabla A.4: Posibles alternativas para “literal2” ________________________________ 246
APÉNDICE B. ESPECIFICACIÓN OWL DE PRONTO __________________________________ 257
Tabla B.1. Restricciones de propiedad definidas en OWL _______________________ 259
XXIII
_____________________________________________________________________ Lista de Tablas
XXIV
Lista de Siglas
Sigla
Significado
AH
Abstraction Hierarchy
ANSI
American National Standards Institute
API
Application Programming Interface
ATO
Assemble-to-Order
BG
BOM Genérico
BOM
Bill of Materials
CAD
Computer Aided Design
CCC
Carne Cocida Congelada
CCE
Carne Cocida Enlatada
CG
Componente Genérico
CODP
Customer Order Decoupling Point
COOBOM Complex Object Oriented BOM
CORBA
Common Object Request Broker Architecture
CPC
Collaborative Product Commerce
CPD
Collaborative Product Development
CRC
Class, Responsability, Collaboration
DCOM
Distributed Component Object Model
DL
Description Logics
DOS
Distribution-on-Stock
DTD
Document Type Definition
DTO
Data Transfer Object
EE
Estructura de Elemento
EG
Ensamblado intermedio Genérico
EI
Ensamblado Intermedio
EJB
Enterprise Java Beans
ERP
Enterprise Requirement Planning
ETO
Engineer-to-Order
FP
Familia de Productos
GQS
Global Query Service
HTML
HyperText Markup Language
HTTP
HyperText Transfer Protocol
XXV
______________________________________________________________________ Lista de Siglas
IPPD
Integrated Process and Product Design
ISO
International Standards Organization
J2EE
Java 2 Enterprise Edition
JME
Jerarquía de Modelos de Elemento
JMS
Java Message Service
JSP
Java Server Page
LPO
Lógica de Primer Orden
LQS
Local Query Service
ME
Modelo de Elemento
ME
Material de Empaque
MP
Materia Prima
MPS
Master Planning Schedule
MRP
Material Requirement Planning
MTO
Make-to-Order
MTS
Make-to-Stock
NAICs
North American Industry Classification System
OOBOM
Object Oriented Bill of Materials
OPC
Orientada al Proceso
OPD
Orientada al Producto
OR
Orientada a los Recursos
OWL
Ontology Web Language
PCP
Planeamiento y Control de la Producciòn
PDM
Product Data Management
PF
Producto Final
PG
Producto Genérico
PIS
Product Information Systems
PLM
Product Lifecycle Management
PP
Producto Primario
PRONTO PRoduct ONTOlogy
PSL
Process Specification Language
PT
Producto Terminado
RDF
Resource Description Framework
RNTD
RosettaNet
SCOR
Supply Chain Operations Reference Model
SDBB
Sistema de Definiciòn de BOMs Base
SE
Semielaborado
SEP
Sistema de Especificaciòn de Productos
SGBP
Sistema de generaciòn de BOMs
XXVI
______________________________________________________________________ Lista de Siglas
SH
Structrual Hierarchy
STEP
Standard for teh Exchange of Product Model Data
STN
State Task Network
SUMO
Suggested Upper Level Ontology
SWRL
Semantic Web Rule Language
TIC
Tecnología de la Información y las Comunicaciones
TOVE
TOronto Virtual Enterprise
UML
Unified Modeling Language
UNSPSC
United Nations Standard Products and Services Code
URI
Uniform Resource Identifier
W3C
World Wide Web Consortium
XML
eXtensible Markup Language
XXVII
I. EL MODELO DE PRODUCTOS EN LAS ORGANIZACIONES
INDUSTRIALES
I.1. INTRODUCCIÓN
Desde los orígenes de la humanidad, los cambios tecnológicos fueron modificando
las sociedades donde éstos ocurrieron, no sólo en las formas de vida y de trabajo del
hombre como individuo sino, y principalmente, en la manera de producir y comercializar.
Esta tendencia se hizo más evidente a partir de la revolución industrial, acentuándose con
los cambios que se asocian a la tecnología de la información. Estos últimos cambios
permitieron la automatización de tareas y procesos dentro de las empresas e industrias,
llevando a la creación de sistemas de producción más eficientes; lo cual, a su vez, requirió
que los sistemas de información que dan soporte a los sistemas productivos sean más
complejos.
En la actualidad, es cada vez mayor el número de empresas que desean integrar
todas sus funciones y departamentos a través de un único sistema que sirva al conjunto de
necesidades que cada una de estas áreas plantea. Esta integración requiere nuevas
estructuras de datos para poder almacenar toda la información relevante necesaria para
llevar a cabo las funciones en las diferentes áreas. Una de las fuentes fundamentales para
una organización productiva es el modelo de productos, el cual mantiene información
referente a la manera de manufacturar los productos que ofrece una organización, así como
a su gestión administrativa, logística, datos de marketing, etc.
Dicha fuente de información, denominada modelo de productos, es el objeto de
estudio de la presente Tesis doctoral, la cual pretende introducir al lector en la problemática
relativa a este dominio del conocimiento, para posteriormente proponer un modelo de
productos que tenga en cuenta los requerimientos de información que el entorno actual
impone sobre las organizaciones industriales y que podría ser usado para lograr la
integración de las funciones de una empresa.
El presente capítulo introduce el concepto de modelo de productos, los distintos
enfoques que se le han dado a la representación del mismo, la influencia que las
tecnologías de la información y de las comunicaciones han tenido sobre dicho modelo, así
como los nuevos requerimientos que dichas tecnologías le imponen.
1
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
I.2. INFORMACIÓN DE PRODUCTOS DURANTE SU CICLO DE VIDA
La información relativa a productos es uno de los pilares de la integración de los procesos
de negocio de una industria de manufactura. Las áreas de una organización usan y
producen datos de productos en sus actividades diarias y en cada etapa del ciclo de vida del
producto.
Una pregunta que surge en este punto es “¿qué se entiende por ciclo de vida de un
producto?”. No está muy claro cuales son las fases que involucra, ya que, según Persson y
colab. (2002), el término es usado para identificar cuatro ciclos de vida diferentes:
Un ciclo de vida orientado al mercado que incluye las diferentes fases por las que
pasa un producto desde su aparición hasta su desaparición o decadencia. Éstas son:
lanzamiento o introducción, crecimiento, madurez, declinación y retiro.
El ciclo de vida que corresponde a las partes que ingresan en la cadena de
suministro y se mueven por ella desde los proveedores hasta los clientes.
El ciclo de vida de un producto particular que es producido, comprado, usado,
desechado o reciclado.
El ciclo de vida de la información que define el producto: creada, modificada,
eliminada.
Los dos primeros ciclos mencionados coinciden, en gran medida, con lo que
Saaksvuori e Immonen (2005) proponen como proceso de producto y proceso de entrega de
orden. Estos autores identifican dos grandes etapas dentro del primer proceso: introducción
de un nuevo producto (INP) y mantenimiento del mismo. En el segundo proceso,
consideran: la venta (en la que se da la generación de la orden de producción),
abastecimiento, producción, entrega y mantenimiento/servicio posventa. Estos procesos se
muestran en la Figura I.1 junto con las fases de los tres primeros ciclos de vida propuestos
por Persson y colab. (2002). Una línea punteada representa el ciclo de vida de un producto
individual, los prismas más oscuros representan el ciclo de vida orientado al mercado y los
más claros corresponden a las etapas del producto dentro de la cadena de suministro.
Los procesos de producto y de entrega de orden están fuertemente ligados por
medio de la información que se trasmite desde el primero al segundo proceso. Al inicio del
ciclo de vida, la información acerca de los componentes y las partes que deben ser provistas
es entregada desde el departamento de diseño al de compras. La estructura del producto y
sus reglas de configuración deben ser comunicadas al área de ventas y hacia el final de la
etapa de INP, el diseño del producto es enviado al sector de producción.
2
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
Introducción
Crecimiento
INP
Madurez
Retiro
Declinación
Proceso de mantenimiento de producto
Venta
Abastecimiento
Producción
Entrega
Mantenimiento
Proceso de entrega de producto
Figura I.1. Ciclos de vida de un producto
Asimismo, durante la fase de mantenimiento del producto, los cambios efectuados al
diseño son comunicados a producción. Además de la información que se maneja entre estos
dos procesos, durante el ciclo de vida de un producto, las diferentes funciones de la
organización producen y consumen información relacionada con el mismo. A continuación
se presentan algunas funciones y su relación con los datos de productos.
El área de desarrollo e ingeniería, que puede ser denominada de diferente forma en
distintas organizaciones, es el área en la que surge la información de productos. De hecho,
previo a su introducción en el mercado, un producto debe ser desarrollado, lo cual en
algunos tipos de industrias da lugar a complejos ciclos de desarrollo que van desde ideas
preliminares, pasando por diversos prototipos, a numerosos y complejos tests anteriores a
su lanzamiento al mercado. Los diseñadores generan el diseño de un producto, su esquema
de fabricación y/o ensamblado, las listas de las partes requeridas para su fabricación e
información de testeo entre otras. La administración de la información acerca de las
estructuras de productos, sus procesos de manufactura y de los cambios efectuados a los
mismos es esencial en un entorno de planificación avanzado.
La función de administración de materiales (AM) se vincula con el abastecimiento de
materiales (materia prima, componentes e insumos) desde que surge un requerimiento de
abastecimiento originado en necesidades productivas hasta que se reciben los materiales.
Con relación a los productos, esta función necesita, entre otros, datos tales como
requerimientos específicos (especificación de producto, cantidad, fecha), niveles de
inventario, información de tipo logístico, de compras, etc. El abastecimiento se inicia con la
planificación de requerimientos de materiales, la cual se lleva a cabo mediante sistemas
MRP (Materials Requirement Planning), los cuales necesitan de información de demanda
para los próximos períodos, niveles de stock de seguridad, de inventario al momento de la
planificación, etc. Sin embargo, la información más importante, necesaria para la
3
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
planificación de requerimientos de materiales, es el resultado del cálculo de las cantidades
de materias primas y productos semielaborados que se necesitan para manufacturar una
unidad de cada producto final. Este cálculo es conocido como explosión de
requerimientos de materiales y tiene como fuente de información más importante la lista
de materiales o BOM (Bill of Materials) que indica todas las partes componentes requeridas
para la manufactura de un determinado producto y en qué cantidad se requiere cada uno de
estos componentes. La función de compras también interviene en la AM, y utiliza datos de
las cantidades requeridas, niveles actuales en stock de cada producto, datos acerca de
puntos de re-orden, stock de seguridad, proveedores para cada producto, así como tiempos
de entrega y precios asociados a cada uno de estos proveedores.
Otra función altamente relacionada con la información de productos es la de
Planeamiento y Control de la Producción (PCP). Los datos básicos para la ejecución de esta
función incluyen el BOM, las rutas de producción, así como las máquinas y/o centros de
trabajos donde pueden ejecutarse las operaciones indicadas en dichas rutas. Una ruta de
producción es una descripción del flujo del proceso de fabricación para una determinada
parte (producto). El área de PCP también utiliza información sobre las demandas de
productos finales y los requerimientos de producción que esta demanda implica.
La información de productos es, además, importante como soporte a la función de
ventas y marketing en empresas donde los productos son vendidos en configuraciones que
se ajustan a los pedidos específicos del cliente. De esta manera, es necesario contar con
información acerca de las estructuras de productos y las reglas de configuración para éstos,
que definen cómo puede modificarse la estructura del producto (si fuera posible) y
determinan la existencia o no de opciones para las partes componentes y cuáles serían
éstas. En cambio, para las actividades de mantenimiento de bienes de capital (aviones,
automóviles, etc.) o servicios posventa no sólo es importante la información relativa a la
estructura del producto, sino también, las versiones de productos y los repuestos que se
proveen para cada uno.
I.2.1. Sistemas que manejan la información de productos
La administración de datos de productos no es una actividad nueva. Ya en la década
del 30, la empresa Ericsson establece un estándar para la identificación de documentos y
sus productos (Persson y colab., 2002). Obviamente, los documentos y dibujos eran
almacenados en papel. En consecuencia, la búsqueda de un documento y la determinación
de su última versión eran tareas muy complicadas. A medida que la tecnología evolucionó,
cada vez más datos de productos se generaron de manera electrónica. Estos documentos
digitales empezaron a ser almacenados en servidores, y surgiendo así, la necesidad de
tener sistemas que administren estos archivos eficientemente.
4
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
Pasar de diseñar productos en forma manual a realizarlo en forma automática a
través de sistemas de diseño asistido por computadoras (CAD), implicó una explosión en el
volumen de archivos electrónicos manejados por el área de ingeniería y diseño en las
organizaciones industriales. En consecuencia, se incrementó en gran manera la dificultad en
la administración de tales archivos. Así, los sistemas de administración de datos de
productos (PDM – Product Data Management) surgieron como respuesta a esta
problemática y se enfocaron, originalmente, en la provisión de almacenamiento para estos
datos dentro del área de ingeniería. Junto con la evolución de las industrias, el alcance de
los PDMs se expandió a otras áreas organizacionales.
Al inicio de los años 90, las industrias demandaron aplicaciones, más sofisticadas
capaces de considerar aspectos relacionados con la administración de las estructuras de los
productos y su configuración. Es entonces que los sistemas PDM comenzaron a incorporar
nuevas capacidades para cumplir con estos requerimientos. Rápidamente se extendieron
las competencias de estos sistemas más allá de las áreas de diseño e ingeniería, surgiendo
así sistemas capaces de administrar los datos de productos a lo largo de todas las etapas
de su ciclo de vida, los que son conocidos como sistemas PLM (Product Lifecycle
Management).
Actualmente, los sistemas PDM/PLM comerciales existentes brindan básicamente las
siguientes funcionalidades, las cuales se esquematizan en la Figura I.2:
Administración de documentos y datos almacenados: permite almacenar,
recuperar y compartir documentos de manera segura, llevando un control de
las versiones.
Administración de procesos y flujos de materiales: permite la definición de
procesos y flujos de materiales en procesos de manufactura y provee los
mecanismos para asegurar el cumplimiento de los mismos.
Administración de las estructuras de productos: brinda soporte para la
definición y manejo de la estructura de los productos.
Administración de partes y componentes: permite la carga y el
mantenimiento de la información de las partes componentes de los distintos
productos.
Administración de la configuración: facilita la definición y gestión de las
distintas configuraciones de un producto; permitiendo que los productos sean
configurados de acuerdo a los deseos de los clientes.
5
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
Administración de
procesos y flujos
Administración de
de materiales
datos y
documentos
Administración de
Administración de la
partes y
estructura de
componentes
productos
Administración
de la
configuración
Figura I.2. Principales módulos de un sistema PDM
I.2.2. Estructura de productos
La estructura de productos forma parte del núcleo central de los sistemas PDM/PLM.
Muchas de las funciones de los sistemas de gestión de productos actuales se basan en el
empleo de la estructura de productos y de los ítems de información que se encuentran
asociados a ella.
Ya en los años 70, las bases de datos eran usadas para almacenar información
acerca de la estructura de productos, la cual era empleada por las plantas de manufactura
durante la fabricación de dichos productos. Por esa razón cada empresa desarrolló sus
propias aplicaciones de bases de datos, las cuales tenían como responsable de la carga de
datos al área de diseño e ingeniería. Por su parte, el área de manufactura también reveló
necesidades de información de productos que, como ya se explicó, no son las mismas que
las del sector de diseño, razón por la cual comenzó a tener sus propias bases de datos.
Hacia el final de los años 80 aparecieron los primeros sistemas PDM comerciales como un
intento para unificar la representación de datos de productos, pero éstos emplearon una
estructura de productos similar a la que se utiliza en el área de manufactura, dejando de
lado otras vistas.
Sin embargo cabe la pregunta, ¿qué se entiende por estructura de productos? La
estructura de productos es un grafo que representa la forma en la cual se agregan (o
desagregan) partes para dar lugar al producto cuya estructura se modela. El concepto de
parte, el cual se muestra en la Figura I.3, abstrae los conceptos de Materia Prima,
Ensamblado, Componente y Producto Terminado.
Un Componente o Materia Prima corresponde al nivel más bajo de la jerarquía
(Persson y colab. 2002), Una materia prima representa un material o producto básico
requerido para la manufactura de un componente, ensamblado o producto terminado que,
en general, se adquiere a un proveedor y no es producido en la organización. Un
componente es una parte confeccionada con un único material. Un ensamblado, a su vez,
6
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
consiste de un conjunto de otros ensamblados y/o componentes. Finalmente, un producto
terminado es aquél que no participa en la fabricación de otros productos sino que se vende
como tal a los clientes. Dada su ubicación en diferentes etapas en el proceso de
manufactura de un producto, estos conceptos tienen diferentes requerimientos de
información.
PARTE
Materia
Prima
Ensamblado Componente
Producto
Terminado
Figura I.3. Especialización del concepto de parte
Estructura de Productos. Formas de Representación
La estructura de productos tiene su origen en el denominado Bill of Materials (BOM)
o lista de materiales, que indica para cada producto, las partes (ensamblados intermedios y
materias primas) necesarias para su fabricación. Es conocido también bajo el nombre de
receta o especificación, aunque el nombre de receta en plantas batch se refiere a una
información más compleja que también incluye instrucciones relativas al proceso de
manufactura.
Las relaciones dentro del BOM definen una correspondencia entre un producto,
referenciado como padre, y cada una de las partes que son directamente utilizadas para su
producción, las que se denominan componentes. Estas relaciones de composición son
transitivas, lo cual implica que si E1 es un componente de P1, y M1 es un componente de
E1, entonces M1 es también un componente de P1. Los componentes se listan indicando la
cantidad necesaria de cada uno de ellos para obtener una unidad del padre. Dicha cantidad
suele denominarse cantidad de composición y puede indicar un número natural, en el caso
de productos de manufactura discreta, o uno real, para los productos generados en las
industrias de procesos. Puede ser necesario, además, especificar la unidad de medida de
dicha cantidad.
El BOM puede representarse como un grafo dirigido sin ciclos en el cual los nodos
son las diferentes partes de un producto y los arcos son las relaciones estructurales entre
estas partes. Esta forma de representación es mostrada en la Figura I.4, en la que se puede
apreciar que el producto P1 se fabrica mediante la materia prima M1, el componente C1 y el
ensamblado intermedio E1. Este último, a su vez, se obtiene de dos materias primas, M3 y
M4. Los rótulos que se asocian a los arcos entre los nodos, representan las
correspondientes cantidades de composición y, en este ejemplo, indican que se necesitan r3
unidades de E1, r1 unidades de M1 y r2 unidades de C1 para fabricar una unidad de P1.
7
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
P1
r3
r2
r1
M1
E1
C1
r4
r5
Mi
Materia Prima i
Ci
Componente i
Pi
Producto Teminado
E1
Ensamblado Intermedio
r6
Relación de composición
M2
M3
M4
ri
Cantidad de composición
Figura I.4. Bill of Materials de un producto final
Esta representación se usa para, calcular las necesidades de ensamblados, partes
componentes (obtenidas internamente a partir de las materias primas o encargadas a
terceras empresas) y materias primas (adquiridas a proveedores) que se requieren para
producir una determinada cantidad de producto final. En otras palabras, la información que
brinda el BOM es necesaria para realizar una explosión de requerimientos. Además, la
estructura de información del BOM, con datos adicionales, puede utilizarse en diferentes
actividades, tales como la estimación de costos o de la fecha de entrega esperada, o para
determinar las cantidades de componentes requeridos para cumplimentar una determinada
orden de cliente, etc.
La estructura del BOM tiene dos elementos importantes: i) su arquitectura y ii) la
cantidad de niveles que posee. La primera corresponde a cómo se organiza el BOM; la
segunda, en cambio, indica la profundidad del árbol. Los distintos niveles se determinan por
las interrupciones en el flujo de producción, que marcan la obtención de materiales
mantenidos en inventario en los puntos intermedios del proceso productivo. La tendencia
actual es la eliminación de la mayor cantidad posible de puntos de almacenamiento de
material en proceso, llevando a la definición de BOMs con menos niveles (achatados). Si en
la estructura presentada en la Figura I.4 se eliminaran el componente C1 y el ensamblado
E1, se obtendría una estructura más aplanada de P1, tal como se muestra en la Figura I.5.
Sin embargo, ello requiere de procesos de manufactura altamente sincronizados para los
cuales no sea necesario contar con stock de los productos intermedios C1 y E1.
P1
r1
M1
r2 *r4
M2
r3 *r5
M3
r3 *r6
M4
Mi
Materia Prima i
Ci
Componente i
Pi
Producto Teminado
E1
Ensamblado Intermedio
ri
Relación de composición
Cantidad de composición
Figura I.5. Bill of Materials aplanado de un producto final
8
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
Cabe destacar que el BOM presentado a modo de ejemplo en la Figura I.4 pertenece
al tipo multinivel. En este caso, los BOMs suelen representarse gráficamente como árboles,
según lo descrito, o como listados indentados de materiales, tal cual se repesenta en la
Tabla I.1
Tabla I.1: Listado indentado de componentes del producto P1
Nivel
1
1
.2
1
.2
.2
Componente Unidades
requeridas
M1
r1
C1
r2
M2
r4
E1
r3
M3
r5
M4
r6
Unidad de medida
Unidad
Unidad
Unidad
Unidad
Unidad
Unidad
Sin embargo, no todas las empresas mantienen BOMs de tipo multinivel. Es posible
mantener BOMs de un único nivel y obtener los de tipo multinivel a través del
encadenamiento de árboles mononivel. Por ejemplo, el árbol presentado en la Figura I.4,
puede obtenerse encadenando los árboles de un nivel correspondientes a P1, C1 y E1, los
cuales se presentan en la Figura I.6 y en las Tablas I.2 a I.4. En las tablas mencionadas, se
ha eliminado la primera columna debido a que, con esta representación, todos los
componentes están en el mismo nivel.
P1
r1
M1
r3
r2
C1
E1
E1
C1
r5
r4
r6
Mi
Materia Prima i
Ci
Componente i
Pi
Producto Teminado
E1
Ensamblado Intermedio
M2
M3
Relación de composición
M4
ri
Cantidad de composición
Figura I.6. BOMs de un único nivel
Tabla I.2: Listado de componentes del producto P1
Componente
M1
C1
E1
Unidades requeridas
r1
r2
r3
Unidad de medida
Unidad
Unidad
Unidad
9
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
Tabla I.3: Listado de componentes del producto C1
Componente
M2
Unidades requeridas
R4
Unidad de medida
Unidad
Tabla I.4: Listado de componentes del producto E1
Componente
M3
M4
Unidades requeridas
r5
r6
Unidad de medida
Unidad
Unidad
Durante el desarrollo de este capítulo y el siguiente, se utilizarán la representación
gráfica y las tablas que se introdujeron en esta sección cada vez que sea necesario
ejemplificar la estructura de algún producto.
Estructura de Productos. Aspectos a contemplar.
Existen diferentes criterios para describir un producto en términos de sus partes
constitutivas. Por ejemplo, la función de planificación de requerimientos de materiales (MRP)
usa la estructura de productos de manera intensiva para explotar los requerimientos de
productos finales en necesidades de ensamblados intermedios y materias primas, de
manera de poder enviar las órdenes de trabajos a los distintos departamentos de producción
y las órdenes de compra hacia el departamento compras. De esta manera, la estructura de
productos que soporta esta función debe ser consistente con la manera en que los
productos son manufacturados y contener además información de los “lead times” de
compras y manufactura. En cambio, la función que genera el Plan Maestro de Producción
(MPS – Master Planning Schedule) no necesita información tan detallada y requiere
información de productos en términos de cómo son vendidos en lugar de cómo son
manufacturados. Otras funciones dentro del departamento de planificación y control de la
producción, como el pronóstico de demandas, utilizan diferentes datos del producto, por
ejemplo factores de alisado y valores de pronósticos previos. Estas diferentes necesidades
de información llevan en la práctica a una situación en la que muchas áreas funcionales han
desarrollado sus propios modelos de productos, acordes a sus requerimientos particulares.
Como mencionan Vollman y colab. (1992), una regla de oro es que cada empresa debe
tener un único BOM que sea mantenido como una unidad y, a su vez, permita satisfacer
todas las necesidades de información de la organización.
Una situación análoga, pero tal vez más crítica, ocurre cuando varias organizaciones
están involucradas en el ciclo de desarrollo y manufactura de un producto (por ejemplo, por
tercerización de alguna de estas actividades) o en el proceso de abastecimiento y
distribución (por tercerización de actividades logísticas). En estos casos, cada empresa
requiere porciones de la información del producto de acuerdo al rol que juega en el proceso
10
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
productivo o logístico. De esta manera, el modelo de productos debe permitir la descripción
de los productos considerando los requerimientos de cada uno de los participantes de la
cadena de suministros, más allá de las fronteras de una única organización.
Por otra parte, un análisis de las estructuras de productos en diferentes empresas
productivas revela la existencia de distintos tipos de estructuras, los cuales se presentan
esquemáticamente en la Figura I.7. El primer caso, identificado como (a), corresponde a
productos que son obtenidos por medio del ensamblado o la combinación de partes
constitutivas, que pueden ser materias primas u otros productos intermedios los cuales, a su
vez, son obtenidos mediante el ensamblado o combinación de otros componentes.
Una situación opuesta es mostrada en la Figura I.7, caso (b). En ese ejemplo
genérico, los productos finales P1, P2, P3 y P4 se obtienen aplicando un proceso de
desagregación o descomposición de una materia prima no atómica M. Un ejemplo simple de
esta situación puede encontrarse en la industria láctea donde los productos crema y leche
descremada pueden obtenerse a partir de la leche entera. En casos como éste, las
estructuras de productos son denominadas de descomposición o desensamblado.
Finalmente, el tercer caso identificado como (c), representa una estructura híbrida o
compleja que
combina los
dos tipos mencionados previamente:
composición
y
descomposición. Puede observarse en la figura que el producto E8 es un producto final
obtenido mediante la descomposición de la materia prima M8. Parte de su producción es
vendida a los clientes, mientras que el resto participa como materia prima en la estructura de
composición asociada al producto P5.
P1
P1
P3
P2
P4
0.25
0.25
1
E1
2
1
0.5
E2
0.25
3
M1
2
M2
0.25
E4
E3
M3
0.25
1
M
M4
P5
(a)
1
(b)
1
2
E7
1
M3
M1
2
E8
0.25
1
M4
P4
0.5
1
M8
E10
0.25
1
(c)
Mi
Materia Prima i
Pi
Producto Teminado i
Ei
Ensamblado Intermedio i
Operación de ensamblado
Operación de desensamblado
Figura I.7. Diferentes tipos de estructuras de productos
11
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
Durante el análisis de la literatura existente, se encontraron solamente dos enfoques
que identifican el problema de la representación de productos que poseen estructuras
complejas. Éstos fueron propuestos por Taleb y Gupta (1997) y por Carboneras y colab.
(1992). Este último trabajo también trata otro aspecto que debe tenerse en cuenta al
momento de definir un modelo para la representación de la estructura de productos, el cual
se refiere a la existencia de estructuras alternativas para un producto dado.
Aunque usualmente un producto tiene sólo una estructura, existen ciertas industrias
donde los productos tienen más de una. En la industria alimenticia o química, por ejemplo,
existen diferentes recetas alternativas para fabricar algunos productos. Cada una de ellas
establece una estructura diferente para el producto en cuestión.
Un producto tiene asociadas diferentes estructuras cuando: i) es posible obtenerlo
por medio de diferentes materiales y/u operaciones; o ii) distintas áreas de una organización
requieren diferentes vistas de dicho producto. La Figura I.8 presenta un ejemplo de un
producto P1 que tiene estructuras alternativas. Las estructuras indicadas como (a) y (b)
representan el uso de las estructuras alternativas para indicar diferentes recetas de
producción. Las estructuras mencionadas indican que es posible fabricar P1 de dos
maneras diferentes:
i)
Según lo indicado por (a): ensamblando 2 unidades de M1, 2 unidades de E1
y 1 unidad de E2; o
ii) Según lo indicado por (b): ensamblando 1 unidad de E3 y 1 unidad de E2.
P1
P1
1
2
1
1
2
E3
E1
E2
2
E2
4
3
2
E4
1
1
M1
2
2
M2
M3
M4
M6
1
1
M1
M3
M4
2
M2
(a)
(b)
P1
2
4
M1
4
3
M2
M6
(c)
M3
2
M4
Mi
Materia Prima i
Pi
Producto Teminado i
Ei
Ensamblado Intermedio i
Operación de ensamblado
Operación de desensamblado
Figura I.8: Estructuras alternativas
12
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
Como un ejemplo del uso de estructuras alternativas para representar distintas
vistas, considere los casos (b) y (c) los cuales representan las vistas que tienen de P1 el
área de manufactura y de planificación, respectivamente.
Cualquiera sea el tipo de estructura y la cantidad de estructuras alternativas que un
producto tenga asociadas, las mismas deben ser modeladas y capturadas de alguna
manera. El BOM es el método tradicionalmente usado para representar la composición de
un producto en términos de sus partes componentes. Esta representación es la que se ha
elegido para expresar las estructuras de productos en los dos primeros capítulos de esta
Tesis.
I.3. INFLUENCIA DE LAS TECNOLOGÍAS DE LA INFORMACIÓN Y DE LAS COMUNICACIONES
EN EL MODELO DE PRODUCTOS
Los avances de las últimas décadas en las tecnologías de la información y de las
comunicaciones (TICs) han disparado un gran número de aplicaciones que involucran la
cooperación entre unidades organizacionales (departamentos, áreas funcionales, empresas,
etc.) vinculadas por algún tipo de red. Por un lado, los desarrollos de Internet posibilitaron la
implementación de paradigmas ya existentes que se encontraban esperando que se dieran
las condiciones propicias, y por otro, motivaron el desarrollo de nuevos conceptos tales
como e-commerce, e-business, empresas virtuales, comunidades virtuales, e-manufacturing,
entre otros. Una de las tendencias subyacentes en el área de investigación y desarrollo de
las TICs pone el foco en los modelos, protocolos y mecanismos para soportar la
colaboración entre diferentes entidades en entornos distribuidos. (Zhou y colab., 2003)
Por otra parte, los avances tecnológicos sumados a un mercado competitivo y
globalizado han ocasionado un cambio de paradigma en el mercado reinante en las
industrias de manufactura. En la actualidad, los clientes demandan productos con precios
bajos, alta calidad y de entrega inmediata; pero también quieren que éstos se adapten a sus
necesidades particulares. Este fenómeno conocido como “mass customization”, necesita
empresas flexibles, capaces de responder rápidamente a los cambios y requiere, por ende,
que cada empresa comparta un modelo de datos común en todas las etapas del ciclo de
vida del producto. Para lograrlo es importante contar con una representación uniforme de
la información de los productos, que posibilite la aplicación de la ingeniería concurrente y
cualquier otra tecnología de manufactura ágil. El modelo de productos debería ser utilizado
en las distintas unidades organizacionales que requieren diferentes vistas de la información
asociada a los productos.
En la práctica, sin embargo, esto no ocurre y cada unidad funcional desarrolla su
propio modelo de productos asociado a las aplicaciones que debe soportar (marketing,
planificación, producción, scheduling, etc.). Esto conlleva a la duplicación de información, a
13
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
la posibilidad de incurrir en inconsistencias, y dificulta enormemente las actualizaciones e
incorporación de modificaciones, problemas que han empezado a tenerse en cuenta en los
primitivos modelos de productos que incorporan los sistemas ERP (“Enterprise Resource
Planning”) y en los nuevos sistemas del tipo PDM (“Product Data Management”). Por otra
parte, la influencia de la demanda y la necesidad de ofrecer continuamente nuevas
alternativas al mercado, hace que el número de variantes de un mismo producto sea
extremadamente alto para poder manejarlo con los sistemas de información de productos
tradicionales (Scheer, 1998).
La personalización de los productos que implica el fenómeno de “mass
customization” lleva a un incremento exponencial en el número de variantes de un mismo
producto. Así, mientras antes existían empresas que fabricaban cientos o miles de
productos iguales para ser vendidos a todos sus clientes, ahora éstas pueden llegar a
producir una variante de dicho producto para cada uno de sus clientes. Esta situación
implica un considerable incremento en el volumen de información almacenada por los
modelos de productos tradicionales. Debe resaltarse que los modelos tradicionales
consideran las distintas variantes (productos similares que difieren mínimamente) como
productos distintos y, en consecuencia, gran parte de la información es redundante y no está
exenta de inconvenientes en cuanto a espacio, eficiencia y consistencia, asociados a la
duplicación de información.
Los puntos antes mencionados incorporan otra dimensión si el problema de
modelado de productos se sitúa en el contexto de las nuevas relaciones inter-empresariales.
La asociación de empresas configura organizaciones de producción virtuales, las cuales
poseen ciclos de vida de productos totalmente diferentes y presentan nuevas exigencias
acerca del acceso y control de la información de productos, requerimientos que no eran
considerados previamente. La implementación de conceptos avanzados de manufactura
depende en gran medida de la habilidad de una empresa para compartir información con
sus proveedores, clientes y socios de manera rápida, eficiente, consistente y confiable.
La problemática del manejo de información de productos excede el enfoque
tradicional que segmentaba la misma asociándola fuertemente a las aplicaciones (diseño,
producción, planificación, gestión de depósitos, ventas, etc.). Es por ello que los sistemas de
información tradicionales tienen serias dificultades para una eficiente representación de los
productos actuales. Los esfuerzos de investigación en el área están dirigidos al problema de
representar la información requerida para todo el ciclo de vida del producto, no ya para
planificar la producción de una determinada planta de la empresa, sino para administrar
ciclos de desarrollo de productos donde participan distintas empresas (debido a
tercerizaciones) como así también cadenas de suministro extendidas donde intervienen
clientes, proveedores, operadores logísticos, etc.
14
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
Una de las consecuencias del competitivo contexto actual ha sido el acortamiento del
ciclo de vida de los productos, no sólo en lo que respecta al proceso de diseño de los
mismos, ya que éstos deben salir al mercado cada vez más rápido, sino también en lo
relativo a la validez del diseño. En consecuencia, van surgiendo versiones de productos más
frecuentemente, junto con sus correspondientes representaciones BOM. Algunas de éstas
serán válidas para productos fabricados y vendidos hasta una determinada fecha, mientras
que otras serán válidas para los nuevos productos que se fabriquen a partir de esa fecha.
Este aspecto impone un nuevo requerimiento sobre los sistemas de representación de datos
de productos: la gestión de versiones de productos. De los enfoques presentados en la
literatura, sólo el de Männistö (2000) propone un modelo conceptual para la evolución de las
familias de productos que tiene en cuenta las múltiples versiones que van surgiendo para un
producto a lo largo de su ciclo de vida. La gestión de versiones es realmente crítica cuando
los productos no son bienes de consumo, sino que prestan determinada función (son autos,
locomotoras, aviones, etc.) y poseen diferentes exigencias de mantenimiento dependiendo
del tipo de componentes que posean.
Para ser exitosa en el altamente competitivo y globalizado ambiente de manufactura
de hoy en día, una compañía debe ser capaz de entregar y soportar los productos que sus
clientes demandan en el momento especificado por éstos. Tales requerimientos imponen
una gran presión sobre la función de ingeniería para mejorar la calidad de los productos y
reducir los tiempos de preparación y entrega (“lead times”). Un camino para lograrlo, es
incrementar la productividad de las actividades de ingeniería y mejorar la coordinación entre
ellas, a través, por ejemplo, de la Ingeniería Concurrente. Ésta ha sido reconocida como una
filosofía y metodología de negocios para la integración de todos los aspectos del ciclo de
vida de los productos dentro de la etapa de diseño, para lo cual se requiere que toda la
empresa comparta un modelo común de datos de productos (Gu y Chan, 1995). Con esto no
se pide que el repositorio de información se encuentre centralizado, sino que el modelo
conceptual sea compartido por todos los involucrados, o para expresarlo de otra manera, se
necesita una integración semántica de este modelo de datos.
En una empresa de producción industrial, el área de manufactura, con su inherente
complejidad, es una componente crítica. La información de productos y procesos es un
elemento clave para las operaciones de manufactura. Los datos compartidos y el
requerimiento de encontrar información confiable de forma rápida dentro de las industrias y
en las relaciones fabricante-cliente han hecho surgir un conjunto de propuestas de
metodologías y arquitecturas orientadas a encontrar una solución a la necesidad de reducir
tiempos de entrega y mejorar la coordinación de actividades (Gonçalves y Scherer, 1999).
En esta dirección se desarrollaron los primeros sistemas PDM para tratar de
responder a los requerimientos de integración de los datos de productos. Los sistemas PDM
15
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
permiten que todos los integrantes de las diferentes áreas de una organización compartan
un modelo de productos común. Estos sistemas tradicionales facilitan la comunicación interorganización local pero no brindan soporte a la cooperación global. Por tal motivo, se
observa el surgimiento de sistemas PDM que buscan superar este obstáculo a través de la
implementación de arquitecturas distribuidas empleando, en muchos casos, tecnologías
Web.
Liu y Xiu (2001) propusieron la aplicación de una arquitectura de tres capas (interface
+ procesamiento lógico + almacenamiento de datos) para la implementación de sistemas
PDMs basados en Web. Mervyn y colab. (2004) presentaron un enfoque para el desarrollo
de aplicaciones distribuidas para el área de manufactura que soporta el desarrollo integrado
de procesos y productos (Integrated Process and Product Design, IPPD), el cual plantea el
uso de una capa común a todas las aplicaciones de manufactura que se distribuye entre un
servidor de modelado y los clientes. La portabilidad de esta capa se logra empleando Java
para el código y XML para los datos.
Abramovici y Gerhard (2000) formularon un sistema PDM basado en Web que
pretende la integración de diferentes PDM locales, a través de la generación de módulos
“add-on” que se incorporan a los sistemas que cada área o departamento está utilizando. El
problema de este enfoque es que no plantea una integración a nivel de modelo de datos,
sino más bien a nivel de interfaz de usuario. Por otra parte, Burkett (2001) propuso la
utilización de XML para la definición de un lenguaje de intercambio de datos de productos,
basado en el Standard STEP (STEP 1991).
Estas propuestas expresan, de cierto modo, las posibilidades que brindan las
tecnologías de la información y las comunicaciones (TICs), en cuanto a disponer de
múltiples medios de comunicación, por lo que son vistas como una promesa de integración
de los procesos de negocios. La realidad, sin embargo, ha planteado un escenario con
nuevas problemáticas vinculadas con las posibilidades emergentes de la tecnología
disponible. Los datos, frecuentemente se encuentran almacenados, y muchas veces
duplicados en varios sitios físicamente distintos; situación que en algunas ocasiones hace
difícil determinar cuál es la información válida y cual no. Los sistemas PDM basados en Web
no están exentos a esta problemática.
Si bien Internet posibilita la comunicación global, rompiendo barreras geográficas y
permitiendo que todos los participantes en una cadena de suministro compartan
información, introduce algunos inconvenientes de tipo semántico. Por ejemplo, puede darse
la ocurrencia de diferentes términos que representan el mismo objeto en distintos sistemas
o, por el contrario, la existencia de un mismo término que representa conceptos totalmente
diferentes.
16
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
Horrocks y colab. (2001) plantearon la necesidad de una integración inteligente de
los sistemas de información a través de tres niveles: técnico, sintáctico y semántico. Internet
y las tecnologías Web proveen respuesta a la integración de los dos primeros niveles, en
tanto la integración semántica está siendo objeto de investigación desde hace unos años.
Los esfuerzos están enfocados en el desarrollo de la Web Semántica (Bernes-Lee y colab.,
2001), si bien se reconoce que esta tecnología no es una solución total y definitiva al
problema de integración semántica. La Web Semántica es la siguiente generación de la
Web, con una infraestructura bien establecida para presentar información de una manera
precisa, entendible por humanos y procesable por máquinas. Permite el acceso a los
recursos Web por su semántica y no sólo por su sintaxis, así como la inferencia de nuevo
conocimiento a partir del existente. Por otra parte, abrirá la posibilidad de tener acceso
inteligente a información heterogénea y distribuida, posibilitando que agentes de software
sean mediadores entre las necesidades de los usuarios y las fuentes de información
disponibles (Ding y colab., 2002). Para lograr este objetivo, la Web Semántica tiene como
uno de sus pilares la definición de ontologías para los diferentes dominios de conocimiento.
El término ontología no es nuevo, proviene del área de la filosofía, fue utilizado con
posterioridad en el área de la Inteligencia Artificial y es adquirido ahora en el ámbito de la
Web Semántica. Una ontología es una especificación explícita y formal de una
conceptualización compartida (Studer y colab. 1998). Se entiende por i) Conceptualización:
un modelo abstracto de un dominio particular, que identifica los conceptos relevantes de
dicho dominio y sus relaciones; ii) Formal: la ontología debe ser definida mediante una teoría
lógica, lo cual permite que la misma pueda ser procesada por agentes de software; iii)
Explícita: los conceptos, sus relaciones y sus restricciones están definidos explícitamente; y
iv) Compartida: refleja que una ontología debe, en el mejor de los casos, dar cuenta de
conocimiento aceptado como mínimo, por el grupo de personas que deben usarla. Puede
citarse como ejemplo, para ilustrar los esfuerzos para la definición de ontologías en el
dominio de las empresas de manufactura, el proyecto PSL (“Process Specification
Language”) (Knutilla y colab., 1998) que intenta desarrollar una ontología para representar
los procesos de manufactura.
En el dominio de modelado de productos específicamente y, a pesar que no surgió
bajo el concepto de “ontología”, el estándar de representación de productos STEP
(“Standard for the Exchange of Product Model Data”), ISO 10303, puede ser considerado
una de las primeras ontologías de productos.
A partir de un análisis de la literatura existente acerca de las ontologías en este
dominio, se advierte que básicamente la mayoría de las que se encuentran definidas,
apuntan más bien a la clasificación de productos en categorías y no involucran conceptos
que tengan que ver con la representación de las estructuras de los productos o de la
17
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
información que debería almacenarse asociada a los mismos. Una excepción a esto es la
propuesta para una ontología integrada de productos que se hace dentro del proyecto TOVE
(Fox, 1992). No obstante, esta ontología no incorpora conceptos requeridos en la
planificación de la producción, ni la posibilidad de expresar estructuras de productos
complejos que involucren esquemas de descomposición/composición.
I.4. ANÁLISIS DE LAS PROPUESTAS MÁS RELEVANTES
La tendencia a producir productos personalizados en lotes pequeños incrementa el
número de variantes de un producto en las organizaciones industriales. Mientras que treinta
años atrás; un yogurt podía ser producido en algunos pocos sabores, los productores de la
industria láctea deben ahora manejar docenas de variantes. A medida que los ciclos de vida
de los productos se hacen más cortos, nuevos productos deben ser introducidos en el
mercado más frecuentemente. De esta manera, el rango de productos disponibles se
incrementa y, como los productos son cada vez más personalizados, el número de
combinaciones posibles de partes crece drásticamente. Esta situación no es bien gestionada
por las representaciones tradicionales de productos, en las cuales cada variante es
manejada de manera diferente.
Los sistemas de gestión de BOMs tradicionales consideran a las variantes como
productos distintos y de esta manera deben mantener un gran volumen de información
duplicada. Es así, que un nuevo tipo de BOM, denominado BOM Generativo surgió como un
intento para solucionar este problema. Recibió ese nombre debido a la generación
(construcción) de una variante específica en el momento en que ésta es requerida. Este tipo
de BOM define una estructura básica para un conjunto de productos similares, denominada
familia de productos, y reglas para adaptar dicha estructura a la de una variante específica.
En este grupo se inscriben los aportes de Schönsleben (1985), Van Veen y Wortmann
(1992), Hegge (1995) y Olsen y colab.(1997).
Por otra parte, otros autores buscaron optimizar las representaciones tradicionales
de estructuras de productos, mediante la tecnología de objetos y la definición de patrones,
por un lado, y mediante el empleo de diferentes niveles de abstracción en la representación,
por el otro. Al primer grupo pertenecen los trabajos de Chung y Fischer (1992, 1994), Usher
(1993), Hvan y colab. (2003), mientras que dentro del segundo grupo se inscriben la
propuesta de Gzara y colab. (2003), junto con la de Männistö y colab. (2001).
I.4.1. Propuestas tradicionales
En la bibliografía se registran diferentes propuestas para salvar las dificultades antes
puntualizadas. Scheer (1998) presentó tres estrategias para administrar la información de
18
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
productos con múltiples variantes. La primera de ellas, que simplemente pretende adaptar la
representación BOM tradicional al manejo de variantes, plantea tres opciones:
i)
BOM básico: Cada variante tiene asociado su BOM.
ii)
BOM parte idéntica: se crean entidades “ficticias” para representar aquellos
ensamblados que son comunes a todas las variantes. Entonces las variantes
se crean usando estas “partes idénticas”, más las partes componentes que
definen las distintas variantes.
iii)
BOM más-menos: toma una de las variantes como base y las otras se
estructuran teniendo como componente esta variante básica y eliminando o
agregando a esta estructura aquellos componentes que difieren de la variante
base.
En las Figuras I.9 a I.11 se pueden observar estas tres posibles alternativas. En el
primer caso, se aprecia que para indicar las estructuras correspondientes a las variantes V1,
V2 y V3 se especifican para cada una de ellas las relaciones con sus partes componentes.
Esta representación posee ocho entidades partes y trece relaciones estructurales. Por otra
parte, dado que las tres variantes utilizan los ensamblados E1, E2 y E3, las relaciones y las
estructuras de las variantes son casi idénticas.
v1
E4
v2
E1
E2
v3
E3
E5
Figura I.9. Gestión de Variantes. Estrategia 1- BOM básico
En el siguiente caso, correspondiente a un BOM parte idéntica (Figura I.10), se
puede apreciar la creación de una parte ficticia IP que agrupa los ensamblados E1, E2 y E3.
De esta manera se disminuye el número de relaciones, si bien se crea una nueva entidad
parte. En consecuencia esta representación da lugar a nueve entidades partes y diez
relaciones.
Finalmente, la última alternativa dentro de esta primera estrategia se ejemplifica en la
Figura I.11. Allí se observa que la variante V2 se define como variante base. Esta variante
se compone de los ensamblados E1, E2, E3 y E4. Las estructuras de las otras variantes (V1
y V3) se definen con relaciones que indican partes que se agregan y/o se eliminan de dicha
variante base. En el caso de V1, se agrega como componente el ensamblado E5 a los ya
definidos como componentes de la base (E1,E2, E3 y E4). Mientras que V3 define que se
19
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
elimina E4 y se agrega E5. Si bien esta alternativa involucra ocho entidades partes y nueve
relaciones, puede ser difícil de manejar si el número de variantes es muy elevado.
v1
v2
v3
IP
E4
E1
E2
E3
E5
Figura I.10. Gestión de Variantes. Estrategia 1- BOM parte idéntica
v1
v3
V2
+
+
E1
E2
E3
E4
E5
Figura I.11. Gestión de Variantes. Estrategia 1 – BOM más - menos
Una segunda estrategia, conocida como BOM múltiple, introduce el concepto de
familia de productos, donde cada familia se representa por una única entidad padre y se
asocia con todas las partes componentes que están incluidas en dicha familia. Siguiendo
con el ejemplo en cuestión, y tal como lo indica la Figura I.12 (a), para representar la
estructura común se necesitan seis entidades partes, la que identifica a la familia rotulada
con VF, más una por cada ensamblado Ei, y cinco relaciones estructurales que unen la
entidad familia VF con cada uno de los ensamblados. Para la representación de las
estructuras particulares de cada variante miembro de la familia, se necesitan agregar, como
lo indica la Figura I.12 (b):
una entidad por cada variante miembro de la familia (los nodos V1, V2 y V3
en el ejemplo);
las correspondientes relaciones que indican la pertenencia de cada variante
(V1, V2 y V3) miembro a la familia VF, simbolizadas con arcos en la figura; y
para cada variante, los vínculos que seleccionan las relaciones de la
estructura común que corresponden a su propia estructura, representados
con líneas punteadas.
20
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
V1
VF
V2
V3
VF
E1
E2
E3
E4
E5
E1
(a)
E2
E3
E4
E5
(b)
Figura I.12. Gestión de Variantes. Estrategia 2 – BOM múltiple
Las relaciones estructurales, como se mencionó antes, poseen asociada abundante
información, entre las que se pueden mencionar: cantidad de componente que se necesita
por cada unidad de producto ensamblado, lead time, costo de producción, etc. En el BOM
múltiple estas relaciones se representan sólo una vez para la estructura común, evitando la
duplicación de información que implica la existencia de estructuras similares. Por su parte,
las otras relaciones que aparecen en este tipo de BOM no tienen información asociada, con
lo cual no incrementan mayormente la cantidad de espacio de almacenamiento requerido
para su representación.
Finalmente, una tercera estrategia propone que las variantes no sean definidas
previamente como entidades, y que sólo se mantengan las partes componentes de las
mismas. Luego, la representación BOM de un producto particular es construida a partir de
estos componentes en caso de ser necesario, al recibirse una orden de producción para una
variante específica. En la Figura I.13 se muestra la representación de este tipo de BOM y se
ilustra conceptualmente cómo al recibirse una orden para la variante V2, se establecen las
relaciones necesarias, las cuales tendrán validez mientras exista la variante V2. En la orden
se deben indicar los ensamblados que participan y la cantidad de cada uno que ingresa en
la producción de la variante V2, que para el ejemplo sería E1, E2, E3 y E4.
Información almacenada
5 entidades partes, 0 relaciones
estructurales
V2
E1
E2
E3
E4
E5
Se genera un
pedido para la
variante V2
Se establecen las relaciones
estructurales relativas a la orden para
la variante V2
21
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
Figura I.13. Manejo de Variantes. Estrategia 3
Vollman y colab. (1992) plantearon la modularización del BOM con una perspectiva
diferente, consistente en la creación de módulos de planificación para una familia de
productos, sus características y opciones. De acuerdo a esta propuesta una opción es la
representación de una propiedad de un producto; una característica representa un conjunto
de opciones mutuamente excluyentes y un módulo de planificación define un conjunto de
componentes necesarios para la construcción de un producto final con un conjunto particular
de opciones. Bajo este enfoque los módulos de planificación pueden aplicarse para
identificar unívocamente el BOM de un producto final específico. Esta propuesta intenta
hacer más eficiente, desde el punto de vista del empleo de la información, la representación
de variantes; sin embargo, a medida que el número de productos similares aumenta,
también crece la complejidad requerida para la definición de los módulos.
I.4.2. Nuevos enfoques
Las representaciones propuestas por los modelos tradicionales se vuelven
ineficientes cuando el número de variantes de productos crece. Si, como se mencionó, se
representa la estructura de productos similares con BOMs independientes, la administración
de los datos producirá un gran volumen de información y un alto grado de redundancia. En
esta sección se introducirán algunas propuestas, que se alejan de la representación
tradicional del BOM y que intentan hacer más eficiente el manejo de la información de las
variantes.
BOMs generativos
Un enfoque que busca reducir el volumen de información necesario para la
representación de BOMs de productos con múltiples variantes es el denominado BOM
generativo. Esta alternativa utiliza el concepto de estructura genérica. La idea básica es que
toda información común sea almacenada sólo una vez en la estructura base, asociando a
las variantes sólo los datos de cómo derivar su BOM particular a partir de la información
almacenada en dicha base. Esta representación recibe el nombre de generativa, ya que a
partir de la estructura básica (BOM Base), mediante la especificación de valores a los
parámetros, se genera la estructura de una variante particular (BOM resultado).
Los conceptos fundamentales que subyacen a este tipo de enfoque son los de
variante de producto, valor de parámetro e ítem. Un ítem representa un conjunto de
productos similares que pueden ser descriptos por medio de parámetros. Estos parámetros
constituyen características que son significativas en el mercado y que pueden ser usadas en
el momento de generar una orden de producción. Una variante de producto representa un
producto particular y puede ser identificada por los valores que asumen los parámetros
22
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
asociados a dicho producto particular. Ese conjunto de valores de parámetros recibe el
nombre de especificación. Un ítem es un conjunto de variantes de productos que tienen el
mismo valor para al menos uno de sus parámetros. Una especificación S es válida para un
ítem P si P contiene una variante de producto que es identificada unívocamente por S.
Otro concepto de importancia en este enfoque es el de sistema de procesamiento de
BOMs, el cual consta de tres subsistemas que se presentan en la Figura I.14:
Sistema de Definición de BOMs Base (SDBB): permite la creación de los BOM Base,
cada uno de los cuales constituye la estructura común de una familia; así como las
reglas que permiten la obtención de estructuras particulares.
Sistema de Especificación de Productos (SEP): la función principal del sistema es
evaluar si una especificación es válida o inválida para un ítem particular de acuerdo a
las reglas definidas en el SDBB.
Sistema de generación de BOMs (SGBP): su finalidad es la generación de la
estructura BOM específica, dado un ítem y una especificación válida para dicho ítem.
Sistema de
Definición de BOMs
Base
BOM Base
Valores de
Parámetros
Sistema de
Especificación de
Productos
Especificación
Sistema de
Generación de
BOMs
BOM
Resultado
Figura I.14. Arquitectura de un sistema de procesamiento de BOMs generativo
El denominado BOM Variante (Schönsleben, 1985) fue uno de los primeros
esfuerzos para desarrollar un BOM Genérico, siendo una extensión del BOM tradicional. En
esta propuesta, la estructura genérica puede verse como la unión de los BOMs tradicionales
de cada una de las variantes del producto. De esta forma, el BOM base para un producto X
incluye todas las relaciones de la estructura para las cuales X es el padre. Dicho conjunto de
relaciones es particionado en subconjuntos, cada uno de los cuales se denomina cluster y
puede tener uno o más miembros. Cada cluster contiene relaciones que son mutuamente
excluyentes en la estructura de cada variante. A efectos de obtener un BOM resultado para
X se debe seleccionar un miembro de cada cluster. Por ello, cada una de los miembros de
un cluster tiene una condición asociada, la cual, si es satisfecha indica cuál es la relación
que participa en el BOM resultado. Dicha condición se expresa en función de los parámetros
que describen al producto X.
23
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
Este modelo provee una solución relativamente simple, principalmente para aquellos
productos donde las variantes se dan en los productos que son raíces de representaciones
BOM. Cuando se pretende aplicarlo a productos que corresponden a nodos intermedios de
dicha representación, comienza a tener algunos inconvenientes debido a un alto grado de
redundancia, ya que las variantes y sus especificaciones (parámetros, valores de
parámetros y restricciones) son aplicadas solamente a los productos finales, que como ya se
indicó, corresponden a nodos raíces de árboles BOM.
Posteriormente, Van Veen y Wortman (1992), introdujeron el concepto de BOM
Genérico que trata de solucionar los inconvenientes planteados para el BOM Variante. En
este modelo, es posible definir especificaciones en cualquier nivel de la estructura del
producto, lo que implica que los nodos intermedios de una estructura pueden tener
variantes. Se introdujo también un nuevo concepto: la función de conversión, la cual produce
una especificación válida para un ítem componente dada una especificación de su ítem
padre.
En este enfoque los ítems se definen no sólo a nivel de producto final, como en el
caso anterior, sino que es posible definirlos en todos los niveles del árbol de estructura de
un producto. Con esto aparecen, entonces, los conceptos de ítem base e ítem resultado. El
último se deriva del primero y representa un ítem al que se le ha asignado una
especificación durante el proceso de generación.
Las relaciones BOM se definen entre ítems. Una relación entre un ítem padre P y un
ítem componente C implica que cada variante de producto que es miembro de P tiene una
variante de producto componente que es miembro de C. En el BOM base, todas las
combinaciones entre miembros de P y miembros de C son representadas por una única
relación BOM entre estos ítems. Esto demanda información adicional para poder identificar
individualmente cada una de las relaciones entre miembros en el momento de generar el
BOM resultado. Para ello se utiliza la función de conversión, la cual produce una
especificación válida de un ítem componente, dada una especificación válida de un ítem
padre. Esta función está definida a través de reglas de conversión, las cuales definen
relaciones entre valores de parámetros de especificaciones de variantes padres y variantes
componentes.
De igual manera, Hegge (1995) propuso otra forma de mejorar el BOM variante a
través del uso de reglas de herencia que determinan implícitamente qué variante de un
componente usar para una determinada variante de un producto. Este autor, definió como
producto genérico (PG) a aquél que representa a un conjunto de productos finales, de
productos primarios (PPs) o materias primas e incluso de ensamblados intermedios (EIs),
los que son similares en algún aspecto. Los productos asociados con el PG representan las
variantes de una familia de productos (FP).
24
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
Según el criterio empleado en la definición de las familias, puede darse el caso que
se tenga más de un BOM Genérico (BG) para cada una de ellas. Las relaciones (genéricas)
dentro de un BG representan la correspondencia entre un “padre” y un “componente”
genérico. Cada relación implica que al menos en algún BOM dentro de la familia existe una
correspondencia entre uno de los padres asociados con el PG y algunos de los
componentes asociados con el componente genérico (CG) presente en dicha relación.
Así como pueden encontrarse variantes de un PG, también éstas existen en el nivel
más bajo del BG, definiéndose como producto primario genérico (PPG) al conjunto de todas
las variantes de un dado PP. Las diferencias entre variantes de FPs tienen su origen en las
que se dan entre los EIs, las que están directamente relacionadas a las variantes de los
distintos PPs de los que éstos se conforman, dentro de los PPGs asociados. Estos últimos
generalmente incorporan un gran número de variantes. Los EIs que tienen casi el mismo
BOM forman un ensamblado intermedio genérico (EG). La manera de identificar
completamente a una variante de un EG radica en indicar con qué variantes de los PPGs
ésta se relaciona, las cuales se diferencian en el valor que adoptan ciertos parámetros
característicos. Si un CG es empleado para fabricar todas las posibles variantes de un EG,
se lo referencia como un componente común, por lo que no se incluye como parte de la
identificación.
Hay diferentes métodos conocidos que pueden ser usados para identificar una
variante dentro de su FP. Los métodos pueden ser clasificados de diversas formas. Una
posibilidad es utilizar un método de identificación directo, en contraposición con uno
indirecto. La primera opción asocia un único código o número a cada variante de producto;
ésta es la manera directa de definir un producto particular. La forma indirecta consiste en
describir la variante a través del uso de un BOM; según esta descripción se mencionan los
componentes del producto final y la manera en que son ensamblados. Consecuentemente,
cada uno de los componentes tiene que ser identificado. Como ya se mencionó, otra
posibilidad para identificar variantes particulares es a través del uso de parámetros. Aquí
resulta necesario disponer de una lista de parámetros para cada FP. Cada uno de los
parámetros tiene valores válidos asociados que permiten especificar las diferentes variantes.
Siguiendo las ideas de la generación de estructuras de BOMs particulares a partir de
una estructura genérica, Olsen y colab. (1997) presentaron un enfoque procedural para la
representación BOM. Este modelo plantea la descripción de un producto genérico a través
de algunos conceptos extraídos del ámbito de la programación. El término procedimiento se
aplica para describir los componentes de la estructura genérica. Un componente consiste de
un encabezado donde se especifica la identificación del mismo y sus atributos más un
cuerpo que establece las relaciones todo-parte. Es aquí también donde se especifican las
reglas de selección para la determinación de los componentes particulares para cada
25
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
variante, que el procesador BOM tomará, para la definición de una estructura BOM
individual, teniendo en cuenta la especificación de parámetros que se le ingrese.
Para finalizar con este grupo de enfoques, es importante destacar que cuando se
considera una filosofía de BOMs generativos, es necesario tener en cuenta que en ciertos
casos no todas las combinaciones de partes son válidas, ya sea por razones tecnológicas o
comerciales. Surge, entonces, la necesidad de tener un mecanismo que permita expresar
qué restricciones existen entre las partes al momento de definir una estructura. Se pueden
establecer dos grandes grupos de restricciones entre partes: de obligatoriedad y de
incompatibilidad. Ambas deben definirse para poder lograr estructuras válidas, y según
Olsen y colab. (1997), todas las restricciones deberían especificarse en la estructura
genérica de manera de simplificar la especificación de una variante del producto.
I.4.3. Otros enfoques no tradicionales
Chung y Fischer (1992, 1994) propusieron un modelo conceptual que integra
elementos de las relaciones semánticas, con conceptos de la tecnología de orientación a
objetos, para desarrollar un modelo BOM al que denominaron OOBOM (“Object Oriented
BOM”). Este enfoque no utiliza el concepto de familia de productos ni de BOM generativo,
con lo cual cada una de las variantes tiene asociado su propio BOM, con el consecuente
volumen y duplicación de información que esto genera.
Este enfoque define un conjunto de clases y utiliza tanto relaciones de generalización
como de agregación para la representación de un “Bill of Materials”. En la Figura I.15 se
presenta el diagrama de clases con los conceptos involucrados en esta propuesta.
En OOBOM la clase BOM, que representa el “Bill of Materials” de un producto
particular, se especializa en Agregación y Componente para representar aquellos productos
que se obtienen del ensamblado de otras partes y los que tienen una estructura simple.
Estos últimos son representados por la clase componente. A su vez, este enfoque discrimina
la agregación en las clases Ensamblado, que representa productos que son resultado
intermedio del proceso de manufactura, y la clase Producto, que representa los productos
finales. Tanto los productos finales como los ensamblados intermedios se obtienen a través
del ensamblado de otros objetos BOMs.
26
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
Referencia
BOM
Compuesto-de
Compuesto-de
Propiedad
Posee
Agregación
Producto
Componente
Ensamblado
Forma
Especificación
Figura I.15. Conceptos asociados a la propuesta OOBOM
Cada uno de los objetos BOMs tiene asociado un conjunto de propiedades que lo
caracterizan. Esta situación es representada a través de la clase propiedad, que puede
especializarse según el dominio de aplicación y las relaciones de referencia, posee y
compuesto-de. El primer tipo de relación se establece entre un objeto BOM y un objeto
propiedad cuando el primero es caracterizado por dicha propiedad y la misma también
caracteriza a otro objeto BOM. Cuando el objeto BOM es el dueño de una propiedad (puede
ordenar su destrucción y tiene permisos para cambiar su estado), la relación que se define
es del tipo “posee”. El tercer tipo de relación, se establece entre un objeto Agregación y las
propiedades de los objetos que éste agrupa.
A efectos de salvar las dificultades vinculadas a la redundancia de información que
existe en los modelos convencionales, Usher (1993) propuso un enfoque orientado a objetos
en el cual pone énfasis en el modelado de productos finales compuestos por partes y
ensamblados, aplicado al dominio de empresas de manufactura discreta. En el trabajo
mencionado se destacan los beneficios del empleo del modelo de objetos para diseñar e
implementar el modelo de productos propuesto, a pesar de haber utilizado el paradigma de
objetos con una interpretación muy elemental. En el modelo de productos que introduce, un
ensamblado es definido en términos de sus componentes. Para la definición de un
componente utiliza una jerarquía que es una combinación de relaciones de composición y
de herencia. Asimismo, distingue componentes comprados a un proveedor de componentes
manufacturados.
Siguiendo el paradigma de objetos, Hvan y colab. (2003) propusieron el uso de
tarjetas CRC (“Class, Responsability, Collaboration”) para el diseño e implementación del
modelo de productos. Si bien establecieron una metodología para el desarrollo de un
modelo de productos, no presentaron una representación conceptual genérica de productos
que pueda especializarse en cada industria. En cada caso particular se debe aplicar la
metodología propuesta para diseñar y obtener el modelo de producto específico.
27
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
Gzara y colab. (2003) plantearon el uso de patrones para la definición de sistemas de
información de productos. Un patrón describe un problema común y recurrente en un
determinado campo del conocimiento y provee la solución a dicho problema. Esta solución
puede ser aplicada repetidamente cada vez que el problema se presenta, de manera de no
tener que resolverlo cada una de estas veces. Por otra parte, sostuvieron que el significado
del concepto de producto depende del contexto en el que se utiliza. En ocasiones puede
referirse a objetos virtuales, mientras que en otras a objetos físicos. Es por esto que
propusieron una definición del concepto de producto en tres niveles de abstracción: producto
genérico, tipo de producto y ejemplar de producto. Cada uno de estos niveles tiene asociado
distintos tipos de conocimiento que deben almacenarse de alguna manera.
Este enfoque considera un modelo de referencia general y un lenguaje de patrones a
usar en el diseño de sistemas de información de productos (PIS – “Product Information
System”). El lenguaje de patrones permite adaptar el modelo de referencia a situaciones
particulares a través de distintos “puntos de variabilidad”. Mediante una aplicación sucesiva
de patrones es posible resolver distintos problemas de la especificación PIS y proveer un
refinamiento de los modelos de acuerdo a las características de la organización donde está
siendo desarrollado el sistema en cuestión. El pasaje de un patrón a otro se hace a través
de dos tipos de enlace: usa y refina. En la Figura I.16 se presentan los patrones que se
proponen en este enfoque para el diseño de sistemas de información de productos.
Patrón Tres
Niveles
usa
usa
Patrón
Variaciones
usa
Niveles de
producto
Patrón Dos
Niveles
BOMs
Aplicados
Patrón Un
Nivel
Asociación
BOMs a
productos
usa
Documentos
Aplicados
usa
Asociación
Documentos a
productos
Figura I.16. Patrones incluidos en el lenguaje propuesto por Gzara y colab. (2003)
Por su parte, Männistö y colab. (2001) usaron el término producto configurable como
sinónimo de un producto que tiene un gran número de variantes. En su propuesta
identificaron tres conceptos principales: estructura de elemento (EE), modelo de elemento
(ME) y jerarquía de modelos de elemento (JME), los cuales se muestran en la Figura I.17.
28
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
Esta propuesta parte de la suposición que cada variante de producto individual tiene
una estructura denominada “order BOM” (que se corresponde con el ya mencionado BOM
resultado). En cada uno de éstas se identifican componentes esenciales por medio de una
estructura de elemento, la cual, como su nombre lo indica, está compuesta por elementos y
provee una vista del “order BOM” desde un punto de vista específico para un área de la
organización. Cada elemento en una EE, se asocia a algún componente de un “order BOM”
y define un rol para dicho componente asociado. La estructura del elemento debe estar de
acuerdo con un ME, el cual describe, por medio de clases de elementos, aquellos elementos
que deben estar presentes en dicha estructura. Este enfoque organiza los modelos de
elemento en una jerarquía (JME). A partir de la JME, el modelo de elemento apropiado se
selecciona para obtener la EE de un producto individual.
Jerarquía de Modelos de
Elemento
Aa
Modelo de
elemento
Clase de Elemento
Componente
Order BOM
Estructura de Elemento
aa
Elemento
Especialización de
Asociado a
Conforme a
Parte de
Figura I.17. Vista de los conceptos básicos de la propuesta de Mänisto y colab (2001)
I.5. NECESIDADES A SATISFACER POR UN MODELO DE PRODUCTOS
La información de los productos manufacturados por una organización industrial
constituye el corazón de los recursos de información que dicha organización gestiona. Los
datos de productos suelen estar dispersos en las diferentes áreas funcionales, incluso
pueden estar distribuidos a través de distintas empresas. Claramente, gran parte de esta
información es creada en el área de diseño e ingeniería; pero también existen datos que son
generados y empleados en las áreas de manufactura, ventas, mantenimiento y planificación,
entre otras. Cuando no existe una definición estándar de los datos de productos, cada
usuario y/o programa de aplicación puede tener un modelo de productos propio; lo cual
29
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
conduce
a
problemas
de
duplicación
de
información
e
inconsistencias,
que,
consecuentemente, implican pérdidas de tiempo y dinero.
Dentro de la información de productos, el núcleo está constituido por los datos
acerca de su estructura. En las organizaciones actuales, las estructuras de productos tienen
algunas características que deben considerarse al momento de la definición de un modelo
conceptual que las represente. Al igual que el resto de los datos de productos, las
estructuras son vistas de manera diferente por las distintas áreas de una organización.
Asimismo, no existe un único tipo de estructura: hay productos que se obtienen por el
ensamblado de partes, otros que son resultado de alguna operación de desagregación de
materias primas no atómicas y algunos productos combinan las estructuras previas. Por otra
parte, un mismo producto podría tener más de una estructura si es posible obtenerlo por
diferentes recetas.
Los grandes adelantos producidos en las tecnologías de la información y las
comunicaciones afectaron tanto a la forma de trabajar de las organizaciones industriales y
sus productos, como a los sistemas que las soportan.
Las empresas de producción industrial se enfrentan por un lado, a los cambios
constantes de las condiciones del mercado, como por ejemplo, patrones de demanda
inciertos, ciclos de vida de los productos mucho más cortos, etc. Por otro, se encuentran
inmersas en un mercado global, que requiere que la cadena de suministros alcance muy
altos niveles de eficiencia. Para mantener la competitividad en este nuevo entorno, estas
empresas, deben lograr una alta integración de sus actividades, lo cual se ve facilitado si se
cuenta con un modelo de datos común a todas las áreas. Los modelos de productos
existentes son insuficientes para responder a estas nuevas exigencias, si bien han surgido
distintas propuestas que tratan de lograr un modelo común, desde los primeros sistemas
PDM locales hasta la aplicación de la tecnología Web para la implementación de sistemas
de datos de productos distribuidos. Más recientemente, y aún en una etapa de desarrollo, se
presentaron algunas propuestas que incorporan conceptos de ontologías para obtener un
modelo de productos a ser usado en la Web Semántica.
Por otra parte, la tendencia a producir productos personalizados en lotes pequeños
incrementa el número de variantes de un producto a ser gestionadas por las organizaciones
industriales. A medida que el tiempo de vida de un producto se hace más corto, nuevos
productos deben ser introducidos en el mercado más frecuentemente. De esta manera, el
rango de productos disponibles se incrementa y, como los productos son cada vez más
personalizados, el número de combinaciones de partes posibles crece drásticamente. Esta
situación no es bien manejada por las representaciones tradicionales de productos, en las
cuales cada variante es gestionada de manera individual. Para superar esta situación se
hicieron algunas adaptaciones de las representaciones tradicionales para satisfacer las
30
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
nuevas necesidades. Debido a que estas modificaciones sólo lograron paliar el problema,
han surgido enfoques un poco más eficientes.
Si bien todas las propuestas analizadas presentan una mejora parcial respecto a los
sistemas BOM tradicionales, en lo que respecta al manejo de múltiples variantes, dejan sin
resolver otros aspectos esenciales para el manejo de datos de productos, como por ejemplo
la representación de estructuras híbridas. Además, las propuestas han sido desarrolladas
para empresas de producción que poseen procesos de manufactura discretos y un esquema
de producción de tipo ensamblado. Ninguna de ellas contempla la existencia de materias
primas no atómicas de las cuales se obtienen derivados que son los que ingresan al sistema
productivo como parte componente de algún otro producto. Un ejemplo típico de este tipo de
organizaciones son las empresas lácteas, frigoríficas y petroquímicas. En ellas, las
estructuras de los productos involucran no sólo relaciones de composición sino que incluyen
también relaciones de descomposición, constituyendo así estructuras de productos
complejas o híbridas que no son fácilmente representables con los modelos antes
mencionados.
De lo expuesto en el presente capítulo se desprende la necesidad de contar con un
modelo de productos compartido por los diferentes actores involucrados en el ciclo de vida
del producto. Dicho modelo deberá permitir:
la administración eficiente de un elevado número de variantes;
la representación de productos con diferentes tipos de estructuras: composición,
descomposición e híbridas;
el manejo de estructuras alternativas;
la representación de las vistas que cada unidad organizacional tiene de los
productos; y
la integración semántica de los datos de productos en los diferentes eslabones de la
cadena de suministros.
Este trabajo presenta un modelo de productos que da respuesta a estos puntos. Los
cuatro primeros, serán abordados en el Capítulo III donde se presenta en detalle las
características del modelo y se explica de qué manera éste da solución a los requerimientos
planteados. Mientras que el último ítem será tratado en el Capítulo V, mediante la definición
de una arquitectura para un sistema de administración de datos de productos distribuido,
pero semánticamente integrado a través de una ontología de productos.
31
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
I.6. ORGANIZACIÓN DE LA TESIS
La presente Tesis consta de siete capítulos, los cuales se encuentran organizados
cronológicamente según la forma en que se fue desarrollando el trabajo. En este primer
capítulo se introdujo al lector en la temática de modelo de productos en las organizaciones
industriales. Se describió la problemática asociada a las estructuras de productos, así como
a sus representaciones. Además, se presentó la influencia que las tecnologías de la
información y las comunicaciones han tenido sobre el modelo de productos y de qué manera
distintas propuestas trataron de adaptar dicho modelo a los nuevos entornos.
En el Capítulo II se expone una caracterización del dominio de trabajo y se definen
los alcances de esta Tesis, indicando qué aspectos de dicho dominio serán abarcados.
Asimismo, se presentan dos casos de estudio que fueron abordados: el modelo de
productos de una planta de producción de golosinas y el correspondiente a una industria
frigorífica.
El Capítulo III presenta las características del modelo postulado. Se discute la
existencia de distintos niveles de abstracción en el concepto de productos y se explican las
particularidades de los distintos elementos que comprende el modelo propuesto. Se cubren
desde los conceptos centrales, tales como familia, conjunto de variantes y producto, hasta
los relacionados directa o indirectamente con éstos. A modo de validación de la propuesta,
el modelo fue empleado para la representación de los datos de producto de los casos de
estudio introducidos en el Capítulo II. Algunos ejemplos de esta implementación se exponen
y discuten en el Capítulo IV.
El Capítulo V presenta el prototipo de sistema de procesamiento de BOMs que fue
desarrollado utilizando el modelo que se describe en el Capítulo III. Se detalla la arquitectura
del mismo, su funcionamiento y se efectúa un análisis de los resultados obtenidos. El
prototipo fue desarrollado para ser usado dentro de una única organización; por lo cual el
siguiente capítulo expone nuevas tecnologías que permiten lograr la integración de este
prototipo con otras organizaciones a través de los conceptos relacionados con las ontologías
y la Web Semántica.
En el Capítulo VI se presenta, entonces, la noción de integración inteligente de
sistemas, los conceptos y herramientas utilizadas en el domino de las ontologías y la Web
Semántica. De igual manera, se introduce una arquitectura para un modelo de productos
distribuido que utiliza una ontología de productos como integrador semántico. Por último, se
expone cómo el modelo de productos propuesto, es migrado a una ontología de productos
denominada PRONTO (“PRoduct ONTOlogy”).
Finalmente, las conclusiones del trabajo de investigación realizado, cuyos resultados
se exponen en la presente Tesis, se reseñan en el Capítulo VII.
32
_______________________________________ El Modelo de Productos en las Organizaciones Industriales
33
II. DOMINIO DE TRABAJO. CARACTERIZACIÓN Y DEFINICIÓN DE SU
ALCANCE
II.1. INTRODUCCIÓN
En este capítulo se presenta una caracterización del complejo dominio de modelado
de productos y la definición de los límites considerados para el desarrollo de este trabajo.
Asimismo, se detallan los dos casos de estudio que se utilizan a lo largo de la Tesis para la
validación de las propuestas.
Cada tipo de industria tiene necesidades de información impuestas por el conjunto de
características distintivas asociadas con la naturaleza de los productos que manufactura, y
con el tipo de proceso productivo y de control de producción que utiliza. Es por esto que para
entender cuáles son las necesidades, se requiere reconocer dichas características
distintivas. Para ello, se presentan a continuación los distintos tipos de procesos productivos
que es posible encontrar en las diferentes industrias. Es importante mencionar que las
clasificaciones que se introducen no son estrictas ya que existen industrias que no se
ajustan taxativamente a una única categoría.
II.2. CLASIFICACIÓN DE PROCESOS PRODUCTIVOS
Los sistemas de producción están estructurados a través de procesos, que entrañan
transformaciones de materias primas en productos de mayor valor agregado y que utilizan
recursos de diversa índole. Estos sistemas apuntan a satisfacer los requerimientos de los
clientes haciendo el mejor uso de los recursos disponibles.
En las empresas de manufactura, estos sistemas productivos representan las
configuraciones adoptadas en torno al proceso de conversión y/o transformación de entradas
(materiales, recursos económicos, informativos, energéticos, etc.) en salidas (bienes) para
satisfacer necesidades, requerimientos y expectativas de los clientes de la forma más
competitiva posible.
Si se analiza el contexto empresarial, podrá encontrarse que existen distintos
sistemas de producción en las empresas manufactureras. Asimismo, si se revisa
apropiadamente la literatura sobre Administración de la Producción y Operaciones, se
encontrará una diversidad de tipologías respecto a la forma de clasificar las configuraciones
productivas. Esto se debe, fundamentalmente, a la variedad de enfoques con que los
diversos autores tratan estos temas en sus trabajos.
33
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Según de Heij (1996), pueden plantearse diferentes clasificaciones teniendo en
cuenta aspectos tales como el tamaño del lote de producción, la organización física del
proceso productivo o la estructura de dicho proceso. Por su parte, Fisher (1990) propone una
clasificación del proceso productivo basada en cómo es el flujo de los materiales en el
mismo. Otro criterio muy utilizado para la clasificación de los procesos productivos tiene que
ver con la ubicación del CODP (“Customer Order Decoupling Point”), el punto a partir del
cual el proceso deja de estar guiado por las actividades de planificación y comienza a ser
dirigido por las órdenes de los clientes. Estas diferentes clasificaciones se muestran en la
Figura II.1.
Único ítem
Largas series
Pequeñas series
Continuo
Tamaño del lote
Flujo de
materiales
Organización física del
proceso productivo
Estructura del proceso
productivo
Industrias de Manufactura Discreta
Industrias de Procesos Continuos
Industrias de Procesos Batch
Industrias de Procesos Semicontinuos
Manufactura flexible
Job shop
Floor Shop
Proceso de Manufactura Continuo
Secuencial
Convergente
Divergente
Red
Continuo
Ubicación del CODP
Distribution on-Stock
Make-to-Stock
Assemble-to-Order
Make-to-Order
Engineer-to-Order
Figura II.1 Clasificación de procesos productivos
La gran diversidad de procesos y los potenciales criterios de clasificación a
considerar hacen que sea difícil encontrar una tipología que sea exhaustiva y que de manera
unívoca contemple cada caso concreto. Con el fin de mostrar cómo el tipo de industria define
los requerimientos de información, a continuación se analizan dos clasificaciones que surgen
de aplicar diferentes criterios de clasificación, a saber: el flujo de materiales y la ubicación
del CODP.
II.2.1. Clasificación de procesos productivos basada en el flujo de materiales
Como ya se mencionó, Fisher (1990) propone una clasificación de los procesos
productivos que se focaliza en cómo es el flujo de los materiales dentro del proceso. Este
autor sostiene que los procesos productivos pueden clasificarse como:
34
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
industrias de manufactura discreta;
industrias de procesos: las cuales a su vez pueden subclasificarse de acuerdo
a cómo es la salida de materiales de la planta:
o
Procesos continuos: los productos egresan en un flujo continuo y
fluyen de esta forma a través de la planta.
o
Procesos discontinuos o “batch”: la salida se origina a partir del
procesamiento de una secuencia de cargas o “bachadas” en los
equipos.
o
Procesos semicontinuos: combinan etapas que poseen equipos
continuos y discontinuos.
Industrias de manufactura discreta
Los procesos de tipo discreto generalmente involucran operaciones vinculadas con la
manipulación de las piezas o partes a procesar en forma directa, y con aquellas que
producen transformaciones físicas sobre las mismas, como podría ser torneado, fresado,
armado o ensamblado. Productos tales como dispositivos electrónicos, artefactos eléctricos,
muebles o automotores son elaborados utilizando tecnología de procesos discretos. Estos
tipos de productos se caracterizan por ser mayormente sólidos y poseer una determinada
“forma” y/o estructura que es necesario representar. Según Gu (1992) esta forma se
describe en términos de:
características del producto final y de cada uno de sus componentes, y
una estructura de ensamble o composición del producto.
Los productos de las industrias de manufactura discreta son, en general, muy
complejos y como tales requieren información de muy diversa índole y articulada de
diferentes formas. Gran parte de esta información está asociada al diseño del producto y,
tradicionalmente, es representada en dos tipos de diagramas: diseño de partes y diseño de
ensamblado. El primero define, para cada parte:
forma geométrica;
dimensiones y su tolerancia;
material y tratamiento térmico requerido; así como
acabado de superficie.
Por otro lado, el diseño de ensamblado contiene información acerca de:
naturaleza de la conexión entre las partes (simple contacto, ajuste, etc);
35
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
posición relativa de cada parte en la estructura del producto;
función de cada parte ; y
el BOM (“Bill of Materials”).
Como ya se mencionó en el capítulo I, el BOM comprende un conjunto de relaciones
ítem padre-componente que tienen, al menos, la siguiente información:
identificación del ítem padre;
identificación del ítem hijo;
fecha de validez de la relación;
cantidad del componente por cada unidad del ítem padre y
factor de desperdicio (si fuera aplicable).
Por otra parte, suele asociarse a la estructura del producto información referida a las
rutas de producción. La ruta de producción de un ítem es una lista ordenada de las
operaciones requeridas para su manufactura y de los equipos que pueden llevarlas a cabo.
La información básica sobre cada operación que conforma una ruta se refiere a:
número de secuencia;
unidad de procesamiento donde se va a ejecutar la operación;
tiempo de operación: cantidad de tiempo necesaria para llevar a cabo la
operación. Está compuesto por el tiempo de puesta en marcha (setup), de
operación propiamente dicho, de inspección y de transporte. Estos tiempos
pueden representarse acumulados en un único atributo o discriminados en
más de uno. En el caso de etapas continuas se especifica la velocidad de
procesamiento.
A partir de esta información, es posible calcular el lead time de producción asociado a
una orden de trabajo de un ítem específico y a un tamaño determinado de lote, a través de la
suma de los tiempos de cada operación que forma parte de la ruta de producción de dicho
ítem.
Industrias de procesos continuos
En las industrias de procesos continuos intervienen productos que sufren
transformaciones físicas y fisicoquímicas a lo largo de su proceso productivo. Éstas utilizan
como materias primas, en general, productos naturales o derivados de éstos para elaborar
productos cuya demanda casi no se afecta por los cambios del mercado.
36
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Los productos de las industrias de tipo continuo son, frecuentemente, de tipo
“commodities” y presentan un muy bajo grado de personalización. Además, sus ciclos de
vida son bastante prolongados por lo que las actividades ingenieriles se focalizan más en los
procesos productivos que en los productos que se elaboran. El diseño y rediseño óptimo de
los procesos, la búsqueda de condiciones operativas más adecuadas y el control óptimo de
procesos constituyen algunas de las responsabilidades de los ingenieros de procesos.
Las plantas se organizan en términos de líneas dedicadas a la fabricación de los
distintos productos; por lo tanto requieren una inversión de capital elevada. Los equipos
realizan continuamente las mismas operaciones físicas y/o fisicoquímicas y las plantas
operan en forma ininterrumpida, suspendiéndose únicamente para tareas de mantenimiento
de los equipos.
Usualmente, en este tipo de procesos no existe relación entre las unidades de
producción y las unidades de venta; es decir, no se identifica qué parte del flujo de salida de
un proceso está destinada a una orden de pedido particular. Esto se debe a que la
producción se destina fundamentalmente a mantener niveles de stock.
Estas industrias tienen sistemas de control automático o semiautomático que se
encargan de mantener los procesos operando bajo las condiciones deseadas y elaborando
los productos de acuerdo a sus especificaciones. Dichos sistemas de control pueden inferir
el estado del proceso a partir de la realización de mediciones periódicas sobre variables
tales como caudales, presiones, temperaturas, composiciones, etc.
Industrias de procesos batch
El requerimiento de productos especializados de alto valor agregado, como los de la
química fina (que son solicitados en volúmenes pequeños, poseen ciclos de vida cortos, y
están sujetos a demandas estacionales), dio lugar a que se consolidase el empleo de
sistemas de procesamientos discontinuos o batch. Al producir en plantas batch se posibilita
la elaboración de diferentes productos en pequeñas cantidades en una misma instalación.
Con respecto a los productos manufacturados en este tipo de plantas puede añadirse que
los mismos están destinados fundamentalmente a consumidores finales o industrias que se
encuentran en los últimos eslabones de la cadena productiva como, por ejemplo, los
productos farmacéuticos, agroquímicos, colorantes, alimenticios, etc. Aunque no llegan a
alcanzar la complejidad de los productos elaborados por procesos de manufactura discreta,
estos productos tienen síntesis químicas más complejas que los producidos en plantas de
procesos continuos.
Las plantas “batch” pueden tener líneas dedicadas a la producción de un único
producto, aunque esta situación es menos frecuente. Como se mencionó, habitualmente se
produce en ellas una variedad de productos. Se denominan Plantas Batch
37
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Multiproducto aquéllas en las cuales los productos elaborados tienen recetas similares y
siguen básicamente la misma secuencia de operaciones. Por ello, estas plantas, también
identificadas como ambientes “job-shop”, fabrican productos de una misma familia.
En este tipo de instalaciones, una corrida de producción identifica un conjunto de
lotes de un producto que se manufacturan secuencialmente en el mismo conjunto de
equipos. El orden y tamaño de cada corrida se definen según los pedidos de cada cliente y
en función de factores tales como la prioridad de estos pedidos. Puede ocurrir que una
corrida de producción permita cumplimentar sólo una orden de pedido o que se asocie a
varias que demanden un mismo producto. Igualmente, una orden puede ser satisfecha por
una o más corridas de producción. Así el concepto de corrida permite vincular las órdenes de
pedidos con los procesos de elaboración y, en consecuencia, conocer el estado de las
órdenes de los clientes.
Por su parte, las plantas “batch” multipropósito son aquéllas en las cuales es posible
elaborar un número importante de productos que presentan diferentes recetas de
procesamiento y que, por lo tanto, siguen secuencias de tareas distintas. Estas plantas
poseen equipos multifuncionales o multipropósito que se agrupan de acuerdo a las tareas
que pueden hacer; siendo consecuentemente más flexibles. Como se mencionó, los
productos poseen secuencias de elaboración disímiles y, más aún, un mismo producto, en
distintos momentos, puede seguir rutas de producción diferentes. Estas instalaciones poseen
una estructura de planta tipo taller o “job-shop” que permite elaborar concurrentemente
varios productos. Sin embargo, esta flexibilidad hace más compleja la operación de estas
plantas, debido a las muchas alternativas de caminos de producción que ellas permiten.
Información de productos en la industria de procesos
A diferencia de los productos de la industria de manufactura discreta, los elaborados
por las industrias de procesos se describen no sólo por BOMs convencionales (que indican
cómo los productos intermedios y terminados se producen a partir de materias primas) sino
también a través de diagramas invertidos (que muestran cómo una materia prima puede ser
descompuesta en diferentes productos). Por otro lado, en la industria de manufactura
discreta en el BOM se incluyen operaciones de ensamblado de partes, mientras que en la
industria química, se describen actividades de combinación y de transformación de
sustancias. De manera contraria, los productos de la industria del petróleo, y algunos
derivados de las industrias lácteas y frigoríficas se describen mediante diagramas invertidos
como los que se introdujeron en la Figura I.7.b. Asimismo, existe un número importante de
productos que se asocian a diagramas mixtos (veáse Figura I.7.c).
En las industrias de procesos, especialmente en las de procesos continuos, los
materiales fluyen en forma continua a través de las distintas etapas del proceso, pudiendo
38
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
ocurrir a lo largo de éste transformaciones químicas que dan lugar a nuevas sustancias.
Asimismo, la elaboración de un producto muchas veces involucra la obtención de otros con
igual o menor valor económico, denominados coproductos y subproductos, respectivamente.
A diferencia de las industrias que manejan productos de naturaleza discreta, aquí no
se hace referencia a la “forma” de los productos por lo que la información que los define no
se relaciona con características geométricas, de dimensiones ni de terminaciones. Sin
embargo, resultan relevantes las propiedades fisicoquímicas de las substancias que fluyen
en el proceso productivo. Según Motard y colab. (1994), una sustancia puede ser un
componente, una mezcla o un sólido amorfo (una sustancia que no puede ser caracterizada
por su peso molecular). En este sentido, la Figura II.2 presenta dicha clasificación.
2..*
Infomezcla
fracMol
fracMas
fracVol
Mezcla
1..*
Sustancia
Componente
NombreSustancia
alias
SólidoAmorfo
tipo
EspecieQuímica
pesoMolecular
fórmulaQuimica
fórmulaEstructural
PseudoComponente
tipo
Figura II.2. Una posible clasificación de sustancias
El concepto de componente abarca tanto especies químicas como pseudocomponentes, tal como las fracciones de petróleo y de carbón. Una especie química es una
sustancia pura que tiene una única fórmula química conocida. Un pseudo-componente es
una sustancia no pura que puede ser caracterizada por un peso molecular promedio medido
o estimado.
Una mezcla es la unión de dos o más sustancias en proporciones variables, de
manera tal que los componentes de la misma pueden separarse por medios físicos. La
participación de una sustancia en una mezcla se establece a partir de su fracción molar, de
masa y/o de volumen.
Una característica común a muchos tipos de industrias es que los productos que
participan son referenciados de diferentes maneras; es común que una sustancia tenga un
nombre con múltiples sinónimos o alias. En el caso de la industria química, los compuestos
se identifican mediante su fórmula química y su nombre. No sólo puede haber más de un
39
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
nombre para una misma sustancia (por ejemplo, etanol o alcohol etílico son sinónimos), sino
que sustancias diferentes, caracterizadas por tener distintas propiedades fisicoquímicas,
pueden tener fórmulas químicas idénticas. Este es el caso de los isómeros, que poseen
diferente estructura molecular. Se aprecia entonces que no es trivial la identificación unívoca
de una especie química y menos aún de una mezcla.
Al ser los productos una parte fundamental de los procesos industriales, surgen
nuevas necesidades de representación de la información. Una de ellas es la vinculada a los
procesos productivos. En la industria de manufactura discreta se utiliza el concepto de ruta
de producción como una forma de representación del proceso de elaboración de un
producto. La ruta de producción no sólo especifica detalles de las operaciones de
maquinado, ensamblado, tratamiento térmico, acabado superficial, etc.; sino también el
orden de ejecución de estas operaciones y los equipos asociados a cada una de ellas
En las industrias de procesos el concepto utilizado es el de receta. Ella especifica la
serie de actividades que requiere la manufactura de un determinado producto, el orden de
ejecución de las mismas, así como las materias primas requeridas. Mientras las recetas de
procesamiento de los productos obtenidos en procesos de tipo continuo son, en general,
sencillas, las que corresponden a industrias de procesos “batch” son por el contrario
complejas (ya que incluyen además de los componentes, la especificación de orden en que
se procesamiento, tiempos de procesamiento, equipos involucrados, valores de variables de
proceso, etc.), y se especifican en diferentes niveles de detalle de acuerdo al estándar ISA
SP-88 (ANSI/ISA 2003).
Esta representación juega un rol importante en la automatización y el control de los
procesos batch; sin embargo, no es la única utilizada. Cuando se abordan problemas de
planificación a corto plazo o “schedulling” de plantas “batch” suele emplearse otra
representación denominada red de estados y tareas (STN - State Task Network) introducido
por Kondili y colab. (1993). Una representación STN es un grafo dirigido que consiste de tres
tipos de elementos: i) nodos estados, que representan las fuentes de alimentación (ingreso
de materias primas), los productos intermedios y los productos finales; ii) nodos tareas, que
representan las operaciones del proceso, que transforman uno o más estados iniciales en
uno o más estados de salida; y iii) arcos que indican el flujo de los materiales.
La Figura II.3 introduce un pequeño ejemplo de este tipo de representación. En ella,
los nodos estados y tareas se esquematizan por círculos y rectángulos respectivamente.
Asimismo, a cada tarea se le asocia un conjunto de estados, que representa los flujos de
entrada y otro que representa los flujos de salida. También se especifican, ya fuera del grafo,
los equipos que pueden llevar a cabo cada tarea, así como un conjunto de parámetros
característicos de la misma y de su ejecución en un determinado equipo.
40
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Producto1
40 %
H
40 %
IntAB
R2
60 %
Alimentación A
10 %
ACaliente
EImpuro
60 %
S
IntBC
90 %
Producto2
50 %
Alimentación B
80 %
R1
50 %
R3
20 %
AlimientaciónC
Figura II.3. Ejemplo de representación STN
A partir del ejemplo y de la descripción presentada en los párrafos previos, es posible
abstraer algunos de los conceptos que se encuentran involucrados en una representación
del tipo STN. Los mismos se muestran en la Figura II.4. Se observa la definición de una
clase Estado, que se especializa en Alimentación, ProductoIntermedio y ProductoFinal.
Algunos ejemplos de instancias de cada una de estas clases se pueden ver en la Figura II.3.
Así, AlimentaciónA, AlimentaciónB y AlimentaciónC son instancias de la clase Alimentación;
ACaliente, IntAB, IntBC y EImpuro son objetos de la segunda clase; mientras que Producto1
y Producto2 corresponden a instancias de la clase ProductoFinal. Otras clases que se
definen para un proceso con etapas “batch” son TareaBatch y EquipoBatch, que constituyen
las diferentes tareas que aparecen en la red y los equipos donde se llevan a cabo. Estas dos
clases se encuentran unidas por la relación RelaciónT-E, en la cual se especifican los
parámetros que caracterizan a un par Tarea-Equipo. El tiempo de procesamiento de una
tarea en un determinado equipo y el tamaño de lote para una tarea en dicho equipo son
ejemplos de estos parámetros. Finalmente, la figura muestra la relación existente entre
Estado y Tarea, que define los flujos de Entrada o de Salida.
Estado
TareaBatch
RelaciónT-E
Flujo
TamañoDeLote
TiempoProcesamiento
Alimentación
EquipoBatch
Entrada
Producto Producto
Intermedio
Final
Salida
Figura II.4. Algunos de los conceptos involucrados en una representación STN para un
41
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
proceso con etapas “batch”
II.2.2. Clasificación de ambientes productivos basada en el concepto de CODP
(Customer Order Decoupling Point)
Antes de presentar una clasificación de los diferentes entornos de producción es
necesario introducir el concepto de Customer Order Decoupling Point (CODP). CODP se
refiere al punto, en el flujo de materiales, a partir del cual las actividades comienzan a estar
específicamente guiadas por las órdenes de los clientes. Las tareas que se encuentran
antes del CODP, se llevan a cabo en base a lo especificado por actividades de planificación
de la producción que toman como base pronósticos de demanda. Por el contrario, la
ejecución de las tareas que se encuentran después del CODP está guiada por las órdenes
de los clientes. Las diferentes ubicaciones del CODP se asocian a distintos entornos de
manufactura y distribución de productos, los cuales se esquematizan en la Figura II.5 y se
describen a continuación:
“Distribution-on-stock” (DOS): los productos son fabricados y distribuidos en
almacenamientos descentralizados sin tener en cuenta una demanda directa
de los clientes;
“Make-to-stock” (MTS): en este esquema los productos son fabricados en
base a pronósticos de demanda, pero la distribución de los mismos se hace a
partir de un stock generalizado, considerando las órdenes de los clientes.
“Assemble-to-order” (ATO): se manufacturan y almacenan componentes, que
son a posteriori ensamblados para fabricar productos finales a pedido del
cliente.
“Make-to-order” (MTO): en este esquema todo el proceso productivo es
controlado por las órdenes de los clientes; es decir, se produce sólo lo que es
especificado en las órdenes por los clientes.
“Engineer-to-order” (ETO): los productos requieren un diseño de ingeniería a
pedido del cliente (o una personalización importante). En general, cada orden
de cliente requiere un diseño, una estimación de costos, listas de materiales
(los que se compran en función del pedido) y rutas de producción particulares
para esa orden.
Cada uno de estos entornos productivos impone diferentes necesidades de
información debido a sus características particulares. Wortmann (1992) presenta la
valoración de una serie de atributos según el entorno productivo, la cual se resume en la
42
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Tabla II.1. En particular, este autor analiza cuáles son las actividades en las que se focalizan
la gerencia superior y la gerencia media, cuáles son los procesos de mayor incertidumbre y
cuáles poseen operaciones de mayor complejidad y deberían ser soportadas por sistemas
de información.
Compra
Manufactura
Ensamblado
Compra
Manufactura
Ensamblado
Compra
Manufactura
Compra
4
Compra
5
Venta
DOS
Distribución
Venta
MTS
Ensamblado
Distribución
Venta
ATO
Manufactura
Ensamblado
Distribución
Venta
MTO
Manufactura
Ensamblado
Distribución
Venta
ETO
3
Distribución
2
1
DOS – Distribution on stock | MTS – Make-to-stock | ATO – Assemble-to-order
MTO – Make-to-order | ETO – Engineer-to-order
Figura II.5 Entornos productivos definidos por la posición del CODP
En entornos tipo ATO, como ya se mencionó, los productos finales se obtienen a
través del ensamblado de componentes (previamente fabricados y almacenados) según los
pedidos de los clientes. Debido a esto, existe una gran variedad de productos que son
ofrecidos a los clientes. En consecuencia, la administración de operaciones enfrenta mucha
incertidumbre en cuanto al número y tipo de órdenes que se recibirán desde los clientes. Las
especificaciones de los productos requeridos cambian de un cliente a otro, incluso para un
mismo cliente en el tiempo. Esta incertidumbre en las demandas afecta en gran medida a las
actividades de planificación. La administración de la producción se enfoca en el balance
entre la provisión de los materiales, la capacidad disponible y el ingreso de órdenes de
clientes. Por otra parte, los sistemas de información dan soporte a las actividades de ingreso
de órdenes de clientes y provisión de materiales. Algunos de los sistemas que se utilizan
son: de chequeo de consistencia de los requerimientos de los clientes, generación de BOMs,
instrucciones de manufactura y otros documentos de ingeniería, así como cálculo de costos
y fechas de entrega en base al programa maestro de producción (MPS-Master Production
Schedule).
43
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Tabla II.1 Comparación de diferentes entornos productivos
CODP
Características
ETO
MTO
ATO
MTS
Marketing
Actividades de mayor
importancia para la
gerencia superior
Contratos de
órdenes de
clientes
Capacidad
productiva
Innovación
Incertidumbres en
Especificaciones
de productos
Utilización de los
recursos de
producción
Variedad de
órdenes de
clientes que se
reciben
Ciclos de vida
de los
productos
Complejidad de las
operaciones de …
Ingeniería
Manufactura de
componentes
Ensamblado
Distribución
física
Actividades de mayor
importancia para la
gerencia media
Administración
de proyectos
Subcontrataciones
Plan maestro de
producción y
schedulling
Control de
stock
Sistemas de
información dan
soporte a …
Ingeniería de
productos
Ingeniería de
manufactura
Provisión de
materiales y
entrada de
órdenes
Pronósticos de
demandas y
control de stock
Control del piso de
planta
Distribución
La situación del mercado en compañías del tipo MTO es usualmente mucho más
incierta que en entornos ATO, debido a que no existe un producto que pueda ser
promocionado y cuya demanda pueda ser pronosticada, ya que cada cliente da las
especificaciones de los productos que requiere. En consecuencia, la incertidumbre de las
operaciones está concentrada usualmente en cuánto esfuerzo demandará el proceso
productivo para un trabajo particular.
A menudo estas compañías tienen restringidas sus capacidades para limitar sus
costos fijos; por lo cual tienden a aceptar más órdenes que las que se pueden efectivamente
realizar y subcontratan parte del trabajo. Por ello, la administración de producción está
enfocada en el control del flujo de trabajo y subcontratos. Asimismo, aspectos tales como
control del “lead time” y eficiencia en el uso de los recursos son bastante importantes.
Por su parte, los negocios tipo ETO enfrentan una gran incertidumbre acerca del
contenido de las especificaciones de los clientes. Cada orden de cliente es gestionada como
un proyecto y requiere, por ende, un diseño, una estimación de costos, una lista de
materiales y rutas de producción particulares para ese pedido. El costo, el tiempo de entrega
y la calidad del producto final son determinados en la fase de ingeniería, por lo cual, la
ingeniería de productos es a menudo la actividad más compleja para gestionar.
El foco en la ingeniería de productos implica que la naturaleza de las actividades de
44
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
planificación de la producción no está orientada a los materiales como en empresas ATO, ni
a las capacidades como en organizaciones MTO, sino que está focalizada en los procesos.
La administración de los proyectos está asociada a la gestión de la complejidad de las
actividades guiadas por las órdenes de clientes. Esto incluye control de documentos, control
del cambio de las especificaciones de los productos, control de la calidad, evaluación del
riesgo, reuso de experiencias previas y uso óptimo de las capacidades de personal.
En las industrias de tipo MTS, donde no hay personalización de los productos, se
manufacturan productos estándares teniendo en cuenta pronósticos de demandas. Por ello,
la incertidumbre no radica ni en los procesos productivos que deben ejecutarse para
responder a las órdenes de los clientes, ni en qué tipo de especificaciones de productos se
recibirán; sino en cómo y en cuán largo será el ciclo de vida de los productos que se
manufacturan, con lo cual pueden variar las políticas de producción y stock. Por otra parte,
debido a que la distribución se realiza a partir de un stock generalizado, según los pedidos
de los clientes, la logística de distribución es la actividad que reviste mayor complejidad. Los
sistemas de información dan soporte, principalmente, a la gestión de dicho stock
generalizado, al seguimiento de las entregas (sistemas “track and trace”) y a la realización
de pronósticos de demanda.
Otro concepto que frecuentemente se tiene en cuenta para la clasificación de
ambientes productivos está relacionado con la cantidad de dinero invertida en el desarrollo
de productos o en el proceso productivo, independientemente de las particularidades de las
órdenes del cliente (Wortmann, 1992). Una compañía se denomina:
i)
Orientada al Producto (OPD): si las inversiones fundamentalmente se dirigen al
desarrollo de productos.
ii)
Orientada al Proceso (OPC): si ha hecho considerables inversiones en el
desarrollo del proceso productivo.
iii)
Orientada a los Recursos (OR): si las inversiones son hechas en recursos
(humanos, maquinarias), pero no necesariamente en procesos.
Las clasificaciones mencionadas en esta sección no son excluyentes y una
determinada industria puede pertenecer a más de una categoría. En la Tabla II.2 se
presentan ejemplos de diferentes industrias y su clasificación de acuerdo a los criterios
recientemente presentados.
A efectos de ilustrar esta doble categorización considérese una fábrica de aviones
que invierte billones de dólares en el desarrollo de sus productos sin tener confirmada una
orden de cliente específica. Estas compañías son capaces de incorporar algo de ingeniería
dirigida por la orden del cliente, constituyéndose así, en empresas del tipo Engineer-to-Order
- Orientadas al Producto. La situación es diferente para una empresa aeroespacial
45
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
que produce satélites. Un satélite es fabricado completamente en base a la orden del cliente
por una empresa que tiene la capacidad para hacerlo. Tales compañías son del tipo
Engineer-to-Order - Orientadas a los Recursos. Finalmente, considérese el caso de una
empresa que elabora packaging a medida. En base a las necesidades específicas de cada
cliente la empresa hace el diseño de las cajas de cartón corrugado y de la impresión que
éstas llevan. Una vez producidas se encarga de la distribución; en consecuencia, se
considera que esta empresa es de tipo Engineer-to-order – Orientada a los procesos.
Tabla II.2. Clasificación de diferentes tipos de industria de acuerdo a la posición
del CODP y a la orientación de las inversiones.
ETO
MTO
ATO
Orientada al Producto
Aeronáutica
Máquinas herramientas
Automotriz Pesada
Orientada al Proceso
Packaging
Papel
Siderurgia
Orientada a los
Recursos
Aeroespacial
Fundición
Construcción
A partir del análisis presentado es posible observar las disímiles características que
presentan los productos en los distintos tipos de organizaciones productivas. Asimismo se
puede apreciar que la información específica de productos a gestionarse cambia con el tipo
de industria.
Por ejemplo, en un entorno MTS es indispensable contar con información acerca de
la logística de distribución de los productos, pronósticos de demanda de cada producto (por
zona geográfica, por segmento de mercado, etc.). Sin embargo, no se requiere información
para llevar a cabo la trazabilidad de la orden de producción para un determinado cliente, ya
que los productos que se manufacturan se destinan a un stock generalizado y no están
asociados a un cliente específico como sucede en los entornos ATO, MTO y ETO. En estos
últimos, cada orden de producción está vinculada a un pedido de cliente, el cual indicará qué
componentes
ensamblar,
qué
componentes
producir
o
qué
productos
diseñar,
respectivamente. En consecuencia, la información que se requiere y/o la forma en que se
emplea en cada uno de estos casos es diferente.
Por otra parte, dependiendo del tipo de entorno productivo los distintos sistemas de
soporte empleados se focalizan en diferentes aspectos, demandando información diversa
vinculada a los productos. Estos sistemas de soporte son, según Wortmann (1995), de dos
tipos: de transacciones y de toma de decisiones. Los primeros soportan la actividad diaria de
las organizaciones mientras que los segundos ayudan a la planificación estratégico-táctica.
Los sistemas de transacciones son clasificados por este autor en “independientes del flujo de
órdenes y materiales” y “dependientes” de dicho flujo. Estos dos tipos de sistemas tendrán
46
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
diferente importancia según se trate de un entorno MTS, ATO, MTO o ETO ya que en cada
uno de ellos, el CODP determina el punto a partir del cual el flujo de órdenes comienza a
influir sobre las actividades productivas. En consecuencia, cuanto más cerca del final del
proceso de manufactura se encuentre dicho punto, más importancia tendrán los sistemas
independientes por sobre los dependientes. Contrariamente, a medida que el CODP se
desplaza hacia las primeras etapas de producción, la importancia de los sistemas
dependientes del flujo de órdenes comienza a crecer, en tanto decrece la de los sistemas
independientes.
La información que es gestionada por los sistemas independientes del flujo de
órdenes está relacionada principalmente con el BOM, las rutas de manufactura y las
capacidades productivas. Esta información es usada de manera diferente según se trate de
un ambiente MTS o de un ambiente ETO. En el primer caso es usada en las actividades de
planificación y control de la producción para generar planes de requerimientos de materiales
y de capacidades, por lo cual debe ser consistente, completa y actualizada. En un entorno
ETO, en cambio, es empleada sólo como información de referencia para el diseño de
soluciones específicas para cada cliente. Por ello, los requerimientos de completitud,
consistencia y actualidad no son tan estrictos en este último caso.
En los sistemas de información dependientes del flujo de órdenes, las órdenes de
clientes juegan un rol importante tanto en un entorno MTS como en uno ETO. La diferencia
radica en lo que representa una orden de cliente en cada uno de los ambientes. En una
empresa MTS, una orden es una lista de ítems que deben ser entregados en determinadas
cantidades y en una fecha dada. En cambio, en una compañía ETO, representa un conjunto
de especificaciones de diseño.
Estos son algunos de los tantos aspectos en que estos dos tipos de entornos difieren
en el manejo de la información de productos. A modo de resumen, la Tabla II.3 presenta una
comparación de las características mencionadas en los párrafos precedentes en relación a
cada uno de los entornos analizados.
A partir del análisis presentado en la primera sección de este capítulo, es posible
observar las disímiles características que presentan los productos en los distintos tipos de
organizaciones productivas. Consecuentemente, la definición de un modelo de productos
que considere correctamente todas las particularidades de cada uno de los distintos tipos de
organizaciones es un objetivo casi imposible de alcanzar.
Por lo hasta aquí expuesto, resulta necesario restringir el alcance de este trabajo, de
manera de: i) abarcar las particularidades comunes a un grupo de organizaciones
productivas; y ii) permitir la extensión del modelo que se propone para contemplar las
características específicas de cada organización. Al respecto, se tomará como información a
47
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
modelar todos aquellos aspectos que se vinculan con la representación de la estructura de
los productos manufacturados. La problemática relacionada con las estructuras de los
productos ya fue introducida en el Capítulo I. Los puntos más complejos de la representación
de estas estructuras estaban dados por la existencia de:
múltiples variantes de productos con estructuras similares,
estructuras híbridas, en las cuales existen tanto relaciones de composición
como de descomposición,
caminos de producción alternativos, que permiten la obtención de un producto
de diferentes maneras.
Tabla II.3. Comparación de la información de productos en entornos MTS y ETO
MTS
ETO
Información de BOMs y rutas de
producción
Totalmente conocida al
momento de recibir la orden
del cliente
Incierta al momento de recibir
la orden del cliente
Estandarización de los productos
Altamente estandarizados
Particulares a cada cliente
Órdenes de cliente
Lista de ítems
Conjunto de especificaciones
de diseño
Identificación del producto
durante el proceso productivo
Por número de parte
Por orden de trabajo
Explosión de requerimientos
Definida a partir del BOM por
la actividad de planificación
de requerimientos de
materiales
Se define en la fase de
ingeniería de productos
Para ejemplificar esta problemática, la siguiente sección presenta dos casos de
estudio de industrias de tipo MTS del sector alimenticio, las cuales serán utilizadas a lo largo
de la Tesis para ilustrar los conceptos propuestos. En ambos casos, se trata de industrias,
cuyos modelos de productos son gestionados actualmente de manera tradicional; es decir
que cada variante es representada como un producto diferente.
II.3. CASOS DE ESTUDIO
Debido a que diferentes industrias tienen distintas necesidades de información, se
consideró conveniente durante el desarrollo de esta Tesis trabajar con dos casos de estudio
distintos que permitan ejemplificar todos los aspectos del modelo propuesto. Es por ello que
se presentan en esta sección las problemáticas que conlleva la gestión de los productos de
una planta de producción de golosinas y los de una industria frigorífica. En ambos casos
existe una enorme cantidad de variantes para cada producto. El segundo, además, es un
48
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
caso típico donde existen productos con estructuras complejas, así como también diferentes
estructuras para un mismo producto. Es importante aclarar que estos casos de estudio se
utilizarán a lo largo de la Tesis para ejemplificar los conceptos que se irán presentando.
II.3.1. Modelo de productos de una planta de producción de golosinas
La información presentada en esta sección corresponde a los datos de productos de
la planta de caramelos duros y rellenos de la División de Golosinas de un importante grupo
industrial de Argentina. Se ha tomado parte del modelo de productos de dicha organización,
el cual se encuentra descrito en mayor detalle en Giménez (2005). Por razones de
confidencialidad se han cambiado los nombres de los mercados, los productos y se emplean
códigos y descripciones de fantasía.
Los productos terminados que salen de la planta bajo estudio son vendidos en dos
grandes segmentos: mercado interno y mercado externo. Además, cada uno de ellos puede
ser fragmentado según tipo de cliente en agrupaciones más pequeñas. Muchos de estos
productos tienen un comportamiento similar en dichos mercados, por ejemplo, en la
estacionalidad de la demanda. De igual manera se hallan similitudes muy manifiestas entre
ciertos productos, los cuales muchas veces difieren solamente en la etiqueta del envase,
respondiendo a exigencias reglamentarias e idiomáticas del país de destino. En cualquiera
de los dos segmentos de mercado los productos que se presentan corresponden a tres
marcas: Bs, KIM y ROC, las cuales son ofrecidas en una gran variedad de presentaciones.
En consecuencia, la cantidad de productos similares que se manejan en la organización es
muy elevada. Los mismos se clasifican dentro de alguna de las siguientes categorías, a
saber:
Producto Terminado (PT)
Semielaborado (SE), o Ensamblado Intermerdio (EI)
Materia Prima (MP)
Material de Empaque (ME)
Esta clasificación contempla si el producto es elaborado dentro de la planta (SE y PT)
o es provisto por terceros (MP y ME). Aquí tanto MP como ME son dos casos particulares de
materia prima, agrupando dentro de este concepto a todos aquellos materiales que son
adquiridos a un proveedor externo a la empresa y que posteriormente reciben un
procesamiento dentro de las instalaciones industriales dispuestas para tal fin. La distinción
entre una y otra categoría reside en el tipo de procesamiento recibido, así pues a la MP se le
realiza una transformación con el fin de obtener los semielaborados, a los cuales se les
adiciona el ME (el cual no sufre transformación alguna) para obtener o bien otro
semielaborado, o un producto terminado. La planta en cuestión gestiona alrededor de 200
49
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
productos finales (PF), 300 ensamblados intermedios (EI), más de 150 materias primas y
500 materiales de empaque diferentes. Para hacer más sencillo el ejemplo, se tomaron
únicamente 70 PT y los semielaborados (180), materias primas (62) y materiales de
empaque (230) requeridos por éstos.
En lo que respecta a la codificación de los productos que se presentarán a
continuación, se utilizará un código que consta de 10 caracteres (2 letras + 6 dígitos) y
responde al siguiente patrón: los dos primeros caracteres representan la categoría del
producto: PT, SE, MP o ME respectivamente. Los siguientes dígitos identifican un producto
particular dentro de la categoría definida por los primeros caracteres del código. De esta
manera, el código SE208395 representa al colorante ColRojoRt54, en tanto, ME211452
corresponde al material de empaque CajaCarx750GR
Todos los productos finales son obtenidos mediante operaciones de transformación y
ensamblado, es decir que tienen una estructura de composición. A partir de distintas
materias primas se manufacturan los diferentes semielaborados intermedios y a estos se les
incorpora una serie de materiales de empaque para obtener así el producto final.
Si se adopta un BOM multinivel para representar la estructura de estos productos, se
tienen entre 5 y 8 niveles dependiendo del producto particular. La Figura II.6 presenta una
estructura genérica que esquematiza la estructura de todos los productos que se analizarán.
El nivel 0 es una composición del semielaborado SE1, el material de empaque y el
material necesario para armar el ballet, representados por los componentes genéricos MEi.
SE1 corresponde a una bolsa, o una caja de cartulina más una etiqueta, que contiene
caramelos individuales envueltos (SE2). Estos caramelos pueden ser del mismo o diferente
tipo. En el nivel 3, se presentan el ensamblado SE3, denominado caramelo desenvuelto,
más el papel envoltorio (ME3.1) y el papel separador (ME3.2). Debajo de ese nivel, se
componen ensamblados intermedios y materias primas para producir cada SEi. El caramelo
desenvuelto se obtiene de una masa y un relleno, en el caso de caramelos rellenos. Por su
parte, la masa (SE4.2) se elabora a partir de almíbar y de otros ingredientes, los cuales
pueden ser semielaborados (SE5.2), como el caso de algunos colorantes (SE5.3), o
materias primas (MP5.i), como el ácido cítrico y las esencias saborizantes. Lo mismo es
válido para el relleno (SE.4.1), compuesto por colorante (SE5.1) y otras materias primas
(MP6.i). En el nivel 6 se encuentran el colorante (SE6.1) y las distintas materias primas
(MP6) de las que se compone el almíbar. En algunas ocasiones se adiciona leche
condensada, que también estaría ubicada como semielaborado en el nivel 6. Por último, en
el nivel 7 se incluye a las materias primas a partir de las que se elaboran los colorantes y la
leche condensada (MP7.i). Es importante aclarar que para algunos productos, el nivel 1 y el
nivel 2 aparecen fusionados en un único nivel, en el cual figuran como componentes los
50
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
caramelos envueltos (SE2.1) por un lado y los materiales para embolsarlos (ME2.i), por otro;
así como los materiales de empaque del nivel 1 (ME1.i). Tal es el caso del ejemplo del
producto final que se muestra en la Figura II.7.
P
Nivel 0
ME
1.1
SE1
Nivel 1
ME
2.1
Nivel 2
ME
2.n
SE
3.1
Nivel 3
Nivel 5
Nivel 7
ME
3.1
ME
3.2
MP
6,1
SE
4.2
MP
5.1
SE
5.1
ME
1.n
SE
2.1
SE
4.1
Nivel 4
Nivel 6
ME
1.2
MP
5.n
MP
6,n
SE
6.1
MP
7.1
SE
5.3
SE
5.2
MP
6,n+1
MP
7.n
MP
6,i
MP
6.i+1
MP
5.n+1
MP
6.m
MP
5.m
MEi
Materia de Empaque i
MPi
Materia Prima i
Pi
Producto Teminado
SEi
Ensamblado Intermedio
Figura II.6 Estructura genérica de un producto
Nivel 0
Nivel 1
Nivel 2
Nivel 3
Nivel 4
Nivel 5
Nivel 6
51
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Figura II.7. Árbol de estructura multinivel para el producto PT112608
(FrutalRelleno5x750GR)
En la Figura II.7 se presenta el árbol de estructura del producto terminado PT112608
(FrutalRelleno5x750GR.) Éste corresponde a una caja de cartón corrugado que contiene 5
bolsas de 750 grs de caramelos de 5 sabores frutales (en proporciones iguales). Cada uno
de los tipos de caramelos envueltos que se incluye está especificado por uno de los
semielaborados (SExxxxxx) que se encuentra en el nivel 1.
Los semielaborados que forman parte de esta estructura corresponden a caramelos
individuales de los denominados “BolsínSaborX5GREnv” marca ROC en los siguientes
sabores: pera (SE511606), pomelo (SE511607), lima (SE511609), frutilla (SE511605) y cereza
(SE511610). La Tabla II.4 presenta el listado de materiales de un nivel, correspondiente al
producto final en cuestión.
Tabla II.4. BOM de un nivel del producto PT112608 (FrutalRelleno5x750GR)
Componente
SE511605
SE511606
SE511607
SE511609
SE511610
ME712167
ME216641
ME108446
ME408998
ME211452
ME107932
ME215741
BolsínFrutilla5GREnv
BolsínPera5GREnv
BolsínPomelo5GREnv
BolsínLima5GREnv
BolsínCerez5GREnv
PeRellenoF750GR
EtFrutal5x750GR
SeparadorT678
PExtensibleb89
CajaCarx750GR
CintaAdh50x1200
EtiqueraFrutal750GR
Unidades
requeridas
1.046520
1.046520
1.046520
1.046520
1.046520
0.043890
1
0.03
0.0041
Unidad de
medida
KG
KG
KG
KG
KG
KG
UNID
UNID
KG
*
*
1
0.93
UNID
M
*
*
6
UNID
De igual manera se presentan en las Tablas II.5 y II.6 los componentes de otros
productos
finales:
PT109446
(RedondoFrutaKIM5x750GR)
y
PT109449
(VaritaKIM5X750GR). En cada una de dichas tablas se marcaron con un asterisco (*)
aquellas partes que son comunes a las tres estructuras y con el símbolo ⊕, las que se
repiten en 2 de las estructuras. Los elementos resaltados corresponden a partes del tipo
material de empaque. Las tres estructuras difieren en los caramelos individuales que
incorporan y en los elementos de rotulado. Sin embargo, más adelante se podrá apreciar
que, si bien son considerados productos diferentes, parte de las estructuras de estos
caramelos individuales son casi idénticas.
Bajando un nivel en la estructura que se presentó en la Figura II.7, se analizarán a
continuación los caramelos envueltos. Se considerará el caso de los caramelos sabor frutilla
SE508219
(VaritaKIMFrutillaEnv),
SE511605
(BolsínFrutilla5GREnv)
y
SE511714
(FrutillaKIM5GREnv), cuyas estructuras se presentan seguidamente en la Figura II.8 y en las
52
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Tablas II.7 a II.9.
Tabla II.5. BOM de un nivel del producto PT109446
(RedondoFrutaKIM5x750GR)
Componente
ME712242
ME217040
ME217009
ME108446
ME408998
ME107932
ME211452
SE511710
SE511711
SE511712
SE511714
SE511713
PeCarKIMx750GR
EtFrutalKIM750ws
EtFrutalKIM750p
SeparadorT678
PExtensibleb89
CintaAdh50x1200
CajaCarx750GR
PeraKIM5GREnv
PomeloKIM5GREnv
LimaKIM5GREnv
FrutillaKIM5GREnv
CerezaKIM5GREnv
Unidades
requeridas
0.045753
6
1
0.033
0.0041
0.96
1
1.026556
1.026556
1.026556
1.026556
1.026556
Unidad de
medida
KG
UNID
UNID
UNID
UNID
M
UNID
KG
KG
KG
KG
KG
⊕
*
*
*
*
Tabla II.6. BOM de un nivel del producto PT1009449 (VaritaKIM5X750GR)
Componente
SE508207
SE508219
SE508246
SE508247
SE508253
ME712242
ME217041
ME2017045
ME108446
ME408998
ME107932
ME211452
VaritaKIMPeraEnv
VaritaKIMFrutillaEnv
VaritaKIMDuraznoEnv
VaritaKIMPomeloEnv
Varita KIM LimaEnv
PeCarKIMx750GR
EtVaritaKIM750
EtVaritaKIM22x80
SeparadorT678
PExtensibleb89
CintaAdh50x1200
CajaCarx750GR
Unidades
requeridas
1.014614
1.014614
1.014614
1.014614
1.014614
0.045753
6
1
0.025
0.03
0.93
1
Unidad de
medida
KG
KG
KG
KG
KG
KG
UNID
UNID
UNID
UNID
M
UNID
⊕
*
*
*
*
Tabla II.7. BOM de un nivel del producto SE508219 (VaritaKIMFrutillaEnv)
Componente
SE408193
ME308386
VaritaFrutillaDes
EnvVaritaKIMFrutilla
Unidades
requeridas
0.958
0.042
Unidad de
medida
KG
KG
Tabla II.8. BOM de un nivel del producto SE511605 (BolsínFrutilla5GREnv)
Componente
SE411614
BolsínFrutilla5GRDes
Unidades
requeridas
0.930232
Unidad de
medida
KG
53
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
ME908441
ME113307
PapelSepBolsín
EnvBolsínFrutillaROC
0.034108
0.035659
KG
KG
Tabla II.9. BOM de un nivel del producto SE511714 (FrutillaKIM5GREnv)
Componente
SE411614
ME910113
ME108346
BolsínFrutilla5GRDes
InteriorBolsin
EnvBolsínFrutillaKIM
Unidades
requeridas
0.946857
0.016672
0.036471
Unidad de
medida
KG
KG
KG
En la Figura II.8 es posible observar que en todos los casos, un caramelo envuelto se
compone de un semielaborado y de uno o dos materiales de empaque. El semielaborado
corresponde al caramelo desenvuelto y los materiales de empaque a los papeles usados
para envolver dicho caramelo. Algunos caramelos llevan sólo un papel de envoltorio y otros
además de éste cuentan con un papel separador. Se aprecia en la figura que el caramelo
SE508219 (VaritaKIMFrutillaEnv) posee solamente el papel envoltorio ME2017045
(EnvVaritaKIMFrutilla); mientras que los otros dos tienen un papel separador (ME908441 y
ME910113) y los correspondientes papeles de envoltorio (ME113307 y ME108346).
Figura II.8. Estructuras de tres semielaborados tomados como ejemplo
Asimismo, existe también otro producto intermedio, el SE508482 (BolsínFrutillaZ),
que se muestra en la Tabla II.10, cuya composición es similar al caramelo envuelto
SE511605 (Tabla II.8). En las Tablas II.8 y II.10 puede observarse que estos dos caramelos,
sólo difieren en el semielaborado que corresponde al caramelo desenvuelto, ya que ambos
poseen el mismo material de empaque. En un caso se trabaja con el SE411614
(BolsínFrutilla5GRDes) y en el otro con el SE408215 (BolsínFrutillaDes). En la Figura II.9
pueden observarse las coincidencias en las estructuras de estos semielaborados. A su vez,
como puede apreciarse en las Tablas II.11 y II.12, estos productos tienen los mismos
componentes: una masa sabor frutilla SE609259 y un relleno sabor frutilla SE808945. Sin
54
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
embargo, las cantidades de composición que se definen en uno y otro caso son diferentes.
En la Figura II.9 también pueden observare las coincidencias en las estructuras de estos dos
semielaborados.
Figura II.9. Ejemplo de caramelos desenvueltos con estructuras similares
Tabla II.10. BOM de un nivel del producto SE508482 (BolsinFrutillaZ)
Componente
SE408215
ME908441
ME113307
BolsínFrutillaDes
PapelSepBolsín
EnvBolsínFrutillaROC
Unidades
requeridas
936.13
30.00
30.87
Unidad de
medida
GR
GR
GR
Tabla II.11. BOM de un nivel del producto SE411614
(BolsínFrutilla5GRDes)
Componente
SE808945
SE609259
Relleno Frutilla
MasaFrutilla
Unidades
requeridas
17
83
Unidad de
medida
GR
GR
Tabla II.12. BOM de un nivel del producto SE408215 (BolsínFrutillaDes)
Componente
SE808945
SE609259
Relleno Frutilla
MasaFrutilla
Unidades
requeridas
19
81
Unidad de
medida
GR
GR
En este punto es importante aclarar que de la muestra de productos a la que se tuvo
acceso, solamente 6 caramelos individuales desenvueltos no incorpora relleno. El resto de
los caramelos individuales desenvueltos está compuesto, en todos los casos, de una masa y
un relleno. Si bien el caso de los caramelos rellenos conduce al manejo de productos con
estructuras más complejas, es posible apreciar que éstos poseen estructuras muy similares,
que merecerían un tratamiento particular.
55
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Continuando con el caso de estudio, se analizará la situación de los caramelos
individuales de una misma marca destinados a un mismo mercado, pero que tienen diferente
sabor. Se tomarán para este estudio los caramelos rellenos frutales con formato bolsín de 5
GR marca ROC. Este tipo de caramelos es producido en 5 sabores: Pera (SE511606),
Frutilla (SE511605), Cereza (SE511610), Pomelo (SE511607) y Lima (SE511609). La
estructura del segundo tipo (frutilla) ya ha sido introducida en la Figura II.9. De igual manera,
la composición del caramelo sabor cereza se presentó en la Figura II.7, mientras que los
otros sabores se ilustran a continuación en la Figura II.10.
Figura II.10. Estructura de caramelos desenvueltos de diferentes sabores frutales
Es posible observar en las figuras precedentes que en todos los casos, los caramelos
se componen de dos partes que pertenecen al grupo de materiales de empaque y de un
semielaborado que es el caramelo propiamente dicho. Las dos primeras corresponden a un
papel separador que siempre es el mismo (ME908441), y un papel envoltorio, que es
diferente para cada caso, ya que está en relación directa con el sabor del caramelo que está
envolviendo. Asimismo, todos los semielaborados se componen de una masa y un relleno
del
correspondiente
sabor.
Por
ejemplo,
el
producto
intermedio
SE411618
(BolsínLima5GRDes) se compone de una masa y un relleno sabor lima (semielaborados
SE609151 y SE808947 respectivamente)
Todos estos semielaborados (masas y rellenos) tienen una composición similar, sólo
difieren en los colorantes y las esencias utilizados para otorgarles un determinado sabor y
aspecto. La Figura II.11 y las Tablas II.13 a II.17 presentan las composiciones
correspondientes a cada uno de los rellenos ilustrados en la figura mencionada.
Tabla II.13. BOM de un nivel del producto SE808943 (RellenoPera)
Componente
Unidades
requeridas
Unidad de
medida
56
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
MP108910
SE808324
EsenciaPeraP33
RellenoMermelada
4.95253
995.04
GR
GR
Tabla II.14. BOM de un nivel del producto SE808944 (RellenoCereza)
Componente
SE208786
MP108922
SE808324
ColRojoRx43
EsenciaCerezaP34
RellenoMermelada
Unidades
requeridas
3.78
4.934
991.284
Unidad de
medida
GR
GR
GR
Tabla II.15. BOM de un nivel del producto SE808945 (RellenoFrutilla)
Componente
SE208786
MP108842
SE808324
ColRojoRx43
EsenciaFrutillaP35
RellenoMermelada
Unidades
requeridas
3.78
4.933
991.28
Unidad de
medida
GR
GR
GR
Tabla II.16. BOM de un nivel del producto SE808946(RellenoPomelo)
Componente
MP108657
SE208570
SE808324
EsenciaPomeloP32
ColAmarilloYz3
RellenoMermelada
Unidades
requeridas
4.27877
3.78
991.93
Unidad de
medida
GR
GR
GR
Tabla II.17. BOM de un nivel del producto SE808947 (RellenoLima)
Componente
MP108616
SE209075
SE808324
EsenciaLimaP31
ColAnaranjadoOm4
RellenoMermelada
Unidades
requeridas
4.27877
3.78
991.93
Unidad de
medida
GR
GR
GR
57
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Figura II.11. Composición de distintos rellenos frutales
Todos los rellenos presentados, con excepción del de pera, se componen de una
base de relleno de mermelada, más una esencia y un colorante correspondiente al sabor del
relleno que se quiere obtener. Teniendo en cuenta las cantidades de composición, se puede
observar que las estructuras de los rellenos sabor cereza y sabor frutilla difieren únicamente
en la esencia que se les incorpora ya que la cantidad de esencia es la misma y el resto de
las relaciones de composición son idénticas (el mismo componente e igual cantidad). Para
los rellenos de pomelo y lima las cantidades de composición son iguales, pero tanto el
colorante como la esencia difieren. A diferencia del resto de los caramelos, al no tener
esencia, las cantidades de composición en el relleno de pera no coinciden con ninguno de
los otros rellenos presentados.
Prosiguiendo con el ejemplo, en la Figura II.12 y las Tablas II.18 a II.22 se presentan
las estructuras asociadas a las masas utilizadas en los caramelos desenvueltos que están
siendo analizados.
Tabla II.18. BOM de un nivel del producto SE609150 (MasaPera)
Componente
SE108451
MP108910
MP107962
AlmíbarT1
EsenciaPeraP33
ÁcidoZ36
Unidades
requeridas
1191
3.099
12.5
Unidad de
medida
GR
GR
GR
Tabla II.19. BOM de un nivel del producto SE609152 (MasaCereza)
Componente
SE108451
AlmíbarT1
Unidades
requeridas
1191
Unidad de
medida
GR
58
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
SE208786
MP108922
MP107962
ColRojoRx43
EsenciaCerezaP34
ÁcidoZ36
2.4
3.157
12.5
GR
GR
GR
Tabla II.20. BOM de un nivel del producto SE609259 (MasaFrutilla)
Componente
SE108451
SE208786
MP108842
MP107962
AlmíbarT1
ColRojoRx43
EsenciaFrutillaP35
ÁcidoZ36
Unidades
requeridas
1192
2.4
2.9
11.5
Unidad de
medida
GR
GR
GR
GR
Tabla II.21. BOM de un nivel del producto SE609149 (MasaPomelo)
Componente
MP108657
SE108451
SE208570
MP107962
EsenciaPomeloP32
AlmíbarT1
ColAmarilloYz3
ÁcidoZ36
Unidades
requeridas
2.727
1191
2.4
12.5
Unidad de
medida
GR
GR
GR
GR
Tabla II.22. BOM de un nivel del producto SE609151 (MasaLima)
Componente
SE108451
MP108616
SE209075
MP107962
AlmíbarT1
EsenciaLimaP31
ColAnaranjadoOm4
ÁcidoZ36
Unidades
requeridas
1191.329
2.727
2.4
12.5
Unidad de
medida
GR
GR
GR
GR
59
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Figura II.12. Composición de las masas frutales
Al igual que en el caso de los rellenos, la masa de pera no lleva colorante, por lo cual
es la que presenta una estructura con mayores diferencias respecto de las otras masas. En
el resto de los casos planteados, para obtener la masa se utiliza: almíbar, ácido Z36,
colorante y esencia. Los dos primeros componentes corresponden al mismo producto en
todos los casos, mientras que el colorante y la esencia dependen del sabor del caramelo que
quiere elaborarse. Por ejemplo, la esencia de lima (MP108616) y el colorante anaranjado
(SE209075) serán utilizados para obtener un caramelo de lima (SE609151); en cambio, si se
pretende un caramelo sabor pomelo (SE609149) se utilizará colorante amarillo (SE208570) y
esencia de pomelo (MP108657). Respecto a las cantidades de composición, son
exactamente las mismas para los sabores de Pomelo y Lima. Mientras que se observó que
los caramelos de frutilla y cereza poseen igual composición para sus rellenos, sin embargo,
sus masas tienen una pequeña diferencia en las cantidades de composición.
Si se analiza lo que ocurre con otras masas, es posible encontrar que estas
semejanzas en las estructuras se mantienen. Como ejemplo de esto, se presentan a
continuación las estructuras correspondientes a todas las masas de sabor frutilla utilizadas
en diferentes tipos de caramelos, a saber:
SE311862(MasaFrutillaEFE)
SE609259 (MasaFrutilla)
SE609198 (MasaFrutillaMIX)
SE313862(MasaFrutillaOK)
60
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Las estructuras de estas masas se muestran a través de los correspondientes grafos
que se presentan en la Figura II.13, complementados con las listas de materiales que para
cada caso se introducen en las diferentes tablas. Éstas son la Tabla II.18 para el caso ya
analizado, y las Tablas II.23 a II.25 para las estructuras que se introducen aquí por primera
vez.
Tabla II.23. BOM de un nivel del producto SE609198 (MasaFrutillaMIX)
Componente
SE108451
SE208786
MP108842
MP107962
AlmíbarT1
ColRojoRx43
EsenciaFrutillaP35
ÁcidoZ36
Unidades
requeridas
1196.571
0.8
3.0
6.0
Unidad de
medida
GR
GR
GR
GR
Tabla II.24. BOM de un nivel del producto SE313862 (MasaFrutillaOK)
Componente
SE113861
SE208786
MP108842
MP107962
AlmíbarT2
ColRojoRx43
EsenciaFrutillaP35
ÁcidoZ36
Unidades
requeridas
1192.28
2.4
2.9
11.5
Unidad de
medida
GR
GR
GR
GR
Tabla II.25. BOM de un nivel del producto SE311862 (MasaFrutillaEFE)
Componente
SE108451
SE208786
MP108219
MP107962
AlmíbarT1
ColRojoRx43
EsenciaFrutillaB97
ÁcidoZ36
Unidades
requeridas
1175.275
2.4
1.057
25.0
Unidad de
medida
GR
GR
GR
GR
Como ocurre en los diferentes sabores analizados más arriba, para el caso de las
masas sabor Frutilla, es posible observar que todas tienen estructuras similares. El colorante
y el ácido son los mismos para todos los productos; pero, en algunos casos, difieren en las
cantidades utilizadas. El almíbar, al igual que la esencia, es el mismo en tres de las cuatro
masas.
61
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Figura II.13. Composición de rellenos sabor frutilla
Es importante mencionar, que estas masas son similares también a las
correspondientes al sabor cereza. Basta observar las Tablas II.19 y II.20 para apreciar las
similitudes, las cuales se repiten para los otros tipos de masas sabor cereza que existen y
cuyas
estructuras
se
presentan
SE609109(MasaCerezaEFE.);
en
ii)
las
tablas
SE613935
II.26
a
II.28,
a
(MasaCerezaOK);
saber:
y
i)
iii)
SE608394(MasaCerezaA).
Hasta aquí se han analizado siempre caramelos del tipo frutal; pero este análisis
podría extenderse a caramelos de otros sabores no frutales. En estos casos, se presentan
situaciones similares en lo que respecta a las estructuras de masas y rellenos de los
caramelos desenvueltos y a las estructuras de los caramelos envueltos que siguen el patrón
ya mencionado (papel envoltorio + papel separador + caramelo desenvuelto).
Tabla II.26. BOM de un nivel del producto SE613935 (MasaCerezaOK)
Componente
SE113861
SE208786
MP108922
MP107962
AlmíbarT2
ColRojoRx43
EsenciaCerezaP34
ÁcidoZ36
Unidades
requeridas
1190.715
2.4
3.157
12.5
Unidad de
medida
GR
GR
GR
GR
Tabla II.27. BOM de un nivel del producto SE608394 (MasaCerezaA)
Componente
SE208395
MP108245
SE109547
ColRojoRt54
EsenciaCerezaB21
Almíbar F1DE
Unidades
requeridas
1.494
3.89
1198.330
Unidad de
medida
GR
GR
GR
62
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
MP107962
ÁcidoZ36
15.0
GR
Tabla II.28. BOM de un nivel del producto SE609109 (MasaCerezaEFE)
Componente
SE108451
SE208786
MP108922
MP107962
AlmíbarT1
ColRojoRx43
EsenciaCerezaP34
ÁcidoZ36
Unidades
requeridas
1172.171
2.36
3.548
25.0
Unidad de
medida
GR
GR
GR
GR
II.3.2. Modelo de productos de una industria frigorífica
Este caso de estudio, presenta la problemática relacionada con los productos de una
industria frigorífica. La organización constituye una red de playas de faena y plantas de
producción (plantas de despostada, manufactura de conservas, preparación y envasado de
menudencias, etc.) ubicadas en diferentes lugares del país, a través de las cuales se
concretan los diversos negocios. La empresa en cuestión se estructura en función de
distintas áreas de negocios que derivan del ganado vacuno, entre las que se destacan:
medias reses, cortes cárnicos frescos enfriados y congelados, así como carnes cocidas
congeladas y enlatadas, chacinados, etc. Uno de sus negocios más significativos
corresponde a los cortes cárnicos frescos, los cuales representan un 60% de los ingresos de
la empresa y se destinan mayormente al mercado externo, aunque también alcanzan el
mercado interno a través de los hipermercados.
Dada la complejidad de la organización este análisis se focalizará en el negocio de
los cortes frescos, junto con los subproductos que permiten obtener las carnes cocidas,
congeladas y enlatadas.
Todas las partes del cuerpo del animal bovino son aprovechables; es decir, pueden
ser comercializadas como tales o luego de algún proceso de manufactura, como es el caso
de los huesos, lengua, rabo, pezuñas, entrañas, nervios y pellejos, grasa, etc., así como los
trozos de carne que resultan como subproductos durante la preparación de los cortes
cárnicos que se comercializan. La industria cárnica produce en grandes cantidades un
amplio rango de productos que pueden clasificarse en:
Cortes cárnicos enfriados: Cortes individuales seleccionados de animales
bovinos, enfriados a 0OC y envasados al vacío para ser vendidos en
mercados locales o internacionales.
Cortes cárnicos congelados: Cortes individuales seleccionados de bovinos,
congelados a -18OC.
Menudencias: menudencias seleccionadas, congeladas y empaquetadas
individualmente.
63
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Carnes cocidas enlatadas (CCE): conservas, corned beef.
Carnes cocidas congeladas (CCC) que luego son usadas como materias
primas por otras empresas alimenticias.
Cada uno de los productos que pertenecen a estas categorías, a su vez, es
comercializado en diferentes presentaciones dependiendo del mercado en el cual es
vendido. En consecuencia, el número de variantes de un mismo producto que se gestiona es
muy alto. De manera ilustrativa, las Tablas II.29 a II.31, presentan ejemplos de cortes
cárnicos congelados de dos diferentes mercados externos; así como productos terminados
correspondientes a carnes cocidas congeladas cubeteadas, rebanadas y picadas, que se
ofrecen en diferentes mercados internacionales y locales.
Tabla II.29. Algunos cortes frescos ofrecidos. Marca A. Mercado USA
Cortes
Lomo
Bife Ancho
Peceto
Cuadril con Tapa
….
Peso medio
1.5 KG
2 KG
1.4 KG
3.5 KG
Envase/ Preservación
Al vacío / Enfriado
Al vacío / Enfriado
IWP
Al vacío/ Enfriado
Presentación
20 KG/Caja
20 KG/Caja
20 KG/caja
20 KG/caja
Tabla II.30. Algunos cortes frescos ofrecidos. Marca B. Mercado
Alemania
Cortes
Lomo
Bife Angosto
Nalga Adentro
Cuadril con Tapa
Garrón
Bife Angosto con
Cuadril y Lomo
…
Peso medio
1.2 KG
1.7 KG
1.4 KG
3.5 KG
4 KG
Envase / Preservación
Al vacío / Enfriado
Al vacío / Enfriado
IWP
Al vacío /Enfriado
Congelado
Al vacío /Enfriado
Presentación
15 KG/Caja
15 KG/Caja
15 KG/caja
15 KG/caja
15 KG/caja
15 KG/caja
Como puede concluirse luego de un análisis de las Tablas II.29 a II.31, en la industria
frigorífica también existe un gran número de variantes de productos. Sin embargo, no se
estudiará en detalle la problemática relacionada con el gran número de variantes existentes,
debido a que la misma ya fue puntualizada en el caso de estudio anterior. Lo que se
pretende aquí es tratar las cuestiones relativas a estructuras de productos mixtas (con
relaciones de composición y descomposición) y estructuras alternativas para algunos de los
productos involucrados en este tipo de industrias. Todos los productos mencionados
anteriormente tienen como materia prima principal el ganado bovino, la cual, a diferencia de
las utilizadas en el caso de los caramelos, es no atómica. La misma es dividida a través de
operaciones de despostada para llegar a obtener productos finales o intermedios, que luego
pasan a ser componentes de algún producto final.
64
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Tabla II.31. Ejemplos de diferentes carnes cocidas congeladas
Producto
Mercados
CCCCub1
Alemania
CCCCub2
USA
CCCCub3
USA
CCCCub4
Italia
CCCCub5
Italia
CCCCub6
Alemania
CCCCub7
Suiza
CCCCub1
Alemania
CCCReb1
Europa
CCCReb2
USA
CCCReb3
Italia
CCCReb4
Alemania
FPB1
Europa
FPB2
Local
FPB3
USA
FPDCva
Local
FPD2
USA
FPD1
Europa
Tipos
Cubeteada
Rebanada
Picada Tipo1
Picada Tipo2
El ganado bovino que se adquiere como materia prima, además de corresponder a
diferentes razas, es clasificado y tipificado dando lugar a distintas calidades de materia
prima. Dicha clasificación establece categorías de animales según edad, peso y sexo del
ganado. Por su parte, la tipificación determina tipos de animales según su calidad,
basándose, entre otros aspectos, en el grado de gordura (cantidad y distribución de la
grasa), la conformación de las masas musculares, así como proporción de carne y hueso en
las regiones de cortes más valiosos. El grado de gordura puede ser: 0-magro, 1-escaso, 2moderado, 3-abundante y 4-excedido. En las Tablas II.32 a II.34 se presentan estas
categorizaciones que determinan los diferentes tipos de materias primas.
Tabla II.32. Categorización del ganado bovino en base al peso
Categorías
Escala de pesos (KG/media res)
Novillo
más de 117
Novillito
hasta 117
65
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Vaquillona
hasta 113
Vaca
más de 113
ternero macho/hembra
hasta 73
Mamón
hasta 50
Toro
sin exigencias
Tabla II.33. Tipificación del ganado bovino y destino del mismo
Categorías Superior Muy Buena Buena Mediana Regular Inferior Baja
Novillo
Novillito
Vaquillona
Vaca
Ternero
Toro
JJ
AA
AA
AA
AA
AA
Exportación
J
A
A
A
A
A
U
U2
B
C
B
C
B
C
B
C
B
B
Consumo Local
N
T
D
E
D
E
D
E
D
E
C
C
Manufactura o Conserva
A
F
F
F
F
C
Tabla II.34. Diferentes calidades de ganado bovino
Categorías
Novillo
Novillito
Vaquillona
Vaca
Ternero
Mamón
Toro
Tipo
Grados de grasa
Escala de pesos
(KG/media res)
JJ-J-U-N
T
A
AA-A-B
D
E
F
AA-A-B
D
E
F
AA-A-B-C-D
E
F
0-1-2-3-4
0-1
Ninguno
0-1-2-3
0-1-2-3
0-1
ninguno
0-1-2-3
0-1-2-3
0-1
ninguno
0-1-2-3-4
0-1-2-3
ninguno
más de 188
sin exigencias
sin exigencias
hasta 117
hasta 108
hasta 95
hasta 95
hasta 113
hasta 103
hasta 85
hasta 85
más de 113
sin exigencias
sin exigencias
AA-A-B-C
D
E
F
A
B
C
AA-A-B-C
0-1-2
0-1-2
0-1
ninguno
0-1
0-1
0-1
0-1-2
hasta 73
hasta 68
hasta 55
hasta 55
hasta 50
hasta 40
hasta 30
sin exigencias
A efectos de mostrar algunas de las problemáticas de este tipo de industria
considérese que a partir de cada cabeza de ganado se obtienen dos medias reses, cada una
de las cuales a su vez se vuelve a dividir en cuarto delantero, cuarto trasero y algunos otros
productos intermedios. Dependiendo de la operación de despostada (desarmado) que se
66
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
aplique sobre la media res, se obtienen diferentes formas de cuartos delanteros y traseros,
los que son considerados productos diferentes.
En particular, los productos CuartoTCorte1, CuartoTCorte2, CuartoTCorte3 son
semielaborados que son la base de la operación de despostada del cuarto trasero. A partir
de cualquiera de éstos es posible obtener los diferentes productos derivados del cuarto
trasero que se muestran en la Figura II.14. Los mismos pueden comportarse como
semielaborados (productos que son sometidos a otras operaciones de terminación) o
productos finales (que se comercializan directamente como tales). Por ejemplo, el Lomo,
puede comercializarse tal como se lo obtiene de la despostada del cuarto trasero (en cuyo
caso se consideraría un producto final) o preparado con menor cantidad de grasa, nervios y
pellejos, de acuerdo a los requerimientos de diferentes clientes (por ejemplo, tal como lo
demandan el Reino Unido, Brasil, etc.). En este último caso, el rol del producto Lomo es el
de un intermediario. En el proceso de despostada del cuarto trasero, además de los
productos mostrados en la Figura II.14 se obtienen subproductos de menor valor comercial.
Ellos son: MP1CarneCocida, MPGrasa, HuesoSinCarne, NerviosyPellejos.
Figura II.14. Algunos productos de valor comercial que se pueden obtener a partir del
cuarto trasero
El
desarmado
de
CuartoTCorte1
mediante
la
operación
denominada
O1CuartoTCorte1 da lugar a los productos intermedios y subproductos que se detallan en la
primera columna de la Tabla II.35. Las siguientes columnas de dicha tabla presentan los
rendimientos para diferentes tipos de animales (NovilloJJ, NovilloJ). Es decir, esta tabla
muestra que la descomposición del CuartoTCorte1 da lugar a diferentes rendimientos para
algunos de los productos obtenidos (por ejemplo, BifeAngosto) dependiendo del tipo de
animal sobre el cual se aplique la operación de descomposición. En la tabla se muestran los
rendimientos para dos tipos diferentes de animales, NovilloJJ y NovilloJ. Sin embargo, en la
práctica, muchas industrias frigoríficas incluyen un mayor número de tipos. Dos tipos
distintos de animales poseen disímiles contexturas y por ende diferentes tamaños de
67
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
algunos de sus cortes cárnicos. Asimismo, la terneza y la composición de cada corte hacen
que los productos de diferentes tipos de animales se destinen a distintos mercados.
Los datos vinculados la Tabla II.35 deben interpretarse de la siguiente manera, por
cada 100 KG de animal vacuno que se faene, el corte CuartoTCorte1 de un animal tipo
NovilloJJ pesa en promedio 40.96 KG y la de un animal tipo NovilloJ pesa 41.68 KG. Es
decir, que si un animal dado pesa 312 KG, es posible calcular cuál es el rendimiento del
corte CuartoTCorte1 y de los productos que de su despostada se obtengan a partir de los
datos anteriores.
Tabla II.35. Descomposición O1CuartoTCorte1 aplicada
sobre el producto CuartoTCorte1
BifeAngosto
BolaLomo
ColitaCuadril
CuadrilCT
CZACuadrada
Garrón
Lomo
NalgaDeAdentroCT
Peceto
Tortuguita
MP1CarneCocida
MPGrasa
HuesoSinCarne
NerviosYPellejos
Total
NovilloJJ
3.86
3.72
1.22
4.10
4.19
2.05
1.775
6.075
1.84
1.56
1.134
0.075
8.32
1.041
40.96
NovilloJ
4.28
3.72
1.22
4.10
4.19
2.05
1.775
6.075
1.84
1.56
1.134
0.085
8.42
1.051
41.68
Una simple comparación entre los productos de la Figura II.14 y los de la Tabla II.35
permite concluir que hay varios productos que se incluyeron en dicha figura pero que no
aparecen en la tabla. Ello ocurre pues existen diferentes formas de descomponer el
semielaborado CuartoTCorte1. Por ejemplo, otra alternativa sería la que se muestra en la
Tabla II.36, donde en lugar de obtener el semielaborado CuadrilCT (Cuadril con Tapa) se
obtienen directamente los semielaborados CuadrilST (Sin Tapa) y TapaCuadril.
Los semielaborados CuadrilST y TapaCuadril podrían obtenerse directamente como
muestra la Tabla II.36 o a partir de la descomposición del CuadrilCT como lo indica la Tabla
II.37. Similares consideraciones podrían hacerse para otros cortes tales como la
NalgaDeAdentroCT que podría descomponerse en NalgaDEAdentroST y TapaNalga, o el
producto Tortuguita del cual puede obtenerse CZONTortuguita (corazón de tortuguita) y
TortuguitaSL.
Como
se
observa,
los
productos
NalgaDeAdentroST,
TapaNalga,
CZONTortuguita y TortuguitaSL no aparecen en las Tablas II.35 ni II.36, pero sí están
incluidos en la Figura II.14.
Como se indicó previamente, los productos CuadrilCT, NalgaDeAdentroCTapa y
68
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Tortuguita pueden ser considerados tanto productos finales como productos intermedios.
Aquí la connotación de producto final se refiere a que dichos productos pueden ser
directamente empacados y vendidos como tales sin sufrir ninguna operación de
procesamiento adicional y. En realidad, se los vende en cajas o contenedores que
comprenden un determinado número de unidades de estos cortes cárnicos.
Tabla II.36. Descomposición OP2CuartoTCorte1
aplicada sobre el producto CuartoTCorte1
BifeAngosto
BolaLomo
ColitaCuadril
TapaCuadril
CuadrilST
CZACuadrada
Garron
Lomo
NalgaDeAdentroCT
Peceto
Tortuguita
MP1CarneCocida
MPGrasa
HuesoSinCarne
NerviosYPellejos
Total
NovilloJJ
3.86
3.72
1.22
0.92
3.18
4.19
2.05
1.775
6.075
1.84
1.56
1.134
0.075
8.32
1.041
40.96
NovilloJ
4.28
3.72
1.22
0.92
3.18
4.19
2.05
1.775
6.075
1.84
1.56
1.134
0.085
8.42
1.051
41.68
Sin embargo, dependiendo de las necesidades y demandas del mercado un producto
dado puede sufrir diversas operaciones de procesamiento dando lugar a nuevos productos
finales y/o intermediarios. Un ejemplo es el que se muestra en la Tabla II.37, donde se
exponen los productos obtenidos (TapaCuadril y CuadrilST) y los rendimientos para dos
tipos de novillos sobre una determinada operación de despostada que se aplica al corte
CuadrilCT (Cuadril con tapa). Otra posible operación de despostada, que se hace sobre el
mismo producto base, es la que se muestra en la Tabla II.38. En este caso se obtienen el
producto final CuadrilCTExp (Cuadril con tapa para exportación) y los subproductos
MPGrasa y NerviosyPellejos. Otra alternativa es la que se exhibe en la Tabla II.39, donde se
obtiene otra variedad de cuadril para exportación al Reino Unido y cuatro subproductos. A
los dos subproductos que aparecían en la Tabla II.38 se agregan MP2CarneCocida y
MP1CarneCocida, que constituyen subproductos que luego serán materias primas para la
elaboración de carnes cocidas.
Tabla II.37. Descomposición OP1CuadrilCT aplicada
sobre el producto CuadrilCT
TapaCuadril
CuadrilST
Total
NovilloJJ
0.92
3.18
4.1
NovilloJ
0.92
3.18
4.1
69
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Tabla II.38. Descomposición OP2CuadrilCT aplicada
sobre el producto CuadrilCT
CuadrilCTExp
MPGrasa
NerviosYPellejos
Total
NovilloJJ
3.30
0.70
0.10
4.1
NovilloJ
3.1
0.9
0.1
4.1
Tabla II.39. Descomposición OP3CuadrilCT aplicada
sobre el producto CuadrilCT
CuadrilCorteUK
MP2CarneCocida
MP1CarneCocida
MPGrasa
NerviosYPellejos
Total
NovilloJJ
3.13
0.13
0.16
0.62
0.06
4.1
NovilloJ
3.0
0.15
0.16
0.72
0.07
4.1
Retornando a los productos que se muestran en la Tabla II.37, también es válido
aclarar
que
CuadrilST
y
TapaCuadril
pueden
considerarse
productos
finales
o
semielaborados. Por ejemplo, el producto TapaCuadril puede comercializarse como tal, con
lo cual se lo consideraría un producto final o podría requerir un procesamiento adicional,
como es el caso de la variedad TapaCuadrilExp que se obtiene a partir de la operación de
despostada que se muestra en la Tabla II.40 o como el caso de la variedad
TapaCuadrilEEUU que se obtiene a partir de la operación de despostada que se presenta en
la
Tabla
II.41.
Asimismo,
el
intermediario
TapaCuadril
podría
descomponerse
completamente en subproductos, tal como sucede en la operación de despostada que se
muestra en la Tabla II.42.
Tabla II.40. Descomposición OP1TapaCuadril aplicada
sobre el productoTapaCuadril
TapaCuadrilExp
MPGrasa
Total
NovilloJJ
0.82
0.10
0.92
NovilloJ
0.77
0.15
0.92
Es posible hacer consideraciones similares a las precedentes para todos los
productos que pueden obtenerse del cuarto trasero y que se han incluido en la Figura II.14.
Se ha mostrado en las tablas y figuras previas que distintas operaciones de despostada
sobre un tipo determinado de cuarto trasero (por ejemplo, sobre CuartoTCorte1) pueden dar
lugar a diferentes caminos de obtención del intermediario CuadrilST. De manera análoga,
partiendo de distintos tipos de cuartos traseros (por ej., CuartoTCorte1 y CuartoTCorte2) y
70
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
aplicando diferentes operaciones de despostada, también es posible obtener el mismo
producto CuadrilST.
Tabla II.41. Descomposición OP2TapaCuadril aplicada
sobre TapaCuadril
TapaCuadrilEEUU
MP1CarneCocida
MPGrasa
NerviosYPellejos
Total
NovilloJJ
0.429
0.155
0.296
0.040
0.92
NovilloJ
0.41
0.16
0.31
0.04
0.92
Tabla II.42. Descomposición OP3TapaCuadril aplicada
sobre el producto TapaCuadril
MP2CarneCocida
MP1CarneCocida
MPGrasa
Total
NovilloJJ
0.60
0.12
0.20
0.92
NovilloJ
0.50
0.12
0.30
0.92
Con respecto a los diferentes caminos de obtención de un producto final, puede
considerarse el caso presentado en las Tablas II.43 y II.44 que muestra diferentes
alternativas de obtención del producto CentroNalgaSuiza, el cual se puede producir, ya sea
a partir del intermediario NalgaDeAdentroST (ver Tabla II.43) o a partir del intermediario
NalgaDeAdentroCT (ver Tabla II.44). La relación entre estos dos últimos intermediarios es la
que se presenta en la Tabla II.45. La razón de la existencia de caminos alternativos puede
comprenderse fácilmente si se considera el caso de dos escenarios de operación. En el
primer escenario existe demanda de los productos CentroNalgaSuiza y TapaNalga, mientras
que en el segundo no hay demanda del último producto. En consecuencia, en el escenario
#1 se adoptarán como operaciones de manufactura las descriptas en las Tablas II.45 y II.43,
mientras que en el escenario #2, la operación de manufactura será la que se muestra en la
Tabla II.44.
Tabla II.43. Descomposición OP1NalgaDeAdentroST aplicada
sobre el producto NalgaDeAdentroST
CentroNalgaSuiza
MP1CarneCocida
MPGrasa
NerviosYPellejos
Total
NovilloJJ
3.16
0.71
0.436
0.339
4.645
NovilloJ
3.16
0.71
0.525
0.25
4.645
71
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Tabla II.44. Descomposición OP1NalgaDeAdentroCT aplicada
sobre el producto NalgaDeAdentroCT
CentroNalgaSuiza
MP2CarneCocida
MP1CarneCocida
MPGrasa
NerviosYPellejos
MP3CarneCocida
Total
NovilloJJ
3.16
0.526
1.414
0.649
0.206
0.120
6.075
NovilloJ
3.16
0.465
1.415
0.679
0.236
0.12
6.075
Tabla II.45. Descomposición OP2NalgaDeAdentroCT
aplicada sobre el producto NalgaDeAdentroCT
NalgaDeAdentroST
TapaNalga
Total
NovilloJJ
4.645
1.430
6.075
NovilloJ
4.645
1.430
6.075
Al inicio de la presentación de este caso de estudio, se mencionó que los cortes que
se obtienen de un cuarto delantero o trasero, pueden ser envasados para ser
comercializados o pueden ingresar como materia prima en el proceso productivo de algunos
de los productos finales que corresponden a la categoría de carnes cocidas congeladas o
enlatadas. Tal es el caso de los distintos productos correspondientes al grupo de las Carnes
Cocidas Congeladas (CCC). Las Tablas II.46 a II.48 presentan los productos intermedios y
las materias primas necesarias para manufacturar tres de dichos productos. En estas tablas,
es posible observar que algunas materias primas son parte componente de los tres
productos presentados (aquéllas marcadas con un asterisco) y otras materias primas están
presentes sólo en dos de ellos (éstas se indican con un símbolo ⊕).
Tabla II.46. BOM de un nivel para el producto final CCCCub1
Componente
CCCtipo1
TuboTipo1cs
Caja ZX3 Azul
Cierre CCC prw
Adhesivo ARP
BolsasT1
RótuloMK6
Unidades
requeridas
1000
280.0
53
53
0.26
2
20
Unidad de
medida
KG
UNID
UNID
UNID
KG
UNID
UNID
*
*
*
*
72
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
ClipsF56
Broches YV7
ObleasQW33
EtiquetaCB
200
400
222
53
UNID
UNID
UNID
UNID
*
*
*
*
Unidad de
medida
KG
UNID
UNID
UNID
KG
UNID
UNID
UNID
UNID
UNID
UNID
⊕
*
*
*
*
*
*
*
*
Tabla II.47. BOM de un nivel para el producto final CCCCub2
Componente
CCCtipo2
TuboTipo2ss
Caja XC71 Amarilla
Cierre CCC prw
Adhesivo ARP
BolsasT1
RótuloMK6
ClipsF56
Broches YV7
ObleasQW33
EtiquetaCB
Unidades
requeridas
1000
180
40.0
40.0
0.26
2
21
200
400
222
40
Tabla II.48. BOM de un nivel para el producto final CCCCub3
Componente
CCCtipo3
TuboTipo3ss
Caja XC71 Amarilla
Cierre CCC prw
Adhesivo ARP
BolsasT1
RótuloMK6
ClipsF56
Broches YV7
ObleasQW33
EtiquetaCB
Unidades
requeridas
1000
180
40.0
40.0
0.26
2
21
200
400
180.70
40
Unidad de
medida
KG
UNID
UNID
UNID
KG
UNID
UNID
UNID
UNID
UNID
UNID
⊕
*
*
*
*
*
*
*
*
Es posible observar en las Tablas II.46 a II.48, que estos productos finales se
componen de un producto intermedio (CCCtipo1, CCCtipo2 y CCCtipo3) respectivamente,
más un conjunto de insumos para el packaging. Las estructuras que corresponden a los
productos intermedios CCCtipo1, CCCtipo2 y CCCtipo3 se exponen en las Tablas II.49 a
II.51 y en la Figura II.15
73
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
Figura II.15 Estructura de los productos intermedios CCC1tipo1, CCCtipo2 y CCCtipo3
Tabla II.49. BOM de un nivel del producto CCCtipo1
Componente
MP3CarneCocida
MP1CarneCocida
Gelatina Comestible
Unidades
requeridas
1213.18
478.0
12.12
Unidad de
medida
KG
KG
KG
Es importante señalar que las cantidades indicadas en las Tablas II.49 a II.51
corresponden a los requerimientos de fabricación de 1000 KG de cada uno de los productos
en cuestión (CCCtipo1 a CCCtipo3, respectivamente). El total requerido en todos los casos
es mayor a 1000 KG debido a que durante el proceso de manufactura se pierde agua, que
no es contabilizada en el BOM por no poseer valor comercial.
Tabla II.50. BOM de un nivel del producto CCCtipo2
Componente
MP3CarneCocida
Gelatina Comestible
Sal Entrefina
Unidades
requeridas
1711.86
12.12
15
Unidad de
medida
KG
KG
KG
Tabla II.51. BOM de un nivel del producto CCCtipo3
Componente
MP3CarneCocida
Gelatina Comestible
Unidades
requeridas
1733.0
12.12
Unidad de
medida
KG
KG
La Figura II.16 presenta la estructura híbrida correspondiente al producto CCCCub2.
En ella puede apreciarse cómo el producto MP3CarneCocida participa en una estructura de
descomposición (como derivado del intermediario NalgaDeAdentroCT) y en una de
composición (como parte componente del producto intermedio CCCtipo2). Debe destacarse
que se presentan situaciones similares para los otros dos productos finales introducidos
anteriormente. En la misma figura, se indica con los rótulos “derivadoX” a las relaciones de
descomposición, mientras que las relaciones de composición se señalan con las etiquetas
74
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
“parteX”.
Estructura de
Composición
Estructura de
Descomposición
Figura II.16 Ejemplo de un producto que participa en una estructura híbrida
Otra característica para destacar en relación a este caso de estudio, y que agrega
complejidad al manejo de la información estructural de los productos en este tipo de
industrias, es que algunos productos intermedios pueden obtenerse a partir de más de una
materia prima y/o semielaborado. Tal es el caso del producto MP1CarneCocida que, como
se muestra en la Figura II.17, puede obtenerse como derivado de 11 productos intermedios
diferentes.
Figura II.17 Diferentes semielaborados a partir de los cuales puede obtenerse el
producto MP1CarneCocida.
Con el objetivo de ejemplificar las notables similitudes existentes entre las estructuras
de algunos de los productos finales analizados, considérese el contenido de la Tabla II.52.
Dicha tabla, presenta diecisiete productos finales que se encuentran en el grupo de las
75
MP3CarneCocida
MP2CarneCocida
CZACuadrada
MP1CarneCocida
Gelatina
Sal
TuboTipo2cs
TuboTipo1ss
TuboTipo1cs
TuboTipo3cs
TuboTipo4ss
TuboTipo4cs
TuboTipo2ss
TuboTipo3ss
TuboTipo5ss
Caja ZX3 Azul
Caja 115 Grande Blanca
Cierre CC prw
Adhesivo ARP
BolsasT1
RotuloMK6
ClipsF56
BrochesYV7
ObleasQW33
EtiquetasCB
40
40
0.26
2
21
200
400
222
40
180
40
40
0.26
2
21
200
400
222
40
180
12
12
CCCCub1
1754
CCCCub2
1754
CCCCub3
53
0.26
2
21
200
400
222
53
53
275
12
15
1754
CCCCub4
53
53
0.26
2
21
200
400
222
53
280
12
1754
CCCCub5
53
53
0.26
2
21
200
400
222
53
275
12
15
1754
CCCReb1
53
0.26
2
21
200
400
222
53
53
280
22
1754
CCCReb2
53
53
0.26
2
21
200
400
222
53
280
22
1754
CCCReb3
53
0.26
2
21
200
400
222
53
53
280
22
1754
CCCReb4
106
106
0.52
4
42
500
500
444
53
446
15
1754
CCCCub7
53
53
0.26
2
21
200
400
222
53
280
12
53
53
0.26
2
21
200
400
222
53
280
12
1202.7 1568
CCCCub6
Tabla II.52. Composición de algunos de los productos finales del negocio de carnes cocidas
FPB1
53
53
0.26
2
19
200
400
222
53
270
1639
8
12
FPB2
53
53
0.26
2
19
200
400
222
53
270
1639
8
12
FPB3
53
53
0.26
2
19
200
400
222
53
270
1639
8
12
CZACuadUK
53
53
0.26
2
19
250
250
222
53
283
1610
CZACuadCEE
53
53
0.26
2
19
300
300
222
53
283
1610
FPBCva
50
0.26
2
18
250
250
222
50
50
212
1587
FPD2
50
0.26
2
18
200
250
222
50
212
50
1587
50
0.26
2
18
250
250
222
50
50
212
1587
FPD1
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
denominadas “carnes cocidas”. Allí se muestran, para cada producto, las materias primas y
los semielaborados que se utilizan para su elaboración. En todos los casos, el producto final
se compone de un semielaborado, cuyos componentes se indican en las primeras seis filas
de dicha tabla, y de un conjunto de insumos para el packaging (listados a partir de la
séptima fila). Se puede observar que los productos involucrados tienen estructuras casi
idénticas. Debido a esto, la utilización de un modelo de representación de estructuras
tradicional, donde cada producto tiene su propia estructura, implicaría un alto grado de
redundancia en la información. Analizando únicamente las relaciones de composición, se
necesitarían para este grupo de productos, 187 relaciones de tipo “parte de”, muchas de las
cuales estarían duplicadas.
II.4. CONCLUSIONES
En la primera parte de este capítulo se presentaron diferentes criterios de
clasificación de organizaciones industriales. Las diversas categorías de clasificación
imponen sobre las empresas productivas, diferentes sistemas de información que den
soporte a sus actividades y, en consecuencia, información de distinta índole es requerida.
Así por ejemplo, los sistemas de entornos MTS requieren exactitud y consistencia en la
información del BOM, en las rutas de manufactura y en las capacidades productivas. En
cambio un ambiente ETO, no requiere tales características sobre dicho conocimiento ya que
sólo lo usa como referencia para definir un diseño de acuerdo a las especificaciones
establecidas en una orden de cliente. Tales especificaciones y el resultado del diseño (lista
de materiales, etapas de producción, costos y tiempos de entrega) son determinantes en el
proceso productivo. Sin embargo, tanto en un entorno MTS como en un ambiente ETO, se
requiere mantener el conocimiento sobre la estructura de los productos que se
manufacturan,
ya sea mediante BOMs estándares o listas de materiales particulares
definidas para un diseño específico. De igual manera, independientemente que se use el
concepto de BOM (industria de manufactura discreta) o de receta (en industrias de
procesos), siempre es necesario representar la estructura de los productos que cada
organización productiva manufactura.
En la segunda parte se introdujeron dos casos de estudio vinculados a los productos
de una planta de golosinas y de un frigorífico, respectivamente, los cuales revelan la
problemática de la representación de estructuras de productos. En particular se observó, en
ambos casos, la presencia de un elevado número de productos similares (variantes de un
producto) y el uso de BOMs tradicionales para la representación de las estructuras de
dichas variantes. En consecuencia, existe un volumen elevado de información duplicada,
con los inconvenientes que ello implica. Además, en el caso de estudio relacionado con la
industria frigorífica, se presentan materias primas no atómicas, las que implican estructuras
77
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
de productos en las que intervienen relaciones de descomposición junto con diferentes
caminos para la obtención de los productos. Esto plantea nuevos desafíos que serán
abordados a lo largo de esta Tesis.
Como ya se mencionó, un modelo de productos único, que represente todas y cada
una de las particularidades que manifiestan las distintas organizaciones productivas, es una
tarea imposible. En consecuencia, esta Tesis se centra en la representación de un modelo
de productos que de solución a la problemática planteada en torno a la información
estructural de los mismos. Se pone especial énfasis en la representación eficiente de un
gran número de variantes con estructuras similares, sean éstas de composición, de
descomposición o híbridas.
78
____________________________________ Dominio de trabajo. Caracterización y definición de su Alcance
III.MODELO DE PRODUCTOS. DEFINICIÓN
III.1. INTRODUCCIÓN
Como ya se mencionó en el Capítulo I, es necesario contar con un modelo de
productos integrado que sea capaz de adaptarse a los cambios impuestos por las nuevas
tecnologías (de producción, gestión y manejo de la información) sobre las organizaciones
industriales actuales. A partir del análisis de los modelos existentes (Capítulo I) y de las
características del dominio de trabajo (Capitulo II), en este capítulo se describe la propuesta
de un modelo de productos que satisface las necesidades planteadas respecto a la
problemática de la representación de estructuras de productos.
En primer lugar, se presentan los fundamentos sobre los que se basa el modelo. Se
introducen los conceptos referidos a: i) múltiples niveles de abstracción para la
representación de un producto; ii) BOM generativo y iii) familia de productos. A continuación
se expone el modelo propuesto teniendo en cuenta los diferentes niveles de abstracción
utilizados en su definición. Es así que se presenta primero el nivel Familia, el cual define los
aspectos comunes a un conjunto de productos. Posteriormente, se define el concepto de
Conjunto de Variantes, que permite diferenciar subconjuntos similares dentro de una Familia
y luego, es explicado el nivel más concreto, denominado Producto. A continuación, se
expone brevemente el comportamiento del modelo en un sistema de procesamiento de
BOMs y finalmente, se presentan las conclusiones.
Los conceptos serán expresados utilizando tecnología de objetos, la cual posibilita la
definición de un modelo extensible y adaptable a un dominio particular. De esta manera los
conceptos aquí propuestos pueden ser especializados en diferentes dominios de trabajo.
Para la representación de los modelos con esta tecnología se utiliza UML (Booch y colab.,
1999; Rumbaugh y colab., 1999). En forma complementaria se definen una serie de axiomas
que permiten aplicar restricciones a las interpretaciones de los modelos planteados en UML.
La especificación de los conceptos propuestos con los axiomas correspondientes, se realiza
en el lenguaje O-Telos, en su implementación ConceptBase (Jarke y colab., 1995, 2003), la
cual provee un modelo computacional integrado (ejecutable en términos de verificación de la
consistencia del modelo).
ConceptBase (base de conceptos) es un administrador de objetos deductivo que
implementa O-Telos, un dialecto de Telos (Mylopoulos y colab., 1990), el cual ha sido uno
de los primeros intentos de integrar propiedades de lenguajes orientados a objetos y
79
_________________________________________________________ Modelo de productos. Definición
lenguajes deductivos. La semántica de O-Telos está basada en DATLOG-neg (Zaniolo y
colab., 1997), una lógica simple que provee una forma no ambigua de determinar la verdad
de una sentencia.
La elección de la base de datos Conceptbase para la representación formal del
modelo se basa fundamentalmente en el hecho de que el grupo de trabajo en el que se
desarrolló esta tesis cuenta con experiencia en la utilización de Conceptbase como
herramienta de especificación y verificación.
III.2. JERARQUÍAS RELACIONADAS CON LA INFORMACIÓN DE PRODUCTOS
En las actividades de planificación estratégica y táctica llevadas a cabo en ambientes
industriales se usa información agregada de productos, ya que el uso de información
detallada implica altos costos computacionales y una gran incertidumbre en los pronósticos.
Por ejemplo, la planificación agregada se ocupa de la generación de planes tácticos de
ventas totales, producción total e inventarios para productos sustitutos (ficticios), que
representan la información agregada de un conjunto de ítems similares. En contraste, esta
información “gruesa” es desagregada para ser usada en la solución de problemas de
planificación de requerimientos de materiales (por ejemplo, cuando el plan agregado es
convertido en el plan maestro de producción, MPS - Master Production Schedule). Dar
soporte a los requerimientos de información de las actividades de planificación con
diferentes horizontes de tiempo (Estratégico-Táctico-Operativo) requiere la capacidad de
organizar los datos y el conocimiento de los productos en diferentes niveles de agregación,
durante todo el ciclo de vida de los mismos.
A efectos de gestionar apropiadamente la información de productos, se proponen
dos jerarquías de conceptos, denominadas jerarquía estructural y jerarquía de abstracción
(Giménez y colab., 2006) (Giménez y colab., 2007). Por un lado, la jerarquía estructural (SH
- Structural Hierarchy) organiza el conocimiento relacionado con la información estructural
de los productos. SH es una herramienta para manejar la información asociada con las
múltiples recetas o procesos disponibles para manufacturar un determinado producto o
grupo de productos similares. Un ejemplo clásico de una aplicación que usa información de
la SH es el sistema de planificación de requerimientos de materiales (MRP – Material
Requirements Planning). Tradicionalmente, la SH ha sido representada a través de los
BOMs. Éstos, como ya se mencionó, permiten representar las relaciones existentes entre
los productos finales, los semielaborados y las materias primas que los componen.
La jerarquía de abstracción (AH – Abstraction Hierarchy) organiza los productos de
acuerdo a diferentes niveles de especificación (desde productos substitutos hasta ítems
individuales). Esta jerarquía utiliza mecanismos para mantener la consistencia de la
información entre los distintos niveles de agregación. Varios ejemplos extraídos de la
80
_________________________________________________________ Modelo de productos. Definición
literatura especializada muestran cómo tareas de agregación-desagregación de información
deben ser utilizadas a lo largo de la AH para coordinar las actividades de planificación que
son ejecutadas en distintos horizontes temporales. Por ejemplo, en los niveles estratégico y
táctico, un pronóstico de demanda agregada es más apropiado (debido a que es más
exacto) que un pronóstico en base a ítems individuales, permitiendo una reducción en los
niveles de inventario (Simchi-levi y colab., 2004). De manera similar, los costos promedios y
las tasas de producción son requeridas para las decisiones de alto nivel en la planificación
de la producción, mientras que se utilizan en el piso de producción datos detallados de estos
factores (Nahmias, 2001).
El modelo propuesto, que es presentado en detalle en este capítulo, formaliza una
representación del conocimiento que integra las jerarquías SH y AH de los productos,
poniendo énfasis en el tratamiento de la información estructural de los mismos.
La jerarquía de abstracción consta de tres niveles, a saber:
Familia: es el nivel más alto y representa un conjunto de productos
similares, que comparten una o más estructuras comunes, pudiendo
representar así recetas de producción alternativas. Estas estructuras
pueden ser particularizadas en el siguiente nivel de abstracción.
Conjunto de Variantes: representa el segundo nivel y es un
subconjunto de integrantes del nivel Familia que comparten una
misma estructura, la cual puede incluir modificaciones respecto de la
estructura de la familia de la cual el conjunto de variantes es miembro.
Producto: se asocia al nivel de menor grado de abstracción.
Representa ítems individuales, que son miembros de un conjunto de
variantes particular. En consecuencia, posee la estructura asociada a
dicho conjunto. Esta estructura está constituida por productos con
existencia física.
Como muestra la Figura III.1, estos tres niveles se encuentran relacionados entre sí
mediante una asociación miembroDe, la cual indica que las entidades que comprenden un
nivel inferior, son miembros de una instancia de abstracción de un nivel superior. Es decir,
una instancia de Producto es miembro de alguna instancia de ConjuntodeVariantes, la cual,
a su vez, es miembro de una instancia de Familia.
81
_________________________________________________________ Modelo de productos. Definición
<<AP>>
AbstracciondeProducto
<<F>>
<<CV>>
<<P>>
Familia
ConjuntodeVariantes
Producto
miembroDe
miembroDe
Figura III.1. Distintos niveles en la abstracción de productos
La Especificación III.1 presenta la implementación en ConceptBase de estos
conceptos y las relaciones que los vinculan. Puede observarse en dicha especificación la
especialización
del
concepto
AbstraccióndeProducto,
en
las
clases
Familia,
ConjuntodeVariantes y Producto. Todos estos conceptos se definen como instancias de la
clase predefinida Class. La relación miembroDe entre un ConjuntodeVariantes y una
Familia, así como la que vincula un Producto con un ConjuntodeVariantes, se implementan
mediante la definición de un atributo con dicho nombre en las clases correspondientes, a
saber: ConjuntodeVariantes y Producto.
Individual AbstracciondeProducto in Class end
Individual Familia in Class isA AbstracciondeProducto end
Individual ConjuntodeVariantes in Class isA AbstracciondeProducto with
attribute
miembroDe:Familia
end
Individual Producto in Class isA AbstracciondeProducto with
attribute
miembroDe:ConjuntodeVariantes
end
Especificación III.1. Definición de niveles de abstracción y sus relaciones
A partir de la información estática que implica la definición introducida por la
Especificación III.1, ConceptBase permite la inferencia de información “dinámica” mediante
la definición de reglas deductivas. En la Especificación III.2 se presenta un ejemplo de este
tipo de reglas que permite la inferencia del atributo miembros que se incorpora en la clase
Familia, el cual corresponde a la inversa de la relación miembroDe entre dicha Familia y la
clase ConjuntodeVariantes. De manera similar, puede definirse una regla en la clase
ConjuntodeVariantes que permita la inferencia de los productos que son miembros de dicho
conjunto.
Familia with
82
_________________________________________________________ Modelo de productos. Definición
attribute
miembros: ConjuntodeVariantes
rule
miembrosRule:$forall f/Familia cv/ConjuntodeVariantes (cv miembroDe f)
==> (f miembros cv)$
end
Especificación III.2. Definición de una regla deductiva
No existe un único criterio para determinar qué características se van a utilizar para
determinar la jerarquía de abstracción. En general, éstos van a depender del tipo de
industria en el que se pretenda implementar el modelo. Asimismo, la definición de esta
jerarquía no es aplicable sólo a productos finales, sino que puede ser establecida para todos
los tipos de partes que intervienen en las diferentes etapas del proceso productivo:
productos terminados, ensamblados intermedios y materias primas. En la Figura III.2 se
presentan algunas instancias de las jerarquías de abstracción para dos productos extraídos
de los casos de estudio introducidos en el Capítulo II.
Para el primer caso, se muestra la familia CarameloFrutalEnv, la cual es una de las
familias definidas a nivel de caramelos envueltos en el caso de estudio de la planta de
golosinas. Los diferentes conjuntos de variantes identificados para dicha familia se
definieron según el tipo de packaging adicionado y de caramelo desenvuelto que utilizan
como componentes. En particular, BolsínFrutalROC y VaritaKIM se muestran en la Figura
III.2. En el último nivel se presentan dos instancias del concepto Producto, las cuales son
miembros del conjunto de variantes BolsínFrutalROC, a saber: BolsínFrutillaROC,
BolsínPeraROC.
En el caso de la industria cárnica, se presenta una jerarquía de abstracción cuya raíz
es la familia CarneCocidaCongelada, cuyos conjuntos de variantes miembros son
CarneCocidaSazonada, CarneCocidaCubeteada1, CarneCocidaCubeteada2. Para estas
dos últimas se muestran algunas instancias de productos que son miembros de las mismas:
CCCCub1 y CCCCub2, para el primer conjunto, y CCCCub4 para el segundo. Estos
productos corresponden a algunos de los productos finales que se presentaron en la Tabla
II.30.
83
_________________________________________________________ Modelo de productos. Definición
<<F>>
Familia
CarneCocidaCongelada
CarameloFrutalEnv
miembroDe
<<VS>>
Conjunto de
Variantes
VaritaKIM
BolsínFrutalROC
CarneCocidaSazonada
CarneCocidaCubeteada2
CarneCocidaCubeteada1
miembroDe
<<P>>
Producto
BolsínFrutillaROC
BolsínPeraROC
CCCCub4
CCCCub1
CCCCub2
Figura III.2. Tres niveles de abstracción en la definición de un producto
III.2.1. Estructura de productos en los distintos niveles de abstracción
Como su nombre lo indica, la jerarquía estructural (SH) permite representar la
información acerca de la estructura de un producto. Esta estructura, como se explicó en el
Capítulo I, puede ser de tres tipos: de composición, de descomposición o híbrida
(combinación de los dos primeros tipos). Es por ello que se propone la definición de una SH
que permita administrar estos tres tipos mencionados. La Figura III.3 presenta ejemplos de
estructuras de composición y descomposición (extraídas de los casos de estudio) a ser
administradas por la SH. Se muestra parte de la estructura de composición correspondiente
al semielaborado BolsínFrutilla5GREnv, la cual se compone de: EnvBolsínFrutillaKIM,
PapelSepBolsín y BolsínFrutillaDes. Este último es un semielaborado de nivel caramelo
desenvuelto que, como se mostró en el Capítulo II, se compone de una masa y un relleno
sabor frutilla. Los cuales a su vez se componen de otros semielaborados y materias primas
que no se muestran en esta figura. Como ejemplo de una estructura de descomposición se
presenta la materia prima CuartoTrasero, de la cual se obtienen, entre otros productos,
Lomo y CuadrilConTapa. A partir de este último, se puede obtener el CuadrilSinTapa y la
TapaCuadril, la cual puede seguir descomponiéndose, según se explicó en el capítulo
previo.
84
_________________________________________________________ Modelo de productos. Definición
BolsínFrutilla5GREnv
CuartoTrasero
PapelSepBolsín
EnvBolsínFrutillaKIM
CuadrilConTapa
SH
Lomo
BolsínFrutillaDes
CuadrilSinTapa
MasaFrutilla
TapaCuadril
RellenoFrutilla
Figura III.3. Estructuras de composición y de descomposición
Una pregunta que se plantea en este punto es, ¿qué sucede con la representación
de la estructura de un producto cuando el mismo se define con distintos niveles de
abstracción? En otras palabras, ¿cómo se especifica la estructura para la familia, para el
conjunto de variantes, y en definitiva, cómo se obtiene una estructura para una variante de
un producto particular? Para dar respuesta a estos interrogantes, la SH propuesta adhiere a
la filosofía de los BOMs generativos, donde un BOM específico se obtiene en el momento en
que es usado a partir de una estructura común. Esta filosofía se materializa definiendo la SH
para cada uno de los niveles de la AH y proveyendo un mecanismo que permita la obtención
de estructuras particulares a partir de estructuras generales.
Los árboles de estructuras mostrados en el Capítulo II para los dos casos de estudio
se corresponden con jerarquías estructurales del nivel más bajo de la AH, representado por
el concepto Producto (Figura III.1). A medida que se asciende en la AH, los árboles de
estructuras se van haciendo más complejos ya que cuando se va escalando en la jerarquía
de abstracción cada nodo del árbol representa información agregada. En consecuencia,
cada uno de ellos ya no simboliza un único componente, sino que puede simbolizar
múltiples potenciales componentes.
Las Figuras III.4 y III.5 presentan ejemplos de árboles de estructuras para los otros
dos niveles de la AH, ConjuntodeVariantes y Familia, para el caso de estudio de la planta de
golosinas. En la primera de estas figuras se muestra, mediante un diagrama BOM con
algunas modificaciones, la estructura para el conjunto de variantes BolsínFrutalROC, al que
pertenece el producto real BolsínFrutilla5GREnv (cuya estructura de composición se
presentó en la Figura III.3).
En la Figura III.4, puede observarse que se han incorporado algunos elementos
nuevos a la representación gráfica de los árboles de estructuras ya vista. En este esquema,
se distinguen aquellos nodos que simbolizan productos reales de los que representan
conjuntos de variantes. En el primer caso, los nodos están dibujados con líneas sólidas,
85
_________________________________________________________ Modelo de productos. Definición
mientras que en el segundo, se utilizan líneas de puntos y rayas intercaladas. Otro elemento
que se incorporó es la representación de la relación miembroDe entre un conjunto de
variantes y sus productos miembros. Por ejemplo, las relaciones entre el conjunto de
variantes SepROC y los productos PapelSepBolsín e InteriorBolsín. También se resaltan en
la figura en tono gris los productos que aparecen en la estructura de nivel de producto, que
ya fueron introducidos en la Figura III.3.
La Figura III.5 presenta la estructura correspondiente a la familia CarameloFrutalEnv,
de la que es miembro el conjunto de variantes BolsínFrutalROC presentado en la Figura
III.4. Al igual que en el caso anterior, se agrega un nuevo tipo de nodo para representar a las
familias (indicado por una línea entrecortada). En este caso, la estructura se compone de
familias, para las que se indican cuales son los posibles conjuntos de variantes por los que
puede reemplazarse un nodo familia en el proceso de obtención de una estructura particular.
Para cada familia se presentan otros conjuntos de variantes miembros de la misma, además
de los mostrados previamente.
El concepto de BOM generativo permite vincular la especialización de una estructura
genérica, la de una familia, con la especificación de una estructura específica
correspondiente a un producto dado (integrante de dicha familia), pasando por las
definiciones de la entidad que los conecta en el nivel de Conjunto de Variantes.
Para el caso presentado en la Figura III.5, a partir de las definiciones asociadas a la
familia CarameloFrutalEnv y el conjunto de variantes BolsínFrutalROC, se obtiene la
estructura del producto BolsínFrutilla5GREnv.
86
_________________________________________________________ Modelo de productos. Definición
BolsínFrutalROC
BolsínFrutilla5GREnv
EnvBolsínFrutillaKIM
EnvBolsínPeraKIM
EnvBolsínCerezaKIM
PapelSepBolsín
EnvBolsínKIM
SepROC
InteriorBolsín
EnvBolsínLimaKIM
EnvBolsínPomeloKIM
BolsínFrutillaDes
BolsínAnanaDes
OvaloFrutal
BolsínLimonDes
BolsínNaranjaDes
BolsínCerezaDes
MasaFrutilla
RellenoFrutilla
MasaPera
MasaCereza
RellenoPera
MasaConAcido
Color
RellenoFrutal
RellenoCereza
MasaLima
RellenoLima
RellenoPomelo
Entidad de Nivel ConjuntodeVariantes
Entidad de Nivel Producto correspondiente a la
estructura de la Figura III.3
Entidad de Nivel Producto
Relación miembroDe
Figura III.4. SH para BolsínFrutalROC, instancia del nivel ConjuntodeVariantes
En la Figura III.6 se introduce el modelo completo que representa los tres niveles de
abstracción planteados. Se han agrupado en recuadros de diferentes tonos de gris los
conceptos correspondientes a cada nivel: Familia, ConjuntodeVariantes y Producto. En los
siguientes apartados de este capítulo se describen y especifican los conceptos y sus
respectivas relaciones. Además, mediante el empleo de vistas se presenta la forma de inferir
conocimiento a partir de la especificación del modelo en el lenguaje O-Telos.
87
MasaPera
Entidad del Nivel ConjuntodeVariantes
Entidad del Nivel Familia
MasaConÁcido
SinColor
MasaConÁcido
Color
EnvBolsínROC
EnvBolsínK
EnvBolsínKIM
PapelSeparador
RellenoFrutal
Entidad del Nivel ConjuntodeVariantes
correspondiente a la estructura de la Figura III.4
Entidad del Nivel Producto
MasaConÁcido
CarameloFrutalDes
PapelEnvoltorio
CarameloFrutalEnv
RellenoPomelo
RellenoLima
RellenoCereza
RellenoPera
RellenoFrutilla
BolsínCerezaDes
BolsínLimaDes
BolsínPomeloDes
BolsínPeraDes
BolsínFrutillaDes
SepRocDeluxe
SepBolsínRoc
InteriorBolsín
PapelSepBolsín
BolsínFrutilla5GREnv
Entidad del Nivel Producto correspondiente a la
estructura de la Figura III.3
Relación miembroDe
RellenoFrutal
VaritaFrutal
FrutalK
OvaloFrutal
FrutalS
SepROC
SepKIM
BolsínFrutalROC
Figura III.5. SH correspondiente a CarameloFrutalEnv, instancia del nivel Familia
MasaLima
MasaCereza
MasaPomelo
MasaFrutilla
EnvBolsínPomeloROC
EnvBolsínLimaROC
EnvBolsínCerezaROC
EnvBolsínPeraROC
EnvBolsínFrutillaROC
EnvBolsínPomeloKIM
EnvBolsínLimaKIM
EnvBolsínCerezaKIM
EnvBolsínPeraKIM
EnvBolsínFrutillaKIM
<<AP>>
<<AP>>
AbstraccionDeProducto
AbstraccióndeProducto
<<FS>>
FamiliaS
derivado
componente derivado
componente
<<F>>
Familia
<<FC>>
FamiliaC
estructuraDe
<<E>>
Estructura
<<RF>>
RestricciónF
<<RC>>
RelaciónC
<<RD>>
RelaciónD
<<ED>>
EstructuraD
<<EC>>
EstructuraC
estructuraAlternativa
tipoRelación
<<TR>>
TipoRelación
quantityPer
<<R>>
Relación prodFactor
max
<<VR>>
min
ValorRestringido
<<TR>>
<<Op>>
Optativa
Optativa
<<TR>>
<<Ob>>
Obligatoria
Obligatoria
<<TR>>
<<S>>
Selectiva
Selectiva
valor
<<
Presel>> preselecciona
<<Presel>>
Preseleccion
Preselección
Conjunto
Seleccionado
miembroDe
modificaciónAplicada
<<M>>
<<M>>
Modificacion
Modificación
<<Elim>>
Eliminación
nuevoQP
cambioAplicado
<<C>>
Cambio
relaciónModificada
<<Sele>>
<<SelFam>>
SelecciónFamilia
SelecciónFamilia
nuevoPF
<<CC>>
CambioC
<<Cpf>>
<<CPF>>
CambioPF
CambioPF
<<Cqp>>
<<CQP>>
CambioQP
CambioQP
<<PS>>
ProductoS
Producto
<<RP>>
RestricciónP
<<U>>
Unidad
derivaDe
<<SVS>>
ConjuntodeVariantesS
miembroDe
miembroD
e <<P>>
<<UV>>
<<VU>>
ValorUnidad
ValorUnidad udeM
<<CVC>>
ConjuntodeVariantesC
<<CV>>
ConjuntodeVariantes
<<RCV>>
RestricciónCV
<<Num>>
<<Num>>
Numero
Número
selecciona
<<PC>>
ProductoC
<< sele>>
Selección
Figura III.6. Modelo de productos propuesto
III.3. NIVEL DE ABSTRACCIÓN FAMILIA
Como se mencionó anteriormente, una Familia agrupa un conjunto de productos
similares. Cada familia está relacionada con la información que es compartida por todos los
miembros que la misma comprende. De dicha información, una de las más importantes se
vincula con la manera en que esa familia está relacionada con otras mediante una
estructura. Estas relaciones definen la jerarquía estructural (SH) de una familia.
89
_________________________________________________________ Modelo de productos. Definición
Una familia puede estar asociada a una o más estructuras, o no estar vinculada a
ellas; ello ocurre en el caso de un producto que es materia prima y no se descompone.
Teniendo en cuenta la cardinalidad de esta relación es posible definir una especialización
del concepto Familia. Dicha especialización se presenta en la Figura III.7.
derivado
componente
Familia
FamiliaS
FamiliaC
estructuraDe
estructuraAlternativa
Estructura
EstructuraD
EstructuraC
RelaciónC
RelaciónD
Relación
Figura III.7. Conceptos del nivel Familia
Por su parte, la Especificación III.3 presenta la implementación en O-Telos de la
especialización de la clase Familia que se muestra en la Figura III.6. Una familia puede ser
simple o compuesta. Una familia simple (FamiliaS) representa aquellas familias que no
tienen una estructura asociada; esto es, no se componen de otras familias ni de ellas
pueden obtenerse familias derivadas.
Una familia compuesta (FamiliaC), en cambio, está relacionada al menos con una
estructura. Para representar esta relación, que puede verse en las Figuras III.6 y III.7 bajo el
nombre de estructuraDe, en la Especificación III.4 se agrega el atributo estructuraDe a la
clase FamiliaC.
Individual Familia in Class end
Individual FamiliaS in Class isA Familia end
Individual FamiliaC in Class isA Familia end
Especificación III.3. Definición de Familia y su especialización
En la Especificación III.4 se expresa en RIII_1 una restricción de integridad, la cual
impone que para toda FamiliaC debe existir al menos una Estructura asociada a dicha
familia mediante el atributo estructuraDe.
90
_________________________________________________________ Modelo de productos. Definición
FamiliaC with
attribute
estructuraDe: Estructura
constraint
RIII_1:$forall f/FamiliaC (exists e/Estructura (f estructuraDe e))$
end
Especificación III.4. Definición de la relación estructuraDe en la clase FamiliaC
Por otra parte, una FamiliaC puede poseer más de una estructura. En ese caso,
estas estructuras corresponden a estructuras alternativas de la familia. Para representar
este concepto en la clase Estructura se define el atributo estAlternativa, cuyo valor será
inferido mediante la regla indicada como estAltRule en la Especificación III.5.
Individual Estructura in Class with
attribute
estAlternativa : Estructura
attribute,rule
estAltRule:$forall e/Estructura e2/Estructura (exists f/Familia
(f estructuraDe e) and (f estructuraDe e2) and not (e == e2))
==> (e estAlternativa e2) $
end
Especificación III.5. Regla para inferir los valores del atributo estAlternativa
Debe resaltarse que no todas las estructuras son iguales, ya que las familias a las
que están asociadas son la base para obtener un conjunto de semielaborados intermedios a
través de operaciones de desagregación, en un caso, o son el resultado del ensamblado de
partes componentes en el otro. Por lo tanto, un modelo de productos que pretenda
representar correctamente las estructuras de los productos que una Familia abstrae, deberá
considerar esta múltiple existencia. Debido a esto, el modelo propuesto especializa la clase
Estructura en dos subclases, a saber:
i) Estructura de Composición: representa estructuras de productos que son
obtenidos por medio del ensamblado de partes componentes.
ii) Estructura de Descomposición: representa la estructura de productos a partir de
los cuales es posible obtener productos derivados a través de una operación de
desensamblado.
Como puede observarse en las Figuras III.6 y III.7, se definen dos subclases para
representar esta especialización, denominadas EstructuraC y EstructuraD, respectivamente.
Ambas clases de estructura poseen una relación de agregación con la clase Familia. Dicha
agregación identifica a las familias que son componentes directos de las estructuras de
composición o, alternativamente, identifica a las familias derivadas inmediatas de
estructuras de descomposición. Los dos tipos de relaciones propuestas, denominadas
91
_________________________________________________________ Modelo de productos. Definición
RelacionC y RelacionD, son especializaciones de la clase Relación. La Especificación III.6
presenta las especializaciones correspondientes a estas dos clases (Estructura y Relación).
Individual EstructuraC in Class isA Estructura with
attribute
componente: RelacionC
end
Individual EstructuraD in Class isA Estructura with
Attribute
requiere: ValorRestringido
derivado: RelacionD
end
Individual Relacion in Class end
Individual RelacionC in Class isA Relacion end
Individual RelacionD in Class isA Relacion end
Especificación III.6. Especialización de la clase Estructura
Cada instancia de la clase Relación contiene información acerca de:
i)
la cantidad/número de un determinado producto que es necesario para
manufacturar
una
unidad
de
producto
(RelacionC)
o
la
cantidad/número de unidades de producto intermedio que se obtienen
a partir de la descomposición de una unidad de materia prima no
atómica (RelacionD);
ii) la proporción que un componente en particular representa respecto a
una unidad del producto en cuya estructura tal componente participa
(RelacionC) o el rendimiento que un producto intermedio determinado
representa en la descomposición de una unidad de materia prima no
atómica (RelacionD);
iii) restricciones de máximo y mínimo para los dos ítems de datos
mencionados arriba; y
iv) el tipo de relación.
En la Figura III.8 se presenta cómo estos ítems son modelados en la propuesta. Los
ítems i) y ii) se representa mediante asociaciones, denominadas quantityPer y prodFactor,
respectivamente, que se establecen entre las clases Relación y ValorRestringido. Esta
última clase representa un valor numérico y la unidad (udeM) en la que debe ser medido
dicho valor; así como los límites máximo (max) y mínimo (min) permitidos para el mismo.
Como se observa en dicha figura, los dos primeros atributos son heredados de la clase
92
_________________________________________________________ Modelo de productos. Definición
ValorUnidad; mientras que los últimos dos corresponden a la representación de la
información mencionada en el ítem iii).
tipoRelación
Relación
quantityPer
prodFactor
max
ValorRestringido
min
TipoRelación
valor
RelaciónC
RelaciónD
ValorUnidad
Número
udeM
Optativa
Obligatoria
Selectiva
Unidad
Figura III.8. Modelo asociado a la clase Relación
Para el ítem iv) se define una clase TipoRelación a la que se vincula la clase
Relación a través de la asociación tipoRelación. La clase TipoRelación se especializa según
los tipos de relaciones que podrían presentarse en una estructura de productos, a saber:
i)
obligatoria: el componente (o derivado) DEBE estar presente en la estructura
de cualquier miembro de la familia;
ii) opcional: el componente (o derivado) PUEDE o no estar presente en las
estructuras; y
iii) selectiva: el componente (o derivado) puede ser seleccionado a partir de un
conjunto, pero SÓLO UN ELEMENTO DEL CONJUNTO DEBE estar como
parte de la estructura.
En la Especificación III.7 se incorporan a la clase Relación los atributos que permiten
representar los conceptos enunciados en los párrafos anteriores, quantityPer, prodFactor y
tipoRelación, así como el atributo parte, que indica la familia (componente o derivado) a la
que está vinculada la relación. El valor del atributo tipoRelación debe ser una instancia de la
clase TipoRelación, cuya definición se presenta en la Especificación III.8. En tanto, los
valores que pueden tomar los atributos quantityPer y prodFactor, deben ser instancias de la
clase ValorRestringido, la cual se ilustra en la Especificación III.9.
En particular, la Especificación III.8 muestra la clase TipoRelación. Esta última se
especializa en tres subclases para representar, respectivamente, los tres tipos definidos, a
saber: Obligatoria, Optativa, Selectiva. Esta última, posee un atributo conjuntoSelección,
cuyos valores serán inferidos por la regla incluida en la Especificación III.8 y permitirán
representar relaciones que son mutuamente selectivas en una estructura.
Individual Relacion in Class with
attribute
parte : Familia;
quantityPer : ValorRestringido;
93
_________________________________________________________ Modelo de productos. Definición
prodFactor : ValorRestringido;
tipoRelacion : TipoRelacion
end
Especificación III.7. Definición de la clase Relación
Individual TipoRelacion in Class end
Individual Obligatoria in Class isA TipoRelacion end
Individual Optativa in Class isA TipoRelacion end
Individual Selectiva in Class isA TipoRelacion with
attribute
conjuntoSeleccion: Relacion
rule
conjSeleccionRule: $ forall r/Relacion s/Selectiva
(s == this) ==> (s conjuntoSeleccion r) $
end
Especificación
especializaciones
III.8.
Definición
de
la
clase
(r tipoRelacion s)
TipoRelación
y
de
and
sus
Es importante mencionar que una estructura podría tener más de un conjunto de
relaciones selectivas. En dicho caso, existirá una instancia de Selectiva para cada uno de
estos grupos y las relaciones que pertenezcan a un grupo se vincularán, a través de la
asociación tipoRelación, con una de dichas instancias y las relaciones de los otros grupos se
conectarán con las otras.
La Especificación III.9 presenta la implementación en O-Telos de las clases
ValorUnidad y ValorRestringido. La primera representa un número (valor) junto con su
unidad de medida. La segunda clase es una especialización de la primera e incorpora dos
atributos: max y min que permiten definir los límites máximo y mínimo, respectivamente, del
atributo valor. Es importante aclarar que la unidad en que deben medirse los atributos max y
min es la misma utilizada para el atributo valor (definida por el atributo udeM). Se muestran
también en dicha especificación dos ejemplos de instancias de estas clases. Por una parte,
1U es instancia de ValorUnidad, cuyo atributo valor toma el valor real 1.0 y cuya unidad de
medida es UNID (unidad). Por otra parte, el individuo 30_87GR representa una instancia de
ValorRestringido con valor igual a 30.87, udeM igual a GR (gramos) y límites máximos y
mínimos de 50.0 y 10.0, respectivamente. Esto implica que, por ejemplo, el valor del atributo
valor de la instancia 30_87GR (valor = 30.87) podrá ser modificado sólo para tomar valores
entre 10.0 y 50.0. De aquí se desprende que un valor de 20.5 gramos para este atributo, en
la instancia 30_87GR, es válido; pero, en cambio, no lo es un valor de 55.3 gramos.
La Figura III.9 presenta, con notación UML, la instancia 30_87GR junto a sus
vínculos con el valor 30.87 (instancia de número), la unidad de medida GR y los límites
máximos y mínimos 10.0 y 50.0 (instancias de número) para dicho valor. En la parte derecha
94
_________________________________________________________ Modelo de productos. Definición
de dicha figura, se puede observar, para la misma instancia de ValorRestringido, la forma
simplificada que se usará para mostrar gráficamente esta información en los ejemplos que
se presenten en lo que resta de esta Tesis. Debe notarse que en este ejemplo, el nombre de
la instancia de ValorRestringido que se emplea, está relacionado con los valores de los
atributos valor y udeM. Esta regla será usada a lo largo de este trabajo para denotar
cualquier instancia de dicha clase, así como de su superclase, ValorUnidad.
Individual ValorUnidad in Class with
attribute
valor : Real;
udeM : Unidad
end
Individual ValorRestringido in Class isA ValorUnidad with
attribute
max : Real;
min : Real
end
Individual 1U in ValorUnidad with
valor valor: 1.0
udeM udeM: UNID
end
Individual 30_87GR in ValorRestringido with
valor valor: 30.87
udeM udeM: GR
max max: 50.0
min min: 10.0
end
Especificación III.9. Representación de valores y unidades de medida
Forma Extendida
<<Número>>
Forma Simplificada
valor
min
10.0
<<ValorRestringido>>
<<Número>>
30.87
<<ValorRestringido>>
30_87GR
<<Número>>
50.0
max
udeM
<<Unidad>>
GR
30_87GR
valor:30.87
udeM:GR
min:10.0
max:50.0
Figura III.9. Ejemplos de instancias de ValorRestringido
Como se muestra en la Especificación III.9 el valor del atributo udeM será una
instancia de la clase Unidad y representa, como se dijo antes, la unidad en la que debe ser
medido el atributo valor, así como los atributos min y max de la clase ValorRestringido.
Dicha clase se especializa para permitir la representación adecuada de las diferentes
unidades de medida existentes: unidades de peso (kilogramo, gramo, onza, libra), de
superficie (metro cuadrado), de longitud (centímetro, metro), de volumen (metro cúbico,
95
_________________________________________________________ Modelo de productos. Definición
centímetro cúbico, litro). La Especificación III.10 presenta la jerarquía de unidades de
medidas definida, junto con la definición de algunas de las instancias que serán utilizadas en
esta Tesis.
Individual
Individual
Individual
Individual
Individual
Unidad in Class end
UnidadPeso in Class isA Unidad end
UnidadLongitud in Class isA Unidad end
UnidadSuperficie in Class isA Unidad end
UnidadVolumen in Class isA Unidad end
Individual
Individual
Individual
Individual
Individual
Individual
Individual
Individual
UNID in Unidad end
GR in UnidadPeso end
KG in UnidadPeso end
LB in UnidadPeso end
M in UnidadLongitud end
M2 in UnidadSuperficie end
CM3 in UnidadVolumen end
LT in UnidadVolumen end
Especificación III.10. Jerarquía de unidades de medida y definición de
instancias
A partir de las especificaciones introducidas hasta este punto es posible definir vistas
que permitan obtener cuál es el árbol que representa la estructura de una determinada
familia. Una vista en ConceptBase es un tipo especial de consulta que se define como
instancia de la clase predefinida View y como especialización de una determinada clase del
modelo. Una vista permite definir cómo se muestra la información de una determinada clase
y, además, posibilita presentar la información almacenada en instancias de clases
diferentes, mediante el empleo de reglas anidadas. La sintaxis usada para la definición de
una vista y algunos ejemplos de uso se describen en el Apéndice A.
Las vistas presentadas en las Especificaciones III.11 a III.13 permiten inferir árboles
de estructuras como el que se muestra en la Figura III.5 para la familia CarameloFrutalEnv.
La Especificación III.11 muestra la vista VerRelaciones que se construye a partir de la clase
Relación, empleando los atributos parte, tipoRelación y cantidad. El atributo parte es, a su
vez, una vista que posee como valores de atributos los conjuntos de variantes que son
miembros de dicha Familia.
Individual VerRelaciones in View isA Relacion with
attribute,inherited_attribute,partof
parte : Familia with
inherited_attribute
miembros: ConjuntodeVariantes
end
attribute,inherited_attribute
tipoRelacion : TipoRelacion
attribute,computed_attribute
96
_________________________________________________________ Modelo de productos. Definición
cantidad : ValorUnidad
attribute,constraint
r:$(this quantityPer ~cantidad) or (this prodFactor ~cantidad) $
end
Especificación III.11. Definición de la vista VerRelaciones
Por su parte, la Especificación III.12 presenta la vista VerEstructura, que utiliza la
primera vista que fuera definida de manera anidada, para mostrar las relaciones (con todos
los atributos antes mencionados) que forman parte de cada estructura. Es importante aclarar
que el atributo conformadoPor, que se observa como parte de la vista, corresponde a un
atributo de dicho nombre que se incorpora en la clase estructura y cuyos valores serán los
valores del atributo componente, si se trata de una estructura de composición, o los del
atributo derivado, en caso de las estructuras de descomposición. La forma en que se
infieren los valores de este atributo se muestra en la parte inferior de la especificación.
Individual VerEstructura in View isA Estructura with
inherited_attribute,partof
conformadoPor: VerRelaciones
end
Individual
rule
confRule:$
==>
end
Individual
rule
confRule:$
==>
end
EstructuraC with
forall r/RelacionC (this componente r)
(this conformadoPor r) $
EstructuraD with
forall r/RelacionD (this derivado r)
(this conformadoPor r) $
Especificación III.12. Definición de la vista VerEstructura
Finalmente, la Especificación III.13 presenta la vista arbolEstructuraFamilia, la cual
permite inferir las estructuras asociadas a una determinada familia a través de la relación
estructuraDe.
Individual arbolEstructuraFamilia in View isA Familia with
inherited_attribute,partof
estructuraDe : VerEstructura
end
Especificación III.13. Definición de la vista arbolEstructuraFamilia
En cuanto a las estructuras de composición y descomposición que puede incluir un
producto en el modelo propuesto, las relaciones de composición (RelaciónC) identifican a
los componentes de una EstructuraC, mientras que las relaciones de descomposición
(RelaciónD) designan a los derivados de una EstructuraD. De esta manera, los
componentes o derivados directos de una familia pueden ser obtenidos a través de estas
97
_________________________________________________________ Modelo de productos. Definición
asociaciones, tal como lo muestra la Especificación III.14, mediante las reglas denominadas
compDirRule y deriDirRule.
Es importante mencionar que el modelo mantiene BOMs de un nivel, ya que, a través
de la estructura de una familia, se almacenan relaciones directas entre dicha familia y sus
componentes o derivados directos. Además, el modelo permite inferir las estructuras
multinivel navegando a través de una sucesión de instancias de clases y relaciones FamiliaestructuraDe - EstructuraC (EstructuraD) - RelacionC (RelacionD) - Familia-…. Esto
posibilita la obtención de los componentes (derivados) no directos de una familia en
particular mediante las reglas compRule y deriRule presentadas en la Especificación III.15.
FamiliaC with
attribute
componenteDirecto: Familia;
derivadoDirecto: Familia
attribute, rule
compDirRule: $ forall f1/FamiliaC f2/Familia (exists e/EstructuraC
r/RelacionC (f1 estructuraDe e) and (e componente r) and
(r parte f2)) ==> (f1 componenteDirecto f2)$;
deriDirRule: $ forall f1/FamiliaC f2/Familia (exists e/EstructuraD
r/RelacionD (f1 estructuraDe e) and (e derivado r) and
(r parte f2)) ==> (f1 derivadoDirecto f2)$
end
Especificación III.14. Definición de relaciones de un nivel entre familias
FamiliaC with
attribute
componente: Familia;
derivado: Familia
attribute, rule
compRule:$forall f1/FamiliaC f2/Familia (f1 componenteDirecto f2) or (exists
e/EstructuraC f3/FamiliaC (f1 componenteDirecto f3) and (f3 componente f2))
==> (f1 componente f2)$;
deriRule:$forall f1/FamiliaC f2/Familia (f1 derivadoDirecto f2) or (exists
e/EstructuraD f3/FamiliaC (f1 derivadoDirecto f3) and (f3 derivado f2))
==> (f1 derivado f2)$
end
Especificación III.15. Definición de relaciones multinivel entre familias
Un uso fundamental de la información estructural de productos tiene que ver con la
generación del Plan Maestro de Producción, el cual para determinadas demandas de
productos finales permite planificar las cantidades de materias primas y productos
intermedios que deben ser compradas y/o manufacturadas a fin de cumplir con dicha
demanda. Por lo cual, tan importante como la información inferida acerca de cuáles son los
componentes de una familia, es la cantidad de cada componente que se necesita para
producir una determinada cantidad de producto. En este sentido, el modelo propuesto
permite inferir esta información.
98
_________________________________________________________ Modelo de productos. Definición
Debido a que el modelo gestiona dos tipos diferentes de estructuras (EstructuraC y
EstructuraD) y, en consecuencia, dos tipos distintos de relaciones (RelacionC y RelacionD),
la forma de obtener la información sobre qué familia se requiere y en qué cantidad, va a ser
diferente según la estructura que se esté analizando. En la Figura III.10, se presentan
ejemplos de estos dos tipos de estructuras y relaciones posibles; asimismo, se indica el
sentido en que deben obtenerse los requerimientos en cada caso.
En el ejemplo que se muestra a la izquierda de la Figura III.10, la familia
CarameloFrutalEnv tiene asociada una estructura de composición (CarameloFrutalEnvSTR),
la cual se vincula a la relación R04. En esta relación, el atributo parte tiene como valor a la
familia CarameloFrutalDes, indicando que dicha familia es requerida para obtener la familia
CarameloFrutalEnv.
Por otra parte, a la derecha de la figura, se puede observar que la familia
CuadrilConTapa, tiene asociada mediante la relación estructuraDe, la estructura (de
descomposición) CuadrilConTapaSTR1, de la cual se deriva, entre otros, la relación R01f.
Ésta, a su vez, está asociada a la familia TapaCuadril mediante el atributo parte. Esto indica
que la familia TapaCuadril se obtiene de la familia CuadrilConTapa (mediante la estructura
CuadrilConTapaSTR1).
Producto Final
R
E
Q
U
I
E
R
E
Materias Primas
Semielaborados
Figura III.10. Mecanismo de inferencia de los requerimientos de una familia
En consecuencia, en el primer caso, la familia que es requerida para obtener
CarameloFrutalEnv coincide con el valor del atributo parte de alguna de las relaciones que
conforman la estructura asociada a dicha familia. En el otro caso, la familia que se requiere
para obtener TapaCuadril se debe inferir navegando las relaciones en sentido inverso al
usado para el caso del caramelo. Es decir, a partir de la TapaCuadril, se debe obtener la
RelaciónD (R01f), luego la estructura (CuadrilConTapaSTR1) de la que es parte dicha
relación, y a partir de ésta inferir la familia (TapaCuadril) de la que es estructura.
99
_________________________________________________________ Modelo de productos. Definición
Es posible, entonces, establecer una clasificación entre dos tipos de familias,
aquéllas cuyos requerimientos se obtienen a partir de una estructura de composición (por
ejemplo
CarameloFrutalEnv)
y
aquéllas
que
son
obtenidas
por
estructuras
de
descomposición (por ejemplo, TapaCuadril). Cada uno de estos tipos se denominará
FamiliaEnsamblada y FamiliaDerivada, respectivamente. La Especificación III.16 presenta la
consulta que permite establecer las familias que corresponden a cada una de estas
categorías. Se muestra también en dicha especificación, el agregado de nuevos atributos,
denominados esDerivado y esEnsamblado, a la clase Familia, así como las reglas
esDerivadoRule y esEnsambladoRule que posibilitan inferir los valores de estos atributos.
Individual Familia in Class with
attribute
esDerivado : Boolean;
esEnsamblado : Boolean
attribute,rule
esDerivadoRule:$forall f/Familia (exists r/RelacionD (r parte f))
==> (f esDerivado TRUE)$;
esDerivadoRule2:$forall f/FamiliaS not(exists r/RelacionD (r parte f))
==> (f esDerivado FALSE)$
esEnsambladoRule:$forall f/FamiliaC (exists e/EstructuraC (f estructuraDe e))
==> (f esEnsamblado TRUE)$;
esEnsambladoRule2:$forall f/FamiliaC not(exists e/EstructuraC
(f estructuraDe e)) ==> (f esEnsamblado FALSE)$;
end
QueryClass FamiliaDerivada isA Familia with
retrieved_attribute
esDerivado : Boolean
constraint
c : $ (this esDerivado TRUE) $
end
QueryClass FamiliaEnsamblada isA Familia with
retrieved_attribute
esEnsamblado : Boolean
constraint
c : $ (this esEnsamblado TRUE) $
end
Especificación III.16. Consultas que permiten establecer familias ensambladas
y derivadas
Por otra parte, para poder inferir los requerimientos concretos de una relación
determinada, se definen nuevos atributos en la clase Relación, a saber: requerimiento y
cantReq, los que pueden apreciarse en la Especificación III.17.
Individual Relacion in Class with
attribute
requerimiento : Familia;
cantReq : ValorUnidad
end
100
_________________________________________________________ Modelo de productos. Definición
Especificación III.17. Definición de nuevos atributos para la clase Relación
Los valores de estos atributos serán inferidos a través de reglas que se definirán en
cada una de las especializaciones de la clase Relación (RelaciónC y RelaciónD). La
Especificación III.18 presenta las reglas que efectúan este tipo de inferencia para la relación
de composición (RelaciónC). En este caso el valor del atributo requerimiento coincide (ver
Figura III.10) con el valor del atributo parte. Es por ello que la regla reqRule indica que para
toda Familia f, y para toda RelacionC r, si f es parte de r (r parte f), entonces dicha Familia f,
es requerimiento de r (r requerimiento f). Por su parte, la cantidad que se requiere de esa
familia (cantReq) coincide con el valor del atributo quantityPer de la relación r, tal como lo
indica la regla CantreqRule.
Individual RelacionC with
attribute,rule
reqRule:$ forall f/Familia r/RelacionC (r parte f) ==> (r requerimiento f) $;
CantreqRule:$ forall r/RelacionC c/ValorRestringido (r quantityPer c)
==> (r cantReq c) $
end
Especificación III.18. Reglas para la inferencia de atributos en una RelaciónC
La forma en que se calculan los valores de los atributos requerimiento y cantReq
para relaciones de descomposición (RelacionD) se presenta en la Especificación III.19. Los
valores de ambos atributos se infieren a través de la estructura de descomposición
(EstructuraD), de la cual la relación es parte. La regla reqRule para este caso, indica que
para toda familia compuesta (FamiliaC) y toda relación de descomposición (RelacionD)
existe alguna estructura de descomposición EstructuraDe que las vincula a través de las
relaciones estructuraDe (f estructuraDe e) y derivado (e derivado r). En consecuencia, f es
requerida por la relación de descomposición r. Por su parte, la cantidad de f que es
requerida (valor del atributo cantReq de la RelacionD), se obtiene del valor del atributo
requiere de la EstructuraD mencionada (cuya definición se muestra en la Especificación
III.6), el cual representa la cantidad de Familia requerida (asociada a la estructura por la
relación estructuraDe) para obtener los derivados indicados por la estructura en cuestión.
Individual RelacionD in Class isA Relacion with
attribute,rule
reqRule:$forall f/FamiliaC r/RelacionD (exists e/EstructuraD (f estructuraDe e)
and (e derivado r)) ==> (r requerimiento f) $ ;
cantreqRule : $ forall r/RelacionD c/ ValorRestringido (exists f/FamiliaC
e/EstructuraD (f estructuraDe e) and (e requiere c)) ==>(r cantReq c)$
end
Especificación III.19. Reglas para la inferencia de atributos en una RelaciónD
101
_________________________________________________________ Modelo de productos. Definición
A partir de las especificaciones planteadas hasta aquí es posible construir una serie
de vistas que permiten inferir los requerimientos de una familia determinada. A continuación,
a manera de ejemplo, se presentan dichas vistas, comenzando por la más simple que
permite determinar cuáles son los requerimientos para cada instancia de Relación (ya sea
de composición o de descomposición). Luego se muestran las vistas que infieren los
requerimientos para las estructuras, y finalmente se introduce la vista que permite
determinar cuáles son los requerimientos de una familia.
La vista RequerimientosInferidos, que se muestra en la Especificación III.20, es una
especialización de la clase Relación, y hereda de la misma solamente los atributos
requerimiento y cantReq, que fueron ilustrados en la Especificación III.17.
Individual RequerimientosInferidos in View isA Relacion with
attribute,retrieved_attribute
requerimiento : Familia;
cantReq : ValorUnidad;
tipoRelacion : TipoRelacion
end
Especificación III.20. Vista RequerimientosInferidos
A partir
de dicha
vista,
en
la
Especificación III.21 se
define la
vista
RequerimientosEstructura, la cual permite reconstruir los requerimientos de las diferentes
estructuras de una familia. Para ello, tiene definido un parámetro denominado unaflia. Esta
vista es una especialización de la clase Estructura y permite calcular requerimientos, tanto
de estructuras de composición como de descomposición, según lo establecido por la regla
definida como restricción de la vista. Dicha regla es una disyunción, donde el primer término
permite el cálculo de los requerimientos cuando la estructura corresponde a una estructura
de una FamiliaEnsamblada. En cambio, el segundo término de la disyunción permite inferir
requerimientos de una FamiliaDerivada.
Individual RequerimientosEstructura in View isA Estructura with
attribute,parameter
unaflia : Familia
attribute,computed_attribute,partof
unReq : RequerimientosInferidos
attribute,constraint
r:$((this estructuraDe ~unaflia) and (this conformadoPor ~unReq) and
(~unaflia in FamiliasEnsambladas)) or ((~unaflia derivaDe ~unReq)
and (this conformadoPor ~unReq) and (~unaflia in FamiliasDerivadas)) $
end
Especificación III.21. Definición de la vista RequerimientosEstructura
En base a estas vistas es posible obtener los requerimientos directos de una familia
dada,
como
se
muestra
en
la
Especificación
III.22.
Se
presenta
la
vista
RequerimientosFamilia que utiliza de manera anidada las dos vistas que fueran expuestas
102
_________________________________________________________ Modelo de productos. Definición
anteriormente. Por otra parte, esta vista utiliza en la restricción r un atributo
estructuraRequerida, que se incorpora a la clase Familia a los efectos de poder inferir cuál
es la estructura a partir de la cual una Familia en particular es obtenida (ver Figura III.10). La
definición de este atributo en la clase Familia y de sus reglas de inferencia se presenta en la
Especificación III.23. Es posible inferir los valores del atributo estructuraRequerida a través
de las reglas estReqRule y estReqRule2, dependiendo de si la familia en cuestión es una
FamiliaEnsamblada o una FamiliaDerivada. En el primer caso el valor de dicho atributo
coincidirá con el valor del atributo estructuraDe. En el segundo, en cambio, corresponderá a
la estructura de la cual es derivada la RelacionD, de la que la familia es un requerimiento.
Individual RequerimientosFamilia in View isA Familia with
computed_attribute,partof
requerimientos : RequerimientosEstructura with
computed_attribute,partof
unReq: RequerimientosInferidos
constraint
rint:$(~unReq requerimiento this) and
(this::requerimientos in ~unReq.perteneceA)$
end
constraint
r:$ (this estructuraRequerida ~requerimientos) $
end
Especificación III.22. Vista RequerimientosFamilia
Individual Familia with
Attribute
estructuraRequerida:Estructura
attribute,rule
estReqRule1: $forall f/Familia e/Estructura
(f in FamiliasEnsambladas) and (f estructuraDe e )
==> (f estructuraRequerida e)$;
estReqRule2: $forall f/Familia e/Estructura (exists r/RelacionD
(f in FamiliasDerivadas) and (r requerimiento f) and
(r perteneceA e)) ==> (f estructuraRequerida e)$
end
Especificación III.23. Atributo estructuraRequerida y sus reglas de inferencia
III.4. NIVEL DE ABSTRACCIÓN CONJUNTO DE VARIANTES
El nivel Familia, descripto y formalizado en la sección anterior, define la información
común a un número elevado de productos similares. Las variaciones que pueden ocurrir
entre estos productos están relacionadas con:
i)
variaciones en la estructura por el agregado o eliminación de algún
componente (derivado);
ii) variaciones en los parámetros o valores de atributos en los componentes
(derivados) de la estructura; y
103
_________________________________________________________ Modelo de productos. Definición
iii) combinaciones de los casos anteriores.
Por ejemplo, distintas variantes de un papel de envoltorio (caso de estudio planta de
golosinas) constituirían un ejemplo del segundo tipo de variantes, si se diferencian unos de
otros por el idioma en que estos papeles están impresos, y/o la marca que se indica en
ellos. En estos casos se estaría frente a variaciones en los parámetros de determinados
productos. Por otro lado, si se considera el caso de la familia de productos que representa a
las masas de sabor frutal, las diferentes masas que forman parte de esta familia, presentan
entre sí variaciones de los tipos i e iii). Se puede observar en la Figura II.13 y en las Tablas
II.17 a II.20 (Capítulo II) que los diferentes productos tienen los mismos componentes, pero
difieren en las cantidades en que participan en la composición (variación estructural). Por
otra parte, las masas SE609150 (MasaPera) y SE609149 (MasaPomelo), por ejemplo,
difieren en los colores y sabores utilizados para los componentes colorante y esencia de
cada una de las estructuras.
El nivel ConjuntodeVariantes corresponde al nivel intermedio de la jerarquía de
abstracción propuesta y es el que permite representar los tipos de variaciones que se
indicaron en los párrafos previos. Los conceptos relacionados con este nivel se muestran en
la Figura III.11.
estructuraDe
FamiliaC
Familia
Estructura
ConjuntoSeleccionado
miembroDe
ConjuntodeVariantes
Preselección
preselecciona
derivaDe
ConjuntodeVariantesS
ConjuntodeVariantesC
modificaciónAplicada
cambioAplicado
Modificación
Cambio
Figura III.11. Diagrama de clases ConjuntodeVariantes
Cada entidad definida en este nivel se relaciona con una única instancia del nivel
Familia, y con una o más del nivel Producto. Como se mencionó anteriormente, entre
instancias perteneciente a distintos niveles de la AH, se establece la relación miembroDe.
En la Especificación III.24 se define en la clase ConjuntodeVariantes una restricción de
104
_________________________________________________________ Modelo de productos. Definición
integridad que impone la obligatoriedad, para todo ConjuntodeVariantes, de la existencia de
la relación miembroDe con alguna Familia. Además, cada conjunto de variantes debe ser
miembro de una única familia (RIII_4).
La clase ConjuntodeVariantes se especializó para representar por separado aquellos
conjuntos de variantes que son miembros de familias con estructuras de composición (o
descomposición) y los que se vinculan con familias simples. Esto permite clasificar a un
conjunto de variantes en “conjunto de variantes simples” (ConjuntodeVariantesS) o “conjunto
de variantes compuestas” (ConjuntodeVariantesC), según deriven de una FamiliaS o de una
FamiliaC, respectivamente. En consecuencia, como puede verse en la Especificación III.25,
se incorpora a las clases ConjuntodeVariantesS y ConjuntodeVariantesC, sendas
restricciones de integridad que imponen, por un lado, que todo ConjuntodeVariantesS debe
ser miembro de alguna FamiliaS (R_III5), y por otro, que todo ConjuntodeVariantesC se
relaciona con una FamiliaC (RIII_6).
ConjuntodeVariantes with
attribute,constraint
RIII_19:$forall cv/ConjuntodeVariantes exists f/Familia
(cv miembroDe f))$;
RIII_4: $forall cv/ConjuntodeVariantes f, f2/Familia (cv miembroDe f) and
(cv miembroDe f2) ==> (f == f2) $
end
Especificación III.24. Definición de restricciones de integridad para la clase
ConjuntodeVariantes
Individual ConjuntodeVariantesS in Class isA ConjuntodeVariantes with
constraint
RIII_5 : $ forall cv/ConjuntodeVariantesS f/Familia (cv miembroDe f) and
(f isA FamiliaS) $
end
Individual ConjuntodeVariantesC in Class isA ConjuntodeVariantes with
constraint
RIII_6 : $ forall cv/ConjuntodeVariantesC f/Familia (cv miembroDe f) and
(f isA FamiliaC) $
end
Especificación III.25. Especialización de la clase ConjuntodeVariantes
Una FamiliaC puede tener asociada más de una estructura. Por lo tanto, un conjunto
de variantes compuestas que es miembro de dicha familia, debe especificar cuál de todas
estas estructuras es la que se debe usar para derivar las estructuras particulares de sus
miembros.
Para
ello,
el
modelo
define
la
relación
derivaDe,
que
asocia
un
ConjuntodeVariantes compuestas con una y sólo una de las estructuras de la familia de la
cual es miembro. La Figura III.11 y la Especificación III.26 muestran esta relación.
105
_________________________________________________________ Modelo de productos. Definición
Se presentan también en dicha especificación las restricciones RIII_7 y RIII_8. La
primera indica que para todo ConjuntodeVariantesC cv, existe una Estructura e asociada a
cv por la relación derivaDe. A su vez, la restricción RIII_8 impone que dicha Estructura es
única para cada conjunto de variantes compuestas.
Individual ConjuntodeVariantesC with
attribute
derivaDe : Estructura
constraint
RIII_7:$forall cv/ConjuntodeVariantesC (exists e/Estructura
(cv derivaDe e))$;
RIII_8:$forall cv/ ConjuntodeVariantesC e1, e2/Estructura
(cv derivaDe e1) and (cv derivaDe e2) ==> (e1 == e2) $
end
Especificación III.26. Atributo derivaDe de un ConjuntodeVariantesC
La relación derivaDe indica, para un conjunto de variantes compuestas, cuál es la
estructura de la familia que utiliza como base para definir su propia estructura. Ésta puede
ser exactamente la misma definida para la familia o puede ser similar. En este último caso,
las modificaciones que se aplican se representan mediante la clase Modificación, la cual
permite establecer variaciones estructurales. Por su parte, la clase Preselección (Figura
III.11) permite imponer una restricción que indica los ConjuntosdeVariantes particulares que
deberán ser empleados obligatoriamente en la especificación del ConjuntodeVariantes
asociado a la Preselección en cuestión por medio de la relación preselecciona.
La Especificación III.27 completa la definición de un conjunto de variantes
compuestas
(ConjuntodeVariantesC),
agregando
los
atributos
preselecciona
y
modificaciónAplicada que representan las relaciones que con estos nombres han sido
propuestas en el modelo (ver Figura III.11).
ConjuntodeVariantesC with
attribute
preselecciona: Preseleccion;
modificacionAplicada: Modificacion
end
Individual Modificacion in Class end
Individual Preseleccion in Class end
Especificación III.27. Definición de ConjuntodeVariantesC
Dependiendo de qué tipo de variaciones represente un conjunto de variantes
compuestas respecto a la familia de la que es miembro, se usará uno o más de los
conceptos mostrados en la Figura III.11. Pero mínimamente se debe establecer la familia a
la que pertenece dicho conjunto (relación miembroDe) y la estructura de la que deriva
(relación derivaDe). A partir de esto, se podrán especificar modificaciones a la misma y/o
106
_________________________________________________________ Modelo de productos. Definición
preseleccionar algunos subconjuntos de determinados conjuntos de variantes de alguna/s
de las familias componentes de la estructura de la cual depende.
Un conjunto de variantes compuestas puede modificar o no la estructura de la que
deriva. Si lo hace deberá especificar qué cambios se deben aplicar a la estructura de la
familia para adaptarla a la estructura particular de los integrantes del ConjuntodeVariantes
en cuestión.
Como lo muestra la Figura III.11, la clase Modificación agrupa todos los cambios que
un conjunto de variantes compuestas realiza sobre la estructura de la cual deriva. Esto
establece una nueva relación entre una modificación y la estructura que ésta afecta, la cual
se encuentra representada por el atributo modifica, introducido en dicha clase. Este atributo
y la regla utilizada para inferir su valor se muestran en la Especificación III.28.
Modificacion with
attribute
cambioAplicado: Cambio
modifica: Estructura
rule
modificaRule: $ forall e/Estructura m/Modificacion
(exists cv/ConjuntodeVariantesC (cv derivaDe e) and
(cv modificacionAplicada m) )==> (m modifica e) $
end
Especificación III.28. Definición de la clase Modificación
La clase Modificación posee un atributo denominado cambioAplicado que representa
cada uno de los cambios que deben hacerse sobre la estructura que se modifica. En este
sentido los cambios que están involucrados en una modificación son representados como
instancias de alguna de las especializaciones de la clase Cambio, dependiendo del tipo de
cambio que se está representando. Los cambios que pueden afectar a la estructura
vinculada a un conjunto de variantes compuestas son:
modificación de los valores en que un componente (o derivado) está presente en
la estructura;
eliminación de un componente (o derivado);
selección de una de las relaciones pertenecientes a un conjunto de relaciones de
tipo selectiva.
Estos diferentes tipos de cambios están representados en el modelo a través de una
especialización de la clase Cambio y pueden observarse en la Figura III.12 y en la
Especificación III.29. Las subclases en cuestión son: CambioC, la cual se especializa en
CambioQP y CambioPF, Eliminación y SelecciónFamilia.
107
_________________________________________________________ Modelo de productos. Definición
Como se aprecia en la misma figura, la manera en que se determina cuál es el
componente que es modificado en la estructura es a través de la asociación
relaciónModificada, la cual vincula el cambio con la relación que es afectada. En otras
palabras, indica cuál es la relación que es eliminada, seleccionada o cuyas cantidades de
composición son modificadas. La relación afectada por el cambio se origina en la estructura
de la que deriva el conjunto de variantes, que está vinculada al cambio en cuestión por
intermedio de la modificación que contiene al cambio. Esta restricción se incorpora a la clase
Cambio, como lo muestra la Especificación III.29.
relaciónModificada
Cambio
Relación
SelecciónFamilia
CambioC
Eliminación
nuevoQP
CambioQP
CambioPF
ValorUnidad
nuevoPF
Figura III.12. Clase Cambio y conceptos relacionados
Individual Cambio in Class with
attribute
relacionModificada : Relacion
constraint
RIII_9: $forall c/Cambio (exists r/Relacion m/Modificacion
e/Estructura (m modifica e) and (e conformadoPor r) and
(m cambioAplicado c)and (c relacionModificada r))$
end
Individual Eliminacion in Class isA Cambio end
Individual SeleccionFamilia in Class isA Cambio end
Individual CambioC in Class isA Cambio end
Especificación III.29. Definición de la clase Cambio y sus especializaciones
La clase CambioC se especializa en CambioQP y CambioPF, como se muestra en la
Especificación III.30. Estas clases indican la modificación de los valores de los atributos
quantityPer y prodFactor, respectivamente, de la instancia de Relación que es afectada por
el cambio (relaciónModificada).
En dicha especificación, las relaciones nuevoQP y nuevoPF, indican los nuevos
valores que toman los atributos de la relaciónModificada mencionados para todos los
108
_________________________________________________________ Modelo de productos. Definición
productos que son miembros del conjunto de variantes que se está definiendo. Estos nuevos
valores deberán estar comprendidos entre los límites máximo y mínimo establecidos para la
relación que está siendo modificada. Para asegurar esto, se incorpora a las clases
CambioQP y CambioPF las restricciones que se indican en la Especificación III.30 mediante
RIII_10 y RIII_27.
Individual CambioQP in Class isA CambioC with
attribute
nuevoQP : ValorUnidad
constraint
RIII_10: $ forall c/CambioQP (exists r/Relacion vu/ValorUnidad
vr/ValorRestringido val,rmax,rmin/Real (c relacionModificada r) and
(r quantityPer vr) and (c newQP vu) and (vu valor val) and (vr min rmin) and
(vr max rmax) and val >= rmin and val <= rmax )$
end
Individual CambioPF in Class isA CambioC with
attribute
nuevoPF : ValorUnidad
constraint
RIII_27: $ forall c/CambioPF (exists r/Relacion vu/ValorUnidad
vr/ValorRestringido val,rmax,rmin/Real (c relacionModificada r) and
(r prodFactor vr) and (c newPF vu) and (vu valor val) and (vr min rmin) and
(vr max rmax) and val >= rmin and val <= rmax)$
end
Especificación III.30. Especialización de la clase CambioC
La clase Eliminación representa la supresión de la relaciónModificada de la
estructura a la que dicha relación pertenece. Como muestra la Especificación III.31 se
incorpora una restricción en esta clase para asegurar la creación de instancias válidas. Una
eliminación es posible de ser aplicada sólo sobre relaciones de tipo optativa. No es posible
eliminar de una estructura una relación de tipo obligatoria, ni de tipo selectiva.
Eliminacion with
constraint
RIII_12: $ forall c/Eliminacion exists r/Relacion tr/TipoRelacion
(c relacionModificada r) and (r tipoRelacion tr) and (tr in Optativa)$
end
Especificación III.31. Definición de la clase Eliminación
Finalmente, el último tipo de cambio propuesto sobre una estructura tiene que ver
con la elección de algunas de las relaciones que pertenecen al conjunto de relaciones
selectivas (Figura III.8) de dicha estructura. Como se mencionó anteriormente, este tipo de
relaciones constituyen un grupo de relaciones mutuamente excluyentes, de las cuáles sólo
una de ellas debe estar presente en la estructura de un conjunto de variantes. Para efectuar
esta selección se utiliza la especialización SelecciónFamilia. En este caso, la asociación
109
_________________________________________________________ Modelo de productos. Definición
relaciónModificada (Figura III.12), indica cuál es la relación elegida entre todas las
integrantes del conjunto de relaciones selectivas (RIII_13 en Especificación III.32).
Obviamente, la relación seleccionada debe ser de tipo selectiva. Por cada instancia de
Selectiva en una Estructura deberá existir una instancia de SelecciónFamilia (RIII_14 en
Especificación III.32). Además, dicha instancia es única para cada conjunto selección
(RIII_15 en Especificación III.32). Estas restricciones de integridad se agregan a la clase
SelecciónFamilia para asegurar consistencia (Especificación III.32).
Como se indicó anteriormente la clase Preselección permite especificar restricciones
en la estructura de conjuntos de variantes compuestas. Una instancia de Preselección
asociada a una instancia cv de la clase ConjuntodeVariantesC restringe las relaciones
miembroDe (entre una instancia de Familia y una instancia de ConjuntodeVariantes) que se
pueden emplear en las familias componentes de la estructura a partir de la cual cv deriva.
SeleccionFamilia with
constraint
RIII_13:$forall c/SeleccionFamilia exists r/Relacion tr/TipoRelacion
(c relacionModificada r) and (r tipoRelacion tr) and (tr in Selectiva)$;
RIII_14: $ forall c/ConjuntodeVariantesC e/Estructura(exists r/Relacion
tr/Selectiva m/Modificacion s/SeleccionFamilia (c derivaDe e) and
(r tipoRelacion tr)and (e conformadoPor r) and (c modificacionAplicada m) and
(m cambioAplicado s) and (s relacionModificada r)) $ ;
RIII_15: $ forall s1,s2/SeleccionFamilia (exists r1,r2/Relacion
tr/Selectiva (s1 relacionModificada r1) and (s2 relacionModificada r2) and
(r1 tipoRelacion tr) and (r2 tipoRelacion tr) and (s1 == s2) and (r1 == r2))$
end
Especificación III.32. Restricciones de integridad para la clase SelecciónFamilia
La Especificación III.33 implementa en el lenguaje O-Telos la clase Preselección. El
atributo conjuntoSeleccionado identifica todos aquellos conjuntos de variantes válidos de
una familia determinada, que sea componente de la estructura de la que deriva el conjunto
de variantes en la que se define la preselección. El componente vinculado a la preselección
está especificado por el atributo componenteAfectado, cuyo valor se infiere por la regla
componenteAfectadoRule que se presenta en dicha especificación.
El modelo definido exige que todos los conjuntos de variantes vinculados a una
preselección dada sean miembros de una única Familia. Esto se especifica en el modelo a
través del atributo componenteAfectado y mediante la restricción de integridad RIII_33
(Especificación III.33).
Preseleccion with
attribute
conjuntoSeleccionado : ConjuntodeVariantes;
componenteAfectado : Familia
attribute,rule
110
_________________________________________________________ Modelo de productos. Definición
componenteAfectadoRule : $ forall f/Familia (exists cv/ConjuntodeVariantes
(this conjuntoSeleccionado cv) and (cv miembroDe f))
==>(this componenteAfectado f)$
attribute,constraint
RIII_33:$ forall p/Preseleccion (exists
cv1,cv2/ConjuntodeVariantes
f1, f2/Familia (p ConjuntoSeleccionado cv1) and
(p ConjuntoSeleccionado cv2) and (cv1 miembroDe f1) and
(cv2 miembroDe f2)and (f1 == f2) and (p componenteAfectado f1))$
end
Especificación III.33. Definición de la clase Preselección
Utilizando las especificaciones presentadas y, de manera similar a lo expuesto para
el nivel de Familia en la sección previa, es posible inferir nueva información para un conjunto
de variantes.
En primer lugar se presenta la vista estructuraCV, de ConjuntodeVariantes, la cual
permite inferir el resultado de aplicar todas las modificaciones asociadas a un conjunto de
variantes a la estructura de la cual ésta se deriva. Dicha vista (Especificación III.34) se
construye
a
partir
de
otras
vistas
sobre
la
clase
Relación,
denominadas:
RelacionesModificadas, RelacionesSeleccionadas y RelacionesIntactas que permiten inferir
los
valores
de
los
atributos
relacionesModificadas,
y
relacionesSeleccionadas,
relacionesIntactas.
Individual estructuraCV in View isA ConjuntodeVariantesC with
retrieved_attribute, partof
relacionesModificadas: Relacion with
retrieved_attribute
parte:Familia
retrieved_attribute,partof
cambioAplicado : CambioC with
inherited_attribute
newQP:ValorUnidad
constraint
rin:$A(this, cambioAplicado, this::relacionesModificadas::cambioAplicado)$
end
end
inherited_attribute, partof
relacionesIntactas: Relacion with
inherited_attribute
parte:Familia;
quantityPer:ValorRestringido
end
inherited_attribute, partof
relacionesSeleccionadas: Relacion with
inherited_attribute
parte:Familia;
quantityPer:ValorRestringido
end
end
Especificación III.34. Vista estructuraCV
111
_________________________________________________________ Modelo de productos. Definición
La vista RelacionesModificadas (Especificación III.35) obtiene las relaciones que son
afectadas por cambios en los valores de los atributos quantityPer o prodFactor. Esta vista es
una especialización de Relación, de la cual hereda el atributo parte, y posee como
parámetro una Modificación. El nuevo valor del atributo que es modificado, quantityPer o
prodFactor, está dado por los valores indicados por los atributos newQP (si es un
CambioQP) o newPF (si es un CambioPF), según se refleja en los dos términos de la
disyunción presente en la regla. El primer término es aplicable a los cambios de tipo
cambioQP, mientras que el segundo a los denominados cambioPF.
Individual RelacionesModificadas in View isA Relacion with
attribute,parameter
mod : Modificacion
attribute,retrieved_attribute
parte: Familia
attribute,computed_attribute
cantidad : ValorUnidad
attribute,constraint
c:$(exists c/CambioQP (~mod cambioAplicado c) and (c relacionModificada this)
and (c newQP ~cantidad)) or exists c2/CambioPF (~mod cambioAplicado c2) and
(c2 relacionModificada this) and (c2 newPF ~cantidad) $
end
Especificación III.35. Vista RelacionesModificadas
La vista RelacionesSeleccionadas (Especificación III.36) permite obtener las
relaciones (que posee un TipoRelación identificado como Selectiva) que se seleccionan a
partir de los cambios SelecciónFamilia aplicados por las correspondientes modificaciones.
Individual RelacionesSeleccionadas in View isA Relacion with
attribute,parameter
mod : Modificacion
retrieved_attribute
parte:Familia
computed_attribute
cantidad: ValorUnidad
attribute,constraint
c : $ exists c/SeleccionFamilia (~mod cambioAplicado c) and
(c relacionModificada this) and ((this quantityPer ~cantidad )or
(this prodFactor ~cantidad ))$
end
Especificación III.36. Vista RelacionesSeleccionadas
Finalmente, la vista RelacionesIntactas que se muestra en la Especificación III.37,
obtiene todas aquellas relaciones de una estructura que no son afectadas por ninguno de
los tipos de cambios que pueden ser asociados a una Modificación.
Individual RelacionesIntactas in View isA Relacion with
attribute,parameter
mod : Modificacion
attribute,retrieved_attribute
112
_________________________________________________________ Modelo de productos. Definición
parte : Familia
attribute,computed_attribute
cantidad : ValorUnidad
attribute,constraint
c : $ exists c/Cambio tr/TipoRelacion r/Relacion (~mod cambioAplicado c) and
(c relacionModificada r) and not(this == r) and ((this quantityPer ~cantidad)
or (this prodFactor ~cantidad )) and (this tipoRelacion tr)
and not(tr in Selectiva)$ end
Especificación III.37. Vista RelacionesIntactas
A partir del modelo planteado en el nivel de ConjuntodeVariantes es posible formular
otras vistas que permitan inferir la restante información contenida en el mismo. En el
Apéndice A se presentan algunos ejemplos adicionales que permiten apreciar las posibles
extensiones y usos de la especificación.
III.5. NIVEL DE ABSTRACCIÓN PRODUCTO
En los puntos precedentes se han presentado los modelos que corresponden a los
dos niveles superiores de la jerarquía de abstracción propuesta. En el nivel Familia se
especifican aspectos comunes a miembros de una familia de productos. En el nivel
ConjuntodeVariantes se definen subconjuntos de dichos miembros que comparten
características y excepciones comunes. En ambos niveles se maneja información agregada
respecto a la estructura del producto y pueden quedar propiedades no definidas que
deberían terminar de especificarse en el último nivel de abstracción. En el caso de conjuntos
de variantes compuestas, es muy probable que para algunos componentes de su estructura
queden todavía aspectos no completamente definidos (por ejemplo, componentes que aún
tienen asociadas preselecciones con más de un valor en el atributo conjuntoSeleccionado).
Estas definiciones se completan en el nivel Producto de la jerarquía de abstracción
propuesta. Este es el nivel más concreto y representa, en definitiva, un producto con
existencia física. Los productos reales miembros de un ConjuntodeVariantes son
representados por la clase Producto, como se muestra en la Figura III.13.
Un producto puede ser simple (ProductoS) o compuesto (ProductoC) dependiendo si
es miembro de un ConjuntodeVariantesS o de un ConjuntodeVariantesC, respectivamente
(Figura III.13). La definición en O-Telos de estas nuevas clases se ilustra en las
Especificaciones III.38 y III.39.
<<CV>>
ConjuntodeVariantes
miembroDe
<<P>>
Producto
<<PS>>
ProductoS
selecciona
<<sele>>
Selección
<<PC>>
ProductoC
113
_________________________________________________________ Modelo de productos. Definición
Figura III.13. Definición de Producto
En la Especificación III.38, se presenta la especialización de la clase Producto en la
clase ProductoS, que representa todos aquellos integrantes de algún conjunto de variantes
simples. Estos productos son atómicos, ya que no se ensamblan a partir de otros productos,
ni se descomponen en sus partes. La identificación del conjunto de variantes del que es
miembro se realiza, como ya se expresó, mediante el atributo miembroDe, el cual es
definido en la clase Producto y heredado por ProductoS. La especificación se completa con
la restricción de integridad RIII_17, que indica que para todo ProductoS p, debe existir un
ConjuntodeVariantesS cv del cual p es miembro.
Por su parte, en la Especificación III.39 se presenta la definición de la clase
ProductoC. Una restricción similar a la puntualizada para ProductoS se incorpora en la
misma. En otras palabras, para todo ProductoC p, existe algún ConjuntodeVariantes cv con
el cual dicho producto se encuentra relacionado por la asociación miembroDe.
Individual ProductoS in Class isA Producto with
constraint
RIII_17:$forall p/ProductoS(exists cv/ConjuntodeVariantesS (p miembroDe cv)) $
end
Especificación III.38. Definición de la clase ProductoS.
Individual ProductoC in Class isA Producto with
attribute
selecciona: Seleccion
constraint
RIII_18: $forall p/ProductoC (exists cv/ConjuntodeVariantesC (p miembroDe cv))$;
RIII_19: $forall p/ProductoC exists s/Seleccion (p Selecciona s) $
end
Especificación III.39. Definición de la clase ProductoC
En este punto es importante recordar que un Producto es miembro de un
determinado ConjuntodeVariantes, el cual a su vez es miembro de una determinada Familia.
A través de su atributo miembroDe, una instancia de producto puede llegar a determinar
cuál es la familia de la cual es integrante. Para lograr esto, un nuevo atributo denominado
integranteFamilia es agregado a la clase Producto, cuyos valores serán inferidos por la regla
que se muestra en la Especificación III.40.
Individual Producto in Class with
attribute
integranteFamilia: Familia
rule
integranteFamiliaRule:$ forall p/Producto f/Familia (exists
cv/ConjuntodeVariantes (cv miembroDe f) and (p miembroDe cv))
==> (p integranteFamilia f) $
end
114
_________________________________________________________ Modelo de productos. Definición
Especificación III.40. Atributo integranteFamilia de la clase Producto
En este contexto se afirmará que un ProductoC está completamente definido cuando
se hallan identificados los ProductosC y/o ProductosS que se asignarán a cada componente
de la estructura de la cual el primero se ha derivado. Este concepto recursivo en la
estructura de un producto tiene por objetivo obtener una estructura integrada por los
productos que realmente participan en el proceso de fabricación del que se obtiene el
producto en cuestión.
Esta selección está indicada por el atributo selecciona definido en la clase
ProductoC. Sólo un miembro de cada conjunto de variantes preseleccionado en las
respectivas estructuras debe ser elegido por cada componente de la estructura de dicho
producto.
Se propone representar esta elección en el modelo mediante la clase asociación
denominada Selección, la cual se muestra en la Figura III.13 y en la Especificación III.41.
Como propiedad de esta relación se tiene información acerca del conjunto sobre el que se
efectúa la selección, el cual puede surgir de una preselección o contemplar todos los
conjuntos de variantes que son miembros de una familia.
Individual Seleccion in Class with
attribute
productoElegido:Producto;
conjuntoASeleccionar: ConjuntodeVariantes
end
Individual Seleccion with
rule
conjASeleccionarRule: $ forall s/Seleccion cv/ ConjuntodeVariantes
(exists cv2/ ConjuntodeVariantesC p,p2/Producto (p selecciona s) and
(p miembroDe cv2) and (cv2 componenteDirecto cv) and (p productoElegido p2)
and
(p2 miembroDe cv2)) ==> (s conjuntoASeleccionar cv)$
end
Especificación III.41. Definición de la clase Selección
III.6. ADMINISTRACIÓN DE RESTRICCIONES
Cuando un modelo define una estructura genérica de una familia de productos y
reglas para especializarla en una estructura particular correspondiente a un producto
miembro de tal familia, puede llegar a permitir un gran número de posibles combinaciones
de componentes o partes (productos). En la práctica algunas de esas combinaciones
pueden ser inválidas por razones técnicas o comerciales. Cuando se definen estructuras
genéricas de productos, como las asociadas a los niveles de abstracción Familia y
ConjuntodeVariantes, éstas incluyen un modelo implícito de la estructura del producto, que
provee condiciones adicionales que deben ser satisfechas por cualquier producto válido
(Männistö y colab., 1998). Con el fin de derivar estructuras particulares válidas a partir de
115
_________________________________________________________ Modelo de productos. Definición
estructuras genéricas, es necesario contar con un mecanismo para expresar las
restricciones entre componentes (familias, conjuntos de variantes o productos) que pudieran
existir y que puedan ser verificadas durante el proceso de generación del BOM (estructura
del producto). Teniendo en cuenta este requerimiento, el modelo propuesto incluye un
mecanismo para expresar restricciones que deben ser validadas al momento en que las
estructuras (genéricas o particulares) sean creadas.
El modelo propuesto contempla tres tipos de restricciones, de acuerdo a cada uno de
los
niveles
que
fueron
definidos:
i)
entre
Familias
(RestricciónF);
ii)
entre
ConjuntosdeVariantes (RestricciónCV); y iii) entre Productos (RestricciónP). Estas
restricciones complementan aquéllas establecidas por los tipos de relaciones de
composición/descomposición que se presentaron anteriormente. En la Figura III.14 se
introduce el diagrama de clases que representa los conceptos mencionados. Se puede
observar que cada tipo de restricción se establece entre pares de instancias de un mismo
nivel. Esto es, entre instancias de Familia o entre ocurrencias de ConjuntodeVariantes o
entre instancias de Producto.
<<I>>
Incompatible
<<Rest>>
Restricción
<<RF>>
RestricciónF
<<F>>
Familia
tipoRestricción
<<RCV>>
RestricciónCV
<<CV>>
ConjuntodeVariantes
<<O>>
Obligatoria
<<Trest>>
TipoRestricción
<<RP>>
RestricciónP
<<P>>
Producto
Figura III.14. Diagrama de clases asociadas a la administración de restricciones
La Especificación III.42 define, en lenguaje O-Telos, las clases presentadas en la
Figura III.14.
Individual Restriccion in Class with
attribute
tipoRestriccion: TipoRestriccion
end
Individual RestriccionF in Class isA Restriccion with
attribute
restringe: Familia
end
Individual RestriccionCV in Class isA Restriccion with
attribute
restringe: ConjuntodeVariantes
end
116
_________________________________________________________ Modelo de productos. Definición
Individual RestriccionP in Class isA Restriccion with
attribute
restringe: Producto
end
Especificación III.42. Definición de la clase Restricción y sus especializaciones
La clase Restricción tiene un atributo tipoRestricción que determina cuál es el tipo de
restricción que se aplica y un atributo restringe que determina cuál es la abstracción de
producto sobre la que se aplicará la restricción. En cada una de las especializaciones de
Restricción, el valor del atributo restringe establece sobre qué especialización de
AbstraccióndeProducto será aplicable la restricción en cuestión. En el caso de una
RestricciónF, los valores de dicho atributo sólo podrán ser instancias de Familia, en el caso
de RestricciónCV serán instancias de ConjuntodeVariantes, mientras que para RestricciónP,
éstos serán Productos.
En cada nivel es posible identificar dos tipos principales de restricciones entre
componentes: i) las que expresan la obligatoriedad de la presencia del componente
correspondiente, y ii) las que indican la incompatibilidad entre ciertos componentes. Ambas,
de ser aplicables, deben ser verificadas para obtener estructuras válidas. Estas restricciones
se representan mediante la clase TipoRestricción (Figura III.14), y sus especializaciones,
denominadas RObligatoria e RIncompatible, se definen en la Especificación III.43.
Individual TipoRestriccion in Class end
Individual RObligatoria in Class isA TipoRestriccion end
Individual RIncompatible in Class isA TipoRestriccion end
Individual robligatoria in RObligatoria end
Individual rincompatible in RIncompatible end
Especificación
especializaciones
III.43.
Definición
de
la
clase
TipoRestricción
y
sus
El primer tipo de restricción (de obligatoriedad), impone que un conjunto determinado
de
instancias
de
un
nivel
particular
de
AbstraccióndeProducto
(Familias,
ConjuntodeVariantes o Productos) estén presentes en la estructura en la que participa la
instancia que está estableciendo la restricción de obligatoriedad. Para verificar el
cumplimiento o no de este tipo de restricciones es necesario poder determinar cuáles son
los componentes de dicha estructura, la cual corresponde a la SH de una Familia, de un
ConjuntodeVariantes, o de un Producto. En la especificación III.15, se presenta el atributo
componente en la clase Familia que permite inferir, mediante la regla compRule, aquellas
familias que participan directa o indirectamente en la estructura de una determinada familia.
De manera similar, en las Especificaciones III.44 y III.45, se definen los atributos y las reglas
para inferir los componentes de la SH de cada uno de los otros niveles de la AH.
117
_________________________________________________________ Modelo de productos. Definición
Particularmente, la Especificación III.44 a través de las reglas componenteRule,
compDirectoRule
y
compDirectoRule2,
infiere
los
valores
de
los
atributos
componenteDirecto y componente de la clase ConjuntodeVariantes, los cuales indican la
presencia (directa e indirecta) de un ConjuntodeVariantes en la estructura de otro conjunto.
Un ConjuntodeVariantes cv2 es componente de otro ConjuntodeVariantesC cv1
componenteDirecto
de
cv2
o
si
existe
otro
ConjuntodeVariantes
cv3
si es
que
es
componenteDirecto de cv1 y cv2 es componente de cv3 (componenteRule). Un
ConjuntodeVariantes cv2 es componenteDirecto de otro ConjuntodeVariantesC cv1 si:
es preseleccionado por cv1 directamente, en otras palabras, existe una
preselección p en cv1 que tiene a cv2 como conjuntoSeleccionado
(comDirectoRule); o
es miembroDe alguna Familia f que forma parte de la estructura de cv1 y no
existe ninguna preselección en cv1 para f (comDirectoRule2).
Individual ConjuntodeVariantesC with
attribute
componenteDirecto:ConjuntodeVariantes;
componente:ConjuntodeVariantes
rule
compDirectoRule : $ $forall cv1/ ConjuntodeVariantesC
cv2/ ConjuntodeVariantes ( exists p/Preseleccion (cv1 preselecciona p) and
(p ConjuntoSeleccionado cv2) )==> (cv1 componenteDirecto cv2)$;
compDirectoRule2 : $ forall cv2/ConjuntodeVariantesC (exists f/Familia
(this fliaComponente f) and not(this componenteAfectado f) and
(cv2 miembroDe f)) ==> (this componenteDirecto cv2) $;
componenteRule : $ forall cv1/ConjuntodeVariantesC cv2/ConjuntodeVariantes
(cv1 componenteDirecto cv2) or (exists cv3/ConjuntodeVariantesC
(cv1 componenteDirecto cv3 ) and (cv3 componente cv2))
==> (cv1 componente cv2)$;
end
Especificación III.44. Definición de los atributos componenteDirecto y
componente en la clase ConjuntodeVariantes
De manera similar, en la especificación III.45 se presentan los atributos componente
y componenteDirecto para la clase Producto, así como las reglas compDirectoRule y
componenteRule, que permiten inferir los componentes presentes en una jerarquía
estructural del nivel más bajo de la AH, es decir Producto.
ProductoC with
attribute
componenteDirecto: Producto;
componente: Producto
rule
118
_________________________________________________________ Modelo de productos. Definición
compDirectoRule:$forall p1/ProductoC p2/Producto (exists
(p1 selecciona s) and (s productoElegido p2))
==> (p1 componenteDirecto p2) $;
s/Seleccion
componenteRule:$ forall p1/ProductoC p2/Producto (p1 componenteDirecto p2) or
(exists p3/ProductoC (p1 seleciconDirecta p3) and (p3 componente p2))
==> (p1 componente p2) $
end
Especificación III.45. Definición de los atributos componenteDirecto y
componente en la clase Producto
La definición de una Restricción de tipo obligatoria, se especifica de manera diferente
para cada una de las especializaciones de dicha clase, las cuales se corresponden con cada
nivel de la AH. Surgen así las Especificaciones III.46 a III.48 que corresponden a
restricciones
de
obligatoriedad
entre
Familias,
ConjuntodeVariantes
y
Productos,
respectivamente.
Individual RestriccionF in Class isA Restriccion with
constraint
restriccionRule: $ forall f1/FamiliaC f2/Familia (exists r/RestriccionF
tr/Obligatoria (f1 restringeA r) and
(r restringe f2) and
(r tipoRestriccion tr) and (f1 componente f2) )$
end
Especificación III.46. Restricción de obligatoriedad entre Familias
Individual RestriccionCV in Class isA Restriccion with
attribute
restringe : ConjuntodeVariantes
constraint
restriccionRule:$forall cv1/ ConjuntodeVariantesC cv2/ConjuntodeVariantes
(exists r/RestriccionCV tr/Obligatoria (cv1 restringeA r) and
(r restringe cv2) and (r tipoRestriccion tr) and
(cv1 componente cv2))$
end
Especificación III.47. Restricción de obligatoriedad entre ConjuntosdeVariantes
Individual RestriccionP in Class isA Restriccion with
attribute
restringe : Producto
constraint
restriccionRule: $ forall p1/ProductoC p2/Producto (exists r/RestriccionP
tr/Obligatoria (p1 restringeA r) and (r restringe p2) and
(r tipoRestriccion tr) and (p1 componente p2)) $
end
Especificación III.48. Restricción de obligatoriedad entre Productos
Una restricción de incompatibilidad establece que determinadas instancias (una o
más) de un cierto nivel de AbstraccióndeProducto (Familia, ConjuntodeVariantes o
Producto), no deben incluirse en la estructura en la que está presente la instancia que
119
_________________________________________________________ Modelo de productos. Definición
establece
la
restricción
de
incompatibilidad.
En
consecuencia,
se
definen
las
Especificaciones III.49 a III.51 que corresponden a restricciones de incompatibilidad entre
Familias, ConjuntodeVariantes y Productos, respectivamente.
Individual RestriccionF in Class isA Restriccion with
attribute,constraint
restriccionRule2 : $ forall f1/FamiliaC f2/Familia (exists r/RestriccionF
tr/Incompatible (f1 restringeA r) and (r restringe f2) and
(r tipoRestriccion tr) and not (f1 componente f2) )$
end
Especificación III.49. Restricción de incompatibilidad entre Familias
Individual RestriccionCV in Class isA Restriccion with
attribute,constraint
restriccionRule2 : $ forall cv1/ ConjuntodeVariantesC cv2/ ConjuntodeVariantes
(exists r/RestriccionCV tr/Incompatible (cv1 restringeA r) and
(r restringe cv2) and (r tipoRestriccion tr) and
not (cv1 preseleccionIndir cv2)) $
end
Especificación
ConjuntosdeVariantes
III.50.
Restricción
de
incompatibilidad
entre
Individual RestriccionP in Class isA Restriccion with
attribute
restringe : Producto
constraint
restriccionRule : $ forall p1/ProductoC p2/Producto (exists r/RestriccionP
tr/Incompatible (p1 restringeA r) and (r restringe p2) and
(r tipoRestriccion tr) and (not (p1 seleccionIndir p2)))$
end
Especificación III.51. Restricción de incompatibilidad entre Productos
En base a las especificaciones anteriores es posible definir, para cada uno de los
niveles de AbstraccióndeProducto, los atributos incompatibleCon y obligatorioCon, y a partir
de las reglas correspondientes se inferirá el valor de los mismos. Es decir, para una
instancia definida en un determinado nivel, dichas reglas permitirán conocer cuáles son las
instancias incompatibles y cuáles son las obligatorias. En la Especificación III.52 se presenta
la definición de estos atributos, así como las reglas correspondientes a la clase Familia.
Podrían efectuarse definiciones similares para las clases ConjuntodeVariantes y Producto,
las cuales no se incluyen en esta Tesis.
Familia with
attribute
incompatibleCon:Familia;
obligatorioCon:Familia
rule
120
_________________________________________________________ Modelo de productos. Definición
incompatibleConRule:$ forall f/Familia (exists r/RestriccionF tr/Incompatible
(this restringeA r) and (r tipoRestriccion tr) and
(r restringe f))
==> (this incompatibleCon f)$;
obligatorioConRule:$ forall f/Familia (exists r/RestriccionF tr/RObligatoria
(this restringeA r) and (r tipoRestriccion tr) and
(r restringe f))
==> (this obligatorioCon f)$
end
Especificación III.52. Definición
obligatorioCon en la clase Familia
de
los
atributos
incompatibleCon
y
III.7. SISTEMA DE GENERACIÓN DE BOMS
El concepto de BOM generativo está muy ligado al concepto de Familia de productos
(FP), ya que, en general, la información común que se define está asociada a una FP. Se
entiende que una familia de productos es “un grupo de productos relacionados que
comparten características, componentes y satisfacen una variedad de nichos del mercado”
(Zha y Sriram, 2006).
Trabajar, con los conceptos de FP y BOMs generativos implica dos fases principales:
i) definición de la familia de productos, su estructura e información común a todos sus
integrantes; y ii) la derivación de información específica para cada uno de los miembros de
la familia. Las dos fases mencionadas están soportadas por diferentes tipos de sistemas;
por un lado, un sistema de especificación de productos, y por otro, un sistema de generación
de BOMs. El primero se vincula con la administración de la información común y con la
definición de reglas de derivación. El segundo, en cambio, hace uso de las especificaciones
mantenidas en el sistema previo para derivar, teniendo en cuenta también los
requerimientos de los clientes, una estructura de producto válida. En este trabajo, el
conjunto definido por estos dos tipos de sistemas, será denominado “sistema de
procesamiento de BOMs”.
La estructura de un producto compuesto particular es el resultado que se obtiene del
sistema de procesamiento de BOMs. Este sistema es el responsable de la creación,
mantenimiento y recuperación de diferentes árboles de estructura para variantes de
productos particulares. Tiene asociadas tres actividades básicas: definición de familias,
definición de conjunto de variantes y derivación de la estructura de productos específicos (o
definición de producto). Este proceso, que se muestra en la Figura III.15, emplea
información de los dos niveles de abstracción más altos (Familia y ConjuntodeVariantes),
para generar una nueva entidad en el nivel más bajo (Producto).
121
_________________________________________________________ Modelo de productos. Definición
Definición Familia
Definición Conjunto
de Variantes
Sistema de especificación de productos
Definición Producto
Sistema de
generación de BOMs
Figura III.15. Módulos del sistema de procesamiento de BOMs
Para poder obtener la estructura de un producto en el sistema de generación de
BOMs, previamente deben estar completamente definidos el conjunto de variantes del que
es miembro el producto en cuestión, así como la familia a la que dicho conjunto pertenece.
Luego, se deberá seleccionar el conjunto de variantes a partir del cual se va a generar el
producto en particular que se desea crear. Si se trata de un producto de tipo ProductoC, se
debe inferir la estructura que le corresponde a partir de la información asociada al conjunto
de variantes compuestas del que éste es miembro. Finalmente, teniendo en cuenta las
preselecciones que el conjunto de variantes tiene definidas, se debe optar por una de dichas
preselecciones por cada componente de la estructura (previamente inferida). En caso de no
existir preselecciones para algún componente, se deberá seleccionar algún conjunto de
variantes a partir de todos aquéllos que dicho componente posee como miembros.
En la siguiente sección se presenta, mediante distintos diagramas de interacción, las
tareas involucradas en la creación de los miembros de los diferentes niveles de abstracción
propuestos. La presentación se desarrollará en el orden establecido esquemáticamente en
la Figura III.15. Se comenzará con las actividades propias de la definición de una Familia,
pasando luego a las características de un ConjuntodeVariantes y finalizando con la
definición de un Producto.
III.7.1. Actividades de creación de los miembros de los distintos niveles de
abstracción de productos.
Las actividades que deben llevarse a cabo para la definición de una instancia del
nivel Familia pueden agruparse en tres grandes actividades:
Creación de la Familia: involucra la creación de una instancia de la clase y la
definición de las propiedades de la misma. Aquí debe tenerse en cuenta que
dependiendo de la organización en la que se haya implementado y especializado
el modelo, estas características van a ser diferentes.
Creación de las restricciones de la Familia (si las tuviera, en el caso de las
familias compuestas): creación de instancias de la clase RestricciónF y definición
122
_________________________________________________________ Modelo de productos. Definición
de su tipo (incompatible u obligatoria) y de la familia que sobre la que se aplica la
restricción.
Creación de la Estructura de la Familia (si se trata de una familia compuesta):
dependiendo del tipo de Familia que se esté definiendo, se creará una instancia
de la clase EstructuraC o de la clase EstructuraD.
En la Figura III.16 se presenta el diagrama de interacción resumido asociado a la
creación de una instancia de la clase FamiliaC. Pueden verse allí, los mensajes que se
intercambian para llevar a cabo las actividades mencionadas.
Por su parte, la Figura III.17 muestra el diagrama de interacción que representa los
mensajes intercambiados para la actividad de creación de una EstructuraC. Para cada
componente que se quiere agregar en la estructura, primero se debe verificar que no se
haya definido alguna restricción de incompatibilidad entre la familia que se está creando y la
familia que se desea incorporar como componente. Si no se viola ninguna restricción, se
define la relación de composición correspondiente, en la cual se establece la familia
componente, y se crean las instancias de ValorRestringido que corresponden a los atributos
quantityPer y prodFactor.
:FamiliaC
Usuario
CrearFamilia
SetCaracteristicas()
restringeA= SetRestriccion(tipo, flia)
:RestriccionF
new
tipoRestriccion= SetTipo(tipo)
restringe= SetRestringe(flia)
SetEstructura
:EstructuraC
[es composición?]: estructuraDe= New
:EstructuraD
[esDescomposición?]: estructuraDe= New
Figura III.16. Diagrama de Interacción correspondiente a la creación de una
instancia de la clase FamiliaC
123
_________________________________________________________ Modelo de productos. Definición
:FamiliaC
:EstructuraC
Verifica si no hay restricciones de incompatibilidad entre
la familia que se está definiendo y el componente que se
está incorporando a la estructura
new
loop Para cada componente
AgregarComponente
VerificarRestricciones
opt RestriccionesOK
:RelacionC
componente= new
parte= setParte(unaFlia)
:ValorRestringido
quantityPer= new(unValor, udeM,unMin, unMax)
:ValorRestringido
prodFactor= new(unValor,ude,unMin,unMax)
Figura III.17. Diagrama de interacción CrearEstructuraC
En la Figura III.18 se presenta el diagrama de interacción asociado a la creación de
una instancia de la clase ConjuntodeVariantesC. Puede observarse en la misma, que al
igual que en el caso de la Familia, existen dos grandes actividades que se vinculan con la
creación de una instancia de la clase ConjuntodeVariantesC, la definición de restricciones
para el conjunto de variantes que se está creando y la definición de la estructura del mismo.
En la primera actividad, se debe determinar la Familia a la que pertenece el conjunto de
variantes en cuestión. Por su parte, la actividad de creación de la estructura involucra, la
selección de la estructura de la que se deriva el conjunto de variantes que se está
definiendo, la creación de las modificaciones que es necesario incluir en la estructura en
cuestión, así como la preselección de opciones para los componentes de dicha estructura.
124
_________________________________________________________ Modelo de productos. Definición
CV1
:ConjuntoDeVariantesC
:Preseleccion
:DiseñadorProducto
New
setPropiedades
setRestriccion
:RestriccionCV
restringeA= new
derivaDe= setEstructura
[si modifica Estructura]: setModificaciones
Modificacion
modificacionAplicada= new(derivaDe)
[si preselecciona Conj.de Variantes]: preseleccionar
Preseleccion
[si es nueva preseleccion]: preselecciona= New
[si ya existe preseleccion]: AgregarCV
Figura III.18. Diagrama de Interacción asociado a la creación de una instancia de la
clase ConjuntodeVariantesC
Dado que la modificación de relaciones es una parte fundamental de la creación de
un conjunto de variantes, la Figura III.19 presenta el diagrama de interacción relacionado
con la creación de una instancia de Modificación. En él puede observarse el intercambio de
mensajes que implica la definición de un cambio. Este intercambio se repite para cada uno
de las alteraciones que se especifican en la modificación que está siendo creada.
Puede observarse en dicha figura que hay un conjunto de mensajes que es común a
cualquier tipo de cambio; mientras que hay otro que es diferente, dependiendo del cambio
que se quiera crear. Inicialmente se especifica la relación que se desea modificar y el tipo de
cambio que se quiere realizar sobre la misma.
Si dicho cambio es de tipo Eliminación, se debe verificar que el tipo de la relación
que se desea modificar sea optativa (se debe recordar que este tipo de relaciones es el
único que puede quitarse de una estructura). Si esto se cumple, se debe verificar aún que
no exista una restricción de obligatoriedad entre la familia que se elimina de la estructura y
la familia cuya estructura se está modificando. En caso de que no existan obligatoriedades,
se crea la instancia de Eliminación que representa el cambio en cuestión. Si las restricciones
anteriores no se verificasen, el cambio no podría realizarse.
Si el cambio deseado es de tipo SelecciónFamilia, se verifica solamente si el tipo de
la relación que va a ser afectada por el cambio es efectivamente Selectiva. Si esto ocurre,
se creará la instancia en cuestión.
125
_________________________________________________________ Modelo de productos. Definición
:Modificacion
unaRelacion
:Relacion
qp :ValorRestringido
:ValorRestringido
loop para cada cambio
unaRelacion= getRelacionAModif
tipoC= getTipoCambio
tipoR= getTipoRelacion
opt
restriccionesOK= checkRestricciones
[restriccionesOK ]: cambioAplicado= New(unaRelacion)
opt
:Eliminacion
:SeleccionFamilia
cambioAplicado= New(unaRelacion)
opt
nuevoValor= getNuevaCantidad
qp= getquantityPer
limitesOK= checkLimites(nuevoValor)
:CambioQP
[limitesOK==True]: cambioAplicado= New(unaRelacion.nuevoValor)
opt
nuevoValor= getNuevaCantidad
pf= getprodFactor
limitesOK= checkLimintes(nuevoValor)
:CambioPF
[limitesOK==True]: cambioAplicado= New(unaRelacion, nuevoValor)
Figura III.19. Diagrama de Interacción asociado a la creación de una instancia
de la clase Modificación
Si se tratase de un CambioQP o de un CambioPF, éste podría ser aplicado a
cualquier tipo de relación (obligatoria, selectiva u optativa). Para implementar el cambio, se
deberá especificar el nuevo valor del atributo quantityPer o prodFactor (según cuál sea el
cambio). Sin embargo, antes de crear la instancia de cambio correspondiente, se debe
verificar que el nuevo valor no esté fuera de los límites mínimo y máximo del atributo que se
modifica (quantityPer o prodFactor). Si estos límites son respetados, se crea entonces la
instancia que corresponde.
Finalmente, la Figura III.20 presenta las actividades involucradas en la definición de
un Producto. En la misma se observa la creación de una instancia de la clase con dicho
nombre y el establecimiento de una relación de pertenencia de esta instancia con el
conjunto de variantes del cual es miembro. Luego se definen las restricciones, tanto de
126
_________________________________________________________ Modelo de productos. Definición
obligatoriedad como de incompatibilidad, entre la instancia de Producto que está siendo
creada y otros productos ya definidos. En caso de tratarse de un ProductoC, deberán
seleccionarse los productos asociados a cada componente de la estructura. Para ello, se
debe obtener la estructura del producto que se desea crear (definida en el conjunto de
variantes del que éste es miembro). Asimismo, para cada uno de sus componentes, se
deberá seleccionar un producto a asociar. Esto implica que primeramente deberá conocerse
el conjunto a partir del cual se seleccionará un componente, el cual se obtiene del conjunto
de variantes antes mencionado. El conjuntoSelección podrá estar dado por una
Preselección, si es que existe para la Familia componente que se está tratando o, por todos
los conjuntos de variantes que son miembros de dicha Familia.
:ProductoC
:ConjuntoDeVariantesC :ConjuntoDeVariantes
:DiseñadorProducto
New
miembroDe= setPertenencia
:RestriccionP
restringeA= New
productSTR= getEstructura
loop Para Cada Componente en ProductSTR
selecciona= seleccionarProducto(unComponente)
conjuntoSeleccionado= existePreseleccion(unComponente)
productosOK= getProductos(conjuntoSeleccionado)
listaProductos= getMiembros
checkRestriccion(ProductosOK)
unaSeleccion= New(ProductosOK)
:Seleccion
productoElegido= setOpcion(ProductoOk)
Figura III.20. Diagrama de interacción asociado a la creación de una instancia de la
clase ProductoC.
Teniendo en cuenta dicho conjuntoSeleccionado, se deberá verificar si no hay
productos que violen las restricciones previamente establecidas para el producto que está
siendo definido. Aquellos productos para los que existan incompatibilidades, serán
eliminados de la lista. En caso de existir una restricción de obligatoriedad con algún
producto de la lista, este único producto quedará en la misma ya que es el que deberá ser
seleccionado para no violar la restricción mencionada. En base a la lista de productos que
no violen las restricciones (ProductosOK en el diagrama), se creará una instancia de la clase
Selección donde se establecerá el valor del atributo productoElegido a partir del producto
seleccionado.
127
_________________________________________________________ Modelo de productos. Definición
III.8. CONCLUSIONES
En este capítulo se introdujo el modelo de productos que constituye el principal
aporte de esta Tesis. La propuesta se basa en dos jerarquías de conceptos, denominadas
jerarquía de abstracción (AH) y jerarquía estructural (SH). La representación de
conocimiento planteada integra estas jerarquías, enfatizándose en la Tesis el tratamiento de
la información de tipo estructural. No obstante, este planteo integrado de jerarquías deja
sentada las bases para formalizar procesos de agregación-desagregación de información,
que quedaron fuera del alcance de este trabajo.
La propuesta utiliza los conceptos de familia de productos y de BOM generativo para
la representación eficiente de información estructural de un elevado número de variantes de
productos. La misma se define en tres niveles de abstracción diferentes: Familia, Conjunto
de Variantes y Producto, posibilitando la gestión de información con distintos niveles de
agregación. Esta característica es muy importante para la generación de información
requerida por las actividades de planificación de la producción a largo, mediano y corto
plazo (estratégica, táctica y operativa).
La Familia es el nivel más abstracto y define la información común a todos sus
miembros, representados a través de conjuntos de variantes. Cada familia puede tener
asociada más de una estructura, permitiendo así la representación de productos con
múltiples recetas de producción.
A diferencia de las propuestas existentes, el modelo presentado, además de permitir
la representación de productos que se obtienen por ensamblado de partes, puede utilizarse
en industrias que emplean materias primas no atómicas; es decir, a partir de las cuales se
obtienen productos intermedios que ingresan luego en el proceso productivo.
Para la representación de estos diferentes tipos de estructuras, el modelo define
diferentes relaciones, de composición y de descomposición. Estas son relaciones todoparte, en el que las estructuras son el todo y las partes corresponden a otras familias de
productos, que son componentes de la familia a la que está asociada la mencionada
estructura (para las relaciones de composición) o son derivados que se obtienen a partir de
dicha familia (en el caso de las relaciones de descomposición). En cualquiera de los dos
casos, las relaciones mantienen información acerca de cantidades numéricas que
simbolizan, según el caso, la cantidad que se necesita de la parte para obtener una unidad
del todo o la proporción que representa la parte respecto del todo.
El
siguiente
nivel
de
abstracción,
denominado
Conjunto
de
Variantes
(ConjuntodeVariantes), se corresponde con la definición de distintos subconjuntos de
miembros de una familia, a partir de aspectos diferenciadores que distinguen unos de otros.
Para el caso de Familias compuestas, las diferentes estructuras constituyen el punto a partir
128
_________________________________________________________ Modelo de productos. Definición
del cual se hace la separación de los distintos ConjuntosdeVariantesC. De esta manera,
cada conjunto de variantes se asocia a una única estructura. Para familias simples, esta
separación en conjuntos de variantes se puede dar de acuerdo a marcas, proveedores,
calidades y algunos otros criterios, que no son abordados en esta Tesis.
Es posible que la estructura asociada a un determinado conjunto de variantes
presente algunas modificaciones respecto de la estructura común de la familia, de la cual el
mencionado conjunto deriva. Los cambios que el modelo considera comprenden la
eliminación de componentes, la alteración parcial de la cantidad de composición de ciertos
componentes, así como la adopción de una de las relaciones selectivas de la estructura, si
es que éstas existieran.
En el último nivel propuesto, denominado Producto, se definen los miembros de un
conjunto de variantes, representándose productos con existencia física. Todos los productos
que son miembros de un ConjuntodeVariantes en particular poseen la misma estructura que
éste. Por lo tanto, en este nivel no se hacen modificaciones en las relaciones estructurales,
sino que se especifican aquéllos componentes que aún no se hubiesen definido, y cuyas
opciones estuvieran abiertas.
Un aporte importante del modelo propuesto es la incorporación de los elementos
necesarios para la definición de restricciones en cualquiera de los tres niveles de
abstracción, tanto de obligatoriedad como de incompatibilidad entre componentes. La
definición explícita de restricciones permite evitar la derivación de estructuras de productos
inválidas; esto es una característica importante, especialmente en el caso de productos que
son especificados por los clientes. Las mismas evitan que el cliente pueda especificar
configuraciones inválidas.
Teniendo en cuenta los requerimientos que un modelo de productos deberá
satisfacer, los que fueron planteados en el Capítulo I, es posible señalar que el modelo
introducido en este capítulo permite:
La administración eficiente de un elevado número de variantes a través de la
utilización del concepto de familia de productos que fuera implementado mediante la
jerarquía de abstracción propuesta, materializada por los conceptos de Familia,
ConjuntodeVariantes y Producto.
La representación de productos con diferentes tipos de estructuras: de composición,
descomposición e híbridas.
La gestión de estructuras alternativas a través de los múltiples valores que puede
tomar la relación estructuraDe para una cierta Familia y la posibilidad de seleccionar
una determinada estructura para cada ConjuntodeVariantes que es miembro de
dicha Familia.
129
_________________________________________________________ Modelo de productos. Definición
La representación de las distintas vistas que cada unidad organizacional tiene de la
estructura de los productos. Ésta se encuentra en relación con el manejo de
estructuras alternativas, ya que cada una de estas vistas puede asociarse a una
estructura particular de una familia.
Los conceptos del modelo propuesto se presentaron mediante diagramas UML y la
correspondiente especificación en el lenguaje O-Telos, con su implementación en la base de
conocimientos ConceptBase. El lenguaje utilizado en la formalización, que combina objetos
con lógica de primer orden, permite establecer un vocabulario común para la definición de
estructuras de productos y especificar la semántica de cada término de manera no ambigua
a través de la lógica de predicados de primer orden. Por otra parte, la implementación en
una base objeto-deductiva permite deducir nuevo conocimiento mediante la máquina de
inferencia que soporta ConceptBase.
La propuesta presentada en esta Tesis es el resultado de un proceso iterativo e
incremetal, que fue arrojando como resultado la definición de diferentes versiones del
modelo (Vegetti y colab., 2001a) (Vegetti y colab., 2002a) (Vegetti y colab., 2003), (Vegetti y
colab., 2005a) que fueron evolucionando hasta alcanzar las características presentadas
aquí. Durante el desarrollo de este proceso, las diferentes versiones se fueron empleando
para la representación de productos de diferentes tipos de industrias, productos cárnicos
(Vegetti y colab., 2001b), golosinas (Vegetti y colab.,2002b) y muebles (Vegetti y colab.,
2004), por ejemplo Esto, permitió detectar las deficiencias que las versiones preliminares
iban teniendo para la representación de casos reales y corregirlas en consecuencia.
En el capítulo siguiente se muestra cómo el modelo propuesto puede emplearse para
representar productos de dos tipos de industrias diferentes. Específicamente se aborda la
representación de los productos que fueran introducidos en los casos de estudio del
Capítulo II.
130
131
IV.
MODELO DE PRODUCTOS. APLICACIONES
IV.1. INTRODUCCIÓN
Este capítulo tiene por objetivo presentar la aplicación del modelo de productos
propuesto en el Capítulo III a los dos casos de estudio introducidos en el Capítulo II. En
ambos, a partir de los datos reales, se delimitó un subconjunto de productos a ser
modelado.
Los conjuntos identificados fueron cargados, utilizando una representación BOM
tradicional, en una base de datos ConceptBase. Posteriormente, utilizando la información
disponible en estas bases se identificaron, para cada caso, las familias, conjuntos de
variantes y los productos, tanto simples como compuestos, correspondientes. En particular,
se identificaron las estructuras comunes pertenecientes a cada una de las familias
compuestas. En el caso de conjuntos de variantes compuestas, se estableció de qué
estructura se deriva cada uno de ellos y, de ser necesario, qué modificaciones aplicarle a la
estructura identificada. Finalmente, la información así modelada se introdujo en sendas
bases de datos ConceptBase, una por cada caso de estudio.
A partir de estas bases de datos se extrajeron los ejemplos que se presentan en este
capítulo, cuya presentación se realiza mediante:
Diagramas de objetos, obtenidos a partir de la herramienta “ConceptBase
Graphical Editor”. Ésta permite representar gráficamente la información de
productos almacenada en las bases de datos.
Especificaciones formales en código O-Telos, las cuales incluyen:
o
la definición de instancias de las distintas clases empleadas; y
o
vistas que permiten lograr una visualización conjunta de información
que se encuentra dispersa en distintas instancias.
Imágenes de la ventana “Telos Editor”, que muestran el resultado de
consultas efectuadas a las bases de datos. “Telos Editor” constituye una parte
de la interfaz gráfica de ConceptBase, que permite el ingreso de definiciones
y consultas a la base de datos en su parte superior, mostrando el resultado
de dichas acciones en la parte inferior.
129
________________________________________________________ Modelo de Productos. Aplicaciones
En la sección IV.2 se expone el caso de estudio correspondiente a los productos de
la planta de golosinas. Se seleccionó como ejemplo la jerarquía de abstracción que se
define a nivel de caramelos envueltos para los caramelos rellenos frutales. En este ejemplo
se muestra la capacidad expresiva que posee el modelo para gestionar un número
importante de variantes. En particular, se definió la familia CarameloFrutalEnv que agrupa a
todos los caramelos rellenos que poseen algún sabor frutal (independientemente de su
marca, tipo y sabor). De todos los conjuntos de variantes que son miembros de esta familia
que se identificaron, se presentan en este capítulo solamente dos. Ellos son
BolsínFrutalROC y VaritaKIM, representantes de dos de las marcas que se manejan (ROC y
KIM) y de los dos tipos de caramelos (Bolsín y Varita). Cada uno de estos conjuntos agrupa
a todos los caramelos de una misma marca y un determinado tipo, pero en sus diferentes
sabores. Esta característica (el sabor del caramelo) es la que se especifica en las entidades
del nivel Producto. En particular, se presenta el producto SE508219 (VaritaKIMFrutilla),
miembro del conjunto de variantes VaritaKIM en sabor frutilla.
Por su parte, la sección IV.3 presenta la aplicación del modelo al caso de estudio de
productos de la industria frigorífica. Inicialmente se describen los diferentes niveles de
abstracción definidos para representar los productos finales que corresponden al grupo de
las carnes cocidas congeladas que se expusieron en la Tabla II.52. Luego se presentan dos
familias, denominadas SECarneCocidaCongelada y CuadrilConTapa, cada una de las
cuales posee distintos tipos de estructuras. La primera de ellas tiene dos, ambas son de
composición y, además, una de las estructuras posee relaciones de tipo selectivas. La otra
familia mencionada, en cambio, tiene asociadas estructuras de descomposición. Finalmente,
se explica cómo se define la estructura del conjunto de variantes SECarneCocidaReb
(miembro de SECarneCocidaCongelada), a partir de una estructura que posee relaciones
selectivas. Los otros conjuntos de variantes y productos no se ejemplificarán debido a que
su tratamiento no difiere del introducido en la sección IV.2.
IV.2. APLICACIÓN DEL MODELO A LOS PRODUCTOS DE LA PLANTA DE GOLOSINAS
En el primer caso de estudio presentado en el Capítulo II se expuso parte del modelo
de productos que actualmente utiliza una industria de producción de golosinas. En particular,
los productos analizados corresponden a caramelos duros rellenos elaborados en una de las
plantas de dicha organización. De todos estos productos, se eligieron los correspondientes a
cajas con bolsas conteniendo diferentes combinaciones de caramelos duros, de distintos
sabores y embalados en diferentes cantidades. En la Figura II.7 se presentó una estructura
genérica que muestra esquemáticamente cómo es la estructura de estos productos.
Como se mencionó en el Capítulo III, el modelo se aplica de igual manera en todos
los niveles mostrados en dicha estructura genérica, ya sean productos finales,
130
________________________________________________________ Modelo de Productos. Aplicaciones
semielaborados o materias primas. Por esto, cualquier producto que se elija de la estructura
presentada en la Figura II.7 permite ejemplificar los conceptos propuestos. En particular, se
seleccionaron 39 caramelos rellenos frutales, de dos marcas diferentes (KIM y ROC), en dos
tipos (bolsín y varita) y en los siguientes sabores: pera, frutilla, pomelo, lima, cereza y
durazno.
Después de efectuar un análisis de las características de estos productos y dado que
se encontró una gran similitud en sus estructuras, se decidió definir una única familia que los
agrupe, CarameloFrutalEnv. La Figura IV.1 presenta la jerarquía de abstracción encabezada
por dicha familia. En el segundo nivel se muestran los conjuntos de variantes, los cuales se
establecieron agrupando los productos en base a la marca y el tipo de caramelo. Quedaron
así definidos nueve conjuntos de variantes, cuyas marcas y tipos se encuentran
especificados en la Tabla IV.1.
Familia
Conjunto de Variantes
Producto
Figura IV.1. Jerarquía de abstracción de la familia CarameloFrutalEnv
Cada uno de estos conjuntos de variantes tiene como miembros a los caramelos de
una marca y un tipo en sus distintos sabores frutales. En la Figura IV.1 se muestran los
miembros de dos de estos conjuntos de variantes: BolsínFrutalROC y VaritaKIM, los cuales
corresponden a caramelos en los siguientes sabores: cereza, frutilla, pera, pomelo y lima en
el primer caso y a caramelos de pera, frutilla, pomelo, lima y durazno en el segundo. Los
otros conjuntos de variantes tienen como miembros también a caramelos cuyos sabores
coinciden con alguno de estos dos grupos. En particular, los de tipo varita coinciden con el
segundo, y el resto de los caramelos con el primer grupo de sabores.
131
________________________________________________________ Modelo de Productos. Aplicaciones
Tabla IV.1. Conjuntos de variantes de CarameloFrutalEnv
Conjunto de
Variantes
Marca
Tipo
Caramelo
Productos miembros
BolsínFrutalKIM
KIM
Bolsín
SE511710 - PeraKIM5GREnv
SE511711 - PomeloKIM5GREnv
SE511712 - LimaKIM5GREnv
SE511714 - FrutillaKIM5GREnv
SE511713 - CerezaKIM5GREnv
BolsínFrutalROC
ROC
Bolsín
SE511605 - BolsínFrutilla5GREnv
SE511606 - BolsínPera5GREnv
SE511607- BolsínPomelo5GREnv
SE511609- BolsínLima5GREnv
SE511610- BolsínCereza5GREnv
FrutalZOro
ROC
BolsínZ
FrutalOKOro
ROC
BolsínOK
VaritaKIM
KIM
Varita
SE512374 - BolsínFrutillaPopEnv
SE508249 - BolsínFrutillaOroZEnv
SE508671 - BolsínFrutillaClasicEnv
SE514191 - BolsínOKFrutillaOroEnv
SE508207 - VaritaKIMPeraEnv
SE508219- VaritaKIMFrutillaEnv
SE508246- VaritaKIMDuraznoEnv
SE508247- VaritaKIMPomeloEnv
SE508253- VaritaKIMLimaEnv
VaritaROC
ROC
Varita
SE508209 - VaritaROCDuraznoEnv
SE508225 - VaritaROCLimaEnv
SE508241 - VaritaROCPomeloEnv
SE508243 - VaritaROCFrutillaEnv
SE508245 - VaritaROCPeraEnv
BolsínFrutalZ
ROC
BolsínZ
SE508482 - BolsínFrutillaZEnv
SE508588 - BolsínPeraZEnv
SE508589 - BolsínPomeloZ4GrEnv
SE508799 - BolsínLimaZ4GrEnv
SE508800 - BolsínCereza4GrEnv
BolsínFrutalOK
ROC
BolsínOK
SE413937 - BolsínOKCereza5GrEnv
SE413940 - BolsínOKLima5GrEnv
SE413942 - BolsínOKPomelo5GrEnv
SE413944 - BolsínOKPera5GrEnv
132
________________________________________________________ Modelo de Productos. Aplicaciones
SE413946 - BolsínOKFrutilla5GrEnv
FrutalOro
ROC
Bolsín
SE511710 - BolsínOroPeraROCEnv
SE511711 - BolsínOroPomeloROCEnv
SE511712 - BolsínOroLimaROCEnv
SE511713 - BolsínOroCerezaROCEnv
SE511714 – BolsínOroFrutillaROCEnv
Un criterio similar se utilizó para la definición de la jerarquía de abstracción que
organiza a los papeles de envoltorio. Como se presentó en las Tablas II.6 a II.9 y en la
Figura II.9 del Capítulo II, estos papeles constituyen uno de los componentes de la
estructura de los caramelos envueltos. Cada uno de estos últimos tiene un papel envoltorio
diferente. En consecuencia, se identificaron 39 instancias en el nivel más bajo de la
jerarquía (Producto). La raíz de la misma es la familia PapelEnvoltorio y los conjuntos de
variantes se definen en coincidencia con los especificados para los caramelos envueltos. La
Figura IV.2 muestra esta jerarquía.
Con el objetivo de poder vincular los productos presentados en el Capítulo II con las
instancias definidas en este capítulo, se decidió mantener, para la denominación de las
entidades del nivel más concreto de la jerarquía, los códigos que poseen los productos
actualmente.
Familia
Conjunto de Variantes
Producto
Figura IV.2. Jerarquía de abstracción de tipo FamiliaS correspondiente a
PapelEnvoltorio
Los otros componentes de la estructura de un caramelo envuelto, como se aprecia
en las tablas ya mencionadas del Capítulo II, son el caramelo sin envoltorio y el papel
133
________________________________________________________ Modelo de Productos. Aplicaciones
separador (excepto para los caramelos tipo varita). Las jerarquías de abstracción
relacionadas con estos dos tipos de componentes se muestran en las Figuras IV.3 y IV.4,
respectivamente.
En la Figura IV.3 puede observarse la jerarquía cuya raíz es la familia compuesta
(FamiliaC) denominada CarameloFrutalDes. Dicha familia posee menos conjuntos de
variantes miembros en relación a los conjuntos de variantes correspondientes a los
caramelos envueltos. Esto se debe a que varios de los conjuntos de variantes mostrados en
la Figura IV.1 utilizan el mismo caramelo desenvuelto en su estructura. En la jerarquía de la
Figura IV.3 existen sólo cuatro conjuntos de variantes, a saber: OvaloFrutal, FrutalOK,
FrutalZ y VaritaKIM. Esta figura sólo presenta los productos miembros del primero y último
conjunto.
Familia
Conjunto de Variantes
Producto
Figura IV.3. Jerarquía de abstracción de tipo FamiliaC correspondiente a
CarameloFrutalDes
Aún más pequeña es la jerarquía de abstracción de los papeles separadores, ya que
los caramelos tipo varita no los llevan en su estructura y todos los otros caramelos utilizan
sólo tres papeles separadores diferentes. Esto conduce a la jerarquía que se presenta en la
Figura IV.4, en la que se presentan tres conjuntos de variantes que son miembros de la
familia PapelSeparador, a saber PapelSepROC1, PapelSepROC2 y PapelSepOro. Cada
uno de ellos posee un único producto miembro: ME908441, ME910113 y ME910124,
respectivamente.
134
________________________________________________________ Modelo de Productos. Aplicaciones
Familia
Conjunto de Variantes
Producto
Figura IV.4. Jerarquía de abstracción del tipo FamiliaS correspondiente a
PapelSeparador
IV.2.1. Especificación y gestión de productos definidos a nivel de Familia
Habiendo presentado las jerarquías de abstracción que intervendrán en la jerarquía
estructural de la familia CarameloFrutalEnv, se procederá a exponer en mayor detalle cómo
se aplican los conceptos propuestos, en el modelo de productos, en la definición de dicha
familia. En la Especificación IV.1 y en la Figura IV.5 se ilustra la definición de la familia
compuesta
(FamiliaC)
denominada
CarameloFrutalEnv
y
su
única
estructura
CarameloFrutalEnvSTR. Se trata de una estructura de composición (EC), conformada por
tres relaciones identificadas como R03, R04 y R05, las cuales unen dicha estructura con las
familias PapelEnvoltorio, CarameloFrutalDes y PapelSeparador, respectivamente.
Individual CarameloFrutalEnv in FamiliaC with
attribute,estructuraDe
estructuraDe : CarameloFrutlEnvSTR
end
Individual CarameloFrutlEnvSTR in EstructuraC with
attribute,conformadoPor
conformadoPor1 : R03;
conformadoPor2 : R04;
conformadoPor3 : R05
end
Especificación IV.1. Definición de la familia denominada CarameloFrutalEnv y
de su correspondiente estructura
135
________________________________________________________ Modelo de Productos. Aplicaciones
Figura IV.5 Definición de la familia CarameloFrutalEnv
Dado que la estructura en cuestión es de composición, las relaciones que la
conforman son de composición. La vista RelacionesenSTR recupera la información a partir
de las instancias de las clases Relación y ValorRestringido para presentar la información
correspondiente a cada una de las relaciones que participan en la estructura de la familia
CarameloFrutalEnv. Dicha vista, que se presenta en la Especificación IV.2, permite mostrar
los
atributos
de
las
instancias
de
RelaciónC
que
conforman
la
estructura
CarameloFrutalEnvSTR; y para cada una de ellas, presenta de manera anidada, las
propiedades del atributo quantityPer.
Los resultados de aplicar la vista RelacionesenSTR se presentan en la
Especificación IV.3, en la cual se observa que la relación R03 vincula la estructura llamada
CarameloFrutalEnvSTR con la familia componente PapelEnvoltorio, con una cantidad de
composición (atributo valor de la propiedad quantityPer) de 30.87 GR. En caso que
posteriormente exista algún cambio indicado por alguno de los conjuntos de variantes que
se derivan de esta estructura, dicho cambio sólo podrá modificar ese valor, manteniéndose
entre los 10.0 y los 50.0 gramos, según lo indicado por los atributos min y max. La relación
R03 se trata de una relación de tipo obligatoria (tipoRelacion) y no podrá ser removida de la
estructura por ningún cambio.
Por otro lado, la relación R04 también es de tipo obligatoria y tiene como parte a la
familia CarameloFrutalDes, la cual participa en la estructura con una cantidad de 930.233
GR y este valor sólo podrá variar (en caso de que se apliquen cambios a la relación) entre
los 900.0 y 1000.0 gramos.
Individual RelacionesenSTR in View isA Relacion with
attribute,inherited_attribute
parte : Familia;
136
________________________________________________________ Modelo de Productos. Aplicaciones
tipoRelacion : TipoRelacion
retrieved_attribute,partof
quantityPer:ValorRestringido with
inherited_attribute
valor:Real;
udeM:Unidad;
min:Real;
max:Real
end
constraint
r:$ (CarameloFrutlEnvSTR conformadoPor this) $
end
Especificación IV.2. Definición de la Vista denominada RelacionesenSTR
R03 in RelacionesenSTR
with
quantityPer
quantityPer:30_87GR
with
valor
valor : 30.87
udeM
udeM : GR
min
min : 10.0
max
max : 50.0
end
parte
parte:PapelEnvoltorio
tipoRelacion
tipoRelacion:obligatoria
end
R04 in RelacionesenSTR
with
quantityPer
quantityPer:930_233GR
with
valor
valor : 930.233
udeM
udeM : GR
min
min : 900.0
max
max : 1000.0
end
parte
parte:CarameloFrutalDes
tipoRelacion
ipoRelacion:obligatoria
end
R05 in RelacionesenSTR
with
quantityPer
quantityPer:33GR with
valor
valor : 33.0
udeM
udeM : GR
min
min : 10.0
max
max : 50.0
end
parte
parte:PapelSeparador
tipoRelacion
tipoRelacion: optativa
end
Especificación IV.3. Relaciones que conforman la estructura CarameloFrutalEnvSTR
Finalmente, la relación R05 une a la estructura CarameloFrutalEnvSTR con 33.0 GR
de la familia PapelSeparador. Tiene como límites mínimo y máximo los valores 10.0 y 50.0,
respectivamente. Se trata de una relación de tipo opcional, y por lo tanto podrá ser eliminada
de la estructura por cambios establecidos por algún conjunto de variantes que sea miembro
de CarameloFrutalEnv. Recordando lo expuesto en el Capítulo II sobre este caso de estudio,
existen caramelos que no llevan papel separador. Por ello, para poder derivar la estructura
particular de este tipo de caramelos se debe permitir suprimir el componente
PapelSeparador de la estructura base de la familia (CarameloFrutalEnvSTR), a la que estos
caramelos pertenecen.
La Figura IV.6 presenta todas las familias que directa o indirectamente participan en
la estructura de la familia CarameloFrutalEnv. Allí se puede observar un árbol multinivel que
137
________________________________________________________ Modelo de Productos. Aplicaciones
muestra los componentes directos (aquéllos que son parte de las relaciones presentadas) y,
de manera recursiva, los componentes directos de éstos.
Figura IV.6. Árbol de composición de la familia CarameloFrutalEnv
Por su parte, la Figura IV.7, presenta la ventana “Telos Editor” luego de la ejecución
de la consulta FamiliaDerivadas (Especificación III.16). El resultado de la misma es nil, es
decir que no existen en la base de datos instancias que cumplan las restricciones impuestas
por dicha consulta. Esto indica la inexistencia de familias de tipo derivado (que se obtienen
de estructuras de descomposición). Por lo tanto, los requerimientos directos coincidirán en
todos los casos con los valores de los atributos quantityPer de las relaciones que conforman
las estructuras de cada una de las familias definidas.
138
________________________________________________________ Modelo de Productos. Aplicaciones
Figura IV.7. Resultado de la consulta FamiliaDerivada (Especificación III.16)
En la Especificación IV.4 se aprecia el resultado de la vista RequerimientosFamilia
(Especificación III.22) para la familia CarameloFrutalEnv. Puede observarse en dicha
especificación, que como valor del atributo requerimientos se infirió la instancia
CarameloFrutalEnvSTR. Para esta estructura se dedujo cuáles son las relaciones que se
requieren (atributo unreq de la vista) para obtenerla, a saber: R03, R04 y R05. Además, para
cada una de estas relaciones se presentan los valores de sus atributos. Los nombres de las
instancias de interés fueron resaltados con negritas para facilitar la interpretación de los
resultados de la vista.
Es importante notar que, a diferencia de los atributos utilizados en la vista
RelacionesenSTR, presentada anteriormente en este capítulo, los atributos involucrados en
la vista RequerimientosFamilia, así como de las vistas que se encuentran anidadas dentro
de ésta, son del tipo computed_attribute. Los valores que una vista recupera para estos
atributos son inferidos mediante reglas que se definen en la propia vista. En la ejecución de
una vista es posible identificar aquellos atributos que son del tipo mencionado porque
aparecen etiquetados como “COMPUTED_nombreAtributo_id_nro”. Es así que, en la
Especificación IV.4 las etiquetas COMPUTED_unreq_id_2498, COMPUTED_unreq_id_2501
y COMPUTED_unreq_id_2504, identifican los valores inferidos por la vista para el atributo
unreq y representan las relaciones R03, R04 y R05, respectivamente. Éstas forman parte de
la estructura CarameloFrutalEnvSTR, la cual es el valor inferido, por medio de la vista, para
el atributo requerimientos. Para cada una de las relaciones incluidas en la vista se presenta
el atributo cantReq, de tipo “computed”, cuyos valores representan las cantidades de
composición que corresponden a cada relación, 30_87GR, 930_233GR y 33GR,
respectivamente.
139
________________________________________________________ Modelo de Productos. Aplicaciones
CarameloFrutalEnv in RequerimientosFamilia with
requerimientos
COMPUTED_requerimientos_id_2494:CarameloFrutalEnvSTR[CarameloFrutalEnv/this_par]
with
unReq
COMPUTED_unReq_id_2498 : R03 with
cantReq
COMPUTED_cantReq_id_2510 : 30_87GR
requerimiento
COMPUTED_requerimiento_id_2422 : PapelEnvoltorio
end ;
COMPUTED_unReq_id_2501 : R04 with
cantReq
COMPUTED_cantReq_id_2518 : 930_233GR
requerimiento
COMPUTED_requerimiento_id_2468 : CarameloFrutalDes
end ;
COMPUTED_unReq_id_2504 : R05 with
cantReq
COMPUTED_cantReq_id_2526 : 33GR
requerimiento
COMPUTED_requerimiento_id_2424 : PapelSeparador
end
end
end
Especificación IV.4. Requerimientos de la familia CarameloFrutalEnv
IV.2.2. Especificación y gestión de conjuntos de variantes
Los conjuntos de variantes compuestas de la familia CarameloFrutalEnv,
presentados en la Figura IV.1 se derivan todos de la única estructura que posee esta familia.
Algunos de ellos, además, requieren que esa estructura sea modificada en este nivel de
abstracción intermedio. Como ejemplo de estos conjuntos de variantes, la Figura IV.8
presenta BolsínFrutalROC y VaritaKIM. En el primer caso, la estructura no es modificada,
mientras que para el segundo conjunto se aplican tres cambios identificados como ElR05,
Ca2R03 y Ca2R04, los cuales son agrupados por la modificación denominada
modVaritaKIM.
La Especificación IV.5 presenta la definición en el lenguaje O-Telos del producto
genérico VaritaKIM. Allí se indica que dicho conjunto de variantes es miembro de la familia
CarameloFrutalEnv y se deriva de la estructura CarameloFrutalEnvSTR (como también
puede verse en la Figura IV.8). Asimismo, se puede observar que se aplica la modificación
modVaritaKIM a la estructura de la que este conjunto de variantes se deriva y que tiene dos
instancias asociadas al atributo preselecciona: CarVaritaFrutal y PreselVaritaKIM.
140
________________________________________________________ Modelo de Productos. Aplicaciones
Figura IV.8. Conjuntos de variantes VaritaKIM y BolsínFrutalROC
Individual VaritaKIM in ConjuntodeVariantesC with
attribute,descripcion
descripcion : "Varita Frutal KIM"
attribute,miembroDe
miembroDe : CarameloFrutalEnv
attribute,derivaDe
derivaDe : CarameloFrutalEnvSTR
attribute,modificacionAplicada
modificacionAplicada : modVaritaKIM
attribute,preselecciona
preselecciona1 : CarVaritaFrutal;
preselecciona2 : PreselVaritaKIM
end
Especificación IV.5. Definición del conjunto de variantes compuestas VaritaKIM
La Especificación IV.6 muestra la definición de la instancia modVaritaKIM, la cual
define los cambios que se aplican a la estructura CarameloFrutalEnvSTR, a saber: Ca2R03,
Ca2R04 y ElR05.
En la Figura IV.8 se presentan las relaciones afectadas por los cambios
mencionados y los valores de los atributos parte y quantityPer, que indican cuál es la familia
que forma parte de la estructura y en qué cantidad participa. En particular, se observan las
relaciones R03, R04 y R05 que se asocian con las familias PapelEnvoltorio,
CarameloFrutalDes y PapelSeparador, respectivamente, con las siguientes cantidades de
141
________________________________________________________ Modelo de Productos. Aplicaciones
composición: 30.87 GR, 930.233 GR y 33 GR. Por otra parte, la figura revela que los
cambios parciales Ca2R03 y Ca2R04 indican la modificación de las relaciones
correspondientes al CarameloFrutalDes (R04) y al PapelEnvoltorio (R03), respectivamente.
Por su parte, el tercer cambio aplicado, ElR05, indica la eliminación del PapelSeparador de
la estructura. Dichos cambios son introducidos en la Especificación IV.7.
Individual modVaritaKIM in Modificacion with
attribute,cambioAplicado
cambioAplicado : Ca2R03;
cambioAplicado2 : Ca2R04;
cambioAplicado3 : ElR05
end
Especificación IV.6. Cambios asociados a la modificación modVaritaKIM
Individual Ca2R03 in CambioQP with
attribute,relacionModificada
relacionModificada : R03
attribute,newQP
newQP : 42GR
end
Individual 42GR in ValorUnidad with
attribute,valor
valor : 42.0
attribute,udeM
udeM : GR
end
Individual ElR05 in Eliminacion with
attribute,relacionModificada
relacionModificada : R05
end
Individual Ca2R04 in CambioQP with
attribute,relacionModificada
relacionModificada : R04
attribute,newQP
newQP : 958GR
end
Individual 958GR in ValorUnidad with
attribute,valor
valor : 958.0
attribute,udeM
udeM : GR
end
Especificación IV.7. Definición de los cambios Ca2R03, Ca2R04 y ElR05
Los cambios en el atributo quantityPer de las relaciones R03 y R04 están indicados
por Ca2R03 y Ca2R04, respectivamente. Ambos, se vinculan con instancias de la clase
ValorUnidad que representan los nuevos valores del atributo quantityPer de las relaciones
modificadas. Como lo señala la Especificación IV.7, el cambio Ca2R03 es una instancia de
la clase CambioC que modifica la relación R03, según lo indica el valor del atributo
relacionModificada. En particular, altera el atributo quantityPer de dicha relación mediante el
valor indicado por la propiedad newQP del cambio en cuestión. De manera similar, en dicha
especificación, puede observarse que el cambio Ca2R04 modifica la relación R04, indicando
como nuevo valor del atributo quantityPer, 958GR y, finalmente, que ElR05 es una instancia
de Eliminación que especifica que la relación R05 (relacionModificada) debe ser eliminada
de la estructura.
La Figura IV.9 muestra el resultado de la vista denominada estructuraVaritaKIM, la
cual es una especialización de la vista arbolEstructuraCV presentada en la Especificación
142
________________________________________________________ Modelo de Productos. Aplicaciones
III.42, que restringe los resultados de la vista para obtener sólo la estructura que
corresponde al conjunto de variantes VaritaKIM. En la misma se observan las dos relaciones
que no han sido eliminadas (R03 y R04), con los nuevos valores para los correspondientes
atributos quantityPer, indicados por el atributo newQP.
Figura IV.9. Resultado de la vista estructuraVaritaKIM
En el diagrama de la Figura IV.8 se incluye al conjunto de variantes denominado
BolsínFrutalROC, cuya definición se muestra en la Especificación IV.8. Este conjunto se
deriva de la estructura CarameloFrutalEnvSTR y, como ya se adelantara, no es necesario
aplicar modificaciones a dicha estructura para especificar este conjunto de variantes.
Finalmente, también pueden apreciarse los tres valores que adopta el atributo
preselecciona.
Individual BolsinFrutalROC in ConjuntodeVariantesC with
attribute,miembroDe
miembroDe : CarameloFrutalEnv
attribute,derivaDe
derivaDe : CarameloFrutlEnvSTR
attribute,preselecciona
preselecciona : PapelEnvRoc;
preselecciona2 : PapelSepRoc;
preselecciona3 : CarFrutal
end
Especificación IV.8. Definición de BolsínFrutalROC
La Figura IV.10 presenta el resultado de la vista estructuraBolsínROC que, al igual
que la vista presentada para VaritaKIM, es una especialización de arbolEstructuraCV
143
________________________________________________________ Modelo de Productos. Aplicaciones
(Especificación III.42), que permite ver sólo la estructura del conjunto de variantes
BolsínROC. Pueden observarse las relaciones que participan en la estructura de dicho
conjunto, indicándose las familias componentes y sus cantidades de composición.
Figura IV.10. Resultado de la vista estructuraBolsínROC
Las familias que son componentes directos de CarameloFrutalEnv y aquéllas que
persisten en la estructura de dicha familia, luego de aplicar las modificaciones indicadas por
los conjuntos de variantes recientemente introducidos, se muestran en la Figura IV.11. Las
familias que permanecen en la estructura vinculada a una variante, luego de aplicar las
correspondientes modificaciones, se infieren como valor del atributo familiaComponente de
la clase ConjuntodeVariantesC. A partir de la Figura IV.11 es posible notar que mientras que
para VaritaKIM sólo se mantienen dos componentes (PapelEnvoltorio y CarameloFrutalDes),
para BolsínFrutalROC, sus tres componentes coinciden completamente con los de la familia
de la que es miembro dicho conjunto de variantes.
Otro tipo de variación que puede ocurrir a nivel de un conjunto de variantes
compuestas, como se indicó en el Capítulo III, corresponde a la preselección de conjuntos
de variantes para los componentes de la estructura de dicho conjunto.
Las preselecciones realizadas a nivel de los dos conjuntos de variantes antes
introducidos, se muestran en las Especificaciones IV.5 y IV.8, donde se definen VaritaKIM y
BolsínFrutalROC, respectivamente.
144
________________________________________________________ Modelo de Productos. Aplicaciones
Figura IV.11. Familias componentes de BolsínFrutalROC y VaritaKIM
En
la
Especificación
IV.5,
el
atributo
preselecciona
posee
dos
valores:
CarVaritaFrutal y PreselEnvVaritaKIM, que representan, respectivamente, la selección del
caramelo desenvuelto y del papel envoltorio, que corresponden a un caramelo envuelto
frutal de marca KIM. En particular, se selecciona el conjunto de variantes compuestas
denominado VaritaFrutal para el caramelo desenvuelto y el conjunto de variantes simples
identificado como EnvVaritaKIM para el papel envoltorio, según lo muestra la Especificación
IV.9.
Individual CarVaritaFrutal in Preseleccion with
ConjuntoSeleccionado ConjuntoSeleccionado: VaritaFrutal
end
Individual PreselVaritaKIM in Preseleccion with
ConjuntoSeleccionado ConjuntoSeleccionado: EnvVaritaKIM
end
Especificación IV.9. Preselecciones definidas para el conjunto de variantes
VaritaKIM
Por otra parte, como lo indica la Especificación IV.10, se asocian al conjunto de
variantes BolsínFrutalROC tres preselecciones, a saber: CarFrutal, para el caramelo
desenvuelto, PapeEnvROC para el papel envoltorio y PapelSepROC para el papel
separador.
En la Figura IV.12 se muestran cuáles son los conjuntos seleccionados a nivel de
cada uno de los conjuntos de variantes presentados, BolsínFrutalROC y VaritaKIM. Es
posible observar en dicha figura que este último sólo posee preselecciones para el caramelo
desenvuelto (CarVaritaFrutal) y para el papel envoltorio (PreselVaritaKIM) ya que, como se
mencionó antes, este conjunto de variantes elimina el papel separador de la estructura. En
cambio, el conjunto de variantes BolsínFrutalROC se vincula con la preselección de
145
________________________________________________________ Modelo de Productos. Aplicaciones
conjuntos de variantes para el caramelo desenvuelto (CarFrutal), el papel envoltorio
(PapelEnvROC) y el papel separador (PapelSepROC).
Individual PapelEnvRoc in Preseleccion with
ConjuntoSeleccionado ConjuntoSeleccionado: EnvBolsinFrutalROC
end
Individual PapelSepRoc in Preseleccion with
ConjuntoSeleccionado ConjuntoSeleccionado: PapelSepROC1
end
Individual CarFrutal in Preseleccion with
ConjuntoSeleccionado ConjuntoSeleccionado: OvaloFrutal
end
Especificación IV.10. Preselecciones definidas para el conjunto de variantes
BolsinFrutalROC
Figura IV.12. Ejemplo de preselección de conjuntos de variantes
Sin bien, en los casos ya presentados, se selecciona un único conjunto de variantes
para cada uno de los componentes, esto no necesariamente debe ser siempre así. De
hecho, es posible preseleccionar más de un conjunto de variantes para una determinada
familia componente.
La figura IV.12 introduce también las familias de las que son miembros los distintos
conjuntos preseleccionados. En particular, se muestra a PapelSepRoc1 como miembro de la
familia PapelSeparador, a EnvBolsínFrutalROC y a EnvVaritaKIM como miembros de
PapelEnvoltorio así como a OvaloFrutal y VaritaFruta, identificadas como miembros de la
FamiliaC, denominada CarameloFrutalDes. Además, para las preselecciones PapelSepRoc
y PapelEnvRoc, se presenta el atributo componenteAfectado. El arco que representa este
146
________________________________________________________ Modelo de Productos. Aplicaciones
atributo aparece con línea punteada, indicando que dicho atributo es calculado a través de
alguna regla de inferencia. En este caso, la regla en cuestión es componenteAfectadoRule,
que se define en la clase Preselección y que fuera introducida en la Especificación III.35.
A continuación se presenta la manera en que afectan las preselecciones definidas
para el conjunto de variantes compuestas BolsínFrutalROC, a los miembros de las familias
componentes de la estructura base de dicho conjunto de variantes. La Figura IV.13 muestra
los componentes directos (atributo componenteDirecto definido en la Especificación III.14)
de la estructura correspondiente a la familia CarameloFrutalEnv, indicando para cada uno de
ellos, los conjuntos de variantes que son miembros de éstos. En particular, se puede
observar que:
la familia simple PapelEnvoltorio, tiene como miembros a los conjuntos de
variantes simples EnvVaritaKIM, EnvBolsínFrutalROC, EnvBolsínFrutalKIM,
EnvVaritaROC, entre otros;
la familia simple PapelSeparador tiene como miembros a los conjuntos de
variantes simples PapelSepROC1, PapelSepROC2; PapelSepOro; y
la familia compuesta CarameloFrutalDes posee cuatro conjuntos de variantes
compuestas: OvaloFrutal, VaritaFrutal, FrutalK y FrutalS.
Figura IV.13. Aplicación de las preselecciones de BolsínFrutalROC
En la Figura IV.13 se representa que el conjunto de variantes BolsínFrutalROC,
infiere como componentes directos solamente a algunos de los conjuntos de variantes
miembros de los componentes directos de la estructura de la cual se deriva
BolsínFrutalROC. Esto puede observarse también en la Especificación IV.11, donde se
exponen los resultados de la vista PreseleccionesRealizadas, que se encuentra definida en
la Especificación A.15 del Apéndice A, para el conjunto de variantes BolsínFrutalROC.
147
________________________________________________________ Modelo de Productos. Aplicaciones
Dicha especificación muestra cómo al aplicar las preselecciones definidas por las
instancias de la clase Preselección, CarOvaloFrutal, SelEnvBolsínROC y SelSepBolsínROC,
asociadas al conjunto de variantes compuestas BolsínFrutalROC, los miembros de las
distintas familias componentes de la estructura, quedan restringidos. Esta limitación implica
que, al momento de derivar una estructura particular para un miembro del conjunto de
variantes BolsínFrutalROC, deberá seleccionarse:
un papel envoltorio que sea miembro del conjunto de variantes simples
EnvBolsínFrutalROC;
un
papel
separador,
miembro
del
conjunto
de
variantes
simples
PapelSepROC; y
un caramelo desenvuelto, miembro del conjunto de variantes compuestas
OvaloFrutal.
BolsinFrutalROC in PreseleccionesRealizadas with
unReq
COMPUTED_unReq_id_3202 : R03[BolsinFrutalROC/this_par] with parte
parte : PapelEnvoltorio[BolsinFrutalROC/this_par] with miembros
COMPUTED_miembros_id_4437:EnvBolsinFrutalROC[BolsinFrutalROC/this_par]
end
end
end ;
COMPUTED_unReq_id_3205 : R04[BolsinFrutalROC/this_par] with parte
parte : CarameloFrutalDes[BolsinFrutalROC/this_par] with
miembros
COMPUTED_miembros_id_4465 : OvaloFrutal[BolsinFrutalROC/this_par]
end
end
end ;
COMPUTED_unReq_id_3208 : R05[BolsinFrutalROC/this_par] with parte
parte : PapelSeparador[BolsinFrutalROC/this_par] with miembros
COMPUTED_miembros_id_4419 : PapelSepROC1[BolsinFrutalROC/this_par]
end
end
end
end
Especificación IV.11. Preselecciones definidas en BolsínFrutalROC
Por otra parte, con una simple modificación a la restricción de la vista
PreseleccionesRealizadas es posible inferir los conjuntos de variantes que pueden
seleccionarse para los componentes de VaritaKIM. Este resultado se presenta en la
Especificación IV.12. Es importante mencionar que para este conjunto, sólo se realizan
preselecciones para los componentes que quedan en la estructura después de aplicar los
cambios indicados por la modificación especificada en VaritaKIM.
148
________________________________________________________ Modelo de Productos. Aplicaciones
VaritaKIM in PreseleccionesRealizadas with
unReq
COMPUTED_unReq_id_3202 : R03[VaritaKIM/this_par] with parte
parte : PapelEnvoltorio[VaritaKIM/this_par] with miembros
COMPUTED_miembros_id_4433 : EnvVaritaKIM[VaritaKIM/this_par] end
end
end ;
COMPUTED_unReq_id_3205 : R04[VaritaKIM/this_par] with parte
parte : CarameloFrutalDes[VaritaKIM/this_par] with miembros
COMPUTED_miembros_id_4508 : VaritaFrutal[VaritaKIM/this_par] end
end
end
end
Especificación IV.12. Preselecciones definidas en VaritaKIM
IV.2.3. Especificación y gestión de productos
La Figura IV.1 muestra, parcialmente, la jerarquía de abstracción de la FamiliaC
denominada CarameloFrutalEnv. En el nivel más bajo de dicha jerarquía aparecen los
siguientes productos compuestos, que corresponden a productos con existencia física.
(VaritaKIMPeraEnv),
SE508246
(VaritaKIMFrutillaEnv),
SE508247
SE508207
SE508219
(VaritaKIMDamascoEnv),
(VaritaKIMPomeloEnv)
y
SE508253 (VaritaKIMLimaEnv), que son miembros del conjunto de variantes
denominado VaritaKIM
SE511710 (PeraKIM5GREnv), SE511713 (CerezaKIM5GREnv), SE511714
(FrutillaKIM5GREnv),
(LimaKIM5GREnv),
SE511711
que
son
(PomeloKIM5GREnv)
miembros
del
conjunto
y
de
SE511712
variantes
BolsínFrutalKIM
Por su parte, la Figura IV.2 muestra ejemplos de productos simples, dentro de la
jerarquía de abstracción de la FamiliaS denominada PapelEnvoltorio. Es posible observar en
dicha figura, los siguientes productos simples:
ME308398
(EnvVaritaKIMPomelo),
ME308409
(EnvVaritaKIMLima),
ME308386 (EnvVaritaKIMFrutilla), ME308351 (EnvVaritaKIMDamasco) y
ME308340 (EnvVaritaKIMPera), que son miembros del conjunto de variantes
EnvVaritaKIM
ME113310
(EnvBolsínROCLima),
ME113309
(EnvBolsínROCPomelo),
ME113307 (EnvBolsínROCFrutilla), ME113311 (EnvBolsínROCCereza) y
ME113308 (EnvBolsínROCPera), que son miembros del conjunto de
variantes EnvBolsínFrutalKIM.
149
________________________________________________________ Modelo de Productos. Aplicaciones
De todos los productos mencionados, se tomará SE508219 (VaritaKIMFrutillaEnv),
con el fin de mostrar cómo se aplica el modelo propuesto en la definición de dicho producto,
la cual se muestra en la Especificación IV.13. Puede observarse que el producto en cuestión
es miembro del conjunto de variantes referido como VaritaKIM. Éste, como se mostró en las
Figuras IV.9 y IV.10, tiene en su estructura dos componentes, el papel separador y el
caramelo desenvuelto. Para cada uno de ellos, al definir SE508219 (VaritaKIMFrutillaEnv)
es necesario seleccionar un producto miembro. Estas selecciones se registran en los
atributos selecciona1 y selecciona2, cuyos valores se definen en la Especificación IV.13.
Individual SE508219 in ProductoC with
descripcion descripcion: "Varita KIM Frutilla*Env"
miembroDe miembroDe: VaritaKIM
seleccionar
selecciona1: selCarVarita;
selecciona2: selEnvVaritaKIM
end
Individual selCarVarita in Seleccion with
productoElegido productoElegido:SE408193
end
Individual selEnvVaritaKIM in Seleccion with
productoElegido productoElegido:ME308386
end
Especificación IV.13. Definición de la instancia de ProductoC denominada
SE508219 (VaritaKIMFrutillaEnv)
A continuación se presenta la Figura IV.14, cuyo objetivo es mostrar cómo los
productos que son seleccionados por un determinado ProductoC son miembros de algún
conjunto
de
variantes,
que
ha
sido
previamente
preseleccionado
por
el
ConjuntodeVariantesC del que dicho producto es miembro. En la figura, puede observarse
que SE508219 (VaritaKIMFrutillaEnv), es miembro del conjunto de variantes compuestas
VaritaKIM, el cual, a su vez, es miembro de la FamiliaC denominada CarameloFrutalEnv
(Figura
IV.12).
Además,
VaritaKIM
incluye
las
preselecciones
CarVaritaFrutal
y
PreselEnvVaritaKIM, para sus dos familias componentes, las cuales se muestran en dicha
figura. La primera indica que debe seleccionarse un miembro del conjunto de variantes
VaritaFrutal (perteneciente a la familia CarameloFrutalDes, según lo indica la Figura IV.13).
En tanto, la segunda preselección, restringe al conjunto de variantes denominado
EnvVaritaKIM, las opciones para el PapelEnvoltorio. Los productos que son miembros de
estos dos últimos conjuntos de variantes, son mostrados en la figura vinculados por la
relación miembros.
Finalmente, la Figura IV.14 presenta las selecciones hechas para el ProductoC
denominado SE508219 (VaritaKIMFrutillaEnv), indicadas allí por las relaciones etiquetadas
150
________________________________________________________ Modelo de Productos. Aplicaciones
con el rótulo selecciona. En particular se eligen, los productos SE408193 (VaritaFrutillaDes)
y ME308386 (EnvVaritaKIMFrutilla), para el caramelo desenvuelto y el papel envoltorio,
respectivamente.
Como se explicó en el capítulo previo, una forma de garantizar que las estructuras de
productos que se especifican sean correctas, es mediante la definición de restricciones entre
distintas abstracciones de productos. Algunas de las restricciones que se establecieron para
este caso de estudio se presentan a continuación en las Figuras IV.15 a IV.17.
miembros: relación inversa de miembroDe
Figura IV.14. Definición de Productos en el caso de estudio de la planta de golosinas
En la Figura IV.15 se observa una restricción que especifica que, en el nivel Familia,
un PapelEnvoltorio debe estar siempre incluido en una estructura en la que un
PapelSeparador esté presente. Sin embargo, en este caso de estudio una restricción del
mismo tipo no es válida en la dirección opuesta; es decir, cuando un PapelEnvoltorio esté
presente en una estructura no es necesario que exista obligatoriamente un PapelSeparador.
La definición en O-Telos de esta restricción se muestra en la Especificación IV.14.
Figura IV.15. Restricción de obligatoriedad que se aplica a PapelSeparador
151
________________________________________________________ Modelo de Productos. Aplicaciones
En el nivel ConjuntodeVariantes, un OvaloFrutal (el caramelo desenvuelto que se
utiliza para los caramelos BolsínFrutalROCEnv, entre otros) nunca puede estar acompañado
de un papel envoltorio EnvVaritaKIM (conjunto de variantes que agrupa los envoltorios de
caramelos tipo VaritaKIM). La definición de esta restricción se presenta en la Especificación
IV.15 y gráficamente en la Figura IV.16.
Individual rincompatible in RIncompatible end
Individual robligatoria in RObligatoria end
PapelSeparador in FamiliaS with
restringeA restringeA: PS_PE
end
Individual PS_PE in RestriccionF with
tipoRestriccion tipoRestriccion : obligatoria
restringe restringeA :PapelEnvoltorio
end
Especificación
PapelSeparador
IV.14.
Restricción
de
obligatoriedad
correspondiente
a
Figura IV.16. Definición de una restricción de incompatibilidad aplicable a OvaloFrutal
Individual OvaloFrutal with
restringeA restringeA: OF_EVK
end
Individual OF_EVK in RestriccionCV
with tipoRestriccion
tipoRestriccion : rincompatible
restringe restringe: EnvVaritaKIM
end
Especificación IV.15. Restricción de incompatibilidad en Ovalo Frutal
Finalmente, en la Figura IV.17 puede observarse que en el último nivel, el ProductoC
denominado SE508219 (VaritaKIMFrutillaEnv) debe estar acompañado por el papel
envoltorio ME308386 (EnvVaritaKIMFrutilla). La correspondiente definición se muestra en la
Especificación IV.16.
152
Individual SE508219 in ProductoC with
restringeA restringeA: CFD_PEF
end
Especificación
SE508219
IV.16.
Restricción
Individual CFD_PEF in RestriccionP with
tipoRestriccion
tipoRestriccion: obligatoria
restringe restringe: ME308386
end
de
obligatoriedad
correspondiente
a
En el Capítulo III, a partir de las especificaciones de las restricciones, se incorporaron
a las clases Familia, ConjuntodeVariantes y Producto, dos atributos que permiten inferir las
instancias del nivel correspondiente, que son incompatibles o que son obligatorias para un
determinado objeto (Especificación III.52). La Figura IV.18, presenta un ejemplo de la
consulta verIncompatibles realizada sobre la clase Familia, la cual permite identificar qué
familias son incompatibles con CarameloFrutalEnv.
Figura IV.17. Restricción de obligatoriedad en SE508219 (VaritaKIMFrutillaEnv)
Figura IV.18. Ejemplo de la consulta VerIncompatibles
153
________________________________________________________ Modelo de Productos. Aplicaciones
IV.3. APLICACIÓN DEL MODELO A PRODUCTOS DE LA INDUSTRIA FRIGORÍFICA
La aplicación del modelo propuesto al caso de estudio tomado de la industria
frigorífica se ha realizado sobre los productos intermedios que participan en la estructura de
los productos finales que se presentaron en la Tabla II.52. Los componentes de dichos
semielaborados se indican en las primeras seis filas de la tabla mencionada. Ellos son:
MP3CarneCocida, MP2CarneCocida, CZACuadrada, MP1CarneCocida, Gelatina y Sal.
Es importante aclarar, que además de la representación de estos productos, se
incorporó a este ejemplo la definición de la familia CuadrilConTapa y sus estructuras de
descomposición, debido a que estas estructuras muestra características que no pudieron ser
ejemplificadas con el caso de estudio previo.
La aplicación del modelo para la representación de los productos semielaborados
antes mencionados da lugar a la definición de dos familias, junto a sus correspondientes
conjuntos de variantes miembros (Figura IV.19). La familia SECarneCocidaPicada posee
dos estructuras, SECCocidaPicadaSTR y SECCocidaPicadaSTR2. A su vez, la familia
SECarneCocidaCongelada
presenta
también
dos
estructuras,
SECarneCocIda
CongeladaSTR y CarneCocidaCongeladaSTR2, las cuales se muestran en la Figura IV.19.
En esta figura se introdujeron también los conjuntos de variantes que son miembros de cada
una de las familias mencionadas, indicándose la estructura de la que deriva cada uno de
estos conjuntos (relación derivaDe).
Figura IV.19. Familias de productos intermedios de la industria cárnica, sus
estructuras y sus miembros
La Tabla IV.2 presenta la jerarquía de abstracción completa para las familias de
semielaborados que se muestran en la Figura IV.19. Para cada familia de carnes cocidas se
muestran los conjuntos de variantes asociados, y para cada uno de éstos, se listan los
productos concretos que ellos comprenden.
154
________________________________________________________ Modelo de Productos. Aplicaciones
Tabla IV.2. Jerarquías de abstracción correspondientes a dos familias de
carnes cocidas
Familia
Conjunto de Variantes
Producto
SE_CCCCub1
SECarneCocidaCub
SE_CCCCub2
SE_CCCCub4
SE_CCCCub3
SECarneCocidaSaz
SE_CCCCub5
SECarneCocidaCongelada
SE_CCCCub6
SECarneCocidaCubMix
SE_CCCCub7
SE_CCCReb1
SE_CCCReb2
SECarneCocidaReb
SE_CCCReb3
SE_CCCReb4
SE_FPB1
SECCPicada1
SE_FPB2
SE_FPB3
SECarneCocidaPicada
SE_FPBCva
SECCPicada2
SE_FPD2
SE_FPD1
De todos los semielaborados introducidos en esta sección, se tomará para
ejemplificar la aplicación del modelo a la familia SECarneCocidaCongelada. La
Especificación IV.17 presenta la definición de dicha familia en lenguaje O-Telos,
estableciéndose que la misma posee dos estructuras, SECarneCocIdaCongeladaSTR y
SECarneCocidaCongeladaSTR2. Estas estructuras se analizarán en los siguientes párrafos.
Individual SECarneCocidaCongelada in FamiliaC with
estructuraDe estructuraDe: SECarneCocidaCongeladaSTR;
estructuraDe2: SECarneCocidaCongeladaSTR2
end
Especificación IV.17. Definición de la familia SECarneCocidaCongelada
155
________________________________________________________ Modelo de Productos. Aplicaciones
En la Especificación IV.18 se indica que SECarneCocidaCongeladaSTR es una
estructura de composición (EstructuraC) que se conforma a partir de cuatro relaciones,
R12f, R13f, R14fa y R14fb, las cuales se esquematizan en la Figura IV.20 y se definen en la
Especificación IV.19.
Individual SECarneCocidaCongeladaSTR in EstructuraC with
conformadoPor conformadoPor: R12f;
conformadoPor2: R13f;
conformadoPor3: R14fa;
conformadoPor4: R14fb
end
Especificación IV.18. Definición de la estructura SECarneCocidaCongeladaSTR
Figura IV.20. Estructura SECarneCocidaCongeladaSTR
En la Figura IV.20 puede observarse que las familias MP2CarneCocida,
MP3CarneCocida, Sal y Gelatina, se corresponden con los valores de los atributos parte de
las relaciones mencionadas. De igual manera, 1754KG, 15KG y 12KG corresponden a los
valores de los atributos quantityPer. Cabe aclarar que se indican sólo tres instancias de la
clase ValorRestringido debido a que las relaciones R14fa y R14fb utilizan la misma
instancia. La definición formal de estas relaciones se muestra en la Especificación IV.19,
donde es posible observar que ha sido necesario recurrir a todos los tipos de relaciones
propuestas (obligatoria, optativa y selectiva).
Individual R12f in RelacionC with
parte parte: Gelatina
quantityPer quantityPer: 12KG
tipoRelacion tipoRelacion: obligatoria
end
Individual R13f in RelacionC with
parte parte: Sal
quantityPer quantityPer: 15KG
tipoRelacion tipoRelacion: optativa
end
Individual R14fa in RelacionC with
parte parte: MP3CarneCocida
quantityPer quantityPer: 1754KG
tipoRelacion tipoRelacion: selectiva
end
Individual R14fb in RelacionC with
parte parte: MP2CarneCocida
quantityPer quantityPer: 1754KG
156
________________________________________________________ Modelo de Productos. Aplicaciones
tipoRelacion tipoRelacion: selectiva
end
Especificación IV.19. Relaciones que conforman SECarneCocidaCongeladaSTR
En la Especificación IV.19 se indica que R12f es una relación obligatoria y que R13f
es optativa, siendo éstos dos tipos de relaciones ya presentados en la sección previa. Las
otras dos relaciones (R14fa y R14fb) son selectivas, lo cual implica que sólo una de ellas
debe estar presente en la estructura final. Sin tener en cuenta las modificaciones que
pueden efectuarse al momento de definir los conjuntos de variantes asociados a esta
familia, pueden derivarse al menos dos estructuras, a saber:
una compuesta de:
o
12 KG de Gelatina (R12f),
o
15 KG de Sal (R13f) y
o
1754 KG de MP3CarneCocida (R14fa);
otra conformada por
o
12 KG de Gelatina (R12f),
o
15 KG de Sal (R13f) y
o
1754 KG de MP2CarneCocida (R14fb).
La segunda estructura, denominada SECarneCocidaCongeladaSTR2 (Especificación
IV.20), incluye tres relaciones, R145f, 146f y 147f. Éstas indican que se necesitan 1202.7
KG de MP3CarneCocida, 515 KG de MP1CarneCocidaCongelada, y 12 KG de Gelatina. Por
otra parte, estas tres relaciones son de tipo obligatoria (atributo tipoRelacion). En
consecuencia, no podrán ser eliminadas de la estructura al definir algún conjunto de
variantes que se derive de SECarneCocidaCongeladaSTR2.
Individual SECarneCocidaCongeladaSTR2 in
EstructuraC with
conformadoPor conformadoPor: R145f;
conformadoPor2: R146f;
conformadoPor3: R147f
end
Individual R146f in RelacionC with
parte parte: MP1CarneCocida
quantityPer quantityPer: 515KG
tipoRelacion tipoRelacion: obligatoria
end
Individual R145f in RelacionC with
parte parte: MP3CarneCocida
quantityPer quantityPer: 1202_7KG
tipoRelacion tipoRelacion: obligatoria
end
Individual R147f in RelacionC with
parte parte: Gelatina
quantityPer quantityPer: 12KG
tipoRelacion tipoRelacion: obligatoria
end
Especificación IV.20. Definición de SECarneCocidaCongeladaSTR2
En la Figura IV.21 se presenta el resultado de la consulta InfoSECarne
CocidaCongelada, la cual muestra los valores de los atributos esEnsamblado, estructuraDe
157
________________________________________________________ Modelo de Productos. Aplicaciones
y estructuraRequerida para la familia SECarneCocidaCongelada. Los valores que
corresponden al primero y al último de estos atributos son inferidos mediante las reglas
definidas en las Especificaciones III.16 y III.23, respectivamente.
Debe notarse que los atributos estructuraDe y estructuraRequerida que aparecen en
la consulta poseen los mismos valores. Esto se debe a que se trata de una familia que se
obtiene a través de una estructura de composición (condición que se observa en el valor del
atributo esEnsamblado, que para este caso es TRUE). Esta característica implica que los
requerimientos que deduce la vista RequerimientosFamilia (Especificación III.22) para esta
familia coinciden con las relaciones de sus estructuras (Especificaciones IV.18 y IV.20).
Figura IV.21. Resultado de la consulta InfoCarneCocidaCongelada
En las dos estructuras de SECarneCocidaCongelada que se presentaron intervienen
como componentes las familias MP1CarneCocida, MP2CarneCocida y MP3CarneCocida,
los cuales representan derivados de cortes cárnicos y, por lo tanto, provienen de alguna
estructura de descomposición. Más aún, pueden provenir alternativamente de más de una
estructura como lo muestra la Especificación IV.21. En ella, se puede observar el resultado
de la vista RequerimientosFamilia (Especificación III.22) para la familia MP2CarneCocida.
La Especificación IV.21 indica que MP2CarneCocida puede obtenerse de NalgaAdentroCT,
de TapaCuadril, o de CuadrilConTapa.
La vista RequerimientosFamilias permite inferir, a partir de la información completa
del ejemplo cargada en una base ConceptBase, que para obtener la familia
MP2CarneCocida se requieren alternativamente tres familias: NalgaAdentroCT, TapaCuadril
158
________________________________________________________ Modelo de Productos. Aplicaciones
o CuadrilConTapa. Estas familias se infieren como requerimientos de MP2CarneCocida a
través de distintas relaciones, pertenecientes a estructuras de descomposición, según lo
indicado en la Tabla IV.3.
Tabla IV.3. Familias de las cuales se puede obtener MP2CarneCocida
Familia Requerida
Relación
Requerida
Estructura requerida
NalgaAdentroCT
R40f
NalgaAdentroCTSTR1
TapaCuadril
R51f
TapaCuadrilSTR2
CuadrilConTapa
R07f
CuadrilConTapaSTR3
MP2CarneCocida in RequerimientosFamilia with
requerimientos
COMPUTED_requerimientos_id_3295: NalgaAdentroCTSTR1[MP2CarneCocida/this_par] with
unReq
COMPUTED_unReq_id_3305 : R40f with
cantReq
cantReq : 1UNID
requerimiento
COMPUTED_requerimiento_id_3077 : NalgaAdentroCT
tipoRelacion
tipoRelacion : obligatoria
end
end ;
COMPUTED_requerimientos_id_3465 : TapaCuadrilSTR2[MP2CarneCocida/this_par] with
unReq
COMPUTED_unReq_id_3522 : R51f with
cantReq
cantReq : 1UNID
requerimiento
COMPUTED_requerimiento_id_3025 : TapaCuadril
tipoRelacion
tipoRelacion : obligatoria
end
end ;
COMPUTED_requerimientos_id_3645 : CuadrilConTapaSTR3[MP2CarneCocida/this_par] with
unReq
COMPUTED_unReq_id_3652 : R07f with
cantReq
cantReq : 1UNID
requerimiento
COMPUTED_requerimiento_id_3075 : CuadrilConTapa
tipoRelacion
tipoRelacion : obligatoria
end
end
end
Especificación IV.21. Resultados parciales de la vista RequerimientosFamilia
correspondientes a MP2CarneCocida
159
________________________________________________________ Modelo de Productos. Aplicaciones
En todos los casos la cantidad requerida (cantReq) es 1 unidad (1UNID). El valor de
los atributos cantReq y requerimiento se infieren por las reglas de la clase RelacionD que se
indicaron en la Especificación III.19. Como se muestra en la Especificación IV.21,
MP2CarneCocida puede ser obtenida a partir de una de las estructuras de descomposición
de la familia CuadrilConTapa (la estructura CuadrilConTapaSTR3). La definición que fuera
realizada para dicha familia se presenta en la Especificación IV.22 junto a las instancias
correspondientes a sus estructuras de descomposición, a saber: CuadrilConTapaSTR1,
CuadrilConTapaSTR2, CuadrilConTapaSTR3. Estas estructuras representan estructuras
alternativas de descomposición de la familia CuadrilConTapa.
Individual CuadrilConTapaSTR1 in EstructuraD end
Individual CuadrilConTapaSTR2 in EstructuraD end
Individual CuadrilConTapaSTR3 in EstructuraD end
Individual CuadrilConTapa in FamiliaC with
attribute,estructuraDe
estructuraDe : CuadrilConTapaSTR1;
estructuraDe2 : CuadrilConTapaSTR2;
estructuraDe3 : CuadrilConTapaSTR3
end
Especificación IV.22. Definición de la familia CuadrilConTapa y sus estructuras
El modelo propuesto permite inferir para una determinada familia cuáles son sus
estructuras alternativas. Para ello utiliza el atributo estAlternativa y la regla estAltRule
mediante la cual se deducen sus valores (Especificación III.5). La Figura IV.22 presenta el
resultado de ejecutar la consulta VerSTRalternativas. Esta consulta, al ser ejecutada
muestra, entre otros valores del mencionado atributo, los correspondientes a las estructuras
de la familia CuadrilConTapa.
160
________________________________________________________ Modelo de Productos. Aplicaciones
Figura IV.22. Ejemplo de aplicación de la consulta VerSTRalternativas
Por su parte, la Especificación IV.23 presenta la definición de CuadrilConTapaSTR3,
una de las estructuras de la familia CuadrilConTapa, la cual cuenta con cinco relaciones de
descomposición (RelacionD), identificadas como R06f, R07f, R08f, R09f y R10f. La
estructura también define como valor del atributo requiere a la instancia de ValorRestringido
denominada 1UNID. Este atributo indica que para poder obtener los derivados definidos por
las relaciones que conforman CuadrilConTapaSTR3 se necesita 1 unidad de la familia
CuadrilConTapa, a la cual pertenece dicha estructura.
Individual
Individual
Individual
Individual
Individual
R06f
R07f
R08f
R09f
R10f
in
in
in
in
in
RelacionD
RelacionD
RelacionD
RelacionD
RelacionD
end
end
end
end
end
Individual 1UNID in ValorRestringido end
CuadrilConTapaSTR3 in EstructuraD with
conformadoPor conformadoPor1: R06f;
conformadoPor2: R07f;
conformadoPor3: R08f;
conformadoPor4: R09f;
conformadoPor5: R10f
requiere requiere : 1UNID
end
Especificación IV.23. Definición de la estructura CuadrilConTapaSTR3
La definición de estas relaciones puede recuperarse a partir de la vista
VerEstructuraFlia2 que se muestra en la Especificación IV.24. En ésta se observa que
mediante la estructura CuadrilConTapaSTR3 (la cual es una de las estructuras de
descomposición de CuadrilConTapa) es posible obtener las familias CuadrilCTExportación,
MP2CarneCocida, MP1CarneCocida, Grasa y NerviosYPellejos, con factores de producción
161
________________________________________________________ Modelo de Productos. Aplicaciones
de 3.13, 0.13, 0.16, 0.62 y 0.06, respectivamente. Todas estas relaciones son del tipo
obligatoria.
CuadrilConTapaSTR3 in VerEstructuraFlia2
with
conformadoPor
COMPUTED_conformadoPor_id_3649:R06f with
cantidad
COMPUTED_cantidad_id_3669:3_13%
parte
parte : CuadrilCTExportacion
tipoRelacion
tipoRelacion : obligatoria
end ;
COMPUTED_conformadoPor_id_3652:R07f with
cantidad
COMPUTED_cantidad_id_3681:0_13%
parte
parte : MP2CarneCocida
tipoRelacion
tipoRelacion : obligatoria
end ;
COMPUTED_conformadoPor_id_3655:R08f with
cantidad
COMPUTED_cantidad_id_3693:0_16%
parte
parte : MP1CarneCocida
tipoRelacion
tipoRelacion : obligatoria
end ;
COMPUTED_conformadoPor_id_3658:R09f with
cantidad
COMPUTED_cantidad_id_3705:0_62%
parte
parte : Grasa
tipoRelacion
tipoRelacion : obligatoria
end ;
COMPUTED_conformadoPor_id_3661:R10f with
cantidad
COMPUTED_cantidad_id_3717:0_06%
parte
parte : NerviosYPellejos
tipoRelacion
tipoRelacion : obligatoria
end
end
Especificación IV.24. Resultado parcial de la vista VerEstructuraFlia2
En la Figura IV.23 se presenta el resultado de la consulta InfoCuadrilConTapa, la
cual permite rescatar información vinculada a la familia CuadrilConTapa. Pueden apreciarse
las estructuras de descomposición alternativas asociadas, así como la estructura de
descomposición (CuartoTraseroSTR) de la cual se deriva CuadrilConTapa.
162
________________________________________________________ Modelo de Productos. Aplicaciones
Figura IV.23. Resultado de efectuar la consulta InfoCuadrilConTapa
En este caso es importante notar que a diferencia de lo mostrado por la Figura IV.21,
los valores de los atributos estructuraRequerida y estructuraDe no coinciden. Para el primer
atributo se tiene como valor a la estructura CuartoTraseroSTR; mientras que en el otro caso
se
tienen
tres
valores
CuadrilConTapaSTR3.
asociados,
Esto
se
debe
CuadrilConTapaSTR1,
a
que
CuadrilConTapaSTR2
CuadrilConTapa
se
obtiene
de
y
la
descomposición de CuartoTrasero, a través de la estructura CuartoTraseroSTR, y que
CuadrilConTapa
se
puede
descomponer
por
medio
de
CuadrilConTapaSTR1,
CuadriConTapaSTR2 y CuadrilConTapaSTR3. En consecuencia, los requerimientos que
impone CuadrilConTapa, los cuales son inferidos por la vista RequerimientosFamilia, no
coinciden con las relaciones que conforman sus estructuras. Estos requerimientos se
muestran en la Figura IV.24.
El caso de estudio de la industria frigorífica se caracteriza, además de incluir
productos que poseen estructuras de descomposición, por la existencia de familias con más
de una estructura. Es por ello, que los conjuntos de variantes compuestas que se definan,
en general, se van a derivar de diferentes estructuras. Algunos ejemplos de esta situación
se muestran en la Figura IV.19, en la cual pueden observarse los conjuntos de variantes que
son miembros de la familia SECarneCocidaCongelada, indicándose también cuál es la
estructura de la que se deriva cada uno de estos conjuntos. Asimismo puede apreciarse que
los conjuntos SECarneCocidaCub, SECarneCocidaCubMix y SECarneCocidaSaz se derivan
de una de las estructuras, mientras que SECarneCocidaReb se deriva de la otra.
.
163
________________________________________________________ Modelo de Productos. Aplicaciones
Figura IV.24. Resultado parcial de la vista RequerimientosFamilia aplicada a
CuadrilConTapa
La aplicación de los conceptos propuestos para la definición de conjuntos de
variantes en este caso de estudio no difiere mayormente de lo ya expuesto para el caso
previo. Por esta razón, sólo se presentará en esta sección la definición de uno de los
conjuntos antes mencionados, con el fin de ejemplificar cómo se define la estructura de un
conjunto de variantes cuando dicha estructura posee relaciones selectivas, como es el caso
de la estructura SECarneCocIdaCongeladaSTR. En particular, se eligió exponer el caso del
conjunto de variantes denominado SECarneCocidaReb, el cual, además de los tipos de
cambios ya explicados al describir el caso de estudio previo, incorpora un cambio de tipo
SeleccionFamilia. La definición de dicho conjunto se muestra en la Figura IV.25 y en la
Especificación IV.25.
SECarneCocidaReb in ConjuntoVarianteC
with
attribute,miembroDe
miembroDe : SECarneCocidaCongelada
attribute,derivaDe
derivaDe : SECarneCocidaCongeladaSTR
attribute,modificacionAplicada
modificacionAplicada : m1CCC_Reb
end
Individual m1CCC_Reb in Modificacion
with
attribute,cambioAplicado
cambioAplicado1 : SeR14fam1;
cambioAplicado2 : ElR13fm1;
cambioAplicado3 : Ca2R12fm1
end
Especificación IV.25. Definición del conjunto de variantes SECarneCocidaReb
164
________________________________________________________ Modelo de Productos. Aplicaciones
Figura IV.25. Definición del conjunto de variantes SECarneCocidaReb
Puede observarse que el conjunto de variantes en cuestión se deriva de la estructura
SECarneCocidaCongeladaSTR, pero implica la aplicación de la modificación m1CCC_Reb a
la misma. Esta última introduce tres cambios diferentes para la mencionada estructura:
SeR14fm1, ElR13fm1 y Ca2R12fm1, cuyas definiciones se presentan en la Especificación
IV.26.
Individual SeR14fam1 in SeleccionFamilia
with
attribute,relacionModificada
relacionModificada : R14fa
end
Individual ElR13fm1 in Eliminacion with
attribute,relaciónModificada
relacionModificada : R13f
end
Individual CaR12fm1 in CambioQP with
attribute,relacionModificada
relacionModificada : R12f
attribute,newQP
newQP : 15KG
end
Especificación IV.26. Definición de los cambios que dan lugar a la estructura
asociada a m1CCC_Reb
Los cambios que se realizan son instancias de SelecciónFamilia, Eliminación y
CambioQP. El empleo de los dos últimos ya fue explicado en la sección previa. Con
respecto a la aplicación del cambio de tipo SeleccionFamilia sobre la estructura
SECarneCocIdaCongeladaSTR, en la Figura IV.26 se presenta el resultado de la vista
estructuraSECarneCocidaReb que, de manera similar a las vistas presentadas en las
Figuras IV.9 y IV.11, es una especialización de la vista definida en la Especificación III.42.
165
________________________________________________________ Modelo de Productos. Aplicaciones
Figura IV.26. Resultado de la consulta denominada estructuraSECarneCocidaReb.
En este punto resulta interesante efectuar una comparación entre la estructura
original (ver Especificación IV.18 y Figura IV.20) y la que resulta de aplicar la modificación
m1CCC_reb. Se puede observar que de las cuatro relaciones sólo quedan dos en la
estructura del conjunto de variantes, a pesar que únicamente se aplicó una operación de
Eliminación (ElR13fm1). Esto se debe a que el cambio denominado SeR14fam1, que se
aplica sólo a relaciones de tipo selectivas, representa la elección de una de las relaciones de
ese tipo presentes en la estructura (R14fa y R14fb) y, en consecuencia, implica que la otra
sea eliminada de la misma.
Para este caso particular, en el que existen solamente dos relaciones selectivas, una
representación equivalente a la aplicada (con un cambio de tipo SeleccionFamilia) consiste
en utilizar un cambio de tipo Eliminación que suprima la relación R14fb de la estructura en
lugar de utilizar el cambio SelecciónFamilia. Sin embargo, si se tienen n relaciones
selectivas (n mayor que dos), esta segunda representación requeriría n -1 instancias del tipo
de cambio Eliminación, en tanto la relación que se selecciona no debe eliminarse. De la
manera propuesta, sólo se necesita una instancia de la clase SeleccionFamilia para indicar
cuál es la relación que debe quedar en la estructura, quedando implícitas las n-1
eliminaciones, lo cual es más eficiente.
Es importante recordar que en la estructura particular de un conjunto de variantes
debe existir una relación selectiva por cada conjuntoSelección que exista en la estructura
base de la familia de la que dicho conjunto de variantes es miembro. La cantidad de estos
conjuntos que existen en una estructura determinada está dado por el número de instancias
166
________________________________________________________ Modelo de Productos. Aplicaciones
de la clase Selectiva que participan como valores de los atributos tipoRelacion de las
relaciones que conforman dicha estructura.
Como ya se mencionó, no se ejemplifican los conceptos vinculados con la definición
de las instancias de nivel de productos para este caso de estudio, debido a que éstos ya
fueron presentados en la sección previa. Con fines ilustrativos, solamente se presentará en
la Figura IV.27 el resultado de la consulta VerMiembrosCV que muestra los productos
específicaos que son miembros del conjunto de variantes SECarneCocidaReb.
Figura IV.27. Consulta VerMiembrosCV aplicada a SECarneCocidaReb
IV.4. CONCLUSIONES
Este capítulo presenta la aplicación del modelo propuesto a dos casos de estudio
extraídos de industrias con características diferentes. Por un lado, se presenta la aplicación
del modelo a la representación de los productos de una planta de producción de golosinas,
que posee una gran cantidad de variantes de productos con estructuras de composición. Por
el otro, se aborda el caso de los productos de una industria frigorífica, en la cual conviven
productos que poseen estructuras de composición, descomposición e híbridas. Sin
embargo, se observa que la aplicación del modelo es similar en ambos casos. Esto
demuestra que la propuesta efectuada es lo suficientemente genérica como para
representar información estructural de productos pertenecientes a diferentes tipos de
industria.
167
________________________________________________________ Modelo de Productos. Aplicaciones
Al mismo tiempo, el hecho que en la representación del modelo se haya elegido
tecnología de objetos, le otorga la flexibilidad necesaria para poder extenderlo de manera de
incorporar información no estructural de los productos, que no está contemplada en esta
propuesta. Así, por ejemplo, podría adicionarse información de utilidad para la función de
planificación, relacionada con las demandas, los proveedores y tiempos de entrega.
Asimismo, podría interesar mantener almacenados como parte del modelo algunos de los
datos logísticos y comerciales de los productos que generalmente son administrados por
otras áreas. También resulta apropiado disponer de información de los parámetros
correspondientes
a
las
distintas
políticas
de
abastecimiento
y/o
producción,
o,
específicamente para el caso de la industria frigorífica, información que permita mantener la
trazabilidad de las medias reses que ingresan como materia prima.
La implementación realizada en ConceptBase permite, sin la construcción de un
sistema informático, verificar la validez del modelo propuesto mediante la aplicación a
diferentes casos de estudio. Por otra parte, permite el agregado de atributos a las distintas
clases y la inferencia de sus valores a través de reglas. Además, la definición de vistas
posibilita la recuperación de información desde diferentes perspectivas, característica que
debe ser explotada para presentar la información de productos de acuerdo a las distintas
visiones que tienen de la misma las diversas áreas funcionales de una organización.
168
V. PROTOTIPO DE SISTEMA DE PROCESAMIENTO DE BOMS
V.1. INTRODUCCIÓN
En base al modelo conceptual propuesto en el Capítulo III se implementó un prototipo
de un sistema de procesamiento de BOMs denominado COOBOM (Complex Object Oriented
BOM). El mismo fue testeado utilizando información correspondiente a los dos casos de
estudio propuestos.
La arquitectura del prototipo se basa en la tecnología J2EE (Java 2 Enterprise
Edition) (http://java.sun.com/javaee/) la cual da soporte para el desarrollo de aplicaciones
distribuidas cliente-servidor multicapas. Para lograr la persistencia de los objetos
almacenados se optó por trabajar con el servidor de base de datos orientado a objetos
Versant (Versant, 1998), que facilitó la implementación del modelo tal cual fue concebido sin
tener que transformarlo para almacenarlo en un esquema relacional.
Sin embargo, cabe aclarar que la tecnología J2EE generalmente es utilizada con
bases de datos relacionales, por lo cual se dispone de una gran variedad de soluciones para
lograr persistencia con este tipo de bases de datos, pero no ocurre lo mismo para bases de
datos orientadas a objetos. Por lo tanto, fue necesario realizar una revisión de las
herramientas disponibles para brindar persistencia en Versant a través de esta tecnología.
Se encontraron aplicaciones propietarias de este administrador de bases de datos que
permitían la implementación, pero de utilizarlas el producto resultante se encontraría muy
ligado a las mismas siendo prácticamente imposible modificar el tipo de almacenamiento en
un futuro. Por ello que se decidió utilizar componentes disponibles como software libre para
contener la aplicación, aislando el componente de acceso a la base de datos de manera
que, en un futuro, pueda ser cambiado por otro.
El presente capítulo presenta en primera instancia una breve descripción de la
arquitectura del prototipo y las tecnologías usadas en su implementación. Posteriormente,
brinda una explicación sobre las funcionalidades de la aplicación desarrollada.
V.2. ARQUITECTURA Y TECNOLOGÍAS USADAS EN LA IMPLEMENTACIÓN DEL PROTOTIPO
Como se puntualizara en la introducción, se utilizó la base de datos Versant para
lograr la persistencia. Versant es un sistema de administración de base de datos orientado a
objetos para aplicaciones distribuidas multiusuario. Provee varios componentes e interfaces
con lenguajes específicos para el desarrollo de aplicaciones que utilizan este tipo de bases
167
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
de datos. Por ejemplo interfaces para C, C++, Smalltalk y Java. Esta última es la que se
empleó para el desarrollo del prototipo.
Como se señaló, el prototipo fue desarrollado bajo tecnología Java 2 Enterprise
Edition (J2EE), la cual ya impone ciertas características arquitectónicas. J2EE define una
arquitectura multicapa para implementar aplicaciones basadas en la Web. La tecnología
J2EE utiliza un modelo unificado y basado en componentes, que simplifica y minimiza la
complejidad del desarrollo de este tipo de aplicaciones.
Un componente J2EE es una unidad de software funcional autocontenido, que se
ensambla dentro de una aplicación y que se comunica con otros componentes de la misma.
La especificación J2EE define los siguientes tipos de componentes:
Aplicaciones clientes y Applets: componentes que se ejecutan en el lado del
cliente.
Java Servlets y Java Server Pages (JSP): componentes Web que se ejecutan
en el lado del servidor.
Enterprise Java Beans (EJB): componentes de negocio que se ejecutan en el
servidor de aplicación.
En cuanto a los EJB, es necesario indicar que existen tres tipos: de sesión (con o sin
estado), de entidad y dirigidos a mensaje. El primer tipo representa una conversación
temporal con un cliente. En este caso, cuando el cliente finaliza su ejecución, el “bean” de
sesión y sus datos desaparecen. Por el contrario, un “bean” de entidad representa datos
persistentes almacenados en una fila de una tabla/relación de una base de datos. Si el
cliente finaliza su sesión, o si se apaga el servidor, los servicios subyacentes se aseguran de
grabar el “bean”. Un “bean” dirigido-a-mensaje combina las características de un “bean” de
sesión y de un oyente de “Java Message Service” (JMS), permitiendo que un componente de
negocio reciba asíncronamente mensajes JMS.
La plataforma J2EE está diseñada para proveer soporte para el lado cliente y para el
lado del servidor en el desarrollo de aplicaciones distribuidas y multicapas. En general, estas
aplicaciones están configuradas para que la capa cliente provea la interfaz de usuario, una o
más capas intermedias se ocupan de los servicios para los clientes y la lógica de negocio y
una capa interna provea la administración de los datos. La Figura V.1 presenta un esquema
general de esta arquitectura. Como muestra dicha figura, esta plataforma provee un modelo
de aplicación multicapa, de forma que las diferentes partes de la aplicación puedan estar
ejecutándose en diferentes dispositivos. J2EE soporta una capa cliente, una intermedia
(consistente en una o más subcapas) y una capa interior. La capa cliente soporta clientes de
diversos tipos ubicados tanto dentro de la red de área local de una organización como fuera
de ella. La capa intermedia soporta el servicio a los clientes a través del contenedor Web y la
168
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
lógica del negocio, utilizando los contenedores de Enterprise Java Beans (EJB). Finalmente,
la capa interior facilita el acceso mediante APIs a los sistemas de información
organizacionales; las bases de datos son accedidas en la capa interior a través de APIs.
Firewall
Cliente
Contenedor
EJB
EB
Cliente
Cliente
EB
EB
Contenedor
WEB
servlet
Cliente
Sistemas de
información
de la
empresa
(bases de datos,
ERP, sistemas
tipo “legacy”)
página
JSP
Capa Cliente
Capa intermedia
Capa interior
Figura V.1. Arquitectura J2EE
Si bien un cliente J2EE puede ser un cliente Web o una aplicación, se adoptó para
COOBOM el primer tipo, el cual posee dos partes: páginas Web dinámicas que contienen
diversos tipos de lenguajes de marcado (HTML, XML, etc.), generadas por componentes
Web que se ejecutan en el contenedor Web y un navegador Web que visualiza las páginas
recibidas desde un servidor. Cada cliente se comunica con el contenedor EJB, que se
ejecuta en el servidor J2EE, a través de una JSP o un Servlet, que está brindando servicios
en el contenedor Web de dicho servidor.
Por otra parte, las reglas de negocios constituyen la lógica que resuelve las
necesidades de un dominio particular. Esta lógica es gestionada por los EJB que se ejecutan
en la capa de negocios, los cuales pueden recibir datos desde un cliente, procesarlos si es
necesario y enviarlos a la capa interior para su almacenamiento; también pueden ejecutar el
procedimiento inverso, obtener datos almacenados, procesarlos y enviarlos al cliente.
Finalmente, la capa interior, está conformada por aquellos sistemas de software que realizan
el procesamiento de las transacciones y permiten el almacenamiento permanente de la
información.
Para cada uno de estos componentes de la arquitectura, en el desarrollo de
COOBOM se ha utilizado:
Clientes Web, ya que aún no se han desarrollado aplicaciones clientes que
puedan comunicarse con el servidor.
JBoss, un servidor de aplicaciones J2EE de código abierto implementado en
Java, donde reside un contenedor de EJB, de tipo “session” (sin estado).
169
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
JSP para presentar la información a los usuarios. En la capa Web se utiliza
Tomcat, un contenedor de Servlets con un entorno JSP.
El servidor de bases de datos Versant en la capa interna.
Estos componentes de la arquitectura se presentan en la Figura V.2. En la misma, se
muestran también los cincos paquetes que fueron creados para implementarla, a saber:
Coobom-db: contiene todos los objetos que se almacenan en la base de datos
y los encargados de accederla para realizar consultas o actualizaciones.
Coobom-ejb: contiene los EJB que son los encargados de realizar todo el
procesamiento de la lógica de la aplicación. Reciben requerimientos por parte
de la presentación y acceden a los gestores de la base de datos para poder
cumplirlos. Estos componentes son los encargados de llevar a cabo las
acciones necesarias para proveer las distintas funcionalidades de la
aplicación, las cuales se explican en la sección V.3.
Coobom-dto: contiene todos los objetos de transferencia de datos (DTO–Data
Transfer Objects). Éstos se utilizan para intercambiar información entre la
lógica y la presentación. Existe un DTO por cada objeto que persiste en la
base de datos.
Coobom-util: contiene las utilidades compartidas por la lógica y la
presentación, como ser las excepciones.
Coobom-web: contiene todos los componentes y archivos de configuración
que conforman la presentación del sistema. Este incluye la definición de los
formularios que se presentan al usuario para su interacción con la aplicación.
Algunos de los formularios definidos serán introducidas en la sección
siguiente.
Lógica de Aplicación
COOBOM-util.j ar
JBoss
COOBOM-ej b.j ar
COOBOM-db.j ar
COOBOM-DTO.j ar
Persistencia
Tomcat
Navegador
COOBOM-w eb.w ar
BD Versant
Presentación
Capa Cliente
Capa Intermedia
Capa Interior
Figura V.2. Arquitectura de COOBOM
170
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
La interrelación de estos paquetes se muestra en el correspondiente diagrama de
paquetes de la Figura V.3. Allí se observa que el paquete Coobom-db, incluye otros dos
paquetes, los cuales se muestran también en la figura: el paquete db y el paquete modelo.
Coobom-ejb
db
+ conjuntodeVariantes
Coobom-db
+ familia
+ producto
+ restriccion
«import»
+ conjuntodeVariantes
+ db
+ familia
+ modelo
+ producto
+ restriccion
+ unidad
+ unidad
+ usuario
+ usuario
(fromCoobom-db)
«import»
«import»
«import»
Coobom-util
+ Conexion
+ DTOFactory
«import»
«import»
modelo
+ conjuntodeVariantes
«import»
+ familia
+ producto
Coobom-web
+ restriccion
«import»
+ conjuntodeVariantes
+ familia
Coobom-DTO
+ login
+ conjuntodeVariantes
+ producto
+ familia
+ restriccion
+ producto
+ unidad
+ restricciones
+ util
+ unidad
+ unidad
+ usuario
(fromCoobom-db)
+ usuario
Figura V.3. Diagrama de paquetes, interrelación entre los conceptos que conforman
COOBOM
El paquete modelo, contiene la especificación de las clases del modelo propuesto en
el Capítulo III, las cuales definen el esquema de la base de datos Versant. Por cada una de
estas clases existe una clase en el paquete db, cuyo nombre se conforma con el nombre de
la correspondiente clase en el modelo más el sufijo ”DB”. Por ejemplo, para la clase Familia
perteneciente al paquete modelo, se define la clase FamiliaDB en el paquete db (ver Figura
V.4).
Estas clases, las que se denominarán genéricamente como clases DBs, son las
encargadas de almacenar y recuperar los objetos de la base de datos. Este es el único lugar
donde se manipulan instancias de la base de datos. En el resto de la aplicación, estos
objetos son transformados en Objetos de Transferencia de Datos. Existe una clase DTO,
incluida en el paquete Coobom-DTO, por cada una de las clases del modelo propuesto. Por
ejemplo, para la clase Familia en el paquete modelo se define en Coobom-DTO la clase
FamiliaDTO. Este tipo de organización permite desacoplar la aplicación del almacenamiento
de los datos. Si se cambia la tecnología de almacenamiento de datos, solamente deberán
modificarse los componentes que generan los DTOs a partir de las instancias almacenadas,
y aquellas clases que acceden a las instancias almacenadas (clases DBs).
171
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
familia
familia
+ FamiliaAction
+ estructura
familia
+ FamiliaDTO
+ FamiliaDB
+ estructuta
+ estructura
+ relacion
+ restriccion
+ relacion
(fromCoobom-DTO)
(fromCoobom-web)
familia::
FamiliaDTO
(fromdb)
familia::
FamiliaDB
usa
familia::
FamiliaAction
manipula
usa
util::
BusinessDelegatorFamilia
invoca
familia::
Familia
familia::
FamiliaBean
familia
familia
util
+ Familia
+ BusinessDelegatorConjuntodeVariantes
+ FamiliaBean
+ estructura
+ BusinessDelegatorFamilia
+ estructura
+ relacion
+ BusinessDelegatorProducto
+ restriccion
(frommodelo)
+ BusinessDelegatorUsuario
(fromCoobom-ejb)
(fromCoobom-web)
Figura V.4. Relaciones entre las clases Familia de los paquetes de las distintas
capas
Como puede observarse en la Figura V.4, se define también para la clase Familia, la
clase FamiliaBean en el paquete Coobom-ejb, así como las clases FamiliaAction,
BusinessDelegatorFamilia y ServiceLocatorFamilia en el paquete Coobom-web. Las tres
últimas están relacionadas con la capa de presentación y son las que invocan a los
correspondientes EJB (ver Figura V.5), que para el caso de la Familia, se encuentra
definidos por la clase FamiliaBean.
La vista lógica que se presenta en la Figura V.4 para la clase Familia, se repite para
cada una de las clases del modelo propuesto, y permite que el flujo de información entre la
interfaz y la base de datos pueda ser manejada de igual manera para todas las instancias de
cualquier clase del sistema. La Figura V.5 muestra un flujo de comunicación dentro de la
aplicación, desde que un requerimiento genérico es solicitado por el usuario hasta que se
retorna la respuesta al mismo.
Los objetos de tipo actionX, son los responsables de capturar los requerimientos en
la interfaz de usuario y delegan dicho requerimiento en el correspondiente objeto
BusinessDelegatorX, el cual usa un objeto serviceLocatorX para crear un XBean, el EJB que
ejecutará las operaciones necesarias para dar respuesta al requerimiento del usuario. Si
dicho componente requiere obtener información de la base de datos, delega en el
correspondiente objeto XDB dicha responsabilidad.
172
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
ActionX
ServiceLocatorX
XBean
DiseñadorProducto
XDB
DTOFactory
XLocalHome
requerimiento
BusinessDelegatorX
método Y
getFacade
InitialContext
lookup(XLocalHome.JNDI_NAME)
XLocalHome
home = XLocalHome
método Y
procesa pedido
manipula base de datos
arma respuesta
dto= toDTO(zz)
retorna null, objetos simples u objetos del sistema (dto)
retorno
forward a JSP
Figura V.5. Flujo de comunicación dentro de la aplicación
Hasta este punto se ha presentado una visión interna de la aplicación (esto es,
algunos detalles acerca de cómo es el funcionamiento de la misma). Esta arquitectura
soporta el comportamiento del prototipo propuesto y permite que éste provea eficientemente
un conjunto de funcionalidades que serán introducidas y ejemplificadas en la siguiente
sección
V.3. FUNCIONALIDADES
DEL PROTOTIPO
La presente sección expone las funcionalidades del prototipo desarrollado. Éstas se
presentarán mediante diagramas de casos de uso, exponiendo las pantallas que la
aplicación presenta en la interacción con el usuario. Las mismas se encuentran definidas en
el paquete Coobom-web, que fuera presentado en la sección previa.
La Figura V.6 presenta el diagrama de casos de uso principal de la aplicación, que
representa las funcionalidades básicas del sistema, asociadas a los actores identificados. El
actor Usuario posee un rol básico de acceso al sistema, el cual se especializa en:
173
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
Modelador de Familias: es aquél que posee el rol que le permite crear,
modificar y eliminar familias y unidades de medida (casos de usos CU-003 y
CU-004, respectivamente).
Modelador de Conjunto de Variantes: es aquél que posee el rol que le permite
crear, modificar y eliminar conjuntos de variantes (caso de uso CU-005).
Modelador de Productos: es aquél que posee el rol que le permite crear,
modificar y eliminar productos (caso de uso CU-006).
Administrador: es aquel que posee el rol que le permite crear, modificar y
eliminar usuarios (caso de uso CU-007).
CU-001 Ingresar
CU-002 Modificar
Dato de Usuario
CU-057 Salir
Usuario
Modelador de
Familias
CU-003 Gestionar
Familia
CU-004 Gestionar
Unidad de Medida
Modelador de
Conj untos de
Variantes
CU-005 Gestionar
Conj unto de
Variantes
Modelador de
Productos
CU-006 Gestionar
Producto
Administrador
CU-007 Gestionar
Usuario
Figura V.6. Diagrama de casos de uso principal de la aplicación
Cuando un usuario inicia una sesión en el sistema, se encuentra con una pantalla
que presenta tres áreas, las cuales se muestran en la Figura V.7. Éstas son:
Selección de opciones: se encuentra a la izquierda de la pantalla y permite el
acceso a las distintas funcionalidades, las cuales se encuentran agrupadas en
módulos. Es por ello que las opciones que se muestran varían según el
modulo que esté seleccionado.
Selección de módulos: se encuentra en la parte superior de la ventana y
permite el acceso a los dos módulos disponibles: configuración y estructuras.
El primero permite acceder a las funcionalidades relacionadas con la gestión
de usuarios de la aplicación. El segundo, en cambio, permite el acceso a las
opciones para la gestión de estructuras de productos.
Área de datos y visualización: corresponde a la mayor parte de la pantalla y
se encuentra enmarcada por las otras dos áreas. Corresponde al área de
174
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
trabajo. Allí se presentarán los diferentes formularios para el ingreso y
visualización de los datos.
En particular, la Figura V.7 presenta la interfaz que muestra el formulario para la
creación de usuarios correspondiente al módulo de configuración, opción usuarios.
El formulario que se muestra en la Figura V.7 permite la creación de un nuevo
usuario, definiendo para éste un nombre, una clave y los permisos de acceso a la base de
datos. Estos permisos indican si un usuario tiene autorización para crear, modificar, acceder
y/o eliminar familias, conjuntos de variantes, productos y/o unidades de medida. Sólo aquél
usuario que tenga el rol de administrador (el cual se asigna tildando la casilla de verificación
que se encuentra debajo del campo de clave) tendrá permisos para la definición de otros
usuarios.
Área de selección de módulos
Área de
selección de
opciones
Área de datos y
visualización
Figura V.7. Formulario para la creación de usuarios
A continuación se presentarán en detalle las funcionalidades que tienen que ver con
la jerarquía estructural (SH) y de abstracción (AH) que fueran presentadas en el Capítulo III
e ilustrados en el Capítulo IV. La presentación se hará teniendo en cuenta los tres niveles de
abstracción que se proponen Familia, ConjuntodeVariantes y Producto. De manera paralela
a la descripción de las funcionalidades, se irán mostrando las interfaces relacionadas y, a
modo de ejemplo, se irá cargando la SH y la AH de la familia CarameloFrutalEnv.
V.4. DEFINICIÓN DE FAMILIAS
Las funcionalidades que permiten la definición de familias se encuentran agrupadas
en el caso de uso Gestionar Familia, el cual es explotado y mostrado en mayor detalle en la
175
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
Figura V.8. Es posible observar que la gestión de una familia incluye la creación, la edición y
la eliminación de una Familia. Estas actividades están representadas por los casos de uso
CU-008, CU-009 y CU-010, respectivamente.
A su vez, la edición de una Familia involucra:
la definición de atributos (CU-011);
la
gestión
y
visualización
de
la
estructura
(CU-012
y
CU-013,
respectivamente);
la edición de las restricciones (CU-014);
la copia de la familia (CU-019);
la generación de reportes (CU–017) y, finalmente,
el cierre de la edición (CU-018).
od Gestionar Familia
CU-003 Gestionar
Familia
«extend»
«extend»
CU-008 Crear
Familia
«extend»
CU-010 Eliminar
Familia
«include»
CU-015 Agregar
Restricción de
Familia
CU-009 Editar
Familia
CU-011 Editar
Atributo de Familia
«extend»
«extend»
CU-014 Editar
Restricción de
Familia
«extend»
«extend»
CU-012 Gestionar
Estructura
«extend»
CU-017 Generar
Reporte
CU-013 Visualizar
Estructura de Familia
«extend»
«extend»
«extend»
«extend»
CU-016 Eliminar
Restricción de
Familia
CU-019 Copiar
Familia
CU-018 Cerrar
Familia
Figura V.8 .Casos de uso que extienden Gestionar Familia
A continuación se presentan las interfaces que muestra el prototipo cuando se quiere
cargar la familia CarameloFrutalEnv, presentada en el caso de estudio. En la Figura V.9 se
puede observar la pantalla que se muestra cuando se selecciona la opción “Familias” en el
menú de la izquierda. Puede observarse el listado de familias abiertas, que en este caso
está vacío. Una familia se encuentra en estado “abierta” desde que es creada hasta que se
cierre explícitamente su edición. Mientras una familia permanezca en edición, no pueden
crearse conjuntos de variantes a partir de ella.
176
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
Figura V.9. Listado de familias “abiertas” cargadas en el sistema
En la misma pantalla, puede cambiarse el listado que se muestra (familias abiertas)
seleccionando la opción “cerradas”, en cuyo caso se listan, como lo expone la Figura V.10,
todas las familias que se encuentran en la base de datos y cuyo estado es “cerrada”. Este
estado indica que ya se ha finalizado la edición de dicha Familia y que pueden crearse
conjuntos de variantes a partir de ella. Una familia cerrada ya no puede modificarse.
Figura V.10. Listado de familias “cerradas” cargadas en el sistema
Para crear una nueva familia, se debe seleccionar el botón etiquetado con el signo
“+”, que se encuentra a la derecha del listado de familias abiertas (Figura V.9). Al hacer esto,
se presenta la pantalla empleada para crear una familia, la cual se expone en la Figura V.11.
177
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
Figura V.11. Pantalla para la creación de una Familia
En este formulario, se debe ingresar el código de la familia, el nombre y la
descripción de la instancia que se está creando. Se observa que el primer campo tiene un
asterisco a la derecha, lo cual indica que su carga es obligatoria. Una vez ingresados los
datos, se debe presionar el botón “Guardar” para hacer persistente la información y proceder
a la edición de la familia. Una vez que se presiona dicho botón, se agregan al formulario
nuevos controles (que se muestran en la Figura V.12) que permitirán el acceso a la edición
de los atributos de la familia (“Atributos”), la gestión de las estructuras asociadas
(“Estructuras”) y su visualización (“Visualizar Estructuras”), la administración de restricciones
(“Restricciones”), así como la generación de reportes (“Reporte”) y el cierre de la edición de
la Familia (“Cerrar”). Al cerrar una familia no será posible modificar su estructura, sus
atributos ni sus restricciones, si es que ésta se emplea en las estructuras de otras familias o
a partir de ella se han definido conjuntos de variantes.
178
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
Figura V.12. Pantalla para la edición de la información de una Familia
Al presionar el botón “Estructuras” se accede al formulario que permite la creación,
edición y borrado de estructuras. En este formulario, que se presenta en la Figura V.13,
puede observarse la lista de estructuras asociadas a la familia que se está editando. En este
caso particular dicha lista aún está vacía. La lista permite filtrar las familias por el tipo de sus
estructuras: de composición, de descomposición o simples, que es la opción a seleccionar
para aquellas familias que no tienen estructura. Para crear una nueva estructura hay que
posicionarse en la lista que corresponde al tipo de estructura que se quiere crear y presionar
el botón etiquetado con el símbolo “+”. Se presentará entonces el formulario para cargar el
código, nombre y descripción de la nueva estructura. Una vez guardada esta información, se
accede a la pantalla que permite la carga de las relaciones que conforman dicha estructura,
la cual se muestra en la Figura V.14.
Figura V.13. Pantalla que permite la creación de las estructuras de una Familia
En el formulario que se presenta en la Figura V.14 se muestran dos de los
componentes de la estructura CarameloFrutalEnvSTR, que fueron ya cargados. Para crear
el último componente que falta se debe seleccionar el botón con el signo “+” a la derecha de
la lista. Se presenta entonces el formulario que permite la carga de nuevas relaciones, el
cual se muestra en la Figura V.15.
Puede observarse en la Figura V.15 que se permite la carga de todas las
propiedades de una relación de composición, a saber:
i)
la familia componente, la cual es seleccionada de una lista de familias
“cerradas”;
ii)
la cantidad de composición;
179
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
iii)
la unidad de medida (si no existe, puede crearse accediendo al formulario
correspondiente desde esta pantalla) y
iv)
los límites máximo y mínimo para la cantidad de composición.
Al finalizar la edición se presiona el botón “Guardar” para grabar las modificaciones y
regresar a la edición de la estructura, formulario en el cual, ahora aparecerá también listada
esta nueva relación.
Crea relación
Elimina relación
seleccionada
Figura V.14. Creación de una estructura de composición
180
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
Figura V.15. Creación de la relación para el componente CarameloFrutalDes
Si se desea visualizar alguna estructura de la familia se debe presionar el botón
“Visualizar Estructuras” en el formulario que se muestra en la Figura V.12. En ese caso, se
presenta un formulario que permite mostrar todas las estructuras que tiene asociada una
familia. En el ejemplo analizado solamente está definida la estructura de composición
CarameloFrutalEnvSTR, la cual se muestra en la Figura V.16. Es posible observar en esta
figura
que,
además
de
los
tres
componentes
de
la
estructura
recién
creada
(CarameloFrutalEnvSTR), se presentan los otros dos componentes de la familia
CarameloFrutalDes, denominados RellenoFrutal y MasaConÁcido. Sin embargo, si se desea
seguir explotando la estructura, se deberán expandir estas dos ramas como se ilustra en la
Figura V.17.
181
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
Figura V.16. Visualización de la estructura de la familia CarameloFrutalEnv. Parte 1
En la Figura V.17 pueden observarse las estructuras alternativas que tienen las
familias RellenoFrutal y MasaConÁcido. La visualización puede ir modificándose mediante el
ocultamiento y/o expansión de las ramas del árbol, con lo cual, es posible llegar a apreciar la
estructura multinivel de la familia CarameloFrutalEnv.
La Figura V.18 presenta la primera página del reporte que se genera para la familia
CarameloFrutalEnv al seleccionar el botón correspondiente en el formulario que se ilustra en
la Figura V.12. Es importante mencionar, que este reporte contiene información de la familia
en cuestión: sus atributos, estructura y restricciones, así como información para todas las
familias presentes en su estructura multinivel.
Como se indicó anteriormente, para poder empezar a crear los conjuntos de variantes
asociados a una familia, se debe cerrar explícitamente la edición de dicha familia. Para ello
se debe presionar el botón “Cerrar” que se muestra en el formulario que expuesto en la
Figura V.12.
182
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
Figura V.17. Visualización de la estructura de la familia CarameloFrutalEnv. Parte 2
Figura V.18. Reporte generado para la familia CarameloFrutalEnv
183
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
V.5. DEFINICIÓN DE CONJUNTOS DE VARIANTES
En esta sección se introducirán las funcionalidades que brinda COOBOM para la
administración de conjuntos de variantes, el segundo nivel en la jerarquía de abstracción
propuesta en el Capítulo III.
En la Figura V.19 se presenta el caso de uso Gestionar Conjunto de Variantes y sus
extensiones. Es posible observar que la gestión del conjunto de variantes permite la
creación, la edición y la eliminación de un ConjuntodeVariantes. Estas actividades están
representadas por los casos de usos CU-027, CU-028 y CU-029, respectivamente.
A su vez, la edición de un conjunto de variantes involucra:
la definición de atributos (CU-031);
la edición de las restricciones (CU-034);
la copia del conjunto de variantes (CU-033);
la gestión del conjunto de variantes (CU-030) y, finalmente,
el cierre de la edición (CU-018).
CU-005 Gestionar
Conj unto de
Variantes
«extend»
CU-027 Crear
Conj unto de
Variantes
«extend»
CU-030 Gestionar
Estructura
Conj unto de
Variantes
«extend»
«extend»
CU-029 Eliminar
Conj unto de
Variantes
CU-028 Editar
Conj unto de
Variantes
«extend»
CU-031 Editar
Atributo de
Conj unto de
Variantes
«extend»
«extend»
CU-032 Cerrar
Conj unto de
Variantes
«extend»
CU-033 Copiar
Conj unto de
Variantes
CU-034 Editar
Restriccion de
Conj unto de
Variantes
«extend»
CU-035 Agregar
Restricción de
Conj unto de
Variantes
«extend»
CU-036 Eliminar
Restricción de
Conj unto de
Variantes
Figura V.19. Caso de uso Gestionar Conjunto de Variantes
Por su parte, la gestión del conjunto de variantes involucra por un lado, la
modificación de la estructura de la que se deriva el conjunto de variantes que está siendo
gestionado y, por el otro, la definición de preselecciones para los distintos componentes de
184
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
la estructura en cuestión. Estas funcionalidades se presentan en el diagrama de casos de
uso que se muestra en la Figura V.20.
CU-030 Gestionar
Estructura
Conj unto de
Variantes
«extend»
CU-038 Excluir
Relación
«extend»
CU-039 Modificar
v alor de Relación
«extend»
«extend»
CU-040 Reincluir
Relación
CU-058
Preseleccionar
Conj untos de
Variantes
Figura V.20. Caso de uso Gestionar Estructura de Conjunto de Variantes
El caso de uso Gestionar Estructura Conjunto de Variantes (Figura IV.20) es
extendido por los casos de uso: Excluir Relación, Modificar Valor de Relación, Reincluir
Relación y Preseleccionar Conjuntos de Variantes. Estos casos de uso representan las
siguientes funcionalidades:
eliminar componentes de la estructura (CU-038) ;
cambiar las cantidades de composición de una relación (CU-039);
cancelar la eliminación realizada para un componente (CU-040);
preseleccionar uno o más conjuntos de variantes (CU-058).
Para ejemplificar estas funcionalidades, se presentan a continuación las interfaces
que ofrece el sistema al usuario durante la carga del conjunto de variantes VaritaKIM.
Al seleccionar la opción “Conjunto de Variantes” en el menú que se encuentra en el
área de selección de opciones, se presenta la lista de conjuntos de variantes que están en
edición (“abiertos”). En la Figura V.21 se muestra este listado, en el cual se aprecia que el
conjunto de variantes BolsínFrutalRoc está en edición.
Figura V.21. Listado de conjuntos de variantes cargados en el sistema
185
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
La creación de una nueva instancia de ConjuntodeVariantes, se realiza mediante el
formulario que se presenta en la Figura V.22 para la carga de VaritaKIM. El campo “Código”
es obligatorio, como lo indica el símbolo * que se encuentra a la derecha del mismo, en tanto
que el campo “Nombre” es opcional. Por su parte, las dos últimas listas desplegables
permiten seleccionar la familia a la cual pertenece el conjunto de variantes que se está
creando y la estructura de la cual se deriva. En este caso particular, VaritaKIM es miembro
de CarameloFrutalEnv y se deriva de la estructura CarameloFrutalEnvSTR, como muestra la
Figura V.22.
Como en el caso de la creación de una familia, se debe presionar el botón “Guardar”
para crear la instancia. Se agregan entonces al formulario los botones que se muestran en la
Figura V.23, los cuales permiten la creación de atributos, el manejo de restricciones, la
edición de los cambios y preselecciones que son propias del conjunto de variantes que se
está editando; así como el cierre de la edición del mismo.
Figura V.22. Pantalla que permite la creación del conjunto de variantes VaritaKIM
Figura V.23. Pantalla que permite la edición del Conjunto de Variantes VaritaKIM
186
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
En la interfaz que se muestra en la Figura V.23 la selección del botón “Gestionar”
permite acceder al formulario para modificación de la estructura y preselección de conjuntos
de variantes, que se presenta en la Figura V.24. En ésta puede observarse que dicho
formulario tiene tres áreas:
i)
Panel de estructura: se ubica a la izquierda del formulario y en él se expone
la estructura de la que se deriva VaritaKIM.
ii)
Panel de preselección: se ubica en la parte superior derecha. Éste permite
realizar, para cada componente de la estructura, la preselección de
conjuntos de variantes.
iii)
Panel de cambios: ubicado en la parte inferior izquierda, posibilita la
introducción de cambios parciales a la estructura.
En el primer panel el usuario puede ir expandiendo o contrayendo las ramas del árbol
de la estructura. Cada vez que una familia componente es seleccionada en el árbol, se
muestran en el panel de preselección, todos los conjuntos de variantes que son miembros
de dicha Familia. Estos conjuntos pueden ser seleccionados mediante la casilla de elección
que se encuentra a la izquierda de cada uno de ellos. Haciendo “clic” en ella, aparece un
tilde cuya presencia indica que ese conjunto de variantes es preseleccionado para el
conjunto de variantes que está siendo editado.
En la Figura V.24, se encuentra resaltado, en el panel de estructura el componente
PapelEnvoltorio, y se puede apreciar, en el panel preselección, que se ha optado por el
conjunto de variantes EnvVaritaKIM. Por otra parte, en la misma figura, el panel de cambios
muestra la cantidad de composición junto con sus límites mínimo y máximo que
corresponden a la relación que une el componente seleccionado con la estructura. El campo
de cantidad puede ser modificado para reflejar cambios en la estructura. Éste es el caso del
componente PapelSeparador (resaltado en la Figura V.24), para el cual la cantidad de
composición fue modificada de 30.87GR a 42GR.
187
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
Panel Preselección
Panel de Estructura
Panel de Cambios Parciales
Figura V.24. Gestión del conjunto de variantes VaritaKIM - Preselección de
PapelEnvoltorio
Siguiendo con el análisis de los componentes de la estructura, la Figura V.25 muestra
la información para la familia CarameloFrutalDes. Se observa la preselección del conjunto de
variantes VaritaFrutal en el panel de preselección, mientras que en el panel de cambios
parciales puede observarse que la cantidad de composición para la correspondiente relación
es de 958GR.
Figura V.25. Gestión del conjunto de variantes VaritaKIM - Preselección
CarameloFrutalDes
188
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
Otra de las funcionalidades que posee la aplicación, es la eliminación es la
eliminación de componentes de una estructura, lo que es posible realizar a través del botón
“Excluir” que se muestra debajo del panel de estructura. Haciendo “clic” sobre el mismo, se
elimina de la estructura el componente que esté seleccionado. Para el conjunto de variantes
VaritaKIM el componente PapelSeparador se ha eliminado, y aparece tachado en las figuras
V.24 a V.26. En particular, esta última figura, muestra que cuando se selecciona un
componente que se encuentra eliminado, desaparecen los paneles de preselección y cambio
parcial. En la Figura V.26 puede observarse, también, que cuando se selecciona un
componente previamente excluido, aparece en el lugar donde estaba antes el botoón
“Excluir”, el botón “Reincluir”. Éste permite deshacer la eliminación y volver a considerar el
componente en la estructura del conjunto de variantes que se está editando.
De manera similar a lo que ocurre con la edición de las familias, una vez finalizada la
edición del conjunto de variantes VaritaKIM, éste debe ser cerrado a través del botón
“Cerrar” que se muestra en la Figura V.23. A partir de ese momento, no podrán realizarse
modificaciones de ningún tipo sobre el conjunto de variantes en cuestión. Por otra parte, se
habilita la posibilidad de crear productos que sean miembros del mismo.
Figura V.26. Gestión del conjunto de variantes VaritaKIM - Eliminación de
PapelSeparador
V.6. DEFINICIÓN DE PRODUCTOS
Resta aún presentar las funcionalidades que brinda el prototipo para la administración
de instancias del último nivel de la jerarquía de abstracción; es decir, aquéllas pertenecientes
189
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
al nivel Producto. Éstas se presentan en el diagrama de casos de uso que se introduce en la
Figura V.27. Allí puede apreciarse que, de manera similar a lo que ocurre para las familias y
los conjuntos de variantes, la Gestión de Productos involucra:
la creación de un producto (CU- 041);
la edición de un producto (CU- 042) y
la eliminación de un producto (CU-043).
La edición de un producto permite la creación del mismo (CU-045), la edición de sus
atributos (CU-047) y la gestión del producto (CU-048); así como su copia (CU-046).
Como ya se hizo en las secciones anteriores se ejemplificarán estas funcionalidades
mediante la presentación de las interfaces que muestra la aplicación a medida que se carga
el producto SE508219 (VaritaKIMFrutillaEnv) en el sistema.
La primera parte del proceso de creación de un producto es similar al de un conjunto
de variantes. Se selecciona el botón que se encuentra a la derecha de la lista de productos
abiertos y que tiene el signo “+”. Luego se procede a la carga del código, del nombre y a la
selección del conjunto de variantes del que es miembro el producto en cuestión,
determinando así la estructura de dicho producto. Una vez que se guarda esta información
se presenta el formulario que se muestra en la Figura V.28.
CU-006 Gestionar
Producto
«extend»
CU-043 Eliminar
Producto
CU-042 Editar
Producto
CU-041 Crear
Producto
«extend»
CU-045 Cerrar
Producto
«extend»
«extend»
«extend»
CU-046 Copiar
Producto
«extend»
«extend»
CU-047 Editar
Atributo de
Producto
CU-048 Gestionar
Estructura
Producto
«extend»
CU-050
Seleccionar
Producto
Figura V.27. Casos de uso asociados a Gestionar Producto
190
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
Figura V.28. Creación del producto SE508219 (VaritaKIMFrutillaEnv)
Para concluir el proceso de creación, se debe realizar la selección de opciones para
aquellas familias componentes de la estructura que aún no tengan un componente asociado.
Para ello, al presionar el botón Gestionar (Figura V.28) se presenta el formulario que se
muestra en la Figura V.29. Este formulario consta de las mismas partes que el formulario
que se presentó para la gestión de los conjuntos de variantes (panel de estructura, de
selección y de cambios parciales). La diferencia radica en que:
1. El panel de cambios parciales no permite nuevas modificaciones. Muestra
los cambios introducidos al definir el conjunto de variantes del que se
deriva el producto que se está editando.
2. El panel de selección, muestra solamente productos que son miembros de
los conjuntos de variantes que fueran preseleccionados al nivel de
conjunto de variantes del que es miembro el producto en edición.
En el ejemplo que se está analizando, para el componente PapelSeparador, se podrá
seleccionar solamente alguno de los productos que son miembros de EnvVaritaKIM (ver
Figura V.24) que se observan en el panel de selección. En particular, como el producto que
se
está
definiendo
es
un
caramelo
de
frutilla,
se
selecciona
ME308386
(EnvVaritaKIMFrutilla).
El componente PapelEnvoltorio se encuentra en cursiva en la Figura V.29, a
diferencia del otro componente CarameloFrutalDes. Esto indica que el primer componente ya
tiene una única opción asociada. Para efectuar la selección correspondiente al
CarameloFrutalDes, éste debe resaltarse en la estructura y en el panel correspondiente se
debe hacer la elección deseada. En este caso particular, se elige el producto SE408193
(VaritaFrutillaDes) según lo muestra la Figura V.30.
191
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
Figura V.29. Gestión del Producto SE508219 – Selección PapelEnvoltorio
Es importante mencionar que en la estructura que se presenta para el producto
SE508219
(VaritaKIMFrutillaEnv),
no
aparece
el
componente
correspondiente
al
PapelSeparador, ya que dicho componente fue eliminado de la estructura cuando se definió
el conjunto de variantes VaritaKIM, del cual éste es miembro (ver Figura V.26).
Figura V.30. Gestión del Producto SE508219 – Selección CarameloFrutalDes
192
______________________________________________ Prototipo de Sistema de Procesamiento de BOMs
V.7. CONCLUSIONES
En este capítulo se presentó la aplicación COOBOM, un prototipo de sistema de
procesamiento de BOMs, que permite verificar la factibilidad del diseño e implementación de
un sistema de este tipo, que utilice el modelo propuesto en el Capítulo III. Este prototipo fue
testeado utilizando productos de los dos casos de estudio presentados en el Capítulo II, de
acuerdo a la modelización de productos propuesta en el Capítulo IV.
La aplicación permite definir entidades en los tres niveles propuestos para la AH y
especificar la SH para cada uno de ellos.
En consecuencia, es factible en el futuro la
incorporación a la misma de funcionalidades que den soporte a la integración entre tareas de
planificación con diferentes horizontes de tiempo (planificaciones estratégicas, tácticas y
operativas), y que gestionan diferentes tipos de datos a nivel de familias, conjuntos de
variantes e instancias concretas de productos.
El prototipo fue desarrollado con tecnología J2EE, desacoplando mediante el uso de
DTOs, el almacenamiento y recuperación de información, respecto de la lógica de la
aplicación. Esto sin dudas le otorga una gran flexibilidad al minimizar el impacto de los
cambios que se realizan en las herramientas de almacenamiento y gestión de la información
sobre la lógia de la aplicación y viceversa.
193
VI. USO DEL MODELO PROPUESTO EN UNA APLICACIÓN BASADA
EN LA WEB SEMÁNTICA
VI.1. INTRODUCCIÓN
La aplicación COOBOM, presentada en el Capítulo V, es un prototipo de sistema de
procesamiento de BOMs, que implementa el modelo de productos propuesto en el Capítulo
III. Su arquitectura basada en componentes le otorga flexibilidad tanto para realizar cambios
en las interfaces y/o en los repositorios de información utilizados, como para incorporar
nuevas funcionalidades que den soporte a las diferentes unidades organizacionales que
requieran información de productos. COOBOM permite el acceso de múltiples usuarios, a
través de navegadores, a una base de datos local, lo que implica una única base de
conocimientos común. Este enfoque centralizado, si bien es útil dentro de una misma
organización, es muy restrictivo para las empresas de manufactura actuales que se
encuentran inmersas en un contexto que se ha tornado más competitivo y se ha expandido
globalmente de manera dramática en los últimos años. Bajo estas circunstancias, las
organizaciones no poseen ellas mismas todo el conocimiento o las capacidades que
necesitan, sino que confían en otras para obtener información y/o servicios. Una de las
respuestas a esta necesidad surge con los sistemas colaborativos de desarrollo de
productos (CPD – Collaborative Product Development). Un CPD puede definirse como “una
arquitectura computacional basada en Internet que soporta el uso compartido y la
transferencia del conocimiento acerca del ciclo de vida de los productos entre compañías
distribuidas geográficamente para tomar decisiones de ingeniería de manera colaborativa”
(Rodríguez y Al-Ashaab, 2005).
Los rápidos avances de Internet han brindado también oportunidades a las empresas
de manufactura para revitalizar sus estrategias de competencia. Una propuesta para mejorar
la competitividad es el comercio colaborativo de productos (CPC - Collaborative Product
Commerce), el cual se refiere a la adopción de los principios de administración del ciclo de
vida de productos (PLM) en entornos de redes de negocios, utilizando las posibilidades de
cooperación que brinda Internet. En el contexto planteado actualemente el factor crítico es la
colaboración entre cada uno de los eslabones de esta red (Saaksvuori e Immonen, 2005).
Sin embargo, este concepto no siempre es fácil de alcanzar debido a la heterogeneidad
existente entre los sistemas de información de cada uno de los participantes de la cadena
de colaboración. Según Sheth (1998), esta heterogeneidad puede darse en diferentes
niveles, a saber:
193
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
Heterogeneidad de Sistemas: se refiere a las diferencias en el hardware y
en los sistemas operativos utilizados.
Heterogeneidad Sintáctica: surge de la utilización de diferentes lenguajes y
representaciones de datos.
Heterogeneidad Estructural: ocurre cuando un mismo modelo conceptual
puede ser implementado en diferentes esquemas físicos.
Heterogeneidad Semántica: se relaciona con el significado que se le da a
los diferentes términos. Aún cuando éstos sean expresados en distintos
sistemas de información con una misma sintaxis, se presentan básicamente
dos grandes problemas a resolver:
o
Diferentes términos son usados para referir al mismo concepto. Por
ejemplo, en el dominio de la administración de información de
productos, los términos ensamblado intermedio y semielaborado
suelen ser usados por diferentes organizaciones para denotar aquel
producto que se obtiene como resultado de alguna etapa del proceso
productivo pero que requiere aún otros pasos de manufactura.
o
Un mismo término puede ser usado para denotar conceptos distintos.
Como muestra de este problema considérese la palabra receta que
tiene al menos tres interpretaciones asociadas en diferentes ámbitos.
Algunas organizaciones consideran que dicho término define las
operaciones que se deben ejecutar para obtener un producto y otras
lo ven como sinónimo de BOM. La tercera concepción considera que
una receta involucra tanto las operaciones como los componentes que
se necesitan para fabricar un producto.
Muchas tecnologías han sido desarrolladas para tratar de lograr la interoperabilidad
entre sistemas heterogéneos. Por ejemplo, CORBA y DCOM han sido concebidos con el fin
de permitir la interoperabilidad entre diferentes plataformas de hardware y software. XML y
XML-Schema son vistos como elementos claves para el intercambio de información en
Internet, superando los inconvenientes planteados por la heterogeneidad semántica. Sin
embargo, sin un acuerdo en los DTDs (Document Type Definition) utilizados, XML no
soluciona este problema.
En el mismo sentido, Horrocks y colab. (2001) plantean la necesidad de una
integración inteligente de los sistemas de información a través de tres niveles, los cuales se
muestran en la Figura VI.1 y se detallan a continuación:
Integración Técnica: se refiere a la integración de las tecnologías de red y
protocolos. Este aspecto ha sido eficientemente resuelto por Internet y la Web. Con estas
194
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
tecnologías, se brinda solución a los problemas planteados por la heterogeneidad de
sistemas.
Integración Sintáctica: Una vez que es posible técnicamente intercambiar
información, los participantes del intercambio deben estar de acuerdo en una sintaxis común
a fin de entenderse. En este sentido, XML ha ganado una significativa importancia para
solucionar los inconvenientes de la heterogeneidad sintáctica y estructural.
Integración Semántica: Más allá de la integración sintáctica, se presenta la
correspondencia o el “mapeo” semántico de los distintos términos que usan las diferentes
fuentes de información. En relación a este aspecto las ontologías son candidatas para
solucionar el problema de la heterogeneidad semántica entre estas fuentes.
SI
Semántica
Web Semántica
Ontologías
Sintáctica
HTML
XML
SI
XMLS
Técnica
HTTP
FTP
TCP/IP
Figura V.1. Distintos niveles de integración informática
Como se mencionó anteriormente, Internet y las tecnologías Web proveen una
respuesta a la integración de los dos primeros niveles, en tanto la integración semántica
está siendo objeto de investigación desde hace unos años. Según Alexiev y colab. (2004)
puede considerarse como solución a este problema la integración de diferentes fuentes de
información en una única arquitectura mediante ontologías. En este sentido, los esfuerzos
están enfocados en el desarrollo de la Web Semántica (Bernes-Lee y colab., 2001), que no
es más que una evolución de la Web actual.
En virtud del escenario antes puntualizado, se planteó como objetivo llegar a la
definición de una infraestructura informática, basada en tecnologías de la Web Semántica,
que posibilite la implementación de los conceptos de manufactura colaborativa y
administración del ciclo de vida de productos. Estos conceptos involucran diferentes áreas
de una organización e incluso de organizaciones diferentes, así como numerosos sistemas
de información y aplicaciones diversas y de gran complejidad. En consecuencia, alcanzar el
objetivo general planteado en un único paso se torna casi impracticable. Es por ello que se
decidió llegar a cumplir con el mismo a través de etapas incrementales, la primera de las
cuales tiene como meta la definición de una arquitectura de un sistema que permita la
realización de consultas acerca de la estructura de productos cuyos componentes son
195
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
manufacturados por diferentes nodos de una cadena de organizaciones que aplican el
concepto de desarrollo colaborativo de productos. En consecuencia, la información sobre
éstos se encuentra distribuida en los diferentes eslabones de dicha cadena, representados
por ontologías.
Los resultados obtenidos en esta primera etapa, la ontología de productos
denominada PRoduct ONTOlogy (PRONTO) y una arquitectura que la utiliza como
vocabulario común se exponen en este capítulo. Se presentan, inicialmente, algunas
nociones básicas sobre ontologías y Web Semántica. A continuación se introducen algunas
características de PRONTO y
finalmente, se presentan la arquitectura propuesta y su
implementación en un prototipo.
VI.2. LAS ONTOLOGÍAS COMO PILARES DE LA WEB SEMÁNTICA
El término ontología no es nuevo, proviene del área de la filosofía, fue utilizado con
posterioridad en el área de la Inteligencia Artificial y es empleado actualmente en el ámbito
de la Web Semántica. Las ontologías han sido utilizadas para diversos propósitos y por
diferentes comunidades, y, en consecuencia, es posible encontrar distintas definiciones de
dicho término dependiendo del área del conocimiento que se analice. Una de las
definiciones más conocidas es la de Gruber (1993), quien define la ontología como “una
especificación explícita de una conceptualización”. Borst (1997) extendió esta definición
indicando que dicha especificación debe ser formal y compartida. Posteriormente, Studer y
colab. (1998), propusieron la definición que se presentó en el Capítulo I, la cual une las
propuestas efectuadas por Gruber y Borst. Esta última definición, que exige la
representación de los conceptos por medio de una teoría lógica, se contrapone con la
concepción de Ushold y Grüninger (1996), quienes sostienen la existencia de ontologías con
diferentes niveles de formalidad, a saber:
altamente informal: si es expresada con lenguaje natural;
semi informal si se expresa en alguna forma restringida y estructurada del
lenguaje natural;
semi formal: si se expresa en algún lenguaje artificial formalmente
definido; y
rigurosamente formal: si provee definiciones minuciosas de términos con
semántica formal, teoremas y pruebas de propiedades tal como
completitud (completeness) y consistencia (soundness).
En cuanto a los lenguajes que se utilizan para la formalización de ontologías
pesadas, éstos se pueden clasificar en dos grandes grupos: aquéllos surgidos dentro del
196
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
área de inteligencia artificial y los más recientes, denominados lenguajes de marcado
(markup languages) o basados en la Web.
Los paradigmas de representación de conocimiento que soportan los lenguajes del
primer grupo, al que se denominará lenguajes IA, se basan en lógica de primer orden (LPO)
(en algunos casos combinada con “frames”) o en lógica descriptiva (DL) (Baader y Nutt,
2003). Por su parte, los lenguajes de marcado se clasifican en tres grandes grupos: los que
son una extensión de HTML y de XML; los que se basan en redes semánticas y los basados
en lógica descriptiva. En este último grupo, se destacan tres lenguajes, los cuales
establecen los fundamentos para la Web Semántica: RDF (Resource Description
Framework) (Manola y Millar, 2004), RDF-Schema (Brickley y Guha, 2004) y OWL (Web
Ontology Language) (Mc Guinness y van Harmelen, 2004). El primero fue desarrollado por
el W3C (World Wide Web Consortium) como un lenguaje basado en redes semánticas para
la representación de recursos en la Web. Por su parte, RDF-Schema que también es una
recomendación del W3C, es una extensión de RDF que provee primitivas basadas en
“frames”.
Como extensión de los dos ya mencionados, surgió el primer lenguaje de marcado
para la representación de ontologías en la Web Semántica, denominado OWL. Este se
divide en tres sublenguajes (también denominados especies o dialectos), OWL-Lite, OWLDL y OWL-Full, cada uno de los cuales proporciona un conjunto de constructores que
otorgan diferentes grados de expresividad al lenguaje. OWL-Lite es el dialecto más sencillo
y el que posee la menor expresividad. En el otro extremo se encuentra OWL-Full que
representa el lenguaje completo. El dialecto del medio define los mismos constructores que
OWL-Full, pero impone determinadas restricciones en el uso de los constructores.
Una ontología definida en el lenguaje OWL consta de individuos, propiedades y
clases. Las clases proveen un mecanismo para agrupar recursos con similares
características y se definen a través de axiomas de clase (Bechhofer y colab., 2004). Cada
clase está asociada con un conjunto de individuos denominado extensión de clase y cada
uno de sus miembros recibe el nombre de instancia. Éstas se vinculan entre sí por medio de
propiedades, las cuales se especifican mediante axiomas de propiedad y pueden ser de dos
clases: propiedad objeto y propiedad “datatype”. La primera conecta dos individuos mientras
que la segunda asocia un individuo con un valor que corresponde a un determinado tipo de
dato XML.
Los axiomas de clase, construidos a partir de descripciones de clases, permiten la
definición de una clase OWL por su nombre o mediante la delimitación de su extensión de
clase. Una descripción de clase puede ser:
1. un identificador;
197
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
2. una enumeración exhaustiva y explícita de los individuos que conforman su
conjunto de instancias;
3. una restricción sobre alguna propiedad de la clase;
4. la intersección de dos o más clases;
5. la unión de dos o más clases;
6. el complemento de una clase.
La intersección, la unión y el complemento pueden ser vistos como los operadores
lógicos AND, OR y NOT y, al igual que el tipo 3, estos tipos conducen a descripciones de
clases anidadas.
La descripción por identificador describe una clase por su nombre. Los cinco tipos
restantes lo hacen a través de la imposición de condiciones sobre su extensión de clase.
Los tipos 2 a 6 definen una clase que:
contiene exactamente los individuos enumerados (tipo 2);
está conformada por todos los individuos que satisfacen una restricción sobre
una de sus propiedades (tipo 3);
satisface combinaciones booleanas de otras descripciones de clases (tipos 4,
5 y 6).
El axioma de clase más simple consiste en una descripción del primer tipo, pero esto
no aporta información sobre la clase más que su nombre. En general, los axiomas
establecen condiciones necesarias y/o suficientes para que un individuo sea instancia de la
clase que dicho axioma define. Si define solamente condiciones necesarias, la clase se
denomina primitiva. En caso de especificar condiciones necesarias y suficientes constituye
una clase definida o no primitiva.
Para una descripción más detallada de los tipos de
axiomas de clase y descripciones que forman parte del lenguaje, refiérase al Apéndice B.
Según Uschold y Grüninger (1996), el grado de formalidad es uno de los tres
aspectos que permiten clasificar las ontologías. Los otros dos aspectos se vinculan con el
propósito y la naturaleza del tema que la ontología esté caracterizando. Relacionado con el
propósito, se encuentra la noción de generalidad, que implica el grado en que una ontología
puede ser reutilizada en un rango de situaciones diferentes. Las más generales se
denominan “de alto nivel” (“Top level” o “Upper level”), mientras que las más específicas, y
en consecuencia menos reutilizables, son conocidas como “de dominio”. Las ontologías de
alto nivel proveen nociones genéricas, con las cuales los términos raíces de todas las
ontologías existentes deberían estar vinculados. Sin embargo, existen varias propuestas y
las mismas difieren en la forma de clasificar los conceptos generales. Una de ellas es SUMO
(Suggested Upper Level Ontology) (Niles y Pease, 2001) que brinda un conjunto de
198
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
nociones genéricas a partir del cual las ontologías de dominio pueden ser construidas,
definiendo conceptos y relaciones válidas para un determinado campo del conocimiento.
Un análisis del dominio de las empresas de manufactura revela que antes que la
noción de Web Semántica se encontrara tan extendida, ya habían sido propuestas algunas
ontologías para representar el conocimiento acerca de las empresas. Entre ellas se
destacan la ontología de empresa de Uschold y colab. (1998) y las propuestas dentro del
proyecto TOVE (TOronto Virtual Enterprise) (Fox, 1992). Asimismo, en el contexto del
comercio electrónico, las aplicaciones B2B (“Business to Business”) requieren una
comunicación efectiva entre máquinas. En consecuencia, comenzaron a surgir intentos de
definición de estándares que faciliten el intercambio de información entre clientes y
proveedores (y entre socios de negocios) que provean un framework para la identificación
de productos y servicios. Entre éstas pueden citarse a UNSPSC, NAICs, eCl@ss, eOTD o el
diccionario técnico de RosettaNet (RNTD). Estos estándares cuentan con el consenso de un
amplio grupo de organizaciones y han sido codificados en varios lenguajes y formatos. Sin
embargo, no pueden ser considerados ontologías “pesadas” (Heavyweight ontologies) ya
que solamente representan taxonomías de conceptos. Si bien existen algunos intentos de
definición de ontologías derivadas del estándar UNSPSC (McGuinness, 2001; Klein, 2002),
los resultados obtenidos no reflejan completamente la semántica del estándar subyacente y,
por lo tanto, su uso se limita a un reducido conjunto de aplicaciones. Por su parte, Hepp
(2004), propuso una ontología escrita en lenguaje OWL y denominada eClassOWL, que
refleja los conceptos del estándar eCl@ss. El inconveniente que tiene es su gran tamaño,
que impide que pueda ser visualizada y/o editada por las herramientas de edición de
ontologías existentes, ni que pueda ser manipulada a través de los frameworks para el
desarrollo de aplicaciones de la Web Semántica.
VI.3. ARQUITECTURA DE LA WEB SEMÁNTICA
La arquitectura de la nueva Web se basa en una jerarquía de capas, cada una de las
cuales utiliza y extiende las capacidades de la inferior. Éstas se ven reflejadas en la “pila
para la Web Semántica” propuesta por Berners-Lee (2003), la cual se muestra en la Figura
VI.2, donde puede observarse que se definen los siguientes niveles:
Nivel de Recursos: sus funciones incluyen: i) identificar los recursos Web
mediante los URIs (Uniform Resource Identifier), los cuales designan de
forma inequívoca un recurso en la red y ii) proporcionar un medio (el estándar
Unicode) por el cual un texto en cualquier forma e idioma pueda ser
codificado
Nivel Sintáctico: su objetivo es solucionar el problema de cómo definir
distintos lenguajes de marcado para añadir contenido sintáctico a las páginas
199
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
Web. Un lenguaje utilizado en este nivel es XML, el cual es en realidad un
metalenguaje, un lenguaje para escribir lenguajes.
Nivel de Descripción de Recursos: permite la descripción de los recursos en
la Web a través de los lenguajes RDF y RDF-Schema.
Nivel de Ontologías: establece la integración semántica a través de las
ontologías, las cuales constituyen la piedra angular de la propuesta de
Berners-Lee. El lenguaje OWL es, según el W3C, la forma más apropiada de
compartir conocimiento en la Web.
Nivel Lógico: pretende dar flexibilidad a la arquitectura para realizar consultas
e inferir conocimiento a partir de las ontologías.
Nivel de seguridad: permite asignar grados de confianza y seguridad a los
distintos recursos distribuidos en la Web, a través de firmas digitales, redes
de confianza u otras técnicas de autenticación.
Seguridad
Nivel de Seguridad
Rules
Ontología
Encriptado
Framework
lógico
Firma Digital
Prueba
RDF Schema
Nivel Lógico
Nivel de Ontologías
Nivel de Descripción de
Recursos
RDF
XML
Namespaces
URI
Unicode
Nivel Sintáctico
Nivel de Recursos
Figura VI.2. Capas de la arquitectura de la Web Semántica
La Web Semántica ha sido estructurada por niveles, estableciendo una jerarquía de
abstracción y dependencia entre los mismos, aunque esta arquitectura no ha sido totalmente
descripta. Actualmente, muchos esfuerzos de investigación se encuentran enfocados en el
nivel lógico y, por otro lado, no se cuenta con una recomendación oficial por parte del W3C
acerca de las capas que están por encima de dicho nivel.
La infraestructura de la Web Semántica se basa en la representación de los modelos
formales de dominio por medio de ontologías, las que se enlazan unas a otras a través de la
Web.
Estas
ontologías
interrelacionadas
constituyen
una
base
de
conocimiento
consensuado a partir del cual, y mediante el uso de agentes y servicios Web, es posible
diseñar una arquitectura que permita la integración inteligente de los sistemas de
información. Sin embargo, debido a que la Web Semántica está en sus primeras etapas, no
200
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
existen muchas propuestas en el área de manufactura. Las que existen, aún plantean de
manera difusa cómo lograr la interoperabilidad de los sistemas.
De manera general, la Figura VI.3 presenta algunos de los componentes que, según
Herman (2007), intervienen en aplicaciones que utilizan este tipo de tecnología. En la capa
inferior, se encuentran los repositorios de datos que pueden ser de diversos tipos y estar
distribuidos geográficamente. La capa intermedia corresponde a las ontologías descriptas en
lenguaje RDF, RDF-Schema u OWL, las cuales brindan la integración semántica de la
información de los repositorios. Obviamente, entre esta capa y la inferior se deben
implementar herramientas que permitan el mapeo entre las instancias almacenadas en
estos repositorios y los individuos de las ontologías. Finalmente, en la capa superior se
encuentran las aplicaciones que brindan servicios en la Web Semántica. Se han
desarrollado algunos frameworks que brindan soporte para la construcción de este tipo de
aplicaciones,
entre
los
cuales
se
puede
mencionar
al
framework
JENA
(http://jena.sourceforge.net/documentation.html).
Aplicaciones
Datos representados en RDF, RDF-Schema u OWL
SPARQL
Motores de inferencia
JENA
Joseki
….
Herramientas de
Mapeo
GRDDL
SQL/RDF Bridge
….
Datos en diferentes formatos y sistemas
Figura VI.3. Capas que suelen participar en la arquitectura de aplicaciones de
la Web Semántica
JENA es una herramienta de código abierto desarrollada por HP Labs Semantic Web
Research que provee:
Una API RDF que soporta la creación, manipulación y consulta de grafos
RDF.
Una herramienta, denominada ARQ, que brinda servicios para la ejecución de
consultas en lenguaje SPARQL (un lenguaje de consultas para grafos RDF
desarrollado por la W3C)
Una API OWL, diseñado para permitir la conexión de JENA con máquinas de
inferencia (razonadores), los cuales son utilizados para derivar conocimiento
nuevo a partir del que se encuentra explícitamente definido en las ontologías.
201
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
Servicios de red que posibilitan que una aplicación consulte y/o actualice una
base RDF remota. En este caso se utiliza la herramienta Joseki
(http://www.joseki.org/), la cual implementa estos servicios sobre el protocolo
HTTP.
JENA es el framework adoptado en esta Tesis para implementar un sistema de
integración de múltiples fuentes de información de productos.
VI.4. UN PRIMER PASO HACIA LA DEFINICIÓN DE UN SISTEMA PDM BASADO EN LA WEB
SEMÁNTICA
En este punto se plantea un escenario en el cual se requiere compartir información
estructural de productos, la cual puede encontrarse distribuida en los nodos de una red de
productores y consumidores. Se propuso como objetivo la definición de un sistema, basado
en tecnología de Web Semántica, que permita lograr el requerimiento formulado. En
particular, se definió un escenario constituido por cuatro nodos, que participan en la
fabricación de productos miembros de la familia CarameloFrutalEnv (Figura IV.1) y de otras
tres familias de caramelos. A diferencia del caso de estudio de la planta de producción de
golosinas, en esta organización virtual, los caramelos no son producidos totalmente en una
única empresa, sino que cada uno de los nodos de la red participa en su manufactura. De
esta manera, la estructura de un producto no es conocida totalmente por una determinada
organización a partir de datos almacenados localmente. Cada una de estas empresas,
posee información sobre el producto que manufactura y consulta a los otros participantes
acerca de los componentes que necesita pero cuya estructura desconoce. En particular, las
empresas que participan son cuatro, a saber:
Empresa A (EA): posee información acerca de caramelos envueltos y
desenvueltos; pero no conoce cómo se obtienen las masas ni los rellenos.
Empresa B (EB): produce las masas y el Almíbar que se usa en esas masas.
No conoce cómo se obtiene el resto de los ingredientes de las mismas.
Empresa C (EC): provee almíbar y leche condensada. Además produce los
rellenos, pero desconoce la manera de obtener los ingredientes que se
utilizan en la fabricación de los mismos.
Empresa D (ED): encargada de suministrar el resto de las materias primas.
La Figura VI.4 presenta el árbol de estructura multinivel para la familia
CarameloFrutaEnv (corresponde a la clase definida como CarameloFrutalEnv en el Capítulo
IV), uno de los productos fabricados por la Empresa A. Por su parte, la Tabla VI.1 indica
quién provee cada uno de los componentes de esta estructura y proporciona información de
otros caramelos producidos por dicha empresa.
202
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
Como puede observarse en la Tabla VI.1, la información acerca de la estructura del
producto se encuentra distribuida en las distintas organizaciones. En una arquitectura
tradicional, estas fuentes de información son independientes y, en general, se almacena
información redundante y, muchas veces, inconsistente (estos problemas ya fueron
introducidos en el Capítulo I). Esta arquitectura es conocida como de repositorios
independientes (“standalone repositories”) (Vdovjak y colab., 2006) y requiere una
integración manual de los resultados de una consulta realizada sobre todos (o algunos) de
estos repositorios.
Figura VI.4. Árbol de estructura de la familia CarameloFrutalEnv
Tabla VI.1. Distribución de productos en las diferentes organizaciones
Empresa A
PapelSeparador
CarameloFrutalEnv
CarameloFrutalDes
PapelEnvoltorio
CarameloLecheEnv
CarameloLecheDes
CarameloMielEnv
CarameloMielDes
CarameloMentolEnv
CarameloMentolDes
Empresa B
Masa con ácido
Masa sin ácido
Almíbar
Empresa C
Relleno Miel
Relleno Mermelada
Esencia
Relleno Leche
Azúcar
Jarabe
Relleno Mentol
Colorante
Leche Condensada
Relleno Fruta
Ácido
Aceite
Esencia
Ingrediente Relleno
Ácido
Glucosa
Miel
Azúcar
Jarabe
Mermelada
Colorante
Leche Condensada
Empresa D
203
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
En una arquitectura de este tipo, si se desea recuperar el árbol de estructura que se
muestra en la Figura VI.4 se debería ir consultando cada uno de los sistemas de
administración de datos de productos de las empresas, para ir rescatando de manera parcial
la información que luego debe ser combinada para armar la estructura final. Esta situación
es un ejemplo simple de la naturaleza distribuida de la información en las cadenas de
colaboración que unen a las organizaciones actuales. Uno de los problemas en estas
cadenas es que el conocimiento relevante para responder a una consulta, se encuentra
disperso en diferentes fuentes agravado por el hecho de que las mismas pueden ingresar o
salir de la cadena con una frecuencia bastante elevada. Esto implica que quien requiere
información deba: i) localizar porciones de la misma en diferentes sitios, ii) recuperarla y iii)
combinar las porciones en un único resultado. Otra característica que agrega complejidad a
esta tarea de recuperación de información tiene que ver con la naturaleza dinámica de la
cadena de colaboración productiva. Nuevos participantes de la cadena pueden incorporarse
a la misma o alguno de los existentes puede dejarla, haciendo que la estructura de los
productos, identificada en un momento determinado, deje de ser válida.
Para solucionar el inconveniente de la distribución de las fuentes de información se
propone una arquitectura que soporta la integración de estas fuentes a través de un
vocabulario común, pero manteniendo la gestión de las datos de manera local a cada nodo.
El principal objetivo es ocultar al usuario que requiere información, el hecho de que la misma
se encuentra dispersa y fragmentada. Éste no necesita conocer el lugar donde reside la
información que se le retorna como respuesta a su consulta. El sistema debe comportarse
como si todo el conocimiento estuviera disponible en una única fuente, para lo cual se
empleará una arquitectura con mediador (Vdovjak y colab., 2006).
En una primera etapa, la información de los productos residente en cada nodo del
sistema estará representada por instancias explícitamente definidas y codificadas en
ontologías OWL. Éstas importan los conceptos definidos en un vocabulario común
(PRONTO) y definen las instancias en ontologías locales. La arquitectura propuesta consta
de un conjunto de nodos iguales (pares), cada uno de los cuales actúa como mediador entre
el usuario y los otros nodos del sistema, si una consulta es iniciada en él. En el punto VI.4.1
se presenta la ontología a ser empleada en el sistema y en el VI.4.2 se describe la ontología
introducida.
Es importante mencionar que el prototipo de aplicación que se describe en este
capítulo abarca solamente las dos capas superiores de las indicadas en la Figura VI.3. Se
presenta un prototipo de sistema distribuido que permite la ejecución de consultas sobre las
ontologías locales. El mapeo entre éstas y los repositorios de información es una de las
tareas a encarar al finalizar esta primera etapa. En particular esta actividad consistiría en
204
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
encontrar la manera de mapear las instancias gestionadas y almacenadas por los sistemas
de información locales con las instancias de las ontologías.
VI.4.1. Definición de PRoduct ONTOlogy
Si bien existen varias metodologías (Grüninger y Fox, 1995; Uschold y Grüninger,
1996; Fernández-López y colab., 1997) para el diseño de una ontología, todas coinciden en
que es un proceso iterativo al que se asocian básicamente las siguientes actividades:
1. Análisis del dominio de conocimiento.
2. Definición de los conceptos involucrados.
3. Especificación formal e implementación de los conceptos, sus relaciones y sus
restricciones.
4. Validación y/o evaluación de la ontología.
PRONTO es una restricción de la ontología de modelo conceptual propuesto en el
Capítulo III, que surge de la necesidad de desarrollar una implementación de dicho modelo
conceptual en una aplicación basada en la Web Semántica. Debido a esto, el proceso de
creación de esta ontología restringida comenzó, en este caso, a partir del tercer paso, la
especificación formal e implementación. En la formalización se empleó el lenguaje OWL DL
y se utilizó el “plug-in” OWL de la herramienta Protégé (Genaro y colab., 2002).
Previo a la implementación de los conceptos, se realizó una búsqueda de ontologías
que puedan ser reutilizadas o especializadas en PRONTO y a partir de este punto se trató
de identificar qué conceptos del modelo debían ser definidos en OWL. En particular, se
efectúo un estudio de las ontologías existentes para el dominio de trabajo. Es importante
destacar que no existe ninguna que contemple los conceptos aquí presentados para el
dominio de empresas de manufactura con el nivel de complejidad abordado en este trabajo.
Por otro lado, se analizaron ontologías de alto nivel relacionadas con el dominio y como
resultado de este estudio, se decidió reutilizar los conceptos UnitOfMeasure y RealNumber
definidos en SUMO, dejando para una etapa futura la especialización de otros conceptos de
esta ontología. Si bien la misma fue escrita originalmente con KIF (Knowledge Interchange
Format), existen traducciones de la misma a OWL. La Figura VI.5 presenta parcialmente su
taxonomía, en la cual se resalta el concepto UnitOfMeasure. Esta clase posee como
atributos los factores que permiten la conversión entre diferentes unidades; además, tiene
definidas instancias para casi todas las unidades existentes. Se creyó conveniente reutilizar
dicho concepto en lugar de la clase Unidad (Especificación III.10) pues provee una definición
más completa que esta última.
En cuanto a las ontologías de dominio, se decidió que sería importante poder utilizar
eClassOWL para clasificar las diferentes instancias de familias definidas. Pero debido a su
205
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
gran tamaño, que impide que sea manipulada por Protégé y por JENA, se optó por
reproducir una porción de dicha ontología (las categorías necesarias para clasificar los
productos del escenario ficticio) en una ontología definida localmente y que se denomina
catalogo.owl. En una futura etapa en el desarrollo de la ontología, se enfocará la búsqueda
de una solución que permita trabajar con la ontología eClassOWL completa.
Figura VI.5. Vista de la ontología SUMO en el editor de ontologías Protégé
La Figura VI.6 presenta algunas características generales de la ontología definida,
denominada PRONTO (PRoduct ONTOlogy), obtenidas a partir del la versión 4 beta del
editor Protégé. En particular, se indican cuales son las ontologías importadas y la
expresividad de la lógica descriptiva utilizada para la definición de los conceptos, así como
el dialecto de OWL empleado en cada ontología involucrada.
206
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
Expresividad de
la ontología
Ontologías importadas por PRONTO
Dialectos en los que se
encuentra definido PRONTO y
las ontologías importadas
Figura VI.6. Información brindada por Protégé 4 beta acerca de PRONTO
Es posible observar en la Figura VI.6 que el documento owl que define PRONTO
(http://www.owl-ontologies.com/pronto.owl)
importa
las
ontologías
definidas
en:
http://www.owl-ontologies.com/catalogo.owl y http://owl-ontologies.com/sumo.owl. Ambas
ontologías se encuentran definidas en OWL-lite, mientras que PRONTO está representada
por OWL-DL, con una expresividad indicada como SOIF. Cada una de las letras presentes
en dicha etiqueta representa un constructor (o un conjunto de constructores) de la lógica
descriptiva que la ontología incorpora. El significado de cada una de ellas se muestra en la
Tabla VI.2.
Tabla VI.2. Expresividad de la ontología
Código
Constructor/es incluido/s
Negación de conceptos atómicos y complejos
Intersección de conceptos
S
Restricciones universales
Cuantificación existencial limitada
Propiedades transitivas
O
Clases enumeradas o restricción de valores de
objetos (owl: oneOf o owl:hasValue)
I
Propiedades inversas
F
Propiedades funcionales
207
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
Respecto a la definición de los conceptos de PRONTO, su organización taxonómica
se presenta en la Figura VI.7, en la cual se puede apreciar que se han incluido los
conceptos que se originan a partir de AbstraccióndeProductos, más todos los que permiten
expresar estructuras de productos complejos y manejo de restricciones. Se observan las
clases y las relaciones de tipo “is-a” que definen la jerarquía entre conceptos. El sombreado
más claro identifica clases primitivas, mientras que el más oscuro corresponde a las
denominadas clases no primitivas. Todas aquellas clases especificadas como instancias de
Class en el Capítulo III se definieron como clases primitivas en PRONTO. Por su parte, las
vistas y consultas que fueron introducidas en dicho capítulo (FamiliasEnsambladas y
FamiliasDerivadas, por ejemplo), se implementaron como clases no primitivas. Se puede
apreciar en la Figura VI.7 que PRONTO incorpora nuevas clases no primitivas, como el
concepto de MateriaPrima, el cual no se definió explícitamente en el modelo desarrollado
en el Capítulo III. Dicho concepto, en el contexto de un sitio de producción, representa todas
aquellas familias que no son manufacturadas en ese sitio y, por lo tanto, deben ser provistas
por otros. El sitio en cuestión no posee conocimiento acerca de la estructura de las familias
que se infieren como MateriaPrima en él.
El código completo de la ontología, el cual contiene los axiomas de clases y
propiedades que pertenecen a PRONTO, se presenta en el Apéndice B. A modo de ejemplo,
en las figuras VI.8 y VI.9, se introducen las clases FamiliaC y FamiliaEnsamblada,
respectivamente. En ambos casos, se muestra una porción de código OWL que
corresponde al axioma de clase que la define.
208
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
Figura VI.7. Taxonomía de PRONTO
En la Figura VI.8 se presenta la definición de la clase FamiliaC. Puede observarse en
dicha figura la pantalla del editor de ontologías que muestra el cuadro “asserted conditions”,
en el cual se ingresan las condiciones necesarias y suficientes, así como las necesarias (las
209
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
definidas en la propia clase y aquéllas heredadas) que debe cumplir un individuo que es
instancia de FamiliaC, el cual necesita ser miembro de la clase Familia y poseer al menos
una Estructura asociada por la propiedad estructuraDe (owl:sameValuesFrom). Además,
todos los individuos que estén como valores de dicha propiedad deben ser instancias de
Estructura (owl:allValuesFrom). Cada una de estas condiciones está expresada en el código
OWL mediante un axioma de clase del tipo rdf:subClassOf (ver Apéndice B). Como puede
observarse, FamiliaC está especificada solamente por condiciones necesarias, en
consecuencia, se trata de una clase primitiva.
Por otra parte, la sección inferior de la pantalla que se muestra en la Figura VI.8
indica que FamiliaS es disjunta respecto a FamiliaC, es decir, que la intersección de los
conjuntos extensión de ambas clases es el conjunto vacío. En otras palabras, no existen
individuos que sean instancias de ambas clases.
<owl:Class rdf:ID="FamiliaC">
<rdfs:subClassOf rdf:resource="#Familia"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#estructuraDe"/>
<owl:someValuesFrom rdf:resource="#Estructura"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#estructuraDe"/>
<owl:allValuesFrom rdf:resource="#Estructura"/>
</owl:Restriction>
</rdfs:subclase
<owl:disjointWith rdf:resource="#FamiliaS"/>
</owl:Class>
Figura VI.8. Axioma de clase de FamiliaC
En la Figura VI.9 se presenta la especificación de la clase FamiliaEnsamblada, la
cual es de tipo no primitiva y su definición incluye tres axiomas de clase que definen
restricciones necesarias y suficientes. Estos axiomas implican que todo individuo que
pertenezca a la extensión de clase de Familia,
tenga el valor Falso para la propiedad esDerivado y, además
tenga el valor Verdadero para la propiedad esEnsamblado
210
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
será instancia de FamiliaEnsamblada.
El código OWL que se muestra en la Figura VI.9 presenta el axioma de clase de
FamiliaEnsamblada, el cual combina varias descripciones de clase. En particular, dicho
axioma especifica que el conjunto de instancias de FamiliaEnsamblada es equivalente
(owl:equivalentClass) a la extensión de una clase anónima que se define por la intersección
(owl:intersectionOf) de dos restricciones (owl:Restriction) de propiedad (owl:onProperty). La
primera restricción indica que la propiedad esDerivado debe tener (owl:hasvalue) el valor
Falso (False) y la otra que esEnsamblado debe poseer valor Verdadero (True). Además, se
indica que el conjunto de instancias de FamiliaEnsamblada, es disjunto respecto a las
extensiones de clase de FamiliaDerivada y MateriaPrima. El axioma de clase que permite
definir esta última es similar al presentado en la Figura VI.9. La diferencia radica en que,
para MateriaPrima, las restricciones imponen el valor Falso para ambas propiedades
(esEnsamblado y esDerivado). (Por más detalles se sugiere consultar el Apéndice B)
<owl:Class rdf:ID="FamiliaEnsamblada">
<owl:equivalentClass>
<owl:Class>
<owl:intersectionOf rdf:parseType="Collection">
<owl:Restriction>
<owl:onProperty rdf:resource="#esDerivada"/>
<owl:hasValue rdf:resource="#False"/>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#esEnsamblada"/>
<owl:hasValue rdf:resource="#True"/>
</owl:Restriction>
<owl:Class rdf:about="#Familia"/>
</owl:intersectionOf>
</owl:Class>
</owl:equivalentClass>
<owl:disjointWith rdf:resource="#FamiliaDerivada"/>
<owl:disjointWith rdf:resource="#MateriaPrima"/>
</owl:Class>
Figura VI.9. Axioma de clase correspondiente a FamiliaEnsamblada
Como puede apreciarse en la Figura VI.7 otras clases definidas que fueron creadas
son:
FamiliaDerivada,
MateriaPrima,
RestricciónIncomp,
RestricciónOblig,
RelaciónSelectiva, RelaciónOptativa, RelaciónObligatoria, TipoRestricción y TipoRelación.
Las dos últimas, corresponden a la aplicación de un patrón de diseño denominado partición
de valores (ValuePartition, su nombre en inglés). Los patrones en ontologías son análogos a
los utilizados en el diseño bajo un enfoque de objetos (Horridge y colab., 2004).
Este patrón permite restringir los valores que puede tomar una propiedad a las
instancias de un conjunto exhaustivo de clases. Para lograr este cometido se debe:
1. Crear la clase que representa la partición, por ejemplo TipoRelación.
211
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
2. Crear las subclases que representan las distintas opciones para la partición y
definirlas como disjuntas. En este ejemplo, se crean las clases Obligatoria,
Optativa y Selectiva, como puede verse en la Figura VI.10, Ventana (A).
3. Crear un axioma de cobertura en la clase que representa la partición. Ver
Figura VI.10, Ventana (B).
4. Asignar como rango de la propiedad a restringir la clase que representa la
partición.
El axioma de cobertura para este ejemplo, se define a través de una restricción sobre
la clase TipoRelación que indica que dicha clase es la unión de las clases Obligatoria,
Optativa y Selectiva y en consecuencia, no existe explícitamente ni puede ser inferido como
instancia de TipoRelación, ningún individuo que no pertenezca a la extensión de alguna de
las subclases definidas de TipoRelación (Obligatoria, Optativa, Selectiva). Es necesario
incluir este axioma debido a la hipótesis de mundo abierto que es inherente a OWL.
<owl:Class rdf:ID="TipoRelacion">
<owl:equivalentClass>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Obligatoria"/>
<owl:Class rdf:about="#Optativa"/>
<owl:Class rdf:about="#Selectiva"/>
</owl:unionOf>
</owl:Class>
</owl:equivalentClass>
(B)
</owl:Class>
<owl:Class rdf:ID="Selectiva">
<rdfs:subClassOf rdf:resource="#TipoRelacion"/>
<owl:disjointWith rdf:resource="#Obligatoria"/>
<owl:disjointWith rdf:resource="#Optativa"/>
</owl:Class>
(A)
Figura VI.10. Definición de una partición de valores
Para la representación de la información de productos de cada nodo del escenario
planteado se crearon cuatro nuevas ontologías, denominadas candiessiteA, candiessiteB,
candiessiteC y candiessiteD. Todas ellas importan PRONTO y crean las instancias
correspondientes a los productos que las Empresas A, B, C y D, respectivamente proveen.
Las relaciones entre las ontologías utilizadas se muestran en la Figura VI.11. Allí puede
observarse que las ontologías SUMO y catalogo.owl son importadas por PRONTO. y ésta a
su vez es importada por cada una de las cuatro ontologías de empresa definidas. La
ontología catalogo.owl corresponde a la representación parcial, que fue definida localmente,
de una parte de eclassOWL (Hepp, 2004).
212
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
«import»
«file»
SUMO
«file»
candiessiteA.ow l
«import»
«file»
«file»
«import»
PRONTO
«import»
«import»
«import»
«file»
candiessiteB.ow l
«file»
catalogo.ow l
«file»
candiessiteC.ow l
candiessiteD.ow l
Figura IV.11. Relaciones entre las ontologías utilizadas
Para la ontología candiessiteA.owl, se crearon instancias para representar los
productos del nivel de caramelo envuelto (Figura VI.12). Con esta figura se pretende mostrar
cómo un razonador clasifica estos individuos de acuerdo a las definiciones dadas para las
clases no primitivas. En particular, se muestran los browser de instancias para las clases
FamiliaC, FamiliaEnsamblada y MateriaPrima.
Después de aplicar el razonador
Figura VI.12. Clasificación de instancias efectuada con un razonador
213
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
En la parte superior de la Figura
VI.12 se observa, para las clases
FamiliasEnsambladas y MateriaPrima, las dos secciones que tiene dicho browser, la de
hechos explicitados (“Asserted”) y la de hechos inferidos (“Inferred”), antes de ejecutar el
razonador para la clasificación de individuos. En la parte inferior se exponen nuevamente la
sección de hechos inferidos para las tres clases mencionadas después de haber ejecutado
la clasificación de individuos en el razonador. Es posible apreciar, que ocho de las familias
cargadas fueron clasificadas como pertenecientes a la categoría FamiliaEnsamblada y el
resto fueron identificadas como MateriaPrima.
VI.4.2. Definición de una arquitectura para integrar información de productos
Para administrar la información de productos en una red de colaboración de
empresas de producción se definió una arquitectura integrada semánticamente a partir del
empleo de PRONTO. La arquitectura propuesta es del tipo mediador y está constituida por
un conjunto de nodos jerárquicamente equivalentes, uno por cada planta de producción
(cuatro en el escenario planteado). Cuando un usuario realiza una consulta desde uno de
los nodos éste se convierte en mediador entre el usuario y el resto de los nodos. La Figura
VI.13 presenta los componentes que conforman esta arquitectura.
Interface
Interface
Servicio de
Consultas Local
Nodo EmpresaA
Servicio de
Consultas Local
Servicio de
Consultas Global
Nodo EmpresaB
Servicio de
Consultas Global
Servicios de Red
Joseki
Consulta
SPARQL
JENA
Inferencia
OWL API
JENA
Ontología
candiessiteB.owl
Lectura/ Escritura
RDF API
Ontología
candiessiteA.owl
Ontología
candiessiteD.owl
Ontología
candiessiteC.owl
JENA
Servicio de
Consultas Local
Interface
Servicio de
Consultas Global
JENA
Servicio de
Consultas Local
Interface
Servicio de
Consultas Global
Nodo EmpresaD
Nodo EmpresaC
Figura VI.13. Arquitectura propuesta para una red colaborativa de empresas de
producción
En cada nodo se encuentra instalado el framework JENA, el cual mediante sus
componentes (Joseki, SPARQL, OWL API, RDF API, que se muestran en la Figura VI.13),
214
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
brinda el soporte tecnológico para la publicación y observación de las ontologías, así como
para la construcción de las consultas. Además, cada nodo de la arquitectura consta de:
Una interface que debe ser accedida por un navegador y que permite al
usuario seleccionar la consulta que desea realizar.
Una ontología que define las instancias del repositorio de información sobre el
que se realizan las consultas.
Un servicio de consultas local (LQC - LocalQueryService), que recibe los
requerimientos desde la interface, obtiene información del servicio SPARQL
local y delega la consulta en el servicio global de consultas (GQS GlobalQueryService).
Un servicio de consultas global (GQS - GlobalQueryService) que construye la
consulta en lenguaje SPARQL y la propaga hacia los nodos que pueden
responderla. A partir de la combinación de las respuestas recibidas, analiza si
ya cuenta con toda la información para dar una respuesta al usuario o si debe
volver a propagar consultas hacia los nodos.
Un nodo puede llevar a cabo dos roles principales: proveedor y explorador. Un nodo
actúa como proveedor cuando publica información acerca de los productos que tiene
almacenados localmente. En tanto que ejecuta su rol explorador cada vez que busca
información de un determinado producto (Bonifacio, 2006). La estructura de cada nodo se
presenta en la Figura VI.14. Allí puede observarse al nodo EA, su ontología local,
denominada candiessiteA.owl, y las actividades (indicadas por los círculos con números)
que se llevan a cabo cuando dicho nodo recibe una consulta, que se detallan en los
siguientes párrafos.
candiessiteA.owl
P
R
O
V
E
E
D
O
R
2
3
E
X
P
L
O
R
A
D
O
R
4
1
Consulta
5
7
?
8
+
EX
6
EA-GQS
Respuesta
EA
Otros Nodos de
la arquitectura
Figura VI.14. Roles que pueden adoptar los nodos de la arquitectura propuesta
215
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
Un nodo que actúa como explorador permite la búsqueda de información de
productos en otros nodos ya que provee el mecanismo para encontrar otras fuentes de
información a los cuales una consulta debe ser reenviada y lleva a cabo la propagación de
las consultas hacia ellas.
Por su parte, un nodo que actúa como proveedor contiene las funcionalidades
requeridas para resolver una consulta e identificar los resultados que deben ser devueltos a
los exploradores. Cuando un nodo proveedor recibe una consulta, trata de resolverla de
manera local. Si encuentra que la información que posee es incompleta, cambia su rol a
explorador y propaga la consulta a los nodos que pueden brindarle la información faltante.
Una vez recibidas las respuestas a las consultas que ha propagado, retoma el rol de
proveedor para combinarlas en una única expresión que se retorna al usuario. El
intercambio de mensajes que se produce entre los componentes de la arquitectura cuando
una consulta es ejecutada desde uno de los nodos se presenta en la Figura VI.15.
EA-LQS
:LocalQueryService
EA-GQS
:GlobalConfigurationServices
EX -GQS
:GlobalQueryService
:GlobalQueryService
modelo :Model
modelo= getCompleteProductModel(urlService,P1)
1
consulta
boolean= fabrica(urlService,P1)
2
conocidos= getKnownComponents(urlService,P1)
3
desconocidos= getUnknownComponents(urlService,P1)
modelo= getCompleteKnownModel(urlService,conocidos)
7
4
loop Por cada desconocido
servicios= getServicesForProduct(desconocidos[i])
5
loop Por cada serv icio
descModelo= getCompleteProductModel(servicios[j],desconocido[i])
Add(descModelo)
6
respuesta
8
Figura VI.15. Diagrama de secuencias correspondiente a una consulta sobre
estructuras
Las actividades presentadas esquemáticamente en las Figuras VI.14 y VI.15, que
expresan los pasos del proceso de ejecución de una consulta, son los siguientes:
216
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
1. Se hace la consulta a un nodo determinado (EA) acerca de la estructura
de una familia determinada (CarameloFrutaEnv). El servicio de consultas
local (EA-LQS) recibe la consulta desde la interface y la delega en el
Servicio de Consultas Global del nodo (EA-GQS).
2. EA-GQS analiza si posee información local sobre la estructura de
CarameloFrutaEnv.
3. Si EA-GQS posee información, identifica cuales son los componentes de
CarameloFrutaEnv para los que conoce la estructura y aquéllos para los
cuales no la conoce (lista de conocidos y desconocidos respectivamente)
4. Para cada familia perteneciente al conjunto de conocidos (por ejemplo
CarameloFrutaDes), obtiene el modelo inferido a partir de las definiciones
de la ontología (candiessiteA.owl).
5. Para cada familia perteneciente al conjunto de desconocidos, inicia
consultas remotas en cada GQS disponible (uno en cada nodo) acerca de
la estructura de dicha familia.
6.
Los modelos recibidos como respuestas (descModelo) se combinan con
el modelo local para ir construyendo las respuestas (modelo).
7. Si permanece alguna familia en la lista de desconocidos se vuelve al paso
4.
8. Se entrega la respuesta (modelo) al LQS que disparó la consulta y éste la
reenvía a la interface.
La decisión de si una familia es conocida o desconocida para un nodo determinado
descansa en el concepto MateriaPrima. Todas aquellas familias que son inferidas en cada
ontología local como MateriaPrima (no son ni FamiliaEnsamblada y ni FamiliaDerivada)
corresponden a familias desconocidas.
En cuanto a la interfaz que el sistema presenta al usuario, la cual se observa en la
Figura IV.16, ésta debe ser accedida mediante un navegador indicando el URL (Uniform
Resource Locutor) donde se está ejecutando el servicio. En la figura puede apreciarse un
inicio de sesión en la aplicación en el nodo EA. Los elementos de la interface son muy
simples: i) un control que permite seleccionar de una lista la familia para la cual se requiere
información (CarameloFrutaEnv en este caso) y ii) dos botones que permiten obtener para
dicha familia su estructura multinivel (botón Consultar) o su “lead time” (botón Cálculo Lead
Time).
217
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
Calcula sólo “lead
time“del producto
seleccionado
Calcula jerarquía
Estructural del producto
seleccionado
Figura VI.16. Interfaz de la aplicación ejecutándose en el nodo A
La Figura VI.17 presenta la respuesta que se obtiene al presionar el botón Consultar
para la selección de CarameloFrutaEnv. Dicha respuesta corresponde al primer nivel del
árbol de estructura de la familia. Se observan algunas propiedades que están definidas en la
ontología, a saber
Nombre Catálogo: Corresponde al URI que identifica la categoría definida
para dicha familia en la ontología catalogo.owl.
Nombre local: corresponde al identificador de la familia en la ontología local.
En dicho nombre, figura cuál es la ontología en la que se encuentra definido
ese recurso (candiessiteA.owl). A partir de dicha ontología, puede ser inferida
la organización que provee la Familia en cuestión.
“Lead time” relativo: indica el tiempo que demanda el ensamblado de sus
componentes. Esta propiedad, si bien no fue definida en el modelo
conceptual, se incorporó a la ontología PRONTO con el fin de verificar que
otro tipo de información de productos, más allá de las relaciones de
estructura, puede ser manipulado por la aplicación.
Componentes: en caso que la familia sea una FamiliaC, expandiendo esta
rama es posible acceder a la información de cada uno de sus componentes.
Figura VI.17. Primer nivel de la jerarquía estructural de CarameloFrutaEnv
218
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
En el escenario planteado, los componentes de una familia podrían ser suministrados
por más de un proveedor, con lo cual al momento de propagar la consulta sobre un
componente, es posible que se obtenga más de un respuesta para ésta. La cantidad de
respuestas se refleja en la cantidad de ramas etiquetadas con “Alternativa x” (con x entre 1
y N), que dependen de un componente dado y representan las N posibles formas de
obtenerlo. Estas formas podrían representar diferentes estructuras y/o distintos proveedores.
En la Figura VI.18 se muestran, señalados con un óvalo, los componentes de
CarameloFrutaEnv: PapelEnvoltorio, CarameloFrutaDes y PapelSeparador. Las ramas
correspondientes a los dos primeros se han expandido para mostrar su información. En
ambos casos puede observarse la existencia de una única alternativa (ramas etiquetadas
como Alternativa1).
En la información que se muestra para PapelEnvoltorio se aprecia que, además de
los datos que se explicaron para CarameloFrutaEnv, se presenta un atributo denominado
Cantidad Requerida que corresponde a la cantidad de composición asociada a la relación
entre CarameloFrutaEnv y el correspondiente componente. PapelEnvoltorio es una familia
simple, por lo tanto no tiene componentes. Los mismos datos se exponen para
CarameloFrutaDes; pero como se trata de un producto con estructura, tiene dos
componentes, MasaCAcido y RellenoFrutal, que se muestran también en la Figura VI.18.
Ontología donde está
definido PapelEnvoltorio
Indica alternativas posibles para
obtener el componente
PapelEnvoltorio
PapelEnvoltorio se
obtiene en 1.0 días
Se requiere 30.87 GR de
PapelEnvoltorio
Componentes de
CarameloFrutaDes
Figura VI.18. Expansión de una de las ramas de la estructura de CarameloFrutaEnv
En párrafos anteriores, se mencionó que los miembros de una familia pueden ser
provistos por más de un nodo de la red. Un ejemplo de esta situación se presenta con la
219
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
familia Ácido (uno de los componentes de MasaCAcido), el cual según la Tabla VI.1, es
provisto tanto por la Empresa C como por la Empresa D. Estas dos alternativas se pueden
observar en la Figura VI.19, donde puede inferirse que las mismas involucran diferentes
“lead times” para la provisión de la familia mencionada.
Ácido puede ser
provisto por
Empresa D con un
lead time de 3.0
Ácido puede ser
provisto por
Empresa C con un
lead time de 4.1
Figura VI.19. Alternativas para la obtención de un componente
El objetivo de la implementación de este prototipo ha sido poner a prueba la
factibilidad de una arquitectura para integrar información de productos entre participantes de
una cadena de colaboración, utilizando la ontología propuesta y tecnología de la Web
Semántica. Naturalmente, se trata de un caso muy simple que ha tratado de probar el
concepto, pero que necesariamente se deberá expandir en el futuro para considerar
diferentes requerimientos.
VI.5. CONCLUSIONES
En este capítulo se ha abordado la problemática asociada a una integración
inteligente de los sistemas de información, pertenecientes a una o varias organizaciones,
que trabajan de manera colaborativa, habiéndose planteado los inconvenientes ocasionados
por los diferentes tipos de heterogeneidad existentes entre ellos. Se ha concluido que una
integración integral impone la necesidad de lograr una interoperabilidad a nivel semántico.
Uno de los enfoques propuestos en la literatura para alcanzarla sugiere la definición de
ontologías, y su empleo de éstas en aplicaciones de la Web Semántica. Esta ha sido,
entonces, la orientación adoptada. A efectos de probar la factibilidad de esta propuesta se
efectúo:
220
____________________________ Uso del Modelo Propuesto en una Aplicación Basada en la Web Semántica
La implementación de una ontología de productos, denominada PRONTO,
que permite el uso de un vocabulario común para la representación de
información estructural de productos.
El desarrollo de un prototipo de aplicación que utiliza tecnología de la Web
Semántica para alcanzar la integración de información de productos a través
de un mecanismo de propagación de consultas entre nodos pares.
Tanto la ontología como el prototipo constituyen el resultado de una primera etapa
hacia la definición de un sistema PDM basado en la Web Semántica. En las siguientes
etapas de este proceso se abren dos líneas de trabajo:
Evolución de las ontologías: que abarca, por un lado, la incorporación a
PRONTO de nuevos conceptos relacionados con información no estructural
de productos y, por otro, su vinculación con la ontología SCOntology (Gonnet
y colab., 2007; Vegetti y colab., 2005b; Vegetti y colab., 2005c), la cual
provee la definición de conceptos relacionados con la gestión de las cadenas
de suministros.
Por otra parte, se debe analizar la definición de ontologías locales para
representar la información de productos particular a cada nodo de la red de
colaboración, las cuales deberán ser mapeadas con PRONTO.
Evolución de la aplicación: mediante la implementación incremental de
prototipos se pretende ir agregando funcionalidades al sistema y/o haciendo
más eficientes las existentes. En lo inmediato, se analizará la manera de
implementar un servicio de descubrimiento de nodos eficiente, por un lado y,
por otro, se tratará de resolver el problema de cómo la información de
productos gestionada por los sistemas de productos locales y almacenada en
diferentes formatos (tablas relacionales, archivos de texto o XML, bases de
datos orientadas a objetos), se mapean con instancias de las ontologías de
empresas.
221
VII. CONCLUSIONES FINALES Y FUTUROS TRABAJOS
VII.1. INTRODUCCIÓN
El presente capítulo tiene por objetivo resaltar las principales contribuciones de esta
Tesis, así como exponer las líneas de investigación que se abren a partir de los resultados
obtenidos.
VII.2. PRINCIPALES CONTRIBUCIONES
En las últimas décadas, las empresas de producción industrial han incrementado
significativamente el número de productos que entregan al mercado. El avance progresivo
de la tecnología ha afectado a los diferentes productos, en cuanto al número de variantes de
los mismos, su complejidad y el acortamiento de su ciclo de vida. Es por ello, que la forma
de representar (y almacenar) la información sobre los productos ha evolucionado para ir
adaptándose a estos cambios. En los últimos años, debido al acelerado avance de las
tecnologías de la información y las comunicaciones (TICs), estas transformaciones han sido
más importantes y complejas, y por lo tanto emerge la necesidad de contar con un modelo
de productos más eficiente, que además contemple los nuevos requerimientos impuestos
por estos avances.
Por otra parte, como se expuso en el Capítulo II, el modelo de productos de una
empresa se encuentra influenciado por la rama industrial a la que pertenece dicha
organización. En consecuencia, el conocimiento que deben representar estos modelos es
muy heterogéneo y está determinado por la naturaleza de los productos que cada industria
manufactura, y por el tipo de proceso productivo que emplea. Sin embargo, existe un
denominador común entre todos ellos, el cual está relacionado con la necesidad de
representar la forma en que los productos son elaborados. Esto es, su estructura, la cual
determina cómo las materias primas se transforman en semielaborados y éstos en
productos finales.
La influencia de las TICs y las particularidades de cada industria sobre las formas de
representar la información acerca de los productos, ha llevado a la necesidad de contar con
un modelo que posibilite la representación eficiente de:
estructuras de productos que posean un gran número de variantes;
221
____________________________________________________ Conclusiones Finales y Futuros Trabajos
productos con diferentes tipos de estructuras (descomposición, composición e
híbridas) y/o con estructuras alternativas; así como
distintas vistas de la estructura, de acuerdo a los requerimientos de diversas
unidades organizacionales.
Como respuesta a esta necesidad, el principal aporte de esta Tesis es la definición
de un modelo de productos que se centra en la información estructural de los mismos y que
brinda una solución a las exigencias antes mencionadas. Ello se logra mediante la
formalización del conocimiento a través de la integración de dos jerarquías que pueden
definirse para organizar la información relacionada con los productos, la jerarquía de
abstracción (AH) y la jerarquía estructural (SH).
La AH establece tres niveles de abstracción diferentes para la definición de
productos: Familia, Conjunto de Variantes y Producto. Esta jerarquía utiliza mecanismos
para mantener la consistencia de la información estructural entre los distintos niveles de
agregación. Además, podrían gestionarse a nivel de Familia o de Conjunto de Variantes
datos como demanda agregada, “lead time” agregado o costos agregados, los cuales no
necesariamente deberían estar almacenados sino que podrían ser calculados a través de
algoritmos que hagan uso de procesos de inferencia que empleen información del nivel más
bajo de la jerarquía (Producto). Contar con este tipo de información permite una gestión
adecuada de la información requerida en los procesos de toma de decisiones estratégicotácticos.
Por otra parte, la SH organiza el conocimiento relacionado con la información
estructural de los productos. Es una herramienta para manejar la información asociada con
las múltiples recetas o procesos disponibles para manufacturar un determinado producto o
grupo de productos similares. En cada uno de los niveles propuestos para la AH, la SH
define las relaciones que se establecen entre materias primas, semielaborados y productos
finales que participan en una estructura. Dichas relaciones se representan en el modelo por
el atributo componente, cuyos valores son inferidos de manera diferente en cada nivel. En
las entidades del nivel Familia dicho atributo infiere sus valores a partir de las clases
Estructura y Relación. En tanto que las clases Preselección y Selección permiten la
inferencia de los componentes en los niveles Conjunto de Variantes y Producto,
respectivamente. Una vista integral del modelo propuesto se presenta en la Figura VII.1, en
la cual pueden observarse las clases definidas para representar la información de productos
en cada uno de los niveles mencionados.
La Familia es el nivel más abstracto y define la información común a todos sus
miembros, los Conjuntos de Variantes. Cada familia, puede tener asociada más de una
222
____________________________________________________ Conclusiones Finales y Futuros Trabajos
estructura (estructuras alternativas), permitiendo así la definición de productos con múltiples
recetas de producción.
<<AP>>
<<AP>>
AbstraccionDeProducto
AbstraccióndeProducto
<<FS>>
FamiliaS
derivado
componente derivado
componente
<<F>>
Familia
<<FC>>
FamiliaC
estructuraDe
<<E>>
Estructura
<<RF>>
RestricciónF
<<RD>>
RelaciónD
<<ED>>
EstructuraD
<<RC>>
RelaciónC
<<EC>>
EstructuraC
estructuraAlternativa
tipoRelación
<<TR>>
TipoRelación
quantityPer
<<R>>
Relación prodFactor
max
<<VR>>
min
ValorRestringido
<<TR>>
<<Op>>
Optativa
Optativa
<<TR>>
<<Ob>>
Obligatoria
Obligatoria
<<TR>>
<<S>>
Selectiva
Selectiva
valor
<<
Presel>> preselecciona
<<Presel>>
Preseleccion
Preselección
Conjunto
Seleccionado
miembroDe
modificaciónAplicada
<<M>>
<<M>>
Modificacion
Modificación
<<Elim>>
Eliminación
Producto
<<RP>>
RestricciónP
<<U>>
Unidad
derivaDe
<<SVS>>
ConjuntodeVariantesS
miembroDe
miembroD
e <<P>>
<<UV>>
<<VU>>
ValorUnidad
ValorUnidad udeM
<<CVC>>
ConjuntodeVariantesC
<<CV>>
ConjuntodeVariantes
<<RCV>>
RestricciónCV
<<Num>>
<<Num>>
Numero
Número
nuevoQP
cambioAplicado
<<C>>
Cambio
relaciónModificada
<<Sele>>
<<SelFam>>
SelecciónFamilia
SelecciónFamilia
<<CC>>
CambioC
nuevoPF
<<Cpf>>
<<CPF>>
CambioPF
CambioPF
<<Cqp>>
<<CQP>>
CambioQP
CambioQP
<<PS>>
ProductoS
selecciona
<<PC>>
ProductoC
<< sele>>
Selección
Figura VII.1. Modelo de productos propuesto
A diferencia de las propuestas existentes, el modelo presentado posibilita la
representación de productos que se obtienen por ensamblado de partes, así como
productos pertenecientes a industrias que emplean materias primas no atómicas y las
descomponen o desagregan; es decir, a partir de las cuales se obtienen productos
intermedios que ingresan, luego, en el proceso productivo. Para lograr esto, el modelo
223
____________________________________________________ Conclusiones Finales y Futuros Trabajos
define dos tipos de estructuras (EstructuraC y EstructuraD), así como dos tipos de
relaciones (RelacionC y RelacionD).
En el nivel intermedio, denominado Conjunto de Variantes, se especifican
subconjuntos de miembros de una Familia, a partir de aspectos diferenciadores que los
distinguen unos de otros. Para el caso de familias compuestas, las diferentes estructuras
constituyen el punto a partir del cual se hace la separación de los distintos Conjuntos de
Variantes Compuestas. Para las familias simples, esta separación se puede dar de acuerdo
a varios criterios que están fuera del alcance de la Tesis.
Cada Conjunto de Variantes Compuestas plantea una estructura diferente, ya sea en
términos de modificaciones sobre la estructura de la familia que tiene asociada o, por medio
de la Preselección de Conjuntos de Variantes diferentes para cada uno de sus
componentes. Una Modificación define un conjunto de cambios, que pueden determinar la
eliminación de un componente o la alteración parcial de la cantidad de composición de
alguna relación, así como la elección de una de las relaciones selectivas (si existieran) de la
estructura que es modificada.
El último nivel propuesto, Producto, define los miembros de un Conjunto de Variantes
y corresponde a productos con existencia física real. Una instancia de Producto infiere su
estructura a partir de la definida para el Conjunto de Variantes del que es miembro. En este
nivel no se hacen modificaciones estructurales, sino que se definen aquéllos componentes
que aún no hubiesen sido especificados.
La propuesta incorpora el concepto de Restricción, el cual impide la derivación de
estructuras
de
productos
inválidas.
Esta
es
una
característica
importante
para
representaciones de productos en las cuales las especificaciones de los clientes tienen
influencia sobre el producto que se va a producir. De esta manera se evita que el cliente
requiera configuraciones incorrectas de productos. El modelo incorpora este concepto de
dos formas: i) explícitamente, a través de la definición de la clase Restricción, la cual permite
la especificación de restricciones tanto de incompatibilidad como de obligatoriedad entre las
relaciones que pueden establecerse entre entidades de un mismo nivel; y ii) de manera
implícita, al establecerse los límites mínimos y máximos a los valores de los atributos
quantityPer y prodFactor, que controlan los cambios que pueden hacerse a estos valores en
los diferentes conjuntos de variantes que se definen.
Las propuestas que han podido relevarse en la literatura ejemplifican los modelos
planteados mediante la aplicación de los mismos en situaciones o escenarios ficticios, que
no presentan la complejidad real que se debe administrar en los ámbitos productivos. A
diferencia de éstas, el modelo desarrollado en esta Tesis fue empleado con éxito en la
representación de los productos de dos empresas reales: una planta de golosinas y un
224
____________________________________________________ Conclusiones Finales y Futuros Trabajos
frigorífico. En el primer caso, se presenta una gran cantidad de productos con estructuras de
composición, y en el segundo, además del gran número de variantes, coexisten productos
que poseen estructuras de composición, descomposición e híbridas. En cualquiera de las
dos situaciones, el modelo fue aplicado de manera similar. Esto demuestra que éste es lo
suficientemente genérico como para representar información estructural de productos en
diferentes tipos de industria.
La adopción de la tecnología de objetos para la representación del modelo brindó
una herramienta flexible que ha permitido incorporar naturalmente cambios al mismo y dejar
explícitamente indicados sus puntos de extensión. Así, por ejemplo, podría adicionarse
información de utilidad para la función de planificación, relacionada con los pronósticos y
valores actuales de las demandas, proveedores y tiempos de entrega. También, podría
interesar mantener almacenados como parte del modelo algunos de los datos logísticos y
comerciales (tales como cubo logístico, condiciones de almacenamiento y transporte, etc.),
que generalmente son administrados por el área de Desarrollo de Productos, o los
parámetros correspondientes a las distintas políticas de abastecimiento y/o producción.
Asimismo, resultaría apropiado disponer de información que permita mantener la
trazabilidad.
Por otra parte, el modelo integrado que se propuso utilizando O-Telos como
lenguaje de formalización, provee un vocabulario común para la definición de estructuras de
productos y especifica la semántica de cada término de manera no ambigua, a través de la
lógica de predicados de primer orden. La implementación en ConceptBase de este modelo
permitió verificar la consistencia de la propuesta y posibilita la ulterior extensión del mismo
mediante la incorporación de atributos a las distintas clases y la inferencia de sus valores a
través de reglas.
Asimismo, a través del desarrollo del prototipo presentado en el Capítulo V, se
verificó la factibilidad del diseño e implementación de un sistema de procesamiento de
BOMs que se sustente en el modelo propuesto. Dicho prototipo posee gran flexibilidad de
adaptación a los cambios en virtud a la forma en que fue implementado. Otra característica
importante de la aplicación radica en que permite la incorporación de módulos adicionales,
con nuevas funcionalidades que den soporte a la integración entre tareas de planificación
con diferentes horizontes de tiempo (planificaciones estratégicas, tácticas y operativas),
debido a que especifica las dos jerarquías propuestas, de abstracción y estructural. Por otra
parte, permite el acceso de múltiples usuarios a través de navegadores de uso común y
desde sitios remotos a una única base de conocimientos. Este enfoque no posee la
suficiente flexibilidad para alcanzar la integración de la información de productos requerida
por la estrategia de manufactura colaborativa que actualmente están tratando de
implementar las empresas.
225
____________________________________________________ Conclusiones Finales y Futuros Trabajos
El Capítulo VI presenta una solución a este problema, permitiendo la distribución de
la información de productos en cada nodo participante de una cadena de colaboración, pero
manteniendo una integración semántica de la misma. Para ello, el modelo conceptual
propuesto en el Capítulo III, funda las bases para la definición de una ontología que permite
la integración semántica de la información que es gestionada y almacenada por los sistemas
de información de productos de cada organización.
Puntualmente, las principales contribuciones de esta Tesis son:
La definición de un modelo conceptual de productos que:
o
Formaliza el conocimiento acerca de los productos mediante la
integración de las jerarquías de abstracción y estructural.
o
Enfatiza la información estructural de los productos como núcleo de un
modelo de productos que puede ser extendido para incorporar
información no estructural.
o
Incorpora e integra los conceptos de familia de productos y BOMs
generativos para la representación eficiente de estructuras de
productos con un gran número de variantes.
o
Posibilita la representación de productos con diferentes tipos de
estructuras y de productos que poseen estructuras alternativas.
o
Limita la derivación de estructuras de productos inválidas por medio
de la aplicación del concepto de Restricción.
La representación del modelo a partir de una especificación que integra
tecnología de objetos y lógica de predicados de primer orden en el
lenguaje O-Telos y la construcción de una base de conocimientos en la
base de objetos deductiva ConceptBase, la cual permite:
o
Aplicar restricciones a la interpretación de los conceptos propuestos
en el modelo.
o
Extender el modelo con conceptos específicos de un tipo determinado
de industria.
o
Responder consultas sobre las estructuras de productos que pueden
derivarse.
o
Inferir nueva información a partir de lo explícitamente representado.
226
____________________________________________________ Conclusiones Finales y Futuros Trabajos
La definición de una ontología de productos, denominada PRONTO, que:
o
Especifica un vocabulario común para la representación de modelos
de productos, que permite la integración semántica de dichos
modelos.
o
Se ha implementado en OWL, el lenguaje estándar para la Web
Semántica, lo que posibilita la utilización de la ontología en
aplicaciones basadas en esta tecnología.
La definición de un prototipo de aplicación que utiliza tecnología de la
Web Semántica, el cual permite alcanzar la integración semántica de
información de productos (representada por medio de ontologías) a través de
un mecanismo de propagación de consultas entre nodos pares.
En síntesis, se puede afirmar que se ha formulado un modelo para representar y
gestionar la información estructural de productos que integra y extiende las propuestas
existentes, y que además brinda la posibilidad de incorporar otras dimensiones de la
información asociada a la manufactura de productos. La ontología del modelo conceptual ha
sido especificado formalmente (en O-Telos) y a partir de la misma, se generó una ontología
restringida (PRONTO) que pueda ser implementada en un lenguaje (OWL) interpretable en
el contexto tecnológico de la Web Semántica.
VII.3. TRABAJOS FUTUROS
A partir de la propuesta efectuada en esta Tesis se abren tres grandes líneas de
investigación que están relacionadas con la evolución:
del modelo conceptual;
de la ontología PRONTO y
del prototipo del sistema distribuido de información de productos.
La evolución de estas tres líneas no es totalmente independiente sino que se
influenciarán mutuamente. Así por ejemplo, la incorporación de nuevos conceptos al modelo
obligará su definición en PRONTO. Sin embargo, la ontología puede crecer aún sin la
incorporación de conceptos desde el modelo, ya que, por ejemplo, si se decide incorporar la
definición de reglas en base al cálculo de predicados, se podrían definir nuevas relaciones
cuyos valores se infieren mediante dichas reglas. Por otra parte, una evolución de la
ontología podría implicar un avance en el prototipo ya que posibilitaría la definición de
nuevas consultas basadas en los nuevos conceptos y/o reglas. Finalmente, el prototipo
podría evolucionar sin influencia de la ontología, por ejemplo, si se cambiara el mecanismo
de descubrimiento de nodos proveedores.
227
____________________________________________________ Conclusiones Finales y Futuros Trabajos
VII.3.1. Evolución del modelo conceptual
En cuanto a la evolución del modelo conceptual, pueden identificarse tres cuestiones
que el modelo debería contemplar en lo inmediato:
Unificación BOM-Routing
El “routing” detalla el proceso de manufactura de un ítem particular. Se especifica
para cada nodo del BOM convencional e incluye las operaciones a llevar a cabo, su
secuencia, los centros de trabajo involucrados, los tiempos de “setup” y producción.
Tradicionalmente existe una separación en la estructura de datos que se gestionan en el
piso de manufactura o “shop-floor”, un aspecto contiene la estructura del producto (BOM) y
otro la ruta a seguir por cada componente del producto en su proceso de fabricación
(“routing”). A efectos de mejorar la calidad de la información de productos y procesos es
necesario integrar estos dos aspectos dentro del modelo propuesto.
Manejo de versiones
Con el tiempo, las diferentes variantes de un producto (o el producto en sí mismo)
irán cambiando de acuerdo a lo que dicta la demanda de los clientes. Esta evolución
histórica es lo que se conoce como “versión” de un producto. Este concepto deberá ser
incorporado al modelo, para poder lograr “trazabilidad” sobre la evolución histórica del
producto, desde los procesos de diseño hasta la gestión de repuestos durante todo el ciclo
de vida de un producto. Si bien el atributo de trazabilidad de versiones no es crítico en el
caso de productos de consumo, sí lo es en industrias que fabrican productos que poseen
una vida útil considerable y debe ofrecerse servicio al cliente durante dicho período. Los
aviones, son un ejemplo de este tipo de productos, ya que un mismo modelo de avión,
fabricado en épocas diferentes, podría tener componentes distintos. Aquí, el manejo de
versiones es crítico, aún cuando el producto ya no se manufacture más. Este último caso
sería muy importante en los denominados Sistemas de Mantenimiento o de Gestión de
Activos.
Servicios de generación de información
La integración de las jerarquías de abstracción y estructural sienta las bases para la
formalización de mecanismos de generación de información de productos de importancia
para otros sistemas informáticos, a los cuales el modelo de productos abastece. Estos
mecanismos pueden extraer información a través de la AH, mediante procesos de
agregación o desagregación de información, o mediante la integración horizontal de
información definida para abstracciones de productos pertenecientes a un mismo nivel, las
que podrían estar vinculadas a través de la SH. Esta integración horizontal se da, por
ejemplo, en el cálculo de los tiempos mínimos y máximos de manufactura de un producto ya
228
____________________________________________________ Conclusiones Finales y Futuros Trabajos
que éstos se obtienen a partir de contabilizar los tiempos involucrados en los distintos
caminos existentes en su/s árbol/es de estructura.
Un proceso de agregación ocurre cuando el valor de una propiedad de una instancia
i de las abstracciones Familia o ConjuntodeVariantes es calculado a partir de los valores que
tiene esta propiedad en las instancias del correspondiente nivel inferior, relacionadas con i
por medio de una asociación miembroDe. Por ejemplo, el valor de la producción anual para
una familia determinada puede obtenerse por la agregación de los valores que dicho atributo
tiene en los conjuntos de variantes que son miembros de la familia. Dichos valores, a su vez,
pueden ser calculados por la agregación de los valores de producción anual de las
correspondientes instancias de Producto que son miembros de cada uno de los conjuntos
de variantes antes mencionados.
En sentido opuesto, un proceso de desagregación tiene como objetivo la generación
de información más detallada para los miembros de una determinada instancia de
AbstraccióndeProducto a partir de la información almacenada en el nivel superior. El
pronóstico de demanda para un conjunto de variantes determinado, por ejemplo, puede ser
usado para estimar la demanda de un producto que es miembro de dicho conjunto de
variantes, mediante la desagregación de información tomando como base a su participación
en el mercado.
VII.3.2. Evolución de PRoduct ONTOlogy y las ontologías locales
Independientemente de los cambios que deban hacerse sobre PRONTO, debidos a
modificaciones en el modelo conceptual, la evolución inmediata de la ontología consistirá en
la incorporación de la capacidad de definición de reglas deductivas en la misma.
La implementación de PRONTO mediante el lenguaje OWL define una base de
conocimientos que consiste de una terminología y un conjunto de aserciones acerca de los
individuos en términos de ese vocabulario. Un motor de inferencia basado en lógica
descriptiva, y que razona sobre dicha ontología, soporta patrones de inferencia como la
clasificación de conceptos y de individuos. La primera clasificación determina relaciones de
inclusión entre términos de un vocabulario, estableciendo una jerarquía de conceptos. Esta
clasificación, estipula que un concepto esté incluido dentro de otro más general
(superconcepto). Por su parte, la clasificación de individuos establece la pertenencia de
cada individuo a determinadas clases definidas en la ontología. Este proceso provee
información útil acerca de las propiedades de los individuos de un dominio de aplicación. Sin
embargo, dicho razonador no podría demostrar que un conjunto de afirmaciones implican
una conclusión, ya que no es posible la definición de reglas deductivas en el lenguaje
empleado para definir PRONTO. Esto impide por ejemplo, derivar los valores del atributo
229
____________________________________________________ Conclusiones Finales y Futuros Trabajos
componente para una FamiliaC determinada, razonamiento que sí es posible realizar en la
implementación efectuada en ConceptBase.
El problema de la incorporación de reglas a las ontologías definidas en OWL es
actualmente objeto de investigación, con lo cual no existen aún estándares definidos. Hay
sólo algunas propuestas enviadas al World Wide Web Consortium (W3C) para su análisis,
pero no tienen aún la categoría de recomendación. Una de ellas, es el lenguaje SWRL
(Semantic Web Rule Language) (Horrocks y colab., 2004), el cual extiende el conjunto de
axiomas OWL para incluir reglas tipo Horn. Por otra parte, las herramientas existentes para
definir reglas y razonar con ellas aún están en desarrollo. Protégé, por ejemplo, tiene un
“plug-in”, denominado SWRL Tab, que permite la definición de reglas, pero para poder
ejecutar la inferencia provee una interfaz con la máquina de inferencia Jess
(http://herzberg.ca.sandia.gov/jess/) y ejecuta un mapeo de la base de conocimientos OWL
en hechos Jess. SWRL.
Una de las actividades de investigación a corto plazo consiste, entonces, en analizar
cuál es la forma más conveniente de llevar a cabo la incorporación de reglas a la ontología
de manera de contar con capacidades deductivas como en la implementación desarrollada
en ConceptBase.
VII.3.3. Evolución del prototipo de sistema DPDM
En el Capítulo VI se presentó un sistema distribuido de consultas de información de
productos como resultado de una primera etapa hacia la definición de una infraestructura
para alcanzar la interoperabilidad de los sistemas de gestión de datos de productos,
directamente relacionados con el flujo de información y de materiales en cadenas de
colaboración entre empresas. Por tratarse de un prototipo, existen varias funcionalidades
que fueron implementadas de manera simplificada y que deberán ser mejoradas. Por
ejemplo, todo aquello asociado a la definición de instancias de la ontología que actualmente
está desconectada de los repositorios de información que utilizan las organizaciones. En
consecuencia, los pasos inmediatos en la evolución del prototipo consisten en la
implementación de un servicio de descubrimiento de fuentes de información eficiente, por
un lado y por otro, la incorporación de un servicio que lleve a cabo el mapeo entre instancias
almacenadas en una base de datos e instancias de la ontología.
El mecanismo de descubrimiento que utiliza actualmente el prototipo, si bien es
simple, no es eficiente ya que implica la propagación de consultas hacia todos los nodos (y
la recepción de las correspondientes respuestas) con la consecuente sobrecarga de las
redes de comunicaciones. Una posible mejora consistiría en determinar de antemano qué
nodos son capaces de responder la consulta y sólo propagarla hacia éstos. Las posibles
soluciones a este problema van desde mantener tablas con vinculaciones entre productos y
230
____________________________________________________ Conclusiones Finales y Futuros Trabajos
proveedores hasta la definición de ontologías que permitan inferir para una consulta dada
qué nodo posee “experiencia” para responderla. Se deberá determinar cuál de todas estas
alternativas es la más conveniente teniendo en cuenta un balance entre eficiencia y costo
computacional.
Actualmente, el prototipo utiliza como base de conocimientos archivos OWL donde
se encuentran definidas las instancias que representan la información de los productos de
cada una de las organizaciones. Sin embargo, si el sistema se ejecutara en una aplicación
real, debería obtener la información a partir de las bases de datos correspondientes a cada
uno de los nodos. Para ello, se deberán especificar mecanismos para definir los individuos
de las ontologías a partir de la información gestionada por los sistemas de información
locales. La forma en que dicha información se encuentra almacenada puede llegar a ser
muy diferente (tablas relacionales, archivos XML, archivos de texto, bases de datos
orientadas a objetos, etc.), implicando diversos grados de formalización. La integración de
estos mecanismos permitirá el empleo del sistema desarrollado en organizaciones reales.
Otro paso en la evolución del prototipo está vinculado con la incorporación de otras
ontologías que permitan representar los procesos logísticos que hacen uso del modelo de
productos. SCOntology (Gonnet y colab., 2007; Vegetti y colab., 2005b; Vegetti y colab.,
2005c) es una ontología que plantea la formalización y la extensión del modelo de referencia
SCOR (Supply Chain Operations Reference Model) (Stewart, 1997). Su integración con la
ontología de productos propuesta en esta Tesis debería ser analizada a mediano plazo, con
el fin de incluir SCOntology en el prototipo.
231
REFERENCIAS
Abramovici, M., y D. Gerhard. A Flexible Web-Based PDM Approach to Support
Abramovici y
Gerhard (2000)
Virtual Engineering Cooperation. Proceedings of the 33rd Hawaii International
Alexiev y
colab. (2004)
Alexiev, V., M. Breu, J. de Bruijn, D. Fensel, R. Lara y H. Lausen. Information
Conference on System Sciences, IEEE (2000).
Integration with Ontologies. John Wiley & Sons, Ltd. (2005).
ANSI/ISA-88.00.03-2003, Batch Control Part 3: General and Site Recipe Models
ANSI/ISA
(2003)
and Representation. Disponible en:
http://www.isa.org/MSTemplate.cfm?MicrositeID=275&CommitteeID=4737
(2003).
Baader, F. y W. Nutt. Basic Description Logics. En: The Description Logics
Baader y Nutt
(2003)
Handbook. Theory, Implementation and Applications. F. Baader, D. Calvanese,
D. McGuinness, D. Nardi y P. Pattel-Schenider Editores. Cambridge University
Press, 41-95 (2003).
Bechhofer, S.,
Bechhofer y
colab. (2004)
Berners-Lee y
colab. (2001)
Berners-Lee
(2003)
F. van Harmelen, J. Hendler, I. Horrocks, D. L. McGuinness, P.
F. Patel-Schneider y L. A. Stein. OWL Web Ontology Language Reference.
Recomendación del W3C. Disponible en: http://www.w3.org/TR/owl-ref/ (2004).
Bernes-Lee, T., J. Hendler, y O. Lassila. The semantic Web. Scientific American,
May (2001).
Bernes-Lee, T. WWW Past & Future. Presentación de la W3C. Disponible en:
http://www.w3.org/2003/Talks/0922-rsoc-tbl/ (2003).
Bonifacio, M. A Peer-to-Peer Solution for Distributed Knowledge Management.
Bonifacio
(2006)
En: Semantic Web and Peer-to-Peer. Decentralized Management and Exchange
of Knowledge and Information. S. Staab, y H. Stuckenschmidt Editores. Springer,
323-335 (2006).
233
________________________________________________________________________ Referencias
Booch y colab.
(1999)
Booch, G., J.Rumbaugh, e I. Jacobson. The Unified Modelling Language User
Guide. Addison Wesley (1999).
Borst, W.N. Construction of Engineering Ontologies for Knowledge Sharing and
Borst (1997)
Reuse. PhD. Thesis. University of Twente. (1997).
Brickley D., y Guha R. RDF Vocabulary Description Language 1.0: RDF Schema,
Brickley y
Guha (2004)
Recomendación del W3C. Disponible en: http://www.w3.org/TR/rdf-schema/
(2004).
Burkett, W. Product Data Markup Language: a New Paradigm for Product Data
Burkett (2001)
Exchange and Integration. Computer Aided Design, 33, 489-500 (2001).
Carboneras, M, C. Insa, y E. Salort. ERP Implementation in the Stone Industry:
Carboneras y
colab. (1992)
Special Difficulties and Solutions in the Production Area. Emerging Technologies
and Factory Automation. Proceedings. ETFA '03. IEEE Conference, 2, 146-150
(2003).
Chung, Y., y G. Fischer. Illustration of Object Oriented Databases for the
Chung y Fisher
(1992)
Structure of a Bill of Materials. Computers in Industry, 19, 257-270 (1992).
Chung, Y., y G. Fischer. A Conceptual Structure and Issues for an Object
Chung y Fisher Oriented Bill of Materials (BOM) Data Model. Computers and Industrial
(1994)
Engineering. 26, 321-339 (1994).
Dahchour, M. Integrated Generic Relationships into Object Models Using
Dahchour
(2001)
Metaclasses. Tesis (PhD). Université Catholique de Louvain, Faculté des
Sciences Appliquées (2001).
De Heij, J. Assessment of Business Information Systems by Data Structure.
De Heij (1996)
Ding y colab.
(2002)
Kluwer Bedrijfswetenschappen (1996).
Ding, Y., D. Fensel, M. Klein, y B. Omelayenko. The Semantic Web: Yet Another
Hip? Data and Knowledge Engineering, 41, 205-227 (2002).
234
________________________________________________________________________ Referencias
Fernandez-López,
FernándezLópez y colab.
(1997)
M.,
A.
Gómez-Pérez,
A.
Pazos,
y
J.
Pazos.
METHONTOLOGY: From Ontological Art Towards Ontological Engineering.
Spring Symposium on Ontological Engineering of AAAI. Universidad de Stanford
(1997).
Fisher, T. Batch control systems: design, application, and implementation.
Fisher (1990)
Resources for measurement and control series. Research Triangle Park, N.C.:
Instrument Society of America (1990).
Fox, M. The TOVE Project: A Common-sense Model of the Enterprise. Lecture
Fox (1992)
Notes in Artificial Intelligence, 604, 25-34 (1992).
Gennari, J., M. Musen, R. Fergerson, W. Grosso, M. Crubezy, H. Eriksson, N.
Genaro y
colab. (2002)
Noy, y S. Tu. The Evolution of Protégé: An Environment for Knowledge-Based
Systems Development. International Journal of Human-Computer Studies, 58,
89-123 (2002).
Giménez, D. Modelización de Información de Productos para Soportar la Gestión
Giménez (2005) Eficiente en una Empresa de Producción Industrial. Proyecto Final de Carrera
Ingeniería Industrial. Universidad Nacional del Litoral (2005).
Giménez, D., M. Vegetti, G. Henning, y H. Leone. Product Ontology. Defining
Giménez y
colab. (2006)
Product-related Concepts for Production Planning Activities. Computer Aided
Chemical Engineering, 21, 2219 – 2224 (2006).
Giménez, D., M. Vegetti, G. Henning, y H. Leone. PRoduct ONTOlogy. Defining
Giménez y
colab. (2007)
product-related concepts for logistics planning activities. Computers in Industry.
En prensa.
Gonçalves, R., y R. Scherer. From Design to Business, by Way of Product Life
Gonçalves y
Scherer (1999)
Cycle. The EAPPM initiative. Conference in Product Data Technology Europe
´99, Stavanger (1999).
235
________________________________________________________________________ Referencias
Gonnet, S. Un Modelo Integrado para la Captura y Administración del Proceso de
Gonnet (2003)
Diseño. Tesis Doctoral. Universidad Nacional del Litoral, Facultad de Ingeniería y
Ciencias Hídricas (2003).
Gonnet, S., M. Vegetti, H. Leone y G. Henning. SCOntology: A formal approach
towards a unified and integrated view of the supply chain. En: Adaptive
Gonnet y
colab. (2007)
Technologies and Business Integration: Social, Managerial and Organizacional
Dimensions. M. Cunha, B. Cortes y G. Putnik Editores. Idea Group, Inc., 137-158,
(2007).
Gruber, T. A translation Approach to Portable Ontology Specifications.
Gruber (1993)
Grüninger y
Fox (1995)
Knowledge Acquisition, 5, 199–220 (1993).
Grüninger, M., y M. Fox. Methodology for the design and evaluation of ontologies.
Workshop on Basic Ontological Issues in Knowledge Sharing (1995).
Gu, P. PML: Product Modelling Language. Computers in Industry, 18, 265-277
Gu (1992)
Gu y Chan
(1995)
(1992).
Gu, P., y K. Chan. Product Modelling Using STEP. Computer-Aided Design, 27,
163-179 (1995).
Gzara L., D. Rieub, y M. Tollenaerea. Product Information Systems Engineering:
Gzara y colab.
(2003)
an Approach for Building Product Models by reuse of patterns. Robotics and
Computer Integrated Manufacturing, 19, 239-261 (2003).
Hegge, H. Intelligent Product Family Descriptions for Business Applications. PhD
Hegge (1995)
Hepp (2004)
Herman (2007)
Thesis. Eindhoven University of Technology (1995).
Hepp, Martin F. (2004) Product Representation in the Semantic Web. Disponible
en SSRN: http://ssrn.com/abstract=545222 (2004).
Herman, I. Introduction to the Semantic Web. Conferencia en el congreso
"International Conference on Semantic Web & Digital Libraries" (2007).
236
________________________________________________________________________ Referencias
Horridge y
colab. (2004)
Horridge, M., H. Knublauch, A. Rector, R. Stevens, y C. Wroe. A Practical Guide
To Building OWL Ontologies Using The Protégé-OWL Plugin and CO-ODE Tools.
Edition 1.0 (2004).
Horrocks, I., D. Fensel , J. Broekstra, S. Decker, M. Erdmann, C. Goble, F. van
Horrocks y
colab. (2001)
Harmelen, M. Klein , S. Staab, R. Studer, y E. Motta. The Ontology Inference
Layer OIL. Technical Report (2001).
Horrocks, I., P. Patel-Schneider, H. Boley, S. Tabet, B Grosof, y M. Dean.
Horrocks y
colab. (2004)
SWRL: A Semantic Web Rule Language combining OWL and RuleML. W3C
Member Submision paper. Disponible en:
http://www.w3.org/Submission/2004/SUBM-SWRL-20040521/ (2004).
Hvan y colab.
(2003)
Hvan, L., J. Riis., y B. Hansen. CRC Cards for Product Modelling. Computers in
Industry, 50, 50-70 (2003).
Jarke, M., R. Gallersdörfer, M.A. Jeusfeld, M. Staudt, y S. Eherer. ConceptBase Jarke y colab.
(1995)
a Deductive Object Base for Meta Data Management. Journal of Intelligent
Information Systems, Special Issue on Advances in Deductive Object-Oriented
Databases, 4, 167-192 (1995).
Jarke, M., M. Jeusfeld, y C. Quix (Eds). ConceptBase V6.1. User Manual.
Jarke y colab.
(2003)
Disponible
en:
http://www-i5.informatik.rwth-aachen.de/CBdoc/userManual/
(2003).
Klein, M. DAML+OIL and RDF Schema representation of UNSPSC. Disponible
Klein (2002)
en: http://www.cs.vu.nl/~mcaklein/unspsc/ (2002).
Knutilla, A. C. Schelenoff, y R. Ivester. A Robust Ontology for Manufacturing
Knutilla y
colab. (1998)
Systems Integration. Proceedings of the 2
nd
International Conference on
Engineering Design and Automation (1998).
237
________________________________________________________________________ Referencias
Kondili, E., C. Pantelides, y R. Sargent. A General Algorithm for Short Term
Kondili y colab. Scheduling of Batch Operations – I. MILP Formulation. Computers and Chemical
(1993)
Engineering, 17, 211-227 (1993).
Liu, D., y W. Xiu. A review of Web-based Product Data Management Systems.
Liu y Xiu (2001)
Computers in Industry, 44, 251-262 (2001).
Manola, F., y E. Millar. RDR Primer. Recomendación del W3C. Disponible en:
Manola y Millar
(2004)
http://www.w3.org/TR/rdf-primer/ (2004).
Männistö y
colab. (1998)
Männistö
(2000)
Männistö y
colab. (2001)
Mc Guinness
(2001)
McGuinness y
van Harmelen
(2004)
Männistö, T., A. Peltonen, y R. Sulomen. Modeling Generic Product Structure in
STEP. Computer Aided Design, 30 (14), 1111-1118 (1998).
Männistö, T. A Conceptual approach to Product Families and their Evolution.
Ph.D. Thesis. Helsinki University of Technology (2000).
Männistö, T., H. Peltonen, y R. Sulomen. Multiple Abstraction Levels in Modelling
Product Structures. Data and Knowledge Engineering, 36, 55-78 (2001).
Mc
Guinness,
D.
UNSPSC
Ontology
in
DAML+OIL.
Disponible
en:
http://www.daml.org/ontologies/106 (2001).
McGuinness, D., y F. van Harmelen. OWL Web Ontology Language Overview.
Recomendación del W3C. Disponible en:
http://www.w3.org/TR/owl-features/
(2004).
Mervyn, F., A. Senthil Kumar, S. Bok, y A. Nee. Developing Distributed
Mervyn y
colab. (2004)
Applications for Integrated Product and Process Design. Computer Aided Design,
36, 679-689 (2004).
Motard, R. L., M. R. Blaha, N. L. Book, y J. J. Fielding, Process Engineering
Motard y colab. Databases -- From the PDXI Perspective. Proceedings de FOCAPD '94,
(1994)
Snowmass, Colorado (1994).
238
________________________________________________________________________ Referencias
Mylopoulos, J., A. Borgida, M. Jarke, y M. Kaubarakis. Telos: Representing
Mylopoulos y
colab. (1990)
Knowledge About Information Systems. ACM Transactions on Information
Systems, 8(4), 352-362 (1998).
Nahmias, S. Production and Operations Analysis, cuarta edición. McGraw-Hill/
Nahmias (2001)
Irwin, Nueva York (2001).
Niles, I. y A. Pease. Towards a Standard Upper Ontology. Proceedings de 2nd
Niles y Pease
(2001)
Olsen y colab.
(1997)
International Conference on Formal Ontology in Information Systems (FOIS2001). Chris Welty and Barry Smith Editores. (2001).
Olsen, K.A., P. Sætre, y A. Thorstenson. A Procedure- Oriented Generic Bill of
Materials. Computers and Industrial Engineering, 32, 29-45 (1997).
Persson-Dahlqvist, A., U. Asklund, I. Crnkovic, M. Larsson, y D. Svesson. PDM
Persson y
colab. (2002)
and SCM – Similarities and Differences. MRTC report ISSN 1404-3041 ISRN
MDH-MRTC-54/2002-1-SE, Mälardalen Real-Time Research Centre, Mälardalen
University (2002).
Rodríguez y
Al-Ashaab
(2005)
Rumbaugh y
colab. (1999)
Saaksvuori e
Immonen
(2005)
Rodríguez, K. y A. Al-Ashaab. Knowledge web-based system architecture for
collaborative product development. Computers in Industry, 56, 125-140 (2005).
Rumbaugh, J., I. Jacobson, y G. Booch. The Unified Modelling Language
Reference Manual. Addison Wesley (1999).
Saaksvuori, A., y A. Immonen. Product Lifecyle Management. Second Edition.
Springer-Verlag, Berlin- Heidelberg (2005).
Scheer, A.W. Business Process Engineering. Springer-Verlag, Berlin- Heidelberg
Scheer (1998)
Schönsleben
(1985)
(1998).
Schönsleben, P. Flexible Prodktionsplanung und Steuerung mit dem Computer.
CW- Publickationen, München (1985).
239
________________________________________________________________________ Referencias
Sheth, A. Changing focus on interoperability in information systems: from system,
syntax, structure to semantics, en Interoperating Geographic Information
Sheth (1998)
Systems. (Eds) Goodchild M., Eghenhofer M., Fegeas R., y Kottan R. Kluwer
(1998).
Simchi-levi y
colab. (2004)
Simchi-Levi, D., P. Kaminsky, y E. Simchi-Levi. Managing the Supply Chain,
McGraw-Hill, Nueva York (2004).
STEP. Product Data Representation and Exchange- Part 44, Product Structure
STEP (1991)
Configuration. Standard ISO 10303 (1991).
Stewart, G. Supply-chain operations reference model (SCOR): The first crossStewart (1997)
industry
framework
for
integrated
supply
chain
management.
Logistics
Information Management, 10, 62– 67 (1997).
Studer, R, V. Benjamins, y D. Fensel. Knowledge Engineering: Principles and
Studer y colab.
(1998)
Taleb y Gupta
(1997)
Uschold y
Grüninger
(1996)
Uschold y
colab. (1998)
Methods. IEEE Transactions on Data and Knowledge Engineering, 25, 161-197
(1998).
Taleb K, y S. Gupta Disassembly of Multiple Product Structures. Computers
industrial engineering, 32, 949-961 (1997).
Uschold, M. y M. Grüninger. Ontologies: Principles, Methods and Applications.
Knowledge Engineering Review, 11, 93-155 (1996).
Ushold, M., M. King, S. Moralee y S. Zorgios. The Enterprise Ontology. The
Knowledge Engineering Review, 13, 31-89 (1998).
Usher J. An Object-Oriented Approach to Product Modelling for Manufacturing
Usher (1993)
Van Veen y
Wortmann
(1992)
Systems. Computers and Industrial Engineering, 25, 557-560 (1993).
Van Veen, E.A., y J.C. Wortmann. Generative Bill of Materials Processing
Systems. Production Planning & Control, 3, 314-326 (1992).
240
________________________________________________________________________ Referencias
Vdovjak R., G.J. Houben, H. Stuchenschmidt y A. Aerts. RDF and Traditional
Vdovjak y
Query Architectures. En: Semantic Web and Peer-to-Peer. Decentralized
colab. (2006)
Management and Exchange of Knowledge and Information. S. Staab, y
H. Stuckenschmidt Editores. Springer. 41-58, (2006).
Vegetti, M., G. Henning y H. Leone. An Object Oriented Model for Complex Bill of
rd
Vegetti y colab. Materials in Process Industries. Proceedings de ENPROMER 2001- 3 Mercosur
(2001a)
Congress on Process Systems Engineering – 1st Mercosur Congress on
Chemical Engineering (2001).
Vegetti y colab.
(2001b)
Vegetti y colab.
(2002a)
Vegetti y colab.
(2002b)
Vegetti, M., G. Henning y H. Leone. Un Modelo de Estructura de Productos para
Industrias de Procesos. Proceedings de CAIP 2001 - 5º Congreso Interamericano
de Computación Aplicada a la Industria de Procesos (2001).
Vegetti, M., G. Henning y H. Leone. An Object Oriented Model for Complex Bill of
Materials in Process Industries. Brazilian Journal of Chemical Engineering,19,
491-497 (2002).
Vegetti, M., G. Henning y H. Leone. An Object Oriented Framework for Bill of
Materials in Process Industries. Computer-Aided Chemical Engineering, 10,
Elsevier, 991-996 (2002).
Vegetti, M., G. Henning y H. Leone. Hacia un Framework Orientado a Objetos
Vegetti y colab. para Bill of Materials Complejos. Proceedings de las 32 Jornadas Argentinas de
(2003)
Informática e Investigación Operativa (2003).
Vegetti, M., G. Henning y H. Leone. A PDM System for the Derivation of Products
Vegetti y colab. with Complex Structure in Process Industries. Proceedings de las 33 Jornadas
(2004)
Argentinas de Informática e Investigación Operativa (2004).
Vegetti, M., G. Henning y H. Leone. PRoduct ONTOlogy. Definition of an
Ontology for Complex Product Modelling Domain. Proceedings de ENPROMER
Vegetti y colab.
nd
th
(2005a)
2005 – 2 Mercosur Congress on Chemical Engineering and 4 Mercosur
Congress on Process Systems Engineering (2005).
241
________________________________________________________________________ Referencias
Vegetti, M., S. Gonnet, G. Henning y H. Leone. Information Logistics for Supply
Vegetti y colab. Chain Management within Process Industry Environments. Computer-Aided
(2005b)
Chemical Engineering, 20, Elsevier, 1231 -1236 (2005).
Vegetti, M., S. Gonnet, G. Henning y H. Leone. Towards a Supply Chain
Ontology of Information Logistics within Process Industry Environments.
Vegetti y colab. Proceedings de ENPROMER 2005 – 2nd Mercosur Congress on Chemical
(2005c)
Engineering and 4th Mercosur Congress on Process Systems Engineering.
(2005).
Versant (1998)
Vollman y
colab. (1992)
Wortmann
(1992)
Wortmann
(1995)
Zaniolo y
colab. (1997)
Versant Corporation, Versant Database Fundamentals 5.2 (1998).
Vollman, T., W. Berry, y D. Whibark. Manufacturing Planning and Control
rd
Systems. 3 edition. Business One Irwin, Honewood IL (1992).
Wortmann, J.C. Production Management Systems for One-of-a-Kind Products.
Computers in Industry, 19, 79-88 (1992).
Wortmann, J.C. Comparison of information systems for engineer-to-order and
make-to-stock situations. Computers in Industry, 26, 261-271 (1995).
Zaniolo, C. S. Ceri, Ch. Faloutsos, R. Snodgrass, V. Subrahmanian, y R. Zicari.
Advanced Database Systems. Morgan Kaufmann Publishers (1997).
Zha, X., y R. Sriram. Platform-based Product Design and Development: A
Zha y Sriram
(2006)
Zhou y colab.
(2003)
Knowledge Intensive support Approach and Implementation. Knowledge-Based
Systems, 19(7), 524-543 (2006).
Zhou, S., K. Chin, y Y. Xie. Internet-based Distributive Knowledge Integrated
System for Product Design. Computers in Industry, 50, 195-205 (2003).
242
APÉNDICE A. DEFINICIÓN DE VISTAS EN CONCEPTBASE
VII.4. INTRODUCCIÓN
Este apéndice tiene por objetivo introducir algunas de las vistas que pueden ser
definidas en el modelo para presentar la información de productos de acuerdo a diversos
requerimientos. Inicialmente se presentan algunas características de la definición de vistas
en ConceptBase.
VII.5. DEFINICIÓN DE CONSULTAS Y VISTAS EN CONCEPTBASE
ConceptBase (CB) significa base de conceptos, y tal como su nombre lo sugiere,
este lenguaje se puede utilizar para almacenar y consultar colecciones de descripciones
conceptuales. CB es considerada una base de datos de objetos deductiva debido a que
hereda las características de las bases de datos orientadas a objetos y de las bases de
datos deductivas. Las potencialidades de CB se sustentan en el modelo de objetos O-Telos,
un dialecto de Telos, que es un lenguaje de modelado conceptual para la representación del
conocimiento sobre sistemas de información. Telos ha sido uno de los primeros intentos de
integrar las propiedades de lenguajes deductivos y orientados a objetos.
Las principales características de CB son:
Provee distintas representaciones de los objetos almacenados en la base de
datos (lógica, basada en “frames” y gráfica).
Posee extensibilidad ilimitada por medio de jerarquías de meta clases.
El comportamiento de los objetos se representa a través de restricciones de
integridad y reglas deductivas que son asociadas a la clase como atributos.
Emplea reglas y restricciones de meta-nivel para la axiomatización de los
lenguajes definidos.
Los objetos pueden ser instancias de un número arbitrario de clases (múltiple
clasificación).
Las consultas se representan como clases con restricciones sobre los
miembros.
Provee el concepto de vistas complejas como extensión de las clases de
consultas.
243
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
Está dotado de una interfaz de programación basada en los métodos ASK y
TELL.
El presente apéndice está estructurado en base al manual del usuario de CB (Jarke y
colab., 2003) y a la introducción a CB realizada por Dahchour (2001), según lo presentado
en Gonnet (2003).
VII.5.1. Base de conocimientos y formas de representación. Conceptos generales
La base de conocimiento de CB está conformada por colecciones de objetos,
denominados proposiciones que representan individuos o atributos. Los individuos
representan
los
conceptos
de
objetos
(por
ejemplo,
una
familia
denominada
CarameloFrutalEnv) y clases (por ejemplo, FamiliaC) del modelo de objetos (Booch y colab.,
1999). Por otra parte, un atributo representa una relación binaria entre: i) dos individuos, ii)
un individuo y un atributo, o iii) dos atributos.
Existen tres constructores básicos utilizados en una base de conocimiento Telos, a
saber:
Instanciación: se denota como in y permite posicionar uniformemente a los
objetos en un número de niveles de instancias.
Especialización: se denota isA y permite especializar/generalizar objetos no
terminales (clases, metaclases, atributos, etc.).
Agrupamiento: se denota por with y permite agrupar en categorías de
atributos a una lista de estos últimos. Esta definición no se debe confundir
con el concepto de agregación, de la literatura de modelado orientado a
objetos.
La definición de atributos en CB es más versátil que la definición usual en el
modelado de objetos, principalmente porque el atributo es considerado una clase; por lo
tanto, es posible asignarle al mismo una estructura y puede ser instanciado.
VII.5.2. Sublenguaje Predicativo CBL
El ambiente CB utiliza el lenguaje predicativo CBL para expresar restricciones de
integridad, reglas deductivas, consultas y vistas. CB ofrece un conjunto de literales para el
lenguaje predicativo que provee acceso a la base de objetos que el mismo dispone. Las
sentencias de CB en la representación de “frame” poseen el formato simplificado indicado
en la Tabla A.1, en tanto las fórmulas (cláusulas) poseen el que se presenta en la Tabla A.2.
244
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
Tabla A.1: Formato de sentencias en un frame en CB
<objeto-o-nombreDeClase> in [<listaInstanciaDe>] [isA] [<listaSuperclase>] [with
[attribute  <nombreAtributoYaDefinido>
[<nombre> : <objeto-o-nombreDeClase> ;] * ]
[constraint  rule [<nombre> : $ <fórmula> $;] * ]
]
end
Tabla A.2: Formato de una fórmula
<fórmula>
→ exists <listaEnlaceVariable> <fórmula>
| forall <listaEnlaceVariable> <fórmula>
| not <fórmula>
| <fórmula> <= => <fórmula>
| <fórmula> = => <fórmula>
| <fórmula> and <fórmula>
| <fórmula> or <fórmula>
| <fórmula>
| <literal1>
|<literal2>
Las posibles alternativas a “literal1”, así como las correspondientes a “literal2”, que
aparecen en la tabla A.2, y su explicación se presentan en las Tablas A.3 y A.4. Cabe
destacar que las variables empleadas en “literal2” deben estar ligadas a un valor a través de
alguna de las alternativas de “literal1” antes de ser utilizadas.
Tabla A.3: Posibles alternativas para “literal1”
(x in c) o In(x, c)
El objeto x es instancia de la clase c.
(c isA d) o Isa(c, d)
El objeto c es una especialización de d.
(x m y) o A(x, m, y)
El objeto x tiene como atributo al objeto y; relación que es
una instancia de la categoría de atributo con etiqueta m.
A(x, m, p)
El objeto x tiene un atributo p, instancia de la categoría de
atributo m.
AL(x, m, l, y)
El objeto x tiene un objeto y con etiqueta l, instancia de la
categoría de atributo m.
245
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
Tabla A.4: Posibles alternativas para “literal2”
x < y, x > y, x <= y,
x >= y, x = y, x <> y
x menor a y, x mayor a y, x menor o igual a y, x mayor o
igual a y, x igual a y, x distinto a y.
x == y o IDENTICAL(x, y)
x e y son el mismo objeto.
Las variables utilizadas en las fórmulas deben ser cuantificadas y asignadas a un
determinado dominio; Esta cuantificación representa una relación de instancia y las
siguientes expresiones
forall x/C <formula>
exists x/C <formula>
son simplificaciones de:
forall x ( x in C) ==> <formula>
exists x (x in C) and <formula>
y serán utilizadas, en su forma simplificada, en la especificación de reglas y
restricciones asociadas a las definiciones de las clases que se presentan en el resto
del presente capítulo.
VII.5.3. Reglas Deductivas y Restricciones
Las reglas deductivas y las restricciones en CB son fórmulas (cláusulas) que se
definen en las clases como si fuesen atributos. Las reglas deductivas son aseveraciones
que imponen nuevos hechos, mientras que las restricciones controlan la información
provista por el usuario (son aseveraciones que deben ser satisfechas en todo momento).
Las restricciones y reglas pueden ser definidas por el usuario, aunque existen algunas
preestablecidas sobre el lenguaje y la semántica de los conceptos predefinidos en CB
(objeto, clase, metaclase, atributo, relaciones de instanciación y especialización). Ellas son
referidas como axiomas de O-Telos.
Cuando un usuario define restricciones y reglas, lo hace como atributos de una clase
dada. Estos atributos son instancias de constraint y rule, que a su vez son atributos
predefinidos de la meta clase Class. Entonces, una clase que especifica reglas y/o
restricciones debe explícitamente definirse como instancia de Class.
Por ejemplo, en la Especificación A.1 se presenta una regla denominada
compDirRule asociada a la clase FamiliaC, la cual permite inferir el/los componente/s de una
familia compuesta a partir de las relaciones que conforman su estructura.
246
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
Individual Familia in Class
FamiliaC with
attribute
componenteDirecto: Familia;
attribute, rule
compDirRule: $ forall f1/FamiliaC f2/Familia (exists e/EstructuraC
r/RelacionC (f1 estructuraDe e) and (e componente r) and
(r parte f2)) ==> (f1 componenteDirecto f2)$;
Especificación A.1. Ejemplo de regla deductiva en CB
En la Especificación A.2 se ejemplifica una restricción sobre los conjuntos de
variantes compuestas. La restricción RIII_1 especifica que para toda familia compuesta
debe existir al menos una estructura. Cabe aclarar que una restricción no permite incorporar
nuevos hechos a la base de conocimientos, sino que garantiza que la sentencia enunciada
se satisfaga en todo momento. En particular, la restricción presentada no permite incorporar
una FamiliaC sin una estructura asociada.
FamiliaC with
attribute
estructuraDe: Estructura
constraint
RIII_1:$forall f/FamiliaC (exists e/Estructura (f estructuraDe e))$
end
Especificación A.2. Ejemplo de restricción de integridad
VII.5.4. Consultas
En CB las consultas se definen como clases especiales cuyas instancias son las
respuestas a la consulta. A su vez, dichas clases se definen como instancias de la clase
predefinida QueryClass; clase que se introduce en la Especificación A.3.
Individual QueryClass in Class isA Class with
attribute
retrieved_attribute: Proposition;
computed_attribute: Proposition
end
Especificación A.3. Definición de la clase QueryClass
Si una QueryClass es definida como una especialización de otra clase definida (por
ejemplo FamiliaC) por el usuario, entonces todas las respuestas a dicha consulta deben ser
instancias de dicha clase. De esta manera, la consulta que se muestra en la Especificación
A.4 retorna todas las familias compuestas. En la misma puede observarse la definición de
retrieved_attribute. Éste permite recuperar los valores del atributo al cual se hace referencia
(estructuraDe), los cuales se asocian con cada una de las instancias de la superclase
FamiliaC, las que serán listadas como respuesta a la consulta. Si para alguna instancia de
247
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
FamiliaC este atributo no posee valor, dicha instancia no será incorporada como respuesta a
la consulta.
QueryClass FamiliaEnsamblada isA FamiliaC with
retrieved_attribute
estructuraDe: Estructura
end
Individual Estructura in Class end
Especificación A.4. Ejemplo de una consulta simple en CB
Si se desea construir consultas más expresivas es posible plantear restricciones en
las mismas, tal como se presenta en la Especificación A.5. En este caso, se restringen las
respuestas a aquellas familias que representan ensambladas. En la definición de la
restricción es posible utilizar la variable this, que asume como valor cualquier objeto de la
clase de consulta.
QueryClass FamiliaEnsamblada isA Familia with
retrieved_attribute
esEnsamblado : Boolean;
estructuraDe: Estructura
constraint
c : $ (this esEnsamblado TRUE) $
end
Especificación A.5. Ejemplo de una consulta con restricciones en CB
En una consulta también es posible definir nuevos atributos, los cuales se denominan
“computed_attributes” debido a que los valores asignados a los mismos se infieren por
medio de una restricción que se especifica en la consulta.
Por último, dado que las consultas se representan como clases, las mismas se
pueden almacenar en la base de conocimiento para su futuro uso. Además, CB permite la
definición de consultas genéricas (Especificación A.6) que serán ejecutadas luego con
ciertos parámetros. En este sentido, las consultas genéricas son consultas donde es posible
derivar nuevas consultas por medio de la sustitución de los parámetros.
Individual GenericQueryClass isA QueryClass with
attribute
parameter: Proposition
end
Especificación A.6. Definición de la clase GenericQueryClass
VII.5.5. Vistas
En ConceptBase las vistas extienden las consultas definidas en la sección previa. En
la Especificación A.7 se presenta la clase predefinida View.
248
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
Los atributos de la categoría inherited_attribute, que se utiliza en la definición de una
vista, son similares a retrieved_attribute mencionado en los párrafos previos, pero éstos no
deben necesariamente poseer instancias para pertenecer a las vistas. El atributo partof
permite la definición de vistas anidadas complejas, es decir, valores de atributos que
representan objetos complejos con sus propios atributos.
Class View isA GenericQueryClass with
attribute
inherited_attribute : Proposition;
partof : SubView
end
Especificación A.7. Definición de la Clase View
La vista que se muestra en la Especificación A.8 permite la visualización de las
relaciones con el valor, la unidad de medida y límites para el atributo quantityPer.
Se
muestran también algunas de las instancias que pertenecen a la vista.
View VistaRelaciones isA Relacion with
retrieved_attribute
parte:Familia
retrieved_attribute, partof
quantityPer : ValorRestringido with
retrieved_attribute
valor:Real;
udeM:Unidad;
min:Real;
max:Real
end
end
...
R03 in VistaRelacion with
quantityPer
quantityPer:30_87GR with
max
max : 50.0
min
min : 10.0
udeM
udeM : GR
valor
valor : 1046.530
end
parte
parte: PapelEnvoltorio
end
R04 in VistaRelacion with
quantityPer
quantityPer:930_233GR
with max
max : 1000.0
min
min : 900.0
udeM
udeM : GR
valor
valor : 930.233
end
parte
parte: CarameloFrutalDes
end
R05 in VistaRelacion with
quantityPer
quantityPer :33GR with
max
max : 50.0
min
min : 10.0
udeM
udeM : GR
valor
valor : 33.0
end
parte
parte : PapelSeparador
end
...
Especificación A.8. Definición y ejemplos de la vista VistaRelaciones
Tal como está definida la vista especificada en A.8, ésta devuelve todas las
instancias de Relación que se encuentren definidas en la base de datos. Si se desea filtrar
por una relación en particular debería agregarse una restricción como se muestra en la
Especificación A.9, en la cual se especifica que sólo forman parte de las vistas, aquellas
instancias equivalentes al individuo R04. Sin embargo, esta vista sirve sólo para ver dicha
249
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
relación. Si se desea la misma información sobre otra relación, es necesario armar otra vista
cambiando la restricción, lo cual hace que este tipo de vistas tenga relativa utilidad.
View VistaRelaciones2 isA Relacion
with
retrieved_attribute
parte:Familia
retrieved_attribute, partof
quantityPer : ValorRestringido
with
retrieved_attribute
valor:Real;
udeM:Unidad;
min:Real;
max:Real
end
constraint
c:$ (this == R04) $
end
R04 in VistaRelacionesv2 with
quantityPer
quantityPer : 930_233GR with
max
max : 1000.0
min
min : 900.0
udeM
udeM : GR
valor
valor : 930.233
end
parte
parte : CarameloFrutalDes
end
Especificación A.9. Definición e instancia de la vista VistaRelacionesv2
La vista previa puede hacerse más genérica a través de la definición de un
parámetro, tal como se muestra en la Especificación A.10. Al momento de ejecutar la vista,
se debe dar un valor para dicho parámetro.
View VistaRelacionesv3 isA Relacion with
attribute, parameter
unaRelacion: Relacion
retrieved_attribute
parte:Familia
retrieved_attribute, partof
quantityPer : ValorRestringido with
retrieved_attribute
valor:Real;
udeM:Unidad;
min:Real;
max:Real
end
end
Especificación A.10. Definición de la vista VistaRelacionesv3
Es importante mencionar que en las vistas presentadas como ejemplos, se define
otra vista anidada para el atributo quantityPer. La presencia de esta vista se indica por la
etiqueta partof (que en la Especificación A.10 está resaltada) la cual se agrega cuando se
introduce dicho atributo. Al igual que pueden establecerse restricciones para las vista
externas, como la que se muestra en la Especificación A.9, las vistas internas (o anidadas)
también pueden incorporar restricciones. Debe tenerse en cuenta en estos casos, que si se
utiliza la palabra clave this, ésta hace siempre referencia a los individuos que pertenecen a
la vista exterior.
Un ejemplo de una vista de este tipo se presenta en la Especificación A.11, en la
cual se muestra la vista VerRelacionesModificadas que recupera todas aquellas instancias
de Relación que están como valores del atributo relacionesModificadas de un conjunto de
250
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
variantes, mostrando para cada una de ellos cuales son los cambios que se aplican y el
valor del atributo newQP que cada uno de estos cambios establece. Se define la restricción
rint en la vista más interna, para asegurar que el cambio que se incluye en la vista se
corresponde con un cambio aplicado por un determinando conjunto de variantes. En dicha
restricción this hace referencia a una instancia de ConjuntodeVariantesC (que además es
instancia de la vista) y se navega por los atributos de las vistas internas utilizando los
caracteres “::”. Por ejemplo, this::relacioneModificadas::cambioAplicado, identifica el atributo
cambioAplicado que se encuentra en la vista más interna.
View VerRelacionesModificadas isA ConjuntodeVariantesC with
retrieved_attribute, partof
relacionesModificadas: RelacionC with
retrieved_attribute,partof
cambioAplicado : CambioC with
retrieved_attribute
newQP:ValorUnidad
constraint
rint:$ A(this, cambioAplicado, this::relacionesModificadas::cambioAplicado)$
end
end
end
Especificación A.11. Ejemplo de vistas anidadas
VII.6. ALGUNAS DE LAS VISTAS DEFINIDAS EN EL MODELO PROPUESTO
En primer lugar, se presenta en la Especificación A.12 la vista VistaAH, la cual infiere
la jerarquía de abstracción relacionada con cada una de las familias cargadas en la base de
datos. Los resultados se presentan en la vista A.13; en particular se muestra la jerarquía de
CarameloFrutalEnv.
En la Especificación A.14 se presenta la vista VistaFamilia, la cual permite visualizar
las estructuras de una familia con sus relaciones. Dicha vista es subclase de Familia y
hereda de ésta el atributo estructuraDe, el cual es especializado en VistaFamilia, como una
vista que obtiene los valores de los atributos conformadoPor, los cuales son mostrados
también a través de una vista anidada. Esta última permite recuperar los valores de los
atributos parte, quantityPer y tipoRelación para cada uno de los valores que se infieran para
el atributo conformadoPor
View VistaAH isA Familia with
retrieved_attribute,partof
miembros: ConjuntoVariante with
retrieved_attribute,partof
miembros:Producto with
retrieved_attribute
descripcion:String
end
end
end
Especificación A.12. Definición de la vista VistaAH
251
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
CarameloFrutalEnv in VistaAH with
miembros
COMPUTED_miembros_id_4773:BolsinFrutalROC
with
miembros
COMPUTED_miembros_id_5047:SE511605 with
descripcion
descripcion : "BolsínFrutilla5GREnv"
end ;
COMPUTED_miembros_id_5055:SE511606 with
descripcion
descripcion:"BolsínPera5GREnv"
end ;
COMPUTED_miembros_id_5063: SE511607 with
descripcion
descripcion:"BolsínPomelo5GREnv"
end ;
COMPUTED_miembros_id_5071:SE511609 with
descripcion
descripcion:"BolsínLima5GREnv"
end ;
COMPUTED_miembros_id_5079:SE511610 with
descripcion
descripcion:"BolsínCerez5GREnv"
end
end ;
COMPUTED_miembros_id_4850: VaritaKIM with
miembros
COMPUTED_miembros_id_4993 : SE508207 with
descripcion
descripcion : "Varita KIM Pera*Env"
end ;
COMPUTED_miembros_id_5001: SE508219 with
descripcion
descripcion : "Varita KIM Frutilla*Env"
end ;
COMPUTED_miembros_id_5023 :SE508246 with
descripcion
descripcion : "VaritaKIMDamascoEnv"
end ;
COMPUTED_miembros_id_5031: SE508247 with
descripcion
descripcion : "VaritaKIMPomeloEnv"
end ;
COMPUTED_miembros_id_5039: SE508253 with
descripcion
descripcion : "VaritaKIMLimaEnv"
end
end
end
...
Especificación A.13. Resultados de la vista VistaAH
View VistaFamilia isA FamiliaC with
inherited_attribute,partof
estructuraDe:Estructura with
retrieved_attribute ,partof
conformadoPor:Relacion with
inherited_attribute
parte:Familia;
quantityPer:ValorRestringido;
prodFactor:ValorRestringido;
tipoRelacion:TipoRelacion
end
end
end
CarameloFrutalDes in VistaFamilia with
estructuraDe
estructuraDe:CarameloFrutlDesSTR with
conformadoPor
conformadoPor1 : R09 with
parte
parte : MasaConAcido
quantityPer
quantityPer : 830GR
tipoRelacion
tipoRelacion : obligatoria
end ;
conformadoPor2 :R10 with
parte
parte : RellenoFrutal
quantityPer
quantityPer : 170GR
tipoRelacion
tipoRelacion : obligatoria
end
end
end
Especificación A.14. Definición e instancia de la VistaFamilia
A continuación se introducen una serie de vistas que permiten obtener información
sobre el nivel ConjuntodeVariantes. La primera que se presenta, en la Especificación A.15,
permite visualizar para cada conjunto de variantes, la familia de la que éste es miembro, sus
propios miembros, la estructura de la que se deriva y las modificaciones que se aplican a
ella.
En particular, la Especificación A.16 muestra el resultado de esta vista para los
conjuntos de variantes VaritaKIM y BolsínFrutalROC.
252
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
View VerInfoCVariantes isA ConjuntoVariante with
inherited_attribute
miembroDe:Familia;
derivaDe:Estructura
inherited_attribute, partof
modificacionAplicada: Modificacion with
inherited_attribute
cambioAplicado: Cambio
end
inherited_attribute, partof
preselecciona: Preseleccion with
inherited_attribute
conjuntoSeleccionado:ConjuntoVariante
end
end
Especificación A.15. Definición de la vista VerInfoCVariantes
BolsinFrutalKIM in VerInfoCVariantes2 with
modificacionAplicada
modificacionAplicada : Mod1BolsinFKIM with
cambioAplicado
cambioAplicado1 : CaR03m1;
cambioAplicado2 : CaR04m1;
cambioAplicado3 : CaR05m1
modifica
COMPUTED_modifica_id_3372:CarameloFrutlEnvSTR
end
preselecciona
preselecciona: PapelEnvKim with
ConjuntoSeleccionado
ConjuntoSeleccionado:EnvBolsinFrutalKIM
end ;
preselecciona2 : CarFrutal with
ConjuntoSeleccionado
ConjuntoSeleccionado : OvaloFrutal
end
miembroDe
miembroDe : CarameloFrutalEnv
derivaDe
derivaDe : CarameloFrutlEnvSTR
end
...
VaritaKIM in VerInfoCVariantes2 with
modificacionAplicada
modificacionAplicada : modVaritaKIM with
cambioAplicado
cambioAplicado : Ca2R03;
cambioAplicado2 : Ca2R04;
cambioAplicado3 : ElR05
modifica
COMPUTED_modifica_id_3372:CarameloFrutlEnvSTR
end
preselecciona
preselecciona1:CarVaritaFrutal with
ConjuntoSeleccionado
ConjuntoSeleccionado : VaritaFrutal
end ;
preselecciona2 : PreselVaritaKIM with
ConjuntoSeleccionado
ConjuntoSeleccionado : EnvVaritaKIM
end
miembroDe
miembroDe : CarameloFrutalEnv
derivaDe
derivaDe : CarameloFrutlEnvSTR
end
...
Especificación A.16. Algunos resultados de la vista VerInfoCVariantes
Las vistas que se presentan a continuación muestran las relaciones que son
afectadas por los diferentes cambios impuestos a una Estructura por una Modificación
establecida en un determinado ConjuntodeVariantes.
En la Especificación A.17 se presenta la vista RelacionesEliminadas, la cual es una
especialización de la clase Relación y tiene como parámetro una instancia de Modificación.
La misma hereda de la clase Relación el atributo parte y agrega el atributo cantidad que es
calculado por la vista. El resultado de esta vista son todas aquellas instancias de la clase
Relación que son eliminadas de una estructura al aplicar la Modificación que se recibe como
parámetro.
253
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
Individual RelacionesEliminadas in View isA Relacion with
attribute,parameter
mod : Modificacion
retrieved_attribute
parte:Familia
computed_attribute
cantidad: ValorUnidad
attribute,constraint
c:$exists c/Eliminacion (~mod cambioAplicado c) and(c relacionModificada this)and
((this quantityPer ~cantidad )or (this prodFactor ~cantidad ))$
end
Especificación A.17. Vista RelacionesEliminadas
La Especificación A.18 presenta la vista PreseleccionesRealizadas, la cual permite
recuperar los conjuntos de variantes que se preseleccionan para cada familia componente
que permanece en la estructura de un determinado ConjuntodeVariantesC. Estas familias
componentes son inferidas por la vista como valores del atributo parte de la vista anidada
definida para el atributo unReq. La restricción de la vista más externa permite filtrar aquellas
relaciones que corresponden a la estructura de la que deriva el conjunto de variantes y no
han sido eliminadas ni dejadas afuera de la misma por no ser seleccionadas. Para ello utiliza
el atributo enSTR, el cual se define en la clase ConjuntodeVariantesC y permite inferir,
cuales son estas relaciones según la Especificación A.19.
El resultado de la vista PreseleccionesRealizadas para los conjuntos de variantes
BolsínROC y VaritaKIM ya fueron presentados en la Especificaciones IV.11 IV.12 del
Capítulo IV.
Individual PreseleccionesRealizadas in View isA ConjuntoVarianteC with
retrieved_attribute,partof
unReq: Relacion with
attribute,retrieved_attribute,partof
parte : Familia with
retrieved_attribute,partof
miembros: ConjuntoVariante with
constraint
rint: $A(this, componenteDirecto,this::unReq::parte::miembros)$
end
end
attribute,inherited_attribute
tipoRelacion : TipoRelacion;
quantityPer : ValorRestringido;
prodFactor:ValorRestringido
constraint
rint:$ A(this,enSTR,this::unReq)$
end
end
Especificación A.18. Vista PreseleccionesRealizadas
254
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
Por otra parte, la restricción de la vista más interna (rint), que define los valores que
toma el atributo unReq, permite restringir los valores que puede tomar el atributo miembros,
a aquéllos que también sean inferidos por el atributo componenteDirecto. La definición de
este último y de las reglas que posibilitan inferir sus valores se introduce en la Especificación
A.20. En la Figura IV.13, que fuera presentada en el Capítulo IV, se pueden observar los
valores inferidos para este atributo para el conjunto de variantes BolsínROC.
ConjuntoVarianteC with
attribute
enSTR: Relacion
rule
enSTRrule1:$ forall r/Relacion (this unReq r) and
(this relacionesModificadas r) ==> (this enSTR r)$;
enSTRrule2:$ forall r/Relacion (this unReq r) and
(this relacionesSeleccionadas r) ==> (this enSTR r)$;
enSTRrule3:$ forall r/Relacion (this unReq r) and
(this relacionesNOAfectadas r) ==> (this enSTR r)$
end
Especificación A.19. Definición del atributo enSTR
ConjuntodeVariantesC with
attribute
componenteDirecto:ConjuntodeVariantes;
rule
compDirectoRule : $ $forall cv1/ ConjuntodeVariantesC cv2/ConjuntodeVariantes
( exists p/Preseleccion (cv1 preselecciona p) and
(p ConjuntoSeleccionado cv2))==> (cv1 componenteDirecto cv2)$;
compDirectoRule2 : $ forall cv2/ConjuntodeVariantesC (exists f/Familia
(this fliaComponente f) and not (this componenteAfectado f) and
(cv2 miembroDe f)) ==> (this componenteDirecto cv2) $
end
Especificación A.20. Definición de los atributos componenteDirecto en la clase
ConjuntodeVariantes
En el
nivel de Producto final se presenta la vista VistaProducto (Especificación
A.21), la cual permite conocer, para cada producto, de qué conjunto de variantes y de qué
familia es miembro; así como los productos que selecciona (mostrando también para ellos
los conjuntos de variantes y las familias a las que éstos pertenecen).
Individual VistaProducto in View isA Producto with
inherited_attribute
descripcion:String
inherited_attribute,partof
miembroDe:ConjuntoVariante with
inherited_attribute
miembroDe:Familia
end
inherited_attribute,partof
selecciona:Seleccion with
inherited_attribute
produtoElegido:Producto with
inherited_attribute,partof
miembroDe:ConjuntoVariante with
inherited_attribute
miembroDe:Familia
255
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
end
end
end
end
Especificación A.21. Definición de VistaProducto
El resultado de la ejecución de esta vista se presenta en la Especificación A.22. En
ella se observa sólo el producto SE508219 (VaritaKIMFrutillaEnv), el cual es miembro del
conjunto de variantes VaritaKIM, que a su vez, es miembro de la familia CarameloFrutalEnv.
Se presentan en la vista también los valores para el atributo selecciona. En particular se
muestran las instancias selCarVarita y SelEnvVaritaKIM, las cuales tienen como
productoElegido a
SE408193 y a ME308386, respectivamente. El primero es miembro del
conjunto de variantes VaritaFrutal y, transitivamente de CarameloFrutalDes. Por su parte, el
segundo producto seleccionado, pertenece al conjunto de variantes EnvVaritaKIM, el cual es
miembro de la familia PapelEnvoltorio.
SE508219 in VistaProducto with
miembroDe
miembroDe : VaritaKIM with miembroDe
miembroDe : CarameloFrutalEnv
end
selecciona
selecciona1 : selCarVarita with productoElegido
productoElegido : SE408193 with miembroDe
miembroDe : VaritaFrutal with miembroDe
miembroDe : CarameloFrutalDes
end
end
end ;
selecciona2 : selEnvVaritaKIM with productoElegido
productoElegido : ME308386 with miembroDe
miembroDe : EnvVaritaKIM with miembroDe
miembroDe : PapelEnvoltorio
end
end
end
descripcion
descripcion : "VaritaKIMFrutillaEnv"
end
Especificación A.22. Resultados de la vista VistaProducto para el producto
SE508219 (VaritaKIMFrutillaEnv)
256
VIII. APÉNDICE B. ESPECIFICACIÓN OWL DE PRONTO
VIII.1. INTRODUCCIÓN
El objetivo del presente apéndice es presentar la especificación OWL (Ontology Web
Language) de la ontología de productos propuesta, denominada PRONTO. Inicialmente se
explican brevemente algunos elementos del lenguaje para posteriormente presentar el
código mencionado.
VIII.2. ELEMENTOS DEL LENGUAJE OWL
El objetivo de OWL es proveer un lenguaje para la representación de información en
la Web Semántica. Una ontología definida en OWL consiste de individuos, propiedades y
clases. Existen tres sublenguajes (o especies), cuya intención es dar soporte a diferentes
grupos de usuarios con distintos niveles de expresividad. Estas especies son:
OWL Full: involucra todos los constructores de OWL. Brinda el mayor poder de
expresión, pero tiene baja performance para los razonamientos.
OWL DL: provee un dialecto de la lógica descriptiva. Define un compromiso entre
expresividad y decidibilidad. Impone restricciones en cómo deben usarse algunos
constructores del lenguaje; estas restricciones son necesarias para que OWL sea decidible.
OWL Lite: Provee el conjunto mínimo de constructores del lenguaje para usuarios
que requieren simplicidad para la definición de ontologías.
VIII.2.1.
Clases
Las clases proveen un mecanismo para agrupar recursos con similares
características. Cada clase OWL está asociada con un conjunto de individuos denominado
extensión de clase y tiene un significado intensional que está relacionado con su extensión
de clase pero no es igual a ésta. Así por ejemplo, dos clases pueden tener la misma
extensión pero ser diferentes clases, ya que su significado intencional es distinto.
Las clases en OWL se definen mediante axiomas de clase que se construyen a partir
de una o más descripciones de clase.
Descripciones de clases
Una
descripción de clase, define una clase OWL por su nombre o mediante la
especificación de su extensión de clase. Se distinguen seis tipos de descripciones de clases:
257
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
7. identificador;
8. una enumeración exhaustiva de los individuos que conforman su conjunto de
instancias;
9. la imposición de restricciones sobre alguna propiedad de la clase;
10.
la intersección de dos o más clases;
11.
la unión de dos o más clases;
12.
el complemento de una clase.
El primer tipo describe una clase por su nombre. Los cinco tipos restantes identifican
clases anónimas, a través de la imposición de restricciones sobre su extensión de clase.
Las descripciones de clases de tipo 2 a 6 describen, respectivamente, una clase que
contiene exactamente los individuos enumerados (tipo 2), una clase conformada por todos
los individuos que satisfacen una restricción sobre una de sus propiedades (tipo 3), o una
clase que satisface combinaciones booleanas de otras descripciones de clases (tipos 4, 5 y
6). La intersección, la unión y el complemento pueden ser vistos como los operadores
lógicos AND, OR y NOT. Por otra parte, los últimos 4 tipos conducen a descripciones de
clases anidadas.
La sintaxis de una descripción de tipo 1 se representa como instancia de owl:Class.
Un ejemplo de este tipo se introduce en la Especificación B.1, para la clase Estructura.
<owl:Class rdf:ID="Estructura"/>
Especificación B.1. Ejemplo de una descripción de clase tipo 1
OWL define dos identificadores de clases: owl:Thing y owl:Nothing. La extensión del
primero es el conjunto de todos los individuos. Por el contrario, la extensión de owl:Nothing
es el conjunto vacío.
Descripción de clase tipo 2: Enumeración
Se define mediante la propiedad owl:oneOf. El valor de ésta debe ser una lista de los
individuos que conforman la clase. La extensión de una clase descripta de esta manera
coincide exactamente con la lista de valores indicados para la propiedad mencionada. Por
ejemplo, la descripción presentada en la Especificación B.2 define la clase que contiene
todos los caramelos envueltos que se producen en la planta de caramelos del caso de
estudio.
<owl:Class>
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#CarameloFrutaEnv"/>
<owl:Thing rdf:about="#CarameloLecheEnv"/>
<owl:Thing rdf:about="#CarameloMielEnv"/>
258
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<owl:Thing rdf:about="#CarameloMentolEnv"/>
</owl:oneOf>
</owl:Class>
Especificación B.2. Ejemplo de una descripción de clase tipo 2
Descripción de clase tipo 3: Restricción de propiedad
OWL distingue dos tipos distintos de restricciones de propiedad: restricciones de
valores y restricciones de cardinalidad. El primer tipo limita el rango de valores que puede
adoptar la propiedad, mientras que el segundo restringe la cantidad de valores que puede
tomar. En general tienen la forma que se indica en la Especificación B.3.
<owl:Restriction>
<owl:onProperty rdf:resource="(alguna propiedad)" />
(una restricción de valor o de cardinalidad)
</owl:Restriction>
Especificación B.3. Forma general de una descripción de clase tipo 3
Existen diferentes tipos de restricciones de valor y de cardinalidad. Los mismos se
presentan en la Tabla B.1.
Tabla B.1. Restricciones de propiedad definidas en OWL
Restricciones de Valor
Restricciones de Cardinalidad
owl:allValuesFrom
owl:cardinality
owl:someValuesFrom
owl:minCardinality
owl:hasValue
owl:maxCardinality
La restricción owl:allValuesFrom vincula una descripción de clase c1 con otra
descripción c2 o con un rango de valores. Describe la clase de todos los individuos que
tiene alguna instancia de c2 (o algún elemento del rango permitido) como valor de la
propiedad que está siendo restringida. La Especificación B.4 describe la clase anónima de
todos los individuos para los cuales la propiedad miembroDe sólo adopta valores de la clase
FamiliaC.
Es importante señalar que la restricción no indica que la propiedad sólo puede tener
como valores a instancias de FamiliaC, sino que esto es verdadero para las instancias de la
clase anónima que se está describiendo. Otro aspecto a resaltar es que esta restricción es
análoga al cuantificador universal de la lógica de predicados de primer orden (para cada
instancia de la clase que está siendo descripta todo valor de la propiedad debe cumplir la
restricción). Esto también implica que esta restricción es satisfecha trivialmente por aquellos
individuos que no tienen ningún valor para la propiedad que es restringida.
259
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<owl:Restriction>
<owl:onProperty rdf:resource="#miembroDe"/>
<owl:allValuesFrom rdf:resource="#FamiliaC"/>
</owl:Restriction>
Especificación B.4. Descripción de clase tipo 3 - owl:allValuesFrom
Como en el caso anterior, la restricción owl:someValuesFrom, vincula una clase
anónima con una descripción de clase o un rango de datos. Describe la clase de todos los
individuos para los cuales al menos un valor de la propiedad restringida es instancia de la
descripción de clase. Es análoga al cuantificador existencial de la lógica de predicados de
primer orden.
El ejemplo que se presenta en la Especificación B.5 describe la clase de los
individuos que tiene al menos una instancia de estructura para la propiedad derivaDe.
<owl:Restriction>
<owl:onProperty rdf:resource="#derivaDe"/>
<owl:someValuesFrom rdf:resource="#Estructura"/>
</owl:Restriction>
Especificación B.5. Descripción de clase tipo 3 - owl:someValuesFrom
Finalmente, owl:hasValue vincula una descripción de clase con un valor v1 y
describe a la clase de todos los individuos para los cuales la propiedad restringida tiene al
menos un valor semánticamente igual a v1. Que dos individuos sean semánticamente
iguales implica que tienen el mismo URI (Unified Resource Identification) o que están
explícitamente definidos como el mismo individuo (owl: sameAs). Como ejemplo de uso del
constructor owl:hasValue, considérese la Especificación B.6 que define una clase anónima
cuyas instancias deben tener el valor True para la propiedad esDerivada.
<owl:Restriction>
<owl:onProperty rdf:resource="#esDerivada"/>
<owl:hasValue rdf:resource="#True"/>
</owl:Restriction>
Especificación B.6. Descripción de clase tipo 3 - owl:hasValuesFrom
En OWL, se supone que cualquier instancia de una clase puede tener un número
arbitrario de valores para una propiedad. Las restricciones de cardinalidad permiten imponer
limitaciones en la cantidad de valores que una propiedad puede tener. Los tres tipos de
restricciones de cardinalidad vinculan una descripción de clase con un valor de tipo
nonNegativeInteger (uno de los tipos de datos definidos por XML-Schema y que representa
a los números enteros positivos).
La restricción owl:maxCardinality describe la clase de todos los individuos que
tienen a lo sumo N valores semánticamente diferentes para la propiedad restringida. En
260
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
cambio, owl:minCardinality describe la clase de todos los individuos que tiene al menos N
valores semánticamente diferentes para la propiedad restrigida. Finalmente, owl:cardinality
define la clase de todos los individuos que tienen exactamente N valores semánticamente
distintos para dicha propiedad. La Especificación B.7 describe, por ejemplo, la clase de los
individuos que tiene como máximo dos estructuras.
<owl:Restriction>
<owl:onProperty rdf:resource="#estructuraDe" />
<owl:maxCardinality
rdf:datatype="&xsd;nonNegativeInteger">2</owl:maxCardinality>
</owl:Restriction>
Especificación B.7. Descripción de clase tipo 3 - owl:maxCardinality
En cambio, la Especificación B.8 define la clase de los individuos que tiene como
mínimo dos estructuras.
<owl:Restriction>
<owl:onProperty rdf:resource="#estructuraDe" />
<owl:minCardinality
rdf:datatype="&xsd;nonNegativeInteger">2</owl:minCardinality>
</owl:Restriction>
Especificación B.8. Descripción de clase tipo 3 - owl:minCardinality
Finalmente, la clase de todos los individuos que tiene exactamente dos estructuras
se define en la Especificación B.9.
<owl:Restriction>
<owl:onProperty rdf:resource="#estructuraDe" />
<owl:Cardinality rdf:datatype="&xsd;nonNegativeInteger">2</owl:Cardinality>
</owl:Restriction>
Especificación B.9. Descripción de clase tipo 3 - owl:Cardinality
Descripción de clase tipo 4: Intersección de dos o más clases
El elemento owl:intersectionOf vincula una clase con una lista de descripciones de
clases. Una sentencia de este tipo describe una clase para la cual la extensión de clase
contiene exactamente aquellos individuos que son miembros de la extensión de todas las
clases de la lista. En la Especificación B.10, el valor de owl:intersectionOf es una lista de
dos descripciones de clases definidas mediante enumeraciones. La primera posee cuatro
individuos y la segunda dos. El resultado de la intersección es una clase que contiene el
único individuo que pertenece a ambas enumeraciones: CarameloFrutaEnv.
<owl:Class>
<owl:intersectionOf rdf:parseType="Collection">
<owl:Class>
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#CarameloFrutaEnv"/>
261
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<owl:Thing rdf:about="#CarameloLecheEnv"/>
<owl:Thing rdf:about="#CarameloMielEnv"/>
</owl:oneOf>
</owl:Class>
<owl:Class>
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#CarameloFrutaEnv"/>
<owl:Thing rdf:about="#CarameloMentolEnv"/>
</owl:oneOf>
</owl:Class>
</owl:intersectionOf>
</owl:Class>
Especificación B.10. Ejemplo de descripción de clase tipo 4
Es importante aclarar que el resultado es el indicado en el párrafo precedente con la
suponiendo que todos los individuos son diferentes. Esta situación no es por defecto
verdadera en OWL, ya que dicho lenguaje no aplica el criterio de unicidad de nombres (éste
indica que si dos individuos tienen identificadores diferentes, entonces son distintos). En
consecuencia, si se desea representar en OWL que dos individuos son diferentes esta
situación debe indicarse explícitamente mediante la sentencia owl:allDifferent.
Descripción de clase tipo 5: Unión de dos o más clases
Al igual que el tipo anterior, owl:unionOf vincula una clase con una lista de
descripciones de clase. Una sentencia de este tipo describe una clase anónima para la cual
la extensión contiene aquellos individuos que ocurren en al menos una de las extensiones
de clase de las descripciones de la lista. El ejemplo que se presenta en la Especificación
B.11
describe
una
clase
cuya
extensión
de
clase
contiene
cuatro
elementos:
CarameloFrutaEnv, CarameloLecheEnv, CarameloMielEnv y CarameloMentolEnv.
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class>
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#CarameloFrutaEnv"/>
<owl:Thing rdf:about="#CarameloLecheEnv"/>
<owl:Thing rdf:about="#CarameloMielEnv"/>
</owl:oneOf>
</owl:Class>
<owl:Class>
<owl:oneOf rdf:parseType="Collection">
262
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<owl:Thing rdf:about="#CarameloFrutaEnv"/>
<owl:Thing rdf:about="#CarameloMentolEnv"/>
</owl:oneOf>
</owl:Class>
</owl: unionOf>
</owl:Class>
Especificación B.11. Ejemplo de descripción de clase tipo 5
Descripción de clase tipo 6: Complemento de una clase
Una sentencia owl:complementOf vincula una clase con una única descripción de
clase y describe una clase anónima cuya extensión contiene exactamente todos los
individuos que no pertenecen a la extensión de la clase que aparece como objeto de la
sentencia. El ejemplo que se presenta en la Especificación B.12 define una clase cuyos
individuos son todos aquellos que no poseen un valor para la propiedad derivaDe que
pertenezca a la clase Estructura.
<owl:complementOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#derivaDe"/>
<owl:someValuesFrom rdf:resource="#Estructura"/>
</owl:Restriction>
</owl:complementOf>
Especificación B.12. Ejemplo de descripción de clase tipo 6
Otro ejemplo más sencillo se muestra, a continuación, en la Especificación B.13. En
ésta se define una clase anónima cuyas instancias son todos aquellos individuos que no
pertenecen a la extensión de la clase FamiliaC.
<owl:Class>
<owl:complementOf>
<owl:Class rdf:about="#FamiliaC"/>
</owl:complementOf>
</owl:Class>
Especificación B.13. Otro ejemplo sencilla de descripción de clase tipo 6
Estas descripciones de clases que fueron presentadas constituyen los bloques
constructores a partir de los cuales se especifican los axiomas de clases, los cuales
permiten combinar varias descripiones para generar definiciones más complejas.
Axiomas de clases
Las descripciones de clases introducidas en los párrafos precedentes constituyen los
bloques básicos para la definición de clases a través de axiomas de clases. El axioma de
clase más simple consiste en una descripción de clase de tipo 1. Este axioma sólo indica la
existencia de la clase usando owl:Class con un identificador. Tal es el caso de la definción
de la clase Abstracción de producto que se muestra en la Especificación B.14.
263
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<owl:Class rdf:ID="AbstracciondeProducto"/>
Especificación B.14. Ejemplo de un axioma de clase
Una definición de este tipo no brinda información sobre la clase excepto su nombre.
En general, los axiomas establecen condiciones necesarias y/o suficientes para que un
individuo sea instancia de la clase que dicho axioma define. Si una clase es descrita con su
nombre o solamente con condiciones necesarias, dicha clase es conocida como clase
primitiva. En caso de estar especificada a través de condiciones necesarias y suficientes se
la menciona como clase definida o no primitiva.
OWL provee tres constructores para combinar descripciones de clases en axiomas, a
saber: rdf:subClassOf, owl:equivalenteClass y owl:disjointWith, los cuales se introducen
a continuación
rdf: subClassOf
Este constructor es definido como parte de RDF-Schema y mantiene su significado
en OWL. Si una descripción de clase c1 se define como subclase de la descripción de clase
c2, entonces el conjunto de individuos en la extensión de clase de c1 es un subconjunto de
la extensión de clase de c2. Una clase es, por definición, subclase de si misma. Como
ejemplo, considérese el axioma de clase que define a FamiliaC.
En la Especificación B.15 se define que la clase FamiliaC es subclase de Familia y
de las clases anónimas definidas por las dos descripciones tipo 3.
Este axioma provee definiciones parciales; es decir, representa condiciones
necesarias pero no suficientes para determinar la pertenencia de un individuo a una clase.
Para efectuar especificaciones completas, OWL provee el constructor que se presenta en el
punto siguiente.
<owl:Class rdf:ID="FamiliaC">
<rdfs:subClassOf rdf:resource="#Familia"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#estructuraDe"/>
<owl:someValuesFrom rdf:resource="#Estructura"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#estructuraDe"/>
<owl:allValuesFrom rdf:resource="#Estructura"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
264
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
Especificación B.15. Ejemplo de uso del constructor owl:subClassOf
owl:equivalentClass
Un
axioma
de
clase
puede
contener
más
de
una
sentencia
de
owl:equivalenteClass. Esta sentencia vincula una descripción de clase con otra, indicando
que
ambas
poseen
el
mismo
conjunto
extensión.
Es
importante
aclarar
que
owl:equivalentClass no implica igualdad de clases (que las dos clases tengan el mismo
significado intencional), sino igualdad de sus extensiones de clase. La igualdad de clase se
define, en OWL, por el constructor owl:sameAs. Como ejemplo se presenta en la
Especificación B.16, el axioma que define a la clase MateriaPrima.
<owl:Class rdf:ID="MateriaPrima">
<owl:equivalentClass>
<owl:Class>
<owl:intersectionOf rdf:parseType="Collection">
<owl:Restriction>
<owl:onProperty rdf:resource="#esDerivada"/>
<owl:hasValue rdf:resource="#False"/>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#esEnsamblada"/>
<owl:hasValue rdf:resource="#False"/>
</owl:Restriction>
</owl:intersectionOf>
</owl:Class>
</owl:equivalentClass>
<rdfs:subClassOf rdf:resource="#Familia"/>
<owl:disjointWith rdf:resource="#FamiliaDerivada"/>
<owl:disjointWith rdf:resource="#FamiliaEnsamblada"/>
</owl:Class>
Especificación B.16. Ejemplo de uso del constructor owl: equivalentClass
En la Especificación B.16 se muestra la definición de una condición necesaria
(owl:subClassOf) y de axiomas owl:disjoinWith, los cuales se explican a continuación.
owl:disjointWith
Esta sentencia vincula dos descripciones de clase e indica que las extensiones de
clase de ambas no tienen individuos en común. Al igual que rdf:subClassOf define
condiciones necesarias para ser instancia de una clase. Un ejemplo simple, que se presenta
en la Especificación B.17, indica que las clases FamiliaC y FamiliaS son disjuntas.
<owl:Class rdf:ID="FamiliaC">
<owl:disjointWith rdf:resource="#FamiliaS"/>
</owl:Class>
Especificación B.17. Ejemplo de uso del constructor owl:disjointWith
265
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
Otro empleo de este constructor se presenta para la definición de axiomas de
cobertura, los cuales permiten restringir las instancias de una clase a una lista exhaustiva.
Un ejemplo es el axioma de cobertura que se define para la clase TipoRelacion y que se
muestra en la Especificación B.18. Para ello, el constructor owl:disjointWith se utiliza junto
con owl:unionOf y owl:equivalentClass.
<owl:Class rdf:ID="TipoRelacion">
<owl:equivalentClass>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Obligatoria"/>
<owl:Class rdf:about="#Optativa"/>
<owl:Class rdf:about="#Selectiva"/>
</owl:unionOf>
</owl:Class>
</owl:equivalentClass>
</owl:Class>
<owl:Class rdf:ID="Obligatoria">
<rdfs:subClassOf rdf:resource="#TipoRelacion"/>
<owl:disjointWith rdf:resource="#Optativa"/>
<owl:disjointWith rdf:resource="#Selectiva"/>
</owl:Class>
<owl:Class rdf:ID="Optativa">
<rdfs:subClassOf rdf:resource="#TipoRelacion"/>
<owl:disjointWith rdf:resource="#Selectiva"/>
<owl:disjointWith rdf:resource="#Obligatoria"/>
</owl:Class>
<owl:Class rdf:ID="Selectiva">
<rdfs:subClassOf rdf:resource="#TipoRelacion"/>
<owl:disjointWith rdf:resource="#Obligatoria"/>
<owl:disjointWith rdf:resource="#Optativa"/>
</owl:Class>
Especificación B.18. Ejemplo de la definición de axiomas de cobertura
VIII.2.2.
Propiedades
Para vincular los individuos OWL utiliza las propiedades, las cuales se definen
mediante axiomas de propiedad y pueden ser de dos tipos:
Propiedades objeto: vinculan individuo con individuo, y se definen como una
instancia de la clase predefinida owl:ObjectProperty
Propiedades tipo de datos: asocian un individuo con valores de tipos de datos
XML-Schema y se definen como una instancia de la clase predefinida
owl:DatatypeProperty. Ambas son subclases de rdf:Property y en OWL-Full
no son disjuntas. En cambio, en OWL-DL no pueden contener instancias en
común.
266
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
Las propiedades se definen por medio de axiomas de propiedad, los cuales en su
forma más simple establecen la existencia de la propiedad. El axioma que se presenta en la
Especificación B.19 establece la existencia de una propiedad miembroDe, cuyos valores
deben ser individuos.
<owl:ObjectProperty rdf:ID="miembroDe"/>
Especificación B.19. Ejemplo de axioma de propiedad
A menudo los axiomas de propiedad definen otras características. OWL soporta los
siguientes constructores para estos axiomas:
Constructores de RDF-Schema
Relaciones con otras propiedades
Restricciones globales de cardinalidad
Características lógicas de las propiedades.
Constructores RDF-Schema
Un axioma rdfs:subPropertyOf define que una propiedad es subpropiedad de otra.
En otras palabras, si p1 es subpropiedad de p2, entonces las instancias de p1 deben ser un
subconjunto de las instancias de p2. Las instancias de una propiedad pueden verse como
pares cuyos elementos corresponden a los individuos (o valores) que dicha propiedad está
vinculando.
El constructor rdfs-domain vincula una propiedad con una descripción de clase,
indicando que los sujetos de dicha propiedad deben ser instancias de dicha descripción de
clase.
Por su parte, rdfs:range vincula una propiedad con una descripción de clase o con
una rango de datos. Especifica que los valores de la propiedad deben pertenecer a dicha
descripción de clase (owl:ObjetctProperty) o a valores de datos dentro del rango indicado
(owl:DatatypeProperty).
Como ejemplo de estos dos constructores se presenta, en la Especificación B.20, la
propiedad miembroDe, la cual vincula individuos de la clase ConjuntodeVariantes y con
instancias de Familia.
<owl:ObjectProperty rdf:ID="miembroDe">
<rdfs:domain rdf:resource="#ConjuntodeVariantes"/>
<rdfs:range rdf:resource="#Familia"/>
</owl:ObjectProperty>
Especificación B.20.
rdfs:range
Ejemplo de uso de los constructores rdfs:domain y
267
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
Para una propiedad pueden definirse más de un owl:domain (owl:range). En este
caso, se restringe el dominio (rango) de la propiedad a todos aquellos individuos que
pertenecen a la intersección de las descripciones de clases indicada por cada owl:domain
(owl:range) que se incorpore al axioma de dicha propiedad. Si se desea especificar que
múltiples clases pertenecen al dominio (al rango) de una propiedad, se debe utilizar una
descripción de clase owl:unionOf.
Relaciones con otras propiedades
Sintácticamente, este grupo de constructores son propiedades predefinidas de OWL
que poseen propiedades como dominio y rango.
El constructor owl:equivalentProperty indica que dos propiedades tienen la misma
extensión de propiedad pero representan conceptos distintos.
Las propiedades OWL tienen una dirección, es decir se interpretan de dominio a
rango. La sentencia owl:inverseOf permite definir una propiedad en el sentido opuesto. Un
axioma de la forma p1 owl:inverseOf p2 implica que para todo par (x,y) que es instancia de
p1, existe el par (y,x) como instancia de p2.
El ejemplo que la propiedad inversa de
miembroDe es la propiedad miembros
<owl:ObjectProperty rdf:ID="miembroDe">
<owl:inverseOf rdf:resource="#miembros"/>
</owl:ObjectProperty>
Especificación B.21. Ejemplo de uso del constructor owl:inverseOf
Restricciones de cardinalidad global sobre propiedades
El constructor owl:FunctionalProperty designa a una propiedad como funcional.
Una propiedad de este tipo tiene un único valor y por cada valor de x. En otras palabras no
pueden existir dos valores y1 e y2 tal que los pares (x, y1) y (x, y2) sean ambos instancias
de dicha propiedad. El ejemplo que se presenta en la Especificación B.22 indica que existe
una única Familia de la que un ConjuntodeVariantes es miembro.
<owl:ObjectProperty rdf:ID="miembroDe">
<rdf:type rdf:resource="&owl;FunctionalProperty"/>
<rdfs:domain rdf:resource="#ConjuntodeVariantes"/>
<rdfs:range rdf:resource="#Familia"/>
</owl:ObjectProperty>
Especificación B.22. Ejemplo de uso del constructor owl: FunctionalProperty
Una forma sintácticamente equivalente de expresar el axioma anterior se presenta en
la Especificación B.23.
<owl:ObjectProperty rdf:ID="miembroDe">
<rdfs:domain rdf:resource="#ConjuntodeVariantes"/>
268
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<rdfs:range rdf:resource="#Familia"/>
</owl:ObjectProperty>
<owl:FunctionalProperty rdf:about="miembroDe"/>
Especificación B.23. Constructor owl: FunctionalProperty.
Afirmar que una propiedad P es owl:InverseFuncionalProperty, implica que un
valor y sólo puede ser valor de P para un único valor de x; es decir, no existen dos
instancias distintas x1 y x2 tal que los pares (x1,y) y (x2,y) sean instancias de P. Un ejemplo
de este tipo de propiedad se presenta en la Especificación B.24.
<owl:ObjectProperty rdf:ID="miembros">
<rdf:type rdf:resource="&owl;InverseFunctionalProperty"/>
<rdfs:domain rdf:resource="#Familia"/>
<rdfs:range rdf:resource="#ConjuntodeVariantes"/>
<owl:inverseOf rdf:resource="#miembroDe"/>
</owl:ObjectProperty>
Especificación
B.24.
owl:InverseFunctionalProperty
Ejemplo
de
uso
del
constructor
El axioma presentado en la Especificación B.24 implica que para cada objeto de la
sentencia
miembros
(algún
ConjuntodeVariantes)
debería
ser
posible
identificar
unívocamente el sujeto (alguna instancia de Familia).
Características lógicas de las propiedades
Cuando se define una propiedad P como transitiva, esto significa que si los pares
(x,y) e (y,z) son instancias de P se puede inferir que el par (x,z) también es instancia de P.
En OWL esto se representa haciendo que P sea instancia de la clase predefinida
owl:TransitiveProperty.
Un ejemplo de este constructor se presenta en la Especificación B.25. A partir de
este axioma un razonador es capaz de inferir que si CarameloFrutalEnv, CarameloFrutalDes
y RellenoFrutal son instancias de Familia y, además, RellenoFrutal esComponente de
CarameloFrutalDes y CarameloFrutalDes esComponente de CarameloFrutalEnv, entonces
RellenoFrutal esComponente de CarameloFrutalEnv.
<owl:TransitiveProperty rdf:ID="esComponente">
<rdfs:domain rdf:resource="#Familia"/>
<rdfs:range rdf:resource="#Familia"/>
</owl: TransitiveProperty>
Especificación B.25. Ejemplo de uso del constructor owl:TransitiveProperty
Si se expresa una propiedad P como instancia de la clase predefinida
owl:SymmetricProperty, se está indicado que dicha propiedad es simétrica. Esto implica
que si el par (x,y) es instancia de P, entonces el par (y,x) también es instancia. Como
269
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
ejemplo de este tipo de propiedad se presenta, en la Especificación B.26, un axioma que
define la propiedad simétrica estructuraAternativa.
<owl:SymmetricProperty rdf:ID="estructuraAlternativa">
<rdfs:domain rdf:resource="#Estructura"/>
<rdfs:range rdf:resource="#Estructura"/>
</owl:ObjectProperty>
Especificación B.26. Ejemplo de uso del constructor owl:SymmetricProperty
A partir del axioma anterior, y considerando que CuadrilConTapaSTR1 y ,
CuadrilConTapaSTR2 son instancias de Estructura y que CuadrilConTapaSTR1 es
estructuraAlternativa de CuadrilConTapaSTR2, un razonador inferirá que CuadirlCon
TapaSTR2 es estructuraAlternativa de CuadrilConTapaSTR1.
VIII.2.3.
Individuos
Los individuos se definen mediante axiomas de individuos, también llamados hechos.
OWL permite la aseveración de
Hechos sobre pertenencia a una clase y valores de propiedades.
Hechos sobre la identidad de los individuos
La mayor parte de los hechos son sentencias que determinan que un individuo
pertenece a una clase o define los valores de las propiedades de dicho individuo. Por
ejemplo, en la Especificación B.27, se define el individuo CarameloFrutaEnv como instancia
de FamiliaC y se establecen los valores de sus propiedades.
<pronto:Family rdf:ID="CarameloFrutaEnv">
<esDerivada rdf:resource="#false"/>
<esEnsamblada rdf:resource="#true"/>
<pronto:equivalenteA rdf:resource="http://www.owlontologies.com/catalogo.owl#CarameloFrutaEnv"/>
<pronto:estructuraDe rdf:resource="#CarameloFrutaEnvSTR"/>
</pronto:Family>
Especificación B.27. Definición de la instancia CarameloFrutaEnv
Por otra parte, OWL provee tres constructores para especificar hechos sobre la
identidad de los individuos:
owl:sameAs: se utiliza para indicar que dos URI se refieren al mismo
individuo
270
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
owl:differentFrom: se utiliza para indicar que dos URI se refieren a dos
individuos diferentes
owl:allDifferent: permite especificar que los individuos que pertenecen a una
lista son todos diferentes.
VIII.3. CÓDIGO OWL DE PRODUCT ONTOLOGY
A continuación se presenta el código OWL de la ontología propuesta, generado a
través editor de ontologías Protégé versión 3.2.1. La primera parte del código define los
espacios de nombres que se utilizan y las ontologías que son importadas en PRONTO.
<?xml version="1.0"?>
<rdf:RDF xmlns="http://www.pronto.com/[email protected]#"
xml:base="http://www.pronto.com/[email protected]"
xmlns:sumo="http://www.owl-ontologies.com/sumo.owl#"
xmlns:eclass="http://www.owl-ontologies.com/[email protected]#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:swrl="http://www.w3.org/2003/11/swrl#"
xmlns:protege="http://protege.stanford.edu/plugins/owl/protege#"
xmlns:swrlb="http://www.w3.org/2003/11/swrlb#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:daml="http://www.daml.org/2001/03/daml+oil#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:cat="http://www.owl-ontologies.com/catalogo.owl#">
<owl:Ontology rdf:about="Ontología de productos">
<owl:imports rdf:resource="http://www.owl-ontologies.com/catalogo.owl"/>
<owl:imports rdf:resource="http://www.owl-ontologies.com/sumo.owl"/>
</owl:Ontology>
VIII.3.1.
Definición de conceptos incluidos en PRONTO
A continuación se presentan los axiomas de clase y de propiedades que forman
parte de la ontología de productos propuesta. Las clases y las propiedades definidas se
encuentran ordenadas alfabéticamente para una fácil localización.
<owl:Class rdf:ID="AbstracciondeProducto"/>
<owl:Class rdf:ID="Boolean">
<owl:equivalentClass>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Falso"/>
<owl:Class rdf:about="#Verdadero"/>
</owl:unionOf>
</owl:Class>
</owl:equivalentClass>
</owl:Class>
271
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<owl:Class rdf:ID="Cambio"/>
<owl:ObjectProperty rdf:ID="cambioAplicado">
<rdfs:domain rdf:resource="#Modificacion"/>
<rdfs:range rdf:resource="#Cambio"/>
<owl:inverseOf rdf:resource="#IdecambioAplicado"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="CambioC">
<rdfs:subClassOf rdf:resource="#Cambio"/>
<owl:disjointWith rdf:resource="#Eliminacion"/>
</owl:Class>
<owl:ObjectProperty rdf:ID="componente">
<rdf:type rdf:resource="owl:TransitiveProperty"/>
<rdfs:domain rdf:resource="#FamiliaC"/>
<rdfs:range rdf:resource="#Familia"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="componenteDirecto">
<rdfs:domain rdf:resource="#FamiliaC"/>
<rdfs:range rdf:resource="#Familia"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="conformadoPor">
<rdfs:domain rdf:resource="#Estructura"/>
<rdfs:range rdf:resource="#Relacion"/>
<owl:inverseOf rdf:resource="#perteneceA"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="ConjuntodeVariantes">
<rdfs:subClassOf rdf:resource="#AbstracciondeProducto"/>
</owl:Class>
<owl:Class rdf:ID="ConjuntodeVariantesC">
<owl:equivalentClass>
<owl:Class>
272
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<owl:intersectionOf rdf:parseType="Collection">
<owl:Restriction>
<owl:onProperty rdf:resource="#derivaDe"/>
<owl:allValuesFrom rdf:resource="#Estructura"/>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#derivaDe"/>
<owl:someValuesFrom rdf:resource="#Estructura"/>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#miembroDe"/>
<owl:allValuesFrom rdf:resource="#FamiliaC"/>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#miembroDe"/>
<owl:someValuesFrom rdf:resource="#FamiliaC"/>
</owl:Restriction>
</owl:intersectionOf>
</owl:Class>
</owl:equivalentClass>
<rdfs:subClassOf rdf:resource="#ConjuntodeVariantes"/>
<owl:disjointWith rdf:resource="#ConjuntodeVariantesS"/>
</owl:Class>
<owl:Class rdf:ID="ConjuntodeVariantesS">
<owl:equivalentClass>
<owl:Class>
<owl:intersectionOf rdf:parseType="Collection">
<owl:Restriction>
<owl:onProperty rdf:resource="#miembroDe"/>
<owl:allValuesFrom rdf:resource="#FamiliaS"/>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#miembroDe"/>
<owl:someValuesFrom rdf:resource="#FamiliaS"/>
</owl:Restriction>
<owl:Class>
<owl:complementOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#derivaDe"/>
<owl:someValuesFrom rdf:resource="#Estructura"/>
</owl:Restriction>
</owl:complementOf>
</owl:Class>
</owl:intersectionOf>
</owl:Class>
</owl:equivalentClass>
<rdfs:subClassOf rdf:resource="#ConjuntodeVariantes"/>
<owl:disjointWith rdf:resource="#ConjuntodeVariantesC"/>
</owl:Class>
273
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<owl:ObjectProperty rdf:ID="conjuntoSeleccionado">
<rdfs:domain rdf:resource="#ConjuntodeVariantesC"/>
<rdfs:range rdf:resource="#Preseleccion"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="derivaDe">
<rdfs:range rdf:resource="#Estructura"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="derivado">
<rdf:type rdf:resource="owl:TransitiveProperty"/>
<rdfs:domain rdf:resource="#FamiliaC"/>
<rdfs:range rdf:resource="#Familia"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="derivadoDirecto">
<rdfs:domain rdf:resource="#FamiliaC"/>
<rdfs:range rdf:resource="#Familia"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="Eliminacion">
<rdfs:subClassOf rdf:resource="#Cambio"/>
<owl:disjointWith rdf:resource="#CambioC"/>
</owl:Class>
<owl:ObjectProperty rdf:ID="equivalenteA">
<rdfs:domain rdf:resource="#Family"/>
<rdfs:range rdf:resource="http://www.owlontologies.com/catalogo.owl#eClassCategory"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="esDerivada">
<rdfs:domain rdf:resource="#Familia"/>
<rdfs:range rdf:resource="#Boolean"/>
</owl:ObjectProperty>
274
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<owl:ObjectProperty rdf:ID="esEnsamblada">
<rdfs:domain rdf:resource="#Familia"/>
<rdfs:range rdf:resource="#Boolean"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="Estructura"/>
<owl:ObjectProperty rdf:ID="estructuraAlternativa">
<rdf:type
rdf:resource="owl:SymmetricProperty"/>
<rdf:type
rdf:resource="owl:TransitiveProperty"/>
<rdfs:domain rdf:resource="#Estructura"/>
<rdfs:range rdf:resource="#Estructura"/>
<owl:inverseOf rdf:resource="#estructuraAlternativa"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="EstructuraC">
<rdfs:subClassOf rdf:resource="#Estructura"/>
<owl:disjointWith rdf:resource="#EstructuraD"/>
</owl:Class>
<owl:Class rdf:ID="EstructuraD">
<rdfs:subClassOf rdf:resource="#Estructura"/>
<owl:disjointWith rdf:resource="#EstructuraC"/>
</owl:Class>
<owl:ObjectProperty rdf:ID="estructuraDe">
<rdfs:domain rdf:resource="#Familia"/>
<rdfs:range rdf:resource="#Estructura"/>
<owl:inverseOf rdf:resource="#IdeestructuraDe"/>
</owl:ObjectProperty>
<Falso rdf:ID="False"/>
<owl:Class rdf:ID="Falso">
<rdfs:subClassOf rdf:resource="#Boolean"/>
</owl:Class>
<owl:Class rdf:ID="Familia">
<rdfs:subClassOf rdf:resource="#AbstracciondeProducto"/>
</owl:Class>
275
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<owl:Class rdf:ID="FamiliaC">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#estructuraDe"/>
<owl:someValuesFrom rdf:resource="#Estructura"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#estructuraDe"/>
<owl:allValuesFrom rdf:resource="#Estructura"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#Familia"/>
<owl:disjointWith rdf:resource="#FamiliaS"/>
</owl:Class>
<owl:Class rdf:ID="FamiliaDerivada">
<owl:equivalentClass>
<owl:Class>
<owl:intersectionOf rdf:parseType="Collection">
<owl:Restriction>
<owl:onProperty rdf:resource="#esDerivada"/>
<owl:hasValue rdf:resource="#True"/>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#esEnsamblada"/>
<owl:hasValue rdf:resource="#False"/>
</owl:Restriction>
<owl:Class rdf:about="#Familia"/>
</owl:intersectionOf>
</owl:Class>
</owl:equivalentClass>
<owl:disjointWith rdf:resource="#FamiliaEnsamblada"/>
<owl:disjointWith rdf:resource="#MateriaPrima"/>
</owl:Class>
<owl:Class rdf:ID="FamiliaEnsamblada">
<owl:equivalentClass>
<owl:Class>
<owl:intersectionOf rdf:parseType="Collection">
<owl:Restriction>
<owl:onProperty rdf:resource="#esDerivada"/>
<owl:hasValue rdf:resource="#False"/>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#esEnsamblada"/>
<owl:hasValue rdf:resource="#True"/>
</owl:Restriction>
<owl:Class rdf:about="#Familia"/>
</owl:intersectionOf>
</owl:Class>
276
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
</owl:equivalentClass>
<owl:disjointWith rdf:resource="#FamiliaDerivada"/>
<owl:disjointWith rdf:resource="#MateriaPrima"/>
</owl:Class>
<owl:Class rdf:ID="FamiliaS">
<rdfs:subClassOf rdf:resource="#Familia"/>
<owl:disjointWith rdf:resource="#FamiliaC"/>
</owl:Class>
<owl:ObjectProperty rdf:ID="IdecambioAplicado">
<rdfs:domain rdf:resource="#Cambio"/>
<rdfs:range rdf:resource="#Modificacion"/>
<owl:inverseOf rdf:resource="#cambioAplicado"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="IdeestructuraDe">
<rdfs:domain rdf:resource="#Estructura"/>
<rdfs:range rdf:resource="#Familia"/>
<owl:inverseOf rdf:resource="#estructuraDe"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="IdemodificacionAplicada">
<rdfs:domain rdf:resource="#Modificacion"/>
<rdfs:range rdf:resource="#ConjuntodeVariantesC"/>
<owl:inverseOf rdf:resource="#modificacionAplicada"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="Incompatibilidad">
<rdfs:subClassOf rdf:resource="#TipoRestriccion"/>
<owl:disjointWith rdf:resource="#Obligatoriedad"/>
</owl:Class>
<owl:Class rdf:ID="MateriaPrima">
<owl:equivalentClass>
<owl:Class>
<owl:intersectionOf rdf:parseType="Collection">
<owl:Restriction>
<owl:onProperty rdf:resource="#esDerivada"/>
<owl:hasValue rdf:resource="#False"/>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#esEnsamblada"/>
<owl:hasValue rdf:resource="#False"/>
</owl:Restriction>
277
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
</owl:intersectionOf>
</owl:Class>
</owl:equivalentClass>
<rdfs:subClassOf rdf:resource="#Familia"/>
<owl:disjointWith rdf:resource="#FamiliaDerivada"/>
<owl:disjointWith rdf:resource="#FamiliaEnsamblada"/>
</owl:Class>
<owl:ObjectProperty rdf:ID="max">
<rdfs:range rdf:resource="http://www.owlontologies.com/sumo.owl#RealNumber"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="miembroDe">
<rdf:type rdf:resource="owl:FunctionalProperty"/>
<rdfs:domain rdf:resource="#ConjuntodeVariantes"/>
<rdfs:range rdf:resource="#Familia"/>
<owl:inverseOf rdf:resource="#miembros"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="miembroDecv">
<rdf:type rdf:resource="owl:FunctionalProperty"/>
<rdfs:domain rdf:resource="#Producto"/>
<rdfs:range rdf:resource="#ConjuntodeVariantes"/>
<owl:inverseOf rdf:resource="#miembrosDecv"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="miembros">
<rdfs:domain rdf:resource="#Familia"/>
<rdfs:range rdf:resource="#ConjuntodeVariantes"/>
<owl:inverseOf rdf:resource="#miembroDe"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="miembrosDecv">
<rdf:type rdf:resource="owl:InverseFunctionalProperty"/>
<rdfs:domain rdf:resource="#ConjuntodeVariantes"/>
<rdfs:range rdf:resource="#Producto"/>
<owl:inverseOf rdf:resource="#miembroDecv"/>
</owl:ObjectProperty>
278
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<owl:ObjectProperty rdf:ID="min">
<rdfs:range rdf:resource="sumo:RealNumber"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="Modificacion"/>
<owl:ObjectProperty rdf:ID="modificacionAplicada">
<rdfs:domain rdf:resource="#ConjuntodeVariantesC"/>
<rdfs:range rdf:resource="#Modificacion"/>
<owl:inverseOf rdf:resource="#IdemodificacionAplicada"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="nuevoPF">
<rdf:type rdf:resource="owl:FunctionalProperty"/>
<rdfs:domain rdf:resource="#Cambio"/>
<rdfs:range rdf:resource="#ValorUnidad"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="nuevoQP">
<rdfs:domain rdf:resource="#Cambio"/>
<rdfs:range rdf:resource="#ValorUnidad"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="Obligatoria">
<rdfs:subClassOf rdf:resource="#TipoRelacion"/>
<owl:disjointWith rdf:resource="#Optativa"/>
<owl:disjointWith rdf:resource="#Selectiva"/>
</owl:Class>
<Obligatoria rdf:ID="obligatoria"/>
<owl:Class rdf:ID="Obligatoriedad">
<rdfs:subClassOf rdf:resource="#TipoRestriccion"/>
<owl:disjointWith rdf:resource="#Incompatibilidad"/>
</owl:Class>
<owl:Class rdf:ID="Optativa">
<rdfs:subClassOf rdf:resource="#TipoRelacion"/>
<owl:disjointWith rdf:resource="#Selectiva"/>
279
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<owl:disjointWith rdf:resource="#Obligatoria"/>
</owl:Class>
<Optativa rdf:ID="optativa"/>
<owl:ObjectProperty rdf:ID="parte">
<rdf:type rdf:resource="owl:FunctionalProperty"/>
<rdfs:domain rdf:resource="#Relacion"/>
<rdfs:range rdf:resource="#Familia"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="perteneceA">
<rdfs:domain rdf:resource="#Relacion"/>
<rdfs:range rdf:resource="#Estructura"/>
<owl:inverseOf rdf:resource="#conformadoPor"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="Preseleccion"/>
<owl:ObjectProperty rdf:ID="presleciona">
<rdfs:domain rdf:resource="#Preseleccion"/>
<rdfs:range rdf:resource="#ConjuntodeVariantes"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="prodFactor">
<rdfs:domain rdf:resource="#Relacion"/>
<rdfs:range rdf:resource="#ValorRestringido"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="Producto">
<rdfs:subClassOf rdf:resource="#AbstracciondeProducto"/>
</owl:Class>
<owl:Class rdf:ID="ProductoC">
<rdfs:subClassOf rdf:resource="#Producto"/>
<owl:disjointWith rdf:resource="#ProductoS"/>
</owl:Class>
280
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<owl:ObjectProperty rdf:ID="productoElegido">
<rdf:type rdf:resource="owl:FunctionalProperty"/>
<rdfs:range rdf:resource="#Producto"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="ProductoS">
<rdfs:subClassOf rdf:resource="#Producto"/>
<owl:disjointWith rdf:resource="#ProductoC"/>
</owl:Class>
<owl:ObjectProperty rdf:ID="quantityPer">
<rdfs:domain rdf:resource="#Relacion"/>
<rdfs:range rdf:resource="#ValorRestringido"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="Relacion"/>
<owl:Class rdf:ID="RelacionC">
<rdfs:subClassOf rdf:resource="#Relacion"/>
<owl:disjointWith rdf:resource="#RelacionD"/>
</owl:Class>
<owl:Class rdf:ID="RelacionD">
<rdfs:subClassOf rdf:resource="#Relacion"/>
<owl:disjointWith rdf:resource="#RelacionC"/>
</owl:Class>
<owl:ObjectProperty rdf:ID="relacionModificacda">
<rdf:type rdf:resource="owl:FunctionalProperty"/>
<rdfs:domain rdf:resource="#Cambio"/>
<rdfs:range rdf:resource="#Relacion"/>
</owl:ObjectProperty>
281
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<owl:Class rdf:ID="RelacionObligatoria">
<owl:equivalentClass>
<owl:Class>
<owl:intersectionOf rdf:parseType="Collection">
<owl:Restriction>
<owl:onProperty rdf:resource="#tipoRelacion"/>
<owl:allValuesFrom rdf:resource="#Obligatoria"/>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#tipoRelacion"/>
<owl:someValuesFrom rdf:resource="#Obligatoria"/>
</owl:Restriction>
</owl:intersectionOf>
</owl:Class>
</owl:equivalentClass>
<rdfs:subClassOf rdf:resource="#Relacion"/>
<owl:disjointWith rdf:resource="#RelacionSelectiva"/>
<owl:disjointWith rdf:resource="#RelacionOptativa"/>
</owl:Class>
<owl:Class rdf:ID="RelacionOptativa">
<owl:equivalentClass>
<owl:Class>
<owl:intersectionOf rdf:parseType="Collection">
<owl:Restriction>
<owl:onProperty rdf:resource="#tipoRelacion"/>
<owl:allValuesFrom rdf:resource="#Optativa"/>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#tipoRelacion"/>
<owl:someValuesFrom rdf:resource="#Optativa"/>
</owl:Restriction>
</owl:intersectionOf>
</owl:Class>
</owl:equivalentClass>
<rdfs:subClassOf rdf:resource="#Relacion"/>
<owl:disjointWith rdf:resource="#RelacionSelectiva"/>
<owl:disjointWith rdf:resource="#RelacionObligatoria"/>
</owl:Class>
<owl:Class rdf:ID="RelacionSelectiva">
<owl:equivalentClass>
282
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<owl:Class>
<owl:intersectionOf rdf:parseType="Collection">
<owl:Restriction>
<owl:onProperty rdf:resource="#tipoRelacion"/>
<owl:allValuesFrom rdf:resource="#Selectiva"/>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#tipoRelacion"/>
<owl:someValuesFrom rdf:resource="#Selectiva"/>
</owl:Restriction>
</owl:intersectionOf>
</owl:Class>
</owl:equivalentClass>
<rdfs:subClassOf rdf:resource="#Relacion"/>
<owl:disjointWith rdf:resource="#RelacionOptativa"/>
<owl:disjointWith rdf:resource="#RelacionObligatoria"/>
</owl:Class>
<owl:Class rdf:ID="Restriccion"/>
<owl:Class rdf:ID="RestriccionCV">
<rdfs:subClassOf rdf:resource="#Restriccion"/>
<owl:disjointWith rdf:resource="#RestriccionP"/>
<owl:disjointWith rdf:resource="#RestriccionF"/>
</owl:Class>
<owl:Class rdf:ID="RestriccionF">
<rdfs:subClassOf rdf:resource="#Restriccion"/>
<owl:disjointWith rdf:resource="#RestriccionP"/>
<owl:disjointWith rdf:resource="#RestriccionCV"/>
</owl:Class>
<owl:Class rdf:ID="RestriccionIncomp">
<owl:equivalentClass>
<owl:Restriction>
<owl:onProperty rdf:resource="#tipoRestriccion"/>
<owl:someValuesFrom rdf:resource="#Incompatibilidad"/>
283
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
</owl:Restriction>
</owl:equivalentClass>
<rdfs:subClassOf rdf:resource="#Restriccion"/>
<owl:disjointWith rdf:resource="#RestriccionOblig"/>
</owl:Class>
<owl:Class rdf:ID="RestriccionOblig">
<owl:equivalentClass>
<owl:Restriction>
<owl:onProperty rdf:resource="#tipoRestriccion"/>
<owl:someValuesFrom rdf:resource="#Obligatoriedad"/>
</owl:Restriction>
</owl:equivalentClass>
<rdfs:subClassOf rdf:resource="#Restriccion"/>
<owl:disjointWith rdf:resource="#RestriccionIncomp"/>
</owl:Class>
<owl:Class rdf:ID="RestriccionP">
<rdfs:subClassOf rdf:resource="#Restriccion"/>
<owl:disjointWith rdf:resource="#RestriccionCV"/>
<owl:disjointWith rdf:resource="#RestriccionF"/>
</owl:Class>
<Incompatibilidad rdf:ID="RIncompatible"/>
<Obligatoriedad rdf:ID="RObligatoria"/>
<owl:ObjectProperty rdf:ID="selecciona">
<rdfs:domain rdf:resource="#ProductoC"/>
<rdfs:range rdf:resource="#Producto"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="Selectiva">
<rdfs:subClassOf rdf:resource="#TipoRelacion"/>
<owl:disjointWith rdf:resource="#Obligatoria"/>
<owl:disjointWith rdf:resource="#Optativa"/>
</owl:Class>
<Selectiva rdf:ID="selectiva"/>
<owl:Class rdf:ID="TipoRelacion">
<owl:equivalentClass>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Obligatoria"/>
<owl:Class rdf:about="#Optativa"/>
<owl:Class rdf:about="#Selectiva"/>
</owl:unionOf>
</owl:Class>
</owl:equivalentClass>
</owl:Class>
284
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<owl:ObjectProperty rdf:ID="tipoRelacion">
<rdf:type rdf:resource="owl:FunctionalProperty"/>
<rdfs:domain>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Relacion"/>
<owl:Class rdf:about="#RelacionObligatoria"/>
</owl:unionOf>
</owl:Class>
</rdfs:domain>
<rdfs:range rdf:resource="#TipoRelacion"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="TipoRestriccion">
<owl:equivalentClass>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Incompatibilidad"/>
<owl:Class rdf:about="#Obligatoriedad"/>
</owl:unionOf>
</owl:Class>
</owl:equivalentClass>
</owl:Class>
<owl:ObjectProperty rdf:ID="tipoRestriccion">
<rdf:type rdf:resource="owl:FunctionalProperty"/>
<rdfs:domain rdf:resource="#Restriccion"/>
<rdfs:range rdf:resource="#TipoRestriccion"/>
</owl:ObjectProperty>
<Verdadero rdf:ID="True"/>
<owl:ObjectProperty rdf:ID="udeM">
<rdf:type rdf:resource="owl:FunctionalProperty"/>
<rdfs:domain rdf:resource="#ValorUnidad"/>
<rdfs:range rdf:resource="sumo:UnitOfMeasure"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="valor">
<rdfs:range rdf:resource="sumo:RealNumber"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="ValorRestringido">
<rdfs:subClassOf rdf:resource="#ValorUnidad"/>
</owl:Class>
285
_____________________________________________ Apéndice A. Definición de Vistas en Conceptbase
<owl:Class rdf:ID="ValorUnidad"/>
<owl:Class rdf:ID="Verdadero">
<rdfs:subClassOf rdf:resource="#Boolean"/>
</owl:Class>
</rdf:RDF>
286