UNIVERSIDAD TECNOLÓGICA NACIONAL FACULTAD REGIONAL SANTA FE DOCTORADO EN INGENIERÍA

Tamaño: px
Comenzar la demostración a partir de la página:

Download "UNIVERSIDAD TECNOLÓGICA NACIONAL FACULTAD REGIONAL SANTA FE DOCTORADO EN INGENIERÍA"

Transcripción

1 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

2

3 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

4

5 A Ivan, Facundo y Martina A mis padres

6

7 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

8

9 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, permitio 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

10 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 exterse 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

11 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, (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, (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, (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 rd Mercosur Congress on Process Systems Engineering 1 st Mercosur Congress on Chemical Engineering, Santa Fe Argentina, 16 al 20 de setiembre de Un Modelo de Estructura de Productos para Industrias de Procesos. Marcela Vegetti, Gabriela Henning y Horacio Leone. CAIP º Congreso Interamericano de Computación Aplicada a la Industria de Procesos, Campos do Jordão Brasil, 22 al 25 de octubre de 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 IX

12 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 PRoduct ONTOlogy. Definition of an Ontology for Complex Product Modelling Domain. Marcela Vegetti, Gabriela Henning y Horacio Leone. ENPROMER nd Mercosur Congress on Chemical Engineering and 4 th Mercosur Congress on Process Systems Engineering, Río de Janeiro Brasil, 14 al 18 de Agosto de 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., (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, (2005) Towards a Supply Chain Ontology of Information Logistics within Process Industry Environments. Marcela Vegetti, Silvio Gonnet, Gabriela Henning, y Horacio Leone. ENPROMER nd Mercosur Congress on Chemical Engineering and 4 th Mercosur Congress on Process Systems Engineering, Río de Janeiro Brasil, 14 al 18 de Agosto de X

13 Í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

14 Í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

15 Í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

16 Índice XIV

17 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 PT (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

18 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

19 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 SE (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

20 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 extien 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 SE (VaritaKIMFrutillaEnv) 189 Figura V.29. Gestión del Producto SE Selección PapelEnvoltorio 190 Figura V.30. Gestión del Producto SE 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

21 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

22

23 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 PT (FrutalRelleno5x750GR) 52 Tabla II.5. BOM de un nivel del producto PT (RedondoFrutaKIM5x750GR) 53 Tabla II.6. BOM de un nivel del producto PT (VaritaKIM5X750GR) 53 Tabla II.7. BOM de un nivel del producto SE (VaritaKIMFrutillaEnv) 53 Tabla II.8. BOM de un nivel del producto SE (BolsínFrutilla5GREnv) 53 Tabla II.9. BOM de un nivel del producto SE (FrutillaKIM5GREnv) 54 Tabla II.10. BOM de un nivel del producto SE (BolsinFrutillaZ) 55 Tabla II.11. BOM de un nivel del producto SE (BolsínFrutilla5GRDes) 55 Tabla II.12. BOM de un nivel del producto SE (BolsínFrutillaDes) 55 Tabla II.13. BOM de un nivel del producto SE (RellenoPera) 56 Tabla II.14. BOM de un nivel del producto SE (RellenoCereza) 57 Tabla II.15. BOM de un nivel del producto SE (RellenoFrutilla) 57 Tabla II.16. BOM de un nivel del producto SE808946(RellenoPomelo) 57 Tabla II.17. BOM de un nivel del producto SE (RellenoLima) 57 Tabla II.18. BOM de un nivel del producto SE (MasaPera) 58 Tabla II.19. BOM de un nivel del producto SE (MasaCereza) 58 Tabla II.20. BOM de un nivel del producto SE (MasaFrutilla) 58 Tabla II.21. BOM de un nivel del producto SE (MasaPomelo) 59 Tabla II.22. BOM de un nivel del producto SE60915 (MasaLima) 59 Tabla II.23. BOM de un nivel del producto SE (MasaFrutillaMIX) 60 Tabla II.24. BOM de un nivel del producto SE (MasaFrutillaOK) 60 Tabla II.25. BOM de un nivel del producto SE (MasaFrutillaEFE) 60 Tabla II.26. BOM de un nivel del producto SE (MasaCerezaOK) 61 XXI

24 Lista de Tablas Tabla II.27. BOM de un nivel del producto SE (MasaCerezaA) 62 Tabla II.28. BOM de un nivel del producto SE (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

25 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

26 Lista de Tablas XXIV

27 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

28 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

29 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

30 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 tencia 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 prete 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

31 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 entie 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

32 El Modelo de Productos en las Organizaciones Industriales Introducción Crecimiento Madurez Declinación Retiro INP 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

33 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 vidos 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 surgio así, la necesidad de tener sistemas que administren estos archivos eficientemente. 4

34 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 extieron las competencias de estos sistemas más allá de las áreas de diseño e ingeniería, surgio 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; permitio que los productos sean configurados de acuerdo a los deseos de los clientes. 5

35 El Modelo de Productos en las Organizaciones Industriales Administración de datos y documentos Administración de procesos y flujos de materiales 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 entie 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

36 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 ve 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

37 El Modelo de Productos en las Organizaciones Industriales P1 r1 r2 r3 M1 C1 E1 r4 r5 r6 M2 M3 M4 Mi Ci Pi E1 ri Materia Prima i Componente i Producto Teminado Ensamblado Intermedio Relación de composición 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 tencia 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 obtrí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 r2 *r4 r3 *r5 r3 *r6 M1 M2 M3 M4 Mi Ci Pi E1 ri Materia Prima i Componente i Producto Teminado Ensamblado Intermedio Relación de composición Cantidad de composición Figura I.5. Bill of Materials aplanado de un producto final 8

38 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 Componente Unidades Unidad de medida requeridas 1 M1 r1 Unidad 1 C1 r2 Unidad.2 M2 r4 Unidad 1 E1 r3 Unidad.2 M3 r5 Unidad.2 M4 r6 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 r2 r3 M1 C1 E1 Mi Materia Prima i C1 E1 Ci Pi Componente i Producto Teminado r4 M2 r5 M3 r6 M4 E1 ri Ensamblado Intermedio Relación de composición Cantidad de composición Figura I.6. BOMs de un único nivel Tabla I.2: Listado de componentes del producto P1 Componente Unidades requeridas Unidad de medida M1 r1 Unidad C1 r2 Unidad E1 r3 Unidad 9

39 El Modelo de Productos en las Organizaciones Industriales Tabla I.3: Listado de componentes del producto C1 Componente Unidades requeridas Unidad de medida M2 R4 Unidad Tabla I.4: Listado de componentes del producto E1 Componente Unidades requeridas Unidad de medida M3 r5 Unidad M4 r6 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 vidos 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

40 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 vida a los clientes, mientras que el resto participa como materia prima en la estructura de composición asociada al producto P5. 2 (a) P1 1 1 E1 E M1 M2 M3 M4 P E7 M1 M4 P1 P2 P3 P E3 E M (b) 1 2 M3 E8 P4 E Mi Pi Materia Prima i Producto Teminado i M8 (c) Ei Ensamblado Intermedio i Operación de ensamblado Operación de desensamblado Figura I.7. Diferentes tipos de estructuras de productos 11

41 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 P E1 E M1 M2 M3 M4 1 2 E4 1 E3 2 3 M6 E2 4 2 M3 M4 M1 M2 (a) (b) P1 Mi Materia Prima i Pi Producto Teminado i 2 M1 4 M M6 M3 M4 Ei Ensamblado Intermedio i Operación de ensamblado (c) Operación de desensamblado Figura I.8: Estructuras alternativas 12

42 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 tencias 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 e, 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

43 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 vidos 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 depe 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 extidas donde intervienen clientes, proveedores, operadores logísticos, etc. 14

44 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 surgio versiones de productos más frecuentemente, junto con sus correspondientes representaciones BOM. Algunas de éstas serán válidas para productos fabricados y vidos 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 surgio 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 depio 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

45 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 prete 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, rompio barreras geográficas y permitio 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

46 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á sio 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, entible 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 entie 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

47 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 tencia 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

48 El Modelo de Productos en las Organizaciones Industriales productos con múltiples variantes. La primera de ellas, que simplemente prete adaptar la representación BOM tradicional al manejo de variantes, plantea tres opciones: i) BOM básico: Cada variante tiene asociado su BOM. ii) iii) 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. BOM más-menos: toma una de las variantes como base y las otras se estructuran tenio 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 v2 v3 E4 E 1 E 2 E 3 E 5 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

49 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 E 1 E 2 E 3 E 5 Figura I.10. Gestión de Variantes. Estrategia 1- BOM parte idéntica v1 v3 V E1 E 2 E 3 E 4 E 5 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. Siguio 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

50 El Modelo de Productos en las Organizaciones Industriales VF V1 VF V2 V3 E1 E2 E3 E4 E5 E1 E2 E3 E4 E5 (a) (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 trá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. V2 E1 E2 E3 E4 E5 Se genera un pedido para la variante V2 Información almacenada 5 entidades partes, 0 relaciones estructurales Se establecen las relaciones estructurales relativas a la orden para la variante V2 21

51 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 indepientes, 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

52 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, sio 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

53 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 prete 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

54 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. Siguio 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

55 El Modelo de Productos en las Organizaciones Industriales variante, que el procesador BOM tomará, para la definición de una estructura BOM individual, tenio 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

56 El Modelo de Productos en las Organizaciones Industriales Referencia Compuesto-de BOM Compuesto-de Propiedad Posee Agregación Componente Producto 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. Siguio 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

57 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 depe 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á sio 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 Niveles de producto Patrón Dos Niveles usa BOMs Aplicados Patrón Un Nivel Patrón Variaciones usa usa usa Asociación BOMs a productos Documentos Aplicados 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

58 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 Especialización de Asociado a Conforme a Order BOM Estructura de Elemento aa Elemento 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

59 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 tencia 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

60 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, constituyo 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 despre 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

61 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 compre 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

62 El Modelo de Productos en las Organizaciones Industriales 33

63 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 enter 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 hacio 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

64 Dominio de trabajo. Caracterización y definición de su Alcance Según de Heij (1996), pueden plantearse diferentes clasificaciones tenio 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. Tamaño del lote Único ítem Largas series Pequeñas series Continuo Flujo de materiales Industrias de Manufactura Discreta Industrias de Procesos Continuos Industrias de Procesos Batch Industrias de Procesos Semicontinuos Organización física del proceso productivo Manufactura flexible Job shop Floor Shop Proceso de Manufactura Continuo Estructura del proceso productivo 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

65 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

66 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 compre 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

67 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, suspié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

68 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; sio 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, pudio 38

69 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. Infomezcla fracmol fracmas fracvol Mezcla tipo 2..* 1..* Sustancia alias Componente SólidoAmorfo NombreSustancia 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

70 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

71 Dominio de trabajo. Caracterización y definición de su Alcance Producto1 Alimentación A H 40 % ACaliente IntBC 40 % R2 60 % 60 % IntAB EImpuro 10 % S 90 % Producto2 50 % 80 % R1 R3 Alimentación B 50 % 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. TareaBatch Estado RelaciónT-E TamañoDeLote TiempoProcesamiento EquipoBatch Entrada Flujo Salida Alimentación Producto Intermedio Producto Final Figura II.4. Algunos de los conceptos involucrados en una representación STN para un 41

72 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

73 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 Distribución Venta 1 DOS Compra Manufactura Ensamblado Distribución Venta 2 MTS Compra Manufactura Ensamblado Distribución Venta 3 ATO Compra Manufactura Ensamblado Distribución Venta 4 MTO Compra Manufactura Ensamblado Distribución Venta 5 ETO 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

74 Dominio de trabajo. Caracterización y definición de su Alcance Tabla II.1 Comparación de diferentes entornos productivos Características CODP ETO MTO ATO MTS Actividades de mayor importancia para la gerencia superior Contratos de órdenes de clientes Capacidad productiva Innovación Marketing Distribució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 Control del piso de planta 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 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 tien 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 e, 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

75 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 tenio 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, indepientemente 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) iii) Orientada al Proceso (OPC): si ha hecho considerables inversiones en el desarrollo del proceso productivo. 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

76 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, depio 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 indepientes del flujo de órdenes y materiales y depientes de dicho flujo. Estos dos tipos de sistemas trán 46

77 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 trán los sistemas indepientes por sobre los depientes. Contrariamente, a medida que el CODP se desplaza hacia las primeras etapas de producción, la importancia de los sistemas depientes del flujo de órdenes comienza a crecer, en tanto decrece la de los sistemas indepientes. La información que es gestionada por los sistemas indepientes 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 depientes 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

78 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 Información de BOMs y rutas de producción MTS Totalmente conocida al momento de recibir la orden del cliente ETO 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 Explosión de requerimientos Por número de parte Definida a partir del BOM por la actividad de planificación de requerimientos de materiales Por orden de trabajo 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

79 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 vidos 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, respondio 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

80 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 SE representa al colorante ColRojoRt54, en tanto, ME 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 depio 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

81 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. Nivel 0 P Nivel 1 SE1 ME 1.1 ME 1.2 ME 1.n Nivel 2 ME 2.1 ME 2.n SE 2.1 Nivel 3 SE 3.1 ME 3.1 ME 3.2 Nivel 4 SE 4.1 SE 4.2 Nivel 5 SE 5.1 MP 5.1 MP 5.n SE 5.2 SE 5.3 MP 5.n+1 MP 5.m MEi Materia de Empaque i Nivel 6 MP 6,1 MP 6,n SE 6.1 MP 6,n+1 MP 6,i MP 6.i+1 MP 6.m MPi Materia Prima i Pi Producto Teminado Nivel 7 MP 7.1 MP 7.n 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

82 Dominio de trabajo. Caracterización y definición de su Alcance Figura II.7. Árbol de estructura multinivel para el producto PT (FrutalRelleno5x750GR) En la Figura II.7 se presenta el árbol de estructura del producto terminado PT (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 PT (FrutalRelleno5x750GR) Componente Unidades Unidad de requeridas medida SE BolsínFrutilla5GREnv KG SE BolsínPera5GREnv KG SE BolsínPomelo5GREnv KG SE BolsínLima5GREnv KG SE BolsínCerez5GREnv KG ME PeRellenoF750GR KG ME EtFrutal5x750GR 1 UNID ME SeparadorT UNID * ME PExtensibleb KG * ME CajaCarx750GR 1 UNID * ME CintaAdh50x M * ME EtiqueraFrutal750GR 6 UNID De igual manera se presentan en las Tablas II.5 y II.6 los componentes de otros productos finales: PT (RedondoFrutaKIM5x750GR) y PT (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 SE (VaritaKIMFrutillaEnv), SE (BolsínFrutilla5GREnv) y SE (FrutillaKIM5GREnv), cuyas estructuras se presentan seguidamente en la Figura II.8 y en las 52

83 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 PT (RedondoFrutaKIM5x750GR) Componente Unidades Unidad de requeridas medida ME PeCarKIMx750GR KG ME EtFrutalKIM750ws 6 UNID ME EtFrutalKIM750p 1 UNID ME SeparadorT UNID * ME PExtensibleb UNID * ME CintaAdh50x M * ME CajaCarx750GR 1 UNID * SE PeraKIM5GREnv KG SE PomeloKIM5GREnv KG SE LimaKIM5GREnv KG SE FrutillaKIM5GREnv KG SE CerezaKIM5GREnv KG Tabla II.6. BOM de un nivel del producto PT (VaritaKIM5X750GR) Componente Unidades Unidad de requeridas medida SE VaritaKIMPeraEnv KG SE VaritaKIMFrutillaEnv KG SE VaritaKIMDuraznoEnv KG SE VaritaKIMPomeloEnv KG SE Varita KIM LimaEnv KG ME PeCarKIMx750GR KG ME EtVaritaKIM750 6 UNID ME EtVaritaKIM22x80 1 UNID ME SeparadorT UNID * ME PExtensibleb UNID * ME CintaAdh50x M * ME CajaCarx750GR 1 UNID * Tabla II.7. BOM de un nivel del producto SE (VaritaKIMFrutillaEnv) Componente Unidades Unidad de requeridas medida SE VaritaFrutillaDes KG ME EnvVaritaKIMFrutilla KG Tabla II.8. BOM de un nivel del producto SE (BolsínFrutilla5GREnv) Unidades Unidad de Componente requeridas medida SE BolsínFrutilla5GRDes KG 53

84 Dominio de trabajo. Caracterización y definición de su Alcance ME PapelSepBolsín KG ME EnvBolsínFrutillaROC KG Tabla II.9. BOM de un nivel del producto SE (FrutillaKIM5GREnv) Componente Unidades Unidad de requeridas medida SE BolsínFrutilla5GRDes KG ME InteriorBolsin KG ME EnvBolsínFrutillaKIM 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 SE (VaritaKIMFrutillaEnv) posee solamente el papel envoltorio ME (EnvVaritaKIMFrutilla); mientras que los otros dos tienen un papel separador (ME y ME910113) y los correspondientes papeles de envoltorio (ME y ME108346). Figura II.8. Estructuras de tres semielaborados tomados como ejemplo Asimismo, existe también otro producto intermedio, el SE (BolsínFrutillaZ), que se muestra en la Tabla II.10, cuya composición es similar al caramelo envuelto SE (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 SE (BolsínFrutilla5GRDes) y en el otro con el SE (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 SE y un relleno sabor frutilla SE Sin 54

85 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 SE (BolsinFrutillaZ) Componente Unidades Unidad de requeridas medida SE BolsínFrutillaDes GR ME PapelSepBolsín GR ME EnvBolsínFrutillaROC GR Tabla II.11. BOM de un nivel del producto SE (BolsínFrutilla5GRDes) Componente Unidades Unidad de requeridas medida SE Relleno Frutilla 17 GR SE MasaFrutilla 83 GR Tabla II.12. BOM de un nivel del producto SE (BolsínFrutillaDes) Componente Unidades Unidad de requeridas medida SE Relleno Frutilla 19 GR SE MasaFrutilla 81 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

86 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á envolvio. Asimismo, todos los semielaborados se componen de una masa y un relleno del correspondiente sabor. Por ejemplo, el producto intermedio SE (BolsínLima5GRDes) se compone de una masa y un relleno sabor lima (semielaborados SE y SE 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 SE (RellenoPera) Componente Unidades requeridas Unidad de medida 56

87 Dominio de trabajo. Caracterización y definición de su Alcance MP EsenciaPeraP GR SE RellenoMermelada GR Tabla II.14. BOM de un nivel del producto SE (RellenoCereza) Componente Unidades Unidad de requeridas medida SE ColRojoRx GR MP EsenciaCerezaP GR SE RellenoMermelada GR Tabla II.15. BOM de un nivel del producto SE (RellenoFrutilla) Componente Unidades Unidad de requeridas medida SE ColRojoRx GR MP EsenciaFrutillaP GR SE RellenoMermelada GR Tabla II.16. BOM de un nivel del producto SE808946(RellenoPomelo) Componente Unidades Unidad de requeridas medida MP EsenciaPomeloP GR SE ColAmarilloYz GR SE RellenoMermelada GR Tabla II.17. BOM de un nivel del producto SE (RellenoLima) Componente Unidades Unidad de requeridas medida MP EsenciaLimaP GR SE ColAnaranjadoOm GR SE RellenoMermelada GR 57

88 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. Tenio 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. Prosiguio 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 sio analizados. Tabla II.18. BOM de un nivel del producto SE (MasaPera) Componente Unidades Unidad de requeridas medida SE AlmíbarT GR MP EsenciaPeraP GR MP ÁcidoZ GR Tabla II.19. BOM de un nivel del producto SE (MasaCereza) Unidades Unidad de Componente requeridas medida SE AlmíbarT GR 58

89 Dominio de trabajo. Caracterización y definición de su Alcance SE ColRojoRx GR MP EsenciaCerezaP GR MP ÁcidoZ GR Tabla II.20. BOM de un nivel del producto SE (MasaFrutilla) Componente Unidades Unidad de requeridas medida SE AlmíbarT GR SE ColRojoRx GR MP EsenciaFrutillaP GR MP ÁcidoZ GR Tabla II.21. BOM de un nivel del producto SE (MasaPomelo) Componente Unidades Unidad de requeridas medida MP EsenciaPomeloP GR SE AlmíbarT GR SE ColAmarilloYz3 2.4 GR MP ÁcidoZ GR Tabla II.22. BOM de un nivel del producto SE (MasaLima) Componente Unidades Unidad de requeridas medida SE AlmíbarT GR MP EsenciaLimaP GR SE ColAnaranjadoOm4 2.4 GR MP ÁcidoZ GR 59

90 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 depen 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 prete 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) SE (MasaFrutilla) SE (MasaFrutillaMIX) SE313862(MasaFrutillaOK) 60

91 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 SE (MasaFrutillaMIX) Componente Unidades Unidad de requeridas medida SE AlmíbarT GR SE ColRojoRx GR MP EsenciaFrutillaP GR MP ÁcidoZ GR Tabla II.24. BOM de un nivel del producto SE (MasaFrutillaOK) Componente Unidades Unidad de requeridas medida SE AlmíbarT GR SE ColRojoRx GR MP EsenciaFrutillaP GR MP ÁcidoZ GR Tabla II.25. BOM de un nivel del producto SE (MasaFrutillaEFE) Componente Unidades Unidad de requeridas medida SE AlmíbarT GR SE ColRojoRx GR MP EsenciaFrutillaB GR MP ÁcidoZ 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

92 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 en las tablas II.26 a II.28, a saber: i) SE609109(MasaCerezaEFE.); ii) SE (MasaCerezaOK); y iii) SE608394(MasaCerezaA). Hasta aquí se han analizado siempre caramelos del tipo frutal; pero este análisis podría exterse 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 SE (MasaCerezaOK) Componente Unidades requeridas Unidad de medida SE AlmíbarT GR SE ColRojoRx GR MP EsenciaCerezaP GR MP ÁcidoZ GR Tabla II.27. BOM de un nivel del producto SE (MasaCerezaA) Componente Unidades Unidad de requeridas medida SE ColRojoRt GR MP EsenciaCerezaB GR SE Almíbar F1DE GR 62

93 Dominio de trabajo. Caracterización y definición de su Alcance MP ÁcidoZ GR Tabla II.28. BOM de un nivel del producto SE (MasaCerezaEFE) Componente Unidades Unidad de requeridas medida SE AlmíbarT GR SE ColRojoRx GR MP EsenciaCerezaP GR MP ÁcidoZ 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 0 O C y envasados al vacío para ser vidos en mercados locales o internacionales. Cortes cárnicos congelados: Cortes individuales seleccionados de bovinos, congelados a -18 O C. Menudencias: menudencias seleccionadas, congeladas y empaquetadas individualmente. 63

94 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 depio del mercado en el cual es vido. 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 Peso medio Envase/ Preservación Presentación Lomo 1.5 KG Al vacío / Enfriado 20 KG/Caja Bife Ancho 2 KG Al vacío / Enfriado 20 KG/Caja Peceto 1.4 KG IWP 20 KG/caja Cuadril con Tapa 3.5 KG Al vacío/ Enfriado 20 KG/caja. Tabla II.30. Algunos cortes frescos ofrecidos. Marca B. Mercado Alemania Cortes Peso medio Envase / Preservación Presentación Lomo 1.2 KG Al vacío / Enfriado 15 KG/Caja Bife Angosto 1.7 KG Al vacío / Enfriado 15 KG/Caja Nalga Adentro 1.4 KG IWP 15 KG/caja Cuadril con Tapa 3.5 KG Al vacío /Enfriado 15 KG/caja Garrón Congelado 15 KG/caja Bife Angosto con 4 KG Al vacío /Enfriado 15 KG/caja Cuadril y Lomo 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 prete 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

95 Dominio de trabajo. Caracterización y definición de su Alcance Tabla II.31. Ejemplos de diferentes carnes cocidas congeladas Producto Mercados Tipos CCCCub1 CCCCub2 CCCCub3 CCCCub4 CCCCub5 CCCCub6 CCCCub7 CCCCub1 CCCReb1 CCCReb2 CCCReb3 CCCReb4 FPB1 FPB2 FPB3 FPDCva FPD2 FPD1 Alemania USA USA Italia Italia Alemania Suiza Alemania Europa USA Italia Alemania Europa Local USA Local USA Europa 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, 2- moderado, 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

96 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 JJ J U U2 N T A Novillito AA A B C D E F Vaquillona AA A B C D E F Vaca AA A B C D E F Ternero AA A B C D E F Toro AA A B B C C C Exportación Consumo Local Manufactura o Conserva Tabla II.34. Diferentes calidades de ganado bovino Categorías Tipo Grados de grasa Escala de pesos (KG/media res) Novillo JJ-J-U-N más de 188 T 0-1 sin exigencias A Ninguno sin exigencias Novillito AA-A-B hasta 117 D hasta 108 E 0-1 hasta 95 F ninguno hasta 95 Vaquillona AA-A-B hasta 113 D hasta 103 E 0-1 hasta 85 F ninguno hasta 85 Vaca AA-A-B-C-D más de 113 E sin exigencias F ninguno sin exigencias Ternero AA-A-B-C hasta 73 D hasta 68 E 0-1 hasta 55 F ninguno hasta 55 Mamón A 0-1 hasta 50 B 0-1 hasta 40 C 0-1 hasta 30 Toro AA-A-B-C 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. Depio de la operación de despostada (desarmado) que se 66

97 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 rimientos para diferentes tipos de animales (NovilloJJ, NovilloJ). Es decir, esta tabla muestra que la descomposición del CuartoTCorte1 da lugar a diferentes rimientos para algunos de los productos obtenidos (por ejemplo, BifeAngosto) depio del tipo de animal sobre el cual se aplique la operación de descomposición. En la tabla se muestran los rimientos 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 e diferentes tamaños de 67

98 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 KG y la de un animal tipo NovilloJ pesa KG. Es decir, que si un animal dado pesa 312 KG, es posible calcular cuál es el rimiento 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 NovilloJJ NovilloJ BifeAngosto BolaLomo ColitaCuadril CuadrilCT CZACuadrada Garrón Lomo NalgaDeAdentroCT Peceto Tortuguita MP1CarneCocida MPGrasa HuesoSinCarne NerviosYPellejos Total 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

99 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 vidos como tales sin sufrir ninguna operación de procesamiento adicional y. En realidad, se los ve en cajas o contenedores que compren un determinado número de unidades de estos cortes cárnicos. Tabla II.36. Descomposición OP2CuartoTCorte1 aplicada sobre el producto CuartoTCorte1 NovilloJJ NovilloJ BifeAngosto BolaLomo ColitaCuadril TapaCuadril CuadrilST CZACuadrada Garron Lomo NalgaDeAdentroCT Peceto Tortuguita MP1CarneCocida MPGrasa HuesoSinCarne NerviosYPellejos Total Sin embargo, depio 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 rimientos 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 NovilloJJ NovilloJ TapaCuadril CuadrilST Total

100 Dominio de trabajo. Caracterización y definición de su Alcance Tabla II.38. Descomposición OP2CuadrilCT aplicada sobre el producto CuadrilCT NovilloJJ NovilloJ CuadrilCTExp MPGrasa NerviosYPellejos Total Tabla II.39. Descomposición OP3CuadrilCT aplicada sobre el producto CuadrilCT NovilloJJ NovilloJ CuadrilCorteUK MP2CarneCocida MP1CarneCocida MPGrasa NerviosYPellejos Total 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 NovilloJJ NovilloJ TapaCuadrilExp MPGrasa Total 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, partio de distintos tipos de cuartos traseros (por ej., CuartoTCorte1 y CuartoTCorte2) y 70

101 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 NovilloJJ NovilloJ TapaCuadrilEEUU MP1CarneCocida MPGrasa NerviosYPellejos Total Tabla II.42. Descomposición OP3TapaCuadril aplicada sobre el producto TapaCuadril NovilloJJ NovilloJ MP2CarneCocida MP1CarneCocida MPGrasa Total 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 comprerse 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 NovilloJJ NovilloJ CentroNalgaSuiza MP1CarneCocida MPGrasa NerviosYPellejos Total

102 Dominio de trabajo. Caracterización y definición de su Alcance Tabla II.44. Descomposición OP1NalgaDeAdentroCT aplicada sobre el producto NalgaDeAdentroCT NovilloJJ NovilloJ CentroNalgaSuiza MP2CarneCocida MP1CarneCocida MPGrasa NerviosYPellejos MP3CarneCocida Total Tabla II.45. Descomposición OP2NalgaDeAdentroCT aplicada sobre el producto NalgaDeAdentroCT NovilloJJ NovilloJ NalgaDeAdentroST TapaNalga Total 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 Unidades Unidad de requeridas medida CCCtipo KG TuboTipo1cs UNID Caja ZX3 Azul 53 UNID Cierre CCC prw 53 UNID * Adhesivo ARP 0.26 KG * BolsasT1 2 UNID * RótuloMK6 20 UNID * 72

103 Dominio de trabajo. Caracterización y definición de su Alcance ClipsF UNID * Broches YV7 400 UNID * ObleasQW UNID * EtiquetaCB 53 UNID * Tabla II.47. BOM de un nivel para el producto final CCCCub2 Componente Unidades Unidad de requeridas medida CCCtipo KG TuboTipo2ss 180 UNID Caja XC71 Amarilla 40.0 UNID Cierre CCC prw 40.0 UNID * Adhesivo ARP 0.26 KG * BolsasT1 2 UNID * RótuloMK6 21 UNID * ClipsF UNID * Broches YV7 400 UNID * ObleasQW UNID * EtiquetaCB 40 UNID * Tabla II.48. BOM de un nivel para el producto final CCCCub3 Componente Unidades Unidad de requeridas medida CCCtipo KG TuboTipo3ss 180 UNID Caja XC71 Amarilla 40.0 UNID Cierre CCC prw 40.0 UNID * Adhesivo ARP 0.26 KG * BolsasT1 2 UNID * RótuloMK6 21 UNID * ClipsF UNID * Broches YV7 400 UNID * ObleasQW UNID * EtiquetaCB 40 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

104 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 Unidades Unidad de requeridas medida MP3CarneCocida KG MP1CarneCocida KG Gelatina Comestible 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 Unidades Unidad de requeridas medida MP3CarneCocida KG Gelatina Comestible KG Sal Entrefina 15 KG Tabla II.51. BOM de un nivel del producto CCCtipo3 Componente Unidades Unidad de requeridas medida MP3CarneCocida KG Gelatina Comestible 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

105 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

106 Tabla II.52. Composición de algunos de los productos finales del negocio de carnes cocidas CCCCub1 CCCCub2 CCCCub3 CCCCub4 CCCCub5 CCCReb1 CCCReb2 CCCReb3 CCCReb4 CCCCub6 CCCCub7 FPB1 FPB2 FPB3 CZACuadUK CZACuadCEE FPBCva FPD2 FPD1 MP3CarneCocida MP2CarneCocida CZACuadrada MP1CarneCocida Gelatina Sal TuboTipo2cs TuboTipo1ss TuboTipo1cs 180 TuboTipo3cs TuboTipo4ss TuboTipo4cs TuboTipo2ss 180 TuboTipo3ss 275 TuboTipo5ss 212 Caja ZX3 Azul Caja 115 Grande Blanca Cierre CC prw Adhesivo ARP BolsasT RotuloMK ClipsF BrochesYV ObleasQW EtiquetasCB

107 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, indepientemente 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

108 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

109 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 tenio 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

110 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

111 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, permitio 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, ponio é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, pudio 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 compren 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

112 Modelo de productos. Definición <<AP>> AbstracciondeProducto <<F>> Familia <<CV>> ConjuntodeVariantes <<P>> 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 Individual Familia in Class isa AbstracciondeProducto Individual ConjuntodeVariantes in Class isa AbstracciondeProducto with attribute miembrode:familia Individual Producto in Class isa AbstracciondeProducto with attribute miembrode:conjuntodevariantes 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

113 Modelo de productos. Definición attribute rule miembros: ConjuntodeVariantes miembrosrule:$forall f/familia cv/conjuntodevariantes (cv miembrode f) ==> (f miembros cv)$ 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 deper del tipo de industria en el que se preta 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

114 Modelo de productos. Definición <<F>> Familia CarameloFrutalEnv CarneCocidaCongelada 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

115 Modelo de productos. Definición BolsínFrutilla5GREnv CuartoTrasero PapelSepBolsín EnvBolsínFrutillaKIM CuadrilConTapa Lomo SH BolsínFrutillaDes CuadrilSinTapa TapaCuadril MasaFrutilla 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 definio la SH para cada uno de los niveles de la AH y proveyo 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 ascie en la AH, los árboles de estructuras se van hacio 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

116 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

117 Modelo de productos. Definición EnvBolsínFrutillaKIM BolsínFrutalROC BolsínFrutilla5GREnv EnvBolsínPeraKIM PapelSepBolsín EnvBolsínCerezaKIM EnvBolsínKIM SepROC InteriorBolsín EnvBolsínLimaKIM EnvBolsínPomeloKIM BolsínFrutillaDes BolsínAnanaDes OvaloFrutal BolsínLimonDes BolsínNaranjaDes BolsínCerezaDes MasaFrutilla RellenoFrutilla MasaPera MasaCereza MasaConAcido Color RellenoFrutal RellenoPera RellenoCereza MasaLima RellenoLima RellenoPomelo Entidad de Nivel ConjuntodeVariantes Entidad de Nivel Producto Entidad de Nivel Producto correspondiente a la estructura de la Figura III.3 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

118 EnvBolsínFrutillaKIM CarameloFrutalEnv BolsínFrutalROC BolsínFrutilla5GREnv EnvBolsínPeraKIM EnvBolsínCerezaKIM EnvBolsínKIM PapelSepBolsín EnvBolsínLimaKIM EnvBolsínPomeloKIM SepKIM PapelEnvoltorio PapelSeparador EnvBolsínK SepROC InteriorBolsín SepBolsínRoc EnvBolsínFrutillaROC SepRocDeluxe EnvBolsínPeraROC EnvBolsínCerezaROC EnvBolsínLimaROC EnvBolsínROC FrutalS CarameloFrutalDes OvaloFrutal BolsínFrutillaDes BolsínPeraDes BolsínPomeloDes EnvBolsínPomeloROC FrutalK BolsínLimaDes MasaFrutilla VaritaFrutal BolsínCerezaDes MasaPomelo MasaCereza MasaLima MasaConÁcido Color MasaConÁcido RellenoFrutal RellenoFrutal RellenoFrutilla RellenoPera RellenoCereza MasaPera MasaConÁcido SinColor RellenoLima RellenoPomelo Entidad del Nivel Familia Entidad del Nivel Producto Relación miembrode Entidad del Nivel ConjuntodeVariantes Entidad del Nivel ConjuntodeVariantes correspondiente a la estructura de la Figura III.4 Entidad del Nivel Producto correspondiente a la estructura de la Figura III.3 Figura III.5. SH correspondiente a CarameloFrutalEnv, instancia del nivel Familia

119 <<AP>> AbstraccionDeProducto AbstraccióndeProducto componente derivado <<F>> Familia <<RF>> RestricciónF <<FS>> FamiliaS <<FC>> FamiliaC estructurade <<E>> Estructura <<ED>> EstructuraD <<EC>> EstructuraC <<RD>> RelaciónD <<RC>> RelaciónC miembrode <<CV>> ConjuntodeVariantes <<RCV>> RestricciónCV estructuraalternativa <<TR>> <<Op>> Optativa <<SVS>> ConjuntodeVariantesS <<TR>> TipoRelación <<TR>> <<Ob>> Obligatoria <<Presel>> Preseleccion preselecciona Preselección Conjunto Seleccionado tiporelación derivade <<TR>> <<S>> Selectiva <<CVC>> ConjuntodeVariantesC <<Elim>> Eliminación modificaciónaplicada <<M>> Modificacion Modificación <<R>> Relación quantityper prodfactor cambioaplicado <<C>> Cambio relaciónmodificada <<SelFam>> <<Sele>> SelecciónFamilia max <<VR>> ValorRestringido min <<CC>> CambioC valor <<UV>> <<VU>> ValorUnidad udem nuevopf <<Num>> Número Numero nuevoqp <<CPF>> <<Cpf>> CambioPF <<Cqp>> <<CQP>> CambioQP <<U>> Unidad miembrode e <<P>> Producto <<PS>> ProductoS <<PC>> ProductoC selecciona <<RP>> RestricciónP << 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 compre. 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

120 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. Tenio 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 Familia componente FamiliaS FamiliaC estructurade estructuraalternativa Estructura RelaciónD EstructuraD EstructuraC RelaciónC 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 Individual FamiliaS in Class isa Familia Individual FamiliaC in Class isa Familia 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

121 Modelo de productos. Definición FamiliaC with attribute estructurade: Estructura constraint RIII_1:$forall f/familiac (exists e/estructura (f estructurade e))$ 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) $ 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 preta 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

122 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 Individual EstructuraD in Class isa Estructura with Attribute requiere: ValorRestringido derivado: RelacionD Individual Relacion in Class Individual RelacionC in Class isa Relacion Individual RelacionD in Class isa Relacion 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 rimiento 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

123 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 ValorRestringido max min TipoRelación RelaciónC RelaciónD valor ValorUnidad Número Optativa Obligatoria Selectiva udem 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

124 Modelo de productos. Definición prodfactor : ValorRestringido; tiporelacion : TipoRelacion Especificación III.7. Definición de la clase Relación Individual TipoRelacion in Class Individual Obligatoria in Class isa TipoRelacion Individual Optativa in Class isa TipoRelacion Individual Selectiva in Class isa TipoRelacion with attribute rule conjuntoseleccion: Relacion conjseleccionrule: $ forall r/relacion s/selectiva (r tiporelacion s) and (s == this) ==> (s conjuntoseleccion r) $ Especificación III.8. Definición de la clase TipoRelación y de sus especializaciones 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 De aquí se despre 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 (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

125 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 Individual ValorRestringido in Class isa ValorUnidad with attribute max : Real; min : Real Individual 1U in ValorUnidad with valor valor: 1.0 udem udem: UNID Individual 30_87GR in ValorRestringido with valor valor: udem udem: GR max max: 50.0 min min: 10.0 Especificación III.9. Representación de valores y unidades de medida Forma Extida Forma Simplificada <<Número>> 10.0 <<Número>> 50.0 min max <<ValorRestringido>> 30_87GR valor udem <<Número>> <<Unidad>> GR <<ValorRestringido>> 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

126 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 Unidad in Class Individual UnidadPeso in Class isa Unidad Individual UnidadLongitud in Class isa Unidad Individual UnidadSuperficie in Class isa Unidad Individual UnidadVolumen in Class isa Unidad Individual UNID in Unidad Individual GR in UnidadPeso Individual KG in UnidadPeso Individual LB in UnidadPeso Individual M in UnidadLongitud Individual M2 in UnidadSuperficie Individual CM3 in UnidadVolumen Individual LT in UnidadVolumen 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 attribute,inherited_attribute tiporelacion : TipoRelacion attribute,computed_attribute 96

127 Modelo de productos. Definición cantidad : ValorUnidad attribute,constraint r:$(this quantityper ~cantidad) or (this prodfactor ~cantidad) $ 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 Individual EstructuraC with rule confrule:$ forall r/relacionc (this componente r) ==> (this conformadopor r) $ Individual EstructuraD with rule confrule:$ 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 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

128 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)$ 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)$ 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

129 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

130 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)$; QueryClass FamiliaDerivada isa Familia with retrieved_attribute esderivado : Boolean constraint c : $ (this esderivado TRUE) $ QueryClass FamiliaEnsamblada isa Familia with retrieved_attribute esensamblado : Boolean constraint c : $ (this esensamblado TRUE) $ 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 100

131 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) $ 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)$ Especificación III.19. Reglas para la inferencia de atributos en una RelaciónD 101

132 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 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)) $ 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

133 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, depio 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 constraint computed_attribute,partof unreq: RequerimientosInferidos constraint rint:$(~unreq requerimiento this) and (this::requerimientos in ~unreq.pertenecea)$ r:$ (this estructurarequerida ~requerimientos) $ 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)$ 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

134 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 SE (MasaPera) y SE (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. FamiliaC estructurade miembrode Familia ConjuntoSeleccionado Estructura ConjuntodeVariantes Preselección preselecciona ConjuntodeVariantesS ConjuntodeVariantesC derivade modificaciónaplicada Modificación cambioaplicado 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

135 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, sas 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) $ 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) $ Individual ConjuntodeVariantesC in Class isa ConjuntodeVariantes with constraint RIII_6 : $ forall cv/conjuntodevariantesc f/familia (cv miembrode f) and (f isa FamiliaC) $ 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

136 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) $ 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 Individual Modificacion in Class Individual Preseleccion in Class Especificación III.27. Definición de ConjuntodeVariantesC Depio 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

137 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 depe. 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 rule cambioaplicado: Cambio modifica: Estructura modificarule: $ forall e/estructura m/modificacion (exists cv/conjuntodevariantesc (cv derivade e) and (cv modificacionaplicada m) )==> (m modifica e) $ 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, depio 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

138 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))$ Individual Eliminacion in Class isa Cambio Individual SeleccionFamilia in Class isa Cambio Individual CambioC in Class isa Cambio 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

139 Modelo de productos. Definición productos que son miembros del conjunto de variantes que se está definio. Estos nuevos valores deberán estar compridos entre los límites máximo y mínimo establecidos para la relación que está sio 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 )$ 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)$ 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)$ 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

140 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))$ 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

141 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))$ 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, relacionesseleccionadas, y 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)$ inherited_attribute, partof relacionesintactas: Relacion with inherited_attribute parte:familia; quantityper:valorrestringido inherited_attribute, partof relacionesseleccionadas: Relacion with inherited_attribute parte:familia; quantityper:valorrestringido Especificación III.34. Vista estructuracv 111

142 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) $ 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 ))$ 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

143 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)$ 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) depio 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 selecciona <<sele>> Selección <<PS>> ProductoS <<PC>> ProductoC 113

144 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)) $ Especificación III.38. Definición de la clase ProductoS. Individual ProductoC in Class isa Producto with attribute constraint selecciona: Seleccion RIII_18: $forall p/productoc (exists cv/conjuntodevariantesc (p miembrode cv))$; RIII_19: $forall p/productoc exists s/seleccion (p Selecciona s) $ 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) $ 114

145 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 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)$ 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

146 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). Tenio 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 <<O>> Obligatoria <<Rest>> Restricción tiporestricción <<Trest>> TipoRestricción <<RF>> RestricciónF <<RCV>> RestricciónCV <<RP>> RestricciónP <<F>> Familia <<CV>> ConjuntodeVariantes <<P>> Producto Figura III.14. Diagrama de clases asociadas a la administración de restricciones Figura III.14. La Especificación III.42 define, en lenguaje O-Telos, las clases presentadas en la Individual Restriccion in Class with attribute tiporestriccion: TipoRestriccion Individual RestriccionF in Class isa Restriccion with attribute restringe: Familia Individual RestriccionCV in Class isa Restriccion with attribute restringe: ConjuntodeVariantes 116

147 Modelo de productos. Definición Individual RestriccionP in Class isa Restriccion with attribute restringe: Producto 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 Individual RObligatoria in Class isa TipoRestriccion Individual RIncompatible in Class isa TipoRestriccion Individual robligatoria in RObligatoria Individual rincompatible in RIncompatible Especificación III.43. Definición de la clase TipoRestricción y sus especializaciones 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á establecio 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

148 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 si es componentedirecto de cv2 o si existe otro ConjuntodeVariantes cv3 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)$; 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

149 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) $ 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) )$ 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))$ 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)) $ 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

150 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) )$ 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)) $ Especificación III.50. Restricción de incompatibilidad entre ConjuntosdeVariantes 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)))$ 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

151 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)$ Especificación III.52. Definición de los atributos incompatiblecon y obligatoriocon en la clase Familia 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 entie 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, tenio 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

152 Modelo de productos. Definición Definición Familia Definición Conjunto de Variantes Definición Producto Sistema de especificación de productos 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, tenio 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 depio 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

153 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): depio del tipo de Familia que se esté definio, 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) new :RestriccionF tiporestriccion= SetTipo(tipo) restringe= SetRestringe(flia) SetEstructura [es composición?]: estructurade= New :EstructuraC [esdescomposición?]: estructurade= New :EstructuraD Figura III.16. Diagrama de Interacción correspondiente a la creación de una instancia de la clase FamiliaC 123

154 Modelo de productos. Definición :FamiliaC :EstructuraC new Verifica si no hay restricciones de incompatibilidad entre la familia que se está definio y el componente que se está incorporando a la estructura loop Para cada componente AgregarComponente VerificarRestricciones opt RestriccionesOK componente= new :RelacionC parte= setparte(unaflia) :ValorRestringido quantityper= new(unvalor, udem,unmin, unmax) prodfactor= new(unvalor,ude,unmin,unmax) :ValorRestringido 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á definio, 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

155 Modelo de productos. Definición :DiseñadorProducto CV1 :ConjuntoDeVariantesC :Preseleccion New setpropiedades setrestriccion restringea= new :RestriccionCV derivade= setestructura [si modifica Estructura]: setmodificaciones modificacionaplicada= new(derivade) Modificacion [si preselecciona Conj.de Variantes]: preseleccionar [si es nueva preseleccion]: preselecciona= New Preseleccion [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á sio 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, depio 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

156 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) :Eliminacion opt :SeleccionFamilia cambioaplicado= New(unaRelacion) opt nuevovalor= getnuevacantidad qp= getquantityper limitesok= checklimites(nuevovalor) [limitesok==true]: cambioaplicado= New(unaRelacion.nuevoValor) :CambioQP opt nuevovalor= getnuevacantidad pf= getprodfactor limitesok= checklimintes(nuevovalor) [limitesok==true]: cambioaplicado= New(unaRelacion, nuevovalor) :CambioPF 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

157 Modelo de productos. Definición obligatoriedad como de incompatibilidad, entre la instancia de Producto que está sio 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 restringea= New :RestriccionP 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. Tenio en cuenta dicho conjuntoseleccionado, se deberá verificar si no hay productos que violen las restricciones previamente establecidas para el producto que está sio 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

158 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, permitio 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

159 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 compren 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. Tenio 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

160 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 tenio 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

161 131

162 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 sas 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

163 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 (indepientemente 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 SE (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 contenio 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

164 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

165 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 SE PeraKIM5GREnv SE PomeloKIM5GREnv SE LimaKIM5GREnv SE FrutillaKIM5GREnv SE CerezaKIM5GREnv BolsínFrutalROC ROC Bolsín SE BolsínFrutilla5GREnv SE BolsínPera5GREnv SE BolsínPomelo5GREnv SE BolsínLima5GREnv FrutalZOro ROC BolsínZ FrutalOKOro ROC BolsínOK VaritaKIM KIM Varita SE BolsínCereza5GREnv SE BolsínFrutillaPopEnv SE BolsínFrutillaOroZEnv SE BolsínFrutillaClasicEnv SE BolsínOKFrutillaOroEnv SE VaritaKIMPeraEnv SE VaritaKIMFrutillaEnv SE VaritaKIMDuraznoEnv SE VaritaKIMPomeloEnv SE VaritaKIMLimaEnv VaritaROC ROC Varita SE VaritaROCDuraznoEnv SE VaritaROCLimaEnv SE VaritaROCPomeloEnv SE VaritaROCFrutillaEnv SE VaritaROCPeraEnv BolsínFrutalZ ROC BolsínZ SE BolsínFrutillaZEnv SE BolsínPeraZEnv SE BolsínPomeloZ4GrEnv SE BolsínLimaZ4GrEnv SE BolsínCereza4GrEnv BolsínFrutalOK ROC BolsínOK SE BolsínOKCereza5GrEnv SE BolsínOKLima5GrEnv SE BolsínOKPomelo5GrEnv SE BolsínOKPera5GrEnv 132

166 Modelo de Productos. Aplicaciones SE BolsínOKFrutilla5GrEnv FrutalOro ROC Bolsín SE BolsínOroPeraROCEnv SE BolsínOroPomeloROCEnv SE BolsínOroLimaROCEnv SE BolsínOroCerezaROCEnv SE 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

167 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, ME y ME910124, respectivamente. 134

168 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 Habio presentado las jerarquías de abstracción que intervrá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 Individual CarameloFrutlEnvSTR in EstructuraC with attribute,conformadopor conformadopor1 : R03; conformadopor2 : R04; conformadopor3 : R05 Especificación IV.1. Definición de la familia denominada CarameloFrutalEnv y de su correspondiente estructura 135

169 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 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 GR y este valor sólo podrá variar (en caso de que se apliquen cambios a la relación) entre los y gramos. Individual RelacionesenSTR in View isa Relacion with attribute,inherited_attribute parte : Familia; 136

170 Modelo de Productos. Aplicaciones tiporelacion : TipoRelacion retrieved_attribute,partof quantityper:valorrestringido with inherited_attribute valor:real; udem:unidad; min:real; max:real constraint r:$ (CarameloFrutlEnvSTR conformadopor this) $ Especificación IV.2. Definición de la Vista denominada RelacionesenSTR R03 in RelacionesenSTR with quantityper quantityper:30_87gr with parte valor udem min max valor : udem : GR min : 10.0 max : 50.0 parte:papelenvoltorio tiporelacion tiporelacion:obligatoria R04 in RelacionesenSTR with quantityper quantityper:930_233gr with parte valor udem min max valor : udem : GR min : max : parte:caramelofrutaldes tiporelacion iporelacion:obligatoria R05 in RelacionesenSTR with quantityper quantityper:33gr with parte valor udem min max valor : 33.0 udem : GR min : 10.0 max : 50.0 parte:papelseparador tiporelacion tiporelacion: optativa 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

171 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

172 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

173 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 ; COMPUTED_unReq_id_2501 : R04 with cantreq COMPUTED_cantReq_id_2518 : 930_233GR requerimiento COMPUTED_requerimiento_id_2468 : CarameloFrutalDes ; COMPUTED_unReq_id_2504 : R05 with cantreq COMPUTED_cantReq_id_2526 : 33GR requerimiento COMPUTED_requerimiento_id_2424 : PapelSeparador 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

174 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 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

175 Modelo de Productos. Aplicaciones composición: GR, 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 Especificación IV.6. Cambios asociados a la modificación modvaritakim Individual Ca2R03 in CambioQP with attribute,relacionmodificada relacionmodificada : R03 attribute,newqp newqp : 42GR Individual 42GR in ValorUnidad with attribute,valor valor : 42.0 attribute,udem udem : GR Individual ElR05 in Eliminacion with attribute,relacionmodificada relacionmodificada : R05 Individual Ca2R04 in CambioQP with attribute,relacionmodificada relacionmodificada : R04 attribute,newqp newqp : 958GR Individual 958GR in ValorUnidad with attribute,valor valor : attribute,udem udem : GR 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

176 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 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

177 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

178 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 Individual PreselVaritaKIM in Preseleccion with ConjuntoSeleccionado ConjuntoSeleccionado: EnvVaritaKIM 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

179 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 Individual PapelSepRoc in Preseleccion with ConjuntoSeleccionado ConjuntoSeleccionado: PapelSepROC1 Individual CarFrutal in Preseleccion with ConjuntoSeleccionado ConjuntoSeleccionado: OvaloFrutal 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

180 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

181 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] ; 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] ; 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] 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

182 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] ; 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] 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. SE (VaritaKIMPeraEnv), SE (VaritaKIMDamascoEnv), SE (VaritaKIMFrutillaEnv), SE (VaritaKIMPomeloEnv) y SE (VaritaKIMLimaEnv), que son miembros del conjunto de variantes denominado VaritaKIM SE (PeraKIM5GREnv), SE (CerezaKIM5GREnv), SE (FrutillaKIM5GREnv), SE (PomeloKIM5GREnv) y SE (LimaKIM5GREnv), que son miembros del conjunto de 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: ME (EnvVaritaKIMPomelo), ME (EnvVaritaKIMLima), ME (EnvVaritaKIMFrutilla), ME (EnvVaritaKIMDamasco) y ME (EnvVaritaKIMPera), que son miembros del conjunto de variantes EnvVaritaKIM ME (EnvBolsínROCLima), ME (EnvBolsínROCPomelo), ME (EnvBolsínROCFrutilla), ME (EnvBolsínROCCereza) y ME (EnvBolsínROCPera), que son miembros del conjunto de variantes EnvBolsínFrutalKIM. 149

183 Modelo de Productos. Aplicaciones De todos los productos mencionados, se tomará SE (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 SE (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 SE in ProductoC with descripcion descripcion: "Varita KIM Frutilla*Env" miembrode miembrode: VaritaKIM seleccionar selecciona1: selcarvarita; selecciona2: selenvvaritakim Individual selcarvarita in Seleccion with productoelegido productoelegido:se Individual selenvvaritakim in Seleccion with productoelegido productoelegido:me Especificación IV.13. Definición de la instancia de ProductoC denominada SE (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 SE (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 SE (VaritaKIMFrutillaEnv), indicadas allí por las relaciones etiquetadas 150

184 Modelo de Productos. Aplicaciones con el rótulo selecciona. En particular se eligen, los productos SE (VaritaFrutillaDes) y ME (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

185 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 Individual robligatoria in RObligatoria PapelSeparador in FamiliaS with restringea restringea: PS_PE Individual PS_PE in RestriccionF with tiporestriccion tiporestriccion : obligatoria restringe restringea :PapelEnvoltorio Especificación IV.14. Restricción de obligatoriedad correspondiente a PapelSeparador Figura IV.16. Definición de una restricción de incompatibilidad aplicable a OvaloFrutal Individual OvaloFrutal with restringea restringea: OF_EVK Individual OF_EVK in RestriccionCV with tiporestriccion tiporestriccion : rincompatible restringe restringe: EnvVaritaKIM 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 SE (VaritaKIMFrutillaEnv) debe estar acompañado por el papel envoltorio ME (EnvVaritaKIMFrutilla). La correspondiente definición se muestra en la Especificación IV

186 Individual SE in ProductoC with restringea restringea: CFD_PEF Individual CFD_PEF in RestriccionP with tiporestriccion tiporestriccion: obligatoria restringe restringe: ME Especificación IV.16. Restricción de obligatoriedad correspondiente a SE 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 SE (VaritaKIMFrutillaEnv) Figura IV.18. Ejemplo de la consulta VerIncompatibles 153

187 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 compren. 154

188 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 SECarneCocidaCongelada SECarneCocidaSaz SECarneCocidaCubMix SE_CCCCub3 SE_CCCCub5 SE_CCCCub6 SE_CCCCub7 SE_CCCReb1 SECarneCocidaReb SE_CCCReb2 SE_CCCReb3 SE_CCCReb4 SE_FPB1 SECCPicada1 SE_FPB2 SECarneCocidaPicada SECCPicada2 SE_FPB3 SE_FPBCva 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 Especificación IV.17. Definición de la familia SECarneCocidaCongelada 155

189 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 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 Individual R13f in RelacionC with parte parte: Sal quantityper quantityper: 15KG tiporelacion tiporelacion: optativa Individual R14fa in RelacionC with parte parte: MP3CarneCocida quantityper quantityper: 1754KG tiporelacion tiporelacion: selectiva Individual R14fb in RelacionC with parte parte: MP2CarneCocida quantityper quantityper: 1754KG 156

190 Modelo de Productos. Aplicaciones tiporelacion tiporelacion: selectiva 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, sio é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 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 Individual R146f in RelacionC with parte parte: MP1CarneCocida quantityper quantityper: 515KG tiporelacion tiporelacion: obligatoria Individual R145f in RelacionC with Individual R147f in RelacionC with parte parte: MP3CarneCocida parte parte: Gelatina quantityper quantityper: 1202_7KG quantityper quantityper: 12KG tiporelacion tiporelacion: obligatoria tiporelacion tiporelacion: obligatoria 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

191 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

192 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 : 1UNID requerimiento cantreq COMPUTED_requerimiento_id_3077 : NalgaAdentroCT tiporelacion tiporelacion : obligatoria COMPUTED_requerimientos_id_3465 : TapaCuadrilSTR2[MP2CarneCocida/this_par] with unreq COMPUTED_unReq_id_3522 : R51f with ; cantreq : 1UNID requerimiento cantreq COMPUTED_requerimiento_id_3025 : TapaCuadril tiporelacion tiporelacion : obligatoria COMPUTED_requerimientos_id_3645 : CuadrilConTapaSTR3[MP2CarneCocida/this_par] with unreq COMPUTED_unReq_id_3652 : R07f with cantreq : 1UNID requerimiento cantreq COMPUTED_requerimiento_id_3075 : CuadrilConTapa tiporelacion tiporelacion : obligatoria Especificación IV.21. Resultados parciales de la vista RequerimientosFamilia correspondientes a MP2CarneCocida 159

193 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 Individual CuadrilConTapaSTR2 in EstructuraD Individual CuadrilConTapaSTR3 in EstructuraD Individual CuadrilConTapa in FamiliaC with attribute,estructurade estructurade : CuadrilConTapaSTR1; estructurade2 : CuadrilConTapaSTR2; estructurade3 : CuadrilConTapaSTR3 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

194 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 R06f in RelacionD Individual R07f in RelacionD Individual R08f in RelacionD Individual R09f in RelacionD Individual R10f in RelacionD Individual 1UNID in ValorRestringido CuadrilConTapaSTR3 in EstructuraD with conformadopor conformadopor1: R06f; conformadopor2: R07f; conformadopor3: R08f; conformadopor4: R09f; conformadopor5: R10f requiere requiere : 1UNID 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

195 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 parte COMPUTED_cantidad_id_3669:3_13% parte : CuadrilCTExportacion tiporelacion ; tiporelacion : obligatoria COMPUTED_conformadoPor_id_3652:R07f with cantidad parte COMPUTED_cantidad_id_3681:0_13% parte : MP2CarneCocida tiporelacion ; tiporelacion : obligatoria COMPUTED_conformadoPor_id_3655:R08f with cantidad COMPUTED_cantidad_id_3693:0_16% parte : MP1CarneCocida tiporelacion ; tiporelacion : obligatoria COMPUTED_conformadoPor_id_3658:R09f with cantidad parte COMPUTED_cantidad_id_3705:0_62% parte : Grasa tiporelacion tiporelacion : obligatoria ; COMPUTED_conformadoPor_id_3661:R10f with cantidad parte COMPUTED_cantidad_id_3717:0_06% parte : NerviosYPellejos tiporelacion tiporelacion : obligatoria parte 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

196 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 asociados, CuadrilConTapaSTR1, CuadrilConTapaSTR2 y CuadrilConTapaSTR3. Esto se debe a que CuadrilConTapa se obtiene de 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

197 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 Individual m1ccc_reb in Modificacion with attribute,cambioaplicado cambioaplicado1 : SeR14fam1; cambioaplicado2 : ElR13fm1; cambioaplicado3 : Ca2R12fm1 Especificación IV.25. Definición del conjunto de variantes SECarneCocidaReb 164

198 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 Individual ElR13fm1 in Eliminacion with attribute,relaciónmodificada relacionmodificada : R13f Individual CaR12fm1 in CambioQP with attribute,relacionmodificada relacionmodificada : R12f attribute,newqp newqp : 15KG 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

199 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

200 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

201 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 exterlo 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

202 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 sio 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

203 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), permitio 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

204 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 Cliente Cliente Cliente EB EB Contenedor WEB servlet página JSP EB Sistemas de información de la empresa (bases de datos, ERP, sistemas tipo legacy ) 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

205 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.jar JBoss COOBOM-ej b.jar COOBOM-DTO.jar COOBOM-db.jar Persistencia Navegador Tomcat COOBOM-web.war BD Versant Presentación Capa Cliente Capa Intermedia Capa Interior Figura V.2. Arquitectura de COOBOM 170

206 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 + conjuntodevariantes + familia + producto + restriccion + unidad + usuario «import» Coobom-db + db + modelo db + conjuntodevariantes + familia + producto + restriccion + unidad + usuario «import» Coobom-util «import» (from Coobom-db) «import» «import» Coobom-web + conjuntodevariantes + familia + login + producto + restriccion + unidad + util «import» + Conexion + DTOFactory «import» modelo + conjuntodevariantes + familia + producto + restriccion «import» + unidad Coobom-DTO + conjuntodevariantes + familia + producto + restricciones + unidad + usuario + usuario (from Coobom-db) 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

207 Prototipo de Sistema de Procesamiento de BOMs familia + FamiliaAction + estructura + restriccion (fromcoobom-web) familia + FamiliaDTO + estructuta + relacion (fromcoobom-dto) familia + FamiliaDB + estructura + relacion (from db) familia:: FamiliaDTO usa familia:: FamiliaDB familia:: FamiliaAction usa manipula util:: BusinessDelegatorFamilia invoca familia:: FamiliaBean familia:: Familia util + BusinessDelegatorConjuntodeVariantes + BusinessDelegatorFamilia + BusinessDelegatorProducto + BusinessDelegatorUsuario (from Coobom-web) familia + FamiliaBean + estructura + restriccion (from Coobom-ejb) familia + Familia + estructura + relacion (from modelo) 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

208 Prototipo de Sistema de Procesamiento de BOMs ActionX ServiceLocatorX XBean XDB DTOFactory DiseñadorProducto 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, exponio 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

209 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 Modelador de Conj untos de Variantes Modelador de Productos Administrador CU-003 Gestionar Familia CU-004 Gestionar Unidad de Medida CU-005 Gestionar Conjunto de Variantes CU-006 Gestionar Producto 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

210 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, definio 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) trá 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á tenio 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

211 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 CU-008 Crear Familia «ext» «include» «ext» «ext» CU-010 Eliminar Familia CU-011 Editar Atributo de Familia «ext» CU-012 Gestionar Estructura «ext» «ext» CU-009 Editar Familia «ext» CU-017 Generar Reporte «ext» «ext» «ext» CU-014 Editar Restricción de Familia CU-019 Copiar Familia «ext» «ext» CU-015 Agregar Restricción de Familia CU-016 Eliminar Restricción de Familia CU-013 Visualizar Estructura de Familia CU-018 Cerrar Familia Figura V.8.Casos de uso que extien 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

212 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

213 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

214 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

215 Prototipo de Sistema de Procesamiento de BOMs iii) iv) la unidad de medida (si no existe, puede crearse accedio al formulario correspondiente desde esta pantalla) y 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

216 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

217 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

218 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

219 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 Conjunto de Variantes «ext» «ext» «ext» CU-027 Crear Conjunto de Variantes CU-028 Editar Conj unto de Variantes CU-029 Eliminar Conjunto de Variantes «ext» «ext» «ext» «ext» «ext» CU-030 Gestionar Estructura Conjunto de Variantes CU-031 Editar Atributo de Conjunto de Variantes CU-032 Cerrar Conjunto de Variantes CU-033 Copiar Conjunto de Variantes CU-034 Editar Restriccion de Conjunto de Variantes «ext» «ext» CU-035 Agregar Restricción de Conjunto de Variantes 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á sio gestionado y, por el otro, la definición de preselecciones para los distintos componentes de 184

220 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 Conjunto de Variantes «ext» «ext» «ext» «ext» CU-038 Excluir Relación CU-039 Modificar valor de Relación CU-040 Reincluir Relación CU-058 Preseleccionar Conjuntos 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 extido 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

221 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

222 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) iii) 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. 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 expandio o contrayo 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. Hacio clic en ella, aparece un tilde cuya presencia indica que ese conjunto de variantes es preseleccionado para el conjunto de variantes que está sio 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

223 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 Siguio 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

224 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. Hacio 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

225 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 SE (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 «ext» «ext» «ext» CU-041 Crear Producto CU-042 Editar Producto CU-043 Eliminar Producto «ext» «ext» «ext» «ext» CU-045 Cerrar Producto CU-046 Copiar Producto CU-047 Editar Atributo de Producto CU-048 Gestionar Estructura Producto «ext» CU-050 Seleccionar Producto Figura V.27. Casos de uso asociados a Gestionar Producto 190

226 Prototipo de Sistema de Procesamiento de BOMs Figura V.28. Creación del producto SE (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á definio es un caramelo de frutilla, se selecciona ME (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 SE (VaritaFrutillaDes) según lo muestra la Figura V

227 Prototipo de Sistema de Procesamiento de BOMs Figura V.29. Gestión del Producto SE Selección PapelEnvoltorio Es importante mencionar que en la estructura que se presenta para el producto SE (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 SE Selección CarameloFrutalDes 192

228 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

229 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

230 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

231 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 enterse. 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. Semántica Web Semántica Ontologías SI Sintáctica HTML XMLS XML SI 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á sio 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

232 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 depio 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) extió 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

233 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 recomació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, OWL- DL 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

234 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

235 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, definio 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 extida, 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, 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 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 extie 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

236 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: prete 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. XML URI RDF Ontología RDF Schema Prueba Framework lógico Rules Seguridad Firma Digital Namespaces Unicode Encriptado Nivel de Seguridad Nivel Lógico Nivel de Ontologías Nivel de Descripción de Recursos 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, establecio una jerarquía de abstracción y depencia 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 recomació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

237 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 SPARQL Motores de inferencia JENA Joseki. Datos representados en RDF, RDF-Schema u OWL 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

238 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

239 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 indepientes 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 indepientes ( 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 Empresa D Aceite Esencia Ingrediente Relleno Ácido Glucosa Miel Azúcar Jarabe Mermelada Colorante Leche Condensada 203

240 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, hacio 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 mantenio 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

241 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

242 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

243 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: y 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 S O I F Negación de conceptos atómicos y complejos Intersección de conceptos Restricciones universales Cuantificación existencial limitada Propiedades transitivas Clases enumeradas o restricción de valores de objetos (owl: oneof o owl:hasvalue) Propiedades inversas Propiedades funcionales 207

244 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

245 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

246 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

247 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

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

GLOSARIO. Análisis Bottom-Up: Técnica utilizada en tareas de ingeniería inversa la cual parte de

GLOSARIO. Análisis Bottom-Up: Técnica utilizada en tareas de ingeniería inversa la cual parte de GLOSARIO Análisis Bottom-Up: Técnica utilizada en tareas de ingeniería inversa la cual parte de una descripción de bajo nivel (código fuente) para generar descripciones con un mayor grado de abstracción.

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN

Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN Fernández Taurant, Juan Pablo Marciszack, Marcelo Martín Universidad Tecnológica Nacional, Facultad Regional

Más detalles

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software IX Contenidos Prólogo... XIX Prefacio... XXI Guía de lectura...xxiii Parte I - Introducción Capítulo 1 - Evolución 1.1 Introducción... 2 1.2 Los hitos en la evolución histórica del desarrollo de software...

Más detalles

JAVA EE 5. Arquitectura, conceptos y ejemplos.

JAVA EE 5. Arquitectura, conceptos y ejemplos. JAVA EE 5. Arquitectura, conceptos y ejemplos. INTRODUCCIÓN. MODELO DE LA APLICACIÓN JEE5. El modelo de aplicación Java EE define una arquitectura para implementar servicios como lo hacen las aplicaciones

Más detalles

Departamento Organización de Empresas TESIS DOCTORAL. Arquitectura, Metodología y Plataforma Tecnológica para

Departamento Organización de Empresas TESIS DOCTORAL. Arquitectura, Metodología y Plataforma Tecnológica para Departamento Organización de Empresas TESIS DOCTORAL Arquitectura, Metodología y Plataforma Tecnológica para la Ingeniería y Operación de Redes Colaborativas. Una aproximación basada en Servicios Digitales

Más detalles

Arquitectura de Empresa. Visión General

Arquitectura de Empresa. Visión General IX Congreso de Ingeniería de Organización Gijón, 8 y 9 de septiembre de 2005 de Empresa. Visión General Llanos Cuenca González 1, Ángel Ortiz Bas 1, Andrés Boza García 1 1 Centro de Investigación Gestión

Más detalles

UN MODELO DE OBJETOS PARA BILLS OF MATERIALS COMPLEJOS

UN MODELO DE OBJETOS PARA BILLS OF MATERIALS COMPLEJOS UN MODELO DE OBJETOS PARA BILLS OF MATERIALS COMPLEJOS Marcela Vegetti, Gabriela Henning, Horacio Leone INTEC, Güemes 3450, 3000 - Santa Fe, Argentina. ghenning@intec.unl.edu.ar INGAR/UTN, Avellaneda 3657,3000-Santa

Más detalles

MANUFACTURA INTERGRADA POR COMPUTADOR (Computer Integrated Manufacture)

MANUFACTURA INTERGRADA POR COMPUTADOR (Computer Integrated Manufacture) MANUFACTURA INTERGRADA POR COMPUTADOR (Computer Integrated Manufacture) Introducción CIM (Computer Integrated manufacturing) es un enfoque (o planeamiento) de la fabricación que emplea la tecnología informática

Más detalles

Búsqueda sobre catálogos basada en ontologías

Búsqueda sobre catálogos basada en ontologías Búsqueda sobre catálogos basada en ontologías Alianis Pérez Sosa, Yuniel Eliades Proenza Arias Universidad de las Ciencias Informáticas. Carretera a San Antonio Km 2 ½, Reparto Torrens, La Lisa, Ciudad

Más detalles

SERVICIOS: EXPLORACIONES EN SOA y WEB.

SERVICIOS: EXPLORACIONES EN SOA y WEB. SERVICIOS: EXPLORACIONES EN SOA y WEB. López, G. 1 ; Jeder, I 1.; Echeverría, A 1.; Grossi, M.D. 2 ; Servetto, A 2.; Fierro, P. (PhD.) 3 1. Laboratorio de Informática de Gestión - Facultad de Ingeniería.

Más detalles

Análisis comparativo entre CIMOSA (CIM-Open System Architecture) y DEM (Dynamic Enterprise Modelling)

Análisis comparativo entre CIMOSA (CIM-Open System Architecture) y DEM (Dynamic Enterprise Modelling) 3rd International Conference on Industrial Engineering and Industrial Management XIII Congreso de Ingeniería de Organización Barcelona-Terrassa, September 2nd-4th 2009 Análisis comparativo entre CIMOSA

Más detalles

1. CIDISI (UTN- FRSF) 2. CIDISI (UTN- FRCON) TE: 0342-4602390 Int. 258/107 TE: 0345-4214590

1. CIDISI (UTN- FRSF) 2. CIDISI (UTN- FRCON) TE: 0342-4602390 Int. 258/107 TE: 0345-4214590 Herramienta BPEL para el desarrollo de Aplicaciones de Comercio Electrónico con Servicios Web Baroni, Federico 1, Chezzi, Carlos María 2, y Tymoschuk, Ana Rosa 1 1. CIDISI (UTN- FRSF) 2. CIDISI (UTN- FRCON)

Más detalles

UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO" DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS

UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO" DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS MODELO DE GESTION WBEM PARA ADMINISTRACION DE REDES

Más detalles

HOJA TÉCNICA. SemTalk 2

HOJA TÉCNICA. SemTalk 2 HOJA TÉCNICA SemTalk 2 SemTalk 2 - Información Técnica SemTalk 2 es una herramienta para modelamiento de procesos de negocios y conocimientos orientado a objetos 100% compatible con MS Office. REQUERIMIENTOS

Más detalles

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

Más detalles

SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio

SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio Arturo Cepeda Pérez, Sergio Bravo Martín, Francisco José García Peñalvo Universidad de Salamanca, Facultad

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

Estrategia FastPDM. México, Julio 2012. F a s t P D M S t r a t e g y V e r. 3. 5 Julio 2012 P. 1

Estrategia FastPDM. México, Julio 2012. F a s t P D M S t r a t e g y V e r. 3. 5 Julio 2012 P. 1 Estrategia FastPDM México, Julio 2012 F a s t P D M S t r a t e g y V e r. 3. 5 Julio 2012 P. 1 > Concepto P L M QUE ES PLM? Product Lifecycle Management La Administración del Ciclo de Vida del Producto,

Más detalles

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

Más detalles

Capitulo III. Diseño del Sistema.

Capitulo III. Diseño del Sistema. Capitulo III. Diseño del Sistema. Para el desarrollo del sistema en la presente tesis se utilizo el paradigma orientado a objetos utilizando el lenguaje Java en su versión 1.2. Por medio de este lenguaje

Más detalles

Para el desarrollo de aplicaciones Web se han generado múltiples tecnologías entre ellas se encuentran:

Para el desarrollo de aplicaciones Web se han generado múltiples tecnologías entre ellas se encuentran: Desarrollo de aplicaciones y servicios web Cinxgler Mariaca Minda Cinxgler@udistrital.edu.co Presidente Capítulo de Computadores Rama IEEE Universidad Distrital Francisco José de Caldas Resumen: Este articulo

Más detalles

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Isaac Gutiérrez Gómez, Salvador Otón Tortosa Universidad de Alcalá, Departamento de Ciencias de la Computación, 28871 Alcalá de Henares, Spain igutierrez09@yahoo.es, salvador.oton@uah.es

Más detalles

El XBRL y sus aportes al intercambio de información financiera

El XBRL y sus aportes al intercambio de información financiera Universidad ORT Uruguay Facultad de Ingeniería El XBRL y sus aportes al intercambio de información financiera Entregado como requisito para la obtención del título de Licenciado en Sistemas Carlos Rial

Más detalles

Gestión de la Información

Gestión de la Información Gestión de la Información Sociedad de la Información Recurso Información Sistemas de Información Tecnologías de la Información Internet ii Fundamentos de SI: Gestión de la Información 49 Un Sistema de

Más detalles

El presente documento describe la importancia que está tomando el cómputo distribuido en

El presente documento describe la importancia que está tomando el cómputo distribuido en INTRODUCCIÓN El presente documento describe la importancia que está tomando el cómputo distribuido en los sistemas de administración integral o empresarial. Con un prototipo particular, mostraremos como

Más detalles

GLOSARIO DE TÉRMINOS

GLOSARIO DE TÉRMINOS MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM

AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM Fabio A. Zorzan y Daniel Riesco Resumen Esta línea de investigación propone una alternativa para lograr la automatización de la gestión

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

ESPECIFICACIONES PARA INTERFAZ ENTRE LOS ÁMBITOS FUNCIONALES CAD CAM, PARA EL DISEÑO DE NUEVOS PRODUCTOS.

ESPECIFICACIONES PARA INTERFAZ ENTRE LOS ÁMBITOS FUNCIONALES CAD CAM, PARA EL DISEÑO DE NUEVOS PRODUCTOS. ESPECIFICACIONES PARA INTERFAZ ENTRE LOS ÁMBITOS FUNCIONALES CAD CAM, PARA EL DISEÑO DE NUEVOS PRODUCTOS. A.S. Hurtado, W.H. Valencia, D.M. Muñoz Departamento de Electrónica, Instrumentación y Control,

Más detalles

RESUMEN. con referencia 1FD 1997-1387, titulado LA GESTIÓN DE LA CADENA DE SUMINISTRO EN CONTEXTO DE INTEGRACIÓN EMPRESARIAL

RESUMEN. con referencia 1FD 1997-1387, titulado LA GESTIÓN DE LA CADENA DE SUMINISTRO EN CONTEXTO DE INTEGRACIÓN EMPRESARIAL II Conferencia de Ingeniería de Organización Vigo, 5-6 Septiembre 2002 Propuesta para la Generación Automática de un Modelo de Workflow, para la Implantación de un Proceso de Negocio Definido según la

Más detalles

Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow

Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow Fabio A. Zorzan 1 y Daniel Riesco 2 Resumen Esta línea de investigación pretende aportar a la mejora

Más detalles

Tema 4: Diseño de flujos interaplicación

Tema 4: Diseño de flujos interaplicación Tema 4: Diseño de flujos interaplicación 4.1 Introducción a los Sistemas EAI Modelo de referencia (1) INTEGRACIÓN B2B INTEGRACIÓN DE APLICACIONES Y PROCESOS INTEGRACIÓN DE DATOS INTEGRACIÓN DE PLATAFORMA

Más detalles

enero febrero 2012 entrevista realizada por Jesús Rivero Presidente de DINTEL y editor de la revista DINTEL Alta Dirección. Fotografía Javier Fuentes

enero febrero 2012 entrevista realizada por Jesús Rivero Presidente de DINTEL y editor de la revista DINTEL Alta Dirección. Fotografía Javier Fuentes 124 entrevista realizada por Jesús Rivero Presidente de DINTEL y editor de la revista DINTEL Alta Dirección. Fotografía Javier Fuentes encuentrocon... Valeria de Castro Red de Servicios Web Investigadora

Más detalles

Tecnología de objetos distribuidos y arquitectura de componentes. Índice. Bibliografía. Introducción. Tema V

Tecnología de objetos distribuidos y arquitectura de componentes. Índice. Bibliografía. Introducción. Tema V Bibliografía Tema V Tecnología de objetos distribuidos y arquitectura de componentes. Szyperski, C. 1998. Component Software. Addison-Wesley. Ruiz Cortés, 1998. A. CORBA: Una visión general. http://www.lsi.us.es/~aruiz

Más detalles

Servicio Web. Estándares empleados. Ventajas de los servicios web. Inconvenientes de los servicios Web

Servicio Web. Estándares empleados. Ventajas de los servicios web. Inconvenientes de los servicios Web Servicio Web Un servicio web (en inglés, Web services) es una tecnología que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones

Más detalles

Service Oriented Architecture

Service Oriented Architecture Programación Concurrente y Distribuida Ingeniería en Informática Service Oriented Architecture José Carlos Cortizo Pérez josecarlos.cortizo@uem.es http://www.esp.uem.es/jccortizo D. Sistemas Informáticos

Más detalles

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms Patrones Patrones Es una solución reusable de problemas comunes. Los patrones solucionan problemas que existen en muchos niveles de abstracción. desde el análisis hasta el diseño y desde la arquitectura

Más detalles

Boletín de Asesoría Gerencial* Business Process Management (BPM)

Boletín de Asesoría Gerencial* Business Process Management (BPM) Espiñeira, Sheldon y Asociados * No. 11-2009 *connectedthinking Contenido Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección

Más detalles

Sistemas ERP (Enterprise Resources Planning)

Sistemas ERP (Enterprise Resources Planning) Sistemas ERP (Enterprise Resources Planning) Apellidos, nombre Departamento Centro Oltra Badenes, Raúl Francisco (rauloltra@doe.upv.es) Departamento de Organización de Empresas Universitat Politècnica

Más detalles

EVOLUCIÓN DE LA WEB. Presentado por: Pablo E. Lozada Y. (pablo.lozada@alumnos.usm.cl)

EVOLUCIÓN DE LA WEB. Presentado por: Pablo E. Lozada Y. (pablo.lozada@alumnos.usm.cl) EVOLUCIÓN DE LA WEB Presentado por: Pablo E. Lozada Y. (pablo.lozada@alumnos.usm.cl) Contenido Historia del Internet. La Web 1.0. Definición. Características. La Web 2.0. Definición. Tecnologías de la

Más detalles

Organizaciones Virtuales e Integración de Información. José Abásolo Prieto

Organizaciones Virtuales e Integración de Información. José Abásolo Prieto Organizaciones Virtuales e Integración de Información José Abásolo Prieto Universidad de los Andes Objetivo de la charla Mostrar que aunque la problemática de integración de información distribuida y heterogénea

Más detalles

BPM: Articulando Estrategia, Procesos y Tecnología

BPM: Articulando Estrategia, Procesos y Tecnología BPM: Articulando Estrategia, Procesos y Tecnología Resumen: La competitividad es el imaginario que dirige las acciones empresariales en la actualidad. Lograr condiciones que permitan competir con mayores

Más detalles

Siemens PLM Connection

Siemens PLM Connection Siemens PLM Connection Noviembre 6, 2012 Ing. Ruben F. Gil X-Plan s.r.l. Haga de su ERP su Base de Datos de Ingeniería 2012. Siemens Product Lifecycle Management Protection Software notice Inc. / Copyright

Más detalles

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3

Más detalles

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje

Más detalles

Aplicaciones Distribuidas. Informática III

Aplicaciones Distribuidas. Informática III Aplicaciones Distribuidas Informática III Temario Elementos arquitecturales Arquitecturas tradicionales Arquitecturas Cliente/Servidor Arquitecturas distribuidas Elementos Arquitecturales Componentes de

Más detalles

Anexo 4 Documento de Arquitectura

Anexo 4 Documento de Arquitectura Anexo 4 Documento de Arquitectura 1. Introducción El anexo se describe el propósito y alcance referentes al proyecto correspondiente al documento de arquitectura. 2. Propósito El propósito del anexo de

Más detalles

GLOSARIO DE TERMINOS

GLOSARIO DE TERMINOS GLOSARIO DE TERMINOS A Aplicaciones Legacy.- Conjunto de aplicaciones desarrolladas o implementadas en plataformas de sistemas anteriores o antiguos. B Bases de Datos.- Organización y conservación de datos

Más detalles

MODULO I Introducción y Gestión de Materiales MODULO II Revisión Estratégica de la Cadena de Abastecimiento MODULO III Planificación y Forecasting

MODULO I Introducción y Gestión de Materiales MODULO II Revisión Estratégica de la Cadena de Abastecimiento MODULO III Planificación y Forecasting MODULO I Introducción y Gestión de Materiales Logística y Supply Chain Management (SCM): Conceptos y datos para entender la actividad en el orden local, regional e internacional. Funciones básicas que

Más detalles

Figura 1. Diagrama de la Cadena de suministro de Boehringer Ingelheim Promeco

Figura 1. Diagrama de la Cadena de suministro de Boehringer Ingelheim Promeco suministro de materias primas hasta el consumidor final. Este proceso incluye la compra de materiales, programación de producción, procesamiento de órdenes, control de inventarios, transportación, almacenamiento

Más detalles

Ciclo Formativo de Grado Superior Desarrollo de Aplicaciones Web

Ciclo Formativo de Grado Superior Desarrollo de Aplicaciones Web Ciclo Formativo de Grado Superior Desarrollo de Aplicaciones Web Proyecto Propio de Ampliación con Programación de Dispositivos Móviles e Inteligentes Paseo de la Puerta del Ángel, s/n 28011 Madrid www.iesellago.net

Más detalles

FORMACIÓN E-LEARNING. Curso de Supply Chain Management

FORMACIÓN E-LEARNING. Curso de Supply Chain Management FORMACIÓN E-LEARNING Curso de Supply Chain Management Para realizar procesos de diseño, implantación y mantenimiento de todas las operaciones que la empresa realiza para satisfacer la demanda de sus clientes.

Más detalles

Seminario en CD Bases para Java

Seminario en CD Bases para Java G: Suplementos Hay varios suplementos para este libro, incluyendo el seminario grabado en el CD que se encuentra en la parte trasera del libro y otros artículos, seminarios y servicios disponibles a través

Más detalles

Modelado de Procesos

Modelado de Procesos Modelado de Procesos Material desarrollado por -An. Miguel Brunnello y Cr. Marcelo Rocha Vargas (1ra.versión 2010) -Cr. Marcelo Rocha Vargas (Actualización 2011) Introducción En los orígenes de las TICs,

Más detalles

Desarrollo y comercialización de productos de software [El proceso unificado]

Desarrollo y comercialización de productos de software [El proceso unificado] Desarrollo y comercialización de productos de software [El proceso unificado] M. en C. Sergio Luis Pérez Pérez UAM CUAJIMALPA, MÉXICO, D. F. Trimestre 13-P Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo

Más detalles

DISEÑO DE APLICACIONES WEB BASADAS EN ARQUITECTURAS ORIENTADAS A SERVICIOS (AOS), UTILIZANDO WEBML

DISEÑO DE APLICACIONES WEB BASADAS EN ARQUITECTURAS ORIENTADAS A SERVICIOS (AOS), UTILIZANDO WEBML DISEÑO DE APLICACIONES WEB BASADAS EN ARQUITECTURAS ORIENTADAS A SERVICIOS (AOS), UTILIZANDO WEBML Luís Fernando GONZÁLEZ ALVARÁN Facultad de Ingenierías, Politécnico Colombiano Jaime Isaza Cadavid Medellín,

Más detalles

Componentes y Middleware. Arquitectura de Software Componentes y Middleware [1] Stakeholders. Sobre el informe. Calidad según los stakeholders

Componentes y Middleware. Arquitectura de Software Componentes y Middleware [1] Stakeholders. Sobre el informe. Calidad según los stakeholders sistema Componentes y Middleware Arquitectura de Software Componentes y Middleware [1] Componentes Middleware Políticas y mecanismos Ejemplo de notación ad-hoc Hernán Astudillo Departamento de Informática

Más detalles

Tema 1. Introducción a Java EE

Tema 1. Introducción a Java EE Objetivos del tema Propiedades de las aplicaciones empresariales El Modelo Cliente/Servidor Presentar la Plataforma Java Presentar Java EE y otras tecnologías horizontales Tema 1. Introducción a Java EE

Más detalles

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA 3.1. Características La tendencia hacia el futuro es el de lograr la integración total de componentes realizados por terceras partes, para lo cual es necesario

Más detalles

Proyecto de trabajo de iniciación a la investigación

Proyecto de trabajo de iniciación a la investigación Proyecto de trabajo de iniciación a la investigación Título: Aplicación de tecnologías de la Web Semántica en el dominio sanitario. Sistemas de Información Sanitarios Semánticos (SISS). Autor: Tutor: Propuesta

Más detalles

Arquitectura de Software Componentes y Middleware [1] Componentes y Middleware. Sobre el informe

Arquitectura de Software Componentes y Middleware [1] Componentes y Middleware. Sobre el informe Arquitectura de Software Componentes y Middleware [1] Hernán Astudillo Departamento de Informática Universidad Técnica Federico Santa María Componentes y Middleware Componentes Middleware

Más detalles

8.1 Arquitectura funcional

8.1 Arquitectura funcional 1 Colección de Tesis Digitales Universidad de las Américas Puebla Zuñiga, Víctor Alejandro 8.1 Arquitectura funcional La arquitectura de un sistema define sus componentes básicos y los conceptos importantes,

Más detalles

Escuela de Ingeniería en Informática Empresarial SYLLABUS

Escuela de Ingeniería en Informática Empresarial SYLLABUS Nombre módulo PROGRAMACIÓN Y TALLER DE INTERNET Nº créditos 10 ECTS ( 270 horas totales, 108 horas presenciales, 162 horas de trabajo autónomo) Nivel Requisitos Responsable(s) de la construcción del syllabus

Más detalles

SISTEMAS DE INFORMACIÓN PARA ADMINISTRACIÓN DE OPERACIONES. Manufactura Integrada por Computadora (CIM) Qué es es CIM?

SISTEMAS DE INFORMACIÓN PARA ADMINISTRACIÓN DE OPERACIONES. Manufactura Integrada por Computadora (CIM) Qué es es CIM? SISTEMAS DE INFORMACIÓN PARA ADMINISTRACIÓN DE OPERACIONES 2003 Manufactura Integrada por Computadora (CIM) Qué es es CIM? Bajo el nombre de CIM se engloba a un conjunto de aplicaciones informáticas cuyo

Más detalles

Instalación de Sistemas de Automatización y Datos

Instalación de Sistemas de Automatización y Datos UNIVERSIDADE DE VIGO E. T. S. Ingenieros Industriales 5º Curso Orientación Instalaciones y Construcción Instalación de Sistemas de Automatización y Datos José Ignacio Armesto Quiroga http://www www.disa.uvigo.es/

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Aplicación de la categoría Administración de Operaciones de Calidad del estándar ISA-95 a un Caso de Estudio

Aplicación de la categoría Administración de Operaciones de Calidad del estándar ISA-95 a un Caso de Estudio Aplicación de la categoría Administración de Operaciones de Calidad del estándar ISA-95 a un Caso de Estudio Andrés Alejandro Sánchez* Diego Leonardo Zuñiga* Oscar A. Rojas A* * Grupo de I+D en Automática

Más detalles

Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos

Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos Autora: Vasquez Pilar María Directora: Dra. Giandini Roxana Codirectora: Mg. Bazán Patricia Agenda Introducción.

Más detalles

Historia de revisiones

Historia de revisiones Binary Rain Glosario Versión 1.1 Historia de revisiones Fecha Versión Descripción Autor 17/08/2012 1.0 Creación del documento Carolina Trias 18/08/2012 1.1 Revisado y corregido por SQA Mercedes Marzoa

Más detalles

Qué significa workflow? Qué es un proceso de negocio? Qué es un software de workflow? Qué es Q-flow?

Qué significa workflow? Qué es un proceso de negocio? Qué es un software de workflow? Qué es Q-flow? Qué significa workflow? Es un término en inglés para proceso de negocio. Su uso en ese idioma se extendió para todo lo vinculado a herramientas informáticas que contribuyen a la automatización y al control

Más detalles

EXPERIENCIAS EN LA GESTIÓN DE APLICACIONES DISTRIBUIDAS

EXPERIENCIAS EN LA GESTIÓN DE APLICACIONES DISTRIBUIDAS EXPERIENCIAS EN LA GESTIÓN DE APLICACIONES DISTRIBUIDAS Jorge E. López de Vergara, Víctor A. Villagrá, Juan I. Asensio, José I. Moreno, Julio J. Berrocal. Dept. de Ingeniería de Sistemas Telemáticos Universidad

Más detalles

Capítulo 1. Introducción

Capítulo 1. Introducción Capítulo 1. Introducción El WWW es la mayor fuente de imágenes que día a día se va incrementando. Según una encuesta realizada por el Centro de Bibliotecas de Cómputo en Línea (OCLC) en Enero de 2005,

Más detalles

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra Si en otros tiempos el factor decisivo de la producción era la tierra y luego lo fue el capital... hoy día el factor decisivo es cada vez más el hombre mismo, es decir, su conocimiento... Juan Pablo II

Más detalles

Modelos de los sistemas distribuidos. Jorge Iván Meza Martínez jimezam@gmail.com

Modelos de los sistemas distribuidos. Jorge Iván Meza Martínez jimezam@gmail.com Modelos de los sistemas distribuidos Jorge Iván Meza Martínez jimezam@gmail.com Especialización en Gestión de Redes de Datos Universidad Nacional de Colombia Sede Manizales 1/36 Contenidos Modelo arquitectónico

Más detalles

CAPÍTULO 5. DESARROLLO Y PRUEBAS

CAPÍTULO 5. DESARROLLO Y PRUEBAS CAPÍTULO 5. DESARROLLO Y PRUEBAS 5.1 Introducción a las Tecnologías 5.1.1 Herramientas 5.1.1.1 SQL Server Es un sistema que sirve para la gestión de base de datos basado en un modelo relacional. Así mismo

Más detalles

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo.

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo. GLOSARIO Actor: Un actor es un usuario del sistema. Esto incluye usuarios humanos y otros sistemas computacionales. Un actor usa un Caso de Uso para ejecutar una porción de trabajo de valor para el negocio.

Más detalles

ONTOLOGÍAS E INTELIGENCIA ARTIFICIAL PARA LA RECUPERACIÓN EFICIENTE DEL CONOCIMIENTO

ONTOLOGÍAS E INTELIGENCIA ARTIFICIAL PARA LA RECUPERACIÓN EFICIENTE DEL CONOCIMIENTO ONTOLOGÍAS E INTELIGENCIA ARTIFICIAL PARA LA RECUPERACIÓN EFICIENTE DEL CONOCIMIENTO Antonio Martín*, Sonsoles Celestino, Adela Valdenebro, Julia Mensaque. Biblioteca Universidad de Sevilla, C/ San Fernando

Más detalles

Gestión de la Información Multimedia en Internet Gestión del conocimiento DAML y ontologías consensuadas

Gestión de la Información Multimedia en Internet Gestión del conocimiento DAML y ontologías consensuadas Gestión de la Información Multimedia en Internet Gestión del conocimiento DAML y ontologías consensuadas Autor: Pablo Barrera González Profesor: Carlos Delgado Kloos Fecha de presentación: 7 de Febrero

Más detalles

WEBBER: USO DE COMPONENTES PARA LA ARMONIZACIÓN DE CONTENIDOS Y METADATOS

WEBBER: USO DE COMPONENTES PARA LA ARMONIZACIÓN DE CONTENIDOS Y METADATOS WEBBER: USO DE COMPONENTES PARA LA ARMONIZACIÓN DE CONTENIDOS Y METADATOS Autores: Introducción Diego R. López RedIRIS diego.lopez@rediris.es El trabajo necesario para mantener un servidor de información

Más detalles

Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio. Contexto

Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio. Contexto Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio Parra Julián Matias 1, Mg. Patricia Bazán 2, Lic. José Martinez Garro 3 1 3 Facultad de Informática

Más detalles

Arquitecturas de Software

Arquitecturas de Software Arquitecturas de Software Ingeniería del Universidad Rey Juan Carlos César Javier Acuña cjacunia@escet.urjc.es Índice Introducción Motivación Definición Pipes and Filters Tipos abstractos de datos y OO

Más detalles

Christian Bolívar Moya Calderón

Christian Bolívar Moya Calderón UNIVERSIDAD SAN FRANCISCO DE QUITO Software Orientado a Sistemas de Control HMI/Scada usando Recursos Libres y de Código Abierto, desarrollado sobre Plataforma Linux Christian Bolívar Moya Calderón Tesis

Más detalles

UML El Lenguaje de Modelado Unificado. Maestría en Ingeniería de Software

UML El Lenguaje de Modelado Unificado. Maestría en Ingeniería de Software UML El Lenguaje de Modelado Unificado Maestría en Ingeniería de Software Agenda Model Driven Architecture (MDA) Unified Model Language (UML) Object Constraint Language (OCL) Patrones Conclusiones Contenido

Más detalles

Universidad Autónoma Metropolitana

Universidad Autónoma Metropolitana Universidad Autónoma Metropolitana Unidad Azcapotzalco División de Ciencias Básicas e Ingeniería Licenciatura en Ingeniería en Computación Propuesta de Proyecto Terminal Composición de servicios web para

Más detalles

FORMACIÓN E-LEARNING. Curso de Puntos Clave en el Supply Chain Management

FORMACIÓN E-LEARNING. Curso de Puntos Clave en el Supply Chain Management FORMACIÓN E-LEARNING Curso de Puntos Clave en el Supply Chain Management Para realizar procesos de diseño, implantación y mantenimiento de todas las operaciones que la empresa realiza para satisfacer la

Más detalles

1 Índice... 1. 2 Introducción... 2. 2.1 Propósito... 2. 2.2 Alcance... 2. 3 Modelo Arquitectónico Inicial... 3

1 Índice... 1. 2 Introducción... 2. 2.1 Propósito... 2. 2.2 Alcance... 2. 3 Modelo Arquitectónico Inicial... 3 1 Índice 1 Índice... 1 2 Introducción... 2 2.1 Propósito... 2 2.2 Alcance... 2 3 Modelo Arquitectónico Inicial... 3 3.1 Diagrama de alto nivel de la arquitectura... 3 3.2 Vista de Casos de Uso... 5 3.2.1

Más detalles

6.1 Introducción a los sistemas EAI

6.1 Introducción a los sistemas EAI 6.1 Introducción a los sistemas EAI Integración de Aplicaciones (1) El problema de la integración de aplicaciones consiste en hacer colaborar entre sí a aplicaciones distribuidas, heterogéneas y posiblemente

Más detalles

SISTEMAS DE INFORMACIÓN III TEORÍA

SISTEMAS DE INFORMACIÓN III TEORÍA CONTENIDO: Introducción a los Web services Las bases de los Web services La nueva generación de la Web Interactuando con los Web services La tecnología de Web services XML: Lo fundamental WSDL: Describiendo

Más detalles

Tecnologías para Desarrollo Orientado a Servicios (posgrado) Desarrollo de Software Orientado a Servicios (pregrado)

Tecnologías para Desarrollo Orientado a Servicios (posgrado) Desarrollo de Software Orientado a Servicios (pregrado) Tecnologías para Desarrollo Orientado a Servicios (posgrado) Desarrollo de Software Orientado a Servicios (pregrado) Mg. Elsa Estévez Universidad Nacional del Sur T.2 Contenidos 1 1) lenguaje XML extensible

Más detalles

Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software

Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software Ramón Gómez-Romero, Karen Cortés Verdin, Juan Carlos Pérez Arriaga, Ángeles Arenas Valdés Universidad

Más detalles

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Tema 5: El Lenguaje Unificado de Modelado Departamento de Lenguajes y Sistemas Informáticos II Contenidos Introducción Diagramas de UML Modelado de la parte estática Modelado de la parte dinámica Las 4+1

Más detalles

Portal de Aplicaciones Médicas

Portal de Aplicaciones Médicas Portal de Aplicaciones Médicas Ing. Javier A. Voos 1 - Ing. Eduardo Gonzalez 2 - Ing. Fernando Cagnolo 2 1 Ingeniero en Sistemas de Información U.T.N. Facultad Regional Córdoba - Argentina 2 Ingeniero

Más detalles

INTRODUCCIÓN A SAP. 22 de octubre de 2009 AlfilSAP.com. Copyright 2009 Ricardo Naya ricardo.naya@alfilsap.com

INTRODUCCIÓN A SAP. 22 de octubre de 2009 AlfilSAP.com. Copyright 2009 Ricardo Naya ricardo.naya@alfilsap.com INTRODUCCIÓN A SAP 22 de octubre de 2009 AlfilSAP.com Copyright 2009 Ricardo Naya ricardo.naya@alfilsap.com Pág 2 de 8 1. Introducción El siguiente curso está diseñado para aquellas personas que no tienen

Más detalles

1. PRESENTACIÓN GLOBAL LEAN.

1. PRESENTACIÓN GLOBAL LEAN. GLOBAL LEAN APPS 1. PRESENTACIÓN GLOBAL LEAN. GLOBALLEAN apuesta por mejorar la competitividad de las empresas. Y una herramienta clave para conseguir mejoras de competitividad que deriven en resultados

Más detalles

UNIVERSIDAD DE SANTANDER UDES

UNIVERSIDAD DE SANTANDER UDES UNIVERSIDAD DE SANTANDER UDES Programa Nombre Código Facultad Administración e Ingenierias Ingenieria de Sistemas Arquitectura Orientada a Servicios (SOA) Problema? Competencia específica Rango de Aplicación

Más detalles

Trabajo Final de Graduación para optar por el título. Bachiller en Ingeniería en Computación

Trabajo Final de Graduación para optar por el título. Bachiller en Ingeniería en Computación Trabajo Final de Graduación para optar por el título Bachiller en Ingeniería en Computación Migración del Módulo de Inventario del Sistema Business Advance Víctor Guzmán Alfaro Carrera Ingeniería en Computación

Más detalles