Arquitectura de software

LUIS FERNANDEZ MUNOZ

¿Por qué?

Prestar atención a la arquitectura de software, es como la construcción de piezas que se sostiene

una sobre otra. Primer entendimiento, el software son piezas que se sostienen una sobre otra.

Mucha atención en la arquitectura de software Sistemas Complejos, si el software no tiene una

forma definida una parábola de los seis sabios ciegos y el elefante.

Los ciegos y el elefante es una parábola originaria de la India, desde donde alcanzó una difusión
notable. Ha sido utilizada para ilustrar la incapacidad del hombre para conocer la totalidad de la
realidad. En distintos momentos se ha usado para expresar la relatividad, la opacidad o la
naturaleza inexpresable de la verdad, el comportamiento de los expertos en campos donde hay un
déficit o falta de acceso a la información, la necesidad de comunicación, y el respeto por
perspectivas diferentes.

Entonces si no tenemos una visión general de las cosas estas se nos escapan de las manos.

Sistemas complejos (Diseño), cumplir ciertas características en particular los sistemas complejos
que funcionan los humanos copiamos de la naturaleza, jerárquicos, separan asuntos, tienen
elementos primitivos relativos, mecanismos de interacción comunes, sistemáticamente todo se
hace igual, se comunican igual,

Si nos ponemos a programar como un loco tengo una maraña.

Vamos a darle forma a prestar atención a la forma, que esto sería la arquitectura de software.

¿Para qué?

Entonces para que prestar atención a la arquitectura del software … para que tenga calidad de
software, si está bien construido el software me va a permitir hacer un desarrollo efectivo
(programar añadiendo líneas y que estas líneas funcionan sin que se destroce todo no tener un
diseño frágil que si agregamos líneas el software se rompe por todos lados), eficaz y eficiente (no
cueste horrores hacer un cambio). (desarrollo del programa) escalable y adaptable criterios de
calidad, seguridad, portabilidad -> de la mantenibilidad depende de la calidad de software.

Rendimiento, un sistema bien diseñado, modular con escaso acoplamiento alta cohesión, con
tamaño de piezas limitadas ose un código que se le puede meter mano, pero con un software que
está hecho una maraña no le aumentas el rendimiento.

Si desarrollamos con diseño con arquitecturas viendo la forma que esta cobrando tu software
ahorramos cash, tiempo.

¿Cuando?

Esto se habla desde el origen de la programación Edsger Dijkstra, mucho cuidado con los lenguajes
que ecogemos.

El huminde programador – the humble Programmer.

Al principio hay teoría!!!!

¿Donde?

Ingenieria de software, alrededor de la arquitectura del software UML-Documentación

¿Quien?

Edsger Dijkstra, Comunidad científica/empresarial.

Metodologias:

Rational propone top/down mirar una visión general

Las Agiles, ponte a programar ponte a programar pero muy bien y entre todos entonces va
emergiendo la arquitectura va apareciendo.

El lenguaje y el pensamiento esta estrechamente relacionados ¡!!

En desarrollo saber dos o tres lenguajes de paradigmas muy diferentes te alimentan y te refrescan
que ya no eres el mismo.
Si no sabemos el porque? De donde vienes y el para que? A donde vas .. en el camino nos
perdemos con mucha facilidad.

Aclarar conceptos, del que:

Juego de lógica Mastermind

1.- Arquitectura del sistema vs. Del Software.

2.- Actores y Atributos de la Arquitectura.

3.- Documentación de la Arquitectura.

Principio de paquetes:

1.- Principio de reusabilidad común.

2.- Principio de cierre común

3.- Principio de equivalencia entre reusabilidad y entregable.(Git)

4.- Principio de dependencias acíclicas. (si una clase está relacionada con la otra y la otra está
relacionada con la una decimos que tiene un ciclo (no va esto) se podría permitir entre clases pero
no dentro de paquetes)

5.- Principio de dependencias estables.

6.- Principio de Abstracciones estables

Estas dos te ensenan el principio de Open/Close

7.- Métricas de paquetes.

Los paquetes (unidad de la arquitectura de software) cumplen el principio de única

responsabilidad.

ROL DEL ARQUITECTO DE SOFTWARE

Proponer, mantener y velar que la arquitectura sea correcta cumpla los principios tenga los estilos
arquitectónicos que tenga que tener (en la metodologia rational) y le dan tiempo para que
estudie los requisitos, los casos de uso, propone una arquitectura de análisis, empieza a implantar,
hace pruebas de rendimiento, hace prueba de los riesgos cuando ya se tiene un prototipo
funcionando y con esto entrega al equipo de desarrollo vigilando y manteniendo que las cosas se
hagan bien.

Cada desarrollador no entrega código sin prueba unitaria.

Para el tema de las pruebas hay un Tester, el tester cuando hace su propuesta se reúne con el
arquitecto y le pregunta cuales son los riesgos del proyecto y el arquitecto le confiesa tengo miedo
a esto a esto… bueno el otro le dice lo voy a encontrar para mostrarte cual es la realidad de tus
miedos, el tester no va a joder va a informar.

En las metodologías Agiles no hay meramente un arquitecto de software … el equipo entero es el

responsable de la arquitectura de software y como lo hacen .. todos además de desarrollar en el
proceso de refactoring es ir mejorando la calidad de software que ya funciona .. primero
programan para que funcione para que pasen las pruebas y cuando ya esta funcionando entonces
refactoring con la misma funcionalidad mejoran la calidad.

Todos le dedican tiempo mejorando la calidad aveces necesitan para todos los desarrolladores y
hacer una mejora general aquí es cuando va emergiendo la arquitectura.

…………………………………

Sobre que modelos y diagramas se deben realizar por lo menos un

arquitecto para decir que tiene una arquitectura.
Respuesta 4 + 1 vistas, (Documentacion de la arquitectura) de Philippe Kruchten.

4+1 es un modelo diseñado por Philippe Kruchten para "describir la arquitectura de sistemas
software, basados en el uso de múltiples vistas concurrentes". Las vistas suelen describir el
sistema desde el punto de vista de diferentes interesados, tales como usuarios finales,
desarrolladores o directores de proyecto. Las cuatro vistas del modelo son: vista lógica, vista de
desarrollo, vista de proceso y vista física. Además, una selección de casos de uso o escenarios
suele utilizarse para ilustrar la arquitectura sirviendo como una vista más. Por ello el modelo
contiene 4+1 vistas:1

 Vista lógica: La vista lógica está enfocada en describir la estructura y funcionalidad del

sistema. Los diagramas UML que se utilizan para representar esta vista son los Diagrama
de Clase, Diagrama de Comunicación, Diagrama de Secuencia.2

 Vista de desarrollo: La vista de desarrollo ilustra el sistema de la perspectiva del

programador y está enfocado en la administración de los artefactos de software. Esta vista
también se conoce como vista de implementación. Utiliza el Diagrama de
Componentes UML para describir los componentes de sistema. Otro diagrama UML que se
utiliza en la vista de desarrollo es el Diagrama de Paquetes.2
  Vista de proceso: La vista de proceso trata los aspectos dinámicos del sistema, explica los
procesos de sistema y cómo se comunican. Se enfoca en el comportamiento del sistema
en tiempo de ejecución. La vista considera aspectos de concurrencia, distribución,
rendimiento, escalabilidad, etc. En UML se utiliza el Diagrama de Actividad para
representar esta vista.2

 Vista física: La vista física describe el sistema desde el punto de vista de un ingeniero de

sistemas. Está relacionada con la topología de componentes de software en la capa física,
así como las conexiones físicas entre estos componentes. Esta vista también se conoce
como vista de despliegue. En UML se utiliza el Diagrama de Despliegue para representar
esta vista.2

 Escenarios: La descripción de la arquitectura se ilustra utilizando un conjunto de casos de

uso, o escenarios lo que genera una quinta vista. Los escenarios describen secuencias de
interacciones entre objetos, y entre procesos. Se utilizan para identificar y validar el diseño
de arquitectura. Esta vista es también conocida como vista de casos de uso.

Philippe Kruchten¸

MICROSERVICIOS, ARQUITECTURA DEL SISTEMA.

CONCEPTOS ARQUITECTURA DEL SOFTWARE

ARQUITECTURA:

 EL arte o ciencia de construir, específicamente, el arte o practica de diseñar y construir

estructuras y en especial habitables.
 Formación o construcción como o como si fuera el resultado de un acto consiente.
 Una forma o estructura unificada o coherente.

Puede ser construido por una persona. Construido de manera más eficiente y oportuna
Requerimientos: Un Modelo Simple, por un equipo.
Procesos Simples y herramientas simples Requerimientos: modelado, proceso bien
definido, herramientas poderosas.
SISTEMAS CON COMPLEJIDAD TECNICA ALTA

SISTEMAS CON COMPLEJIDAD TECNICA BAJA

TIPICA APLICACIÓN CRUD O HACER MARCROS DE EXCEL, BD SQL

SISTEMAS CON COMPLEJIDAD DE GESTION ALTA

APLICACIÓN CON CLIENTES, PROVEEDORES, Y TODOS LAS CLASES

SISTEMAS CON COMPLEJIDAD DE GESTION BAJA

ARQUITECTURA DEL SISTEMA VS DEL SOFTWARE

La industria del software se complace en tomar palabras y estirarlas en un sin número de

significados sutilmente contradictorios. Uno de los mayores afectados es la “arquitectura”. Tiendo
a ver la arquitectura como una de esas palabras que suenan impresionantes, usadas
principalmente para indicar que estamos hablando de algo que es importante. Martin Fowler.

Definición de Arquitectura del sistema:

La organización fundamental de un sistema incorporado en sus componentes, sus relaciones con

otros y su entorno y las principales guías de su diseño y evolución. IEEE
Diferencia entre Arquitectura del Sistema y Arquitectura del Software

Al nivel más alto, un sistema a menudo comprende Hardware, Software, Firmware, etc. Por lo
tanto, al obtener y seleccionar la arquitectura del sistema mas adecuada, la salida mas probable es
un conjunto de bloques de construcción funcionales, algunos de los cuales son hardware, algunos
softwares, etc. Los bloques de construcción del software, los subsistemas de software, tendrán un
conjunto de requisitos que deberán ser analizados y diseñados de la misma manera que se hace
en la Arquitectura de Sistemas de nivel superior. Sin embargo, en este siguiente nivel, es mas
probable que se preocupe por el rendimiento general del software, las interfaces de usuario, las
arquitecturas de base de datos, etc.

LA ARQUITECTURA DE SOFTWARE ESTA DENTRO LA ARQUITECTURA DEL SISTEMA

La arquitectura se habla a nivel de paquetes.

Definición de arquitectura de software

La arquitectura de un sistema de software intensivo es la estructura o estructuras del sistema, que

comprenden elementos de software (paquetes de clases), las propiedades visibles externamente
de esos elementos y las relaciones entre ellos. Carnigie-Mellon University

Una arquitectura es el conjunto de decisiones significativas sobre la organización de un sistema de

software, la selección de los elementos estructurales (paquetes) y sus interfaces por los que el
sistema está compuesto junto con su comportamiento como se especifica en sus colaboraciones
entre estos elementos, la composición de estos elementos estructurales y de comportamiento en
subsistemas progresivamente más grandes y el estilo de arquitectura que guían la organización …
estos elementos, sus interfaces, sus colaboraciones y su composición. Booch, Rumbaugh and
Jacobson

Analogía con la arquitectura de edificios proponemos el siguiente modelo de arquitectura de

software: {elementos, formas, justificación}. Esto es una arquitectura de software es un conjunto
de elementos arquitecturales (paquetes) que tienen una particular forma. Distinguimos tres clases
de elementos arquitecturales: elementos de procesamiento, elementos de datos y conexiones
entre elementos. Los elementos de procesamiento(controladores - presentadores) son
componentes que suministran la transformación de los elementos de datos: los elementos de
datos(modelos) son los que contienen la información usada y transformada: los elementos de
conexión (los cuales pueden ser tanto de procesamientos, de datos o ambas) son el pegamento
que une juntas las diferentes piezas de la arquitectura. Perry y Wolf
ANALOGIA
UN SISTEMA DE SOFTWARE INSTALADO CONSISTE DE:
 Megabytes de datos y código binario
 Asentado en algún medio de almacenamiento de
una o varias computadoras.
 Mientras de ejecuta parte de su código se carga en
la memoria principal.
UN RASCACIELOS CONSTA DE:
 Millones de ladrillos o toneladas de cemento.
 Asentado sobre tierra firme.
 Mientras funciona, necesita suministro de energía
para el aire acondicionado, ascensores, luz, etc.

DIFERENCIA ENTRE DISEÑO DE SOFTWARE Y ARQUITECTURA DE SOFTWARE

 El diseño del software se centra en la implementación de las funcionalidades (requisitos) del

sistema en términos de clases, sus relaciones, datos que manejan, casos de uso, etc.
 La arquitectura del software se centra en paquetes, no se centra en la implementación o la
aplicación de patrones de diseño.