Modelo de datos y navegacion de una aplicacion de tareas

Translator
Translator
Translator
Translator

 



El modelo de datos de la aplicación debe definir las entidades y relaciones que se utilizarán para almacenar los datos de las tareas, los usuarios y los proyectos. En este caso, las entidades básicas que necesitamos son las siguientes:

  • Tarea: Representa una tarea individual.
  • Usuario: Representa un usuario de la aplicación.
  • Proyecto: Representa un proyecto que puede tener varias tareas.

Las relaciones entre estas entidades pueden ser las siguientes:

  • **Tarea **pertenece a Usuario: Una tarea pertenece a un usuario.
  • **Tarea **está en Proyecto: Una tarea puede estar en un proyecto.

Modelo de navegación

El modelo de navegación de la aplicación debe definir la forma en que los usuarios navegarán por la aplicación. En este caso, podemos definir los siguientes elementos de navegación:

  • Página de inicio: La página de inicio de la aplicación debe mostrar una lista de las tareas pendientes del usuario.
  • Página de creación de tareas: La página de creación de tareas debe permitir a los usuarios crear nuevas tareas.
  • Página de edición de tareas: La página de edición de tareas debe permitir a los usuarios editar tareas existentes.
  • Página de listas de tareas: La página de listas de tareas debe permitir a los usuarios ver y gestionar sus listas de tareas.
  • Página de proyectos: La página de proyectos debe permitir a los usuarios ver y gestionar sus proyectos.

a continuación se muestra unos ejemplos de los prototipos de la aplicación ademas de que al darle clic a la imagen abrirá una pestaña nueva en Figma para ver los prototipos mas detalladamente enlace para poder verlos mas detalladamente


 

Comentarios

Publicar un comentario

Entradas populares de este blog

Patron de diseño estructural "decorator"

Imagen
  **Patrón de diseño estructural: Decorador** El patrón de diseño Decorador es un patrón estructural que permite añadir responsabilidades adicionales a un objeto de forma dinámica. Esto se consigue envolviendo el objeto original en un objeto decorador que proporciona la funcionalidad adicional. **Problema que resuelve** El patrón Decorador resuelve el problema de añadir funcionalidades adicionales a un objeto de forma dinámica. Esto es útil en situaciones en las que: * No es posible o práctico modificar el código del objeto original. * Se desea añadir funcionalidades adicionales a un objeto sin tener que crear subclases. * Se desea añadir funcionalidades adicionales a un objeto de forma incremental. **Solución** El patrón Decorador proporciona la siguiente solución: * Define una interfaz para los objetos que pueden tener responsabilidades añadidas. * Define un objeto al cual se le pueden agregar responsabilidades adicionales. * Define una clase decoradora abstracta que proporciona ...
Leer más

Arquitectura Monolitica

Imagen
 En los últimos tiempos, hemos escuchado muchas opiniones sobre cómo es conveniente diseñar nuestras aplicaciones, desde el punto de vista de su arquitectura en la ejecución.  Históricamente las aplicaciones eran monolíticas (una aplicación que se instalaba en una computadora y hacia todo lo que necesitaba) y en forma más recientes se esta optando por hacer aplicaciones distribuidas en varias computadoras, dividas en servicios independientes (algunos lo llaman microservicios). Voy a hacer una comparación sencilla de una arquitectura monolítica y una arquitectura de microservicios, viendo sus beneficios y sus desventajas.  Beneficios de una arquitectura monolítica Sencilla de desarrollar.  No hay que pensar demasiado donde desarrollo una nueva funcionalidad. Todo se programa en la misma KB. Sencilla de instalar.  Se instala todo junto en una misma instalación. Sencilla de escalar.  Si necesito mas potencia, puedo replicar una máquina...
Leer más