Enjoy A New Student Discount All 55,000 Courses on sale for Only $12.99

Ends in 05h 23m 49s

OOP (III) – Diseñando la aplicacion. Casos de uso

Ahora que ya conocemos conceptos tales como abstracción, herencia, polimorfismo y encapsulacion, ha llegado el momento en que veamos como podemos iniciar el diseño de un proyecto (naturalmente un diseño orientado a objetos), para poder aplicar luego una programación orientada a objetos

Nota: Podéis encontrar mas información acerca de las notaciones gráficas del UML en el articulo de Introducción al UML que hemos publicado.

Como en cualquier análisis, lo primero sera descubrir que es lo que nuestro cliente quiere.

Requerimientos.

Para conocer los requerimientos, deberemos hablar con la persona (nuestro cliente o un empleado suyo) que conoce los objetivos del proyecto, exactamente igual que se ha hecho en cualquier análisis….desde el principio de «esto»

La descripción de esa entrevista, la realice tiempo atrás, para crear una tienda de incienso…. y dado que nuestro trabajo se va a basar en ello, es mejor que la leáis.

A partir de esa hipotética reunión con el cliente debemos establecer

Que es lo que ha de hacer la aplicación

Dentro de esos requerimientos, habrá una parte funcional, «lo que ha de hacer», y otra parte no funcional relativa a usabilidad, fiabilidad, rendimiento, soporte, seguridad, limitaciones legales, equipo necesario, lenguaje de programación, sistema objetivo…que no vamos a revisar en estos artículos, pero que son totalmente imprescindible para plantearse un desarrollo con un mínimo de seriedad

Teniendo todo esto en mente, vamos a releer la entrevista y extraer los requerimientos mínimos necesarios. De dicha lectura obtengo:

La aplicación debe:

  • realizar ventas
  • gestionar productos
  • gestionar existencias
  • gestionar artículos y comentarios (un blog)
  • listar artículos por categorías
  • listar productos por categorías
  • gestionar un carro de compras
  • gestionar usuarios

Daros cuenta que no intento detallar todo lo que hace la aplicación, solo menciono temas, y ya los desarrollaré mas adelante; se trata de tener un documento con el que revisar con el cliente las lineas principales del proyecto

Describir la aplicación

Para describir la aplicación, vamos a utilizar un Diagrama de Casos de uso, aunque nuestro primer paso serán los casos de uso, que nos muestra en detalle por medio de una descripción completa literal, lo que tenemos que hacer, mientras que el diagrama no hace mas que mostrarnos una visión conjunta de los casos de uso que tenemos y como están relacionados.

Casos de uso

Debemos reconocer que los Casos de uso no son un recurso orientado a objetos como tal, pero si es una de las mejores maneras que hay para ir localizando los requerimientos y necesidades de la aplicación, en pleno diálogo con el cliente o usuario final.

Todo caso de uso debe contener .

  • Titulo. Se trata de establecer la acción que se va a realizar
  • Actor: Una entidad externa al sistema que inicia/solicita la acción
  • Escenario: Como se va a llevar a cabo la acción o como vamos a cumplir el objetivo.

Mientras que Titulo debe ser una frase corta con un verbo activo, un escenario puede ser un párrafo escrito en lenguaje corriente, para que cualquier persona pueda entenderlo, nosotros os proponemos que lo intentéis hacer con la forma de lista.

Para el tema de actores, deberemos considerar que, aunque la mayoría de las veces los actores serán personas que necesitan algo de la aplicación, también hemos de tener en cuenta cualquier proceso informático que necesite interactuar con la aplicación.

Incluso en el caso de las personas, debemos considerar, no tanto la persona, como el rol, ya que puede que tenga que participar como administrador, o como usuario….y también puede que un mismo actor necesite conseguir objetivos distintos, lo que dará lugar a casos de uso distintos

También podemos detallar mas apartados como:

  • Actor secundario, cuando el actor no es el que inicia la petición
  • Flujos alternativos, en donde podemos describir caminos alternativos a la acción normal, que sucede por causa de alguna incidencia.
  • Precondiciones, Cual debe ser la situación para que se pueda llevar a cabo este caso de uso
  • Postcondiciones, qué debe cumplirse cuando el caso de uso se completa con éxito, o bien el flujo básico o algún flujo alternativo

Teniendo en cuenta que hay gente que ha trabajado mas que yo esta idea (casi todo el mundo), os puedo referir, por ejemplo, a este trabajo sobre plantillas de casos de uso. Nosotros, en este articulo vamos a utilizar esta plantilla ( a la que puedo añadir mas apartados si los necesito):

Plantilla para caso de uso

Ahora veremos como rellenaría un caso de uso para Registrar un usuario.

Caso de Uso. Registro de usuario

Como deseamos que nuestro registro sea en dos pasos, prepararemos otro caso de uso:

Caso de uso autorizacion de registro

Y así iremos definiendo todos los casos de uso, hasta conseguir tener  explicada la aplicación.  El objetivo final, es que podamos leer todo esto con nuestros usuarios, y ellos puedan entender perfectamente como funciona la aplicación.

Para ello, utilizaremos un lenguaje sencillo, e intentaremos describir lo que se ha de hacer, no el como se ha de hacer.

Recordad que cada caso de uso ha de perseguir un objetivo DE NEGOCIO, (por ejemplo, logonarse no es un objetivo de negocio, «Hacer un pedido» si es un objetivo de negocio, por lo que puede ser caso de uso, e internamente, puede incluir «logonarse»).

Recordad también que un objetivo valido para caso de uso será aquel que el actor pueda realizar con UNA SOLA interacción, osea que los objetivos complicados, los deberemos partir en varios casos de uso que se puedan resolver con u

En las descripciones, no os olvidéis el utilizar lenguaje normal para el cliente o usuario, pero también deberéis tener cuidado para omitir palabras innecesarias, por ejemplo en lugar de :

Al sistema se le da la información necesaria por parte del usuario

podemos decir

El usuario proporciona la información

o

El usuario introduce los datos

Utilizando acciones en primera persona, facilitamos la comprensión de los pasos.

Todo va bien si no entramos en detalles; si no utilizamos palabras como «Haz click», «Despliega la lista»,  «Pulsa el botón»…. En esta fase debemos especificar lo que queremos hacer; las intenciones, y no nos debemos preocupar del «Como».

Hasta ahora, hemos hablado de las charlas con el cliente, y de como habéis ido encontrando los casos de usos gracias a esas charlas; ahora os invito a que os hagáis unas cuantas preguntas, para ver si necesitáis mas actores. Preguntas como:

  • Hay algún responsable que gestione usuarios?
  • Hay alguien encargado de hacer copias, de administrar el sistema…?
  • Hay alguien siguiendo el funcionamiento de la aplicación’ (Estadísticas, rendimiento, incidencias….)?
  • Con que otros «Actores» mecánicos/electrónicos, ordenadores, aplicaciones se debe relacionar la aplicación?

Dado que estamos planteando un método iterativo, no necesitamos detectar todos los actores; solo los imprescindibles, luego volveremos a por mas. Estamos intentando no quedarnos bloqueados durante meses en esta fase del diseño.

Diagramas de casos de uso

Si ya hemos terminado de escribir los casos de uso que necesitamos, podemos verlos en conjunto por medio  del diagrama de casos de uso.

Un diagrama de casos de uso no sustituye a los casos de uso; mientras que un caso de uso detalle que es lo que se tiene que hacer para conseguir un objetivo, un diagrama de casos de uso, muestra de una forma gráfica un conjunto de casos de uso y sus actores de forma resumida.

Por ejemplo, podríamos visualizar la gestión de usuarios que necesitamos por medio de un diagrama de casos de uso.

Diagrama de casos de uso para usuarioEn el diagrama vemos dos casos de uso que ya hemos estudiado en detalle (CDO-Registro y CDU-Autorizacion) y otros que todavía no los hemos visto. El diagrama nos ha ayudado también a pensar en las funcionalidades que necesitabamos, y en los actores que podían aparecer.

Tenemos que pensar que todo esto son herramientas que nos ayudan a pensar, por lo que el nivel de detalle que tenemos que utilizar sera el adecuado para cada situación ,pero haciendo especial énfasis en que, para este articulo, el análisis no es un fin en si mismo, si no únicamente un medio.

En el siguiente artículo, veremos mas herramientas que podemos utilizar para afinar nuestro diseño

 

 

/*Si te ha gustado el artículo
no dudes en compartirlo*/

Facebook
Twitter
LinkedIn

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies

Ver mi IP

Ver ip de mi máquina
tipo valor
Ip: 54.173.214.79
Proxy: 54.173.214.79
Remote host: ec2-54-173-214-79.compute-1.amazonaws.com
Remote port: 16976
** 54.173.214.79