Blog de Harry² 🚀

Los modelos y documentación de arquitectura de software son una manera fantástica de comunicar cómo planea construir un sistema de software (diseño inicial) o cómo funciona un sistema de software existente (documentación retrospectiva, intercambio de conocimientos y aprendizaje). Dominio:  Arquitectura de Software. Cómo comunicar la arquitectura: Vistas y Puntos de vista “Esencialmente, todo modelo es incorrecto. Pero algunos son útiles.” Empirical Model-Building and Response Surfaces (George Box, 1987). A rquitectura restrictiva : Restringe las decisiones que quedan por tomar (por ejemplo cuándo se le da a un equipo de desarrollo) Arquitectura descriptiva : Documenta las decisiones tomadas y describe el estado actual del sistema, restricciones del pasado más las actuales El arquitecto va a trabajar con diferentes personas para garantizar que la arquitectura se ejecute correctamente: Analista : Negociación de requerimientos. Operaciones : Cálculo de recursos. Desarrolladores : Restric

¡Maravilloso este punto, tantas opciones para elegir puede hacer que tomes una decisión no acertada… pero si basamos nuestra decisión en la experiencia ajena (exitosamente probada), seguro que llegamos a puerto seguro! Dominio:  Arquitectura de Software. Primer paso para crear una arquitectura. Pararse en hombros de gigantes Aprovechar el conocimiento existente para nuestra solución. Productos “de la estantería”. Productos ya echos que resuelvan parte de nuestros problemas. Frameworks y librerías. Ayuda a empezar/proponer desde una arquitectura más especifica. Arquitecturas especificas del dominio. Decisiones de diseño ya tomadas para ciertos dominios del problema. Patrones de arquitectura. Empezar desde un punto mas solido y restringir nuestro diseño a las partes importantes que quedan por resolver. Herramientas y partes de un diseño: Tipos de conectores La arquitectura está separada en dos partes fundamentales: Componentes : Son partes de nuestro sistema que cumplen una función espec

Son decisiones de diseño importantes ya tomadas para generar un esquema, estructura o tipo de comunicación entre componentes. Dominio:  Arquitectura de Software. Patrones monolíticos vs distribuidos Monolíticos : En este tipo de patrones, se entiende que existe una comunicación directa entre las partes del sistema, pero al distribuir dicho sistema este funciona como un ente único, esto dificulta la manutención del mismo pues no se pueden alterar partes especificas sin afectar al sistema en su totalidad, sin embargo, se puede desarrollar de manera más rápida. Distribuidos : En este caso, el patrón distribuido es aquel que despliega el sistema en forma seccionada, cada uno de los subsistemas funcionan como entes monolíticos de por si, esto facilita la manutención o la alteración de estos subsistemas sin dañar el sistema en su totalidad, sin embargo, se debe tener cuidado de generar inconvenientes de comunicación entre los subsistemas. Gran Bola de Lodo : Es un patrón que surge del descui

Son las expectativas de usuario, en general implícitas, de cuan bien funcionará un producto. Los atributos tienen identidad en si mismos y son las cualidades de la que todos hablamos, cuando un sistema es bueno o malo en algún aspecto. "Los atributos de calidad son las expectativas de usuario, en general implícitas, de cuán bien funcionará un producto." Software Requirements: 3rd Edition (Wiegers, Betty, 2013) Dominio:  Arquitectura de Software. Idoneidad Funcional  Tiene que ver con la conexión del usuario (tareas u objetivos a resolver con el sistema) y como están implementadas funcionalmente en dicho sistema. Se puede dividir en 3 partes: Completitud funcional : cuan completa esta la implementación con respecto a lo que se espera del sistema. Requerimientos Funcionales vs Funcionalidades implementadas. Exactitud funcional : cuan preciso es el sistema para implementar lo requerido. Resultados Esperados vs Resultados Obtenidos. Pertinencia funcional : cuan alineado esta lo