Frameworks de Aplicacin

1
Frameworks de Aplicación

• Fernando Telechea Bull Uruguay
• Germán Matosas Microsoft Uruguay

2
Agenda

• PRIMERA PARTE
• Definición de Framework
• Tipos de Frameworks
• Ventajas y Dificultades en la Utilización de
  Frameworks
• Documentación de los Frameworks
• Diferencias entre Patrones, Frameworks y
  Bibliotecas de Clase
• Nuestra Experiencia Uso de Enterprise Library
• SEGUNDA PARTE
• Microsoft patterns practices
• Filosofía de Microsoft Enterprise Library
• Applications Block que componen la Enterprise
  Library
• Visión de la Enterprise Library
• Bibliografía
• Preguntas y Respuestas

3
Definición de Framework

• El framework puede ser definido como un conjunto
  de clases (algunas de ellas generalmente
  abstractas), y las colaboraciones que se
  establecen entre ellas, para proporcionar un
  diseño abstracto para las soluciones de un
  conjunto de problemas.
• El framework captura las decisiones de diseño
  comunes a un tipo de aplicación, estableciendo un
  modelo común a todas ellas, asignándo
  responsabilidades y estableciendo colaboraciones
  entre las clases que forman el modelo.

4
Tipos de Frameworks

• Frameworks de Aplicación
• Un framework de aplicación encapsula una capa de
  funcionalidad horizontal que puede ser aplicada
  en la construcción de una gran variedad de
  programas.
• Frameworks de Dominio
• Un framework de dominio implementa una capa de
  funcionalidad vertical, correspondiéndose con un
  dominio de aplicación o una línea de producto. Su
  evolución deberá ser también la más rápida, pues
  deben adaptarse a las áreas de negocio para las
  que están diseñados.

5
Ventajas en la Utilización de Frameworks

• Se logra buen nivel de reuso (no solo a nivel de
  código), lo que implica
• Reducción en el tiempo de desarrollo de nuevos
  aplicativos.
• Reducción del costo de mantenimiento.
• Mayor nivel de confiabilidad (comparado con
  escribir código nuevo), en la medida que hay
  reuso y el framework se estabiliza.
• Estandarización y Consistencia
• Es posible encapsular estándares y mejores
  prácticas de la compañía en un framework,
  logrando consistencia y aseguramiento de uso de
  dichos estándares y mejores prácticas.

6
Dificultades con los Frameworks

• Los frameworks no son reutilizables por si solos,
  y cuando se diseña e implementan soluciones con
  la reutilización en mente, el tiempo y los costos
  en general, son mayores.
• Esto debe ser visto como una inversión, ya que en
  la medida que el framework se reutilice,
  aparecerán los beneficios.
• Requieren de programadores más experientes para
  su desarrollo, que una aplicación común
• Requieren de buena documentación y de
  entrenamiento para los desarrolladores que lo
  utilizan

7
Documentación del Framework

• La documentación del framework es escencial, para
  que este pueda ser reutilizado.
• La documentación debe contener
• El propósito del framework
• Como debe ser utilizado
• Diseño detallado del framework
• The most profoundly elegant framework will never
  be reused unless the cost of understanding it and
  then using its abstractions is lower than the
  programmer's perceived cost of writing them from
  scratch. Grady Booch

8
Documentación del FrameworkEjemplo - Utilización
9
Documentación del FrameworkEjemplo - Diseño de
DAAB
10
Patrones y Frameworks

• Los patrones de diseño tienen descripciones más
  abstractas que los frameworks
• Las descripciones de patrones suelen ser
  independientes de los detalles de implementación
  o del lenguaje de programación
• Los frameworks están implementados en un lenguaje
  de programación, y pueden ser ejecutados y
  reutilizados directamente
• Los patrones de diseño son elementos
  arquitecturales más pequeños que los frameworks
• Un framework incorpora varios patrones
• Los patrones se pueden usar para documentar un
  framework

11
Bibliotecas de Clase y Frameworks

• Arquitectura basada en biblioteca de clases
• Se logra reutilización a nivel de código
• Arquitectura basada en framework
• Se logra reutilización a nivel de diseño y código
• La arquitectura del framework tiene que ser
  diseñada tan bien como la comunicación entre los
  componentes internos de dicho framework. Al
  diseñar un componente para una biblioteca de
  clases ninguna de estas decisiones tienen que ser
  tomadas en cuenta.

12
Nuestra Experiencia - Proyecto B.P.S

• Aplicativo Actual
• Arquitectura de 3 capas
• Más de 3000 componentes COM (1300 de acceso a
  datos)
• Más de 5000 páginas ASP
• Cada componente en la capa de datos, resuelve el
  acceso a la base de datos.
• Desde que se migró la base de datos a la versión
  9i, no está soportado el driver de ODBC de
  Microsoft para Oracle.
• Los cambios se realizarán (cualquiera sea la
  alternativa), en cada uno de los 1300 componentes
  de acceso a datos.

13
Nuestra Experiencia - Proyecto B.P.S

• Nueva Arquitectura
• Creación de un framework de aplicación en base a
  Enterprise Library

• Extensión de Enterprise Library para poder
  utilizar el Managed Provider de Oracle para .NET
  (ODP.NET). Esto se logra heredando de una clase
  abstracta.

14
Nuestra Experiencia - Proyecto B.P.S

• Nueva Arquitectura
• El acceso a datos, se realizará de forma
  centralizada a partir del Data Application Block.

15
patterns practicesGuías de Arquitectura para
la Empresa
Probadas Basadas en la experiencia de
campo Precisas Tecnicamente validadas y testeadas
Accionables Provéen los pasos al éxito
Relevantes Encaran problemas reales basados en
casos de clientes
Disponibles en línea http//www.microsoft.com/pr
actices Libros disponibles http//www.amazon.co
m/practices
Application Blocks
Patrones
Arquitecturas de Referencia
Soluciones atómicas a problemas recurrentes
Guías a nivel de subsistema para servicios comunes
Guías a nivel de sistema para escenarios comunes
de clientes
D
A
D
I
D
A
D
I
A
A
D
D
I
I
Guías Orientación para amplios tópicos
transversales tales como seguridad, performance,
distribución y operaciones
16
Filosofía de la Enterprise Library

• Consistencia
• Aplicar patrones de diseño consistentes
  proveyendo implementaciones
• Extensibilidad
• Incluir puntos de extensión permitiendo a los
  desarrolladores personalizar la conducta de los
  bloques añadiendole su propio código o
  modificando directamente el código fuente
• Facilidad de Uso
• Proveer una herramienta de configuración gráfica
• Proveer un procedimiento de instalación sencillo
• Incluir documentación clara y completa y ejemplos
• Integración
• Los application blocks deberían estar diseñados
  para colaborar entre sí y testeados para asegurar
  que lo hagan. Pero debería también ser posible
  usar los application blocks individualmente

17
Enterprise Library v1
Caching
Exceptions
Security
Data Access
Logging
Crypto
Configuration
Config Tool
18
Enterprise Library Vision
Bloques pp
Bloques de proveedores
Bloques de clientes
Bloques de comunidad
Especificación de bloque
19
Enterprise Library

• Enterprise Library es
• Una biblioteca de application blocks que resuelve
  problemas comunes
• Un conjunto de clases helper que trabaja con
  cualquier estilo de arquitectura
• Guía de arquitectura incorporada en código
  distribuída con los fuentes permitiendo modificar
  y extender
• Disponible para descargar en forma gratuita

• Enterprise Library no es
• Parte de la plataforma .NET
• Un framework de aplicación que impone un estilo
  de arquitectura
• Un producto de Microsoft con soporte,
  compatibilidad y localización

20
Bibliografía y Documentación

• J. Bosch, Design Use of Software Architectures
  adapting and evolving a product-line approach,
  Addison Wesley
• M. Fayad, R. Johnson y D. Schmidt, Building
  Application Frameworks, Wiley Sons
• L. Bass, P. Clements y R. Kazman, Software
  Architecture in Practice, Addison Wesley
• http//www.microsoft.com/practices

21
Preguntas y Respuestas

• Muchas Gracias
• Germán Matosas germane_at_microsoft.com
• Fernando Telechea fernando.telechea_at_bull.com.uy