LucasianLabs.UJAVERIANA.MNARANJO.DEF-ARQUITECTURA.ver1.6.0
Transcript of LucasianLabs.UJAVERIANA.MNARANJO.DEF-ARQUITECTURA.ver1.6.0
1
Fundamentos de Fundamentos de Definición de Arquitectura en Definición de Arquitectura en
RUP, IFM y SunTone AMRUP, IFM y SunTone AM
The Software Architecture And The Software Architecture And EngineeringEngineering Company Company
Mauricio NaranjoMauricio NaranjoChief Software Architect
www.lucasian.com
2
Objetivos
Esta presentación introduce:
• Conceptos de arquitectura de software y su importancia• Definiciones de Calidades Sistémicas• El rol del arquitecto• Fundamentos de Definición de Arquitectura en Procesos de
Desarrollo• Lecciones aprendidas en consultoría de arquitectura y diseño
de aplicaciones J2EE
3
Fundamentos de Definición de Arquitectura
Agenda
• Parte 1 - Fundamentos de Arquitectura de Software– Que es arquitectura de software?– Cual es el rol de arquitecto?– Calidades Sistémicas
• Parte 2 – Conceptos de Definición de Arquitectura– Rational Unified Process (RUP)– Suntone Architecture
Methodology (AM)– Iterative Founding Method
4
Arquitectura de Software
Que es una arquitectura?
“No estamos seguros, pero la reconocemos cuando vemos una”IEEE-1471-FAQ
5
• IEEE 1471El nivel conceptual más alto de un sistema en su ambiente.
• “Arquitectura es la organización fundamental de un sistema descrita en: – Sus componentes.– Relación entre ellos y con el
ambiente.– Principios que guían su
diseño y evolución”.
Arquitectura de Software
• Software Architecture in Practice - Kazman
“La estructura de estructuras de un sistema, la cual abarca componentes de software, propiedades externas visibles de estos componentes y sus relaciones”.
• “El objetivo de esta definición es que la arquitectura de software debe abstraer alguna información del sistema y aún proveer suficiente información para ser la base del análisis, toma de decisiones y lograr la reducción de riesgos”.
6
Arquitectura de Software
• Rational Unified Process
“Arquitectura es la estructura de los componentes más significativos de un sistema interactuando a través de interfaces con otros componentes conformados por componentes sucesivamente pequeños e interfaces”.
• SUN SL-425: Architecting and Designing J2EE Applications
“Arquitectura se refiere a la representación abstracta de los componentes de un sistema y su comportamiento”.
“La arquitectura no contiene detalles de implementación”.
7
Arquitectura de Software
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
8
Por que es importante definir una arquitectura?
Premisa• Las arquitecturas de los sistemas, existen indiferente si han
sido definidas formalmente o no.
• Dos factores primarios en la ingeniería de software que han incrementado la importancia de la arquitectura:
9
Evolución de Arquitecturas
Aplicaciones Monolíticas
• Interfaces gráficas de usuario (GUI).• Servicios de presentación, negocios y
persistencia en la misma máquina.
• No hay concurrencia de usuarios.• Alto acoplamiento entre tiers.
• Presentación• Lógica negocio• Persistencia
Arquitectura Cliente-Servidor
• Clientes pesados, no estándar• Conexiones dedicadas a BD• Protocolos pesados• Ejecución remota de SQLs
• Alta administración• Bajo rendimiento• Alto tráfico de red• Baja accesibilidad
• Presentación• Lógica de negocio • Persistencia
10
Evolución de Arquitecturas
Arquitectura Cliente-Servidor Mejorada
• Clientes pesados, no estándar.• Conexiones dedicadas a la BD.• Lógica de negocios en BD• Mejora en rendimiento• Alta administración• Baja escalabilidad• Baja flexibilidad• Baja portabilidad
Aplicaciones 3 niveles
• Reutilización de lógica de negocio para diferentes clientes o sistemas.
• Mejora la escalabilidad.• Mejora la flexibilidad.• Independencia de la base de datos.
Procedimientos Almacenados
Presentación
Servidor de Aplicaciones
Clientes GUIsemi-livianos
Base de Datos
Negocio(EJB, CORBA, COM+)
Clientes GUISemilivianos
11
Evolución de Arquitecturas
Aplicaciones N-niveles (clientes livianos)
Despliegue decontenido
Clienteslivianos
DatabaseServers
Lógica denegocios
100.000+
WebServer
Presentación
Servidor de Aplicaciones
• Bajo costo de administración de clientes.• Alta accesibilidad.• Alta flexibilidad.• Alta disponibilidad y tolerancia a fallos.• Alta escalabilidad.• Independencia de DB
12
Evolución de Arquitecturas
• Situación actual de Sistemas Empresariales
• Las empresas necesitan agilidad en su negocio:– Requerimientos cambian
continuamente.– Implementación de nuevos programas
o servicios para atraer o retener clientes.
– Requieren unificar, refina y medir sus procesos de negocio
• Requieren que su infraestructura de IT se pueda adaptar al cambio, se flexible y tener libertad de escoger nuevas tecnologías o productos en una relación costo beneficio.
13
Evolución de Arquitecturas
Procesos fragmentados
• Aplicaciones publicadas en diferentes departamentos y unidades de negocios
•Como se pueden integrar procesos y datos en una empresa con una relación costo beneficio efectiva?
•Como ayuda la arquitectura de software?
14
Evolución de Arquitecturas
Visión idealizada de Arquitectura Orientada a Servicios (SOA)
Cluster deServidores de Aplicaciones
AplicacionesLegadas
Servidor de Procesos
(BPM)
Base de Datos
SistemaBatch
Portal deServicios Integrados
Requerimientos Arquitectónicos
• Heterogeneidad• Escalabilidad• Disponibilidad• Distribución• Manejabilidad de Procesos• Administración y monitoreo de procesos,
servicios e infraestructura
15
Que es un Arquitecto de Software?
• Rational Unified Process
Arquitecto es un rol en un proyecto de desarrollo de software el cual tiene las siguientes responsabilidades:
– Liderar el proceso de arquitectura.
– Producir los artefactos necesarios: Documento de descripción de arquitectura
– Modelos y prototipos de arquitectura.
• SUN SL-425:
El arquitecto: – Visualiza el comportamiento
del sistema.– Crea los planos del sistema.– Define la forma en la cual los
elementos del sistema trabajan en conjunto.
– Responsable de integrar los requerimientos no-funcionales (NRFs) en el sistema.
16
Arquitectura Vs. Diseño
Discusión
• Existe alguna diferencia entre arquitectura y diseño de software?
17
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, Especificaciones de codificación
Áreas de Enfoque
Selección de tecnologías, Requerimientos no funcionales (QoS), Manejo de riesgos
Requerimientos funcionales
18
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.
Las decisiones de arquitectura son
las decisiones más fundamentales, por lo tanto, cambiarlas
ocasiona efectos significativos.Arquitectura
Diseño
Implementación
Código
19
Artefactos de Arquitectura
Rational Unified Process:En el proceso de definición de
arquitectura se producen:
• Arquitectura Inicial.• Arquitectura de Referencia.• Documento de Descripción de
arquitectura (SAD):– Subsistemas– Componentes– Arquitectura Runtime.
• Guías para el proyecto y estándares de Diseño.
SunTone AM:Adicionalmente se producen:
• Matriz Tecnológica de Layers y Tiers
• Template de Arquitectura
20
Evaluación de Tecnologías
Discusión
• Es importante para el arquitecto tener experiencia en evaluación de tecnologías?
• Si es así por que?
21
Evaluación de Tecnologías
• Beneficios de las habilidades del arquitecto para evaluación de tecnologías en proyectos:
– Aceptación. Conseguir la aceptación de los participantes del proyecto sustentando sus recomendaciones y decisiones con un buen nivel de fundamentación.
– Uso adecuado. Asegurar el uso apropiado de las tecnologías por los miembros del equipo.
•Un Arquitecto es un facilitador y líder.•No toma decisiones unilaterales, irracionales.•Evita riesgos en los proyectos, agrega valor.
22
Control de Riesgos
Discusión
• Por que fallan usualmente los proyectos?
23
Control de Riesgos
Quiz
• Una tienda virtual que vende juguetes no puede manejar la carga de usuarios por su alta demanda y sale de línea:
– Dos semanas antes de navidad– Después de una campaña de 20 Millones de USD.
• La expansión de capacidad tomará 6 semanas.
Cual es su diagnóstico respecto a la situación?• Los problemas que tiene esta aplicación son funcionales?• Están asociados a su arquitectura, diseño o implementación?
24
Control de Riesgos
• La calidad de servicio (QoS = Quality Of Service) es un riesgo primario relacionado con la arquitectura.
• 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
25
Calidades Sistémicas
Definición
• Son propiedades que establecen la calidad de servicio (QoS) que un sistema expone.
• Son globales a toda la arquitectura e influencian el diseño.
• Son no-funcionales pero observables.
• No se pueden satisfacer completamente por un componente.
• Familias de Calidades Sistémicas
• Manifiestas (Manifiest).• Operacionales
(Operational).• Desarrollo (Developmental).• Evolutivas (Evolutionary).
26
Calidades Sistémicas
Calidades Manifiestas (Manifest)• 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.
27
Calidades Sistémicas
• Throughput. Solicitudes atendidas por unidad de tiempo.
• Manageability. Cantidad inversa de esfuerzo para realizar labores administrativas.
• Serviceability. Esfuerzo para actualizar el sistema para reparar errores.
• Security. Prevención de uso indeseado, por abuso o uso inapropiado:
– Identidad– Autoridad– Confidencialidad– Auditabilidad– Integridad
• Testability. Esfuerzo invertido para detectar y aislar errores.
Calidades Manifiestas (Manifest)Observables cuando el sistema está operando en producción:
28
Calidades Sistémicas
Calidades Evolutivas (Evolutionary)Relacionadas con el comportamiento del sistema cuando es actualizado.
• 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.
• Extensibility. Esfuerzo ahorrado para adicionar nuevas funcionalidades.
• Reusability. Esfuerzo ganado en la utilización de componentes existentes.
• Portability. Esfuerzo ahorrado cuando se migra a una infraestructura diferente.
• Mantainability. Esfuerzo ahorrado para revisar y corregir errores de diseño.
29
Recursos de Arquitectura y Diseño
Discusión
• Que son los patrones de diseño?
• Por que son relevantes para unarquitecto?
30
Recursos de Arquitectura y Diseño
• Un Patrón describe una solución probada a un problema recurrente de diseño, el cual ocurre en un contexto.
• Existen patrones de arquitectura, análisis y diseño.
• La definición de arquitectura requiere un proceso basado en el raciocinio sobre patrones:
– Un arquitecto reutiliza patrones para definir la estructura y el comportamiento interno y externo de un sistema.
Utilizar patrones de
diseño es diferente a
diseñar patrones
31
Catálogos de Patrones• Como arquitecto se debe familiarizar
con la mayor cantidad de patrones posibles:
– Dedique tiempo a los catálogos de patrones.
– Conozca los patrones que están disponibles.
– Adquiera experiencia en el uso de los patrones.
– Conozca como tipificar los problemas que resuelven los patrones.
Recursos de Arquitectura y Diseño
32
Recursos de Arquitectura y Diseño
Catálogos de Patrones• Un arquitecto experimentado
reutiliza:– Arquitecturas de sistemas
exitosos.– Diseños que han funcionado
correctamente en el pasado.– Frameworks conceptuales y
tecnológicos.– Componentes y librerías.
33
Recursos de Arquitectura y Diseño
Discusión
• Que es un Framework?
34
Recursos de Arquitectura y Diseño
Definición de Framework
• Es un subsistema de software parcialmente construido, de propósito general para un tipo específico de problema, el cual debe ser instanciado para resolver un problema particular.
Características • Define la arquitectura para una familia de subsistemas• Provee bloques básicos de construcción y adaptadores.
Típicamente un framework se construye a partir de patrones de diseño.El framework impone patrones de diseño para su uso.
35
Recursos de Arquitectura y Diseño
Ejemplos de Frameworks
Tecnológicos• Struts y Java Server Faces (JSF)
para Interfaces Web.• Log4J para auditoría técnica o
negocios en app.• Toplink, Hybernate, ROME para
mapeos objeto-relacionales.• Enterprise Java Beans para
construcción de servicios de negocios.
• Framework de patrones de diseño para J2EE de Sun Microsystems.
• Grinder como framework para testing de performance.
Conceptuales• El Cubo para definición de
arquitecturas.• eTom para empresas de
telecomunicaciones.• RUP como metodología para
definición de procesos de desarrollo.
36
Métodos de Desarrollo
Discusión
• Cuales son los principios fundamentales en los métodos de desarrollo de software modernos?
37
Métodos de Desarrollo
Principios Fundamentales de Métodos 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.
38
Desarrollo Iterativo e Incremental
• Compare el costo de hacer correcciones en un desarrollo tradicional, con el costo de hacer correcciones en un desarrollo iterativo.
Cost
o f
ijo
TiempoC
ost
o f
ijoTiempo
Desarrollo Tradicional Desarrollo Iterativo
39
Reducción de RiesgoReducción de RiesgoReducción de RiesgoReducción de Riesgo
Riesgo de un proceso en cascada
Riesgo de un proceso iterativo
Tiempo
Riesgo
Desarrollo Iterativo e Incremental
40
Desarrollo Conducido por las Calidades Sistémicas
• Las calidades sistémicas son requerimientos no funcionales, los cuales definen la calidad de servicio que un sistema expone.
• Algunos ejemplos:– Rendimiento– Confiabilidad– Escalabilidad– Seguridad
• Las calidades sistémicas impactan directamente la arquitectura de un sistema.
41
Desarrollo Centrado en la Arquitectura
4 + 1 View ModelFramework de definición de arquitectura del RUP
• SunTone AM agrega dos características importantes a RUP:– Un enfoque en las
calidades sistémicas– El uso de patrones basados
en el razonamiento• Framework el Cubo:
42
Desarrollo Basado en Modelos
Definición• Los modelos son mecanismos primarios de comunicación
entre todos los participantes de un proyecto de software. Reflejan un aspecto particular de un sistema y abstraen detalles no relevantes.
Tipos• Documentos de texto• Diagramas UML• Prototipos
Objetivos• Comunicación• Resolver Problemas• Pruebas de Concepto
SistemaSistema
MiddlewareMiddleware
NegociosNegocios
AplicaciónAplicación
43
Definición de Arquitectura en RUP
• Proceso de Desarrollo Unificado
44
Definición de Arquitectura en RUP
Fase de Inicio• Durante la fase de inicio se
establece:– Requerimientos no-funcionales.– Arquitectura inicial, la cual se
considera viable para el proyecto.
– Lista de Riesgos y Restricciones.
• Entregables:– Documento de Visión– Arquitectura Inicial– Plan de la siguiente fase
45
Definición de Arquitectura en RUP
Fase de Elaboración• Durante esta fase se crean:
– Arquitectura línea base.– 80% de los requerimientos
del sistema.– Plan de iteraciones para la
fase de construcción.
• Entregables:– Requerimientos del Sistema.– Documento de Definición de
Arquitectura.– Prototipo evolutivo de
arquitectura.– Guías y Estándares.– Plan de Iteraciones.
46
Definición de Arquitectura en RUP
Modelo de Vista 4+1• Framework para Descripción de Arquitecturas del Rational
Unified Process (RUP), basado en vistas lógicas y físicas UML y una vista funcional de casos de uso.
Process View Deployment View
Logical View
Use-Case View
Implementation View
End-user Functionality
Programmers Software management
PerformanceScalabilityThroughput
System integratorsSystem topology
Delivery, installationcommunication
System engineering
Analysts/DesignersStructure
47
Definición de Arquitectura en RUP
[EarlyElaboration Iteration]
[Inception Iteration (Optional)]
Define a CandidateArchitecture
PerformArchitectural
Synthesis
Analyze Behavior
Refine theArchitecture
DefineComponents
Design theDatabase
(Optional)Architect
Describe the Run-timeArchitecture
Describe Distribution
ArchitectureAnalysis
Architect
48
Definición de Arquitectura en SunTone AM
• SunTone AM es una metodología de desarrollo de software análoga al Unified Process (UP), con un fuerte énfasis en las calidades sistémicas y patrones de diseño.
• Tiene un framework conceptual, el cubo, el cual provee una vista tridimensional de:– Tiers lógicos– Layers tecnológicos– Calidades sistémicas
• Con el cubo se puede definir la matriz tecnológica de Layers y Tiers, la cual documenta las decisiones tecnológicas para soportar la arquitectura de un sistema.
49
PlataformaVirtual
PlataformaSuperior
PlataformaInferior
Transporte
Aplicación
Layers
Tiers
Calidades Sistémicas
PERFORMANCE
AVAILABILITY
RELIABILITY
SCALABILITY
SECURITY
ClientePresentación
Negocios
Integración
Recurso
s
Definición de Arquitectura en SunTone AM
50
Definición de Arquitectura en SunTone AM
Presentación Negocios Integración Recursos
Estabilidad
Cliente
Volatilidad
- +
-+
51
Definición de Arquitectura en SunTone AM
Layers Tiers
Cliente Presentación Negocios Integración Recursos
Aplicación
Plataforma Virtual
Plataforma Superior
Plataforma Inferior
Red
52
Definición de Arquitectura en SunTone AM
Layers Tiers
Cliente Presentación Negocios Integración Recursos
Aplicación HTMLJava Script
Java ServletsJSPs
POJO DAO Tablas
Plataforma Virtual
Servlets 2.1JSPs 1.1
Plataforma Superior
Web Browser Apache 1.3.x, Tomcat 4.x MySQL
Plataforma Inferior
Independiente Linux
Red HTTP JDBC
POJO: Plain Old-Style Java Object
53
Definición de Arquitectura en SunTone AM
Layers Tiers
Cliente Presentación Negocios Integración Recursos
Aplicación HTMLJava Script
JSPsActionForms, Actions
Session Beans
DAO Tablas
Plataforma Virtual
Struts 1.xServlets 2.1JSPs 1.1
EJB 2.0
Plataforma Superior
Web Browser Apache 1.3.xTomcat 4.x
JBOSS Oracle DB
Plataforma Inferior
Independiente Linux
Red HTTP RMI/IIOP JDBC
54
Definición de Arquitectura en SunTone
Fundamentos• La arquitectura es primariamente necesaria para crear un
framework para el desarrollo basado en patrones y para la entrega de calidades sistémicas predecibles.
Business
Session Facade Composite Entity
Database Integration
DAO Factory Oracle DAO
Factory
OracleDAODAO
Value Object
Business Integration
Business Delegate
Service Locator
Presentation
Front Controller
Action Factory
Action
View
JSF Components
55
Definición de Arquitectura en Iterative Founding Method
Definición• Metodología con un enfoque de retorno
a la inversión (ROI) informado, en el cual el software es desarrollado y puesto en producción, en trozos de funcionalidades que agregan valor al usuario, cuidadosamente priorizados, llamados MMFs (Minimum Marketable Features).
• IFM integra actividades de ingeniería de software, con estrategias financieras de administración de proyectos.
• Descompone la arquitectura en elementos arquitectónicos (AEs).
56
Definición de Arquitectura en Iterative Founding Method
Principios Arquitectónicos• El proceso de creación de arquitectura, debe ser un proceso
de creación de valor.• Descompone la arquitectura en elementos arquitectónicos
(AEs).• Disminuye los costos de implementación de los AEs en un
modelo de secuencia.• Crea la arquitectura de software incrementalmente acorde a
un proceso secuencial dirigido por el retorno a la inversión (ROI).
Primer principio arquitectónico:“Difiera la solución de cualquier conflicto arquitectónico, hasta el momento en que la decisión sea necesaria”.
57
Definición de Arquitectura en Iterative Founding Method
• La codependencia de la Arquitectura en procesos tradicionales.
Definir arquitectura candidata
Evaluar Req.No Funcionales (NFR)
Refinar y Seleccionar la Arquitectura
Prototipar la Arquitectura
Medir CalidadesSistémicas
AjustarArquitectura
58
Definición de Arquitectura en Iterative Founding Method
• Dependencias arquitectónicas en IFM.• La instanciación de los elementos
arquitectónicos (AEs) se realiza incrementalmente acorde a la secuencia de MMFs, determinada por el ROI.
MMF A
AE 1
AE 3
AE 7
AE 8
MMF B
AE 2
MMF C
AE 7
AE 8
59
Conclusiones y Recomendaciones
Respecto a la arquitectura de software• La Arquitectura aborda la problemática de más alto nivel de los proyectos, es
crítica debido al alto riesgo de los proyectos actuales por su escala, distribución y complejidad.
• La arquitectura determina la estructura general de un sistema, la cual debe satisfacer la calidad de servicio requerida, mitigar riesgos.
• Las decisiones de arquitectura restringen el diseño y la implementación de un proyecto.
Respecto al arquitecto• Es un rol crítico en los proyectos, se focaliza en la calidad de servicio y lidera
el proceso de definición y la implementación de la arquitectura.• El arquitecto reutiliza arquitectura exitosas, frameworks y patrones de diseño.• No es un diseñador en un proyecto.
Respecto al Proceso de Definición de Arquitectura• El proceso de definición de arquitectura debe ser un proceso incremental de
creación de valor.• Defina solo los entregables necesarios para definir la arquitectura acorde a las
necesidades y trace la estrategia adecuada.
60
Preguntas y Respuestas
61
Fundamentos de Fundamentos de Definición de Arquitectura en Definición de Arquitectura en
RUP, IFM y SunTone AMRUP, IFM y SunTone AM
The Software Architecture And The Software Architecture And EngineeringEngineering Company Company
Mauricio NaranjoMauricio NaranjoChief Software [email protected]