Ingeniera Multimedia

Diseo de Sistemas Multimedia

Tema 2 Interfaces
Introduccin
Disciplina HCI: human-computer-interaction
Estudia cmo los humanos interactan con todo tipo de ordenadores. Disciplinas involucradas: psicologa, ergonoma, ingeniera, diseo grfico El UI debe ser transparente: o El usuario debe olvidar que est usando un ordenador o Debe permitirle centrarse en su tarea El UI debe ser accesible: para todos en todo momento El UI debe ser usable: eficacia + eficiencia + satisfaccin

ISO 9241
The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. Effectiveness: the accuracy and completeness with which users can achieve goals in particular environments Efficiency: the resources expended in relation to the accuracy and completeness of the goals achieved Satisfaction: the comfort and acceptability of the work system to its users and other people affected by its use

Como hacerlo bien

Principios Human-Centered Design (HCD) (ISO 13407) Involucrar activamente a los usuarios Iteracin de soluciones de diseo Equipos de diseo multidisciplinares 4 actividades esenciales Entender y especificar el contexto de uso Especificar el usuario y requerimientos organizacionales Usar prototipos Evaluar los diseos con usuarios confrontando requerimientos

Requerimientos
Visin general
Para qu dominio se desarrollar la aplicacin Pblico objetivo: quines son los usuarios, qu quieren hacer con el sistema, dnde se usar ste.

Usuarios
Observacin directa, indirecta, entrevistas, encuestas Caractersticas UI segn rol de usuario, experiencia.

Discapacidades
Permanente Temporal (pero usual): Trabajador con jornadas muy largas, al final de stas disminuyen sus reflejos.

Tareas
Describir el trabajo del usuario objetivo: dnde quiere llegar el usuario tarea: secuencia de actividades accin: actividad parte de una tarea

Casos de uso
Ver desde el punto de vista del usuario, no del programador. (Clsico, sistema) Accin del usuario Respuesta del sistema (que hace internamente) (Vista usuario, tarea) Propsito del usuario Responsabilidad del sistema (que muestra)

Ensayos cognitivos
Se evalan los pasos requeridos para realizar una tarea y se intenta descubrir errores entre lo que el usuario piensa sobre una tarea y cmo la ve el diseador del UI. Paso: El usuario hace accin Cuestin Sabe el usuario que hacer? Y antes y despus de accin?

Diseo conceptual
Paso de requerimientos a diseo fsico/visual Principios de diseo grfico Uso de metforas Seleccionar elementos SW y HW de E/S adecuados Proceso creativo de establecer la organizacin de la informacin y las acciones disponibles. Sobre este diseo realizaremos el diseo del UI Requerimientos --> Diagrama de contenido --> Diseo UI

Pasos
1. 2. 3. 4. Caso uso esencial: esbozamos las tareas que el usuario quiere hacer Derivamos caso de uso concreto: es un refinamiento del caso de uso esencial Hacemos el diagrama de contenido Concretamos el diagrama de contenido en uno o varios mockups

1. Diagrama de caso de uso

Propsito del usuario | Responsabilidad del sistema

2. Diagrama de contenido
Antes de disear pantallas. Boceto o prototipo de baja fidelidad que representa la organizacin y estructura del UI desde la perspectiva del diseador. Compuesto de contenedores y enlaces entre ellos:

Contenedor = representacin abstracta de una parte de la funcionalidad ofrecida al usuario. Puede ser una pantalla, parte de sta, un dilogo... Pantalla en GUI = uno o varios contenedores Enlaces = { navegacin | intercambio de informacin }. Puede ser un hipertexto, un men contextual, la interaccin entre una tabla de datos y una grfica

Actividades para producir un diagrama de contenido: 1. Derivar casos de uso concretos a partir de los C.U. esenciales 2. Identificar los objetos principales que soportarn la tarea, atributos y acciones 3. Crear contenedores y establecer los objetos que van en cada uno 4. Enlazar contenedores para mostrar cmo fluye la navegacin y la informacin

Estilos de interaccin
1. Estilos de interaccin
Diferentes formas con las que un usuario se comunica con el sistema Conjunto de controles de UI que proporcionan el look & feel (apariencia y comportamiento) Todos deben seguir los principios de diseo: Affordance (el diseo del objeto sugiere cmo se debe usar), Visibilidad, Retroalimentacin, Simplicidad, Estructura, Consistencia, Tolerancia

2. Lnea de comandos
Potente, flexible, difcil de aprender, difcil de recordar, tpicamente baja tolerancia a errores: mensajes de salida confusos, para expertos, mayor control. PAUTAS Usar nombres significativos para comandos Seguir una sintaxis consistente (gramtica) para todos los comandos Abreviaturas consistentes Hacer los comandos lo ms cortos posibles para evitar errores y en su caso que sea sencillo detectarlos y corregirlos Para respuestas a comandos usar abreviaturas comunes (S para s, N para no,...) Limitar el nmero de comandos y formas para realizar una tarea Ofrecer la posibilidad de crear y ejecutar macros (scripts - p.ej. potencia bash)

3. Men de seleccin
No tiene por qu ser grfica (los clsicos de DOS (pulse 1 para entrar, pulse 0 para salir,...)). Efectivos: ofrecen pistas para que el usuario reconozca lo que quiere frente a recordar lo que quiere para que realmente lo sean los nombres de mens e iconos deben ser auto-explicativos Mejor para usuarios no entrenados. Para los entrenados: usar atajos PAUTAS Usar la semntica de tareas para organizar los mens Ttulos de los mens que reflejen las funciones Agrupar los tems con sentido Evitar mens demasiado largos: adems considerar el tamao de pantalla

Ordenar los tems de los mens con sentido Usar nombres cortos Usar una gramtica, organizacin y terminologa consistentes Ofrecer ayuda sensible al contexto: caja de bsqueda en mens...

4. Formularios
Cuando necesitamos obtener muchos datos del usuario. Metfora de una hoja de papel. Si est bien diseado el formulario el usuario se formar rpidamente un modelo mental preciso. PAUTAS Nombres o ttulos de campos con sentido Usar el lenguaje del usuario (no el del diseador) Ofrecer instrucciones completas y comprensibles Ordenar (visualmente + tab) y agrupar los campos de forma lgica Presentar de forma llamativa el formulario Usar terminologa y abreviaturas consistentes Usar los espacios para organizar Restringir el nmero de caracteres Ofrecer valores por defecto (con cuidado para evitar que sean usados mal) Permitir el movimiento con el cursor Permitir que se corrijan caracteres sueltos o el campo entero Mostrar mensajes de error para campos individuales cuanto antes mejor que expliquen cmo corregir el error Indicar campos obligatorios Ofrecer ayuda contextual y ejemplos

5. Manipulacin directa (DM)

El usuario interacta directamente con los objetos del UI. Tpicos en entornos WYSWYG (what you see is what you get). Uso extensivo de metforas. La mayora de los sistemas embebidos la usan (a travs de teclas, apuntadores, voz). Caractersticas clsicas de los DM: Hay una representacin visible y continua de los objetos de tarea y sus acciones, por lo que no hay nada que recordar. Los objetos de tarea se manipulan con acciones fsicas, como pinchando o arrastrndolos, en lugar de tener que usar sintaxis complejas. Las operaciones suelen ser rpidas, incrementales y reversibles El usuario percibe que interacta con el dominio, ms que con un interfaz. El usuario gana en confianza Los novatos aprenden rpidamente la funcionalidad bsica PAUTAS Seleccionar cuidadosamente las metforas, que sean conocidas al usuario Crear representaciones visuales de las tareas Ofrecer acciones rpidas, incrementales y reversibles

Reemplazar el tecleo por la seleccin con apuntador o mejor, complementar, el teclado es ms rpido para usuarios expertos Presentar una estructura atractiva Hacer que el resultado de las acciones sea inmediato mediante retroalimentacin visual o de audio

6. Antropomrficas
Intentan interactuar con las personas igual que las personas lo hacen entre ellas Reconocimiento (voz, lenguaje natural, movimiento de ojos, seales biomtricas) Dificultad: separar seal de ruido Actualmente en investigacin: ver wereable computer

7. Combinacin de estilos
Es la mejor opcin Un estilo para cada tipo de tarea El usuario elige el que prefiere (como Autocad)

Gua/Directrices de diseo
ISO 13407 proceso de diseo de sistemas interactivos centrado en la persona Beneficios: Los sistemas son ms fciles de entender y usar Se reduce la incomodidad y el estrs Se mejora la satisfaccin del usuario Se mejora la productividad y la eficiencia Se mejora la calidad, la esttica Elementos esenciales: Involucracin activa de usuarios Entendimiento claro de usuarios Reparto correcto de funciones entre usuarios y tecnologa Iteracin de soluciones de diseo Perspectiva de diseo multidisciplinar

Guas de estilo
Una gua de estilo tpica incluye Descripcin de estilos de interaccin requeridos y controles de interfaz de usuario Directriz sobre cundo y cmo usar los distintos estilos y controles Ilustraciones de los estilos, controles y pantallas de ejemplo Gua de estilo corporativa Colores, tipografas, usos correctos e incorrectos de la marca Rellenos, espaciados

Principios de diseo
Simplicidad, Estructura, Consistencia, Tolerancia, Consistencia, Repeticin, Alineamiento, Proximidad Gestalt: proximidad, similitud, continuidad, simetra, visibilidad,...

Simplicidad
Mantener el interfaz lo ms simple posible: Usando el lenguaje del usuario: iconos, palabras, acciones, controles que le sean familiares, modelo mental usuario, metforas Dividir las tareas complejas en otras ms simples: recordar el diseo conceptual --> contenedores Pocos elementos, bien repartidos y estructurados La imagen define claramente de qu es la web Navegacin (qu podemos hacer en la web) clara

Consistencia
Uniformidad de apariencia, ubicacin y comportamiento Afecta de manera importante la usabilidad Para conseguirla es muy aconsejable usar una gua de estilo personalizada Otra posibilidad es reusar En Web, CSS Si la herramienta lo soporta, especializamos los controles: Microsoft WPF

Tolerancia
Evitar que el usuario cometa errores Hace falta el mensaje de error? Reducir las posibilidades: Mscaras. Campos numricos que slo admitan nmeros Cambiar input por selecciones (radio boxes, listas...) Valores por defecto (con cuidado), ejemplos de contestaciones vlidas Comprobar antes de salir del campo: Compromiso anticipacin error vs. Ritmo Recuperabilidad de errores Hacia delante: el sistema acepta el error y ayuda al usuario a conseguir el objetivo Hacia atrs: deshace los efectos de la accin errnea Ayudar a los usuarios a recuperarse de los errores. Deben ser comunicarse de forma positiva, constructiva, informativa, con mensajes centrados en el usuario: Mensajes de error con la informacin suficiente para corregirlos Si el usuario lo demanda, dar explicaciones adicionales durante la correccin del error No agredir al usuario con el lenguaje (escrito y visual) o Error fatal, violacin de acceso, error de integridad referencial o Dar la culpa del error al sistema, no al usuario Usar trminos especficos, constructivos: cambiamos el mensaje de error por una pregunta. Adems, que se identifique el error como de nuestro programa.

Accesibilidad
... el diseo de productos y entornos para ser usables por todo el mundo sin necesidad de adaptaciones especiales

7 PRINCIPIOS Affordance - (el diseo del objeto sugiere cmo se debe usar) Uso equitativo - til para distintas habilidades Flexibilidad de uso - se acomoda a un amplio rango de preferencias y habilidades Uso simple e intuitivo - fcil de usar y aprender Informacin perceptible - comunica con eficacia con independencia de las condiciones ambientales y capacidades sensoriales Tolerancia a errores - minimiza los peligros y las consecuencias adversas de acciones accidentales o no intencionadas Bajo esfuerzo fsico - minimiza la fatiga e incremente la comodidad de uso Directrices de accesibilidad de contenido Web de W3C, 14 principios generales de diseo accesible: 1. Ofrecer alternativas a contenido audiovisual 2. No basar todo en el color slo: texto y color se deben entender en escala de grises 3. Usar las etiquetas y las hojas de estilo correctamente: evitar etiquetas, HTML de presentacin. Usar etiquetas estructurales (h1, p...) 4. Clarificar el uso del lenguaje natural: facilitar la comprensin de los textos, sobre todo para texto en lengua extranjera o abreviaturas 5. Diseo lquido. Tablas y DIVs que se transformen bien para todos los navegadores 6. Preparar las pginas para que se sigan pudiendo leer con tecnologas deshabilitadas (p.ej. JS) 7. El usuario debe poder parar o pausar contenido que parpadee, se auto-actualice, haga scroll 8. Asegurar accesibilidad directa de UI embebidos 9. Disear para independencia de dispositivo 10. Usar soluciones no demasiado costosas de realizar para que los diseos funcionen con navegadores antiguos, o al menos, ofrecer alternativa 11. Usar las tecnologas y directrices de W3C, o al menos, ofrecer alternativa 12. Ofrecer informacin contextual que ayuden al usuario a entender elementos o pginas complejas 13. Proveer mecanismos de navegacin claros: el usuario debe poder encontrar rpidamente lo que busca en el sitio 14. Asegurar que los documentos son claros y simples

Tema 3 Introduccin a Software y DSLs

Introduccin al diseo de software
Causas de los proyecto fallidos/problemticos
Requisitos mal definidos o mal administrados Inconsistencias no detectadas entre los requisitos, el diseo y la implementacin Comunicacin ambigua o imprecisa Pruebas insuficientes Evaluacin subjetiva del avance del proyecto Propagacin de cambios sin control Bajo nivel de automatizacin

Diseo de software
El diseo es una visin de la solucin del problema que abstrae elementos ligados exclusivamente a la implementacin.

Modelado visual
Capturar la estructura y comportamiento del sistema y sus componentes. Mostrar cmo los elementos del sistema encajan entre ellos. Mantener la consistencia entre anlisis, diseo e implementacin. Promover la automatizacin (desarrollo dirigido por modelos).

Ventajas: Permiten capturar el diseo formalmente y de manera no ambigua. Los detalles pueden ser omitidos cuando sea necesario. Los diseos no ambiguos muestran las inconsistencias ms claramente. La calidad de la aplicacin comienza con un buen diseo. Las herramientas de modelado proporcionan mecanismos de automatizacin que aceleran el desarrollo.

Arquitectura temprana
Establece divisin en capas que proporciona una vista a grandes rasgos del sistema en funcin de sus necesidades de distribucin y una configuracin de los componentes que proporciona la estructura de la aplicacin y como se va a ubicar la funcionalidad. Representa tanto la estructura de los componentes como su comportamiento Captura los requisitos no funcionales como la usabilidad, escalabilidad, mantenibilidad, rendimiento, etc. Un desarrollo dirigido a componentes permite mejorar el reso (COTS) y adecuarse a plataformas distribuidas

Arquitectura de capas
Mdulos independientes, incluso en plataformas distintas. Interfaz usuario: Componente de IU, componente de proceso de usuario --> Lgica: Componentes de proceso --> Componentes de Entidad de Negocio --> Persistencia: Componentes de acceso a datos --> Datos de la aplicacin.

Componente de interfaz de usuario (CUI)

Ofrecen al usuario un mecanismo para interactuar con el sistema. Se encargan de procesar y validar la entrada y dar formato a la salida de datos. A partir de mockups, prototipos, alta fidelidad, etc.

Componente de proceso de usuario (CPU)

Facilita la sincronizacin y organizacin de las interacciones con el usuario Recibe las peticiones del usuario y las reenva en forma de llamadas a la lgica de negocio Contiene el flujo del proceso y la lgica de administracin de estado separndolo del cdigo de los elementos de la interfaz de usuario Los CPU obtienen su funcionalidad partiendo del modelo de navegacin o flujo y diagramas de contenido. Se encarga de exponer los mtodos de ms alto nivel que la lgica de negocio expone al cliente Permite independizar la funcionalidad ofertada de cmo est realizada la implementacin de los mtodos invocados Reduce el interfaz entre las capas del interfaz de usuario y la lgica de negocio implementando el patrn Faade [Gamma et al., 1995] que reduce el acoplamiento y mejora la mantenibilidad Contiene la lgica de negocio que involucra a procesos complejos donde intervienen ms de una entidad de negocio. Inicia y finaliza las transacciones de manera que las Entidades de Negocio y Componentes de Acceso a Datos estn dentro del contexto de una transaccin Puede contener la autorizacin para el acceso a determinada funcionalidad por parte del usuario

Componente de proceso

Componente de acceso a datos

Encapsulan la tecnologa de acceso a datos y la BBDD al resto de la aplicacin. Proporciona un interfaz sencillo que permite recuperar los datos de la BD y salvar una o ms entidades de negocio en la BD (mtodos CRUD) Los CADs tambin podran contener cierta lgica de negocio necesaria para realizar operaciones relacionadas con datos (consultas SQL)

Datos de la aplicacin
Representados y almacenados en uno o ms gestores de base de datos Su estructura puede ser jerrquica, relacional u orientada a objetos La estructuracin de dichos datos se obtiene mediante un entidad relacin (BDR) o un modelo de dominio (BDOO)

Diseo basado en lenguajes de dominio especfico (DSL)

Necesidad del modelado
Nivel de abstraccin alto. Permite arquitectura temprana. Permite paso a diseo y despus a implementacin mediante procesos automatizados.

Modelos de diseo
Representan de forma reducida un sistema. Ayudar a comprender un problema complejo (o solucin). Comunicar ideas acerca de un problema o solucin. Guiar la implementacin. Para detectar errores u omisiones en el diseo antes de comprometer recursos para la implementacin Para comunicarse con los stakeholders Para guiar la implementacin (ModelDriven Engineering). Utiliza un modelo para representar y obtener el cdigo final

Caractersticas: Abstracto: Enfatiza los elementos importantes y oculta los irrelevantes. Comprensible: Fcil de comprender por los observadores. Preciso: Representa de forma fiel el sistema que modela. Predictivo: Se pueden usar para deducir conclusiones sobre el sistema que modela. Barato: Mucho ms barato y sencillo de construir que el sistema que modela.

Metodologas MDE
Mejora la productividad (acelera el desarrollo del software) Mejora la mantenibilidad Reduce los errores al automa9zar parte o todo el cdigo obtenido Permiten especificar con mayor precisin el modelado de un dominio concreto Inconvenientes: o Supone una mayor curva de aprendizaje para los desarrolladores o Coste de las herramientas MDE Considerar: o Los modelos se centran en parte del problema proporcionan 50%-80% del cdigo. o El resto del cdigo mediante diagramas de componente/secuencia ms complejos. o Compatibilizar cdigo generado con el manual.

Modelado de dominio (DSL OOH4RIA)

Autogenerated y Password son tipos especiales de atributos. Relaciones: asociacin, agregacin. Generalizacin/especializacin. Agregacin y generalizacin forman jerarquas de clases. UML proporciona una escasa caracterizacin de la agregacin. Relacin con mnimos de 1 a 1 solo con composicin. Operaciones: Permite generar el cdigo de dicha operacin tanto a nivel de lgica de negocio, como su invocacin para su persistencia en BBDD.

Tema 4 Introduccin al Diseo Detallado

Patrones => calidad: mantenible, escalable, usable, eficiente, etc. Permiten reutilizar la experiencia de otros diseadores, y reducir el esfuerzo asociado a la produccin de sistemas ms efectivos y flexibles (ms adaptables al cambio). Soluciones exitosas y conocimiento de problemas en el desarrollo de software. Patrn: Presenta una solucin probada para un problema recurrente (no trivial) en un contexto concreto. Especifica una configuracin espacial de elementos y un comportamiento asociado a esta configuracin Provee un vocabulario comn y un concepto que permite la mejora del entendimiento entre expertos Mejora la calidad de la solucin del problema

Representacin
Contexto: Sita el entorno bajo el cual el patrn existe Problema: Describe que aspectos abordados por el desarrollador se realizan de forma insatisfactoria Fuerzas: Lista de razones y motivaciones que afectan al problema y justifican la aplicacin del patrn Solucin: Describe la solucin adoptada brevemente y los elementos de la solucin en 2 secciones. Estructura: Usa el diagrama de clases para mostrar la estructura bsica de la solucin Estrategia: Describe una de las posibles implementaciones del patrn en la tecnologa apropiada (en nuestro caso .NET)

Patrones GRASP
General Responsability Assigment Software Patterns La base de cmo se disear el sistema. Primeros momentos de diseo. Tras haber identificado los requisitos, y haber creado un modelo de dominio, se aaden operaciones a las clases, y define las secuencias de mensajes entre objetos para cubrir los requisitos. Hay principios fundamentales de diseo que deben ser tenidos en cuenta a la hora de: Decidir qu operaciones hay que asignar a qu clases Cmo los objetos deberan interactuar para dar respuesta a los casos de uso

Responsabilidad
Contrato u obligacin de un clasificador/clase. Responsabilidades relacionadas con obligaciones de una clase en cuanto a su comportamiento. Dos tipos: Conocer. Los datos privados encapsulados, objetos relacionados y las cosas que puede derivar o calcular. Hacer. Algo l mismo (crear objeto o clculo), iniciar una accin en otros objetos, controlar y coordinar actividades en otros objetos. Hay dos tipos de patrones GRASP. Vamos a ver los cinco BSICOS.

1. Experto en informacin
Problema: Cul es el principio general para asignar responsabilidades a las clases? Solucin: Asignar una responsabilidad a la clase (experto) que tiene la informacin necesaria para realizar la responsabilidad. Ventajas: Encapsulamiento de la informacin Distribucin del comportamiento del manejo de la informacin

2. Creador
Problema: Quin debera ser el responsable de la creacin de una nueva instancia de alguna clase? Solucin: B es un Creador de A si se asigna a la clase B la responsabilidad de crear una instancia de la clase A y si se cumple uno o ms de los casos siguientes: B agrega objetos de A; B contiene objetos de A; B registra instancias de objetos de A; B utiliza ms estrechamente objetos de A; B tiene los datos de inicializacin que se pasarn a un objeto de A cuando sea creado ( por lo tanto, B es un Experto con respecto a la creacin de A) El patrn Creador gua la asignacin de responsabilidades relacionadas con la creacin de objetos (una tarea muy comn). La intencin bsica del patrn es encontrar un creador que necesite conectarse al objeto creado en alguna situacin. Ventajas: Bajo acoplamiento logrando mayor mantenibilidad y reutilizacin. Desventajas: Puede ser muy compleja la operacin de creacin de instancia.

3. Bajo acoplamiento
Problema: Cmo podemos reducir las dependencias entre clases, reducir el impacto de los cambios e incrementar la reutilizacin? Solucin: Asignar las responsabilidades de manera que el acoplamiento permanezca bajo El acoplamiento es una medida de la fuerza con la que un objeto est conectado a, tiene conocimiento de, o confa en otros objetos Un objeto con bajo (o dbil) acoplamiento no depende demasiado de otros objetos. El patrn Bajo Acoplamiento es un principio a tener en mente en todas las decisiones de diseo. Es un principio evaluativo que debe aplicar un diseador mientras evala todas las decisiones de diseo. El bajo acoplamiento genera clases ms independientes. Ventajas: Se reducen los cambios en otras clases Fcil de entender de manera aislada Es conveniente para reutilizar componentes (o clases)

Ejemplos de posibles acoplamientos entre una clase A y una clase B: A tiene un dato miembro del tipo B (es decir, tiene una relacin navegable de asociacin, agregacin o composicin) Un objeto de la clase A invoca a una operacin de B Una operacin de A tiene un parmetro del tipo B Una operacin de A devuelve un valor de tipo B A es subclase directa o indirectamente de B

4. Alta cohesin
Problema: Cmo mantener una complejidad manejable? Solucin: Asignar las responsabilidades de manera que la cohesin permanezca alta. La cohesin es una medida de la fuerza con la que se relacionan y del grado de focalizacin de las responsabilidades de un elemento Una clase con baja cohesin hace muchas cosas que no estn relacionadas, o hace demasiado trabajo: Clases difciles de entender, reutilizar, mantener, delicadas ante cambios en otras clases. Sin embargo, una clase con alta cohesin tiene: Un nmero relativamente pequeo de operaciones, con funcionalidad altamente relacionada No realiza mucho trabajo Colabora con otros objetos para compartir el esfuerzo si la tarea es extensa Ventajas: Incrementa la claridad y facilita la comprensin del diseo Simplifica el mantenimiento y las mejoras Soporta a menudo el bajo acoplamiento Incrementa la reutilizacin

5. Controlador
Problema: Qu clase de la lgica de negocio debe ser el responsable de gestionar un evento que procede de la capa de cliente? Solucin 1: El controlador es un componente de negocio que representa a las clases de dominio. Sera el componente de IU donde residiran los procesos complejos. No son buenas las clases o los componentes de negocio que representan al dominio. Se crearan dependencias entre la interfaz y los componentes de lgica de negocio (aumenta el acoplamiento entre capas). No es conveniente que un objeto de interfaz maneje los procesos de la lgica de negocio (se reduce la cohesin de los componentes de interfaz de usuario). Solucin 2: Definimos una clase intermedia llamada Controlador que nicamente se encarga de recibir la peticin del interfaz y de reenviar las llamadas a los objetos de negocio.

En algunas ocasiones solamente reenviar la peticin a la lgica (operaciones simples), en otras ocasiones se definirn coreografas o una secuencia de llamadas (operaciones complejas) Tipos de controladores: Controlador de Fachada: representa una fachada global, o por dispositivo o por subsistema (controlador fachada) Controlador de casos de uso: o Contendr nicamente aquellos eventos que pertenecen a un caso de uso. Habiendo tantos controladores como casos de uso tenga cada usuario o Construccin artificial para dar soporte al sistema o Se utilizan cuando los Controladores de Fachada conducen a diseos con baja cohesin o alto acoplamiento

Patrones GOF
Un patrn de diseo son soluciones recurrentes a problemas de diseo detallado que puedes encontrar una y otra vez en el desarrollo de aplicaciones reales. Tres tipos: Creacionales, Estructurales, de Comportamiento.

Patrones Creacionales
Abstraen el proceso de instanciacin. Nos ayudan a independizar a un sistema de cmo sus objetos son creados. Tratan de ocultar a los objetos de sus mtodos concretos de creacin, de tal forma que al variar su implementacin, no se sea afectado el resto del sistema.

Son los siguientes: Abstract Factory: Nos da una interfaz para crear objetos de alguna familia, sin especificar la clase en concreto Builder: Separa la construccin de un objeto complejo, de su representacin. De esa manera, el mismo proceso de construccin puede crear diferentes resultados Factory Method: Se define una interfaz para crear objetos, como en el Abstract Factory, pero se delega a las subclases implementar la creacin en concreto Prototype: Mediante una instancia prototpica, conseguimos otras instancias de ese objeto Singleton: Nos consigue dar un solo objeto de la clase, en cualquier momento de la aplicacin PATRN SINGLETON Contexto: Necesitamos que algunos datos sean accesibles para todo el sistema. Y tambin necesitamos que esos datos sean nicos. Ej. Los datos de configuracin del sistema. Problema: Cmo hacer que la instancia de un objeto sea accesible globalmente y sea nica? Fuerzas: Hay lenguajes que soportan la existencia de variables globales pero hay otros que no Solucin: Permitir que otros objetos obtengan esa instancia, mediante la llamada a mtodos estticos de la clase Declarar el constructor como privado, para evitar la creacin de otros objetos

PATRN FACTORY METHOD Contexto: Existe siempre la necesidad de reducir el tiempo de desarrollo reutilizando partes del programa realizadas con anterioridad. Problema: Queremos estandarizar nuestra aplicacin para diferentes modelos de dominio (Ej. Agencia de viajes, comercio electrnico, etc.) permitiendo a los dominios individuales definir sus propias clases y proveerlas de su instanciacin. Solucin: Define una interfaz para crear los objetos de cada clase, que permita a las subclases decidir qu clase se va a instanciar (mtodo de factora). Factory Method permite a una clase diferir su instanciacin a las subclases Permite definir algoritmos genricos que trabajen con la clase raz de la jerarqua y es aplicable a cualquier tipo de subclase

Patrones Estructurales
Se ocupan de cmo las clases y los objetos se agrupan, para formar estructuras ms grandes Ofrecen modos efec0vos de utilizar mecanismos OO como herencia, agregacin y composicin para sa0sfacer requisitos par0culares (p.e. extensibilidad) Podemos nombrar al clsico patrn Composite, que permite agrupar varios objetos como si fueran uno solo, y tratar al objeto compuesto de una forma similar al simple

Tipos: Adapter: Permite conver0r una interfaz de una clase, en otra, que es la esperada por algn cliente Bridge: Desacopla una abstraccin de su implementacin en concreto. Luego, podemos cambiar la implementacin, o la abstraccin, sin cambiar la otra Composite: Compone objetos en una estructura de rbol, donde los objetos compuestos se tratan de forma similar a los objetos simples Decorator: Agrega responsabilidad a un objeto dinmicamente, dndonos una alternativa a la extensin de una clase, en lugar de usar subclases Faade: Provee una interfaz unificada a un conjunto de funciones de un subsistema. Es una interfaz de alto nivel, para facilitar el uso del subsistema Flyweight: Permite compar0r objetos, sin repetirlos en el sistema, eficientemente Proxy: Provee un subrogado a otro objeto, para controlar el acceso al mismo PATRN COMPOSITE Contexto: Existencia de objetos compuestos y componentes que deben ofrecer el mismo comportamiento. Problema: Necesidad de representar jerarquas todo/parte. Tanto el todo como la parte proporcionan la misma interfaz a los objetos cliente. Fuerzas: Si el componente y compuesto ofrecen la misma interfaz sugiere su pertenencia a la misma jerarqua de herencia. Eso permite que las operaciones sean heredadas y redefinidas de manera polimrfica. La necesidad de representar estructuras todo-parte sugiere la necesidad de una estructura de agregacin Solucin: Combinar jerarquas de agregacin y de herencia. El objeto compuesto manda mensajes a los componentes para el comportamiento comn, y ofrece operaciones adicionales para aadir/borrar componentes.

PATRN FAADE Contexto: Al dividir un sistema en capas se simplifica la complejidad del sistema pero a la vez se hace compleja la comunicacin ya que los clientes se deben comunicar con la correspondiente capa anexa de acuerdo al requisito. Un objetivo de diseo es minimizar la comunicacin y el acoplamiento entre las diferentes capas para reducir el trfico entre ellas (p.e. entre el interfaz de usuario y la lgica de negocio). Problema: Se requiere una interfaz comn unificada a partir de un conjunto heterogneo de interfaces, como la de una capa lgica Fuerzas: Proteger a los clientes de los componentes de la capa lgica. Esto permite reducir el nmero de objetos con el que el cliente trata y el subsistema es ms fcil de usar Promueve reducir el acoplamiento entre una capa y sus clientes. Esto permite variar los componentes del subsistema sin afectar a sus clientes Reduce la compilacin de dependencias, esto es vital en grandes sistemas de software. Solucin: El patrn Faade provee una interfaz unificada sencilla para una capa lgica o subsistema Este interfaz hace de intermediario entre el cliente y una interfaz o grupo de interfaces ms complejas pertenecientes a la capa lgica.

Patrones de conducta
Ms que describir objetos o clases, describen la comunicacin entre ellos. Frecuentemente, describen las colaboraciones entre distintos elementos, para conseguir un objetivo P.e. en .NET tenemos el System.Collec0on.IEnumerator, que implementan el patrn Iterator, una forma de recorrer una lista o coleccin independientemente de la estructura interna. Tipos: Command: Encapsula la llamada a un objeto, permi0endo el "undo" y el redo de la operacin Observer: Define una relacin uno a muchos, entre un objeto y otros que estn interesados en sus cambios, de nuevo, sin caer en el acople entre los mismos Iterator: Nos da un modo de acceder a los elementos de un objeto coleccin o similar, sin exponer su estructura interna Mediator: Permite la interaccin de varios objetos, sin generar acoples fuertes en esas relaciones Memento: Sin necesitar entrar en la estructura interna de un objeto, permite capturar su estado, para, por ejemplo, poder restaurarlo ms adelante State: Permite a un objeto cambiar su conducta cuando cambia su estado interno, simulando que cambia de clase Strategy: Define una familia de algoritmos, y los hace intercambiables Template Method: Define el esqueleto de una operacin, cuyas operaciones ms bsicas, quedan delegadas en subclases Visitor: Nos permite recorrer una estructura (un rbol, por ejemplo), aplicando una operacin a cada elemento Interpreter: Construye una representacin de la gram0ca de un lenguaje, junto con su intrprete

PATRN STATE Contexto: Un objeto puede tener un comportamiento complejo (distintas respuestas a un mismo mensaje) en funcin de su estado Problema: Como realizar un objeto que exhibe un comportamiento distinto cuando su estado interno cambia. Se necesita simular que el objeto cambia de clase en tiempo de ejecucin Fuerzas: El objeto presenta un comportamiento complejo que debera ser factorizado en elementos ms simples Una o ms operaciones tienen un comportamiento que vara en funcin del estado del objeto Se pueden definir operaciones distintas para cada estado, pero los objetos cliente necesitaran saber el estado del objeto para invocar la operacin concreta, lo cual incluira un acoplamiento elevado entre la clase cliente y la clase de invocada Solucin: Separar el comportamiento dependiente de estado del objeto original, y colocarlo en una serie de objetos, uno por cada estado. El objeto original llamado contexto delega la responsabilidad al objeto de estado apropiado Contexto se convierte en un agregado de sus estados, donde slo uno de ellos est activo en un momento dado. Los estados forman una jerarqua de herencia. La responsabilidad en las transiciones de estado puede recaer en el contexto o ser compartida entre las subclases de Estado PATRN COMMAND Contexto: El concepto de "orden" puede ser ambiguo y complejo en los sistemas actuales y al mismo tiempo muy extendido: intrpretes de rdenes (shell) del sistema operativo, macros de paquetes ofimticos, gestores de bases de datos, etc. Problema: A veces es necesario enviar pe0ciones a objetos sin saber nada de la operacin solicitada o de quien es el receptor de la peticin. Fuerzas: Permitir gestionar colas o registro de mensajes Soportar restaurar el estado a par0r de un momento dado (undo y redo) Ofrecer una interfaz comn que permita invocar las acciones de forma uniforme y extender el sistema con nuevas acciones de forma sencilla Solucin: Encapsular una peticin en un objeto, permitiendo as invocar a los clientes con diferentes peticiones, hacer colas o llevar un registro de las peticiones y poder deshacer las operaciones.

Tema 5 Diseo de la Lgica de Negocio y Capa de Datos

Diseo de la lgica de negocio
Lgica de negocio
Contiene las reglas de negocio en las que se va a basar nuestra aplicacin. Va a estar sujeta a continuos cambios, as que es necesario mantener un bajo acoplamiento entre la capa de negocio y el resto de capas. Aplicamos el patrn Domain Model de Mar0n Fowler (EAP, 2003), que propone representar la lgica de negocio como un conjunto de clases con datos y comportamiento que provienen del modelo de dominio.

Componente Entidad de Negocio

Un modelo de dominio contiene mltiples clases con relaciones y debemos decidir cmo mapear las clases en diferentes Componentes Entidad de Negocio (CEN), en ingls Business Objects (BO). Se debe identificar el ncleo de CENs que encapsularn la funcionalidad de la aplicacin (p.e. un solo CEN puede contener una agregacin o una jerarqua de herencia). IMPORTANTE Al no tener estado requieren que todas sus operaciones reciban el OID del objeto al cual queremos modicar, a excepcin de los mtodos de creacin y consulta. La comunicacin con el CAD se realiza mediante uno o ms objetos tipo EN o DTO que realizan la funcin de objeto de trasiego. La implementacin de los CEN debe ser independiente de si utilizan Nhibernate, EntityFramework o cualquier mapeo objeto-relacional. CEN vs EN Hablamos de CEN (Componente Entidad de Negocio o BO), cuando dicho componente representa a las entidades de dominio localizadas en la capa de lgica de negocio. Hablamos de EN (Entidad de Negocio) o DTO (Data Transfer Object) cuando es un componente que representa a las entidades de dominio que pueden almacenarse y transitar por diferentes capas. Los CEN requieren de lgica de negocio y de persistencia aunque esta puede contener el almacenamiento en BBDD mediante el CRUD (alta, baja, modificacin y consulta) o sin CRUD. Las EN pueden ofrecer lgica de forma opcional para que sea evaluada en la capa de cliente. Solo son obligatorios los atributos y las propiedades. IMPLEMENTACIN Se implementa un componente CEN por cada clase de dominio (o composicin o jerarqua de herencia) <-- cuidado con la perdida de cohesin! Existen diferentes tipos de CEN: Contienen atributos (y propiedades pblicas) y las operaciones de la clase de dominio Contienen exclusivamente las operaciones y separamos en una clase a parte los atributos y propiedades llamada EN o DTO (Patrn Object Value, Core J2EE, 2002).

Cada CEN referenciar a un Componente de Acceso a Datos (Patrn Data Access Object) que permite independizar la lgica de negocio de la persistencia. En lugar de referenciar directamente a la clase, lo har mediante la interfaz del CAD aplicando el patrn de Dependency Injection (Fowler, 2002). Los CEN con DTO separado no mantienen estado, en cada operacin se instancia el EN (que contiene el estado) y se opera sobre el mismo. Se mantiene as la necesidad de que las operaciones que trabajen sobre objeto/s reciban sus OID/s para trabajar.

Implementacin CEN de una clase (Ej. Producto) Cada CEN ser una clase cuyo nico atributo es el interfaz del CAD Se aplica el patrn de inyeccin de dependencia, recibiendo como parmetro el interfaz del CAD en el constructor, y bajando el acoplamiento con el CAD y permitiendo ser sustituido por un mock (elemento para realizar pruebas)

Modificar
Los atributos que provienen de las relaciones de asociacin (los roles) se modicarn o bien en la operacin crear o en los mtodos relationer y unrelationer.

Relationers
Se utilizan para asignar valor a los roles o los atributos de la clase derivados de las asociaciones Son obligatorios, en aquellas relaciones de asociacin donde en ambos lados la cardinalidad mnima es 0, y los objetos se crean sin estar relacionados. Si la cardinalidad mxima es *, entonces relationer permitir aadir objetos relacionados Si la cardinalidad mxima es 1, entonces relationer cambiar el objeto relacionado y lo sustituir por otro.

Unrelationers
Se utilizan para borrar el valor de los roles o los atributos de la clase derivados de las asociaciones. Si la cardinalidad mxima es *, entonces unrelationer permitir borrar una lista de objetos relacionados (quita tuplas de una tabla M:M o pone a null todas las claves ajenas que apunta hacia l). Si la cardinalidad mxima es 1, entonces unrela0oner quitar un solo objeto relacionado (le asignar valor null a una sola clave ajena).

Entidades de Negocio
El patrn Object Value establece que un objeto Entidad de Negocio se encarga de contener el estado del objeto (atributos y roles ) y los mtodos que permiten acceder a dicho estado (propiedades). Las EN pueden estar el diferentes capas y permiten mltiples tipos de representaciones orientadas a objetos o a datos. Pueden ser serializables lo que permite que se enven a travs de la red o sean almacenadas Las EN no inician transacciones

Tipos de representaciones de los EN: XML: Se usa una cadena XML o un objeto XML DOM (Document Object Model). XML es un formato abierto y flexible que puede ser usado para integrar diversos tipos de aplicaciones. DataSet: representa la estructura de tablas y relaciones de cualquier BBDD relacional. DataSet tipado: clase que hereda del DataSet de ADO.NET que proporciona mtodos fuertemente tipados asociados a una BBDD concreta. Clase Personalizada: se define una clase por cada entidad de dominio. Contiene los atributos y propiedades para exponer la informacin a la aplicacin cliente. Representan las relaciones de asociacin (incluidas sus subtipos agregacin y composicin) y las de herencia (el CEN NO!!). No contiene los mtodos CRUD para invocar a los CAD, sino que es el CEN quien lo hace.

Relaciones de Asociacin
La diferencia a nivel de asociacin, con composicin no se refleja a nivel de EN ya que todas las relaciones se representan con atributos (roles) tipo EN a otras clases. Cuidado con la navegabilidad, si una relacin no es navegable en un sentido, no se genera ni el rol ni la propiedad en el EN. No definas EN separadas para representar relaciones muchos-a-muchos. Estas relaciones pueden ser implementadas mediante Listas (List<EN>) en los EN implicados.

Representando una EN con XML

Ventajas: Utilizacin de un estndar de la W3C para la representacin de datos Flexibilidad. XML permite representar jerarquas y colecciones de informacin Interoperabilidad. XML es una opcin ideal para intercambiar informacin con sistemas legados (externos), socios comerciales, de forma independiente de plataforma. Desventajas: La correctitud del tipo no es preservada en XML La validacin de un XML es lenta No permite el uso de campos privados Requiere de un proceso complejo para su ordenacin

Modelo de ejecucin de una operacin

Se pretende unificar la forma de plasmar las operaciones de dominio en la implementacin. Nos basamos en el diseo dirigido por contrato para definir las operaciones (Meyer, 1992). Se deben de cumplir las precondiciones y postcondiciones antes y despus del cuerpo de las operaciones.

Diseo dirigido por contrato

Los contratos de software se especican mediante la utilizacin de expresiones lgicas denominadas aserciones. Dichas aserciones siempre deben cumplirse para poder ejecutar una operacin. Existen 2 tipos de aserciones: Precondiciones: Asegura que se cumple un determinado estado de partida para ejecutar la operacin.

Postcondiciones: Verica que el trabajo realizado por la operacin se ha cumplido correctamente. Su incumplimiento invlida totalmente el software, indicando que existen un error en la operacin (se lanza una excepcin).

Diseo de componentes de acceso a datos

Los Componentes de Acceso a Datos (CADs) encapsulan la tecnologa de acceso a datos y la BD al resto de la aplicacin (Patrn DAO). Proporciona un interfaz sencillo que permite recuperar los datos de la BD y salvar una o ms entidades de negocio en la BD (mtodos CRUD). Los CADs tambin podran contener cierta lgica de negocio necesaria para realizar operaciones relacionadas con datos (consultas con filtros)

Para cada CEN, definimos un CAD que ser definido como sigue: ClienteCAD: Esta clase provee los servicios para recuperar y modificar los datos de las tablas Cliente PedidoCAD: Esta clase provee los servicios para recuperar y modificar los datos de las tablas Pedido y LineaPedido ProductoCAD: Esta clase provee los servicios para recuperar y modificar los datos de la tabla Producto CategoraCAD:Esta clase provee los servicios para recuperar y modificar los datos de la tabla Categoria

Mapeo Objecto - Relacional

Definir todos los mtodos que devuelven un tipo concreto de Entidad de Negocio en un solo CAD (mantener una Alta cohesin!) Por ejemplo, si se estn recuperando todos los pedidos de un determinado cliente, implementar la funcin en PedidoCAD llamada DamePedidosPorCliente que devuelva los pedidos filtrando por un idCliente Contrariamente, si ests recuperando todos los clientes que han realizado un pedido especfico, implementa la funcin en ClienteCAD DameClientesPorPedido Se han de mantener las relaciones de asociacin mediante mtodos de modificacin, creacin y borrado de relaciones. Relaciones 1 a muchos, 1 a 1, requieren de mtodos de update en la BBDD. Relaciones muchos a muchos requieren de mtodos de aadir y borrar relaciones en una tabla intermedia.

Implementacin de los CAD

Un CAD es utilizado sin estado, es decir, todos los mensajes intercambiados pueden ser interpretados independientemente, sin almacenar datos entre llamadas. Sin embargo, cuando la transaccin se define en el Componente de Proceso, esta se mantiene a lo largo de diferentes llamadas al CAD. Uno de los principales objetivos de un CAD es encapsular o esconder la idiosincrasia de la invocacin y el formato de la BD a la lgica de negocio.

Operaciones de CAD
Un CAD debe proveer los mtodos para realizar las siguientes tareas sobre la BD: Crear registros en la BD Leer registros en la BD y devolver las entidades de negocio al componente invocante Actualizar registros en la BD, usando entidades de negocio proporcionadas por el componente invocante Borrar registros de la BD Estos mtodos son llamados CRUD, acrnimo de Create, Read, Update and Delete Los CAD pueden contener tambin mtodos que realizan algn filtro. Por ejemplo, un CAD puede tener un mtodo para encontrar el producto ms vendido en un catlogo durante un mes. Un CAD accede a una nica BD y encapsula las operaciones relacionadas con una nica tabla o un grupo de tablas vinculadas de la BD. Por ejemplo, podris definir un CAD que controle las tablas de Cliente y ClienteVIP (herencia), y otro CAD que controle los Pedidos y las LineasDePedido (composicin)

CADs con NHibernate

Framework Object-Relational Mapping (ORM) Permite simplificar el almacenamiento y recuperacin de los objetos en la BBDD Simplifica el cdigo de los CADs reduciendo las operaciones ofertadas al mnimo Las navegaciones por rol y herencia, y su almacenamiento son realizadas de forma implicita por el propio framework Permite sustituir el cdigo SQL orientado a datos dependiente del gestor y utilizar el lenguaje HQL (Object-Oriented) Nhibernate solo crea las tablas as que nosotros debemos crear la BBDD y el schema primero (createDB.cs)

Mapping XML Hibernate

Se establece un mapeo entre la en0dad de negocio (EN) y una tabla de la BBDD Cada atributo se mapea a una columna Cada relacin de asociacin se mapea a una relacin de tablas (en funcin de cada tipo, se har de una forma u otra) Cada relacin de herencia tambin se convierte en una relacin de asociacin (existen 3 estrategias)

Mapping Uno a Muchos: Introducimos borrado en cascada solo en las relaciones de composicin En los otros casos (asociacin y agregacin) daremos un error al intentar borrar el objeto (de la parte uno) que todava tenga relaciones con la parte muchos Mapping Uno a Uno: Se introduce el unique=true para forzar el one-to-one. Mapping Muchos a Muchos: Cada subclase tiene una clave ajena a la clase padre. Equivale a un mapping one-to-one.

Aspectos de Arquitectura
Actualmente Nhibernate se configura con la estrategia lazy fetching, es decir, se trae el objeto y sus relaciones bajo demanda Solamente cuando tengamos una Session abierta de Nhibernate podramos tener una lacy fetching, es decir, llama a BBDD cada vez que navega una relacin La alternativa es poner lazy-fetching=false, y se trae el objeto y sus relaciones (hasta 3 niveles). Pero es menos eficiente

Hibernate Query Language

Utiliza createQuery como mecanismo de bsqueda. Dos tipos de asociacin: Implcita: En la sentencia no se usa la palabra JOIN si la relacin est presente en el objeto. Explicita: Hay 3 tipos de JOIN (inner, left, right). Herencia con HQL Tenemos una jerarqua de Usuario del que heredan Administrador y UsuarioWeb. Una consulta como esta: from Usuario as usu Devuelve no solo instancias de Usuario, sino tambin de sus subclases Administrador y UsuarioWeb. Las consultas HQL pueden referenciar cualquier entidad (EN o DTO) o interfaz en la clusula from. Las consultas devolvern instancias de las clases persistentes que extiendan de dicha clase o implementen su interfaz. La propiedad especial class accede al valor discriminador de una instancia en el caso de la persistencia polimrfica. Siguiendo el ejemplo del caso anterior, podemos indicar en la clusula where que queremos solo las instancias de un determinado subtipo: From Usuario usu where usu.class = UsuarioWeb

CAD con procedimientos almacenados

Los CADs pueden invocar a procedimientos almacenados para realizar tareas complejas contra la BD. Ventajas: Mejora del rendimiento al almacenarse el plan de acceso y cachearse Reduce el trfico al reducirse el nmero de invocaciones SQL Desventajas: Incrementa la carga del servidor de BD que es menos escalable que la capa de Lgica de Negocio Escribir un procedimiento almacenado en T-SQL es una tarea muy especializada y es poco portable

Tema 6 Diseo de los Componentes de Proceso

Una aplicacin realiza un proceso de negocio que puede constar de una o varias tareas. Cuando existen tareas complejas que requieren de varios pasos se necesita de un mecanismo para organizar y almacenar el estado hasta que el proceso se haya completado El Componente de Proceso (CP) se encarga de exponer al interfaz de usuario los mtodos de mayor nivel de la lgica de negocio. Permite independizar la funcionalidad ofertada de cmo y dnde est realizada la implementacin de los mtodos invocados. Un CP contiene la lgica de negocio que involucra a procesos complejos a diferencia del CEN que contiene la lgica de procesos simples (o locales a una entidad). Inicia y finaliza las transacciones de manera que los Componentes Entidad de Negocio y Componentes de Acceso a Datos estn dentro del contexto estos servicios. Si deseamos que se ejecuten dichos componentes en diferentes mquinas en .NET pueden implementarse con: COM+ 1.5,Windows Communication Fundation (WCF),.NET Remoting Existen bsicamente 2 alternativas: Definir un componente de proceso por cada entidad de negocio de manera que encapsulamos tanto operaciones simples como complejas (patrn Session Faade). Definir nicamente un componente de proceso para las operaciones complejas delegando a los CEN las operaciones simples (patrn Application Faade). 1 ESTRATEGIA: CP COMO SESSION FAADE Session Faade (Core J2EE, 2001) tienen la responsabilidad de definir las transacciones y adems se le incorpora la responsabilidad de la distribucin. Permite realizar una distribucin de los componentes de proceso de forma individual permitiendo as un mayor balanceo de carga y escalabilidad. Requerido en aplicaciones con lgica de negocio complejas. Ventajas: Mayor escalabilidad soportando la distribucin a nivel de componente. Soporta transacciones distribuidas en diferentes fuentes de datos. Desventajas: Mayor acoplamiento en las responsabilidades de distribucin y transaccionalidad (reduce el reuso) Introduce mayor retardo en las llamadas distribuidas entre componentes reduciendo el rendimiento en operaciones simples 2 ESTRATEGIA: CP COMO APPLICATION FAADE El CP tiene la responsabilidad nicamente de la transaccionalidad delegando en un componente Application Faade la distribucin. Se define un CP para cada operacin compleja y las operaciones simples son realizadas en el CEN.

Este CP se caracteriza por: Iniciar y terminar las transacciones entre las diferentes entidades Permite reutilizar la lgica de negocio de dichos componentes de proceso por diferentes fachadas de negocio No interviene si se requiere directamente a una operacin simple, solo las invoca desde una operacin complejaNo permite distribuir la lgica de negocio entre diferentes BBDD Ventajas: Reduccin del cdigo al solo poner en el CP las operaciones complejas Permite una mayor reutilizacin de los CPs para diferentes fachadas al separar la distribucin de la transaccionalidad Desventajas: La granularidad de la distribucin se eleva a nivel de capa (ms acomplamiento funcional) Menos posibilidades de balancear la carga

Transaccin
Una transaccin es un conjunto de operaciones realizadas en una nica unidad de trabajo Su ejecucin de forma atmica asegura la consistencia y fiabilidad del sistema Todas las operaciones de transaccin han de ser completadas con xito para que su ejecucin se materialice. Si todo ha ido bien: Commit. Se materializan los cambios realizados por todas las invocaciones Si ha habido algn error: Rollback. Deshacen todos los cambios realizados desde el inicio de la transaccin

TIPOS
Existen tres modos de implementarlas en .NET: Utilizando procedimientos almacenados Transacciones manuales con ADO.NET (incluido frameworks como Nhibernate o Enterprise Library) Transacciones automticas con un Monitor transaccional (p.e. COM+ o WCF)

1. Procedimiento almacenado
Transaccin manual escrita en el T-SQL (SQLServer) encapsula las operaciones dentro de BEGIN TRANSACTION y COMMIT/ROLLBACK TRANSACTION Solo permite lanzar transacciones de forma local a un gestor de BBDD. Se obtiene un excelente rendimiento permitiendo lanzar una transaccin compleja con solo una invocacin al gestor Ventajas: Alto rendimiento al ser local al gestor y solo requerir una llamada a la BBDD Proporciona flexibilidad para explicitar el mbito de la transaccin Desventajas: Aprender Transact-SQL o el lenguaje del gestor, aumenta la curva de aprendizaje Poco portable ya que el cdigo es dependiente del gestor

La escalabilidad est limitada por los servidores de datos

2. Manuales con ADO.NET

ADO.NET proporciona un objeto transaccin (SQLTransaction) usado para comenzar la transaccin y para controlar explcitamente si debe hacerse commit o rollback. Dicho objeto est ligado a una conexin de BBDD, as que en nuestra arquitectura se ha de implementar en una clase CAD (repaso tema 3). Ventajas: Fciles de programar Flexibilidad para controlar la transaccin con instrucciones explcitas Soluciones como NHibernate permiten mantener en el CP el mbito de dichas transacciones Desventajas: Necesita ms invocaciones al gestor que en el procedimiento almacenado Solo admite transacciones en un nico gestor de BBDD Optamos por esta segunda estrategia cuando las aplicaciones tienen una lgica de negocio sencilla. Para ello los CP son clases de librera que invocan a los CEN, y que inician las sesiones y transacciones de Nhibernate Permite el lazy feching = true en cada entidad EN, ya que en este contexto podemos mantener una sesin durante todas las llamadas de la operacin.

Solucin con NHibernate

Los CPs heredan de basicCP.cs que tiene el atributo booleano sessionStarted indicando si se ha iniciado la sesin o no Adems se implementan los mtodos SessionInicializeTransation, SessionCommit y SessionRollback Permite crear o no una transaccin en un CP Permite que un CP llame a otro CP y se conserve la misma session y transaccin de NHibernate

Definimos un CP por cada clase de dominio que tenga operaciones complejas. La clase CP debe heredar de BasicCP debe tener 2 constructores que llamen al padre: Constructor vaco que crea una nueva sesin Constructor que conserva la sesin y se utiliza para ser invocado desde otro CP Aspectos importantes: Los CADs deben recibir en el constructor el objeto session de los CPs Los CEN deben recibir en el constructor al objeto CAD Basic CP: SessionCommit, SessionRollback y SessionClose, solo actan cuando la sesin se ha iniciado en el mismo CP. Invocacin CP a CP: Un CP puede invocar a una operacin de otro CP o de l mismo. Permitiendo as la composicin de operaciones complejas. En caso de que se invoque a una operacin de otro CP se invocar al constructor del CP pasndole la sesin

Invocacin operacin a otra del mismo CP: Cuando ambas operaciones pertenezcan al mismo componente de proceso, debemos tener en cuenta poner las variables del CP (sessionStarted) para que no inicie ni finalice la transaccin en la operacin invocada

Patrn Data Transfer Object

Contexto: Has diseado tu aplicacin distribuida, y para satisfacer un requisito del cliente, te encuentras realizando mltiples llamadas a objetos remotos. Demasiadas invocaciones remotas incrementan el tiempo de respuesta de tu aplicacin ms all de los niveles aceptables Problema: Cmo preservamos en una aplicacin distribuida la semntica de acceso a los atributos sencillos de un objeto sin estar sujetos a las latencias inherentes de la comunicacin remota? Fuerzas: Las llamadas remotas son lentas Si la latencia (tiempo que tarda el primer byte en llegar al destino) es mucho mayor (100 veces) que el throughtput (bytes/tiempo). Puede llevar casi el mismo tiempo enviar 10 bytes que 1000 bytes La encapsulacin nos lleva a definir mtodos de grano fino que acceden a un nico atributo de la clase. Esto implica un alto nmero de invocaciones a los mtodos del objeto Solucin: Creamos un objeto de transferencia de datos (DTO) que contenga todos los datos requeridos en una sola invocacin remota Modificamos el interfaz del servidor para que tenga el DTO como parmetro de salida El cliente almacena una copia del DTO recibido y realiza un conjunto de invocaciones de forma local para recuperar los datos ms detallados. Cuando diseamos un DTO tenemos dos opciones: Usar una clase y coleccin genrica para todas las entidades de negocio Crear una clase personalizada con getters y setters explcitos por cada entidad

DTO Genrico
Ventajas: Solo necesitas una dos clases (instancia, coleccin) para toda la aplicacin El propio lenguaje te proporciona las clases coleccin (ArrayList, Hashtable, etc.) Puedes hacer componentes de interfaz genricos (Datagrid para cualquier entidad) Desventajas: Dbilmente tipado, pueden producirse errores en el acceso desde el cliente en tiempo de ejecucin

DTP Personalizado
Se define una clase personalizada para cada clase del dominio, una Entidad de negocio con solo atributos y propiedades Ventajas: Fuertemente tipado lo que permite detectar los errores en tiempo de compilacin Soporte en la escritura del cdigo con la utilizacin del IntelliSense Desventajas: Se incrementa la programacin de un alto nmero de clases (utilizar generacin automtica)

Mejor solucin de DTO

Patron Assembler [Fowler2003] Una clase assembler permite crear un objeto DTO desde un objeto de dominio y viceversa. Ventajas: Se consigue desacoplar DTO de las clases del dominio Permite que se pueda reutilizar los DTOs para ms de un sistema NOTA: Estamos obligados si queremos distribuirlo ya que los EN de Nhibernate no son serializables y no pueden enviarse por la red.

Clase personalizada como DTO

Se define un DTO para representar cada entidad de negocio, que contenga solo atributos y propiedades Recomendaciones: Definirlo en un proyecto de biblioteca para que pueda usarse tanto en la capa de interfaz como en el cliente. Para representar colecciones genricas debemos usar clases de System.Collections como ArrayList, List cuyos objetos sean otra clase DTO personalizada. Ventajas: Conversin directa con las Entidad de Negocio Mayor eficiencia para consultas sencillas Inconvenientes: Mapping Objeto-Relacional en el CAD desde el DataReader (pero no necesario con Nhibernate) Menor compatibilidad con los controles de Interfaz de usuario

Tema 7 Patrones IU
Diseo de interfaz de usuario 1
--- Windows Presentation Foundation 1 Parte --Est basado en la tecnologa DirectX (a diferencia de los predecesores en C++). Caractersticas Principales: Separacin de la parte del diseador en un formato de etiquetas (XAML) del resto del cdigo de presentacin (Code-behind) Permite la inclusin de componentes multimedia, animacin, grficos 2D y 3D, e incluso pginas Web Incluye enlace de datos (data binding) de muchos controles y sus propiedades Introduce caractersticas de accesibilidad e internacionalizacin Permite separar el diseo en un fichero XML separado (al estilo CSS) permitiendo estrategias de jerarquas de estilos

XAML y Code-Behind
Una mejora evidente es la capacidad para programar una aplicacin mediante cdigo de lenguaje marcado (XML) y separado de cdigo subyacente (C#), una experiencia similar a las aplicaciones Web. Esta separacin de responsabilidades permite que personas o herramientas encargadas del diseo se enfoquen en el lenguaje de marcado XAML, donde se representa el aspecto de IU. Las personas con un perfil de programacin se encargan del codebehind donde se encuentra la definicin del comportamiento de la IU, es decir, eventos y llamadas a otras capas. XAML: es un lenguaje de marcado basado en XML que se utiliza para implementar la apariencia de una aplicacin de forma declarativa, en una jerarqua de elementos anidados que se denomina rbol de elementos. Se suele utilizar para crear ventanas, cuadros de dilogo, pginas y controles de usuario, as como para rellenarlos con controles, formas y grficos. Permite tambin asociar los controles con los datos mediante el mecanismo declarativo de databinding (enlace de datos Code-Behind: El comportamiento de una Interfaz de Usuario es implementar la funcionalidad que responde a las interacciones con el usuario, lo que incluye controlar los eventos (por ejemplo, hacer clic en un men, en una barra de herramientas o un botn) y llamar, en respuesta, a la lgica de negocio. En WPF, este comportamiento se suele implementar en cdigo asociado al marcado. Este tipo de cdigo se denomina subyacente (en ingls, codebehind)

Se genera una clase que hereda de Window o Page por cada XAML. La clase tiene un constructor donde se inicializa la visualizacin de los componentes y un conjunto de mtodos y eventos donde se define la parte dinmica.

Controles WPF
Un "control" es un trmino general que se aplica a una categora de clases de WPF hospedadas en una ventana o una pgina, tienen una interfaz de usuario (IU) e implementa un comportamiento determinado. Existen bsicamente 2 tipos de controles: Bsicos: que no pueden contener a ms de un elemento (button, label, textbox, etc.) Complejos: Que con0enen a una coleccin de elementos (paneles, datagrid, listview, etc.)

Fichero aplicacin
Es un archivo XAML llamado app.xml que define un espacio de recursos y una ejecucin inicial (app.xml.cs) para una aplicacin WPF. Por ejemplo, podemos situar el estilo de la aplicacin WPF Se utiliza este archivo para especificar la ventana que se muestra automticamente cuando se inicia la aplicacin (p.e. MainWindow.xaml)

Estilos de controles
Es habitual que todos los elementos del mismo tipo de una interfaz de usuario presenten la misma apariencia. WPF define mediante el elemento style que permiten la reutilizacin de las distintas apariencias en diversos elementos (controles o datos) Los estilos se definen como recursos, dentro de las pginas, ventanas o a nivel de toda la aplicacin en el App.xml Agregamos los estilos al fichero App.xml, dentro del elemento Application.Resources

--- Patrones de interfaz de usuario 1 Parte --Model View Controller

Contexto: El propsito de muchas aplicaciones empresariales consiste en recuperar datos almacenados, modificarlos y finalmente persistir dichos cambios. El flujo principal se encuentra entre la lgica de negocio y el interfaz de usuario Muchas veces se unen las capas para reducir la cantidad de cdigo y mejorar el rendimiento Esto trae consigo problemas como: Alto acoplamiento, ya que el interfaz cambia con ms frecuencia que la lgica de negocio Baja cohesin, el cdigo del interfaz se hace muy complejo al contener lgica de negocio junto a la lgica de presentacin Problema: Cmo se dividira la funcionalidad de la aplicacin para que se pueda fcilmente mantener IU y la lgica de negocio por separado? Fuerzas: Disear el aspecto de las IU se requiere unas habilidades diferentes y personas diferentes al desarrollo de la lgica de negocio. El cdigo de interfaz de usuario tiende a ser ms dependiente de dispositivo que la lgica de negocio. P.e. si queremos migrar nuestra aplicacin WPF para Web, Tablet o mvil, debemos remplazar principalmente cdigo de IU y no tanto de lgica de negocio.

Una clara separacin de las dos partes acelera la migracin y minimiza el cdigo de la lgica de negocio al no haber duplicidad Solucin: El patrn Model-View-Controller (MVC) separa la lgica, la presentacin, y las acciones basadas en la entrada del usuario en tres partes separadas: Model (Modelo): El modelo controla el comportamiento y los datos del dominio de la aplicacin, responde las peticiones para la informacin sobre su estado (normalmente de la vista) y responde a las instrucciones de cambio de estado (usualmente del controlador). View (Vista): La vista maneja la informacin de pantalla Controller (Controlador): El controlador interpreta las entradas de teclado y ratn del usuario, informa al modelo y/o la vista para realizar la accin apropiada

Es importante remarcar: View y Controller dependen de Model, pero Model no depende de ninguno. Esto es una la clave de la separacin y permite a Model ser implementado y probado de forma independiente a la presentacin. La separacin entre vista y controlador aqu es secundaria. En los WindowsForm aparecen unidos, pero en las aplicaciones WPF, View es la parte que se define con el XAML mientras que el controlador es el cdigo (c#) que maneja los eventos (code-behind) 2 aspectos a destacar: La herramienta Visual Studio .NET en su aproximacin WebForm y WPF nos gua para que utilicemos el MVC El Model mostrado est implementado por el componente fachada de aplicacin (CFA) (sea local o remoto) Pero el componente Model podra ser directamente un componente CEN o CP.

Master Template
Contexto: Se decide usar el patrn MVC para separar los componentes del interfaz y de la lgica de negocio. El MVC con la herramienta VS .NET es fcil de crear, pero est introduciendo una serie de desventajas cuando la aplicacin nos crece. Vista y controlador tienen una relacin 1 a 1. Existe mucho cdigo comn en diferentes pginas, lo que puede llevar a cdigo duplicado.

Problema: Cul es la mejor estructura del controlador para aplicaciones moderadamente complejas, y donde deseamos alcanzar el reso y la flexibilidad evitando la duplicacin? Fuerzas: El cdigo que contienen la mayora de las pginas o formularios tiene muchos pasos similares: extraer los parmetros de la pgina, recuperar datos del usuario logueado, aadir cabeceras y pies. Esto conduce a un incremento significativo de duplicacin de cdigo. La apariencia y navegacin comunes tienden a mejorar la usabilidad y el reconocimiento de la aplicacin. Sin embargo, conducen a la repeticin de cdigo de presentacin. Es necesaria una mejora en el reuso de la lgica de presentacin a travs de las pantallas de IU. Basado en el patrn Master Template definido por Jim Conallen (2003). Originariamente definido para Web. Master Template permite crear una apariencia consistente para todas las pginas de una aplicacin. Una nica plantilla establece la apariencia (cabecera, pie, contenido, etc.) y la funcionalidad comn que deseas para las pginas. La pgina principal (una window) contiene los fragmentos comunes para todas las pginas Dicha pgina contiene las referencias a las partes dinmicas mediante Frames (Cabecera, Menu, Contenido, Pie, etc.). Cada una de las pginas especficas ser a su vez una page de XAML, y tendr su propio controlador. El controlador de la pgina maestra (window) define las tareas comunes a todas las pginas.

Creamos una pgina XAML (Page): No es una pgina completa sino que nicamente va a representar un fragmento de pgina Sin embargo, va tener un controlador asociado como cualquier pagina Ventajas: La divisin de las diferentes partes permite reducir el cdigo duplicado, y dejar la parte comn en la window (Vease un men en la cabecera, un pie de notificaciones, etc.). Queda el cdigo mucho ms estructurado en las vistas. Desventajas: La comunicacin entre la Window y sus Pages, y sobre todo la comunicacin entre diferentes pages. Se requiere el paso de parmetros por constructor o propiedad entre diferentes pages.

Model View Presenter

Contexto En el MVC el controlador se encarga de gestionar los eventos el usuario, modificar los componentes de interfaz y llamar al modelo en respuesta de dichos eventos En el MVC controlador se encuentra muy ligado con las vistas que gestiona, dificultando su reutilizacin para diferentes vistas El controlador del MVC es difcil de mantener al no poderse probar separadamente del interfaz de usuario Problema: Cmo proveemos de una separacin en el Interfaz de Usuario que facilite la reutilizacin del controlador, permita realizarle pruebas y mejore la separacin IU y Lgica? Fuerzas: Deseamos que las vistas puedan ser testeadas mediantes tcnicas de automatizacin de pruebas Deseamos compartir cdigo del controlador entre pantallas (incluso de diferente tecnologa) que requieren el mismo comportamiento Aumentar la separacin entre el interfaz y la lgica de negocio (View y Model) permite hacer el cdigo ms fcil de mantener Solucin: Separar las responsabilidades de la visualizacin del IU y la gestin de eventos en diferentes clases, llamadas respectivamente View y Presenter La clase View gestiona los controles en la pgina, captura los eventos y redirige las peticiones a la clase Presenter (View sera el XAML y el code-behind) El presenter contiene la lgica que responde a las peticiones de la vista (carga y modificacin de datos), actualiza el modelo, y a su vez, manipula el estado de la vista. Para facilitar las pruebas del Presenter, hacemos que este mantenga una referencia a un interfaz de la Vista que permita cambiar su estado. Facilitando el remplazo de la vista por otra tecnologa, o por mock, permitiendo as realizar tests funcionales (Patrn Dependency Injection) El Presenter puede comunicarse con la vista y con el modelo, pero la vista es completamente independiente del modelo (a diferencia del patrn MVC) Estrategia: Implementamos el mismo ejemplo Petstore utilizado en los patrones anteriores. La aplicacin comienza eligiendo la categora y consultando sus productos relacionados MVP se combina con Master Template, definiendo un Presenter para la pgina principal y uno para cada pgina contenido

Interfaz de la Vista: Se definen las propiedades que la vista expone al Presenter para que este lo actualice. Presenter: Referencia a un interfaz de la vista, y contiene los mtodos que inicializan la vista, y la modifican. View: El Code-Behind debe implementar la interfaz definida, y referenciar al presenter que modificar su estado. Alternativas de Implementacin: Si utilizamos el patrn Observer, podemos descoplar la Vista y el Presenter para mejorar su reuso, pero perdemos un poco de trazabilidad Podemos hacer que el Presenter invoque a la Vista mediante eventos, para ello se debe definir un eventHandler en el Presenter en el que se incluyan los eventos de la vista a invocar El Presenter invoca al View mediante eventos para realizar tareas como la navegacin. En el Presenter definimos el manejador de eventos ObtenerProductos que en caso de ser lanzado invocar al evento publicado en el View. Ventajas: Desacopla completamente la View del Model Permite la automatizacin de las pruebas del presenter Desventajas: No provee un mecanismo para unificar el flujo del data binding como hace el Model-view Viewmodel

Diseo de interfaz de usuario 2

--- Windows Presentation Foundation 2 Parte --Enlace de datos (Data Binding)
El enlace de datos es el proceso que establece una conexin entre la UI de la aplicacin y los datos Si el enlace est correctamente configurado y los datos proporcionan las notificaciones adecuadas, cuando los datos cambian su valor, los elementos que estn enlazados a ellos reflejan los cambios automticamente. Los objetos ContentControl como Button y los objetos ItemsControl como ListBox y ListView 0enen funciones integradas que permiten definir de forma flexible elementos de datos individuales o colecciones de elementos de datos

Independientemente del elemento que se vaya a enlazar y de la naturaleza del origen de datos, cada enlace sigue siempre el modelo que se muestra en la ilustracin siguiente:

Elementos del enlace de datos

Normalmente, cada enlace 0ene estos cuatro componentes: 1. un objeto de destino del enlace 2. una propiedad de destino 3. un origen del enlace 4. y una ruta de acceso al valor en el origen del enlace que se va a usar. Por ejemplo, si desea enlazar el contenido de TextBox a la propiedad Nombre de un objeto Empleado: Su objeto de destino es TextBox, la propiedad de destino es la propiedad Text, el valor que se va a utilizar es Nombre y el objeto de origen es el objeto Empleado.

Tipos de enlace
Oneway (predeterminado): el widget se actualiza siempre que cambie el valor en la propiedad origen. Se utiliza con controles de solo lectura Onetime: el widget (objeto destino) obtiene el valor solo en su inicializacin, es decir, la primera vez que se carga la pgina Twoway: permite que los cambios realizados en la propiedad de origen o en la de destino se actualicen automticamente en el otro OneWayToSource: es el enlace inverso de OneWay; actualiza la propiedad de origen cuando cambia la propiedad de destino

Cambios del destino al origen

Los enlaces TwoWay u OneWayToSource realizan escuchas para detectar los cambios en la propiedad de destino (widget) y los propagan de nuevo al origen. La propiedad UpdateSourceTrigger del enlace de datos determina qu evento desencadena la actualizacin del origen. El valor predeterminado en controles como checkbox, radiobutton es propertyChanged (cambio del valor la propiedad destino) El valor por defecto, para la propiedad Text de TextBox es LostFocus, ya que es ms eficiente hacer el cambio nicamente al terminar de escribir el texto (en lugar de cada vez que cambia el texto) Cuando el valor de propertyChanged es Explicit se invoca al mtodo del CodeBehind UpdateSource Ejemplo: Controles TextBox en un formulario modificable (slo actualiza los valores de origen cuando el usuario hace clic en el botn de envo)

Repasando los 4 elementos, el origen del enlace (normalmente una clase con propiedades) debe especificarse para que funcione el binding. Existen 2 formas para especificar el origen del enlace de datos: Utilizando la propiedad DataContext a un elemento primario. Es til para enlazar varias propiedades al mismo origen Enlazando directamente un control al origen de datos con la propiedad source. Es til cuando se desean realizar enlaces individuales. Propiedades Destino a las que bindear: Slo los objetos DependencyObject pueden definir propiedades de dependencia es decir que permiten enlace de datos La mayora de los controles heredan de UIElement que a su vez se derivan de DependencyObject Por ello, la mayora de las propiedades de los componentes visuales, excepto las de slo lectura, admiten el enlace de datos de forma predeterminada

Validacin de datos
Las aplicaciones que toman datos proporcionados por el usuario requieren lgica de validacin para asegurarse de que el usuario ha escrito la informacin esperada. Las comprobaciones de validacin pueden basarse en el tipo, intervalo, formato u otros requisitos especficos de la aplicacin

Existen 2 maneras de introducir la validacin: Asociando una clase validacin a la propiedad validationRules del control de entrada bindeado Si el objeto de origen del binding implementa la interfaz IDataErrorInfo, puede utilizar la regla integrada DataErrorValidationRule

Validacin personalizada
El modelo de enlace de datos de WPF permite asociar reglas de validacin personalizadas Valida0onRules al objeto destino del Binding Concretamente aqu estaremos definiendo una regla para cada control Por ejemplo, tenemos un TextBox que se enlaza a la propiedad Age (de tipo int) de un objeto de origen de enlace denominado ods. El enlace est configurado para utilizar una regla de validacin denominada AgeRangeRule, de tal forma que si el usuario especifica caracteres no numricos o un valor menor que 21 o mayor que 130 se indica el error

--- Patrones de interfaz de usuario 2 Parte --Model View Viewmodel

Contexto: Debemos elegir la arquitectura de Interfaz de Usuario de una aplicacin con interfaz rico que contiene mucha interaccin entre el interfaz de usuario y los datos de la aplicacin La vista recupera los datos y maneja los eventos de usuario, que pueden modificar otros controles en respuesta a ellos o enviar los cambios para actualizar los datos Incluir el cdigo que realiza todas las funciones en la vista hace que se complique en exceso Sin embargo, debemos mantener el alto nivel de interaccin que requiere dicha interfaz Se hace muy difcil compartir cdigo entre las vistas que requieren el mismo comportamiento, dificultando su mantenimiento y sus pruebas Fuerzas: Se quiere maximizar el cdigo que puede ser probado automticamente Se quiere compartir cdigo entre las vistas que tienen el mismo comportamiento Se desea separar la lgica de negocio de la lgica de presentacin para hacer un cdigo ms entendible y mantenible Problema: Se puede hacer una arquitectura de presentacin para las interfaces ricas que mejore el mantenimiento y las pruebas? Solucin: Patrn Presentation Model [Fowler, 2004] o Model View Viewmodel (MVVM) Propone una separacin de responsabilidades en la interfaz de usuario: La representacin visual en el componente View El estado del interfaz y el comportamiento en el componente Viewmodel La lgica de negocio en un componente Model (que notifique de los cambios a la UI) La View contiene los controles en la interfaz de usuario y el Viewmodel acta como una fachada del modelo con el estado y el comportamiento de la IU

El Viewmodel encapsula el acceso al modelo proveyendo una interfaz publica que es fcil de consumir desde la vista (usando data binding)

Model
UIENTITY: Los UIEntities son una vista de los datos de servidor que van a estar accesibles desde la interfaz cliente y tambin proporcionan el acceso a los servicios que ofrece el servidor. Estos objetos se encargan de hacer transparente si se accede un servidor remoto o el acceso se realiza a un servidor local de dominio, ya que encapsulan la llamada al servidor Adems, incluyen eventos NotifyPropertyChanged que generan un evento cada vez que se modifica una propiedad Un UIEntity siempre tiene dos constructores, uno vaco que se utilizara para acceder a los servicios y otro al que se le pasa un DTO como parmetro el cual dar acceso a los datos de ese DTO DTO es dependiente de la comunicacin entre cliente y servidor (p.e. WCF) Si trabajamos con una fachada local y no hay DTO trabajaremos directamente con los ENs El UIEntity apunta a un DTO que es quien contiene los datos Todos los UIEntity heredan de UIEntityBase Propiedades: Utilizan el NotifyPropertyChanged que permite notificar de los cambios (set) al Viewmodel cada vez que se actualiza una propiedad de un objeto del model Operaciones: El UIEntity invoca al Componente Fachada aplicacin (o a los CENs y CPs). UIEntityBase contiene el EventHandler y el notificador para cada propiedad

View
En MVVM la vista es activa. A diferencia de una vista pasiva sin conocimiento del modelo, y bajo el manejo total de un controlador o presenter (como en MVP) La vista en MVVM contiene comportamiento y enlace a datos que son asociados mediante el data binding a mtodos, propiedades y comandos Se enlazan tambin los comandos, aplicando el patrn command para notificar de las acciones de los controles Como se ha comentado, la vista NO es responsable de llevar cuenta de su estado Tanto la navegacin como la actualizacin de los datos se hace desde el viewmodel El enlace de datos de los controles de la vista, se realizan a travs de las propiedades del viewmodel, es el mecanismo de mantener sincronizados a ambos componentes view y viewmodel

Viewmodel
El viewmodel en el MVVM es la pieza clave del tro Esta separacin permite que el modelo se limite a contener los datos, sin preocuparse de formatos La vista slo tiene que presentar los datos El viewmodel trabaja como intermediario recibiendo informacin de la vista e insertndola en el modelo, u obtiene los datos del modelo y luego convertirlos en propiedades que pueden ser usadas en la vista

Se define un Viewmodel por cada vista ya sea Window, Page o UserControl Cada Viewmodel ha de contener: Una propiedad para cada objeto que se desee mostrar (bindear) en la view Una propiedad ICommand por cada comando que se desee ejecutar como accin desde el interfaz Invoca a los UIEntity para las acciones de servidor Notifica mediante eventos cuando quiere actualizar la interfaz

Command en Viewmodel
Se establece un binding entre la propiedad Command de los controles (Hyperlink, Button, etc.) y las propiedades ICommand expuestas por el ViewModel Se est aplicando el patrn command el cual permite asociar una funcionalidad realizada en el Viewmodel y declarada desde la vista (en el XAML) Para implementar el patrn command hay 2 alternativas: 1. Implementar una inner class que implemente el interfaz ICommand. El uso de RelayCommand que permite pasar la implementacin de los mtodos por delegacin en su constructor 2. La segunda alternativa permite tener un cdigo mucho ms sencillo y la utilizacin de la notacin lambda El viewmodel define una propiedad para cada enlace de datos que se defina en la vista (filtra las que el modelo tiene)