Introducción a UML Antecedentes evolución conjunta proporcionar estabilidad

Transcripción

1 2.2 Introducción a UML Antecedentes En cualquier desarrollo de un sistema de información, es indispensable contar con ciertas reglas para comunicarse con cada uno de los miembros del equipo de desarrollo, usuarios y clientes. A través del esfuerzo de varios profesionales en la industria de software, se ha llegado a una notación estándar para el análisis y diseño de sistemas. Esta notación se llama UML (Unified Model Language), el cual ha resuelto un gran problema de comunicación entre los desarrolladores, unificando la simbología de diversos autores en una sola notación. No importa que metodología ocupes, te podrás comunicar con tu equipo de trabajo siempre y cuando conozcan y comprendan los componentes y reglas que conforman UML. Una masa crítica de ideas comenzó a formarse en la primera mitad de los años 90, cuando Grady Booch (Rational Software Corporation), James Rumbaugh (General Electric), Ivar Jacobson (Objectory) y otros empezaron a adoptar ideas de los métodos orientados a objetos existentes, los cuales habían sido reconocidos unánimemente como los tres principales métodos orientados a objetos a nivel mundial. Los creadores de los métodos Booch, OOSE y OMT se sintieron motivados para crear un lenguaje unificado de modelado por tres razones: 1. Cada uno de los métodos ya estaba evolucionado independientemente hacia los otros dos. Tenía más sentido continuar esta evolución en forma conjunta en vez de hacerlo por separado, eliminando la posibilidad de cualquier diferencia gratuita e innecesaria que confundiría aún más a los usuarios de los métodos. 2. Al unificar lo métodos, se podría proporcionar cierta estabilidad al mercado orientado a objetos haciendo posible que los proyectos se asentaran sobre un lenguaje de modelado maduro y permitiendo a los constructores de herramientas que se centraran en proporcionar más características útiles.

2 3. Se esperaba que su colaboración introdujera una mejora en los tres métodos anteriores, ayudándose a partir de las lecciones aprendidas y tratando problemas que ninguno de los métodos había manejado bien anteriormente. Cuando comenzaron con la unificación, establecieron tres metas para su trabajo: 1. Modelar sistemas, desde el concepto hasta los artefactos ejecutables, utilizando técnicas orientadas a objetos. 2. Tratar las cuestiones relacionadas con el tamaño inherente a los sistemas complejos y críticos. 3. Crear un lenguaje de modelado utilizable tanto por personas como por máquinas. El esfuerzo para la definición de UML, comenzó en octubre de 1994, cuando Rumabaugh se unió a Booch en Rational. El objetivo inicial del proyecto fue la unificación de los métodos de Booch y OMT. El borrador de la versión 0.8 del Método Unificado (como fue llamado entonces) se publicó en octubre de Por esa época, Jacobson se unió y el alcance del proyecto UML se amplió para incorporar OOSE. Los esfuerzos se plasmaron en los documentos de la versión 0.9 en junio de Durante 1996, se pidió y recibió retroalimentación de la comunidad internacional relacionada con la ingeniería de software. Durante este periodo, también se vio claro que muchas organizaciones de software veían a UML como un punto estratégico en su negocio. Se estableció un consorcio de UML, con varias organizaciones que querían dedicar recursos para trabajar hacia una definición fuerte y completa de UML. Las organizaciones que contribuyeron a la definición de la versión 1.0 de UML fueron Digital Equipment Corporation, Hewlet-Packard, I-Logix, Intellicorp, k Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Intruments y Unisys. Esta colaboración produjo UML 1.0, un lenguaje de modelado bien definido, expresivo, potente y aplicable a un amplio espectro de dominios de problemas. Mary Loomis fue decisiva para convencer al Object Management Group (OMG) de que emitiera una solicitud de propuestas (RFP, Request For Proposals) para un lenguaje de modelado

3 estándar. UML 1.0 se ofreció para estandarización al OMG en enero de 1997, en respuesta su solicitud. Entre enero y julio de 1997, el grupo inicial de colaboradores se amplió para incluir prácticamente a todas las demás organizaciones que habían enviado alguna propuesta o habían contribuido en alguna medida en las respuesta iniciales al OMG, incluyendo a Anderson Consulting, Ericsson, ObjectTime Limited, Platinum technology, PTech, Recih Technologies, Softeam, Sterling Software y Taskon. Se formó un grupo de trabajo para la semántica, liderado por Cris Kobryn de MCI Systemhouse y coordinado por Ed Eykholt de Rational, para formalizar la especificación de UML y para integrar UML con otros esfuerzos de estandarización. Una versión revisada de UML (la versión 1.1) se ofreció al OMG para su estandarización en julio de En septiembre de 1997, esta versión fue aceptada por la OMG Analysis and Design Task Force (ADTK) y el OMG Architecture Borrad y se sometió a voto de todos los miembros del OMG. UML 1.1 fue adoptado por el OMG el 14 de noviembre de Durante varios años, el mantenimiento de UML fue asumido por la OMG 1 Revision Task Force, que creó las versiones 1.3, 1.4 y 1.5. Del año 2000 al 2003, un conjunto nuevo y ampliado de colaboradores creó una especificación actualizada de UML, versión 2.0. Esta versión fue revisada durante un año por una Finalization Task Force (FTF) liderada por Bran Selic, de IBM, y el OMG adoptó la versión oficial de UML 2.0 a principios de UML 2.0 es una revisión importante de UML 1, e incluye muchas características adicionales. Además, se hicieron muchos cambios a los elementos previos a partir de la experiencia con la versión anterior UML como notación UML es un lenguaje. Un lenguaje proporciona un vocabulario y reglas para combinar sus palabras con el objetivo de posibilitar la comunicación. Un lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la representación conceptual 1 Los documentos de la especificación actual de UML se encuentran en la página web del OMG en 2 Grady Booch, et al El Lenguaje Unificado de Modelado 2.0, pp. XVII XIX.

4 y física de un sistema. Un lenguaje de modelado como UML es un lenguaje estándar para los modelos de software. El vocabulario y las reglas de un lenguaje como UML indican cómo crear y leer modelos bien formados, pero no dice qué modelos se deben crear ni cuándo crearlos. Ésta es la tarea del proceso de desarrollo de software. Un proceso bien definido guiará a los usuarios al decidir cuáles artefactos producir, qué actividades y qué personal se emplea para crearlos y gestionarlos, y cómo usar esos artefactos para medir y controlar el proyecto de forma global. UML es un lenguaje para visualizar. Para muchos programadores, la distancia entre pensar en una implementación y transformarla en código es casi nula. Lo piensas, lo codificas. De hecho, algunas cosas se modelan mejor directamente en código. El texto es un medio maravilloso para escribir expresiones y algoritmos de forma concisa y directa. UML es algo más que un simple montón de símbolos gráficos. Detrás de cada símbolo en la notación UML hay una semántica bien definida. De esta manera, un desarrollador puede escribir un modelo en UML, otro desarrollador o incluso otra herramienta puede interpretar ese modelo sin ambigüedad. UML es un lenguaje para especificar. En este caso, especificar significa construir modelos precisos, no ambiguos y completos. En particular UML cubre la especificación de todas las decisiones de análisis, diseño e implementación que deben realizarse al desarrollar y desplegar un sistema con gran cantidad de software. UML es un lenguaje para construir. UML no es un lenguaje de programación visual, pero sus modelos pueden conectar en forma directa a una gran variedad de lenguajes de programación. Esto significa que es posible establecer correspondencias desde un modelo UML a un lenguaje de programación como Java, C++ o Visual Basic, o incluso a tablas en una base de datos relacional o al almacenamiento persistente en una base de

5 datos orientada a objetos. Las cosas que se expresan mejor gráficamente también se representan gráficamente en UML, mientras que las cosas que se expresan mejor textualmente se plasman con el lenguaje de programación. UML es un lenguaje para documentar. Una organización de software que trabaje bien produce toda la clase de artefactos, además de código ejecutable. Estos artefactos incluyen (sin ser limitativa): requerimientos, arquitectura, diseño, código fuente, planeación de proyectos, pruebas, prototipos y versiones. Dependiendo de la cultura de desarrollo, algunos de estos artefactos se tratan más o menos formalmente que otros. Tales artefactos no son tan sólo los entregables de un proyecto, también son críticos para el control, la medición y comunicación que requiere un sistema durante su desarrollo y después de su despliegue Conceptos principales de UML El vocabulario de UML incluye tres clases de bloques básicos: Elementos. Relaciones. Diagramas. Los elementos son abstracciones que constituyen las partes de primera clase en un modelo; las relaciones ligan estos elementos entre sí; los diagramas agrupan colecciones interesantes de elementos. Estructurales elementos Comportamiento UML Agrupación Anotación Figura 2.3 Elementos en UML

6 Elementos estructurales Los elementos estructurales son los nombres de los modelos UML. En su mayoría son las partes estáticas de un modelo y representan conceptos o cosas materiales. Colectivamente los elementos estructurales se denominan clasificadores. Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase implementa una o más interfaces. Gráficamente una clase se representa como un rectángulo, que normalmente incluye su nombre, atributos y operaciones. 3 Curso +nombre +creditos +crear() +modificar() +eliminar() Figura 2.4. Clase Una interfaz es una colección de operaciones que especifican un servicio de una clase o componente. Por tanto, una interfaz describe el comportamiento visible externamente, de ese elemento. Una interfaz puede representar el comportamiento completo de una clase o componente o sólo una aparte de él. Una interfaz define un conjunto de operaciones que se compromete a realizar, pero nunca define la implementación de las operaciones. La declaración de una interfaz se asemeja a la de una clase con la palabra interfaz sobre el nombre; los atributos no son relevantes, excepto algunas veces, para mostrar constantes. Una interfaz raramente se encuentra aislada. Cuando una clase proporciona una interfaz al mundo externo, ésta se representa como una pequeña circunferencia unida al rectángulo que representa a la clase por una línea. 4 3 Ibidem, p Ibidem, p. 21.

7 <<interfaz>> ICurso +crear() +modificar() +eliminar() Curso IVentana Figura 2.5. Interfaz Una colaboración define una interacción y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamiento de sus elementos. Las colaboraciones tienen tanto una dimensión estructural como una de comportamiento. Una clase dada o un objeto pueden participar en varias colaboraciones. Estas colaboraciones representan la implementación de patrones que configuran un sistema. Gráficamente, una colaboración se representa como una elipse de borde discontinuo, que normalmente incluye sólo su nombre. 5 Colaboración Administración Cursos Figura 2.6. Colaboración Un caso de uso es una descripción de un conjunto de secuencias de acciones que ejecuta un sistema y que produce un resultado observable de interés para un actor particular. Un caso de uso se utiliza para estructurar los aspectos de comportamiento de un modelo. Un caso es realizado por una colaboración. Gráficamente, un caso de uso se representa como una elipse de borde continuo y normalmente incluye sólo su nombre. 6 5 Idem. 6 Ibidem, p 22.

8 Administrar Cursos Figura 2.7. Caso de uso Los cuatro elementos estructurales restantes (clases activas, componentes, artefactos y nodos). Son todos similares a las clases, en cuanto que también describen un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Sin embargo, estos cuatro son suficientemente diferentes y son necesarios para modelar ciertos aspectos de un sistema orientado a objetos; así que está justificado un tratamiento especial. Una clase activa es una clase cuyos objetos tiene uno o más procesos o hilos de ejecución y, por tanto, pueden dar origen a actividades de control. Una clase activa es igual que una clase, excepto que sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos. Gráficamente, una clase activa se representa como una clase, pero con líneas dobles en la derecha y en la izquierda, normalmente incluye su nombre, atributos y operaciones. 7 GestorDeEventos +suspender() +vaciarcola() Figura 2.8. Clase activa Un componente es un parte modular del diseño del sistema que oculta su implementación tras un conjunto de interfaces externas. En un sistema, los componentes que comparten las mismas interfaces pueden sustituirse siempre y cuando conserven el mismo comportamiento lógico. La implementación de un componente puede expresarse conectando partes y conectores; las partes pueden 7 Idem.

9 incluir componentes más pequeños. Gráficamente, un componente se representa como una clase con un icono especial en la esquina superior derecha. 8 FormaRegistroInscripcion Figura 2.9. Componente Los dos elementos restantes (artefactos y nodos) también son diferentes. Representan elementos físicos, mientras que los seis elementos anteriores representan cosas conceptuales o lógicas. Un artefacto es una parte física y reemplazable de un sistema que contiene información física (bits). En un sistema hay diferentes tipos de artefactos de despliegue, como archivos de código fuente, ejecutables y scripts. Un artefacto representa típicamente el empaquetamiento físico de código fuente o información en tiempo de ejecución. Gráficamente, un artefacto se representa como un rectángulo con la palabra clave artifact sobre el nombre. 9 <<artifact>> ventada.dll Figura Artefacto Se denomina un nodo como un elemento físico que existe en tiempo de ejecución y representa un recurso computacional, que por lo general dispone de algo de memoria, y con frecuencia, capacidad de procesamiento. También puede residir en un nodo un conjunto de artefactos; también se puede migrar de un nodo a otro. Gráficamente, un nodo se representa como un cubo, incluyendo normalmente sólo su nombre. 8 Idem. 9 Ibidem, p 23.

10 Servidor Figura Nodo Elementos de comportamiento Los elementos de comportamiento son las partes dinámicas de los modelos UML. Éstos son los verbos de un modelo y representan comportamiento en el tiempo y en el espacio. En total hay tres tipos principales de elementos de comportamiento. Una interacción es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular, para alcanzar un propósito específico. El comportamiento de una sociedad de objetos o una operación individual puede especificarse con una interacción. Una interacción involucra a muchos otros elementos, mensajes, acciones y enlaces (conexiones entre objetos). Gráficamente, un mensaje se muestra con una línea dirigida, incluyendo casi siempre el nombre de su operación. 10 enviargrupo Figura Interacción Una máquina de estados es un comportamiento que especifica las secuencias de estados por las que pasa un objeto o una interacción durante su vida en respuesta a eventos, junto con sus reacciones a estos eventos. El comportamiento de una clase individual o una colaboración de clases puede especificarse con una máquina de estados. Una máquina de estados involucra a otros elementos, incluyendo estados, transiciones (el flujo de un estado a otro), eventos (que dispara una transición) y actividades (la respuesta a una transición). Gráficamente, un estado se representa 10 Ibidem, p. 24.

11 como un rectángulo de esquinas redondeadas, que incluye normalmente su nombre y sus subastados, si los tiene. 11 Esperando Figura Máquina de estado Una actividad es un comportamiento que especifica la secuencia de pasos que ejecuta un proceso computacional. En una interacción, el énfasis se pone en el conjunto de objetos que interactúan. En una máquina de estados, el énfasis se pone en el ciclo de vida de un objeto cada vez. En una actividad, el énfasis se pone en los flujos entre los pasos, sin mirar qué objeto ejecuta cada paso. Un paso de una actividad se denomina una acción. Gráficamente, una acción se representa como un rectángulo con las esquinas redondeadas, con un nombre que indica su propósito. Los estados y las acciones se distinguen por sus diferentes contextos. 12 procesar inscripción Figura Actividad Estos tres elementos (interacciones, máquinas de estados y actividades) son los elementos básicos de comportamiento que se pueden incluir en modelo UML. Semánticamente, estos elementos están conectados normalmente a diversos elementos estructurales, principalmente clases, colaboraciones y objetos. Elementos de agrupación Los elementos de agrupación son las partes organizativas de los modelos UML. Éstos son las cajas en las que puede descomponerse un modelo. Hay un tipo principal de elementos de agrupación: los paquetes. 11 Idem. 12 Ibidem, p. 25

12 Un paquete es un mecanismo de propósito para organizar el propio diseño, en oposición a las clases, que organizan construcciones de implementación. Los elementos estructurales, los elementos de comportamiento e incluso otros elementos de agrupación pueden incluirse en un paquete. Al contrario que los componentes (que existe en tiempo de ejecución), un paquete es puramente conceptual (sólo existe en tiempo de desarrollo). Gráficamente, un paquete se visualiza como una carpeta, que normalmente sólo incluye su nombre y, a veces, su contenido. 13 Reglas del Negocio Figura Paquete Los paquetes son los elementos de agrupación básica con los cuales se puede organizar un modelo UML. También hay variaciones, tales como los frameworks, los modelos y los subsistemas (tipos de paquetes). Elementos de anotación. Los elementos de anotación son las partes explicativas de los modelos UML. Son comentarios que se pueden aplicar para describir, clarificar y hacer observaciones sobre cualquier elemento de un modelo. Hay un tipo principal de elemento de anotación llamado nota. Una nota es simplemente un símbolo para mostrar restricciones y comentarios junto a un elemento o una colección de elementos. Gráficamente, una nota se representa como un rectángulo con una esquina doblada, junto con un comentario textual o gráfico. investigar las políticas para hacer una inscripción Figura Nota 13 Idem.

13 Este elemento es el objeto básico de anotación que se puede incluir en un modelo UML. Típicamente, las notas se utilizarán para adornar los diagramas con restricciones o comentario que se expresen mejor en texto informal o formal. También hay variaciones sobre este elemento, tales como los requisitos (que especifican algún comportamiento deseado desde la perspectiva externa del modelo). Relaciones en UML.- Hay cuatro tipos de relaciones en UML: Dependencia. Asociación. Generalización. Realización.

14 Estas cuatro son los bloques básicos de construcción para relaciones en UML y se utilizan para escribir modelos bien formados: Una dependencia es una relación semántica entre dos elementos, en la cual un cambio a un elemento (el elemento independiente) puede afectar a la semántica del otro elemento (el elemento dependiente). Gráficamente, una dependencia se representa como una línea discontinua, posiblemente dirigida, que incluye a veces una etiqueta. 14 Figura Dependencia Una asociación es una relación estructural entre clases que describe un conjunto de enlaces, los cuales son conexiones entre objetos que son instancias de clases. La agregación es un tipo especial de asociación, que representa una relación estructural entre un todo y sus partes. Gráficamente, una asociación se representa como una línea continua, posiblemente dirigida, que a veces incluye una etiqueta, y a menudo incluye otros adornos, como la multiplicidad y los nombres de rol. 15 +jefe empleado * Figura Asociación Una generalización es una relación de especialización /generalización en la cual el elemento especializado (el hijo) se basa en la especificación del elemento generalizado (el padre). El hijo comparte la estructura y el comportamiento de padre. Gráficamente, una relación de generalización se 14 Ibidem, p Ibidem, p. 27

15 representa como una línea continua con una punta de flecha vacía apuntando al padre. 16 Figura Generalización La realización es una relación semántica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. Existen relaciones de realización en dos sitios: entre interfaces y las clases y componente que las realizan, y entre los casos de uso y las colaboraciones que los realizan. Gráficamente, una relación de realización se representa como una mezcla entre una generalización y una relación de dependencia. Figura Realización Diagramas Casos de uso Estados Clases Tipos de Actividad Secuencia Tipos de Diagramas Componentes Colaboración Implementación Figura Ídem.

16 Diagrama de casos de uso Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso. Es importante resaltar que los diagramas de casos de uso no están pensados para representar el diseño y no puede describir los elementos internos de un sistema. Los diagramas de casos de uso sirven para facilitar la comunicación con los futuros usuarios del sistema, y con el cliente, y resultan especialmente útiles para determinar las características necesarias que tendrá el sistema. En otras palabras, los diagramas de casos de uso describen qué es lo que debe hacer el sistema, pero no cómo. Diagrama de clases Los diagramas de clases muestran las diferentes clases que componen un sistema y cómo se relacionan unas con otras. Los diagramas de clases son de carácter estático porque muestran las clases, junto con sus métodos y atributos, así como las relaciones estáticas entre ellas: qué clases conocen a otras clases o qué clases son parte de otras clases, pero no muestran los métodos mediante los que se invocan entre ellas. Diagrama de secuencia Los diagramas de secuencia muestran el intercambio de mensajes (es decir, la forma en que se invocan) en un momento dado. Los diagramas de secuencia ponen especial énfasis en el orden y el momento en que se envían los mensajes a los objetos. En los diagramas de secuencia, los objetos están representados por líneas intermitentes verticales, con el nombre del objeto en la parte más alta. El eje de tiempo también es vertical, incrementándose hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma de flechas con los nombres de la operación y los parámetros. Diagrama de colaboración Los diagramas de colaboración muestran las interacciones que ocurren entre los objetos que participan en una situación determinada. Esta es más o menos

17 la misma información que la mostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones se producen en el tiempo, mientras que los diagramas de colaboración fijan el interés en las relaciones entre los objetos y su topología. En los diagramas de colaboración los mensajes enviados de un objeto a otro se representan mediante flechas, mostrando el nombre del mensaje, los parámetros y la secuencia del mensaje. Los diagramas de colaboración muestran una situación o flujo de programa específicos y son unos de los mejores tipos de diagramas para demostrar o explicar rápidamente un proceso dentro de la lógica del programa. Diagrama de estados Los diagramas muestran los diferentes estados de un objeto durante su vida, y los estímulos que provocan los cambios de estado en un objeto. Determinan a los objetos como máquinas de estado o autómatas finitos que pueden estar en un conjunto de estados finitos y que también pueden cambiar su estado a través de un estímulo perteneciente a un conjunto finito. Diagrama de actividad Los diagramas describen la secuencia de las actividades en un sistema. Son una forma especial de los diagramas de estado, que únicamente (o generalmente) contienen actividades. Diagrama de componentes Los diagramas muestran los componentes del software (componentes CORBA, Java Beans o simplemente secciones del sistema claramente distintas) y los artefactos de que está compuesto con los archivos de código fuente, las bibliotecas o las tablas de una base de datos. Los componentes pueden tener interfaces (es decir, clases abstractas con operaciones) que permiten asociaciones entre ellos.

18 Diagrama de implementación Los diagramas de implementación muestran las instancias existentes al ejecutarse así como sus relaciones. También se representan los nodos que identifican recursos físicos, típicamente un ordenador, así como interfaces y objetos (instancias de las clases).