Manual de Técnicas de Desarrollo

SolucionJava.
com
Reproducción prohibida
Ing. Cedric Simon – Tel: 268 09 74 – Cel: 888 23 87 – Email: c e d r i c @ s o l u c i o n j a v a . c o m – Web: www.solucionjava.com
técnicas de desarrollo
Manual del alumno

Curso de
©Copyright Cédric Simon, 2008
Profesor: Cédric Simon
Curso de técnicas de desarrollo Pagina 2 / 13
1 Índice
Índice....................................................................................................................................................................................2
1 Introducción al curso.........................................................................................................................................................3
1.1 Objetivo de este curso......................................................................................................................................................3
1.2 Manual del alumno...........................................................................................................................................................3
1.3 Requisitos para atender a este curso.............................................................................................................................3
1.4 Soporte después del curso................................................................................................................................................3
2 Ciclo de vida del desarrollo de una aplicación.................................................................................................................4
2.1 Objetivo..............................................................................................................................................................................4
2.2 Establecimiento de los requisitos...................................................................................................................................4
2.3 Estimación de alta nivel...................................................................................................................................................4
2.4 Diseño funcional................................................................................................................................................................4
2.5 Diseño técnico....................................................................................................................................................................5
2.6 Desarrollo...........................................................................................................................................................................5
2.7 Pruebas unitarias..............................................................................................................................................................5
2.8 Plan de prueba .................................................................................................................................................................6
2.9 Integración.........................................................................................................................................................................6
2.10 Pruebas de usuarios.......................................................................................................................................................6
2.11 Producción.......................................................................................................................................................................6
2.12 Parches.............................................................................................................................................................................6
3 Manejo de versiones...........................................................................................................................................................7
3.1 Uso de programa de manejo de versiones.....................................................................................................................7
3.1.1 Sistema de bloqueo................................................................................................................................................7
3.1.2 Sistema de fusión..................................................................................................................................................8
3.1.3 CVS.......................................................................................................................................................................9
3.1.4 Subversion.............................................................................................................................................................9
3.2 Ramas de desarrollo.........................................................................................................................................................9
3.3 Integración de CVS con herramientas de desarrollo : Eclipse y CVS...................................................................10
4 Documentación del código..............................................................................................................................................11
4.1 Uso.....................................................................................................................................................................................11
4.2 Objetivo............................................................................................................................................................................11
4.3 Estandartes......................................................................................................................................................................11
5 Reglas de nombramiento.................................................................................................................................................12
5.1 Objetivo............................................................................................................................................................................12
5.2 Ejemplos de reglas de nombramiento.........................................................................................................................12
5.3 Nombramiento de códigos.............................................................................................................................................12
5.4 Nombramientos de variables........................................................................................................................................12
© Copyright Cédric Simon, 2007 Versión 1.0 Reproducción prohibida

1 Introducción al curso
1.1 Objetivo de este curso
Este curso intenta dar al alumno buenas costumbres de desarrollo y claves para desarrollar aplicaciones
estables, sostenible, y listas para crecer.
1.2 Manual del alumno
Este manual del alumno es una ayuda para el alumno, para tenga un recuerdo del curso. Este manual
contiene un resumen de las materias que se van a estudiar durante el curso, pero el alumno debería de
tomar notas personales para completas este manual.
1.3 Requisitos para atender a este curso
No hay requisitos para seguir este curso, pero una experiencia previa en desarrollo de aplicaciones es
deseable para entender mejor el fin del curso.
1.4 Soporte después del curso
Si tienes preguntas sobre la materia del curso en tus ejercicios prácticos, puedes escribir tus
preguntas a cedric@solucionjava.com .
Para informaciones sobre otros cursos, visita el sitio web www.solucionjava.com .

2 Ciclo de vida del desarrollo de una
aplicación
2.1 Objetivo
Para lograr un desarrollo sostenible es importante conocer y respetar el ciclo de vida de una aplicación.
El ciclo explicado enseguida sirve tanto para el desarrollo de nueva aplicaciones como para modificar una
aplicación existente.
Cuando se desea cambiar una varias partes de una aplicación se agrupan en un proyecto, y el proyecto
sigue el ciclo de vida explicado abajo.
Dependiendo del tamaño de la aplicación y de la empresa, las etapas tomarán más o menos importancia.
Entre más grande es la aplicación, más importante es de pegarse a cada paso.
Para aplicaciones grande y/o importantes, se utilizan varios ambientes. Es decir que la aplicación existe
en varios ejemplares. Debería de tener siempre un mínimo de dos ambientes: producción y desarrollo.
Otros ambientes pueden ser el ambiente de integración, el de prueba de usuario, el de capacitación, y el
de referencia.
2.2 Establecimiento de los requisitos
Es a veces lo más difícil de conseguir, pero es lo más importante. Los usuario o el cliente debe explicar
claramente que es lo que el quiere.
Para eso el debe listar todos sus requisitos de manera detallada.'Haga como en tal otro modulo...' no se
puede aceptar como un requisito válido, pero le concedo que a veces hay que aceptarlo (el cliente es
rey...).
Cuando los requisitos no están muy detallados, es muy importante detallarlos en la análisis funcional,
para estar seguro que lo que se va a desarrollar es lo deseado.
2.3 Estimación de alta nivel
Este paso es opcional. Es una estimación 'a primera vista' del esfuerzo (trabajo) necesario para
implementar los cambios o desarrollar la aplicación requerida.
Eso sirve para estimar el costo y planificar los recursos necesarios.
2.4 Diseño funcional
Es la traducción de los requisitos (punto 2.2) en un diseño 'informático'. Por ejemplo, se describirá como
parecerán las pantallas del GUI, los flujos de pantallas y los flujos de negocios que se implementarán.

La persona que redacta el diseño funcional debe tener una idea general que como se implementará a
nivel técnico, para evitar de proponer en el diseño algo que no se puede implementar, o que pediría un
esfuerzo demasiado grande para implementar.
Es buena idea que un programador revisa este diseño ante que se le presenta al cliente, para tener un
acuerdo tácito de que, a primera vista, se puede implementar al nivel técnico dentro del costo (tiempo)
estimado.
En caso que se hizo una estimación de alta nivel, el esfuerzo/costo se puede confirmar, afinar, o modificar
aquí.
El objetivo es que el cliente 'firma' el diseño funcional como acuerdo de los que se va a desarrollar. Este
documento servirá de base para la evaluación (prueba) de la aplicación.
Si al final algo no funciona como esperado, hay que regresar al diseño funcional para averiguar si el
punto que da problema estaba presente en el diseño o no. Si no estaba ni en el diseño ni en los
requisitos, se trata de un nuevo requisito (a cargo del cliente). Si está presente y funciona como descrito,
es se trata de un cambio de requisito (a cargo del cliente). Si está presente pero no funciona como
descrito, es un error de programación que hay que corregir (a cargo del desarollador).
Un ejemplo de diseño funcional está disponible en el CD (AF Siminsa en linea.pdf).
2.5 Diseño técnico
Es la traducción del diseño funcional en una solución técnica. Se describe la arquitectura técnica que se
va a utilizar para programar lo requerido.
El diseño técnico no debería de contener código fuente, si no la estructura del código que se va a utilizar
y de los cambios necesarios. Que sean cambios de la base de datos, nuevos objetos Java, servlet,...
Una vez finalizado, este diseño debería ser revisado y aprobado por el analista funcional ante de iniciar
el desarrollo.
2.6 Desarrollo
Es la aplicación del diseño técnico y el propio desarrollo de la aplicación.
En caso que se hizo una estimación de alta nivel, el esfuerzo/costo se puede confirmar, afinar, o modificar
aquí.
En caso que se encuentra algún problema (la solución imaginada no funciona o da problemas), hay que
revisar la situación con el analista funcional, y eventualmente el cliente si el impacto es grande.
2.7 Pruebas unitarias
Después de haber hecho su desarrollo, el programador debe probar su código de manera unitaria. Es
decir, cada código aparte sin tener en cuenta la totalidad de la aplicación. Las pruebas se deberían de
hacer en condiciones similar a la producción. Es decir que si la aplicación funciona en 3tiers, hay que
probarla en 3tiers también.

Las pruebas hechas se deben registrar y presentar al analista funcional para poder concluir que el código
está listo para pasar al ambiente de integración.
2.8 Plan de prueba
Una vez el diseño funcional aprobado, el analista funcional y los usuarios deberían(cada uno) que
escribir un plan de prueba.
El plan de prueba debe contener además de las pruebas del código nueva, pruebas de regresión, para
verificar que las principales funciones de la aplicación preexistente no han sido impactado de manera no
deseada.
2.9 Integración
Este paso es el puesto en común de todos las modificaciones de la aplicación, ya que varios proyectos
diferentes pueden desarrollarse en paralelo, y que más de un programador puede trabajar en el proyecto.
Aquí es que el analista funcional hará sus pruebas para validar la aplicación, antes de entregarla al
cliente.
La pruebas deberían ser documentadas, así como los problemas encontrados.
Además de probar las nuevas funciones o cambios del sistema, se debe siempre efectuar pruebas de
regresión para asegurarse que todas las funciones importantes de la aplicación, mismo si no han sido
modificada directamente, siguen funcionando como esperado.
2.10Pruebas de usuarios

Aquí son los usuarios que van hacer sus pruebas.
La pruebas deberían ser documentadas, así como los problemas encontrados.
Una vez las pruebas terminadas, el cliente decide si el está de acuerdo que la aplicación pasa a
producción o no.
2.11Pruebas de rendimiento

Aquí se va a probar el rendimiento de la aplicación. Las pruebas de rendimiento se deberían efectuar
sobre un ambiente lo más parecido posible a la producción.
Se van a probar entre otros la carga que soporta el sistema, el tiempo de ejecución de los interfaces
'batch', y el rendimiento de las diferentes partes del sistema.
El objetivo es detectar antes de producción posibles problemas de rendimientos (por ejemplo consulta
SQL no optimizada), y conocer las limites de carga del sistema (usuarios, transacciones,...). Existen
programas que permiten generar carga del sistema simulando múltiples usuarios., como JMeter.
2.12Producción

Aquí es donde se usa finalmente la aplicación. Debe ser un ambiente estable. La producción no se
debería de modificar muy seguido.

2.13Parches

Los parches son correcciones de códigos por errores que no fueron detectadas antes de producción o que
lo fueron pero que no eran críticas y no se podían corregir a tiempo para pasar en producción. También
pueden servir para implementar cambios pequeños (requisito modificado en camino del desarrollo del
proyecto).
Los parches deben de seguir el mismo ciclo (puntos 2.2 a 2.11), pero más ligeramente.
2.14Seguimiento de problemas

Para seguir el estado de los problemas que fueron reportados, les aconsejo el uso de algún tipo de
programa. Lo más simple sería un archivo texto o un tabulador, hasta programas diseñados para este
tipo de actividad (por ejemplo Peregrine). Personalmente, he diseñado un programa, basado en mi
experiencia con Peregrine, para el seguimientos de actividades (proyectos, parches, problemas...) que de
llama VIDA, está escrito en Java (JSP) con base de datos MySQL.

3 Manejo de versiones
3.1 Uso de programa de manejo de versiones
Uno de los problemas en la vida de una aplicación es de saber cual es la versión actual (en producción) de
los archivos, sin tener que sacar una copia de la producción, de poder retroceder hacia una versión
anterior. Otro problema es el desarrollo concurrente (varios programadores trabajando sobre un mismo
código).
Para contestar estos problemas existen los programas de manejo de versiones. Estos programas van a
guardar todos los archivos en un repositorio . Se incrementará automáticamente el número de versión de
un archivo cada vez que se guarda una nueva versión del archivo en el repositorio, y se le podrá adjuntar
un comentario con el fin de poder trazar el histórico del archivo.
En un sistema típico de cliente servidor, una sola persona puede tener el derecho de escribir en el
archivo, los demás solo lo pueden leer. Si dos personas leen el mismo archivo, lo modifican cada uno de
su lado y luego lo escriben, la segunda persona va a sobrescribir los cambios hechos por la primera
persona, perdiendo su trabajo.
El problema a evitar
Para evitar este problema de sobre escritura, existen dos soluciones: el bloqueo del archivo, y la fusión de
archivos.
3.1.1 Sistema de bloqueo
Con el sistema de bloqueo, un usuario adquiere un bloqueo de un archivo, lo que impide cualquier otro
usuario de modificar lo hasta que el bloqueo haga sido quitado.

Con este sistema, un archivo solo puede ser utilizado por un usuario. No se permite el desarrollo
concurrente.
Esto asegura que al momento de guardar su copia, nadie ha modificado en archivo de desde el bloqueo.
El puede sobrescribir el archivo en el repositorio sin riesgo de sobrescribir los cambios hechos por otro
usuario.
La solución de bloqueo – lectura escritura desbloqueo
3.1.2 Sistema de fusión
Con el sistema de fusión, los usuario guardan una copia del archivo en local, y al momento de guardarlo
el sistema detecta si alguien de otro modifico el archivo en el repositorio desde el momento de la copia en
local. En caso que si, tendrá que ocurrir una fusión de los cambios antes de poder guardarlos. Eso
permite el desarrollo concurrente.
La fusión se puede pasar automáticamente o manualmente. En caso de conflictos (por ejemplo una
misma línea modificada por dos personas), hará que resolverlos manualmente.
Hay que notar que la fusión funciona muy bien cuando el código se fusiona y se compilan en la
herramienta misma (como Eclipse), pero no tanto cuando se fusiona afuera del entorno, a menos que se
valida luego todo el código fusionado, lo que puede ser fastidioso. Para estos últimos, el bloqueo es una
mejora opción.

La solución copiar – modificar fusionar

3.1.3 CVS
CVS es un programa libre que permite manejar versiones de archivos. Es el sistema más soportados, y
muchas herramientas soportan por defecto la conexión con un repositorio de CVS.
Más información en www.cvs.org
3.1.4 Subversion
Subversion es un sistema de control de versión como CVS (el herede de CVS), pero con más
posibilidades. Entre otros, Subversion permite versionar carpetas, sobrevivir en el histórico a un cambio
de nombre de un archivo, y soporta varios tipos de conexión, entre otros HTTP o HTTPS. Se está
haciendo muy popular por lo que supera a CVS y es gratis.
Más información en htt
p://subversion.tigris.org/

3.2 Ramas de desarrollo
Los programas de control de versión permiten crear ramas dentro del repositorio.
El código 'original' se encuentra en el tronco (TRUNK / HEAD). Cuando se inicia un proyecto de
modificaciones, se crea una rama saliendo del tronco, y se trabajará en esta rama. Cuando el proyecto
pasa a producción se pone al día el tronco con las modificaciones.

Ramas de desarrollo
Histórico de un archivo con rama
3.3 Integración de CVS con herramientas de desarrollo :
Eclipse y CVS
Eclipse se integra de manera nativa con CVS, y vía un plugin con Subversión.
Vamos a crear un nuevo proyecto, guardarlo en CVS, y luego cargar el proyecto en otro computadora,
modificar un archivo en ambos computadoras y ver como se comporta la fusión de las modificaciones.
Hay que notar que los entornos están en ingles.

4 Documentación del código
4.1 Uso
La documentación del código sirve tanto para el creador del código como para los otros programadores
que luego modificarán el código.
La documentación se puede encontrar en dos lugares distintos: en el código mismo o afuero en otro
archivo.
La documentación que se guarda afuera es de dos tipos: el diseño técnico, que da la estructura general, y
la implementación técnica, que da los detalles técnico sobre el código mismo. Un ejemplo de esa última
documentación en la JavaDoc.
4.2 Objetivo
El objetivo de la documentación del código es tanto para que otra persona pueda entender como funciona
el código, como con fines de auditoria, para que alguien que tiene que cambiar un código que el conocía
antes se puede dar cuenta si alguien de otro lo tocó y que se le ha cambiado.
4.3 Estandartes
Si no existen estandartes internacionales de documentación del código, es muy importante que dentro de
una misma organización se implementan estandartes para que todo el mundo trabaja de la misma
manera y que un programador puede encontrar la información fácilmente, sin importancia de quien creo
o cambió el código.
Entonces hay dos tipo de información en la documentación: los datos históricos y los detalles técnicos.
Un caso especial es la JavaDoc. Para utilizar la JavaDoc, que crea una documentación en formato HTML
sobre las clases y sus métodos automáticamente basándose en comentarios estructurados a dentro del
código Java, hay que respetar unos estandartes para que se pueda generar la documentación (que
JavaDoc sepa cuales son los comentarios a incluir en la documentación).
Para la información histórica, le aconsejo de colocarla en cabeza del código, con los datos siguiente: la
versión del archivo o de la aplicación, la fecha del cambio, las iniciales o el nombre del programador que
hizo el cambio, y la descripción general del cambio.
Por ejemplo:
/*
* Version Fecha Programador Detalles
* 1.0 10/03/06 Cedric Creación del código. Proyecto no 845.
* 1.0.1 02/05/06 Cedric Corrección bug no 245
* 1.1 05/10/06 Jose Adjunto de la posibilidad de mencionar origen de la
* compra. Proyecto no 1545.
*/
Cuanto al la documentación técnica en el código, hay no hay realmente estandartes. Hay que probar de
meter suficiente información para que otro programador pueda 'entrar' fácilmente en el código y
entender a donde modificar lo para lograr su proyecto. Las reglas de nombramiento también ayudan a
documentar el código.

5 Reglas de nombramiento
5.1 Objetivo
Las reglas de nombramiento permiten que los programadores puedan entender fácilmente la estructura
de un código y interactuar más fácilmente con otros códigos.
Ciertos lenguaje tienen estandartes internacionales muy seguidos, como el lenguaje Java. Otros no, y se
tiene que definir un estándar a nivel local.
Existen restricciones de nombramiento que son propias a cada lenguaje, Por ejemplo, por lo general un
nombre de variable no puede ser igual a una palabra reservada del lenguaje.
También, ciertos lenguajes son sensibles a mayúsculas y minúsculas, y otros no. Ciertos lenguajes
permiten el uso de acentos, pero no se lo aconsejo porque puede dar confusión si uno lo utiliza y otro no,
o si trabaja con dos lenguaje del cual uno acepta acentos y otro no. También ciertas herramientas no
soportan los acentos, y si trabaja con Linux o Unix y Windows, copiando archivos de un sistema al otro
podría dar problemas con los acentos.
Es siempre importante elegir un nombre que sea inteligible, es decir que cuenta los que contiene el
archivo/código/variable...
5.2 Ejemplos de reglas de nombramiento
Las reglas de nombramiento ayudan a encontrar fácilmente un archivo. Por ejemplo, se puede definir
que todos los nombres de archivos serán en minúscula, con subraya para separar nombres internos (por
ejemplo pagina_de_inicio.html).
5.3 Nombramiento de códigos
Además del código principal van también partes internas del códigos (como la clase y sus métodos). Es
bueno definir una regla de nombramiento para cada tipo de parte de código.
Cuando hay varios códigos muy cercanos, con acción muy parecida (por ejemplo los disparadores), se
puede usar prefijos o sufijos para diferenciarlos. Por ejemplo: 'empleado_au' para un disparador 'after
update' sobre la table empleado, 'empleado_bi' para un disparador 'before insert' sobre la table empleado,
5.4 Nombramientos de variables
Para el nombramiento de variables existen varios estandartes internacionales, de los cuales el más
conocido es la notación hungarina ('Hungarian notation'). Usted se puede pegar a uno, o crear el suyo.
Por lo general es buena practica de tener por lo menos dos partes en su nombre de variable: un prefijo
indicador de alcance (variable local, global, parámetro) y el nombre inteligible de la variable.
Por ejemplo: sin prefijo para variables locales, el prefijo 'g_' para variables globales, y el prefijo 'p_' para
parámetros.
Ciertos estandartes también adjuntan el tipo de variable en el nombre de al variable.

Manual de Técnicas de Desarrollo

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Manual de Técnicas de Desarrollo

Uploaded by

Copyright:

Available Formats

SolucionJava.

Manual del alumno

© Copyright Cédric Simon, 2007 Versión 1.0 Reproducción prohibida

© Copyright Cédric Simon, 2007 Versión 1.0 Reproducción prohibida

© Copyright Cédric Simon, 2007 Versión 1.0 Reproducción prohibida

© Copyright Cédric Simon, 2007 Versión 1.0 Reproducción prohibida

© Copyright Cédric Simon, 2007 Versión 1.0 Reproducción prohibida

© Copyright Cédric Simon, 2007 Versión 1.0 Reproducción prohibida

© Copyright Cédric Simon, 2007 Versión 1.0 Reproducción prohibida

© Copyright Cédric Simon, 2007 Versión 1.0 Reproducción prohibida

© Copyright Cédric Simon, 2007 Versión 1.0 Reproducción prohibida

© Copyright Cédric Simon, 2007 Versión 1.0 Reproducción prohibida

© Copyright Cédric Simon, 2007 Versión 1.0 Reproducción prohibida

© Copyright Cédric Simon, 2007 Versión 1.0 Reproducción prohibida

You might also like