80
Arquitectura de Software Juan Bernardo Quintero

Arquitectura de Software - Programa Integración de ...aprendeenlinea.udea.edu.co/lms/moodle/pluginfile.php/109880/mod... · de software mas relacionado con el dominio que con la

Embed Size (px)

Citation preview

Arquitectura de Software

Juan Bernardo Quintero

¿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)

PDM: Platform Description Model

De un ciclo de vida

en “V”

Hacia un ciclo de

vida e “Y”

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

Proceso de Transformación de Modelos

Enfoques en el Proceso de Transformación

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]

MDSD en una imagen [Markus Völter]

Conceptos de MDSD

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

DSL (Domain Specific Language) en MDSD

¿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.

Gráficos No SW:

Textuales en SW:

Gráficos en SW:

(Transformado

en Textual)

DSL (Ejemplos)

Plataformas en MDSD

¿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)

Transformación de Modelos en MDSD

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

Ejemplo de Perfil EJB

Ejemplo del uso del Perfil EJB

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ć,

Ejemplo de un Meta-modelo de un RDBMS

MOF: El Meta-modelo de UML

MOF

UML Meta-Model

UML

Instancias con datos

Ecore el meta-modelo de UML en Eclipse

Ecore el meta-modelo de UML en Eclipse

¿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

BPMN como el CIM en MDA

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.

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

OMG’s Workshop on Building a Service Oriented Architecture with BPM and MDA

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

Ejemplo de Aplicación Compuesta

Aplicación de “Atención de Solicitudes”

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”

El Metamodelo de SCA

http://www.eclipse.org/stp/sca/

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