Requerimientos

de la
implementación

Análisis de
Sistemas

1
Requerimientos de la
implementación
Así como en el análisis se estudiaron los requisitos especiales, luego
corresponde estudiar e identificar los mecanismos genéricos de diseño e
implementación referidos a:

 Persistencia
 Distribución de objetos
 Características de seguridad, detección y reparación de errores
 Gestión de transacciones

Y se decide cómo tratarlos en función de las tecnologías de diseño e

implementación disponibles, como por ejemplo se muestra en los siguientes
cuadros.

Fuente: Object-Oriented Design - Module 5: Identify Design Mechanisms, 2001, Rational Software
(Curso “Diseño Orientado a Objetos” – dictado por Baufest SA asociado de negocios de IBM, abril de
2004, Buenos Aires)

Significado de las Siglas: RDBMS (Sistema de Administración de Bases de

Datos Relacionales), OODBMS (Sistema de Administración de Bases de Datos
Orientadas a Objetos), RMI (Invocación a Métodos Remotos), CORBA
(Arquitectura Común de Agente de Solicitud de Objetos), JDBC (Conectividad
a Bases de Datos con Java)

El trabajo de diseño anterior no debería implicar que no exista prototipado

o diseño durante la implementación (codificación / programación); las
herramientas de desarrollo modernas proporcionan un entorno muy bueno

2
para explorar rápidamente enfoques alternativos y normalmente merece la
pena elaborar algo de diseño mientras se programa.

Durante el trabajo de diseño se tomaron algunas decisiones y se llevó a cabo

un trabajo creativo. Sin embargo, generalmente el trabajo de programación
no es una etapa de generación de código trivial. En realidad, los resultados
generados durante el diseño son un primer paso incompleto; durante la
programación y pruebas se realizarán innumerables cambios y se
descubrirán y resolverán problemas complicados.

Propósitos de la Implementación

En la implementación comenzamos con el resultado del diseño e

implementamos el sistema en términos de componentes (archivos de código
fuente, ejecutables, librerías y otros, como veremos más adelante)

La mayor parte de la arquitectura del sistema ya fue capturada durante el

diseño, siendo el propósito principal de la Implementación desarrollar la
arquitectura y el sistema como un todo.

De forma más específica los propósitos de la implementación, tal como lo

presentan los creadores del PUD son (Jacobson I, Booch G., Rumbaugh J.,
1999, pág. 255).

 Planificar las integraciones de sistemas necesarias en cada iteración.

 Asignar artefactos ejecutables a nodos en el diagrama de despliegue,
realizando así la distribución de la funcionalidad del sistema.
 Implementar las clases y subsistemas de diseño.
 Probar los componentes individualmente, para luego integrarlos,
compilarlos y enlazarlos en uno o más ejecutables.

La ubicación de los trabajos de Implementación en el Proceso Unificado de

Desarrollo es la que se destaca en la figura siguiente:

3
Fuente: Libro “El Proceso Unificado de Desarrollo de Software” – Ivar Jacobson y otros, 2000, pág.
11.

Durante la fase de Elaboración se hace Implementación para crear la línea

base ejecutable de la arquitectura.

En la fase de Construcción se realiza la actividad fuerte de la implementación

y durante la Transición se tratan defectos tardíos.

Flujo de Trabajo de Implementación

Para describir el flujo de trabajo de implementación se enumeran los
artefactos creados en este flujo de trabajo, los trabajadores participantes y
las actividades a realizar:

 Artefactos: Los artefactos fundamentales que se producen en la

implementación son:

o Modelo de implementación.
o Componente.
o Subsistema de implementación.
o Interfaz.
o Modelo de despliegue.
o Descripción de la arquitectura (vista del modelo de
implementación).
o Plan de integración de construcciones.

4
 Trabajadores: Los trabajadores responsables por los artefactos que se
producen en el modelo de implementación son:

o Arquitecto
o Ingeniero de componentes
o Integrador de sistemas

 Actividades: Las actividades a realizar por los trabajadores para producir

los distintos artefactos son:

o Implementar de la arquitectura.
o Integrar el sistema.
o Implementar un subsistema.
o Implementar una clase.
o Realizar prueba de unidad.

El siguiente gráfico muestra la relación entre los artefactos de la

implementación y los trabajadores responsables de cada uno:

Fuente: Libro “El Proceso Unificado de Desarrollo de Software” Ivar Jacobson y otros, 2000, Pág. 256

A continuación se muestra un gráfico que indica el flujo de trabajo para la

actividad de implementación, que relaciona los trabajadores participantes
con sus actividades, poniendo de manifiesto la secuencia de éstas:

5
Fuente: Libro “El Proceso Unificado de Desarrollo de Software” Ivar Jacobson y otros, 2000, Pág.
267.

Artefactos del Flujo de Trabajo de Implementación

Mencionaremos brevemente el concepto de cada uno de los artefactos que
se obtienen como resultado del Flujo de Trabajo de Implementación.

Modelo de Implementación
El modelo de implementación describe cómo los elementos del diseño se
implementan en términos de componentes. También describe cómo se
organizan los componentes de acuerdo con los mecanismos de
estructuración y modularización disponibles en el entorno de
implementación y en e/los lenguajes de programación utilizados.

Descripción de la arquitectura (vista del modelo de

implementación)
Como siempre, la descripción de la arquitectura como vista del modelo de
implementación contiene los artefactos que son significativos para la
arquitectura en este modelo, esto es, la descomposición del modelo de
implementación en subsistemas, sus interfaces y dependencias entre ellos,

6
como también componentes claves, que siguen la traza de las clases de
diseño arquitectónicamente significativas.

Modelo de despliegue
El modelo de despliegue es un modelo de objetos que describe la
distribución física del sistema en cuanto a la distribución de la funcionalidad
entre los nodos de cómputo.

El modelo de despliegue puede describir diferentes configuraciones de red,

incluidas las configuraciones para pruebas y simulación.

La funcionalidad de un nodo se define por los componentes que se

distribuyen en ese nodo.

Plan de Integración de Construcciones

Es importante desarrollar el software en forma incremental, en pasos
manejables. El resultado de cada paso es una versión ejecutable del sistema
al que se denomina “construcción”. Cada construcción es sometida a
pruebas de integración (como se describe más adelante).

Para estar preparado ante el fallo de una construcción se lleva un control de

versiones, de forma de poder volver atrás a una versión anterior.

Este enfoque de construcción incremental permite crear una versión

ejecutable del sistema muy pronto, de modo que las pruebas de integración
comienzan antes y se pueden realizar demostraciones de las características
del sistema a los participantes del proyecto.

Además es más fácil localizar defectos durante las pruebas de integración,

porque cada construcción sólo añade o refina una pequeña parte respecto
de la versión anterior.

El plan de integración de construcciones describe la secuencia de

construcciones necesarias en una iteración, definiendo para cada una de
ellas:

La funcionalidad que debe implementar (casos de uso o

escenarios, requisitos especiales)

Las partes afectadas por la construcción (subsistemas

y componentes necesarios para implementar la
funcionalidad).

7
Componente
Un componente es un empaquetamiento físico de los elementos de un
modelo, como las clases de diseño. Los componentes tienen las siguientes
características:

Los componentes tienen relaciones de traza con los

elementos de modelo que implementan.

Es normal que un componente implemente varios elementos,

por ejemplo varias clases, sin embargo la forma exacta en que
se crea esta traza depende de cómo van a ser estructurados
y modularizados los archivos de código fuente según el
lenguaje de programación que se esté utilizando.

Subsistema de Implementación
Los subsistemas de implementación constituyen una forma de organizar los
elementos del modelo de implementación en partes más manejables y
pueden estar compuestos por interfaces, componentes y otros subsistemas.

Un subsistema de implementación se manifiesta a través del mecanismo de

empaquetamiento que provea el entorno de implementación con el que se
está trabajando. Por ejemplo: un “paquete” en Java, un “proyecto” en Visual
Basic, un “directorio” de ficheros en C++.

Interfaz
Las mismas interfaces que se utilizaron en el modelo de diseño, pueden
utilizarse en el modelo de implementación para especificar operaciones
implementadas por componentes y subsistemas de implementación.

Identificación de subsistemas y
de sus interfaces
Obviamente los subsistemas de implementación están muy relacionados
con los subsistemas de diseño. La siguiente figura aclara la relación entre los
dos modelos:

8
Fuente: Libro “El Proceso Unificado de Desarrollo de Software” Ivar Jacobson y otros, 2000, pág. 261

Describimos a continuación las actividades del Flujo de Trabajo de

Implementación que nos llevarán a la obtención de los subsistemas e
interfaces de implementación.

Implementar la arquitectura
El objetivo de esta actividad es esbozar el modelo de implementación y su
arquitectura mediante la identificación de componentes significativos
arquitectónicamente, tales como componentes ejecutables, y asignar esos
componentes a los nodos en las configuraciones de redes relevantes.

Los desarrolladores deben tener cuidado de no identificar demasiados

componentes, ahondando en detalles triviales (como un componente por
cada clase).

Utilizando los modelos de diseño y de despliegue para identificar

componentes ejecutables, se puede examinar si hay objetos activos
asignados a nodos. Si esto se da, los componentes que siguen la traza de las
clases activas correspondientes deberían ser desplegados sobre los mismos
nodos.

Para modelar que un componente se “despliega” en un determinado nodo,

lo mostramos así:

9
Esto significa que el componente ejecutable inscripción.exe se ejecuta, y por
lo tanto debe estar instalado (junto a los componentes con los que tenga
dependencia) en el nodo Bedelía 1.

Integrar el sistema
Durante esta actividad se procederá a crear un plan de integración de
construcciones que describa las construcciones necesarias en una iteración

y los requisitos de cada construcción, y luego se integrará cada construcción

antes de que sea sometida a la prueba de integración.

Una construcción, que es una versión ejecutable del sistema producto de la

iteración actual, debe tener en cuenta las siguientes recomendaciones:

 Debe añadir funcionalidad a la construcción previa implementando

casos de uso completos o escenarios de éstos.
 No debe incluir demasiados componentes nuevos o refinados.
 Debe basarse en la construcción anterior y expandirse hacia arriba y
hacia los lados en la jerarquía de subsistemas.

Por cada caso de uso que va a ser implementado se debe:

 Identificar su realización de caso de uso-diseño

 Identificar los subsistemas y clases de diseño que participan en ella.
 Identificar subsistemas y componentes de implementación que siguen la
traza de los subsistemas y clases de diseño. Estos serán los subsistemas
y componentes necesarios para implementar el caso de uso.
 Considerar el impacto de implementar los requisitos de estos
subsistemas de implementación y de los componentes sobre la
construcción en cuestión. Si este impacto es aceptable, se procede a
planificar la implementación del caso de uso en la construcción, de lo
contrario se deja para una construcción posterior.

10
Si la construcción fue planificada correctamente, su integración será tarea
fácil. Se procede recopilando las versiones correctas de los subsistemas de
implementación y de los componentes, se los compila y enlaza, generando
así la construcción.

Implementar un subsistema

Esta actividad se realiza para asegurar que un subsistema cumple su papel

en cada construcción, tal como se especifica en el plan de integración.

Esto quiere decir, asegurarse que los requisitos (por ejemplo, escenarios de
casos de uso) implementados en la construcción y los que afectan al
subsistema son implementados correctamente por componentes o por
otros subsistemas dentro del subsistema con el que se está trabajando.

Implementar una clase

Una clase de diseño se implementa en un componente file (fichero o
archivo). Esto incluye las siguientes tareas:

 Esbozar un componente fichero que contendrá el código fuente.

 Generar el código fuente a partir de la clase de diseño y de las
relaciones en las que participa.
 Implementar las operaciones de la clase en forma de métodos.
 Comprobar que el componente proporciona las mismas interfaces que
la clase de diseño.

Realizar pruebas de unidad

El propósito de esta actividad es probar los componentes implementados
como unidades individuales. Se llevan a cabo dos tipos de pruebas de
unidad:

 La prueba de especificación o de “caja negra”, que verifica el

comportamiento de la unidad observable externamente. Es decir, si se
proporcionan ciertas entradas, verificar las salidas sin importar lo que
ocurre en el proceso intermedio.

 La prueba de estructura o de “caja blanca”, que verifica la

implementación interna de la unidad. En estas pruebas el ingeniero de
componentes debe asegurarse que son probados todos los caminos
posibles en el código fuente.

11
Orden de Implementación
Es necesario implementar las clases y subsistemas, e idealmente realizar las
pruebas de unidad completamente, desde los menos a los más acoplados.

En la siguiente figura veremos, dada la relación dependencia existente entre

los subsistemas cuál sería el orden aconsejado para comenzar a
implementar los mismos. Éste será un punto importante a tener en cuenta
por el Arquitecto cuando determina los elementos significativos a incluir en
la Descripción de la Arquitectura correspondiente a la iteración actual, y
también será de utilidad para el Integrador de Sistemas cuando planifica la
construcción actual.

Identificación de nodos y
configuración de redes
Durante esta actividad, los arquitectos consideran distintas posibilidades de
reutilización, ya sea de partes de sistemas parecidos o productos de
software generales.

Comprende las siguientes tareas:

 Identificar nodos y configuraciones de red

 Identificar subsistemas e interfaces
 Identificar clases de diseño relevantes para la arquitectura
 Identificar mecanismos genéricos de diseño

Identificar nodos y configuraciones de red

La configuración física de la red que se necesitará tiene mucha influencia
sobre la arquitectura de software.

12
Es muy común una configuración cliente/servidor en tres capas: una capa
para el cliente, otra para la funcionalidad de la base de datos y una tercera
la aplicación o lógica del negocio.

Una versión más simple es la arquitectura cliente/servidor de dos capas en

las que la lógica del negocio se mueve hacia alguna de las otras dos capa.

Para poder armar la configuración física de la red hay que determinar

primero, lo siguiente:

 Nodos que se necesitarán y capacidad de cada uno (potencia de

procesador, tamaño de memoria).
 Tipos de conexiones entre los nodos, protocolos de comunicación.
 Características de las conexiones y protocolos en cuando a ancho de
banda, disponibilidad, calidad.
 Necesidad de disponer de procesos tales como modo de fallos,
migración de procesos, copias de seguridad de datos y otros.

Un nodo es un elemento físico que existe en tiempo de ejecución y

representa un recurso de cómputo que, generalmente, tiene alguna
memoria y, normalmente, capacidad de procesamiento.

Gráficamente un nodo se representa por un cubo.

Los nodos se utilizan para modelar la topología del hardware sobre el que se
ejecuta el sistema.

Un nodo representa normalmente un procesador o un dispositivo de

hardware similar sobre el que se pueden desplegar los artefactos.

La funcionalidad de un nodo se define por los artefactos que se distribuyen

en ese nodo.

13
Los nodos poseen relaciones, conexiones, que representan medios de
comunicación entre ellos, tales como Internet, Intranet, bus y similares. Esta
relación se grafica mediante una asociación.

En este contexto una asociación representa una conexión física entre los
nodos.

Los nodos también se pueden organizar especificando relaciones de

generalización y dependencia, además de la asociación.

Los nodos se pueden organizar agrupándolos en paquetes.

Modelo de arquitectura
Los sistemas grandes siempre se descomponen en subsistemas que
suministran algún conjunto relacionado de servicios.

El proceso de diseño inicial para identificar éstos subsistemas y establecer

un marco de trabajo para control y comunicación de los subsistemas se llama
Diseño Arquitectónico.

Roger Pressman, en su libro “Ingeniería de Software” nos presenta la

siguiente definición.

“La Arquitectura del Software de un sistema de cómputo es

la estructura o las estructuras del sistema que incluyen los
componentes del software, las propiedades visibles
externamente de esos componentes y las relaciones entre
ellos” (Pressman Roger, 2006, pág. 277).

La importancia de tener un modelo de la arquitectura radica en que:

 Permiten la comunicación entre todas las partes (participantes)

interesadas en el desarrollo de un sistema de cómputo.
 Destaca las decisiones iniciales relacionadas con el diseño que tendrán
impacto en todo el trabajo de ingeniería de software que sigue.
 Constituye un modelo relativamente pequeño e intelectualmente
comprensible de cómo está estructurado el sistema y cómo trabajan
juntos sus componentes.

Según nos los plantea David Ruble el modelo arquitectónico (1998, pág 200):

14
 Mapea los requerimientos esenciales de la fase de análisis hacia una
arquitectura tecnológica.
 Es la asignación de los modelos de requerimientos esenciales hacia una
tecnología específica.

El mismo autor, ha elaborado la siguiente lista de productos del modelado

arquitectónico que se obtienen al finalizar el esfuerzo de modelado
arquitectónico:

 La distribución geográfica de los requerimientos de cómputo.

 Los componentes de hardware para las máquinas cliente y servidores.
 Configuración y cantidad de niveles de hardware cliente/servidor.
 Los mecanismos y lenguajes de comunicación de red.
 Definición del sistema operativo, el paradigma de desarrollo, el lenguaje
de presentación, el lenguaje de codificación de fondo, el sistema de
administración de base de datos.
 La ubicación/es de los procesos.
 La ubicación/es de los datos físicos.
 Las estrategias de sincronización de los datos distribuidos físicamente.

Subsistema
Desde el punto de vista del modelado de la arquitectura, un Subsistema:

 Es un sistema por sí mismo cuya operación no depende de los servicios

suministrados por otros subsistemas.
 Se compone de módulos y tiene interfaces definidas que se utilizan para
la comunicación con otros subsistemas.

Módulo

Un módulo es un componente del sistema que suministra uno o más

servicios a otros módulos.

 Utiliza los servicios suministrados por otros módulos

 No se considera un sistema independiente
 Generalmente, los módulos están compuestos de varios componentes
simples del sistema.

15
Modelado de subsistemas de implementación
El siguiente gráfico muestra el modelado de los subsistemas de
implementación para el caso del Sistema de Comercialización de Discografía
que hemos venido desarrollando. El diagrama UML (Lenguaje Unificado de
Modelado) utilizado para confeccionar este modelo es el “Diagrama de
Componentes”.

16
Referencias
Booch Grady, Rumbaugh James, Jacobson Ivar (1999) “El lenguaje de
Modelado Unificado”, España, Addison Wesley Iberoamericana. Capítulos: 25,26,
29 y 30

Braude Eric (2003) “Ingeniería de Software, una perspectiva orientada a objetos”,

Alfaomega Grupo Editor SA. Capítulo: 8 y 9

Jacobson Ivar, Booch Grady, Rumbaugh James (2000) “El Proceso

Unificado de Desarrollo de Software”, España, Addison Wesley. Capítulos: 10 y 11
Larman Craig (2003) “UML y Patrones. Una introducción al análisis y diseño
orientado a objetos y al proceso unificado”, 2da. edición, España, Prentice Hall.
Capítulo: 20

Pressman Roger (2006) “Ingeniería de Software. Un enfoque práctico”

6ta. edición, McGraw Hill. Capítulos 10

Rubble David (1998) "Análisis y Diseño práctico de Sistemas Cliente/Servidor con

GUI". Prentice Hall. Capítulo: 8

Sommerville Ian (2002) “Ingeniería de Sofware”, Ed. Pearson Educación, México.

Capítulo: 10

17
 Diagrama de
despliegue y
Diagrama de
componentes

Análisis de
Sistemas

1
Diagrama de despliegue
Un diagrama de despliegue es un diagrama que muestra la configuración de
los nodos de procesamiento y de los artefactos que residen en ellos.

Gráficamente un diagrama de despliegue es una colección de nodos y arcos.

Normalmente contienen:
 Nodos
 Relaciones de dependencia y asociación

Ejemplos:

2
En las figuras anteriores se mostraban los nodos en forma de “instancia”; en
la figura siguiente mostramos los nodos en forma de “descriptor” y a su vez
se verá cómo pueden agruparse los nodos en paquetes para proporcionar
un diagrama de despliegue simplificado, en el que se indique solamente los
tipos de nodos y sus conexiones sin representar cada uno de ellos.

Ejemplo de diagrama de despliegue para el caso de la empresa de venta de

discografía que hemos desarrollados en los módulos de la materia:

3
Usos comunes del Diagrama de Despliegue
El diagrama de despliegue se puede utilizar:

 Para modelar sistemas embebidos

 Para modelar sistemas cliente/servidor
 Para modelar sistemas completamente distribuidos.

Diagrama de Despliegue para modelar sistemas embebidos

Un sistema embebido es una colección de hardware con gran cantidad de

software que interactúa con el mundo físico.

Los sistemas embebidos involucran software que controla dispositivos como

motores, actuadores y pantallas y que a su vez están controlados por

4
estímulos externos tales como entradas de sensores, movimientos y
cambios de temperatura.

Los diagramas de despliegue se pueden utilizar para modelar los dispositivos

y los procesadores que comprenden un sistema embebido.

Diagrama de Despliegue para modelar sistemas cliente/servidor

Un sistema cliente/servidor es una arquitectura muy difundida que se basa

en una clara separación de intereses entre la interfaz de usuario del sistema
(que reside en el cliente) y los datos persistentes del sistema (que residen
en el servidor).

Estos sistemas requieren tomar decisiones sobre la conectividad de red de

los clientes a los servidores y sobre la distribución física de los artefactos de
software.

Con los diagramas de despliegue modelamos la topología de tales sistemas.

Diagrama de Despliegue para sistemas distribuidos

En el otro extremo del espectro se encuentran aquellos que son

ampliamente, si no totalmente, distribuidos y que normalmente incluyen
varios niveles de servidores.

Tales sistemas contienen a menudo varias versiones de artefactos de

software algunos inclusos pueden migrar de un nodo a otro.

El diseño de estos sistemas requiere tomar decisiones que permitan un

cambio continuo de la topología.

Los diagramas de despliegue modelan la topología actual y permiten razonar

sobre el impacto de los cambios en esa topología.

Diagrama de componentes
Un componente es una parte física y reemplazable de un sistema que existe
a nivel de la plataforma de implementación.

Un componente es la implementación física de otros elementos lógicos

como clases y colaboraciones.

El símbolo UML para componente es el siguiente:

5
En la siguiente tabla se muestran algunos tipos (estereotipos) de
componentes.

Un diagrama de componentes modela un conjunto de componentes y sus

relaciones. Los diagramas de componentes contienen: componentes,
interfaces y relaciones (dependencia, generalización, asociación,
realización).

Usos comunes del diagrama de componentes:

Cuando se modela la vista de implementación estática de un sistema,

normalmente se utilizarán los diagramas de componentes de una de las
cuatro maneras siguientes:

1) Para modelar código fuente: Con la mayoría de los lenguajes de

programación orientados a objetos actuales, el código se produce
utilizando entornos integrados de desarrollo, que almacenan el
código fuente en archivos (.java por ejemplo). Los diagramas de

6
 componentes se pueden utilizar para modelar la gestión de las
configuraciones de estos archivos, los cuales representan los
componentes obtenidos como producto del trabajo.
Para modelar el código fuente de un sistema:
o Hay que identificar el conjunto de archivos de código fuente de
interés y modelarlos como componentes estereotipados como
archivos (file).
o En los sistemas más grandes, hay que utilizar paquetes para
mostrar los grupos de archivos de código fuente.
o Hay que considerar mostrar un valor etiquetado que indique
información como el número de versión, su autor y la fecha de la
última modificación.
o Hay que modelar las dependencias de compilación entre estos
archivos mediante dependencias.

Ejemplo:

2) Para modelar versiones ejecutables: Una versión es un conjunto de

artefactos relativamente consistentes y completos que se entrega a
un usuario. Cuando se modela una versión mediante diagramas de
componentes, se están visualizando, especificando y documentando
las decisiones acerca de las partes físicas que constituyen el
software.

7
 Para modelar una versión ejecutable:
o Hay que identificar el conjunto de componentes que se pretende
modelar. Normalmente esto implicará a alguno o todos los
componentes existentes en un nodo, o a la distribución de estos
conjuntos de componentes a través de todos los nodos del
sistema.
o Hay que considerar el estereotipo de cada componente de este
conjunto, tales como ejecutables, bibliotecas, tablas, archivos y
documentos. Los mecanismos de extensibilidad de pueden utilizar
para proporcionar señales visuales para estos estereotipos.
o Por cada componente de este conjunto hay que considerar sus
relaciones con los vecinos. La mayoría de las veces esto incluirá las
interfaces que son exportadas (realizadas) por ciertos
componentes e importadas (utilizadas) por otros.

Ejemplo:

3) Para modelar bases de datos físicas: Una base de datos física puede
ser vista como la realización concreta de un esquema. El modelo de
una base de datos física representa el almacenamiento de esa
información en las tablas de una base de datos relacional o las
páginas de una base de datos orientada a objetos.
Para modelar una base de datos física:
o Hay que identificar las clases del modelo que representan el
esquema lógico de la base de datos.
o Hay que seleccionar una estrategia para hacer corresponder estas
clases con tablas. También habrá que considerar la distribución
física de la base de datos.

8
 o Para visualizar, especificar, construir y documentar la
correspondencia, hay que crear un diagrama de componentes que
contenga componentes estereotipados como tablas.

Ejemplo:

4) Para modelar sistemas adaptables: Algunos sistemas son bastantes

estáticos: sus componentes entran en escena, participan en la
ejecución y desaparecen. Otros sistemas son más dinámicos, e
implican agentes móviles o componentes que migran con el
propósito de equilibrar la carga o la recuperación de fallos. Los
diagramas de componentes se utilizan junto a algunos de los
diagramas de UML, para modelar el comportamiento con el fin de
representar a estos tipos de sistemas.
Para modelar un sistema adaptable:
o Hay que considerar la distribución física de los componentes que
pueden migrar de un nodo a otro.
o Si se quiere modelar las acciones que hacen que migre un
componente, hay que crear el correspondiente diagrama de
interacción que contenga instancias de componentes.

9
Referencias
Booch Grady, Rumbaugh James, Jacobson Ivar (1999) “El lenguaje de
Modelado Unificado”, España, Addison Wesley Iberoamericana. Capítulos: 25,26,
29 y 30

Braude Eric (2003) “Ingeniería de Software, una perspectiva orientada a objetos”,

Alfaomega Grupo Editor SA. Capítulo: 8 y 9

Jacobson Ivar, Booch Grady, Rumbaugh James (2000) “El Proceso

Unificado de Desarrollo de Software”, España, Addison Wesley. Capítulos: 10 y 11
Larman Craig (2003) “UML y Patrones. Una introducción al análisis y diseño
orientado a objetos y al proceso unificado”, 2da. Edición, España, Prentice Hall.
Capítulo: 20

Pressman Roger (2006) “Ingeniería de Software. Un enfoque práctico”

6ta. edición, McGraw Hill. Capítulos 10

Rubble David (1998) "Análisis y Diseño práctico de Sistemas Cliente/Servidor con

GUI". Prentice Hall. Capítulo: 8

Sommerville Ian (2002) “Ingeniería de Sofware”, Ed. Pearson Educación, México.

Capítulo: 10

10
 Modelo de
prueba

Análisis de
Sistemas

1
El papel de la prueba en el ciclo
de vida del software
Propósito de las pruebas
El proceso de prueba, también llamado verificación y validación (V & V), es
el nombre que se le da a los proceso de comprobación y análisis que
aseguran que el software esté acorde con su especificación y cumpla las
necesidades de los clientes que pagaron por ese software.

La verificación y validación es un proceso de ciclo de vida completo. Inicia

con las revisiones de los requerimientos y continúa con las revisiones del
diseño y las inspecciones del código hasta la prueba del producto.

Existen actividades de V & V en cada etapa del proceso del software. Estas
actividades comprueban que los resultados de las tareas del proceso estén
acordes con lo especificado.

La verificación y la validación no son la misma cosa, aunque es muy fácil

confundirlas. Podemos expresar de manera sucinta la diferencia entre ellas
así:

Estas definiciones señalan que el papel de la verificación comprende

comprobar que el software esté de acuerdo con su especificación. Se
comprueba que el sistema cumple sus requerimientos funcionales y no
funcionales especificados.

La validación, sin embargo, es un proceso más general. Se debe asegurar que

el software cumple las expectativas del cliente. Va más allá de comprobar si

2
el sistema está acorde con su especificación para mostrar que el software
hace lo que el usuario espera a diferencia de lo que se ha especificado.

Dentro del proceso de V & V se utilizan dos técnicas de comprobación y

análisis de sistemas:

 Las inspecciones del software analizan y comprueban las

representaciones del sistema como el documento de requerimientos,
los diagramas de diseño y el código fuente del programa. Se aplican a
todas las etapas del proceso. Las inspecciones se complementan con
algún tipo de análisis automático del texto fuente de un sistema o con
documentos asociados. Las inspecciones del software y los análisis
automatizados son técnicas V & V estáticas puesto que no requieren
que el sistema se ejecute.

 Las pruebas del software comprenden llevar a cabo una

implementación del software con los datos de prueba y examinar las
salidas del software y su comportamiento operacional para comprobar
que se desempeñe conforme a lo requerido. Llevar a cabo las pruebas es
una técnica dinámica de la verificación y validación debido a que se
realizan en una representación ejecutable del sistema.

La meta fundamental del proceso de verificación y validación es generar la

confianza de que el sistema de software se “ajusta a los propósitos”.

Esto no significa que el programa deba estar libre de defectos. Más bien,
significa que el sistema debe ser suficientemente bueno para la utilización
que se pretende.

El nivel de confianza requerido depende de:

 El propósito del sistema

 Las expectativas de los usuarios del sistema
 El entorno actual de mercado para el sistema.

La Prueba en el PUD
Durante este flujo de trabajo se procederá a verificar el resultado de la
implementación probando cada construcción, tanto las intermedias como
las versiones finales del sistema.

Los objetivos de la prueba son:

3
 Planificar las pruebas necesarias en cada iteración (pruebas de
integración y de sistema).

 Diseñar e implementar las pruebas creando casos de prueba que

especifican qué probar, procedimientos de prueba que indican cómo
realizar las pruebas y de ser posible crear componentes automatizados
que realicen las pruebas.

 Realizar las pruebas y manejar los resultados de las mismas

sistemáticamente. Las construcciones en las que se detectan defectos
son probadas se nuevo y posiblemente devueltas al flujo de diseño o
implementación para que sean arregladas.

El siguiente gráfico muestra la ubicación del Flujo de Trabajo de Prueba en

el ciclo de vida del Proceso Unificado de Desarrollo.

Fuente: Libro “El Proceso Unificado de Desarrollo de Software” Ivar Jacobson y otros, 2000, pág. 11.

Durante la fase de inicio puede hacerse algo de la planificación de las

pruebas. Sin embargo las pruebas se llevan a cabo cuando una construcción
es sometida a las pruebas de integración y de sistema. Esto quiere decir que
las actividades de pruebas se centran en las fases de elaboración cuando se
prueba la línea base ejecutable del sistema, y en la fase de construcción
cuando el grueso del sistema está implementado.

4
Durante la fase de transición el centro de atención se desplaza hacia la
corrección de defectos durante los primeros usos del sistema y a las pruebas
de regresión.

Flujo de trabajo de prueba

Para describir el flujo de trabajo de prueba se enumeran los artefactos
creados en este flujo de trabajo, los trabajadores participantes y las
actividades a realizar:

 Artefactos: Los artefactos que se producen en la Prueba son:

o Modelo de pruebas.
o Caso de prueba.
o Procedimiento de prueba.
o Componente de prueba.
o Plan de prueba.
o Defecto.
o Evaluación de prueba.

 Trabajadores: Los trabajadores responsables por los artefactos que se

producen en el modelo de prueba son:

o Diseñador de pruebas
o Ingeniero de componentes.
o Ingeniero de pruebas de integración.
o Ingeniero de pruebas de sistema

 Actividades: Las actividades a realizar por los trabajadores para producir

los distintos artefactos son:

o Planificar la prueba.
o Diseñar prueba.
o Implementar prueba.
o Realizar pruebas de integración.
o Realizar prueba de sistema.
o Evaluar prueba.

El siguiente gráfico muestra la relación entre los artefactos de la Prueba y los

trabajadores responsables de cada uno:

5
Fuente: Libro “El Proceso Unificado de Desarrollo de Software” Ivar Jacobson y otros, 2000, pág.
282.

A continuación se muestra un gráfico que indica el flujo de trabajo para la

actividad de Prueba, que relaciona los trabajadores participantes con sus
actividades, poniendo de manifiesto la secuencia de éstas:

Fuente: Libro “El Proceso Unificado de Desarrollo de Software” Ivar Jacobson y otros, 2000, pág.
290.

6
Modelo de prueba
El Modelo de Prueba es un modelo que describe principalmente cómo se
prueban los componentes ejecutables (construcciones) en el modelo de
implementación con pruebas de integración y de sistema. También puede
especificar cómo se probarán ciertos aspectos específicos como la interfaz
de usuario y la ayuda en línea.

El modelo de pruebas está compuesto por un conjunto de casos de prueba,

procedimientos de prueba y componentes de prueba.

Plan de prueba
Este plan describe las estrategias, recursos y planificación de la prueba. La
estrategia incluye la definición del tipo de pruebas a realizar para cada
iteración y sus objetivos, el nivel de cobertura de prueba y el porcentaje de
pruebas que deberían ejecutarse con un resultado específico.
Defecto
Un defecto es una anomalía del sistema. Un defecto puede ser utilizado para
localizar cualquier cosa que los desarrolladores deben registrar como un
síntoma de problema en el software, que ellos necesitan controlar y
resolver.

Evaluación de prueba
Esto es un análisis y valoración del resultado de la prueba, tales como
cobertura del caso de prueba, cobertura de código y el estado de los
defectos. Más adelante, veremos cómo determinar el porcentaje de
cobertura de la prueba en función de la cantidad de escenarios posibles de
un caso de uso.

Procedimiento de prueba
En este punto veremos los conceptos de procedimiento de prueba (indica
cómo probar), caso de prueba (indica qué probar) y componente de prueba
(automatiza el procedimiento de prueba cuando sea posible).

7
Procedimiento de prueba
Un procedimiento de prueba especifica cómo realizar uno o más casos de
prueba. Esto implica las instrucciones para que un individuo lleve a cabo las
pruebas o las instrucciones para interactuar con una herramienta de
automatización de pruebas.

El cómo llevar a cabo un caso de prueba puede ser especificado por un

procedimiento de prueba, pero a menudo es útil reutilizar un procedimiento
de prueba para varios casos y reutilizar varios procedimientos de prueba
para un caso de uso

El procedimiento de prueba es similar a la descripción del flujo de eventos

de un caso de uso pero incluye información adicional, como los valores de
entrada del caso de uso a utilizar, la forma en la que estos valores han de ser
introducidos en la interfaz de usuario y lo que hay que verificar.

A continuación se muestra un ejemplo de Procedimiento de Prueba para el

caso de uso “Registrar Disco”.

Caso de prueba
Un caso de prueba especifica una forma de probar el sistema, incluyendo la
entrada o resultado con la que se ha de probar y las condiciones bajo las que
ha de probarse.

Típicamente un caso de prueba (en el Flujo de Trabajo de Prueba del PUD)

puede especificar:

8
 Cómo probar un caso de uso o un escenario específico de un caso de
uso. Este tipo de caso de prueba incluye la verificación del resultado de
la interacción entre los actores y el sistema, que se satisfacen las
precondiciones y las postcondiciones. Un caso de prueba de este tipo es
una prueba de “caja negra”, es decir, una prueba del comportamiento
exteriormente observable.

 Cómo probar una realización de caso de uso-diseño, que incluye la

verificación de la interacción de los componentes que implementan
dicho caso de uso. Este tipo de prueba es una prueba de “caja blanca”,
es decir una prueba de la interacción interna de los componentes.

Para las pruebas de sistema, en el Flujo de Trabajo de Prueba se plantean

las siguientes:

 Pruebas de instalación: Verifican que el sistema pueda ser instalado en

la plataforma del cliente y que funcionará correctamente.

 Pruebas de configuración: Verifican que el sistema funciona

correctamente en diferentes configuraciones, como por ejemplo
distintas configuraciones de red.

 Pruebas negativas: Intentan provocar que el sistema falle para revelar

sus debilidades. Consisten en casos de prueba en los que se utilizará el
sistema deliberadamente “mal” o realizando cosas que no son las
esperadas, o sobrecargándolo.

 Pruebas de tensión o de estrés: Identifican problemas con el sistema

cuando hay recursos insuficientes o cuando hay competencia por los
recursos.

 Pruebas de aceptación: Se realizan en el ambiente de operación,

también se las conoce como testing del cliente. En la confección del plan
de pruebas de aceptación debería participar el cliente.

Componente de prueba
Un componente de prueba automatiza uno o varios procedimientos de
prueba o partes de ellos. Pueden ser desarrollados utilizando un lenguaje de
programación común o desarrollada con una herramienta de
automatización de pruebas.

9
Si son complejos de desarrollar, se puede confeccionar un modelo de diseño
de pruebas (similar al modelo de diseño del sistema), para modelar los
componentes de prueba.

10
Referencias
Booch Grady, Rumbaugh James, Jacobson Ivar (1999) “El lenguaje de
Modelado Unificado”, España, Addison Wesley Iberoamericana. Capítulos: 25,26,
29 y 30

Braude Eric (2003) “Ingeniería de Software, una perspectiva orientada a objetos”,

Alfaomega Grupo Editor SA. Capítulo: 8 y 9

Jacobson Ivar, Booch Grady, Rumbaugh James (2000) “El Proceso

Unificado de Desarrollo de Software”, España, Addison Wesley. Capítulos: 10 y 11
Larman Craig (2003) “UML y Patrones. Una introducción al análisis y diseño
orientado a objetos y al proceso unificado”, 2da. Edición, España, Prentice Hall.
Capítulo: 20

Pressman Roger (2006) “Ingeniería de Software. Un enfoque práctico”

6ta. edición, McGraw Hill. Capítulos 10

Rubble David (1998) "Análisis y Diseño práctico de Sistemas Cliente/Servidor con

GUI". Prentice Hall. Capítulo: 8

Sommerville Ian (2002) “Ingeniería de Sofware”, Ed. Pearson Educación, México.

Capítulo: 10

11
 Planificar la
prueba

Análisis de
Sistemas

1
Planificar la prueba
La planificación de la prueba consta de:

 Una descripción de la estrategia de prueba: Qué pruebas ejecutar,

cómo, cuándo y cómo determinar el éxito.
 Estimación de los recursos para la prueba (recursos humanos, equipos,
sistemas necesarios).
 Planificación del esfuerzo de la prueba.

Una vez planificada la prueba se procederá al diseño de la prueba.

Planeación de las pruebas de unidad

Se resumen a continuación los pasos para confeccionar un plan de pruebas
de unidades, tal como lo sugiere Eric Fraude (Braude Eric , 2003, pág. 405 –
407)

1) Decida la filosofía de las pruebas de unidades: El primer paso es

identificar qué “unidades” deben probarse y quién lo hará. Para
proyectos de desarrollo orientados a objetos, una organización
común para las pruebas de unidades es probar los métodos de cada
clase, después las clases de cada paquete y luego el paquete como
un todo.
2) Decida cómo se documentarán las pruebas de unidades: La
documentación de las pruebas de unidades consiste en los
procedimientos de prueba, los datos de entrada, el código que
ejecuta las pruebas y los datos de salida. Las pruebas de unidades
pueden estar en el paquete del código o en documentos separados.
3) Determine el alcance de las pruebas unitarias: Dado que es imposible
probar “todo”, debe definirse el alcance de las pruebas con cuidado.
Por ejemplo, si tenemos una clase CajaDeAhorro con sus métodos:
depositar(), extraer(), consultarSaldo(), las pruebas de unidad
podrían especificar que cada método se debe probarse con una
cantidad igual de datos ilegales, legales y de frontera; o tal vez los
métodos depositar() y extraer() se prueben tres veces más que los de
consulta.
En general, los métodos que cambian el estado (valores de las
variables, llamados métodos modificadores) suelen probarse en
forma más extensa que los otros (métodos selectores, que acceden
a los atributos pero sin modificar sus valores).
4) Decida cómo y dónde obtener datos para las pruebas: Se han
mencionado entradas legales, de frontera e ilegales para estos datos.

2
 También se requiere cierta generación aleatoria. Puede disponerse
de una buena cantidad de versiones anteriores de la aplicación,
fuentes estándar, entre otros. Todo eso se documenta para
referencia futura y reuso.
5) Estime los recursos requeridos: Igual que con toda la planeación, se
identifican las personas-mes y la duración requeridas para realizar las
pruebas de unidades. La fuente más importante de esta estimación
consiste en los datos históricos. Aunque las pruebas de unidades
pueden unirse al código fuente, la ejecución por separado da datos
invaluables.
6) Registre tiempo, cuenta de defectos, tipo y fuente: Los ingenieros
que participan determinan la forma exacta en la que registrarán el
tiempo dedicado a pruebas de unidades, estado de la aplicación y
pronosticar la calidad que tendrá el producto y su fecha de
terminación. Además, los datos se convierten en parte del registro
histórico de la organización.

Listas de verificación para las pruebas de métodos

Las pruebas de unidades incluyen pruebas independientes, cuando es
posible, de cada método que corresponde directamente a un requerimiento
establecido en la ERS (Especificación de Requisitos del Software), es decir,
se verifica que el método satisfaga sus requerimientos.

Dentro de su alcance limitado, ésta es una prueba de caja negra. También se

aplican pruebas de caja blanca para cada método.

Se brinda a continuación una lista de verificación para realizar pruebas de

métodos, que conviene tener a mano y consultar a la hora de diseñar los
casos de prueba de unidad:

1) Verificar la operación con valores normales de los parámetros (caja

negra)
2) Verificar la operación en los valores límite de los parámetros (caja negra)
3) Verificar la operación para en los valores de los parámetros fuera de los
límites (caja negra)
4) Asegurar que ejecuta todas las instrucciones (caja blanca – cubrimiento
de sentencias)
5) Verificar todas las trayectorias, incluidos ambos lados de todas las ramas
6) (caja blanca – cubrimiento de decisiones)
7) Verificar el uso de todos los objetos llamados
8) Verificar el manejo de todas las estructuras de datos
9) Verificar el manejo de todos los archivos
10) Verificar la terminación normal de todos los ciclos
11) Verificar la terminación anormal de todos los ciclos

3
12) Verificar la terminación normal de todas las recursiones
13) Verificar la terminación anormal de todas las recursiones
14) Verificar el manejo de todas las condiciones de error
15) Verificar el tiempo y la sincronización
16) Verificar todas las dependencias de hardware

Listas de verificación para las pruebas de clase

Una vez probados los métodos individuales, se puede pasar a la prueba de
la clase como un todo; esto significa ejecutar métodos en combinación. Una
vez más, es probable que un conjunta puramente aleatorio de
combinaciones de métodos desperdicie tiempo y de todos modos deje
huecos en la cobertura.

En la siguiente lista de verificación se encontrarán consejos para realizar

pruebas de la clase:

1) Use métodos en combinación:

1.1. Por lo común de 2 a 5 métodos.

1.2. Elija la mayoría de las secuencias primero.

1.3. Incluya las secuencias que son probables causas de defectos.

1.4. Requiere el cálculo a mano de valores de los atributos obtenidos.

2) Enfoque las pruebas de unidades a cada atributo: Inicie, después ejecute

las secuencias del método que lo afectan.

3) Verifique la transición de objetos entre los estados esperados:

3.1. Planee la secuencia de eventos de transición de estados

(basarse en el Diagrama de Estados).

3.2. Establezca el objeto en su estado inicial con los valores de las variables.

3.3. Proporcione el primer evento y verifique que ocurra la transición, y así

sucesivamente.

Planificar Pruebas de Integración

Una manera de planear y ejecutar las pruebas de integración sería la
siguiente:

4
1) Decidir cuándo y dónde almacenar, reusar y codificar las pruebas de
integración. Esto deber quedar claramente expresado en la
programación de tiempos del proyecto.
2) Asegurar que los requerimientos de las construcciones están bien
especificados.
3) Ejecutar los casos de uso que debe implementar la construcción: Realizar
la prueba contra lo documentado en la ERS (Documento de
Especificación de Requisitos del Software).
4) Realizar pruebas de regresión, para asegurar que las capacidades
existentes siguen funcionando.
5) Ejecutar las pruebas del sistema soportadas por esta construcción.

Actividades posteriores a la Planeación de la prueba

Luego de la actividad de planear la prueba deberá procederse al diseño de
la prueba, implementar componentes automatizados de prueba (de ser
posible) y luego realizar las pruebas (de integración y de sistema en el caso
del Flujo de Trabajo de Prueba del PUD ya que las pruebas de unidad se
ejecutan en el Flujo de Trabajo de Implementación).

Diseñar la prueba
En esta actividad se procederá a: identificar y describir los casos de prueba
para cada construcción, identificar y estructurar los procedimientos de
prueba especificando cómo realizar los casos de prueba.

Hay que considerar en esta actividad:

 Casos de prueba de integración, normalmente derivados de las

realizaciones de caso de uso-diseño.

 Casos de prueba de sistema, en los que se da prioridad a las

combinaciones de los casos de uso que se necesitan que funcionen en
paralelo, que se influencian entre sí si funcionan en paralelo, involucran
varios procesadores, usan recursos del sistema en quizás en forma
impredecible y compleja.

 Casos de prueba de regresión, que permiten asegurar, al finalizar una

iteración, que no se ha estropeado ninguna parte del sistema que antes
funcionaba bien y ya había sido probada. Son fundamentales en un
proceso iterativo e incremental.

5
Implementar pruebas
El propósito de esta actividad es automatizar los procedimientos de prueba
creando componentes de prueba, si es que es posible ya que no siempre es
posible o factible automatizar los procedimientos de prueba.

Realizar pruebas de integración

Durante esta actividad se procede a realizar las pruebas de integración
relevantes a la construcción realizando los procedimientos de prueba para
cada caso de prueba o ejecutando los componentes de prueba
desarrollados.

Luego se comparan los resultados de las pruebas con los resultados

esperados y se investigan los casos en que no coincidieron. Se procede
entonces a informar los defectos a los ingenieros de componentes
responsables de los componentes que se cree que tienen fallos.

También se informa de los defectos a los diseñadores de pruebas quienes

usarán los defectos para evaluar los resultados del esfuerzo de prueba.

Realizar prueba de sistema

La prueba de sistema puede comenzar cuando las pruebas de integración
indican que el sistema satisface los objetivos de calidad de integración
fijados en el plan de prueba de la iteración actual.

Tipos de prueba
Niveles de prueba
Todo proceso de prueba de software consiste en tres niveles de prueba:
pruebas de unidad, de integración y de sistema. En el Proceso de Desarrollo
Unificado, las pruebas de unidad se realizan el Flujo de Trabajo de
Implementación y las pruebas de integración y de sistema en el Flujo de
Trabajo de Prueba, que tratamos en esta unidad.

Las pruebas de unidad son el primer tipo de pruebas que se realizan. Por
referirse principalmente a la prueba de métodos de las clases, se ubican
naturalmente en el Flujo de Trabajo de Implementación ya que es normal

6
que quien realiza la codificación de la clase vaya realizando la prueba de sus
métodos.

El siguiente nivel de pruebas consiste en las pruebas de integración. Esto

valida la funcionalidad global de cada etapa de la aplicación parcial.

Por último las pruebas de sistema y de aceptación validan el producto final.

La siguiente figura ilustra los niveles de prueba:

Fuente: Libro “Ingeniería de Software – Una perspectiva orientada a objetos” – Eric Braude, 2003,
Pág. 395.

Pruebas de Unidad
La meta de las pruebas de unidades es estructural mientras que el otro tipo
de pruebas es funcional típico. Como se muestra en el gráfico de la página
anterior, en general las funciones son las partes más pequeñas a las que se
aplican las pruebas de unidades. En el caso de la orientación a objetos se
refiere a los métodos de una clase. La siguiente unidad en tamaño es el
módulo, que en nuestro caso se refiere a una clase. Algunas veces, las
“combinaciones de módulos” se consideran unidades para los propósitos de
las pruebas (estos serían paquetes o subsistemas).

Las unidades a las que se aplican las “pruebas de unidad” son los bloques de
construcción de la aplicación, algo así como los ladrillos individuales sobre
los que se apoya una casa. Si algunos de estos “ladrillos” son defectuosos,
una vez integradas las partes defectuosas en una aplicación, puede tomar
mucho tiempo identificarlas y repararlas. Por ello, los bloques de
construcción de software deben ser completamente confiables y esta es la
meta de las pruebas de unidad.

7
En términos del PUD (Proceso de Desarrollo Unificado), las pruebas unitarias
se llevan a cabo durante las iteraciones de la fase de Elaboración y también
en las primeras iteraciones de la Construcción.

Pasos para realizar pruebas de unidad

La siguiente figura, basada en el estándar IEEE 1008-1987, muestra un mapa

conceptual típico para las pruebas de unidades:

Fuente: Libro “Ingeniería de Software. Una perspectiva orientada a objetos” Eric Braude, 2003, Pág.
397.

Los pasos que requiere el estándar IEEE (1008-1987) para las pruebas de
unidades, que amplían el mapa conceptual anterior, son:

1) Planear el enfoque general, recursos y programa de tiempos.

2) Determinar las características basadas en los requerimientos que deben
probarse.
3) Refinar el plan general.
4) Diseñar un conjunto de pruebas.
5) Implementar el plan y diseño refinados.
6) Ejecutar los procedimientos de pruebas.
7) Verificar que terminen.
8) Evaluar el esfuerzo y la unidad de las pruebas.

Tipos de pruebas de unidad

Generalmente una prueba de unidad consiste en una evaluación estructural
(o prueba de caja blanca), lo cual significa que se usan los conocimientos de
cómo la unidad es diseñada internamente, y una evaluación de
especificación (o prueba de caja negra), la cual usa lo opuesto: se aplican
los test solamente sobre la especificación de los comportamientos de la
unidad visibles externamente.

8
En el caso de sistemas orientados a objetos también se necesitan ejecutar
tests basados en estados encapsulados de objetos y la interacción de
operaciones, a las que se denomina evaluación basada en estado.

Pruebas de Caja Negra

Cuando el único interés de una prueba es si una aplicación o parte de ella
proporciona la salida adecuada, se prueba que cumpla cada requerimiento
al usar la entrada apropiada. Esto se llama prueba de caja negra porque no
se pone atención al interior de la “caja” (la aplicación).

Las pruebas de caja negra pueden ser suficientes si se puede asegurar que
agotan todas las combinaciones de entrada. Esto probaría al cliente que
todos los requerimientos se satisfacen. Sin embargo, ninguna prueba cubre
todas las posibilidades.

Fuente: Libro “Ingeniería de Software. Una perspectiva orientada a objetos” Eric Braude, 2000, Pág.
398.

Como no se pueden probar todas las combinaciones, se buscan casos de

prueba representativos. El problema es representar de la mejor manera el
conjunto infinito de posibilidades con un conjunto finito tan representativo
como sea posible.

La partición de equivalencia es la división de los datos de entrada de las

pruebas en subconjuntos tales que si cualquier entrada única tiene éxito,
entonces es probable que todas las demás entradas tengan éxito.

Por ejemplo al probar el método tomarNombre(String), pasar la prueba para

tomarNombre (“Francisco”) significa que tal vez no se encuentren defectos
al probar tomarNombre() en cada cadena de nueve caracteres alfabéticos.
Sin duda, quizá ese conjunto de equivalencia se pueda extender a “todos los
nombres con un número de caracteres mayor que cero y menor que
maxNumCarEnNombre() (función que determina el máximo número de
caracteres aceptados para el nombre).”

En general, se llega a las particiones de equivalencia mediante la

investigación de los valores que limitan las variables dentro de la aplicación.

9
Por ejemplo, en un caso de un sistema académico de cursado de materias
en una facultad, los valores válidos para las notas de los parciales van entre
0 y 10 (0 se consideraría un Ausente), esto proporciona dos fronteras. Ahora
bien, que la nota sea mayor o igual a 4 tiene un significado especial (es la
nota inferior para aprobar), esto introduciría una frontera adicional. Al
diseñar las pruebas, también se usan los valores fuera de estas fronteras (es
decir, las entradas no válidas) como datos de prueba.

Ejemplo: Prueba de un método de la clase MateriaAlumno

Método: verificarRegularidad

Tablas de partición del intervalo para las pruebas de unidad

10
Pruebas de Caja Blanca
La idea de las pruebas de caja blanca es verificar los elementos de la
aplicación y la manera en que se ensamblaron. La meta de las pruebas de
caja blanca es probar las líneas de falla más probables de la aplicación.

Para realizar pruebas de caja blanca, primero se desglosa el diseño de la

aplicación en busca de trayectorias y otras particiones de control y datos.
Después se diseñan pruebas que recorran todas o algunas de estas
trayectorias y se ejecutan todas las partes o elementos. Un nombre que
describe mejor esta actividad es “pruebas de caja de vidrio”.

Fuente: Libro “Ingeniería de Software. Una perspectiva orientada a objetos” Eric Braude, 2000, Pág.
398.

Cada sentencia en un programa debe ejecutarse en al menos una prueba.

Esta cobertura es necesaria. Sin embargo, la cobertura de sentencias de
ninguna manera es suficiente para asegurar que un programa sea correcto.

La cobertura de decisiones asegura que el programa toma cada rama de

cada decisión. Por ejemplo, asegurar que cada “SI” y cada “NO” de cada
decisión se ha seguido por lo menos una vez en las pruebas del conjunto. La
cobertura de decisiones asegura también, que se ejecute cada iteración de
cada ciclo. Esto se puede hacer de manera que cada iteración de cada ciclo
se ejecute al menos una vez.

Este enfoque no es difícil para ciclos (sentencias FOR y equivalentes), pero

introduce complicaciones en los ciclos de while. En ocasiones se pueden
enumerar todas las posibilidades, otras se puede hacer una partición en
grupos. Sin embargo, algunas veces es casi imposible una cobertura
completa de las decisiones para los ciclos while.

11
Pruebas basadas en los estados
Como ya se ha visto, los objetos de las clases muchas veces se pueden
interpretar como transiciones entre estados en respuesta a los eventos. Por
lo tanto, deben probarse esas clases en términos de su estado. Las pruebas
basadas en estado prueban la interacción entre las operaciones de una clase
monitoreando los cambios que tienen lugar en los atributos de los objetos.
Probar sólo una operación aislada no es suficiente para probar una unidad,
se debe probar también los atributos del objeto.

Una prueba consistiría en la estimulación del sistema de manera que transite

por una secuencia de estados. Habría que probar todas las secuencias de
estados válidas y también introducir eventos que no se aplican a estados
particulares, para asegurar que no afectan a la aplicación. Es importante
basarse en los diagramas de transición de estados, así nos aseguramos que
cada estado es visitado al menos una vez y cada transición es atravesada al
menos una vez.

La matriz de estados es una buena herramienta para este tipo de pruebas.

La combinación de estados y estímulos puede probarse con esta matriz.

Una de las ventajas de este tipo de matrices es que focaliza la atención del
diseñador en la combinación estímulo (evento)/estado que puede ser

12
descuidada durante el diseño. Es posible incluir todas las combinaciones de
atributos del objeto (todos los posibles valores de las variables) y todas las
variantes de estímulo (distintos parámetros). En general algunas
combinaciones específicas de atributos pueden ser más interesantes que
otras. Algunas operaciones, como las de lectura, que no afectan el estado,
no necesitan ser consideradas.

Debe verificarse que todos los posibles estados pueden alcanzarse con
alguna combinación de operaciones, de otra manera puede haber una falla
en el diseño de la clase.

Pruebas de Integración
Concepto de Integración

Debido a que las aplicaciones son complejas, deben construirse con partes
que primero se desarrollan por separado. La “integración” se refiere a este
proceso de ensamble. Se realizan varios tipos de pruebas en los ensambles
parciales de la aplicación y en toda ella. La etapa de integración suele
producir sorpresas desagradables por incompatibilidad de las partes que se
integran. Por esto, el Proceso de Desarrollo Unificado, en particular, intenta
evitar la integración “explosiva” mediante la integración continua con
múltiples iteraciones.

Cuando se desarrolla la arquitectura, una consideración importante es la

facilidad con que se pueden integrar las partes. Sin embargo, rara vez es
factible completar los módulos individuales de software antes de la
integración. Aunque el proceso de construcción típico tiene la desventaja de
trabajar con unidades incompletas, posee la ventaja de ejercer la integración
antes en el proceso de desarrollo. Esto ayuda a eliminar los riesgos, al evitar
la integración “explosiva”.

Las dificultades de integrar las aplicaciones resaltan la importancia de

diseñar unidades (como clases y paquetes) que se centren en un propósito
lo más que sea posible, disminuyendo sus interfaces mutuas todo lo que se
pueda. Estas metas, “alta cohesión” y “bajo acoplamiento”,
respectivamente, se analizaron en la actividad de diseño.

Cuando se aplica a la integración, la verificación se reduce a confirmar que

se están uniendo justo los componentes que se planeó ensamblar, justo en
la forma que se planeó ensamblarlos. Esa verificación se puede realizar
mediante la inspección de los productos de la integración.

Realizar pruebas se simplifica con la incorporación de implementaciones de

casos de uso completos en cada construcción en lugar de sólo partes de un

13
caso de uso. Crear casos de uso relativamente pequeños desde el principio
facilita su ajuste en las construcciones.

Proceso de pruebas de Integración

Los casos de uso son una fuente ideal de casos de prueba para las pruebas
de integración. La idea es que los casos de uso se construyan sobre los que
ya están integrados para formar pruebas cada vez más representativas del
uso de la aplicación, como se muestra en la siguiente figura:

Fuente: Libro “Ingeniería de Software. Una perspectiva orientada a objetos” Eric Braude, 2000, Pág.
445.

Se requiere un número grande de pruebas para validar una aplicación de

manera adecuada, y necesitan una organización metódica. Un estilo de
organizar los casos de prueba es ponerlos en un paquete en clases
especialmente creadas para las pruebas. Una clase o quizá un paquete
entero, se puede dedicar a probar toda la aplicación.

Por lo general, las construcciones consisten en el código de varios

desarrolladores y es común encontrar muchos problemas cuando se integra
el código para crear la construcción. Por ello, se intenta comenzar la
integración y las pruebas de integración pronto en el proceso, para ejecutar
el código en su contexto final.

Pruebas de Interacción
Las interacciones entre casos de uso son las áreas más difíciles de probar,
debido a la gran cantidad de combinaciones posibles aún en un sistema de
tamaño moderado.

14
Una forma de buscar interacciones es buscar objetos compartidos entre
casos de uso. Para esto se pueden utilizar matrices CRUD
(Create/Read/Update/Delete - Crear/Leer/Actualizar/Borrar), buscando
principalmente las situaciones en las que los objetos son leídos, actualizados
o borrados en un caso de uso y creados en otro.

Veamos como ejemplo la matriz CRUD para el caso de un sistema académico

simplificado:

Del análisis de esta matriz vemos que en diversos casos de uso se “leen”
objetos “alumno, materia y profesor”, pero nunca son creados. En este caso
debe considerarse si:

 Se agregan casos de uso necesarios en nuestro sistema, o

 Si los datos serán proporcionados por otro sistema.

De cualquier manera, debemos asegurarnos que los objetos existan para

poder realizar las pruebas de nuestro sistema.

Pruebas de Sistema
La prueba del sistema es la culminación de las pruebas de integración.
Consiste en pruebas de caja negra que validan la aplicación completa contra
sus requerimientos (funcionales y no funcionales).

Siempre que sea posible, las pruebas del sistema se realizan mientras la
aplicación se ejecuta en su entorno requerido. Sin embargo, en ocasiones
habrá que conformarse con pruebas de ejecuciones del sistema en un
entorno o configuración que no es equivalente a la del cliente.

La confiabilidad/disponibilidad se determinan mediante medidas como el

tiempo medio entre fallas: MTBF (mean time between failures). Para
obtener el MTBF primero se establece una definición de “falla”, por ejemplo
la deshabilitación total de la aplicación (se pueden definir varios niveles de
falla). Para calcular el MTBF, un probador inicia la aplicación, registra la hora

15
y ejecuta la aplicación con un escenario aleatorio, hasta que el sistema falla.
Registra la hora y calcula el tiempo transcurrido. Este proceso se realiza
muchas veces. El MTBF es el promedio de los tiempos obtenidos.

A continuación se enumeran distintos tipos de pruebas de sistema:

 Volumen: Somete al producta a la entrada de grandes cantidades de

datos.

 Utilidad: Mide la reacción del usuario, por ejemplo con una calificación
del 0 a 10 (ver más detalles debajo).

 Desempeño: Mide la velocidad para varias circunstancias.

 Configurabilidad: Configura los distintos elementos de

hardware/software. Por ejemplo, mide el tiempo de preparación.

 Compatibilidad: Con otras aplicaciones designadas. Por ejemplo, mide

el tiempo de adaptación.

 Seguridad: Sujeta a intentos comprometedores. Por ejemplo, mide el

tiempo promedio para entrar (romper) al sistema.

 Uso de recursos: Mide el uso de RAM, espacio en disco, entre otros.

 Aptitud de instalación: Mide el tiempo de instalación.

 Recuperabilidad: Fuerza actividades que desactivan la aplicación y mide

el tiempo de recuperación.

 Funcionalidad: Da servicio a las aplicaciones en diferentes

circunstancias, mide el tiempo de servicio. El término funcionalidad se
refiere a la facilidad o dificultad con que la aplicación se mantiene
operativa. Por ejemplo, una aplicación de sistema experto se apoya en
su base de conocimientos, que debe ser capaz de modificarse con
facilidad.

Pruebas de Utilidad
Una buena interfaz puede mejorar mucho el valor de la aplicación. La prueba
de utilidad valida la aceptación de la aplicación por los usuarios. Una manera
de hacer esto es cuantificar el nivel de satisfacción que informan los usuarios
al usar la aplicación.

Algunos criterios esenciales para estas pruebas son los siguientes:

16
 Accesibilidad: Facilidad con la que entran, navegan y salen los usuarios.
Por ejemplo, medida por el tiempo promedio que toma.

 Rapidez de respuesta: Qué tan rápido permite la aplicación al usuario

lograr sus metas especificadas. Por ejemplo, medida del tiempo
promedio que toma.

 Eficiencia: Qué tan pequeños son los pasos requeridos para la

funcionalidad elegida. Por ejemplo, medida por el tiempo mínimo de
una muestra de usuarios.

 Comprensión: La facilidad con que se entiende y usa el producto

mediante la documentación y la ayuda en línea. Por ejemplo, medida
por el tiempo que toman las investigaciones estándar.

Pruebas de Regresión
Cuando una aplicación crece, las pruebas del sistema adquieren un
significado especial. Esto es en especial notorio cuando se hace un cambio
en una aplicación grande y los desarrolladores necesitan validad el hecho de
que el cambio no haya afectado la funcionalidad existente.

La primera pregunta después de integrar el cambio casi siempre es la

siguiente: “¿es este producto el mismo que el anterior, con la funcionalidad
agregada?”. En general, la reinspección no es práctica, por lo que una
manera práctica importante de ayudar a contestar esta pregunta es verificar
que el sistema continúe pasando el mismo conjunto de pruebas diseñado
antes de hacer los cambios. Este proceso de verificación se llama pruebas de
regresión. Si el tiempo no permite realizar las pruebas completas, se
seleccionan aquellas con mayor probabilidad de fallar debido a los cambios.

Pruebas de Aceptación
La organización desarrolladora y la del cliente son las partes de un contrato.
Cuando termina un trabajo, un desarrollador inteligente obtiene una
declaración definitiva del cliente que establece que de hecho la aplicación
está entregada.

Las pruebas de aceptación están diseñadas para asegurar al cliente que se

construyó la aplicación estipulada. Las pruebas de aceptación tal vez no sean
muy diferentes de las pruebas del sistema que diseña el desarrollador, pero

17
la organización del cliente es el testigo y se ejecutan en la plataforma que
van a operar.

Evaluación de la prueba
En esta actividad, los diseñadores de pruebas evalúan los resultados del
esfuerzo de la prueba comparando los resultados obtenidos con los
objetivos establecidos en el plan de prueba.

Como resultado de esta actividad se preparan métricas que les permiten

determinar el nivel de calidad del software y qué cantidad de pruebas son
necesarias.

Fundamentalmente se observan dos métricas:

 Compleción de la prueba: Indica el porcentaje de casos de prueba que

han sido ejecutados y el porcentaje de código que ha sido probado.

 Fiabilidad: Se basa en el análisis de las tendencias en los defectos

detectados y en las tendencias en las pruebas que se ejecutan con el
resultado esperado.

Para determinar la fiabilidad del sistema, los diseñadores de pruebas crean

diagramas de las tendencias de los defectos, donde representan la
distribución de tipos específicos de defectos a lo largo del tiempo. La prueba
puede crear también diagramas de tendencias que representan el
porcentaje de pruebas ejecutas con éxito (es decir con los resultados
esperados) a lo largo del tiempo.

Basándose en el análisis de la tendencia de los defectos, los diseñadores de

pruebas pueden sugerir otras acciones, como por ejemplo:

 Realizar pruebas adicionales para localizar más defectos, si la fiabilidad

medida sugiere que el sistema no en un nivel de madurez apropiado.
 Relajar el criterio para las pruebas, si los objetivos de calidad para la
iteración actual se pusieron demasiado altos.
 Aislar las partes del sistema que parecen tener una calidad aceptable y
entregarlas como resultado de la iteración actual. Las partes que no
cumplen los criterios de calidad deben ser revisados y probados
nuevamente.

18
Referencias
Booch Grady, Rumbaugh James, Jacobson Ivar (1999) “El lenguaje de
Modelado Unificado”, España, Addison Wesley Iberoamericana. Capítulos: 25,26,
29 y 30

Braude Eric (2003) “Ingeniería de Software, una perspectiva orientada a objetos”,

Alfaomega Grupo Editor SA. Capítulo: 8 y 9

Jacobson Ivar, Booch Grady, Rumbaugh James (2000) “El Proceso

Unificado de Desarrollo de Software”, España, Addison Wesley. Capítulos: 10 y 11
Larman Craig (2003) “UML y Patrones. Una introducción al análisis y diseño
orientado a objetos y al proceso unificado”, 2da. Edición, España, Prentice Hall.
Capítulo: 20

Pressman Roger (2006) “Ingeniería de Software. Un enfoque práctico”

6ta. edición, McGraw Hill. Capítulos 10

Rubble David (1998) "Análisis y Diseño práctico de Sistemas Cliente/Servidor con

GUI". Prentice Hall. Capítulo: 8

Sommerville Ian (2002) “Ingeniería de Sofware”, Ed. Pearson Educación, México.

Capítulo: 10

19