ARQUITECTURA DE SOFTWARE

¿Qué es la Arquitectura de Software?

• "... una especificación abstracta de sistema que consiste principalmente en

componentes funcionales descritos en términos de sus comportamientos e
interfaces e interconexiones componente-componente. “ [Hayes-Roth]

• "... cosas que la gente percibe como difíciles de cambiar." [Martin Fowler]

• "La arquitectura de software es el conjunto de decisiones de diseño que, si se

toman de forma incorrecta, pueden provocar la cancelación de su proyecto." [Eoin
Woods]

• "... La arquitectura representa las decisiones de diseño significativas que dan forma
a un sistema, donde la importancia se mide por el costo del cambio." [Grady Booch]
 ¿Qué es la Arquitectura de Software? (Cont.)

• Arquitectura de Software =
Suma de todas las decisiones
arquitectónicas.

• Decisiones Arquitectónicas =
Decisiones fundamentales que
no se pueden cambiar
fácilmente después.
 ¿Qué son las decisiones arquitectónicas?

Preguntas Clave Ejemplos

¿Es difícil cambiar la decisión más tarde? Uso del protocolo XY para integrar el sistema Z

¿Es costosa la implementación de la decisión? Provisión de funcionalidades a través de una Web

API

¿Hay requisitos de alta calidad involucrados? Estructuración de todas las interfaces web
utilizando el modelo vista/controlador

¿Es difícil mapear los requisitos a la funcionalidad Uso del tipo "doble" en todos los algoritmos
ya existente?

¿Es tu experiencia en el espectro de la solución Uso de ORM XY

bastante débil?
MODELO C4
 MODELO C4

• Surge como solución para aliviar la

brecha entre modelo y código.

• Permite comunicar la arquitectura

de un sistema en función del
detalle que se quiera
proporcionar.

• Está basado en cuatro niveles que

describen el sistema con distintos
grados de granularidad:

• El nivel de contexto.
• El nivel de contenedores.
• El nivel de componentes.
• El nivel de código.
MODELO C4 (Cont.)
DIAGRAMAS PRINCIPALES
 NIVEL DE CONTEXTO

• Nos permite tener una imagen

genérica de nuestro sistema y
sus interacciones con el exterior.

• En este nivel podemos

especificar los sistemas externos
con los que interactúa nuestro
propio sistema.

• El sistema que modelamos se

considera una “caja negra”, sólo
nos interesan sus relaciones
externas.

• También permite identificar los

usuarios finales que harán uso
de la funcionalidad de nuestro
software.
 NIVEL DE CONTENEDORES

• Los contenedores referencian

cualquier entidad que ejecuta
código o almacena datos.

• Pueden verse como unidades

desplegables o ejecutables.

• Ejemplos de contenedores:

• Aplicaciones web
• Servicios web.
• Aplicaciones de Escritorio.
• Bases de datos.
• Sistemas de archivos.
 NIVEL DE COMPONENTES

• Dentro de cada contenedor

podemos encontrar diversos
componentes.

• Los componentes representan

un grupo de funcionalidades.

• Los componentes pueden tener

relaciones entre sí y entre los
usuarios finales.

• En este nivel se muestra la

responsabilidad de cada
componente de alto nivel, así
como los detalles de la
implementación (tecnología
utilizada, por ejemplo).
 NIVEL DE CÓDIGO

• En este nivel se muestran

detalles de la implementación de
cada componente.

• Se pueden utilizar diagramas de

clase, de entidad relación, o
similares.

• Este es un nivel de detalle

opcional y, a menudo, está
disponible bajo demanda desde
herramientas IDE.

• Este nivel de detalle se

recomienda sólo para los
componentes más importantes o
complejos.
NOTACIÓN
DIAGRAMAS COMPLEMENTARIOS
 DIAGRAMA DE PANORAMA DEL SISTEMA

• El modelo C4 proporciona una vista

estática de un solo sistema de
software pero, en el mundo real, los
sistemas de software nunca viven
aislados.
• A menudo es útil comprender cómo
encajan todos estos sistemas de
software dentro de los límites de
una empresa.
• El diagrama de panorama es otro
diagrama que muestra una vista
más amplia que los otros diagramas
principales del modelo C4, desde
una perspectiva de TI.
• Al igual que el diagrama de
contexto del sistema, este diagrama
puede mostrar los límites de la
organización, los usuarios
internos/externos y los sistemas
internos/externos.
 DIAGRAMA DINÁMICO

• Un diagrama dinámico puede ser

útil cuando se desea mostrar cómo
los elementos de un modelo
estático colaboran en tiempo de
ejecución para implementar una
historia de usuario, un caso de uso,
una característica, etc.
• Este diagrama dinámico se basa en
un diagrama de comunicación UML
(anteriormente conocido como
"diagrama de colaboración UML").
Es similar a un diagrama de
secuencia UML, aunque permite
una disposición de forma libre de
los elementos del diagrama con
interacciones numeradas para
indicar el orden.
 DIAGRAMA DE DESPLIEGUE

• Un diagrama de despliegue permite

ilustrar cómo los sistemas de software
y/o los contenedores en el modelo
estático se asignan a la infraestructura.
• Este diagrama se basa en el diagrama
de implementación de UML, aunque se
ha simplificado ligeramente para
mostrar la asignación entre
contenedores y nodos de despliegue.
• Un nodo de despliegue es una
infraestructura física (un servidor o
dispositivo físico), una infraestructura
virtualizada (IaaS, PaaS, una máquina
virtual), una infraestructura de
contenedores (Docker, Kubernates), un
entorno de ejecución (servidor de base
de datos, servidor web/aplicación de
Java EE, Microsoft IIS), etc.
• Los nodos de implementación se
pueden anidar.
HERRAMIENTAS
 https://www.draw.io/