UT01. Desarrollo de software.

El software es el conjunto de programas informáticos que actúan sobre el hardware para realizar una tarea
específica.

• El software de sistema es el software base que ha de estar instalado y configurado en nuestro ordenador para que las
aplicaciones puedan ejecutarse y funcionar.
• El software de programación es el conjunto de herramientas que nos permiten desarrollar programas informáticos.
• Las aplicaciones informáticas son un conjunto de programas que tienen una finalidad más o menos concreta.

Un programa: es un conjunto de instrucciones escritas en un lenguaje de programación, que indican a la máquina que
operaciones realizar sobre unos determinados datos.

Un lenguaje de programación: es un conjunto predefinido de palabras y símbolos que se utilizan siguiendo unas reglas
prefijadas (sintaxis).

FASES DESARROLLO DEL PROYECTO

 Análisis: Es la primera etapa del proyecto, la más complicada y la que más depende de la capacidad del analista. Está
comprobado que los errores en esta fase son los que mayor impacto tienen en el proyecto en su conjunto. De esta fase
obtendremos dos salidas:

• Funcionales: qué funciones tendrá que realizar la aplicación. Qué respuesta dará la aplicación ante todas las entradas.
Cómo se comportará la aplicación en situaciones inesperadas.

• No funcionales: los requisitos no funcionales explican las limitaciones y restricciones del sistema a diseñar. Ejemplos
serían: tiempos de respuesta del programa, legislación aplicable, tratamiento ante la simultaneidad de peticiones, etc.

Es imprescindible una buena comunicación entre el analista y el cliente para que la aplicación que se va a desarrollar cumpla
con sus expectativas.

 Diseño: De esta fase obtendremos dos salidas:

• Documento de Diseño del Software, que recoge información de los aspectos anteriormente mencionados.
• Plan de pruebas a utilizar en la fase de pruebas, sin entrar en detalles de las mismas.

 Codificación: Es la fase en donde se implementa el código fuente y se obtienen los ficheros en código máquina que es
capaz de entender el ordenador. Durante la fase de programación, el código puede adoptar varios estados, dependiendo
de la forma de trabajo y del lenguaje elegido, a saber:

• Código fuente
• Código objeto
• Código ejecutable
Se han propuesto diversas técnicas de programación cuyo objetivo es mejorar tanto el proceso de creación de software como
su mantenimiento. Entre ellas, se pueden mencionar las siguientes:

 programación estructurada
 programación modular
 programación orientada a objetos (POO)
 programación declarativa

PRUEBAS:
Se llevan a cabo sobre un conjunto de datos de prueba, que consisten en una colección predefinida de datos límite a los que la
aplicación es sometida.
La realización de pruebas es imprescindible para asegurar la validación y verificación del software construido. Entre todas las
pruebas que se efectúan sobre el software podemos distinguir básicamente:

• Pruebas unitarias:
Consisten en probar, una a una, las diferentes partes de software y comprobar su funcionamiento (por separado, de manera
independiente). Como resultado de las pruebas unitarias se genera un documento de procedimiento de pruebas, que tendrá
como partida el plan de pruebas de la fase de diseño. Éste incluye los resultados obtenidos y deben ser comparados con los
resultados esperados que se habrán determinado de antemano.
Ejemplo: JUnit es el entorno de pruebas unitarias para Java.

• Pruebas de integración:
Consiste en poner en común todos los programas desarrollados pasadas las pruebas unitarias de cada uno. Para las pruebas
de integración se genera un documento de procedimiento de pruebas de integración, que podrá partir de un plan de pruebas de
integración si durante la fase de análisis fue generado. Al igual que en las pruebas unitarias los resultados esperados se
compararán con los obtenidos.

 Verificación en cliente / Explotación:

Es la fase en donde el usuario final utiliza el sistema en un entorno de preproducción o pruebas, ya en sus propias
instalaciones. Si todo va correctamente, el producto estará listo para ser pasado a producción (entorno de
explotación).

 Mantenimiento:
Se define como el proceso de control, mejora y optimización del software tras la implantación. Por su naturaleza, el
software es cambiante y deberá actualizarse y evolucionar con el tiempo. Deberá ir adaptándose de forma paralela a
las mejoras del hardware en el mercado y afrontar situaciones nuevas que no existían cuando el software se
construyó. Los tipos de cambios que hacen necesario el mantenimiento del software son los siguientes:

• Correctivo: Resuelve un error detectado.

• Evolutivo: El cliente propone mejoras para el producto. Implica nuevos requisitos.
• Adaptativo: El programa precisa adaptarse a las nuevas tendencias del mercado, a nuevos componentes hardware,
nuevas condiciones especificadas por organismos reguladores, etc.

 Documentación:
La documentación no debe ser considerada como una etapa más en el desarrollo del proyecto, la elaboración de documentos
es constante durante todo su ciclo de vida. Documentar un proyecto se hace necesario para dar toda la información a los
usuarios de nuestro software y para poder acometer futuras revisiones.

CICLO DE VIDA DEL SOFWARE

Conjunto de fases o etapas, procesos y actividades requeridas para ofertar, desarrollar, probar, integrar, explotar y mantener un
producto software. Los más conocidos y utilizados son los citados a continuación:

• Modelo en cascada:
El modelo en cascada es un enfoque rígido donde las etapas se siguen secuencialmente sin posibilidad de retorno. Cualquier
error al principio es difícil de corregir más tarde. Funciona mejor para proyectos pequeños con requisitos claros desde el inicio,
como desarrollar una calculadora básica para un dispositivo móvil.

• Modelo en cascada con realimentación:

Permite retroceder en cualquier etapa para ajustes. Es ideal para proyectos con requisitos claros y pocos cambios, como un
bloc de notas en línea donde se pueden hacer ajustes basados en la retroalimentación de los usuarios.

• Modelos evolutivos:
Son más modernos que los anteriores. Tienen en cuenta la naturaleza cambiante y evolutiva del software. Distinguimos las
siguientes variantes: Ejemplo de Aplicación: Desarrollo de un reproductor de música simple que comienza reproduciendo
archivos de música locales y se expande gradualmente para admitir la reproducción de listas de reproducción y la integración
con servicios de transmisión de música en línea.

 Modelo iterativo incremental:

Es una mejora del modelo en cascada con retroalimentación. Se repiten y refinan fases, generando versiones
parciales del producto. Cada iteración añade funcionalidades, partiendo de versiones previas. Por ejemplo, en la
creación de un sistema de gestión de contactos, se comienza con funciones básicas como agregar nombres y
números, y se añaden iterativamente más características como correos electrónicos y direcciones.

• Modelo en espiral:
Se trata de un modelo iterativo como el anterior, pero en este caso, tras cada vuelta se lleva a cabo un análisis de riesgos y se
determinan los objetivos a conseguir en las siguientes iteraciones. Es un modelo muy abierto a cambios de requisitos, incluso
una vez puesto en marcha el proyecto. El modelo en espiral corre el riesgo de alargarse excesivamente en el tiempo y
aumentar el coste de su desarrollo. Ejemplo de Aplicación: Desarrollo de un reloj despertador o un juego de laberinto en el
cual se realizan multiples iteraciones para mejorar

• Modelos ágiles:
Muy centrados en la satisfacción del cliente, muestran gran flexibilidad a la aparición de nuevos requistitos, incluso durante el
desarrollo de la aplicación. Al tratarse de metodologías evolutivas, el desarrollo es incremental, pero estos incrementos son
cortos y están abiertos al solapado de unas fases con otras. La comunicación entre los integrantes del equipo de trabajo y de
éstos con el cliente son constantes. Un ejemplo de metodología ágil es Scrum y KANBAN.

Las herramientas CASE (Computer Aided Software Engineering):

son un conjunto de aplicaciones que se utilizan en el desarrollo de software con el objetivo de automatizar las fases del
desarrollo y reducir tanto costes como tiempo del proceso. Como consecuencia, se consigue mejorar la productividad, la
calidad del proceso y el resultado final.
• U-CASE (Upper-Case): ofrece ayuda en las fases de planificación y análisis de requisitos.
 • M-CASE (Medium-Case): útil en análisis y diseño.
• L-CASE (Lower-Case): ayuda en la programación del software, detección de errores del código, depuración de
programas y pruebas y en la generación de la documentación del proyecto.

PREGUNTAS Y RESPUESTAS:

1. La obtención de código máquina puede realizarse mediante: Compilación, interpretación.

2. En el análisis semántico: La tabla de símbolos es una herramienta utilizada. Utiliza como entrada el árbol generado por
el analizador sintáctico. No es posible generar el código máquina, cuando el código fuente. presenta errores.

3. En los compiladores: El analizador sintáctico genera un árbol que garantiza la estructura del programa.

4. En el lenguaje Castellano, la frase: “el aplaudió. niño, a ayer comer una chuche”:Devuelve errores durante el análisis
sintáctico.

5. ¿Cuál de los siguientes modelos del software, pasa de una etapa a otra, sin retorno posible?Modelo en Cascada.

6. ¿Qué lenguaje es directamente ejecutable por la computadora? Máquina.

7. En el lenguaje Castellano, la frase: “la discoteca sonriente bebió alfileres cansados”:Devuelve errores durante el análisis
semántico.

8. ¿Cómo se llama el proceso de traducción del código fuente a código objeto?Compilación.

9. ¿En qué etapas ofrecen ayuda las L-CASE?: Codificación, Pruebas

UT02. Instalación y uso de entornos de desarrollo.

Un entorno integrado de desarrollo (IDE), es un tipo de software compuesto por un conjunto de herramientas de programación.
Esta integrado por Editor de codigo, compilador, interprete, depurador e interfaz grafica. El programa BASIC se considera que
fue el primero en usar un IDE.

JRE: es un conjunto de utilidades que permite la ejecución de programas Java.

La JVM: es el programa que ejecuta el código Java previamente compilado (bytecode) mientras que las librerías de clases
estándar son las que implementan el API de Java. Ambas JVM y API deben ser consistentes entre sí, de ahí que sean
distribuidas de modo conjunto.

Java Development Kit (JDK): es un software que provee herramientas de desarrollo para la creación de programas en Java.
Puede instalarse en una computadora local o en una unidad de red. Este sofware es impresindible para poder instalar y
ejecutar Netbeans.

Los programas más importantes que se incluyen:

• appletviewer.exe: es un visor de applets para generar sus vistas previas, ya que un applet carece de método main y no
se puede ejecutar con el programa java.
 • javac.exe: es el compilador de Java.
• java.exe: es el masterescuela (intérprete) de Java.
• javadoc.exe: genera la documentación de las clases Java de un programa.

Entornos de desarrollo libres más relevantes: Eclipse,NetBeans,CodeLite,JDeveloper,IntelliJ

Entornos de desarrollo propietarios más relevantes: Microsoft Visual Studio,C++ Builder,QtCreator

JBC (Java ByteCode) permite ver la información compilada de un fichero .class desde el IDE.

Bytecode outline: Al igual que JBC, el propósito de este plugin vuelve a ser mostrar el formato bytecode de los ficheros Java
compilados.

UMLet: Diagrama de modelado útil en la fase de análisis y diseño

.jar: Es caracteristica de proyectos empaquetados en Java.

PREGUNTAS Y RESPUESTAS:

1. Como se llama el proceso de alteracion de codigo para mejorar su legibilidad, sin cambiar su funcionalidad:
Refactorizacion
2. El plugin necesario para actualizar on-line complementos en NetBeans se llama Portal Update Center. Verdadero
3. ¿Qué es el llamado manifest file? Archivo especial que identifica a un módulo.
4. ¿Cómo se llama el primer software que se consideró el precursor de los actuales IDE, en la década de los 70?
Maestro.
5. Son entornos de desarrollo propietarios: Visual Studio., Xcode.
6. Una de las opciones de personalizacion de la configuracion del entorno para un proyecto java es cambiar el color de las
clases de codigo. FALSO, no se puede elegir colores por proyecto.
7. La extension propia de los modulos plugins en Netbeans es: .nbm.
8. Como se llama la adicion de plugins sin salir del IDE: On-line
9. Como se llama el cambio consistente en mejorar la legibilidad de programas sin alterar la funcionalidad: Refactorizacion
10. Que componente es responsable del seguimiento de las variables en tiempo de ejecucion?: Depurador (lo que resulta
fundamental para identificar errores, corregir problemas y comprender el comportamiento del programa.)
___________________________________________________________________
sudo chmod 755 jdk: Dar permiso ejecucion al archivo
sudo mv jdk /usr/local: Mover el archivo de instalacion a la ubicacion correcta
sudo./jdk: Ejecutar archivo
ls/usr/local: Listar el conenido de ese directorio para comprobar que el archivo ha sido movido correctamente.
__________________________________________________________________
sudo chmod 755 netbeans: Le damos permiso de ejecucion al archivo
sudo: A partir de esta orden se considera que somos root
../sudo mv: Order no valida en Linux
sudo./netbeans: Ejecuramos el archivo
________________________________________________________

UT03. Diseño y realización de pruebas.

Pruebas de la caja negra o (FUNCIONALES): La aplicación es probada de acuerdo a su interfaz externa, sin preocuparnos de
la implementación de esta. Una prueba de tipo caja negra se lleva a cabo sin tener necesidad de conocer la estructura interna
del sistema. El propósito es comprobar si las salidas que devuelve la aplicación son las esperadas en función de los parámetros
de entrada. Se realiza completando los siguientes pasos:
Dentro de las pruebas funcionales, podemos indicar los siguientes tipos:
• Particiones equivalentes: la idea de este tipo de pruebas funcionales, es considerar el menor
número posible de casos de pruebas, para ello, cada caso de prueba tiene que abarcar el mayor
número posible de entradas diferentes. Lo que se pretende, es crear un conjunto de clases de
equivalencia, donde la prueba de un valor representativo de la misma, en cuanto a la verificación de
errores, sería extrapolable al que se conseguiría probando cualquier valor de la clase.

• Análisis de valores límite: al implementar un caso de prueba, se elegirán como valores de

entrada aquellos que están en el límite de las clases de equivalencia.

• Pruebas aleatorias: consiste en generar entradas aleatorias para la aplicación que hay que
probar. Se suelen utilizar generadores de prueba, que son capaces de crear un volumen de casos
de prueba al azar, con los que será alimentada la aplicación.

• Conjetura de errores: trata de generar casos de prueba que la experiencia ha demostrado

generan típicamente errores. En valores numéricos, un buen ejemplo es comprobar si funciona
correctamente con el valor 0, ya que si es utilizado como denominador en alguna división podría
generar un error en nuestro programa.

Determinar las clases de equivalencia: es un tipo de prueba funcional, donde en cada caso de prueba se agrupa
el mayor número de entradas posibles. A partir de aquí, se asume que la prueba de un valor representativo de cada
clase, permite suponer que el resultado que se obtiene con él, será el mismo que con cualquier otro valor de la
clase.

Los pasos a seguir para identificar las clases de equivalencia son:

 Identificar las condiciones de las entradas del programa, es decir, restricciones de formato o contenido de los datos de
entrada. identificar clases de equivalencia que pueden ser: De datos válidos o no válidos o erróneos.
 Determinar un análisis de valores límite.
 Conjetura de errores.
 Generar los caso de uso necesarios para probar las clases válidas y no válidas.
 Lanzar una ejecución del programa por cada caso de uso y comparar los resultados obtenidos con los esperados para
determinar la corrección del código.

Pruebas de la caja blanca o (ESTRUCTURALES): se prueba la aplicación desde dentro, usando su lógica de aplicación. Una
prueba de caja blanca va a analizar y probar directamente el código de la aplicación, intentando localizar estructuras incorrectas
o ineficientes en el código. Se realiza completando los siguientes pasos:

• Crear un grafo que represente el código a probar.

• Calcular la complejidad ciclomática o de McCABE del grafo obtenido.
• Determinar tantos caminos como la complejidad ciclomática calculada.
• Generar un caso de uso por cada camino, determinando sus datos de entrada y resultados
• Lanzar una ejecución del programa por cada caso de uso y comparar los resultados obtenidos con los esperados para
comprobar la corrección del código.

Obtención del grafo: Los grafos se construyen a partir de nodos y aristas. Los nodos representan secuencias de instrucciones
consecutivas donde no hay alternativas en la ejecución o condiciones a evaluar, que en función del resultado hará que la
ejecución siga una dirección u otra.
Complejidad de McCabe o ciclomática: A partir del grafo se determina su complejidad ciclomática. Es posible
hacerlo por tres métodos diferentes, pero todos deben dar el mismo resultado:

• V (G) = a - n + 2, siendo a el número de arcos o aristas del grafo y n el número de nodos.

• V (G) = r, siendo r el número de regiones cerradas del grafo (incluida la externa).
• V(G) = c + 1, siendo c el número de nodos de condición.

Enfoque aleatorio: consiste en utilizar modelos que representen las posibles entradas al programa, para crear a
partir de ellos los casos de prueba. Se trata de una técnica menos sistemática, que será utilizada por
programadores más experimentados.
Pruebas de regresión: se deben llevar a cabo cada vez que se hace un cambio en el sistema, tanto para corregir un error,
como para realizar una mejora. No basta probar solo los componentes modificados o añadidos, o las funciones que en ellos se
realizan, sino que también hay que controlar que las modificaciones no produzcan efectos negativos sobre él u otros
componentes. El diseño de las pruebas de regresión podrá ser una combinación de casos de uso obtenidos desde los enfoques
de caja blanca, caja negra y aleatoria. Contiene tres clases diferentes de pruebas:

1. Una muestra representativa de pruebas que ejercite diversas funciones del software.
2. Pruebas adicionales que se centran en las funciones del software que se van a ver probablemente afectadas por el
cambio.
3. Pruebas que se centran en los componentes del software que han cambiado.

Documentación de la prueba:
Las metodologías actuales, como Métrica v.3, proponen que la documentación de la fase de pruebas se basen en los
estándares ANSI / IEEE sobre verificación y validación de software. IEEE estándar 829

MÉTRICA v3:
Se concibe como una Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de Información

ISO/IEC 29119:
Se compone de las siguientes partes: pretende unificar todos los estándares, de forma que proporcione vocabulario, procesos,
documentación y técnicas para cubrir todo el ciclo de vida del software.

Validación:
La validación del software se consigue mediante una serie de pruebas de caja negra que demuestran la conformidad con lo
acordado (requisitos).Se genera un plan de prueba que traza la clase de pruebas que se han de llevar a cabo, y un
procedimiento de prueba que define los casos de prueba específicos a realizar. Tanto el plan como el procedimiento estarán
diseñados para asegurar que se satisfacen todos los requisitos: funcionales, de rendimiento, de portabilidad, de compatibilidad,
de recuperación de errores, de facilidad de mantenimiento etc.

JUnit:
es una herramienta que ayuda a pasar de forma automática estas pruebas a los métodos y clases de los programas Java.

Depuración:
Nos ayuda a analizar todo el programa mientras éste se ejecuta. Proporciona funciones como la de suspender la ejecución de
un programa, examinar y establecer los valores de las variables, comprobar los valores devueltos por un determinado método,
el resultado de una comparación lógica o relacional, etc.

Nos encontramos con los siguientes tipo de ejecución:

• Paso a paso. Algunas veces es necesario ejecutar un programa línea por línea, para buscar y corregir
errores lógicos.
• Paso a paso por procedimientos. Nos permite introducir los parámetro que queremos a un método o
función de nuestro programa, pero en vez de ejecutar instrucción por instrucción ese método, nos devuelve su
resultado.
• Ejecución hasta una instrucción. El depurador ejecuta el programa, y se detiene en la instrucción donde
se encuentra establecido un punto de parada, a partir de ese punto, podemos hacer una depuración paso a
paso o por procedimiento.
• Ejecución de un programa hasta el final. Ejecutamos las instrucciones de un programa hasta el final, sin
detenernos en las instrucciones intermedias.

Diferencia entre caja blanca, negra y pruebas unitarias:

las pruebas de caja blanca se centran en la estructura interna del software, las pruebas de caja negra en la funcionalidad
externa y las pruebas unitarias en fragmentos específicos de código. Las pruebas unitarias pueden usar tanto el enfoque de
caja blanca como el de caja negra para evaluar unidades individuales de software.

Los criterios de cobertura de caja blanca son:

• Cobertura de sentencias: se han de generar casos de pruebas suficientes para que cada instrucción del
programa sea ejecutada al menos una vez.

• Cobertura de decisiones: se trata de crear los suficientes casos de prueba para que cada opción resultado de
una comprobación lógica del programa, se evalúe al menos una vez a cierto y otra a falso. En la decisión
MIENTRAS (A and B), habrá casos de prueba donde (A and B) sea verdadero y donde (A and B) sea falso.

• Cobertura de condiciones: se trata de crear los suficientes casos de prueba para que cada elemento de una
condición, se evalúe al menos una vez a falso y otra a verdadero. En la decisión MIENTRAS (A and B), habrá
casos de prueba donde A sea falso, A sea verdadero, B sea falso y B sea verdadero.
• Cobertura de condiciones y decisiones: consiste en cumplir simultáneamente las dos anteriores.

• Cobertura del camino de prueba: se pueden realizar dos variantes, una indica que cada bucle se debe ejecutar
sólo una vez, ya que hacerlo más veces no aumenta la efectividad de la prueba y otra que recomienda que se
pruebe cada bucle tres veces: la primera sin entrar en su interior, otra ejecutándolo una vez y otra más
ejecutándolo al menos dos veces.

b) Representa mediante un Diagrama de Clases la siguiente especificación: -Una aplicación necesita almacenar información
sobre empresas, sus empleados y sus clientes. Ambos se caracterizan por su nombre y edad. -Los empleados tienen un sueldo
bruto, los empleados que son directivos tienen una categoría, así como un conjunto de empleados subordinados. -De los
clientes además se necesita conocer su teléfono de contacto. -La aplicación necesita mostrar los datos de empleados y
clientes.

PREGUNTAS Y RESPUESTAS:

1. Las clases de equivalencia: Nos permite crear casos de prueba representativos de un conjunto de valores posibles.

2. Con las clases de equivalencia diseñamos casos de pruebas: Con valores representativos del rango admitido.

3. La herramienta de prueba unitaria más extendida en Java es: JUnit

4. La prueba de software: Sirve para verificar y validar el sistema.

5. Son ventajas de la prueba de la unidad: Simplifican la integración., Documentan el código., Separación de la interfaz y
la implementación.

6. Son ejemplos de herramientas para cubrimiento: JJPath., Clover.

7. En la planificación de pruebas: Se diseñan los tipos de prueba y los casos de prueba.

8. El Objetivo del cubrimiento: Comprobar que todos los caminos se pueden ejecutar.
 9. La caja negra: Es la principal herramienta de validacion

10. Que componente del IDE es basico en la realizacion de pruebas: Depurador

11. En que momento se suelen realizar las pruebas de la unidad? Antes de las pruebas de integracion.

12. Los estandares de normalizacion de prueba BSI cubren todas las fases de la prueba? FALSO

13. Un caso de prueba: Se diseña intentando deteccion de errores maxima.

14. El depurador: Localiza errores de implementacion, verifica el flujo de ejecucion, controla los valores que toman los
datos.

15. La realizacion de pruebas ___ nos permite detectar errores de cada parte por separado: UNITARIAS

16. Con las clases de equivalencia diseñamos casos de pruebas: Con valores representativos del rango admitido

17. Como se llama la prueba que comprueba el cumplimiento de los requisitos funcionales: VALIDACION

18. En la planificacion de pruebas: Se diseñan los tipos de prueba y los casos de prueba

19. Si en un bucle while la condicion es while (x>5 && x <10) siendo x un valor single, seria valores limites: 4,99 y 9,99.
20. Si tenemos el bucle while ((x>5)&&(x<10)) prodrian ser valores limite _____ para pobrar los valores limites: x igual a
seis

21. En las pruebas de caja negra: Se comprueba que los resultados son los esperados para las entradas que se le han
proporcionado.

22. Relaciona las herramientas de automatizacion con su lenguage:

JUnit: Java
FoxUnit: Microsoft Visual FoxPro
CppUnit: C++
SimpleTest: PHP

UT04. Optimización y documentación.

Refactorización: es una técnica, que consiste en realizar pequeñas transformaciones en el código de un programa, para
mejorar la estructura sin que cambie el comportamiento ni funcionalidad del mismo. Su objetivo es mejorar la estructura, la
legibilidad o la eficiencia del código. Algunos de los patrones más habituales de refactorización, que vienen ya integrados en
la mayoría de los entornos de desarrollos, son los siguientes:

 Renombrar: Cambiar el nombre de un paquete, clase, método o campo, por un nombre más significativo.
 Encapsular campos: Crear métodos de asignación y de consulta (getters y setters)
 Sustituir bloques de código por un método.
 Modificar la extensión del código: Hacer un código más extenso si se gana en claridad
 Reorganizar código condicional complejo: Aplicable cuando existen varios if o condiciones complejas.
 Crear código común (en una clase o método): para evitar el código repetido.
 Mover la clase: Mover una clase de un paquete a otro
 Borrado seguro: Garantizar que cuando un elemento del código ya no es necesario, se borra
  Cambiar los parámetros del método: Permite añadir/modificar/eliminar los parámetros en un método
 Extraer la interfaz: Crea una nueva interfaz de los métodos public non-static

Analisadores de codigo: Las principales funciones de los analizadores es encontrar partes del código que puedan
reducir el rendimiento, provocar errores en el software, tener una excesiva complejidad, complicar el flujo de datos,
crear problemas de seguridad. Ejemplo: PMD o Sonarcube.

Control de versiones: Las herramientas de control de versiones proveen de un sitio central donde almacenar el
código fuente de la aplicación, así como el historial de cambios realizados a lo largo de la vida del proyecto. Existen
distintas alternativas de código abierto, GIT, CVS, Subversion, Mercurial. Un repositorio interesante para la gestión
de proyectos es Bitbucket.

Herramienta de control de versiones: es un sistema de mantenimiento de código fuente (o de grupos de archivos

en general) de gran utilidad para grupos de desarrolladores que trabajan cooperativamente.

Tipos de herramientas de control de versiones:

 Sistemas locales: se trata del control de versiones donde la información se guardan en diferentes
directorios en función de sus versiones.
 Sistemas centralizados: responden a una arquitectura cliente-servidor.
 Sistemas distribuidos: en este modelo cada sistema hace con una copia completa de los ficheros de
trabajo y de todas sus versiones.

GIT: es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia, la confiabilidad y
compatibilidad del mantenimiento de versiones de aplicaciones cuando estas tienen un gran número de archivos de
código fuente. Gratis, de código abierto. Algunos de los términos de uso habitual en GIT son:
Repositorio, Rama (Branch), Comentario, Push:, Fetch, pull

En un proyecto colaborativo coordinado con GIT, un escenario típico de trabajo sería el siguiente.

Resumen de comandos GIT:

 Init Crea un nuevo repositorio en el directorio inicialmente vacío.
 clone Crea un nuevo repositorio, copia de uno ya existente.
 add, rm, mv Permite identificar los ficheros del área de trabajo que van a ser incluidos en el repositorio.
 status Imprime un resumen del estado de los ficheros de la copia de trabajo. Los ficheros se pueden
encontrar en los siguientes estados:

o Unmodified: igual que en la rama activa del repositorio.

o Modified: con cambios respecto al repositorio, pero que no está previsto que sean guardados al
 hacer commit.
o Untracked: no guardados en el repositorio. GIT ignora el fichero.
o Staged: el fichero está en el index. Será parte del próximo changeset que se añadirá al repositorio.
 commit Crea una nueva versión en el repositorio local, incluyendo los cambios en estado Staged
procedentes del área de trabajo.
push Sube las versiones del repositorio local a un repositorio remoto.
 checkout Extrae versiones del repositorio local a la copia de trabajo,
 branch Lista, crea o elimina ramas en un repositorio.

Gitk: es un visor del repositorio local. Permite revisar ramas, commits y merges entre otros. Es una aplicación útil
para:
• Recuperar versiones antiguas de un fichero.
• Visualizar las ramas de un repositorio.
• Hacer un seguimiento de la actividad en el repositorio.

Documentacion: es uno de los aspectos más importantes de la labor de un programador. Documentar el código
sirve para explicar su funcionamiento, punto por punto, de forma que cualquier persona que lea el comentario, pueda
entender la finalidad del código. Existen diferentes herramientas que permiten automatizar, completar y enriquecer
nuestra documentación, entre otras están JavaDoc, SchemeSpy o Doxygen.

PREGUNTAS Y RESPUESTAS:

1. Señala los analizadores de código: PMD., FindBugs.

2. características de una analizador de código: evalúa el software., nos informa sobre modificaciones a
realizar para mejorar el código., encuentran partes del código que puede ralentizar su funcionamiento.

3. ¿Qué herramienta de automatización de documentación usa Java? Javadoc.

4. La refactorización: modifica el diseño del código pero no su comportamiento.

5. Los tipos de comentarios admitidos en Java son: comentarios de una línea., comentarios multilínea.,
comentarios estilo Javadoc.

6. El concepto de entrega hace referencia a: una instancia de un sistema que se distribuye a usuarios
externos al equipo de desarrollo.

7. La refactorización no es necesario documentarla. FALSO

8. La refactorización: utiliza una serie de patrones de aplicación sobre el código fuente.

9. Una versión: es la evolución de un único elemento, dentro de un sistema en desarrollo.

 UT05. Diseño orientado a objetos. Elaboración de diagramas estructurales.
Lla orientación a objetos trata de resolver un problema simulando los elementos que participan en su resolución y
basa su desarrollo en los siguientes conceptos:

 Abstracción. Permite capturar las características y comportamientos similares de un conjunto de objetos

con el objetivo de darles una descripción formal.
 Encapsulación. Organiza los datos y métodos de una clase, evitando el acceso a datos por cualquier otro
medio distinto a los definidos.
 Modularidad. Propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas
módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de
las restantes partes.
 Principio de ocultación. La implementación de una clase sólo es conocida por los responsables de su
desarrollo. Gracias a la ocultación, ésta podrá ser modificada para mejorar su algoritmo de implementación
sin tener repercusión en el resto del programa.
 Polimorfismo. Consiste en reunir bajo el mismo nombre comportamientos diferentes. El modo en el que
actuará un objeto en cada momento depende del mensaje que se le envíe al solicitar la ejecución de sus
métodos.
 Herencia. Relación que se establece entre objetos en los que unos utilizan las propiedades y
comportamientos de otros formando una jerarquía. Los objetos heredan las propiedades y el
comportamiento de todas las clases a las que pertenecen.
 Recolección de basura. Técnica por la cual el programa se encarga de destruir automáticamente los
objetos que hayan quedado sin referenciar, y por tanto desvincular su memoria asociada. Característica
disponible en algunos lenguajes orientados a objetos, no en todos.

Ventajas de la orientación a objetos:

El paradigma orientado a objetos tiene las siguientes ventajas con respecto a otros:

 Permite desarrollar software en mucho menos tiempo, con menos coste. Al ser completamente modular
facilita la creación de código reusable.
 Se consigue aumentar la calidad de los sistemas.
 El software orientado a objetos es más fácil de modificar y mantener porque se basa en criterios de
modularidad y encapsulación, en el que el sistema se descompone en objetos con unas responsabilidades
claramente especificadas e independientes del resto.
 La tecnología de objetos facilita la adaptación al entorno y el cambio haciendo aplicaciones escalables.

Visibilidad: Existen distintos niveles de ocultación que se implementan en lo que se denomina visibilidad. Es una
característica que define el tipo de acceso que se permite a atributos y métodos y que podemos establecer
como:

 -Público: se pueden acceder desde cualquier clase y cualquier parte del programa.
 +Privado: sólo se pueden acceder desde operaciones de la clase.
 #Protegido: sólo se pueden acceder desde operaciones de la clase o de clases derivadas en cualquier
nivel.

Un objeto se define por:

 Su estado: definido como el conjunto de valores concretos que tienen sus parámetros.
  Su comportamiento: definido por los métodos públicos de su clase.
 Su tiempo de vida: intervalo de tiempo a lo largo del programa en el que el objeto existe. Comienza con su
creación a través del mecanismo de instanciación y finaliza cuando el objeto se destruye.

La encapsulación y el ocultamiento aseguran que los datos de un objeto están ocultos, con lo que no se pueden
modificar accidentalmente por funciones externas al objeto.

UML (Unified Modeling Language o Lenguaje Unificado de Modelado) : es un conjunto de herramientas que
permiten modelar y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido
en el estándar de facto de la industria, porque lo concibieron los autores de los tres métodos de orientación a objetos
más usados: Grady Booch, Ivar Jacobson y Jim Rumbaugh.

Las raíces técnicas de UML son:

 OMT - Object Modeling Technique (Rumbaugh et al.).

 Método-Booch (G. Booch).
 OOSE - Object-Oriented Software Engineering (I. Jacobson).

Los diagramas UML se clasifican en:

 Diagramas estructurales. Representan la visión estática del sistema. Especifican clases y objetos y como se
distribuyen físicamente en el sistema.
 Diagramas de comportamiento. Muestran la conducta en tiempo de ejecución del sistema, tanto desde el
punto de vista del sistema completo como de las instancias u objetos que lo integran.

Herramientas para la elaboración de diagramas UML:

 Rational Systems Developer de IBM: herramienta propietaria que permite el desarrollo de proyectos
software basados en la metodología UML.
 UMLet: herramienta UML de código abierto y libre distribución. Dispone de un interfaz de usuario sencillo de
utilizar. Es un software gratuito. Es multiplataforma. Incluye un módulo para integrarse con Eclipse.
 Visual Paradigm for UML (VP-UML) : incluye una versión para uso no comercial que se distribuye
libremente sin más que registrarse para obtener un archivo de licencia.
 ArgoUML: se distribuye bajo licencia Eclipse. Soporta los diagramas de UML 1.4, y genera código para java
y C++. Para poder ejecutarlo se necesita la plataforma java. Admite ingeniería directa e inversa.

Ingeniería inversa: se define como el proceso de analizar código, documentación y comportamiento de una
aplicación para extraer información del diseño. Puede ser de varios tipos:

 Ingeniería inversa de datos: se aplica sobre algún código de bases datos (aplicación, código SQL, etc.) para
obtener los modelos relacionales o sobre el modelo relacional para obtener el diagrama entidad-relación.
 Ingeniería inversa de lógica o de proceso: cuando la ingeniería inversa se aplica sobre el código de un
programa para averiguar su lógica (reingeniería), o sobre cualquier documento de diseño para obtener
documentos de análisis o de requisitos.
 Ingeniería inversa de interfaces de usuario: consiste en estudiar la lógica interna de las interfaces para
obtener los modelos y especificaciones que sirvieron para su construcción, con objeto de tomarlas como punto
de partida en procesos de ingeniería directa que permitan su actualización.

Diagramas de clases: representa los elementos estáticos del sistema, sus atributos y comportamientos, y como se
relacionan entre ellos. A partir de éste se obtendrán las clases que formarán después el programa informático. En un
diagrama de clases podemos encontrar los siguientes elementos:
  Clases: agrupan conjuntos de objetos con características comunes, que llamaremos atributos, y su
comportamiento, que serán métodos.
 Relaciones: en el diagrama se representan relaciones reales entre los elementos del sistema a los que
hacen referencia las clases.
 Notas: se representan como un cuadro donde podemos escribir comentarios que ayuden al entendimiento
del diagrama.
 Elementos de agrupación: se utilizan cuando hay que modelar un sistema grande, entonces las clases y
sus relaciones se agrupan en paquetes, que a su vez se relacionan entre sí.

Creación de clases: Una clase se representa en el diagrama como un rectángulo divido en tres filas, arriba aparece
el nombre de la clase, a continuación, los atributos y por último los métodos.

Atributos: Forman la parte estática de la clase. Son un conjunto de variables para las que es preciso definir: Su
nombre. Su tipo. Además, se pueden indicar otros datos como un valor inicial o su visibilidad.

Métodos: Representan la funcionalidad de la clase, es decir, qué puede hacer. Para definir un método hay que
indicar como mínimo su nombre, parámetros, el tipo que devuelve y su visibilidad (similar a la de los atributos).

Relaciones entre clases: Una relación es una conexión entre dos clases que incluimos en el diagrama. Se
representan como una línea continua. Las relaciones se caracterizan por su cardinalidad, que representa cuantos
objetos de una clase se pueden involucrar en la relación.

Generalización (herencia): es la propiedad que permite construir objetos a partir de otros objetos, la capacidad de
un objeto para utilizar estructuras de datos y métodos presentes en sus antepasados. Tipos:
 Herencia simple: una clase puede tener sólo un ascendente inmediato. Es decir, una subclase puede heredar datos
y métodos de una única clase base.
 Herencia múltiple: una clase puede tener más de un ascendente inmediato, adquirir datos y métodos de más de una
clase.

Nota: algunos lenguajes como Java no soportan herencia múltiple.

Agregación y composición:
 La agregación: es una asociación binaria que representa una relación todo-parte (pertenece a, tiene un, es
parte de). (Ejemplo: Chaleco) Rombo transparente.

 La composición: es una agregación fuerte en la que una instancia ‘parte’ está relacionada, como máximo,
con una instancia ‘todo’ en un momento dado, de forma que cuando un objeto ‘todo’ es eliminado, también
son eliminados sus objetos ‘parte’. (Ejemplo: Cerebro) Rombo negro.
PREGUNTAS Y RESPUESTAS:

1. ¿No es una ventaja de las aplicaciones orientadas a objetos? Produce código que es complicado reutilizar.

2. ¿Cuál de los siguientes elementos no forma parte de la descripción de una clase? Abstracción.

3. Son características de la programación estructurada? Tiene como núcleo funciones que actúan sobre
estructuras de datos., Es anterior a la programación orientada a objetos.

4. La instanciación es un proceso de... Concreción.

5. ¿Qué tipo de relación utilizarías para modelar las clases libro y capítulo? Composición.

6. Al proceso de obtener el diagrama entidad-relación a partir de una base de datos existente se le denomina:
Ingeniería inversa de datos.

7. ¿Qué diferencia un objeto de otro? Los valores que toman los atributos.

8. ¿Cuáles de las siguientes son características de UML? Se puede conectar con lenguajes de programación
mediante ingeniería inversa y directa., Utiliza diferentes diagramas para representar distintos puntos de
vista del sistema., Permite representar cosas como la arquitectura del sistema o qué módulos de software
se van a crear.

UT06. Diseño orientado a objetos. Elaboración de diagramas de

comportamiento.
DIAGRAMAS DE CASOS DE USO:
Documentan el comportamiento de un sistema desde el punto de vista del usuario. Por lo tanto, los casos de uso
determinan los requisitos funcionales del sistema. La notación propia de estos diagramas representa casos de uso
(dibujados como elipses) y los actores que interactúan con ellos (como monigotes).

Actores:
Los actores representan los tipos de usuario que interactúan con el sistema (un ser humano, un PC, una
empresa...) Es importante entender la diferencia entre actores y usuarios, por ejemplo, un usuario puede
interpretar diferentes roles según la operación ejecutada, cada uno representará un actor diferente. Por otro
lado, cada actor puede ser interpretado por diferentes usuarios. Existen: Primarios, secundarios e
Iniciadores.

Relaciones:
Los diagramas de casos de uso son grafos no conexos en los que los nodos son actores y casos de uso, y
las aristas son las relaciones que existen entre ellos. Representan qué actores realizan las tareas descritas
en los casos de uso. Pero además existen otros tipos de relaciones que se utilizan para especificar
relaciones más complejas (include/use, extends, o generalización).

Existen diferentes tipos de relaciones entre elementos:

 Asociación: Representa la relación entre el actor y un caso de uso en el que participa.

 Inclusión (include - use): Se trata de una relación entre casos de uso. La ejecución de un caso de uso
implica necesariamente la ejecución del segundo.
 Extensión (extend): Se trata de una relación entre casos de uso. La ejecución de un caso de uso puede
provocar la ejecución del segundo.
 Generalización: Se utiliza para representar relaciones de herencia entre casos de uso o actores. No se
contemplan generalizaciones combinadas entre actores y casos de uso.

DIAGRAMAS DE INTERACCION:

Una vez conocidos los diagramas de casos de uso, se hace necesario buscar la forma de representar como circula
la información, los objetos que participan en los casos de uso, los mensajes que envían, y en el momento en que se
producen. Hay dos tipos de diagramas de interacción:
  diagramas de secuencia: los objetos se dibujan mediante rectángulos y se distribuyen horizontalmente en
la parte superior del diagrama.
o Invocación de métodos.
Los mensajes, que significan la invocación de métodos, se representan como flechas horizontales
que van de una línea de vida a otra, indicando con la flecha la dirección del mensaje.

 diagramas de colaboración: muestran una secuencia de ejecución de uno o varios casos de uso. La
notación utilizada es muy similar la principal diferencia radica en el modo de mostrar el orden de mensajes
intercambiados entre objetos. permiten una mejor organización visual de los objetos, tienen forma de grafo
en el que los nodos son objetos y las aristas son los mensajes que intercambian.
o Paso de mensajes: es necesario que exista una asociación entre los objetos, que se podrá
mostrar mediante una línea que los una y una flecha que indique la dirección.

DIAGRAMAS DE ESTADOS:

Permiten analizar la evolución del estado de un objeto en el tiempo, representa su comportamiento transitando por
varios estados.

En relación con el diagrama de estados se cumple que:

• Un objeto está en un estado concreto en un cierto momento, que principalmente viene determinado, por los
valores de sus atributos.
• La transición de un estado a otro es momentánea y se produce cuando ocurre un determinado evento.

Estados y eventos:
Un estado: es una situación en la vida de un objeto en la que satisface cierta condición, realiza alguna actividad o
espera algún evento.

Existen tres tipos de estado en los que se puede encontrar un objeto:

• Estado inicial. Punto de partida por defecto del diagrama de estados. Corresponde a los valores de una
clase al instanciar un nuevo objeto.
• Estado final. Estado en el que se encuentra el objeto una vez finalizado la secuencia de eventos que
pueden proporcionar transiciones entre estados.
• Estado intermedio. Cualquiera de los estados intermedios entre los dos anteriores.

Un evento: es un acontecimiento que dispara una transición entre dos estados del objeto. Existen eventos externos
y eventos internos según el agente que los produzca.

Tipos de eventos:
 • Señales (excepciones): la recepción de una señal, producida por una situación excepcional en el sistema.
Puede ser origen de una transición entre estados.
• Llamadas: la recepción de una petición para invocar una operación. Normalmente un evento de llamada es
manejado por un método del objeto.
• Paso de tiempo: el evento se genera como consecuencia del cumplimiento de un temporizador.
• Cambio de estado: evento generado por un cambio en el estado o el cumplimiento de una condición.

DIAGRAMAS DE ACTIVIDAD:

Es una especialización del diagrama de estados, organizado en torno a las acciones en lugar de los objetos, que se
compone de una serie de actividades y representa como se pasa de unas a otras.

Elementos del diagrama de actividad:

 Estados de actividad y estados de acción.

 Transiciones: relación entre dos estados que indica que un nodo en el primer estado realizará ciertas
acciones y pasará al segundo estado cuando ocurra un evento específico y satisfaga ciertas condiciones.

o Secuencial o sin disparadores: al completar la acción del estado origen se ejecuta la acción de
salida y, sin ningún retraso, el control sigue por la transición y pasa al siguiente estado.
o Bifurcación (decision node): especifica caminos alternativos, elegidos según el valor de alguna
expresión booleana. Las condiciones de salida no deben solaparse y deben cubrir todas las
posibilidades (puede utilizarse la palabra clave else ).
o Fusión (merge node): redirigen varios flujos de entrada en un único flujo de salida. No tiene
tiempo de espera ni sincronización.

 Objetos: manifestación concreta de una abstracción o instancia de una clase.

PREGUNTAS Y RESPUESTAS:

1. ¿Cuál es el principal objetivo de un diagrama de colaboración?

Describir la interacción entre objetos mediante el paso de mensajes entre ellos empleado conexiones entre
objetos en un grafo.

2. ¿Qué elemento del diagrama de actividad utilizarías para especificar la reunión de varios flujos de entrada
síncronos? Un nodo de unión.

3. El uso de calles en un diagrama de actividad permite: Indicar quien realiza las acciones dentro de su calle.

4. ¿Qué elemento del diagrama de actividad utilizarías para especificar varios caminos de salida en un
diagrama de actividad sin sincronización? Un nodo de bifurcación.

5. ¿Qué representa el estado inicial en el diagrama de estados de nivel más alto? La creación de una
instancia de la clase para la que se define el diagrama de estados.

ANALISIS COMPILACION:

a. Análisis léxico: divide el código en tokens, no define el conjunto de símbolos permitidos.

b. Análisis semántico: verifica el significado y consistencia del código, no las normas de construcción de símbolos.

c. Análisis sintáctico: verifica la estructura gramatical, no el significado de las construcciones.