• Author / Uploaded
• rubenmamani

• Categories
• Objeto (informática)
• Caso de uso
• Clase (Programación informática)
• Programación orientada a objetos
• Lenguaje de programación

Citation preview

Diagramas de Casos de Uso En los apartados anteriores, vimos que el lenguaje UML es muy útil para la colaboración con personas sin conocimientos técnicos. Uno de los diagramas más importantes y útiles para entablar este proceso es el diagrama de casos de uso. Empezaremos a escribir diagramas UML al final de la fase de inicio o al principio de la fase de elaboración. El primer tipo de diagrama que realizaremos es un diagrama de casos de uso. Es un diagrama que presenta a los usuarios finales del sistema y que trata de recoger todas las formas en la que los usuarios interactuarán con la aplicación. Este diagrama es parte de los diagramas de comportamiento, que muestran de forma sencilla y visual cómo funciona el sistema para que todas las personas involucradas en el proyecto lo entiendan.

Se trata de entender el sistema como una historia. Una historia tiene personajes, unas acciones, y un contexto. Un diagrama de casos de usos es la representación en UML de una historia. Ya estás familiarizado con casos de uso aunque no te des cuenta. Un caso de uso describe lo que siempre tiene que pasar dentro de nuestro sistema y los pasos para llegar a ello, pero también debe contemplar casos menos comunes. Por ejemplo, en caso de una avería o si el usuario cambia de idea a lo largo de su interacción

Ejemplo de un caso de uso Vamos a ver algunos casos de uso para una tienda online. 1. Un vendedor de libros se conecta a la web para subir el articulo que tiene a la venta. 2. Un cliente se conecta a la página web de una tienda online para comprar un libro. Escribe el título del libro en la barra de búsqueda y busca el mejor precio entre los resultados. Cuando encuentra una oferta que le interesa, le añade al carrito de la compra. Tiene que haber iniciado una sesión para poder hacerlo. Los casos de uso siempre deben comportar un verbo. Este es un caso de uso muy sencillo. Muchas veces, la descripción será más larga si el proyecto es más complejo. Ahora tratemos de traducir nuestro caso de uso a un diagrama de casos de uso. Este diagrama incluye lo siguiente :   

Un actor o varios actores. Acciones. Relaciones de "include" y "extend".

Los actores son los diferentes participantes en nuestro escenario. Son los que llevan a cabo las acciones que describimos en los casos de uso. Los actores se representan como figuras de palo. No hace falta ser muy buen dibujante ¡Los actores no son necesariamente personas! Pueden representar organizaciones o incluso componentes del software. Las acciones son aquello que hacen los actores con el sistema. Son funcionalidades que deberán ser luego implementadas. En el centro, dibujamos el sistema. Es el escenario dónde nuestros actores interactúan. Lo representaremos como un rectángulo, y dibujaremos los casos de uso dentro del sistema.

Primera etapa del diseño de un diagrama de casos de uso Empecemos con las primeras acciones descritas en el caso de uso textual: el comprador buscando un articulo. Podemos añadir “ver artículos” en el sistema. Dibujamos una línea entre el comprador y la acción para significar quien lleva a cabo la acción. También añadimos la acción “subir articulo” y dibujamos una linea entre el vendedor y la acción.

Actores y acciones Para poder elegir la mejor oferta, el comprador tiene que ser capaz de ordenar los articulos por precio. Usaremos la palabra clave para designar una acción que puede derivar de otra, dibujando una linea punteada entre los casos de uso con la palabraen la linea.

Añadimos la palabra clave Ahora pasamos a la acción “comprar articulo”. Esta acción involucra el comprador así como el vendedor. También hemos de añadir otro actor, ya que para efectuar el pago, necesitamos usar el sistema de pagos. Lo añadiremos como otro actor (recordar que los actores no son necesariamente humanos!). Dibujamos una línea entre cada actor y la acción.

añadimos la acción "comprar articulo" Finalmente, hemos de asegurarnos de que para poder comprar, un usuario este registrado en la plataforma. Este requerimiento lo modelamos con la palabra clavecon una flecha desde “comprar articulo” hacía “iniciar sesión”.

Añadimos una acción con la palabra clave Con esto hemos visto los principales elementos de un diagrama de casos de uso. Es bastante sencillo, ¿no? Pero no te dejes engañar: esta etapa es muy importante para entender el contexto del trabajo que vamos a realizar, y nos permite enfocarnos solo en lo importante y descartar el resto. Recuerda que los elementos que siempre debe llevar un diagrama de casos de uso son 

Actores  Acciones  Lineas entre los actores y las acciones que les corresponden Adicionalmente, puede comportar 

relaciones entre acciones cuando una acción es prerequisito de otra  relaciones entre acciones cuando una acción es una opción después de realizar otra. En el próximo apartado veremos cómo describir la arquitectura del sistema con los diagramas de clase. ¡Hasta ahora!

Crear el diagrama de clase del sistema Ahora nos vamos a centrar en aspectos más técnicos del diseño de sistemas. Vamos a ver cómo hacer un diagrama de clase. Este es un tipo de diagrama que nos tocará hacer una vez tengamos los primeros pasos de la fase de elaboración bien adelantados. El diagramas de clase entra en la categoría de los diagramas estructurales, y es sin duda el más común de ellos. Son diagramas que permiten describir la arquitectura de un sistema con bastante detalle. Es muy recomendable tener un diagrama de clase antes de empezar a escribir código para una base de datos o una aplicación.

Escribiendo un diagrama de clase, podemos describir cómo se relacionan los elementos de un sistema, qué atributos les caracterizan. Después de haber escrito diagramas de casos de uso, tendremos las cosas lo suficientemente despejadas como para poder ir diseñando la arquitectura del sistema. A continuación, vamos a escribir el diagrama de clase para el ejemplo con el que estamos trabajando. En el apartado anterior, hemos identificado los elementos principales de nuestro sistema: compradores, vendedores, y artículos.

Identificar las clases del sistema Añadiremos los artículos como el primer elemento en nuestro diagrama de clase. Es tan sencillo como dibujar un cuadrado y escribir “articulo” arriba del todo.

La clase "artículo" Debajo del titulo, colocamos los atributos de un articulo. ¿Qué tiene un articulo? ¿Qué características tiene que permite diferenciarlo de otros artículos? Lo importante es que nos quedemos con lo relevante para nuestra aplicación. Trata de imaginarlo en una página web. ¿Qué información esperarías que ponga? Recuerda que adoptar el proceso unificado nos permite refinar el modelo de forma iterativa y que entonces podemos añadir detalles a medida que vayamos mejorando la aplicación o recibamos feedback de nuestros clientes u otros miembros de nuestro equipo. A continuación detallamos las otras clases de nuestro sistema. Hemos añadido el comprador, el vendedor, el envío y el pago de un articulo.

Las clases de nuestro diagrama de clase

Identificar las relaciones entre las clases Establecer la cardinalidad de las relaciones Ahora nos toca averiguar cómo se relacionan los elementos entre ellos. Una pregunta que tenemos que hacer cada vez que estudiamos la relación entre dos elementos es : ¿Cuántos elementos A por cada elemento B? ¿Y Cuántos B por cada A? Este proceso lo llamamos establecer la cardinalidad de las relaciones. Además es recomendado añadir verbos a las relaciones para ayudar a cubrir mejor la semántica de las relaciones. Relaciones de uno a varios Por ejemplo, ¿Cuántos artículos por cada envío? La respuesta es bastante intuitiva: un envío solo puede existir si contiene como mínimo un articulo. Además, no se puede definir un número máximo de artículos en un envío. Esto lo representamos escribiendo 1..* en la línea entre artículos y envíos, al lado de la caja de artículos. Significa que tendremos entre 1 y un numero indeterminado de articulo por envío. Es lo que se denomina un relación de uno a varios. Relaciones de varios a varios ¿Cuántos artículos puede vender un vendedor? Puede ser que un vendedor se quede sin artículos para vender, por lo tanto el mínimo sería 0. No impondremos un máximo de artículos que pueda vender alguien en la plataforma. Entonces pondremos 0..* del lado del articulo. Y, ¿por cuántos vendedores puede ser vendido un mismo articulo? Esto depende si consideramos que los artículos son únicos o si varias personas pueden vender el mismo tipo de artículo. Desde luego, en la medida de lo posible, queremos que artículos idénticos estén catalogados dentro de la misma categoría. Así podremos, por ejemplo, comparar los precios para un mismo artículo. Puede ser que en algún momento no haya más vendedores

vendiendo este artículo o que lo venden un número indeterminado de personas. Pondremos 0..* del lado de los vendedores. Ésta es una relación de varios a varios. Relaciones de uno a uno Finalmente, vamos a mirar la relación entre Envíos y Pagos. En este caso, consideramos que a cada envío le corresponde un solo pago y vice-versa. Un envío se creará en cuánto se realice el pago del articulo. Es casi cómo si fuesen lamisma entidad. Los separamos para mantener la semántica de lo que representan. Así podemos diferenciar mas fácilmente la fecha de envío de la fecha de pago, y la dirección de envío de la dirección de pago. Entonces, lo que aquí acabamos de definir es una relación de uno a uno. Establecer el diagrama completo del sistema Este es el diagrama completo. Hemos añadido las relaciones comprador-envío (uno a varios) y vendedor-envío (uno a varios). Añadimos unos verbos en las lineas entre entidades.

Diagrama de clase con las cardinalidades de las relaciones Como puedes ver, no todas las entidades tienen relaciones directas con las otras. Por ejemplo, no hay relaciones directas entre un artículo y un comprador. Sería redundante, porque ya tenemos una relación definida entre el comprador y el vendedor a través de un envío. Por el mismo motivo, no hay una relación directa entre comprador y vendedor ya que está contemplada a través de un envío. ¡Éste sólo es uno de los muchos modelados posibles del sistema! No hay solo una respuesta correcta para el diseño y depende de decisiones tomadas en un equipoy de la implementación. Eso si, dado que UML es un lenguaje estandardizado, el significado de las relaciones definidas es muy

especifico y deberá ser implementado de forma rigurosa por los programadores. Ahora que hemos visto los elementos básicos de un diagrama de clase, vamos a introducir elementos del análisis orientado a objetos, que es la filosofía subyacente al lenguaje UML.

Conceptos del análisis orientado a objetos A continuación, vamos a introducir unos conceptos de Análisis Orientado a Objetos (AOO) normalmente destinados a la programación orientada a objetos pero que también nos pueden ser útiles diseñando bases de datos. Estos conceptos y su representación asociada pueden ser incluidos en el diagrama de clase de nuestros sistema, aunque no son obligatorios. Permiten ser mas precisos en la semántica que se recoge en nuestro modelo.

Clase e Instancia Unos elementos fundamentales del AOO son las nociones de objetos, clases, e instanciación.

La clase Una clase es una plantilla para objetos, con una especificación sobre qué atributos deben comportar estos objetos para poder ser considerados como parte de esta clase. Una clase puede describir algo abstracto (el estado de un proceso, un comportamiento) tanto como algo físico (una mercancía, una persona). Las clases son el concepto que manipulamos diseñando nuestro diagrama de clase. Definiendo clases y sus atributos , intentamos anticipar los agentes de nuestro sistema y sus comportamientos, para poder clasificarlos mejor. Eligiendo las metáforas correctas podemos describir cualquier cosa con clases.

El objeto Un objeto es un elemento único e identificable, que tiene que derivar de una clase. Se dice que es una instancia de esta clase, cuando posee todos los atributos de la clase y les atribuye un valor. La instanciación La instanciación es el proceso de creación de un objeto a partir de una clase. El resultado es un objeto con atributos definidos que es añadido a nuestra base de datos o a nuestro programa. El diagrama de objetos permite dar ejemplos de qué valor pueden recibir estos atributos, es decir que proporciona un ejemplo de instanciación de las clases que definimos. Se usan los términos instancia y objeto como equivalentes.

Herencia El AOO nos permite definir una relación de herencia entre clases. La clase de la que se herede se dice que es una abstracción de la que herede. Por ejemplo, si volvemos al ejemplo de nuestra plataforma de venta introducida en lo capítulos anteriores.

Ambos Vendedores y Compradores realmente son Usuarios. Podemos crear una abstracción de la que heredan ambas clases. Así podemos tener los atributos comunes a todos los usuarios, como sus nombres y apellidos, y los atributos y asociaciones específicos a un Vendedor solo estén reflejados en la clase correspondiente. Ademas, si un usuario, después de darse de alta como comprador, decide darse de alta como vendedor, puede hacerlo simplemente creando una nueva instancia de la clase Vendedor con una referencia al Usuario creado antes.

Ejemplo de herencia

En el modelo relacional no hay relación de herencia, pero este concepto puede ser útil durante el diseño y es fácil de implementar en el modelo físico de datos. Pondremos una referencia de clave ajena en cada de las tablas que heredan de la clase Usuario

Composición y Agregación Composición Cuando objetos de una clase están compuestos de elementos de otra clase se llama una relación de composición. Las composiciones son un subconjunto de las relaciones de uno a varios. Por ejemplo : 

un equipo está compuesto de varios miembros  un avión está compuesto de asientos  un parking está compuesto de aparcamientos La composición se representa con un diamante negro del lado del contenedor. A continuación te mostramos el ejemplo de una relación de composición entre Parking y Aparcamiento.

Ejemplo de una relación de composición

Agregación Cuando objetos de una clase son los componentes de otra clase pero los componentes de esa clase no tienen que formar parte de los objetos de la clase contenedora se trata de una relación de agregación.

Por ejemplo : 

un equipo tiene un campo para entrenar  un avión tiene pasajeros  un parking contiene coches La agregación se representa con un diamante blanco del lado del contenedor. Aquí tienes un ejemplo de una relación de agregación entre Parking y Coche.

Ejemplo de una relación de agregación

Una forma de reconocer si se trata de una relación de agregación o de composición es evaluar el grado de integración de los elementos. Si el elemento que contiene a los otros no puede existir sin los subelementos, se trata de composición. Si no, hablamos de una agregación. Las relaciones de agregación y composición son una forma de recoger semánticamente un tipo de relación uno a varios, con una cardinalidad 1..* del lado del contenido para la composición (sin contenido no hay contenedor) y una cardinalidad 0..* del lado del contenido para la agregación (sin contenido puede haber contenedor). Te parece muy abstracto lo que acabamos de presentar? El AOO es considerado muchas veces el arma definitiva del programador, pero al principio es difícil entender para qué sirve y cómo aplicarlo correctamente. En general, podemos decir que su objetivo es hacernos la vida mas fácil permitiendo reutilizar y especializar los comportamientos y atributos que definimos. Si es verdad que no es necesario para las bases de datos en si, a la hora de programar código que interactúe con esta base de datos , sí que tendremosque usar estas abstracciones. Ánimo!

Con estos nuevos conceptos podemos cubrir mejor la semántica de nuestros sistema y también aprendimos a mantener la consistencia de nuestras bases de datos y evitar redundancia.

Ejercicio : Casos de Uso Nada mejor para asimilar un conocimiento que de ponerlo en práctica!

Este curso usaba el ejemplo de una plataforma de ventas entre particulares. Ahora va a ser tu responsabilidad encargarte de algo similar con un sistema de alquiler de bicicletas. Se trata de una nueva app, OpenBikes, que permite alquilar bicicletas conectadas a Internet por toda la ciudad. También llevan GPS, lo que permite ubicarlas en un mapa y encontrar la bici más cerca. Las bicicletas llevan un candado controlado por la app. 🚲 Un caso de uso textual podría ser el siguiente: Un usuario quiere desplazarse usando la app OpenBikes. Ya se ha dado de alta y ha pagado la suscripción mensual para poder utilizar el servicio. Abre la app en su móvil y ubica la bicicleta más cercana gracias al mapa que muestra las bicicletas. Puede reservarla durante unos minutos para estar seguro de que no se la lleve otra persona antes de que llegue. Cuando llegue a la bicicleta, a través del sistema, desbloquea el candado y se puede ir con ella. El tiempo de uso que le permite su suscripción es de 30 minutos. Si gasta más tiempo en ello se le cobrará un suplemento. Al terminar su desplazamiento, debe atar la bici y confirmar que el sistema ha detectado la nueva ubicación de la bicicleta y su disponibilidad. Si no, se le podría cobrar un suplemento correspondiente al tiempo que estuvo sin poder usarse. Escribe el diagrama de casos de uso que corresponde a este caso de uso textual, con la herramienta que prefieras. Imagina cuáles son los actores, las acciones, y sus posibles elaciones extend e include. Puede ser algún programa para dibujar diagrama, o simplemente con una hoja y un lapiz.

Ejercicio : Diagrama de clase Genial, ahora que has hecho el diagrama de casos de uso para OpenBikes, ¡es hora de traducir esto al diagrama de clase! A partir de la descripción del apartado anterior, puedes sacar los principales elementos del sistema. Se trata de una nueva app, OpenBikes, que permite alquilar bicicletas conectadas por internet por toda la ciudad. También llevan GPS, lo que permite ubicarlas en un mapa y encontrar la bici más cercana. Las bicicletas llevan un candado controlado por la app. 🚲 Te volvemos a poner el caso de uso textual: Un usuario quiere desplazarse usando la app OpenBikes. Ya se ha dado de alta y ha pagado la suscripción mensual para poder utilizar el servicio. Abre la app en su móvil y ubica la bicicleta más cercana gracias al mapa que muestra las bicicletas. Puede reservarla durante unos minutos para estar seguro de que no se la lleve otra persona antes de que llegue. Cuando llegue a la bicicleta, a través del sistema, desbloquea el candado y se puede ir con ella. El tiempo de uso que le permite su suscripción es de 30minutos. Si gasta más tiempo en ello se le cobrará un suplemento. Al terminar su desplazamiento, debe atar la bici y confirmar que el sistema ha detectado la nuevaubicación de la bicicleta y su disponibilidad. Si no, se le podría cobrar un suplemento correspondiente al tiempo que estuvo sin poder usarse.

Escribe el diagrama de clase que corresponde con esta descripción e imagina cuales serían las clases, atributos, relaciones, cardinalidad de las asociaciones que forman el sistema.