Arquitectura de Software: Componentes, Calidad y Diseño

Arquitectura de Software: Componentes, su Relación entre Ellos y su Ambiente

Componentes: Corresponde a una parte del sistema, la cual ofrece un servicio definido y es capaz de comunicarse con otros componentes.

Servicio: Cumple una funcionalidad específica, es independiente y se comunica con otros servicios.

Interfaz: Puntos de acceso de un componente en donde recibe datos o entrega datos.

Requerimientos No Funcionales / Parámetros de Calidad

1. Performance

Eficiencia con la que el sistema realiza sus tareas, se mide con throughput, tiempo de respuesta, plazos de tiempo que tarda un proceso.

2. Escalabilidad

Sistema capaz de adecuarse dinámicamente a la carga (SD), la carga se mide en transacciones por segundo (tps), conexiones simultáneas, volumen de datos (cantidad de datos que se manejan en la base de datos), despliegue (qué tan fácil es distribuir los procesos), escalabilidad vertical (hardware) y horizontal (más dispositivos).

3. Mantenibilidad

Qué tan fácil es modificar una pieza o función del sistema. Esta la modificabilidad (coste de realizar cambios en el sistema y que este se adapte al cambio) y escalabilidad de requerimientos (capaz de admitir nuevos RF).

4. Seguridad

Resistir ataques, esta en usuarios –> autenticación (validar acceso a una plataforma) y autorización (permite el uso de componentes por rol) y en los datos –> encriptación (cifrar), integridad (no malversación de datos) y no repudio (asegurar que la comunicación llegó al destino correcto).

5. Confiabilidad

Confiar que el sistema esté operable. Esta disponibilidad (sistema preparado para recibir peticiones y poder responder), recuperabilidad (en caso de falla, volver a ser funcional), regla 99999 (tiempo ideal esperado de disponibilidad), gasto (gasto de falla probabilístico, cambio de prevención de falla es seguro).

6. Integrabilidad

Capacidad de agregar componentes externos. Esta agregación (implementar componentes de terceros), interoperabilidad (funcionamiento correcto entre distintos sistemas como Docker) y APIs (interfaz de comunicación estándar)

7. Portabilidad

No desarrollo para un solo entorno, desarrollo para múltiples de una vez.

8. Verificabilidad

Capacidad de auto chequearse.

9. Soportabilidad

Diagnóstico y corrección de incidencias, incluir ayuda al proceso de re-corrección.

Diseño de Software

1. Analizar el Contexto

Consiste en requerimientos funcionales (qué debe hacer el sistema), requerimientos no funcionales (atributos de calidad), ambiente operacional (hardware y software), restricciones técnicas, operativas o de negocio.

2. Estructuración

Identificar componentes y sus relaciones. Utiliza un diagrama de bloques simple que muestra la estructura indicando el flujo de datos entre los componentes. Muestra además las interfaces que provee el sistema.

3. Modelo de Control

Evaluar el comportamiento que tendrán los componentes al realizar sus tareas.

4. Descomposición de Módulos

Se realiza un diseño detallado del proyecto.

Análisis de Párrafo

El objetivo del requerimiento funcional de mantenibilidad es mantener operativo el sistema el mayor tiempo posible.

R:// La mantenibilidad se refiere a la facilidad con la que un sistema puede ser modificado para corregir fallos, mejorar su rendimiento o adaptarse a un cambio de entorno. Lo que se describe es más adecuado para la confiabilidad, que se enfoca en la capacidad del sistema para funcionar sin fallos bajo condiciones especificadas durante un periodo de tiempo determinado.

El óptimo a alcanzar es que opere al 99,999% del tiempo, regla conocida como la de los cinco nueves.

R:// Esta afirmación es verdadera. La regla de los cinco nueves es un estándar de la industria para sistemas de alta disponibilidad, indicando que el sistema debe estar operativo el 99,999% del tiempo, lo que equivale a aproximadamente 5.26 minutos de tiempo de inactividad no planificado por año.

Para lograr los cinco nueves, un sistema debe diseñarse con componentes redundantes que puedan tomar el control de la operación del sistema en el caso que uno de ellos falle.

R:// Esta afirmación es verdadera. La redundancia de componentes es una estrategia clave para lograr altos niveles de disponibilidad y confiabilidad, permitiendo que el sistema continúe funcionando incluso si parte de sus componentes fallan.

Si esto ocurre, utilizando los procesos definidos al incluir el requerimiento de mantenibilidad se podrá corregir el error y restaurar el sistema a su estado normal del procesamiento.

R:// Falso, la soportabilidad se refiere a la capacidad de un sistema para ser soportado, incluyendo actividades de mantenimiento y corrección de errores para restaurar la funcionalidad.

Preguntas Teóricas

Mencione y explique 3 factores utilizados para medir la escalabilidad de un sistema de software.

R// – Carga: Cantidad de transacciones por segundo que puede soportar el sistema. – Conexiones simultáneas: Número máximo de usuarios o dispositivos que pueden interactuar con el sistema al mismo tiempo. – Volumen de datos: Capacidad del sistema para manejar grandes volúmenes de datos.

Describa 4 competencias que debe tener el arquitecto de software.

R// – Administración del riesgo. – Excelentes habilidades de diseño. – Interfaz entre el cliente y el equipo técnico. – Puente de comunicación entre los equipos de desarrollo. – Promoción de buenas prácticas de desarrollo – Diseño – Conocimiento de las tecnologías.

Explique cuáles factores son utilizados para medir la escalabilidad de un sistema de software.

R// – Carga: Cantidad de transacciones por segundo que puede soportar el sistema. – Conexiones simultáneas – Volumen de datos

Describa las diferencias que tienen entre sí los siguientes requerimientos no funcionales: Mantenibilidad/Soportabilidad/Verificabilidad

R// – Mantenibilidad: Se refiere a la facilidad con la que un sistema puede ser modificado. – Soportabilidad: Está relacionada con la facilidad con la que un sistema puede ser diagnosticado, reparado, o configurado. – Verificabilidad: Hace referencia a la facilidad con la que se pueden realizar pruebas en el sistema para verificar que cumple con los requisitos especificados.

Explique qué se debe considerar al especificar una arquitectura de un sistema.

R// Al especificar una arquitectura se deben considerar los siguientes factores: – Requerimientos funcionales: Que es lo que debe hacer el sistema. – Requerimientos no funcionales: Que atributos de calidad son requeridos. – Ambiente operacional: Dónde se utilizará el sistema (Hardware y Software involucrados). – Restricciones: Las restricciones pueden ser tecnológicas, temporales, de personal, etc.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.