Hide Notes 

Slide 1: Contextualización de las arquitecturas distribuidas
Slide 2: Modelos de Programación. Programación no Estructurada. Programación Estructurada. Programación Orientada a Objetos. El modelo MFC. Programación Orientada a Componentes. El modelo Java-Beans. El modelo COM. MFC. ATL.
Slide 3: Modelos de Computación Computación Monopuesto. Computación Multicapa. Computación Distribuída.
Slide 4: Computación Multicapa Computación Cliente-Servidor o Two Tier (2 capas). Computación Three Tier (3 capas). Computación n-Tier (n capas). Internet.
Slide 5: Internet/Intranet HTML. CGI. La Arquitectura Java/J2EE. La Arquitectura Windows DNA (Distributed iNternet Applications). La Arquitectura .NET. XML.
Slide 6: La Arquitectura Java/J2EE. El lado del Cliente. Applets. El lado del Servidor. La lógica de negocio. Aplicaciones. Servlets. JSPs (Java Server Pages). Beans EJBs Web Services (J2EE 1.4) El servidor de Datos. JDBC
Slide 7: La Arquitectura Windows DNA (Distributed iNternet Applications). El lado del Cliente. Controles ActiveX. El lado del Servidor. La lógica de Negocio. ISAPI. ASPs (Active Server Pages). MTS. El servidor de Datos. ODBC. DAO. RDO. ADO.
Slide 8: La Arquitectura .NET. De ATL/COM a .NET. El lado del Cliente. WinForms. El lado del Servidor. La lógica de Negocio. WebForms. ASP.NET COM+ Componentes .NET Web Services El servidor de Datos. ADO.NET
Slide 9: Computación Distribuída. CORBA. RMI. DCOM. XML/SOAP.
Slide 10: Computación Distribuída.
Slide 11: Computación Distribuída.
Slide 12: TOO Tecnologia Orientada a Objetos
Slide 13: Objetivos  Objetivos  Historia de los lenguajes orientados a Objetos  Evolución del modelo de Objetos  Fundamentos del modelo de Objetos  Elementos del modelo de Objetos  Estado actual de las tecnologías orientadas a Objetos  Perspectivas Futuras
Slide 14: Too (Oot) La Tecnología Orientada a Objetos no sólo se aplica a los lenguajes de programación, sino que también se ha propagado a los métodos de análisis y diseño y a otras áreas tales como las bases de datos y/o las comunicaciones. Por lo tanto, para hacer desarrollo de sistemas de software basados en la TOO (OOT), hay que entender bien todos los conceptos del modelo de objetos que hay detrás de ella y sus antecedentes históricos.
Slide 15: Historia de los lenguajes Orientados a Objetos El primer lenguaje que introdujo los conceptos de orientación a objetos fue SIMULA 67 creado en Noruega, por un grupo de investigadores dirigido por O. J. Dahl y K. Nygaard, con el fin de realizar simulaciones discretas de sistemas reales. En estos tiempos no existían lenguajes de programación que se ajustaran a sus necesidades, así que se basaron en el lenguaje ALGOL 60 y lo extendieron con conceptos de objetos, clases, herencia, el polimorfismo por inclusión (que se obtiene introduciendo la herencia de clases) y procedimientos virtuales (permiten sobrecarga de procedimientos). El lenguaje fue utilizado sobre todo en Europa y no tuvo mucho impacto comercial, sin embargo los conceptos que se definieron en él, se volvieron sumamente importantes para el futuro del desarrollo de software.
Slide 16: Historia de los lenguajes Orientados a Objetos Alrededor de los años 70´s fue desarrollado el lenguaje de programación OO llamado SMALLTALK en los laboratorios Xerox de Palo Alto. Este lenguaje ayudó a que se introdujera a nivel mundial el término de Orientación a Objetos (Object Oriented) y que cobrara importancia entre los diseñadores de lenguajes de programación. El punto más importante de este lenguaje fue el hecho de adoptar el concepto de objeto y clase como núcleo del lenguaje. Un punto a reseñar es que era un lenguaje interpretado.
Slide 17: Historia de los lenguajes Orientados a Objetos En 1985, Bjarne Stroustrup extendió el lenguaje de programación C a C++, es decir C con conceptos de clases y objetos. También por esta fecha, Bertrand Meyer creó el lenguaje EIFFEL desde las bases de C. Ambos manejan conceptos de objetos y herencia de clases. La herencia es múltiple, y se introduce pensando en dar mayor flexibilidad a los desarrolladores. Sin embargo, actualmente la herencia múltiple se ha evitado por agregar complejidad en las estructura de clases.
Slide 18: Historia de los lenguajes Orientados a Objetos El lenguaje de programación C++ • Lenguaje Orientado a Objetos híbrido • Mantiene compatibilidad en parte con el lenguaje C permitiendo el uso de funciones libres y de clases • Es un C mejorado • Soporta programación genérica • Lenguaje compilado muy eficiente y rápido • El código generado debe compilarse específicamente para cada sistema operativo y plataforma • Es muy extenso y con bastantes peculiaridades
Slide 19: Historia de los lenguajes Orientados a Objetos Primer ejemplo en C++ // Hola.cpp // Primer programa en C++ // Emite el saludo “Hola a todos” // incluye la biblioteca de Entrada/Salida #include <iostream> using namespace std; //Para usar la biblioteca estándar int main() { cout << "Hola a todos\n"; return 0; }
Slide 20: Historia de los lenguajes Orientados a Objetos • Para compilar con el compilador de GNU (www.gnu.org) en linux $ g++ -o Hola.out Hola.cpp • Para ejecutar el programa $./Hola.out
Slide 21: Historia de los lenguajes Orientados a Objetos En 1995 apareció JAVA, desarrollado por SUN, que hereda conceptos de C++, pero los simplifica y evita la herencia múltiple. A cambio se introduce el término de interfaz, y la herencia múltiple de interfaces. Java obtuvo una rápida aceptación gracias a los applets, que son programas en JAVA insertados dentro del código HTML de una página WEB. Java introduce también, la programación concurrente y distribuida. El lenguaje es interpretado, dando como resultado la portabilidad a distintas plataformas.
Slide 22: Historia de los lenguajes Orientados a Objetos El lenguaje de programación Java • Lenguaje Orientado a Objetos puro • Todo el código se organiza en clases • Se pueden ejecutar las clases independientemente, lo que facilita la prueba unitaria de cada clase • Puede haber tantas funciones main( ) como clases. • Lenguaje interpretado independiente de plataforma y sistema operativo • Relativamente pequeño y con una biblioteca de clases muy grande
Slide 23: Historia de los lenguajes Orientados a Objetos Primer ejemplo en Java /* Hola.java Primer programa en Java Emite el saludo “Hola” */ class Hola { public static void main (String[] args) { System.out.println( "Hola” ); } }
Slide 24: Historia de los lenguajes Orientados a Objetos • Para compilar con el compilador de SDK $ javac Hola.java • Genera un fichero denominado Hola.class • Este fichero está en un formato binario denominado bytecode • Para ejecutar el programa se interpreta el fichero Hola.class $ java Hola
Slide 25: Historia de los lenguajes Orientados a Objetos En el año 2000, como respuesta de Microsoft al mundo Java, apareció el lenguaje C#. C# es el lenguaje pensado para la plataforma .NET de Microsoft. Sus características son similares a las de Java. El hecho de estar avalado por Microsoft y poder ser utilizado en la plataforma .NET puede convertirlo en uno de los lenguajes de programación orientados a objetos más utilizados.
Slide 26: Historia de los lenguajes Orientados a Objetos Primer ejemplo en C# /* Hola.cs Primer programa en C# Emite el saludo “Hola” */ class Hola { public static void Main() { System.Console.WriteLine(“Hola”); } }
Slide 27: Historia de los lenguajes Orientados a Objetos • Para compilar con el compilador de SDK C:...\> csc Hola.cs • Genera un fichero denominado Hola.exe • Este fichero está en un formato binario denominado IL (Intermediate Language ) • Para ejecutar el programa se interpreta el fichero Hola.exe C:...\> Hola
Slide 29: Evolución del modelo de objetos Tendencias en ingeniería del software [Booch 94] Hay una correspondencia entre la evolución de la ingeniería del software y la evolución de los lenguajes de alto nivel.
Slide 30: Evolución del modelo de objetos Topología de los lenguajes de la primera generación y principios de la segunda (FORTRAN y COBOL) – Datos globales y subprogramas • Sólo soportaban paso de parámetros por dirección • Un error en una parte de un programa puede tener un devastador efecto de propagación a través del resto del sistema, porque las estructuras de datos globales están expuestas al acceso de todos los subprogramas • Cuando se realizan modificaciones en un sistema grande, es difícil mantener la integridad del diseño original
Slide 31: Evolución del modelo de objetos
Slide 32: Evolución del modelo de objetos Topología de los lenguajes de finales de la segunda generación y principios de la tercera (PASCAL y C) – Nuevos mecanismos de paso de parámetros (paso por valor) – Se asentaron los fundamentos de la programación estructurada • Los lenguajes permiten anidar subprogramas • Se permiten variables locales introduciendo los conceptos de ámbito y visibilidad de las declaraciones • Se avanza en las estructuras de control de flujo – Surgen los métodos de diseño estructurado descendente • Se construyen grandes programas utilizando los subprogramas como bloques físicos de construcción
Slide 33: Evolución del modelo de objetos Esta topología es una variante más refinada de la anterior mejorando el control sobre las abstracciones algorítmicas, pero sigue fallando a la hora de superar los problemas de la producción de software a gran escala.
Slide 34: Evolución del modelo de objetos Topología de los lenguajes de finales de la tercera generación (Modula-2) – Introducen los módulos compilados separadamente • Inicialmente son contenedores arbitrarios de datos y subprogramas • Aparecen extensiones para otros lenguajes (por ejemplo en Pascal se incorporan las units) • Tenían pocas reglas que exigiesen una consistencia semántica entre los interfaces de los módulos – Desembocan en la definición de Tipos Abstractos de Datos (TAD)
Slide 35: Evolución del modelo de objetos – Aparecen los métodos de diseño dirigido por los datos (Jackson, Warnier) • Proporcionaron una aproximación disciplinada a los problemas de realizar abstracciones de datos en lenguajes orientados algoritmicamente
Slide 36: Evolución del modelo de objetos Topología de los lenguajes basados en objetos y orientados a objetos (ADA, Object Pascal, Smalltalk, Eiffel, C++, Java) – Introducen los conceptos de clase y objetos – Los lenguajes basados en objetos no tienen herencia ni polimorfismo – Los lenguajes orientados a objetos cumplen las características básicas del modelo de objetos – El bloque físico de construcción de estos lenguajes es el módulo, que contiene una agrupación de clases y objetos – En sistemas muy complejos las clases, objetos y módulos proporcionan un medio esencial, pero, aun así, insuficiente de abstracción
Slide 37: Evolución del modelo de objetos
Slide 38: Evolución del modelo de objetos Topología de aplicaciones utilizando componentes (ActiveX, JavaBeans, Componentes .NET) – Sistemas operativos y lenguajes de programación soportan directamente el concepto de componente – Un componente es una parte física y reemplazable de un sistema con un conjunto de interfaces y proporciona la implementación de dicho conjunto • Un componente representa típicamente el empaquetamiento físico de diferentes elementos lógicos, como clases, interfaces y colaboraciones – El desarrollo orientado a objetos proporciona la base fundamental para ensamblar sistemas a partir de componentes
Slide 39: Evolución del modelo de objetos
Slide 40: Evolución del modelo de objetos Ingeniería web (Murugesan et al.: proceso utilizado para crear, implantar y mantener aplicaciones y sistemas Web de alta calidad) – Lenguajes y especificaciones para aplicaciones en la web – Lenguajes de marcas: HTML, XML y SGML – Lenguajes de programación (Java y C# ) – Tecnologías Java y .NET – Lenguajes de script (ASP, JavaScript) – Applets y Servlets – Computación ubicua
Slide 41: Evolución del modelo de objetos
Slide 42: Fundamentos del modelo de objetos Programación orientada a objetos (POO) [Booch 94] Es un método de implementación en el que los programas se organizan como colecciones cooperativas de objetos, cada uno de los cuales representa una instancia de alguna clase, y cuyas clases son, todas ellas, miembros de una jerarquía de clases unidas mediante relaciones de herencia Diseño orientado a objetos (DOO) [Booch 94] Es un método de diseño que abarca el proceso de descomposición orientada a objetos y una notación para describir los modelos lógico y físico, así como los modelos estático y dinámico del sistema que se diseña Análisis orientado a objetos (AOO) [Booch 94] Es un método de análisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema
Slide 43: Fundamentos del modelo de objetos
Slide 44: Fundamentos del modelo de objetos Análisis Orientado a Objetos Esta orientado a definir el problema, intentando el mejor entendimiento con el cliente Preguntas que se deben plantear • ¿Cuál es el comportamiento que se desea en el sistema? • ¿Qué objetos existen en el sistema? • ¿Cuáles son las misiones de los objetos para llevar a cabo el comportamiento deseado del sistema?
Slide 45: Fundamentos del modelo de objetos Diseño Orientado a Objetos Esta orientado a construir un modelo que permita razonar sobre el problema y guiar la implementación Preguntas que se deben plantear Modelo lógico • ¿Qué clases existen y como se relacionan estas clases? • ¿Qué mecanismos se utilizan para regular la forma en que los objetos colaboran? Modelo físico • ¿Dónde debería declararse y construirse cada clase y objeto? • ¿A qué procesador debería asignarse un proceso, y para un procesador dado, cómo deberían planificarse sus múltiples procesos?
Slide 46: Fundamentos del modelo de objetos
Slide 47: Fundamentos del modelo de objetos Método y metodología “Un método es un proceso disciplinado para generar un conjunto de modelos que describen varios aspectos de un sistema de software en desarrollo, utilizando alguna notación bien definida” [Booch 94] • “Una metodología es una colección de métodos aplicados a lo largo del ciclo de vida del desarrollo de software y unificados por alguna aproximación general o filosófica” [Booch 94]
Slide 48: Fundamentos del modelo de objetos Cada metodología puede catalogarse en uno de los grupos siguientes: • Diseño estructurado descendente – Yourdon y Constantine – Wirth – Dahl, Dijkstra y Hoare • Diseño dirigido por datos – Jackson – Warnier y Orr • Diseño orientado a objetos son las que siguen el modelo de objetos – Booch – OMT (Rumbaugh et al.) – Objectory (Jacobson et al.) – Schlaer-Mellor – Coad/Yourdon – Fusion (Coleman et al.) – Métrica - 3
Slide 49: Fundamentos del modelo de objetos Notaciones “Una notación es un conjunto de diagramas normalizados que posibilita al analista o desarrollador el describir el comportamiento del sistema (análisis) y los detalles de una arquitectura (diseño) de forma no ambigua” [Booch 94] – La acción de dibujar un diagrama no constituye ni análisis ni diseño – Una notación no es un fin por si misma – El hecho de que una notación sea detallada no significa que todos sus aspectos deban ser utilizados en todas las ocasiones – La notación son como los planos para un arquitecto o un ingeniero – Una notación no es más que un vehículo para capturar los razonamientos acerca del comportamiento y la arquitectura de un sistema – Las notaciones deben ser lo más independientes posibles de los lenguajes de programación, sin embargo facilita el proceso de desarrollo que exista una equivalencia entre la notación y los lenguajes de programación
Slide 50: Fundamentos del modelo de objetos Evolución de las notaciones • La popularidad de las tecnologías de objetos ha generado docenas de metodologías de AOO y DOO • Cada metodología tenia su propia notación • La tendencia actual es separar la metodología de la notación y adoptar una notación estándar, papel que pretende adoptar UML
Slide 51: Fundamentos del modelo de objetos
Slide 52: Fundamentos del modelo de objetos Unified Modeling Language (UML) [Rational] [Booch 99] [OMG] • UML es el sucesor de la ola de notaciones de A y DOO que aparecieron a finales de los 80 y principios de los 90 • UML unifica principalmente las notaciones de Booch, Rumbaught (OMT) y Jacobson. Pero pretende dar una visión más amplia de los mismos • UML está definido como estándar por el OMG (Object Management Group) [OMG] • UML es un lenguaje de modelado, no un método ni una metodología. • UML es un lenguaje para – Visualizar – Especificar – Construir – Documentar
Slide 53: Fundamentos del modelo de objetos • Un método incluye – Lenguaje de modelado: Es la notación (en su mayoría métodos para expresar los diseños. gráfica) que utilizan los diseño – Proceso: Son los pasos que se aconsejan dar para realizar un
Slide 54: Fundamentos del modelo de objetos Modelado orientado a objetos [Booch 99, capítulos 1y 2] • Un modelo es una representación simplificada de la realidad • Construimos modelos para comprender mejor el sistema que estamos desarrollando • Es necesario observar el modelo desde distintas vistas, que tiene que ser compatibles entre sí – Al igual que en un plano se tienen varias perspectivas (planta, perfiles) compatibles entre sí. alzado, • La arquitectura de un sistema orientado a objetos puede describirse con cinco vistas interrelacionadas – Vista de casos de uso, vista de diseño, vista de procesos, implementación, vista de despliegue vista de • Cada vista del modelo que resulta del diseño orientado a objetos es un conjunto de diagramas
Slide 55: Fundamentos del modelo de objetos • Estos diagramas permiten razonar sobre el comportamiento del sistema • Cuando el modelo es estable cada uno de los diagramas permanece semánticamente consistente con el resto de los diagramas
Slide 56: Fundamentos del modelo de objetos Arquitectura de sistemas orientados a objetos [Booch 99, capítulos 1,2, 31] • La arquitectura de un sistema orientado a objetos puede describirse con cinco vistas interrelacionadas – Vista de casos de uso • Muestra los requisitos del sistema tal como es percibido los usuarios finales, analistas, y encargados de pruebas. – Vista de diseño • Captura el vocabulario del espacio del problema y del espacio de la solución – Vista de procesos • Modela la distribución de los procesos e hilos (threads) – Vista de implementación • Modela los componentes y archivos que se utilizan para ensamblar y hacer disponible el sistema físico. por
Slide 57: Fundamentos del modelo de objetos – Vista de despliegue • Modela los nodos de la topología hardware sobre la que ejecuta el sistema • Cada una de estas vistas representan los planos del sistema • Según la naturaleza del problema unas vistas tendrán más peso que otras. Así por ejemplo: – Los sistemas con grandes cantidades de datos dominaran las – Los sistemas con uso intensivo de interfaces gráficas de usuario vistas de casos de uso – Los sistemas de tiempo real las vistas de procesos tienden a ser importantes – En los sistemas distribuidos las vistas de implementación y a un plano importante vistas de diseño dominarán las las más despliegue pasan se
Slide 58: Fundamentos del modelo de objetos Ciclo de vida del desarrollo de software Metodología: Proceso Unificado de Rational [Booch 99, capítulo 2, apendice C] [Jacobson 99] • Se caracteriza por – Está dirigida por los casos de uso • Se utilizan para establecer el comportamiento deseado por el sistema, para verificar y validar la arquitectura del sistema, para las pruebas y para la comunicación entre las personas del proyecto – Centrado en la arquitectura • La arquitectura se utiliza para conceptualizar, construir, gestionar y hacer evolucionar el sistema en desarrollo
Slide 59: Fundamentos del modelo de objetos – Iterativo e incremental • Proceso iterativo es aquél que involucra la gestión de un flujo de ejecutables • Proceso incremental es aquél que involucra la continua integración de la arquitectura del sistema para producir esos ejecutables, donde cada ejecutable incorpora mejoras incrementales sobre los otros. • Un proceso iterativo e incremental está dirigido por el riesgo, lo que significa que cada versión se encarga de atacar y reducir los riesgos más significativos para del proyecto el éxito
Slide 60: Fundamentos del modelo de objetos • Se descompone en fases – Una fase es el intervalo de tiempo entre dos hitos importantes del proceso, cuando se cumplen un conjunto de objetivos bien definidos, se completan los artefactos y se toman las decisiones sobre si pasar o no a la siguiente fase • Hay cuatro fases – Iniciación – Elaboración – Construcción – Transición • Una iteración es un conjunto bien definido de actividades, con un plan y unos criterios de evaluación bien establecidos, que acaba en una versión, bien interna o externa
Slide 61: Fundamentos del modelo de objetos
Slide 62: Fundamentos del modelo de objetos
Slide 63: Fundamentos del modelo de objetos Herramientas CASE (Computer Aided/assisted Software/System Engineering) [Piattini 96] • La tecnología CASE persigue la automatización del desarrollo de software • Las herramientas CASE permiten mejorar la calidad y la productividad de los sistemas de información • Permitir la aplicación práctica de metodologías, lo que resulta muy difícil sin emplear herramientas. • Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones. • Simplificar el mantenimiento de los programas. • Mejorar y estandarizar la documentación. • Aumentar la portabilidad de las aplicaciones. • Facilitar la reutilización de componentes software. • Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilización de gráficos
Slide 64: Fundamentos del modelo de objetos Elementos de una herramienta CASE • Repositorio (diccionario) • Análisis Orientado a Objetos • Diseño Orientado a Objetos • Pruebas • Métricas • Generador de documentación • Generador de código • Consistencia Semántica • Interfaz de usuario
Slide 65: Fundamentos del modelo de objetos
Slide 66: Fundamentos del modelo de objetos Criterios de selección de herramientas CASE • Soporte completo de una notaciones • Interfaz de usuario amigable – Consistente con la notación – Debe realizar comprobaciones mientras se está diseñando • Ejemplo: No debe permitir que una clase padre herede de una clase hija • Generación de código automático – Normalmente generan declaraciones y algunos métodos básicos como constructores y destructores • Ingeniería inversa a partir de código legado o código generado – A partir de ficheros con programas se obtiene los esquemas de – Cambios en el código implican cambios en la notación la notación
Slide 67: Fundamentos del modelo de objetos • Seguimiento de los requisitos – Reflejar en el diseño y en el código los requisitos • Generación automática de la documentación de la aplicación – La documentación producida debe ser • Completa • Bien diseñada, cómoda de utilizar y de usar • Personalizable (se genera en formatos estándar que pueden ser manejados por herramientas de maquetación estándar) • Comprobación de la consistencia y completitud entre todas las vistas del sistema • Ayuda en línea completa • Buena documentación de la herramienta
Slide 68: Fundamentos del modelo de objetos Herramienta Rational Rose ® • Permite el uso de la notación UML • Genera varios lenguajes: Java, C++, Visual Basic, ... • Soporta el desarrollo basado en componentes • Permite el trabajo en equipo
Slide 69: Fundamentos del modelo de objetos Herramienta Microsoft Visio ® • Permite el uso de la notación UML • Genera varios lenguajes: Java, C++, Visual Basic, ... • Soporta el desarrollo basado en componentes • Permite el trabajo en equipo
Slide 70: Elementos del modelo de objetos Elementos fundamentales – Abstracción – Encapsulación y ocultación de la información – Modularidad – Jerarquía (herencia, polimorfismo y agregación)
Slide 71: Elementos del modelo de objetos Elementos secundarios – Tipos (control de tipos) – Concurrencia – Persistencia – Distribución – Sobrecarga – Genericidad – Manejo de excepciones
Slide 72: Elementos del modelo de objetos Elementos relacionados – Componentes – Patrones de diseño
Slide 73: Elementos del modelo de objetos Abstracción Una abstracción denota las características esenciales de un objeto que lo distinguen de todos los demás tipos de objeto y proporciona así fronteras conceptuales nítidamente definidas respecto a la perspectiva del observador [Booch 94]
Slide 74: Elementos del modelo de objetos Abstracción • En la abstracción obtenemos objetos del mundo real de los cuales enfatizaremos algunos detalles o propiedades mientras suprimiremos otros • También nos fijaremos en el comportamiento de los objetos para definir las acciones u operaciones que son capaces de realizar • Los objetos en el sistema se deben de tratar como seres vivos que nacen (constructores), viven (están activos), duermen (están pasivos), se reproducen (copia de objetos), y mueren por eutanasia (destructores) o por inanición (recolector de basura) • Ejemplo de objetos: una factura, un albarán, un usuario, ... • A partir de objetos que tienen unas propiedades y acciones comunes se deben abstraer las clases. • En las clases se definen las propiedades y operaciones comunes de los objetos
Slide 75: Elementos del modelo de objetos
Slide 76: Elementos del modelo de objetos
Slide 77: Elementos del modelo de objetos Identidad de objetos En las clases deben diseñarse atributos de forma que permitan identificar a los objetos de manera única
Slide 78: Elementos del modelo de objetos Mensajes Una aplicación orientada a objetos consiste en un número determinado de objetos que interactúan entre si enviándose mensajes unos a otros para invocar sus métodos. Este intercambio de mensajes facilita su comportamiento, cambios de estado, destrucción o almacenamiento. Ya que todo lo que un objeto puede realizar está expresado en sus métodos, este simple mecanismo de mensajes soporta todas las posibles interacciones entre ellos.
Slide 79: Elementos del modelo de objetos Encapsulación Es el proceso de almacenar en un mismo compartimento los elementos de una abstracción que constituyen su estructura y su comportamiento; sirve para separar el interfaz contractual de una abstracción y su implementación [Booch 94]
Slide 80: Elementos del modelo de objetos Encapsulación El propósito de la encapsulación es ofrecer una interfaz que garantice que todas las interacciones del objeto tengan lugar a través de un sistema de mensajería predefinido con el que es capaz de entenderse y reaccionar adecuadamente. Para un objeto externo no existe otro modo de acceder a los atributos y métodos escondidos dentro de la interface de mensajes de otro objeto.
Slide 81: Elementos del modelo de objetos Clases Una clase es un conjunto de objetos que comparten una estructura común y un comportamiento común [Booch 94]
Slide 82: Elementos del modelo de objetos Clases • Los atributos y las operaciones pueden ser visibles o no según el detalle deseado • Un atributo es un dato que se almacenará en los objetos que son instancias de la clase. • Un método es la implementación de una operación para la clase • Un adorno de clase es una propiedad por ejemplo indicar que la clase es abstracta (no puede tener instancias, sólo se puede heredar de ella)
Slide 83: Elementos del modelo de objetos • En UML las clases se pueden representar de tres formas: – Sin detalle – Detalles a nivel de análisis y diseño – Detalle a nivel de implementación • Los atributos en UML se pueden describir como: visibilidad : tipo = valor-inicial { propiedad } • donde visibilidad puede ser: – + publico – # protegido – - privado
Slide 84: Elementos del modelo de objetos Ejemplo: Diseño de la clase Perro
Slide 85: Elementos del modelo de objetos Conclusiones para el diseño de clases • Una clase es un tipo definido por el usuario, que permite crear objetos. Las clases tienen miembros formados por campos y métodos. Una struct es una clase con todos los miembros públicos. • Los campos miembro suelen declararse protegidos (protected), salvo en casos especiales que se declaran privados (privated) • Los métodos públicos (public) permiten acceder a los campos miembro desde el exterior de la clase • Los métodos selectores no modifican el valor de los campos miembro. Se suelen denominar: – ver...campoMiembro( ) (en castellano). ¡ ver, pero no tocar ! – get...campoMiembro( ) (en inglés). – Suele declararse un método por cada tipo de campo miembro accesible – Son una garantía para que no se modifiquen accidentalmente los campos miembro
Slide 86: Elementos del modelo de objetos Conclusiones para el diseño de clases • Los métodos modificadores permiten modificar los campos miembro de la clase. Se suelen denominar – pon...campoMiembro( ) (en castellano). – set...campoMiembro( ) (en inglés). – Suele declararse un método por cada tipo de campo miembro accesible – Establecen el camino de cómo se modifican los campos miembro y realizan las comprobaciones necesarias. • Los métodos iteradores permiten recorrer las partes de un objeto
Slide 87: Elementos del modelo de objetos Conclusiones para el diseño de clases • Los constructores crean los objetos – Pueden estar sobrecargados (overload). Se pueden definir varios métodos con el mismo identificador pero que difieran en número o tipo de parámetros. – Se aconseja poner siempre constructores, para saber donde y cuando se crean los objetos. – Se puede poner un mensaje que indique cuando y donde se están construyendo los objetos. Muy aconsejable para depurar programas. • Los destructores se encargan de eliminar los objetos – Se aconseja poner siempre destructores (en C++), para saber donde y cuando se destruyen los objetos. – Se puede poner un mensaje que indique cuando y donde se están destruyendo los objetos. Muy aconsejable para depurar programas
Slide 88: Elementos del modelo de objetos Ocultación de información En una clase debe ser posible especificar que características están disponibles a todos los clientes, a los herederos, a algunos clientes o sólo pueden ser accedidas internamente
Slide 89: Elementos del modelo de objetos Encapsulación y ocultación de información • Con la encapsulación los usuarios de una clase no necesitan conocer los detalles internos de la implementación (a esto último también se denomina ocultación de información) – Por ejemplo las estructuras de datos utilizadas internamente en una clase • Si se modifican los detalles internos de la implementación no es necesario modificar ninguno de los clientes o métodos • Los lenguajes Java, C++ y C# utilizan las palabras reservadas: public, protected y private para realizar el control de acceso o visibilidad de los miembros de una clase. C++ también soporta el concepto de clases y funciones amigas (friends)a las que se les permite el acceso a partes privadas. • “La ocultación es para prevenir accidentes, no para prevenir el fraude”. [Stroustrup 1997, Capítulo 10, epígrafe 10.2.2]
Slide 90: Elementos del modelo de objetos Objetos Un objeto tiene estado, comportamiento e identidad; la estructura y comportamiento de objetos similares están definidos en su clase común; los términos “instancia” y “objeto” son intercambiables [Booch 94]
Slide 91: Elementos del modelo de objetos Objetos • Estado: El estado de un objeto abarca todas las propiedades (normalmente estáticas) del mismo más los valores actuales (normalmente dinámicos) de cada una de esas propiedades • Comportamiento: El comportamiento es cómo actúa y reacciona un objeto, en términos de sus cambios de estado y paso de mensajes. – El estado de un objeto representa los resultados acumulados de su comportamiento
Slide 92: Elementos del modelo de objetos Objetos • Operaciones: Una operación denota un servicio que una clase ofrece a sus clientes.Los tipos de operaciones más frecuentes son: – Modificador: Operación que altera el estado de un objeto – Selector: Operación que accede al estado de un objeto, pero no estado – Iterador: Operación que permite acceder a todas las partes de un objeto en algún orden perfectamente establecido – Constructor: Operación que crea un objeto y/o inicializa su estado – Destructor: Operación que libera el estado de un objeto y/o destruye el propio objeto • Subprogramas libres: En los lenguajes OO puros (Smalltalk, Eiffel, Java, C#) sólo pueden declararse las operaciones como métodos. Sin embargo en los lenguajes OO híbridos (C++, Object Pascal, Ada, CLOS) pueden escribirse subprogramas libres, que en C++ se denominan funciones no miembro, y que en algunos casos se les puede dar ciertos privilegios al declararlas como amigas utilizando la palabra reservada friend. altera este
Slide 93: Elementos del modelo de objetos Objetos • Papeles (roles) y responsabilidades – protocolo: El protocolo es el caparazón externo que define el comportamiento admisible de un objeto. • El protocolo engloba la visión estática y dinámica de un objeto • El protocolo está formado por los métodos de un objeto. En los lenguajes OO híbridos hay que añadir los subprogramas libres (en C++ las funciones amigas) • Para las abstracciones no triviales es útil dividir el protocolo en grupos lógicos de comportamiento denominados papeles (roles) – papeles (roles): Los papeles son los grupos de comportamiento que desempeña un objeto y que constituyen un contrato entre una abstracción y sus clientes – responsabilidades: Las responsabilidades de un objeto son todos los servicios que proporciona para todos los contratos en los que está comprometido
Slide 94: Elementos del modelo de objetos Objetos • Objetos como autómatas finitos. Algunos objetos se caracterizan por el orden en que se invocan sus operaciones, de tal forma que se pueden definir formalmente con un autómata finito. • Identidad: La identidad es aquella propiedad de un objeto que lo distingue de todos los demás objetos – Los identificadores de los objetos pueden servir para distinguir objetos en un programa, pero no sirven para distinguir objetos persistentes cuya vida transciende a la del programa
Slide 95: Elementos del modelo de objetos Tiempo de vida de un objeto • El tiempo de vida de un objeto se extiende desde el momento en que se crea por primera vez (y consume espacio por primera vez) hasta que ese espacio se recupera • En lenguajes con recolección de basura (Smalltalk, Eiffel, CLOS) un objeto se destruye automáticamente cuando todas las referencias a él se han perdido • En lenguajes con asignación y liberación explícita de memoria heap (C++, Object Pascal, Ada) un objeto sigue existiendo y consume espacio incluso si todas las referencias a él han desaparecido • Los objetos persistentes suelen implementarse utilizando una clase aditiva persistente de un marco de aplicación (framework). Así todos los objetos para los que se desea persistencia tienen a esta clase aditiva como superclase en algún punto de su trama de herencia de clases
Slide 96: Elementos del modelo de objetos Modularidad Es la propiedad que tiene un sistema que ha sido descompuesto en un conjunto de módulos cohesivos y débilmente acoplados [Booch 94]
Slide 97: Elementos del modelo de objetos Modularidad • La modularidad es la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes. • Desde el punto de vista de la implementación la modularidad consiste en dividir una aplicación en módulos que se puedan compilar por separado
Slide 98: Elementos del modelo de objetos Modularidad • En Java los módulos se denominan paquetes (package) • En C++ los módulos son archivos compilados por separado. Habitualmente cada módulo consta de dos archivos: – un archivo cabecera con la declaración de las clases (con extensión .h o .hpp) – un archivo de implementación de los métodos de las clases (con extensión .cpp) – Otro nivel de modularidad en C++ son los espacios de nombres (namespaces) • En Ada cada módulo se define como un paquete (package) con dos partes: la especificación y el cuerpo del paquete • En Object Pascal y Delphi los módulos se denominan units y son un archivo único.
Slide 99: Elementos del modelo de objetos Modularidad El diseño modular se puede enunciar con 5 criterios, 5 reglas y 5 principios [Meyer 97] • Los 5 criterios – Descomponibilidad – Componibilidad – Comprensibilidad – Continuidad – Protección • Los 5 principios – Unidades modulares lingüísticas – Auto-documentación – Acceso uniforme – Principio abierto-cerrado – Elección única • Las 5 reglas – Correspondencia directa – Pocas interfaces – Interfaces pequeñas – Interfaces explícitas – Ocultación de la información
Slide 100: Elementos del modelo de objetos Modularidad (Criterios) 1º- Descomponibilidad modular Es la tarea de separar un problema complejo en varios subproblemas menos complejos, conectados por una estructura simple y suficientemente independiente que permita construir cada subproblema separadamente El ejemplo más típico de un método que satisface la descomponibilidad modular es el diseño descendente (Top-down design)
Slide 101: Elementos del modelo de objetos Modularidad (Criterios) 2º - Componibilidad modular Es la resolución de problemas por la composición de módulos previamente desarrollados
Slide 102: Elementos del modelo de objetos Modularidad (Criterios) 3º - Comprensibilidad Un método favorece la comprensibilidad modular si ayuda a producir software que permite comprender cada módulo por separado sin tener que conocer los otros, o en el caso peor tener que examinar sólo alguno de los otros módulos. 4º - Continuidad Un método satisface la continuidad modular si un pequeño cambio en las especificaciones del problema obliga a modificar un módulo o un pequeño número de módulos. 5º - Protección Un método satisface la protección modular si en el caso de que ocurra un anormal comportamiento en tiempo de ejecución éste se detecta en un módulo, o en el caso peor se propaga a unos pocos módulos vecinos.
Slide 103: Elementos del modelo de objetos Modularidad (Reglas) 1º - Correspondencia directa La estructura modular concebida en el proceso de construcción del sistema de software debe permanecer compatible con cualquier estructura modular creada en el proceso de modelado del dominio del problema Esta regla sigue especialmente dos criterios: • Continuidad: Conservando la traza de la estructura modular del problema será más fácil aquilatar y limitar los impactos de los cambios. • Descomponibilidad: El trabajo realizado para analizar la estructura modular del dominio del problema puede ser un buen punto de comienzo para la descomposición modular del software.
Slide 104: Elementos del modelo de objetos Modularidad (Reglas) 2º - Pocas interfaces Todo módulo debe comunicarse con el menor número de módulos posibles. Esta regla sigue especialmente dos criterios: • Continuidad: El efecto de los cambios se propaga al número módulos • Protección: El efecto de los errores se propaga al número menor de módulos menor de Si un sistema está compuesto de n módulos el número de conexiones entre módulos es: • n-1 (fig. A) Mínimos enlaces, pero demasiado centralizada • n(n-1)/2 (fig. B) Caso peor • n (fig. C) Tiene enlaces con los módulos vecinos, pero no está centralizado
Slide 105: Elementos del modelo de objetos Modularidad (Reglas) 3º - Interfaces pequeñas Si dos módulos intercambian información, esta debe ser la menor posible Esta regla sigue especialmente dos criterios: • Continuidad: El efecto de los cambios se propaga al número menor de módulos • Protección: El efecto de los errores se propaga al número menor de módulos
Slide 106: Elementos del modelo de objetos Modularidad (Reglas) 4º - Interfaces explícitas Si dos módulos intercambian información, esta debe ser obvia desde la perspectiva de cada módulo y desde una perspectiva global a ambos. Esta regla sigue especialmente los criterios: • Descomponibilidad: Si es necesario descomponer un módulo en varios submódulos cualquier conexión entre ellos debe ser claramente visible • Componibilidad: Si es necesario componer un módulo con varios submódulos cualquier conexión entre ellos debe ser claramente visible • Continuidad: Facilita encontrar los elementos que pueden ser afectados por cambios. • Compresibilidad: Facilita la comprensión de cada módulo y de todos los módulos relacionados con dicho módulo.
Slide 107: Elementos del modelo de objetos Modularidad (Reglas) 5º - Ocultación de información El diseñador de un módulo debe seleccionar un subconjunto de propiedades de cada módulo como información oficial del módulo, esta información estará disponible para los autores de los módulos clientes. El resto de la información es secreta. Esta regla sigue especialmente el criterio: • Continuidad: Los cambios de un módulo se tratarán de hacer en la parte secreta, pero no en la interfaz o parte pública.
Slide 108: Elementos del modelo de objetos Modularidad (Principios) 1º - Unidades modulares lingüísticas Los módulos deben corresponderse con unidades sintácticas en el lenguaje utilizado. El lenguaje puede ser: • Un lenguaje de programación (los módulos deben poder compilarse por separado) • Un lenguaje de diseño • Un lenguaje de especificación,...
Slide 109: Elementos del modelo de objetos Modularidad (Principios) 1º - Unidades modulares lingüísticas Este principio sigue especialmente los criterios y reglas: • Continuidad: Para asegurar la continuidad debe haber una correspondencia directa entre los módulos de especificación, diseño e implementación. • Correspondencia directa: Se mantiene una correspondencia muy clara entre la estructura del modelo y la estructura de la solución. • Descomponibilidad: Se asegura que cada módulo del sistema está bien delimitado en una unidad sintáctica. • Componibilidad: La definición sintácticamente no ambigua facilita la combinación de módulos. • Protección: Facilita el control del ámbito de los errores al estar los módulos delimitados sintácticamente.
Slide 110: Elementos del modelo de objetos Modularidad (Principios) 2º - Auto-documentación El diseñador de un módulo debe esforzase para hacer que toda la información relativa al módulo esté autocontenida en dicho módulo. Este principio sigue especialmente los criterios: • Compresibilidad: Es obvio que facilita la comprensión de cada módulo. • Continuidad: Si el software y su documentación se tratan simultáneamente se garantiza que ambos permanezcan compatibles cuando las cosas comienzan a cambiar. 3º - Acceso uniforme Todos los servicios ofertados por un módulo deben utilizarse a través de una notación uniforme, que no debe delatar como se implementa internamente ese servicio. También se puede ver como un caso particular de la regla de ocultación de la información.
Slide 111: Elementos del modelo de objetos Modularidad (Principios) 4º - Principio abierto-cerrado Los módulos deben ser simultáneamente abiertos y cerrados. Esta contradicción aparente responde a dos conceptos de diferente naturaleza: • Un módulo es abierto si se puede extender. Por ejemplo utilizando la herencia. • Un módulo está cerrado si está disponible para ser utilizado por otros módulos. Se supone que el módulo está definido con una descripción estable de su interfaz. 5º - Elección única Siempre que un sistema de software deba soportar un conjunto de alternativas, uno y sólo un módulo debe conocer la lista exhaustiva de alternativas. La tecnología de objetos ofrece dos técnicas conectadas con la herencia: el polimorfismo y el enlace dinámico.
Slide 112: Elementos del modelo de objetos Jerarquía Es una clasificación u ordenación de abstracciones [Booch 94]
Slide 113: Elementos del modelo de objetos Herencia La herencia se debe utilizar para extender atributos y métodos dentro de una jerarquía. Sin embargo no debe verse como la única forma de trabajo, así la composición (o agregación) permite delegar el trabajo a los objetos apropiados (Booch 94)
Slide 114: Elementos del modelo de objetos Herencia simple Ejemplo de herencia simple multinivel con instancias en notación OMT [Rumbaught 91]
Slide 115: Elementos del modelo de objetos Herencia simple Ejemplo en notación de Booch [Booch 94]
Slide 116: Herencia simple y clases abstractas Una clase abstracta es una clase que no tiene instancias, y que se diseña para ser clase base en una jerarquía de herencias Notación de Booch [Booch 94]
Slide 117: Elementos del modelo de objetos Herencia • La herencia es la jerarquía de clases más importante y es uno de los elementos esenciales de los sistemas orientados a objetos • La herencia define una relación entre clases, en la que una clase comparte la estructura de comportamiento definida en una o más clases (herencia simple o múltiple) • La herencia denota una relación “es-un” (“is-a”). Algunos autores también la denotan como “is-a-kind-of”. • La herencia implica una jerarquía de generalización/especialización, en la que una subclase especializa el comportamiento o estructura, más general, de sus superclases • Las superclases representan abstracciones generalizadas • Las subclases representan especializaciones en las que los campos y métodos de la superclase sufren añadidos, modificaciones o incluso ocultaciones
Slide 118: Elementos del modelo de objetos Herencia • La herencia puede violar los principios de la encapsulación • Los lenguajes OO ofrecen mecanismos para acoplar encapsulación y herencia • C++ ofrece que las interfaces de una clase sean partes – private que declaran miembros accesibles sólo a la propia clase – protected que declaran miembros accesibles a la propia clase sus subclases – public que declaran miembros accesibles a todas las clases y funciones libres • En C++ cuando se desea que un comportamiento se especialice en las subclases se declara el método virtual y
Slide 119: Elementos del modelo de objetos Herencia (Redefinición de métodos) (también denominada anulación o sustitución, en inglés overriding) • Los atributos y métodos definidos en una superclase se heredan en las subclases. • Los métodos de las subclases se pueden redefinir para que su comportamiento se adapte al de la subclase. • En el siguiente ejemplo en UML mostrar() está redefinido UML
Slide 120: Elementos del modelo de objetos Herencia (Redefinición de métodos) Ejemplo de herencia y redefinición de métodos
Slide 121: Elementos del modelo de objetos Herencia Múltiple
Slide 122: Elementos del modelo de objetos Clases abstractas y Herencia Múltiple Ejemplos OMT Ejemplo de método abstracto Herencia múltiple con clases solapadas
Slide 123: Elementos del modelo de objetos Herencia Múltiple • La herencia múltiple es conceptualmente correcta pero en la práctica introduce dos complejidades: – colisiones entre nombres de superclases diferentes – herencia repetida • Las colisiones se producen cuando dos o más superclases proporcionan un campo u operación con el mismo nombre – En C++ se resuelven con calificación explícita – En Smalltalk se utiliza la primera ocurrencia del nombre • La herencia repetida ocurre cuando una clase D hereda de dos o más superclases “hermanas” (B y C) que a su vez heredan por algún camino de una clase (A) que es un antepasado común a ambas
Slide 124: Elementos del modelo de objetos Herencia Múltiple • ¿ Debe tener la clase que hereda de ambas una sola copia o muchas copias de la estructura de la clase compartida ? • Algunos lenguajes prohiben la herencia repetida (Eiffel) • C++ permite al programador que decida. Si las clase común es virtual no aparecen copias. Si no es virtual se producen copias repetidas, siendo necesaria la calificación explícita para resolver la ambigüedad al elegir las copias • La herencia múltiple se sobreutiliza a menudo y es utilizada de forma inadecuada por principiantes • Algunos lenguajes orientados a a enseñanza (por ejemplo Object Pascal) no permiten herencia múltiple obligando al principiante a utilizar siempre herencia simple. Java sólo tiene herencia simple, sin embargo tiene herencia múltiple de interfaces
Slide 125: Elementos del modelo de objetos Riesgos de la herencia [COAD 97, pp. 53] • La herencia promueve una fuerte encapsulación con respecto a otras clases fuera de la jerarquía de herencia. Sin embargo la encapsulación es frágil entre las clases de la jerarquía, dado que un cambio en una superclase se trasmite a todas las subclases • La herencia promueve un acomodo frágil a objetos que cambian de subclase con el tiempo
Slide 126: Elementos del modelo de objetos Interfaces • Una interfaz es una colección de operaciones que se usa para especificar un servicio de una clase o de un componente • Las interfaces sólo tienen operaciones, no tienen atributos • Las operaciones sólo están especificadas, pero no implementadas • Las operaciones pueden tener indicaciones sobre visibilidad y concurrencia • Otra definición de Interfaces versus Clases es la dada por Bruce Eckel (www.bruceeckel.com) – Una interfaz es un TIPO y una clase es la IMPLEMENTACIÓN de un tipo. – Si la implementación es parcial nos encontramos con una clase abstracta
Slide 127: Elementos del modelo de objetos
Slide 128: Elementos del modelo de objetos Polimorfismo Es un mecanismo que permite a un método realizar distintas acciones al ser aplicado sobre distintos tipos de objetos que son instancias de una misma jerarquía de clases • Polimorfismo significa “muchas formas” • El polimorfismo se realiza en tiempo de ejecución gracias a la ligadura dinámica. • No se debe confundir polimorfismo con sobrecarga. • La sobrecarga se resuelve en tiempo de compilación, dado que los métodos se deben diferenciar en el tipo o en el número de parámetros. • El polimorfismo se resuelve en tiempo de ejecución, todos los métodos tienen los mismos parámetros, las acciones cambian en función del objeto al que se le aplica. • El lenguaje C++ utiliza los denominados métodos virtuales y punteros a objetos para implementar el polimorfismo
Slide 129: Elementos del modelo de objetos Sobrecarga (Overloading) • Se produce cuando existen dos o más métodos con el mismo identificador pero con distinto número o tipo de parámetros resolviendo el compilador en tiempo de compilación. • Algunos autores también denominan a la sobrecarga polimorfismo estático. • Cada método realiza una operación en función de los argumentos que recibe • Algunos lenguajes como C++ también soportan sobrecarga de operadores, en este caso el significado de cada operador depende del operando al que se aplique.
Slide 130: Elementos del modelo de objetos Agregación o composición • Las relaciones de agregación son jerarquías “parte de” o “tiene un” • La agregación no es un concepto exclusivo de los lenguajes orientados a objetos. Por ejemplo el uso de estructuras anidadas en C. • La agregación plantea el problema de la propiedad y relaciones entre los componentes agregados • Los constructores de la clase contenedora deben llamar a los constructores de las clases de los objetos contenidos
Slide 131: Elementos del modelo de objetos Agregación o composición Ejemplo
Slide 132: Elementos del modelo de objetos Agregación versus herencia • Herencia: “es-un” • Agregación: “parte-de” o “tiene-un”
Slide 133: Elementos del modelo de objetos Agregación versus herencia // Implementación en C++ class Ala {...}; // Los ...indican que se ha implementado la clase class Motor {...}; class TrenDeAterrizaje{...}; class Cabina{...}; class Avion { Ala *a1, *a2; Motor *m1, *m2; TrenDeAterrizaje *t; Cabina *c; ...}; // El constructor de la clase //Avion debe llamar a los //constructores de las clases //agregadas
Slide 134: Elementos del modelo de objetos Control estricto de tipos Los tipos son la puesta en vigor de la clase de los objetos, de modo que los objetos de tipos distintos no pueden intercambiarse o, como mucho, pueden intercambiarse de formas muy restringidas [Booch 94]
Slide 135: Elementos del modelo de objetos Control estricto de tipos • Se intercambiará el concepto de tipo y clase, aunque en algunos lenguajes Orientados a Objetos no son exactamente lo mismo • La congruencia de tipos se produce en la comprobación estricta de forma que las reglas del dominio dictan y refuerzan ciertas combinaciones correctas de las abstracciones • Los lenguajes orientados a objetos pueden ser – con comprobación estricta de tipos – con comprobación debil de tipos – sin tipos
Slide 136: Elementos del modelo de objetos Control estricto de tipos • Lenguajes con comprobación estricta de tipos (Java, Eiffel, Ada, Object Pascal) – La concordancia de tipos se impone de manera estricta – No puede llamarse a una operación sobre un objeto a menos que en la clase o superclases del objeto esté definido el prototipo exacto de esa operación – La violación de tipos se detecta en tiempo de compilación – La comprobación estricta de tipos permite utilizar el lenguaje de programación para imponer ciertas decisiones de diseño, y por eso es particularmente relevante a medida que aumenta la complejidad del sistema – El inconveniente principal es que pequeños cambios en el interfaz de una clase base obliga a la recompilación de todas las subclases
Slide 137: Elementos del modelo de objetos Control estricto de tipos • Lenguajes con comprobación estricta de tipos (Java, Eiffel, Ada, Object Pascal) ... – Si el lenguaje no soporta genericidad (clases parametrizadas) es problemático manejar colecciones de objetos heterogéneos seguras respecto al tipo. Si el lenguaje si las soporta (C++) se puede utilizar una clase contenedor segura respecto al tipo – Una primera solución es utilizar punteros genéricos (void en C C++, pointer en Pascal y Object Pascal) – La segunda solución es la identificación de tipos en tiempo de ejecución (Smalltalk y C++) – Una tercera solución es utilizar operaciones polimórficas ligadura dinámica o tardía utilizando y
Slide 138: Elementos del modelo de objetos Control estricto de tipos • Lenguajes con comprobación débil o híbrida de tipos (C++) – Permiten ignorar o suprimir las reglas de comprobación de tipos • Lenguajes sin tipos (Smalltalk) – Se puede enviar cualquier mensaje a cualquier clase aunque ésta desconozca como responder al mensaje – Los errores se detectan en tiempo de ejecución
Slide 139: Elementos del modelo de objetos Concurrencia Es la propiedad que distingue un objeto activo de uno que no está activo [Booch 94]
Slide 140: Elementos del modelo de objetos Concurrencia • La concurrencia se centra en la abstracción de hilos (threads) y en la sincronización • Los objetos pueden adquirir estas propiedades • El diseño orientado a objetos puede construir modelos como un conjunto de objetos cooperativos, algunos de los cuales son activos y sirven así como centros de actividad independiente • La mayor parte de los sistemas operativos actuales dan soporte a la concurrencia (UNIX, Linux, OS/2, familia Windows: NT, 95, 2000, XP,...)
Slide 141: Elementos del modelo de objetos Concurrencia • La concurrencia es una característica intrínseca de ciertos lenguajes de programación (Java) – En Ada las tareas (task) – EnSmalltalk la clase Process • En otros es una característica añadida por medio debibliotecas, por ejemplo C++ y la biblioteca de tareas de AT&T con las clases Sched, Timer, Task y otras • En último caso pueden utilizarse interrupciones si el sistema operativo no tiene concurrencia (MS-DOS)
Slide 142: Elementos del modelo de objetos Persistencia Es la propiedad de un objeto por la que su existencia transciende el tiempo (es decir, el objeto continúa existiendo después de que su creador deja de existir) y/o el espacio (es decir, la posición del objeto varía con respecto al espacio de direcciones en el que fue creado) [Booch 94]
Slide 143: Elementos del modelo de objetos Persistencia • La persistencia conserva el estado de un objeto en el tiempo y en el espacio [Booch 94] • La persistencia implica más que la mera duración de los datos, no sólo persiste el estado del objeto, sino que su clase debe trascender a cualquier programa individual, de forma que todos los programas interpreten de la misma manera el estado almacenado • Los lenguajes orientados a objetos ofrecen el soporte de la persistencia por medio de algún artilugio (almacenamiento de clases y datos,…) • El almacenar objetos en ficheros es una solución ingenua para la persistencia, pues los objetos no son sólo datos • El principal problema es que los sistemas operativos actuales están basados en ficheros
Slide 144: Elementos del modelo de objetos Distribución • Computación de objetos distribuidos (Distributed Object Computing, DOC) – Es un paradigma de computación que distribuye objetos de cooperación a través de una red heterogénea y permite que los objetos interoperen como un todo unificado • Beneficios de la computación con objetos distribuidos – Independencia de la plataforma y sistema operativo – Integración mediante uso de envoltorios (wrapping) de aplicaciones heredadas (legacy applications) – Descomposición del sistema en componentes – Flexibilidad para adaptarse a los cambios – Simplicidad cuando se distribuyen aplicaciones complejas en entornos heterogéneos
Slide 145: Elementos del modelo de objetos Distribución Beneficios de los objetos distribuidos [Orfali 96]
Slide 146: Elementos del modelo de objetos Distribución Soluciones para manejar objetos distribuidos OMG : CORBA URL http:://www.omg.org Microsoft : DCOM Distributed Component Object Model Es un protocolo que permite comunicarse a los componentes a través de las redes de los sistemas operativos de la familia windows. Existen puentes DCOM-CORBA. http://www.microsoft.com/com/tech/DCOM.asp Microsoft : .NET Web Servces NET Remoting
Slide 147: Elementos del modelo de objetos Distribución Sun: CORBA y RMI JavaTM Remote Method Invocation Permite un acceso fácil a objetos distribuidos de Java http://java.sun.com/products/jdk/rmi/ Otras soluciones: Agentes móviles
Slide 148: Elementos del modelo de objetos Genericidad Es la propiedad que permite construir abstracciones modelo (clases genéricas) para otras clases. El modelo puede parametrizarse con otras clases, objetos y/o operaciones. [Booch 94]
Slide 149: Elementos del modelo de objetos Genericidad • Es un elemento del modelo de objetos discutido, algunos autores como Booch lo consideran ligado al lenguaje de programación que implementa el modelo de objetos. • C++ y Eiffel soportan mecanismos de clases genéricas, habitualmente denominados clases parametrizadas o plantillas (templates) • En C y Pascal pueden construir estructuras de datos genéricas utilizando punteros genéricos (void y pointer) • B. Meyer[Meyer 97] ha apuntado que la herencia es un mecanismo más potente que la genericidad y que gran parte de los beneficios de la genericidad puede conseguirse mediante la herencia, pero no al revés. • En la práctica, es útil usar un lenguaje que soporte tanto la herencia como clases parametrizadas • Actualmente C++ soporta la nueva norma ANSI con la biblioteca de clases genéricas STL (Standard Template Library)
Slide 150: Elementos del modelo de objetos Manejo de excepciones Se deben tener mecanismos para recuperar el sistema de situaciones anormales no esperadas [Meyer 97] • Los lenguajes orientados a objetos establecen mecanismos para que en el caso de situaciones anómalas se disparen excepciones que el programador puede atrapar en distintas partes del código • Ejemplos: Java, C++, C#, Delphi,...
Slide 151: Elementos del modelo de objetos Componentes Un componente es un elemento de software que por una parte debe ser suficientemente pequeño para crearse y mantenerse y por otra suficientemente grande para poder utilizarse, además debe tener interfaces estándar para que sea interoperable [Orfali 96] • Propiedades de los componentes – Son entidades que se pueden comercializar separadas – No son aplicaciones completas – Pueden combinarse en formas impredecibles – Tienen un interfaz perfectamente especificado – Son objetos interoperables. Se pueden invocar de forma independiente de los sistemas software a través del espacio de direcciones, redes, lenguajes, sistemas operativos y herramientas – Son una extensión de los objetos. Es decir deben soportar encapsulación, herencia, polimorfismo,...
Slide 152: Elementos del modelo de objetos Componentes • Un componente es una entidad funcional que está completamente caracterizada por sus entradas y salidas • Un componente puede usarse y comprobarse como una unidad, independiente del contexto en el que se esté usando eventualmente • La implementación interna de un componente está oculta al usuario • Un componente está formado por – Propiedades – Métodos – Eventos
Slide 153: Elementos del modelo de objetos Componentes (Propiedades) • Una propiedad es un valor, o estado, asociado al componente • Las propiedades no son solamente variables cuyo valor se puede leer o escribir directamente, como se haría en una clase C++ • Las propiedades tienen normalmente asociada una acción que se ejecuta con la modificación de la propiedad • Las propiedades tienen un valor antes de que se use el componente • El valor de una propiedad puede cambiarse en tiempo de ejecución • Los resultados de modificar una propiedad son inmediatos al desencadenarse la acción ligada a la propiedad
Slide 154: Elementos del modelo de objetos Componentes (Métodos) • Los métodos de un componente funcionan como lo haría cualquier método de una clase de C++ • Cada método proporciona un comportamiento de un componente, ya que obligan al componente a realizar una acción Componentes (Eventos o Sucesos) • Un evento es alguna acción producida por el usuario o por actividades internas del sistema • Ejemplos: – pulsar el ratón – llamar a un método – modificar el valor de una propiedad
Slide 155: Elementos del modelo de objetos Componentes (Eventos o Sucesos) Manejo de eventos • Es el código el que responde al evento cuando éste ocurre • El programador escribirá el código adecuado para responder a cada evento
Slide 156: Elementos del modelo de objetos Patrones de diseño Un patrón de diseño describe una solución a un problema en un contexto particular de tal forma que otros puedan reutilizar esta solución Un patrón de diseño tiene cuatro elementos esenciales • El nombre del patrón • Suele estar formado por una palabra o dos • Describe un problema de diseño • El nombre del patrón incrementa el vocabulario de diseño • Se debe buscar un buen nombre para cada patrón
Slide 157: Elementos del modelo de objetos Patrones de diseño • La descripción del problema al que se aplica el patrón • Se explica el problema y su contexto • Se describen problemas de diseño específicos • También se puede incluir una lista de las condiciones que se deben de cumplir antes de aplicar un patrón • La solución • Describe los elementos que componen el diseño, así como sus relaciones, responsabilidades y colaboraciones • La solución no describe un diseño concreto o una implementación particular, ya que un patrón es como una plantilla que se puede aplicar a diferentes situaciones. • Un patrón muestra una descripción abstracta de un problema de diseño y como se organizan los elementos que resuelven el problema (clases y objetos en nuestro caso).
Slide 158: Elementos del modelo de objetos Patrones de diseño • Las consecuencias • Son los resultados y beneficios de aplicar el patrón • A través de las consecuencias se pueden evaluar las alternativas de diseño y estimar los costes y beneficios de aplicar un patrón • También pueden incluir aspectos sobre los lenguajes de programación • Dado que la reutilización de un patrón es un factor muy importante, en las consecuencias también se debe incluir el impacto sobre la flexibilidad, extensibilidad y portabilidad de los sistemas. • Un listado explícito de estas consecuencias ayuda a comprender y evaluar un patrón.
Slide 159: Elementos del modelo de objetos Reutilización [Meyer 97] • Premisas – No reinventes la rueda, ¡herédala! – Usa y construye componentes • Beneficios – Reducción de tiempos – Decremento del esfuerzo de mantenimiento – Fiabilidad • Cada desarrollador de un componente trabaja en su área de conocimiento – Eficiencia – Consistencia – Protección de la inversión en desarrollos
Slide 160: Elementos del modelo de objetos Reutilización [Meyer 97] • La regla de la reutilización – Se debe ser consumidor de reutilización antes de ser un productor de reutilización • ¿Qué se debe reutilizar? – Personal (formación) – Diseños y especificaciones (Patrones de Diseño) – Código fuente (componentes, herencia y genericidad) – Módulos abstractos (frameworks)
Slide 161: Elementos del modelo de objetos Reutilización [Meyer 97] • Obstáculos para la reutilización – El síndrome NIA (No Inventado Aquí) – Impedimentos legales, comerciales o estratégicos – Acceso a a los fuentes de componentes y frameworks – Formatos de distribución de componentes (CORBA, ActiveX, ...) – Dilema reutilización-rehacer – Inercia del personal a los cambios
Slide 162: Elementos del modelo de objetos Precondiciones y post-condiciones [Meyer 97] • Factores de calidad – Corrección (Comprobación de aserciones) – Robustez (Manejo de excepciones) • Asertos o aserciones – son expresiones booleanas (con algunas extensiones) que manejan entidades software comprobando algunas propiedades que estas entidades pueden satisfacer en ciertas etapas de la ejecución del software.
Slide 163: Elementos del modelo de objetos Precondiciones y post-condiciones [Meyer 97] • Precondiciones y post-condiciones – Son dos aserciones asociadas a cada método de una clase – Precondición: comprueba el estado de las propiedades que se deben cumplir antes de la ejecución del método. – Post-condición: comprueba el estado de las propiedades que se deben cumplir después de la ejecución del método. – El lenguaje Eiffel tiene dos secciones en cada método para precondiciones (require) y post-condiciones (ensure) – Ejemplos: sea una Pila con los métodos push y pop • Precondiciones de push: la pila no puede estar llena • Post-condiciones de push: la pila no puede estar vacía • Precondiciones de pop: la pila no puede estar vacía • Post-condiciones de pop: la pila no puede estar llena
Slide 164: Estado actual de las TOO • Bussiness Objects (objetos de negocio) - Son componentes que modelan completamente aplicaciones de un dominio determinado • Frameworks - Un framework (marco estructural) es un conjunto de bibliotecas de clases preparadas para la reutilización, que pueden utilizar a su vez componentes. • Entornos de desarrollo
Slide 165: Perspectivas futuras de las TOO • Lenguajes O O • Métodos y metodologías • Distribución • Componentes • Internet • Sistemas Operativos O O • Bases de datos Orientadas a Objetos • Interfaces de usuario
Slide 166: Plataforma Java2
Slide 167: Índice  El lenguaje Java Plataforma Java2: J2SE + J2ME + J2EE Introducción a J2EE Especificaciones J2EE (Servlet, JSP, EJB, JDBC, JTA, JNDI, JMS, JAXP, ...)   
Slide 168: El lenguaje Java  Un poco de historia:  1990: James Gosling, responsable de una empresa filial creada por Sun Microsystems a tal fin llamada FirstPerson Inc., empieza a diseñar Java como software para dispositivos electrónicos de consumo como calculadoras, microondas y la televisión interactiva. El nombre de Java por aquel entonces era Oak (roble en inglés).  1995: Java se reconvirtió en un lenguaje de programación utilizable en Internet (en la www). Para ello se incorporó una JVM en Netscape Navigator 2.0 (applets), produciendo una verdadera revolución en el mundo de los ordenadores.
Slide 169: El lenguaje Java  Un poco de historia ( continua )  1997: Aparece Java 1.1 mejorando mucho la primera versión del lenguaje  1998: Aparece Java 1.2 (a partir de aquí aparece el nombre Java2) incorporando nuevos elementos. Según sus creadores en Sun Microsystems, ésta es la primera versión realmente profesional del lenguaje. Java2 se compone de J2SE, J2EE y J2ME.  2001: Aparece la versión 2.0 de los Enterprise JavaBeans o EJBs (dentro de J2EE) que incluye importantes avances en la gestión de la persistencia..  2002: Aparece la versión J2EE 1.4
Slide 170: El lenguaje Java  Características principales de Java  Simple, pequeño y robusto  Compilado + interpretado  Independiente de la plataforma
Slide 171: El lenguaje Java  Características principales de Java  Simple, pequeño y robusto  Compilado + interpretado  Independiente de la plataforma  El sistema operativo pierde importancia --> Microsoft :(  Bytecodes.... ¿independientes del lenguaje?  Sun: “Escribe una vez y ejecuta en cualquier sitio”  Programación centrada en la red  SUN: “La red es el ordenador”  1º applets, luego aplicaciones web (Servlets, JSP, EJB)
Slide 172: El lenguaje Java  Repasemos algunos términos importantes:  Java: lenguaje de programación  Bytecode: código intermedio resultado de compilar los programas escritos en Java  JVM = Java Virtual Machine. Es el intérprete Java que es capaz de ejecutar en una plataforma concreta (Unix, Windows, Mac, Linux, ...) los bytecodes pre-compilados de Java.  JRE = Java Runtime Environment. Se compone de los requerimientos mínimos para ejecutar una aplicación Java, esto es, de una JVM, de las clases básicas y de ficheros de soporte.
Slide 173: Índice  El lenguaje Java Plataforma Java2: J2SE + J2ME + J2EE Introducción a J2EE Especificaciones J2EE (Servlet, JSP, EJB, JDBC, JTA, JNDI, JMS, JAXP, ...)   
Slide 174: Plataforma Java2: J2SE + J2EE + J2ME  De qué se compone Java2:  Java: Lenguaje O.O. creado por SUN.  Plataforma Java2 está formada por:  J2SE (Java 2 Standar Edition): Paquete básico del lenguaje Java. Desarrollo --> J2SDK  J2ME (Java 2 Micro Edition): Especificación de Java para el desarrollo de aplicaciones para pequeños dispositivos electrónicos. Desarrollo --> J2ME Wireless Toolkit  J2EE (Java 2 Enterprise Edition): Conjunto de especificaciones Java para el desarrollo de aplicaciones empresariales.
Slide 175: Plataforma Java2: J2SE + J2EE + J2ME  J2SE = Java2 Estandar Edition  Es la plataforma básica de Java que permite desarrollar applets y potentes aplicaciones ‘standalone’ y Cliente/Servidor clásicas.  Algunos de los componentes de J2SE son:  JavaBeans  JavaWebStar  RMI  Java2D  JFC/Swing + AWT  Javadoc Tool  Otros componentes adicionales son:  JavaMail  JSSE  Java3D  ...
Slide 176: Plataforma Java2: J2SE + J2EE + J2ME  J2SE = Java2 Estandar Edition
Slide 177: Plataforma Java2: J2SE + J2EE + J2ME  J2ME = Java2 Micro Edition  Es una JRE muy optimizada para usarse en dispositivos electrónicos de todo tipo.  Algunas de las tecnologías que soporta son: Bluetooth  J2ME Web services  JavaTV  JavaPhone  J2EE client  Java Card 
Slide 178: Plataforma Java2: J2SE + J2EE + J2ME  J2ME = Java2 Micro Edition  MIDP = Movile Information Device Profile.  CLDC = Connected Limited Device Configuration  MIDP + CDLC = JRE de J2ME (para pequeños dispositivos electrónicos)  MIDP ocupa entorno a 0.8-1 Mb.  Desarrollo:  J2ME Wireless Toolkit  Herramientas propietarias de los fabricantes
Slide 179: Índice  El lenguaje Java Plataforma Java2: J2SE + J2ME + J2EE Introducción a J2EE Especificaciones J2EE (Servlet, JSP, EJB, JDBC, JTA, JNDI, JMS, JAXP, ...)   
Slide 180: Introducción a J2EE J2EE = Java2 Enterprise Edition  J2EE está compuesto de un conjunto de especificaciones Java orientadas al desarrollo de aplicaciones empresariales  ¿Qué se entiende por una aplicación empresarial?  Compleja  ¿Distribuida?  Exigente en cuanto a:  Carga de trabajo  Rendimiento  ¿Multi-capa? 
Slide 181: Introducción a J2EE  Pongamos un poco de orden...
Slide 182: Introducción a J2EE  Aplicaciones multi-capa con J2EE:
Slide 183: Introducción a J2EE  Arquitectura de componentes J2EE: Sistema Remoto Applets / Java Apps Navegador web PDA’s Web Services IIOP HTTP HTTP Servlets Servlets / JSP Componentes EJB’s Conectores Propietario Repositiorio de Contexto JDBC Bases de Datos Propietario ERP, Legacy, Mainframe Web Services Sistemas de socios
Slide 184: Introducción a J2EE  La portabilidad de las aplicaciones J2EE se basa en tres pilares:  Componentes:  EJBs, Servlets, JSPs  Desarrollarlos es responsabilidad en los desarrolladores de aplicaciones J2EE  Contenedores  Motor servlets/JSPs y contenedor de EJBs  Desarrollarlos es responsabilidad en los fabricantes de contenedores  Conectores  Permiten conectar aplicaciones J2EE con EIS (sistemas de información empresariales) tipo SAP, Siebel, JD Edwards, etc.  Desarrollarlos es responsabilidad en los fabricantes de EIS
Slide 185: Introducción a J2EE  Componentes  Applets  JSP y Servlets  EJBs  Aplicaciones J2EE  Legacy Systems  Bases de datos  EIS J2EE:  Aplicaciones cliente --> ficheros ‘WAR’ --> ficheros ‘JAR’ --> ficheros ‘EAR’
Slide 186: Introducción a J2EE  Contenedores de componentes J2EE:
Slide 187: Introducción a J2EE  Cronograma histórico en J2EE: Soporte XML JAX Pack WS Pack Web Services EJB JMS JNDI J2EE EJB 1.0 J2EE 1.2 EJB 1.1 J2EE 1.3 EJB 2.0 2001 2002 J2EE 1.4 EJB 2.1 2003 1997 1998 1999 2000 Servlets JSP Servlets 2.1 JSP 1.0 Servlets 2.2 JSP 1.1 JSP 1.2 JSP 2.0 Servlets 2.4 Servlets 2.3 JCA 1.0 JMS 1.1 JMS 1.0 JCA 1.5 (Todas las fechas son aproximadas. Muchas de estas especificaciones fueron anunciadas bastante antes de publicarse)
Slide 188: Introducción a J2EE  Qué aplica dónde:
Slide 189: Introducción a J2EE  Roles en torno a J2EE
Slide 190: Introducción a J2EE  ¿Dónde empieza y dónde acaba J2EE?
Slide 191: Introducción a J2EE  Patrones J2EE
Slide 192: Índice  El lenguaje Java Plataforma Java2: J2SE + J2ME + J2EE Introducción a J2EE Especificaciones J2EE (Servlet, JSP, EJB, JDBC, JTA, JNDI, JMS, JAXP, ...)   
Slide 193: Especificaciones J2EE ...
Slide 194: Especificaciones J2EE ...  J2EE se materializa a través de un conjunto de especificaciones, cada una de la cual cumple un papel concreto en el puzzle global de las aplicaciones empresariales.  JSP,  Servlet,  EJB,  JDBC,  JavaMail,  JMS,  JAXP,  ...
Slide 195: Especificaciones J2EE ... Servlets
Slide 196: Especificaciones J2EE ... Los servlets son clases de Java que amplían la funcionalidad de un servidor Web mediante la generación dinámica de páginas Web  Un entorno de ejecución denominado motor de servlets (habitualmente “incrustado” en un servidor web o un servidor de aplicaciones) administra la carga y descarga en memoria del servlet, y trabaja con el servidor Web HTTP para dirigir las peticiones de los usuarios remotos (clientes) a los servlets y enviar la respuesta a los clientes 
Slide 197: Especificaciones J2EE ... Tipos de servlets:  Genéricos  Http  Servlets Http:  La comunicación entre un servlet y sus clientes es del tipo ‘petición-respuesta’  HttpServletRequest  HttpServletResponse 
Slide 198: Especificaciones J2EE ...  Equivalencias entre comandos HTTP y métodos de los servlets HTTP HttpServlet ---------------------------------GET doGet() POST doPost() HEAD doHead() PUT doPut() DELETE doDelete() TRACE doTrace() OPTIONS doOptions() Http support classes
Slide 199: Especificaciones J2EE ...  Ciclo de vida de los Servlets  Los Servlets se ejecutan en el mismo proceso que el Servidor Web que los aloja.  El Servidor Web es el responsable de inicializarlos, invocarlos y destruir cada instancia de los Servlets.  El Servidor Web se comunica con los Servlets usando la interfaz definida en javax.servlet.Servlet  init()  service()  destroy()  getServletConfig()  getServletInfo()
Slide 200: Especificaciones J2EE ...  Ciclo de vida de los Servlets
Slide 201: Especificaciones J2EE ...  Ciclo de vida de los Servlets
Slide 202: Especificaciones J2EE ...  Ejemplo: crear y probar un servlet:  Escribir el código fuente (la clase)  Compilar y obtener los bytecodes (fichero ‘.class’)  Desplegar (instalar) el servlet en un motor de servlets  Probar el servlet haciendo una petición HTTP
Slide 203: Especificaciones J2EE ...  Ejemplo: crear y probar un servlet:  Escribir el código fuente (la clase) import javax.servlet.*; import javax.servlet.http.*; import java.io.*; public class HolaMundoServlet extends HttpServlet { public void service (HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType("text/html"); PrintWriter out = res.getWriter(); out.println("<html><body><h1>Hola Mundo</h1></body></html>"); } } //fin de la clase
Slide 204: Especificaciones J2EE ...  Ejemplo: crear y probar un servlet:  Compilar y obtener los bytecodes (fichero ‘.class’)
Slide 205: Especificaciones J2EE ...  Ejemplo: crear y probar un servlet: :  Desplegar (instalar) el servlet en un motor de servlets Motor de servlets (pe, Tomcat) HolaMundoServlet.class HolaMundoServlet.class Nota: El modo de desplegar el servlet en el motor de servlets dependerá de las utilidades que éste provea
Slide 206: Especificaciones J2EE ...  Ejemplo: crear y probar un servlet: :  Probar el servlet haciendo una petición HTTP
Slide 207: Especificaciones J2EE ... El API de Servlets contiene los siguientes paquetes:  javax.servlet (Servlets Genéricos)  javax.servlet.http (Servlets HTTP)  Este API soporta las siguiente funcionalidades:  Gestión del ciclo de vida del Servlet  Acceso al Contexto del Servlet  Utility Classes  Classes específicas para HTTP. 
Slide 208: Especificaciones J2EE ...  Objetos HttpServletRequest y HttpServletResponse  Estos 2 parámetros se los pasa el Servidor Web a los métodos del Servlet que tratan peticiones Http (doGet, doPost, ...)  HttpServletRequest contiene información relativa a la petición recibida del cliente.  HttpServletResponse se utiliza para configurar y responder a cada petición del cliente.
Slide 209: Especificaciones J2EE ... JSPs
Slide 210: Especificaciones J2EE ...  Funcionamiento de las JSP Bean Bean <HTML> <BODY> Contenido estático <% Código Java%> <jsp:tagJSP/> </BODY> </HTML> Traducción Servlet
Slide 211: Especificaciones J2EE ...  Funcionamiento de las JSP Archivos JSP Servidor de Aplicaciones Web JSP Container Servlets Compilados Archivos HTML Servlet Container Servidor Web Pedido HTTP Respuesta HTTP Cliente Web
Slide 212: Especificaciones J2EE ...  Motor de JSP  Las páginas JSP se interpretan en tiempo de ejecución en un “Motor de JSP”, normalmente en un Servidor Web.  El “Motor de JSP” no es más que un Servlet un tanto especial que se ejecuta a su vez bajo el control del “Motor de Servlets”.
Slide 213: Especificaciones J2EE ...  Fases de ejecución en las JSP:  Translation phase  Se ejecuta la 1ª vez o cuando cambia el JSP. Se “compila” el JSP y se genera una clase (Servlet) que se carga en el “Motor de Servlets”.  Request processing phase  La clase pre-compilada trata las peticiones que recibe el JSP.
Slide 214: Especificaciones J2EE ...  Sintáxis  Page básica: <%@ ... %>  Directivas: Directives: <%@ page import=“java.util.*” %>  Include Directives: <%@ include file=“header.html” %>  Declaraciones  Se <%! ... %> pueden declarar variables y métodos “de página”.  <%! int i=0; %>
Slide 215: Especificaciones J2EE ...  Sintáxis  Se básica: <%= ...%>  Expresiones imprime el resultado de evaluar la expresión:  <%= i %> (no se pone ‘;’ al final de la expresión)  Scriptlets  Código <% ... %> JSP propiamente dicho.  Comentarios  Son <%-- ... --%> comentarios de programación que no se imprimen en el resultado del procesamiento de la página JSP.
Slide 216: Especificaciones J2EE ...  Visibilidad de los objetos (Ámbito) Objetos visibles desde pags de la misma aplicación Objetos visibles desde pags de la misma sesión Objetos visibles desde pags que procesen una misma petición Objetos visibles sólo desde la página donde son creados Más visible Aplicación Sesión Petición Menos visible Página
Slide 217: Especificaciones J2EE ...  Objetos implícitos  El “Motor de JSP” ofrece como facilidad una serie de objetos que son visibles desde los scriptlets y desde las expresiones pero NO son visibles en métodos definidos en declaraciones.
Slide 218: Especificaciones J2EE ...  Objetos implícitos  Los 9 objetos son:  request  response  pageContext  application  out  config  page  session  exception (HttpServletRequest) (HttpServletResponse) (PageContext) (ServletContext) (JspWriter.... output stream) (ServletConfig) (HttpJspPage.... “this”) (HttpSession) (the uncaugth Throwable object)
Slide 219: Especificaciones J2EE ...  JavaBeans y JSP  El modelo de componentes de las JSP está basado en JavaBeans.  Un JavaBean es una clase Java que implementa una interfaz y que tiene unas propiedades privadas a las que se puede acceder mediante métodos de acceso (getters y setters).
Slide 220: Especificaciones J2EE ...  JavaBeans y JSP  Antes de usar un JavaBean, hay que identificarlo y obtener una referencia del mismo: <jsp:useBean id=“casa” class=“com.miempresa.Casa” scope=“session” > <% casa.setDormitorios(3); %> </jsp:useBean> (se ejecuta sólo al instanciar el JavaBean)
Slide 221: Especificaciones J2EE ...  JavaBeans y JSP  Para acceder a las propiedades del JavaBean se utilizan las etiquetas <jsp:getProperty> y <jsp:setProperty> <jsp:setProperty name=“casa” property=“dormitorios” value=“ <%= i %> ” /> (siendo ‘i’ una var previamente definida) <jsp:setProperty name=“casa” property=“dormitorios” value=“5” /> ... <jsp:getProperty name=“casa” property=“dormitorios” /> (se imprimiría ‘5’)
Slide 222: Especificaciones J2EE ...  Ejemplo1 de página JSP <html> <head><title>Hola mundo JSP</title></head> <body> <% String s= "Hello World"; out.println(s); %> </body> </html>
Slide 223: Especificaciones J2EE ...  Ejemplo2 de página JSP <html> <% String s= "Hello World"; %> <head><title>Hola mundo JSP</title></head> <body> <%=s%> </body> </html>
Slide 224: Especificaciones J2EE ...  Ejemplo3 de página JSP <%@ include file=“header.html” %> <% String s= "Hello World"; %> <%=s%> <%@ include file=“footer.html” %> “header.html” <html> <head><title>Hola mundo JSP</title></head> <body> “footer.html” </body> </html>
Slide 225: Especificaciones J2EE ... EJBs
Slide 226: Especificaciones J2EE ... Los EJB son componentes Java pensados para modelar la lógica de negocio de los sistemas J2EE.  La lógica de negocio es la esencia del sistema; es independiente de la o las interfaces gráficas que pueda ofrecer el sistema a sus clientes.  Viven en Servidores EJB, los cuales les ofrecen servicios “extra” de los cuales no tienen que preocuparse. 
Slide 227: Especificaciones J2EE ...  Las ventajas que aporta usar EJBs son las derivadas de usar servidores EJB:  Balanceo de carga  Seguridad  Pool de conexiones a BD  Gestión de la transaccionalidad  Gestión del ciclo de vida  Persistencia  ...
Slide 228: Especificaciones J2EE ... LÓGICA DE PRESENTACIÓN LÓGICA DE NEGOCIO BASE DE DATOS SERVLETS WWW JSP EJB LEGACY SYSTEM
Slide 229: Especificaciones J2EE ...  Dependiendo de los requerimientos del sistema a desarrollar el uso de EJBs puede ser hasta poco recomendable. Dos ejemplos:  Si disponemos de un servidor poco potente para implementar una pequeña Intranet corporativa de una PYME.  Si sé que mi aplicación ni es transaccional, ni tendrá más de 3 usuarios, ni migraré mi repositorio ...
Slide 230: Especificaciones J2EE ...  “Hazlo tú mismo”:  Modelar tu lógica de negocio en clases Java y, dependiendo de tus necesidades concretas: Crearte tu propio Pool de conexiones a BD  Crearte tu mecanismo de Seguridad  Crearte tu propio mecanismo de Gestión Transaccional  ... 
Slide 231: Especificaciones J2EE ... Los EJB son componentes Java “de servidor” que pueden ser instalados en entornos distribuidos.  Un EJB puede contener 1 o más objetos Java, pero ofrecen un único interfaz externo a los clientes que le hagan peticiones.  Un cliente de un EJB puede ser cualquier cosa:  Un servlet/JSP, una clase Java, un Applet, otro EJB, ... 
Slide 232: Especificaciones J2EE ... El estándar EJB define 6 diferentes partes involucradas entorno a los EJB, así como las responsabilidades de cada parte y sus formas de colaboración.  Estas 6 partes son:  Proveedores de Beans  Proveedores de contenedores de EJB  Proveedores de servidores de EJB  Ensambladores de aplicaciones  Instaladores (“deployers”)  Administradores de sistemas 
Slide 233: Especificaciones J2EE ...  Colaboraciones entre las 6 partes: Construyen EJBs Construyen aplicaciones Instalador (“Deployer”) Proveedor de EJBs Ensamblador de aplicaciones Instalación / or s id rv JB e l S de E e r d dor e ve ene o Pr ont C Proveedores de Servidores / Contenedores de EJB Administrador del sistema
Slide 234: Especificaciones J2EE ...  Contenedor EJB  “Es el SO sobre el cual se implantan y se ejecutan los EJB”.  Gestiona el acceso remoto a los EJB, la seguridad, persistencia, transaccionalidad, concurrencia y acceso a los pool de recursos.  Protege a los EJB del acceso directo por parte de aplicaciones cliente. Toda petición remota es 1º interceptada por el contenedor para asegurarse de la correcta gestión de los temas arriba mencionados.
Slide 235: Especificaciones J2EE ...  Contenedor EJB  El desarrollador de EJBs se despreocupa de programar aspectos de persistencia, concurrencia, seguridad, ...  ¡ Se puede centrar en la lógica de negocio !
Slide 236: Especificaciones J2EE ...  Relación entre clientes y EJBs:  Los clientes no tratan directamente con los EJB, si no que lo hacen mediante la mediación de los servidores / contenedores de EJB. Servidor EJBs Código Cliente invocar delegar EJB2 Contenedor EJBs EJB1 invocar delegar
Slide 237: Especificaciones J2EE ...  Tipos de EJB:  Session Beans:  Representan procesos del sistema.  Se llaman así porque viven tanto como dure la “sesión” del cliente que los está llamando, esto es, la ejecución del código del cliente que los llama.  Un Session Bean es usado por un cliente cada vez.  Entity Beans:  Representan los datos persistentes del sistema.  Un Session Bean puede ser usado por más de un cliente a la vez.  NO contienen lógica de negocio del sistema (procesos).
Slide 238: Especificaciones J2EE ...  Tipos de EJB:  Message Driven Beans  Permiten a aplicaciones J2EE procesar peticiones asíncronamente.  Funcionan como ‘listeners’ de JMS
Slide 239: Especificaciones J2EE ...  Tipos de Session Beans:  Stateless Session Beans:  Son procesos del sistema que duran una única petición.  NO hay gestión del estado entre llamadas o peticiones de un mismo cliente.  Stateful Session Beans:  SI hay gestión del estado entre peticiones de un mismo cliente.  Es responsabilidad del servidor / contenedor de EJBs gestionar el estado entre peticiones de un mismo cliente. La gestión del estado ha de ser transparente.
Slide 240: Especificaciones J2EE ...  Tipos de Entity Beans:  Bean Managed Persistance (BMP):  Es responsabilidad del Bean (del desarrollador del Bean en realidad ;-) gestionar la persistencia.  Container Managed Persistance (CMP):  El Bean delega la gestión de su persistencia en el contenedor.
Slide 241: Especificaciones J2EE ...  Message-Driven Beans  Son sin estado (Stateless)  El contenedor de EJBs mantiene un pool de MDBs que atienden a mensajes asíncronos JMS.  No tienen interfaces --> SOLO la clase Bean.
Slide 242: Especificaciones J2EE ...  Message-Driven Beans  Ciclo de vida de los MDB:  El contenedor de EJBs crea un “consumidor” de mensajes (para colas o para temas)  Asocia el bean a un destino y a una factoría de conexiones en tiempo de “instalación” (deployment)  Registra el “listener”
Slide 243: Especificaciones J2EE ...  Message-Driven Beans  Ciclo de vida de los MDB:
Slide 244: Especificaciones J2EE ...  Message-Driven Beans  ¿Qué supone escribir/desarrollar un MDB?  Escribir la clase que ha de implementar las interfaces: javax.ejb.MessageDrivenBean javax.jms.MessageListener  Implementar el método onMessage(Message msg)  Implementar setMessageDrivenContext()  Implementar ejbCreate()  Implementar ejbRemove()  Un constructor sin argumentos
Slide 245: Especificaciones J2EE ... Portabilidad de EJBs entre Contenedores:  Todo lo anterior resulta en un “contrato” entre los desarrolladores de EJB y los proveedores de Contenedores, que hace que los EJB sean portables entre diferentes Contenedores.  Sencillez en la programación de EJBs:  Dado que el Contenedor se hace cargo de tareas complejas (seguridad, concurrencia, transaccionalidad, etc), el desarrollador se libera de gestionar estos temas y se centra en la lógica de su aplicación. 
Slide 246: Especificaciones J2EE ... Componentes / Partes más importantes de un EJB (Session y Entity):  Remote interface  Home interface  Bean  El desarrollador de un EJB ha de proveer de 2 interfaces que definen los métodos de negocio del EJB y la clase propiamente dicha del Bean.  El cliente utiliza los 2 interfaces para obtener, manipular y eliminar EJBs del Contenedor. 
Slide 247: Especificaciones J2EE ... Remote Interface  define los métodos de negocio del EJB (getX, setX, ...)  Home Interface  define los métodos propios del ciclo de vida del EJB (create, destroy, ...)  Bean  Contiene el código que se ejecutará  Local inteface (desde EJB 2.0)  como el remote pero para llamadas entre EJBs dentro de un mismo contenedor (por rendimiento) 
Slide 248: Especificaciones J2EE ...  Implantación / Instalación de EJB en un Contenedor:  Deployment Descriptor (XML):  Le dice al Contenedor cómo ha de comportarse el EJB (persistencia, accesos, ...)  META-INF/ejb-jar.xml (nombre que ha de tener el DD). Un EJB ha de estar empaquetado en un fichero JAR. 
Slide 249: Especificaciones J2EE ...  Implantación / Instalación de EJB en un Contenedor:  Este JAR ha de contener:  El Deployment Descriptor  Los interfaces Remote y Home y las clases del Bean.  La persona que esté instalando el EJB, habrá de “retocar” el DD para ajustarlo al entorno del Contenedor (pe, driver de la BD que se use en ese entorno concreto).
Slide 250: Especificaciones J2EE ... Resumen de componentes de un EJB (Session y Entity): El Bean La interfaz Remote La interfaz Home El Deployment Descriptor El Manifiesto (propio del .jar) ----------------------------------Fichero “.jar”  Ahora que ya conocemos los componentes más importantes de un EJB vamos a verlos con un poco más de detalle ... 
Slide 251: Especificaciones J2EE ... Home Interface Contenedor / servidor de EJBs Código Cliente Objeto Home - 1 - invocación de un método - 4 - Respuesta Remote Interface Objecto EJB - 3 - Respuesta - 2 - Obtener una instancia y delegar la llamada Bean
Slide 252: Especificaciones J2EE ...  El objeto Home:  ¿Cómo obtienen los clientes una referencia al objeto EJB?  Dado que los clientes no saben dónde se encuentra el objeto EJB (entornos distribuidos + transparencia), no pueden instanciar un objeto EJB directamente.  Los clientes solicitan referencias a objetos EJB a través del objeto Home, el cual es responsable de construir, encontrar y destruir instancias de objetos EJB.  Los objetos Home los generan los contenedores de manera transparente a los clientes y al desarrollador.
Slide 253: Especificaciones J2EE ...  El objeto Home: destruir objetos de un Bean concreto?  Los  ¿Cómo saben los contenedores cómo crear o objetos Home creados por el contenedor (1 por cada EJB) implementan la interfaz Home del EJB.  Todas las interfaces Home deben derivar de la interfaz javax.ejb.EJBHome, la cual a su vez deriva de la interfaz javax.rmi.Remote.
Slide 254: Especificaciones J2EE ...  La interfaz Home:  Toda interfaz Home debe derivar de: public interface javax.ejb.EJBHome extends java.rmi.Remote { public abstract EJBMetaData getEJBMetaData() throws java.rmi.RemoteException; public abstract void remove(Handel handle) throws java.rmi.RemoteException, javax.ejb.RemoveException; public abstract void remove(Object primaryKey) throws java.rmi.RemoteException, javax.ejb.RemoveException; }
Slide 255: Especificaciones J2EE ...  La interfaz Home:  Deberá  La interfaz Home que provea el desarrollador: derivar de javax.ejb.EJBHome  Habrá de describir los métodos propios del ciclo de vida del EJB que el desarrollador considere necesarios (por lo menos un “create”).
Slide 256: Especificaciones J2EE ... Home Interface - 1 - Crear un nuevo objeto EJB - 3 - Devuelve la referencia al objeto EJB Contenedor / servidor de EJBs Objeto Home - 2 - Crear un objeto EJB Código Cliente Bean Objecto EJB Remote Interface
Slide 257: Especificaciones J2EE ...   El Deployment Descriptor:  Es un documento XML  En él, los EJB informan al contenedor de sus necesidades de recursos de middleware (persistencia, transaccionalidad, gestión del ciclo de vida, seguridad, ...) Ficheros de Properties:  Son ficheros en los cuales hay variables que el EJB lee en tiempo de ejecución y mediante las cuales se puede configurar su comportamiento sin tocar su código (y por lo tanto tener que recompilar).
Slide 258: Especificaciones J2EE ...  El fichero .jar:  Es un fichero comprimido donde se aglutinan todos los componentes de un EJB.  Sigue el tipo de compresión de los ZIP. Fichero .jar Interfaz Remote Interfaz Home Bean classes Manifiesto (.jar) Ficheros de Properties Deployment Descriptor
Slide 259: Especificaciones J2EE ...  Uso de los EJBs. Punto de vista del cliente:  Para poder hacer uso de un EJB, los clientes han de obtener una referencia al objeto Home.  Para obtener esta referencia se usa JNDI.  JNDI es un protocolo Java ideado para poder usar directorios de nombres y de servicios sin que el código sea dependiente de ninguno concreto.  Los directorios de nombres y servicios son repositorios que almacenan y “enganchan” recursos compartidos en entornos distribuidos (pe, Microsoft Active Directory, LDAP, Netscape Directory Server, ...)
Slide 260: Especificaciones J2EE ...  Uso de los EJBs. Punto de vista del cliente:  J2EE usa directorios de nombres para gestionar recursos compartidos en aplicaciones empresariales (BD, servicios de mensajería asíncrona, objetos Home, ...)  Cuando un EJB se instala en un contenedor especifica a través de su Deployment Descriptor su alias JNDI.  Los clientes usan el alias dado por el EJB para acceder al objeto Home a través de JNDI.
Slide 261: Especificaciones J2EE ...  Uso de los EJBs. Punto de vista del cliente:  El lugar dónde se encuentre el objeto Home es desconocido para los clientes, JNDI hace que los clientes tan sólo hayan de buscarlo por su alias.  Los directorios de nombres y servicios que el contenedor utilice se encargarán de buscar algún EJB que tenga ese alias definido.  Pasos a dar por un cliente para obtener una referencia al objeto Home: Configurar el entorno, especificando el directorio de servicios se va a usar así como usuario / contraseña. Establecer el contexto inicial.
Slide 262: Especificaciones J2EE ...  Uso de los EJBs. Punto de vista del cliente: - 2 - Crear un nuevo objeto EJB Contenedor / servidor de EJBs Código Cliente - 1 - Obtener una referencia del objeto Home Home Interface - 4 - Devuelve la referencia al objeto EJB Objeto Home - 3 - Crear un objeto EJB - 5 - invocar un método de negocio JNDI Bean Objecto EJB - 6 - delegar la llamada al Bean Remote Interface Directorio de nombres (pe, LDAP)
Slide 263: Especificaciones J2EE ...  Ejemplo de código cliente: // Obtener el Properties del sistema para inicializar JNDI. Properties props = System.getProperties(); // Crear un contexto inicial Context ctx = new InitialContext( props ); // Obtener una referencia del objeto Home MiHome miHome = (MiHome) ctx.lookup(“MiHome”); // Obtener una referencia del objeto EJB MiRemote miObjetoEJB = miHome.create(); // Invocación de un método de negocio del EJB miObjetoEJB.setXXXX(“xxxxxx”);
Slide 264: Especificaciones J2EE ... Otras (JDBC, JTA, JCA, JMS, JNDI, ...)
Slide 265: Especificaciones J2EE ...  JDBC  Java DataBase Connectivity  Es una API que permite el acceso prácticamente a cualquier base de datos relacional desde el lenguaje de programación Java (java.sql)  Es una API para ejecutar instrucciones SQL. JDBC no es un lenguaje de interrogación, sino que simplemente es una interfaz (API) basada en JAVA para trabajar con SQL. Las aplicaciones pueden utilizar JDBC, por ejemplo, para someter sentencias SQL a un sistema gestor de bases de datos.  Cada base de datos (Sybase, SQL Server, Oracle, MySQL, ...) tiene un driver JDBC, a través del cual las aplicaciones Java realizan peticiones a la base de datos.
Slide 266: Especificaciones J2EE ...  JDBC  JDBC, a través de SQL y de los drivers, independiza a las aplicaciones Java de los detalles de cada base de datos. Aplicación A Aplicación B JDBC Oracle Sybase SQL Server
Slide 267: Especificaciones J2EE ...  JNDI  Java Naming and Directory Interface  API que provee de un estándar para conectarse a y usar servicios de nombres dispares (DNS, LDAP, ...)  Se usa para localizar EJBs
Slide 268: Especificaciones J2EE ...  JCA  Java Connector Architecture  Es similar en JDBC en su filosofía: se usa para integrar aplicaciones J2EE con sistemas de backend que no sean bases de datos empresariales  Se crea un adaptador por cada sistema de backend  SAP  Ariba  Siebel  JD Edwards  ...
Slide 269: Especificaciones J2EE ...  JTA/JTS  Una transacción consiste en un conjunto de operaciones que se han de ejecutar como una única unidad --> o se ejecutan todas o no se debe ejecutar ninguna.  Ejemplos de situaciones que requieren de un control transaccional:  Transferencias bancarias  Generación de pedidos  Compra-venta de productos bursátiles  Reservas de alquileres de coches, hoteles, aviones, ...  ...
Slide 270: Especificaciones J2EE ...  JTA/JTS  Ejemplo concreto:  1 transacción compuesta realizada por 2 componentes de negocio que acceden a 4 BBDD diferentes
Slide 271: Especificaciones J2EE ...  JTA/JTS  Problemas que pudieran surgir y que requieren de una gestión transaccional:  Fallos de comunicación de red.  Caídas de sistemas debidos a fallos hardware.  Caídas de sistemas debidos a fallos de suministro eléctrico.  Bloqueo (“cuelgue”) de sistemas debidos a fallos software.  Paso de parámetros incorrectos en una llamada.  ...
Slide 272: Especificaciones J2EE ...  JTA/JTS  Propiedades ACID  Atomicity: Un conjunto de operaciones aparecen como una única unidad de trabajo.  Consistency: La gestión transaccional garantiza que el sistema quedará en un estado consistente cuando se complete la transacción.  Isolation: Transacciones concurrentes no ven el estado inconsistente que pudiera haber en medio de una transacción --> bloqueos.  Durability: Las modificaciones en los repositorios y en general la transacción en sí es persistente (a prueba de caídas) --> logs transaccionales.
Slide 273: Especificaciones J2EE ...  JTA/JTS  Actores  Objetos transaccionales: Son componentes software que toman parte en una transacción.  Gestores transaccionales: Son las aplicaciones encargadas de gestionar la transaccionalidad “detrás de la escena”.  Recursos: Son sistemas de almacenamiento tales como bases de datos, colas de mensajes, ... en los cuales una transacción realiza lecturas/escrituras.  Gestores de recursos: Por ejemplo: drivers de BD, una aplicación MOM, ...
Slide 274: Especificaciones J2EE ...  JTA/JTS  “Lenguaje” transaccional  begin: Comienza la transacción.  abort: Una de las operaciones falla.  commit: Todo ha ido bien y se confirma la transacción.  rollback: Alguna de las operaciones ha fallado y se vuelve al estado previo al inicio de la transacción.
Slide 275: Especificaciones J2EE ...  JTA/JTS  Algunos Modelos Transaccionales  Transacciones planas: Son las más sencillas. Son un conjunto de operaciones que se ejecutan como una única unidad de trabajo.  Transacciones anidadas: Son transacciones que incluyen otras transacciones dentro, además de unidades de trabajo unitarias. Si la transacción embebida falla, la transacción “padre” puede intentar buscar otra solución. Si la encuentra, el transacción “padre” podrá completarse con éxito. Si no encuentra solución al fallo de la transacción embebida, la transacción “padre” también habrá fallado.
Slide 276: Especificaciones J2EE ...  JTA/JTS  Estándares/Tecnologías:  X/Open Distributed Transaction Processing Open Group Estándar “de facto” para Monitores Transaccionales y Gestores de Bases de Datos  Object Transaction Service OMG Gestión transaccional en CORBA  JTA/JTS Sun / J2EE  MTS (Microsoft)
Slide 277: Especificaciones J2EE ...  JTA/JTS  En J2EE la gestión transaccional se ha copiado de otra ya existente llamada OTS, especificación desarrollada por OMG, y que es una extensión para dotar de capacidad transaccional a la computación distribuida en CORBA.  SUN se dio cuenta de que trabajar con OTS era complejo y creo 2 especificaciones Java para dotar a J2EE de capacidad transaccional: JTA y JTS
Slide 278: Especificaciones J2EE ...  JTA/JTS
Slide 279: Especificaciones J2EE ...  JTA/JTS  JTS: Java Transaction Service  Esta especificación está pensada para que los “Gestores transaccionales” se integren con OTS.  Los desarrolladores de aplicaciones / componentes J2EE no tiene porqué saber del detalle de OTS (que es farragoso y complejo).  JTA: Java Transaction API  Esta especificación está pensada para que la usen los “objetos transaccionales” que deseen programar transacciones.
Slide 280: Especificaciones J2EE ...  JTA/JTS  Hay maneras de programar transacciones en un “cliente transaccional” (por ejemplo un Session Bean):  Transacciones declarativas: Es el gestor transaccional quien se encarga de iniciar (begin) y finalizar (commit) las transacciones. El objeto transaccional es instalado en el gestor transaccional y configurado para que determinadas funciones sean transaccionales.  Transacciones Programáticas: Es el propio objeto transaccional quien inicia y finaliza las transacciones.
Slide 281: Especificaciones J2EE ...  JTA/JTS  Transacciones declarativas (1) metodoZZZ() Contenedor / servidor de EJBs Código Cliente Objecto EJB XXX (2) Delega llamada a metodoZZZ() (3) begin Bean XXX (4) El Bean XXX realiza las operaciones que componen la transacción Servicio Transaccional (5) commit / abort
Slide 282: Especificaciones J2EE ...  JTA/JTS  Transacciones declarativas: ejemplo de código public void retirarDinero(double p_cantidad) { UserTransaction ut = m_ctx.getUserTransaction(); try { ut.begin(); // ... Realizo las operaciones de la transacción ... ut.commit(); } catch (Exception ex) { try { ut.rollback(); } catch (SystemException syex) { throw new EJBException (syex.getMessage()); } throw new EJBException (ex.getMessage()); } } // end of the method
Slide 283: Especificaciones J2EE ...  JTA/JTS  Transacciones declarativas (1) metodoZZZ() Contenedor / servidor de EJBs Código Cliente (3) begin Objecto EJB XXX (5) commit / abort (2) Delega llamada a metodoZZZ() Servicio Transaccional Bean XXX (4) El Bean XXX realiza las operaciones que componen la transacción
Slide 284: Especificaciones J2EE ...  JTA/JTS  ¿Cómo podemos especificar en los EJBs para indicar que la gestión transaccional va a ser programática o declarativa?  El tag “<transaction-type>” del Deployment Descriptor.
Slide 285: Especificaciones J2EE ...  JTA/JTS  Aislamiento (isolation) en los EJBs  La especificación define que se pueden configurar diferentes niveles de aislamiento, desde muy fuertes hasta relajados.  El grado de aislamiento se define también a través del Deployment Descriptor. Hay 4 niveles, que de menos a más fuerte son: TRANSACTION_READ_UNCOMMITED TRANSACTION_READ_COMMITED --> Sólo se leen datos que han sido “aceptados” (commited). TRANSACTION_REPEATABLE_READ --> Actualizaciones de los datos durante la transacción TRANSACTION_SERIALIZABLE --> Nuevos datos
Slide 286: Especificaciones J2EE ...  JTA/JTS  Aislamiento (isolation) en los EJBs  Con un aislamiento muy fuerte, se crean continuos bloqueos en los recursos compartidos con lo que podrían darse problemas de rendimiento.
Slide 287: Especificaciones J2EE ...  JTA/JTS  Durability en los EJBs  Para asegurarnos que las modificaciones sobre los repositorios sean permanentes y se ejecuten aún y cuando puedan darse caídas en los sistemas... --> Protocolo 2-phase commit  Fase 1 Se envía un aviso anterior al commit final. De esta manera se da una última opción para abortar la transacción y para guardar en el log la operación que se va a realizar.  Fase 2 Se envía el commit final.
Slide 288: Especificaciones J2EE ...  JTA/JTS  Transaccionalidad y JMS  En aplicaciones J2EE donde haya una parte de integración con MOMs se utiliza JMS.  Existe un tipo específico de EJBs para la comunicación con JMS: Message-Driven Beans (MDB) Son como “listeners” que escuchan mensajes y que se pueden conectar a colas (queues) y/o a temas (topics) Tienen el método onMessasge(Message) que es invocado cuando la cola o el tema tienen un mensaje y se lo entregan al MDB.
Slide 289: Especificaciones J2EE ...  JMS  Es un API Java usado para crear, mandar, recibir y leer mensajes asíncronos  Abstrae a las aplicaciones Java de los APIs propietarios de los diferentes MOMs existentes (MQSeries, etc)  Hay dos tipos de mensajes: punto a punto  publicación / subscripción 
Slide 290: Especificaciones J2EE ...  JMS  Message-Driven Beans
Slide 291: Especificaciones J2EE ...  La suite JAX*:  JAXR (Java API for XML Registries): para encontrar el web service del socio de negocio.  JAX/RPC (Java API for XML RPC): para enviar requerimientos RPC a web services externos.  JAXM (Java API for XML Messaging): para enviar mensajes SOAP/ebXML a web services externos.  JAXP (Java API for XML Parsing) y JAXB (Java API for XML Binding): para transformar datos java en formato XML y viceversa y ejecuta transformaciones XSLT para convertir esquemas.