Un Caso Practico UML Proceso de Desarrollo

UML – RUP Un caso práctico

1

UML-RUP UM L-RUP - un caso práctico Objetivos

El presente ejemplo, que se complementa con el curso de UML-RUP, tiene como fin presentar un caso práctico (simplificado) que sirva a los alumnos como modelo para desarrollar un sistema OO, utilizando UML y el Proceso de Desarrollo. Desarrollo

1. Descripción básica del problema 2. Definición de los Casos de uso a. Identificación de los actores b. Diagrama de contexto c. Identificación de los casos de uso d. Diagramas de caso de uso e. Descripción básica de los casos de uso i. Refinamiento f. Descripción detallada de los casos de uso 3. Definición del modelo de clases de dominio 4. Definición de diagramas de interacción a. Diagramas de secuencia de sistema b. Diagramas de colaboración colaboraci ón para asignar responsabilidades responsabi lidades 5. Definición de diagramas de clases de diseño diseño 6. Persistencia de las clases en un modelo relacional Dentro de un proceso de desarrollo iterativo e incremental, podríamos considerar que estamos en una primera iteración, en la etapa de elaboración. No consideramos la codificación (estamos cubriendo la parte marcada con doble línea negra)

Mg Carlos Neil

Material preparado para el curso UML - Proceso de Desarrollo


2

1. Descripción básica del problema Compañía de Ventas

de Libros por I nternet ( CVLI)

El cliente accede a la información sobre los libros a través de la Web El cliente elegirá un nombre de usuario y una clave como método de autentificación para efectuar las transacciones El cliente podrá realizar búsquedas por autor, título o ISBN El cliente debe estar previamente registrado El cliente puede establecer preferencias de envío El cliente puede introducir opciones de empaquetado La librería deberá recoger los datos de los pedidos La librería deberá rearmar en uno único los pedidos aislados que estén dentro del plazo de 90 minutos La empresa puede realizar envíos parciales en función de la disponibilidad de los ítems 1.a. Identificación de los actores

Cliente (primario) Administrador del sistema (primario) Tarjeta de crédito (secundario) Gestor de libros (secundario) 1.b. Diagrama de contexto << actor>>

0..1

TARJETA DE CREDITO

0..* secundario

Cliente CVLI

<< actor>>

secundario

GESTOR DE LIBROS

0..1

0..1 secundario

Administrador Sistema

0..1

<< actor>> GESTOR DE ENVIO

1.c. Identificación de los casos de uso Cliente

Registrarse al sistema Consultar libro Comprar libro Establecer preferencias de envío y empaquetado Mg Carlos Neil



3

Administrador del sistema

Armar pedidos Rearmar pedidos 1.d. Diagrama de Casos de Uso

Registrarse al sistema Gestor de Libros

Consultar libro Tarjeta de Credito Cliente Comprar libro

Establecer preferencias de envío y empaquetado

Arma r pedidos

Rearmar pedidos

Administrador del Sistema

1.e. Descripción de los casos de uso nota :

esta descripción podría corresponder a la etapa de inicio, donde se trabaja la visión y el análisis del negocio Titulo: Registrarse al sistema Resumen: el cliente, antes de realizar

una primera transacción de compra o búsqueda de libros, debe introducir todos sus datos por única vez, los cuales serán guardados por el sistema y éste le ofrecerá la posibilidad de tener una clave y contraseña que utilizara para cada transacción que realice posteriormente, el cliente tendrá la posibilidad de hacer cambios en los datos introducidos, incluso en su clave y contraseña Actores: cliente (primario), tarjeta de crédito (secundario) Titulo: Consultar libro Resumen: el cliente, una

vez ingresado al sistema, podrá navegar por el mismo en búsqueda de libros, novedades, ofertas, etc. Actores: cliente (primario), gestor de libros (secundario) Titulo: Comprar libro Resumen: el cliente, una

vez ingresado al sistema, podrá realizar compras de libros, eligiéndolo de una lista ofrecida por la empresa, cada libro elegido, se sumara a una carrito de compra, etc. El cliente informará el numero y tipo de tarjeta de crédito para realizar el pago. Deberá especificar dirección de envió y forma de pago Actores: cliente (primario), gestor de libros (secundario), tarjeta de crédito (secundario)

Mg Carlos Neil



4

Titulo: Establecer preferencias de envío y empaquetado Resumen: el cliente, en cada pedido, podrá asociar al mismo

empaque, dirección de envío, mensaje en la tarjeta, etc Actores: cliente (primario)

opciones tales como tipo de

Titulo: Armar pedidos Resumen: El administrador

del sistema, agrupará todos los pedidos realizados por un cliente para proceder a su despacho , permitiéndole al cliente realizar modificaciones al pedido original. Se enviara un notificación por mail al cliente Actores: Administrador del Sistema (primario) Titulo: Rearmar pedidos Resumen: El administrador

del sistema, una vez completado el pedido definitivo puede rearmarlo en función de las limitaciones respecto a los libros en disponibilidad, no obstante el costo del pedido no se modifica, avisándole al cliente que el resto del pedido se efectuara ni bien se actualicen las existencias Actores: Administrador del Sistema (primario) 1.e.i Refinamiento nota : esta sección podría

corresponderse con una segunda iteración

Especialización de cliente

El cliente ocasional, que puede mirar las novedades, best-sellers o buscar un libro determinado de acuerdo a un criterio y el cliente especializado (estudiante, investigador o profesor) que puede necesitar ver los libros que tratan sobre un tema específico

Registrarse al sistema

Consultar libro Cliente Especializado

Cliente

Comprar libro

Cliente Ocasional Establecer preferencias de envío y empaquetado

Mg Carlos Neil



Metas Nota: las

5

metas son fines que debe lograrse independientemente de cómo se obtenga <<meta cualitativa>> uso del sistema

<<meta cuantitativa>> busqueda en sistema

UdeM1 : interfaz = amigable UdeM2 : exito en la busqueda = alto

UdeM1 : tiempo respuesta < 2 seg

<<meta cuantitativa>> errores en el sistema UdeM1 : cantidad de errores = 0 Cliente Ocacional Cliente

Cliente Especializado

Uso de extensiones e inclusión

Consultar libros en general

Consultar novedades

Consultar ofertas

<> <> <>

Gestor de Libros

Consultar libro Cliente <>

Tarjeta de Credito

Comprar libro <>

Establecer preferencias de envío y empaquetado

Mg Carlos Neil



6

Nuevos casos de uso

Consultar libros en general Consultar novedades Consultar ofertas f. Descripción detallada de casos de usos Nota: hay

muchas formas de representar los casos de uso, lo importante es describir con claridad los requerimientos de los usuarios Titulo: Registrarse al sistema Resumen: el

cliente, antes de realizar una primera transacción de compra o búsqueda de libros, debe introducir todos sus datos por única vez, los cuales serán guardados por el sistema y éste le ofrecerá la posibilidad de tener una clave y contraseña que utilizara para cada transacción que realice posteriormente, el cliente tendrá la posibilidad de hacer cambios en los datos introducidos, incluso en su clave y contraseña Actores: cliente (primario), tarjeta de crédito (secundario) Fecha de creación: Fecha de actualización: Versión: Precondición:

el cliente ingresa al sistema por primera vez

Escenario principal

El cliente ingresa a la pagina web de CVLI El cliente ingresa a la opción “registración “ El sistema solicita ingreso de los datos personales: nombre y apellidos, dirección, localidad, código postal, país 4. El cliente ingresa los datos personales 5. El sistema evalúa el país de origen y solicita ingreso de los datos de la tarjeta de crédito: tipo de tarjeta, número, fecha límite de validez 6. El cliente ingresa datos de la tarjeta de crédito 7. El sistema chequea el número de la tarjeta de crédito 8. El sistema (teniendo en cuenta el país de origen) solicita la opción de preferencia de envío por omisión, esta opción puede modificarse en cada envío 9. El cliente ingresa preferencia de envío 10. El sistema solicita, para finalizar, el ingreso de la clave de acceso y la contraseña 11. El cliente ingresa clave y contraseña 12. El sistema solicita reingreso de contraseña 13. El cliente reingresa contraseña 14. El sistema informa que la transacción se realizo correctamente 1. 2. 3.

Flujo alternativo Mg Carlos Neil



A1 Ingreso

7

incorrecto de los números de los datos

La secuencia comienza en el punto 4 del escenario principal 5. 6.

El sistema informa que los datos ingresados son incorrectos El sistema pide ingreso de números nuevamente

El escenario vuelve al punto 5 A2 Ingreso

incorrecto de los números de la tarjeta de crédito

La secuencia comienza en el punto 7 del escenario principal El sistema informa que los números ingresados son incorrectos el sistema evalúa si la cantidad de veces que ingreso el número de tarjeta en forma incorrecta es menor a 3 9. El sistema pide ingreso de números nuevamente 7. 8.

El escenario vuelve al punto 8 Poscondición:

el cliente está registrado en el sistema

Titulo: Consultar libro

el cliente, una vez ingresado al sistema, podrá navegar por el mismo en búsqueda de libros, novedades, ofertas, etc. Resumen:

Actores: cliente

(primario), gestor de libros (secundario)

Fecha de creación: Fecha de actualización: Versión: Precondición:

el cliente se ha registrado previamente

Escenario principal

El cliente ingresa a la opción consulta de libros El sistema despliega la opciones a. Ir a CONSULTAR LIBROS EN GENERAL b. Ir a CONSULTAR NOVEDADES c. Ir a CONSULTAR OFERTAS 3. El sistema vuelve al menú principal 1. 2.

Mg Carlos Neil



8

Titulo: Consultar libro en general

el cliente, una vez ingresado al sistema, podrá navegar por el mismo en búsqueda de libros para una posterior compra Resumen:

Actores: cliente

(primario), gestor de libros (secundario)


el cliente ha ingresado a la opción consultar libros

Escenario principal

1. 2. 3. 4.

El cliente solicita listado de libros El sistema despliega listado de libros El cliente navega por las lista de libros El cliente elige un libro y opta por alguna de las opciones a. consultar detalles de libro b. incluir libro en su carrito de compras c. eliminar libro de su carrito de compra 5. El sistema permite, si el cliente lo desea, elegir otro libro (va al punto 3) 6. El sistema muestra carrito de compra con detalles de libros y precio total de la transacción 7. El cliente, si lo desea, puede modificar el contenido del carrito 8. El cliente solicita ir al menú principal 9. El sistema despliega el menú principal 10. Del cliente elige opciones del menú principal o salir del sistema Flujo alternativo A1

falta de disponibilidad actual del libro


El sistema informa que no existe disponibilidad actual de ese libro El sistema solicita elegir otro libro

El escenario vuelve al punto 4 Poscondición:

el carrito de compras tiene cero o mas libros elegidos para la compra

Titulo: Comprar libro

el cliente, una vez ingresado al sistema, podrá realizar compras de libros, eligiéndolo de una lista ofrecida por la empresa, cada libro elegido, se sumara a una carrito de compra, etc. El cliente informará el numero y tipo de tarjeta de crédito para realizar el pago. Deberá especificar dirección de envió y forma de pago Resumen:

Mg Carlos Neil



Actores: cliente

9

(primario), gestor de libros (secundario), tarjeta de crédito (secundario)


el cliente ha ingresado al sistema

Escenario principal 1. El cliente ingresa a la pagina de CVLI 2. El sistema muestra opciones de navegación 3. El cliente ingresa opción de ingreso al sistema de venta 4. El sistema pide ingreso de clave y contraseña 5. El cliente ingresa clave y contraseña 6. El sistema muestra opciones de navegación 7. El cliente ingresa opción de compra 8. El cliente va a CONSULTAR LIBRO 9. El sistema pide número de tarjeta de crédito 10. El cliente ingresa el número de tarjeta 11. Si el usuario lo requiere, ir a ESTABLECER PREFERENCIAS DE ENVÍO Y

EMPAQUETADO 12. El sistema despliega mensaje de transacción realizada 13. El sistema vuelve al menú principal Flujo alternativo A1 Ingreso

incorrecto de clave y contraseña


El sistema informa que clave y/o contraseña ingresados son incorrectos El sistema pide ingreso nuevamente

El escenario vuelve al punto 6 A2

Transacción Abortada

La secuencia comienza en el punto 12 del escenario principal 13. El 14. El

sistema informa que hubo un problema en la transacción sistema solicita al usuario comenzar nuevamente la compra

El escenario vuelve al punto 13 el cliente ha realizado la compra, el sistema a registrado la venta, la tarjeta de crédito ha autorizado la transacción Poscondición:

Mg Carlos Neil



10

3. Definición del modelo de clases de dominio

El modelo de dominio muestra los objetos del dominio o clases conceptuales, asociaciones entre clases y atributos. NO son componentes software. En una primera etapa reconocemos las clases más significativas Diagrama de Clases Cliente nombre apellido direccion te profesion

1

1 tiene

usa

1

0..*

CarritoCompra

OrdenCompra

es de

1 1

1

numero tarjeta direccionEntrega opcionEntrega

tiene

1..*

Items cantidad

EjemplarLibro

0..*

pertenecen

1

numero precio

1..*

tiene

1 Libro isbn titulo editorial soporte categoria

Mg Carlos Neil

Aut or esta escrito por

1..*

1..*

nombre apellido



11

4. Definición de diagramas de interacción a. Diagramas de secuencia de sistema Registrarse al Sistema : SISTEMA

: cliente

ingresarSistema()

ingresarDatosPersonales()

ingresarTarjetaCredito()

ingresarPreferenciasEnvio()

ingresarClaveContraseña()

Comprar Libro : SISTEMA

: cliente

ingresarSistema()

ingresarClaveContraseña()

comprarLibro()

consultarLibro()

corresponde al <> CONSULTAR LIBRO

verListadoLibros()

elegirLibro()

ingresarTarjeta()

terminarTransacción()

Mg Carlos Neil



12

El diagrama de secuencia de sistema muestra, para un escenario específico de un caso de uso, los eventos que generan los actores externos. Los sistemas se tratan como cajas negras. El diagrama de secuencia muestran los mensajes que podrían ser traducidos a operaciones dentro del sistema. Si el sistema estuviera constituido por una sola clase, éstas serían las operaciones candidatas que debería tener (teniendo en cuenta los dos casos de uso que analizamos) La distribución de operaciones en las distintas clases, correspond e a una actividad de diseño

SISTEMA ingresarSistema() ingresarDatosPersonales() ingresarTarjetaCredito() ingresarPreferenciasEnvio() ingresarClaveContraseña() comprarLibro() consultarLibro() verListadoLibros() elegirLibro() terminarTransacción()

Mg Carlos Neil



13

4. Definición de diagramas de interacción b. Diagramas de colaboración para asignar responsabilidades a. Uso del patrón “Experto”

Reconocemos una operación en el DSS comprar libro , en esta etapa, le damos un nombre más representativo: venta ¿Quién es el responsable de saber la cantidad de ítems vendidos?. Desde el punto de vista del patrón Experto, deberíamos buscar la clase de objetos que posee información sobre los Items ; el objeto que conoce esto es CarritoCompra. ¿Qué información hace falta saber para determinar la cantidad de items pedidos y el precio para saber la venta total? La cantidad de items pedido está en la clase Items y el precio, en EjemplarLibro, ambos tienen la información necesaria para realizar la responsabilidad

b. Uso del patrón “Creador”

En la aplicación ¿quién debería encargarse de crear una instancia de items ? Desde el punto de vista del patrón Creador, deberíamos buscar una clase que agregue, contenga, y realice otras operaciones sobre este tipo de instancias. Un CarritoCompra contiene (agrega) muchos objetos Items . Es por esto que el patrón Creador sugiere que CarritoCompra es la clase idónea para asumir la responsabilidad de crear las instancias de Items . Este método no lo encontramos inicialmente en el DSS. La creación de instancias es una de las actividades más comunes en un sistema orientado a objetos

Mg Carlos Neil



14

c. Otras asignaciones

Existen otras operaciones en el DSS, cuya asignación en mas evidente: IngresarDatosPersonales es una responsabilidad de la clase Cliente ConsultarLibro es una responsabilidad de Libro IngresarPreferenciasEnvio es una responsabilidad de OrdenCompra 5. Definición de diagramas de clases de diseño

El diagrama de clases quedaría entonces, con la inclusión de las operaciones: Cliente nombre apellido direccion te profesion

1

1

usa

tiene

1

0..*

CarritoCompra agregarItem() venta()

OrdenCompra

es de

1 1

1


tiene

1..* EjemplarLibro

Items cantidad crear() subtotal()

0..*

numero precio

pertenecen

1 darPrecio() 1..*

tiene


Autor esta escrito por

1..*

1..*

nombre apellido

Figura 1 Mg Carlos Neil



15

Puede suceder que existan operaciones que reconocimos en las primeras etapas análisis y que, en la fase de diseño, consideremos innecesario asignarlas a una clase en particular. En un refinamiento posterior, luego de la primera iteración, podríamos tener este diagrama de clases (analicen las diferencias con el de la figura 1)

ClienteOcacional

ClienteEspecializado

profesion Cliente nombre apellido direccion te

tiene

1

0..*

OrdenCompra numero

ingresarDatos()

IngresarPreferencias()

1

1 es de

usa

1

1

1

1 CarritoCompra

Tarjeta

agregarItem() venta()

nombre numero

1

1

1

1

OpcionEntrega

DireccionCompra

tipo

calle numero

1 tiene

Categoria

1..*

tipo


EjemplarLibro

0..* pertenecen

1

numero

1

darPrecio()

per ten ece

1..*

1..*

tiene

1

Libro isbn titulo editorial ConsultarLibro() 1..* escrito por

1..*

Au to r nombre apellido

Mg Carlos Neil



16

6. Persistencia de las clases en un modelo relacional

Debido al predominio de las bases de datos relacionales, es normal mantener las persistencia de los objetos en tablas Modelo básico de transformación Todas las clases se transforman en entidades o Los atributos de la clase pasan a ser atributos de la entidad o Se crean atributos identificadores para cada entidad Las clases asociación se transforman en interrelaciones o La multiplicidad es de M:N o Los atributos de la clase asociación pasan a ser atributos de la interrelación Las asociaciones se transforman en interrelaciones o Se mantiene la misma multiplicidad de la asociación en las interrelaciones Diagrama de clases a partir del cual realizamos el mapeo con los criterios anteriores

Cliente nombre apellido direccion te profesion

1

1

usa

tiene

1

0..*

CarritoCompra agregarItem() venta()

OrdenCompra

es de

1 1

1


tiene

1..* EjemplarLibro


numero precio

0..* pertenecen 1

darPrecio() 1..*

tiene


Mg Carlos Neil

Autor esta escrito por

1..*

1..*

nombre apellido



17

Modelo Entidad Interrelación resultante del mapeo cod_ord

cod_cli

CLIENTE

ORDENCOMPRA 1

N

1

1

cod_carro 1 CARRITOCOMPRA

1

1 num_ejemp N N

1

ITEMS

EJEMPLARLIBRO N num_item

cod_autor

cod_libro 1 N

AUTOR

Nota :

N LIBRO

omitimos, por simplicidad, dibujar los atributos

Transformación del modelo Entidad Interrelación al Modelo Relacional

Cliente (cod_cli, ...) OrdenCompra (cod_ord, ..., cod_cli(Cliente)) CarritoCompra (cod_carro, ..., cod_cli(Cliente), cod_ord(OrdenCompra)) Items (num_item, ..., cod_carro(CarritoCompra), num_ejem(EjemplarLibro)) EjemplarLibro (num_ejem, ..., cod_libro(Libro)) Libro(cod_libro, ...) Autor(cod_autor, ...) LibroAutor(cod_libro(Libro), cod_autor(Autor))

Mg Carlos Neil


Un Caso Practico UML Proceso de Desarrollo

Recommend Documents