tesis de maestrÍa en ciencias...que además de ser mi hermano, siempre has sido mi mejor amigo, mi...

cenidet

Centro Nacional de Investigación y Desarrollo Tecnológico

Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS

Conteo Semiautomático de Líneas de Código en Ambientes de Desarrollo Integrado Mediante una Estrategia de Marcado de Texto en Tiempo de

Codificación

presentada por

Erick Leobardo Iduñate Rosales Ing. en Sistemas Computacionales por el Instituto Tecnológico de Durango

como requisito para la obtención del grado de:

Maestría en Ciencias en Ciencias Computacionales

Director de tesis: Dr. Máximo López Sánchez

Co-Director de tesis:

M.C. José Armando Alfonzo García

Jurado: Dr. Guillermo Rodríguez Ortiz – Presidente Dr. Máximo López Sánchez – Secretario

Dr. Moisés González García – Vocal M.C. Reynaldo Alanís Cantú - Vocal Suplente

Cuernavaca, Morelos, México. 8 de Mayo de 2008

Dedicatorias

A Dios. Porque todas mis obras son para Ti y gracias a Ti.

A ustedes, papás. Porque todos mis logros los debo a los más de treinta años que se han esforzado por darnos a Ricardo y a mí lo mejor, por no privarnos de ninguna oportunidad de superación. Porque siempre han respetado nuestras decisiones aunque implique pasar por alto sus propios anhelos. Porque nos han dado herramientas de la mejor calidad para enfrentar la vida y sus altibajos. Gracias pos su ejemplo, su infinita paciencia y por enseñarnos que la mejor educación está en casa. No puedo hacer menos que dedicarles este trabajo, lo hicieron ustedes. Los admiro, los respeto y los amo.

A ti, Pequeño. Que además de ser mi hermano, siempre has sido mi mejor amigo, mi confidente y el que siempre me cortó el viento, consciente o inconscientemente, porque en el proceso de crecimiento, tú fuiste la referencia para tomar mis propias decisiones. Ha sido duro alejarme de ti después de convivir por tanto tiempo. Cuida y ama a tu esposa, que el matrimonio es para toda la vida.

A mi gran familia. Agradezco infinitamente a la vida, que es Dios, por haberme hecho este regalo. Una familia unida con la que puedo contar, la que me ha dado la confianza de emprender nuevos caminos sin temor, sabiendo que me puedo apoyar en ella en cualquier situación. Esto es para ustedes: papá Memo y mamá Raquel, tía Elsa y tío Gil, tía Irma, tío Fernando y tía Lourdes, tía María Elena, tío René y tía Tommy, tía Paty, Sergio, tío Memo y tía Irma, Pete, tía Susy, tío Tity y Javier, además de todos mis primos que son como mis hermanos.

A mis amigos. A los del Tecno: porque para ser maestro primero hay que ser ingeniero, y ustedes también son parte de esto. A los de Volley: que gracias a este deporte encontré buenos amigos y se amplió mi perspectiva de la vida. Con ustedes aprendí a trabajar en equipo. A los del Cenidet: Compa, fue un placer y un orgullo compartir con usted escuela y vivienda por más de dos años, no andaba tan perdida la señora de la 3. Elvia (¡¡quéeee!!), no veo claro con el apoyo al movimiento, ¿segura que quieres continuar? Bro, Lalo para muchos, la historia continúa, sigamos causando estragos ahora en la capital. Hermana, gracias a su sencillez, simpatía y buena vibra, es capaz de alegrarle el día a cualquiera. Eso, más su constancia y tenacidad son un ejemplo para todos nosotros. Erwin, cuídense y respétense, que mi hermana es un tesoro. Por cierto, ¿fifa? Cindy y Héctor, Chucho, Daniel, Adriana, Lirio, Jazmín, Luz, Silvana, Perla, Zuci, Rubén, Erick, Ricardo, Arturo, Gera. A los Hackers-Cavernicolitas-Aleluyos NTM. Un equipo ganador. A los del Coro. Que domingo a domingo nos reunimos para cantar, espero que nunca olvidemos a quién van dedicadas esas canciones. A los de Cuernavaca. Eunice, Ana, Cecy, Ken y Ana. Que en las buenas y en las malas están presentes brindando su amistad y apoyo.

A la señora Rosy. Que ha sabido ser una verdadera amiga para mí, un ejemplo de voluntad y fortaleza.

A ti, que en un principio fuiste mi amiga buena onda, luego mi mejor amiga y ahora eres mi motivación más grande, mi mejor opción. A ti, que me hiciste recordar quién soy, que sacaste de muy dentro de mí a alguien que yo pensé que ya no existía. A ti, que me mostraste que los pequeños detalles son los que hacen que la vida valga la pena. A ti, que me inspiras a ser cada vez mejor. Esto es también para ti Cielo, mi Mochita. Te amo.

Agradecimientos

Al Consejo Nacional de Ciencia y Tecnología CONACYT por su apoyo económico para permitir llevar a cabo el desarrollo de esta tesis de maestría.

A la Dirección General de Estudios Superiores Tecnológicos DGEST por el apoyo económico que permitió la extensión de tiempo para el trabajo de tesis.

Al Cenidet, así como a todo el personal que ahí labora, por haber creído en mí y darme la oportunidad de formar parte de su equipo.

A mi Director, el Dr. Máximo López Sánchez, por su apoyo y guía incondicionales en esta etapa tan importante en mi carrera profesional. También por enseñarme, junto con el Dr. Veljko Milutinovic y el Dr. Petar Kocovic, que un investigador también puede tener una vida allá afuera.

A mi Co-Director, el M.C. José Armando Alfonzo García, quien siempre estuvo ahí para ayudarme.

A mis revisores: Dr. Moisés González García, Dr. Guillermo Rodríguez Ortiz y M.C. Reynaldo Alanís Cantú, por haber colaborado con su experiencia en la realización de esta tesis.

A mis maestros: Dr. René Santaolaya, M.C. Olivia Fragoso, Dr. Antonio Zárate, Dr. José Ruiz, Dra. Azucena Montes, M.C. Felipe Alaniz, M.C. Mario Guillén, M.C. José Luis Ramírez, Dra. Leticia Sánchez.

A mis otros maestros: mi familia, todos mis compañeros de clases, personal del Cenidet, a todos mis amigos en todas las latitudes -tanto del tecno, como del Cenidet, de Durango, de México, del mundo-, a quienes me alimentaron, me hospedaron, me tendieron la mano, me escucharon, me hablaron. Todos ellos me enseñaron algo y me prepararon para llegar a este punto y para enfrentar lo que viene.

A Edna y a Lalo por ayudarme tanto en esta última fase que, aunque aparentemente sencilla, no hubiera terminado todavía sin su valiosa ayuda.

Resumen

Resumen Dada la necesidad de medir el tamaño de productos de software para conocer el rendimiento de programadores y hacer estimaciones del tamaño de nuevos proyectos, emergieron estándares para el conteo y clasificación de líneas de código, mismos que proponen distintos tipos de líneas para las situaciones en que éstas se producen. En consecuencia, infinidad de herramientas tratan de automatizar el proceso de medición aplicando lo definido por los estándares. Desafortunadamente, no se ha llegado a un estándar que refleje lo que verdaderamente sucede cuando se codifica un proyecto de software. Esta situación se torna evidente al observar que las líneas generadas por los ambientes de programación no son consideradas dentro los estándares actuales de clasificación.

El objetivo de esta tesis fue definir una estrategia de conteo de líneas de código en ambientes de desarrollo integrado, separando las líneas generadas automáticamente de las escritas por el programador. Para esto, se identificaron los tipos de línea que se producen con cada evento que realiza un desarrollador en un ambiente de programación. Además se realizó un análisis de los escenarios que se presentan cuando un programador codifica en un ambiente de desarrollo integrado. Por último, se elaboró una estrategia para clasificar y contar las líneas de código de acuerdo a los eventos ocurridos en la codificación de un proyecto. Esta estrategia involucra la detección de eventos de teclado y llamadas a funciones del ambiente de programación, así como el uso de marcado de texto para la identificación, clasificación y conteo de líneas de código.

Como resultado de la investigación se propusieron dos tipos de línea –“generadas” y “copiadas”- para considerarse en el conteo de líneas de código de los ambientes de desarrollo. Además, se dedujo que las líneas generadas automáticamente pueden ser detectadas si la clasificación de líneas de código se lleva a cabo en la fase de codificación utilizando registros actualizables mediante la detección de eventos de teclado y ratón. Lo que reduce la posibilidad de errores al hacer un conteo final cuando el código se libera.

Conteo semiautomático de líneas de código en ambientes de desarrollo integrado mediante una estrategia de marcado de texto en tiempo de codificación

Contenido

Abstract Due to the need to measure the size of software projects in order to know performance of developers, standards for lines of code counting and classification emerged. They propose different line types for each situation where these are produced. As a consequence, too many tools try to automate the measure process by applying what the standards defined. Unfortunately, a standard that shows what actually happens when a software project is coded has not been reached yet. This situation gets evident when it is seen that the lines of code generated by development environments are not considered in the current classification standards.

The goal of this thesis is to define a lines-of-code counting strategy for integrated development environments (IDE), where the automatically generated lines are separated from those written by the developer. In order to achieve this, lines produced with every event triggered by the developer were identified. Also, it was made an analysis of possible scenarios occurred when a developer codes within an integrated development environment. Finally, a strategy for counting and classifying lines of code was made, according to the events occurred at a project’s code. This strategy involves keyboard events and calls to functions of the development environment, as well as the use of text markups for lines of code identification, classification and count.

As a result of this investigation, two types of line were proposed –“generated” and “copied”- in order to be considered in IDE lines of code counting. Also, it was deduced that automatically generated lines can be detected if the classification of lines of code takes place in coding phase, and using updatable registers by handling keyboard and mouse events, which reduces error possibility in the final counting when code is released.

Contenido

i

Contenido Pág. Resumen ................................................................................................................................ 1 Contenido ............................................................................................................................... i Índice de Tablas y Figuras .................................................................................................. iii Introducción .......................................................................................................................... 1 Capítulo 1. Generalidades .................................................................................................... 3

1.1 Antecedentes del proyecto ............................................................................................ 4 1.2 Trabajos relacionados ................................................................................................... 4

1.2.1 Estandarización de conteo de líneas de código ..................................................... 5 1.2.2 Algunos métodos usados para conteo y clasificación automática de líneas .......... 6 1.2.3 Herramientas .......................................................................................................... 7

1.3 Descripción del problema .......................................................................................... 12 1.4 Objetivo ...................................................................................................................... 13 1.5 Hipótesis ..................................................................................................................... 13 1.6 Justificación ................................................................................................................ 13

1.6.1 Beneficios ............................................................................................................ 14 1.7 Alcances y limitaciones .............................................................................................. 14

1.7.1 Alcances .............................................................................................................. 14 1.7.2 Limitaciones ........................................................................................................ 15

1.8 Metodología de solución ............................................................................................ 15 Capítulo 2. Marco Teórico ................................................................................................. 17

2.1 Proceso de software .................................................................................................... 18 2.1.1 Proceso de Software Personal (PSP) ................................................................... 18 2.1.1.1 Estructura del PSP ............................................................................................ 19

2.2 Tamaño del Software .................................................................................................. 20 2.2.1 Métricas de software ............................................................................................ 20 2.2.2 Métricas orientadas al tamaño ............................................................................. 21 2.2.1 Clasificación de líneas de código ........................................................................ 22

2.3 Marcado de Texto ....................................................................................................... 24 2.3.1 XML [WES02] .................................................................................................... 24

2.4 Interfaz de Programa de Aplicación (API) ................................................................. 25 2.5 Generación de Código ................................................................................................ 25 2.6 Eventos ....................................................................................................................... 26 2.7 Observaciones ............................................................................................................. 26

Capítulo 3. Tipos de LOC producidas en un IDE ........................................................... 27 3.1 Vista general de Casos de Uso de codificación .......................................................... 28 3.2 Usos de generación automática de código (U1) ......................................................... 28 3.3 Usos de copiar-cortar/pegar (U2) ............................................................................... 32 3.4 Usos de modificaciones (U3) ..................................................................................... 40 3.5 Usos de borrado (U4) ................................................................................................. 43 3.6 Uso de agregación de líneas (U5) ............................................................................... 44 3.7 Resumen ..................................................................................................................... 44


ii

Pág. Capítulo 4. Escenarios de Codificación ............................................................................ 47

4.1 Acciones de codificación en un IDE .......................................................................... 48 4.1.1 Teclas que influyen en un IDE ............................................................................ 48 4.1.2 Métodos del IDE .................................................................................................. 71

4.2 Conclusión .................................................................................................................. 90 Capítulo 5. Estrategia de Conteo ...................................................................................... 91

5.1 Estrategias descartadas ............................................................................................... 92 5.1.1 Estrategia inicial: Marcado de texto .................................................................... 93 5.1.2 Estrategia alterna 1: Identificación de líneas generadas por diferenciación ........ 93 5.1.3 Estrategia alterna 2: Manejo de versiones internas ............................................. 94

5.2 Estrategia de Conteo propuesta .................................................................................. 96 5.2.1 Idea inicial ........................................................................................................... 96 5.2.2 Estrategia de Conteo de LOC en ambientes de desarrollo integrado (Reglas) .... 96 5.2.3 Riesgos .............................................................................................................. 100 5.2.3 Elementos cubiertos ........................................................................................... 101 5.2.4 Observaciones .................................................................................................... 101

5.3 Casos de Uso y escenarios de la herramienta ........................................................... 101 5.3.1 Representación de escenarios ............................................................................ 102 5.3.2 Diagramas de Casos de Uso, plantillas de escenarios y diagramas de actividad .................................................................................................................................... 104

5.4 Conclusiones ............................................................................................................. 139 Conclusiones ...................................................................................................................... 141 Apéndice A. Análisis de IDEs .......................................................................................... 143 Apéndice B. Generación de Código................................................................................. 149 Apéndice C. Detección de Eventos en Java .................................................................... 155 Apéndice D. Estrategias Descartadas ............................................................................. 161 Glosario de Términos ....................................................................................................... 169 Referencias ........................................................................................................................ 173

Índice de Tablas y Figuras

iii

Índice de Tablas y Figuras Pág.

Figuras Capítulo 2. Marco Teórico Figura 2. 1 Flujo del proceso PSP .................................................................................................................... 20 Figura 2. 2 Plantilla de definición para conteo de instrucciones de código. .................................................... 23 Capítulo 3. Tipos de LOC producidas en un IDE Figura 3. 1 Casos de Uso de codificación en un ambiente de desarrollo integrado .......................................... 28 Figura 3. 2 Inicio de un proyecto en un IDE. a) Asistente de configuración de nuevo proyecto, b) Lista de archivos generados automáticamente, c) Parte del código generado automáticamente .................................... 29 Figura 3. 3 Agregación de componentes a interfaz de usuario. Se observa la forma gráfica y un fragmento del código asociado. ............................................................................................................................................... 30 Figura 3. 4 Utilización de asistentes (wizards) para crear clases y sus métodos, en la parte inferior se observa el código generado después de usar los asistentes. ........................................................................................... 31 Figura 3. 5 Ejemplo de generación de código a partir de modelado. ................................................................ 32 Figura 3. 6 Ejemplo del uso de Cortar para borrar. .......................................................................................... 33 Figura 3. 7 Ejemplo de uso de Cortar para mover. ........................................................................................... 34 Figura 3. 8 Ejemplo de uso de Copiar y Pegar para duplicar. .......................................................................... 35 Figura 3. 9 Ejemplo de uso de Copiar y Pegar para crear plantillas. ................................................................ 36 Figura 3. 10 Ejemplo de uso de Copiar y Pegar para crear plantillas. ............................................................. 37 Figura 3. 11 Código copiado de una fuerte externa (Internet) y pegado en el proyecto actual ......................... 38 Figura 3. 12 Código copiado de un proyecto hacia el mismo proyecto. ........................................................... 39 Figura 3. 13 Código base al que se le modificaron líneas. ............................................................................... 40 Figura 3. 14 Código pegado y posteriormente modificado............................................................................... 41 Figura 3. 15 Código modificado después de ser agregado o modificado anteriormente. ................................. 42 Figura 3. 16 Código modificado después de ser generado automáticamente. .................................................. 43 Capítulo 4. Escenarios de Codificación Figura 4. 1 Uso de salto de línea (tecla Enter). ................................................................................................ 49 Figura 4. 2 Uso de teclas con carácter o dígito. ................................................................................................ 53 Figura 4. 3 Suprimir y Retroceso. ..................................................................................................................... 61 Figura 4. 4 Punto y coma .................................................................................................................................. 69 Figura 4. 5 Deshacer y Rehacer acciones. ........................................................................................................ 72 Figura 4. 6 Asistentes y paneles. ...................................................................................................................... 74 Figura 4. 7 Formularios. ................................................................................................................................... 79 Figura 4. 8 Acciones con el ratón. .................................................................................................................... 84 Figura 4. 9 Opciones de archivo. ...................................................................................................................... 87


iv

Pág. Capítulo 5. Estrategia de Conteo Figura 5. 1 Casos de Uso de Contador de Líneas. .......................................................................................... 105 Figura 5. 4 Diagrama de Actividad para CU3 Editar código. ......................................................................... 109 Figura 5. 5 Diagrama de actividad para CU4 Solicitar conteo de líneas ....................................................... 111 Figura 5. 6 Diagrama de actividad para CU5 Cambiar tipos de línea. .......................................................... 112 Figura 5. 7 Diagrama de actividad para CU6 Ver reporte. ............................................................................. 113 Figura 5. 8 Casos de uso de codificación para herramienta de conteo ........................................................... 114 Figura 5. 9 Diagrama de actividad para CU3.1.1 Presionar Enter ................................................................. 118 Figura 5. 10 Diagrama de actividad para CU3.1.2 Presionar caracteres ........................................................ 120 Figura 5. 11 Diagrama de actividad para CU3.1.3 Presionar Suprimir o Retroceso ...................................... 122 Figura 5. 12 Diagrama de actividad de CU3.2.1 Llamar a función Deshacer o Rehacer ............................... 125 Figura 5. 13 Diagrama de actividad de CU3.2.2 Generar código. .................................................................. 127 Figura 5. 14 Diagrama de actividad de CU3.2.3 Copiar código. .................................................................... 128 Figura 5. 15 Diagrama de actividad de CU3.2.4 Cortar código ..................................................................... 129 Figura 5. 16 Diagrama de actividad de CU3.2.5 Pegar código. ...................................................................... 131 Figura 5. 17 Diagrama de actividad de CU3.2.6 Crear archivo/proyecto. ...................................................... 132 Figura 5. 18 Diagrama de actividad de CU3.2.7 Guardar archivo/proyecto................................................... 133 Figura 5. 19 Diagrama de actividad de CU3.2.8 Guardar archivo/proyecto como… ..................................... 135 Figura 5. 20 Diagrama de actividad para CU3.2.9 Eliminar archivo/proyecto. .............................................. 136 Figura 5. 21 Diagrama de actividad para CU3.2.10 Renombrar archivo/proyecto ......................................... 137 Figura 5. 22 Diagrama de actividad para CU3.2.11 Salir sin guardar. ........................................................... 139 Apéndices Figura A. 1Arquitectura de Eclipse ................................................................................................................ 144 Figura B. 1 Generación de Archivos de salida mediante code mungers ......................................................... 152 Figura B. 2 Proceso de generación de código mediante expansor de código en línea .................................... 152 Figura B. 3 Flujo del proceso de generación de código con generadores de clases parciales ........................ 153 Figura C. 1 Asociación de la secuencia de teclas Ctrl+G con el comando Save. ........................................... 158 Figura D. 1 Diagrama de flujo de un sistema de manejo de versiones internas. ............................................ 165 Figura D. 2 Ejemplo del empleo de versiones preliminares ........................................................................... 166

Tablas Capítulo 1. Generalidades Tabla 1. 1 Comparación de trabajos relacionados con la tesis. ........................................................................ 12 Capítulo 3. Tipos de LOC producidas en un IDE Tabla 3. 1 Tipificación de líneas antes y después de eventos de codificación. ................................................. 45

Índice de Tablas y Figuras

v

Capítulo 4. Escenarios de Codificación Pág. C 1 Presionar Enter .......................................................................................................................................... 50 C1. 1 Finalizar línea programada .................................................................................................................. 50 C1. 2 Agregar líneas en blanco ..................................................................................................................... 51 C1. 3 Dividir línea ........................................................................................................................................ 51 C1. 4 Borrar código ...................................................................................................................................... 52 C 2 Seleccionar código ..................................................................................................................................... 52 C 3 Oprimir cualquier carácter o dígito ............................................................................................................ 55 C3. 1 Crear nueva línea ................................................................................................................................. 55 C3. 2 Extender una línea existente ................................................................................................................ 56 C3.2. 1 Agregar código al inicio de una línea ............................................................................................ 56 C3.2. 2 Agregar código en medio de una línea ........................................................................................... 57 C3.2. 3 Agregar código al final de una línea .............................................................................................. 57 C3. 3 Remplazar código ................................................................................................................................ 58 C3.3. 1 Remplazar código seleccionado ..................................................................................................... 58 C3.3.1. 1 Remplazar una línea existente ................................................................................................. 59 C3.3.1. 2 Remplazar líneas existentes y fragmento de línea ................................................................... 59 C3.3. 2 Remplazar caracteres ..................................................................................................................... 60 C 4 Accionar función ‘Insert’ ........................................................................................................................... 60 C 5 Oprimir teclas Suprimir o Retroceso ......................................................................................................... 64 C5. 1 Borrar línea completa .......................................................................................................................... 64 C5. 2 Borrar varias líneas.............................................................................................................................. 65 C5. 3 Borrar fragmento de línea ................................................................................................................... 65 C5. 4 Borrar una o varias líneas y un fragmento ........................................................................................... 66 C5. 5 Borrar un carácter ................................................................................................................................ 66 C5.5. 1 Borrar único carácter existente ...................................................................................................... 67 C5.5. 2 Borrar uno y dejar más ................................................................................................................... 67 C5. 6 Unir dos líneas ..................................................................................................................................... 68 C5.6. 1 Unión con Suprimir........................................................................................................................ 68 C5.6. 2 Unión con Retroceso ...................................................................................................................... 69 C 6 Oprimir punto y coma ................................................................................................................................ 70 C6. 1 Finalizar instrucción ............................................................................................................................ 70 C6. 2 Puntuar una cadena de texto ................................................................................................................ 71 C 7 Llamar a función de Deshacer ................................................................................................................... 73 C 8 Llamar a función de Rehacer ..................................................................................................................... 73 C 9 Generar clases ............................................................................................................................................ 75 C 10 Generar métodos ...................................................................................................................................... 75 C10. 1 Generar métodos con asistente .......................................................................................................... 76 C10. 2 Generar métodos get y set ................................................................................................................. 76 C 11 Generar atributos...................................................................................................................................... 77 C 12 Borrar clase .............................................................................................................................................. 77 C 13 Borrar método .......................................................................................................................................... 78 C 14 Agregar componenetes de formulario ...................................................................................................... 80 C 15 Modificar componente en formulario ...................................................................................................... 80 C15. 1 Modificar componente en Propiedades ............................................................................................. 81 C15. 2 Modificar componente desde código ................................................................................................. 81 C 16 Borrar componente .................................................................................................................................. 82 C16. 1 Borrar del formulario o panel ............................................................................................................ 82


vi

Pág. C16. 2 Borrar desde código .......................................................................................................................... 83 C 17 Copiar selección ....................................................................................................................................... 84 C17. 1 Pegar código ...................................................................................................................................... 85 C 18 Cortar código ........................................................................................................................................... 85 C 19 Arrastrar código ....................................................................................................................................... 86 C 20 Nuevo proyecto/archivo ........................................................................................................................... 88 C 21 Guardar proyecto/archivo ........................................................................................................................ 88 C 22 Guardar proyecto/archivo como…........................................................................................................... 89 C 23 Eliminar ................................................................................................................................................... 89 Capítulo 5. Estrategia de Conteo Tabla 5. 1 Comparación de estrategias descartadas de acuerdo a los elementos básicos cubiertos. ................. 95 Tabla 5. 2 Tipificación de líneas resultantes por Evento .................................................................................. 99 CU 1 Comenzar proyecto ............................................................................................................................... 106 CU 2 Finalizar proyecto ................................................................................................................................. 108 CU 3 Editar código ......................................................................................................................................... 109 CU 4 Solicitar conteo de líneas ...................................................................................................................... 110 CU 5 Cambiar tipos de línea .......................................................................................................................... 111 CU 6 Ver reporte ............................................................................................................................................ 112 CU3. 1 Presionar teclas .................................................................................................................................. 115 CU3.1. 1 Presionar Enter ............................................................................................................................. 116 CU3.1. 2 Presionar caracteres...................................................................................................................... 119 CU3.1. 3 Presionar Suprimir y Retroceso ................................................................................................... 120 CU3. 2 Usar métodos del IDE ........................................................................................................................ 123 CU3.2. 1 Llamar a función Deshacer o Rehacer ......................................................................................... 123 CU3.2. 2 Generar código ............................................................................................................................ 126 CU3.2. 3 Copiar código .............................................................................................................................. 127 CU3.2. 4 Cortar código ............................................................................................................................... 128 CU3.2. 5 Pegar código ................................................................................................................................ 129 CU3.2. 6 Crear archivo/proyecto ................................................................................................................ 131 CU3.2. 7 Guardar archivo/proyecto ............................................................................................................ 132 CU3.2. 8 Guardar archivo/proyecto como… .............................................................................................. 134 CU3.2. 9 Eliminar archivo/proyecto ........................................................................................................... 135 CU3.2. 10 Renombrar archivo/proyecto ..................................................................................................... 137 CU3.2. 11 Salir sin guardar ......................................................................................................................... 138

Introducción

1

Introducción La elaboración de productos de software crece desmesuradamente con el paso del tiempo por diversas razones, como son la facilidad con la que se puede disponer de recursos para desarrollarlo y la gran cantidad de problemas que resuelve en diferentes dominios de aplicación. Sin embargo, no existe una cultura para desarrollar software de calidad ya que cada programador tiende a utilizar sus propios métodos y esto dificulta la comprensión del producto por parte de otros programadores y, por tanto, es más difícil su mantenimiento así como la planeación de futuros proyectos.

Por estas razones, la Ingeniería de Software se propone darle un sentido formal al desarrollo de software mediante el uso de los procesos de software, la cual tiene como objetivo llevar de manera ordenada y bien estructurada el desarrollo de un proyecto, de tal forma que se pueda asegurar la calidad del mismo y facilitar su comprensión para el mantenimiento.

Una de las formas más comunes para conocer el rendimiento de los programadores dentro de los procesos de desarrollo de software, así como para realizar estimaciones del tamaño de un producto a desarrollar, se da a partir del conteo de líneas de código de productos anteriores, ya que estos reflejan el esfuerzo realizado por los desarrolladores en escenarios similares.

Es importante mencionar que llevar el conteo de líneas implica considerar líneas

nuevas, modificadas, borradas, reutilizadas, entre otras. Desafortunadamente, es común que los desarrolladores de software no realicen el conteo y clasificación de líneas de código de manera correcta, puesto que esta práctica supone un consumo importante de tiempo si se lleva a cabo de manera manual y, aunque ya existen varios trabajos que indican cómo contar las líneas de código, son muy pocas las herramientas automáticas que ayudan a contar líneas de código lógicas durante el desarrollo del software y aparentemente nulas las que consideran todas los tipos de línea involucrados para una medición presumiblemente más exacta (ver tabla 1.1 en el apartado “Trabajos Relacionados”, Capítulo 1).

Esta situación no era tan evidente hace más de una década, pero con la aparición de entornos de desarrollo que facilitan la tarea de los programadores al permitir la generación automática de código a partir de diseño, ha crecido el margen de error al pretender hacer la medición de un producto de software a partir de la cantidad de sus líneas de código, puesto que las técnicas existentes no consideran que gran parte de las líneas que se cuentan fueron generadas automáticamente por los ambientes de desarrollo y no que no fueron escritas por el propio desarrollador, lo que haría parecer que el producto requirió de más esfuerzo del que realmente se empleó.

Por lo expuesto anteriormente, éste trabajo proporciona una alternativa de solución a esta problemática.


2

Organización del documento Este documento se encuentra organizado de la siguiente forma:

Capítulo 1: Se presentan los antecedentes a esta investigación, seguidos de un análisis y comparación de los trabajos relacionados al aquí presentado. También se describen los problemas a atacar, el objetivo a lograr, la hipótesis planteada, justificación del estudio y sus alcances y limitaciones.

Capítulo 2. Marco Teórico: Se definen los conceptos más importantes que se emplean a lo largo de este documento con el objetivo de asegurar la comprensión del mismo.

Capítulo 3. Tipos de LOC producidas en un IDE: Estudio de las formas en que un desarrollador produce código en un ambiente de programación integrado. Aquí se identifican los tipos de líneas de código que se originan con cada evento que se realiza en el ambiente de programación.

Capítulo 4. Escenarios de Codificación: Análisis de los eventos que se llevan a cabo dentro de un ambiente de desarrollo que pueden producir cambios en los tipos de líneas de código contenidos en un proyecto de software.

Capítulo 5. Estrategia de Conteo: Definición de la Estrategia de Conteo a la que se llegó al analizar los escenarios de Codificación. También se describen los métodos que se aplican a la Estrategia en cada evento y que produce un cambio en el tipo de una línea de código.

Conclusiones: Interpretación de los resultados obtenidos a lo largo de la investigación. Se presentan trabajos a futuro.

Apéndice A. Análisis de IDEs: Descripción de las APIs de extensión de tres ambientes de desarrollo integrado de lenguaje Java.

Apéndice B. Generación de Código: Descripción de las formas de generación automática de código tradicionales y algunas propuestas para la detección de este evento.

Apéndice C. Detección de Eventos en Java: Recursos que aportan algunas librerías de lenguaje Java para la detección de eventos de teclado y ratón.

Apéndice D. Estrategias Descartadas: Estrategias de conteo propuestas en diferentes puntos de la investigación que fueron desechadas por presentar problemas evidentes.

Los tipos de letra varían deliberadamente en el contenido del documento. El tipo de letra base es Times New Roman- 12, el tipo de letra para las ilustraciones y tablas es Times New Roman – 10, el tipo de letra para porciones de código es Courier New-10.

Capítulo 1 Generalidades

3


Se presentan los antecedentes a esta investigación, seguidos de un análisis y comparación de los trabajos relacionados al aquí presentado. También se describen los problemas a atacar, el objetivo perseguido, la hipótesis planteada, la justificación del estudio y sus alcances y limitaciones. Por último se presenta la metodología de solución.


4

1.1 Antecedentes del proyecto En el año 2002 un grupo de profesores del área de Ingeniería de Software del Cenidet, recibió junto con otros miembros de la comunidad científica e industriales del software del estado de Morelos, el curso del Proceso Personal de Software (PSP) ofrecido por la compañía desarrolladora de software QuarkSoft de México.1 A partir de entonces, los programas de estudio que se imparten en la especialidad de Ingeniería de Software de este Centro, incluyen la enseñanza del proceso como parte de la formación que deben tener los egresados de esta área de estudio.

Un trabajo, consecuencia de la impartición del curso de PSP en este centro de investigación, es la “Bitácora de registro de tiempos para la planificación de actividades de ingeniería”, también conocido como “PSP Cenidet”, herramienta que pretende facilitar el registro de actividades y la realización de informes que los desarrolladores de software necesitan para planificar y estimar costos de los productos de software. Este instrumento, si bien no involucra el conteo de líneas dentro de sus alcances, sí está orientado a la automatización de uno de los requerimientos a cubrir que marca el PSP, específicamente el registro de tiempos de actividades a lo largo del desarrollo de un proyecto. Es por ello que el “PSP Cenidet” se incluye como único antecedente al presente trabajo de tesis.

La figura 1.1 (en la siguiente página) muestra una captura de pantalla de la

herramienta “PSP Cenidet” en funcionamiento.

1.2 Trabajos relacionados El estudio de los trabajos relacionados a esta tesis se enfoca en los estándares que se tienen con respecto a la clasificación de las líneas de código, las técnicas que existen para lograr la automatización de la clasificación y el conteo de estas líneas y las herramientas que las implementan.

La información que aquí se reúne muestra la situación actual de las estrategias de conteo y clasificación de líneas de código, y se compara con la estrategia que se presenta en este documento como resultado de la investigación.

1 Para mayor información acerca de esta empresa visitar la página de la empresa http://www.quarksoft.net


5

Figura 1.1 PSP Cenidet. Herramienta que ayuda al desarrollador a llevar un registro del tiempo de sus

actividades dentro de un proceso de software.

1.2.1 Estandarización de conteo de líneas de código Robert E. Park en [PAR92] desarrolló un marco para contar sentencias de código que presenta “guías para definir, registrar y reportar dos medidas de tamaño de software frecuentemente usadas –líneas de código físicas y sentencias de código lógicas”. Lo que dio como resultado una plantilla en la que se pueden especificar los atributos con los que cuenta el código fuente de un determinado proyecto de software y cómo éstos deben considerarse. La plantilla tiene diferentes tipos de clasificación como: “tipo de sentencias que contiene, cómo se produjo el código, origen del código, uso del código, tipo de entrega, funcionalidad, lenguaje utilizado, clarificaciones, clarificaciones del lenguaje, replicaciones y estatus de desarrollo”.

Más adelante, Watts Humphrey en [HUM95] identifica distintos tipos de líneas de código fuente, que son: “base, borradas, reutilizadas, añadidas, modificadas, totales, nuevas y cambiadas y nuevas reutilizadas”.

Estos dos enfoques se explican con mayor detalle en el Capítulo 2, Marco Teórico,

y conforman la base teórica de la información que se presenta en esta investigación.


6

1.2.2 Algunos métodos usados para conteo y clasificación automática de líneas

Así como existen trabajos que intentan estandarizar las métricas de tamaño de software -como el conteo de líneas de código- hay otros que pretenden automatizar esta tarea. Algunos de estos trabajos, como el contador de líneas incluido en la herramienta Process Dashboard [RAI05], se basan en algoritmos que no fueron originalmente concebidos pensando en conteo de líneas de código, pero fueron adaptados para este fin. Otros, como la heurística para detección de código generado de Wheeler [WHE02], sí se hicieron exclusivamente para clasificar las LOC. Todos los trabajos encontrados recorren el código (texto plano) en busca de información que los lleve a tomar decisiones acerca de la clasificación de cada línea y/o sentencia encontrada.

1.2.2.1 El empleo de diff Una forma sencilla de hacer conteo es enfocarse a las líneas físicas, esto es, contar cada renglón como una línea, ignorando las líneas en blanco y los comentarios. Por lo que no es difícil fabricar contadores automáticos con estas características. La complejidad crece cuando se detectan sentencias, dentro del código, que tienen la finalidad de conocer el número de instrucciones contenidas en el mismo, entonces ya se debe recurrir a la gramática de cada lenguaje e implementarla en el algoritmo. Con esto se logra identificar cada sentencia y, si se desea, clasificar de acuerdo a su tipo como “ejecutable”, “declaración”, “directivas del compilador”, etc.

Para comparar entre distintas versiones de un mismo producto, es posible utilizar el

algoritmo desarrollado por J.W. Hunt y D. McIlroy para detectar diferencias entre archivos. Con el nombre de diff, este algoritmo se usa “para encontrar las líneas que no cambian entre archivos.”[HUNT76] Diferencias como líneas agregadas, borradas y cambiadas se localizan utilizando esta técnica.

La aplicación del algoritmo proporcionado por [HUNT76] cubre en buena parte el

objetivo de identificar los tipos de línea definidos anteriormente; sin embargo, se hace evidente que, aun combinando esta técnica con el uso de las gramáticas de lenguajes, todavía no es capaz de identificar las líneas generadas y de re-uso, principalmente.

1.2.2.2 Código duplicado Existen algoritmos que se ocupan de encontrar secciones de texto idénticas. Christian Charras y Thierry Lecroq describen en su libro “Handbook of Exact String-Matching Algorithms” diversos algoritmos de búsqueda de cadenas exactas. [CHA04].

Basándose en uno de estos algoritmos, específicamente el propuesto por Karp y Rabin, Michael J. Wise desarrolla en 1993 el Greedy String Tiling (GST) “Embaldosado de Cadena Codicioso” [WIS93], con el que comparan pares de cadenas y se determina el grado de similitud entre ambas. GST “está basado en una comparación uno-a-uno y es capaz de


7

tratar con la transposición de sub-cadenas”. La intención al desarrollar este método fue la detección de posible plagio en programas de computadora y otros textos (también se pensó en comparaciones de ADN -Ácido Desoxirribonucleico- y secuencias de aminoácidos).

Actualmente la utilidad de la detección de código duplicado se observa desde la

perspectiva de que si existe código duplicado en un programa, sus errores están duplicados también, por lo que es importante localizarlo y revisarlo. Por esta razón, los creadores de CPD (Copy/Paste Detector) [PMD06], tomaron el algoritmo de Karp-Rabin [CHA04] como el más indicado para implementarse como detector de código duplicado en un mismo programa.

Para el caso del conteo de líneas, la detección de código duplicado en un mismo

proyecto podría utilizarse dentro de las categorías ya conocidas de líneas de código, o incluso proponerse una diferente.

1.2.2.3 Encontrando líneas generadas automáticamente Existen herramientas para producir código automáticamente, unas a partir de modelos de software, otras dedicadas al desarrollo de aplicaciones (como los ambientes de desarrollo integrado) y algunas más que sirven como traductoras entre lenguajes de programación.

Las líneas de código generadas automáticamente por estas utilidades representan un esfuerzo distinto al que se hace cuando se codifica manualmente. Motivado por esto, David Wheeler, con la intención de medir el tamaño de distribuciones de Linux y basándose en la guía de conteo de código de [PAR92], decide excluir del conteo los archivos que, según Wheeler, fueron generados automáticamente. Para esto, se usó una heurística bastante sencilla en [WHE04]: en cada archivo se buscan dentro de sus primeras quince líneas una cadena dentro de un comentario que indique que el archivo fue generado automáticamente (p. ej. “generated automatically”, “automatically generated”, “do not edit”) [WHE02]. Algunas herramientas generadoras de código indican así la procedencia de los archivos que producen, sin embargo, no todas lo hacen, situación que provoca errores en el método de Wheeler.

Estos son los trabajos encontrados referentes a los intereses de esta tesis. Ahora se presenta un resumen de las herramientas que se relacionan con la presente investigación.

1.2.3 Herramientas Existe una enorme cantidad de herramientas que tienen por intención realizar mediciones de tamaño de proyectos de software, algunas incluyen otro tipo de métricas conjuntamente. En este apartado se presentan herramientas que, a criterio propio, se consideraron como las más estrechamente relacionadas con el trabajo propuesto. Cada una de las definiciones se compone de:


8

- El nombre de la herramienta. - Una pequeña descripción. - Tipo de líneas identificadas. La clasificación de las líneas que detecta, ya sean las

especificadas en libro de Humphrey [HUM95] o que se adapten a otras métricas, incluso propias de la herramienta.

- Estrategia. Cómo se analiza el código para detectar los tipos de línea. - Ubicación. Se especifica dónde hace su trabajo la herramienta, es decir, si trabaja

desde una consola (línea de comandos), en su propio entorno, como complemento de un ambiente de desarrollo integrado o algún otro sitio.

- Tipos de Reporte Generados: En qué formatos presenta los reportes que arroja.

A continuación se describen algunas herramientas: 1. Process Dashboard[RAI05].

Módulo que incorpora plantillas, scripts y otros materiales del libro “A Discipline for Software Engineering” de Watts Humphrey [HUM95]. Incluye una clase hecha en lenguaje java que se utiliza como contador de líneas.

• Tipo de líneas identificadas: Distingue líneas base, añadidas, modificadas y borradas. Ignora comentarios y líneas en blanco. No identifica líneas reutilizadas ni generadas por IDE; los bloques de código movidos se catalogan como líneas borradas y agregadas.

• Estrategia. Recorre y compara dos versiones de un programa, es decir, dos archivos con código fuente, asumiendo que cada línea física debe contarse, a excepción de las ya mencionadas.

• Ubicación: Módulo independiente del entorno de desarrollo de los programas analizados.

• Tipos de Reporte Generados: El Process Dashboard permite exportar sus reportes a formatos HTML y CSV, aunque el contador de esta herramienta sólo genera un reporte en formato HTML.

2. Resource Standard Metrics.[MSQ06]

Herramienta para análisis de métricas y calidad de código fuente para ANSI C++, C# y Java. Desarrollada por M Squared Technologies.

• Tipo de líneas identificadas: Identifica líneas lógicas (aquí las consideran como separaciones con punto y coma) y físicas así como agregadas, borradas, modificadas y comentarios. Además, clasifica líneas “efectivas (aquéllas que no contienen una llave de apertura sola, paréntesis o llave de cierre con punto y coma.”[MSQ06]. Aunque parte de una base de líneas de código al diferenciar entre versiones, no presenta una cifra de líneas base como tal. No identifica líneas generadas por un IDE.


9

• Estrategia. Recorre uno o varios archivos manualmente especificados por el usuario y analiza su contenido. También puede comparar dos versiones de un programa, es decir, dos archivos con código fuente y mostrar sus diferencias.

• Ubicación: Puede ser utilizada de distintas formas: 1. Módulo independiente del entorno de desarrollo de los programas

analizados. 2. Integrado en los ambientes de desarrollo Eclipse, JBuilder y

Visual Studio (6 y .Net). 3. Desde la línea de comandos, especifica la ubicación de los

archivos y parámetros para analizar y generar reportes. • Tipos de Reporte Generados: Permite exportar sus reportes a formatos

HTML, CSV y texto. 3. CodeStriker [SIT05]. Sistema basado en Web para análisis conjunto de código fuente. Permite a varios usuarios hacer una revisión del código de aplicaciones desde diversas ubicaciones mediante el intercambio de mensajes vía Internet, no precisamente en tiempo real, sino como un foro de discusión. Incluye conteo de LOC.

• Tipo de líneas identificadas: Distingue líneas de código añadidas, borradas y modificadas, implícitamente reconoce líneas base al no haber cambio en ellas, aunque no las incluye en el reporte. Ignora líneas en blanco y comentarios. No identifica líneas reutilizadas ni generadas por IDE.

• Estrategia. Recorre uno o varios archivos manualmente especificados por el usuario y analiza su contenido. También puede comparar dos versiones de un programa, es decir, dos archivos con código fuente y mostrar sus diferencias.

• Ubicación: Su ejecución se lleva a cabo en red, utilizando páginas dinámicas con tecnología cliente/servidor. Lo que habilita el intercambio de mensajes entre usuarios vía Internet o Intranet.

• Tipos de Reporte Generados: Permite exportar sus reportes a formato HTML.

4. SourceMonitor [CAM06]. Desarrollado por Campwood Software. Hace mediciones del tamaño y de calidad de software tanto para archivos únicos como para proyectos hechos con Java, C, C++, C#, Delphi y Visual Basic.

• Tipo de líneas identificadas: Su conteo de líneas final está expresado en líneas físicas. Utiliza métricas de calidad, por lo que se enfoca al reconocimiento de líneas ejecutables y comentarios, ignora líneas en blanco, cuenta instrucciones que llaman a métodos, número total de instrucciones


10

(con base en el delimitador de cada lenguaje). No identifica líneas reutilizadas ni generadas por IDE.

• Estrategia. Recorre los archivos contenidos en un directorio y, si se especifica, sus subdirectorios y analiza su contenido. También compara dos o más versiones de un programa, es decir, dos archivos con código fuente y mostrar sus diferencias. Lleva un registro de cada punto de revisión del proyecto y sus resultados. Cuando la herramienta está empotrada en un entorno de desarrollo, este chequeo es realizado automáticamente al guardar el proyecto.

• Ubicación: Utilizable de distintas formas: 1. Módulo independiente del entorno de desarrollo de los programas

analizados. 2. Integrado en el ambiente de desarrollo Visual Studio (6 y .Net).

• Tipos de Reporte Generados: Permite exportar sus reportes a formato XML.

5. SLOCCount [WHE04].

Es un conjunto de programas para contar líneas de código físicas en sistemas de software grandes. Desarrollada por David A. Wheeler, originalmente para contar las líneas en una distribución Linux, aunque puede ser usada para contar las LOC de muchos tipos de sistemas de software. Además de contar líneas, hace estimaciones de tiempo y esfuerzo basadas en el modelo COCOMO, así como estimaciones de costo del software analizado. Es capaz de identificar archivos con código escrito en veintinueve lenguajes.

• Tipo de líneas identificadas: Se enfoca en el conteo de líneas físicas, ignorando líneas en blanco y comentarios. Al no incluir comparación entre versiones es incapaz de detectar líneas base, modificadas, reutilizadas o borradas. No incluye líneas lógicas. Por otro lado, intenta ignorar los archivos generados automáticamente por editores.

• Estrategia. Recorre los archivos contenidos en un directorio (incluso en una distribución de Linux completa) y con base en su extensión y algunas heurísticas identifica y clasifica el tipo de lenguaje que contiene cada archivo.

El autor comenta en la guía de usuario del producto que la forma en la que intenta detectar si un archivo fue generado automáticamente es buscando en sus primeras 15 líneas físicas alguna cadena con el texto “generated automatically”, “automatically generated”, “this is a generated file”, “generated with (alguna) utility” o “do not edit”. En dicha guía se reconoce que este método puede tener fallas.

• Ubicación: Se ejecuta desde la línea de comandos en Linux o un emulador de línea de comandos de Linux en Windows.

• Tipos de Reporte Generados: Permite exportar sus reportes a formato texto, HTML.


11

6. Existe una cantidad considerable de herramientas dedicadas al conteo de líneas de

código en la página de recursos libres SourceForge.Net. [SFG06]. El común denominador es que cuentan líneas físicas, haciendo distinción entre código, líneas en blanco y comentarios para los lenguajes que manejan. No toman en cuenta líneas generadas ni lógicas y en su mayoría sólo recorren los archivos, sin comparar entre versiones.

En la tabla siguiente (Tabla 1.1) se muestra una comparación de las herramientas

estudiadas con el presente trabajo. En la primera columna se ubica el nombre de la herramienta; las siguientes nueve, forman un conjunto de tipos de líneas identificadas por dicha herramienta, en donde se puede ver si consideran o no esa clasificación (marcando con una “X” en cada campo); viene después la estrategia utilizada para la identificación de esas líneas; luego, la ubicación desde la que la herramienta hace su trabajo y por último el tipo de reporte generado. Además, se sombrearon los campos en los que las características analizadas coinciden con el trabajo presentado.

La clasificación ‘Otra’ se refiere a cualquier tipo línea que no esté considerada dentro de los que fueron mencionados hasta el momento, siendo propias de la herramienta en cuestión, o referentes a otro tipo de métrica diferente al tamaño. Para el caso de esta tesis, se representa a las líneas ‘copiadas’ como de tipo ‘Otra’ en la tabla.

De las herramientas que se analizaron sólo SLOCCount hace un intento por

identificar las líneas que fueron generadas por ambientes de desarrollo, aunque, como ya se mencionó en la descripción de ésta, es propensa a fallar debido a la estrategia que sigue. Por otro lado, no se detectan trabajos que reúnan las características que tiene el aquí presentado.


12

Tabla 1. 1 Comparación de trabajos relacionados con la tesis.

Herramienta

Tipo de Líneas Identificadas* (Sí = X)

Ubicación Tipo de Reporte

Gene

rada

s

Lógi

cas

Físic

as

Agre

gada

s

Borra

das

Cam

biad

as

Base

Reus

adas

Otra

Estrategia

Dashboard[RAI05] X X X X X *Recorre Archivos Independiente

HTML *Compara versiones

RSM[MSQ06] X X X X X

*Recorre Archivos *Independiente *Compara versiones *Línea de comandos HTML

*Integrado al IDE CSV

LOCC[DAN06] X X X *Recorre Archivos *Independiente Texto

*Compara versiones *Línea de comandos XML

Understand[SCT05] X X X *Recorre Archivos *Independiente

HTML *Internet/Intranet

CodeStriker[SIT05] X X X X *Recorre Archivos *Internet/Intranet


Krakatau[POW05] X X X X X X *Recorre Archivos *Independiente


SourceMonitor[CAM06] X X *Recorre Archivos *Independiente

*Compara versiones *Integrado al IDE XML

SLOCCount[WHE04] X

*Recorre Archivos *Línea de comandos Texto *Busca cadenas que HTML indiquen si el código X fue generado.

CCCC[CCC05] X X *Recorre Archivos *Línea de comandos HTML, XML

SourceForge[SFG06] X X *Recorre Archivos *Línea de comandos

TXT, HTML, CSV *Independiente TESIS X X X X X X X X X *Marcado de Texto *Integrado al IDE XML

1.3 Descripción del problema Cuando se aplica el Proceso Personal de Software (PSP) es necesario conocer el estado actual del desarrollador, por tanto, debe medirse la cantidad de trabajo realizado con respecto al tiempo de desarrollo del producto. La tarea de medir consiste en contar las líneas de código escritas por el programador, siendo clasificadas en distintos tipos como líneas añadidas, modificadas, reutilizadas, entre otras; lo que hace complicada esta labor es que con la utilización de ambientes de desarrollo que permiten generar líneas de código de manera automática sin tener completa la aplicación, tales como los IDE, el código escrito para completar la funcionalidad del sistema deberá introducirlo el desarrollador, con la observancia de que sus líneas deberán contarse para medir el rendimiento de quien las escribió.


13

El problema radica en que llevar el conteo manual de las líneas de código escritas, provoca errores y confusión sobre el tipo en el que se debieran clasificar las líneas que se agregaron a la base inicial elaborada por el ambiente de desarrollo; además, incrementa el tiempo que el desarrollador invierte en la actividad de postmortem dentro del PSP, específicamente en la medición del tamaño del proyecto (ver “Estructura del PSP”, Capítulo 2).

Gran parte de la confusión que se genera al clasificar y contar las líneas de código radica en que esta labor se lleva a cabo después de la liberación del código, y es natural que el programador no recuerde con exactitud qué acciones se ejecutaron en cada una de las líneas contenidas en el código final.

1.4 Objetivo Definir una estrategia de conteo de los distintos tipos de líneas de código para estimar el tamaño de los proyectos de software, haciendo la diferencia entre las que son generadas automáticamente por un ambiente de desarrollo integrado (IDE) y las que escribe un desarrollador.

1.5 Hipótesis “La clasificación automática de las líneas de código al momento de hacer la codificación en un proyecto, almacenando la información en una bitácora, ayuda a distinguir las líneas generadas automáticamente por un IDE y las que escritas por el programador”.

Teóricamente, al contar con una herramienta de clasificación automática de líneas, el desarrollador no tendría que recordar cuáles fueron las acciones que ejecutó para producir cada línea de código del proyecto (p. ej.: si la línea fue añadida, borrada, modificada, generada por el IDE, etc.) cuando requiera de hacer el conteo de las líneas empleadas y, por tanto, los datos obtenidos en la medición serían más exactos que los que se obtienen con herramientas convencionales.

1.6 Justificación El Proceso de Software Personal (PSP) propone un método para evaluar el rendimiento del desarrollador que incluye actividades tales como planeación, diseño, codificación, compilación, pruebas y postmortem [HUM95]. Una parte importante para la planeación de proyectos de software es la estimación de su tamaño. Para este propósito se han ideado diversas técnicas de medición, aunque una de las más aceptadas es el conteo de líneas de código (LOC); para lograr esto se requiere contar las líneas nuevas, base, modificadas,


14

reutilizadas y borradas, lo que no es parte sustantiva del proceso, ya que esta actividad toma tiempo del esfuerzo dedicado al desarrollo del sistema; esta labor es de medición exclusivamente.

Muchos desarrolladores ignoran cuantas líneas de código se han creado hasta el momento o al final del proyecto, debido a la escasez de herramientas que le ayuden a contar de manera automática y en ocasiones debido al consumo de tiempo que implica contar líneas de código de manera manual, por lo que sería de gran utilidad disponer de una herramienta que realice esta tarea automáticamente y libre de errores para que el desarrollador pueda utilizar el tiempo rescatado en otras actividades más productivas, como sería la revisión del diseño, por mencionar alguna.

Pese a que ya existen estrategias para llevar a cabo el conteo de líneas, no se ha llegado a un estándar que refleje lo que verdaderamente sucede cuando se codifica un software, lo que se demuestra con las herramientas que generan código. Esta situación se torna evidente al observar que las líneas generadas por los ambientes de programación no son consideradas dentro los estándares actuales de clasificación, provocando que existan desviaciones importantes de planeación al calcular el tiempo que tomará un proyecto en ser realizado en base a los tamaños de trabajos anteriores y, por ende, una mala valoración de su presupuesto.

1.6.1 Beneficios

• Una estrategia para automatizar el conteo y la clasificación de líneas de código, al mismo tiempo que se realiza la codificación de un proyecto de software.

• Una estimación de tamaños de software más confiable con base en las líneas de código.

• Menor esfuerzo al contar líneas de código y reducción de tiempo dedicado a esta actividad.

1.7 Alcances y limitaciones

1.7.1 Alcances • El trabajo está basado en el conteo que propone el PSP para la medición del tamaño

de un software, es decir, se obtiene el tamaño de líneas de código lógicas a partir de líneas base, borradas, modificadas, añadidas, reutilizadas más las generadas.

• Se identifican los escenarios de codificación en ambientes de desarrollo integrado que influyen en la clasificación y conteo de líneas de código.

• Con la Estrategia de Conteo propuesta se definen los requerimientos para una herramienta que se aplique en un ambiente de desarrollo que permita extensión.


15

1.7.2 Limitaciones • No se implementa la estrategia obtenida en una herramienta. • No se evalúa la productividad del desarrollador con base en el tiempo. • No se hacen otros tipos de medición distintos al conteo de líneas de código (por

ejemplo, complejidad ciclomática o puntos de función).

1.8 Metodología de Solución La metodología empleada en la elaboración de la Estrategia de Conteo involucró las siguientes actividades:

1. Tipificación de líneas de código producidas en un ambiente de desarrollo integrado. Se identificaron distintas formas en que un programador puede producir código en un ambiente de desarrollo integrado, ya sea por escrito o mediante el uso de las funciones que el IDE le proporciona. A partir de los casos de uso detectados se tomó en cuenta el tipo inicial de una línea de código (“nueva”, “base”, etc.) para establecer su tipo resultante al ocurrir un evento determinado.

2. Análisis de escenarios de codificación en IDEs. Se identificaron los eventos que

pueden producir cambios en el tipo de una línea de código dentro un ambiente de desarrollo. Para cada uno se asignó un Caso de Uso y se describió en plantillas de escenarios para ser analizadas con el objetivo de definir una estrategia de clasificación y conteo de líneas, basada en los tipos de línea definidos en la actividad anterior.

3. Estudio de formas de generación automática de código. Con la finalidad de

detectar el momento en que una herramienta que genera código lanza a éste a un editor, se realizó un estudio de los métodos usados para la generación automática de código.

4. Estudio de APIs de extensión de ambientes de desarrollo integrado. Se

revisaron tres IDEs de Java para conocer cómo se pueden integrar herramientas externas al entorno de programación y cuál de ellas presenta mayor facilidad para ser extendida con una herramienta de conteo de líneas.

5. Estudio de la detección de eventos en IDEs. Para comprobar que el conteo de

líneas de código puede ser llevado a la fase de codificación y se pueden registrar los cambios en una línea en el momento en que suceden, fue necesario conocer cómo se detectan eventos en un IDE (el estudio fue enfocado a lenguaje Java).


16

6. Elaboración de estrategias de conteo. En un principio se propuso una estrategia que, luego de hacer los estudios necesarios –en los puntos anteriores- para revisar su factibilidad, se concluyó que no era viable llevarla a cabo, por lo que se procedió a plantear estrategias alternas para resolver los problemas identificados en la primera, cada una cubriendo algunas necesidades pero presentando riesgos importantes. Al final, se logró integrar las estrategias para minimizar los problemas de cada una, resultando en una Estrategia de Conteo final.

7. Adaptación de la Estrategia de Conteo a los escenarios de codificación. Se

formularon métodos para adaptar la Estrategia de Conteo a cada uno de los casos de uso identificados en la actividad 2. Posteriormente se identificaron y resolvieron ambigüedades y problemas que conllevan estos métodos. Por último, se integraron los métodos sin ambigüedades, para presentarse en las plantillas de escenarios de los casos de uso de una herramienta que implemente la Estrategia encontrada.

En los próximos capítulos se describen con detalle las actividades mencionadas.

Capítulo 2 Marco Teórico

17


Para poder asegurar la comprensión de los principales conceptos que se usan a lo largo de esta la tesis es necesario definirlos. A continuación se presentan los términos más importantes utilizados en este documento y su significado, tratando de describir el entorno en el que se manejan.


18

2.1 Proceso de software Dentro de la Ingeniería de Software los procesos se usan para trabajar de una manera ordenada en la producción de proyectos de software. Watts Humphrey define a los procesos de software como “la secuencia de pasos requerida para desarrollar o mantener software. Una definición del proceso de software es una descripción de este proceso. Cuando está bien diseñada y presentada, la definición sirve de guía a los ingenieros de software al momento de trabajar.”[HUM95]

En su libro “A Discipline for Software Engineering” [HUM95] , Humphrey presenta el Proceso de Software Personal (PSP por sus siglas en inglés) , el cual incluye dentro de su última fase -postmortem- el conteo de líneas de código. Por este motivo, a continuación se describe brevemente este proceso.

2.1.1 Proceso de Software Personal (PSP) Del inglés Personal Software Process. “El PSP es un proceso de software definido y ajustado para ser usarse por un solo ingeniero de software”. [HAY97]

A finales de los 80s y principios de los 90s el SEI (Software Engineering Institute – Instituto de Ingeniería de Software) 2 desarrolló el Capability Maturity Model (CMM) el cual capturó las mejores prácticas organizacionales del desarrollo de software. Como miembro del SEI, Watts Humphrey decidió aplicar los principios subyacentes del CMM a las prácticas del desarrollo de software de un solo desarrollador. El resultado de este esfuerzo fue el Proceso de Software Personal (PSP), diseñado para ser un proceso de nivel 5 del CMM para desarrolladores de software individuales. [SEI06]

De acuerdo a [HUM95] “la intención [del PSP] es guiar la planeación y el desarrollo de módulos de software o pequeños programas, pero es adaptable a otras tareas personales. Para promover una mejora a nivel personal, el PSP orienta al ingeniero de software hacia el manejo y control del proceso. Con PSP los ingenieros desarrollan software usando un enfoque disciplinado y estructurado”.

El PSP enseña a los ingenieros cómo:

• Administrar la calidad de sus proyectos • Realizar compromisos que puedan cumplir • Mejorar la estimación y planeación • Reducir defectos en su productos

2 SEI. Siglas en inglés del Instituto de Ingeniería de Software. Centro de investigación y desarrollo financiado federalmente, patrocinado por el Departamento de Defensa de los E.E.U.U. y operado por la Carnegie Mellon University. URL http://www.sei.cmu.edu


19

El Instituto de Ingeniería de Software en [SEI06] afirma que “puesto que los costos personales constituyen un 70 por ciento del costo del desarrollo de software, las habilidades y hábitos de trabajo de los ingenieros determinan ampliamente los resultados del proceso de desarrollo de software.”

El PSP puede aplicarse a muchas partes del proceso de desarrollo de software,

incluyendo:

• Desarrollo de programas pequeños. • Definición de requerimientos. • Documentación. • Pruebas del sistema. • Mantenimiento del sistema. • Mejora de sistemas de software grandes.

2.1.1.1 Estructura del PSP La estructura del proceso PSP se muestra conceptualmente en la figura 2.1. Empezando con un estatuto de requerimientos, el primer paso en el proceso PSP es la planeación. Existe un script de planeación que guía este trabajo y un resumen del plan para registrar los datos de planeación, que incluyen estimaciones de tamaño, tiempo y defectos. Mientras los ingenieros siguen el script para hacer el trabajo, registran su tiempo y sus defectos en las bitácoras de tiempo y defectos. Al final del trabajo, durante la fase de postmortem (PM), los ingenieros resumen los datos de tiempo y defectos de las bitácoras, miden el tamaño del programa e introducen estos datos en el formulario de resumen del plan. El registro de los datos obtenidos se compara con los datos planeados al inicio del proyecto para identificar la exactitud de la planeación y posibles puntos de mejora. Cuando el ingeniero termina el postmortem, entrega el producto terminado junto con el formulario de resumen del plan completo. [HUM00]


20

Figura 2. 1 Flujo del proceso PSP

2.2 Tamaño del Software

2.2.1 Métricas de software

“Las métricas del software se refieren a un amplio elenco de mediciones para el software de computadora. La medición se puede aplicar al proceso del software con la intención de mejorarlo sobre una base continua. Se puede utilizar en el proyecto del software para ayudar en la estimación, el control de calidad, la evaluación de productividad y el control de proyectos. Finalmente, el ingeniero de software puede utilizar la medición para ayudar a evaluar la calidad de los resultados de trabajos técnicos y para ayudar en la toma de decisiones a medida que el proyecto evoluciona”. [PRE02]

Existen diversas métricas para el software con el propósito de recopilar información

que sirva como base para “ayudar en la estimación, el control de calidad, la evaluación de productividad y el control de proyectos”. [PRE02]

En un proyecto de software, se utiliza la medición como ayuda para la evaluación de la calidad del trabajo (en cuanto al producto y el proceso empleado) y como guía para la toma de decisiones. Las métricas de software se clasifican de acuerdo a sus objetivos como: del producto o del proceso. Las primeras miden el producto en cualquiera de las fases del proceso, calculando la complejidad del diseño, el tamaño total del programa o el tamaño de la documentación generada; las últimas, se avocan a la medición del proceso de desarrollo,


21

como es el tiempo de desarrollo, tipo de metodología empleada o nivel de experiencia del equipo de desarrollo, por mencionar algunos ejemplos. [SEI88]

Este documento trata únicamente de las métricas del producto de software, específicamente de las orientadas al tamaño, puesto que es el área en la que se encuentra dirigida la investigación en curso.

2.2.2 Métricas Orientadas al Tamaño “Las métricas del software orientadas al tamaño provienen de la normalización de las medidas de calidad y/o productividad considerando el «tamaño» del software que se haya producido”. [PRE02]

Como se mencionó anteriormente, las métricas de tamaño forman parte de las

métricas del producto de software. Entre las métricas de tamaño más populares se encuentran las líneas de código (LOC, por sus siglas en inglés) y los puntos de función.

• Líneas de código: Es aparentemente la forma más simple de medir un producto de software; sin embargo, existen diversas definiciones para las líneas de código contenidas en un programa, como las que identificó el SEI y que serán discutidas más adelante. La forma más sencilla de contar líneas de código es considerar cualquier línea que no esté en blanco o sea un comentario, independientemente del número de instrucciones que contenga [SEI88]. El conteo de líneas de código es usado para predecir la complejidad de un programa, el esfuerzo de desarrollo total y el desempeño del programador.

• Puntos de función: Medida del tamaño de software propuesta por Allan Albercht,

puede implementarse desde el inicio del desarrollo. Se trata de calcular el valor de los puntos de función para un proyecto basados en las entradas del usuario, consultas, salidas del sistema y archivos. Se aplican diferentes pesos dependiendo del tipo de punto de función y se ajustan de acuerdo a la complejidad estimada de cada uno de ellos, para después obtener el total del conjunto. [ALB83]

Aunque existen trabajos que sugieren que los puntos de función deberían ser

mayormente utilizados en vez de las líneas de código [GOL04], esta investigación está dirigida a servir tanto a los desarrolladores que sigan el PSP y TSP3 - que usan LOC como medida de tamaño - como a todos aquéllos que utilicen el conteo de líneas de código para medir sus productos.

3 TSP Siglas en inglés de Proceso de Software en Equipo. Proceso de software creado por Watts Humphrey, del SEI, para proyectos en equipo. URL http://www.sei.cmu.edu/tsp/tsp.html


22

2.2.1 Clasificación de líneas de código

En 1992, Robert E. Park – del SEI- desarrolló un marco para contar sentencias de código que presenta “guías para definir, registrar y reportar dos medidas de tamaño de software frecuentemente usadas –líneas de código físicas y sentencias de código lógicas”. [PAR92]

El resultado del trabajo de Park es una plantilla para especificar el tipo de atributos con los que cuenta el código fuente de un proyecto de software y cómo deben considerarse.

Como se observa en la figura 2.2, la primera hoja de la plantilla contiene cuatro

tipos de clasificación: • Tipo de sentencia. Pueden ser ejecutables, declaraciones, directivas del

compilador, líneas en blanco y comentarios. Estos últimos se subdividen en comentarios en su propia línea, comentarios con código, banners (bloques) y comentarios en blanco.

• Cómo se produjo. Identifica el proceso usado para producir líneas y sentencias

individuales. Pueden ser programadas, generadas automáticamente por herramientas, convertidas con traductores automáticos, copiadas o reutilizadas sin cambios, modificadas u alguna otra definida por el usuario de la plantilla.

• Origen. Identifica la forma anterior (si existe) en la que el producto de software se

basó. Puede tratarse de un nuevo trabajo o un trabajo anterior, por lo que se especifica si viene de una versión previa, librerías de re-uso, otro producto, etcétera.

• Uso. Distingue entre el software que se usa como una parte de un producto principal

y el que no (puede ser un producto principal por sí mismo o una parte externa o de soporte para el principal). Esta discriminación se hace porque existen diferencias en diseño, codificación y pruebas entre estos los dos tipos de uso mencionados.

En las siguientes secciones de la plantilla están incluidas clasificaciones como tipo

de entrega, funcionalidad, lenguaje, clarificaciones, clarificaciones del lenguaje, réplicas y estatus de desarrollo.


23

Figura 2. 2 Plantilla de definición para conteo de instrucciones de código. [PAR92]

Posteriormente Watts Humphrey en [HUM95], continuando con el trabajo de Park [PAR92], éste identifica distintos tipos de líneas de código fuente, entre las que se encuentran:

- Base (B). Cuando se modifica un programa desarrollado anteriormente, el total de

líneas de código de un programa previo. - Borradas (D). El total de LOC borradas de un programa base, contadas en la

conclusión del proyecto. - Reutilizadas (R). Las LOC de programas previamente desarrollados que son usadas

sin modificación, contadas en la conclusión del desarrollo.


24

- Totales (T). El total de líneas de código del programa finalizado; se miden al concluir el proyecto.

- Añadidas (A). Las LOC agregadas durante el proyecto actual, calculadas como A=T-B+D-R.

- Modificadas (M). Las líneas de código cambiadas en el programa base, contadas en la conclusión del proyecto. Podría contarse cada línea de código modificada como una línea borrada y una línea añadida.

- Nuevas y Cambiadas (N). Todo el código añadido o modificado, calculado como N=A+M

- Nuevas Reutilizadas. Las LOC desarrolladas en el proyecto actual que se agregan a la librería de reutilización, contadas en la conclusión del proyecto. Existen diversos estudios orientados a la estandarización de las métricas de

software, tomando en cuenta diferentes factores como en el caso de las métricas de tamaño, en el que las líneas de código se analizan para determinar su procedencia, propósito y destino, entre otras cosas. En esta investigación se partió del trabajo de [PAR92] y [HUM95] para determinar los tipos de línea a considerarse en el conteo para ambientes de desarrollo integrado.

2.3 Marcado de Texto En los próximos capítulos se verá cómo interviene el marcado de texto en la estrategia planteada para el conteo de líneas de código. En esta tesis se propone al XML como medio para almacenar los tipos de línea por un contador aplicado a un ambiente de desarrollo.

2.3.1 XML [WES02] Viene de eXtensible Markup Language (Lenguaje de Marcado Extensible), una sintaxis que describe cómo agregar estructura a la información. Un lenguaje de marcado es una especificación que adhiere nueva información a la ya existente, mientras que se mantienen los dos conjuntos de información por separado.

El XML es una sintaxis que describe información, mediante un conjunto de tecnologías que permite dar formato y filtrar información independientemente de cómo esté representada y la concepción de una idea que reduce los datos a su forma más pura, libres de formato y otros aspectos irrelevantes, para conseguir un alto nivel de utilidad y flexibilidad.

El XML define un conjunto de reglas para crear lenguajes de marcado. Existen muchos tipos de lenguajes de marcado, el más popular es HTML (Lenguaje de Marcado de Hipertexto – Hypertext Markup Language). HTML combina el formateo de información con el contenido de una página Web para que lo que se vea la página esté en la forma que el diseñador intentaba mostrarla.


25

Los dos elementos más importantes que hacen que HTML funcione son el HTML mismo y el software que es capaz de interpretar el HTML. Cuando se visualiza una página Web, el navegador obtiene la página, interpreta el HTML y despliega el documento resultante en la pantalla. De igual manera, en el XML se necesitan dos elementos: el XML mismo y el software que es capaz de interpretar el XML.

2.4 Interfaz de Programa de Aplicación (API)

Para implementar una herramienta como la descrita en esta tesis, se deber hacer uso de las APIs de extensión del ambiente de desarrollo integrado al que se quiera aplicar la herramienta.

Una API (acrónimo de Application Program Interface -Interfaz de Programa de Aplicación) es un conjunto de rutinas, protocolos y herramientas para construir aplicaciones de software. Una buena API hace más fácil desarrollar un programa suministrando todos los bloques para construir. Un programador junta los bloques.

La mayoría de los ambientes operativos, como MS-Windows, proveen una API para que los programadores puedan escribir aplicaciones consistentes con el ambiente operativo.

Aunque las APIs están diseñadas para programadores, también pueden ser buenas

para los usuarios, porque garantizan que todos los programas usando una API en común tendrán interfaces similares. Esto hace más fácil para los usuarios el aprender nuevos programas. [WEB07]

Como parte de esta investigación se realizó un estudio de las APIs para extensión

que utilizan tres ambientes de programación de lenguaje Java. Este estudio se encuentra en el Apéndice A.

2.5 Generación de Código Uno de los aspectos que cubre la estrategia de conteo propuesta en esta tesis es la detección de líneas de código generadas automáticamente en un proyecto.

Se define a la generación de código como “la construcción automática de código de alto nivel (como Java, C#, etc.) a partir de una descripción de los requerimientos del código.”[HER03].

Existen aplicaciones cuyo propósito es la generación de código fuente desde la especificación de requerimientos de nuevas aplicaciones, mismos que son obtenidos de formularios y/o pantallas con elementos gráficos. Ejemplos claros de aplicaciones que implementan esta práctica son los ambientes de desarrollo integrado (IDE por sus siglas en


26

inglés), mismos que presentan asistentes para la generación de código; también existen herramientas generadoras que toman las especificaciones de los modelos definidos por el usuario como son: diagramas UML, Warnier, entre otros.

El Apéndice B muestra los tipos de generación de código que se emplean

regularmente y las opciones que se encontraron para la detección de líneas de código producidas de esta forma.

2.6 Eventos “Un evento es la acción u ocurrencia detectada por un programa. Los eventos pueden ser acciones de un usuario -como hacer clic a un botón del ratón o presionar una tecla-, u ocurrencias del sistema -como la falta de memoria. Muchas de las aplicaciones modernas, particularmente aquéllas que corren bajo ambientes Macintosh y Windows, se dice que están dirigidas a eventos, porque están diseñadas a responder a eventos.” [WEB07] El Apéndice C describe cómo se pueden detectar eventos de ratón o teclado por medio de funciones en lenguaje Java y, cuál es la utilidad de hacerlo para el conteo de líneas de código.

2.7 Observaciones En este capítulo se presentaron los conceptos más relevantes que son usados en el resto del documento. Éstos y otros conceptos se definen en el glosario de términos.

Capítulo 3 Tipos de LOC producidas en un IDE

27

Capítulo 3 Tipos de LOC producidas en un IDE Cuando un programador codifica, utiliza los recursos que presta el ambiente de programación para facilitar el trabajo. Además de escribir líneas de código manualmente, es posible utilizar asistentes para generación automática de código y valerse de los beneficios de las funciones copiar-cortar y pegar que brinda su ambiente. Por otro lado, el desarrollador puede realizar algunas acciones sobre código ya existente.

Este capítulo describe los casos se presentan al trabajar sobre la fase de codificación en el proceso de software. A partir de los casos descritos se hizo un análisis para obtener la clasificación de las líneas de código que producen cada uno de ellos.

Para cada Caso de Uso se describe uno o varios tipos de línea que produce

(descritos por Humphrey en [HUM95]), aunque también se proponen dos tipos de línea más: “generadas” y “copiadas”. Por otra parte, un tipo de línea puede ser producida por varios escenarios.


28

3.1 Vista general de Casos de Uso de codificación Un desarrollador tiene distintas formas de producir código, la figura 3.1 muestra los casos de uso generales de codificación en un proyecto en un ambiente de desarrollo integrado (IDE).

uc Casos de Uso Codificación

Desarrollador

U5 Agregar líneasU1 Generar código automáticamente

U3 Modificar código

U4 Borrar códigoU2 Copiar-

Cortar/Pegar

Figura 3. 1 Casos de Uso de codificación en un ambiente de desarrollo integrado

En los apartados siguientes se describen estos casos, se muestra su comportamiento

mediante ejemplos específicos y se definen el o los tipos de línea que producen.

3.2 Usos de generación automática de código (U1) Existen distintas formas de generar código automáticamente en un proyecto de software:

• El comienzo de una aplicación mediante ambientes de desarrollo integrado. Descripción. Al utilizar los llamados IDEs, cuando se comienza con una aplicación, se puede generar código automáticamente. El entorno de desarrollo lanza un asistente con cada nuevo proyecto para recopilar información con la que produce el código necesario de inicio. Ver figura 3.2.


29

Figura 3. 2 Inicio de un proyecto en un IDE. a) Asistente de configuración de nuevo proyecto, b) Lista de

archivos generados automáticamente, c) Parte del código generado automáticamente • Al agregar componentes a un formulario.

Descripción Ya comenzado el proyecto, en los ambientes visuales se pueden utilizar formularios para diseñar las interfaces de usuario. En éstos se agregan componentes como botones, cuadros de texto, etiquetas, listas desplegables, etc., cada uno con capacidad de capturar un evento del ratón o del teclado y ejecutar ciertas acciones. Al momento que se coloca cada uno de los componentes, se genera código, una estructura que debe ser completada para que tenga funcionalidad. Ver figura 3.3.

a b

c


30

Figura 3. 3 Agregación de componentes a interfaz de usuario. Se observa la forma gráfica y un fragmento

del código asociado. • Con el uso de asistentes (wizards) en el proyecto iniciado.

Descripción Aunque los asistentes aparecen principalmente al inicio de un proyecto, pueden ser usados cuando éste ya está en curso. Por ejemplo, cuando se quieren agregar clases en un lenguaje orientado a objetos, es posible recurrir a un asistente que pregunte por el nombre de la clase, su clase padre –si existe-, después sus métodos y variables. Todo esto es traducido a código automáticamente al finalizar el diálogo. Más adelante se pueden agregar o modificar las características a petición del programador. (Figura 3.4)


31

Figura 3. 4 Utilización de asistentes (wizards) para crear clases y sus métodos, en la parte inferior se observa

el código generado después de usar los asistentes.

• Al exportar modelos de las herramientas de diseño de software.

Descripción Existen herramientas de modelado de software de las que se obtiene código. Generalmente el diseñador reúne componentes visuales con características particulares en un proyecto de diseño. A partir de ahí se pueden exportar estos datos y transformarlos a código, mismo que debe completarse para ser funcional (Figura 3.5).


32

Figura 3. 5 Ejemplo de generación de código a partir de modelado.

Líneas producidas

Cada vez que se genera código con uno de estos métodos el desarrollador invierte cierta cantidad de esfuerzo distinta de cuando se codifica manualmente, por lo que es útil hacer una distinción entre estas fuentes de codificación.

Se propone, entonces, agregar a los tipos de línea identificados por [HUM95] la categoría de línea “generada”, con el propósito de dar al desarrollador una mejor idea del esfuerzo empleado.

Una herramienta automatizada que detecte líneas “generadas” deberá ser lo

suficientemente flexible para ignorar cuando esto suceda, permitiendo la opción de clasificar este código como “base”, “reusado” o “nuevo”.

3.3 Usos de copiar-cortar/pegar (U2) Mann [MANN06] describe cinco escenarios del uso de las funciones copiar, cortar y pegar según su intención:

• Cortar para borrar

Descripción. Aunque el objetivo de cortar es mover código al pegarlo en un lugar distinto a donde fue cortado, esta función también se usa sólo para borrar código, al no ser pegado posteriormente.


33

Figura 3. 6 Ejemplo del uso de Cortar para borrar.

Líneas producidas. En la figura 3.6 se da un ejemplo del uso de la función Cortar para quitar código. Este es un caso típico de borrado, por lo que se debe clasificar de acuerdo a los casos descritos en el apartado “Escenarios de borrado” en este mismo capítulo.

• Cortar y pegar para mover algo

Descripción. La función esencial de Cortar es mover la información de lugar, removiéndola de su ubicación original y colocándola en otra. Como se aprecia en la Figura 3.7, el bucle while es movido abajo usando esta combinación de funciones (Cortar-Pegar).


34

Figura 3. 7 Ejemplo de uso de Cortar para mover.

Líneas producidas. Para deducir el tipo de líneas que produce este caso, habrá que verificar la condición anterior de las líneas que han sido movidas. Existiendo los siguientes sub-casos:

o Cortar una línea “base” y pegar en otro lado: Esto es una situación clara de modificación de código, por lo que deberían de clasificarse estas líneas como “cambiadas”, siempre y cuando el código haya sido cambiado de lugar; de lo contrario, no existirá cambio en la clasificación, manteniéndose en su tipo original, es decir, como “base”.

o Cortar cualquier otro tipo de línea y pegar en otro lado: En este caso las

líneas conservarían su tipo original, ya que la clasificación de cada una debe quedar asentada al final de cada versión del proyecto.

Si el destino del código cortado es el mismo origen no se deberá producir ningún cambio en el tipo de líneas.


35

• Copiar y pegar para duplicar

Descripción. La idea es tener exactamente lo mismo en lugares distintos. En el ejemplo de la figura 3.8 se desea duplicar el nombre de la variable fileIn para no generar inconsistencias al escribirla cada vez que se utiliza.

Figura 3. 8 Ejemplo de uso de Copiar y Pegar para duplicar.

Líneas producidas. Cuando sólo se duplican fragmentos de líneas de código como nombres de variables o datos constantes, necesariamente se escribirá código para completar la línea, entonces, debería ser clasificada como “nueva”.


36

• Copiar y pegar para crear una plantilla

Descripción. En este caso la idea es tener fragmentos de código similares. Suponiendo que se quiere tener el mismo comportamiento para dos métodos diferentes, el programador únicamente copia la primera función para generar la segunda, a ésta última sólo le cambia el nombre, obteniendo el resultado deseado (figura 3.9).

Figura 3. 9 Ejemplo de uso de Copiar y Pegar para crear plantillas.

Líneas producidas. Aunque se produce nuevo código cada vez que se copia y pega, el esfuerzo que se hace es distinto a cuando se escribe manualmente cada línea de código.

Hay que tomar en cuenta que un fragmento de código puede ser tomado: 1) de una fuente externa a un nuevo proyecto, o 2) de una versión anterior – ya contada- y replicarse en el nuevo proyecto.

En [PAR92] se consideran los dos casos anteriores, proponiendo que las copias de sentencias preexistentes (caso 1) se tomen como “reusadas”; mientras que para el caso 2 se aconseja que se clasifiquen como “copias de sentencias maestras físicamente repetidas en el código maestro”, es decir, copias de líneas base. Este tipo no forma parte de la definición de líneas del PSP [HUM95], sin embargo, resulta útil hacer una identificación de este código puesto que ayuda a dar una idea del esfuerzo realizado, por lo que se recomienda la utilización del término “copiada” como una clasificación, con la consideración de que se le pueda asignar otro tipo manualmente en cualquier momento.

Lógicamente el código que no cambia mantiene su estatus de “copiado”,

mientras que las líneas de código copiadas y posteriormente cambiadas serán consideradas como “cambiadas”.


37

• Copiar y pegar sin conexión lógica.

Descripción. Este caso se presenta cuando el programador sólo quiere conservar una cadena de caracteres en el portapapeles que necesita usar varias veces, sin que esto signifique que cada copia de la cadena deba tener una relación con las demás. En el ejemplo de la figura 3.10, la palabra reservada int se copió y pegó en tres ocasiones para declarar distintas variables.

Figura 3. 10 Ejemplo de uso de Copiar y Pegar para crear plantillas.

Líneas producidas. Al igual que el escenario de copiar y pegar para duplicar, cuando se copia y pega sin conexión lógica, sólo se duplica una cadena de texto fuera de cualquier contexto, es necesario agregar código manualmente para tener una línea de código completa. Así, este escenario genera una línea de código “nueva”.

Además de los escenarios mencionados, se pueden identificar otros correspondientes a las funciones Copiar/Cortar – Pegar según la procedencia del código. A continuación se tienen los siguientes casos y los tipos de líneas que producen:

• Desde una fuente externa.

Descripción. Código obtenido de cualquier fuente ajena al proyecto en curso, como ejemplos se pueden mencionar: otro proyecto, código de ejemplo en un tutorial y código mostrado en Internet (figura 3.11).


38

Figura 3. 11 Código copiado de una fuerte externa (Internet) y pegado en el proyecto actual

Líneas producidas. El hecho de tomar código de un lugar distinto de donde se encuentra el proyecto en curso representa reuso. Independientemente de que el código venga de otro proyecto, algún archivo independiente, Internet, etc., las líneas que se producen deberían ser tomadas como “reusadas”. Mismas que luego podrán ser “cambiadas” o “borradas”.

• Dentro del proyecto.

Descripción. Para este caso se pueden presentar cualquiera de los escenarios descritos en [MANN06], todos ellos dentro del proyecto en curso (figura 3.12).


39

Figura 3. 12 Código copiado de un proyecto hacia el mismo proyecto.

Líneas producidas. Esta situación va estrechamente ligada a los escenarios anteriormente descritos:

o cortar y pegar para mover algo, o copiar y pegar para duplicar, o copiar y pegar para crear una plantilla y o copiar y pegar sin conexión lógica

de los que se pueden obtener exactamente los tipos de línea.

• Del mismo archivo.

Descripción. De la misma manera, cualquier escenario descrito por [MANN06] puede ocurrir, aunque en esta ocasión la fuente y el destino estarán en el mismo archivo. Ver figuras 3.6, 3.7, 3.8 y 3.9.

Líneas producidas. Al igual que el caso anterior, se pueden presentar las situaciones ya mencionadas:

o cortar y pegar para mover algo, o copiar y pegar para duplicar, o copiar y pegar para crear una plantilla y o copiar y pegar sin conexión lógica,

obteniendo los mismos resultados para cualquiera de las formas en que se producen estas líneas.


40

3.4 Usos de modificaciones (U3)

• Sobre una base

Descripción. Existen ocasiones en que el código viene de una versión anterior de un proyecto y se requieren algunas modificaciones. Este escenario se refiere a los cambios que se hacen a una base inicial. En este caso las líneas tomadas como “base” serán cambiadas (figura 3.13).

Figura 3. 13 Código base al que se le modificaron líneas.

Líneas producidas Éste es el escenario tradicional de modificación de código. Humphrey [HUM95], clasifica a las líneas que modifican a una base como “cambiadas”.

• Sobre una línea copiada-pegada

Descripción Se puede dar la situación de corregir una línea o fragmento de código recién pegado, considerando que el acto de copiar/cortar – pegar y el de modificar se ejecutan en una misma fase de desarrollo: codificación. Por tanto, es posible que uno se sobreponga al otro. Ver figura 3.14.


41

Figura 3. 14 Código pegado y posteriormente modificado.

Líneas producidas Recordando que una línea producida por copiar – o cortar- y pegar puede ser clasificada como “copiada” o “reusada” según las especificaciones mencionadas anteriormente, se debe decir que cualquier cambio que se aplique a estas líneas deberá ser tomado como

o “cambiada” para una línea “reusada” según [PAR92]. o “nueva” para una línea “copiada”, ya que no se parte de una base o código

reusable conocidos.

Para los fragmentos de línea que son copiados para duplicar con o sin conexión lógica (como nombres de variables para el primero o palabras reservadas para el segundo), una modificación será hecha para completar la línea, por lo que no se puede hablar de un cambio propiamente sino de la producción de una línea “nueva”.

• Sobre una línea “nueva” o “cambiada” (corrección)

Descripción Se trata de corregir una línea recién escrita o cambiada. Como en el caso anterior, estos actos se llevan a cabo en la misma fase de desarrollo que la modificación y por tanto podrían superponerse (figura 3.15).


42

Figura 3. 15 Código modificado después de ser agregado o modificado anteriormente.

Líneas producidas Si se tiene una línea “nueva” o “cambiada” en un proyecto, se deduce que éste no ha sido liberado, por lo que cualquier modificación que se aplique a esta línea no afectará su clasificación. Por ejemplo, suponiendo que se parte de una versión de un proyecto, la totalidad de su código será considerado como líneas “base”; ahora, si se modifica una línea pasará a ser una línea “cambiada”. Si más adelante se llegara a cambiar esa misma línea, obviamente mantendría su tipo. Por otro lado, si se agrega una línea a la base, su tipo será “nueva”; si esta misma es modificada más adelante cuando el proyecto no ha sido liberado, seguirá siendo “nueva”, aunque sufra cualquier tipo de cambios en cualquier momento del proceso de software.

• Sobre una línea generada automáticamente.

Descripción El caso de las modificaciones a líneas generadas automáticamente es similar a los anteriores, ya que la generación de código automática forma parte de la fase de codificación. Aunque también podría considerarse como código “base”, por estar predefinido por la herramienta (figura 3.16).


43

Figura 3. 16 Código modificado después de ser generado automáticamente.

Líneas producidas Cuando se realiza un cambio a una de estas líneas, es como si se modificara una “base”, por lo que debe ser tipificada como “cambiada”. Es posible que se piense que el cambiar una línea “generada” resulte en una línea “nueva”, puesto que no forma parte de una base inicial propiamente dicha, pero a simple vista el esfuerzo empleado en modificar una línea “generada” está más cerca del esfuerzo de cambiar una “base” que el de escribir una línea “nueva”.

Confirmando, las líneas “generadas” que sufren cambios hechos por el usuario, serán tomadas como “cambiadas”.

3.5 Usos de borrado (U4) Los escenarios posibles de borrado de código son aplicables exactamente a las mismas fuentes en que se presentan los escenarios de modificación descritos en el apartado anterior.

• De una base Líneas producidas Cualquier línea que sea removida de una base será contada como línea “borrada”.

• Líneas copiadas-pegadas.

Líneas producidas Nuevamente se tiene el caso de las líneas “reusadas” provenientes del acto copiar y pegar. Cuando una de éstas se elimina, se tomará como línea “borrada” [PAR92]. Cosa que no sucede al quitar una línea calificada como “copiada”, en este caso no habrá cambio alguno, ya que se trata con código agregado dentro de un proyecto o


44

versión nueva y no ha sido liberado todavía, por lo que los cambios no son oficialmente registrados.

• Líneas “nuevas” o “cambiadas” Líneas producidas En este caso sí es conveniente distinguir entre las líneas “nuevas” y las “cambiadas”. Para las “nuevas” este escenario se resuelve de la misma forma que cuando se borra una línea “copiada”, es decir, no han sido liberadas aún y por esta causa no se puede decir que dichas líneas se borraron. Por otro lado, hay que recordar que una línea “cambiada” proviene de la modificación de una línea “base”, así que si es eliminada del código realmente se está quitando la línea “base”, por lo que el resultado será una línea de tipo “borrada”.

• Líneas generadas automáticamente.

Líneas producidas El acto de borrar líneas “generadas” no debe suponer un cambio en la versión del proyecto actual. Como en el caso del borrado de líneas “nuevas”, las líneas “generadas” no debieran ser contadas hasta el final del proyecto; así, este caso no producirá ningún cambio en el conteo final del producto.

3.6 Uso de agregación de líneas (U5) Descripción Se refiere a la forma más primitiva de producir líneas de código: escribirlas mediante el teclado de principio a fin, esto es, sustituir una línea en blanco con una línea de código escrita por el programador, delimitada por un salto de línea (Enter). Líneas producidas Todas las líneas escritas por el programador naturalmente son consideradas como “nuevas”.

3.7 Resumen Los eventos que se presentan cuando se codifica un proyecto de software definen el tipo de líneas de código que lo componen. Para determinar cuáles son estos tipos de línea es necesario considerar el tipo inicial de la LOC – si es que hay líneas existentes- y cuáles son los eventos que se le aplican.


45

En la tabla 3.1 se muestra un concentrado de las combinaciones que se presentan en fase de codificación y los tipos de línea resultantes según lo establecido en este documento. La primera columna muestra el tipo de línea a la que se puede aplicar un evento; la segunda, los eventos aplicables a cada línea y, la última, los tipos de línea que se producen al ocurrir el evento. Se observa que en la primera fila de la columna Línea(s) afectada(s) hay una ‘----’, lo que indica que el evento “generar automáticamente” no cambia el tipo a una línea, sólo produce líneas “generadas”. También se puede ver que en la columna Línea resultante puede estar el valor “descartada”, esto significa que la línea desaparece y no se debe registrar como “borrada” puesto que no se eliminó de una base existente.

Una herramienta que aplique esta estrategia de conteo de líneas de código debe

ofrecer al usuario la opción de hacer los cambios de forma manual, considerando los que crea oportunos de acuerdo a la clasificación, es decir, que la aplicación no sea rígida al asignar los tipos a las líneas de código analizadas.

Tabla 3. 1 Tipificación de líneas antes y después de eventos de codificación. Línea(s) afectada(s) Evento Línea resultante

----- Generar automáticamente

Generada

Base

Cortar-Pegar Cambiada Modificar Copiar-Pegar Copiada Borrar/Cortar Borrada

Nueva

Cortar-Pegar Nueva Modificar Copiar-Pegar Copiada Borrar/Cortar Descartar

Cambiada

Cortar-Pegar Cambiada Modificar Copiar-Pegar Copiada Borrar/Cortar Borrada

Copiada

Cortar-Pegar Copiada Copiar-Pegar Modificar Nueva

Borrar/Cortar Descartar

Reusada

Cortar-Pegar Reusada Copiar-Pegar Modificar Cambiada

Borrar Borrada

Generada

Cortar-Pegar Generada Copiar-Pegar Copiada

Modificar Cambiada Borrar Descartar

Nota: Cada línea agregada manualmente es considerada “nueva”. En este capítulo se mostraron de una manera general los casos de codificación en ambientes de desarrollo integrado, los que repercuten en el conteo y clasificación de líneas


46

de código de un proyecto de software. En el capítulo siguiente se describen de manera más específica los casos de codificación hasta el momento mencionados y sus casos derivados, tomando en cuenta a los que se considera que pueden influir en un la tipificación de las líneas de código producidas. Esto con la finalidad de presentar un panorama amplio de Casos de Uso de codificación que permita encontrar la manera de adaptar los tipos de línea identificados en este capítulo con los casos descritos más adelante.

Capítulo 4 Escenarios de Codificación

47


Una vez identificados los tipos de línea producidos por los eventos ocurridos en un IDE al codificar un proyecto, como se hizo en el capítulo 3, se requirió profundizar en el reconocimiento de los escenarios de codificación en que se presentan posibles cambios en el tipo de las líneas de código afectadas. Esta tarea es necesaria para desarrollar una estrategia de conteo de líneas de código en un IDE, ya que más adelante se propone la forma de asignar un tipo de línea a cada evento que provoque un cambio en el código.

El propósito de este capítulo es cubrir la mayor parte de escenarios posibles con los

que un Desarrollador escribe código en un ambiente de desarrollo integrado, considerando las características de las interfaces que el usuario utiliza para lograr esta tarea - teclado y ratón-, además de las funciones que brinda el IDE para la generación, modificación o eliminación automática de código.


48

4.1 Acciones de codificación en un IDE A continuación se presentan diferentes movimientos que existen durante la codificación de un proyecto de software en un ambiente de desarrollo integrado. Se muestran primero las acciones referentes al teclado, tomando en cuenta funciones especiales del mismo como el uso de la tecla Enter, la tecla Retroceso, entre otras; así como el uso de caracteres y dígitos. En el segundo apartado – Métodos del IDE- se reúnen las funciones para codificación que presentan generalmente los IDEs, como son las opciones en menús, asistentes, paneles, etcétera.

En ambos apartados se muestran las figuras con los casos de uso identificados, seguidos de algunos ejemplos para los casos de uso de cada diagrama y posteriormente los escenarios que describen cada uno de los casos. La explicación de cada se muestra en el campo “Nota” de las tablas de escenarios.

El único actor que interviene es el Desarrollador.

Actor: A. Desarrollador. Usuario de un ambiente de desarrollo integrado (IDE), encargado de la codificación de un proyecto.

4.1.1 Teclas que influyen en un IDE La forma en que se emplean las teclas en la codificación de un proyecto influye en la clasificación de líneas de código, por lo que es importante identificar las acciones que se ejecutan sobre éstas, considerando el propósito de su pulsación y su consecuencia.

4.1.1.1 Uso de salto de línea (tecla Enter) Como se observa la figura 4.1, existen diversos usos que se le dan a la presión de la tecla Enter, como finalizar una línea recién escrita (C1.1), agregar líneas en blanco (C1.2), dividir una línea en dos (C1.3) e, incluso, borrar código (C1.4). La diferencia entre los tres primeros casos es la posición del cursor al momento de hacer el salto de línea. Para el C1.1 el cursor debe estar situado al final de la línea recién escrita; para C1.2 el cursor se sitúa ya sea al principio o final de una línea o en una línea en blanco; para C1.3 el cursor se sitúa dentro de una línea, es decir, después del primer carácter y antes del último. El caso C1.4 es diferente, pues se requiere una selección de código previa para borrarlo con un salto de línea.


49

uc Uso de salto de línea (tecla Enter)

C1 Presionar Enter

C1.1 Finalizar línea programada

C1.2 Agregar líneas en blanco

C1.3 Div idir línea

C1.4 Borrar códigoC2 Seleccionar

código

A. Desarrollador

(from Estrategia)

«extend»

«include»

«extend»

«extend»

«extend»

Figura 4. 1 Uso de salto de línea (tecla Enter).

A continuación se describen algunos ejemplos de los casos de uso relacionados y

más adelante se muestran los escenarios correspondientes a estos casos.

Para el caso C1.1 Finalizar línea programada, un ejemplo es la escritura de una línea nueva, finalizando con un salto de línea (Enter).

public class Clase1 {

En el C1.2 Agregar líneas en blanco se dan tres ejemplos:

a. public class Clase1 {

b. public class Clase1 {

c. En C1.3 Dividir una línea, el ejemplo puede ser:


En C1.4 Borrar código, se trata de la selección previa de código que luego puede

ser borrada oprimiendo la tecla Enter. Por ejemplo:


50

public class Clase1 { String cadena1;

String cadena2; } Ahora se describen los escenarios asociados a cada Caso de Uso: C 1 Presionar Enter Nombre del Caso de Uso:

C1 Presionar Enter

Estado: Propuesto Versión: 1.0 Fase: 1.0 Autor: Erick Iduñate Creado en: 09/07/2007 Modificado en: 05/08/2007

Descripción: El Desarrollador puede presionar Enter para dar por terminada la escritura de una línea, dar formato al código mediante saltos de línea, dividir una línea previamente escrita o incluso, borrar un segmento de código seleccionado.

Escenarios: Ruta Básica Presiona Enter

1. El Desarrollador oprime la tecla Enter. 2. Se produce un salto de línea.

Restricciones: Pre-Condición (Propuesto)

Editor Se debe codificar dentro del editor del lenguaje o lenguajes seleccionados.

Pre-Condición (Aprobado)

Funcionamiento La tecla Enter debe funcionar correctamente en el teclado.

Post-Condición (Aprobado)

Salto de línea Se produce un salto de línea.

C1. 1 Finalizar línea programada Nombre del Caso de Uso:

C1.1 Finalizar línea programada


Descripción: El Desarrollador presiona la tecla Enter para finalizar una línea que acaba de escribir (secuencia de caracteres).

Escenarios: Ruta Básica Fin de línea

1. El Desarrollador escribe una línea. 2. El Desarrollador presiona Enter. 3. Se produce un salto de línea.

Restricciones: Pre-Condición (Propuesto) Uno o más caracteres Al presionar Enter debe haber una cadena de

caracteres antes del fin de línea. Pre-Condición (Propuesto) Fin de línea No existen caracteres delante del cursor al

momento de presionar Enter. Pre-Condición (Propuesto) La línea no existía No se modificó ninguna línea existente al

momento de presionar Enter.


51

C1. 2 Agregar líneas en blanco Nombre del Caso de Uso:

C1.2 Agregar líneas en blanco


Descripción: El Desarrollador quiere dar formato al interlineado para mejor comprensión del código mediante saltos de línea.

Escenarios: Ruta Básica Agregar líneas en blanco

1. El Desarrollador sitúa el puntero en una línea en blanco. 2. El Desarrollador oprime Enter. 3. Se produce un salto de línea.

Ruta Básica Agregar líneas en blanco al final de una línea

1. El Desarrollador sitúa el cursor al final de una línea escrita. 2. El Desarrollador presiona Enter. 3. Se produce un salto de línea.

Ruta Básica Agregar líneas en blanco al inicio de una línea

1. El Desarrollador sitúa el cursor al inicio de una línea. 2. El Desarrollador oprime Enter. 3. Se produce un salto de línea.

Restricciones: Pre-Condición (Propuesto) Líneas existentes El salto de línea debe darse entre líneas que ya

fueron programadas o generadas. Pre-Condición (Propuesto) Lugar del cursor El cursor debe colocarse al inicio o fin de una

línea, o en una línea en blanco. No debe colocarse entre caracteres.

Post-Condición (Propuesto)

Salto de línea El espacio entre dos líneas se incrementará en uno.

C1. 3 Dividir línea Nombre del Caso de Uso:

C1.3 Dividir línea

Estado: Propuesto Versión: 1.0 Fase: 1.0Autor: Erick Iduñate Creado en: 09/07/2007 Modificado en: 27/07/2007

Descripción: Varias instrucciones o sentencias en una línea que el Desarrollador quiere separar mediante saltos de línea.

Escenarios: Ruta Básica Dividir línea

1. El Desarrollador sitúa el cursor dentro de una línea. 2. El Desarrollador oprime Enter. 3. La línea es dividida en dos mediante un salto de línea.

Restricciones: Pre-Condición (Propuesto) Línea existente Deben existir caracteres que formen una línea. Pre-Condición (Propuesto) Lugar del cursor El cursor debe colocarse entre caracteres, no al

inicio ni al final de una línea. Post-Condición (Propuesto)



52

C1. 4 Borrar código Nombre del Caso de Uso:

C1.4 Borrar código


Descripción: Se puede borrar código con la tecla Enter si anteriormente fue seleccionado (resaltado)

Escenarios: Ruta Básica Borrado de código seleccionado

1. El Desarrollador selecciona un fragmento de código. 2. El Desarrollador oprime Enter. 3. El código seleccionado es borrado. 4. Se produce un salto de línea.

Restricciones: Pre-Condición (Propuesto) Seleccionar Antes de oprimir Enter debe haber código

seleccionado. Post-Condición (Propuesto)

Borrado El código seleccionado es eliminado.



C 2 Seleccionar código Nombre del Caso de Uso:

C2 Seleccionar código


Descripción: El Desarrollador puede seleccionar código dentro del editor para darle un uso posterior. Puede tratarse de uno o más caracteres, formando un fragmento de línea, una línea completa o varias líneas.

Escenarios: Ruta Básica Seleccionar

1. El Desarrollador selecciona código. 2. El código seleccionado estará listo para ser copiado, cortado, borrado, modificado, etc.

Restricciones: Pre-Condición (Propuesto) No vacío Para seleccionar debe haber por lo menos un

carácter escrito en el editor. Pre-Condición (Propuesto) Selección El código seleccionado estará listo para ser

copiado, cortado, borrado, modificado, etc.


53

4.1.1.2 Uso de teclas con carácter o dígito Cuando se pulsa una tecla con carácter o dígito, se pueden tener distintos fines (ver figura 4.2) como crear una línea nueva (C3.1), extender una línea ya existente (C3.2) al inicio, en medio o al final de la misma (C3.2.1-C3.2.3) o para remplazar código (C3.3), ya sea un solo carácter (C3.3.2) o una selección (C3.3.1) de una o más líneas (C3.3.1.1 y C3.3.1.2).

uc Uso de teclas con carácter o dígito

C3.1 Crear nuev a línea

C3.2 Extender una línea existente

C3.3.1 Remplazar código seleccionado

C3.3.1.1 Remplazar una línea existente

C3.2.1 Agregar código al inicio de

una línea

C3.2.2 Agregar código en medio de

una línea

C3.2.3 Agregar código al final de una

línea

C3.3.2 Remplazar caracteres

C4 Accionar función 'insert'

C3.3 Remplazar código

C3 Oprimir cualquier carácter o dígito


C3.3.1.2 Remplazar líneas existentes y fragmento de línea

A. Desarrollador

(from Estrategia)

«include»

«extend»

«extend»

«include»

«extend»

«extend»

«include»

«extend»

«extend»

«include»

«extend»

«extend»

«extend»

«extend»

Figura 4. 2 Uso de teclas con carácter o dígito.

A continuación se describe un ejemplo de los Casos de Uso relacionados y más adelante se muestran sus respectivos escenarios.

El caso C3.1 Crear Nueva Línea, se refiere al hecho de escribir código, carácter por carácter, en una línea originalmente blanca del editor.


54

En C3.2 Extender una línea existente y sus derivadas C3.2.1, C3.2.2 y C3.2.3 se presentan los ejemplos:

a. public class Clase1 { b. public class Clase_1 { c. public class Clase1 {

Cuando se utiliza la presión de teclas con carácter para remplazar código C3.3, es

posible que se encuentre activada la función Insert (sobrescribir) – C4-, dando como resultado el reemplazo de un solo carácter C3.3.2.

Por otro lado, cuando se remplaza código también puede hacerse después de una

selección de una (C3.3.1.1) o varias líneas con un fragmento (C3.3.1.2). Por ejemplo: a.1 public class Clase1 { String cadena1; String cadena2; }

que, al pulsar una tecla – digamos “i”-, se convierte en

a.2 public class Clase1 { i

String cadena2; }

Un ejemplo de la selección de una o más líneas completas más un fragmento de

otra, seguida de la pulsación de una tecla con carácter o dígito (C3.3.1.2), es:

b.1 public class Clase1 { String cadena1; String cadena2; } que, al pulsar una tecla – digamos “i”-, se convierte en

b.1 public class Clase1 { /*id00001*/ String i }

Ahora se describen los escenarios asociados a cada Caso de Uso:


55

C 3 Oprimir cualquier carácter o dígito Nombre del Caso de Uso:

C3 Oprimir cualquier carácter o dígito


Descripción: El Desarrollador oprime una tecla de carácter o dígito para escribir código. Puede crear nuevas líneas, extender una línea existente o remplazar código existente.

Escenarios: Ruta Básica Oprimir cualquier carácter o dígito

1. El Desarrollador oprime una tecla con carácter o dígito. 2. Se imprime el carácter asignado a la tecla presionada.


Editor Se debe codificar en el editor asignado.

Pre-Condición (Propuesto)

Funcionamiento Las teclas con caracteres y dígitos deben funcionar correctamente.


Nuevo carácter escrito Se imprime en el editor un nuevo carácter que forma parte de una línea.

C3. 1 Crear nueva línea Nombre del Caso de Uso:

C3.1 Crear nueva línea


Descripción: Cada carácter escrito para completar una línea que está siendo creada (no modificada).

Escenarios: Ruta Básica Línea nueva

1. El Desarrollador sitúa el cursor en una línea en blanco. 2. El Desarrollador presiona una tecla de carácter o dígito. 3. Se produce un carácter nuevo en una línea nueva.

Restricciones: Pre-Condición (Propuesto) Línea nueva Debe escribirse una línea que antes no existía.Pre-Condición (Propuesto) No remplazo Carácter o dígito nuevos, sin remplazar a otro. Post-Condición (Propuesto)

Carácter nuevo Un carácter o dígito nuevos, formando parte de una línea nueva.


56

C3. 2 Extender una línea existente Nombre del Caso de Uso:

C3.2 Extender una línea existente


Descripción: Se agregan caracteres a una línea previamente escrita, ya sea al inicio, en medio o al final de la misma.

Escenarios: Ruta Básica Extender línea existente

1. El Desarrollador sitúa el cursor en una línea existente. 2. El Desarrollador presiona una tecla con carácter o dígito. 3. El nuevo carácter se adhiere a la línea.

Restricciones: Pre-Condición (Propuesto) Línea existente El carácter o dígito debe escribirse en una línea

previamente escrita. Pre-Condición (Propuesto) No selección La línea no debe tener ningún código seleccionado

que pueda ser remplazado por el nuevo carácter. Pre-Condición (Propuesto) No Insert La función Insert (sobrescribir) no debe estar

activa. Post-Condición (Propuesto)

Línea extendida El nuevo carácter formará parte de la línea original.

C3.2. 1 Agregar código al inicio de una línea Nombre del Caso de Uso:

C3.2.1 Agregar código al inicio de una línea


Descripción: Agregar un carácter o dígito antes de una línea existente. Escenarios: Ruta Básica Agregar código al inicio

1. El Desarrollador sitúa el cursor al inicio de una línea existente. 2. El Desarrollador pulsa una tecla con carácter o dígito. 3. Se agrega un carácter o dígito antes de la línea original.

Restricciones: Pre-Condición (Propuesto) Cursor al inicio El cursor debe estar al inicio de la línea original. Post-Condición (Propuesto)

Nuevo carácter al inicio Se adhiere un nuevo carácter al inicio de la línea original.


57

C3.2. 2 Agregar código en medio de una línea Nombre del Caso de Uso:

C3.2.2 Agregar código en medio de una línea


Descripción: Agregar un carácter o dígito antes del inicio o después del final de una línea previamente escrita.

Escenarios: Ruta Básica Agregar código en medio

1. El Desarrollador sitúa el cursor dentro de la línea escrita. 2. El Desarrollador oprime una tecla con carácter o dígito. 3. Se produce un nuevo carácter dentro de la línea original.

Restricciones: Pre-Condición (Aprobado) Cursor en medio El cursor debe situarse después del inicio y antes

del final de la línea escrita. Post-Condición (Propuesto)

Nuevo carácter en medio Se escribe un nuevo carácter dentro de la línea original.

C3.2. 3 Agregar código al final de una línea Nombre del Caso de Uso:

C3.2.3 Agregar código al final de una línea


Descripción: Agregar un carácter o dígito después del final de una línea previamente escrita. Escenarios: Ruta Básica Agregar carácter al final

1. El Desarrollador sitúa el cursor después del final de una línea existente. 2. El Desarrollador oprime una tecla con carácter o dígito. 3. Se adhiere un carácter o dígito al final de la línea original.

Restricciones: Pre-Condición (Propuesto) Cursor al final El cursor debe situarse después del final de la

línea escrita. Post-Condición (Propuesto)

Nuevo carácter al final Se produce un nuevo carácter o dígito después de la línea original.


58

C3. 3 Remplazar código Nombre del Caso de Uso:

C3.3 Remplazar código


Descripción: Escribir un carácter o dígito en lugar de los que ya existen en una línea escrita. Ya sea remplazar (borrar y sustituir) un carácter por medio de la función Insert o uno o varios caracteres previamente seleccionados.

Escenarios: Ruta Básica Remplazo de caracteres

1. El Desarrollador activa la función Insert o selecciona código. 2. El Desarrollador oprime una tecla con carácter o dígito. 3. El nuevo carácter remplaza al código seleccionado.

Restricciones: Pre-Condición (Propuesto) Línea existente El cursor debe situarse dentro de una línea

previamente escrita. Pre-Condición (Propuesto) Insert o Selección La función Insert debe estar activada o parte del

código debe ser previamente seleccionado. Post-Condición (Propuesto)

Remplazo de caracteres Un nuevo carácter remplazará al o los caracteres afectados.

C3.3. 1 Remplazar código seleccionado Nombre del Caso de Uso:

C3.3.1 Remplazar código seleccionado


Descripción: Cuando se selecciona código, si se oprime una tecla con carácter o dígito, el código es remplazado por el nuevo carácter.

Escenarios: Ruta Básica Remplazar código seleccionado

1. El Desarrollador selecciona código. 2. El Desarrollador oprime una tecla con carácter o dígito. 3. El nuevo carácter o dígito remplaza el código seleccionado.

Restricciones: Pre-Condición (Propuesto) Seleccionar Código Debe haber código seleccionado antes de oprimir

cualquier tecla con carácter o dígito. Post-Condición (Aprobado)

Remplazo de código El nuevo carácter o dígito remplazará el código previamente seleccionado.


59

C3.3.1. 1 Remplazar una línea existente Nombre del Caso de Uso:

C3.3.1.1 Remplazar una línea existente


Descripción: Es posible que el código seleccionado abarque una o varias líneas, las cuales serán remplazadas por el nuevo carácter.

Escenarios: Ruta Básica Remplazo de línea

1. El Desarrollador selecciona una o varias líneas. 2. El Desarrollador oprime una tecla con carácter o dígito. 3. El nuevo carácter o dígito sustituye a la o las líneas seleccionadas.

Restricciones: Pre-Condición (Propuesto) Seleccionar código Debe haber código seleccionado antes de oprimir

cualquier tecla con carácter o dígito. Pre-Condición (Propuesto) Una o varias líneas

seleccionadas El código seleccionado debe abarcar una o varias líneas.


Remplazo de línea La o las líneas seleccionadas serán remplazadas por el nuevo carácter o dígito.

C3.3.1. 2 Remplazar líneas existentes y fragmento de línea Nombre del Caso de Uso:

C3.3.1.2 Remplazar líneas existentes y fragmento de línea


Descripción: Es posible que el código seleccionado abarque una o varias líneas además de un fragmento de otra línea, las cuales serán remplazadas por el nuevo carácter.

Escenarios: Ruta Básica Remplazo de líneas y fragmento

1. El Desarrollador selecciona una o varias líneas y fragmento de otra. 2. El Desarrollador oprime una tecla con carácter o dígito. 3. El código seleccionado es sustituido por el nuevo carácter.

Restricciones: Pre-Condición (Propuesto) Selección de código Debe seleccionarse código antes de oprimir tecla

con carácter o dígito. Pre-Condición (Propuesto) Seleccionar líneas y

fragmento Debe seleccionarse una o varias líneas y un fragmento de otra línea.


Remplazo de código La o las líneas mas el fragmento de línea seleccionados serán remplazados por el nuevo carácter.


60

C3.3. 2 Remplazar caracteres Nombre del Caso de Uso:

C3.3.2 Remplazar caracteres


Descripción: Cuando se activa la función Insert, si se presiona una tecla con carácter o dígito, se remplaza el carácter de la línea en curso por el nuevo.

Escenarios: Ruta Básica Remplazo de carácter

1. El Desarrollador activa la función Insert (sobrescribir). 2. El Desarrollador presiona una tecla con carácter o dígito. 3. Se remplaza un carácter con el nuevo.

Restricciones: Pre-Condición (Propuesto) Función Insert activada La función Insert debe estar en activo antes de

oprimir cualquier tecla de carácter o dígito. Post-Condición (Propuesto)

Remplazo de carácter El carácter al que apuntaba el cursor es remplazado por el nuevo carácter.

C 4 Accionar función ‘Insert’ Nombre del Caso de Uso:

C4 Accionar función 'Insert'


Descripción: La función Insert sustituye el carácter apuntado por el cursor por un nuevo carácter o dígito de la tecla que se oprima.

Escenarios: Ruta Básica Accionar función Insert

1. El Desarrollador verifica que la función Insert está desactivada. 2. El Desarrollador oprime la tecla Insert o activa la función en la interfaz de usuario. 3. La función de sobre escritura está activada.

Restricciones: Pre-Condición (Propuesto) Función utilizable La tecla Insert debe funcionar o la función Insert

debe ser accesible en la interfaz. Post-Condición (Propuesto)

Sobrescribir listo La función Insert o sobrescribir afectará al carácter apuntado por el cursor.

4.1.1.3 Suprimir y Retroceso Las teclas suprimir y retroceso se emplean para diversas tareas. Como se aprecia en la figura 4.3, estas tareas incluyen borrar una o más líneas completas (C5.1, C5.2), borrar un fragmento de línea (C5.3), borrar una o varias líneas con un fragmento (C5.4), borrar un carácter (C5.5) o unir dos líneas (C5.6).


61

uc Suprimir y Retroceso

C5 Oprimir teclas Suprimir o Retroceso

C5.1 Borrar línea completa

C5.2 Borrar v arias líneas

C5.3 Borrar fragmento de línea

C5.4 Borrar una o v arias líneas y un

fragmento

C5.5 Borrar un caracter

C5.5.1 Borrar único caracter existente

C5.5.2 Borrar uno y dejar más


C5.6 Unir dos líneas

C5.6.1 Unión con Suprimir

C5.6.2 Unión con Retroceso

A. Desarrollador

(from Estrategia)

«include»

«include»

«include»

«extend»

«extend»

«extend»

«extend» «extend»

«extend»«extend»

«include»

«extend»

«extend»

«extend»

Figura 4. 3 Suprimir y Retroceso.

A continuación se describe un ejemplo de los Casos de Uso relacionados y más adelante se muestran sus respectivos escenarios. Para C5.1 Borrar una línea completa, un ejemplo es:

public class Clase1 { String cadena1; String cadena2; }

que, al pulsar las teclas Suprimir o Retroceso, se convierte en


String cadena2; }


62

Un ejemplo para C5.2 Borrar varias líneas es:


dando como resultado:

public class Clase1 { }

Cuando se trata de C5.3 Borrar fragmento de línea, el ejemplo es:


dando como resultado

public class Clase1 { String ; String cadena2; }

Si el caso es C5.4 Borrar una o varias líneas y un fragmento, el ejemplo es:


dando como resultado

public class

Si lo que se pretende es borrar un solo carácter (C5.5 Borrar carácter), se puede

dar el caso de borrar el único carácter restante en una línea (C5.5.1 Borrar único carácter), por ejemplo:

public class Clase1 { String cadena1; S }



63

public class Clase1 { String cadena1; }

El caso más común para el borrado de un carácter es C5.5.2 Borrar uno y dejar

más en la línea. Ejemplo:



public class Clase1 { String cadena1; String cadena; }

Las teclas Suprimir y Retroceso pueden usarse para C5.6 Unir dos líneas, dependiendo de la posición del cursor (casos C5.6.1 y C5.6.2). Por ejemplo:


Dando como resultado:


Ahora se describen los escenarios asociados a cada Caso de Uso:


64

C 5 Oprimir teclas Suprimir o Retroceso Nombre del Caso de Uso:



Descripción: Las teclas Suprimir y Retroceso sirven para borrar código, la primera para borrar el carácter que se encuentra apuntado por el cursor y la segunda para eliminar el carácter anterior al apuntado por el cursor.

Escenarios: Ruta Básica Suprimir o Retroceso

1. El Desarrollador sitúa el cursor en o después del carácter a borrar. 2. El Desarrollador presiona la tecla Suprimir o Retroceso. 3. El carácter indicado es eliminado.


Funcionamiento Las teclas Suprimir y Retroceso deben funcionar correctamente.


Editor Se debe codificar dentro del editor del lenguaje o lenguajes seleccionados.


Código existente Debe de haber uno o más caracteres en el Editor.


Carácter borrado El carácter indicado será eliminado.

C5. 1 Borrar línea completa Nombre del Caso de Uso:

C5.1 Borrar línea completa


Descripción: Si al oprimir Suprimir o Retroceso está seleccionada una línea completa, ésta será eliminada.

Escenarios: Ruta Básica Borrar línea

1. El Desarrollador selecciona una línea completa. 2. El Desarrollador oprime la tecla Suprimir o Retroceso. 3. La línea seleccionada es eliminada.

Restricciones: Pre-Condición (Propuesto) Selección Debe haber código seleccionado. Pre-Condición (Propuesto) Línea seleccionada El código seleccionado debe abarcar una sola

línea completa. Post-Condición (Propuesto)

Línea borrada La línea seleccionada será eliminada después de oprimir Suprimir o Retroceso.


65

C5. 2 Borrar varias líneas Nombre del Caso de Uso:

C5.2 Borrar varias líneas


Descripción: Si al suprimir o retroceder (borrar) se encuentran varias líneas completas seleccionadas, éstas serán eliminadas.

Escenarios: Ruta Básica Borrar varias líneas

1. El Desarrollador selecciona dos o más líneas completas. 2. El Desarrollador oprime la tecla Suprimir o Retroceso. 3. Las líneas seleccionadas son eliminadas.

Restricciones: Pre-Condición (Propuesto) Selección Debe haber código seleccionado. Pre-Condición (Propuesto) Selección de varias líneas Dos o más líneas completas deben estar

seleccionadas. Post-Condición (Propuesto)

Borrar varias líneas Al oprimir Suprimir o Retroceso las líneas seleccionadas serán eliminadas.

C5. 3 Borrar fragmento de línea Nombre del Caso de Uso:

C5.3 Borrar fragmento de línea


Descripción: Si al suprimir o retroceder (borrar) hay un fragmento de línea seleccionado, éste será eliminado.

Escenarios: Ruta Básica Borrar fragmento de línea

1. El Desarrollador selecciona un fragmento de línea. 2. El Desarrollador oprime las teclas Suprimir o Retroceso. 3. El fragmento de línea es eliminado.

Restricciones: Pre-Condición (Propuesto) Selección Debe haber código seleccionado. Pre-Condición (Propuesto) Fragmento de línea

seleccionado Sólo un fragmento de una línea, sin incluir la línea completa, debe ser seleccionado.


Fragmento de línea borrado El fragmento de línea seleccionado será borrado al oprimir las teclas Suprimir o Retroceso.


66

C5. 4 Borrar una o varias líneas y un fragmento Nombre del Caso de Uso:

C5.4 Borrar una o varias líneas y un fragmento


Descripción: Si al oprimir las teclas Suprimir o Retroceso hay una o varias líneas y un fragmento seleccionados, estos serán eliminados.

Escenarios: Ruta Básica Borrar una o varias líneas y un fragmento

1. El Desarrollador selecciona una o varias líneas y un fragmento de código. 2. El Desarrollador oprime las teclas Suprimir o Retroceso. 3. El código seleccionado es eliminado.

Restricciones: Pre-Condición (Propuesto) Selección Debe haber código seleccionado. Pre-Condición (Propuesto) Una o varias líneas más un

fragmento Deben seleccionarse una o varias líneas completas más un fragmento de código.


Una o varias líneas y un fragmento borrados

Al oprimir las teclas Suprimir o Retroceso, la(s) línea(s) y el fragmento seleccionados serán eliminados.

C5. 5 Borrar un carácter Nombre del Caso de Uso:

C5.5 Borrar un carácter


Descripción: Si al oprimir las teclas Suprimir o Retroceso no existe ningún código seleccionado, el carácter indicado por el cursor será eliminado.

Escenarios: Ruta Básica Borrar un carácter

1. El Desarrollador sitúa el cursor dentro de una línea. 2. El Desarrollador oprime las teclas Suprimir o Retroceso. 3. Un carácter el eliminado.

Restricciones: Pre-Condición (Propuesto) No selección No debe haber ningún código seleccionado. Pre-Condición (Propuesto) Carácter borrado El carácter indicado por el cursor (en el caso de

Suprimir) o el carácter anterior al cursor (para Retroceso) serán eliminados.


67

C5.5. 1 Borrar único carácter existente Nombre del Caso de Uso:

C5.5.1 Borrar único carácter existente


Descripción: Es posible que después de borrar varios caracteres en una línea sólo quede un carácter en ella, que también vaya a ser borrado mediante Suprimir o Retroceso.

Escenarios: Ruta Básica Borrar único carácter en línea

1. El Desarrollador sitúa el cursor en el único carácter restante de una línea. 2. El Desarrollador oprime las teclas Suprimir o Retroceso. 3. El carácter es eliminado. 4. Se produce una línea en blanco.

Restricciones: Pre-Condición (Propuesto) Un solo carácter Debe haber un solo carácter o dígito en la línea. Post-Condición (Propuesto)

Línea en blanco El carácter restante será eliminado y se producirá una línea en blanco.

C5.5. 2 Borrar uno y dejar más Nombre del Caso de Uso:

C5.5.2 Borrar uno y dejar más


Descripción: Cada vez que se borra un carácter en una línea, existen otros más que se mantienen en ella hasta que sólo resta uno en la línea.

Escenarios: Ruta Básica Borrar uno y dejar más

1. El Desarrollador sitúa el cursor en el carácter a eliminar dentro de una línea con dos o más caracteres. 2. El Desarrollador oprime las teclas Suprimir o Retroceso. 3. El carácter es eliminado. 4. La línea uno o más caracteres.

Restricciones: Pre-Condición (Propuesto) Dos o más caracteres Debe haber dos o más caracteres en la línea en la

que se borra. Post-Condición (Propuesto)

Carácter eliminado El carácter indicado será borrado, dejando los restantes en la línea.


68

C5. 6 Unir dos líneas Nombre del Caso de Uso:

C5.6 Unir dos líneas


Descripción: Si el cursor se sitúa al inicio de una línea (en el caso de Retroceso) o después del final de ella (para Suprimir) y no existen líneas en blanco antes o después de la línea en curso, se unirán dos líneas existentes.

Escenarios: Ruta Básica Unión de líneas

1 El Desarrollador sitúa el cursor en el extremo de una línea. 2 El Desarrollador oprime las teclas Suprimir o Retroceso. 3 La línea se une a su antecesora o predecesora.

Restricciones: Pre-Condición (Propuesto) Inicio o fin de línea El cursor debe situarse al inicio o después del fin

de una línea. Pre-Condición (Propuesto) Línea escritas antes o

después Debe haber una línea inmediatamente antes o después de la línea en curso (no línea en blanco), según la tecla que se oprima.


Unión de líneas La línea en curso y su línea anterior o siguiente (dependiendo de la tecla oprimida) serán unidas.

C5.6. 1 Unión con Suprimir Nombre del Caso de Uso:

C5.6.1 Unión con Suprimir


Descripción: Si al oprimir la tecla Suprimir el cursor se encuentra delante del último carácter de una línea escrita, la línea escrita siguiente (no blanca) se unirá a la primera formando una sola línea.

Escenarios: Ruta Básica Unión con Suprimir

1. El Desarrollador sitúa el cursor después del final de la línea. 2. El Desarrollador oprime la tecla Suprimir. 3. La línea siguiente se desplaza hacia arriba. 4. Las dos líneas se unen.

Restricciones: Pre-Condición (Propuesto) Línea escrita siguiente Debe haber una línea escrita (no blanca)

inmediatamente después del salto de línea. Pre-Condición (Propuesto) Cursor después del final El cursor debe estar situado después del último

carácter de la línea. Post-Condición (Propuesto)

Recorrido hacia arriba La línea siguiente es desplazada hacia arriba, a la misma altura de la línea en curso.


Unión de líneas La línea actual y su línea siguiente estarán unidas en una sola línea.


69

C5.6. 2 Unión con Retroceso Nombre del Caso de Uso:

C5.6.2 Unión con Retroceso


Descripción: Si al oprimir la tecla Retroceso el cursor se encuentra en el primer carácter de una línea escrita, la línea se unirá a la anterior (no blanca) formando una sola línea.

Escenarios: Ruta Básica Unión con Retroceso

1. El Desarrollador sitúa el cursor al inicio de la línea. 2. El Desarrollador oprime la tecla Retroceso. 3. La línea se desplaza hacia arriba. 4. La línea se une con la línea anterior.

Restricciones: Pre-Condición (Propuesto) Línea escrita anterior Debe haber una línea escrita (no blanca) anterior a

la línea donde se encuentra el cursor. Pre-Condición (Propuesto) Cursor al inicio El cursor debe situarse al inicio de una línea. Post-Condición (Propuesto)

Recorrido hacia arriba La línea en curso es desplazada hacia arriba donde se encuentra su línea anterior.


Unión de líneas Las líneas en cuestión (afectada y anterior) se unen en una sola línea en el lugar de la anterior.

4.1.1.4 Punto y Coma La figura 4.4 muestra los casos de uso para un Desarrollador que oprime la tecla punto y coma: C6.1 Finalizar Instrucción y C6.2 Puntuar una cadena de texto.

uc Punto y coma

C6 Oprimir punto y coma

C6.1 Finalizar instrucción

C6.2 Puntuar una cadena de texto

Desarrollador

(from Casos de Uso Codificación)

«extend»

«extend»

Figura 4. 4 Punto y coma


70

A continuación se describe un ejemplo de los Casos de Uso relacionados y más adelante se muestran sus respectivos escenarios. Para C6.1 Finalizar una instrucción un ejemplo común es:

String cadena2;

Cuando se trata de C6.2 Puntuar una cadena de texto, es posible teclear: System.out.println("El delimitador es un ;");

Ahora se describen los escenarios asociados a cada Caso de Uso: C 6 Oprimir punto y coma Nombre del Caso de Uso:

C6 Oprimir punto y coma


Descripción: Delimitador de instrucciones en java y otros lenguajes (;). Escenarios: Ruta Básica Punto y coma

1. El Desarrollador escribe código. 2. El Desarrollador oprime la tecla ';' 3. El ';' se imprime en el código.


Editor Se debe codificar dentro del editor.


Funcionamiento La tecla ';' debe funcionar correctamente.


Imprime punto y coma Se imprime el signo ';' en el editor.

C6. 1 Finalizar instrucción Nombre del Caso de Uso:

C6.1 Finalizar instrucción


Descripción: El ';' es usado para finalizar una instrucción en diversos lenguajes de programación. Escenarios: Ruta Básica Finalizar instrucción

1. El Desarrollador oprime ';' al finalizar una cadena de caracteres. 2. Se imprime un ';'

Restricciones: Pre-Condición (Propuesta) No cadena El ';' debe estar fuera de una cadena de texto, es

decir, no debe estar dentro de un par de comillas (").


71

C6. 2 Puntuar una cadena de texto Nombre del Caso de Uso:

C6.2 Puntuar una cadena de texto


Descripción: Puede estar contenido dentro de una cadena. Ej. System.out.println("El delimitador es un ;");

Escenarios: Ruta Básica Puntuar cadena

1. El Desarrollador codifica la impresión de una cadena de texto (abre comillas). 2. El Desarrollador oprime la tecla ';'. 3. Se imprime ';'.

Restricciones: Pre-Condición (Propuesta) Cadena de texto El ';' debe estar contenido dentro de un par de

comillas ("), indicando que se encuentra en una cadena de texto.

4.1.2 Métodos del IDE Los ambientes de desarrollo cuentan con funciones específicas para la generación automática de código, así como para la eliminación del mismo, mediante el uso de asistentes, formularios y acciones sobre paneles con características de proyectos (clases, funciones, atributos). También se incluyen funciones para el almacenamiento de los proyectos y archivos en curso (guardar, crear, eliminar).

4.1.2.1 Deshacer y Rehacer acciones La figura 4.5 muestra los casos de uso para un Desarrollador que utiliza las funciones Deshacer o Rehacer. La forma en que generalmente es posible deshacer y rehacer en un editor es mediante el uso de pilas en donde se acumulan las últimas acciones del Desarrollador; así, cuando se llama a la función Deshacer (C7), el sistema recurre a la pila correspondiente y saca de ahí los datos necesarios para eliminar el último cambio, removiendo esta información de la pila de Deshacer para llevarla a la pila de Rehacer. De esta forma, si se desea restaurar una acción previamente deshecha, se llama a la función de Rehacer (C8) y se toma la información de la pila correspondiente, llevándola de nuevo a la pila de Deshacer.


72

uc Deshacer y Rehacer acciones

C7 Llamar a función de Deshacer

C8 Llamar a función de RehacerA. Desarrollador

(from Estrategia)

Figura 4. 5 Deshacer y Rehacer acciones.

A continuación se describe un ejemplo de los Casos de Uso relacionados y más adelante se muestran sus respectivos escenarios. Suponiendo que en el código siguiente se acaban de agregar algunos caracteres,


si se llama a la función Deshacer, el resultado es

public class Clase1 { String cadena1; String }

se puede Rehacer la acción deshecha, obteniendo nuevamente


Ahora se describen los escenarios asociados a cada Caso de Uso.

Última acción


73

C 7 Llamar a función de Deshacer Nombre del Caso de Uso:

C7 Llamar a función de Deshacer


Descripción: a) Desecha el último cambio realizado en el código. Por ejemplo: - Inserción de código. - Borrado de código. - Generación de código por asistentes. - Borrado de código por asistentes. - Modificación de código (formato, cambio en líneas). b) No es posible deshacer la creación de un proyecto.

Escenarios: Ruta Básica Deshacer última acción

1. El Desarrollador realiza una acción en el editor. 2. El Desarrollador llama a la función Deshacer. 3. La última acción se deshace.

Restricciones: Pre-Condición (Propuesto) Acciones realizadas Debe haber alguna acción anterior qué deshacer. Post-Condición (Propuesto)

Acción deshecha La última acción realizada es deshecha y el código vuelve a una fase anterior.

C 8 Llamar a función de Rehacer Nombre del Caso de Uso:

C8 Llamar a función de Rehacer


Descripción: a) Revierte una acción de Deshacer. Ejemplo: - Inserción de código. - Borrado de código. - Generación de código por asistentes. - Borrado de código por asistentes. - Modificación de código (formato, cambio en líneas).

Escenarios: Ruta Básica Rehacer última acción

1. El Desarrollador deshace una acción. 2. El Desarrollador llama a la función Rehacer. 3. La última acción deshecha es restaurada.

Restricciones: Pre-Condición (Aprobado) Deshacer primero Debe existir al menos una acción deshacer

primero. Post-Condición (Propuesto)

Rehacer última acción La última acción deshecha se restaura.


74

4.1.2.2 Asistentes y paneles Cuando se utilizan asistentes y paneles para el desarrollo de un producto de software, es evidente que se genera código automáticamente. La figura 4.6 muestra los casos en los que se emplean estas herramientas en un ambiente de desarrollo.

Mediante el uso de asistentes y paneles, es posible generar clases (C9), métodos (C10), atributos (C11) para cada clase, así como borrar clases y métodos (C12 y C13, respectivamente).

uc Asistentes y paneles

C9 Generar clases

C10.1 Generar métodos con

asistente

C10 Generar métodos

C10.2 Generar métodos get y set

C11 Generar atributos

C12 Borrar Clase

C13 Borrar método

A. Desarrollador

(from Estrategia)

«extend»

«extend»

Figura 4. 6 Asistentes y paneles.



75

C 9 Generar clases Nombre del Caso de Uso:

C9 Generar clases


Descripción: Mediante un asistente, el Desarrollador puede crear clases expresando su nombre, tipo, herencia, entre otros. Lo que resulta en la generación automática de código con dichas características.

Escenarios: Ruta Básica Generar clase

1. El Desarrollador abre el asistente para generar clases. 2. El Desarrollador introduce los datos solicitados por el asistente. 3. Se genera el código de una nueva clase en el editor.

Restricciones: Pre-Condición (Propuesto) Parámetros válidos La información introducida en el asistente debe

ser válida (nombre de clase, clase Padre existente, etc.).


Clase Generada El código referente a una nueva clase es arrojado al editor con los parámetros especificados en el asistente.

C 10 Generar métodos Nombre del Caso de Uso:

C10 Generar métodos


Descripción: Se pueden generar métodos de una clase mediante el uso de asistentes (wizards) del IDE que solicitan ciertos parámetros o a través de opciones como la de generación automática de métodos get y set.

Escenarios: Ruta Básica Generar método

1. El Desarrollador elige una forma de generar un método. 2. El Desarrollador lleva a cabo la generación mediante la opción seleccionada. 3. Se genera código con el método especificado.

Restricciones: Pre-Condición (Propuesto) Clase existente Antes de crear un método se debe tener una clase

que lo contenga. Post-Condición (Propuesto)

Método creado Generación de código con el método especificado.


76

C10. 1 Generar métodos con asistente Nombre del Caso de Uso:

C10.1 Generar métodos con asistente


Descripción: Mediante un asistente, el Desarrollador puede crear métodos expresando su nombre, clase contenedora, entre otros. Lo que resulta en la generación automática de código con dichas características.

Escenarios: Ruta Básica Generar métodos

1. El Desarrollador abre un asistente para crear un método de una clase. 2. El Desarrollador inserta los parámetros requeridos por el asistente. 3. El código del método es arrojado al editor.

Restricciones: Pre-Condición (Propuesto) Parámetros válidos La información introducida en el asistente debe

ser válida (nombre de método, clase contenedora, etc.).

Pre-Condición (Propuesto) Nuevo método El código referente a un nuevo método es arrojado al editor con los parámetros especificados en el asistente.

C10. 2 Generar métodos get y set Nombre del Caso de Uso:

C10.2 Generar métodos get y set


Descripción: Los métodos get y set de los atributos de una clase pueden generarse automáticamente.

Escenarios: Ruta Básica Métodos get y set

1. El Desarrollador define y codifica los atributos de una clase. 2. El Desarrollador llama a la función del IDE de creación de métodos get y set. 3. El código de los métodos get y set es arrojado al editor.

Restricciones: Pre-Condición (Propuesto) Atributos existentes Al menos un atributo debe existir para generar sus

métodos get y set. Post-Condición (Propuesto)

Métodos creados Métodos get y set de los atributos de la clase generados.


77

C 11 Generar atributos Nombre del Caso de Uso:

C11 Generar atributos


Descripción: Algunos IDEs presentan la opción de crear atributos de clases mediante asistentes, lo que lleva a la generación automática de código.

Escenarios: Ruta Básica Generación de atributos

1. El Desarrollador inicia el asistente para creación de atributos. 2. El Desarrollador especifica los atributos en el asistente. 3. El código de los atributos es arrojado al editor.

Restricciones: Pre-Condición (Propuesto) Parámetros válidos Los parámetros introducidos en el asistente deben

ser válidos con respecto a la especificación de un atributo de clase.


Generación de atributos El código para la declaración de atributos es arrojado al editor.

C 12 Borrar clase Nombre del Caso de Uso:

C12 Borrar clase


Descripción: Una clase puede ser eliminada por completo mediante una función de borrado del ambiente de programación. Lo que supone una eliminación automática de código fuente (generado y escrito).

Escenarios: Ruta Básica Borrar clase

1. El Desarrollador selecciona la clase a eliminar. 2. El Desarrollador llama a la función Eliminar clase del IDE. 3. La clase seleccionada es eliminada junto con sus métodos y atributos.

Restricciones: Pre-Condición (Propuesto) Clase existente La clase que se quiere eliminar debe existir en el

código. Pre-Condición (Propuesto) Clase eliminada La clase seleccionada para borrarse se eliminará

por completo, incluyendo su código interno (métodos y atributos).


78

C 13 Borrar método Nombre del Caso de Uso:

C13 Borrar método


Descripción: Se pueden borrar métodos de clase a través de funciones de eliminación automática de los ambientes de programación. Se borra código generado y escrito.

Escenarios: Ruta Básica Borrar método

1. El Desarrollador selecciona el método a eliminar. 2. El Desarrollador llama a la función de borrado del IDE. 3. El método seleccionado es eliminado completamente, incluido su código interno.

Restricciones: Pre-Condición (Propuesto) Método existente El método a eliminar debe existir en el código. Post-Condición (Propuesto)

Método eliminado El método seleccionado es eliminado del código.

4.1.2.3 Formularios De la misma forma que el uso de asistentes y paneles, el uso de formularios implica generación automática de código. La figura 4.7 muestra los Casos de Uso para un Desarrollador que utiliza formularios para generar o modificar código.


79

uc Formularios

C14 Agregar componentes de

formulario

C15 Modificar componente en

formulario

C15.1 Modificar componente en

Propiedades

C15.2 Modificar componente desde

código

C16 Borrar componente

C16.1 Borrar del formulario o panel

C16.2 Borrar desde código

(from Teclas que influyen en un IDE)



C1.4 Borrar código

A. Desarrollador

(from Estrategia)


«extend»

«extend»

«extend»

«extend»

Figura 4.7 Formularios.



80

C 14 Agregar componentes de formulario Nombre del Caso de Uso:

C14 Agregar componentes de formulario


Descripción: Cuando un IDE presenta de manera visual componentes para crear Interfaces gráficas de usuario, al agregarse estos componentes a un formulario se genera código automáticamente.

Escenarios: Ruta Básica Generar Componente de formulario

1. El Desarrollador crea un formulario para interfaz de usuario. 2. El Desarrollador agrega un componente al formulario. 3. El código del componente es arrojado al editor.

Restricciones: Pre-Condición (Propuesto) Formularios habilitados El ambiente de desarrollo debe contar con

formularios visuales para la creación de Interfaces gráficas con el usuario.


Código de componente El Código del componente añadido al formulario es generado.

Pre-Condición (Propuesto) Clase existente La clase que contendrá el código de los componentes ya debió ser creada (los IDEs ya manejan esta pre-condición).

C 15 Modificar componente en formulario Nombre del Caso de Uso:

C15 Modificar componente en formulario


Descripción: Luego de insertarse un componente en el formulario, es decir, ya que se generó su código es posible editar las Propiedades de dicho componente, como su nombre, coordenadas, tamaño, entre otros, modificaciones que se verán reflejadas en el código.

Escenarios: Ruta Básica Modificar componente

1. El Desarrollador Crea un Componente. 2. El Desarrollador edita las Propiedades del componente. 3. El código es modificado según las nuevas características.


Componente creado El componente a editar debe haber sido previamente creado.


Modificaciones El código del componente es cambiado con las nuevas características.


81

C15. 1 Modificar componente en Propiedades Nombre del Caso de Uso:

C15.1 Modificar componente en Propiedades


Descripción: Es posible modificar las características de un componente desde el cuadro de Propiedades proporcionado por el IDE.

Escenarios: Ruta Básica Modificar componente en

Propiedades 1. El Desarrollador abre/localiza el cuadro de Propiedades del componente en el IDE. 2. El Desarrollador modifica las Propiedades del componente. 3. El código es modificado según las nuevas Propiedades.

Ruta Básica Modificar componente en Propiedades

1. El Desarrollador abre/localiza el cuadro de Propiedades del componente en el IDE.2. El Desarrollador modifica las Propiedades del componente. 3. El código es modificado según las nuevas Propiedades.

Restricciones: Pre-Condición (Propuesto) Componente creado Las Propiedades a editar deben pertenecer a un

componente existente en el formulario. Pre-Condición (Propuesto) Componente modificado El código del componente es cambiado de

acuerdo a las nuevas Propiedades.

C15. 2 Modificar componente desde código Nombre del Caso de Uso:

C15.2 Modificar componente desde código


Descripción: Es posible modificar las características del componente directamente en el código. Escenarios: Ruta Básica Modificar desde código

1. El Desarrollador localiza en el código el componente y la propiedad a modificar. 2. El Desarrollador modifica la propiedad del componente. 3. El componente es modificado.

Restricciones: Pre-Condición (Propuesto) Componente existe Las Propiedades a editar deben pertenecer a un

componente existente en el formulario. Post-Condición (Propuesto)

Componente modificado Las características del componente cambian.


82

C 16 Borrar componente Nombre del Caso de Uso:

C16 Borrar componente


Descripción: Es posible eliminar un componente del formulario ya sea desde el editor de código o desde el formulario.

Escenarios: Ruta Básica Borrar componente

1. El Desarrollador localiza el componente a eliminar. 2. El Desarollador ejecuta un método de eliminación. 3. El componente es borrado.

Restricciones: Pre-Condición (Propuesto) Componente creado El componente debe existir antes de ser

eliminado. Post-Condición (Propuesto)

Componente eliminado El componente es eliminado totalmente.

C16. 1 Borrar del formulario o panel Nombre del Caso de Uso:

C16.1 Borrar del formulario o panel


Descripción: Un componente puede ser eliminado desde el formulario o desde el panel de componentes.

Escenarios: Ruta Básica Borrar del formulario o panel

1. El Desarrollador selecciona el componente a borrar. 2. El Desarrollador llama a la función eliminar componente. 3. El componente es eliminado.

Restricciones: Pre-Condición (Propuesto) Componente creado El componente debe existir antes de ser eliminadoPost-Condición (Propuesto)

Componente eliminado El componente seleccionado es eliminado del formulario y del código


83

C16. 2 Borrar desde código Nombre del Caso de Uso:

C16.2 Borrar desde código


Descripción: Es posible borrar un componente desde código si se siguen las acciones descritas en los casos de borrado (incluidos en los diagramas 'Uso de salto de línea' - caso C1.4 - y 'Suprimir y Retroceso').

Escenarios: Ruta Básica Borrar componente desde código

1. El Desarrollador localiza el componente a borrar. 2. El Desarrollador selecciona el código del componente a borrar. 3. El Desarrollador presiona Enter, Suprimir, Retroceso o Barra espaciadora. 4. El componente es eliminado.

Alterno Borrar cada carácter

1. El Desarrollador localiza el componente a borrar. 2. El Desarrollador presiona Suprimir o Retroceso en repetidas ocasiones hasta borrar todo el código del componente 3. El componente es eliminado.

Restricciones: Pre-Condición (Propuesto) Componente creado El componente debe existir previamente. Pre-Condición (Propuesto) Borrar todo Todo el código correspondiente al

componente a borrar debe ser eliminado. Post-Condición (Propuesto) Componente borrado El componente seleccionado es

eliminado.

4.1.2.4 Acciones con el ratón Con el ratón se realizan diversas acciones en el editor de código. La figura 4.8 muestra las más importantes. Estas acciones sirven para elegir las llamadas a funciones que se aplican sobre el código seleccionado en el editor, como son Copiar (C17) o Mover código (C18 y C17.1).


84

uc Acciones con el ratón

C17 Copiar selección



C18 Cortar código

C17.1 Pegar código

C19 Arrastrar código

A. Desarrollador

(from Estrategia)

«include»

«include»

«include»

«extend»

«extend»

«include»

Figura 4. 8 Acciones con el ratón.

Ahora se describen los escenarios asociados a cada Caso de Uso. C 17 Copiar selección Nombre del Caso de Uso:

C17 Copiar selección


Descripción: El código seleccionado es almacenado en un búfer para su posterior duplicación. Escenarios: Ruta Básica Copiar código seleccionado

1. El Desarrollador selecciona código. 2. El Desarrollador llama a la función Copiar. 3. El código se encuentra listo para duplicarse.

Restricciones: Pre-Condición (Propuesto) Código seleccionado Para Copiar, debe existir código seleccionado (un

componente en un formulario también cuenta como código seleccionado).

Pre-Condición (Aprobado) Selección para Copiar El código seleccionado se carga en el búfer para ser duplicado.


85

C17. 1 Pegar código Nombre del Caso de Uso:

C17.1 Pegar Código


Descripción: El código contenido en el búfer tras el llamado de la función Copiar (C18) o Cortar (C19) es insertado en el lugar que indique el cursor (o puntero del ratón).

Escenarios: Ruta Básica Pegar código copiado o cortado

1. El Desarrollador copia o corta el código seleccionado. 2. El Desarrollador elige un lugar para pegar el código. 3. El Desarrollador llama a la función de pegar del IDE. 4. El código copiado o cortado es insertado en la posición elegida por el Desarrollador.

Restricciones: Pre-Condición (Propuesto) Código en búfer Debe existir un fragmento de código almacenado

mediante la acción de Copiar o Cortar. Post-Condición (Propuesto)

Código pegado El código contenido en el búfer es arrojado al editor en la posición del cursor o puntero.

C 18 Cortar código Nombre del Caso de Uso:

C18 Cortar código


Descripción: Al igual que Copiar (C18), el código seleccionado es almacenado en un búfer al elegir la opción Cortar para ser movido, con la diferencia de que el código elegido es eliminado de su lugar original.

Escenarios: Ruta Básica Cortar código

1. El Desarrollador selecciona el código a Cortar. 2. El Desarrollador llama a la función Cortar. 3. El código es almacenado en el búfer y se elimina de su ubicación.

Restricciones: Pre-Condición (Propuesto) Código seleccionado El código a Cortar debe ser seleccionado antes de

ser cortado. Post-Condición (Propuesto)

Código cortado El código seleccionado es almacenado en el búfer y eliminado de su lugar original.


86

C 19 Arrastrar código Nombre del Caso de Uso:

C19 Arrastrar código


Descripción: El código seleccionado puede ser arrastrado a otro lugar, esto es, cambiado de lugar mediante las funciones Cortar-pegar, pero en un solo movimiento del ratón.

Escenarios: Ruta Básica Arrastre de código

1. El Desarrollador selecciona el código a mover. 2. El Desarrollador pulsa el botón izquierdo del ratón. 3. Sin soltar el botón izquierdo del ratón, el Desarrollador mueve el puntero hasta el lugar deseado. 4. El Desarrollador suelta el botón. 5. El código seleccionado es cortado de su lugar original y replicado en la posición del puntero.

Restricciones: Pre-Condición (Propuesto) Código seleccionado El código a mover debe estar seleccionado. Pre-Condición (Propuesto) Arrastre El botón izquierdo del ratón debe mantenerse

presionado y el puntero moviéndose para considerarse arrastre.


Código movido El código arrastrado es cambiado de su lugar original.

4.1.2.5 Opciones de archivo El código de un proyecto se encuentra en uno o más archivos que son creados desde el inicio. Los cambios que realiza un desarrollador en un IDE deben ser guardados para que tomen efecto. La figura 4.9 muestra las opciones que se tienen para tratar los archivos de un proyecto.


87

uc Opciones de archiv o

C20 Nuev o proyecto/archiv o

C21 Guardar Proyecto/Archiv o

C22 Guardar proyecto/archiv o

como...

C23 Eliminar

A. Desarrollador

(from Estrategia)

Figura 4. 9 Opciones de archivo.



88

C 20 Nuevo proyecto/archivo Nombre del Caso de Uso:

C20 Nuevo Proyecto/Archivo


Descripción: Para crear un nuevo archivo o proyecto es necesario elegir la función Nuevo del IDE. Esta opción no genera código por sí sola, pero es indispensable para contener al mismo.

Escenarios: Ruta Básica Crear proyecto/archivo

1. El Desarrollador abre el asistente para nuevo proyecto/archivo. 2. El Desarrollador escoge el tipo de proyecto o archivo a crear. 3. El Desarrollador especifica las características del proyecto/archivo 4. El proyecto/archivo está creado.


Nombre válido El nombre y las características para cada archivo/proyecto deben ser válidos.


Proyecto/Archivo creado El proyecto o archivo son creados y están listos para ser utilizados.

C 21 Guardar proyecto/archivo Nombre del Caso de Uso:

C21 Guardar Proyecto/Archivo


Descripción: Cada proyecto y archivo debe ser guardado periódicamente para poder ser utilizado. Los cambios hechos en los mismos tomarán efecto hasta que esta acción sea ejecutada (además de la compilación, en los lenguajes que es necesaria).

Escenarios: Ruta Básica Guardar proyecto/archivo

1. El Desarrollador crea/modifica un proyecto/archivo. 2. El Desarrollador llama a la función de guardar proyecto/archivo. 3. El proyecto/archivo es guardado, sobrescribiendo la información de los archivos con el mismo nombre.


Proyecto/archivo existente Debe existir un proyecto/archivo para guardar.


Proyecto/archivo guardado Los cambios más recientes son guardados (sobrescritos) en el proyecto/archivo con el mismo nombre.


89

C 22 Guardar proyecto/archivo como… Nombre del Caso de Uso:

C22 Guardar proyecto/archivo como...


Descripción: El proyecto o archivo pueden guardarse con otros nombres, ya sea que tengan cambios o no, la información contenida es almacenada en nuevos archivos, es decir, la información original es duplicada y la restante es guardada, ambas en un archivo diferente al inicial.

Escenarios: Ruta Básica Guardar como...

1. El Desarrollador crea/modifica un proyecto/archivo. 2. El Desarrollador llama a la función de guardar como... para el proyecto/archivo. 3. El proyecto/archivo es guardado con otros nombres, conteniendo la información original más los últimos cambios.


Proyecto/archivo existente El proyecto/archivo a guardar debe ser creado antes de ser guardado.


Proyecto/archivo guardado El proyecto/archivo es guardado con un nombre diferente al original, en caso de conservar el nombre, los archivos serán sobrescritos.

C23 Eliminar Nombre del Caso de Uso:

C23 Eliminar


Descripción: Un archivo o proyecto pueden ser eliminados, suprimiendo con ellos el código que contienen.

Escenarios: Ruta Básica Eliminar

1. El Desarrollador elige el proyecto/código a borrar. 2. El Desarrollador llama a la función Eliminar del IDE. 3. El proyecto/archivo elegido es eliminado junto con el código contenido en él.


Proyecto/archivo existente El proyecto/archivo a eliminar debe haber sido creado anteriormente.


Proyecto/archivo eliminado El proyecto/archivo seleccionado es eliminado junto con su código.


90

4.2 Conclusión Se identificaron y definieron 56 Casos de Uso de codificación en ambientes de desarrollo integrado y sus respectivos escenarios. Aunque se pensó que estos casos podrían producir cambios en la clasificación de las líneas de código dentro de un proyecto de software, no todos los aquí descritos afectan directamente una línea de código al grado de cambiar su tipo; sin embargo, son parte de los hábitos de codificación de un usuario del ambiente de desarrollo y fue necesario que se tomaran en cuenta para su análisis. Con esta información y, en conjunto con la obtenida en el Capítulo 3 (Tipos de líneas producidas en un IDE), se puede definir una estrategia de líneas de código que cumpla con el objetivo de esta investigación.

En el siguiente capítulo se define una Estrategia de Conteo para asignar los tipos de líneas de código definidos en el Capítulo 3 a los eventos provocados por los escenarios descritos en el Capítulo 4, realizando esta tarea en tiempo de codificación y de manera semiautomática.

Capítulo 5 Estrategia de Conteo

91


Luego de estudiar los escenarios de codificación presentados en el capítulo anterior y tomando en cuenta los tipos de línea definidos en el Capítulo 3, se dedujo una estrategia de conteo de líneas de código fuente, la cual es utilizable en ambientes de desarrollo integrado en la fase de codificación de un proyecto.

La primera parte de este capítulo describe brevemente las estrategias que no cubrieron las expectativas de la investigación, presentando las causas que originaron sus fallas. En la segunda parte se describe la Estrategia de Conteo, a la que se llegó al hacer el estudio de los escenarios de Codificación en los ambientes de desarrollo integrado. Por último, en la tercera parte se presentan los Casos de Uso de una herramienta que implementa la Estrategia definida, así como los escenarios correspondientes a cada caso.


92

5.1 Estrategias descartadas Según la Real Academia de la Lengua Española, una estrategia es un “conjunto de las reglas que aseguran una decisión óptima en cada momento” [RAE07]. Esta definición se toma como válida para usarse en esta investigación puesto que, para realizar un conteo de líneas de código en un IDE, es necesario tomar decisiones de acuerdo a la ocurrencia de un evento y, por tanto, se deben seguir ciertas reglas que aseguren la consecución de tal fin. En pocas palabras, hay que seguir una estrategia para hacer una buena clasificación y conteo de líneas de código. Para este trabajo se buscó una estrategia que cubriera tres elementos básicos:

1. Identificación de LOC tradicionalmente utilizadas para el conteo (base, nuevas, cambiadas, borradas)

2. Identificación líneas generadas automáticamente, las líneas copiadas y las reusadas4.

3. Mínima intervención del usuario para la identificación de los tipos de línea producidos al codificar.

La estructura para representar una estrategia en esta investigación es: 1. Idea inicial. Descripción de la posible manera de cubrir los tres elementos

descritos. 2. Reglas. Descripción de criterios que se deben considerar para llevar a cabo la

idea inicial. 3. Riesgos. Descripción de los riesgos o problemas inminentes que pueden poner

en peligro el éxito de la estrategia. 4. Elementos cubiertos. Mención de los elementos básicos que cubre la estrategia. Antes de llegar a definir la Estrategia de Conteo final, se idearon otras estrategias

que pretendían cubrir las necesidades del conteo de líneas de código en fase de codificación; sin embargo, al elaborarlas se presentaron riesgos importantes que impidieron la consecución de los elementos básicos especificados, lo que provocó que se buscaran estrategias alternas que sí cumplieran con estos elementos básicos5. A continuación se describe brevemente cada una de las estrategias descartadas junto con los problemas que conlleva cada una de ellas. 4 Aunque las líneas reusadas son habitualmente consideradas en las métricas de tamaño por líneas de código, las herramientas que automatizan este proceso no son capaces de identificarlas actualmente, por ello es que no se consideran en este trabajo dentro de las LOC tradicionalmente usadas. 5 Las estrategias descartadas y sus problemas se explican a detalle en el Apéndice D.


93

5.1.1 Estrategia inicial: Marcado de texto Idea inicial. Mediante marcado de texto, llevar una bitácora de cambios en el

código, registrada a partir de eventos ocurridos en el ambiente de programación. Reglas.

- Utilizar marcado de texto para la clasificación de las líneas de código. - Crear una bitácora de codificación donde se haga una copia de cada línea de código

en un proyecto, en el momento en que son escritas, generadas automáticamente o copiadas-pegadas, especificando su tipo.

- Llevar un registro de los eventos ocurridos en el IDE para detectar posibles cambios en cada línea.

Riesgos. No existe un estándar de generación automática de código, por lo que las

formas de generación son muchas y muy variadas dentro de un ambiente de desarrollo, lo que dificulta enormemente hacer una clasificación automática de líneas de código generadas automáticamente en el instante en que fueron creadas.6

Elementos cubiertos. Con esta estrategia es posible identificar las líneas

tradicionales (elemento 1) y se minimiza la intervención del usuario en el conteo (elemento 3), pero no es factible identificar las líneas generadas automáticamente (elemento 2).

Por esta razón, se idearon un par de estrategias alternas, que aunque resuelven el problema de la detección de código generado automáticamente, vienen con riesgos que ponen en peligro una buena clasificación y conteo.

5.1.2 Estrategia alterna 1: Identificación de líneas generadas por diferenciación Idea inicial. Contar las líneas efectivamente nuevas mediante detección de eventos

en el IDE y, al final de la codificación, restarlas del total de líneas nuevas detectadas por un algoritmo diff (de comparación de cadenas de texto), esta diferencia dará como resultado el total de líneas generadas automáticamente.

Reglas.

- Identificar las líneas nuevas en el momento en que son creadas mediante la detección de eventos del teclado que así lo sugieran (posiblemente pulsar Enter).

- Obtener el total de líneas nuevas reales mediante un acumulador (nuevas_reales).

6 El Apéndice B ahonda en las formas de generación automática de código y expone el problema de su detección.


94

- Utilizar un algoritmo de coincidencias de cadenas de texto (diff [HUNT76]) para obtener el total de líneas nuevas respecto a una versión anterior (nuevas_diff). Este mismo algoritmo se usa para obtener los tipos de línea base, cambiadas y borradas.

- Restar el número de líneas nuevas reales del número de líneas nuevas obtenidas por el algoritmo diff. El resultado es el número de líneas generadas.

realesnuevasdiffnuevasgeneradas __ −=

Riesgos. No se puede utilizar la ocurrencia de un evento aislado para determinar si una línea es nueva o no, es necesario tomar en cuenta otros factores como la ocurrencia de otros eventos de teclado y ratón y el tipo anterior de la línea – si es que ya existía al momento de ejecutarse el evento.

Elementos cubiertos. Aunque la idea inicial y las reglas de esta estrategia

aparentemente cubren los tres elementos básicos que se persiguen, el riesgo detectado anticipa que las líneas nuevas no serán efectivamente contadas de esta forma, por lo que no se obtendrán los tipos de línea tradicionales (elemento 1). Por consiguiente, al no tener un conteo correcto de líneas nuevas reales, el resultado de la diferenciación con las líneas nuevas obtenidas mediante diff no corresponderá al del total de líneas generadas automáticamente, lo que significa que el elemento 2 (identificación de líneas generadas y cambiadas) tampoco se cubre con esta estrategia. El único elemento cubierto es el tercero: mínima intervención del usuario para la identificación de los tipos de línea producidos al codificar.

5.1.3 Estrategia alterna 2: Manejo de versiones internas Idea inicial. Dotar al Desarrollador con dos botones de guardado de proyecto en el

ambiente de desarrollo, con la intención de guardar una versión distinta del proyecto cada vez que se presionen dichos botones. El primero se oprime luego de generar código automáticamente; el segundo, antes de generar código. De esta manera, la diferencia entre cada versión será código escrito o código generado, dependiendo del botón usado para guardar el proyecto.

Reglas.

- Proporcionar un botón especial de guardado de proyectos que se debe pulsar cada vez que se genera código automáticamente.

- Proporcionar otro botón de guardado para pulsar justo antes de generar código. - Crear copias de toda la codificación con nombres de archivo distintos dependiendo

del botón pulsado. - Comparar en cada ocasión los archivos de cada versión y encontrar código agregado

en la versión más reciente. - En caso de haber pulsado el botón de guardado para código generado, la diferencia

entre las versiones será dicho código generado automáticamente.


95

- En caso de haber pulsado el botón de guardado para código escrito, la diferencia entre las versiones será el código agregado manualmente.

Riesgos. Esta estrategia depende principalmente de la intervención del usuario, ya

que es él quien decide en qué momento guardar su proyecto con cualquiera de las opciones. Por lo que si hay una omisión al guardar, es muy probable que el conteo de líneas no sea el correcto.

Elementos cubiertos. Mediante esta estrategia es posible identificar los tipos de

línea tradicionales, ya que se puede usar el algoritmo diff para la comparación de versiones y determinar qué líneas se modificaron (cambiadas), cuáles se agregaron (nuevas), cuáles se eliminaron (borradas), por lo que el elemento 1 está cubierto. Por otro lado, es posible identificar las líneas generadas a través de los botones de guardado especial; para considerar también las líneas copiadas y las reusadas, basta con agregar un botón con la misma funcionalidad para cada tipo, por lo que se puede decir que también el elemento básico 2 se cubre también con esta estrategia. Por último, el tercer elemento no se cubre, ya que la responsabilidad del funcionamiento de esta estrategia cae completamente en el Desarrollador. La Tabla 5.2 muestra una comparación de las estrategias hasta aquí descritas, de acuerdo a sus elementos cubiertos, los cuales se encuentran marcados con una x.

Tabla 5. 1 Comparación de estrategias descartadas de acuerdo a los elementos básicos cubiertos. Estrategia Identifica líneas

tradicionales Identifica líneas generadas,

copiadas y reusadas Minimiza la intervención

del Desarrollador Marcado de texto x x

Líneas generadas por diferenciación

x

Manejo de versiones x x

Considerando las ventajas y desventajas de las estrategias descritas en este apartado, se propone una última estrategia que pretende minimizar los riesgos de aquéllas. Se trata de la integración de las características principales de las estrategias alternas con la inicial (marcado de texto). En el siguiente apartado se define la estrategia final.


96

5.2 Estrategia de Conteo propuesta De acuerdo con lo especificado en el objetivo planteado anteriormente (ver Objetivo, en el Capítulo 1), se definió una estrategia de conteo de líneas de código fuente para ambientes de desarrollo integrado en fase de codificación, a partir de la integración de las estrategias mencionadas en el apartado anterior.

5.2.1 Idea inicial

Analizando las estrategias alternas, se puede ver que el problema de la detección de código generado automáticamente – problema encontrado en la estrategia iniciales fácilmente tratable mediante la sustracción de líneas totales de código con las escritas por el programador. De esta forma, la atención se centra ahora en la tipificación de las demás líneas de código (nuevas, cambiadas, etc.). Este aspecto fue tratado en el tercer capítulo de esta tesis, donde se sugieren diversas clases de línea conforme a su procedencia y tipo de evento realizado en cada una de ellas (ver tabla 3.1, en el Capítulo 3).

5.2.2 Estrategia de Conteo de LOC en ambientes de desarrollo integrado (Reglas) Es posible implementar una estrategia de marcado de texto en donde se monitoreen los eventos de teclado y ratón ocurridos dentro del editor de código, para hacer la tipificación de LOC en el momento de la codificación. Para ello, se definen las siguientes reglas:

5.2.2.1 Estructura de la bitácora

Se deberá contar con una bitácora externa –se propone XML- de todos los movimientos hechos para cada línea de código, teniendo como atributos para cada registro:

- Un identificador de línea de código para mantener una relación entre la línea de código real y su correspondiente en la bitácora.

- El tipo de línea, que irá variando cada vez que ocurra un cambio en la línea de código.

- La forma original de cada línea, es decir, el contenido de una línea al momento de iniciar con el proyecto.

- La forma del último cambio de cada línea, para compararse con la forma original y determinar el tipo de línea resultante.

Para mantener una relación entre cada línea de código del editor con su equivalente

en la bitácora, es necesario que cuente con un identificador, algo similar a lo que ocurre con las llaves en una base de datos, que se emplean para mantener las relaciones entre los registros de tablas. Para lograr esto, es necesario agregar al código un comentario que


97

incluya el identificador de la línea. Por ejemplo, si se trata de la primera línea escrita, se añade al final un comentario aislado con, digamos, el texto “/*id00001*/”. La segunda línea llevaría un identificador distinto al primero. Lo que se vería de la siguiente forma:

public class Clase1 { /*id00001*/

String cadena; /*id00002*/ }

La asignación del identificador puede hacerse de una manera incremental para evitar

ambigüedades al momento de hacer el reconocimiento de cada línea. Por otra parte, al momento de agregar este comentario en la línea de código, se debe de hacer un registro de los atributos de ésta en la bitácora.

En un archivo XML, los elementos necesarios para describir cada LOC serían:

<archivo></archivo> Agrupa las líneas contenidas en un archivo de código. <linea></linea> Contiene la información de cada LOC. Atributo:

“id”. Que será el identificador contenido en la línea de código correspondiente.

<original/>

Almacena el contenido inicial de cada línea de código, ya sea que exista al inicio del proyecto o recién creada. Atributos:

“tipo”. Puede variar entre “base”, “nueva”, “copiada”, “generada” y “reusada”, para indicar el tipo de línea al que pertenece el identificador contenido dentro de las etiquetas.

“contenido”. Es una copia del contenido de la línea en el código, sustituyendo los caracteres especiales de XML (por ejemplo comillas, apóstrofes, etc.).

<ultimo/>

Almacena el contenido después del último cambio de cada línea de código. Por convención, las etiquetas no deben llevar acentos –entre otros caracteres especiales-, por esta razón esta etiqueta no lleva tilde en la letra “u”. Atributos:

“tipo”. Puede contener cualquier tipo de línea al que pertenece el identificador contenido dentro de las etiquetas.

“contenido”. Es una copia del contenido de la línea en el código, sustituyendo los caracteres especiales de XML (ej. Comillas, apóstrofes, etc.).


98

En el ejemplo siguiente se muestra la correspondencia de las líneas de código anteriores con la bitácora en un archivo XML:

<archivo> <linea id=”id00001”> <original tipo=”nueva” contenido=”public class Clase1 {“ /> </linea> <linea id=”id00002”> <original tipo=”nueva” contenido=”String cadena;” /> </linea> </archivo>

El ID del primer elemento <linea>, “/*id00001*/”, corresponde a la primera línea del archivo de código. Dentro de este elemento se ubica la información de la línea, para este caso la forma <original> es de tipo “nueva”. De igual forma, la segunda línea también se presenta en su forma original el tipo “nueva”. El contenido de ambos elementos es el de la línea de código correspondiente al identificador. Como ya se mencionó, cada vez que un evento altere una línea de código, este cambio se puede registrar en la bitácora. Por ejemplo, suponiendo que una línea con identificador “id00003” y código “cadena=”Uno”;”, cuyo tipo inicial es “base”, es modificada a “cadena=”Dos”;”, la bitácora cambiaría de:

<linea id=”id00003”> <original tipo=”base” contenido= “cadena="Uno";”/> </linea>

a <linea id=”id00003”> <original tipo=”base” contenido= “cadena="Uno";”/> <ultima tipo=”cambiada” contenido= “cadena="Dos";”/> </linea> Así, cada línea codificada será monitoreada para registrar cambios, siendo todas

ellas consideradas para el conteo final.

5.2.2.2 Tipificación de líneas de código A partir de la tabla 3.1 (en el Capítulo 3) se obtiene la tabla 5.2. Esta última contiene la misma información que aquélla, con la única diferencia de que aquí se organiza de otra forma para facilitar su consulta de acuerdo a la estrategia propuesta.


99

Tabla 5. 2 Tipificación de líneas resultantes por Evento

Línea afectada Tipo de línea resultante por Evento

Modificar Borrar/Cortar Copiar-Pegar Cortar-Pegar

Reusada

Cambiada Borrada Reusada Reusada

Base

Copiada

Cambiada Cambiada Generadas*

Descartar Generada

Copiada Nueva Copiada Nueva Nueva

Nota: Cada línea agregada manualmente es considerada “nueva”. * Se considera un cambio sobre línea “generada” sólo si se da directamente en el

código, de lo contrario, permanece su tipo “generada”.

En la primera columna se listan los tipos de línea que pueden ser afectadas en el código. La segunda parte de la tabla agrupa los tipos de línea resultantes a partir de los eventos realizados en las líneas del código, estos eventos pueden ser Modificar, Borrar (o Cortar sin Pegar), Copiar-Pegar, y Corta-Pegar código. Por ejemplo, si una línea “base” es modificada -evento Modificar-, la tabla indica que su tipo resultante sería “cambiada”; por otro lado, si una línea “copiada” es eliminada -evento Borrar/Cortar-, su tipo será “descartada”, lo que indica que la línea quitada no era parte del código inicial.

5.2.2.3 Tipificación de líneas según la fase de codificación Para efectos de clasificación de líneas de código, la codificación en un proyecto puede tener 3 fases: código inicial, código en curso y código liberado.

• Código inicial. Al inicio de la codificación en un proceso es posible que ya exista código que se va a modificar, a este código se le clasificará como “base”. Es posible que también exista código de reuso al inicio de la codificación, para efectos de simplicidad en el método, éste será indicado manualmente seleccionando las líneas de uso y dándoles el tipo “reusada” en un menú contextual que deberá estar a disposición del usuario. Aunque nominalmente una línea “reusada” no será cambiada, es posible que esto suceda, lo que derivaría en tipos de línea “cambiada” o simplemente eliminada del registro (tabla 5.2).

• Código en curso. En esta fase se hacen todos los cambios en la clasificación de las líneas (ver tabla 5.2) de acuerdo a los eventos ocurridos en el ambiente de desarrollo. Si existe un cambio en el código, se deberá consultar automáticamente la información contenida en la tabla para determinar el tipo resultante de la o las líneas afectadas.

• Código liberado. En este momento se hace el conteo final de LOC, reportando todos sus tipos y cantidades. Finalmente el código liberado puede quedar como “base” para futuras extensiones y cambios.


100

5.2.2.4 Identificación de líneas generadas Como ya se mencionó, no es factible intentar detectar todos los eventos de generación de código en el momento en el que suceden, debido a que aun no existe un estándar de generación (ver Apéndice B). Lo que conduce a una gran cantidad de formas de generar código automáticamente. Por esta razón es que esta estrategia de conteo de LOC propone detectar el código que no fue escrito por el Desarrollador – generado automáticamente- mediante una diferenciación del total de líneas de código del resto de las líneas clasificadas (nuevas, cambiadas, base, reusadas, copiadas, borradas y descartadas) por la herramienta de detección de eventos. La tarea de encontrar las LGA por sustracción después de clasificar las escritas por el programador se puede realizar periódicamente en intervalos de tiempo cortos mientras la codificación esté en curso. Cabe recordar que las LGA aparecen en el código en fracciones de segundo después de ser arrojadas ya sea por un asistente, panel o formulario. Así, al momento del recorrido del código para su detección, el monitor encontrará una o varias líneas sin clasificar, lo que se interpreta como la aparición de código generado. Es importante llevar estas líneas al registro, asignándole también un identificador a cada una para ser clasificada como “generada”.

Es posible que el momento en que este recorrido automático se ejecute el Desarrollador esté escribiendo una línea, lo que podría derivar en que la herramienta de clasificación reporte esta línea como generada automáticamente. Para evitar esta situación, es recomendable que el recorrido automático se ejecute en un tiempo razonable después de la última vez que se presionaron caracteres (unos segundos, tal vez configurable por el usuario). También es recomendable que esta acción se lleve a cabo a petición del usuario y cada vez que se guarde el proyecto.

5.2.2.5 Conteo de líneas de código Para hacer el conteo final, bastará con hacer un recorrido de la bitácora y agrupar los tipos de línea contenidos en ella. El registro tendrá todas las líneas “nuevas”, “cambiadas”, “copiadas”, “base”, “borradas”, “descartadas”, “reusadas” y “generadas”. Cabe mencionar que una herramienta que implemente este método de conteo debe dar al usuario la opción de cambiar manualmente los tipos de línea que así desee.

5.2.3 Riesgos Es posible que las bitácoras creadas para registrar los cambios en las líneas sean modificadas externamente, lo que provocaría una pérdida o corrupción de los datos asociados al proyecto. Se recomienda que estas bitácoras sean protegidas por contraseña.


101

También, es altamente recomendable que los identificadores asignados a cada línea de código mediante un comentario, sean protegidos y sólo puedan ser eliminados si la línea es completamente borrada, de lo contrario, se pueden generar inconsistencias con la información contenida en la bitácora.

5.2.3 Elementos cubiertos Al utilizar la detección de eventos para la clasificación de líneas de código, considerando el tipo anterior de cada una de ellas y aplicando las reglas descritas para la estrategia, se pueden identificar los tipos resultantes de cada línea, lo que asegura el cumplimiento del criterio de líneas tradicionales detectadas (elemento 2). También, al utilizar recorridos periódicos al código se logra la detección de líneas “generadas”, lo que, aunado a la detección de código copiado y reusado a través de eventos, cubre la parte referente al segundo elemento básico considerado para esta tesis. Por último, la intervención del Desarrollador para el conteo y clasificación se reduce únicamente a solicitudes de conteo y supervisión de la clasificación de las líneas, por lo que se puede afirmar que el tercer elemento también se cubre. Por estas razones, es que se consideró a esta estrategia como la más indicada para implementarse para el conteo de LOC.

5.2.4 Observaciones A partir de la Estrategia de Conteo planteada en esta tesis, se puede desarrollar una herramienta para integrarse al ambiente de desarrollo y, ejecutar la clasificación y conteo de líneas de código en el momento en que se codifica. El Apéndice A presenta un breve análisis sobre la forma de integrar aplicaciones en algunos IDEs de Java; también, el Apéndice C presenta algunos recursos para la detección de eventos de teclado y ratón y, de qué forma ésta puede ser aprovechada para la clasificación de líneas de código. La información en estos apéndices resulta útil para el diseño y desarrollo de una herramienta que implemente la Estrategia de Conteo. En el siguiente apartado se muestran los casos de uso para dicha herramienta y los escenarios que debe considerar para implementar la Estrategia. Estos últimos proponen métodos para dar tratamiento a los diferentes escenarios de codificación con los que se puede encontrar al estar en ejecución.

5.3 Casos de Uso y escenarios de la herramienta Tras definir la Estrategia de Conteo se identificaron los Casos de Uso para la herramienta que la implementaría. La estructura de la documentación de estos Casos consta de:

• Diagramas de Casos de Uso. • Plantillas de escenarios para cada Caso de Uso. • Un diagrama de actividad por cada plantilla de escenarios.


102

Antes de pasar a describir los mencionados Casos de Uso, es necesario mostrar la

notación que se utiliza para representar los procedimientos que siguen los escenarios correspondientes a dichos casos.

5.3.1 Representación de escenarios Uno de los elementos utilizados aquí para documentar los Casos de Uso de la herramienta son las plantillas. En ellas se describen los atributos correspondientes a cada Caso. En la parte de “Escenarios” de cada plantilla se muestran procedimientos que responden a la ocurrencia del caso de uso para la tipificación de las líneas de código afectadas. Para facilitar la comprensión de los procedimientos se ideó la siguiente estructura:

Los procedimientos están divididos en pasos, los cuales están identificados por números cardinales consecutivos (1, 2, 3). Para algunos casos los pasos contienen sub-procedimientos, mismos que están identificados por el número del paso al que pertenecen, seguidos de otro número cardinal consecutivo, separados por un punto (Ej. 1.1, 1.2, 1.3, etc.). Un tercer nivel de anidamiento, es decir, sub-procedimientos dentro de sub-procedimientos, se identifica mediante letras minúsculas consecutivas (Ej. a, b, c). Un ejemplo de un procedimiento es el siguiente:

1. Inicio 2. Captura de datos. 2.1. El usuario introduce su ID. 2.2. El usuario introduce su Contraseña. 3. Validación de datos por el sistema. 3.1. El sistema autentica los datos del usuario. a. El sistema valida que el ID y Contraseña sean correctos. b. El sistema valida que el usuario pertenezca al grupo correcto. 4. Entrada a la aplicación. 5. Salir. El ejemplo muestra la forma en que un usuario accede a un sistema mediante la

autenticación de su nombre de usuario y contraseña. Para la utilización de condicionales, iteraciones y llamadas a otros procedimientos

se utilizan etiquetas con la siguiente estructura: Condicionales. Para representar un condicional se usa una etiqueta de inicio [CONDICIÓN] y otra

de fin [FIN DE CONDICIÓN]. En caso de que exista una ruta alterna cuando la condición no se cumple, se definió una etiqueta de nombre [CONDICIÓN ALTERNA] y su respectiva finalización [FIN DE CONDICIÓN ALTERNA]. La sintaxis de un condicional es como sigue:


103

[CONDICIÓN] Si -condición- Procedimiento [FIN DE CONDICIÓN] [CONDICIÓN ALTERNA] Si -condición alterna- Procedimiento [FIN DE CONDICIÓN ALTERNA] Iteraciones Para representar una iteración se usa una etiqueta de inicio [CICLO] y otra de fin

[FIN DE CICLO]. La sintaxis de un procedimiento iterativo es como sigue: [CICLO] (-Condición de inicio y terminación del ciclo-) Procedimiento [FIN DE CICLO] Llamadas a otros procedimientos (otros escenarios) Para representar una llamada a un procedimiento que responde a otro caso de uso

particular se usa la etiqueta [LLAMADA]. La sintaxis de una llamada es: [LLAMADA] Ejecutar -Nombre del Caso de Uso- También es posible que en un paso se llame a otro procedimiento encontrado en la

misma plantilla. En este caso sólo se hace referencia al nombre que se haya asignado a dicho procedimiento alterno. Los nombres de los procedimientos alternos se escriben con mayúsculas y entrecomillados. Por ejemplo:

1. Ejecutar “OTRO PROCEDIMIENTO”. Ejemplo de la sintaxis. El procedimiento de validación de un usuario por el sistema representado con esta

sintaxis sería: 1. El sistema captura los datos del usuario. 1.1. Establecer la validación como fracasada. 1.2. [CICLO] (Mientras que la validación sea fracasada). a. [CONDICIÓN] Si el ID y contraseña del usuario son válidos. a.1. Mostrar mensaje de éxito. a.2. Establecer la validación como exitosa. [FIN DE CONDICIÓN] b. [CONDICIÓN ALTERNA] Si el ID o contraseña no son válidos. b.1. Mostrar mensaje de error.


104

[FIN DE CONDICIÓN ALTERNA] [FIN DE CICLO] 2. [LLAMADA] Ejecutar "CU Abrir Sistema". 3. Salir. En el ejemplo se observa que el ciclo se repetirá mientras la validación sea

fracasada (paso 1.2.). Esto se logra si los datos del usuario son válidos, lo que cambiará el estado de la validación como 'exitosa' (pasos a y b). Al salir del ciclo se manda llamar al caso de uso "CU Abrir Sistema" (paso 2).

Una vez definida la sintaxis con la que se compone un procedimiento en las plantillas, se procede a mostrar los diagramas de Casos Uso, plantillas de escenarios y diagramas de actividad correspondientes a una herramienta de conteo de líneas de código que aplica la Estrategia de Conteo definida en este trabajo.

5.3.2 Diagramas de Casos de Uso, plantillas de escenarios y diagramas de actividad

En este apartado se exponen los Casos de Uso de una herramienta de conteo de LOC que implementa la Estrategia de conteo definida en este trabajo de tesis. Se utilizó una plantilla de escenarios para documentar cada Casos de Uso. Estas plantillas contienen los procedimientos que permiten que la herramienta tipifique líneas de código según lo especificado en la tabla 5.2, tomando en cuenta la Estrategia propuesta. La sintaxis con que se define cada procedimiento es la especificada en el apartado anterior.

A cada plantilla de escenarios le sigue un diagrama de actividad, cuyo objetivo es mostrar el flujo que se sigue en los procedimientos. Cabe mencionar, que estos diagramas no necesariamente muestran paso a paso el procedimiento, sino que definen la ruta que debe seguirse para considerar los escenarios mostrados en su plantilla correspondiente. Así, es posible que, si existe una ruta alterna (escenario alterno) para un Caso de Uso, el diagrama de actividad muestre sólo el nombre del procedimiento a seguir y no la totalidad de sus pasos.

A continuación se muestran los Casos de Uso, plantillas de escenarios y diagramas

de actividad para una herramienta que implementa la Estrategia de Conteo de Líneas de Código propuesta. La figura 5.1 muestra los Casos de Uso.


105

uc Casos de Uso Contador

CU1 Comenzar proyecto

CU2 Finalizar proyecto

CU3 Editar código

CU4 Solicitar conteo de líneas

CU5 Cambiar tipos de línea

CU6 Ver reporte

A. Desarrollador

Figura 5. 1 Casos de Uso de Contador de Líneas.

Como se observa en la figura 5.1, el actor –definido desde los escenarios de

Codificación en el Capítulo 4- sigue siendo el Desarrollador quien interactúa con el ambiente de desarrollo y con la herramienta de conteo (que deberá integrarse al IDE). Los casos que se pueden presentar al utilizar la herramienta van desde el comienzo de un proyecto (CU1) hasta su finalización (CU2). La parte principal de su uso será la edición de código (CU3), aunque el Desarrollador probablemente sólo perciba su interacción con el IDE, la herramienta debe detectar los eventos con teclado y ratón. La intervención del usuario al tipificar las LOC viene cuando se desea hacer un cambio manual en su clasificación (CU5). Por otra parte el usuario puede solicitar un conteo general de líneas (CU4) y ver el reporte al momento (CU6). Ahora se muestran las plantillas de escenarios correspondientes a los Casos de Uso ilustrados en la figura 5.1. El nombre de cada plantilla corresponde al Caso de Uso que documenta.


106

CU 1 Comenzar proyecto Nombre del Caso de Uso:

CU1 Comenzar proyecto


Descripción: El inicio del proyecto marca el punto de partida para el contador de líneas. Puede ser que se trate de una nueva versión de un proyecto anterior o de un proyecto nuevo. Para ambos casos se debe preguntar al usuario si las líneas existentes (si las hay) se toman como "base", "reusadas" o "generadas".

Escenarios: Ruta Básica Comienzo de proyecto

1. El usuario inicia el sistema contador de líneas. 2. El sistema crea un directorio de registro con el mismo nombre del proyecto. 3. El sistema crea un archivo de registro de líneas para cada archivo con código fuente que el proyecto tiene. 4. El sistema solicita al Desarrollador que elija el tipo de líneas que se asignarán a las existentes en el proyecto. 5. El Desarrollador asigna el tipo de líneas iniciales (con opción a elegir cuáles y de qué tipo). 6. El sistema actualiza los archivos de registro con los tipos de línea. 7. El sistema configura el estado del proyecto como "iniciado".

Restricciones: Pre-Condición (Propuesto) Proyecto creado Para comenzar a usar el contador de líneas el

proyecto debió haberse creado. Post-Condición (Propuesto)

Repositorio creado El repositorio que contendrá las líneas de código y sus tipos fue creado.


Líneas iniciales clasificadas Las líneas producidas al inicio del proyecto fueron clasificadas y reportadas en el repositorio.


Proyecto iniciado El estado del proyecto es "iniciado".

Como se mencionó al inicio de este apartado, para comprender mejor el flujo que

sigue un procedimiento, se muestra el mismo con un diagrama de actividad. En la figura 5.2 aparece el diagrama de actividad correspondiente al Caso de Uso “CU1”. Para los Casos de Uso y plantillas restantes, también se muestra un diagrama de actividad correspondiente. Nuevamente, se recuerda que en dichos diagramas sólo se representa el flujo a seguir y no se detallan los pasos que ya se especificaron en los procedimientos.


107

act CU1

Inicio del contador delíneas

Crear directorio deregistro

Crear archiv o XML para cadaarchiv o con código del proyecto

Elegir el tipo de líneas que se asignan a lasexistentes en el proyecto

Actualizar los registros (XML) con eltipo de línea elegido

Se califica al sistemacomo "iniciado"

Fin

Inicio

Figura 5. 2 Diagrama de actividad para CU1 Comenzar Proyecto


108

CU 2 Finalizar proyecto Nombre del Caso de Uso:

CU2 Finalizar proyecto


Descripción: El Desarrollador decide cuándo desea finalizar el conteo, indicando que el código se ha liberado. Se realiza el conteo final y el reporte correspondiente.

Escenarios: Ruta Básica Finaliza proyecto

1. El Desarrollador indica que el proyecto finalizó. 2. El sistema realiza un recorrido final al código para actualizar los tipos de cada línea. 3. El sistema genera un reporte de los resultados del conteo. 4. El sistema cambia el estado del proyecto a "terminado".

Restricciones: Pre-Condición (Propuesto) Conteo iniciado El conteo de líneas debió iniciarse previamente, lo

que significa que los registros también existen. Post-Condición (Propuesto)

Conteo finalizado Los totales de cada tipo de líneas fueron contados.


Reporte generado Se produce un reporte del conteo de líneas final.


Proyecto finalizado El estado del proyecto cambió a "terminado".

La figura 5.3 muestra el diagrama de actividad correspondiente.

act CU2 Finalizar proyecto

Recorrer todo el código del proyectopara actualizar tipos en registro

Generar reporte deresultados de conteo

Se califica al sistemacomo "terminado"

Inicio

Fin

Figura 5. 3 Diagrama de actividad para CU2 Finalizar proyecto


109

CU 3 Editar código Nombre del Caso de Uso:

CU3 Editar código


Descripción: El Desarrollador codifica el proyecto de software, valiéndose tanto del teclado y del ratón para escribir como de asistenes, formularios y paneles para generar código automáticamente.

Escenarios: Ruta Básica Registrar cambios

1. El Desarrollador comienza editar código. 2. El sistema monitorea los cambios. 3. El sistema almacena los cambios de cada línea en el registro.



Registro actualizado Después de editar el código en el proyecto los cambios en cada línea son actualizados en el registro.


act CU3 Editar código

Inicio

Comienzo de la ediciónde código

Monitorear cambios en elcódigo

Almacenar cambios de cadalínea de código en el registro

Fin

Figura 5. 4 Diagrama de Actividad para CU3 Editar código.


110

CU 4 Solicitar conteo de líneas Nombre del Caso de Uso:

CU4 Solicitar conteo de líneas


Descripción: El Desarrollador solicita al sistema que realice el conteo de líneas de un proyecto hasta la fecha actual, incluso después de terminado. El sistema debe presentar un reporte del conteo de líneas de código.

Escenarios: Ruta Básica Conteo de líneas

1. El Desarrollador solicita el conteo de líneas. 2. El Desarrollador indica al sistema qué archivos del proyecto se van a contar. 3. El sistema recorre los archivos de registro del proyecto solicitados contando y agrupando los tipos de línea de código. 4. El sistema genera un reporte con el número y el tipo de líneas del proyecto.



Líneas contadas Se contaron y agruparon por tipo las líneas de código del proyecto.

Post-Condición (Aprobado)

Reporte generado Se generó un reporte con el número y tipo de líneas de código del proyecto.



111

act CU4 Solicitar conteo de líneas

Inicio

Elegir los arhiv os del proyectoque serán contados

Recorrer el código de los archiv ossolicitados del proyecto

Contar y agrupar los tiposde línea de código

Generar reporte con lostipos de línea del proyecto

Fin

Figura 5. 5 Diagrama de actividad para CU4 Solicitar conteo de líneas

CU 5 Cambiar tipos de línea Nombre del Caso de Uso:

CU5 Cambiar tipos de línea


Descripción: El Desarrollador puede cambiar el tipo asignado por el sistema a una línea en cualquier momento durante la codificación de un proyecto, incluso después de liberarlo.

Escenarios: Ruta Básica Cambiar tipo de línea

1. El Desarrollador selecciona la o las líneas a las que cambiará el tipo. 2. El Desarrollador elige del menú contextual la opción de cambiar tipo. 3. El Desarrollador elige el tipo de línea que desea asignar a la(s) líneas seleccionadas. 4. El sistema busca el identificador de la línea en el registro y actualiza éste último de acuerdo al tipo asignado.



Línea(s) cambiada(s) Una o más líneas cambiaron su tipo.



112

act CU5 Cambiar tipos de línea

Inicio

Seleccionar las líneas de código a las quese cambiará el tipo

Desplegar menú contextual con lostipos de línea existentes

Elegir un tipo de líneadesde menú contextual

Capturar el identificador de la o laslíneas seleccionadas

Localizar el identificador en elregistro

Actualizar el tipo de la línea en elregistro con el elegido en el menú

contextual

Fin

Figura 5. 6 Diagrama de actividad para CU5 Cambiar tipos de línea.

CU 6 Ver reporte Nombre del Caso de Uso:

CU6 Ver reporte


Descripción: Un Desarrollador solicita ver el reporte del conteo de líneas en un proyecto. Puede tratarse del proyecto en curso o de otro en particular, siempre y cuando sus LOC hayan sido contadas.

Escenarios: Ruta Básica Ver reporte

1. El Desarrollador solicita ver un reporte de conteo. 2. El sistema pide al Desarrollador que elija el proyecto del que va a mostrar reporte. 3. El Desarrollador escoge un proyecto (puede ser el proyecto en curso). 4. El sistema busca el reporte de conteo de líneas generado para el proyecto seleccionado. 5. El sistema muestra el reporte de conteo de líneas del proyecto elegido.

Restricciones:


113

Pre-Condición (Propuesto) Conteo iniciado El conteo de líneas debió iniciarse previamente, lo que significa que los registros también existen.


Vista del reporte Se exhibe el reporte generado del proyecto.


act CU6 Ver reporte

Inicio

Mostrar la lista de proyectos quecuentan con conteo de líneas

Buscar el reporte en el directorio delproyecto elegido por el Desarrollador

Mostrar el reporteencontrado

Fin

Figura 5. 7 Diagrama de actividad para CU6 Ver reporte.

El Caso de Uso principal es el CU3 Editar código, del cual se derivan otros Casos de Uso. Estos casos que se identificaron y describieron en el Capítulo 4, se refieren a las acciones que un Desarrollador realiza en el ambiente de desarrollo, ya sea mediante el teclado y ratón, o llamando a funciones propias del IDE. Para el propósito de la implementación de la Estrategia de Conteo, se detectaron los casos de uso de edición de código que afectan directamente en el tipo de líneas de código del proyecto de software en curso. La figura 5.2 muestra el diagrama de estos casos.


114

uc Casos de Uso Codificación

Replicar/Mover Código

Opciones de archivo

A. Desarrollador

CU3 Editar código

CU3.1 Presionar teclas

CU3.1.1 Presionar Enter

CU3.1.2 Presionar caracteres

CU3.1.3 Presionar Suprimir y Retroceso

CU3.2 Usar métodos del IDE

CU3.2.1 Llamar a función Deshacer o

Rehacer

CU3.2.8 Guardar archivo/proyecto

como...

CU3.2.9 Eliminar archiv o/proyecto

CU3.2.10 Renombrar archiv o/proyecto

CU3.2.2 Generar código

CU3.2.3 Copiar código

CU3.2.4 Cortar código

CU3.2.5 Pegar código

CU3.2.6 Crear archiv o/proyecto

CU3.2.7 Guardar archiv o/proyecto

CU3.2.11 Salir sin guardar

«extend»

«extend»

«extend»


«extend»

«extend»

«extend»

«extend»


«extend»

«extend»

«extend»

«extend»

«extend»

«extend»

Figura 5. 8 Casos de uso de codificación para herramienta de conteo

Con el Desarrollador como actor que interactúa con el editor de código, se tienen dos casos de uso extendidos para la edición: presionar teclas (CU3.1) y usar métodos del IDE (CU3.2). El primero se refiere al uso del teclado y del que se tendrán que detectar eventos como presionar la tecla Enter (CU3.1.1), presionara caracteres o dígitos (CU3.1.2) y presionar las teclas Suprimir o Retroceso (CU3.1.3). El segundo caso extendido se refiere


115

a las llamadas a las funciones propias del ambiente de desarrollo, que incluyen llamar a las funciones Rehacer o Deshacer (CU3.2.1), generar código automáticamente (CU3.2.2), copiar, cortar o pegar código (CU3.2.3, CU3.2.4 y CU3.2.5, respectivamente) y el manejo de archivos y proyectos como crear (CU3.2.6), guardar (CU3.2.7), guardar como… (CU3.2.8), eliminar (CU3.2.9), renombrar (CU3.2.10) y salir sin guardar (CU3.2.11). Ahora se describen los escenarios asociados a cada Caso de Uso. Nuevamente se recuerda que el contenido de cada uno muestra un método que cumple con lo definido en la Estrategia de Conteo. CU3. 1 Presionar teclas Nombre del Caso de Uso:

CU3.1 Presionar teclas


Descripción: El Desarrollador escribe código con el teclado en el editor. Las teclas que afectan el tipo de una línea de código son "Enter", "Suprimir", "Retroceso" y los caracteres y dígitos del teclado. Las combinaciones de letras como Ctrl+Z son llamadas a funciones del IDE, por lo que se ignoran en este Caso de Uso.

Escenarios: Ruta Básica Presionar teclas

1. El Desarrollador presiona las teclas mencionadas. 2. El sistema determina el cambio que se hizo con la tecla. 3. El sistema localiza en el registro la línea afectada. 4. El sistema asigna el nuevo tipo a la línea afectada en el registro.

1. El Desarrollador p2. El sistema determi3. El sistema localiza4. El sistema asigna

Restricciones: Pre-Condición (Propuesto) Teclas presionadas Se presiona una de las teclas mencionadas en

la notas. Post-Condición (Propuesto) Registro actualizado Se actualiza en el registro el o los tipos de

líneas afectadas.

Esta plantilla no presenta un diagrama de actividad, ya que se trata de un Caso de Uso extendido (ver figura 5.8, CU 3.1), por los que los Casos de Uso que lo extienden son los que cuentan con diagramas de actividad para ilustrar su comportamiento.


116

CU3.1. 1 Presionar Enter Nombre del Caso de Uso:

CU3.1.1 Presionar Enter

Estado: Propuesto Versión: 1.0 Fase: 1.0 Autor: Erick Iduñate Creado en: 10/10/2007 Modificado en: 10/02/2008 Descripción: El Desarrollador puede presionar Enter para dar por terminada la escritura de una

línea, dar formato al código mediante saltos de línea, dividir una línea previamente escrita o, incluso, borrar un segmento de código seleccionado.

Escenarios: Ruta Básica Presionar Enter

1. El Desarrollador oprime la tecla Enter. 2. [CONDICIÓN] Si hay selección de código. 2.1. Ejecutar "CÓDIGO SELECCIONADO". 2.2. Saltar a paso 8. [FIN DE CONDICIÓN] 3. Capturar el contenido de la línea. 4. [CONDICIÓN] Si el cursor está en una línea en blanco. 4.1. Ejecutar "LÍNEA EN BLANCO". 4.2. Saltar a paso 9. [FIN DE CONDICIÓN] 5. [CONDICIÓN] Si el cursor está al final de una línea y la línea no tiene identificador. 5.1. Ejecutar "D. FIN DE LÍNEA SIN IDENTIFICADOR". 5.2. Saltar a paso 8. [FIN DE CONDICIÓN] 6. [CONDICIÓN] Si el cursor se encuentra al inicio o final de una línea y tiene identificador. 6.1. Ejecutar "CURSOR FUERA DE LÍNEA CON IDENTIFICIADOR". 6.2. Saltar a paso 8. [FIN DE CONDICIÓN] 7. [CONDICÓN] Si el cursor se encuentra después del inicio y antes del final de la línea. 7.1. Ejecutar "CURSOR DENTRO DE UNA LÍNEA". [FIN DE CONDICIÓN] 8. Hacer salto de línea. 9. Salir.

Ruta Alterna CÓDIGO SELECCIONADO

1. Contar el número de líneas completas seleccionadas. 2. [CONDICIÓN] Si existe una o más líneas completas seleccionadas. 2.1. [CICLO] (De 1 al número de líneas completas seleccionadas). a. Situar un cursor en la línea correspondiente al número de iteración. b. Capturar el identificador de la línea en turno. c. Localizar en la bitácora la línea de acuerdo al identificador. d. Capturar el tipo de línea correspondiente a la línea en curso. e. Cambiar el tipo de línea de acuerdo a la Tabla 5.2 en el evento Borrar. [FIN DE CICLO] [FIN DE CONDICIÓN] 3. [CONDICIÓN] Si existe un fragmento de línea seleccionado (línea no completa) y el fragmento seleccionado está fuera de un comentario. 3.1. [CONDICIÓN] Si la línea tiene identificador. a. Captura el identificador de la línea. b. Localizar en la bitácora la línea de acuerdo al identificador. c. Capturar el tipo de línea correspondiente a la línea en curso. d. Cambiar el tipo de línea de acuerdo a la Tabla 5.2 en el evento Modificar. [FIN DE CONDICIÓN] 3.2. [CONDICIÓN ALTERNA] Si la línea no tiene identificador.


117

a. Ir a "C. FIN DE LÍNEA SIN IDENTIFICADOR". [FIN DE CONDICIÓN ALTERNA] [FIN DE CONDICIÓN] 4. Borrar el código seleccionado.

Ruta Alterna LÍNEA EN BLANCO

1. Hacer salto de línea.

Ruta Alterna FIN DE LÍNEA SIN IDENTIFICADOR

1. Agregar un comentario con la identificación de la línea. Ej.: /*id00001*/ 2. Agregar en la bitácora un nuevo elemento referente a la línea de tipo "nueva".

Ruta Alterna CURSOR FUERA DE LÍNEA CON IDENTIFICIADOR

1. El Desarrollador oprime la tecla Enter. 2. [CONDICIÓN] Si el cursor se encuentra al inicio o final de una línea y tiene identificador. a. Hacer salto de línea. [FIN DE CONDICIÓN]

Ruta Alterna CURSOR DENTRO DE UNA LÍNEA

1. [CONDICIÓN] Si la línea tiene identificador. 1.1. Capturar el identificador de la línea. 1.2. Asignar el mismo identificador a la primera mitad de la línea. 1.3. Buscar identificador en la bitácora. 1.4. Capturar el tipo correspondiente a la línea. 1.5. Asigna clasificación correspondiente a la primera mitad de acuerdo a la Tabla 5.2, evento Modificar). 1.6. Asignar identificador nuevo a la segunda mitad. 1.7. Agregar nuevo elemento a la bitácora con la información de la segunda mitad. Mismo tipo de la primera mitad. [FIN DE CONDICIÓN] 2. [CONDICIÓN ALTERNA] 2.1. Ir a "FIN DE LÍNEA SIN IDENTIFICADOR". [FIN DE CONDICIÓN ALTERNA]

Restricciones: Pre-Condición (Propuesto) Editor Se debe codificar dentro del editor del lenguaje

o lenguajes seleccionados. Pre-Condición (Propuesto) Funcionamiento La tecla Enter debe funcionar correctamente

en el teclado. Post-Condición (Propuesto) Salto de línea Se produce un salto de línea. Post-Condición (Propuesto) Registro actualizado El registro es actualizado con información

procedente de los cambios en el código.



118

stm CU3.1.1 Presionar Enter

Inicio

1. El Desarrollador oprimela tecla Enter.

B. CÓDIGOSELECCIONADO

8. Hacer salto de línea.

3. Capturar el contenidode la línea.

C. LÍNEA EN BLANCO

Fin

D. FIN DE LÍNEA SINIDENTIFICADOR

El cursor se encuentra al inicio o final

de una línea y tiene identificador.

El cursor está en una línea en blanco.

Hay código seleccionado No hay código seleccionado

Figura 5. 9 Diagrama de actividad para CU3.1.1 Presionar Enter


119

CU3.1. 2 Presionar caracteres Nombre del Caso de Uso:

CU3.1.2 Presionar caracteres

Estado: Propuesto Versión: 1.0 Fase: 1.0 Autor: Erick Iduñate Creado en: 10/10/2007 Modificado en: 10/02/2008 Descripción: El Desarrollador oprime una tecla de carácter o dígito para escribir código. Puede

crear nuevas líneas, extender una línea existente o remplazar código existente. Para remplazar código es necesario tener activada la tecla "insert" o haber seleccionado código previamente.

Escenarios: Ruta Básica Presionar un carácter.

1. El Desarrollador oprime un carácter. 2. [CONDICIÓN] Si existe código seleccionado. 2.1. Ejecutar "HAY CÓDIGO SELECCIONADO". [FIN DE CONDICIÓN] 3. [CONDICIÓN ALTERNA] Si no existe código seleccionado. a. Ejecutar "NO HAY CÓDIGO SELECCIONADO" [FIN DE CONDICIÓN ALTERNA] 4. Imprimir el carácter. 5. Salir.


1. Contar el número de líneas completas seleccionadas. 2. [CONDICIÓN] Si existe una o más líneas completas seleccionadas. 2.1. [CICLO] (De 1 al número de líneas completas seleccionadas). a. Situar un cursor en la línea correspondiente al número de iteración. b. Capturar el identificador de la línea en turno. c. Localizar en la bitácora la línea de acuerdo al identificador. d. Capturar el tipo de línea correspondiente a la línea en curso. e. Cambiar el tipo de línea de acuerdo a la Tabla 5.2 en el evento Borrar. f. Pasar a la siguiente línea. [FIN DE CICLO] [FIN DE CONDICIÓN] 3. [CONDICIÓN] Si existe un fragmento de línea seleccionada (línea no completa) y existe identificador en la línea. 3.1. [CONDICIÓN] Si el fragmento seleccionado está fuera de un comentario. a. Captura el identificador de la línea. b. Localizar en la bitácora la línea de acuerdo al identificador. c. Capturar el tipo de línea correspondiente a la línea en curso. d. Cambiar el tipo de línea de acuerdo a la Tabla 5.2 en el evento Modificar. [FIN DE CONDICIÓN] [FIN DE CONDICIÓN] 4. Borrar el código seleccionado.

Ruta Alterna NO HAY CÓDIGO SELECCIONADO

1. [CONDICIÓN] Si la línea tiene identificador y el cursor no está en un comentario 1.1. Buscar el identificador de la línea en el registro 1.2. Insertar o modificar (si existe) el elemento <ultimo> con contenido de la línea y el tipo indicado por la Tabla 5.2 en el evento "Modificar". [FIN DE CONDICIÓN]


o lenguajes seleccionados. Pre-Condición (Propuesto) Funcionamiento Las teclas con caracteres y dígitos deben

funcionar correctamente. Post-Condición (Propuesto) Carácter escrito Se imprime en el editor el carácter o dígito

presionado. Post-Condición (Propuesto) Registro actualizado El registro es actualizado con información



120


act CU3.1.2 Presionar Caracteres

Inicio

El Desarrollador oprimeun carácter


C. NO HAY CÓDIGOSELECCIONADO

Imprimir el carácter

Fin

No existe código seleccionadoExiste código seleccionado

Figura 5. 10 Diagrama de actividad para CU3.1.2 Presionar caracteres

CU3.1. 3 Presionar Suprimir y Retroceso Nombre del Caso de Uso:

CU3.1.3 Presionar Suprimir y Retroceso


Descripción: Las teclas Suprimir y Retroceso sirven para borrar código, la primera para borrar el carácter que se encuentra apuntado por el cursor y la segunda para eliminar el carácter anterior al apuntado por el cursor. Si existe código seleccionado al oprimir cualquiera de estas teclas, el código se borrará. También se pueden unir dos líneas al eliminar los espacios y saltos de líneas entre ellas.

Escenarios: Ruta Básica Oprimir tecla Suprimir o

1. El Desarrollador oprime la tecla suprimir o retroceso. 2. [CONDICIÓN] Si existe código seleccionado. 2.1. Ejecutar "HAY CÓDIGO SELECCIONADO".


121

Retroceso. [FIN DE CONDICIÓN] 3. [CONDICIÓN ALTERNA] Si no existe código seleccionado. 3.1. Ejecutar "NO HAY CÓDIGO SELECCIONADO". [FIN DE CONDICIÓN ALTERNA] 4. [CONDICIÓN] Si la línea se une con la línea previa o posterior. 4.1. Ejecutar "UNIÓN DE LÍNEAS". [FIN DE CONDICIÓN] 5. Salir.


1. Contar el número de líneas completas seleccionadas. 2. [CONDICIÓN] Si existe una o más líneas completas seleccionadas (excluyendo comentarios). 2.1. [CICLO] (De 1 al número de líneas completas seleccionadas). a. Situar un cursor en la línea correspondiente al número de iteración. b. Capturar el identificador de la línea en turno. c. Localizar en la bitácora la línea de acuerdo al identificador. d. Capturar el tipo de línea correspondiente a la línea en curso. e. Insertar o modificar (si existe) el elemento <ultimo> con contenido vacío y el tipo indicado por la Tabla 5.2 en el evento "Borrar". f. Pasar a la siguiente línea. [FIN DE CICLO] [FIN DE CONDICIÓN] 3. [CONDICIÓN] Si existe un fragmento de línea seleccionada (línea no completa) y existe identificador en la línea. 3.1. [CONDICIÓN] Si el fragmento seleccionado está fuera de un comentario. a. Captura el identificador de la línea. b. Localizar en la bitácora la línea de acuerdo al identificador. c. Capturar el tipo de línea correspondiente a la línea en curso. d. Insertar o modificar (si existe) el elemento <ultimo> con contenido de la línea y el tipo indicado por la Tabla 5.2 en el evento "Modificar". [FIN DE CONDICIÓN] [FIN DE CONDICIÓN] 4. Borrar el código seleccionado.

Ruta Alterna NO HAY CÓDIGO SELECCIONADO

1. [CONDICIÓN] Si existe identificador en la línea. 1.1. [CONDICIÓN] Si el cursor no se encuentra dentro de un comentario y no es el único carácter en la línea. a. Buscar el identificador de la línea en el registro. b. Insertar o modificar (si existe) el elemento <ultimo> con contenido de la línea y el tipo indicado por la Tabla 5.2 en el evento "Modificar". [FIN DE CONDICIÓN] 1.2. [CONDICIÓN] Si el cursor no se encuentra dentro de un comentario y sí es el único carácter en la línea. a. Buscar el identificador de la línea en el registro. b. Insertar o modificar (si existe) el elemento <ultimo> con contenido vacío y el tipo indicado por la Tabla 5.2 en el evento "Borrar". c. Borrar comentario con identificador en la línea. [FIN DE CONDICIÓN] [FIN DE CONDICIÓN] 2. Borrar carácter.


o lenguajes seleccionados. Pre-Condición (Propuesto) Funcionamiento Las teclas suprimir y retroceso deben

funcionar adecuadamente. Post-Condición (Propuesto) Código borrado Un carácter o código son eliminados. Post-Condición (Propuesto) Registro actualizado El registro es actualizado con información



122


act CU3.1.3 Presionar Suprimir y Retroceso

Inicio

El Desarrollador oprime latecla Suprimir o Retroceso


C. NO HAY CÓDIGOSELECCIONADO

D. UNIÓN DE LÍNEAS

Fin

La lí

nea

no s

e un

e co

n ni

ngun

a ot

ra

La línea se une con una línea previa o posterior

No existe código seleccionadoExiste código seleccionado

Figura 5. 11 Diagrama de actividad para CU3.1.3 Presionar Suprimir o Retroceso


123

CU3. 2 Usar métodos del IDE Nombre del Caso de Uso:

CU3.2 Usar métodos del IDE


Descripción: Un ambiente de desarrollo contiene métodos para la generación automática de código, como son los asistentes para la creación de clases y métodos, así como el empleo de formularios con componentes para el diseño de Interfaces Gráficas de Usuario (GUI por sus siglas en inglés), que también generan código. Los métodos de Rehacer y Deshacer influyen en la tipificación de líneas de código. Además, los métodos "cortar", "copiar" y "pegar", así como la manipulación de archivos y proyectos desde el IDE también afecta la tipificación de las líneas de código contenidas en ellos.

Escenarios: Ruta Alterna Usar métodos del IDE

1. El Desarrollador puede llamar a cualquier método del IDE que afecte las líneas de código del proyecto.

Restricciones: Pre-Condición (Propuesto) Métodos presentes El IDE cuenta con métodos de generación

automática de código, manejo de archivos y proyectos, replicación y desplazamiento de código o Deshacer y Rehacer acciones.

Post-Condición (Propuesto) Registro actualizado Se actualiza en el registro el o los tipos de líneas afectadas.

Esta plantilla no presenta un diagrama de actividad, ya que se trata de un Caso de Uso extendido (ver figura 5.8, CU 3.2), por los que los Casos de Uso que lo extienden son los que cuentan con diagramas de actividad para ilustrar su comportamiento. CU3.2. 1 Llamar a función Deshacer o Rehacer Nombre del Caso de Uso:

CU3.2.1 Llamar a función Deshacer o Rehacer

Estado: Propuesto Versión: 1.0 Fase: 1.0Autor: Erick Iduñate Creado en: 10/10/2007 Modificado en: 11/02/2008

Descripción: a) Desecha o rehace el último cambio realizado en el código. - Inserción de código. - Borrado de código. - Generación de código por asistentes. - Borrado de código por asistentes. - Modificación de código (formato, cambio en líneas). b) No es posible Deshacer la creación de un proyecto.

Escenarios: Ruta Básica Deshacer/Rehacer

1. El Desarrollador llama a la función Deshacer o Rehacer. 2. Contar el total de líneas afectadas. 3. [CICLO] (DE 1 HASTA EL TOTAL DE LÍNEAS AFECTADAS) 3.1. Obtener el ID de la línea. 3.2. Buscar el identificador de la línea en el registro.


124

3.2.1. [CONDICIÓN] Si la línea es borrada a. Ejecutar "LÍNEA BORRADA". [FIN DE CONDICIÓN] 3.2.2. [CONDICION ALTERNA] Si la línea se modificó a. Ejecutar "LÍNEA MODIFICADA". [FIN DE CONDICIÓN ALTERNA] 3.2.3. [CONDICION ALTERNA] Si se agregó una línea. a. Ejecutar "AGREGADA". [FIN DE CONDICION ALTERNA] 3.3. Mover a siguiente línea. [FIN DE CICLO] 4. Salir.

Alterna LÍNEA BORRADA

1. Insertar o modificar (si existe) el elemento <ultimo> con contenido vacío y el tipo indicado por la Tabla 5.2 en el evento "Borrar", usando como parámetro el último tipo de la línea.

Alterna LÍNEA MODIFICADA

1. Insertar o modificar (si existe) el elemento <ultimo> con contenido de la línea y el tipo indicado por la Tabla 5.2 en el evento "Modificar", usando como parámetro el último tipo de la línea.

Alterna LÍNEA AGREGADA

1. Insertar o modificar (si existe) el elemento <ultimo> con contenido de la línea y el tipo será el último tipo de la línea.

Restricciones: Pre-Condición (Propuesto) Acción realizada Debe existir una acción previa al evento de

Deshacer o un evento de Deshacer previo a un evento Rehacer.

Post-Condición (Propuesto) Registro actualizado El registro es actualizado con información procedente de los cambios en el código.



125

act CU3.2.1 Llamar a función Deshacer o Rehacer.

Inicio

El Desarrollador llama ala función Deshacer o

Rehacer

Contar total de líneasafectadas

Localizar el identificadoren el registro

LÍNEA BORRADA LÍNEA MODIFICADA LÍNEA AGREGADA

Mov er a línea siguiente

Fin

No existen más líneas afectadas

Ciclo de 1 hasta el total de líneas afectadas.

Se borró la línea

Se modificó la línea

Se agregó la línea

Figura 5. 12 Diagrama de actividad de CU3.2.1 Llamar a función Deshacer o Rehacer


126

CU3.2. 2 Generar código Nombre del Caso de Uso:

CU3.2.2 Generar código


Descripción: Un Desarrollador genera código automáticamente de distintas formas: asistentes, formularios con componentes visuales, paneles, etc. Para detectar las líneas de código generadas por estos medios (no escrito manualmente) se hace un recorrido general del código periódicamente. El sistema no responde a un evento de generación automática en específico.

Escenarios: Ruta Básica Generar código

1. [CONDICIÓN] Si el tiempo de inactividad es igual o mayor al especificado en la configuración del sistema o si el usuario solicita un conteo de líneas o si el usuario guarda el proyecto o archivo. 1.1. Ejecutar "BUSCAR CÓDIGO GENERADO". [FIN DE CONDICIÓN] 2. Salir.

Ruta Alterna B. BUSCAR CÓDIGO GENERADO

1. [CICLO] (De 1 al número de líneas completas seleccionadas). 1.1. Situar un cursor en la línea correspondiente al número de iteración. 1.2. [CONDICIÓN] Si la línea no tiene identificador. a. Capturar el identificador de la línea en turno. b. Agregar un comentario con la identificación de la línea. Ej.: /*id00345*/ c. Agregar en el registro un nuevo elemento <original> dentro de una nueva <linea> con el contenido de la línea y asignar al tipo la cadena "generada". [FIN DE CONDICIÓN] 1.3. Pasar a la siguiente línea. [FIN DE CICLO]

Restricciones: Post-Condición (Propuesto) Líneas generadas detectadas Se identificaron y comentaron en el código

todas las líneas generadas automáticamente. Post-Condición (Propuesto) Registro actualizado El registro es actualizado con información




127

act CU3.2.2. Generar código

Inicio

B. BUSCAR CÓDIGOGENERADO

Fin

Tiempo de inactividad cumplido | El usuariosolicita conteo | El usuario guarda proyecto

Figura 5. 13 Diagrama de actividad de CU3.2.2 Generar código.

CU3.2. 3 Copiar código Nombre del Caso de Uso:

CU3.2.3 Copiar código


Descripción: El código seleccionado es almacenado en un búfer para su posterior duplicación. Escenarios: Ruta Básica Copiar código

1. El Desarrollador llama a la función Copiar. 2. [CONDICIÓN] Si existe código seleccionado. 2.1. Cargar al búfer el código seleccionado (esto lo hace el sistema operativo). 2.2. Asignar a una variable de control un estado que indique que existe código copiado (se propone el número 1). [FIN DE CONDICIÓN] 3. Salir.

Restricciones: Pre-Condición (Propuesto) Código seleccionado Debió seleccionarse primero un fragmento de

código para ser copiado. Post-Condición (Propuesto) Estado cambiado El estado del controlador de contenido (para

ver si existe código en el búfer) cambia.



128

act CU3.2.3 Copiar código

Inicio

Cargar al búfer el códigoseleccionado.

Variable de control = 1(código copiado)

Fin

El Desarrollador llama ala función Copiar

Existe código seleccionadoNo existe código seleccionado

Existe códigoseleccionado

Figura 5. 14 Diagrama de actividad de CU3.2.3 Copiar código.

CU3.2. 4 Cortar código Nombre del Caso de Uso:

CU3.2.4 Cortar código

Estado: Propuesto Versión: 1.0 Fase: 1.0 Autor: Erick Iduñate Creado en: 10/10/2007 Modificado en: 29/10/2007 Descripción: Al igual que Copiar código (C3.2.4), el código seleccionado es almacenado en un

búfer al elegir la opción Cortar para ser movido, con la diferencia de que el código elegido es eliminado de su lugar original.

Escenarios: Ruta Básica Cortar código

1. El Desarrollador llama a la función Cortar. 2. [CONDICIÓN] Si existe código seleccionado. 2.1. Cargar al búfer el código seleccionado (esto lo hace el sistema operativo). 2.2. Asignar a una variable de control un estado que indique que existe código que será cortado (se propone el número 2). [FIN DE CONDICIÓN] 3. Salir.

Restricciones: Pre-Condición (Propuesto) Código seleccionado Debió seleccionarse primero un fragmento de


129

código para ser copiado. Post-Condición (Propuesto) Estado cambiado El estado del controlador de contenido (para

ver si existe código en el búfer) cambia.


act CU3.2.4 Cortar código

Inicio

El Desarrollador llama ala función Cortar

Cargar al búfer el códigoseleccionado.

Variable de control = 2(código cortado)

Fin

No existe código seleccionado

Existe código seleccionado

Figura 5. 15 Diagrama de actividad de CU3.2.4 Cortar código

CU3.2. 5 Pegar código Nombre del Caso de Uso:

CU3.2.5 Pegar código

Estado: Propuesto Versión: 1.0 Fase: 1.0 Autor: Erick Iduñate Creado en: 10/10/2007 Modificado en: 29/10/2007 Descripción: El código contenido en el búfer tras el llamado de la función copiar o cortar es

insertado en el lugar que indique el cursor (o puntero del ratón). Escenarios: Ruta Básica Pegar código

1. El Desarrollador llama a la función Pegar. 2. [CONDICIÓN] Si el estado de la variable de control es 0 (libre). 2.1. Ejecutar "EL ESTADO ES 0". [FIN DE CONDICIÓN]


130

3. [CONDICIÓN ALTERNA] Si el estado de la variable de control es 1 (código copiado). 3.1. Ejecutar "EL ESTADO ES 1". [FIN DE CONDICIÓN ALTERNA] 4. [CONDICIÓN ALTERNA] Si el estado de la variable de control es 2 (código cortado). 4.1. Ejecutar "EL ESTADO ES 2". [FIN DE CONDICIÓN ALTERNA] 5. Salir.

Ruta Alterna EL ESTADO ES 0

1. [CONDICIÓN] Si existe código en el búfer (el código viene de una fuente externa - ver apartado "Desde fuente externa", Capítulo 3). 1.1. Pegar el código en el editor. 1.2. Contar el número de líneas pegadas. 1.2. [CICLO] (De 1 hasta el número de líneas pegadas). a. Situar un cursor en la línea correspondiente al número de iteración. b. Capturar el contenido de la línea. c. Agregar un comentario con la identificación de la línea. Ej.: /*id00345*/ d. Agregar en el registro un nuevo elemento <original> dentro de una nueva <linea> con el contenido de la línea y asignar al tipo la cadena ”reusada" (Ver Tabla 5.2 en el evento Copiar-Pegar línea base - se podrá cambiar manualmente después o en la configuración del sistema). e. Pasar a la siguiente línea. [FIN DE CICLO] [FIN DE CONDICIÓN]

Ruta Alterna EL ESTADO ES 1

1. Pegar el código en el editor. 2. Contar el número de líneas pegadas. 3. [CICLO] (De 1 hasta el número de líneas pegadas). 3.1. Situar un cursor en la línea correspondiente al número de iteración. 3.2. Capturar el contenido de la línea. 3.3. Buscar en el registro el identificador de la línea pegada y verificar su tipo en <ultimo>. 3.4. Asignar un nuevo identificador para cada línea pegada. Ej.: /*id00346*/ 3.5. Agregar en el registro un nuevo elemento <original> dentro de una nueva <linea> con el contenido de la línea pegada y asignar al tipo el indicado por la Tabla 5.2 en el evento "Copiar-Pegar". [FIN DE CICLO] 4. Cambiar el estado de la variable de control a 0 (libre).

Ruta Alterna D. EL ESTADO ES 2

1. Pegar el código en el editor. 2. Eliminar el código seleccionado para cortar. 3. [CICLO] (De 1 hasta el número de líneas pegadas). 3.1. Situar un cursor en la línea correspondiente al número de iteración. 3.2. Capturar el contenido de la línea. 3.3. Buscar en el registro el identificador de la línea pegada y verificar su tipo en <ultimo>. 3.4. Asignar un nuevo identificador para cada línea pegada. Ej.: /*id00346*/ 3.5. Agregar en el registro un nuevo elemento <original> dentro de una nueva <linea> con el contenido de la línea pegada y asignar al tipo el indicado por la Tabla 5.2 en el evento "Cortar-Pegar". [FIN DE CICLO] 4. Cambiar el estado de la variable de control a 0 (libre).

Restricciones: Pre-Condición (Propuesto) Código copiado o cortado Existe código almacenado en el búfer

(portapapeles). Post-Condición (Propuesto) Registro actualizado Se identificaron y comentaron en el código

todas las líneas generadas automáticamente.


131


act CU3.2.5 Pegar código

Inicio

El Desarrollador llama ala función Pegar

B. EL ESTADO ES 0 C. EL ESTADO ES 1 D. EL ESTADO ES 2

Fin

Variable = 2 (código cortado)

Variable = 1 (código copiado)

Variable = 0 (libre)

Figura 5. 16 Diagrama de actividad de CU3.2.5 Pegar código.

CU3.2. 6 Crear archivo/proyecto Nombre del Caso de Uso:

CU3.2.6 Crear archivo/proyecto


Descripción: Para crear un nuevo archivo o proyecto es necesario elegir la función Nuevo del IDE. Esta opción no genera código por sí sola, pero es indispensable para contener al mismo.

Escenarios: Ruta Básica Crear proyecto

1. El Desarrollador crea un nuevo archivo. 2. Crear un registro con el nombre original del archivo y una extensión propia de la herramienta de conteo (se propone .loc). 3. Salir.

Restricciones: Post-Condición (Propuesto) Archivo de registro creado Se crea un archivo de registro asociado al

nuevo archivo de código fuente.



132

act CU3.2.6 Crear archiv o/proyecto

Inicio

El Desarrollador crea unnuev o archiv o

Crear registro con nombre delarchiv o y una extensión .loc

Fin

Figura 5. 17 Diagrama de actividad de CU3.2.6 Crear archivo/proyecto.

CU3.2. 7 Guardar archivo/proyecto Nombre del Caso de Uso:

CU3.2.7 Guardar archivo/proyecto


Descripción: Cada proyecto y archivo debe ser guardado periódicamente para poder ser utilizado. Los cambios hechos en los mismos tomarán efecto hasta que esta acción sea ejecutada (además de la compilación, en los lenguajes que es necesaria).

Escenarios: Ruta Básica Guardar archivo/proyecto

1. El Desarrollador guarda un proyecto o archivo. 2. [LLAMADA] Ejecutar detección de líneas generadas (CU3.2.2). 3. [CONDICIÓN] Si Se guarda un proyecto. 4.1. Ejecutar "GUARDAR PROYECTO". [FIN DE CONDICIÓN] 4. [CONDICIÓN ALTERNA] Si se guarda un archivo. 4.2. Ejecutar "GUARDAR ARCHIVO". [FIN DE CONDICIÓN ALTERNA] 5. Salir

GUARDAR PROYECTO

1. [CICLO] (DE 1 HASTA EL NÚMERO TOTAL DE ARCHIVOS EN EL PROYECTO). 1.1. Ejecutar "GUARDAR ARCHIVO". 1.2. Moverse al Archivo siguiente. [FIN DE CICLO]

GUARDAR ARCHIVO

1. Abrir Archivo. 2. [CICLO] (De 1 hasta el número total de líneas del archivo). 2.1. Buscar el identificador de la línea en el registro.


133

2.2. [CONDICIÓN] Si el contenido de la línea en <original> es igual al contenido en <ultimo>. 2.2.1. Modificar el tipo del elemento <ultimo> con la cadena del tipo del elemento <original>. [FIN DE CONDICIÓN] 2.3. Moverse a la siguiente línea. [FIN DE CICLO]

Restricciones: Pre-Condición (Propuesto) Cambios realizados Se hicieron cambios en el código del archivo

que se pretende guardar. Post-Condición (Propuesto) Registro actualizado El registro es actualizado con información



act CU3.2.7 Guardar archiv o/proyecto

Inicio

El Desarrollador guardaun proyecto o archiv o.

Ejecutar detección delíneas generadas

(CU3.2.2)

GUARDAR PROYECTOGUARDAR ARCHIVO

Fin

Se guarda un archivo Se guarda un proyecto

Figura 5. 18 Diagrama de actividad de CU3.2.7 Guardar archivo/proyecto.


134

CU3.2. 8 Guardar archivo/proyecto como… Nombre del Caso de Uso:

CU3.2.8 Guardar archivo/proyecto como...


Descripción: El proyecto o archivo pueden guardarse con otros nombres, ya sea que tengan cambios o no, la información contenida es almacenada en nuevos archivos, es decir, la información original es duplicada y la restante es guardada, ambas en un archivo diferente al inicial. También es posible guardar por primera vez un archivo/proyecto con esta función.

Escenarios: Ruta Básica Guardar como…

1. El Desarrollador guarda un archivo con la opción guardar como... 2. [CONDICIÓN] Si el nombre del archivo no existe (se duplica el archivo original). 2.1. Ejecutar "EL ARCHIVO NO EXISTE". [FIN DE CONDICIÓN] 3. [CONDICIÓN ALTERNA] Si el nombre del archivo ya existe y se quiere sobrescribir. (Equivale a caso CU3.2.7 guardar). 3.1. Ejecutar "EL ARCHIVO EXISTE". [FIN DE CONDICIÓN ALTERNA] 4. Salir.

Alterna EL ARCHIVO NO EXISTE

1. Crear un registro con el nuevo nombre del archivo y la extensión .loc. 2. [CICLO] (De 1 hasta el número total de líneas en el archivo). 2.1. Almacenar la línea de código en el nuevo registro con su respectivo identificador (elemento <original>). 2.2. Buscar el identificador en el registro original. 2.3. Capturar el tipo de línea del elemento <ultimo> en el registro original. 2.4. Cambiar el tipo de línea del elemento <original> en el nuevo registro según la Tabla 5.2 para el evento "Copiar-Pegar". 2.5. Moverse a la siguiente línea [FIN DE CICLO] 3. [LLAMADA] Ejecutar detección de líneas generadas (CU3.2.2) para el archivo guardado.

Alterna EL ARCHIVO EXISTE

1. [LLAMADA] Ejecutar los pasos del caso CU3.2.7.

Restricciones: Post-Condición (Propuesto) Registro creado o actualizado El registro es actualizado con información

procedente de los cambios en el código o, si se duplicó el archivo, se creó un nuevo registro con toda la información del código en el editor.



135

act CU3.2.8 Guardar archiv o/proyecto como...

Inicio

El Desarrollador guardaun archiv o con la opción

guardar como...

ARCHIVO NO EXISTE ARCHIVO EXISTE

Fin

El nombre del archivo no existe El nombre del archivo ya existe

Figura 5. 19 Diagrama de actividad de CU3.2.8 Guardar archivo/proyecto como…

CU3.2. 9 Eliminar archivo/proyecto Nombre del Caso de Uso:

CU3.2.9 Eliminar archivo/proyecto


Descripción: Un archivo o proyecto pueden ser eliminados. Cuando esto sucede también se suprime con ellos el código que contienen.

Escenarios: Ruta Básica Eliminar

1. El Desarrollador elimina uno o todos los archivos de un proyecto. 2. [CONDICIÓN] Si hay más de un archivo por eliminar. 2.1. Ejecutar "ELIMINAR ARCHIVOS" [FIN DE CONDICIÓN] 3. [CONDICIÓN ALTERNA] Si sólo hay un archivo para eliminar. 3.1. Ejecutar "ELIMINAR LÍNEAS". [FIN DE CONDICIÓN ALTERNA] 4. Salir.

Alterna 1. [CICLO] (DE 1 HASTA EL NÚMERO TOTAL DE ARCHIVOS


136

ELIMINAR ARCHIVOS

SELECCIONADOS). 1.1. Ejecutar "ELIMINAR LÍNEAS". 1.2. Moverse al Archivo siguiente. [FIN DE CICLO]

Alterna ELIMINAR LÍNEAS

1. Abrir archivo. 2. [CICLO] (De 1 hasta el número total de líneas del archivo) 2.1. Buscar el identificador de la línea en el registro asociado. 2.2. Insertar o modificar (si existe) el elemento <ultimo> con contenido vacío y el tipo indicado por la Tabla 5.2 en el evento "Borrar". 2.3. Moverse a la siguiente línea. [FIN DE CICLO]

Restricciones: Pre-Condición (Propuesto) El archivo existe El o los archivos que se pretenden eliminar

existen y tienen un registro de conteo asociado.Post-Condición (Propuesto) Registro actualizado El registro es actualizado con información



act CU3.2.9 Eliminar archiv o/proyecto

Inicio

El Desarrollador eliminauno o todos los archiv os

de un proyecto

ELIMINAR ARCHIVOS ELIMINAR LÍNEAS

Fin

Hay más de un archivo para eliminar Sólo hay un archivo para eliminar

Figura 5. 20 Diagrama de actividad para CU3.2.9 Eliminar archivo/proyecto.


137

CU3.2. 10 Renombrar archivo/proyecto Nombre del Caso de Uso:

CU3.2.10 Renombrar archivo/proyecto


Descripción: Un Desarrollador puede cambiar el nombre de un archivo o del proyecto entero desde el ambiente de desarrollo.

Escenarios: Ruta Básica Renombrar archivo/proyecto

1. El Desarrollador cambia el nombre de un archivo o proyecto. 2. Localizar el archivo/proyecto de registro asociado. 3. Remplazar el nombre del archivo/proyecto de registro con el nuevo nombre.

Restricciones: Pre-Condición (Propuesto) Cambio desde IDE El cambio de nombre se tiene que hacer desde

el ambiente de desarrollo. Post-Condición (Propuesto) Archivo de registro

renombrado. El archivo o proyecto de registro es renombrado según el especificado.


act CU3.2.10 Renombrar arc...

Inicio

El Desarrollador cambiael nombre de un archiv o o

proyecto

Localizar elarchiv o/proyecto de

registro asociado

Remplazar el nombre delarchiv o/proyecto de

registro con el nuev onombre

Fin

Figura 5. 21 Diagrama de actividad para CU3.2.10 Renombrar archivo/proyecto


138

CU3.2. 11 Salir sin guardar Nombre del Caso de Uso:

CU3.2.11 Salir sin guardar


Descripción: Es posible que el Desarrollador elija cerrar el proyecto en curso sin guardar los últimos cambios.

Escenarios: Ruta Básica Salir sin guardar

1. El Desarrollador sale del proyecto sin guardar los últimos cambios. 2. Ejecutar "RESTAURAR CONTEO" 3. Salir.

Alterna RESTAURAR CONTEO

1. [CICLO] (DE 1 HASTA EL NÚMERO TOTAL DE LÍNEAS EN EL ARCHIVO) 1.1. Buscar el identificador de la línea en el registro asociado. 1.2. [CONDICIÓN] Si el contenido de la línea del archivo es diferente al contenido de <ultimo> en el registro. 1.2.1. Modificar el elemento <ultimo> con el contenido de la línea en el archivo. 1.2.2. [CONDICIÓN] Si el contenido de <ultimo> y el contenido de <original> es idéntico. a. Remplazar el tipo en <ultimo> con el tipo de <original>. [FIN DE CONDICIÓN] 1.2.3. [CONDICIÓN ALTERNA] Si el contenido de <ultimo> y <original> es distinto. a. Remplazar el tipo en <ultimo> con el valor de la Tabla 5.2 en el evento "Modificar". [FIN DE CONDICIÓN ALTERNA] [FIN DE CONDICIÓN] 1.3. Moverse a línea siguiente [FIN DE CICLO]

Restricciones: Pre-Condición (Propuesto) Cambios realizados Se hicieron cambios en el código del archivo

que se pretende guardar. Post-Condición (Propuesto) Registro restaurado Los últimos cambios hechos en el registro son

descartados, de acuerdo al último archivo fuente guardado.



139

act CU3.2.11 Salir sin guardar

Inicio

El Desarrollador sale delproyecto sin guardar los

últimos cambios

RESTAURAR CONTEO

Fin

Figura 5. 22 Diagrama de actividad para CU3.2.11 Salir sin guardar.

Como puede verse en los escenarios anteriores, la mayor parte de los métodos se

puede implementar independientemente de los demás, lo que significa que se pueden crear comandos especiales que contengan cada método y ser llamados, como se sugiere en el Apéndice C, con la ocurrencia de un evento determinado.

5.4 Conclusiones En este capítulo se mostró la forma en que los cambios sobre cada línea de código en un IDE pueden almacenarse en un registro basado en marcado de texto y, de esta manera, asignarle un tipo a la línea después de cada movimiento si es necesario.

Al definirse la Estrategia de Conteo fue posible identificar los Casos de Uso para una herramienta que la implemente. Además, se idearon procedimientos que llevan a la consecución de la implementación de la Estrategia respondiendo a cada Caso de Uso.


140

Conclusiones

141

Conclusiones

A la finalización de este trabajo de investigación se logró definir una Estrategia de Conteo de líneas de código en ambientes de desarrollo integrado, distinguiendo entre las líneas generadas automáticamente y las escritas por un Desarrollador. Esto cumple con el objetivo planteado.

Además de proponer el tipo de línea “generada” para ser agregada al estándar de clasificación de Humphrey [HUM95], se propuso también el tipo de línea “copiada”, atendiendo a las recomendaciones hechas en [PAR92] para ambos casos.

En cuanto a la hipótesis planteada, se demostró que llevar una clasificación automática de líneas de código al momento de la codificación ayuda a distinguir las líneas generadas automáticamente por un IDE y las escritas por el programador. Esto es posible mediante la detección de eventos de teclado y ratón dentro del ambiente de programación y almacenando inmediatamente esta información en un registro o bitácora para la clasificación de líneas escritas manualmente, mientras que las líneas generadas automáticamente se detectan por diferenciación como se explica en la Estrategia de Conteo en el capítulo 5. Se propuso una notación sencilla para la representación de procedimientos que involucren tomas de decisiones, iteraciones y llamadas a otros procedimientos. La Estrategia propuesta, al llevar la clasificación de las líneas de código de forma automática en el momento de la codificación y siendo flexible para modificar manualmente los tipos de línea en cualquier momento, reduce la posibilidad de cometer los errores


142

habituales y de provocar la confusión que se tiene cuando esta actividad se hace de manera tradicional.

Trabajos futuros

1. Diseñar e implementar una herramienta que cumpla con las características definidas en la Estrategia de Conteo propuesta.

2. Con la herramienta se podrá hacer un estudio sobre cuánto afecta a las estimaciones de tamaño y tiempo en un proyecto el no hacer una distinción entre las líneas generadas automáticamente, las copiadas y las escritas por el programador.

3. Analizar las APIs de extensión de otros ambientes de desarrollo para poder desarrollar una herramienta para varios IDEs.

4. Analizar y optimizar los métodos propuestos en cada evento para reducir la carga en memoria al ejecutarse el conteo y clasificación de líneas, de esta forma reducir también el tiempo de respuesta.

Apéndice A Análisis de IDEs

143


Para la elección del IDE (Ambiente de Desarrollo Integrado por sus siglas en inglés) en el que se desarrolla la tesis se analizaron tres de los IDEs de Java libres más conocidos: Eclipse, JDeveloper y JBuilder Foundation. Únicamente se pone atención en las Interfaces de Programas de Aplicación (en adelante APIs) que proporcionan para extender dichas IDEs, puesto que el motivo del análisis es encontrar el ambiente que puede ser más fácilmente extendido considerando que se pretende detectar eventos de teclado, ratón y generación de código.


144

Eclipse 3.2 [ECL07]

Eclipse es una comunidad de código abierto cuyos proyectos se enfocan en construir una plataforma de desarrollo abierto comprendida por marcos de trabajo extensibles, herramientas y tiempos de ejecución para construir, utilizar y administrar software a lo largo de su ciclo de vida. La comunidad está constituida por proveedores de tecnología, universidades, institutos de investigación y colaboradores independientes.

Está estructurado bajo el concepto de plug-ins7. Los plug-ins pueden definir puntos de extensión, que son lugares bien definidos donde otros plug-ins pueden agregar funcionalidad al ambiente de desarrollo.

Cada subsistema en la plataforma está estructurado como un conjunto de plug-ins que implementan alguna función clave. Algunos añaden características visibles a la plataforma usando el modelo de extensión. Otros proveen librerías de clases que se pueden usar para implementar extensiones al sistema. La SDK (acrónimo de Software Development Kit - Kit de Desarrollo de Software) de Eclipse, incluye la plataforma básica más dos herramientas principales que son útiles para el desarrollo de plug-ins.

Figura A. 1Arquitectura de Eclipse

7 Paquetes estructurados de código y/o datos que agregan funciones a un sistema. Las funciones se pueden agregar en forma de librerías de código, extensiones de plataforma o incluso documentación. [ECL06]


145

En la Figura A.1 se muestra la arquitectura del SDK de Eclipse con su plataforma básica y las herramientas para extensión:

• Workbench o mesa de trabajo. Es un plug-in que define un número de puntos extensión que permiten a otros plug-ins añadir acciones al menú y barras de herramientas, cuadros de diálogo, operaciones de arrastre, asistentes y vistas y editores personalizados.

o El Standard Widget Toolkit (SWT), es una caja de herramientas de bajo nivel independiente del sistema operativo que soporta la integración de plataformas y APIs portátiles.

o El marco de trabajo de interfaces de usuario JFace provee bloques de aplicación de un nivel más alto para soportar cuadros de diálogo, asistentes, acciones, preferencias de usuario y manejo de accesorios.

• Soporte de equipo. Plug-in que permite a otros definir y registrar implementaciones para programación por equipos, acceso a repositorios y manejo de versiones.

• Soporte de depuración. Permite implementar lanzadores y depuradores de programas específicos.

• Sistema de ayuda. Implementa la integración de documentación y un servidor web de ayuda. Define puntos de extensión que los plug-ins pueden usar para ampliar la misma ayuda u otra documentación. El servidor web de documentación facilita a los plug-ins referenciar archivos usando URLs basados en plug-ins en vez de URLs de sistemas de archivos.

• JDT (Java Development Tools - Herramientas de desarrollo de Java). Extienden la plataforma proveyendo características especiales para editar, ver, compilar, depurar y correr código Java. El JDT está instalado como un conjunto de plug-ins que están incluidos en el SDK.

• PDE (Plug-in Development Environment – Ambiente de desarrollo de plug-ins). Proporciona herramientas que automatizan la creación, manipulación, depuración y despliegue de plug-ins.

Oracle JDeveloper 10.1.3.2 [ORA07] IDE para construir aplicaciones orientadas a servicios “usando los estándares más recientes de Java, XML, servicios Web y SQL. […] Soporta el ciclo de vida de desarrollo completo con características integradas para modelar, depurar, probar, perfilar, ajustar y desplegar aplicaciones.”8.

8 Traducción libre del autor, tomado de [ORA07]


146

Oracle JDeveloper utiliza el Extension SDK, una API pública para extender y personalizar el entorno de desarrollo. Se pueden agregar componentes que van desde una nueva opción de menú o un asistente hasta un editor completo.

La arquitectura de JDeveloper es de alguna manera similar a la de Eclipse: varios módulos con diferentes objetivos integrados para formar un ambiente de desarrollo relativamente fácil de usar para el programador.

JSR-198 [JCP06]

La compañía Oracle desarrolló un API de extensión estándar para ambientes de desarrollo denominado JSR-198, que trata de generalizar el desarrollo de extensiones para IDEs de Java. JSR-198 permite a cualquier desarrollador de extensiones usar un API estándar común para integrar funcionalidad con cualquier IDE que soporte el estándar.

Oracle JDeveloper 10g soporta la API JSR-198 y es posible usar tanto la API de extensión de JDeveloper o la API de JSR-198 para hacer extensiones a JDeveloper.

Borland JBuilder Foundation [COD07]

La compañía Borland también tiene un IDE gratuito para Java llamado JBuilder Foundation, el cual puede ser extendido mediante el uso de las llamadas open tools. Éstas son similares a los plug-ins de Eclipse y a las extensiones de JDeveloper. Desafortunadamente la edición Foundation de JBuilder, es decir, la versión gratuita, dejó de recibir soporte desde su último lanzamiento en 2005. Actualmente Borland lanzó una edición 2007 de JBuilder, dedicada a contribuir con la comunidad Eclipse, con lo que aseguran tener la capacidad de hacer un desarrollo más rápido y confiable con Java para el código abierto y la Web.

Ya que Borland decidió darle apoyo a Eclipse – mediante herramientas de modelado, asistentes para proyectos, entre otros- y que ya no ofrece soporte a Foundation, se tomó la decisión de no seguir investigando su arquitectura.

Criterios para la elección de IDE

Eclipse es una plataforma que cuenta con un extenso y creciente número de usuarios, ya que, al ser libre, recibe soporte de toda la comunidad que lo integra y sus propios usuarios. La documentación existente está en constante actualización y se están desarrollando diariamente extensiones de todo tipo, lo que hace que se trate realmente de una comunidad de programadores que se ofrecen soporte y recursos mutuamente, todo esto de manera gratuita.

Oracle es una compañía reconocida dentro de las aplicaciones empresariales y, por ende, tiene suficiente soporte para poder hacer herramientas de calidad; sin embargo, en comparación con el auge que está teniendo Eclipse y todas las contribuciones que recibe


147

diariamente, resulta hipotéticamente más sencillo desarrollar una extensión en este último ambiente de desarrollo.

Por otro lado, la iniciativa de crear un estándar que normalice las reglas para extender un ambiente de desarrollo integrado ha sido fuertemente discutida y, aunque ya es aceptado el modelo de Oracle como estándar, actualmente se tienen pocas esperanzas en que sea adoptado por las compañías que ofrecen extender sus IDEs al usuario, ya que se piensa que las diferentes formas en que se puede agregar funcionalidad a éstos es lo que hace que los programadores se inclinen hacia un IDE o a otro en particular.[JCP06].

Por estas razones es que se eligió al IDE de Eclipse para ser estudiado más a fondo y ser utilizado como base para el desarrollo de una herramienta de conteo de LOC.

Conclusiones Cada IDE tiene una forma parecida de ser extendido, pero no idéntica, por lo que fue necesario identificar cuáles eran las ventajas y desventajas de los tres ambientes presentados: Eclipse, JDeveloper y JBuilder.

Dado que JBuilder dejó de ser un ambiente de desarrollo independiente y se orientó hacia la colaboración con Eclipse, la decisión para analizar más a fondo un IDE que sirva para el desarrollo de una herramienta de conteo de LOC queda sólo entre JDeveloper y Eclipse. Considerando que Eclipse es una de los ambientes de desarrollo con más adeptos y recibe soporte, contribuciones y actualizaciones constantemente y, al ver que el estándar JSR-198 propuesto por Oracle no genera aún un interés por ser adoptado por la mayoría de los IDEs, se decidió que Eclipse es la opción más viable para desarrollar una herramienta de conteo de líneas de código integrada a un ambiente de desarrollo con las características que propone este trabajo de tesis.


148

Apéndice B Generación de Código

149



150

Definiciones Alan Monnox define a los generadores de código en su libro “Rapid J2EE Development: An Adaptive Foundation for Enterprise Applications” (“Desarrollo Rápido en J2EE: Una Base Adaptable para Aplicaciones Empresariales”) [MON05] como “modelos de software que escriben software”, o visto de otra forma, “código que escribe código” [MON05]. De igual forma Jack Herrington, en su artículo “Are You Missing Out on Code Generation?” (“¿Se está perdiendo en la generación de código?”), como “la construcción automática de código de alto nivel (como Java, C#, etc.) a partir de una descripción de los requerimientos del código.”[HER03].

Ambos autores se refieren a aplicaciones cuyo propósito es la generación de código fuente desde la especificación de requerimientos de nuevas aplicaciones, mismos que son obtenidos de formularios y/o pantallas con elementos gráficos. Ejemplos claros de aplicaciones que implementan esta práctica son los ambientes de desarrollo integrado (IDE por sus siglas en inglés), que presentan asistentes para la generación de código; también existen herramientas generadoras que toman las especificaciones de los modelos definidos por el usuario como son diagramas UML, Warnier, entre otros.

Para Andrew Hunt y David Thomas existen dos tipos de generadores de código: pasivos y activos, que quedan definidos en su libro “The Pragmatic Programmer” [HUN00]. En el análisis que realizan tanto Retting y Fowler sobre la generación de código en “Reflection vs. Code Generation” (“Reflexión vs. Generación de Código”) [RET01] como Monnox en [MON05] resumen estos términos como sigue:

• Pasivos: Se ejecutan una sola vez proporcionando al programador un inicio rápido. Requieren algo de intervención humana para implementar código. Muchos IDEs proveen asistentes que utilizan este enfoque.

• Activos: La generación de código activa se refiere a la creación de código que

nunca tiene que ser modificado una vez generado. Si surge un problema, debe arreglarse en el generador de código, no en el código generado, esto sobrescribirá el código generado en su totalidad.

Este trabajo de tesis fue dirigido especialmente a los generadores de código pasivos, ya que son los utilizados por los ambientes de desarrollo integrado


151

Fuentes de generación automática de código Existen distintas formas de generar código automáticamente en un proyecto de software:

• Al comenzar una aplicación mediante ambientes de desarrollo integrado, el entorno de desarrollo lanza un asistente con cada nuevo proyecto para recopilar información con la que produce el código necesario de inicio.

• Al agregar componentes a un formulario. En los ambientes visuales se pueden utilizar formularios para diseñar las interfaces de usuario, donde se agregan componentes como botones, cuadros de texto, etiquetas, listas desplegables, etc., cada uno con capacidad de capturar un evento del ratón o del teclado y ejecutar ciertas acciones. Al momento que se coloca cada uno de los componentes, se genera código, una estructura que debe ser completada para que tenga funcionalidad.

• Con el uso de asistentes (wizards) en el proyecto iniciado. Cuando se quieren agregar clases en un lenguaje orientado a objetos, es posible recurrir a un asistente que pregunte por el nombre de la clase, su clase padre –si existe-, después sus métodos y variables. Todo esto es traducido a código automáticamente al finalizar el dialogo. Más adelante, se pueden agregar o modificar las características a petición del programador.

• Al convertir modelos de las herramientas de diseño de software hacia código.

Existen herramientas de modelado de software de las que se puede obtener código. Generalmente el diseñador reúne componentes visuales con características particulares en un proyecto de diseño. A partir de ahí se pueden exportar estos datos y transformarlos a código, mismo que tiene que ser completado para que pueda ser funcional.

Modelos de generación de código. Existen distintos modelos de generación de código, su utilización depende del objetivo y complejidad con que se quiere hacer una herramienta de generación, los modelos más comunes, descritos en [CGN03], son:

• Code mungers. Son los generadores de código más usados. Procesan archivos con código fuente y generan otros archivos de salida, por ejemplo, JavaDoc recorre el código de los archivos y analiza los comentarios para producir archivos HTML. En la Figura A.1 se muestra el flujo de generación de código.


152

Figura B. 1 Generación de Archivos de salida mediante code mungers

• Expansores de código en línea (inline). Se recurre al uso de un nuevo lenguaje.

Usualmente es un lenguaje existente con algunas extensiones de sintaxis. El expansor de código en línea es usado para convertir este lenguaje en código de producción en un lenguaje de alto nivel. Por ejemplo, un código en lenguaje C con SQL embebido puede ser usado como código de entrada para el generador, dando como resultado código fuente que haga una conexión a una base de datos. La figura 3.2 muestra el proceso que se sigue en el empleo de expansores de código en línea.

Figura B. 2 Proceso de generación de código mediante expansor de código en línea

• Generadores de clases parciales. Construye un conjunto de clases base para

implementar un diseño especificado en un archivo de definición. Estas clases base son usadas como plataforma para construir las clases de producción. Las clases base están diseñadas para hacer la mayor parte del trabajo de bajo nivel de la clase completa, dejando a la clase derivada libre de sobrescribir comportamientos específicos. En la figura A.3 se muestra que el generador lee un archivo de


153

definición, luego, usando un conjunto de plantillas, construye una o más clases base. Estas clases base son extendidas con clases derivadas. Todas las clases son compiladas juntas para construir un producto final.

Figura B. 3 Flujo del proceso de generación de código con generadores de clases parciales

• Lenguaje del dominio. Construcción de analizadores de lenguajes específicos de

dominio completo. La ventaja de éstos es que se tienen tipos, sintaxis y operaciones que se mapean directamente a los conceptos en un determinado dominio.

Generación de código en los ambientes de programación. Dentro de los ambientes de programación, se recurre a varios de los modelos anteriormente descritos para generar automáticamente código. Como ejemplo se tiene a JavaDoc para la documentación de código en páginas con formato HTML, donde se usa el modelo de code mungers, mismos que son empleados también para producir fragmentos de código fuente en archivos existentes.

Los ambientes de desarrollo cuentan con módulos que producen y/o dan formato a código fuente a partir de entradas con características específicas. El JDT (Java Developing Tooling) contenido en Eclipse, cuenta con clases e interfaces que pueden ser usadas para generar código. Así, un plug-in que recurre a estas clases debe mandar ciertos parámetros y se obtendrá como resultado código generado en Java. Por otro lado, existen generadores de código que pueden ser utilizados en cualquier ambiente de desarrollo y producir código en otros lenguajes.

Una extensión de un IDE también puede realizar su propia generación de código

mediante el uso de la clase PrintWriter en el paquete java.io de Java, misma que se


154

encarga de imprimir en un determinado destino (en este caso el editor de Java) cualquier cadena que se le envíe. De esta forma, al ocurrir un evento determinado las instancias de las clases generadoras hacen una valoración del evento ocurrido y envían al editor el código correspondiente.

Detectando eventos de generación de código automática. Existen esfuerzos por hacer que la generación de código automática se lleve a cabo

a través de generadores de código dedicados únicamente a este fin, con separación de modelo y vista. Como menciona Terence Parr en [TPA04]:

“Los traductores y otros programas generadores de código deberían usar

gramáticas de salida para generar texto porque cualquier estructura de salida se conforma a un lenguaje. La manifestación de gramática de salida más conveniente es una plantilla. Mientras que muchas plantillas existen, la mayoría no hacen cumplir la estricta separación de modelo y vista, por lo tanto, dejando completamente acoplada la lógica de traducción con la plantilla. La estricta separación permite que haya generadores de código con varios objetivos porque no puede haber lógica en la plantilla y no hay frases de salida en el código”.

Sin embargo, todavía son muchas las herramientas que generan código que no

recurren a este tipo de plantillas, sino que producen su propio código y lo arrojan al editor, mezclando el modelo con la vista, lo que dificulta la detección de este tipo de eventos, ya que habría que revisar y modificar el código de cada una de estas herramientas para notificar cuando está efectuándose la generación. Trabajo que resultaría interminable, considerando que a un IDE se le pueden embeber cualquier número de herramientas que generen código.

Una alternativa para detectar cuándo se está generando código sería modificar la

clase PrinterWriter, registrando el número de líneas generadas cada vez que se utilice la función de impresión; sin embargo, esto significaría alterar la base del código base de un paquete estándar de Java y, por consiguiente, aunque la función de impresión no sea utilizada específicamente para la generación de código hacia un editor, la función estaría tratando de registrar este evento.

Por estas razones, es que hasta el momento no es factible registrar el código

automáticamente generado en el momento en que éste es producido. Sin embargo, es posible detectar este código con otras estrategias, pero en un momento posterior a la ocurrencia del evento de generación.

Apéndice C Detección de Eventos en Java

155


Para determinar la factibilidad de utilizar una herramienta que detecte eventos de teclado y ratón, así como de llamadas a funciones de un ambiente de desarrollo integrado, se hizo un estudio de la detección de eventos para lenguaje Java en el IDE Eclipse 3.2


156

Definición “Un evento es la acción u ocurrencia detectada por un programa. Los eventos pueden ser acciones de un usuario, como hacer clic a un botón del ratón o presionar una tecla, u ocurrencias del sistema, como la falta de memoria. Muchas de las aplicaciones modernas, particularmente aquéllas que corren bajo ambientes Macintosh y Windows, se dice que son dirigidas a eventos, porque están diseñadas a responder a eventos.” [WEB07]

Recursos para la detección de eventos en Java Dentro de las Java Foundation Classes9 existe el AWT (Abstract Window Toolkit), paquete que soporta la programación interfaces gráficas de usuario (GUI por sus siglas en inglés). Incluye un conjunto de componentes de interfaces de usuario, un modelo de manejo de eventos, herramientas para graficar, manejo de capas y clases de transferencia de datos (para el manejo de las funciones de copiado y pegado). En forma conjunta, se usa el paquete SWING, el cual implementa un conjunto de componentes de GUI (botones, barras de desplazamiento, árboles, etc.) que permiten diseñar un solo conjunto de componentes gráficos utilizables en cualquier sistema operativo. Este trabajo fue dirigido hacia el estudio del ambiente de programación Eclipse, el cual sustituye el uso de AWT y Swing por SWT (Standard Widget Toolkit), este paquete está incluido en la base de Eclipse. Los desarrolladores de este IDE justifican la sustitución de AWT y Swing por la naturaleza de éstos, puesto que éstos implementan widgets10 en Java en vez de utilizar los proveídos por cada plataforma, lo que sí sucede con SWT, que usa widgets nativos de las plataformas. SWT puede detectar eventos de ratón y teclado como el presionar o soltar una tecla o un botón del ratón, hacer doble clic con el ratón, movimiento del ratón, la rueda del ratón, la selección de un texto, copiado y pegado, entre otros.

SWT puede ser empleado fácilmente para monitorear eventos en aplicaciones independientes, de la siguiente manera:

• Crear un Display que representa una sesión de SWT. Los displays son usados principalmente para manejar el ciclo de eventos de la plataforma y controlar la comunicación entre un hilo de la interfaz de usuario y otro hilo.

9 API estándar para proveer interfaces gráficas de usuario para programas de Java, se resume como JFC. 10 Término genérico para la parte de una GUI (Interfaz Gráfica de Usuario, pos sus siglas en inglés) que permite al usuario interactuar con la aplicación y el sistema operativo [WEB07].


157

• Crear una o más Shells, que servirán como ventana(s) principal(es) para la aplicación. Un shell es una ventana manejada por el administrador de ventanas de la plataforma del sistema operativo. Pueden moverse, cambiar de tamaño, minimizarse y maximizarse mientras corra la aplicación.

• Crear cualquier otro widget necesario dentro del shell. • Inicializar los tamaños y cualquier otro estado para los widgets. Registrar monitores

(listeners) para eventos del widget que necesiten ser manejados. • Abrir la ventana del shell. • Ejecutar el ciclo de envío de eventos hasta que ocurra una condición de salida, que

es generalmente cuando la ventana del shell se cierra. • Destruir el display.

De esta forma, los eventos dentro de la aplicación en curso son monitoreados y

tratados según se haya especificado hasta que la aplicación finalice. Cuando se trata detectar eventos de teclado en un editor dentro de Eclipse, ya sea

editor de texto, de Java o cualquier otro lenguaje de programación (Eclipse puede extenderse para ser un IDE de otros lenguajes además de Java), es posible recurrir a las llamadas key bindings (uniones de teclas). Se llama key binding a la asociación entre un comando y la combinación de teclas que debe invocar a ese comando. Fueron originalmente creadas como “atajos” para ejecutar operaciones que pueden ser invocadas de otra forma. Por ejemplo, la operación de guardar un archivo está definida por un comando, que es llamado al elegir del menú la opción “Save”, al presionar el botón de guardado de la barra de herramientas y al presionar la combinación de teclas Ctrl + S (esta combinación fue previamente registrada como key binding); suponiendo que se quisiera guardar un archivo mediante la combinación de teclas Ctrl + G, que es más común en ambientes en español, se debe registrar como key binding y asociarse al comando de guardado. La figura C.1 muestra el cuadro de diálogo Keys en las preferencias del IDE, para asignar comandos a las secuencias de teclas elegidas, en este caso Ctrl + G.


158

Figura C. 1 Asociación de la secuencia de teclas Ctrl+G con el comando Save.

El grupo Command contiene la categoría en la que se engloba el comando a asociar, en el ejemplo se escogió file porque se quiere trabajar sobre un único archivo. El nombre del comando se elige de una lista de comandos asociados a las operaciones sobre un archivo, en este caso la opción save es la indicada. Se puede ver que ya hay una secuencia de teclas asociada al comando save: Ctrl+S, que es la predeterminada en la mayoría de entornos en inglés. Dentro del grupo Key Sequence, el nombre de la secuencia debe ser Ctrl+G. Debe ser definido un contexto dentro del cual opera el comando a ejecutar, aquí se eligió Editing Java Source, lo que indica que sólo cuando se esté trabajando en el editor de Java entrará en acción el comando save al presionar la secuencia de teclas Ctrl+G. Por defecto, existen numerosos comandos y secuencias que ya están registrados como key bindings, pudiendo realizar combinaciones entre ellos. Además, es posible programar nuevos comandos y registrarlos para ser llamados ya sea por elementos de menú, botones o secuencias de teclas. Los comandos, luego de ser programados, se declaran en el punto de extensión org.eclipse.ui.commands, especificando su nombre, identificación, definición, etcétera para que pueda ser reconocido y estar disponible para ser llamado.


159

Una vez programado y declarado un comando, se puede asociar a una secuencia de teclas en el punto de extensión org.eclipse.ui.bindings, que también requiere de información como identificación, nombre, secuencia, entre otros. En conclusión, es posible capturar los eventos de teclado dentro de un editor de código en un ambiente de programación. La capacidad de agregar comandos y relacionarlos con secuencias de teclas puede usarse para la clasificación de líneas de código al momento de escribir código en un editor dentro del IDE, como se explica en el siguiente apartado.

Empleo del manejo de eventos en la clasificación de líneas. La intención de detectar los eventos que ocurren en determinado entorno es la de registrar cuando una línea de código está siendo escrita, modificada o borrada en un editor de programación, así como el uso de las funciones de copiar, cortar y pegar. Partiendo de esta idea se puede pensar en usar key bindings que ejecuten comandos que verifiquen si se ha escrito una línea nueva, se ha modificado o borrado una línea existente. Un primer acercamiento podría ser interpretar que cada vez que se presiona la tecla de retorno (Enter) es porque se acaba de escribir una línea nueva, entonces, se invocaría a un comando que revisara si existe código entre el salto de línea y el inicio de la misma y que no se trate de un comentario, lo que significaría que efectivamente se trata de una línea física. Este mismo comando incrementaría una cuenta de líneas nuevas. Al final, se tendría el total de líneas nuevas en un archivo con base en el número de veces que se presionó la tecla Enter para dar un salto de línea en una línea física. Otra posibilidad es tener un key binding para cada vez que se oprima la tecla punto y coma (;), delimitador común en gran parte de los lenguajes de programación. Así, al momento de oprimir ‘;’ se ejecutaría un comando que incremente una cuenta de líneas lógicas. Lo mismo puede suceder con otras teclas como la de retroceso y suprimir, verificando si ha habido cambios en una línea, o posiblemente su eliminación. Al inicio de este trabajo se habló de registrar los movimientos en el editor dentro de una bitácora, también esto es posible usando key bindings, cualquier movimiento ejecutado con el teclado puede ser registrado empleando comandos especiales de guardado, donde la parte de la información contenida en el editor –una línea de código- se guarde en un archivo, por ejemplo, XML. Cabe recordar que el uso de comandos no está limitado al uso exclusivo de key bindings, sino también se pueden llamar desde elementos de menú, vistas y botones de las barras de herramientas. Incluso, un comando puede responder a un evento de copiado y


160

pegado hecho con el ratón, identificando desde la información que fue seleccionada, la cantidad de líneas que ésta representa, hasta el destino que tuvo. El empleo que puede darse a los comandos es aparentemente ilimitado, lo que contribuye al desarrollo de extensiones con características propias de una herramienta de conteo de líneas de código.

Apéndice D Estrategias Descartadas

161


Debido a que en el transcurso de esta investigación se encontraron algunos problemas para poder implementar la estrategia inicial propuesta (detección de líneas generadas y marcado de texto), se idearon otras estrategias en un esfuerzo por solucionar los problemas iniciales. A continuación se expone cada una de ellas.


162

Marcado de texto (estrategia inicial). La primera idea de solución fue desarrollar una herramienta que monitoree todos los eventos ocurridos en el editor de código, enviando una copia de cada línea de código contenida en él a un repositorio en formato XML y asignándole un atributo que indique el tipo de línea de que se trata, pudiendo ser: nueva, cambiada, reusada, copiada, generada o incluso borrada. Por ejemplo: al utilizar un asistente para la creación de una clase, las líneas generadas automáticamente por éste deben registrarse en el depósito como de tipo “generada”; de la misma forma, cuando el programador termine de escribir una línea de código, se debe registrar en el depósito como una línea “nueva”.

Cada vez que se hace un cambio en el código, la línea afectada debe ser comparada contra su equivalente en el archivo XML y, de ser necesario, cambiar su tipo según lo especificado en el análisis de clasificación de líneas (ver tabla 3.1, Capítulo 3).

A petición del usuario se realiza un conteo de líneas de código, generando un

reporte que indique el número y tipos de líneas contenidas en el proyecto.

Problemas encontrados. Como se menciona en el Apéndice B, “Generación de Código”, todavía son muchas las herramientas que generan código que no recurren a módulos dedicados únicamente a recibir parámetros para interpretarlos y producir código, sino que producen su propio código, mezclado con la lógica del programa, y lo arrojan al editor, lo que dificulta la detección del evento de generación automática de código, ya que habría que modificar cada una de estas herramientas para notificar cuando está efectuándose la generación automática. Trabajo que resultaría interminable, considerando que un IDE puede contar con cualquier número de herramientas que generen código. Por esta razón no es factible que se intente detectar si un asistente o formulario está generando código en el preciso momento en que lo hace. Por lo tanto, tampoco es factible que las líneas producidas de esta manera sean clasificadas automáticamente en el repositorio. Por otro lado, surgieron contratiempos para la detección de eventos del ratón y teclado, ya que la información referente al tema, aunque es suficiente, se encuentra dispersa y no ha sido enfocada a ser utilizada dentro de un editor de código, por lo que se llevó bastante tiempo en encontrar la información presentada en este documento. Estos problemas dieron paso a pensar en una primera estrategia alterna, que es la segunda aquí presentada.


163

Identificación de líneas generadas por diferenciación. Una posible solución al problema de la identificación de líneas de código generadas automáticamente es ignorarlas momentáneamente, dejando su conteo para cuando así lo solicite el programador. En esta segunda estrategia se deja la tarea de conteo y clasificación a la detección de los demás eventos dentro del editor de código, ajenos a la generación automática de código. De esta forma, monitoreando el empleo de la tecla Enter como delimitadora de líneas de código escritas por el programador, es posible contar las líneas nuevas en un proyecto, ignorando las líneas en blanco y los comentarios. Cabe recordar que [HUM95] recomienda ampliamente hacer coincidir las líneas físicas con las líneas lógicas al momento de codificar, para facilitar su conteo. Al terminar la edición de código se tiene ya un total de líneas nuevas. Al utilizar algoritmos de coincidencias de cadenas de texto como diff [HUNT76], se obtienen el total de líneas base, cambiadas y borradas, además de un supuesto número de líneas nuevas. Este total de líneas nuevas representa a las líneas escritas por el programador más el total de líneas generadas por el ambiente de programación. Finalmente, se deben descontar las líneas nuevas obtenidas inicialmente del total de líneas nuevas reportadas después de la aplicación del algoritmo diff, dando como resultado el total de líneas generadas. Esto se representa de la siguiente manera

generadasrealesnuevasdiffnuevas += __ Donde: nuevas_diff = número de líneas nuevas obtenidas por el algoritmo diff. nuevas_reales= número de líneas nuevas contadas durante la codificación generadas= número de líneas generadas por el ambiente de programación Por tanto:

realesnuevasdiffnuevasgeneradas __ −= Para el caso del código copiado, ya existen plug-ins que detectan estos eventos. De esta forma, las líneas que provengan de esta acción pueden ser contadas automáticamente como “copiadas” (para ver todas las opciones consultar la tabla 1.2) y también deberán ser descontadas del total de líneas identificadas como nuevas por el algoritmo diff. Riesgos detectados. Al contar líneas a partir del número de veces que se presionó la tecla Enter se corren grandes riesgos. Un programador utiliza esta tecla no sólo cuando termina de escribir una línea nueva, sino también para dar formato a código existente. Por ejemplo, es posible que una línea base quiera ser separada de su línea siguiente para facilitar el entendimiento del código, por lo que el programador se sitúa al final de la línea y presiona una vez la tecla Enter. Si se sigue esta estrategia al pie de la letra, el sistema reportará una línea nueva inexistente.


164

Un segundo ejemplo es que una línea nueva puede ser contada, luego borrarse y posteriormente volverse a escribir, lo que haría que cuente como nueva otra vez. Evidentemente se trata de la misma línea, la cual debe ser contada sólo una vez, pero con esta estrategia, la línea contaría como dos líneas nuevas. Como estos dos ejemplos, pueden surgir una gran cantidad de escenarios más, en los que el simple hecho de detectar la ocurrencia de un evento no son suficiente indicativo de que una línea sea nueva. Tal vez se piense que se puede sustituir la ocurrencia del evento de presión de la tecla Enter por el de la presión de “;”, pero los riesgos descritos en los dos ejemplos anteriores pueden ser los mismos o incluso mayores. Los eventos de un teclado dentro del editor al momento de codificar pueden tener innumerables combinaciones y situaciones. El tratar de hacer un conteo basado únicamente en el número de veces que se presiona una tecla supone una gran cantidad de escenarios, los cuales tendrían que ser ampliamente analizados antes de implementar una estrategia de este tipo.

Manejo de versiones internas La tercera estrategia concebida para atacar el problema de conteo de líneas de código toma algunas de las partes de las estrategias anteriores. Esta vez se dejan de lado los eventos dentro del editor y se recurre al respaldo de versiones internas, previas a la liberación del código. Cuando un programador hace un proyecto de software, es común que guarde su proyecto varias veces antes de liberar una versión. Esto puede ser aprovechado generando archivos con el código del proyecto para que sirvan como una bitácora, comparando en cada ocasión entre cada una de las versiones que se produzcan y reportando los cambios, esto tantas veces como se salve el proyecto; lo que daría como resultado un historial de cambios antes de la liberación y, al final, un conteo de líneas de código apegado a lo sucedido al codificar. La figura D.1 muestra cómo podría funcionar un sistema que maneje versiones internas o preliminares. Después de empezar a desarrollar, el programador guarda su trabajo, en este momento el sistema genera una copia de los archivos con código del proyecto, cambiando de versión cada vez que se haga el guardado. Posteriormente se hace el conteo de líneas de código y se compara el código con la versión anterior, clasificando líneas nuevas, cambiadas y borradas. Este procedimiento se repite tantas veces como se guarde el proyecto, al final se obtiene el total de cada uno de los tipos de línea del código.


165

Figura D. 1 Diagrama de flujo de un sistema de manejo de versiones internas.

A partir de esta idea general, la estrategia ahora se enfoca a la distinción entre el código generado por el ambiente de programación y el código escrito por el programador. Se trata de hacer un plug-in que agregue dos tipos de guardado de versiones del proyecto:

• Para código generado automáticamente, la primera opción genera archivos con un nombre que indique que parte del código fue generado por la herramienta (Ej. Clase1GenV1.ver o Clase1V1.gen)

• Para código agregado por el programador, usar la segunda opción de guardado, con el correspondiente nombre (Ej. Clase1NewV2.ver o Clase1V2.new)

De esta forma, cada vez que se genere código automáticamente, el desarrollador

debe guardar de inmediato el proyecto mediante la primera opción de guardado, “guardar código generado”, antes de continuar con la codificación. Igualmente, después de haber escrito líneas de código de forma manual, se debe guardar el proyecto ahora por medio de la segunda opción, “guardar modificaciones”. Es necesario que se guarde por la opción “guardar modificaciones” justo antes de volver a usar un asistente para asegurar que no se pasó por alto ninguna modificación.

Cada vez que se recurre a uno de los dos tipos de guardado, lo que procede es usar

un algoritmo de comparación de cadenas de texto para ver los cambios entre cada versión. Por ejemplo, la diferencia entre una versión nueva usando la opción de guardado de código generado automáticamente con una versión previa será el número de líneas “generadas” agregadas al proyecto.


166

Figura D. 2 Ejemplo del empleo de versiones preliminares

En la figura D.2 se muestra un ejemplo de cómo debe funcionar la estrategia de versiones preliminares implementada. Suponiendo que se al inicio del proyecto se usó un asistente que generó 3 líneas de código, el usuario guardó mediante la opción “guardar generadas”, lo que creó un archivo de nombre Clase1V1Gen.ver. Debe haber un módulo que analice el código y reporte el tipo de líneas contenidas en él, con base en el nombre del archivo. Para el primer caso se observa que el archivo contiene líneas generadas porque lleva en su nombre la cadena de 3 caracteres “Gen”, por tanto el resultado es de 3 líneas generadas agregadas en la primera iteración, para un total de 3 líneas generadas. Después el programador decide guardar mediante la opción “guardar modificaciones”, lo que genera un segundo archivo de nombre Clase1V2New.ver. Nótese que esta vez existe la cadena “New” en el nombre del archivo, lo que indica que el código que se encuentra diferente de la versión anterior fue escrito por el programador. Al analizar el contenido se tienen 5 líneas totales, a las que se descuentan las 3 líneas que se tenían anteriormente, dando como resultado 2 líneas, que son clasificadas como “nuevas” por ser consideradas como escritas por el programador. El total de líneas del proyecto es de 3 generadas y 2 nuevas. Por último, se guarda una versión final después de usar un asistente, por lo que se usa la opción “guardar generadas” y se produjo el archivo Clase1V3Gen.ver. El resultado del conteo es de 6 líneas, descontando 5 líneas que se tenían en el archivo anterior, lo que arroja una línea agregada de tipo “generada”. El total de líneas es de 4 generadas y 2 nuevas. Este pequeño ejemplo muestra que la estrategia puede ser usada para separar código generado automáticamente del escrito por el programador. Al igual que en la alternativa anterior, si se usa un algoritmo de comparación de cadenas como diff, es posible detectar líneas cambiadas y borradas. Una tercera opción de guardado puede ser empleada si se quieren considerar las líneas copiadas. De igual forma que las otras opciones, ésta deberá dar un nombre


167

descriptivo a los archivos que produzca, por ejemplo: Clase1V1Cop.ver. La diferencia con la versión anterior dará como resultado el total de líneas copiadas. Riesgos detectados Esta estrategia depende principalmente intervención del usuario, ya que es él quien decide en qué momento guardar su proyecto. Así, si hay una omisión al salvar, es muy probable que el conteo de líneas no sea el correcto.

Ejemplos:

• El usuario no guardó el proyecto inmediatamente después de generar código, sólo hasta que escribió otra parte. En este caso las líneas que se cuentan van a ser clasificadas como “generadas”, aunque algunas de ellas hayan sido escritas por el programador.

• El usuario no escoge la opción correcta de guardado, lo que llevó al sistema a

identificar el código nuevo como generado o viceversa. Al igual que en la primera opción, el conteo se vería alterado, clasificando erróneamente las líneas más recientes.

El equivocarse u olvidar constantemente el tipo de guardado que se debe hacer

puede llevar a hacer un conteo con resultados demasiado desviados de los reales. Lo ideal sería que cada vez que se use un asistente que genere código,

inmediatamente se use el botón de guardado de proyecto con la opción de código generado, y, después de agregar código manualmente, antes de volver a usar asistentes de generación, guardar el proyecto con la opción de código agregado por el programador. Sin embargo, se da el mismo caso de la detección del evento de generación de código, habría que modificar cada formulario, asistente, etc., para que notifique el momento en que se genera código.


168

Glosario de Términos

169

Glosario de Términos API Del inglés Application Program Interface (Interfaz de Programas de Aplicación). Conjunto de

rutinas, protocolos y herramientas para la construcción de aplicaciones de software. Una buena API facilita el desarrollo de un programa proveyendo los bloques de construcción. Un programador reúne esos bloques. [WEB07]

Arrastrar En entornos gráficos de usuario, consiste en apuntar con el ratón o dispositivo señalizador a un determinado objeto, arrastrarlo mediante la presión constante del botón izquierdo del ratón hasta su nueva posición, donde, al dejar de hacer presión en el botón, se situará el objeto. [LWP07]

Asistente (wizard)

Programa que guía al usuario, paso a paso y de forma instructiva, en la realización de un proceso. [LWP07]

Atributo Contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto, y cuyo valor puede ser alterado por la ejecución de algún método. [LWP07]

Bitácora En este documento se usa esta palabra para referirse al almacén creado por un Contador de Líneas. La bitácora contiene la información de cada línea de código de un proyecto de software. En el documento se usa como sinónimo de registro.

Carácter Cualquier signo -letra, número o símbolo--- que puede visualizarse en una pantalla e imprimirse. [LWP07]

Caso de Uso Artefactos de UML utilizados en la fase de captura de requerimientos de un proyecto de software. Sirven para representar la forma en que funciona un negocio y también para especificar la forma en que un nuevo proyecto de software debe funcionar. [ODO05]

CMM El CMM para software (CAPABILITY MATURITY MODEL - Modelo de Capacidad de Madurez) es el modelo del SEI (Software Engineering Institute) que las organizaciones pueden usar para determinar sus capacidades para desarrollar o mantener software, basado en un proceso de mejoramiento continuo en la organización. [LWP07]

COCOMO Constructive Cost Model. Un método para evaluar y/o estimar el costo para el desarrollo de software. [WEB07]

Comando Instrucción a una computadora o dispositivo para realizar una tarea específica. Los comandos vienen en distintas formas. Pueden ser: palabras especiales que un programa entiende, teclas de función, opciones de un menú, botones u otros objetos gráficos en pantalla. [WEB07]


170

Complejidad ciclomática

Introducida por Thomas McCabe en 1976, mide el número de rutas linealmente independientes en un módulo de un programa. Esta medida provee un número ordinal que puede ser comparada a la complejidad de otros programas. [SEI07]

Copiar Copiar una pieza de información a un sitio temporal. En el procesamiento de texto, por ejemplo, “copiar” se refiere a duplicar una sección de un documento y colocarla en el búfer (algunas veces llamado “portapapeles”). Después de copiar, se puede remover el contenido del búfer al pegarlo en otro lado. [WEB07]

Cortar Remover un objeto de un documento y colocarlo en el búfer. En el procesamiento de texto, por ejemplo, “cortar” se refiere a mover una sección de texto de un documento a un búfer temporal. Ésta es una forma de borrar texto. De cualquier forma, ya que el texto es transferido al búfer, no se pierde definitivamente. Se puede copiar del búfer a otra parte en el documento o en otro documento, a esto se le llama “pegar”. [WEB07]

CSV Siglas en inglés de Valores Separados por Coma. Un tipo de formato de datos en el que cada porción de datos se separa por una coma. Es un formato popular para transferir datos entre aplicaciones, ya que la mayoría de los sistemas de bases de datos son capaces de importar y exportar datos delimitados por comas. [WEB07]

Desarrollador-Programador-Usuario

Persona que diseña, escribe y/o depura programas de ordenador o computadora, es decir, quien diseña la estrategia a seguir, propone las secuencias de instrucciones y/o escribe el código correspondiente en un determinado lenguaje de programación. [LWP07] Estos tres términos se usan a lo largo del documento como sinónimos.

Deshacer Regresar a un estado previo “deshaciendo” los efectos de uno o más comandos. El comando Deshacer es una característica valiosa contenida por muchos productos de software. Permite probar comandos desconocidos con menor riesgo, porque siempre es posible regresar a un estado anterior. También, si accidentalmente se presiona una tecla equivocada, se puede deshacer el error. [WEB07]

Dígito Carácter simple en un sistema de numeración. En el sistema decimal, los dígitos van del 0 al 9. En el sistema binario, los dígitos son el 0 y el 1. [LWP07]

Eclipse Eclipse es una comunidad de código abierto cuyos proyectos se enfocan en construir una plataforma de desarrollo abierto comprendida por marcos de trabajo extensibles, herramientas y tiempos de ejecución para construir, utilizar y administrar software a lo largo de su ciclo de vida. La comunidad está constituida por proveedores de tecnología, universidades, institutos de investigación y colaboradores independientes. [ECL07]

Enter Tecla que mueve el cursor al inicio de la siguiente línea, o regresa el control a cualquier programa que esté en ejecución. Luego de que un programa solicita información del usuario generalmente no responde a su entrada hasta que éste presiona la tecla Enter o Retorno. [WEB07]

Escenario Secuencias hipotéticas de eventos, construidos con el propósito de centrar la atención en el proceso causal y en los puntos de decisión. [KAH67]

Glosario de Términos

171

Estrategia Conjunto de las reglas que aseguran una decisión óptima en cada momento. [RAE07]

Evento Acción u ocurrencia detectada por un programa. Los eventos pueden ser acciones de un

usuario, como hacer clic a un botón del ratón o presionar una tecla, u ocurrencias del sistema, como la falta de memoria. Muchas de las aplicaciones modernas, particularmente aquéllas que corren bajo ambientes Macintosh y Windows, se dice que son dirigidas a eventos, porque están diseñadas a responder a eventos. [WEB07]

HTML Siglas en inglés de Lenguaje de Marcado de HiperTexto. Lenguaje usado para crear documentos en la Web. El HTML define la estructura y capa de un documento Web usando una variedad de etiquetas y atributos. [WEB07]

IDE De Integrated Development Environment - Ambiente de Desarrollo Integrado. Un ambiente de programación integrado a una aplicación de software que provee un constructor por una Interfaz Gráfica de Usuario (GUI), un editor de texto o código, un compilador y/o intérprete y un debugger(corrector). Visual Studio, Delphi, JBuilder, FrontPage y DreamWeaver son ejemplos de IDEs [WEB06]

Ingeniería de Software

Disciplina de las Ciencias Computacionales concerniente al desarrollo de grandes aplicaciones. La Ingeniería de Software no sólo cubre aspectos técnicos de construcción de sistemas de software, sino que también cubre aspectos de administración como la dirección de equipos de programación, planeación y presupuesto. [WEB07]

Internet Red global que conecta millones de computadoras. Más de cien países están ligados para intercambio de información, noticias y opiniones. [WEB07]

JBuilder IDE de lenguaje Java desarrollado por la compañía Borland, actualmente extiende la funcionalidad de Eclipse. [COD07]

JDeveloper IDE para construir aplicaciones orientadas a servicios usando los estándares más recientes de Java, XML, servicios Web y SQL. Soporta el ciclo de vida de desarrollo completo con características integradas para modelar, depurar, probar, perfilar, ajustar y desplegar aplicaciones. [ORA07]

Key binding Asociación entre un comando y la combinación de teclas que debe invocar a ese comando. Fueron originalmente creadas como “atajos” para ejecutar operaciones que pueden ser invocadas de otra forma.[ECL07]

LGA Acrónimo de Líneas Generadas Automáticamente

LOC Acrónimo de Line of Code – “Línea de Código”.

Método Proceso o camino sistemático establecido para realizar una tarea o trabajo con el fin de alcanzar un objetivo predeterminado. [DEF07]


172

Pegar Copiar un objeto desde un búfer (o portapapeles) a un archivo. En procesamiento de palabras,

los bloques de texto se mueven de un lugar a otro mediante copiado y pegado. Cuando se corta un bloque de texto, el procesador de palabras remueve el bloque desde el archivo de origen y lo coloca en un área de almacenamiento temporal (un búfer). Entonces se puede pegar el material contenido en el búfer en otro lado. [WEB07]

Propiedades (de componente)

Características de un objeto. En muchos lenguajes de programación el término “propiedad” es usado para describir atributos asociados a una estructura de datos [WEB07]. En los ambientes de desarrollo integrado, las propiedades de un componente se pueden mostrar en un panel exterior al editor de código.

PSP Acrónimo de Personal Software Process- Proceso de Software Personal. [HUM95]

Registro En este documento se usa esta palabra para referirse al almacén creado por un Contador de Líneas. El registro contiene la información de cada línea de código de un proyecto de software. En el documento se usa como sinónimo de bitácora.

Rehacer Proceso inverso a la acción de Deshacer una acción o comando.

Retroceso Carácter que causa que el cursor se mueva hacia atrás un espacio, posiblemente borrando el carácter anterior. La mayoría de los teclados tienen una tecla Retroceso que invoca éste carácter. [WEB07]

SEI Siglas en inglés del Instituto de Ingeniería de Software. Centro de investigación y desarrollo financiado federalmente, patrocinado por el Departamento de Defensa de los E.E.U.U. y operado por la Carnegie Mellon University.

Seleccionar código

Elegir un objeto con el fin de manipularlo de alguna forma. En muchas aplicaciones se pueden seleccionar bloques de texto posicionando el cursor en un punto determinado y arrastrándolo sobre el bloque de texto. [WEB07]

Suprimir Remover o borrar. Por ejemplo, borrar un carácter significa removerlo de un archive o borrarlo de la pantalla. [WEB07]

Tipificación de líneas de código

Asignar un tipo o clasificación a una línea de código. Los tipos de línea empleados en este documento son: “base”, “borrada”, “nueva”, “cambiada”, “reusada”, “copiada” y “generada”.

TSP Siglas en inglés de Proceso en Equipo de Software (Team Software Process). Proceso de software creado por Watts Humphrey, del SEI, para proyectos en equipo.

UML Siglas en inglés de Lenguaje de Modelado Unificado (Unified Modeling Language), un lenguaje notacional de propósito general para especificar y visualizar proyectos de software orientados a objetos. [WEB07]

XML Viene de eXtensible Markup Language (Lenguaje de Marcado Extensible), una sintaxis que describe cómo agregar estructura a la información. Un lenguaje de marcado es una especificación que adhiere nueva información a la ya existente mientras que se mantienen los dos conjuntos de información por separado. [WES02]

Referencias

173

Referencias [ALB83] Alan Albrecht, “Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation”, IEEE Software, 1983 [CAM06] SourceMonitor, Campwood Software. http://www.campwoodsw.com 2006 [CCC05] Tim Littlefair, CCCC C and C++ Code Counter http://sourceforge.net/projects/cccc 2005 [CGN03] “Code Generator Models”, Code Generation Network, http://www.codegeneration.net/tiki-index.php?page=ModelsIntroduction, 2003 [COD07] CodeGear, JBuilder 2005 Foundation y JBuilder 2007, Borland http://www.codegear.com/Products/JBuilder/tabid/102/Default.aspx, 2007 [CHA04] Christian Charras, Thierry Lecroq; “Handbook of Exact String-Matching Algorithms”, King's College London Publications, 2004 [DAN06] Joseph A. Dane, "Modular Program Size Counting”. University of Hawai’i, December, 1999. LOCC v5.1 2006 [DEF07] Definición de “método”, http://www.definicion.org/metodo [ECL07] Eclipse 3.2 por Eclipse Foundation http://www.eclipse.org, 2007 [GOL04] Kurmanadham V.V.G.B. Gollapudi, “Function Points or Lines of Code: An Insight”, Global Microsoft Business Unit, Wipro Technologies, 2004. [HAY97] Will Hayes, James W. Over; “The Personal Software Process (PSP): An Empirical Study of the Impact of PSP on Individual Engineers”, December 1997 [HER03] Jack Herrington, “Are You Missing Out on Code Generation?”, DevX.com, http://www.devx.com/Java/Article/15511, Abril 2003, última consulta: Noviembre 2006. [HUM95] Watts S. Humphrey, “A Discipline for Software Engineering”, (Addison-Wesley), 1995. [HUM00] Watts S. Humphrey, “The Personal Software Process (PSP)” – Technical Report – Carnegie Mellon Software Engineering Institute. 2000 [HUN00] Andrew Hunt, David Thomas, “The Pragmatic Programmer”, Addison-Wesley, 2000.

174

[HUNT76] J.W. Hunt, M.D. McIlroy, “An Algorithm for Differential Comparison”; Department of Electrical Engineering, Stanford University; Bell Laboratories, New Jersey; 1976 [JCP06] The Java Community Process, “JSR#198 A Standard Extension API for Integrated Development Environments Final Approval Ballot” http://www.jcp.org/en/jsr/results?id=3608, 2006 [KAH67] Kahn, Herman; Wiener, Anthony. “The Year 2000”, 1967 [LWP07] Diccionario Informático de La Web del Programador, Comunidad de Programadores, http://www.lawebdelprogramador.com/diccionario/, 2007 [MANN06] Zoltán Ádám Mann, “Three Public Enemies: Cut, Copy, and Paste”, Budapest University of Tecnology and Economics, Revista “Computer”, volumen 39, número 7, IEEE, Julio 2006. [MON05] Alan Monnox, “Rapid J2EE Development: An Adaptive Foundation for Enterprise

Applications”, Prentice Hall, Marzo 2005 Nota: La información aquí referida también puede encontrarse en el artículo “Aplying Code

Generation Techniques to the J2EE Development” del sitio Informit.Com http://www.informit.com/articles/article.asp?p=389718&seqNum=2&rl=1, Junio 2005.

[MSQ06] Resource Standard Metrics, M Squared Technologies http://msquaredtechnologies.com/ 2006 [ODO05] O’Docherty, Mike; “Object Oriented Analysis and Design. Understanding System Development with UML 2.0”; John Wiley & Sons, Ltd.; 2005 [ORA07] JDeveloper 10.1.3.2 por Oracle Technology Network, http://www.oracle.com/technology/software/products/jdev/index.html [PAR92] Robert E. Park, “Software Size Measurement: A Framework for Counting Source Statements”, Technical Report, SEI, 1992. [PMD06] CPD, Copy/Paste Detector; PMD; http://pmd.sourceforge.net ; 2006 [POW05] Krakatau Professional, PowerSoftware.Com. http://www.powersoftware.com/kepm/ 2005 [PRE02] Roger S. Pressman; “Ingeniería de Software, un enfoque práctico”; Quinta Edición; Ed. McGraw Hill, 2002. [RAE07] Diccionario de la Real Academia Española de la Lengua, http://www.rae.es, 2007 [RAI05] Ken Raisor, Rick Reynolds, David Tuma “Personal Process Dashboard v1.6.6” http://processdash.sourceforge.net/ copyright 1998-2005

Referencias

175

[RET01] Michael Retting, Martin Fowler, “Reflection vs. Code Generation”, JavaWorld.com, http://www.javaworld.com/javaworld/jw-11-2001/jw-1102-codegen.html?page=3#resources, Febrero 2001, última consulta: Noviembre 2006. [SEI06] “The Team Software Process (TSP) and the Personal Software Process (PSP)”, Carnegie Mellon Software Engineering Institute, http://www.sei.cmu.edu/tsp/main.html, 2006 [SEI07] “Cyclomatic Complexity. Software Technology Roadmap”, Carnegie Mellon Software Engineering Institute, http://www.sei.cmu.edu/str/descriptions/cyclomatic_body.html, 2007 [SEI88] Everald E. Mills, “Software Metrics – SEI Curriculum Module SEI-CM-12-11”, Carnegie Mellon Software Engineering Institute, 1988 [SIT05] David Sitski, CodeStriker , http://codestriker.sourceforge.net, 2005. [SCT05] Understand for [c++|java|jovial|ada|fortran], Scientific Toolworks Inc. www.scitools.com , 2005 [SFG06] SourceForge.Net, página de recursos libres. http://sourceforge.net 2006 [TPA04] Terrence Parr, “Generating Java and XML Using String Template”, University of San Francisco, disponible en Code Generation Network: http://www.codegeneration.net/tiki-read_article.php?articleId=65 , mayo 2004 (revisado en abril 2007). [WEB07] Webopedia.Com: Online Computer Dictionary for Computer and Internet Terms and Definitions, hosted in the Small Business Computing Channel by Internet.Com, member of the JupiterWeb Networks, 2006. [WES02] Westermann, Erik. “Learn XML In a Weekend.” Boston, MA, USA: Course PTR, 2002. p 2. http://site.ebrary.com/lib/bivitec/Doc?id=10054336&ppg=26 [WHE02] David Wheeler, “SLOCCount User’s Guide”, http://www.dwheeler.com/sloccount/sloccount.html, 2002 [WHE04] Wheeler, David, SLOCCount. http://www.dwheeler.com/sloccount/ 2004 [WIS93] Michael J. Wise, “String Similarity via Greedy String Tiling and Running Karp-Rabin Matching”; Department of Computer Science, University of Sydney, Australia; 1993

tesis de maestrÍa en ciencias...que además de ser mi hermano, siempre has sido mi mejor amigo, mi...

Documents