analisis, dise´ no y modelado de una l˜ ´ınea piloto de

INSTITUTO POLITECNICO NACIONAL

CENTRO DE INVESTIGACION EN CIENCIA

APLICADA Y TECNOLOGIA AVANZADA

UNIDAD QUERETARO

POSGRADO EN TECNOLOGIA AVANZADA

Analisis, Diseno y Modelado de una Lınea Piloto

de Manufactura Usando Lenguaje Unificado de

Modelado

TESIS

QUE PARA OBTENER EL GRADO DE

MAESTRIA EN TECNOLOGIA AVANZADA

PRESENTA

Ing. Francisco Ivan Silva Tapia

DIRECTORES

Dr. Adrian Luis Garcıa Garcıa

Dr. Rodolfo Orosco Guerrero

Santiago de Queretaro Qro. a 9 de enero de 2014

A las personas que siempre se esforzaron para que yo cumpliera mis

suenos y anhelos. De ellos siempre he recibido amor, comprension y

apoyo incondicional

Mis padres

Agradecimientos

A mis padres y mi hermana

Porque en ellos siempre he encontrado amor y un apoyo incondicional

A mi asesor

Cuyas lecciones y experiencias contribuyeron sobremanera en mi formacion cientıfica y tecnologica.

A mi familia

Que siempre me ha brindado su ayuda en los momentos difıciles.

A mi novia

Vicky, tu ayuda y tu companıa durante este tiempo han sido una parte muy importante de mi vida.

A CICATA Queretaro

Por permitirme hacer uso de sus equipo e instalaciones.

A CONACyT

Por su apoyo economico durante mi estancia en la Maestrıa.

IX

Tengamos la completa seguridad de que mientras mas disciplinados

seamos de pensamientos, mas prudentes y responsables seremos al

momento de emitir una verdad. Es de hombres pedantes creerse los

duenos de la verdad, un hombre honesto reconoce sus limitaciones y

admite sencillamente que es imposible saberlo todo...

F. Nietzsche.

Resumen

El sector industrial de manufactura se ha caracterizado por ser uno de los escenarios favoritos para los gran-

des avances tecnologicos gracias a la constante competencia en los mercados. Las empresas actuales deben de

contar con metodologıas para desarrollar procesos suficientemente flexibles capaces de responder a los rapidos

cambios en los mercados, ası como tambien aprovechar las oportunidades que presentan los nuevos nichos de

mercado y tener la posibilidad de adaptar de la manera mas eficiente los procesos de produccion a la elaboracion

de nuevos productos.

El presente trabajo muestra el desarrollo de una lınea piloto de manufactura mediante herramientas comunmente

usadas para el desarrollo de sistemas complejos de software: Lenguaje Unificado de Modelado y Metodologıa

de Analisis de Sistemas. La necesidad de desarrollar el sistema de manufactura bajo una metodologıa orientada

a objetos, obedece a que la lınea de manufactura esta pensada para experimentar nuevos metodos de produccion

y el desarrollo de nuevos productos, por lo que se requiere de una alta flexibilidad y reusabilidad de componen-

tes, ası como la generacion y procesamiento de gran cantidad de datos.

Se adapto el lenguaje para descripcion de sistemas UML, en la construccion de un sistema de manufactura

a partir de las requerimientos funcionales del usuario. El diseno y modelado del sistema se realizo usando la

herramienta CASE Enterprise Architect. El diseno fue el resultado de iteraciones mediante entrevistas entre el

usuario final y el equipo multidisciplinario de diseno. Una vez que el usuario estuvo conforme con el modelo

del sistema en UML, el equipo de diseno determino los requerimientos tecnicos del sistema y selecciono los

dispositivos que constituyen el sistema. El diseno del sistema se realizo sobre el modelo de UML donde se

consideran las interacciones y comunicacion que debıa existir entre los diferentes elementos del sistema.

El modelo del sistema elaborado con la herramienta CASE permitio generar de forma casi automatica la docu-

mentacion del sistema, necesaria para comprender e implentar el mismo, estos son: diagramas de bloques del

sistema, flujos de informacion y descripcion tecnica de los componentes del sistema. Todo esto gracias al pro-

cedimiento de diseno del sistema en CASE, que solicita la mayor cantidad de informacion posible para obtener

el modelo del sistema.

I

Abstract

The manufacturing industry has been one of the main protagonists of the major technological advances due to

the hard struggle for the markets. The prevailing companies must have methodologies to develop flexible pro-

cesses capable to respond to the fast changes of the markets, to move ahead when new niche markets come up,

and to have the possibility to efficiently adapt their processes to manufacture new products.

This work shows the development of a pilot manufacture line employing tools commonly used in the deve-

lopment of complex systems of software, like Unified Modeling Language (UML) and System Methodology

Analysis. The development of a manufacturing system under an object-oriented methodology allowed to try out

new production processes and to develop new products, which requires a high flexibility, reusability of compo-

nents, and generation and processing of data.

UML software was used to build the manufacturing system based on the user’s functional requirements. Design

and modeling of the system was performed by means of a CASE Enterprise Architect tool. The design came up

from iterative interviews with the end user and multidisciplinary design team. Once the end user was satisfied

with the system model, depicted by UML, the design team determined the system technical requirements, and

then elected the devices that would comprise the system. System designed was based on the UML model, in

which the interactions and communication that must exist between all elements were considered.

The model of the system, made by using the CASE tool, created almost automatically the system’s documents,

which are necessary for its understanding and implementation. Those documents are: block diagrams, informa-

tion flow, and technical description of system components. All these due to the design of the system in CASE,

which manages the greatest amount of information to obtain the model of the system.

III

Indice general

Resumen I

Abstract III

Indice general V

Indice de figuras IX

Indice de tablas XI

1. Marco de referencia 1

1.1. Retos de las empresas de manufactura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. El enfoque OO en el modelado de sistemas de manufactura . . . . . . . . . . . . . . . . . . . . 4

1.2.1. El enfoque OO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.2. Estado del arte del enfoque orientado a objetos en el desarrollo de sistemas de manufactura 6

1.3. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3.1. Definicion del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4. Hipotesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.5. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.5.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.5.2. Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2. Marco teorico 11

2.1. Los sistemas de manufactura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.1. Definicion de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.2. Conceptos sobre sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.3. La manufactura como un sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2. La informacion en los procesos de manufactura . . . . . . . . . . . . . . . . . . . . . . . . . . 24

V

INDICE GENERAL

2.2.1. Modelo conceptual de un sistema de informacion . . . . . . . . . . . . . . . . . . . . . 28

2.3. Generalidades en el analisis de sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.3.1. Determinacion de los requerimientos de informacion del usuario . . . . . . . . . . . . . 31

2.3.2. Analisis de las necesidades del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.3.3. Las organizaciones como sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.3.4. Modelado de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.3.5. Planeacion y control de actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.3.6. La metodologıa del flujo de datos para determinar los requerimientos de los usuarios . . 36

2.3.7. Especificaciones de los procesos y decisiones estructuradas . . . . . . . . . . . . . . . . 38

2.3.8. Conceptos y diagramas del Lenguaje Unificado de Modelado (UML) . . . . . . . . . . 39

2.3.9. Diseno de una salida del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.3.10. Diseno de una entrada efectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.3.11. Interaccion Humano-Computadora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2.4. Modelado de sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.4.1. El Lenguaje Unificado de Modelado (UML) . . . . . . . . . . . . . . . . . . . . . . . . 50

2.4.2. Enterprise Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3. Metodo de desarrollo del Sistema Integral de Manufactura 55

3.1. Identificacion de los problemas, oportunidades y objetivos . . . . . . . . . . . . . . . . . . . . 56

3.2. Determinacion de los requerimientos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.2.1. Requerimientos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.2.2. Modelado del dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58


3.3. Analisis de las necesidades del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.4. Diseno preliminar del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.5. Diseno detallado del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.6. Revision crıtica del diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.7. Implementacion y evaluacion del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4. Desarrollo de la lınea prototipo 65

4.1. Identificacion de los problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.2. Determinacion de los requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.2.1. Secuencia del proceso de produccion . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.2.2. Modelado del dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69


4.3. Analisis de las necesidades del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.4. Diseno preliminar del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

INDICE GENERAL

4.5. Diseno detallado del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.6. Revision crıtica del diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5. Modelo del sistema 83

5.1. Diseno del sistema en la plataforma Enterprise Architect . . . . . . . . . . . . . . . . . . . . . 83

6. Discusion y Conclusion 91

Referencias 93

7. Anexos 101

INDICE GENERAL

Indice de figuras

1.1. Modelo V del proceso de diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1. Distincion entre las formas de estudiar un sistema, donde a y b simbolizan los complejos . . . . 11

2.2. Esquema del Sistema de Manufactura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3. Esquema de un taller de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4. Esquema de un taller de proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5. Esquema de un sistema celular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.6. Esquema mostrando la estructura de una linea de flujo . . . . . . . . . . . . . . . . . . . . . . . 21

2.7. Esquema de un sistema continuo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.8. Ejemplo de un diagrama de flujo de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.9. Ejemplos de casos de uso y los diferentes conectores . . . . . . . . . . . . . . . . . . . . . . . 34

2.10. El diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.11. Ejemplo de un diagrama de flujo de datos fısico . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.12. Ejemplo de un diagrama de flujo de datos logico . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.13. Simbologıa de un diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.14. Ejemplo del diagrama de secuencia aplicado a una maquina CNC . . . . . . . . . . . . . . . . . 43

2.15. Ejemplo de un diagrama de clases en una empresa . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.16. Ejemplo de un diagrama de estados en una lınea de elaboracion de pistones . . . . . . . . . . . 46

3.1. El ciclo en el proceso de desarrollo de sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.2. Ejemplo de un diagrama de clases de un sistema de manufactura . . . . . . . . . . . . . . . . . 60

4.1. Diagrama de requerimientos funcionales del sistema realizado en Enterprise Architec . . . . . . 68

4.2. Captura de pantalla de diagrama de requerimientos en Enterprise Architect . . . . . . . . . . . . 69

4.3. Esquema del proceso como lo propone el usuario final . . . . . . . . . . . . . . . . . . . . . . 69

4.4. Imagenes y datos obtenidos del producto entre cada etapa . . . . . . . . . . . . . . . . . . . . . 70

IX

INDICE DE FIGURAS

4.5. Diagrama de casos de uso del sistema implementado . . . . . . . . . . . . . . . . . . . . . . . 71

4.6. Captura de pantalla con la descripcion de uno de los casos de uso del sistema . . . . . . . . . . 71

4.7. Descomposicion del diagrama en sus clases principales: Rociado, Carga y Recubrimiento . . . . 72

4.8. Clases y objetos definidos para las etapas de Rociado y Carga. . . . . . . . . . . . . . . . . . . 73

4.9. Clases, subclases y objetos definidos para la etapa de Recubrimiento . . . . . . . . . . . . . . . 74

4.10. Descripcion de cada una de las clases dispuestas en el diagrama . . . . . . . . . . . . . . . . . 75

4.11. Diagrama de clases de la lınea de manufactura prototipo . . . . . . . . . . . . . . . . . . . . . 76

4.12. Ejemplo de descomposicion de un sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.13. Diagrama de secuencia del proceso desarrollado . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.1. Descripcion del proceso desarrollado en UML . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.2. Primera etapa del proceso disenado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.3. Vista del bloque de Informacion de entrada para inicializar el sistema . . . . . . . . . . . . . . 85

5.4. Etapa de Rociado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.5. Contenido del bloque del sistema de Eductor en la de descripcion de bloque . . . . . . . . . . . 86

5.6. Contenido del bloque del sistema de Eductor en la descripcion de las partes que lo conforman . 86

5.7. Contenido del bloque de informacion de entrada al proceso de eductor . . . . . . . . . . . . . . 87

5.8. Contenido del bloque de informacion de salida del proceso de eductor . . . . . . . . . . . . . . 87

5.9. Contenido del bloque de informacion obtenida del producto de la etapa de rociado . . . . . . . . 88

5.10. Etapa de carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.11. Etapa de recubrimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Indice de tablas

2.1. Ejemplos de funciones en los dos modos de operacion . . . . . . . . . . . . . . . . . . . . . . . 28

2.2. Los sımbolos basicos utilizados en los diagramas de flujo de datos. . . . . . . . . . . . . . . . . 37

4.1. Caracterısticas principales de los motores usados. . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.2. Caracterısticas principales de los controladores de motor. . . . . . . . . . . . . . . . . . . . . . 78

4.3. Caracterısticas principales de los dispositivos neumaticos. . . . . . . . . . . . . . . . . . . . . . 78

4.4. Revision los requerimientos del sistema vs el diagrama de secuencia . . . . . . . . . . . . . . . 81

XI

INDICE DE TABLAS

XII

CAPITULO PRIMERO

MARCO DE REFERENCIA

Este primer capıtulo tiene como objetivo situar al lector dentro del entorno de este trabajo de investigacion. Se

comienza con un breve marco historico sobre la la evolucion las empresas de manufactura en general y los cam-

bios que obligaron a que esta se produjera. A continuacion se describe la necesidad de cambiar el paradigma en

el modelado de estos sistemas usando lenguaje Orientado a Objetos (OO) y, en particular UML. Se citan varios

trabajos de investigacion sobre la aplicacion de la semantica del enfoque Orientado a Objetos y algunos que ya

han logrado aplicaciones en el entorno industrial. Por ultimo, este capıtulo cuenta con las partes esenciales de

toda tesis: la descripcion del problema, hipotesis y objetivos.

La manufactura es una actividad humana que se encuentra en practicamente todos los aspectos de nuestra vida,

ya que sus productos pueden encontrarse por doquier. Actualmente, los productos mas comunes y basicos usa-

dos en nuestra vida diaria provienen de procesos industriales de manufactura. De lo anterior, se puede definir la

manufactura como una entidad que transforma materiales e informacion en bienes para satisfacer las necesida-

des humanas [1].

La historia de la manufactura esta marcada por desarrollos graduales desde la revolucion industrial en el siglo

XVIII, pero los efectos acumulados han tenido sustanciales consecuencias sociales, las cuales pueden hasta

considerarse revolucionarias.

Una de las caracterısticas mas incisivas del desarrollo tecnologico es el drastico incremento en nuestra capaci-

dad para reunir y procesar informacion. En general, se acepta que hemos entrado en la Era de la Informacion.

Debido a que el campo de la manufactura integra diversas disciplinas en ingenierıa y gestion, en la actualidad

es usual dividirla de manera que se facilite la identificacion de problemas y areas de oportunidad para ası darle

un enfoque cientıfico a los problemas encontrados.

La globalizacion ha obligado a cambiar distintos sectores de las empresas, ya que ahora se cuenta con canales

mucho mas largos, en terminos de participantes en la cadena de produccion, para la distribucion de productos;

1

1.1. RETOS DE LAS EMPRESAS DE MANUFACTURA

mientras que internamente los procesos de fabricacion son cada vez mas complejos y especializados. Se ha

hecho necesario conducir la manufactura hacia productos mas anonimos, al crear valor agregado en el proceso

y no en el producto, donde las cadenas de suministro son mas largas y complejas [2].

La manufactura eficiente y competitiva requiere de una relacion cercana entre las distintas actividades que se

convierten en partes verdaderas de un sistema dinamico interactuante [3]. Toda empresa que quiera competir en

el mercado internacional debe ser capaz de ofrecer al cliente un valor agregado; por ejemplo, alta flexibilidad

en los procesos, tiempos de entrega cortos, amplio rango de variables manejadas, ciclos de produccion de vida

corta, entre otros. Todas las anteriores son caracterısticas que no son creadas por el producto, si no por el pro-

ceso [2].

1.1. Retos de las empresas de manufactura

Los avances tecnologicos, ası como la constante y creciente inversion en investigacion, por parte del sector in-

dustrial, se han vuelto cada vez mas necesarios debido a que la implementacion de tecnologıa avanzada en los

procesos de produccion implica alcanzar una mayor productividad y eficiencia de estos.

Desde principios de la decada de 1990 se comenzo a percibir la necesidad de las empresas de manufactura por

flexibilizar sus procesos con el fin de seguir vigentes dentro de un mercado cada vez mas dinamico. Adlemo

et al. [4] plantean un esquema de modelado que, si bien puede considerarse un metamodelo general, es uno

de los primeros trabajos que propone el uso de la semantica del lenguaje Orientado a Objetos, proponiendo la

descomposicion de un sistema de manufactura en objetos, jerarquizar esos objetos y asociarlos a traves de un

intercambio de mensajes entre estos.

Tambien debido a la constante presion que las empresas de manufactura sufren para volver sus procesos mas es-

beltos, transparentes y agiles, W. A. Estrem [5] identifica seis retos constantes para las empresas de manufactura:

Lograr concurrencia en todas las operaciones.

Integracion de los recursos humanos y tecnicos para mejorar el rendimiento de la fuerza de trabajo satis-

faciendo las necesidades del proceso.

La transformacion instantanea de los datos obtenidos, desde un gran numero de fuentes, a informacion

util para la toma de decisiones.

Reducir los desperdicios de la produccion, ası como una tendencia hacia un impacto ambiental nulo.

2

CAPITULO 1. MARCO DE REFERENCIA

Reconfigurar los procesos de manufactura rapidamente en respuesta a cambios en las necesidades del

cliente o en busca de nuevas oportunidades.

Desarrollar procesos de manufactura innovadores y productos con un enfoque a la miniaturizacion.

Los retos mencionados estan directamente relacionados con la integracion de tecnologıas de informacion y co-

municacion (TIC’s) y metodologıas de diseno e implementacion a los procesos de produccion en la industria

manufacturera. El diseno de sistemas de produccion ya no puede llevarse a cabo de forma tradicional, esto es:

el desarrollo del software de control comienza cuando el desarrollo de los sistemas electronico y mecanico, que

tambien fueron desarrollados de forma independiente, ya se encuentran en una etapa donde los cambios son

caros y requieren demasiado tiempo [6].

En trabajos mas recientes comienza a aplicarse el enfoque Orientado a Objetos para analizar los sistemas de

manufactura, tal es el caso de E. Carpanzano [7] y Marcos W. [8], que describen una forma de visualizar los sis-

temas complejos, y que puede sintetizarse: La arquitectura del sistema de automatizacion de una empresa puede

modelarse como una coleccion de dispositivos divididos en recursos interconectados a traves de las redes de

comunicacion, mientras las funciones realizadas por dicho sistema son modeladas como aplicaciones. Ademas,

se proponen soluciones en automatizacion para fabricas adaptables, promoviendo una metodologıa para diseno

de sistemas comenzando por la definicion del sistema y sus requerimientos. El trabajo de E. Carpanzano [7]

concluye con el desarrollo de un algoritmo para autoadaptar el sistema de manufactura a las necesidades del

producto.

Para lograr reaccionar ante la competencia y a los rapidos cambios en la demanda del cliente, las organizaciones

han desarrollado un profundo interes por los procesos y la automatizacion flexibles [9–11]. Otro aspecto que

ha tomado gran importancia dentro de los procesos de produccion es el uso de bases de datos para almacenar

datos de produccion, procesarlos y mostrarlos de la manera mas pertinente a los diferentes involucrados en el

proceso [12, 13].

Lo mencionado supone la interaccion de muchas areas de conocimiento, integradas en un mismo sistema, lo

que se traduce en muchas personas con diferentes formaciones academicas trabajando paralelamente e interac-

tuando unos con otros. Si ademas se suman las diferencias culturales o de lenguaje, cada vez mas comunes en

las empresas internacionales, el desarrollo del sistema puede volverse un obstaculo a vencer antes de pensar en

llevar a cabo el desarrollo de algun sistema de manufactura. Es un hecho que el diseno de sistemas depende

tambien en gran medida de la comunicacion entre quien plantea los requerimientos funcionales del sistema y la

interpretacion que el equipo de diseno haga de esos requerimientos para lograr que el producto cumpla con las

especificaciones funcionales.

3

1.2. EL ENFOQUE OO EN EL MODELADO DE SISTEMAS DE MANUFACTURA

La necesidad de cubrir ciertos huecos en la metodologıa de diseno de sistemas ha llevado a la concepcion

de un termino abstracto para modelar los componentes industriales llamado Componente Mecatronico [6, 14],

compuesto por partes mecanica, electronica y de software. Por consecuencia, un sistema mecatronico se define

como una agregacion o interconexion de componentes mecatronicos. K.Thramboulidis [6] comenta ademas los

retos encontrados en empresas que siguen un proceso de desarrollo basado en componentes:

El numero de los componentes en una companıa real puede presentar crecimiento exponencial.

El esfuerzo para encontrar el componente correcto puede llegar a ser significativo.

La necesidad por modificar un componente puede viciar los beneficios de tener componentes ya compro-

bados.

La dificultad de integrar los componentes disponibles.

Pueden existir varias alternativas de diseno para un componente.

1.2. El enfoque OO en el modelado de sistemas de manufactura

El entorno de programacion orientado a objetos (POO) fue concebido aproximadamente hace tres decadas, re-

volucionando no solamente el lenguaje usado para programar computadoras, mas bien se convirtio en una nueva

forma de pensar acerca del proceso de descomposicion de problemas y de desarrollo de soluciones de progra-

macion. El enfoque orientado a objetos considera a un programa como una coleccion de agentes ampliamente

autonomos, llamados objetos. Cada objeto es responsable de tareas especıficas. Es mediante la interaccion de

los objetos, usando el intercambio de mensajes, que avanza el computo. Por lo tanto, en cierto sentido la pro-

gramacion orientada a objetos puede considerarse la simulacion de un universo modelo [15].

1.2.1. El enfoque OO

Un objeto es una encapsulacion del estado y del comportamiento, por lo que se le puede considerar como un

modulo o un tipo de datos abstracto. El comportamiento de un objeto queda determinado por su clase. Cada

objeto es un ejemplar de alguna clase y todos los ejemplares de la misma clase se comportaran de una forma

similar como respuesta a una solicitud similar.

El comportamiento del objeto se conoce mediante la invocacion a un metodo como respuesta a un mensaje. La

interpretacion de un mensaje es decision del objeto y puede diferir de una clase de objetos a otra. Los objetos y

las clases amplıan el concepto de tipos de datos abstractos al anadir el concepto de herencia. Las clases pueden

organizarse en un arbol de herencia jerarquico, donde las clases que se encuentran en niveles mas bajos en el

4


arbol tienen acceso y pueden usar datos y comportamiento asociados con las clases mas altas del arbol.

Al reducir la interdependencia entre los componentes de software, el enfoque orientado a objetos permite el

desarrollo de sistemas de software reutilizable. Tales unidades pueden crearse y probarse como unidades inde-

pendientes, aislados de otras partes de una aplicacion de software.

Los componentes reutilizables permiten al disenador lidiar con los problemas en un nivel mas alto de abstrac-

cion [16]. Se pueden definir y manipular objetos simplemente en terminos de los mensajes que los componentes

entienden y de una descripcion de las tareas que ellos realizan, pasando por alto los detalles de la implantacion.

Los metodos orientados a objetos han permitido a los programadores construir complejos sistemas de software

en periodos de tiempo cortos, y al mismo tiempo asegurar una gran facilidad de mantenimento. Desde la decada

de 1990, investigadores comenzaron a plantear el uso de lenguaje Orientado a Objetos para modelar sistemas

de manufactura, como D. Pratt [17] quien propone la descomposicion de sistemas de manufactura en:

Objetos fısicos.

Objetos de informacion.

Objetos de control/decision.

Despues de aproximadamente una decada de desarrollo, las tecnicas orientadas a objetos fueron estandarizadas

con la publicacion del Lenguaje Unificado de Modelado, (UML, por sus siglas en ingles) [18, 19], poniendo

dentro de un mismo marco coherente todas las construcciones adoptadas por la comunidad OO. Desde su intro-

duccion, UML ha sido empleado para desarrollar y documentar codigo con gran exito y, gracias a la extension

de sus capacidades, se ha podido ampliar su alcance original hasta lograr actualmente el desarrollo de software

en tiempo real.

Con la finalidad de poder aprovechar la funcionalidad y versatilidad que brinda UML se crearon diferentes

plataformas CASE (Computer-Aided System Engineering), que ademas cuentan con diversas herramientas para

el diseno, representacion y hasta simulacion [20] de sistemas de software. Dentro de estas se encuentra toda la

semantica necesaria para el modelado, la posibilidad de desarrollar todos los diagramas necesarios para descri-

bir y simular complejos sistemas de software.

Los sistemas de manufactura se han vuelto cada vez mas complejos, por lo que se ha tornado un campo fertil

para los investigadores buscando nuevas soluciones de diseno para enfrentar esta creciente complejidad. El mo-

delado de sistemas de manufactura y su software de programacion encontro inconvenientes como los citados

por S. Adiga [21], ya que la abstraccion a traves de las subrutinas solamente son eficientes para la descripcion

5

1.2. EL ENFOQUE OO EN EL MODELADO DE SISTEMAS DE MANUFACTURA

de eventos (operaciones), pero no ası para la descripcion de objetos abstractos.

Gracias a que el enfoque OO es una forma mucho mas natural de representar sistemas, permite que personas

no expertas en programacion pero muy familiarizadas con el proceso de produccion puedan hacer un mejor tra-

bajo modificando o manteniendo software del proceso industrial. Uno de los obstaculos clasicos para modelar

sistemas de manufactura usando un enfoque estructurado, es la necesidad de incorporar multiples niveles de

abstraccion, debido al hecho de que el personal en diferentes niveles, hablando de la jerarquıa organizacional

en la empresa, tienden a ver datos con diferentes niveles de abstraccion [21].

Con el paso del tiempo las tecnicas para el modelado de sistemas de manufactura fueron refinandose, al grado

de que algunos investigadores han propuesto metodologıas de diseno [8, 10, 22–26], ası como el uso de herra-

mientas CASE como plataforma de desarrollo [8], difiriendo entre estas el uso de algunas herramientas como

las Redes de Petri y cartas de estado, o las capas de abstraccion.

Por su puesto, el enfoque Orientado a Objetos tambien sufre de algunas desventajas, encontramos que para

poder aprovechar la reusabilidad, primero se tiene que contar con una librerıa bastante extensa de objetos, esto

provoca la necesidad de contar con una buena documentacion desde el inicio en el proceso de desarrollo hasta

sus posteriores revisiones o modificaciones.

1.2.2. Estado del arte del enfoque orientado a objetos en el desarrollo de sistemas de

manufactura

En el pasado, la reutilizacion de modulos era una meta muy buscada y pocas veces alcanzada. Una razon im-

portante para ello es la estrecha interconexion de los componentes de un sistema que se crearon en una forma

convencional. Es difıcil extraer elementos de un sistema que puedan usarse facilmente en otro no relacionado,

porque tıpicamente cada parte de un sistema de manufactura tiene interdependencias con otras partes del mismo.

Como lo menciona L. Bassi [27], el reto principal en las aplicaciones de la industria moderna es lidiar con la

inmensa cantidad de datos involucrados en el proceso de diseno. Durante el diseno de sistemas con una estrecha

integracion entre mecanica, electronica y procesamiento de informacion, tiene lugar la ingenierıa simultanea,

llamada ası por el diseno usando una plataforma donde coincidan distintas disciplinas trabajando en paralelo.

Un sistema de manufactura complejo puede resultar muy amplio para tratarse mediante las metodologıas de

diseno conocidas o, peor aun, sin metodologıa. Estas consideraciones sugieren que adaptando tecnicas orienta-

das a objetos a los sistemas de ingenierıa podrıa conducir a mejoras con respecto a costos de diseno y tiempo,

mantenimiento y confiabilidad como ha sucedido con los sistemas de software. Un argumento a favor de esta

6


Figura 1.1: Modelo V del proceso de diseno

hipotesis es que observando el modelo matematico de sistemas fısicos es posible reinterpretar su dinamica como

el resultado del intercambio de energıa de muchos subsistemas elementales a traves de interconexiones, donde

cada uno se caracteriza por una propiedad energetica, lograndose ası la descripcion de un sistema complejo

como una coleccion de modelos donde cada uno contiene la descripcion de una parte del sistema.

La Figura 1.1 muestra el metodo de desarrollo mencionado por L. Bassi [27] para el diseno y modelado de una

empacadora Tetra Pak R©. En esta figura se muestra el proceso de diseno comunmente referido como el modelo

en V del proceso de diseno, donde se parte de los requerimientos para definir el problema hasta deducir los

requerimientos de los componentes. Una vez definidos los componentes, comienza la etapa de integracion y

validacion del sistema. En este caso, la herramienta usada es una plataforma de codigo abierto llamada SysML

(Systems Modeling Languaje), basada en UML.

En el uso de UML han surgido algunos trabajos describiendo la metodologıa para analizar sistemas de manufactura

y su software de control, en estos trabajos son pioneros los investigadores italianos M. Bonfe, C. Secchi y C.

Fantuzzi con una variedad de aportaciones desde el analisis de software de control [28–32], modelado de siste-

mas fısicos [33], y el modelado de la entidad hıbrida que ellos llamaron componente mecatronico [14, 34–36].

Otro investigador que ha propuesto modelado con lenguaje Orientado a Objetos, UML y Bloques de Funciones

para modelar sistemas de manufactura es K. Thramboulidis [37–42]. Es importante mencionar que este autor

es uno de los precursores del nuevo estandar de automatizacion industrial IEC 61499, basada en el desarrollo

de bloques de funcion para automatizacion de procesos [43]. El concepto de bloques de funcion esta basado en

el enfoque Orientado a Objetos ya que representan objetos con atributos y operaciones que se comunican entre

sı por medio del intercambio de mensajes.

7

1.3. PLANTEAMIENTO DEL PROBLEMA

Como esfuerzos en estos campos de investigacion, ya se han llevado a cabo trabajos de modelado y diseno de

sistemas usando UML; M.Bonfe et al. en [31] y [14] muestran el diseno y la verificacion del modelado del

sistema de control y del mecanismo respectivamente en una maquina empaquetadora, usando un software es-

pecializado llamado SMV Symbolic Model Verifying, que simula sistemas de estados finitos, tambien llamados

estructuras Kripke. En trabajos posteriores, estos mismos autores discuten diferentes metodologıas para el mo-

delado de sistemas de manufactura [27,44], junto a estos ultimos, D. Witsch [45] tambien propone herramientas

para traducir los diagramas UML a codigo para PLC [36, 46]. K. Thramboulidis tambien presenta trabajos de

aplicacion de metodologıa de analisis y desarrollo de sistemas en aplicaciones industriales reales [42, 47]. En

otros trabajos se describe el uso de UML para el modelado de sistemas reales: C. Basnet [48] describe una de las

primeras aplicaciones del Lenguaje Orientado a Objetos en una lınea industrial de empaquetado; H. Gomaa [26]

modela el sistema de control de crucero para automoviles; S. Burmester [49,50] presenta la aplicacion de UML

en un sistema de trenes que pueda enganchar y desenganchar los vagones automaticamente; D. Witsch [51]

desarrolla un modelo hıbrido entre bloques de funcion con el protocolo IEC 61131-3 y UML.

Lo anterior constituye el marco de referencia de la presente investigacion, dando a conocer trabajos similares y

el estado del arte sobre el tema. Tambien se busca dar a conocer las necesidades de las empresas de manufactura

y las consecuentes oportunidades para desarrollar sistemas que cumplan con los actuales requerimientos de

las industrias. A continuacion se presenta la descripcion del problema propuesto, la hipotesis de trabajo y los

objetivos de este trabajo de investigacion.

1.3. Planteamiento del problema

Las siguientes lıneas tienen el objetivo de describir y definir los terminos del problema que a lo largo de este

trabajo se busco solucionar.

1.3.1. Definicion del problema

En la actualidad, la practica comun en la industria de manufactura aun sufre por la falta de metodologıas de

ingenierıa adecuadas para el diseno de los procesos, puesto que este requiere la participacion de diferentes com-

petecias tecnologicas, por ejemplo: ingenierıa mecanica, ingenierıa electronica, teorıa de sistemas y ciencias

de la computacion; ademas el control del sistema generalmente esta compuesto por partes de control continuo

(control de movimiento) y parte de control logico (secuencia del proceso y manejo de alarmas).

El enfoque Orientado a Objetos ha probado ser una poderosa tecnica para modelar, analizar y disenar sistemas

complejos, ya que se caracteriza por ser reusable, modificable y extendible y se ha comenzado a usar en el mo-

delado de sistemas industriales de gran complejidad que puedan adaptarse facilmente a cambios significativos

en las especificaciones del sistema [9].

8


Este trabajo reporta el desarrollo de un sistema piloto de manufactura para el sector alimenticio. El sistema debe

ser flexible y aportar la informacion necesaria del proceso y el producto, ya que el objetivo es usarlo para el

desarrollo de nuevos productos y en la mejora de procesos de produccion. El desarrollo del sistema parte de los

requerimientos funcionales por parte del usuario, seguido por la determinacion de los requerimientos tecnicos,

el modelado y la documentacion del sistema.

1.4. Hipotesis

Usando la metodologıa y semantica de la programacion Orientada a Objetos, particularmente UML, pueden

disenarse sistemas de manufactura.

1.5. Objetivos

1.5.1. Objetivo general

Analizar, disenar y modelar un sistema de manufactura usando el Lenguaje Unificado de Modelado, a partir de

los requerimientos funcionales determinados por el usuario del sistema.

1.5.2. Objetivos especıficos

1. Establecer los fundamentos teoricos necesarios para llevar a cabo el diseno de una lınea de manufactura.

2. Analizar los requerimientos funcionales propios de la lınea piloto de manufactura.

3. Modelar el sistema de manufactura en base a los casos de uso y las clases del sistema.

4. Disenar el sistema siguiendo los lineamientos propuestos en la documentacion del mismo.

9

1.5. OBJETIVOS

10

CAPITULO SEGUNDO

MARCO TEORICO

2.1. Los sistemas de manufactura

El concepto de sistema ha invadido todos los campos de la ciencia y penetrado en el pensamiento y el habla

populares debido principalmente al uso de medios masivos de comunicacion. El razonamiento en terminos de

sistemas desempena un papel dominante en diferentes campos, desde las empresas industriales y la carrera ar-

mamentista, hasta temas de ciencia pura [58]. Desde hace un par de decadas han entrado en auge profesiones

dedicadas al analisis de sistemas, ingenierıa de sistemas, proyecto de sistemas, entre otras.

Al manejar un conjunto de elementos, L. Bertalanffy [58] distingue tres tipos de acuerdo con:

1. Su numero.

2. Sus especımenes.

3. Las relaciones entre elementos.

La Figura 2.1 ilustra lo mencionado anteriormente, donde a y b simbolizan varios complejos.

Figura 2.1: Distincion entre las formas de estudiar un sistema, donde a y b simbolizan los complejos

11

2.1. LOS SISTEMAS DE MANUFACTURA

En los dos primeros casos, el complejo puede ser comprendido como una suma de elementos considerados ais-

ladamente. En el caso 3, no solo hay que conocer los elementos, sino tambien las relaciones entre ellos. Las

caracterısticas del primer tipo pueden llamarse sumativas, y las del segundo, constitutivas. Las caracterısticas

sumativas de un elemento son las mismas dentro y fuera del complejo; por lo tanto, las caracterısticas del com-

plejo se obtienen por suma de caracterısticas y comportamiento de elementos, tal como son conocidos aislados.

Las caracterısticas constitutivas son las que dependen de las relaciones especıficas que se dan dentro del com-

plejo; por lo tanto, para entender esas caracterısticas se deben conocer no solo las partes aisladas, sino tambien

las relaciones entre estas.

Dicho lo anterior, puede transladarse el concepto de la tecnologıa a un estudio formal de sistemas. Por un lado

se encuentra el transito de la ingenierıa electrica, con el manejo de grandes cantidades de electricidad, hasta la

ingenierıa de control, que dirige procesos mediante dispositivos de bajo consumo energetico y que ha condu-

cido a las computadoras y la automatizacion. La tecnologıa ha progresado con un enfoque, no en terminos de

maquinas sueltas, sino de sistemas. En la actualidad desde un telefono celular o un automovil, hasta proyec-

tiles y vehıculos espaciales, son ensamblados usando componentes procedentes de tecnologıas heterogeneas:

mecanica, electronica, quımica, y muchas mas; comienzan a intervenir relaciones entre hombre y maquina, y se

comienzan a encontrar diversos problemas financieros, economicos, sociales y polıticos citando ejemplos como

la contaminacion por el uso de hidrocarburos, el debate sobre el uso de la energıa nuclear hasta la compleja

comparacion entre la mente humana y la inteligencia artificial [58].

2.1.1. Definicion de sistema

En el contexto del presente trabajo, un sistema se define como el conjunto de elementos dinamicamente rela-

cionados entre sı, que realizan una actividad para alcanzar un objetivo, operando sobre entradas y proveyendo

salidas procesadas. Se encuentra en un medio ambiente y constituye una totalidad diferente de otra ya que se

definen los lımite de cada sistema [58].

Las partes constitutivas de un sistema son los elementos, los cuales se definen como la parte integrante de una

cosa o porcion de un todo. De los elementos de un sistema puede decirse que:

1. Tienen caracterısticas particulares que afectan o se ven expresadas en las caracterısticas del sistema total.

A su vez, las caracterısticas del sistema afectan o influyen en las caracterısticas de los elementos.

2. Depende del analista del sistema determinar con que detalle y que elementos considerar al momento de

evaluar un sistema.

12

CAPITULO 2. MARCO TEORICO

2.1.2. Conceptos sobre sistemas

Se define como Relacion a la situacion que se da entre dos cosas, ideas o hechos cuando por alguna circunstan-

cia estan unidas de manera real tangible o intangible. Tambien se le conoce a la relacion como: union, conexion,

interaccion o enlace. Es importante mencionar que la mayorıa de las veces la influencia mutua entre las relacio-

nes es mas importante que la cantidad de partes o el tamano de las mismas.

O. Johansen [59] identifica, a partir de las relaciones entre los elementos de un sistema, propiedades que la

totalidad no tendrıa de no existir tales relaciones, como:

Estabilidad: esta depende de la cantidad, tamano y diversidad de subsistemas que abarquen el sistema y

el tipo y grado de conectividad que exista entre ellos.

Efecto de palanca: corresponde a la posibilidad de cambiar repentinamente un sistema si se emprenden las

acciones apropiadas. El cambio que se necesita o requiere resulta sorprendentemente facil si se identifican

las conexiones apropiadas. El efecto de la palanca se logra al saber donde intervenir para obtener un gran

resultado con un pequeno esfuerzo, en lugar de malgastar energıa. El efecto de palanca se logra porque

hay algunas partes y relaciones que son mas importantes que otras y ejercen un mayor grado de control

en el sistema.

Efecto secundario: consecuencia no esperada de la conectividad de las piezas de un sistema.

La estructura de un sistema es un componente que es permanente o cambia lenta u ocasionalmente. A conti-

nuacion se analizan diferentes tipos de estructuras que pueden poseer en los sistemas. Es posible encontrarlas

combinadas en la medida que el sistema sea mas complejo:

Lineal: los elementos se encuentran uno despues del otro.

Circular: los elementos se encuentran un despues del otro, pero no existe un principio o fin de la secuencia.

Centralizada: los elementos se encuentran unidos a uno que se denomina el central.

Matricial: los elementos se disponen en filas o columnas, se asocia a la idea de tener varias estructuras

lineales unidas.

Jerarquica: los elementos mantienen una relacion de dependencia entre ellos, hay elementos en niveles

superiores y elementos en niveles inferiores.

Descentralizada: a diferencia de las estructuras anteriores, no existen secuencias, elementos centrales o

dependencias entre los elementos.

Los objetivos determinan el funcionamiento del sistema, para lograrlos deben tenerse en cuenta los elementos,

las relaciones como los insumos y lo producido por el mismo. de manera que esten coordinados y el sistema

13


tenga validez y significado.

La entrada de un sistema es todo aquello que el sistema recibe o importa de su ambiente exterior. Visto el siste-

ma como un subsistema de otro mayor que lo contiene, las entradas pueden ser consideradas como las relaciones

externas de ese sistema con otro. El sistema recibe entradas para operar sobre ellas, procesarlas y transformarlas

en salidas.

Existen varios tipos de entradas a los sistemas:

Energıa: Se utiliza para mover y dinamizar el sistema.

Materia: Son los recursos que el sistema utiliza para producir salidas, que a su vez pueden ser:

• Recursos operacionales: Utilizados para transformar otros recursos (maquinas, equipos, instalacio-

nes, herramientas, utensilios, etc.)

• Recursos productivos: Materias primas

• Informacion: Es todo aquello que reduce la incertidumbre sobre una situacion, proporciona orien-

tacion, instruccion y conocimiento con respecto a algo, permite programar y planear el comporta-

miento o funcionamiento del sistema.

O. Johansen [59] diferencıa dos tipos de entrada de acuerdo con el comportamiento que ellas tienen en el

sistema:

1. Ley de la conservacion de la materia y la energıa: la cantidad de materia y energıa que permanece en un

sistema es igual a la suma de al materia y la energıa importada, menos la suma de la energıa exportada.

2. Ley de los incrementos de la informacion: la cantidad de informacion que permanece en el sistema no

es igual a la diferencia entre lla entrada y la salida, si no que es igual a la informacion que existe mas

la que entre, es decir, hay una agregacion neta en la entrada, y la salida no elimina informacion del sistema.

La salida es el resultado final de la operacion o procesamiento de un sistema. Los flujos de salida permiten al

sistema exportar el resultado de sus operaciones al medio ambiente.

Segun O. Johansen [59], las salidas se pueden clasificar como positivas o negativas para el medio, la relacion

que existe entre estas determina la supervivencia del sistema. Las caracterısticas de un sistema viable son:

Capacidad de autoorganizacion: Mantener una estructura permanente y modificarla de acuerdo con las

circunstancias.

Capacidad de autocontrol: Mantener sus principales variables dentro de ciertos lımites.

14


Cierto grado de autonomıa: Poseer suficiente nivel de libertad determinado por sus recursos para mante-

ner las variables dentro del area de normalidad.

El Ambiente es el medio que rodea externamente al sistema, es una fuente de recursos y amenazas. Se conoce

tambien con el nombre de Entorno o Contexto. El sistema y el ambiente mantienen una interaccion constante,

estan interrelacionadas y son interdependientes. La influencia que el sistema ejerce sobre el medio ambiente

regresa a el a traves de la retroalimentacion, el ambiente condiciona al sistema y determina su funcionamiento.

La totalidad se define como el conjunto de todos los componentes. El objetivo de aplicar este concepto al siste-

ma tiene que ver con la evaluacion al unısono de todos los aspectos relacionados con el mismo. El sistema debe

considerarse como una cosa ıntegra, completa, entera, absoluta y conjunta. Debido a la naturaleza organica de

los sistemas, una accion que produzca un cambio en una de las unidades el sistema podrıa generar cambios en

los demas; el efecto total se presenta como un ajuste de todo el sistema reaccionando globalmente.

La sinergıa existe en un sistema cuando la suma de las partes del mismo es mas que el todo todo, es decir,

cuando el estudio de una de las partes del sistema de manera aislada no puede explicar o predecir la conducta

de la totalidad. Se le conoce tambien como la propiedad por la cual la capacidad de actuacion de un sistema es

superior a la de sus componentes sumados individualmente.

Johansen [59] atribuye la existencia de la sinergıa a la presencia de relaciones e interacciones entre las partes,

lo que se denomina relaciones causales. Estas representan una relacion causa-efecto entre los elementos de un

sistema, la relacion causal positiva indica que un cambio producido en un elemento genera una influencia en el

mismo sentido en los otros elementos con los cuales esta conectado; la negativa muestra el cambio que se da en

sentido contrario.

La entropıa es un proceso mediante el cual un sistema tiende a consumirse, desorganizarse y morir. Se basa en

la segunda ley de la termodinamica, que plantea que la perdida de energıa en los sistemas aislados los lleva a la

degradacion, degeneracion, desintegracion y desaparicion.

Para la teorıa general de sistemas, la entropıa se debe a la perdida de informacion del sistema que provoca la

ausencia de integracion y comunicacion de las partes del sistema.

La retroalimentacion es un mecanismo mediante el cual la informacion sobre la salida del sistema se vuelve a

este convertida en una de sus entradas. Esto se logra a traves de un mecanismo de comunicacion de retorno que

tiene como fin alterar de alguna manera el comportamiento del sistema.

La retroalimentacion sirve para establecer una comparacion entre la forma real de funcionamiento del sistema y

15


el parametro ideal establecido. Si hay alguna diferencia o desviacion, el proceso de retroalimentacion se encarga

de regular o modificar las entradas para que la salida se acerque al valor definido.

La homeostasis es la capacidad de los sistemas de mantener sus variables dentro de ciertos lımites frente a los

estımulos cambiantes externos que ejerce sobre ellos el medio ambiente y que lo forzan a adoptar valores fuera

de los lımites de la normalidad. Es la tendencia de un sistema a mantener un equilibrio interno y dinamico

mediante la autorregulacion o el autocontrol.

2.1.3. La manufactura como un sistema

Ası mismo, centrando la teorıa de sistemas a los sistemas de manufactura se pueden citar diferentes definiciones,

Jingshan Li [60] propone:

La manufactura es el proceso de transformar materia prima en un producto util. Todo lo que se hace en o por

las operaciones de piso de una fabrica es vista como manufactura.

De la misma forma, Chryssolouris [1] define al sistema de manufactura como: una combinacion de humanos,

maquinaria y equipo que se encuentran limitados por un flujo comun de material e informacion.

Un sistema o modelo contiene conocimiento condensado de un fenomeno fısico. La razon de obtener un modelo

es que, basado en la informacion que recibe una unidad de procesamiento proveniente de las mediciones, puede

planearse una estrategia de control. Los sistemas dinamicos se comportan de tal manera que el resultado de la

manipulacion de las entradas no puede verse inmediatamente.

Existen dos maneras de encontrar modelos dinamicos: comenzando desde los principios fısicos basicos, o me-

diante las mediciones. Usando el modelo teorico, ası como tambien las mediciones es posible calcular las varia-

bles internas del proceso.

Un concepto importante relacionado con la reconstruccion y estimacion en base al modelo es la observabilidad.

Esta nos muestra si el arreglo de sensores es adecuada para entregar la informacion requerida acerca del proceso.

16


Existen diferentes maneras de modelar los sistemas dinamicos, algunos de los tipo de modelado mas importantes

son:

Descripcion en tiempo continuo Este modelo se representa en terminos de ecuaciones diferenciales,

lineales y no lineales, dando una descripcion cuantitativa de masa, energıa, fuerza o momento de un

proceso fısico.

Descripcion en tiempo muestreado En este caso, la descripcion del sistema se hace por medio de ecua-

ciones en diferencias, lo que significa que la informacion esta disponible solamente en ciertos instantes

de tiempo. El muestreo es necesario cuando se usan unidades de procesamiento de informacion (algun

tipo de computadora) trabajando secuencialmente en el tiempo.

Eventos Discretos o Sistemas Secuenciales Tıpicamente, las amplitudes de las entradas y salidas del

sistema son discretas y normalmente del tipo encendido/apagado.

Sistemas con incertidumbres El sistema por sı mismo o las mediciones estan contaminadas por ruido.

En algunos casos a dicho ruido puede darsele una interpretacion estadıstica.

Los sistemas de manufactura suelen ser bastante complejos. La dificultad de disenar, modelar o analizar los

sistemas puede resumirse en los siguientes puntos:

1. Los sistemas de manufactura son grandes y tienen componentes que interactuan entre sı.

2. Son dinamicos.

3. Los sistemas de manufactura son sistemas abiertos, por lo que estos pueden influenciar y ser influenciados

por el medio.

4. Las relaciones entre el comportamiento de las mediciones y las variables crıticas normalmente no pueden

expresarse analıticamente.

5. Los datos pueden presentar dificultad para ser medidos en ambientes de produccion muy severos.

6. Usualmente existen multiples requisitos de funcionamiento para los sistemas de manufactura y esto puede

llegar a causar conflictos.

El mismo Chryssolouris [1] refiere al proceso de manufactura como un sistema cuya primera etapa es el diseno

del producto, y la entrega del producto terminado es la etapa final, como se ilustra en la Figura 2.2.

Las decisiones correspondientes al diseno y operacion de un sistema de manufactura requieren un alto grado

de conocimiento tecnico, ası como la vision para satisfacer ciertos objetivos de negocios. En general, puede

hablarse de cuatro atributos de la manufactura a tomarse en cuenta cuando se trata de tomar decisiones acerca

17


Diseño del producto (para producción)

Planeación de la producción

Control de la producción

(Realimentación, Supervisión Op<mización)

Equipo para producción (Maquinaria)

Proceso de producción

Requisitos del producto

Trabajo creativo

Producto Terminado

Comportamiento

Costos y Capacidades

Figura 2.2: Esquema del Sistema de Manufactura

del diseno del proceso, estos son: costo, tiempo, calidad y flexibilidad.

Al momento de disenar un proceso de manufactura debe buscarse un equilibrio entre los cuatro atributos antes

mencionados. A continuacion se explica brevemente en que consiste cada uno de ellos:

Costo. Los costos dentro de la manufactura son causa de diversos factores que a grandes rasgos entran en

las siguientes categorıas:

• Costos de equipo e instalaciones

• Materiales

• Manejo de la Informacion

• Mano de Obra

• Energıa

• Mantenimiento y Capacitacion

• Gastos Generales

• Costo de Capital

Es importante mencionar que los costos relacionados con los materiales incluyen la materia prima ası co-

mo los materiales auxiliares utilizados dentro de los procesos. El costo del manejo de la informacion es

un concepto relativamente nuevo, como lo menciona W. A. Estrem [5]. Los gastos derivados del man-

tenimiento de la red de informacion interna, ası como la constante actualizacion llegan a ser bastante

significativos e importantes para la empresa.

Tiempo. El tiempo se mide en base a:

18


• Que tan rapido un sistema de manufactura puede responder a cambios en el diseno, volumen de la

demanda, etc

• Que tan rapido el sistema puede terminar un producto.

Flexibilidad. Este aspecto se ha vuelto recientemente importante al irse reemplazando la produccion

en masa, por los nichos de mercado. Actualmente la meta de las empresas de manufactura es tener la

capacidad de fabricacion de muy diversos productos a peticion del cliente. La flexibilidad y la variabilidad

son claves para cumplir con los retos impuestos en el mercado global. A traves del tiempo, las empresas

han comprendido que el primer objetivo para poder definir una cambio es definir las acciones necesarias

oportunamente. Un aspecto principal es el de definir los objetos que tienen que ser variables ası como

su nivel de variabilidad [61]. El impulso para cambiar proviene de agentes como la volatilidad en la

demanda, medida en las fluctuaciones del volumen a traves del tiempo.

Calidad. La calidad de un producto puede explicar en gran manera la satisfaccion del cliente, aunque es

bastante difıcil expresar esta en terminos cuantitativos.

De manera general, los sistemas de manufactura pueden dividirse en dos areas:

1. El area en la cual los materiales son procesados y las partes o componentes son hechos, tambien conocida

como el area de procesamiento.

2. El area en la cual, si es necesario, las partes individuales o componentes son ensamblados ya sea un

subproducto o ya un el producto terminado.

En el entorno industrial, en la practica se manejan usualmente 5 enfoques en la estructuracion del area de pro-

cesamiento: el taller de trabajo, el taller de proyectos, sistema celular, lınea de flujo y sistema continuo.

En el taller de trabajo, cuyo esquema puede verse en la figura 2.3, la maquinaria con las mismas o similares

capacidades de procesamiento son agrupados. La maquinas normalmente son de proposito general y pueden

acomodar gran cantidad de tipos de piezas.

En un taller de proyectos la posicion del producto se mantiene fija durante la manufactura debido a su tamano o

peso. Como se observa en la figura 2.4, los materiales, las personas y la maquinaria se acomodan dependiendo

de las necesidades del producto.

En un sistema de manufactura organizado a manera de sistema celular, los equipos o maquinaria se agrupan de

acuerdo a las combinaciones que ocurren en las familias de partes manufacturadas. Como se representa en la

figura 2.5, cada celula contiene maquinaria que produce cierta familia de partes, el flujo de material entre estas

puede diferir dependiendo de las partes de una familia de piezas.

19


Figura 2.3: Esquema de un taller de trabajo

Figura 2.4: Esquema de un taller de proyectos

Figura 2.5: Esquema de un sistema celular

20


Figura 2.6: Esquema mostrando la estructura de una linea de flujo

Como cuarta opcion para la estructuracion es la creacion de una lınea de flujo (figura 2.6) en la cual las maquinas

y otros equipos se encuentran ordenados de acuerdo a la secuencia de proceso de las partes a ser manufactu-

radas. En contraste con los demas tipos de sistemas de manufactura, que llevan a cabo la produccion de partes

discretas, los sistemas continuos producen lıquidos, gases o polvos. Ejemplos de sectores que utilizan como ba-

se este esquema de manufactura son: la petroquımica y las cementeras. El sistema continuo es el menos flexible

de los sistemas de manufactura.

En los actuales sistemas de manufactura, estas estructuras estandar normalmente ocurren en combinaciones, o

con ligeras modificaciones. La eleccion de un tipo de estructura depende del diseno de las partes a ser manufac-

turadas, el tamano de lote y demas factores del mercado. De manera general, talleres de trabajo y de proyectos

son comunes para la produccion de pequenos lotes, mientras que por el otro lado, las lıneas de flujo son las mas

usadas para la produccion de grandes lotes. Los sistemas celulares son los mas apropiados cuando se requiera

la produccion de lotes de mediano tamano.

Los sistemas de manufactura pueden ser clasificados en dos grupos: continuos y discretos. Ejemplos de indus-

trias con sistemas continuos de manufactura son las industrias quımicas y de energıa, donde los procesos son

continuos en el tiempo. Las industrias con sistemas discretos de manufactura son practicamente todos las demas:

automotrices, de electronica, la industria aeroespacial y muchas otras.

21


Figura 2.7: Esquema de un sistema continuo

Entropıa y reestructuracion de factores en un sistema de manufactura

Ya se hablo de la manufactura como un sistema, por lo tanto las definiciones generales de sistema aplican

tambien para el caso de la manufactura. El principio de entropıa puede encontrarse dentro de los sistemas de

manufactura tambien. El principio sugiere que los sistemas comienzan en un estado de buen diseno pero, a

medida que se anaden subsistemas o procesos para nuevas funcionalidades, gradualmente van perdiendo su es-

tructura, deformandose de tal modo que acaban haciendose parches de manera que se mantenga funcionando el

sistema pero sin tener completa certeza de como lo esta haciendo.

Parte de este hecho se debe a la escala. Se disena un sistema pequeno que hace bien un trabajo especıfico.

Luego se pide mejorar el sistema, por lo que se vuelve mas complejo, sucediendo esto incluso cuando se lleva

el registro del diseno.

Una de las razones por las que surge la entropıa en un sistema es que cuando se anade una funcion o proceso al

sistema, se construye encima del ya existente, con frecuencia de una manera para la que no estaba disenado. En

dicha situacion, se puede redisenar el sistema existente para que maneje mejor los cambios, o se pueden adecuar

esos cambios al codigo que se anada.

Aunque es recomendable redisenar el sistema, este procedimiento por lo general cuesta mas trabajo; ya que

cualquier reestructura del sistema es susceptible a nuevas fallas y problemas. Sin embargo, si no se redisena el

sistema las adiciones seran mas complejas de lo que deberıan.

Es importante tomar en cuenta el alto costo en que se puede incurrir por la complejidad de las adiciones en

el mediano y largo plazo si se considera la importancia de la flexibilidad en los procesos de manufactura. Es

22


cuestion de tener un balance, considerando que el rediseno provoca molestias de corto plazo a cambio de una

ganancia a largo plazo, con su contraparte de la presion que existe sobre los calendarios de trabajo, la mayorıa

de las personas prefieren posponer las molestias para el futuro.

La reestructuracion de factores es un termino que describe tecnicas UML con las que se reducen las molestias

a corto plazo del rediseno. Cuando se reestructuran los factores, no cambia la funcionalidad del sistema; lo que

busca es cambiar su estructura interna, a fin de simplificar su comprension y su modificacion.

Los cambios por la reestructuracion de factores usualmente se hacen a pasos pequenos: renombrar un metodo;

mover un campo de una clase a otra; consolidar dos metodos similares en una superclase. Cada paso es pequeno;

sin embargo, algunas horas invertidas en dichos pasos pueden ayudar sobremanera al sistema.

La reestructuracion de factores puede hacerse de manera mas sencilla con el uso de los siguientes principios [62]:

No reestructurar el sistema y agregar funcionalidad al mismo tiempo; separar claramente ambas acciones

mientras se trabaja. Es posible alternarlas en tiempo y en pasos cortos.

Asegurarse de tener a la mano buenas pruebas o simulaciones antes de comenzar la reestructuracion. Eje-

cutar las iteraciones de diseno/simulacion con la mayor frecuencia posible, de modo que se sabra pronto

si los cambios han afectado el funcionamiento.

Avanzar con pasos cortos y deliberados. Es recomendable mover un campo de una clase a otra. Fusionar

dos metodos similares, creando una superclase. La reestructuracion implica con frecuencia hacer muchos

cambios localizados cuyo resultado es un cambio de mayor escala. Si los pasos son cortos y se prueban

de uno por uno, se reducira el numero de depuraciones prolongadas.

La retroalimentacion en los sistemas de manufactura

La retroalimentacion constituye un mecanismo de control del sistema. Como sistemas, toda empresa utiliza la

planeacion y el control para administrar con eficacia sus recursos. Sin embargo, el sistema ideal es aquel que se

corrige y regula por sı mismo, de manera que no es necesario tomar decisiones sobre las situaciones comunes.

Como ejemplo se puede citar un sistema de informacion computarizado para planear la produccion que toma en

cuenta la demanda actual y la proyectada y propone una solucion como salida.

23

2.2. LA INFORMACION EN LOS PROCESOS DE MANUFACTURA

2.2. La informacion en los procesos de manufactura

Todo proceso de manufactura produce dos tipos de resultados:

Resultados del tipo tangible

Resultados del tipo intangible

Del tipo tangible son todos los productos que se obtienen o esperan obtenerse al final del proceso, un producto

con ciertas caracterısticas de calidad, funcionamiento, utilidad entre muchas otras. Esta parte de los procesos

de manufactura esta muy bien estudiado y las metodologıas de diseno en esta parte tienen bastantes decadas

mejorando hasta llegar a la gran competitividad actual, donde la eficiencia en los procesos es parte esencial de

cualquier empresa.

Sin embargo, la parte del proceso intangible no ha sido objeto de estudio profundo. La parte intangible de

un proceso de manufactura es basicamente la informacion que puede extraerse de este. Las companıas actua-

les se deben de convertir en sistemas de procesamiento de informacion. Segun Kletti [2], puede asumirse que

actualmente mas de la mitad del valor agregado a los costos en el flujo de produccion se deben al factor de

informacion. Puede entenderse la informacion como una entrada al sistema de manufactura en la forma de las

necesidades del cliente sobre los productos manufacturados [1].

La informacion se puede considerar como un recurso organizacional. Como tal, se debe manejar con cuidado al

igual que los demas recursos. La disponibilidad de gran poder de computo en las organizaciones ha propiciado

una explosion de informacion y, en consecuencia, se debe prestar mayor atencion al manejo y generacion de

esta [63].

La informacion, como un recurso, ha comenzado a incrementar su importancia en distintas organizaciones. Ca-

da tarea, ya sea operativa o a nivel estrategico siempre tiene algo que ver con alacenamiento, procesamiento

o provision de informacion. Un ejecutivo puede gastar alrededor del 80 % de su tiempo en el procesamiento y

comunicacion de informacion [64].

Se debe enfrentar el hecho de que la industria ya no puede ser solamente un centro de produccion ya que esta

ha comenzado a ser reemplazada por la capacidad de servicio de ofertas en un mercado con un rango amplio en

los productos ofrecidos.

Dicho de otra forma, la empresa debe de ser capaz de adaptarse a las necesidades de los clientes, cada uno

con muy diversas necesidades y caracterısticas deseadas. El tiempo en que la produccion consistıa en grandes

lotes de producto esta desapareciendo, dando paso a la produccion dirigida a pequenos nichos de clientes que

24


buscan productos con un valor agregado significativo. Todo lo anterior se consigue mediante el correcto uso de

la informacion generada durante la produccion.

Caracterısticas como el consumo de energıa por producto, la fecha y la hora de produccion, el numero de parte,

la cantidad de partes producidas en un momento, el operador y muchas mas variables intangibles del proce-

so se pierden y se hace imposible poder usarlas para hacer mas eficiente el proceso y generar informacion de

importancia para la toma de decisiones. Informacion como el nivel de conformidad del cliente en cuanto a la

calidad, servicio, gama de productos ofrecidos, entre otra, es imposible de obtener con el concepto tradicional

de produccion y poderlo llevar a un nivel medible hacia el valor del producto.

El valor agregado de un producto proviene principalmente del procesamiento de la informacion y de la habilidad

de tener la informacion disponible en el momento justo, en la cantidad correcta y en el lugar preciso [2].

Una companıa que busque incrementar su productividad debe de incrementar su inversion en el sistema de ge-

neracion y procesamiento de informacion. Sin embargo, no significa que el simple hecho de obtener hardware

y software para dicha tarea se traduzca en beneficios en la productividad, flexibilidad o la transparencia. Un

uso no sistematico o metodologicamente incorrecto de un hardware/software de generacion y procesamiento de

informacion tendera a causar mas desventajas que los beneficios buscados.

Las companıas que buscan crear un valor agregado a sus procesos comienzan por generar informacion que por

un lado documenta el estado de la generacion de dicho valor y por otro lado describe el rendimiento que aun

debe de alcanzar el sistema. La informacion es, entonces, el verdadero motor de los procesos y de esta manera

controla las operaciones secuenciales de la companıa. Los cambios decisivos dentro de una companıa en el fu-

turo no seran solamente en el campo de la tecnologıa utilizada, sino tambien en generacion, definicion y control

de la informacion de los procesos.

En la actualidad se ha comenzado a ver claramente que la produccion por sı misma sufre frecuentemente en

deficiencias en procesamiento de informacion y la creacion de redes internas de informacion. El principal mo-

tivo de la creciente complejidad de los niveles en la produccion se debe principalmente en la gran variedad de

productos e implementaciones especıficas al producto por parte del cliente.

Es muy comun encontrar aun gran numero de companıas que usan un sistema de intercambio de informacion

basado en papel u hojas de calculo. La recoleccion de datos en papel acerca de los distintos aspectos de la

produccion en proceso es un anacronismo. Esta forma de trabajar es extremadamente ineficiente ası como una

fuente de errores e inexactitudes.

25


Cuando se toca el tema de procesamiento de informacion dentro de los sistemas de manufactura, lo que viene

a la mente en primera instancia es algun programa corriendo dentro un hardware clasico como los ordenadores

centrales, servidores y PC’s. Sin embargo en paralelo a esta tecnologıa se encuentra el mundo de la tecnologıa

de automatizacion y software orientado a la maquinaria. La tecnologıa de automatizacion usada actualmente se

convierte normalmente en un sistema de procesamiento de informacion bastante complejo.

Desde el punto de vista de una empresa altamente eficiente, el hecho de que la generacion y el procesamiento

de informacion se desarrollen independientemente de la automatizacion de procesos se ha convertido en una

barrera importante de derribar.

Existe una sutil diferencia entre los conceptos de datos e informacion, se tendra que definir por lo tanto cada

uno de los conceptos:

Un dato es todo conjunto de caracteres que describa algo sobre nuestra realidad [65]. Puede ser la direccion de

un proveedor, el precio de compra de un elemento, los detalles del diseno de un producto o el contenido de un

almacen.

Para poder definir informacion tiene que usarse el conjunto de datos definidos anteriormente ya que un dato

puede converse en informacion si se dan ciertas circunstancias. Por ejemplo, en cuanto a la direccion de un

proveedor sigue siendo un dato, pero para una persona que tiene que enviar un correo de reclamacion, la direc-

cion se convierte en informacion. Ası mismo, el contenido de un almacen es un dato, pero llega a convertire en

informacion cuando se pretende saber si puede llegar a cumplirse con el pedido urgente de un cliente. Es posible

decir que la informacion existe o no dependiendo de si se utiliza para tomar una decision.

La informacion es la parte de los datos que influye o no en nuestras acciones, dependiendo de la ausencia o

disponibilidad de esta. La diferencia entre dato e informacion reside en la relacion con la decision requerida,

por lo tanto, si no se sabe con anticipacion que tipo de decision se debe de tomar, no se sabra que tipo de dato se

necesitara exactamente, por lo que todo dato podrıa convertirse en informacion en algun momento. En realidad,

no es un asunto tan trivial el hecho de distinguir entre una base de datos y un sistema de informacion.

Contrario a la definicion anterior de informacion, existen autores como Goldratt [65], que definen la informa-

cion como la respuesta a lo que se ha preguntado. Esto es, que la informacion no es lo que entra en el proceso

de decision, si no lo que sale de el.

El hecho de no contar con una metodologıa adecuada en el diseno de sistemas de generacion y acondicionamien-

to de datos acerca del sistema de manufactura ha llevado a las companıas a reunir mas y mas datos y despues,

26


cuando esto ya no resulto util, se obtuvieron datos mas precisos. Los datos son necesarios, pero no todos. Una

de las clases de datos mas buscada es el coste del producto.

Consecuencia del estudio sobre la generacion y gestion de informacion, el concepto de un sistema de infor-

macion comenzo a emerger en la decada de 1960. A pesar del tiempo que lleva desarrollandose el entorno de

los sistemas de informacion, aun se encuentran dificultades para definirlos con precision. Parte de esa dificul-

tad se deriva del hecho de que los sistemas de informacion pueden analizarse desde al menos tres diferentes

perspectivas [66]:

Por la contribucion de estos.

Por su estructura y comportamiento.

Por la funcion que estos desempenan.

Desde la primera perspectiva, los sistemas de informacion se definen como medios que permiten lograr un

objetivo. Desde este punto de vista, los sistemas de informacion son subsistemas que contribuyen en sistemas

mayores.

Basandose en la segunda perspectiva, se enfatiza la estructura y comportamiento de los elementos fısicos y

abstractos que son parte de un sistema de informacion. Para el proposito de un modelado conceptual, la mejor

definicion es la que esta basada en las funciones que desempena el sistema de informacion. Desde esta ultima

perspectiva, la definicion marca que un sistema de informacion es aquel que colecta, almacena, procesa y dis-

tribuye informacion.

El uso de sistemas de informacion ha comenzado a abarcar una amplia variedad de areas, en las ciencias sociales

y en la ciencias de la naturaleza [64], para obtencion de informacion de una granja experimental [67], en fısica

experimental [68] y, por supuesto en, sistemas de manufactura [13].

Sin embargo, para el campo de la ingenierıa, el concepto de sistema de informacion debe restringirse a sis-

temas disenados. Por lo tanto, se debe considerar un sistema solo si tiene las siguientes tres representaciones

principales, y cada una puede darse en dos modos: por peticion o automaticamente

Memoria: Para mantener una representacion del estado de un dominio.

Informativo: Para proveer informacion acerca del estado de un dominio.

Activo: Para llevar a cabo acciones que cambian el estado de un dominio.

La funcion de memoria busca mantener una representacion interna del estado del dominio. Esta representacion

la necesitan otras funciones del sistema. El estado del dominio cambia frecuentemente de manera diferente. En

27


el caso de un sistema de produccion, las maquinas, el producto y su posicion, las personas involucradas en el

proceso, los proveedores y los clientes son parte del dominio.

La funcion informativa del sistema debe mostrar a los usuarios informacion acerca del estado del dominio; por

ejemplo, la cantidad de cierto producto en el almacen puede observarse directamente cuando sea necesario y,

simultaneamente, representarse en el sistema de informacion. En esencia, es mas facil pedir la informacion a un

sistema, que observarlo directamente.

La funcion activa se encarga de las acciones que modifican el estado del dominio. Con el fin de llevar a cabo

dichas actividades, el sistema debe conocer las acciones que puede tomar, cuando tomarse y como afectan el

estado del dominio.

Tabla 2.1: Ejemplos de funciones en los dos modos de operacion

FuncionesModos de operacion

Por solicitud Autonomo

Memoria Cambio de domicilio de un proveedor Lectura de temperatura de un proceso

Informativo ¿Cual en la temperatura de cierto proceso? Senales cuando la temperatura sobrepaso cierto nivel

Activo Intereses de un prestamo Reposicion automatica de productos en una tienda

2.2.1. Modelo conceptual de un sistema de informacion

Los sistemas empresariales denominados sistemas de planificacion de recursos empresariales ERP, es un nom-

bre comercial de los sistemas de informacion organizacional que se usan comunmente en las empresas. La

implementacion de un sistema ERP puede ser una tarea bastante compleja ya que es dificil analizar un sistema

en uso y despues ajustar el modelo ERP al sistema de manufactura, esto debido a que las empresas tienden a

disenar sus procesos antes de implementar el sistema ERP. Por desgracia, es comun que el desarrollo del sistema

se realice sin una metodologıa adecuada y de manera apresurada por lo que el modelo de negocios propuesto no

siempre coincide con la funcionalidad del sistema ERP. El resultado es que se requiere mas tiempo de persona-

lizacion, periodos de tiempo de implementacion extendidos, costos mas altos, etc.

Para propositos de modelado conceptual, las definiciones mas usadas son aquellas basadas en las funciones que

desarrolla el sistema de informacion. Las consideraciones en este caso se basan exclusivamente que hace el

sistema de informacion, sin considerar porque y como lo hacen.

A. Olive [66] define un sistema de informacion como: Un sistema disenado para colectar, procesar y distribuir

28


informacion acerca del estado de cierto dominio u organizacion.

Como ya se menciono anteriormente, las funciones principales de un sistema de informacion son: Memoria,

Informativo y Activo. Para que este sea capaz de llevar a cabo esas funciones necesita tener un conocimiento

acerca de su dominio y acerca de las funciones que va a desempenar. Para conocer los principales tipos de co-

nocimiento requerido por un sistema de informacion, se sigue la siguiente lınea de razonamiento:

Si la funcion de memoria de un sistema de informacion mantiene una representacion del estado del do-

minio, el disenador debe definir el estado particular que debe representarse.

El estado de diferentes dominios varia conforme al tiempo, por lo que los cambios potenciales deben de

estar definidos.

La representacion del estado en el sistema de informacion debe ser consistente. Por lo tanto, es necesario

definir cuando una representacion es consistente.

Los sistemas de informacion se desarrollan con diversos propositos, segun las necesidades de la empresa donde

seran aplicados [63]. Existen actualmente disenos estandarizados de sistemas de informacion para fines especıfi-

cos como por ejemplo:

Sistemas de procesamiento de transacciones.

Sistemas de automatizacion de la oficina.

Sistemas de gestion del conocimiento.

Sistemas de informacion gerencial.

Sistemas de apoyo a la toma de decisiones.

e infinidad de otros sistemas derivados de los anteriores destinados usualmente al sector industrial.

Dentro del contexto de los sistemas de informacion, se tiene una suposicion fundamental de que el dominio

consiste en cierto numero de objetos y las relaciones entre ellos, las cuales son clasificadas en conceptos. Por los

tanto, el estado de un domino en particular, en un tiempo dado, consiste en un conjunto de objetos, un conjunto

de relaciones y de un conjunto de conceptos en el que estan clasificados los objetos y las relaciones [66].

Los sistemas de informacion en sistemas de tiempo real

Los sistemas en tiempo real monitorean y controlan un ambiente. Siguiendo las definiciones antes mencionadas,

la funcion de memoria es el monitoreo del ambiente y el control aplicado a este es la funcion activa. Ademas, los

sistemas en tiempo real interactuan con los usuarios, para quienes llevan a cabo una funcion determinada. Dicha

29

2.3. GENERALIDADES EN EL ANALISIS DE SISTEMAS

funcion puede ser informativa o activa. Los sistemas en tiempo real usualmente cuentan con varios sensores e

interfaces entre sistemas que proveen una entrada continua y periodica de datos. Estos son los mecanismos que

permiten al sistema conocer el estado del ambiente para la funcion de memoria. Finalmente, un sistema en tiem-

po real tiene un conjunto de actuadores o interfaces entre sistemas que permiten modificarlo periodicamente,

correspondiendo estos a los mecanismos que el sistema usa para enviar informacion de salida hacia el ambiente

desde la funcion de activacion.

Un sistema de tiempo real posee otras caracterısticas relacionadas no solamente con las funciones que este

realiza, si no en como las realiza, por ejemplo el periodo, de muestreo de los sensores, el tiempo de respues-

ta, procesamiento simultaneo de varias entradas, exactitud y limitaciones del sistema. Las caracterısticas antes

mencionadas son muy importantes, sin embargo estas no cambian el hecho de que los sistemas en tiempo real

pueda considerarse como sistemas de informacion.

2.3. Generalidades en el analisis de sistemas

El analisis de sistemas busca comprender que necesitan los usuarios para analizar la entrada o el flujo de datos

de manera sistematica, procesar o transformar los datos, almacenarlos y producir informacion en el contexto de

una organizacion especıfica [63]. Mediante una analisis detallado se pueden identificar y resolver correctamente

los problemas.

Si un sistema se instala sin una planificacion apropiada, a menudo el usuario puede quedar insatisfecho y de-

jara de usar el sistema. El analisis y diseno anade estructura a los sistemas y constituye una actividad costosa

que de otra manera se termina realizando al azar. El analisis y diseno de sistemas puede considerarse como una

serie de pasos que se llevan a cabo en forma sistematica para mejorar una empresa mediante el uso de sistemas

de informacion computarizados.

Las nuevas tecnologıas tambien impulsan la necesidad del analisis de sistemas. Existen paquetes de softwa-

re CASE, Computer Aided Software Engineering, que proporcionan la plataforma para desarrollar sistemas de

software; desde paginas WEB, hasta complejos sistemas de informacion de una corporacion. Todo esto responde

a que independientemente del grado, uso y complejidad de los programas, finalmente todos estos son sistemas.

30


2.3.1. Determinacion de los requerimientos de informacion del usuario

Una fase muy importante del analisis de sistemas es determinar las necesidades de los usuarios involucrados.

El proceso de analisis utiliza metodos interactivos como entrevistas, muestreos e investigacion de datos duros,

ademas de los cuestionarios y metodos discretos, como la observacion del comportamiento de los usuarios y los

encargados de tomar decisiones.

Puede resumirse este proceso al platear ciertas preguntas como lo plantea E. Kendall [63]: ¿Que se puede hacer

para que el sistema sea perceptible, legible y seguro?, ¿como puede disenarse el nuevo sistema para que sea

facil de usar, aprender y recordar?, ¿como puede el sistema ser agradable o incluso divertido de usar?, ¿como

puede el sistema apoyar las tareas laborales individuales de un usuario y buscar nuevas formas de hacerlas

mas productivas?.

Las personas involucradas en esta fase son los analistas/disenadores y los usuarios, por lo general los gerentes

y los trabajadores de operaciones. El disenador debe conocer los detalles sobre las funciones del sistema re-

queridas por el interesado o usuario final: personas involucradas, actividad general del sistema, entorno en el

que se llevaran a cabo las operaciones, coordinacion, de que manera particular se realizan los procedimientos u

operaciones.

2.3.2. Analisis de las necesidades del sistema

La siguiente fase que debe llevar a cabo el disenador de sistemas involucra el analisis de las necesidades del

sistema. Las herramientas comunmente usadas son los diagramas de flujo de datos para graficar la entrada,

los procesos y la salida de las funciones de la empresa, o tambien los diagramas de actividad o de secuencia

para mostrar la secuencia de los eventos; sirven para ilustrar a los sistemas de una manera estructurada y grafica.

Durante esta fase, el disenador del sistema tambien analiza las decisiones estructuradas llevadas a cabo. Las

decisiones estructuradas son aquellas para las que se pueden determinar condiciones, alternativas de condicion,

acciones y reglas de accion.

2.3.3. Las organizaciones como sistemas

Las organizaciones son sistemas extensos compuestos por subsistemas interrelacionados. Los subsistemas se

ven influenciados por tres amplios niveles de personas que toman decisiones administrativas y atraviesan hori-

zontalmente todo el sistema organizacional. Se puede conceptualizar operativamente a las organizaciones y sus

miembros con un sistema disenado para cumplir con ciertas metas y objetivos predeterminados.

31


Figura 2.8: Ejemplo de un diagrama de flujo de datos.

Conceptualizar a las organizaciones como sistemas complejos permite entender la forma en que funcionan a

traves de los principios de sistemas. Para establecer adecuadamente los requerimientos de informacion y di-

senar sistemas de informacion apropiados, es primordial comprender a la organizacion como un todo.Todos los

sistemas procesan entradas provenientes de sus entornos. Los procesos cambian o transforman las entradas en

salidas.

Otro aspecto de las organizaciones como sistemas es que todos los sistemas estan contenidos por lımites que los

separan de sus entornos. Los lımites organizacionales existen en un rango continuo, desde los extremadamente

permeables hasta los que son casi impermeables.

La retroalimentacion es una forma de control de un sistema. Como sistemas, todas las organizaciones usan la

planeacion y el control para administrar sus recursos con efectividad. El sistema ideal puede conceptualizarse

como uno que se corrige o regula automaticamente, de tal forma que no se requieran decisiones basadas en

acontecimientos comunes. La retroalimentacion se recibe desde el interior de la organizacion y de los entornos

exteriores. Cualquier cosa externa a los lımites de una organizacion se considera su entorno. Algunos de estos

entornos comunes a las empresas pueden ser:

El entorno de la comunidad en la que se encuentra fısicamente la organizacion

El entorno economico

El entorno polıtico

El entorno legal

Diagrama de flujo de datos logicos y fısicos

Un diagrama de flujo de datos fısicos (Figura 2.8) muestra como se implementara el sistema, incluyendo hard-

ware, software, los archivos y las personas involucradas en el sistema. Es importante mencionar que el modelo

32


logico refleja a la empresa, mientras que el modelo fısico describe al sistema.

Para crear el diagrama de flujo de datos fısico para un sistema, hay que analizar sus salidas y entradas. Al crear

un diagrama de flujo de datos fısico, el flujo de datos de entrada que proviene de una entidad externa se le deno-

mina algunas veces desencadenador, debido a que empieza las actividades de un proceso; el flujo de datos de

salida de una entidad externa se le denomina algunas veces respuesta, ya que se envıa como resultado de alguna

actividad. Hay que determinar cuales campos de datos o elementos que se tiene que capturar. Estos campos se

denominan elementos base y se deben almacenar en un archivo. Los elementos que no se capturan, sino que

constituyen el resultado de un calculo o una operacion logica, se denominan elementos derivados.

Los diagramas de casos de uso identifican a todos los actores en el dominio del problema, de forma que un

analista de sistemas se puede concentrar en lo que los usuarios desean y necesitan para usar el sistema y extender

sus capacidades. Los diagramas de caso de uso se popularizaron entre los analistas de sistemas debido a su

sencillez y carencia de detalles tecnicos, con lo que se volvio mas facil la comunicacion con el usuario. Se

utilizan para mostrar el alcance de un sistema, junto con las principales caracterısticas del mismo y los actores

que trabajan con estas caracterısticas principales. Los usuarios al ver el sistema de esta manera pueden proveer

valiosa retroalimentacion.

2.3.4. Modelado de casos de uso

Un modelo de casos de uso describe que hace un sistema sin describir como lo hace, por lo tanto, es un modelo

logico del sistema. El modelo de caso de uso presenta al sistema desde la perspectiva de un usuario fuera del

mismo.

El disenador de sistemas desarrolla casos de uso en cooperacion con los expertos para ayudar a definir los re-

querimientos del sistema. El modelo de caso de uso provee un medio efectivo de comunicacion entre el usuario

final y el equipo de desarrollo. Un modelo de caso de uso fracciona la forma en que trabaja el sistema en com-

portamientos, servicios y respuestas que sean importantes para los usuarios del sistema.

Sımbolos de los casos de uso

Un diagrama de caso de uso contiene los sımbolos del actor y del caso de uso, junto con lıneas conectoras,

como en los ejemplos de la figura 2.9. El termino actor se refiere a un rol especıfico de un usuario del sistema.

El actor existe fuera del sistema e interactua con este de una manera especıfica. Un actor puede ser un humano,

otro sistema o un dispositivo como un teclado o una conexion Web. Los actores pueden iniciar una instancia, o

desencadenar una accion, de un caso de uso. Un actor puede interactuar con uno o mas casos de uso; un caso de

uso puede involucrar uno o mas actores.

33


Figura 2.9: Ejemplos de casos de uso y los diferentes conectores

Los actores pueden dividirse en grupos. Los actores principales suministran datos o reciben informacion del

sistema. Algunos actores interactuan directamente con el sistema, pero los actores principales tambien pueden

ser personas en la organizacion que no interactua directamente con el sistema.

Un caso de uso provee a los desarolladores una perspectiva de lo que quieren los usuarios, si detalles tecnicos o

implementacion. Un caso de uso siempre describe tres cosas:

1. un actor que inicia un evento

2. el evento que desencadena un caso de uso

3. el caso de uso que ejecuta las acciones desencadenadas por el evento.

Un evento es una entrada para el sistema que ocurre a una hora y lugar especıficos y provoca que el sistema

haga algo.

Relaciones en los casos de uso

Las relaciones se utilizan principalmente en los diagramas de casos de uso. Hay cuatro tipos basicos de relacio-

nes de comportamiento: comunica, incluye, extiende y generaliza.

Comunicacion. Es la relacion de comportamiento que se utiliza para conectar un actor con un caso de uso.

34


Inclusion. Tambien se le conoce como relacion de usos y describe la situacion en la que un caso de uso contine

comportamiento comun para mas de un caso de uso.

Extension. Esta relacion describe la situacion en la que un caso de uso posee el comportamiento que permite

al nuevo caso de uso manejar una variacion o excepcion a partir del caso de uso basico.

Generalizacion. Esta relacion implica que una cosa es mas comun que otra.

El alcance de un sistema define sus lımites. Por lo general el proyecto cuenta con un presupuesto que ayuda a

definir el alcance, ademas del tiempo inicial y final. Los actores siempre estan fuera del alcance del sistema.

Las lıneas de comunicacion que conectan a los actores con los casos de uso son los lımites que definen el alcance.

Desarrollo de diagramas de casos de uso

Para crear un diagrama de caso de uso, es necesario contar con una lista de todo lo que el sistema deba hacer por

el usuario. Esta lista puede obtenerse por medio de entrevistas, en una sesion de diseno de aplicacion conjunta o

a traves de sesiones guiadas en equipo. Es importante tambien tener la informacion sobre quien esta involucrado

con cada caso de uso y las responsablidades o servicios que el caso de uso debe proveer a los actores o a los

otros sistemas.

Un diagrama de flujo de datos a nivel de contexto puede ser un punto de partida para un caso de uso. Las

entidades externas son los actores potenciales.

Desarrollo de escenarios de casos de uso

Cada caso de uso tiene una descripcion. Se designa a la descripcion como un escenario de caso de uso. El caso

de uso principal representa el flujo estandar de eventos en el sistema; las rutas alternativas describen variaciones

sobre el comportamiento. No hay formato estandarizado para los casos de uso; por lo que cada organizacion

tiene que especificar los estandares a incluir.

Creacion de las descripciones de los casos de uso

Segun E. Kendall [63], los siguientes pasos son los mas comunes para crear las descripciones de casos de uso:

1. Usar historias agiles, los objetivos de la definicion del problema, requerimientos de los usuarios o una

lista de caracterısticas como punto de inicio.

2. Tener conocimiento sobre las tareas que hay que realizar para lograr la transaccion. Tambien es importante

saber si el caso de uso lee datos o actualiza alguna tabla.

35


Figura 2.10: El diagrama de Gantt

3. Es importante saber si hay acciones iterativas o de ciclos.

4. El caso de uso termina cuando se completa el objetivo del usuario.

2.3.5. Planeacion y control de actividades

Ya que el analisis y diseno de sistemas involucra muchas actividades, el equipo de analisis y diseno debe ser

capaz de administrar el proyecto con cuidado para que este tenga exito. La gestion de proyectos incluye las

tareas de planeacion y control comunes.

La planeacion incluye todas las actividades requeridas para seleccionar un equipo de analisis de sistema, asig-

nar miembros del equipo de diseno a los proyectos apropiados, estimar el tiempo requerido para completar cada

tarea y programar el proyecto de manera que las tareas se completen a tiempo. El control implica utilizar retro-

alimentacion para supervisar el proyecto. Ademas el control implica tomar la accion apropiada para agilizar o

reprogramar las actividades para que estas se pueden terminar a tiempo.

Uso de graficos de Gantt para programar proyectos

Este tipo de grafico donde las barras representan cada tarea o actividad. La longitud de cada barra representa la

duracion relativa de la tarea. La principal ventaja del grafico de Gantt es su simpleza.

2.3.6. La metodologıa del flujo de datos para determinar los requerimientos de los

usuarios

Los diagramas de flujo de datos describen con la mayor generalidad posible las entradas, los procesos y las

salidas del sistema. Para que un equipo de desarrollo de sistemas pueda comprender los requerimientos de in-

36


Tabla 2.2: Los sımbolos basicos utilizados en los diagramas de flujo de datos.

Sımbolo Significado

Entidad

Flujo de datos

Proceso

Almacen de datos

formacion de los usuarios, debe ser capaz de conceptualizar la forma en que los datos se mueven a traves de

la organizacion, los procesos o la transformacion por la que pasan los datos y las salidas de los mismos. Por

medio de una tecnica de analisis estructurado conocida como diagramas de flujo de datos se puede ensamblar

una representacion grafica de los procesos de datos a traves de la organizacion.

La metodologıa de flujo de datos tiene cuatro ventajas importantes en comparacion con las explicaciones

narrativas:

No hay que comprometerse demasiado pronto con la implementacion tecnica del sistema.

Permite comprender con mas detalle la capacidad de interrelacion de los sistemas y subsistemas.

Se puede comunicar el conocimiento del sistema actual a los ususaris por medio de diagramas de flujo de

datos.

Se puede analizar un sistema propuesto para determinar si se han definido los datos y procesos necesarios.

Se utilizan cuatro sımbolos basicos para graficar el movimiento de los datos en los diagramas: un cuadro, una

flecha, un rectangulo con esquinas redondeadas y un rectangulo con un extremo abierto. Vease la Tabla 2.2.

El cuadrado doble se utiliza para describir una entidad externa que puede enviar-recibir datos desde o hacia en

el sistema. La entidad externa , o simplemente entidad, tambien se conoce como origen o destino de los datos,

y se considera externa al sistema que se esta describiendo.

La flecha muestra el movimiento de los datos de un punto a otro. Los flujos de datos que ocurren al mismo

tiempo se pueden describir mediante el uso de flechas paralelas.

37


Figura 2.11: Ejemplo de un diagrama de flujo de datos fısico

Se utiliza un rectangulo con esquinas redondeadas para mostrar la ocurrencia de un proceso de transformacion.

Los procesos siempre expresan un cambio o transformacion en los datos. Los procesos representan el trabajo

que se realiza en el sistema.

El rectangulo con un extremo abierto representa un almacen de datos. En los diagramas de flujo de datos logicos

no se especifica el tipo de almacenamiento fısico. En este punto, el sımbolo del almacen de datos muestra solo

un deposito de datos que permite examinar, agregar y recuperar los datos.

Diagramas de datos logicos y fısicos

Un diagrama de flujo de datos fısico muestra como se implementara el sistema incluyendo hardware, software,

los archivos y las personas involucradas en el sistema (figura 2.11). Por su parte, es importante tener en cuen-

ta que es mas facil usar un modelo logico (figura 2.12) al momento de comunicarse con los usuarios del sistema.

2.3.7. Especificaciones de los procesos y decisiones estructuradas

Es importante que los disenadores de sistemas sean capaces de reconocer las decisiones logicas y estructuradas

que ocurren en una empresa y como se pueden diferenciar de las decisiones semiestructuradas que tienden a

involucrar el juicio humano. Para determinar los requerimientos humanos de informacion, primero se deben

determinar los objetivos de los usuarios junto con los objetivos de la organizacion, ya sea mediante el uso de

una metodologıa arriba-abajo o una metodologıa orientada a objetos.

Los tres objetivos al producir especificaciones de los procesos son:

Reducir la ambiguedad del proceso. Hay que detectar las areas imprecisas, anotarlas y consolidarlas

38


Figura 2.12: Ejemplo de un diagrama de flujo de datos logico

para todas las especificaciones de los procesos.

Obtener una descripcion precisa de lo que se va a lograr, que por lo general se incluye en un paquete

de especificaciones para el disenador.

Validar el sistema de diseno, lo que significa que el proceso tenga todo el flujo de datos de entrada

necesario para producir la salida.

Ademas es importante tener en cuenta los procesos o categorıas que generalmente no requieren especificaciones,

como son:

Procesos que representan entrada o salida fısica, como lectura y escritura.

Procesos que representan una validacion de datos simple, lo cual por lo general es bastante facil de lograr.

Procesos que utilizan codigo escrito con anterioridad.

2.3.8. Conceptos y diagramas del Lenguaje Unificado de Modelado (UML)

El enfoque Orientado a Objetos

El modelado orientado a objetos basa su idea misma en que nuestro mundo es un mundo de objetos. Los objetos

existen en la naturaleza, en entidades hechas por el hombre, en negocios, en productos usados en nuestra vida

cotidiana. Esos objetos pueden categorizarse, describirse, organizarse, combinarse, manipularse y crearse. Por

lo anterior, es normal esperar que se propusiera la creacion de software usando este enfoque, ya que todo soft-

ware es un abstraccion que nos permite modelar el mundo de forma que nos ayude a entender y navegarlo mejor.

Un objeto es el concepto basico, en lugar del proceso, contrario a la metodologıa de programacion estructurada.

Un objeto representa: un individuo, elemento identificable, unidad, o entidad, real o abstracta, con un papel

39


bien definido en el dominio del sistema al que pertenece. El objeto es la unidad atomica de encapsulacion y se

usa para la descomposicion del sistema.

Un objeto tiene:

Estado.

Comportamiento.

Identidad.

Los objetos cuyo comportamiento sea similar se definen en clases comunes [18,19]. Un objeto contiene atributos

que representan el estado de dicho objeto, y operaciones llamadas metodos, que definen el comportamiento del

objeto. Los metodos especifican la respuesta del objeto a los mensajes recibidos. Un objeto acepta parametros

y tiene acceso a los atributos que resultan comunmente en un cambio de estado. Cada objeto esta compuesto

por dos partes: la interface y la implementacion. La implementacion es el funcionamiento interno del objeto

y esta oculta para el exterior. La interface es visible para otros objetos que la usan para obtener servicios que

provee el objeto dueno de dicha interfaz.

Dentro del enfoque orientado a objetos, un sistema es considerado como una agregacion de objetos discretos

que colaboran con el fin de llevar a cabo un trabajo que beneficiara finalmente al usuario. La colaboracion entre

objetos que componen el sistemas se logra a traves del intercambio de mensajes.

Conceptos de UML

El Lenguaje Unificado de Modelado es un estandar nuevo en la industria de modelado de sistemas intensivos

de software. UML fue concebido como un lenguaje de proposito general para modelado de aplicaciones de

software orientado a objetos. El lenguaje representa un paso adicional de abstraccion que el provisto por los

lenguajes de programacion de alto nivel, los que estan mas cercanos a la implementacion de tecnologıa.

UML se define como un lenguaje estandar para especificar, visualizar, construir y documentar todos los arte-

factos en un sistema de software [69]. Etimologicamente hablando, un lenguaje provee un vocabulario y reglas

para combinar palabras en dicho vocabulario con el proposito de lograr una comunicacion. El vocabulario y las

reglas de UML se enfocan en la representacion conceptual y fısica de un sistema. Estas definen como crear y

leer modelos de sistemas; pero no definen que modelos deben crearse y cuando deben ser creados. Por esto es

por lo que se debe usar una metodologıa a traves del proceso de desarrollo.

Extendiendo la definicion de UML, citada en el parrafo anterior, el termino especificar se refiere o establece las

necesidades especıficas, requerimientos o instrucciones encontrados dentro de un sistema complejo. Visualizar

40


refiere el hecho de representar la informacion de forma visual, usando diagramas. El termino construir significa

crear un sistema basado en componentes especıficos de dicho sistema. Documentar es el hecho de guardar todo

el conocimiento y experiencia derivada del diseno del sistema con la finalidad de mostrar como fue concebido,

disenado, desarrollado, verificado y validado el sistema.

UML provee un conjunto estandarizado de herramientas para documentar el analisis y diseno de un sistema

de software. El conjunto de herramientas de UML incluye diagramas que permiten a las personas visualizar

la construccion de un sistema orientado a objetos, algo similar a la forma en que los planos de construccion

permiten a las personas visualizar la construccion de un edificio.

UML consiste en objetos, relaciones y diagramas. Los elementos estructurales permiten al usuario describir las

relaciones. Los aspectos de comportamiento describen la forma en que funcionan las cosas. Las cosas de grupo

se utilizan para definir lımites, los elementos de anotaciones se usan para poder agregar notas en los diagramas.

Aunque UML esta pensado para modelar sistemas complejos con gran cantidad de software, el lenguaje es lo

suficientemente expresivo como para modelar sistemas que no son informaticos, como flujos de trabajo en una

empresa, diseno de la estructura de una organizacion y en el diseno de hardware.

Las relaciones son el pegamento que mantiene las cosas unidas entre sı. Las relaciones estructurales se utili-

zan para unir los elementos en los diagramas estructurales. Las relaciones estructurales incluyen dependencias,

agregaciones, asociaciones y generalizaciones.

Hay dos tipos principales de diagramas en UML: diagramas estructurales y diagramas de comportamiento. Los

diagramas estructurales se utilizan, por ejemplo, para poder describir las relaciones entre los diferentes objetos.

Estos se dividen en diagramas de clases, diagramas de objetos, diagramas de componentes y diagramas de des-

pliegue.

Los diagramas de comportamiento se pueden utilizar para describir la interaccion entre las personas y casos de

uso del sistema, o dicho de otra forma, describe la manera en que los actores utilizan el sistema. Los diagramas

de comportamiento se dividen en diagramas de casos de uso, diagramas de secuencia, diagramas de comunica-

cion, diagramas de estado y diagramas de actividad.

Los seis diagramas de UML que se utilizan mayormente son:

1. Diagrama de casos de uso, que describe la forma en que se utiliza el sistema.

2. Escenario de caso de uso, una articulacion verbal de excepciones para el comportamiento principal des-

crito por el caso de uso.

41


3. Diagrama de actividad, que ilustra el flujo de actividades en general.

4. Diagramas de secuencia, que muestran la secuencia de las actividades y las relaciones entre las clases

5. Diagramas de clases, que muestran las clases y sus relaciones.

6. Diagramas de estado, que muestran las transiciones de estado.

Diagramas de secuencia y comunicacion

Un diagrama de interaccion puede ser un diagrama de secuencia o un diagrama de comunicacion como el que se

muestra en la Figura 2.13, ambos de los cuales muestran esencialmente la misma informacion. Estos diagramas

se utilizan para la realizacion de un caso de uso.

Los diagramas de secuencia pueden ilustrar una sucesion de interacciones entre las clases o instancias de obje-

tos a traves del tiempo. Los diagramas de secuencia se derivan del analisis de casos de uso y se utilizan en el

diseno de sistemas para derivar las interacciones, las relaciones y los metodos de los objetos en el sistema. Los

diagramas de secuencia se utilizan para mostrar el patron general de las actividades o interacciones en un caso

de uso.

Una lınea vertical representa la lınea de vida de la clase u objeto, que corresponde al tiempo a partir del que se

creo hasta el momento en que se destruye. Una X en la parte inferior de la lınea de la vida repreenta el momen-

to en que se destruye el objeto. Las flechas horizontales muestran mensajes o senales que se envıan entre las

clases. Los mensajes pertenecen a la clase receptora. Hay algunas variaciones en las flechas de los mensajes.

Las puntas de flecha solidas representan llamadas sincronicas, que son las mas comunes. Las medias puntas de

flecha representan llamadas asıncronas.

La sincronizacion en el diagrama de secuencia se muestra de arriba hacia abajo; la primera interaccion se dibuja

en la parte superior del diagrama y la interaccion que ocurre al ultimo se dibuja en la parte inferior del dia-

grama. Las flechas de interaccion empiezan en la barra del actor u objeto que indica la interaccion y terminan

apuntando a la barra del actor u objeto que recibe la solicitud de interaccion. El actor inicial u objeto se muestra

a la izquierda. Un ejemplo de la aplicacion de este diagrama se muestra en la Figura 2.14, usando una sencilla

secuencia de una maquina CNC.

Diagramas de comunicacion Los diagramas de comunicacion tambien se conocen como diagramas de co-

laboracion. Estos describen las interacciones entre dos o mas elementos en el sistema que desempenan un

comportamiento mayor a lo que cualquiera estos pueden hacer por su cuenta. Un diagrama de comunicacion

consta de tres partes: los objetos, los enlaces de comunicacion y los mensajes que se pueden pasar a traves de

42


Figura 2.13: Simbologıa de un diagrama de secuencia

Figura 2.14: Ejemplo del diagrama de secuencia aplicado a una maquina CNC

43


esos enlaces. Los diagramas de comunicacion muestran la misma informacion que un diagrama de secuencia,

pero pueden ser mas difıciles de leer.

Un diagrama de comunicacion hace enfasis en la organizacion de los objetos, mientras que un diagrama de

secuencia hace hincapie en el orden de los mensajes en el tiempo.

Diagramas de clases

Primero es esencial el concepto de objeto dentro del paradigma OO: Los objetos pueden ser personas, lugares

o cosas que son relevantes para el sistema a desarrollar. Ejemplo de objetos son los clientes, los pedidos, los

motores, valvulas y demas componentes que integre al sistema.

Las clases son construcciones que, gracias a atributos y operaciones previamente definidos, sirven de modelo

para la creacion de objetos del mismo tipo haciendo uso de la propiedad de herencia. Dicho lo anterior es claro

que los objetos se representan y agrupan en clases que son optimas para reutilizarse y darles mantenimiento.

Las metodologıas orientadas a objetos trabajan para descubrir las clases, atributos, metodos y relaciones entre

las clases. Definir clases es una de las tareas mas importantes del analisis orientado a objetos. Los diagramas de

clases muestran las caracterısticas estaticas del sistema y no representan ningun procesamiento en especial. Un

diagrama de clases tambien muestra la naturaleza de las relaciones entre las clases.

Como se observa en diagrama de la figura 2.15, las clases se representan mediante un rectangulo. En el formato

mas simple, el rectangulo puede incluir solo el nombre de la clase, pero tambien puede incluir atributos y meto-

dos. Los atributos son lo que la clase conoce sobre las caracterısticas de los objetos, y los metodos son lo que

la clase sabe acerca de como hacer las cosas. Los metodos son pequenas seccioines de codigo que trabajan con

los atributos.

Como se observa en la Figura 2.15, cada una de las clases esta definida por un nombre en la parte superior, la

seccion central contiene los atributos propios en cada clase y en la seccion final se encuentran las operaciones

que cada clase desempena. En este mismo diagrama se especifica la relacion entre las clases, por ejemplo: la

lınea, de produccion, es parte de un departamento y ejecuta una operacion especıfica; de la misma forma que

una maquina y un operador son parte de la lınea de produccion.

Un diagrama de clases puede mostrar solo el nombre de la clase, el nombre de la clase y los atributos o el

nombre de la clase, los atributos y los metodos. Es util mostrar solo el nombre de la clase cuando el diagrama

es muy complejo e incluye muchas clases.

44


Figura 2.15: Ejemplo de un diagrama de clases en una empresa

Las clases se dividen en cuatro categorıas: de entidad, de interfaz, abastracta y de control:

Clases de entidad Estas clases representan elementos del mundo real como personas o cosas. Las clases de

entidad son las entidades representadas en un diagrama de entidad-relacion. Las herramientas CASE permiten

crear una clase de entidad de UML a partir de una entidad en diagrama Entidad-Relacion.

Clases de lımite o de interfaz Se encargan de proveer los medios para que los usuarios trabajen con el siste-

ma. Existen dos amplias categorıas de clases de interfaz: humana y de sistema.

Una interfaz humana puede ser una pantalla , una ventana, un formulario Web, un cuadro de dialogo, un menu,

un cuadro de lista u otro control de visualizacion.

Las interfaces del sistema necesitan enviar o recibir datos de otros sistemas. Esto puede incluir a las bases de

datos en la organizacion.

Clases abstractas Son las clases que no se pueden instanciar o definir en forma directa. Las clases abstractas

estan enlazadas a clases concretas en una relacion de generalizacion/especializacion.

45


Figura 2.16: Ejemplo de un diagrama de estados en una lınea de elaboracion de pistones

Clases de control Tambien se les conoce como clases activas y se utilizan para controlar el flujo de acti-

vidades; actuan como un coordinador a la hora de implementar las clases. Para obtener clases que se puedan

reutilizar, un diagrama de clases puede incluir muchas clases de control pequenas.

Diagramas de estados

El diagrama de estados (Figura 2.16) es otra herramienta para determinar los metodos de las clases. Se utiliza

para examinar los distintos estados que puede tener un objeto. Se crea un diagrama de estados para una sola

clase. Por lo general los objetos se crean, pasan por cambios y se eliminan o quitan.

Los objetos existen en estos diversos estados, que son las condiciones de un objeto en un momento especıfico.

Los valores del atributo de un objeto definen el estado en que se encuentra el objeto y algunas veces hay un

atributo tal como el estado del pedido que indica el estado. Un estado tiene un nombre en el que cada palabra

empieza con mayuscula. El nombre debe ser unico y descriptivo.

Un evento es algo que ocurre en un tiempo y lugar especıficos. Los eventos provocan un cambio del estado del

objeto y se dice que una transicion se dispara. Los estados separan eventos.

Los eventos se clasifican en tres categorıas:

1. Senales o mensajes asıncronos, que ocurren cuando el programa que hace la llamada no espera un mensaje

de retorno.

2. Mensajes sıncronos, que son llamadas a funciones o subrutinas.

46


3. Eventos temporales, que ocurren en tiempo predeterminado.

2.3.9. Diseno de una salida del sistema

La salida es informacion que se entrega a los usuarios por medio del sistema de informacion. Algunos datos

requieren de mucho procesamiento para poder convertirse en una salida adecuada; otros se almacenan y, cuando

se recuperan, se consideran salida sin que necesiten mucho procesamiento.

La salida puede tener diversos formatos: la tradicional copia en papel de los informes impresos y la copia tran-

sitoria como las pantallas, microformas y la salida de video y audio.

Es esencial una salida util para asegurar el uso y la aceptacion del sistema de informacion, por lo que el diseno

de sistemas debe de alcanzar seis objetivos [63]:

1. Disenar la salida para servir al proposito especıfico. Durante la fase de determinacion de los requeri-

mientos de informacion del analisis, el equipo de diseno averigua los propositos existentes de los usuarios

y la organizacion.

2. Disenar la salida para ajustarla al usuario. En un sistema de informacion extenso que atiende a muchos

usuarios con muchos fines, y a menudo es difıcil personalizar la salida para cada uno de estos. Con base

en las entrevistas, observaciones, consideraciones de costo es posible disenar una salida para atender lo

que muchos usuarios prefieren.

3. Entregar la cantidad apropiada de salida. El sistema debe proveer lo que necesita cada persona para

realizar su trabajo.

4. Asegurarse que la salida este donde se necesite. El aumento en el uso de la salida que se muestra a traves

de una pantalla en lınea y a la que se puede acceder personalmente ha reducido en parte el problema de

distribucion, pero la distribucion apropiada sigue siento un objetivo importante en el diseno de sistemas.

5. Proveer la salida en forma oportuna. Aunque la sincronizacion no lo es todo, sı desempena un papel

importante en cuanto a la utilidad de la salida.

6. Elegir el metodo de salida correcto. El proceso de eleccion de un metodo de salida tiene que ver con el

costo, accesibilidad, flexibilidad, durabilidad, distribucion, posibilidades de almacenamiento y recupera-

cion etc.

2.3.10. Diseno de una entrada efectiva

Los formularios de entrada, las pantallas y los formularios interactivos bien disenados deben cumplir con los

objetivos de efectividad, precision, facilidad de uso, consistencia, simpleza y atraccion. La efectividad significa

47


que los formularios de entrada o las pantallas de entrada sirvan a propositos especıficos para los usuarios del

sistema de informacion, mientras que la precision se refiere a la busqueda de que el diseno cuente con una

estructura apropiada para el llenado adecuado. La facilidad de uso significa que los formularios y pantallas sean

simples, de manera tal que el usuario requiera el mınimo tiempo posible para descifrar su estructura.

En el analisis y diseno de sistemas, se debe ser capaz de disenar un formulario completo y util; los formularios

innecesarios desperdician los recursos de una organizacion. Para disenar formularios utiles se deben tener en

cuenta cuatro lineamientos de diseno de formularios:

1. Que los formularios sean faciles de llenar. Para evitar los errores, agilizar el proceso de complementar-

los y facilitar la introduccion de los datos, es esencial que los formularios sean faciles de llenar. El costo

de los formularios es mınimo si se compara con el del tiempo que invierten los empleados en llenarlos y

despues en introducir lo datos en el sistema de informacion.

Un formulario con un flujo apropiado reduce el tiempo y esfuerzo que invierten los empleados en llenarlo.

Los formularios deben fluir de izquierda a derecha y de arriba abajo.

El uso de leyendas es otra tecnica para facilitar el trabajo de llenar un formulario. Las leyendas indican

a la persona que completa el formulario lo que debe poner en una lınea, espacio o cuadro en blanco. No

importan los estilos de leyendas que se elijan, es imprescindible emplearlos de manera consistente. Las

leyendas de verificacion son una mejor opcion cuando es necesario restringir las opciones de respuesta.

Una leyenda de verificacion horizontal tambien es mejor opcion que una leyenda de lınea cuando la

informacion requerida es rutinaria y constante.

2. Que cumplan con el proposito para el que se disenaron. Los formularios se crean para servir en los

procesos de registrar, procesar, almacenar y recuperar la informacion para las empresas. Algunas veces es

conveniente proveer distinta informacion a los diferentes departamentos o usuarios y compartir al mismo

tiempo cierta informacion basica.

3. Que su diseno cumpla a que estos se completen con precision Por lo general, las tasas de errores

asociadas con la recoleccion de los datos disminuyen de manera considerable cuando los formularios

se disenan de tal forma que sea obvia la manera en que deben completarse con precision. El diseno es

importante para asegurar que las personas hagan lo correcto con el formulario siempre que lo utilicen.

4. Que sean atractivos. Los formularios deben lucir ordenados, los formularios deben solicitar la informa-

cion en el orden esperado. La distribucion y el flujo apropiados contribuyen al atractivo de un formulario.

Utilizar distintos tipos de letra en el mismo formulario puede ser util para que a los usuarios se les haga

mas atractivo llenarlo. Separar las categorıas y subcategorıas con lıneas gruesas y delgadas tambien puede

fomentar el interes.

48


Las tareas basicas para disenar los formularios incluyen asegurar que cada formulario en uso cumpla con su

proposito especıfico para ayudar a los trabajadores a realizar sus tareas y que el proposito especificado sea

integral para el funcionamiento de la organizacion, de manera que se evite la duplicacion de la informacion

recopilada y de los formularios correspondientes.

2.3.11. Interaccion Humano-Computadora

El diseno bajo la perspectiva de la Interaccion Humano-Computadora (HCI por su siglas en ingles) implica ase-

gurar la funcionalidad y usabilidad del sistema, proporcionando un soporte efectivo a las interacciones con el

usuario y posibilitandole una experiencia confortable. El objetivo primordial es alcanzar efectividad y eficiencia

para el usuario tanto empresarial como individual.

El contexto de la HCI consiste en conocer la interaccion entre los usuarios, las tareas, los contextos de las tareas

las tecnologıas de la informacion y los entornos donde se utilizan los sistemas.

Otros conceptos a tener en cuenta en el diseno basado en HCI (Human-Computer Interface):

Ajuste. Un buen ajuste entre los elementos de HCI del humano, la cumputadora y la tarea a desarrollar con-

ducen al desempeno y bienestar.

Un disenador de sistemas debe buscar el mejor ajuste para su diseno; aspira a emplear al personal de la mejor

manera posible, para disenar una tarea computarizada que cumpla con un objetivo de la organizacion. Un mejor

ajuste produce mejor desempeno y mayor confort para la persona involucrada con el sistema.

Tarea. Las tareas pueden ser estructuradas y rutinarias, o pueden estar mal definidas y sin una estructura apa-

rente.

Desempeno. En el contexto de la HCI el desempeno se refiere a una combinacion de la eficiencia involucrada

al desempenar una tarea y la calidad del trabajo que esta produce.

Bienestar. Se refiere a la preocupacion por la comodidad, seguridad y salud de un humano en general.

Para asegurar la calidad de los datos que los usuarios introducen al sistema, es importante capturar los datos

con efectividad. La captura de datos ha recibido cada vez mas atencion como el punto en el procesamiento de

49

2.4. MODELADO DE SISTEMAS

la informacion en el que se pueden obtener excelentes ganancias en productividad.

La decision sobre lo que se debe capturar es mas importante que la interaccion del usuario con el sistema. El

desarrollador y los usuarios son los que se deben encargar de las decisiones sobre los datos que se deben captu-

rar para introducirlos al sistema. Gran parte de lo que se captura es especıfico para la empresa en particular.

Hay dos tipos de datos a introducir: los datos que cambian o varian con cada transaccion, y los datos que dife-

rencian en forma concisa un elemento especıfico que se esta procesando de los demas elementos.

Al considerar que datos es necesario capturar para cada transaccion y los que hay que dejar para que el sistema

los introduzca, el disenador del sistema debe aprovechar que las computadoras pueden manejar de manera

automatica las tareas repetitivas, como registrar el tiempo de la transaccion, calcular nuevos valores a partir de

la entrada, ademas de almacenar y recuperar datos bajo demanda.

2.4. Modelado de sistemas

Un modelo es un generador de configuraciones potenciales de sistemas; los sistemas posibles son sus extensio-

nes o valores. Idealmente, todas las configuraciones consistentes con el modelo deberıan ser posibles. A veces,

sin embargo no es posible representar todas las restricciones dentro de un modelo. Un modelo es tambien una

descripcion de la estructura generica y del significado de un sistema. Las descripciones son su objetivo, o signi-

ficado. Un modelo es siempre una abstraccion a un cierto nivel. Captura los aspectos esenciales de un sistema y

omite algunos detalles.

2.4.1. El Lenguaje Unificado de Modelado (UML)

Ası como su nombre lo indica, UML es un lenguaje estrictamente de modelado y no contiene nada sobre el pro-

ceso de desarrollo de sistemas. El objetivo del modelado de un sistema es capturar las partes esenciales de un

sistema. Para facilitar el modelado, se realiza una abstraccion y se plasma en una notacion grafica. El modelado

visual permite manejar la complejidad de los sistemas y ası poderlos analizar o hasta disenar.

UML se usa para entender, disenar, hojear, configurar, mantener y controlar la informacion sobre los sistemas.

Esta pensado para usarse con todos los metodos de desarrollo, etapas de ciclo de vida, dominios de aplicacion

y medios [18].

Uno de los mayores desafıos en el desarrollo de sistemas es el de construir el sistema adecuado, el que resuelva

las necesidades de los usuarios a un costo razonable. Esto se hace aun mas difıcil porque los disenadores poseen

50


un lenguaje propio y ademas tiene que comunicarse con usuarios que tambien tiene su propio lenguaje contex-

tual. Lograr una buena comuncacion, junto con una comprension adecuada del mundo del usuario, es la clave

para el desarrollo de un buen sistema.

El objetivo principal del UML es la representacion grafica en el diseno de sistemas. La idea de un lenguaje de

modelado que fuera usado por todas las personas surgio dentro del mundo del diseno de software, ya que los

involucrados comenzaron a darse cuenta que en el desarrollo de un proyecto grande, que involucrara a distintas

personas, los problemas de estandarizacion utilizada, ası como la metodologıa a seguir, se volvieron factores

primordiales en el momento de buscar disenar software mas complejo en un menor tiempo.

EL lenguaje UML tiene una notacion grafica muy expresiva que permite representar en mayor o menor medida

todas las fases de un proyecto de cualquier ındole, desde analizar en base a casos de uso, el diseno con los dia-

gramas de clases, objetos, etc hasta lograr la implementacion y configuracion con los diagramas de despliegue.

La necesidad de una metodologıa se hace demasiado crıtica dentro de las empresas u organizaciones donde los

sistemas de software son esenciales. tales como las financieras, las de control de trafico aereo, las de defensa

y las de sistemas de telecomunicaciones. En otras palabras, la direccion exitosa de un negocio o la ejecucion

oportuna de la administracion publica depende del sistema de informacion que la soporta [19].

Un proceso define quien esta haciendo que, cuando y como alcanzar un determinado objetivo. Un proceso efec-

tivo proporciona normas para el desarrollo eficiente de productos de calidad. Captura y presenta las mejores

practicas que el estado actual de la tecnologıa permite. En consecuencia, reduce el riesgo y hace el proyecto

mas predecible. El efecto global es el fomento de una vision y una cultura comunes [18, 19].

Es necesario tener un proceso que sirva como guıa para todos los participantes (clientes, usuarios, desarrolla-

dores, gerentes, ejecutivos). Es necesario tener el mejor proceso que la industria pueda reunir en este punto de

su historia. Ademas tambien es necesario tener un proceso que este ampliamente disponible de forma que todos

los interesados puedan comprender su papel en el desarrollo en el que se encuentran involucrados.

El proceso de desarrollar un sistema hardware-software para un proceso de manufactura debe tomar en cuenta

la evolucion y los cambios que este sufra durante un largo periodo de tiempo. Durante esta continua evolucion

deberıa limitar su alcance a las realidades que permitan las tecnologıas, herramientas, personas y patrones de

organizacion, que a continuacion se describen:

Tecnologıas: El proceso debe construirse sobre las tecnologıas (lenguajes de programacion, sistemas ope-

rativos, computadores, sensores, interfaces) disponibles en el momento en que se va a emplear el proceso.

51


Herramientas: Los procesos y las herramientas deben desarrollarse en paralelo. Las herramientas son

esenciales en el proceso. En otras palabras, un proceso ampliamente utilizado puede soportar la inversion

necesaria para crear las herramientas que lo soporten.

Personas: El creador del sistema debe limitar las habilidades que se requieren para trabajar en este. Por lo

que debe de conocer las habilidades de los actuales usuarios o considerar aquellas habilidades que puedan

obtenerse facilmente.

Patrones de Organizacion: Los desarrolladores del sistema deben poder adaptar el sistema a las actuales

realidades que brindan las TI’s, ejemplo de estas son las empresas virtuales, el trabajo a distancia, la

mezcla de socios en la empresa, etc.

2.4.2. Enterprise Architect

Enterprise Architect es una herramienta CASE (Computer Aided Software Engineering) para disenar y construir

sistemas de software. Enterprise Architec soporta especificaciones y semantica de UML 2.0. la cual describe un

lenguaje visual usado para definir mapas o modelos de un proyecto.

Enterprise Architect proporciona una plataforma de modelado para todo el ciclo de modelado, en proyectos de:

Sistemas empresariales y de Tecnologıas de la Informacion.

Ingenierıa de Software y Sistemas.

Desarrollo en tiempo real en sistemas embebidos.

Enterprise Architect soporta todos los diagramas y modelos de UML 2.0; puede modelarse el diagrama de pro-

ceso de negocio, interfaces de usuario, configuraciones de hardware, intercambio de mensajes entre objetos,

entre muchas mas, estimar el tamano del proyecto horas de trabajo, capturar y trazar los requerimientos, recur-

sos, defectos y requisitos de cambio. Ademas es una herramienta progresiva que soporta todos los aspectos del

ciclo de desarrollo, proporcionando una trazabilidad completa desde el analisis de requerimientos del sistema,

diseno, implementacion prueba y soporte, basado en modelado UML, SysML, ademas de algunos estandares

abiertos.

Enterprise Architect cuenta con una amplia gama de estandares industriales abiertos para disenar y modelar

sistemas como son:

UML

SysML (usado por L. Bassi para modelar y disenar maquinaria para manufactura [27])

BPMN

52


BPEL

SoaML

SPEM

WSDL

XSD

DDS

ArchiMate

Entre las caracterısticas principales. que ayudan al modelado y diseno de sistemas se encuentran:

Gestion de los Requerimientos. La plataforma brinda la posibilidad de personalizar la manera en la que

se documentan los requerimientos, enlazando los requerimientos con los detalles del diseno e implemen-

tacion, promoviendo ası una trazabilidad de los requerimientos a travez de las diferentes etapas de diseno

y construccion.

Modelado y analisis de Negocio. Enterprise Architect cuenta con diferentes metodos para modelar, usan-

do UML, los procesos de una empresa. El modelado de procesos puede combinarse con un analisis de

vacıos para detectar potenciales fallas en las soluciones propuestas.

Simulacion. La simulacion del modelo de comportamiento del sistema es soportada para:

• Maquinas de estado.

• Diagramas de Secuencia.

• Actividades del sistema.

Desarrollo de Sistemas. Las herramientas que Enterprise Architect provee para el desarrollo de sistemas

es muy completa, en estas se puede:

• Crear elementos de modelos UML para una amplia gama de propositos,

• Colocar dichos elementos en diagramas y paquetes.

• Crear conectores entre elementos.

• Documentar los elementos creados.

• Generar codigo para el software que se esta construyendo.

• Ingenierıa y re-ingenierıa de codigo en:

◦ C++

◦ C#

53


◦ Delphi

◦ Java

◦ Python

◦ PHP

◦ Visual Basic

Ingenierıa de Sistemas. La ingenierıa de sistemas es soportada con modelado de SysML, que soporta el

modelado desde la definicion de requerimientos usando la composicion de Bloques y Partes de SysML, a

traves de la simulacion de modelo parametrico.

Gestion de Proyectos. Las herramientas de Enterprise Architect para la gestion de proyectos incluyen:

• Asignacion y rastreo de recursos usando graficas de Gantt.

• Registro de eventos usando calendarios modelo.

• Definicion del flujo de trabajo del proceso.

• Historial de actualizaciones en clases y objetos.

Usando Enterprise Architect se puede sincronizar codigo y elementos del modelo para disenar y generar ele-

mentos de base de datos. Desde los modelos se puede exportar rapidamente documentacion de alta calidad en

un estandar industrial, formato RTF o en Microsoft Word para una presentacion final.

54

CAPITULO TERCERO

METODO DE DESARROLLO DEL

SISTEMA INTEGRAL DE MANUFACTURA

En este capıtulo se expone la metodologıa para el analisis y desarrollo de Sistemas Integrales de Manufactura,

adaptado principalmente del metodo para desarrollo de sistemas de software presentado por K. Kendall [63] y

D. Rosenberg [70], ası como otras fuentes dedicadas principalmente al diseno de sistemas de manufactura. El

objetivo de contar con una metodologıa para desarrollar sistemas de manufactura, presentada en este capıtulo,

es el de lograr un modelo de sistema basado en un lenguaje simple y comprensible para personas que no son

expertas en programacion, pero que forman parte del equipo de desarrollo de un sistema, logrando al final unifi-

car la comunicacion en el equipo de desarrollo, dotando a todos los miembros con una lingua franca o lenguaje

uniforme, de comunicacion.

En el presente trabajo se acuna el nombre de Sistema Integral de Manufactura para los sistemas desarrollados

bajo la metodologıa aquı desarrollada. El objetivo de la metodologıa para el desarrollo de sistemas es el de

integrar todas las disciplinas necesarias dentro de una sola plataforma, unificar el lenguaje de comunicacion y

tener un control total sobre el modelo del sistema. Tambien se promueve la documentacion del sistema con la

finalidad de realizar mejoras o modificaciones de forma mucho mas sencilla y sin tener que volver a cambiar

todo el modelo del sistema, utilizando para esto las propiedades del lenguaje Orientado a Objetos como la mo-

dularidad y la reutilizacion de objetos.

El proceso de desarrollo de sistemas de manufactura es iterativo ya que estos siempre se encuentran sujetos a

cambios y modificaciones, los motivos pueden variar pero el cambio continuo es inminente, por tanto, el desa-

rrollo del sistema siempre debe estar pensado para poderse adaptar de la mejor manera a modificaciones futuras,

tomando en cuenta al sistema ıntegro, sin fraccionarlo en partes tecnologicamente diferentes. Esto es, en la ac-

tualidad ante un cambio en una lınea de produccion se realizan las modificaciones de automatizacion/control

por un equipo tecnico, las modificaciones estructurales las realiza otro equipo logrando muy pocas veces la

55

3.1. IDENTIFICACION DE LOS PROBLEMAS, OPORTUNIDADES Y OBJETIVOS

integracion de ambos con el sistema de procesamiento de informacion de la empresa.

Como lo plantea D. Pratt [17], es posible hacer una primera clasificacion, para modelar, en los elementos de un

sistema como sigue:

Objetos fısicos: son los objetos con su correspondiente tangible con el sistema del “mundo real”

Objetos de informacion: son objetos que pueden o no tener su correspondiente en el “mundo real” pero

que guardan interes por la informacion que poseen.

Objetos de control/decision: son objetos logicos que tipicamente no cuentan con correspondiente tangi-

ble, cuyas funciones son (1) evaluar el estado del sistema, (2) ejecutar un algoritmo logico y (3) senalar

la accion apropiada a ser tomada.

El proceso de desarrollo de sistemas se encuentra mas o menos estandarizado, salvo por ligeras variantes que

muestran diversos autores, como ejemplo: K. Kendall y D. Rosenberg [63,70], respectivamente; siendo iterativo

el proceso de desarrollo de un sistema ( Figura 3.1) y se divide en 7 fases:

Identificacion de los problemas, oportunidades y objetivos.

Determinacion de los requerimientos del sistema.

Analisis de las necesidades del sistema.

Diseno preliminar del sistema.

Diseno detallado del sistema.

Revision crıtica del diseno.

Implementacion y evaluacion del sistema

3.1. Identificacion de los problemas, oportunidades y objetivos

Es la primera fase del proceso de desarrollo, donde el equipo de diseno debe identificar correctamente los pro-

blemas que presenta el sistema a desarrollar, ası como las oportunidades de mejoras que el sistema actual puede

representar. El equipo de diseno analiza el problema desde la perspectiva de las necesidades de los usuarios y la

funcionalidad que estos buscan en el sistema de manufactura.

Lo primero que se debe definir es que se trata de resolver con el sistema de manufactura. En esta etapa el usua-

rio final del sistema debe proporcionar una descripcion general de las necesidades que se requiere cubrir y los

resultados que requiere obtener. En esta fase las actividades principales son: entrevistas a los involucrados en la

56

CAPITULO 3. METODO DE DESARROLLO DEL SISTEMA INTEGRAL DE MANUFACTURA

Figura 3.1: El ciclo en el proceso de desarrollo de sistemas

empresa, sintetizar el conocimiento adquirido, estimar el alcance del proyecto y documentar los resultados que

se buscan.

El resultado de esta fase puede ser un informe, tanto para los usuarios como para el equipo del diseno, donde

se detalle la definicion del problema y se sinteticen los objetivos. Este es el primer acercamiento al problema a

resolver, por lo que los involucrados en el diseno del sistema deben obtener la mayor cantidad de informacion

posible acerca problema, si ya existe una solucion poder hacerla mas eficiente y en caso de no existir tal, poder

proponer una solucion lo mas acertada posible.

3.2. Determinacion de los requerimientos del sistema

El usuario, con base en sus necesidades, proporciona los requerimientos funcionales del sistema. En sistemas

muy complejos o extensos, los disenadores pueden descomponer al modelo del sistema en varias partes y je-

rarquizar a estas. Todo esto con el fin de que el modelo preliminar sea mas comprensible para los usuarios y

disenadores con el objetivo de poder explorar, por partes, las necesidades del sistema para lograr un modelo lo

mas detallado posible.

Esta etapa puede dividirse en tres fases, que se definen como sigue:

Requerimientos funcionales

Modelado de dominio

Requerimientos de comportamiento (Modelado de casos de uso)

57

3.2. DETERMINACION DE LOS REQUERIMIENTOS DEL SISTEMA

3.2.1. Requerimientos funcionales

Define lo que el sistema es capaz de hacer. El proceso para completar esta fase se hace normalmente desde las

generalidades hasta los particulares, la idea es ir presentado bosquejos o borradores a los involucrados en el

proceso hasta lograr una definicion lo mas precisa de los requerimientos funcionales del sistema.

Al comienzo del proyecto, los disenadores deben entrevistarse con la persona que este financiando el mismo,

con los usuarios finales, y hasta con los proveedores o demas dependientes del sistema. Es de esperar como

resultado de estas reuniones un documento donde se explique la funcionalidad buscada en el sistema. Puesto

que este documento es redactado conforme la informacion sobre el sistema va fluyendo, este tiende a no tener

una estructura definida, misma que debe de irse refinando conforme avanza esta etapa.

Como recomendaciones para ayudar a completar esta fase, se mencionan:

1. Usar una herramienta donde puedan relacionarse y rastrearse entre requerimientos y casos de uso.

2. Enlazar los requerimientos con casos de uso.

3. Tener cuidado en la separacion entre los detalles funcionales y las especificaciones de comportamiento.

4. Documentar al menos una prueba para cada requerimiento.

5. Tener en cuenta que los requerimientos son los pilares del sistema, al momento de modelar.

6. Distinguir entre los diferentes tipos de requerimientos.

7. En ocasiones en conveniente usar ejemplos al momento de escribir los requerimientos funcionales. Pueden

ayudar a que personas involucradas no expertas comprendan mejor el funcionamiento del sistema.

Una vez completos los requerimientos, es indispensable analizarlos nuevamente, con la finalidad de crear un

primer boquejo de los requerimientos de funcionalidad, mejor conocidos como casos de uso.

3.2.2. Modelado del dominio

En esta fase es conveniente crear un glosario/diccionario sobre los terminos usados en el sistema. El proposito

de este glosario es asegurarse que todos los involucrados comprenden el problema sin que existan terminos

ambiguos.

En el modelo de dominio se define el alcance y sienta las bases para construir los casos de uso. Tambien se pro-

vee un vocabulario comun que posibilita una comunicacion clara entro los miembros del equipo de diseno. De la

misma forma que en la fase anterior, en este caso tambien existen diferentes recomendaciones para completarla:

58


1. El enfoque debe estar en objetos reales.

2. Es conveniente usar las relaciones de generalizacion y agregacion para mostrar las dependencias entre los

objetos.

3. Para evitar modelos rebuscados, se recomienda no usar mas de dos horas para realizar un bosquejo del

modelo de dominio, puede irse depurando en varias sesiones.

4. Organizar las clases alrededor de las abstracciones clave en el dominio del problema.

5. Es recomendable hacer el dominio del modelo antes de documentar los casos de uso; se evitaran nombres

ambiguos.


Esta es una de las fases cruciales en el diseno del sistema, pues aquı se definira el comportamiento de este,

ası como su interaccion con el usuario, resultando en modelos de flujo de informacion y datos, decisiones sobre

los dispositivos a utilizar, etc.

D. Rosenberg [70] hace la siguiente lista de recomendaciones para documentar y modelar los casos de uso:

1. La descripcion de los casos de uso no debe ser mayor a los dos parrafos.

2. Organizar los casos de uso con actores y diagramas de casos de uso.

3. Escribir los casos de uso en voz activa.

4. Escribir los casos de uso usando un flujo de evento/respuesta, describiendo ambos lados del dialogo

usuario/sistema.

5. Escribir el caso de uso en el contexto del modelo de objeto.

6. Referenciar el dominio de clases por su nombre.

En esta etapa es posible elaborar un diagrama de clases del sistema. Despues de descomponer al sistema se

pueden asociar los elementos comunes dentro de una misma clase. Cada clase u objeto debe de jerarquizarse

segun el orden, y su grado de complejidad debido a su composicion de otros objetos. En la Figura 3.2 se muestra

un ejemplo del diagrama de clases de una pequena maquina, en este caso la relacion entre los diferentes objetos

es de pertenencia. En esta etapa no es necesario profundizar demasiado en el modelado de clases ya que se trata

simplemente de lograr una vision clara y global del sistema.

59

3.3. ANALISIS DE LAS NECESIDADES DEL SISTEMA

Figura 3.2: Ejemplo de un diagrama de clases de un sistema de manufactura

3.3. Analisis de las necesidades del sistema

Un enfoque practico para esta etapa es descomponer, antes de todo, el sistema en bloques funcionales para poder

identificar con esto a los objetos fısicos que llevan a cabo cada operacion unitaria. Una vez definido el modelo

estructural y el diagrama de clases, como el modelo de comportamiento con el diagrama de casos de uso, el

equipo de diseno puede comenzar a definir mas a profundidad los requerimientos del sistema.

Con la vision global que proporciona el diagrama de clases, cada disenador puede desarrollar sus propios dia-

gramas a la profundidad o nivel de jerarquıa que le sea necesario. En el caso del disenador del sistema de

control electronico necesitara definir los elementos mınimos funcionales (motores, drivers, etc.) necesarios para

el correcto funcionamiento del sistema. Las herramientas CASE permiten describir cada elemento incorporado

en el modelo, con esto se logra la posibilidad de documentar, por ejemplo, cada motor, su modelo, fabricante,

costo, etc. y en el futuro se puede tener facil acceso a esta informacion, reutilizarla o hasta actualizarla de forma

sencilla.

En este punto, los disenadores tienen los datos necesarios para encontrar los dispositivos, elementos mecanicos

y software que el sistema requiera, todo esto documentado y con su debida justificacion, teniendo ası un mayor

control en la planificacion durante el desarrollo del sistema. Cabe resaltar la importancia de documentar cada

dispositivo utilizado en el sistema ya que en caso necesario, de haber algun cambio, es mucho mas sencillo

realizar modificaciones usando la informacion y el modelo estructural del sistema.

Es necesario tambien identificar los objetos del dominio del sistema, ya que estos pueden ser:

Objetos fısicos: dentro del modelo, representan a los dispositivos fısicos como actuadores, sensores,

60


motores, etc.

Objetos de abstraccion de datos: modelan a las entidades del mundo real encapsulando los datos o

informacion necesaria.

Objetos de control: son objetos abstractos con diferentes estados y controlan el comportamiento de otros

objetos.

Objetos de algoritmo: encapsulan un algoritmo usado en el sistema.

Objetos de funcion de usuario: modelan la funcion de los usuarios en la aplicacion.

El proceso de manufactura se descompone en pasos funcionales para identificar las entidades fısicas del siste-

ma. Estos modulos deben asociarse biunıvocamente con algun modulo de software de control, encapsulando el

codigo de control logico y de supervision dedicado especıficamente a esa funcionalidad del modulo.

El diagrama de secuencia, tambien llamado Workflow de captura de comportamiento, como el que se muestra

en la Figura 2.13 es de mucha utilidad en esta fase para modelar la interaccion que tienen los objetos del sis-

tema entre sı, la seleccion de los diferentes dispositivos del sistema depende en gran medida de la forma en la

que estos tienen que interactuar con otros, a veces hay incompatibilidades con los protocolos de comunicacion,

niveles de voltaje, acomplamientos, por mencionar algunos.

Dicho lo anterior, en esta etapa se selecciona el equipo, comenzando por los requerimientos tecnologicos en-

contrados, listando caracterısticas como capacidad, confiabilidad, flexibilidad, etc.

3.4. Diseno preliminar del sistema

La importancia de realizar el proceso de desarrollo mediante una herramienta CASE, es que para cada paso y

cada decision que se deba tomar, el usuario tiene facil acceso a la documentacion y en caso de ser necesaria una

modificacion se realizara en tiempo y a bajo costo.

Esta etapa es la indicada para realizar el diseno exploratorio necesario para comprender los requerimientos, de-

purando las ambiguedades que se han ido acarreando desde los pasos anteriores con los diagramas de casos de

uso y el analisis de requerimientos. Ademas debe asegurarse tambien el correcto enlace entre los requerimientos

de comportamiento con los objetos del sistema ya determinados.

La etapa de diseno se puede tomar tambien como un proceso iterativo, donde a partir de las especificaciones de

modelado se llevan a cabo los siguientes pasos :

Definicion de las capacidades de los recursos

61

3.4. DISENO PRELIMINAR DEL SISTEMA

Representar los recursos en forma de entidades funcionales y componentes activos.

Probar los aspectos dinamicos de los recursos a traves de simulaciones y prototipos rapidos.

Revisar las especificaciones y re-ejecutar los pasos previos, hasta lograr un solucion satisfactoria.

Reemplazar los recursos del modelo por el recurso fısico actual.

En general despues de determinar los objetos que constituyen al sistema, es importante tomar en cuenta los

siguientes puntos para el modelado y descripcion del sistema:

Desarrollar la jerarquıa,de los objetos y las clases por agregacion.

Definir las interfaces entre los objetos.

Especificar cada objeto.

Determinar las variaciones del dominio.

Definir las dependencias de los objetos.

Generar las especificaciones del sistema objetivo

Se debe decidir acerca de la estructura de los subsistemas e interfaces, y como se distribuira el sistema. Tam-

bien se definen las caracterısticas finales que deben tener los objetos, estableciendo cuando estos se encuentran

activos o pasivos y las operaciones de cada clase y los parametros de operacion de estas. Es necesario definir las

interfaces de clases, para cada subsistema, disenar las clases con ocultamiento de informacion.

Como todo proceso de manufactura es necesaria una interfaz, esta conecta al usuario con el sistema por lo que

es extremadamente importante. La interfaz de usuario se disena con ayuda de los usuarios para asegurar que el

sistema sea perceptible, legible y seguro, ası como atractivo y amigable. Dentro de la interfaz se deben contem-

plar todos los datos que requiere el sistema para funcionar, ası como mostrar los datos requeridos del proceso

en tiempo y forma adecuados.

Debe definirse el comportamiento de los modulos u objetos desde un punto de vista interno para manejo de

eventos, y desde un punto de vista externo para secuencias y senales de entrada/salida.

En esta etapa tambien se contempla el sistema de informacion o la base de datos que se usara, recordando la

importancia propia de la informacion que genera un sistema de manufactura. Las mediciones de las variables

necesarias en el proceso deben de conectarse al sistema de informacion para su posterior procesamiento y mues-

treo.

62


Hasta esta etapa, los diagramas del sistema (de clases, objetos, casos de uso) deben poder mostrar el comporta-

miento requerido del sistema tomando en cuenta las siguientes recomendaciones:

1. Asegurarse de que se puede trazar un flujo de datos entre los objetos y la interfaz.

2. Asegurarse de que cada caso de uso cubre ambos lados del dialogo entre usuario y sistema.

3.5. Diseno detallado del sistema

Hasta esta etapa, todo ha sido desarrollado dentro de una plataforma CASE. Si se ha tenido el cuidado de descri-

bir todo los elementos del sistema como los requiere la herramienta, la generacion de la documentacion solo se

vuelve una tarea de rutina. Como los usuarios estan involucrados desde el principio, la fase de documentacion

debe lidiar con las preguntas que hicieron y resolvieron junto con los disenadores.

La herramienta principal para realizar el diseno detallado es el uso del diagrama de secuencia. En el diseno

Orientado a Objetos es necesario encontrar el lugar optimo donde funcione cada clase, esto se hace mediante

flechas de mensaje en los diagramas de secuencia permitiendo ası a una herramienta de modelado asignar au-

tomaticamente una operacion a la clase del objeto que recibe el mensaje, como ejemplo vease la Figura 2.14.

Como lo hace notar D. Rosenberg [70], el diagrama de secuencia persigue tres grandes objetivos:

Asignar el comportamiento de las clases del sistema.

Mostrar detalladamente como interactuan las clases entre ellas durante la secuencia del sistema.

Finalizar la distribucion de las operaciones entre las clases.

La documentacion indica a los usuarios como deben usar el software y los diagramas quedan a disposicion para

proximos cambios y modificaciones. Al seguir esta metodologıa, y contando con la documentacion del sistema

se puede incrementar eficiencia en el desarrollo de sistemas de manufactura al reducir los tiempos de analisis y

diseno, haciendo que el ciclo aquı presentado le tome menor tiempo iterar.

3.6. Revision crıtica del diseno

Debido a la naturaleza evolutiva del paradigma de diseno OO, los modelos de este comienzan con representa-

ciones informales de requisitos del sistema y evolucionan hacia un modelo de clases detallado, conexiones y

relaciones entre clases, diseno del sistema y asignaciones. En cada etapa, los modelos pueden probarse en un

intento por descubrir los errores antes de que se propaguen a la proxima iteracion.

63

3.7. IMPLEMENTACION Y EVALUACION DEL SISTEMA

Existen muchas y diferentes razones para llevar a cabo la revision crıtica del sistema, justo antes de implemen-

tarlo, pero aquı se presentan las principales segun D. Rosenberg [70]:

Asegurar que el como, del diseno detallado, coincida con el que, especificado en los requerimientos.

Especıficamente, para cada caso de uso se necesita asegurar la relacion entre los casos de uso con el

diagrama de secuencia.

Revisar la calidad del diseno, ayudado por lo menos con un experto en el sistema desarrollado.

Verificar la continuidad de los mensajes. Es recomendable checar la direccion de los mensajes en el

diagrama de secuencia para asegurarse de que el diagrama especifique el control de los objetos.

Las pruebas al sistema deben hacerse antes de ponerlo a producir, el mantenimiento y la documentacion de este

comienza en esta fase y se debe llevar a cabo de manera rutinaria durante todo el tiempo que el sistema se en-

cuentre en produccion [63]. Una gran parte del trabajo que realizara el equipo de diseno en este caso, sera el de

brindar el mantenimiento o las modificaciones necesarias, esto se traduce en una gran inversion de la empresa,

por lo que el ahorro de tiempo en paros es de suma importancia.

Es un error comun asignar algun atributo extrano a alguna de las clases. Se especifican entonces dos operaciones

para manipular el atributo. Una mala interpretacion de la clase puede conducir a relaciones de clases innecesa-

rias o incorrectas. Si el problema pasa la etapa de descripcion del modelo y se usa este para la codificacion de

los objetos como controladores, interfaces y otros, se realizara un esfuerzo y desgaste de energıa considerable

para generar el codigo que implementara una o mas operaciones innecesarias.

3.7. Implementacion y evaluacion del sistema

Es importante asegurar una estricta relacion entre las entidades de modelado y las caracterısticas del sistema

al momento de la implementacion. Esto con el fin de que el modelo sea comprensible para cualquier persona

en un futuro, ya sea con fines de modificar el sistema, colocar extensiones a este o reconfigurar el sistema de

manufactura.

En esta ultima fase hay que capacitar a los usuarios que operaran el sistema. Se entrega la documentacion del

sistema y el modelo de este. Es de esperar que para cuando termine esta fase, se requieran realizar algunas

mejoras o cambios, mismos que se podran realizar de forma mas sencilla.

64

CAPITULO CUARTO

DESARROLLO DE LA LINEA PROTOTIPO

Este capıtulo describe las actividades realizadas durante el desarrollo del sistema piloto de manufactura de acuer-

do a la metodologıa desarrollada en el capıtulo anterior. Se presentan los documentos y diagramas desarrollados

y una descripcion de cada uno de estos.

4.1. Identificacion de los problemas

La primera etapa en el desarrollo del sistema fue el acercamiento con el usuario final que informo que el sistema

serıa usado para realizar pruebas y desarrollar nuevos productos y procedimientos de produccion. Por lo tanto,

el sistema debe ser lo suficientemente flexible para agregar o suprimir modulos para procesar la materia prima,

sin que esto signifique una completa reestructuracion y reprogramacion del software de control y de adquisicion

de datos.

Es tambien importante el procesamiento de los datos, ya que estos seran analizados posteriormente a los experi-

mentos en el sistema, por ello la importancia de asegurar un orden en los datos, usando fechas e identificadores

de experimentos.

Durante ese primer acercamiento, se generaron dos documentos que tecnicamente son simples ya que su

proposito fue el de poner bajo el mismo plano al usuario y al equipo de diseno. En los documentos conteni-

dos en los anexos se observa una descripcion general del sistema, las etapas en las que se divide, la secuencia y

tambien las variables que el usuario desea medir y/o controlar.

4.2. Determinacion de los requerimientos

El sistema desarrollado se diseno a partir de las necesidades y los requerimientos funcionales definidos por el

usuario final. El equipo de diseno planteo varias iteraciones de modelado hasta que el usuario quedo satisfecho

65

4.2. DETERMINACION DE LOS REQUERIMIENTOS

con el concepto presentado.

El prototipo es una lınea de produccion piloto, lo suficientemente flexible para poder adaptar diferentes parame-

tros que afectan al producto, ya que pretende usarse para la elaboracion de pequenos lotes de productos nuevos.

El prototipo desarrollado para la empresa PEPSICO sera usado dentro del proyecto de investigacion CICATA

Qro-PEPSICO para desarrollar una nueva tecnica de implantacion de condimentos a diversos productos de la

lınea SABRITAS.

La tecnica de rociado, para la implantacion de condimentos en polvo al material base de la botana, se desa-

rrollo anteriormente en CICATA. Hasta la fecha esta tecnica no se ha usado para producir lotes de suficiente

tamano para poder realizar una prueba sensorial ante un panel de expertos que determinen la viabilidad de pro-

duccion en masa de nuevos productos.

La tecnica de implantacion de polvos sobre el material base se divide en tres etapas principales, que dentro de

la semantica de UML representan las clases:

Rociado

Carga

Recubrimiento

Rociado

El rociado es la primera etapa del proceso que se lleva a cabo dentro de un recipiente llamado bombo donde el

producto base es impactado con partıculas a alta velocidad con el fin de modificar la superficie de este. En esta

parte del proceso se necesita tener control de la presion del subsistema eductor encargado de regular la presion

del aire y del flujo de alimentacion de las partıculas.

El desarrollo de esta tecnica fue el resultado de una investigacion previa, donde se encontro que al impactar al

material base de la botana con partıculas del mismo condimento se modificaba superficialmente la base creando

microporos que posteriormente son aprovechados en la etapa de carga.

Carga

En la carga, tambien llevada a cabo en el bombo a una velocidad angular constante, los elementos base se su-

mergen en una gran cantidad de partıculas logrando que el elemento base se impregne de la mayor cantidad de

66

CAPITULO 4. DESARROLLO DE LA LINEA PROTOTIPO

estas. En esta etapa las variables a medir son la velocidad angular del bombo y la duracion de esta etapa.

Esta etapa es basicamente la misma que se ha usado siempre en la elaboracion de estos productos, la diferencia

radica en que los microporos en el material base creados en la etapa de rociado permiten que el condimento

penetre al material, logrando con esto insertar el sabor al material, sin necesidad de usar aceite.

Recubrimiento

La ultima etapa, el recubrimiento, consiste en aplicar a los elementos impregnados en la etapa de carga, mien-

tras giran en un tumbler, una mezcla viscosa para sellar las partıculas atrapadas dentro de los elementos base

ası como dotar al producto de un acabado final.

Es importante tener un control preciso de la temperatura de la mezcla ya que debido a sus propiedades alimenti-

cias esta tiende a degradarse con demasiada facilidad a temperaturas fuera del rango de 43 ± 3o C. Tambien se

debe tener el control sobre la presion neumatica a la que se aplica el recubrimiento, ası como el flujo volumetri-

co de la mezcla, ya que de estas depende la cantidad de condimento y aceite que contenga el producto.

La Figura 4.1 es un diagrama de requerimientos construido en Enterprise Architect a partir de la definicion de

estos como se observa en la Figura 4.2 , donde ademas de proporcionar un entorno grafico donde se muestren los

requerimientos del sistema, tambien se describe a cada uno ya que al final los requerimientos tambien formaran

parte de la documentacion del sistema.

4.2.1. Secuencia del proceso de produccion

1. Antes de comenzar al experimento el usuario registra su nombre (Nombre de usuario), ası como el tıtulo

que ha sido asignado al experimento (Titulo de Experimento). La fecha y la hora seran obtenidas del

sistema operativo de la computadora.

2. El usuario registrara en la interfaz la cantidad de material base (mb) ingresado al proceso. Asignara desde

la interfaz de usuario la presion neumatica del eductor (Pe), la velocidad angular del bombo (ωB), el flujo

masico del polvo (fmc) y el tiempo que se desea exponer el material base al rociado (tRO). Las variables

flujo de entrada de aire (fa), humedad (H) y temperatura (T) se comenzaran a monitorear automaticamente

una vez que se de inicio al proceso.

3. Cuando termine el rociado, el usuario tomara al azar un ejemplar del material base para obtener datos cua-

litativos de este, mismos que seran integrados manualmente al sistema. Tambien se obtendran imagenes

del mismo ejemplar y estas seran almacenadas como parte de las variables del experimento.

67


Figura 4.1: Diagrama de requerimientos funcionales del sistema realizado en Enterprise Architec

4. Antes de comenzar la etapa de carga, el usuario debe indicar al sistema la cantidad de condimento que

se ingresara al bombo (mc), el tiempo que desea dure la etapa de carga (tc) y la velocidad que tendra el

bombo (ωB2). Una vez hecho lo anterior, comenzara a girar el bombo.

5. De la misma manera que la etapa anterior, una vez terminada la etapa de carga se obtendra al azar un

ejemplar del producto para obtener datos e imagenes de este que se ingresaran tambien a la base de datos

del sistema.

6. Para comenzar con la etapa de recubrimiento, el usuario debera indicar la velocidad angular del tumbler

(ωT ), el flujo volumetrico de la mezcla (υm), el tiempo que se aplicara el recubrimiento (tRE) la tempe-

ratura de la mezcla (Tm) y la presion neumatica para el recubrimiento (PR).

7. Una vez transcurrido el tiempo de recubrimiento (tRE), el sistema se detendra y se indicara el fin del

proceso. Los datos obtenidos del experimento se guardaran en un archivo generado automaticamente y el

producto podra ser retirado para su posterior envase.

Con base en los datos y requisitos proporcionados por el usuario final, se elaboro un diagrama previo sobre el

proceso, donde se detalla la informacion que necesita cada etapa del proceso, la informacion que debera ser

medida y el flujo del material dentro del proceso, vease la figura 4.3, ası como tambien la informacion que se

68


Figura 4.2: Captura de pantalla de diagrama de requerimientos en Enterprise Architect

obtendra del producto entre cada una de las etapas (figura 4.4).

Figura 4.3: Esquema del proceso como lo propone el usuario final

4.2.2. Modelado del dominio

Como se menciono en el capıtulo anterior, el modelado de dominio pretende convertirse en un diccionario o

glosario con la definicion de terminos cruciales del sistema, con la finalidad de evitar confusiones entre los in-

69


Figura 4.4: Imagenes y datos obtenidos del producto entre cada etapa

volucrados en el desarrollo del sistema. Para el caso de este trabajo, se redacto un glosario incluido en la seccion

del mismo nombre, donde se explican de forma mas detallada los terminos importantes del sistema.


Los casos de uso fue el siguiente paso en el modelado del sistema, la herramienta CASE Enterprise Architect

provee una excelente plataforma donde modelar los casos de uso. De manera relativamente sencilla se pueden

describir graficamente los casos de uso, el actor que los desencadena y la relacion entre los diversos casos de

uso. El diagrama de casos de uso se muestra en la figura 4.5.

Enterprise Architect permite que, ademas de la representacion grafica de los casos de uso, tambien se detalla

cada uno de los casos de uso, las actividades necesarias y quien las realiza. En la Figura 4.6 se muestra la des-

cripcion general de un caso de uso, tambien pueden agregarse algunos requerimientos.

70


Figura 4.5: Diagrama de casos de uso del sistema implementado

Figura 4.6: Captura de pantalla con la descripcion de uno de los casos de uso del sistema

71

4.3. ANALISIS DE LAS NECESIDADES DEL SISTEMA

Figura 4.7: Descomposicion del diagrama en sus clases principales: Rociado, Carga y Recubrimiento

4.3. Analisis de las necesidades del sistema

Como se indica en el metodo descrito en el tercer capıtulo, en esta etapa es necesario descomponer al sistema

en bloques funcionales y con ello poder identificar los objetos fısicos que el sistema requiere. La Figura 4.11

muestra el diagrama de clases del sistema, descompuesto primero por etapas, luego por subsistemas hasta termi-

nar en las especificaciones de cada dispositivo fısico. A continuacion se describe con mayor detalle el diagrama

de clases del sistema.

Como se muestra en la Figura 4.7, las clases de mayor jerarquıa son las que definen a cada etapa del proceso:

Rociado, Carga y Recubrimiento. Dentro de cada una se encuentran definidos, en la parte central, los atributos

de estas. En la parte de abajo se definen las operaciones propias de cada clase, mismas que seran posteriormente

relegadas a las subclases u objetos que contenga cada una de las clases mayores. Las relaciones de las clases

con el sistema completo son relaciones de pertenencia.

La descomposicion de las etapas de Rociado y Carga se muestra en la Figura 4.8. ambas comparten al elemento

Giro Bombo, que a su vez se descompone en los componentes fısicos de Motor AC y Driver AC. Lo anterior

es una de las ventajas brindadas por un modelo OO, ya que requiere definir solamente una vez un objeto y este

podra usarse las veces que sea necesario dentro del sistema. Los objetos de menor jerarquıa son los componentes

fısicos del sistema que tambien tienen definidos sus atributos y operaciones.

Finalmente, las subclases y objetos definidos para la etapa de recubrimiento se muestran en la Figura 4.9. Esta

etapa es la mas compleja en cuanto a componentes, abstractos y fısicos, se refiere, ya que tiene que considerar

diferentes variables de control y de adquisicion de datos.

Dependiendo de las competencias de cada uno de los involucrados en el diseno del sistema, cada uno podra desa-

72


Figura 4.8: Clases y objetos definidos para las etapas de Rociado y Carga.

rrollar sus propios diagramas con la profundidad o jerarquıa que requiera. En el caso del diseno del sistema de

control, se requiere profundizar hasta el nivel de cada dispositivo con sus atributos y operaciones.

En la Figura 4.12 se muestra la descompocision de la etapa de rociado, hasta llegar a los componentes electroni-

cos y mecanicos. Tambien se discrimina entre el tipo de elementos u objetos necesarios, entre elementos de

informacion, las operaciones y los objetos fısicos, estratificando ası el diagrama en tres planos.

Ademas, gracias al uso de Enterprise Architect , el disenador cuenta tambien con la descripcion de cada clase,

de sus atributos y operaciones ya que para declarar cada clase u objeto, el software brinda posibilidad de des-

cribir lo mas preciso posible cada clase. (vease figura 4.10)

73


Figura 4.9: Clases, subclases y objetos definidos para la etapa de Recubrimiento

4.4. Diseno preliminar del sistema

Con el diseno preliminar, se comienza a suponer como interactuaran las clases y objetos entre ellos, pero la

tarea de precisar esas relaciones se lleva a cabo hasta la siguiente etapa, el diseno detallado.

La primera etapa del diseno preliminar del sistema consistio en, una vez determinados los dispositivos a utilizar,

realizar una tabla donde se observen las caracterısticas principales de cada uno. Con esto se busca poder realizar

un filtro mas sobre la decision en los dispositivos a usar. Debido a los diferentes tipos de elementos involucrados

en este proyecto, se realizaron tablas con los elementos similares.

En las tablas 4.1, 4.2 y 4.3 se resumen de manera concisa las caracterısticas mas importantes de los dispositivos

a usar. Como todo sistema, en esta etapa lo mas importante son las relaciones entre los diferentes dispositivos.

74


Figura 4.10: Descripcion de cada una de las clases dispuestas en el diagrama

Tabla 4.1: Caracterısticas principales de los motores usados.

Dispositivo Rango de velocidad Potencia Torque Alimentacion

Motor para bombo 0 - 1140 rpm 1 HP NA 3F - AC

Motor para tumbler 0 - 1140 rpm 1 HP NA 3F - AC

Motor alimentador 0 - 170 rpm 4.22 W 1.5 Kg/cm 12V- DC

En las tablas se puede comparar de forma mucho mas sencilla la compatibilidad de comunicacion, alimentacion

electrica, temporizacion y hasta unidades de medicion.

Como se describio en el capıtulo anterior, en la metodologıa de diseno de sistemas integrales de manufactura, es

importante desarrollar la jerarquıa de los objetos, o dispositivos, y las clases por agregacion. En la Figura 4.11

se muestran tres niveles de jerarquıa del sistema, las relaciones por agregacion segun la semantica de UML se

representan con lineas con una de sus terminales con un rombo; el rombo esta conectado a la clase u objeto de

mayor jerarquıa.

La plataforma Enterprise Architect permite al disenador del modelo poder indicar y describir los atributos y las

operaciones de cada objeto y clase, con una descripcion precisa de los atributos y operaciones de cada objeto,

la tarea de programar, en cualquier lenguaje, el funcionamiento de cada bloque se convierte en una actividad

relativamente simple ya que la programacion se subdivide en pequenos modulos que al final adicionaran sus

operaciones e intercambiaran mensajes para cumplir con la funcionalidad del sistema.

75


Figura 4.11: Diagrama de clases de la lınea de manufactura prototipo76


Figura 4.12: Ejemplo de descomposicion de un sistema 77

4.5. DISENO DETALLADO DEL SISTEMA

Tabla 4.2: Caracterısticas principales de los controladores de motor.

Dispositivo Potencia Alimentacion Comunicacion

Controlador p/motor de bombo 2 HP 220 VAC Protocolos RS-485

Controlador p/motor de tumbler 2HP 220 VAC Protocolos RS-485

Controlador p/motor alimentador 10 W 12 VDC Voltaje analogico

Tabla 4.3: Caracterısticas principales de los dispositivos neumaticos.

Dispositivo Tipo Rango de Presion Alimentacion Conexion Comunicacion

Valvula proporcional p/eductor Proporcional 0 - 0.5 MPa 12 VDC NPT 1/4 Voltaje analogico

Valvula para recubrimiento Proporcional 0 - 0.5 MPa 12 VDC NPT 1/4 Voltaje analogico

Valvula de proceso On/Off 0 - 4 MPa 12 VDC NPT 3/8 Pulso electrico

Flujostato Digital Sensor -50kPa - 0.5MPa 12 VDC NPT 1/4 Voltaje Analogico

4.5. Diseno detallado del sistema

El objeto de analisis en esta etapa es la secuencia de cada uno de los componentes del sistema. Como se acos-

tumbra en la metodologıa OO, se debe precisar la secuencia y la definicion de los mensajes que intercambian

los diferentes objetos.

En la Figura 4.13 se muestra el diagrama de secuencia de la lınea piloto. Dicho diagrama tambien se elaboro en

Enterprise Architect tomando como referencia los objetos ya especificados en las etapas anteriores. La im-

portancia de elaborar este diagrama no solamente termina con la parte grafica ya que tambien es parte de la

documentacion del sistema que describe el como, donde y cuando interactuan los objetos involucrados.

El unico actor, mostrado en el diagrama, es el operador, quien interactuara con el sistema de la manera ya des-

crita con los casos de uso. Los objetos dentro de este diagrama pueden ser de tres tipos: Actor/usuario, Objeto

Frontera, Objeto Entidad. En el diagrama de la Figura 4.13 se distingue el Actor que inicializa y prepara ca-

da etapa, el Objeto Frontera normalmente es la interfaz grafica existente entre el usuario y cualquier sistema y

tambien los Objetos Entidad, en este caso son los objetos fısicos que realizan algun trabajo durante la secuencia.

Es importante hacer notar que en este diagrama no se esta tomando en cuenta ningun objeto de control, ya se

que esta suponiendo que los elementos encargados del control se regulan de manera autonoma. UML no prohıbe

la incorporacion de estos elementos, ya que las acciones y controles se convierten en mensajes entre el objeto

de frontera y las entidades del sistema.

El Objeto frontera o interfaz realiza la comunicacion entre el usuario y los dispositivos del proceso ya que su

78


funcion es la de pedirle al operador informacion sobre las variables del proceso, procesar esta informacion y

enviarla al dispositivo que corresponda. El objeto entidad Temporizador es abstracto e interno ya que el usua-

rio no tiene acceso a este, el funcionamiento de este objeto se limita solamente a establecer intervalos de tiempo.

El objetivo final del diagrama de secuencia es poder mostrar como se cumple con el comportamiento de cada

caso de uso. En el caso de este sistema, puede hacerse la comparacion entre cada uno de los casos de uso

y estos se encuentran embebidos dentro del diagrama de secuencia. El diagrama de casos de uso expone el

comportamiento requerido, el diagrama de secuencia explica como lo logra cada entidad.

79

4.6. REVISION CRITICA DEL DISENO

Figura 4.13: Diagrama de secuencia del proceso desarrollado

4.6. Revision crıtica del diseno

Como se describio en el capıtulo anterior, esta etapa del diseno busca eliminar los posibles errores que se pu-

dieron haber acarreado hasta esta instancia en el modelado del sistema. La revision del modelo del sistema para

80


asegurar la congruencia entre los requerimientos (Figura 4.1) y el diseno detallado o el diagrama de secuencia

(Figura 4.13) se realizo la Tabla 4.4

Tabla 4.4: Revision los requerimientos del sistema vs el diagrama de secuencia

Requerimiento Manera de llevarlo a cabo

Control de presion en el eductor Mensaje de asignacion de presion a la valvula proporcional antes de

iniciar el rociado.

Tasa de alimentacion de polvo Mensaje de asignacion de voltaje proporcional a cierta velocidad al mo-

tor alimentador antes de comenzar el rociado.

Control de velocidad de bombo Mensaje de asignacion de velocidad al driver AC que controla al motor

acoplado al bombo antes de comenzar el rociado.

Control de velocidad del

Tumbler

Mensaje de asignacion de velocidad al driver AC que controla al motor

acoplado al tumbler antes de comenzar el recubrimiento.

Flujo volumetrico de slurry Mensaje de asignacion de velocidad, correspondiente al flujo volumetri-

co deseado, al motor acoplado a la bomba hidraulica que desplaza al

slurry.

Temperatura de slurry Mensaje para comenzar a calentar al slurry antes de comenzar el pro-

ceso. la etapa de recubrimiento no puede comenzar hasta que no reciba

el mensaje, por parte del control de temperatura, de que ya alcanzo la

temperatura adecuada.

Presion del sistema de aspersion Mensaje de asignacion de presion a la valvula proporcional antes de

comenzar el recubrimiento.

Control de tasa de alimentacion Mensaje de asignacion de velocidad al driver AC que controla al motor

acoplado a la banda de alimentacion de producto.

La relacion entre la Tabla 4.4 y el diagrama de secuencia 4.13 son los mensajes que senalan la interaccion entre

los diferentes objetos del sistema. El diagrama de secuencia representa el orden de ejecucion de cada objeto al

comenzar desde la parte superior hasta terminar el proceso en la parte inferior. Los mensajes entre los objetos

tambien indican la direccion de la comunicacion entre estos.

81

4.6. REVISION CRITICA DEL DISENO

82

CAPITULO QUINTO

MODELO DEL SISTEMA

5.1. Diseno del sistema en la plataforma Enterprise Architect

El objetivo de este trabajo es el de plantear el diseno conceptual de una lınea piloto de produccion usando len-

guaje UML, desde la plataforma Enterprise Architect. En este software se describe todo el proceso desde la

descripcion de cada etapa, la informacion requerida y la obtenida en cada proceso ademas de poder profundizar

hasta la descripcion de cada una de las partes mecanicas y dispositivos electronicos requeridos para el funcio-

namiento de cada proceso. La figura 5.1 muestra el diagrama del proceso desarrollado en Enterprise Architect.

Figura 5.1: Descripcion del proceso desarrollado en UML

Una vista rapida al diagrama de la figura 5.1 muestra el orden del proceso ası como el flujo del material. Pero

el objetivo principal de este diagrama es la descripcion completa del proceso, hecha dentro de cada uno de los

83

5.1. DISENO DEL SISTEMA EN LA PLATAFORMA ENTERPRISE ARCHITECT

objetos que representan procesos fısicos o informacion.

La primera etapa se muestra en la figura 5.2. Esta etapa consiste en la inicializacion del sistema por parte del

usuario, donde este proporciona datos sobre el experimento que comenzara. Datos como el nombre de usua-

rio, tipo de experimento a realizar y fecha se usaran para generar un codigo del experimento y con esto poder

identificar facilmente los datos relacionados con el experimento en el futuro. Tambien se le solicita al usuario

datos mas tecnicos como la presion de aire deseada durante el experimento, la cantidad de polvo para rociado

que se ingresara, el tiempo de exposicion de los collets al rociado, etc. Una vez que se ingresen estos datos

podra comenzar la etapa de rociado del producto. La figura 5.3, muestra el contenido del bloque de informacion

de entrada para inicalizar el sistema, donde se observa toda la informacion y datos que el sistema solicita al

usuario para comenzar.

Figura 5.2: Primera etapa del proceso disenado

La etapa de rociado consiste en impactar a los collets con una mezcla de polvo y aire a presion. Esta etapa

requiere de tres sistemas: dosificador, eductor y mezclador, los cuales se encuentran activos paralelamente. En

la figura 5.4 se observa que para describir la etapa no se usa solamente la descripcion fısica de la etapa, si no

tambien se indica tanto la informacion que cada proceso requiere como la informacion obtenida en cada proceso.

Cada uno de los bloques es descrito de la manera mas detallada posible, como se muestra en la figura 5.5, una

primera vista del contenido del bloque muestra la descripcion de este, se describe su funcionamiento dentro del

sistema ası como la interaccion que tiene con el usuario u otros procesos del sistema. La figura 5.6 muestra la

segunda etapa del bloque donde se detalla cada uno de los componentes fısicos del proceso, de igual manera

la descripcion es lo mas detallada posible pudiendo llegar incluso a indicar el proveedor o fabricante de cada

84

CAPITULO 5. MODELO DEL SISTEMA

Figura 5.3: Vista del bloque de Informacion de entrada para inicializar el sistema

dispositivo y demas especificaciones tecnicas sobre los elementos individuales del proceso.

Figura 5.4: Etapa de Rociado

Pero ningun sistema puede quedar descrito de forma adecuada sino hasta que se toma en cuenta la informacion

que procesa cada uno de los procesos involucrados. En la figura 5.7 se muestra el contenido del bloque de infor-

macion de entrada al proceso de eductor, estos son los datos que el proceso necesita para funcionar de la manera

indicada por el usuario.

De igual forma que se requiere informacion de entrada a cada proceso, es deseable obtener informacion o datos

85


Figura 5.5: Contenido del bloque del sistema de Eductor en la de descripcion de bloque

Figura 5.6: Contenido del bloque del sistema de Eductor en la descripcion de las partes que lo conforman

de interes de los procesos, la figura 5.8 muestra el contenido del bloque de informacion de salida del proceso

de eductor. Dentro de dicho bloque pueden describirse detalladamente todos los datos requeridos, su formato,

tiempo de muestreo, encriptacion, etc.

En el diagrama de la figura 5.1 puede observarse tambien que existe un bloque entre cada una de las etapas y

es donde se describen las caracterısticas del subproducto de cada etapa ası como tambien las acciones que debe

de llevar a cabo el usuario para manipular el subproducto. En el caso del prototipo disenado requiere que se

obtengan imagenes y datos analıticos del producto despues de cada etapa.

La figura 5.9 muestra el contenido del bloque de informacion de salida del producto de la etapa de rociado,

aunque un bloque similar se usa para el producto de cada etapa. Este bloque de informacion describe el tipo de

86


Figura 5.7: Contenido del bloque de informacion de entrada al proceso de eductor

Figura 5.8: Contenido del bloque de informacion de salida del proceso de eductor

datos que se obtendran ası como la forma en que el sistema los usara posteriormente.

87


Figura 5.9: Contenido del bloque de informacion obtenida del producto de la etapa de rociado

La siguiente etapa se representa en la figura 5.10, la etapa de carga consiste solamente en mantener giran-

do cierto tiempo el bombo donde se encuentran los collets y una cantidad de condimento determinada por el

usuario. La velocidad angular del bombo y el tiempo que se mantendra girando son parametros que el usuario

registrara antes de que comience la etapa de carga, ademas estos datos son almacenados para poder realizar un

analisis posterior de toda la cantidad de datos obtenidos e ingresados en cada caso.

Figura 5.10: Etapa de carga

La ultima etapa es la de recubrimiento, que se muestra en la figura 5.11, en esta etapa se busca sellar el con-

dimento adherido a los collets usando una mezcla preparada para sellar el polvo que se adhirio a los collets

durante la etapa de carga. Es necesario en esta etapa tener control my preciso en la temperatura de la mezcla, ya

que la mezcla requiere mantenerse siempre a una temperatura de 43±3o C.

88


Figura 5.11: Etapa de recubrimiento

Al diagrama mostrado en la figura 5.1 es solamente uno de los muchos tipos en que UML permite desarrollar y

disenar los sistema. En el entorno Enterprise Architect el nombre de este tipo de diagrama es Bussines Workflow,

ya que, como claramente se intuye con el nombre, este diagrama es usado para describir el flujo de datos o

informacion de una empresa o negocio.

89


90

CAPITULO SEIS

DISCUSION Y CONCLUSION

La hipotesis sobre la que se baso este trabajo, planteo que con el uso de lenguaje Orientado a Objetos,ası como

la metodologıa subyacente que este provee, se puede modelar un sistema de manufactura con un lenguaje de

facil comprension para todos los involucrados, ademas de agregarle caracterısticas para hacer mas eficiente la

sustitucion, remocion o modificacion de elementos del sistema.

El sistema desarrollado es para una lınea piloto, por lo que su tamano es pequeno en comparacion con sistemas

de manufactura reales, pero sirvio para ilustrar el principio del modelado de sistemas reales usando tecnicas

Orientadas a Objetos. Los grandes sistemas industriales requieren muchas veces el procesamiento y almacena-

miento de grandes cantidades de datos hasta requerir bases de datos, necesidades que se cubren conveniente-

mente con UML y las herramientas con las que se desarrollan.

Los resultados mostrados en el capıtulo cinco muestran el modelado grafico del sistema disenado. El desarrollo

de este comenzo desde la captura, lo mas precisa posible, de los requerimientos del sistema mediante el empleo

del diagrama de requerimientos, ası como los casos de uso que junto con los diagramas de secuencia forman el

modelo de comportamiento del sistema.

El modelo estructural del sistema se creo a partir del diagrama Business Workflow que describe la totalidad del

proceso deseado por el usuario. Este diagrama es el menos detallado, pero describe la totalidad del proceso, la

interaccion entre los diferentes subsistemas, la informacion de entrada/salida requerida en cada etapa y hasta la

interaccion con el usuario.

Se partio del diagrama Business Workflow para desarrollar la estructura del sistema a un nivel mas detallado

hasta llegar al nivel de los componentes individuales y la interaccion entre estos, quedando plasmado en el dia-

grama de clases y objetos del sistema. Este diagrama es muy util ya que en el se pueden describir a gran detalle

cada uno de los objetos del sistema, permitiendo ası a cualquier persona relacionada o no con el sistema poder

comprender y hasta modificar partes de este.

91

Con base en los objetivos planteados en este trabajo, se pueden resumir los resultados en:

Se esbozo el diseno de un sistema de manufactura completo bajo una misma plataforma.

Gracias a la identificacion de objetos que permite UML se identificaron y describieron los dispositivos

del sistema bajo una metodologıa concreta.

Desde las fases tempranas de diseno se identifico el flujo de informacion en el sistema, permitiendo

seleccionar desde esa etapa los dispositivos mas apropiados para dicha tarea.

El desarrollo del sistema fue un avance en paralelo entre el diseno electronico, mecanico y sistema de

informacion con la ventaja de que el usuario siempre estuvo en condiciones de conocer el avance del

sistema.

La documentacion del sistema se genera de forma casi automatica, gracias a que todos los objetos ya

cuentan con su descripcion, informacion de entrada/salida y operaciones a realizar.

Es importante hacer notar que aunque no se realizo una simulacion, se asentaron las bases para poder realizar en

un futuro las simulaciones del sistema disenado antes de implementarlo en planta, ahorrando ası cierta cantidad

de dinero y tiempo.

La hipotesis planteada quedo comprobada, logrando desarrollar y modelar un sistema de manufactura real usan-

do la herramienta CASE Enterprise Architect y bajo una metodologıa conocida. Se logro tener un canal de co-

municacion eficaz entre el equipo de diseno y el usuario del sistema. La documentacion del sistema quedo lista

como manual de usuario y guıa para futuras modificaciones o expansiones.

92

Referencias

[1] George Chryssolouris. Manufacturing Systems: Theory and Practice. Mechanical Engineering Series.

Springer, second edition, 2006.

[2] Jurgen Kletti. Manufacturing Execution Systems-MES. Springer, 2007.

[3] John A. Schey. Procesos de Manufactura. McGraw Hill, tercera edicion edition, 2002.

[4] A. Adlemo, S. A. Andreasson, M. Fabian, P. Gullander, and B. Lennartsson. Towards a truly flexible

manufacturing system. Control Engineering Practice, 3(4):545–554, 1995.

[5] William A and Estrem. An evaluation framework for deploying web services in the next generation ma-

nufacturing enterprise. Robotics and Computer-Integrated Manufacturing, 19(6):509 – 519, 2003.

[6] Kleanthis Thramboulidis. Challenges in the development of mechatronic systems: The mechatronic com-

ponent. In 13th IEEE Int. Conf. on Emerging Technologies end Factory Automation, page 8, Hamburg,

Germany, September 2008. IEEE.

[7] E. Carpanzano and F Jovane. Advanced automation solutions for future adaptive factories. CIRP Annals

- Manufacturing Technology, 56(1):435–438, 2007.

[8] Marcos W. C. Aguiar, I. Shaun Murgatroyd, and John M. Edwards. Object-oriented resource models: their

role in specifying components of integrated manufacturing systems. Computer Integrated Manufacturing

Systems, 9(1):33–48, 1996.

[9] Manfredi Bruccoleri, Sergio Noto La Diega, and Giovanni Perrone. An object-oriented approach for

flexible manufacturing control systems analysis and design using the unified modeling languaje. The

International Journal of Flexible Manufacturing Systems, (12):196–216, 2003.

[10] K. W. Young, R Piggin, and P Rachitrangsan. An object-oriented approach to an agile manufacturing

control system design. The International Journal of Advanced Manufacturing Technology, 17(11):850–

859, 2001.

93

REFERENCIAS

[11] Felix T. S. Chan, Zhang Jie, H. C. W. Lau, and A. Ning. Object-oriented architecture of control system for

agile manufacturing cells. ICMIT, pages 863–868, 2000.

[12] J. and Schein. An information model for building automation systems. Automation in Construction,

16(2):125 – 139, 2007.

[13] Sthepen T. Rahimifard, Shahin y Newman. The application of information systems for the design and

operation of flexible machining cells. Journal of Intelligent Manufacturing, 10:21–27, 1999.

[14] Marcello Bonfe and Cesare Fantuzzi. Design and verification of mechatronic object-oriented models for

industrial control systems. In IEEE, editor, Emerging Technologies and Factory Automation, volume 2,

pages 253–360, 2003.

[15] Timothy Budd. Introduccion a la Programacion Orientada a Objetos. Addison-Wesley Iberoamericana,

primera edicion en espanol edition, 1994.

[16] Bertrand Meyer. Reusability: The case for object-oriented design. IEEE Software, 4(2):50–64, March

1987.

[17] David B. Pratt, Phillip A. Farrington, Chuda B. Basnet, Hemant C. Bhuskute, Manjunath Kamath, and Joe

H. Mize. A framework for highly reusable simulation modeling: Separating physical, information, and

control elements. In Proceedings of the 24th Annual Simulation Symposium, pages 254–261, 1991.

[18] Ivar Jacobson, Grady Booch, and James Rumbaugh. El Lenguaje Unificado de Modelado. Manual de

Referencia. Object Tecnology. Addison-Wesley, primera edicion en espanol edition, 2000.

[19] Ivar Jacobson, Grady Booch, and James Rumbaugh. El Proceso Unificado de Desarrollo de Software.

Addison-Wesley, primera edicion en espanol edition, 2000.

[20] S. Narayanan, D. A. Bodner, U. Sreekanth, T. Govindaraj, L. F. McGinnis, and M. C. Mitchell. Research

in object-oriented manufacturing simulations: An assessment of the state of the art. IIE Transactions,

30(9):795–810, September 1998.

[21] Sadashiv Adiga. Software modelling of manufacturing systems: A case for an object-oriented program-

ming approach. Annals of Operations Research, (17):363–378, 1989.

[22] A. Storr, J. Lewek, and R. Lutz. Modeling and reuse of object-oriented machine software. In Proceedings

of European Conference In Integration in Manufacturing, pages 475–484, 1997.

[23] Vosniakos G.C. Ziaaie-Moayyed, Ma. Application of the ‘fusion’method in designing a generic object-

oriented modelling shell for manfacturing systems. Computer Integrated Manufacturing Systems, 11(1-

2):25–34, 1998.

94

REFERENCIAS

[24] Rolf Isermann. Modeling and design methodology for mechatronic systems. IEEE/ASME Transactions

on Mechatronics, 1(1):16–28, March 1996.

[25] G. C. Vosniakos, M Ziaaie-Moayyed, and A. G. Mamalis. Design of a system for computer-aided engi-

neering of a manufacturing facilities. Computer Integrated Manufacturing Systems, 10(1):1–7, 1997.

[26] Hassan Gomaa. An object-oriented domain analysis and modelling method for software reuse. In Procee-

dings of the Twenty-Fifth Hawaii International Conference on System Sciences, volume 2, pages 46–56,

1992.

[27] Luca Bassi, Christian Secchi, and Marcello Bonfe. A SysML-based methodology for manufacturing ma-

chinery modeling and design. IEEE/ASME Transactions on Mechatronics, 16(6):1049–1062, 2011.

[28] Marcello Bonfe, Cesare Fantuzzi, and Christian Secchi. Unified modeling and verification of logic con-

trollers for physical systems. In Proceedings of the 44th IEEE Conference on Decision and Control, and

the European Control Conference 2005, pages 12–15, Sevilla, Espana, December 2005. IEEE.

[29] Christian Secchi, Cesare Fantuzzi, and Marcello Bonfe. Unified modeling of control software and physical

plants. In Proceedings of IFAC World Congress, volume 16, pages 1053–1058, Prague, Czech Republic,

July 2005.

[30] Marcello Bonfe, Cesare Fantuzzi, and Christian Secchi. Verification of behavioral sustitutability in object-

oriented models for industrial controllers. In Proceedings of the 2005 IEEE International Conference on

Robotics and Automation, pages 3978–3983, Barcelona, Espana, April 2005. IEEE.

[31] Marcello Bonfe and Cesare Fantuzzi. Design and verification of industrial logic controllers with UML and

statecharts. IEEE Conference on Control Applications, pages 1029–1034, June 2003.

[32] Marcello Bonfe, Claudio Donati, and Cesare Fantuzzi. An application of software design methods to ma-

nufacturing systems supervision and control. In IEEE, editor, Proceedings of the 2002 IEEE International

Conference on Control Applications, pages 850–855, Glasgow, Scotland, U.K., September 2002.

[33] Christian Secchi, Cesare Fantuzzi, and Marcello Bonfe. On the use of UML for modeling physical sys-

tems. In Proceedings of the 2005 IEEE International Conference on Robotics and Automation, Barcelona,

Espana, April 2005. IEEE.

[34] Christian Secchi, Marcello Bonfe, and Cesare Fantuzzi. On the use of UML for modeling mechatronic

systems. IEEE Transactions on Automation Science and Engineering, 4(1), January 2007.

[35] Christian Secchi, Marcello Bonfe, Cesare Fantuzzi, Roberto Borsari, and Davide Borghi. Object-oriented

modeling of complex mechatronic components for the manufacturing industry. IEEE/ASME Transactions

on Mechatronics, 12(6):696–702, December 2007.

95

REFERENCIAS

[36] Christian Secchi, Davide Zanichelli, Riccardo Rubini, Cesare Fantuzzi, Marcello Bonfe, Davide Borghi,

Roberto Borsari, and Elena Sacchetti. Towards object-oriented modeling of complex mechatronic systems

for the manufacturing industry. In Proceedings of ASME 2006 International Mechanical Engineering,

page 9, Chicago, USA, November 2006. ASME.

[37] Kleanthis Thramboulidis and Chris Tranoris. An architecture for the development of function block orien-

ted engineering support systems. In IEEE, editor, IEEE International Conference on Computational Inte-

ligence in Robotics and Automation, pages 536–542, Canada, Agosto 2001.

[38] Kleanthis Thramboulidis. Using UML in control and automation: A model driven approach. In IEEE,

editor, 2nd IEEE International Conference on Industrial Informatics (INDIN’04), Berlin, Germany, June

2004.

[39] Kleanthis Thramboulidis. Using UML for the development of distributed industrial process measurement

and control systems. In IEEE, editor, IEEE Conference on Control Applications (CCA), pages 1–6, Mexi-

co, September 2001.

[40] Kleanthis Thramboulidis and Chris Tranoris. Developing a case tool for distributed control applications.

The International Journal of Advanced Manufacturing Technology, 24(1-2):12, July 2004.

[41] Christos Tranoris and Kleanthis Thramboulidis. Integrating UML and the function block concept for the

development of distributed control applications. In IEEE, editor, Emerging Technologies and Factory

Automation, 2003. Proceedings. ETFA ’03. IEEE Conference, volume 2, pages 87–94, September 2003.

[42] Christos Tranoris and Kleanthis Thramboulidis. From requirements to function block diagrams: A new

approach for the design of industrial control applications. In Proceedings of the 10th Mediterranean

Conference on Control Applications - MED2002, Lisbon, Portugal, July 2002.

[43] Goran Cengic, Oscar Ljungkrantz, and Knut Akesson. A framework for component based distributed

control software development using iec 61499. In IEEE, editor, Conference on Emerging Technologies

and Factory Automation, pages 782–789, September 2006.

[44] Marcello Bonfe and Cesare Fantuzzi. A practical approach to object-oriented modeling of logic control

systems for industrial applications. In 43rd IEEE Conference on Decision and Control, volume 1, pages

980–985, Atlantis, Paradise Island, Bahamas, December 2004. IEEE.

[45] Daniel Witsch and Birgit Vogel-Heuser. Plc-statecharts: An approach to integrate uml-statecharts in open-

loop control engineering - aspects on behavioral semantics and model-checking. In 8th IEEE International

Conference on Industrial Informatics, pages 915–920, Osaka, July 2010. IEEE.

[46] Marcello Bonfe, Cesare Fantuzzi, and Christian Secchi. Design patterns for model-based automation

software design and implementation. Control Engineering Practice, page 12, 2012.

96

REFERENCIAS

[47] Kleanthis Thramboulidis. Model-integrated mechatronics: Towards a new paradigm in the development

of manufacturing system. IEEE Transactions on Industrial Informatics, 1(1):54–61, February 2005.

[48] Chuda B. Basnet, Phillip A. Farrington, David B. Pratt, Manjunath Kamath, S Cem Karacal, and Terren-

ce G. Beaumariage. Experiences in developing an object-oriented modeling environment for manufactu-

ring systems. In Richard E. Nance Osman Balci, Randall P. Sadowski, editor, Proceedings of the 1990

Winter Simulation Conference, pages 477–481, 1990.

[49] Sven Burmester, Matthias Tichy, and Holger Giese. Modeling reconfigurable mechatronic system with

mechatronic UML. In U. Asmann, editor, Proceedings of Model Driven Architecture: Foundations and

Applications (MDAFA 2004), pages 155–169, Limkoping, Sweden, June 2004.

[50] Sven Burmester, Holger Giese, and Matthias Tichy. Model-driven development of reconfigurable mecha-

tronic system with mechatronic UML. Lecture Notes in Computer Science, 3599:47–61, 2005.

[51] Daniel Witsch and Birgit Vogel-Heuser. Close integration between UML and IEC 61131-3: New pos-

sibilities through object-oriented extensions. In IEEE Conference on Emerging Technologies & Factory

Automation, pages 1–6, Mallorca, September 2009. IEEE.

[52] Peter O’Grady and Wen-Yau Liang. An object-oriented approach to design with modules. Computer

Integrated Manufacturing Systems, 11(4):267–283, 1998.

[53] Bonie S. Heck, Linda M. Willis, and George J. Vachtsevanos. Software technology for implementing

reusable, distributed control systems. IEEE Control Systems Magazine, 2003.

[54] Bran Selic and Jim Rumbaugh. Using UML for modeling complex real-time systems. Technical report,

IBM, 1998.

[55] Heiko Mosemann and Friedrich M. Wahl. Automatic decomposition of planned assembly sequences into

skill primitives. IEEE Transactions on Robotics and Automation, 17(5):709–718, October 2001.

[56] Tuukka Ritala and Seppo Kuikka. UML automation profile:enhancing the efficiency of software develop-

ment in the automation industry. In IEEE, editor, 5th International Conference on Industrial Informatics,

volume 2, pages 885–890, June 2007.

[57] J. Norberto Pires and J.M.G. Sa da Costa. Object-oriented and distributed approach for programming

robotic manufacturing cells. Robotics and Conputer Integrated Manufacturing, 16:29–42, 2000.

[58] Ludwig von Bertalanffy. Teorıa General de los Sistemas. Fondo de Cultura Economica, 1989.

[59] Oscar Johansen Bertoglio. Introduccion a la teorıa general de sistemas. Limusa, 1993.

[60] Jingshan Li and Semyon M. Meerkov. Production Systems Engineering. Springer, 2009.

97

REFERENCIAS

[61] H.-P. Wiendahl, H.A. ElMaraghy, P. Nyhuis, M.F. ZAh, H.-H. Wiendahl, N. Duffie, and M. Brieke. Chan-

geable manufacturing - classification, design and operation. CIRP Annals - Manufacturing Technology,

56(2):783 – 809, 2007.

[62] Martin Fowler and Kendall Scott. UML gota a gota. Pearson Education, primera edicion en espanol

edition, 1999.

[63] Kenneth E. Kendall and Julie E. Kendall. Analisis y Diseno de Sistemas. Pearson Education, 2005.

[64] Jitendra y Gera Mohit Kumar Garg, Rajiv y Kumar Dar. Organizational dynamics of an information

system: case study from the forestry sector. Journal of Forestry Research, 18(1(2007)):1–10, 2007.

[65] Eliyahu M. Goldratt. El sındrome del pajar. Ediciones Castillo, 1994.

[66] Antoni Olive. Conceptual Modeling of Information Systems. Springer, 2007.

[67] M y Lipczak Jacobsen H. y Wulfsohn D. y Blackmore S y Griepentrog H. W. Fountas, S. y Kyhn. A

systems analysis of information system requirements for an experimental farm. Journal of Precision

Agriculture, pages 247–261, 2009.

[68] S. V. y Derzhavets B. A. y Trukhov A. V Naumov, A. P. y Vonsovich. The software and information system

for development of neutro activation techniques with optimal characteristics. Journal of Radioanalytical

and Nuclear Chemistry, 197(1(1993)):31–37, 1993.

[69] Kleanthis Thramboulidis. The Industrial Information Technology Handbook. Industrial Electronics Series.

CRC Press LLC, 2005.

[70] Doug Rosenberg and Math Stephens. Use Case Driven Object Modeling with UML:Theory and Practice.

Apress, 2007.

98

Glosario de terminos

Como la metodologıa lo indica, es necesario incluir un glosario donde se expliquen los diferentes terminos usa-

dos en el sistema, con la finalidad de asegurar la clara comprension por parte de todos los involucrados:

Termino Definicion

Bombo Recipiente redondo que contendra el material base durante las etapas de rociado y carga.

Carga Segunda etapa del proceso, consiste en mantener girando, durante un tiempo determinado ,

el bombo conteniendo el material base y el polvo.

Collete Material base del producto, proviene de un proceso anterior y las caracterısticas de este

seran las que se se modificaran.

Flujo masico Variacion de masa, en este caso del polvo, por unidad de tiempo en la mezcla aire-polvo que

impacta el collete durante la etapa de rociado.

Flujo volumetrico Volumen del fluido, en este caso el aire, que ingresa al eductor para mezclarse con el polvo

e impactara al collete durante la etapa de rociado.

Recubrimiento Tercera etapa del proceso, consiste en aplicar una capa de slurry a los colletes una vez

cargados para sellar el polvo dentro de estos.

Rociado Primera etapa del proceso. Consiste en rociar los colletes con una mezcla de aire-polvo a

presion durante un tiempo determinado por el usuario.

Slurry Mezcla usada en la tercera etapa del proceso, usada para sellar el polvo dentro de colletes.

Tumbler Recipiente cilındrico dentro del cual se lleva a cabo la tercera etapa del proceso. Este se

encuentra girando a velocidad indicada por el usuario para que la aplicacion del slurry sobre

los colletes sea lo mas homogenea posible.

99

REFERENCIAS

100

CAPITULO SIETE

ANEXOS

Como resultado de las primeras reuniones del equipo de diseno con el usuario, el primer documento que se

genero explicando el funcionamiento del sistema fue:

4"de"octubre"de"2012"

"

Resumen"de"la"reunión"del"día"con"el"Dr."Adrián"G.,"Dr."Iván"."y"Alberto"Tiburcio"

"

"

Se"definió"que"el"funcionamiento"del"sistema"debe"basarse"en"la"siguiente"

secuencia."

"

1)"El"sistema"debe"encenderse"usando"un"interruptor"principal"que"energice"a"todo"

el"prototipo."La"función"de"encendido"también"implica"encender"la"laptop"y"abrir"el"

programa"en"LabVIEW."

"

2)"El"operador"ingresará"en"la"interfaz"de"LabVIEW"todos"los"datos"necesarios"para"

que"el"programa"pueda"comenzar"a"funcionar"ya"que"si"no"se"incluyen"dichos"datos"

el"sistema"comenzará"con"la"prueba."Los"datos"que"el"operador"debe"ingresar"son:"

" "

Información+general+ONombre"del"Operador."

" ONombre"del"Experimento."

" OPeso"del"lote"de"material"base"que"se"usará."

" OPeso"del"polvo"que"se"ingresará"en"la"etapa"de"carga"

"

Rociado+" OTipo"de"polvo"que"se"usará."

" OPresión"neumática"deseada"para"esta"etapa"

" OTasa"de"alimentación"de"polvo."

" OVelocidad"angular"del"bombo"para"esta"etapa."

" OTiempo"de"exposición"al"rociado."

"

Carga+" OTipo"de"polvo"que"se"usará"para"la"carga."

OVelocidad"angular"del"bombo"para"la"etapa"de"carga."

" OTiempo"que"durará"la"etapa."

"

Recubrimiento+" OVelocidad"angular"del"tumbler."

" OFlujo"volumétrico"de"la"mezcla"para"recubrimiento."

" OPresión"neumática"para"la"aplicación"del"recubrimiento."

" OTasa"de"alimentación"de"collete"al"proceso"de"recubrimiento."

"

"

3)" Una" vez" ingresados" los" datos"mencionados," el" sistema" comenzará" a" correr" el"

experimento"de"acuerdo"a"los"datos"proporcionados"por"el"operador."

"

4)"Desde"que"comience"el"experimento"el"sistema"comenzará"a"tomar"muestras"de"

la"temperatura"y"humedad"ambiental,"además"de"obtener"un"promedio"de"ambas"al"

final"del"experimento."

"

101

5)" Una" vez" que" termine" el" proceso" de" rociado," el" sistema" pedirá" al" usuario" que"

haga"los"ajustes"necesarios"como"ingresar"la"cantidad"de"polvo"indicada"y"poner"la"

tapa"del"bombo"adecuada"para"poder"continuar"con"el"siguiente"proceso."También"

recordará"al"operador"para"que"éste"tome"una"muestra"de"los"colletes"y"lo"etiquete"

con"el"código"correspondiente"

"

6)"Cuando"el"operador"termine"de"hacer"los"ajustes"necesarios,"indicará"al"sistema"

que"prosiga"con"el"experimento."

"

7)" El" experimento" continuará" según" la" información" ingresada" por" el" operador"

antes"de"comenzar"con"la"prueba."

"

8)"Cuando"termine"la"etapa"de"carga,"el"sistema"pedirá"al"operador"que"coloque"los"

colletes" en" el" dosificador" para" poder" continuar" con" la" etapa" de" recubrimiento."

También"recordará"al"operador"para"que"éste"tome"una"muestra"de"los"coletes"y"lo"

etiquete"con"el"código"correspondiente"

"

9)"El"operador"indicará"al"sistema"cuando"los"coletes"estén"listos"en"el"dosificador"

y"pueda"continuar"con"la"prueba."

"

10)"El"sistema"continuará"con"la"última"etapa"siguiendo"las"especificaciones"dadas"

por" el" operador" al" comienzo." Cuando" se" termine" la" prueba" el" sistema" avisará" al"

operador."También"recordará"al"operador"para"que"éste"tome"una"muestra"de"los"

colletes"y"lo"etiquete"con"el"código"correspondiente."

" "

102

CAPITULO 7. ANEXOS

Como segunda iteracion en cuanto a la determinacion de los requerimientos del sistema se genero el siguiente

documento, donde se detallan todas las variables que se requieren medir y controlar, los tipos de sensores y

actuadores y hasta los posibles vendedores del equipo.

Diseño'de'línea'piloto'de'manufactura'!1.6'Definición'del'problema:'(Implica)establecer)lo)que)se)supone)que)debe)realizar)el)producto,)incluyendo)especificaciones)y)necesidades)especiales)))El!sistema,!viéndolo!desde!el!punto!de!vista!electrónico,!se!divide!en!dos!partes:!Instrumentación!y!control.!!Subsistema!de!Instrumentación:!!Debe!ser!capaz!de!monitorear!constantemente!las!variables!del!proceso.!!!Variables'controlables' Variables'solo'medibles'Presión! Nombre!del!operador!Flujo!másico!del!polvo! Fecha/hora!Tiempo!en!cada!etapa!del!proceso! Título!del!experimento!Velocidad! angular! del! bombo! en! cada!etapa!

Peso! del! material! base! (se! medirá! en!cada!etapa)!

Velocidad! angular! del! tumbler! en! la!etapa!de!recubrimiento!

Flujo!de!entrada!de!aire!

Flujo! volumétrico! de! la! mezcla! en! la!etapa!de!recubrimiento!

Humedad!ambiental!

Temperatura! de! la! mezcla! en! la! etapa!de!recubrimiento!

Temperatura!ambienta!

Presión! neumática! en! la! etapa! de!recubrimiento!

Peso!del!polvo!ingresado!en!la!etapa!de!carga!

!!Lo!anterior!implica!hacer!un!estudio!de!la!naturaleza!de!las!variables,!los!métodos!para!medirlas,!los!dispositivos!comerciales!y,!finalmente,!!la!interacción!de!dichos!dispositivos!entre!ellos.!El!último!punto!es!importante!ya!que!todo!se!centrará!en!un! sistema! de! adquisición! de! datos,! todos! los! dispositivos! sensores! deben! de!compartir! rangos! de! voltajes,! corrientes,! o! protocolos! de! comunicación! en! todo!caso.!!Subsistema!de!control:!!Existen!variables!que!querrán!controlarse!por!medios!remotos!o!desde!la!interfaz!de!usuario.!Para!éstas!se!debe!de!evaluar!la!naturaleza!de!la!variable,!los!métodos!para!controlar!su!magnitud,!los!dispositivos!comerciales!que!cumplen!dicha!tarea.!Al!momento!de!diseñar!el!sistema,!debe!tomarse!en!cuenta!la!compatibilidad!entre!todos!los!dispositivos!involucrados.!!Es! importante!tener!en!cuenta!que!es!deseable!que!la! interfaz!mencionada!sea! la!misma!para!el!sistema!de!instrumentación!y!el!de!control.!El!trabajo!de!ésta!será!la!de!convertir!las!diferentes!señales!recibidas!de!los!sensores!en!datos!que!puedan!enviarse!a!una!base!de!datos!y!viceversa!para!el!caso!del!sistema!de!control!donde!los!datos!recibidos!desde!el!dispositivo!principal!se!conviertan!en!señales!hacia!los!actuadores.!

103

'''2.6'Subdivisión'del'problema:!))El!sistema!se!dividirá!por!bloques!funcionales!como!se!muestra!en!la!Fig.!1!!!

!Fig.'1:'Diagrama'del'proceso'

!El!rociado!es!la!sección!donde!el!producto!base!es!impactado!con!partículas!a!alta!velocidad!con!el!fin!de!modificar!la!superficie!de!éste.!En!esta!parte!del!proceso!se!necesita!tener!control!de!la!presión!del!sistema!y!del!flujo!de!alimentación!de!las!partículas.!!En! la! carga! los! elementos! base! se! sumergen! en! una! gran! cantidad! de! partículas!logrando!que!el!elemento!base!se!impregne!de!la!mayor!cantidad!de!partículas.!Ya!que! la! carga! se! realiza! dentro! de! un! recipiente,! donde! se! confinan! tanto! los!elementos!base!como!las!partículas,!mientras!éste!gira,!las!variables!a!medir!serán!la!velocidad!angular!del!recipiente!y!el!tiempo!!que!se!tarde!este!proceso.!!La!última!etapa,!el!recubrimiento,!consiste!en!aplicar!a!los!elementos!impregnados!en! la! etapa! anterior! de! una! mezcla! viscosa! para! sellar! las! partículas! atrapadas!dentro!de!los!elementos!base!así!como!dotar!al!producto!de!un!acabo!final.!!Ya! que! cada! bloque! cumple! con! una! tarea! específica! debe! apegarse! a! ciertas!características,! mismas! que! serán! constantemente! medidas! y! algunas! también!controladas.!Las!variables!importantes!en!cada!bloque!se!muestran!en!la!Fig.!2:!!!

!Fig.'2:'Esquema'detallado'de'variables'del'proceso'

Rociado' Carga' Recubrimiento'Productor'de'elemento'base'

! Presión'(P1)'! Vel.'Angular'de'bombo'(ωB)'

! =empo.'! flujo'másico'de'condimento'(m)'

! Vel.'Angular'de'bombo'(ωB)'

! =empo.'

! Vel.'Angular'de'tombler'(ωT)'

! flujo'volumétrico'de'mezcla'(ν)'

! Temperatura.'! Presión'(P2)'

! Masa'material'base'(mb)'

! Flujo'de'entrada'de'aire'(fa)'

! Humedad'(H)'y'Temperatura'(T)'ambiental.'

! Masa'de'condimento''(mb)'

! Masa'de'material'base'(mb2)'

! Nombre'del'operador.'

! Fecha/Hora.'! Titulo'de'Experimento.'

Rociado Carga Recubrimiento

Productor!de!elemento!base

104

CAPITULO 7. ANEXOS

!!En!la!Fig.!2!se!observan!los!2!tipos!de!variables!del!proceso.!Las!variables!de!proceso!mostradas!dentro!de! los! rectángulos!de! línea! interrumpida,!en! la!parte!de!abajo,!son! las! variables! que! se! podrán! controlar! con! la! finalidad! de! poder! observar! su!influencia!en!el!producto.!Las!demás!variables,!que!se!encuentran!encerradas!en!los! rectángulos! con! línea! punteada,! son! las! que! solamente! podrán! medirse,!proporcionando!así!información!necesaria!sobre!el!proceso.!!!Como!se!muestra!en!la!Fig.!3!Además!de!las!variables!antes!mencionadas!también!se!integrarán!a!la!base!de!datos!del!proceso!imágenes!del!producto,!para!observar!la!evolución! del! producto,! ! así! como! datos! relevantes! al! producto! como! el! peso!individual,!cantidad!de!partículas!adheridas,!porcentaje!de!micro!poros,!etc.!!!!

!!!!!!!!!!!!!!!!!!!!!!!!

Rociado' Carga' Recubrimiento'

!  Imágenes'!  Datos'sobre'material'base'

!  Imágenes'!  Datos'sobre'material'base'

Fig.'3:'Obtención'de'Imágenes'y'datos'sobre'elemento'base'entre'etapas'del'proceso'

105

3.6'Especificaciones'técnicas'de'cada'una'de'las'variables:'!

Variable! Símbolo! Intérvalo!de!medición!

Dispositivo!a!usar!

Fabricante! Señal!de!control!

Comunicación! Observaciones!

!Presión!de!entrada!al!eductor!

!!

Pe!

!!20Z80!psi!

!Válvula!proporcional!de!presión!

!ZNorgren!

ZAnalógica!(Voltaje)!ZDigital(8!bits)!

No! Existe!distribuidor!en!Querétaro!

ZSMC!(Serie!ITV)!

ZVoltaje!ZCorriente!

No! Existe!Distribuidor!en!Querétaro!

Flujo!másico!de!polvo!

fmp! 0Z500!rpm! Driver!p/motor!eléctrico!

ZDiseño!propio!

ZDigital! No! El!diseño!del!cto.!está!pensado!para!que!la!señal!digital!(pwm)!controle!la!salida!de!un!circuito!CD/CD!

Tiempo!de!rociado!

tR! 0Z30!min! Reloj!interno!del!sistema!

! ! ! !

Velocidad!angular!de!bombo!

ωB! 0Z300!rpm! Driver!para!motor!CD!

ZRoboteq!ZAllen!Bradley!

Z!Digital!(RS232/USB)!

Puertos!seriales,!vía!software!

El!controlador!es!capaz!de!recibir!órdenes!a!partir!de!programación.!

Tiempo!de!carga!

tc! 0Z300!rpm! Reloj!interno!del!sistema!

! ! ! !

!!Velocidad!angular!de!tumbler!

!!!ωt!

!!!

0Z300!rpm!

!!Driver!para!motor!AC!

!!ZAllen!Bradley!

!!ZDigital!ZEthernet!

! Allen!Bradley!cuenta!con!diversos!modelos!de!controladores!que!pueden!comunicarse!por!software!!

Flujo!volumétrico!de!la!mezcla!

νm! ! Driver!para!motor!AC!

ZAllen!Bradley!

ZVía!puerto!de!comunicación!

ZProtocolos!de!Allen!Bradley!vía!RS485:!*DeviceNet!*Ethernet/IP!*ControlNet!*PROFITBUS!

!

Temperatura!de!la!mezcla!

Tm! ! ZControl!de!la!marmita!

! ! ! !

!Presión!neumática!para!recubrimiento!

!!PR!

! !!Válvula!proporcional!de!presión!

!ZNorgren!

ZAnalógica!(Voltaje)!ZDigital(8!bits)!

No! Existe!distribuidor!en!Querétaro!

ZSMC!(Serie!ITV)!

ZVoltaje!ZCorriente!

No! Existe!Distribuidor!en!Querétaro!

!!!

106

analisis, dise´ no y modelado de una l˜ ´ınea piloto de

Documents