Este documento presenta los fundamentos de la definición de arquitectura de software por un grupo de estudiantes. Incluye una introducción a conceptos clave de arquitectura de software según definiciones de IEEE y otros autores. Luego describe la evolución de modelos de arquitectura de software como monolítica, cliente-servidor y orientada a servicios. Finalmente discute principios de procesos de desarrollo de software modernos y el rol del arquitecto de software.

1. Fundamentos de Definición
de Arquitectura de Software
Integrantes:
Castillo Harving V-21.134.315
Garcia Ender V-16.126.317
Guzmán Mariam V-20.963.865
Muñoz Luis V-19.278.031
Rodriguez Maria V-22.114.256
Sandoval Anthony V-23.037.857
Septiembre 27 a Octubre 01 de 2005
Bogotá, Colombia

2. Arquitectura de Software
+ Que es una arquitectura?
+ “No estamos seguros, pero la reconocemos cuando
vemos una”
+ IEEE-1471-FAQ
2
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

3. Arquitectura de Software
+ IEEE 1471
+ Software Architecture in
Practice - Kazman
El nivel conceptual más alto de
un sistema en su ambiente.
“La estructura de
estructuras de un sistema,
la cual abarca
+ Arquitectura es la organización
componentes de software,
fundamental de un sistema
propiedades externas
visibles de estos
descrita en:
componentes y sus
– Sus componentes.
relaciones”.
– Relación entre ellos y con el
ambiente.
– Principios que guían su diseño y
evolución.
3
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

4. Discusión
+ Definir la arquitectura en los proyectos actuales es
crítico...
4
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

5. Evolución de Arquitecturas
+ Dos factores primarios en la ingeniería de software
que han incrementado la importancia de la
arquitectura:
5
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

6. Evolución de Arquitecturas
+ Aplicaciones Monolíticas
Arquitectura Cliente-Servidor
+ Interfaces gráficas de usuario (GUI).
+ Servicios de presentación, negocios
+ Clientes pesados, no estándar
+ Conexiones dedicadas a BD
y persistencia en la misma máquina.
+ No hay concurrencia de usuarios.
+ Alto acoplamiento entre tiers.
+ Protocolos pesados
+ Ejecución remota de SQLs
+ Alta administración
+ Bajo rendimiento
+ Alto tráfico de red
+ Baja accesibilidad
6
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

7. Evolución de Arquitecturas
+ Arquitectura Cliente-Servidor
Arquitectura de 3 niveles
Mejorada
+ Reutilización de lógica de negocio para
+ Lógica de negocios en BD
+ Clientes pesados, no estándar.
+ Conexiones dedicadas a la BD.
+ Mejora en rendimiento
diferentes clientes o sistemas.
+ Mejora la escalabilidad.
+ Mejora la flexibilidad.
+ Independencia de la base de datos.
+ Alta administración
+ Baja escalabilidad
+ Baja flexibilidad
+ Baja portabilidad
7
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

8. Evolución de Arquitecturas
+ Arquitectura de N-niveles
100.000+
+ Bajo costo de administración de clientes.
+ Alta accesibilidad.
+ Alta flexibilidad.
+ Alta disponibilidad y tolerancia a fallos.
+ Alta escalabilidad.
+ Independencia de DB
8
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

9. Evolución de Arquitecturas
+ Visión de Arquitectura Orientada a Servicios (SOA)
+ Requerimientos
Sistema
Batch
Portal de
Servicios Integrados
Arquitectónicos
+ Heterogeneidad
+ Escalabilidad
Base de
Datos
+ Disponibilidad
Servidor de
Procesos
+ Distribución
(BPM) Aplicaciones
+ Manejabilidad de Procesos
Legadas
+ Administración y monitoreo de procesos,
servicios e infraestructura
9
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005
Cluster de
Servidores de
Aplicaciones

10. Que es un Arquitecto de Software?
•
Rational Unified Process
•
SUN SL-425:
Arquitecto es un rol en un proyecto de El arquitecto:
desarrollo de software el cual es
– Visualiza el comportamiento
responsable de:
del sistema.
– Crea los planos del sistema.
– Liderar el proceso de arquitectura. –
Define la forma en la cual los
– Producir los artefactos necesarios:
elementos del sistema
Documento de descripción de
trabajan en conjunto.
arquitectura
– Responsable de integrar los
– Modelos y prototipos de
requerimientos no-funcionales
arquitectura.
(NRFs) en el sistema.
10
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

11. Discusión
+ Existe alguna diferencia entre arquitectura y diseño
de software?
11
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

12. Arquitectura Vs. Diseño
+ La arquitectura y el diseño difieren en tres áreas:
Arquitectura
Diseño
Nivel de
Abstracción
Alto nivel
Bajo nivel. Enfoque
específico en detalles
Entregables
Planear subsistemas, interfaces
con sistemas externos,
servicios horizontales,
frameworks, componentes
reutilizables, prototipo
arquitectónico
Diseño detallado
componentes.
Selección de tecnologías,
Requerimientos no funcionales
(QoS),
Manejo de riesgos
Requerimientos
funcionales
Áreas de
Enfoque
12
Especificaciones de
codificación
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

13. Arquitectura Vs. Diseño
+ La arquitectura envuelve un conjunto de decisiones
estratégicas de diseño, lineamientos, reglas y
patrones que restringen el diseño y la implementación
de un software.
Código
Implementación
Diseño
Las decisiones
de arquitectura
causan un alto
impacto en los
proyectos de IT
Arquitectura
13
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

14. Discusión
+ Cuales son los principios fundamentales en los
métodos de desarrollo de software modernos?
14
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

15. Arquitectura y Procesos de Desarrollo
Principios Fundamentales de Procesos Modernos
+ Desarrollo iterativo e incremental.
+ Conducido por las calidades sistémicas.
+ Centrado en la arquitectura.
+ Dirigido por los casos de uso.
+ Basada en Modelos.
+ Mejores prácticas de diseño.
15
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

16. Arquitectura y Procesos de Desarrollo
+ Que es un Proceso de Arquitectura?
+ Rational Unified Process:
+ Secuencia de actividades
que conllevan a la
producción de artefactos
arquitectónicos:
– Descripción de arquitectura
– Prototipo arquitectónico
16
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

17. Arquitectura y Procesos de Desarrollo
Rational Unified Process:
SunTone AM:
En el proceso de definición de
arquitectura se producen:
Adicionalmente se producen:
Matriz Tecnológica de Layers
y Tiers
+ Template de Arquitectura
+
Arquitectura Inicial.
+ Arquitectura de Referencia.
+ Documento de Descripción de
arquitectura (SAD):
+
–
–
–
+
17
Subsistemas
Componentes
Arquitectura Runtime.
Guías para el proyecto y
estándares de Diseño.
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

18. Definición de Arquitectura en RUP
Fase de Inicio
+
Con respecto a la arquitectura, en la
fase de inicio de los proyectos se
establece:
Requerimientos no-funcionales
– Lista de riesgos y restricciones
– Arquitectura inicial
–
18
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

19. Definición de Arquitectura en RUP
Fase de Elaboración
+
+
19
Con respecto a la arquitectura, en la
fase de elaboración se establece:
– Arquitectura línea base.
Entregables:
– Documento de Definición de
Arquitectura.
– Prototipo evolutivo de arquitectura.
– Guías y Estándares de Diseño.
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

20. Definición de Arquitectura en RUP
+ Modelo de Vista 4+1
+ Framework para Descripción de Arquitectura, basado en vistas
lógicas y físicas UML y una vista funcional de casos de uso.
Logical View
Analysts/Designers
Structure
Implementation View
Programmers
Software management
End-user
Functionality
Use-Case View
Process View
System integrators
Performance
Scalability
Throughput
20
Deployment View
System engineering
System topology
Delivery, installation
communication
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

21. Definición de Arquitectura en RUP
Definir arquitectura
candidata
Evaluar Req.
No Funcionales (NFR)
Refinar y Seleccionar
la Arquitectura
Prototipar la
Arquitectura
Valorar Calidades
Sistémicas
21
Ajustar
Arquitectura
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

22. Definición de Arquitectura en SunTone AM
+
+
22
Metodología de desarrollo de software análoga al Unified
Process (UP) con un fuerte énfasis en Calidad de Servicio y
Patrones de diseño.
El cubo: framework conceptual, el cual provee una vista
tridimensional:
– Tiers lógicos
– Layers tecnológicos
– Calidades sistémicas
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

23. Definición de Arquitectura en SunTone AM
23
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

24. Definición de Arquitectura en SunTone
+ Principios Arquitectónicos
+ La arquitectura es primariamente necesaria para crear
un framework para el desarrollo basado en patrones y
para la entrega de calidades sistémicas predecibles.
Presentation
Action Factory
Business
Integration
Business
Database Integration
DAO
Factory
Business
Delegate
Action
Session Facade
Oracle DAO
Factory
Composite Entity
Front Controller
View
JSF Components
24
Service
Locator
Value
Object
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005
DAO
OracleDAO

25. Definición de Arquitectura en IFM
+ Principios Arquitectónicos
+ El proceso de creación de arquitectura debe ser un
proceso de creación de valor.
+ La arquitectura se descompone en elementos
arquitectónicos (AEs).
+ La arquitectura se crea incrementalmente acorde a un
proceso secuencial dirigido por el ROI.
25
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

26. Definición de Arquitectura en IFM
+ Principios Arquitectónicos
+ La instanciación de los elementos arquitectónicos
(AEs) se realiza incrementalmente acorde a la
secuencia de MMFs, determinada por el ROI.
AE 1
AE 3
AE 7
AE 7
AE 8
AE 8
MMF A
26
AE 2
MMF B
MMF C
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

27. Ejemplo de Definición de
Arquitectura
+ eBank Trusted Hosting
+ Workshop de Arquitectura y Diseño de Aplicaciones J2EE
+ Curso WS50I - Lucasian Labs Ltda.
+ Entidad que presta el hosting
de los servicios de banca
personal en Internet
para un grupo de bancos.
27
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

28. Ejemplo de Definición de
Arquitectura
+ Dado un conjunto de requerimientos primarios
28
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

29. Ejemplo de Definición de
Arquitectura
+ Identificación de requerimientos funcionales y de
calidad de servicio (QoS)
29
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

30. Ejemplo de Definición de
Arquitectura
+ Identificación de supuestos, riesgos y restricciones
30
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

31. Ejemplo de Definición de
Arquitectura
+ Identificación de Actores y Casos de Uso primarios
31
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

32. Ejemplo de Definición de
Arquitectura
+ Arquitectura Lógica. Identificación de tiers lógicos,
subsistemas y paquetes
32
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

33. Ejemplo de Definición de
Arquitectura
+ Diseño de Arquitectura Runtime. Diagrama de
Despliegue.
33
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

34. Ejemplo de Definición de
Arquitectura
+ Plataforma Tecnológica. Definición de la matriz
tecnológica de layers y tiers
34
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

35. Discusión
+ Los requerimientos no funcionales son fuentes
comunes de riesgo…
35
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

36. Calidades Sistémicas
+ El manejo inadecuado de los requerimientos no
funcionales, es una de las fuentes más importante
de riesgo en los proyectos:
Reglas de negocio de alta complejidad.
– Calidades sistémicas
–
−
−
−
−
−
Seguridad
Rendimiento
Escalabilidad
Disponibilidad
Extensibilidad
+ La calidad de servicio (QoS = Quality Of Service) es
un riesgo primario relacionado con la arquitectura.
36
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

37. Calidades Sistémicas
+ Definición
+ Propiedades que establecen la
calidad de servicio (QoS) que un
sistema expone.
+ Son globales a toda la arquitectura
+ Influencian el diseño.
+ Son no-funcionales pero
+ Familias de
Calidades
Sistémicas
+ Manifiestas
+ Operacionales
+ Desarrollo
+ Evolutivas
observables.
37
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

38. Calidades Sistémicas Manifiestas
+ Observables por los usuarios del sistema.
+ Performance. Tiempo de respuesta desde el punto de vista del
usuario.
+ Reliability. Grado de probabilidad de realizar operaciones
correctamente.
+ Availability. Porcentaje de tiempo que un sistema puede
procesar solicitudes.
38
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

39. Calidades Sistémicas Operacionales
Observables cuando el sistema está operando en producción.
+ Throughput. Solicitudes atendidas + Security. Prevención de uso
por unidad de tiempo.
+ Manageability. Cantidad inversa de
esfuerzo para realizar labores
administrativas.
+ Serviceability. Esfuerzo para
actualizar el sistema para reparar
errores.
39
indeseado, por abuso o uso
inapropiado:
– Identidad
– Autoridad
– Confidencialidad
– Auditabilidad
– Integridad
+ Testability. Esfuerzo
invertido para detectar y
aislar errores.
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

40. Calidades Sistémicas - Evolutivas
+ Relacionadas con el comportamiento del sistema
cuando sufre algún cambio.
+ Escalability. La habilidad para
soportar la calidad de servicio
requerida conforme la carga aumenta.
+ Flexibility. Esfuerzo ahorrado cuando
se hace un cambio de configuración.
+ Portability. Esfuerzo ahorrado
+ Reusability. Esfuerzo ganado
en la utilización de componentes
existentes.
+ Extensibility. Esfuerzo ahorrado
para adicionar nuevas
funcionalidades.
cuando se migra a una infraestructura
+ Mantainability. Esfuerzo
diferente.
ahorrado para revisar y corregir
errores.
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005
40

41. Lecciones Aprendidas en
Consultoría
+ Defina una persona o un grupo de personas experimentadas,
encargadas de definir y validar arquitectura de sus proyectos.
+ Establezca los requerimientos de calidad de servicio con los
expertos del dominio y con los usuarios finales.
+ Involucre al equipo de trabajo en el proceso de definición de
arquitectura.
+ Documente y comunique la arquitectura y
lineamientos de diseño y logre aceptación.
No la imponga.
+ Sea firme con las decisiones, valore impactos
e identifique riesgos.
41
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005

42. Lecciones Aprendidas en
Consultoría
+ Valore alternativas de arquitectura y diseño tomando en cuenta las
calidades sistémicas y relación costo-beneficio.
+ Instancie los mecanismos arquitectónicos definidos incrementalmente.
No los instancie en bloque.
+ Reutilice frameworks, patrones de diseño y mejores prácticas. Sea
racional en el uso de tecnologías.
+ Tenga siempre presente que requerimientos
de seguridad, integración con sistemas
externos, canales de comunicaciones
con poco ancho de banda,
crecimiento del volumen de
usuario, expectativas de cambios de
requerimientos son fuentes comunes de riesgo.
42
XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 2005