Ingeniería Multimedia

Diseño de Sistemas Multimedia

Tema 2 InterfacesIntroducciónDisciplina HCI: human-computer-interactionEstudia cómo los humanos interactúan con todo tipo de ordenadores. Disciplinas involucradas: psicología, ergonomía, ingeniería, diseño gráfico…

El UI debe ser transparente:o El usuario debe olvidar que está usando un ordenadoro Debe permitirle centrarse en su tarea

El UI debe ser accesible: para todos en todo momento El UI debe ser usable: eficacia + eficiencia + satisfacción

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 bienPrincipios Human-Centered Design (HCD) (ISO 13407)

Involucrar activamente a los usuarios Iteración de soluciones de diseño Equipos de diseño multidisciplinares

4 actividades esenciales Entender y especificar el contexto de uso Especificar el usuario y requerimientos organizacionales Usar prototipos Evaluar los diseños con usuarios confrontando requerimientos

RequerimientosVisión generalPara qué dominio se desarrollará la aplicaciónPúblico objetivo: quiénes son los usuarios, qué quieren hacer con el sistema, dónde se usará éste.

UsuariosObservación directa, indirecta, entrevistas, encuestas…Características UI según rol de usuario, experiencia.

DiscapacidadesPermanenteTemporal (pero usual): Trabajador con jornadas muy largas, al final de éstas disminuyen sus reflejos.

TareasDescribir el trabajo del usuario

objetivo: dónde quiere llegar el usuario tarea: secuencia de actividades acción: actividad parte de una tarea

Casos de usoVer desde el punto de vista del usuario, no del programador.(Clásico, sistema) Acción del usuario Respuesta del sistema (que hace internamente…)(Vista usuario, tarea) Propósito del usuario Responsabilidad del sistema (que muestra…)

Ensayos cognitivosSe evalúan los pasos requeridos para realizar una tarea y se intenta descubrir errores entre lo que el usuario piensa sobre una tarea y cómo la ve el diseñador del UI.Paso: El usuario hace acción Cuestión ¿Sabe el usuario que hacer? ¿Y antes y después de acción?

Diseño conceptualPaso de requerimientos a diseño físico/visual

Principios de diseño gráfico Uso de metáforas Seleccionar elementos SW y HW de E/S adecuados Proceso creativo de establecer la organización de la información y las acciones disponibles. Sobre este diseño realizaremos el diseño del UI Requerimientos --> Diagrama de contenido --> Diseño UI

Pasos1. Caso uso esencial: esbozamos las tareas que el usuario quiere hacer2. Derivamos caso de uso concreto: es un refinamiento del caso de uso esencial3. Hacemos el diagrama de contenido4. Concretamos el diagrama de contenido en uno o varios mockups

1. Diagrama de caso de uso Propósito del usuario | Responsabilidad del sistema

2. Diagrama de contenidoAntes de diseñar pantallas. Boceto o prototipo de baja fidelidad que representa la organización y estructura del UI desde la perspectiva del diseñador. Compuesto de contenedores y enlaces entre ellos:

Contenedor = representación abstracta de una parte de la funcionalidad ofrecida al usuario. Puede ser una pantalla, parte de ésta, un diálogo...

Pantalla en GUI = uno o varios contenedores Enlaces = { navegación | intercambio de información }. Puede ser un hipertexto, un menú

contextual, la interacción entre una tabla de datos y una gráfica

Actividades para producir un diagrama de contenido:1. Derivar casos de uso concretos a partir de los C.U. esenciales2. Identificar los objetos principales que soportarán la tarea, atributos y acciones3. Crear contenedores y establecer los objetos que van en cada uno4. Enlazar contenedores para mostrar cómo fluye la navegación y la información

Estilos de interacción1. Estilos de interacciónDiferentes formas con las que un usuario se comunica con el sistemaConjunto de controles de UI que proporcionan el look & feel (apariencia y comportamiento)

Todos deben seguir los principios de diseño: Affordance (el diseño del objeto sugiere cómo se debe usar), Visibilidad, Retroalimentación, Simplicidad, Estructura, Consistencia, Tolerancia

2. Línea de comandosPotente, flexible, difícil de aprender, difícil de recordar, típicamente baja tolerancia a errores: mensajes de salida confusos, para expertos, mayor control.

PAUTAS Usar nombres significativos para comandos Seguir una sintaxis consistente (gramática) para todos los comandos Abreviaturas consistentes Hacer los comandos lo más 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 número de comandos y formas para realizar una tarea Ofrecer la posibilidad de crear y ejecutar macros (scripts - p.ej. potencia bash)

3. Menú de selecciónNo tiene por qué ser gráfica (los clásicos 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 menús e iconos deben ser auto-explicativosMejor para usuarios no entrenados. Para los entrenados: usar atajos

PAUTAS Usar la semántica de tareas para organizar los menús Títulos de los menús que reflejen las funciones Agrupar los ítems con sentido Evitar menús demasiado largos: además considerar el tamaño de pantalla Ordenar los ítems de los menús con sentido

Usar nombres cortos Usar una gramática, organización y terminología consistentes Ofrecer ayuda sensible al contexto: caja de búsqueda en menús...

4. FormulariosCuando necesitamos obtener muchos datos del usuario. Metáfora de una hoja de papel.Si está bien diseñado el formulario el usuario se formará rápidamente un modelo mental preciso.

PAUTAS Nombres o títulos de campos con sentido Usar el lenguaje del usuario (no el del diseñador) Ofrecer instrucciones completas y comprensibles Ordenar (visualmente + tab) y agrupar los campos de forma lógica Presentar de forma llamativa el formulario Usar terminología y abreviaturas consistentes Usar los espacios para organizar Restringir el número 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

cómo corregir el error Indicar campos obligatorios Ofrecer ayuda contextual y ejemplos

5. Manipulación directa (DM)El usuario interactúa directamente con los objetos del UI. Típicos en entornos WYSWYG (what you see is what you get). Uso extensivo de metáforas. La mayoría de los sistemas embebidos la usan (a través de teclas, apuntadores, voz).

Características clásicas de los DM: Hay una representación 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 físicas, como pinchando o arrastrándolos, en

lugar de tener que usar sintaxis complejas. Las operaciones suelen ser rápidas, incrementales y reversibles El usuario percibe que interactúa con el dominio, más que con un interfaz. El usuario gana

en confianza Los novatos aprenden rápidamente la funcionalidad básica

PAUTAS Seleccionar cuidadosamente las metáforas, que sean conocidas al usuario Crear representaciones visuales de las tareas Ofrecer acciones rápidas, incrementales y reversibles Reemplazar el tecleo por la selección con apuntador o mejor, complementar, el teclado es

más rápido para usuarios expertos Presentar una estructura atractiva

Hacer que el resultado de las acciones sea inmediato mediante retroalimentación visual o de audio

6. AntropomórficasIntentan interactuar con las personas igual que las personas lo hacen entre ellasReconocimiento (voz, lenguaje natural, movimiento de ojos, señales biométricas)Dificultad: separar señal de ruidoActualmente en investigación: ver “wereable computer”

7. Combinación de estilos Es la mejor opción Un estilo para cada tipo de tarea El usuario elige el que prefiere (como Autocad)

Guía/Directrices de diseñoISO 13407 – proceso de diseño de sistemas interactivos centrado en la persona

Beneficios: Los sistemas son más fáciles de entender y usar Se reduce la incomodidad y el estrés Se mejora la satisfacción del usuario Se mejora la productividad y la eficiencia Se mejora la calidad, la estética

Elementos esenciales: Involucración activa de usuarios Entendimiento claro de usuarios Reparto correcto de funciones entre usuarios y tecnología Iteración de soluciones de diseño Perspectiva de diseño multidisciplinar

Guías de estiloUna guía de estilo típica incluye

Descripción de estilos de interacción requeridos y controles de interfaz de usuario Directriz sobre cuándo y cómo usar los distintos estilos y controles Ilustraciones de los estilos, controles y pantallas de ejemplo

Guía de estilo corporativa Colores, tipografías, usos correctos e incorrectos de la marca Rellenos, espaciados

Principios de diseñoSimplicidad, Estructura, Consistencia, Tolerancia, Consistencia, Repetición, Alineamiento, ProximidadGestalt: proximidad, similitud, continuidad, simetría, visibilidad,...

SimplicidadMantener el interfaz lo más simple posible:

Usando el lenguaje del usuario: iconos, palabras, acciones, controles que le sean familiares, modelo mental usuario, metáforas

Dividir las tareas complejas en otras más simples: recordar el diseño conceptual --> contenedores

Pocos elementos, bien repartidos y estructurados La imagen define claramente de qué es la web Navegación (qué podemos hacer en la web) clara

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

ToleranciaEvitar que el usuario cometa errores ¿Hace falta el mensaje de error? Reducir las posibilidades:

Máscaras. Campos numéricos que sólo admitan números Cambiar input por selecciones (radio boxes, listas...) Valores por defecto (con cuidado), ejemplos de contestaciones válidas Comprobar antes de salir del campo: Compromiso anticipación error vs. Ritmo

Recuperabilidad de errores Hacia delante: el sistema acepta el error y ayuda al usuario a conseguir el objetivo Hacia atrás: deshace los efectos de la acción errónea

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 información suficiente para corregirlos Si el usuario lo demanda, dar explicaciones adicionales durante la corrección del error No agredir al usuario con el lenguaje (escrito y visual)

o Error fatal, violación de acceso, error de integridad referencialo Dar la culpa del error al sistema, no al usuario

Usar términos específicos, constructivos: cambiamos el mensaje de error por una pregunta. Además, que se identifique el error como de nuestro programa.

Accesibilidad“... el diseño de productos y entornos para ser usables por todo el mundo sin necesidad de adaptaciones especiales”7 PRINCIPIOS

Affordance - (el diseño del objeto sugiere cómo 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 - fácil de usar y aprender

Información 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 físico - minimiza la fatiga e incremente la comodidad de uso

Directrices de accesibilidad de contenido Web de W3C, 14 principios generales de diseño accesible:1. Ofrecer alternativas a contenido audiovisual2. No basar todo en el color sólo: texto y color se deben entender en escala de grises3. Usar las etiquetas y las hojas de estilo correctamente: evitar etiquetas, HTML de

presentación. Usar etiquetas estructurales (h1, p...)4. Clarificar el uso del lenguaje natural: facilitar la comprensión de los textos, sobre todo para

texto en lengua extranjera o abreviaturas5. Diseño líquido. Tablas y DIVs que se transformen bien para todos los navegadores6. Preparar las páginas para que se sigan pudiendo leer con tecnologías deshabilitadas (p.ej.

JS)7. El usuario debe poder parar o pausar contenido que parpadee, se auto-actualice, haga scroll8. Asegurar accesibilidad directa de UI embebidos9. Diseñar para independencia de dispositivo10. Usar soluciones no demasiado costosas de realizar para que los diseños funcionen con

navegadores antiguos, o al menos, ofrecer alternativa11. Usar las tecnologías y directrices de W3C, o al menos, ofrecer alternativa12. Ofrecer información contextual que ayuden al usuario a entender elementos o páginas

complejas13. Proveer mecanismos de navegación claros: el usuario debe poder encontrar rápidamente lo

que busca en el sitio14. Asegurar que los documentos son claros y simples

Tema 3 Introducción a Software y DSLsIntroducción al diseño de softwareCausas de los proyecto fallidos/problemáticos

Requisitos mal definidos o mal administrados Inconsistencias no detectadas entre los requisitos, el diseño y la implementación Comunicación ambigua o imprecisa Pruebas insuficientes Evaluación subjetiva del avance del proyecto Propagación de cambios sin control Bajo nivel de automatización

Diseño de softwareEl diseño es una visión de la solución del problema que abstrae elementos ligados exclusivamente a la implementación.

Modelado visual Capturar la estructura y comportamiento del sistema y sus componentes. Mostrar cómo los elementos del sistema “encajan” entre ellos. Mantener la consistencia entre análisis, diseño e implementación. Promover la automatización (desarrollo dirigido por modelos).

Ventajas: Permiten capturar el diseño formalmente y de manera no ambigua. Los detalles pueden ser omitidos cuando sea necesario. Los diseños no ambiguos muestran las inconsistencias más claramente. La calidad de la aplicación comienza con un buen diseño. Las herramientas de modelado proporcionan mecanismos de automatización que aceleran

el desarrollo.

Arquitectura tempranaEstablece división en capas que proporciona una vista a grandes rasgos del sistema en función de sus necesidades de distribución y una configuración de los componentes que proporciona la estructura de la aplicación 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 reúso (COTS) y adecuarse a

plataformas distribuidas

Arquitectura de capasMódulos independientes, incluso en plataformas distintas.Interfaz usuario: Componente de IU, componente de proceso de usuario -->Lógica: Componentes de proceso --> Componentes de Entidad de Negocio -->Persistencia: Componentes de acceso a datos --> Datos de la aplicación.

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 sincronización y organización de las interacciones con el usuario Recibe las peticiones del usuario y las reenvía en forma de llamadas a la lógica de negocio Contiene el flujo del proceso y la lógica de administración de estado separándolo del código

de los elementos de la interfaz de usuario Los CPU obtienen su funcionalidad partiendo del modelo de navegación o flujo y diagramas

de contenido.

Componente de proceso Se encarga de exponer los métodos de más alto nivel que la lógica de negocio expone al

cliente Permite independizar la funcionalidad ofertada de cómo esté realizada la implementación

de los métodos invocados Reduce el interfaz entre las capas del interfaz de usuario y la lógica de negocio

implementando el patrón Façade [Gamma et al., 1995] que reduce el acoplamiento y mejora la mantenibilidad Contiene la lógica de negocio que involucra a procesos complejos donde intervienen más de

una entidad de negocio. Inicia y finaliza las transacciones de manera que las Entidades de Negocio y Componentes de

Acceso a Datos estén dentro del contexto de una transacción Puede contener la autorización para el acceso a determinada funcionalidad por parte del

usuario

Componente de acceso a datos Encapsulan la tecnología de acceso a datos y la BBDD al resto de la aplicación. Proporciona un interfaz sencillo que permite recuperar los datos de la BD y salvar una o más

entidades de negocio en la BD (métodos CRUD) Los CADs también podrían contener cierta lógica de negocio necesaria para realizar

operaciones relacionadas con datos (consultas SQL)

Datos de la aplicación Representados y almacenados en uno o más gestores de base de datos Su estructura puede ser jerárquica, relacional u orientada a objetos

La estructuración de dichos datos se obtiene mediante un entidad relación (BDR) o un modelo de dominio (BDOO)

Diseño basado en lenguajes de dominio específico (DSL)Necesidad del modeladoNivel de abstracción alto. Permite arquitectura temprana. Permite paso a diseño y después a implementación mediante procesos automatizados.

Modelos de diseño Representan de forma reducida un sistema. Ayudar a comprender un problema complejo (o solución). Comunicar ideas acerca de un problema o solución. Guiar la implementación. Para detectar errores u omisiones en el diseño antes de comprometer recursos para la

implementación Para comunicarse con los “stakeholders” Para guiar la implementación (Model Driven Engineering). Utiliza un modelo para‐

representar y obtener el código final

Características: Abstracto: Enfatiza los elementos importantes y oculta los irrelevantes. Comprensible: Fácil 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 más barato y sencillo de construir que el sistema que modela.

Metodologías MDE Mejora la productividad (acelera el desarrollo del software) Mejora la mantenibilidad Reduce los errores al automa9zar parte o todo el código obtenido Permiten especificar con mayor precisión 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 código.o El resto del código mediante diagramas de componente/secuencia más complejos.o Compatibilizar código generado con el manual.

Modelado de dominio (DSL OOH4RIA)Autogenerated y Password son tipos especiales de atributos.Relaciones: asociación, agregación. Generalización/especialización. Agregación y generalización forman jerarquías de clases. UML proporciona una escasa caracterización de la agregación.Relación con mínimos de 1 a 1 solo con composición.

Operaciones: Permite generar el código de dicha operación tanto a nivel de lógica de negocio, como su invocación para su persistencia en BBDD.

Tema 4 Introducción al Diseño DetalladoPatrones => calidad: mantenible, escalable, usable, eficiente, etc.Permiten reutilizar la experiencia de otros diseñadores, y reducir el esfuerzo asociado a la producción de sistemas más efectivos y flexibles (más adaptables al cambio). Soluciones exitosas y conocimiento de problemas en el desarrollo de software.

Patrón: Presenta una solución probada para un problema recurrente (no trivial) en un contexto concreto.

Especifica una configuración espacial de elementos y un comportamiento asociado a esta configuración

Provee un vocabulario común y un concepto que permite la mejora del entendimiento entre expertos

Mejora la calidad de la solución del problema

RepresentaciónContexto: Sitúa el entorno bajo el cual el patrón existeProblema: Describe que aspectos abordados por el desarrollador se realizan de forma insatisfactoriaFuerzas: Lista de razones y motivaciones que afectan al problema y justifican la aplicación del patrónSolución: Describe la solución adoptada brevemente y los elementos de la solución en 2 secciones.

Estructura: Usa el diagrama de clases para mostrar la estructura básica de la solución Estrategia: Describe una de las posibles implementaciones del patrón en la tecnología

apropiada (en nuestro caso .NET)

Patrones GRASPGeneral Responsability Assigment Software PatternsLa base de cómo se diseñará el sistema. Primeros momentos de diseño.Tras haber identificado los requisitos, y haber creado un modelo de dominio, se añaden operaciones a las clases, y define las secuencias de mensajes entre objetos para cubrir los requisitos.

Hay principios fundamentales de diseño que deben ser tenidos en cuenta a la hora de: Decidir qué operaciones hay que asignar a qué clases Cómo los objetos deberían interactuar para dar respuesta a los casos de uso

ResponsabilidadContrato u obligación 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 cálculo), iniciar una acción en otros objetos, controlar y coordinar actividades en otros objetos.

Hay dos tipos de patrones GRASP. Vamos a ver los cinco BÁSICOS.

1. Experto en informaciónProblema: ¿Cuál es el principio general para asignar responsabilidades a las clases?Solución: Asignar una responsabilidad a la clase (experto) que tiene la información necesaria para realizar la responsabilidad. Ventajas:

Encapsulamiento de la información Distribución del comportamiento del manejo de la información

2. CreadorProblema: ¿Quién debería ser el responsable de la creación de una nueva instancia de alguna clase? Solución: 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 más de los casos siguientes:

B agrega objetos de A; B contiene objetos de A; B registra instancias de objetos de A; B utiliza más estrechamente objetos de A; B tiene los datos de inicialización que se pasarán a un objeto de A cuando sea creado ( por lo

tanto, B es un Experto con respecto a la creación de A)

El patrón Creador guía la asignación de responsabilidades relacionadas con la creación de objetos (una tarea muy común). La intención básica del patrón es encontrar un creador que necesite conectarse al objeto creado en alguna situación.

Ventajas: Bajo acoplamiento logrando mayor mantenibilidad y reutilización. Desventajas: Puede ser muy compleja la operación de creación de instancia.

3. Bajo acoplamientoProblema: ¿Cómo podemos reducir las dependencias entre clases, reducir el impacto de los cambios e incrementar la reutilización? Solución:

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 confía en otros objetos Un objeto con bajo (o débil) acoplamiento no depende demasiado de otros objetos.

El patrón Bajo Acoplamiento es un principio a tener en mente en todas las decisiones de diseño. Es un principio evaluativo que debe aplicar un diseñador mientras evalúa todas las decisiones de diseño. El bajo acoplamiento genera clases más independientes.

Ventajas: Se reducen los cambios en otras clases Fácil 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 relación navegable de asociación,

agregación o composición) Un objeto de la clase A invoca a una operación de B Una operación de A tiene un parámetro del tipo B Una operación de A devuelve un valor de tipo B A es subclase directa o indirectamente de B

4. Alta cohesiónProblema: ¿Cómo mantener una complejidad manejable? Solución:

Asignar las responsabilidades de manera que la cohesión permanezca alta. La cohesión es una medida de la fuerza con la que se relacionan y del grado de focalización

de las responsabilidades de un elemento

Una clase con baja cohesión hace muchas cosas que no están relacionadas, o hace demasiado trabajo: Clases difíciles de entender, reutilizar, mantener, delicadas ante cambios en otras clases.

Sin embargo, una clase con alta cohesión tiene: Un número relativamente pequeño 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 comprensión del diseño Simplifica el mantenimiento y las mejoras Soporta a menudo el bajo acoplamiento Incrementa la reutilización

5. ControladorProblema: ¿Qué clase de la lógica de negocio debe ser el responsable de gestionar un evento que procede de la capa de cliente?

Solución 1: El controlador es un componente de negocio que representa a las clases de dominio. Sería el componente de IU donde residirían los procesos complejos.

No son buenas las clases o los componentes de negocio que representan al dominio.Se crearían dependencias entre la interfaz y los componentes de lógica de negocio (aumenta el acoplamiento entre capas).No es conveniente que un objeto de interfaz maneje los procesos de la lógica de negocio (se reduce la cohesión de los componentes de interfaz de usuario).

Solución 2: Definimos una clase intermedia llamada Controlador que únicamente se encarga de recibir la petición del interfaz y de reenviar las llamadas a los objetos de negocio.

En algunas ocasiones solamente reenviará la petición a la lógica (operaciones simples), en otras ocasiones se definirán coreografías 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 Construcción artificial para dar soporte al sistema o Se utilizan cuando los Controladores de Fachada conducen a diseños con baja

cohesión o alto acoplamiento

Patrones GOFUn patrón de diseño son soluciones recurrentes a problemas de diseño 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 instanciación. Nos ayudan a independizar a un sistema de cómo sus objetos son creados. Tratan de ocultar a los objetos de sus métodos concretos de creación, de tal forma que al

variar su implementación, 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 construcción de un objeto complejo, de su representación. De esa

manera, el mismo proceso de construcción 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 creación en concreto Prototype: Mediante una instancia prototípica, conseguimos otras instancias de ese objeto Singleton: Nos consigue dar un solo objeto de la clase, en cualquier momento de la

aplicación

PATRÓN SINGLETONContexto: Necesitamos que algunos datos sean accesibles para todo el sistema. Y también necesitamos que esos datos sean únicos. Ej. Los datos de configuración del sistema.Problema: ¿Cómo 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 noSolución:

Permitir que otros objetos obtengan esa instancia, mediante la llamada a métodos estáticos de la clase

Declarar el constructor como privado, para evitar la creación de otros objetos

PATRÓN FACTORY METHODContexto: Existe siempre la necesidad de reducir el tiempo de desarrollo reutilizando partes del programa realizadas con anterioridad.Problema: Queremos estandarizar nuestra aplicación para diferentes modelos de dominio (Ej. Agencia de viajes, comercio electrónico, etc.) permitiendo a los dominios individuales definir sus propias clases y proveerlas de su instanciación.Solución: Define una interfaz para crear los objetos de cada clase, que permita a las subclases decidir qué clase se va a instanciar (método de factoría).

Factory Method permite a una clase diferir su instanciación a las subclases Permite definir algoritmos genéricos que trabajen con la clase raíz de la jerarquía y es

aplicable a cualquier tipo de subclase

Patrones Estructurales Se ocupan de cómo las clases y los objetos se agrupan, para formar estructuras más grandes Ofrecen modos efec0vos de utilizar mecanismos OO como herencia, agregación y

composición para sa0sfacer requisitos par0culares (p.e. extensibilidad) Podemos nombrar al clásico patrón 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 algún

cliente Bridge: Desacopla una abstracción de su implementación en concreto. Luego, podemos

cambiar la implementación, o la abstracción, 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 dinámicamente, dándonos una alternativa a

la extensión de una clase, en lugar de usar subclases Façade: 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

PATRÓN COMPOSITEContexto: Existencia de objetos compuestos y componentes que deben ofrecer el mismo comportamiento.Problema: Necesidad de representar jerarquías 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 jerarquía de herencia. Eso permite que las operaciones sean heredadas y redefinidas de manera polimórfica. La necesidad de representar estructuras todo- parte sugiere la necesidad de una‐ estructura de agregación

Solución:Combinar jerarquías de agregación y de herencia. El objeto compuesto manda mensajes a los componentes para el comportamiento común, y ofrece operaciones adicionales para añadir/borrar componentes.

PATRÓN FAÇADEContexto: Al dividir un sistema en capas se simplifica la complejidad del sistema pero a la vez se hace compleja la comunicación ya que los clientes se deben comunicar con la correspondiente capa anexa de acuerdo al requisito.Un objetivo de diseño es minimizar la comunicación y el acoplamiento entre las diferentes capas para reducir el tráfico entre ellas (p.e. entre el interfaz de usuario y la lógica de negocio).Problema: Se requiere una interfaz común unificada a partir de un conjunto heterogéneo de interfaces, como la de una capa lógica Fuerzas:

Proteger a los clientes de los componentes de la capa lógica. Esto permite reducir el número de objetos con el que el cliente trata y el subsistema es más fácil 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 compilación de dependencias, esto es vital en grandes sistemas de software.Solución: El patrón Façade provee una interfaz unificada sencilla para una capa lógica o subsistema Este interfaz hace de intermediario entre el cliente y una interfaz o grupo de interfaces más complejas pertenecientes a la capa lógica.

Patrones de conductaMás que describir objetos o clases, describen la comunicación 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 patrón Iterator, una forma de recorrer una lista o colección independientemente de la estructura interna.

Tipos: Command: Encapsula la llamada a un objeto, permi0endo el "undo" y el “redo” de la

operación Observer: Define una relación uno a muchos, entre un objeto y otros que están 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 colección o similar, sin

exponer su estructura interna Mediator: Permite la interacción 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 más 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 operación, cuyas operaciones más básicas,

quedan delegadas en subclases Visitor: Nos permite recorrer una estructura (un árbol, por ejemplo), aplicando una

operación a cada elemento

Interpreter: Construye una representación de la gramá0ca de un lenguaje, junto con su intérprete

PATRÓN STATEContexto: Un objeto puede tener un comportamiento complejo (distintas respuestas a un mismo mensaje) en función 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 ejecuciónFuerzas:

El objeto presenta un comportamiento complejo que debería ser factorizado en elementos más simples

Una o más operaciones tienen un comportamiento que varía en función del estado del objeto

Se pueden definir operaciones distintas para cada estado, pero los objetos cliente necesitarían saber el estado del objeto para invocar la operación concreta, lo cual incluiría un acoplamiento elevado entre la clase cliente y la clase de invocada

Solución: 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 apropiadoContexto se convierte en un agregado de sus estados, donde sólo uno de ellos está activo en un momento dado. Los estados forman una jerarquía de herencia. La responsabilidad en las transiciones de estado puede recaer en el contexto o ser compartida entre las subclases de Estado

PATRÓN COMMANDContexto: El concepto de "orden" puede ser ambiguo y complejo en los sistemas actuales y al mismo tiempo muy extendido: intérpretes de órdenes (shell) del sistema operativo, macros de paquetes ofimáticos, gestores de bases de datos, etc. Problema: A veces es necesario enviar pe0ciones a objetos sin saber nada de la operación solicitada o de quien es el receptor de la petición.Fuerzas:

Permitir gestionar colas o registro de mensajes Soportar restaurar el estado a par0r de un momento dado (undo y redo) Ofrecer una interfaz común que permita invocar las acciones de forma uniforme y extender

el sistema con nuevas acciones de forma sencilla Solución: Encapsular una petición 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 Diseño de la Lógica de Negocio y Capa de DatosDiseño de la lógica de negocioLógica de negocio

Contiene las reglas de negocio en las que se va a basar nuestra aplicación. 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 patrón Domain Model de Mar0n Fowler (EAP, 2003), que propone representar

la lógica 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 múltiples clases con relaciones y debemos decidir cómo

mapear las clases en diferentes Componentes Entidad de Negocio (CEN), en inglés Business Objects (BO).

Se debe identificar el núcleo de CENs que encapsularán la funcionalidad de la aplicación (p.e. un solo CEN puede contener una agregación o una jerarquía de herencia).

IMPORTANTE Al no tener estado requieren que todas sus operaciones reciban el OID del objeto al cual

queremos modificar, a excepción de los métodos de creación y consulta. La comunicación con el CAD se realiza mediante uno o más objetos tipo EN o DTO que

realizan la función de objeto de trasiego. La implementación 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 lógica 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 lógica de negocio y de persistencia aunque esta puede contener el almacenamiento en BBDD mediante el CRUD (alta, baja, modificación y consulta) o sin CRUD.

Las EN pueden ofrecer lógica de forma opcional para que sea evaluada en la capa de cliente. Solo son obligatorios los atributos y las propiedades.

IMPLEMENTACIÓNSe implementa un componente CEN por cada clase de dominio (o composición o jerarquía de herencia) <-- ¡cuidado con la perdida de cohesión!

Existen diferentes tipos de CEN: Contienen atributos (y propiedades públicas) 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 (Patrón Object Value, Core J2EE, 2002).

Cada CEN referenciará a un Componente de Acceso a Datos (Patrón Data Access Object) que permite independizar la lógica de negocio de la persistencia.

En lugar de referenciar directamente a la clase, lo hará mediante la interfaz del CAD aplicando el patrón de Dependency Injection (Fowler, 2002).

Los CEN con DTO separado no mantienen estado, en cada operación 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.

Implementación CEN de una clase (Ej. Producto) Cada CEN será una clase cuyo único atributo es el interfaz del CAD Se aplica el patrón de inyección de dependencia, recibiendo como parámetro 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)

ModificarLos atributos que provienen de las relaciones de asociación (los roles) se modificarán o bien en la operación crear o en los métodos 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 asociación donde en ambos lados la cardinalidad

mínima es 0, y los objetos se crean sin estar relacionados. Si la cardinalidad máxima es *, entonces relationer permitirá añadir objetos relacionados Si la cardinalidad máxima 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 máxima 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 máxima es 1, entonces unrela0oner quitará un solo objeto relacionado (le asignará valor null a una sola clave ajena).

Entidades de Negocio El patrón Object Value establece que un objeto Entidad de Negocio se encarga de contener

el estado del objeto (atributos y roles ) y los métodos que permiten acceder a dicho estado (propiedades).

Las EN pueden estar el diferentes capas y permiten múltiples tipos de representaciones orientadas a objetos o a datos.

Pueden ser serializables lo que permite que se envíen a través 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 métodos

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 información a la aplicación cliente. Representan las relaciones de asociación (incluidas sus subtipos agregación y composición) y las de herencia (el CEN NO!!).  No contiene los métodos CRUD para invocar a los CAD, sino que es el CEN quien lo hace.

Relaciones de Asociación La diferencia a nivel de asociación, con composición 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 relación 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 XMLVentajas:

Utilización de un estándar de la W3C para la representación de datos Flexibilidad. XML permite representar jerarquías y colecciones de información Interoperabilidad. XML es una opción ideal para intercambiar información con sistemas

legados (externos), socios comerciales, de forma independiente de plataforma.Desventajas:

La correctitud del tipo no es preservada en XML La validación de un XML es lenta No permite el uso de campos privados Requiere de un proceso complejo para su ordenación

Modelo de ejecución de una operación Se pretende unificar la forma de plasmar las operaciones de dominio en la implementación. Nos basamos en el diseño dirigido por contrato para definir las operaciones (Meyer, 1992). Se deben de cumplir las precondiciones y postcondiciones antes y después del cuerpo de las

operaciones.

Diseño dirigido por contratoLos contratos de software se especifican mediante la utilización de expresiones lógicas denominadas aserciones. Dichas aserciones siempre deben cumplirse para poder ejecutar una operación.

Existen 2 tipos de aserciones: Precondiciones: Asegura que se cumple un determinado estado de partida para ejecutar la

operación.

Postcondiciones: Verifica que el trabajo realizado por la operación se ha cumplido correctamente.

Su incumplimiento inválida totalmente el software, indicando que existen un error en la operación (se lanza una excepción).

Diseño de componentes de acceso a datos Los Componentes de Acceso a Datos (CADs) encapsulan la tecnología de acceso a datos y la

BD al resto de la aplicación (Patrón DAO). Proporciona un interfaz sencillo que permite recuperar los datos de la BD y salvar una o más

entidades de negocio en la BD (métodos CRUD). Los CADs también podrían contener cierta lógica 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 CategoríaCAD:Esta clase provee los servicios para recuperar y modificar los datos de la tabla

Categoria

Mapeo Objecto - RelacionalDefinir todos los métodos que devuelven un tipo concreto de Entidad de Negocio en un solo CAD (¡mantener una Alta cohesión!)

Por ejemplo, si se están recuperando todos los pedidos de un determinado cliente, implementar la función en PedidoCAD llamada DamePedidosPorCliente que devuelva los pedidos filtrando por un idCliente

Contrariamente, si estás recuperando todos los clientes que han realizado un pedido específico, implementa la función en ClienteCAD DameClientesPorPedido

Se han de mantener las relaciones de asociación mediante métodos de modificación, creación y borrado de relaciones.Relaciones 1 a muchos, 1 a 1, requieren de métodos de update en la BBDD.Relaciones muchos a muchos requieren de métodos de añadir y borrar relaciones en una tabla intermedia.

Implementación 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 transacción 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

invocación y el formato de la BD a la lógica de negocio.

Operaciones de CADUn CAD debe proveer los métodos 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 métodos son llamados CRUD, acrónimo de “Create, Read, Update and Delete”

Los CAD pueden contener también métodos que realizan algún filtro. Por ejemplo, un CAD puede tener un método para encontrar el producto más vendido en un catálogo 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, podréis definir un CAD que controle las tablas de Cliente y ClienteVIP (herencia), y otro CAD que controle los Pedidos y las LineasDePedido (composición)

CADs con NHibernate Framework Object-Relational Mapping (ORM) Permite simplificar el almacenamiento y recuperación de los objetos en la BBDD Simplifica el código de los CADs reduciendo las operaciones ofertadas al mínimo Las navegaciones por rol y herencia, y su almacenamiento son realizadas de forma implicita

por el propio framework Permite sustituir el código 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 relación de asociación se mapea a una relación de tablas (en función de cada tipo, se

hará de una forma u otra) Cada relación de herencia también se convierte en una relación de asociación (existen 3

estrategias)

Mapping Uno a Muchos: Introducimos borrado en cascada solo en las relaciones de composición En los otros casos (asociación y agregación) daremos un error al intentar borrar el objeto (de

la parte uno) que todavía 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 podríamos tener una lacy fetching, es decir, llama a BBDD cada vez que navega una relación

La alternativa es poner lazy-fetching=false, y se trae el objeto y sus relaciones (hasta 3 niveles). Pero es menos eficiente

Hibernate Query LanguageUtiliza createQuery como mecanismo de búsqueda.

Dos tipos de asociación: Implícita: En la sentencia no se usa la palabra JOIN si la relación está presente en el objeto. Explicita: Hay 3 tipos de JOIN (inner, left, right).

Herencia con HQLTenemos una jerarquía de Usuario del que heredan Administrador y UsuarioWeb. Una consulta como esta: from Usuario as usu

Devuelve no solo instancias de Usuario, sino también de sus subclases Administrador y UsuarioWeb.Las consultas HQL pueden referenciar cualquier entidad (EN o DTO) o interfaz en la cláusula from.Las consultas devolverán 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 polimórfica.Siguiendo el ejemplo del caso anterior, podemos indicar en la cláusula where que queremos solo las instancias de un determinado subtipo: From Usuario usu where usu.class = UsuarioWeb

CAD con procedimientos almacenadosLos CADs pueden invocar a procedimientos almacenados para realizar tareas complejas contra la BD.Ventajas:Mejora del rendimiento al almacenarse el plan de acceso y cachearseReduce el tráfico al reducirse el número de invocaciones SQLDesventajas:Incrementa la carga del servidor de BD que es menos escalable que la capa de Lógica de NegocioEscribir un procedimiento almacenado en T-SQL es una tarea muy especializada y es poco portable

Tema 6 Diseño de los Componentes de ProcesoUna aplicación 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 métodos de mayor nivel de la lógica de negocio. Permite independizar la funcionalidad ofertada de cómo y dónde esté realizada la implementación de los métodos invocados.

Un CP contiene la lógica de negocio que involucra a procesos complejos a diferencia del CEN que contiene la lógica 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 estén dentro del contexto estos servicios.

Si deseamos que se ejecuten dichos componentes en diferentes máquinas en .NET pueden implementarse con: COM+ 1.5,Windows Communication Fundation (WCF),.NET Remoting

Existen básicamente 2 alternativas: Definir un componente de proceso por cada entidad de negocio de manera que

encapsulamos tanto operaciones simples como complejas (patrón Session Façade). Definir únicamente un componente de proceso para las operaciones complejas delegando a

los CEN las operaciones simples (patrón Application Façade).

1ª ESTRATEGIA: CP COMO SESSION FAÇADE Session Façade (Core J2EE, 2001) tienen la responsabilidad de definir las transacciones y

además se le incorpora la responsabilidad de la distribución. Permite realizar una distribución de los componentes de proceso de forma individual

permitiendo así un mayor balanceo de carga y escalabilidad. Requerido en aplicaciones con lógica de negocio complejas.

Ventajas: Mayor escalabilidad soportando la distribución a nivel de componente. Soporta transacciones distribuidas en diferentes fuentes de datos.

Desventajas: Mayor acoplamiento en las responsabilidades de distribución 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 FAÇADE El CP tiene la responsabilidad únicamente de la transaccionalidad delegando en un componenteApplication Façade la distribución. Se define un CP para cada operación 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 lógica de negocio de dichos componentes de proceso por diferentes

fachadas de negocio No interviene si se requiere directamente a una operación simple, solo las invoca desde una

operación complejaNo permite distribuir la lógica de negocio entre diferentes BBDD

Ventajas: Reducción del código al solo poner en el CP las operaciones complejas Permite una mayor reutilización de los CPs para diferentes fachadas al separar la

distribución de la transaccionalidadDesventajas:

La granularidad de la distribución se eleva a nivel de capa (más acomplamiento funcional) Menos posibilidades de balancear la carga

TransacciónUna transacción es un conjunto de operaciones realizadas en una única unidad de trabajoSu ejecución de forma atómica asegura la consistencia y fiabilidad del sistemaTodas las operaciones de transacción han de ser completadas con éxito para que su ejecución se materialice.

Si todo ha ido bien: Commit. Se materializan los cambios realizados por todas las invocaciones Si ha habido algún error: Rollback. Deshacen todos los cambios realizados desde el inicio de la transacción

TIPOSExisten tres modos de implementarlas en .NET:

Utilizando procedimientos almacenados Transacciones manuales con ADO.NET (incluido frameworks como Nhibernate o Enterprise

Library) Transacciones automáticas con un Monitor transaccional (p.e. COM+ o WCF)

1. Procedimiento almacenadoTransacción manual escrita en el T-SQL (SQLServer) encapsula las operaciones dentro de BEGINTRANSACTION y COMMIT/ROLLBACK

TRANSACTION Solo permite lanzar transacciones de forma local a un gestor de BBDD. Se obtiene un excelente rendimiento permitiendo lanzar una transacción compleja con solo una invocación 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 transacción

Desventajas: Aprender Transact-SQL o el lenguaje del gestor, aumenta la curva de aprendizaje Poco portable ya que el código es dependiente del gestor

La escalabilidad está limitada por los servidores de datos

2. Manuales con ADO.NETADO.NET proporciona un objeto transacción (SQLTransaction) usado para comenzar la transacción ypara controlar explícitamente si debe hacerse commit o rollback.Dicho objeto está ligado a una conexión de BBDD, así que en nuestra arquitectura se ha de implementar en una clase CAD (repaso tema 3).

Ventajas: Fáciles de programar Flexibilidad para controlar la transacción con instrucciones explícitas Soluciones como NHibernate permiten mantener en el CP el ámbito de dichas transacciones

Desventajas: Necesita más 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 lógica de negocio sencilla.Para ello los CP son clases de librería que invocan a los CEN, y que inician las sesiones y transacciones de NhibernatePermite el lazy feching = true en cada entidad EN, ya que en este contexto podemos mantener una sesión durante todas las llamadas de la operación.

Solución con NHibernate Los CPs heredan de basicCP.cs que tiene el atributo booleano sessionStarted indicando si se

ha iniciado la sesión o no Además se implementan los métodos SessionInicializeTransation, SessionCommit y

SessionRollback Permite crear o no una transacción en un CP Permite que un CP llame a otro CP y se conserve la misma session y transacción 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 vacío que crea una nueva sesión Constructor que conserva la sesión 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 actúan cuando la sesión se ha iniciado en el mismo CP.Invocación CP a CP:

Un CP puede invocar a una operación de otro CP o de él mismo. Permitiendo así la composición de operaciones complejas.

En caso de que se invoque a una operación de otro CP se invocará al constructor del CP pasándole la sesión

Invocación operación 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 transacción en la operación invocada

Patrón Data Transfer ObjectContexto:

Has diseñado tu aplicación distribuida, y para satisfacer un requisito del cliente, te encuentras realizando múltiples llamadas a objetos remotos.

Demasiadas invocaciones remotas incrementan el tiempo de respuesta de tu aplicación más allá de los niveles aceptables

Problema: ¿Cómo preservamos en una aplicación distribuida la semántica de acceso a los atributos sencillos de un objeto sin estar sujetos a las latencias inherentes de la comunicación 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 encapsulación nos lleva a definir métodos de grano fino que acceden a un único atributo de la clase. Esto implica un alto número de invocaciones a los métodos del objeto

Solución: Creamos un objeto de transferencia de datos (DTO) que contenga todos los datos requeridos

en una sola invocación remota Modificamos el interfaz del servidor para que tenga el DTO como parámetro de salida El cliente almacena una copia del DTO recibido y realiza un conjunto de invocaciones de

forma local para recuperar los datos más detallados.

Cuando diseñamos un DTO tenemos dos opciones: Usar una clase y colección genérica para todas las entidades de negocio Crear una clase personalizada con getters y setters explícitos por cada entidad

DTO GenéricoVentajas:

Solo necesitas una dos clases (instancia, colección) para toda la aplicación El propio lenguaje te proporciona las clases colección (ArrayList, Hashtable, etc.) Puedes hacer componentes de interfaz genéricos (Datagrid para cualquier entidad)

Desventajas: Débilmente tipado, pueden producirse errores en el acceso desde el cliente en tiempo de

ejecución

DTP PersonalizadoSe 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 compilación Soporte en la escritura del código con la utilización del IntelliSense

Desventajas: Se incrementa la programación de un alto número de clases (utilizar generación automática)

Mejor solución de DTOPatron 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 dominioPermite que se pueda reutilizar los DTOs para más de un sistemaNOTA: Estamos obligados si queremos distribuirlo ya que los EN de Nhibernate no son serializables y no pueden enviarse por la red.

Clase personalizada como DTOSe define un DTO para representar cada entidad de negocio, que contenga solo atributos y propiedadesRecomendaciones:Definirlo en un proyecto de biblioteca para que pueda usarse tanto en la capa de interfaz como en el cliente.Para representar colecciones genéricas debemos usar clases de System.Collections como ArrayList, List cuyos objetos sean otra clase DTO personalizada.

Ventajas: Conversión 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 IUDiseño de interfaz de usuario 1--- Windows Presentation Foundation 1ª Parte ---Está basado en la tecnología DirectX (a diferencia de los predecesores en C++).Características Principales:

Separación de la parte del diseñador en un formato de etiquetas (XAML) del resto del código de presentación (Code- behind)‐

Permite la inclusión de componentes multimedia, animación, gráficos 2D y 3D, e incluso páginas Web

Incluye enlace de datos (data binding) de muchos controles y sus propiedades Introduce características de accesibilidad e internacionalización Permite separar el diseño en un fichero XML separado (al estilo CSS) permitiendo estrategias

de jerarquías de estilos

XAML y Code-Behind Una mejora evidente es la capacidad para programar una aplicación mediante código de

lenguaje marcado (XML) y separado de código subyacente (C#), una experiencia similar a las aplicaciones Web.

Esta separación de responsabilidades permite que personas o herramientas encargadas del diseño se enfoquen en el lenguaje de marcado XAML, donde se representa el aspecto de IU.

Las personas con un perfil de programación se encargan del code behind donde se‐ encuentra la definición 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 aplicación de forma declarativa, en una jerarquía de elementos anidados que se denomina árbol de elementos.

Se suele utilizar para crear ventanas, cuadros de diálogo, páginas y controles de usuario, así como para rellenarlos con controles, formas y gráficos.

Permite también 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 botón) y llamar, en respuesta, a la lógica de negocio.

En WPF, este comportamiento se suele implementar en código asociado al marcado. Este tipo de código se denomina subyacente (en inglés, code behind‐ )

Se genera una clase que hereda de Window o Page por cada XAML. La clase tiene un constructor donde se inicializa la visualización de los componentes y un conjunto de métodos y eventos donde se define la parte dinámica.

Controles WPFUn "control" es un término general que se aplica a una categoría de clases de WPF hospedadas en una ventana o una página, tienen una interfaz de usuario (IU) e implementa un comportamiento determinado.

Existen básicamente 2 tipos de controles: Básicos: que no pueden contener a más de un elemento (button, label, textbox, etc.) Complejos: Que con0enen a una colección de elementos (paneles, datagrid, listview, etc.)

Fichero aplicaciónEs un archivo XAML llamado app.xml que define un espacio de recursos y una ejecución inicial (app.xml.cs) para una aplicación WPF. Por ejemplo, podemos situar el estilo de la aplicación WPF Se utiliza este archivo para especificar la ventana que se muestra automáticamente cuando se inicia la aplicación (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 reutilización de las distintas

apariencias en diversos elementos (controles o datos) Los estilos se definen como recursos, dentro de las páginas, ventanas o a nivel de toda la

aplicación 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 ControllerContexto: El propósito de muchas aplicaciones empresariales consiste en recuperar datos almacenados, modificarlos y finalmente persistir dichos cambios.

El flujo principal se encuentra entre la lógica de negocio y el interfaz de usuario Muchas veces se unen las capas para reducir la cantidad de código y mejorar el rendimiento

Esto trae consigo problemas como:Alto acoplamiento, ya que el interfaz cambia con más frecuencia que la lógica de negocioBaja cohesión, el código del interfaz se hace muy complejo al contener lógica de negocio junto a la lógica de presentación

Problema: ¿Cómo se dividiría la funcionalidad de la aplicación para que se pueda fácilmente mantener IU y la lógica de negocio por separado?

Fuerzas: Diseñar el aspecto de las IU se requiere unas habilidades diferentes y personas diferentes al desarrollo de la lógica de negocio.

El código de interfaz de usuario tiende a ser más dependiente de dispositivo que la lógica de negocio. P.e. si queremos migrar nuestra aplicación WPF para Web, Tablet o móvil, debemos remplazar principalmente código de IU y no tanto de lógica de negocio.

Una clara separación de las dos partes acelera la migración y minimiza el código de la lógica de negocio al no haber duplicidad

Solución: El patrón Model-View-Controller (MVC) separa la lógica, la presentación, 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 aplicación, responde las peticiones para la información 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 información de pantalla Controller (Controlador): El controlador interpreta las entradas de teclado y ratón del

usuario, informa al modelo y/o la vista para realizar la acción apropiada

Es importante remarcar: View y Controller dependen de Model, pero Model no depende de ninguno. Esto es una la

clave de la separación y permite a Model ser implementado y probado de forma independiente a la presentación.

La separación 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 código (c#) que maneja los eventos (code-behind)

2 aspectos a destacar: La herramienta Visual Studio .NET en su aproximación WebForm y WPF nos guía para que

utilicemos el MVC El Model mostrado está implementado por el componente fachada de aplicación (CFA) (sea

local o remoto) Pero el componente Model podría ser directamente un componente CEN o CP.

Master TemplateContexto: Se decide usar el patrón MVC para separar los componentes del interfaz y de la lógica de negocio.

El MVC con la herramienta VS .NET es fácil de crear, pero está introduciendo una serie de desventajas cuando la aplicación nos crece.

Vista y controlador tienen una relación 1 a 1. Existe mucho código común en diferentes páginas, lo que puede llevar a código duplicado.

Problema: ¿Cuál es la mejor estructura del controlador para aplicaciones moderadamente complejas, y donde deseamos alcanzar el reúso y la flexibilidad evitando la duplicación?

Fuerzas: El código que contienen la mayoría de las páginas o formularios tiene muchos pasos similares: extraer los parámetros de la página, recuperar datos del usuario logueado, añadir cabeceras y pies. Esto conduce a un incremento significativo de duplicación de código.

La apariencia y navegación comunes tienden a mejorar la usabilidad y el reconocimiento de la aplicación. Sin embargo, conducen a la repetición de código de presentación. Es necesaria una mejora en el reuso de la lógica de presentación a través de las pantallas de IU.

Basado en el patrón Master Template definido por Jim Conallen (2003). Originariamente definido para Web. Master Template permite crear una apariencia consistente para todas las páginas de una

aplicación. Una única plantilla establece la apariencia (cabecera, pie, contenido, etc.) y la funcionalidad

común que deseas para las páginas. La página principal (una window) contiene los fragmentos comunes para todas las páginas Dicha página contiene las referencias a las partes dinámicas mediante Frames (Cabecera,

Menu, Contenido, Pie, etc.). Cada una de las páginas específicas será a su vez una page de XAML, y tendrá su propio

controlador. El controlador de la página maestra (window) define las tareas comunes a todas las páginas.

Creamos una página XAML (Page): No es una página completa sino que únicamente va a representar un fragmento de página Sin embargo, va tener un controlador asociado como cualquier pagina

Ventajas: La división de las diferentes partes permite reducir el código duplicado, y dejar la parte

común en la window (Vease un menú en la cabecera, un pie de notificaciones, etc.). Queda el código mucho más estructurado en las vistas.

Desventajas: La comunicación entre la Window y sus Pages, y sobre todo la comunicación entre diferentes

pages. Se requiere el paso de parámetros por constructor o propiedad entre diferentes pages.

Model View PresenterContexto

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 reutilización para diferentes vistas

El controlador del MVC es difícil de mantener al no poderse probar separadamente del interfaz de usuario

Problema: ¿Cómo proveemos de una separación en el Interfaz de Usuario que facilite la reutilización del controlador, permita realizarle pruebas y mejore la separación IU y Lógica?

Fuerzas: Deseamos que las vistas puedan ser testeadas mediantes técnicas de automatización de

pruebas Deseamos compartir código del controlador entre pantallas (incluso de diferente tecnología)

que requieren el mismo comportamiento Aumentar la separación entre el interfaz y la lógica de negocio (View y Model) permite hacer

el código más fácil de mantener

Solución: Separar las responsabilidades de la visualización del IU y la gestión de eventos en diferentes

clases, llamadas respectivamente View y Presenter La clase View gestiona los controles en la página, captura los eventos y redirige las

peticiones a la clase Presenter (View sería el XAML y el code-behind) El presenter contiene la lógica que responde a las peticiones de la vista (carga y modificación

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 tecnología, o por mock, permitiendo así realizar tests funcionales (Patrón Dependency Injection)

El Presenter puede comunicarse con la vista y con el modelo, pero la vista es completamente independiente del modelo (a diferencia del patrón MVC)

Estrategia: Implementamos el mismo ejemplo Petstore utilizado en los patrones anteriores. La aplicación comienza eligiendo la categoría y consultando sus productos relacionados MVP se combina con Master Template, definiendo un Presenter para la página principal y

uno para cada página 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 métodos 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 Implementación: Si utilizamos el patrón 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 navegación. 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 automatización de las pruebas del presenter

Desventajas: No provee un mecanismo para unificar el flujo del data binding como hace el Model-view

Viewmodel

Diseño 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 conexión entre la UI de la aplicación 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 están enlazados a ellos reflejan los cambios automáticamente.

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 ilustración siguiente:

Elementos del enlace de datosNormalmente, cada enlace 0ene estos cuatro componentes:

1. un objeto de destino del enlace2. una propiedad de destino 3. un origen del enlace4. 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 inicialización, es decir, la

primera vez que se carga la página Twoway: permite que los cambios realizados en la propiedad de origen o en la de destino se

actualicen automáticamente 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 actualización 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 más 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 método del Code Behind‐ UpdateSource

Ejemplo: Controles TextBox en un formulario modificable (sólo actualiza los valores de origen cuando el usuario hace clic en el botón de envío)

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: Sólo los objetos DependencyObject pueden definir propiedades de dependencia es decir que

permiten enlace de datos La mayoría de los controles heredan de UIElement que a su vez se derivan de

DependencyObject Por ello, la mayoría de las propiedades de los componentes visuales, excepto las de sólo

lectura, admiten el enlace de datos de forma predeterminada

Validación de datos Las aplicaciones que toman datos proporcionados por el usuario requieren lógica de

validación para asegurarse de que el usuario ha escrito la información esperada. Las comprobaciones de validación pueden basarse en el tipo, intervalo, formato u otros

requisitos específicos de la aplicación

Existen 2 maneras de introducir la validación:

Asociando una clase validación 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

Validación personalizada El modelo de enlace de datos de WPF permite asociar reglas de validación 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 validación denominada AgeRangeRule, de tal forma que si el usuario especifica caracteres no numéricos o un valor menor que 21 o mayor que 130 se indica el error

--- Patrones de interfaz de usuario 2ª Parte ---

Model View ViewmodelContexto:

Debemos elegir la arquitectura de Interfaz de Usuario de una aplicación con interfaz rico que contiene mucha interacción entre el interfaz de usuario y los datos de la aplicación

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 código que realiza todas las funciones en la vista hace que se complique en exceso Sin embargo, debemos mantener el alto nivel de interacción que requiere dicha interfaz Se hace muy difícil compartir código entre las vistas que requieren el mismo

comportamiento, dificultando su mantenimiento y sus pruebas

Fuerzas: Se quiere maximizar el código que puede ser probado automáticamente Se quiere compartir código entre las vistas que tienen el mismo comportamiento Se desea separar la lógica de negocio de la lógica de presentación para hacer un código más

entendible y mantenible

Problema: ¿Se puede hacer una arquitectura de presentación para las interfaces ricas que mejore el mantenimiento y las pruebas?

Solución: Patrón Presentation Model [Fowler, 2004] o Model View Viewmodel (MVVM)Propone una separación de responsabilidades en la interfaz de usuario:

La representación visual en el componente View El estado del interfaz y el comportamiento en el componente Viewmodel La lógica 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 actúa como una fachada del modelo con el estado y el comportamiento de la IUEl Viewmodel encapsula el acceso al modelo proveyendo una interfaz publica que es fácil 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 también 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 Además, incluyen eventos NotifyPropertyChanged que generan un evento cada vez que se

modifica una propiedad Un UIEntity siempre tiene dos constructores, uno vacío que se utilizara para acceder a los

servicios y otro al que se le pasa un DTO como parámetro el cual dará acceso a los datos de ese DTO

DTO es dependiente de la comunicación 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 aplicación (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 métodos, propiedades y comandos

Se enlazan también los comandos, aplicando el patrón 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 navegación como la actualización de los datos se hace desde el viewmodel El enlace de datos de los controles de la vista, se realizan a través 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 trío Esta separación permite que el modelo se limite a contener los datos, sin preocuparse de

formatos La vista sólo tiene que presentar los datos El viewmodel trabaja como intermediario recibiendo información de la vista e insertándola

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 acción desde el

interfaz Invoca a los UIEntity para las acciones de servidor Notifica mediante eventos cuando quiere actualizar la interfaz

Command en ViewmodelSe 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 patrón command el cual permite asociar una funcionalidad realizada en el Viewmodel y declarada desde la vista (en el XAML)

Para implementar el patrón command hay 2 alternativas:1. Implementar una inner class que implemente el interfaz ICommand. El uso de RelayCommand que permite pasar la implementación de los métodos por delegación en su constructor2. La segunda alternativa permite tener un código mucho más sencillo y la utilización de la notación lambda

El viewmodel define una propiedad para cada enlace de datos que se defina en la vista (filtra las que el modelo tiene)