Definitivamente, aquí están los casos de uso

Por fin, por fin, por fin.

Aquí están, recién salidos del horno, como el buen bollo, los casos de uso.

Hemos hablado de la teoría de que es un caso de uso.

Hemos hablado de que es un CRUD.

Hemos hablado de las fases de desarrollo de software (análisis, diseño, implementación, testeo y despliegue).

Hemos visto que aún estamos en fase de análisis, pero también me he calentado y he caído en la fase de implementación al hablar de tecnologías.

Y hoy, por fin, después de muchos días de darte la tabara, te comparto los casos de uso.

Si no lo he hecho antes es por pereza. Simple.

Bueno, aquí te tiro el diagrama y ya te espabilas tú para entenderlo.

“Uf Josué, son las 9 de la mañana y no estoy yo como para pensar. Necesito al menos 2 cafés más.”

Vale, vale. Te cuento.

Antes, recuperemos el diagrama del modelo del dominio (ese diagrama en el que definimos las palabras clave para entender el problema y la solución sin hablar de tecnologías).

Con el modelo del dominio en mano, te cuento como van los casos de uso. Por puntos:

1. Tenemos un único actor, que es el usuario y el único que interactua con nuestro sistema buscando un resultado observable de interés.
2. Después puedes ver que los casos de uso (el texto escrito dentro de un óvalo) están agrupados en paquetes (las cajas más grandes).
3. Los paquetes son (con sus casos de uso):
   1. Auth:
      1. Register user: el usuario debe de poder registrarse en la aplicación. Un usuario ya registrado no se puede registrar dos veces.
      2. Login: un usuario registrado debe de autenticarse en la aplicación.
   2. JobApplication
      1. Add job application: un usuario logeado puede añadir una aplicación de trabajo
      2. View job application: un usuario logeado puede ver una aplicación de trabajo existente
      3. Edit job application information: un usuario logeado puede editar la información de una aplicación de trabajo existente.
      4. Delete job application: un usuario logeado puede eliminar una aplicación de trabajo existente.
      5. Advance on job application: un usuario logeado puedo avanzar en el proceso de una aplicación de trabajo existente.
      6. Close job application: un usuario logeado puede cerrar una aplicación de trabajo existente. útil para cuando el proceso no se ha podido finalizar por X razones.
   3. Document
      1. Add document to job application: un usuario logeado debe de poder añadir un documento a una aplicación de trabajo existente.
      2. View document from job application: un usuario logeado debe de poder ver el documento existente de una aplicación de trabajo existente.
      3. Update document from job application: un usuario logeado debe de poder actualizar el documento existente de una aplicación de trabajo existente.
      4. Delete document from job application: un usuario logeado debe de poder eliminar el documento existente de una aplicación de trabajo existente.
   4. Contact
      1. Add contact: un usuario logeado debe de poder añadir un contacto a su cuenta
      2. Add/assign contact to job application: un usuario logeado debe de poder añadir o asignar un contacto existente a una aplicación de trabajo existente.
      3. Edit contact: un usuario logeado debe de poder editar un contacto existente.
      4. View contact: un usuario logeado debe de poder ver un contacto existente.
      5. Delete contact: un usuario logeado debe de poder eliminar un contacto existente.
   5. Note
      1. Add note to job application: un usuario logeado debe de poder añadir una nota a una aplicación de trabajo existente.
      2. Edit note from job application: un usuario logeado debe de poder editar una nota existente en aplicación de trabajo existente.
      3. View note from job application: un usuario logeado debe de poder ver una nota existente en aplicación de trabajo existente.
      4. Delete note from job application: un usuario logeado debe de poder eliminar una nota existente en aplicación de trabajo existente.

Esos son todos los casos de uso.

Ahora quiero que te fijes en una cosa.

Si te fijas, hay un patrón en todos los paquetes: puedo añadir (sinónimo de crear), ver, editar o eliminar. A veces están las 4 acciones, a veces falta alguna.

Si recuerdas, esas 4 acciones se simplifican en el concepto CRUD (Create, Retrieve, Update, Delete).

Y es que como te decía, la mayoría de aplicaciones en las que puedes crear, ver, actualizar y eliminar la información, se simplifican con CRUDs diversos sobre cada colección de datos.

Y en el caso de trabajo.io, la gracia está en relacionar diferentes colecciones de datos (ojo que esto es importante para cuando lleguemos a la fase de implementación y elegir base de datos).

Otra cosa, antes de despedirme.

En esta mail te he compartido los casos de uso de dos formas diferentes.

La primera es con el diagrama de casos de uso y la segunda en formato textual.

Lo habitual es que se haga en una de las 2 formas, no las dos, en una.

Eso se merece, por lo menos, que compartes este mail.

Nada más,

Feliz miércoles,

Josué.

PD1: si tienes algo que aportar, no te cortes.

PD2: si te gusta la que lees, comparte que es gratis.