Arquitectura de Software Capitulo 7

1. SOFTWARE AVANZADO
FACULTAD DE INGENIERIA – ESCUELA DE CIENCIAS Y
SISTEMAS

2. ARQUITECTURA QUANTICA
• Un artefacto de despliegue independiente con alta cohesión funcional
y sin conciencia crónica.
• Despliegue independiente: Cada componente puede desplegarse de manera
independiente sin afectar el funcionamiento global del sistema. Equivale al
principio cuántico de superposición de estados.
• Alta cohesión funcional: Los componentes están altamente cohesionados en
términos de la funcionalidad que encapsulan. Siguiendo el principio cuántico de
especialización de función.
• Conciencia Sincrónica: Los componentes tienen una visión global del sistema
para coordinarse, equivalente a la noción cuántica de entanglement donde las
partículas están correlacionadas.
• La arquitectura cuántica busca aplicar metáforas de la física cuántica
para diseñar sistemas con componentes débilmente acoplados,
altamente cohesivos, y con conocimiento global del sistema. Esto en
teoría brinda mayor escalabilidad, flexibilidad y facilidad de
despliegue.
2
SOFTWARE
ARCHITECTURE

3. PENSAMIENTO BASADO EN COMPONENTES
• Componente es la manifestación física de un módulo.
• Los desarrolladores empaquetan módulos en diferentes formas,
dependiendo de la plataforma de desarrollo.
3
SOFTWARE
ARCHITECTURE

4. ALCANCE DEL
COMPONENTE
Los componentes ofrecen un mecanismo
específico del idioma para agrupar artefactos
a menudo anidandolos para crear
estratificación.
El contenedor más simple a menudo se
denomina biblioteca (library), que tiende a
ejecutarse en la misma dirección de memoria
que el código de llamada y comunicarse a
través de los mecanismos de invocación de la
función.
Los componentes también aparecen como
subsistemas o capas en la arquitectura, como
la implementable unidad de trabajo para
muchos procesadores de eventos.
Otro tipo de componente, es un servicio,
tiende a ejecutarse en su propio espacio de
direcciones y se comunica a través de
protocolos de red de bajo nivel.
4
S
O
F
T
W
A
R
E
A
R
C
H
I
T
E
C
T
U
R
E

5. ROLE DEL ARQUITECTO
• Por lo general, el arquitecto define, refina, administra y gobierna los
componentes dentro de una arquitectura.
• Arquitectos de software, en colaboración con analistas de negocios,
expertos, desarrolladores, ingenieros de aseguramiento de calidad y
operaciones, crean el diseño inicial del software, incorporando
características arquitectónicas y requerimientos del software.
• El componente es el nivel más bajo del sistema de software en el que
interviene un arquitecto.
• Los componentes consisten en clases o funciones, cuyo diseño cae en
la responsabilidad de lideres técnicos o desarrolladores.
• Un arquitecto debe identificar componentes como la primera tarea en
un proyecto, pero antes debe decidir como particionar la arquitectura.
5
SOFTWARE
ARCHITECTURE

6. PARTICIONAMIENTO
• Por capas versus Monolitica
6
S
O
F
T
W
A
R
E
A
R
C
H
I
T
E
C
T
U
R
E

7. TECHNICAL TOP LEVEL
PARTITIONING
7
SOFTWARE
ARCHITECTURE

8. LEY DE CONWAY
8
SOFTWARE
ARCHITECTURE
Las organizaciones que diseñan sistemas están obligadas a producir diseños que
son copias de las estructuras de comunicación de estas organizaciones.

9. DOMINIOS Y
FLUJOS DE
TRABAJO
Arquitectura con particiones técnicas y de
dominio
9
S
O
F
T
W
A
R
E
A
R
C
H
I
T
E
C
T
U
R
E

10. DISEÑO PARTICIONADO POR
DOMINIO
1 0
SOFTWARE
ARCHITECTURE

11. PARTICIONES DE DOMINIO
• Separan los componentes de nivel superior por flujos de trabajo y/o
dominios.
• Ventajas:
• Modelado más cerca de cómo funciona el negocio en lugar de una
implementación detallada.
• Facilidad para utilizar la Maniobra inversa de Conway para construir equipos
multifuncionales alrededor del Dominio.
• Alineado a estilos arquitectónicos monolíticos y microservicios.
• El flujo de mensajes coincide con el dominio del problema
• Fácil de migrar datos y componentes a la arquitectura distribuida
• Deventajas:
• El cࣕódigo personalizado aparace en varios lugares
1 1
SOFTWARE
ARCHITECTURE

12. DISEÑO PARTICIONADO
TECNICAMENTE
1 2
SOFTWARE
ARCHITECTURE

13. PARTICIONAMIENTO
TECNICO
• Separa componentes de alto nivel basado en capacidades técnicas
más que en flujos de trabajo discretos.
• Se pueden separar en capas como en Modelo-Vista-Controlador.
• Ventajas
• Las personalizaciones en código son separadas claramente.
• Alinea mas estrechamente a los patrones de arquitectura por capas
• Desventajas
• Mayor grado de acoplamiento global.
• Los cambios en los componentes comunes o locales afectan a los demás
componentes
• Es posible que los desarrolladores tengan que duplicar conceptos de dominio
tanto en el dominio común como en el local.
• Mayor acoplamiento a nivel de datos.
1 3
SOFTWARE
ARCHITECTURE

14. CICLO DE IDENTIFICACIÓN
DE COMPONENTES
1 4
SOFTWARE
ARCHITECTURE

15. DISEÑO DE COMPONENTES
1 5
SOFTWARE
ARCHITECTURE
• No existe una forma "correcta" aceptada para diseñar componentes.
• Existe una amplia variedad de técnicas con varias compensaciones.
• Un arquitecto toma requisitos y trata de determinar qué bloques de
construcción de grano grueso aplicar.
• Existe muchas técnicas diferentes, todas con diferentes compensaciones y
acoplado al proceso de desarrollo de software utilizado por el equipo y la
organización

16. DISEÑO DE COMPONENTES
• Arquitectos, desarrolladores, analistas de negocios y expertos, crean
un diseño inicial de componente basado en el conocimiento del
sistema y como eligen descomponerlo, con base en criterios técnicos
o partición de dominio.
• El objetivo del equipo es un diseño inicial que divide el problema
espacio en trozos gruesos que tienen en cuenta las diferentes
características arquitectónicas.
1 6
SOFTWARE
ARCHITECTURE

17. TRAMPA DE LA ENTIDAD
• Si bien no existe una única forma de determinar los componentes, un
antipatrón común acecha: La trampa de la entidad.
• En el siguiente diagrama el arquitecto básicamente ha tomado cada
entidad identificada en el requerimiento y creó un componente
llamador Manager basado en la entidad.
1 7
SOFTWARE
ARCHITECTURE

18. TRAMPA DE LA ENTIDAD
• Esta no es una arquitectura, es una mapa objeto relacional (ORM) de
un marco de trabajo a una base de datos. Si un sistema solo necesita
operaciones simples (créate, read, update, delete) de la base de
datos, entonces se puede utilizar un marco de trabajo para crear
intefaces directas a la base de datos.
• Muchos frameworks ORM populares para resolver este problema
común
1 8
SOFTWARE
ARCHITECTURE

19. ENFOQUE ACTOR/ACCION
• Enfoque Actor/Acción
• Se utiliza para mapear requerimientos a componentes. Definido por Rational
Unified Process.
• Lluvia de eventos
• Es una técnica de descubrimiento de componentes dentro del Diseño basado en
Dominios (DDD), se asume que el proyecto usará mensajes y/o eventos para
comunicar entre varios componentes.
• Enfoque de flujos de trabajo
• Ofrece un enfoque más genérico para arquitectos que no utilizan DDD o
mensajes. Se modelan componentes a través de los flujos de trabajo.
1 9
SOFTWARE
ARCHITECTURE

20. SOFTWARE AVANZADO
FACULTAD DE INGENIERIA – ESCUELA DE CIENCIAS Y
SISTEMAS