Lic. Esteban Cesar Calabria 2007estebancalabria.com.ar/articulospdf/Parte I - Introduccion.pdf · Consideraremos como definir la arquitectura de una aplicación empresarial a

Arquitectura de

Aplicaciones

Empresariales

Lic. Esteban Cesar Calabria

2007

TEMARIO

� Introducción Aplicaciones Empresariales

� Introducción a la Arquitectura de Aplicaciones

empresariales

� Layering

� Patrones Arquitecturas Empresariales

� Algunos patrones Base

Arquitectura


Arquitectura

“Software architecture is the set of design decisions

which, if made incorrectly, may cause your project

to be cancelled."

– Eoin Woods

Aplicaciones Empresariales

� Que entendemos por arquitectura…

�División de alto nivel de un sistema en

sus partes

�Decisiones que son difíciles de cambiar



� Existen distintas visiones de arquitectura

que cambian durante el ciclo de vida del

sistema.

� Es algo subjetivo, un conocimiento

compartido sobre el diseño del sistema en

forma de los componentes mas

importantes y como interactúan.


División de

alto nivel

Decisiones

difíciles de

cambiar

Conocimiento

subjetivo

Vision del

Sistema

ARQUITECTURA

Decisiones

tempranas

Interaccion

Partes

Componentes

Importantes


� Algunos factores que intervendrán son:

�El equipo de trabajo

�La plataforma

�Cantidad de usuarios

�Complejidad de la lógica de negocios

�Escalabilidad

�El tipo de aplicación


Patrones de Arquitectura

Arquitectura

� Patrón de Arquitectura

� Describen un problema que ocurren una y otra vez.

� Esbozan una la solución a ese problema

� Un mismo patrón puede aplicarse muchas veces sin

hacer 2 veces lo mismo.

� Están arraigados en la práctica

� Ayudan a la comunicación

Arquitectura

� Algunos ejemplos de Patrones de Arquitectura son:

� Presentation-abstraction-control

� Layering

� Pipe-Filter

� Implicit invocation

� Blackboard system

� Peer-to-peer

� Broker Pattern

� Naked objects

� SOA

� Microkernel

Arquitectura

� Los mencionados son aceptados con cierto

consenso como patrones de arquitectura.

� Cada patrón de arquitectura se orienta a un

determinado tipo de aplicación.

� Aquí veremos aplicaciones empresariales donde

se utiliza principalmente layering, pero eso no

implica que no podamos tomar ideas de otros

patrones de arquitectura.

Arquitectura

� Naked Objects

�Toda la interfaz de usuario es generada

automáticamente a partir de un modelo de

objetos.

� Peer-to-Peer

�Por ejemplo el azureus o emule presenta esta

arquitectura

Arquitectura

� Pipe-Filter� Muy común ver soluciones de este estilo implementadas en el shell de unix/linux.

� MicroKernel� Un componente central (Kernel) que se encarga de mediar entre distintos modulos.

� Interpreter� Por ejemplo la Java se construye sobre una arquitectura de ese estilo



� Qué es una aplicación empresarial?

� Aplicaciones que se utilizan en una empresa

� Se integran en los procesos de negocio de la misma

� Muestran, manipulan y almacenan grandes

cantidades de información


� Las aplicaciones Empresariales pueden

incluir:

�Manejo del Stock de la empresa

�Sistemas Financieros

�Sistemas de Reservas

�Ventas, Compras

�Manejo de la Producción

�ERP (Enterprise Resource Planning)


� NO son aplicaciones empresariales:

�Sistemas Operativos

�Juegos de Computadoras

�Sistemas Embebidos

�Aplicaciones Ofimáticas

�Aplicaciones P2P que funcionen por Internet.

�Sistemas Inteligentes


� Consideraremos como definir la arquitectura de una aplicación empresarial a..� Definir como separaremos la aplicaciones empresariales en capas.

� Definir como estructuraremos la lógica de negocios.

� Definir como va a ser la presentación.

� Describir el mecanismo que utilizaremos para Transportar objetos de memoria a la base de datos

� Acordar como realizaremos el manejo de sesiones

� …


Caracteristicas



� Características Importantes

�Manejar Datos Persistentes

�Manejan Grandes Cantidades de Datos

�Se accede a los datos concurrentemente

�Muchas Interfaces de Usuario

�Se integran con otras aplicaciones

empresariales

�Contienen lógica de negocio compleja

Problemáticas

en Aplicaciones Empresariales


� Las temas que nos enfrentamos al construir una

aplicación empresarial abarcan:

� Organización de la aplicación (Layering)

� Estructurar Reglas de Negocio

� Interfaz de Usuario y Presentación

� Persistencia

� Seguridad

� Concurrencia

� Manejo de Sesiones

� Internacionalización


� La lista continua:

�Manejo de transacciones

�Distribución

�Validación y manejo de errores

�Mensajería

� Integración de Diferentes Aplicaciones

�Escalabilidad

�Performance

�Versionados y Entregas Incrementales

Layering


� Layering es una técnica muy común utilizada a

la hora de diseñar software para dividir un

sistema complejo.

� Se puede ver en

� Arquitectura de computadoras

� Arquitectura de Redes

� Arquitectura de Sistemas Operativos



�Ejemplo de Layering en

Computadoras

�Lenguaje de Programación

�Llamadas al Sistema Operativo

�Llamadas a Assembler

�Hardware



�Ejemplo de Layering en Redes

�FTP se construye sobre..

�TCP que se construye sobre..

�IP que se construye sobre

�Ethernet





� Ejemplo de Layering en sistemas operativos



� Características

�Existe la idea de Capa Superior y Capa inferior.

�Una capa superior usa los servicios de la capa inferior inmediata

�Una capa inferior no sabe nada de la existencia de las capas superiores

�Generalmente la capa 4 usa servicios de la capa 3 que a su vez usa servicios de la capa 2, pero la capa 4 desconoce la existencia de la capa 2



� Ventajas

�Se puede entender una

capa en particular sin

saber demasiado sobre el

resto de las capas

�Por ejemplo se puede

construir un servidor ftp

sobre tcp sin saber en

detalle como funciona

ethernet.

FTP

TCP

???



� Ventajas

�Se pueden sustituir capas con

implementaciones alternativas que

ofrezcan los mismos servicios

Aplicacion

Capa que lee datos

desde un archivo

Capa que lee los datos

desde una base de datos

Access

Capa que lee los datos

desde una base de Firebird

Interfaz Capa

PersistenciaInterfaz Capa

Persistencia

Interfaz Capa

Persistencia


� Ventajas

� Agregar capas intermedias

permite minimizar

dependencias entre las

capa.

� Por ejemplo podemos

cambiar ADSL por

Cabmemodem, pero

mientras funcione la capa

de IP, no tenemos que

modificar el servidor FTP


Aplicaciones Empresariales� Ventaja

� Una vez que se construye una capa, se puede reutilizar con muchos servicios de alto nivel

FTP HTTP TELNET SSH

TCP

� Ventaja

� Las capas y los servicios que ofrecen son un buen lugar para definir estándars.



� Desventaja

� No existen estándares en cuanto a la definición de los

servicios e interfaces entre capaz para las aplicaciones

empresariales.

� No existe un estándar/consenso para el desarrollo de

aplicaciones empresariales de la misma forma que

existe por ejemplo con TCP/IP

� Desventaja

� Capas adicionales pueden dañar la performance



� Desventajas

�Las capas encapsulan algunas cosas, pero no

todas.

�Cambios en Cascada.

�Ejemplo

� Para agregar un campo nuevo para mostrar en la

interfaz gráfica debe modificarse la base de datos y

por consiguiente todas las capas en el medio



� Centraremos la discusión sobre

Aplicaciones empresariales en tres Layers

o capas lógicas

�Presentación

�Dominio, Domain, Lógica de Negocio, Capa

de negocios

�Data Source (ej:Persistencia)


� En ingles se distinguen los términos Tier y Layer

� En castellano no hay una clara separación y suele referir a todo

como capa

� Tier

� Implica una separación física

� Separar un sistema en capas no significa que todas

tienen que correr en una PC o procesos distinto.

� Hablaremos de Capas lógicas


Layering En Aplicaciones

Empresariales



� Centraremos la discusión sobre Aplicaciones

empresariales en tres Layers o capas lógicas

�Presentación

�Dominio, Domain, Lógica de Negocio, Capa de

legocios

�Data Source (ej:Persistencia)



Comunicación con: base de datos,

sistemas de mensajería,

manejadores de transacciones,

otros paquetes

Data Source

Modela y resuelve la problemática

para la que el sistema fue

concebido

Dominio

Proveer lo necesario para mostrar

información y manejar las acciones

que genera el usuario

Presentación

ResponsabilidadLayer

Layering

� Dividir la aplicación en capas es algo conceptual.

� Por ejemplo, para un problema simple puedo

hacer todo en un mismo método o hacer un

método para la presentación, un método para la

persistencia y un método para la lógica de

negocios

� A medida que el sistema evoluciona esos

métodos se pueden ir transformando en clases

independientes

Capa de Negocios


Capa de Negocios

Modela y resuelve la problemática para la

que el sistema fue concebido


Capa de Negocios

� Opciones� Trabajar orientado a transacciones:

� y tener un metodo/objeto que se encargue de procesar cada transaccion del sistema:

� Aprovechar las funcionalidades de una plataforma que base mucha de su funcionalidad alrededor de un RecordSet

� Construir un modelo de negocios rico con objetos


Capa de Negocios

� Opciones

� Transaction Script

� Table Module

� Domain Model


Layer de Negocios

Capa de Persistencia



Comunicación con: base de datos, sistemas de

mensajería, manejadores de transacciones, otros

paquetes

Debido a su importancia nos concentraremos en la

comunicación del objeto con la base de datos



� Opciones� Un objeto que abstraiga el acceso a una tabla

� Un objeto que abstraiga el acceso a un registro de la base de datos

� Un objeto que abstraiga el acceso a un registro de la base de datos y contenta lógica de negocios

� Un objeto que transporta objetos de memoria a una base de datos



� Opciones

� Table Data Gateway / DAO

� Row Data Gateway

� Active Record

� Data Mapper


Capa Presentación


Capa Presentación

Proveer lo necesario para mostrar información y

manejar las acciones que genera el usuario


Presentación

� Gran parte de la arquitectura de nuestra

aplicación se vera afectada dependiendo si

decidimos realizar:

� Rich Clients

� Thin Clients

� Smart Clients


� Opciones

� Model View Controller

� Model View Presenter

� Template View

� Transform View

� Two Step View



� Heurística Importante

�Las capas de Domain y Data Source no

deben ser dependientes de la

presentación. En otras palabras no debe

existir ningún método en capas que

invoque a una rutina de la presentación.

Ejemplo Separación en Capas



�En el Cliente

�Ventajas

�Tiempos de Respuesta (responsiveness)

�Operaciones Desconectadas

� Interfaces Gráficas ricas y complejas



� Veamos un ejemplos…

�Se quiere mostrar en una lista de productos

de modo que aquellos que han incrementado

sus ventas en relación al mes anterior se

pinten con verde

�Como lo resolvemos?

Donde ejecutar cada capa…



� La separación de capas es útil incluso si todas

las capas corren en la misma PC.

� La decisión es dónde ejecutar el procesamiento

� En el cliente

� En un servidor

� Ej : tener un front-end HTML que use un web browser



�En el servidor

�Ventajas

�Facilita el deployment

�Facilita solucionar errores

�Soluciona problemas de compatibilidad



� Opción 1: Programo esa lógica en la capa de

presentación de modo que antes mostrar un

producto comparo sus ventas contra las del mes

anterior

� Opción 2: Agrego un método en la capa de

negocios que me devuelva un valor Boolean

dependiendo si el producto vendió mas que el

mes anterior. La capa de presentación llama a

ese método para saber si pintar el producto de

otro color o no

Patrones Base

Patrones Base

� Algunos patrones base que citaremos son:

� Dependency Injection / Plugin / Separated Interface

� Data Transfer Object / Value Object

� Record Set

� Gateway

� Mapper

� Layer Supertype

� Conditional Map

Documents

Lic. Esteban Cesar Calabria 2007estebancalabria.com.ar/articulospdf/Parte I - Introduccion.pdf · Consideraremos como definir la arquitectura de una aplicación empresarial a