jueves, 24 de mayo de 2012
miércoles, 4 de abril de 2012
Práctica 5
Memoria:
Descarga:
Mediafire
Trabajo:
Descarga:
Mediafire
jueves, 22 de marzo de 2012
Tema complementario III
Lectura recomendada. Patrones de Diseño, Refactorización y Antipatrones. Ventajas y Desventajas de su utilización en el Software Orientado a Objetos.
Descarga:
Mediafire
PREGUNTAS:
1. Cuando una clase conoce o hace demasiado monopolizando el sistema, ¿de que antipatrón estamos hablando?
a) The blob
b) Lava flow
c) Golden hammer
d) Ninguna de las anteriores
2. Cuando hablamos de refactorización, ¿cuál de estas afimaciones es falsa?
a) La refactorización facilita el diseño del software.
b) La refactorización facilita la comprensión del código fuente.
c) La refactorización permite detectar errores.
d) La refactorización permite programar más rápido.
3. Por Patrones de Diseño entendemos.
a) Una metodología ágil que consiste en el uso de patrones de código ya hecho para agilizar la programación.
b) Una metodología ágil que propone la creación de patrones de diseño durante esa fase, para ser usados como referencia rápida luego durante la fase de desarrollo.
c) Un conjunto de normas a seguir para que el software desarrollado cumpla con los estándares impuestos.
d) Un conjunto de soluciones a un problema común durante el desarrollo de software.
4. Señala la respuesta incorrecta.
a) Los Patrones de Arquitectura se centran en la arquitectura del software a nivel general.
b) Los Patrones de Diseño intentan establecer un lenguaje común entre diseñadores.
c) Los Patrones de codificación o Dialectos sirven para sintetizar correctamente el software y empaquetarlo para su posterior uso.
d) Los Patrones de Diseño fueron creados para la arquitectura, pero su uso se extendió en el desarrollo de software.
5. Cuando hablamos del uso de antipatrones podemos establecer una serie de pasos.
a) Encontrar el problema, Establecer un patrón de fallas, Refactorizar el código, Publicar la solución, Identificar debilidades, Corregir el proceso.
b) Encontrar el problema, Establecer un patrón de fallas, Refactorizar el código, Identificar debilidades, Corregir el proceso.
c) Refactorizar el código, Encontrar el problema, Establecer un patrón de fallas, Identificar debilidades, Corregir el proceso, Publicar la solución.
d) Refactorizar el código, Encontrar el problema, Establecer un patrón de fallas, Identificar debilidades, Corregir el proceso.
6. ¿En qué grupos se ordenan los 23 patrones de diseño según el libro “Gang Of Four”?
a) Patrones creacionales, estructurales y de comportamiento.
b) Patrones creacionales, de diseño, estructurales y de comportamiento.
c) Patrones de diseño, estructurales, y de comportamiento.
d) Patrones de diseño y comportamiento.
7. ¿Qué desventajas tiene la refactorización?
a) Se corre el riesgo de que el sistema no funcione como antes de la refactorización.
b) Problemas con la base de datos y con las interfaces.
c) Que se enfade el programador por retocar “su” código.
d) Surjan más problemas en el código de los que ya había.
8. ¿En qué se centra el nivel de Desarrollo del estudio de antipatrones?
a) Se centra en los problemas recurrentes relacionados a la estructura del sistema, sus consecuencias y soluciones.
b) Comunicarse con la gente y resolver problemas.
c) Describe situaciones encontradas por programadores en la resolución de problemas de programación.
d) Todas las respuestas son correctas.
Práctica 4: Herramientas CASE
Memoria:
Descarga:
Mediafire
Trabajo:
Descarga:
Mediafire
Manual de usuario:
Descarga:
Mediafire
miércoles, 21 de marzo de 2012
Tema complementario II: ATDD
ATDD (Acceptance Test Driven Development)
INTRODUCCIÓN
En TDD las pruebas unitarias son definidas por el programador y no están necesariamente relacionadas con los requisitos. Existen dos enfoques cercanos que también han llevado la filosofía de TDD al terreno de los requisitos, estos son Acceptance Test Driven Development (ATDD) y Behaviour Driven Development (BDD), nosotros nos centraremos en ATDD.
ATDD es una evolución de TDD, orientada a resolver la falta de comunicación con el cliente y abordar adecuadamente los cambios que pueda introducir a lo largo del proceso de desarrollo. En ATDD el proceso de desarrollo está dirigido por las pruebas de aceptación, las cuales deberían ser escritas por el cliente con la ayuda de un desarrollador. Podríamos decir que las pruebas de aceptación proporcionan al cliente un contrato legible y ejecutable que el programador tiene que cumplir, y son usadas como documentación en un entorno ágil, dejando de ser únicamente un artefacto de pruebas como se utiliza en TDD. Para la mayoría de profesionales, un requisito en ATDD es una historia de usuario, especificada con una breve descripción narrativa y a la cual se le asocia un conjunto de pruebas de aceptación, escritas normalmente en lenguaje natural.
CARACTERÍSTICAS
El ATDD ayuda a coordinar los proyectos de software de manera que entregaremos lo que el cliente desea. Según Koskela, una buena prueba de aceptación debe ser:
- Propiedad de los clientes.
- Escrito en conjunto con los clientes, desarrolladores y analistas de prueba.
- Sobre el Qué y no sobre el Cómo.
- Expresada en lenguaje de dominio del problema.
- Conciso, preciso y sin ambigüedades.
PASOS A SEGUIR
Hasta aquí hemos descrito una prueba de aceptación que podría simplemente estar dentro de un documento Word o una plantilla Excel. Entonces, ¿cuál es la diferencia de la prueba de aceptación tradicional para la prueba de aceptación "clásica"? En primer lugar es que en ATDD la prueba debe ser automatizada. Este es un punto esencial para realizar las pruebas regresivas continuas. En segundo lugar, las pruebas de aceptación son escritas antes de la funcionalidad. Pero, ¿cómo? siguiendo los pasos a continuación:
- Tome una historia o flujo de caso de uso.
- Escriba las pruebas de aceptación en el lenguaje de dominio del cliente.
- Automatice las pruebas de aceptación.
- Implemente la funcionalidad.
HERRAMIENTAS
Existen actualmente en el mercado una enorme cantidad de herramientas para realizar las Pruebas de Aceptación:
- Canoo
- Concordion
- FitNesse
- JBehave
- JMeter
- Sahi
- Selenium
- SoapUI
- Watir
- easyb
CONCLUSIÓN
ATDD está orientado a la automatización de pruebas y generación de código.
En ATDD las pruebas se automatizan inmediatamente al ser identificadas, no existe separación temporal en cuanto a la especificación de la prueba y su correspondiente implementación.
Nuestro enfoque no obliga a instanciar las pruebas cuando se definen los requisitos ya que dejará en manos de los testers el determinar las mejores combinaciones de datos y el decidir si es conveniente la automatización de la prueba dentro de la misma iteración en la cual se incorpora el cambio asociado a la prueba.
Finalmente, el enfoque ATDD no aborda la problemática de gestionar la gran cantidad de pruebas que se generan. Es esencial disponer de mecanismos para manipular de forma ágil las PAs, particularmente en un contexto de mantenimiento continuo de un producto.
ATDD siempre vendrá acompañada de alguna metodología ágil, pienso que nos quedaremos cortos si solo apostamos por ATDD de forma aislada.
REFERENCIAS UTILIZADAS
PREGUNTAS:
1. Las pruebas de aceptación proporcionan al cliente:
a) Un contrato legible y ejecutable que el programador tiene que cumplir.
b b) La seguridad de que no ocurran errores.
c c) Unas bases para saber la capacidad del programador.
) d) La garantía de que el proyecto durara el tiempo estipulado.
2 2. ¿Porque es necesario instanciar las pruebas de aceptación?
a a) Porque el cliente tiene que guiar cada prueba de aceptación.
b b) Porque así se pueden verificar los errores en cada prueba.
c c) Porque así los grupos de programadores trabajan con más comunicación con el cliente.
d d) Porque no existe separación temporal en cuanto a la especificación de la prueba y su correspondiente implementación.
3 3. ¿Qué filosofía sigue ATDD?
a a) XP.
b b) RUP.
c c) TDD.
d d) BDD.
4 4. En ATDD, ¿Cómo realiza el cliente las pruebas de aceptación?
a a) Con un lenguaje de programación (C#, Java, etc.).
b b) En lenguaje natural.
c c) Mediante diagramas, utilizando UML.
d d) Ninguna de las anteriores.
5 5. ATDD está orientada a…
a a) La generación de código y su posterior análisis y depuración.
b b) La comunicación constante de cliente-desarrollador para omitir pruebas innecesarias.
c c) La automatización de pruebas y generación de código.
d d) Ninguna de las anteriores.
6 6. En Acceptance Test Driven Development (ATDD):
a a) Se intenta reducir el código innecesario generado.
b b) Se dan pluses a aquellos desarrolladores que más comunicación tengan con el cliente.
c c) Se generan gran cantidad de documentos técnicos para realizar las pruebas.
d d) Ninguna de las anteriores.
7 7. ¿Cuál de las siguientes herramientas puede servir en ATDD?
a a) FitNesse.
b b) Selenium.
c c) Concordion.
d d) Todas las anteriores son correctas.
8 8. En ATDD, ¿cómo debe ser una buena prueba de aceptación?
a a) Desarrollada por los programadores y revisada por los clientes.
b b) Escrita en conjunto con los clientes, desarrolladores y analistas de prueba.
c c)Escrita en lenguaje de programación por los clientes para que los programadores la entiendan de una forma más rápida.
d d) Ha de ser larga y muy bien detallada, para que no se escape ningún tipo de requisito.
sábado, 10 de marzo de 2012
Tema Complementario I: Test Driven Development (TDD)
TEST DRIVEN DEVELOPMENT
INTRODUCCIÓN
Según el Desarrollo Guiado por Pruebas o Test Driven Development, en inglés, es el programador quien realiza las pruebas de unidad de su propio código, e implementa esas pruebas antes de escribir el código a ser probado.
Cuando el programador recibe el requerimiento de implementar una parte del sistema, y una vez que comprendió cuál es la funcionalidad pretendida, debe empezar por pensar qué pruebas va a tener que pasar ese fragmento de programa (o unidad) para que se considere correcto. Luego procede a programar, pero no el código de la unidad que le tocó, sino el código que se va a encargar de llevar a cabo las pruebas. Cuando está satisfecho de haber escrito todas las pruebas necesarias (y no antes), comienza a programar la unidad, con el objetivo de pasar las pruebas que programó.
La forma de trabajo del programador también cambia mucho durante la escritura del código funcional propiamente dicho. En lugar de trabajar durante horas o días hasta tener la primera versión en condiciones de ser probada, va creando pequeñas versiones que puedan ser compiladas y pasen por lo menos algunas de las pruebas. Cada vez que hace un cambio y vuelve a compilar, también ejecuta las pruebas de unidad. Y trata de que su programa vaya pasando más y más pruebas hasta que no falle en ninguna, que es cuando lo considera listo para ser integrado con el resto del sistema.
CARACTERÍSTICAS
Una ventaja de esta forma de programación es el evitar escribir código innecesario ("You Ain't Gonna Need It" (YAGNI)). Se intenta escribir el mínimo código posible, y si el código pasa una prueba aunque sepamos que es incorrecto nos da una idea de que tenemos que modificar nuestra lista de requerimientos agregando uno nuevo.
La generación de pruebas para cada funcionalidad hace que el programador confíe en el código escrito. Esto permite hacer modificaciones profundas del código (posiblemente en una etapa de mantenimiento del programa) pues sabemos que si luego logramos hacer pasar todas las pruebas tendremos un código que funcione correctamente.
Otra característica del Test Driven Development es que requiere que el programador primero haga fallar los casos de prueba. La idea es asegurarse de que los casos de prueba realmente funcionen y puedan recoger un error.
DESARROLLO
La metodología TDD, a grandes rasgos, se basa en lo siguiente:
- Se construyen las pruebas unitarias (o se puede extender si se desea el concepto a otros tipos de pruebas de más alto nivel, siempre y cuando sea automatizable su ejecución).
- A continuación se construye el componente software que debe verificar las reglas de funcionamiento definidas en las pruebas.
- Una vez que se tiene un software que verifica las pruebas implementadas, se procede a su refactorización.
VENTAJAS
-En ocasiones contadas, los programadores necesitarán ejecutar el depurador o debugger.
-Produce aplicaciones de mayor calidad en un tiempo menor, a pesar de los elevados requisitos iniciales.
-Permite que el programador se centre en la tarea actual y como objetivo hacerla pasar las diferentes pruebas establecidas.
-Da confianza a los programadores en su código, ya que habrá pasado por las pruebas.
LIMITACIONES
-Complejidad a la hora de automatizar las pruebas.
-Es difícil el uso de esta metodología en situaciones en las que requieren pruebas completas de funcionalidad del sistema.
-Es muy importante diseñar y codificar test de bajo y fácil mantenimiento.
-Las pruebas en el desarrollo de software tienen una menor importancia que el desarrollo o arquitectura de software, pero son fundamentales.
CONSLUSIONES Y OPINIÓN PERSONAL
Una de las grandes diferencias con el estilo de trabajo tradicional es que ya no compite con otro u otros, sino que compite consigo mismo; se enfrenta al desafío de escribir código que pase las pruebas que él mismo programó. Y siguiendo las premisas de muchos de los métodos ágiles, solamente programará lo que sea estrictamente necesario para ese fin.
La ventaja de desarrollar las pruebas antes de implementar los componentes es la indicada en el párrafo anterior, es decir, enfrentarse y comprender el problema antes de empezar a resolverlo. Si las pruebas unitarias se construyen después, no estaríamos hablando de TDD, eso es importante, por lo que lo repito, si las pruebas unitarias se construyen después se trata de otra estrategia de desarrollo de software, no de desarrollo guiado por las pruebas.
Se sabe que cuanto más tarde se detecten los errores más esfuerzo se requiere para solucionarlo, esta técnica pretende disminuir el riesgo por la presencia de errores de ese tipo, además de facilitar un código donde sea mucho más fácil trabajar, tanto para corregir esas incidencias como para construir nuevas funcionalidades o modificar, si fuera necesario (el software es de naturaleza adaptativa), las ya implementadas.
REFERENCIAS UTILIZADAS
PREGUNTAS:
1. ¿Cuál de estas reglas se incluye en Test Driven Development?:
a) Se deben evitar las pruebas automáticas, ya que no nos aportan suficiente información de los fallos.
b) No se puede escribir más código productivo del estrictamente necesario para hacer pasar un test.
c) Los errores de compilación no se consideran fallos.
d) Las pruebas unitarias deben de ser lo mas grande posible para ahorrar futuras pruebas.
2. En el TDD, ¿qué afirmación es falsa?:
a) El uso de las base de datos hace que las pruebas sean menos costosas.
b) Se intenta escribir el mínimo código posible.
c) La generación de pruebas para cada funcionalidad hace que el programador confíe en el código.
d) Se requiere que el programador primero haga fallar los casos de prueba.
3. Según el TDD, ¿quién es el encargado de realizar las pruebas unitarias?
a) Gerente del proyecto.
b) Product Owner.
c) Coordinador técnico.
d) El propio programador.
4. ¿Cómo se puede abreviar el ciclo de vida del TDD?
a) Refactor-rojo-verde (haciendo referencia a hacer un refactor, a fallar un test y hacerlo pasar).
b) Rojo-refactor-verde (haciendo referencia a fallar un test, hacer un refactor y hacerlo pasar).
c) Rojo-verde-refactor (haciendo referencia a fallar un test, hacerlo pasar, y hacer un refactor).
d) Verde-rojo-refactor (haciendo referencia a hacer pasar un test, fallar el test y hacer un refactor).
5. ¿Cúal de las siguientes disciplinas no pertenece al ciclo de vida del TDD?
a) Escribir una prueba
b) Elegir un requisito
c) Definir la lista de requisitos
d) Ejecutar las pruebas automatizadas
6. ¿De qué metodología evolucionó el TDD?
a) Scrum
b) XP
c) RUP
d) DSDM
7. Tras generar las pruebas e implementarlas, el programador:
a) Comienza la programación de la solución, y no se prueba hasta que no está generado todo el programa en sí.
b) Debe esperar a que el cliente de el visto bueno a los test generados.
c) Se programa la funcionalidad con vistas a fallar en las pruebas, para así saber que son correctas.
d) Juntan todas las pruebas para hacer un gran test a pasar posteriormente.
8. ¿Cual de las siguientes afirmaciones NO es correcta?
a) Como los programadores hacen pruebas que les imponen sus compañeros y el cliente, el código que surge es más robusto.
b) Aunque inicialmente en el TDD hay que crear muchas pruebas antes de comenzar la implementación final, se hace un desarrollo más rápido.
c) Uno de los objetivos es intentar escribir la mínima cantidad de código posible.
d) Las pruebas unitarias son obligatorias y una funcionalidad no se da por acabada hasta que las pase.
jueves, 8 de marzo de 2012
Práctica 3
Memoria:
Descarga:
Mediafire
Trabajo:
Descarga:
Mediafire
Suscribirse a:
Entradas (Atom)