Es en si el J2EE.
Un programa que de por si contiene todo lo necesario para generar una aplicación estable de por sí.
....... y aunque no se me ocurre nada mas, me voy a la cama que son las 3 !!!!!
2008-01-30
Definiciones inconexas
bueno, estas definiciones son importantes pero no sé donde ponerlas, ....por eso las pongo por aqui:
Imagino que luego me diran... "in.con.eXas" me vienes ahora?
TDD.- (Test Directed Development) Es un tipo de desarrollo de Software en el cual el desarrollo de este se realiza a partir de la prueba. Ello implica generar los casos de prueba con anterioridad al desarrollo del Sofware. De esta forma, el Software debe pasar por los "escollos" que tiene la prueba. Cuando consiga pasar por ellas, se podrá de forma fehaciente afirmar que el codigo no generará errores.
La ventaja de esta codificacion es que a mayor bateria de pruebas, mas fiable será nuestro codigo y por otro lado, estas baterias de pruebas pueden ser extensibles a distintos procesos tengan conexion. Es decir, empleo la estructura de las pruebas a distintos procesos para probarlos.
POJO.-(Plain Old Java Object) Este acrónimo hace referencia a las clases mas internas de JAVA, no es mas que una clase básica(entendida como esencial) de JAVA. Cualquier clase que sea POJO posee unas propiedades y métodos tales que no dependen del Framework en el que se lancen. La union del POJO con las @notaciones da lugar al EJB3.
DATA PROVIDER.- Es una coleccion de Beans que nos permiten conectar a cualquier forma de datos incluyendo texto, XML o RDBMS.
Para ello se genera un Objeto que contengan ciertos datos, objeto que se marca con una anotacion tipo @DataProvider y un nombre.
Con posterioridad se pueden hacer pruebas de métodos empleando el contenido de este objeto y evaluar el resultado. Esto se emplea para cuando en el proyecto no se tiene una Base de Datos pero se requiere de ella. Así se puede simular la existencia de ella.
POLIMORFISMO.- Es una capacidad que tiene Java para a partir de una Clase determinada, se ejecute un método u otro de los generados en función de los parámetros con que se lanzan en ese momento.
El ejemplo mas utilizado es la obtencion de un área de cierta forma plana. Si se envia un radio, se ejecuta el metodo de obtencion de area de un circulo; si se envia un lado, se ejecuta el metodo de obtencion del area de un cuadrado, etc... esto permite reutilizar código.
ENCAPSULAMIENTO.- No logro entender bien lo que és. Imagino que es una forma de acceder indirectamente a ciertas clases a partir de otras, pero no logro entender que se pretende... (sigo buscando). En la -Wiki- se enrolla mucho y no logro enterarme.
Imagino que luego me diran... "in.con.eXas" me vienes ahora?
TDD.- (Test Directed Development) Es un tipo de desarrollo de Software en el cual el desarrollo de este se realiza a partir de la prueba. Ello implica generar los casos de prueba con anterioridad al desarrollo del Sofware. De esta forma, el Software debe pasar por los "escollos" que tiene la prueba. Cuando consiga pasar por ellas, se podrá de forma fehaciente afirmar que el codigo no generará errores.
La ventaja de esta codificacion es que a mayor bateria de pruebas, mas fiable será nuestro codigo y por otro lado, estas baterias de pruebas pueden ser extensibles a distintos procesos tengan conexion. Es decir, empleo la estructura de las pruebas a distintos procesos para probarlos.
POJO.-(Plain Old Java Object) Este acrónimo hace referencia a las clases mas internas de JAVA, no es mas que una clase básica(entendida como esencial) de JAVA. Cualquier clase que sea POJO posee unas propiedades y métodos tales que no dependen del Framework en el que se lancen. La union del POJO con las @notaciones da lugar al EJB3.
DATA PROVIDER.- Es una coleccion de Beans que nos permiten conectar a cualquier forma de datos incluyendo texto, XML o RDBMS.
Para ello se genera un Objeto que contengan ciertos datos, objeto que se marca con una anotacion tipo @DataProvider y un nombre.
Con posterioridad se pueden hacer pruebas de métodos empleando el contenido de este objeto y evaluar el resultado. Esto se emplea para cuando en el proyecto no se tiene una Base de Datos pero se requiere de ella. Así se puede simular la existencia de ella.
POLIMORFISMO.- Es una capacidad que tiene Java para a partir de una Clase determinada, se ejecute un método u otro de los generados en función de los parámetros con que se lanzan en ese momento.
El ejemplo mas utilizado es la obtencion de un área de cierta forma plana. Si se envia un radio, se ejecuta el metodo de obtencion de area de un circulo; si se envia un lado, se ejecuta el metodo de obtencion del area de un cuadrado, etc... esto permite reutilizar código.
ENCAPSULAMIENTO.- No logro entender bien lo que és. Imagino que es una forma de acceder indirectamente a ciertas clases a partir de otras, pero no logro entender que se pretende... (sigo buscando). En la -Wiki- se enrolla mucho y no logro enterarme.
Diagrama de Secuencia
Es un grafico en el cual se muestra un proceso en sus diferentes capas. Y en un eje temporal vertical como se produce el flujo de información entre las distintas capas. La información siempre parte del cliente que solicita una petición (entiéndase cualquier tipo de información de acceso, inclusión en BB.DD, etc… ) quien solo habla con el consolador de Usuario. El proceso continúa hasta realizarse el proceso en sí y recibir el cliente una información de conformidad(Ok) o no conformidad (NOOK) de ese proceso.
EasyMock
Easymock es una librería que se instala en Eclipse para generar pruebas.
Se generan los llamado MOCK que no son mas que un conjunto de sentencias que generan la prueba.
Se desconoce lo que ocurre en el interior del Mock, tan solo se devuelve una información tras ser alimentada la prueba con ciertos datos. Por ello es una prueba de tipo Caja Negra.(Recordemos que testNG es un metodo de prueba de caja blanca en la que en todo momento se conoce el contenido de variables, etc...).
Para hacer una prueba “Mock”, se tomará el caso de envío de un mail(prueba que se realizo en el proyecto de Carrito de Compra).
El código Java queda como sigue, con posterioridad a él se explicará cada sentencia.
(1) se crea una clase en el paquete de Test con el nombre de la prueba
(2) se crea la anotacion @Test para que Easymock reconozca que esa es la prueba en sí, se crea el método que se quiere probar. En realidad la prueba en sí es sobre este método EnviarMail() codificado en la correspondiente carpeta source “src”
(3) para realizar la prueba se necesita estabilizar el sistema con la información apropiada. Por ello se genera un nuevo cliente, con un controlador asociado a él, y un servicio de contacto(en el cual se crea un objeto)
(4) El Mock(es decir la prueba) referente a la prueba nuestra se resetea y se impone una condicion que espera que espera a la ejecución de cierto metodo
(5) Se hace un replay del Mock
(6) Se llama al servicio de contacto del controlador
(7) Se lanza el metodo a probar a traves del controlador empleando el cliente
(8) Se verifica que todo ha ido bien
De esta forma con EasyMock es posible hacer pruebas de código sin necesidad de poseer el que aún no está generado por otros desarrolladores, porque lo que hace es simular su buen o mal comportamiento. Así es posible delimitar los margenes de responsabilidad de cierto desarrollador en concreto, quien sabe que su código es correcto hasta el punto que le compete.
Se generan los llamado MOCK que no son mas que un conjunto de sentencias que generan la prueba.
Se desconoce lo que ocurre en el interior del Mock, tan solo se devuelve una información tras ser alimentada la prueba con ciertos datos. Por ello es una prueba de tipo Caja Negra.(Recordemos que testNG es un metodo de prueba de caja blanca en la que en todo momento se conoce el contenido de variables, etc...).
Para hacer una prueba “Mock”, se tomará el caso de envío de un mail(prueba que se realizo en el proyecto de Carrito de Compra).
El código Java queda como sigue, con posterioridad a él se explicará cada sentencia.
(1) se crea una clase en el paquete de Test con el nombre de la prueba
(2) se crea la anotacion @Test para que Easymock reconozca que esa es la prueba en sí, se crea el método que se quiere probar. En realidad la prueba en sí es sobre este método EnviarMail() codificado en la correspondiente carpeta source “src”
(3) para realizar la prueba se necesita estabilizar el sistema con la información apropiada. Por ello se genera un nuevo cliente, con un controlador asociado a él, y un servicio de contacto(en el cual se crea un objeto)
(4) El Mock(es decir la prueba) referente a la prueba nuestra se resetea y se impone una condicion que espera que espera a la ejecución de cierto metodo
(5) Se hace un replay del Mock
(6) Se llama al servicio de contacto del controlador
(7) Se lanza el metodo a probar a traves del controlador empleando el cliente
(8) Se verifica que todo ha ido bien
De esta forma con EasyMock es posible hacer pruebas de código sin necesidad de poseer el que aún no está generado por otros desarrolladores, porque lo que hace es simular su buen o mal comportamiento. Así es posible delimitar los margenes de responsabilidad de cierto desarrollador en concreto, quien sabe que su código es correcto hasta el punto que le compete.
2008-01-24
Refactorizacion
Es realizar un cambio de nombre de una clase, propiedad, o atributo que aparezca en cualquier clase de un paquete completo de una aplicación.
Así, si hay que hacer modificaciones en el código porque por ejemplo al unir el trabajo de dos o mas personas de un equipo, no ha habido un criterio único para gestionar nombres de variables, duplicidad de clases, etc... no hay que chequear todo el código e ir línea a línea cambiándolo.
Así, si hay que hacer modificaciones en el código porque por ejemplo al unir el trabajo de dos o mas personas de un equipo, no ha habido un criterio único para gestionar nombres de variables, duplicidad de clases, etc... no hay que chequear todo el código e ir línea a línea cambiándolo.
Herencia
Cuando una clase “a-a” adquiere propiedades de otra clase “b-b” (cosa que se indica en java como :
class a-a extends b-b{} )
Se dice que a-a es hija de b-b, a parte de esas propiedades puede tener las suyas propias por lo que es una clase mas amplia.
A ver si algún día heredo algo aunque sea con poca “clase” ….
class a-a extends b-b{} )
Se dice que a-a es hija de b-b, a parte de esas propiedades puede tener las suyas propias por lo que es una clase mas amplia.
A ver si algún día heredo algo aunque sea con poca “clase” ….
AOP vs. OOP
OOP es la programación orientada a objetos, en ella cada objeto es una clase y funciona relacionándose con el resto de clases(a través de sus métodos).
El usuario se relaciona con estos objetos (clases) a través del Controlador de Eventos. El hecho que las clases se relacionen entre sí a través del controlador de eventos implica que una modificación en las clases impacta sobre el resto de clases de alrededor y las pruebas que se realizan. Y por ello no solo habría que tener en cuenta la modificación de la clase en sí, sino de las que están a su alrededor, es decir, con las clases con quien esta se comunica.
AAP es la programación orientada a aspectos, en ella las clases siguen siendo igual que antes, objetos de por si.
Pero aquí la aplicación se separa en aspectos, las pruebas y las codificaciones ya no son por objetos sino que varias clases que se crean con un fin determinado seguridad, envío_de_información, historial_de_sucesos conforman lo que se llama un Aspecto. Un aspecto no es más que un módulo(por llamarlo de alguna forma), un pequeño sistema que si se alimenta de cierta información es capaz de generar ciertas acciones sin requerir de nadie más.
Así las pruebas que se realizan aquí van dirigidas al aspecto en sí.
Aquí todo el software se crea a partir de la prueba, es decir, se prepara la prueba y a posteriori se genera el código que debe superar las diferentes pruebas a las que es sometido.
El usuario se relaciona con estos objetos (clases) a través del Controlador de Eventos. El hecho que las clases se relacionen entre sí a través del controlador de eventos implica que una modificación en las clases impacta sobre el resto de clases de alrededor y las pruebas que se realizan. Y por ello no solo habría que tener en cuenta la modificación de la clase en sí, sino de las que están a su alrededor, es decir, con las clases con quien esta se comunica.
AAP es la programación orientada a aspectos, en ella las clases siguen siendo igual que antes, objetos de por si.
Pero aquí la aplicación se separa en aspectos, las pruebas y las codificaciones ya no son por objetos sino que varias clases que se crean con un fin determinado seguridad, envío_de_información, historial_de_sucesos conforman lo que se llama un Aspecto. Un aspecto no es más que un módulo(por llamarlo de alguna forma), un pequeño sistema que si se alimenta de cierta información es capaz de generar ciertas acciones sin requerir de nadie más.
Así las pruebas que se realizan aquí van dirigidas al aspecto en sí.
Aquí todo el software se crea a partir de la prueba, es decir, se prepara la prueba y a posteriori se genera el código que debe superar las diferentes pruebas a las que es sometido.
Suscribirse a:
Entradas (Atom)
