Libro Entornos de Desarrollo Ed. Paraninfo

DESARROLLO DE APLICACIONES WEB
Entornos
de desarrollo
José Manuel Piñeiro Gómez
Entornos
de desarrollo
Entornos
de desarrollo
José Manuel Piñeiro Gómez
Paraninfo
ciclos formativos
Paraninfo
Entornos de desarrollo
O José Manuel Piñeiro Gómez
Gerente Editorial
Reservados los derechos para to-
María José López Raso dos los países de lengua española.
De conformidad con lo dispuesto
Técnico Editorial en el artículo 270 del Código Pe-
Paola Paz Otero nal vigente, podrán ser castigados
con penas de multa y privación de
Sofía Durán Tamayo
libertad quienes reprodujeren o
plagiaren, en todo o en parte, una
Editora de Adquisiciones obra literaria, artística o científica
Carmen Lara Carmona fijada en cualquier tipo de soporte
sin la preceptiva autorización. Nin-
guna parte de esta publicación,
Producción
incluido el diseño de la cubierta,
Nacho Cabal Ramos puede ser reproducida, almace-
nada o transmitida de ninguna
Diseño de cubierta forma, ni por ningún medio, sea
este electrónico, químico, mecáni-
Ediciones Nobel
co, electroóptico, grabación, foto-
copia o cualquier otro, sin la previa
Preimpresión autorización escrita por parte de la
Ediciones Nobel Editorial.
Todas las marcas comerciales y sus logos mencionados en este texto son propiedad
de sus respectivos dueños.
COPYRIGHT O 2022 Ediciones Paraninfo, SA Impreso en España /Printed in Spain

1.* edición, 2022 Tórculo Comunicación Gráfica
C/ Sierra de Guadarrama 35. Naves 2, 3, 4 y 5 (Santiago de Compostela)
Polígono Industrial San Fernando ll, 28830
San Fernando de Henares. Tel.: 914 463 350
clientesQparaninfo.es / www.paraninfo.es
ISBN: 978-84-1366-524-5
Depósito legal: M-14353-2022
(24.040)
La editorial recomienda que el alumnado realice las actividades sobre el cuaderno y no sobre el libro.
Paraninfo
Este libro desarrolla los contenidos del módulo profesional de Entornos de desarrollo,
de los Ciclos Formativos de grado superior en Desarrollo de Aplicaciones Web
y Desarrollo de Aplicaciones Multiplataforma, pertenecientes a la familia
profesional de Informática y Comunicaciones.
Gran cantidad de actividades propuestas y resueltas.

Recuadros con información complementaria.
Mapas conceptuales al final de cada unidad.
Enlaces web de interés.
Argot técnico.
Actividades de comprobación de tipo test al final
de cada unidad.
Actividades de aplicación y ampliación al final
de cada unidad.
Índice de términos al final del libro.
Programación didáctica.
Solucionario.
Presentación de aula.
Examina.
LDP (Libro Digital Proyectable).
Materiales y documentación extra.
'
$
Proyecto figuras para la aplicación de patrones

O Ediciones Paraninfo
de refactorización.
Proyecto geometría para la aplicación de ingeniería
inversa.
elif _Opel';tí…¡ == "MIRROR 7":
N =
bpy . context.scene.objects.active = modifier_ob

print("Selected” + str(modifier_0b)) % modifier ob is the active ob
- 1 Desarr0||0 de SomNare ..... 1 1.8.1. Modelo en cascada.... 24

1.8.2. Modelos de proceso
1.1. El software y su relación con incremental... . .....——. 26
otras partes del ordenador .... 2 1.8.3. Modelos de proceso
1.2. Lenguajes de programación. EVOLULIVO « .= 2- mena s 27
TIpos. .. ..... ...
... .. ... 5 1.9. Metodologías de desarrollo
1.3. Código fuente, código objeto de SOfWAare : : «==an:::5.a.: 30
y código ejecutable. 1.9.1. El proceso unificado
Herramientas implicadas ..... 10 de Rational (RUP) ..... 32
1.4. Máquinas virtuales. ......... 14 1.9.2. Modelos de desarrollo
1.5. La ingeniería del software..... 13 EBIL - amama e — 35
1.6. Fases del desarrollo de Mapa conceptual. ..........ee_e_. 41
una aplicación informática .... 15 Actividades finales ............. 42
1.60.1. Análisis. . ........... 17
1.6.2. Diseño ............. 19
1.6.3. Programación ........ 19 - 2 |nSta|a0|Ón y USO
1.6.4. Pruebas ............ 20 de entornos de desarrollo. .. 47
1.6.5. Explotación . ......... 21
1.6.6. Mantenimiento ....... 22 2.1. La tilidad de los entornos
1.7. Roles que intervienen de desarrollo integrados...... 48 %
en el proceso de desarrollo 2.2. Componentes de un entorno ¿%
de software ........r...eoco.—. 22 de desarrollo . ............. 52 2
1.8. Modelos de ciclo 2.3. Instalación de un entorno é
de vida del software......... 24 de desarrollo . ...........—.. 53 o
1Y COMUNICACIÓNES
2.3.1. Instalación 3.3.3. Estrategia de aplicación
de Eclipse........... 53 de las técnicas de diseño
2.3.2. Instalación de casos de prueba. .. 99
de NetBeans......... 55 3.4. Documentación
2.4. Edición de programas de las pruebas. ........... 100
y generación de archivos 3.5. Herramientas
ejecutables ... ... w===..... 56 de depuración ............ 102
2.4.1. Edición dg¡programas 3.6. Pruebas automáticas ....... 107
y generación 3.6.1. Tratamiento
de archivos ejecutables de excepciones ...... a Es
eni E£:I|p56 """""" 56 3.6.2. Anotaciones ........ 112
2.4.2. Edición dg programas 3.6.3. Análisis de
y Eeraración la cobertura
de archivos ejecutables
en NetBeans ......... 60 a s D.
2.5. Instalación y desinstalación Mº_º? conceptual """"""" .
de médulos --....ses=:::.5 64 Actividades finales .........r... 119
2.5.1. Instalación
y desinstalación
de módulos
M 4. Optimización .
en Eclipse ........... 64 y documentación ........ 125
2.5.2. Instalación
y desinstalación 4.1. Refactorización ........... 126
de módulos 4.1.1. Los malos olores
en NetBeans......... 71 (bad smells). ......... 127
2.6. Mecanismos de actualización. .. 73 4.1.2. Implantación
Mapa conceptual. ........—....e.. 74 de la refactorización. . 129
Actividades finales ...........é.. 75 4.1.3. Patrones de
refactorización
He - z en Eclipse. ......... 130
- 3 Dlsen0y rea||2a0|0n 4.1.4. Otras operaciones
de pruebas............. 79 deen refactorización

Eclipse.......... 139
3.1. Filosofía de las pruebas 4.2. Analizadores de código...... 140
del software. ........r.—.._..e. 80 4.3. Control de versiones ....... 146
3.2. Estrategia de pruebas 4.3.1. Gestión
del software. .........._._co.. 82 de versiones........ 148
3.2.1. Prueba de unidad...... 82 4.3.2. Herramientas
3.2.2. Prueba de integración. .. 83 de control
3.2.3. Prueba del sistema .... 83 de versiones........ 149
3.2.4. Prueba de validación ... 84 4.4. Documentación ........... 163
3.3. Técnicas de diseño de casos 4.4.1. Estructura
de prueba .........oeeee.. 85 de los documentos ... 163

3.3.1. Pruebas estructurales 4.4.2. Generación
o de caja blanca ...... 86 de documentación.... 168
3.3.2. Pruebas funcionales Mapa conceptual. ..........e... 173
o de caja negra....... 94 Actividades finales ............ 174
INFORMÁTIY COMU
CA
5, Elaboración de diagramas 5.8. Generación de diagramas

de clases a partir de código
de clases.............. (ingeniería inversa)......... 225
Mapa conceptual. ............. 229
5.1. Conceptos básicos Actividades finales 230
de la orientación a objetos ... 180
D:2. El lenguaje UML........... 181
5.2.1. Tipos de elementos EN 6. Elaboración de diagramas
en UML............
5.2.2. Tipos de diagramas
182
de comportamiento ....... 237
en UML:= 2 : = m=enanas 188 6.1. Diagramas de comportamiento 238
D.3. Clases, atributos, métodos 6.2. Diagramas de casos
Y VISIDIlIdad === ::::==2s:aa 190 de uso 239
5.4. Relaciones entre clases ..... 193 6.2.1. Herramientas
5.4.1. Agregación ......... 193 para la elaboración
5.4.2. Composición........ 195 de diagramas
5.4.3. Generalización de casos de uso ..... 247
y especialización ..... 197 6.3. Diagramas de interacción.... 251
5.4.4. Asociación ......... 198 6.3.1. Diagramas
5.4.5. Realización ......... 206 de secuencia........ 252
55. Tipos de clases de análisis. .. 206 6.3.2. Diagramas
5.6. Herramientas para la creación de colaboración...... 259
de diagramas de clases ..... 207 6.3.3. Herramientas
5.6.1. Creación de diagramas para la elaboración
de clases de diagramas
con diagrams.net..... 207 de interacción ....... 261
5.6.2. Creación de diagramas 6.4. Diagramas de estados ...... 271
de clases 6.5. Diagramas de actividades. ... 276
con Papyrus ........ 212 Mapa conceptual. ......e..e..s 278
5.6.3.Creación de diagramas Actividades finales 279
de clases
con Modelio ........
.T. Generación de código
218
M Índice alfabético 205
a partir de diagramas
de clases .........oo.—.e.e._ 224 E Bibliografia
1
UNIDAD
Comprender el concepto de software. “.1 El software y su relación con
otras partes del ordenador
Diferenciar los conceptos de código fuente,
código objeto y código ejecutable. E 12. Lenguajes de programación.
Tipos
Clasificar los lenguajes de programación.
Conocer el proceso de obtención del código 1.3. Código fuente, código objeto y
código ejecutable. Herramientas
ejecutable a partir del código fuente
implicadas
y las herramientas implicadas.
Conocer el concepto de máquina virtual E 1.4. Máqguinas virtuales
y su utilidad. 15. La ingeniería del software
Comprender la razón de ser de la ingeniería E 1.6. Fases del desarrollo de una
del software. aplicación informática
Identificar las fases del desarrollo de una E 17. Roles que intervienen
aplicación informática y el cometido de cada en el proceso de desarrollo
una de ellas. de software
Conocer los diferentes modelos de ciclo de vida E 1.8. Modelos de ciclo de vida
del software. del software
Conocer las metodologías de desarrollo E 1.9. Metodologías de desarrollo
de software actuales. de software
1. DESARROLLO DE SOFTWARE |NFORMATICA / [Cf
Introducción
Sería imposible concebir la sociedad actual sin tener en cuenta la presencia de los orde-
nadores, pues estos desempeñan un papel trascendental en muchos ámbitos de nuestra
actividad cotidiana. En esta unidad, se analiza el software del ordenador y el proceso que
es necesario llevar a cabo para la creación de programas o aplicaciones informáticas.
Este es el objeto de estudio de una disciplina conocida como ingeniería del software.
Una de las etapas fundamentales del desarrollo de software es la de programación, ta-

rea en la que entran en juego los lenguajes de programación. Por ello, aquí se lleva a
cabo una clasificación de estos lenguajes y se analiza el proceso que parte del código
fuente hasta el código ejecutable y las herramientas necesarias para realizar esta tarea.
M 1.1.El software y su relación con otras partes

del ordenador
La definición de software que proporciona la Real Academia Española (RAE) es la siguien-
te: «conjunto de programas, instrucciones y reglas informáticas para ejecutar ciertas ta-
reas en una computadora».
Según la definición de Pressman (2010), más rigurosa y técnica, el software es: «1) ins-
trucciones (programas de cómputo) que cuando se ejecutan proporcionan las caracte-
rísticas, función y desempeño buscados; 2) estructuras de datos que permiten que los
programas manipulen de forma adecuada la información, y 3) información descriptiva tan-
to en papel como en formas virtuales que describen la operación y uso de los programas.»
En cualquier caso, se hace referencia a los programas que se ejecutan en un ordenador

con el fin de realizar determinadas tareas sobre el hardware, y los datos necesarios para
la ejecución de dichos programas.
Para comprender un poco mejor el concepto de software, es necesario hacer referencia

a las diferentes partes que componen el hardware de un ordenador, que son básicamen-
te tres:
1. Unidad central de proceso (CPU): es la parte del ordenador que ejecuta las instruc-
ciones contenidas en los programas. Aunque las instrucciones de un programa
puedan ser muy complejas, estas al final se traducen o materializan en sencillas
operaciones aritméticas (sumas, restas, etc.) y lógicas (OR, AND, etc.) que se rea-
lizan sobre bits. La CPU consta, a su vez, de las siguientes partes:
E Unidad aritmético-lIógica (ALU): ejecuta las operaciones aritméticas y lógicas en-

comendadas por la unidad de control con los datos que recibe, y devuelve el re-
sultado de dichas operaciones, siguiendo las órdenes de la unidad de control.
E Unidad de control (UC): recoge las instrucciones contenidas en la memoria

principal y ordena su ejecución mediante el envío de señales a la ALU y a los
registros.
| 1O/V…NICACIONES 1. DESARROLLO DE SOFTWARE
E Registros: constituyen el almacenamiento interno de la CPU e intervienen en la

ejecución de las instrucciones. Hay varios registros, como el contador de pro-
grama y el registro de instrucción.
2. Memoria principal o memoria RAM: contiene las instrucciones del programa que
hay que ejecutar y los datos sobre los que deben operar estas instrucciones. La
CPU toma estas instrucciones de la memoria RAM y envía las órdenes necesarias
para su ejecución. Se trata de una memoria volátil, lo que quiere decir que su con-
tenido desaparece cuando se apaga el ordenador.
3. Unidad de entrada/salida: permite la comunicación del ordenador con el exterior,

transfiriendo la información a través de periféricos. Los periféricos pueden ser de
varios tipos:
E De entrada: proporcionan al ordenador datos e instrucciones. Ejemplos: tecla-

do, ratón, etcétera.
E De salida: muestran información al exterior, es decir, al usuario del ordenador.

Ejemplos: pantalla, impresora, etcétera.
E De entrada/salida: proporcionan información al ordenador y envían información

del ordenador al exterior. Ejemplos: módem, tarjeta de red, etc. También se pue-
de incluir entre estos periféricos los dispositivos que permiten almacenar infor-
mación de manera permanente (memoria secundaria), como los discos duros,
las memorias flash, DVD, etcétera.
Para la interconexión de todos estos elementos, existe una serie de conexiones que reci-
ben el nombre de buses, que se representan mediante flechas (véase Figura 1.1).
REGISTROS
MEMORIA
PRINCIPAL
| UNIDAD DE <i>
| CONTROL
PERIFÉRICO PERIFÉRICO PERIFÉRICO ;5 E:5'FF?Á%2/

DE ENTRADA DE ENTRADA DE SALIDA SALIDA
Figura 1.1. La estructura de un ordenador consta de una CPU, dividida en: unidad de control, unidad
aritmético-lógica (ALU) y registros; la memoria principal o memoria RAM y la unidad de entrada/salida, que
permite la comunicación del ordenador con el exterior gracias a la conexión de los periféricos con esta unidad.
Los diversos elementos del hardware de un ordenador se conectan por medio de unas líneas llamadas buses
por las que circulan los bits.
1. DESARROLLO DE SOFTWARE |NFORMÁTÍCA y (
El software, por tanto, hace referencia al conjunto de instrucciones que debe ejecutar el
ordenador para resolver un problema a partir una serie de datos de entrada con el fin de
obtener determinados resultados. Tanto estas instrucciones como los datos sobre los
que estas operan deben residir en la memoria principal o memoria RAM. Estas instruc-
ciones son tomadas por la unidad de control, la cual envía las órdenes necesarias con el
fin de que la ALU realice las operaciones para dar respuestas a esas instrucciones. Los
datos de entrada para resolver el problema pueden ser suministrados al ordenador por
medio de una serie de periféricos de entrada, como el teclado y el ratón, y los resultados
se pueden mostrar mediante los periféricos de salida, como la pantalla y la impresora.
La información que se requiere guardar de manera permanente se almacena en periféri-
cos de entrada/salida, como el disco duro o una memoria flash.
Existen distintos tipos de software en función de su uso:
E Software de sistemas: se trata de programas que permiten el uso de un ordenador,

para lo cual se comunican con el hardware y permiten la interacción entre el usua-
rio y el ordenador. Son ejemplos de software de sistemas, los sistemas operativos,
los controladores o drivers de dispositivos y las herramientas de diagnóstico.
E Software de programación o desarrollo: posibilita la creación de programas. Los

editores, compiladores o depuradores, entre otros, son ejemplos de este tipo de
software. En el Apartado 1.3, se tratarán las herramientas para la creación de pro-
gramas. Sin embargo, lo más habitual es usar un tipo de software que integre to-
das estas herramientas, los llamados entornos de desarrollo integrados.
E Software de aplicación: se trata de todo aquel software que no se incluye en los gru-
pos anteriores. Son todos aquellos programas que ayudan a las y los usuarios a
realizar algún tipo de tarea y que permiten que el ordenador sea un objeto útil para
las personas que lo usan. La existencia de este tipo de software es posible gracias
a la existencia del software de sistemas y del software de programación, ya que, al
final, se trata de programas creados con software de programación, y porque, para
poder usar cualquier ordenador, se requiere un software de sistemas. Constituyen
software de aplicación multitud de aplicaciones distintas, como aplicaciones ofimá-
ticas, programas de gestión empresarial, herramientas de diseño y programas para
el desarrollo de sitios web, videojuegos, etcétera.
Actividad propuesta 1.1

El hardware y el software de un ordenador
Relaciona los elementos de hardware o software de un ordenador que aparecen en
la columna de la izquierda con el tipo de hardware o de software correspondiente
de la columna de la derecha:
Procesador de textos Periférico de entrada

Impresora Periférico de salida
Ratón Periférico de entrada/ salida

Compilador Software de sistemas
Sistema operativo Software de programación
Memoria flash Software de aplicación
| J/VXUN'CAGONES 1. DESARROLLO DE SOFTWARE
M 1.2. Lenguajes de programación. Tipos

Las instrucciones de los programas que ha de ejecutar el ordenador para resolver un
determinado problema deben estar escritas en el lenguaje que comprenda el ordenador,
que es el lenguaje binario (compuesto por ceros y unos), pero sería enormemente com-
plicado para un programador escribir sus programas empleando únicamente ceros y
unos. Como se verá más adelante, quienes programan pueden utilizar lenguajes mu-
cho más cercanos al lenguaje natural que facilitan enormemente la creación de progra-
mas para resolver problemas complejos. Para ello, emplearán los llamados lenguajes
de programación de alto nivel. De hecho, es posible realizar una clasificación de los len-
guajes de programación en función de su cercanía a la máquina, esto es, en función
de la medida en que ese lenguaje es próximo al lenguaje binario directamente compren-
sible por un ordenador. No obstante, antes de proceder a describir dicha clasificación,
en este apartado, se caracterizarán los lenguajes de programación.
Un lenguaje de programación puede definirse como una notación para escribir programas
a través de los cuales es posible establecer una comunicación con el hardware y dar así
las órdenes necesarias para la realización de una determinada tarea. Los lenguajes de
programación vienen definidos por una gramática o conjunto de reglas que se aplican a
un alfabeto compuesto por un conjunto de símbolos.
Los elementos básicos de los lenguajes de programación son los siguientes:
E Identificadores: nombres simbólicos que se dan a ciertos elementos de programa-

ción (variables, tipos, módulos, etc.).
E Constantes: datos que no cambian su valor a lo largo del programa.
E Operadores: símbolos que representan operaciones entre variables, constantes y

expresiones.
E Instrucciones: símbolos especiales que representan estructuras de procesamiento

y de definición de elementos de programación.
E Comentarios: texto que se usa para documentar los programas.
Como se indicó anteriormente, se puede realizar una clasificación de los lenguajes de

programación atendiendo a la cercanía de dichos lenguajes respecto al lenguaje que uti-
liza el ordenador (lenguaje binario) o respecto al lenguaje de las personas o lenguaje na-
tural. Sobre la base de este parámetro, es posible establecer tres grupos de lenguajes:
E Lenguajes de bajo nivel o lenguajes máquina: el lenguaje máquina es el único lengua-

je de programación que entiende directamente la máquina. Utiliza el alfabeto bina-
rio (números O y 1) para establecer la comunicación con el hardware de la máquina.
Fue el primer lenguaje empleado para la programación de ordenadores, pero dejó de
usarse debido a su complejidad, siendo sustituido por otros más cercanos al lengua-
je natural, que eran más fáciles de aprender y de utilizar. Las instrucciones en el len-
guaje máquina son secuencias de unos y ceros. Para referirse a los datos que se
van a procesar, este lenguaje utiliza la dirección de memoria en la que se encuen-
tran, de forma que es tarea del programador asignar una dirección a cada dato.
1. DESARROLLO DE SOFTWARE |NFORMATICA / [Cf
E Lenguajes intermedios o lenguajes ensambladores: con estos lenguajes ya no se

utilizan códigos numéricos ni direcciones reales de memoria, sino que se sustitu-
yen por representaciones textuales, equivalentes a las instrucciones del lenguaje
máquina que representan, es decir, se codifican las instrucciones de forma simbó-
lica. A cada instrucción o dato, le corresponde un código mnemotécnico, cuya for-
mulación guarda alguna relación con la operación o el dato al que representa (por
ejemplo, pueden ser abreviaturas). Estos lenguajes utilizan direcciones simbólicas
en lugar de direcciones binarias para referirse a los datos. Los lenguajes ensambla-
dores guardan una estrecha relación con los lenguajes máquina, ya que cada ins-
trucción de los programas en lenguaje ensamblador corresponde a una instrucción
en lenguaje máquina; la diferencia radica en la forma de codificación o representa-
ción de los lenguajes ensambladores, que es mucho más fácil de entender por el
hombre. Con el fin de que el ordenador entienda las instrucciones escritas en len-
guaje ensamblador, estas se traducen a lenguaje máquina (secuencias de ceros y
unos). Para ello se emplea un traductor, que también recibe el nombre de ensam-
blador. En la Figura 1.2 se muestra una porción de código en lenguaje ensamblador
y su correspondencia en lenguaje máquina. De este proceso de transformación se
encarga un ensamblador.
LENGUAJE ENSAMBLADOR LENGUAJE MÁQUINA
ADD CL, AL 0001 1001 0100 1101

ENSAMBLADOR
MOV CL, 325 0110 0011 0001 1110
SUB CL, 45 1100 0000 0001 1010
Figura 1.2. Las instrucciones en lenguaje ensamblador están escritas empleando códigos mnemotécnicos
(add indica sumar; mov, mover; etc.) y cada instrucción corresponde a una instrucción en lenguaje
máquina. Para pasar del lenguaje ensamblador al lenguaje máquina se usa un traductor llamado
ensamblador.
m Lenguajes de alto nivel o lenguajes evolucionados: tienen como objetivo principal li-
berar al programador de tareas tediosas y complejas que pueden frenar su producti-
vidad y eficiencia. Esto se consigue gracias al gran nivel de abstracción que ofrecen
estos lenguajes, lo cual hace que sea innecesario que las programadoras y progra-
madores conozcan las características de la máquina. Otra ventaja es la proximidad
que presentan estos lenguajes respecto al lenguaje natural. Sus características
más importantes son las siguientes:
— Las instrucciones se expresan por medio de caracteres alfanuméricos, numéri-

cos y especiales.
— Se pueden definir variables para recoger los datos que se vayan a tratar. Estas
variables pueden adoptar la forma de complejas estructuras de datos, lo que fa-
cilita enormemente la labor de programación.
— Pueden incluirse líneas de comentarios.
— Disponen de instrucciones muy potentes de tipo aritmético, lógicas, de trata-

miento de caracteres, etcétera.
| l/ 1*OMUNÍCACIONES 1. DESARROLLO DE SOFTWARE
— El tiempo de codificación y puesta a punto de los programas es mucho menor

que el requerido por los anteriores lenguajes.
— Resultan más fáciles de corregir y modificar, lo que conlleva un gran ahorro de

tiempo de programación.
— La curva de aprendizaje de las personas responsables de la programación es

más corta y menos pronunciada que con los lenguajes máquina y ensambladores.
Sin embargo, no todo son ventajas: estos programas también presentan inconve-
nientes:
— Los programas escritos en estos lenguajes no pueden ejecutarse directamente,

por lo que existe un tiempo durante el cual se deben traducir, tiempo que los an-
teriores no requieren.
— La ocupación de memoria se incrementa, tanto por el traductor como por el pro-

grama traducido. No obstante, hoy en día, las posibilidades que nos ofrece el
hardware y los sistemas operativos restan importancia a esta cuestión.
— La eficiencia en el consumo de recursos y las prestaciones conseguidas son

bastante menores que con los lenguajes máquina y ensambladores.
Figura 1.3. Nombres de algunos lenguajes de programación de alto nivel.
En el ámbito de los lenguajes de alto nivel, también es posible realizar una clasificación
en función del paradigma de programación empleado. Así, cabe distinguir entre /enguajes
estructurados y lenguajes orientados a objetos.
Los lenguajes de programación estructurados se caracterizan por el empleo exclusivo

de tres estructuras para la creación de cualquier programa: la estructura secuencial, la
alternativa y la repetitiva. Además, en la metodología estructurada, para la que se em-

plean los lenguajes estructurados, las aplicaciones informáticas integran diversos com-
ponentes de software llamados módulos. Un módulo realiza determinadas tareas de
procesamiento, para lo que requiere utilizar determinados datos. Por lo tanto, una apli-
cación informática se compone de diversos módulos que realizan pequeñas tareas. Los
1. DESARROLLO DE SOFTWARE |NFORMÁT'CA Y CON
módulos se combinan entre sí, realizándose llamadas de unos a otros. En estas llama-
das, los módulos se pasan datos (llamados parámetros) y a veces devuelven resultados.
Los módulos pueden ser de dos tipos: procedimientos o funciones. La diferencia entre
estos es que las funciones devuelven algún dato como resultado de su ejecución, mien-
tras que los procedimientos no lo hacen.
Argot técnico
En algunos lenguajes de programación, como C, no se realiza de manera explícita la
distinción entre procedimiento y función, sino que se llama función a cualquier módulo.
En estos lenguajes, una función puede devolver un resultado o no devolver nada, de forma
que se puede considerar que, conceptualmente, las funciones que no devuelven ningún
resultado son en realidad procedimientos.
La arquitectura de una aplicación informática consta de un módulo de control principal

que llama a varios módulos subordinados. Estos módulos llaman a otros y así sucesiva-
mente. La arquitectura de un programa se puede representar mediante lo que es conoci-
do como diagrama de estructuras, en el que cada rectángulo representa un módulo y las
flechas que unen los módulos representan las llamadas. Estas llamadas parten de un
módulo y llegan a otro. En el diagrama de estructuras de la Figura 1.4, el módulo de con-
trol principal se llama A y este módulo llama a los módulos subordinados B y C; a su vez,
B llama al D y al E, y el C llama al F.
-
Figura 1.4. Diagrama de estructuras que muestra la arquitectura de una aplicación informática siguiendo
la metodología estructurada.
En la metodología estructurada, la atención se centra en los procesos o tareas que de-

ben realizarse para resolver un determinado problema y estos procesos o tareas se dis-
tribuyen en módulos que los ejecutan. Para llevar a cabo estos procesos, es necesario
que los módulos manipulen ciertos datos. Los datos que se tienen que almacenar de
manera permanente se registran en una base de datos, sobre la que los diferentes mó-
dulos realizan operaciones de consulta, inserción, modificación o borrado.
Son ejemplos de lenguajes de programación estructurados: Pascal, C, COBOL.

Los lenguajes orientados a objetos, que surgieron más tarde, supusieron en cierto modo
un cambio de visión en relación con el desarrollo de software. Se pasó de un enfoque
centrado en los procesos a prestar mayor atención a los datos sobre los que había
que operar. Según el paradigma orientado a objetos, se considera que una aplicación
| JMUNÍCACIONES 1. DESARROLLO DE SOFTWARE
informática consta de diversos objetos que interactúan entre sí. Un objeto es una instan-
cia de una clase, la cual está constituida por una serie de datos y un conjunto de ope-
raciones que se aplican sobre dichos datos. Los datos de una clase reciben el nombre
de atributos y las operaciones que se aplican sobre esos datos se llaman métodos. La
ejecución de todas las tareas encomendadas a un programa se logra mediante la parti-
cipación cooperativa de los objetos que componen la aplicación. Si en las metodologías
estructuradas, esta participación cooperativa se conseguía mediante las llamadas de
unos mádulos a otros, en el paradigma orientado a objetos, esta se consigue mediante
el envío de mensajes. Un mensaje representa la solicitud enviada desde un método de
un objeto para que otro objeto o él mismo ejecute otro método.
Por otra parte, un objeto se identifica por un conjunto de datos que configuran su esta-
do y un conjunto de métodos que indican el comportamiento que muestra dicho objeto:
M El estado de un objeto viene determinado por el conjunto de propiedades o atributos

que tiene el objeto y los valores que toman estos en cada momento. En el sistema de
gestión de una biblioteca, un objeto puede ser un libro en concreto y su estado pue-
de venir definido por los atributos: código, ISBN, título, editorial, número de páginas
y su situación de prestado o no; junto con los valores que toma cada uno de estos
atributos para ese libro en concreto, por ejemplo: A087 para el código; el número
1234567890123 sería el valor del ISBN; el título tomaría como valor «Introducción a la
programación»; el valor de la editorial sería «Paraninfo», con 140 páginas y el valor de la
situación de prestado sería «falso». En el sistema de gestión de una entidad bancaria,
un objeto puede ser una cuenta bancaria en concreto y su estado puede estar defini-
do por los atributos número de cuenta y saldo. Los valores que tomarían estos atribu-
tos para una cuenta en concreto serían, por ejemplo, ES1200781234547708669999
para el número de cuenta y 4.323,65 euros para el saldo.
E El comportamiento de un objeto está determinado por la manera en que actúa al

recibir un mensaje por parte de otro objeto, posiblemente cambiando su estado. La
manera de responder a un mensaje es mediante la ejecución de una operación que
está asociada a dicho objeto.
Algunos ejemplos de lenguajes orientados a objetos son Java, C1 y C++.

Lenguajes de programación estructurados y orientados a objetos
Como sabes, se puede realizar una clasificación de los lenguajes de programación
de alto nivel en función de si permiten o no realizar programación orientada a ob-
jetos. Así, los que no la permiten se llaman /enguajes estructurados, y los que sí,
lenguajes orientados a objetos.
Investiga si los siguientes lenguajes de programación son estructurados u orienta-

dos a objetos: Python, Ruby, PHP, Pascal, Swift, Smalltalk, Scala.
Para el caso de los lenguajes estructurados, investiga cuáles de ellos han incor-
porado la programación orientada a objetos dando lugar a un lenguaje orientado a
objetos, tal y como ocurrió con el lenguaje orientado a objetos C++, que surgió como
extensión del lenguaje estructurado C.
1. DESARROLLO DE SOFTWARE |NFORMAT¡CA Y F
M 1.3. Código fuente, código objeto y código ejecutable.

Herramientas implicadas
Las instrucciones de los programas que ejecutan los ordenadores para resolver un de-
terminado problema deben estar escritas en el lenguaje que estos comprenden, que es
el lenguaje binario. Pero, como se ha señalado antes, programar en este lenguaje bina-
rio es una labor compleja y muy tediosa, por lo que, actualmente, se utilizan para ello
lenguajes de programación de alto nivel. Por este motivo, es necesario un proceso que
transforme el programa escrito en un lenguaje de alto nivel en otro escrito en lenguaje
máquina o lenguaje binario. Es en este proceso en el que se puede hablar de códigos
fuente, objeto y ejecutable.
Se considera código fuente aquel que el programador escribe directamente, por lo que
en casi todos los casos, consiste en instrucciones escritas siguiendo las normas de un
lenguaje de programación de alto nivel. Como el ordenador no comprende este lengua-
je, debe ser transformado en código objeto. Dependiendo de cómo se lleve a cabo este
proceso de traducción o de transformación del código fuente en código objeto, hay dos
tipos de traductores:
1. Compiladores. Son traductores que realizan su tarea de forma global, esto es,
en un único proceso se analiza todo el programa fuente, se genera el código ob-
jeto respectivo y se almacena el resultado. Todo esto se podrá llevar a cabo en
caso de que el programa fuente esté correctamente escrito de acuerdo con las
normas del lenguaje de programación correspondiente; en caso de que no sea
así, no se generará el código objeto y se mostrarán uno o varios mensajes de
error que pueden ayudar a la persona encargada de la programación a corregir
estos errores. El código objeto generado como resultado de la compilación, de-
pendiendo del tipo de compilador, se podrá ejecutar directamente o puede que
se precisen otros pasos antes de que el programa sea ejecutable, como los pa-
sos de ensamblado, enlazado y carga. Una vez obtenido el código ejecutable,
este se podrá ejecutar tantas veces como se desee sin necesidad de tener que
volver a realizar el proceso de compilación.
2. Intérpretes. A diferencia de lo que ocurre con los compiladores, estos simulta-

nean el proceso de traducción y el de ejecución. La forma de trabajo de los intér-
pretes es la siguiente: analizan bloques del programa fuente, generan el código
objeto correspondiente y lo ejecutan, luego repiten este proceso hasta que aca-
ba el programa. En la etapa de ejecución simplemente se pasa el control al códi-
go objeto generado y se espera a que termine su ejecución. De esta forma, cada
fragmento de código fuente solo se almacena provisionalmente.
En el caso del lenguaje Java, se combinan la compilación y la interpretación: el progra-

ma se compila en primer lugar, luego se genera un formato intermedio llamado bytecode
y este resultado es interpretado por la máquina virtual de Java.
| JMUNÍCAGONES 1. DESARROLLO DE SOFTWARE
Para realizar todo el proceso, desde la generación del código fuente hasta la ejecución
del programa, se precisa una serie de herramientas:
M Para escribir el código fuente se puede emplear un editor de textos simple o algu-
na herramienta de programación. Hay programas, como Notepadd++ o Sublime, que
permiten crear código fuente en diferentes lenguajes de programación y facilitan el
trabajo de las y los programadores, marcando los diferentes elementos del código
fuente en distintos colores, lo que facilita de manera importante la tarea de escritu-
ra del código fuente.
m En función del lenguaje de programación utilizado, para la transformación del códi-

go fuente en código objeto, se empleará un compilador o un intérprete.
m También puede ocurrir que el código objeto generado no sea ejecutable directamen-
te, en cuyo caso, será necesario emplear alguna herramienta adicional, como un
enlazador. El enlazador inserta en el código objeto una serie de rutinas y librerías
que permiten que el código sea directamente ejecutable por el ordenador.
No obstante, en lugar de utilizar estas herramientas de manera independiente, en la ac-

tualidad, se suele emplear un entorno de desarrollo integrado, que es una aplicación infor-
mática compuesta por un conjunto de herramientas que facilitan a la persona encargada
de la programación su tarea y posibilitan una mayor rapidez en la creación de programas.
La mayoría de los entornos de desarrollo incluyen, además de un editor de textos con
ayudas visuales y un compilador o un intérprete, otras herramientas, como un depurador
(para ayudar en la detección y corrección de errores de programación), una herramienta
de control de versiones y un constructor de interfaz gráfica.
B 1.4.Máquinas virtuales
Una máquina virtual es una aplicación que ejecuta los programas como si fuese una má-
quina real, aunque no lo sea. Existen dos tipos de máquinas virtuales:
1. Máquinas virtuales de sistema: son aplicaciones que emulan a un ordenador por

completo, de forma que se puede instalar en su interior otro sistema operativo
con su propio disco duro, memoria, tarjeta gráfica, etc. Se puede trabajar en la
máquina virtual de igual forma que si se tratase de una máquina real. Son ejem-
plos de aplicaciones de este tipo VMware Workstation y Virtual Box. Se pueden
utilizar estas máquinas virtuales para disponer de manera sencilla de varios sis-
temas operativos en el mismo ordenador (instalando uno de ellos en la máquina
real y otro diferente en la virtual). Esto permite, por ejemplo, evaluar nuevos siste-
mas operativos y probar aplicaciones en diferentes sistemas operativos. Sin em-
bargo, es importante tener en cuenta que las máquinas virtuales suponen una
carga importante para el ordenador físico en el que se instalan, por lo que se re-
quiere que este tenga una capacidad notable, sobre todo, en cuanto a disco duro
y memoria RAM.
1. DESARROLLO DE SOFTWARE ¡NFORMAHCA [
= Windows 7 x64 UBU - VMware Workstation ==
File Edit View VM Tabs Help
v m| OodIiaaeEm|oO
| Ú Windows 7 x64 UBU
3
Papelera de
'l
OraciexEl12
Wi
áí9 N
HediSQU9:5 64
U
SQL Developer
e
reciciaje
e
GetStarted
Oracle Database
With
D.O
Practicas SIA
Figura 1.5. Uso del programa VMware Workstation para poder utilizar, dentro de un equipo, otro equipo
que tiene incorporado su propio sistema operativo y disco duro, entre otras tecnologías.
2. Máquinas virtuales de proceso: estas máquinas ejecutan un proceso concreto den-

tro de un sistema operativo. Este tipo de máquinas se inician cuando se lanza el
proceso que se desea ejecutar y se detienen cuando este termina. El objetivo de
estas máquinas es permitir que un programa se ejecute de igual forma en cualquier
plataforma, proporcionando un entorno de ejecución independiente del hardware
y del sistema operativo y ocultando los detalles de la plataforma subyacente. El
ejemplo más popular de máquina virtual de proceso es la máquina virtual de Java.
La máquina virtual de Java (JVM, por sus siglas en inglés, Java virtual machine) es el
ejemplo típico de máquina virtual de proceso. Su ventaja es que dota de portabilidad al
lenguaje, de manera que un programa compilado en Java se puede ejecutar en cualquier
plataforma. Esto se debe a que el programa escrito en Java realmente no es ejecutado
por el procesador del ordenador, sino por la JVM.
-
La máquina virtual de Java (JVM), como se estudiará en la Unidad 2, forma parte del entorno
en tiempo de ejecución de Java (JRE, por sus siglas en inglés, Java Runtime Environment),
que está constituido por un conjunto de utilidades que permite la ejecución de programas
en Java. El JRE incluye, además de la JVM, un conjunto de librerías de Java y otros
componentes necesarios para que un programa escrito en Java se pueda ejecutar.
O MUNICACIONES
1. DESARROLLO DE SOFTWARE
El proceso que se lleva a cabo para poder ejecutar un programa escrito en Java es el si-
guiente:
1. La persona encargada de la programación escribe el código fuente del programa

en lenguaje Java mediante el empleo de un editor de textos, para lo que puede
usar el que viene incorporado en el entorno de desarrollo integrado. De esta ma-
nera, se genera un archivo de texto con extensión .java.
2. Se compila el programa fuente mediante el compilador javac, que también viene

incorporado en el entorno de desarrollo, lo que da lugar a un fichero con extensión
.class, en caso de que no haya errores en el código fuente. Este fichero contiene
código en un lenguaje intermedio llamado bytecode, que es independiente del or-
denador y del sistema operativo en el que se ejecuta.
3. La máquina virtual de Java traduce el archivo con extensión .class al código bina-
rio para que el programa pueda ser ejecutado. Como la JVM está disponible en
diferentes sistemas operativos, los archivos con extensión .class se pueden eje-
cutar en distintas plataformas, como Windows, Linux, macOS, etcétera.
Código Código Máquina .

fuente »
_ € bytecode _»
_ vitual — ——» ej(e:ggtlggle
Clase.java Clase.class de Java
Figura 1.6. Proceso de obtención del código ejecutable de un programa escrito en Java: se parte del
código fuente, que se plasma en un archivo con extensión .java por cada clase; con el compilador javac
se transforma en un archivo con extensión .class escrito en código bytecode; finalmente, la JVM transforma
este archivo en código ejecutable.
M 1.5.La ingeniería del software

La definición de software que propuso Pressman (véase Apartado 1.1) deja patente que
el software no es solo un programa que funciona, que es obviamente lo más importante,
sino que también comprende las estructuras de datos sobre las que opera el programa
y la documentación resultado del proceso de desarrollo, así como la que describe cómo
se debe usar el programa.
Es importante destacar que el proceso de desarrollo de software no fue concebido en

sus inicios como un proceso de ingeniería, sino más bien como un trabajo artesanal en
el que cada persona desarrolladora de software se ponía a programar directamente sin
llevar a cabo fases previas y sin seguir unas normas mínimas.
En la década de los 70 del siglo xx, se produjo lo que se conoce como la crisis del software,
que se refiere a un conjunto de problemas encontrados en el desarrollo de software. Esta
crisis abarcaba cómo desarrollar el software, cómo mantenerlo y cómo satisfacer la de-
manda creciente de software.
Los problemas fundamentales del software eran que:
m La planificación y estimación de costes eran frecuentemente muy imprecisas.

M La productividad de quienes desarrollaban el software no se correspondía con la

demanda de sus servicios.
M La calidad del software no llegaba a veces a ser ni adecuada.
Se llegó a la conclusión de que todos estos problemas podían corregirse y que la clave
estaba en dar un enfoque de ingeniería al desarrollo del software, junto con la mejora de
las técnicas y las herramientas.
Todo esto desembocó en el nacimiento de la ingeniería del software, que es una disci-
plina para el desarrollo de software que surgió a partir de la ingeniería de sistemas y de
hardware. La definición que propuso Fitz Bauer para la ingeniería del software es: «el es-
tablecimiento y uso de principios de ingeniería para llegar a un obtener un software renta-
ble, que sea fiable y que funcione eficientemente en máquinas reales».
E
IMPLANTACIÓN
e
DESARROLLO
INGENIERÍA
DEL SOFTWARE
DISEÑO 7A /N(
m VALIDACIÓN º
Y VERIFICACIÓN
PRUEBAS
Figura 1.7. La ingeniería del software incluye una serie de tareas de desarrollo como la planificación, el análisis,
diseño, programación, pruebas e implantación. Aquí también se muestran otros conceptos relacionados
con el desarrollo de software, como el propio desarrollo y la validación y verificación de este.
El objetivo fundamental de la ingeniería del software es, por tanto, regular de alguna ma-
nera el desarrollo de software, es decir, establecer de manera clara las tareas que es ne-
cesario realizar para crear aplicaciones informáticas, realizando controles que aseguren
que la calidad de los programas resultantes sea aceptable.
Argot técnico
Según la RAE, el término ingeniería se refiere al «conjunto de conocimientos orientados a la
invención y utilización de técnicas para el aprovechamiento de los recursos naturales o para
la actividad industrial».
En el caso del software, esta definición es aplicable a la actividad industrial consistente

en la creación de aplicaciones informáticas. Hace referencia, por tanto, al conjunto de
conocimientos relacionados con el empleo de las técnicas necesarias para el desarrollo de
software.
| JMUN'CAGONES 1. DESARROLLO DE SOFTWARE
Se suele emplear también el término proceso software para referirse a los pasos necesa-
rios para desarrollar una aplicación informática. En este sentido, una de las acepciones
del vocablo proceso en el diccionario de la RAE es la siguiente: «conjunto de las fases
sucesivas de un fenómeno natural o de una operación artificial». Se puede, por tanto, in-
terpretar que el proceso de ingeniería del software o proceso software hace referencia al
conjunto de fases para la construcción de software. En el Apartado 1.6, se estudiarán a
fondo las tareas necesarias para el desarrollo de software.
M 1.6. Fases del desarrollo de una aplicación informática

Para la obtención de software, es necesario completar una serie de fases en las que se
realizan una serie de tareas, que se exponen a continuación:
E Análisis: el objetivo de esta tarea es analizar las necesidades de los usuarios po-
tenciales del software para determinar qué debe hacer la aplicación y, de acuerdo
con ello, escribir una especificación precisa de dicho sistema. Durante esta fase
se pretende responder a las siguientes preguntas: qué información ha de ser pro-
cesada, qué función y rendimiento se desean, qué interfaces deben establecerse,
qué restricciones de diseño existen y qué criterios de validación se necesitan para
definir un sistema correcto. Para ello, como es obvio, es necesario realizar una ac-
tividad inicial de comunicación con el cliente que ha encargado el desarrollo de la
aplicación, y una vez obtenida la información necesaria, se podrá modelar el siste-
ma. Como resultado, se obtendrá una especificación del sistema, que consistirá en
una documentación que describe lo que tiene que hacer el software, pero no cómo.
Es primordial que esta documentación sea comprensible, completa y fácil de verifi-
car y de modificar para facilitar todo el trabajo posterior.
E Diseño: si bien el objetivo de la fase de análisis es determinar qué debe hacer el

sistema, una vez se sabe esto, es preciso establecer cómo se va a resolver el pro-
blema planteado. Durante esta fase, se traducen los requisitos resultado de la fase
de análisis en componentes de software (tablas de una base de datos, programas
con procedimientos o funciones, clases con atributos y métodos, interfaz de usua-
rio, etc.). Se trata de un refinamiento de la fase anterior. Por ejemplo, en esta fase,
una de las decisiones que habrá que tomar es decidir qué sistema gestor de base
de datos (SGBD) se va a emplear para gestionar la información que debe ser usada
o generada por la aplicación: Oracle, MySQL, SQL Server, etcétera.
E Programación: consiste en traducir los resultados de la fase de diseño en una for-

ma legible para la máquina, es decir, se escribe el código fuente de cada com-
ponente del software empleando un determinado lenguaje de programación. El
resultado de esta etapa es el código ejecutable.
m Pruebas: con estas se comprueba si la aplicación funciona correctamente. Hay dife-

rentes tipos de pruebas. Así, se comienza probando cada componente de software
por separado (pruebas unitarias) y, posteriormente, se van integrando poco a poco los
componentes (pruebas de integración), hasta probar el programa completo (pruebas
1. DESARROLLO DE SOFTWARE INFORMÁT|CA Y CCIJX '
de validación), cuyo objetivo es comprobar que la aplicación satisface los requisitos

del cliente. Como resultado de estas pruebas, se descubrirán errores, en atención a
los cuales, será necesario modificar el código, o incluso rehacer las tareas previas de
diseño y/o análisis.
m Explotación: en esta etapa, se lleva a cabo la instalación y puesta en marcha del

software en el entorno de trabajo del cliente.
E Mantenimiento: el software sufrirá cambios después de que se entregue al cliente

por diversos motivos. La tarea de mantenimiento consiste en realizar cambios so-
bre el software, para lo que se aplicará al programa existente, cada una de las acti-
vidades precedentes del ciclo de vida en vez de a uno nuevo.
Mantenimiento
Figura 1.8. Fases del desarrollo de una aplicación informática.
Recuerda
Aunque la tarea de mantenimiento parezca poco importante, hay estudios que indican que
más del 50 % del esfuerzo de desarrollo de software se dedica a esta tarea.
Esto se debe a que es muy común que toda aplicación informática, a lo largo de su vida,
debe ser sometida a ampliaciones, correcciones o a adaptaciones a nuevos entornos.
Por este motivo, es muy importante tener presente que, al desarrollar software, lo más
probable es que otras personas tengan que revisarlo y modificarlo, y por este motivo,
nuestro trabajo siempre debe poder ser entendido por esas personas.
Además de las tareas técnicas que se han señalado, es necesario llevar a cabo otra ta-
rea, que debe comenzar tras la comunicación inicial con el cliente y que es una actividad
más de gestión que técnica. Se trata de la tarea de planificación, que consiste en elabo-
rar un plan del proyecto de software que indique las tareas técnicas que se han de rea-
lizar, los riesgos probables, los recursos que se necesitan, los productos de trabajo que
se obtendrán y una programación de las actividades (qué actividades se deben ejecutar,
en qué orden, la duración de cada actividad, los recursos humanos y materiales necesa-
rios para cada actividad, etc.).
Por otro lado, además de todas estas actividades, que Pressman (2010) denomina ac-
tividades estructurales, para el desarrollo de software, es preciso realizar otras tareas
adicionales, de menor carácter técnico y también relacionadas con la gestión, y que
Pressman (2010) llamó actividades sombrilla:
E Seguimiento y control del proyecto de software: se debe evaluar periódicamente el

proyecto comparándolo con el plan preestablecido con el fin de tomar acciones si

se produce algún desvío respecto al plan.
E Administración del riesgo: consiste en evaluar los riesgos (problemas) que pueden
afectar al resultado del proyecto o a la calidad del producto.
*OMUNICACIONES 1. DESARROLLO DE SOFTWARE
E Aseguramiento de la calidad del software: se definen y ejecutan las actividades ne-

cesarias para garantizar la calidad del software.
M Revisiones técnicas: se evalúan los productos obtenidos con el fin de descubrir y eli-
minar errores antes de que se propaguen a la siguiente actividad.
m Medición: consiste en definir y reunir las mediciones del proceso, proyecto y produc-
to para ayudar al equipo a entregar el software que satisfaga las necesidades del
cliente.
E Administración de la configuración del software: se administran los efectos del cam-

bio a lo largo del proceso de desarrollo de software.
E Administración de la reutilización: se establecen los criterios para poder usar pro-

ductos del trabajo en proyectos posteriores y los mecanismos para que esto se
pueda llevar a la práctica, es decir, para obtener componentes reutilizables.
E Preparación y producción del producto del trabajo: se agrupan las actividades nece-
sarias para crear productos del trabajo, como modelos, documentos, registros, for-
matos, etcétera.
Seguidamente, se amplía la explicación de cada una de las actividades estructurales de

la ingeniería del software.
ME 1.6.1.Análisis
El objetivo de esta actividad estructural de análisis es lograr una comprensión clara del
problema que se necesita resolver o, dicho de otro modo, de los requisitos funcionales
que debe cumplir la aplicación que el cliente ha encargado.
Esta tarea no es sencilla por diversos motivos:
M El cliente puede no tener claro qué requisitos debe satisfacer la aplicación.
E El cliente tiene claros los requisitos, pero no es capaz de expresarlos de manera

comprensible para el equipo de desarrollo.
m Puede haber malentendidos entre el equipo de desarrollo y el cliente por la razón

indicada en el punto anterior, por desconocimiento del problema que hay que resol-
ver por parte del equipo de desarrollo, o por desconocimiento de lo que la tecnolo-
gía puede ofrecer por parte del cliente.
Además de los requisitos funcionales, que hacen referencia a lo que tiene que hacer la
aplicación, hay otro tipo de requisitos llamados no funcionales, como los siguientes:
E Fiabilidad: grado en que una aplicación funciona sin fallos.

M Escalabilidad: capacidad del sistema para manejar aumentos de carga sin disminuir
el rendimiento.
M Extensibilidad: capacidad del software para añadir nuevas funcionalidades y compo-

nentes.
1. DESARROLLO DE SOFTWARE INFORMÁT|CA Y ((a/ y
E Seguridad: grado con que una aplicación protege la información contra el acceso in-
debido a ella.
m Mantenibilidad: grado en que el software es comprendido, reparado o mejorado.
Estos requisitos también hay que tenerlos en cuenta para crear una aplicación que res-
ponda a las necesidades del cliente.
Antes de elaborar los modelos que son el resultado de la fase de análisis, es necesaria
una tarea de comunicación con el cliente, para la que se pueden emplear distintas téc-
nicas, como:
M Entrevistas: es la técnica más tradicional. Es similar a una entrevista periodística en

la que el analista entrevista, uno a uno, a los futuros usuarios del software.
m Desarrollo conjunto de aplicaciones (JAD, por sus siglas en inglés, joint application
development): se crea un equipo de analistas y usuarios que se reúnen para traba-
jar conjuntamente en la determinación de las necesidades de los usuarios.
E Desarrollo de un prototipo: consiste en construir un modelo o maqueta del sistema
que permite ver a los usuarios las características del sistema que desean obtener.
El prototipo se puede o bien usar solo para este fin y se desecha, o bien se puede
mejorar para convertirlo en el producto final.
Como resultado de esta fase, se debe obtener un documento llamado especificación de

requisitos del software (ERS), que sirve de base para la siguiente etapa de diseño.
En la ERS, se incluyen modelos gráficos con apoyos textuales. Dichos modelos tienen la
ventaja de no ser ambiguos, a diferencia del lenguaje natural (español, inglés, etc.), y al
ser creados con herramientas informáticas, son fácilmente modificables. En esta etapa,
se crearán tanto diagramas de clases como diagramas de casos de uso, que se estudia-
rán en las Unidades 5 y 6 de este libro, respectivamente. En la Figura 1.9, se muestra un
diagrama de casos de uso.
Transferencia por internet
<<incluye>> . ..
______________ - a M Identificación
. <<incluye>>
Glieñte — . — eÉ A YE nl ea si h
Figura 1.9. Este diagrama de casos de uso refleja los requisitos funcionales que debe satisfacer una aplicación
para una entidad bancaria en la que los usuarios pueden realizar tres tipos de operaciones con su cuenta
bancaria: ingresar dinero, extraer dinero o realizar una transferencia. Para los dos últimos tipos de operaciones,
los clientes se tienen que identificar.
“ñ MUNICAGONES 1. DESARROLLO DE SOFTWARE
BNE 1.6.2.Diseño
Partiendo de la ERS obtenida en la etapa anterior, que indica, en esencia, cuál es el pro-
blema que se ha de resolver con la aplicación, en la etapa de diseño, se determina cómo
se ha de solucionar dicho problema. Para ello, se partirá de los diagramas obtenidos en
la etapa de análisis, refinando algunos de ellos y creando otros que indiquen los pasos
que hay que dar para responder a los requisitos establecidos.
Por ejemplo, partiendo del diagrama de casos de uso obtenido en la etapa de análisis,
se tratará de establecer que acciones hay que llevar a cabo para ejecutar cada caso de
uso, teniendo en cuenta que cada caso de uso se corresponde generalmente con un re-
quisito funcional. Así, tomando como ejemplo el diagrama de casos de uso de la Figu-
ra 1.9, en la etapa de diseño, habrá que indicar cuáles son los pasos necesarios para
realizar una transferencia de dinero de una cuenta a otra. De esta forma, cada caso de
uso genera un diagrama de interacción que detalla los pasos necesarios para ejecutarlo.
ME 1.0.3. Programación
Se parte del diseño detallado y, en esta fase, se escribe el código fuente correspondien-
te siguiendo las normas del lenguaje de programación de alto nivel seleccionado.
Es habitual que se establezcan determinadas normas a la hora de escribir el código fuen-

te con el fin de que los programas tengan un aspecto homogéneo y sean fáciles de en-
tender y, por tanto, de modificar, sobre todo si se tiene en cuenta la relevancia de las
posteriores tareas de mantenimiento. Normalmente, se establecen normas en relación
con los siguientes elementos:
E Comentarios: se suelen escribir al comienzo de determinadas partes del código

para describir su razón de ser (al comienzo de una clase, al indicar cada atributo de
una clase, al comienzo de cada método, etc.) y para aclarar determinadas porcio-
nes de código por su alto nivel de complejidad.
Declaraciones de variables y de parámetros de métodos.
Nombres de clases, atributos, métodos, variables, constantes, etc.
Líneas en blanco entre clases, métodos, etc.
Sangrados para facilitar la legibilidad del código.
A modo de ejemplo, se muestran dos representaciones del código fuente de un progra-

ma que suma los números pares comprendidos entre el 1 y el número introducido por el
teclado. La segunda versión del programa es más comprensible porque incluye comenta-
rios, sangrados y líneas en blanco para separar los elementos del código.
Primera versión del programa:
1 package programas; import java.util.Scanner;

2 public class PruebaSumaPares (
1. DESARROLLO DE SOFTWARE |NFORMÁT|CA Y CO/X/ 1
3 public static void main(String[] args) (

4 int suma = 0; int mum = 1;
5 System.out .print (“Introduzca un número mayor o igual que 1: “);
6 Scanner teclado = new Scanner (System.in);
7 int máximo = teclado.nextInt();
S while (num <= máximo) f
9 if (num % 2 == 0) suma = suma + num; +-+num; ]
10 System.out .printin (“La suma de los números pares entre 1 y “
+ máximo + “ es “+suma);
11 )
12 )
Segunda versión del programa:
1 package programas;
a import java.util.Scanner;
3 public class PruebaSumaPares (
3 //Declaramos una variable para que contenga el resultado de
las sumas
6 int suma = 0;
7 /*Usamos la variable num para contener todos los números
8 comprendidos entre 1 y máximo*/
9 Tnt num =
10 System.out.print (“Introduzca un número mayor o igual que 1: “);
ha //Leemos un número entero por teclado y lo almacenamos en
máximo
12 Scanner teclado = new Scanner (System.in);
13 int máximo = teclado.nextInt();
14 //Sumamos los números pares comprendidos entre 1 y máximo
15 while (num <= máximo) f
16 if (num % 2 == 0)
17 suma = suma + num;
18 ++num;
19 )
20 System.out .printiln (“La suma de los números pares entre 1 y
“ + Máximo + “ es “+suma);
21 )
22
BNE 1.6.4.Pruebas
El objetivo de esta actividad es detectar errores en el software antes de que este sea en-
tregado al cliente. La estrategia que se aplica en dichas pruebas consiste en realizarlas
desde los elementos más pequeños hasta los más grandes, es decir, se comienza pro-
bando pequeños componentes de software hasta llegar al programa completo.
- —Í,j.¡“*-/'/qí UN'CAGONES 1. DESARROLLO DE SOFTWARE
El objetivo de las pruebas es doble: verificar y validar el software. En otras palabras:
E Por medio de la verificación, se determina si el software se ha construido correcta-

mente, es decir, si las tareas que realiza las lleva a cabo de manera adecuada.
E La validación consiste en comprobar si el software es realmente el que el usuario

desea, o sea, si el sistema hace lo que quiere el usuario.
Existen dos tipos de técnicas de pruebas:
1. Las pruebas de caja blanca o pruebas estructurales: se examinan los detalles de cada
módulo, para lo que se debe disponer del código fuente. Así, se prueban los diferen-
tes caminos a través de este código, así como los bucles, las variables, etcétera.
2. Las pruebas de caja negra o pruebas funcionales: el software se considera como

una caja negra que recibe una serie de entradas y proporciona una serie de salidas.
El objetivo es validar los requisitos funcionales.
Lo habitual es emplear estas dos técnicas de pruebas. De hecho, se pueden combinar

y se complementan perfectamente. Si al realizar una prueba esta tiene éxito, es decir, si
se detecta algún error, se procede al proceso de depuración, que consiste en localizar y
corregir el error. Esto puede suponer realizar cambios solo en la programación, o también
en etapas previas, como el diseño, o incluso el análisis.
Pruebas de caja blanca Pruebas de caja negra
Entrada Entrada
Figura 1.10. En las pruebas de caja blanca es necesario conocer el código fuente para realizar las pruebas,
mientras que en las de caja negra, solo es necesario conocer las funciones que realiza el software
para comprobar si la salida obtenida coincide con la esperada.
ME 1.6.5. Explotación
Una vez que se ha probado el software, se han corregido los errores detectados y se ha
documentado todo el proceso, se lleva a cabo la instalación y la puesta a punto y en fun-
cionamiento de la aplicación en las instalaciones del cliente. Durante esta fase, es nece-
saria la presencia del cliente. Por lo tanto, las tareas de esta fase son:
E Se instalan los programas en el equipo o los equipos del cliente.
E Se llevan a cabo las comprobaciones conocidas como pruebas beta, que se realizan
en las instalaciones del cliente.
E Se realiza la configuración del sistema y se comprueba que la aplicación funciona

de manera adecuada.
E Una vez completados los pasos anteriores, la aplicación ya pasa a la fase de pro-
ducción normal, esto es, a su uso por parte del usuario final.
1. DESARROLLO DE SOFTWARE |NFORMATÍCA Y KF
ME 1.6.6. Mantenimiento
Hay diferentes tipos de mantenimiento en función del motivo que lo origina:
E Mantenimiento correctivo: este se debe a que el cliente detecta errores en el software

a pesar de las pruebas que se realizaron, y consiste en corregir estos errores.
E Mantenimiento adaptativo: en muchos casos el software deba adaptarse a cambios

del entorno externo porque, por ejemplo, se tiene un nuevo sistema operativo. Este
tipo de mantenimiento se realiza frecuentemente por los rápidos avances en el ám-
bito de la informática.
E Mantenimiento perfectivo: es muy común que, con el paso del tiempo, el cliente so-
licite ampliaciones funcionales, es decir, desee que la aplicación incorpore nuevos
requisitos funcionales. Asimismo, es posible que se deseen mejoras en requisitos
no funcionales, por ejemplo, que el programa se ejecute más rápidamente o que se
incremente la seguridad del sistema.
M 1.7.Holes que intervienen en el proceso de desarrollo

de software
Puesto que el desarrollo de software se puede dividir en distintas tareas, es habitual con-
tar con una persona experta para cada una de ellas, lo que origina que en el campo de la
ingeniería del software existan diferentes roles:
E Jefe de proyecto: lleva a cabo la tarea de planificación del proyecto, que incluye,
además de la propia planificación, la puesta en marcha del proyecto, su ejecu-
ción, seguimiento, control y cierre. Se trata, pues, de una tarea más de gestión que
técnica pero de gran relevancia, pues puede influir de manera decisiva en el éxito
o fracaso del proyecto. Se trata del máximo responsable de que el proyecto salga
adelante.
E Expertos del dominio: son personas que trabajan en la empresa u organismo para
el que hay que desarrollar la aplicación y que conocen el dominio del problema, es
decir, la parte de la realidad para la que se va a crear la aplicación. Los técnicos de-
ben comunicarse con estas personas, puesto que son las que conocen en detalle
los requisitos que la aplicación debe satisfacer.
E Analista: su cometido es la tarea de análisis, que consiste en crear un modelo cla-

ro y consistente que se corresponda con la visión del problema que ha conseguido
con la ayuda de los expertos del dominio. Este rol también se conoce frecuente-
mente como analista funcional.
E Arquitecto: a partir del trabajo realizado por el analista, debe definir las líneas
maestras del diseño, estableciendo la arquitectura del sistema, esto es, la mane-
ra en que este se divide en una serie de componentes. Esta arquitectura deberá
ser tomada como referencia por el resto de personas desarrolladoras para llevar a
buen término su trabajo.
]MUN4CACIONES 1. DESARROLLO DE SOFTWARE
E Diseñador: parte de un subconjunto de los requisitos definidos por el analista y de

la arquitectura del sistema para diseñar las partes del sistema que implementan
esos requisitos hasta un nivel de detalle suficiente para acometer la tarea de pro-
gramación. Este rol también se conoce como analista orgánico o analista técnico.
E Programador: se encarga de la tarea de programación, es decir, de escribir el códi-

go fuente partiendo del diseño detallado realizado por el diseñador.
E Probador: se encarga de la tarea de pruebas y, por tanto, de garantizar la calidad de

la aplicación creada. Para ello partirá de los requisitos y de los programas, y se en-
cargará de probarlos para decidir, en último término, si están en condiciones de ser
entregados al usuario final.
E Encargado de la implantación: es el encargado de que se realice el empaquetado

de los programas y su instalación en el entorno de trabajo del cliente. También es
el encargado de gestionar la configuración y, por tanto, las diferentes versiones que
vayan surgiendo de la aplicación a partir de los cambios que se vayan incorporando.
Esta distribución de roles no indica necesariamente que cada rol sea desempeñado por
una sola persona ni tampoco que una misma persona no pueda desempeñar varios ro-
les. Estos hacen referencia simplemente a los distintos papeles que deben desempe-
har personas en el desarrollo de software, pero cada uno puede ser desempeñado por
una o varias personas o, incluso, una persona puede desempeñar varios de estos roles,
lo que dependerá de las características de la aplicación que se esté desarrollando, del
equipo de desarrollo con que se cuente y de las características y organización de la em-
presa de desarrollo.
SNE — V e 3 - e Y
[) * A . * .V. E . o
| E ./ .
- " H N ".. h
D o A
Figura 1.11. El trabajo conjunto y cohesionado de todos los miembros del equipo de desarrollo bajo el mando
de un líder (jefe de proyecto) es un aspecto fundamental para el éxito del proyecto.
1. DESARROLLO DE SOFTWARE |NFORMAT¡CA Y [F
MN 1.5 Modelos de cicio de vida del software

Si bien las actividades necesarias para el desarrollo de software son las expuestas en el
Apartado 1.6, estas se pueden organizar de diferentes maneras en función de las carac-
terísticas del proyecto o del producto, del personal involucrado en el desarrollo, etc. Esto
se plasma en el empleo de un determinado ciclo de vida del software.
Piattini et al. (2007) proporcionan la siguiente definición para el concepto de ciclo de

vida: «el ciclo de vida del software es la descripción de las distintas formas de desarrollo
de un proyecto o aplicación informática, es decir, la orientación que debe seguirse para
obtener, a partir de los requerimientos del cliente, sistemas que puedan ser utilizados
por dicho cliente».
Un ciclo de vida determina el orden en el que se deben llevar a cabo las tareas en el pro-
ceso de desarrollo de software y los criterios que se deben cumplir para realizar el paso
de una tarea a la siguiente. Estos criterios consisten en la obtención de ciertos produc-
tos intermedios y, también, en indicar las características que deben satisfacer estos pro-
ductos para progresar a la fase posterior. Por ejemplo, como resultado de la tarea de
análisis, se debe obtener una ERS y se puede establecer qué condiciones debe cumplir
esta para poder avanzar a la fase de diseño.
De todo ello se deduce que la selección del ciclo de vida para un proyecto es una tarea
muy relevante que puede influir de manera decisiva en su éxito o fracaso.
El ciclo de vida que surgió en primer lugar es el llamado ciclo de vida clásico o modelo
en cascada. Posteriormente, se desarrollaron otros modelos: de proceso incremental, de
proceso evolutivo y de desarrollo ágil. En los siguientes apartados, se describe cada uno
de ellos.
ME 1.8.1.Modelo en cascada
El modelo en cascada, también llamado ciclo de vida clásico, es el modelo más primitivo
de ciclo de vida, pero ha resultado fundamental para el progreso posterior porque en él
se identifican ya prácticamente todas las clases de actividades distintas que intervienen
en el desarrollo y explotación de software.
En este modelo, se propone un enfoque sistemático y secuencial para el desarrollo de

software, comenzando con el análisis y continuando a través del diseño, la programación
y las pruebas hasta llegar al software terminado, sobre el que se pueden aplicar también
operaciones de mantenimiento. La Figura 1.12 muestra este flujo de actividades.
Se plantea un flujo secuencial de las actividades y para pasar de una fase a la siguiente
es necesario cumplir ciertos objetivos. Para detectar los errores lo antes posible y evitar
que se propaguen a fases posteriores, se establece un proceso de revisión al completar

cada fase, antes de pasar a la siguiente. Esta revisión se realiza fundamentalmente so-
bre la documentación producida en esa fase y se hace de una manera formal. Si, a pe-
sar de todo, durante la realización de una fase, se detectan errores en el resultado de
fases anteriores, será necesario rehacer parte del trabajo volviendo a un punto anterior
| i/ 1OÍVH.J'X“CIAXCIO'XIES 1. DESARROLLO DE SOFTWARE
del ciclo de vida, como se indica con las flechas de la Figura 1.12. Por ejemplo, si en la
etapa de mantenimiento, se detecta que se cometió algún error en el diseño, será nece-
sario corregir dicho error de diseño y realizar cambios en las etapas posteriores de pro-
gramación y pruebas.
Mantenimiento
Figura 1.12. Representación del modelo en cascada o ciclo de vida clásico. Las cinco actividades
que se muestran se deben ejecutar en secuencia, si bien se permite volver hacia atrás cuando
se detecta la necesidad de realizar algún cambio.
Este modelo tiene, entre otras ventajas, que es fácil de comprender, de planificar y de se-
guir, y existen además herramientas que lo soportan. Sin embargo, entre los problemas
de este modelo se encuentran los siguientes (Pressman, 2010):
E En la realidad, es raro que los proyectos sigan el flujo secuencial propuesto por el
modelo. Aunque este modelo acepta repeticiones, lo hace de forma indirecta. Como
resultado, los cambios generan confusión conforme el equipo del proyecto avanza.
E A menudo, es difícil para el cliente enunciar de forma explícita todos los requeri-
mientos. Se debe tener presente que cuanto más tarde en el proceso de desarrollo
se detecte algún fallo en una fase previa, más costoso será incorporar los cambios
que ese fallo implique. Esto quiere decir que si durante la fase de programación se
ha detectado que algún requisito no se ha incorporado o se ha hecho de manera
errónea, será necesario rehacer todas las fases previas del ciclo de vida (análisis y
diseño).
E El cliente debe tener paciencia, ya que no se dispondrá de una versión funcional

del programa hasta que el proyecto esté muy avanzado. Sería desastroso si al revi-
sar el funcionamiento del programa supuestamente terminado, se detectara un fa-
llo grande en este.
Hoy día, el desarrollo de software está sometido a multitud de cambios, motivo por el
cual este modelo de ciclo de vida no resulta apropiado en la mayoría de los casos. A pe-
sar de ello, se podría emplear en aquellos casos en los que no es previsible que se pro-
duzcan cambios en los requisitos.
Dadas las desventajas de este modelo, se desarrollaron con posterioridad otros modelos
que se exponen a continuación.
1. DESARROLLO DE SOFTWARE INFORMÁTICA Y CQ/X1
ME 1.8.2.Modelos de proceso incremental

Uno de los inconvenientes más importantes del modelo en cascada es que el cliente no
dispone de una versión funcional del sistema hasta muy tarde. En muchos casos puede re-
sultar más conveniente proporcionar cierta funcionalidad parcial del software al cliente y
aumentarla en entregas posteriores. De esta manera, se concibe el desarrollo de software
como un proceso en el que se van produciendo diversos incrementos o entregables. Para la
elaboración de cada incremento, se siguen las actividades del modelo en cascada que se
indicaron anteriormente, como se puede observar en la Figura 1.13. En esta figura, para
simplificar, se han eliminado las líneas de retroalimentación que van de una fase a las fa-
ses previas.
Incremento N
Incremento 2
Incremento 1 'Mantenimiento
Mantenimiento
Mantenimiento
Figura 1.13. Representación del modelo incremental de desarrollo de software. El software se divide en una serie
de incrementos, en cada uno de los cuales se aplican los pasos del ciclo de vida clásico.
Entre las ventajas de este modelo, Cuevas et al. (2003) señalan las siguientes:
M Reduce los riesgos de retrasos, de cambios de requisitos y problemas de acepta-

ción.
E Los entregables intermedios facilitan la retroalimentación por parte de los clientes,

lo cual resulta ventajoso para evitar problemas mayores en los siguientes entrega-
bles.
E Permiten al usuario validar el sistema a medida que se construye.
Resulta recomendable emplear este modelo de ciclo de vida cuando no están bien defini-
dos los requisitos y es muy probable que se produzcan cambios.
| JMUN'CAGONES 1. DESARROLLO DE SOFTWARE
ME 1.8.3.Modelos de proceso evolutivo

Los modelos de proceso evolutivo tienen su razón de ser en el hecho de que «el software,
como todos los sistemas complejos, evoluciona en el tiempo. Es frecuente que los reque-
rimientos del negocio y del producto cambien conforme avanza el desarrollo, lo que hace
que no sea realista trazar una trayectoria rectilínea hacia el producto final [...] Se com-
prende bien el conjunto de requerimientos o el producto básico, pero los detalles del pro-
ducto o extensiones del sistema aún están por definirse» (Pressman, 2010).
Estos modelos son iterativos y se caracterizan por el desarrollo de versiones cada vez más
completas del software. Se presentan a continuación dos modelos de proceso evolutivo:
M EN Construcción de prototipos
Un prototipo se puede definir como un sistema auxiliar que permite probar experimental-
mente ciertas soluciones parciales a las necesidades del usuario o a los requisitos del
sistema. Puede tratarse de un modelo que describa la interacción hombre-máquina, de
manera que facilite al usuario la comprensión de cómo se producirá la interacción, o un
programa que implemente algunos subconjuntos de la funcionalidad de la aplicación. Es
conveniente seguir este modelo de ciclo de vida cuando el cliente es capaz de definir un
conjunto de objetivos generales para el software, pero no puede identificar los requeri-
mientos en detalle, o cuando las personas desarrolladoras tienen dudas considerables
sobre determinados aspectos importantes del desarrollo, como la eficiencia de un algo-
ritmo, en qué medida la aplicación se podrá usar en un determinado sistema operativo o
de qué forma se ha de llevar a cabo la interacción hombre-máquina. Se puede conside-
rar este modelo de ciclo de vida de manera aislada, pero es más común emplearlo como
una técnica que puede implementarse en el contexto de cualquiera de los modelos de ci-
clo de vida descritos en este tema.
Hay que tener en cuenta que el objetivo fundamental a la hora de desarrollar el prototipo
es que las y los desarrolladores sepan exactamente lo que tiene que hacer la aplicación.
En la Figura 1.14, se presenta la secuencia de tareas que se llevan a cabo según este
modelo. Se comienza con una actividad de comunicación con el cliente con el fin de defi-
nir los objetivos generales del software y detectar las áreas en las que es necesaria una
mayor definición. Luego se planifica una iteración para desarrollar el prototipo y se lleva
a cabo el modelado (diseño rápido). Seguidamente, se construye el prototipo, que se en-
trega y es evaluado por los participantes, quienes proporcionan retroalimentación a las
personas desarrolladoras con el fin de mejorar la respuesta a los requerimientos. La ite-
ración ocurre a medida que el prototipo es refinado para satisfacer las necesidades de
distintos participantes y, al mismo tiempo, le permite a las y los desarrolladores entender
mejor lo que se necesita hacer.
En este modelo, se construye el software a partir de versiones cada vez más completas,
de manera que se realizan una serie de tareas varias veces. En la primera iteración, se
llevan a cabo las tareas de la Figura 1.14 (planificación, modelado, construcción, desplie-
gue, evaluación y comunicación) para construir una primera versión del prototipo. La rea-
lización de todas estas actividades constituye una iteración, luego se vuelven a realizar
1. DESARROLLO DE SOFTWARE |NFORMÁT|CA Y COM W |
estas mismas tareas en la segunda iteración para obtener una segunda versión del pro-
totipo más completa, y así sucesivamente.
Hay que tener en cuenta que algunos prototipos son desechables, mientras que otros
son evolutivos, es decir, se transforman poco a poco hasta convertirse en el sistema real.
Figura 1.14. Actividades del modelado de construcción de prototipos.
M ENE Modelo en espiral

Este modelo evolutivo fue diseñado para cubrir las mejores características tanto del mo-
delo en cascada como del modelo de construcción de prototipos, añadiendo un nuevo
elemento, que es el análisis de riesgo, dentro de la actividad estructural de planificación.
Como modelo de desarrollo evolutivo que es, el software se desarrolla en una serie de
entregas que se pueden representar como iteraciones o vueltas alrededor de una espiral.
Durante las primeras iteraciones lo que se entrega puede ser un modelo o prototipo. En
las iteraciones posteriores se producen versiones cada vez más completas del software.
Se muestra una representación de este modelo en la Figura 1.15.
PLANIFICACIÓN ANÁLISIS DE RIESGO

EVALUACIÓN INGENIERÍA
Figura 1.15. Representación del modelo en espiral, indicando las actividades

que se llevan a cabo en cada cuadrante.
jÍ¡'/kx Y COMUNICACIONES 1. DESARROLLO DE SOFTWARE
Se describe a continuación el cometido de las tareas que se llevan a cabo en cada ciclo
alrededor de la espiral:
E Planificación: se identifican los objetivos que se desean conseguir mediante la ite-

ración, asf como las alternativas para la consecución de dichos objetivos y las res-
tricciones impuestas en cuanto a plazos, costes, etc.
E Análisis de riesgo: consiste en evaluar las diferentes alternativas para la realización

de la parte del desarrollo elegida, seleccionando la más ventajosa y tomando pre-
cauciones para evitar los inconvenientes o riesgos previstos.
E Ingeniería: se desarrolla el producto (análisis, diseño, programación, etc.). El objeti-

vo es ir obteniendo en cada ciclo una versión más completa del sistema.
E Evaluación: el resultado del trabajo de ingeniería es evaluado por el cliente y se de-

cide si se continúa, para lo que se procede a planificar la siguiente iteración.
La principal ventaja de este modelo es que la consideración de los riesgos o problemas

que pueden afectar al desarrollo del software en diferentes momentos permite que tan-
to quienes encargaron el software como los que lo desarrollan sean conscientes de los
problemas que pueden presentarse y sean capaces de reaccionar en caso de que estos
ocurran. Además, si hay cierta inseguridad en cuanto a sus requisitos, se puede aplicar
el enfoque de construcción de prototipos para eliminar ese riesgo.
El principal inconveniente de este modelo es, como indica Pressman (2010), que
«requiere mucha experiencia en la evaluación del riesgo y se basa en ella para llegar al
éxito. No hay duda de que habrá problemas si algún riesgo importante no se descubre y
administra».
Recuerda
Los dos modelos de proceso evolutivo que se han presentado (construcción de prototipo
modelo en espiral) tienen dos características principales en común:
E Laconsideración del proceso de desarrollo de software como un proceso incremental en

el que se van obteniendo versiones del software cada vez más completas hasta llegar al
producto final.
La combinación del modelo evolutivo correspondiente con el modelo en cascada, que

en lugar de aplicarse sobre todo el software, se aplica sobre incrementos de software o
versiones de la aplicación cada vez más completas. De esta manera, se saca provecho
de las mejores características de varios modelos de ciclo de vida.
Actividad resuelta 1.1

1. DESARROLLO DE SOFTWARE INFORMÁT¡CA Y (Cr
Solución
Cuando se sigue el modelo en espiral, al tratarse de un modelo de proceso evolutivo, se va

construyendo el software sobre la base de incrementos o versiones del software cada vez
más completas. El conjunto de tareas por medio de las cuales se construye cada uno de
dichos incrementos recibe el nombre de iteración. En cada iteración en el cuadrante de in-
geniería, se llevan a cabo las tareas propias del modelo en cascada antes de la entrega de
la aplicación (análisis, diseño, programación y pruebas). Por tanto, se aplica el modelo en
cascada, pero no sobre el producto final, sino sobre incrementos de software cada vez más
completos o versiones de la aplicación que incorporan progresivamente más funcionalidad.
Una vez que se ha creado cada uno de estos incrementos, se muestra al cliente, quien lo
evalúa, y se pasa a la siguiente iteración, hasta que, como consecuencia de la última itera-
ción, se entrega el software completo y se procede a su implantación final en las instalacio-
nes del cliente (explotación).

El modelo en espiral y el modelo de construcción de prototipos
Explica detalladamente de qué forma se combinan y complementan el modelo en
espiral y el modelo de construcción de prototipos.
MN 1.9. Metodologías de desarrollo de software

Maddison (1983) propone la siguiente definición para el concepto de metodología: «un
conjunto de filosofías, fases, procedimientos, reglas, técnicas, herramientas, documenta-
ción y aspectos de formación para los desarrolladores de sistemas de información». Una
metodología puede seguir uno o varios modelos de ciclo de vida, esto es, el ciclo de vida
indica qué es lo que hay obtener a lo largo del desarrollo del proyecto, pero no cómo, que
es lo que indicará la metodología. Por tanto, el ciclo de vida es el modelo general que
se sigue para el desarrollo de software, mientras que una metodología establece las ta-
reas concretas que hay que llevar a cabo, cómo se debe llevar a cabo cada tarea, con qué
herramientas, etcétera.
Es necesario detenerse aquí y aclarar primero los conceptos de procedimiento, técnica y

herramienta que aparecen en la definición anterior de metodología,junto con los concep-
tos de tarea, producto intermedio y producto final:
1. El proceso de desarrollo de software, para que sea manejable, ha de dividirse en

una serie de fases en las que se deben llevar a cabo una serie de tareas.
2. Para llevar a cabo cada tarea, se debe seguir un determinado procedimiento y,

como consecuencia de su realización, se obtienen uno o varios productos, los cua-
les pueden ser intermedios, si se usan como base para la realización de alguna
tarea posterior, o finales, en caso de que se entreguen al cliente al final del proce-
so de desarrollo.
' J/VÁUN'CACIONES 1. DESARROLLO DE SOFTWARE
3. Para aplicar cada procedimiento, se deben utilizar uno o varios métodos o técni-
cas, en las que se crean diagramas gráficos con apoyos textuales. Además, para
aplicar cada método se puede disponer de la ayuda de alguna herramienta que
automatice en mayor o menor medida la aplicación de dicho método. Un mismo
método se puede usar varias veces en una misma metodología y también se pue-
de utilizar en diferentes metodologías.
Las herramientas que permiten automatizar las tareas de desarrollo de software reciben
el nombre de herramientas CASE (del inglés, computer-aided software engineering).
De las definiciones de método y metodología, se puede deducir pues que una metodolo-
gía incluye un conjunto de métodos para realizar cada una de las tareas necesarias para
el desarrollo de software.
Las metodologías de desarrollo de software han ido evolucionando a lo largo del tiempo.
Así, se identifican tres periodos de tiempo:
1. Desarrollo convencional: durante los primeros años del desarrollo de software las
prácticas de desarrollo eran totalmente artesanales y no se seguía ninguna meto-
dología, lo que acarreaba multitud de problemas y desembocó en lo que se llamó la
crisis del software.
2. Metodologías estructuradas: la primera respuesta a esta crisis fue la regulación de

la tarea de programación con la difusión de la programación estructurada, a la que
siguió el surgimiento de métodos para el diseño y análisis estructurado, dando lu-
gar a las metodologías estructuradas, que abarcan la totalidad del ciclo de vida del
software.
3. Metodologías orientadas a objetos: en la década de los 80 del siglo pasado surgie-

ron, en primer lugar, los lenguajes orientados a objetos y más tarde, métodos para
el diseño y análisis orientados a objetos.
El paradigma orientado a objetos supuso un cambio de filosofía en relación con la mane-

ra de desarrollar software que se había empleado hasta entonces, la cual se basaba en
la metodología estructurada.
Como se recordará por lo indicado en el Apartado 1.2, en la metodología estructura-

da, las aplicaciones se conciben como programas compuestos por diversos componen-
tes de software llamados módulos entre los que se realizan llamadas. Sin embargo, en
la metodología orientada a objetos, la atención se centra más que en los procesos, en
los datos sobre los que hay que operar. Una aplicación consta de varios objetos, cada
uno de los cuales tiene un estado (definido por un conjunto de atributos) y un comporta-
miento (definido por una serie de operaciones o métodos que ejecuta al recibir un men-
saje de otro objeto).
En la actualidad, la metodología que está sirviendo como referencia es el denominado

proceso unificado de desarrollo de software de Rational Software Corporation, que está
avalado por Ivar Jacobson, Grady Booch y James Rumbaugh, autores del lenguaje unifica-
do de modelado (UML, por sus siglas en inglés, unified modeling language). En el Aparta-
do 1.9.1, se estudia a fondo esta metodología.
1. DESARROLLO DE SOFTWARE |NFORMATICA Y ( N
Argot técnico
El lenguaje UML es muy conocido y, aunque en su nombre se incluye el vocablo /enguaje,
este lenguaje es un tanto especial en el sentido de que se trata de un lenguaje gráfico que
establece un conjunto de normas que permiten visualizar, construir, especificar y documentar
un sistema. Siguiendo estas normas, se pueden dibujar distintos tipos de diagramas que
representan diferentes aspectos de un sistema siguiendo el paradigma orientado a objetos.
Así, en la Unidad 5, se estudian las normas de UML para el dibujo de diagramas de clases
y, en la Unidad 6, se explica cómo dibujar los diferentes tipos de diagramas que reflejan el
comportamiento de un sistema, como los diagramas de casos de uso y los diagramas de
interacción.
Recientemente, se han desarrollado metodologías de desarrollo novedosas conocidas

como modelos de desarrollo ágil, que intentan simplificar las metodologías existentes,
buscando un equilibrio entre seguir un proceso de desarrollo que sea excesivo o «muy
burocrático» y su inexistencia. Estas metodologías se analizan en el Apartado 1.9.2.
ME 1.9.1.El proceso unificado de Rational (RUP)

El proceso RUP (Kruchten, 2000) se puede describir en función de dos dimensiones:
E Dimensión temporal: se expresa en términos de ciclos, fases, iteraciones e hitos.
E Dimensión estática: se expresa en términos de actividades (activities), produc-

tos intermedios (artifacts), perfiles de trabajo o roles (workers) y flujos de trabajo
(workflow).
Atendiendo a la dimensión temporal, el ciclo de vida se divide en ciclos entendiendo es-

tos como vueltas alrededor de una espiral, y estas, a su vez, como los periodos de tiem-
po en los que se trabaja sobre una versión completa del sistema. Cada ciclo se compone
de cuatro fases que se realizan secuencialmente:
M Fase de comienzo (inception): el objetivo de esta fase es estudiar la viabilidad del

sistema. Para ello, se establece el objetivo del sistema y se delimita su alcance,
definiendo, además, las estimaciones de recursos y un plan de tiempos general en
el que se establecen los hitos principales, las previsiones financieras, los riesgos
del proyecto y los criterios para su éxito. Al finalizar esta fase, se decide si se con-
tinúa o no con el proyecto.
E Fase de elaboración (elaboration): los objetivos de esta fase son analizar el dominio
del problema, establecer una base de la arquitectura software, desarrollar el plan del
proyecto y eliminar los riesgos más importantes. En esta fase se debe disponer de
un prototipo validado de la arquitectura software a partir del cual se puede desarro-
llar el sistema.
' JMUN'CACIONES 1. DESARROLLO DE SOFTWARE
E Fase de construcción (construction): durante esta fase se desarrolla el sistema de

forma iterativa e incremental hasta que esté preparado para su puesta en funcio-
namiento. Para cada iteración, se seleccionan algunos casos de uso (requisitos),
se refina su análisis y diseño y se procede a su implementación y pruebas. Se rea-
lizan tantas iteraciones como sean necesarias hasta que termine la implementa-
ción del producto. Como resultado de esta fase, se obtiene el sistema integrado
en las plataformas adecuadas, los manuales de usuario y una descripción de la
versión actual.
E Fase de transición (transition): el propósito de esta fase es poner en funcionamiento

el sistema y ponerlo a disposición de los usuarios. En esta fase, suelen surgir nue-
vas cuestiones que requieren un desarrollo adicional para refinar y ajustar el siste-
ma, corregir problemas o finalizar aspectos que puedan haber sido aplazados. Esta
fase comienza con una versión beta del sistema, que se reemplaza finalmente con
el sistema en producción.
Al término de cada una de estas fases, se define un hito principal, esto es, un punto en
el tiempo en el que se deben haber conseguido unos objetivos determinados. Cuando
llega este momento, la dirección del proyecto tiene que decidir si el trabajo puede conti-
nuar con la siguiente fase.
Cada una de las fases de RUP puede descomponerse en iteraciones. Una iteración es un
periodo de tiempo en el que se realiza un conjunto completo de actividades de desarro-
llo. El sistema, por lo tanto, se va desarrollando incrementalmente de iteración en itera-
ción. Una nueva iteración produce una nueva versión que proporciona al software mayor
funcionalidad y es más refinada.
Atendiendo a la dimensión estática, el proceso RUP describe los perfiles o papeles de tra-
bajo (quién) que realizan productos intermedios (qué) como resultado de realizar un con-
junto de actividades (cómo) por medio de un flujo de trabajo predefinido (cuándo). De esta
forma, el RUP establece cuatro elementos de modelado principales:
E Perfiles o papeles de trabajo (workers): mediante el papel o rol de trabajo se defi-

ne el comportamiento y la responsabilidad de una persona o un grupo de personas
que trabajan como una unidad y en equipo. Un individuo puede tener diversos roles
y un rol lo pueden llevar a término varios individuos. Ejemplos de perfiles son la jefa
o el jefe de un proyecto, las y los diseñadores de pruebas, los programadores y pro-
gramadoras, etcétera.
E Actividad (activity): es una unidad de trabajo que lleva a cabo un individuo con un
rol determinado. Por ejemplo, para el papel del jefe o jefa de proyecto, una actividad
podría ser planificar una iteración. Otras actividades podrían ser: llevar a cabo prue-
bas, codificar una clase, detallar un caso de uso, etcétera.
E Producto intermedio (artifact): son elementos de información producidos, modificados

o usados para el desarrollo del software. Son la entrada y la salida de las actividades
y la responsabilidad de los perfiles o roles. A modo de ilustración, algunos produc-
tos intermedios podrían ser: un modelo de casos de uso, documentos, código fuente,
ejecutables, etcétera.
E Flujos de trabajo (workflows): son secuencias de actividades para producir produc-

tos intermedios. RUP define nueve flujos de trabajo agrupados en dos clases prin-
cipales:
— FLuJOs DE INGENIERÍA (actividades secuenciales):
1: Modelado del negocio (business modelling): el objetivo es entender el conjun-

to de procesos de negocio que aparecen dentro de la empresa como un paso
previo a la recogida de requisitos del sistema que se debe desarrollar. En
esta fase, se obtiene un modelo de casos de uso del negocio, que describe
los procesos de negocio en términos de casos de uso y actores, y un modelo
de objetos del negocio, que describe cómo cada caso de uso del negocio se
lleva a cabo por el conjunto de trabajadores del negocio.
. Requisitos (requirements): el propósito es establecer los requisitos funcio-

nales (qué debe hacer el sistema) mediante casos de uso y los requisitos
no funcionales (rendimiento, restricciones, facilidad de mantenimiento, fia-
bilidad, etc.).
. Análisis y diseño (analysis 8: design): en esta fase se analizan los requisitos

capturados anteriormente con el objeto de tener una comprensión y descrip-
ción más precisa de los mismos, se refinan y se estructuran. El diseño produ-
ce un modelo físico del sistema que se debe construir (modelo de diseño) y
que no es genérico (específico para una implementación). Este debe ser más
detallado que el de análisis y debe ser mantenido durante todo el ciclo de
vida del software.
Implementación (implementation): consiste en programar o implementar el

sistema en términos de componentes, es decir, ficheros de código fuente,
ejecutables, etcétera.
. Pruebas (test): incluye crear casos de prueba (especificando qué probar y

cómo realizar la prueba), realizar las pruebas y evaluar sus resultados.
. Implantación (deployment): el objetivo es asegurarse de que el producto está

preparado para ser suministrado al cliente, ajustar el producto de software a
las necesidades del usuario y organizar su entrega y la recepción por parte
del usuario.
— FLujos DE APoYo (actividades de gestión paralelas):
7. Gestión de la configuración: control de cambios sobre los productos inter-

medios.
. Gestión de proyecto: planificación del proyecto, gestión de los riesgos y mo-

nitorización del progreso del proyecto.
. Entorno: cubre la infraestructura necesaria para desarrollar un sistema.

! 'Í' 1OMUN|CA(:IONES 1. DESARROLLO DE SOFTWARE
PROCESO UNIFICADO DE RATIONAL

Comienzo Elaboración Construcción Transición
[l 12 El E2 C1 C2 C3 C4 T1 T2
Modelado del negocio
Requisitos
Análisis y diseño —
Implementación A
Prueba _—
Implantación _.
Figura 1.16. Ejemplo de evolución de un proyecto de desarrollo empleando la metodología RUP. Se puede
observar cómo en las diferentes fases (comienzo, elaboración, construcción y transición) se van realizando
tareas correspondientes a los distintos flujos de ingeniería (modelado del negocio, requisitos, análisis y diseño,
implementación, pruebas e implantación), así como el volumen de trabajo que supone cada uno de estos flujos
de ingeniería en cada una de las iteraciones.
ME 1.9.2.Modelos de desarrollo ágil

En 2001, un grupo de desarrolladores encabezados por Kent Beck, grupo conocido como
Alianza Ágil, firmaron el Manifiesto por el desarrollo ágil de software, en el que se estable-
ce lo siguiente (véase https://agilemanifesto.org/):
Estamos descubriendo formas mejores de desarrollar software, haciéndolo y ayudando a

otros para que lo hagan. Este trabajo nos ha hecho valorar:
E Los individuos y sus interacciones, más que los procesos y las herramientas.
E El software que funciona, más que la documentación exhaustiva.
E La colaboración con el cliente, y no tanto la negociación del contrato.
E Responder al cambio, mejor que apegarse a un plan.
Es decir, si bien son valiosos los conceptos que aparecen en segundo lugar, valoramos más
los que aparecen en primer lugar.
En el desarrollo ágil, se pone el énfasis en la entrega al cliente, cada poco tiempo, de

software que funcione, más que en el rigor en la ingeniería del software y en los produc-
tos intermedios. Uno de los objetivos es la entrega rápida de software incremental y para
ello se prefiere formar equipos pequeños y bien motivados.
Una de las principales ventajas del desarrollo ágil es su mayor facilidad para incorpo-
rar los cambios a lo largo del desarrollo y el menor coste que estos cambios conllevan.
Como sabemos, cuanto más tarde en el proceso de desarrollo se detecta la necesidad
de realizar un cambio, más costoso es incorporarlo. También resultará más costoso si
1. DESARROLLO DE SOFTWARE INFORMÁTICA Y G3¡M
este cambio afecta a etapas iniciales (análisis o diseño). Gracias a la entrega incremen-
tal propia del desarrollo ágil y a otras prácticas propias de esta metodología, como las
pruebas unitarias continuas y la programación por parejas, se consigue reducir el coste
de los cambios. Esto también es posible gracias a las entregas cada poco tiempo y a la
retroalimentación del cliente en cada entrega.
CICLO DE VIDA EN CASCADA VS. MODELO DE DESARROLLO INCREMENTAL
<
Q
<
O)
))
<
O) DESARROLLO
z
u
PRUEBAS
REVISIÓN
— E-
Figura 1.17. La agilidad, propia del modelo de desarrollo incremental, frente al modelo en cascada. En este
modelo, se llevan a cabo las mismas tareas que en el modelo en cascada, pero se aplican sobre entregas
pequeñas o incrementos de software.
La Alianza Ágil ha establecido doce principios de agilidad (véase https://agilemanifesto.org/),

que son los siguientes:
1. La máxima prioridad es satisfacer al cliente a través de la entrega rápida y continua

de software valioso.
. Los requisitos cambiantes son bienvenidos, aun en etapas avanzadas del desarro-
llo, pues, cuando hay cambios, los procesos ágiles son beneficiosos para la ventaja
competitiva del cliente.
. Se realizan entregas frecuentes y lo más pronto que se pueda de software que fun-
cione, preferiblemente entre dos semanas y un par de meses.
. Las personas responsables del negocio y las encargadas del desarrollo del software
trabajan conjuntamente, a diario y durante todo el proyecto.
. Los proyectos son desarrollados por individuos motivados. Debe proporcionarse a

estos el entorno y el apoyo adecuados, y confiar en que harán el trabajo.
. El método más eficiente y eficaz para comunicar información al equipo de desarrollo

y entre sus miembros es la conversación cara a cara.
. La principal medida para progresar es un software que funcione.
. Los procesos ágiles impulsan el desarrollo sostenible. Los promotores, las perso-
nas que desarrollan el software y las usuarias de este deben ser capaces de mante-
ner un ritmo constante de forma indefinida.
a 1Z_OMUNICACIONES 1. DESARROLLO DE SOFTWARE
9. La atención continua a la excelencia técnica y al buen diseño mejoran la agilidad.
10. Es esencial la simplicidad: el arte de maximizar la cantidad de trabajo no realizado.
11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos con organiza-
ción propia.
12. El equipo reflexiona con regularidad sobre cómo ser más eficaz, para después per-
feccionar y ajustar su comportamiento en consecuencia.
No es necesario que todas las metodologías ágiles apliquen estos doce principios con
la misma intensidad, pero estos principios sí que definen la filosofía del desarrollo ágil.
CICLO DE VIDA INCREMENTAL
Figura 1.18. Cada uno de los incrementos de software se obtiene mediante una iteración, que en los modelos
ágiles suele recibir el nombre de sprint. En este caso, se desarrolla el software en tres sprints.
Seguidamente, se presentan dos modelos concretos de desarrollo ágil:
M ENEN Programación extrema (XP)

La programación extrema (XP) fue formulada por Kent Beck y es el más destacado de los
métodos de desarrollo ágil.
Los cinco valores originales de la programación extrema son la simplicidad, la comuni-

cación, la retroalimentación, la valentía y el respeto. A continuación, se describen breve-
mente cada uno de ellos:
E Simplicidad: se debe simplificar el diseño para agilizar el desarrollo y facilitar el

mantenimiento. Solo se diseña de forma inmediata lo necesario. Si se tuviera que
mejorar el diseño, siempre se puede rediseñar o realizar una refactorización con
posterioridad.
E Comunicación: debe establecerse una comunicación cercana pero informal con el

cliente; debe existir una retroalimentación continua y se deben evitar los documen-
tos voluminosos como medio de comunicación.
E Retroalimentación: al realizar incrementos de software en cortos intervalos de tiempo,

los cuales son mostrados al cliente una vez terminados, se obtiene una retroalimenta-
ción continua y frecuente, lo que evita tener que rehacer partes importantes del traba-
jo. Las pruebas son una fuente esencial de la retroalimentación.
1. DESARROLLO DE SOFTWARE |NFORMATÍCA / KF
E Valentía: cumplir con las prácticas de la programación extrema requiere valentía.

Por ejemplo, no se debe diseñar pensando en requisitos futuros, aunque llevar esto
a la práctica es difícil, pues la mayoría de los equipos de desarrollo de software
suelen recibir presión para que tengan en cuenta también los requerimientos fu-
turos.
E Respeto: el cumplimiento de los cuatro principios anteriores conlleva respeto entre

los miembros del equipo de desarrollo y entre estos y las demás personas que par-
ticipan en el proyecto. Así, las personas responsables de la programación no pue-
den realizar cambios que hagan que las pruebas existentes fallen o que retrasen el
trabajo de sus compañeras y compañeros.
La programación extrema usa el enfoque orientado a objetos como paradigma de desa-

rrollo preferido.
Por otro lado, en la estructuración del proceso de desarrollo de software, se llevan a

cabo las siguientes cuatro actividades estructurales: planificación, diseño, codificación y
pruebas:
E Planificación: tras escuchar al cliente, se crean las llamadas historias de usuario, si-
milares a los casos de uso, que son escritas por el cliente; se colocan entonces en
una tarjeta y el cliente les asigna una prioridad. Posteriormente, el equipo XP asig-
na a cada historia un coste (semanas de desarrollo). El tiempo máximo de una his-
toria es de tres semanas; en caso de que sea más larga, se le pide al cliente que
la descomponga en historias más pequeñas y, de nuevo, se le asigna una prioridad
y un coste. En cualquier momento, se pueden escribir nuevas historias. El cliente y
las personas que se encargan del desarrollo deciden conjuntamente qué historias
incluir en el siguiente incremento de software, así como su fecha de entrega y de-
más aspectos relevantes.
E Diseño: la XP contribuye al diseño sencillo. Cuando hay dificultades en el diseño, se

suele crear un prototipo que permita disminuir el riesgo. La XP fomenta también el
rediseño o refactorización, que consiste en reescribir ciertas partes del código para
aumentar su legibilidad y mantenibilidad, pero sin modificar su comportamiento. Se
deben realizar pruebas para garantizar que al refactorizar no se hayan introducido
errores.
E Codificación: antes de la codificación, se diseñan pruebas unitarias para cada una

de las historias. Una vez creado el código, se aplica la prueba unitaria creada para
proporcionar retroalimentación a las personas que lo han desarrollado. Un concep-
to clave de la codificación es la programación por parejas, en la que cada persona
juega un rol distinto: por ejemplo, uno se centra en los detalles del código y el otro
se encarga de asegurarse de que se siguen las pautas de codificación y de que el
código superará con éxito la prueba unitaria. A medida que las parejas de progra-
madores terminan su trabajo, el código que desarrollan se integra con el trabajo de

los demás.
E Pruebas: además de las pruebas unitarias que se hacen una vez creado el códi-
go, también se realizan continuamente pruebas de integración y validación, lo que
] MUNICACIONES
1. DESARROLLO DE SOFTWARE
revela al equipo XP los avances obtenidos de forma continua y permite lanzar seña-
les de alerta en caso de que haya problemas importantes. Finalmente, se llevan a
cabo las pruebas de aceptación, que son especificadas por el cliente.
EE Scrum
Scrum es un modelo de desarrollo ágil concebido por Jeff Sutherland y su equipo de
desarrollo en la década de los 90 y que luego fue desarrollado por Schwaber y Beedie.
Este modelo de desarrollo ágil tiene como objetivo la entrega de valor (productos) al
cliente en cortos periodos de tiempo y se basa en tres pilares: transparencia, inspec-
ción y adaptación:
E Transparencia: todas las personas involucradas en el proyecto conocen en todo

momento qué ocurre y cómo, lo que permite que haya una visión global del pro-
yecto.
E Inspección: todos los miembros del equipo inspeccionan de manera autoorgani-

zada el progreso del proyecto para detectar posibles problemas.
E Adaptación: cuando es necesario realizar algún cambio en el proyecto, el equipo

se adapta para conseguir el objetivo.
En esta metodología, se consideran las siguientes actividades estructurales: requeri-

mientos, análisis, diseño, evolución y entrega. Cada actividad estructural se divide en
una serie de sprints. Un sprint abarca el periodo de tiempo que se emplea para reali-
zar el trabajo necesario para entregar valor al cliente. La duración máxima de un sprint
es de un mes, aunque es aconsejable que sea inferior (unas dos semanas). La dura-
ción se determina en función del nivel de comunicación que el cliente desea tener con
el equipo de desarrollo.
Antes de iniciarse un sprint, tiene lugar una reunión llamada sprint planning, en la que
todo el equipo establece qué tareas se van a realizar en el sprint, cuál es su objetivo y
cómo se van a llevar a cabo las tareas. Al final del sprint, se hace una entrega de valor
al cliente. Se organizan reuniones diarias dentro de cada sprint con una duración máxi-
ma de 15 minutos. En las reuniones, se responde a las siguientes preguntas: ¿qué
hicimos ayer?, ¿qué vamos a hacer hoy? Y ¿tenemos algún problema que hay que so-
lucionar?
Una vez ha concluido el sprint, se entrega y presenta el producto al cliente (sprint review).
El equipo de desarrollo muestra el funcionamiento del producto al cliente, quien tendrá
que validarlo. Además, durante esta reunión, el cliente proporciona retroalimentación
útil para nuevas tareas.
Tras el sprint review, se efectúa una retrospectiva del sprint, en la que se hace una eva-
luación del trabajo realizado durante el sprint, proponiendo mejoras para el siguiente
sprint. Finalizada esta reunión, se comienza el siguiente sprint, que incluirá las cua-
tro tareas que se han indicado: planificación, reuniones diarias, sprint review y retros-
pectiva.
1. DESARROLLO DE SOFTWARE |NFORMÁT'CA Y CO/N 1
4 METODOLOGÍA SCRUM
EOta % D
Dueño del Maestro Scrum
producto
Equipo de
desarrollo
Desarrollo del proyecto Desarrollo del sprint Incremento
Figura 1.19. En la metodología Scrum todo el trabajo que hay que realizar para el desarrollo del proyecto
(product backlog) se divide en una serie de sprints. A partir de la planificación del sprint, se crea una lista
de tareas (sprint backlog) que irá realizando el equipo asignado (Scrum team). Cada día de trabajo, se lleva
a cabo una reunión para analizar la marcha del sprint (Scrum meeting) y, al finalizar el sprint, se realiza una
presentación al cliente (sprint review) del producto obtenido hasta el momento (incremento, en inglés
“product increment”).
Actividad resuelta
Solución
Las características diferenciales de mayor relevancia de los modelos de desarrollo ágil fren-
te a otras metodologías son:
E Se sigue un proceso de desarrollo menos burocrático, en el que se da más relevan-

cia al software que funcione y menos importancia a la documentación.
E Se considera fundamental la colaboración con el cliente y su implicación constante a

lo largo de todo el proceso de desarrollo.
E Se hacen cada poco tiempo entregas de software que funciona al cliente, con el fin de
que este lo pueda evaluar y proporcionar así una retroalimentación gracias a la cual
se puedan solventar errores o problemas lo antes posible.
E Gracias a las dos características indicadas anteriormente, es más sencilla la incorpo-

ración de cambios al software.
E El equipo reflexiona frecuentemente sobre el proceso de desarrollo con vistas a me-

jorar su funcionamiento.
El software y su relación con
otras partes del ordenador
Lenguajes de programación.
Tipos
Código fuente, código

objeto y código ejecutable.
Herramientas implicadas
Máquinas virtuales
Desarrollo de software
La ingeniería del software |
Fases del desarrollo de una ——J

aplicación informática
Roles que intervienen

en el proceso de desarrollo I
de software
Modelos de ciclo de vida

del software
Metodologías de desarrollo
de software
E Actividades de comprobación
1 La parte del hardware del ordenador que permite la comunicación de este con el
exterior, haciendo posible la conexión del ordenador con los periféricos, recibe el
nombre de:
a) Memoria RAM.
b) CPU.
c) ALU.
d) Unidad de entrada/salida.
1:2: ¿A qué tipo de software pertenece un sistema operativo?

a) Software de aplicación.
b) Software de programación.
c) Software de sistemas.
d) Software de desarrollo.
1.3. Los únicos lenguajes que es capaz de entender directamente un ordenador son:
a) Los lenguajes de alto nivel.
b) Los lenguajes ensambladores.
C) Los lenguajes evolucionados.
d) Los lenguajes máquina.
1.4. El código de un programa formado por un conjunto de instrucciones escritas si-

guiendo las normas de un lenguaje de programación de alto nivel recibe el nombre
de:
a) Código objeto.
b) Código fuente.
c) Código enlazable.
d) Código ejecutable.
1.5. La herramienta informática que permite convertir el código fuente de un programa

en código objeto recibe el nombre de:
a) Editor de textos.
b) Depurador.
c) Enlazador.
d) Compilador.
1.6. Tras compilar el código fuente de un programa en Java, se obtiene un fichero con
extensión .class. Para convertir este código bytecode en código ejecutable se re-
quiere la intervención:
a) Del compilador javac.
b) De la máquina virtual de Java.
c) De un depurador.
d) De un intérprete.
42
1. DESARROLLO DE SOFTWARE ACTIVIDADES FINALES
1.7. Lafase del ciclo de vida en la que se modifica el software tras haber sido este en-
tregado al cliente recibe el nombre de:
a) Pruebas.
b) Análisis.
c) Mantenimiento.
d) Diseño.
1.8. ¿A qué persona de las siguientes le corresponde la tarea de planificación del pro-
yecto de desarrollo de software?
a) Jefa o jefe de proyecto.
b) Analista.
c) Diseñador o diseñadora.
d) Arquitecto o arquitecta.
1.9. Lafase del modelo en espiral que diferencia a este modelo con respecto a otros es:
a) La planificación.
b) El análisis de riesgo.
c) La ingeniería.
d) La evaluación del cliente.
1.10. El mantenimiento consistente en modificar las aplicaciones añadiendo nuevas ne-

cesidades del usuario recibe el nombre de mantenimiento:
a) Preventivo.
b) Adaptativo.
c) Correctivo.
d) Perfectivo.
1.11. El modelado del negocio, los requisitos, el análisis y diseño, la implementación, las
pruebas y la implantación, ¿qué son en el ámbito de la metodología RUP?
a) Flujos de ingeniería.
b) Flujos de apoyo.
c) Productos intermedios.
d) Ninguna de las anteriores respuestas es correcta.
1.12. La programación por parejas es una práctica relevante de:

a) La metodología RUP.
b) La metodología Scrum.
c) La programación extrema.
d) El modelo en espiral.
E Actividades de aplicación
1.13. ¿Cuál es la función de la unidad central de proceso (CPU) de un ordenador?
1.14. ¿De qué tres tipos de lenguajes de programación se puede hablar en función de su cer-
canía al lenguaje que utiliza el ordenador o al lenguaje natural? ¿Qué tipo de lenguajes
de programación son los más empleados en la actualidad y por qué? 43
ACTIVIDADES FINALES 1. DESARROLLO DE SOFTWARE
1.15. ¿Cuáles son las diferencias más relevantes entre el paradigma estructurado y el paradig-
ma orientado a objetos?
1.16. ¿En qué consiste el código fuente de un programa?
ic ¿Para qué sirven los compiladores y los intérpretes? ¿En qué se diferencian?
1.18. ¿Qué dos tipos de máquinas virtuales existen y en qué se diferencian? ¿Qué tipo de má-
quina virtual es la máguina virtual de Java?
1ETO: ¿Cuál es el cometido de la máguina virtual de Java?
1.20. ¿Qué razón de ser tiene la existencia de la ingeniería del software?
VZA ¿Para qué sirve la fase de pruebas de una aplicación informática?
1.22. ¿Cuál es el modelo de ciclo de vida del software más antiguo? ¿Cómo se concibe el de-
sarrollo de software siguiendo este modelo?
1.23. ¿Cuándo resulta especialmente conveniente aplicar el modelo de construcción de proto-

tipos en el desarrollo de software?
1.24. ¿Cuál es la relación entre los conceptos método y metodología en el ámbito de la inge-
niería del software?
¿Qué es un producto intermedio en la metodología RUP?
¿Cómo se puede definir un sprint en la metodología Scrum?
Busca en internet información sobre la metodología Métrica. ¿Cuáles son los tres proce-
sos principales de desarrollo de software según Métrica?
Busca en la red información sobre la ingeniería inversa. ¿En qué consiste este proceso?
1.29. Busca en internet información sobre la reingeniería. ¿Qué comprende esta actividad?
1.30. Encuentra en la red cuáles son las características deseables de una metodología de de-
sarrollo de software. Enuméralas.
1.31. Busca en internet información sobre la reutilización de software. Explica este concepto e
indica por qué es importante fomentar la reutilización de software.
1.32. Con ayuda de internet, investiga sobre el modelo de desarrollo de software en V. ¿A qué
modelo de ciclo de vida se parece más? Describe este modelo.
44
1. DESARROLLO DE SOFTWARE ACTIVIDADES FINALES
Enlaces web de interés
(Enc¡cloped¡a l¡bre y colaborat¡va en internet)
Métrica v3 - https://administracionelectronica.gob.es/pae_Home/pae_Documentacion/
pae_Metodolog/pae_Metrica_v3.html
(Página web con información sobre la metodología Métrica v3 promovida por la Administra-
ción Pública española)
Tutorials point - https://www.tutorialspoint.com

(Portal web que ofrece tutoriales gratuitos y cursos sobre programación y otras tecnologías)
Rupmetodologia - http://rupmetodologia.blogspot.com/
(Blog sobre la metodología RUP)
AgileAlliance.org - https://www.agilealliance.org/
(Portal web creado por la ONG Agile Alliance que apoya a aquellos que exploran, aplican y
[m] expanden los valores, principios y práctica ágiles)
E (a) [m] Scrum.org - https://www.scrum.org/

= (Sitio web fundado por el cocreador de la metodología Scrum, Kent Schwaber, para ayudar a
aplicar profesionalmente Scrum por medio de cursos de formación, certificaciones y aprendi-
] zaje permanente)
45
UNIDAD 2
Comprender la utilidad de los entornos E 2.1. La utilidad de los entornos
de desarrollo integrados. de desarrollo integrados
Identificar los componentes de un entorno m 2.2. Componentes de un entorno
de desarrollo integrado. de desarrollo
Instalar entornos de desarrollo integrados m 2.3. Instalación de un entorno
para crear aplicaciones en Java. de desarrollo
Saber utilizar entornos de desarrollo integrados E 2.4. Edición de programas y
para la edición de programas y la generación generación de archivos
de archivos ejecutables. ejecutables
Instalar y desinstalar módulos (p/ug-ins) E 2.5. Instalación y desinstalación
en un entorno de desarrollo integrado. de módulos
Conocer los mecanismos de actualización N 2.6. Mecanismos de actualización
de un entorno de desarrollo integrado.
a
/ : …'1'.kV N
2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO INFORMATICA Y (r '
Introducción
En la Unidad 1 se explicó el proceso que es necesario llevar a cabo para transformar el
código fuente de un programa en código ejecutable. Ello conlleva el empleo de varias
herramientas: un editor, un compilador o intérprete, un depurador, etc. Hoy en día, en
lugar de emplear estas herramientas de forma aislada, se suelen integrar en una apli-
cación que recibe el nombre de entorno de desarrollo o entorno de desarrollo integrado
(integrated development environment), conocido también por sus siglas en inglés, IDE.
En este tema, se verán cuáles son los componentes de un IDE, se explicará la ins-
talación de dos entornos de desarrollo (Eclipse y Apache NetBeans) y cómo se pue-
den crear programas mediante ellos. Además, se ejemplificará la instalación de módulos
adicionales para realizar tareas que los citados entornos no llevan incorporadas, pero
que pueden resultar interesantes con el objeto de crear aplicaciones de un determina-
do tipo o llevar a cabo tareas que quedan fuera del ámbito estricto de la programación.
M 2.1.La utilidad de los entornos de desarrollo integrados

En la Unidad 1, se explicó el proceso de creación de programas ejecutables, que consta
de los siguientes pasos:
1. Creación del código fuente del programa siguiendo las normas sintácticas de un
determinado lenguaje de programación de alto nivel.
2. Transformación del código fuente en código objeto mediante el empleo de un tra-

ductor (compilador o intérprete). Si el traductor detecta errores de sintaxis, indica
el error o errores correspondientes y no se genera el código objeto.
3. Obtención del código ejecutable insertando en el código objeto una serie de ruti-
nas o librerías.
Para la realización de cada uno de estos pasos, se debe emplear una herramienta dife-
rente. Así, para la primera tarea se debe emplear un editor; para la segunda, un compila-
dor o un intérprete; y para la tercera, un enlazador.
El hecho de tener que emplear una herramienta independiente para cada una de estas
tareas, cuando estas siempre se tienen que realizar en secuencia para la creación de un
programa, es tedioso. Por este motivo, se crearon los llamados entornos de desarrollo
integrados. Estos se pueden definir como una aplicación informática compuesta por un
conjunto de herramientas integradas que facilitan el desarrollo de software. Estas herra-
mientas también se conocen como entornos de desarrollo.
Argot técnico
La forma más habitual de referirse a los entornos de desarrollo o entornos de desarrollo
integrados es empleando sus siglas en inglés IDE (Integrated Development Environment).
C)MUNICACIONES 2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO
Aunque por la definición propuesta, se puede entender que un IDE asiste a la persona
usuaria en todas las tareas de desarrollo de software (análisis, diseño, programación,
pruebas y mantenimiento), lo cierto es que las actividades que mejor apoyo reciben por
la mayoría de los entornos de desarrollo son la programación y las pruebas, por lo que
en algunos casos se suele hablar de entornos de programación. La mayor parte de los
IDE, además de permitir la edición de programas y su ejecución, tras la traducción corres-
pondiente, permiten llevar a cabo las siguientes tareas:
E Ejecutar en modo depuración, para poder corregir los errores encontrados durante
las pruebas.
E Analizar la consistencia y calidad del código fuente.
E Ejecución automática de pruebas.
E Control de versiones.
E Generación de documentación.
E Optimización del código (refactorización).
Cabe mencionar aquí que hay IDE creados para su uso con un único lenguaje de progra-
mación, pero también existen entornos de desarrollo multilenguaje, es decir, que per-
miten crear y ejecutar programas escritos en varios lenguajes de programación de alto
nivel.
A continuación, se muestra la manera de crear un programa muy sencillo en Java y su

ejecución sin el empleo de ningún entorno de desarrollo, en otras palabras, de la mane-
ra tradicional.
Para crear y ejecutar programas en Java, independientemente de que se use o no un

IDE, es necesario instalar el equipo de desarrollo de Java, conocido de manera abrevia-
da como JDK (Java Development Kit), con el que viene incorporado; asimismo, el entor-
no en tiempo de ejecución de Java, más conocido como JRE (Java Runtime Environment):
E El JDK es un software que proporciona herramientas para la creación de programas

en Java, entre ellas un compilador llamado javac.
E El JRE está formado por un conjunto de utilidades que permiten la ejecución de pro-
gramas escritos en Java. Este entorno está formado por la máquina virtual de Java
(JVM), que se trató en la Unidad 1, un conjunto de bibliotecas Java y otros compo-
nentes necesarios para que una aplicación escrita en Java pueda ejecutarse.
El JDK y el JRE de Java se instalan conjuntamente. Para ello, se accede a la página web:
https://www.oracle.com/Java/technologies/Javase-downloads.HTMLHJavaseJDK. En
esta dirección es donde se accede a la última versión disponible en el momento de escri-
bir este libro, la 16.0.2. En esta página, en la sección correspondiente a la versión Java
SE Development Kit 16.0.2, se hace clic en la descarga correspondiente a nuestro siste-

ma operativo. En el caso de que se desee realizar la instalación en Windows, es posible
descargar un archivo comprimido, un instalador MSI (por sus siglas en inglés, Microsoft
installer, conocido ahora como Windows installer) o un instalador .exe. En este ejemplo,
se elige esta última opción.
a
MM
2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO INFORMATICA Y < JI
Una vez realizada la descarga, se comienza la instalación haciendo doble clic sobre el fi-
chero ejecutable descargado. La instalación no presenta ningún problema y se seleccio-
nan todas las opciones por defecto.
Cuando estén instalados el JDK y el JRE de Java, será posible crear programas en Java
sin el empleo de ningún IDE o mediante el empleo de uno como Eclipse.
Para la creación de un programa en Java sin el empleo de ningún IDE, lo primero que
se ha de hacer es escribir su código fuente mediante el empleo de un editor de tex-
tos, como el bloc de notas. En este, se escribe el siguiente código, por medio del cual
se crea un programa que lo único que hace es escribir en la pantalla el texto «¡Hola,
mundo!»:
public class HolaMundo(

H
public static void main (String[] args) f

System.out .printin (“¡Hola, mundo!”);
w
s
u
Archivo Edición fFormato Ver Ayuda

bublic class HolaMundof
public static void main (String[] args)f
System.out.println ("¡Hola, mundo!");
Figura 2.1. Código fuente de un programa que muestra un mensaje en la pantalla

y que ha sido creado en el bloc de notas.
Este programa se debe guardar con el nombre de la clase creada y extensión .java, por
lo que su nombre será: HolaMundo.java. Además, se guarda en la carpeta en la que está
instalado el JDK de Java, que es C:VProgram Files Java dk-16.0.2
Vbin. Según la configu-
ración de nuestro sistema y del usuario con el que se haya accedido, puede ser que no
sea posible almacenar el archivo en la carpeta indicada. En este caso, se debe ejecutar
el editor de textos como administrador.
El siguiente paso es la compilación del programa, para lo que se usa el compilador de

Java javac ubicado en la carpeta correspondiente al JDK. Con este fin, se abre el símbolo
del sistema y nos colocaremos en la carpeta del JDK. Una vez en esa carpeta, se escri-
be javac y, a continuación, el nombre del fichero fuente que se desea compilar, como se
muestra en la Figura 2.2. Puede ser necesario, también en este caso, ejecutar el símbolo
del sistema como administrador, si surge algún problema con los permisos. En la Figura
2.2, se pueden leer las instrucciones ejecutadas desde el símbolo del sistema.
i1 ' [OMUNICACIONES 2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO
Z
Anma
Argot técnico
El símbolo del sistema, también conocido por sus siglas en inglés CMD (command prompt),
es un intérprete de línea de comandos que incorpora Windows desde el que se pueden
dar órdenes al sistema por escrito empleando el teclado en lugar de utilizando una interfaz
gráfica. En una interfaz gráfica de usuario, también conocida como GUI (por sus siglas en
inglés, graphical user interface), se emplean tanto el teclado como el ratón para realizar
operaciones sobre elementos gráficos disponibles en la pantalla del ordenador. Así, las
interfaces más características de los sistemas operativos actuales son interfaces gráficas.
icrosoft Windows [Versión 6.3.96081

<c) 2013 Microsoft Corporation. Todos los derechos reservados.
:NWindowsNs ystem32>cd C:NProgram Files NJavaNjdk-16.0.2Nbin

:NProgram FilesNJavaNjdk-16.0.2Nbin>javac HolaMundo.java
:NProgram FilesNJavaNjdk-16.0.2Nbin>
Figura 2.2. Órdenes que hay que ejecutar en el símbolo del sistema para compilar
el archivo con el código fuente.
Si todo ha funcionado correctamente, no se mostrará ningún mensaje y se habrá crea-

do un archivo llamado HolaMundo.class en la carpeta donde está el archivo HolaMundo.
java. En caso de que haya habido algún problema, aparece el correspondiente mensaje
de error que se debe corregir. Una vez corregido, se vuelve a ejecutar la orden de compi-
lación del programa.
Tras compilar correctamente el programa, solo faltará ejecutarlo, para lo que, desde el
símbolo del sistema, se escribe java y, después, el nombre del fichero sin extensión, en
este caso, HolaMundo. Como se puede observar en la imagen de la Figura 2.3, el mensa-
je «¡Hola, mundo!» aparece en la pantalla.
:NProgram FilesNJavaNjdk-16.0.2Nbin>java HolaMundo

¿Hola,. mundo*
:NProgram FilesNJavaNjdk-16.0.2Nbin>
Figura 2.3. Orden para ejecutar el programa una vez que este ha sido compilado
exitosamente. Debajo de dicha orden se muestra el resultado de la ejecución.
En el Apartado 2.4 se verá que, con la ayuda de un IDE, estas tareas se pueden llevar a
cabo más rápida y eficientemente mediante herramientas diseñadas a tal efecto.
a
e
2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO INFORMATICA Y C
E 7.2.Componentes de un entorno de desarrollo

En este apartado, se ofrece una lista de los componentes que vienen incorporados en la
mayoría de los entornos de desarrollo, siendo los dos primeros los que forman parte de
todos ellos:
E Editor de textos: se emplea para la escritura del código fuente del programa. Inclu-
ye las funciones propias de cualquier editor de textos (copiar, cortar, pegar, buscar,
reemplazar, etc.) e incluye herramientas importantes para la escritura de los pro-
gramas. Así, marca en ciertos colores determinados elementos del lenguaje, como
palabras reservadas y variables, resalta el inicio y el fin de cada bloque, etc. Esto
contribuye a la legibilidad de los programas y es un apoyo relevante para las tareas
de escritura y revisión del código fuente.
E Compilador o intérprete: comprueba la corrección del programa escrito en lenguaje

fuente y, en caso de que sintácticamente sea correcto, genera el correspondiente
código objeto o directamente el código ejecutable. La diferencia entre los compi-
ladores y los intérpretes, como se indicó en la Unidad 1, es que los compiladores
traducen todo el programa fuente y almacenan el resultado, mientras que los intér-
pretes van traduciendo porciones de código y las van ejecutando, y no almacenan el
resultado de la traducción.
E Depurador (debugger): ayuda a quienes realizan la programación en la tarea de de-

puración, esto es, en la localización y corrección de errores en el programa. Para
ello, permite realizar tareas como la detención de la ejecución del programa en una
determinada instrucción mediante el establecimiento de puntos de ruptura, la eje-
cución del programa instrucción a instrucción, la visualización de los valores de las
variables a lo largo de la ejecución, etc. El depurador puede resultar muy útil para
detectar y corregir determinados errores que, sin esta herramienta, resultaría com-
plicado.
E Constructor de interfaz gráfica: permite crear aplicaciones con una interfaz gráfica
de usuario (GUI, por sus siglas en inglés, graphical user interface). Una GUI se crea
mediante la colocación de distintos controles en la pantalla, como botones, campos
de texto, listas o barras de menús, con los cuales interactúa el usuario mediante
el ratón o el teclado. La aplicación responde a las acciones (eventos) que realiza el
usuario sobre estos controles. La mayoría de los entornos de desarrollo requieren
la instalación de módulos adicionales para la creación de este tipo de aplicaciones.
E Control de versiones: controla los cambios que se realizan sobre los programas,
creando diferentes versiones de estos a medida que se van incorporando dichos
cambios.
P
Recuerda o
Todo entorno de desarrollo debe incluir obligatoriamente un editor de textos orientado al
lenguaje y un compilador o un intérprete. La mayoría de los entornos de desarrollo incorporan
también los otros componentes descritos en este apartado.
3MUNICACIONES 2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO
Existen, además, como herramientas independientes (no como entornos de desarrollo)

editores de textos, que permiten escribir código fuente. Con la mayor parte de estos, es
posible escribir en varios lenguajes de programación. Algunos ejemplos de editores de
este tipo son Notepadd++ y Sublime. La mayoría de estos editores de textos presentan
las mismas características que aquellos que van incorporados a los entornos de desarrollo
(resaltado de determinados elementos de los programas, señalamiento del comienzo y final
de los bloques, etc.), pero no permiten transformar el código fuente escrito en código objeto
ni ejecutable.
EN 2.3. Instalación de un entorno de desarrollo

En la actualidad, existen muchos entornos de desarrollo disponibles. En este libro, se ex-
plican dos entornos de desarrollo para poder crear programas en Java. En este sentido,
el hecho de que Oracle ponga a disposición de quienes desarrollan programas, de for-
ma gratuita, el JDK de Java y otras descargas ha permitido que surjan un buen número
de aplicaciones de apoyo, entre ellas, entornos de desarrollo como Eclipse, NetBeans,
JBuilder, JDeveloper, etc.
Para explicar cómo se instala un IDE, aquí se han elegido dos de esos entornos, que son
de código abierto y gratuitos, concretamente, Eclipse y NetBeans. El software de código
abierto es software cuyo código fuente es del dominio público y, por tanto, puede ser uti-
lizado, cambiado e incluso redistribuido. Sin embargo, el software de código cerrado se
caracteriza por que el código fuente del producto no está a disposición del público en ge-
neral.
ME 7.3.1.Instalación de Eclipse
Eclipse presenta una arquitectura abierta y extensible basada en módulos (plug-ins en
inglés). De esta forma, Eclipse puede ser muy ligero o más pesado, dependiendo de los
módulos que se instalen. Otros entornos llevan integrados una serie de herramientas ne-
cesarias para desarrollar webs o para crear aplicaciones con interfaces gráficas de usua-
rio, motivo por el cual estos entornos desperdician recursos del ordenador, ya que hacen
al IDE más lento durante el tiempo en el que está funcionando. Eclipse se puede instalar
en diferentes sistemas operativos, en versiones de 32 y 64 bits.
En primer lugar, aquí se explicará cómo se instala la plataforma Eclipse. Las versiones de
Eclipse disponibles se encuentran en la página web http://www.eclipse.org/ downloads/

(Figura 2.4).
Si se hace clic en el botón Download x86_64, aparece otra pantalla, en la que, para co-
menzar la descarga, hay que pulsar sobre el botón Download (Figura 2.5).
VA|
LA
2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO |NFORMAT¡CA | CU
Es Eclipse Downloads
| The Eclipse | X
- Y> C A edipseorg/downloads/
ECLIPSE Projects Working Groups Members More-
ECLIPSE
ALOXY LEVERAGES
ECLIPSE FOUNDATION
Download Eclipse Technology MEMBERSHIP TO BUILD
ITS PETRO-CHEMICAL
thatis right for you BUSINESS
Tool Platforns
The Eclipse installer 2021-06 R now includes a JRE

for macOS, Windows and Linux.
- ORIC.N
- Eclipse Che is a developer
workspace server and cloud
.
A modem, open source
software development
Get Eclipse IDE 2021-06 IDE. environment
that runs in the
cloud
Install your favorite desktop IDE packages.
Figura 2.4. Se pulsa en el botón Download x86_64 para descargar Eclipse para sistemas
operativos de 32 o de 64 bits.
Es Eclipse downloads - Select a mir X
€ > C Á eclipse.org/downloads/download.php?file=/0omph/epp/2021-06/R/eclipse-inst-jre-win64.exe
E C L | p S E Projects Working Groups 1Members More-
Home / Downlcads / Eclipse downloads

- Select a mirror
All downloads are provided under the terms and conditions of the Eclipse Foundation Software User Agreement uniess
otherwise specified. CRYSTAL REPORTS
Download from: Italy - Consortium GARR (https)

File: eclipseinstire-win64.exe | SHA-512
>> Select Another Mirror
Figura 2.5. Para iniciar la descarga del IDE Eclipse, se hace clic en el botón Download.
Tras hacer doble clic en el archivo ejecutable descargado, se selecciona la primera op-
ción: Eclipse IDE for Java Developers. En la ventana emergente, se puede madificar la car-
peta en la que se encuentra la máquina virtual de Java (JVM), así como la carpeta en la
que se desea realizar la instalación. Lo habitual es que sean válidas las rutas propues-
tas. Al hacer clic en el botón INSTALL, comienza la instalación, al inicio de la cual, se soli-
cita aceptar el acuerdo de licencia. Una vez finalizada la instalación, aparece una ventana
como la de la Figura 2.6, en la que se indican las carpetas donde se encuentran insta-
lados JDK y Eclipse, y en la que se puede pulsar en el botón LAUNCH para iniciar el IDE
por primera vez.
N¡/XX Y COMUNICACIONES 2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO
. ; —
eclipseinstaller ., oo —
Eclipse IDE for Java Developers details

% The essential tools for any Java developer, including a Java IDE, a Git
client, XML Editor, Maven and Gradle integration.
Java 11+ VM CProgram FilesYavadk-16.0.2 v s
Installation Folder | CAUsersYJoseleclipseljava-2021-06 =
Y create start menu entry
Y create desktop shortcut
D LAUNCH
< BACK
Figura 2.6. Ventana que se muestra tras la instalación exitosa del

IDE Eclipse. Para iniciar Eclipse por primera vez, se pincha sobre
el botón Launch.
ME 7.3.2. Instalación de NetBeans

Para instalar la última versión de Apache NetBeans, que en el momento de escribir este
libro, es la 12.4, se accede a la página web https://NetBeans.Apache.org/
download/
index.html, y allí, se hace clic sobre el botón Download (Figura 2.7).
) Apache NetBeans Releases — X

< >0 4 netbeansapacheorg/download/indexhtml * O:
o Apache NetBeans Community — Participate “ Blog — GetHelp — Plugins — Download
Latest release
Apache NetBeans 12.4
Apache NetBeans Releases

Apache NetBeans is released four times a year. For details, see full release schedule.
Apache NetBeans 12 feature update 4 (NB 12.4)

Latest version of the IDE, released on May 19, 2021.
Te -
W_Apggn_gñ_ljlet8eans 12 LTS (NB 12.0)
Figura 2.7. La última versión de Apache NetBeans se puede

descargar en la página web de descargas de Apache NetBeans,
pinchando sobre el botón Download.
Se puede descargar un instalador, disponible para diferentes sistemas operativos, o bien

un archivo comprimido. Aquí, se elige esta última opción, pulsando en el enlace corres-
pondiente al archivo NetBeans-12.4-bin.zip (Figura 2.8).
LA
ÍJN¡… f
2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO INFORMAT|CA Y Cl¿!)
Q Downloading Apache NetBeans — X
€ > C MM netbeansapacheorg/download/nb124/nb124.htmi Y º :
o Apache NetBeans Community Participate Blog Get Help Plugins Download I
Downloading Apache NetBeans 12.4

Apache NetBeans 12.4 was released May 19, 2021. See Apache NetBeans 12.4 Features Deployment Platforms
for a full list of features.
Building from Source
Apache NetBeans 12.4 is available for download from your closest Apache mirror.
Community Approval
* Binaries: netbeans-12 4-bin zip (SHA-512, PGP ASC)
Earlier Releases
* Installers
* Apache-NetBeans-12 4-bin-windows-x64.exe (SHA-512, PGP ASC)
* Apache-NetBeans-12 4-bin-linux-x64.sh (SHA-512, PGP ASC)
* Apache-NetBeans-12 4-bin-macosx.dmg (SHA-512, PGP ASC)
º macos versions prior to 10.14.4 require the Swift 5 Runtime to be installed to launch Apache NetBeans 12.4
Figura 2.8. Página web en la que se puede descargar un instalador de Apache NetBeans,
dependiendo del sistema operativo, o bien un archivo binario (archivo comprimido).
Una vez realizada la descarga del archivo comprimido, hay que descomprimirlo en nues-
tro equipo. Por ejemplo, se puede descomprimir en la unidad C:X, donde, tras la descom-
presión, se crea una carpeta con el nombre NetBeans. En la carpeta NetBeans Vbin habrá
dos archivos ejecutables para iniciar el IDE NetBeans: NetBeans.exe y NetBeans64.exe.
Es aconsejable crear un acceso directo a uno de estos archivos, dependiendo de si el
sistema operativo utilizado es de 32 o 64 bits. Al pinchar sobre este acceso directo, se
inicia el IDE NetBeans.
M 2.4. Edición de programas y generación de archivos

ejecutables
Una de las funciones que debe incorporar necesariamente todo entorno de desarrollo es
la de permitir la escritura del código fuente de los programas y la generación de archivos
ejecutables. En este apartado, se explica cómo se llevan a cabo ambas tareas en Eclipse
y NetBeans.
ME 2.4.1.Edición de programas y generación de archivos ejecutables

en Eclipse
Al acceder al IDE Eclipse, se solicita que se indique el nombre y ubicación del espacio de
trabajo (workspace) en el que desea almacenar los proyectos (Figura 2.9). Si la ruta que
se propone no nos interesa, se puede modificar escribiéndola directamente o pulsando
en el botón Browse para navegar por la estructura de carpetas de nuestro equipo. Des-
pués, se pincha sobre el botón Launch.
A k“1/ COMUNICACIONES 2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO
Select a directory as workspace

Eclipse IDE uses the workspace directory to store its preferences and development artifacts.
Wolkspac='| [CNUsersVoselDesktop ParaninfoVED
[JUse this as the default and do not ask again

» Recent Workspaces
Figura 2.9. Ventana que se muestra la primera vez que se ejecuta Eclipse y las
siguientes veces si no se activa la casilla de verificación que se muestra. Se debe elegir
la carpeta en la que se desean guardar los proyectos, que se conoce como espacio
de trabajo o workspace.
Tras elegir la ubicación del espacio de trabajo, para empezar a trabajar con Eclipse,
hay que crear un proyecto seleccionando la opción de menú File > New > Java Project.
Seguidamente, se asigna un nombre al proyecto. Por ejemplo, como se muestra en la Fi-
gura 2.10, se escribe el nombre Ejercicios y se hace clic en el botón Finish.
Create a Java Project

Create a Java project in the workspace orin an external location.
Project name: [ Ejerciciod

Use default location
Location: - CAUsersVosel DesktopParaninfo UF240AProgramsjercicios
JRE
() Use an execution environment

JRE: JavaSE-16
OUsea project specific JRE: jdk-16.0.2

(9) Use default JRE 'jdk-16.0.2' and workspace compiler preferences
Project layout
O Use project folder as root for sources and class files

(0) Create separate
folders for sources and class files Configure default...
Working sets
[ JAdd projectto working sets New...
Working sets:
Module
Create module-info.java file
0)
Figura 2.10. Ventana para la creación de un proyecto, dentro del cual se pueden crear
varios paquetes o clases.
Una vez creado el proyecto, existen varias opciones. Una de ellas consiste en crear pa-
quetes dentro de nuestro proyecto para englobar diversas clases. Para crear un paquete,
se selecciona la opción de menú File > New Package. Por su parte, si se desea crear cla-
ses en el proyecto en el paquete por defecto o en el paquete que se haya creado, se se-
lecciona la opción de menú File > New Class.
, TE
2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO INFORMATICA Y CO……
Así pues, siguiendo con el ejemplo, primero se selecciona la opción de menú File > New
Package para crear un paquete llamado programas, como se muestra en la Figura 2.11.
Java Package
Create a new Java package.
Creates folders corresponding to packages.
Source folder: Ejercicios/src
Name: programad
[]Create package-info
java
[ Generate comments (configure templates and default value here!
Figura 2.11. Ventana para la creación de un paquete dentro de un proyecto. En la opción

Source folder, se indica la carpeta en la que se creará y, en la casilla de abajo, se le da un
nombre al paquete.
A continuación, para crear una clase, se activa la opción de menú File > New Class. En la
pantalla que aparece después, se indica el paquete en el que se desea ubicar la clase y
su nombre. Asimismo, es posible seleccionar diferentes opciones interesantes, como por
ejemplo, que se cree un método main para la clase que se está creando o que se gene-
ren comentarios (Figura 2.12).
Java Class
Create a new Java class.
Source folder: Ejercicios/src
Package: programas
[]Enclosing type:
Name: Saludo
Modifiers: Opublic Opackage “ private — ) protected
[Jabstract [ ]final A static
Superclass: java.lang.Object
Interfaces:
Which method stubs would you like to create?

ipúbi sic yd
[] Constructors from superclass
Inherited abstract methods
Do you want to add comments? (Configure templates and default value here)
[ ] Generate conments
Figura 2.12. Ventana mediante la cual se crea una clase dentro del paquete y del
proyecto indicados en las opciones Package y Source folder, respectivamente.
Se debe asignar un nombre a la clase.
| l/ í»OMUNICACIONES 2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO
Tras crear la clase, aparece una pantalla (Figura 2.13), en la que, a modo de ejemplo, se
puede escribir una instrucción dentro del método main de la clase para mostrar un mensaje,
por ejemplo, «¡Hola, mundo!». En esta pantalla, se distinguen las siguientes áreas:
M Área de proyectos: en la parte izquierda, Package Explorer, se puede navegar por to-
dos los proyectos del espacio de trabajo y por los elementos que los componen.
M Área de edición: en la parte central, se puede escribir el código fuente de los pro-
gramas. En el código que se muestra en la Figura 2.13, el texto aparece resaltado
en diferentes colores; así, por ejemplo, las palabras clave del lenguaje aparecen en
color morado. Si se escribe una instrucción errónea, el editor la señala subrayando
en color rojo lo incorrecto y marcando la línea con una x dentro de un cuadrado con
fondo de color rojo.
E Outline: en la parte derecha, se muestra el esquema de la clase cuyo código se
está editando. Así, se accede más rápidamente a sus métodos y atributos.
E Consola Java: en la parte inferior, se muestra el resultado de la ejecución de los pro-
gramas o los errores de ejecución, en su caso.
File Edit Source Refactor ¡Navigate Search Project Run Window Help
- O:9
142 E 7 :D:.:%-0-4-Q-:7 0-:95-:0-6-e976C-p-r|r Qq :5|8
S Package Explorer 52 =2 [ "Saludojava 32 = E de Outline %2 = m
E E 3 1 package programas; A E 14 N w e x 3
4 E Ejercicios 2 £B programas
> 2A JRE System Library (jdk-16.0.2) $ public class saludo (| 4 O, Saludo
4 ( sre
a - ; A
—
e * main(String[]): void
a El programas 5e public static void main(String[] args) (
>I[3) Saludoj /7 TODO Auto-generated method stub
s a System.out.printin ("¡Hola, mundo!");
v
>
[*] Problems G Javadoc

[E) Declaration ) Console33 s X %| E l EE| * e -d eo
<terminated> Saludo [Java Application] C:1Program FilesVava jdk-16.0.21bin javaw.exe (7 ago 2021 12:33:49 — 12:33:54)
¡Hola, mundo!
<
| Writable | Smart Insert |3:22:4
Figura 2.13. Aspecto del IDE Eclipse cuando se está escribiendo el código de un programa, en este caso,
uno que tan solo muestra en pantalla el famoso mensaje «¡Hola, mundo!»
Una vez se haya creado un programa en Eclipse con al menos una clase, ya es posible
ejecutarlo. Para ello, se debe mostrar en pantalla la clase cuyo código se desea ejecutar
y realizar una de las siguientes acciones:
M Seleccionar la clase en cuestión en el explorador del proyecto (parte izquierda de

la pantalla) y elegir, en el menú contextual (pulsando el botón derecho del ratón), la
opción Run As > Java Application.
E Activar la opción de menú Run > Run.

M Hacer clic en el icono O .
Seguidamente, aparece el resultado de la ejecución en la consola Java (parte inferior de

la pantalla).
2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO INFORMATICA Xl/ ,
Por cada proyecto creado en Eclipse, se genera, dentro de la carpeta que se ha asigna-
do al espacio de trabajo (workspace), una carpeta con el nombre asignado al proyecto. Es
importante saber que, dentro de esa carpeta, habrá a su vez dos carpetas:
E La carpeta src, que contiene los ficheros con el código fuente Java correspondiente
a cada una de las clases que contiene la aplicación que se está creando. En esta
carpeta, habrá una carpeta por cada paquete (si se han creado) y, dentro de estas,
un archivo de tipo texto con extensión .java por cada clase.
E La carpeta bin, en la que se encuentran los ficheros con las clases objeto. En esta
carpeta, hay, al igual que en la src, una carpeta por cada paquete (si se han creado)
y, dentro de estas, un archivo con la extensión .class por cada clase.
Selección de un espacio de trabajo usado recientemente al iniciar Eclipse

¿ES posible, al iniciar Eclipse, seleccionar un espacio de trabajo diferente del que aparece
por defecto y que haya sido usado recientemente sin tener que navegar por la estructura de
carpetas y ficheros del equipo?
Solución
Sí, es posible. Si se pulsa sobre el enlace Recent Workspaces que aparece en la parte infe-
rior izquierda de la ventana que se muestra en la Figura 2.9, aparecerá una lista con los es-
pacios de trabajo empleados recientemente entre los que se puede seleccionar el que se
desee, haciendo clic sobre el nombre correspondiente.
Cambio del espacio de trabajo en Eclipse

Al iniciar Eclipse, aparece una ventana (Figura 2.9) donde se pide el nombre y la ubicación
del espacio de trabajo que se quiere usar. Pues bien, ¿es posible cambiar de espacio de tra-
bajo una vez que se ha comenzado a usar Eclipse sin necesidad de reiniciar el IDE?
Solución
La respuesta es afirmativa, pues la opción de menú File > Switch Workspace permite selec-
cionar uno de los espacios de trabajo usados recientemente. Si ninguno de los espacios de
trabajo nos interesa, se puede clicar sobre la opción Other. En este caso, aparece una ven-
tana como la representada en la Figura 2.9, en la que haciendo clic en el botón Browse...,
se puede seleccionar, como espacio de trabajo, una carpeta de nuestro equipo.
ME 7.4.2.Edición de programas y generación de archivos ejecutables

en NetBeans
Al acceder al IDE NetBeans, para crear una aplicación con este entorno, lo primero que
se debe hacer, como con el entorno Eclipse, es crear un proyecto. Con este fin, se activa
la opción de menú File > New Project. En la ventana que se muestra en la Figura 2.14,
I 1MX*… 1/ [OMUNICACIONES 2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO
se puede observar que con NetBeans, se ofrece la posibilidad de crear proyectos no solo
en Java, sino también en otros lenguajes, como C, C++ o PHP En este caso, se seleccio-
na la opción de menú Java with Maven > Java Application. La opción Java with Maven >
> Java Frontend Application permite crear una aplicación Java con GUI, aunque esto tam-
bién es posible simplemente añadiendo un panel a una aplicación Java creada con la op-
ción Java Application.
Choose Project
Q Fiter: |
Categories: 5
:- [ Java with Maven = N Java Application
+- [ with Gradie
Java 28 JavaFrontend Application
-E Java with Ant
+ HIMLS/Javascript
1- E C/C++
- PP
E- E Samples
Description:
This feature s not yet enabled. Press Next to activateit.
A simple Java SE application using Maven. You are recommended to begin here, if you are
Lnew to Java!
Ensh — | Canel|| hep
Figura 2.14. Ventana que se muestra al seleccionar la opción de menú File > New
Project y que permite crear proyectos en Java, C, C++, PHP etcétera.
Si se elige la opción Java with Maven > Java Application, puede ocurrir que se indique a
continuación que se debe activar el soporte para Java SE; si este fuera el caso, se pulsa
el botón Activate (Figura 2.15).
Finding Feature
In order to use this functionality, support for Java SE must be activated.
Additional modules are recommended to run Java SE support.
[] nb-javac
Impl
Download
and Activate...
Figura 2.15. Ventana en la que se solicita activar la asistencia para Java SE,
para lo que se pulsa sobre el botón Activate.
Tras la activación, si esta ha sido necesaria, en la ventana que se muestra en la Figura 2.16,
se da nombre al proyecto y, en el campo Project Location, se indica su ubicación en
nuestro equipo. En los otros campos, se puede dejar la información que aparece por de-
fecto. Al hacer clic en el botón Finish, se crea el proyecto.
2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO INFORMATICA Y CQ/X1
Name
and Location
ProjectName: — [ProyectoNetBeans
Project Location: [C:Wsem&)oseb&d:mw…fc'£º
+ |C:WsersVoseDesktopParaninfo|EDProyectoNetBeans1
ProyectoNetBeans1
com.mycompany
1,0-SNAPSHOT
chm.mymnpanv.proymbeans A
Figura 2.16. Ventana en la que se da un nombre al proyecto y se indica dónde se va

a almacenar en el equipo. Si se desea cambiar la ubicación por defecto, se hace clic
en Browse para seleccionar una nueva ubicación.
Una vez generado un proyecto, es posible crear en él paquetes y clases, al igual que en
Eclipse. En NetBeans, se selecciona el menú contextual del proyecto en cuestión y se ac-
tiva la opción de menú New > Java Package o New > Java Class, respectivamente. Por
ejemplo, se puede añadir al proyecto creado anteriormente un paquete llamado progra-
mas. Este aparecerá inmediatamente en el explorador de proyectos (arriba a la izquierda)
dentro de la carpeta Source Packages. Luego, se abre el menú contextual de este pa-
quete para crear en él una clase llamada Saludo con el fin de mostrar el mensaje «¡Hola,
mundo!».
v
CrestedFile: [C:WsersVoselDesktopParaninfo
ED royectoNetBeans 1)srcain Vava lprogramas Saludo java |
Superdass:
Interfaces:
Figura 2.17. Ventana en la que se crea una clase llamada Saludo dentro del paquete
programas del proyecto ProyectoNetBeans1.
Al clicar en el botón Finish (véase Figura 2.17), se procede a la creación de la clase y se

muestra una pantalla como la de la Figura 2.18, en cuya parte derecha, se puede escri-
bir el código fuente de la clase (área de edición). Hay disponible, al igual que en Eclipse,
un área reservada al explorador de proyectos (parte superior izquierda) y un área que re-
cibe el nombre de Navigator, donde se muestra el esquema de la clase que se está codi-
ficando (parte inferior izquierda).
A k“1/ COMUNICACIONES 2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO
Al igual que se hizo para la clase creada con Eclipse, a modo de ejemplo, se puede in-
Cluir, dentro de la clase Saludo, un método main que muestre el saludo «¡Hola, mundo!».
File Edit View Navigate Source Refactor Run Debug Profile Team Iool indow - Help Q search (Ctl+D)
EE
DE eu O TY) 0- mO S
Projects X | Files Services
E- ProvectoNetnemnsl 2- a aua r7etladueu., E
-FE Source Packages
A m
+ EEl com.mycompany.proyectonetbeans1 License Headers ín Project Properties.
E- EE programas , Choose Tools | Templates
— saludo.java
he templarte in che editor,
-Ey Test Padkages
package programas;
..
* Cauthor Jose
"/
public class Saludo .
— Q man(strino] aros) public static void main (String args[])(í
System.out.printin ("¡Hola, mundo!");
Figura 2.18. Aspecto de la pantalla de IDE NetBeans cuando se está escribiendo el código de un programa.
En este caso, se ha creado un programa que tan solo muestra en pantalla el famoso mensaje «¡Hola, mundo!».
Para ejecutar el programa, hay disponibles varias opciones:
M Seleccionar el proyecto en el explorador de proyectos y elegir en el menú contextual

la opción Run.
E Activar la opción de menú Run > Run Project.
E Hacer clic en el icono ©
Independientemente de la opción utilizada, emergerá una ventana como la que se mues-

tra en la Figura 2.19, donde se permite elegir una clase del proyecto como clase main,
es decir, como la clase cuyo método main iniciará la ejecución de la aplicación. En este
caso, se selecciona la clase Saludo dentro del paquete programas (programas.Saludo).
Se puede indicar, además, si se desea que esta elección sea recordada para siempre o
solo en la sesión actual.
programas.Saludo
Figura 2.19. Ventana en la que se selecciona la clase cuyo

método main se quiere ejecutar.
2. INSTALACIÓN Y USO DE ENTORNOS DE DESAR INFORMATICAY C
Como en Eclipse, el resultado de la ejecución se muestra debajo del área de edición.
Esta área viene etiquetada con la palabra Output (salida).
M 7.5.Instalación y desinstalación de módulos

En los entornos de desarrollo, es frecuente instalar también módulos o plug-ins adicio-
nales para la realización de tareas para las que no hay componentes incorporados en la
versión instalada.
Argot técnico
El término plug in es un verbo inglés que se puede traducir como «enchufar» o «conectar».
Se puede interpretar que un plug-in es un módulo o componente de software que añade una
característica o un servicio adicional a un software existente y que se enchufa o conecta a
dicho sistema.
ME 7.5.1.Instalación y de sinstalación de módulos en Eclipse

Se pueden consultar cuáles son | os módulos instalados y los que hay disponibles para
Eclipse, seleccionando en el menú la opción Help > Eclipse Marketplace. Se muestra en-
tonces una pantalla, como la de la Figura 2.20. Si ya tiene algún módulo instalado, pue-
de ocurrir que Eclipse haya detectado actualizaciones para alguno de ellos, en cuyo caso
se indicará, como se puede observar en la figura. Si se desea actualizar los módulos,
que es lo más deseable, se hace clic en el botón Update now.
Eclipse Marketplace
Select solutions to instal I. Press Install Now to proceed with installation.
Press the "more info" link to learn more about a solution.
Search l Recent [ Popular Favorites|Installed] 7 Giving loT an Edge

Find: [»ºi [All Markets v | [All Categories
Updates available
Some of your installed plug-ins have updates available. Please update
now to benefit from the latest improvements.
|Show updates | | Updatenow ,
Marketplaces
—
0) < Back Install Now >
Figura 2.20. Ventana que se muestra al seleccionar la opción de menú Help > Eclipse
Marketplace, útil para instalar o desinstalar módulos en Eclipse. Si hay actualizaciones
disponibles para los módulos instalados, Eclipse informa sobre este hecho, como es el caso.
1 kOMUNICAGONES 2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO
En la siguiente ventana, se solicita confirmar las actualizaciones y, posteriormente, se

aceptan los acuerdos de licencia correspondientes, tras lo cual comienza la actualiza-
ción de los módulos afectados, que se lleva a cabo en segundo plano. Una vez que la
actualización haya finalizado, se indica que es necesario reiniciar Eclipse para que esta
tenga efecto.
M N Instalación de WindowBuilder en Eclipse

Dado que Eclipse no tiene incorporada de serie la opción de crear aplicaciones con in-
terfaces gráficas de usuario (GUI, graphical user interface), es preciso instalar un módulo
que permita crear este tipo de programas. Swing es la librería que permite crear aplica-
ciones con interfaces gráficas de usuario en Java.
Para instalar el módulo que incorpora Swing a Eclipse, se selecciona de nuevo la opción
de menú Help > Eclipse Marketplace y, en la ventana que aparece en pantalla, se escri-
be WindowBuilder en el cuadro de texto que hay a la derecha de la palabra Find. Window-
Builder es el módulo que permite incorporar Swing a nuestra instalación de Eclipse. Una
vez escrito, se pulsa el botón Go a la derecha y aparece más abajo, entre otros, el módu-
lo WindowBuilder 1.9.5. Seguidamente, se clica sobre el botón Install correspondiente a
este módulo (véase Figura 2.21).
Eclipse Marketplace
Select solutions to install. Press Install Now to proceed with installation.
Search,R:(ent Popular | Favorites | Installed| ) Giving loT an Edge

Find: , — Window Builder » | [AN Markets y | [All Categories
WindowBuilder 1.9.5
WindowBuilder is composed of SWT Designer and Swing Designer and makes it very easy to create Java GUI
applications without spending a lot of time writing code.... more info
T byeEclipse Foundation, EPL
SWT swing wysiwyg graphical WindowBuilder
[9P] Installs: 600K (9.606 last month) Install
—EL
Marketplaces
© < Back Install Now >
Figura 2.21. En Eclipse Marketplace, se muestra el módulo WindowBuilder preparado

para su instalación.
A continuación, aparece una nueva ventana con los elementos del módulo que se va a
instalar (Figura 2.22), de entre los cuales se puede seleccionar solo algunos o todos
ellos.
2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO INFORMATICA Y COÍM
Contirm Selected Features 1

Press Confirm to continue with the installation. Or go back to choose more
solutions to install.
a V| G WindowBuilder 1.9.5 http://download.eclipse.org/windowbuilder/latest/

] Y WindowBuilder Core (required)
Q WindowBuilder Core Ul (required)
4 WindowBuilder Java Core (required)
K WindowBuilder Swing Designer (required)
4 WindowBuilder SWT Designer (required)
] Y WindowBuilder SWT Designer Core (required)
U WindowBuilder Core Documentation
4 WindowBuilder GroupLayout Support
U WindowBuilder Swing Designer Documentation
4 WindowBuilder SWT Designer Documentation
KP WindowBuilder SWT Designer SWT_AWT Support
< Install More Confirm >
Figura 2.22. Elementos del módulo WindowBuilder disponibles para su instalación.

Se marca aquellos que se desea instalar.
Una vez elegidos los componentes que se desean instalar, se pulsa el botón Confirm y se
acepta el acuerdo de licencia en la siguiente ventana, tras lo cual, comienza la instala-
ción en segundo plano. Al finalizar la instalación, debe reiniciarse Eclipse para que tenga
efecto la actualización del software.
El módulo WindowBuilder sirve para la creación de aplicaciones con una interfaz gráfica
de usuario, en las que se presentan diferentes tipos de controles, como los que se sue-
len mostrar en los formularios. Algunos de ellos son los siguientes:
Etiquetas (JLabel): contienen texto que no se puede modificar.
Campos de texto (JTextField): sirven para escribir texto en su interior.
Cuadros de contraseña (JPasswordField): en ellos, se escribe texto que se desea

que no sea visible, de manera que el texto introducido queda oculto, generalmente,
por medio de puntos.
Áreas de texto (JTextArea): se utilizan para introducir texto que ocupa varias líneas.
Botones (JButton): sirven para dar una orden.
Casillas de activación (JCheckBox): mediante estas, la persona usuaria puede elegir

una opción o varias, de manera que pueden estar activadas o no. Si hay varias ca-
sillas marcadas, pueden estar activadas de manera independiente.
Botones de opción (JRadioButton): son similares a las casillas de activación, pero

los botones de opción son excluyentes, mientras que aquellas no lo son.
Listas (JList): permiten escoger un valor de entre varios, habiendo dos posibilidades:
la selección de una sola opción o de varias (con la tecla Ctrl pulsada).
Cuadros combinados (JComboBox): son listas desplegables que pueden ser utiliza-
das también como cuadros de texto, en los que se puede escribir.
Í JKI¡. KW/ COMUNICACIONES 2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO
En la Figura 2.23, se muestran algunos de los controles descritos en la página anterior.
Etiqueta Campo de texto
NUEVO USUARIO
1 Cuadro de contraseña
Cuadro combinado
Botones de opción
Área de texto
Botón
Figura 2.23. Ventana creada con Swing gracias a la instalación del módulo WindowBuilder en Eclipse
y en la que se muestran distintos tipos de controles.
Para crear una aplicación visual, se activa la opción del menú New > Other > Window-
Builder > Swing Designer > Application Window.
Select a wizard
Create a Swing application window
Wizards:
type filter text
b E Plug-in Development
b ( User Assistance
4 ( WindowBuilder
Project Palette
4 (= Swing Designer
7 Application Window
B JApplet
= ia
Figura 2.24. Ventana para crear una aplicación visual con Eclipse.
Una vez hecho esto, tras indicar el paquete en el que desea ubicar la aplicación visual,
se da un nombre a esta. Entonces, aparece una pantalla, como la se muestra en la Fi-
gura 2.25, en la que aparece el código de la aplicación, que ha sido generado de mane-
ra automática.
2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO INFORMÁTICA
Y COMU
File Edit Source Refactor MNavigate Search Project Run Window Help
E- DaO -O- U - rP G-:2 9riN-A-eve-S-|A a ia

H Package Explorer 2 = E [ Personajava f PruebaSwingjava 53 = a e Outine%2 =a
b [$ Figurajava
e 5
A
% 1
2
package programas; A BARRVox:
EB programas
» ] Personajava 3% import java.awt.EventQueue:[] 4 O, Pruebaswing
> D) PruebaCuenta.java 6 a- frame: JFrame
7 public class PruebaSwing í a .s main(String[]) : void
» D) PruebaCuentaHerenciaja
b (7) PruebaDíaSemana.java d Q new Runnable()(...
private JFrame frame;
b $7 PruebaEdadPersona.java e “ Pruebaswing0
» [2] PruebaEmpleado.java 7 E initializeQ):
void
» (7 PruebaExcepción1.java
* Launch the application.
» (7 Pruebafactorial.java *Z
> () PruebaFechas.java public static void main (String[] args) 1
> ] PruebaFigura.java EventQueue.invokelLater(new Runnable() (
> D) PruebaFiguralnt.java public void run() 1
> ) PruebaFiguraPolimórfica.j try í
b () PruebaFiguraPolimórfica2 PruebaSwing window = new PruebaSwing
();
» $) PruebaForjava window. frame.setVisible (true) ;
b 47) PruebalecturaNum.java ) catch (Exception e) (
b $9) PruebaMath.java e.printStackTrace () ;
> ] PruebaPersona java »
> B PruebaPersonaPolimórfic:l
> 17 PruebaRandom.java
» $7 PruebaSumabPares.java = Sour::l Design|
>[[] PruebaSwing.java [E] Problems G Javadoc [Q) Declaration El Console %
b 5) PruebaTablaMultiplicar.ja
No consoles to display at this time.
> $7 PruebaWhile.java
b [) Rectángulo.java
» [ Saludo.java
» () Triángulo.java v
< >
programas.PruebaSwing.java - Ejercicios/src
Figura 2.25. Pantalla que aparece inmediatamente después del momento en que se crea una aplicación visual.
En el área central se muestra el código fuente de la aplicación porque está seleccionada por defecto la pestaña
Source, pero se puede visualizar su diseño seleccionando la pestaña Design.
Si se clica sobre la pestaña Design, que está situada en la parte inferior del área central,
aparece el área de diseño de la ventana de la aplicación (Figura 2.26). A la izquierda de
dicha área, se muestra una paleta con diversos elementos. Los más importantes son los
componentes o controles que se pueden añadir a la ventana que se está creando (eti-
quetas, campos de texto, botones, casillas de activación, etc.).
< — Palette —
() Struts
8: Springs
(= Components
tEuJLabel ¡AlTerfield
(EJComboBox ESIButton
WIJCheckBox — € JRadioButt...
Ef JToggleBu... EB JTextArea
[elJFormatte... E-JPassword...
—| JTextPane EjJEditorPane
[EJSpinner =f JList
E JTable E] JTree
E JProgressB... M )ScrollBar
E Separator — (GiJSlider
( Swing Actions
ha <
Figura 2.26. Área de diseño de la ventana que se está creando y que inicialmente está
en blanco, pero en la que se pueden colocar los controles o componentes que aparecen
en la paleta de la izquierda.
Hx XW/ [OMUNICACIONES 2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO
M EN EN Instalación de Papyrus SysML en Eclipse

Otro módulo que resulta interesante instalar es el que permite crear diagramas UML (por
sus siglas en inglés, Unified Modeling Language) en Eclipse. Para ello, se activa la opción
del menú Help > Eclipse Marketplace y se escribe Papyrus en el cuadro de texto que hay
a la derecha de la palabra Find (Figura 2.27). Papyrus es un software que permite crear,
editar y visualizar diagramas UML 2.5.
Eclipse Marketplace
Searcthecent Popular| Favorites ' Installed| - Giving loT an Edge

Find: lp Papyrus Xl Al Markets
Papyrus SysML 1.6 2.2.a

SysML1.6 is a project of the Eclipse Papyrus's galaxy. SysML 1.6 application is a Papyrus
DSML implementing the SysML 1.6 OMG standard. more info
t by Papyrus, EPL
Installs: 8,92K (325 last month) Install
< Back Install Now >
Figura 2.27. Ventana de Eclipse Marketplace en el que se muestra el módulo Papyrus SysML
preparado para su instalación.
Para instalar el módulo Papyrus SysML, se pulsa sobre el botón Install, se seleccionan to-
dos sus componentes y, finalmente, se hace clic en el botón Confirm. Luego, se debe reini-
ciar el IDE Eclipse para que la instalación tenga efecto.

Instalación de un módulo en Eclipse
Instala en Eclipse un módulo que permita crear programas en Python y ejecutarlos.
M EE Modificación y desinstalación de módulos en Eclipse

Tras la instalación de un módulo en Eclipse, este aparece en la pestaña Installed de
Eclipse Marketplace (véase Figura 2.28).
2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO INFORMAT|CA Y COM J |
Eclipse Marketplace
Popular |Favorites
| Installed | () Giving loT an Edge
WindowBuilder 1.9.5
WindowBuilder is composed of SWT Designer and Swing Designer and
makes it very easyto create Java GUI applications without spending a
" lotoftime writing code.... more info
by Eclipse Foundation, EPL
SWT swing wysiwyg graphical WindowBuilder
| Instalis: 601K (9.502 last month) Change ! v
WindowBuilder Nightly Build 1.9.6.pre

Nightly Build! Install ¡f you want to usethe latest patches before a
release is available. It can be unstable. WindowBuilder is composed of
SWT Designer and... more info
by Eclipse Foundation, EPL
X) [] installs:19,3K (456 last month) Update |+
Marketplaces
Install Now >
Figura 2.28. Para saber cuáles son los módulos instalados en Eclipse Marketplace,
se pincha sobre la pestaña Installed. Estos módulos se pueden actualizar
(si hay alguna actualización disponible), cambiar o desinstalar.
Por cada módulo instalado, en la parte inferior derecha, aparece un botón en el que pue-
de leer Update o Change. Si aparece el texto Update, quiere decir que hay alguna actuali-
zación disponible para ese módulo, en cuyo caso, se puede activar la opción Update que
aparece al desplegarla para llevar a cabo la actualización. También aparece la opción
Change, que sirve para modificar elementos del módulo instalado. Así, si se pincha esta
opción para el módulo WindowBuilder 1.9.5, aparece la ventana que se muestra en la Fi-
gura 2.29.
Confirm Selected Features 4;

Press Confirm to continue with the installation. Or go back to choose more |g
solutions to install.
a VG WindowBuilder
1.9.5 http://download.eclipse.org/windowbuilder/latest/
RG WindowBuilder Core (required)
4 WindowBuilder Core Ul (required)
] 4 WindowBuilder Java Core (required)
R WindowBuilder Swing Designer (required)
G WindowBuilder SWT Designer (required)
I WindowBuilder SWT Designer Core (required)
[ G+ WindowBuilder Core Documentation
[V] G WindowBuilder GroupLayout Support
Á WindowBuilder Swing Designer Documentation
4 WindowBuilder SWT Designer Documentation
4 WindowBuilder SWT Designer SWT_AWT Support
< Install More Confirm >
Figura 2.29. Ventana que muestra los elementos del módulo PowerBuilder 1.9.5
instalados por si se desea eliminar alguno o añadir otro que no esté incorporado.
H—… 1XW/ COMUNICACIONES 2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO
En esta ventana, se puede desmarcar alguno de los elementos del módulo, en cuyo caso
se activa el botón Confirm y se procede a su desinstalación. En caso de haber seleccio-
nado un módulo que no incluya todos los elementos disponibles para este, también se
podrá instalar algún elemento adicional.
Para todos los módulos instalados, también aparece la opción Uninstall, que habrá que
seleccionar si se desea desinstalarlo, para lo cual se pedirá confirmación.

Modificación de elementos de un módulo instalado en Eclipse
Desinstala alguno de los elementos opcionales que componen el módulo para programar en
Python instalado en la Actividad propuesta 2.1.

Desinstalación de un módulo en Eclipse
Desinstala en Eclipse el módulo instalado en la Actividad propuesta 2.1.
ME 7.5.2. Instalación y desinstalación de módulos en NetBeans

Al igual que en Eclipse, en NetBeans, se pueden instalar módulos o plug-ins que permi-
ten realizar tareas para las que no hay complementos incorporados en la instalación del
IDE. En este entorno, se emplea la opción de menú Tools > Plugins. Si se activa esta,
aparece una ventana con varias pestañas.
Si hay actualizaciones disponibles para el IDE, estas aparecerán en la pestaña Updates.
También se puede clicar en el botón Check for Updates para que en ese momento se bus-
quen actualizaciones disponibles.
En la pestaña Available Plugins, es posible visualizar los módulos disponibles para su ins-
talación en NetBeans, como se muestra en la Figura 2.30. Al marcar cada módulo, apa-
rece su descripción en la parte derecha de la ventana.
[Updates | Avaiable Plugins (42) [ Download

| Installed
ed (11 | setings|
)
EZ
P
Install - Name
NB MindMap Editor
] Backlog Support
] Github Issues Support 1“nmmmmv¡cm::immlri.¿¡n
[ JM for NB Update Center
[m] TegMyCode Version: 1.4.11
[m] NetBeans Case Converter Author:
Igor Maznitsa
al Calor Codes Preview Date: 28/3/21
[m] nb-noext-mime-resolver Source: NetBeans Plugin Portal
l| Change Line Endingson Save Editing Homepage: htto://www.scareto.org
dMap Editor E
Modia Descriati
000000
The Plugin allons creste and edit mind maps within NetBeans projects.
?
1
Figura 2.30. Módulos o plug-ins disponibles para su instalación en Apache NetBeans.

2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO INFORMATICA Y CO”'1 1
A modo de ilustración, aquí se explica cómo instalar el módulo NB MindMap Editor, que
permite crear y editar mapas mentales dentro de los proyectos de NetBeans. A tal fin, se
selecciona dicho módulo y se hace clic en el botón Install. Tras aceptar el acuerdo de li-
cencia, comienza su instalación, que se puede indicar que tenga lugar en segundo plano
(casilla de verificación Run in Background). Cuando ya está instalado, es necesario reini-
ciar el IDE para lo que habrá que indicar si se desea reiniciar el entorno en ese momen-
to o más tarde.
The NetBeans IDE Installr has successfuly installed the folowing plugins:
NB MindMap Editor
Figura 2.31. Ventana que se muestra al finalizar la instalación de un módulo

en NetBeans. Para que tenga efecto, hay que reiniciar el IDE, y abajo se pregunta
si se desea hacerlo en ese momento o más tarde.
Una vez instalado un módulo, aparece este en la pestaña Installed. Como se puede ob-
servar en la Figura 2.32, en esta pestaña, se indica para cada módulo instalado si está
activo o no en la columna Active.
Avalable Plugins (35) | Donnloaded | Installed (12) | Settings]
PHP
s! :
SO
Version: 1.74
E
i
Source: Apache NetBeans IDE 12.4

o0NDoDOÉdoDO
Plugin Description
e
YI
Provides tools and support for PHP development. Indudes

PHP editor, debugger,
samples
and documentation.
PHP Satic Antsis
Static analysis
for PHP files.
Figura 2.32. Visualización de los módulos o plug-ins instalados en Apache NetBeans.

Es posible activar y desactivar cada módulo instalado y también desinstalarlo, tras

seleccionarlo en la columna Select.
Para activar cualquier módulo, tan solo es necesario marcarlo y hacer clic en el botón
Activate; en caso de que se quiera desinstalar, se pulsa sobre el botón Uninstall.
X1/ kOMUNICACIONES 2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO
MN 2.6.Mecanismos de actualización
Es importante mantener actualizado el entorno de desarrollo que se utilice, así como los
módulos o plug-ins que se han instalado.
En el Apartado 2.5.1, se indicó que, en el caso de Eclipse, al seleccionar la opción de

menú Help > Eclipse Marketplace, si hay actualizaciones disponibles para algún módulo,
estas se indican al entrar en Eclipse Marketplace, pudiendo proceder desde ahí a su ac-
tualización. No obstante, existe también la posibilidad de buscar actualizaciones no solo
para los módulos, sino también para el IDE, activando la opción de menú Help > Check
for Updates, tras lo cual, en la ventana emergente, aparecen todas las actualizaciones
disponibles, como se ve en la Figura 2.33.
Available Updates
Check the updates that you wish to install. 7
Name Version 1d
[Z] E Oomph Setup 1.22.0.v20210817-... — org.eclipse.oomph.setup feature.group
<
— SelectAll —| | DeselectAl
Details
Figura 2.33. Actualizaciones disponibles para Eclipse. Se puede elegir las que se desea instalar.
En esta ventana, es posible seleccionar las que deseen instalar y, una vez selecciona-
das, se pulsa en el botón Next. Después de esto, se confirma y se inicia el proceso de
instalación tras aceptar el correspondiente acuerdo de licencia.
En el caso de NetBeans, para actualizar el IDE, existe la misma opción de menú Help >
> Check for Updates. Una vez activado, aparecen en una ventana las actualizaciones
disponibles y se puede proceder entonces a instalarlas pinchando sobre el botón Next.
Welcome to the NetBeans IDE Plugin Installer

The installer will download, verify and then install the selected plugins.
The following plugins will be updated:
External Code Formatters [1.14.0 -> 1.14.1]

Figura 2.34. Actualizaciones disponibles para Apache NetBeans. Para llevar a cabo
su instalación, se hace clic en el botón Next.
Utilidad de los entornos
de desarrollo
Componentes de un entorno
de desarrollo
Instalación de un entorno
o de desarrollo
o£
]A
—
()
K)
()
v
)
o=
-]
_
=
()
()
K7
oD Edición de programas
= y generación de archivos
-
= ejecutables
=
o
s
+e
”
£
Instalación y desinstalación
de módulos
Mecanismos de actualización
74
2.1. Las actividades de desarrollo de software que más asistencia reciben por los en-
tornos de desarrollo son:
a) Programación y pruebas.
b) Análisis y diseño.
c) Diseño y programación.
d) Programación y mantenimiento.
2.2. El conjunto de utilidades que permite la ejecución de programas escritos en Java

recibe el nombre de:
a) JDK.
b) JRE.
c) JVM.
d) IDE.
2.3. ¿Qué nombre recibe el componente de un entorno de desarrollo que permite con-
trolar los cambios que se realizan sobre los programas, creando distintas versiones
de estos?
a) Constructor de interfaz gráfica.
b) Depurador.
c) Editor de textos.
d) Control de versiones.
2.4. Para compilar un programa escrito en Java desde el indicador del sistema se usa el
compilador llamado:
a) javac.
b) java.
c) compiler.
d) Ninguna de las respuestas anteriores es correcta.
2.5. Los ficheros que contienen el código fuente de los programas escritos en Java tie-
nen extensión:
a) .java.
b) .class.
C) .exe.
d) .txt.
2.6. Los entornos de desarrollo Eclipse y Apache NetBeans son:

a) De código cerrado y gratuitos.
b) De código cerrado y de pago.
c) De código abierto y gratuitos.
d) De código abierto y de pago.
79
2.7. Por cada proyecto Java creado en Eclipse, se crea una carpeta en el espacio
de trabajo (Workspace) especificado y, dentro de esta carpeta, hay una carpeta
cuyo nombre es . Esta carpeta contiene una subcarpeta por cada paque-
te del proyecto y, dentro de cada una de estas subcarpetas, hay un archivo con
la extensión para cada clase creada en el paquete. Elige la opción correc-
ta para rellenar los huecos en el texto anterior:
a) bin / class.
b) src / class.
C) bin / java.
2.8. Indica la afirmación correcta en relación con las similitudes y diferencias entre
los entornos de desarrollo Eclipse y Apache NetBeans:
a) En los dos entornos de desarrollo se debe indicar la ubicación del espacio de tra-
bajo o workspace donde se almacenarán los proyectos.
b) En Eclipse, se puede ejecutar cada clase de manera independiente seleccionan-
do, desde su menú contextual, la opción de ejecución correspondiente, mientras
que en NetBeans esto no es posible.
c) En los dos entornos de desarrollo, tras instalar un módulo, es posible modificar
los elementos de los que consta el módulo instalado.
2.9. En cuanto a la creación de aplicaciones con interfaces gráficas de usuario en

Apache NetBeans:
a) Para crear estas aplicaciones es necesario instalar un módulo o plug-in.
b) Para crear este tipo de aplicaciones, se debe crear un proyecto usando la opción
de menú File > New Project > Java with Maven > Java Application y luego se
añade un panel a la aplicación.
C) Para crear este tipo de aplicaciones, se crea un proyecto empleando la opción de
menú File > New Project > Java with Maven > Java Frontend Application.
d) Las respuestas b y c son correctas.
2.10. En Eclipse y en Apache NetBeans, puede constar de

y, en , puede haber . Elige
la opción correcta para rellenar los huecos en el texto anterior:
a) un paquete / varios proyectos / cada proyecto / varias clases.
b) un proyecto / varios paquetes / cada paquete / varias clases.
C) un paquete / varias clases / cada clase / varios paquetes.
d) un proyecto / varias clases / cada clase / varios paquetes.
Actividades de aplicación
2.11. Se sabe que es posible crear y ejecutar programas en Java sin el uso de ningún entorno
de desarrollo. ¿Qué ventajas aporta el empleo de un entorno de desarrollo?
2.12. ¿Cuáles son las diferencias entre un editor de textos como el bloc de notas y el editor de
76 textos que incorpora un entorno de desarrollo?
2. INSTALACIÓN Y USO DE ENTORNOS DE DESARROLLO ACTIVIDADES FINALES
2.13. ¿Qué software es necesario instalar en un ordenador antes de poder crear y ejecutar progra-
mas en Java independientemente de que se use para ello un entorno de desarrollo o no?
2.14. ¿Qué extensión tienen los programas fuente escritos en Java? Y una vez compilados,
¿Qqué extensión tiene el archivo resultado de dicha compilación?
2.15. ¿En qué consiste un constructor de interfaz gráfica? ¿Incorporan este componente
Eclipse y Apache NetBeans tras su instalación?
2.16. ¿En qué área de la pantalla de Eclipse se puede ver el resultado de la ejecución de un
programa abierto? Y ¿en qué área se pueden visualizar los proyectos del espacio de tra-
bajo (workspace) y se puede navegar por sus elementos?
2 ¿Qué controles se emplean dentro de una aplicación con interfaz gráfica de usuario para
que la persona usuaria pueda elegir una opción de entre varias que son excluyentes en-
tre sí? Y ¿cuáles se pueden usar para introducir texto que se desea que quede oculto?
2.18. Muchos entornos de desarrollo incluyen entre sus componentes un debugger o depura-
dor, ¿para qué sirve este componente?
2:19: ¿Cuál es la utilidad de los módulos o plug-ins en un entorno de desarrollo?
2.20. ¿Cómo se pueden instalar módulos o plug-ins en Eclipse y en Apache NetBeans?
2.2 ¿Es posible modificar los elementos o componentes de un módulo instalado en Eclipse
sin desinstalarlo y volver a instalarlo? En caso afirmativo, ¿cómo se puede realizar?
2.22. ¿En qué lenguajes de programación es posible escribir programas en Apache NetBeans
una vez instalado, es decir, sin instalar ningún módulo adicional o plug-in?
E Actividedaampdliaeció
sn
2.23. Crea en Eclipse una pantalla como la de la Figura 2.35, para la introducción de los datos
de una nueva persona usuaria de una aplicación.
Figura 2.35. Pantalla creada con Swing gracias a la instalación del módulo WindowBuilder en Eclipse. 1
2.24. Busca en internet información sobre el entorno de desarrollo BlueJ. ¿Qué le diferencia de
entornos de desarrollo como Eclipse y Apache NetBeans? ¿Con qué lenguajes de pro-
gramación se puede utilizar?
2.25. Busca información en la red sobre el entorno de desarrollo Microsoft Visual Studio. ¿Con
qué lenguajes de programación se puede utilizar?, ¿es de código abierto o cerrado?, ¿es
gratuito?
2.26. Averigua en internet qué lenguajes de programación se pueden utilizar con el entorno de
desarrollo Oracle JDeveloper, si se trata de un entorno de código abierto o cerrado y si
es gratuito.
2.27. Accede a la página web https://marketplace.eclipse.org/. ¿Qué información se muestra

en ella y para qué crees que sirve?
2.28. Crea la ventana correspondiente a la Figura 2.35 en Apache NetBeans.

E (( Eclipse - https://www.eclipse.org/
“ (Sitio web de Eclipse Foundation con información sobre los productos que pone a disposición
[a] del público y la posibilidad de descargarlos)
Linuxtopia - https://www.linuxtopia.org/online_books/eclipse_guides.html
(Página web con guías sobre Linux y desarrollo de software. Incluye una sección sobre Eclipse)
[a]
E [m]M(m] Apache NetBeans - https://netbeans.apache.org/
* (Página web con información sobre el IDE Apache NetBeans, desde la que se puede descargar)
E (m]5-T[m] Nube Colectiva - https://nubecolectiva.com/

(Portal web que ofrece tutoriales y recursos sobre desarrollo de software)
78
SEARCH
<o
z
>
Diseño y realización
de pruebas
Objetivos Contenidos
Comprender la filosofía de las pruebas El 3.1. Filosofía de las pruebas
del software. del software
Emplear las estrategias adecuadas El 3.2. Estrategia de pruebas
para la realización de pruebas a lo largo del software
del ciclo de vida del software. E 3.3. Técnicas de diseño de casos
Conocer y aplicar técnicas de diseño de casos de prueba
de prueba de caja blanca y de caja negra. E 3.4. Documentación de las pruebas
Conocer de qué manera se documentan E 3.5. Herramientas de depuración
las pruebas.
E 3.6. Pruebas automáticas
Utilizar herramientas de depuración
en un entorno de desarrollo.
Realizar pruebas automáticas en un entorno
de desarrollo.
3. DISEÑO Y REALIZACIÓN DE PRUEBAS |NFORMATÍCA / Kf
Introducción
Cuando un equipo de desarrollo acepta el encargo de crear una aplicación informática,
desea que el resultado de su trabajo sea de calidad, esto es, que la aplicación responda
a las necesidades del cliente y que tenga el menor número posible de errores. El objetivo
de la etapa de pruebas, posterior a la programación, es descubrir dichos defectos antes
de que el software sea entregado al cliente.
En esta unidad, se explica cómo abordar esta importante tarea y las diferentes técnicas
de diseño de casos de prueba. También se verá de qué manera un entorno de desarrollo
puede asistir a las personas que desarrollan programas informáticos en las tareas de de-
puración o corrección de errores encontrados en esta fase. Para finalizar, se describe el
empleo de una herramienta que sirve para la realización de pruebas unitarias de mane-
ra automatizada.
M 3.1. Filosofía de las pruebas del software

Las pruebas constituyen una de las tareas del ciclo de vida del software y tienen como
objetivo fundamental la detección de defectos que se han cometido inadvertidamente du-
rante el proceso de construcción del software.
Cabe hacer hincapie aquí que el objetivo de esta tarea es la detección de defectos y no
precisamente la demostración de que el software no tiene ninguno. Y es que, aunque
se trate de una pequeña aplicación, es imposible probar exhaustivamente el software,
es decir, es imposible encontrar todos sus errores. El objetivo debe ser pues realizar
pruebas que no supongan un esfuerzo excesivo y que haya una elevada probabilidad de
que se detecten los fallos, es decir, se trata de intentar encontrar un equilibrio entre el
esfuerzo requerido para esta tarea y la capacidad de detección de defectos. En este sen-
tido, también es necesario desmitificar una creencia común: el hecho de que se detecten
defectos durante este proceso es un indicativo de la negligente actuación de los desarro-
lladores de software. Nada más lejos de la realidad: como seres humanos que son, se
equivocan, lo que tiene como consecuencia que el resultado de su trabajo (en este caso,
el software) puede contener errores. Así pues, el objetivo debe ser detectar estos fallos
antes de que el software sea entregado al cliente, porque es probable que si no los en-
cuentran quienes han desarrollado el programa, los detecte el cliente una vez que el pro-
ducto ha sido entregado, y esto, sin lugar a dudas, no es deseable.
Otro factor que juega en contra de la consideración adecuada de las pruebas es que si
bien las tareas de análisis, diseño y programación se consideran tareas constructivas,
las pruebas pueden ser consideradas por parte del equipo desarrollador como psicológi-
camente destructivas. En consecuencia, el desarrollador o la desarrolladora actuará con

cuidado, y diseñará y ejecutará pruebas que demostrarán que el programa funciona, en
lugar de descubrir errores. Sin embargo, dado que las personas que desarrollan software
no son infalibles, es probable que haya errores, y por ello, es conveniente hacer un es-
fuerzo por encontrarlos antes de que el cliente los descubra, lo que sería lamentable.
| JMUN'CACIONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
Piattini et al. (2007), en relación con la actitud necesaria para acometer las pruebas, nos
indican que «un buen caso de prueba es aquel que tiene una gran probabilidad de encon-
trar un defecto no descubierto aún y que el éxito de una prueba consiste en detectar un
defecto no encontrado antes. El contraste con la visión tradicional de las pruebas ('Va-
mos a probar un par de opciones para comprobar que funciona y ya está') es radical».
Por estas razones, es necesario cambiar la mentalidad en relación con las pruebas del
software. Lo indicado anteriormente no quiere decir que las desarrolladoras y desarro-
lladores no deban probar sus propios programas. De hecho, siempre suelen ser ellas y
ellos mismos las personas encargadas de realizar las pruebas de más bajo nivel o las
pruebas de unidades individuales. No obstante, en el caso de proyectos grandes y sobre
todo en pruebas a mayor nivel, se suele involucrar en esta tarea a un equipo de pruebas
independiente, con el que deben trabajar conjuntamente las personas encargadas del de-
sarrollo del software para garantizar que se realicen pruebas exhaustivas del programa.
El objetivo de las pruebas puede percibirse desde dos puntos de vista:
1. Mediante las pruebas se pretende, por un lado, comprobar si se está construyen-

do el producto correcto, es decir, el que desea el cliente, lo cual se relaciona con
el concepto de validación.
2. Por otro lado, se trata de comprobar si el producto que se está desarrollando fun-
ciona correctamente, es decir, si lo que hace lo realiza de manera correcta. Esto
se refiere al concepto de verificación.
Así pues, mediante las pruebas se debe comprobar tanto si el producto es el que quiere
el cliente (validación) como si está construido correctamente, de manera que lo que hace
lo hace bien (verificación).
Asimismo, en relación con las pruebas, hay dos aspectos estratégicos, relacionados con
su puesta en práctica, que es preciso considerar:
1. La estrategia de aplicación de las pruebas, es decir, debe establecerse qué partes

del software deben someterse a pruebas a medida que se va desarrollando. Este
aspecto se analizará a fondo en el Apartado 3.2.
2. Las técnicas de diseño de casos de prueba que se van a emplear. O dicho de otro
modo, una vez seleccionada la parte del software que se someterá a prueba, se
deberá decidir de qué manera se debe llevar a cabo esta, es decir, habrá que
seleccionar la técnica apropiada. Estas técnicas se estudiarán en detalle en el
Apartado 3.3.
El IEEE (por sus siglas en inglés, Institute of Electrical and Electronics Engineers) propor-
ciona la siguiente definición para caso de prueba: «un conjunto de entradas, condiciones
de ejecución y resultados esperados desarrollados para un objetivo particular como, por
ejemplo, ejercitar un camino concreto de un programa o verificar el cumplimiento de un
determinado requisito». Es decir, un caso de prueba consiste básicamente en indicar qué

datos de entrada se deben suministrar al programa, qué datos de salida se deben obte-
ner y cuál es el fin de llevar a cabo dicho caso de prueba. Una vez ejecutada la prueba,
se comprueba si la salida obtenida coincide con la salida esperada. La coincidencia indi-
cará que no se ha detectado defecto alguno para ese caso de prueba; en caso contrario,
3. DISEÑO Y REALIZACIÓN DE PRUEBAS INFORMÁTICA Y C¡j/ '—
se realiza una tarea conocida con el nombre de depuración. La depuración es, por tanto,
el resultado de una prueba exitosa y consiste en localizar el error y corregirlo, para lo que
puede ser necesario efectuar nuevos casos de prueba.
—
Recuerda o
El hecho de que se encuentren errores a lo largo de la fase de pruebas de una aplicación
no debe entenderse como un fracaso del trabajo previo realizado. Al contrario, se debe
considerar como algo positivo el hecho de que se encuentren errores después de terminada
la programación, pues esto permite eliminarlos antes de entregar la aplicación y evita que
estos sean descubiertos por el cliente. No se debe olvidar que «todos cometemos errores» y,
como dice el dicho popular, «rectificar es de sabios».
MN 3.2. Estrategia de pruebas del software

Las pruebas siempre comienzan por los componentes más pequeños, es decir, se empie-
Za probando pequeñas porciones de software y se va incrementando de manera progresi-
va el alcance de la prueba. Se suelen llevar a cabo cuatro tipos de pruebas secuenciales
que se exponen en los siguientes subapartados.
ME 32.1.Prueba de unidad
Se comienza probando o bien módulos individuales de software, en caso de que se de-
sarrolle software convencional, o bien clases, si se trata de software orientado a objetos.
En este último caso, la prueba de unidad conlleva realizar también pruebas a nivel de
método, es decir, para cada método no trivial habrá que comprobar si su comportamiento
es el adecuado. Es obvio pues que para probar correctamente una clase entera, es nece-
sario realizar pruebas con cada uno de sus métodos.
ZN
Amma
Argot técnico
Cuando se habla de software convencional, ello se refiere al software creado siguiendo el
paradigma estructurado, según el cual una aplicación consta de varios componentes o
módulos (procedimientos o funciones), de manera que existe un módulo de control principal,
que llama a otros módulos, y estos a otros y así sucesivamente.
Recuérdese que, por el contrario, en el paradigma orientado a objetos, una aplicación
consta de varias clases, y que cada una de estas se compone de atributos y operaciones,
llamadas métodos. A partir de una clase, se pueden crear objetos o instancias de ella. La
ejecución de la aplicación se consigue mediante el envío de mensajes de unos objetos a

otros.
Puesto que, hoy en día, se emplea mayoritariamente el paradigma orientado a objetos, este
libro se centra casi exclusivamente en este.
1CWRUNICACIONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
ME 3.2.7. Prueba de integración

El objetivo de estas pruebas, que se realizan a continuación de las pruebas de unidad,
es comprobar si las clases de las que consta el software funcionan correctamente cuan-
do cooperan entre ellas con el objetivo de realizar las tareas encomendadas al programa.
Existen dos estrategias para las pruebas de integración en los sistemas orientados a ob-
jetos:
1. Prueba basada en hebra: integra el conjunto de clases requeridas para responder

a una entrada o evento del sistema. Cada hebra se integra y prueba de manera in-
dividual.
2. Prueba basada en uso: se comienza probando las clases independientes, esto es,
aquellas que usan muy pocas clases de servidor o ninguna. Después de probar
estas, se examina la siguiente capa de clases, llamadas clases dependientes, que
son utilizadas por las primeras. Esta secuencia de pruebas para las capas de cla-
ses dependientes continúa hasta que se construye todo el sistema.
ME 3.72.3. Prueba del sistema

Como indican Piattini et al. (2007), este tipo de prueba consiste en:
«el proceso de prueba de un sistema integrado de hardware y software para comprobar

si cumple con los requisitos especificados, los cuales son:
E Cumplimiento de todos los requisitos funcionales, considerando el producto

software final al completo, en un entorno de sistema.
E El funcionamiento y rendimiento de las interfaces hardware, software, de usuario

y de operador.
m Adecuación de la documentación de usuario.
E Ejecución y rendimiento en condiciones límite y de sobrecarga».
Es posible distinguir varios tipos de pruebas del sistema:
E Pruebas de recuperación: se fuerza al software a fallar y se verifica que la recupera-

ción se realice de manera adecuada. Este tipo de prueba debe aplicarse a aquellos
sistemas que deben ser tolerantes a fallos y en los que la recuperación debe reali-
zarse de manera rápida.
E Pruebas de seguridad: para algunos sistemas, por su naturaleza, es importante prote-

gerlos de acciones de personas que deseen realizar daños o que pretendan obtener
información confidencial. Las pruebas de seguridad intentan verificar que los meca-
nismos de protección del sistema lo protegerán contra accesos ilegales. Se trata de
que la persona que lleva a cabo la prueba «ponga en jaque» el sistema, intentando
conseguir contraseñas, provocando errores del sistema, etc. El objetivo es comprobar
el comportamiento del sistema antes estas situaciones y determinar en qué medida
la dificultad que supone el intento de penetración en el sistema no compensa los be-
neficios que pueda conseguir la persona que lo intenta penetrar.
3. DISEÑO Y REALIZACIÓN DE PRUEBAS |NFORMATÍCA / [r
E Pruebas de esfuerzo: en este tipo de prueba se trata de exponer al sistema a si-

tuaciones extremas para comprobar su comportamiento ante estas circunstancias,
que, aunque no sean las normales, pueden tener lugar en la vida real. Alguna de
las situaciones que se pueden plantear para realizar este tipo de pruebas son: eje-
cutar casos de prueba que requieran memoria máxima y otros recursos, que provo-
quen una búsqueda excesiva de datos residentes en disco, etcétera.
E Pruebas de rendimiento: se realizan con los sistemas para los que no es suficiente
el cumplimiento de una serie de requisitos funcionales, sino que también es nece-
sario que se cumplan ciertos requisitos de rendimiento, como que se dé respuesta
a un determinado evento en un tiempo limitado. Por lo tanto, están diseñadas para
probar el rendimiento del sistema.
E Pruebas de despliegue: también llamadas pruebas de configuración, estas se rea-

lizan cuando es necesario que la aplicación se ejecute en diversas plataformas y
sistemas operativos. Consisten en probar el funcionamiento del sistema en las di-
ferentes plataformas en las que se debe poder utilizar. Por ejemplo, en el caso del
desarrollo de una aplicación web, puede ser necesario probar su funcionamiento en
diferentes navegadores y en distintos sistemas operativos, incluyendo todas las po-
sibles combinaciones de navegador y sistema operativo.
ME 3.2.4. Prueba de validación

El objetivo de la prueba de validación, también llamada prueba de aceptación, es determi-
nar si el software es considerado válido por parte la persona usuaria y si está preparado
para su implantación en el entorno de las personas que lo vayan a usar.
La consideración de la validez del software se debe basar en una serie de criterios de

validación o aceptación previamente establecidos, que deben formar parte de la especi-
ficación de requisitos del software. Por ello, es muy importante que estos criterios de vali-
dación aparezcan de manera explícita en la ERS (especificación de requisitos del software).
Se ha de tener en cuenta que, según Piattini et al. (2007), la calidad del software se puede
definir como «la concordancia del software producido con los requisitos explícitamente es-
tablecidos, con los estándares de desarrollo expresamente fijados y con los requisitos im-
plícitos no establecidos formalmente, que desea el usuario». Es deseable que no existan
requisitos implícitos, es decir, no incluidos en la ERS, porque ello podría originar problemas
a la hora de considerar el software preparado para su entrega al cliente.
En este tipo de pruebas, participan activamente aquellas personas que lo van a utilizar,
las cuales, ayudadas por el equipo de pruebas, deben ejecutar las pruebas. Esta es la
fase final del proceso software, en la que la persona usuaria da su consentimiento para
su uso o explotación.
Todos estos tipos de pruebas se muestran en el modelo en V, que es una variante del
modelo en cascada. En su representación, los diferentes niveles de pruebas se colocan
formando una V (véase la Figura 3.1) para mostrar la relación de cada fase del ciclo de
vida con su fase de pruebas asociada.
“ MUN'CACIONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
MODELO EN V
Plan de la prueba
de aceptación
REQUISITOS PRUEBA DE ACEPTACIÓN
Plan de la prueba
del sistema
Plan de la prueba
de integración
CÓDIGO
Figura 3.1. Representación del modelo en V, en el que la fase posterior a la programación (las pruebas)
se divide en varias subfases que corresponden a las etapas del ciclo de vida en cascada, si bien las etapas
de análisis y diseño se dividen cada una de ellas en dos.
M 3.3. Técnicas de diseño de casos de prueba

Las técnicas de diseño de casos de prueba son las diferentes formas en que se pueden
generar casos de prueba para probar el software. Dependiendo del enfoque que se adop-
te, se puede aplicar uno de los dos siguientes tipos de técnicas de diseño de casos de
prueba (véase la Figura 1.10 de la Unidad 1):
1. Pruebas de caja blanca o pruebas estructurales: examinan los detalles de cada

módulo, para lo que se debe disponer del código fuente. A través de dicho código,
se prueban los diferentes caminos, los bucles, las variables, etcétera.
2. Pruebas de caja negra o pruebas funcionales: se considera al software como una

caja negra que recibe una serie de entradas y proporciona una serie de salidas. El
objetivo de estas pruebas es validar los requisitos funcionales.
No obstante, lo habitual es emplear los dos tipos de técnicas de diseño de casos de

prueba, pues se pueden combinar y complementar perfectamente.
Jot técnico
El nombre de estos dos tipos de pruebas está relacionado con la percepción del probador
acerca de la porción del software que prueba.
En el caso de las pruebas de caja negra, para la persona que prueba el software, este se
puede considerar una caja negra porque no es necesario conocer ningún detalle acerca de
este más que la función que realiza y, por tanto, la salida que genera a partir de la entrada
proporcionada.
3. DISEÑO Y REALIZACIÓN DE PRUEBAS |NFORMÁTICA Y ( NN
Sin embargo, en el caso de las pruebas de caja blanca, se parte del código fuente y, de su
examen, se derivan los casos de prueba. En este caso, sí es necesario, por consiguiente,
conocer el interior (el código fuente) del software que se somete a prueba. De hecho, las
pruebas de caja blanca también reciben el nombre de pruebas de caja de cristal porque el
interior del software debe ser visible para el probador.
A continuación, se presentan las distintas técnicas de diseño de casos de prueba y, por

último, se propone una estrategia para aplicar estas técnicas.
ME 3.3.1.Pruebas estructurales o de caja blanca

El objetivo de las pruebas de caja blanca es crear casos de prueba que permitan revisar
detalles internos del software. Así, de estas pruebas se derivan casos de prueba que:
1. Garantizan que todas las rutas independientes dentro de un módulo se revisaron

al menos una vez.
2. Revisan todas las decisiones lógicas en sus lados verdadero y falso.
3. Ejecutan todos los bucles en sus fronteras y dentro de sus fronteras operativas.
4. Revisan estructuras de datos internas para garantizar su validez.
Existen diferentes técnicas de diseño de casos de prueba de caja blanca, que se expo-
nen seguidamente.
BNNEN Prueba del camino básico

Esta técnica también recibe el nombre de prueba de ruta básica y fue propuesta por Thomas J.
McCabe. Esta técnica permite generar una métrica de la complejidad del módulo probado lla-
mada complejidad ciclomática de McCabe, que es un número entero que indica el número de
caminos independientes que hay en el código y, en consecuencia, el número de casos de prue-
ba que hay que ejecutar para garantizar que se recorren todas las sentencias del código al me-
nos una vez. Para calcular esta métrica y, en consecuencia, generar los casos de prueba, es
necesario representar el código fuente que se va a probar en un grafo de flujo.
Para crear un grafo de flujo, se deben llevar a cabo los siguientes pasos:
1. Se asigna un número único a cada sentencia del código y a cada condición.

No obstante, si se dispone de varias instrucciones en secuencia, es posible asig-
nar un número único a todas ellas y estas serán tratadas como un bloque. Cada
uno estos elementos (sentencia o grupo de sentencias en secuencia o condición)
constituirá un nodo del grafo de flujo, que se representará mediante un círculo en
cuyo interior aparecerá el número asignado.
2. Se unen los nodos mediante flechas llamadas aristas que representan el flujo de
control y son similares a las flechas de un diagrama de flujo. Se deben represen-
tar las estructuras básicas de programación tal y como se muestra en Figura 3.2.
AY COMUNICACIONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
Alternativa doble
Alternativa simple (If ... then ...
Secuencial (if ... then... endif) else ... endif)
L D 4Repetitiva de O an
(while ... do Repetitiva de 1 an
... end while) (repeat ... until ...)
Figura 3.2. Representación de los grafos de flujo para diferentes estructuras de control.
Una vez creado el grafo de flujo, se puede calcular la complejidad ciclomática de McCabe
V(G) de cualquiera de las tres formas siguientes:
E Número de regiones del grafo, considerando una región como una zona del grafo
cerrada. No obstante, también se debe considerar como región la región externa
(no cerrada).
E De acuerdo con la fórmula:
V(G)=A-N+2
donde A es el número de aristas del grafo, y N, el número de nodos.
E Según la ecuación:
VG) =NP+1
donde NP es el número de nodos predicados del grafo de flujo, es decir, el número

de nodos que contienen condiciones.
El valor V(G) indica el número de caminos independientes del grafo y, por tanto, el núme-
ro de casos de prueba que hay que generar para garantizar que se han recorrido todas
las instrucciones y condiciones del código.
El último paso de este método es generar casos de prueba que recorran cada uno de los ca-
minos, para lo que se deben elegir los datos de entrada que fuercen cada uno de esos cami-
nos. Puede ocurrir que alguno de los caminos no pueda recorrerse de manera independiente,
sino como parte de otro camino.
3. DISEÑO Y REALIZACIÓN DE PRUEBAS INFORMATICA Y (L
Para cada caso de prueba, se deben comparar los resultados obtenidos con los espe-
rados. La no coincidencia indicará la existencia de algún defecto y, en consecuencia, se
debe llevar a cabo un proceso de depuración.
Prueba del camino básico

En este ejercicio se aplica la prueba del camino básico a un método que lee una serie de
números hasta que se introduce un cero y muestra la media de los números positivos intro-
ducidos y la media de los números negativos.
Solución
La primera tarea que se debe a llevar a cabo es asignar un número entero a cada secuen-
cia de instrucciones y a cada condición:
begin
int num = 0, cont pos=0, cont neg=0, suma pos=0, suma neg=0;
2 float neg=
media pos=0,med ia 0;
System.out .print (“Introduce número: “);

num=Entrada.entero();
while
if
cont
_ pos++;
else
cont_neg++;
suma neg+=num;
endif;
System.out
.print (“Introduce número: “);
G
num=Entrada .entero();
1f ((cont_pos l= 0))
media 00s = (float)suma pos/cont pos;
System.out .printin ( “Media de los positivos: “+ media_pos);]
if (( cont_neg !=0 ))
[media_neg= (£loat) suma neg/cont neg;
System.out .printin ( “Media de los negativos: “+ media_neg);]

endif;
end; >
* * /XAUN'CAGONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
Es posible incluir dentro un mismo nodo varias instrucciones en secuencia, como es el

caso de las instrucciones incluidas dentro del nodo 1. También se puede incluir, dentro
del mismo nodo, la instrucción que indica el fin de una instrucción condicional y la instruc-
ción o las instrucciones siguientes en secuencia, como se ha hecho para el nodo 6. Asi-
mismo, es posible incluir, dentro de un mismo nodo, la instrucción que indica el fin de una
estructura repetitiva junto con las instrucciones anteriores dentro del bucle si son instruc-
ciones en secuencia. Por este motivo, aunque no se ha hecho, también se podrían haber
incluido en el mismo nodo las instrucciones asignadas a los nodos 6 y 7.
El siguiente paso es construir el grafo de flujo de acuerdo con las estructuras mostradas
en la Figura 3.2. El grafo de flujo quedaría como el que se muestra en la Figura 3.3. En el
grafo, se han marcado en rojo los nodos predicados y se ha asignado un número a cada
región en color azul.
Figura 3.3. Grafo de flujo correspondiente al código de esta actividad.
Una vez que se tiene el grafo de flujo, ya se puede calcular la complejidad ciclomática,
V(G), de las tres formas que se ha indicado antes:
V(G)
= número de regiones
= 5
VWG)=A-N+2=16-13+2=5
VG)=NP+1=4+1=5
Como V(G) toma el valor 5, se deduce que hay cinco caminos independientes en el códi-
go examinado y, por tanto, el número de casos de prueba que hay que crear para cubrir
todas las instrucciones y condiciones del programa es 5. La siguiente tarea es encontrar
esos cinco caminos independientes. Para ello, hay que tener en cuenta que cada camino
independiente incluye una ruta nueva en relación con los anteriores:
3. DISEÑO Y REALIZACIÓN DE PRUEBAS INFORMÁTICA Y (L
Camino 1: 1-2-8-10-11-13
Camino 2: 1-2-3-4-6-7-2-8-10-11-13
Camino 3: 1-2-34-6-7-2-8-9-10-11-13
Camino 4: 1-2-3-5-6-7-2-8-10-11-13
Camino 5: 1-2-3-5-6-7-8-10-11-12-13
Con objeto de probar el camino 1, se debe introducir como primer número el O con el
fin de que no se entre en el bucle ni una sola vez y se pase directamente del nodo 2 al
nodo 8. En este caso, el programa no debe mostrar nada, ya que no se ha introducido nin-
gún número ni positivo, ni negativo.
El camino 2 no se puede probar como tal, ya que al introducir un número positivo (para
pasar por el nodo 4), se debería pasar por el nodo 9, que muestra la media de los núme-
ros positivos. Por consiguiente, este camino debe probarse como parte de otro.
Para probar el camino 3, hay que suministrar al programa, en primer lugar, un número po-
sitivo (para pasar por el nodo 4), por ejemplo, el número 8, y un O a continuación (para no
pasar más por el bucle). El programa deberá indicar que la media de los números positi-
vos es 8. Al probar el camino 3, ya se prueba el camino 2 como parte de él.
El camino 4 tampoco se puede probar como tal, pues al introducir un número negativo
(para pasar por el nodo 5), se debe pasar por el nodo 12 para mostrar la media de los nú-
meros negativos.
Por último, a fin de probar el camino 5, se debe suministrar al programa un número ne-
gativo (para pasar por el nodo 5), por ejemplo, el —4, y un 0 a continuación. El programa
deberá indicar que la media de los números negativos es —4. Al probar el camino 5, se
prueba también el camino 4 como parte de él.
Para cada caso de prueba, se comprueba que el resultado mostrado coincide con el espe-
rado, de forma que la no coincidencia indicará la existencia de algún defecto, por lo que
habrá que proceder a detectar y corregir dicho error (mediante un proceso de depuración).
La complejidad ciclomática de McCabe es una métrica de la complejidad del módulo pro-

bado. Así, cuando V(G) es mayor que 10, la probabilidad de defectos en el módulo o en
el programa crece bastante si dicho valor alto no se debe a sentencias case o similares.
En estos casos, es recomendable replantearse el diseño modular obtenido, de modo que
sería conveniente dividir el módulo complejo en varios módulos para reducir la compleji-
dad del software.

Prueba del camino básico
El siguiente programa escrito en Java pide un número entero por teclado e indica si
es un número perfecto, es decir, si es igual a la suma de sus divisores propios. Un
divisor propio es un entero positivo distinto del número en sí mismo y que divide al
número de forma exacta, es decir, sin resto. >
A f (OMUNICACIONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
Construye el grafo de flujo para este programa y calcula su complejidad ciclomáti-

ca. Además, indica un conjunto de caminos independientes y, para cada camino,
el caso de prueba correspondiente, incluyendo la entrada proporcionada y la salida
esperada.

2 int num, divisor, sumadivisores;
3 divisor =
4 sumadivisores = 0; a
5 Scanner entrada = new Scanner (System.in);
6 System.out .print (“Introduzca un número mayor que 0: “);
7 num = entrada.nextInt();
8 while (divisor <= num/2)
9 ( if (num % divisor == 0)
10 sumadivisores = sumadivisores + divisor;
ual divisor++;
12 )
13 if (num == sumadivisores)
14 System.out .printin (“El número “ + num + “ es un número
perfecto”);
15 else
16 System.out .printin (“El número “ + num + “ no es un número
perfecto”);
7
M ENE Prueba de bucles

Los bucles o estructuras repetitivas constituyen una estructura de control fundamen-
tal en todo lenguaje de programación. La prueba de bucles se centra exclusivamente en
este tipo de estructuras. Los casos de prueba que se deben generar para cada tipo de
bucle son los siguientes:
E Bucles simples: si el número máximo de iteraciones por el bucle es n, se deben pro-

bar los siguientes casos:
— Saltarse completamente el bucle.
— Realizar una iteración por el bucle.
— Realizar dos iteraciones por el bucle.
— Realizar m iteraciones por el bucle, siendo m < n.
— Realizar n-1, n y n+1 iteraciones por el bucle.
E Bucles anidados: se deben llevar a cabo los siguientes pasos:

1. Comenzar por el bucle más interno, estableciendo valores mínimos para todos
los demás bucles.
2. Realizar pruebas de bucle simple para el bucle más interno, manteniendo los
bucles exteriores en sus valores mínimos.
3. DISEÑO Y REALIZACIÓN DE PRUEBAS |NFORMÁT'CA Y CON
3. Trabajar de fuera hacia dentro y probar el siguiente bucle manteniendo los otros
bucles exteriores en valores mínimos y los otros bucles interiores en valores tí-
picos.
4. Continuar hasta que se hayan probado todos los bucles.
E Bucles concatenados: si los bucles son independientes unos de otros, se pueden

probar empleando la estrategia indicada para los bucles simples. Si los bucles con-
catenados son dependientes porque el segundo bucle usa el contador del primer
bucle como valor inicial para el segundo, se recomienda emplear el enfoque aplica-
do a los bucles anidados.
M EE Prueba de flujo de datos

Esta técnica de diseño de casos de prueba selecciona caminos de un programa de
acuerdo con las ubicaciones de las definiciones y usos de variables en dicho programa.
Aquí es necesario considerar que, en una instrucción, se define una variable si se le asig-
na valor, mientras que se puede afirmar que esa variable se usa si se consulta o utiliza
su valor de algún modo. Así, en una condición, siempre se usan una o varias variables.
Si se asigna el número / a una instrucción, el conjunto DEF para esa instrucción / estará
formado por el conjunto de variables que se definen en esa instrucción. Su conjunto USO
estará formado por el conjunto de variables cuyo valor se usa en esa instrucción. Esto
quedaría ilustrado así:
DEF(1) = (X | 1 contiene una definición de X)
USO(1) = (X | 1 contiene un uso de X)

La definición de una variable X en la instrucción | está viva en la instrucción /' si hay un
camino entre las instrucciones / e /” que no contiene ninguna otra definición de X.
Mediante esta técnica, se encuentran las cadenas DU para una variable. Estas cadenas
tienen la forma /X, 1, 1'], donde X es una variable, / e / son instrucciones tal que X está en
DEF(1) y en USO(1), y la definición de X en ! está viva en /” porque existe algún camino en-
tre / e / que no incluye ninguna otra definición de X.
Argot técnico
Las cadenas DU de esta técnica reciben este nombre porque se trata de cadenas de
definición-uso, más concretamente, cadenas en las que primero se define una variable
y luego se usa esa misma variable sin que haya entre la instrucción donde se define y la
instrucción donde se usa ninguna otra definición de la variable.
Debido a que el objetivo es encontrar cadenas DU, esta técnica también recibe el nombre de
prueba DU.
Esta técnica requiere llevar a cabo los siguientes pasos:
1. Asignar un número a cada instrucción y condición de un programa.

f íOMUNICACIONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
2. Calcular el conjunto DEF y USO para cada variable que se usa en ese programa.
3. Encontrar las cadenas DU para todas las variables.
4. Generar el número mínimo de casos de prueba que incluyan caminos para todas
las cadenas DU.
5. Generar datos de entrada que fuercen cada uno de los caminos encontrados en el
paso anterior.

A
Solución
El primer paso ya está hecho porque ya se ha asignado un número a cada instrucción y

condición.
Seguidamente, se calculan las cadenas DU solo para la variable num. A tal fin, se definen
los conjuntos DEF y USO para esta variable. Como se puede observar, la variable num se
define en las instrucciones 1 y 6, mientras que se usa en las que tienen asignados los
números 2, 3, 4 y 5. Esto se indica del siguiente modo:
DEF(1) = (num)
USO(2) = fnum)
USO(3) = fnum)
USO(4) = fnum)
USO(5) = fnum)
DEF(6) = (num)
El siguiente paso es buscar las cadenas DU para esta variable, que son las siguientes
numeradas:
DU [fnum, 1, 2] (1)
DU [num, 1, 31 (2)
DU [num, 1, 4] (3)
DU [num, 1, 5] (4)
DU [num, 6, 2] (5)
DU [num, 6, 3] (6)
DU [num, 6, 4] (7)
DU [num, 6, 5] (8)
A continuación, se debe encontrar el número mínimo de caminos que incluyan todas las
cadenas DU. Estos caminos son: >
3. DISEÑO Y REALIZACIÓN DE PRUEBAS |NFORMÁTICA y ();
E Camino 1: 1-2-3-4-6-7-2-3-4-6-7-2-3-5-6-7-2-8-9-10-11-12-13. Este camino cubre las

cadenas DU: (1), (2), (3), (5), (6), (7) y (8)-
El Camino 2: 1-2-3-5-6-7-2-8-10-11-12-13. Este camino cubre la cadena DU (4).
En este caso, con dos caminos es suficiente para cubrir todas las cadenas DU encontra-
das. En la primera iteración del bucle del camino 1, se cubren las cadenas DU (1), (2) y
(3); en la segunda iteración, se cubren las cadenas DU (5), (6) y (7) y, en la tercera itera-
ción, se cubre la cadena DU (8). Pero, en el camino 1, no es posible cubrir la cadena DU
con el número (4), es decir, DU [num, 1, 5] porque por el nodo 1 solo se pasa una vez. En
las iteraciones, no se puede pasar por los nodos 4 y 5 a la vez y, para volver a uno de los
nodos 4 0 5, hay que pasar por el nodo 6, que contiene otra definición de la variable num.
Por este motivo, hay que establecer otro camino para cubrir esta cadena DU.
Ya solo quedaría generar los datos de entrada para recorrer cada uno de estos dos cami-
nos. Para el camino 1, habría que introducir en el programa dos números positivos, luego
uno negativo y un cero para finalizar. Por ejemplo, si se suministra un 4, un 8 y un —9, el
programa nos debe indicar que la media de los números positivos es 6 y la de los nega-
tivos, —9. Para forzar el camino 2, habría que introducir en el programa un número nega-
tivo y un cero para finalizar. Si, por ejemplo, se proporciona como entrada el número —10
y luego un 0, el programa debe indicar que la media de los números negativos es —10.

Prueba de flujo de datos
Tomando el programa de la Actividad propuesta 3.1, obtén las cadenas DU para la
variable sumadivisores y encuentra el número mínimo de caminos de prueba que
recorren todas estas cadenas.
ME 3.3.2. Pruebas funcionales o de caja negra

El objetivo de las pruebas de caja negra es crear casos de prueba que permitan revisar
todos los requisitos funcionales de un programa. A tal efecto, existen diferentes técnicas
de diseño de casos de prueba de caja negra que se exponen a continuación.
M EN EN Particiones o clases de equivalencia

Por medio de esta técnica, se identifican un conjunto de clases de equivalencia o tipos
de valores que se deben asignar a los datos de entrada. El primer paso para identificar
las clases de equivalencia es determinar las condiciones de entrada del programa. Una
condición de entrada puede ser:
E Un valor específico.
E Un rango de valores permitido, por ejemplo, entre 18 y 65.
E Un conjunto de valores permitidos, por ejemplo, 18, 36 y 72.

jÍ¡'/kx Y COMUNICACIONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
E Una condición lógica o booleana, por ejemplo, es español o no es español.
Hay una serie de reglas que ayudan a identificar las clases de equivalencia en función
del tipo de la condición de entrada:
E Si la condición de entrada es un valor específico, se debe crear una clase válida

(con ese valor) y dos no válidas (con dos valores distintos).
E Si la condición de entrada consiste en un rango de valores permitidos (por ejemplo,

un número entre 18 y 65), se debe crear una clase válida (18 < número < 65) y dos
no válidas (número < 18 y número > 65).
E Si la condición de entrada consiste en un conjunto de valores permitidos y se sabe

que el programa trata de manera diferente cada uno de ellos (por ejemplo, el idio-
ma es inglés, francés o italiano), se identifica una clase válida por cada valor (en
este caso, tres valores) y una clase no válida (por ejemplo, alemán).
E Si la condición de entrada consiste en una condición lógica (por ejemplo, la perso-

na debe tener nacionalidad española), se identifica una clase de equivalencia válida
(es española) y otra no válida (no es española).
E Si se sabe que algunos elementos de una clase no se tratan de igual forma que el
resto de sus elementos, debe dividirse dicha clase de equivalencia en varias clases
menores.
Para la creación de los casos de prueba, una vez conocidas estas reglas, se llevan a
cabo los siguientes tres pasos:
1. Asignar un número único a cada clase de equivalencia.
2. Crear el número mínimo de casos de prueba que incluyan todas las clases
válidas.
3. Crear un caso de prueba por cada clase no válida. El caso de prueba debe incluir
una clase no válida, y todas las demás clases deben ser válidas.
Actividad resuelta 3
Solución
En la Tabla 3.1, se muestran las condiciones de entrada y, por cada una de ellas, las cla-
ses válidas y las no válidas, numerándose cada una de ellas. >
/ A
3. DISEÑO Y REALIZACIÓN DE PRUEBAS INFORMAT¡CA Y 'í,¡'.…w“'
Tabla 3.1. Condiciones de entrada para el supuesto, junto con las clases de equivalencia
válidas y no válidas de acuerdo con las normas especificadas
Condición — Clases Clases

de entrada í válidas no válidas
Edad 1 18 <edad <65 (1) : edad<18(2)
: edad> 65(3)
: No es un número (4)
NIF Una cadena de 9 caracteres compues- < 9 caracteres (6)
i : ta por 8 números y una letra (5) : > 9 caracteres (7)
: Alguno de los 8 primeros caracteres
: no es un número (8)
: El último carácter no es una letra (9)
Nacionalidad Española (10) No española (11)
En la Tabla 3.2, se muestran los casos de prueba válidos y, en la Tabla 3.3, los no váli-
dos. Por cada caso de prueba, se indica, en la última columna, las clases de equivalencia
incluidas. Recuerda que, para el caso de las clases válidas, se debe crear el número mí-
nimo de casos de prueba que incluyan todas las clases válidas; en este caso, se requie-
re un único caso de prueba.
Tabla 3.2. Caso de prueba con clases de equivalencia válidas
Nacionalidad Clases incluidas
: Española (1),(6), (10)

Para las clases no válidas, hay que crear un caso de prueba por cada una de ellas. Como
se puede observar en la Tabla 3.1, al haber 8 clases de equivalencia no válidas, se deben
crear 8 casos de prueba (Tabla 3.3).
Tabla 3.3. Casos de prueba con clases de equivalencia no válidas
_ _ Nacionalidad Clases incluidas
116 E 787876547 : Española (2),(5), 10)

7388788888UE3pan0la(3)(5)(10) .................................
A355337433Y|53pano|a(4)(5)(10) .................................
45 ...................879847FEspanola (1)(5)(10) ..................................
23 57s757s752a ............. Espan0Ia ............................... …(7)(10) .................................
64mggoogn ................. Españo|a(1)(8)(10) ................................. ;
19569832349E3pan0]a(1)(9)(10) .................................
2398323232c ................. Noespanºla()(5)(11) .................................
W»" 10M[.HXHCIAX(:IO'XIES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS

Prueba de particiones o clases de equivalencia
La consejería de sanidad de una región desea crear una aplicación para posibilitar la soli-
citud de citas previas de los pacientes con sus médicos. Los datos que deben introducir
los pacientes para acceder a esta aplicación son:
a) Número de tarjeta sanitaria (TIS): debe ser un número entero de 8 dígitos.
b) Primer apellido: debe ser una cadena de entre 2 y 30 letras, pudiendo incluir algún
espacio en blanco.
C) Año de nacimiento: debe ser un número entero entre 1901 y el año actual.
Crea una tabla de clases de equivalencia. Además, genera los casos de prueba corres-
pondientes usando la técnica de particiones o clases equivalencia, indicando en cada
caso las clases cubiertas.
M ENE Análisis de valores límite

Se trata de una técnica de diseño de casos de prueba complementaria a la de clases de
equivalencia. Las diferencias que presenta con relación a esta son:
E En vez de seleccionar cualquier elemento dentro de una clase de equivalencia, se

selecciona aquel o aquellos que se hallan justo en los límites de la clase.
E En vez de centrarse únicamente en las condiciones de entrada, en esta técnica, los

casos de prueba se generan teniendo en cuenta también el dominio de salida.
Las reglas que se siguen para generar los casos de prueba son las siguientes:
1. Si una condición de entrada especifica un rango de valores, por ejemplo, entre —5

y 10, se deben generar casos válidos para los extremos del rango (-5 y 10) y ca-
sos no válidos justo más allá de los extremos (-5,01 y 10,01, en caso de que se
admitan dos decimales).
2. Si una condición de entrada especifica un número de valores (entre 1 y 100), hay
que generar casos de prueba para los valores mínimo y máximo (1 y 100), uno
menos que el mínimo (0) y uno más que el máximo (101).
3. Se emplea la regla 1 para cada condición de salida que especifique un rango

de valores. Si, por ejemplo, el salario mínimo es 1.200,00 € y el máximo es
3.600,00 €, se deben generar casos de prueba que den como resultado salarios
de 1.200,00 €, 3.600,00 €, 1.199,99 € y 3.600,01 €.
4. Se usa la regla 2 para cada condición de salida que especifique un número de va-
lores. Si, por ejemplo, el programa especifica que se puede hacer uso de uno a
tres descuentos, habrá que generar casos de prueba para lograr cero, uno, tres y
cuatro descuentos.
5. Si la entrada o salida de un programa es un conjunto ordenado (por ejemplo, una

tabla o un archivo secuencial), los casos de prueba se deben centrar en el primer
y último elemento.
3. DISEÑO Y REALIZACIÓN DE PRUEBAS INFORMAT¡CA Y 'í _xl

Prueba de análisis de valores límite
Partiendo de la condición de entrada edad de la Actividad resuelta 3.3, indica qué clases
de equivalencia adicionales habría que crear, y genera los casos de prueba correspon-
dientes empleando la técnica de análisis de valores Iímite.
Solución
Dado que esta condición de entrada especifica un número de valores (entre 18 y 65), hay
que generar clases de equivalencia para los valores mínimo y máximo (18 y 65), uno me-
nos que el mínimo (17) y uno más que el máximo (66), como se muestra en la Tabla 3.4,
en la que se ha asignado a las clases de equivalencia una numeración que sigue la de la
Actividad resuelta 3.3:
Tabla 3.4. Clases de equivalencia válidas y no válidas para la condición de entrada edad
empleando la técnica de análisis de valores límite
Condición Clases Clases

de entrada válidas no válidas
: Edad i edad=18(12) - edad=17 (14)
f + edad=65 (13) + edad=66 (15)
Una vez generada estas clases de equivalencia adicionales, se trata de generar los casos
de prueba que abarquen estas clases. Para ello, se debe tener en cuenta que hay que
generar un caso de prueba válido que abarque todas las clases válidas. Como, en este
caso, para la edad, hay dos clases válidas, se deben generar dos casos de prueba váli-
dos (véase Tabla 3.5). A la edad, se deben añadir las otras condiciones de entrada que
se incluyeron en la Actividad resuelta 3.3.
Tabla 3.5. Casos de prueba con clases de equivalencia válidas que se generan empleando la
técnica de análisis de valores límite
i i Nacionalidad Clases incluidas

118 : 32323267G : Española (12),(5), (10)
65 - 323232676 - Española -(13),5), 10)
Hay que generar, además, un caso de prueba nuevo por cada clase no válida. Como se
han añadido dos nuevas clases no válidas, se generará un caso de prueba no válido por
cada una de ellas (Tabla 3.6).
Tabla 3.6. Casos de prueba con clases de equivalencia no válidas que se generan empleando
la técnica de análisis de valores límite
Nacionalidad Clases incluidas

]MUNICAGONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
M EN Conjetura de errores
Esta técnica consiste en generar una lista de errores que suelen cometer quienes desa-
rrollan aplicaciones y de las situaciones que suelen dar lugar a dichos errores, para lue-
go generar un conjunto de casos de prueba basándose en esta lista. Se trata de errores
que se cometen comúnmente y no relacionados con aspectos funcionales.
Se muestran a continuación una serie de ejemplos típicos que reflejan el empleo de esta
técnica:
E El valor O tanto en la entrada como en la salida es una situación propensa a que se

cometan errores.
E En situaciones en las que se introduce un número variable de valores, como por

ejemplo una lista, conviene considerar los siguientes casos: no introducir ningún va-
lor, introducir un solo valor y un conjunto de valores en el que todos son iguales.
E La usuaria o usuario de la aplicación puede introducir datos erróneos, por ejemplo,

que en un campo numérico introduzca algún carácter no numérico.
E La persona encargada de la programación pueda haber interpretado incorrectamen-

te algo en la especificación.
ME 3.3.3. Estrategia de aplicación de las técnicas de diseño

de casos de prueba
El proceso de prueba de una aplicación completa se debe ejecutar de acuerdo con los si-
guientes pasos:
E Se comienza realizando la prueba de unidad de cada clase. Se puede comenzar con

la técnica de análisis de valores límite, añadir clases válidas y/o no válidas no con-
templadas con la técnica de clases de equivalencia y finalizar con la técnica de con-
jetura de errores.
E Si no se ha alcanzado la cobertura deseada (por ejemplo, el recorrido de todos los

posibles caminos a lo largo del código fuente), se deben añadir los casos necesa-
rios mediante técnicas de pruebas de caja blanca (es decir, la prueba del camino
básico, la de bucles y la de flujo de datos).
E Se continúa con las pruebas de integración, aunque también se pueden combinar

estas con pruebas de unidad. Las pruebas de integración se deben centrar en la
comprobación de los mecanismos de interacción entre las diferentes clases y se
deben usar preferentemente técnicas de caja blanca. Se debe ir incrementando pro-
gresivamente el alcance de estas pruebas hasta abarcar el software completo.
E La prueba del sistema debe emplear casos de prueba de caja negra para compro-
bar el cumplimiento de los objetivos requeridos por el sistema.
E En la prueba de validación, deben tomar parte las personas usuarias finales y se

pueden reutilizar casos de prueba del sistema. La finalización exitosa de estas
pruebas supone la aceptación final del software por parte del usuario o usuaria.
3. DISEÑO Y REALIZACIÓN DE PRUEBAS INFORMATICA Y G3/M
Recuerda
Una buena estrategia de prueba debe combinar los dos tipos de técnicas de diseño de
casos de prueba estudiadas (pruebas de caja blanca y de caja negra) para lograr la cobertura
deseada.
E 3.4. Documentación de las pruebas

La documentación de las pruebas es conveniente para una buena organización de estas
y para asegurar su reutilización. Se deben documentar tanto el diseño de las pruebas
como el resultado o ejecución de las pruebas.
En cuanto a la documentación del diseño de las pruebas, es conveniente crear los si-
guientes documentos:
E Plan de pruebas: es un documento con la planificación general de las pruebas

para la aplicación que se está creando. Se debe indicar el enfoque general de las
pruebas, los recursos requeridos, las actividades de pruebas que se van a llevar
a cabo, los elementos que se deben probar, el personal responsable y los riesgos
asociados.
E Especificación del diseño de las pruebas: es un informe que detalla el plan de prue-
bas porque en él se indica cada uno de los elementos concretos que se van a pro-
bar y los procedimientos de prueba. A partir de este documento se generan los
siguientes:
— Especificaciones de casos de prueba: por cada prueba que se va a realizar, se de-

ben indicar los datos de entrada que se van a suministrar, los resultados espera-
dos y las dependencias entre casos de prueba.
— Especificaciones de procedimientos de prueba: especifica los pasos para la ejecu-

ción de uno o de un conjunto de casos de prueba. En este documento, se deben
indicar la lista de casos de prueba correspondientes al procedimiento, los requi-
sitos para la ejecución de los casos de prueba (entorno, personal, etc.) y los pa-
sos del procedimiento.
En cuanto a la documentación de la ejecución de las pruebas, esta es importante para la efi-

cacia en la detección y corrección de defectos y para dejar constancia de los resultados de
las pruebas. La ejecución de las pruebas toma como entrada las especificaciones de los
casos de prueba que se van a usar y las especificaciones de los procedimientos de prueba,
y debe generar dos tipos de documentos:
1. Histórico de pruebas: registra todos los hechos relevantes ocurridos durante la eje-
cución: elementos probados, entorno de pruebas, resultados obtenidos, fecha y

hora y referencia al informe de incidentes, si es el caso.
2. Informe de incidentes: registra cada incidente ocurrido durante la prueba que re-
quiera una posterior investigación.
.' !X*. Yl [OMUNICACIONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
La ejecución de las pruebas correspondiente a cada especificación del diseño de las

pruebas genera asimismo un informe resumen de pruebas, que incluye: resumen de la
evaluación de los elementos probados, variaciones del software como resultado de las
pruebas, valoración de la cobertura de la prueba, resumen de los resultados obtenidos y
resumen de las actividades de prueba (incluyendo el consumo de recursos).
Especificación del
diseño de las pruebas
Figura 3.4. El plan de pruebas es un documento único para una aplicación con indicaciones generales acerca
de las pruebas. Este se desglosa, por cada elemento que se va a probar, en varias especificaciones del diseño
de las pruebas. Cada uno de estos documentos contiene además varias especificaciones de casos de prueba
y varias especificaciones de procedimientos de pruebas.
Informe
de incidente
Figura 3.5. Se parte de una especificación del diseño de las pruebas y, por cada ejecución de estas, a partir
de una serie de casos de pruebas y sus procedimientos, se genera un histórico de pruebas con todos
los hechos relevantes ocurridos durante esas pruebas y un informe por cada incidente ocurrido.
Todo ello se recoge en el informe resumen de pruebas.
La valoración de los procesos de prueba es importante porque puede ayudar en pro-

yectos posteriores. Por ello, es conveniente realizar un análisis causal, cuyo objetivo es
3. DISEÑO Y REALIZACIÓN DE PRUEBAS |NFORMÁTICA Y ( N
proporcionar información sobre la naturaleza de los defectos encontrados. Por cada de-
fecto encontrado, se debería registrar la siguiente información: cuándo se cometió, quién
lo cometió, qué se hizo mal, cómo se podría haber evitado, por qué no se detectó antes,
cómo se podría haber detectado antes y cómo se encontró el error.
El objetivo del análisis causal es formar al personal sobre los errores cometidos para
que se puedan prevenir en el futuro. La información generada se puede emplear para
predecir los fallos futuros del software.
M 3.5. Herramientas de depuración

La depuración es la tarea que hay que realizar tras una prueba exitosa, es decir, tras una
prueba que detecta un fallo 0, más bien, el síntoma de un defecto. En ese caso, lo que
se hace es localizar el defecto en el software y corregirlo, proceso que se conoce con el
nombre de depuración.
A veces, la localización del defecto es una tarea sencilla, pero otras veces, no tanto, y
para ello, pueden resultar útiles las herramientas de depuración que proporcionan los en-
tornos de desarrollo. Puede ocurrir incluso que para la detección del defecto sea necesa-
rio crear nuevos casos de prueba.
Una vez detectado el defecto, habrá que corregirlo y tener en cuenta que, al llevar a cabo
las modificaciones que supuestamente corregirán el fallo, se pueden introducir nuevos
defectos, por lo que será conveniente ejecutar pruebas de regresión, esto es, se repeti-
rán los casos de prueba que se ejecutaron antes de las modificaciones para estar segu-
ros de que los cambios no hayan originado nuevos defectos en el software.
A modo de ejemplo, aquí se verá cómo el depurador o debugger del IDE Eclipse asiste en
esta tarea a las personas que desarrollan software. Grosso modo, las ayudas que propor-
ciona esta herramienta son las siguientes:
E Ejecuta el código paso a paso.

E Establece puntos de ruptura o interrupción para que el código se ejecute hasta
esos puntos sin ejecutarse paso a paso.
E Suspende la ejecución del programa.
E Examina los valores de las variables a lo largo de la ejecución.
Para ejecutar un programa en modo depuración, se puede realizar cualquiera de las si-
guientes acciones:
E Activar la opción de menú Run > Debug.

m Seleccionar la clase que se desea ejecutar y, en el menú contextual, elegir la opción
Debug As > Java Application.
M Hacer clic en el icono % y seleccionar la opción Debug As > Java Application.
Es conveniente también abrir la vista depuración seleccionando la opción de menú

Window > Perspective > Open Perspective > Debug. Aparecerá entonces una pantalla
como la que se muestra en la Figura 3.6.
| lr (»OMUNICACIONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
Eile Edit Source Refactor Navigate Search Project Pydev Run Window Help
e -OO| NAN ELOAPIVIF-0-0-Q-185
-P IFETIO-A-eve-5-14 ARE
- Q Signin
+5 Debug x E Project Explorer = 6 [NotaMediajava X = l (;)Variables X % Breakpoints 6 Expressions = (=)
=1 2 s s S, ; ER A EE :
4 7 NotaMedia [Java Application] 23 notas[contador] = teciado.nextInt(): Name Value
4 E programas.NotaMedia at localhost:53248 2 » E* no method return val
4 P Thread [main] (Suspended (breakpoint at line34ir — 25 teclado.close(): 4 6 notas (id=20)
= NotaMedia.calcularNotaMedia(nt[]) line:34 2 return notas; = 10
= NotaMedia.main(String[]) lne: 12 2 a m
»E CaProgram FilesVavaljdk-16.0.2bin javaw.exe (16fe _2E a ]
private static double calcularNoraMedia (int[] notas) (
ha variable para almacenar la suma de las notas a Bl
a ]
ray para sumar codas las notas a 15)
= 0; Eontador < nota=.lengrh: ++668tadoz) 4 Í:]]
a
a nora medía como el resultado de dividir la suma al a [8]
notas entre el número de notas*/ a 19
float media = (float) suma/notas.length: a ol
return media; a m
» a 12
<
El Console X [E] Problems (1) Debug Shell XZ|
NotaMedia [Java Application] CAProgram FilesVavajdk-16.0.Abin javaw.exe (16 feb 2022 20:18:17)
Introduzca una nota: Ú
Introduzca una nota: £
Introduzca una nota:
Figura 3.6. Vista Depuración mientras se está ejecutando una aplicación en modo de depuración.
En esta pantalla, es posible distinguir las siguientes áreas:
E Área de depuración o debug: esta área se encuentra a la izquierda y en ella se

muestran los hilos de ejecución del programa que se está ejecutando, en este
caso, solo uno. Se indica la línea en la que está parada la ejecución del programa.
E _ Área de edición: situada en la parte central, en ella se muestra el código fuente del
programa que se está ejecutando.
E Área de consola: esta se encuentra en la parte inferior, donde se muestra el resul-

tado de la ejecución del programa.
E Área de inspección: se ubica a la derecha y dispone de varias pestañas. En la pes-

taña Variables, se muestran los valores de las variables a lo largo de la ejecución
del programa. Estos valores se pueden modificar simplemente cambiando el valor
en la columna Value. En la pestaña Breakpoints, se pueden ver los puntos de ruptu-
ra creados, que se pueden editar (eliminar, añadir nuevos puntos de ruptura, etc.).
Por último, en la pestaña Expressions, se pueden escribir expresiones en la colum-
na Name y ver su valor a lo largo de la ejecución del programa en la columna Value.
En modo depuración, al hacer clic en la opción de menú Run, aparecen nuevas opciones,
algunas de las cuales se explican a continuación:
E Resume (o tecla F8): reanuda un hilo suspendido ejecutando instrucciones de este

hasta llegar a un punto de ruptura.
E Suspend: suspende el hilo seleccionado.
E Terminate (o teclas Ctrl + F2): termina el proceso de depuración.
E Step into (o tecla F5): ejecuta el código paso a paso. En caso de que en el código
haya una llamada a un método, también se ejecutará paso a paso cada instrucción
de este.
E Step over (o tecla F6): ejecuta el código paso a paso, pero en caso de que en el códi-
go haya una llamada a un método, el código del método no se ejecutará paso a paso.
3. DISEÑO Y REALIZACIÓN DE PRUEBAS INFORMATICA Y (0IM '
Step return (o tecla F7): si la ejecución está dentro de un método, el depurador sale
del método en cuestión.
Run (o teclas Ctrl + F11): ejecuta el programa normalmente.
Debug (o tecla F11): ejecuta el programa en modo depuración.
Skip all breakpoints (teclas Ctrl + Alt + B): se saltan todos los puntos de ruptura
como si estos no existiesen.
Remove all breakpoints: elimina todos los puntos de ruptura.
Add Java exception breakpoint: permite añadir una excepción como punto de ruptura.
A continuación, se ofrece un ejemplo de uso del depurador a partir del código que se expo-
ne abajo, por medio del cual, se crea un array de 15 números que representan las notas
(números enteros) obtenidas por 15 alumnos. Se usa el método /eerNotas para leer por te-
clado las 15 notas e introducirlas en el array y el método calcularNotaMedia para leer to-
das las notas y calcular la nota media, que es mostrada por pantalla en el método main.
package programas;
(NH
import java.util.Scanner;
public class NotaMedia (
public static void main(String[] args) f
ooJatuH.s
int [] notas new int [15]; //Declaramos el array

II
//Llamamos al método leerNotas para leer las notas por teclado

notas = leerNotas|();
//Llamamos al método que calcula la nota media
System.out .printin (“La nota media es un “ +
v
calcularNotaMedia
(notas) ) ;
)
WNHOao
private static int[] leerNotas() (f

H HH
int [] notas new int [15]; //Declaramos el array

II
//Creamos un objeto de tipo Scanner para leer datos por

teclado
Scanner teclado = new Scanner (System.in);
audkr
for (int contador = 0; contador < notas.length; ++contador) (

HA
System.out .print (“Introduzca una nota: “);

/*Leemos un número entero por teclado y lo almacenamos
H
<
en la posición contador del array*/

notas [contador] = teclado.nextInt();
mNNI=—NEENNE.H.HH
WmnNn",Heokwoo
)
teclado.close();
return notas;
)
private static double calcularNotaMedia

(int [] notas) (
//Declaramos una variable para almacenar la suma de las notas
.
int suma = 0;
au
//Recorremos el array para sumar todas las notas

for (int contador = 0; contador < notas.length; ++contador)
B
J
Í;/K'v. Y COMUNICACIONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
28 suma = suma + notas [contador] ;

29 /*Obtenemos la nota media como el resultado de dividir la
suma de todas las notas entre el número de notas*/
30 float media = (float) suma/notas.length;
31 return media;
32 )
33 )
Seguidamente, se ejecuta en modo depuración este programa. Para ello, se abre la

vista de depuración seleccionando la opción de menú Window > Perspective > Open
Perspective > Debug y se establece un punto de ruptura o interrupción en la instruc-
ción del método calcularNotaMedia donde se incrementa la variable suma con el valor
de cada nota del array (línea 34). Para ello, se hace doble clic en el margen izquierdo
del editor y aparecerá un circulito en dicho margen, como se puede observar en la Figu-
ra 3.7. Además, en la pestaña Breakpoints del área de inspección, aparecerá dicho pun-
to de ruptura.
D) NotaMediajava X
//Llamamos al método que calcula la nota media
System.out.printin ("La nota media es un " + calcularNotaMedia (notas));
)
private static int[] leerNotas() (

int [] notas = new int [(15]; //Declaramos el array
//Creamos un objeto de tipo Scanner para leer datos por teclado
Scanner teclado = new Scanner (System.imn);
for (int contador = 0; contador < notas.length; ++contador) í
System.out.print ("Introduzca una nota: ");
/*Leemos un número entero por teclado y lo almacenamos en la
posición contador del array*/
notas[contador] = teclado.nextInt():
)
teclado.close();
return notas;
)
private static double calcularNotaMedia

(int[] notas) (
//Declaramos una variable para almacenar la suma de las notas
int suma = 0;
for (int contador = 0; contador < notas.length; ++contador)
de todas las notas entre el número de notas*/

float media = (float) suma/notas.length;
return media;
)
Figura 3.7. Punto de ruptura o interrupción en la instrucción de la línea 34 reflejado mediante el círculo
pequeño que aparece a la izquierda de dicha línea.
El siguiente paso es ejecutar el programa en modo depuración de forma que se ejecute

hasta la instrucción en la que se ha establecido el punto de ruptura. Para ello, se activa
la opción de menú Run > Debus, por lo que se tendrá que introducir por teclado las 15
notas que se solicitan.
3. DISEÑO Y REALIZACIÓN DE PRUEBAS |NFORMAT|CA Y C'13 |
Al llegar a la instrucción marcada como punto de ruptura, se interrumpe la ejecución del

programa. En ese momento, en el área de depuración (Figura 3.8), se muestra para el
hilo en ejecución los números de las líneas en las que está parada la ejecución: en la
instrucción n.* 34 del método calcularNotaMedia() y en la instrucción n.* 12 del método
main, en la que se llama al método calcularNotaMedia().
+ Debug 52 [; Project Explorer x 850

4 T] NotaMedia [Java Application]
4 P programas.NotaMedia at localhost:52990
4 ' Thread [main] (Suspended (breakpoint at line 34 in NotaMedia))
= NotaMedia.calcularNotaMedia(int[]) line: 34
= NotaMedia.main(String[]) line: 12
yE CaProgram FilesJava jdk-16.0.21binjavaw.exe (16 ago 2021 11:24:00)
Figura 3.8. Área de depuración de la vista de depuración en la que se puede

ver el hilo en ejecución y los números de líneas en los que se ha parado la
ejecución del programa.
Se puede continuar la ejecución, instrucción a instrucción, de cada método, seleccionan-

do la opción de menú Run > Step into o pulsando la tecla F5; o bien ejecutar instruc-
ción a instrucción, pero saltándose los métodos, para lo que habrá que elegir la opción
de menú Run > Step over o pulsar la tecla F6. Es posible finalizar la ejecución del depu-
rador seleccionado la opción de menú Run > Terminate o pulsando las teclas Ctrl + F2.
Se pulsa F5 para ejecutar el programa instrucción a instrucción y la instrucción que se

está ejecutando aparece marcada con una flechita en el margen izquierdo.
Si se desea eliminar un punto de ruptura, tan solo hay que hacer doble clic sobre el
circulito.
En el área de inspección, en la pestaña Variables, se pueden consultar los valores que

van tomando las variables en el momento de la ejecución.
D) NotaMediajava X = El (=Variables X g Breakpoints E7 Expressions = £

19 for (int contador = 0; contador < notas.length; ++contador) ( P PEc g
20 System.out.print ("Introduzca una nota: ");
21 úmero entero por teclado y lo almacenamos en la Name Value
22 De or del array*/ E» no method retumn valt
23 notas [conr.ador] = teclado.nextInt (); 4 6 notas (id=20)
24 ) a [0] 5
25 teclado.close(); a [1] 8
26 return notas; a [2] 10
27 ) a [ 6
2a a 4
5729"' private static double calcularNotaMedia
(int[] notas) ( 7 :g 8
so //Declaramos una variable para almacenar la suma de las notas a [6] 3
— a m 2
h a [8] 0
34 a [9] 8
ss /*Obtenemos la nota media como el re: a 10 :

s6 de todas las notas entre el número E e 1 u
37 float media = (float) suma/notas.length; la a 112 L
lss return media; a [13] 5
| EL) D 4 [14] 4
40 o suma 3
a) INEN
a2 v
< > < >
Figura 3.9. Áreas de edición y de inspección de la vista de depuración en un momento determinado

de la ejecución del programa.
1 1xOMUNICACIONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
En el área de inspección, al ser notas un array, se puede hacer clic en el desplegable

para ver los valores que toma cada una de sus posiciones. Se puede modificar el valor
de cualquier variable colocándose sobre el valor correspondiente y modificándolo.
E 3.6. Pruebas automáticas

Las pruebas de unidad o unitarias, esto es, las pruebas que afectan a una clase y a sus
métodos, implican crear algún objeto de la clase que se está probando y realizar llama-
das a sus métodos. Esto se puede realizar de manera manual, pero también existen he-
rramientas que permiten realizar pruebas unitarias de manera automatizada, como JUnit,
que está integrada en Eclipse.
Para demostrar el funcionamiento de JUnit, en este apartado, se crea una clase Cuenta
en un proyecto en Eclipse. Esta clase incluye como atributos el número de la cuenta y su
saldo, un método constructor con un parámetro por cada uno de los atributos de la cla-
se, métodos de consulta y acceso a cada uno de sus atributos, así como los siguientes
métodos:
E ingresarDinero(), para incrementar el saldo de la cuenta con el importe recibido

como parámetro.
E extraerDinero(), para disminuir el saldo de la cuenta con el importe recibido como

parámetro.
E mostrarCuenta(), que muestra el número de la cuenta y su saldo.
Se muestra a continuación el código de la clase creada:
2 public class Cuenta (
3 private String número; //Número de la cuenta bancaria
4 private float saldo; //Saldo de la cuenta bancaria en euros
5 public Cuenta (String numCta, float saldoCta)
6 número= numCta;
7 saldo = saldoCta;
8 )
9 public String getNúmero
() f
10 return número;
10 )
11 public float getSaldo
() (
12 return saldo;
13 )
14 public void setNúmero (String numCta) (
15 número = numCta;
16 )
1 public void setSaldo(float saldoCta) f
18 saldo = saldoCta;
19 )
3. DISEÑO Y REALIZACIÓN DE PRUEBAS INFORMÁT|CA Y CO/X*—/¡1 W*
20 public void ingresarDinero (float importe) f

29 saldo = saldo + importe;
20 )
23 public void extraerDinero (float importe) f
24 saldo = saldo - importe;
25 )
26 public void mostrarCuenta () f
27 System.out .println (“N* cuenta: “+ getNúmero());
28 System.out .printin (“Saldo: “+ getSaldo()+ “ €”);
29 )
30 )
El siguiente paso es crear una clase de prueba para esta clase. Seleccionada la clase
Cuenta, se activa con el botón derecho del ratón la opción del menú contextual New >
> JUnit Test Case. Se dejan las opciones por defecto y se pulsa en el botón Next. En la
ventana emergente (Figura 3.10), se eligen los métodos que se quieren probar; en este
caso, se probarán los métodos getSaldo, setSaldo, ingresarDinero y extraerDinero.
Test Methods
Select methods for which test method stubs should be created. E_'
Available methods:
- ]O -Cuena]
Ce 5 Cuenta(String, float)
getNúmero()
getSaldo()
setNúmero(String)
setSaldo(float)
ingresarDinero(float)
extraerDinero(float)
mostrarCuenta()
a ]O object
4 methods selected.
[]Create final method stubs

[]Create tasks for generated test methods
) < Back Next >
Figura 3.10. Ventana en la que se seleccionan los métodos que se desean

probar, en este caso, para la clase Cuenta.
Se creará una clase de prueba llamada CuentaTest, cuyo código se muestra a conti-
nuación:
package programas;
H
import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.Test;
w
class CuentaTest (
E
eTest
u
1 KOMUNICACIONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
6 void testGetSaldo() (f
7 fail (“Not yet implemented”);
8 )
9 eTest
10 void testSetSaldo() (f
12 )
13 eTest
14 void testIngresarDinero() (
fail (“Not yet implemented”);
15 )
16 eTest
17 void testExtraerDinero() (
19 )
20 )
Como se puede observar, se ha creado un método de prueba para cada uno de los méto-
dos que se han seleccionado antes. El nombre de cada uno de estos métodos comienza
por test y, por cada uno de ellos, aparece la notación ETest por ser un método de prueba.
A continuación, se deben implementar estos métodos. Para implementar los métodos de
prueba, es útil el empleo del método JUnit assertEquals (valorEsperado, valorReal), que
comprueba si el valor esperado indicado coincide con el valor real.
Después, se crea el código para el método de prueba testGetSaldo(), que comprueba el

funcionamiento del método getSaldo(). A tal fin, se crea un objeto de la clase Cuenta con
un saldo inicial de 100 €. El método se llamará getSaldo(), y luego se comprueba con
assertEquals() si el saldo de la cuenta es de 100 €:
eTest
HH
void testGetSaldo() |
au
Cuenta cuental = new Cuenta (“ES21099865462528660871295”, 100);

w
float saldo = cuental.getSaldo();

,
assertEquals (100, saldo);
Si se escribe este código para el método y se pulsa el botón Run o la opción de menú
Run > Run, se podrá ver, en la parte izquierda de la pantalla (véase Figura 3.11), que
se han ejecutado cuatro casos de prueba en los cuales no se ha producido ningún error,
pero que ha habido tres fallos. Al lado de cada método de prueba, hay un símbolo, de
manera que:
E Si es de color rojo, indica que se ha producido un error.
E Si es de color azul, indica que se ha producido un fallo.
E Si es de color verde, indica que la prueba ha tenido éxito.

3. DISEÑO Y REALIZACIÓN DE PRUEBAS |NFORMÁT|CA Y CO/M W
| Package Explorer ¿u JUnit 53 = [ Cuentajava — [J) CuentaTestjava 3

8ÍH'ÚÚÍWR'E'B 1 package programas;
Finished after 0,415 seconds 2
36 import static org.junit.jupiter.api.Assertions.*:[]
Runs: 4/4 E Errors: 0 El Failures: 3 6
| !
a Ki CuentaTest [Runner: JUnit 5) (0,135 s) Íi se eTest
del testExtraerDinero0 (0,1235) — void testGerSaldo() [
dEl testingresarDinero0 (0,005«) !Il-.x Cuenta cuental = new Cuenta ("ES21099865462528660871295", 100):
Jl testGetSaldo0) (0,002 ) 12 float saldo = cuental.gerSaldo();
LEl testSetSaldo0 (0,003 s) LWB',2 ] assertEquals (100, saldo);
168 eTest
a void testSerSaldo() (
18 fail("Not yet implemented");
9 D
Figura 3.11. Pantalla en la que se muestra el resultado de la ejecución de la clase de prueba CuentaTest,
obteniendo una prueba exitosa (la del método testGetSaldo) y tres fallos porque los otros tres métodos
aún no han sido implementados.
En este caso, en el panel izquierdo, junto al método testGetSaldo(), se observa un símbo-

lo de color verde que indica que el resultado esperado ha coincidido con el obtenido. En
el caso de los otros métodos de prueba, se indica que se ha producido un fallo porque
aún no han sido implementados. Se implementarán de esta forma:
1 QeTest
2 void testSetSaldo() |
3 Cuenta cuental = new Cuenta (“ES21099865462528660871295”, 0);
4 cuental.setSaldo(100);
5 assertEquals (100, cuental.getSaldo());
6 )
7 QeTest
10 cuental.ingresarDinero(400);
ha assertEquals (500, cuental.getSaldo());
12 )
13 eTest
14 void testExtraerDinero() |
L5 Cuenta cuental = new Cuenta (“ES21099865462528660871295”, 100);
16 cuental.extraerDinero(20) ;
18 )
Una vez implementados, si se hace clic en el botón de ejecución, se indicará que la eje-
cución de los cuatro casos de prueba ha sido exitosa:
Finished after 0,165 seconds

Runs: 4/4 E Errors: 0 Failures: 0
a f CuentaTest [Runner: JUnit 5) (0,056s) —

del testExtraerDinero() (0,039 s)
£] testingresarDinero() (0,001 s)
el testGetSaldo0) (0,002 s)
dEl testSetSaldo0) (0,014 5)
Figura 3.12. Parte de la pantalla en la que se muestra el resultado de la ejecución de la clase de prueba
CuentaTest, obteniéndose una prueba exitosa para los cuatro métodos de la clase porque los cuatro han
podido implementarse y, además, el resultado de la ejecución de cada método coincide con el esperado.
; (,OMUNICACIONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
Recuerda
En relación con lo dicho en el Apartado 3.1, se puede afirmar que un buen caso de prueba es
aquel que ofrece una elevada probabilidad de detectar un error, o lo que es lo mismo, aquel
que es muy probable que tenga éxito. Recuérdese que el objetivo de las pruebas es detectar
errores antes de que el software sea entregado al cliente, por lo que cabe afirmar que las
pruebas tienen éxito en la medida en que, mediante su ejecución, se encuentran defectos.
Sin embargo, en el ámbito de la herramienta JUnit, se marcan en color verde aquellos
métodos de prueba en los que el resultado obtenido coincide con el esperado. El color verde
suele vincularse con el éxito o con lo bueno y, por lo tanto, se puede afirmar que, en JUnit,
se considera exitoso aquel método de prueba como consecuencia del cual no se produce
un error o divergencia entre el resultado obtenido y el esperado. Esto parece ir en contra
de lo afirmado en el párrafo anterior y explicado en apartados anteriores, es decir, en
contra de la consideración de que un caso de prueba exitoso es aquel que detecta un fallo.
No obstante, no se trata de una incongruencia en relación con lo que se indicó en el
Apartado 3.1, sino, más bien, una forma diferente de interpretar el resultado de la ejecución
de un caso de prueba. Hay que seguir siendo conscientes de que la detección de un defecto
al ejecutar un caso de prueba es una «buena noticia» en la medida en que permite corregir
algo que se ha hecho mal porque, al ser humanos, nos podemos equivocar,
y lo positivo de todo ello es que aún se tiene tiempo de enmendar el error sin que el cliente
lo detecte.
ME 3.6.1. Tratamiento de excepciones

También es posible crear métodos de prueba que comprueben si, en determinados ca-
Sos, en un método, se ha producido una excepción si esta estaba prevista.
Para ejemplificar ese caso, aquí se modificará el método extraerDinero() de la clase Cuenta,
de manera que se produzca una excepción cuando el saldo resultante de la extracción
de dinero sea negativo. A tal fin, se lanza una excepción, ArithmeticException, que mues-
tre un mensaje de error indicando lo que ha ocurrido. El método extraerDinero() quedaría
del siguiente modo:
public void extraerDinero (float importe) f

H
if ((saldo - importe) < 0)

throw new java.lang.ArithmeticException (“Saldo negativo”) ;
au w
else
,
saldo = saldo - importe;
Con el fin de comprobar que, efectivamente, se lanza una excepción cuando el saldo de
la cuenta es negativo, se modifica el método de prueba testExtraerDinero() generando un
caso de prueba que dé lugar a esta situación, por ejemplo, creando una cuenta con 100 €
y solicitando una extracción de 120 € de esta. Para ello, se debe generar la excepción
ArithmeticException, capturando esa excepción y colocando el código que la genera den-
tro de un bloque try. En caso de que no se genere la excepción, como es de esperar, se
muestra un mensaje indicando que se ha producido un fallo con fail.
3. DISEÑO Y REALIZACIÓN DE PRUEBAS INFORMÁT|CA Y (,O/X
1 QeTest
3 try(
5 cuental .extraerDinero
(120);
6 fail (“ERROR. Se debería haber lanzado una excepción al
resultar un saldo negativo”) ;
7 )
8 catch (ArithmeticException ae) f
9 //Prueba correcta
10 )
11 )
Si se ejecuta de nuevo la clase de prueba, se verá que la ejecución de los 4 casos de

prueba, testGetSaldo(), testSetSaldo(), testIngresardinero() y testExtraerDinero(), es correc-
ta porque en este caso se ha generado una excepción al resultar el saldo de la cuenta
negativo.
ME 3.6.2. Anotaciones
Muy frecuentemente, al crear un caso de prueba, es necesario repetir ciertas instruc-
ciones en cada uno de los métodos de prueba. Así, en todos los métodos de la clase
CuentaTest se puso como primera instrucción la de creación de una cuenta con un sal-
do de 100 €:
Cuenta cuental = new Cuenta (“ES21099865462528660871295”, 100);
No obstante, es posible escribir la anotación OBeforeEach delante de un método para co-

locar en dicho método el código que se debe ejecutar por cada método de prueba y an-
tes de cualquiera de estos métodos.
De forma análoga, existe la anotación QAfterEach, para indicar que todas las instruccio-
nes del método para el que se especifica esta anotación se deben ejecutar después de
la ejecución de cualquier método de prueba.
A modo de ilustración, aquí se modificará la clase CuentaTest para incluir dicha instruc-
ción en un método nuevaCuenta(). La clase quedaría así:
package programas;
J4aukewrnHh
import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.BeforeEach;
class CuentaTest (
private Cuenta cuenta;
aBeforeEach
public void nuevaCuenta
() f
o
I A YI COMUNICACIONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
9 cuenta = new Cuenta (“ES21099865462528660871295”, 100);

10 )
1Ee eTest
12 void testGetSaldo() (
13 float saldo = cuenta.getSaldo();
14 assertEguals (100, saldo);
15 )
16 eTest
17 void testSetSaldo() (
18 cuenta.setSaldo(100) ;
19 assertEquals (100, cuenta.getSaldo());
20 )
21 eTest
23 cuenta.ingresarDinero
(400);
25 )
26 eTest
28 try(
29 cuenta.extraerDinero(120);
30 fail (“ERROR. Se debería haber lanzado una excepción
al resultar un saldo negativo”) ;
31 )
32 catch (ArithmeticException ae) (
33 //Prueba correcta
34 )
35 )
36 )
Asimismo, es muy habitual tener que realizar ciertas acciones una sola vez al inicio de
las pruebas, es decir, antes de la ejecución de cualquier método de prueba. Para ello,
se debe emplear la anotación EBeforeAll. De manera similar, existe la notación GAfterAll,
cuyas instrucciones se deben ejecutar después de la ejecución de todos los métodos de
prueba.
Los métodos con las anotaciones OBeforeAll y QAfterAll, así como los atributos a los que
acceden, deben tener asignada la propiedad static porque para el uso de estos métodos
y de los atributos a los que acceden, no es necesario crear ningún objeto de la clase a
la que pertenecen.
En el caso de la clase de prueba CuentaTest, se puede emplear la notación EBeforeAll

para el método nuevaCuenta(), pues la instrucción de creación de la cuenta es sufi-

ciente con que se ejecute una sola vez antes de la ejecución de todos los métodos
de prueba. Con el objeto de emplear la notación EBeforeAll, se modificará la clase
CuentaTest:
3. DISEÑO Y REALIZACIÓN DE PRUEBAS INFORMÁT|CA Y COM V
2 import static org.junit.jupiter.api.Assertions.*;
3 import org.junit.jupiter.api.Test;
4 import org.junit.jupiter.api.BeforeAll;
5 class CuentaTest (
6 private Cuenta cuenta;
7 eBeforeAll
8 public void nuevaCuenta
() f
9 cuenta = new Cuenta (“ES21099865462528660871295”, 100);
10 )
E eTest
12 void testGetSaldo() (
13 float saldo = cuenta.getSaldo();
14 assertEquals (100, saldo);
15 )
16 eTest
17 void testSetSaldo() f
18 cuenta.setSaldo(100);
19 assertEquals (100, cuenta.getSaldo());
20 )
2 eTest
23 cuenta.ingresarDinero
(400);
25 )
26 eTest
28 try(
29 cuenta.extraerDinero
(120);
30 fail (“ERROR. Se debería haber lanzado una excepción
al resultar un saldo negativo”);
31 )
32 catch (ArithmeticException ae) (
33 //Prueba correcta
34 )
35 )
36 )
Al ejecutar la clase de prueba, se obtiene el resultado que se muestra en la Figura 3.13.
Runs: 4/4 E Emors: 0 El Failures: 1 T

ÑT—;———.;.].—
— ]z;— DD
a fEl CuentaTest [Runner: JUnit 5] (0,028 s) Failure Trace El hejE"
101 AND UN S| N
dEl testExtraerDinero() (0,014 5) org.opentest4j.AssertionFailedError: expected: <100.0> but was: <500.0>

dEl testingresarDinero() (0,004 s) at programas.CuentaTest.testGetSaldo(CuentaTest.java:17)

del testGetSaldo() (0,007 s) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
dEl testSetSaldo() (0,001 s) at java.base/java.util.ArrayList. forEach(ArrayList.java:1511)
Figura 3.13. Resultado de la ejecución de la clase de prueba CuentaTest. En este caso, la prueba ha originado
un fallo para el método testGetSaldo().
u “O/VNUNICACIONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
Como se puede observar, se señala un fallo para el método testGetSaldo() porque se es-
peraba el valor 100, pero el valor del saldo es 500. Esto es debido a que el orden de
ejecución de los métodos de prueba no es el orden en el que se han escrito en la cla-
se CuentaTest, sino el orden en el que aparecen en el resultado de la ejecución, que se
muestra en la Figura 3.13, que es en orden alfabético por nombre de los métodos. Dado
que, en el método testIngresarDinero(), se ha incrementado el saldo en 400 €, tras ha-
berle asignado a la cuenta un saldo de 100 € al inicio, en el método nuevaCuenta(), que
tiene asignada la notación QBeforeAll, el saldo de la cuenta debe ser 500 €, y no 100 €,
como debía ser en la anterior versión de la clase CuentaTest. El motivo es que, en ese
caso, antes de la ejecución de cada método de prueba, se ejecutaba de nuevo el méto-
do nuevaCuenta(), por tener este asignado la anotación OBeforeEach. Se puede observar,
por tanto, como el empleo de una notación u otra (OBeforeAll o OBeforeEach) es muy re-
levante. Por tanto, para que el método testGetSaldo() se ejecute correctamente, se debe
cambiar el valor esperado del saldo a 500 €, quedando el método testGetSaldo() así:
eTest
H
void testGetSaldo() |
aH N
float saldo = cuenta.getSaldo();

w
assertEquals (500, saldo);
Recuerda
El criterio de cobertura de las pruebas es relevante porque es el que se usa para determinar en
qué momento se considera que se han realizado tantas pruebas con una alta probabilidad de
detección de errores como para considerar que ya no es necesario continuar realizando pruebas
sobre el elemento del software considerado. Un criterio de cobertura ampliamente empleado
es el recorrido de todas las instrucciones del código fuente del elemento que se está probando.
ME 3.0.3. Andlisis de la cobertura de las pruebas

Cuando se llevan a cabo pruebas, se debe tener un determinado criterio de cobertura que
dé por finalizadas las mismas, pues, como se sabe, la prueba exhaustiva del software
es impracticable, esto es, no es posible probar todas las posibles entradas con el fin de
determinar si en todos esos casos la salida es la esperada.
Eclipse nos da la opción de analizar la cobertura del código que se ha alcanzado con una
determinada clase de prueba. De esta manera, nos indica qué parte del código ha sido
probada y cuál no.
Si se toman como referencia la clase Cuenta y la clase de prueba CuentaTest, se puede ana-
lizar la cobertura de código eligiendo la opción de menú Run > Coverage con la clase de
prueba visible en el explorador de proyectos, o bien seleccionar del menú contextual de la
clase CuentaTest la opción Coverage As > Junit Test. En cualquiera de los dos casos, nos
aparecerá en el área de consola (parte inferior de la pantalla) una nueva pestaña llamada
Coverage con la indicación de la cobertura alcanzada, como se muestra en la Figura 3.14.
3. DISEÑO Y REALIZACIÓN DE PRUEBAS INFORMÁT|CA Y CO)…X/&1 ;'
[F Problems E Javadoc [E) Declaration [áa Coverage 2 E

| Element Coverage Covered Instructio... Missed Instructions Total Instructions
| í E 65% 70 1.008 1.078
E 65% 70 1.008 1.078
b EB programas E= 00% 0 964 964
4 EE CuentaPrueba 1 61,4% 70 - 114
4 [J) Cuentajava E 486% 35 37 72
4 O Cuenta m 486% 35 37 72
e mostrarCuenta() E 00% 0 23 23
e extraerDinero(float) Em 632% 12 A 19
e setNúmero(String) 1 0,0% 0 4 4
e getNúmero( 1 0,0% 0 3 3
- Cuenta(String, float) E 100,0 % 9 o 9
e getSaldo0 1 1000% 3 0 3
e ingresarDinero(float) E 1000% 7 0 7
e setSaldof(float) 1 100,0 % 4 o 4
b [] CuentaTestjava m 833% 35 7 42
Figura 3.14. Cobertura de prueba alcanzada para la clase Cuenta y para el paquete y el proyecto en el que está
incluida esta clase.
Se indica, para cada elemento, el número de instrucciones cubiertas por la prueba

(Covered Instructions), el número de instrucciones no cubiertas (Missed Intructions) y el
número total de instrucciones (Total Instructions). A partir de estos datos, se calcula la
cobertura (Coverage), que es el porcentaje que resulta de relacionar el número de instruc-
ciones cubiertas con el número total de instrucciones.
Así, para el caso de la clase Cuenta, la cobertura es del 48,6 %. Esto se debe a que hay
tres métodos que no han sido probados en absoluto (setNúmero(), getNúmero() y mostrar-
Cuenta()) y otro que solo ha sido probado parcialmente, que es extraerDinero(). Si se se-
lecciona en el explorador de proyectos la clase Cuenta, es posible observar en el área de
edición sus instrucciones en diferentes colores (Figura 3.15):
E El color verde indica que el método ha sido probado por completo.
E El color rojo indica que el método no se ha probado.
E El color amarillo indica que el método se ha probado parcialmente. Por ejemplo,

en el método extraerDinero(), se puede observar que se ha probado la rama del if
correspondiente a la excepción (en color verde) pero no la otra rama (en color rojo).
S Package Explorer - ¿Ju JUnit 5% = E [ CuentaTestjava [3) Cuentajava 53

0 TFAMQOREE-I E
Finished after 0,794 seconds 6
Runs: 4/4 E Errors: 0 El Failures: 0 ;
— se Ppublic String getNúmero
()1
-- return número;
a[E CuentaTest [Runner JUnit 5) (0,120 5)
del testExtraerDinero() (0,000 s)
dEl testingresarDinero() (0,000 s)
dEl testGetSaldo() (0,112 5)
testSetSaldo() (0,002 s)
180 public voíd serSaldo(float saldoCta)1(
218 public void ingresarDinero(float importe) (

22 1
23
= Failure Trace El hejE" 2.. public void extraerDinero(float importe) 1
27 else
Figura 3.15. Instrucciones del código de la clase Cuenta que se han probado, en diferentes colores,
que indican si el método correspondiente se ha probado o no.
—. JK". Y COMUNICACIONES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
De esta forma, se ha mostrado la cobertura de instrucciones del código, pero se pue-

den mostrar otros tipos de cobertura haciendo clic en el botón % situado en la parte de-
recha de la pestaña Coverage del área de consola. Así, si se selecciona la cobertura de
métodos (opción Method Counters), el resultado es el que se observa en la Figura 3.16.
ER Problems G Javadoc [G) Declaration | [ Coverage %

uentaTest (1) (25 ago 2021 16:56:06)
Element Coverage Covered Methods Missed Methods Total Methods
a [7 Cuentajava E 625% 5 3 8
4 O Cuenta E 625% 5 3 8
e getNúmero() E 00% 0 1 1
e mostrarCuenta() E 00% 0 1 1
e setNúmero(String) E 00% 0 1 1
i Cuenta(String, float) EE 100,0% 1 0 1
e extraerDinero(float) EE 100,0% 1 0 1
e getSaldo() E 100,0% 1 0 1|
e ingresarDinero(float) EN 100,0% 1 0 1
e setSaldo(float) EE 100,0% 1 0 1 1
Figura 3.16. Cobertura de métodos para la clase Cuenta.
En este caso, la cobertura es del 62,5 % porque de los 8 métodos de la clase Cuenta
han sido probados 5.
Si se selecciona la opción Branch Counters, se señalarán, para los métodos con varias ra-
mas, la cobertura de ramas que se ha conseguido con la clase de prueba. Como en este
caso, en la clase Cuenta, solo hay un método con dos ramas, el método extraerDinero(),
el resultado para este método es que la cobertura es del 50 %.
ER Problems (G Javadoc [Q Declaration [ Coverage %% '

CuentaTest (1) (25 ago 2021 16:56:06)
Element Coverage Covered Branches Missed Branches Total Branches
a [ Cuentajava E 50,0% 1 1 2
4 O Cuenta E 500% 1 1 2|
e extraerDinero(float) E 500% 1 1 2|
- Cuenta(String, float) 0 0 0.
e getNúmero( 0 0 0.
e getSaldo( 0 0 0 |
e ingresarDinero(float) 0 0 1) |
e mostrarCuenta() 0 0 0.
e setNúmero(String) 0 (1) 0 |
e setSaldo(float) 0 0 0
Figura 3.17. Cobertura de ramas para los métodos de la clase Cuenta que tienen ramas. Solo hay un método
con dos ramas, de las cuales, se ha probado una de ellas.
Filosofía de las pruebas
del software
Estrategia de pruebas
del software
Diseño y realización de pruebas
Técnicas de diseño de casos

de prueba
Documentación de las pruebas
Herramientas de depuración
Pruebas automáticas
118
3.1. Señala la afirmación correcta en relación con las pruebas del software:
a) Es posible probar exhaustivamente el software para garantizar que este está
exento de errores.
b) La prueba del software es por naturaleza una tarea destructiva frente a las restan-
tes etapas del ciclo de vida.
c) Mediante las pruebas es posible validar y verificar el software.
d) El orden en el que se deben aplicar las pruebas sobre el software viene determi-
nado por las técnicas de diseño de casos de prueba.
3.2. Las pruebas cuyo objetivo es garantizar que los elementos que componen el
software se comunican adecuadamente y cooperan entre ellos para realizar las
tareas encomendadas son las pruebas:
a) Del sistema.
b) De validación.
c) De unidad.
d) De integración.
3.3. Las técnicas de diseño de casos de prueba en las que se examinan los detalles
de cada componente del software para generar los casos de prueba son:
a) Las pruebas de caja negra.
b) Las pruebas estructurales.
c) Las pruebas de caja blanca.
3.4. El gráfico que hay que dibujar a partir del código fuente para poder aplicar la
prueba del camino básico se llama:
a) Grafo de flujo.
b) Organigrama.
c) Ordinograma.
d) Grafo de programa.
3.5. En la prueba del camino básico es posible asignar el mismo nodo a:

a) La instrucción que indica el fin de una estructura repetitiva y la siguiente instruc-
ción en secuencia.
b) La instrucción que indica el fin de una instrucción condicional y la siguiente ins-
trucción en secuencia.
c) Las respuestas a y b son correctas.
3.6. En la técnica de diseño de casos de prueba de flujo de datos, una cadena DU

[X; 1, l] es aquella en la que X está en DEF(1), X está en USO(1”) y:
a) Hay algún camino entre / e /* que incluye algún otro uso de la variable X.
b) Hay algún camino entre / e / que incluye alguna otra definición de la variable X.
c) Hay algún camino entre / e /” que no incluye ningún otro uso de la variable X.
d) Hay algún camino entre / e /” que no incluye ninguna otra definición de la variable X.
119
ACTIVIDADES FINALES 3. DISEÑO Y REALIZACIÓN DE PRUEBAS
3.7. Indica la regla válida para la generación de casos de prueba en la técnica de

clases de equivalencia:
a) Si una condición de entrada consiste en una condición lógica, se deben identifi-
car una clase válida y dos no válidas.
b) Si una condición de entrada consiste en un rango de valores, se deben identificar
una clase válida y dos no válidas.
C) Si una condición de entrada consiste en un valor específico, se deben identificar
una clase válida y una no válida.
3.8. Las pruebas consistentes en volver a ejecutar casos de prueba tras modifica-
ciones en el software con el fin de asegurarse de que los cambios no han origi-
nado nuevos defectos se llaman:
a) Pruebas de regresión.
b) Pruebas de repetición.
c) Pruebas de integración.
d) Pruebas de validación.
3.9. ¿En qué área de la vista de depuración de Eclipse se pueden ver las variables
del programa y los valores que van tomando estas a lo largo de la ejecución del
programa?
a) En el área de depuración.
b) En la consola.
c) En el área de inspección.
d) En el área de edición.
3.10. En el ámbito de las clases de prueba que se pueden crear con JUnit, ¿cuándo
se dice que se ha producido un error?
a) Cuando el resultado de la ejecución de un caso de prueba coincide con el espe-
rado.
b) Cuando el resultado de la ejecución de un caso de prueba no coincide con el es-
perado.
c) Cuando un método de prueba no se ha implementado todavía.
3.11. ¿Qué es un caso de prueba?
3.12. ¿Qué diferencia hay entre las pruebas de caja blanca y las de caja negra?
3.13. El siguiente programa escrito en Java pide números por teclado hasta que se introduzca
un O y calcula, por un lado, la suma de los números pares y, por otro, la suma de los
impares. Para este programa, construye el grafo de flujo correspondiente, calcula la
complejidad ciclomática e indica un conjunto de caminos independientes. Además, se-
ñala, para cada camino, el caso de prueba correspondiente, incluyendo la entrada pro-
120 porcionada y la salida esperada.
E int num;
3 int sumapares = 0;
4 int sumaimpares = 0;
6 System.out .print (“Introduzca un número (0 para
terminar): “);
8 while (num != 0)
9 ( if (num $ 2 == 0)
10 sumapares = sumapares + num;
Ta else
1 sumaimpares = sumaimpares + num;
13 System.out.print (“Introduzca un número (0 para
terminar): “);
15 )
16 System.out .printin (“La suma de los números pares es “ +
sumapares) ;
17 System.out .printin (“La suma de los números impares es “ +
sumaimpares) ;
18 )
3.14. El siguiente programa escrito en Java solicita por teclado un número entero e indi-
ca si es primo o no. Para este programa, construye el grafo de flujo correspondiente,
calcula la complejidad ciclomática e indica un conjunto de caminos independientes.
Además, señala, para cada camino, el caso de prueba correspondiente, incluyendo
la entrada proporcionada y la salida esperada.
1 public static void main(String[] args) f

E n nUum, 1=
3 boolean esPrimo = true;
5 System.out .print (“Introduzca un número entero: “);
6 num = teclado.nextInt();
7 while ( i <= num/2 £% esPrimo )(
8 if (numsi == 0)!
9 esPrimo = false;
10 )
de i++;
12 )
13 if (esPrimo)
14 System.out.println (“El número “ + num + “ es
primo.”);
15 else
16 System.out.println (“El número “ + mnum + “ no es
primo.”);
e y
121
3.15. Tomando el programa de la Actividad 3.13, obtén las cadenas DU para la variable suma-
pares y encuentra el número mínimo de caminos de prueba que deben recorrer todas es-
tas cadenas.
3.16. Obtén las cadenas DU para la variable ¡ del programa de la Actividad 3.14 y encuentra el
número mínimo de caminos de prueba que deben recorrer todas estas cadenas.
3.17. Un establecimiento vende sus productos a través de internet y, en la aplicación corres-

pondiente, se solicita al cliente introducir varios datos. Algunos de los datos que se de-
ben introducir y para los que se requieren validaciones son los siguientes:
a) NIF: debe ser una cadena de 9 caracteres de los cuales los 8 primeros deben ser dí-
gitos, mientras que el último debe ser una letra. La letra debe corresponder a los
8 números de acuerdo con el algoritmo correspondiente.
b) El número de la tarjeta de crédito con la que se va a pagar: debe ser un número de

16 cifras.
C) La marca de la tarjeta de crédito: solo puede ser Visa, Mastercard o Maestro. Los tra-
tamientos que se deben realizar en cada caso son diferentes.
Crea una tabla de clases de equivalencia y genera los casos de prueba correspondien-
tes, usando la técnica de particiones de equivalencia, e indica, en cada caso, las clases
cubiertas.
3.18. Un taller de reparación de vehículos permite reservar cita previa vía internet. En su apli-
cación, se solicita al cliente introducir varios datos y, para algunos de ellos, se desea rea-
lizar validaciones:
a) La matrícula del vehículo, que debe constar de cuatro números y tres letras.
b) El número de puertas del vehículo, que debe ser 3, 4 05.
c) La potencia del vehículo en caballos, que debe ser un número entero entre 40 y 300.
Genera una tabla de clases de equivalencia y los casos de prueba correspondientes,

usando la técnica de particiones de equivalencia, e indica, en cada caso, las clases cu-
biertas.
3.19. ¿En qué consiste la técnica de prueba de conjetura de errores?
3.20. ¿De qué manera se pueden complementar las técnicas de diseño de casos de prueba de
clases de equivalencia y el análisis de valores límite?
3.21. Se proporciona el código de una clase llamada Punto con dos atributos para sus coor-
denadas en dos dimensiones y una serie de métodos que permiten realizar operaciones
con puntos:
public class Punto (

khH
private double x;
N
private double y;
w
public Punto (double x, double y) f

B
this.x =
122
u
6 this.y = y;
7 )
8 public double getX()(f
9 return x;,;
10 )
ae public double getY ()
12 return y;
13 )
14 public void setX(double x) f
115 this.x = ;
16 )
17 public void setY (double y) f
18 this.y = y;
19 )
20 public double distancia (Punto p) (
2 return Math.sgrt (Math.pow(p.x-this.x, 2) + Math.pow(p.y-
this.y, 2));
22 )
23 public boolean compara (Punto p) f
24 iE£ (p-x -- xp.Yy —Y)
25 return true;
26 else
27 return false;
28 )
29 )
Crea una clase de prueba para probar el correcto funcionamiento de los métodos distancia
y compara que, respectivamente, calculan la distancia entre dos puntos y los comparan,
indicando si son iguales o no. Emplea la anotación EBeforeEach para crear dos puntos
con los cuales se realicen las dos operaciones.
3.22. ¿Para qué se utiliza la notación G AfterEach en un método dentro de una clase de prueba?
3.23. Calcula la cobertura de métodos y de instrucciones para la clase Punto de la Actividad 3.21
y analiza los resultados.
3.24. ¿Son válidas las estrategias de pruebas de integración expuestas en el Apartado 3.2.2
para software convencional? Si no es así, ¿qué otras estrategias se emplean para este
tipo de software?
Busca en la red información sobre las pruebas alfa y beta. ¿De qué tipo de pruebas se
[
trata en cuanto a la estrategia de aplicación de las pruebas? ¿En qué se diferencian las
pruebas alfa de las pruebas beta? 123
3.26. Como se indicó en el Apartado 3.5, las pruebas de regresión consisten en repetir casos
de prueba que se ejecutaron antes de realizar ciertas modificaciones para cerciorarse de
que los cambios no hayan originado nuevos defectos en el software. Busca información
sobre este tipo de pruebas para dar respuesta a las siguientes preguntas: ¿cuándo se
deben llevar a cabo este tipo de pruebas?, ¿qué técnicas de diseño de casos de prueba
se suelen emplear?, ¿es posible automatizarlas?
A7 Con ayuda de internet, averigua qué son las pruebas de usabilidad y por qué son tan Úti-
les para las aplicaciones web.
3.28. Investiga en internet en qué consisten las pruebas de humo y cuándo se suelen llevar a
cabo.
3.29. Busca en internet información sobre las pruebas de portabilidad. ¿En qué consisten este
tipo de pruebas y para qué tipo de software se suelen llevar a cabo?
[m] ¡javiergarzas.com - https://www.javiergarzas.com/

= — (Blog de Javier Garzas sobre temas relacionados con el desarrollo de software y, especialmen-
te, con las metodologías ágiles)
124
Home Blog Team Info
UNIDAD 4
Optimization
Vestibulum molestie nisl nec nunc viverra efficitur.
efficiturquam tristique aliquam.Proin ut est lectus.
rísus quis sagittis porta.
Fusce luctus blandit nisi.
Ut imperdiet dui at tincidunt mattis.
— 5
1IIIIIIIIII""
Optimización
y documentación
Comprender el concepto de refactorización y El 4.1. Refactorización
los patrones de refactorización más usuales. N 4.2. Analizadores de código
Aplicar patrones de refactorización en el ámbito
E 4.3. Control de versiones
del entorno de desarrollo.
; -A - A El 4.4. Documentación
Revisar el código fuente mediante un analizador
de código.
Conocer el concepto de control de versiones.
Utilizar herramientas de control de versiones
integradas en el entorno de desarrollo.
Comprender la necesidad de una correcta
documentación de una aplicación.
Emplear herramientas del entorno de desarrollo
para documentar clases.
4. OPTIMIZACIÓN Y DOCUMENTACIÓN |NFORMÁTICA Y ( NN
Introducción
La calidad del código creado, como producto final de un proyecto de desarrollo, es fun-
damental para facilitar la tarea de mantenimiento, la cual supone un porcentaje muy
elevado del esfuerzo realizado para el desarrollo de software. Por eso, actualmente, la
refactorización del código fuente o mejora de su estructura interna, sin alterar su com-
portamiento externo, es una tarea muy relevante. En esta unidad, se explicará con de-
talle dicho proceso y se estudiarán los patrones de refactorización más usuales y su
aplicación en Eclipse.
Por otro lado, los analizadores de código sirven para la mejora de la calidad del código
fuente, pues detectan defectos en este, que podrían tener efectos adversos. Aquí, se
describe el funcionamiento de un analizador de código integrado en el IDE Eclipse.
Un correcto control sobre las diferentes versiones que se van generando de una aplica-
ción informática también es de gran importancia para controlar los cambios que se van
produciendo y para facilitar el mantenimiento del software, motivo por el cual se dedica
una parte de esta unidad al control de versiones.
La realización de una documentación clara y explicativa de una aplicación informática, in-

cluyendo el código fuente, también es esencial para facilitar la tarea de mantenimiento.
En este tema, se contempla la posibilidad de usar las herramientas de documentación
que vienen incorporadas en los entornos de desarrollo.
E 41 Refactorización
Uno de los productos finales del proceso de desarrollo de software es el código fuente y,
ante cualquier cambio que sea necesario llevar a cabo en una aplicación, habrá que mo-
dificar dicho código. Es muy frecuente que, a lo largo del ciclo de vida de una aplicación,
haya que realizar cambios sobre esta por varios motivos y, para cada uno de ellos, exis-
ten distintos tipos de mantenimiento:
E Mantenimiento perfectivo: es el que se lleva a cabo porque el cliente propone nue-

vos requisitos funcionales o de cualquier otro tipo.
E Mantenimiento correctivo: es el que se realiza como consecuencia de la detección

por parte del cliente de algún error tras la entrega de la aplicación.
E Mantenimiento adaptativo: es el que se lleva a cabo para poder utilizar la aplicación

en nuevos entornos de hardware o software, como por ejemplo, el que se requiere
cuando se necesita usar un programa en un nuevo sistema operativo.
La probabilidad de que haya que realizar alguno de estos tipos de mantenimiento sobre
una aplicación es casi del 100 % y, además, es muy probable que la persona o perso-
nas que tengan que ocuparse de este no sean las mismas que se encargaron de crear
la aplicación. Por todo ello, es del todo conveniente que el código fuente sea sencillo y
esté bien estructurado.
3 ÍVRUN'CACIONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
Martin Fowler (2018) define así la refactorización: «realizar modificaciones en el código

con el objetivo de mejorar su estructura interna, sin alterar su comportamiento externo».
No se trata, por tanto, de encontrar y corregir errores en una aplicación, lo que constitui-
ría una tarea de mantenimiento correctivo de esta, sino de realizar pequeños cambios en
el código fuente sin alterar su comportamiento, de manera que el efecto acumulativo de
todas estas modificaciones dé lugar a una simplificación del código y a una mejora de su
estructura. El resultado de esta tarea es que el código será más fácil de entender y mo-
dificar, facilitando así la tarea de mantenimiento.
Argot técnico
El vocablo refactorizar no aparece en el diccionario de la RAE. Proviene del inglés refactoring,
pero esta palabra inglesa tampoco aparece de momento en los diccionarios de inglés.
Para evitar usar una palabra extranjera, se podrían emplear vocablos como «perfeccionar»,
«reestructurar», «reorganizar», pero estos términos resultan más genéricos de lo deseable,
por lo que a lo largo de esta unidad se usará el término refactorizar, cuyo significado se ha
señalado en el párrafo anterior.
Existen varias razones por las que puede ser conveniente refactorizar:
E Calidad: un código de calidad es un código sencillo y bien estructurado, de manera

que sea fácilmente legible y comprensible por cualquier persona sin que esta haya
formado parte del equipo de desarrollo.
E Eficiencia: el esfuerzo que se invierta en refactorizar se verá recompensado cuando

se tenga que realizar cualquier tarea de mantenimiento del software.
E Evitar la reescritura de código: refactorizar suele ser mejor que reescribir el código,
ya que suele ser más costoso escribir código desde cero.
Mediante la refactorización se pretende conseguir un diseño lo más sencillo posible y de

calidad, lo que implica:
E Que el código funcione, es decir, que haya superado la etapa de pruebas de acuer-
do con el nivel de cobertura deseado.
E Que no existe código duplicado.
E Que el código permite entender el diseño.
E Que se ha minimizado el número de clases y de métodos.
ME 41.1.Los malos olores (bad smells)

Es muy importante saber cuándo es conveniente refactorizar. Para abordar esta necesi-
dad, Martin Fowler, quien popularizó la técnica de la refactorización, acuñó por primer vez
el término bad smells (malos olores), que son aquellos síntomas en el código que acon-
sejan la realización de una refactorización. Que el código presente estos síntomas no
significa que el software no funcione, pero puede llevar a una ejecución más lenta del
programa o a un código difícil de mantener, y debido a la baja calidad del código, este
será más propenso a tener fallos en el futuro.
4. OPTIMIZACIÓN Y DOCUMENTACIÓN |NFORMÁT'CA Y CON
“D
Anma
Argot técnico
El término bad smell, que traducido literalmente del inglés quiere decir “mal olor”, se debe
entender en sentido metafórico. Es frecuente escuchar la expresión española de que «algo no
huele bien», la cual se emplea no en el sentido estricto del verbo oler (*percibir un olor”), sino
en sentido figurado. De hecho, en el diccionario de la RAE, la expresión no oler bien significa
«dar sospecha de que encubre un daño o fraude». Esto es precisamente lo que ocurre
cuando se detecta un mal olor en el código: se trata de un síntoma o una sospecha de que
hay algo mal en el código que puede tener efectos secundarios negativos.
En la página web https://www.codegrip.tech/ productivity/ everything-you-need-to-know-

about-code-smells/ se realiza una clasificación de los malos olores que se pueden encon-
trar en el código, en función del nivel al que afectan:
EA nivel de aplicación:
— Código duplicado (duplicated code): consiste en la existencia de código similar en

varios lugares. Es uno de los síntomas más frecuentes, ante el que es necesario
extraer ese código y colocarlo en una única ubicación.
— Cirugía a tiros (shotgun surgery): un cambio en una clase conlleva la realización

de cambios en otras muchas clases.
— Complejidad artificial (contrived complexity): consiste en usar patrones de diseño

complejos cuando se podría usar un diseño más simple o de menor complejidad.
EA nivel de clase:
— Clase larga (large class): consiste en tener una clase con demasiados atributos,
métodos o instancias. Esto es debido a que la clase tiene encomendadas más
tareas de las que le deberían corresponder.
— Clase demasiado simple (freeloader): consiste en tener una clase con muy pocas
responsabilidades. Muchas veces se trata de clases que solo tienen atributos y
métodos de acceso (set) y de consulta (get).
— Envidia de funcionalidad (feature envy): existe un método en una clase que pa-
rece más interesado en otra clase que en la clase en la que se encuentra, es
decir, un método que usa en exceso métodos de otra clase. Se suele resolver
moviendo el método a la clase cuyos elementos más utiliza.
— Código divergente (divergent code): al realizar un cambio en el sistema, una clase

sufre demasiados tipos de cambios.
— Grupo de datos (data clump): ocurre cuando conjuntos de datos se agrupan en

varias partes del programa. Lo más probable es que sea más adecuado agrupar
las variables en un único objeto.
— Intimidad inapropiada (inappropriate intimacy): se da cuando una clase depende

de los detalles de implementación de otra clase.
— Legado rechazado (refused bequest): una clase no usa métodos y atributos de la

superclase, lo que suele indicar que la jerarquía de clases se ha creado incorrec-
tamente.
3 MUN'CAGONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
— Complejidad ciclomática (cyclomatic complexity): se trata de una clase con dema-

siadas ramas y bucles. Esto quiere decir que el método o los métodos a los que
afecta este problema se deben dividir en varios métodos o se deben simplificar.
E A nivel de método:
— Método largo (long method): es un método difícil de entender. Además, un méto-

do debe realizar una función única y bien definida, por lo que es muy probable
que un método largo realice más tareas de las que debería. Por este motivo, se
debería descomponer en varios métodos más pequeños.
— Cadenas de mensajes (message chains): un método llama a otro método, el cual

llama a otro método y este a otro, y así sucesivamente.
— Demasiados parámetros (too many parameters): un método con una larga lista de
parámetros hace que sea difícil de invocar y de probar. Además, puede indicar
que el método está realizando más tareas de las que debería.
— Línea de código excesivamente larga (God line): una línea de código demasiado
larga hace el código difícil de leer, entender, corregir y dificulta la reutilización.
— Excesiva devolución (excessive returner): consiste en un método que devuelve

más datos de los que son necesarios.
— Tamaño del identificador (identifier size): el nombre del identificador es demasiado

largo o demasiado corto.
ME 4.1.2.Implantación de la refactorización
Existen dos posibilidades a la hora de realizar la refactorización: comenzar con un nuevo
desarrollo o aplicar la refactorización a posteriori 0, dicho de otro modo, ejecutarla sobre
una aplicación ya desarrollada.
En el primero de los casos, la refactorización continua es lo más adecuado. Esta con-

siste en llevar a cabo pequeñas refactorizaciones y, a menudo, en vez de realizar pocas
pero grandes refactorizaciones. Se debe recordar que una refactorización debe suponer
un cambio en la estructura del código sin cambiar la funcionalidad de la aplicación y, por
lo tanto, cuanto mayor sea el cambio de código producido por la refactorización, mayor es
la posibilidad de que, como consecuencia de esos cambios, la aplicación deje de funcio-
nar o lo haga de manera anómala.
En el caso de que la aplicación ya esté desarrollada, no hay más remedio que aplicar la
refactorización sobre toda la aplicación en lugar de incorporar la refactorización como ta-
rea que se va aplicando de forma continua a medida que se va escribiendo el código. Aun
así, lo recomendable es ir llevando a cabo pequeñas refactorizaciones secuencialmente
Y, tras cada una, realizar pruebas para comprobar que la aplicación sigue funcionando co-
rrectamente, de manera que no se hayan introducido errores como consecuencia de las
modificaciones incorporadas al código.
Para la implantación de la refactorización, se recomiendan las siguientes buenas prácticas:

4. OPTIMIZACIÓN Y DOCUMENTACIÓN |NFORMATÍCA | KF
1. Antes de comenzar la refactorización, es necesario llevar a cabo pruebas unitarias

y funcionales.
2. Promover y recibir formación sobre patrones de refactorización, pues el conocimien-
to de las refactorizaciones más comunes permite a quienes realizan la programa-
ción detectar los malos olores de los que no serían conscientes si no tuvieran esa
formación.
3. Usar herramientas especializadas, ya que las refactorizaciones muchas veces supo-

nen pequeñas modificaciones muy simples y en muchas clases, que se pueden reali-
zar de manera automática y sin riesgo mediante el empleo de dichas herramientas.
4. Comenzar refactorizando los principales fallos de diseño (código duplicado, clases lar-
gas, etc.). Se trata de refactorizaciones que son fáciles de aplicar y muy beneficiosas.
5. Refactorizar el código tras añadir cada nueva funcionalidad. Resulta muy producti-
vo realizar discusiones en grupo sobre la conveniencia de realizar una refactoriza-
ción tras la adición de cada nueva función al software.
6. Implantar la refactorización continua, por lo que las personas responsables del de-
sarrollo del software deben incorporar la tarea de refactorización como una más
dentro del proceso de desarrollo.
Sin embargo, aunque la refactorización continua puede ser una práctica muy adecuada,
es cierto que hay ocasiones en las que no es tan fácil aplicarla por uno de los siguien-
tes motivos:
E Porque un equipo de desarrollo debe comenzar a trabajar con código desarrollado

por otro equipo y el código no tiene buena calidad o no está preparado para la adi-
ción de nuevas funcionalidades.
E Porque se ha aplicado refactorización continua, pero la calidad del código se ha de-

gradado debido a que no se detectó a tiempo la necesidad de una refactorización o
bien se aplicó una refactorización de manera incorrecta.
La mejor estrategia en estos casos es, como se indicó antes, dividir la refactorización
completa en el mayor número posible de pequeñas refactorizaciones. También es acon-
sejable, antes de llevar a cabo cada pequeña refactorización, comunicar los cambios que
se van a realizar a las personas afectadas, esto es, a las personas que están trabajando
con el código que va a ser objeto de la refactorización. Asimismo, puede resultar conve-
niente explicar cada refactorización llevada a cabo una vez que esta se haya completado.
ME 4.1.3,Patrones de refactorización en Eclipse

A la hora de refactorizar, se deben seguir distintos métodos o patrones. En el momento
de utilizar cada patrón de refactorización, es posible previsualizar la solución que se ofre-
ce, ante la cual, se puede optar por aplicarla o no.
Para aplicar los patrones de refactorización en el IDE Eclipse, hay que seleccionar el ele-
mento sobre el que se desea aplicar la refactorización y elegir del menú contextual la op-
ción Refactor, o bien seleccionar la opción Refactor del menú principal. La refactorización
se puede aplicar sobre una clase, un atributo, una variable, una expresión, un bloque de
instrucciones, etcétera.
| 'ílr “OMUNICACIONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
En los siguientes subapartados, se describen los patrones de refactorización más habi-

tuales. A modo de ejemplo, se aplicarán algunos de los patrones de refactorización a una
aplicación llamada figuras, que se encuentra disponible como material disponible previo
registro en www.paraninfo.es. Esta aplicación dispone de una clase abstracta, Figura,
con sus subclases Rectángulo y Triángulo. Además, Rectángulo dispone de la subclase
Cuadrado. La clase Figura es abstracta porque no se puede crear ninguna figura sin sa-
ber si se trata de un rectángulo, un triángulo o un cuadrado. Cada figura se caracteriza
por tener un centro y por su color. Para definir el centro de una figura, se utiliza un pun-
to, motivo por el que se incluye también la clase Punto. El programa principal muestra un
menú en el que se solicita elegir una figura (triángulo, rectángulo o cuadrado), se piden
sus datos (por ejemplo, en el caso de un rectángulo, información sobre el centro y dos la-
dos) y se muestran en pantalla su perímetro y su área.
BNE Rename
Este patrón de Eclipse permite cambiar el nombre de una clase, de un atributo, de un
método, de una variable, etc., de forma que se renombran todas las referencias a ese
elemento a lo largo del programa.
A modo de ejemplo, aquí se va a cambiar el nombre de la clase Rectángulo en el proyec-
to figuras de manera que se elimine la tilde del nombre, esto es, su nuevo nombre será
Rectangulo. Seleccionada la clase Rectángulo, se elige la opción del menú contextual
Refactor > Rename. A continuación, se escribe su nuevo nombre en el campo New name.
Si se pulsa en el botón Next, en la ventana emergente (Figura 4.1), aparecen en la par-
te superior las partes de la aplicación en las que se propone realizar la modificación,
pudiéndose seleccionar las que nos interesan (lo más probable es que sean todas). Ade-
más, se puede visualizar el estado antes y después del renombrado. Si se hace clic en el
botón Finish, se procede al renombrado en las partes seleccionadas.
Changes to be performed
Cuadrado.java - Ejercicios/src/figuras
> [V]P PruebaFigura.java - Ejercicios/src/figuras
€, Rename compilation unit 'Rectángulo.java' to 'Rectangulo.java'
D) Cuadrado.java [>|4 | & ñ Ág ñ&

Original Source Refactored Source
1package figuras; 1lpackage figuras; A
2 2
3 import java.awt.Color; 3 import java.awt.Color;
4 4
5public class Cuadrado extends Rectángulo! S5public class Cuadrado extends Rectangulo!
6 6
7public Cuadrado (double x, double y, Color có 7public Cuadrado (double x, double y, Colc
£super (x, y, color, lado, lado); Ssuper (x, y, color, lado, lado);
9) 9)
<
Figura 4.1. Al seleccionar el patrón de refactorización Rename de un elemento, se muestran todos los lugares
de la aplicación donde ese cambio de nombre tendrá efecto antes de llevarlo a cabo.
4. OPTIMIZACIÓN Y DOCUMENTACIÓN |NFORMÁTICA Y C… |
EE oe
Esta opción permite mover una clase de un paquete a otro, procediéndose a cambiar to-
das las referencias a esa clase.
ME Extract Interface
Si se selecciona una clase en Eclipse, el programa permite extraer los métodos desea-
dos de esa clase para crear una interfaz (véase en qué consiste una interfaz en el Apar-
tado 5.4.5). En la interfaz se definen los métodos especificando solo su cabecera, es
decir, el nombre del método, el tipo de valor de retorno (si devuelve algo) y sus paráme-
tros. El código de los métodos se especifica en las clases que implementan la interfaz.
Por ejemplo, podría resultar interesante llevar a una interfaz el método esMayorQue de la
clase Figura porque se van a incluir en la aplicación otras clases para las que también in-
teresa saber si un objeto es mayor que otro. Así, se va a añadir la clase Fracción, para la
que nos interesa saber si una fracción es mayor que otra. En este caso, es conveniente
crear una interfaz porque aunque tanto las figuras como las fracciones se pueden compa-
rar, no se comparan de la misma manera: en el caso de las figuras, una es mayor que otra
en función de su área, mientras que en el caso de las fracciones, una es mayor que otra en
función de su valor. Entonces, se va a crear una interfaz llamada Comparar que incluya el
método esMayorQue.
Una vez seleccionada la clase Figura, se activa la opción del menú contextual Refactor >
> Extract Interface y aparece una ventana como la que se muestra la Figura 4.2, en la
que se pide el nombre de la interfaz y se deben seleccionar los métodos que se incorpo-
rarán a esta.
Interface name: | Comparar|

] Use the extracted interface type where possible
Use the extracted interface in 'instanceof' expressions
Generate 'OOverride' annotations (1.6 or higher)
Members to declare in the interface:
.* área() : double
e esMayorQuelFigura): int
e getColor(): Color
e getXCentro(): double
e getYCentro(): double
* perímetro() : double
e setColor(Color): void
e setXCentro(double): void
e setYCentro(double): void
Generate method comments

Figura 4.2. Al seleccionar el patrón de refactorización Extract Interface para

una clase, se pide el nombre que se quiere dar a la interfaz y los métodos
que se quieren colocar en ella.
'— ier [OMUNICACIONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
ME Extract Superciass
Permite crear a partir de una clase una superclase para ella, la cual contendrá los mé-
todos y atributos seleccionados de la clase en cuestión. Conviene tener en cuenta que
puede haber errores en los métodos de la nueva superclase si estos hacen referencia a
atributos de la clase original, esto es, a atributos de la subclase tras la refactorización.
ME ENE Use Supertype Where Possible

Sustituye todas las referencias a una clase por la de su superclase después de identifi-
car todos los lugares donde esta sustitución es posible. Resulta especialmente útil em-
plear este patrón después del patrón Extract superclass.
m P p
Mueve un atributo o un método de una clase a su superclase 0, en el caso de los méto-
dos, declara el método como abstracto en la superclase.
EE PUN Down
Mueve un conjunto de métodos y atributos de una clase a sus subclases.
BNE Extract Class

Sustituye un conjunto de atributos por una nueva clase. Todas las referencias a los atri-
butos son reemplazadas para acceder a la nueva clase que contiene los atributos. Se
proporciona la opción de crear métodos de acceso (set) y de consulta (get) para la nue-
va clase.
M ENE Change Method Signature

Permite cambiar la firma o cabecera de un método, esto es, su nombre, el nombre de sus
parámetros, los tipos de sus parámetros o el tipo de dato que devuelve. Se actualizarán
de manera automática todas las llamadas al método dentro del proyecto. Al seleccionar la
opción del menú contextual Refactor > Change Method Signature para un método, como,
por ejemplo, el método distancia de la clase Punto, aparecerá una ventana, como la de la
Figura 4.3, en la que se puede cambiar el modificador de acceso del método, el tipo de
dato que devuelve y su nombre. Asimismo, por cada uno de sus parámetros, haciendo clic
en el botón Edit..., se puede madificar su tipo de dato, su nombre y se le puede modifi-
car o asignar un valor por defecto. También es posible añadir nuevos parámetros pulsan-
do el botón Add, o eliminar un parámetro, estando este seleccionado y clicando sobre el
botón Remove. Los botones Up y Down sirven para cambiar el orden de los parámetros.
También se pueden cambiar, añadir o eliminar las excepciones que lanza el método en la
pestaña Exceptions.
4. OPTIMIZACIÓN Y DOCUMENTACIÓN |NFORMÁT|CA Y CO/“¡ ;
public
Parameters
Type Default value

[Punto m Z E ]
[ Keep original method as delegateto changed method

[ Mark as deprecated
Method signature preview:
public double distancia (Punto p)
O Method signature is unchanged.
Preview >
Figura 4.3. Al seleccionar el patrón de refactorización Change Method Signature

para un método, se pueden cambiar todos los elementos definidos en su cabecera:
modificador de acceso, nombre del método, tipo de dato que devuelve; nombre,
tipo y valor por defecto de sus parámetros; se pueden añadir parámetros o
eliminarlos y añadir, eliminar o modificar excepciones que lanza el método.
EE nline
Permite escribir en una sola línea la referencia a una variable o a un método y el uso de
dicha variable o método.
Por ejemplo, en el siguiente código del método simétrico de la clase Punto
public Punto simétrico() f

NH
Punto nuevoP = new Punto (this.x * -1, this.y);

return nuevoP;
W
E
se puede seleccionar la variable nuevoP y, en el menú contextual, elegir la opción Refactor >
> Inline. El resultado será el que se muestra a continuación, donde se ha sustituido, en
la instrucción return, la referencia a la variable nuevoP por el valor que se le asignó en la
instrucción anterior:
1 public Punto simétrico

()
2 return new Punto (this.x * -1, this.y);
3)
ME EN Introduce Parameter Object

Crea una clase a partir de un conjunto de parámetros de un método y sustituye dichos
parámetros por un objeto de la clase. Además, actualiza todas las llamadas al método
para sustituir esos parámetros por un objeto de la nueva clase.
A f KZOMUNICAUONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
MN ENE Extract Local Variable

Sustituye la expresión seleccionada por una nueva variable, de manera que cualquier re-
ferencia a esa expresión es sustituida por dicha variable en ese ámbito. Esta modifica-
ción solo afecta al método en el que se realiza la refactorización.
Por ejemplo, en el método main de la clase PruebaFigura, se selecciona la cadena “El

perímetro es:” para extraerla a una variable local llamada mostrarPerímetro. Al selec-
cionar esta cadena, se activa la opción de menú Refactor > Extract Local Variable y se
hace clic en el botón Preview, para poder ver los diferentes lugares del método donde
se va a realizar la sustitución, la cual se llevará a cabo tras clicar sobre el botón OK
(Figura 4.4).
a Eá PruebaFigura.java - Ejercicios/src/figuras
G PruebaFigura
4 Y) é mainíString[])
“E Add variable declaration
“El Replace expression with variable reference
[V] E Replace expression with variable reference v
D) PruebaFigura.java Da | £ SA
Original Source
1 switch (opción) 17 String mostrarPerímetro = "El perímetro es: ";
f case 1: 18switch (opción)
System.out.print ("Introduzca el lado 1 de 19 1 case 1:
double ladol = teclado.nextDouble() ; System.out.print ("Introduzca el lado
System.out.print ("Introduzca el lado 2 de double ladol = teclado.nextDouble
():
double lado?2 = teclado.nextDouble
(); System.out.print ("Introduzca el lado
System.out.print ("Introduzca el lado 3 de double lado2 = teciado.nextDouble
():
double lado3 = teclado.nextDouble
(); System.out.print ("Introduzca el lado
Triángulo t = new Triángulo
(x, y, Color.re double lado3 = teciado.nextDouble()
System.out.printlin ("El perímetro es: " + — Triángulo t = new Triángulo (x, y, Colo:
System.out.printin ("El área: " + t.área()| 27 System.out.printin (mostrarPerímetro +
break: Svstem.out.printin ("El área: " + t.ári Y
>
Figura 4.4, Al seleccionar el patrón de refactorización Extract Local Variable para una expresión, se pueden
cambiar todas las ocurrencias de esa expresión por una variable cuyo nombre se debe indicar.
ME Extract Constant
Sustituye un número o una cadena de caracteres por una constante. Todas las aparicio-
nes del número o cadena son sustituidas por la constante indicada.
No obstante, se pueden visualizar los lugares donde se va a realizar el cambio y selec-

cionar aquellos donde se desea que se refactorice, aunque lo habitual es que se desee
que el cambio se lleve a cabo para todas las apariciones del número o cadena de ca-
racteres.
El objetivo es que el valor literal se ubique en un solo lugar para facilitar su modificación,
si fuera el caso.
4. OPTIMIZACIÓN Y DOCUMENTACIÓN INFORMÁTYICOCAMU
Solución
Se selecciona la cadena en el método indicado, se activa la opción de menú contextual

Refactor > Extract Local Variable y se hace clic en el botón Preview. Se podrán ver enton-
ces los diferentes lugares del método donde se va a realizar la sustitución, tal y como se
muestra en la Figura 4.5.
a V]é! PruebaFigura.java - Ejercicios/src/figuras
a V PruebaFigura
Y] El Add constant declaration
ae main(String[])
Y) ] Replace expression with constant reference
() Pruebafigura,java MILASA
20.ectangulo r = new Rectangulo (x, 20 ectangulo r = new Rectangulo
21 ystem.out.println (mostrarPerime 21 ystem.out.println (mostrarPe
22 ystem.out.printin (MEl área: " + 22 ystem.out.printin (ÁREA + r.
23 reak; 23 reak;
243: 24 3:
25 ystem.out.print ("Introduzca el 25 ystem.out.print ("Introduzca
26 .0uble lado = teclado.nextDouble ( 26.0uble lado = teclado.nextDoul
27 uadrado c = new Cuadrado (x, y, d 27 uadrado c = new Cuadrado(x,
28 ystem.out.printin (mostrarPerime 28 ystem.out.printin (mostrarPe
29 ystem.out.printin ("El área: " + 29 ystem.out.printin ("El área:
<
Figura 4.5. Al seleccionar el patrón de refactorización Extract Constant para una expresión, se pueden
cambiar todas las ocurrencias de esa expresión por una constante cuyo nombre se debe indicar.
La sustitución se llevará a cabo tras clicar sobre el botón OK.
MN ENE Convert Local Variable to Field

Convierte una variable local de un método en un atributo privado de la clase correspon-
diente. Tras la refactorización, todas las referencias a la variable local son sustituidas por
el atributo. Si la variable es inicializada en su declaración, esta refactorización mueve di-
cha inicialización a la declaración del atributo, al método donde se usa o al constructor
de la clase.
A modo de ejemplo, se puede convertir la variable local mostrarPerímetro, que se creó

antes dentro del método main de la clase PruebaFigura, en un atributo de la clase. Para
ello, se selecciona esta variable y se activa la opción de menú Refactor > Convert Local
Variable to Field. Aparecerá una ventana (Figura 4.6), donde se debe asignar un nombre
A Y COMUNICACIÓNES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
al atributo, indicar su modificador de acceso y dónde se desea que se lleve a cabo su ini-
cialización (en la declaración del atributo o en el método en el que se encuentra).
Field name: W mostrarPerímetro
Access modifier
Opublic — Oprotected Opackage 0) private
0) Current method
) Class constructors
[Y] Declare field as 'static'

[ ]Declare field as final'
Figura 4.6. Al seleccionar el patrón de refactorización Convert Local Variable

to Field para una variable local, se pueden cambiar todas las ocurrencias
de esa variable por un atributo de la clase.
Al pinchar sobre el botón Preview, Eclipse también permite ver los efectos que tendrá el
cambio realizado (véase Figura 4.7).
4 [V| PruebaFigurajava
- Ejercicios/src/figuras
a V| E Pruebafigura
a ] f main(String[])
[v] $El Convert local variableto field
[3] PruebaFigura.java
7public static void main(String[] args) ( 74
£ int opción; 8
sdo í Spublic static void main (String[] args) (
opción = mostrarMenú(); 10 int opción;
if (opción != 4)1 11 do í
Scanner teclado = new Scanner (System.in): opción = mostrarMenú ();
System.out.print ("Introduzca la coordenada x del centro if (opción != 4)1
double x = teclado.nextDouble
(): Scanner teclado = new Scanner (System.in):
System.out.print ("Introduzca la coordenada y del centro System.out.print ("Introduzca la coordenada x del cel
double y = teclado.nextDouble (): double x = teclado.nextDouble
();
String mostrarPerímetro = "El perímetro es: "; System.out.print ("Introduzca la coordenada y del cel
3 switch (opción) double y = teclado.nextDouble
(): v
< _ _ >
Figura 4.7. Ventana que aparece al hacer clic en el botón Preview y en la que se visualizan los cambios
que supone la conversión de una variable local a un atributo de la clase.
Los cambios se llevarán a cabo al pulsar sobre el botón OK.
ME Extract Method
Convierte un conjunto de instrucciones en un método. Eclipse determinará de manera au-

tomática los parámetros y el valor de retorno del método. Es útil para acortar métodos
excesivamente largos o para extraer porciones de código repetidas en varias partes de
una aplicación.
4. OPTIMIZACIÓN Y DOCUMENTACIÓN INFORMÁTICA Y CO/X"1 ;
Para ilustrar esto, en el método main de la clase PruebaFigura se podría asignar un méto-
do a cada bloque de código que se ejecuta al seleccionar cada opción de menú. En ese
caso, se seleccionaría la porción de código entre case 1 y la correspondiente instrucción
break y se activaría la opción de menú Refactor > Extract Method. Aparece entonces una
ventana en la que se debe asignar un nombre al método (procesarTriángulo) y un modifi-
cador de acceso (private). En dicha ventana se visualizan sus parámetros y, en la parte
inferior, la cabecera del método resultante (Figura 4.8).
Method name: — procesarTriángulo|
Access modifier: C) public C) protected C) package () private

Parameters:
Type
Scanner
double
double
String
[]Declare thrown runtime exceptions

[ Generate method comment
[ Replace additional occurrences of statements with method
Method signature preview:
private static void procesarTriángulo (Scanner teclado,
double x, double y, String mostrarPerímetro)
[ Preview>_
Figura 4.8. Al seleccionar el patrón de refactorización Extract Method

para un bloque de código, se le da un nombre y un modificador
de acceso al método y Eclipse ajusta automáticamente sus parámetros
y el valor de retorno.
Además, se puede visualizar cómo quedará el código haciendo clic en el botón Preview.
La refactorización se llevará a cabo pinchando sobre el botón OK.

Uso del patrón de refactorización Extract Method en Eclipse
Sustituye cada una de las porciones de código en las que se procesa un rectángulo y un
cuadrado del método main por un método, de manera similar a como se ha hecho para
las instrucciones mediante las que se procesaba un triángulo.
M ENEN Encapsulate Field

Este patrón sustituye todas las referencias a un atributo de una clase por los correspon-
dientes métodos de consulta (get) y de acceso (set).
Por ejemplo, se podrían encapsular los atributos x e y de la clase Punto. Para ello, se
selecciona el atributo x y se activa la opción Refactor > Encapsulate Field del menú
A 1'1/ (…OMUNICACIONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
contextual. Eclipse indicará los nombres de los métodos de consulta y acceso que se
usarán para el encapsulamiento, que serán los presentes en la clase, en caso de que
ya estén declarados. Como siempre, al hacer clic en el botón Preview, es posible ver los
cambios que supondría llevar a cabo esta refactorización, la cual se activará al pulsar el
botón OK (Figura 4.9). Se debe hacer lo mismo para el atributo y.
Changes to be performed $ | y
D ¿,E Punto.java - Ejercicios/src/figuras
m Punto.java |>N | & & 4º B

7E=0: 7 SeEX(O); A
8y= 0; 8y= 0;
9)
10
11 public Punto(double x, double y) 11public Punto(donble x, doubli
12 this.xIelk: 12 this.setX(x);
13 this.y = y; 13 this.y = y:
14) 14)
15 15
16public Punto (Punto p)1 16public Punto (Punto p)!
17 EE 17 setX (p.getX()):
18y = p.y; 18y = p.y;
19) 19)
<
Figura 4.9. Al seleccionar el patrón de refactorización Encapsulate Field

para un atributo, se sustituyen todos los usos de este atributo por una
llamada al método get correspondiente y todas las asignaciones de valor
a dicho atributo por una llamada al método set que corresponda.

Uso del patrón de refactorización Encapsulate Field en Eclipse
Encapsula todos los atributos de la clase Triángulo del proyecto figuras.
ME 4.1.4.0tras operaciones de refactorización en Eclipse

Eclipse permite almacenar en un script los cambios que han supuesto las refactorizacio-
nes realizadas. Para ello, es necesario seleccionar la opción de menú Refactor > Create
Script. En la pantalla que se muestra, se pueden seleccionar las refactorizaciones que se
quieren almacenar en el script. También es posible cargar un script de refactorizaciones
para aplicarlo por medio de la opción de menú Refactor > Apply Script.
Además, es posible consultar las refactorizaciones que se han llevado a cabo visuali-
zando un histórico de refactorizaciones. A tal fin, se elige la opción de menú Refactor >
> History. Entonces, se pueden seleccionar las refactorizaciones que se desea consultar
y, al colocarse sobre cada una de ellas, se muestra información detallada sobre cada re-
factorización (véase la Figura 4.10).
4. OPTIMIZACIÓN Y DOCUMENTACIÓN INFORMÁTICA Y CQ/X1
Refactoring History
Browse and edit the workspace refactoring history.
Refactoring history of workspace:

aE Ejercicios
4 1 Today (23 oct 2021)
O 12:23 Extract method 'procesarTriángulo'
O 11:49 Etract local variable 'mostrarPerímetro'
O 11:18 Inline local variable 'nuevoP'
O 10:18 Extract interface 'Comparar
O 10:02 Rename type 'Rectángulo'
b 1D This Month (octubre 2021)
b EO 2021
b 1D Last Week (Week 41)
b D 2021
Details:
Extract local variable 'mostrarPerímetro' from expression "“El perímetro es: " +
- Original project: 'Ejercicios'
- Variable name: 'mostrarPerímetro'
- Destination method: 'figuras.PruebaFigura.main(...)'
- Variable expression: '"El perímetro es: "
- Replace occurrences of expression with variable
<
Figura 4.10. Al seleccionar la opción de menú Refactor > History,

se muestra un histórico de refactorizaciones realizadas. Al colocarse
sobre cada una de ellas, se obtiene información detallada.
Por último, se pueden eliminar las refactorizaciones que se deseen del historial, seleccio-
nándolas y haciendo clic en el botón Remove.
M 4.7. Analizadores de código

Los analizadores de código son herramientas que realizan un análisis estático del códi-
go fuente. Estos analizadores evalúan el código fuente sin llegar a ejecutarlo. El objetivo
es una mejora del código fuente sin modificar su comportamiento, que es exactamente el
mismo fin que el de la refactorización. Sin embargo, en el caso de la refactorización, es
el programador o la programadora quien debe detectar los síntomas de código mejorable
(bad smells) y aplicar, entonces, el patrón de refactorización que permite eliminar esos
síntomas. Los analizadores de código automáticamente detectan los síntomas y aportan
también de forma automática una solución que la persona encargada de la programación
puede decidir si aplicar o no.
Los analizadores de código realizan un análisis léxico y sintáctico del código fuente y
si detectan que este es mejorable, lo indicarán y propondrán la manera de realizar la
mejora.
La función principal de los analizadores de código es encontrar porciones de código que

puedan generar efectos adversos como:
E Reducir el rendimiento.
E Provocar errores.
E Crear problemas de seguridad.

Xfrl KOMUNICAC'ONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
E Tener una excesiva complejidad.
E Complicar el flujo de datos.
Los analizadores de código son herramientas automáticas que realizan un análisis está-
tico del código fuente con el fin de detectar deficiencias en este y proponer mejoras, para
lo que se basan en una serie de reglas predefinidas. Si el análisis del código es realiza-
do de manera manual por parte de una persona, recibe más bien el nombre de compren-
sión de programas o revisión de código.
Por un lado, existen analizadores de código gratuitos y de pago y, por otro lado, de código
abierto y de código cerrado. En este sentido, PMD (Programming Mistake Detector) es un
analizador de código gratuito y de código abierto. PMD es capaz de detectar errores co-
munes de programación como:
E Variables, métodos y parámetros no utilizados.
Bloques vacíos de sentencias catch, try, finally, switch, etc.
Expresiones lógicas que se pueden simplificar.
Código que no se ejecuta nunca porque es inalcanzable.
Código duplicado.
E Clases con complejidad ciclomática elevada.
Este analizador de código está orientado a los lenguajes de programación Java y Apex,
pero también se puede emplear con JavaScript, Visualforce, PL/SQL, ApacheVelocity, XML
y XLS.
Se puede instalar PMD como un módulo en Eclipse. Para ello, en Eclipse, se activa la op-
ción de menú Help > Eclipse Marketplace. Tras escribir PMD en la casilla Find y hacer
clic en el botón Go, uno de los módulos que aparece se llama pmd-Eclipse-plugin 4.28.0
(Figura 4.11). Para proceder a su instalación, se pulsa en el botón Install.
Eclipse Marketplace
Search| Recent | Papularí!mrhs[ Installed| Y Giving loT an Edgel

Find: [ PMO] » | [ANMarkets v| [All Categories
pmd-eclipse-plugin 4.28.0
PMD is a source code analyzer. It finds common programming flaws like unused variables,
empty catch blocks, unnecessary object creation, and so forth. It supports... more info
by PMD, BSD
PMD linter Source Code Analyzer code quality java
en7| () installs: 65,9K (1.534 last month) | Install
—
Marketplaces
] < Back Install Now >
Figura 4.11. Ventana que muestra el módulo PMD en Eclipse. Para instalar
este analizador de código, se clica sobre el botón Install.
4. OPTIMIZACIÓN Y DOCUMENTACIÓN INFORMÁTICA Y COA/'WH, ;
Después de aceptar el acuerdo de licencia, comienza la instalación del analizador de có-

digo, el cual estará operativo tras reiniciar Eclipse.
Realizados los pasos anteriores, en Eclipse, tras seleccionar un proyecto, un paquete o
una clase, se podrá elegir del menú contextual la opción de menú PMD > Check code.
Aquí se hará para el proyecto figuras. Aparecerá una pantalla como la de la Figura 4.12.
File Edit Source Refactor Navigate Search Project Run Window Help
EO 4-0-Q-255-:PMPEr iN-6-o970-0-1*
Q B
= S Package Explorer X = O ( Puntojava X dy Figurajava [ Pruebafigur... [7 Cuentajava
EEs as ? 1 package programas:
» 13 DClasestjemplo l
a Ejercicios 3 public class Punto
» m JRE System Library [JavaS£-14 + private double x;
.=m = 5 private double y;
E
>E :""'"”'"ºº' 7Epublic Punto(double x, double y)[
l - s 8o this.x = x;
» PA Compararjava Mieyo yr
59 Cuadradojjava 10 )
5 B Figurajava
» ] PruebaFigurajava 128 public donmble getX()!
> 5) Puntojave 13 return x:
5 B Rectangulojava 14
5 2 Triángulojava
5 JB programas “public double gerY()[
5 m JUnit 5 ? return y;
b S doc
public void setX(double x) (
21 this.x — x:
22 )
23
245 public void setY (double y)1
25 this.y = y;
26 )
> —
| Writable | Smart Insert | 18:2:224
Figura 4.12. Ventana que muestra, para el proyecto figuras, el resultado del análisis
de código realizado por PMD. Se indica por cada clase y mediante un color
distinto si se ha detectado algún defecto.
En esta pantalla, se muestra la vista PMD, que aparece por defecto cuando se solicita el
análisis de código. Por cada clase, se indica si se ha detectado algún defecto mediante
símbolos de determinados colores. Se puede ver el significado de estos colores eligien-
do la opción de menú Window > Preferences y luego seleccionando en la parte izquier-
da PMD (Figura 4.13).
type filtertot [ PMD-Plugin Options

> General
_ General options
» Ant [YIShow PMD perspective when checking code
» Ess [ Show PMD violations overview when checking code
» Gradie [ Show PMD violations outline when checking code
> Help Enable using Java Project Build Path. Disable if your Eclipse VM version ís incompatible with .class file versions.
iratpate [ICheek code after saving
» Java
5 Language Servers file types automatically (based on rule languages)
[Y] Determine applicable
> Maven
p Model Validation Priority levels
> Myyn PMD folder annotations can be enabled on the label decorations page Use custom names
_
5 OCL
> Papyrus
Sul
Dl
EE
116
5 Plug-in Development
> PMD Medium
> QVT Operational Editor Medium Low
> Run/Debug i Low
> Terminal
> TextMate
b UML Lab and Color.
Shape O r 09 D OOIOS ODPAVD><d
Validation . i " — 3
> Version Control (Team) eon: IT CEE
CICIENCIC
» WindowBuilder
» XML
» XML (Wild Web Developer)
» Xpand Violations review parameters
Use PMD style (// NOPMD comment)
OeO
Figura 4.13. Ventana que muestra la configuración de PMD en Eclipse, que

permite ver los distintos colores que se usan para identificar los defectos
detectados por PMD.
— 1 1OMUNICACIONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
Como se puede observar en la Figura 4.13, está activada la casilla de verificación que in-
dica que se muestre la vista PMD cuando se solicita la realización del análisis de código.
Las dos casillas de verificación que se muestran a continuación sirven para indicar si se
desea que se muestren dos áreas de la pantalla al hacer la revisión de código: Violations
Overview y Violations Outline, respectivamente. Más abajo se indican los símbolos que se
emplean para cada tipo de defecto descubierto al lanzar PMD: la gama va desde el co-
lor rojo, que se usa para los defectos más graves hasta el color morado para los avisos
(warnings). Se pueden modificar el símbolo y el color que se desea para la señalización
de cada tipo de defecto. En este caso, se marcarán las casillas de verificación para soli-
citar que se muestren en la vista PMD las áreas Violations Overview y Violations Outline.
Si se vuelve a analizar el código correspondiente al proyecto figuras, aparecerá la panta-
lla que se representa en la Figura 4.14.
File Edit Source Refactor MNavigate Search Project Run Window Help
NE DRIO:+-0-4-00 4-:PMePa - i-e00-5-|1* a BNE

3 Signin
H Package Explorer X ES 0 Eruntojara — $ Figurajava X D) Pruebafigur.. D Cuadradojava — *; = B e
b m JRE System Library [JavaSE-16] A P 3 public abstract class Figura implements Comparar ( AM
aba sic D 4 private Punto centro; E
> EB CuentaPrueba P 5 private Color color:
aE figuras 6
> B Compararjava D 7“public Figura (double x, double y, Color color)(
» 5) Cuadradojava 8 centro = new Punto (x, y):
.A Figurajava _9 this.color = color:
» 5) Pruebafigura,java 10 (
> 99 Puntojava
Di2Spublic double getXCentro
()1
> B5) Rectangulojava 13 return centro.gerX();
5 99 Triángulo.java
»— Violations Outline X
6“public double getYCentro() (|
P Line — created 7 return centro.getY():
37 MonOct251351:.. MethodNamingConvent
35 MonOct251351:.. MethodNamingConvent
31 Mon Oct25 13:51:... - MethodArgumentCouldl 205 mblio Calor getcolen)4
3 Mon Oct25 13:51:... - AbstractNaming - e )'º“"“ estara
< >
En Violations Overview X >' ! l>"|! f

Element * Violations — £ Violations/K... * Violations/M... Project
a E figuras 197 12312 4.69 Ejercicios
D > MElseStmtsMustUseBraces 5 312 0.12 Ejercicios
b > MethodArgumentCouldBeFinal 39 243.8 0.93 Ejercicios
» > AvoidinstantiatingObjectsinLoops 4 250 0.10 Ejercicios
= » D> CommentRequired 40 2500 095 Ejercicios
| Writable | Smartinsert | 16:28:328
Figura 4.14. Resultado del análisis de código de un proyecto en la vista PMD,

incluyendo dos nuevas áreas en la pantalla, que muestran información detallada
sobre los defectos hallados.
En el área Violations Outline, se muestran en detalle los defectos encontrados en la cla-

se cuyo código se está mostrando (en este caso, para la clase Figura). Los defectos apa-
recen ordenados por gravedad, de mayor a menor, y por cada uno de ellos, se indica la
línea de código afectada, cuándo se creó, la regla que incumple y el mensaje de error ge-
nerado. Por ejemplo, se señala como error grave que los nombres de los métodos área()
y perímetro() no cumplen con el patrón /a-z][a-zA-Z0-9]* por contener una letra con tilde.
Por otra parte, se consideran errores de gravedad media que no haya comentarios para
los atributos y métodos y que no se hayan usado llaves en las sentencias ¡f...else.
En el área Violations Overview, se muestra un resumen de los defectos encontrados en

todo el elemento analizado (proyecto, paquete o clase). Por defecto, se muestra por cada
error detectado, su número de ocurrencias y se puede desplegar para ver en qué clases
4. OPTIMIZACIÓN Y DOCUMENTACIÓN INFORMÁTICA Y CÚÍM
se han cometido. Haciendo clic en el botón con los tres puntos de la parte derecha, se
puede seleccionar Show violations to files, en cuyo caso los errores no aparecerán agru-
pados por tipo de error, sino por cada uno de los ficheros (clases) en que se han produ-
cido. Por cada fichero, se podrá desplegar la información para que se muestre cada uno
de los tipos de errores.
En el área Violations Overview, es posible seleccionar cada error detectado y, en su menú

contextual, elegir cada una de las siguientes opciones:
E Show details: se mostrará información detallada sobre el defecto encontrado.
E Mark as reviewed: si se marca esta opción, se da a entender que ya se ha revisado

el error y que se ha tratado de la forma más conveniente, por lo que en posteriores
análisis de código, no se volverá a mostrar.
E Remove violation: al seleccionar esta opción, se le indica al IDE que no se conside-

ra esta situación como un error.
E Disable rule: por medio de esta opción, se inhabilita la regla correspondiente a di-
cho error, por lo que todos los errores relacionados con esta regla no se volverán a
mostrar hasta que no se vuelva a habilitar la regla.
PMD se basa en una serie de reglas predefinidas para la detección de defectos, de ma-
nera que, al lanzar este analizador de código, se considerará errónea toda aquella por-
ción de código que incumpla alguna de las reglas establecidas. Se pueden consultar
estas reglas eligiendo la opción de menú Windows > Preferences y seleccionando en la
parte izquierda PMD > Rule Configuration (véase Figura 4.15).
Rule Configuration
|
A
Use global rule management
lf global rule management is enabled, you can deactivate rules here globally. This is
useful in order to ignore some rules temporarily. This setting overrides
project-specific settings.
» Install/Update
b Java
b Language Servers
[ | Rules grouped by [<no grouping> _v | Active rules: 446/446 4
b Maven
» Model Validation F Rule set Type Language *A
o
> Mylyn AbstractClassWithoutAbstractMethod Best Practices T l

vVYYVVVVVVY
b OCL AbstractClassWithoutAnyMethod Design XT

> Oomph [V] AbstractNaming Code Style XT
» Papyrus AccessorClassGeneration Best Practices — T
» Plug-in Development AccessorMethodGeneration Best Practices T
4 PMD AddEmptyString Performance XT
CPD Preferences [Y] ApexssertionsShouldincludeMessage Best Practices — -
File Filters ApexBadCrypto Security
Reports ApexCRUDViolation Security
Rule Configuration [Y] ApexCSRF Error Prone
> QVT Operational Editor -
» Run/Debug | Summary [ Rule -———
| Exclusions | -——-]
b Terminal I
Name
» TextMate AbstractClassWithoutAbstractMethod
> UML Lab
Validation Description
» Version Control (Team) The abstract class does not contain any abstract methods. An abstract class suggests
» WindowBuilder an incomplete implementation, which is to be completed by subclasses implementing the
H abstract methods. If the class is intended to be used as a base class only (not to be instantiated
b XML U directly) a protected constructor can be provided prevent direct instantiation.
< MRNCO More information can be found here.
(OO
Figura 4.15. Ventana que muestra las reglas que emplea PMD al analizar el código.
Si se activa la casilla de verificación de la parte superior, se pueden añadir reglas,
borrar las existentes o modificar las propiedades de las reglas.
TJ KOMUNICACIONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
Si se marca la casilla de verificación de la parte superior Use global rule management,

se pueden realizar modificaciones sobre las reglas. En la parte inferior, en la pestaña
Summary, se puede leer el nombre, la descripción de la regla y un ejemplo. Como se pue-
de observar en la Figura 4.16, en la pestaña Rule, se muestran las propiedades de la
regla (su prioridad, el conjunto de reglas al que pertenece, el lenguaje para el que se apli-
ca, etc.). Estas propiedades se pueden modificar, lo que tendrá efecto cuando se clique
sobre el botón Apply.
| type filter text Rule Configuration
d I global rule management is enabled, you can deactivate rules here globally. This is
» AN useful in orderto ignore some rules temporarily. This setting overrides
b Ant project-specific settings.
b eS
» Gradi
“ H';pº 5| Rules grouped
by | <no grouping> —< | Active rules: 446/ 446 4
b Install/Update A
. Rule O — Ruleset Type Language
» Language Servers AbstractClassWithoutAbstractMethod Best Practices — T
vYYVVVVVVYY
> Maven AbstractClassWithoutAnyMethod Design XT
» Model Validation AbstractNaming Code Style XT
[Y] AccessorClassGeneration Best Practices — T
AccessorMethodGeneration BestPractices — T
AddEmptyString Performance — X, T
ApexAssertionsShouldincludeMessage Best Practices — -
» Plug-in Development ApedBadCrypto Ceruety
4 PMD ApexCRUDViolation Security
CPD Preferences V ApexCSRF Error Prone
File Filters s
Reports [ Summary | Rule — [-——— [ Exclusions [ ---—-—W
Rule Configuration - , ;
» QVT Operational Editor Priority: ¡Waming —< D>
e Rule name : AbstractClassWithoutAbstractMethod
——]————] — —
b Terminal
b TextMate RuleSet: Best Practices _.
b UML Lab Implemented by: — Java class
Validation
» Version Control (Team) Implementation class: | net sourceforge.pmdlang,java.rule.bestpractices.AbstractClassWithoutAbstractMethodRule —|
p WindowBuilder Uses type resolution — []Uses data flow analysis
b XML
> XML (Wild Web Developer) Targetlanguage: — [Java Y | Min version: v
» Xpand
Oy e
Figura 4.16. Ventana en la que se pueden visualizar y modificar las propiedades de una regla
concreta en la parte inferior (pestaña Rule), haciendo clic en el botón Apply.
También es posible eliminar reglas o crear nuevas reglas haciendo clic en los botones
+ y % , respectivamente.
Si tras seleccionar en el explorador de proyectos un proyecto, un paquete o una clase, se
elige en el menú contextual la opción de menú PMD > Clear Violations Review, se elimi-
nan las revisiones de error realizadas, por lo que al volver a analizar el código, esos erro-
res volverán a aparecer si siguen presentes en el código o si se han cometido de nuevo.
En caso de que se active la opción del menú contextual PMD > Clear Violations, se eli-
minarán todas las violaciones detectadas. No obstante, si se vuelve a analizar el código,
estas volverán a aparecer.
Por otra parte, se puede utilizar PMD para encontrar código duplicado. Para ello, PMD in-
cluye un detector de código duplicado conocido como CPD (Cut and Paste Detector). Para
usarlo, se selecciona un proyecto en el explorador de proyectos y, en el menú contextual,
se elige la opción PMD > Find Suspect Cut and Paste. Emergerá una ventana como la de
la Figura 4.17.
4. OPTIMIZACIÓN Y DOCUMENTACIÓN
Choose a language for the Copy/Paste detection. You can

set the size of duplicated code by setting the minimum tile-size,
Language:
Minimum Tile-size:
Report
Y] Create report file (saved to project report folder)
Output format: —| Simple Text
oK
Figura 4.17. Ventana que se muestra al lanzar el detector de código

duplicado CPD que lleva incorporado el analizador de código PMD.
Será necesario elegir el lenguaje de programación (en nuestro caso, Java) y, en el campo
Minimum Tile-size, se debe indicar el número mínimo de tokens (identificadores, palabras
reservadas, operadores, etc.), los cuales, si se repiten en varios lugares de la aplicación,
se consideran código duplicado. El resultado de este detector o bien se puede mostrar
en el área inferior de la pantalla, o bien, si se mantiene activada la casilla de verificación
bajo la palabra Report, se generará un informe con el nombre pmd-report que se almace-
nará en la carpeta del proyecto y para el que se pueden elegir diversos formatos: texto
plano (archivo con extensión .txt), XML o CSvV.
Argot técnico
El vocablo token tiene diferentes acepciones. En el párrafo anterior, se ha usado este término
con el siguiente significado: «cadena de caracteres que tiene un significado coherente en
cierto lenguaje de programación».
En el Apartado 4.3.2, se usa otra acepción de token, que se traduce por “identificador”.
En ese caso, se usa este identificador a modo de contraseña para la protección de cierta
información sensible.
EN 4.3. Control de versiones

El software está sometido a continuos cambios, no solo durante las tareas de desarrollo
que se llevan a cabo antes de que el producto sea entregado al cliente (análisis, diseño,
programación y pruebas), sino también después. Esto ha llevado a que se incluya la ta-
rea de mantenimiento dentro de las fases del desarrollo de una aplicación informática.
Aparte de dicha tarea, ha surgido también la necesidad de otra nueva labor, más de
gestión que técnica, que se debe llevar a cabo de manera paralela a las tareas técnicas
de desarrollo (análisis, diseño, etc.) y que se conoce como gestión de la configuración
del software (GCS). Esta tarea tiene fundamentalmente cuatro objetivos ante cualquier
cambio:
u “OMUNICACIONES 4. OPTIMIZAC
Y DOCUMENTACIÓN
IÓN
1. Identificar el cambio.
2. Controlar el cambio.
3. Garantizar que el cambio se implemente de manera adecuada.
4. Informar de los cambios aplicados a todos aquellos a los que pueda afectar.
P
Recuerda O
A la tarea de gestión de la configuración del software (GCS) ya se hizo referencia en el
Apartado 1.6, en el que se señaló que, además de las actividades técnicas típicas del
proceso de desarrollo de software (análisis, diseño, programación, etc.), hay otra serie de
tareas de apoyo a todo el proceso, más de gestión que técnicas, una de las cuales Pressman
(2010) llamó administración de la configuración del software, que tiene por objeto
administrar los efectos del cambio a lo largo del proceso de desarrollo de software. Se trata
de las mismas tareas pero con distinto nombre.
Como es sabido, el desarrollo de un producto de software, a no ser que este sea trivial,
se debe descomponer en una serie de tareas como consecuencia de las cuales se obtie-
nen una serie de productos intermedios hasta llegar al producto final (programa ejecuta-
ble) deseado por el cliente. Se puede afirmar, por tanto, que la configuración del software
está formada por una serie de elementos de configuración (EC) aprobados en un mo-
mento dado del ciclo de vida. A medida que evoluciona el software, como consecuencia
de la realización de uno o varios EC, o como consecuencia de una nueva versión de uno
o varios EC, surge una nueva configuración del software. Normalmente, se trabaja con
aquella configuración del software formada por las últimas versiones de los EC corres-
pondientes.
Los EC pueden ser de dos tipos: básicos o agregados, donde un EC agregado se pue-
de dividir en varios EC básicos. Así, por ejemplo, un EC agregado lo constituye el código
fuente de la aplicación completa, y un EC básico, el código fuente de una clase.
La GCS debe gestionar los EC, identificándolos, controlándolos, informando acerca de su

estado y validando su contenido. El objetivo de la GCS es facilitar el trabajo con los EC
y los métodos para construir una configuración software que satisfaga las necesidades
del cliente.
Conforme avanza el proyecto, se crearán nuevas versiones de los EC. El término versión
tiene diferentes acepciones en el diccionario de la RAE, pero la que más directa aplica-
ción tiene en nuestro ámbito es la siguiente: «cada una de las formas que adopta la re-
lación de un suceso, el texto de una obra o la interpretación de un tema». Por lo tanto,
este concepto hace referencia a las diferentes formas que puede adoptar un EC a lo lar-
go su existencia. Y por consiguiente, una tarea correspondiente a la GCS es la identifica-
ción de las versiones de cada EC.
En la actualidad, la GCS se puede llevar a cabo mediante herramientas de control de

versiones. Toda herramienta de este tipo hace uso de un repositorio, que se puede defi-
nir como un almacén que contiene toda la información sobre un proyecto, lo que incluye,
por tanto, todas las versiones de todos los EC que forman parte de la configuración del
4. OPTIMIZACIÓN Y DOCUMENTACIÓN |NFORMATÍCA | [r
software. La existencia de este depósito integrado posibilita el almacenamiento de las

relaciones existentes entre los diferentes EC, lo cual es fundamental para conocer los
impactos de los cambios realizados sobre el software. Gracias al repositorio, es posible
saber qué elementos del software se verán afectados, por ejemplo, por la realización de
una modificación en una parte de un diagrama de clases.
La GCS, según está regulada en el estándar IEEE 828-2005, consta de las siguientes ac-
tividades:
E Identificación de los EC: se establece un método claro y consistente para identificar

cada EC y cada una de sus versiones.
E Control de cambios: el objetivo de esta actividad es asegurarse de que los cambios

aceptados sobre un proyecto se incorporan a este sin causar problemas. Para ello,
ante una petición de cambio, se analiza y se evalúa su impacto, y tomando esto
como base, se aprueba o no el cambio solicitado. Si se acepta el cambio, se ge-
nera una orden de cambio que describe este y cómo se debe llevar a cabo, indica
las restricciones que se deben respetar y los criterios para su revisión. Una vez im-
plementado el cambio, se actualiza la versión del EC o de los EC afectados por el
cambio.
E Auditoría de configuración: tiene por objetivo comprobar si el cambio se implementó

correctamente. Para esto, se dispone de dos medios: revisiones técnicas formales
y auditorías de configuración. Las primeras se centran en determinar si el o los EC
cambiados son correctos desde el punto de vista técnico; las auditorías de configu-
ración pretenden averiguar otros aspectos: si se realizó el cambio especificado en la
orden de cambio, si se llevó a cabo una revisión técnica, si se aplicaron adecuada-
mente los estándares de ingeniería del software, si se siguieron los procedimientos
de la GCS para reflejar el cambio en el o los EC afectados, si los EC se actualizaron
correctamente, si se informó del cambio al personal afectado, etcétera.
E Generación de informes: se debe documentar de manera adecuada el cambio que

se ha realizado sobre la configuración del software para que los miembros del equi-
po de desarrollo puedan determinar qué EC deben utilizar, cuál está sujeto a peti-
ciones de cambio y cuáles conforman la versión construida.
ME 4.3.1.Gestión de versiones
Las versiones de un EC hacen referencia a las diferentes formas que va tomando este a
lo largo del proceso de desarrollo de software. Se considera que existen versiones a ni-
vel de cada EC y a nivel de la configuración del software completo.
Es posible representar las diferentes versiones de una configuración de software en for-

ma de grafo, donde los nodos se corresponden con las diferentes versiones numeradas
y los arcos muestran la transición de una versión a otra. A este respecto, hay dos tipos
de grafos:
1. Grafo de evolución simple: que se representa mediante una simple secuencia li-
neal de versiones de forma que cada revisión de una versión da lugar a una nueva
versión. No coexisten varias versiones en el tiempo.
" 3MUN'CACIONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
2. Árbol: en el que existe un tronco, donde está la versión principal, desde el que se
pueden crear ramas con el fin de realizar modificaciones sobre ellas para incorpo-
rar cambios al tronco, pero no modificándolo directamente, sino haciéndolo sobre
la rama en cuestión. Se llama cabeza a la última versión del tronco. Dado que el
producto que se entrega al cliente se encuentra en el tronco, siempre es necesa-
rio fusionar las ramas con el tronco, lo que consiste en unir con el tronco los cam-
bios realizados en una rama. Puede ocurrir que incluso sea preciso fusionar varias
ramas y luego fusionar el resultado con el tronco.
Cada vez que se crea una versión, a esta se le debe asignar una etiqueta. Los cambios
que incorpora una versión con respecto a la anterior llevan el nombre de delta y esta in-
formación se puede registrar en el repositorio de diferentes maneras:
E Deltas directos: se almacena la primera versión completa y los cambios que presen-
ta una versión con respecto a la anterior.
E Deltas inversos: se almacena la última versión completa y los cambios necesarios

para reconstruir cada versión anterior a partir de la siguiente.
E Marcado selectivo: se almacena el texto refundido de todas las versiones como una
secuencia en la que se indica por cada sección la versión a la que corresponde.
ME 4,3.2. Herramientas de control de versiones

Hoy en día es común emplear herramientas o sistemas de control de versiones que son
de gran ayuda en las tareas correspondientes a la GCS. Estos sistemas son especial-
mente útiles para posibilitar el trabajo colaborativo que caracteriza a todos los proyectos
de desarrollo de software. El modo de trabajo con estas herramientas es como se indi-
ca a continuación:
1. El proyecto se encontrará cargado en un repositorio en un servidor.

2. Se realiza una copia del proyecto desde el repositorio al equipo local del progra-
mador.
3. Se realizan los cambios necesarios sobre el código.

Se envían los cambios al servidor.
Las herramientas o sistemas de control de versiones han ido evolucionando a lo largo

del tiempo y, básicamente, se puede hablar de dos tipos de herramientas:
1. Sistemas centralizados: el repositorio del proyecto se encuentra en un servidor y

quienes desarrollan el software disponen de herramientas para acceder desde
su propio ordenador a este servidor, recuperar el proyecto, realizar cambios en
su equipo local y enviarlos al servidor. El principal inconveniente de estos siste-
mas es que si se produce un fallo en el servidor, se pierde toda la información del
proyecto si no se han realizado copias de seguridad y los usuarios no disponen
de copias en sus equipos locales. Son ejemplos de sistemas centralizados CVS

(Concurrent Versions System) y SVN (Apache Subversion).
2. Sistemas distribuidos: en este caso, el repositorio no se almacena en un único

servidor, sino que está replicado para cada desarrollador, lo que tiene la ventaja
4. OPTIMIZACIÓN Y DOCUMENTACIÓN |NFORMATICA | [Cf
de que si se produce un fallo en el servidor, el contenido del repositorio se puede

copiar a partir de la copia existente en los equipos de cada uno de los clientes.
Son ejemplos de sistemas distribuidos Git y Mercurial. Dado que Git es la herra-
mienta de control de versiones más empleada en la actualidad, se analizará en
detalle a continuación.
M Git
Git es una herramienta libre de control de versiones de software que fue creada por
Linus Torvalds durante el proceso de desarrollo del núcleo de Linux.
Trabajando con Git, los ficheros deben pasar por varias ubicaciones antes de quedar al-
macenados en el repositorio. Así, es posible distinguir las siguientes áreas:
E Área de trabajo (working area): se trata del directorio local de trabajo en el que se
crean los archivos primero y luego se modifican.
E Área de preparación (staging area): es una zona intermedia en la que se colocan los
archivos del área de trabajo que se encuentran en esta área pendientes de confir-
mación.
E Repositorio local (commit area): este repositorio debe ser creado en el equipo local
y es donde se almacenan los archivos con sus modificaciones y las diferentes ver-
siones antes de enviarlos al repositorio remoto. Normalmente, los archivos pasan
del área de preparación al repositorio local.
E Repositorio remoto: este repositorio se encuentra fuera del equipo local y es donde
se almacenan los ficheros totalmente confirmados. Es posible establecer una sin-
cronización entre el repositorio local y el remoto.
Por otro lado, en Git un archivo puede pasar por los siguientes estados:
E Fuera de seguimiento (untracked): se encuentran en este estado los archivos nuevos

creados en el repositorio local o añadidos a él. El resto de los estados se pueden
considerar estados bajo seguimiento.
E Modificado (modified): cuando los archivos han sido modificados en el repositorio

local, pero los cambios no se han confirmado en este repositorio, los archivos se
encuentran en estado modificado y en el área de trabajo.
E Preparado para confirmación (staged): cuando los archivos modificados en el orde-

nador local se han preparado para formar parte de la siguiente confirmación, se
dice que están en estado preparado y se encontrarán en el área de preparación.
E Confirmado (commited): después de hacer una confirmación (commit), los ficheros

preparados para su confirmación se almacenan en el repositorio local (commit area).
En Git se emplean una serie de comandos que es conveniente aprender. El objetivo de

estos comandos es el cambio de estado de los diferentes archivos de un proyecto hasta
que se crea la versión definitiva que se entrega al cliente. Hay que tener en cuenta que
los archivos se crean en modo local y, una vez confirmados los cambios realizados so-
bre ellos, deben subirse al repositorio remoto. Los comandos básicos son los siguientes:
A f (OMUNICACIONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
El git add: permite pasar un fichero o un directorio del área de trabajo al área de pre-
paración.
E git commit: confirma cambios realizados en el área de preparación, de manera que

los ficheros correspondientes pasan al repositorio local (commit area). Al confirmar-
los (commit), Git exige la escritura de un mensaje de confirmación.
E git push: permite pasar los cambios realizados en el repositorio local al repositorio
remoto.
E git pull: permite actualizar el repositorio local con los cambios más recientes del
repositorio remoto, de forma que los archivos que reflejan esos cambios llegan al
área de preparación.
E git clone: hace una copia del repositorio remoto en el repositorio local.
E git branch: permite crear una nueva rama.
E git checkout: permite cambiar a la rama indicada.
M git merge: permite fusionar las dos ramas indicadas.
En la Figura 4.18, se muestra cuáles son los comandos que permiten el paso de los fi-
cheros de un área a otra.
git commit
—
git pull / git clone
Figura 4.18. Diferentes ubicaciones por las que puede pasar un archivo gestionado con Git hasta que llega
al repositorio remoto y los comandos que permiten el paso de una ubicación a otra.
Aquí se estudiará cómo se trabaja con Git integrado en el IDE Eclipse. Para ello, primero,
se crea una carpeta, que se puede llamar EjemplosCtrolVersionesGit y será el nuevo espa-
cio de trabajo (workspace) para Eclipse, y otra carpeta que se puede llamar Repositorios-
Git para almacenar los repositorios locales de los proyectos.
Creación de un repositorio local

En primer lugar, se abre en Eclipse la vista Git seleccionando la opción de menú Window >
> Perspective > Open Perspective > Other > Git. Aparecerán entonces en la parte iz-
quierda de la pantalla tres opciones: 1) añadir un repositorio de Git local ya existente,
2) clonar un repositorio de Git o 3) crear un nuevo repositorio local de Git. Se elige esta
4. OPTIMIZACIÓN Y DOCUMENTACIÓN |NFORMÁT|CA Y C… |
última opción, tras lo cual, se pide indicar la ruta del repositorio (carpeta Repositorios-
Git) y el nombre del nuevo repositorio: Ejemplo1. En la ventana representada en la Figu-
ra 4.19, se puede observar que el nombre del repositorio se debe indicar después de la
ruta y que la rama que se crea por defecto se llama master. Se trata del nombre que Git
asigna a la rama principal, también llamada tronco.
Create a New Git Repository

Determine the directory for the new repository
Repository directory: | CalUsersUoselDesktoplParaninfo|VEDWRepositoriosGitVEjemplo!
Default branch name: | master

[]Create as bare repository
Figura 4.19. Ventana en la que se selecciona la ruta del repositorio y se le asigna un

nombre. Asimismo, se crea la rama principal o tronco del repositorio, a la que Git llama
por defecto con el nombre de master.
Al hacer clic en el botón Create, se crea el repositorio, cuya estructura se puede observar
en el área de repositorios Git, que aparece en la parte izquierda de la pantalla debajo del
área de proyectos (Figura 4.20). El Working Tree que se puede observar en esta área se
corresponde con el área de trabajo y se ubica en la carpeta asignada al repositorio local.
©|_.ff|¿.%| EÑ: =a
(E) Git Repositories X
4*_ _ Ejemplo1 [master] - C:'¡Useronse'&5BhopXParan¡nfo“x£[iReposutonos(5utí£jemplo1*….9r1
b el Branches
> Ka Tags
b > References
9 Remotes
4|(= Working Tree - CAUsersVose|DesktopParaninfoEDRepositoriosGitvEjemplo1
4 (= .git
E branches
= hooks
Figura 4.20. Estructura del repositorio que se acaba de crear y que se muestra en la parte
izquierda de la pantalla.
Creación de un proyecto Java

A continuación, se crea un nuevo proyecto en Eclipse, para lo que se abre la vista Java, a la
que se accede activando la opción de menú Window > Perspective > Open Perspective >
> Other > Java (default). Se crea el proyecto en la carpeta EjemplosCtrolVersionesGit y

se le asigna el nombre Proyecto1. Después, se asocia este proyecto al repositorio local
Ejemplo1 que antes se ha creado. Para ello, en el menú contextual del proyecto, se pul-
sa sobre la opción Team/Share Project... En la ventana que aparece (Figura 4.21), se se-
lecciona, en la casilla Repository, el repositorio Ejemplo1 y se clica sobre el botón Finish.
N.Í/Xi. Y COMUNICACIONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
Configure Git Repository

Select an existing repository or create a new one
[]Use or create repository in parent folder of project

Repository: Ejemplo! - CAUsersJoseDesktop|ParaninfoED RepositoriosGitVEjemplo1N.git
Working tree: CalUsersUoseDesktop|Paraninfo

ED RepositoriosGitvEjemplo1
Path within repository:
Figura 4.21. Al seleccionar el repositorio creado anteriormente, el proyecto queda asociado a él.
Como se puede observar en la Figura 4.22, en el área de proyectos, delante del nombre
del proyecto, aparece el símbolo > y además se indica que es la rama master. Con esto,
Eclipse informa a la persona que está programando que el proyecto está bajo el control
de versiones de Git.
File Edit Source Refactor MNavigate Search
-E -YO:k-0-4-
-Q-
H Package Explorer X BS 3
alic3 > Proyecto! [RepositoriosGit master]|
b BÍ JRE System Library [JavaSE-16]
S sre
Figura 4.22. Se muestra el proyecto que se acaba de crear en el explorador de paquetes de la vista Java.
El símbolo > antes del nombre del proyecto indica que está bajo el control de versiones de Git.
El siguiente paso es crear dentro del proyecto Proyecto1 un paquete llamado paquete1
y, dentro de este, una clase llamada Principal con un método main, como se muestra en
la Figura 4.23.
[] *Principal.java X =a
1 package paquetel; a
N
public class Principal (

0
».
public static void main (String[] args) (

6
System.out.println ("Estamos haciendo control de versiones con Git");

7
)
s
9
Figura 4.23. Contenido de la clase creada para el proyecto de prueba Proyecto1 con el que se van a controlar
las versiones a través de la herramienta Git.
4. OPTIMIZACIÓN Y DOCUMENTACIÓN INFORMÁT|CA Y Ci )
Validación de cambios en el repositorio local
Después, se validan estos cambios, esto es, se confirman (commit) para pasar este fi-
chero al área de preparación. Para ello, desde el menú contextual de cualquier elemento
del proyecto en el explorador de proyectos se selecciona la opción Team > Commit... Se-
guidamente, aparece una pantalla (Figura 4.24), en la que en el área Unstaged Changes,
se muestran los cambios que se han detectado en el área de trabajo que no han sido
validados, es decir, que no han pasado al área de preparación. Por otro lado, en el área
Staged Changes, se ven los cambios confirmados, es decir, los que están en el área de
preparación. En la parte derecha de la pantalla, hay un cuadro de texto para escribir el
mensaje correspondiente a la validación, información que es obligatorio rellenar.
EN Problems € Javadoc [E) Declaration EJ Console ¡y Git Staging X f Filter files S QH a '|_EE] 8 50
8 > Ejemplo1 [master]
Unstaged Changes (5) de $ E v (E CommitMessage £7

[% .elasspath - Proyecto! i Unbom branch: this commit will create the branch 'master'.
Es .gitignore - Proyecto!
[% .project - Proyecto!
E org.eclipsejdt.core.prefs - Proyecto1/.settings
[Z Principal.java - Proyecto1/src/paquete!
Staged Changes (0) - "
EfAuthor — [Jose <JoseQlose> ]

M Committer: | Jose <JoseBJose> |
Commit and Push... Commit
Figura 4.24. Pantalla desde la que se pueden seleccionar los cambios que se desean confirmar (commit)
para su paso al área de preparación. Para ello, Eclipse obliga a escribir un mensaje en el cuadro de texto
Commit Message.
Para confirmar los cambios, se arrastran los elementos correspondientes del área Unstaged
Changes al área Staged Changes, lo cual supone pasar los ficheros modificados del área
de trabajo al área de preparación. Si se desea que estos cambios sean confirmados en
el repositorio local, se debe escribir un mensaje en el cuadro Commit Message y clicar
en el botón Commit. Por otro lado, si se desea que los cambios lleguen al repositorio re-
moto, habrá que hacer clic en el botón Commit and Push.
Para continuar con esta práctica, después de escribir un mensaje en el cuadro Commit
Message y pulsar sobre el botón Commit, se puede realizar algún cambio adicional en el
método main de la clase Principal, por ejemplo, se puede escribir otro mensaje por pan-
talla. De nuevo, se activa la opción de menú contextual Team > Commit... De esta forma,
ya se han llevado a cabo dos confirmaciones o commits. Es posible visualizar el historial
de versiones de la clase Principal seleccionando en su menú contextual la opción Team >
> Show in History (véase la Figura 4.25).
Como se puede ver en la Figura 4.25, para el segundo commit, aparecen las etiquetas
master y HEAD. Como ya se indicó, Git llama master a la rama principal o tronco. Por otro
lado, HEAD hace referencia a la versión más reciente de una determinada rama o del
tronco.
x. /K¡. YI COMUNICACIONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
(E Problems € Javadoc [E) Declaration EJ Console ¿Sy GitStaging é) Histoy X $HEriE-aa-7 - e-*e3:c506
File: Proyecto1/src/paquete1/Principal.java [Ejemplo!]
ld Message Author Authored Date Committer Committed Date
…HEADij commit Jose 1seconds 290 Jose 1 seconds ago ñ]
ece9397 Primera confirmación Jose 12 hours ago Jose 12 hours ago
commir 360e0e570b8f985130ef5eSed693CE6EDODTEDC42 * | [ Proyecto1/src/paquete1/Principaljava

Author: Jose <JoseeJose> 2021-12-05 09:34:54
Committer: Jose <JosefJose> 2021-12-05 09:34:54
Parent: ece9397faalc4741b0078937627ea49544627635 (Primera confirmación)
Branches: master
Segundo commit
index 72b6f83..572a4cb 100644

-—— a/Proyecto1/src/paquetel/Principal.java
+++ b/Proyecto1/src/paquetel/Principal .java
ee -4,5 +4,6 EE
public static void main (String[] args) í
System.out.println ("Estamos haciendo control de versiones con Git"”);
+ System.out.printin ("Escribo otra línea para hacer un 2% commit ");
Figura 4.25. Seleccionando la opción del menú contextual Team > Show in History, se puede visualizar
el historial de versiones de un fichero. Se puede navegar por las distintas versiones y observar
las modificaciones que incorpora cada versión en relación con la anterior.
Al hacer doble clic sobre una versión, se pueden ver más en detalle los cambios reali-
zados (Figura 4.26). Así, si se hace doble clic sobre el primer commit, se muestra en la
parte derecha de la pantalla la versión actual y, a la izquierda, el contenido de la versión
correspondiente al commit seleccionado, marcando en azul los cambios que ha supuesto
una versión en relación con la otra.
[J] Java Source Compare -$ ME
4 as
Local: Principaljava Principaljava ece9397 (Jose)
1package paquetel; 1package paquetel; A
2 2
3public class Principal | 3public class Principal (
4 4
5 public static void main(String[] args) ( 5 public static void main(String[] args) (
6 System.GU€.println ("Estamos haciendo control de versiones c 6 System.out.printin ("Estamos haciendo control de versione
7 System.cut.printin ("Escribo otra línea para hac EE 7 »
ef » e)
9 s v
< > < >
(S) Problems E Javadoc S), Declaration EJ Console ¿Sy GitStaging ) Histoy X HE| 2- 0- -Me-*%3c50
File: Proyecto1/src/paquetel/Principaljava [Ejemplo1]
360e0e5 (master)(HEAD)Segundo commit Jose 1 seconds ago Jose 1 seconds ago
Figura 4.26. Historial de versiones de un fichero: si se hace doble clic sobre uno de los commits, se puede ver
en detalle los cambios realizados en esa versión.
Para seguir practicando la validación de cambios, se podría realizar un cambio adicional

consistente en mostrar otro mensaje en el método main de la clase Principal y confirmar
este cambio en el repositorio local. De esta manera, se habrían llevado a cabo tres con-
firmaciones o commits.
Creación de un repositorio remoto con GitHub

Para poder utilizar un repositorio remoto, se puede hacer uso de GitHub, que ofrece
la posibilidad de crear un repositorio en la nube. Con este fin, se accede al sitio web
https:// github.com/ y se pincha sobre el botón Sign up, para darse de alta y crear una
cuenta gratuita de GitHub.
4. OPTIMIZACIÓN Y DOCUMENTACIÓN |NFORMAT|CA Y (/N
A continuación, se crea un repositorio haciendo clic en el botón Create repository, tras lo

cual aparece una pantalla (véase Figura 4.27), en la que se debe dar un nombre al repo-
sitorio, se puede proporcionar una descripción para este y se indica que sea público para
que pueda ser visto por cualquiera en internet, si bien aquí se elegirá quién o quiénes
pueden confirmar los cambios (commit).
() Create a New Repository
€ >Ccl(a hnps//gnhubcom/new¡ º
Pulls Issues Marketplace Explore
Create a new repository

Arrepository contains all project files, including the revision history: Already have a project repository elsewhere?
Import a repository.
Owner * Repository name *

4 entomosparaninfo- — / - RepositorionemotoGit1 PA
Great repository names are short and memorable. Need inspiration? How about glowing-octo-broccoli?
Description (optionar)
Repositorio remoto de GitHub para pruebas
[ l: Public
- Anyone on the intenet can see this repository. You choose who can commit.
o Private
You choose who can see and commit to this repository.
Figura 4.27. Vista de la plataforma GitHub en la que, para crear un repositorio remoto, se
debe indicar el nombre, que el repositorio sea público y, opcionalmente, una descripción.
Al hacer clic en el botón Create repository, que aparece en la parte inferior de la pantalla,
se creará el repositorio. Después aparecerá otra pantalla como la que se representa en
la Figura 4.28, en la que se indica la URL del repositorio que se acaba de crear y se pro-
porcionan comandos para trabajar con este repositorio.
€) entornosparaninfo/Repositorion:
€ > C A githubcom/entomosparaninfo/RepositorioremotoGit1
Pulls Issues Marketplace Explore
E entornosparaninfo
/ RepositorioRemotoGit1 - Pubiic unvatch - 1 s 0
Ocode Olsues — T Pullrequests — O Actions— Mprojects Mwiki O security — [ Insights
Quick setup — if you've done this kind of thing before

CsetupinDesktop — or — HITPS SH https://eithub.com/entornosparaninfo/RepositorioRemotocit1.git a)
Get started by creating a new file or uploading an exísting file. We recommend every repository include a README, LICENSE, and
-gitignore.
...Or create a new repository on the command line

echo "% RepositorioRemotoGit1" >> README.md
git init
git add README.md
git comit -m "first comit"
git branch -M main
git remote add origin https://github.con/entornosparaninfo/RepositorioRemotoGit1.git
git push -u orígin main
Figura 4.28. Pantalla que aparece tras haber creado un repositorio remoto en GitHub.
Un dato muy relevante es la URL del repositorio creado, que se puede leer en la parte
superior de la pantalla.
] MUNICACIONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
GitHub no hace uso de la autenticación vía HTTPS (Hypertext Transfer Protocol Secure) con
la contraseña de la cuenta de GitHub por motivos de seguridad. Debido a esto, para so-
lucionar este problema, el cual impide subir ficheros al repositorio remoto, se debe crear
un identificador o token de acceso personal. Para ello, en nuestra cuenta de GitHub (ico-
no de arriba a la derecha), se selecciona la opción de menú Settings y se clica en el enla-
ce Developer settings de entre las opciones que se muestran a la izquierda en la pantalla
que aparece después. Seguidamente, se hace clic en el enlace Personal Access tokens
en el menú de la izquierda (Figura 4.29). En Note, se señala el uso que se va a dar al
token; en Expiration, se elige la opción No expiration; se marca la casilla de verificación
repo y, finalmente, se pulsa el botón de la parte inferior de la pantalla Generate token.
Pull requests - Issues Marketplace Explore
Settings / Developer settings
GitHub Apps New personal access token

OAuth Apps
Personal access tokens function like ordinary OAuth access tokens. They can be used instead of a password for Git over
Personal access tokens HTTPS, or can be used to authenticate to the API over Basic Authentication.
Note
GitHub Eclipse token

What's this token for?
Expiration *
No expiration + | Thetoken wil never expiret
GitHub stronaly recommends that you set an expiration date for your token to help keep your information secure.
Learn more
L
Select scopes
Scopes define the access for personal tokens. Read more about OAuth scopes.
repo Full control of private repositories
reposstatus Access commit status
Figura 4.29. Creación de un token de acceso personal en GitHub para poder subir ficheros al repositorio remoto.
Se indica para qué se va a usar y que no expire nunca. El token se creará al hacer clic en el botón Generate token.
Tras haber creado el token, se puede copiar al portapapeles, pues se necesitará para
configurar, desde Eclipse, la subida de archivos al repositorio remoto. Para realizar dicha
configuración, en Eclipse se debe abrir la vista de repositorios de Git, para lo que se acti-
va la opción de menú Window > Show view > Other > Git > Git Repositories.
Desde la vista Git Repositories, que se puede ver debajo del explorador de paquetes,
para el elemento Remotes, se elegirá del menú contextual la opción Create Remote...
Aparecerá una ventana (Figura 4.30) en la que se pueden dejar las opciones que apare-
cen por defecto y se hace clic en el botón Create.
Please enter a name for the new remote

You need to configure the new remote for either fetch or push; you can add
configuration for the other direction later
Remote name: | EE
(9) Configure push
O Configure fetch
(O)
Figura 4.30. Desde la vista Git Repositories en Eclipse se crea un repositorio

remoto para configurar posteriormente las subidas a dicho repositorio (push).
4. OPTIMIZACIÓN Y DOCUMENTACIÓN INFORMÁTICA
Y CON
Aparece entonces una ventana para configurar las subidas a este repositorio remoto (Fi-
gura 4.31). Para ello, se indica la URL del repositorio remoto que aparecía indicada en
GitHub (Figura 4.28). Al introducirla, se rellenan automáticamente los cuadros de texto
Host y Repository path. También, se debe indicar el nombre de usuario y el token de ac-
ceso personal de GitHub (no la contraseña del usuario de GitHub). Por último, se pincha
sobre el botón Finish.
Source Git Repository

Enterthe location of the source repository.
Location
URI: '1 https://github.com/entornosparaninfo/RepositorioRemotoGit1.git | Local Folder... Local Bundle File...
Host: | _g_ithub.com
Repository path: | /entornosparaninfo/RepositorioRemotoGit1.git
Connection
Protocol: [ https v
oe| ¡
Authentication
User: [ entnmos£araninfo
Password: W eoeooococoooooCooeoooCeoeOCocoeoeee
[]Store in Secure Store
Figura 4.31. Ventana en la que se configura la subida de archivos al repositorio remoto de GitHub,
proporcionando la URL de dicho repositorio, el nombre de usuario de GitHub y el token personal de acceso.
Validación de cambios en el repositorio remoto
Una vez se dispone de un repositorio remoto y se han configurado las subidas a dicho re-
positorio, se pueden subir los ficheros del repositorio local al remoto. Para ello, se dispo-
nen de varias opciones:
M Seleccionar para el fichero que se quiere subir la opción del menú contextual Team >
> Commit... y hacer clic en el botón Commit and Push (como el que se muestra en
la Figura 4.24), o bien en el botón Push HEAD si el fichero ya está confirmado en el
repositorio local.
M Seleccionar para el fichero que se desea subir la opción del menú contextual Team >
> Repository > Push Branch “master'...
m Seleccionar para el proyecto que se va a subir la opción del menú contextual Team >
> Remote > Push...
E Seleccionar para el proyecto que se desea subir la opción del menú contextual
Team > Push Branch “master”...
Al seleccionar el proyecto y la opción de menú Team > Remote > Push..., aparece una
ventana (Figura 4.32) con la opción de usar los datos del repositorio ya configurado, que
es lo que se seleccionará, y después se hará clic en el botón Next.
| A k“1/ COMUNICACIONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
Destination Git Repository

Enter the location of the destination repository.
(9) Configured remote repository:
¡oligin: https://github.com/entornosparaninfo/RepositorioRemotoGit1.git —
0) Custom URI:
Location
URI: Local Folder...
Host:
Repositary path:
Connection
Protocol:
Port:
Authentication
User:
Password:
Figura 4.32. Ventana en la que ya aparecen configuradas las subidas al repositorio remoto.
En la siguiente ventana que aparece (Figura 4.33), en la casilla situada bajo Source ref,
se elige lo que se quiere subir al repositorio remoto (en este caso, HEAD) y se clica en
el botón Add Spec.
Push Ref Specifications

Select refsto push.
Specifications for push

Source ref:
T» v| 4 Addspec
Remote ref to delete: " v| I Add Spec
Mode Source Ref Destination Ref Force Update Remove Force Update All
de Update - HEAD HEAD a
E Remove All
Add predefined specification Configured Push Specs All Branches
[ Save specifications in 'origin' configuration
Figura 4.33. Ventana en la que se indica qué parte del proyecto se desea subir al
repositorio remoto, seleccionándolo en Source ref y haciendo clic en el botón Add Spec.
Luego, se pulsa sobre Finish y, si se solicitan de nuevo los datos de autenticación (nom-
bre de usuario de GitHub y token personal de acceso), se introducen estos. El proyec-
to se subirá al repositorio remoto de GitHub. Si se va ahora a GitHub, se verá que, en el
repositorio creado (RepositorioRemotoGit1), aparece el proyecto que se acaba de subir.
4. OPTIMIZACIÓN Y DOCUMENTACIÓN INFORMÁTICA Y CQÍM ;
Creación de una rama y validación de esta en los repositorios local y remoto

Se verá a continuación cómo es posible crear una rama en el repositorio local, fusionarla
luego con el tronco y subirla al repositorio remoto.
Para crear una rama, en el área de repositorios Git, se elige para el elemento Branches
la opción del menú contextual Switch To > New Branch... (Figura 4.34). Se asignará un
nombre a la rama (por ejemplo, rama1) y se dejará marcada la casilla de verificación
Check out new branch, mediante la cual nos cambiamos a la rama rama/1, que se está
creando.
Create a new branch in repository Ejemplo1

Please choose a source branch and a name for the new
branch
Source: £% master
Branch name: | ramai|

Configure upstream for push and pull
When pulling:
Check out new branch
Figura 4.34. Ventana en la que se crea una nueva rama, llamada rama,
y nos movemos a ella.
Dentro del proyecto, se crea un nuevo paquete (paqueteRama1) con una clase llamada
Rama1, en cuyo método main, se mostrará un mensaje por pantalla.
A continuación, se confirma este cambio en el repositorio local mediante la opción Commit.

Si se selecciona para el proyecto la opción de menú Team > Show in History, se pueden
ver todas las confirmaciones (commits) realizadas y cómo, para la rama1, aparece el indi-
cador HEAD (Figura 4.35), pues se trata de la versión más reciente.
Eílpmblems G Javadoc [Declaration EJ Console ¿Sy Git Staging ) Histoy X HE| E-aa-y7 - -4350
roject: Proyecto1 [Ejemplo!]
[ 18fa6e4 Confirmación para cambio rama 1 Jose 16 seconds ago Jose 16 seconds ago
048eb52 master |Tercer commit Jose 31 minutes ago Jose 31 minutes ago
360e0e5 % Segundo commit Jose 4 hours ago Jose 4 hours ago
Figura 4.35. Vista de las diferentes versiones que se han creado para el proyecto, incluyendo la que se acaba
de crear a partir de la rama rama.
Para subir esta rama al repositorio remoto, se selecciona la rama rama1 en el área de
repositorios Git y la opción del menú contextual Push Branch... Se hace clic en el botón
Preview y luego en Finish en la siguiente pantalla, y entonces, la subida ya se habrá rea-
lizado, como se podrá observar en GitHub, donde se indica que hay dos ramas (master y
rama1) (véase Figura 4.36).
— 1 1OMUN|CACIOMES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
0 t Pull requests Issues Marketplace Explore [A E
E entornosparaninfo
/ RepositorioRemotoGit1 ' Public Ounwatch - 1 Astar 0 Y Fork 0
Ocode Olsues — 1 Pullrequests — O Actions — ] Projects Mwiki — O security — L Insights — 3 Settings
P master - | P 2branches QOtags Go to file Adá file - Code - About s
Switch branches/tags » Repositorio remoto de GitHub para

essebs2 6 hours ago 0) 3 commits pruebas
[ Find or create a branch...
mit 6 hours ago
Branches Tags
default . Releases
Y master
rama1
Create a new reiease
View al branches
Figura 4.36. Pantalla de inicio de GitHub para el repositorio remoto RepositorioRemotoGit1, donde se puede
observar que hay dos ramas (branches), pudiéndose seleccionar la rama master o la rama ramal.
Al seleccionar una rama, se puede navegar por todos sus ficheros.
Fusión de ramas
Para terminar, se explica a continuación cómo se pueden fusionar dos ramas en el re-
positorio local. A modo de ejemplo, aquí se fusionarán las ramas master y rama1. Para
ello, en Eclipse, en el área de repositorios Git, se hace doble clic sobre la rama master
con el fin de cambiar a esa rama. De hecho, el programa pregunta si se quiere hacer
un checkout a la rama master, a lo que se debe responder que sí, haciendo clic en el bo-
tón Check Out. A continuación, en el menú contextual de la rama master, se activa la op-
ción Merge (Figura 4.37).
29 Git Repositories X = B (2 Probems G =
El er|" S| [ : Repostor emplo! _
4 () Ejemplo! [rama1] - CAUsersVoselDesktopParaninfoVEDWRepositoriost | Id Message
4 25 Branches 18fabed
4 5 Local 048eb52 3
£ master 048eb52 Tercer com—!
, ramal 18fa6e4 Confirmació 39 - Check Out
E Remote Tracking 4 - Push Branch...
» Tags 28 CreateBranch...
Dil References 1 RenameBranch...
b 9 Remotes C
b E Working Tree - C:1UsersVJoselDes ENfIgurE Sranch.
$ Delete Branch Delete
. Synchronize with Workspace

ES Compare with Working Tree
[% Merge
y Rebase on
45 Reset...
Show In Alt+Shift+W »
Figura 4.37. Para fusionar la rama rama1 con el tronco (rama master), se selecciona
en el área de repositorios Git de Eclipse, para la rama master, la opción del menú
contextual Merge.
En la ventana que aparece después (Figura 4.38), se selecciona la rama que se desea
fusionar, en este caso, rama/1, y se clica en el botón Merge.
4. OPTIMIZACIÓN Y DOCUMENTACIÓN INFORMÁTICA Y (
Merge 'master'
Select a branch or tag to merge into the 'master' branch
type filter text
4 (= Local
9 master 048eb52 Tercer commit
£5. ramal 18fabe4 Confirmación para cambio rama 1
( Remote Tracking
as Tags
Merge options
(9) Commit (commit the result)
() No commit (prepare merge commit, but don't commit yet)
O Squash (merge changes into working tree, but don't create merge commit)
Fast forward options

(0) H afast-forward, only update the branch pointer
O Mafast-forward, create a merge commit
Onotafast-forward, fail
Figura 4.38. Ventana en la que selecciona la rama que se quiere fusionar con la rama
master y se confirma haciendo clic en el botón Merge.
Para que esta fusión se plasme en el repositorio remoto, se debe activar la opción Push
Branch del menú contextual para la rama master, y, en la siguiente ventana, hacer clic en
el botón Preview y, en la siguiente, pulsar el botón Push. Se indicará si se ha realizado
correctamente la subida al repositorio remoto.
Se puede corroborar si la subida ha sido exitosa accediendo a GitHub y entrando en la

rama master, en cuya carpeta, src, deben aparecer tanto el paquete paquete1 como el
paquete paqueteRama1, como se puede ver en la Figura 4.39.
Pull requests ¡Issues Marketplace Explore
aninfo | ubiic
/ RepositorioRemotoGit1
E entornospar Ounwatch = 1 | Wstar 0! Yrok 0
Ocode — O Issues 17 pull requests O Actions — [] Projects — [ wiki O Security — Y Insights — 83 settings
$ master - — RepositorioRemotoGit1 / Proyecto1 / src / Go to file Add file -
Jose and Jose Confirmación para cambio rama 1 18fases 6 hours ago O History
Ea paquetel Tercer commit 6 hours ago

B paqueteRamal Confirmación para cambio rama 1 6 hours ago
Figura 4.39. En CitHub, para la rama master, aparece tanto el contenido de la rama master antes de la fusión
(paquete paquete1) como el contenido de la rama rama1 (paquete paqueteRama1), puesto que ambas ramas
se han fusionado correctamente.
1OMUN|CACIONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
EN 4.4.Documentación
Uno de los componentes del software que se incluyó en la definición de software en el
Apartado 1.1 fue «información descriptiva tanto en papel como en formas virtuales que
describen la operación y uso de los programas», lo cual se refiere a la documentación
que debe acompañar a todo software cuando se entrega al cliente. Asf, se deben docu-
mentar las diferentes fases de cada proyecto, lo que proporcionará información relevan-
te al cliente y favorecerá la realización de las tareas de mantenimiento que afectan a la
mayoría del software que se crea.
Básicamente, se pueden distinguir tres tipos de documentos relacionados con el software:
1. Documentos que describen el resultado de las diferentes tareas del desarrollo de

software, excepto la de programación: documentos resultado de la fase de análisis
(especificación de requisitos del software), de la fase de diseño (documentación
de diseño) y de la fase de pruebas.
2. Documentos que describen el código fuente.
3. Documentos que describen el uso del software (manual de usuario).
No existen normas estandarizadas que describan cómo producir estos documentos. Lo

más adecuado es seguir un índice establecido para cada documento en la empresa de
desarrollo de software para la que se esté trabajando. Puede haber índices estandari-
zados para cada uno de los tipos de documentos indicados anteriormente, pero estos
siempre se pueden adaptar a la aplicación en concreto que se esté desarrollando. A con-
tinuación, se describen los formatos que se pueden seguir para la elaboración de dife-
rentes documentos.
ME 441 Estructura de los documentos

El documento resultado de la fase de análisis recibe comúnmente el nombre de Especifi-
cación de requisitos del software (ERS) y según Piattini et al. (2007) su objetivo es «des-
cribir los requisitos esenciales (funciones, rendimiento, diseño, restricciones y atributos)
del software y de sus interfaces externas».
Seguidamente, se ofrece el índice de ERS propuesto por el IEEE en la norma IEEE 830.
No es obligatorio seguir este Índice, pero toda ERS debería incluir toda la información
que aquí se indica:
1. Introducción.
1.1. Objetivo.
1.2. Ámbito.
1.3. Definiciones, acrónimos y abreviaturas.
1.4. Referencias.
1.5. Visión general del documento.
4. OPTIMIZACIÓN Y DOCUMENTACIÓN INFORMÁTICA Y CO/X 1
2. Descripción general.
2.1. Perspectiva del producto.
2.2. Funciones del producto.
2.3. Características del usuario.
2.4. Limitaciones generales.
2.5. Supuestos y dependencias.
2.6. Requisitos futuros.
3. Requisitos específicos.
3.1. Interfaces externas.
3.1.1. Interfaces de usuario.
3.1.2. Interfaces de hardware.
3.1.3. Interfaces de software.
3.1.4. Interfaces de comunicaciones.
3.2. Requisitos funcionales.
3.3. Requisitos de rendimiento.
3.4. Restricciones de diseño.
3.5. Atributos de calidad del sistema.
3.6. Otros requisitos.
4. Apéndices.
Con relación a la documentación del diseño, esta es definida por el IEEE como una des-
cripción del software creada para facilitar el análisis, la planificación, la implementación y
la toma de decisiones. Este documento debe explicar cómo un producto de software será
construido para satisfacer un conjunto de requisitos técnicos. Una ERS describe el qué
del proyecto, mientras que la documentación del diseño se enfoca en el cómo. Este do-
cumento debe servir de base para el equipo de desarrollo y otros interesados en el pro-
yecto. Debería contener toda la información necesaria para que un programador pueda
escribir el código. El índice de documentación de diseño propuesto por el IEEE en la nor-
ma IEEE 1016 es el siguiente:
1. Introducción.
1.1. Objetivo.
1.2. Ámbito.
1.3. Visión general del documento.
1.4. Material de referencia.
1.5. Definiciones y acrónimos.
2. Visión del sistema.
3. Arquitectura del sistema.

3.1. Diseño de la arquitectura.
3.2. Descripción de la arquitectura.
3.3. Justificación del diseño.
A x( ÍOMUNICACIONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
4. Diseño de datos.
4.1. Descripción de los datos.
4.2. Diccionario de datos.

5. Diseño de componentes.
6. Diseño de la interfaz hombre-máquina.
6.1. Visión de la interfaz de usuario.

6.2. Imágenes de las pantallas.
6.3. Objetos de las pantallas y acciones.
7. Matriz de requisitos.
8. Apéndices.
En cuanto a la documentación de las pruebas, es conveniente que, para una buena orga-
nización de estas y para asegurar su reutilización, se documenten tanto el diseño de las
pruebas como el resultado o ejecución de estas. El estándar IEEE 829 propone una serie
de documentos cuya utilidad se describe en el Apartado 3.4. A continuación se muestran
los índices propuestos en dicho estándar para cada uno de los documentos.
PLAN DE PRUEBAS DEL SOFTWARE
1. Identificador del documento.

2. Introducción y resumen de elementos y características a probar.
3. Elementos software que se van a probar.
4. Características que se van a probar.
5. Características que no se prueban.
6. Enfoque general de la prueba (actividades, técnicas, herramientas, etc.).
7. Criterios de paso/fallo para cada elemento.
8. Criterios de suspensión y requisitos de reanudación.
9. Documentos que se van a entregar.

10. Actividades de preparación y ejecución de pruebas.
11. Necesidades de entorno.

12. Responsabilidades en la organización y realización de las pruebas.
13. Necesidades de personal y de formación.
14. Esquema de tiempos (con tiempos estimados, hitos, etc.).
15. Riesgos asumidos por el plan y planes de contingencia para cada riesgo.
16. Aprobación y firmas con nombre y puesto desempeñado.

ESPECIFICACIÓN DEL DISEÑO DE LAS PRUEBAS
1. Identificador para la especificación, con una referencia al plan asociado.

2. Características que se van a probar de los elementos software.
4. OPTIMIZACIÓN Y DOCUMENTACIÓN INFORMÁTICA Y COÍM
3. Detalles sobre el plan de pruebas, incluyendo las técnicas de prueba específi-

cas y los métodos de análisis de resultados.
4. Identificación de cada prueba:
4.1. Identificador.
4.2. Casos que se van a utilizar.
4.3. Procedimientos que se van a seguir.
D Criterios de paso/fallo de la prueba.
ESPECIFICACIÓN DE CASO DE PRUEBA
1 Identificador único de la especificación.

2. Elementos software que se van a probar con indicación de las características
que ejercitará cada caso.
Especificaciones de cada entrada requerida para ejecutar el caso de prueba, in-
cluyendo las relaciones entre las diversas entradas, por ejemplo, la sincroniza-
ción de estas.
Especificaciones de todas las salidas y las características requeridas (por ejem-
plo, el tiempo de respuesta) para los elementos que se van a probar.
Necesidades de entorno (hardware, software, personal, etc.).
Requisitos especiales de procedimiento.
Dependencias entre casos de prueba, identificando los casos que se han de
ejecutar antes de este caso de prueba.
ESPECIFICACIÓN DE PROCEDIMIENTO DE PRUEBA
1. Identificador único de la especificación y referencia a la correspondiente especi-

ficación de diseño de prueba.
Objetivo del procedimiento y lista de casos que se ejecutan con él.
Requisitos especiales para la ejecución (por ejemplo, entorno especial o perso-
nal especial).
Pasos en el procedimiento. Se debe indicar la manera de registrar los resulta-
dos y los incidentes de la ejecución, y además:
La secuencia necesaria de acciones para preparar la ejecución.
Acciones necesarias para empezar la ejecución.
Acciones necesarias durante la ejecución.
Cómo se realizarán las medidas, por ejemplo, el tiempo de respuesta.
Acciones necesarias para suspender la prueba.
Puntos para reinicio de la ejecución y acciones necesarias para el reinicio en
estos puntos.
M Acciones necesarias para detener ordenadamente la ejecución.

M Acciones necesarias para restaurar el entorno y dejarlo en la situación exis-
tente antes de las pruebas.
E Acciones necesarias para tratar los acontecimientos anómalos.
jÍ,»'/XX Y COMUNICACIONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
HISTÓRICO DE PRUEBAS
1. Identificador.
2. Descripción de la prueba: elementos probados y entorno de la prueba.
Anotación de datos sobre cada hecho ocurrido:
M Fecha y hora.
M Identificador del informe de incidente.

4. Otras informaciones.
INFORME DE INCIDENTE
1. Identificador.
2 Resumen del incidente.
Descripción de datos objetivos (fecha y hora, entradas, resultados esperados,
etc.).
4. Impacto que tendrá sobre las pruebas.
INFORME RESUMEN DE LAS PRUEBAS
1- Identificador.
2. Resumen de la evaluación de los elementos probados.
Variaciones del software respecto a su especificación de diseño, así como las
variaciones en las pruebas.
Valoración de la extensión de las pruebas (cobertura lógica, funcional, de requi-

sitos, etc.).
Resumen de los resultados obtenidos en las pruebas.

Evaluación de cada elemento software sometido a pruebas.
Resumen de las actividades de prueba, incluyendo el consumo de todo tipo de
recursos.
Firmas y aprobaciones de quienes deban supervisar el informe.
Solución
No es necesario. Se trata de unos documentos propuestos por el IEEE en los que se inclu-
yen todos los apartados que debería incluir cada documento, como por ejemplo, la ERS. No
obstante, aunque no es preciso seguir los índices de estos documentos, en cualquier docu-
mento que se elabore, sí se debería incluir toda la información a la que se refiere cada uno
de los puntos de los citados índices.
4. OPTIMIZACIÓN Y DOCUMENTACIÓN |NFORMATÍCA | KF
BNE 4.4.7. Generación de documentación

La generación automática de documentación se usa fundamentalmente para la documen-
tación del código fuente.
La documentación del código fuente, aunque parezca una tarea innecesaria o poco inte-
resante, en la vida real, es una tarea de gran importancia porque un porcentaje muy im-
portante del esfuerzo de desarrollo de software de una organización se dedica a la tarea
de mantenimiento, en cualquiera de sus modalidades (mantenimiento correctivo, perfec-
tivo o adaptativo). Todos los estudios realizados en relación con el esfuerzo de la tarea
de mantenimiento, cifran su coste en más del 50 % del esfuerzo dedicado al desarrollo
de software.
Hay que tener en cuenta que todos los programas que tengan éxito tendrán que sufrir
cambios a lo largo de su uso por errores no detectados, porque se requieran nuevas fun-
cionalidades o cambios en funcionalidades existentes, o porque sea necesario adaptar
el software a nuevos entornos.
Además, es muy probable que las personas que tengan que realizar modificaciones so-
bre un determinado programa no sean las mismas personas que lo elaboraron. Y aunque
lo sean, lo cual no es muy frecuente, no es muy probable que recuerden por qué escri-
bieron cierto código. La utilidad de la documentación debe ser precisamente facilitar la
modificación de programas, es decir, la tarea de mantenimiento del software. Se debe
posibilitar la rápida detección de errores y su depuración y la detección de aquellas par-
tes del software que es necesario modificar, por ejemplo, por la inclusión de nuevas fun-
cionalidades.
Es importante documentar o comentar la utilidad de cada clase, de cada método, de

cada variable, el algoritmo que se usa para resolver un problema, indicar el autor de cada
uno de estos elementos y la fecha de la última modificación, etcétera.
Se pueden documentar programas escritos en casi cualquier lenguaje de programación

mediante el empleo de herramientas de generación automática, como por ejemplo, el sis-
tema JavaDoc que sirve para documentar programas escritos en Java.
JavaDoc permite generar documentación de código escrito en Java en formato HTML. Para
que esto resulte útil, es necesario seguir una serie de recomendaciones de JavaDoc, herra-
mienta que generará un fichero que incluirá el código y la documentación. JavaDoc recomien-
da lo siguiente en relación con los comentarios.
Los tipos de comentarios que se pueden utilizar son los siguientes:
E Comentarios de línea: comienzan con los caracteres “//” y finalizan con la línea.
E Comentarios de varias líneas: pueden abarcar varias líneas, empiezan con “/*” y
terminan con “*/”.
E Comentarios de documentación JavaDoc: estos comentarios deben comenzar con

</**” y finalizar con “*/”, y, también, pueden abarcar varias líneas. Sin embargo,
cada línea dentro de estos comentarios debe comenzarse con el símbolo * y se
pueden incluir etiquetas HTML dentro de ellos. Estos comentarios no se pueden
A Y COMUNICACIONES 4. OPTIMIZACIÓN
Y DOCUMENTACIÓN
colocar en cualquier lugar de los programas, sino que deben situarse antes de la
declaración de una clase, un atributo o un método. Incluyen dos partes: una des-
cripción y un bloque de etiquetas o tags. Las etiquetas más utilizadas se muestran
en la Tabla 4.1.
Tabla 4.1. Etiquetas que se incluyen en los comentarios de documentación JavaDoc
Etiqueta
: Eauthor nombre_autor : Autor del elemento que se documenta, generalmente una

: clase.
Eparam nombre_param descripción : Descripción del parámetro. Se usa una etiqueta de este tipo
por cada parámetro.
: Gretumn descrip Descripción de lo que devuelve el método.
i Osee referencia Referencia a otro elemento: a una clase del mismo proyecto :
: : (paquete.clase),aotro método de la misma clase (+método()),
: a un método de otra clase (claseitmétodo()), a un método de :
una clase de otro paquete (paquete.clasetmétodo()). :
: Eversion versión Versión de la clase. Solo es aplicable a clases.
i Esince descrip ndica la versión del software a partir de la cual ha estado :

disponible la entidad declarada.
Se muestra a continuación la descripción de la clase CuentaDoc, que es como la clase Cuen-

ta que se creó en el Apartado 3.6, pero con una serie de comentarios de JavaDoc añadidos.
package CuentaPrueba;
NH
/**
W
* <h3> Clase CuentaDoc, para contener la información de cada una

B
de las
* cuentas bancarias </h2>
* eversion 01-2021
* Gauthor Jose Piñeiro
* since 14-02-2021
*
public class CuentaDoc (
private String número; //Número de la cuenta bancaria
private float saldo; //Saldo de la cuenta bancaria en euros
/*—k
* Constructor de la clase CuentaDoc con todos los parámetros

* Eparam numCta Número de la cuenta bancaria

* Eparam saldoCta Saldo inicial de la cuenta
*
public CuentaDoc (String numCta, float saldoCta) f
número= numCta;
4. OPTIMIZACIÓN Y DOCUMENTACIÓN |NFORMÁTICA Y COA/H¡L_J |
22
23
24 /**
Z5 * Método de selección del número de la cuenta

26 * Ereturn Número de la cuenta bancaria
27 E
28 public String getNúmero
() f
29 return número;
30
31
32 /**
33 * Método de selección del saldo de la cuenta

34 * Ereturn Saldo de la cuenta bancaria
35 s
36 public float getSaldo() (
37 return saldo;
38
39
40 /**
41 * Método de acceso al número de la cuenta

42 * Eparam numCta Número de cta. que se desea asignar a la cuenta
bancaria
43 *
i public void setNúmero (String numCta)
45 número = numCta;
46
47
48 /**
49 * Método de acceso al saldo de la cuenta

50 * Eparam saldoCta Valor que se desea asignar al saldo de la
cuenta
51 s
52 public void setSaldo(float saldoCta)
54 )
55 /**
56 * Método que ingresa dinero en la cuenta, incrementando su

saldo
57 * Eparam importe Valor con que se desea incrementar el saldo
58 E
59 public void ingresarDinero (float importe) f
60 saldo = saldo + importe;
61
62
63 /**
64 * Método que saca dinero de la cuenta, decrementando su saldo

65 * Eparam importe Valor con que se desea decrementar el saldo
66 u
| A H1/ [.OMUNICACIONES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
67 public void extraerDinero (float importe) f

68 saldo = saldo - importe;
69 )
70 /*%*
71 * Método que muestra el n* de la cuenta y su saldo

72 *7
73 public void mostrarCuenta () f
74 System.out.printin (“N* cuenta: “+ getNúmero());
E System.out .printin (“Saldo: “+ getSaldo()+ “ €”);
76
77
Para ejecutar JavaDoc desde Eclipse, se activa la opción de menú Project > Generate
Javadoc. En la pantalla que se muestra en la Figura 4.40, se debe:
e Indicar debajo de Javadoc command la ruta en la que se encuentra el archivo eje-

cutable de JavaDoc, javadoc.exe. Se puede seleccionar la ubicación en el equipo
haciendo clic en el botón Configure. Se debe buscar el archivo javadoc.exe en la
carpeta bin, que estará dentro de la carpeta en la que se encuentra el JDK.
Seleccionar el proyecto y las clases que se desean documentar.
. Seleccionar la visibilidad máxima de los elementos que se desean documentar. Si

se selecciona Private, se está indicando que se desean documentar todos los miem-
bros (atributos y métodos), incluso los que tienen asignada la visibilidad private.
4. Indicar, a la derecha de Destination, la carpeta donde se almacenará el código HTML.
Javadoc Generation
Select types for Javadoc generation.
Javadoc command:
C:1Program FilesVava jdk-16.0.21bin javadoc.exe
Select types for which Javadoc will be generated:
a [u]( Ejercicios
a [u](8 sic [] P CuentaTestjava
[m]EB CuentaPrueba Y] [ CuentaDocjava
] B programas
Create Javadoc for members with visibility:

O Private O Package O Protected () Public
Public: Generate Javadoc for public classes and members.
(8) Use standard doclet
Destination: [ CUsersVose|DesktopParaninfoVED'Ejercicios
doc
) Use custom doclet
Doclet name:
Doclet class path:

0)
Figura 4.40. Generación de documentación automática con JavaDoc

para la clase CuentaDoc.
4. OPTIMIZACIÓN Y DOCUMENTACIÓN INFORMÁT|CA Y COM |
Seguidamente, se clica en el botón Next y, en la siguiente ventana, se indica, en la par-

te superior, el nombre del documento que se va a generar y se seleccionan las opciones
deseadas para la generación del documento HTML. Finalmente, se pulsa el botón Finish.
Si nos dirigimos a la carpeta especificada en Destination por medio del explorador de ar-
chivos, se puede hacer doble clic en el documento index.html, cuyo contenido es el que
se muestra en la Figura 4.41.
( CuentaDoc
€ > C O Archivo | C:/Users/Jose/Desktop/Paraninfo/ED/Ejercicios/doc/CuentaPrueb... Q * . :

151 Aplicaciones »e Bookmarks [ Natur [ Nudeus M XAMPP G LaguíaGranCanari.. —» Lista
de lectura
USE TREE INDEX HELP
SUMMARY: NESTED | FIELD |CONSTR |METHOD — DETAIL: FIELD|CONSTR

| METHOD
Package CuentaPrueba
Class CuentaDoc
java lang Object
CuentaPrueba CuentaDoc
public class Cuentapoc
extends object*
Clase CuentaDoc, para contener la información de cada una de las cuentas bancarias
Version:
012021
Author:
Jose Piñeiro since 14-02-2021
Constructor Summary
Constructor Description
Cuentapoc(string” nuncta, flost saldocta) Constructor dela clase CuentaDoc con todos los parámetros
Method Summary
[Modifier
and Type
mc ae | an ed
Method Description
void extraerDinero(flost importe) Método que saca dinero de la cuenta, decrementando su saldo
String" getnúmero() Método de selección del número de la cuenta

flost getsaldo() Método de selección del saldo de la cuenta
Figura 4.41. Documentación generada con JavaDoc para la clase CuentaDoc.

Documentación de una clase con JavaDoc
Documenta la clase Punto del proyecto figuras de manera similar a como se ha he-
cho para la clase CuentaDoc y obtén, como resultado, un documento HTML.
Los malos olores (bad smells)
Implantación de
Refactorización
Patrones de refactorización
en Eclipse
operaciones de
refactorización en Eclipse
Opt imización y documentac ión
Analizadores de código
Gestión de versiones
Control de versiones
Herramientas de control
de versiones
Estructura de los documentos
Documentación
Generación de documentación
7
ACTIVIDADES FINALES 4. OPTIMIZACIÓN Y DOCUMENTACIÓN
4.1. En relación con el momento de aplicación de la refactorización, indica cuál es la
afirmación verdadera:
a) Es más adecuado aplicar la refactorización sobre una aplicación ya finalizada.
b) Es mejor realizar pequeñas refactorizaciones a lo largo del proceso de desarrollo
de software.
c) Es conveniente aplicar refactorizaciones tras la adición de cada nueva funcionali-
dad al software.
4.2. ¿Qué nombre recibe el mal olor (bad smell) consistente en que existen demasia-
das ramas y bucles en un método?
a) Método largo (long method).
b) Código divergente (divergent code).
c) Código duplicado (duplicated code).
d) Complejidad ciclomática (cyclomatic complexity).
4.3. ¿Cuál de los siguientes patrones de refactorización en Eclipse es aplicable a un

bloque de código?
a) Encapsulate Field.
b) Extract Method.
c) Change Method Signature.
d) Pull up.
4.4. ¿Cuál de los siguientes patrones de refactorización se debe aplicar en Eclipse

para mover un atributo de una clase a su superclase?
a) Move.
b) Pull up.
c) Pull down.
d) /nline.
4.5. ¿Cuál de los siguientes patrones de refactorización en Eclipse es aplicable so-

bre un atributo de una clase?
a) Move.
b) Extract Class.
c) Extract Local Variable.
d) Encapsulate Field.
4.6. En cuanto a las diferencias entre las herramientas automáticas para la refactori-
zación y las que se usan para el análisis estático de código (analizadores de có-
digo):
a) Los dos tipos de herramientas son capaces de detectar automáticamente defec-
tos en el código.
b) Los dos tipos de herramientas pueden ser empleadas por las personas que llevan
a cabo la programación como medio para corregir defectos cometidos en esta.
C) Los dos tipos de herramientas son capaces de detectar automáticamente malos
olores (bad smells).
174 d) Ninguna de las respuestas anteriores es correcta.
4. OPTIMIZACIÓN Y DOCUMENTACIÓN ACTIVIDADES FINALES
4.7. Indica cuál de las siguientes afirmaciones es verdadera en relación con el códi-
go duplicado:
a) Las herramientas de refactorización de Eclipse pueden emplearse para la detec-
ción automática de código duplicado.
b) Existe algún patrón de refactorización en Eclipse que se puede emplear para so-
lucionar el problema del código duplicado.
c) El analizador de código PMD se puede emplear para la detección automática de
código duplicado.
4.8. En Git un archivo que está pendiente de confirmación, ¿en qué área se encuen-
tra?
a) En el repositorio local (commit area).
b) En el área de trabajo (working area).
c) En el área de preparación (staging area).
d) En el repositorio remoto.
4.9. ¿Qué orden se emplea en Git para pasar cambios realizados en el repositorio lo-
cal al repositorio remoto?
a) Pull.
b) Push.
c) Check out.
d) Commit.
4.10. ¿Qué orden se emplea en Git para cambiar de rama?

a) Pull.
b) Push.
c) Check out.
d) Commit.
4.11. En Git, ¿a qué elemento se le atribuye el nombre de master?

a) Alaúltima versión de una rama.
b) Ala última rama que se ha creado.
C) A la rama principal o tronco.
d) Al repositorio remoto.
4.12. ¿JavaDoc se emplea para generar qué tipo de documentación?

a) Documentos que describen el uso del software (manual de usuario).
b) Documentos que describen el código fuente.
c) Documentos que describen el resultado de las fases de análisis y diseño del
software.
d) Todas las respuestas son correctas.
175
M Actividades de aplicación
4.13. Describe en qué consiste la técnica de la refactorización.
4.14. ¿Es mejor aplicar la refactorización continua o a posteriori?, ¿por qué?
4.15. ¿En qué consiste el patrón de refactorización Extract Local Variable de Eclipse?
4.16. ¿En qué consiste el patrón de refactorización Encapsulate Field de Eclipse?
4.17. En la aplicación figuras, cambia el nombre de la clase Triángulo para eliminar su tilde,
de forma que su nuevo nombre sea Triangulo. Elimina también las tildes de los nom-
bres de los métodos abstractos área() y perímetro() de la clase Figura.
4.18. En la clase PruebaFigura de la aplicación figuras, elimina las tildes de las variables op-
ción y mostrarPerímetro del método main, del nombre de los métodos mostrarMenú()
y procesarTriángulo() y de la variable opción del método mostrarMenú/().
4.19. En la clase PruebaFigura, sustituye la variable local opcion del método main por un
atributo privado de la clase.
4.20. ¿Qué diferencias hay entre las herramientas para la refactorización y los analizadores
de código?
4.21. ¿Es posible en Eclipse consultar las reglas que emplea el analizador de código PMD
al realizar sus análisis? Si es posible, ¿cómo se pueden consultar?
4.22. ¿Es posible en Eclipse modificar las reglas que emplea el analizador de código PMD
al realizar sus análisis? Si es posible, ¿cómo se pueden modificar?
4.23. Crea en Eclipse un repositorio local llamado Ejemplo2 dentro de la carpeta Reposi-
toriosGit que se creó anteriormente. Crea un proyecto Java en Eclipse llamado Pro-
yecto? dentro de la carpeta EjemplosCtrolVersionesGit. Crea dentro del proyecto una
clase mediante la que se muestre un mensaje por pantalla. Confirma los cambios
realizados en el repositorio local.
Crea un repositorio remoto en GitHub llamado RepositorioRemotoGit? y pasa el con-

tenido del repositorio local al repositorio remoto.
Crea una rama llamada rama?, en la cual debes añadir una nueva clase que muestre
dos mensajes por pantalla, y confírmala en el repositorio local. Añade para la clase
creada en la rama rama1 dos nuevos mensajes por pantalla, valida los cambios en el
repositorio local y súbela al repositorio remoto. Fusiona esta rama con el tronco y sú-
bela al repositorio remoto.
Crea otra rama llamada rama2 con una nueva clase que muestre un mensaje por
pantalla y confirma estos cambios en el repositorio local. Visualiza el histórico de ver-

siones del proyecto. Confirma esta rama en el repositorio local y súbela al reposito-
rio remoto. Luego fusiona esta rama con el tronco y sube los cambios al repositorio
remoto.
176
4.24. ¿A qué hacen referencia las siglas ERS? Este documento se obtiene como resultado
de una fase del desarrollo de software, ¿cuál es esta fase?
M Actividedaampde
liaciós n
4.25. Enel Apartado 4.1, se indicó que existen tres tipos de mantenimiento (perfectivo, co-
rrectivo y adaptativo), sin embargo, se suele hablar a veces de mantenimiento pre-
ventivo. ¿En qué consiste este tipo de mantenimiento?, ¿tiene alguna relación con la
refactorización?
4.25. Uno de los malos olores que se señaló en el Apartado 4.1.1 es el llamado cirugía a ti-
ros (shotgun surgery), consistente en que un cambio en una clase conlleva la realiza-
ción de cambios en otras muchas clases. Investiga cuál puede ser el motivo de este
mal olor y cómo se puede solucionar.
4.27. Otro de los malos olores que se describió en el Apartado 4.1.1 es el llamado código
divergente (divergent code), que consiste en que un cambio en el sistema conlleva
muchos cambios en una misma clase. Se trata del mal olor contrario a cirugía a tiros.
Investiga cuál puede ser el motivo de este mal olor y Cómo se puede solucionar.
4.258. Enel Apartado 4.3.3, se ha empleado la herramienta de control de versiones Git inte-
grada en el IDE Eclipse, pero también es posible emplearla de manera independiente
en modo línea de comandos. ¿Desde qué página web es posible realizar la descar-
ga? ¿En qué sistemas operativos se puede instalar Git?
4.29. ¿Es posible instalar Git con interfaz gráfica sin estar integrado en un IDE? En caso de
que sea posible, ¿desde qué página web se puede realizar la descarga correspon-
diente y en qué sistemas operativos se puede instalar?
4.30. Busca la utilidad de los siguientes comandos que se pueden emplear en Git en modo
línea de comandos: git init y git diff.
4.31. Investiga si es posible emplear Git integrado en el IDE Apache NetBeans. En caso de
que sea posible, ¿es necesario realizar alguna instalación?
177
Baeldung - https://www.baeldung.com/Eclipse-refactoring
(Tutoriales sobre temas relacionados con el desarrollo en Java)
Linuxtopia - https://www.linuxtopia.org/online_books/eclipse_guides.html
(Página web con guías sobre Linux y el desarrollo de software. Incluye una sección sobre
Eclipse)
Refactoring.Guru - https://refactoring.guru/es
(Sitio web sobre refactorización, patrones de diseño, principios SOLID y otros temas rela-
cionados con la programación)
Git-sem - https://git-sem.com/
(Sitio web dedicado a la gestión de la configuración del software empleando la herramien-
ta Git)
PMD - https://pmd.github.io/
: (Sitio web sobre el analizador de código PMD)
178
—[—ÑCS————]].
ofobb ou¿¿oQ
;-f,¡ : hi
UNIDAD 5
17 * !—.u'
.n+eu1:;' £¿I.o1
'::
'll'
á. asifors ..
1u
anolesd
YTS
(,
*
;*jVe 7
.!( ¿A i &l1llo
bita J
eaiyT2 : |
(! b
Y.1u,:.|0u). .”| edaroz
00 ; 1oenf : 9ru¡º
a q
“ ¡fu(n¡ de
Elaboración de diagramas
de clases
Aprender los conceptos básicos de la orientación E 5.1. Conceptos básicos
a objetos. de la orientación a objetos
Comprender los fundamentos del lenguaje UML. m 5.2. El lenguaje UML
Conocer los tipos de diagramas que se pueden E 5.3. Clases, atributos, métodos
construir en el lenguaje UML. y visibilidad
Saber cómo representar clases empleando E 5.4. Relaciones entre clases
el lenguaje UML.
El 5.5. Tipos de clases de análisis
Reconocer y diferenciar los tipos de relaciones
E 5.6. Herramientas para la creación
que se pueden establecer entre las clases.
de diagramas de clases
Conocer la manera de representar las diferentes
El 5.7. Generación de código a partir
relaciones entre clases empleando el lenguaje de diagramas de clases
UML.
l 5.8. Generación de diagramas
Distinguir los tipos de clases de análisis
de interfaz, de control y de entidad. (ingeniería inversa)
Utilizar herramientas para la elaboración
de diagramas de clases.
Generar código a partir de un diagrama de clases.
Crear un diagrama de clases a partir de código
mediante ingeniería inversa.
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMATICA Y [C fM"
Introducción
Para crear una aplicación informática, es necesario llevar a cabo una serie de tareas que
ya fueron descritas en las unidades previas. Durante las etapas de análisis y diseño, se
deben obtener modelos gráficos que representen la información que es necesario mane-
jar en la aplicación y las operaciones que se deben realizar sobre dicha información. La
creación de estos modelos se debe realizar siguiendo ciertas normas y el estándar a ni-
vel internacional para ello es el lenguaje UML (unified modeling language).
Una aplicación orientada a objetos consta de una serie de clases relacionadas entre sí,
a partir de las cuales, se crean objetos que se envían mensajes. Con relación a ello, el
lenguaje UML establece las normas para crear muchos tipos diferentes de diagramas,
de los cuales los más relevantes son los diagramas de clases, a los que se dedica esta
unidad. Así, se estudiarán cómo se representan las clases y sus relaciones siguiendo el
lenguaje UML y cómo crear estos diagramas empleando varias herramientas informáti-
cas. También se verá la manera de generar código a partir de un diagrama de clases, y
viceversa.
M 5.1. Conceptos básicos de la orientación a objetos

Como se indicó en el Apartado 1.2, el paradigma orientado a objetos supuso en cierto
modo un cambio de visión en relación con el desarrollo de software. Básicamente, se
pasó de prestar atención a los procesos que se tenían que realizar en una aplicación a
dar mayor relevancia a los datos sobre los que se debía operar.
En el paradigma orientado a objetos, una aplicación consta de objetos que interactúan

entre ellos para llevar a cabo las funciones encomendadas al software. Como se indicó
en la Unidad 1, un objeto es una instancia de una clase, y toda clase tiene una serie de
propiedades o atributos y realiza un conjunto de operaciones llamadas métodos. Se pue-
de definir un mensaje como una solicitud de un objeto para que otro objeto o él mismo
ejecute uno de sus métodos.
Para que un lenguaje de programación pueda ser calificado como orientado a objetos
precisa tener una serie de características, que se enumeran a continuación (Coad y
Yourdon, 1991):
E Abstracción: cada objeto en el sistema funciona como un agente abstracto que pue-
de realizar trabajo, informar y cambiar su estado, así como comunicarse con otros
objetos en el sistema sin revelar cómo se implementan estas características. El
proceso de abstracción permite seleccionar las características relevantes dentro de
un conjunto e identificar comportamientos comunes para definir nuevos tipos de en-
tidades en el mundo real.
E Encapsulamiento: hace referencia a reunir todos los elementos que pueden consi-
derarse pertenecientes a una misma entidad. Esto permite aumentar la cohesión
de los componentes del sistema.
| ]MUN'CACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
E Polimorfismo: comportamientos diferentes asociados a objetos distintos pueden

compartir el mismo nombre; al llamarlos por este nombre, se utilizará el compor-
tamiento correspondiente al objeto que se esté usando. Esto hace posible definir
varios métodos con el mismo nombre y la misma interfaz en diferentes clases, y
también definir varios métodos con el mismo nombre en una misma clase, pero con
interfaz distinta (distinto número y/o tipo de parámetros y/o tipo de valor devuelto).
E Herencia: las clases con atributos o métodos comunes se relacionan entre sí for-
mando jerarquías de clasificación en las que las subclases (clases hijas) poseen
por herencia los atributos y métodos de la superclase o de las superclases (clase
padre o clases padres). La herencia posibilita el polimorfismo y el encapsulamiento,
lo que permite crear clases como tipos especializados de clases preexistentes.
E Modularidad: es la propiedad que permite dividir una aplicación en partes más pe-
queñas llamadas módulos, cada uno de los cuales debe ser lo más independiente
posible de los otros módulos, es decir, el acoplamiento entre los módulos debe ser
el menor posible.
E Ocultamiento: cada objeto está aislado del exterior y expone su interfaz a otros ob-
jetos, la cual especifica cómo interactuar con los objetos de la clase. Esta propie-
dad protege a las propiedades de un objeto contra su modificación por quien no
tenga derecho a acceder a ellas, de manera que solo los métodos del objeto pue-
den acceder a su estado. Esto asegura que otros objetos no puedan cambiar el
estado interno de un objeto de manera inesperada, y así se evitan efectos secunda-
rios e interacciones inesperadas.
E Recolección de basura: es la técnica por la cual el entorno se encarga de destruir

automáticamente los objetos que hayan quedado sin ninguna referencia a ellos,
desvinculando la memoria asociada. Gracias a esta característica el programador
no necesita preocuparse por la asignación o liberación de memoria, ya que el en-
torno la asignará al crear un objeto y la liberará cuando nadie la esté usando. En al-
gunos lenguajes orientados a objetos que surgieron como extensión de lenguajes
estructurados, como es el caso de C++ y Object Pascal, esta característica no exis-
te y debe anularse la asignación de la memoria expresamente.
Por tanto, se puede considerar que un lenguaje de programación orientado a objetos es el

que cumple todas estas características, si bien se podría decir que la última de estas pro-
piedades (recolección de basura) no es del todo necesaria para considerar a lenguajes como
C++ u Object Pascal como orientados a objetos.
M 5.2. El lenguaje UML

El modelo orientado a objetos surgió como parte de las metodologías de análisis y dise-
ño orientado a objetos, que comenzaron su andadura durante los años 80 del siglo pa-
sado. A partir del año 1996, se integraron varios de los métodos de análisis y diseño
orientado a objetos, lo que dio lugar a la aparición del lenguaje unificado de modelado
(UML), cuya última versión es la 2.5.1, que data del año 2015.
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMATICA Y Cv (w—¡
Los principios básicos que se deben seguir a la hora de diseñar el modelo de un siste-
ma son los siguientes:
E La elección acerca de qué modelos crear tiene una enorme influencia sobre cómo
se acomete un problema y cómo se da forma a una solución.
E Todo modelo puede ser expresado con diferentes niveles de precisión.
E Los mejores modelos están ligados a la realidad.
E Un único modelo o vista no es suficiente. Cualquier sistema no trivial se aborda me-

jor mediante un pequeño conjunto de modelos casi independientes y desde múlti-
ples puntos de vista.
El lenguaje UML sigue estos principios. Cabe afirmar que UML es un lenguaje gráfico que
se emplea para visualizar, especificar, construir y documentar un sistema por medio de
diferentes tipos de diagramas que se utilizan en las diferentes tareas de desarrollo del
software. Estos modelos se corresponden con diferentes niveles de abstracción y pre-
sentan diferente nivel de detalle, o dicho de otro modo, empleando UML se puede es-
tudiar el sistema desde diferentes puntos de vista, ya que no todos los usuarios de un
sistema precisan tener la misma visión de este. UML incorpora distintos tipos de diagra-
mas y notaciones gráficas y textuales destinadas a mostrar el sistema desde diferentes
perspectivas, que pueden usarse en las diferentes fases del ciclo de vida del desarro-
llo de software. UML establece las normas que se deben seguir cuando se elaboran es-
tos diagramas.
ME 5.2.1.TIpos de elementos en UML

En el lenguaje UML, existen cuatro tipos de elementos que se describen a continuación.
MN EN Elementos estructurales
En su mayoría, los elementos estructurales son la parte estática de un modelo y repre-
sentan conceptos o cosas materiales. Son los siguientes:
1. Clase: es una descripción de un conjunto de objetos que comparten los mismos

atributos, operaciones, relaciones y semántica. Gráficamente, una clase se repre-
senta como un rectángulo que incluye su nombre, sus atributos y sus operacio-
nes o métodos, como se muestra en la Figura 5.1. En los siguientes apartados de
esta unidad, se explica con mayor detalle la manera de representar clases y los
diagramas de clases.
2. Interfaz: es una colección de operaciones que especifican un servicio de una clase

o componente. Por lo tanto, una interfaz describe el comportamiento visible desde
el exterior de ese elemento. Una interfaz define un conjunto de especificaciones

de operaciones, pero no un conjunto de implementaciones de operaciones. Esto
quiere decir que de las operaciones solo se conoce su nombre, los datos que hay
que proporcionar para llevarlas a cabo y los datos que devuelven, si fuera el caso,
pero no se conoce cómo se llevan a cabo las operaciones, es decir, cómo estas
| A YI [OMUNICACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
se implementan. Gráficamente, una interfaz se representa mediante un rectángu-

lo que incluye su nombre con la leyenda <<Interface>> y sus operaciones o méto-
dos, tal y como se muestra en la Figura 5.2.
Libro
- código: int
- ISBN: String
- título: String
- editorial: String
- prestado: boolean
+ prestar (): boolean
+ devolver (): boolean
Figura 5.1. Clase llamada Libro con cinco atributos (código, ISBN,
título, editorial y prestado) y dos métodos (prestar y devolver).
<<Interface>>
IVentana
+ abrir ()
+ cerrar ()
+ mover ()
+ dibujar ()
Figura 5.2. Interfaz IVentana con las operaciones que ofrece

(abrir, cerrar, mover y dibujar).
3. Colaboración: define una interacción y se trata de una sociedad de roles y otros

elementos que colaboran para proporcionar un comportamiento cooperativo ma-
yor que la suma de los comportamientos de sus elementos. Se representa gráfi-
camente por medio de una elipse con borde discontinuo que normalmente incluye
solo su nombre (Figura 5.3).
— —
— .
( Generarfactura )
' = — —
—
Figura 5.3. Representación de una colaboración, en este caso

Generar factura.
4. Caso de uso: describe un comportamiento de un sistema, clase o componente

desde el punto de vista de la persona usuaria. Describe un conjunto de secuen-

cias de acciones que ejecuta un sistema y que produce un resultado observable
de interés para un usuario o una usuaria particular. Gráficamente, se representa
mediante una elipse con borde continuo que, por lo general, solo incluye su nom-
bre (véase la Figura 5.4).
5. ELABORACIÓN DE DIAGRAMAS DE CLASES |NFORMÁT|CA Y (
Registrar pedido
Figura 5.4. Representación del caso de uso Registrar pedido, que

describe un conjunto de operaciones que realiza la aplicación y
que son de interés para la persona que la utiliza.
5. Clase activa: es un tipo especial de clase cuyos objetos tienen uno o más proce-
sos o hilos de ejecución. Una clase activa es lo mismo que una clase excepto en
el hecho de que sus objetos pueden ejecutarse concurrentemente con otros obje-
tos de clases activas. Se representa mediante un rectángulo, al igual que una cla-
se, pero con líneas dobles a la derecha e izquierda (Figura 5.5).
GestorDeEventos
+suspender(
)
+vaciarCola()
Figura 5.5. Representación de la clase activa GestorDeEventos

con los métodos suspender y vaciarCola.
6. Componente: es una parte modular del diseño del sistema que oculta su imple-
mentación tras un conjunto de interfaces externas. El sistema se define a partir
de los componentes conectados entre sí. La implementación de un componen-
te puede expresarse conectando partes y conectores, y las partes pueden incluir
componentes más pequeños. Por consiguiente, los componentes pueden ser de
granularidad variable. Gráficamente, se representa como una clase con un icono
especial en la esquina superior derecha (véase la Figura 5.6).
]
FormularioDeCliente
Figura 5.6. Representación del componente FormularioDeCliente.
Argot técnico
El vocablo granularidad tiene diferentes acepciones, pero la que aquí interesa es la siguiente:
«el nivel de detalle considerado en un modelo o proceso». Cuanto mayor sea la granularidad,
mayor será el nivel de detalle. Así, cabe afirmar que un componente con procesos genéricos
tiene un nivel de granularidad bajo y, por este motivo, se puede dividir en componentes más
detallados, es decir, en componentes con una granularidad mayor o más nivel de detalle.
1»' [OMUNICACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
7. Artefacto: es una parte física y reemplazable de un sistema que contiene infor-

mación física (bits). En un sistema, existen diferentes tipos de artefactos de des-
pliegue, como archivos de código fuente, ejecutables y scripts. Los artefactos se
representan por medio de un rectángulo con la leyenda «artifact» sobre el nombre
(Figura 5.7).
<<artifact>>
NavegadorWeb
Figura 5.7. Representación de un artefacto llamado NavegadorWeb.
8. Nodo: es un elemento físico que existe en tiempo de ejecución y representa un re-

curso computacional que, por lo general, dispone de algo de memoria y, con fre-
cuencia, capacidad de procesamiento. Un conjunto de artefactos pueden residir
en un nodo. Sirven para describir las plataformas en las que se ejecutan las apli-
caciones. Gráficamente, se representa mediante un cubo, en cuyo interior se pue-
de leer su nombre (Figura 5.8).
=
A
Figura 5.8. Nodo que representa un servidor web.
M EE Elementos de comportamiento
Los elementos de comportamiento son las partes dinámicas de los modelos UML y re-
presentan un comportamiento en el tiempo y en el espacio. Suelen estar conectados
semánticamente a elementos estructurales. Existen de tres tipos:
1. Interacción: comprende un conjunto de mensajes intercambiados entre un conjun-

to de objetos, dentro de un contexto particular y para un propósito específico. Un
mensaje se representa gráficamente por medio de una flecha con el nombre de la
operación sobre ella (Figura 5.9).
Imprimirractura
Figura 5.9. Mensaje que solicita la impresión de una factura.
2. Máquina de estados: especifica las secuencias de estados por los que pasa un
objeto o una interacción durante su vida, en respuesta a eventos, junto con sus
reacciones a esos eventos. Sirve para especificar el comportamiento de una cla-
se individual o de una colaboración de clases. Una máquina de estados involucra

los siguientes elementos: estados, transiciones (paso de un estado a otro), even-
tos (disparadores de una transición) y actividades (la respuesta a una transición).
Gráficamente, un estado se representa como un rectángulo con esquinas redon-
deadas con el nombre en su interior (Figura 5.10).
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMAT|CA Y C(?f
1 En espera |
Figura 5.10. Representación de un estado en espera.
3. Actividad: especifica la secuencia de pasos que ejecuta un proceso computacio-

nal. En una máquina de estados, el énfasis se pone en el ciclo de vida de un ob-
jeto, mientras que en una actividad, lo importante es la secuencia o el flujo de
pasos, sin importar qué objeto ejecuta cada paso. Cada paso de una actividad re-
cibe el nombre de acción. Una acción se representa por medio de un rectángulo
con esquinas redondeadas, en cuyo interior, se lee su nombre, que indica su pro-
pósito (véase la Figura 5.11). Los estados y las acciones se distinguen por sus
diferentes contextos, pues, aunque los estados y las acciones se representan de
igual modo, los diagramas en los que se incluyen (diagramas de estados y dia-
gramas de actividades, respectivamente) no tienen la misma forma, como se verá
posteriormente en la Unidad 6. Esto se debe a que los estados incluidos en un
diagrama de estados no se conectan de igual manera que las actividades que
aparecen en un diagrama de actividades.
Procesar pedido
Figura 5.11. Acción que hace referencia al procesamiento de

un pedido. Las acciones se representan de igual modo que los
estados, pero se distinguen de estos por el contexto en el que
se usan.
M E EN Elementos de agrupación
Son las partes organizativas de los modelos UML. El principal elemento de agrupación es
el paquete. Frente a las clases, que organizan construcciones de implementación, un pa-
quete es un mecanismo de propósito general para organizar el diseño. Un paquete pue-
de incluir elementos estructurales, de comportamiento y otros paquetes. Al contrario de
los componentes, que existen en tiempo de ejecución, los paquetes son puramente con-
ceptuales, de manera que solo existen en tiempo de desarrollo. Los paquetes se repre-
sentan gráficamente como una carpeta que lleva en su interior el nombre del paquete
(Figura 5.12).
Reglas del negocio

Figura 5.12. Representación de un paquete llamado

Reglas del negocio.
Un paquete puede contener otros paquetes sin límite de anidamiento, pero cada elemen-
to pertenece a solo un paquete. Los paquetes se pueden utilizar en cualquier diagrama
1,Ú 1ñ MUN'CACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
UML y la visibilidad de los elementos incluidos en un paquete puede controlarse para

que algunos elementos sean visibles desde el exterior del paquete, mientras que otros
permanecen ocultos.
Argot técnico
El vocablo anidamiento en el diccionario de la RAE viene definido como «acción y efecto
de anidar» y el verbo anidar posee varias acepciones. En este ámbito, la que se aplica es
la de «abrigar, acoger». Así, si se dijera que se admiten paquetes de hasta dos niveles de
anidamiento, se querría decir que un paquete puede acoger en su interior a varios paquetes,
y cada uno de estos puede acoger a varios paquetes más pequeños. Si solo se permite
dos niveles de anidamiento, cada uno de los paquetes de tercer nivel ya no se puede
descomponer en paquetes más pequeños. El hecho de que no haya límite de anidamiento
quiere decir que no existe ninguna limitación en cuanto a los niveles de descomposición
de un paquete en paquetes más pequeños.
Los paquetes son los elementos básicos de agrupación, pero también hay otros, como
frameworks, modelos y subsistemas.
Argot técnico
El término inglés framework se puede traducir por 'marco de trabajo” y en Wikipedia se
define como «un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un
tipo de problemática particular que sirve como referencia para enfrentar y resolver nuevos
problemas de índole similar» (https://es.wikipedia.org/wiki/Framework). Este término se usa
ampliamente en el mundo del software, en el que se podría describir como un conjunto de
herramientas que hacen posible que los desarrolladores sean más eficientes en su trabajo.
Un framework ofrece un conjunto de componentes de software listos para su uso y
reutilización. Ejemplos de ello son los frameworks .NET de Microsoft, Angular.js y CakePHP.
BNE Elementos de anotación

Son las partes explicativas de los modelos UML. Son comentarios que se añaden para
describir, clarificar y hacer observaciones. El elemento de anotación más importan-
te se llama nota. Una nota es simplemente un símbolo para mostrar restricciones y
comentarios asociados a un elemento o a una colección de elementos. Gráficamente,
una nota se representa por medio de un rectángulo con una esquina doblada junto con
un comentario textual o gráfico (véase la Figura 5.13).
Ejemplar es débil
respecto a Libro
Figura 5.13. Nota que indica que la clase Ejemplar es débil

respecto a la clase Libro.
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMATICA Y (y fhv'
ME 5.2.7.TIpos de diagramas en UML

En UML se pueden construir hasta 14 tipos de diagramas distintos que se pueden agru-
par en dos tipos de diagramas genéricos: estructurales y de comportamiento. En los siguien-
tes subapartados, se describen todos los tipos de diagramas y se clasifican según su tipo.
M ENEN Diagramas estructurales

Estos diagramas sirven para visualizar, construir, especificar y documentar los aspectos
estáticos de un sistema. Se pueden emplear los siete tipos de diagramas estructurales
que se indican a continuación:
1. Diagramas de clases: muestran un conjunto de clases y las relaciones entre ellas.

Son los diagramas más comunes en el análisis y diseño de un sistema. Un diagra-
ma de clases incluye básicamente clases (con atributos y métodos) y relaciones
(asociación, agregación, composición, generalización y dependencia). Se explica-
rán en detalle los diagramas de clases en los Apartados 5.3 y 5.4.
2. Diagramas de objetos: muestran un conjunto de objetos y sus relaciones. Se pue-

den considerar como un caso especial de diagramas de clases en los que se
muestran objetos, es decir, instancias de clases en un momento del tiempo. Por
ello, cabe decir que representan instantáneas estáticas de los elementos existen-
tes en los diagramas de clases.
3. Diagramas de componentes: describen la estructura del software mostrando la or-

ganización y las dependencias entre un conjunto de componentes. Un diagrama
de componentes representa la encapsulación de una clase, junto con sus interfa-
ces, puertos y estructura interna, la cual está formada por otros componentes ani-
dados y conectores. Se usan para construir sistemas grandes a partir de partes
pequeñas.
4. Diagramas de despliegue: muestran un conjunto de nodos de procesamiento y los

artefactos que residen en ellos. Normalmente, un nodo (hardware) suele albergar
uno o más componentes. Muestran el hardware, el software y el middleware usa-
dos para conectar las máquinas.
Z
Ae
Argot técnico
El vocablo middleware, como se puede deducir por analogía con los términos hardware y
software, hace referencia a aquello que no está muy claro si se debe situar en el ámbito del
hardware o en el del software. Se trata de un tipo de software que se sitúa entre el sistema
operativo y las aplicaciones que se ejecutan en el ordenador. Gracias al middleware es
posible la comunicación y la administración de datos en aplicaciones distribuidas.
5. Diagramas de paquetes: muestran la descomposición del modelo en unidades orga-

nizativas (paquetes) y sus dependencias. Sirven para simplificar diagramas de clases
que sean complejos y permiten la agrupación de elementos estructurales en paquetes.
| JMUN'CACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
6. Diagramas de perfiles: permiten extender el lenguaje UML para su uso con una
plataforma de programación en particular (como el framework .NET de Microsoft o
la plataforma Java Enterprise Edition) o modelar sistemas para su uso en un domi-
nio particular, como la medicina o los servicios financieros.
7. Diagramas de estructura compuesta: muestran la estructura interna, incluyendo

partes y conectores, de un elemento estructural o de una colaboración. Son pues
muy similares a los diagramas de componentes.
ME ENEN Diagramas de comportamiento

Estos diagramas sirven para visualizar, especificar, construir y documentar los aspectos
dinámicos de un sistema. Se pueden distinguir siete tipos de diagramas de comporta-
miento, si bien los cuatro últimos que se muestran están agrupados bajo el subtipo de
diagramas de interacción. Se explicarán en detalle estos diagramas en la Unidad 6.
1. Diagramas de casos de uso: ayudan a determinar la funcionalidad y las caracte-

rísticas del software desde el punto de vista del usuario. En estos diagramas se
muestran casos de uso, actores y las relaciones entre ellos. Un caso de uso es un
fragmento de funcionalidad del sistema que proporciona a la persona usuaria un re-
sultado de interés, como por ejemplo dar de alta a un empleado. Por su parte, un
actor es un conjunto coherente de roles que desempeñan los usuarios y usuarias
de los casos de uso cuando interactúan con estos. Estos diagramas se estudiarán
a fondo en el Apartado 6.2.
2. Diagramas de actividades: muestran el flujo paso a paso de una computación. Una

actividad muestra un conjunto de acciones, el flujo entre ellas y los valores pro-
ducidos o consumidos. Se emplean para especificar una operación compleja, un
proceso de negocio o un flujo de trabajo. En el Apartado 6.5 se ofrece una des-
cripción de estos diagramas.
3. Diagramas de estados: estos diagramas muestran una máquina de estados, que

consta de estados, transiciones (pasos de un estado a otro), eventos (que provo-
can transiciones) y actividades (tareas que se llevan a cabo al realizar una tran-
sición). Son especialmente importantes en el modelado de una clase o de una
colaboración con comportamiento significativo. Así pues, podría afirmarse que
muestran el comportamiento dirigido por los eventos de un objeto. Se estudiarán
estos diagramas en el Apartado 6.4.
4. Diagramas de interacción: son un grupo especial de diagramas de comportamiento

que muestran una interacción, es decir, muestran un conjunto de objetos o roles y
los mensajes que se envían entre ellos. Un mensaje es una solicitud de un objeto
a otro (0 a él mismo) para que ejecute el método indicado en el mensaje. Los obje-
tos interactúan unos con otros para realizar colectivamente las tareas encomenda-
das a la aplicación. Se pueden distinguir cuatro tipos de diagramas de interacción:
E Diagramas de secuencia: muestran la secuencia cronológica de los mensa-

jes entre objetos durante un escenario de un caso de uso. Sirven para mos-
trar cómo interactúan unos objetos con otros para ejecutar lo especificado en
un escenario de un caso de uso (para una descripción más detallada véase el
Apartado 6.3.1).
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMATICA Y [*F fhv'
E Diagramas de colaboración: muestran un conjunto de objetos, enlaces entre

ellos y los mensajes enviados y recibidos entre ellos. Los diagramas de co-
laboración muestran la misma información que los diagramas de secuencia,
pero mientras que estos resaltan la ordenación temporal, los de colaboración
resaltan la estructura de datos a través de la cual fluyen los mensajes (véase
el Apartado 6.3.2 para una explicación más amplia).
E Diagramas de tiempos: muestran los tiempos reales en la interacción entre di-

ferentes objetos y roles. O dicho de otra forma, en ellos se representa el com-
portamiento de los objetos en un determinado periodo de tiempo.
E Diagrama global de interacciones: aportan una visión general del flujo de con-
trol de las interacciones. Es un tipo de diagrama híbrido entre el diagrama de
secuencia y el diagrama de actividad. El empleo de este diagrama es útil cuan-
do el modelo de interacción tiene un gran tamaño, ya que este ofrece una vi-
sión global de la interacción.
El lenguaje UML es independiente de la metodología de análisis y diseño que se siga en

el desarrollo de software, si bien utiliza una perspectiva orientada a objetos.
M 5.3. Clases, atributos, métodos y visibilidad

Un objeto es una instancia de una clase, de modo que una clase está formada por un
conjunto de objetos que poseen la misma estructura y el mismo comportamiento. Por
ejemplo, la clase Libro representa cualquier libro de una biblioteca, siendo un objeto
cada uno de los ejemplares de libros disponibles en la biblioteca. Por otro lado, la clase
Cuenta representa cualquier cuenta bancaria, siendo un objeto cada una de las cuentas
de los clientes del banco.
Una clase tiene tanto una serie de atributos como una serie de métodos, comunes a to-
dos los objetos de la clase:
E Los atributos son las propiedades que posee una clase. Así, la clase Libro podría
tener los atributos: código, ISBN, título, editorial y prestado. Cada atributo tendrá
un nombre, un tipo de dato (numérico entero, numérico real, cadena de caracteres,
etc.) y, posiblemente, un valor por defecto. Cada objeto de la clase Libro tendrá es-
tos mismos atributos y cada uno de estos atributos tendrá un valor asignado. La
clase Cuenta podría tener los atributos número de cuenta y saldo.
E Los métodos son las operaciones que se pueden llevar a cabo con los objetos de la
clase y definen el comportamiento de la clase. Así, por ejemplo, la clase Libro po-
dría disponer de los métodos prestar y devolver, que deben ser invocados cuando
un usuario o una usuaria pide prestado un libro de la biblioteca y devuelve un libro
que le fue prestado, respectivamente. Por otro lado, la clase Cuenta podría disponer
de los métodos ingresarDinero y extraerDinero, que deben ser invocados cuando un
cliente ingrese dinero en la cuenta o extraiga dinero de ella, respectivamente. Estos
dos métodos recibirán como argumento o parámetro el importe que se desea ingre-
sar y extraer, respectivamente.
| i íOMUNICACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
La información acerca de las clases se suele representar mediante los llamados diagra-
mas de clases siguiendo la notación UML. Cada clase se representa mediante un rectán-
gulo con tres secciones:
E En la superior se indica el nombre de la clase.
E En la central se coloca información sobre los atributos de la clase.
E En la inferior se coloca información sobre los métodos de la clase.
Sin embargo, la información que se incluye en las secciones correspondientes a los atri-
butos y a los métodos puede diferir dependiendo de lo avanzado que se encuentre el pro-
ceso de análisis y diseño del software. Así, inicialmente, puede ser suficiente con indicar
únicamente los nombres de los atributos y los nombres de los métodos, como se mues-
tra en la Figura 5.14 para las clases Libro y Cuenta.
Libro
código
Cuenta
-
ISBN
número
título
saldo
editorial
prestado ingresarDinero ()
extraerDinero ()
prestar ()
devolver ()
Figura 5.14. Representación de las clases Libro (con los atributos código, ISBN,
título, editorial y prestado y los métodos prestar y devolver) y Cuenta (con los
atributos número y saldo y los métodos ingresarDinero y extraerDinero).
No obstante, a medida que se avanza en el proceso de desarrollo de software, se puede

añadir más información a cada clase. Así, se pueden detallar más los diagramas de cla-
ses UML, indicando para cada atributo de una clase un modificador de acceso y el tipo de
dato asociado a este, escribiendo:
modificador atributo: tipoDato
El modificador de acceso hace referencia a la visibilidad del atributo, es decir, al ámbito

desde el cual es visible el atributo en cuestión. Los modificadores de acceso más impor-
tantes son:
E Private: si un atributo o un método de una clase se define con el modificador de ac-

ceso private, quiere decir que ese atributo o método solo es accesible desde méto-
dos de la clase en la que está declarado el atributo o método. Este modificador se
simboliza con un guion (-).
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMÁTICA Y C
E Public: si un atributo o un método de una clase se define con el modificador de ac-

ceso public, quiere decir que ese atributo o método es accesible desde métodos de
cualquier clase. Este modificador se simboliza mediante el signo más (+).
E Protected: este modificador de acceso indica que el atributo o el método que lo ten-
ga asignado es accesible desde métodos de la propia clase y desde métodos de su
subclase o de sus subclases. Este modificador se simboliza por medio del símbolo
almohadilla (%).
E Package: indica que el atributo o el método es visible en las clases incluidas en el

mismo paquete. Este modificador se simboliza con el carácter tilde (-).
Lo habitual es, al menos en las fases iniciales del proceso de desarrollo, asignar a los
atributos el modificador de acceso private, y a los métodos, el modificador public, si bien
este último se puede cambiar posteriormente a private si se detecta que no es necesario
el uso del método por parte de otras clases.
En cuanto a los tipos de datos, se pueden utilizar los tipos básicos de datos de UML, que
son los siguientes:
E int o integer: hace referencia a un número entero, es decir, sin decimales.
E String: hace referencia a cadenas de caracteres.
E boolean: permite almacenar solo los valores true (verdadero) o false (falso).
También, es posible usar los tipos de datos de lenguajes orientados a objetos, como Java,
a saber:
E float o double: hace referencia a un número real, es decir, con decimales o bien un
número que permite un rango de valores mayor que el tipo int.
E char: permite almacenar un solo carácter, que puede ser una letra, un dígito, un ca-
rácter especial (+, Q, $, :, etc.) o una secuencia de escape (como, por ejemplo, el
carácter de nueva línea, Un).
E Date: permite almacenar una fecha.
E Time: permite almacenar una hora.
E DateTime: permite almacenar una fecha y una hora conjuntamente.
Además, en el caso de los métodos, se puede indicar el tipo del valor devuelto, si es que
el método devuelve algún valor, y para cada uno de los datos que recibe el método (pará-
metro), el nombre del parámetro y su tipo de dato, siguiendo la siguiente sintaxis:
modificador método (parám,: tipoDato,, parám,: tipoDato,, ...): tipoDatoDevuelto

Así, se podría indicar que el atributo código de Libro es de tipo entero (int), que los atribu-
tos /SBN, título y editorial son de tipo cadena de caracteres (String) y que el atributo pres-
tado es de tipo booleano (boolean), dado que un libro solo puede estar prestado (que se
representa con valor true para el atributo prestado) o no prestado (que se representa con
1,5 [OMUNICACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
valor false para este atributo). Por otro lado, para los métodos prestar y devolver, podría
indicarse que devuelven un valor de tipo boolean, que informaría si el préstamo o la de-
volución ha tenido lugar o no, respectivamente.
En el caso de la clase Cuenta, podría indicarse que su atributo número es de tipo cadena
de caracteres (String) y que su atributo saldo es de tipo número real (float). En el caso de
los métodos ingresarDinero y extraerDinero, estos no devuelven nada, pero ambos recibi-
rán un parámetro, que se puede llamar importe, que debe ser de tipo número real (float).
Se podría entonces representar las clases Libro y Cuenta en un diagrama UML con la in-
formación antes expuesta tal y como se muestra en la Figura 5.15.
Libro
- código: int
Cuenta
- ISBN: String
- número: String
- título: String
- saldo. float
- editorial: String
- prestado: boolean + ingresarDinero (importe: float)
+ extraerDinero (importe: float)

+ prestar (): boolean
+ devolver (): boolean
Figura 5.15. Representación detallada de las clases Libro y Cuenta, indicando

la visibilidad de cada atributo y método. En el caso de los atributos, se indica,
además, su tipo de dato, y en el caso de los métodos, el tipo de dato devuelto,
si lo hay, y por cada parámetro, si es el caso, su nombre y tipo de dato.
MN 5.4. Relaciones entre clases

Para todos los diagramas de clases, se han de establecer relaciones entre las clases,
de manera similar a como se establecen relaciones entre las entidades de un diagrama
entidad-relación. Existen diferentes tipos de relaciones entre clases, que se van a expo-
ner a continuación.
ME 5.4.1.Agregación
Una agregación es un tipo de relación entre clases que representa un objeto compues-
to por otros objetos. En esta relación, se distingue la parte que representa el todo, que
recibe el nombre de compuesto, y las diferentes partes que lo componen, que reciben el
nombre de componente.
La agregación implica que solo puede existir una instancia del objeto agregado si existe
al menos una instancia relacionada de alguno de los componentes. Por ejemplo, no tiene
sentido hablar de un plan de estudios si no tiene al menos una asignatura.
5. ELABORACIÓN DE DIAGRAMAS DE CLASES |NFORMÁT|C A Y (
Existen dos tipos de agregaciones: la agregación débil, que se conoce generalmente

como agregación «a secas» y la agregación fuerte, conocida como composición.
En el caso de la agregación débil, o simplemente agregación, como indican Alonso,

Martínez y Segovia (2005):
el tiempo de vida de los componentes es diferente que el del agregado. En otras

palabras, los objetos de las clases componentes pueden existir antes de crear el
agregado relacionado e incluso después de desaparecer el agregado. Por ejemplo,
si se especifica que un cuadro puede estar compuesto de un marco, un cristal y
una lámina, es perfectamente válido suponer que el marco puede existir antes de
hacer el cuadro y no tiene que dejar de existir al destruir el cuadro.
Las relaciones de agregación se representan uniendo el compuesto con sus partes com-
ponentes mediante una línea colocando un rombo con fondo blanco al lado del compues-
to, como se muestra en la Figura 5.16.
Figura 5.16. Diagrama UML que muestra una relación de agregación entre la clase de tipo compuesto
Cuadro y sus partes o componentes Marco, Cristal y Lámina.
Los números 1 al lado de las clases reciben el nombre de multiplicidades o cardinalida-

des e indican el número de objetos de una clase que pueden estar vinculados con cada
objeto de la otra clase. Las cardinalidades en un diagrama UML pueden ser:
M 1: uno.
E 0..1: cero o uno.
E 0..*: cero o varios. También se puede representar solo con el símbolo del asterisco
(*)
1..*: uno o varios.
E N: el número indicado.
E N..M: entre los números N y M.
Así, el 1 al lado de la clase Marco se debe interpretar como que un cuadro posee un
solo marco, el 1 al lado Cristal se debe interpretar como que un cuadro posee un_único
cristal, y el 1 al lado de Lámina, como que un cuadro posee una única lámina. El 1 si-
tuado al lado de Cuadro y del rombo de la línea que representa su relación con Marco
debe interpretarse como que un marco pertenece a un solo cuadro y lo mismo ocurre
con Cristal y Lámina.
1,Ú [OMUNICACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
En la Figura 5.17, se muestra otro ejemplo de agregación, en el que se indica que un pla-
to se elabora con un conjunto de varios ingredientes. El 1..* al lado de Ingrediente indica
que un plato consta de uno o varios ingredientes. El * al lado de Plato indica que un in-
grediente puede estar presente en ninguno o en varios platos. Se puede asignar o no un
nombre a cualquier agregación, en cuyo caso, este nombre se debe colocar al lado de la
línea que une las dos clases. Así, en el diagrama UML que se observa en la Figura 5.17,
se ha asignado el nombre se elabora con a la agregación, aunque no sea obligatorio.
Plato |
se elabora con
l"
Ingrediente M
Figura 5.17. Diagrama UML que muestra una relación de agregación

entre la clase de tipo compuesto Plato y sus ingredientes.
ME 5.4.2. Composición
La agregación fuerte o composición es un tipo especial de agregación en la que la mul-
tiplicidad al lado de la clase que representa el compuesto es siempre 1 y en la que la
existencia de los componentes depende del compuesto. De esto se puede deducir que,
a diferencia de la agregación, la composición impone dos restricciones:
1. Cada componente solo puede estar presente en un compuesto.
2. Si se elimina el compuesto, hay que eliminar todos los componentes vinculados a él.
Las relaciones de composición se representan como las de agregación, pero el rombo

que se coloca al lado del compuesto tiene el fondo de color negro en lugar de blanco. Se
puede asignar o no un nombre a la composición, en cuyo caso este nombre se debe co-
locar al lado de la línea que une las dos clases.
Un ejemplo de composición es el que se da entre un plan de estudios y las asignaturas

de que consta dicho plan. Una asignatura solo puede pertenecer a un plan de estudios,
y cuando desaparece este plan, desaparecen con él todas sus asignaturas. En la Figu-
ra 5.18, se representa la relación de composición de dicho ejemplo.
Otro ejemplo de composición (Figura 5.19) sería aquel en el que se relaciona una ven-
tana de una interfaz gráfica de usuario con sus partes, de tal manera que toda ventana
consta de un único panel, puede tener o no una cabecera y dispone de dos barras de
desplazamiento (una por la izquierda y otra por la derecha).
5. ELABORACIÓN DE DIAGRAMAS DE CLASES |NFORMÁTICA Y COM | U N
PlanEstudios
título
fechaAprobación
númeroCréditos
consta de
1.
Asignatura
código
nombre
tipo
créditos
Figura 5.18. Diagrama UML que muestra una

relación de composición entre la clase 'compuesto'
PlanEstudios y sus asignaturas.
0..1
Figura 5.19. Diagrama UML que muestra una relación de composición entre la clase 'compuesto' Ventana
y sus componentes Cabecera, BarraDesplazamiento y Panel.
Solución
Entre las clases País y Región se debe establecer una relación de tipo composición por-
que un país es un compuesto que consta de varios componentes (regiones) y no pueden
existir regiones sin un país asociado. Además, se cumplen las dos restricciones que im-
pone una composición respecto a una agregación: >
] MUN'CACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
1. Una región solo puede pertenecer a un país.
2. Si se elimina un país porque, por ejemplo, ya no se va a trabajar con información

sobre ese país en el programa, se deben eliminar también todas las regiones per-
tenecientes a dicho país.
ME 5.4.3. Generalización y especialización

Las relaciones de generalización-especialización ocurren cuando se establece una jerar-
quía de clases y subclases motivada por el hecho de que hay varias clases que poseen
atributos y/o métodos comunes. En este caso, se deben asignar los atributos y métodos
comunes a la superclase, dejando los atributos y métodos específicos en las subclases.
En este contexto, se habla de generalización porque se puede decir que las subclases se
generalizan en una superclase, dado que los atributos y métodos comunes a las subclases
se asignan a la superclase. Por otro lado, se habla de especialización porque la superclase
se especializa en una o varias subclases, las cuales poseen atributos y/o métodos espe-
cíficos además de los de la superclase.
Así, si en una aplicación se quisieran contemplar cuentas corrientes y cuentas de ahorro,

se debería tener en cuenta que toda cuenta corriente tiene un número de cuenta, un sal-
do y un saldo medio; y, por otro lado, toda cuenta de ahorro tiene un número de cuen-
ta, un saldo y un tipo de interés. En este caso, se creará una superclase llamada Cuenta
que englobe los atributos comunes a los dos tipos de cuentas (número de cuenta y sal-
do), de manera que CuentaCorriente y CuentaDeAhorro serán las subclases con los atri-
butos específicos (saldo medio y tipo de interés, respectivamente).
Cabe afirmar, por tanto, que la clase Cuenta es una generalización de las subclases
CuentaCorriente y CuentaDeAhorro, y que CuentaCorriente es una especialización de la
superclase Cuenta porque una cuenta corriente es algo más especializado que una cuen-
ta, pues posee todas las características de una cuenta, pero también una característica
adicional, que es el saldo medio.
Este tipo de relaciones se representan uniendo mediante una línea cada subclase con su
superclase y esta línea lleva en el extremo un triángulo apuntando a la superclase, como
se puede observar en la Figura 5.20.
Cuenta
- número: String
- saldo: float
| CuentaCorriente | | CuentaDeAhorro |
- saldoMedio: float - interés: float
Figura 5.20. Diagrama UML que muestra una relación de generalización-especialización entre la superclase
Clase y sus subclases CuentaCorriente y CuentaDeAhorro.
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMÁTICA Y C rM '
La herencia hace referencia al hecho de que las superclases poseen no solo sus atribu-
tos o métodos propios, sino que también heredan los de la superclase correspondiente.
Así, la subclase CuentaCorriente tiene un saldo medio (atributo propio), pero también tie-
ne un número de cuenta y un saldo, atributos que hereda de la superclase Cuenta.
Argot técnico
El hecho de emplear el término herencia para referirse al hecho de que las subclases poseen,
además de sus atributos y métodos propios, los de la superclase con la que se vinculan,
está directamente relacionado con el hecho de que a la superclase se le llame también clase
padre, y a las subclases, clases hijas.
ENEN 5.4.4. Asociación

Entre las clases pueden existir relaciones genéricas, que reciben el nombre de aso-
ciaciones. Cabe definir las asociaciones como relaciones entre clases del dominio
del problema que no tienen las características de la agregación ni de la relación de
generalización-especialización. También es común referirse a las asociaciones con el
nombre genérico de relación, por lo que se emplearán ambos términos indistintamente.
Las asociaciones pueden ser de diferentes tipos en función del número de clases que
vinculan. El número de clases que se vinculan por medio de una asociación recibe el
nombre de grado de la relación. En función de su grado, existen los siguientes tipos de
relaciones:
E Reflexivas: son las relaciones de grado 1, es decir, aquellas que vinculan a una cla-
se consigo misma.
E Binarias: son las relaciones de grado 2, esto es, aquellas que vinculan dos clases.
E Ternarias, cuaternarias...: son las relaciones de grado 3, 4..., es decir, aquellas que
vinculan tres, cuatro... clases, respectivamente.
Toda asociación se representa mediante una línea que une las clases vinculadas y lo
más habitual es asociarle un nombre, que suele ser un verbo y se debe escribir sobre di-
cha línea.
Una asociación reflexiva se representa por medio de una línea que une una clase consigo
misma. Por ejemplo, en una aplicación puede haber una clase Empleado y se podría querer
reflejar la jerarquía de la plantilla de la empresa, esto es, se podría querer saber, por cada
persona empleada, qué empleado o empleada es su jefe directo, que será solamente uno,
en caso de tenerlo. Para determinar las cardinalidades o multiplicidades, habría que plan-
tearse las siguientes cuestiones:
E Un empleado es jefe de ninguno o varios empleados, por lo que una de las cardina-
lidades será 0..* o *. Esto quiere decir que un empleado tiene cero o muchos su-
bordinados.
| l (»OMUNICACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
E Un empleado tiene como jefe a ningún empleado (si es el máximo responsable de

la empresa) o a solo uno (su jefe directo), por lo que la otra cardinalidad será O..1.
esJefeDe
0..1
Empleado
- NIF: String
- nombre: String
- dirección: String
- fecNac: Date
Figura 5.21. Diagrama UML que muestra una relación reflexiva de Empleado, la cual refleja el jefe directo
de cada persona empleada, en caso de que lo tenga.
Una relación binaria se representa por medio de una línea que une las dos clases. Por
ejemplo, puede haber una relación entre Cliente y Pedido, que indique por cada cliente
los pedidos que este ha realizado. En este caso, para la determinación de las cardinali-
dades, habría que plantearse lo siguiente:
E Un cliente puede realizar uno o varios pedidos, por lo que se pondrá 1..* al lado de
la clase Pedido.
E Un pedido es realizado por un único cliente, por lo que se escribirá 1 al lado de la

clase Cliente.
Cliente
- NIF: String
. realiza 4..+| - referencia: String
- nombre: String
- fecha: Date
- teléfono: String
Figura 5.22. Diagrama UML que muestra una asociación binaria entre Cliente y Pedido, que refleja los pedidos
que realiza cada cliente.
Para las asociaciones, agregaciones y composiciones, también se puede indicar su nave-

gabilidad, esto es, el sentido en el que se puede acceder a información desde una de las
clases intervinientes en la asociación. La navegabilidad se representa mediante una pun-
ta de flecha que indica en qué sentido es navegable la relación. Así, en el diagrama que
se muestra en la Figura 5.23, en el que se ha dibujado una punta de flecha al lado de la
clase Pedido, se indica que la relación es navegable de Cliente a Pedido, lo que quiere de-
cir que a partir de un cliente se puede acceder a todos sus pedidos, pero no es posible
saber por cada pedido qué cliente lo ha realizado.
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMÁT|CA Y CO/X 1
Cliente
- NIF: String
realiza 1..+| - referencia: String
- nombre: String
- fecha: Date
- teléfono: String
Figura 5.23. Diagrama UML que muestra una asociación binaria entre Cliente y Pedido navegable solo
de Cliente a Pedido, lo que quiere decir que a partir de un cliente se puede acceder a todos los pedidos
que este ha realizado.
El código que se genera a partir de este diagrama de clases debe ser similar al que se
muestra a continuación, en el que, como se puede observar, en la clase Cliente se ha
creado un atributo de tipo ArrayList para registrar sus pedidos.
1 public class Cliente (

2 private String NIF;
3 private String nombre;
4 private String teléfono;
5 private List<Pedido> pedidos = new ArrayList<Pedido> ();
..
7 )
S public class Pedido (
9 private String referencia;
10 private Date fecha;
AaE
1e
Si la punta de flecha se hubiese colocado solo al lado de Cliente, querría decir que, a par-
tir de un pedido, se puede saber el cliente que lo ha realizado, pero no es posible conocer
para un cliente todos los pedidos que ha solicitado. En este caso, se incluiría en la clase
Pedido un atributo de tipo objeto de la clase Cliente, como se puede observar en el siguien-
te código.
1 public class Cliente (

2 private String NIF;
3 private String nombre;
4 private String teléfono;
Se
6 )
7 public class Pedido (
8 private String referencia;

9 private Date fecha;
10 private Cliente cliente;
11
12 )
]MUNICAGONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
Si se dibujaran puntas de flecha tanto al lado de Cliente como al lado de Pedido, enton-
ces la relación sería navegable en los dos sentidos, y en el código generado, aparecería
en Cliente el atributo que indica el conjunto de pedidos que ha realizado, y en Pedido, el
atributo que indica el cliente que ha realizado el pedido.
No todas las herramientas emplean la misma notación para representar la navegabilidad.

Así, en algunas de ellas, la ausencia de punta de flecha en las dos partes indica que la
relación es navegable en los dos sentidos. En la mayoría de los diagramas que se mues-
tran a partir de aquí no hay dibujadas puntas de flecha, salvo que la navegabilidad de la
relación correspondiente sea relevante.
Las relaciones de grado mayor que 2 (ternarias, cuaternarias, etc.) se representan me-
diante un rombo que une a las clases relacionadas. Sería posible tener, por ejemplo,
una relación ternaria entre las clases Atleta, Prueba y Fecha, que indica, para los parti-
cipantes en una competición de atletismo, qué día o días han participado en cada prue-
ba. Para la determinación de las cardinalidades en el caso de las relaciones ternarias, se
debe tomar un objeto de cada dos clases y sería necesario plantearse con cuántos obje-
tos de la otra clase como mínimo y como máximo puede estar relacionado ese par de ob-
jetos. En este caso, habría que plantearse lo siguiente:
E Dados un atleta y una prueba, ese atleta en esa prueba ha podido participar ningún
día o varios días, por lo que se indicará la cardinalidad O..* o * al lado de Fecha.
E Dados un atleta y una fecha, ese atleta ese día puede haber competido en ninguna
o varias pruebas, por lo que se indicará la cardinalidad 0..* al lado de Prueba.
E Dadas una prueba y una fecha, ese día en esa prueba han podido participar ningu-
no o varios atletas, por lo que se indicará la cardinalidad O..* al lado de Atleta.
En la Figura 5.24 se muestra el diagrama UML que representa la relación ternaria arri-
ba descrita.
Atleta
participaEn Prueba
- dorsal: int
- código: int
- nombre: String
- descripcion: String
- equipo: String
|—
Fecha
- fecha: Date
Figura 5.24. Diagrama UML que muestra una asociación ternaria entre Prueba, Atleta y Fecha, que refleja el día
0 los días en los que participa cada atleta en cada prueba.
Hay algunas ocasiones en las que es necesario almacenar información acerca de las
asociaciones. La manera de reflejar esto es por medio de la creación de lo que se cono-
ce como una clase asociativa. A modo de ilustración, aquí se describe la relación binaria
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMAT|CA Y CIA]»
entre las clases Pedido y Artículo. Un pedido tiene como atributos su referencia y fecha,
y un artículo, su código, descripción y precio (PVP). En un pedido, se pueden solicitar uno
o varios artículos y un artículo puede ser solicitado en ninguno o en varios pedidos. Esto
se representa mediante el diagrama UML que se muestra en la Figura 5.25.
Artículo
0.* incluye 4.* |- código: String

- referencia: String
- descripción: String
- fecha: Date
- PVP: float
Figura 5.25. Diagrama UML que muestra una asociación binaria entre Pedido y Artículo, que refleja el artículo
0 los artículos solicitados en cada pedido.

Diagrama de clases para una cadena de supermercados |
Crea un diagrama de clases que refleje la información necesaria para gestionar una cade-
na de supermercados, de acuerdo con los siguientes requisitos:
E La cadena dispone de varios supermercados y, para cada uno de estos, se desea

registrar su código, nombre, dirección, número de teléfono y la ciudad donde está
ubicado.
E Cada ciudad tiene asignado un código, su nombre y el nombre de la provincia a la

que pertenece.
E Se sabe que en una ciudad puede haber varios supermercados de la cadena.
Cuando un cliente realiza un pedido, este puede solicitar un número diferente de unida-
des para cada uno de los artículos incluidos en dicho pedido, por ejemplo, en un pedi-
do podría solicitar 5 bolígrafos azules de la marca X y 20 gomas de borrar de la marca Y.
Este atributo, que hace referencia al número de unidades de cada artículo que se solici-
ta en cada pedido, y que se llamará cantidad, ¿dónde se sitúa: en la clase Pedido o en
la clase Artículo? No tiene sentido colocarlo en la clase Pedido porque en un pedido se
pueden solicitar cantidades distintas por cada uno de los artículos incluidos en él. Así,
en este ejemplo, se solicitan dos cantidades: 5 (bolígrafos) y 20 (gomas de borrar). Asi-
mismo, no es posible en un objeto de una clase asignar varios valores al mismo atributo.
Tampoco tiene sentido colocar este atributo en la clase Artículo porque un mismo artí-
culo se puede solicitar en varios pedidos y la cantidad que se solicita de dicho artículo
en cada pedido puede ser diferente. Por ejemplo, la goma de borrar de la marca Y puede
estar incluida en tres pedidos: en uno de ellos, se han podido solicitar 20 unidades; en
otro, 12; y en otro, 25.
Así pues, realmente, el atributo cantidad no proporciona información acerca de un pedi-

do ni acerca de un artículo, sino acerca de la relación entre pedido y artículo. O dicho de
otra forma, el atributo cantidad nos indica por cada pareja de pedido-artículo, el número
XÍ' xOMUNICACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
de unidades de ese artículo que se solicitan en ese pedido. La manera de reflejar esta
información es creando una clase asociativa vinculada a la relación entre Pedido y Artí-
culo. Se podría llamar a esta clase LíneaPedido, que en la vida real hace referencia a la
parte de cada pedido correspondiente a cada artículo solicitado en dicho pedido. Tenien-
do esto en cuenta, en esta clase asociativa se colocará el atributo cantidad, que indica el
número de unidades que se solicitan de cada artículo en cada pedido. Una clase asocia-
tiva se representa como una clase normal, pero se une mediante una línea discontinua a
la asociación a la que se vincula, como se muestra en la Figura 5.26.
Artículo
Pedido
: - código: String
- referencia: String — | 0* incluye T
! - descripción: String
- fecha: Date E
H - PVP: float
LíneaPedido
- cantidad: int
Figura 5.26. Diagrama UML que muestra, además de una asociación binaria entre Pedido y Artículo, una clase
asociativa, a la que se ha llamado LíneaPedido. Esta indica, por artículo solicitado en cada pedido, la cantidad
o número de unidades que de ese artículo se han solicitado en ese pedido.
P
Recuerda .
Si se establece una analogía entre los diagramas de clases y los diagramas
entidad-relación, que se emplean para representar conceptualmente la información que
se debe almacenar en una base de datos, se podría decir que una clase asociativa de un
diagrama de clases es un constructo que se crea para albergar lo que en un diagrama
entidad-relación serían los atributos de una relación. De esta forma, una clase asociativa
contiene los atributos que corresponderían a una relación en un diagrama entidad-relación.

Diagrama de clases para una cadena de supermercados ll
Amplía el diagrama de clases de la Actividad propuesta 5.1 teniendo en cuenta que aho-
ra, por cada supermercado, además se desean conocer los artículos que tiene a la venta.
Para ello, se deben considerar los siguientes requisitos:
El Por cada artículo, se desea registrar su código, descripción, precio de venta al públi-
co (PVP) y stock o existencias que hay de ese artículo en cada supermercado.
El No es necesario que en todos los supermercados se vendan todos los artículos.
El El PVP de un artículo determinado puede diferir de un supermercado a otro, esto es,

un mismo artículo no tiene por qué venderse al mismo precio en todos los super-
mercados.
También se pueden vincular clases asociativas a relaciones de grado mayor que 2 (ter-
narias, cuaternarias, etc.). Si, por ejemplo, para el diagrama UML de la Figura 5.24, se
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMÁTICA Y (:OM v
quisiera almacenar por cada día en el que un atleta participa en una prueba, el resultado
obtenido por ese atleta ese día en esa prueba, habría que vincular una clase asociativa
a la relación ternaria con el atributo resultado de tipo String. En este atributo, se almace-
naría el tiempo que ha empleado en la carrera, la longitud saltada, la distancia a la que
ha llegado el elemento lanzado, etc. La Figura 5.27 muestra el diagrama UML con la cla-
se asociativa.
Fecha
- fecha: Date
Atleta
Prueba
- dorsal: int
-] - código: int
- nombre: String
- descripcion: String
- equipo: String
Participacion
- resultado: String
Figura 5.27. Diagrama UML que muestra una asociación ternaria entre Prueba, Atleta y Fecha, que refleja
el día o los días que participa cada atleta en cada prueba. Además, se ha vinculado una clase asociativa
a dicha relación ternaria con el objetivo de almacenar el resultado obtenido por cada atleta en cada prueba
en la que ha participado.

Diagrama de clases para una cadena de supermercados lII
Amplía el diagrama de clases de la Actividad propuesta 5.2, teniendo en cuenta que se
desea manejar información sobre los proveedores que suministran artículos a los super-
mercados. Para ello, se debe tener presente que:
E Por cada proveedor, se desea registrar su número de identificación, nombre, direc-
ción y qué artículos suministra a cada supermercado, dado que un proveedor no
tiene por qué suministrar los mismos artículos a todos los supermercados de la
cadena.
E Además, un mismo artículo lo puede vender un proveedor a diferentes precios en
función del supermercado al que se lo suministra.
E Se quiere tener constancia de qué artículos suministra cada proveedor a cada su-
permercado y a qué precio. Este se conoce habitualmente como precio de venta de
distribución (PVD).

; '¡'Jí'xk/;i! UN'CAGONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
Cada tipo de vehículo consta de varias piezas (carrocería, motor, ruedas, etc.) y
cada una de estas piezas se puede descomponer en piezas más pequeñas, y así
sucesivamente, hasta llegar a piezas indivisibles, como por ejemplo, un espejo o un
tornillo.
Se consideran piezas todos los componentes de un tipo de vehículo independien-
temente de su tamaño, por lo que se considera que un vehículo es una pieza en sí
misma, pero también lo es un simple tornillo.
Dada una pieza, puede que esta no forme parte de ninguna pieza superior (tal es el
caso de un vehículo) o que forme parte de varias piezas superiores.
Se desea conocer:
Por cada pieza, su código, nombre, existencias, existencias mínimas deseables, en

qué pieza o piezas está incluida (si es el caso) y de qué pieza o piezas consta (si es
el caso).
Por cada pieza que consta de piezas inferiores, el número de unidades de cada pie-
za inferior que incluye cada pieza superior; así, no solo interesa saber que un de-
terminado tipo de vehículo consta de motor y de ruedas, sino también cuántos
motores tiene ese tipo de vehículo (uno) y cuántas ruedas (4, por ejemplo).
Solución
Para poder manejar toda esa información, se debe crear una clase Pieza, y para reflejar la je-
rarquía de piezas, se debe establecer una relación reflexiva. Así pues, con el objeto de deter-
minar las cardinalidades o multiplicidades de esta relación, hay que plantearse las siguientes
cuestiones:
Una pieza se descompone o divide en ninguna o varias piezas, por lo que una de las
cardinalidades es 0..* o *. Las piezas indivisibles no se dividen en piezas más pe-
queñas.
Una pieza está incluida en ninguna pieza (si la pieza es un tipo de vehículo) o en va-
rias, por lo que la otra cardinalidad también es 0..* 0 *.
Por otro lado, para saber el número de unidades de cada subpieza en que se divide cada
pieza, se necesita vincular, a la relación reflexiva, una clase asociativa albergando ese nú-
mero, que indicará, por cada pareja de pieza-subpieza, el número de subpiezas que con-
tiene cada pieza (véase la Figura 5.28).
se divide en
- Composición
Pieza
- unidades: Integer
- código: String
- nombre: String
- stock: Integer
- stockMínimo: Integer
Figura 5.28. Diagrama UML que muestra una relación reflexiva de la clase Pieza, necesaria para conocer
la relación jerárquica existente entre las piezas. Se precisa de una clase asociativa para conocer el número
de subpiezas que contiene cada pieza.
5. ELABORACIÓN DE DIAGRAMAS DE CLASES Y COM
INFORMÁTICA
BNE 5.4.5. Realización

Una relación de realización es la que se establece entre una clase Interface y las clases
que implementan esa interfaz. Una clase Interface es un mecanismo que se puede em-
plear en Java para permitir la herencia múltiple, es decir, que una clase herede de varias
superclases. El motivo es que, en Java, una clase solo puede heredar de una superclase,
pero puede implementar una o varias interfaces.
Las interfaces suelen contener métodos comunes a varias clases, de forma que todas
las clases que implementan una interfaz o que establecen una relación de realización
con una interfaz, heredan de dicha interfaz todos sus métodos.
Por ejemplo, se podría tener las clases Figura y Fracción que implementan la interfaz
Comparar que incluye un método esMayorQue(), el cual permite determinar si una figura
es mayor que otra (tiene un área mayor que otra) o si una fracción es mayor que otra. A
su vez, la clase Figura tiene tres subclases: Rectángulo, Triángulo y Círculo. Una relación
de realización se representa gráficamente uniendo mediante una línea con trazado dis-
continuo cada clase con la interfaz que implementa y esta línea tiene en el extremo un
triángulo apuntando a la interfaz, como se puede observar en la Figura 5.29.
«interface»
Comparar
Figura
- X; float - numerador; int
- Y: float - denominador: int
Rectángulo Triángulo | Círculo |
- ancho; float - base; float - radio; float
- alto: float - altura: float
Figura 5.29. Diagrama UML que muestra una relación de realización entre Figura y la interfaz
Comparar y otra relación de realización entre Fracción y la interfaz Comparar. Además,
la clase Figura es la superclase de las subclases Rectángulo, Triángulo y Círculo.
M 5.5. Tipos de clases de analisis

Durante la fase de análisis del desarrollo de una aplicación, siguiendo el paradigma
orientado a objetos, se deben identificar tres tipos de clases:
]MUN'CAGONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
1. Las clases de interfaz se usan para modelar la interacción entre el sistema y sus ac-
tores. Esta interacción consiste normalmente en recibir y mostrar información o pe-
dirla a las personas usuarias o sistemas externos. Estas clases se deben limitar a
describir la información y peticiones que se intercambian los actores y el sistema a
través de ellas. Cada clase de interfaz se debería asociar a, al menos, un actor, y vi-
ceversa. Se usan estas clases para modelar ventanas, formularios, impresos, etc.
2. Las clases de entidad se emplean para modelar información que persiste en el

tiempo. Suelen mostrar una estructura de datos lógica.
3. Las clases de control realizan la coordinación y el control sobre otros objetos del
sistema. Toda la dinámica del sistema es modelada por clases de control. Se aso-
cia una clase de control a cada aplicación y esta clase modela la dinámica del sis-
tema delegando trabajo a otras clases.
Cada tipo de clase se representa como se muestra en la Figura 5.30.
OOO
Clase de interfaz Clase de control Clase de entidad
Figura 5.30. Representación de los tipos de clases de interfaz, de control y de entidad.
E 5.0. Herramientas para la creación de diagramas de clases

En la actualidad, existen muchas herramientas para la creación de diagramas de clases.
En esta unidad, se aprenderá a emplear tres de ellas:
E diagrams.net: es una herramienta muy sencilla de aprender y utilizar, pero que no

realiza comprobaciones sobre los diagramas creados, por lo que es posible crear
diagramas que no respeten las normas de UML.
E Papyrus: es una herramienta mucho más avanzada que se puede integrar en Eclipse
como un módulo y que permite realizar todo tipo de diagramas UML.
E Modelio: es una aplicación de modelado UML de código abierto que permite crear
todo tipo de diagramas y, además, generar el código correspondiente.
ME 5.0.1. Creación de diagramas de clases con diagrams.net

La herramienta diagrams.net permite elaborar multitud de diagramas distintos y se pue-
de utilizar accediendo a la página web https://app.diagrams.net/, por lo que no es nece-
sario instalarla en el ordenador, aunque también se ofrece la posibilidad de descargarse

una aplicación de escritorio e instalarla.
Nada más acceder a la página web indicada, se ofrecen dos opciones: crear un nuevo
diagrama o abrir un diagrama (véase la Figura 5.31).
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMÁTICA Y COM l )
E2 Device
Create New Diagram
Open Existing Diagram
Change storage
Figura 5.31. Pantalla de inicio de diagrams.net, en la que se muestran

dos opciones: crear un nuevo diagrama o abrir un diagrama existente.
Tras seleccionar la opción Create New Diagram, en la ventana que aparece a continua-
ción, se asigna un nombre al diagrama y se deja el tipo de archivo por defecto: de tipo
XML con la extensión .drawio. Se puede elegir, además, el tipo de diagrama que se de-
sea crear; en este caso, UML. Por último, se hace clic en el botón Create (Figura 5.32).
D Filename: [DiagramaPrueba-drawio ] [XMLFile (.drawio) RjO

Search a - la "
Business (15) = — —Q: — = Q — - 1- — º—'_

Charts (5) "V —
» Cloud (41) = = E
Engineering (3) T i | | Foa
Flowcharts (9) a
Maps (5)
Network (13) a a q
Olher (11) EE -
Software (12) l*l = L1 — a
Tables (4) :E=1'1 | | ==o- e
UML (8)
Venn (8) _
Wireframes (5) le a - - a
Layout (4) e = re
Help Cancel From Template URL
Figura 5.32. Ventana en la que se da un nombre al diagrama y se deja

el tipo y la extensión por defecto.
A continuación, la herramienta pide indicar la ubicación en nuestro equipo donde se de-

sea guardar el diagrama y se debe volver a escribir su nombre (Figura 5.33).
) - T de Paraninfo » ED » Imágenes v || - BuscarenImágenes
Organizar = — Nueva carpeta

E h
“r Favoritos
18 Descargas
E Escritorio
S Mobile Uploads
“E Stios recientes Figuras-24.drewi — Figura5-25.drawi — Figura5-26.drami — Figura6-1.drawio
o o o
d OneDrive h b
b Grupo en el hogar
Figura6-2.drawio — Figurab-3.drawio
Tipo: [XML File (*.drawio;"

ml asit*.bls)
(a) Ocultar carpetas
Figura 5.33. Ventana en la que se indica la ubicación donde se desea

guardar el diagrama en el equipo y se asigna su nombre.
| l/ í,OMUNICACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
Aparece entonces la pantalla principal de diagrams.net (Figura 5.34), en la que se distin-

guen las siguientes áreas:
E Área de paletas: en esta área situada en la parte izquierda de la pantalla, hay dis-
tintas paletas disponibles para seleccionar los elementos que se desean dibujar
en nuestro diagrama. Hay varias paletas con distintos nombres para crear distin-
tos tipos de diagramas: General, Flowchart, Entity Relation, UML, UML 2.5, etc. En
el ejemplo que aquí se expone, se hará uso de las paletas UML y UML 2.5. Al ha-
cer clic en cualquiera de ellas, se pueden visualizar todas las formas de que dis-
pone cada paleta. Si no está disponible la paleta UML 2.5, se debe pulsar en el
enlace + More Shapes de la esquina inferior izquierda de la pantalla y, en la sec-
ción Software de la ventana que aparecerá a continuación, se marca la casilla de
verificación correspondiente a UML 2.5, tras lo cual aparecerá esta paleta en el
área de paletas.
E Área de edición: es el área que aparece en la parte central de la pantalla y en ella

se dibujará el diagrama correspondiente.
M Área de propiedades: en esta área de la parte derecha, se muestran y se pueden

modificar las propiedades del elemento seleccionado en el área de edición o del
diagrama, si no está seleccionado ningún elemento.
B DiagramaPrueba.drawio - diagra: X
€ > C 4 appdiagrams.net E a n * º :
1I Aplicaciones d Bookmarks [ Natur E Nucleus M XAMPP G LaguíaGranCanari.. 9 Hombres: Nunca es... » Lista de lectura
DiagramaPrueba.drawio
File Edit View Arrange Extras Help
- 10%- Aaáa
Page View
) Backgruun
O Shadow
Options
Connection Arrows
Connection Points
Guides
Autosave
Paper Size
A4 (210 mm x 297 mm)
Figura 5.34. Pantalla principal de diagrams.net, donde se distinguen tres áreas de izquierda a derecha:
área de paletas, área de edición y área de propiedades.
Para practicar el uso de esta herramienta, aquí se va a crear un diagrama de clases que
refleja información sobre el personal y los clientes de una empresa, así como los artícu-
los que esta vende y los pedidos que realizan los clientes de estos artículos (véase su
representación en la Figura 5.35).
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMATICA Y <|í' /MX'—'1
Persona
- NIF: String
- nombre: String
- dirección: String
- teléfono: String
Empleado
- fecNacto: Date - NSS: String

- fecAlta: Date es jefe de
- puesto: String
realiza :
(¿_ + gestiona
| Artículo
Pedido
, - 0.* incluye 1..*) - código: String
0.* | referencia: String
- - descripción: String
- fecha: Date
LineaPedido - precio: float
2 -soÑ5 i. ——m—.—m <q
- cantidad: int
Figura 5.35. Diagrama de clases creado con diagrams.net que refleja el personal y los clientes de una empresa
y los pedidos que estos hacen de los artículos que vende la empresa.
Para crear una clase, tan solo hay que hacer clic sobre uno de los dos siguientes ico-
nos de la paleta UML: , en función de si se quiere reflejar atributos y métodos de
cada clase o solamente sus atributos, respectivamente. Aquí, se hará clic con el botón iz-
quierdo del ratón en el primero de estos iconos para crear las clases. Aparecerá entonces
una clase en el área de edición. Después, hay que colocarse sobre la palabra Classna-
me y escribir el nombre que se desea dar a la clase, por ejemplo, Pedido. Una vez he-
cho esto, hay que colocarse sobre cada campo e indicar su visibilidad, nombre y tipo,
por ejemplo: — referencia: String (Figura 5.36). Para añadir otro atributo, se seleccio-
na este con el botón izquierdo del ratón, se activa en el menú contextual la opción
Duplicate y aparecerá duplicado debajo del último método, pero se puede subir, arras-
trándolo con el botón izquierdo del ratón pulsado hasta el área de atributos que se quie-
ra. ES posible asimismo cambiar su visibilidad, nombre y tipo. Si no se desea indicar
métodos para alguna clase, es posible colocarse sobre todos los métodos que haya y
eliminarlos, eligiendo la opción Delete del menú contextual o pulsando la tecla Supr. Se
puede modificar el tamaño de una clase, seleccionándola y pulsando sobre la sección
superior de la clase (donde se muestra el nombre) y arrastrando cualquiera de las fle-
chas que se muestran.
| i (,OMUNICACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
Pedido
- fecha: Date
Figura 5.36. Clase Pedido creada con diagrams.net con dos

atributos (referencia y fecha) y sin métodos.
La clase Artículo se podría crear de manera similar.
Para dibujar una asociación sin indicación de navegabilidad entre dos clases, se puede
clicar en el elemento de la sección UML de la paleta que se muestra en la Figura 5.37.
parent child
Association 1
Figura 5.37. Elemento de la paleta UML para crear

una asociación entre dos clases.
Al hacer clic sobre este elemento, este pasará al área de edición y se debe arrastrar
pulsando cada uno de sus extremos hasta el borde de la clase donde se quiere unir la
línea. Una vez hecho esto, se sobrescriben las palabras parent y child con las cardinali-
dades o multiplicidades que corresponda. En este caso, para la relación entre Pedido y
Artículo, una de las cardinalidades debe ser 0..* y la otra, 1..*. Aunque en un diagrama
de clases UML, no es obligatorio asignar nombre a las relaciones, es muy conveniente.
Para ello, se puede hacer uso del elemento Text de la sección General de la paleta: se
hace clic en este elemento y aparecerá en el área de edición. Se sobrescribe la palabra
Text con el texto incluye y se arrastra este hasta colocarlo sobre la línea de la relación.
De este modo, quedarán unidas las clases Pedido y Artículo (Figura 5.38).
Artículo
Pedido
0.* incluye 4..4 - código: String
- descripción: String
- fecha: Date
- precio: float
Figura 5.38. Parte del diagrama de clases en el que se muestran las clases Pedido y
Artículo unidas por medio de una asociación llamada incluye.
Como se puede observar en la Figura 5.35, hay una clase asociativa vinculada a la rela-
ción incluye llamada LíneaPedido. En este ejemplo, se creará esta clase como cualquier
otra, y para unirla a la relación incluye, se usará una línea con trazado discontinuo me-
diante el elemento Dashed Line de la sección General de la paleta (Figura 5.39).
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMAT|CA Y GÍ))M
Dashed Line
Figura 5.39. Elemento de la paleta General para crear una

línea discontinua.
Después, se pueden crear las clases Persona, Cliente y Empleado y para reflejar la rela-
ción de generalización-especialización entre la superclase Persona y las subclases Clien-
te y Empleado, se utilizará el elemento llamado Generalization de la sección UML de la
paleta (Figura 5.40).
Extends——>
Generalization
Figura 5.40. Elemento de la paleta UML para crear una

relación de generalización-especialización.
Tras hacer clic en este elemento, se arrastra el extremo con el triángulo hasta que toque
la superclase Persona y el otro extremo hasta tocar una subclase. Conviene eliminar la
leyenda Extends de la flecha, para lo que hay que colocarse sobre esta leyenda y pulsar
la tecla Supr.
Por último, se pueden establecer las relaciones binarias realiza y gestiona entre Cliente
y Pedido y entre Empleado y Pedido, respectivamente, y la relación reflexiva es jefe de la
clase Empleado.
Una vez terminado el diagrama, se debe guardar activando la opción de menú File > Save,
o bien File > Save as, esta última opción si se quiere dar un nombre distinto del indicado
con anterioridad. Se creará un archivo editable desde diagrams.net en la ubicación indi-
cada de tipo XML y con extensión .drawio.
También es posible exportar el archivo a diferentes formatos: de tipo imagen (PNG, JPEG
y SVG), PDF, HTML, etc. Para ello, hay que seleccionar la opción de menú File > Export as.
ME 5.6.2. Creación de diagramas de clases con Papyrus

Papyrus SysML fue instalado como un módulo del IDE Eclipse en el Apartado 2.5.1. Este
módulo permite crear todos los tipos de diagramas UML.
Una vez instalado, para su uso, es necesario abrir la vista Papyrus para que aparezcan
en pantalla todos los elementos necesarios para la creación de diagramas UML. Para
que se abra dicha vista, se selecciona la opción de menú Window > Perspective > Open
Perspective > Other > <Papyrus>.
j/'x_¡¡ Y COMUNICACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
Con objeto de generar un diagrama de clases, lo primero que se debe hacer es crear un
proyecto, para lo que hay que seleccionar la opción de menú File > New > Papyrus Pro-
ject. En la ventana que se muestra en la Figura 5.41, se marca la casilla de verificación
correspondiente a UML:
Select Architecture Context

Select the architecture context(s) and viewpoints to apply to /
the Papyrus model
Architecture Contexts:
«e ing.
m|
Ia UML
4 ] € Systems Engineering
CE SysML 1.6
Architecture Viewpoints:
] € Software Analysis
] € Software Design
Figura 5.41. Al crear un proyecto en Papyrus para elaborar un diagrama

de clases, se debe seleccionar el contexto UML.
Después de hacer clic en el botón Next, en la siguiente ventana, se debe asignar un nom-
bre al proyecto, por ejemplo, DClasesEmpresa. En la ventana siguiente (Figura 5.42), es
necesario indicar el tipo o los tipos de diagramas que se desea incluir en el proyecto. En
este caso, solo se indica que se desea hacer diagramas de clases marcando la casilla
de verificación Class Diagram.
Initialization information
Select root element name and representation kind
Root model element name:

| DClasesEmpresa
Select a Representation Kind:
Representation name
44 Activity Diagram
M PA Class Diagram
F Class Tree Table
E Communication Diagram
El Component Diagram
You can load a template:
A UML model with basic primitive types
Choose profiles to apply

Figura 5.42. Como último paso en el proceso de creación de

un proyecto Papyrus, se han de seleccionar el tipo o los tipos
de diagramas UML que se desean crear en el proyecto.
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMATICA Y CQÍM -
Tras pulsar en el botón Finish, aparece una ventana (Figura 5.43), con varias áreas:
E Explorador de proyectos (Project Explorer), en la parte superior izquierda.
E Explorador del modelo (Model Explorer), en la parte izquierda debajo del explorador
de proyectos; en esta área, se permite navegar por los diferentes elementos del
modelo. Se creó un modelo asociado al proyecto en el proceso de creación del pro-
yecto Papyrus.
E Outline, en la parte inferior izquierda; en esta área, se muestra una miniatura del
diagrama que se está creando.
E Editor de diagramas, en la parte central; esta área se emplea para el dibujo del dia-
grama correspondiente.
E Paleta, en la parte derecha; se debe seleccionar de la paleta los elementos que se

desean añadir al diagrama haciendo clic, en primer lugar, sobre el elemento corres-
pondiente y luego sobre el editor de diagramas. En la sección Nodes de la paleta,
se pueden seleccionar clases, atributos, interfaces, métodos, etc.; y en la sección
Edges, las asociaciones entre clases.
E Propiedades (Properties), en la parte inferior; en esta área se pueden ver y modificar

las propiedades o características del elemento del modelo seleccionado, el cual se
puede seleccionar en el diagrama (editor de diagramas) o en el explorador del modelo.
Elle Edit Navigate Search Papyrus Project Run Window Help

ICE- RE NA-0- 02- =-|B| -- --0-e-| 0 - 0% IX -O-Q-5 y-
EN M-eOe O MedIB /|A- r. Q E| E sinin
(Ey Project Explorer X 5 O 7 iasesEmpresadi X m
aSy ! : ; " HE HE ; ; | Palete D
5 1 DClasesEmpresa MRadr-.
» J Ejercicios al Nodo =
El Class
£9: Classifier Template Parameter
12 Comment
E £l Component
TE Model Explorer X
EE 0e f Ea be A : : : Ea i (2).Con
> En DClasesEmpresa y ' '1 y " T : e - ; : m : , Abstraction
» / Asseciation (Directed)
/ Association Branch
E Association Class
[ M Conteinmmeninbe
B Class Diagram |
EE Outline X —_ — —
[ Properties X J Model Validation %7 References Q Documentation
-| E DClasesEmpresa
Name
Figura 5.43. Vista Papyrus de Eclipse con los elementos necesarios para crear diagramas de clases
repartidos en diferentes áreas.
Con el propósito de practicar el uso de esta herramienta, aquí se va a crear el mismo dia-
grama de clases que se creó con diagrams.net en el Apartado 5.6.1 (Figura 5.35).
Para crear una clase hay que hacer clic sobre el elemento con el nombre Class de la paleta
y luego clicar en el editor de diagramas. Seleccionada la clase, en el área de propiedades,
se escribe el nombre que se desea dar a la clase en el campo Name, por ejemplo, Pedido.
| A H1/ COMUNICACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
Si se escribe algo en el campo Label, lo que se escriba en él es lo que se mostrará en el

diagrama como nombre de la clase. Se puede indicar si la clase es abstracta o no en |s
abstract, y si es o no activa en ls active. Es posible establecer su visibilidad seleccionan-
do entre las opciones public, private, protected o package. En este caso, se van a dejar
todas las opciones por defecto (Figura 5.44).
B Class Diagram X |
E Properties X / Model Validation %7 References - Documentation m
E Pedido
f UNIL Name [ Pedido
| Comments Label f
Profile -
| Qualified name DClasesEmpresa::Pedido
Style
Appearance ls abstract Otme (false Is active Otme (false
Rulers And Grid _ Visibility [publid y
Advanced =
Owned attribute EE
Owned operation ] * Owned reception [e] *
Figura 5.44. En la sección Properties, se pueden ver y modificar las propiedades de una clase
(su nombre, visibilidad, etc.).
Para indicar los atributos de la clase, se debe hacer clic en el botón j de la sección
Owned attribute del área de propiedades. En la ventana que aparece entonces (Figura
5.45), se debe indicar, por cada atributo, su nombre en Name, su visibilidad, su tipo de
dato en Type y su valor por defecto, si lo tiene, en Default value. Además, si el atributo
tiene un valor único, se elige la opción true en ls unique. En cuanto al tipo de dato, la ma-
yoría de los tipos de datos primitivos de Java están disponibles en el paquete «EPackage,
ModelLibrary» Primitive Types. Se dispone de más tipos de datos, como el de tipo fecha
(EDate) en el paquete «ModelLibrary» EcorePrimitive Types, y se accede a estos al hacer
clic en el botón (-+ que aparece al lado de Type.
Otue Ofalse
Otmue Ofalse
Otme Ofalse
private
UML | Comments:
Figura 5.45. Ventana que muestra las propiedades del atributo referencia de
la clase Pedido: su nombre, tipo de dato y visibilidad son las más importantes.
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMÁTICA Y CO/X1
Se debe proporcionar la misma información para el otro atributo de la clase Pedido, es

decir, para fecha.
Una vez proporcionada la información de los atributos, para que esta se pueda visualizar
en el diagrama, es necesario arrastrar cada atributo del explorador del modelo hasta la
clase a la que pertenece. De este modo, la clase Pedido se verá en el diagrama como se
muestra en la Figura 5.46.
E Pedido
E - referencia: String [1]
EZ - fecha: EDate [1]
Figura 5.46. Representación de la clase Pedido en un diagrama de clases UML

creado con Papyrus SysML.
Se puede crear de manera similar la clase Artículo.
Para dibujar una asociación con clase asociativa vinculada, se debe hacer clic en el icono
de la sección Edges de la paleta con el nombre Association Class y luego se debe pinchar
sobre una de las clases y posteriormente sobre la otra. Aparecerá entonces una asocia-
ción dirigida entre las dos clases y la clase asociativa, a la que se debe dar el nombre
LíneaPedido y asignarle el atributo cantidad de tipo integer.
Al hacer clic sobre la línea que representa la asociación, se mostrarán las propiedades
de la asociación, las cuales se pueden modificar. En Name aparece el nombre de la clase
asociativa, LíneaPedido, que se va a mantener. Se deben cambiar las multiplicidades o
cardinalidades a cada lado de la asociación, de modo que sean 1..* al lado de Artículo y
0..* al lado de Pedido. Para que estas se muestren en el diagrama, además de ponerlas
en Multiplicity, se deben escribir en el campo Name, como se muestra en la Figura 5.47.
[ Properties X [ )|
úl LíneaPedido |
UML Name [LínezPedido J
Comments
o Label YY
s;ñ'º Is abstract Otme - Ofalse Is active Otue - Ofalse
e
— ls derived Otue - Ofalse
[ public -
Advance Visibility
Rulers And Grid .
Ovmed atiribute E-
Advanced —
EZ cantidad : Integer
Member End Member End

Name “ | Name [0.*
Label - Label
ee [E artículo El eZ ] e |E Pedido ] ] [2] [
Ouwner Association v Owner [ Association v

Navigable Otme - Ofalse Navigable Otme Ofalse
Aggregation none a Aggregation | none v
Multplicity [ Y) [E] — Muttipiiciy E ] [S]
Figura 5.47. Propiedades de la asociación con clase asociativa LíneaPedido entre Pedido y Artículo.
X1/ KOMUNICAC'ONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
Tras estos cambios, la asociación entre Pedido y Artículo con la clase asociativa LíneaPe-
dido quedará como se refleja en la Figura 5.48.
E - referencia: String [1] E - código: String [1]

EZ - fecha: EDate [1] “ E - descripción: String [1]
E- - precio: Real [1]
Figura 5.48. Representación de las clases Pedido y Artículo unidas por medio de una asociación con una clase
asociativa vinculada llamada LíneaPedido.
A continuación, se crearán las clases Persona, Cliente y Empleado. Una vez creadas es-
tas tres, se debe establecer la relación de generalización existente entre ellas, ya que
Persona es superclase de Cliente y Empleado. Para ello, se hace clic sobre Generalization
en la sección Edges de la paleta y luego se clica en la subclase y la superclase.
Se puede ahora establecer la relación binaria realiza entre Cliente y Pedido. A tal fin,
se debe hacer clic sobre Association (Directed) en la sección Edges de la paleta y lue-
go sobre cada una de las clases vinculadas (Cliente y Pedido). Aparecerá entonces una
asociación con flecha (dirigida) entre las dos clases. Al hacer clic sobre la línea que re-
presenta la asociación, se puede modificar sus propiedades. En Name se escribe el nom-
bre realiza. Si no se quiere que la asociación sea navegable o tenga punta de flecha, se
seleccionará la opción false en Navigable. Finalmente, se escribe en Multiplicity las cardi-
nalidades correspondientes: 0..* al lado de Pedido y 1 al lado de Cliente. Las propieda-
des de esta asociación deben establecerse como se indica en la Figura 5.49.
[ Properties X mieics
7 realiza
UML Name realiza |
Comments Label [ 1
Profile “ : -
Siye Visibility public
ñ ppearance Member End Member End
— Name [ pedido | Name cliente |
Rulers AndGrid — Label [ | Label ]
Advanced — =
Type El Pedido Cel e E Criente E [l (2 [2e]
Owner | Association | Oe Association -
Navigable Otue Ofalse Navigable Otue Ofalse
Aggregation | none v Aggregation none v
Multiplicity - v| [El - Multipticity 1 ] [S]
Figura 5.49. Propiedades de la asociación realiza entre Cliente y Pedido.

De manera similar, se crean la asociación binaria gestiona entre Empleado y Pedido y la

relación reflexiva es jefe de de la clase Empleado. El diagrama de clases quedará como
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMÁTICA Y CO/X
+ AlquilarPelícula()
+ DevolverPelícula()
— E A
Película m - nombre : string m“º':t mº_;"'“
“o:ly
; - dirección; str
-g
TE -emai sirirg
mtníglm - numSocio : string
<aPodición: - ecAla: e - ecAlquier: dale
::b¿ro?.:;;n “ pesamión: d — - fecD£*reu'sta :sting
I'$ínjr$t oc$ncwpel a manan 1| +gelSanción): foat - lecDevie: sting
al
integer): boolean + selSanción(in importe: toa) 1| +setFecDeealín value:string) 00
EsOl + CompararNIF(in NIF: string): bool... '
Stock0: nteger — | NIF: string, in CodPel: integer) — C
+ Alquilerfin
S .Zim=>->--———mmm——m—— ,
| .. .>=—---4-G e +| + ComprobarSanción(: foat
—P__—“ -
Figura 5.50. Diagrama de clases creado con Papyrus en Eclipse que refleja los empleados y clientes
de una empresa y los pedidos que estos hacen de artículos que vende la empresa.
Una vez finalizado el diagrama, se debe guardar seleccionando la opción de menú File >
> Save. También es posible exportar el diagrama a diferentes formatos, seleccionando
el modelo en el explorador de proyectos y la opción del menú contextual Export... y lue-
go la opción Papyrus > Export All Diagrams. Se puede exportar a formato GIF, BMP JPEG,
JPG, SVG o PDF.
BNE 5.0.3. Creación de diagramas de clases con Modelio

La herramienta Modelio permite crear todo tipo de diagramas UML y se puede descargar,
desde la página web https://www.modelio.org/ downloads/download-modelio.html, la ver-
sión correspondiente al del sistema operativo sobre el que se desee realizar la instala-
ción (Windows, RedHat, Debian, Ubuntu o macosS).
Al ejecutar por primera vez la herramienta, aparece una ventana de bienvenida desde la
que es posible acceder a diferentes guías. Aquí se va a realizar el diagrama de clases de
la Figura 6.18 de la Unidad 6.
A Kf/ £OMUNICAC'ONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
Una vez se cierra la ventana de bienvenida, para comenzar a trabajar con Modelio, se
debe crear un proyecto seleccionando la opción de menú File > Create a project. En el
cuadro de diálogo que aparece entonces (Figura 5.51), se debe dar un nombre al pro-
yecto y se puede proporcionar una descripción de este. Después, se activa la casilla de
verificación Java project para posteriormente generar el código Java correspondiente al
diagrama de clases. Para crear el proyecto, se pulsa sobre el botón Create the project.
Create a project
Enter project details
ProyectoVideoclub
Figura 5.51. Ventana de creación de un proyecto en Modelio, en la que se debe dar

un nombre al proyecto que se está creando.
En la parte izquierda de la ventana, aparece entonces una carpeta con el nombre del
proyecto. En el proyecto, se creará un paquete con el nombre Videoclub. Para ello, se
despliegan las dos carpetas con el nombre del proyecto y en el menú contextual de la
carpeta inferior, se elige la opción de menú Create element > Package, como se puede
observar en la Figura 5.52.
File Edit Configuration Views Help
diesProjectX |
— Search -QemEC ioM1h
Persectves Package
= =a
te= mode 1e , - | as
€O7 EN 1 ) Interface
4 É ProyectoVideoclub E sa
> E LocalModule Create diagram... =
a e PmyedoV¡den(qu Create element » % e
; m Component
b E PredefinedTypes 3.9 -'1 RD eane , E Artifact

Q ModelerModule » ) Ne
$, Addstereotype E UseCase
Figura 5.52. Para crear un diagrama en Modelio, una vez creado un proyecto, hay que
seleccionar la carpeta correspondiente al proyecto y la opción del menú contextual
Create element > Package.
Seguidamente aparece en el explorador del modelo un paquete al que se debe asignar

un nombre escribiendo directamente el nombre elegido sobre el nombre que aparece por
defecto (Package); en este caso, se va a llamar Videoclub.
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMAT|CA Y COM … |
A continuación, dentro de este paquete, se indica que se desea crear un diagrama, acti-
vando la opción del menú contextual Create diagram (véase la Figura 5.53).
File Edit Configuration Views Help
leX
f- Model 32 1
€O7 EE -
a ,g-—,_l ProyectoVideoclub
D $ LocalModule
Create diagram...
Create element »
Modeler Module »
» JavaDesigner »
Figura 5.53. Para crear un diagrama en Modellio, tras crear un paquete, hay que
seleccionar el paquete y elegir la opción del menú contextual Create diagram.
Es necesario indicar el tipo de diagrama que se quiere crear, en este caso, un diagrama
de clases, y asignarle un nombre (Figura 5.54).
Creation wizard
Creste 2 Class diagram
Identification
la e UML/BPMN Name | DiagramaClasesVideoclub|
Gn Owner | Videoclub
Activity diagram
ES| BPMN Collaboration diagram
BPMN Process diagram
CommunicationT diagram obsener
—
f| Dependency Diagram (automatic) N
Deployment diagram
Object diagram
/| Package Structure Diagram (automatic)
Sequence diagram
(2 State Machine diagram
ConcreteSubject — ConcreteObserver
/| Sub-Packages Structure Diagram (automatic)
- subjectState: string | — BC - cbsenerState- string
Use Case diagram
+ getState(): string | + update)
Class diagrams are the most commonly used diagrams in UML.

In analysis, they model the notions of a domain or those supported by a system, with their
relationships and properties,
Ín design/development, they model the constituants of a system, or technical classes
Vava, C5, ..) ordata (SQL data schemas, ..).
Show only applicable elements
Figura 5.54. Ventana que se muestra antes de proceder a la creación de un diagrama

en la que se selecciona el tipo de diagrama que se desea crear y se le da un nombre.
Tras clicar en el botón OK, aparecerá la pantalla principal de Modelio, donde se pueden
distinguir varias áreas:
E Explorador del modelo, en la parte izquierda, donde se muestran todos los elemen-
tos del diagrama por los que se puede navegar haciendo doble clic sobre cada uno
de ellos.
B Área de paletas, a continuación a la derecha, donde se muestran varias paletas

para seleccionar los elementos que se desean incorporar a los diagramas.
| i'/ 1OMUNICACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
E Área de edición, en la parte superior derecha de la pantalla, que es la zona reserva-

da para la creación de los diagramas.
M Área de detalles, en la parte inferior; en esta área, se muestran diversos tipos de in-
formación en función de la pestaña seleccionada. Así, si se hace clic sobre la pesta-
ha Properties, se muestran las propiedades del elemento seleccionado del diagrama;
si se hace clic sobre Diagrams, se muestra un desplegable con los diagramas del
proyecto.
Lo primero que se debe hacer es indicar que el paquete que se ha creado con el nombre
Videoclub es un elemento Java para posibilitar posteriormente la generación de código
Java a partir del diagrama de clases. A tal fin, seleccionado el paquete, en el área de de-
talles en la pestaña Properties, se marca la casilla de verificación Java element.
Para crear una clase en el diagrama, tan solo hay que pinchar sobre el icono — de la
paleta Class model y hacer clic en la posición deseada del área de edición. O bien en la
pestaña Properties, o bien seleccionando la opción del menú contextual de la clase Edit
element, se pueden ver y madificar las propiedades de la clase. En la pestaña Properties,
se le asigna a la clase el nombre Película. Para añadirle atributos a la clase, se pulsa sobre
el icono 4a: de la paleta Class Model y, luego, se clica sobre la clase. En la pestaña Proper-
ties del área de detalles, se puede asignar las propiedades necesarias al atributo: nombre,
tipo de dato y visibilidad. En la Figura 5.55, se muestran las propiedades para el atributo
código de la clase Película.
Type T | integer
Visibility Private
Multiplicity min 1
Multiplicity max 1
Value |
Access mode — Read/Write
Type constraint |
Abstract |
Class
Derived
Ordered
Unique
Target is class
Figura 5.55. Ventana en la que se visualizan y editan las propiedades de un atributo

en la pestaña Properties. En este caso, se muestran las propiedades del atributo código
de la clase Película.
De igual modo, se añaden el resto de atributos a la clase Película (título, añoProducción,

género, país y stock).
Para asignar métodos a una clase, se debe pulsar sobre el icono 00 de la paleta Class
Model y luego se hace clic sobre la clase. Se puede observar que al llevar a cabo esta
operación han aparecido automáticamente para la clase los métodos de selección (get)
y acceso (set) para todos sus atributos. Esto es así porque el módulo Java Designer que
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMATICA Y 0Í)) y
viene incorporado en Modelio tiene una propiedad por defecto que indica que se generen
estos métodos de manera automática para todas las clases. Si se quiere eliminar esta
posibilidad porque hace excesivamente densos los diagramas, se puede seleccionar la
opción de menú Configuration > Modules, hacer clic sobre el módulo Java Designer, y en
sus propiedades, que aparecen en la parte inferior de la ventana, asignar el valor Never
a la propiedad Accessor generation dentro del apartado Automation, como se muestra en
la Figura 5.56.
Project configuration
Project properties
Audit ] Informations
| Work models| Modules [ Libraries
| URLs ]
= Project's modules
Modules installed in the project.
Enable Scope Name Version Status — License Compatibility
User - E ModelerModule — 9200 Started Free — Compatible
User — $ JavaDesigner — 3000 Started Free — Compatible
Project's modules parameters

Select a module in the 'Project's modules'lit to edit its parameters.
Name
4 £ JavaDesigner
General
Directories
Code generation
“ Automation
Update classes implementing an interfac

Accessor generation
Visibility for getters generated from "Pul
Figura 5.56 Se puede indicar a Modelio que no cree automáticamente métodos de

consulta y acceso para todos los atributos de una clase modificando la propiedad
Accessor generation del módulo Java Designer al valor Never.
No obstante, también es posible eliminar cualquier atributo o método asignado a una cla-
se colocándose sobre él con el ratón y pulsando la tecla Supr o la opción del menú con-
textual Delete selection.
A la hora de asignar propiedades a un método u operación de una clase, por ejemplo, al

método CompararCódigo de la clase Película, se debe hacer clic sobre el nombre asignado
por defecto al método o elegir la opción del menú contextual Edit element. En la pestaña
Operation, se le asigna un nombre al método (CompararCódigo) y se indica su tipo (opera-
ción, constructor o destructor) y su visibilidad (public). Además, en la sección Operation
parameters, se indican los parámetros del método y su valor de retorno, si es el caso. El bo-
tón * sirve para añadir un parámetro al método, y el botón “, para indicar el valor de retor-
no del método. Con los iconos que aparecen a la derecha de la pantalla de la Figura 5.57,
se ofrece la posibilidad de eliminar un parámetro, ascenderlo en la lista de parámetros o

descenderlo, respectivamente. Se muestra a continuación toda la información para el mé-
todo CompararCódigo de la clase Película. Este método presenta un parámetro de entrada
CodPel de tipo integer y un valor de retorno de tipo boolean. Se puede observar el prototipo
0 la cabecera del método debajo de la lista de parámetros.
A Y COMUNICACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
Edition of Operation
Operation
Properties | Notes and constraints

| Audit | Java _|
| CompararCódigo
[Operation — | Visibilty |Public v ¡ [ Abstract [ Class [JFinal
Operation parameters
Name
ERE
Multiplicity — Passingmode — Value
47 retum 1
»P CodPel 1 n
<
00 + CompararCódigo
(CodPel in : integer): boolean
Description CIHTML
[KEnter note text here>
Figura 5.57. Ventana en la que se visualizan y modifican las propiedades de los métodos
de una clase al seleccionar el método correspondiente y la opción del menú contextual
Edit element. En la pestaña Operation, se debe asignar al método su nombre, tipo y
visibilidad, y se deben definir sus parámetros y valor de retorno, si procede.
Después, se crean del mismo modo los restantes métodos de la clase Película (dismi-
nuirStock, aumentarStock y getStock) y, a continuación, la clase Videoclub con sus dos
métodos AlquilarPelícula y DevolverPelícula.
Para crear relaciones entre clases, se debe clicar sobre el tipo de relación que nos inte-
resa en la paleta Class Model y luego en la clase origen y en la clase destino. En el caso
de la relación entre Videoclub y Película, se hará clic sobre el icono =— que se usa
para una asociación o relación genérica. A continuación, se deben modificar las propieda-
des de la asociación (nombre, navegabilidad y multiplicidades mínimas y máximas al lado
de cada clase), seleccionando la opción del menú contextual Edit element. En el caso de
esta relación, sus propiedades deberán quedar como se muestra en la Figura 5.58.
Edition
Association End
Properties | Notes
and constraints | Audit | Java _|
; be -
=— UML - AssociationEnd Property — | To: Película e
Fa Desioner ;Asmciat¡on name — <null> |
— Navigable a 1)
E Modeler Module — | |
Target <null> N Película
Association type Association - Association |
Multplicity min — 1 o -
Mu)tí6licity max TI hl hd
Visibility N/A Public |
ls changeable N/A IB
Accessors N/A Read/Wiite -
Abstract N/A m l
Figura 5.58. Ventana en la que se visualizan y modifican las propiedades de las relaciones establecidas
entre clases, seleccionando la relación correspondiente y la opción del menú contextual Edit element.
En la pestaña Properties se puede asignar un nombre a la relación, los roles, cambiar el tipo de asociación
e indicar las multiplicidades mínimas y máximas al lado de cada clase.
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMÁTICA
Y COM
Después, se crea el resto del diagrama de clases siguiendo los pasos que se han indicado.
Al final, se obtiene un diagrama de clases como el que se muestra en la Figura 5.59.
Ventana Videoclub
=+
+ AlquilarPelícula() 1 1 | + AlquilarPelícula(in NIF: string, in CodPel: integer): boolean
+ DevolverPelícula() + DevolverPelicula(in NIF: string, in CodPel: integer): boolean
1 1 1
Cliente =
— NIF.: string
Película E - nombre : string
s - dirección : string
- ] - teléfono : string
_sé1sv:'s:'? - email - string Q
- numSocio : string Alquiler
. si¡¡ngng
añoProducción - integer ANe - fecAlqui-ler date
- ae - fecDevPrevista - string
“St0eK rteger o _ ; : ++ getSan ción(): float - fecDereal : string
: as…mp…lmrstoc…ko in CodPel: integer): boolean setSanción(in importe: float) '<1 * Eac EA ale: stmmg) 00
Der -
+ aumentarStock + CompararNIF(in NIF: string): bool...
le + Alquiler(in NIF: string,
e in CodPel: integer) — CO
+ getSto
¡*_qe —
t$tock_0integer
1 = | + ComprobarSanción(): float
Figura 5.59. Diagrama de clases creado en Modelio que refleja la información que es necesario gestionar
en un videoclub.
E 5.7. Generación de código a partir de diagramas de clases

Una vez generado un diagrama de clases, se puede crear de manera automática el códi-
go en Java mediante el empleo de un generador de código.
Para poner esto en práctica, aquí se usará Modelio, partiendo del diagrama de clases de
la Figura 5.59. Esto se puede llevar a cabo gracias a que, al instalar Modelio, esta he-
rramienta incorpora un módulo llamado Java Designer, una de cuyas utilidades es la ge-
neración de código Java. Para ello, es necesario haber especificado que las clases del
diagrama, o bien el paquete que incluye todo el diagrama de clases, es un elemento
Java. A tal fin, se selecciona el paquete o la clase correspondiente, y en la pestaña Java
del área de detalles, se activa la casilla de verificación Java element.
Para generar el código Java correspondiente a una clase, se debe seleccionar dicha clase en
el explorador del modelo y elegir la opción del menú contextual Java Designer > Generate,
como se muestra para la clase Película en la Figura 5.60.
?¡: Model 53 =0 Bíagnm€hs&%dml¡;h Ea
EO 1O
"e 1
=:_ E Creste diagram...
4 E ProyectoVideoclu e Create element »
» E LocalModule E ModelerModule »
4 M Proyectovideon Java Designer D ME
a E pmyme E =
« E Videociu 4 Addstereoy [£ Update model from sourcesii necessany
> [ E ctetrntpe. E
Delete PÉ Cresteajava atribute property
— eº| » — Delete element
vm*1 PP Cresteajava association end property
E
b c|¡gu_%ñ Cut element Ctrl+X
Figura 5.60. En Modelio es posible generar el código Java correspondiente a una

clase activado la opción del menú contextual Java Designer > Generate.
| l íkOMUNICACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
Se habrá creado, en ese instante, un archivo con el codigo fuente Java correspon-
diente, llamado Pelicula.java. Este archivo se podrá encontrar en la carpeta src/
Videoclub de la carpeta dedicada al proyecto, creada por Modelio en el equipo. Se pue-
de visualizar el contenido de este archivo seleccionando para la clase la opción del menú
contextual Java Designer > Edit. En la Figura 5.61, se puede observar el código genera-
do para la clase Película, que debe ser revisado y modificado convenientemente. Como
se puede ver en el código, Modelio ha añadido alguna importación y anotaciones propias.
También es reseñable que ha creado un atributo de tipo lista para reflejar la navegabi-
lidad de la relación entre Película y Alquiler, es decir, para registrar todos los alquileres
que se han realizado para cada película.
DiagramaClasesVideoclub “% Película 2
package Videoclub;
import java.util.ArrayList;
import java.util.List;
import com.modeliosoft.modelio.javadesigner.annotations.objid;
Bobjid (*O
private int código;
private String título;

0864089- 1761
|;riv$te String género;
Dobjid (Ba25c2c8- 1c3e-4417-998

private Strir;g país;
Dobjid de2bceba- lef1-461b-97c0-2f253ed51fc0

private
int stock;
Dar — — —
Dobjid 83 212 7-4343-929d-b2d 128137c
public List<Alquiler> = new ArrayList<Alquiler> ;
- 333be3d4-3e77-48d0
public boolean CompararCódigo(int CodPel)
Figura 5.61. En Modelio se puede visualizar el código Java correspondiente a

una clase seleccionando la opción del menú contextual Java Designer > Edit.
Asimismo, existe la posibilidad de generar código para el paquete completo, seleccionán-

dolo desde el explorador del modelo y eligiendo la opción del menú contextual Java Desig-
ner > Generate. Se generará un archivo con el código fuente correspondiente para cada
clase del paquete en la carpeta src/Videoclub de la carpeta dedicada al proyecto, crea-
da por Modelio.
N 5.8. Generación de diagramas de clases a partir

de código (ingeniería inversa)
Es posible definir la ingeniería inversa como «el proceso llevado a cabo con el objetivo
de obtener información o un diseño a partir de un producto, con el fin de determinar cuá-
les son sus componentes y de qué manera interactúan entre sí y cuál fue el proceso de
5. ELABORACIÓN DE DIAGRAMAS DE CLASES |NFORMÁT|CA Y ( '
fabricación» (https://es.wikipedia.org/ wiki/ Ingeniería_inversa). Como se puede deducir,

este proceso no se aplica, por tanto, únicamente en el ámbito del software.
Argot técnico
Aplicada al software, la ingeniería inversa consiste en llevar a cabo las tareas de la
ingeniería del software en un sentido contrario al habitual. Teniendo en cuenta que las fases
del desarrollo más importantes de una aplicación informática son, en este orden, análisis,
diseño y programación, se trata de partir del resultado de la tarea de programación, o sea,
del código fuente, y obtener a partir de este la documentación que se debería haber obtenido
durante las fases de diseño y análisis.
Aquí, se aplicará la ingeniería inversa para obtener a partir de una aplicación escrita en
Java el diagrama de clases correspondiente. A tal efecto, se utilizará Modelio.
En primer lugar, se crea un proyecto en Modelio activando la casilla de verificación Java

project. En el explorador del modelo, se selecciona la carpeta creada para el proyecto y se
elige la opción del menú contextual Java Designer > Reverse > Reverse Java application
from sources (Figura 5.62). A continuación, se seleccionan los archivos con el código
fuente de las clases del proyecto para el que se desea aplicar ingeniería inversa. Para
ello, se emplearán los archivos que vienen dentro de la carpeta Geometria que se en-
cuentra disponible como material previo registro en www.paraninfo.es.
?:: Model 23W =a ]
€OT 1E
E*
- Create diagram...
4 í IngenieríalnversaGeometría e Create element »

í LocalModule
=£ an Designer l_ "EEr Generte
a e IngenieríalnversaGeomet
. Modeler Module » WE Update model from sources if necessary
& ingenieríainversageo!
» — El PredefinedTypes3.9.00 d REmie '| Generste the JavaDoc
% Creslt stere ¡;] Visualize the JavaDoc
¡ Create a compilation artifact

$ — Delete element Delete
x E Create a java component
Cut element Ctrl+X
Create/Update auto-diagrams
=| Copyelement Ctrl+C = — j
í Em Reverse » l& Reverse Java application from sources
º¡ Paste element Ctrl+V —
- 4y Configuration » £ Reverse Java binaries
Fal Editelement.
Figura 5.62. Para realizar ingeniería inversa a partir de archivos con código fuente de Java en Modelio, se debe
crear un proyecto Java y activar la opción del menú contextual Java Designer > Reverse > Reverser Java
application from sources.
En primer lugar, se pulsa en el botón = para acceder a la ubicación donde se encuen-

'—1 . ..
tran los archivos con el código fuente. Una vez seleccionada la carpeta, aparece una ven-
tana como la de la Figura 5.63, en la que se deben marcar las clases deseadas.
—. JX'. Y COMUNICACIONES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
Java Reverse
Choose the files to reverse (.java)
Files to reverse | Project's jars | Reverse's

jars
bemvmesnopxPamninfoxE_DxlngenieñalnversaX6eometn'a .
Content of C.AUsersVoselDesktop Paraninfo|EDIngenierialnversa|Geometría,
Círculo.java
[2¡ Cuadrado.java
[Z) Figurajava
% Punto java
[2! Rectángulo java
E] Triángulo java
Granularity
Complete
< Previous
Figura 5.63. Ventana en la que se seleccionan las clases para las que
se desea aplicar la ingeniería inversa.
En esta ventana, hay que pulsar la tecla Next y, también, en la siguiente, y finalmente la
tecla Reverse. Entonces, aparece un aviso indicando que el tipo String no es reconocido,
pero la ingeniería inversa se lleva a cabo y, de hecho, se muestran inmediatamente en el
explorador del modelo todas las clases incluidas en el paquete. A continuación, es posi-
ble desplegar cada clase y visualizar todos sus elementos (atributos, operaciones y rela-
ciones), como se puede observar en la Figura 5.64 para la clase Circulo.
a . ingenierfainversageometría
a ls a Figura (from geometria)

a: -radio: double
CO +Circulo(xin: double, y in: double,
00 +getRadio0: double
O +setRadio(radio in: double)

b 00 +area(): double
00 +perimetro(): double
Figura 5.64. En el explorador del modelo se muestran todas las clases

que se han creado a partir del código fuente. Estas se pueden desplegar
para visualizar sus elementos (atributos, operaciones y relaciones).
Luego, es necesario crear un diagrama de clases, para lo que se activa la opción del menú
contextual de la carpeta Create diagram, y se le asigna un nombre. El siguiente paso será
arrastrar, desde el explorador del modelo hasta el área de edición del diagrama, las clases
y los elementos de estas que se deseen (atributos, métodos y relaciones).
5. ELABORACIÓN DE DIAGRAMAS DE CLASES INFORMÁTICA Y (/O/X'1 1
Si se arrastran todas las clases con sus atributos y las relaciones existentes entre ellas,
se obtiene un diagrama de clases, como el de la Figura 5.65, en el que, no obstante, se
han modificado las cardinalidades para la asociación entre las clases Figura y Punto. Se
mostraban a ambos lados las cardinalidades 0..1, pero deben ser, por un lado, 1 al lado
de Punto porque toda figura tiene un punto como centro y, por otro lado, * al lado de Fi-
gura, porque un punto puede ser el centro de más de una figura.
Figura Punto
— - centro |
-color: <no type> ——> - x: double
u 1 | -y : double
- radio : double - base : double - lado1 : double

- altura : double - lado2 : double
- lado3 : double
z =
Cuadrado !
Figura 5.65. Diagrama de clases sin métodos resultado del proceso de ingeniería inversa en Modelio.
Se puede observar que, en el diagrama se ha establecido una relación entre Figura y Punto,
a la que se ha asignado el nombre centro, que es el nombre del atributo de la clase Pun-
to dentro de la clase Figura que indica el punto que constituye el centro de la figura. Ade-
más, la punta de flecha al lado de Punto indica que esta relación es navegable solo desde
Figura hasta Punto. Esto quiere decir que, dada una figura, es posible conocer el punto
que constituye su centro, pero dado un punto, no es posible conocer las figuras para las
cuales ese punto es su centro. Esto sería posible si en la clase Punto hubiese un atribu-
to de tipo lista con objetos de la clase Figura, pero esto no ocurre en este ejemplo, como
se puede observar en el código de la clase Punto.
Conceptos básicos de
la orientación a objetos
El lenguaje UML
Clases, atributos, métodos

y visibilidad
Elaboración de diagramas de clases
Relaciones entre clases
Tipos de clases de análisis J
Herramientas para la creación

Generación de código a partir

Generación de diagramas
(ingeniería inversa)
229
ACTIVIDADES FINALES 5. ELABORACIÓN DE DIAGRAMAS DE CLASES
5.1. ¿Cuál es la característica de un lenguaje de programación por la que es posible
definir varios métodos para la misma clase con el mismo nombre, pero diferen-
te número y/o tipo de parámetros y/o tipo de valor devuelto?
a) Polimorfismo.
b) Modularidad.
c) Encapsulamiento.
d) Ocultamiento.
5.2. ¿Cuál de las siguientes características no es imprescindible para que un

lenguaje de programación se pueda considerar orientado a objetos?
a) Herencia.
b) Abstracción.
c) Recolección de basura.
d) Polimorfismo.
5.3. La siguiente definición se corresponde con un componente estructural de UML,

¿de qué elemento se trata?
«Es un elemento físico que existe en tiempo de ejecución y representa un recurso
computacional que, por lo general, dispone de algo de memoria y, con frecuencia,
capacidad de procesamiento».
a) Nodo.
b) Artefacto.
c) Componente.
d) Caso de uso.
5.4. Un diagrama de secuencia es un diagrama de:

a) Interacción.
b) Comportamiento.
c) Estructural.
d) Las repuestas a y b son correctas.
5.5. ¿Qué diagramas muestran la funcionalidad del software desde el punto de vista
del usuario?
a) Diagramas de casos de uso.
b) Diagramas de clases.
c) Diagramas de actividades.
d) Diagramas de componentes.
5.6. Si a la hora de definir una clase, se quiere que sus atributos sean accesibles
desde la propia clase y sus subclases, se tendrá que asignar a los atributos el
modificador de acceso:
a) Public.
b) Protected.
c) Private.
230 d) Package.
5.7. La propiedad por la cual una subclase tiene, además de sus atributos y métodos
propios, los atributos y métodos de su superclase, recibe el nombre de:
a) Jerarquía.
b) Herencia.
c) Especialización.
d) Generalización.
5.8. El tipo de relación entre una clase de tipo compuesto y una clase componen-
te tal que el tiempo de vida de los componentes tiene que coincidir con el del
compuesto, recibe el nombre de:
a) Asociación.
b) Agregación.
c) Composición.
d) Generalización.
5.9. ¿Es posible en un diagrama de clases UML reflejar información que en lugar de
ser propia de una clase pertenezca a una asociación entre clases?
a) No, noes posible.
b) Sí, sí es posible y esto se puede llevar a cabo simplemente asignando atributos a
la relación.
C) Sí, sí es posible y esto se puede llevar a cabo creando una clase asociativa vincu-
lada a la relación, de manera que esta clase contenga los atributos propios de la
relación.
5.10. El proceso de obtener un diagrama de clases a partir del código fuente recibe el
nombre de:
a) Ingeniería.
b) Reingeniería.
c) Ingeniería inversa.
d) Ingeniería invertida.
5.11. ¿Cuál es la diferencia entre los diagramas de clases y los diagramas de objetos?
5.12. ¿Para qué se usan los diagramas de casos de uso? ¿De qué elementos consta un
diagrama de casos de uso?
5.13. ¿En qué consiste la visibilidad de un atributo o de un método? ¿Qué valores puede
tomar la visibilidad de un atributo o de un método?
5.14. ¿Cómo se representan en un diagrama de clases las relaciones de grado mayor que
2 (ternarias, cuaternarias, etc.)? ¿Pueden tener estas relaciones atributos asociados?
En caso afirmativo, ¿cómo se representa esta información? 231
5.15. ¿A qué se refieren los conceptos de generalización y especialización?
5.16. ¿Cómo se deben interpretar las multiplicidades o cardinalidades en las relaciones de

los siguientes diagramas de clases?
Profesor
esCapitalDe
Asignatura
Figura 5.66. Diagrama de clases que refleja, por un lado, la ciudad capital de cada país, y por otro,
las asignaturas que imparte cada profesor y el grupo al que imparte cada asignatura.
5.17. ¿Por qué en el siguiente diagrama de clases la línea que una la relación vende con
la clase Venta esta dibujada con un trazado discontinuo? ¿Qué información propor-
cionan los atributos stock y precio de la clase Venta? ¿Por qué se ha creado la clase
Venta?
Supermercado
- código: String Artículo
- nombre: String 1.7 ver|1de 1- - código: String

- dirección: String i - descripción: String
- teléfono: String Venta
- stock: int
- precio: float
Figura 5.67. Diagrama de clases que refleja los artículos que vende cada supermercado.
5.18. ¿Qué tipos de clases de análisis se pueden identificar en una aplicación? ¿Para qué
se usa cada uno de estos tipos de clases?
5.19. Realiza un diagrama de clases sin métodos para una empresa dedicada al alquiler de
automóviles, teniendo en cuenta los siguientes requisitos:
E Un determinado cliente puede tener, en un momento dado, varias reservas hechas.

E De cada cliente, se desea almacenar su DNI, nombre, dirección y teléfono. Ade-

más, los clientes se diferencian por un código único.
E Cada cliente puede ser avalado por otro cliente de la empresa. Un cliente puede
avalar a varios.
5. ELABORACIÓN DE DIAGRAMAS DE CLASES ACTIVIDADES FINALES
E Una reserva la realiza un único cliente, pero puede involucrar varios coches.
E Es importante registrar la fecha de inicio y fin de la reserva, el precio de alquiler

de cada uno de los coches, los litros de gasolina en el momento de realizar la re-
serva, el precio total de la reserva y un indicador que informe acerca de si cada
coche ha sido entregado o no.
E Todo coche tiene siempre asignado un determinado garaje. De cada coche, se re-
quiere registrar su matrícula, modelo, color y marca.
E Cada eserva se realiza en una determinada agencia. De cada agencia, se requie-
re registrar su nombre y dirección.
E Sobre cada garaje, es necesario conocer su código único, ubicación y capacidad
o número máximo de coches que caben en el garaje.
5.20. Elabora un diagrama de clases sin métodos para un sistema de monitorización de

sensores, teniendo en cuenta los siguientes requisitos:
E El sistema monitoriza sensores y también informa sobre posibles problemas.
E Cada sensor lo describe su fabricante y número de modelo, secuencia de inicia-

ción (que se envía al sensor para iniciarlo), factor de escala y unidad de medida,
intervalo de muestreo, ubicación, estado (encendido, apagado, en reserva), valor
actual y umbral de alarma. Hay un tipo especial de sensores, que son los senso-
res críticos. Estos tienen una característica adicional, que es su tolerancia del in-
tervalo de muestreo.
E Los sensores están instalados en edificios. El sistema hace un seguimiento de los

sensores de cada edificio. De cada edificio, se conoce su dirección y el número
de contacto en caso de emergencia.
E El sistema activa determinados dispositivos de alarma siempre que se supera el
umbral de un sensor. Los dispositivos de alarma tienen dos características de las
cuales depende su funcionamiento: el estado del dispositivo y la duración de la
señal de alarma.
E El sistema registra información de la fecha, hora, gravedad, tiempo de reparación

y estado de cada suceso de alarma.
5.21. Realiza un diagrama de clases sin métodos para una entidad bancaria, de la que es
necesario saber su CIF, nombre y dirección. Tras una entrevista se ha obtenido la si-
guiente información:
E Listado de sucursales: código de la sucursal, dirección y teléfono.
E Listado de cuentas corrientes: número de la cuenta, saldo y, además, NIF, nombre

y apellidos y dirección de las personas que pueden utilizar esa cuenta.
Listado de operaciones realizables: código de la operación y descripción.

Listado de recibos domiciliados: número de recibo, número de cuenta de pago,

importe del recibo, entidad emisora (empresa que emite el recibo) y fecha.
Las reglas que regulan este sistema son las siguientes:
E El banco tiene muchas sucursales. 233

Cada sucursal tiene una serie de cuentas corrientes.
Cada cuenta corriente tiene asociados uno o más clientes. Sin embargo, es posi-
ble que varios clientes con la misma cuenta (por ejemplo, personas de la misma
familia: padres e hijos menores) no puedan realizar las mismas operaciones.
Cada cliente puede tener varias cuentas. En cada una de ellas puede realizar ope-
raciones distintas.
Cada cuenta puede o no tener uno o varios recibos domiciliados.
5.22. Elabora un diagrama de clases sin métodos para una empresa que pertenece a un
grupo nacional de agencias que se dedican a la venta al por mayor, de acuerdo con
las siguientes especificaciones:
Los clientes de la empresa pueden ser mayoristas, minoristas e, incluso, clientes
del propio grupo de empresas. Acerca de todos los clientes, se debe conocer su
NIF, nombre y apellidos, dirección y teléfono. Además, para los mayoristas se ne-
cesita saber el almacén y el número de tarjeta bancaria. En el caso de los mino-
ristas, interesa el número de cuenta bancaria; y en el caso de clientes del propio
grupo, la actividad a la que se dedican.
Cuando un cliente hace un pedido, al que se asigna un número y del que se re-
gistra asimismo su fecha, se genera un documento con la relación de los artículos
solicitados. De cada artículo se precisa saber su código, nombre, precio, existen-
cias actuales y el número mínimo y máximo de existencias recomendables, así
como el número de unidades de ese artículo solicitadas en el pedido. Cada ar-
tículo lleva asociado un tipo de IVA, que puede ser del 4, del 10 o del 21 %. Por
otra parte, algunos artículos tienen asociado un envase, del que se desea alma-
cenar su código, descripción y precio.
El pedido puede ser modificado como consecuencia de devoluciones, siniestros,
cambios de última hora en el criterio del cliente, etcétera.
Al final de cada mes, la empresa pone en marcha el proceso de facturación que
consiste en crear una factura por cada cliente, en la que se incluyen los pedidos
correspondientes a ese mes. Las facturas se numeran y llevan una fecha asociada.
En los pedidos intervienen los llamados vendedores o comisionistas, que son em-
pleados de la empresa cuyo propósito es promocionar y vender los artículos. En
cada pedido interviene un solo comisionista. Al final de cada mes, reciben sus li-
quidaciones correspondientes. Cada vendedor-comisionista tiene un porcentaje
sobre el total de sus ventas y una determinada antiguiedad. Aparte de estos da-
tos, se precisa registrar su NIF, nombre y apellidos, teléfono y NSS (número de
Seguridad Social). Se considera venta solamente si se ha facturado.
234
5. ELABORACIÓN DE DIAGRAMAS DE CLASES ACTIVIDADES FINALES
A la hora de representar una asociación entre clases, además de asignar un nom-

bre a la relación, se pueden escribir roles sobre la línea que representa la relación y al
lado de cada una de las clases. Busca información sobre los roles y responde a las
siguientes preguntas: ¿para qué se usan los roles?, ¿en qué tipos de relaciones se
suelen especificar con más frecuencia?
5.24. Además de los tipos de relaciones entre clases que se han estudiado en el Apartado 5.4
de esta unidad, en un diagrama de clases, se pueden reflejar relaciones de depen-
dencia entre clases. Busca información sobre este tipo de relaciones y responde a
las siguientes preguntas: ¿qué significado tienen las relaciones de dependencia entre
clases?, ¿cómo se representan?
5.25. Encuentra información sobre la restricción xor en un diagrama de clases y contesta a

las siguientes preguntas: ¿para qué sirve esta restricción?, ¿cómo se representa?
5.26. Busca también información sobre la restricción subset en un diagrama de clases.

¿Con qué fin se emplea esta restricción? Indica cómo se representa.
5.27. Averigua en qué consiste la restricción ordered en un diagrama de clases. ¿Para qué
se emplea? Describe cómo se representa.
5.28. Busca información sobre los tipos de relaciones de generalización y especialización.

¿Qué diferencia a una generalización disjunta de una solapada? ¿En qué se diferen-
cia una generalización total de una parcial?

E [a)dA(m] DiagramasUML - https://diagramasuml.com/
7 (Tutorial sobre diagramas UML con numerosos ejemplos)
[
E (m]i2:(m] UML-diagrams.org - https://www.uml-diagrams.org/
5ñ (Sitio web en inglés con información sobre todos los diagramas UML)
el .
Diagrams.net - https://www.diagrams.net/
(Sitio web sobre la herramienta de modelado de código abierto app.diagrams.net)
Modelio - https://www.modelio.org/
(Sitio web sobre la herramienta de modelado UML de código abierto Modelio)
235
O
Q
<
Q
_
—
dentificar los tipos de diagramas de E 6.1. Diagramas de comportamiento

comportamiento que se pueden construir en UML.
E 6.2. Diagramas de casos de uso
nterpretar y elaborar diagramas de casos de uso.
El 6.3. Diagramas de interacción
nterpretar diagramas de interacción.
El 6.4. Diagramas de estados
Elaborar diagramas de interacción sencillos.
E 6.5. Diagramas de actividades
nterpretar diagramas de estados.
Diseñar diagramas de estados sencillos.
nterpretar diagramas de actividades.
Elaborar diagramas de actividades sencillos.
LA
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO INFORMAT¡CA Y l*_,“—. AN
Introducción
En la Unidad 5, se vio que el lenguaje UML se utiliza para elaborar diferentes tipos de
diagramas que son necesarios para realizar las tareas de análisis y diseño de una apli-
cación informática. Entre ellos, se estudiaron en detalle los diagramas de clases, los
cuales son diagramas estructurales que se usan para representar la parte estática del
sistema. Paralelamente, esta unidad se dedicará a los diagramas de comportamiento, es
decir, aquellos que reflejan la parte dinámica del sistema.
En primer lugar, se presentan los diagramas de casos de uso, que son fundamentales en
todo el proceso de desarrollo del software y reflejan las funciones encomendadas al sis-
tema desde el punto de vista de quienes utilizan la aplicación. Después, se caracterizan
los diagramas de interacción (diagramas de secuencia y de colaboración), cuya función
es informar con detalle sobre el comportamiento de cada caso de uso. Por último, se
estudian los diagramas de estados y los de actividades.
E 6.1.Diagramas de comportamiento
Los diagramas de comportamiento UML sirven para visualizar, especificar, construir y do-
cumentar los aspectos dinámicos de un sistema. La Tabla 6.1 recoge los siete tipos de
diagramas de comportamiento disponibles y la utilidad de cada uno de ellos.
Tabla 6.1. Tipos de diagramas de comportamiento que se pueden construir en lenguaje UML
y su uso
Diagrama Uso
Diagramas de casos de uso Describen las funcionalidades del sistema desde el punto de
: : vista de la persona usuaria. Son fundamentales, pues se usan :
: como punto de partida para los demás diagramas. :
: Diagramas de actividades : Se emplean para especificar paso a paso una operación com- :
: : pleja. Sirven para modelar el flujo de un caso de uso o entre :
: casos de uso. E
Diagramas de estados Sirven para modelar el comportamiento de un objeto dirigido

: por eventos que provocan cambios de estado o transiciones.
: Diagramas de secuencia * Muestran la secuencia cronológica de mensajes entre objetos :

: : durante un escenario de un caso de uso. º
: Diagramas de colaboración “ Muestran un conjunto de objetos, los enlaces entre ellos y los
: : mensajes que se reciben y se envían entre ellos. :
: Diagramas de tiempos : Representan el comportamiento de distintos objetos en un de- i

= : terminado periodo de tiempo. º
: Diagrama global de interacciones — : Aportan una visión general de la interacción en el sistema.
]MUN'CACIONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
A lo largo de esta unidad, se estudiarán los diagramas de comportamiento de mayor

relevancia en la construcción de un sistema.
E 6.2. Diagramas de casos de uso

Los diagramas de casos de uso son fundamentales en el proceso de desarrollo de software
orientado a objetos. De hecho, una de las características más importantes de la metodo-
logía RUP (proceso unificado de Rational), descrita en el Apartado 1.9.1, es que el proceso
RUP está dirigido por los casos de uso. Así, durante la tarea de análisis, la captura de los
requisitos se realiza a través de los diagramas de casos de uso, y se descubren y definen
clases a medida que se leen las descripciones de los casos de uso. Durante las tareas de
diseño y programación, quienes desarrollan el software crean modelos para dar respuesta
a los requisitos incluidos en los diagramas de casos de uso. Finalmente, en la tarea de
pruebas se garantiza que la aplicación implementa correctamente los casos de uso.
Se puede afirmar que los casos de uso sirven de guía en un conjunto de actividades de
desarrollo:
m Creación y validación de la arquitectura del sistema.
E Definición de procedimientos y casos de prueba.
E Planificación de iteraciones.
E Generación de la documentación de usuario.
E Despliegue del sistema.
Una característica muy relevante de los casos de uso es que proporcionan trazabilidad
al sistema, esto es, por medio de ellos, se puede determinar qué parte del sistema se
ha creado a partir de cada caso de uso: qué parte del diagrama de clases, qué parte del
programa, qué casos de prueba, etc. De esta manera, se puede detectar al realizar un
cambio en un caso de uso, qué clases y componentes es necesario modificar.
Los principales elementos de estos diagramas son dos:
1. Los casos de uso describen, bajo la forma de acciones y reacciones, el comporta-

miento de un sistema desde la perspectiva de la persona que lo usa. Son descrip-
ciones de la funcionalidad del sistema independientes de su arquitectura. Como se
señaló en el Apartado 5.2.1, los casos de uso se representan mediante una elipse
con borde continuo. En el interior de la elipse o a su lado, se debe escribir el nom-
bre del caso de uso.
2. Los actores se determinan observando las personas usuarias directas del sis-
tema, las personas responsables del uso o mantenimiento del sistema y otros
sistemas que interactúan con el sistema en cuestión. Hay que tener en cuenta
que una misma persona puede desempeñar varios papeles distintos y, por lo tan-
to, se representaría por medio de distintos actores. Cada actor lleva asociado un
nombre que describe el papel que desempeña. Los actores se representan como
se muestra en la Figura 6.1, escribiéndose el nombre del actor en la parte inferior.
LA
/ FAN
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO INFORMATICA Y (r '
Usuario
Figura 6.1. Símbolo que representa a un actor en un diagrama

de casos de uso con su nombre debajo.
Un diagrama de casos de uso para una aplicación ofrece un panorama de todos los ca-
sos de uso y sus relaciones. Por lo tanto, en él, se representa toda la funcionalidad que
proporciona el sistema. Todos los casos de uso se colocan en el interior de un recuadro
que representa al sistema que se está construyendo, de manera que los actores quedan
fuera de este recuadro, pues se encuentran fuera del sistema.
Entre los elementos integrantes de un diagrama de casos de uso (casos de uso y acto-
res) se pueden establecer varios tipos de relaciones:
E Relación de comunicación: este tipo de relaciones se usa para indicar qué actor o
actores intervienen en cada caso de uso. Se representa mediante una línea que
une el actor con el caso de uso.
E Relación de uso o inclusión: se crea este tipo de relación cuando se dispone de va-
rios casos de uso con una serie de actividades comunes. En estos casos, se crea
un caso de uso que incluye la actividad o actividades duplicadas y, luego, se indica
que los otros casos de uso incluyen o hacen uso de este nuevo caso de uso que se
crea. Esta relación de inclusión se representa mediante una línea con trazado dis-
continuo y una punta de flecha hacia el caso de uso con la actividad o actividades
duplicadas. Esta línea lleva la leyenda o el estereotipo «include».
E Relación de extensión: este tipo de relación se emplea cuando un caso de uso ori-
gen (A) amplía o extiende la funcionalidad del caso de uso destino (B), es decir, in-
cluye algunos pasos adicionales con respecto al caso de uso destino. Esta relación
se representa mediante una línea con trazado discontinuo y una punta de flecha ha-
cia el caso de uso destino. Esta línea lleva la leyenda o el estereotipo «extend». El
caso de uso A no es imprescindible que ocurra y, cuando ocurre, realiza funciones
adicionales a las del caso de uso B.
A modo de ejemplo, en una entidad bancaria en la que los clientes pueden realizar di-
ferentes operaciones con sus cuentas, como transferencias, ingresos y extracciones de
dinero, se dispondría de tres casos de uso correspondientes a esas tres funcionalidades
(transferencia, ingreso y extracción). Para poder realizar las operaciones de transferencia
y extracción, los clientes se tienen que identificar. Por lo tanto, se podría crear un caso
de uso que incluyera esa parte común a esos dos casos de uso, que se puede llamar
identificación. En el caso de las transferencias, también se pueden realizar por internet,
por lo que habría que crear el caso de uso transferencia por internet, que incluiría algu-
nos pasos adicionales con respecto al caso de uso transferencia. El diagrama de casos
de uso quedaría como el que se muestra en la Figura 6.2.
T/ £OMUNICACIONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
Sistema bancario )
Transferencia
por internet
Transferencia
Cliente Identificación
- -- <<include>>
Figura 6.2. Diagrama de casos de uso para un sistema bancario en el que las y los
clientes pueden realizar ingresos, extracciones o transferencias de dinero.
Un caso de uso debe ser simple, inteligible, claro y conciso. Lo habitual es que haya
pocos actores asociados a cada caso de uso. Hay una serie de preguntas clave que es
preciso plantearse al crear un diagrama de casos de uso:
E ¿Cuáles son las tareas del actor?
E ¿Qué información crea, guarda, modifica, destruye o lee el actor?
E ¿Debe el actor notificar al sistema los cambios externos?
E ¿Debe el sistema notificar al actor los cambios internos?
Además de obtener el diagrama de casos de uso para una aplicación, es necesario des-
cribir para cada caso de uso lo siguiente:
E Los actores involucrados.
E La precondición, es decir, el estado inicial del que parte el caso de uso.
E El flujo básico, es decir, el flujo de eventos ordenados por los que pasa el caso de
uso.
E Los caminos alternativos, es decir, las posibles desviaciones con respecto al flujo
básico.
E La poscondición, esto es, el estado final al que llega el caso de uso.
Los casos de uso permiten comprobar la verificación y validación del sistema. En cuanto al
primer aspecto (verificación), permiten determinar que el sistema se ha desarrollado correc-

tamente, es decir, que las tareas se llevan a cabo de manera adecuada. En lo que respecta
a la validación, permiten comprobar si el sistema es realmente el que la persona usuaria
desea. O dicho de otro modo, la validación consiste en determinar si el sistema hace lo que
quiere la persona que lo va a utilizar, mientras que la verificación consiste en determinar
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO 'NFORMATH:,/(XV » N
si lo que hace el sistema lo hace bien, es decir, si lo hace como la persona usuaria quiere
que se haga.
El modelo de casos de uso consta de un diagrama de casos de uso y la descripción de

todos los casos de uso. Cuando se termina de elaborar el modelo, se presenta a las per-
sonas que van a usar la aplicación y a los clientes para que lo validen, es decir, para que
determinen si cubre sus necesidades y si les ofrece la funcionalidad deseada.
Diagrama de casos de uso y descripciones de los casos de uso

Se desea crear un programa con una agenda de antiguos compañeros y compañeras de
estudios con los que se suele realizar una cena anual para mantener la amistad. Por
cada una y uno de ellos, se desea registrar en la agenda su nombre completo (nombre y
dos apellidos), número de teléfono y correo electrónico. No puede haber dos excompañe-
ros o dos excompañeras con el mismo nombre.
Las operaciones que deberá realizar la aplicación son las que se indican a continuación:
Agregar excompañero/a: para esta operación, se deberán suministrar todos los da-
tos indicados anteriormente.
Consultar datos de un/a excompañero/a: se proporciona su nombre completo y se

mostrarán su número de teléfono y correo electrónico.
Agregar cena: para esta operación, se deberá suministrar la fecha de la cena, el

lugar en el que se va a celebrar y el nombre de la persona que la organiza.
Eliminar cena: para esta, se deberá suministrar el año de la cena que se desea
eliminar.
Consultar cena: se suministrará el año de la cena y se mostrarán sus datos (fecha,

lugar y nombre del organizador).
Agregar asistente: para esta operación, es necesario indicar el año de la cena y el

nombre del nuevo asistente.
Eliminar asistente: para esta, habrá que suministrar el año de la cena y el nombre
del asistente que al final no va a acudir a la cena.
Consultar asistentes: se deberá indicar el año de la cena y se mostrarán los nom-

bres de los asistentes a esta.
Asimismo, deben tenerse en cuenta las siguientes restricciones:
No puede haber dos excompañeros o excompañeras con el mismo nombre comple-

to (nombre y dos apellidos), por lo que antes de agregar una persona, se deberá
comprobar que no están ya almacenados sus datos.
No puede haber dos cenas el mismo año. Se deberá realizar la comprobación perti-
nente a la hora de agregar una cena.
La persona encargada de organizar una cena debe ser una previamente agregada al
programa. Esto se deberá comprobar al agregar una nueva cena.
Todos los asistentes a las cenas deben ser antiguos compañeros y compañeras ya
agregados al programa. Esto se deberá comprobar al agregar un nuevo asistente.
IMUNICACIONES
! .K…—“ Á ! E 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
A continuación, se detallan cada uno de los casos de uso considerando las restricciones
indicadas:
Agregar excompañero/a: en este caso de uso, se solicita al usuario o usuaria la

introducción del nombre completo, número de teléfono y correo electrónico del ex-
compañero o excompañera. En caso de que haya uno o una con ese mismo nombre,
se muestra un mensaje de error; en caso contrario, se añade el antiguo compañero
o compañera.
Consultar excompañero/a: se solicita a la persona usuaria la introducción del nom-

bre completo del excompañero o excompañera cuyos datos se desean ver. En caso
de que no haya ninguno o ninguna con ese nombre, se muestra un mensaje de
error; en caso contrario, se muestran el número de teléfono y el correo electrónico
del antiguo compañero o compañera.
Agregar cena: se solicita la fecha de la cena. Si ya hay cena ese año, se mostrará
un mensaje de error; si no la hubiera, la aplicación pedirá al usuario que ingrese el
lugar de la cena y el nombre de la persona que la organiza. Si el nombre de esta no
se corresponde con el de un excompañero o excompañera existente, aparecerá un
mensaje de error; en el caso contrario, se guardan los datos de la cena.
Eliminar cena: se pide el año de la cena que se desea eliminar. Si no hubiera una
cena ese año, se mostrará un mensaje de error; en caso contrario, se eliminará
la cena.
Consultar cena: para este caso de uso, se solicita el año de la cena. En caso de que
no haya ninguna cena ese año, aparecerá un mensaje de error; en caso contrario,
se mostrarán la fecha de la cena, el lugar donde se realizará y el nombre de la per-
sona organizadora.
Agregar asistente: se pide que se indique el año de la cena. Si no hay cena en ese
año, se mostrará un mensaje de error; en el caso contrario, se preguntará el nom-
bre del nuevo asistente a la cena. En caso de que el nombre del asistente no coin-
cida con alguno de las y los excompañeros agregados, saldrá un mensaje de error.
En caso de que ya esté anotado ese asistente para la cena, se indicará mediante
un mensaje; en caso contrario, se añadirá dicho asistente a la cena.
Eliminar asistente: de nuevo, se solicitará el año de la cena. Si ese año no hay

ninguna cena, aparecerá un mensaje de error; y, en caso contrario, se solicitará el
nombre del asistente a la cena. Si esa persona no figura como asistente a la cena,
se mostrará el pertinente mensaje de error; en el caso de que sí figure como asis-
tente, se eliminará ese asistente de la cena.
Consultar asistentes: en este caso de uso, se pide el año de la cena. En caso de

que no haya ninguna cena ese año, se mostrará el correspondiente mensaje de
error, y en caso contrario, por cada uno de los asistentes a la cena, se mostrará su
nombre.
Se pide realizar el diagrama de casos de uso y la descripción de los casos de uso

Agregar excompañero/a, Consultar excompañero/a, Agregar cena, Eliminar cena y Agregar
asistente.
Solución
En la Figura 6.3, se muestra el modelo de casos de uso de la aplicación.

6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO INFORMATICA Y (L —' '
Agenda
excompañeros/as
Agregar
excompañero/a
Consultar
excompañero/a
Agregar
cena
Eliminar
cena
Consultar
N cena
Usuario
Agregar
asistente
Eliminar
asistente
Consultar
asistentes
Figura 6.3. Diagrama de casos de uso para un sistema en el que se desean

almacenar datos de antiguos compañeros y compañeras con los que
se celebran cenas anualmente.
La descripción de los casos de uso solicitados sería como se expone a continuación.
M ENEN Caso de uso Agregar excompañero/a

El Actores involucrados: persona usuaria.
El Precondición: la agenda tiene que estar creada.

El Flujo básico:
1. La persona usuaria solicita agregar un nuevo excompañero o excompañera.

2 Se pide a la persona usuaria de la aplicación la introducción del nombre comple-
to, teléfono y correo electrónico del nuevo excompañero o excompañera.
Tras la introducción de los datos, el sistema comprueba que no haya una perso-
na con el mismo nombre y, si es así, lo añade a la agenda y muestra un mensa-
je de confirmación en pantalla.
Se vuelve a solicitar al usuario o usuaria la selección de una operación.
COMUNCACIONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
E Caminos alternativos:
Si en el paso 3 se detecta que ya existe un excompañero o excompañera con

ese nombre, se muestra un mensaje que el usuario debe aceptar y se pasa al
paso 4 anterior.
El Poscondición: la agenda dispone de un excompañero o excompañera más o del

mismo de número de antiguas y antiguos compañeros si la persona ya estaba en la
agenda.
M ENEN Caso de uso Consultar excompañero/a

El Precondición: la agenda tiene que estar creada y deben existir excompañeras o ex-
compañeros agregados.
El Flujo básico:
dl El usuario o usuaria solicita consultar los datos de un antiguo compañero o
compañera.
Se pide a la persona usuaria la introducción del nombre completo del excompa-

ñero o excompañera (nombre y apellidos) que se busca.
El sistema comprueba si hay alguna persona con ese nombre y muestra sus
datos: teléfono y correo electrónico.
4. Se vuelve a solicitar a la persona usuaria la selección de una operación.
El Caminos alternativos:
Si en el paso 3 anterior se detecta que no existe ninguna persona con ese nom-
bre, se muestra un mensaje que el usuario o usuaria debe aceptar y se pasa al
paso 4.
El Poscondición: el estado del sistema no cambia.
M ENEN Caso de uso Agregar cena

El Precondición: la agenda tiene que estar creada y debe existir algún excompañero
agregado o excompañera agregada.
Flujo básico:
de El usuario o la usuaria solicita introducir una nueva cena.
2 Se pide a la persona usuaria la introducción de la fecha y el lugar de la cena.
El sistema comprueba que no haya ninguna cena ese mismo año.
Se pide a la persona usuaria la introducción del nombre de la persona organiza-
dora de la cena.
El sistema comprueba que haya alguna persona con el nombre del organizador
de la cena y si la hay, se añaden los datos de la cena y se muestra un mensaje
de confirmación en la pantalla.
Se vuelve a solicitar al usuario o usuaria que seleccione una operación.

4
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO INFORMAT¡CA Y (L
E Caminos alternativos:
— Sienel paso 3 se detecta que ya existe una cena ese año, se muestra un men-
saje que el usuario o usuaria debe aceptar y se pasa al paso 6.
— Sienel paso 5 se detecta que no existe ninguna persona con el nombre de

la persona organizadora, se muestra un mensaje que la persona usuaria debe
aceptary se pasa al paso 6.
E Poscondición: la agenda dispone de una cena más o del mismo de número de cenas
si esta no se ha podido añadir.
M ENEN Caso de uso Eliminar cena

El Precondición: la agenda tiene que estar creada y deben existir cenas.

El Flujo básico:
1. La persona usuaria solicita eliminar una cena.
2. Se pide al usuario o usuaria la introducción del año de la cena que se desea

eliminar.
3. El sistema comprueba que haya una cena ese año y, si es así, se elimina la
cena y se muestra un mensaje de confirmación en la pantalla.
4. Se vuelve a solicitar al usuario o usuaria la selección de una operación.
— Sienel paso 3 se detecta que no existe ninguna cena ese año, se muestra un
mensaje que el usuario o usuaria debe aceptar y se pasa al paso 4.
El Poscondición: la agenda dispone de una cena menos o del mismo de número de

cenas si esta no se ha podido eliminar.
M ENEN Caso de uso Agregar asistente

El Precondición: la agenda tiene que estar creada y deben existir cenas y excompañe-
ras y excompañeros agregados.
El Flujo básico:
1. El usuario o usuaria solicita agregar un asistente a una cena.
2. Se pide al usuario o usuaria la introducción del año de la cena.
3. El sistema comprueba que haya una cena ese año.

4 Se solicita entonces a la persona usuaria la introducción del nombre de un ex-
compañero o una excompañera.

El sistema comprueba que haya alguna persona con ese nombre.
a
El sistema comprueba que esa persona no figure ya entre los asistentes a la cena. >
D
! lf' *OMUN'CACIONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
7. El sistema añade al excompañero o excompañera como asistente a la cena y

muestra un mensaje de confirmación.
8. Se vuelve a solicitar a la persona usuaria la selección de una operación.
— Sienel paso 3 se detecta que no existe ninguna cena ese año, se muestra un
mensaje que la persona usuaria debe aceptar y se pasa al paso 8.
— Sienel paso 5 se detecta que no existe ninguna persona con ese nombre, se
muestra un mensaje que el usuario o usuaria debe aceptar y se pasa al paso 8.
— Sienel paso 6 se detecta que esa persona ya figura entre los asistentes a la
cena, se muestra un mensaje que el usuario o usuaria debe aceptar y se pasa
al paso 8.
El Poscondición: en la cena indicada figura un asistente más o los mismos en caso de

que no se haya podido añadir un asistente a la cena.

Descripciones de casos de uso
A partir de la Actividad resuelta 6.1, proporciona la descripción de los casos de uso Con-
sultar cena, Eliminar asistente y Consultar asistentes.
ME 6.2.1.Herramientas para la elaboración de diagramas de casos de uso

En este apartado, se verá cómo se crean los diagramas de casos de uso mediante la
herramienta diagrams.net y el módulo Papyrus SysML de Eclipse.
M ENEN Elaboración de diagramas de casos de uso con diagrams.net

Cabe recordar aquí lo que se aprendió en el Apartado 5.6.1. En dicho apartado, se expli-
có cómo se generan diagramas de clases con la herramienta diagrams.net, a la que se
puede acceder a través de la página web https://app.diagrams.net/.
Una vez dentro de la aplicación, tras indicar que se desea crear un nuevo diagrama y la
ubicación donde se quiere almacenar, aparece una pantalla como la de la Figura 5.34.
A modo de ilustración, aquí se creará el diagrama de casos de uso para el sistema

bancario de la Figura 6.2. En la Tabla 6.2 se muestran los elementos de las paletas de
diagrams.net que se pueden utilizar en un diagrama.
Para crear un caso de uso, hay que hacer clic con el botón izquierdo del ratón sobre el
icono correspondiente a un caso de uso en la paleta UML. Ese icono aparece entonces
en el área de edición y se puede escribir en él su nombre. Para los actores, se debe ha-
cer clic sobre el icono del actor y asignarle su nombre.
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO INFORMATICA Y CO/X
Tabla 6.2. Elementos que forman parte de los diagramas de casos de uso con su icono y paleta
correspondiente en diagrams.net
Elemento
1 Caso de uso º UML

Use Case
: Actor Í UML
: E Actor
* Relación de comunicación Association / Connector / UML 2.5

: : Instance Specification / PI'OD€IÍY :
/ Connector End
<<include>>
Relación de inclusión UML 2.5

i : Include :
<<extend>>
: Relación de extensión UML 2.5

Extend
Sistema UML
Una vez creados los actores y los casos de uso, hay que establecer las relaciones entre
ellos. Para las relaciones de comunicación, se utiliza el icono Association/Connector de la
paleta UML 2.5 que se muestra en la Tabla 6.2. Se puede cambiar el grosor de la línea,
seleccionándola y reduciendo su número de puntos en la pestaña Style de las propieda-
des de la derecha (véase Figura 5.34).
Para establecer las relaciones de inclusión y de extensión, se emplean los elementos

Include y Extend que aparecen al final de la paleta UML 2.5. El diagrama de casos de uso
quedará como el que se muestra en la Figura 6.4.
"
N 1OMUNICACIONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
Transferencia
_por internet
<<exterid>>
,
Transferencia
- -<<include>>
- a( dentificación
Cliente <<include3
Figura 6.4. Diagrama de casos de uso para una entidad bancaria creado con diagrams.net.
Ya solo faltaría indicar los límites del sistema, pues debe recordarse que los actores no
forman parte del sistema en un diagrama de casos de uso. A tal fin, se hace uso del ele-
mento Frame de la paleta UML, como se muestra en la Tabla 6.2. Se debe clicar en este
elemento, escribir el nombre que se quiere dar al sistema donde pone frame y mover el
marco al lugar del área de edición. Allí se dimensionará este marco lo necesario para
que abarque todo el diagrama excepto los actores. De esta manera, se habrá conseguido
un diagrama de casos de uso completo como el de la Figura 6.2.
M EE Elaboración de diagramas de casos de uso con Papyrus

En el Apartado 5.6.2. se vio que, para crear diagramas UML con el módulo Papyrus Sys-
ML de Eclipse, es necesario crear un proyecto por medio de la opción de menú File >
> New > Papyrus Project. Al activar en la ventana emergente (véase Figura 5.42) la casi-
lla de verificación correspondiente a Use Case Diagram, se indica que se quiere crear un
diagrama de casos de uso.
En el caso de querer añadir un diagrama de casos de uso a un proyecto ya existente,

una vez abierto este, se pueden añadir nuevos diagramas activando la opción del menú
Papyrus > New Diagram y eligiendo el tipo de diagrama de que se trate.
En este ejemplo, se va a crear el mismo diagrama de casos de uso para un sistema

bancario que se ha creado con diagrams.net. En la Tabla 6.3 se recogen los elementos
de la paleta que se van a incluir en el diagrama y la sección de la paleta en la que se
encuentra cada elemento.
Tabla 6.3. Elementos que forman parte de los diagramas de casos de uso con el símbolo
correspondiente en Papyrus SysML y la sección de la paleta donde se encuentra
Elemento Símbolo Sección de la paleta

Caso de uso E Use Case Nodes
Actor $ Actor Nodes )

6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO INFORMATICA Y CO/X 1
Elemento Símbolo i Sección de la paleta

: Relación de comunicación : 7 Association Links
i - ; - : - i ,
Relación de inclusión - o Include Links
En primer lugar, se colocará en el diagrama el elemento que señaliza los límites del sis-
tema. Para ello, se utilizará el elemento Subject de la sección Nodes de la paleta. Una
vez seleccionado este elemento, y al hacer clic sobre el área de edición, aparecerá una
ventana como la de la Figura 6.5, en la que habrá que indicar el tipo de elemento que se
desea crear. Se debe elegir el tipo Component.
[SY Artifact
/ Association
É AssociationClass
Class
“= Collaboration
f CommunicationPath
Etoménaú¡
DataType
[ DeploymentSpecification
(S) Device
FEl Enumeration
(E] ExecutionEnvironment
O)
Figura 6.5. Ventana en la que se indica el tipo de elemento que se desea

crear cuando se establecen los límites del sistema con el elemento Subject
de la paleta. Se debe elegir el elemento Component.
A continuación, aparecerá dicho componente en el área de edición. En ese momento, se

debe asignar un nombre al sistema y luego se podrá redimensionar para que abarque
todo el diagrama, exceptuando el actor Cliente.
Cuando se añaden elementos al diagrama, se deben de colocar todos ellos, excepto el actor,
dentro de los límites del sistema. Para crear un caso de uso, hay que clicar sobre el icono
correspondiente en la sección Nodes de la paleta. Luego, se debe hacer clic en el área deli-
mitada por el sistema y se escribe el nombre del caso de uso. En el caso de los actores, se
debe pulsar sobre el icono del actor en la misma sección de la paleta y asignarle su nombre.
1,Ú 1»OMUNICACIONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
Una vez creados los actores y los casos de uso, se deben establecer las relaciones entre
ellos. Para las relaciones de comunicación, se hará uso del icono Association de la sec-
ción Links de la paleta que se muestra en la Tabla 6.3. Solo hará falta pulsar sobre este
icono, luego hacer clic en el actor y el correspondiente caso de uso en el área de edición.
Si se quiere establecer relaciones de inclusión y de extensión, se utilizarán los elemen-

tos Include y Extend que aparecen en la sección Links de la paleta.
De esta manera, se habrá conseguido un diagrama de casos de uso completo como el

de la Figura 6.6.
=|
- Sistema bancario
- Ingreso E Transferencia por internet
«extend»
' Transferencia «include»
Cliente
- Identificación
' Extracción
Figura 6.6. Diagrama de casos de uso para una entidad bancaria creado con Papyrus SysML en Eclipse.
E 6.3. Diagramas de interacción

Los diagramas de interacción muestran un conjunto de objetos y los mensajes que se
intercambian entre ellos para describir el comportamiento del sistema.
7Ziv
EFO
Argot técnico
El nombre de diagramas de interacción que se asigna a estos diagramas en UML obedece
a que estos diagramas muestran de qué manera interactúan los distintos objetos que forman
parte de una aplicación para llevar a cabo las tareas encomendadas a ella. Hay que tener
presente que una aplicación orientada a objetos se ejecuta por medio del envío de mensajes
entre los diferentes objetos que la componen y que un mensaje es una solicitud enviada
desde un objeto a otro o a él mismo para que ejecute un método.
Aunque en la última versión de UML se distinguen cuatro tipos de diagramas de interac-

ción, los más relevantes son los diagramas de secuencia y los de colaboración, que se
van a estudiar a continuación.
f /
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO INFORMATICA Y (… JI
ME 6.3.1. Diagramas de secuencia

Los diagramas de secuencia muestran la secuencia cronológica de los mensajes inter-
cambiados entre objetos durante un escenario de un caso de uso, por lo que es posible
afirmar que detallan el flujo de control para llevar a cabo lo especificado en un escenario
de un caso de uso.
Argot técnico
Lo relevante en un diagrama de secuencia es precisamente la secuencia cronológica o el
orden en el que se envían los mensajes para ejecutar lo especificado en un escenario de un
caso de uso; de ahí su nombre.
En un diagrama de secuencia, para cada actor u objeto que interviene, se crea una línea
vertical con trazado discontinuo llamada línea de vida, en la parte superior de la cual se
dibuja un rectángulo que representa a una clase, o un actor, según el caso. En el interior
del rectángulo se debe escribir el signo de puntuación dos puntos (:) y el nombre de la
clase, que representa un objeto de dicha clase.
El tiempo transcurrido se representa de arriba hacia abajo. Los mensajes se representan

mediante flechas de una clase a otra clase, indicando que la clase de la que parte la fle-
cha envía un mensaje a la clase en la que acaba la flecha. Por medio de dichas flechas,
se solicita la ejecución del método correspondiente de la clase receptora del mensaje.
Sobre las líneas de vida se pueden representar opcionalmente rectángulos en vertical

que representan el tiempo durante el cual está activo un método, es decir, el tiempo
durante el que este se está ejecutando o bien está esperando la finalización de otro
método llamado desde él.
En el ejemplo de la Figura 6.7 se muestra un diagrama de secuencia en el que un objeto

de la clase A envía un mensaje a un objeto de la clase B solicitando la ejecución del
método m1/(). A su vez, este objeto, necesita, para ejecutar el método m1, enviar dos
mensajes a un objeto de la clase C, el m2() y el m3(), en este orden.
Figura 6.7. Diagrama de secuencia de ejemplo con tres objetos que se intercambian
mensajes para realizar lo especificado en un supuesto escenario de un caso de uso.
| *¡/XX Y COMUNICACIONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
Como paso previo a la elaboración de los diagramas de secuencia para cada caso de
uso, es necesario identificar las clases de análisis. Por ejemplo, para la aplicación de la
agenda de excompañeros de la Actividad resuelta 6.1, para la que se especificaron los
casos de uso, se pueden identificar las siguientes clases:
E Una clase de interfaz, que se llama Ventana.
E Una clase de control, que se llama Contro!.
E Dos clases de entidad, llamadas Excompañero y Cena.
Con estas cuatro clases, es posible crear el diagrama de clases que se representa en
la Figura 6.8, en el que se ha relacionado la clase de control con las clases de entidad
Excompañero y Cena. Para cada cena se necesita conocer los excompañeros y excom-
pañeras que han asistido y la persona que la ha organizado. No se han indicado méto-
dos para las clases, los cuales se irán añadiendo a las clases a medida que se vayan
descubriendo en los diagramas de secuencia. Cada mensaje enviado a una clase en un
diagrama de secuencia será un método de la clase receptora en el diagrama de clases.
Ventana Control
Excompañero
- nombre: String
- fecha: Date
. - teléfono: String
- lugar: String
- email: String
Figura 6.8. Diagrama de clases de análisis con las clases de interfaz, de control y de entidad identificadas
en la aplicación para una agenda de antiguos compañeros y compañeras de estudios.

6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO |NFORMATICFK Íl [ N
Solución
El caso de uso Agregar excompañero/a se inicia en el momento que el usuario o usuaria

solicita agregar un/a excompañero/a, la ventana obtiene los datos del excompañero/a
(nombre, teléfono y correo electrónico) y pide a la clase de control que agregue una per-
sona con esos datos. La clase de control comprueba si ya existe algún excompañero/a
con ese nombre comparando el nombre del excompañero/a que se desea añadir con los
nombres de las personas ya agregadas. En caso de que ya exista una persona con ese
nombre, finaliza el caso de uso; en caso contrario, se crea un objeto de la clase Excompa-
ñero a partir de los datos introducidos por la persona usuaria. En la Figura 6.9 se puede
observar el correspondiente diagrama de secuencia.
Usuano
AgregarExcompañero ()
AgregarExcompañero (nom, tel, ema)
»>
CompararNombre (nom)
Excompañero (nom, tel, ema)
Figura 6.9. Diagrama de secuencia del caso de uso Agregar excompañero(/a.
El caso de uso Consultar excompañero/a (véase Figura 6.10) comienza cuando la persona
usuaria solicita consultar los datos de un/a excompañero/a, la ventana obtiene el nombre
de este o esta, y pide a la clase de control que busque una persona con ese nombre. La
clase de control comprueba si existe alguna persona con ese nombre comparando el nom-
bre del excompañero/a que se desea consultar con los nombres de los excompañeros/as
existentes. En caso de que no exista una persona con ese nombre, finaliza el caso de
uso; y en caso contrario, se muestran los datos de ese antiguo compañero o compañera
(teléfono y correo electrónico).
Ust:ano
-—ConsultarExcompañero(
ConsultarExcompañero (nom)
CompararNombre (nom)
MostrarExcompañero ()
Figura 6.10. Diagrama de secuencia del caso de uso Consultar excompañero/a.

| U…UN'CAGONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
El caso de uso Agregar cena (Figura 6.11) se inicia cuando el usuario o usuaria solicita
agregar una cena. La ventana obtiene entonces la fecha y el lugar de la cena y pide a
la clase de control que agregue una cena con esos datos. Se comprueba si ya existe
alguna cena para el año indicado, comparando el año de la cena que se desea añadir
con los años de las cenas existentes. En caso de que se encuentre una cena para el año
indicado, finaliza el caso de uso; en caso contrario, la ventana solicita la introducción del
nombre de la persona que organiza la cena y se busca un excompañero o excompañera
con el nombre de la persona organizadora, comparando este nombre con los de las per-
sonas ya agregadas. En caso de que no exista ningún excompañero o excompañera con
ese nombre finaliza el caso de uso; en caso contrario, se crea un objeto de la clase Cena
a partir de los datos introducidos por la persona usuaria.
í :Ventana :Control :Cena :Excompañero

Usuario y -
AgregarCena () E
AgregarCena1 (fec, lug)
CompararAño (año)
AgregarCena2 (org) :
CompararNombre (org)
Cena (fec, lug, org)
Figura 6.11. Diagrama de secuencia del caso de uso Agregar cena.
El caso de uso Eliminar cena (Figura 6.12) comienza solicitándose eliminar una cena. La
ventana obtiene el año de la cena que se desea eliminar y pide a la clase de control que
busque una cena para ese año. La clase de control comprueba si existe alguna cena para
el año indicado comparando el año de la cena que se desea eliminar con los años de
las cenas existentes. En caso de que no exista, finaliza el caso de uso; en caso de que
sÍ exista, la clase de control solicita la eliminación de la cena enviando un mensaje a la
clase Cena.
Usuario
1
1
EliminarCena ()
EliminarCena (año)
CompararAño (año)
EliminarCena ()
Figura 6.12. Diagrama de secuencia del caso de uso Eliminar cena.

6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO |NFORMAT¡CÁ Y [k
El caso de uso Agregar asistente (Figura 6.13) se inicia en el momento en que la persona
usuaria solicita agregar un asistente a una cena, la ventana obtiene el año de la cena y
pide a la clase de control que consulte si hay una cena para ese año. La clase de control
comprueba si esta existe, comparando el año de la cena que se desea consultar con
los años de las cenas existentes. En caso de que no haya ninguna cena para ese año,
finaliza el caso de uso; en el caso contrario, la ventana obtiene el nombre del asistente
a la cena que se desea agregar y pide a la clase de control agregar dicho asistente. Esta
clase de control solicita buscar dicho asistente entre las personas agregadas. Si no lo
encuentra, finaliza el caso de uso; en caso contrario, lo busca entre los asistentes a la
cena. En caso de que ya figure, finaliza el caso de uso; y, en caso contrario, se agrega
dicho asistente a la cena.
í Ventana :Control :Cena :Excompañero

Usuario
r AgregarAsistente () ' :,
— ——— ,
BuscarCena (año) e CompararAño (año) —_:
Ul .
AgregarAsistente (año, asisl _:_ H
BuscarAsistente (asis)
CompararNombre (asis)
Figura 6.13. Diagrama de secuencia correspondiente al caso de uso Agregar asistente.
Una vez elaborados los diagramas de secuencia, se puede ir refinando o ampliando el dia-
grama de clases de la Figura 6.8, de manera que cada mensaje que recibe una clase se
corresponde con un método de dicha clase. Por tanto, a partir de los diagramas de secuen-
cia especificados en esta actividad, se generaría el diagrama de clases que se muestra en
la Figura 6.14.
Control
Ve + AgregarExcompañero (nom: String, tel:String, ema: String) : boolean
+ AgregarExcompañero () + ConsultarExcompañero (nom: String): boolean
+ ConsultarExcompañero () + AgregarCena1 (fec: Date, lug:String): boolean
+ AgregarCena () A —< + AgregarCena2 (org: String): boolean
+ EliminarCena () + EliminarCena (año: int): boolean
+ AgregarAsistente () + BuscarCena (año: int): boolean
+ AgregarAsistente (año: int, asis: String): boolean

j 1
í 0 0.*
Cena Excompañero
- fecha: Date - nombre: String
- lugar: String [ asiste 10,.1| - teléfono: String
+ CompararAño (año: int): boolean E E

. N 0.. organiza _1
+ Cena (fec: Date, lug: String, org: String) + CompararNombre (nom: String) : boolean
+ EliminarCena () + MostrarExcompañero()
+ BuscarAsistente (asis: String): boolean + Excompañero (nom: String, tel: String, ema: String)
Figura 6.14. Diagrama de clases ampliado con los métodos encontrados en los diagramas de secuencia
correspondientes a los casos de uso Agregar excompañero/a, Consultar excompañero/a, Agregar cena,
Eliminar cena y Agregar asistente.
| 1WIX/…NK:AGONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO

Diagramas de secuencia
A partir de la Actividad resuelta 6.2, crea los diagramas de secuencia correspondientes
a los casos de uso Consultar cena, Eliminar asistente y Consultar asistentes. Después,
amplía el diagrama de clases de la Figura 6.14, incluyendo los métodos descubiertos en
los diagramas de secuencia propuestos.
Diagrama de casos de uso, diagramas de secuencia y diagrama de clases

Se desea crear una aplicación para la gestión de un videoclub a partir de la siguiente
descripción:
1. Para cada película es preciso almacenar en el sistema su código, título, año de
producción, género al que pertenece y nombre del país de producción. De la intro-
ducción de estos datos en el sistema se encarga el dependiente del videoclub.
2. Los clientes del videoclub alquilan películas usando una máquina dispensadora de
películas. De cada cliente se guarda la siguiente información en el videoclub: NIF,
nombre, dirección completa, número de teléfono, dirección de correo electrónico,
número de socio y fecha de alta. El dependiente del videoclub también se encarga
de dar de alta a los clientes en el sistema.
3. Cuando un cliente quiere alquilar una película, selecciona la película en la má-
quina dispensadora y el sistema comprueba si el cliente ha recibido una sanción
porque, en tal caso, no se le permitirá alquilar la película. En caso contrario, se
comprobará si hay existencias suficientes de esa película y, en caso afirmativo, se
disminuye el stock de la película y se registra la fecha del alquiler.
4. Cuando un cliente realiza la devolución de una película, se aumenta el stock de la
película. Será necesario registrar asimismo la fecha de devolución de la película,
así como la sanción impuesta en caso de que la devolución se efectúe con poste-
rioridad a la fecha convenida.
Solución
El primer paso es crear el diagrama de casos de uso, que se muestra en la Figura 6.15.
Videoclub J
Registrar película
; ; Registrar cliente
Dependiente
Alquilar película
; ; Devolver película
Cliente
Figura 6.15. Diagrama de casos de uso para un videoclub, que incluye los dos actores que intervienen
en la aplicación (cliente y dependiente) y cuatro casos de uso (registrar película, registrar cliente,
alquilar película y devolver película).
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO |NFORMATICÁX Y [k N
A continuación, se elaboran los diagramas de secuencia para los casos de uso Alquilar
película y Devolver película, pero antes se tienen que identificar las clases de análisis,
que son las siguientes:
El Una clase de interfaz, que se puede llamar Ventana.
El Una clase de control, que se puede llamar Videoclub.
El Tres clases de entidad, llamadas Película, Cliente y Alquiler.
El caso de uso Alquilar película (véase la Figura 6.16) se inicia cuando el cliente solicita
alquilar una película, la ventana obtiene la identificación del cliente (su NIF) y la de la pe-
lícula que desea alquilar (su código) y le pide a la clase Videoclub que proceda al alquiler
de dicha película. Esta comprueba si el cliente tiene impuesta alguna sanción, buscando
el cliente por su NIF. Si ha recibido alguna sanción, se muestra un mensaje de error y fi-
naliza el caso de uso; en caso contrario, se busca la película que se desea alquilar y una
vez encontrada, se comprueba si hay ejemplares suficientes de esa película. En caso de
que no lo haya, se muestra un mensaje de error y finaliza el caso de uso; en caso contra-
rio, se disminuye el stock de dicha película y se procede a registrar el alquiler.
N
Clie:nte :Ventana W :Videoclub , :Cliente :Película ¡Alquiler
'
A AlquilarPelícula() ! — !
F AlquilarPelícula (NIF, CodPel)¿n_
CompararNIF (NIF)
getSanción() []
u
CompararCódigo (CodPel)
getSto¡:k ()
DisminuirStock 0
Alquiler (NIF, CodPel)

1
Figura 6.16. Diagrama de secuencia correspondiente al caso de uso Alquilar película.
El caso de uso Devolver película (Figura 6.17) comienza cuando el cliente solicita devolver
una película. Para ello, la ventana obtiene la identificación del cliente (su NIF) y la de la
película que desea devolver (su código) y le pide a la clase Videoclub que proceda a la
devolución de dicha película. Al efecto de registrar la devolución, se busca la película por
su código y se aumenta su stock. Posteriormente, se registra la devolución apuntando la

fecha de esta y se comprueba si hay que imponer una sanción al cliente por devolución
fuera de plazo. Si es así, se registra dicha sanción para el cliente correspondiente.
1 1IÍJMUNICAC'ONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
Í :Ventana :Videoclub :Película :Alquiler :Cliente

Cliante
: DevolverPelícula () E ! E E i
—¡DevolverPelícula (NIF, CodPel), H ' d
CompararCódigo (CodPel) í E 5
AumentarStock () U ! !
setFecóev() E é
ComprobarSanción ()
setSancion ()
m d
U "
Figura 6.17. Diagrama de secuencia del caso de uso Devolver película.
A partir de las clases de análisis indicadas anteriormente y los métodos detectados en los
dos diagramas de secuencia anteriores, se deduce el diagrama de clases que se observa
en la Figura 6.18.
Ventana Videoclub
+ AlquilarPelícula () + AlquilarPelícula (NIF: String, CodPel:String) : boolean
+ DevolverPelícula () + DevolverPelicula (NIF: String, CodPel:String)
Cliente
- código: int Alquiler
- NIF: String
- fecAlquiler: Date
- título: String
- nombre: String - fecDevPrevista: Date
- añoProducción: int
- dirección: String - fecDevReal: Date
- género: String
- teléfono: String
- país: String + Alquiler (NIF: String, CodPel: int)
- email: String
+ ComprobarSanción (): Float
+ CompararCódigo (CodPel: int): boolean - numSocio: int
+ setFecDev ()
+ getStock (): int - fecAlta: Date
+ DisminuirStock () - sanción: Float

+ AumentarStock
0 + getSanción (): Float
+ setSanción ()
+ CompararNIF (NIF: String): boolean
Figura 6.18. Diagrama de clases para un videoclub.
ME 6.3.2. Diagramas de colaboración

Los diagramas de colaboración son otro tipo de diagramas de interacción. Estos dia-
gramas muestran la misma información que los diagramas de secuencia, pero en los
diagramas de colaboración no se concede una especial relevancia al orden (la secuencia)
en que se envían los mensajes, sino que se da mayor importancia a visualizar las clases
que colaboran y cómo estas se relacionan mediante el envío de mensajes.
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO INFORMATICA Y CC/X
—
Recuerda ,
Lo relevante en un diagrama de colaboración no es el orden en el que se envían los
mensajes para ejecutar lo especificado en un escenario de un caso de uso, sino la
visualización de los objetos que colaboran en una aplicación o en parte de ella por medio
del envío de mensajes. De hecho, los mensajes y colaboraciones que se muestran en un
diagrama de colaboración no tienen por qué estar restringidos a un determinado caso de
Uso, sino que pueden mostrarse las colaboraciones necesarias para la ejecución de varios
o incluso todos los casos de uso de la aplicación.
En un diagrama de colaboración intervienen los siguientes elementos:

E Objetos, clases o actores: se representan de igual modo que en los diagramas de
secuencia.
E Enlaces: las clases que interactúan entre sí mediante el envío de algún mensaje se
unen mediante una línea que representa un enlace entre las clases.
E Mensajes: se representan al lado del enlace entre las dos clases que se inter-
cambian el mensaje, que se representa mediante una flecha, al lado de la cual se
coloca un número y el mensaje en cuestión. El número hace referencia al orden del
mensaje (número de secuencia) dentro del diagrama de colaboración.
Así, el diagrama de colaboración que corresponde al diagrama de secuencia de la Figura 6.7

es el que se muestra en la Figura 6.19. En este diagrama de colaboración, delante de cada
mensaje se ha colocado un número que hace referencia al orden en el que se envía cada
mensaje.
2: m2 ()
——
1:mi1 ()> 3:m3 ()>
A :B C
Figura 6.19. Diagrama de colaboración de ejemplo correspondiente al diagrama de secuencia de la Figura 6.7.
En las Figuras 6.20 y 6.21, se muestran, respectivamente, los diagramas de colabora-

ción que corresponden a los diagramas de secuencia del caso de uso Agregar excompa-
hero/a (Figura 6.9) y del caso de uso Agregar cena (Figura 6.11).
1: AgregarExcompañero () 2: AgregarExcompañero (nom, tel, ema)

— » —— »
:Ventana :Control
Usuario
3: CompararNombre (nom) l í4: Excompañero (nom, tel, ema)

:Excompañero
1a ¡'M
N uOMUNICACIONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
2: AgregarCena!1 (fec, lug)

—
1: AgregarCena () 4: AgregarCena2 (org)
— » — »
:Ventana :Control
Usuario
:Cena :Excompañero
ME 6.3.3. Herramientas para la elaboración de diagramas de interacción

En este apartado, se verá cómo se pueden emplear las herramientas diagrams.net y el
módulo Papyrus SysML de Eclipse para la creación de diagramas de interacción.
M ENE Elaboración de diagramas de secuencia con diagrams.net

Como ya se señaló antes, a la herramienta diagrams.net se accede por medio de la pági-
na web https://app.diagrams.net/.
Una vez cargada la aplicación y tras indicar que se desea crear un nuevo diagrama y la ubi-
cación donde se desea almacenar este, aparecerá una pantalla como la de la Figura 5.34
de la Unidad 5.
En el ejemplo que se va a describir aquí, en primer lugar, se va a crear el diagrama de se-

cuencia para la agenda de antiguos compañeros y compañeras correspondiente al caso
de uso Agregar excompañero/a de la Figura 6.9.
Para crear un diagrama de secuencia, hay que hacer clic sobre el icono correspondiente
a cada elemento en la paleta UML. Dichos elementos se recogen en la Tabla 6.4.
Tabla 6.4. Elementos que forman parte de los diagramas de secuencia, su icono correspondiente
en diagrams.net y la paleta que le corresponde
Elemento
: Línea de vida Í UML

: para un actor
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
Elemento
Línea de vida
: para un objeto UML
Mensaje enviado de un objeto a UML

: otro :
Synchronous
Invocation
— |selfcal .
: <
: Mensaje enviado de UML
: un objeto a sí mismo
Self Call
Para comenzar a elaborar el diagrama, habrá que colocar las líneas de vida correspon-
dientes al actor Usuario y a las clases Ventana, Control y Excompañero. Se clica sobre el
icono correspondiente de la paleta UML y se le asigna un nombre al actor o a la clase.
Posteriormente, habrá que representar los mensajes.
Para cada uno de ellos, se debe pinchar sobre el icono que le corresponde (véase Tabla 6.4)
y se colocará en el lugar correspondiente del diagrama. La flecha discontinua de vuelta
de un mensaje que se envía de un objeto a otro se puede eliminar y se debe sustituir el
texto dispatch, haciendo doble clic sobre él, por el nombre del método correspondiente
con sus parámetros, si es el caso.
Se puede alargar o acortar el rectángulo vertical que representa el tiempo durante el

cual un método está activo, seleccionando dicho rectángulo y haciendo clic con el botón
izquierdo del ratón sobre su extremo superior o inferior. De igual modo, también es posi-
ble acortar o alargar la línea discontinua que representa la línea de vida de un objeto o
de un actor.
Siguiendo estas indicaciones, resulta muy sencillo elaborar un diagrama de secuencia

como el de la Figura 6.9.
M EE Elaboración de diagramas de secuencia con Papyrus

En el siguiente ejemplo, con el fin de crear de manera adecuada los diagramas de se-
cuencia de la agenda de excompañeros y excompañeras, en primer lugar, se crea el
diagrama de casos de uso correspondiente a esta aplicación, que es el que se mostró
'…Á—,1 1 (_OMUNICACIONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
en la Figura 6.3, si bien solo se van a incluir los casos de uso Agregar excompañero/a,
Consultar excompañero/a, Agregar cena, Eliminar cena y Agregar asistente. Después, se
creará también el diagrama de clases de la Figura 6.14.
Para ello, se va a crear un nuevo proyecto con el módulo Papyrus SysML de Eclipse. Hay
que indicar que en este caso se desea crear un diagrama de casos de uso, un diagrama de
clases y un diagrama secuencia. Por consiguiente, se deberán activar en la pantalla como
la de la Figura 5.42 de la Unidad 5, las casillas de verificación correspondientes a Use Case
Diagram, Class Diagram y Sequence Diagram.
En primer lugar, se generará el diagrama de casos de uso de la Figura 6.22 siguiendo

las instrucciones recogidas en el Apartado 6.2.1. Se muestra el diagrama resultante en
dicha figura.
£ ] Agenda excompañeros
C Agregar excompañero
C Consultar excompañero
Usuario
O Agregar cena
C Eliminar cena
O Agregar asistente
Figura 6.22. Diagrama de casos de uso para la aplicación de una agenda de antiguos
compañeros y compañeras que incluye los casos de uso Agregar excompañero/a,
Consultar excompañero/a, Agregar cena, Eliminar cena y Eliminar asistente.
El siguiente paso es crear el diagrama de clases de la Figura 6.14. Para ello, se puede
consultar el Apartado 5.6.2, en el que se indicó cómo crear diagramas de clases con el
módulo Papyrus SysML de Eclipse, si bien no se añadieron métodos a las clases. Dicha
tarea es lo que se debe hacer ahora.
Para añadir métodos a una clase incluida en un diagrama, se debe pulsar en el botón *! de
la sección Owned operation del área de propiedades (véase la Figura 5.44). Es necesario
indicar por cada método, su nombre, tipo de valor que devuelve, visibilidad y parámetros.
En el caso de la clase Ventana, para cada método solo es necesario indicar su nombre en
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO INFORMAT|CA Y CÍ)/X1
Name. Una vez creados los métodos, para que se puedan visualizar en el diagrama, es
necesario, como en el caso de los atributos, arrastrarlos desde el explorador del modelo.
Si el método requiere parámetros, es necesario, por cada uno de ellos, clicar en el botón +
de la sección Owned parameter. Así, para el método AgregarExcompañero de la clase
Control, se deben añadir tres parámetros. Para el primer parámetro, llamado nom, habrá
que indicar su nombre en Name, que es un parámetro de entrada (valor in) en Direction y
que su tipo es String, como se puede observar en la Figura 6.23.
ls exception Otrue (O false ls ordered Otrue (O false

ls stream Otmue (0false ls unique (Otrue O false
Direction in Effect | creste
Visibility | public Type S, String
Multiplicity [ — Default value <Undefined>
UML 1 Comments
Figura 6.23. Propiedades del parámetro nom del método AgregarExcompañero de la clase
Control. El nombre, dirección y tipo de dato son las más importantes.
Para el método AgregarExcompañero, se deben añadir de igual modo los otros dos pará-
metros: tel y ema. Como esta función devuelve un valor booleano que indica si el excom-
pañero o la excompañera se ha podido agregar a la agenda, se debe incluir un «cuarto
parámetro» que determine el tipo del valor de retorno. Por este motivo, no se asignará
ningún nombre al parámetro en la casilla Name, pero se indicará en Direction el valor
return y se elegirá el tipo de dato Boolean (véase la Figura 6.24).
Label
ls exception ls ordered Otrue (O false

ls stream ls unique (Otrue Ofalse
Direction 1 Effect create v
Visibility | yre ES Boolean rai [4p
Default value <Undefined>

Multiplicity
UML| Comments
Figura 6.24. Ventana en la que se muestran las propiedades para el valor de retorno
del método AgregarExcompañero de la clase Control. No es necesario asignarle nombre,
pero se debe indicar en Direction el valor return y se debe indicar su tipo de dato, Boolean.
A Y COMUNICACIÓNES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
Una vez incluidos los tres parámetros para el método AgregarExcompañero, e indicado el
tipo de dato del valor de retorno, las propiedades de este método son las que se mues-
tran en la Figura 6.25.
Name AgregarExcompañero
Label
ls abstract Otrue (O false ls query
ls static Otrue (O false
Body condition <Undefined> Il Visibility

Concurrency [ sequential
Method Owned parameter

“ nom: String
d tel: String
“ ema: String
£ :Boolean
Figura 6.25. Propiedades para el método AgregarExcompañero de la clase Control:

su nombre, visibilidad, sus tres parámetros y el tipo del valor de retorno.
Se deberá obrar de igual modo para los demás métodos de esta clase y para el resto de
clases del diagrama, obteniéndose al final el diagrama de clases de la Figura 6.26.
Ventana Control
48 + AgregarExcompañero() - 48 + AgregarExcompañero( in nom: String, in tel: String, in ema: String): Boolean|

ventana 1
4 + ConsultarExcompañero() [ ConsultarExcompañero( in nom: String): Boolean
1B + AgregarCena() 4 + AgregarCena1( in fec: EDate, in lug: String): Boolean
48 + EliminarCena() 1 + control
Bl + AgregarCena2( in org: String): Boolean
48 + AgregarAsistente() 48 + EliminarCena( in año: Integer): Boolean
B + BuscarCena( in año: Integer): Boolean
48 + AgregarAsistente( in año: Integer, _in asis: String): Boolean
1
+ control
+ control
+ excompañero *
E Cena " E Excompañero
+ cena . :
E - fecha: EDate [1] asiste EZ - nombre: String [1]
E - lugar: String [1] EZ - teléfono: String [1]
+ + excompañero EZ — - email:email String
Stei [1]
E + CompararAño( in año: Integer): Boolean
1B + Cena( infec: EDate, in lug: String, n org: String) B + CompararNombre( in nom: String): Boolean
+cena organiza 1
B + EliminarCena() u - MostrarExcompañero()
4 + BuscarAsistente( in asis: String): Boolean + excompañero 4 + Excompañero( in nom: String, in tel: String, in ema: String)
Figura 6.26. Diagrama de clases creado con Papyrus SysML para los casos de uso Agregar excompañero(/a,
Consultar excompañero/a, Agregar cena, Eliminar cena y Agregar asistente de la agenda de antiguos
compañeros y compañeras.
Seguidamente, se explicará cómo crear diagramas de secuencia con Papyrus, tomando como
ejemplo el diagrama de secuencia para el caso de uso Agregar cena de la Figura 6.11.
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO INFORMAT|CA Y CON! v
Con este fin, en primer lugar, hay que colocarse en la pestaña de Eclipse correspon-
diente al diagrama de secuencia. Una vez situados en esa pestaña, lo primero que hay
que hacer es colocar las líneas de vida correspondientes al actor Usuario y a las clases
Ventana, Control, Cena y Excompañero. Para ello, se arrastra el elemento correspondiente
(el actor y las clases) desde el explorador del modelo al área de edición. Se obtiene un
resultado como el que se observa en la Figura 6.27.
f- Model Explorer X = a 7)"Agendaxcompañeros.di X

=
e7 % s E () 3 [interction
Eltea J
% Usuario A
: Usuario : Ventana : Control :Cena : Excompañero
b £] Agenda excompañeros
b / A agregar excompañero 1
> / A consultar excompañero.
b / A agregar cena_usuario
b / Aceliminar cena_<Property
b / Aeliminar asistente_<Proy
D E Ventana
» El Control
» El Excompañero
» £l Cena
b / A control ventana
b / A excompañero_control
b / organiza
b / asiste
b / Acena control
9É Use Case Diagram < -
B Class Diagram “EN Seguence Diagram X |28 Use&sel)¡¡gnml E ClmDi¡gnm|
Sequence Diagram = — e
DE ¿Paélige Imiporf5'UMLP E Properties X J Model Validation %7 References € Documentation
» ] Interaction1 E] Interaction1, Interaction1, Interaction1
É Í:| :;'::': compineo UML Is abstract Otme Ofalse ls active Otme Ofalse
b / Aagregarexcompañero
L y — Advanced - lsreentrant Otrue Ofalse
l2 E :
Figura 6.27. Líneas de vida necesarias para el diagrama de secuencia correspondiente al caso de uso Agregar
cena. Para colocar las líneas de vida, se debe arrastrar el elemento correspondiente de cada línea de vida
(actor o clase) desde el explorador del modelo al área de edición del diagrama.
Para añadir los mensajes, se hace clic sobre el elemento % Message Sync de la sección
Edges de la paleta (Figura 6.28) situada a la derecha del área de edición.
7 AgendaExcom... X % =a
<7 Palette D
N a ar; --
E Nodes <
? Lifeline
[> Action Execution Specification
[6P Behavior Execution Specification
=.) InteractionUse
] Combined Fragment
2 ] Interaction Operand
[ StateInvariant_—— —
5S Edges <
) Message Sync
) Message Async
+-- Message Reply
--> Message Create
—>x Message Delete

—» Message Lost
— Message Foun¡
Figura 6.28. Paleta de Papyrus para la elaboración

de diagramas de secuencia.
—. JK". Y COMUNICACIONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
Luego, se debe arrastrar el ratón desde la línea de vida del emisor a la del receptor, y se
asigna un nombre por defecto al mensaje enviado y al mensaje de retorno (Figura 6.29).
:Usuario :Ventana
Message11
E—
h Message16
Figura 6.29. Por cada mensaje que se envía en un diagrama de secuencia, Papyrus
SysML crea dos mensajes: el mensaje enviado, que en este caso se llama Message11,
y el mensaje de retorno, llamado Message16.
Al seleccionar el mensaje de envío Message11, es posible conocer sus propiedades en la

sección Properties, tal y como se muestra en la Figura 6.30.
9 Message11
ua Name [Messagel![ ]
Comments aa ]
Profile _
Se Message sort synehCall v
Appearance Signature |<Undefined> El e a

Advance
Rulers And Grid -- Argument EE
Advanced
Figura 6.30. En la sección Properties, tras seleccionar un mensaje, se pueden ver y

modificar sus propiedades (su nombre, etiqueta, el método al que se llama, etc.).
En el campo Signature (Figura 6.30), se debe indicar el método del objeto receptor que ha
de ejecutarse en respuesta al mensaje. Para ello, se hace clic en el botón que presenta los
tres puntos y se elige el método AgregarCena() de la clase Ventana, como se muestra en
la Figura 6.31. Al realizar esta operación, el nombre del mensaje enviado es sustituido por
el método seleccionado.
= Tree $= Flat
4 5 Ventana
4 Agregarfxcompañero (
4 Consultarxcompañero
AgregarCena
[ 0)
48 EliminarCena (
4 AgregarAsistente ()
> El Control
> El Excompañero
» El Cena
Recent selections
[4 AgregarCena Q
Figura 6.31. Por cada mensaje que se envía en un diagrama de secuencia en Papyrus
SysML, se debe seleccionar el método de la clase receptora que se debe ejecutar en
respuesta a ese mensaje, asignando un valor al campo Signature del mensaje enviado.
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO INFORMATICA Y CO/X1 1
Aunque los mensajes de retorno no sean necesarios en este caso, no se pueden elimi-
nar del modelo porque entonces Papyrus SysML borra el rectángulo vertical que repre-
senta el tiempo durante el cual el método está activo. Lo que se puede hacer es selec-
cionar el mensaje de retorno y dejar en blanco el nombre del mensaje (campo Name de
las propiedades del mensaje). Tras hacer esto, para el primer mensaje del diagrama de
secuencia, el resultado es el que se muestra en la Figura 6.32.
79 “AgendaExcompañeros.di X
: Usuario : Control :C : Excompañero
Ea
AgregarCena()
A
|
< _
TE Sequence Diagram |98 Use Case Diagram | BA Class Diagram |
[ Properties X — / Model Validation %7 References € Documentation
% Message11
UmL Name [ Messagel1
Comments Label [
Profile eal
siyle Message sort syne
Appearance Signature 48 AgregarCena 0
Figura 6.32. Diagrama de secuencia correspondiente al caso de uso Agregar cena, en el que se muestra
el primer mensaje, que es enviado desde el actor Usuario a la clase Ventana y solicita la ejecución
del método AgregarCena().
Se debe realizar la misma operación para crear el resto del diagrama de secuencia.
Conviene que se alarguen o acorten los rectángulos verticales que representan el tiempo
de activación de cada mensaje antes de añadir posteriores mensajes. Para ello, basta
con arrastrar el extremo inferior de cada rectángulo. Al final se obtiene un diagrama de
secuencia como el que se muestra en la Figura 6.33.
: Usuario : Ventana : Control I : Cena | I ; Excom&ñero |

U L U U
AgregarCena() '' '
'
AgregarCena1(fec: EDate, lugi String): Boolean
AgregarCena2(org: String): Boolean

A
Figura 6.33. Diagrama de secuencia para el caso de uso Agregar cena de la agenda de excompañeros
y excompañeras realizado con el módulo Papyrus SysML de Eclipse.
ij X1Í/ (.OÍ…UNICACIONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
M EN EN Elaboración de diagramas de colaboración con diagrams.net

En este apartado, se aprenderá cómo se puede crear un diagrama de colaboración con
diagrams.net. En este caso, se realizará el correspondiente al caso de uso Agregar ex-
compañero/a de la agenda de antiguos compañeros y compañeras (Figura 6.20).
Para crear un diagrama de colaboración, se pincha sobre el icono correspondiente a cada

elemento en la paleta UML, de acuerdo con la Tabla 6.5.
Tabla 6.5. Diferentes elementos que forman parte de los diagramas de colaboración, su símbolo
correspondiente en diagrams.net y la paleta que le corresponde
Elemento Símbolo
: Actor Í UML
Clase u objeto UML
Enlace Association / Connector / UML

: : Instance Specification / Property :
/ Connector End
: . dispatch
: Mensaje UML
Message
Se comenzará a elaborar el diagrama colocando en el área de edición el actor Usuario y

las clases Ventana, Control y Excompañero. Una vez hecho esto, se unirán mediante un
enlace el actor Usuario y la clase Ventana.
Luego, se añade el mensaje AgregarExcompañero() enviado desde Usuario a Ventana.

Tras colocar la flecha en el área de edición, se sustituye el texto dispatch por AgregarEx-
compañero().
Siguiendo estas indicaciones, resulta muy sencillo elaborar el diagrama de colaboración

de la Figura 6.20.
4 /
|¡ N
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO INFORMATICA Y ( y
M ENEN Elaboración de diagramas de colaboración con Papyrus

En este ejercicio, se va a añadir al proyecto en el que antes se ha creado el diagrama
de secuencia para el caso de uso Agregar cena (véase Figura 6.11) el correspondiente
diagrama de colaboración, que se mostró en la Figura 6.21. A tal efecto, una vez abierto
el proyecto en Eclipse, seleccionándolo desde el explorador del modelo, se activa en el
menú contextual la opción New Diagram > Communication Diagram y se le da un nombre
al diagrama de colaboración.
Para comenzar, será necesario colocar en el área de edición los rectángulos que repre-
sentan los objetos o clases. En Papyrus, los actores se representan también con rectán-
gulos, como los objetos y las clases. Para ello, se arrastran desde el explorador del mo-
delo los elementos del modelo correspondientes: el actor Usuario y las clases Ventana,
Control, Cena y Excompañero. Una vez hecho esto, la única manera de establecer enlaces
entre las clases es mediante el envío de mensajes entre ellas.
Se empieza haciendo clic sobre el elemento Message del área Edges de la paleta (véase
Figura 6.34).
ss
6? Palette ID
Naan-E-
E7 Nodes o
? Lifeline
El Comment
(?) Constraint
$ Duration Observation
Et Time Observation
dj Edges o
--> Message
Z Link
Figura 6.34. Paleta de Papyrus para la elaboración de diagramas

de colaboración.
A continuación, se clica sobre la clase que envía el mensaje, en primer lugar, y luego
sobre la clase receptora. En este caso, se comenzará con el mensaje AgregarCena()
enviado desde el actor Usuario a la clase Ventana. Aparecerá entonces un mensaje con
un nombre por defecto que habrá que modificar. En las propiedades del mensaje, en el
campo Signature, se seleccionará el mensaje de la clase receptora (Ventana) correspon-
diente: en este caso, AgregarCena(). A diferencia de lo que ocurría al hacer esto en los
diagramas de secuencia, no se modifica el texto del mensaje, por lo que habrá que es-
cribirlo en la propiedad Name, como se muestra en la Figura 6.35. Debe recordarse que,
para los diagramas de colaboración, se debe poner antes del nombre del mensaje un nú-
mero, que indica el orden en el que se envía el mensaje en el contexto de este diagrama.
Las propiedades para el primer mensaje del diagrama se mostrarán como se observa en
la Figura 6.35.
A Xf, (OMUNICACIONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
7 *AgendaExcompañeros.di X
P]interaction19 J
1: AgregarCena()
: Usuario h — — l : Ventana : Control
:Cena : Excompañero
<
H Sequence Diagram |;8 Use Case Diagram W BB Class Diagram [$ DColaboraciónAgregarCena X
[ Properties X J Model Validation %7 References Q Documentation

% 1: AgregarCena()
UML Name | 1: AgregarCena()
Comments Label í
Profile =
style Message sort | asynchCall
Appearance Signature |'Ú AgregarCena ()
Figura 6.35. Propiedades del mensaje AgregarCena(), que es el primero del diagrama de colaboración
correspondiente al caso de uso Agregar cena de la agenda de excompañeros y excompañeras.
Después, se establecerán los restantes mensajes entre las clases del diagrama de cola-
boración de igual modo y se conseguirá al final un diagrama de colaboración como el que
EJinteraction19 _)
2: AgregarCena1 (fec, lug)
—
1: AgregarCena: 5: CompararNombre (org
+ Usuario — : Ventana : Control — : Excompañero
4: AgregarCena2 (org)
—
3: CompararAño (año) l6: Cena (fec, lug, org)
l : Cena
|
Figura 6.36. Diagrama de colaboración para el caso de uso Agregar cena de la agenda de antiguos compañeros
y compañeras realizado con el módulo Papyrus SysML de Eclipse.
EN 6.4. Diagramas de estados

Los diagramas de estados se usan para describir el comportamiento en el tiempo de un

objeto particular o de una interacción. Concretamente, muestran los estados (situacio-
nes) por las que puede pasar un objeto y las transiciones o cambios de estado que expe-
rimenta como consecuencia de los eventos que van sucediendo. Este tipo de diagramas
se usan normalmente para mostrar el comportamiento de objetos relevantes.
A
I PAI
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO INFORMATICA [x….'._w '
Seguidamente, se detallan los elementos de los que consta un diagrama de estados y la

manera de representarlos:
E Estado: un estado es cada una de las situaciones por las que puede pasar un ob-
jeto, tiempo durante el cual realiza cierta actividad o espera la ocurrencia de algún
evento. Un estado se representa mediante un rectángulo con esquinas redondea-
das. No obstante, hay dos estados especiales durante los cuales el objeto no reali-
Za ninguna actividad; estos se simbolizan de manera distinta (véase la Figura 6.37).
1. El estado inicial, que se representa mediante un círculo relleno de color negro.
2. El estado final o último estado por el que pasa un objeto, que se representa
como se muestra en la Figura 6.37. No es necesario que en todos los casos
haya un estado final, y también hay que tener en cuenta que podría haber más
de uno.
“ o
Estado inicial Estado final
Figura 6.37. Representación de los estados inicial y final

en un diagrama de estados.
M Evento: es algo que acontece durante la vida de un objeto y que desencadena el

paso de este a otro estado, es decir, los cambios de estado de los objetos vienen
determinados por la ocurrencia de determinados eventos. Un evento puede ser el
cumplimiento de una determinada condición, la recepción de un mensaje, el trans-
curso de cierto periodo de tiempo, etcétera.
E Transición: es el paso de un estado a otro como consecuencia de la ocurrencia de

un evento. Se representa como una flecha que parte del estado origen y llega al
estado destino y sobre esta flecha se debe indicar el nombre del evento que desen-
cadena el cambio de estado.
A modo de ejemplo, se va a mostrar a continuación un diagrama de estados que repre-

senta los estados por los que puede pasar la puerta de un garaje a lo largo de su vida
(Figura 6.38).
Para el manejo de esta puerta, se dispone de un mando a distancia con dos botones:
uno para solicitar su apertura y otro para solicitar su cierre. Así, del estado inicial, la
puerta pasa al estado Cerrada. Si en este estado se solicita su cierre, seguirá en el
mismo estado, mientras que si alguien solicita su apertura, pasará al estado Abriendo.
Encontrándose en este estado, cuando se detecte que la puerta ya se ha abierto com-
pletamente, pasará al estado Abierta. Si en el estado Abriendo se solicita su apertura no
cambiará de estado, mientras que si se solicita su cierre, pasará al estado Cerrando. Si

en este estado se solicita su cierre, continuará en el mismo estado, pero si se solicita su
apertura, pasará al estado Abriendo. Si encontrándose en el estado Cerrando, se detecta
que la puerta ya se ha cerrado completamente, pasará al estado Cerrada. En este caso,
no se necesita la existencia de un estado final.
| l í»OMUNICACIONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
Puerta
- código: int
- nombre: String
abrir ()
. - Ubicación: String
abrir ()
cerrar () + abrir ()
apertura completa
+ cerrar ()
Figura 6.38. Diagrama de estados que representa los estados por los que puede pasar una puerta de garaje.
Sobre las flechas que representan las transiciones, se pueden incluir no solo el evento
que origina la transición, sino también los dos elementos que se indican a continuación:
1. Una condición de guarda, que se evalúa cuando ocurre el evento, de forma que si
la condición es verdadera, se produce la transición, mientras que si es falsa, no
se da la transición. Esta condición se debe especificar entre corchetes después
del nombre del evento.
2. Una acción, que es una operación que se lleva a cabo si se produce la transición
y se corresponde con algún método de la clase para la que se está creando el
diagrama. También puede ser una solicitud para la ejecución de algún método por
parte de otra clase. Se debe escribir esta acción después del evento, con la con-
dición asociada, si es el caso, y después del símbolo de barra (/).
Si se incluyen en el evento una condición de guarda y una acción, el texto que se debe
colocar encima de la flecha correspondiente a la transición puede tener alguna de las
dos siguientes formas, dependiendo de si la acción se corresponde con un método de la
propia clase o de otra clase, respectivamente:
evento [condición] / método
evento [condición] / objeto.método
Para ilustrar lo que se acaba de explicar, aquí se va a realizar el diagrama de estados

correspondiente a la clase Ventana de la agenda de excompañeros y excompañeras, re-
flejando únicamente los estados por los que pasa esta clase en relación con los casos
de uso Agregar excompañero/a y Agregar cena.
La ventana parte de un estado llamado En espera hasta que el usuario o usuaria selec-
ciona una de las opciones del menú.
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO INFORMAT|CA Y CO/XV'1 1—
En el momento en que se selecciona la opción de menú Agregar excompañero/a, pasa al

estado Comprobando excompañero/a con el fin de determinar si el antiguo compañero o
compañera que se pretende añadir ya está en la agenda. Si esta persona ya está agrega-
da, se muestra un mensaje de error y se vuelve al estado de espera. En cambio, si esa
persona no está en la agenda, se crea este excompañero o excompañera y se vuelve al
estado de espera.
Si se selecciona la opción de menú Agregar cena, pasa al estado Comprobando cena con
el fin de determinar si ya hay una cena ese año. En este caso, se muestra un mensaje
de error y se vuelve al estado de espera. En caso de que no haya cena ese año, se com-
prueba si el nombre de la persona que organiza la cena es correcto, es decir, si ya existe
en la lista de antiguos compañeros y compañeras. Si no existe, se muestra un mensaje
de error, y si existe, se agrega la cena a la lista de cenas y se vuelve al estado de espera.
Si en estado de espera se selecciona la opción de menú Salir, se pasa al estado final.
El diagrama de estados del ejemplo anterior se representaría como se muestra en la

Figura 6.39.
AgregarExcompañero () /
Control.AgregarExcompañero (nom, tel, ema
No existe /
Excompañero.Excompañero
- Añadiendo
Añadiendo
.ze)?<?“ompañe.
Figura 6.39. Diagrama de estados que representa los estados por los que pasa la clase Ventana
en la agenda de excompañeros y excompañeras en relación con los casos de uso
Agregar excompañero/a y Agregar cena.

Diagrama de estados
Realiza el diagrama de estados correspondiente a la clase Ventana de la agenda de an-
tiguos compañeros y compañeras, reflejando únicamente los estados por los que pasa
esta clase en relación con los casos de uso Consultar excompañero/a y Eliminar cena.
…*A UN'CAUONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO

Diagrama de estados
Crea un diagrama de estados que refleje el funcionamiento de un microondas que solo

dispone de dos botones: uno para ponerlo en funcionamiento y otro para abrir la puerta.
El botón de funcionamiento solo tiene efecto cuando la puerta del horno está cerrada, en
cuyo caso se calienta la comida durante un tiempo determinado, tras el cual finaliza el ca-
lentamiento. Se puede interrumpir el proceso pulsando el botón de apertura de la puerta.
Si el microondas está en funcionamiento o la puerta está abierta, se enciende la luz del
interior del microondas.
En relación con el funcionamiento del microondas, se pueden aplicar los siguientes méto-
dos: encender(), apagar(), encenderLuz() y apagarLuz().
Solución
Se detectan tres estados: Apagado con puerta cerrada, Apagado con puerta abierta y En
funcionamiento. El estado inicial es el primero de los tres.
Si mientras el microondas está apagado con la puerta cerrada, se pulsa el botón de

funcionamiento, se deben encender el microondas y su luz y se debe pasar al estado En
funcionamiento. Si cuando está apagado con la puerta cerrada se pulsa el botón de aper-
tura, se debe encender la luz y pasar al estado Apagado con puerta abierta.
Si mientras está apagado con la puerta abierta, se pulsa el botón de funcionamiento ON

o el botón de apertura de la puerta, no se produce ningún cambio de estado. Si se cierra
la puerta, se debe apagar la luz y se pasa al estado Apagado con puerta cerrada.
Si mientras se encuentra en funcionamiento el microondas, se pulsa el botón de fun-

cionamiento ON, no se producirá ningún cambio de estado. Sin embargo, si se pulsa el
botón de apertura, se debe apagar el microondas y pasar al estado Apagado con puerta
abierta. Si, en funcionamiento, expira el tiempo de calentamiento, se debe apagar el mi-
croondas y la luz y se debe pasar al estado Apagado con puerta cerrada.
En la Figura 6.40 se muestra el diagrama que refleja las situaciones antes descritas.
Botón apertura
Botón apertura / encenderLuz()

Apagado con Apagado con
puerta cerrada puerta abierta ENe
Cerrar puerta / apagarLuz()
Tiempo acabado / apagar(), apagarLuz() Botón apertura / apagar()
(_ Botón ON / encender(), encenderLuz()

En funcionamiento Botón ON
Figura 6.40. Diagrama de estados que representa el funcionamiento de un microondas con dos botones:
el de funcionamiento (ON) y el de apertura de la puerta. Este microondas dispone de una luz que debe
permanecer encendida mientras está en funcionamiento o si la puerta está abierta.
1
I FA
[ )N
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO INFORMATICA [*…'—.;/ '
E 6.5. Diagramas de actividades

Los diagramas de actividades se usan para mostrar el flujo de control de las acciones
que se llevan a cabo en una parte del sistema. En concreto, se pueden usar los diagra-
mas de actividades para:
E Especificar el comportamiento de un método complejo.
E Especificar el comportamiento de un caso de uso.
E Describir el comportamiento de un proceso de negocio o un flujo de trabajo entre

las personas usuarias y el sistema.
E Especificar el comportamiento de un objeto o de un conjunto de objetos.
E Definir estados complejos.
Los elementos que se pueden incluir en un diagrama de actividades se recogen en la

Tabla 6.6. Como se puede observar, por cada elemento, se indica su nombre, el símbolo
que lo representa y una descripción del elemento.
Tabla 6.6. Elementos de un diagrama de actividades
Elemento Simbolo Descripción
Nodo de inicio . Representa el inicio del diagrama de actividad.
, Representa el final del flujo de actividades. Puede

Nodo de fin i o ; ; i
: que no haya ningún nodo de fin, uno o varios. E
f Actividad o acción - Actividad Represeqta cada una de las acciones md¡v¡c_iuales

¿ ¿ : que se ejecutan a lo largo del flujo de trabajo. — :
: : * Establece el flujo de control entre las acciones.

Flujo de control EE£ . » Después de la acción de la que parte la flecha, se :
i : : ejecuta la acción a la que llega la flecha. :
El flujo de control se desvía a alguna de las ra- í

: mas etiquetadas con condiciones. En función de :
: la condición que se cumple, el flujo se dirige por :
: Bifurcación £ [condiciont] X [condicion2] i un camino u otro. El rombo de decisión solo pue- :
: de tener una entrada y puede tener dos o más :
: salidas. :
: : El flujo de control de varios caminos se junta en :

: Fusión : uno solo. El rombo de fusión puede tener varias :
: : : entradas pero sola una salida. )
T.
N Y
aUV LOMUNICACIONES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
Elemento : Simbolo Descripción
Un flujo de control se separa en dos o más flujos

: de control concurrentes. Se representa llegando :
: un flujo a una barra de sincronización y saliendo :
División
varios. Sirve para indicar que, a partir de determi-
: nado punto, se van a ejecutar varias actividades :
: simultáneamente. E
Varios flujos de control concurrentes se unen en :

¿ un único flujo de control. Se representa llegando :
: a una barra de sincronización varios flujos y sa- i
: Unión
: liendo uno solo. Sirve para indicar que a partir de :
: determinado punto finalizan su ejecución varias :
: actividades simultáneas. :
Se muestra a continuación el diagrama de actividades correspondiente al caso de uso

Agregar cena de la agenda de excompañeros (Figura 6.41). Como se puede observar en
el diagrama de secuencia correspondiente a este caso de uso (Figura 6.11), antes de
agregar la cena, hay que realizar dos comprobaciones: que no haya una cena ese mismo
año y que la persona que organiza la cena se encuentre en la lista de excompañeros y
excompañeras. Si se cumplen estas dos condiciones, se procede a añadir la cena a la
lista de cenas y, en caso contrario, se muestra el correspondiente mensaje de error.
[no hay cena]
[es excompañero]
Figura 6.41. Diagrama de actividades que muestra el flujo de control para el caso de uso Agregar cena.
Diagramas de
comportamiento
—
o
=
.
=
A
É
Eu
o
a
=
o
o
C)
D
[22)
S
=
Ss
u
a
-
()
D
=
o
o
Ss
o
D
Te
u
Diagramas de interacción O Ediciones Paraninfo
Diagramas de actividades
278
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO ACTIVIDADES FINALES
Actividades de comprobación
6.1. ¿Qué diagramas de los especificados a continuación se deben crear antes en el
proceso de desarrollo de software orientado a objetos?
a) Diagramas de secuencia.
b) Diagramas de clases.
c) Diagramas de colaboración.
d) Diagramas de casos de uso.
6.2. ¿Qué relación entre casos de uso indica que varios de ellos hacen uso de otro caso
de uso de forma que este último incluye actividades comunes a los otros?
a) Relación de uso o inclusión.
b) Relación de comunicación.
c) Relación de extensión.
6.3. ¿Qué apartado de la descripción de un caso de uso indica la secuencia ordenada

de pasos por los que pasa el caso de uso?
a) La precondición.
b) La poscondición.
C) Los caminos alternativos.
d) El flujo básico.
6.4. ¿En qué tipos de diagramas se establecen enlaces entre las clases que se envían
mensajes y se muestran los mensajes intercambiados, precediendo a cada mensa-
je un número que hace referencia al orden del mensaje dentro del diagrama?
a) Diagramas de colaboración.
b) Diagramas de secuencia.
c) Diagramas de casos de uso.
d) Diagramas de estados.
6.5. En un diagrama de secuencia, si una clase recibe un mensaje solicitando la ejecu-

ción de un método:
a) Ese método debe estar alojado en la clase que recibe el mensaje.
b) Ese método debe estar alojado en la clase que envía el mensaje.
c) Ese método debe estar alojado en la clase que recibe el mensaje y en la clase que
envía el mensaje.
6.6. Los diagramas de actividades se usan para representar:

a) El comportamiento de varios objetos.
b) La secuencia de mensajes que se intercambian los objetos involucrados en la realiza-
ción de un caso de uso.

c) El comportamiento de un método o de uno o varios casos de uso.
279
ACTIVIDADES FINALES —y rnrianonnenaorassne mc
6.7. En un diagrama de estados:
a) Debe haber un único estado inicial y un único estado final.
b) Debe haber un único estado inicial y puede no haber estado final.
c) Puede no haber estado inicial y debe haber un único estado final.
d) Puede no haber ni estado inicial ni estado final.
6.8. Los diagramas UML que sirven para especificar el flujo de control de las acciones
que se deben realizar para ejecutar un método son:
a) Los diagramas de colaboración.
b) Los diagramas de secuencia.
C) Los diagramas de estados.
d) Los diagramas de actividades.
6.9. En un diagrama de estados, un cambio de estado recibe el nombre de

y lo que desencadena un cambio de estado se llama
a) evento/transición.
b) acción/transición.
c) transición/evento.
d) evento/acción.
6.10. ¿Qué diagramas se podrían emplear para mostrar los mensajes intercambiados
entre varios objetos en varios casos de uso?
a) Los diagramas de secuencia.
b) Los diagramas de colaboración.
c) Los diagramas de actividades.
d) Los diagramas de casos de uso.
6.11. ¿En qué diagrama se muestran todos los actores que intervienen en una aplicación?
a) En un diagrama de secuencia.
b) En un diagrama de colaboración.
C) En un diagrama de actividades.
d) En un diagrama de casos de uso.
6.12. ¿En qué diagramas se pueden detectar métodos para incorporarlos a las clases
que forman parte del diagrama de clases?
a) En los diagramas de secuencia.
b) En los diagramas de actividades.
c) En los diagramas de casos de uso.
6.13. ¿Es posible en un diagrama de actividades representar la ejecución concurrente o

simultánea de varias tareas a partir de un determinado momento?
a) No, noes posible.
b) Sí, para lo que se debe usar un elemento llamado bifurcación.
C) Sí, para lo que se debe usar un elemento llamado división.
d) Sí, para lo que se debe usar un elemento llamado fusión.
280
6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO ACTIVIDADES FINALES
6.14. Crea el diagrama de casos de uso que refleje la gestión de los pedidos de una empresa
que vende una serie de productos de acuerdo con la siguiente descripción:
E Cuando un cliente llama por teléfono o se persona en la empresa para realizar un
pedido, le atiende una vendedora, la cual, para poder registrar el pedido, en primer
lugar, le solicita al cliente sus datos personales, para más tarde tomar los datos del
pedido en cuestión. La vendedora acordará con el cliente la forma de pago.
E Losclientes también pueden consultar en cualquier momento el estado de sus pedi-
dos, información que será proporcionada por la vendedora.
E Porotro lado, una vez que la empresa dispone de los productos solicitados por el
cliente, la persona responsable de los envíos se encarga de gestionar su envío al
domicilio del cliente.
6.15. Crea el diagrama de casos de uso para una librería online de acuerdo con la siguiente
descripción y sin emplear relaciones «include» ni «extend»:
E Cualquier persona usuaria puede buscar los libros que desee aunque no esté regis-
trada. Sin embargo, antes de comprar libros, esta persona debe registrarse sumi-
nistrando sus datos personales, preferencias literarias, un nombre de usuario y una
contraseña. Al finalizar el registro, se le envía a dicha persona un correo electrónico
confirmándole su registro.
E Cualquier usuaria o usuario registrado puede pedir los libros que considere, añadién-
dolos al carrito de la compra. Cuando la persona usuaria selecciona la opción Pedir
libros, se le solicita un nombre de usuario y contraseña y, si estos son correctos, se
le muestran los datos de los libros en pantalla y su dirección de envío, que puede ser
modificada. Una vez confirmados estos datos, debe proceder al pago mediante tar-
jeta bancaria, introduciendo los datos de la tarjeta. Si estos datos son correctos, se
procede al cobro y se le muestra un número de pedido para posteriores consultas del
estado del pedido.
E Cualquier usuaria o usuario registrado puede consultar el estado de su pedido, para
lo que debe introducir el nombre de usuario y contraseña y un número de pedido.
6.16. Realiza la descripción del caso de uso Registro para la librería online de la Activi-
dad 6.15.
6.17. Realiza la descripción del caso de uso Pedir libros para la librería online de la Activi-
dad 6.15.
6.18. Modifica el diagrama de casos de uso de la Actividad 6.15, teniendo en cuenta que si al
pedir un libro, un usuario o usuaria no está registrado, se le permite hacerlo en ese mo-
mento. No obstante, sigue habiendo la opción de registrarse de manera independiente.
6.19. Modifica el diagrama de casos de uso de la Actividad 6.18, incorporando alguna relación
«include».
281
ACTIVIDADES FINALES —y rnrnanonnenaonassne omormiwen
6.20. Crea el diagrama de casos de uso para una academia de acuerdo con la siguiente
descripción:
E Esta academia imparte diferentes cursillos a lo largo del año. Cada cursillo tiene
asignado un código, un nombre, una duración en horas, una fecha de inicio, una
fecha de fin y se imparte ciertos días de la semana en un horario determinado. De
la introducción de los datos de cada cursillo se encarga la secretaria de la aca-
demia.
E Además, para realizar cada cursillo es necesario disponer de una determinada

titulación académica. Por cada una de estas, se registra un código y un nombre
(graduado/a en ESO, bachillerato, ingeniero/a, etc.).
E Las y los alumnos se pueden apuntar en la academia en cualquier momento a lo

largo del año. El registro de un alumno o alumna en la academia implica anotar
los siguientes datos: NIF, nombre y apellidos, dirección, teléfono, correo electró-
nico y titulación de mayor nivel que posee. La secretaria se encarga de introducir
estos datos en el sistema.
E Cuando un alumno o una alumna se desea matricular en un determinado cursillo,

se lo solicita a la secretaria. El sistema comprobará que su titulación se corres-
ponda con la requerida para realizar el cursillo y, en caso de que así sea, se matri-
culará al alumno o alumna asignándole un número de matrícula por cada cursillo
en el que se matricule.
E Es necesario registrar en el sistema, por cada cursillo en el que se matricula un

alumno o alumna, si él o ella ha asistido al 80 % de las clases o no y su califica-
ción (apto o no apto). Al finalizar el cursillo, la secretaria se encargará de generar
los títulos para quienes tengan la calificación de apto.
6.21. Crea el diagrama de secuencia para el caso de uso de la Actividad 6.20 relacionado
con la matrícula del alumnado en un cursillo.
6.22. Crea el diagrama de clases que refleje todas las clases con sus atributos y los méto-
dos detectados en el diagrama de secuencia de la Actividad 6.21.
6.23. Crea un diagrama de actividades para el caso de uso Consultar excompañero/a, cuyo
diagrama de secuencia se muestra en la Figura 6.10.
6.24. Crea un diagrama de actividades para el caso de uso Agregar asistente, cuyo diagra-
ma de secuencia se muestra en la Figura 6.13.
6.25. Crea un diagrama de estados que refleje los estados por los que puede pasar un
mensaje de correo electrónico teniendo en cuenta lo siguiente: inicialmente el mensa-
je se encuentra en estado no leído y, desde esta situación, o bien se puede eliminar,
con lo que pasaría a la papelera, o bien se puede leer, en cuyo caso pasaría a la si-
tuación de leído. Desde esta situación, también se puede eliminar, por lo que pasaría
a la papelera. Estando en la papelera, el mensaje se puede eliminar definitivamente.
Además, si han transcurrido 30 días desde que se envió a la papelera, también es

eliminado de manera definitiva por el servidor de correo.
En la Figura 6.42, se muestra la clase Email con los mensajes que provocan un cam-
282 bio de estado: /eer(), eliminar() y eliminarDefinitivamente().
Email
- fecha
- emisor
- asunto
- contenido
+ leer()
+ eliminar()
+ eliminarDefinitivamente()
Figura 6.42. Clase Email con métodos para leer el mensaje, eliminarlo
para enviarlo a la papelera y eliminarlo de manera definitiva.
6.26. Crea un diagrama de estados que refleje los estados por los que puede pasar un
préstamo solicitado a una entidad bancaria. Se debe tener en cuenta que el prés-
tamo comienza en estado solicitado. En algún momento se procede a su estudio,
como resultado del cual, puede ser rechazado o aceptado por la entidad bancaria.
Se debe comunicar este estado al cliente, que puede formalizarlo o rechazarlo. En
caso de que lo formalice, a partir de ese momento, cada cierto tiempo, el cliente
procederá a su pago parcial o a su amortización (pago por completo), momento en
el cual el préstamo quedará pagado. En la Figura 6.43, se muestra la clase Présta-
mo con los mensajes que provocan un cambio de estado: estudiar(), aceptarBanco(),
rechazarBanco(), comunicar(), formalizar(), rechazarCliente(), pagar() y amortizar().
Préstamo
- código
- importe
- plazo
- cuota
+ estudiar()
+ aceptarBanco()
+ rechazarBanco()
+ comunicar()
+ formalizar()
+ rechazarCliente()
+ pagar()
+ amortizar()
Figura 6.43. Clase Préstamo con métodos para estudiar el préstamo,

su aceptación o rechazo por parte del banco, su comunicación
al cliente, su formalización, su rechazo por parte del cliente,
su pago parcial y su amortización total. 283
ACTIVIDADES FINALES 6. ELABORACIÓN DE DIAGRAMAS DE COMPORTAMIENTO
M Actividadesde ampliación
6.27. Aveces, en los diagramas de secuencia, es necesario incluir mensajes que se han de
enviar solo en caso de que se cumpla una determinada condición, de manera similar
a una estructura alternativa simple de programación. Busca información sobre cómo
se puede representar esta situación en un diagrama de secuencia.
6.28. También existe la posibilidad de representar en los diagramas de secuencia estruc-

turas alternativas dobles o múltiples. Averigua cómo se pueden representar dichas
situaciones en un diagrama de secuencia.
6.29. En ocasiones, es necesario incluir en los diagramas de secuencia mensajes que se

han de enviar varias veces mientras se cumpla una determinada condición, de mane-
ra similar a una estructura repetitiva while. Busca información sobre cómo se puede
reflejar esta situación en un diagrama de secuencia.
6.30. Modifica el diagrama de secuencia correspondiente al caso de uso Agregar excom-

pañero/a de la Figura 6.9 para detallarlo más, empleando una estructura alternativa
simple y una estructura repetitiva.
6.31. Modifica el diagrama de secuencia correspondiente al caso de uso Agregar cena de

la Figura 6.11 con el fin de detallarlo más. Para ello, haz uso de estructuras alternati-
vas y repetitivas.
6.32. Enlos diagramas de estados, se representa un estado mediante un rectángulo con el

nombre del estado en su interior, pero también existe la posibilidad de representar los
estados con mayor detalle indicando para cada estado la acción de entrada (entry),
la acción de salida (exit) y la acción interna (do). Busca información sobre esta re-
presentación de los estados y explica en qué consiste cada uno de los elementos
indicados (entry, exit y do).

E (a)áA[(m] DiagramasUML - https://diagramasuml.com/
7 (Tutorial sobre diagramas UML con numerosos ejemplos)
[
E (m]i=:[0] UML-diagrams.org - https://www.uml-diagrams.org/
=*º','-. (Sitio web en inglés con información sobre todos los diagramas UML)
el E
E (m];:4(0] Diagrams.net - https://www.diagrams.net/

= - (Sitio web sobre la herramienta de modelado de código abierto app.diagrams.net)
mirror_mod.use y - True
mirror mod.use 7 = False
elif operation < "
i -add back the deselected mirror modifier object
modifier_ob.select
print("Selected”" + str(modifier_0b)) % modifier ob is the active ob
rref_ob. sal pa
Analizador de código, 140-146

Abstracción, 180 Arquitecto/a, 22
Acción, 186, 273, 276 Arquitectura del sistema, 22, 23, 239
Acoplamiento, 181 Artefacto, 185
Actividad, 186, 189 Aseguramiento de la calidad del software,
Diagramas de actividades, véase 17
Diagramas UML — de actividades Atributo, 190-193
Actor, 189, 239, Auditoría de configuración, 148
Administración
de la configuración del software, 17,
147 Bad smells, véase Malos olores
de la reutilización, 17 Bucles
del riesgo, 16 anidados, 91
Alianza Ágil, 35-36 concatenados, 92
ALU (unidad aritmético-lógica), véase Prueba de, véase Prueba de bucles,
Unidad aritmético-lógica (ALU) 91-92
Análisis, 15, 17-18, 34 simples, 91
Causal, 101-102
de riesgo, 28-29
de valores límite, 97-99 C, 8,61

estático del código fuente, 140 C++, 61, 181
estructurado, 31 Cabeza (HEAD), 149, 154, 159-160
orientado a objetos, 31 Cadenas de mensajes (message chains),
Analista, 22 129
ÍNDICE ALFABÉTICO INFORMÁTICA
Y COM
Cadenas definición-uso, cadenas DU, 92- fuente, 10-11, 13, 15, 19, 23, 48,
94 52-53
Caminos independientes, 86-87 objeto, 10-11, 48, 52
Cardinalidades, 194, 198-199, 201, 205, Colaboración, 183
211, 216-217, 228 Diagramas de, véase Diagramas UML
Casos de prueba, 81-82 — Diagramas de colaboración
Técnicas de diseño de, véase Comandos Git
Técnicas de diseño de casos de git add, 151
prueba git branch, 151
Casos de uso, 239-241 git checkout, 151, 160-161
Diagramas de, véase Diagramas de git clone, 151
casos de uso git commit, 151, 154-156, 158, 160
Descripción de un caso de uso, 241, git merge, 151, 161-162
244-247 git pull, 151
Ciclo de vida, 24, 30 git push, 151, 154, 158, 160, 162
clásico o modelo en cascada, 24-25 Comentarios, 5, 6, 19
de construcción de prototipos, 27-28 en Java, véase Comentarios en Java
Definición, 24 Comentarios de documentación JavaDoc,
en espiral, 28-30 168-172
en V, 84-85 Etiqueta Gauthor, 169
evolutivo, 27-30 Etiqueta Eparam, 169
incremental, 26 Etiqueta Ereturn, 169
Cirugía a tiros (shotgun surgery), 128 Etiqueta Osee, 169
Clase, 182, 190-192 Etiqueta Qsince, 169
activa, 184 Etiqueta Oversion, 169
asociativa, 201-205 Comentarios en Java, 168-172
de control, 206, 253, 258 de JavaDoc, véase Comentarios de
de entidad, 206, 253, 258 documentación JavaDoc
de interfaz, 206, 253, 258 de línea, 168
Diagramas de clases, véase de varias líneas, 168
Diagramas de clases Compilador, 4, 10-11, 48, 52
Clase demasiado simple (freeloader), 128 javac, 13, 49, 50
Clase hija, véase Subclase Complejidad artificial (contrived complexity),
Clase larga (large class), 128 128
Clase padre, véase Superclase Complejidad ciclomática de McCabe, 86-87,
Clases de equivalencia, 94-97 89-90, 129, 141
Cobertura, 99, 101 Componente, 184, 188
de instrucciones, 117 Comportamiento
de las pruebas, 115-117 de un objeto, 9
de métodos, 117 Diagramas de, véase Diagramas de
de ramas, 117 comportamiento
Código Condición de entrada, 94-95

bytecode, 10, 13 Configuración del software, 147
divergente (divergent code), 128 Conjetura de errores, 99
duplicado, 127, 128, 146 Conjunto DEF, 92-93
ejecutable, 10-11, 48, 52 Conjunto USO, 92-93
! COMUNICACIONES ÍNDICE ALFABÉTICO
Constructor de interfaz gráfica, 52 Diagramas de clases, 18, 180, 182, 188,

Control de cambios, 34, 148, 149-162 190-228
Control de versiones, 49, 52, 146-162 Relaciones entre clases, véase
Herramientas de, véase Herramientas Relaciones entre clases
de control de versiones Diagramas de colaboración, 259-261,
CPD (Cut and Paste Detector), 145-146 269
CPU (unidad central de proceso), véase Herramientas para la elaboración de,
Unidad central de proceso (CPU) véase diagrams.net — Crear diagramas
Criterios de aceptación, 84 de colaboración con, Papyrus SysML
Criterios de validación, 15, 84 en Eclipse — Crear diagramas de
colaboración con
D Diagramas de comportamiento, 189-190,
Delta, 149 238-277
Deltas directos, 149 Diagramas de estructuras, 8
Deltas inversos, 149 Diagramas de secuencia, 189, 190, 238,
Demasiados parámetros (too many 252-259
parameters), 129 Línea de vida, 252, 261, 262
Dependencia en existencia, 195 Herramientas para la elaboración
Depuración, 21, 49, 52, 80, 82, 102-107 de, véase diagrams.net — Crear
Depurador (debugger), 52, 102 diagramas de secuencia con, Papyrus
Herramientas de, 102-107 SysML en Eclipse — Crear diagramas
Desarrollo conjunto de aplicaciones (JAD), de secuencia con
18 Diagramas estructurales, 188-189, 238
Desarrollo convencional, 31, véase tb. Diagramas UML
Software convencional, véase tb. de actividades, 276-277
Paradigma estructurado de casos de uso, véase Diagramas de
Despliegue, 27-28, 185, 239 casos de uso
Diagramas de, véase Diagramas UML de clases, véase Diagramas de
— Diagramas de despliegue clases
Detector de código duplicado, véase CPD de colaboración, véase Diagramas de
(Cut and Paste Detector) colaboración
Diagramas de casos de uso, 18, 32, 189, de componentes, 188, 189
238, 239-251 de comportamiento, véase Diagramas
Actor, véase Actor de comportamiento
Casos de uso, véase Casos de uso de despliegue, 188
Herramientas para la elaboración de estados, 189, 238, 271-275
de, ¡véase diagrams.net — Crear de estructura compuesta, 189
diagramas de casos de uso con, de interacción, 189-190, 251-271
Papyrus SysML en Eclipse — Crear de paquetes, 188
diagramas de casos de uso con de perfiles, 189
Relación de comunicación, 240, 248,
de secuencia, véase Diagramas de

250 secuencia
Relación de extensión, 240, 248, 250 de tiempos, 190, 238
Relación de uso o inclusión, 240, 248, estructurales, véase Diagramas
250 estructurales
ÍNDICE ALFABÉTICO INFORMÁTIY CCAO
diagrams.net Patrones de refactorización en, véase
Crear diagramas de casos de uso Patrones de refactorización en
con, 247-249 Eclipse
Crear diagramas de clases con, 207- Editor de textos, 11, 13, 50, 52
212 Ejecución paso a paso, 102, 103
Crear diagramas de colaboración con, Elemento de configuración (EC), 147, 148
269 Encapsulamiento, 139, 180, 181
Crear diagramas de secuencia con, Encargado/a de despliegue, 23
261-262 Enlazador, 11, 48
Diseñador/a, 23 Ensamblador, 6-7
Diseño, 15, 16, 18, 19, 21, 22, 23, 31, Entorno
38, 127, 164-165, 186, 188, 225, de desarrollo (IDE), 11, 13, 48-78
226 de programación, 49
Estructurado, 31, Entrevista, 18
orientado a objetos, 31, 181
Envidia de funcionalidad (feature envy),
Documentación, 13, 35, 83, 163-172
128
de la ejecución de las pruebas,
Especialización, 197, 198
100-101, 166-167
Especificación
de las pruebas, 100-102, 165-167
de casos de prueba, 101, 166
del código fuente, 168-172
de requisitos del software (ERS),
del diseño, 164-165
18-19, 24, 84, 163-164
del diseño de las pruebas, 100-101,
del diseño de las pruebas, 100-101,
165-166
165-166
Especificación de requisitos del
del procedimiento de prueba, 100-
software (ERS), véase
101, 166
Especificación de requisitos del
Estado
software (ERS)
de un objeto, 9
Generación automática de código,
168-172 Diagramas de estados, véase
JavaDoc, véase JavaDoc
Diagramas UML — Diagramas de
Manual de usuario, 163 estados
Estados de un archivo en Git, 150
E Confirmado (committed) , 150
Eclipse, Fuera de seguimiento (untracked),
Actualización de, 73 150
Creación de clases en, 57-58 Modificado (modified), 150
Creación de paquetes en, 57-58 Preparado para confirmación (staged),
Creación de proyectos en, 57 150
Desinstalación de módulos (plug-ins) Estructura de control, 5, 87
en, 69-71 Evento, 272-273
Edición de programas en, 59 Excepción, 104, 111-114, 116
Espacio de trabajo (workspace), 56-57 ArithmeticException, 114

Generación de ejecutables en, 59 Excesiva devolución (excessive returner),
Instalación de, 53-55 129
Instalación de módulos (plug-ins) en, Experto/a del dominio, 22
64-69 Explotación, 16, 21, 84
Y COMUNICACIONES ÍNDICE ALFABÉTICO
F Apache Subversion (SVN), 149

Flujo de control, 276-277 CvsS, 149
Framework, véase Software — Frameworks Git, véase Git
Función, 8 Historial de versiones, véase Git —
Historial de versiones
G Mercurial, 150
Generación de código a partir de Sistemas centralizados, 149
diagramas de clases, 221, 224-225 Sistemas distribuidos, 149-150
Generación de diagramas de clases a Herramientas para crear diagramas UML
partir de código, véase Ingeniería diagrams.net, véase diagrams.net
inversa Modelio, véase Modelio
Generalización, 197, 198, 212, 217 Papyrus, véase Papyrus SysML en
Gestión de la configuración del software Eclipse
(GCS), 146-162 Historia de usuario, 38
Git Histórico de pruebas, 100-101, 167
Área de preparación (staging area),
150-151, 154
Área de trabajo (working area) , IDE (Integrated Development Environment),
150-151, 154-156, 158, 160 véase Entorno — de desarrollo (IDE)
Cabeza (HEAD), véase Cabeza (HEAD) Informe de incidentes, 100-101
Comandos, véase Comandos Git Informe resumen de pruebas, 101, 167
Confirmación (commit), 150-151, 154,
Ingeniería
Estados de un archivo en, véase
Inversa, 225-228,
Estados de un archivo en Git
Ingeniería del software
Historial de versiones, 154-155
Definición, 14
Rama máster, véase Rama máster
Inspección de variables, 103, 105-107
Repositorio local, 150-152, 154-155,
Interacción, 185
160-161
Diagramas de, véase Diagramas UML
Repositorio remoto, 150-151, 154-
— Diagramas de interacción
162,
Interface, 206
Tronco, véase Tronco
Interfaz, 132, 181-183, 206
GitHub
Interfaz gráfica de usuario (GUI), 51-52,
Identificador de acceso personal,
157-158 65-68
Grafo de flujo, 86-87 Intérprete, 11, 48, 52
Grupo de datos (data clump), 128 Intimidad inapropiada (inappropriate
GUI (graphical user interface), véase intimacy), 128
Interfaz gráfica de usuario
J
H Java
Hardware, 2-5, 7, 12, 188 Compilador de, véase Compilador
Herencia, 181, 198 javac

Múltiple, 206 Entorno en tiempo de ejecución de
Herramienta CASE, 31 (JRE), 12, 49-50
Herramientas de control de versiones, Equipo de desarrollo de (JDK), 49-50,
147, 149-162 53-54, 171,
ÍNDICE ALFABÉTICO IN F O R M Á T Y
I C
C O
A M
Máquina virtual de (JVM), véase de sistema, 11-12
Máquina virtual de Java (JVM) Marcado selectivo, 149
JavaDoc, 168-172 Memoria
Comentarios de, 168-172 principal o RAM, 3-4, 11
JDK (Java Development Kit), véase Java — secundaria, 3
Equipo de desarrollo de (JDK) Mensaje, 9, 31, 180, 185, 189
Jefe/a de proyecto, 22 Método, 9, 19, 82, 106-107
Jerarquía, 128, 197-198, 205 assertEquals, 109-110
JRE (Java Runtime Environment), véase de ingeniería del software, 31
Java — Entorno en tiempo de ejecución de prueba, 109-111
de (JRE) largo (long method), 129
JUnit, 107-117 Metodología
Anotación QAfterAll, 113 de desarrollo de software, 30-40
Anotación GAfterEach, 112 estructurada, 7-9, 31
Anotación EBeforeAll, 113, 115 orientada a objetos, 9, 31
Anotación EBeforeEach, 112, 115 RUP (proceso unificado de Rational),
Crear una clase de prueba en, 108 véase RUP
JVM (Java Virtual Machine), véase Modelio
Máquina virtual de Java (JVM) Crear diagramas de clases con, 218-
224
L Generación de código a partir de
Legado rechazado (refused bequest), 128 diagramas de clases en, 224-225
Lenguaje Generación de diagramas de clases a
de bajo nivel o lenguaje máquina, 5-6, partir de código en, véase Modelio
10 — Ingeniería inversa en
de programación, 5-9 Ingeniería inversa en, 225-228
ensamblador, 6 Modelo
estructurado, 7, 9 de construcción de prototipos, 27-29
orientado a objetos, 8-9 de desarrollo ágil, 32, 35-40
unificado de modelado (UML), véase en cascada, 24-26, 28, 84
UML en espiral, 28-30
Línea de código excesivamente larga (God en V, 84-85
line), 129 evolutivo, 27-30
incremental, 26
Modificador de acceso, 191-192,
Malos olores, 127-129, 130 package, 192
Mantenimiento, 16, 19, 22, 126-127, private, 191-192
146, 163, 168 protected, 192
adaptativo, 22, 126 public, 192
correctivo, 22, 126-127 Modularidad, 181
perfectivo, 22, 126 Módulo, 7-8, 21

Máquina de estados, 185-186, 189 Módulo o plug-in, 64-72
Máquina virtual Desinstalación de, 69-72
de Java (JVM), 12-13, 49, 54 Instalación de, 64-69, 71-72
de proceso, 12 Multiplicidades, véase Cardinalidades
1Y COMUNICACIONES ÍNDICE ALFABÉTICO
Parámetro, 192-193
Navegabilidad, véase Relaciones entre Particiones o clases de equivalencia, 94-
clases — Navegabilidad 97, 99
NetBeans Patrones de refactorización en Eclipse,
Actualización de, 73 130-139
Creación de clases en, 58 Cambiar prototipo del método (change
Creación de paquetes en, 58 method signature), 133-134
Creación de proyectos en, 56-57 Convertir variable local en atributo
Desinstalación de módulos (plug-ins) (convert local variable to field),
en, 72 136-137
Edición de programas en, 59 Encapsular atributo (encapsulate
Generación de ejecutables en, 59-60 field), 138
Instalación de, 55-56 Extraer clase (extract class), 133
Instalación de módulos (plug-ins) en, Extraer constante (extract constant),
71-72 135-136
Nodo, 86, 185, 188 Extraer interfaz (extract interface), 132
Nota, 187 Extraer método (extract method),
137-138
(o) Extraer superclase (extract
Object Pascal, 181 superclass), 133
Objeto Extraer variable local (extract local
Comportamiento de un objeto, véase variable), 135
Comportamiento — de un objeto Inline, 134
Definición, 9 Introducir parámetro objeto (introduce
Estado de un objeto, véase Estado — parameter object), 134
de un objeto Mover (move), 132
Ocultamiento, 181 Pull down, 133
Orden de cambio, 148 Pull up, 133
Renombrar (rename), 131
P Usar supertipo donde sea posible
Papyrus SysML en Eclipse (use supertype where possible),
Crear diagramas de casos de uso 133
con, 249-251 Periférico, 3-4
Crear diagramas de clases con, 212- Plan
218 de proyecto, 16
Crear diagramas de colaboración con, de pruebas, 100-101, 165-166
270-271 Planificación, 16, 22, 27, 38
Crear diagramas de secuencia con, Plug-in, véase Módulo o plug-in
262-268 PMD (Programming Mistake Detector),
Instalación de, 69 141-146
Paquete, 187-197 Polimorfismo, 181
Anidamiento, 186-187 Procedimiento, 8

Paradigma de ingeniería del software, 30-31
estructurado, 7-8, 31, 82 de prueba, 100, 166
orientado a objetos, 8-9, 31-32, 82, Proceso software, 15
180-181 Probador/a, 23
ÍNDICE ALFABÉTICO INFORMÁTIY CCAO
Producto Equipo de pruebas independiente, 81
final, 29-30 Estrategia de aplicación de las,
intermedio, 30, 33 99-100
Programación estructurales, véase Pruebas — de
extrema (XP) caja blanca
por parejas Filosofía de las, 80-82
Programador/a, 23 funcionales, véase Pruebas — de caja
Prototipo negra
Desarrollo de un, 18 unitarias, 15, 82, 107, 130
Modelo de construcción de un, Puntos de ruptura, 52, 102-106
véase Modelo — de construcción
de prototipos R
Pruebas, 15-16, 20-21, 23, 79-124 Rama, 149, 151,
automáticas, 107-117 Fusionar ramas, 161-162
basadas en hebra, 83 máster, 152-154
basadas en uso, 83 principal, véase Rama — máster
de análisis de valores límite, véase Tronco, véase Rama — máster
Análisis de valores límite Recolección de basura, 181
de aceptación, 84-85 Refactorización, 37-38, 126-140
de bucles, 91-92 a posteriori, 129
de caja blanca, 21, 85-94, 99-100 continua, 129-130
de caja de cristal, véase Pruebas — de Histórico de refactorizaciones,
caja blanca 139-140
de caja negra, 21, 85, 94-100 Implantación de la, 129-130
de configuración, 84 Patrones de, 130-139
de conjetura de errores, véase Refactorizar (significado), 127
Conjetura de errores Relaciones entre clases, 193-206
de despliegue, 84 Agregación, 193-195
de esfuerzo, 84 Asociación, 198-205
de flujo de datos, 92-94, 99 binarias, 198-203
de integración, 15, 38, 83, 99 Composición, 195-197
de particiones o clases de cuaternarias, 198
equivalencia, véase Particiones o Generalización y especialización,
clases de equivalencia 197-198
de recuperación, 83 Grado de una relación, 198
de regresión, 102 Navegabilidad, 199-201
de rendimiento, 84 Realización, 206
de ruta básica, véase Pruebas del reflexivas, 198-199, 204-205
camino básico ternarias, 201, 203-204
de seguridad, 83 Repositorio (significado), 147-148
de unidad, véase Pruebas unitarias local, 149-151
de validación, 84-85 remoto, 149-151, 155-158

del camino básico, 86-91 Requisito funcional, 17, 19, 21, 34, 83-
del sistema, 83-84, 99 84, 94
del software, véase Pruebas Revisión de código, 141
DU, véase Prueba de flujo de datos Revisión técnica, 17, 148
A Y COMUNICACIONES ÍNDICE ALFABÉTICO
RUP (proceso unificado de Rational), 32- Técnicas

35, 239 de ingeniería del software, 30
Actividad, 33 de diseño de casos de prueba, 81,
Modelado del negocio, 34 85-100
Perfil o rol (worker), 33 Tipos de datos, 192
Producto intermedio (artifact), 33 Transición, 185, 189, 272
Transparencia, 39
S Trazabilidad, 239
Sangrado del código, 19, Tronco, véase Rama — máster
Scrum, 39-40
Retrospectiva, 39 U
Sprint, 37, 39,40 UML
Sprint planning, 39
Diagramas, véase Diagramas UML
Sprint review, 39, 40
Elementos de agrupación, 186-187
Secuencia
Elementos de anotación, 187
Diagramas de, véase Diagramas de
Elementos de comportamiento,
secuencia
185-186
Seguimiento del proyecto, 16, 22
Elementos estructurales, 182-185
Software
Unidad aritmético-lógica (ALU), 2-3
convencional o estructurado, 82,
Unidad central de proceso (CPU), 2-3
véase tb. Desarrollo convencional
Unidad de control (UC), 2-4
de aplicación, 4
Unidad de entrada/ salida, 3
de código abierto, 53
de código cerrado, 53
de programación o de desarrollo, 4 '
de sistemas, 4 Validación, 21, 81, 84-85
Definición, 2 Valoración del proceso de prueba,
Frameworks, 187, 189 101-102
Tipos de, 4 Verificación, 21, 81
Subclase, 181, 197-198 Versión,
Superclase, 181, 197-198 Control de versiones, véase Control
Swing, 65 de versiones
Principal, 147-148
T Visibilidad, 191-192
Tamaño del identificador (identifier size),
129 w
Tarea, 30 WindowBuilder, 65-68
mirror_mod.use y - True
mirror_mod.use 7 = False
elif operation < .
j -add back the deselected mirror modifier object

print(“Selected” + str(modifier_0b)) * modifier ob is the active ob
o 0sl p
Alonso, F.; Martínez, L.; Segovia, F.J. (2005) — (2008) IEEE Standard for Software
Introducción a la ingeniería del softwa- and System Test Documentation, IEEE
re: Modelo de desarrollo de programas. Std 829-2008. IEEE, Nueva York. doi:
Delta Publicaciones, Madrid. 10.1109/1EEESTD.2008.4578383.
Coad, P.; Yourdon, E. (1991) Object-Orien- — (2009) IEEE Standard for Informa-
ted Design. Prentice-Hall, Nueva York. tion Technology —Systems Design—
Cuevas, G. (coord.); De Amescua, A.; San Software Design Description, IEEE STD
Feliú, T.; Arcilla, M.; Cerrada J.A.; Cal- 1016-2009. IEEE, Nueva York. doi:
vo-Manzano, J.A.; García, M. (2003) 10.1109/1EEESTD.2009.5167255.
Gestión del proceso software. Centro Kruchten, P. (2000) The Rational Unified
de Estudios Ramón Areces, Madrid. Process: An Introduction, 2.* edición.
Fowler, M. (2018) Refactoring: Improving Addison Wesley Longman, Inc., Bos-
the design of existing code, 2.* edición. ton.
The Addison Wesley Signature Se- Maddison, R.N. (1983) Information System
ries, Addison-Wesley, Reading (Mass., Methodologies. Wiley Henden.
EE. UU.). Piattini, M.; Calvo-Manzano, J.A.; Cervera,
IEEE (Institute of Electrical and Electronics J.; Fernández, L. (2007) Análisis y dise-
Engineers) (1998) IEEE Recommended ño detallado de aplicaciones informáti-
Practice for Software Requirements cas de gestión. Ed. Ra-ma, Madrid.
Specifications, IEEE Std 830-1998. Pressman, R.S. (2010) Ingeniería del
IEEE, Nueva York. doi: 10.1109/ software: Un enfoque práctico, 7 .* edi-

IEEESTD.1998.88286. ción. McGraw-Hill.
Entornos de desarrollo
El desarrollo de software es una actividad que requiere
cada vez de más personal especializado.
Este libro desarrolla los contenidos del módulo profesional de Entornos de desarrollo, de
los Ciclos Formativos de grado superior en Desarrollo de Aplicaciones Web y Desarrollo
de Aplicaciones Multiplataforma, pertenecientes a la familia profesional de Informática
y Comunicaciones.
Se aborda, desde un punto de vista práctico, el empleo de entornos de desarrollo, como
herramientas esenciales para la creación de programas, así como las tareas de desarrollo
de software previas a la programación (análisis y diseño) y posteriores a esta, como la
optimización del código y las pruebas.
Entre los principales contenidos del libro, cabe destacar los siguientes:
* El proceso de desarrollo de software orientado a objetos.
* Lainstalación y el uso de entornos de desarrollo (Eclipse y NetBeans).
* Laoptimización del código, mediante la refactorización, el empleo de analizadores de
código (PMD) y herramientas para el control de versiones (Git).
* Las pruebas, que tienen por objetivo mejorar la calidad del software, comprobandosi
este funciona correctamente y realiza las funciones encomendadas por el cliente.
* El análisis y el diseño orientado a objetos, que requieren la elaboración de diagramas
UML, como diagramas de clases, de casos de uso y de interacción, entre otros.
El autor, José Manuel Piñeiro Gómez, es ingeniero en Informática y máster en la Socie-

dad de la información y el conocimiento. Ejerce como profesor de Enseñanza Secundaria
en la especialidad de Informática y como profesor colaborador en los estudios de Infor-
mática, Multimedia y Telecomunicación en la Universitat Oberta de Catalunya. Tiene una
amplia experiencia docente, tanto en la Formación Profesional como en el ámbito uni-
versitario y ha publicado varias obras relacionadas con las bases de datos y el desarrollo
de software.
RECURSOS PARA EL PROFESORADO
7 Programación de aula 7 Presentación de aula

7 Solucionario 7 Materiales y documentación extra
7 Examina 7 LDP (Libro Digital Proyectable)
Estos recursos son exclusivos para el profesorado que confirme con nuestro Departamento de Promoción
la adopción de este título como libro de texto en el aula.
ISBN: 978-84-1366-524-5
También en
Paraninfo J
Ebook
ciclos formativos
9 788413 665245
www.paraninfo.es

Libro Entornos de Desarrollo Ed. Paraninfo

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Libro Entornos de Desarrollo Ed. Paraninfo

Cargado por

Copyright:

Formatos disponibles

DESARROLLO DE APLICACIONES WEB

COPYRIGHT O 2022 Ediciones Paraninfo, SA Impreso en España /Printed in Spain

Gran cantidad de actividades propuestas y resueltas.

Proyecto figuras para la aplicación de patrones

bpy . context.scene.objects.active = modifier_ob

- 1 Desarr0||0 de SomNare ..... 1 1.8.1. Modelo en cascada.... 24

de pruebas............. 79 deen refactorización

de prueba .........oeeee.. 85 de los documentos ... 163

5, Elaboración de diagramas 5.8. Generación de diagramas

Una de las etapas fundamentales del desarrollo de software es la de programación, ta-

M 1.1.El software y su relación con otras partes

En cualquier caso, se hace referencia a los programas que se ejecutan en un ordenador

Para comprender un poco mejor el concepto de software, es necesario hacer referencia

E Unidad aritmético-lIógica (ALU): ejecuta las operaciones aritméticas y lógicas en-

sultado de dichas operaciones, siguiendo las órdenes de la unidad de control.

E Unidad de control (UC): recoge las instrucciones contenidas en la memoria

E Registros: constituyen el almacenamiento interno de la CPU e intervienen en la

3. Unidad de entrada/salida: permite la comunicación del ordenador con el exterior,

E De entrada: proporcionan al ordenador datos e instrucciones. Ejemplos: tecla-

E De salida: muestran información al exterior, es decir, al usuario del ordenador.

E De entrada/salida: proporcionan información al ordenador y envían información

PERIFÉRICO PERIFÉRICO PERIFÉRICO ;5 E:5'FF?Á%2/

Existen distintos tipos de software en función de su uso:

E Software de sistemas: se trata de programas que permiten el uso de un ordenador,

E Software de programación o desarrollo: posibilita la creación de programas. Los

Actividad propuesta 1.1

Procesador de textos Periférico de entrada

Ratón Periférico de entrada/ salida

M 1.2. Lenguajes de programación. Tipos

Los elementos básicos de los lenguajes de programación son los siguientes:

E Identificadores: nombres simbólicos que se dan a ciertos elementos de programa-

E Constantes: datos que no cambian su valor a lo largo del programa.

E Operadores: símbolos que representan operaciones entre variables, constantes y

E Instrucciones: símbolos especiales que representan estructuras de procesamiento

E Comentarios: texto que se usa para documentar los programas.

Como se indicó anteriormente, se puede realizar una clasificación de los lenguajes de

E Lenguajes de bajo nivel o lenguajes máquina: el lenguaje máquina es el único lengua-

E Lenguajes intermedios o lenguajes ensambladores: con estos lenguajes ya no se

LENGUAJE ENSAMBLADOR LENGUAJE MÁQUINA

ADD CL, AL 0001 1001 0100 1101

— Las instrucciones se expresan por medio de caracteres alfanuméricos, numéri-

cilita enormemente la labor de programación.

— Pueden incluirse líneas de comentarios.

— Disponen de instrucciones muy potentes de tipo aritmético, lógicas, de trata-

— El tiempo de codificación y puesta a punto de los programas es mucho menor

— Resultan más fáciles de corregir y modificar, lo que conlleva un gran ahorro de

— La curva de aprendizaje de las personas responsables de la programación es

— Los programas escritos en estos lenguajes no pueden ejecutarse directamente,

— La ocupación de memoria se incrementa, tanto por el traductor como por el pro-

— La eficiencia en el consumo de recursos y las prestaciones conseguidas son

Figura 1.3. Nombres de algunos lenguajes de programación de alto nivel.

Los lenguajes de programación estructurados se caracterizan por el empleo exclusivo

alternativa y la repetitiva. Además, en la metodología estructurada, para la que se em-

La arquitectura de una aplicación informática consta de un módulo de control principal

En la metodología estructurada, la atención se centra en los procesos o tareas que de-

Son ejemplos de lenguajes de programación estructurados: Pascal, C, COBOL.

M El estado de un objeto viene determinado por el conjunto de propiedades o atributos

E El comportamiento de un objeto está determinado por la manera en que actúa al

Algunos ejemplos de lenguajes orientados a objetos son Java, C1 y C++.

Actividad propuesta 1.2

Investiga si los siguientes lenguajes de programación son estructurados u orienta-

M 1.3. Código fuente, código objeto y código ejecutable.

2. Intérpretes. A diferencia de lo que ocurre con los compiladores, estos simulta-

En el caso del lenguaje Java, se combinan la compilación y la interpretación: el progra-