modelo para la integraciÓn automatizada de los procesos en la industria - uml --- ronald orellano...
TRANSCRIPT
Universidad de Pamplona La academia al servicio de la vida.
1
Técnicas de mantenimiento.
MODELO PARA LA INTEGRACIÓN AUTOMATIZADA DE LOS PROCESOS EN LA INDUSTRIA
(UML)
Ronald Orellano Mercado
Cod. 72279525
UNIVERSIDAD DE PAMPLONA,
Facultad de ingeniería,
Programa de ingeniería eléctrica.
Pamplona – Norte de Santander, Colombia.
Resumen: La Ingeniería de Software utiliza modelos de procesos de desarrollo de
software y un conjunto de técnicas y metodologías para definir, analizar y diseñar
sistemas de información. Una de esas técnicas es el Lenguaje Unificado de Modelado
(UML). UML se caracteriza por ser un lenguaje semiformal, generando problemas de
ambigüedad, claridad y consistencia. Algunos investigadores intentan formalizarlo
mediante Lógica de predicados de primer orden, teoría de conjuntos, lenguajes
controlados y/o restringidos y metamodelado; sin embargo, estos acercamientos no son
suficientes debido a que se suelen enfocar en un solo diagrama y únicamente en la
sintaxis, dejando de lado la semántica. En este artículo se presenta un conjunto de reglas
que permiten la representación de las primitivas conceptuales de UML, así su aplicación
como gestión integrada de Mantenimiento, modelado de una gestión Operacional Y
detección y diagnóstico de fallas en una industria.
Descriptores: Lenguaje Unificado de Modelado, primitivas conceptuales de UML,
gestión Operacional, diagnóstico de fallas, representación formal.
Abstract: Software engineering uses models of software development processes and a
set of techniques and methodologies to define, analyze and design information systems.
One such technique is the Unified Modeling Language (UML). UML is characterized as
semi-formal language, creating problems of ambiguity, clarity and consistency. Some
researchers attempt to formalize logic predicates by first order set theory, controlled
languages and / or restricted and metamodeling, however, these approaches are not
enough because they often focus on a single diagram and only the syntax, leaving
semantics aside. This article presents a set of rules that allow the representation of
conceptual primitives of UML and its application as integrated management of
maintenance, operational management modeling and fault detection and diagnosis in an
industry.
Descriptors: Unified Modeling Language, UML conceptual primitives, operational
management, fault diagnosis, formal representation.
25 de Abril de 2013
Universidad de Pamplona La academia al servicio de la vida.
1
Técnicas de mantenimiento.
1. INTRODUCCIÓN
En este artículo daré un recorrido por las partes
más importantes de UML e intentare hacer ver la
importancia de modelar y porqué es tan importante
un buen diseño de software.
Un proyecto de software con éxito es aquél que
produce un software de calidad, consistente y sobre
todo que satisface las necesidades de los usuarios
que van a utilizar el producto resultante.
Una empresa que produce software de calidad, con
un uso eficiente y efectivo de los recursos y
terminar los proyectos en plazo tiene un negocio
sostenible. Y tenemos que tener en cuenta que lo
que importa es el producto final, que funcione bien
y que cumpla los requisitos establecidos por los
usuarios y no que sea muy bonito, que se hagan
reuniones muy importantes o que se hayan
codificado muchas líneas de código.
Hace ya tiempo leí una frase que creo que merece
la pena recordar: “Para desarrollar software de
calidad duradera, hay que idear una sólida base
arquitectónica que sea flexible al cambio”. El
modelado es una parte fundamental en esta
aspecto, construimos modelos para poder visualizar
el comportamiento del sistema y poder controlar su
arquitectura.
Incluso para producir software de sistemas
pequeños sería bueno hacer un análisis y un
modelado ya que se producirían sistemas de mejor
calidad, pero lo que si es cierto, es que cuanto más
grande y complejos son los sistemas más
importante es hacer un buen modelado ya que nos
ayudará a entender el comportamiento del sistema
en su totalidad y que si no tenemos modelado sería
bastante difícil. Y cuando se trata de sistemas
complejos el modelado nos dará una idea de los
recursos necesarios (tanto humanos como
materiales) para abordar el proyecto. También nos
dará una visión más amplia de cómo abordar el
problema para darle la mejor solución.
2. MARCO TEÓRICO
2.1 Que es UML?
UML es un lenguaje gráfico para visualizar,
especificar, construir y documentar un sistema de
software. UML ofrece un estándar para describir
un "plano" del sistema (modelo), incluyendo
aspectos conceptuales tales como procesos de
negocios y funciones del sistema, y aspectos
concretos como expresiones de lenguajes de
programación, esquemas de bases de datos y
componentes de software reutilizables.
El punto importante para notar aquí es que UML es
un "lenguaje" para especificar y no un método o un
proceso. UML se usa para definir un sistema de
software; para detallar los artefactos en el sistema;
para documentar y construir, es el lenguaje en el
que está descrito el modelo. UML se puede usar en
una gran variedad de formas para soportar una
metodología de desarrollo de software, pero no
especifica en sí mismo qué metodología o proceso
usar.
2.2 Para Qué Sirve UML?
UML sirve para hacer modelos que permitan:
Visualizar como es un sistema o como
queremos que sea.
Especificar la estructura y/o
comportamiento de un sistema.
Hacer una plantilla que guíe la
construcción de los sistemas.
Documentar las decisiones que hemos
tomado.
El modelado sirve no solamente para los grandes
sistemas; aún en aplicaciones de pequeño tamaño
se obtienen beneficios de modelar, sin embargo, es
un hecho que entre más grande y más complejo es
el sistema, el modelado juega un papel más
importante.
Hay límites para el entendimiento de la
complejidad. A través del modelado reducimos el
ámbito del problema de estudio al enfocar solo un
aspecto a la vez.
UML puede ser usado extensivamente en:
Recopilación de requerimientos, Análisis de
aplicaciones, Diseño de sistemas, en pruebas, en
implementación, en reingeniería y prácticamente
en cualquier actividad de desarrollo que sea
susceptible de ser modelada.
Cabe aclarar que aunque UML es orientado a
objetos preferentemente, es útil en cualquier
modelo tecnológico ya que es independiente de
Universidad de Pamplona La academia al servicio de la vida.
2
Técnicas de mantenimiento.
lenguajes de programación o tecnología
determinada.
2.3 ¿Porque Es Importante UML?
Esta consolidado como el lenguaje estándar en el
análisis y diseño de sistemas de cómputo.
Mediante UML es posible establecer la serie de
requerimientos y estructuras necesarias para
plasmar un sistema de software previo al proceso
intensivo de escribir código.
En otros términos, así como en la construcción de
un edificio se realizan planos previo a su
construcción, en Software se deben realizar diseños
en UML previa codificación de un sistema, ahora
bien, aunque UML es un lenguaje, éste posee más
características visuales que programáticas, mismas
que facilitan a integrantes de un equipo
multidisciplinario participar e intercomunicarse
fácilmente, estos integrantes siendo los analistas,
diseñadores, especialistas de área y desde luego los
programadores.
2.4 Primitivas Conceptuales de UML
Las primitivas conceptuales (constructs, como se
conocen en inglés) permiten describir, de forma
abstracta, los aspectos funcionales de una
aplicación; a estas primitivas conceptuales también
se les denomina elementos conceptuales o patrones
conceptuales (Molina et al., 2004). En otras
palabras, una primitiva conceptual es un término
empleado para hacer referencia a los diferentes
elementos que componen un esquema conceptual.
Las principales primitivas conceptuales utilizadas
en UML 2.2 se describen a continuación (OMG,
2010).
Actor: Es el rol que los usuarios desempeñan
respecto del sistema y que emplean los casos de
uso. Pueden ser humanos u otros sistemas que se
comunican con el sistema.
Asociación: Es la interacción que se establecen
entre los actores y los casos de uso.
Asociación entre clases: Es un elemento de
modelo que puede tener propiedades de clase y de
asociación.
Atributo: Es una característica estructural.
Caso de uso: Es la especificación de un conjunto
de acciones realizadas por el actor sobre el sistema;
es decir, son los pasos que describen de principio a
fin un proceso.
Clase: Describe un conjunto de objetos que
comparten las mismas especificaciones de
características, restricciones y semántica.
Estado: Es uno de los tres estados definidos para la
clase State (Estado simple, estado compuesto y
máquina de subestados), el cual representa una
situación durante la cual las condiciones estáticas
no se modifican.
Extensión: Es una interacción que se presenta
cuando una instancia del caso de uso origen
extiende el comportamiento del caso de uso
destino; en otras palabras, el caso de uso a extender
invoca el caso de uso base bajo ciertas condiciones
(Cockburn, 2000).
Generalización: Es una relación taxonómica entre
un clasificador más general y un clasificador más
específico. Cada instancia del clasificador
específico es también una instancia indirecta del
clasificador general. El clasificador específico
hereda las características del clasificador más
general.
Inclusión: Es una interacción que se presenta
cuando una instancia del caso de uso origen
incluye también el comportamiento descrito por el
caso de uso destino; es decir, un caso de uso
incluido describe un objetivo de bajo nivel de un
caso de uso base.
Herencia: Es una interacción que se presenta
cuando un caso de uso origen hereda la
especificación de un caso de uso destino y
posiblemente la modifica y/o amplia; se presenta
también entre los actores.
Línea de vida: Representa una única entidad que
interactúa dentro del diagrama, aunque puede tener
multiplicidad.
Mensaje: Interacción entre líneas de vida, la cual
puede representar la invocación de una operación,
la creación o destrucción de una instancia o el
envío de una señal; el mensaje normalmente indica
la entidad que envía el mensaje y la que la recibe.
Operación: Es una característica del
comportamiento de un clasificador que especifica
el nombre, tipo, parámetros y restricciones para
hacer valer un comportamiento asociado.
Universidad de Pamplona La academia al servicio de la vida.
3
Técnicas de mantenimiento.
Transición: Representa la relación entre un vértice
de origen y uno de destino; puede formar también
relaciones compuestas en las que cambia.
2.5 Diagramas en UML
Los diagramas son la manera de representar un
modelado en UML ya que son estos la esencia de
del mismo. Cada diagrama usa la anotación
pertinente y la suma de estos diagramas crean las
diferentes vistas. Las vistas existentes en UML
son:
a- Vista casos de uso: Se forma con los diagramas
de casos de uso, colaboración, estados y
actividades.
b- Vista de diseño: Se forma con los diagramas de
clases, objetos, colaboración, estados y actividades.
c- Vista de procesos: Se forma con los diagramas
de la vista de diseño. Recalcando las clases y
objetos referentes a procesos.
d- Vista de implementación: Se forma con los
diagramas de componentes, colaboración, estados y
actividades.
e- Vista de despliegue: Se forma con los
diagramas de despliegue, interacción, estados y
actividades.
Se Dispone de dos tipos diferentes de diagramas
los que dan una vista estática del sistema y los que
dan una visión dinámica. Los diagramas estáticos
son:
a- Diagrama de clases: Muestra las clases,
interfaces, colaboraciones y sus relaciones. Son los
más comunes y dan una vista estática del proyecto.
b- Diagrama de objetos: Es un diagrama de
instancias de las clases mostradas en el diagrama
de clases. Muestra las instancias y como se
relacionan entre ellas. Se da una visión de casos
reales.
c- Diagrama de componentes: Muestran la
organización de los componentes del sistema. Un
componente se corresponde con una o varias
clases, interfaces o colaboraciones.
d- Diagrama de despliegue: Muestra los nodos y
sus relaciones. Un nodo es un conjunto de
componentes. Se utiliza para reducir la
complejidad de los diagramas de clases y
componentes de un gran sistema. Sirve como
resumen e índice.
e- Diagrama de casos de uso: Muestran los casos
de uso, actores y sus relaciones. Muestra quien
puede hacer que y relaciones existen entre acciones
(casos de uso). Son muy importantes para modelar
y organizar el comportamiento del sistema.
Lo diagramas dinámicos son:
a- Diagrama de secuencia: Los Diagramas de
Secuencias muestran la forma en que un grupo de
objetos se comunican (interactúan) entre sí a lo
largo del tiempo.
b- Diagrama de colaboración: Muestran a los
diferentes objetos y las relaciones que pueden tener
entre ellos, los mensajes que se envían entre ellos.
Son dos diagramas diferentes, que se puede pasar
de uno a otro sin pérdida de información, pero que
nos dan puntos de vista diferentes del sistema. En
resumen, cualquiera de los dos es un Diagrama de
Interacción.
c- Diagrama de estados: muestra los estados,
eventos, transiciones y actividades de los diferentes
objetos. Son útiles en sistemas que reaccionen a
eventos.
c- Diagrama de actividades: Es un caso especial
del diagrama de estados. Muestra el flujo entre los
objetos. Se utilizan para modelar el funcionamiento
del sistema y el flujo de control entre objetos.
Como podemos ver el número de diagramas es
muy alto, en la mayoría de los casos excesivos, y
UML permite definir solo los necesarios, ya que no
todos son necesarios en todos los proyectos. En el
documento se dará una breve explicación de todos,
ampliándose para los más necesarios.
2.5.1 Diagramas recomendados
Los diagramas a representar dependerán del
sistema a desarrollar, para ello se efectúan las
siguientes recomendaciones dependiendo del
sistema. Estas recomendaciones se deberán adaptar
a las características de cada desarrollo, y
seguramente será la práctica lo que nos diga las
cosas que echamos en falta o los diagramas que
parecen ser menos necesarios. Según la aplicación
se recomiendan los siguientes diagramas:
Universidad de Pamplona La academia al servicio de la vida.
4
Técnicas de mantenimiento.
a- Aplicación monopuesto
Diagrama de casos de uso.
Diagrama de clases.
Diagrama de interacción.
b- Aplicación monopuesto, con entrada de
eventos:
Añadir: Diagrama de estados.
Aplicación cliente servidor:
Añadir: Diagrama de despliegue y diagrama de
componentes, dependiendo de la complejidad.
c- Aplicación compleja distribuida:
Todos.
Así tenemos que para una aplicación sencilla
debemos realizar entre tres y seis tipos de
diagramas, y para una aplicación compleja unos
nueve tipos. ¿Es esto demasiado trabajo? En un
principio no lo parece, ya que el tiempo dedicado a
la realización de los diagramas es proporcional al
tamaño del producto a realizar, no entraremos en la
discusión de que el tiempo de diseño no es tiempo
perdido si no ganado.
2.5.2 Ejemplos de algunos diagramas en UML
Fig. 1 Diagrama de casos de uso.
Fig.2 Diagrama de clases
Fig. 3 Diagrama de componentes
Fig. 4 Diagrama de despliegue.
2.6 Como puede utilizarse el UML para modelar
una gestión integrada de Mantenimiento?
Hoy las empresas están entendiendo que la
“Gestión Eficaz de Activos” es altamente
especializada y compleja, que es la fuente de
grandes ventajas competitivas, pero a su vez
también un área de extremo cuidado. Si bien son
diversas las estrategias de gestión, la
“Confiabilidad Operacional” se señala como la de
mayor ímpetu, pues permite implementar procesos
para alcanzar la Excelencia Organizacional.
La Optimización Integral del Mantenimiento
(MIO) plantea un enfoque global para desarrollar
sus funciones en el marco de la Confiabilidad
Operacional. Para ello debe cubrir cuatro áreas
vitales: Desarrollo del Talento Humano, Definición
de Estrategias de Gestión, Optimización de los
Activos Físicos, y de los Procesos y Sistemas de
Información.
La Gestión Integral del Mantenimiento, incluye
una serie de estrategias alineadas con la misión del
negocio, cuyo objetivo es lograr la Competitividad
Organizacional. Para alcanzarla existen cinco
factores claves: la seguridad, la Productividad, el
respeto por el medio ambiente y la Confiabilidad.
Con una modelación sobre el problema planteado
en la industria se puede hacer más fácil la gestión
integral de mantenimiento, para ello contamos con
Universidad de Pamplona La academia al servicio de la vida.
5
Técnicas de mantenimiento.
UML el cual es un lenguaje universal y sencillo de
entender y aplicar para un óptimo modelado en
cuestión de mantenimiento empresarial.
2.7 Como puede utilizarse el UML para modelar
una gestión Operacional?
Los administradores de operaciones son los
responsables de la producción de los bienes o
servicios de las organizaciones. Los
administradores de operaciones toman decisiones
que se relacionan con la función de operaciones y
los sistemas de transformación que se utilizan. La
administración de operaciones es el estudio de la
toma de decisiones en la función de operaciones,
La gestión de operaciones debe ayudar a la
empresa a ser más competitiva y las decisiones de
operaciones deben ser consistentes con las de otras
áreas. UML nos permite modelar de manera eficaz
y gestionar las operaciones de una empresa,
teniendo en cuenta que:
En la estrategia corporativa: en qué negocios
participa la empresa.
Estrategia del negocio: cómo competirá un negocio
dado (bajo costo, diferenciación del producto,
segmentación del mercado).
La estrategia de operaciones sigue a la estrategia
del negocio (como regla general).
2.8 Como puede utilizarse el UML, para
concebir un sistema de detección y diagnóstico
de fallas en una industria?
2.8.1 Análisis Causa Raíz
Las estructuras y modelado en UML de transición
robusta aplicada originalmente al control de
procesos con diferentes regímenes de operación, se
plantean como alternativa para la detección y el
diagnóstico de fallas. Una de las ventajas de este
método es la reducción en la complejidad
matemática inherente a muchas estructuras
aplicadas a la detección y el diagnóstico de fallas.
El esquema propuesto utiliza modelos matemáticos
paramétricos para caracterizar las fallas en los
instrumentos.
El RCA es un riguroso método de solución de
problemas, para cualquier tipo de falla, que utiliza
la lógica sistemática y el árbol de causa raíz de
fallas, usando la deducción y la verificación de los
hechos que conducen a las raíces originales.
Mediante la aplicación de la metodología se
determinaron las causas raíz reales de las
principales fallas de los equipos críticos de la
planta, se clasificaron y se establecieron las
actividades más convenientes a incluir en la Plan
General de Mantenimiento Proactivo.
Los pasos usados en la aplicación de la
metodología RCA fueron:
Describir el evento de la falla
Describir los modos de falla
Listar las causas potenciales de falla y verificar
Determinar y verificar las Causas Raíz
Físicas
Determinar y verificar las Causas Raíz
Humanas
Determinar y verificar las Causas Raíz del
Sistema
Fig. 5 Ejemplo de diagnóstico de fallas con UML
Universidad de Pamplona La academia al servicio de la vida.
6
Técnicas de mantenimiento.
2.9 Ejemplo de aplicación de UML en ing.
Eléctrica.
Fig. 6 UML aplicado a la ing. Eléctrica.
- En la fig. 5 los actores son: Clientes, la empresa
distribuidora de energía y el medidor inteligente. El
actor #1 es quien interactúa con el sistema, en este
caso es el cliente y la empresa distribuidora.
- El caso de uso # 2 representa las acciones que los
clientes realizan a fin de conseguir un objetivo
determinado. Estos casos de uso son: Solicitar
factura, actualizar servicio y procesar pago.
- Las asociaciones # 3 se conectan del caso de uso
al cliente o actor que solicita.
- Elk sistema de facturación o sistema #4 es el
sistema que se está desarrollando, el cual puede ser
un software, este muestra la medición de energía
consumida, envío de facturación de la empresa y la
comunicación con el cliente.
3. CONCLUSIONES
El empleo de UML conforma un conjunto de
soluciones de enorme utilidad y amplia aplicación
para el desarrollo empresarial en todo sentido, ya
sea en un sistema de detección de fallas, gestión de
mantenimiento o la gestión operacional en
cualquier ámbito, sea eléctrico, electrónico y
demás ramas de la ingeniería.
La exigencia de la gran mayoría de instituciones
dentro de su Plan Informático estratégico, es que
los desarrollos de software bajo una arquitectura en
Capas, se formalicen con un lenguaje estándar y
unificado. Es decir, se requiere que cada una de las
partes que comprende el desarrollo de todo
software de diseño orientado a objetos, se
visualice, especifique y documente con lenguaje
común.
Se necesitaba un lenguaje que fuese gráfico, a fin
de especificar y documentar un sistema de
software, de un modo estándar incluyendo aspectos
conceptuales tales como procesos de negocios y
funciones del sistema.
Este lenguaje unificado que cumple con estos
requerimientos, es ciertamente UML, el cual
cuenta con una notación estándar y semánticas
esenciales para el modelado de un sistema
orientado a objetos.
REFERENCIAS
J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy y
W. Lorensen - Object oriented modeling and
design. Prentice - Hall. 1991.
P. Muller - Modelaje con UML. Eyrolles, 1997.
SITIOS WEB
http://www.osmosislatina.com/lenguajes/uml/
http://www.monografias.com/trabajos5/insof/insof.
shtml
http://www.inflexa.com/jsp/template.jsp?pag=uml2
.htm&mnu=mnu-soluciones.jsp
www.ucema.edu.ar/~ey/Diapositivas_clase_1.ppt