OOP(IV)-Diseñando la aplicacion. Mas recursos

Para realizar un análisis, hay que reconocer la utilidad de los “Casos de usos”, y darle la importancia que se merece, dedicándole el tiempo adecuado. Sin embargo, no es la única herramienta que podemos utilizar, en este articulo vamos a ver alguna mas, como las “Historias de usuario”,  “Modelo conceptual del sistema” y la “Identificacion de responsabilidades”

Historias de usuario.

Las historias de usuario frases en la que el usuario indica lo que quiere, y porqué lo quiere. Toda las ventajas las obtendremos si conseguimos que cada historia se resuma en una  única frase corta.

Realmente la frase que proponemos es:

  • Como tipo de usuario
  • Quiero funcionalidad/objetivo
  • Para motivo

Ejemplos de esta formulación podría ser:

  • Como visitante quiero registrarme para hacer compras
  • Como usuario quiero modificar mis datos
  • Como administrador quiero gestionar los usuarios

Aunque la parte del “para” es opcional, es muy conveniente ya que puede perfilar las necesidades, y descubrir nuevas formas de atenderlas, aunque nos obligara a ir pensando en usabilidad.

Si lo observáis, esta orientado a intenciones, no a la forma de implementarlas. Si vamos guardando estas “peticiones” en tarjetas, nos permitirá, mas adelante, hablar sobre ello con los usuarios, y con eso profundizar  mas en los requerimientos. Al tener un contenido tan informal, es muy fácil que nuestros futuros usuarios las puedan rellenar incluso sin nuestra supervision, lo que puede agilizar el proceso.

Luego, veremos como la mayoría de ellas se transforma en casos de uso

Modelo conceptual del sistema.

Hasta aquí, hemos ido hablando con el cliente y con los futuros usuarios del sistema; ahora ha llegado el momento en que nos sentemos con una hoja de papel delante, para empezarnos a hacer una idea de lo que será nuestro sistema.

En esta fase deberemos identificar los puntos mas importantes de la aplicación, no se trata de una visión detallada; se trata de ir revisando las historias de usuario, y/o los casos de uso para ir detectando los trabajos principales que ha de desarrollar nuestra aplicación.

Los “objetos” que vamos a identificar en este caso, no tienen porque ser los objetos de programación, en este paso se trata de identificar que es lo que hay; como productos, artículos, clientes, carro de compras,…Pasamos de estudiar el punto de vista del usuario, de los actores, para generalizar un poco y ver la aplicación en su conjunto.

Ahora nos queda identificarlos y mostrarlos en un Diagrama, a la vez que podemos señalar las interacciones entre ellos. Y todo ello, ahora si, pensando ya en un diseño orientado a objetos.

Pensemos en un caso de uso de Carrito de compra; en el escenario habremos escrito algo asi:

El cliente revisa los artículos que hay en el carrito de compra, y confirma las cantidades. Introduce los datos de pago y envío para procesar el pedido. El sistema valida el pago y genera un identificador de pedido, con el que el cliente podrá realizar el seguimiento de su pedido. El sistema envía una copia del pedido al cliente, vía correo electrónico, y registra la venta.

Si os fijáis, he ido subrayando todos los sustantivos que aparecen en el texto, no me preocupa la adecuación de la palabra, incluso aunque repita el mismo sustantivo, aunque no sea necesario.

Con los nombre subrayados podemos preparar una lista, y seguimos sin discutir su idoneidad.

cliente articulo carrito de compra
cantidades datos de pago datos de envío
pedido sistema identificador de pedido
correo electrónico venta

En esta lista, vamos a comprobar si aparecen nombre repetidos, y por ejemplo, vemos que “pedido” tiene el mismo significado que “venta”, por lo que borraremos venta.

Otra cosa que podemos ver es que alguno de los sustantivos puede que sean atributos mas que objetos, en lineas generales, todos los nombres acompañados de otro nombre, si uno de ellos es objeto, el otro será atributo; ese  es el caso de “identificado de pedido”, ya que “pedido” lo aceptamos como objeto. Lo mismo pasa con cantidades, ya que la escritura entera seria “cantidades del articulo”.

La nueva lista nos quedará:

cliente articulo carrito de compra
cantidades datos de pago datos de envío
pedido sistema identificador de pedido
correo electrónico venta

En esta tabla, también hemos tachado “sistema” ya que, aunque se podría considerar objeto, no lo tomaremos en cuenta ya que es el recurso director, y sobre el que no podemos planificar acciones.

 Ahora podemos preparar un sencillo Diagrama con esta información. Metemos cada uno de los nombre que hemos seleccionado en una caja.

A continuación, vamos revisando nuevamente nuestros casos de uso para ir estableciendo las relaciones que hay entre los distintos conceptos que hemos mostradoUML Modelo conceptual

En este paso solo se trata de mostrar/unir los objetos que están relacionados, sin ver el “como” ni el “porque”. De forma que unimos con lineas aquellos que están relacionados, hasta que nos queda algo semejante a la imagen superior.

Este diagrama podemos hacerlo mas completo si añadimos los verbos de las relaciones, por ejemplo:

UML-Detalle de relacionescomo “Crea”, “Usa”, “Contiene”, o las que nos definen la multiplicidad de los elementos como la que se indica en el carrito que esta explicando que (1) carrito contiene cualquier cantidad (*) de artículos.

En cualquier caso, debemos analizar si las relaciones son lo suficientemente importantes como para dibujarlas, teniendo en cuenta que solo es un diagrama conceptual, y que sigue teniendo como misión el facilitar la comunicación con el cliente, con los futuros usuarios, o con los miembros del equipo.

Otra misión del modelo conceptual, es el ayudarnos a:

Identificar responsabilidades

Dado que en el modelo conceptual no hay suficiente información como para empezar a programar, necesitamos pasar por la definición de las clases que utilizaremos, y para llegar a ello, va a ser muy útil el identificar responsabilidades.

Las responsabilidades serán lo que se va a transformar en métodos en nuestras futuras clases. Una forma de empezar, será tomar nuevamente el párrafo donde se describía el escenario y marcar los verbos que se utilizan.

El cliente revisa los artículos que hay en el carrito de compra, y confirma las cantidades. Introduce los datos de pago y envío para procesar el pedido. El sistema valida el pago y genera un identificador de pedido, con el que el cliente podrá realizar el seguimiento de su pedido. El sistema envía una copia del pedido al cliente, vía correo electrónico, y registra la venta.

En nuestro párrafo, he ido marcando esos verbos con el color azul a la vez que he desmarcado todos aquellos nombre que al final no decidimos que fueran objetos.

Con esto conseguimos una lista de responsabilidades para empezar.

Revisa artículos
Confirma cantidades
Introduce datos de pago y envío
procesar pedido
valida pago
genera identificador de pedido
realizar seguimiento
enviar copia por email
registrar venta

Ahora debemos depurarla y ademas encontrar al objeto al que se le asigna dicha responsabilidad, cosa, muchas veces, nada fácil. Para ello, debemos recordar que un objeto SIEMPRE ha de ser responsable de sus datos, y que en una orientación a objetos correcta, nadie puede ver ni alterar los datos del objeto si no es a través de comportamientos del mismo.

Eso significa que los atributos de un objeto SIEMPRE van a estar protegidos desde el exterior y cualquier interacción deberá realizarse a través de métodos. Ahora veremos que significa.

Cuando decimos que el cliente confirma las cantidades de artículos que hay en el carrito de compra, estamos mezclando tres objetos en la frase:

  • Cliente
  • Artículos
  • Carrito de compra

y una responsabilidad revisar las cantidades, osea poder cambiar las cantidades de los artículos. Si pensamos quien ha de guardar las cantidades de cada articulo que hay en el carro de compra de un cliente, vemos que el único sitio lógico es el el carrito de compra; luego si el dato se guarda en ese objeto, es responsabilidad del mismo el controlar los cambios.

Vamos a ver como distribuimos las responsabilidades:

Revisa artículos  La lista de artículos la deberemos guardar en el carrito, luego este comportamiento es para Carrito Compra
Confirma cantidades  Igual al caso anterior
Introduce datos de pago y envio  Se deberán crear dos comportamientos:

  • Guardar datos pago, para Pago
  • Guardar datos envío, para Envío
procesar pedido  Para Pedido….sin dudarlo, ¿verdad?
valida pago  Para el nodo de Pago
genera identificador de pedido  Para el nodo Pedido
realizar seguimiento  Mientras no tengamos mas objetos, también para Pedido
enviar copia por email  Deberemos crear un comportamiento:

  • Crear mail de pedido

que sera responsabilidad de pedido, y otro comportamiento

  • enviar mail

que sera de Correo Electrónico

registrar venta Asimilamos venta<–>pedido, por lo que este comportamiento, de momento será de pedido

El nuevo gráfico para nuestro modelo conceptual queda:

Modelo conceptual completoNuestro modelo, y solo de momento, puede quedar así. No es la única forma, pero creo que es una forma bastante valida.

Debemos tener mucho cuidado con “Quien inicia” y “Quien realiza”, fijaros que posiblemente sea el nodo Cliente el que inicie la mayoría de acciones, en cambio, no tiene responsabilidad sobre ninguna, ya que no las realiza. Algo semejante puede pasar con la acción “Registrar venta”, cuya responsabilidad se la hemos adjudicado al pedido, pero, que si tuviéramos un nodo Contabilidad y/o Estadísticas, depende del concepto “registro”, deberíamos pasar esa responsabilidad a ello…..

 

Acerca de Miguel Garcia

Programador, Desarrollador web, Formador en distintas areas de informatica y director de equipos multidisciplinares.
Esta entrada fue publicada en Orientacion a objetos y etiquetada , , . Guarda el enlace permanente.

5 respuestas a OOP(IV)-Diseñando la aplicacion. Mas recursos

  1. Said dijo:

    Muy buena publicación, me gustaría estar enterado cuando salgan las siguientes

    • Miguel dijo:

      Gracias, Said. Ya hay publicado el siguiente, de cualquier forma, tienes a la izquierda una cja para que dejes to correo electronico para suscribirte, o bien, en Facebook, puedes dar un “Me gusta” a la pagina de Recursos Formacion”, o añadirme a tus circulos de Google Plus….

      Lo que mas te guste

  2. Luis Orozco dijo:

    Buena explicación!

  3. Pingback: OOP(V) - Diseñando la aplicación. EL diagrama de clasesRecursos para formacion

Deja un comentario