UML. Una Metodología Orientada a Objetos aplicada a la
Anuncio
UML. Una Metodología Orientada a Objetos aplicada a la Reingeniería de la Empresa MIGUEL REBOLLO PEDRUELO Departamento de Sistemas Informáticos y Computación Universidad de Valencia El proceso de reingeniería busca construir el modelo de una situación real, con el fin de determinar su funcionamiento para mejorarlo posteriormente. Cuando el sistema que se considera es el mundo empresarial, se habla de reingeniería de la empresa. Para realizar este proceso se pueden utilizar herramientas que nacen del campo de la Infor mática, en concreto el análisis y diseño orientado a objetos. En el presente artículo se muestra cómo aplicar la metodología y el lenguaje UML al proceso de reingeniería de la empresa. Esta técnica permite determinar la estructura de la empresa y sus procesos internos y externos, de forma que es posible detectar y co rregir un posible malfuncionamiento, modificar su estructura para modernizarla, apli car técnicas de control, etc… usando unos mecanismos formales que garantizan su co rrección y facilitan la construcción de sistemas de información que soporten los nuevos procesos rediseñados. 1. INTRODUCCIÓN Ha llegado el momento de cambiar estructura, administración y desempeño de los negocios: entramos en el siglo XXI con empresas creadas en el siglo XX con las ideas del siglo XIX. Estos cambios están motivados, entre otras razones, por la fuerte variación que se ha producido en los clientes, en la competencia y en el propio proceso de cambio. Los clientes exigen productos y servicios diseñados a medida. Ya no se trata con un mercado masivo que está dispuesto a absorber cualquier producto, si no que saben lo que quieren, cuándo lo quieren, bajo qué condiciones y cuánto están dispuestos a pagar por ello. Otro aspecto importante es la naturaleza del cambio, que se ha convertido en algo general y permanente. Este cambio continuo ha reducido el ciclo de vida de los producESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000 106 MIGUEL REBOLLO PEDRUELO 498/00 tos, así como el tiempo disponible para diseñar e introducir otros nuevos [KOTLER, 95] [SERRANO, 94]. El problema actual es que muchas empresas parecen estar en decadencia. Los motivos a los que se achaca son muy diversos. Unos piensan que se debe a factores externos, sobre los que no se tiene control. Otros, a que no se da con el producto adecuado. Hay quienes deciden plantear nuevas estrategias corporativas para “salir de la crisis”, como cambios de mercado, pasarse a otro negocio o incluso manipular los activos. También están los que lo atribuyen a deficiencias en la administración y piensan que la solución es hacer cambios en la gestión de la empresa, variando su estructura departamental o el estilo de dirección. Muchos ven en la automatización el remedio a sus problemas. Para determinar qué ocurre realmente y cómo solucionar estos problemas hay que fijarse en las empresas que tienen éxito: son las que hacen mejor su trabajo. Lo que se debe mejorar es, entonces, la forma en la que se realizan las distintas tareas que se llevan a cabo en la empresa. 2. REINGENIERÍA DE LA EMPRESA 2.1. Concepto de reingeniería La reingeniería propone obtener una visión de la empresa a partir de sus procesos. “Es la revisión fundamental y el rediseño radical de procesos para alcanzar mejoras es pectaculares en medidas críticas y contemporáneas de rendimiento, tales como costes, calidad, servicio o rapidez” [HAMMER, 94], [P ÉREZ, 96]. Esta definición se basa en el concepto de proceso. Un proceso es un conjunto de actividades que recibe una o más entradas y crea un producto de valor para el cliente [FERNANDEZ, 96], [KUBECK, 95] [OULD, 94]. Esta definición es muy útil sobre todo a la hora de rediseñar los procesos: todo aquello que no aporte algo de valor al producto, o al menos no sea considerado como algo imprescindible, no debería formar parte del proceso rediseñado. Esto conlleva implícitamente una reducción en las tareas de control. Otra implicación de la visión de la empresa a través de sus procesos es la abolición de la división de éstos en tareas más sencillas (ALAN SMITH, 1776), que tiende a perder de vista el objetivo global. Las empresas rediseñadas suelen necesitar GENERALISTAS, no ESPECIALISTAS. La reingeniería consiste en empezar de cero, abandonando reglas anticuadas y supuestos fundamentales heredados. Este sistema para reformar la empresa tiene una serie de características comunes añadidas: ambición (no busca mejoras pequeñas), quebrantamiento de reglas y uso creativo de la informática. Dentro de esta revolución de las empresas, la Informática tiene un papel fundamental [WILEY, 94], [HAMMER, 94]. En primer lugar, no se debe confundir los cambios tecnolóESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000 499/00 UML. UNA METODOLOGÍA ORIENTADA A OBJETOS APLICADA A LA… 107 gicos con la automatización. Usar nuevas tecnologías debe suponer un cambio en la forma de trabajar y en los métodos empleados. La introducción de las tecnologías de la información ha favorecido la ruptura de una serie de reglas que hasta hace algunos años se consideraban inamovibles: • “La información sólo puede estar en un sitio”. Ahora, Las bases de datos distribuidas permiten disponer de la información allá donde es necesaria, sin duplicidad en los datos, manteniendo la información dispersa en diversas localizaciones. • “Sólo los expertos hacen el trabajo complejo”. Los sistemas expertos, como aplicación de las técnicas más novedosas de la Inteligencia Artificial, permiten a los usuarios consultar a los ordenadores como si de expertos en materias concretas se tratara. • “Escoger entre centralizar y descentralizar”. La proliferación de las redes de telecomunicaciones y el gran desarrollo de Internet permite mantener centralizado sólo lo imprescindible y repartir localmente la información necesaria, sin perder las ventajas de cada uno de estos métodos. • “Sólo los gerentes toman decisiones”. El desarrollo de los sistemas de ayuda a la toma de decisiones (DSS —Decision Support System—) permite a los usuarios consultar grandes bancos de datos con los que basar las decisiones que afectan directamente a su trabajo. Todo esto conlleva una serie de implicaciones que se deben traducir en un cambio en el comportamiento y la filosofía de una empresa. Estas implicaciones pueden resumirse en una: las compañías deben ser flexibles y rápidas en sus reacciones, tal y como exigen los clientes, la competencia y el mismo proceso de cambio. 2.2. Ingredientes para un proceso de reingeniería formal Un proceso formal de reingeniería incluye [JACOBSON, 94]: • una descripción que especifique todas las actividades involucradas y se adapte al proyecto de reingeniería; • modelos del negocio, centrados en la arquitectura y dinámica de la empresa. Han de ser diferentes a los modelos tradicionales, que fallan porque modelan la empresa como si fuera un ordenador con una base de datos y un programa que la manipula; • un proceso para el desarrollo de un sistema de información que esté realmente integrado en la empresa rediseñada. Un sistema así debe construirse en paralelo con los nuevos procesos de los negocios. ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000 108 MIGUEL REBOLLO PEDRUELO 500/00 Los procesos son rediseñados por un equipo de reingeniería, habitualmente compuesto por gente que procede de distintos ámbitos de la empresa. Para que este equipo pueda realizar su trabajo adecuadamente necesita: • un proceso formal para rediseñar la empresa; • herramientas para visualizar, explicar, comprobar y evaluar sus ideas, soluciones, decisiones y acciones; • modelos expresivos para la compañía rediseñada, que también son utilizados por el personal que construye los sistemas de información. Este último punto es especialmente importante, pues la Informática tiene un gran peso en el éxito de los nuevos procesos. Por eso, es importante que los modelos sean lo suficientemente expresivos y flexibles como para representar cualquier situación del mundo real, pero también deben ser formales y sin ambigüedades, de forma que no necesiten transformaciones ni interpretaciones para desarrollar el sistema de información que les dé soporte. La técnica que se propone en el presente artículo está basada en las siguientes ideas fundamentales: • Casos de uso (1). Constituyen una forma natural de identificar los procesos de la empresa. Los usuarios de la empresa hacen uso de ésta a través de procesos. Cada vía para “utilizar” la empresa es un caso de uso. • La metodología orientada a objetos (OO), que se expondrá en el siguiente apartado, es excelente para clasificar el trabajo interno de una empresa —sus procesos, productos, servicios, recursos, …— y cómo estos elementos dependen los unos de los otros. • El modelo de una empresa rediseñada se construye mediante la unión de la reingeniería de la empresa y una metodología de análisis y diseño orientado a objetos. 3. ANÁLISIS ORIENTADO A OBJETOS El paradigma orientado a objetos surge en los años 80 como un nuevo enfoque para el desarrollo de software. Sustituye a modelos anteriores, ya desfasados, que consideran la resolución de problemas mediante el modelo clásico de entrada → proceso → sali da o modelos basados en estructuras jerárquicas de información [PRESSMAN, 93]. Los objetos se emplean para representar una gran variedad de elementos del sistema: (1) Use cases” en el inglés original. ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000 501/00 UML. UNA METODOLOGÍA ORIENTADA A OBJETOS APLICADA A LA… 109 • entidades externas, ajenas al sistema pero que interactúan con él; • elementos físicos que forman parte del dominio del problema; • sucesos: operaciones que tienen lugar; • papeles o roles que desempeñan las personas que interactúan con el sistema; • unidades organizativas: estructuras que aglutinan los objetos en entidades de nivel superior; • lugares: establecen el contexto del problema y el funcionamiento general del sistema. El término “orientado a objetos” se aplica a multitud de campos: sistemas gestores de bases de datos, lenguajes de programación, metodologías de análisis y diseño… Un objeto es una entidad dinámica cuyo estado interno evoluciona a lo largo de su historia como consecuencia de la ocurrencia de eventos. Es el elemento que más se aproxima a cualquier entidad del mundo real, por lo que resulta un mecanismo muy intuitivo. Se basa en dos conceptos: la ocultación de información y los tipos abstractos de datos (TAD’s). El primero consiste en hacer inaccesibles algunas partes, ocultándolas a los usuarios, que sólo pueden acceder al estado interno del objeto a través de una interfaz concreta. Como un TAD, un objeto encapsula datos y operaciones. Los datos representan el estado de los objetos en un momento dado y las operaciones actúan sobre los datos para modificarlos [PASTOR, 93]. Un sistema construido con un método orientado a objetos se caracteriza porque sus componentes [PASTOR, 96]: • son “paquetes” que encapsulan estática (datos) y dinámica (funciones); • pueden heredar atributos y comportamiento de otras componentes; • se comunican a través de mensajes. 3.1. Conceptos fundamentales La entidad de más alto nivel es la clase. Una clase agrupa los objetos con un comportamiento similar, definiendo la estructura y el comportamiento común de todos los objetos que forman parte de ella. Puede verse como un esquema o un patrón de todos los objetos de la clase. Cada uno de los objetos se considera una instancia de esa clase. Surge la necesidad de distinguir las instancias de una misma clase, por lo que se recurre a la identificación de los objetos a través de una serie de variables, denominadas atributos, que describen su estado. Debe haber al menos una variable especial a través de la cual se pueda identificar de forma inequívoca a cada objeto. A esta variable se le denomina identificador. Los ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000 110 MIGUEL REBOLLO PEDRUELO 502/00 atributos pueden permanecer constantes o ir modificando su valor a lo largo de la vida del objeto. El comportamiento de un objeto se representa a través de las acciones que requiere a otros objetos y de las que él mismo ofrece a los demás. Las operaciones propias de un objeto se denominan métodos. Los objetos se comunican entre sí mediante mensa jes (operaciones indicadas en la especificación), que provocan la ejecución de dichos métodos. 3.2. Qué es UML UML (Unified Modeling Language —Lenguaje de Modelado Unificado—) es un lenguaje para la especificación, creación y documentación de sistemas informáticos, aunque puede utilizarse también para modelar cualquier tipo de sistemas, entre los que se encuentran las empresas [BOOCH, 97], [JACOBSON, 97], [RUMBAUGH, 97]. Proporciona una serie de conceptos de ingeniería útiles para el modelado de sistemas grandes y complejos. Además del lenguaje, junto con UML se propone una metodología de análisis y diseño orientado a objetos. La primera propuesta data de Septiembre de 1997. Fusiona los conceptos propuestos en las metodologías de BOOCH [BOOCH, 91], OMT [RUMBAUGH, 91] y OOSE [JACOBSON, 92]. Es un lenguaje (y una metodología) que debe aplicarse en un contexto de procesos y ese es, precisamente, el entorno necesario para aplicar la reingeniería de la empresa. El resultado es un proceso de desarrollo dirigido por casos de uso, con una arquitectura centralizada (aunque no excluye la posibilidad de modelar sistemas distribuidos), iterativo e incremental. UML es una arquitectura jerarquizada por niveles y organizada en paquetes. Dentro de cada paquete, los elementos del modelo se definen en términos de una sintaxis abstracta (diagrama de clases), reglas bien formadas (restricciones sobre el modelo) y una semántica. Incorpora todos los conceptos asumidos por la comunidad orientada a objetos. 3.3. Elementos básicos de UML UML utiliza una representación gráfica para modelar los sistemas. Cada diagrama tiene asociado un nombre, una notación y una semántica que proporciona un formalismo adecuado. Los diagramas que forman el modelo de un sistema genérico son los que se describen a continuación. 3.3.1. Diagrama de casos de uso Delimita el sistema a construir y define su funcionalidad. Utiliza dos elementos: los actores y los casos de uso. ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000 503/00 UML. UNA METODOLOGÍA ORIENTADA A OBJETOS APLICADA A LA… 111 Un caso de uso es una entidad funcional que representa un proceso en el modelo, visto como la secuencia de mensajes que intercambian el sistema y las entidades que interactúan con él (actores), junto con las acciones que realiza el sistema como respuesta a los estímulos externos. Un actor representa el papel que desempeña un elemento externo al sistema. Venta por teléfono Comprobar estado vendedor Realizar pedido cliente Despachar pedido dependiente Proporcionar crédito supervisor 3.3.2. Diagrama de clases Muestra la estructura estática del modelo, compuesto por todo aquello que puede existir en el mundo real (y es de relevancia para el sistema), su estructura interna y sus relaciones. Especifica las clases que forman el sistema, unidas por relaciones de dos tipos: asociación y generalización. Dentro de cada clase, se indica su estructura (atributos) y su comportamiento (métodos). CLIENTE Nif: String Nombre: String Cuenta corriente: Integer Realizar Compra () Solicitar Crédito (importe: Integer) Pedir Información (tema:String) Una clase se representa como un rectángulo dividido entres partes. En la primera de ellas se indica el nombre de la clase, en la segunda sus atributos (indicando su nombre y el tipo de datos que almacena) y en la tercera los métodos (su nombre y los argumentos que necesita). Las clases pueden relacionarse entre sí mediante generalización o mediante asociación. La generalización permite realizar una clasificación taxonómica entre clases más ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000 112 MIGUEL REBOLLO PEDRUELO 504/00 generales y otras más específicas, consistentes con las primeras y que añaden más información. A la clase general se le denomina superclase y a la específica subclase. Se representa mediante una flecha que parte de la subclase y termina en la superclase. La aso ciación es la relación más frecuente. Se utiliza para representar cualquier otro tipo de relación existente entre las clases (es-parte-de, es-un,… ). Se representa con una línea que une las dos clases relacionadas. A estas líneas se le pueden añadir distintos símbolos que indican sus propiedades y características. 3.3.3. Diagrama de secuencia Muestra cómo interactúan entre sí los objetos definidos en el modelo, así como los mensajes que intercambian. Normalmente, cada caso de uso tiene asociado un diagrama de secuencia que especifica cómo se desarrolla el proceso a lo largo del tiempo. emisor centralita receptor descolgar dar tono marcar n.º encaminar dar tono sonar descolgar parar tonos parar timbre Un diagrama de secuencia tiene dos dimensiones: la vertical representa el tiempo (en dirección descendente) y la horizontal los distintos objetos que intervienen. Cada objeto tiene asociado un eje vertical y los mensajes se representan como flechas que van de un eje a otro. 3.3.4. Diagrama de colaboración Muestra cómo colaboran los objetos del sistema entre sí, pero sin considerar el tiempo de forma explícita. Los elementos que lo componen son clases y los mensajes que se envían entre ellas. Con él se determina el comportamiento global de un proceso, así como los elementos que cooperan para realizar una determinada acción. Suele haber uno para cada caso de uso. ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000 505/00 UML. UNA METODOLOGÍA ORIENTADA A OBJETOS APLICADA A LA… 113 Nótese que tanto el diagrama de secuencia como el de colaboración expresan información similar. Por eso, normalmente, es suficiente construir sólo uno de ellos para modelar el sistema. Los diagramas de secuencia muestran de forma explícita el flujo de mensajes en el sistema, siendo más adecuados para modelos de tiempo real o escenarios complejos. Los diagramas de colaboración muestran relaciones entre los objetos y son mejores para comprender todos lo efectos que produce un objeto. 3.3.5. Diagrama de transición de estados Expresa la secuencia de estados en los que se puede encontrar un objeto durante su vida en el sistema, desde que se crea hasta que se destruye. Un objeto cambia de estado como respuesta a un cierto mensaje. Además, en función de su estado actual, el objeto responderá a un tipo de mensaje o a otro. Se representa mediante una máquina de esta dos [HOPCROF, 79], donde los símbolos de estado representan los posibles estados del objeto y las flechas corresponden a las transiciones entre estados. activo inválido 15 seg. marcar dígito 15 seg. levantar auricular tono de preparado marcar dígito marcando terminar marcar conectando ocioso tono de ocupado colgar auricular hablan- ocupado receptor contesta conectado sonando 3.3.6. Diagrama de actividad Es una variación de la máquina de estados, en la que cada estado es una actividad que representa la ejecución de una operación y las transiciones se disparan por su terminación. Representa un proceso completo o una parte de él, asociándose a un caso de uso, a una clase o a un método de una clase. Su propósito es centrar la atención en el flujo de control de un proceso interno del modelo. Los elementos de un diagrama de actividad son: ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000 114 MIGUEL REBOLLO PEDRUELO 506/00 • acciones: representan el estado asociado a una operación interna; • decisiones: expresan una bifurcación como consecuencia de la evaluación de una condición; • mensajes: indican el envío o la recepción de un mensaje. Marcar n.º [coste < 50$] Calcular coste enviar [coste ≥ 50$] recibir 4. REINGENIERÍA DE LA EMPRESA CON UML El equipo de reingeniería necesita modelos de los procesos de la empresa, centrando la atención en aquellos elementos y relaciones que resulten significativos. UML es un lenguaje y una metodología adecuada para modelar el funcionamiento actual de la empresa, pues permite detectar posibles errores de concepto y mejoras eventuales de los procesos, y también para diseñar los procesos nuevos. La metodología a seguir con UML favorece un ciclo de vida en espiral para el modelado, en contraposición con los ciclos de vida secuenciales clásicos (en los que las tareas de especificación, análisis, diseño, implementación y mantenimiento se realizan en estricto orden) [PRESSMAN, 93]. El ciclo de vida en espiral es un proceso que construye el sistema final de forma incremental, partiendo de las especificaciones iniciales y generando prototipos cada vez más refinados y completos, que valida el usuario. El primer paso consiste en obtener los requerimientos de los procesos rediseñados, que normalmente se le suministran al equipo de reingeniería (o genera él mismo) en forma de enunciado. A continuación se realiza el análisis y diseño de estos procesos partiendo de cero. En esta fase, el equipo construye todos los diagramas propuestos en UML, con los que el proceso queda completamente especificado. 1. Se comienza con el diagrama de casos de uso, que limita el modelo a construir identificando elementos internos y externos a la empresa, así como los procesos fundamentales que realiza. 2. Después se construye el diagrama de clases, que contiene todos los objetos relevantes que intervienen en los procesos rediseñados. 3. Dependiendo de las características de los procesos, se debe escoger entre utilizar un diagrama de secuencia o uno de colaboración para cada caso de uso. En cualquier caso, deben figurar al menos una vez cada una de las clases definidas en el diagrama anterior. Si alguna no interviene, debe eliminarse del modelo. AsiESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000 507/00 UML. UNA METODOLOGÍA ORIENTADA A OBJETOS APLICADA A LA… 115 mismo, todos los mensajes tienen que estar definidos como métodos de las clases que les dan soporte. 4. Un diagrama de transición de estados por cada clase, aunque en ocasiones puede utilizarse para una jerarquía de generalización completa. Muestra también los mensajes que provocan los cambios de estado, definidos en el diagrama de clases. 5. El último es el diagrama de actividad, que muestra con detalle la secuencia de acciones que se debe seguir para ejecutar un proceso o un método de una clase y los puntos de sincronismo con las demás tareas (envío/recepción de mensajes). Todos estos diagramas constituyen un modelo de la empresa rediseñada. Si es necesario, se puede incluso construir un prototipo de sistema de información que proporcione un soporte informático básico al modelo inicial. Este modelo es el primer resultado del equipo de reingeniería, pero no necesariamente el definitivo. Los diagramas se deben revisar, refinándolos más o corrigiendo y modificando algún componente. El modelo revisado constituye un segundo prototipo de la empresa. Este proceso continua hasta que se considere que el modelo refleja exactamente la empresa rediseñada. 5. EJEMPLO DE APLICACIÓN ARIMEZ S.A. es una empresa constructora cuya actividad se centra principalmente en realizar grandes obras para el sector público. Una entidad saca a concurso público la adjudicación de una obra, publicándolo en el B.O.E. y en el de la provincia, así como en dos periódicos de tirada nacional. ARIMEZ acude a la administración correspondiente para obtener una copia del proyecto para su evaluación. La oficina técnica, con el apoyo del departamento de administración, lo estudia y confecciona una propuesta, especificando (si procede) una baja en el importe del presupuesto o en tiempo de ejecución sobre el proyecto inicial. Esta propuesta se envía en la entidad. Cuando finaliza el plazo de presentación de ofertas, la entidad resuelve el concurso público y adjudica la obra a una empresa determinada. En el plazo de 7 días se firma el contrato, asumiendo la cuantía y duración especificadas en la propuesta y fijando un calendario para la ejecución de la obra. Periódicamente, la entidad supervisa el estado de la obra, realizando una serie de mediciones sobre el volumen de trabajo realizado. Con los resultados de estas mediciones, se elabora una valoración y la entidad emite una certificación y abona a ARIMEZ la cantidad correspondiente. Cuando ARIMEZ concluye la obra, la entidad emite una última certificación y, en el caso de que se haya ejecutado un volumen distinto al presupuestado, realiza una liquidación por la diferencia, tras la cual el proyecto se da por concluido. En ese momento, comienza un periodo de garantía, pasado el cual se archiva el proyecto. ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000 116 MIGUEL REBOLLO PEDRUELO 508/00 5.1. Diagrama de casos de uso Las tareas principales en las que se ve involucrada ARIMEZ pueden resumirse en tres procesos fundamentales: la confección de propuestas para proyectos, la adjudicación o rechazo de las propuestas en concurso público y la certificación de los trabajos realizados a medida que avanza la obra. Cada uno de estos procesos se modela como un caso de uso. Confeccionar propuesta Entidad Oficina técnica Adjudicar Certificar Dpto. Administración Los actores, elementos activos de estos procesos, son: la entidad pública (externo) y la oficina técnica y el departamento de administración (internos). 5.2. Diagrama de clases El diagrama de clases muestra todos los objetos, activos o pasivos, que intervienen en los procesos de ARIMEZ (2). Las clases principales del modelo aparecen agrupadas en una jerarquía de generalizaciones que tiene el proyecto como superclase. La propuesta es una subclase del proyecto, al que se le añade la baja que oferta la empresa (frecuentemente, expresada en porcentaje). Las propuestas, tras la resolución del concurso, se clasifican en acaptadas o rechazadas. Esta clasificación de las propuestas aparece en el diagrama como una nueva generalización. Tras la firma del contrato, la propuesta adjudicada recibe más información (como la fecha de inicio y la de finalización), pasando a ser una obra en ejecución. Cuando termina, se le añaden los datos reales de ejecución y se archiva. Una obra archivada es a su vez una subclase de la obra en ejecución. Los documentos que se generan en el proceso también se modelan como clases. En el caso de ARIMEZ, los únicos documentos que se especifican son las certificaciones y la liquidación final. Deben asociarse a la clase que los genera (la entidad) y a la (2) Por motivos de espacio y de complejidad del diagrama, sólo aparece el nombre de las clases y las relaciones que existen entre ellas. Para que el diagrama sea completo, se debe indicar, para cada clase, todos sus atributos y todos sus métodos. ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000 509/00 UML. UNA METODOLOGÍA ORIENTADA A OBJETOS APLICADA A LA… 117 proyecto 1..n. 1..n. estudia 1..n. 1..n. elabora 1..n. elabora propone propuesta evalúa 1 1 oficina técnica 1 1 1 rechazada entidad 1 1 adjudicada emite dpto. administración cobra 1..n. certificación abona 1..n. 1 1 1..n. ejecución 1 realiza liquida 1..n. liquidación 1 archivada clase que los recibe (una obra en ejecución). Se unen a través de asociaciones, que se etiquetan con un nombre y una cardinalidad (el número de instancias con las que se relaciona).Así, una entidad emite una o varias certificaciones (marcado como 1..n), y cada certificación sólo es emitida por una entidad (marcada como 1). Por último, deben aparecer los actores del diagrama de casos de uso (3), relacionados mediante asociaciones con las clases sobre las que interactúan directamente. 5.3. Diagrama de secuencia Cada proceso de ARIMEZ debe tener un diagrama de secuencia o de colaboración asociado. La figura muestra el diagrama de secuencia asociado al proceso de certificación de la obra (ver enunciado). Los menajes muestran el flujo de información a lo largo de este proceso. En el modelo inicial, la certificación está unida a la finalización de la obra. En un futuro refinamiento, se puede considerar la posibilidad de separar este proceso en dos, uno dedicado exclusivamente a la certificación y otro que modela las acciones que se realizan al finalizar la obra (última certificación, liquidación y periodo de garantía). (3) Algunos actores pueden corresponder a entidades externas sobre las que no se desea almacenar ningún tipo de información. En ese caso, no aparecen en el diagrama de clases. ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000 118 MIGUEL REBOLLO PEDRUELO dpto. admón. ejecución certificación 510/00 entidad archivada supervisar resultado emitir abonar cobrar liquidar finalizar 5.4. Diagrama de transición de estados Cada clase del modelo tiene asociado un diagrama de transición de estados, que muestra cómo evoluciona en el sistema a lo largo de su vida. Se puede emplear un solo diagrama para representar toda una red de generalizaciones, tal y como muestra este caso. proyectada certificar realizar propuesta ofertada adjudicada adjudicar en ejecución firmar en garantía liquidar rechazar finalizar plazo rechazada archivada Una obra arranca en estado “proyectada” y a medida que le llegan distintos eventos (realizar propuesta, aceptar/rechazar,…) va cambiando de estado. Algunas clases están representadas por un único estado (como la clase adjudicada), pues un evento de cambio de estado hace que también cambie de clase (al firmarla, pasa a ser una obra en ejecución). ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000 511/00 UML. UNA METODOLOGÍA ORIENTADA A OBJETOS APLICADA A LA… 119 5.5. Diagrama de actividad El último paso antes de dar por concluido el modelo consiste en especificar con más detalle cada una de las tareas que se realizan en el sistema, bien desde el punto de vista de los procesos o bien ofreciendo un mayor nivel de detalle, modelando los métodos de las clases. Inicio emitir propuesta estudiar rechazada aceptada firmar contrato fin El diagrama de la figura muestra la secuencia de acciones que debe realizarse en el proceso de adjudicación de una obra a una empresa. Nótese que, en el caso de que se modelen procesos, los diagramas que resultan son muy parecidos a los diagramas de secuencia, pero especificando con detalle las acciones que se realizan entre los lanzamientos de los mensajes. 6. CONCLUSIONES En el presente artículo se ha descrito cómo aplicar la metodología orientada a objetos en el entorno empresarial. El empleo de este tipo de técnicas permite modelar sistemas de forma sencilla, sin tener que utilizar artificios y abstracciones complejas. Así, no es necesario disponer de conocimientos informáticos profundos para elaborar los diagramas y construir un sistema de información acorde con la realidad de la empresa que se está modelando. Incluso existen herramientas CASE (4) que traducen los esquemas a código directamente implementable en un ordenador, generando el software que da soporte al sistema de información. Las ventajas de emplear los objetos son claras. La más importante es que se trata de un modelo formal, es decir, la especificación del sistema se describe mediante una sintaxis y una semántica formales, basadas en conceptos matemáticos, que permite eliminar ambigüedades e inconsistencias en el modelo y que dan rigor y robustez a los sistemas. Los conceptos que utiliza están próximos al mecanismo cognitivo humano. Desde el (4) Computer Aided Sowftare Engineering (Ingeniería del Software Asistida por Computador). Son herramientas que proporcionan un soporte automático o semiautomático para las fases de análisis y diseño de sistemas informáticos, apoyado por controles de coherencia internos, análisis de los modelos, facilidades de documentación, etc… ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000 120 MIGUEL REBOLLO PEDRUELO 512/00 punto de vista del diseñador, ofrecen una visión conjunta de la estática y la dinámica del sistema, aportando grandes ventajas sobre los métodos centrados sólo en los datos (modelo entidad-relación [CHEN, 76]) o en los procesos (análisis y diseño estructurado [GANE, 81]). Los modelos que resultan son escalables, simplificando las ampliaciones sobre el modelo, lo que favorece el ciclo de vida en espiral. UML proporciona una metodología que reúne los conceptos asumidos por la comunidad orientada a objetos. El resultado es un lenguaje de propósito general, útil para rediseñar los procesos de la empresa y que favorece la comunicación entre distintos equipos al facilitar diagramas claros, sencillos, expresivos, flexibles y formales. 7. BIBLIOGRAFÍA [BOOCH, 91] BOOCH, G. “Object Oriented Design with Applications”, Benjamin Cummings Publishing Company (1991). [BOOCH, 97] BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. “Unified Modeling Language User’s Guide”, Addison-Wesley (1997). [CHEN, 76] CHEN, P. “The Entity-Relationship Model. Towward a Unified View of Data”, ACM Transactions on Database Systems 1, 1 (Mar. 1976). [FERNANDEZ, 96] FERNANDEZ, M. A. “El Control, Fundamento de la Gestión por Proce sos”, ESIC Editorial (1996). [GANE, 81] GANE C.; S ARSON T. “Análisis Estructurado de Sistemas”, Ed. Librería “El Ateneo”, (1981). [HAMMER, 94] HAMMER, M.; CHAMPY, J. “Reingeniería de la empresa”, Paramón (1994). [HOPCROF, 79] H OPCROF, J. Z.; ULLMAN, J. D. “Introduction to Automata Theory. Lan guages and Computation”, Addison-Wesley (1979). [JACOBSON, 92] JACOBSON, I. “Object-Oriented Software Engineering: An Use Case Dri ven Approach”, Addison-Wesley (1992) [JACOBSON, 94] JACOBSON, I. “The Object Advantage”, Addison-Wesley (1994) [JACOBSON, 97] J ACOBSON I.; BOOCH, G.; R UMBAUGH, J. “The Objectory Software Deve lopment Process”, Addison-Wesley (1997). [KOTLER, 94] KOTLER, P. “Dirección de Marketing”, Prentice-Hall (1994). [KUBECK, 95] KUBECK, L. C. “Techniques for Business Process Redesign”, JOHN WILEY & S ONS (1995). [OULD, 94] OULD, M. A. “Business Processes”, John Wiley & Sons (1994). [PASTOR, 93] P ASTOR, O.; SICOL, J. J.; HERRERO, M. “Modelos Semánticos y Modelos Orientados a Objetos”, Universidad Politécnica de Valencia (1993). [PASTOR, 96] PASTOR, O. “Análisis Orientado a Objetos. Conceptos y Metodologías”, Internal Report, Dpto. de Sistemas Informáticos y Computación, Universidad Politécnica de Valencia (1996). ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000 513/00 UML. UNA METODOLOGÍA ORIENTADA A OBJETOS APLICADA A LA… 121 [PEREZ, 96] PÉREZ-FERNANDEZ, J. A. “Gestión por procesos. Reingeniería y mejora de los procesos de la empresa”, ESIC Editorial (1996). [PRESSMAN, 93] PRESSMAN, R. S. “Ingeniería del Software. Un enfoque práctico”, M CGRAW-HILL (1993). [RUMBAUGH, 91] R UMBAUGH, J. “Object Oriented Modeling and Design”, Prentice-Hall (1991). [RUMBAUGH, 97] R UMBAUGH, J.; BOOCH, G.; J ACOBSON, I. “Unified Modeling Language Reference Manual”, Addison-Wesley (1997). [SERRANO, 95] SERRANO, F. “Temas de Introducción al marketing”, ESIC Editorial (1995). [TAYLOR, 95] TAYLOR, D. A. “Business Engineering with Object Technology”, John Wiley & Sons (1995). [WILEY, 94] Varios autores. “Software Assistance for Bussines Re-Engineering”, J OHN WILEY & SONS (1994). ESIC MARKET. SEPTIEMBRE-DICIEMBRE 2000
