Un Método de Generación de Pruebas de Rendimiento para Múltiples Tecnologías desde Modelos UML con Anotaciones MARTE

Introducción Generación de artefactos de prueba de rendimiento Conclusiones y trabajo futuro

Un Método de Generación de Pruebas deRendimiento para Múltiples Tecnologías desde

Modelos UML con Anotaciones MARTE

A. García Domínguez e I. Medina Bulo

SEUniversidad de Cádiz, España

JISBD 201218 septiembre, 2012

A. García Domínguez e I. Medina Bulo UCASE (Universidad de Cádiz)

Generación de Pruebas de Rendimiento desde MARTE 1 / 19


Contenidos

1 IntroducciónMotivaciónModelos de rendimientoAlgoritmos de inferencia

2 Generación de artefactos de prueba de rendimientoEnfoque generalDesde pruebas unitarias en JavaDesde documentos WSDL

3 Conclusiones y trabajo futuro




Motivación

Rendimiento como requisitoEn algunos contextos, puede ser clave para tener éxitoSe firman Acuerdos de Nivel de Servicio en partes críticasEs difícil garantizar el cumplimiento de un acuerdo en unacomposición de Servicios Web

Principal reto: dependencia en otros servicios¿Cuánto rendimiento debemos pedir?Insuficiente: no cumpliremos nuestro acuerdoExcesivo: pagaremos más de la cuenta




Enfoques existentes para obtener el rendimiento deseado¿Desde acuerdos o desde código? ¿Ascendente o descendente?

Ingeniería de rendimiento tradicional: acuerdos, ascendenteTenemos acuerdos para todos los componentesEstimamos el rendimiento global y comparamos¿Y si no tenemos esa información para algún servicio?

Perfilado o monitorización: código, ascendenteHemos implementado todos los serviciosMedimos tiempos reales y corregimos cuellos de botella¿Y si tenemos que firmar un acuerdo antes de implementar?




Nuestro enfoque: inferencia de rendimiento

CaracterísticasDesde acuerdos, descendenteTenemos requisitos para la composición y anotaciones localescon nuestros conocimientos parciales sobre los servicios usadosInferimos el rendimiento mínimo a exigir a los servicios

VentajasPuede usar la información incompleta que haya disponiblesobre los serviciosPuede ayudar a definir el acuerdo antes de implementar




Ejemplo de modelo: motor de búsqueda de viajes

RecibirConsulta

ConsultarAerolínea A

ConsultarAerolínea B

ConsultarHotel C

ConsultarHotel D

Reservarc

!c




Inferencia de peticiones por segundo

«gastep»{throughput = ?}

RC


CAA


CAB


CHC


CHD


R

«gascenario»{throughput =(10Hz, req)}

«gastep»{prob = 0.8}

c


!c




Inferencia de peticiones por segundo

«gastep»{throughput = 10}

RC


CAA


CAB


CHC


CHD


R

«gascenario»{throughput =(10Hz, req)}


c


!c




Inferencia de tiempos límite

«gastep» {hostDemand= {(sRP, req)}}

RR

«gastep» {hostDemand= {(5, req)}}

QAA

«gastep» {hostDemand= {(sAB, req)},rep=3}

QAB

«gastep» {hostDemand= {(sHC, req)}}

QHC

«gastep» {hostDemand= {(2 + sHD, req)}}

QHD

«gastep» {hostDemand= {(3 × sR, req)}}

B

«gascenario»{respT = (10s, req)}«gaanalysiscontext»{contextParams = {sRP = ?, sAB = ?,sHC = ?, sHD = ?,

sR = ?}}






RR


QAA


QAB


QHC


QHD


B

«gascenario»{respT = (10s, req)}«gaanalysiscontext»{contextParams = {sRP = ?, sAB = ?,sHC = ?, sHD = ?,

sR = ?}}






RR


QAA


QAB


QHC


QHD


B

«gascenario»{respT = (10s, req)}«gaanalysiscontext»{contextParams = {

sRP = 0,6, sAB = 1,66,sHC = 2,6, sHD = 0,6,

sR = 0,6}}




Contenidos

1 IntroducciónMotivaciónModelos de rendimientoAlgoritmos de inferencia

2 Generación de artefactos de prueba de rendimientoEnfoque generalDesde pruebas unitarias en JavaDesde documentos WSDL

3 Conclusiones y trabajo futuro




Punto de partida

Modelo derendimiento

Modelodiseño/impl.

TransformaciónM2T

Artefactosde pruebas

¿Cómo podemos relacionar los modelos de rendimiento con losmodelos de diseño e implementación, a la vez que los mantenemos

limpios de detalles innecesarios?




Entrelazado de modelos para unir rendimiento y diseño


Modelodiseño/impl.

Modeloentrelazado

TransformaciónM2T


¿Qué hacer cuando no tenemos modelos de diseño o deimplementación, sino sólo código?




Extracción de modelos desde código


Modelodiseño/impl.

Extracciónde modelos

Código

Modelo deentrelazado

TransformaciónM2T


¿Qué hacer si el modelo de entrelazado no es suficientementedetallado?




Refinamiento de modelos de entrelazado y resultado final


Modelodiseño/impl.

Extracciónde modelos

Código

Modelo deentrelazado

Transf. M2Mde refinado

Modelo entr.refinado

TransformaciónM2T





Generación desde pruebas unitarias en JavaMuchos SW se hacen en Java (Apache Axis, Apache CXF) y se prueban con JUnit

Código Desc. modelos Modelo entrel. Artefactos de prueba

public class MisPruebasUnitarias {@Testpublic void rechazado() {

// ... test code ...}

@Testpublic void aceptado() {

// ... test code ...}

}






Casos de prueba






Caso de prueba

Requisito de rendimiento






@RunWith(ContiPerfSuiteRunner.class)@SuiteClasses(MyUnitTests.class)@PerfTest( invocations = 100, threads = 10)@Required(max=1000)public class PruebaCargaInferida {}

Se usa la biblioteca ContiPerf para generar menos códigoSe pueden convertir conjuntos completos o pruebas sueltasSe pueden expresar tiempos límite como máximos, promedios,percentiles (90%, 95% , 99%) o medianas




Generación desde documentos WSDL

DiferenciasPodemos usar el documento WSDL como modelo de diseñoNecesitamos otro metamodelo específico de entrelazadoUsamos una herramienta de pruebas de rendimiento separada:The Grinder

Generación de casos de prueba: refinamiento del entrelazadoEl anterior enfoque reutilizaba pruebas existentesEn este caso, el modelo de entrelazado puede especificar cómogenerar las pruebasEl paso de refinamiento del modelo de entrelazado podríaimplementar la generación




Conclusiones y trabajo futuro

ResultadosHemos presentado un enfoque general para generar pruebas derendimiento para varias tecnologías desde los mismos requisitosHemos mostrado dos formas de usar este enfoque, empleandotecnologías libremente disponiblesAmbos enfoques están implementados y disponibles bajo laEclipse Public License

Trabajo futuroEstrategias alternativas para generar entradas desde WSDLValidar el enfoque con casos de estudio mayores



Fin de la presentación

¡Gracias por su atención!

Código y descargas:https://neptuno.uca.es/redmine/projects/sodmt

E-mail:[email protected]

Twitter:@antoniogado



https://neptuno.uca.es/redmine/projects/sodmt

mailto:[email protected]

Referencias I

A. García-Domínguez, I. Medina-Bulo and M. Marcos-Bárcena.Model-driven design of performance requirements with UMLand MARTE.Actas de ICSOFT 2011, Sevilla, España, págs. 54–63.

H. Bruneliere, J. Cabot, F. Jouault, and F. Madiot.MoDisco: a generic and extensible framework for model drivenreverse engineering.Actas de ASE 2010, Antwerp, Bélgica, págs. 173–174.

D. S. Kolovos.Epsilon ModeLink.http://eclipse.org/epsilon/doc/modelink/



http://eclipse.org/epsilon/doc/modelink/

Referencias II

V. Bergmann.ContiPerf 2.http://databene.org/contiperf.html



http://databene.org/contiperf.html

Education

Un Método de Generación de Pruebas de Rendimiento para Múltiples Tecnologías desde Modelos UML con Anotaciones MARTE