Inforsalud 2004 Tutorial de uml



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

3.1.3.1.- Diagrama de Clases y Diagrama de Objetos

Los diagramas de clases muestran un resumen del sistema en términos de sus clases y las relaciones entre ellas. Son diagramas estáticos que muestran qué es lo que interactúa, pero no cómo interactúa o qué pasa cuando ocurre la interacción.


El siguiente diagrama modela los pedidos de un cliente a una tienda de venta por catálogo. La clase principal es “Pedido”, asociada a un cliente, una forma de pago y un conjunto de artículos.
La clase “Pago” es abstracta, en UML los nombres de clases abstractas se representan en Itálica. Las clases abstractas actúan a modo de interfaz, proporcionando únicamente un listado de métodos a ser “realizados” por las clases que las implementan o realizan. “Pago” es una superclase especializada, y a la vez realizada, por sus formas más comunes “Credito” y “Efectivo”. Un “Pedido” tiene una única forma de pago, expresada por su multiplicidad, 1, mientras que una forma de pago puede estar presente en uno o más pedidos, como sugiere su multiplicidad, 1..*.
En cuanto a las asociaciones, observamos que algunas vienen representadas como una flecha navegable, cuya orientación expresa el sentido en que se consultan los datos. Las asociaciones sin flecha son bi-direccionales. Las agregaciones expresan “conjunto de”; la relación entre “Pedido” y “Articulo” es de conjunto. Un pedido es una agregación de una o más líneas de pedido, donde cada una hace alusión a un artículo concreto, así mismo una línea de pedido puede estar presente en varios pedidos y un artículo puede no haber sido solicitado nunca.

Figura 3: Diagrama de Clases


En cuanto a la multiplicidad, la siguiente tabla resume las más comunes. Hay que tener en cuenta que la multiplicidad se expresa “en el lado opuesto” de la relación y es el número de posibles instancias de una clase asociadas con una única instancia de la clase en el otro extremo.



Multiplicidad

Significado

1

Una única instancia

N / *

N instancias

0..N / 0..*

Entre ninguna y N instancias

1..N / 1..*

Entre una y N instancias

0..1

Ninguna o una instancia

N..M

Entre N y M instancias

Tabla 4: Multiplicidad en Diagramas de Clases
El siguiente diagrama muestra una dependencia existente entre las clases “Pedido” y “Fecha”. Cualquier cambio en la clase dependida, “Fecha”, afectará la clase dependiente, “Pedida”.
Así mismo se puede observar que las clases vienen representadas por cajas en las que hay tres separaciones, o compartimentos. El primero se emplea siempre para indicar el nombre de la clase, el segundo para mostrar los atributos y el tercero para los métodos. Tanto los atributos como los métodos vienen precedidos por un símbolo de acceso, que normalmente suele ser un “+” para el acceso público, un “-” para el acceso privado, (sólo por otros métodos de la clase) y un “#” para el acceso protegido (sólo por clases hija), aunque la herramienta empleada en la elaboración del tutorial traduce estos elementos en iconos.
Los atributos tienen un tipo que puede mostrarse a continuación de su nombre separado por “:”. De igual manera, los métodos pueden devolver un elemento de un tipo determinado y recibir parámetros, expresados entre paréntesis mediante el nombre del parámetro y el tipo, separados por “:”. Para el caso de múltiples parámetros, se separan por comas (p1:t1, p2:t2 ... pn:tn). Los parámetros que tienen un valor por defecto se expresan mediante un “=” y el valor, a continuación del tipo (p1:t1=v1) y si un parámetro en la posición “i” de la lista de parámetros tiene valor por defecto, todos los parámetros que le sigan, es decir que ocupen posiciones sucesivas a “i” en la lista, deberán tener también un valor por defecto.
Los atributos y métodos estáticos (de clase) se representan mediante un subrayado (en el caso de los métodos se puede emplear el estereotipo <>, los estereotipos se ven más adelante).

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

El siguiente diagrama muestra una auto-relación de agregación. Un “Departamento” puede estar compuesto a su vez por más sub-departamentos, o ninguno, con la restricción de que el mínimo número de personas en los sub-departamentos debe ser dos. Las restricciones son condiciones que deben ser cumplidas siempre, se expresan entre llaves {condición }”.

Figura 5: Auto-agregación

Los diagramas de objetos son análogos a los de clases, con la particularidad de que en lugar de encontrar clases, encontramos instancias de éstas. Son útiles para explicar partes pequeñas del modelo en las que hay relaciones complejas.


3.1.3.2.- Diagrama de Componentes y Diagrama de Despliegue

Los componentes son módulos de código, así que los diagramas de componentes vienen a ser los análogos físicos a los diagramas de clases. Muestran como está organizado un conjunto de componentes y las dependencias que existen entre ellos.



Figura 6: Diagrama de Componentes



Los diagramas de despliegue sirven para modelar la configuración hardware del sistema, mostrando qué nodos lo componen.

Figura 7: Diagrama de Despliegue




3.1.3.3.- Diagrama de Casos de Uso

Los diagramas de Casos de Uso describen lo que hace un sistema desde el punto de vista de un observador externo, enfatizando el qué más que el cómo. Plantean escenarios, es decir, lo que pasa cuando alguien interactúa con el sistema, proporcionando un resumen para una tarea u objetivo. El siguiente Caso de Uso describe como Carlos va a desayunar (este es su objetivo), para lo que se plantea el escenario de preparar su café y el pan tostado



.

Figura 8: Diagrama de Casos de Uso nivel 1


En los Casos de Uso, los Actores son papeles que determinadas personas u objetos desempeñan. Se representan mediante un “hombre de palitos”, de modo que en el ejemplo, Carlos es un Actor. Los Casos de Uso se representan por medio de óvalos y las líneas que unen Actores con Casos de Uso representan una asociación de comunicación.

Por su puesto, un Caso de Uso puede ser descrito en mayor profundidad. Por ejemplo si tomamos por separado “Preparar pan” y “Preparar cafe”, podemos bajar un nivel de descripción y llegar a los siguientes Casos de Uso.



Figura 9: Diagrama Casos de Uso nivel 2 A



Carlos tuesta el pan en la tostadora, después lo unta con mantequilla y mermelada de fresa y se lo come, posiblemente mojándolo en un café.”

Figura 10: Diagrama Casos de Uso nivel 2 B

Carlos calienta leche, añade café y azúcar al gusto y se lo bebe.”

Los Casos de Uso suelen venir delimitados por fronteras o límites, que definen una separación entre lo que es realmente la funcionalidad del sistema y los actores que la usan o colaboran en su desempeño. En las figuras, esta separación viene representada por medio de la caja que encapsula los óvalos.


Los Casos de Uso son acompañados por una explicación textual que clarifica las posibles cadencias del lenguaje meramente gráfico. De esta manera, combinando Casos de Uso y explicación textual, se puede obtener escenarios no ambiguos, que resultan ideales en la captura de requisitos de usuario, dada su sencillez de comprensión incluso por quien no está familiarizado con UML. Los Casos de Uso se emplean también en la preparación de escenarios de pruebas con que verificar el software una vez ha sido construido.
El siguiente Caso de Uso es equivalente al primero, “Desayuno”, sólo que en él se ha condensado la máxima cantidad posible de información. En él se muestra un nuevo elemento que hasta ahora no se había mostrado, el “estereotipo”, que viene entre sendos símbolos angulados “<<” y “>>” y concreta un paso más allá el tipo de relación existente entre dos Casos de Uso. Encontramos dos estereotipos <> y <>. El primero indica que el Caso de Uso “Tostar pan” requiere de “Usar tostadora” para poder ser llevado a cabo. Esta es una forma muy adecuada de sacar factor común entre Casos de Uso, o incluso de fraccionar Casos de Uso muy grandes. El segundo indica que el Caso de Uso “Untar pan” es una variación de “Untar”. Observamos también que “Comer pan” y “Beber cafe” son una generalización de “Alimentarse”.

Figura 11: Diagrama Casos de Uso nivel 1 detallado

“Carlos va a desayunar. Para ello debe hacer dos actividades distintas, pero relacionadas. La primera consisten en tostar pan, para lo cual necesita emplear una tostadora. Una vez tostado el pan, lo unta de mantequilla y mermelada de fresa (untar pan no es muy distinto de untar otro tipo de alimentos). La segunda consiste en preparar el café, par lo cual necesita calentar leche y añadir café y azuzar. Terminadas ambas actividades, Carlos puede proceder a alimentarse, comiendo el pan tostado y bebiendo el café. El orden en que realice las actividades da igual y también da igual si se realizan a la vez.”


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

Los diagramas de secuencia describen como los objetos del sistema colaboran. Se trata de un diagrama de interacción que detalla como las operaciones se llevan a cabo, qué mensajes son enviados y cuando, organizado todo en torno al tiempo. El tiempo avanza “hacia abajo” en el diagrama. Los objetos involucrados en la operación se listan de izquierda a derecha de acuerdo a su orden de participación dentro de la secuencia de mensajes.


Figura 12: Diagrama de Secuencia

Las líneas verticales o “líneas de la vida” representan el tiempo de vida del objeto. La vida del objeto “carlos” no termina en este diagrama, sin embargo la del objeto “tosty” sí y esto viene representado mediante el aspa al final de su línea de la vida.
Los rectángulos verticales son barras de activación y representan la duración de la ejecución del mensaje. El mensaje “Encender”, posiblemente implementado mediante la introducción del enchufe en una toma de pared, tiene una duración escasa y similar a la de “Apagar”. No ocurre lo mismo con la llamada al método “tostar()”, que dura desde la pulsación del botón de tostar hasta que el pan es retirado de la bandeja y además interviene la emisión de un aviso cuando el pan está lo suficientemente caliente, a fin de evitar que se queme.
Como se puede observar, la acción tostar viene condicionada por la presencia de pan en la bandeja de la tostadora. En UML los corchetes “[]” expresan condición y si están precedidos de un asterisco indican interacción mientras se cumpla la condición.
Los mensajes que son intercambiados entre los objetos de un diagrama de secuencia pueden ser síncronos o asíncronos. Los mensajes asíncronos son aquellos tal que el emisor puede enviar nuevos mensajes mientras el original está siendo procesado. El mensaje asíncrono ocurre en el tiempo de manera independiente a otros mensajes. Los mensajes síncronos son todo lo contrario, el emisor debe esperar a que termine el tiempo de proceso del mensaje antes de que pueda emitir nuevos mensajes. UML emplea los siguientes convenios para representar el tipo de mensaje.



Símbolo

Significado


Mensaje simple que puede

ser síncrono o asíncrono.



Mensaje simple de vuelta

(opcional).




Mensaje síncrono.




Mensaje asíncrono.



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

Los diagramas de colaboración son otro tipo de diagramas de interacción, que contiene la misma información que los de secuencia, sólo que se centran en las responsabilidades de cada objeto, en lugar de en el tiempo en que los mensajes son enviados. Cada mensaje de un diagrama de colaboración tiene un número de secuencia. El primer nivel de la secuencia es 1, y los mensajes que son enviados durante la misma llamada a un método se numeran 1.1, 1.2 y así sucesivamente para tantos niveles como sea necesario.


Figura 13: Diagrama de Colaboración




3.1.3.5.- Diagrama de Estados y Diagrama de Actividades

Los diagramas de estados muestran los posibles estados en que puede encontrarse un objeto y las transiciones que pueden causar un cambio de estado. El estado de un objeto depende de la actividad que esté llevando a cabo o de alguna condición.


Las transiciones son las líneas que unen los diferentes estados. En ellas se representa la condición que provoca el cambio, seguida de la acción oportuna separada por “/”. En un estado en que el objeto esta pendiente de algún tipo de validación que dependa de un proceso en curso, no es necesario evento externo alguno para que se produzca la transición, ya que ésta ocurrirá cuando termine el proceso, en función del resultado de éste. En estos casos es conveniente, por claridad, incluir la condición que de la que depende la transición (entre corchetes).
Los estados inicial, a partir del que se “entra” en la máquina de estados, y final, que indica que la máquina de estados termina, no tienen otro significado adicional, son elementos ornamentales y se representan mediante un circulo negro y un circulo negro resaltado respectivamente.
Los estados de un diagrama de estados pueden anidarse, de forma que los estados relacionados pueden ser agrupados en un estado compuesto. Esto puede ser necesario cuando una actividad involucra sub-actividades asíncronas o concurrentes.

Figura 14: Máquina de Estados, estados simples



Figura 15: Máquina de Estados, estados compuestos



Los diagramas de actividades son básicamente diagramas de flujo adornados, que guardan mucha similitud con los diagramas de estados. Mientras que los diagramas de estados centran su atención en el proceso que está llevando a cabo un objeto, los diagramas de actividades muestran como las actividades fluyen y las dependencias entre ellas.
Los diagramas de actividades pueden dividirse en “calles” que determinan qué objeto es responsable de qué actividad. Las actividades vienen unidas por transiciones, que pueden separarse en ramas en función del resultado de una condición expresada entre corchetes. Cada rama muestra la condición que debe ser satisfecha para que el flujo opte por ese camino. Igualmente, las transiciones se pueden bifurcarse en dos o más actividades paralelas.

Figura 16: Diagrama de Actividades




3.2.- Cómo utilizar UML

UML es simplemente un lenguaje de modelado. Define un conjunto de elementos y relaciones entre ellos, que se emplean en la definición de modelos. UML es típicamente usado como parte de un proceso de desarrollo, con la ayuda de una herramienta CASE (Computer Aided Software Engineering), para definir requerimientos, interacciones y elementos del software que se está desarrollando. UML es independiente de cualquier proceso particular, no está ligado a ningún ciclo de vida de desarrollo del software concreto, no obstante se obtienen mayores beneficios si se selecciona un proceso que esté dirigido por Casos de Uso, se centre en la arquitectura y sea incremental.


La arquitectura de un sistema es el conjunto de decisiones significativas que se toma en torno a su organización, la selección de elementos estructurales, la definición de las interfaces entre estos elementos, su comportamiento, su división en subsistemas, qué elementos son estáticos y cuales dinámicos. La arquitectura también incluye el uso que se le va a dar al sistema, la funcionalidad, el rendimiento, la capacidad de adaptación, la reutilización, la capacidad de ser comprendido, las restricciones económicas, las temporales, los compromisos entre alternativas y los aspectos estéticos.
Un proceso incremental es aquél que consiste en sucesivas ampliaciones y mejoras de la arquitectura, a partir de una línea básica. Cada incremento resuelve los problemas encontrados en la versión anterior minimizando incrementalmente los riesgos más significativos para el éxito del proyecto.
Lo primero que se debe hacer para comenzar a desarrollar un proyecto con UML, es seleccionar una metodología de desarrollo que defina la naturaleza concreta del proceso a seguir. El modelo a definir en base al proceso elegido, se divide en realidad en varios tipos de modelo o vistas, cada una centrada en un aspecto o punto de vista del sistema. En general, independientemente del proceso que se emplee, se puede encontrar las siguientes vistas:


  • Vista de Casos de Uso: Engloba los Casos de Uso que describen el comportamiento del sistema como lo verían los usuarios finales, los analistas y demás componentes del equipo de desarrollo. No especifica la organización del sistema. Con UML los aspectos estáticos de esta vista se pueden concretar con los diagramas de Casos de Uso; los aspectos dinámicos con los diagramas de iteración (secuencia y colaboración), diagramas de estados y de actividades.



  • Vista de Diseño: Engloba las clases e interfaces que conforman el vocabulario del problema y su solución. Da soporte a los requisitos funcionales del sistema, es decir los servicios que proporciona a los usuarios finales. Con UML los aspectos estáticos de esta vista se pueden concretar con los diagramas de clases y de objetos; los aspectos dinámicos con los diagramas de iteración (secuencia y colaboración), diagramas de estados y de actividades.



  • Vista de Procesos: Engloba los hilos y procesos que forman los mecanismos de sincronización y concurrencia del sistema. Da soporte al funcionamiento, capacidad de crecimiento y rendimiento del sistema. Con UML los aspectos estáticos de esta vista se pueden concretar con los diagramas de clases, de clases activas y de objetos; los aspectos dinámicos con los diagramas de iteración (secuencia y colaboración), diagramas de estados y de actividades.



  • Vista de Despliegue: Engloba los nodos que forman la topología hardware sobre el que se ejecuta el sistema. Da soporte a la distribución, entrega e instalación de las partes que conforman el sistema físico. Con UML los aspectos estáticos de esta vista se pueden concretar con los diagramas despliegue; los aspectos dinámicos con los diagramas de iteración (secuencia y colaboración), diagramas de estados y de actividades.



  • Vista de Implementación: Engloba los componentes y archivos empleados para hacer posible el sistema físico. Da soporte a la gestión de configuraciones de las distintas versiones del sistema, a partir de componentes y archivos. Con UML los aspectos estáticos de esta vista se pueden concretar con los diagramas de componentes; los aspectos dinámicos con los diagramas de iteración (secuencia y colaboración), diagramas de estados y de actividades.

Un ejemplo de proceso para la construcción de un programa, podría ser similar al siguiente, teniendo en cuenta que el proceso descrito deja muchas cosas por ampliar y puede no adaptarse a las necesidades particulares de un grupo de trabajo determinado. Se proporciona meramente como un ejemplo de cómo se puede encajar UML como soporte para el desarrollo de un proyecto:


  1. Iniciar y mantener reuniones con los usuarios finales del programa, para comprender sus necesidades, el contexto en que lo usarán y todos los detalles necesarios para comprender el ámbito del problema a resolver. Esta información será empleada para capturar las actividades y procesos involucrados y susceptibles de ser incorporados en el programa, a un nivel alto, y proporcionará la base para construir la vista de Casos de Uso.




  1. Construir la vista de Casos de Uso definiendo exactamente la funcionalidad que se va a incorporar en el programa, desde el punto de vista de sus usuarios. El modelo resultante es realmente un mapeo de la información obtenida en el paso anterior, en el que cada nuevo Caso de Uso realiza un aspecto de la funcionalidad planteada. Refinar, en conjunto con los usuarios finales, todos los diagramas de Casos de Uso, incluyendo requisitos y restricciones, para llegar a un acuerdo común en lo que el programa hará y no hará. En este punto puede ser conveniente diseñar escenarios de prueba que ayuden a verificar si el programa finalizado cumple con las expectativas del contrato.




  1. Partiendo del modelo de Casos de Uso se comienza a estructurar los requisitos en una arquitectura llamada “línea base”. Se definen clases y relaciones entre ellas, los primeros diagramas de secuencia y colaboración, definiendo los comportamientos de cada clase, también las interfaces entre los diferentes elementos de la arquitectura. Se construye aquí la vista de diseño y la vista de procesos. Construir diagramas de clases más elaborados y refinar los comportamientos del sistema.




  1. A medida que crece el modelo se puede fraccionar en componentes software y paquetes. Aparecen nuevos requisitos que deben ser integrados. Se define la vista de despliegue, que define la arquitectura física del sistema, y la vista de implementación.




  1. Construir el sistema, repartiendo las tareas entre el equipo de programación.




  1. Buscar errores de programación, o incluso de diseño, corregirlos e ir sacando sucesivas versiones del programa hasta llegar a una versión que cumpla con todos los requisitos especificados en el contrato con los usuarios.




  1. Documentar y entregar el programa a los usuarios finales.

4.- Referencias

Grady Booch, James Rumbaugh, Ivar Jacobson, (1996) El Lenguaje Unificado de Modelado¸Addison Wesley.


Schneider G., Winters J.P., (2001) Applying Use Cases: A Practical Guide, Addison Wesley.

INFORSALUD 2004
1   2   3   4   5


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

    Página principal