25 de mayo de 2015

INFORME PATRONES DE DISEO Y PRUEBAS DEL SOFTWARE

Un patrn de diseo es una descripcin de clases y objetos que se comunican

entre s, adaptada para resolver un problema general de diseo en un contexto
particular. Es una solucin a un problema en un contexto.
Cada patrn describe un problema que ocurre una y otra vez en nuestro
entorno y describe tambin el ncleo de su solucin, de forma que puede
utilizarse un milln de veces sin hacer dos veces lo mismo.

Ventajas de los patrones de diseo:

-

Facilitan la localizacin de los objetos que formarn el sistema.

Facilitan la determinacin de la granularidad adecuada.
Especifican interfaces para las clases.
Especifican implementaciones.
Facilitan el aprendizaje y la comunicacin entre programadores y
diseadores.

Clasificacin de los patrones de diseo:

Respecto a su propsito:
Creacionales: Resuelven problemas relativos a la creacin de
objetos.
Estructurales: Resuelven problemas relativos a la composicin de
objetos.
Comportamiento: Resuelven problemas relativos a la interaccin
entre objetos.

Respecto a su mbito:
Clases: Relaciones estticas entre clases.
Objetos: Relaciones dinmicas entre objetos.

Creacional

CLASES
Mtodo
Fabrica

Estructural

Adaptador

OBJETOS
Fabrica Abstracta,
Constructor, Prototipo,
Singleton
Adaptador, Puente,
Compuesto, Decorador,

Comportamiento

Interprete,
Mtodo
Plantilla

Fachada, Peso Ligero,

Apoderado
Cadena de
Responsabilidad,
Comando, Iterador,
Mediador, Memento,
Observador, Estado,
Estrategia y Visitante

1- Adaptador (Adapter):
- Intencin: Convierte la interfaz de una clase en otra interfaz esperada por los
clientes. Permite la cooperacin de clases que de otro modo seran
incompatibles.
- Motivacin: Se necesita reutilizar clases ajenas para nuestro sistema, pero
aunque la funcionalidad de estas clases es la que deseamos, la interfaz no es
compatible. Si no se puede o no se quiere modificar las clases a reutilizar,
necesitamos hacerlas compatibles con nuestro sistema.
- Observacin: Este patrn tiene dos versiones, una con mbito en clases y otra
con mbito en objetos.
- Participantes:
-> OBJETIVO: Define la interfaz que espera el cliente.
-> ADAPTABLE: Implementa la interfaz incompatible que necesitamos
adaptar.
-> ADAPTADOR: Implementa la interfaz de OBJETIVO mediante llamadas
al objeto adaptado.
- Colaboraciones:
->Los clientes utilizan la interfaz OBJETIVO. Sus peticiones son recogidas
por un ADAPTADOR que las redirige al objeto adaptable.
- Consecuencias:
+ Un adaptador puede funcionar con varios adaptables de forma simultnea,
coordinando sus tareas.
+ Si se necesita redefinir el comportamiento de adaptable basta construir un
heredero y hacer que el adaptador lo adapte.

2- Compuesto (Composite):

- Intencin: Componer objetos en jerarquas todo-parte y permitir a los clientes

tratar objetos simples y compuestos de modo uniforme.
- Motivacin: Se necesita representar un conjunto de elementos de una interfaz
grfica de usuario (GUI). Algunos de estos elementos son simples, mientras
que otros estn formados por varios elementos ms simples. El
comportamiento e informacin que proporciona un elemento complejo est
determinada por los elementos que lo componen.

- Participantes:
-> COMPONENTE: Declara la interfaz comn para todos los objetos de la
composicin e implementa acciones por defecto cuando sea apropiado.
Tambin puede proporcionar la interfaz de acceso a hijos y padres.
-> SIMPLE: Representa
comportamiento comn.

los

objetos

simples

implementa

su

-> COMPUESTO: Representa los objetos con hijos, almacenando a stos e

implementando las operaciones de acceso y mantenimiento relacionadas
con ellos.
- Colaboraciones:
-> Los clientes utilizan la interfaz de COMPONENTE.
-> Los objetos simples contestan directamente, mientras que los
compuestos pueden reenviar la operacin a sus componentes.
-> Los objetos que construyen la estructura deben ser clientes tanto de
SIMPLE como de COMPUESTO.
- Consecuencias:
+ Permite el tratamiento uniforme de objetos simples y complejos.
+ Simplifica el cdigo de los clientes, que usan una sola interfaz.
+ Permite aadir nuevos tipos de componentes sin afectar a los clientes.
+ Es difcil restringir los tipos de los hijos Definir las operaciones de gestin de
los hijos en COMPONENTE crea problemas de consistencia con los hijos.
+ La implementacin de las operaciones de los compuestos que dependen de
los hijos puede ser ms fcil utilizando el patrn iterador.

3- Comando (Command):
- Intencin:
*Encapsula una peticin en un objeto.

* Permite con ello parametrizar a los clientes con diferentes peticiones y

almacenar peticiones para deshacerlas en caso necesario.
- Motivacin: Parametrizacin de las acciones a realizar por los objetos GUI de
un framework.
- Participantes:
-> COMANDO: Declara la interfaz para ejecutar una operacin.
-> COMANDO_CONCRETO: Define una relacin entre un receptor y una
accin, redefiniendo la operacin ejecutar para que se enve una peticin
adecuada al receptor.
-> CLIENTE: Crea un comando concreto indicndole cul es su receptor y
lo almacena en su emisor.
-> EMISOR: Pide al comando que lleve a cabo una peticin.
-> RECEPTOR: Sabe cmo realizar la operacin relacionada con una
peticin.
- Colaboraciones:
-> El cliente crea un comando concreto indicndole cul es su receptor.
-> El emisor almacena uno o varios comandos concretos.
-> El emisor solicita al comando que se ejecute.
-> El comando pide al receptor que realice las operaciones necesarias.
- Consecuencias:
+ La intermediacin de comando desacopla emisor y receptor Permite
manipular comandos tratados como objetos.
+ Permite aadir nuevos comandos sin alterar las otras clases.
+ Aplicando el patrn compuesto podemos obtener comandos complejos.

4- Observador (Observer):
- Intencin: Definir una dependencia entre un objeto y un conjunto de ellos, de
modo que los cambios en el primero se vean reflejados en los otros.
- Motivacin: En un toolkit de GUI necesitamos separar los objetos de
presentacin de los objetos que modelan los datos interesantes para la
aplicacin, de forma que se puedan tener varias vistas sincronizadas de los
mismos datos.
- Participantes:

-> SUJETO: Mantiene una lista de observadores y proporciona una

interfaz para su gestin.
-> OBSERVADOR: Define una interfaz para actualizar los objetos que
deben reflejar los cambios en el sujeto.
-> SUJETO_CONCRETO: Enva una notificacin a sus observadores
cuando cambia su estado.
-> OBSERVADOR_CONCRETO: Mantiene una referencia a una sujeto
concreto, almacenando parte de su estado e implementado la interfaz de
OBSERVADOR.
- Colaboraciones:
-> El SUJETO_CONCRETO notifica a sus observadores de los cambios que
sufre.
-> Los observadores concretos solicitan a su sujeto los datos necesarios
para mantener la consistencia con su nuevo estado.
- Consecuencias:
+ Permite reutilizar sujetos y observadores por separado Permite aadir nuevos
observadores sin modificar al sujeto o a otros observadores.
+ Que el sujeto no informe a sus observadores de qu cambio ha sufrido
permite mantener el acoplamiento en un nivel bajo, puesto que el observador
slo pide los datos del estado del sujeto que le interesan.
+ Aunque el observador no est interesado en ciertos cambios del sujeto ser
notificado de ellos.
+ Se pueden realizar implementaciones con observadores que coordinan
informacin sobre varios sujetos.
+ Los cambios en el sujeto pueden ser solicitados por objetos que no son
observadores.

5- Iterador (Iterator):
- Intencin: Permite acceder secuencialmente a los elementos de un agregado
sin exponer su estructura interna.
- Motivacin: Se necesita implementar una estructura de datos compleja. Se
desea proteger a los clientes de la estructura frente a los detalles de
implementacin de la misma. Permitiendo incluso que el cambio de su
estructura no los afecte.
- Participantes:
-> ITERADOR: Define la interfaz comn para recorrer todos los agregados
y acceder a ellos.

-> AGREGADO: Define la interfaz de creacin del iterador.

-> ITERADOR_CONCRETO: Implementa la interfaz de ITERADOR y
mantiene la posicin actual del iterador.
-> AGREGADO_CONCRETO: Implementa la interfaz de creacin de los
iteradores.
- Colaboraciones:
-> El iterador concreto mantiene la informacin actualizada sobre el
recorrido que se est realizando sobre el agregado.
- Consecuencias:
+ La interfaz del agregado resulta ms simple al implementar menos
operaciones de recorrido.
+ Permite el recorrido simultneo con varios iteradores, utilizando varios
algoritmos para el mismo.
+ Hay muchas alternativas de implementacin: Iterador interno o externo,
cursor, iterador robusto, etc.
+ La interfaz del iterador puede tener elementos adicionales.
6- Singleton (nico):
- Intencin: Asegurarse de que una clase tiene una sola instancia y
proporcionar un nico punto de acceso a ella.
-Motivacin: Se necesita definir una nica instancia de cierta clase MODELO de
modo que sea accesible desde mltiples objetos del sistema. S desea que el
diseo imposibilite la creacin accidental de varias instancias de la clase.
- Participantes:
-> SINGLETON: Clase que proporciona la funcionalidad deseada del
objeto nico y verifica mediante su contrato que no existen dos
instancias suyas.
-> ACCESO: Punto de acceso que devuelve el objeto singleton. Varias
instancias del punto de acceso devuelven la misma instancia del objeto
nico gracias a una funcin once.

Pruebas de Software:
La prueba de software es un conjunto de herramientas, tcnicas y mtodos que
hacen a la excelencia del desempeo de un programa. Las tcnicas para
encontrar problemas en un programa son extensamente variadas y van desde
el uso del ingenio por parte del personal de prueba hasta herramientas
automatizadas que ayudan a aliviar el peso y el costo de tiempo de esta
actividad. Pero de nada servira conocer todas las tcnicas de prueba de

software, si un programa carece de documentacin, el cdigo es confuso, o no

se han seguido pasos para la planificacin y desarrollo del software.

TEST

Unitario

Integraci
n

Funcional

Sistema

Aceptaci
n

NIVELES DE PRUEBAS
PARTICIPANTE
AMBIENTE
S
Detectar
Programador
Desarrollo
errores en los es
datos,
lgica,
algoritmos
Detectar
Programador
Desarrollo
errores
en es
interfaces
y
relaciones
entre
componentes
Detectar
Testers,
Desarrollo
errores en la Analistas
implementaci
n
de
requerimientos
Detectar fallas Testers,
Desarrollo
en
el Analistas
cubrimiento de
requerimientos
Detectar fallas Testers,
Productivo
en
la Analistas,
implementaci
Cliente
n del sistema
OBJETIVO

METODO
Caja Blanca

Caja Blanca,
Top
Down,
Bottom Up

Funcional

Funcional

Funcional

- Pruebas Unitarias o de Componente: este tipo de pruebas son ejecutadas

normalmente por el equipo de desarrollo, bsicamente consisten en la
ejecucin de actividades que le permitan verificar al desarrollador que los
componentes unitarios estn codificados bajo condiciones de robustez, esto es,
soportando el ingreso de datos errneos o inesperados y demostrando as la
capacidad de tratar errores de manera controlada.
- Pruebas de Integracin: este tipo de pruebas son ejecutas por el equipo de
desarrollo y consisten en la comprobacin de que elementos del software que
interactan entre s, funcionan de manera correcta.
- Pruebas de Sistema: este tipo de pruebas deben ser ejecutadas idealmente
por un equipo de pruebas ajeno al equipo de desarrollo, una buena prctica en
este punto corresponde a la tercerizacin de esta responsabilidad. La
obligacin de este equipo, consiste en la ejecucin de actividades de prueba
en donde se debe verificar que la funcionalidad total de un sistema fue

implementada de acuerdo a los documentos de especificacin definidos en el

proyecto. Los casos de prueba a disear en este nivel de pruebas, deben
cubrir los aspectos funcionales y no funcionales del sistema. Para el diseo de
los casos de prueba en este nivel, el equipo debe utilizar como bases de
prueba entregables tales como: requerimientos iniciales, casos de uso,
historias de usuario, diseos, manuales tcnicos y de usuario final, etc. Por
ltimo, es importante que los tipos de pruebas ejecutados en este nivel se
desplieguen en un ambiente de pruebas / ambiente de pre-produccin cuya
infraestructura y arquitectura sea similar al ambiente de produccin, evitando
en todos los casos utilizar el ambiente real del cliente.
- Pruebas de Aceptacin: Independientemente de que se haya tercerizado el
proceso de pruebas y as la firma responsable de estas actividades haya
emitido un certificado de calidad sobre el sistema objeto de prueba, es
indispensable, que el cliente designe a personal que haga parte de los
procesos de negocio para la ejecucin de pruebas de aceptacin, es incluso
recomendable, que los usuarios finales que participen en este proceso, sean
independientes al personal que apoy el proceso de desarrollo.

Metodologa de Pruebas:

Un proceso de pruebas formal, est compuesto, cuando menos por las

siguientes 5 tpicas etapas:

12345-

Planeacin de pruebas.
Diseo de pruebas.
implementacin de pruebas.
Evaluacin de criterios de salida.
Cierre del proceso.

1- Planeacin de Pruebas:
Es la etapa en donde se ejecutan las primeras actividades correspondientes al
proceso de pruebas y tiene como resultado un entregable denominado plan de
pruebas el cual debe estar conformado en cuando menos por aspectos tales
como:

Alcance de la prueba: determina que funcionalidades del producto y/o

software sern probadas durante el transcurso de la prueba. Este listado
de funcionalidades a probar se extrae con base a un anlisis de riesgos
realizado de manera previa, que tienen en cuenta variables tales como

el impacto que podra ocasionar la falla de una funcionalidad y la

probabilidad de falla de una funcionalidad. Producto de este anlisis, se
cuenta con informacin adicional que permite determinar adems del
alcance detallado del proceso de pruebas, la prioridad con la que las
funcionalidades deben probarse y la profundidad de las pruebas.
Tipos de Prueba: en este punto se debe determinar qu tipos de pruebas
requerira el producto. No todos los productos de software requieren la
aplicacin de todos los tipos de pruebas que existen, por esta razn, es
estrictamente necesario que el lder de pruebas se plantee preguntas
que le permitan determinar qu tipos de prueba son aplicables al
proyecto en evaluacin. Los posibles tipos de prueba a aplicar son:
pruebas de stress, pruebas de rendimiento, pruebas de carga, pruebas
funcionales, pruebas de usabilidad, pruebas de regresin, entre otros.
Estrategia de Pruebas: teniendo en cuenta que no es viable probar con
base a todas las posibles combinaciones de datos, es necesario
determinar a travs de un anlisis de riesgos sobre que funcionalidades
debemos centrar nuestra atencin. Adicionalmente, una buena
estrategia de pruebas debe indicar los niveles de pruebas (ciclos) que
aplicaremos y la intensidad o profundidad a aplicar para cada nivel de
pruebas definido. En este punto tambin es importante definir los
criterios de entrada y salida para cada ciclo de pruebas a ejecutar.
Criterios de Salida: entre las partes involucradas en el proceso, se define
de manera formal, bajo qu condiciones se puede considerar que una
actividad de pruebas fue finalizada. Los criterios de salida se deben
definir para cada nivel de pruebas a ejecutar. Algunos ejemplos de
criterios de salida que pueden ser utilizados son: porcentaje de
funcionalidades de alto riesgo probadas con xito, nmero defectos
crticos y/o mayores aceptados, etc.
Otros aspectos: tal y como se realiza en cualquier plan de proyecto, se
debe incluir una estimacin de tiempos, los roles y/o recursos que harn
parte del proceso, la preparacin del entorno de pruebas, cronograma
base, etc.

2- Diseo de Pruebas: una vez elaborado y aprobado el plan de pruebas, el

equipo de trabajo debe iniciar el anlisis de toda la documentacin existente
con respecto al sistema, con el objeto de iniciar el diseo de los casos de
prueba. Los entregables claves para iniciar este diseo pueden ser: casos de
uso, historias de usuario, arquitectura del sistema, diseos, manuales de
usuario (si existen), manuales tcnicos (si existen). El diseo de los casos,
debe considerar la elaboracin de casos positivos y negativos. Los casos de
prueba negativos permiten validar cmo se comporta el sistema ante
situaciones atpicas y permite verificar la robustez del sistema, atributo que
constituye uno de los requerimientos no funcionales indispensable para
cualquier software. Por ltimo, es necesario definir cules son los datos de
prueba necesarios para la ejecucin de los casos de prueba diseados.
3- Implementacin y Ejecucin de Pruebas: la ejecucin de pruebas debe iniciar
con la creacin de los datos de prueba necesarios para ejecutar los casos de

prueba diseados. La ejecucin de estos casos, puede realizarse de manera

manual o automatizada; en cualquiera de los casos, cuando se detecte un
fallo en el sistema,
este debe ser documentado y registrado en una
herramienta que permita gestionar los defectos. Una vez el defecto ha sido
corregido por la firma desarrolladora en su respectivo proceso de depuracin,
es necesario realizar un re-test que permita confirmar que el defecto fue
solucionado de manera exitosa. Por ltimo, es indispensable ejecutar un ciclo
de regresin que nos permita garantizar, que los defectos corregidos en el
proceso de depuracin de la firma, no hayan desencadenado otros tipos de
defectos en el sistema.
4- Evaluacin de Criterios de Salida: los criterios de salida son necesarios para
determinar si es posible dar por finalizado un ciclo de pruebas. Para esto, es
conveniente definir una serie de mtricas que permitirn al finalizar un proceso
de pruebas, comparar los resultados obtenidos contra las mtricas definidas, s
los resultados obtenidos no superan la mtricas definidas, no es posible
continuar con el siguiente ciclo de pruebas.
5- Cierre del proceso: durante este periodo de cierre el cual histricamente se
ha comprobado que se le destina muy poco tiempo en la planeacin, se deben
cerrar las incidencias reportadas,
se debe verificar si los entregables
planeados han sido entregados y aprobados, se deben finalizar y aprobar los
documentos de soporte de prueba, analizar las lecciones aprendidas para
aplicar en futuros proyectos, etc.

Tipos de Pruebas:

Test
Test
Test
Test
Test
Test
Test
Test
Test
Test
Test
Test

de
de
de
de
de
de
de
de
de
de
de
de

Facilidad
Volumen
Stress
Usabilidad
Seguridad
Performance
Configuracin
Insta labilidad
Fiabilidad
Recuperacin
Documentacin
Mantenibilidad

Mtodos de Prueba:
Test incrementales:

Testeo continuo, distribuye las pruebas de integracin en la integracin diaria

del cdigo compartido.
Top Down:

Se requieren Stubs para suplantar los mdulos inferiores aun no

implementados.
Los Stubs se quitan a medida que se desarrollan los diferentes mdulos.
Un test por modulo que se suma.
Realizar test de regresin sobre los mdulos.

Desventajas:

Se retrasa la prueba del procesamiento real realizado generalmente en

mdulos de nivel ms bajo.
Desarrollar Stubs que emulen a los mdulos es mucho trabajo.

Bottom Up:

Las pruebas comienzan en el ms bajo nivel con la integracin de

algoritmos que realizan procesamiento.
Se escriben test que dan el contexto de ejecucin a los mdulos.
Se prueban los mdulos.
Se desarrollan e integran funcionalidades del mdulo superior y se
repite.

Desventajas:

Hasta que se logre un nivel determinado, la aplicacin no es visible.

Problemas asociados a volumen, recursos y tiempo se prueban en
etapas tardas.

Caja Negra:
Pruebas funcionales sin acceso al cdigo fuente de las aplicaciones, se trabaja
con entradas y salidas.
Caja Blanca:
Pruebas con acceso al cdigo fuente (datos y lgica). Se trabaja con entradas y
salidas y el conocimiento interno.

Mateo Rodrguez Ocampo