Inforsalud 2004 Tutorial de uml



Descargar 236,34 Kb.
Página1/5
Fecha de conversión12.01.2017
Tamaño236,34 Kb.
  1   2   3   4   5




Tutorial de UML

de






INFORSALUD 2004


Tutorial de UML



Miguel Arregui

(marregui@sg.uji.es)
Dpto. de lenguajes y sistemas informáticos

Grupo IRIS (INTEGRACIÓN y reingeniería de sistemas)
Universitat Jaume I, Castellón

Presentación
El presente documento ha sido preparado como material de soporte para el tutorial de UML, Lenguaje Unificado de Modelado, del inglés “Unified Modeling Language”, impartido en el VII Congreso Nacional de Informática para la Salud, INFORSALUD 2004.
El tutorial ofrece una introducción a todos los conceptos que maneja UML, empezando por los más relevantes del paradigma de la Orientación a Objetos, OO, sobre el que asientan los cimientos de UML. Por último, describe como puede emplearse UML en el desarrollo de un proyecto. El tutorial no pretende profundizar en cada detalle, en cambio busca ser una útil toma de contacto con UML, como mínimo para conocer sus posibilidades y ayudar en la decisión de si adoptarlo como parte del arsenal de desarrollo.

Contenidos


1.- Introducción 5

2.- La Orientación a Objetos, OO 5

2.1.- Qué es un Objeto 6

2.2.- Qué es una Clase 7

2.3.- Qué es la Herencia 7

2.4.- Qué es una Interfaz 8

3.- El Lenguaje Unificado de Modelado, UML 9

3.1.- Bloques básicos de construcción de UML 9

3.1.1.- Elementos 10

3.1.2.- Relaciones 11

3.1.3.- Diagramas 11

3.1.3.1.- Diagrama de Clases y Diagrama de Objetos 13

3.1.3.2.- Diagrama de Componentes y Diagrama de Despliegue 15

3.1.3.3.- Diagrama de Casos de Uso 16

3.1.3.4.- Diagrama de Secuencia y Diagrama de Colaboración 18

3.1.3.5.- Diagrama de Estados y Diagrama de Actividades 20

3.2.- Cómo utilizar UML 22

4.- Referencias 26



Figuras


Figura 1: Objetos comunicándose 6

Figura 2: La Herencia 8

Figura 3: Diagrama de Clases 14

Figura 4: Relación de dependencia en Diagramas de Clase 15

Figura 5: Auto-agregación 15

Figura 6: Diagrama de Componentes 16

Figura 7: Diagrama de Despliegue 16

Figura 8: Diagrama de Casos de Uso nivel 1 17

Figura 9: Diagrama Casos de Uso nivel 2 A 17

Figura 10: Diagrama Casos de Uso nivel 2 B 17

Figura 11: Diagrama Casos de Uso nivel 1 detallado 18

Figura 12: Diagrama de Secuencia 19

Figura 13: Diagrama de Colaboración 20

Figura 14: Máquina de Estados, estados simples 21

Figura 15: Máquina de Estados, estados compuestos 21

Figura 16: Diagrama de Actividades 22




Tablas




Tabla 1: Elementos de construcción en UML 11

Tabla 2: Elementos de relación en UML 11

Tabla 3: Diagramas de UML 12

Tabla 4: Multiplicidad en Diagramas de Clases 14

Tabla 5: Tipos de mensaje en diagramas de interacción 20




1.- Introducción

En los tiempos que corren, el software tiene la tendencia de ser grande y complejo. Los usuarios demandan interfaces cada vez más completas y funcionalidades más elaboradas, todo ello influyendo en el tamaño y la complejidad del producto final. Por ello, los programas deben ser estructurados de manera que puedan ser revisados, corregidos y mantenidos, rápida y eficazmente, por gente que no necesariamente ha colaborado en su diseño y construcción, permitiendo acomodar nueva funcionalidad, mayor seguridad y robustez, funcionando en todas las situaciones que puedan surgir, de manera previsible y reproducible.


Ante problemas de gran complejidad, la mejor forma de abordar la solución es modelar. Modelar es diseñar y estructurar el software antes de lanzarse a programar y es la única forma de visualizar un diseño y comprobar que cumple todos los requisitos para él estipulados, antes de que la flotilla de programadores comience a generar código. Modelando, los responsables del éxito del producto pueden estar seguros de que su funcionalidad es completa y correcta, que todas las expectativas de los usuarios finales se cumplen, que las posibles futuras ampliaciones pueden ser acomodadas, todo ello mucho antes de que la implementación haga que los cambios sean difíciles o imposibles de acomodar. Modelando, se abstraen los detalles esenciales de un problema complejo y se obtiene diseños estructurados que, además, permiten la reutilización de código, reduciendo los tiempos de producción y minimizando las posibilidades de introducir errores.

UML es un lenguaje gráfico que sirve para modelar, diseñar, estructurar, visualizar, especificar, construir y documentar software. UML proporciona un vocabulario común para toda la cadena de producción, desde quien recaba los requisitos de los usuarios, hasta el último programador responsable del mantenimiento. Es un lenguaje estándar para crear los planos de un sistema de forma completa y no ambigua. Fue creado por el Object Management Group, OMG, un consorcio internacional sin ánimo de lucro, que asienta estándares en el área de computación distribuida orientada a objetos, y actualmente revisa y actualiza periódicamente las especificaciones del lenguaje, para adaptarlo a las necesidades que surgen. El prestigio de este consorcio es un aval más para UML, considerando que cuenta con socios tan conocidos como la NASA, la Agencia Europea del Espacio ESA, el Instituto Europeo de Bioinformática EBI, Boeing, Borland, Motorla y el W3C, por mencionar algunos.




2.- La Orientación a Objetos, OO

Aunque UML puede emplearse en cualquier paradigma, como la programación estructurada o la lógica, está especialmente cerca del paradigma de la orientación a objetos. Por tanto, es precisa una familiarización con algunos detalles de este paradigma antes de continuar con UML.



2.1.- Qué es un Objeto

De manera intuitiva, la tendencia general es asociar el término objeto con todo aquello a lo que se puede atribuir la propiedad física de masa, como una tostadora de pan, aunque es posible encontrar objetos de índole no tangible, como por ejemplo una dirección postal. En el ámbito de la informática, un objeto define una representación abstracta de las entidades del mundo, tangibles o no, con la intención de emularlas. Existe pues, una relación directa entre los objetos del mundo y los objetos informáticos, de modo que puede emplearse el término objeto de manera indistinta.


Los objetos tienen dos características, que son su estado y su comportamiento. El estado es una situación en la que se encuentra el objeto, tal que cumple con alguna condición o condiciones particulares, realiza alguna actividad o espera que suceda un acontecimiento. Una tostadora puede estar encendida y cargada de pan y, en cuanto a su comportamiento, lo normal en este estado es tostar pan.
Los objetos mantienen su estado en uno o más atributos, que son simplemente datos identificados por un nombre, y exhiben su comportamiento a través de métodos, que son trozos de funcionalidad asociados al objeto. En este sentido, un objeto es realmente un conjunto de atributos y métodos. Pero un objeto sólo revela su verdadera utilidad cuando es integrado en un contexto de comunicación con otros objetos, a través del envío de mensajes, para componer un sistema mucho mayor y demostrar un comportamiento más complejo. Una tostadora en un armario resulta de poca utilidad, pero cuando interactúa con otro objeto, como un ser humano, se convierte en una herramienta útil para tostar pan. El humano intercambiaría con la tostadora el mensaje “tuesta el pan que tienes en la bandeja” a través de la pulsación del botón de tostar.
A partir del ejemplo anterior, es fácil deducir que el envío de mensajes es la forma en que se invocan los métodos de un objeto y que la invocación de métodos es el mecanismo a través del cual un objeto puede cambiar su estado o el de otro objeto. Los atributos y los métodos de un objeto pueden tener un menor o mayor grado de visibilidad, desde “privado” hasta “público”, lo que hace que aparezca un concepto nuevo, la encapsulación. La encapsulación oculta los detalles del funcionamiento interno del objeto, exponiendo sólo aquello que pueda ser de interés.


Figura 1: Objetos comunicándose



  1   2   3   4   5


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal