GA8-220501096-AA1-EV02 módulos integrados
David Santiago Roa Riatiga
Servicio Nacional De Aprendizaje
Análisis Y Desarrollo de
Software2721422
Bogotá D.C
Tercer trimestre del año
2024
INTRODUCCION
Desarrollar proyectos web a partir de la integración de módulos desarrollados por separado
es un enfoque común en proyectos colaborativos o de gran escala. Este proceso se basa en
una arquitectura modular y sigue pasos claros para asegurar que los módulos funcionen de
manera conjunta sin conflictos. A continuación, se describe el proceso:
1. Planificación y Diseño del Proyecto
• Definición de Requisitos: Divide las funcionalidades en módulos independientes
con interfaces claramente definidas.
• Diseño de Arquitectura: Decide cómo los módulos interactuarán entre sí. Por
ejemplo, puedes usar APIs REST, GraphQL o eventos para la comunicación.
• Documentación de Interfaces: Detalla los contratos (inputs y outputs) que cada
módulo debe cumplir.
2. Desarrollo de Módulos
• Trabajo Independiente: Los equipos o desarrolladores trabajan en sus módulos de
forma aislada. Utilizan datos de prueba y las interfaces definidas.
• Pruebas Unitarias: Cada módulo debe incluir pruebas unitarias para garantizar que
funcione correctamente de manera independiente.
3. Configuración de un Repositorio Central
• Usa herramientas como Git y un sistema de ramas para manejar el código.
• Cada módulo puede ser desarrollado en un repositorio independiente o en un
monorepo.
4. Integración Continua (CI)
• Implementa pipelines de CI/CD para automatizar la integración y las pruebas
cuando se combinan los módulos.
• Utiliza herramientas como Jenkins, GitHub Actions o GitLab CI para verificar que
los cambios en los módulos no rompan la integración.
5. Pruebas de Integración
• Conexión de Módulos: Une los módulos y realiza pruebas para asegurar que los
datos fluyen correctamente entre ellos.
• Gestión de Errores: Identifica y soluciona problemas de compatibilidad o
malentendidos en las interfaces.
6. Despliegue
• Ambientes de Prueba: Primero despliega el sistema integrado en un entorno de
staging para realizar pruebas completas.
• Ambientes de Producción: Después de las pruebas exitosas, lanza el proyecto
completo en producción.
7. Mantenimiento
• Actualizaciones Modulares: Cualquier cambio o mejora en un módulo debe
probarse en aislamiento y luego integrarse nuevamente.
• Monitoreo: Implementa herramientas de monitoreo para detectar problemas entre
los módulos después del despliegue.
Integracion modulos:
Modulo de home:
Modulo de diseños:
Modulo de Registro:
Modulo de Obtención de datos:
Modulos desplegados:
Home:
Diseños:
Inicio de Sesion:
Obtencion de datos:
Diagrama de Clases
Un diagrama de clases es una representación gráfica que muestra la estructura estática de
un sistema orientado a objetos. Incluye las clases, que son plantillas para crear objetos,
junto con sus atributos (propiedades o datos) y métodos (funciones o comportamientos).
También describe las relaciones entre las clases, como asociaciones, generalizaciones,
dependencias o composiciones. Este diagrama es esencial para comprender y diseñar los
aspectos estáticos del sistema, ya que permite visualizar cómo se estructuran los objetos y
cómo interactúan entre sí.
Diagrama de Paquetes
Un diagrama de paquetes organiza los elementos de un sistema en grupos lógicos
llamados paquetes. Cada paquete agrupa clases, interfaces, u otros elementos que están
relacionados entre sí. Este diagrama es útil para gestionar la complejidad de sistemas
grandes, ya que permite dividirlos en subsistemas o capas, facilitando la navegación y el
entendimiento del diseño. Además, muestra las dependencias entre los paquetes, lo que
ayuda a identificar posibles problemas de acoplamiento o a planificar la modularidad del
sistema.
Diagrama de Componentes
El diagrama de componentes representa los componentes físicos de un sistema, como
módulos de software, bibliotecas, archivos de configuración o ejecutables. Estos
componentes son unidades autónomas que implementan una funcionalidad específica del
sistema. El diagrama también muestra las interfaces que los componentes exponen para
interactuar con otros y las dependencias entre ellos. Este tipo de diagrama es crucial para
diseñar la arquitectura del sistema, especialmente durante la etapa de implementación, ya
que describe cómo los distintos elementos del software se ensamblan para formar un
sistema funcional.
Patrones de Diseño
Los patrones de diseño son soluciones reutilizables a problemas comunes que surgen
durante el desarrollo de software. Son enfoques probados y optimizados para resolver
problemas recurrentes en el diseño de sistemas, proporcionando un marco estandarizado
que mejora la mantenibilidad, escalabilidad y flexibilidad del software. Los patrones de
diseño no son implementaciones específicas, sino abstracciones que guían a los
desarrolladores para construir sistemas más estructurados y fáciles de modificar.
Se dividen en tres grandes categorías:
1. Patrones Creacionales: Ayudan a gestionar la creación de objetos, permitiendo que
el sistema sea independiente de cómo se crean, componen y representan los objetos.
Ejemplos: Singleton, Factory Method, Abstract Factory.
2. Patrones Estructurales: Se centran en cómo los componentes del sistema se
organizan y se relacionan entre sí. Ejemplos: Adapter, Composite, Decorator.
3. Patrones de Comportamiento: Describen cómo los objetos interactúan entre sí y
cómo se distribuyen las responsabilidades dentro del sistema. Ejemplos: Observer,
Strategy, Command.
¿Cómo se usan y para qué se usan los patrones de diseño?
Los patrones de diseño se usan para resolver problemas específicos que surgen durante el
desarrollo del software de manera eficiente y estandarizada. Ayudan a los desarrolladores a:
• Mejorar la comunicación: Al ser soluciones conocidas, los patrones permiten que
los desarrolladores se comuniquen de manera más efectiva, usando un lenguaje
común.
• Facilitar la reutilización: Los patrones permiten que se implementen soluciones
probadas y probadas, lo que reduce el esfuerzo de reinvención y mejora la calidad
del software.
• Asegurar la escalabilidad y mantenibilidad: Al proporcionar una estructura sólida
y modular, los patrones de diseño permiten que el sistema sea más fácil de mantener
y escalar con el tiempo.
• Optimizar la resolución de problemas complejos: Facilitan la resolución de
problemas complejos mediante el uso de soluciones estructuradas y bien definidas.
Patrón MVC (Modelo-Vista-Controlador)
El patrón MVC es uno de los patrones de diseño más conocidos, especialmente utilizado
en el desarrollo de aplicaciones web. Este patrón separa la lógica de la aplicación en tres
componentes principales:
1. Modelo (Model): Representa los datos y la lógica de negocio de la aplicación. El
modelo es responsable de recuperar, almacenar y procesar los datos, sin preocuparse
por la forma en que esos datos se presentan al usuario.
2. Vista (View): Es la interfaz de usuario (UI) que presenta los datos. La vista recibe
la información del modelo y la muestra al usuario, pero no realiza ningún tipo de
procesamiento de los datos.
3. Controlador (Controller): Actúa como intermediario entre el modelo y la vista.
Recibe las entradas del usuario desde la vista, las procesa (a menudo actualizando el
modelo), y luego actualiza la vista.
¿Cómo funciona el patrón MVC y para qué se utiliza?
El MVC permite la separación de responsabilidades, lo que facilita la mantenibilidad,
escalabilidad y flexibilidad del sistema. Cada componente tiene una tarea clara y no
depende directamente de los demás, lo que hace que los cambios en una parte del sistema
no afecten drásticamente a las otras partes.
Usos del MVC:
• Aplicaciones Web: Es uno de los patrones más utilizados en el desarrollo web,
donde el modelo puede ser gestionado por una base de datos, la vista se encarga de
representar las interfaces de usuario, y el controlador maneja las interacciones.
• Desarrollo de Software: Se usa en aplicaciones de escritorio y móviles para
estructurar el código de manera eficiente y ordenada.
Ventajas de MVC:
• Mantenibilidad: Dado que el modelo, la vista y el controlador están separados, es
fácil realizar cambios en una parte del sistema sin afectar otras áreas.
• Escalabilidad: Al estar bien estructurado, es más fácil agregar nuevas
características o modificar las existentes.
• Reusabilidad: Los componentes del sistema pueden ser reutilizados en otros
contextos con menos esfuerzo.
Este patrón es muy útil en aplicaciones donde la interfaz de usuario y la lógica de negocio
son complejas, ya que permite mantener un código limpio y organizado.
¿Qué son las pruebas unitarias?
Las pruebas unitarias son una técnica de prueba de software en la que se verifican de
manera aislada las unidades o componentes más pequeños de un sistema, generalmente una
función o un método. El objetivo es asegurarse de que cada unidad de código se comporta
como se espera bajo diferentes condiciones y entradas.
Cada prueba unitaria se enfoca en una porción mínima de la lógica del programa y se lleva
a cabo de forma independiente, sin depender de otros componentes del sistema (por
ejemplo, bases de datos, interfaces de usuario o servicios externos). Para ello, se utilizan
datos simulados (mocking o stubbing) que permiten verificar la funcionalidad de la unidad
de código sin ejecutar toda la aplicación.
¿Cómo se usan las pruebas unitarias?
Las pruebas unitarias se utilizan de la siguiente manera:
1. Escribir Pruebas: El desarrollador escribe una prueba para una función o método
específico, definiendo las entradas y las salidas esperadas. Las pruebas deben ser lo
más simples posibles y comprobar un único comportamiento o función.
2. Ejecutar las Pruebas: Se ejecutan todas las pruebas unitarias para comprobar que
el código funciona correctamente. Existen herramientas y marcos de trabajo como
JUnit (Java), Jest (JavaScript), Mocha ([Link]) o pytest (Python) que facilitan la
automatización de las pruebas unitarias.
3. Aislar Dependencias: Si la unidad que se está probando depende de otros módulos
o servicios, se usan mocks o stubs para simular su comportamiento y evitar la
necesidad de ejecutar el sistema completo.
4. Verificar Resultados: Después de ejecutar la prueba, se compara el resultado
obtenido con el resultado esperado. Si coinciden, la prueba es exitosa; de lo
contrario, el desarrollador puede corregir el error y volver a probar.
5. Automatización: Las pruebas unitarias se pueden integrar en el proceso de
Integración Continua (CI), lo que permite ejecutarlas de manera automática cada
vez que se realicen cambios en el código.
¿Por qué son importantes las pruebas unitarias?
Las pruebas unitarias son cruciales por varias razones:
1. Detección Temprana de Errores: Permiten identificar y corregir errores en fases
tempranas del desarrollo, antes de que el código sea integrado con otros módulos o
se despliegue en producción.
2. Facilitan el Refactorizado: El código puede ser modificado o refactorizado con
mayor confianza. Al tener pruebas unitarias, los desarrolladores pueden verificar
rápidamente que los cambios no rompen funcionalidades existentes.
3. Mejora la Calidad del Código: Al escribir pruebas unitarias, los desarrolladores se
ven obligados a diseñar un código más modular y con funciones claramente
definidas, lo que mejora la calidad y mantenibilidad del sistema.
4. Documentación Viva: Las pruebas unitarias también sirven como una
documentación viva del comportamiento esperado de la aplicación, ya que
muestran cómo debe funcionar cada parte del sistema.
5. Reducción de Costos a Largo Plazo: Aunque escribir pruebas unitarias requiere
tiempo al principio, a largo plazo ahorran tiempo y recursos al reducir el número de
defectos que deben corregirse en fases posteriores del desarrollo y al evitar fallos en
producción.
6. Facilitan el Trabajo en Equipo: En proyectos colaborativos, las pruebas unitarias
aseguran que los diferentes desarrolladores puedan trabajar en paralelo sin temor a
que los cambios realizados rompan funcionalidades existentes en otras partes del
sistema.
Buenas Prácticas en las Pruebas Unitarias
1. Independencia: Cada prueba debe ser independiente, es decir, el resultado de una
prueba no debe depender de las otras. Esto ayuda a evitar efectos secundarios y
facilita la depuración.
2. Claridad: Las pruebas deben ser fáciles de leer y entender, por lo que deben tener
nombres descriptivos y reflejar el comportamiento esperado de la unidad probada.
3. Cobertura: Idealmente, las pruebas unitarias deben cubrir la mayor parte del
código posible, incluyendo casos de borde y escenarios poco frecuentes.
4. Rápidas y Repetibles: Las pruebas deben ser rápidas de ejecutar y repetibles en
cualquier entorno para que puedan ejecutarse frecuentemente durante el proceso de
desarrollo.
5. No Deben Afectar el Entorno: Las pruebas unitarias no deben depender de
recursos externos, como bases de datos o servicios en la nube, a menos que sea
estrictamente necesario. Se deben utilizar mocks o stubs para simular esos recursos.
Link del proyecto:
[Link]
Link de repositorios:
Front end:
[Link]
Backend:
[Link]
