Arquitectura de Software: Principios, Patrones y Aplicaciones - Prof. Caza, Esquemas y mapas conceptuales de Arquitectura

¡Descarga Arquitectura de Software: Principios, Patrones y Aplicaciones - Prof. Caza y más Esquemas y mapas conceptuales en PDF de Arquitectura solo en Docsity!

ARQUITECTURA DE

SOFTWARE

Manual del Estudiante 2025 - 2025

Ing. Sandra Navarrete

Ing. Sandra Navarrete

UNIDAD NO 1: LA ARQUITECTURA DE SOFTWARE

En esta unidad el estudiante comprende las metodologías y procesos de desarrollo de software, siguiendo estándares de la industria. Analiza, diseña e implementa soluciones eficientes, considerando requisitos funcionales y no funcionales. Además, domina los atributos de calidad del software (como escalabilidad, mantenibilidad y seguridad) y aplica conceptos fundamentales para el diseño de arquitecturas de software robustas y adaptables a diferentes contextos.

1.1 DEFINICIÓN

OBJETIVOS DEL MODULO

Este módulo busca que el estudiante desarrolle las siguientes habilidades:

1. Comprender los fundamentos de la arquitectura de software, su importancia en el desarrollo de sistemas y su impacto en la calidad del producto final.
2. Analizar y aplicar los procesos estándar de desarrollo de software, desde la planificación hasta la implementación.

1.1.1 ¿Qué es la Arquitectura De Software?

Al igual que el plano arquitectónico de un edificio, la arquitectura de software es fundamental para desarrollar sistemas de software exitosos. Puede describirse brevemente como la estructura fundamental de un sistema de software que define los componentes, sus interacciones y los principios generales que guían su evolución. Este plano asegura que el software cumpla con las especificaciones técnicas y los objetivos empresariales, manteniéndose flexible, seguro y eficiente con el tiempo. La arquitectura de software es un aspecto crucial e indispensable del desarrollo de software. Sin ella, los proyectos pueden volverse desorganizados y caóticos rápidamente, lo que lleva a costosos errores y plazos incumplidos. Por lo tanto, si quieres que tus

Ing. Sandra Navarrete proyectos de desarrollo de software tengan éxito, presta atención al papel crítico de la arquitectura de software. La importancia de la arquitectura de software radica en su capacidad para sentar las bases de un sistema robusto y eficiente. Una arquitectura bien diseñada previene problemas como la duda técnica, los cuellos de botella en el rendimiento o las costosas reestructuraciones futuras. Finalmente, la arquitectura de software sirve como lenguaje común entre los distintos actores involucrados en el proyecto del desarrollo de un sistema, desde desarrolladores hasta gerentes de la empresa que utilizarán el sistema. En esencia, la arquitectura de software es el arte de tomar decisiones de diseño que equilibran complejidad técnica, costos, tiempo y objetivos estratégicos , un concepto que trasciende la codificación para convertirse en un pilar de sistemas sostenibles. Ahora que hemos establecido una comprensión sólida de la arquitectura de software y su importancia, avanzaremos a las etapas del ciclo de desarrollo de software y las complejidades del diseño de software.

1.1.2 Proceso De Desarrollo De Software

El desarrollo de software es un proceso sistemático y estructurado que transforma requisitos y necesidades de usuarios en un producto funcional y de calidad. Este proceso sigue un conjunto de etapas interrelacionadas, conocidas como ciclo de vida del desarrollo del software , que guían a los equipos desde la concepción inicial hasta el mantenimiento final. Aunque existen diversas metodologías de desarrollo de software (cascada, ágil, iterativo), todas comparten fases fundamentales que aseguran un desarrollo controlado y eficiente. La primera etapa es el análisis de requisitos , donde se recopilan y documentan las necesidades del cliente y los usuarios finales. En esta fase, ingenieros de software y analistas trabajan estrechamente con los usuarios para definir tanto los requisitos funcionales (qué debe hacer el sistema) como los no funcionales (rendimiento, seguridad, usabilidad). Herramientas como diagramas de casos de uso o historias de usuario (en metodologías ágiles) ayudan a formalizar estos requerimientos.

Ing. Sandra Navarrete La arquitectura de software se ocupa más de la estructura de alto nivel del software; por otro lado, el diseño de software profundiza en los aspectos "micro" , detallando los pormenores de la implementación del sistema. Se preocupa por el comportamiento y la estructura de los componentes de software, como módulos, objetos, clases y sus interacciones. El diseño toma las decisiones arquitectónicas y las traduce en instrucciones detalladas para resolver problemas específicos.

1.1.4 Comprendiendo El Rol Del Arquitecto De Software

El arquitecto de software desempeña un rol crítico en proyectos de software complejos mediante el diseño de estructuras de sistema, la toma de decisiones tecnológicas cruciales, el establecimiento de estándares de codificación y la colaboración con las partes interesadas (stakeholders). Lideran equipos técnicos, gestionan riesgos, aseguran la calidad y el cumplimiento (compliance), e impulsan la mejora continua. Este rol multifacético demanda experiencia técnica, conocimiento actualizado de nuevas tendencias y tecnologías, liderazgo y habilidades de comunicación efectivas para entregar con éxito sistemas de software complejos.

1.1.5 El Impacto De La Arquitectura De Software En Los Últimos

Tiempos

En la actual era digital de rápida evolución, la arquitectura de software sigue siendo vital, con arquitectos dedicados e incluso un equipo de arquitectura de software en organizaciones más grandes, y enfoques colaborativos en equipos más pequeños o start- ups donde los ingenieros de software asumen el rol de arquitecto. Si bien los roles dedicados a la arquitectura de software siguen siendo esenciales, la forma en que se aborda e implementa la arquitectura de software puede variar ampliamente dependiendo del contexto y la cultura organizacional. La clave es asegurar que las decisiones arquitectónicas estén bien fundamentadas, alineadas con los objetivos del negocio y continuamente refinadas a través de la colaboración y la retroalimentación. Ahora que hemos comprendido las diferencias entre la arquitectura y el diseño de software, el papel del arquitecto de software y la importancia de la arquitectura de software en el panorama digital actual, exploremos las metodologías de desarrollo de software.

Ing. Sandra Navarrete

1.2 METODOLOGÍAS DE DESARROLLO DE SOFTWARE

OBJETIVOS DEL MODULO

Este módulo tiene como objetivo proporcionar una visión general clara y estructurada de las metodologías de desarrollo de software más relevantes utilizadas en la industria. Se busca que el estudiante desarrolle las siguientes habilidades:

1. Comprenda los principios, características, ventajas y desventajas de cada metodología, así como los contextos idóneos para su aplicación. 2. Facilitar la toma de decisiones informadas para la selección o adaptación de una metodología acorde a las necesidades específicas de un proyecto, considerando factores como complejidad, tamaño del equipo, requisitos del cliente y flexibilidad requerida. El desarrollo de software no solo depende de habilidades técnicas, sino también de cómo se organiza el trabajo. Las metodologías de desarrollo son marcos de trabajo que definen procesos, roles y prácticas para gestionar proyectos de manera eficiente. La evolución de las metodologías de desarrollo de software ha dado lugar principalmente a dos grandes enfoques: los tradicionales (o predictivos) y los ágiles (adaptativos). Esta clasificación refleja no solo diferencias en procesos y herramientas, sino también en filosofías de gestión y respuesta a la incertidumbre inherente al desarrollo de software. Las metodologías de desarrollo de software no deben interpretarse como chalecos de fuerza rígidos e inmutables, sino como marcos de referencia flexibles que pueden y deben adaptarse a la realidad particular de cada proyecto. Su verdadero valor reside en la capacidad de ajustarse a variables como el tamaño del equipo, la complejidad técnica, los plazos de entrega, la claridad de los requisitos y la cultura organizacional. La adopción

Ing. Sandra Navarrete

1. Análisis de Requisitos La primera fase se centra en comprender y documentar exhaustivamente lo que el sistema debe hacer. Los analistas trabajan estrechamente con los usuarios para capturar tanto los requisitos funcionales (qué funciones debe realizar el sistema) como los no funcionales (rendimiento, seguridad, usabilidad). El resultado es un Documento de Especificación de Requisitos Software (SRS) que sirve como contrato técnico y guía para todo el proyecto. Esta documentación detallada es crucial, ya que cualquier omisión o error aquí se propagará a las fases posteriores. 2. Diseño del Sistema Con los requisitos claramente definidos, los arquitectos y diseñadores crean el plano técnico del sistema. Esta fase se divide típicamente en diseño arquitectónico (estructura general del sistema, componentes principales y sus relaciones) y diseño detallado (especificación de algoritmos, estructuras de datos e interfaces). Se producen diagramas UML, modelos de bases de datos y documentación técnica que los programadores usarán como guía exacta para la implementación. La atención al detalle en esta fase es fundamental para evitar costosas refactorizaciones posteriores. 3. Implementación (Codificación) Los desarrolladores traducen las especificaciones de diseño a código fuente, siguiendo rigurosamente los documentos generados en las fases anteriores. Esta fase suele organizarse en módulos o componentes que se implementan por separado. Se enfatiza la adherencia a estándares de codificación y prácticas como el control de versiones. La comunicación entre equipos es limitada, ya que se espera que todos los aspectos del sistema hayan sido definidos y documentados previamente. 4. Pruebas Una vez completada la implementación, el sistema entra en una fase de pruebas rigurosas y sistemáticas. Los equipos de calidad verifican que el software cumpla con todos los requisitos especificados inicialmente, ejecutando pruebas unitarias, de integración, de sistema y de aceptación. Cualquier discrepancia entre el comportamiento esperado (definido en el SRS) y el observado genera reportes de errores que deben ser corregidos antes de proceder a la siguiente fase. 5. Despliegue y Mantenimiento El software terminado se instala en el entorno de producción y se entrega a los usuarios finales. La fase de mantenimiento aborda problemas no detectados durante las pruebas (mantenimiento correctivo) y, en casos limitados, pequeñas adaptaciones a nuevos requisitos (mantenimiento evolutivo). Sin embargo, cambios significativos suelen requerir reiniciar todo el ciclo, lo que hace costosas las modificaciones una vez avanzado el proyecto. Esta estructura secuencial hace que el modelo en cascada sea particularmente adecuado para proyectos con requisitos estables y bien comprendidos, donde la predictibilidad y el control son prioritarios. Sin embargo, su rigidez lo hace vulnerable cuando surgen necesidades de cambio, ya que las iteraciones entre fases no están contempladas en el modelo clásico.

Ing. Sandra Navarrete CARACTERÍSTICAS PRINCIPALES:  Secuencial y Lineal: Cada fase debe estar 100% completa antes de pasar a la siguiente. No hay vuelta atrás.  Énfasis en la Documentación: Cada etapa genera documentación exhaustiva (especificaciones, planos técnicos) que actúa como contrato para la siguiente.  Predictivo: Se planifica todo al detalle al inicio del proyecto. El alcance, tiempo y costo se definen y congelan desde el principio.  Rol del Cliente: Involucrado casi exclusivamente en las fases inicial (Requisitos) y final (Entrega). VENTAJAS

• Predictibilidad : Presupuestos y cronogramas precisos gracias a la planificación detallada inicial.
• Documentación robusta : Ideal para auditorías o proyectos con regulaciones estrictas (ej.: ISO 27000 ).
• Roles definidos : Claridad en responsabilidades (analistas, diseñadores, programadores, QA). LIMITACIONES CRÍTICAS
• Inflexibilidad : Los cambios requieren retroceder fases. Ejemplo: Si en pruebas se detecta un requisito mal interpretado, debe modificarse el SRS y rediseñarse el sistema.
• Riesgo de "túnel" : El cliente no ve el producto hasta etapas tardías, lo que puede generar desalineaciones costosas.
• Poca adaptabilidad a entornos dinámicos : No es viable para startups o productos innovadores con requisitos volátiles. ¿Cuándo usarlo?
• Proyectos cortos y simples con requisitos bien entendidos y que no cambiarán.
• Proyectos con regulaciones estrictas que requieran una documentación exhaustiva y un proceso auditado (ej.: software médico, aeroespacial).
• Cuando el cliente exige un presupuesto y cronograma fijos desde el primer día. Ejemplo de Documento SRS (Especificación de Requisitos Software) en Cascada Nombre del Proyecto : Sistema de Gestión de Biblioteca Universitaria Versión : 1. Autores : Equipo de Desarrollo XYZ 1. Introducción 1.1 Propósito Este documento especifica los requisitos funcionales y no funcionales del sistema de gestión de biblioteca para la Universidad UCE, que permitirá administrar préstamos, devoluciones y catálogo de libros.

Ing. Sandra Navarrete

• Identificar los Casos de Uso que son funcionalidades principales que el sistema ofrece a los actores.
• Conectar Actores con Casos de Uso, para cada actor hay que establecer qué funcionalidad puede ejecutar.
• Colocar las relaciones y dependencias para evitar duplicación de funcionalidades. o Inclusión: Cuando un caso de uso siempre requiere otro. Se representa con una flecha punteada desde el caso base hacia el incluido, etiquetada con <>. Ej: "Reservar Libro" <> "Buscar Libro". (No puedes reservar sin antes buscar). o Extensión: Cuando un caso de uso puede (bajo cierta condición) extender el comportamiento de otro. Es una relación opcional. La flecha punteada va desde el caso que extiende hacia el caso base, etiquetada con <>. Ej: "Pagar Multa" <> "Devolver Libro". (Solo se paga multa si la devolución está atrasada). El diagrama identifica los principales procesos de negocio (casos de uso) como acciones que los actores pueden realizar, como "Insertar un nuevo libro" en una base de datos de la biblioteca. Su objetivo es clarificar los requisitos funcionales durante las fases iniciales de análisis. (Ejemplo simplificado: Actores: "Usuario”, “Bibliotecario", “base de datos”, Casos de uso: "Buscar libros", "Solicitar el préstamo de un libro”, etc.) Tarea : Completar los casos de uso para el sistema de biblioteca.

Ing. Sandra Navarrete

2. Diagrama de Secuencia (Préstamo de Libro) Un diagrama de secuencia es un tipo de diagrama de comportamiento en el modelado UML (Lenguaje Unificado de Modelado) que visualiza la interacción entre objetos en un sistema a lo largo del tiempo, mostrando el orden temporal en el que los mensajes se intercambian entre los diferentes componentes o actores involucrados en un escenario específico. Propósito Principal:

• Modelar la lógica de un caso de uso.
• Mostrar cómo los objetos colaboran para lograr una funcionalidad.
• Visualizar el flujo de mensajes y responsabilidades. Elementos Clave:

1. Actores: Entidades externas que interactúan con el sistema.
2. Línea de Vida (Lifeline): Representa un objeto o participante en la interacción.
3. Barras de Activación: Muestran el período durante el cual un objeto está procesando una tarea.
4. Mensajes: Flechas que indican la comunicación entre objetos es decir invocación y retorno.
5. Fragmentos: Áreas marcadas para condiciones (alt), opciones (opt), bucles (loop), etc. Este diagrama de secuencia muestra el proceso de autenticación de un usuario utilizando un fragmento alt para representar los dos escenarios posibles: credenciales válidas e inválidas.

Ing. Sandra Navarrete Consejos para decidir que tipo de relaciones utilizar:

• Agregación (Aggregation) : Cuando una clase (contenedora) tiene una colección de objetos de otra clase (contenida), pero el ciclo de vida de los objetos contenidos no depende de la clase contenedora. Ejemplo: Un Préstamo de Libros pertenece a un Usuario, pero si el préstamo se elimina, el usuario sigue existiendo, muchas veces se marca la cantidad de objetos que son parte como atributos de la clase, en este caso es un préstamo tiene un usuario. Por otra parte un Préstamo de Libros tiene uno o varias copias de libros, por lo que su relación es de 1 a n, incluso el atributo de la clase PrestamoLibro es una lista.
• Composición (Composition): Cuando una clase (contenedora) es dueña de objetos de otra clase (contenida) y el ciclo de vida de los contenidos depende del contenedor, es decir si una contenedora deja de existir, los objetos contenidos también dejan de existir. Ejemplo: un Préstamo de Libro puede tener una multa si se entrega tarde, por eso la cardinalidad es 0 (no es obligatorio ese atributo), sin embargo, una multa no puede existir si el préstamo no existe.
• Implementación (Interface Realization): Cuando una clase implementa una interfaz. La Interfaz define un contrato que la clase debe cumplir si es una clase concreta, o puede mantenerse como abstracta, y sus clases derivadas deben implementar los métodos definidos en la interfaz.

Ing. Sandra Navarrete

• Generalización (Inheritance): Para modelar herencia (relación "es-un"). Una subclase extiende una superclase. Por Ejemplo: Las clases LibroRepositorio, AutorRepositorio, RolRepositorio son heredadas de la clase abstracta BaseRepositorio, y deben implementar los métodos abstractos de la clase BaseRepositorio y heredan sus atributos protegidos.
• Dependencia (Dependency): Cuando una clase usa otra clase, pero no la almacena como atributo. Por ejemplo, la clase A tiene métodos que reciben parámetros del tipo de otra clase B, o retorna un objeto de la clase B, o en los métodos de la clase A se usan objetos de la clase B.
• Clase Interna (Inner Class): Cuando una clase existe únicamente en el contexto de otra clase y no tiene sentido independiente. Por ejemplo las clases estáticas que se declaran dentro de otras clases.