Arquitectura de Software - Programa Integración de...
Transcript of Arquitectura de Software - Programa Integración de...
¿Quienes conforman OMG?
AT&T
BEA
Borland
Boeing
CA
Citigroup
Compaq
Compuware
Ericsson
Ford
Fujitsu
Glaxo SmithKline
Hewlett Packard
Hitachi
Hyperion
IBM
IONA
io Software
Kabira
Kennedy Carter
John Deere
Microsoft
MITRE
MSC.Software
NASA
NEC
NetGenics
NTT
OASIS
Oracle
Pfizer
Rational
SAGA Software
SAP
SAS Institute
Secant
Siemens
Sprint
Sun
Unisys
Vertel
Object Management Group
Definición de MDA
MDA (Model Driven Architecture) es un Framework que proporciona
una solución para los cambios de negocio y de tecnología,
permitiendo construir aplicaciones independientes de la
plataforma e implementarlas en plataformas como CORBA, J2EE,
Servicios Web, etc. [OMG]
¿Qué es MDA?
MDA Guide v1.0.1 (www.omg.org/mda):
MDA is an approach to system development, which
increases the power of models in that work. It is model-
driven because it provides a means for using models to
direct the course of understanding, design, construction,
deployment, operation, maintenance and modification.
¿Qué es MDA?
IBM, An MDA Manifesto:
MDA is a style of enterprise application development and integration,
based on using automated tools to build system independent models
and transform them into efficient implementations.
In essence, the foundations of MDA consist of three complementary
ideas: Direct Representation, Automation and Open Standards.
1. Representación Directa:
Enfocándose en el dominio del
problema y no de la tecnología.
2. Automatización:
Herramientas que apoyen y
facilitan las labores mecánicas.
3. Estándares abiertos:
Que eliminen la diversidad y
formalicen el desarrollo en cada
plataforma.
Principios de MDA
IBM, An MDA Manifesto
¿Por Qué MDA?
Muchas plataformas y tecnologías
- Objetos Distribuidos, Componentes, Web services, ...
- No hay mucha interoperabilidad
- Y con tendencia aumentar
Evolución muy rápida
- Tecnologías evolucionadas que son obsoletas muy pronto
- Cual tecnología va a salir mañana?
- Y cuanto va a durar la ultima?
- Y como protejo mi inversión?
Por consiguiente, nunca tenemos un estándar en SO. DB, Servidores, Plataformas, Middleware, etc
Es complejo consensualizar un modelo y una forma de transformarlo con el propósito de ser menos dependiente de la tecnologías
¿Que es un Modelo?
Un modelo es la descripción de (una parte de) un sistema en un
lenguaje bien definido.
Un lenguaje bien definido es un lenguaje con una forma definida
(sintaxis) y significado (semántica), el cual sea apropiado para se
interpretado automáticamente por un computador. [MDA Explained]
Un modelo es frecuentemente presentado como una combinación de
dibujos y de texto. [MDA Guide]
Problemas con los modelos de software
Los modelos son usados solo como documentación
Vacíos entre el modelo y la implementación de los sistemas
- Vacíos semánticas en los lenguajes
- Los cambios en el modelo no se reflejan en el código
- Los cambios en el código nos se reflejan en los modelos (Solo segenera el código de los modelos la primera vez y nunca se actualiza)
No hay mezcla de modelos
- Vistas desconectadas de un sistema (horizontal)
- Grupos de modelos desconectados (vertical)
No hay transformación de modelos
- Pocos lenguajes de transformación populares
- No hay herramientas
1. Modelar Problema
2. Analizar Problema
3. Diseñar Solución
4. Construir Solución
Problema
Solución
Espacio del
problema
Espacio
de la
solución
Espacios del Problema y de la Solución
Problema
Solución
1. Modelar Problema
2. Analizar Problema
3. Diseñar Solución
4. Construir Solución
CIM- Modelo
Independiente de la
Computación
PIM- Modelo
Independiente de la
Plataforma
PSM- Modelo Específico
de la Plataforma
CODE- Código de la
Aplicación
MDA
Espacios del Problema y de la Solución
MDA - Arquitectura Dirigida por Modelos
• CIM: Modelo Independiente de la Computación
• PIM: Modelo Independiente de la Plataforma
• PSM: Modelo Específico de la Plataforma
• Código: Modelo de Texto
Espacio del problema
Espacio de la solución
Problema
CIM
PIM
PSM
Código
Solución
Procesos de transformación,
en lo posible apoyados con
herramientas.
Proceso de Desarrollo Cascada vs. MDA
Adaptado de: Kleppe, A., Warmer , J., Bast, W.: MDA Explained. Addison-Wesley (2003)
PIM
PIM
PIM
PSM
PSM
Code
Requirement
Analysis
Design
(Abstract)
Design
(concrete)
Production
(fine)
PDM Technical
Requirements
Technical
ArchitecturePDM
Platform
integration
Platform
description
PDM: Platform Description Model
Si el modelo inicial de las transformaciones tienen errores, estos se
propagaran a través de todos las transformaciones y la aplicación
resultante tendrá este error ampliamente potenciado.
Propagación de errores desde el CIM
Conceptos de MDSD
MDSD (Model Driven Software Development) se refiere a hacer desarrollo
de software mas relacionado con el dominio que con la computación, esta
es una forma de hacer desarrollo de software en un determinado dominio
mas eficiente.
[Markus Völter]
Arquitectura de Dominio en MDSD
Estructura de una Arquitectura de Dominio
y su relación con las Líneas de Productos
Adaptado de: Völter, M. y Stahl, T. Model-Driven Software Development (Technology, Engineering, Management)
ISBN: 978-0-470-02570-3, 444 p, 2006.
Para clarificar la diferencia entre los frentes físicos y lógicos definiremos los tres
conceptos que componen una arquitectura de dominio:
Un DSL (Lenguaje Específico de Dominio): Se refiere a un concepto de
carácter lógico que se usa en el espacio del problema, se define como un
lenguaje diseñado para modelar o resolver problemas en un dominio particular
bien definido, esto significa que en vez de ser un lenguaje para propósito
general, es un lenguaje que captura con precisión la semántica de un dominio
determinado.
Una plataforma: Se refiere a conceptos de carácter físico que hacen parte del
espacio de la solución, se define como la agregación de conceptos como: el
Middlewares, Librerías, Frameworks, Componentes y Aspectos.
Las transformaciones: Definen los mecanismos para llevar los modelos desde
el espacio del problema hasta el espacio de la solución.
Elementos de una Arquitectura de Dominio
¿Qué es un DSL?
Software Factories Definition:
A domain specific language (DSL) is a language that
enables the specification of software from a specific
viewpoint.
It defines abstractions that encode the vocabulary of the
domain that is focus of the viewpoint.
¿Que es Plataforma?
MDA Guide v1.0.1 by OMG:
is a set of subsystems and technologies that provide a coherent
set of functionality through interfaces and specified usage
patterns, which any application supported by that platform can
use without concern for the details of how the functionality
provided by the platform is implemented.
En informática, una plataforma es precisamente el principio, ya sea de
hardware o software, sobre el cual un programa puede ejecutarse.
Ejemplos típicos incluyen: arquitectura de hardware, sistema operativo,
lenguajes de programación y sus librerías de tiempo de ejecución.
Plataforma (otra definición)
Tipo de transformación
Adaptado de: OBJECT MANAGEMENT GROUP. Business Processes and the OMG: An Overview.
M2M
M2T
El Arquetipo de la Transformación de Modelos
Conforme a Conforme a
Meta-modelo A Meta-modelo B
Modelo A Modelo B
Transformación
Definición de la
transformación
Aplicación de la
transformación
Un Perfil es un mecanismo definido por UML para extender y adaptar
UML a una plataforma o dominio particular. Incluye 3 elementos:
estereotipos, valores etiquetados y restricciones.
Perfiles de UML
Los Perfiles se basan en Meta-modelos.
Un meta-modelo es un modelo que define el lenguaje para expresar un
modelo. La siguiente figura ilustra las diferentes capas definidas en la
arquitectura de la OMG que sustenta MOF, el meta-modelo de UML.
[OMG-MOF2003].
Los Perfiles y los Meta-modelos
Imagen Tomada de: The Tao of Modeling Spaces Dragan Djurić, Dragan Gašević, Vladan Devedžić,
Relación entre BPM, EA y OOAD
http://www.ibm.com/developerworks/webservices/library/ws-soad1/
¿Dadas las características de un proyecto o empresa, qué
modelo de proceso de desarrollo de software debo aplicar?
Caracterización de Proyectos
Métodos
Técnicas
Lenguajes
Herramientas
Ascendente
(Bottom-Up)
Descendente
(Top-Down)
Registro de información en bases de datos.
Aplicaciones transaccionales.
Aplicaciones Web.
Interfaces de usuario.
…
Desarrollo de Aplicaciones
Métodos: RUP
Técnicas: OO, Componentes, …
Lenguajes: UML, Java, PHP, …, SOAP, …
Herramientas: Modeladores UML, Eclipse, Netbeans, …
Descendente
(Top-Down)
Mejoramiento continuo.
Automatización de procesos.
Monitoreo de procesos.
Estrategias de negocio.
…
Proyectos de Procesos
Métodos: PMF, …
Técnicas: BPM
Lenguajes: BPMN, BPEL, …, SOAP, …
Herramientas: BPMS como Intalio, BizAgi, Oracle, etc.
Descendente
(Top-Down)
BPMS Business Process Management System
Transformación
BPMN - BPEL
Proceso de transformación,
generalmente no manipulable
por parte del desarrollador.
Herramientade Modelado
(BPMN)
Motor de Ejecución de Procesos
(BPEL)
Proyectos de Procesos con BPM
Desarrollo de Software con BPM (Business Process Management)
Modelo de procesos de Negocio construido usando
BPMN (Business Process Modeling Notation)
Aplicación Web desplegada desde un BPMS usando
BPEL (Business Process Execution Language)
http://www.bpminstitute.org/articles/article/article/a-soa-based-business-rules-approach-decision-services.html
Un proceso de desarrollo que involucre “proyectos de
procesos” debe realizar actividades que cubran todas
las Capas de Procesos de Negocio.
Enfoques orientados por procesos
http://soaagenda.com/journal/articulos/category/bpm/
Enfoques orientados por procesos
Suelen aplicar ciclos de vida en
espiral, o se basan en el ciclo
de vida de los procesos,
buscando cubrir las diferentes
aspectos del proceso de
negocio.
En el ejemplo se ven los roles y
las fases, usando la plataforma
BEA Aqualogic BPMS.
En algunos casos las plataformas definen enfoques propios definidos por el
ciclo de vida del proceso, como recientemente Intalio con PMF.
The Process Modeling Framework (P.M.F.) is a structured approach to process
modeling that results in consistent, accurate, readable process diagrams using
the BPMN
Enfoques orientados por procesos
Se basan principalmente en el uso de “Suites de Gestión de Procesos
de Negocio”
http://mediaproducts.gartner.com/reprints/lombardi/article2/article2.html
Enfoques orientados por procesos
Adobe Livecycle - Adobe Systems
BizAgi BPM Suite - BizAgi
Fujitsu Interstage BPM - Fujitsu
IBM BPMS - IBM
Intalio Enterprise Edition - Intalio
Lombardi Teamworks - Lombardi Software
Oracle BPM Suite - Oracle
SAP's NetWeaver Composition Environment - SAP
Tibco iProcess - Tibco Software
Integración de tecnologías.
Negocios basados en tercerización.
Aplicaciones que acceden plataformas heterogéneas (Legadas).
Estrategias de proceso basados en tecnología.
…
Proyectos de Servicios
Métodos: SOAD, …
Técnicas: SOA
Lenguajes: SOAP, WSDL, …, BPEL, …
Herramientas: ESB como OpenESB, OESB, WESB,
WMB
Ascendente
(Bottom-Up)
Arquitectura Orientada a Servicios
SOA (Service Oriented Architecture) es una aproximación
para construir sistemas usando servicios que se adhieren
a 4 pilares fundamentales:
Los limites son explícitos.
Los servicios son Autónomos.
Los servicios comparten esquemas y contratos, no clases.
La compatibilidad de los servicios, se determina basados
en las políticas.
Implementación de una SOA con un ESB
http://msdn.microsoft.com/en-us/library/ff647678.aspx
Enfoques orientados por servicios
Un proceso de desarrollo que involucre “proyectos de
servicios” debe realizar actividades que cubran todas las
Capas de una SOA.
http://www.ibm.com/developerworks/webservices/library/ws-soa-design1/
Suelen aplicar ciclos de vida en
cascada, o se basan en el ciclo
de vida de los servicios,
buscando cubrir las diferentes
capas de una SOA.
En cada capa se desarrollan los
componentes necesarios para
el funcionamiento de la misma
http://soaagenda.com/journal/articulos/category/soa/
Enfoques orientados por servicios
Los métodos orientados por servicios suelen poner especial énfasis en
la arquitectura y el modelado, los aspectos mas relevantes a
representar en la arquitectura son:
Datos
Reglas de Negocio
Servicios
Perfiles de Configuración
Variaciones
http://www.ibm.com/developerworks/webservices/library/ws-soa-design1/
Enfoques orientados por servicios
Se basan principalmente en el uso de “Buses de Servicios
Empresariales” y herramientas para “SOA Governance”
http://mediaproducts.gartner.com/reprints/oracle/article53/article53.html
http://mediaproducts.gartner.com/reprints/oracle/article65/article65.html
Enfoques orientados por servicios
Estándares SOA según Oracle
http://download.oracle.com/docs/cd/E12839_01/integration.1111/e10223/suite_02.htm
La Arquitectura de Componentes de Servicio (SCA) es unconjunto de especificaciones que describen un modelopara construir aplicaciones y sistemas usando unaArquitectura Orientada a Servicios (SOA).
SCA extiende y complementa enfoques predecesores paraimplementar servicios (EJB, JMS, JCA, Java EE Integration),diversas tecnologías (Java, C, C++, Spring, PHP, COBOL,BPEL) y estándares existentes (Web Services).
¿Qué es SCA?
http://www.osoa.org/display/Main/Service+Component+Architecture+Home
Está basado en la idea de que la funcionalidad denegocios es provista como una serie de servicios, que seensamblan para crear soluciones que sirven unanecesidad de negocio particular.
Estas aplicaciones compuestas pueden contener tantoservicios nuevos como funcionalidad expuesta comoservicios de aplicaciones existentes, reusadas comoparte de la composición.
¿Qué es SCA?
http://www.osoa.org/display/Main/Service+Component+Architecture+Home
Un artefacto básico de SCA es el componente, el cual es unaunidad de construcción para SCA. Un componente consistede una instancia configurada de una funcionalidadimplementada.
La funcionalidad es ofrecida mediante servicios. Suimplementación pueden depender de otros servicios; dichasdependencias se llaman referencias.
Los componentes pueden tener propiedades configurables.
Conceptos de SCA
http://www.osoa.org/display/Main/The+Assembly+Model
SCA describe el contenido y ensamblaje de una aplicaciónen ensambles conocidos como composites.
Los composite pueden contener componentes, servicios,referencias, declaraciones de propiedades, así como elwiring que describe las conexiones de estos elementos.
Los servicios y referencias de componentes pueden serpromovidos a servicios y referencias del composite.
Conceptos de SCA
Notación en SCA
http://www.osoa.org/display/Main/The+Assembly+Model
Especificación complementaria a SCA, diseñada parasimplificar y unificar el acceso a datos en las aplicaciones,bajo el enfoque SOA.
Usando SDO, las aplicaciones pueden acceder y manipulardatos a través de orígenes heterogéneos, como RDBMS,repositorios XML, Web services, y sistemas de informaciónempresariales (ERP, SRH, CRM entre otros)
SDO: Service Data Objects
Actualmente existen especificaciones e implementacionespara diversos lenguajes:
- Java
- PHP
- C
- C++
- COBOL
SDO: Service Data Objects
http://www.ibm.com/developerworks/websphere/techjournal/0510_peterson/0510_peterson.html
Implementación del
Proceso en BPEL
Ejemplo de Aplicación Compuesta
Aplicación de “Atención de Solicitudes”
Implementación del
Servicio de Negocio,
con las 4 operaciones, y
referencias a los
servicios de entidad y
de aplicación
requeridos.
Ejemplo de Aplicación Compuesta
Aplicación de “Atención de Solicitudes”
Servicios de Entidad,
implementados con SDO
Servicios de Aplicación
(SRH y CRM)
Ejemplo de Aplicación Compuesta
Aplicación de “Atención de Solicitudes”
Open SOA group. The SCA and SDO specifications. http://www.opensoa.org
Eclipse SCA Tools wiki. http://www.eclipse.org/stp/sca/
Wokflow Management Coallition. The XPDL specification.
http://www.wfmc.org/xpdl.html
Baeyens, Tom. InfoQ Articles. Process Model Components.
http://www.infoq.com/articles/process-component-models
Dubray, Jean-Jacques. InfoQ Articles. The Seven fallacies of business process
model execution. http://www.infoq.com/articles/seven-fallacies-of-bpm
White, Stephen. "Mapping BPMN to BPEL Example". Febrero 2005.
http://www.bpmn.org
Referencias
1. Vallecillo, Antonio. El Futuro de los Servicios Web. Universidad de Málaga
2. Naranjo, Julio. Arquitectura Basada en Servicios, Microsoft.
3. Álvarez, José Mauricio. EL Valor de Negocio de Arquitecturas Orientadas a
Servicios. Microsoft.
4. NET Architecture Center: Service Oriented Architecture
http://msdn.microsoft.com/architecture/soa/
5. Understanding Service-Oriented Architecture
http://msdn.microsoft.com/architecture/soa/default.aspx?pull=/library/en-
us/dnmaj/html/aj1soa.asp
6. Patterns & Practices http://www.microsoft.com/resources/practices
7. FTPOnline: SPECIAL REPORT: Service-Oriented Architecture
http://www.ftponline.com/special/soa/
8. MetaGroup – Disruptive SOA Trends - Transcript 2034
Referencias